エンタープライズエージェントプラットフォームのリファレンスアーキテクチャ
貴社の財務チームが、月次決算プロセスを支援するエージェントの構築に成功したと想像してみてください。その結果は有望です。照合時間の短縮、例外の早期発見、そしてチームはデータ入力ではなく分析に集中できるようになりました。この成功を見て、購買チームは発注依頼から注文書までのプロセスを担うエージェントの構築を始めました。カスタマーサービスチームは、苦情解決のためのエージェントを希望しています。IT運用チームは、インシデントトリアージ用のエージェントの設計を開始しました。
各チームは同じ熱意を持ってスタートしました。しかし、それぞれが独自の方法で構築しています。財務チームはスプレッドシートで簡易的なログを作成しました。購買チームは異なるモデルゲートウェイを選択しました。カスタマーサービスチームはコンテキストをローカルファイルに保存しています。IT運用チームは独自の承認メカニズムを作成しました。
局所的に見れば、これらの判断はすべて理にかなっています。しかし、エンタープライズ全体で見ると、その影響が現れ始めます。ツール統合の重複作業、一貫性のないアクセス制御、比較不可能なログと監査、エージェント間の評価の困難さ。かつては進歩のように感じられたものが、徐々に断片化へと変わっていきます。
ここが、企業が問い始めるポイントです。私たちは、いくつかのエージェントアプリケーションを構築しているのか、それとも、エージェントを安全かつスケーラブルに実行するためのエンタープライズプラットフォームを構築しているのか、と。
「各チームが独自に構築する」パターンが問題となる理由
多くの組織は正しいアプローチで始めます。すなわち、価値のあるユースケースを一つ選び、迅速にパイロットを構築し、そのメリットを証明する。問題は、その初期の成功がプラットフォームの規律なしに複製されたときに発生します。各チームが独自のスタック、ログ、制御を用いてエージェントを構築します。結果はエージェントの乱立です。多くのエージェントが稼働しているものの、それらすべてを一貫して管理可能にする共通の基盤は存在しません。
これがなぜ問題なのかを理解するには、しばしば混同される二つの概念を区別する必要があります。
エージェントアプリケーションは、特定のユースケースに対するソリューションです。例えば、買掛金（AP）例外処理のためのエージェント、購買の発注依頼から注文書までのエージェント、顧客苦情解決のためのエージェントなどです。それぞれに、そのドメインに特化したワークフロー、プロンプト、ツール、コンテキスト、UIが含まれています。これは、ビジネスユーザーが直接目にするレイヤーです。
エンタープライズエージェントプラットフォームは、多くのエージェントアプリケーションによって利用される共通レイヤーです。このプラットフォームは、特定のビジネスプロセスを直接解決するものではありません。アイデンティティとアクセス制御、モデルゲートウェイ、ツールレジストリ、コンテキスト検索、可観測性、評価ハーネス、デプロイとロールバック、ポリシー実施、ならびにレジストリとライフサイクルガバナンスといった標準的な機能を提供します。
この区別がなければ、企業はしばしば方向性を誤ります。プラットフォームを構築しているつもりが、実際には再利用が難しいカスタムコンポーネントを多数含む最初のエージェントを作成しているだけ、というケースがあります。また、実際のユースケースなしに汎用プラットフォームの構築に時間をかけすぎて、誰も使わないインフラプロジェクトになってしまうケースもあります。
共通プラットフォームが重要になるのは、スケール時に発生する三つの問題があるからです。第一に、再利用性です。モデルルーティング、パーミッションを認識した検索、監査ログ、承認オーケストレーションといった機能は、エージェントごとに再構築する必要はありません。第二に、制御の一貫性です。すべてのエージェントが同じポリシー実施、可観測性、アイデンティティパターンを通過すれば、ガバナンスははるかに強力になります。第三に、運用効率です。プラットフォームチームはコスト、レイテンシ、インシデント、ライフサイクルを集中的に管理でき、ドメインチームはビジネスロジックに集中できます。
もちろん、すべての組織がすぐに完全なプラットフォームを構築する必要があるわけではありません。企業がまだコアシステムに触れていない1つか2つのパイロット段階であれば、軽量なアプローチで十分な場合もあります。しかし、エージェントがエンタープライズAPIを呼び出し、機密データにアクセスし、アクションを実行し、または部門横断的に使用されるようになると、共通プラットフォームのパターンは贅沢品ではなく、必須の要件となります。
ランタイム：エージェントが実際に実行される場所
リファレンスアーキテクチャの最初のレイヤーは、エージェントがトリガーを受け取り、推論し、コンテキストを取得し、ツールを呼び出し、アクションを生成する場所です。ここに実行ロジックが存在します。
オーケストレーターは、エージェントのワークフローを管理するコンポーネントです。ユーザー、イベント、またはワークフローからのトリガーを受け取り、タスクをステップに分解し、モデルをいつ呼び出すか、ツールをいつ使用するか、人間の承認をいつ求めるか、プロセスをいつ停止またはエスカレーションするかを決定します。単純なユースケースでは、オーケストレーターは軽量で済みます。しかし、財務決済やサプライチェーンの例外管理のようなエンタープライズワークフローでは、プロセスがマルチステップで、ハンドオフが多く、複数のシステムが関与することが多いため、オーケストレーターは重要になります。財務決済では、オーケストレーターは、照合データの取得、例外の分類、コメンタリーのドラフト作成、そしてコントローラーへのルーティングというステップを順序立てることができます。IT運用では、オーケストレーターはイベント監視、診断、Runbook、エンジニアによる承認を組み合わせることができます。
モデルゲートウェイは、しばしば軽視されるコンポーネントですが、非常に重要です。その機能は、単にモデルに接続することだけではありません。特定のタスクに適したモデルを選択し、プライマリモデルが失敗した場合のフォールバックを管理し、標準的なログを適用し、コストとレイテンシを制御し、モデル使用に関するポリシーの一貫性を維持することです。モデルゲートウェイがなければ、各エージェントは異なるパターンで直接モデルを呼び出す傾向があります。その結果、企業はコスト、品質、および監査可能性に対する制御を失います。モデルゲートウェイは、マルチモデル戦略にも重要です。単純な分類タスクには軽量なモデルで十分かもしれませんが、複雑な推論やドキュメント横断的な合成には、より強力なモデルが必要になる場合があります。
エンタープライズエージェントプラットフォームにおけるツールは、自由に使用できるAPIのリストとして扱われるべきではありません。二つの異なるレイヤーが必要です。ツールレジストリは、利用可能なツールのカタログであり、メタデータ、所有者、権限、リスク階層、および使用契約を含みます。ツール実行サービスは、検証後にツールコールを実際に実行するランタイムレイヤーです。エージェントのすべてのアクションは、パラメータ検証、パーミッションチェック、ポリシー評価、監査ログ、そして必要に応じて承認ワークフローを通過する必要があります。これにより、エージェントが適切な制御なしにERP、CRM、HRIS、ITSMに直接アクションを実行することを防ぎます。購買エージェントは購買依頼のドラフトを作成するツールを呼び出せますが、ツール実行サービスは、ベンダーが承認されていない場合、実行を拒否できます。カスタマーオペレーションズエージェントは返金を準備できますが、その値がポリシーのしきい値を超える場合、実行は保留されます。
エンタープライズエージェントが単一のインタラクションで完結することはほとんどありません。ワークフローの状態、前のステップの結果、暫定的な決定、そして場合によっては後続のインタラクションに関連するメモリを保存する必要があります。そのため、アーキテクチャは、決定論的な運用ワークフロー状態のための状態ストアと、エージェントがセッション間またはステップ間で使用できる追加コンテキストのためのメモリサービスを区別する必要があります。多くの実装では、これらすべてをメモリとして混同していますが、ガバナンスの要件は異なります。ワークフロー状態は通常、より厳格で、構造化され、監査が容易である必要があります。メモリはより柔軟である可能性がありますが、それでもパーミッションと保持ポリシーに従う必要があります。
ポリシー実施ポイントは、ランタイムにおいてポリシーの決定が適用される場所です。これは、ツールコール、データアクセス、およびアクション実行の近くに配置される必要があります。明示的な実施ポイントがなければ、ポリシーは単なる文書化されるか、多くのコンポーネントに分散したロジックになってしまいます。エンタープライズにとって、これは脆弱すぎます。
コンテキストとナレッジ：エージェントの品質はここで決まる
エージェントの失敗の多くは、モデルが悪いからではなく、提供されたコンテキストが間違っている、不完全である、古くなっている、またはパーミッションの境界を越えているからです。コンテキストレイヤーは付属品ではありません。これはエージェントの品質の主要な依存関係です。
プラットフォームは、ドキュメント、ナレッジ記事、ポリシー、SOP、トランスクリプト、参照データなどを管理された方法でコンテキストレイヤーに取り込むためのインジェストパイプラインを必要とします。このパイプラインは、抽出、チャンキングまたはセグメンテーション、メタデータのエンリッチメント、機密性の分類、バージョン管理、および更新の同期を処理します。規律あるインジェストがなければ、検索は無関係または時代遅れのドキュメントを取得することになります。
三つのストレージコンポーネントは、それぞれ異なる役割を持ちます。ベクターストアは、非構造化コンテンツのセマンティック検索を支援します。メタデータカタログは構造を提供します。ドキュメントのソース、所有者、有効日、分類、ドメイン、アクセス権などです。ナレッジグラフは、企業がエンティティ間の関係（ベンダー、契約、製品、顧客、アカウント、インシデント、場所、ポリシーなど）を理解する必要がある場合に役立ちます。すべてのユースケースが最初からナレッジグラフを必要とするわけではありません。単純なナレッジアシスタントには、ベクター検索とメタデータで十分かもしれません。しかし、サプライチェーンの混乱、顧客の権利、またはエンティティ間の財務例外など、複雑な関係を含むエンタープライズユースケースでは、グラフによって推論とコンテキストナビゲーションの品質が向上します。
パーミッションを認識した検索は、最も重要な機能の一つです。エージェントは、ドキュメントがセマンティックに類似しているという理由だけでコンテキストを取得するべきではありません。検索は権限を認識する必要があります。すなわち、元のユーザーまたはプリンシパルは誰か、どのエージェントが要求しているか、どのドメインが処理中か、そのコンテキストでどのデータにアクセスできるか、です。HRエージェントは、関連性のない報酬ドキュメントを取得するべきではありません。カスタマーサービスエージェントは、他の顧客の履歴を取得するべきではありません。財務エージェントは、適切なアクセス権なしにエンティティ間のガイダンスを混在させるべきではありません。
優れたエンタープライズエージェントは、ほぼ常に二種類のコンテキストを組み合わせる必要があります。ERP、CRM、HRIS、データウェアハウス、またはイベントストリームからの構造化データと、ドキュメント、メール、SOP、契約、ナレッジベース、またはトランスクリプトからの非構造化データです。プラットフォームは、これら両方を安全に統合できるコンテキストサービスを備えているべきです。AP例外処理では、エージェントは構造化システムからの請求書、発注書、入庫伝票に加え、ドキュメントからのポリシーやケース履歴を必要とします。カスタマーオペレーションズでは、エージェントはCRM/OMSからの権利情報や注文履歴に加え、ナレッジ記事やインタラクションのトランスクリプトを必要とします。コンテキストサービスが弱ければ、エージェントは賢く聞こえても、脆弱な基盤に基づいて行動することになります。
ガバナンスと運用：エージェントを本番運用可能にするために
エンタープライズプラットフォームは、ランタイムとコンテキストだけでは完結しません。エージェントを監査、テスト、そしてライフサイクル全体にわたって管理可能にする、ガバナンスと運用のレイヤーも必要です。
エージェントレジストリは、エンタープライズ内に存在するすべてのエージェントの公式カタログです。最低限、エージェントの名前と目的、ビジネスおよびテクニカルオーナー、リスク階層、ツールとデータソース、自律性のレベル、ライフサイクルステータス、および主要な依存関係を含みます。ポリシーレジストリは、エージェント間で使用されるルールを保存します。取引のしきい値、承認ルール、ツールの制限、リスク分類、特定のドメインポリシーなどです。レジストリがなければ、企業はガバナンスに値するインベントリを持つことができません。
すべてのエージェントに同じ制御が必要なわけではありません。プラットフォームはリスク階層化をサポートする必要があります。アシストモードの内部ナレッジエージェントは、ERPでアクションを実行できるエージェントとは当然異なります。コメンタリーをドラフトするエージェントは、返金や本番環境の是正をトリガーできるエージェントとは異なります。このリスク階層化は、承認ワークフロー、可観測性の深さ、テストの厳格さ、およびリリース管理に結び付けられる必要があります。
ツールコール、ポリシー決定、承認、コンテキスト検索、結果など、すべての重要なトレースは、安全でトレーサブルな監査ストレージに記録される必要があります。これに加えて、プラットフォームは評価ハーネスを必要とします。これは、リリース前後にエージェントをテストするための環境とツールです。これには、ゴールデンデータセット、シナリオテスト、ポリシー準拠テスト、モデルやプロンプト、ツールが変更された際の回帰テスト、および本番後のサンプリング評価が含まれます。評価ハーネスがなければ、企業はエージェントが動作していることしか分からず、品質が向上しているのか低下しているのかを知ることはできません。
運用面では、プラットフォームは、ランタイムヘルスダッシュボード、品質と成果のダッシュボード、技術的インシデント、ポリシー違反、コスト急増のためのアラート、迅速なロールバックまたは無効化メカニズム、ならびにモデル、検索、ツール使用のためのコスト管理を提供する必要があります。エージェンティックシステムは、技術的に失敗するだけではありません。コストが高くなりすぎたり、遅くなりすぎたり、エスカレーションが頻発したり、あるいは静かに意思決定の質を低下させたりする可能性もあります。
合理的な構築順序
プラットフォーム戦略における古典的な誤りは、初日から完全なアーキテクチャを構築しようとすることです。これはほとんどの場合、遅く、高コストで、ビジネスニーズからかけ離れたものになります。より健全なアプローチは、最初のプロダクショングレードのユースケースから生まれた最小限の実行可能なプラットフォームを構築することです。
通常、最も合理的な実践的な順序は、モデルゲートウェイから始めることです。これにより、初期のすべてのエージェントがモデルアクセス、ログ、フォールバック、コスト制御のための標準的な経路を持つことができます。次に、ツールレジストリとツール実行です。エージェントがエンタープライズシステムに触れ始めると、この機能は必須になります。これらがなければ、統合は野放図になり、監査が困難になります。その後、基本的なログ、トレーシング、可観測性です。スケールする前に、企業はエージェントが何をしているか、そのコストとレイテンシを把握できなければなりません。パーミッション実施とポリシーチェックは、エージェントが機密データを読み取ったり、アクションを実行したりし始めたら追加します。評価ハーネスは、モデル、プロンプト、またはツールの変更が頻繁に発生するようになると必要になります。メモリサービスとより成熟したエージェントレジストリは、ユースケースが最初からそれらを必要としない限り、後で構築することができます。
主要な原則は、機能は実際のユースケースから生まれるべきであるということです。複雑な関係を真に必要とするユースケースなしにナレッジグラフを構築すれば、それはほとんど使われない高価な資産になるリスクがあります。エージェントが依然としてタスクベースでステートレスであるにもかかわらず、高度なメモリサービスを構築するのも時期尚早です。健全なプラットフォームは、実際のニーズから成長しますが、一貫したアーキテクチャパターンを持ちます。
例えば、企業が二つのユースケース、すなわちシェアードサービスにおけるAP例外処理とIT運用におけるインシデントトリアージから始めたとします。これら二つのユースケースから、企業は最も差し迫った共通のニーズが、モデルゲートウェイ、ツールレジストリ、可観測性、パーミッションを認識した検索、および承認ワークフローであることに気付くかもしれません。一方、完全なナレッジグラフやエージェント間のメモリは、まだ差し迫っていないかもしれません。このようにして、プラットフォームは機能リストではなく、実際の経済性とリスクに基づいて成長します。
優れたリファレンスアーキテクチャとは、紙の上で最も完全なものではなく、企業が一つのシンプルな質問に自信を持って答えられるようにするものです。すなわち、「もし明日、財務、購買、カスタマーオペレーションズ、ITに10の新しいエージェントを追加したとしても、それらを安全に、スケーラブルに、そしてエージェントの乱立を引き起こさずに実行するための共通の基盤があるだろうか？」という質問です。
もし答えが「まだない」のであれば、次の優先事項はエージェントを追加することではなく、プラットフォームを強化することです。