最小チームはこれ：Plan / Execute / Review の3ロール設計

マルチエージェントの「最小にして最強」の構成、それが Plan / Execute / Review の3ロール設計です。 役割を無秩序に増やすのではなく、「計画する人」「実行する人」「評価する人」の3つに絞ることで、AIエージェントの出力品質を飛躍的に向上させます。本記事では、すぐに試せる役割カード（テンプレート）と、同一タスクでの単体 vs 3ロール比較実演で、この設計の威力を体感してください。

この記事の前提と使い方

本記事は、AIエージェントの4設計要素（TMPE）を前提知識とします。4要素のうち特にP（計画/推論ループ）とE（自己評価/軌道修正）を、マルチエージェント構成としてどう実装するかが本記事のテーマです。

使い方: まずセクション1の役割カードをそのままコピーして試してください。次にセクション2の実演ログで「単体との差」を確認し、セクション3以降で理論背景と適用判断の基準を理解してください。

1. コピペで使える3ロール役割カード

マルチエージェントシステムの各エージェントは、人間の組織における職務記述書（Job Description）のように、厳格に定義された「役割カード」で統制する必要があります。以下の3つの役割カードは、「目的」「入力」「出力形式」「禁止事項」の4要素で構成されています。

1-1. Planner（計画役）の役割カード

Plannerの存在理由は、ユーザーの曖昧な目標を、実行可能なサブタスクの集合に分解することです。Planner自身は決して実作業を行わず、戦略的ディレクションに専念します。

1-2. Executor（実行役）の役割カード

Executorは、Plannerの計画に忠実に従い、ツールを駆動して具体的な成果物を生成する労働力です。

1-3. Reviewer（評価・修正役）の役割カード

Reviewerは、システムの品質を担保する防波堤です。Executorの出力を冷徹に採点し、基準を満たさない場合は具体的な修正指示とともに差し戻します。

2. 実演：同一タスクで「単体 vs 3ロール」を比較する

アーキテクチャの優位性を証明するため、同じ複雑なタスクに対する「単体プロンプト」と「3ロール設計」の挙動を比較します。

タスク要件

「次世代全固体電池の市場動向に関する技術レポートを作成せよ。以下の制約を厳守すること。①2024年以降の最新データのみを使用 ②主要3社（トヨタ、サムスンSDI、QuantumScape）の技術比較表を含める ③全体で800文字以内 ④専門用語（デンドライト、硫化物系等）には初出時に注釈を付与」

4つの制約が課された、典型的な「制約の同時充足」が求められるタスクです。

2-1. 単体プロンプトの挙動 — 制約が"忘れられる"

単一のエージェントにこのタスクを投入すると、初期段階ではタスクの意図を正確に把握します。しかし、情報の検索と要約を繰り返すうちに、コンテキストウィンドウの消費が進み、プロンプトの忠実度（Prompt Fidelity）が急速に低下していきます。

なぜこうなるのか？ 単一エージェントは、情報の検索と統合に認知リソース（Attention）を集中させた結果、プロンプト末尾に記述された文字数制限や注釈ルールを忘却します。そして最大の問題は、自分自身の出力を客観的に振り返るメカニズムがないため、制約違反に気づくことなくタスクを完了状態としてしまうことです。

2-2. 3ロールの挙動 — Reviewが"漏れ"を捕まえる

同一タスクを3ロールアーキテクチャに投入すると、システム内部で以下の厳密な状態遷移と自己修正ループが展開されます。

ステップ1: Plannerがタスクを分解

Plannerは目標を分析し、3つのステップに分解した実行計画を生成します。

特筆すべきは、ハンドオフ・ドキュメントを通じて「落とし穴の予測」が事前に共有される点です。

ステップ2: Executorがドラフトを生成（ミスも起きる）

Executorは指定されたツールでデータを収集し、ドラフトを生成します。しかし、情報の密度が高まった結果、文字数が950文字に膨張し、「硫化物系」の注釈を忘却しました。単体エージェントとまったく同じミスです。

ここが決定的に異なるポイントです — 単体エージェントならこのまま完了してしまうのに対し、3ロール設計ではReviewerが介入します。

ステップ3: Reviewerが冷徹に差し戻す

Reviewerは成果物を読み込み、評価ルーブリックと要件リストを照合します。一切の称賛を交えず、欠陥を具体的に指摘します。

1. 第2段落の市場規模に関する歴史的背景の記述を完全に削除し、文字数を800文字以内に圧縮せよ
2. 第3段落の「硫化物系」の直後に短い注釈を追記せよ

ステップ4: Executorが修正し、REVIEWをPASS

REJECTと具体的なフィードバックを受け取ったExecutorは、新規の検索を行うことなく、フィードバックにのみ基づいてドラフトを編集します。第2段落を大幅に削減し、注釈を追記した新バージョン（760文字）を再提出。Reviewerが再度採点し、すべての基準が満たされたことを確認してPASSを出します。

2-3. 比較結果：制約遵守能力の差

単体プロンプトでは不可避だった「要件の取りこぼし」が、内部の監査ループによって完全に補正されたことが実証されました。

3. なぜ3ロールが「最小にして最強」なのか — 理論的背景

3ロール設計の高い性能は偶然ではなく、AIエージェント設計の歴史的な進化の中で洗練されてきたアーキテクチャの結晶です。

3-1. ReActの限界：一人で全部やると破綻する

自律型エージェントの初期標準であったReAct（Reasoning and Acting）は、LLMに「思考→行動→観察」のループを繰り返させる手法です。しかし、タスクが複雑化すると致命的な限界を露呈しました。

この課題を克服するために設計されたのが「Plan-and-Execute」アーキテクチャ — 推論を「高次元の戦略立案（Planner）」と「低次元の戦術実行（Executor）」に分離する設計です。

3-2. Reflexion：失敗から学ぶ自己修正メカニズム

計画と実行の分離は効率性を高めますが、それだけでは「実行の失敗」や「環境の変化」に対応できません。そこで導入されたのが、Reflexion（リフレクション） — エージェントが過去の失敗から「言語的なフィードバック」を生成し、次の意思決定を改善する手法です。

3-3. 思考の退化 — 自分で自分を評価する限界

しかし、「自分で計画し、自分で実行し、自分で評価する」アプローチには、人間の確証バイアスに似た構造的欠陥があります。研究者たちはこれを「思考の退化（Degeneration-of-Thought）」と呼んでいます。

思考の退化とは: エージェントが自身の誤った初期推論に固執し、明らかな失敗にもかかわらず、その失敗を正当化する誤った反省を生成して、反復ごとに同じミスを繰り返す現象

この問題を防ぐ唯一にして最大の解決策が、Reviewerを完全に独立したペルソナとして分離することです。自己評価ではなく、独立した評価者による外部からの批判的視点を導入することで、エージェントは論理的盲点に気づけるようになります。

3-4. ハンドオフの落とし穴 — 情報の圧縮イベント

3ロール設計を成功させる上で、最大の罠がエージェント間のハンドオフ（引き継ぎ）に潜んでいます。

セクション1の役割カードに「ハンドオフ・ドキュメント」を明示的に含めているのは、この圧縮イベントの問題を構造的に防ぐためです。

4. 3ロール設計が効く領域・効かない領域

いかに優れたアーキテクチャでも、すべてのタスクに適用すべきではありません。タスクの性質と複雑さに基づく適用境界を正確に見極めることが重要です。

4-1. 3ロール設計が劇的に効く領域

4-2. 3ロール設計が不適合（逆効果）な領域

4-3. 適用判断フローチャート

4-4. 総合比較

5. Reviewer の品質を最大化する設計

3ロール設計の全体的な性能は、Reviewerの評価品質に完全に依存しています。Reviewerが曖昧なフィードバックを返したり、誤った批判をしたりすれば、システム全体が「改悪のループ」に突入します。

5-1. 分析的ルーブリック（採点基準）のハードコード

Reviewerを正確に機能させる第一歩は、自由記述の評価を禁止し、多次元的な「ルーブリック（採点基準表）」をあらかじめ定義しておくことです。

5-2. 評価根拠（Rationale）の強制

Reviewerにスコアだけを出力させる設計は避けるべきです。「なぜそのスコアか」の推論プロセスを記述させることで、評価の信頼性と一貫性が劇的に向上します。

さらに高度な手法として「直交的検証」ツールの導入があります。LLMは言語パターンの評価には優れていますが、数学的正確性やコードの動作保証には限界があります。そこで、Reviewerに対してテスト実行環境やファクトチェック用の検索ツールへのアクセス権を付与します。これにより、Reviewerは自らの「言語的な確率」ではなく、客観的な実行結果に基づいた反論の余地のない批判をExecutorに突きつけることができます。

5-3. 役割境界の維持 — 「禁止事項」が最重要

Reviewerのプロンプトで最も重要なのが禁止事項です。特に注意すべき2つの罠があります。

よくある質問

Q1. 3ロール設計はどんなツール/フレームワークで実装できる？

LangGraph、CrewAI、AutoGen、Dify、Amazon Bedrockなど、主要なエージェントフレームワークの大半が3ロール構成をサポートしています。フレームワークを使わなくても、3つのLLM呼び出しをステートマシンで繋ぐだけで基本的な実装は可能です。

Q2. 3つのロールすべてに高性能モデルが必要？

いいえ。PlannerとReviewerには高い推論能力が求められますが、Executorにはドメイン特化型の小型モデルや安価なモデルを割り当てることで、コストと速度を大幅に最適化できます。これがPlan-and-Executeアーキテクチャの大きなメリットの一つです。

Q3. Reviewerの修正ループは何回まで？

一般的には最大3回を推奨します。3回以内にPASSしない場合、タスクの定義自体に問題がある可能性が高く、Plannerの再計画フェーズに戻すか、人間の介入を要求すべきです。無制限のループは無限ループ障害（F04）の原因になります。

Q4. 単体プロンプトから3ロールへの移行は段階的にできる？

はい。まず単体プロンプトに「Reviewer」だけを追加する2ロール構成（Execute + Review）から始めるのが効果的です。これだけでも制約遵守能力が大幅に向上します。効果を確認した上でPlannerを分離し、3ロールに拡張してください。

Q5. 4ロール以上に拡張すべきケースは？

大規模で複雑なプロジェクト（例: フルスタック開発、大規模リサーチ）では、Executorをドメイン別に複数化する（例: フロントエンド担当、バックエンド担当）ことがあります。ただし、PlannerとReviewerは原則として各1つに保つのがベストプラクティスです。役割を増やしすぎるとエージェント間の通信オーバーヘッドが指数関数的に増大します。

まとめ

LLMを活用した自律型エージェント設計において、Plan（計画）/ Execute（実行）/ Review（評価・修正）の3ロールは、複雑なタスクを処理するための最も合理的で強力な最小単位です。

1. Planner: 曖昧な目標をサブタスクに分解し、ハンドオフ・ドキュメントで落とし穴を予告する
2. Executor: 計画に忠実に従い、ツールを駆動して成果物を生成する
3. Reviewer: 評価ルーブリックで冷徹に採点し、基準未達なら具体的な修正指示で差し戻す

この3つの職務の厳密な分離により、各エージェントは自身の目的にのみ集中でき、システム全体の制約遵守能力と出力品質が飛躍的に向上します。エラーはユーザーに到達する前にシステム内部で自己浄化されます。

本記事は、AIエージェント設計30記事シリーズの第4回です。関連する記事で各要素をさらに深掘りしています。

• 基礎定義 → AIエージェントとは何か：4設計要素
• 失敗パターン → エージェントが壊れる10パターン
• メモリ設計 → 短期・長期・外部メモリの設計パターン
• 人間監督 → Human-in-the-Loop設計
• 可視化 → オブザーバビリティダッシュボード設計
• 評価 → エージェント評価KPI設計

この記事の著者

Agentic Base 編集部

AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。