推論と計画 ─ Extended Thinking と Orchestrator-Worker
エージェントの上から 1 層目、推論・計画レイヤは「LLM をどう使って計画を立てさせ、その計画を再計画しながら完遂させるか」を扱う層だ。デモで派手に動くエージェントの裏には、ほぼ例外なくこの層の工夫がある。本章では、業務に投入できる推論・計画レイヤを設計するための 5 つの軸を順に見ていく。
軸 1：Extended Thinking と「考えるブロック」を保持する作法
2025-2026 で最も実装が変わったのがここだ。Anthropic の Extended Thinking、OpenAI の reasoning model、Gemini の thinking など、主要モデルが「回答前に内部で逐次的に推論する」機能を出した。Claude API の場合は thinking ブロック + text ブロックの形でレスポンスが返る。
Opus 4.6 以降の Anthropic は Adaptive Thinking を推奨している。effort パラメータで low / medium / high / xhigh を選ぶと、内部の推論長を可変できる。ツール使用と組み合わせる時の制約は次の通り。
- ツール呼び出し時は
tool_choice: autoまたはnoneのみ（requiredなどは併用不可） - ツール結果を返す次ターンの assistant content には、thinking ブロックをそのまま含めて戻す
この 2 つ目が業務投入では特に重要だ。
# ❌ 悪い例：thinking ブロックを捨ててしまう
response = client.messages.create(...)
# 次ターンに渡すとき、text だけ拾って thinking を捨てる
next_messages = [..., {"role": "assistant", "content": [text_block_only]}]
# → API が暗黙に thinking を無効化し、再計画品質が崩れる
# ✅ 良い例：thinking ブロックも含めて全部戻す
next_messages = [..., {"role": "assistant", "content": response.content}]
# response.content には thinking + text 両方が入っているさらに Interleaved Thinking がツール呼び出しの間に思考を挟める。Claude Opus 4.7 では自動、それ以前は interleaved-thinking-2025-05-14 ベータヘッダで有効化する。長時間のエージェントがツール結果を踏まえて再計画するときに必須の機能だ。
軸 2：Plan-and-Act ── 計画と実行の分離
ICLR 2025 で発表された Plan-and-Act は、古典的な Plan-and-Execute パターンの現代版だ。ポイントは Planner（高レベル計画） と Executor（環境固有のアクション） を完全に分離すること。
sequenceDiagram
participant U as User
participant P as Planner (大モデル)
participant E as Executor (小モデル)
participant T as Tool / Env
U->>P: 目標
P->>P: 高レベル計画 (5-10 ステップ)
P->>E: ステップ 1 を委譲
E->>T: tool 呼び出し
T->>E: 結果
E->>P: ステップ 1 完了 + 観察
P->>P: 再計画 (必要なら)
P->>E: ステップ 2 を委譲
Note over E,T: 以下繰り返しベンチでは WebArena-Lite で 57.58%、WebVoyager (テキスト) で 81.36% という SOTA を出した。論文の核心は「合成データで Planner を訓練することで、Planner の品質が Executor とは独立に上げられる」ことだ。業務投入の文脈では、Planner に高価なモデル（Opus）、Executor に安価なモデル（Sonnet / Haiku）を割り当てるだけで、コスト効率が大きく変わる。
軸 3：Orchestrator-Worker パターン
Anthropic Engineering の Multi-agent Research System は、1 つの Lead エージェント + 3〜5 個の Sub エージェントという構成を提案する。
graph TB
L[Lead Agent<br/>Opus 4.7]
S1[Sub Agent 1<br/>Sonnet]
S2[Sub Agent 2<br/>Sonnet]
S3[Sub Agent 3<br/>Sonnet]
M[(Shared Memory<br/>計画書 / 進捗 / 失敗履歴)]
L -->|計画分割| S1
L -->|計画分割| S2
L -->|計画分割| S3
S1 -->|要約 1-2K tokens| L
S2 -->|要約 1-2K tokens| L
S3 -->|要約 1-2K tokens| L
L -.write.-> M
S1 -.read.-> M
S2 -.read.-> M
S3 -.read.-> M数字でいうと、シングルエージェント Opus 比 +90.2% の性能向上、ただしトークン消費は約 15 倍。コストが跳ねるが、難易度の高いリサーチタスクではこれが必要、という結論だ。
業務投入で重要な実装の知見：
- Lead は大、Sub は小：Opus × Sonnet 構成が経験則。同じモデルを並列に動かすと、判断が冗長になりコストだけ増える
- Sub からのフィードバックは要約で：Sub agent は 1〜2K トークン以内の要約を Lead に返す。生のツール出力を返すと Lead の context が膨れる
- 計画書は外部ファイルに：context が 200K に近づく前に、計画書 / 進捗 / 失敗履歴を
progress.md等の外部ファイルへ書き出す（軸 5 で詳述）
軸 4：Deep Research 4 系統の整理
2025 年にほぼ同時期に各社が Deep Research 機能を出した。これらは「計画 → 並列リサーチ → 統合 → 構造化レポート」という骨子は同じだが、内部設計はかなり違う。
| 系統 | ベースモデル | 設計の特徴 | 備考 |
|---|---|---|---|
| OpenAI Deep Research | o3 を RL で fine-tune | 単一エージェント中心、o3-deep-research モデルとして API 化 | トリアージ / 明確化 / リサーチの専門サブエージェントが補佐 [要検証] |
| Gemini Deep Research / Max | Gemini 3.1 Pro | 計画 → ユーザー確認 → 実行の協調プランニング、MCP server を外部ツールに、可視化（チャート / 図）まで生成 | Gemini 3.x の thinking と統合 |
| Perplexity Deep Research | DeepSeek R1 + 独自 Test Time Compute | 20-50 並列クエリ、ソーストレーサビリティに強み | HLE 21.1% |
| Anthropic Research | Claude Opus 4.x + orchestrator-worker | 軸 3 のパターンそのもの、Workspace 横断検索 | Claude.ai 上の機能 |
業務投入で参考になる点：
- Deep Research 系の API（OpenAI
o3-deep-research、Gemini Deep Research API、Anthropic Research）は、自前で多階層エージェントを組まずに「リサーチ機能」だけ調達する選択肢を提供する。社内ナレッジ検索エージェントを作るとき、自前で 0 から組むより、これらの API を社内 MCP server に繋いで使う方が立ち上がりが速い場合がある - **Perplexity 型の「並列クエリ + reranker」**は、企業内検索の文脈で特に強い。20-50 並列で投げて Test Time Compute で集約する設計は、社内サーチに移植しやすい
軸 5：Effective Harness ── 「セッションを跨ぐ」設計
Anthropic の Effective Harnesses for Long-Running Agents は、24 時間以上のタスクを完遂するエージェントの設計知見を整理した重要記事だ。本シリーズの「ハーネス」という用語もここから取っている。
ハーネスは「モデル外側のセッション間状態を支える枠組み」のこと。具体的には次のファイル群を agent 自身が読み書きする。
| ファイル | 役割 | 寿命 |
|---|---|---|
init.sh | 環境構築スクリプト | 永続 |
feature_list.json | やるべきタスクの一覧 | タスク完了で削除 |
progress.md | 現在の進捗（最終更新日時、現在のステップ） | 常に最新を保持 |
CHANGELOG.md | 失敗したアプローチの履歴 | 永続 |
| git commit | 各セッションの境界 | 永続 |
最後の CHANGELOG.md が業務投入で特に効く。同じ袋小路に再突入することを防ぐ仕組みだ。
✅ CHANGELOG.md の例
─────────────────────
2026-05-09: ❌ Stripe API v2 で webhook 検証を試みたが、署名形式が変更されていた → v3 に切り替え必要
2026-05-09: ✅ webhook 検証を v3 で実装、idempotency key を必ず保存することで重複処理を防止
2026-05-10: ❌ DB のトランザクション分離レベルを READ COMMITTED に下げたら、二重課金が起きた → SERIALIZABLE で要再試行このフォーマットは Claude Code の内部設計（CLAUDE.md / sub-agent / hooks）にも採用されており、long-running Claude の研究プレビューでも 失敗履歴を残さなかった場合に同じ問題で再びハマる事象が報告されている。
OSWorld-Verified の数字が意味すること
2026 年 5 月時点で、Anthropic Mythos Preview が OSWorld で 79.6%、Opus 4.7 が 78.0%、GPT-5.5 が 78.7% を出した。人間ベースラインは 72.36%（OSWorld 元論文 arXiv:2404.07972）。つまり、
「コンピュータを操作する」というタスクで、最先端のモデルは平均的な人間を超えた
しかしこれは、必ずしも「業務に投入できる」ことを意味しない。OSWorld のタスクは「ファイルを開いて編集する」「メールを送る」のような限定的なシナリオで、長時間・高文脈・複雑な要件には及ばない。Cognition の Devin チームは 18 ヶ月の運用 retrospective で「曖昧要件・スコープ変更・反復対話が依然として弱い」とエクスプリシットに認めている。Devin は junior の置き換え とポジショニングしているのが現状だ。
つまり推論・計画レイヤの実装の壁は越えたが、コスト・信頼性・運用の壁が次の主戦場になる。それを解くのが、本シリーズの ch5（メモリ）以降だ。
❌ アンチパターン：Single-shot LLM call で全部やらせる
症状
─────────
- 5 ステップ目で計画が破綻する
- ツールを呼び忘れる、または間違ったツールを選ぶ
- 同じツール呼び出しを数回繰り返してループに入る
根本原因
─────────
- Extended Thinking を使っていない（thinking ブロックを保持していない）
- 計画と実行を 1 つの呼び出しに混ぜている
- 失敗履歴を残していない（同じ袋小路に何度も入る）
脱出法
─────────
1. Adaptive Thinking を有効化、thinking ブロックを次ターンに必ず保持
2. Planner / Executor を別呼び出しに分ける（軸 2）
3. 5 ステップ以上の計画なら Orchestrator-Worker に切り替える
4. 失敗履歴を CHANGELOG.md として外部ファイルに書く業務投入の観点で重要な 3 点
- Thinking ブロックを絶対に消すな：tool result を返す次ターンで thinking ブロックを保持しないと API が暗黙に thinking を無効化し、再計画品質が崩れる。これは Anthropic の公式ドキュメントに明記されている挙動
- Lead は大、Sub は小、計画書は外部ファイル：Opus × Sonnet ×
progress.mdの三点セットが、24 時間以上のタスクを成立させる経験則 - 失敗履歴を必ず永続化：CHANGELOG.md / git commit / external journal のいずれかに、失敗したアプローチを記録する。これがないと同じ袋小路に再突入し、コストが跳ね上がる
次章への接続
ch4 では、Layer 1 の計画器が呼び出す Layer 2: ツール接続を扱う。MCP の 2025-11-25 仕様、Tool Search / Programmatic Tool Calling / Tool Use Examples の効果数値、Computer Use の OSWorld-Verified スコア、Browser 自動化 3 系統（Playwright / Stagehand / browser-use）、Tool Poisoning と OAuth 2.1 + RFC 8707 の遵守を順に押さえる。
この章のまとめ
- Extended Thinking のブロックは絶対に消さない：保持しないと再計画が壊れる
- Plan-and-Act パターンで Planner と Executor を分離：Planner に高価モデル、Executor に安価モデル
- Orchestrator-Worker は +90.2% / 15× コスト：難易度の高いリサーチでは正当化されるが、コスト跳ねる
- Deep Research 4 系統は同じ問題に違う解：自前で組まず API を叩く選択肢が現実的
- Effective Harness（progress.md / CHANGELOG.md / git commit）：セッションを跨ぐタスクには外部ファイル必須
- OSWorld-Verified で人間越え：実装の壁は越え、次はコスト・信頼性・運用が主戦場