従業員ひとり。AIツール1つ。「すべて許可」のクリック1回。

2026年4月、世界的なWebインフラ企業Vercelが、セキュリティインシデントを公式に開示しました。侵入経路は、会社が契約したSaaSではありません。従業員が個人判断で試した1つのAIツールから漏えいした、OAuthトークンでした。

本記事では、この事件を日本の情報システム部門（以下、情シス）の視点で読み解きます。Shadow AI（業務で無断利用されるAIツール）が映し出す5つの盲点と、明日から始められる打ち手をまとめました。

Vercel事件の全体像

事件の構造を正しく理解するには、3つの観点で整理する必要があります。攻撃の時系列、確認済みの事実と未検証情報の切り分け、そして本事件が示した新しい攻撃パターン。この順で見ていきます。

攻撃の3段階時系

この事件は、2026年2月から4月にかけて、3つの段階で進行しました。

第1段階：2026年2月（起点）

Context.ai（AI Office Suiteを提供する企業）の従業員端末が、Lumma Stealerに感染しました。これは、端末内の認証情報を盗み出す情報窃取型マルウェアです。感染により、Google Workspaceの資格情報が外部へ流出します。各種APIキーや、OAuth連携で発行された認証情報（OAuthトークン）も同時に盗まれました。

第2段階：2026年3月（検知と封じ込め）

Context.aiが、自社のAWS環境への不正アクセスを検知しました。CrowdStrike社と連携してフォレンジック調査を実施します。AWS環境を停止し、消費者向け製品の終了を発表しました。この時点での影響評価は「限定的」とされます。

第3段階：2026年4月19日（Vercel開示）

Vercelが公式にインシデントを開示しました。調査にはMandiant、他の外部セキュリティ会社、法執行機関が関与しています。同時期にBreachForums上で動きがありました。ShinyHunters名義のアカウントが、Vercelのデータを200万ドルで販売すると主張したのです。

確認事実と未検証情報の切り分け

この事件では、確認済みの事実と未検証の主張を分けて扱う必要があります。

Vercel公式が確認した事実

• 侵入経路はContext.ai経由であること
• 攻撃ベクターは侵害されたOAuthトークンであること
• 漏えいデータは"sensitive"フラグがない環境変数であること
• Next.js、Turbopack、Vercelオープンソースプロジェクトはサプライチェーン攻撃から安全と評価されたこと
• 公開IOC（侵害指標）として、OAuth App IDが開示されたこと

未検証の主張

• ShinyHuntersが販売を主張するデータ（ソースコード・NPM/GitHubトークン）の真正性
• ShinyHuntersが実際に関与した主体かどうか
• 影響を受けた顧客数

情シスとして記事や報道を読む際は、この切り分けを前提に情報源を確認することが重要です。

新しいパターン：組織をまたぐラテラルムーブメント

なお本事件は、ラテラルムーブメント（lateral movement：侵害された認証情報を使った横展開）の典型例でもあります。従来、ラテラルムーブメントは「社内ネットワーク内での横移動」を指す概念でした。Vercel事件は、その定義が広がったことを示しています。

Context.aiに侵入したマルウェアが盗んだOAuthトークンは、Vercelのアカウントに紐付いた認証情報でした。このトークン経由で、攻撃者は別組織であるVercelの内部システムへ直接アクセスできたのです。

「自社ネットワークは守っている」「自社の端末はEDRで監視している」。それだけでは不十分な時代に入りました。取引先や連携SaaSの侵害が、そのまま自社への侵入経路になる。この新しいパターンを前提に、守り方を再設計する必要があります。

出典：Vercel公式開示（2026年4月19日）／BleepingComputer／BreachForums上のShinyHunters投稿（未検証）

盲点1：情シスが承認していないツールは、すでに社内にある

「うちの会社では、勝手なSaaS導入は禁止しています」

そう答える情シス部長は多いかもしれません。しかし、現実の数字は別のことを語っています。

『The Shadow AI Crisis, 2026』では、次のように報告されています。

従業員の78%が情シスの承認を経ずにAIツールを業務利用している。さらに、そのうち30%が業務メールアドレスでサインアップしている。

業務メールでの登録は、単なるルール違反では終わりません。SSO（シングルサインオン）の認証基盤を経由するからです。Google Workspaceや社内システムへのOAuth連携が成立します。つまり、情シスが知らないうちに「会社のアカウントに外部AIサービスがつながっている」状態が生まれるのです。

日本の職場に置き換えると、以下のような例が思い当たるのではないでしょうか。

• 会議議事録の自動要約AI（Otter、Notta、Google Meet標準機能）
• 翻訳・要約ツール（DeepL、ChatGPT、Claude、Gemini）
• コード生成AI（GitHub Copilot、Cursor）
• プレゼン作成AI（Gamma）
• スケジューリングAI（カレンダー連携型）

どれも業務効率を押し上げる便利なツールです。そして、その多くが「個人でサインアップ→業務メールで認証→OAuth連携」というルートをたどります。情シスのSaaS一覧には現れません。

Vercel事件のContext.aiも、会社として契約したSaaSではありませんでした。従業員が個別に試した「ちょっと便利なAIツール」が、結果として侵入の扉になったのです。

出典：The Shadow AI Crisis, 2026（CamoCopy）

盲点2：「すべて許可」は組織でもっとも危険なボタン

OAuth連携の画面には、いくつもの権限項目が並びます。メールの読み取り、カレンダーへのアクセス、ドライブのファイル閲覧、連絡先の参照、送信権限。

しかし、それを丁寧に確認する従業員は多くありません。

Software AGの2024年調査では、以下のように報告されています。

‍46%の従業員が新しいAIツールを使う際、会社のポリシーを確認しないと回答した。

半数近くが、権限画面を「とりあえず全部OK」で通過しているということです。

「すべて許可」は、便利さの代償として組織のデータを差し出すボタンです。読み取り権限だけのつもりが、書き込みや送信の権限まで含まれていた。そんなケースは実際に起きています。

Vercel事件でも、Context.aiに付与されたOAuthトークンは複数スコープの権限を持っていました。Google Workspaceの広い範囲へのアクセスが可能な状態です。このトークンが盗まれた時点で、攻撃者は正規の認証情報を手にしたも同然です。

情シスの視点で見ると、もう1つ恐ろしい事実があります。「クリックした本人さえ、自分が何を許可したか覚えていない」という点です。事後に棚卸しをしようとしても、個別の権限範囲を追いきれません。

Vercel事件で公開されたOAuth App IDは、次の通りです。

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

自社のGoogle Workspace管理コンソールで、このIDによる連携履歴を確認する価値があります。過去に同じApp IDによる連携が存在しなかったかを、念のため点検しましょう。

出典：Software AG, 2024／Vercel公式開示（2026年4月19日）

盲点3：Shadow AI経由の侵害は、金額でも誤差ではすまない

「Shadow AIのリスク」と言われても、被害金額が見えにくいと経営層への説明は難しくなります。ここは数字で押さえておきましょう。

IBM『Cost of a Data Breach Report 2025』では、印象的な数字が報告されました。

Shadow AI経由で発生したインシデントでは、通常のデータ侵害コストに追加負担が乗る。その額、平均+$670,000（約1億円、1ドル=150円換算）だ。

なぜ追加コストが発生するのか。Shadow AIが絡むインシデントは、以下の理由で対応が長期化しやすいためです。

• どのツールに、どのデータが流れていたかの特定に時間がかかる
• 認証経路が複数にまたがり、封じ込めが難しい
• 漏えい範囲の確定に、外部フォレンジック調査が必要になる
• 顧客・取引先への説明責任の範囲が広がる

日本企業特有のコスト要素

日本企業の場合、ここにさらに国内特有の負担が重なります。

• 個人情報保護委員会への報告義務：改正個人情報保護法により、漏えい時は速報と確報の提出が必要です
• 金融庁モニタリング対象企業：金融庁への報告と追加監査への対応が発生します
• NISC（内閣サイバーセキュリティセンター）との連携：重要インフラ事業者は連絡調整が求められます
• 業界別ガイドライン対応：金融ならFISC、医療なら3省2ガイドラインに沿った説明責任があります
• J-SOX（内部統制報告書）への影響：上場企業は内部統制の評価に影響が及ぶ可能性があります
• 投資家向け説明責任：Vercel事件でも投資家への説明が発生しています

Vercel事件では、脅威アクター（ShinyHunters名義）が追加の情報窃取を主張しています。ただしこの部分は、Vercel公式が検証したものではありません。検証済みの事実と、脅威アクターの主張を切り分ける。この姿勢はインシデント対応の基本です。ただShadow AIが絡むと情報ソースが増えるぶん、切り分け自体にも工数がかかります。

出典：IBM Cost of a Data Breach Report, 2025／Vercel公式開示（2026年4月19日）

盲点4：統制が必要な瞬間に、統制の枠組みが存在しない

多くの日本企業に当てはまる、構造的な課題を指摘します。

IBMの2025年調査では、以下のように報告された。

‍63%の組織がAI利用に関するガバナンスポリシーを持っていないと回答した。さらに、ポリシーを持つ組織のうち18%のみが、そのポリシーを実際に施行できている状況だった。

ポリシーがないか、あっても機能していない。この状態でShadow AIが拡大すると、インシデント発生時に以下の事態が起きます。

• 誰が意思決定するかが曖昧になる
• 該当ツールの利用停止や、トークン失効の手順が定まっていない
• 社内への通知範囲・タイミングの判断基準がない
• 再発防止のための全社棚卸しが、後手に回る

EDR/XDRが万能でない理由

「当社はEDR（端末監視型のセキュリティ製品）を入れている」という声もあります。ただ、EDR/XDRがShadow AIに効きにくい理由があります。

実は、Context.aiはCrowdStrike（代表的なEDRベンダー）を導入していました。それでも、OAuthトークンの流出は、AWSインシデント対応の初期段階で検知できていません。

理由はシンプルです。エンドポイントやインフラの可視化と、SaaS間の権限・アイデンティティの可視化は、別の軸にあるからです。EDRが監視するのは端末上の異常挙動です。一方、OAuthトークンは正規の認証情報として扱われます。連携先のSaaSから見れば、それは「正規ユーザーのアクセス」としか映りません。

日本企業でもEDRの導入率は上がっていますが、アイデンティティ軸の監視はまだ手薄です。「端末は見ているが、アカウントと権限のつながりは見ていない」。このギャップが、Shadow AIの温床になっています。

紙のポリシーは、可視化手段がなければ機能しません。どのAIツールに、誰が、どんな権限で接続しているか。この事実が見えていなければ、ポリシーは絵に描いた餅で終わります。

出典：IBM Cost of a Data Breach Report, 2025

盲点5：見えないものは統制できない

5つの盲点を通じて浮かび上がるのは、1つの原則です。

見えないものは、統制できない。

Shadow AIは「悪意ある従業員」の問題ではありません。日々の業務を少しでも効率化したい、真面目な従業員ほど積極的にAIツールを試します。問題なのは、その試行が情シスに見えない構造にあります。OAuth連携という形で、会社の認証基盤に静かに接続されていくのです。

従来のSaaS管理ツールは、購買経路のあるSaaSを前提に設計されてきました。契約・請求・アカウント発行を情シスが管理できるSaaSです。一方、AIツールの多くはフリーミアム、個人登録、OAuth連携という経路をたどります。購買経路を持たないため、従来の管理フローでは捕捉できません。

求められるのは、AI統合も含めたSaaS可視化と、OAuth権限のガバナンスです。

• どのSaaS・AIツールが、社内で実際に使われているか
• それぞれに、誰のアカウントが、どんな権限で連携しているか
• 退職者や異動者のOAuthトークンが、いま現在も有効になっていないか
• リスクの高い権限範囲（メール送信、ドライブ書き込み）が、どのツールに付与されているか

これらが一覧で見える状態を作ることが、AIガバナンスの出発点になります。

日本企業が明日から始められる5つの打ち手

ここからは、読者がすぐ着手できる具体的な打ち手を5つ提示します。それぞれ「何をするか」「なぜ必要か」「最初の一歩」の3点で整理しました。

打ち手1：OAuth連携アプリの棚卸し

何をするか

Google WorkspaceやMicrosoft 365の管理コンソールから、OAuth連携アプリの一覧を取得します。従業員が個別にインストールしたサードパーティアプリを、すべて洗い出します。

なぜ必要か

Shadow AIの多くは、このOAuth連携の一覧に現れます。ところが、棚卸し作業は定期化されていない企業が大半です。まずは現状把握からしか、打ち手は組み立てられません。

最初の一歩

Google Workspaceなら「管理コンソール→セキュリティ→APIコントロール→サードパーティアプリのアクセス」から一覧をエクスポートできます。Vercel事件のIOCに挙がっているOAuth App IDが含まれていないかも、あわせて確認しましょう。

打ち手2：「すべて許可」に代わる最小権限設計

何をするか

管理者承認が必要なOAuthスコープを絞り込みます。高リスクなスコープ（Drive全体アクセス、Gmail送信、連絡先の参照）には、管理者レビューを挟む運用に切り替えます。

なぜ必要か

従業員の善意のクリック1回で、組織データの大半にアクセスできる権限が外部に渡る現状を変える必要があるためです。Google WorkspaceのApp access control機能を使えば、管理者側で事前に制御できます。

最初の一歩

高リスクスコープを一時的にブロックし、業務への影響を確認します。本当に必要なユーザーだけに例外的に許可を出す運用へ段階的に移行しましょう。

打ち手3：承認済みAIツールのホワイトリスト化

何をするか

社内で利用可能なAIツールを「承認済み」として一覧化します。各ツールについて、扱ってよいデータの種類と扱ってはいけないデータの種類を明文化します。違反時のエスカレーションフローもあわせて整備します。

なぜ必要か

ホワイトリストがない状態で「Shadow AI禁止」と通達しても、水面下に潜るだけです。従業員が「どれを使っていいのか」を判断できる基準を先に示すことが、統制の出発点になります。明確な選択肢があれば、データ流出リスクのある未承認ツールから承認ルートへ自然に流れます。

最初の一歩

現在社内で利用されているAIツールをヒアリングで洗い出します。扱うデータの機密度（個人情報、契約情報、ソースコード）に応じてリスク別に分類し、「承認済み」カテゴリを確定しましょう。ゼロから決めるのではなく、すでに定着している利用実態から逆算するのが現実的です。

打ち手4：SaaS間連携（SaaS-to-SaaS）の継続モニタリング

何をするか

新規OAuth付与時のアラート、未使用トークンの自動失効、トークン有効期限のローテーション運用を整備します。

なぜ必要か

棚卸しは「点」の活動ですが、Shadow AIは「線」で増えていきます。継続モニタリングの仕組みがなければ、棚卸した翌日にまた新しい連携が増えているのが現実です。

最初の一歩

直近90日で新規付与されたOAuthトークンを一覧化します。毎月の定例棚卸しのスコープに「新規追加分のみ」を加えるだけでも、運用負荷を抑えつつ継続性を確保できます。

打ち手5：ベンダーリスク評価フレームワークの再設計

何をするか

契約関係のないベンダーでも、OAuth連携がある時点でリスク対象として扱う評価フレームワークに改定します。SOC2やISO27001の取得有無だけでなく、インシデント開示時の対応プロセスも評価軸に加えます。

なぜ必要か

Vercel事件の教訓は「ベンダーがAWS環境を停止しても、発行済みOAuthトークンは生きていた」ことです。ベンダー側のサービス終了と、自社の権限クリーンアップは別作業なのです。

最初の一歩

既存のOAuth連携アプリについて、セキュリティ資料（SOC2レポート、セキュリティホワイトペーパー）の有無を確認します。資料が取得できないアプリは、リスクカテゴリを一段階上げるルールを検討しましょう。

Josysが可視化する領域

ここまで読んで、「打ち手は理解したが、自社で実際にやるとなると工数が読めない」と感じた情シス責任者の方もいるかもしれません。

JosysはSaaS管理とID管理を1つのプラットフォームで提供します。AI統合を含む社内のSaaS利用状況、OAuth連携の権限範囲、アカウントのライフサイクルを、360度の視点で可視化する設計です。

Shadow AI対応の文脈では、以下の3つのフェーズで活用できます。

フェーズ1：可視化

契約済みSaaSに加えて、Shadow利用されているSaaS・AIツールを検出します。OAuth連携アプリとその権限スコープを、一覧で把握できます。

フェーズ2：統制

リスクの高い権限連携や、退職者・異動者のアカウントを特定します。必要な権限への最小化、不要なアクセスの剥奪をサポートします。

フェーズ3：継続モニタリング

新規OAuth連携の発生や、通常と異なる権限付与を継続的に検知します。棚卸しを「点」ではなく「線」の運用に変える仕組みです。

機能の詳細や、自社環境への適合は、デモで実際の画面を見ながら確認するのが早いと思います。

Shadow AIは例外ではない

Vercel事件を「大手の話」「海外の話」と片付けるのは簡単です。しかし、従業員が業務メールでAIツールに登録する。OAuthの「すべて許可」をクリックする。この瞬間は、日本のどの会社でも、いま起きている可能性があります。

Shadow AIは、特殊な例外ではなくなりました。2026年の業務インフラの一部として、前提に組み込んで考える段階に来ています。

禁止通達を出すだけでは、Shadow AIは止まりません。業務効率化というメリットを従業員が体感している以上、水面下に潜るだけです。

大切なのは、まず現状を可視化すること。自社の環境で、どのAIツールに、どんなOAuth権限が渡っているのかを把握する。そこから、組織に合った統制の形を一緒に考えていけます。

まずは、可視化から始めませんか

「自社では、どのAIツールがどんな権限で動いているのか、まず棚卸ししたい」

そんな第一歩から、Josysはお手伝いできます。30分のオンラインデモで、お使いの環境で具体的にどのような可視化ができるかをお見せします。Shadow AI対応の現状整理として、ぜひご活用ください。

→ Josysのデモを予約する