プロンプトチェーニングで複雑業務を段階的に自動化する方法

結論

プロンプトチェーニングは、複雑なタスクを「分析→判断→実行→検証」のように複数のステップに分割し、前のステップの出力を次のステップの入力として連結する設計です。1つの巨大なプロンプトで全てを処理しようとするより、各ステップを専門化することで精度と制御性が大幅に上がります。

「全ファイルを一度にレビューする」と「ファイルごとにレビューして最後に統合する」では、後者の方が見落としが少なくなります。この原理がプロンプトチェーニングの核心です。

---

なぜ1ステップで全部やると精度が落ちるのか

複数の異なる作業を1つのプロンプトで依頼すると、Claudeはそれぞれに集中できなくなります。

例えば「14ファイルのコードを全部チェックしてセキュリティ問題・バグ・コーディング規約違反・パフォーマンス問題を全て報告してください」という指示では、次の問題が起きます。

• ファイルが増えるほど後半のファイルへの注意が薄れる（注意力の希薄化）
• セキュリティとパフォーマンスのような異なる視点が混在して、どちらも中途半端になる
• あるファイルで問題として指摘したパターンを、別のファイルでは見逃す矛盾が起きる

14ファイルを一度にレビューした結果、詳細なフィードバックがあるファイルと表面的なコメントしかないファイルが混在し、同じパターンが一方では問題・他方では許容されるという矛盾が生じます。

---

2種類のチェーニングパターン

パターン1: 固定逐次パイプライン

あらかじめ決まった順序でステップを実行します。各ステップが何をするかが事前にわかっていて、順序が変わらない業務に適しています。

ステップ1: ファイルA〜Nをそれぞれ個別にレビュー（ローカル問題を検出）
    ↓ 各ファイルの問題リストを受け取る
ステップ2: 全ファイルの問題リストを統合して、クロスファイルの依存問題を分析
    ↓ 統合レポートを受け取る
ステップ3: 重複を排除して優先度付きの最終レポートを生成

固定逐次パイプラインが適しているケース：

• コードレビュー（ファイル別→統合の流れが一定）
• 多言語文書の翻訳→校正→品質チェック
• データ抽出→バリデーション→フォーマット変換

パターン2: 動的適応分解

最初のステップの結果に応じて、次のステップを動的に決める設計です。「調べてみないと何をすべきかわからない」ようなオープンな調査タスクに適しています。

ステップ1: コードベースをスキャンして問題のある領域を特定
    ↓ 「支払い処理・認証・ログ出力の3領域に集中すべき」という発見
ステップ2: 3領域それぞれを詳しく調査（ステップ1の結果によって生成）
    ↓ 各領域の詳細問題リスト
ステップ3: 各問題の修正案を優先度順に作成

動的分解が適しているケース：

• 「このコードベースに包括的なテストを追加する」のような開放的タスク
• 調査の結果によって方向性が変わるリサーチ
• 初見のシステムの問題調査

---

コードレビューへの実践的な適用

コードレビューはプロンプトチェーニングの効果が特に出やすい業務です。

ステップ1: ファイル別ローカルレビュー

各ファイルへのプロンプト（14回繰り返す）:

「{filename}をレビューしてください。
確認項目:
- SQLインジェクション・XSSなどのセキュリティ問題
- 未処理の例外・エラーハンドリングの漏れ
- このファイル内での明らかなバグ

各問題を次の形式で返してください:
{
  "file": "ファイル名",
  "line": 行番号,
  "severity": "critical/high/medium",
  "issue": "問題の説明",
  "fix": "推奨する修正"
}」

ステップ2: クロスファイル統合レビュー

統合プロンプト:

「以下は各ファイルのレビュー結果です:
[ステップ1の14件の結果を全て含める]

このデータをもとに次を分析してください:
1. ファイルAで問題として指摘したパターンが、ファイルBでは見逃されていないか
2. 複数ファイルにまたがるデータフローの問題（A→B→Cという依存関係で生じる問題）
3. ステップ1で見つかった問題の中で、優先度を上げるべきものはあるか」

ステップ3: 最終レポート生成

「上記の分析結果を開発者向けレポートとして整理してください。
優先度順に並べ、各問題に修正手順を付けてください。
重複する指摘は統合してください。」

この3ステップの分割により、単一パスに比べてクリティカルな問題の発見率が上がります。

---

ステップ間のデータ受け渡し設計

チェーンの品質は「前のステップの出力をどう次のステップに渡すか」で決まります。

生テキストをそのまま渡す（問題あり）

ステップ1の出力（自由記述）:
「auth.tsファイルを確認しました。L45でトークン検証が甘く、
L78では例外が握りつぶされています。また、L102のコードは
パフォーマンス上の懸念があります...」

ステップ2の入力: このテキストをそのまま貼り付ける

問題：次のステップがどの部分を参照すべきか判断しにくく、詳細が埋もれます。

構造化データで渡す（推奨）

{
  "file": "auth.ts",
  "issues": [
    {"line": 45, "severity": "critical", "category": "security", "issue": "JWTトークンの署名検証がない"},
    {"line": 78, "severity": "high", "category": "error_handling", "issue": "catch節が空（例外を握りつぶしている）"},
    {"line": 102, "severity": "medium", "category": "performance", "issue": "ループ内でDB呼び出し"}
  ]
}

構造化データで渡すと、次のステップが「criticalだけ抽出」「security問題だけ集計」のような操作を正確に行えます。

構造化データの設計についてはClaudeのJSONスキーマ構造化出力で詳しく解説しています。

---

文書処理パイプラインの設計例

業務文書を処理するパイプラインも、プロンプトチェーニングが効果的な領域です。

大量の契約書を処理するパイプライン

ステップ1: 契約書の種別と構造を識別
  入力: 生のPDFテキスト
  出力: {"type": "NDA", "parties": 2, "jurisdiction": "日本法"}

ステップ2: 種別に応じた専用スキーマで情報抽出
  入力: 生テキスト + ステップ1の種別情報
  出力: NDA専用の構造化フィールド（秘密情報の定義・期間・罰則条項）

ステップ3: 抽出結果の検証と異常値チェック
  入力: ステップ2の抽出結果
  出力: バリデーション結果（期間が論理的か・金額の整合性など）

ステップ4: データベース登録用フォーマットに変換
  入力: 検証済みデータ
  出力: システム連携用JSON

各ステップで前のステップの出力を受け取り、そのステップに特化した処理だけを行います。1ステップで全て行うより、各ステップが明確な責任を持ちます。

---

エラーハンドリングとリトライ設計

チェーンの途中でステップが失敗した場合の設計も重要です。

各ステップで出力を検証する

def run_chain(document):
    # ステップ1
    step1_result = claude.extract_metadata(document)
    if not validate_step1(step1_result):
        step1_result = claude.extract_metadata(document, retry=True)  # 失敗したステップだけリトライ
    
    # ステップ2（ステップ1が成功した場合のみ進む）
    step2_result = claude.extract_content(document, metadata=step1_result)
    ...

失敗したステップだけをリトライすることで、成功済みのステップの処理コストを無駄にしません。

チェーンを途中から再開する

長いチェーンで途中のステップまで完了している場合、最初からやり直すのは非効率です。各ステップの結果を中間ファイルに保存し、失敗した箇所から再開できるようにします。

---

プロンプトチェーニングと動的分解の選び方

判断基準	プロンプトチェーニング（固定）	動的分解
手順の予測可能性	事前に手順が決まっている	調査結果によって手順が変わる
タスクの性質	明確な作業ステップがある	探索的・調査的
エラー対処	ステップごとにリトライしやすい	柔軟だが制御が複雑
設計コスト	低い	高い

ほとんどの定型業務（文書処理・コードレビュー・レポート生成）は固定チェーニングで対応できます。動的分解が必要になるのは、「調べてみないと何をすべきかわからない」開放的な調査タスクです。

動的に判断するエージェント設計についてはマルチエージェント設計の実践パターンで詳しく解説しています。

---

まとめ

プロンプトチェーニングの実践ポイントをまとめます。

• 複雑な業務は「分析→判断→実行→検証」のように専門化されたステップに分割する
• 固定逐次パイプラインは手順が決まっている業務に、動的分解は探索的タスクに使う
• ステップ間は構造化データで受け渡し、自由記述のテキストをそのまま流用しない
• 各ステップで出力を検証してから次のステップに進み、失敗したステップだけリトライする
• コードレビューは「ファイル別→統合→レポート」の3段階に分けると精度が上がる

この設計を身につけることで、単一プロンプトでは精度が出なかった複雑な業務を、段階的かつ確実に自動化できます。