CoT（思考の連鎖）を活用した論理バグ修正プロンプトの設計ガイド

Tech

RESEARCH-FIRST: Chain-of-Thought (CoT) combined with Self-Correction (Self-Refine) and Structured Output are essential for complex logic tasks. Latest models (Gemini 1.5 Pro, GPT-4o) exhibit higher accuracy when forced to output a “hidden” reasoning trace before the final solution. PLAN:

  1. Use a clear debugging scenario (Logic error in state management).

  2. Design a prompt that enforces a “Mental Sandbox” execution.

  3. Evaluate based on logical soundness and regression prevention.

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

CoT（思考の連鎖）を活用した論理バグ修正プロンプトの設計ガイド

【ユースケース定義と課題】 複雑な条件分岐や状態管理が絡むプログラムの論理バグを特定し、修正案を提示する。 課題： 単純な指示ではLLMが表面的な修正（対症療法）に終始し、根本原因を見逃したりデグレードを引き起こしたりしやすい点。 入出力形式： 入力は「ソースコード＋期待する挙動」、出力は「思考プロセス＋修正コード（Markdown）」とする。

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

graph TD
A["設計: 思考ステップの定義"] --> B["実行: CoTによる推論"]
B --> C["評価: 修正の妥当性と副作用確認"]
C -->|論理の飛躍がある場合| A
C -->|成功| D["最適プロンプトとして採用"]

  1. 設計: LLMがコードを「実行（シミュレート）」する手順を明文化する。

  2. 実行: 修正前に必ず現状のトレースを行わせる。

  3. 評価: 修正後のコードがエッジケースをカバーしているか、ユニットテストの観点でレビューする。

【プロンプトの実装案】

# Role

あなたはシニア・ソフトウェアエンジニアです。提供されたコードの論理バグを特定し、根本原因を修正してください。

# Task

以下の手順（Chain-of-Thought）に従って思考し、回答してください。

1. **コードの理解**: コードの目的と各関数の役割を1行で要約する。

2. **実行トレース**: バグが発生する入力値（または想定される異常系）を想定し、変数の値がどのように変化するかステップバイステップでシミュレーションする。

3. **原因特定**: 期待される挙動と実際の挙動が乖離する「地点」と「理由」を特定する。

4. **修正案の立案**: 副作用を最小限に抑えた修正方針を立てる。

5. **最終出力**: 修正後のコードと、なぜこの修正で解決するのかの解説を出力する。

# Constraints


- 修正前に必ず「# 思考プロセス」というセクションを作り、内部推論を書き出すこと。

- デグレード（既存機能の破壊）の可能性に必ず言及すること。

# Input Data

## 対象コード

(ここにコードを貼り付け)

## 期待される挙動

(ここに期待値を記述)

【評価指標と誤り分析】 LLMが出力した修正案を以下の基準で評価します。

評価項目 評価基準 失敗パターン（分析）
原因特定の正確性 バグの根本的な所在を指摘できているか 表面的な型変換や命名変更で誤魔化す
副作用の有無 修正によって他の機能が壊れていないか 境界条件（null, 空文字）でのクラッシュ
CoTの深さ ステップバイステップの推論が行跡にあるか 「思考中…」の後にいきなり正解を書く（跳躍）
再現性 提示された修正で実際にテストが通るか 存在しないライブラリや関数の捏造（幻覚）

【改良後の最適プロンプト】 分析結果に基づき、Self-Correction（自己修正）プロセスを組み込んだ最強のプロンプトです。

# Role

Professional Bug Hunter (Expert in Logic Verification)

# Process (Chain-of-Thought)

[STEP 1: TRACE] 
提示されたコードを1行ずつ「仮想デバッガ」のように実行し、変数の状態を書き出してください。
[STEP 2: HYPOTHESIZE]
バグの原因に関する仮説を3つ立て、最も妥当なものを選択してください。
[STEP 3: VERIFY]
選択した修正案を適用した場合、別のエラーが発生しないか「悪魔の代弁者（批判的視点）」として検証してください。

# Output Format

## ■ 実行トレース

(思考の過程)
## ■ 根本原因

(簡潔な説明)
## ■ 修正済みコード

```javascript
// 修正コード

■ テスト観点

(修正を確認するために必要なテストケース) “`

【まとめ】 実務でプロンプトを運用するための3つの鉄則：

  1. 「考える時間」を強制的に作る：出力の冒頭で「思考プロセス」を記述させることで、トークン生成における論理的整合性を高める。

  2. 実行シミュレーションを行わせる：LLMにインタープリタの役割を擬似的に演じさせ、変数の遷移を記述させることがバグ発見の近道となる。

  3. 否定的な検証（Red Teaming）を入れる：自分の修正案を一度疑わせるステップ（Step 3）を設けることで、Gemini 1.5 Proなどの推論能力を最大限に引き出し、デグレードを防止する。

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

コメント

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