CoT（思考の連鎖）を活用した複雑な論理バグの特定と修正プロンプトの設計

Tech

RESEARCH-FIRST: CoT（Chain-of-Thought）はプログラミングタスクにおいて、単にコードを出力させるよりも、実行計画と論理検証をステップごとに踏ませることで、推論精度が大幅に向上することが論文（Wei et al., 2022）等で示されている。特にGemini 1.5 Pro等の長文コンテキストモデルでは、中間思考プロセスを明示的に出力させることが、大規模なコードベースでの整合性維持に有効である。 PLAN:

  1. 構造化された思考プロセス（分析→仮説→修正案→検証）の定義。

  2. 修正前後の差分を明確にする出力フォーマットの指定。

  3. 失敗パターン（依存関係の無視など）を防ぐ制約事項の組み込み。

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

CoT（思考の連鎖）を活用した複雑な論理バグの特定と修正プロンプトの設計

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

複雑なロジックが絡む関数のバグ特定と修正。単なる文法ミスではなく、境界条件や論理の破綻を深く考察させる必要がある。

  • 入力の型：対象のソースコード、エラーメッセージ（あれば）、期待される動作。

  • 出力の型：Markdown（思考プロセス、修正方針、修正済みコード、テストケース案）。

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

graph TD
A["設計: 思考ステップの定義"] --> B["実行: コード解析と修正案生成"]
B --> C["評価: 修正の妥当性と副作用の確認"]
C -->|改善: 制約の追加やFew-shotの強化| A

  1. 設計: LLMに「まず問題を理解し、次に原因を推論し、最後にコードを書く」という順序を徹底させる。

  2. 実行: 修正コードだけでなく、なぜその修正が必要なのかという「根拠」をセットで出力させる。

  3. 評価: 修正によって他の機能が壊れていないか（退行バグ）、計算量が悪化していないかを検証する。

【プロンプトの実装案】

# Role

あなたはシニアソフトウェアエンジニアとして、コードのデバッグとリファクタリングの専門家です。

# Task

提供されたコードに含まれる論理バグを特定し、修正してください。

# Constraints


- 回答は必ず以下の「Thinking Process」を経てから最終的な解決策を提示すること。

- 修正コードは、元のコーディングスタイルを維持すること。

- 破壊的変更が必要な場合は、その理由を明記すること。

# Thinking Process


1. Analysis: コードの目的と現在の挙動、発生している問題を分析せよ。

2. Hypothesis: なぜそのバグが発生しているのか、根本原因に関する仮説を立てよ。

3. Plan: バグを修正するためのステップを箇条書きで作成せよ。

4. Implementation: 修正後のコードを生成せよ。

5. Verification: 修正によって解決されることと、考慮すべきエッジケースを挙げよ。

# Input Data


- Code: 
[ここにコードを貼り付け]

- Issue:
[ここにエラー内容や期待する動作を記述]

# Output Format

## 🧠 Thinking Process

(ここに分析・仮説・計画を記述)

## ✅ Fixed Code

```[language]
// 修正済みコード

🧪 Verification & Edge Cases

  • (検証内容)
## 【評価指標と誤り分析】

期待通りにいかない「失敗パターン」：

- **文脈無視**: 特定の関数を修正する際、クラス全体のステート管理を無視して修正してしまう。

- **過剰修正**: バグに関係のない正常なロジックまでリファクタリングしてしまい、差分が肥大化する。

- **幻覚（Hallucination）**: 存在しないライブラリのメソッドを提案する。

### LLM-as-a-Judge 採点基準

| 評価項目 | 1点: 不十分 | 3点: 標準 | 5点: 優秀 |
| :--- | :--- | :--- | :--- |
| **論理的整合性** | 原因分析と修正内容が一致していない | 分析は正しいが、修正が一部不足 | 根本原因が特定され、完璧に修正 |
| **副作用の考慮** | 他の機能への影響を無視している | 懸念点への言及はある | 副作用を最小化し、代替案も提示 |
| **CoTの遵守** | 思考プロセスが省略されている | 手順通りだが内容が浅い | 各ステップが深く考察されている |

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

分析結果に基づき、**「修正前後のDiff（差分）」**と**「テストコードの自動生成」**を組み込んだ最強プロンプトです。

```text

# Role

Expert Debugging Engine (Chain-of-Thought Enabled)

# Instructions

以下の手順に従い、提供されたコードの論理的な欠陥を修正してください。

## Step 1: Root Cause Analysis


- 問題が発生する最小の入力パターンを特定してください。

- データの流れ（Data Flow）を追跡し、どこで期待値と乖離するかを説明してください。

## Step 2: Implementation (with Diff)


- 修正コードを提示してください。

- 修正箇所が明確になるよう、可能な限り `// MODIFIED:` コメントを添えるか、前後の差分について言及してください。

## Step 3: Regression Testing


- 修正が正しいことを証明するための単体テスト（Unit Test）コードを作成してください。

- 境界値（空の値、最大値、異常値）を少なくとも3つ含めてください。

# Input


- Target Code: 
{{CODE}}

- Reported Issue:
{{ISSUE}}

# Output

(Markdown形式でStep1〜3を出力)

【まとめ】

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

  1. 「思考の出力」を強制する: Thinking Process というセクションを設け、書き込みを強制することで、LLMの「早とちり」を防ぐ。

  2. 境界条件を明示させる: Edge Cases を出力させることで、LLM自身に自分の回答の脆弱性をチェックさせるセルフデバッグ機能を働かせる。

  3. 差分（Diff）意識を持たせる: どこを変えたのかを明示させる指示を入れることで、既存コードへのマージミスを減らす。

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

コメント

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