複雑な意思決定のためのTree of Thoughts (ToT) プロンプティング：制約充足型の計画を導く

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

複雑な意思決定のためのTree of Thoughts (ToT) プロンプティング：制約充足型の計画を導く

【ユースケース定義と課題】

ユースケースと課題

複数の時間的、予算的、地理的制約を同時に満たし、かつ、顧客満足度が最大化されるような最適な多段階の業務アジェンダを策定させる。従来のChain-of-Thought (CoT) では、初期段階の判断ミスを引きずり、最終的に制約違反や非最適な計画に陥ることが課題。

入出力の型定義

  • 入力: 計画要件（制約条件、目標）。

  • 出力: 思考の分岐（複数の選択肢とその評価）、および最終的な計画を含む厳格なJSONスキーマ。

【プロンプト設計のループ】

LLMが複雑なタスクを解く際、単発のプロンプトで最適解を得ることは困難です。ToTプロンプトを成功させるには、パスの生成、評価、選択を繰り返す反復構造の指示が必要です。

graph TD
A["設計: ToT構造と評価関数を定義"] --> B["実行: LLMに複数の思考パスを生成させる"]
B --> C["評価: 出力を制約充足度で検証"]
C -->|改善: 評価基準の厳格化/探索幅の調整| A

各ステップの役割:

  1. 設計: LLMが生成すべき思考の「幅」（探索すべきパスの数）と「深さ」（ステップ数）、そして各パスを評価するための具体的なヒューリスティック関数（例：コスト、制約充足スコア）をプロンプトに組み込みます。

  2. 実行: LLMは定義された構造に従い、複数の選択肢とその評価をJSON形式で出力します。

  3. 評価: 人間またはLLM-as-a-Judgeが出力を検証し、制約が守られているか、論理的矛盾がないかをチェックします。

【プロンプトの実装案】

複雑な計画タスクに対し、ToTを適用する際の基本的なプロンプト構造です。これは、LLMに「複数の選択肢を生成し、それぞれを評価し、最も有望なものを選び、次のステップに進む」という探索プロセスを強制します。

Tree of Thoughts (ToT) 基本構造プロンプト

このプロンプトでは、タスクを3つの主要な「思考フェーズ」に分割しています。

# ROLE

あなたは、厳格な制約条件下で最適な多段階計画を策定する戦略コンサルタントです。

# TASK

以下の【制約】と【目標】に基づき、最適な計画（アジェンダ）を策定してください。決定プロセス全体をTree of Thoughts (ToT) 形式で実行し、各ステップで3つの分岐案を提示し、評価してください。

## 【計画要件】


1.  **目標**: 3日間の業務アジェンダを策定する。

2.  **制約**:

    *   総予算は15万円（交通費、宿泊費、活動費込み）。

    *   毎日、午前中に必ず「クリエイティブ・レビュー」の時間を設ける（最低2時間）。

    *   移動時間は各ステップ間で最大2時間とする。

    *   重要顧客Aへの訪問（必須）は2日目または3日目に設定する。

---
## 思考フェーズ 1: 初期パス生成と評価（3日間の大枠）

以下のJSON形式で、3つの異なる初期案（パス）を提示し、それぞれのヒューリスティック評価を出力せよ。

1.  **パス生成**: 制約を満たす3つの異なる3日間の大枠（例：A案：初日移動多め、B案：顧客訪問を2日目に固定、C案：予算効率重視）。

2.  **ヒューリスティック評価**: 各案について、以下の3要素を10点満点で評価せよ。

    *   制約充足度（10点満点）: すべての制約を満たしているか。

    *   予算効率（10点満点）: 予算15万円に対する余裕度。

    *   戦略的妥当性（10点満点）: 目標達成への寄与度。

## 思考フェーズ 2: 最適パスの選択と深化

フェーズ1で最も高い総合評価を得たパス（P_Selected）を選択し、そのパスの「2日目」に焦点を当て、具体的な行動計画（アクティビティ、時間、コスト）を3つの異なる方法で具体化せよ。

## 思考フェーズ 3: 最終計画の統合と総括

フェーズ2で最も評価された具体的な計画を統合し、最終的な3日間の計画（JSON形式）を出力せよ。最終JSONには、総コストとすべての制約が満たされていることの確認（Yes/No）を含めよ。

---

# FORMAT

最終的な回答は、必ず以下の厳密なJSONスキーマに従い出力してください。
{
    "Phase_1_Results": [
        {"Path_ID": "A", "Outline": "...", "Scores": {"Constraint_Fulfillment": 8, "Budget_Efficiency": 9, "Strategic_Relevance": 7}},
        // 2つのパスをさらに記述
    ],
    "Selected_Path_1": "...",
    "Phase_2_Details": [
        // P_Selectedの2日目の深化案3つ
    ],
    "Final_Plan_Summary": {
        "Total_Cost": 145000,
        "Constraint_Check": "Yes",
        "Agenda": [
            {"Day": 1, "Activities": "...", "Cost": "..."}
            // Day 2, Day 3
        ]
    }
}

【評価指標と誤り分析】

ToTプロンプトの最大の誤りパターンは、「思考の木の途中で探索を放棄する」「自己矛盾した評価を下す」「指定された構造を無視する」ことです。特に強力なLLM（Gemini 1.5 Pro/Flash, GPT-4o）を使う場合、評価関数（ヒューリスティック）が具体的であればあるほど、出力品質は向上します。

失敗パターン（誤り分析）

  1. 評価基準の無視: パスAが制約を違反しているにもかかわらず、高得点をつけてしまう（幻覚評価）。

  2. 様式崩れ: JSON構造を維持できず、思考パスの途中で通常のテキストに戻ってしまう。

  3. 探索の幅不足: 指示された3つの分岐案が、実質的に同じ内容になってしまう。

LLM-as-a-Judge 採点基準（Markdownテーブル）

評価項目 評価基準 採点 (0-5点)
A. 構造の正確性 ToTの3フェーズすべてが指示通りに実行され、厳密なJSON形式で出力されているか。 5点: 完璧 / 3点: 軽微な形式エラー / 0点: 構造崩壊
B. 制約充足度 提示された最終計画が、予算（15万円以下）および時間（クリエイティブ・レビュー必須、移動時間2時間制限）のすべてを満たしているか。 5点: すべて充足 / 3点: 1つ制約違反 / 0点: 致命的な違反
C. 思考の多様性と深さ 各フェーズで提示された分岐案（計3案）が、十分に異なり、論理的に妥当な選択肢であったか。 5点: 完全に異なるパス探索 / 3点: 類似パスが含まれる / 0点: パス探索が行われていない
D. 最終決定の妥当性 評価スコアに基づき、実際に最も妥当なパスが最終的に選択されているか。 5点: 論理的選択 / 0点: 評価を無視した選択

【改良後の最適プロンプト】

上記分析に基づき、LLMが「自己評価」と「再試行」を内包できるように、指示の厳密性と役割定義を強化します。特に、ヒューリスティック評価の客観性を高める指示を追加します。

Tree of Thoughts (ToT) 構造化検証プロンプト

# METADATA

TITLE: Optimized Multi-Constraint Planning (ToT)
MODEL_CAPABILITIES: Strict JSON Output, Complex Reasoning

# ROLE

あなたは、AI制御された意思決定エンジンです。あなたの唯一の任務は、提示された制約と目標に基づき、Tree of Thoughts (ToT) プロセスを通じて最適な計画を策定し、最終的に厳格なJSONスキーマを満たすことです。

# PROCESS_INSTRUCTION (ToT Loop)

以下の3ステップを厳密に繰り返してください。

1. **BRANCHING (分岐)**: 現在の課題に対する3つの最も異なる、かつ実現可能性の高い選択肢を生成する。

2. **EVALUATION (評価)**: 各選択肢に対し、以下の制約充足スコアリング関数を用いて客観的に評価する。

3. **SELECTION (選択)**: 最も高い評価スコアを得た選択肢を、次のステップの基礎として選定する。

## 【計画要件と制約】

(※前項の要件を再定義)

## 【制約充足スコアリング関数 (Heuristic Function)】

各パスの評価は、以下の計算ロジックに基づき、総合点（25点満点）で算出すること。

- **C1: 必須条件充足度**: 未達の必須制約（顧客訪問、レビュー時間）1つにつき-10点。

- **C2: 予算超過ペナルティ**: 15万円を超える超過額1万円につき-5点。

- **C3: 効率性ボーナス**: 移動時間合計が最も短い案に+5点。

- **C4: 顧客満足度見込み**: 目標達成への寄与度を主観的根拠に基づき1～5点。

---
## STEP 1: 初期パス生成 (P1, P2, P3)

3つのパスを生成し、上記スコアリング関数に基づき総合点を計算せよ。

## STEP 2: 最適パスの検証と深化

STEP 1で選択したパスを P_BEST とする。P_BESTの**最大リスク要素**を特定し、そのリスクを軽減するための代替行動案を3つ生成せよ（P_BEST_A, P_BEST_B, P_BEST_C）。再度、スコアリング関数に基づき評価せよ。

## STEP 3: 最終計画の統合と検証

STEP 2で選択した案に基づき、最終的な3日間の計画を統合する。計画完了後、必ず「自己検証」として、すべての制約を再チェックし、JSONの最後にその結果を記述せよ。

# FINAL_OUTPUT_SCHEMA

回答は、このスキーマを厳守せよ。JSON以外は一切記述してはならない。

```json
{
    "Thought_Process_Trace": {
        "Step_1_Initial_Evaluation": [
            {
                "Path_ID": "P1",
                "Description": "...",
                "Scores": {"C1": "...", "C2": "...", "C3": "...", "C4": "...", "Total_Score": 20},
                "Rationale": "C2に基づき予算超過ペナルティなし。"
            }
            // P2, P3を続ける
        ],
        "Selected_Path_1": "P2",
        "Step_2_Refinement_Evaluation": [
            // P_BEST_A, P_BEST_B, P_BEST_Cの詳細とスコア
        ]
    },
    "Final_Validated_Plan": {
        "Title": "最適化された3日間業務アジェンダ",
        "Constraint_Check": {
            "Budget_OK": true,
            "Review_Time_OK": true,
            "Movement_OK": true
        },
        "Total_Projected_Cost_JPY": 148500,
        "Agenda": [
            // 3日間の詳細計画
        ]
    }
}

【まとめ】

Tree of Thoughts (ToT) は、単なるCoTの拡張ではなく、LLMに複雑な探索アルゴリズムをシミュレートさせる手法です。実務でこの技術を運用するための鉄則は以下の通りです。

  1. 評価関数（ヒューリスティック）を数値化せよ: 抽象的な「良い計画」ではなく、具体的に「未達制約1つにつき-10点」のように数値化することで、LLMの意思決定を客観的なものにします。

  2. 構造化出力で探索経路を保証せよ: JSONやXMLなどの厳格な構造化出力を強制することで、LLMが思考の木（ノードと枝）を正しく管理し、人間や他のシステムがその探索パスを追跡できるようにします。

  3. モデルの自己批判能力を組み込め: 最適プロンプトのように、パス選定後に「最大リスク要素の特定」や「最終検証」を強制することで、LLM自身の出力に対するチェックと改善のループ（Self-Refinement）をToTプロセスの中に組み込みます。これは、特にGemini 1.5 Pro/FlashやGPT-4oのような高度なモデルで効果を発揮します。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました