2026/08/20各部門がAIを孤立して構築しないように
人工知能と機械学習｜Appar Technologies Co., Ltd.｜2026/08/20
企業がAIエージェントを導入する際に最も直面しやすい問題は、社員が使用を拒むことではなく、むしろ皆が急速に使い始めることです。カスタマーサポート、財務、エンジニアリング、営業、各地の支社がそれぞれ独自のエージェントを構築すると、企業はすぐに別の形の情報の孤島に直面します。各エージェントがそれぞれ証明書を保存し、システムを接続し、権限を設定し、同じ能力を重複して開発するのです。AGCO、Microsoft、Amazon Web Servicesの最新の実践は、エージェントを断片的な試験から本格的な運用能力に拡張するためには、共通のAIインフラストラクチャを構築する必要があることを示しています。
2026年、アメリカの農業機械メーカーAGCOは、企業の人工知能を推進する際に多くの企業が羨む問題に直面しました。それは、社員のAIエージェントへの関心が予想を超えて高かったことです。約2,200人が参加した管理職と社員の会議で、エージェントの構築を学びたい人を尋ねたところ、約900人が手を挙げました。その後、この内部の構築者コミュニティは約2,000人に拡大し、社員やチームによって数百のエージェントが次々と生み出されました。
AGCOはこの熱意を単なるツール購入計画とは見なしていませんでした。管理チームは早い段階で、各社員が独自にツールを探し、会社のデータに接続する場合、最終的には過去のシャドーITを新しいシャドーAIに置き換えるだけになる可能性があることを認識していました。AGCOは、社員が業務上の摩擦点を提案し、AIチームと専門家がそのニーズを適切なエージェント、プロセス、または自動化に変換するようにしました。会社は、複数のエージェントが継続的に参加できるフレームワークを意図的に構築し、無関係な小プロジェクトの連続ではないようにしました。
このアプローチはすでにAGCOの製造および品質管理プロセスに影響を与え始めています。過去には、品質や保証の案件が数週間から数か月かかることがあり、少数の専門家が複数のチーム間で情報を整理し、データを検証し、次のステップを調整していました。エージェントを導入した後、会社はAIが異なるシステムの情報を同じプロセスに取り込むことを期待しており、問題がより迅速に読み取られ、検証され、次の段階に進むことができるようにしています。真の価値は、特定のチャットボットがどれだけ速く回答するかではなく、組織全体が再利用可能なAI能力を構築し始めることにあります。
同様の問題が他の大企業でも発生しています。Microsoftは急増するエージェントを新しい企業のワークロードとして説明し、Amazon Web Servicesは、企業が数百から数千のエージェントを持ち始めると、3つの核心的な問題が発生すると指摘しています。それは、現在どのエージェントがあるのかが見えないこと、どの能力が外部に提供できるかを一貫して管理できないこと、異なるチームが既存の機能を繰り返し構築することです。AWSは2026年にエージェントレジストリを導入し、企業がエージェント、ツール、能力を集中して発見、共有、管理できるようにしようとしています。
これらのケースは重要な転換点を示しています。企業のAIの第一段階では、「誰がより早くエージェントを作成できるか」が競争の焦点でしたが、次の段階では「会社がどのようにして第100のエージェントを迅速かつ安全に構築できるか」が真の問題になります。エージェントの数が増え始めると、単一の製品の良し悪しが唯一の問題ではなくなり、アーキテクチャ自体が拡張速度を決定し始めます。
社員の自発的なイノベーションからエージェントの拡散へ
企業のAI採用は通常、最初から制御不能になることはありません。最初のカスタマーサポートエージェントは顧客関係管理システムに接続するだけで済むかもしれません。2番目の財務エージェントは企業資源計画システムに接続し、エンジニアリング部門は別途プログラム開発エージェントを構築し、マーケティング部門は独自にツールを購入します。各プロジェクトは個別に見れば合理的であり、短期間で価値を証明することができます。
問題は、これらのエージェントが徐々に増加した後、各チームが完全に同じことを繰り返し処理し始めることです。全員が会社のシステムへのログイン方法、証明書の保存方法、APIの記述方法、操作記録の残し方、権限の制御方法を研究しなければなりません。元々AIが重複作業を排除することを期待していた企業が、「AIを構築する」こと自体で大量の重複作業を生み出してしまいます。
Amazon Web Servicesはこの状況をエージェントの拡散と呼び、エージェントの数が急増する一方で、共通の棚卸し、ガバナンス、再利用のメカニズムが欠如しているとしています。AWSはエージェントレジストリを紹介する際、中央ディレクトリがないと、チームが他の部門が既に類似の能力を持っていることを知らずに別のエージェントやツールを再構築し、最終的に維持コストと技術的負債を増加させると指摘しています。
AGCOの経験は別の道を示しています。会社は社員がエージェントを構築することを阻止せず、個人の試験から企業の正式な環境に段階的に進むガバナンスの道を構築しました。社員は迅速に試すことができる一方で、企業のプロセスに影響を与えるより大規模なエージェントは、中央チームと専門家が共同で協力します。このモデルはイノベーションを分散させつつ、インフラストラクチャとガバナンスを徐々に集中させます。
企業AIインフラストラクチャの再定義
企業がエージェントの拡散を解決するには、すべてのエージェントを中央のAI部門が開発する必要はありません。このアプローチは、各部門が何らかのニーズを持つたびに情報部門を待つことになり、最終的に中央チームが常に手一杯になるという伝統的な情報プロジェクトのボトルネックに戻る可能性があります。真に集中管理が必要なのは、「誰がエージェントを作れるか」ではなく、皆が繰り返し必要とする基盤能力です。
例えば、認証、権限管理、証明書の保存、企業ツールのディレクトリ、接続方法、トラフィック制御、監査記録と監視は、各エージェントチームが再開発する必要はありません。これらの能力が標準化されるほど、事業単位は業務プロセス、プロンプト、データ品質、人間と機械の協力、ユーザー体験など、真に差別化されるべき部分に時間を費やすことができます。
Microsoftも自社のエージェント管理実務で同様の方向を取り始めています。Microsoft Digitalは中央制御層を使用して、異なるプラットフォームで構築されたエージェントを誰が構築し、誰が使用でき、どのデータにアクセスできるかを把握しています。管理者は複数のシステム間でエージェントの状況を逐一探す必要がありません。この中央で観測可能で分散したイノベーションのモデルは、企業のエージェントアーキテクチャの重要な特徴になる可能性があります。
この共通制御層の定義
現在の大企業やクラウドプラットフォームの構造を見ると、共有の人工知能インフラストラクチャは通常、単一の製品ではなく、エージェントと企業システムの間に位置する共通のサービス群です。異なる企業は既存の構造に応じてそれを異なる場所に配置できます。例えば：
- 企業の人工知能プラットフォーム、中央情報または人工知能チームによる運営
- APIゲートウェイまたはMCPゲートウェイタイプの共有接続層
- アイデンティティとアクセス管理プラットフォーム
- エージェントレジストリまたは企業ツールディレクトリ
- 部門横断の人工知能ガバナンスと可観測プラットフォーム
どの製品や組織方式を採用しても、その目的は似ています：各エージェントが再度解決する必要のある問題を抽出し、企業が再利用できる能力に変えることです。Amazon Bedrock AgentCore Gatewayはその具体例であり、エージェントが単一の安全なエントリーポイントを通じてツール、他のエージェント、モデルに接続し、インバウンドおよびアウトバウンドの認証、OAuth、証明書の保存、ツール統合、監査能力を集中処理します。
成熟した企業AI共有層は通常、以下の作業を担当します：
- 企業が利用可能なエージェント、MCPサーバー、ツールの共通ディレクトリを作成
- エージェントとユーザーのアイデンティティを統一的に処理
- 企業システムに必要なAPIキー、OAuthトークン、その他の証明書を管理
- どのエージェントがどのツールを呼び出せるかを制御
- 各ツールの使用とシステム操作の監査記録を残す
- トラフィック、コスト、エラー、パフォーマンス、異常行動の監視を提供
- 正式な稼働、バージョン更新、無効化、ライフサイクル管理メカニズムを確立
この層があることで、エージェントの開発方法は大きく変わります。開発者は「企業リソース計画システムを再度統合する方法」を問うのではなく、「会社が現在提供している利用可能な能力は何か」を問います。この違いは一見、統合プログラムを少し書かなくて済むだけのように見えますが、実際には企業が10のエージェントから100のエージェントに拡張できるかどうかを決定します。
良いAIインフラストラクチャの特質
現在のMicrosoft、Amazon Web Services、Google、MCPエコシステムの発展を観察すると、企業の共有インフラストラクチャが次第にいくつかの共通の特徴を形成していることがわかります。これらの能力は単一モデルの推論能力とは異なり、半年後に別の大規模言語モデルに切り替わっても価値を失うことはありません：
- モデル中立：企業の基盤能力は特定のモデルに縛られるべきではありません。今日OpenAIを使用し、明日Claude、Gemini、または自社モデルを追加でき、企業システムをすべて作り直す必要はありません。
- ツールの再利用可能性：同じ「顧客を照会」「作業指示を作成」「在庫を取得」する能力は、異なるエージェントによって使用できるべきであり、各エージェントが個別に再統合するべきではありません。
- アイデンティティの一貫性：エージェントはどのプラットフォームで作成されても、企業によって識別、認可、追跡されるべきです。Microsoft Entra Agent IDはこの方向に進んでおり、Microsoft以外のプラットフォームで作成されたエージェントもサポートしています。
- ガバナンスの集中、イノベーションの分散：事業部門は依然としてニーズに応じたエージェントを自ら作成できますが、安全、権限、データ、監査ポリシーは共通プラットフォームによって提供されるべきです。
- 完全な可観測性：企業はモデルがどれだけのトークンを使用したかを知るだけでなく、どのエージェントがどのツールを使用したか、成功率、どのようなエラーが発生したか、実際にどれだけのビジネス価値を生み出したかを知る必要があります。
- 交換可能性と拡張可能性：企業が新しいエージェントプラットフォーム、新しいシステム、または新しいツールを追加する際、全体の構造を再度書き直す必要はありません。
このような設計が特に重要なのは、人工知能モデルの変動速度が企業のコアシステムよりもはるかに速いからです。顧客関係管理システム、企業リソース計画システム、内部データベースは10年以上使用される可能性がありますが、企業が使用するモデルプロバイダーは1年以内に数回変更される可能性があります。企業がすべての企業統合を特定のモデルプロバイダーのエージェントに直接書き込んでしまうと、プラットフォーム戦略の変更ごとに再開発コストが発生します。
したがって、真に長期的に価値があるのは「会社が今日どのモデルを使用しているか」ではなく、企業が徐々に蓄積するツール、権限、データガバナンス、プロセス能力です。モデルは交換可能であり、エージェントも交換可能であり、さらにはエージェントプラットフォームも交換可能です。企業が本当に再度作り直したくないのは、後ろにある一連の企業独自の能力です。
企業共用のエージェントプラットフォームを構築する方法
企業がこの構造を構築する際、初日から大規模な「人工知能オペレーティングシステム」を作成する必要はありません。より合理的な方法は、現在最も頻繁に発生する統合問題から始めることです。例えば、3つの異なるチームが顧客データを照会する必要がある場合、「顧客を照会する」ことを共通の能力に変え、4番目のチームが再度顧客関係管理システムを統合することを避けるべきです。
第二のステップは、エージェントとツールのリストを作成することです。企業は現在どのエージェントが存在し、どのツールが使用可能で、責任者が誰で、どれが正式な環境で稼働しているかを知る必要があります。AWS Agent Registryはこの問題に対処するために開発された中央ディレクトリであり、ユーザーとエージェントは既存のエージェント、MCPサーバー、ツール、能力を検索し、不要な再開発を避けることができます。
第三のステップは、証明書と権限をエージェント自体から分離することです。各エージェントが独自の企業システムパスワード、APIキー、またはトークンを保持している場合、会社は取り消し、更新、監査を管理するのが難しくなります。ゲートウェイタイプの構造は、エージェントが「特定のツールを呼び出す必要がある」とだけ知り、実際にバックエンドシステムに接続するために必要な企業証明書は共通層によって安全に管理されます。AWS AgentCore Gatewayはこのようなセキュアな証明書交換とOAuth管理をコア能力として位置付けています。
第四のステップは、低リスクのエージェントのための迅速な導入経路を確立することです。企業が承認したツール、データ、身分確認メカニズムを使用し、高リスクの行動を伴わない場合、チームはエージェントを迅速に本番環境に導入できます。新しい機密データへのアクセス、支払い、削除、または不可逆的な操作が必要な場合は、より厳格な審査を受けることになります。このようなリスクの階層化は、「すべてのエージェントを情報部門で審査する」よりもスピードを重視することができます。
最後に、企業は共通の評価基準を確立する必要があります。あるエージェントが従業員の時間をどれだけ節約するかは一つの指標に過ぎません。より重要なのは、企業が重複した統合を減少させ始めているか、新しいエージェントの導入時間が短縮されているか、既存のツールの再利用率が向上しているか、事故を迅速に追跡できるかどうかです。プラットフォームが次のエージェントを前のものよりも簡単に構築できるようになったとき、企業は本当にAIの組織能力を蓄積したことになります。
AI基盤競争が急速に加熱中
この分野が企業にとって今注目すべき理由は、大手テクノロジー企業が「モデルの提供」から「エージェント基盤の提供」へと拡大し始めているからです。MicrosoftはAgent 365とEntra Agent IDを構築し、Amazon Web ServicesはAgentCore GatewayとAgent Registryを構築しています。Google Cloudは企業向けのMCP Serverと関連するガバナンス機能を提供し始めています。これにより、市場の焦点は単一のモデル競争から、多数のエージェント、ツール、企業システムを管理できるかどうかに移行しています。
企業にとって本当に投資すべきなのは、特定のエージェントプロジェクトそのものではなく、新しいモデル、新しいツール、新しいワークフローを継続的に吸収できるアーキテクチャです。今日構築したカスタマーサービスエージェントは、2年後には別の製品に置き換えられるかもしれませんが、その背後で使用される顧客データ、権限ルール、カスタマーサービスポリシー、企業ツールは、依然として会社の長期的な資産です。
企業のAI成熟度は、最終的には「どれだけのエージェントがあるか」ではなく、「新しいエージェントをどれだけ簡単に追加できるか」で決まるかもしれません。各部門がそれぞれAIを持つ場合、会社は多くのAIプロジェクトを得ることになりますが、データ、ツール、権限、ガバナンスが繰り返し再利用できる場合、会社は本当に自分自身のAI基盤を構築し始めたことになります。
