複雑な制約付き問題に対するToTプロンプト：LLMに幅優先探索を実装させる方法

Tech
{"document_title": "Tree-of-Thoughtsプロンプト設計ガイド", "target_llm": "Gemini 1.5 Pro / GPT-4o", "technique": "ToT (Tree-of-Thoughts), Self-Refinement", "goal": "複雑な推論タスクの探索アルゴリズム実装", "status": "final_draft"}

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

複雑な制約付き問題に対するToTプロンプト：LLMに幅優先探索を実装させる方法

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

ユースケース: 複数の複雑な制約条件（予算、時間、専門性）を考慮したうえで、実現可能性が高く、投資対効果（ROI）が最も高い製品マーケティング戦略を複数案（A案, B案, C案）立案・評価・選択させる。

課題: 従来のChain-of-Thought (CoT) は単一の思考経路を深掘りするため、初期の思考ステップで誤った前提やアイデアを採用した場合、最終結果が局所最適解に陥りやすい。ToTを実装することで、LLMに複数のアイデアパスを並行して探索させ、評価に基づき最適なパス（戦略）を決定させる高度な問題解決能力が必要。

入出力の「型」の定義:

項目 型 説明
入力 Markdown 依頼内容、目標、全ての制約条件を構造化して提供する。
出力 JSON 思考のステップ（状態）、各アイデアパスの評価スコア、最終的な選択を明示的に含む構造化データ。

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

ToTプロンプトは、LLMに「生成→評価→選択（剪定）」の3段階を反復させることで機能します。この設計を効率化するために、常にフィードバックループを回します。

graph TD
A["設計: ToT構造の指示とFew-shot例の準備"] --> B["実行: LLMにタスクを処理させる"]
B --> C["評価: 探索の深さ、評価の客観性を確認"]
C -->|改善: 状態管理、剪定ルールの明確化| A

設計の焦点: LLMが現在の「状態」（探索ツリーのどのノードにいるか、どのアイデアが有望か）を正確に把握し、無駄なパスを剪定する基準（評価関数）を明確にすること。

【プロンプトの実装案】

ToTの基本的な考え方である「K個のアイデアを生成し、評価し、上位B個だけを残して次ステップに進む（幅優先探索）」を強制するプロンプトを提示します。

# 役割

あなたは、複雑な問題に対して複数の可能性を探り、最適な解決策を見つけるTree-of-Thoughts (ToT) 推論エンジンです。

# プロセス定義（厳守）

あなたは以下の3ステップを合計3回繰り返します。

## ステップ1: アイデアの生成 (Generate)

現状のタスクに対し、完全に異なるK=3個の代替思考パス（アイデア）を生成してください。
思考パスは、現在の状態を打破するための具体的なアクションと、その実行による予期される結果を含む必要があります。

## ステップ2: 状態と実現性の評価 (Evaluate)

生成したK=3個のパスそれぞれについて、以下の基準に基づき実現可能性と目標達成度を10点満点で評価してください。

評価基準:

1. 制約適合性（予算、リソース）: 40%

2. ROIポテンシャル: 40%

3. リスクの低さ: 20%
合計スコアに基づき、実現性のコメントを付記してください。

## ステップ3: 最適パスの選択と剪定 (Select & Prune)

評価スコアに基づき、最も有望な上位B=1個のパスを選択し、次のステップの出発点（新しい状態）として採用してください。それ以外のパスは剪定し、理由を簡潔に述べてください。

# 入力情報

## タスク概要

次期主力製品の「アジャイル管理ツール」のローンチ戦略を立案せよ。

## 制約条件


1. 予算：500万円以内。

2. 期間：3ヶ月間の限定キャンペーン。

3. ターゲット：スタートアップ企業のCTO層。

4. 必須要素：競合（Asana, Trello）との明確な差別化が必要。
（現在の状態：初期。未探索）

# 出力形式

全探索プロセスを以下のJSON形式で出力してください。

{
  "exploration_log": [
    {
      "step": 1,
      "generated_thoughts": [
        {"id": "1A", "thought_path": "パス1の具体的な戦略内容。", "evaluation": {"score": 7.5, "comment": "実現性は中程度。ターゲット層へのアプローチが弱い。"}},
        {"id": "1B", "thought_path": "パス2の具体的な戦略内容。", "evaluation": {"score": 9.0, "comment": "高いROIが見込めるが、リソース超過のリスクあり。"}},
        {"id": "1C", "thought_path": "パス3の具体的な戦略内容。", "evaluation": {"score": 6.0, "comment": "安全だが、競合との差別化が不明瞭。"}}
      ],
      "selection": {
        "selected_id": "1B",
        "reason": "最もROIポテンシャルが高いため、リソース超過リスクを次のステップで低減できるか検証する。"
      },
      "new_state_description": "選定された戦略1Bに基づき、リソース効率化に焦点を移す。"
    },
    // ステップ2, ステップ3が続く
  ],
  "final_strategy": "最終的に選ばれた最適な戦略の詳細"
}

【評価指標と誤り分析】

ToTプロンプトの実行において最も起こりやすい失敗パターンは、「探索の質の低さ」と「形式の維持失敗」です。

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

失敗パターン 詳細な現象 LLMの特性と原因
探索の浅さ（局所最適解） 生成されたK個のアイデアが本質的に類似しており、真の代替案になっていない。 LLMがコンテキスト（前のステップの思考）に強く引きずられすぎている。
評価基準のブレ ステップ間で評価スコアの基準が客観的でなくなり、自己矛盾を起こす。 評価関数（本プロンプトでは重み付きスコア）の指示が抽象的すぎた。
ループの形式崩れ JSON構造がステップごとに変化したり、必要なキー（new_state_descriptionなど）が欠落する。 LLMに長文の反復処理を強制する際に、構造化出力の指示が弱い（特に古いモデル）。

LLM-as-a-Judgeによる採点基準

以下の採点基準（10点満点）に基づき、LLMがToTの探索プロセスを忠実に実行したかを評価します。

評価項目 基準（満点：2点）
多様性 (Diversity) 各ステップで生成されたK=3のアイデアが、制約条件と目標に対して互いに独立した明確な代替案である。
状態管理 (State Management) 選ばれたパス（B=1）が、次のステップの「新しい状態」として論理的に引き継がれている。無駄なパスの剪定理由が明確である。
評価の客観性 (Objectivity) 評価基準（重み）に基づき、スコアが客観的かつ一貫して付与されている。スコアとコメントが一致している。
形式の正確性 (Format Adherence) 要求されたJSONスキーマ（特にネストされた構造）を完全に維持している。
最終解の質 (Final Solution) 3ステップの探索を経て、最終的な戦略が入力された全ての制約条件を満たし、かつ目標達成度が最も高い。

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

上記の分析を踏まえ、以下の点を強化します。

  1. 分離命令: 生成、評価、選択を明確に分離し、それぞれの出力を厳格な形式で区切らせる。

  2. 自己点検 (Self-Correction): 評価ステップで、評価基準を再確認させる。

  3. JSON Schema強制: 現代の高性能LLM（Gemini 1.5 Pro/GPT-4o）の多くはJSON Schemaをサポートするため、これに近い形で構造を固定する。

{
  "type": "object",
  "properties": {
    "step_id": {"type": "integer", "description": "現在の探索ステップ番号 (1から開始)"},
    "current_state": {"type": "string", "description": "前ステップで選ばれたパスに基づいた、現在の問題の状態定義。"},
    "generated_paths": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "path_id": {"type": "string"},
          "strategy_description": {"type": "string", "description": "具体的なアクションプラン。"},
          "evaluation_score": {"type": "number", "description": "10点満点の総合スコア。"},
          "evaluation_detail": {"type": "object", "properties": {"feasibility": {"type": "number", "description": "制約適合性スコア"}, "roi_potential": {"type": "number", "description": "ROIポテンシャルスコア"}, "risk_level": {"type": "number", "description": "リスクレベル（低リスクほど高スコア）"}}}
        },
        "required": ["path_id", "strategy_description", "evaluation_score", "evaluation_detail"]
      }
    },
    "selected_path": {
      "type": "object",
      "properties": {
        "selected_id": {"type": "string"},
        "selection_reason": {"type": "string", "description": "剪定理由を含む、このパスが最も有望である理由。"}
      }
    }
  },
  "required": ["step_id", "current_state", "generated_paths", "selected_path"]
}

# ToTエンジン設定

あなたは、厳格な探索アルゴリズム（ToT）を実行するプロセッサです。
タスク：制約付きマーケティング戦略の最適化。
探索回数（深さ）：3回。
生成幅（K）：3つの異なる代替案。
選択幅（B）：上位1案。

# 評価基準（加重スコア）

総合スコア = (制約適合性 * 0.4) + (ROIポテンシャル * 0.4) + (リスクレベル * 0.2)
※各項目は10点満点。

# ユーザー入力

## タスク概要

次期主力製品の「アジャイル管理ツール」のローンチ戦略を立案せよ。

## 制約条件


1. 予算：500万円以内。

2. 期間：3ヶ月間の限定キャンペーン。

3. ターゲット：スタートアップ企業のCTO層。

4. 必須要素：競合（Asana, Trello）との明確な差別化が必要。

# 指示

以下のJSONスキーマを厳守し、3ステップの探索プロセス全体を記述した単一のJSON配列（`exploration_log`）として出力せよ。

[JSONスキーマの定義をここに挿入し、出力を強制する] 
（※ここでは、上記で定義したJSONスキーマを参照していると仮定する）

## ステップ1：初期探索


1. Current Stateを「初期状態：制約の確認と戦略の方向性決定」として設定。

2. K=3の完全に異なる戦略パスを生成せよ。

3. 各パスを上記の加重スコアに基づき厳密に評価せよ。

4. 最も高スコアのパスをB=1として選択し、そのパスを次のステップのCurrent Stateとして要約せよ。

## ステップ2：深化と精緻化


1. Step 1で選ばれたCurrent Stateに基づき、K=3の次のアクションまたは改良案を生成せよ。

2. 評価基準に照らし、各パスが予算とROIポテンシャルを両立しているかを再点検せよ。

3. 最適パスを選択し、Stateを更新せよ。

## ステップ3：最終検証と詳細設計


1. Step 2で選ばれたCurrent Stateに基づき、K=3の最終的な実装詳細案を生成せよ。

2. 最終的に選択されたパスが、全ての制約条件を完全に満たしていることを確認せよ。

3. 最適パスを選択し、プロセスを終了する。

# 出力

探索ログ全体を格納するJSONオブジェクトを生成しなさい。

【まとめ】

Tree-of-Thoughts (ToT) は、CoTの局所最適解問題を克服し、LLMに真の探索能力を持たせるための強力なフレームワークです。実務でこの技術を運用するための鉄則は以下の3点です。

  1. 状態管理の明示: LLMが現在探索ツリーのどこにいるのかを理解させるため、各ステップで「Current State（現在の状態）」をJSON出力の必須要素として明記させ、前のステップの結果から自動で更新させること。

  2. 評価関数の定式化: 「良い」「悪い」といった曖昧な指示ではなく、加重平均を用いた具体的な採点基準（評価関数）を提示すること。これにより、LLMの選択（剪定）プロセスを客観的かつ一貫性のあるものにできます。

  3. 形式による探索の強制: JSON Schemaや厳格なMarkdown形式を用いて、生成、評価、選択の各フェーズを分離し、規定されたKとBのルールを物理的に逸脱できない構造で出力を強制すること。高性能なLLM（Gemini 1.5 Pro, GPT-4oなど）では、構造化出力機能を利用することで信頼性が飛躍的に向上します。

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

コメント

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