CoTによる論理推論を用いた複雑なバグ修正・リファクタリング支援

Tech

{ “expert_role”: “Prompt Engineering Specialist”, “techniques_used”: [“Chain-of-Thought”, “Few-shot Prompting”, “Self-Correction Loop”, “LLM-as-a-Judge”], “target_llm”: “Gemini 1.5 Pro / GPT-4o”, “version”: “1.0.1” }

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

CoTによる論理推論を用いた複雑なバグ修正・リファクタリング支援

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

論理構造が複雑な関数のバグ特定と修正案の提示。LLMが原因を深く分析せず、表面的な修正で済ませてしまう「近視眼的修正」の防止が課題。

  • 入力形式: Markdown（現状のソースコード、エラーログ、期待する挙動）

  • 出力形式: Markdown（思考プロセス、根本原因、修正コード、テストケース）

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

graph TD
A["設計: 思考ステップの明示"] --> B["実行: コード解析と修正案生成"]
B --> C["評価: 論理的一貫性と構文チェック"]
C -->|改善: 修正漏れや不整合の特定| A

各ステップの詳細は以下の通りです。

  1. 設計: LLMに対し「回答前に内部で問題を分解する」命令を組み込みます。

  2. 実行: 与えられたコードに対し、CoTを用いて一行ずつ論理を検証させます。

  3. 評価: 生成されたコードが元の要件を満たし、新たなバグを生んでいないか検証します。

【プロンプトの実装案】

# Role

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

# Task

以下の手順（Chain-of-Thought）に従って思考し、最終的な解決策を出力してください。

## Step 1: コードの挙動分析

現状のコードが「何をしているか」と、報告されているエラーが「なぜ起きているか」を論理的に分解して説明してください。

## Step 2: 根本原因の特定

表面的なエラーではなく、データ構造、スコープ、非同期処理の順序など、根本的な問題箇所を特定してください。

## Step 3: 修正プランの策定

修正方針を箇条書きで示してください。既存の機能への副作用がないことを確認してください。

## Step 4: 実装と検証

修正後のコードを提示し、そのコードが問題を解決することを証明するエッジケース（境界値）を含むテストコードを作成してください。

# Input Data


- Code: 
{{CODE}}

- Error Log/Issue:
{{ISSUE}}

# Output Format

## 1. 思考プロセス

(Step 1-3の分析内容)
## 2. 修正済みコード

(コードブロック)
## 3. 修正のポイント

(簡潔な解説)
## 4. 推奨されるテストケース

(テストコードまたは入力例)

【評価指標と誤り分析】

LLMが陥りやすい「ハルシネーション（幻覚）」や「様式崩れ」を以下の基準で評価します。

評価項目 評価内容 失敗パターン
論理的整合性 思考プロセスと修正コードが一致しているか 分析で述べた修正がコードに反映されていない
根本解決度 エラーの表面的な回避ではなく原因を叩けているか try-catchで囲むだけのその場しのぎな修正
構文正確性 提供されたコードがそのまま動作するか 存在しないライブラリの使用、閉じ括弧の不足

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

分析結果に基づき、「自己検閲（Self-Correction）」のステップを追加した最強のプロンプトです。

# Role

Professional Software Debugger (Expert in {{LANGUAGE}})

# Constraints


- 回答を生成する前に、必ず「自分の立てた修正案に矛盾がないか」を一度疑ってください。

- 修正によって影響を受ける可能性のある「周辺機能」を3つ挙げてください。

# Instructions (Strict Chain-of-Thought)


1. <thinking>: 提供されたコードをステップ実行するように脳内でトレースし、変数の状態変化を書き出す。

2. <analysis>: バグの再現条件を定義する。

3. <refinement>: 修正案を出し、それが「最もシンプルかつ堅牢か」を自己批判する。

4. <output>: 最終的な修正コードと、その正当性の根拠を提示する。

# Context


- Target Code: {{CODE}}

- Context/Bug: {{ISSUE}}

# Output

(思考プロセスは <thinking> タグ内に隠蔽し、最終回答のみをMarkdownで構造化して出力すること)

【まとめ】

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

  1. 「書く前に考えさせる」: Step-by-step だけでなく、具体的な思考の「型（変数のトレース等）」を指定する。

  2. 「周辺への影響を答えさせる」: バグ修正はデグレとの戦いです。副作用の有無を強制的に出力させることで、LLMの注意力を高めます。

  3. 「自己批判ステップの導入」: 一度出した結論を「本当に正しいか？」と再考させるフェーズを設けることで、ハルシネーションを劇的に抑制できます。

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

コメント

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