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["最終出力"]
設計:LLMに「即座にコードを書くこと」を禁じ、まず現象を分析させる制約を課す。
実行:CoT(Chain-of-Thought)を用いて、原因、仮説、検証、実装の順に出力させる。
評価: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つの鉄則:
「即時回答」を禁止する:
Wait and ThinkやAnalyze before codingという明示的な指示が、コードの質を劇的に変える。型を定義する:思考プロセスはMarkdown、メタデータ(影響度など)はJSONと分けることで、後続の自動化パイプラインに組み込みやすくする。
自己検品(Self-Verification)を組み込む:プロンプトの最後に「自分で自分のコードをレビューせよ」というステップを加えるだけで、単純なタイプミスや論理の漏れが大幅に減少する。
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月20日
- 削除記事本文の冒頭に残存していた内部メタデータのプレースホルダーを削除しました。

