レッスン4：プランニングとエージェントパターン——ReAct・Plan-and-Execute・Reflection

このレッスンで学ぶこと

ReAct（Yao et al. 2022）の Thought → Action → Observation ループを理解する
Plan-and-Execute パターンを ReAct と区別できる
Reflection／Self-correction（Shinn et al. 2023 ほか）の発想を押さえる
3 つのパターンの使い分け軸を持つ
reasoning モデル時代のプランニングを整理する
暴走を防ぐ設計上の上限と打ち切り条件を組み込める

前のレッスンでは、エージェントが外部世界と接続する Function Calling・JSON Schema・MCP の仕組みを学びました。本レッスンは、そのツール群を「いつ・どの順序で・どう呼ぶか」を決めるプランニングの中核——ReAct・Plan-and-Execute・Reflection という代表的なパターンを扱います。

3 つのパターンの位置づけ

エージェントが複数ステップで動くとき、思考と行動の順序をどう設計するかで、いくつかの代表的なパターンが知られています。

パターン	中核の発想	出典の代表例
ReAct	Thought → Action → Observation を 1 ステップずつ繰り返す	Yao et al. 2022 「ReAct」
Plan-and-Execute	最初に全体計画を立て、計画通りに順に実行する	LangChain などの実装で広まったパターン
Reflection	行動の結果を振り返り、自分の判断を修正する	Shinn et al. 2023 「Reflexion」、Madaan et al. 2023 「Self-Refine」

それぞれを順に見ていきます。

ReAct——「考えながら動く」ループ

ReAct（Reasoning + Acting）は、2022 年に Yao 氏らが論文「ReAct: Synergizing Reasoning and Acting in Language Models」で提唱したパターンです。エージェント設計の代表的な古典として、いまも広く参照されます。

基本ループ

flowchart LR
  T[Thought<br/>思考] --> A[Action<br/>行動]
  A --> O[Observation<br/>結果観察]
  O --> T

Thought：「現状を踏まえて、次に何をすべきか」を LLM が言語化する
Action：思考の結論として、ツールを 1 つ選んで呼び出す
Observation：ツール実行の結果を読み取る
1 に戻る

例：旅行プラン作成エージェント

Thought：「東京の人気観光地を調べる必要がある」
Action：search_web("東京観光地")
Observation：「上位 10 件の観光地リストが返ってきた」
Thought：「次に各観光地の営業時間を調べる」
Action：search_web("浅草寺営業時間")
Observation：「24 時間境内自由、本堂は 6:00〜17:00」
Thought：「次に〜」（以下繰り返し）

ReAct の強み

柔軟性：各ステップで観察結果に応じて動的に判断できる
デバッグしやすさ：Thought がテキストで残るため、なぜその行動を取ったかを追跡できる
シンプル：実装が比較的容易

ReAct の弱み

全体最適にならない：1 ステップずつ判断するため、長期的に効率が悪い経路を選ぶことがある
無限ループ：「これで十分」と判断できず、同じツールを繰り返し呼ぶことがある
トークン消費：Thought を毎ステップ生成するため、コストが膨らむ

💡 ポイント ReAct は「最も基本的なエージェントパターン」として広く知られていますが、必ずしもすべてのユースケースで最適ではありません。タスクが定型的なら Plan-and-Execute、自己修正が重要なら Reflection、というように、ユースケースに合わせて使い分けます。

Plan-and-Execute——「最初に計画、あとは実行」

Plan-and-Execute は、最初に全体計画を立て、計画通りに順に実行するパターンです。LangChain の実装で広く知られるようになりました。

基本フロー

flowchart TD
  G[ゴール受け取り] --> P[Plan<br/>全体計画立案]
  P --> E1[ステップ 1 実行]
  E1 --> E2[ステップ 2 実行]
  E2 --> E3[ステップ 3 実行]
  E3 --> F[最終出力]

Plan：ゴールを受け取り、全体を解決する複数ステップの計画を立てる
Execute：計画されたステップを順に実行する
必要に応じて、各ステップの結果に応じて計画を見直す（Hybrid）

例：データレポート作成エージェント

Plan：
1. 売上 DB から先月のデータを取得
2. 業界別に集計
3. 前年同月と比較
4. グラフ生成
5. Markdown レポート出力
Execute：上記を順に実行

Plan-and-Execute の強み

全体最適：最初に俯瞰してから動くため、無駄なステップが減る
コスト効率：reasoning は最初の計画段階のみ。実行はシンプルなツール呼び出し
進捗が見える：「いま全体のうち何ステップ目」がわかるため、人間がモニタリングしやすい

Plan-and-Execute の弱み

環境変化に弱い：計画立案時の想定と実環境がずれていると、途中で破綻する
計画の質に依存：最初の計画が悪いと全体が崩れる
柔軟性が低い：途中で計画変更すると複雑になる

📝 補足 実務では純粋な Plan-and-Execute より、「Plan で大枠を立て、各 Execute ステップで局所的に判断」のハイブリッド設計が多く採用されています。reasoning モデルが計画段階を担当することで、品質が安定するようになりました。

Reflection——「振り返って自己修正」

Reflection は、行動の結果を振り返り、自分の判断を修正していくパターンです。代表的な論文として、Shinn 氏らの「Reflexion」（2023）と、Madaan 氏らの「Self-Refine」（2023）があります。

基本フロー

flowchart LR
  A[行動] --> O[結果観察]
  O --> R[Reflection<br/>振り返り]
  R --> A

エージェントが行動を実行
結果を観察
「いまの結果は満足できるか？できないなら何を変えるべきか？」を自問する（Reflection）
修正された判断で次の行動

例：コード生成エージェント

Action：「ユーザー要求に応じて Python コードを生成」
Observation：「コードを実行したら、エラーで止まった」
Reflection：「エラーメッセージは、型変換ミスを示している。修正案として int(x) を str(x) に変える」
Action：「修正したコードを生成」
続行

Reflection の強み

失敗からの学習：誤りに気づいて修正できる
品質向上：1 発で正解を出すより、複数回の反復で精度が上がる
複雑な問題への対応：1 回の Thought では捉えきれない問題に強い

Reflection の弱み

コスト・遅延の増加：反復回数が増えるとトークンとレイテンシが膨らむ
無限改善ループ：「もっと良くできる」と判断し続けて停止しないリスク
改善判断の難しさ：本当に改善されたかを評価する基準が必要

⚠️ 注意 Reflection は強力ですが、「いつ満足とするか」の停止条件を設計しないと、無限ループに陥ります。「3 回反復で打ち切る」「品質スコアが閾値を超えたら停止」など、明示的な打ち切り基準が必須です。

3 つのパターンの使い分け

特性	ReAct	Plan-and-Execute	Reflection
柔軟性	高	中	高
全体最適	低	高	中
デバッグしやすさ	高	中	中
コスト効率	低	高	低
環境変化への強さ	高	低	中
自己修正	弱	弱	強

使い分けの目安

動的な探索タスク（Web 調査、未知ドメインの問題解決）：ReAct
定型的な複数ステップ業務（レポート作成、データ集計）：Plan-and-Execute
品質改善が重要なタスク（コード生成、文書校正）：Reflection を組み込む
複雑な業務エージェント：Plan-and-Execute＋各ステップで局所的 ReAct＋必要時に Reflection、というハイブリッド

ハイブリッドが現実解

実務では純粋なパターンを使うことは少なく、3 つを組み合わせるハイブリッド設計が一般的です。

Plan-and-Execute で大枠を立てる（reasoning モデルで計画）
各 Execute ステップ内では ReAct ループで局所判断（軽量モデルで実行）
重要な結果には Reflection を 1〜2 回挟む（品質保証）

💡 ポイント 「ReAct か Plan-and-Execute か Reflection か」を二者択一で考えるより、「どこに reasoning モデルを置き、どこで Reflection を挟み、どこは ReAct で動的判断するか」という設計判断として捉える方が、現実的です。

reasoning モデル時代のプランニング

reasoning モデル（Claude Extended Thinking、OpenAI の o シリーズ、Gemini Thinking）の登場は、プランニング設計を大きく変えました。

従来モデル＋外部 CoT

以前は、エージェントが「step by step で考えて、次の行動を決めて」と LLM に明示的に思考を促していました。ReAct のような外部 CoT が必要だったのです。

reasoning モデルの内部思考

reasoning モデルは、入力を受け取った後、内部で思考プロセスを実行してから出力します。プランニング段階で「step by step」を強制する必要性が下がりました。

設計上の含意

プランニング段階のみ reasoning モデル、実行段階は軽量モデル、というハイブリッド設計が広まった
ReAct の「Thought」を明示的に書く意義は下がるが、デバッグのためにあえて残す設計も多い
Reflection の品質が、reasoning モデルで安定するようになった

📝 補足 reasoning モデルは強力ですが、すべての場面で必要というわけではありません。単純な定型処理に reasoning モデルを使うとコストが過剰になります。「複雑な判断が必要な箇所のみ reasoning」を意識した使い分けが大切です。

暴走を防ぐ設計

エージェントは、設計が雑だと「無限ループ」「想定外のコスト」「同じツールを繰り返し呼ぶ」などの暴走を起こします。

上限を設定する

最大ステップ数：1 タスクで実行できる最大ループ回数（例：20 ステップ）
最大トークン数：1 タスクで消費できる総トークン量
最大時間：1 タスクで使える最大実行時間
最大コスト：1 タスクで使える API コスト

これらの上限を超えたら、エージェントを強制的に停止し、人間に通知する仕組みを必ず組み込みます。

重複検知

同じツールを同じ引数で 3 回以上呼んだら、無限ループと判定して停止
Thought の内容が前回と酷似しているなら、進捗していないサインとして警告

終了条件の明示

「ゴール達成」の判定基準を、最初に LLM に伝える
Plan-and-Execute なら「全ステップ完了」、ReAct なら「最終結論に到達」など、終わり方を明示

⚠️ 注意 エージェントの暴走は、開発初期に最も多く発生する事故です。最大ステップ数・最大コスト・重複検知を「実装の最初」に組み込むのが、後から追加するよりずっと楽です。本コースのスタンスとして、暴走対策はオプションではなく必須機能です。

講師の現場メモ：「無限改善ループでクラウド請求書が 8 万円になった話」

私（高梨）が AI スタートアップで CTO だった頃の話です。社内プロジェクトとして「マーケティング文章のコピー作成エージェント」を試作していました。社内コピーライターの作業を補助する目的で、Reflection パターンを採用したのです。

仕組みはシンプルでした：

エージェントが商品の説明から広告文を 1 案生成
「もっと魅力的にできるか？」と Reflection を呼ぶ
Reflection が改善案を出したら、それを元に新しい広告文を生成
2〜3 に戻る

私たちは「品質が頭打ちになれば自然に止まるだろう」と楽観視していました。停止条件は「Reflection が『改善不要』と判断したら終了」だけでした。

ある金曜日の夕方、検証スクリプトを動かして帰宅しました。月曜の朝、出社して Slack を確認すると、コスト監視チームから通知が来ていました。「クラウドの LLM API 料金が、土日で 8 万円増加しています」。

調査してみると、Reflection がほぼ毎回「もう一歩改善できる」と判断し続け、無限ループに入っていたのです。「もっと魅力的に」「もっと簡潔に」「もっと感情的に」と、改善方向を変えながら同じ広告文を 1 万回以上生成していました。3 日間止まらなかったのです。

私はその場で 3 つの対策を入れました：

最大反復回数：Reflection は最大 3 回まで
品質スコアの定量化：LLM-as-a-Judge で 1〜5 のスコアを付け、4 以上なら停止
コスト上限アラート：1 タスクが 100 円を超えたら自動停止し、Slack 通知

3 つを組み合わせた結果、暴走は起きなくなりました。同時に、品質も上がりました。「3 回まで」と縛ったことで、各反復の質を高める設計に変わったからです。

このときに学んだのが、エージェントの設計で「暴走対策」は装飾ではなく前提条件だということです。本コースで繰り返し「最大ステップ数」「コスト上限」「重複検知」を強調するのは、この 8 万円の請求書の記憶があるからです。

まとめ

このレッスンでは、以下のことを学びました。

ReAct（Thought → Action → Observation ループ）は柔軟で動的な探索に強い
Plan-and-Execute（最初に全体計画、順次実行）は定型業務とコスト効率に強い
Reflection／Self-correction（振り返って自己修正）は品質改善に強い
3 つは対立せず、ハイブリッドで組み合わせるのが現実的
reasoning モデル時代は「プランニングは reasoning、実行は軽量モデル」のハイブリッドが主流
暴走対策（最大ステップ数・最大コスト・重複検知・終了条件）は装飾ではなく必須機能

次のレッスンでは、エージェントが過去の文脈を保持し参照する記憶——短期・長期・エピソード記憶とコンテキスト管理——を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。