🧠 AI プロダクト動向

Anthropic は自社の設計指針で、workflow を「LLM とツールが事前に定義されたコードパスに沿って呼び出される構成」、agent を「LLM が自らの処理とツール利用を動的に制御する構成」と定義している。前者には prompt chaining（逐次分解＋検証ゲート）、routing（分類して専門処理へ振り分け）、parallelization（並列実行と多数決）、orchestrator-workers（中心の LLM が動的に分解・委譲）、evaluator-optimizer（フィードバックによる反復改善）という 5 つの具体パターンが並ぶ。

この切り分けが実務で効くのは、判断基準が「流行っているかどうか」ではなく「手順を事前に書き切れるかどうか」という一点に絞られているからだ。書き切れるタスクに agent を充てても、コストと遅延を払って再現性を失うだけの結果になる。

Shopify の Sidekick チームはツール数が 20 から 50 以上に増える過程で、システムプロンプトへ指示を積み上げる方式が破綻したため、必要な指示をツールの結果と一緒にその場で渡す JIT（Just-In-Time）instructions へ切り替えた。同時にマルチエージェント化は見送り、単一のエージェントループ（入力→判断→実行→フィードバック）のまま複雑なマーチャント業務に対応させている。Ramp が社内向けに作った agentic データアナリスト「Ramp Research」も同様に単一エージェント構成で、inspect column values, branch, and backtrack という人間のアナリストに近い探索的なツール利用を LLM 自身に判断させている。

両社に共通するのは、複雑さは実証されてから足すという順序だ。マルチエージェント化やオーケストレーション層の追加は、単一エージェントで頭打ちになったことを確認してからの手当てであり、最初から選ぶものではない。

一方で Anthropic 自身の Research 機能は、Lead Researcher が調査計画を立て、3〜5 体のサブエージェントを並列に立てて Web 検索を分担させるオーケストレーター・ワーカー構成を採っており、複雑な調査クエリで所要時間を最大 90% 短縮したと報告している。これは『読み取りが並列化できる、探索的で開放的なタスク』という条件が揃った場合の話であり、前節の単一エージェント推奨と矛盾しない。

顧客対応のような書き込みを伴う業務では、むしろ workflow と agent を組み合わせるほうが安定する。Intercom の Fin はメール対応において RAG ベースのエージェントが自律的に応答を組み立てつつ、ワークフロー側のトリガーで起動し、対応しきれない場合は人間のサポート担当へエスカレーションする設計を取っている。