CoTを活用した高度なデバッグ支援：論理的思考を介在させるバグ修正プロンプト設計

Tech

research_status: [CoT, ReAct, System-2 Thinking applied] design_pattern: [Analytical Chain-of-Thought for Software Engineering] author_note: 複雑なコードベースにおける論理的飛躍を防ぐため、推論ステップを明示的に分離したプロンプトを設計。

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

CoTを活用した高度なデバッグ支援：論理的思考を介在させるバグ修正プロンプト設計

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

複雑なロジックが絡むバグの根本原因を特定し、副作用を最小限に抑えた修正案を、論理的推論プロセス（CoT）を経て出力させる。

  • 入力型：ソースコード、スタックトレース/エラー内容（Markdown形式）

  • 出力型：推論ログ、修正済みコード、変更点サマリ（Markdown/JSON形式）

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

graph TD
A["設計: 推論ステップの定義"] --> B["実行: コード解析と論理追跡"]
B --> C["評価: 修正の妥当性と副作用確認"]
C -->|改善: 制約条件の追加| A

  1. 設計: LLMが直接回答せず、「現状分析→仮説立案→検証→修正」の順で思考するよう強制する。

  2. 実行: 与えられたコードに対して、一行ずつの実行トレースをシミュレーションさせる。

  3. 評価: 修正案が既存の機能を破壊していないか、エッジケースを考慮しているかを検証する。

【プロンプトの実装案】

# 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. 影響範囲の確認

  • 副作用の有無：

  • テスト観点： “`

【まとめ】

  1. 思考を外部化させる：<thinking>タグやステップ指定を用いて、LLMが「直感」でコードを生成するのを防ぎ、論理的なトレースを強制する。

  2. 自己批判ステップを入れる：修正案を出した後に「この修正で壊れる可能性のある箇所は？」と問うことで、ハルシネーション（幻覚）による不適切な修正を抑制できる。

  3. 型を固定する：出力形式をMarkdown見出しで制御することで、開発ツールやCI/CDへの組み込みが容易になり、業務効率が向上する。

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

コメント

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