複数のAIエージェントで問題を解決する場合、単に丸投げするのではなく、AIエージェントが活躍できるような仕組みが必要です。そのために必要な3つのワークフローパターンをAnthropicが公開したブログ記事を基に紹介します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Anthropicは2026年3月5日、AIエージェントを活用して問題を解決する際の代表的なワークフローのパターンの特徴をまとめたブログ記事を公開した。以下ではその内容を紹介していく。
Anthropicが示す3種類のワークフローパターンとその選択の基準この記事では、AIエージェントに何かの問題を解決してもらう際には、エージェントは自律的に判断するが、そこにワークフローという構造をもたらすことで、レイテンシ(応答の遅延)やトークン消費量、信頼性、それからもちろん得られる結果に大きな差が出るとしている。複数のAIエージェントを使って何かを処理するのであれば、ワークフローで全体の大きな構成を決め、その個別のステップでAIエージェントが自律的に判断を下すという形にするのがよいということだ。
そして、ワークフローには次に示す3つのパターンがあるという。
記事で強調されているのは「まず単一エージェントで試すこと」だ。つまり、単一のエージェントで十分な結果が得られるのであれば、複数エージェントもそれらを協調させるワークフローも不要ということだ。単一エージェントで足りない場合に、必要に応じて複数エージェントや反復構造を導入する話である。また、3種類のワークフローは相互排他的ではなく、シーケンシャルワークフローのどこかのステップでパラレルワークフローを使うといったことも可能である。
どうも。HPかわさきです。
最初はこのブログ記事、コーディングに関することなのかなと思いながら読んでいたのですが、そうでもなくって、AIエージェントで何かをしようという人なら誰もが目を通しておいてほしいことだなと考えています。特にClaude Coworkが一般の業務や日々のこまごまとしたことをバリバリに処理してくれるようになってきた今だから、「何かエージェントがもんもんとしているなぁ」と感じたら、エージェントがうまく仕事をこなせるように人さまの側でやり方(ワークフロー)を設定してあげられるようになるといいですね。
以下ではワークフローの3つのパターンについて簡単に紹介しよう。
シーケンシャルワークフローは「あらかじめ決められた順序でタスクを実行する」パターンだ。全体が自然に幾つかのステップに分割され、あるステップが前のステップの結果に依存するような場合にシーケンシャルワークフローが有用といえる。各ステップではAIエージェントは自律的に判断し、必要に応じてツールを呼び出して、最終的な結果を次のステップに渡す形で処理が進められる。シーケンシャルワークフローでは各ステップが前のステップの終了を待つため、レイテンシは増える一方で、各エージェントが1つの役割に集中できるため精度向上が期待できる。
使いどころとしては次のようなことが考えられる。まず、各ステップが前のステップの出力に依存して実行される多段ステップの処理がそうだ。それから、各ステップが独自に何らかの価値を付加していくようなデータの加工処理。ステップ間の依存関係から並列化できないタスクや「初期のアウトプット→レビュー→仕上げ」のような反復に改善を行う処理もそうである。
そうしたタスクの具体的な例としては、広告文の作成→多言語への翻訳(多言語への翻訳は、後述するパラレルワークフローを適用しやすい)や、ドキュメントからのデータの抽出→スキーマを使用してのデータの検証→データベースへの保存などがある。
これに対して、シーケンシャルワークフローを使うべきでない場合もある。例えば、単一のAIエージェントがタスク全体を効率的に処理できる場合や、複数のAIエージェントが協調してタスクを進めなければならないような場合がそうだ。
パラレルワークフローでは、独立した(他のタスクに依存しない)タスクを複数のAIエージェントに分散し、AIエージェントがそれらを同時に実行する。他のタスクに依存しないということは、あるAIエージェントが他のAIエージェントの出力結果を待つ必要がなく、それらのタスクを個別のAIエージェントが同時に処理できるということだ。こうした場合には速度面での改善が見込める。AIエージェントが独立に処理をした結果は、最終的に集約したり、統合したりすることになる。
パラレルワークフロー(Agent 2とAgent 3がパラレルワークフロー)パラレルワークフローは、タスクを独立したサブタスクに分割でき、同時にそれらを処理することにメリットがある場合に使える。あるいは、1つの問題を多方面の視点から処理する場合もそうだ。複雑なタスクでは、複数の考慮事項を1つのAIエージェントに任せてしまうよりも、考慮事項ごとに別々のAIエージェントへ分けて処理する方が品質が上がりやすい。
具体的な例としては、評価の自動化やコードレビュー(どちらもAIエージェントがそれぞれに異なる指標を持って評価する)、ドキュメントの分析(主要テーマの抽出、センチメント分析、事実検証などを並列に実行した後に結果を統合する)などが挙げられている。
これに対して、AIエージェントが他のAIエージェントの処理結果に依存するような場合はパラレルワークフローを使うべきではないとされている。また、APIの使用量などのリソース面での制限があり、効率的に並列処理ができない場合や、さまざまなAIエージェントからの結果が矛盾している場合に、それらをどう扱えばよいか具体的な対処策がない場合にもパラレルワークフローを使うべきではない。
記事によれば、複数のAIエージェントで処理を始める前に、結果をどう集約するかを決めておくのが重要となる(多数決・信頼スコアの平均・最専門エージェントへの委譲など)。明確な方針を立てておけば、矛盾した結果が得られたときにどうしようもなくなって詰みということがなくなるだろう。
エバリュエーター&オプティマイザーワークフローは、「生成エージェント」と「評価エージェント」を反復的なサイクルで組み合わせるもの。生成エージェントがコンテンツを生成し、評価エージェントが何らかの品質基準に照らし合わせてそれを評価して、フィードバックを返す。生成エージェントはフィードバックを基にコンテンツを改善する。このサイクルをコンテンツが一定の基準に達するか、反復回数の上限に達するまで続ける。これらの基準や上限はあらかじめ定めておくことが推奨されている。
エバリュエーター&オプティマイザーワークフローは、評価エージェントが一貫して適用できる明確で計測可能な品質基準があり、かつ、初回の出力の品質と最終的な出力の品質に大きな差があり、ワークフローで必要となる追加のトークンやレイテンシが正当化できる場合に有効となる。セキュリティ基準、パフォーマンスベンチマーク、スタイルガイドラインなどの要件を満たすコードの生成や、適切な表現と正確性が求められるメッセージの作成などに向いている。
具体的な例としては、APIドキュメントの生成(生成エージェントがドキュメントを書き、評価エージェントが記述漏れや分かりやすさ、コードベースを正しく反映しているかどうかなどをチェックする)、カスタマーサービス(生成エージェントがメールの文面を作成し、評価エージェントがその口調や正確性をチェックする)、SQLクエリの生成(生成エージェントがクエリを生成し、評価エージェントが効率やセキュリティに問題がないかなどをチェックする)などが挙げられている。
一方、初回の出力から品質が十分であれば、エバリュエーター&オプティマイザーワークフローは必要ない。また、即時の応答が必要なリアルタイムアプリケーションや、基本的な分類処理のようなルーチンワーク、AIエージェントが一貫して適用できる基準がない場合にもこのワークフローを使うべきではない。さらに、すでにそのためのツールがあるという場合(例:コードのスタイルを修正するリンター)にはそれらを使うべきだろう。品質の改善よりもリソース制約の方が重要な場合にもこのパターンは使わない方がよい。
ブログ記事ではどんなときにどのワークフローを選ぶかについても述べられている。簡単にまとめておこう。
これについては冒頭の画像にも示したが再掲しておこう。
Anthropicが示す3種類のワークフローパターンとその選択の基準いずれかのワークフローを使うのであれば、以下についても考慮する必要がある。
複数のAIエージェントを活用することで、大規模な処理をAIエージェントにお任せできる世の中がやってきつつある。しかし、そのためにはAIエージェントが自律的かつ効率的に、そして期待通りに問題を解決できるように人間の側がワークフローを適切に与える必要がある。まずは単一のAIエージェントでうまくいくのかを確認し、そうでなければ自分がやりたいことが何かを分析した上で、AIエージェントに活躍の場を与えることが重要だ。
筆者はサッカーも好きなんですが、「戦術は選手を縛るものではなくて、選手を助けるものだ」って話とよく似ているなと感じました。チーム全体の戦い方を定義して、個々の選手がどんなときにどう動くかを定めた上で、個別の場面では選手が自由に判断するみたいな話です(ホントかな)。20数年前にはトルシエ監督も「7割が組織、3割が個人」みたいなことをよくいっていたような記憶があります。組織をワークフロー、個人をAIエージェントと考えると、「なるほどな」って気もしますね(笑)。
Copyright© Digital Advantage Corp. All Rights Reserved.
編集部からのお知らせ