固定パイプラインと適応的な分解

1つのプロンプトでは大きすぎるタスクは、分解して処理します。基本的な戦略は2つあり、適切なものを選ぶことは、アーキテクチャ設計における重要なスキルです。

• 固定パイプライン（prompt chaining）：既知のステップを決まった順序でハードコードします。ステップ1の結果をステップ2に渡し、さらにステップ3へ渡します。
• 適応的分解：モデルが発見した内容に基づいて次の処理を決め、目標を達成するまでループします。

目安は次のとおりです。既知の順次ステップには固定パイプライン、自由度の高い調査には適応的分解を使います。このレッスンでは、その判断基準を明確にします。

固定パイプラインとは、単なる prompt chaining です。独自のコードで、決定論的な一連の処理をオーケストレーションします。ステップを事前に把握しているため、明示的に接続できます。各呼び出しは1つの集中した作業を行い、その出力が次の呼び出しの入力になります。

順序を制御できるため、フローは予測しやすく、デバッグしやすく、理解するためのコストも低くなります。次に何を行うかをモデルが分岐させることはなく、各ステップ内の作業だけを実行します。

作業の形が安定していて既知の場合は、固定パイプラインを選びます。

• 毎回同じステップを実行する（抽出してから検証し、その後フォーマットするなど）。
• 順序が重要で、ほとんど変わらない。
• コスト、レイテンシ、デバッグのしやすさを予測可能にしたい。
• 各段階の責任が明確で限定されている。

典型例は、構造化データの抽出です。フィールドを抽出し、検証と再試行の処理を行い、その後に出典情報を付与します。常にこの3つをこの順序で行うため、チェーンにします。

適応的分解では、計画をモデルに委ねます。ツールと目標を与えると、モデルは結果を調べて次のアクションを選択します。これがエージェント型のループです。リクエストを送信し、stop_reason を確認し、それが tool_use ならツールを実行して結果を履歴に追加し、end_turn になるまで繰り返します。

事前に経路を把握できないため、処理経路をあらかじめ配線することはできません。経路は各ステップで明らかになる内容に依存します。

事前に経路を把握できない自由度の高い調査には、適応的分解を選びます。

• 曖昧な症状からのデバッグ。見つかった内容に基づいて grep、読み取り、使用箇所の grep を行います。
• 追加のクエリが以前の回答に依存する、複数ソースにまたがる調査。
• 検索結果に応じて次のアクションが変わるカスタマーサポート。

ここでは分岐そのものが作業です。固定的なパイプラインでは、経路を見落とすか、保守できない条件分岐が爆発的に増えてしまいます。

試験で最もよくある適応型ループの間違いは、モデルのテキストを調べて「done」や「finished」などの単語が出たらループを終了することです。これはしないでください。判断はモデル主導で行い、API の stop_reason で終了します。

stop_reason が end_turn になるとループは終了します。tool_use の間は処理を続けます。反復回数の上限は安全策にすぎません。主な終了条件にしてはいけません。ハードコードした制御は、作業が概念的に完了したかを判断するためではなく、保証が必要な場合に限定して使います。

実際のシステムでは、両方を組み合わせます。外側のフローは固定されたパイプラインであることが多い一方、1つのステージだけ適応型のエージェントループになる場合があります。これにより、マクロレベルではチェイニングの予測可能性を保ちつつ、本当に必要な部分では柔軟性を得られます。

例として、抽出パイプラインの中央ステージに、適応型の「曖昧さを解消する」エージェントを置く構成があります。このエージェントは、回数を事前に決めずに検索ツールを呼び出す可能性があります。その前後を、決定論的な検証・フォーマット処理のステージで囲みます。

分解は、パイプラインとループのどちらを選ぶかだけの話ではありません。モデルの注意力を守るために、タスクをどのように分割するかも重要です。複数ファイルのコードレビューがその典型です。

多くのファイルを1回でレビューすると、注意が分散し、ファイル単位のバグと統合上の問題の両方を見逃します。解決策は、意図的に分解することです。まずファイルごとのローカルパスを実行し、その後に独立したファイル横断の統合パスを実行します。焦点の定まった2回のパスは、焦点の定まらない1回のパスに勝ります。

ハブアンドスポーク型のマルチエージェントシステムでは、コーディネーターが目標を分解し、サブエージェントに委任してから結果を集約します。これはオーケストレーション層での適応的な分解です。コーディネーターがリクエストに応じて分割方法を決めます。

重要なのは、サブエージェントがコーディネーターの会話履歴を引き継がないことです。各サブエージェントのプロンプトには、完全なコンテキストを明示的に含める必要があります。1つのレスポンス内にある複数のTask呼び出しは並列に実行されます。サブ問題が独立している場合に便利です。

適応的な作業は、複数のセッションにまたがることがよくあります。Claude Code では、名前付きセッションを続行する--resume <name>と、共有地点から分岐して並行して別の案を試すfork_sessionを利用できます。

ただし注意が必要です。コードベースが変更されていると、再開したセッションのツール結果が古くなっている可能性があります。場合によっては、構造化された要約を初期情報として与えた新規セッションのほうが、再開より優れています。古いツール出力を引きずらずに、現在の状態と整理されたコンテキストを得られるためです。

構築する前に、次の点を確認してください。

• 手順を事前に、固定された順序で把握していますか。 -> 固定パイプライン / プロンプトチェイニング。
• 次のステップは、それまでのステップで明らかになった内容に依存しますか。 -> 適応型エージェントループ。
• ほとんどは固定されていますが、不確実なステージが1つありますか。 -> ハイブリッド：外側のフローをチェーン化し、適応型ループを組み込みます。
• 多くのファイルをレビューしますか。 -> ファイルごとのパス、続いてファイル横断のパスに分解します。

そして常に、適応型ループはstop_reasonで終了させ、反復回数の上限は安全策としてのみ使用してください。

重要なポイント：

• 既知の順序付けられた手順には、固定パイプライン（プロンプトチェイニング）を使います。予測しやすく、デバッグしやすく、低コストです。
• 次のステップが発見した内容に依存する、答えの決まっていない調査には適応的な分解を使います。
• ハイブリッドは一般的な構成です。固定された外側のフローに、適応型ステージを組み込みます。
• 適応型ループは必ずstop_reason（end_turn）で終了させてください。反復回数の上限は安全策であり、主な停止条件ではありません。「done」というテキストを解析してはいけません。
• 複数ファイルのレビューでは、ファイルごとのパスの後に、独立したファイル横断のパスを実行します。
• サブエージェントは履歴を引き継ぎません。コンテキストを明示的に渡してください。セッションの再開は慎重に行い、構造化された要約を与えた新規セッションのほうが、古い再開セッションのツール結果より優れる場合があります。