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

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

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

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

本記事は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)を組み込む:プロンプトの最後に「自分で自分のコードをレビューせよ」というステップを加えるだけで、単純なタイプミスや論理の漏れが大幅に減少する。

この記事の更新履歴

この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。

2026年9月20日

  • 削除記事本文の冒頭に残存していた内部メタデータのプレースホルダーを削除しました。

文書情報

記事タイトル
CoT(思考の連鎖)を用いた複雑なプログラムバグの構造的修正手法
作成日
更新日
Source URL
https://papanda925.com/?p=6398

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

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