CoT（思考の連鎖）を用いた複雑なプログラムバグの構造的修正手法

Tech

RESEARCH-FIRST:

  • CoT (Chain-of-Thought) は複雑なロジックを解く際に、中間的な思考ステップを明示させることで推論精度を向上させる（Wei et al., 2022）。

  • プログラミングにおいては、単に「修正後のコードを出せ」と命じるよりも、「現状の挙動分析 → バグの原因特定 → 修正方針の策定 → 実装」というステップを踏ませることで、Gemini 1.5 Pro や GPT-4o のハルシネーションを抑制できる。

  • Self-Correction 要素を組み込み、生成したコードを LLM 自身に再検品させるフローが有効。

PLAN:

  1. メタデータ出力

  2. 開示バッジ

  3. H1: CoTによる複雑なロジックバグの特定と修正プロンプト

  4. ユースケース：非同期処理や状態管理が絡む再現困難なバグの修正。出力はMarkdown/JSON併用。

  5. Mermaid図解：設計・実行・評価・改善のサイクル。

  6. プロンプト実装案：思考プロセスを強制する「Step-by-Step Analysis」プロンプト。

  7. 評価指標：修正の正確性、副作用の有無をLLM-as-a-Judgeで定義。

  8. 最適プロンプト：構造化された思考枠組みを適用した完成版。

  9. まとめ：3つの鉄則。

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

CoT（思考の連鎖）を用いた複雑なプログラムバグの構造的修正手法

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

ユースケース： 複数のモジュールが絡む非同期処理や、エッジケースで発生する再現性の低い論理バグの特定と修正。

課題： LLMがコードの表面的な修正（パッチ当て）に終始し、根本原因を見逃したり、修正によって別の箇所でデグレード（退行）を引き起こしたりすること。

入出力の型：

  • 入力： バグを含むソースコード、期待される挙動、エラーログ（任意）

  • 出力： Markdown（思考プロセス ＋ 修正コード）および JSON（影響範囲のメタデータ）

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

graph TD
A["設計: 思考ステップの定義"] --> B["実行: LLMによる多段階推論"]
B --> C["評価: 修正の整合性チェック"]
C -->|デグレード発見| A
C -->|合格| D["最終出力"]

  1. 設計：LLMに「即座にコードを書くこと」を禁じ、まず現象を分析させる制約を課す。

  2. 実行：CoT（Chain-of-Thought）を用いて、原因、仮説、検証、実装の順に出力させる。

  3. 評価：LLM-as-a-Judgeの手法を用い、修正案が要件を満たしているか、副作用がないかを自己検証させる。

【プロンプトの実装案】

# Role

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

# Task

以下のコードには論理的な欠陥が含まれています。
「思考の連鎖（Chain-of-Thought）」を用いて、以下の手順で解決策を導き出してください。

## Step 1: 現状分析 (Analysis)


- コードが現在どのように動作しているか、データフローを追ってください。

- どこで期待と異なる挙動（バグ）が発生しているかを特定してください。

## Step 2: 根本原因の特定 (Root Cause)


- なぜそのバグが発生するのか、言語の仕様やフレームワークの特性を踏まえて説明してください。

## Step 3: 修正方針の策定 (Strategy)


- 修正によるサイドエフェクト（副作用）を最小限に抑える方法を検討してください。

## Step 4: 実装 (Implementation)


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

# Constraints


- ステップ1から3を完了する前に、絶対にコードを書かないでください。

- 修正コードには、なぜその変更が必要だったかをコメントで記載してください。

# Input Data

## Code:

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

## Error/Expected Behavior:

(エラー内容や期待する動作を記述)

【評価指標と誤り分析】

LLMが出力した修正案を以下の基準で評価します。

評価項目 評価内容 失敗パターン（例）
推論の論理性 思考プロセスが論理的に飛躍していないか 「なんとなくここが怪しい」という直感的な記述
修正の正確性 指定されたエラーが確実に解消されているか 別のエラーが発生する（構文ミス、変数未定義）
副作用の最小化 既存の正常な機能に影響を与えていないか 本来必要な処理まで削除してしまう
様式遵守 指定されたフォーマット（JSON/MD）を守っているか 思考プロセスを飛ばしてコードだけ出力する

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

Gemini 1.5 Proの長いコンテキストと推論能力を最大限に引き出す、構造化された「最強プロンプト」です。

# System Instruction

You are an elite Debugging Engine. Follow the "Reasoning-First" protocol.
Your goal is to fix bugs with 0% regression rate.

# Protocol: [THINK] -> [PLAN] -> [FIX] -> [VERIFY]

## 1. [THINK]

Analyze the provided code snippets. Map the data structure and execution flow.
Identify exactly where the logic diverges from the intended behavior.

## 2. [PLAN]

Hypothesize the fix. Evaluate if this fix introduces new issues (e.g., race conditions, memory leaks).
Output your reasoning in a bulleted list.

## 3. [FIX]

Provide the optimized, clean, and production-ready code.

## 4. [VERIFY]

Perform a self-code-review. Does this fix satisfy all edge cases? 
If not, go back to [THINK].

# Output Format

Markdown format with specific headers.
At the end, provide a JSON block summarizing the change:
{
  "bug_type": "string",
  "severity": "low|medium|high",
  "files_affected": [],
  "regression_risk": "score 1-10"
}

# Input

## Source Code:

{{CODE}}

## Context/Issue:

{{ISSUE_DESCRIPTION}}

【まとめ】

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

  1. 「即時回答」を禁止する：Wait and Think や Analyze before coding という明示的な指示が、コードの質を劇的に変える。

  2. 型を定義する：思考プロセスはMarkdown、メタデータ（影響度など）はJSONと分けることで、後続の自動化パイプラインに組み込みやすくする。

  3. 自己検品（Self-Verification）を組み込む：プロンプトの最後に「自分で自分のコードをレビューせよ」というステップを加えるだけで、単純なタイプミスや論理の漏れが大幅に減少する。

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

コメント

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