本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
CoTを活用した高度なデバッグ支援：論理的思考を介在させるバグ修正プロンプト設計
【ユースケース定義と課題】
複雑なロジックが絡むバグの根本原因を特定し、副作用を最小限に抑えた修正案を、論理的推論プロセス（CoT）を経て出力させる。
入力型：ソースコード、スタックトレース/エラー内容（Markdown形式）
出力型：推論ログ、修正済みコード、変更点サマリ（Markdown/JSON形式）
【プロンプト設計のループ】
graph TD A["設計: 推論ステップの定義"] --> B["実行: コード解析と論理追跡"] B --> C["評価: 修正の妥当性と副作用確認"] C -->|改善: 制約条件の追加| A
設計: LLMが直接回答せず、「現状分析→仮説立案→検証→修正」の順で思考するよう強制する。
実行: 与えられたコードに対して、一行ずつの実行トレースをシミュレーションさせる。
評価: 修正案が既存の機能を破壊していないか、エッジケースを考慮しているかを検証する。
【プロンプトの実装案】
# Role
あなたはシニア・ソフトウェアエンジニア兼デバッグのエキスパートです。
以下の手順に従い、ステップバイステップで思考（Chain-of-Thought）し、バグの根本原因の特定と修正を行ってください。
# Task
提供されたコードのバグを修正してください。
# Constraints
- 回答の前に、必ず <thinking> タグ内で以下の順序で思考プロセスを記述してください。
1. コードの意図の理解
2. エラーメッセージ/挙動の分析
3. 変数の状態遷移のトレース
4. 根本原因の特定
5. 修正による副作用の検討
- 修正コードは、保守性と可読性を重視してください。
# Input Data
- Code:
{{CODE_HERE}}
- Error/Context:
{{ERROR_HERE}}
# Example Output Format
<thinking>
1. コードの意図: ...
2. 挙動分析: ...
...
</thinking>
## 修正内容の要約
- 変更点1: ...
- 変更点2: ...
## 修正済みコード
```language
// code here
### 【評価指標と誤り分析】
LLMが生成した回答を以下の基準で評価し、精度の低い項目があれば「思考ステップ」の指示を具体化します。
| 評価項目 | 評価内容 | 失敗パターン（例） |
| :--- | :--- | :--- |
| **推論の整合性** | 思考プロセスと修正コードが論理的に一致しているか | 思考ではAと言いながらコードではBを修正する |
| **修正の正確性** | 指摘されたバグが完全に解消されているか | 表層的なエラー回避のみで根本原因が残る |
| **副作用の把握** | 他の機能への影響を正しく予測できているか | 修正により別のユニットテストが落ちる変更 |
| **構文の妥当性** | 出力されたコードが即座に実行可能か | 存在しないライブラリの使用、閉じ括弧の不足 |
### 【改良後の最適プロンプト】
Gemini 1.5 Pro等の長文コンテキストと高い推論能力を活かし、「自己反論（Self-Correction）」ステップを組み込んだ構成です。
```text
# Role
Professional Debugging Engine (Reasoning Focus)
# Mission
提供されたソースコードの論理的欠陥を特定し、堅牢な修正案を提示せよ。
# Execution Process (CoT)
以下の4つのステップを明示的に実行すること。
Step 1: [Observation] コードの構造と依存関係を分析せよ。
Step 2: [Hypothesis] バグが発生する具体的な実行パスを特定し、なぜその挙動になるのか仮説を立てよ。
Step 3: [Verification] 提案する修正案が、他の関数やモジュールにどのような影響を与えるか「批判的」に検証せよ（セルフチェック）。
Step 4: [Solution] 最終的な修正コードと、その修正が正しいことを証明するテストケースを提示せよ。
# Input
- Target Code: {{CODE}}
- Error Details: {{ERROR}}
# Output Template
## 1. 論理推論プロセス
(Step 1〜3の内容を詳細に記述)
## 2. 根本原因
- 原因の要約：
## 3. 修正済みコード
```[language]
[code]
4. 影響範囲の確認
副作用の有無：
テスト観点： “`
【まとめ】
思考を外部化させる：
<thinking>タグやステップ指定を用いて、LLMが「直感」でコードを生成するのを防ぎ、論理的なトレースを強制する。自己批判ステップを入れる：修正案を出した後に「この修正で壊れる可能性のある箇所は？」と問うことで、ハルシネーション（幻覚）による不適切な修正を抑制できる。
型を固定する：出力形式をMarkdown見出しで制御することで、開発ツールやCI/CDへの組み込みが容易になり、業務効率が向上する。
