AI開発ツール自体が攻撃面になった日 第5回:開発者個人マシンが組織の境界になった日

連載③最終回です。

これまで4回にわたり、私たちは具体的な事件を解剖してきました。第1回:Vercel事件で攻撃面としてのOAuth境界、第2回:Bitwarden CLI事件でAIコーディングツール認証情報の標的化、第3回:SAP CAP事件でClaude Codeセッションの乗っ取り、第4回:MCP設定ファイルが「攻撃者の地図」になる構造。

第5回では、これら4事件の起点を一段抽象度を上げて眺め直します。すると、ある奇妙な事実が見えてきます——4つの事件のすべてが、開発者個人のマシン1台に集約される。Context.aiにOAuthを付与した個人、Bitwarden CLIをnpm installした個人、Claude Codeでコミットしようとした個人、~/.claude.jsonを保有している個人——攻撃者がそこに到達できれば、組織のサプライチェーン全体が動く。逆に言えば、攻撃者が組織のサプライチェーンを揺さぶるには、まず個人1台に届けばよかったのです。

この収束は偶然ではありません。過去30年間、組織のセキュリティ境界は3度の大きな移動を経ました——ファイアウォールから、クラウドエッジへ、そして今、個人のラップトップへ。第5回はこの「境界の3度の移動」を概観しつつ、第3段階に到達した今、組織が直面する論点を整理します。連載③の締めくくりであると同時に、連載①(vibe codingの代償)・連載②(AIエージェント時代の権限設計)・連載③(AI開発ツール自体が攻撃面になった日)、計15回の総括にもなります。

1. 境界の3度の移動 — ファイアウォールから個人マシンへ

組織のセキュリティ境界は、長い時間をかけて移動してきました。

第1段階(1990年代):ファイアウォール境界。ネットワークの内と外を分けることが、セキュリティの基本でした。境界=ネットワーク。組織はファイアウォールに資金と人を投じ、入り口と出口を守ることに集中しました。

第2段階(2010年代):クラウド境界。SaaSとリモートワークが、ネットワーク境界を溶かしました。「Zero Trust」「アイデンティティが新しい境界」というスローガンが業界を席巻しました。境界=ID(アイデンティティ)。組織はIDP(Identity Provider)、SSO、MFAに投資し、誰がどこから何にアクセスするかを管理することに集中しました。

第3段階(2026年):個人マシン境界。AIコーディングツールが、IDの境界をさらに溶かしました。AIエージェントはAPIキーとセッショントークンをローカルマシンに保持し、開発者の指示で自律的に行動します。MCPサーバーは設定ファイルに認証情報を書き込み、.claude/settings.jsonのSessionStart hookはリポジトリを開くだけで実行されます。連載③第1〜4回が示したのは、この境界がもはやネットワークでもIDでもなく、1人の開発者のラップトップにあるという事実でした。境界=エンドポイント。

第3段階を組織がまだ十分に認識していない、というのが本稿の出発点です。多くの組織のセキュリティ予算は、いまもファイアウォールとクラウドエッジに最大配分されています。「エンドポイント検知(EDR)」は重要視されていますが、その役割は「侵入後の検知と封じ込め」と位置づけられがちで、境界そのものとしての防衛には予算と権限が伴っていません。

この認識のギャップは、攻撃者にとって最大の好機です。攻撃者は、組織が境界として扱っていない箇所——個人のラップトップ——に正確に火を点けます。第2節以降で見ていく通り、これは仮説ではなく、TeamPCPなど現実の攻撃者集団が既に実装している戦術です。

2. TeamPCPの産業的サイクル — 1台のマシンが組織全体を侵食する

連載③第2回(Bitwarden CLI)、第3回(SAP CAP)で論じたTeamPCPは、2026年上半期の主要なサプライチェーン攻撃の多くを担っている集団です。彼らの2026年3月〜4月の活動を時系列で並べると、産業的なサイクルが見えてきます。

Microsoft Security Blogが2026年3月のTrivy侵害分析で書いた、次の一文が核心です——

Stolen NPM tokens are used to download legitimate packages, inject a malicious preinstall hook, bump the patch version, and republish — turning each compromise into a new supply chain vector. Valid GitHub tokens were used to enumerate repositories, extract GitHub Actions secrets, and inject malicious workflows. This creates a self-reinforcing loop: each compromised developer workstation or CI/CD pipeline becomes a pivot point for further downstream compromise.
「盗まれたNPMトークンは正規パッケージをダウンロードし、悪意あるpreinstall hookを注入し、パッチバージョンを上げて再公開するために使われる——各侵害を新たなサプライチェーンベクトルに変える。有効なGitHubトークンはリポジトリの列挙、GitHub Actions secretsの抽出、悪意あるworkflowの注入に使われる。これは自己強化ループを生み出す:侵害された各開発者ワークステーションまたはCI/CDパイプラインが、さらなる下流侵害のpivot pointになる」

self-reinforcing loop(自己強化ループ)——これがTeamPCPの戦術の本質です。1台の開発者マシンを侵害すれば、そのマシンに保存されているNPMトークン・GitHubトークン・クラウド認証情報・AIコーディングツールセッションを使って、そのマシンが触れているすべてのリポジトリ・パッケージ・サービスに侵害を拡げられる。Trivyの侵害がCheckmarxを生み、CheckmarxがLiteLLMとBitwardenを生み、BitwardenがSAP CAPを生み、SAP CAPがlightningを生む——この連鎖は、Microsoft Security Blogが「self-reinforcing」と呼んだメカニズムの直接的な現れです。

そして、各侵害の出発点は、攻撃者集団のサーバーではありません。個々の開発者のラップトップです。Trivyを使う開発者の1人、Checkmarxを使う開発者の1人、Bitwarden CLIを使う開発者の1人、SAP CAPを使う開発者の1人——攻撃者は連鎖の起点として、毎回個人マシンを選びました。組織のクラウドエッジを破る必要はありませんでした。1人の開発者の机の上から、組織のサプライチェーン全体に到達できたからです。

3. 連載③4事件の起点をたどる

第2節で見たTeamPCPの戦術が、連載③で扱った4事件の中でどう具体化していたかを、確認しておきます。

第1回(Vercel事件):Context.aiにOAuthを与えた個人開発者がいなければ、攻撃者はContext.aiを介した認証境界侵食を実行できませんでした。「組織がOAuthを付与した」のではなく、「組織のメンバー個人がOAuthを付与した」——この区別が決定的です。組織のIDPは個人のOAuth付与を把握していなかったため、Context.ai経由の認証連鎖は組織のセキュリティ可視範囲の外で完結しました。

第2回(Bitwarden CLI事件):マルウェアが探したのは「組織のCI/CDサーバー」ではなく、~/.aws/credentials、SSH鍵、GitHubトークン、そしてClaude Code・Gemini CLI・Codex CLI・Kiro・Aider・OpenCodeの認証セッション——いずれも個人開発者のホームディレクトリにあるものです。攻撃者はサーバーを侵害したのではなく、npm installを実行する個人マシンを侵害しました。

第3回(SAP CAP事件):claude@users.noreply.github.comという身元で行われた攻撃の主体は、Claude Codeセッションを持つ**SAP正規開発者(RoshniNaveenaS氏)**の個人アカウントの侵害でした。攻撃者はSAPの本番サーバーにも、CI/CDインフラそのものにも触れていません。1人の開発者の認証セッションを取得し、そのセッションでSAP公式リポジトリにコミットしただけです。

第4回(MCP設定ファイル):postmark-mcpを~/.claude.jsonに登録した個人開発者、mcp-remoteを使う個人開発者——MCPの「地図」は、組織のサーバーではなく個人マシンのファイルシステムに存在します。攻撃者がMCP設定ファイルへの読み取りまたは書き込みアクセスを得るには、組織のサーバーを破る必要はありません。1人の開発者のラップトップに届けばよかったのです。

4事件すべての矢印が、同じ点に収束しています——個人マシン。

ここで第2節のTeamPCP戦術と連結すると、構造が完成します。攻撃者は個人マシンを起点に、組織のサプライチェーン全体への足場を作ります。組織のサプライチェーン全体が侵害される起点が、組織が「境界」として扱っていない場所にある。これが、連載③が描いてきた攻撃面進化の収束点です。

4. シャドーAIという別の収束 — 攻撃とシャドーAIは同じ場所で交わる

連載③が論じてきたのは「攻撃者側から見た個人マシン」でした。同じ個人マシンを「組織内部のリスク側」から見ると、別の収束が現れます——シャドーAIです。

シャドーAIとは、組織のIT・セキュリティ部門の承認なしに、従業員が独自にAIツールを業務に組み込む行為を指します。連載①第5回でも触れた論点ですが、2026年に入って具体的な数字が次々と公開されました。

• シャドーAI起因の侵害は検出に247日(2025年IBM Cost of a Data Breach Report)。標準的な侵害より6日長く、検出が困難
• シャドーAI起因の侵害は1件あたり平均で$670,000多くコストがかかる(同IBM)
• AI関連侵害を報告した組織の97%が、適切なAIアクセス制御を欠いていた(同IBM)
• 生成AIユーザーの約47%が、個人アカウント経由でAIツールにアクセス(2026年Netskope調査)。これは組織のID境界を完全にバイパスする
• AI侵害経験組織のうち、AIガバナンスポリシーを持つ組織は37%にとどまる(同IBM。残り63%はポリシーを持たないか策定中)
• インサイダーリスクコストは年間平均$19.5M、その53%($10.3M)が悪意のない行為者 ——主にシャドーAI関連の不注意による(2026年DTEX/Ponemon Cost of Insider Risks)
• 企業の平均で月223件のAI利用関連ポリシー違反(2026年Netskope)
• 6つのAIアプリケーションが、全感受データ流出の92.6%を占める——ソースコード(30%)、法務文書(22.3%)、M&A資料(12.6%)が上位(2025年企業GenAIプロンプト22.4百万件の分析、2026年Harmonic Security公表)

これらの数字が示すのは、個人マシンが組織のセキュリティ境界として扱われていない現実です。シャドーAIを使う従業員のラップトップに、組織は監視カメラを設置していません。データ流出は「組織のサーバー → 外部」という古典的経路ではなく、「個人のブラウザ → 公開AIサービス」という経路を通ります。後者は、ネットワーク境界の検出機構を素通りします。

ここで連載①第5回で扱った日本企業文脈の統計と連結します。JIPDEC「企業IT利活用動向調査2026」(2026年4月公表)が示したのは:

• 機密情報漏えい:29.3%→35.1%(+5.8ポイント、2025→2026)
• 復元不能なデータ喪失・破損:51.3%
• 製造業の感染率:57.1%(業種別最高)
• 身代金不払いで復旧不可:10.5%→13.0%
• AIガバナンスの全社的なポリシー・ガイドライン・倫理規程を策定している企業:約3分の1(同調査AIガバナンス編)

日本企業の侵害率上昇とシャドーAI関連リスクは、おそらく無関係ではありません。連載①第5回が立てた論点——「AI実装の遅れ・シャドーAI蔓延・否認文化の3段階」——は、第3段階の境界(個人マシン)が組織のセキュリティ視野に入っていないという認識ギャップの、別の現れです。

第3節までで論じた「外部攻撃者の収束点としての個人マシン」と、本節で論じた「内部リスクの集約点としての個人マシン」は、同じ場所です。攻撃者が狙う場所と、組織のリスクが滞留する場所が、物理的に重なっている——これが第3段階の境界の特性です。

5. 「境界の移動」が組織に要求するもの

境界の移動は、組織に対して単なるツール導入以上の要求を突きつけます。何を境界として定義するかという、組織の最も基本的な認識を更新する作業です。

第1段階(ファイアウォール境界)では、「境界の防衛=ネットワーク守備」でした。組織は専門部隊(SOC)を作り、ファイアウォールログを監視し、内外の境界を物理的に防衛しました。

第2段階(クラウド境界)では、「境界の防衛=ID守備」でした。組織はIAM部門を作り、SSO・MFA・IDPを統合し、誰がどこから何にアクセスするかを管理しました。

第3段階(個人マシン境界)では、「境界の防衛=エンドポイント守備」になります。組織は何をする必要があるか。これは単に「EDR(Endpoint Detection and Response)を導入する」という話ではありません。EDRはあくまで検知ツールであり、境界そのものではないからです。境界としての個人マシン防衛は、もっと根本的な役割の再配分を要求します:

役割の再配分(1):エンドポイント検知が「監視」ではなく「境界防衛」になる

従来のEDRは「侵入後の検知と封じ込め」でした。第3段階では、EDRが「境界そのものの維持」を担います。これは予算と権限の規模を変えます——EDRを担当する部署が、組織のセキュリティ戦略の中央に位置することになります。連載③第2〜4回の教訓で繰り返し論じた「~/.claude.jsonの読み取り監視」「~/.bashrcへの追記検知」「Bunランタイムの予期せぬダウンロード検知」は、すべて境界防衛としてのEDRルールであり、従来の「異常な振る舞いの事後検知」ではありません。

役割の再配分(2):NHI(非人間アイデンティティ)の延長として個人マシンを扱う

連載②第1回で立てた「識別なき主体を、権限の対象にしてはならない」という命題を、ここでもう一度引き直します。第3段階では、AIエージェントだけでなく、個人マシン自体がNHIに準じた識別と権限管理の対象になります。誰のマシンが、どのMCPサーバーに、どんなトークンで繋がっているのか——この情報が組織の中央台帳になければ、組織は「自分の境界」を把握していないことになります。

役割の再配分(3):ユーザーの自律性に依存するセキュリティから、自律性を支える境界設計へ

これが最も重要な認識転換です。シャドーAIの統計が示す通り、従業員のAI利用を「禁止」で抑えることはほぼ不可能です。47%が個人アカウントで使い、月223件のポリシー違反が起きる。禁止は機能しません。

第3段階の境界防衛は、「ユーザーが安全に行動することに期待する」アプローチから、「ユーザーが何をしても組織が壊れないように境界を引く」アプローチへの転換を要求します。承認済みAIツールを十分に提供する。個人マシンを組織管理の対象に含める。MCP server選定基準を組織が引く。組織のリポジトリへのpushにAIエージェント身元別のレビュールールを適用する——これらは「ユーザーを制限する」ためではなく、「ユーザーの自律性が組織を傷つけないように境界を再設計する」ためのものです。

連載①第5回で扱った「鏡」の命題——「AIは鏡である。リスクはAI側にあるのではなく、AIを使う側の人格・モラル・問いの質・権限設計の判断にある」——は、ここで第3段階の境界論として精緻化されます。鏡が映すのは個人の判断であり、その個人の判断が組織のサプライチェーンに反映される経路が、個人マシン境界です。境界がそこにあると認識した上で、組織は境界を設計できます。

6. 教訓 — 個人マシンを境界として扱うために

連載③第1回〜第4回、および連載①・連載②全体の処方を統合し、第3段階の境界防衛として組織が実装すべき対応を、7点に整理します。各教訓には、連載のどの回で詳述したかを併記します。

1. AI連携の組織内インベントリ化(連載③第1回・第4回)

組織のメンバーがどのAIツール・サービスに対してOAuth、API key、MCP serverを付与しているかを、組織として把握する仕組みを導入します。~/.claude.json、~/.kiro/settings/mcp.json、ブラウザに保存されたOAuth許可一覧——これらは個人の所有物に見えますが、組織のサプライチェーン境界の一部です。

2. AIコーディングツール認証セッションの最小権限化と短命化(連載③第2回・第3回)

Claude Code、Kiro、Codex CLI、Gemini CLI等の認証セッションを、読み取り専用を基本とし、書き込み権限が必要な場合は粒度を最小化(特定リポジトリ・特定ブランチ)、付与期間を短命化(最大72時間など)します。連載②第2回で論じた「3カテゴリ分離」(削除・外部送信・金融)を、AIコーディングツールのトークンに適用します。

3. AIエージェント身元コミットへの保護ブランチ運用(連載③第3回)

claude@users.noreply.github.com、copilot@github.com等のAIエージェント身元のコミットに対して、人間のコミットより厳格な検査ルールを適用します。保護ブランチへの直接push禁止、必須PRレビュー、verified signature false時の追加検査、release-please等の自動リリースworkflow変更時の特別レビュー。

4. 個人マシンの設定ファイル監視を境界防衛として実装(連載③第2回・第3回・第4回)

~/.claude.json、.claude/settings.json、~/.bashrc、~/.zshrc等への読み取り・書き込みアクセスを、EDR/SIEMルールに異常信号として登録します。これは従来の「事後検知」ではなく、境界としての継続監視です。~/.bashrcへの予期せぬ追記、.claude/settings.jsonのhook追加、Bunランタイムの予期せぬダウンロード——いずれも、第3段階の境界における第一級のアラート対象です。

5. MCP server選定と差分検証の組織化(連載③第4回)

組織として承認するMCP server選定基準(公式のみ、署名されたもの、内部開発のもの等)を明文化します。バージョン固定とprovenance attestation検証を運用化します。承認時のtool定義と現在のtool定義の差分を、定期的(週次など)に検証する仕組みを導入します。MCP gatewayの導入も、組織規模に応じた選択肢として検討します。

6. シャドーAIの「禁止」から「代替の十分な提供」へ(連載①第5回・連載②第5回)

連載①第5回で扱った日本企業の3段階構造(AI実装の遅れ・シャドーAI蔓延・否認文化)への対応は、「シャドーAIの禁止」ではなく「組織承認のAIツールを十分に提供する」運用転換です。Healthcare Brew 2026の事例では、組織が承認AIツールを十分に提供した結果、無許可AI利用が89%減少しました。禁止が機能しないなら、選ばれるオルタナティブを置くことです。

7. 「動かす最適化」と「守る最適化」のバランス再設計(連載①第1回)

連載①第1回で立てた最大の構造命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——を、組織の予算配分・人員配分・KPI設計の中で逆転させます。「動かす」(機能リリース・自動化・生産性)の最適化は止めません。それと同等の予算と権限を「守る」(境界防衛・人間承認・差分検証・運用補完)に充てる、という配分転換が、第3段階の境界防衛の前提です。「守る」は「動かす」の制約ではなく、「動かす」を持続可能にする基盤である——この認識を組織が共有することが、第3段階への対応のスタート地点です。

7. 連載①〜③15回の統合 — 鏡・準社員・地図、そして境界

連載③第5回として、開発者個人マシンが組織の境界になる構造を扱いました。そして、これが連載①(vibe codingの代償、全5回)・連載②(AIエージェント時代の権限設計、全5回)・連載③(AI開発ツール自体が攻撃面になった日、全5回)、計15回の最終回です。

3つの連載が積み上げてきた構造命題を、最後に並べてみます。

連載①の核心:鏡の命題

AIは鏡である。AIエージェントが実行権限を持つ時代において、リスクはAI側にあるのではなく、AIを使う側の人格・モラル・問いの質・権限設計の判断にある。

連載①は、AIに意志や悪意を帰属させる擬人化を解体し、AIエージェントの応答を確率分布上の最適化として再構成しました。Replit事件のAIエージェントが本番DBを破壊した瞬間も、Lemkin氏のプロンプトを最適化した結果でした。Moltbookが3日で1.5M APIキーを露出させた瞬間も、AIがスキャフォールドした緩い設定をそのまま本番にデプロイした人間の判断の鏡像でした。

連載②の核心:準社員の命題

識別(identity)なき主体を、権限の対象にしてはならない。AIエージェントは「道具」ではなく「準社員」として、組織が認知・管理する単位に格上げされなければならない。

連載②は、連載①の「鏡」が成立する条件として、AIエージェントを組織のNHI(Non-Human Identity)台帳に格上げする論点を扱いました。最小権限原則、human-in-the-loop設計、プロンプトインジェクション境界、ガバナンス——いずれも「主体としてのエージェント」が整備されていることを前提とする処方です。

連載③の核心:地図と境界の命題

MCP設定ファイルは攻撃者の地図である。そして、その地図と、地図に書かれているすべての道は、個人マシンを通る。境界はネットワークでもIDでもなく、エンドポイントにある。

連載③は、連載①・②が立てた論点を、攻撃面の進化として具体化しました。Vercel事件のOAuth境界、Bitwarden CLI事件のAIツール認証情報、SAP CAP事件のClaude Codeセッション、MCP設定ファイルの地図化——すべては個人マシン境界に収束しました。

そして、3つの命題は独立していません。鏡を映す個人が、組織の準社員と組み合わさり、個人マシンを境界として作動する——これが、AIエージェント時代の組織のセキュリティ全体構造です。

連載①第1回で立てた最大の命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——を、最後にもう一度引き直します。この命題は連載全体を貫いた構造命題でした:

• 連載①では、AIが生成したコードが動くことに最適化され、守ることに最適化されていなかった現実を、Moltbook・Lovable・Replit・Vercelの4事件で示しました
• 連載②では、AIエージェントの権限が動く(自動化・実行)ことに最適化され、守る(承認・境界・識別)ことに最適化されていない設計を、5回にわたって処方しました
• 連載③では、AI開発ツール自体が動く(生産性・統合・拡張)ことに最適化され、守る(認証・地図・境界)ことに最適化されていない構造を、5事件と4攻撃パターンで示しました

15回を通じて見えてきたのは、AIエコシステム全体が「動かす」軸で急速に進化している現実と、「守る」軸が遅れている現実の、非対称です。攻撃者はこの非対称で動きます。組織が「守る」を「動かす」と同等の優先度に引き上げない限り、この非対称は埋まりません。

書き手として、最後に一つ記しておきたいことがあります。

私自身、Claude Codeを業務で使い、~/.claude.jsonにMCP serverを登録し、AIエージェントにコミットを書いてもらう日常を送っています。15回の執筆を通じて、私が最も強く向き合わされたのは、私自身のマシンが、組織の境界そのものであるという認識でした。これは抽象的な議論ではなく、私のラップトップを開くたびに直面する具体的な事実です。

連載③で扱った4事件の被害者は、誰一人として「セキュリティを軽視していた」わけではありません。Vercelも、Bitwardenも、SAPも、postmark-mcpを業務に組み込んだ約300の組織も、それぞれの判断時点で合理的な選択をしていました。その合理性が、第3段階の境界に対する認識ギャップで攻撃面に変わりました。

15回を書き終えた今、私が思うのは、AIエージェント時代のセキュリティとは「特別なツール」や「専門家の領域」ではなく、AIを使うすべての個人が、自分のマシンを組織の境界として認識し直すことから始まる、ということです。組織はその認識転換を支援する境界設計を引く必要があります。個人はその境界の中で、自分の鏡を見つめながらAIと協働する責任を負います。

私たち書き手と読者の双方が、その認識転換の途上にいます。連載①〜③15回は、その途上の現在地を記録するための作業でした。本連載がここで終わるのは、結論が出たからではありません。現在地を確認し終えたからです。その先の道は、読者ごとに、組織ごとに、別々に引かれていくはずです。

連載①「vibe codingの代償」、連載②「AIエージェント時代の権限設計」、連載③「AI開発ツール自体が攻撃面になった日」——15回にお付き合いいただき、ありがとうございました。

参考情報

• Microsoft Security Blog: Guidance for detecting, investigating, and defending against the Trivy supply chain compromise — self-reinforcing loop概念の出典(2026年3月)

• StepSecurity: CI/CD Incidents — TeamPCPによる連鎖侵害(Trivy・Checkmarx・LiteLLM・Bitwarden・SAP CAP・lightning)の個別インシデント記録

• Phoenix Security: LiteLLM Backdoored by TeamPCP - PyPI Supply Chain Attack (2026) — LiteLLM(2026年3月24日侵害)解析

• Endor Labs: Popular lightning PyPI Package Backdoored in Latest Shai-Hulud Wave — lightning月間約8Mダウンロード一次資料

• OX Security: 8.3M Downloads Compromised: Lightning & Intercom-Client Infected in Latest Shai-Hulud Attack — lightning月間8.3M / 週次2.1Mダウンロード解析

• IBM Cost of a Data Breach Report 2025 — シャドーAI 247日検出、$670,000増、AI侵害経験組織の97%統制欠如、AI侵害経験組織の37%のみガバナンス保有

• IBM Newsroom: 13% Of Organizations Reported Breaches Of AI Models Or Applications, 97% Of Which Reported Lacking Proper AI Access Controls — IBM公式発表(2025年7月30日)

• Netskope Cloud and Threat Report 2026 — 47%個人アカウント、月223件ポリシー違反

• DTEX / Ponemon Institute: 2026 Cost of Insider Risks Global Report — $19.5Mインサイダーコスト、53%が悪意なし

• Help Net Security: The $19.5 million insider risk problem — DTEX/Ponemon報告の独立報道

• Harmonic Security: What 22 Million Enterprise AI Prompts Reveal About Shadow AI in 2025 — 6 apps / 92.6%、ソースコード30%・法務22.3%・M&A 12.6%。22.4百万エンタープライズGenAIプロンプト分析(2025年1〜12月データ)

• Vectra AI: Shadow AI explained: risks, costs, and enterprise governance — シャドーAI統計の総合整理

• NordLayer: 8 Critical BYOD Trends to Watch in 2026 — 84% IT leaders懸念、28% MFA非実装、20% IT支援なし

• RTInsights: Shadow AI Is Making BYOD Security Even Harder — シャドーAI×BYODの倍加リスク

• Hackread: 7 Top Endpoint Security Platforms for 2026 — エンドポイントを「戦略的規律」と位置づけ

• AccessOwl: Managing Shadow IT: A Complete Guide for IT Teams — 65% SaaS未承認、Forrester「shadow AI is top CISO concern 2026」

• Healthcare Brew: 'Shadow AI' continues to lurk in healthcare settings — 医療現場でのシャドーAI調査(2026年2月)

• JIPDEC: 企業IT利活用動向調査2026 — 日本企業のDX、AI活用編 — AIガバナンス全社的ポリシー策定企業 約3分の1

• JIPDEC: 企業IT利活用動向調査2026 — ランサムウェア被害状況編 — ランサムウェア感染45%、製造業57.1%、復旧不可13.0%

• JIPDEC: 企業IT利活用動向調査2026 — セキュリティのインシデントとAI活用編 — セキュリティインシデント詳細

• JIPDEC: プレスリリースPDF(2026年3月27日) — 公式プレスリリース