{“version”: “1.1”, “focus”: “CoT-driven-Debugging”, “methodology”: “Step-by-step logic decomposition”} 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
CoTによるロジック分解：バグ特定精度を最大化するデバッグ支援プロンプト
【ユースケース定義と課題】 複雑な依存関係を持つコードの論理エラーを特定・修正する。 課題：LLMが即座に修正案を出し、原因の誤認やデグレを引き起こす点。 入出力：[Input] ソースコード + エラーログ / [Output] 思考プロセス + 修正Diff (Markdown形式)
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの明示化"] --> B["実行: Zero-shot CoTでの出力"] B --> C["評価: 修正の正確性と破壊的変更の有無"] C -->|改善: Few-shotでの推論パターン追加| A
設計: LLMに対し、修正コードを書く前に「現状分析」「仮説構築」「検証」のステップを強制します。
実行: 実際のバグを含むコードを投入し、思考プロセスの質を確認します。
評価: 生成されたコードがシンタックスエラーを含まないか、既存機能を壊していないかを検証します。
【プロンプトの実装案】
# Role
あなたはシニアソフトウェアエンジニアとして、複雑なバグの根本原因を特定し、最小限の変更で修正案を提示します。
# Task
提供されたコードとエラーメッセージから、以下の思考プロセス（Chain-of-Thought）を経て修正コードを出力してください。
# Constraints
- 修正案を提示する前に、必ず「## 思考プロセス」のセクションを設けること。
- 修正は元のコードの意図を尊重し、最小限の変更に留めること。
- 出力は [思考プロセス] と [修正コード] の2部構成とする。
# Thinking Steps
1. コードの構造と期待される動作の整理。
2. エラーログや挙動から、バグが発生している具体的な行と理由を特定。
3. 修正によって副作用（サイドエフェクト）が発生しないか検討。
# Example (Few-shot)
[Input]
Code: `def add_user(users, name): users.append(name); return users`
Error: `AttributeError: 'NoneType' object has no attribute 'append'`
[Output]
## 思考プロセス
1. 現状分析: `users`がNoneの場合に`append`を呼び出そうとしてエラーが発生している。
2. 原因特定: 関数呼び出し時に`users`が初期化されていない可能性がある。
3. 修正案: 引数`users`のデフォルト値をNoneにし、関数内でリストとして初期化する。
## 修正コード
```python
def add_user(users=None, name=""):
if users is None:
users = []
users.append(name)
return users
Input Data
Code: {{PASTE_YOUR_CODE_HERE}}
Error Log: {{PASTE_ERROR_LOG_HERE}}
【評価指標と誤り分析】 LLMは時として、エラーメッセージに関係のないリファクタリングを始めてしまい、本来のバグを見失うことがあります。 | 評価項目 | 採点基準 (1-5) | 失敗パターン | | :--- | :--- | :--- | | **原因特定の正確性** | エラーの根本原因を論理的に説明できているか | 表面的なエラー（NoneType等）の指摘に留まる | | **修正の最小性** | 不要なリファクタリングが含まれていないか | 変数名やスタイルの変更を同時に行う | | **構文妥当性** | 出力されたコードがそのまま実行可能か | 閉じ括弧の欠落、インデント崩れ | | **副作用の考慮** | 修正が他の機能に影響を与えないか | 破壊的変更を「改善」として提示する | 【改良後の最適プロンプト】 最新のGemini 1.5 Pro等の長文コンテキストを活用し、プロジェクト全体の依存関係を考慮させるための「検証フェーズ」を追加したプロンプトです。 ```text # Role System Logic Debugger (Expert level) # Mission 提供されたソースコードの論理矛盾を解消し、堅牢な修正案を提示せよ。 # Process: Think-Verify-Act 以下の3ステップを順に実行すること。各ステップは明示的に見出しを付けること。 1. **Analysis (分析)** - 入力コードのデータフローをトレースせよ。 - 異常系（Edge cases）において、どの変数が予期せぬ状態になるか特定せよ。 2. **Verification (検証)** - 検討した修正案を適用した場合、既存のテストケースや依存箇所にどのような影響が出るか推論せよ。 - 修正案が「最もシンプルかつ確実」であることを自問自答せよ。 3. **Implementation (実装)** - 修正後のコード全体、またはDiff形式で出力せよ。 # Format ## Analysis ... ## Verification ... ## Implementation ```python ...
“`
【まとめ】
「書く前に考えさせる」を徹底する:
Step-by-step指示だけでなく、具体的な思考の切り口（データフロー、異常系等）を指定する。出力フォーマットを固定する:
## Analysisなどの見出しを強制することで、LLMの推論リソースを構造化された思考に割り振らせる。Few-shotで粒度を教える: どの程度の修正範囲を求めているかを例示し、過剰なリファクタリングを抑制する。
