12. 曖昧な要求を構造化するプロンプト設計の技術的アプローチ
自然言語の「解釈の揺らぎ」が引き起こす実行エラー
ユーザーからの依頼は、文脈や前提知識に大きく依存するため、一貫した構造を持っていません。この「解釈の揺らぎ」をそのまま実行ロジックに組み込むと、システムはどの部分を真の指示として扱うべきか判断できず、処理が失敗したり、意図しない結果を出す原因となります。
プロンプトによる「思考の強制構造化」
この課題を解決するアプローチは、プロンプトを単なる指示文としてではなく、「思考の強制構造化（Forced Structuring of Thought）」を行うためのフレームワークとして利用することです。つまり、LLMに「考える過程」を、人間が読みやすい構造（JSONやマークダウンの特定のタグ）で出力させることを目的とします。
3段階の構造化アプローチ
曖昧な要求を処理する際は、以下の3段階のステップをプロンプト内で強制的に実行させることが、最も効果的です。
- ステップ1: 意図の特定と分類 (Intent Classification)：まず、要求の背後にある「目的」を特定させます。例：「これは情報検索か？」「コンテンツ生成か？」「データ操作か？」という分類を強制します。
- ステップ2: 必要な要素の抽出と検証 (Entity Extraction & Validation)：次に、その意図を達成するために必要な具体的な要素（日時、対象キーワード、トピックなど）を抽出し、それぞれに「必須/任意」のフラグを立てさせます。この段階で、不足している要素があれば、それを「未定義のタスク」として特定させます。
ステップ3: 実行計画の出力 (Action Plan Generation)：最終的に、ステップ1と2の結果を統合し、「実行すべきアクションのリスト」をJSON形式で出力させます。このJSONには、実行するツール名、引数、実行順序を含めることが理想です。
「計画」と「実行」の分離の徹底
このプロセスで生成されたJSON（実行計画）は、絶対にLLMの出力としてそのまま次のステップに渡してはいけません。必ず、このJSONを読み込む専用の「バリデーター（検証スクリプト）」を設け、JSONのスキーマチェック、必須フィールドの存在チェック、値の型チェックを**コード側で実行する**必要があります。これが、プロンプトの「思考」とコードの「実行」を分ける境界線となります。
まとめ：プロンプトは「思考の設計図」として使う
プロンプトは、システムが「何を考えるべきか」という設計図を描くための強力なツールです。この設計図を基に、実際の実行は必ず堅牢なコード（スクリプト）に任せることで、曖昧な要求からでも高い信頼性を持つワークフローを構築できます。
