CoT（思考連鎖）を活用した難解なバグ修正プロンプト：思考の可視化による修正精度の最大化

Tech

{ “expert_role”: “LLM Prompt Engineer / Senior Software Architect”, “technical_focus”: [“Chain-of-Thought”, “Bug Diagnosis”, “Reasoning Optimization”], “instructional_design”: “Structured Drafting Framework” } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

CoT（思考連鎖）を活用した難解なバグ修正プロンプト：思考の可視化による修正精度の最大化

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

複雑な条件分岐や状態遷移を持つプログラムの、表面化しにくいロジックエラーを「実行状態のシミュレーション」を通して特定・修正する。

  • 入力の型：Markdown（ソースコード、期待する動作、発生している不具合）

  • 出力の型：Markdown（思考プロセス、修正計画、修正済みコード、単体テスト案）

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

graph TD
A["設計: 思考ステップの明示化"] --> B["実行: コード解析とシミュレーション"]
B --> C["評価: 修正の妥当性と副作用の確認"]
C -->|改善: ステップの細分化/制約追加| A

  1. 設計: LLMに対し、修正案を出す前に「変数の推移」や「論理的な矛盾」を書き出すよう指示する。

  2. 実行: 実際のコードを入力し、CoTに基づく推論を行わせる。

  3. 評価: 修正後のコードがエッジケースをカバーしているか、既存機能を壊していないかを検証する。

【プロンプトの実装案】

# 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つの鉄則：

  1. 「すぐにコードを書かせない」：ReasoningやAnalysisタグを強制し、LLMに「溜め」を作らせることで論理飛躍を防ぐ。

  2. 「シミュレーションの具体化」：具体的な入力値を与え、「この時の変数の変化を書け」と指示することで幻覚（ハルシネーション）を抑制する。

  3. 「反証ステップの導入」：一度出した結論を疑わせる指示（STEP 3）を加えることで、見落としがちなエッジケースの発見率が劇的に向上する。

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

コメント

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