結論: マッキンゼーの社内AI「Lilli」は、AIエージェントによるSQLインジェクションでわずか2時間でハックされ、4,650万件のチャット・72.8万ファイル・5.7万アカウントが露出した。しかも攻撃者はLilliの「システムプロンプト」を書き換えられる状態にあった。これは単なる大企業のセキュリティ事故ではなく、「社内AIに機密情報を入れていいのか」という問いに対するリアルな答えだ。
この記事の要点:
- マッキンゼーの社内AI「Lilli」がAIエージェントによるSQLインジェクションで2時間で突破された（2026年3月9日報道）
- 4,650万件のチャット・72.8万ファイル・5.7万アカウントが読み書きアクセス可能な状態に
- 最大の問題はLilliを動かす「システムプロンプト95本」が書き換え可能だったこと——これは「4万人のコンサルタントへのアドバイスを静かに改ざんできる」状態だった
対象読者: 社内AIツールの導入を検討中・運用中の経営者・DX推進担当者
読了後にできること: 自社の社内AI/チャットツールに対するセキュリティチェック項目を3つ確認する
2026年3月9日、The Registerが報じた一本の記事が、AI業界に衝撃を与えました。
英サイバーセキュリティ企業CodeWallの自律型AIエージェントが、マッキンゼー・アンド・カンパニーの社内AI基盤「Lilli」に侵入し、2時間で本番データベースへの完全な読み書きアクセスを取得したというのです。
アクセスできた情報は、4,650万件のチャット履歴（M&A戦略や顧客情報が含まれる）、72.8万件のファイル、5.7万件のユーザーアカウント、そしてLilliを動かす95本のシステムプロンプト——すべてが読み書き可能な状態でした。
この記事では、事件の全貌・技術的な詳細・マッキンゼーの対応、そして「では日本企業はどうすればいいのか」を、100社以上のAI研修・導入支援の現場から見た実務視点で徹底解説します。
何が起きたのか——事件のタイムラインと全体像
まず、確認済みのファクトを時系列で整理します。
| 日時 | 出来事 |
|---|---|
| 2026年2月下旬 | CodeWallのAIエージェントがLilliの脆弱性を発見・侵入開始 |
| 2026年2月28日頃 | AIエージェントが本番DBへの完全アクセスを取得（所要時間: 約2時間） |
| 2026年3月1日 | CodeWallがマッキンゼーに完全な攻撃チェーンを開示（責任ある開示） |
| 2026年3月2日 | マッキンゼーが全脆弱エンドポイントにパッチ適用、開発環境をオフライン化 |
| 2026年3月9日 | The Register・The Decoder・Inc.等が一斉報道 |
| 2026年3月9日以降 | X（旧Twitter）で日本語ツイートが2,767いいね、HackerNewsで508点を獲得 |
重要な前提として、CodeWallは「レッドチーム（ペネトレーションテスト）」として自らAIエージェントを動かし、その結果をマッキンゼーに責任を持って開示しています。つまりこれは「悪意ある外部攻撃者がデータを盗んだ」事件ではなく、「プロのセキュリティ研究者が脆弱性を証明してみせた」事件です。
ただし、その「証明」があまりにも衝撃的でした。
Lilliは、マッキンゼーの全世界4万人以上のコンサルタントが日常的に使う社内AI基盤です。月間プロンプト処理数は50万件——M&A戦略、リストラ計画、クライアントの機密データが日々流れ込んでいる。そのデータベースが、外部のAIエージェントに認証なしで読み書きアクセスされたのです。
技術的な詳細——「古典的な手法」が最先端AIを突破した
CodeWallのAIエージェントが用いた攻撃手法は、SQLインジェクション。Web開発の教科書に必ず載っている、20年以上前から知られる「古典的な脆弱性」です。
なぜこれが2026年のマッキンゼーで通用したのか？技術的な詳細を整理します。
ステップ1：公開APIドキュメントから入口を発見
CodeWallのAIエージェントはまず、Lilliのインフラを自律的に偵察しました。その結果、認証不要の22のAPIエンドポイントが公開状態にあることを発見します。
マッキンゼーほどの大企業でも、開発環境のAPIドキュメントが誤って外部から参照できる状態になっていたのです。
ステップ2：JSONキーのSQLインジェクション
通常のSQLインジェクション対策は「入力値をエスケープする」というものです。ところがLilliの脆弱なエンドポイントでは、JSONの「キー名」（フィールド名）そのものがSQLクエリに結合されていました。
入力値のバリデーションをしていても、キー名までは疑わない実装が多い——これが盲点でした。AIエージェントはエラーメッセージを見ながら15回のブラインドイテレーションを繰り返し、データベース構造を解明。最終的に本番DBへの完全アクセスを手に入れました。
ステップ3：システムプロンプトが書き換え可能だった
そして最も深刻な問題がここです。
Lilliを動かす95本のシステムプロンプト——「どんな質問に答えるか」「どんなトーンで回答するか」「どの情報を優先するか」を定義する、AIの「行動指針」——が、同じデータベースに平文で保存されていました。
そして、それが書き換え可能だった。
「システムプロンプトを書き換えるには、たった1回のHTTPリクエストでUPDATE文を発行するだけでよかった。コードのデプロイも、システム変更も不要。変更ログも残らない。4万人のコンサルタントへのアドバイスを、誰にも気づかれずに改ざんできる状態だった。」
— CodeWall社のレポートより（参照日: 2026-03-09）
つまり攻撃者は、Lilliが提供する財務モデル、戦略提言、リスク評価——これらを静かに、誰にも気づかれずに書き換えられたのです。
AI導入を進める企業にとって、この問題は「データが漏れる」よりも深刻です。AIが出力する「答え」そのものが汚染されるリスクがあるからです。
AIガバナンスの全体像については、AI導入戦略完全ガイドでも詳しく解説しています。
マッキンゼーは何と言ったのか——声明と論点
マッキンゼーは事件開示後、以下の公式コメントを発表しました。
「第三者フォレンジック企業による調査の結果、この研究者またはその他の不正な第三者によって顧客データや顧客機密情報にアクセスされた証拠は見つかりませんでした。脆弱性の報告から数時間以内に、全エンドポイントにパッチを適用しました。」
— マッキンゼー・アンド・カンパニー広報（参照日: 2026-03-09）
この声明に対して、セキュリティ研究者からはいくつかの疑問が上がっています。
まず、CodeWallが「開発環境」を侵害したのか、本番環境にアクセスできたのかについて、両社の主張に差異があります。CodeWallは「本番DBへのフルアクセスを取得した」と主張していますが、マッキンゼーは「証拠なし」の立場。この点は独立した第三者による検証が難しく、完全には決着がついていません。
ただし、以下の事実については両社ともに認めています：
- 認証不要のAPIエンドポイントが存在していた
- SQLインジェクションの脆弱性があった
- 報告から1日以内にパッチが適用された
セキュリティ専門家のEdward Kiledjian氏は「CodeWallの主張の一部は誇張されている可能性があるが、脆弱性自体は実在したことは明らか」と分析しています（参照日: 2026-03-10）。
なぜこれが「日本企業の問題」なのか
「でもうちは中小企業だし、マッキンゼーほどの規模じゃない。関係ないのでは？」
100社以上の企業向けAI研修・コンサルの経験から言わせていただくと、むしろ中小企業の方が危険だと思っています。理由は3つです。
理由1：社内AIに「入れてはいけない情報」のルールが曖昧
大企業はAI利用ガイドラインを整備していることが多いですが、中小企業では「とりあえずChatGPTで便利になった」という段階で終わっているケースが多い。
研修の場で「ChatGPTに何を入力していますか？」と聞くと、驚くような回答が返ってくることがあります。顧客名と金額が入った見積書、採用候補者の個人情報、未公開のM&A情報——これらが「プロンプト」として入力されていたのです。
今回のLilli事件は、「しっかり管理されているはずの社内専用AI基盤でさえ、この状態だった」という事実を示しています。社内AIを「完全に安全」と思い込むのは危険です。
理由2：AIエージェントが攻撃ツールになっている現実
CodeWallのAIエージェントは、人間のハッカーよりも速く、疲れることなく、22のエンドポイントを自律的に偵察し、15回のブラインドイテレーションを繰り返しました。
これが意味するのは、「標的になる企業の規模に関係なく、AIが攻撃ツールとして普及しつつある」ということです。かつて高度なペネトレーションテストは専門家が数日かけて行うものでした。今はAIエージェントが2時間でやってしまう。
理由3：「システムプロンプト汚染」は発見しにくい
従来のサイバー攻撃は、ファイルが盗まれた・サービスが止まった、といった「目に見える被害」が出ることが多かった。しかしシステムプロンプトの汚染は違います。AIの回答が微妙に変わる——財務モデルが少しだけ楽観的になる、リスク評価が少しだけ甘くなる——これを発見するのは非常に困難です。
AI活用の全体像と日本企業のリスク対応については、AI導入戦略ガイドでも詳しく取り上げています。
専門家の見解——楽観論と慎重論
この事件に対しては、異なる評価が出ています。
楽観的な見方：「適切な開示と迅速なパッチ適用がうまく機能した」
CodeWallは悪意ある攻撃者ではなく、責任ある開示（Responsible Disclosure）を行いました。マッキンゼーも報告から1日以内にパッチを適用。「このプロセス自体は、セキュリティエコシステムが正しく機能した例」とも言えます。
また、マッキンゼーが「顧客データへのアクセス証拠なし」と主張しており、第三者フォレンジック調査も実施しています。CodeWallの主張の一部（「本番環境への完全アクセス」）については独立検証が困難な部分もあり、誇張の可能性も指摘されています。
慎重な見方：「これは氷山の一角に過ぎない」
一方で、セキュリティ研究者の多くは「これが初めて発覚した事例というだけで、同様の脆弱性は他の企業のAIシステムにも潜んでいる」と警告しています。
特に問題視されているのが、「システムプロンプトの完全性を保護する概念がほとんどの企業にない」という点です。ファイルシステムのパーミッション、データベースのアクセス制御、コードのバージョン管理——これらは整備されていても、「AIのシステムプロンプトを誰が変更したか」を追跡する仕組みがある企業はほぼ皆無です。
AIが業務の中核を担うようになった今、システムプロンプトは「ガバナンス文書」と同等の重要性を持っています。それが無防備な状態に置かれているというのが、この事件が示した最大の教訓です。
日本企業がとるべきアクション——5つの具体的な対策
では、実際に何をすればいいのか。AI研修・導入支援の現場から見た、実務的なアクションを5つ紹介します。
対策1：社内AIツールの「入力禁止情報」を明文化する
「機密情報は入れないで」では不十分です。具体的に何がNGかを明文化する必要があります。
例として：
- 顧客の実名・会社名・金額が含まれる文書 → NG（匿名化してから入力）
- 採用候補者の個人情報 → NG（個人を特定できない形式のみ可）
- 未公表のM&A・新製品情報 → NG
- 社員の人事評価情報 → NG
これをチームに周知・定期確認するだけで、リスクは大幅に下がります。
対策2：社内AIのシステムプロンプトを「変更管理」の対象にする
今回の事件で最も深刻だったのが、システムプロンプトの書き換えが「誰にも気づかれない」状態だったことです。
自社でChatGPT API・Claude API・Gemini APIを使ったカスタムAIを運用している場合、システムプロンプトをGitで管理し、変更時はレビューを義務づける、という運用を徹底してください。SaaSのAIツールを使っている場合も、管理者アカウントの変更ログを定期的に確認する習慣を持つべきです。
対策3：APIエンドポイントの認証状態を定期チェックする
今回の侵入口は「認証不要のAPIエンドポイント」でした。自社でAPIを運用している場合、「本当に全てのエンドポイントに認証がかかっているか」を半年に一度はレビューしてください。特にクラウドサービスをβ版で試したあとに正式運用に移行した場合、テスト用の無認証エンドポイントが残存するケースが多いです。
対策4：外部向けAPIドキュメントを必要最小限に絞る
CodeWallのAIエージェントは、公開されたAPIドキュメントから侵入口を発見しました。開発者の利便性のために公開したドキュメントが、攻撃者にも読まれているということです。内部向けのAPIエンドポイント情報は、認証済みの開発者のみにアクセスを限定する設計を検討してください。
対策5：「SQLインジェクション対策」は「入力値」だけでなく「キー名・カラム名」も
今回の脆弱性はJSONのキー名（フィールド名）がSQLに結合されていたというものでした。通常のSQLインジェクション対策は「入力値のエスケープ」を中心に教えられますが、動的に生成されるSQL文のあらゆる部分を対象とする必要があります。
自社でシステム開発を行っている場合は、セキュリティレビューの範囲をJSON/APIのパラメータ全体に広げることを開発チームに伝えてください。
この事件が示す「AI時代のセキュリティの本質」
Lilli事件を振り返って、最も重要なメッセージは何か。
それは、「AIを業務に組み込めば組み込むほど、AIシステム自体がクリティカルな攻撃対象になる」という事実です。
従来のサイバーセキュリティは「データを守る」という発想が中心でした。しかし今回の事件で明らかになったのは、「AIの判断・行動そのものを書き換えることができる」という新しい攻撃ベクターです。
システムプロンプトを書き換えられれば、AIが出力する財務分析、戦略提言、法律解釈、採用基準——これら全てが静かに汚染される可能性があります。しかも、通常のセキュリティログにはその痕跡が残りにくい。
CodeWallのレポートは、システムプロンプトを「現代のAI時代における王冠の宝石（Crown Jewel Asset）」と表現しています。金庫に価値ある文書を保管するように、システムプロンプトも保護・管理・バージョン管理する時代が来ているということです。
「古典的な脆弱性」がなぜ見過ごされたのか
SQLインジェクションは2000年代初頭から知られる脆弱性です。なぜ世界有数のコンサルティングファームの内部システムに、この脆弱性が存在したのでしょうか。
セキュリティ専門家の間では、以下の背景が指摘されています。
第一に、AIシステムの開発スピードと安全性設計のギャップ。Lilliは2023年に急速に展開されたシステムです。「まず展開して後でセキュリティを強化する」という開発手法が、この種のリスクを生みやすい構造的な問題があります。
第二に、「社内専用だから大丈夫」という思い込み。Lilliはマッキンゼーの社内専用ツールです。外部公開しているサービスほど厳格なセキュリティレビューが行われない傾向があります。しかし現代のクラウド環境では、「社内専用」でも何らかの形で外部からアクセス可能なエンドポイントが生まれやすい構造になっています。
第三に、AI特有のセキュリティ盲点。従来のWebアプリケーションのセキュリティレビューは入力値の検証が中心です。AIシステムでは、自然言語のプロンプト、APIパラメータ、JSONの構造、ベクターDBのアクセス制御など、検証すべき範囲が大幅に広がっています。多くの組織が、この「新しい攻撃面」に対応できていないのが現状です。
日本企業のAI利用ガイドラインの現状
経済産業省が2024年に公開した「AI事業者ガイドライン」では、AIシステムの安全性・セキュリティへの配慮が明記されています。しかし同省の調査では、中小企業の多くがこのガイドラインを認知していないか、具体的な実践につなげられていない状況が続いています。
企業向けAI研修の現場では、「ChatGPTの使い方」は教えても、「何を入れてはいけないか」「どうセキュリティを考えるか」を体系的に教えている企業はまだ少数です。今回のLilli事件は、この教育ギャップを埋める必要性を改めて示しています。
AIエージェントの安全な導入方法については、AIエージェント導入完全ガイドもあわせてご覧ください。
まとめ：今日から始める3つのアクション
Lilli事件の教訓を、今日から実際に活かすための3ステップです。
- 今日やること: チームに「社内AIツールへの入力禁止情報リスト」を展開する（顧客実名・金額・未公表情報などを明文化）
- 今週中: 自社で運用しているAIシステム・API・カスタムツールのアクセス制御状態を棚卸しし、「認証不要のエンドポイントがないか」を確認する
- 今月中: システムプロンプトを使っているAIシステムがある場合、プロンプトをGit等でバージョン管理し、変更時の承認フローを設計する
「うちはChatGPTをそのまま使っているだけだから関係ない」と思う方もいるかもしれません。しかし、SaaSのAIツールを使っている場合も、自社のアカウントが乗っ取られた際のリスク、入力した情報の扱われ方、ツールのアクセス権限設定——これらは自社で確認・管理するべき事項です。
AI活用は生産性向上に直結する一方で、「何をAIに渡すか」の判断は人間がしなければなりません。Lilli事件はその判断の重要性を、あらためて私たちに教えてくれています。
また、自社のAI導入状況を第三者の目でチェックしたいという場合は、弊社のAIセキュリティ診断・AI利用ガイドライン策定支援をご活用ください。研修を通じてチーム全体のリテラシーを底上げするアプローチも含め、貴社の状況に合った方法をご提案します。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
次回予告: 次の記事では「AIエージェントの社内導入でつまずく5つのポイントと解決策」を、実際の支援事例をもとに解説します。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
参考・出典
- AI agent hacked McKinsey chatbot for read-write access — The Register（参照日: 2026-03-09）
- An AI agent hacked McKinsey’s internal AI platform in two hours using a decades-old technique — The Decoder（参照日: 2026-03-09）
- How We Hacked McKinsey’s AI Platform — CodeWall（参照日: 2026-03-09）
- An AI Agent Broke Into McKinsey’s Internal Chatbot and Accessed Millions of Records in Just 2 Hours — Inc.（参照日: 2026-03-09）
- CodeWall says it hacked McKinsey’s AI platform. Here’s what holds up — and what doesn’t. — Edward Kiledjian（参照日: 2026-03-10）
- How an AI Agent Hacked McKinsey and Exposed 46 Million Messages — NeuralTrust（参照日: 2026-03-10）
