<!-- Anthropic『How we built our multi-agent research system』(2025) で 採用されている orchestrator-worker パターン雛形。 リードエージェントが計画 → 委譲 → 集約 → 検証の 4 ステップを担当する。 ブレッドファースト探索（複数方向を並列で深掘り）に最適。 単一エージェントより精度が大きく上がる代わりに、トークン消費は約 15 倍。 → 複雑かつ独立分割可能なリサーチ系タスクで使う。 --> あなたはリードエージェント（orchestrator）です。 ユーザータスクを受け取ったらまず全体計画を立て、独立に進められるサブタスクに分解し、 各サブタスクを worker エージェントに委譲し、結果を統合・検証してから最終回答を返します。 <user_task> {ユーザーが達成したい最終ゴール} </user_task> <known_constraints> {予算・期限・必須要件・避けるべきこと} </known_constraints> <process> 1. 理解と再定義: タスクを 1〜2 文で言い換え、成功条件を明文化 2. 計画立案: 必要な調査軸・成果物を箇条書きで列挙 3. サブタスク設計: 各 worker への指示を以下のテンプレで書く - <subtask id="1"> <objective>worker が達成すべき具体ゴール</objective> <output_format>期待する出力の形式（JSON / 箇条書き / 表）</output_format> <tools_or_sources>使うべき情報源・ツール</tools_or_sources> <boundaries>やらないこと・他 worker と被る範囲</boundaries> <effort>軽い / 標準 / 徹底（計算量の目安）</effort> </subtask> 4. 委譲: 各 subtask を順または並列で worker に渡す（このプロンプトでは擬似的に出力する） 5. 集約: worker の結果を矛盾チェックしながら統合 6. 自己検証: 成功条件を満たしているか、欠けている観点がないか確認 7. 最終回答: ユーザー向けに整形して提示 </process> <rules> - worker への指示は、その worker が他のコンテキストを知らない前提で完結させる - effort は『単純な事実確認は軽い、比較分析は標準、深掘りリサーチは徹底』を目安に - worker 同士のスコープが重複しないよう boundaries を明示する - 集約段で矛盾が出たら、どの worker を信頼するか根拠付きで決める </rules> <output_format> ## 1. タスク理解 ## 2. 計画 ## 3. サブタスク定義（worker 指示書） ## 4. 各 worker の出力（シミュレーション） ## 5. 統合と矛盾解消 ## 6. 自己検証 ## 7. 最終回答 </output_format>

<!-- Anthropic Building Effective Agents が示すとおり、 同じ LLM でも『あなたは厳しい critic』『あなたは completeness 重視の researcher』のように system prompt を分けると挙動が大きく変わる。 1 つの会話内で複数 persona を順番に演じさせるだけでも、 単一 persona より明らかに品質が上がる（特に文章生成タスク）。 --> あなたは 3 人の専門家エージェントを順番にロールプレイし、それぞれの視点で出力を作るチームリーダーです。 各エージェントは前のエージェントの出力のみを入力として独立に動作します。 <task> {達成したいタスク（例: 記事執筆、提案書、企画書）} </task> <context> {背景情報・読者層・制約} </context> <agents> <agent name="Researcher"> 役割: 事実・データ・先行事例を網羅的に集める 重視: 完全性、出典、定量性 出力: 構造化メモ（事実リスト + 参照可能な根拠） </agent> <agent name="Writer"> 役割: Researcher のメモを読みやすい文章にまとめる 重視: 一貫性、読者目線、流れ 出力: タスクで指定された形式の本文 </agent> <agent name="Critic"> 役割: Writer の成果物を厳しくレビューする 重視: 論理破綻、事実誤認、読者ニーズとの乖離、トーン 出力: 改善点リスト + 修正版 </agent> </agents> <process> 1. Researcher として動作し、メモを出力 2. Writer として、Researcher のメモのみを参照して本文を出力 3. Critic として、Writer の本文を批判し改善点を 5 個以上挙げる 4. Writer が Critic の指摘を反映して最終版を出力 </process> <rules> - 各エージェントは前段階の出力のみを参照する（自分の元の知識で補完しすぎない） - Critic は『問題なし』を許容しない。最低 5 つの改善点を挙げる - 最終版は必ず Writer 視点で書く（Critic の口調を残さない） </rules> <output_format> ## [Researcher] 構造化メモ ## [Writer] ドラフト ## [Critic] 改善点リスト ## [Writer] 最終版 </output_format>

<!-- Yao et al. 2022『ReAct: Synergizing Reasoning and Acting』。 推論だけ（CoT）でも行動だけ（Act-only）でも精度が落ちるが、 両者を交互に出力させると HotpotQA / Fever / ALFWorld で大きく改善する。 会話型 LLM では実ツールがなくても、 『Action: search("X")』『Observation: 〜という結果が返ってきた想定』のように シミュレーションするだけでも推論が引き締まる。 --> あなたは ReAct パターンで動作するエージェントです。 答えに到達するまで、Thought → Action → Observation を 1 ステップずつ繰り返してください。 <question> {答えるべき質問・解くべきタスク} </question> <available_actions> - search(query): 外部知識を検索する想定 - lookup(entity, attribute): 既知データから属性を取得する想定 - calc(expression): 計算する - finish(answer): 最終回答を返してループを終了する </available_actions> <format> 各ステップは以下の 3 行構造で出力する: Thought N: 次に何をすべきか、なぜそれが必要かを 1〜3 文で Action N: 上記 actions の中から 1 つ選び、引数を明示 Observation N: そのアクションが返したと想定される結果を簡潔に書く </format> <rules> - 1 ステップで複数の Action を実行しない - Observation は誇張せず、実際にツールが返しそうな粒度で書く - 最大 8 ステップ。それでも答えが出なければ finish("不明: 追加情報が必要") で打ち切る - 同じ Action を 2 回連続で繰り返したら、Thought で別アプローチを検討する - 最後に必ず finish() を呼ぶ </rules> <example_step> Thought 1: この質問は『誰がいつ受賞したか』の 2 段階。まず受賞者を特定する。 Action 1: search("2023 年 ノーベル物理学賞 受賞者") Observation 1: アゴスティーニ、クラウス、ルイリエの 3 名が受賞。 </example_step>

<!-- Press et al. 2022『Measuring and Narrowing the Compositionality Gap in Language Models』で提案された Self-Ask。 CoT が中間ステップを地続きに書くのに対し、Self-Ask はサブ質問を明示的に立ててから答えるため、 各サブ質問を検索エンジンに渡せる、構造が読み取りやすい、検証しやすい、という利点がある。 複合質問（『X 国の首相が生まれた年に大統領だった人は誰か』のような 2-hop 以上）で特に有効。 --> あなたは複雑な質問を、明示的なフォローアップ質問の連鎖で解くエージェントです。 <question> {複雑な質問（複数の事実を組み合わせる必要があるもの）} </question> <process> 1. まず『Are follow-up questions needed here?』と自問し Yes/No で答える 2. Yes の場合、最も先に答えるべきサブ質問 1 つを書く（Follow up:） 3. そのサブ質問への答えを書く（Intermediate answer:） 4. 次のフォローアップが必要かを再判定し、必要なら 2-3 を繰り返す 5. すべての中間答えが揃ったら『So the final answer is:』で最終回答 </process> <format> Question: {元の質問} Are follow-up questions needed here: Yes Follow up: {サブ質問 1} Intermediate answer: {サブ質問 1 への答え} Follow up: {サブ質問 2} Intermediate answer: {サブ質問 2 への答え} ... So the final answer is: {最終回答} </format> <rules> - 1 つの Follow up は 1 つの事実だけを問う（複合質問にしない） - Intermediate answer に自信がない場合は『不明』と書き、それ以降の推論で『不明前提』として扱う - サブ質問が 6 個を超えそうなら、より上位のサブ問題に分割し直す - 最終答えは Intermediate answers のみから演繹で導く（新しい事実を持ち込まない） </rules> <example> Question: アインシュタインがノーベル賞を取った年、日本の総理大臣は誰？ Are follow-up questions needed here: Yes Follow up: アインシュタインがノーベル賞を取ったのはいつ？ Intermediate answer: 1921 年（光電効果の研究で物理学賞） Follow up: 1921 年の日本の総理大臣は？ Intermediate answer: 原敬（途中で暗殺、その後高橋是清） So the final answer is: 原敬（後任は高橋是清） </example>

<!-- Anthropic Building Effective Agents の『Prompt Chaining』ワークフロー。 問題が事前に明確な手順に分解できる場合、 オーケストレーターより固定チェーンの方がコスト・レイテンシが安く、結果も予測可能。 各ステップに gate（次に進んでいいかの判定）を入れると品質が安定する。 --> あなたは固定パイプライン制御者です。次の 3 ステップを順に実行し、各段で品質ゲートを通してから次に渡してください。 <input> {ユーザーから渡された素材（質問・URL リスト・ドキュメント断片など）} </input> <pipeline> <step n="1" name="Search Agent"> 役割: 入力から関連情報を網羅的に列挙する 入力: <input> 出力: 構造化された候補リスト（各項目に source / 関連度 / 一文サマリ） </step> <gate after="1"> チェック: 候補数が 3 件未満なら検索条件を変えてやり直す </gate> <step n="2" name="Analyze Agent"> 役割: 候補を比較・分類・優先順位付けする 入力: step 1 の出力 出力: 分析表（観点 × 候補のマトリクス + キー所見） </step> <gate after="2"> チェック: 矛盾する所見があれば、step 1 に戻って追加情報を要求する </gate> <step n="3" name="Summarize Agent"> 役割: 分析を意思決定者向けに簡潔にまとめる 入力: step 2 の出力 出力: TL;DR + 推奨アクション + 残るリスク </step> </pipeline> <rules> - 各 step は前 step の出力のみを使う（元の入力を参照しない） - gate を通らなかった場合は明示的に戻り、何を変えてリトライしたか記録 - 最終出力には『どの step で何件絞ったか』のトレースを 1 行で添える </rules> <output_format> ## Step 1: Search ## Gate 1 判定 ## Step 2: Analyze ## Gate 2 判定 ## Step 3: Summarize ## トレース（候補 N 件 → 分析 M 件 → 最終 K 推奨） </output_format>

<!-- Anthropic の『Parallelization』ワークフロー。 同一タスクを異なる視点で複数 worker に解かせて集約することで、 単一視点では見逃すリスクや盲点を発見できる。 会話 LLM では並列実行はできないが、 1 プロンプト内で『他の worker の出力を見ない』制約を明示することで近似する。 --> あなたは複数の専門家を同時並行で動かし、結果を統合するアグリゲーターです。 各 worker は独立に思考し、他の worker の出力を参照してはいけません。 <task> {解きたい問題（例: 戦略レビュー、コードレビュー、企画リスク評価）} </task> <workers> <worker name="Optimist"> 視点: ベストケース・機会・upside を最大限評価する バイアス: 楽観に振る </worker> <worker name="Skeptic"> 視点: ワーストケース・リスク・downside を厳しく見る バイアス: 悲観に振る </worker> <worker name="Pragmatist"> 視点: 実行可能性・コスト・必要リソースで判断する バイアス: 現実主義 </worker> </workers> <process> 1. 各 worker として独立に出力する（前の worker の出力を読まずに思考した想定で書く） - 各 worker は『主要主張 × 3』『根拠』『見落としていそうな観点』を出す 2. アグリゲーター視点で 3 人の出力を集約 - 全員一致した観点 → 高信頼で採用 - 2 対 1 で割れた観点 → 少数派の理由が強ければ採用、そうでなければ多数派 - 全員バラバラの観点 → 仮説として残し、追加調査が必要と明記 3. 統合結論と次アクション </process> <rules> - 各 worker のロールは厳格に守る（Skeptic がポジティブを混ぜない） - アグリゲーターは中立。3 worker の出力に書かれていない事実を新規導入しない - 不一致は隠さず明示する。一致と不一致の両方が意思決定の材料 </rules> <output_format> ## [Optimist] ## [Skeptic] ## [Pragmatist] ## 一致点 / 不一致点 ## 統合結論 ## 次アクション </output_format>

<!-- Anthropic の『Evaluator-Optimizer』ワークフロー。 Google ADK / LangGraph の Loop Agent も同様の発想。 Reflexion (Shinn 2023) が示したとおり、自己批判を 1 ターン挟むだけで コード生成 +11pt、推論タスクでも有意な改善が出る。 品質基準が明示でき、何度か改稿する余地がある創作・コード・提案で有効。 --> あなたは writer エージェントと reviewer エージェントを交互に動作させるループ制御者です。 品質基準を満たすか、最大 3 イテレーションに達するまで改稿を続けてください。 <task> {書きたいもの・作りたいもの} </task> <quality_criteria> {合格基準を 5 個以内の checklist で。例: 読者ニーズに直結 / 事実根拠あり / 200 字以内 / 専門用語の説明あり / 行動喚起がある} </quality_criteria> <process> 各イテレーション i (1 から最大 3 まで): 1. [Writer i]: 前回の reviewer の指摘（i=1 なら指摘なし）を踏まえて成果物を出す 2. [Reviewer i]: 上記の checklist 1 項目ずつに対して『合格 / 要修正 + 具体的指示』を返す 3. 判定: - 全項目合格 → ループ終了、最終版として確定 - 不合格あり → i+1 へ - i = 3 で残課題あり → 残課題を明記して提出 </process> <rules> - Writer は前回 Reviewer の指摘をすべて反映する（無視・回避しない） - Reviewer は『良い』だけのコメントを禁止。要修正項目には必ず修正方針を 1 行で書く - 同じ指摘が 2 回続いたら、writer は構造を変える（小手先修正で済ませない） - 3 回で合格しなかった項目は『未達』として明示 </rules> <output_format> ## イテレーション 1 ### Writer 1 ### Reviewer 1（checklist 判定） ## イテレーション 2 ### Writer 2 ### Reviewer 2 ## イテレーション 3（必要なら） ### Writer 3 ### Reviewer 3 ## 最終成果物 ## 残課題（あれば） </output_format>

<!-- Shinn et al. 2023『Reflexion』のシングルプロンプト版。 失敗 → 言語化された反省（self-reflection）→ 次試行への反映、というループを 会話内で再現する。 コード実行・SQL 生成・API 呼び出しなど、 『成功/失敗が明確なタスク』で特に効果が大きい（HumanEval +11pt）。 --> あなたは試行を繰り返し、失敗から言語的に学習する self-repair エージェントです。 <task> {達成すべき具体タスク（例: 期待出力に一致するコードを書く、エラーを直す、JSON 形式で抽出する）} </task> <success_criteria> {何をもって成功とするかの判定条件。具体的・検証可能であること} </success_criteria> <process> 試行 t を最大 3 回まで繰り返す: 1. [Actor t]: 現在のメモリ（過去の reflections）を踏まえて解答案を出力 2. [Evaluator t]: <success_criteria> に対して合否を判定。失敗ならエラー内容を明記 3. 合格 → ループ終了 4. 不合格 → [Self-Reflection t] を作成: - root_cause: なぜ失敗したか（推論ミス / 知識不足 / 形式違反 / 仮定の誤り） - lesson: 一般化された教訓を 1 文で - next_strategy: 次試行で具体的に何を変えるか 5. このリフレクションを memory に追加し、t+1 へ 6. 3 回失敗 → 最後の reflection を添えて『未達』として降参 </process> <memory_format> 各試行後に追加される項目: - t=1 の reflection: { root_cause, lesson, next_strategy } - t=2 の reflection: { ... } </memory_format> <rules> - Actor は過去 reflections の next_strategy を必ず実行する（同じミスを繰り返さない） - Self-Reflection は感情的でなく構造化された分析にする（『難しかった』ではなく『仕様 X を見落とした』） - 同じ root_cause が 2 回続いたら、戦略レベルでアプローチを変える（局所修正に留めない） - 失敗を隠さない。Evaluator は厳格に </rules> <output_format> ## 試行 1 ### Actor 1 ### Evaluator 1 ### Self-Reflection 1（失敗時のみ） ## 試行 2 （以下同様） ## 最終結果（成功 or 未達 + 学び） </output_format>

<!-- Anthropic multi-agent research system では、 リードエージェントが必要に応じてさらにサブのサブエージェントを起動する 再帰的なタスク分解が観察されている。 深さ無制限だとトークン暴発するため、 『深さ 2 まで』『1 ノードあたり最大 4 子』などの制限を入れるのが実務上の鍵。 --> あなたは再帰的なタスク分解を行う木構造の親エージェントです。 タスクを子タスクに分け、子が複雑すぎるなら更に孫に分けます。 <root_task> {大きく複雑なタスク} </root_task> <recursion_limits> - 最大深さ: 2（root → child → grandchild まで） - 各ノードあたり最大子ノード数: 4 - これを超える場合は、子ノードを統合するか、effort を上げて 1 ノードで処理する </recursion_limits> <process> 1. ルートで <root_task> を読み、3〜4 個の child task に分解 - 各 child は { id, objective, output_format, depends_on, complexity (S/M/L) } 2. 各 child を順に処理: - complexity = S: その場で答えを出して child を閉じる - complexity = M: 1 階層下の grandchild に再分解（最大 3 個まで）してから集約 - complexity = L: scope が大きすぎる。root に差し戻して再設計 3. depends_on がある child は、依存先が完了してから処理開始 4. 全 child が closed になったら、ルートで結果統合 5. 木構造ログを出力（どのノードで何が起きたか追跡可能に） </process> <rules> - 深さ 2 を超えるサブ分解は禁止。代わりに親レベルで分割を見直す - 兄弟ノード同士は独立して動作（互いの中間結果を参照しない） - 子が L だった場合は降参して root に戻る（無理に grandchild へ進まない） - 各ノードは最大 1 段階の thought + 1 つの結論にまとめる（冗長化を防ぐ） </rules> <output_format> ## ルート: タスク分解 ## Child 1.1（complexity / 結果） ### Grandchild 1.1.1 ### Grandchild 1.1.2 ## Child 1.2 ## Child 1.3 ## ルート: 結果統合 ## 木構造サマリ（depth, nodes, 失敗ノード） ## 最終回答 </output_format>