レッスン4: コラボレーションパターン: パイプライン、レビュー、投票

学習目標:

• パイプライン、プロデューサー・レビュアー、マルチパースペクティブ投票が実際にどう動作するかを区別する
• 与えられたタスクにどのパターンが適合するか判断し、それぞれのコストプロファイルを説明する
• ハンドオフスタイルのコラボレーションとオーケストレーター・サブエージェントのコラボレーションで、誰が制御を保持するかの重要な違いを理解する

前提: レッスン3を完了し、自己完結型で明確にスコープされた委任プロンプトを書くことに慣れていること | 前: レッスン3 << | 次: レッスン5 >>

過去2つのレッスンで扱ったオーケストレーター・サブエージェント構造は一つの形です。中央ノードがタスクを分割し、複数のサブエージェントが並列に作業し、その結果がマージされて戻ります。しかし、それは複数のエージェントを接続する唯一の方法ではありません。このレッスンでは、3つのより具体的なコラボレーションパターン（パイプライン、プロデューサー・レビュアー、マルチパースペクティブ投票）について、それぞれがどこに適合し、コストがどこに発生するかを説明し、さらにオーケストレーター・サブエージェントとは全く異なるアイデアで動作する4番目のコラボレーション方法である制御の直接的な受け渡しについて解説します。

パイプライン: 一つずつステップを進み、前のステップを次のステップが消費する

パイプライン（プロンプトチェーニング）: "Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one."¹ パイプラインとオーケストレーター・サブエージェントの最大の違いはこれです。オーケストレーター・サブエージェントは並列構造です。"a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."¹ パイプラインは厳密に一つのステップの後に次のステップが続きます。次のステップは前のステップが完了するまで開始できず、前のステップの出力を直接自分の入力として受け取ります。

製品発表のブログ記事を例に取りましょう。これを3つのステップに分割できます。最初のバージョンを下書きし、その下書きを別の言語に翻訳し、翻訳されたバージョンを用語の不整合がないかチェックします。ステップ2の入力はステップ1の出力、ステップ3の入力はステップ2の出力で、それらのどれも先に進んで独自に開始することはできません。この形は自然な順序を持つタスクに適合します。次のステップが前のステップの結果なしには本当に進められない場合です。3つの企業の価格を調査する場合は本当に独立したチャンクに分割できますが、パイプラインの各ステップはその前のステップに依存します。

プロデューサー・レビュアー: 一方が書き、もう一方が精査し、繰り返す

プロデューサー・レビュアー（エバリュエーター・オプティマイザー）: "one LLM call generates a response while another provides evaluation and feedback in a loop."¹ パイプラインとの重要な違いはそのループです。パイプラインは固定されたステップセットを実行して停止しますが、プロデューサー・レビュアーは下書き、レビュアーがフィードバックを提供、フィードバックに対して修正、再度レビューし、レビュアーが満足する（または事前設定された最大ラウンド数に達する）まで停止しません。何ラウンド必要かは通常事前にわかりません。

例えば、一つのエージェントに決済ロジックを処理するコードを書かせ、別のエージェントにそのコードがエッジケースを見逃していないかチェックする役割だけを与えます。負の金額、並行性の下での重複送信など。レビュアーエージェントが問題を見つけた場合、コードはプロデューサーエージェントに戻されてもう一度処理され、その後レビュアーに戻り、レビュアーが明らかな問題を見なくなるまで続きます。この形は、「良い仕事をしたか」を一発で正確に判断できず、収束するために繰り返し磨く必要があるタスクに適合します。最初のバージョンが最終版になることはまれで、レビューステップは配信前に明らかな問題をキャッチし、プロデューサーにもう一度修正させるために存在します。

マルチパースペクティブ投票: 一つのものに対する複数の独立した判断

マルチパースペクティブ投票: 複数のエージェントが同じコンテンツをそれぞれ独立して判断します。リレーでステップごとに処理するのではありません。公式の例はコードのセキュリティレビューです。"Reviewing a piece of code for vulnerabilities, where several different prompts review and flag the code if they find a problem."¹ ここで「いくつかの異なるプロンプト」はそれぞれ同じコードを独立して見て、他の判断に依存せず、一つのプロンプトでも問題をフラグすればコードはフラグされ、より詳しく見る価値があります。

このパターンはプロデューサー・レビュアーとは異なります。投票は下書きして修正するループではありません。エージェントは既に存在する一つのコンテンツを並列かつ独立して判断します。目標は、繰り返し編集を通じてコンテンツをより良くすることではなく、複数の異なる角度からチェックすることで見逃しの確率を下げることです。これは、いくつかの追加の呼び出しに費やすよりも問題を見逃す方がまずい状況に適合します。セキュリティレビューやコンプライアンスチェックでは、本当の問題を見逃すコストは通常、いくつかの追加トークンよりもはるかに高くつきます。

3つの中から選ぶ方法とコストがどこに発生するか

3つのパターンは異なるコスト構造を持つので、実際の状況に対して計算して選びます。

• パイプライン: 総コストはステップ全体の呼び出しの合計にほぼ等しいです。ステップ数は固定され予測可能ですが、実行は厳密に順次なので、総レイテンシは各ステップの時間を合計したもので、速くはありません。各ステップのスコープがかなり小さい明確なステップ間依存関係を持つタスクに適しています。
• プロデューサー・レビュアー: コストは収束するまでに何ラウンドかかるかに依存し、ラウンド数は不確実です。プロデューサーとレビュアーがやり取りを始めると、コストは予想をはるかに超えて実行される可能性があります。そのため、このパターンは通常、ループが永遠に回転し続けないように最大ラウンドキャップが必要です。最初のバージョンがおそらく十分に良くなく、繰り返し磨く必要があるタスクに適しています。
• マルチパースペクティブ投票: コストは単一レビューコストに投票するエージェント数を掛けたものにほぼ等しいです。単純な掛け算なので、Nエージェントは N 倍のコストを意味します。見逃しが高くつき、より広いカバレッジのために支払う価値があるタスクに適しています。コンテンツ自体があまりリスキーでない、コストに敏感な状況には適合しません。

選択するには、タスクそのものの形に戻ります。ステップの自然な順序がありますか。もしそうなら、パイプラインを検討してください。出力品質が十分に良くなるために繰り返し磨く必要がありますか。もしそうなら、プロデューサー・レビュアーを検討してください。問題を見逃すことが複数の角度からチェックする価値があるほど高くつきますか。もしそうなら、マルチパースペクティブ投票を検討してください。3つは相互に排他的でもありません。完全なワークフローは固定パイプラインを実行し、そのステップの1つの内側にプロデューサー・レビュアーループをネストできます。レッスン6では、まさにこの種の組み合わせを実践的に構築します。

別のコラボレーション方法: 制御を直接受け渡す

これまでのパターンは一つの共通点を持っています。オーケストレーター（またはパイプラインの接続ノード）が全体の責任を保持し、サブエージェントは完了時に結果を返します。ハンドルを保持して次に何が来るかを指示することはありません。しかし、コラボレーションには全く異なるアイデアがあります。ハンドオフ: "Handoffs: Peer agents hand off control to a specialized agent that takes over the conversation. This is decentralized."²

ハンドオフとオーケストレーター・サブエージェントの核心的な違いは、誰が制御を保持するかだけではありません。引き継ぐエージェントが全く異なる量の情報を見ることです。ドキュメントは明示的です。"When a handoff occurs, it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history."³ それがデフォルトの動作で、新しいエージェントがどれだけの履歴を見るかを変更する入力フィルターのような設定オプションがあります。これはレッスン2と3のサブエージェントメカニズムの正反対です。サブエージェントは新鮮で隔離されたコンテキストから開始し、以前の会話を見ません⁴。一方、ハンドオフの受信エージェントはデフォルトで完全な履歴を見ます。なぜなら、一つの隔離されたタスクを実行して結果を返すために派遣されるのではなく、本当に会話を引き継ぎ、ユーザーまたは次のステージとそこから続けるからです。

この違いは、各スタイルがどの状況に適合するかを決定します。オーケストレーター・サブエージェントは、それぞれが結論を返し、中央ノードが全体の責任を保持する独立したサブタスクのバッチに分割することに適合します。ハンドオフは、会話が進むにつれて、より専門的なエージェントがここから引き継ぐべきだと判断し、会話全体をそのまま渡す場合に適合します。例えば、カスタマーサポートでは、一般的なサポートエージェントがユーザーの問題が返金に関係すると判断し、会話全体を返金専門のエージェントに渡すので、ユーザーは問題を最初から説明する必要がありません。この制御の転送は依然として単一の実行内で発生します。"Handoffs stay within a single run."³

まとめ

• パイプラインはタスクを順序依存の固定ステップの連鎖に分割し、各ステップが前のステップの出力を処理します¹。作業を戻す必要がない自然な順序を持つタスクに適しています。
• プロデューサー・レビュアーは下書きを書く、フィードバックを得る、修正する、再度レビューするループで、収束するまで実行されます¹。出力品質が繰り返し磨く必要があるタスクに適しており、コストはラウンド数によって駆動されるため、通常最大ラウンドキャップが必要です。
• マルチパースペクティブ投票は複数のエージェントが同じコンテンツを並列かつ独立して判断し、一つの角度でも問題を見つけたらすぐにフラグします¹。見逃しが高くつき、より広いカバレッジのために数倍のコストを支払う状況に適しており、コストは単一実行コストに判断するエージェント数を掛けたものにほぼ等しいです。
• 3つの中から選ぶには、タスクの形を見ます。ステップの自然な順序がありますか、繰り返し磨く必要がありますか、見逃しが高くつきますか。3つの質問はそれぞれパイプライン、プロデューサー・レビュアー、マルチパースペクティブ投票を指します。
• ハンドオフは異なるコラボレーションのアイデアです。エージェントは互いに制御を直接受け渡し、受信エージェントは会話を引き継ぎ、デフォルトで以前の会話履歴全体を見ます³。これはオーケストレーター・サブエージェントのメカニズムの反対です。サブエージェントは新鮮で隔離されたコンテキストから開始し、結論のみを返します⁴。ハンドオフは単一の実行内に留まり、より専門的なエージェントがここから会話を引き継ぐべきケースに適合します²。

>> レッスン5: 失敗と調整