テクニカル火曜日:オーケストレーションが効果的な AI エージェント展開の鍵となる理由

エージェント オーケストレーションは初めてですか? ここから始めましょう .

実際に見てみましょう。AI エージェントの構築や導入は簡単ではありません。しかし、一度埋め込まれると、その影響は信じられないほど大きくなります。私は、Lantik のデジタル サービス責任者である Ainara Etxeandia Sagasti のような UiPath の顧客の話を聞くのが大好きです。彼は「RPA、生成 AI、エージェント テクノロジーを組み合わせて、公共サービスをこれまで以上にアクセスしやすく、効率的で、市民中心のものにしている」と話しています。すでに 10,000 を超える AI エージェントが UiPath Platform™ 上に構築されています。エージェントはプロセスの効率と収益性を変革できますが、強力なオーケストレーションと、自動化とループ内の人間による支援が必要です。

このブログ投稿では、AI エージェントを大規模に構築、テスト、デプロイする際の最も一般的な問題点について説明します。また、制御された機関と相互運用性に基づいて構築された、統合されたアプローチがどのようにそれらを軽減できるかについても説明します。

1.エージェントのパフォーマンスと信頼性

開発者とユーザーは、AI エージェントの信頼性の低さが運用の障壁であると頻繁に言及します。大規模言語モデル (LLM) により、エージェントは柔軟で順応性が高くなりますが、これは出力の不一致にもつながります。これにより、開発とテストが妨げられる可能性があります。あるエンジニアは次のように述べています。「エージェントは時々完璧に動作することもありますが、その後、同様の入力で完全に失敗します。エッジケースをシミュレートし、障害を一貫して再現するためのより良い方法が必要です…時間の経過とともにエージェントの「ドリフト」を監視することは、本当に頭の痛い問題です。」

もう 1 つの課題は、プロセスを停止させる可能性がある幻覚 (エージェントが事実やツールの入力を捏造すること) です。 AI ワークフローを構築しているユーザーは、「私たちが発見した最大の問題点は再現性と幻覚です。同じまたは類似のクエリに対して、LLM エージェントが常軌を逸して他のツールへの入力を幻覚させないようにすることです。」と共有しました。この予測不能性には大規模なテストと検証が必要ですが、エージェントのテスト ツールは未熟です。エラーが発生した場合、モデルの推論が不透明であるため、診断が困難になることがあります。このため、チームは変更に対して非常に慎重になります。「エージェントに何かをしないように指示したことで火傷を負い、その後エージェントが奇妙な動作をし始めることが何度もあったため、現時点ではシステムのプロンプト変更には非常に慎重になっています。」

基礎となる AI モデルのパフォーマンスも別の問題です。大規模なモデルはリソースを大量に消費したり低速になる可能性があり、一方、小規模なモデルではパフォーマンスが低下する可能性があります。適切なバランスを見つけるのは困難です。

一貫性のある信頼性の高い出力が欠如しているため、広範な保護策がなければ、ミッションクリティカルなタスクや顧客対応のタスクにおいて AI エージェントを信頼することが困難になります。実際には、高い信頼性を実現するには、多くの場合、エージェントの動作を簡素化したり、厳格な制約を導入したり、フォールバック (人間による継続的な介入など) を導入したりする必要があります。しかし、これらの対策はエージェントの自主性、効率性を損なう傾向があり、したがって付加価値のある企業シナリオでの有用性を損なう傾向があります。

2.管理された代理店と人間関係者

AI エージェントは複雑なタスクを自動化できますが、開発者は人間の監視とコラボレーションが不可欠であり、適切なバランスを取るのが難しいことを認識しています。エージェントが間違いを犯したり、不明確な決定を下したりする可能性があるため、完全に手を離す自律性は多くの場合非現実的です。企業は代理店の度合いを制御する必要があります。代理店の精度と信頼性が高まるにつれて、代理店の度合いは時間の経過とともに増加する可能性があります。

一般的なアプローチは、特定の承認のために「人間参加者」を維持したり、特殊なケースに対処したりすることですが、これが適切に調整されていない場合、プロセスが遅くなる可能性があります。次に、特定の承認、重要な決定を行い、例外を処理するために「関与者」が呼び出されます。ある AI エンジニアは、エージェントを制約し、人間を関与させることでより良い結果が得られると指摘しました。「人間の監視下で厳しく制約された LLM は、中複雑なタスクで良好な結果を達成できます…[完全に] 自律型の汎用エージェントが [大規模に]」はまだ現実的ではありません。

逆に、AI が厳密に制御されすぎたり、継続的なチェックが必要な場合は、ROI は生み出されません。場合によっては、エージェントがワークフローを中断したり、節約できる以上の労力を費やしたりすることがあります。たとえば、ある開発者は、Copilot のコーディングが手作業による修正を強制することでどのように生産性を妨げているかについて説明しました。「何かを始めても、それを終わらせることができません…タグや括弧などを確認して閉じることに注意をそらさなければなりません。それによりフローが中断され、作業の速度が低下します。」

課題は、エージェントが作業を処理しながら、判断の判断は人間にシームレスに引き継ぎ、余分な摩擦を生じさせることなく、ハイブリッド ワークフローを設計することです。

3.コストと ROI に関する懸念

AI エージェントの ROI は、特に使用量が拡大するにつれて、繰り返し懸念される問題です。大規模な言語モデル API (およびそれらを実行するインフラストラクチャ) は高価になる可能性があります。チームは、エージェントが最適化されていない場合、コストが高騰することを懸念しています。あるユーザーは、現在のエージェントは成果に対して「高すぎる」と主張しました。信頼性が低い場合、ROI を測定するのは困難になることがあります。エージェントが部分的にしか成功しない場合、その失敗 (および手動による修正) のコストがメリットを上回る可能性があります。

企業は、モデルの最適化や使用ポリシーなどの方法を通じてコストを管理しようとしています。あるユーザーは、繰り返しの呼び出しを減らすためにキャッシュを実装し、出力効率を向上させるために高品質のデータを慎重に取得することについて説明しました。 「私は、プロンプトをさまざまなモデルすべてで実行して、最良かつ最も安価なものを見つけることができるフレームワークが欲しいと思っています。現在、私の AI エージェントは 200 以上のプロンプト テンプレートを使用しており、それらすべてのテストと再テストにはコストがかかります。」最終的には、迅速なエンジニアリングとモデルの実験には実際のコストが発生します。

ベンダーの価格設定モデル (トークンごと、コールごとなど) も役割を果たします。たとえば、すべてに GPT-4 を使用するのはやりすぎかもしれませんが、安価なモデルを使用すると品質が低下する可能性があります。チームは ROI を正当化するためにバランスを取る必要があります。さらに、クラウド AI サービスや特殊なインフラストラクチャに多額の継続的な支出が必要な場合、経営陣はエージェント プロジェクトのビジネス価値に疑問を抱く可能性があります。明確な勝利（自動化による収益の増加またはコスト削減のいずれか）がなければ、投資を守るのは困難になる可能性があります。したがって、コストの最適化と ROI の実証が最優先事項です。チームは、価値の高いユースケースに焦点を当てながら、モデルを組み合わせてマッチングすることで、AI エージェントを「最も安く利益を得たい」と考えています。

4.ガバナンス、セキュリティ、プライバシーに関する懸念

組織は AI エージェントに対してセキュリティ、コンプライアンス、倫理ガイドラインを強制する必要がありますが、これは言うは易く行うは難しです。データ プライバシーは最大の懸念事項であり、機密データが漏洩しないと確信できるまで、多くの企業がクラウド AI サービスを禁止または制限しています。ある開発者は、職場では知的財産上のリスクを理由に ChatGPT のようなツールを禁止していると共有しました。「そうではありません。これは知財リスクが大きすぎると考えられており、秘密が漏洩したり、他人の著作権を侵害したりする可能性があると考えています。」サードパーティの AI API を使用する場合、実務者は顧客データが誤ってそれらのサービスに送信されるのではないかと心配します。

セキュリティも別の問題です。自律エージェントは、適切にサンドボックス化されていない場合、リスクをもたらします。チームがエージェント プラットフォーム上に追加の保護手段を追加しているという報告があります。たとえば、リード生成エージェントを導入する際に、「最上位にセキュリティ レイヤーを追加する必要があり…[そして] コスト最適化のためにキャッシュ (Redis) を使用する必要がありました」。すぐに使えるソリューションにはエンタープライズレベルのセキュリティ管理やコスト管理が欠けていることが多く、企業は独自のガバナンスを強化する必要があります。さらに、エージェントのフレームワークに監視のためのフックが提供されていない場合、エージェントが規制 (GDPR、HIPAA など) に準拠し、組織のポリシーに従うことを保証することは困難です。

これらの懸念により利害関係者は慎重になっています。利害関係者は、AI エージェントが強力であると同時に透明性があり、データの使用方法を隠す「独自のシステムではなく、中立的で広く受け入れられているプロトコルで」制御されることを望んでいます。つまり、堅牢なガバナンス機能 (監査ログ、権限制御、人間によるオーバーライドなど) がなければ、多くの組織は広範なエージェントの導入において壁にぶつかります。

5.導入と拡張の困難

AI エージェントを概念実証から運用環境に移行すると、多くの問題が発生する可能性があります。ユーザーは、管理されたデモで機能するものは、現実世界の規模、量、複雑さの点で苦労することが多いと報告しています。一般的な懸念事項には、遅延とスループット (LLM を利用したエージェントは、トラフィックの多いアプリケーションやリアルタイム アプリケーションには遅すぎる可能性があります)、およびシステムを確実に実行するための運用オーバーヘッドが含まれます。 Kadoa の共同創設者兼 CEO である Adrian Krebs 氏は、「AI エージェントが遅すぎる、高価すぎる、信頼性が低すぎるという根本的な問題がある場合、オーケストレーション フレームワークを使用しているかどうかは関係ありません。」と述べています。チームは多くの場合、パフォーマンス要件を満たすためだけに、キャッシュ、モデルの交換、エージェント ロジックの簡素化などを使用して、効率性を高めるために再設計する必要があります。

また、一貫性を維持しながら複数の環境 (クラウド、オンプレミス、エッジ デバイス) にデプロイするという課題もあります。企業環境では、すべての部門が同じツールを使用したいわけではないため、標準化された導入が困難になります。現場でのエージェントの監視、ロギング、更新などの運用拡張の問題も同様に未開発です。ある Reddit ユーザーは、基本的なデバッグですら「悪夢のようなものになる可能性がある」と指摘しました。エラー ログは難解な場合が多く、明確なトラブルシューティング ガイドがありません。多くのエージェントが導入されている場合、これはさらに困難になります。これらすべてがエージェントの採用を遅らせる可能性があります。大手ベンダーでさえ、顧客は「まだ始めたばかり」であり、大規模な意味のある結果はまだ出てきている段階であることを認めています。

6.マルチエージェント オーケストレーションの複雑さ

複数の AI エージェントが連携するシステムの構築は困難です。開発者は、エージェントの役割を調整し、共有状態を管理し、エージェントがループに入ったりエージェント同士が競合したりするのを防ぐことに苦労しています。オーケストレーション フレームワークを使用している場合でも、1 人のエージェントの出力に誤りがあると、ワークフロー全体が狂ってしまう可能性があります。ある開発者は、「人々はただ実験しているだけです。信頼性の低さは依然として大きな問題です。自動回帰生成プロセスでの脱線は、エージェントにとって致命的となる可能性があります。」と述べています。また、自己修復ワークフローや回復力のあるワークフローを作成することの難しさを強調する人もいます。たとえば、失敗したステップや人間の介入を再試行するためのロジックを追加するなどです。

こうしたオーケストレーションの課題は、チームが 1 つの問題を解決するだけで他の問題が現れることがよくあることを意味します。「モグラたたきのような気分になることもあります。迅速なエンジニアリングで 1 つの問題を修正してから、さらに 3 つの問題を作成します。」

7.モデルの互換性と統合の課題

単一の AI エージェントが市場で支配的なわけではありません。組織は、ある日 OpenAI を使用し、次の日にはオープンソース モデルに切り替え、さまざまなサードパーティ ツールを統合する可能性があります。しかし、互換性とスムーズな統合は大きな課題です。ツールとモデルの統合には、多くの場合、カスタム アダプターまたはグルー コードが必要です。たとえば、フレームワークがそれを念頭に置いて設計されていない場合、エージェントを独自のデータベースや内部 API に接続するには、多大な労力がかかる可能性があります。開発者らは、多くのフレームワークは「重く」、すべてのユースケースに当てはまらない前提が含まれていると主張しています。「残念ながら、これらのフレームワークの多くは、基本的な機能だけが必要な場合には非常に重いです。」

逆に、「フレームワークに依存しない」ということは、多くの定型文を最初から作成することを意味することがよくあります。ユーザーは、ロックインされることなく車輪の再発明を避けたいと考えています。ある開発者は、特に互換性を最大化するために、より柔軟なライブラリに落ち着いたと説明しました。「いろいろ試しました…最終的に、[Instructor] を使用することに落ち着きました。LLM (ローカル/OS とプロプライエタリの両方) をすぐに切り替えることができ、どこでも同じ構造化された入出力を使用できるからです。」これは、進化するニーズに合わせて AI モデルやサービスを簡単に交換できるエージェントの必要性を浮き彫りにしています。

もう 1 つの一般的なニーズは、エージェントを既存のソフトウェア スタックおよびワークフローと統合することです。標準インターフェイスがないということは、新しいエージェントごとに新たな統合作業が必要になる可能性があることを意味します。前述したように、サンプルの欠落や高度な設定がこれを妨げる可能性があります。さらに、1 つのコンポーネントの更新 (LLM API の変更など) によってエージェントのロジックが壊れた場合、互換性の問題が発生します。これはチームが積極的に管理する必要があります。つまり、実務者はプラグアンドプレイの相互運用性、つまり大規模なカスタム エンジニアリングを行わずにさまざまなモデル、データ ソース、システムに接続できる AI エージェントを望んでいます。

8.ベンダーロックインと相互運用性の問題

AI モデルとフレームワークは急速に変化しています。多くのチームは最善の組み合わせを望んでおり、単一ベンダーの AI エージェント ソリューションを選択すると、将来的に柔軟性がなくなるのではないかと心配しています。エージェント フレームワークは爆発的に増加しており、それぞれに独自の API と考慮事項があります。ある開発者はこれを JavaScript フレームワークの流行に例えました。「おそらく数か月以内に、私たちのバージョンの『100 種類の JS Web フレームワークで TODO アプリ』ができるでしょう…それらをすべて理解するだけでも大変な作業です。」

1 つのエコシステムにコミットすると、柔軟性が制限される可能性があります。特定のライブラリは特定のプロバイダーを優先します。たとえば、不満を抱いたユーザーは、フレームワークの選択が「主に壊れる」と警告し、一部のツールがどのように暗黙的に特定のモデルやサービスにユーザーを拘束するかを強調しました。リスクはベンダーのビジョンを中心に構築され、後になって「そのアップデート、価格設定、ポリシーに依存し、実行可能な代替手段がない」ことに気づくことになります。相互運用性は、エージェントを既存のソフトウェア スタックに統合する場合の懸念事項でもあります。開発者は、エージェントをすでに使用している言語やクラウド サービスに引き込むための「明確な例がない」ことがよくあり、多様なチームにわたってこれらのツールを導入することが困難になっています。

エージェント オーケストレーションによる機会

これらの課題の多くは、柔軟性、相互運用性、人間中心のエージェント オーケストレーション ソリューションの必要性を示しています。エージェント オーケストレーションは、人、ロボット、AI エージェントの能力に応じてタスクと責任を効果的に管理、割り当て、業務がスムーズかつ効率的に行われ、ビジネスの戦略的成果と一致することを保証します。

信頼性の高い AI エージェント、決定論的な自動化、人間の入力を効果的に統合するオーケストレーション レイヤーには、いくつかの利点があります。

• 決定論的なバックストップによる信頼性の向上:オーケストレーションされたアプローチの理想的な最終状態は、管理された主体性であり、過度の手動介入なしで最適な効率が可能になります。これは、エンタープライズ グレードのツール、決定論的なロボット、および快適なレベルの人間によるレビューによってプロセスが慎重に制限される、専門化された AI エージェントのオーケストレーションに依存します。 AI エージェントを決定論的な自動化スクリプトまたはルールと組み合わせることで、オーケストレーション層によって常にフォールバック パスが確保されます。たとえば、AI エージェントの出力が特定の精度しきい値を満たさない場合、事前定義されたルールがそのケースを処理する (または少なくともフラグを立てる) 可能性があります。このハイブリッド アプローチでは、ガードレール内で AI の創造性を活用します。時間の経過とともに、オーケストレーション プラットフォームは、どのエージェントがどのタスクに対して最も信頼できるかを (結果の監視を通じて) 学習し、それに応じてタスクをルーティングすることで、成功率を最適化することもできます。最終的な効果は、単一のブラックボックス エージェントと比較して、ワークフローの全体的な信頼性が高くなります。ある開発者が述べたように、「人間の監視によって [エージェント] を厳しく制限」し、明確に定義されたプロセスにより、確実に優れた結果が得られます。これはまさにオーケストレーションによって可能になります。

• 人間参加型の統合:適切に設計されたオーケストレーション層の主な利点は、人間によるチェックポイントを組み込むのが容易なことです。たとえば、エージェントの信頼度が低い場合、またはエージェントの決定に大きなリスクがある場合に、オーケストレーション層を一時停止して人間の承認を要求するように構成できます。これにより、重要なワークフローにエージェントを展開するために必要な「セーフティ ネット」が提供されます。人間の監視をエージェントごとに個別にハードコーディングする代わりに、共通プラットフォームは人間へのエスカレーションのための一貫したインターフェイスを提供し、時間の経過とともに人間による修正から学習することもできます。 AI と人間のワークフローをこのように連携させることで、必要に応じて AI のスピードを活用することができますが、信頼性と信頼性を確保するために常に人間のバックストップが必要です。

• 一元化されたガバナンスとセキュリティ:ベンダーに依存しないオーケストレーション層により、すべての AI アクティビティにわたってセキュリティとコンプライアンスを均一に適用できます。各エージェントに送信されるデータを監視し、機密情報をスクラブまたは匿名化し、監査目的でエージェントのすべての決定を記録するゲートウェイとして機能します。これにより、組織に単一の制御点を与えることでガバナンスの問題が解決されます。たとえば、管理者は、特定のデータの処理を許可する AI モデルを構成したり、プライバシー ポリシーにより特定のクエリを常にオンプレミス モデルで処理することを要求したりできます。このようなシステムは、エージェントのアクションをロールベースで制御するために ID およびアクセス管理 (IAM) と統合することもできます。ポリシー (レート制限やコスト予算など) はグローバルに適用できます。これらすべての機能は、企業が望ましくないデータ漏洩や不正行為を防ぐための監視層があることを知っているため、より自信を持って AI エージェントを導入できることを意味します。

• 相互運用性とロックインの回避:中立的なオーケストレーション層により、チームは 1 つのベンダーのエコシステムに縛られることなく、必要に応じてさまざまな AI モデルやサービスを接続できます。これにより、プロバイダーを切り替えた場合にすべてを再構築しなければならないという不安が軽減されます。あるエンジニアが主張したように、その目標は、エンドユーザーが「ベンダーのロックインを心配する必要がなく、単一ベンダーのエコシステム内にユーザーを閉じ込めるのではなく、AI システムがプラットフォーム間でシームレスに動作することを保証すること」です。オーケストレーション レイヤーは、複数の AI バックエンド (OpenAI、Anthropic、オープンソース モデルなど) に対して「共通言語」を話すことで、常に業務に最適なツールを選択し、テクノロジーや価格が変更された場合に方向転換できるようにします。

• マルチエージェントの調整と専門化:オーケストレーション プラットフォームは、それぞれがサブタスクに特化したエージェントのチームを管理し、それらの対話を決定論的に調整できます。これにより、担当者の複雑さが軽減されます。オーケストレーション層は、エージェント間のタスク ルーティング、状態管理、およびエラー回復を処理できます。 1 つのモノリシック エージェントがすべてを試みる (そして、多くの場合予期せぬ失敗に終わる) のではなく、オーケストレーション層がそれらをリンクすることで、特定の役割に焦点を当てたより単純なエージェントを配置できます。このようなセットアップには、ルールベースの自動化や、AI を必要としないタスク用の従来のソフトウェア コンポーネントも含めることができ、AI が価値を付加する場合にのみ使用されるようにすることができます。その結果、1 つのコンポーネントで障害が発生したり、不確実な出力が生成された場合に、オーケストレーション プラットフォームが (検証、再試行、フォールバックなどを介して) それをキャッチできる、より堅牢なシステムが実現します。

• コストの最適化とリソースの柔軟性:ベンダーに依存しないプラットフォームは、さまざまなモデルまたはルートから動的に選択して、パフォーマンスのニーズを満たしながらコストを最小限に抑えることができます。たとえば、単純なクエリには安価なローカル モデルを使用し、複雑な場合にのみエンド ユーザーに透過的に高価な API を呼び出すことができます。また、リクエストをバッチ処理したり、結果をキャッシュしたり、エージェントの実行頻度を調整したりすることもできます。あるチームは、これを手動で行っていると報告しました (キャッシュを追加し、特定のタスクには安価なモデルを使用しました)。インテリジェントなオーケストレーション プラットフォームは、このような最適化を自動的に処理できます。さらに、1 つのベンダーに縛られないことで、組織は価格競争を利用して、価格を上げた場合には、より費用対効果の高いサービスに切り替えることができます。この柔軟性が オーケストレーションにより、リソースを最も効率的な方法 (ユーザーが望むように各ジョブに「最適かつ安価な」モデル) で確実に使用できるため、ROI が向上します。

「エージェント オーケストレーションの決定版ガイド」を読んでください。

要約すると、実証済みで信頼できるエージェント オーケストレーション レイヤーは、多くの問題点に直接対処します。

• 自律性や有用性を損なうことなく、エージェントの信頼性を向上させることで、制御された代理店を実現します

• AI と人間およびロボットをブレンドして、より良い結果を実現します

• マルチエージェントの複雑さを管理可能なフレームワークに抽象化します

• 単一ベンダーの制限を回避します

• エンタープライズ規模の展開に必要なガバナンスを提供します

このようなソリューションは、再現性の問題、統合の悩み、セキュリティへの懸念、コストの超過といった現実世界の困難から学ぶことで、実務者がはるかに少ない摩擦とリスクで AI エージェントを活用できるようにすることができます。その結果、より信頼性が高く、適応性が高く、ビジネス ニーズに合わせた AI エージェント エコシステムが実現し、チームはインフラストラクチャと戦うのではなく、問題の解決に集中できるようになります。

次は: