CoTを活用したプログラミング支援：論理バグを根絶する思考プロセス型プロンプト

Tech

{ “template_version”: “1.2”, “optimization_target”: “Programming Assistance / CoT”, “llm_engine”: “Gemini 1.5 Pro / GPT-4o”, “status”: “Draft / Experimental” }

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

CoTを活用したプログラミング支援：論理バグを根絶する思考プロセス型プロンプト

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

複雑なコードの論理バグに対し、思考プロセスを明示させることで修正の妥当性と精度を向上させるタスク。入出力はMarkdown形式。

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

graph TD
A["設計: 思考ステップの構造化"] --> B["実行: コード解析と修正案生成"]
B --> C["評価: 修正の正確性と退行テスト"]
C -->|改善: 制約条件の追加| A

  1. 設計: LLMに対し、コードの挙動理解、バグ原因の特定、修正方針の策定を順序立てて行うよう指示。

  2. 実行: 入力されたソースコードとエラーログを基に、内部的な推論（Chain-of-Thought）を経てコードを出力。

  3. 評価: 修正後のコードが元の仕様を満たしているか、新たなバグを生んでいないかをLLM-as-a-Judgeで検証。

【プロンプトの実装案】

# Role

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

# Task

以下の手順（Chain-of-Thought）に従って思考し、最終的な修正コードを出力してください。

## Step 1: コードの挙動分析

提供されたコードが本来何を目的としているのか、現在の実装はどうなっているのかを整理してください。

## Step 2: バグの特定と根本原因の推定

エラーメッセージや期待値との乖離から、どの行にどのような論理的誤りがあるのかを特定してください。

## Step 3: 修正プランの策定

修正による副作用（サイドエフェクト）を最小限に抑えるための修正方針を立ててください。

## Step 4: 実装と検証

修正後のコードを提示し、なぜその修正でバグが解決するのかを論理的に説明してください。

# Input Data


- Code Snippet:
{{CODE}}

- Error Message / Symptom:
{{ERROR}}

# Output Format

Markdown形式で、各ステップの思考プロセスを「###」の見出しで記述し、最後に「### 修正済みコード」としてコードブロックを出力してください。

【評価指標と誤り分析】

評価項目 評価内容 失敗パターン（例） 改善策
論理整合性 思考ステップと修正コードが一致しているか 思考ではAと言いつつBを実装する 思考内容の要約を実装前に自己確認させる
コードの完全性 必要なインポートや変数が欠落していないか 関数の一部だけを出力して動かない 「完結したコードを出力せよ」と明示
ハルシネーション 存在しないライブラリやAPIを使用していないか 最新版にないメソッドを捏造する 公式ドキュメントのURLをコンテキストに含める

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

# Role: Expert Debugging Assistant (CoT Optimized)

# Instructions:

以下のXMLタグ形式のステップに従って、論理的思考プロセスを「言語化」しながら回答してください。

<thought_process>

1. [Analysis]: コードのデータフローと期待される仕様の定義。

2. [Bug_Isolation]: エラーの原因となっている具体的な行と条件の特定。

3. [Impact_Assessment]: 修正が他のコンポーネントに与える影響の予測。

4. [Fix_Strategy]: 修正のための擬似コード作成。
</thought_process>

# Constraints:


- 修正コードは、コピペでそのまま動作する完全な状態で出力すること。

- 修正箇所には必ずコメントで「FIXED: [理由]」を追記すること。

- 不要な解説は省き、技術的な妥当性に集中すること。

# Input:


- Source: {{CODE}}

- Context: {{CONTEXT}}

# Output:

<thought>
(ここに思考プロセスを記述)
</thought>

### 修正済みコード

```python
(ここに修正コードを記述)

“`

【まとめ】

  1. 思考の「外出し」: thoughtタグなどを用いて、LLMに「答えを出す前に考えさせる」ことが、複雑なバグ修正では不可欠。

  2. 文脈の具体化: 単なるエラー文だけでなく、期待される挙動（期待値）を明確に与えることで、論理のブレを防ぐ。

  3. 完全性の要求: 差分（diff）だけではなく、常に実行可能な「完全なコードブロック」を出力させることで、ユーザーの工数を削減する。

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

コメント

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