MCPやA2Aの導入によるリスクとは?

mcpa2a_main.png

生成AIはチャットのように対話するような使い方だけでなく、外部のデータやプログラムをAIと接続するときに使われる「MCP」や、人ではなくAIが操作する「A2A」という考え方が広がっています。

複数のシステム間での連携が可能になり、作業担当者の負担を軽減できる一方で、情報システム担当者としては管理コストとリスクが大幅に増える可能性があります。

導入から運用、更新まで含めて、どのようなリスクがあり、具体的にどのような対策が考えられるのかを紹介します。

MCP(Model Context Protocol)とは

私たちはパソコンの中でも複数のプログラムを実行しますし、インターネット上には便利なサービスがたくさんあります。

これらのプログラムやサービスの開発者が、自分たちのソフトウェアを生成AIに対応させることを検討しています。そんな中、世の中にはChatGPTやGemini、Perplexityなどさまざまな生成AIがあります。

従来はそれぞれの生成AIが提供するインターフェイス(API)に合わせて、プログラムを開発する必要がありました。さらに、新たな生成AIが次から次へと登場するため、プログラム同士を連携させようとすると組み合わせが膨大になります。

そこで、AIモデルに送る「文脈(コンテキスト)」の標準化を目指して開発されたプロトコルが「MCP(Model Context Protocol)」です。利用者からの指示、会話の履歴、ドメイン知識などを共通のフォーマットでやり取りできるようにすることで、開発者の負担を軽減できます。

2025年に入って多くの生成AIがMCPに対応したことで、サービス側の対応が進んでいます。今後は利用者が自然言語でさまざまなサービスを使えるため、利便性が向上すると考えられます。

A2A(Agent to Agent)とは

MCPによって生成AIとプログラムを連携できますが、人間が指示を出すことが前提でした。しかし、プログラムと生成AIを連携できる仕組みが整えば、プログラム同士が直接やり取りすることによって人間の手間を省けます。

このとき、「エージェント」と呼ばれるソフトウェア同士が直接コミュニケーションし、協調してタスクを遂行する方式をA2A(Agent to Agent)といいます。人が指示したタスクを自動的に小さく分割し、それぞれのエージェントが持つ機能に応じて役割を分担し、並行して処理することで効率が向上します。

つまり、MCPが通信で用いる「文脈」の標準フォーマットを定める役割を果たす一方、A2Aは異なるエージェントが意味の取り違えなく協調できるようにする仕組みだと言えます。MCPで文脈を正しく設計しておけば、A2Aでのタスク分割や結果の統合もスムーズになります。

すでにプログラミング(コーディング)の工程では、エージェントを用いてシステム開発を進めることが一般的になりつつあり、開発効率の向上が期待されています。

このように、MCPで定めた文脈に沿ってA2Aで処理できるのであれば便利だと感じるかもしれません。しかし、そこにはさまざまなリスクがあります。

リスク1)情報の漏洩

MCPやA2Aが社内だけで完結していれば問題は小さいかもしれませんが、実際には外部サービスや外部のMCPサーバーと接続するケースが少なくありません。
複数のエージェント間でやり取りされる文脈に、本来含まれるべきでない顧客の個人情報や組織の機密情報が含まれると情報漏洩に該当します。

MCPサーバーは社内外を問わず同じインターフェイスで接続できるため、意図せず外部にデータを送信してしまう可能性があります。A2Aによってエージェント間で全文をやり取りした結果、不要な顧客データが外部モデルへ送信された、という状況が発生しても、利用者はそれに気づかないことも考えられます。

対策としては、やり取りする項目を明確に絞り込むなどアクセスする範囲を最小化すること、外部サーバーと接続する際のデータフローを可視化すること、DLP(Data Loss Prevention)や送信先制限などの対策を併用することが重要です。

リスク2)認証や認可の欠如

従業員が社内のサーバーに接続するときには、認証や認可の設定が不可欠です。外部サーバーに対してプログラムからAPI経由でアクセスする場合は、APIキーなどの管理も必要です。

これらの設定に誤りがあると、権限のない範囲にアクセスされる可能性があります。悪意あるエージェントが社内のワークフローに参加して、不正な命令を実行したり、機密データにアクセスしたりするリスクもあります。

たとえば、テスト環境用に使用したAPIキーがそのまま本番環境で使われ、権限を越えて操作されると、想定外のやり取りが発生する可能性があります。また、あるエージェントが他のエージェントだと偽装して機密情報にアクセスするような使い方がされる可能性もあります。

これらを防ぐためには、エージェントに対する認証を強化するとともに、定期的にAPIキーなどの更新を求めたり、インシデントが発生したときには即時無効化したりして被害を最小限に抑えることも考えられます。

また、生成AIに限らず、データにアクセスする人の権限は最小にするとともに、単にIDとパスワードなどで認証するのではなく、リスクベース認証や属性ベース認証の導入などが考えられます。

リスク3)再現性の欠如

生成AIの応答は確率的に生成されるため、MCPやA2Aの出力が常に同じものになるとは限りません。日常的な会話であれば問題にならなくても、システム間の連携において同じ結果が再現できないと業務に支障をきたすことがあります。

さらに、生成AIのモデルのバージョンアップや学習データの追加などによって結果が変わると、以前の挙動に戻すことすらできません。トラブルが発生したときの原因究明が難しくなることも問題です。

社内で使うだけであれば問題なくても、顧客に提供するようなサービスで、結果が不安定なものでは説明できないこともあるでしょう。

対策としては、バージョン管理の徹底、出力ログの記録、重要な処理には確定的なルールを定めること、必要に応じてモデルのバージョン固定やシミュレーション環境での検証をおこなうことなどが挙げられます。

リスク4)運用費用の不足

生成AIはサブスクリプション契約が基本ですが、利用料に応じて追加課金される場合もあります。人間が操作する場合は使用量が比較的安定することが多いですが、エージェントが自動で大量に動作すると、通信量やAPI呼び出しが急増し、コストが膨らむ可能性があります。

特に、エージェント間で冗長なリクエストが発生すると、短期間でコストが急増することもあります。大量のエージェントが動作していると、問題の原因となるエージェントを特定できず、動作を止めることが難しい状況も考えられます。

このため、レートリミットの設定や、課金アカウントの分離と管理は必須です。それに加えて、運用状況の監視やアラート、異常検知時の自動遮断についても事前に検討しておきましょう。

まとめ

MCPとA2Aは生成AIとプログラムの連携を容易にし、生産性を大きく向上させる可能性があります。しかし一方で、情報の漏洩、認証・認可の不備、再現性の欠如、運用コストの増大といったリスクが顕在化します。

これらを軽減するため、導入前にリスク分析を行い、運用ルールを整備して、安全かつ効率よく活用するようにしましょう。

著者プロフィール
増井 敏克氏(ますい としかつ)
増井技術士事務所代表。技術士(情報工学部門)、情報処理技術者試験にも多数合格。
ビジネス数学検定1級。

「ビジネス」×「数学」×「IT」を組み合わせ、コンピューターを「正しく」「効率よく」使うためのスキルアップ支援や各種ソフトウェア開発、データ分析などをおこなっている。

著書に『図解まるわかり セキュリティのしくみ』『図解まるわかり プログラミングのしくみ』『図解まるわかり アルゴリズムのしくみ』『IT用語図鑑』『IT用語図鑑[エンジニア編]』『Pythonではじめるアルゴリズム入門』『プログラマ脳を鍛える数学パズル』『プログラマを育てる脳トレパズル』(以上、翔泳社)、『プログラマのためのディープラーニングのしくみがわかる数学入門』『プログラミング言語図鑑』(以上、ソシム)、『基礎からのプログラミングリテラシー』(技術評論社)、『RとPythonで学ぶ統計学入門』(オーム社)などがある。