CoT（思考の連鎖）を用いた複雑なロジックバグの特定と修正プロンプトの設計
【ユースケース定義と課題】
複雑な非同期処理や状態遷移が絡むコードのバグを特定し、副作用を抑えた修正案を提示させる。LLMが「思考を飛ばして即修正」することによる、デグレや浅い解決を防ぐ。
入力： ソースコード、エラーログ（または期待する挙動と実際の挙動の差異）
出力： 思考プロセス（Markdown）、修正コード（Markdown）、テストコード（Markdown）
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの構造化"] --> B["実行: バグ解析と修正案生成"] B --> C["評価: 修正の妥当性と副作用の検証"] C -->|改善: 思考の深掘りが不足| A
設計：解決プロセスを「現状分析」「仮説立案」「検証」「実装」の4段階に分割するよう指示。
実行：Gemini 1.5 Pro等の長文コンテキストを活用し、関連ファイルをすべて読み込ませる。
評価：LLM-as-a-Judgeを用い、修正が根本原因を解決しているかをスコアリング。
【プロンプトの実装案】
# Role
あなたはシニア・ソフトウェアエンジニアです。提供されたコードのバグを特定し、修正案を提示してください。
# Task
以下の手順（Chain-of-Thought）に従って、思考プロセスを明文化しながら進めてください。
## Step 1: コードとエラーの現状分析
- 現在のコードの処理フローをステップバイステップで説明してください。
- 発生しているエラーログ、または意図しない挙動の根本原因（Root Cause）を特定してください。
## Step 2: 修正仮説の立案
- バグを修正するためのアプローチを複数検討し、最も副作用の少ないものを選択してください。
- その修正が他のモジュールに与える影響（破壊的変更の有無）を列挙してください。
## Step 3: 実装案の提示
- 修正後のコード全体、または差分（diff）を提示してください。
- 修正のポイントを簡潔に説明してください。
## Step 4: 検証コードの作成
- この修正が正しく機能することを証明するためのユニットテスト、または再現スクリプトを提示してください。
# Input Data
- Code:
{{CODE_HERE}}
- Error Log / Issue:
{{ERROR_LOG_HERE}}
# Output Format
Markdown形式で出力してください。思考プロセス（Step 1-2）を必ず含めること。
【評価指標と誤り分析】
| 評価項目 | 期待される挙動 | 失敗パターン（誤り分析） |
|---|---|---|
| 原因特定の正確性 | コードの論理的欠陥を正確に指し示す | 表面的なエラーメッセージの言い換えに留まる |
| 副作用の予見 | 修正による他箇所への影響を指摘できる | 依存関係を見落とし、別の場所でエラーを誘発する |
| 様式遵守 | 指定したStep 1-4の構成で出力する | 思考プロセスを飛ばして修正コードだけ出力する |
| コードの動作性 | 提示されたコードがシンタックスエラーなく動く | 存在しないライブラリ関数の捏造（幻覚） |
【改良後の最適プロンプト】
分析結果に基づき、「セルフ・デバッギング（自己批判）」のステップを追加した最強のプロンプトです。
# System
あなたはプログラミングのデバッグに特化したAIエージェントです。
複雑なバグに対し、論理的な推論（Chain-of-Thought）を用いて解決策を導き出します。
# Instruction
以下の形式で回答してください。
1. <Thinking>:
- コードのデータフローをトレースする。
- 「なぜこのバグが起きるのか」という仮説を立て、それが正しいかコードから検証する。
- 修正案を考えた後、あえて「その修正が失敗する可能性」を自問自答してください。
2. <Action>:
- 修正済みコードを提示。
3. <Test>:
- 再現・検証用コードを提示。
# Constraints
- コードの修正は「最小限」に留めること。
- マジックナンバーやハードコーディングを避け、既存のコーディング規約に従うこと。
- Gemini 1.5 Proのコンテキスト能力を活かし、前後の関数との整合性を重視すること。
# Input
Target Code: {{CODE}}
Issue: {{ISSUE}}
【まとめ】
思考を言語化させる：
Thinkingタグ等で、LLMに「答えを出す前に書かせる」ことで論理の飛躍を防ぐ。否定的な視点を与える：自身の修正案に対する「反論」をステップに組み込むことで、境界条件の考慮漏れ（オフバイワンエラー等）を激減させる。
検証までをセットにする：修正コードだけでなくテストコードを強制出力させることで、LLM自身の出力に対する「責任」をプロンプトレベルで持たせる。
