プロジェクト管理大手Asanaの新AI機能が、意図せずして企業の機密情報を他社に晒す事態を引き起こした。5月1日に鳴り物入りで登場した「Model Context Protocol（MCP）サーバー」の論理的欠陥が原因だ。1ヶ月以上にわたり続いたこのデータ漏洩リスクは、AI導入の光と影を浮き彫りにする。企業は今、この事件から何を学ぶべきだろうか。
発覚した「見えない壁」の欠落 – 何が起きたのか
事件の核心は、Asanaが2025年5月1日に提供を開始した「MCPサーバー」にある。このサーバーは、ChatGPTのような大規模言語モデル（LLM）とAsanaのデータを連携させ、自然言語での問い合わせやタスクの要約といった高度なAI機能を実現するものだった。
しかし、その導入から約1ヶ月後の6月4日、Asanaは自社でサーバーのコードに重大なロジック上の欠陥を発見。この欠陥により、本来厳格に分離されるべき企業ごとのデータ領域（テナント）の壁が崩れ、MCP機能を利用するあるユーザーが、別の組織のデータにアクセスできてしまう可能性が生まれた。
BleepingComputerの取材に対し、Asanaの広報担当者はこの問題がおよそ1,000社の顧客に影響を与えたと認めている。
漏洩した可能性のあるデータは、ユーザーが持つアクセス権限の範囲内に限定されるという。つまり、あるユーザーがアクセス権を持たないプロジェクトの情報までが丸ごと流出したわけではない。それでも、その範囲には以下のような機密性の高い情報が含まれうる。
- タスクレベルの情報: タスクの内容、担当者、期日など
- プロジェクトのメタデータ: プロジェクト名、進捗状況、関連チーム
- コメントやディスカッション: プロジェクトに関する内部のやり取り
- アップロードされたファイル: タスクに添付された各種資料
多くの企業がAsanaを業務の中枢として利用していることを考えれば、これらの情報が他社に漏れることのリスクは計り知れない。新製品の開発計画、マーケティング戦略、人事情報といった機密データが、意図せず競合他社や無関係の第三者の目に触れた可能性も否定できないのだ。
MCPとは何か？ 利便性の裏に潜む「実験的」リスク
今回の事件を理解する上で鍵となるのが「MCP（Model Context Protocol）」という技術だ。これは、AI開発の雄であるAnthropic社が2024年11月に提唱し、オープンソース化したプロトコルである。その目的は、LLMという強力な「脳」を、企業内に散在するデータベースや業務ツールといった「身体」に接続するための標準的な「神経網」を提供することにある。
開発者は、このMCPという共通言語を使うことで、個々のアプリケーションごとに連携方法を開発する手間を省き、迅速にAIを自社データに接続できる。Asanaもこの流れに乗り、ユーザーがClaudeのようなAIアシスタントから自社のAsanaデータを活用できるよう、MCPサーバーを立ち上げた。例えば、「マーケティングチームの今週締め切りの未完了タスクをすべてリストアップして」といった指示をAIに与えることが可能になるはずだった。
しかし、Asana自身もこの技術のリスクを認識していたようだ。同社の開発者向けドキュメントには「これは実験的なベータツールであり、『現状有姿』で提供されます。バグ、エラー、または予期しない結果に遭遇する可能性があります」と明記されていた。
この「予期しない結果」は、最悪の形で現実のものとなった。最先端技術の導入がもたらす利便性の裏で、データ分離というセキュリティの根幹が揺らいでいたのである。
Asanaの迅速な対応と残された課題
脆弱性の発見後、Asanaの対応は迅速だったと言える。UpGuardがまとめたタイムラインは以下の通りだ。
- 5月1日: MCPサーバーをリリース。
- 6月4日: 脆弱性を発見。直ちにMCPサーバーをオフラインにし、調査と修正に着手。
- 6月16日: 影響を受ける可能性のある顧客への通知を開始。
- 6月17日: 修正を完了し、サーバーを再稼働。
Asanaはサーバーを再稼働させたものの、接続は自動的には復旧させていない。「我々のチームが経験した問題を認識していただき、いつAsanaインスタンスをMCPサーバーに再接続するかを完全にお客様がコントロールできるようにしたい」として、ユーザー側に手動での再接続を求めている。これは、インシデントの透明性を確保し、ユーザーの意思を尊重する真摯な姿勢と評価できるだろう。
しかし、問題は残る。脆弱性が約1ヶ月もの間、誰にも気づかれずに存在し続けたという事実だ。この期間に実際にデータ漏洩が発生したかどうかの確証はない。Asanaは「悪意のある活動の結果ではない」と強調するが、偶発的に他社のデータを閲覧したユーザーがいた可能性は否定できない。同社は影響を受けた顧客に対し、関連するログやメタデータの提供を申し出ているが、すべての痕跡を追うのは困難を極めるだろう。
専門家が鳴らす警鐘 – AI統合の「落とし穴」
この一件は、Asana一社だけの問題ではない。急速に進むAIと既存システムとの連携がはらむ、構造的なリスクを露呈している。
カナダのコンサルタント会社DeepCove Cybersecurityのプリンシパルセキュリティアーキテクト、Kellman Meghu氏はCSO Onlineの取材に対し、「これはMCPサーバーに共通する問題だ」と手厳しい。彼は、MCPが採用する常時接続型の通信方式（long-lived TCP connections）の危うさを指摘し、リクエストごとに認証を行うAPIベースの接続方式、特に「RAG（Retrieval-Augmented Generation：検索拡張生成）」モデルの方が安全性が高いと主張する。
Meghu氏は、「なぜ我々はJSONやRestAPIのような既知のプロトコルで構築できなかったのか？ なぜこれが特別なサービスでなければならなかったのか？ 彼らはプロトコルの一部としてアクセス制御を考えていなかったのではないか？」と、MCPの設計思想そのものに疑問を投げかける。
また、セキュリティ企業UpGuardは、今回の事件から得られる教訓として、LLMを統合するすべての組織に対し、以下の4点を強く推奨している。
- スコープの徹底的な限定: AIがアクセスできるデータの範囲を、必要最小限の権限に厳しく制限する。
- すべてのロギング: AIによるクエリを含め、すべてのリクエストを詳細に記録し、事後調査に備える。
- インシデント発生時の手動監視: 問題発生時は、自動化された再接続や再学習の仕組みを即座に停止する。
- 内部バグの深刻な受け止め: 外部からの攻撃だけでなく、内部のソフトウェアの欠陥も重大な情報漏洩につながりうることを認識する。
利用者と企業が今すべきこと、そして未来への教訓
AsanaのMCP機能を利用していた、あるいは利用を検討していた企業は、今すぐ行動を起こすべきだ。Asanaからの通知を確認し、提供されるログを精査して、自社のデータが外部に漏れた形跡がないか、あるいは他社のデータを意図せず取得していないかを確認する必要がある。もし不審なデータを発見した場合は、Asanaの指示に従い、直ちに報告・削除することが求められる。
今回のAsanaのインシデントは、氷山の一角に過ぎないのかもしれない。AIによる生産性革命の熱狂の中で、我々はセキュリティの基本原則を見失ってはいないだろうか。最先端の「実験的」なツールを業務の根幹に関わるデータに接続することのリスクを、十分に評価できていただろうか。
利便性と安全性は、常にトレードオフの関係にある。しかし、企業の生命線であるデータを守るという点において、決して譲れない一線があるはずだ。今回の事件は、AI時代におけるデータガバナンスのあり方を、すべての企業と開発者に改めて問いかけている。技術の進化に目を奪われるだけでなく、その足元に潜むリスクを冷静に見つめ、堅牢なセキュリティ基盤を築くこと。それこそが、AIという強力なツールを真に使いこなすための第一歩となるだろう。
Sources
