レッスン3: 委任のためのプロンプトを書く

学習目標:

• サブエージェントがあなたとオーケストレーターの会話を見ることに依存しない、自己完結型の委任プロンプトを書く
• タスクの範囲、境界、どのソースを使うかを委任プロンプト自体の中で明示する
• 「1つの問題領域、1つのエージェント」原則と、それを破るコストを説明する

前提: レッスン2を完了し、オーケストレーター・サブエージェントアーキテクチャとコンテキストの分離を理解している | 前: レッスン2 << | 次: レッスン4 >>

復習: サブエージェントが見られないものは、あなたがそのために書き込む必要がある

レッスン2はここで重要な1つのメカニズムをカバーしました: "Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. Claude composes a delegation message that summarizes the task, and the subagent works from there."（各サブエージェントは新鮮な、分離されたコンテキストウィンドウから始まる。それはあなたの会話履歴、あなたが既に呼び出したスキル、Claudeが既に読んだファイルを見ない。Claudeはタスクを要約した委任メッセージを作成し、サブエージェントはそこから作業する）¹。このレッスンはそれを具体化します。つまり、オーケストレーターレベルでユーザーと話し合ったすべての背景、以前のラウンドで決着させたトレードオフ、ユーザーが何気なく投げ込んだ制約——サブエージェントはそれを何も知りません。サブエージェントが知っているのは、あなたがこの1つの委任タスクに書いた言葉だけです。

これは優しいリマインダーではなく、ハードな制約です: 委任プロンプトの品質の上限が、サブエージェントが生み出すものの品質の上限を設定します。プロンプトが明示しないものは、サブエージェントは推測するか、スキップするか、または仮定を発明して進み続けます。正しく推測すれば運が良かった。間違って推測すれば、そのサブタスク全体が基本的に無駄になります。

自己完結型: プロンプトは全体を独自に言わなければならない

自己完結型: 委任プロンプトを読んだ後、サブエージェントは何をすべきかを正確に判断するために追加の背景を必要としません。プロンプトが自己完結型かどうかの簡単なテストがあります。それを単独で引き出し、あなたとオーケストレーターの間のすべてのコンテキストを取り除き、白紙から読みます。それでもタスクの詳細を埋めるために推測しなければならない場合、プロンプトはテストに失敗します。

3つのクラウドプロバイダーの価格調査というレッスン1の例を取り上げましょう。オーケストレーターがサブエージェントに「AWSの価格を調べる」とだけ言うタスクを渡すと、その1行はオーケストレーター自身には十分な情報を運びます——オーケストレーターのコンテキストには「なぜこれを調べているのか」「後で誰と比較するのか」「どの次元で比較するのか」の背景がまだ残っているからです。しかしサブエージェントはそれを何も見ることができません。それが受け取るのは1つの孤独な行、「AWSの価格を調べる」であり、推測するしかありません: どの製品カテゴリーの価格？現在の価格だけ、それとも過去1年間の変更？見つけたら成果物はどのように見えるべき？すべての推測は間違う可能性のある賭けです。

範囲と制約を明示する: 何をすべきか、何をすべきでないか、どのソースを使うか

公式ガイダンスは、堅実なサブエージェントタスク記述が含むべきものをリストしています: "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information."（各サブエージェントは目的、出力フォーマット、使用するツールとソースのガイダンス、明確なタスク境界を必要とする。詳細なタスク記述がなければ、エージェントは作業を重複させ、ギャップを残し、必要な情報を見つけられない）²

そのリストを開いてみましょう。「目的」と「出力フォーマット」は理解しやすいです。スキップされるのは最後のペア——ソースガイダンスとタスク境界です。ソースガイダンスは、サブエージェントに答えをどこで探すべきかを伝えます: 公式の価格ページ、サードパーティの価格比較サイト、または両方で公式ページが優先される。タスク境界は、サブエージェントにこの実行はこのスライスだけをカバーし、それを超えて手を伸ばさないよう伝えます: 現在の価格のみ、過去の価格変更なし。主要な製品ラインのみ、あらゆる不明瞭なサービスをリストしない。この2つを見逃すと、サブエージェントは2つの方法のいずれかに漂う傾向があります。実際に欲しかった情報を見逃すか、または欲しかったよりもはるかに多くを取得し、節約できたツール呼び出しとトークンを消費します。

明確な範囲を持つ自己完結型のタスク記述として書き直すと、クラウドプロバイダー調査はおおよそ次のようになります:

単独で引き出されたこの記述は、サブエージェントがオーケストレーターが内部で議論したことを何も知らずに、「何を調べるか、どこまで進めるか、何を提供するか」を正確に判断できるようにします。

反例: 曖昧な指示はサブエージェントに即興を強いる

範囲と境界を明示しない場合に実際に何が間違うか——公式チームは実践からの実例を示しました: "We started by allowing the lead agent to give simple, short instructions like 'research the semiconductor shortage,' but found these instructions often were vague enough that subagents misinterpreted the task or performed the exact same searches as other agents."（我々は、リードエージェントが「半導体不足を調査する」のような単純で短い指示を与えることから始めたが、これらの指示はしばしば十分に曖昧で、サブエージェントがタスクを誤解したり、他のエージェントとまったく同じ検索を実行したりすることがわかった）²

「半導体不足を調査する」はタスクを渡すように読めますが、何も固定していません——どの時間範囲で？供給側、需要側、または政策の影響に焦点を当てる？どの形式で提供される？同じ曖昧な指示を渡された3つのサブエージェントは、「半導体不足の原因」、最初に思い浮かぶ角度に向かって検索し、結果として3つの大きく重複する調査の塊が生じる可能性が非常に高く、実際にカバーが必要だった角度（例えば、川下産業への影響、または異なる国がどのように対応したか）は手つかずのままになります。これは、レッスン2からの「重複作業」問題のプロンプトレベルでの根源です——サブエージェントが聞かないのではなく、タスク記述自体が境界を引かなかったのです。

1つの問題領域、1つのエージェント

単一のプロンプトを明確に書くことを超えて、複数のサブエージェントが作業をどのように分割するかも、公式の実践から抽出できる原則に従います——公式チームはそれに名前を付けませんでした。この命名は我々のものです: 1つの問題領域、1つのエージェント——各サブエージェントは、1つのサブエージェントが一度にいくつかの無関係なものを扱うのではなく、明確に境界された1つのクラスの問題だけを所有すべきです。

公式システムには直接的な例があります: 彼らは専用のCitationAgentを設定しました。"a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."（CitationAgentは、文書と調査レポートを処理して引用の特定の場所を識別する。これにより、すべての主張がそのソースに適切に帰属される）²。引用がどこに行くかを見つけることは、「ある会社の価格戦略を調査する」とはまったく異なる種類の作業です——前者はチェックと位置特定、後者は検索と判断です。両方を同じサブエージェントに渡すと、それは2つのまったく異なる思考モードの間を行き来しなければならず、そのタスク記述は2つの目的を果たそうとして長く絡み合ったものになり、一方を他方のために軽視しやすくなります。2つの集中したサブエージェントに分割すると、それぞれのタスク記述は単純で明確に境界されたままです——これはレッスン1からの尺度を反映しています: 独立したサブタスクに分割できる場合、分割する価値があります。

まとめ

• サブエージェントはオーケストレーターの会話履歴を見ることができません¹。これは、委任プロンプトが自己完結型でなければならないことを意味します: 単独で読めて、会話の背景から離れても、サブエージェントが何をすべきかを正確に判断するのに十分です。
• 堅実なタスク記述は、目的、出力フォーマット、ソースガイダンス、明確なタスク境界を含まなければなりません。これらがなければ、サブエージェントは作業を重複させ、ギャップを残し、必要な情報を見つけられません²。
• 公式の実世界の反例は、「半導体不足を調査する」のような曖昧な指示がサブエージェントにタスクを誤解させたり、他のサブエージェントとまったく同じ検索を実行させたりすることを証明しています²——範囲と境界はオプションではなく、重複作業を避けるための鍵です。
• 1つの問題領域、1つのエージェント（このレッスンの公式実践の抽出）: 各サブエージェントは、引用の場所を処理する専用のCitationAgentを設定するように、明確に境界された1つのクラスの問題だけを所有すべきであり、異なる性質の作業を異なるサブエージェントに分割します²。そうすることで、各タスク記述は単純で集中したままです。
• 委任プロンプトが十分に良いかどうかを判断するために、テストは単純です: それを単独で引き出して一度読み、サブエージェントがタスクの詳細を埋めるために推測しなければならないかどうかを見てください。

>> レッスン4: コラボレーションパターン: パイプライン、レビュー、投票