CoT（思考連鎖）を活用した難解なバグ修正プロンプト：思考の可視化による修正精度の最大化
【ユースケース定義と課題】
複雑な条件分岐や状態遷移を持つプログラムの、表面化しにくいロジックエラーを「実行状態のシミュレーション」を通して特定・修正する。
入力の型：Markdown（ソースコード、期待する動作、発生している不具合）
出力の型：Markdown（思考プロセス、修正計画、修正済みコード、単体テスト案）
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの明示化"] --> B["実行: コード解析とシミュレーション"] B --> C["評価: 修正の妥当性と副作用の確認"] C -->|改善: ステップの細分化/制約追加| A
設計: LLMに対し、修正案を出す前に「変数の推移」や「論理的な矛盾」を書き出すよう指示する。
実行: 実際のコードを入力し、CoTに基づく推論を行わせる。
評価: 修正後のコードがエッジケースをカバーしているか、既存機能を壊していないかを検証する。
【プロンプトの実装案】
# Role あなたはシニア・ソフトウェアエンジニア兼デバッグのエキスパートです。 提供されたコードの論理的な誤りを、思考プロセスを明示しながら修正してください。 # Constraints - 修正案を提示する前に、必ず「## Reasoning」セクションを設けて思考過程を記述してください。 - 思考過程では、特定の入力を想定した「コードのドライラン（1行ずつのトレース）」を含めてください。 - 修正は最小限に留め、既存の設計思想を尊重してください。 # Input Data - Code: [修正対象のコードをここに貼り付け] - Expected: [期待される動作] - Actual: [実際の不具合・エラー内容] # Output Format ## 1. Reasoning - 現状のロジックの問題点 - ステップバイステップの実行シミュレーション（変数の変化など） - 根本原因の特定 ## 2. Fix Plan - 修正方針の簡潔な説明 ## 3. Fixed Code ```[language] [修正後のコード]
4. Test Cases
- 修正を確認するための正常系・異常系テストケース
### 【評価指標と誤り分析】 | 評価項目 | 採点基準 (1-5) | 失敗パターン（例） | | :--- | :--- | :--- | | **推論の論理性** | 実行トレースが正確か | 推論の中で変数の値を間違え、誤った結論に達する | | **修正の正確性** | 不具合が解消されているか | 表面的な修正のみで、境界条件でのエラーが残る | | **副作用の最小化** | 既存機能への影響はないか | 修正により別の関数の挙動が変わってしまう | | **形式遵守** | 指定したセクションがあるか | `Reasoning`を飛ばしてコードだけ出力する | ### 【改良後の最適プロンプト】 最新のLLM（GPT-4oやGemini 1.5 Pro）の長いコンテキストと推論能力を最大限引き出すため、**「反証のステップ」**を追加した構成です。 ```text # Task あなたはデバッグ専門の自律型エージェントです。提供されたコードの潜在的なバグを特定し、修正してください。 # Instructions 以下の4つのステップで思考し、出力してください。 STEP 1: [ANALYSIS] コードを静的に解析し、データフローを追跡してください。 STEP 2: [SIMULATION] 不具合が発生する具体的な入力を1つ選び、1行ずつ実行シミュレーションを行ってください。各行での変数の状態を記述してください。 STEP 3: [FALSIFICATION] 「自分の立てた修正案が間違っている可能性」を検討し、別の原因がないか1分間再考してください。 STEP 4: [SOLUTION] 最も堅牢な修正コードを提示してください。 # Target Code [コードを挿入] # Issue Description [期待と現実の差異を挿入]
【まとめ】
実務でプロンプトを運用するための3つの鉄則：
「すぐにコードを書かせない」：
ReasoningやAnalysisタグを強制し、LLMに「溜め」を作らせることで論理飛躍を防ぐ。「シミュレーションの具体化」：具体的な入力値を与え、「この時の変数の変化を書け」と指示することで幻覚（ハルシネーション）を抑制する。
「反証ステップの導入」：一度出した結論を疑わせる指示（STEP 3）を加えることで、見落としがちなエッジケースの発見率が劇的に向上する。
