CoT（思考の連鎖）を活用した複雑なロジックのデバッグとリファクタリングの最適化手法

Tech

role: プロンプトエンジニアリング・スペシャリスト tone: 技術的かつ実用的、簡潔な構造 format: Markdown + Mermaid focus: CoT (Chain-of-Thought), 構造化出力, プログラミング支援

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

CoT（思考の連鎖）を活用した複雑なロジックのデバッグとリファクタリングの最適化手法

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

複雑な依存関係を持つ関数のバグ特定とリファクタリングにおいて、推論過程を可視化し、副作用を最小限に抑えた修正コードをJSON形式で生成します。

  • 入力形式: Markdown（ソースコード + エラーログ）

  • 出力形式: 構造化JSON（思考プロセス + 修正コード + テストケース）

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

graph TD
A["設計: 思考ステップの定義"] --> B["実行: Zero-shot CoTの投入"]
B --> C["評価: 推論の論理整合性と構文確認"]
C -->|改善: Few-shotによる具体例追加| A

  1. 設計: LLMに「まずコードを解釈し、次に問題を特定し、最後に修正案を出す」というステップを明示します。

  2. 実行: Gemini 1.5 Proなどの長文コンテキストモデルに対し、バグを含むコードを提示します。

  3. 評価: 出力された「思考プロセス」が実際のバグと整合しているか、生成されたコードが構文的に正しいかを検証します。

  4. 改善: 推論が飛躍する場合は、類似のデバッグ事例をFew-shotとして追加します。

【プロンプトの実装案】

# Role

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

# Task

以下の手順に従って思考し、最終的な結果をJSON形式で出力してください。

1. **コード解析**: 提供された関数の役割、入力、出力を整理してください。

2. **原因特定**: エラーログや挙動の不一致から、論理的な欠陥を1ステップずつ特定してください。

3. **影響範囲の確認**: 修正によって破壊される可能性がある既存機能をリストアップしてください。

4. **修正案の生成**: バグを修正しつつ、可読性とパフォーマンスを向上させたコードを作成してください。

# Constraints


- 出力は必ず以下のJSONスキーマに従うこと。

- `thought_process` フィールドには、各手順での考察を詳細に記述すること。

# Input


- Code: 
```javascript
function calculateDiscount(price, type) {
  if (type = "VIP") {
    return price * 0.8;
  } else {
    return price;
  }
}
  • Error: typeが”Standard”でも20%引きになってしまう。

Output JSON Structure

{ “thought_process”: “…”, “identified_bug”: “…”, “fixed_code”: “…”, “test_cases”: [] }

### 【評価指標と誤り分析】

LLMは時として「思考プロセス（thought_process）」では正解を導き出しながら、最終的な「コード（fixed_code）」で単純なタイポをしたり、既存の変数を上書きしたりする「出力の不整合」を起こします。

| 評価項目 | 採点基準 (1-5) | 失敗パターン |
| :--- | :--- | :--- |
| **論理整合性** | 思考とコードが一致しているか | 思考では代入演算子のミスを指摘しながら、コードでも `=` を使ってしまう。 |
| **構文の正確性** | そのまま実行可能なコードか | 閉じカッコの欠落、存在しないライブラリのインポート。 |
| **副作用の最小化** | 既存ロジックを破壊していないか | 全く関係のない関数のシグネチャを変更してしまう。 |

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

分析結果に基づき、**「自己検閲（Self-Correction）」**のステップを追加した最終プロンプトです。

```text

# System

あなたはプログラミングのデバッグに特化したエージェントです。CoT（Chain-of-Thought）を用いて、思考の跡をすべて開示してください。

# Step-by-Step Instructions

Step 1. [ANALYZE]: コードの動作原理を日本語で説明せよ。
Step 2. [DEBUG]: 発生しているバグの根本原因を特定せよ（特に比較演算子、型変換、スコープに注目）。
Step 3. [VERIFY]: 修正案を提示する前に、その修正が他の箇所に悪影響を与えないか自己検閲せよ。
Step 4. [OUTPUT]: 以下のJSONフォーマットで出力せよ。

# Format

{
  "analysis": "...",
  "bug_cause": "...",
  "verification_result": "Self-correction memo...",
  "fixed_code": "...",
  "explanation": "..."
}

# Input

[ここにコードを貼り付け]

【まとめ】

  1. 思考の強制（Explicit Thought）: LLMに「いきなりコードを書かず、まず分析せよ」と命じることで、論理的飛躍を防ぐ。

  2. 構造化の徹底（Schema Enforcement）: JSONスキーマを指定することで、後続の自動テストやCI/CDパイプラインとの連携を容易にする。

  3. 自己検閲の組み込み（Self-Correction）: 修正案を生成した直後に「本当にこれで正しいか？」と再考させるステップを入れることで、単純なミスを激減させる。

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

コメント

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