付録 B：パターン選択ガイド (Pattern Selection Guide)

「どの場面でどのパターンを使うか」を素早く決めるためのガイド。過剰設計や選択ミスを防ごう。

本番環境で一番よくある問題って何だと思う？「パターンの実装方法がわからない」じゃないんだよね。実は「どのパターンを使えばいいかわからない」なんだ。

こんな疑問を持ったことはないかな：

• 「このタスク、ReAct と Planning どっちがいい？」
• 「Reflection っていつ必要なの？」
• 「ToT と Debate の違いって何？」
• 「マルチエージェント編成って、結局何を解決するの？」

この付録では、決定木・比較表・アンチパターンの警告を通じて、5分で最適なパターンを見つけられるようにするよ。

コア原則：まずシンプルなパターンを選ぶこと。複雑なパターンに手を出すのは本当に必要なときだけ。複雑なパターン = 高コスト + 遅い + デバッグが大変。

B.1 シングルエージェントの推論パターン選択

クイック決定木

タスクに外部ツールが必要？（検索、API、ファイル読み書きなど）
│
├─ 不要 → 明示的な推論プロセスが必要？
│           ├─ 必要 → Chain-of-Thought（第12章）
│           └─ 不要 → 直接プロンプト（パターン不要）
│
└─ 必要 → タスクを複数ステップに分解する必要がある？
          │
          ├─ 不要 → ReAct（第2章）
          │
          └─ 分解が必要 → 分解後のステップ間に明確な依存関係がある？
                         │
                         ├─ 依存なし → ReAct（第2章）
                         │
                         └─ 依存あり → Planning（第10章）
                                       ↓
                         Planning 完了後、品質は基準を満たした？
                         │
                         ├─ OK → 完了
                         │
                         └─ NG → 品質向上が必要？それとも多角的な視点が必要？
                                  │
                                  ├─ 品質向上 → Reflection（第11章）
                                  │
                                  └─ 多角的/議論の余地あり → 複数の経路を探索する必要がある？
                                                           │
                                                           ├─ 探索必要 → Tree-of-Thoughts（第17章）
                                                           │
                                                           └─ 対立的議論が必要 → Debate（第18章）

シングルエージェントパターン比較マトリクス

コスト説明：パーセンテージは ReAct を基準とした相対値。実際のコストはタスクの複雑さや設定パラメータによって変わるよ。

ReAct を使うべきとき

適用場面：

• 外部ツールの呼び出しが必要（検索、API、ファイル操作）
• タスクが比較的シンプルで、複雑な計画は不要
• 透明な推論プロセスが必要（監査可能性）
• コスト重視で、素早いレスポンスが必要

不適切な場面：

• 純粋な推論タスクで、外部ツールが不要
• タスクが複雑すぎて、事前の計画が必要
• 高品質な出力が必要で、一回の生成では不十分

コストの目安：

• Token: タスクあたり約 3000-8000
• レイテンシ: 約 10-30 秒
• 失敗時のリトライコストは低い

例：

○ 「API が 500 エラーを返す原因を調べて」
○ 「Python 3.12 の新機能を検索してまとめて」
× 「この会社を調査して 5000 文字のレポートを書いて」（Planning + Research を使う）
× 「このシステムはマイクロサービスとモノリス、どっちがいい？」（Debate を使う）

Planning を使うべきとき

適用場面：

• タスクを 3 つ以上の独立したサブタスクに分解できる
• サブタスク間に依存関係がある
• 並列実行で効率を上げられる
• 出力に構造化された整理が必要

不適切な場面：

• 1 ステップで完了するシンプルなタスク
• タスクを明確に分解できない
• レイテンシ重視のリアルタイム場面

コストの目安：

• Token: タスクあたり約 5000-15000
• レイテンシ: 約 30-90 秒
• 分解オーバーヘッド: 約 1000 tokens
• 統合オーバーヘッド: 約 1500 tokens

主要な設定：

MaxIterations:     3    // カバレッジ評価の最大イテレーション
MinCoverage:       0.85 // 最低カバレッジ閾値
MaxSubtasks:       7    // サブタスク数の上限

例：

○ 「テスラの 2024 年財務実績を分析して。売上、利益、競合比較を含めて」
○ 「OpenAI について調査して、完全な競合分析レポートを作成して」
× 「今日の天気は？」（ReAct を使う）
× 「ソート関数を書いて」（ReAct を使う）

Reflection を使うべきとき

適用場面：

• 出力品質の要求が高い（レポート、ドキュメント、分析）
• 明確な評価基準がある
• コストより品質を優先
• 一回の生成では品質が安定しない

不適切な場面：

• シンプルな Q&A で、品質要求が低い
• レイテンシ重視（時間が倍増する）
• コスト重視
• 客観的な評価基準がない

コストの目安：

• Token: 初期コストの 2-3 倍
• レイテンシ: 初期レイテンシの 2-3 倍
• MaxRetries = 1-2 で十分

主要な設定：

MaxRetries:          2    // 最大リトライ回数
ConfidenceThreshold: 0.7  // 品質閾値（高すぎに設定しないこと）
Criteria: []string{
    "completeness",
    "correctness",
    "clarity",
}

例：

○ 「API 技術ドキュメントを生成して」（高品質が必要）
○ 「投資デューデリジェンスレポートを書いて」（正確性が重要）
× 「明日の天気を調べて」（コストに見合わない）
× 「リアルタイムチャット返信」（レイテンシ重視）

Chain-of-Thought を使うべきとき

適用場面：

• 数学的推論、論理分析
• 思考プロセスを示す必要がある
• 外部ツールが不要
• 飛躍的なエラーを減らしたい

不適切な場面：

• 外部ツールの呼び出しが必要（ReAct を使う）
• 複数の経路を探索する必要がある（ToT を使う）
• シンプルな事実確認

コストの目安：

• Token: 直接回答より +10%
• レイテンシ: ほとんど増加なし
• 推論精度が約 15% 向上

例：

○ 「この数学問題を解いて：24 ゲーム (3,8,8,3)」
○ 「このコードの時間計算量を分析して」
× 「最新の AI ニュースを検索して」（ReAct を使う）
× 「高可用性アーキテクチャを設計して」（ToT または Debate を使う）

Tree-of-Thoughts を使うべきとき

適用場面：

• 解空間が広く、複数の可能な経路がある
• 初期の判断が重要で、間違えると戻りにくい
• 中間状態の品質を評価できる
• 品質 > コスト/スピード

不適切な場面：

• 明確な標準解法がある
• コスト/レイテンシ重視
• 中間状態を評価できない

コストの目安：

• Token: +200-400%（ノード数 x 単回コスト）
• レイテンシ: +200-300%
• ExplorationBudget で上限を制御

主要な設定：

MaxDepth:          3    // ツリーの深さ
BranchingFactor:   3    // 各ノードの分岐数
PruningThreshold:  0.3  // 枝刈り閾値
ExplorationBudget: 15   // 最大探索ノード数

例：

○ 「100 万 QPS を支える決済システムのアーキテクチャを設計して」
○ 「この複雑なバグの根本原因を見つけて（複数の可能性あり）」
× 「標準的なユーザーログイン機能を実装して」（成熟したテンプレートあり）
× 「データベースの特定フィールドの値をクエリして」（明確な操作）

Debate を使うべきとき

適用場面：

• 議論の余地がある話題で、標準的な答えがない
• 多角的な分析が必要
• 対立的な質問・反論が必要
• 意思決定のリスクが高く、十分な論証が必要

不適切な場面：

• 客観的に正しい答えがある
• コスト/レイテンシが極めて重要
• シンプルな意思決定

コストの目安：

• Token: NumDebaters x MaxRounds x 単回コスト
• レイテンシ: 各ラウンドを順次実行
• 3 人の討論者 x 2 ラウンド = 基準コストの 6 倍

主要な設定：

NumDebaters:      3     // 2-5 人の討論者
MaxRounds:        2     // 2-3 ラウンドで十分
Perspectives:     []string{"optimistic", "skeptical", "practical"}
RequireConsensus: false // 合意を強制しない
VotingEnabled:    true  // 投票でフォールバック

例：

○ 「AI は 2025 年に SaaS を置き換えるか？」
○ 「会社はオンプレミスとクラウド、どちらを選ぶべきか？」
× 「2 + 2 は？」（客観的な答え）
× 「Python の構文は何？」（事実の問題）

B.2 マルチエージェント編成パターン選択

クイック決定木

タスクに複数のエージェントの協調が必要？
│
├─ 不要 → シングルエージェントパターンを使う（B.1 を参照）
│
└─ 必要 → タスクを事前に完全に計画できる？
          │
          ├─ 完全に計画可能 → サブタスク間に依存関係がある？
          │                   │
          │                   ├─ 依存なし → Parallel（第14章）
          │                   │
          │                   ├─ 部分的に依存 → DAG（第14章）
          │                   │
          │                   └─ 完全にシリアル → Sequential（第14章）
          │
          └─ 完全に計画できない → 動的な調整が必要？
                                 │
                                 ├─ 必要 → Supervisor（第15章）
                                 │
                                 └─ 不要 → タスク間で引き継ぎが必要？
                                           │
                                           ├─ 必要 → Handoff（第16章）
                                           │
                                           └─ 不要 → DAG（第14章）

マルチエージェントパターン比較マトリクス

Parallel 実行を使うべきとき

適用場面：

• 3 つ以上の完全に独立したサブタスク
• 同時実行で効率を上げられる
• タスク間にデータ依存がない

不適切な場面：

• タスク間に依存関係がある
• タスク数が少ない（1-2 個）
• 後続タスクが前のタスクの結果を必要とする

コストの目安：

• 並列度: MaxConcurrency = 3-5（個人アカウント）
• 並列度: MaxConcurrency = 5-10（チームアカウント）
• 時間節約: シリアル実行と比べて約 40-60%

例：

○ 「テスラ、BYD、Rivian の 3 社の株価を検索して」
○ 「このテキストを英語、日本語、フランス語に翻訳して」
× 「まず株価を検索して、次に変動率を計算して」（依存あり、Sequential を使う）
× 「1 社の情報を検索して」（タスクが 1 つだけ、並列不要）

Sequential 実行を使うべきとき

適用場面：

• 後続タスクが前のタスクの結果に明確に依存
• 結果の受け渡しが必要
• ロジックがチェーン状に進行

不適切な場面：

• タスクが並列実行可能
• タスク間に依存がない

コストの目安：

• レイテンシ: 各タスクのレイテンシの合計
• PassPreviousResults: 約 +10% token
• 適切な範囲: 3-5 個の順次ステップ

例：

○ 「まずテスラの株価を検索して、次に変動率を計算して、最後に分析を生成して」
○ 「ファイル読み込み → データ分析 → レポート生成」
× 「3 社の株価を検索して」（並列可能、Parallel を使う）

DAG ワークフローを使うべきとき

適用場面：

• 5 つ以上のサブタスクがあり、一部は並列可能
• 明確な依存関係がある
• インテリジェントなスケジューリングで効率を最適化したい
• 事前に依存関係を計画できる

不適切な場面：

• すべてのタスクが独立（Parallel を使う）
• すべてのタスクがシリアル（Sequential を使う）
• 依存関係が確定できない（Supervisor を使う）
• タスク数が少ない（3 個未満）

コストの目安：

• スケジューリングオーバーヘッド: 約 +5% token
• 時間節約: 純粋なシリアル実行と比べて約 20-40%
• 適切な範囲: 5-15 個のサブタスク

主要な設定：

MaxConcurrency:         5      // 最大並行数
DependencyWaitTimeout:  360    // 依存待ちタイムアウト（秒）
PassDependencyResults:  true   // 依存結果を受け渡す

例：

○ 「テスラの財務分析：財務報告取得(A) + 競合情報取得(B) → 成長率計算(C、Aに依存) + 利益率計算(D、Aに依存) → 比較分析(E、A,B,C,Dに依存)」
× 「3 社を検索」（依存なし、Parallel を使う）
× 「次のステップを動的に決定」（事前計画できない、Supervisor を使う）

Supervisor パターンを使うべきとき

適用場面：

• タスクの数や種類が不確定
• 動的なタスク割り当てが必要
• エージェント間でリアルタイム通信が必要
• 部分的な失敗時にインテリジェントな降格が必要

不適切な場面：

• タスクを事前に完全に計画できる
• シンプルな固定フロー
• コストが極めて重要

コストの目安：

• スケジューリングオーバーヘッド: +20-30% token
• Supervisor の判断: 各ラウンド約 1000 tokens
• 適切な場面: 複雑で動的なシナリオ

例：

○ 「複数のエキスパートエージェントを調整して複雑な技術問題を解決（戦略を動的に調整）」
○ 「カスタマーサービスシステムで異なるエキスパートエージェントに動的にルーティング」
× 「固定のデータ処理パイプライン」（DAG を使う）
× 「シンプルな並列検索」（Parallel を使う）

Handoff メカニズムを使うべきとき

適用場面：

• 専門分化した分業が必要
• タスクの引き継ぎが明確
• コンテキストの受け渡しが必要
• ワークフロー的な業務移行に似ている

不適切な場面：

• 専門分化が不要
• 引き継ぎポイントがない
• タスクが完全に独立

コストの目安：

• 引き継ぎオーバーヘッド: 各回約 500 tokens
• コンテキスト受け渡し: サイズによる

例：

○ 「カスタマーサービスエージェント → テクニカルサポートエージェント → 返金エージェント」
○ 「要件分析エージェント → 設計エージェント → 実装エージェント」
× 「3 つのウェブサイトを並列検索」（引き継ぎ不要、Parallel を使う）

B.3 アンチパターン警告 (Anti-Patterns)

マルチエージェントを使うべきでないとき

アンチパターン 1：マルチエージェントのためのマルチエージェント

間違った例：
タスク：「今日の天気を調べて」
設計：エージェント1 で検索 → エージェント2 で解析 → エージェント3 でフォーマット

問題：3 エージェント = 3 倍のコスト。でもシングルエージェントなら 5 秒で終わる

正しいやり方：シングル ReAct エージェントで直接完了

アンチパターン 2：過度な分割

間違った例：
タスク：「1 社を分析して」
分割：20 個の細かいサブタスク（会社名、設立日、CEO、資金調達、製品1、製品2...）

問題：調整コスト > 実行コスト

正しいやり方：3-7 個の粗いタスク（基本情報、製品マトリクス、資金調達履歴）

アンチパターン 3：無理やり並列化

間違った例：
タスク：「まず株価を検索して、次に変動率を計算して」
無理やり並列：エージェント1 で株価検索 || エージェント2 で変動率計算（データがない！）

問題：依存関係が無視されている

正しいやり方：Sequential または DAG

アンチパターン 4：無限イテレーション

間違った例：
Planning with RequirePerfectCoverage = true
MaxIterations = 100

問題：100% には永遠に到達しない、Token を使い果たす

正しいやり方：CoverageThreshold = 0.85, MaxIterations = 3

よくある過剰設計の罠

判断原則

オッカムの剃刀原則：

必要がなければ、複雑にするな。シンプルなパターンで解決できるなら、複雑なパターンは使わない。

段階的拡張原則：

Level 1: 単一の LLM 呼び出し
         ↓ 効果が不十分？
Level 2: ReAct（ツールを追加）
         ↓ タスクが複雑すぎる？
Level 3: Planning（分解を追加）
         ↓ 品質が不十分？
Level 4: Reflection（イテレーションを追加）
         ↓ 多角的な視点が必要？
Level 5: ToT / Debate（探索/対立を追加）

80/20 の法則：

• 80% のタスクは ReAct + Planning で十分
• 15% のタスクは Reflection が必要
• 5% のタスクだけが ToT / Debate を必要とする

B.4 コスト-品質-レイテンシのトレードオフマトリクス

三次元トレードオフ

              品質
               ▲
               │
    Debate ●   │
           │   │   ● ToT
  Research ●   │
           │   │
Reflection ●   │
           │   │
  Planning ●   │   ● DAG
           │   │
       CoT ●   │
           │   │
     ReAct ●───┼────────────────► レイテンシ
               │
               │
               ▼
              コスト

シナリオ別最適化戦略

レイテンシ重視シナリオ（リアルタイム対話、オンラインクエリ）

• 優先：ReAct、CoT
• 回避：Reflection、ToT、Debate
• 設定：MaxIterations = 5, Timeout = 30s

コスト重視シナリオ（大規模バッチ処理）

• 優先：ReAct、Planning
• 回避：ToT、Debate、Research
• 設定：BudgetAgentMax = 5000、評価には小さいモデルを使用

品質重視シナリオ（調査レポート、意思決定支援）

• 優先：Planning + Reflection、Research、Debate
• コスト：2-5 倍は許容可能
• 設定：ConfidenceThreshold = 0.8, MaxRetries = 2

コスト見積もり式

シングルエージェントパターン：

ReAct:      Base
Planning:   Base x (1 + 0.5 x NumSubtasks)
Reflection: Base x (1 + MaxRetries)
CoT:        Base x 1.1
ToT:        Base x ExplorationBudget
Debate:     Base x NumDebaters x MaxRounds

マルチエージェントパターン：

Parallel:   Base x NumTasks / MaxConcurrency（時間最適化）
Sequential: Base x NumTasks（時間累積）
DAG:        Base x NumTasks x 0.6-0.8（部分並列）
Supervisor: Base x (NumAgents + SupervisorOverhead)

B.5 クイック選択早見表

タスクタイプ別選択

制約条件別選択

チーム成熟度別選択

B.6 実際のケース選定

ケース 1：競合分析

要件：3 社の競合を分析して、比較レポートを作成

初期選択：Planning（分解）+ Parallel（並列検索）

最適化の方向性：

• 品質要求が高い → Reflection を追加
• 議論の余地がある（技術ロードマップの比較など）→ Debate を追加

最終方案：

Planning（3 つのサブタスクに分解）
  → Parallel（3 社を並列検索）
  → Synthesis（統合）
  → Reflection（品質チェック）

コスト見積もり：

• Base (ReAct): 約 5000 tokens
• Planning: +2500 tokens
• Parallel (x3): +10000 tokens
• Reflection: +5000 tokens
• 合計: 約 22500 tokens（GPT-4o-mini で約 $0.03）

ケース 2：技術アーキテクチャ設計

要件：高並行性の決済システムを設計

初期選択：ToT（複数のアーキテクチャ案を探索）

最適化の方向性：

• 明確な制約がある（コスト、技術スタックなど）→ ToT より Debate を使用
• エキスパートの視点が必要 → 3 つの Perspective を設定（性能、コスト、セキュリティ）

最終方案：

Debate（3 つの視点：性能優先、コスト優先、セキュリティ優先）
  → 2 ラウンドの討論
  → モデレーターが統合

コスト見積もり：

• Base: 約 8000 tokens
• Debate (3 x 2 ラウンド): 約 48000 tokens
• 合計: 約 56000 tokens（GPT-4o-mini で約 $0.07）

ケース 3：カスタマーサービスのインテリジェントルーティング

要件：ユーザーの質問に応じて異なるエキスパートエージェントにルーティング

初期選択：Supervisor（動的ルーティング）

最適化の方向性：

• ルーティングルールが比較的固定 → Supervisor より Handoff を使用
• Supervisor の判断コストを節約

最終方案：

分類エージェント（問題タイプを判定）
  → 対応するエキスパートに Handoff
  → エキスパートエージェントが処理

コスト見積もり：

• 分類: 約 1000 tokens
• エキスパート処理: 約 5000 tokens
• Handoff オーバーヘッド: 約 500 tokens
• 合計: リクエストあたり約 6500 tokens

B.7 設定テンプレート参考

Fast テンプレート（レイテンシ優先）

mode: react
config:
  max_iterations: 5
  timeout_seconds: 30
  budget_agent_max: 5000

# 無効化
reflection_enabled: false
debate_enabled: false
tot_enabled: false

Balanced テンプレート（バランス型）

mode: planning
config:
  max_iterations: 10
  timeout_seconds: 120
  budget_agent_max: 15000

  # Planning
  max_subtasks: 7
  min_coverage: 0.85

  # Reflection（オプション）
  reflection_enabled: true
  reflection_max_retries: 1
  reflection_confidence_threshold: 0.7

Quality テンプレート（品質優先）

mode: research
config:
  max_iterations: 15
  timeout_seconds: 300
  budget_agent_max: 30000

  # Research
  max_research_rounds: 3
  coverage_threshold: 0.9

  # Reflection
  reflection_enabled: true
  reflection_max_retries: 2
  reflection_confidence_threshold: 0.8

  # Debate（オプション）
  debate_enabled: true
  debate_num_debaters: 3
  debate_max_rounds: 2

B.8 デバッグ判断フロー

タスクの効果が良くないとき：

効果が悪い？
│
├─ ツールを呼び出している？
│  ├─ 呼び出していない → MinIterations をチェック、ツール使用を強制
│  └─ 呼び出している → 続行
│
├─ タスクを分解している？
│  ├─ していない → タスク複雑度 > 0.5？Planning を有効化を検討
│  └─ している → 続行
│
├─ 品質は基準を満たしている？
│  ├─ 満たしていない → Reflection を試す (MaxRetries=1)
│  └─ 満たしているが議論の余地あり → Debate を検討
│
└─ コストは許容範囲？
   ├─ 高すぎる → MaxIterations、BudgetAgentMax を下げる
   └─ 許容範囲 → 設定パラメータの最適化を続ける

B.9 まとめと判断原則

ゴールデンルール

1. オッカムの剃刀：シンプルでできるなら、複雑にしない
2. 段階的拡張：ReAct から始めて、徐々にアップグレード
3. ROI を評価：コスト増加は同等の品質向上をもたらすか
4. 制約を明確に：レイテンシ/コスト/品質、最大 2 つまで最適化

よくある判断経路

90% のタスク：

• ReAct（ツールが必要）
• CoT（純粋な推論）

5% のタスク：

• Planning（複雑な分解）
• DAG（並列最適化）

3% のタスク：

• Reflection（高品質）
• Research（体系的調査）

2% のタスク：

• ToT（複数経路探索）
• Debate（議論のある話題）

最後のアドバイス

本番環境では：

• まず ReAct でフローを通す
• ボトルネックを特定（品質/効率/コスト）
• 的を絞って高度なパターンを導入
• 継続的に ROI を監視

完璧を追求しないこと：

• 85% の品質で十分な場合が多い
• 最後の 15% の向上には 5 倍のコストがかかることが多い
• 限界収益は逓減する

覚えておこう：

正しいパターン選択 > 完璧なパラメータチューニング

関連資料

• 第 2 章：ReAct 循環 - 基礎パターン
• 第 10 章：Planning パターン - タスク分解
• 第 11 章：Reflection パターン - 品質保証
• 第 12 章：Chain-of-Thought - 推論の可視化
• 第 14 章：DAG ワークフロー - マルチエージェント編成
• 第 17 章：Tree-of-Thoughts - 複数経路探索
• 第 18 章：Debate パターン - 対立的議論
• 第 23 章：Token 予算制御 - コスト管理
• 付録 A：ケーススタディ（ある場合）- 実際のシナリオ

次のステップ：このガイドで適切なパターンを選んだら、対応する章を参照して実装の詳細を深く学ぼう。