2026/08/20AIが企業ソフトウェアの新しいユーザーになるとき
人工知能と機械学習｜Appar Technologies Co., Ltd.｜2026/08/20
過去20年以上、企業ソフトウェアは主に2種類のユーザーにサービスを提供してきました：画面を通じてシステムを操作する人々と、APIを通じて機能を呼び出す他のプログラムです。AIエージェントは第3のユーザーをもたらしています。AIはタスクを理解し、利用可能なツールを探索し、データを読み取り、次のステップを自ら決定します。Model Context Protocol、つまりMCPが注目される理由は、単に別の統合技術を提供するだけでなく、企業が初めてシステム的に考えることを促しているからです：ソフトウェアが自分の能力をAIに「伝える」方法です。
2024年11月、AnthropicがModel Context Protocolを発表した際、提示されたのは一見単純なエンジニアリングの問題でした：大規模言語モデルの能力が急速に向上しているにもかかわらず、モデルはデータの孤島の外に取り残されています。データソースや企業ツールが増えるたびに、AIアプリケーションは専用の統合を再開発しなければならず、モデル、ツール、データソースが同時に増加すると、システムの維持がますます困難になります。Anthropicは、AIアプリケーションと外部データやツールが標準化された双方向接続を確立するための共通プロトコルを提案しました。
それから間もなく、このプロトコルは元々単一のAI企業によって提案されたものでしたが、既存のエコシステムを超えて広がり始めました。OpenAIはResponses APIとAgents SDKにリモートMCPサーバーのサポートを追加し、開発者がMCP規格に準拠したツールにモデルを直接接続できるようにしました。Google Cloudも続いて、Googleサービスが共通プロトコルを通じてAIアプリケーションで使用できるようにする公式MCPサーバーを提供すると発表しました。
2025年12月、AnthropicはMCPをLinux Foundationの新設のAgentic AI Foundationに寄付しました。Linux Foundationが発表した創設およびプラチナメンバーには、Anthropic、OpenAI、Amazon Web Services、Google、Microsoft、Cloudflareなどの企業が含まれています。2026年には、財団は金融、インフラ、政府、企業ソフトウェア分野の新しいメンバーを増やし続け、エージェントの相互運用性とオープンスタンダードが単一の製品機能から業界全体の基盤的な問題に変わり始めていることを示しています。
しかし、企業が本当に注意を払うべきなのは「みんながMCPをサポートしている」という事実そのものではありません。より根本的な変化は、AIがもはやシステムの外側に立って貼り付けられたテキストを読むだけではなく、企業ソフトウェアの正式なユーザーになり始めていることです。AIは、会社にどのようなツールがあるのか、各ツールが何をするのか、どのパラメーターが必要なのか、現在のユーザーに権限があるのか、実行後にどのような結果が得られるのかを知る必要があります。
この動きが続けば、企業ソフトウェアのインターフェースは過去20年で見られなかった大きな変化を遂げる可能性があります。ウェブインターフェースが人間にソフトウェアを使用させ、APIが他のプログラムにソフトウェアを統合させたように、MCPタイプのプロトコルはAIがソフトウェアを理解し操作できる第3のインターフェースを構築しようとしています。したがって、本当に議論すべきなのは新しい技術の略語ではなく、企業システムが「非人間ユーザー」のために能力を設計し始めなければならないということです。
APIインターフェースからAIツールインターフェースへ
仮に、顧客関係管理システムがREST API：POST /customers/{id}/tasksを提供しているとします。従来のアプリケーションにとって、エンジニアがAPIドキュメントを見れば、いつ呼び出すか、どのデータを渡すか、失敗した場合の処理方法を決定するプログラムを書くことができます。すべての「理解」はエンジニアが書いたコードの中に存在します。
AIエージェントの動作方法は異なります。ユーザーは単に「半年間連絡がなく、今年の消費が100万円を超える顧客を整理し、最近の取引記録を確認し、追跡が必要な人に業務タスクを作成する」と言うかもしれません。エージェントはまず目標を理解し、次に企業が現在利用できるツールを知り、順に顧客を照会し、取引データを取得し、履歴を読み取り、最終的にタスクを作成するかどうかを決定します。必要なのは単なるAPIアドレスではなく、モデルが「この能力が何をするか」を理解できるツールの説明です。
MCPはこのレベルで標準化されたインターフェースを追加しました。MCPサーバーはデータ、ツール、プロンプトなどの能力を固定された方法でMCPクライアントに提供し、エージェントがどのツールがあるかをリストアップし、ツールの名前、説明、パラメーターに基づいて呼び出すかどうかを決定できるようにします。Google CloudのMCPに関する説明も、MCPサーバーをAPI、データベース、またはサービス能力を標準インターフェースを通じてAIアプリケーションに提供するプログラムとして定義しています。
したがって、MCPはAPIを廃止するものではありません。多くのMCPサーバーのバックエンドは依然としてREST API、GraphQL、データベース、または既存の企業サービスを呼び出す可能性があります。真の変化は、APIの上にAIエージェントのために設計されたセマンティックおよびインタラクションインターフェースが追加されることです：APIはプログラムに「どのように呼び出すか」を伝え、MCPツールはさらにAIに「この能力が何であり、どのように使用するか」を伝えます。
企業システムのインターフェースを再定義する
このトレンドが続く場合、将来の企業ソフトウェアは3種類のインターフェースを同時に管理する必要があるかもしれません。第一はHuman Interface、つまりウェブ、モバイルアプリケーション、その他の人が操作する画面です。第二はApplication Programming Interface、つまり他のプログラムが使用するAPIです。第三はAI Tool Interfaceで、AIがシステムが提供する能力を理解できるようにします。
これら3種類のインターフェースは同じ企業能力をサービスしますが、ユーザーが異なります。例えば、購買注文を作成する場合、人間は画面を通じてフォームを記入するかもしれません。別のシステムはAPIを呼び出すことができます。AIエージェントはMCPツールを通じて「購買注文を作成する」目的、必要なフィールド、制限を理解し、ユーザーの要求に基づいて呼び出すかどうかを決定するかもしれません。企業は3つのコアビジネスロジックを再構築する必要はありませんが、3種類のユーザーが同じ能力に安全にアクセスする方法を考える必要があります。
この変化は、企業がソフトウェアを調達する方法にも再び影響を与えるでしょう。過去には情報担当者がサプライヤーに「APIはありますか？シングルサインオンをサポートしていますか？Webhookを統合できますか？」と尋ねていましたが、将来的には「エージェントはどの機能を使用できますか？標準のMCPサーバーはありますか？各ツールは独立してライセンスできますか？エージェントの操作は監査記録を残せますか？」といった質問が増えるかもしれません。APIがかつて追加機能から企業ソフトウェアの基本能力に変わったように、AIインターフェースも同様の道を歩む可能性があります。
企業アーキテクチャにおけるMCPの位置を定義する
MCP自体は通信プロトコルであり、完全な企業AIガバナンスプラットフォームではありません。したがって、企業がMCPを導入する際には、「MCPがある」ことと「本番環境に安全に移行できる」ことを同一視してはいけません。完全な企業アーキテクチャは、いくつかの異なるレベルを含む可能性があります：
- AIエージェントまたはMCPクライアント：ユーザーの目標を理解し、作業を計画し、ツールを選択する
- MCPゲートウェイまたは企業制御層：アイデンティティ、認証、トラフィック、証明書、記録、ポリシーを処理する
- MCPサーバー：企業データと機能をエージェントが使用できる標準能力として記述する
- エンタープライズシステム：データを実際に保存し、ビジネスルールを実行し、取引を完了する
この分層の目的は、「AIがどのように考えるか」と「企業がそれに何を許可するか」を分けることです。Microsoftは2026年に自社のMCPセキュリティガバナンス方法を公開した際、リモートMCPサーバーをAPIゲートウェイの背後に配置し、レビュー、アイデンティティ管理、隔離、適切なスロットルメカニズムを追加して、エージェントがMCP標準化接続を通じて無制限の企業能力を直接取得するのを防ぐと明確に述べました。
Amazon Web ServicesのAgentCoreゲートウェイも同様の方向を採用しています。MCPサーバーを単一のエントリーポイントに集約するだけでなく、インバウンドおよびアウトバウンドの検証、OAuth、証明書管理、ツール選択、監査、観測も担当しています。これにより、MCPが企業環境に本格的に導入された後、プロトコルは通常、基礎的な標準に過ぎず、その周囲には完全な企業制御メカニズムが必要であることが示されています。
企業レベルのMCPアーキテクチャは通常、次のことを処理する必要があります：
- MCPサーバーとツールの発見とバージョン管理
- ユーザーとエージェントのアイデンティティ識別
- ツールレベルのアクセス制御
- APIキー、OAuthトークンなどのバックエンド証明書管理
- 使用記録、エラー、パフォーマンス、監査
- 機密操作の手動承認
- 異なるMCPバージョンとエージェントプラットフォームの互換性
これらの能力が共通プラットフォームに抽出されると、企業は各エージェントに安全とガバナンスロジックを再度書き込む必要がなくなります。これがゲートウェイアーキテクチャが注目され始めた理由です。それは技術を追加するためではなく、エージェントが大量の企業システムと直接接続することを避けるためです。
成熟したMCPアーキテクチャの特性
MCPは依然として急速に進化しているプロトコルであるため、企業はアーキテクチャを「今日のMCP仕様に準拠しているだけで完了」と設計すべきではありません。2026年7月28日に発表された新バージョンはその良い例です。この更新では、コア伝送方法が大幅に調整され、ステートレスコア、正式な拡張メカニズム、認証強化、新しいライフサイクルルールが導入されました。AWSも特に、これはMCPが導入されて以来最大のバージョン変更の一つであると指摘しています。
したがって、成熟した企業MCPアーキテクチャは次の6つの特性を備えているべきです：
- プロトコルとビジネスロジックの分離：企業のコアAPIとビジネスルールは完全にMCPに依存すべきではなく、MCPサーバーは企業能力の一つのインターフェースであるべきです。
- バージョン管理可能：MCP仕様は進化し続けるため、企業は異なるバージョンを同時に管理し、段階的にアップグレードできる必要があります。プロトコルの変化があるたびにすべてのエージェントを同時に変更することを強制されるべきではありません。
- アイデンティティと権限の外部化：ツールが使用できるかどうかは、企業のアイデンティティと認証メカニズムによって決定されるべきであり、ツールのテキスト記述にのみ書かれるべきではありません。
- モデルとプラットフォームの中立性：同じ企業ツールは、異なるエージェントクライアントによって使用できるべきです。OpenAI、Google、Amazon Web Services、その他のプラットフォームがMCPエコシステムに参加することで、このような互換性が徐々に実際の基盤を持ち始めています。
- 完全な可観測性：企業はどのユーザーがどのエージェントを通じてどのツールを呼び出したかを知ることができるべきであり、単にあるAPIがリクエストを受け取ったことを知るだけではありません。
- ゲートウェイ化ガバナンス：MCPサーバーが増加するにつれて、企業はセキュリティ、トラフィック、バージョン、ポリシーの制御を集中管理する必要があります。MCPが再び管理しにくい点対点統合に発展するのを避けるためです。
これらの条件は、企業が投資する価値があるのは「AIが操作可能な企業能力」であり、MCPという3文字そのものではないことを示しています。たとえ5年後に新しいエージェントプロトコルが市場に登場しても、企業がツールの境界、アイデンティティ、権限、ビジネス能力を整理していれば、新しいプロトコルは単にインターフェースを変更するだけであり、企業のシステムを再整理する必要はありません。
逆に、企業が単に各APIをMCPサーバーとしてパッケージ化し、ツールの境界、権限、ガバナンスを考慮しない場合、元のAPI時代の統合の混乱をそのままエージェント時代に持ち込むことは容易です。標準化は接続コストを下げることができますが、企業のアーキテクチャの問題を自動的に解決することはできません。
MCPを導入する方法、MCPを追いかけるのではなく
企業が現在MCPの研究を開始する際に最も避けるべきことは、「MCPをサポートするため」にすべての企業システムを一から書き直すことです。最初の合理的なステップは、どの企業能力が複数のエージェントによって繰り返し使用される可能性が高いかを評価することです。例えば、顧客の照会、工単の作成、在庫の取得、文書の検索、購買草稿の作成などは、特定のプロジェクト専用の機能よりも優先して標準化する価値があります。
次のステップは、低リスクの読み取り型ツールから始めることです。エージェントが会社の知識を照会し、注文情報を取得することと、エージェントが正式に返金、支払い、またはデータ削除を行うことでは、リスクが全く異なります。企業はまず、エージェントがどのように識別されるか、ツールがどのように認可されるか、操作がどのように記録されるかを確立し、徐々に書き込み能力を持つツールを増やしていくことができます。
第三のステップは、各部門が互換性のないMCPサーバーを個別に構築することを避けることです。MCPの価値は、重複した統合を減らすことにあります。同じ顧客関係管理システムが異なるチームによって4つのMCPサーバーにパッケージ化されている場合、最終的には過去の問題に戻ってしまいます。MCPサーバー自体も企業が再利用可能な製品として見なされるべきであり、責任者、バージョン、文書、ライフサイクルが必要です。
第四のステップは、ゲートウェイまたは共通制御層を早期に構築することです。MCPサーバーが少ない場合、エージェントが直接接続するのが最も簡単に見えますが、数が増えると、アイデンティティ、OAuth、ツールリスト、トラフィック制限、監査がすぐに分散します。AWSの最新のゲートウェイアーキテクチャや、MicrosoftがリモートMCPサーバーをゲートウェイの背後に配置する実践は、大規模な展開が集中制御に向かっていることを示しています。
最後に、企業はMCPを長期的なインターフェース戦略として捉えるべきであり、一度限りのAIプロジェクトとして捉えるべきではありません。新しいエージェントプラットフォームが登場したときに、「企業資源計画システムを再統合する必要があるか」を問うのではなく、「このエージェントが企業がすでに提供している標準能力を安全に使用できるか」を問うべきです。この質問に安定して答えられるようになったとき、企業はオープンプロトコルの価値を真に享受できるようになります。
第三の企業インターフェースが急速に形成されつつある
MCPが10年後に唯一のエージェントツール標準になるかどうかは、現時点では誰にも確定できません。プロトコルは依然として急速に調整されており、エージェント間の他の標準も発展しています。しかし、MCPはAnthropicの単一プロジェクトからLinux Foundationの中立的なガバナンスに移行し、主要なAIおよびクラウドプロバイダーの支援を受けています。2026年の新しい仕様では、企業規模の展開に必要なステートレスアーキテクチャ、認可、拡張メカニズムに関する調整がすでに始まっています。
企業にとって、これは「MCPが必ず勝つ」と賭ける必要はないが、より大きなトレンドを受け入れ始めるべきことを意味します。AIエージェントは徐々に企業システムの正式なユーザーになりつつあります。将来の優れた企業ソフトウェアは、人が操作しやすく、プログラムが統合しやすいだけでなく、AIがその能力を理解し、明確な権限の下で安全に実行できる必要があります。
過去には人のために画面を設計し、プログラムのためにAPIを設計しました。これからは、企業はAIのためにツールインターフェースを設計し始める必要があります。MCPの本当の重要性は、単に新しい接続方法が増えたことではなく、AIが企業システムに本格的に参入し始めたときに、ソフトウェア自体がAIとどのように協力するかを学び始める必要があることを企業に初めて明確に示したことです。
