CoTによる複雑な非同期処理バグの段階的特定と自動修正プロンプト

Tech

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

CoTによる複雑な非同期処理バグの段階的特定と自動修正プロンプト

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

  • 対象タスク：非同期処理（Promise/async-await）や競合状態（Race Condition）に起因する複雑な挙動バグの特定と修正。

  • 課題：LLMがコードの表面的な整合性のみを判断し、実行コンテキストや非同期の実行順序を無視した誤修正を出力しやすい点。

  • 入出力の型：

    • 入力：バグのあるソースコード、発生しているエラーログまたは期待する挙動（Markdown記述）。

    • 出力：原因分析、修正方針、修正コード（JSONフォーマット：{"analysis": "...", "strategy": "...", "fixed_code": "..."}）。

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

graph TD
    A["設計: 段階的思考プロンプトの構築"] --> B["実行: バグコードの解析と修正案出力"]
    B --> C["評価: 修正コードの動作検証とLLM自己評価"]
    C -->|分析結果をプロンプトにフィードバック| A

  • 設計：思考プロセス（Chain-of-Thought）を強制的に踏ませるステップ（静的解析、実行フロー追跡、仮説検証）を定義します。

  • 実行：設計したプロンプトを最新のLLMに投入し、出力JSONのパース可否と修正精度を確認します。

  • 評価：LLM-as-a-Judgeを用いて、提示された修正方針の妥当性とコードの正確性を自動判定します。

【プロンプトの実装案】

# 命令書

あなたは極めて優秀なシニアソフトウェアエンジニアです。
提供されたバグを含むコードを分析し、以下のステップ（Chain-of-Thought）に従って、発生している非同期バグの原因特定と修正コードの生成を行ってください。

# 思考ステップ


1. [コード理解]: 提供されたコードの全体的な役割と、非同期処理の流れを1行ずつ整理してください。

2. [バグの再現ストーリー]: どのようなイベントシーケンスが発生したときにバグ（競合状態、未処理のPromise等）が顕在化するか、時系列で説明してください。

3. [仮説検証]: バグを引き起こしている直接的な原因箇所（数行）を特定し、なぜそれが誤りなのか論理的に説明してください。

4. [修正方針策定]: 最も堅牢で、かつ副作用の少ない修正アプローチを決定してください。

# 制約事項


- 出力は必ず以下のJSONフォーマットのみとしてください。他の挨拶や余分なテキストは一切含めないでください。

# 出力フォーマット

{
  "thought_process": {
    "code_understanding": "ステップ1の考察",
    "reproduction_story": "ステップ2の考察",
    "hypothesis_verification": "ステップ3の考察",
    "fix_strategy": "ステップ4の考察"
  },
  "fixed_code": "修正後のコード全体（適切なエスケープを行うこと）"
}

# 入力データ

## バグコード

（ここにコードを挿入）

## 発生している問題 / ログ

（ここに問題やログを挿入）

【評価指標と誤り分析】

最新のLLM（Gemini 1.5 ProやGPT-4oなど）は推論能力が向上していますが、以下のような典型的な失敗パターンが存在します。

失敗パターン

  1. フォーマット崩れ：出力フォーマットにJSONを強制しても、説明用のテキストが前後に付着したり、コードブロック内のダブルクォーテーションのエスケープ漏れが発生する。

  2. 「動けば良い」パッチあて：根本的な非同期制御（セマフォや排他制御など）を行わず、setTimeoutによる時間差などの場当たり的な修正を行う。

自動評価（LLM-as-a-Judge）の採点基準

評価項目 評価基準 (5点満点) 採点ポイント
JSON構造の準拠性 パースエラーが発生しない完璧なJSONか JSONパーサーによる検証（必須）
原因特定の論理性 非同期フローのズレを時系列で論理的に説明できているか 思考プロセス内「reproduction_story」の論理整合性
修正の堅牢性 対症療法ではなく、根本的なレースコンディションの解決が行われているか 修正コード内の排他制御や適切なPromiseハンドリング

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

上記の分析を反映し、スキーマの崩れを防ぐために「XMLライクなタグ」で思考プロセスを分離し、最終出力のみをJSONにするように厳格化した最終プロンプトです。

# 命令書

提供されたコードに潜む非同期処理のバグを特定し、修正してください。
出力の堅牢性を高めるため、まずは <thinking> タグ内で段階的に推論を行い、最終結果のみを <output_json> タグ内に構造化データとして出力してください。

# 思考プロセス（<thinking>タグ内で実施すること）


1. コード全体のデータフローと非同期ライフサイクルをマッピングする。

2. 競合状態が発生する具体的なタイムラインをシナリオとして組み立てる。

3. 修正によって他の非同期処理に影響が及ばないか（デッドロック等）をダブルチェックする。

# 出力指示


- 思考プロセスは <thinking> タグで囲んでください。

- 最終的な出力は <output_json> タグで囲み、有効なJSONオブジェクト（キー：analysis, strategy, fixed_code）のみを含めてください。Markdownのコードブロック（```json）はタグ内に記述しないでください。

# 入力データ

## バグコード

（ここにコードを挿入）

## 発生している問題 / ログ

（ここに問題やログを挿入）

【まとめ】

実務でこのプロンプトを運用するための3つの鉄則：

  1. 「思考」と「構造化出力」の分離：LLMに高度な推論と厳密なフォーマット遵守を同時に求めると精度が低下します。<thinking>などのタグを用いて、脳内メモリ（コンテキスト）を整理した後にフォーマット整形させる設計が最重要です。

  2. 時間軸の明示（シナリオ化）：非同期バグの分析時には「どの関数が先に走り、どの時点で割り込みが発生するか」というタイムラインを書き出させる指示（再現ストーリー）が効果的です。

  3. スキーマバリデーションの自動化：LLMの出力を受け取るアプリケーション側で必ずJSONパースエラーのハンドリングを行い、失敗した場合はエラーログを付与して自己修復（Self-Correction）ループに回す仕組みを構築してください。

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

コメント

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