ThoughtSpotのプロダクトマネジメント担当上級副社長であるフランソワ・ロピトー氏は、インテリジェントな体験のためのAI分析製品の戦略と実行を主導しています。
前回の記事では、エージェントオーケストレーションの概念とAIの可能性を最大限に引き出すための重要性について紹介しました。今回は、エージェントオーケストレーションについてさらに掘り下げ、ベストプラクティスの実装方法と一般的な落とし穴を回避するための実用的な提案を行います。
エージェントオーケストレーションは基盤となるものですが、正しく実装するのは難しいものです。そのため、実証済みのステップに従うことが非常に重要です。本稿では、適切な基盤アーキテクチャの選定から本番環境への完全移行まで、エージェントオーケストレーションの取り組みに関するあらゆる側面を解説します。
将来を見据えた構築方法、ユーザーの信頼を確立する方法、優れた体験を提供する方法、そして将来的な規制遵守への準備方法について説明します。また、正しい方向に進んでいることを示す良い兆候と、下流での問題を示す可能性のある一般的な警告サインについても紹介します。
ベストプラクティスとその実装方法
アーキテクチャを選択する。
エージェントオーケストレーションに使用する基盤フレームワークを特定します。利用可能な製品を調査・テストして、組織のエージェントオーケストレーションの目標を最もよくサポートするものを決定します。まず、汎用フレームワークか専門プラットフォームかを選択します。汎用フレームワークは、OpenAI GPT-4、Google Gemini、Anthropic Claude、Azure OpenAIなど、幅広い大規模言語モデル（LLM）と統合する柔軟性を提供します。これらは幅広いユースケース向けに設計されており、必要に応じてツールやモデルを組み合わせることができます。
対照的に、専門プラットフォームは、分析やビジネスインテリジェンス向けに特化したオーケストレーション層を提供します。これらのよりエージェント指向のアーキテクチャには通常、推論エンジン、オーケストレーション層、エージェントビルダーが含まれており、すべてがデータ中心のタスク向けに最適化され、クエリ、分析、可視化のための事前構築されたスキルが付属しています。
サブエージェントを選択する。
これらの目標に関連するタスクを完了するための適切なサブエージェントを特定します。最終的に、エージェントオーケストレーターは、選択したサブエージェントやツールとうまく連携できれば成功します。これらのツールの中には、すでにエージェントが組み込まれているものもあれば、アドオンが必要なものもあります。現在市場に出ているすべてのアプリケーションが本質的にエージェント指向というわけではありません。
相互運用性を優先する。
日々新しいソリューションが登場する中、自社の実用的な問題を解決しようとすると、それらに気を取られがちです。明日、もっと良いものが登場したらどうしますか？この分野は急速に変化する未開拓のフロンティアです。モジュール式のアーキテクチャ、つまり必要に応じて一つのモジュールを簡単に別のものに置き換えられるアーキテクチャを見つけましょう。単一のLLMや一つのモデルに縛られたくはありません。技術環境が進化するにつれて、より高度な技術やソリューションを活用できる自由が欲しいはずです。
アクセスが鍵となる。
組織のデータが価値のある形で利用できるようにします。つまり、サブエージェントにどこへのアクセスを与えるかによって、それらが意図した目的をどのように、そしてどれだけ効果的に果たすかが決まります。情報を取り込み、あなたの代わりに行動するエージェントもあれば、問題を解決するためにより手動でのアクセスを必要とするエージェントもあります。最終的に必要なツールセットは、達成したい成果によって異なります。
適切なガバナンスを実践する。
下流の監査要件に備えるため、誰が何を使用しているかを含め、すべての会話を追跡できるようにします。組織が選択したエージェントやLLM内で特定のデータを使用することに安心できるようにし、必要に応じて個人を特定できる情報（PII）を制限します。精度を測定し、時間の経過とともに精度の段階的な向上を検証できる評価セットを作成します。
ユーザー体験を考慮する。
エンドユーザーに提供したいユーザー体験のタイプを考えましょう。例えば、グローバルエージェントを使用してエージェント型アプリケーションに接続すると、そのアプリケーションのUIに関連するグラフィックスや可視化を失う可能性があります。ユーザー体験はシステム構築の方法を導くべきです。
一般的な落とし穴とその回避方法
大きく始めて、大きく失敗する。
すべての問題を一度に解決しようとしないでください。単一のユースケースから始めましょう。これは新しい技術を導入する際の一般的なアドバイスです。小さく始めて、成功のための再現可能なプロセスができたら、フットプリントを拡大していきましょう。現在時間がかかりミスが発生しやすい、予測可能で比較的単純で反復的なタスクに焦点を当てましょう。
静止していることが致命的になりうる。
組織が思っている以上によく遭遇する落とし穴の一つは、単に十分な行動を取らないことです。リスクを取ることを恐れたり、データを過度に保護したりする組織は、意味のある結果を生み出すための十分な実験を行わないことがよくあります。好きなだけ実験を行うことはできますが、アプリケーションを本番環境に投入しなければ、価値のある成果を生み出すことはできません。
不正確さは大きな警告サイン。
単一のオーケストレーターの下で複数のエージェントを扱う場合、一見わずかな不正確さが原因で大きく方向性を誤るものを構築するのは非常に容易です。エージェントごとに5%のエラー率があると想像し、それを10のエージェントに掛けると、すぐにシステムはユーザーが信頼できない結果を生成することになります。精度に関するガードレールを設けることが不可欠です。そうでなければ、人々はそのツールを使用しなくなります。
大局的視点：信頼と透明性が最も重要
以前の職業的役割で、金銭的融資を承認または拒否することを目的とした機械学習（ML）モデルの構築とトレーニングを支援しました。答えは二者択一でした—はいかいいえか—しかし、どのようにその結論に達したのかについての洞察はありませんでした。それは完全なブラックボックスでした。今日、MLモデルには透明性が組み込まれています。どの決定がなされ、なぜそうなったのかをユーザーに伝えるため、ミスが発生した場合に特定できます。LLMやエージェントでも同じレベルの透明性を達成する必要があります。エージェントが信頼され、精度を監査し、最終的に出力を改善するためには、その作業過程を示す必要があります。
透明性を通じた信頼の構築は、人間をループに保つことです。LLMは本質的にインテリジェントではありません。それらはプロンプト、メモリ、そしてそれらをインテリジェントにするために使用しているツールに依存しています。信頼、透明性、説明責任を優先することで、ユーザーは成果を達成し、組織は将来的に確実に訪れる新たな規制要件に対してより良く準備することができます。
