LLMチェイニング（エルエルエムチェイニング）

LLMチェイニングとは

LLMチェイニングは、1回のLLM呼び出しでは十分な品質が得られないタスクを、複数の小さなステップに分解し、各ステップの出力を次のステップの入力として連鎖させる手法である。「大きな問題を小さな問題に分解する」というソフトウェア工学の原則をLLM活用に適用したものといえる。

なぜチェイニングが必要か

単一のLLM呼び出しには以下の限界がある。

代表的なチェイニングパターン

シーケンシャルチェイン

最も基本的なパターンで、Step A → Step B → Step C の順に実行する。各ステップは独立したプロンプトを持ち、前ステップの出力が次ステップのコンテキストに注入される。

例: 記事生成チェイン

1. Step 1（アウトライン生成）: トピックからH2/H3の構成を生成
2. Step 2（各セクション執筆）: アウトラインの各H2について詳細な本文を生成
3. Step 3（統合・校正）: 全セクションを統合し、一貫性・重複をチェック
4. Step 4（メタデータ生成）: タイトル・description・FAQ を生成

マップ-リデュースチェイン

大量のデータを処理する際に、まず個別に処理（マップ）してから結果を統合（リデュース）するパターン。100ページの報告書を要約する場合、10ページずつ個別要約（マップ）→10個の要約を統合要約（リデュース）する。LangChainのMapReduceDocumentsChainがこのパターンを標準化している。

リファインチェイン

初期出力を段階的に改善していくパターン。まず粗い回答を生成し、追加情報を1つずつ組み込みながら回答を洗練させる。マップ-リデュースと異なり各ステップが前ステップの結果を引き継ぐため、文脈の連続性が保たれやすい。ただし逐次実行のため並列化できず、処理時間は長くなる。

自己改善チェイン

生成→評価→改善のループを繰り返すパターン。Step 1でコードを生成し、Step 2で別のLLM呼び出しがバグを指摘し、Step 3で指摘を反映した修正版を生成する。Constitutional AIの手法を応用した自己批判チェインとも呼ばれる。

チェイニングの実装上の注意

トークンコストの増大

N段のチェインではN回のLLM呼び出しが発生し、前段の出力が次段のコンテキストに含まれるためトークン消費が累積的に増加する。5段チェインで各段の入出力が2,000トークンの場合、総トークン消費は単純計算で2,000+4,000+6,000+8,000+10,000=30,000トークンとなり、単一呼び出しの15倍のコストがかかる可能性がある。

エラー伝搬

前段のエラーが後段に波及する「ガベージイン・ガベージアウト」問題がある。各段の出力にバリデーションを入れ、異常検知時に早期終了するサーキットブレーカーの実装が推奨される。

レイテンシの累積

逐次実行では各段のレイテンシが累積するため、5段チェインで各段2秒なら合計10秒の応答時間になる。ユーザー向けアプリケーションでは中間結果をストリーミングで表示し、体感待ち時間を短縮する工夫が必要。

チェイニング vs 単一プロンプト

Claude 4 OpusやGPT-4oクラスの高性能モデルでは、チェイニングせずとも複雑なタスクをこなせるケースが増えている。チェイニングが効果的かどうかは実験で検証すべきであり、「とりあえずチェインする」アプローチは過剰設計（Over-engineering）になりやすい。まず単一プロンプトで試し、品質が不十分な場合にのみチェイニングを導入するのが現実的である。

FAQ

Q1: チェインの段数はどの程度が適切ですか？

2〜5段が一般的。7段以上になるとデバッグが困難になり、コスト・レイテンシも実用的でなくなる。段数が増えすぎる場合はタスクの再定義（スコープの縮小）を検討すべき。

Q2: チェイン内で異なるモデルを使い分けるべきですか？

コスト最適化の観点では推奨。構造化出力の整形やバリデーションにはHaiku 4.5（低コスト・高速）、核心的な推論にはOpus 4（高精度）を使い分けることで、品質を維持しながらコストを50-70%削減できるケースがある。

Q3: チェインの途中結果を保存する必要はありますか？

デバッグとリトライのために保存を推奨。中間結果をDBやファイルに永続化しておけば、特定のステップから再実行できるため、障害発生時の復旧が容易になる。Langfuseなどのトレーシングツールで自動記録するのが最も手軽。