<p><meta/>
{“version”: “1.1”, “focus”: “CoT-driven-Debugging”, “methodology”: “Step-by-step logic decomposition”}
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">CoTによるロジック分解：バグ特定精度を最大化するデバッグ支援プロンプト</h1>
<p>【ユースケース定義と課題】
複雑な依存関係を持つコードの論理エラーを特定・修正する。
課題：LLMが即座に修正案を出し、原因の誤認やデグレを引き起こす点。
入出力：[Input] ソースコード + エラーログ / [Output] 思考プロセス + 修正Diff (Markdown形式)</p>
<p>【プロンプト設計のループ】</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
graph TD
A["設計: 思考ステップの明示化"] --> B["実行: Zero-shot CoTでの出力"]
B --> C["評価: 修正の正確性と破壊的変更の有無"]
C -->|改善: Few-shotでの推論パターン追加| A
</pre></div>
<ol class="wp-block-list">
<li><p><strong>設計</strong>: LLMに対し、修正コードを書く前に「現状分析」「仮説構築」「検証」のステップを強制します。</p></li>
<li><p><strong>実行</strong>: 実際のバグを含むコードを投入し、思考プロセスの質を確認します。</p></li>
<li><p><strong>評価</strong>: 生成されたコードがシンタックスエラーを含まないか、既存機能を壊していないかを検証します。</p></li>
</ol>
<p>【プロンプトの実装案】</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># 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
</pre>
</div>
<h1 class="wp-block-heading">Input Data</h1>
<p>Code:
{{PASTE_YOUR_CODE_HERE}}</p>
<p>Error Log:
{{PASTE_ERROR_LOG_HERE}}</p>
<pre data-enlighter-language="generic">
【評価指標と誤り分析】
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
...
</pre>
<p>“`</p>
<p>【まとめ】</p>
<ol class="wp-block-list">
<li><p><strong>「書く前に考えさせる」を徹底する</strong>: <code>Step-by-step</code>指示だけでなく、具体的な思考の切り口（データフロー、異常系等）を指定する。</p></li>
<li><p><strong>出力フォーマットを固定する</strong>: <code>## Analysis</code> などの見出しを強制することで、LLMの推論リソースを構造化された思考に割り振らせる。</p></li>
<li><p><strong>Few-shotで粒度を教える</strong>: どの程度の修正範囲を求めているかを例示し、過剰なリファクタリングを抑制する。</p></li>
</ol>
{“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で粒度を教える: どの程度の修正範囲を求めているかを例示し、過剰なリファクタリングを抑制する。
ライセンス：本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。
コメント