エージェントの構築パート2: DatabricksとOpenAI Agents SDKを用いたマルチエージェントアプリケーションの構築とデプロイ

[Build Multi\-agent Apps with Databricks & OpenAI \| Medium](https://medium.com/@AI-on-Databricks/building-agents-part-2-build-and-deploy-multi-agent-applications-with-databricks-and-openai-agents-7c4cae81caf4)の翻訳です。

:::note warn
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*3NvnNIC70a9Tg6P9)

著者: Sathish Gangichetty (Lead Solutions Architect @ Databricks), Usman Zubair (Lead Solutions Architect @ Databricks), Samaya Madhavan (Sr. Solutions Architect @ Databricks)

[パート1](https://qiita.com/taka_yayoi/items/25709cfb38744c219790)では、ツールとして接続されたGenieスペース(エージェント)と、(agent-as-a-toolパターンの)単一のツール呼び出しエージェントをデプロイするために何が必要なのかを見てきました。我々はこれによって得られる利点を検討し、組織がインセンティブを適切に整合させられるようになることを確認しました。つまり、ファイナンス部門の担当者であれば、サプライチェーン分析のGenie Spaceを気にすることなく、自身のファイナンス用Genie Spaceの品質を維持できるということです。その結果、自分が最も重視する領域の健全性を保つために、指標の定義、ルールの適用、評価やベンチマークの実行などを自由に行うことができます。

これでも十分良いのですが、ここではもう少しレベルを引き上げたいと考えています。ここまでに示したものは、**「<ins>データインテリジェンス</ins>」の強み**です。現実的な話としては、**これ単体では不十分です**。多くの環境においては組織は、汎用的なインテリジェンスを自社のドメイン固有のデータインテリジェンスと組み合わせて活用する必要があります。たとえば前回のブログでは、当社のエージェントが「先月の店舗Xの売上総額は？さらに、同じ店舗における製品Yの現在の発注残数は？」といった質問に対応できることを紹介しました。質問を2つのツールの呼び出しに分解し、対応するGenieルームに問い合わせを行い、のちの結果合成に結果を引き渡しました。しかし、「店舗Aと店舗Bの位置とデモグラフィックに基づくと、今年のこのタイミングにおいて、どこでゴルフ用品の特売を行うべきか？」というような質問をエージェントが受けた場合には何が起きるのでしょうか？これには、より深い計画が必要となります。

エージェントは店舗の位置を特定し、(国勢調査ACSのデータ)のデモグラフィック情報、そして、ExperiaやLexisNexisの有料データを持っているのであればそれら2つを比較し、2つの一のどちらがよりゴルフ用品に興味を持つ人の来店を見込めるのかを理解し、現在の季節性のパターン(時期の効果、地域のイベントなど)を理解し、一連の推奨事項と観点をユーザーに提示する必要があります。

目的に応えるために、今回は「データインテリジェンス」と「マーケットインテリジェンス」の両方を活用し、戦略的意思決定のサイクルタイムを短縮するマルチエージェントシステムの構築方法をご紹介します。

> 未来の企業: 実際に互いに会話を行うマルチエージェントシステム

# 単一エージェントの思考における問題

ほとんどの素晴らしい人間の専門家たちは自身の領域に特化しています。金融アナリストは、デモグラフィックデータを解釈するベストな人物ではなく、市場リサーチャーはサプライチェーン分析のニュアンスを理解できないでしょう。もちろん、このようにエージェントをセットアップすることは可能ですが、品質に関しては、時間が経つにつれて効果が徐々に低下していくでしょう。

上で強調した問題に対するソリューションには、異なるアプローチが必要となります。単体の忙しくしているエージェントの代わりに、引き継ぎ、委任、協調が可能なマルチエージェントシステムにたどり着くことになります。おおまかなデザインは以下のようになります。

**トリアージエージェント** - このエージェントは、ユーザーのクエリーの分析と、リクエストに対応するには、エンタープライズインテリジェンスエージェントやマーケットインテリジェンスエージェントのような他のエージェントのどれを使うのがベストなのかを決定することに責任を持ちます。マルチエージェントシステムにおけるコンタクトポイント、適切な専門家エージェントへのルーティングとして動作します。自分自身がユーザークエリーに対応するのがベストな場合、クエリーがスペシャリストの関与を必要な場合にはルーティングしないことを選択することも可能です。この例は、ユーザーがやり取りの要約を選択した場合などです。

**エンタープライズインテリジェンスエージェント** - これは、あなたの内部オペレーションのエキスパートです。あなたの会社のデータに根ざして動作し、[Databricks Genieスペース](https://www.databricks.com/jp/product/business-intelligence/ai-bi-genie)を通じた店舗パフォーマンス分析や在庫トラッキング、ツール呼び出しによるビジネスポリシーの問い合わせなどの全てに対応します。決して眠らず、あなたがこれまでに生成した内部データのすべてのピースに対して即座にアクセスできる、最も知識に富んだシニアアナリストを思い浮かべてください。

**マーケットインテリジェンスエージェント** - これは、あなたの外部世界の専門家です。国勢調査APIからリアルタイムのデモグラフィックデータを引き出し、人口トレンド、家族収入パターン、教育レベル、持ち家率を分析します。しかし、もっと面白いのは、複雑な市場リサーチの質問の推論のためにPerplexity APIを活用し、実質的にはインターネット全体から情報を合成できるリサーチチームを提供するということです。このようなセットアップにおけるアーキテクチャ図を以下に示します。

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*6uMA7VbTdgMDskPk)

# コラボレーションで生じる魔法

本当にエキサイティングなのはここからです。これらのエージェントは割り当てられたタスクに取り組むだけではありません。それらは、ツールとして互いに呼び出すことができます。これは多くの場合、複雑な問題のブレークダウンや、マクロな検索クエリーに文脈を与えるためにドメインインテリジェンスに根拠を与える際に必要となります。

「別の州にある類似の店舗と比較して、なぜ店舗110のパフォーマンスが悪いのか？」という質問をした際、背後では以下のようなことが起こります:

1. トリアージエージェントは、あなたのクエリーを解析し、このクエリーは主にエンタープライズインテリジェンスエージェントによって対応できると判断します。
1. エンタープライズインテリジェンスエージェントは店舗パフォーマンスデータ、売上トレンド、オペレーションメトリクスを調査します。
1. しかし - ここが魔法です - デモグラフィックの文脈が必要であることを理解し、ツールとしてマーケットインテリジェンスエージェントを呼び出します。
1. マーケットインテリジェンスエージェントは、店舗の位置の国勢調査データを引き出し、(オプションで)地域の経済状況を分析し、この文脈を返却します。
1. 結果として、**これらは単一のエージェントでは提供できないであろう回答を合成します。**

これらのタイプの複雑で複合的な質問に正確に回答するには、エージェントツール横断での文脈に基づいた実行が必須であり、エージェント間のコラボレーションが必要となります。さもないと、エージェントの一つによって捏造された正しくない回答に直面することになります。

# 本システムへのアクセス

我々はこのシステムを、それぞれが異なるユースケースや利用者に最適化された2つの異なるインタフェースを通じてアクセスできるように構築しました:

**CLIツール** - ターミナルで生活しているアナリストやデータサイエンティストにとって完璧なものです。プログレスインジケータ、エージェントの処理の追跡、詳細なロギングを用いたリッチで整形されたアウトプットを提供します。クイックな洞察のために単一のクエリーを実行したり、より深い探索のためにインタラクティブなセッションを起動したりすることができます。あなたの最も知識に富んだ同僚と会話するようなものですが、例外は彼らはあなたの組織のすべてのデータにアクセスできるということです。

<iframe width="560" height="315" src="https://www.youtube.com/embed/YIofyKLdi5k?si=lirFY38TSokN3asv" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

**Databricks上のStreamlitアプリ** (上のデモで提示) - ここにこそ、エンタープライズ導入の美しさがあります。ウェブインタフェースは、リアルタイムのエージェントの処理の可視化を提供するので、実際にエージェントがコラボレーションする様子を観察できます。しかし、ここにこそ企業向けの“金脈”があります: [Databricks Apps](https://www.databricks.com/jp/product/databricks-apps)は[アプリケーションレベルの認証](https://docs.databricks.com/aws/ja/dev-tools/databricks-apps/auth#%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AE%E8%AA%8D%E8%A8%BC)と[ユーザーベースの代理認証](https://docs.databricks.com/aws/ja/dev-tools/databricks-apps/auth#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E8%AA%8D%E8%A8%BC)の両方をサポートしています。これは、あなたの経営層が洞察を得ることを可能に歯痛も、データガバナンスに準拠することを意味します - ユーザーは参照を許可されたものしか見ることはできず、システムは完全な監査証跡を保持します。ここで、Databricksへのアプリデプロイにおける重要な機能が真価を発揮します - 代理認証です。しかし、その前に、デモをクイックに参照し、アプリが何をするのかを見てみましょう。

<iframe width="560" height="315" src="https://www.youtube.com/embed/ek-ypuI4tQk?si=7JM_ioHPCVzzDtEW" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

# 代理認証: 動作原理と必要なわけ

カスタムソフトウェアの構築やメンテナンスは、つなぎ合わせや管理のオーバーヘッドによって常に高コストなものになっていました。Databricks AppsとUnity Catalogの組み合わせによって、データだけではなく、モデルサービングやベクトルサーチエンドポイントによって、これを簡単なものにします。

- **代理ユーザー認証:** アプリのサービスプリンシパルに幅広の権限を付与するのではなく、アプリはリソースにアクセスするためにユーザーの認証情報を使用します。これは、ハードコードすることなしに、行レベルのフィルターや列マスクのような既存のきめ細かいアクセス制御を活用しています。
- **一貫性のあるガバナンス:** すべてのデータのクエリー、モデルの推論、ベクトルインデックスの呼び出しは、Unity Catalogで定義されたポリシーに準拠し、コンプライアンスと監査可能性を確実にします。
- **テーブルを越えて:** ユーザー認証はモデルサービング、関数、ベクトルサーチエンドポイント、ユーザーが起動可能なDatabricksジョブすらも含めたセキュリティ保護オブジェクトに拡張され、すべての資産タイプにおけるガバナンスを統合します。
- **ハイブリッド認証モード:** サービスプリンシパルと代理モードを組み合わせます。例えば、サービスプリンシパルを用いてアプリが監査ログを書き込み、ユーザーの認証情報でユーザー固有のデータにクエリーをします。
- **APIによるアプリのチェーン:** アプリとサービス間でのOAuthトークンの転送によって、カスタムの認証コードなしに複雑なマルチサービスワークフローを実現します。

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*XP3Rn_MVQd-04YnV)

ユーザーがアプリを起動すると、彼らの代理として動作する承認が求められ、すべてのクエリーやアクションが自身のUnity Catalogの権限を継承するようにします:

![](https://miro.medium.com/v2/resize:fit:770/format:webp/0*1vuJiO_oEHOsXFan)

我々のRetailOps Intelligence Appが店舗マネージャに展開されるシナリオを考えてみましょう: マネージャはログインして質問します。「先週、私の店舗で最も売れなかったSKUトップスリーはどれか、来月の在庫を最適化するためにどれだけのユニットを注文すべきか？」内部では、このアプリは売上データにクエリーするために代理認証を用い、それぞれのマネージャ自身の店舗の結果のみを参照できるようにする行レベルのフィルターが適用されます。そして、これもUnity Catalogで管理されている予測モデルを呼び出し、これらのSKUの最適な注文数を予測します。すべてのやり取りやメトリクスは、アプリのサービスプリンシパルによって、集中管理される監査テーブルに記録され、完全なトレーサビリティとガバナンスを実現します。

# 未来にあるのはコラボレーティブインテリジェンス

このシステムにおいて我々を最も興奮させるのは技術ではありません - 開かれている可能性です。人間が異なるデータソース間の結合組織になる必要があった世界から、複雑な問題に対応するためにAIエージェントが自然にコラボレーションし、自身の専門性を持ち寄る世界へと移行しています。

最初に小売業の経営者と言いましたか？このシステムによって、彼らは店舗パフォーマンスに関する答えを得るだけではありません - 内部のオペレーション、市場の状況、競合のダイナミクス、デモグラフィックのトレンドにまたがる洞察を獲得します。すべては、数週間ではなく数分でもたらされます。

これが、エンタープライズインテリジェンスの未来です: 特化され、コラボレーティブで、無限にスケーラブルです。ここでの質問は、あなたの組織がマルチエージェントシステムを導入するかどうかではありません - 最初にこれらのパワーを活用するか、後でキャッチアップするのかどうかです。

ご自身のユースケースに適応できるように[こちらにコード](https://github.com/datasciencemonkey/multi-agent-system-databricks)があります。

### はじめてのDatabricks

[はじめてのDatabricks](https://qiita.com/taka_yayoi/items/8dc72d083edb879a5e5d)

### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)