はじめに：AIとの新たな対話パラダイム「/goal」の登場

AIとの協働を次のレベルへ：自律型エージェントの核心「/goal」が拓く未来

近年、人工知能、特に大規模言語モデル（LLM）の進化は目覚ましく、私たちの仕事や生活に深く浸透しつつあります。その中でも、AIとの効果的な協働をいかに実現するかは、生産性向上における喫緊の課題となっています。OpenAIのCodexをはじめとするAIプラットフォームは、開発者や知識労働者がAIの能力を最大限に引き出すためのさまざまな試みを行ってきました。従来のAIとの対話は、主に「ターンベース」というパラダイムに縛られていました。これは、ユーザーがプロンプトを入力し、AIが応答を生成し、ユーザーがその応答をレビューし、フィードバックを与え、AIが次のステップに進む、という一連の逐次的なプロセスです。この往復運動は、シンプルである一方で、複雑なタスクや多段階の作業においては、レイテンシー（応答遅延）が蓄積し、生産性を低下させる要因となっていました。

このような課題意識から、OpenAIのJason LuはCodexを最大限に活用するための9つのテクニック「Codex maxing」を提唱しました。これらは、単一のスレッドで関連するすべてのコンテキストを保持し続ける「耐久性のあるスレッド（モノスレッド）」の概念や、サイドパネルでの成果物検査、音声入力、作業中のフィードバック挿入（ステアリング）、リモート制御、ハートビート機能などを通じて、人間とAI間のレイテンシーを効果的に削減し、より並行的な作業フローを実現することを目指しました。これらの技術は、AIとの対話が単なる質疑応答の繰り返しではなく、より統合された協働プロセスへと移行しつつあることを示唆しています。

そして、この進化の最前線に位置するのが、今回深く掘り下げる「/goal」という新機能です。これは、単なる「より高度なプロンプト」ではなく、AIとの協働のあり方を根本から変える可能性を秘めた「新しいプリミティブ」として登場しました。このブログ記事では、「/goal」がどのようにAIの自律性を飛躍させ、私たちの知識労働にどのような変革をもたらすのかを、その機能、応用、そして将来性に至るまで詳細に解説していきます。

「/goal」とは何か？：AIの自律性を飛躍させる新概念

「/goal」は、OpenAIのCodexチームによって導入され、そのインパクトの大きさから、瞬く間に他の競合プラットフォーム（例：Claude Code）にも採用された、画期的な機能です。CodexチームのTiboは「/goal」を「Codexに搭載された最も結果に結びつく可能性のあるもの」と評し、良い指示の価値がかつてないほど高まっていることを指摘しました。

「/goal」の核心：ループ、自己評価、そして自律的な完了

Pavel Huronは「/goal」のメカニズムを簡潔に説明しています。「あなたは成果を述べる。モデルはループし、自己評価し、完了したら停止する。」この「ループ」という概念こそが、「/goal」の核心であり、従来のAIとの対話モデルからの決定的な脱却を意味します。

過去には、人間が介入せずともAIが問題を繰り返し解決し続けるための「Ralph Wiggumループ」のようなハック的な手法が存在しました。Anthropicに移籍した元OpenAI共同創設者のAndre Karpathyも、「LLMは特定の目標を達成するまでループすることに非常に優れている」と述べ、自身の「オートリサーチループ」のような取り組みを通じて、このループの重要性を強調しています。彼らは、「AIに何をするべきか指示するのではなく、成功基準を与え、その動きを見守るべきだ」と提言しています。

つまり、「/goal」は、AIに「具体的な手順」を指示するのではなく、「達成すべき最終的な状態（成果物）と、それを確認するための基準」を与えることで、AIが自律的にタスクを分解し、実行し、その結果を自己評価し、目標達成まで繰り返し作業を続けることを可能にするのです。Pavel Huronは、この新たなスキルを「意図のエンジニアリング」と呼び、なぜそのタスクが重要なのか、戦略的な文脈は何か、成功はどのように測定されるのかを明確にすることで、AIエージェントがより良い自律的な意思決定を行えるようになると述べています。

広がる反響と「新しいプリミティブ」としての確立

「/goal」の登場は、開発者コミュニティに大きな反響を呼びました。Gregor Zunicは「OpenAIがこれまで出荷した中で最高の機能の一つだ」と絶賛し、Alex Finnは「今最も過小評価されているAI機能だ」とコメントしました。Ollie Lemonは、これを「複雑なAIタスクのオートパイロット」と表現し、非技術者向けにその動作を以下の5段階で説明しました。

1. /goalと入力し、望む最終結果を記述する。
2. AIが作業を開始する。
3. 各ステップの後、AIは自己チェックを行う。「終わったか？」
4. 終わっていなければ、作業を続行する。
5. 終わっていれば、停止してユーザーに報告する。

この単純ながらも強力なパラダイムは、その有用性が瞬く間に認識され、わずか数週間後にはClaude Codeも同機能を採用しました。さらに注目すべきは、Claude Codeがこの機能を「/goal」という同じ名称で導入したことです。これは、特定の企業が機能を独占しようとするのではなく、その普遍的な価値を認識し、新たな「プリミティブ（基本要素）」として業界全体で共有する賢明な判断と言えるでしょう。

MicrosoftのNicholas Bustamanteは、この動きを歓迎し、「/goalが長時間実行タスクの新しいプリミティブとなることを嬉しく思う」と述べています。彼は、モデルがターン、コンテキストウィンドウ、サンドボックス、プロセス障害、または数日間の作業を通して自然に永続しないという課題に対し、「/goal」がハーネス（AI実行環境）の助けを借りて、あいまいなユーザーの意図を計画ファイルを持つ耐久性のあるワークスペース構造に変換し、ワーカーエージェントがその構造に対して着実に進捗させ、ジャッジエージェントが完了条件が満たされたかどうかを判断するメカニズムを賞賛しました。彼は、2024年にユーザーが自分でwhileループを記述していたものが、2026年には「ループがプロダクトプリミティブになる」というように、抽象化のレベルがスタックを上に移動していると指摘しています。

Sean Wang（Swyx）は、「/goal」がAIの自律性のレベルをさらに引き上げたと分析しています。以前の/skill（事前設定されたプロンプト）から/plan（人間が洗練した入力）へと進化し、そして今や/goalによってAIが自律的に出力を評価する段階に到達したと見ています。この「/goal」は、AIとの協働における新たなスタンダードを確立しつつあり、その利用方法を深く理解することは、今後のAI活用において不可欠となるでしょう。

「プロンプト」と「ゴール」の根本的な違い

「/goal」を理解する上で最も重要なのは、これが単なる「より大きなプロンプト」ではない、という認識です。両者はAIとの相互作用のパラダイムにおいて、根本的に異なるタイプのアプローチを代表しています。

プロンプト：逐次的な対話と人間の絶え間ない介入

従来の「プロンプト」ベースのAIとの対話は、基本的に「要求と応答の繰り返し」です。

1. ユーザーが特定の質問や指示（プロンプト）をAIに与える。
2. AIは即座にその指示に基づいた結果（テキスト、コード、画像など）を生成する。
3. ユーザーはその結果をレビューし、必要に応じて「さらに進めて」「ここを修正して」といった次の指示（フィードバック）を与える。
4. AIは新たな指示に基づいて作業を続ける。

このプロセスは、AIが特定のタスクの一部を実行し、その度に人間が次のステップを決定・指示する「ターンベース」のモデルです。人間はAIの「監督者」として、各中間ステップで状況を評価し、AIの進路を逐一「ステアリング」する必要があります。例えば、コードのバグを見つけるタスクの場合、「このコードをレビューして」「ここにバグがあるか調べて」「見つけたバグを修正して」と、細かく指示を出すことになります。

ゴール：自律的なループと「フィニッシュライン契約」

対照的に、「/goal」はAIとの関係を「フィニッシュライン契約」として定義します。OpenAIのガイダンスを要約すると、「/goal」は以下の3つの要素を含むものとして説明されます。

1. 何が真実であるべきか（What should be true）：最終的に達成されるべき状態、つまり目標を明確に定義します。
2. 成功はどのようにチェックされるべきか（How success should be checked）：目標達成を客観的に判断するための基準、証拠を具体的に指定します。
3. 途中で何が損なわれないか（What has to stay intact along the way）：作業中に維持すべき制約や条件を明確にします。

「/goal」は、この「フィニッシュライン契約」に基づき、ユーザーからのフィードバックを待つことなく、自律的に以下の連続的なループを実行します。

1. 耐久性のある目標に向かって作業を進める：AIは与えられた目標（耐久性のある目的）を達成するために、タスクを分解し、実行可能なステップを特定し、作業を開始します。
2. 現在の証拠をフィニッシュラインと比較してチェックする：各ステップの実行後、AIは自らその進捗と結果を評価します。与えられた成功基準と照らし合わせ、現在の状態が目標達成にどれだけ近づいているか、または達成しているかを判断します。
3. 継続、完了、または停止を決定する：自己評価の結果に基づき、AIは以下のいずれかを決定します。
   • 継続（Continue）：まだ目標が達成されていない場合、AIは次の最適なステップを自律的に決定し、作業を続けます。
   • 完了（Complete）：目標が達成され、成功基準が満たされた場合、AIは作業を停止し、結果をユーザーに報告します。
   • 停止（Stop because it's blocked）：これ以上進めることができない、または有効なパスが存在しないと判断した場合、AIは作業を停止し、その理由を説明します。

このメカニズムの背景には、多くの仕事が本質的に「逐次性」を持っているという認識があります。つまり、前のステップから何らかの知見を得るまで、次のステップが何かを知ることができないという特性です。従来のプロンプト方式では、このような逐次的な作業において、AIが各中間ステップで立ち止まり、人間が「続けて」「これをチェックして」「あれを再実行して」と指示を出す必要がありました。「/goal」は、この「続けて」ボタンをAI自身が押せるようにすることで、人間の介入を最小限に抑え、AIがより長く、より自律的に作業に集中できる環境を提供するのです。

要するに、プロンプトが「何を今すぐ実行してほしいか」を問うのに対し、「/goal」は「最終的に何が完了しているべきか」を問います。これは、AIへの指示の粒度と、タスク実行におけるAIの自律性に根本的な違いをもたらします。

「/goal」が真価を発揮するタスクの特性

「/goal」が全てのタスクに万能というわけではありません。この強力な機能が最も効果を発揮するのは、特定の特性を持つタスクです。OpenAIの開発者によるドキュメントでは、プロファイリング、パッチ適用、ベンチマーク、再現性の低いテストの再現、移行作業、バグハント、研究監査といった、コード関連のタスクが中心に挙げられています。これらのタスクに共通するのは、「具体的なターゲットがあるにもかかわらず、その達成までの経路がAIが証拠を収集するにつれて変化する」という点です。

良い「ゴール」候補となる仕事の3つの条件

「/goal」に適したタスクは、コーディングに限らず、監査可能な永続性（auditable persistence）を必要とするあらゆる目的に応用できます。以下に、良い「ゴール」候補となる仕事の3つの主要な条件を挙げます。

1. 耐久性のある目的（Durable Objective）

   • 目標とするターゲットが、各実行ターンを通じて変化しないこと。
   • 例えば、「このファイルのバグを修正する」という目標は、作業中に修正されるべきバグが常に同じであるため、耐久性があります。しかし、「ユーザーの好みに合わせてUIを頻繁に変更する」といった目標は、ユーザーの好み自体が変動する可能性があるため、耐久性のある目的とは言えません。
   • 目標が作業中に動的に変化するようなタスクには、「/goal」は適していません。目標自体が安定していることが重要です。

2. 不確実な成功経路（Uncertain Path to Success）

   • 目標達成までの具体的な手順が、事前に完全に決まっていないこと。
   • AI（CodexやClaude Codeなど）が、次の最適な行動を決定する前に、現在の状況を「検査（inspect）」、「比較（compare）」、「再実行（rerun）」、「修正（revise）」、「調査（investigate）」する必要があるようなタスクです。
   • 例えば、システムのパフォーマンス改善タスクでは、どこにボトルネックがあるか、どのような改善策が効果的かをAIが試行錯誤しながら見つける必要があります。このような不確実性の高い探索的なタスクは、「/goal」の強みが活かされます。
   • 対照的に、レシピ通りに料理を作るような、手順が明確で一直線なタスクには、AIの自律的な試行錯誤の余地が少ないため、「/goal」のメリットは小さくなります。

3. 明確で監査可能な完了証拠（Strong, Clear Finish Line Evidence）

   • 目標が達成されたことを、客観的かつAI自身が判断できる形で証明できること。
   • 「気分（vibes）」や主観的な印象に頼るのではなく、「テスト（tests）」、「ソースコード（sources）」、「成果物（artifacts）」、「引用（citations）」、ログ、マトリックス、ルーブリックなどの具体的な「証拠（proof）」によって完了を検証できる必要があります。
   • AIがこれらの証拠を「検査可能（inspectable）」であり、それに基づいて「自己評価（self-judge）」して、タスクが実際に完了したかどうかを判断できることが重要です。
   • 例えば、「このドキュメントの誤字脱字を全て修正する」というゴールは、修正されたドキュメントと元のドキュメントを比較することで、AIが自己評価できます。しかし、「このブログ記事をもっと魅力的にする」といった抽象的なゴールは、魅力の基準が主観的であるため、AIが自己評価するための明確な証拠を提供しにくいでしょう。

要するに、「/goal」は、特定の作業の完了を定義します。そして、「/goal」を使用することで、あなたはAIに「何をすべきか」を指示するのではなく、「作業終了時に何が達成されているべきか」を指示する立場へと移行するのです。

ユーザー制御の維持：自律性の中のバランス

「/goal」はAIの自律性を高めるツールですが、ユーザーを完全にプロセスから切り離すことを意図しているわけではありません。むしろ、非常に高いレベルでユーザーによる制御が可能です。ユーザーは、目標を定義するだけでなく、以下のコマンドを通じてプロセスのライフサイクルを管理できます。

• /goal pause：AIの作業を一時停止させます。
• /goal resume：一時停止した作業を再開させます。
• /goal clear：現在の目標とそれに関連するすべての作業履歴をクリアします。
• /goal complete：AIの作業を強制的に完了させます（AIがまだ完了と判断していなくても）。

これらのコマンドは、AIが間違った方向に進んでいると感じた場合や、成功基準を変更する必要が生じた場合に、ユーザーが途中で介入し、進捗を破棄することなく調整を行えるように設計されています。これにより、「/goal」は、AIの自律性とユーザーの監督という二つの要素のバランスを保ちながら、効果的な協働を可能にします。ライフサイクル管理の権限は依然としてユーザーにあり、システムとユーザーが提供した証拠に基づいています。

モノスレッド（耐久性のあるスレッド）の重要性

「/goal」が機能する際のもう一つの重要な側面は、「耐久性のあるスレッド（Durable Threads）」、または「モノスレッド（Mono Threads）」という概念です。これは、プロジェクト全体で共有されるグローバルメモリや広範なプロジェクト指示を利用するのではなく、個々の「スレッド」自体がコンテキストの単位として機能することを意味します。

つまり、「/goal」によって設定された目的と、それに関連するすべての情報は、その特定のチャットスレッド内で蓄積されます。AIは、このスレッド内の履歴と現在のコンテキストのみを参照して、作業を進め、自己評価を行います。このアプローチは、異なるタスクやプロジェクト間でコンテキストが混同されるのを防ぎ、AIが特定の目標に集中して効率的に作業を進めることを可能にします。

効果的な「ゴール」設定のベストプラクティス

「/goal」を最大限に活用するためには、単に最終的な成果を漠然と述べるだけでなく、その設定方法に工夫が必要です。良い「ゴール」プロンプトは、AIが目標達成に向けて自律的かつ効果的に機能するための明確な指針となります。

良いゴールプロンプトの6つの構成要素

OpenAIのヒントドキュメントによると、最も強力なゴールは通常、以下の6つの要素を定義しています。

1. 成果（Outcome）：

   • 作業が完了したときに「何が真実であるべきか」を具体的に定義します。これは、最終的に得られる結果であり、単なる行動ではなく「状態」として記述します。
   • 例：「このPythonライブラリの全ての単体テストがパスすること。」「顧客フィードバックの要約レポートが生成され、主要なペインポイントが特定されていること。」

2. 検証対象（Verification Surface）：

   • 成果が達成されたことを証明する、客観的で監査可能な「証拠」を特定します。AIが自己評価を行うために参照する具体的な対象です。
   • 例：「テストベンチマークレポート」「成果物（特定のファイルやデータベースエントリ）」「コマンド出力」「引用されたソース資料」「ダッシュボードのメトリクス」など。
   • 成果物だけでなく、その成果物を検証する方法（例：make testコマンドを実行し、全てのテストがパスすること）まで指定すると、より効果的です。

3. 制約（Constraints）：

   • Codexが作業中に「何が退行してはならないか（what must not regress）」を明確にします。これは、目標達成のために他の重要な要素を犠牲にしないためのガードレールです。
   • 例：「既存の機能テストは全て引き続きパスすること。」「パフォーマンスが5%以上低下しないこと。」「セキュリティ脆弱性が導入されないこと。」「特定のリソース使用量を超過しないこと。」

4. 境界（Boundaries）：

   • Codexが作業に利用できる「ファイル」「ツール」「リソース」を明確に定義します。これにより、AIが不必要な領域に踏み込んだり、許可されていないリソースを使用したりするのを防ぎます。
   • 例：「src/ディレクトリ内のファイルのみを変更すること。」「GitHub APIのみを使用すること。」「提供されたドキュメントセットのみを参照すること。」
   • これにより、AIが探索する範囲を適切に制限し、関連性の高い情報に集中させることができます。

5. 反復ポリシー（Iteration Policy）：

   • 各試行の後、Codexが「次に何を試すべきかをどのように決定するか」を指示します。これは、AIの試行錯誤の戦略をガイドします。
   • 例：「テストが失敗した場合、最も関連性の高いエラーメッセージからデバッグを開始すること。」「パフォーマンステストの結果に基づいて、最もボトルネックとなっている部分から最適化を試みること。」「複数の選択肢がある場合、最もリスクの低いアプローチから優先すること。」
   • これにより、AIが無作為に試行するのではなく、より賢明な探索パスを選択できるようになります。

6. ブロック停止条件（Block Stop Condition）：

   • Codexが「いつ作業を停止すべきか」を定義します。これは、目標達成が不可能であると判断した場合や、これ以上進められない状況に陥った場合の明確な終了条件です。
   • 例：「3回連続で同じエラーが発生した場合、停止して報告すること。」「既知のすべての手段を試しても問題が解決しない場合、停止すること。」「有効な解決策への道筋が見いだせないと判断した場合。」

これらの要素を盛り込むことで、AIはより明確な目的意識を持って自律的に作業を進め、ユーザーはAIの進捗を信頼し、期待通りの成果を得られる可能性が高まります。

スコープの「ゴールディロックスゾーン」：狭すぎず、広すぎず

「/goal」を設定する際のもう一つの重要な考慮事項は、その「スコープ」です。初期の実験から、目標のスコープには「ゴールディロックスゾーン」のような適正な範囲が存在することが示唆されています。つまり、狭すぎても広すぎても、最適な結果は得られないということです。

• 狭すぎるスコープの課題（例：「この1行を修正して」）：

  • たとえその1行が実際に修正すべき箇所であったとしても、システムに十分な柔軟性を与えない可能性があります。
  • 問題の根本原因が、その1行ではなく、関連する依存関係や上流のロジックにある場合、AIは真の問題を発見し、修正することができません。
  • AIの自律的な探索と問題解決能力が活かされないため、手動で修正するのと大差ない結果になる可能性があります。

• 広すぎるスコープの課題（例：「システム全体を改善して」）：

  • CodexやClaude Codeがタスクを成功裏に達成したかどうかを判断するための具体的な証拠を提供することが非常に困難になります。
  • 「システム全体が改善された」という状態を客観的に測定するための明確な指標や検証可能な成果物が不足しがちです。
  • 目標が曖昧であるため、AIは作業の方向性を見失い、非効率な探索を繰り返したり、期待外れの結果を生成したりする可能性が高まります。

「ちょうど良い」スコープは、これら両極端の中間に位置します。AIに問題の解決策を探索する十分な柔軟性を与えつつ、目標達成を客観的に検証できる具体的な成果物と成功基準を伴うスコープです。例えば、「このモジュールのテストカバレッジを80%以上に引き上げる」といった目標は、モジュールという適切な範囲を設定しつつ、テストカバレッジという明確な検証基準を提供できます。

強力な「成果物」定義の重要性

スコープと同様に、目標の「成果物（Output Artifact）」を明確に定義できるかどうかが、「/goal」の成功を左右する大きな要因となります。漠然としたプロンプトが期待外れの結果を生むのと同じように、あいまいな成果物の定義は「/goal」の効果を低下させます。

弱い成果物ゴールの例： 「この機能のドキュメントを作成して。」 この場合、AIが生成するドキュメントがどのような内容であるべきか、どれくらいの詳細度が必要か、どのような形式であるべきかが不明確です。AIはドキュメントを生成するかもしれませんが、それがユーザーの期待する「最良の証拠サーフェス」を提供しない可能性があります。

強力な成果物ゴールの例： 「ライフサイクル、コマンドサーフェス、および2つの具体的な使用例を説明するドキュメントページを作成せよ。そのページがローカルでビルドされ、参照されているすべてのコマンドが現在のCLIの動作と一致することを確認せよ。」 この例では、成果物の内容（ライフサイクル、コマンド、例）が具体的に指定され、さらにその検証基準（ローカルビルド可能、CLI動作との一致）まで明確に定義されています。これにより、AIは目標達成のために何をすべきか、そしてどのように自己評価すべきかを正確に理解し、期待される高品質なドキュメントを生成する可能性が高まります。

このように、明確で監査可能な成果物の定義は、「/goal」が単なるテキスト生成を超えて、実用的な価値を持つアウトプットを生み出すために不可欠です。

知識労働への「/goal」の応用：具体的なユースケースと可能性

これまで見てきたように、「/goal」の多くの初期の例は開発者向けのコーディングタスクに焦点を当てていました。しかし、その根本的なメカニズムは、ソフトウェアエンジニアリング以外の広範な「知識労働（Knowledge Work）」にも適用可能です。鍵となるのは、「出力が単なる『答え』ではなく、『監査報告書』となり得るか」という視点です。

「監査」としての出力：知識労働における「/goal」の強み

良い非コーディングの「ゴール」は、単一の事実や意見を提供するだけでなく、以下の要素を含む「台帳（ledger）」のような出力を生成します。

• 何がチェックされたか（What was checked）：検証された情報源やデータ。
• 何が支持されたか（What was supported）：確認された事実や主張。
• 何が矛盾したか（What was contradicted）：確認された情報と矛盾する事実や主張。
• 何が弱かったか（What was weak）：根拠が薄い、または不十分な情報。
• 何が不明のままか（What remains unknown）：現在の情報源では判断できない未解決の疑問。

このような出力は、情報収集、分析、検証が不可欠な多くの知識労働タスクにおいて非常に価値があります。AIが自律的に情報を収集し、複数の情報源を比較検討し、その信頼性や矛盾を指摘することで、人間が行うデューデリジェンス、研究、分析作業を大幅に効率化できる可能性を秘めています。

成功定義の源泉：外部基準とユーザー提供基準

知識労働における「/goal」の適用を考える上で、成功基準（ルブリック）がどこから来るのかを理解することは非常に重要です。大きく分けて2つのパスがあります。

1. 外部で定義可能なルブリック（Externally Definable Rubric）：

   • これは、すでに存在し、公開されている客観的な基準を指します。
   • 例：既存の公開された業界標準、公式ドキュメント、第三者提供のデータセット、既存のログや議事録、特定のプロジェクトで定められたRFP（提案依頼書）の質問事項など。
   • これらの基準は普遍的で、AIが参照し、それに基づいて自己評価を行いやすい性質を持っています。

2. ユーザー提供ルブリック（User-Provided Rubric）：

   • 多くの知識労働のユースケースにおいて、成功基準は外部に明確に存在せず、ユーザー自身が定義する必要があるケースが非常に多いです。これが「/goal」が本当に力を発揮し始める領域であり、非常に興味深い点です。
   • 例：
     • 採用基準：外部に普遍的な採用基準があるわけではなく、企業やポジションごとにユーザー（採用担当者）が求める具体的なスキル、経験、特性をAIに明確に伝える必要があります。AIはこれらの基準に基づき、候補者の履歴書やポートフォリオを評価します。
     • ベンダー評価スコアカード：ベンダーの評価基準は、企業固有のニーズや優先順位によって異なります。ユーザーは、AIに自社のベンダーに求める具体的な要素（例：コスト、信頼性、サポート、技術力）と、それらを評価するためのスコアリング基準を提供します。
     • 編集基準：出版物やコンテンツ作成における編集基準は、メディアのブランドや方針によって異なります。AIは、これらの内部基準に沿って原稿をレビューし、改善点を提案します。
     • リード評価ルール（Lead Qualification Rules）：営業におけるリードの適格性判断基準は、製品やターゲット市場によって変動します。
     • 投資デューデリジェンス優先順位：投資家は、独自の投資戦略やリスク許容度に基づき、デューデリジェンスの優先順位を設定します。

実際、もしあなたが取り組んでいる知識労働タスクが、暗黙的に何らかの評価基準や成功条件を伴っている場合、それは「/goal」プリミティブの優れた候補である可能性が高いと考えることができます。

知識労働における「/goal」の10の具体例

ここでは、「/goal」が特に適していると考えられる10の知識労働分野と、いくつかの詳細な例を挙げます。

1. 文献レビュー（Literature Reviews）
2. 市場調査（Market Landscapes）
3. ベンダー評価（Vendor Evaluations）
4. デューデリジェンス（Due Diligence）
5. クレーム監査（Claim Audits）
6. 政策研究（Policy Research）
7. インタビュー要約（Interview Synthesis）
8. タイムライン再構築（Timeline Reconstruction）
9. スプレッドシート監査（Spreadsheet Audits）
10. 戦略メモ（Strategy Memos） (入力が雑多な場合)

これらのタスクは、多くの場合、大量の情報を構造化された形式に整理し、特定の基準に基づいて評価することを伴います。

具体例の掘り下げ

1. クレーム監査（Claim Audits）

クレーム監査は、「/goal」にとって非常に明確な適合性を持つユースケースです。

ゴール設定の例： /goal このメモの各主張を監査せよ。各主張を提供された情報源と信頼できる外部情報源（別途提供）と照合して検証せよ。最終的に、各主張を「支持された」「矛盾した」「部分的に支持された」「未検証」のいずれかに分類するテーブルを作成し、引用と不確実性に関する注記を付記せよ。

このゴールは、まさに「監査証跡」としての出力を求めており、適切な「ゴールディロックスゾーン」に位置しています。AIが下す全ての結論は、明確な証拠に遡って追跡可能であるため、非常に効果的に機能します。

2. 市場調査（Market Landscapes）

市場調査は通常のAIによるリサーチクエスチョンに見えるかもしれませんが、「/goal」の視点で見ると大きく異なります。

ゴール設定の例： /goal X市場の市場調査レポートを作成せよ。引用された企業のウェブページ、提出書類、アナリストレポート、価格ページ、製品ドキュメントによって検証すること。最終的に、比較テーブル、信頼度レベル、および証拠が不足しているギャップ箇所を提示せよ。

このゴールを一般的なリサーチプロジェクトから「/goal」プロジェクトへと昇華させているのは、「プロセスと出力を監査として扱う」という考え方です。AIが目指す成果物は、検証可能な情報、推測された情報、そして証拠が不足している箇所を示す比較テーブルです。これにより、単なる情報収集に留まらず、情報の信頼性と完全性まで評価したレポートが期待できます。

3. 文献レビュー（Literature Reviews）

文献レビューも、複雑で多様な情報を扱う知識労働の典型です。「/goal」を適用することで、対立する証拠や意見の相違を単に「平坦化」するのではなく、むしろ「際立たせる」ことができるようになります。

ゴール設定の例： /goal Xトピックに関する証拠に基づいた文献レビューを提供せよ。方法論、サンプルサイズ、発見、限界、および矛盾をカバーする情報源マトリックスを作成せよ。最終的に、確認されたテーマ、議論されている発見、および未解決の質問を提示せよ。

このパターンは、証拠が目録化され、完全な形で提示できるあらゆる場所で機能します。AIは、各研究の重要な側面を抽出し、それらを比較検討することで、単なる要約ではなく、批判的で洞察に満ちた文献レビューを生成します。

「/goal」と従来のプロンプトの使い分け：プロセス全体の自動化

私の推測では、多くの知識労働者が「/goal」を短期的に利用する方法は、主に「ユーザー提供のルブリック」がある分野になるでしょう。従来のプロンプトは、単一パス（single pass）の作業には適しています。例えば、「この5つのアプリケーションをこのルブリックと照らしてレビューし、証拠を引用し、面接の質問を提案せよ」といったプロンプトは、少数の入力、直接的な基準、そして一度の比較的な読み込みで完結するため、うまく機能します。

しかし、「/goal」は、この「一度のレビュー」を、プロセス全体のアーキテクチャへと拡張できます。例えば、上記のようなアプリケーションレビュータスクを「/goal」で設定すると、AIは以下の連続的なプロセスを実行できます。

• 証拠の抽出
• ルブリックの適用
• 一貫性のチェック
• ボーダーラインケースの見直し
• 欠落情報のフラグ立て
• （新しいエントリが追加されるたびに）継続的に更新されるドキュメントの生成

このように、「/goal」は、単なる一度のタスク実行を超えて、繰り返し発生する複雑なプロセス全体を自律的に管理・実行する能力を提供します。これにより、知識労働者は、反復的で時間のかかる評価作業から解放され、より戦略的で創造的なタスクに集中できるようになります。

「/goal」の限界と賢い使い分け

「/goal」は非常に強力なツールですが、すべてのタスクに適しているわけではありません。その能力を過信せず、適切な場面で賢く使い分けることが重要です。

すべてのタスクに適しているわけではない

深く掘り下げていくと、すべてのタスクが「/goal」に適しているわけではないことが明らかになります。実際、おそらくほとんどのケースでは、従来の「ターンベース」のプロンプトによる相互作用パターンで十分であり、かつ最適であるでしょう。

「/goal」が適さない主な理由は以下の通りです。

1. 成果目標が小さい場合：

   • 目的が非常に単純で、一回限りの簡単な質問やタスクであれば、あえて「/goal」のような複雑なフレームワークを使用するメリットはほとんどありません。例えば、「今日の天気は？」や「この文章を要約して」といったタスクは、標準的なプロンプトで十分です。
   • 小さな目的の場合、ゴール設定に費やす時間と労力が、手動で作業を行うよりも大きくなる可能性があります。

2. 成功基準が明確でない、または定義しにくい場合：

   • 前述したように、「/goal」の成功の鍵は、明確で監査可能な「フィニッシュライン契約」を設定できるかどうかです。もし、タスクの完了基準が主観的であったり、曖昧であったり、客観的に測定できないものであれば、「/goal」はうまく機能しません。
   • 例えば、「このアイデアをもっと独創的にする」といった目標は、独創性の基準が人によって異なるため、AIが自己評価を行うことは困難です。このようなタスクでは、人間の創造性や判断力による直接的なフィードバックが不可欠です。

「Codex maxing」のヒントは引き続き重要

「/goal」時代においても、Jason Luが提唱した「Codex maxing」のヒントがその重要性を失うことはありません。なぜなら、多くの場合、ユーザーは「/goal」が提供するような完全なプロセスからの「切断（fully disconnected）」を望まないからです。

• 継続的なステアリングの必要性：特に複雑で新しい分野のタスクでは、AIが完全に自律的に進むよりも、人間が定期的に進捗をレビューし、途中で方向転換や追加の指示を与える「ステアリング」が効果的である場合があります。
• 探索的な作業：未知の領域を探索するようなタスクでは、AIが生成する中間結果から人間が新たな洞察を得て、それに基づいて次のステップを決定したい場合があります。この場合、ターンベースの対話の方が柔軟性が高いと言えます。
• 信頼の構築：AIとの協働において、ユーザーがプロセス全体を完全にブラックボックス化することに抵抗を感じる場合もあります。中間段階での透明性や、必要に応じて介入できる能力は、ユーザーのAIに対する信頼感を高めます。

ユーザーとAIの間の自律性のスペクトル

要するに、ユーザーとAI（ハーネス）の間の「インタラクション自律性」にはスペクトルが存在します。

• 完全な人間主導：すべてのステップを人間が指示し、AIはツールとして機能する。
• ターンベースの対話：プロンプトとフィードバックの繰り返し。人間が各ターンの判断を監督する。
• 部分的な自律性：「Codex maxing」のヒントを活用し、レイテンシーを削減しつつ、必要に応じて人間が介入する。
• 高度な自律性：「/goal」のように、成果物と基準を定義すれば、AIが自律的にループし、自己評価し、完了まで作業を進める。

どの方法が最適かは、達成しようとしているタスクの種類、その複雑さ、成功基準の明確さ、そしてユーザーがプロセスにどれだけ関与したいかによって異なります。

「/goal」は、このスペクトルの高度な自律性側に位置する非常に優れたツールです。しかし、それは全てのタスクに対する唯一の答えではありません。ユーザーは、自身のワークフローとタスクの特性を深く理解し、適切なツールとインタラクションパターンを選択する能力が求められます。

結論：AIとの協働の新時代と「/goal」が拓く未来

「/goal」の登場は、AIとの協働のあり方を再定義する画期的な一歩と言えるでしょう。これまでのAIが主に「人間が指示した単一のタスクを効率的に実行するツール」であったのに対し、「/goal」はAIを「設定された目標に向けて自律的に問題解決プロセスを実行し、自己評価を行うエージェント」へと進化させます。

このパラダイムシフトがもたらす最大のメリットは、知識労働者の生産性の飛躍的な向上です。反復的で時間のかかる中間ステップの監督から解放されることで、人間はより高度な思考、創造的な問題解決、戦略的な意思決定といった、真に人間が得意とする領域に集中できるようになります。これは、個人のワークフローを最適化するだけでなく、企業や組織全体のオペレーション効率を劇的に改善する可能性を秘めています。

また、「/goal」は、AIに対する私たちの指示の仕方に変化を促します。単に「何をすべきか」を指示するのではなく、「最終的にどうなっていてほしいか」「それをどう確認できるか」という「意図のエンジニアリング」が、これからのAI活用における重要なスキルとなるでしょう。これにより、私たちはAIの潜在能力をより深く引き出し、より複雑で大規模な課題にAIを適用できるようになります。

現時点ではまだ導入から日が浅く、多くのユースケースが模索されている段階です。特に、コーディング以外の知識労働分野での具体的な応用事例やベストプラクティスは、今後数週間から数ヶ月でさらに豊富になることが期待されます。しかし、文献レビュー、市場調査、デューデリジェンス、クレーム監査といった、証拠に基づいた分析や検証が不可欠な知識労働において、「/goal」がどれほど大きな変革をもたらすかは明らかです。

「/goal」は、単なる機能追加ではなく、AIとの関係性における新たな「プリミティブ」です。この強力なツールを理解し、自身のワークフローにどのように統合できるかを実験することは、これからのAI時代を生き抜く上で不可欠な投資となるでしょう。

AIの進化は止まることを知りません。「/goal」が私たちをどこへ導くのか、その可能性を探求することは、未来の働き方を形作る上で非常にエキサイティングな挑戦となるはずです。