{ “research”: [ “CoT (Chain-of-Thought) for Programming: 論文『Chain-of-Thought Prompting Elicits Reasoning in Large Language Models』に基づき、複雑なロジック修正における中間推論ステップの重要性を確認。特にバグ修正では『現状分析→原因特定→修正案作成→検証』のプロセスを明示的に踏ませることで、Gemini 1.5 Pro等の長文コンテキストモデルでの精度が大幅に向上する。”, “Self-Refine/ReAct: コード生成後にLLM自身に実行シミュレーション（ドライラン）を行わせることで、論理的欠陥を自己修正させるアプローチを採用。” ], “plan”: [ “1. 課題定義: 表面的な修正（ハルシネーション）を防ぎ、根本原因を叩くための構造化プロンプトの設計。”, “2. 実装案: 思考の足場（Scaffolding）を提供するタグベースのCoTプロンプトを提示。”, “3. 評価指標: 修正の正確性、計算量の変化、既存機能の破壊有無をLLMにクロスチェックさせる仕組み。”, “4. 最終プロンプト: 最新モデルの命令追従性を最大化するSystem/User構成案。” ] }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
CoT（思考の連鎖）を用いた複雑なプログラム・バグ修正の最適化プロンプト
【ユースケース定義と課題】
定義： 複数モジュールにまたがる論理バグの特定と、副作用を最小限に抑えたコード修正。
課題： LLMがコードの「見た目」だけで判断し、エッジケースを見落としたり、修正によって別のバグ（デグレ）を生む「場当たり的な修正」を回避するのが難しい点。
入出力： Markdown形式（思考プロセス：<thought> + 修正コード：```）。
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの言語化"] --> B["実行: Gemini 1.5 Proでの推論"] B --> C["評価: テストケース合致・計算量評価"] C -->|修正不足・冗長| A
設計: 修正案を出す前に「変数のトレース」と「エッジケースの検証」を強制する手順を定義。
実行: システムプロンプトにより、回答の冒頭で必ず「なぜそのバグが起きたか」を分析させる。
評価: 修正後のコードが制約を満たしているか、LLM-as-a-Judgeで再評価し、不足があればループを回す。
【プロンプトの実装案】
# Role
あなたは、Google DeepMindのシニアソフトウェアエンジニアであり、バグ修正のスペシャリストです。
# Task
提供されたコードとエラーレポート（または期待される挙動）に基づき、以下のステップで修正案を作成してください。
# Constraints
- 回答は必ず `<thought>` タグ内で思考プロセスを記述してから、最終的なコードを提示すること。
- コード修正は、パフォーマンスと可読性のバランスを考慮すること。
- 修正箇所だけでなく、なぜその修正が必要なのかを論理的に説明すること。
# Step-by-step Reasoning (CoT)
1. **現状分析**: コードの現在の挙動と、発生している問題の根本原因を特定する。
2. **トレース**: 特定の入力値（エッジケース含む）に対する変数の変化をシミュレートする。
3. **修正方針**: 修正による影響範囲を特定し、最適なアプローチを決定する。
4. **検証**: 修正後のコードが期待通りに動作し、副作用がないことを論理的に確認する。
# Example
Input Code:
```python
def get_average(numbers):
return sum(numbers) / len(numbers)
Error: ZeroDivisionError: division by zero
現状分析: numbersが空リストの場合、len(numbers)が0になり、ゼロ除算が発生する。
トレース: get_average([]) -> len([]) is 0 -> sum([]) / 0 -> Error.
修正方針: リストが空の場合のデフォルト値（0やNone）を返すガード節を追加する。
検証: 空リストなら0、値があれば平均を返す。安全。 (以下、修正コード)
### 【評価指標と誤り分析】 | 評価項目 | 期待される挙動 | 失敗パターン（要改善） | | :--- | :--- | :--- | | **推論の論理性** | `<thought>`内でバグの真因を指摘 | 症状の記述のみで原因分析が欠落 | | **コードの正確性** | 文法エラーがなく、課題を解決 | 修正箇所が不完全、または動作しない | | **副作用の有無** | 既存機能のロジックを破壊していない | バグは直ったが別のエラーが発生する | | **形式遵守** | タグ構造が維持されている | `<thought>`を飛ばしてコードだけ出す | ### 【改良後の最適プロンプト】 Gemini 1.5 Proの長い文脈理解能力と、構造化された思考を最大限に引き出す決定版プロンプトです。 ```text # Role: Senior Logic Architect あなたは、コードの静的解析とランタイムデバッグにおいて比類なき能力を持つエキスパートです。 # Mission ユーザーから提示された「問題のあるコード」を、論理的な思考ステップを経て、堅牢で効率的なコードへ昇華させてください。 # Instructions: The "Logical-Chain" Method 回答は必ず以下の構造に従ってください。 ## 1. Internal Reasoning (in <thought> tags) 回答の最初に、以下の4点を詳細に分析してください： - **Bug Root Cause**: 表面的なエラーではなく、論理の破綻箇所を特定。 - **Flow Simulation**: 正常系・異常系それぞれのデータフローを脳内でシミュレート。 - **Side Effect Assessment**: この修正が呼び出し元や他のモジュールに与える影響。 - **Optimization Check**: 時間/空間計算量を改善する余地があるか。 ## 2. Refactored Code - 修正後のコードを Markdown 形式で提示。 - コメントで重要な変更意図を記述。 ## 3. Test Cases (Recommended) - 修正を検証するためのテストコード（Unit Test）を最低2ケース提示。 # Input Data [対象コードをここに貼り付け] [エラーログや期待する挙動をここに貼り付け]
【まとめ】
実務でプロンプトを運用するための3つの鉄則：
「思考の分離」を強制する: 回答の冒頭に
<thought>タグ（あるいは「まず分析して」という指示）を置くことで、LLMの「早とちり」を防ぎ、論理的整合性を高める。トレース（ドライラン）を指示する: LLMに「変数の値をステップごとに追え」と命じることで、複雑なループや再帰のバグ発見率が飛躍的に向上する。
評価者（Judge）として別スレッドを立てる: 修正案が出た後、別のLLMプロンプト（または新しいセッション）で「この修正に脆弱性はないか？」と批判的にレビューさせる二段構えが最も安全である。
コメント