CoT（思考の連鎖）を用いた複雑なロジックバグの特定と修正プロンプトの設計

Tech

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

CoT（思考の連鎖）を用いた複雑なロジックバグの特定と修正プロンプトの設計

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

複雑な非同期処理や状態遷移が絡むコードのバグを特定し、副作用を抑えた修正案を提示させる。LLMが「思考を飛ばして即修正」することによる、デグレや浅い解決を防ぐ。

  • 入力： ソースコード、エラーログ（または期待する挙動と実際の挙動の差異）

  • 出力： 思考プロセス（Markdown）、修正コード（Markdown）、テストコード（Markdown）

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

graph TD
A["設計: 思考ステップの構造化"] --> B["実行: バグ解析と修正案生成"]
B --> C["評価: 修正の妥当性と副作用の検証"]
C -->|改善: 思考の深掘りが不足| A

  • 設計：解決プロセスを「現状分析」「仮説立案」「検証」「実装」の4段階に分割するよう指示。

  • 実行：Gemini 1.5 Pro等の長文コンテキストを活用し、関連ファイルをすべて読み込ませる。

  • 評価：LLM-as-a-Judgeを用い、修正が根本原因を解決しているかをスコアリング。

【プロンプトの実装案】

# Role

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

# Task

以下の手順（Chain-of-Thought）に従って、思考プロセスを明文化しながら進めてください。

## Step 1: コードとエラーの現状分析


- 現在のコードの処理フローをステップバイステップで説明してください。

- 発生しているエラーログ、または意図しない挙動の根本原因（Root Cause）を特定してください。

## Step 2: 修正仮説の立案


- バグを修正するためのアプローチを複数検討し、最も副作用の少ないものを選択してください。

- その修正が他のモジュールに与える影響（破壊的変更の有無）を列挙してください。

## Step 3: 実装案の提示


- 修正後のコード全体、または差分（diff）を提示してください。

- 修正のポイントを簡潔に説明してください。

## Step 4: 検証コードの作成


- この修正が正しく機能することを証明するためのユニットテスト、または再現スクリプトを提示してください。

# Input Data


- Code: 
{{CODE_HERE}}

- Error Log / Issue:
{{ERROR_LOG_HERE}}

# Output Format

Markdown形式で出力してください。思考プロセス（Step 1-2）を必ず含めること。

【評価指標と誤り分析】

評価項目 期待される挙動 失敗パターン（誤り分析）
原因特定の正確性 コードの論理的欠陥を正確に指し示す 表面的なエラーメッセージの言い換えに留まる
副作用の予見 修正による他箇所への影響を指摘できる 依存関係を見落とし、別の場所でエラーを誘発する
様式遵守 指定したStep 1-4の構成で出力する 思考プロセスを飛ばして修正コードだけ出力する
コードの動作性 提示されたコードがシンタックスエラーなく動く 存在しないライブラリ関数の捏造（幻覚）

【改良後の最適プロンプト】

分析結果に基づき、「セルフ・デバッギング（自己批判）」のステップを追加した最強のプロンプトです。

# System

あなたはプログラミングのデバッグに特化したAIエージェントです。
複雑なバグに対し、論理的な推論（Chain-of-Thought）を用いて解決策を導き出します。

# Instruction

以下の形式で回答してください。

1. <Thinking>: 

   - コードのデータフローをトレースする。

   - 「なぜこのバグが起きるのか」という仮説を立て、それが正しいかコードから検証する。

   - 修正案を考えた後、あえて「その修正が失敗する可能性」を自問自答してください。

2. <Action>:

   - 修正済みコードを提示。

3. <Test>:

   - 再現・検証用コードを提示。

# Constraints


- コードの修正は「最小限」に留めること。

- マジックナンバーやハードコーディングを避け、既存のコーディング規約に従うこと。

- Gemini 1.5 Proのコンテキスト能力を活かし、前後の関数との整合性を重視すること。

# Input

Target Code: {{CODE}}
Issue: {{ISSUE}}

【まとめ】

  1. 思考を言語化させる：Thinkingタグ等で、LLMに「答えを出す前に書かせる」ことで論理の飛躍を防ぐ。

  2. 否定的な視点を与える：自身の修正案に対する「反論」をステップに組み込むことで、境界条件の考慮漏れ（オフバイワンエラー等）を激減させる。

  3. 検証までをセットにする：修正コードだけでなくテストコードを強制出力させることで、LLM自身の出力に対する「責任」をプロンプトレベルで持たせる。

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

コメント

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