エージェンティックエンタープライズアーキテクチャとは
あなたの会社の経理部門が、月次決算プロセスを実行しているところを想像してみてください。データはERP、メールで送られてくるスプレッドシート、そしてシェアードサービスからの手作業による記録に散在しています。調整、異常値の確認、承認の取得には数日を要します。ここで、決算スケジュールを監視し、調整データを未提出の部門を検出し、不審な仕訳を分析し、複数のシステムから証憑を収集し、コントローラー向けの推奨事項を準備する——これらすべてを、数日ではなく数分で実行できる何かがあったとしたらどうでしょうか。
魅力的に聞こえます。しかし、すぐに疑問が湧きます。どうやって実現するのか？ このような仕組みを、単なる印象的なデモで終わらせず、企業で実際に稼働させるためには、何を準備する必要があるのか？
この疑問こそが、エージェンティックエンタープライズアーキテクチャという概念へと私たちを導きます。この用語は技術的に聞こえるかもしれませんが、その本質は極めて実務的です。これは、企業が既存のシステムの上にAIエージェントをどのように配置するか、エージェントがどのようにビジネスコンテキストを理解するか、エンタープライズシステムを通じてどのように行動するか、そしてそれらの行動全体を安全かつ監査可能、そしてスケーラブルにするためにどのように制御するかについての設計図です。
明確なアーキテクチャがなければ、企業は通常、2つの極端な状態のいずれかに陥ります。1つ目の極端な状態は、AIが単なる優秀な回答ができるチャットボットに留まり、実際の作業を完了できない状態です。2つ目の極端な状態は、エージェントにシステムやデータへの過度に広範なアクセス権を、適切な制御なしに与えてしまう状態です。どちらも同様に問題です。
なぜこれは単なる賢いチャットボットではないのか
多くの組織は、エージェンティックAIを生成AIの自然な延長線上にあるものと見なしています。つまり、より賢いモデル、より優れたプロンプト、より便利なインターフェースという認識です。この見方はあまりにも狭すぎます。
現在起きている変化は、むしろエンタープライズプラットフォームの進化に近いものです。これまで、ERP、CRM、HRIS、ワークフローエンジンは、取引と制御の基盤となってきました。これらのプラットフォームは、プロセスの標準化のために構築されています。安定したルールには強力ですが、システム間のオーケストレーション、例外処理、動的なコンテキストを必要とする運用上の意思決定には柔軟性が不足しています。
エージェンティックAIは、これらのプラットフォームの上に位置する、新たなオーケストレーション層としての役割を担い始めています。これはERPやCRMを置き換えるものではありません。目的を理解し、様々なソースからコンテキストを取得し、ツールやAPIを呼び出し、複数段階のワークステップを実行し、必要に応じて人間の承認を求めるために停止することができる、インターフェース兼実行基盤となるのです。
したがって、エージェンティックエンタープライズアーキテクチャは、AIの機能に関するトピックではありません。これは、企業アーキテクチャのトピックです。すなわち、AIがどこに存在し、どのようにプラットフォームに接続され、どのようにデータにアクセスし、その行動がどのように統制されるか、という問題です。
エージェントをチャットボットから区別する3つの要素
簡単に言えば、エージェンティックエンタープライズアーキテクチャとは、AIエージェントがコンテキストを理解し、限定された意思決定を行い、エンタープライズツールを通じて行動することで、特定のビジネス成果を達成することを可能にするシステム設計です。ここには3つのキーワードがあります。
第一に、コンテキストを理解すること。 エンタープライズのコンテキストなしにプロンプトを受け取るだけのエージェントは、実際の運用では役に立ちません。企業において、コンテキストとは、取引データ、ドキュメントやナレッジベース、プロセスメタデータ、インタラクション履歴、ポリシールール、ワークフローステータス、そしてユーザーやユニットのアクセス権限の組み合わせを意味します。例えば、調達プロセスにおいて、エージェントが滞留している請求書があることを知っているだけでは不十分です。どのベンダーが関与しているか、POが有効か、価格に不一致がないか、そのカテゴリの承認者は誰か、適用される許容ポリシーは何か、そして同様のケースが過去に発生したことがあるか、といった情報も必要です。
第二に、限定された意思決定を行うこと。 「限定された」という言葉は非常に重要です。健全なエージェンティックアーキテクチャは、エージェントが何でも決定してよいという前提に基づいて構築されるわけではありません。むしろ、明確な意思決定の範囲を持って設計されます。エージェントは、ITチケットを分類し、初期診断用のRunbookを実行することができます。エージェントは、修正仕訳のドラフトを作成し、証憑を準備することができます。エージェントは、ポリシーに基づいて債権回収フォローアップのアクションを提案することができます。しかし、エージェントは、追加の制御なしに、ベンダーマスタを変更したり、大口支払いを承認したり、重大インシデントをクローズしたりすることは自動的にはできません。
第三に、エンタープライズツールを通じて行動すること。 これがチャットボットとの最大の違いです。チャットボットは回答します。エージェントは行動します。行動するとは、ツール呼び出し、API、ワークフローエンジン、ロボティックアクション、またはアプリケーション統合を使用して、実際のシステムで何かを実行することを意味します。すなわち、チケットを作成する、CRMを更新する、承認をトリガーする、ERPからデータを取得する、クエリを実行する、他のプラットフォームに指示を送信する、といったことです。
つまり、エージェンティックエンタープライズアーキテクチャとは、すべてを知っている単一のスーパーエージェントを構築することではありません。その目的は、制御可能で、モジュール化され、スケーラブルなエージェントのエコシステムを構築することです。
アーキテクチャを構成する3つの層
このアーキテクチャを理解する最も有用な方法は、それを3つの層として見ることです。すなわち、エージェント層、コンテキスト層、そして制御層です。これらの下には、企業のデジタルコア、つまりERP、CRM、HRIS、データプラットフォーム、ワークフローエンジン、その他の運用アプリケーションが存在します。
エージェント層：誰が何を行うのか
すべてのエージェントが同じ役割を持つ必要はありません。最も一般的な設計上の誤りの一つは、すべてのニーズに対応する単一の汎用エージェントを作成することです。結果は概して芳しくありません。制御が難しく、テストが難しく、ビジネス部門からの信頼を得るのも困難です。
より健全なアーキテクチャは、いくつかのタイプのエージェントを区別します。オーケストレーターエージェントは、複数のステップや複数のエージェントにまたがるワークフローを管理します。各ドメインで最も専門的である必要はありませんが、作業の順序、いつ専門エージェントを呼び出すか、いつツールを呼び出すか、そしていつ人間にエスカレーションするかを理解しています。決算プロセスでは、オーケストレーターは決算カレンダーを監視し、調整データを未提出の部門を検出し、仕訳の異常分析のために専門エージェントを呼び出し、シェアードサービスに証憑を要求し、重要な例外事項を承認のためにコントローラーに送信します。
専門エージェントは、特定のドメインに焦点を当てます。例えば、調達ポリシーエージェント、契約分析エージェント、カスタマークレームトリアージエージェント、ITインシデントの根本原因分析エージェント、サプライチェーン例外解決エージェントなどです。その利点は、範囲がより狭く、知識がより特化され、評価がより容易であることです。
タスクエージェントは、より原子的で反復的なタスクを処理します。例えば、請求書からデータを抽出する、ドキュメントを標準と比較する、ケースの要約を作成する、システム内の特定のフィールドに入力する、オンボーディングデータの完全性を検証する、といったタスクです。タスクエージェントは、ルールが比較的明確な、大量の作業に適しています。
ヒューマンインターフェースエージェントは、従業員、マネージャー、ベンダー、顧客など、人間と直接対話します。チャット、ポータル、メール、音声、社内ワークスペースなどに存在できます。しかし、その役割は単なる会話ではありません。それは、より広範なエージェンティックシステムへの入り口となります。人事業務において、従業員が経費精算のステータスについて質問したとします。ヒューマンインターフェースエージェントは質問を理解し、本人確認を行い、システムからステータスを取得し、遅延の理由を説明し、必要に応じて不足書類を確認するためにタスクエージェントを起動します。
このように役割を分離することは、制御の設計、テスト、および所有権の明確化を容易にするため、重要です。
コンテキスト層：エージェントが企業の世界を理解する方法
エージェントは、コンテキストが浅ければうまく機能しません。そのため、コンテキスト層は、印象的なデモと実際に有用な本番システムとの違いを生み出すことがよくあります。
多くの組織は、エージェントにドキュメント、SOP、ポリシー、マニュアル、ナレッジベースへのアクセスを提供するために、検索拡張生成（RAG）から始めます。これは、特にサービスデスク、法務オペレーション、ポリシーサポートといった知識集約型のユースケースにおいて、理にかなった最初のステップです。しかし、複雑なエンタープライズプロセスには、RAGだけでは不十分なことがよくあります。
実際の運用では、エージェントはエンティティ間の関係を理解する必要があります。つまり、顧客はどの契約に関連するか、請求書はどのPOに関連するか、資産はどの場所に関連するか、ユーザーはどのロールに関連するか、サプライヤーはどのリスクカテゴリに関連するか、といったことです。ここで、ナレッジグラフやエンタープライズリレーショナルモデルが役立ちます。これらは、エージェントがドキュメント形式だけでなく、ビジネスオブジェクト間の関係も含むコンテキストをナビゲートするのに役立ちます。
優れたエージェントは、現在のドキュメントを読むだけではありません。過去の意思決定、これまでに発生した例外のパターン、過去のインタラクションの結果、ユーザーの好み、以前の行動の成果も記憶する必要があります。しかし、エンタープライズにおけるメモリは、無制限で自由な記憶として理解されるべきではありません。それは、何を、どのくらいの期間、どのような目的で、誰がアクセスできるのかという、アーキテクチャ上の資産として管理されなければなりません。
しばしば見落とされるコンポーネントの一つは、パーミッションを認識した検索です。企業においては、すべてのコンテキストが、すべてのエージェントによって、すべてのユーザーに対して取得できるわけではありません。検索は権限を認識する必要があります。人事エージェントは、許可なく従業員間の報酬データを表示してはなりません。調達エージェントは、すべての要求者に対して戦略的契約を開示してはなりません。経理エージェントは、ユーザーにアクセス権限がなければ、特定の部門のデータを取得してはなりません。検索のパーミッションモデルが成熟していなければ、エージェントは非常に危険なデータ漏洩経路となり得ます。
制御層：企業がどのように制御を維持するか
エージェントが「回答する」ことから「行動する」ことへと移行するにつれて、制御層の重要性は増します。これはコンプライアンスのおまけではありません。アーキテクチャの中核です。
エージェントは明確なアイデンティティを持つ必要があります。企業は、どのエージェントが、誰の代理として、どのようなアクセス権限で、どのシステム上で、どのプロセスのコンテキストで行動しているかを把握できなければなりません。原則は単純です。エージェントに、そのタスクの範囲に必要なものよりも広いアクセス権を決して与えてはなりません。請求書例外処理用のエージェントにERPの全モジュールへのフルアクセス権を与えた場合、問題はAIにあるのではなく、アーキテクチャの設計にあります。
すべてのアクションが直接実行可能であるべきではありません。一部はポリシーに従う必要があります。取引金額のしきい値、機密データの種類、モデルの信頼度、リスクカテゴリ、または業務への影響などです。そのため、アーキテクチャは明示的な承認ワークフローをサポートする必要があります。エージェントは推奨事項と証憑を準備できますが、特定のケースにおける最終的な決定は人間に委ねられるべきです。
エージェントのすべてのアクションは追跡可能でなければなりません。最低限、企業は次の質問に答えられる必要があります。どのエージェントがアクションを実行したか、どのデータが使用されたか、どのツールまたはAPIが呼び出されたか、どのポリシーが適用されたか、どのような出力が生成されたか、そして承認があった場合は誰が承認したか。監査証跡がなければ、企業はインシデントを説明したり、エラーを修正したり、規制当局や監査人の信頼を構築したりすることができません。
エージェンティックシステムは、一度テストして本番にリリースすれば終わり、というわけにはいきません。継続的な評価が必要です。エージェントの判断はまだ正確か、ツール呼び出しは頻繁に失敗していないか、レイテンシーがSLAを妨げていないか、エージェントが頻繁にエスカレーションしすぎていないか、出力品質にドリフトが生じていないか。ランタイムモニタリングも、ループの繰り返し、過剰なツール呼び出し、通常のパターンから外れたアクションなど、予期しない動作を検出するために重要です。
健全なアーキテクチャと脆弱なアーキテクチャを分ける設計原則
構成要素を理解したところで、次の疑問は、健全なアーキテクチャと脆弱なアーキテクチャを分ける設計原則は何か、ということです。
モデルの能力から始めるのではなく、スコープから始める。 多くの技術チームは、最も高度なモデルから始めて、それに適合する問題を探すという誘惑に駆られます。エンタープライズのアプローチは逆であるべきです。ビジネス成果から始め、エージェントの作業範囲を定義し、その後で必要な能力を選択します。カスタマー返金用の低リスクエージェントに、サプライチェーン再計画用のエージェントと同じ能力は必要ありません。明確なスコープは、設計をより安全にし、本番化をより迅速にします。
すべてのアクションは説明可能かつ追跡可能でなければならない。 エンタープライズにおいては、エージェントが成功したというだけでは不十分です。組織は、どのようにしてその結果に至ったかを知る必要があります。エージェントが顧客のクレームを却下した場合、組織はその根拠となったポリシー、使用されたデータ、および却下またはエスカレーションを引き起こした判断ポイントを確認できなければなりません。
ヒューマンオーバーライドは、緊急時のフォールバックではなく、中核機能であるべき。 成熟したエージェンティックアーキテクチャは、人間が介入しなければならない状況が存在することを常に前提としています。すなわち、信頼度が低い、データが不完全、ポリシーがアクションを禁止している、例外が複雑すぎる、ビジネスへの影響が大きすぎる、といった状況です。ヒューマンオーバーライドは失敗の兆候ではありません。それは健全な運用設計の一部です。
アーキテクチャはグレースフルデグラデーションをサポートすべき。 モデルが失敗したとき、ツールが利用できないとき、または検索が十分なコンテキストを見つけられなかったとき、システムは完全に停止すべきではありません。自律的なアクションから推奨へ、マルチステップ実行からドラフト出力へ、セルフサービスから人間へのハンドオフへと、優雅に機能を低下させることができなければなりません。これは、厳格なSLAが求められるIT運用、決算、カスタマーオペレーションなどの重要なプロセスにおいて特に重要です。
モノリシックよりもモジュール式が優れている。 モジュール式のエージェントエコシステムは、すべてをこなす単一の大きなエージェントよりも、テスト、交換、ガバナンスが容易です。モジュール性はまた、企業がベンダー、モデル、およびプロセスの変更を時間の経過とともに管理することを容易にします。トレードオフとして、モジュール性はオーケストレーションの必要性を高めます。しかし、大企業にとっては、このトレードオフは通常、リスクの集中を減らし、スケーリングを容易にするため、価値があります。
エンタープライズワークフローへの適用例
あまり抽象的にならないように、いくつかの簡単な例を見てみましょう。
決算プロセスにおいて、優れたエージェンティックアーキテクチャは、エージェントにいきなり帳簿を閉じる権限を与えたりはしません。より現実的なのは、タスクエージェントが調整データを取得して例外を検出し、専門エージェントが仕訳の異常を分析し、オーケストレーターが重要性と期限に基づいて優先順位を付け、ヒューマンインターフェースエージェントがコントローラーとコミュニケーションを取り、承認ワークフローが特定の仕訳については人間の承認を確実に行う、という流れです。価値は、完全な自律性からではなく、オーケストレーションの迅速化と例外処理から生まれます。
調達において、エージェントは、要求の受付を分類し、購買ポリシーをチェックし、ベンダーオンボーディングを検証し、POドラフトを準備し、単純な請求書不一致を処理することができます。しかし、戦略的カテゴリ、契約交渉、またはベンダーマスタの変更については、完全な自律性よりも、範囲が制限された自律性（バウンデッド・オートノミー）の方が適切です。
IT運用において、エージェンティックアーキテクチャは、可観測性とRunbookがすでに整備されている場合に非常に適しています。エージェントは、アラートを監視し、関連するログを収集し、初期診断を実行し、インシデントを起票し、低リスクの是正措置を実行することができます。しかし、CMDBが乱雑で、Runbookが標準化されておらず、管理者アクセス権が整理されていない場合、エージェントはむしろ混乱を加速させます。
よくある間違い
多くの組織は、デモでは洗練されて見えるが、実際のワークフロー、SLA、意思決定権限に接続されていないエージェントを作成します。結果として、エージェントはたまに使われるだけで、決して運用の一部にはなりません。エージェントがエンドツーエンドのプロセスに接続されていなければ、それは実行層ではなく、単なる追加層に過ぎません。
すぐに結果を示したいという思いから、チームはしばしば過度に広範なサービスアカウントを付与します。短期的には統合が容易になります。中期的には、これはセキュリティ、コンプライアンス、および説明責任に関する深刻なリスクを生み出します。
企業はしばしば回答の正確性に焦点を当てますが、システムの動作を監視することを忘れます。つまり、ツール呼び出しが何回発生したか、エージェントがどこで失敗したか、エージェントがいつ頻繁にエスカレーションしすぎているか、エージェントのアクションが実際にビジネス成果を生み出しているか、といったことです。可観測性がなければ、組織はエージェントが何をしているのかを知ることができず、ましてやそれを改善することはできません。
すべてのプロセスにエージェントが必要なわけではありません。非常に決定論的なプロセスには、通常のワークフローや従来の自動化の方が、より安価で、より高速で、より予測可能な場合があります。エージェンティックパターンは、動的なコンテキスト、高い例外発生率、およびシステム間のオーケストレーションの必要性が組み合わさった場合に、より適切です。
企業全体をカバーする単一のエージェントを目指す野心は、通常、制御不能な複雑さに行き着きます。明確なドメインから始め、再利用可能なアーキテクチャパターンを構築し、段階的にスケールアップする方が良いでしょう。
CIO、COO、そして変革リーダーへの示唆
CIOにとって、このトピックは、エンタープライズアーキテクチャがもはやアプリケーション、データ、統合について語るだけでは不十分であることを意味します。今や、デジタルレイバー層、すなわちエージェントの種類、そのアイデンティティ、アクセス権、ライフサイクルについての明確な見解が必要です。
COOにとって、これは、プロセスの再設計がワークフローの単純化で終わってはならないことを意味します。問いは、「バリューストリームのどの部分を人間が実行し、どの部分をエージェントが実行し、どの制御ポイントを維持すべきか」に変わります。
CHROにとって、このアーキテクチャは労働力に影響を及ぼします。エージェントが実行者となるにつれて、人間の役割は監督、例外処理、ポリシー設計、継続的改善へと移行します。これは、ジョブデザイン、能力モデル、業績評価指標も変更されなければならないことを意味します。
変革リーダーにとって、メッセージはシンプルです。技術アーキテクチャとオペレーティングモデルを分離してはなりません。両者がバラバラに進めば、企業は導入のないテクノロジー、または制御のない導入を持つことになります。
持ち帰るべき問い
これを読んだ後、チームでの議論に持ち帰るべきいくつかの問いがあります。CIOへ： あなたのエンタープライズアーキテクチャは、エージェントを実際の運用上のアイデンティティとして組み込んでいますか、それともまだアプリケーションの機能として扱っていますか？ COOへ： どのプロセスが、人間とエージェントのチームによるオーケストレーションに真に備わっており、どのプロセスが自律性を与えるにはまだ脆弱すぎますか？ CHROへ： 実行の一部がデジタルレイバーに移行する場合、今、どのような人間の役割を強化すべきですか？ 変革リーダーへ： あなたは、スケーラブルな基盤を構築していますか、それとも、決してオペレーティングモデルにならないデモをただ集めているだけですか？
次の記事では、技術的な設計図から、同様に重要な問いへと進みます。アーキテクチャが理解できたとして、真に実行可能なエージェンティックエンタープライズのオペレーティングモデルとは、どのようなものでしょうか？