サイバー攻撃は、昔から「速さ」「しつこさ」「技術力」がものをいう世界でした。
ただ、2026年に入ってからは、その前提がかなり変わってきたように感じます。攻撃者が何年もかけてプログラミングを学び、脆弱性の仕組みを深く理解し、複数人で役割分担しなければできなかったことが、AIによって一部ショートカットされるようになってきました。
もちろん、AIを使えば誰でも一流の攻撃者になれる、という話ではありません。そこは冷静に見る必要があります。ただ、これまでなら実行できなかった人が、AIの補助を受けて攻撃に近づけるようになったことは、企業側として無視できない変化です。
守る側に求められるのは、「検知したら対応する」「見つけたらパッチを当てる」という従来型の発想だけではなく、攻撃の入口そのものを減らす考え方です。
TABLE OF CONTENTS
AIは、攻撃者の学習コストを下げている
生成AIやコーディング支援AIの普及によって、攻撃者の姿は少しずつ変わっています。
以前であれば、攻撃用のプログラムを書くには、プログラミング、ネットワーク、認証、エラー処理、対象システムの挙動など、複数の知識が必要でした。途中でエラーが出ても、自分で調べて直す力が求められます。
ところが今は、AIにコードを書かせ、エラー内容を貼り付け、修正案を出させ、処理の意味を説明させることができます。攻撃者にとっては、学習や試行錯誤の負担が大きく下がっている状態です。
国内でも、生成AIの悪用が疑われる未成年による不正アクセス事件が報じられています。楽天モバイルの不正契約に関する事件では、中高生が不正アクセスや回線契約に関与したと報じられました。また、快活CLUBをめぐる事件では、17歳の少年が不正アクセスに関与し、約725万件の会員情報を取得した疑いが報じられています。
こうした事例から見えてくるのは、「動機はあるが技術力が足りない人」と「実際に攻撃を組み立てられる人」の距離が縮まっているということです。
AIは補助役から、自律的に動く「オペレーター（エージェント型AI）」へ
AIの悪用リスクは、単にフィッシングメールの文章が自然になる、という話にとどまりません。
Anthropicは2025年、Claude Codeが大規模なデータ窃取・恐喝行為に悪用された事例を報告しています。同社によると、少なくとも17の組織が標的となり、AIによって偵察から認証情報の収集、ネットワーク侵入、さらには盗んだデータの分析や恐喝文の生成までが自動化・効率化されていました。
ここで重要なのは、AIが単なる「文章作成の助手」ではなく、意思決定を伴いながら攻撃サイクルを完結させる「実行主体（オペレーター）」になりつつある点です。
| 攻撃工程 | AIが悪用される可能性がある作業 |
|---|---|
| 偵察 | 公開情報の整理、対象候補の洗い出し、攻撃面の分析 |
| 開発 | 不正プログラムの作成、エラー修正、処理ロジックの改善 |
| 侵入 | 認証情報の悪用、設定不備の探索、手順の自動化 |
| 窃取後 | 盗んだファイルの分類、重要情報の抽出、金銭的価値の推定 |
| 恐喝・詐欺 | 相手に合わせた文面作成、説得力のあるメッセージ生成 |
この変化を見ると、2026年の脅威は「AIが作ったマルウェア」だけではありません。より大きな問題は、AIによって攻撃の準備、実行、拡大が効率化されることです。
ソフトウェアサプライチェーンが狙われやすくなっている
AI支援型の攻撃と相性が悪い領域のひとつが、オープンソースを含むソフトウェアサプライチェーンです。
Sonatypeは、2025年を通じてnpm、PyPI、Maven Central、NuGet、Hugging Faceなどのエコシステムで、45万4,600件を超える新たな悪性パッケージを確認したと報告しています。かつては悪ふざけやスパムに近いものも多かったオープンソースマルウェアが、開発者やビルド環境を狙う継続的な攻撃へ変化している、という指摘です。
特にnpmで確認されたワーム型攻撃「Shai-Hulud 2.0」の事例では、2万5,000件を超えるGitHubリポジトリが汚染されるなど、AIのスケール能力を背景にした爆発的な拡散が脅威となっています。
この種の攻撃が厄介なのは、自社のシステムに直接侵入されるとは限らないことです。
- 開発者が汚染されたパッケージをインストールする
- CI/CDパイプライン上で悪性スクリプトが実行される
- npmトークン、GitHubトークン、クラウド認証情報が盗まれる
- 保守者アカウントが悪用され、別のパッケージへ感染が広がる
- 正規の開発フローを通じて、本番環境にリスクが入り込む
企業が信頼しているソフトウェア、開発ツール、ビルド環境そのものが攻撃経路になります。これは、従来の境界防御だけでは見えにくいリスクです。
パッチを早く当てるだけでは追いつかない
セキュリティ対策では、長い間「早くパッチを当てること」が重要だと言われてきました。これは今でも正しいです。脆弱性を放置してよい理由にはなりません。
ただし、パッチ適用だけを中心にした守り方には限界が見えています。
Edgescanの2026年脆弱性統計レポートでは、2025年に公開されたCVEは4万8,185件で過去最多とされています。また、重大度の高いアプリケーション/API脆弱性の平均修正期間は54.81日、デバイス・ネットワーク系の高・重大脆弱性では平均39日とされています。
攻撃者側は、新しい脆弱性情報を見て、数時間から数日で悪用コードやスキャン手法を組み立てることがあります。AIが加わることで、公開情報の読み解き、PoCコードの作成、対象探索、自動化がさらに速くなる可能性があります。
つまり、企業側が数週間かけて修正している間に、攻撃者はその隙間を狙ってくるわけです。
検知も難しくなっている
従来の検知は、既知のシグネチャ、不審なコードの特徴、怪しい文字列、過去に観測された挙動などに依存する場面が多くあります。
しかし、AIを使って作られた悪性コードや悪性パッケージは、見た目だけでは判断しにくくなることがあります。
- READMEやドキュメントが自然に整っている
- パッケージ名や説明文がもっともらしい
- コード構造が通常のライブラリに近い
- テストコードやサンプルまで用意されている
- 特定の環境で実行されるまで悪性挙動が見えにくい
悪性コードが「見るからに怪しい」時代ではなくなっています。特に開発者端末やCI/CD環境のように、認証情報や公開権限が集まる場所では、実行前に止める仕組みが重要になります。
これから必要なのは、攻撃の種類ごと消す考え方
AI支援型攻撃に対して、守る側が永遠に速さだけで勝ち続けるのは現実的ではありません。
もちろん、検知、監視、パッチ適用、インシデント対応は必要です。ただ、それだけでは攻撃者とのスピード競争になってしまいます。今後は、「見つけたら直す」だけでなく、「そもそもその攻撃が成立しにくい構造にする」ことが重要です。
ソフトウェアサプライチェーンであれば、次のような対策が現実的です。
- 出所を確認できる依存関係だけを利用する
- 不要な依存パッケージを減らす
- パッケージの自動更新を無条件に通さない
- CI/CDで使うトークンや認証情報の権限を最小化する
- ビルド環境で長期間有効なシークレットを使わない
- 公開レジストリから取得したパッケージをそのまま信用しない
- SBOMや依存関係の棚卸しを継続する
- 不審なインストールスクリプトや外部通信を検知・制御する
一例として、Chainguard Librariesのように検証可能なソースコードから再ビルドする手法では、テストにおいて悪性npmパッケージの99.7%、Pythonパッケージの約98%を阻止したというデータも報告されています。特定製品の導入ありきではなく、「どの依存関係を、どこから、どのような信頼根拠で使っているか」を見直すことが重要です。
企業が今すぐ見直したいポイント
1. ソフトウェアサプライチェーンを経営リスクとして扱う
悪性パッケージ、保守者アカウントの侵害、CI/CDシークレットの流出は、開発部門だけの問題ではありません。
本番環境、顧客データ、サービス停止、ブランド信用に直結するため、経営リスクとして扱う必要があります。特にSaaS、EC、金融、医療、公共系のシステムでは、開発工程そのものが攻撃対象になっている前提で考えた方が安全です。
2. 公開パッケージを無条件に信用しない
オープンソースは現代の開発に欠かせません。ただし、公開レジストリにあるから安全、ダウンロード数が多いから安全、という判断は危険です。
人気パッケージの保守者アカウントが侵害されるケースもあります。自社で利用している依存関係、更新頻度、保守状況、権限、インストール時の挙動を把握することが必要です。
3. CI/CDを重要資産として保護する
攻撃者にとって、CI/CD環境は非常に魅力的な標的です。
なぜなら、そこにはソースコード、デプロイ権限、クラウド認証情報、パッケージ公開権限が集まりやすいからです。開発者端末やビルド環境で盗まれたトークンが、そのままサプライチェーン攻撃に使われる可能性があります。
- CI/CD用トークンの権限を最小化する
- 使っていないシークレットを削除する
- 長期間有効な認証情報を避ける
- ビルドログに秘密情報が出ないようにする
- パッケージ公開権限を持つアカウントにMFAを徹底する
4. パッチ適用と同時に、露出管理を行う
パッチ適用は必要ですが、全ての脆弱性を即日で修正するのは現実的ではありません。
そのため、どの脆弱性が外部公開資産に存在しているのか、攻撃に使われやすい状態なのか、認証情報や機密データに近い場所なのかを見極める必要があります。
単にCVSSの点数だけで並べるのではなく、自社環境における攻撃可能性と影響度を踏まえて優先順位をつけることが大切です。
5. 検知後対応だけに頼らない
AI支援型攻撃では、攻撃の準備と展開が速くなります。
侵入後に検知する仕組みはもちろん必要ですが、開発環境、依存関係、認証情報、外部公開資産の段階でリスクを減らす方が、結果的に被害を小さくできます。
「入られたら検知する」だけでなく、「入られにくくする」「広がりにくくする」「使われても被害が限定される」設計が重要です。
AI時代に守りを強くするための考え方
AIは、防御側にとっても強力な道具です。ログ分析、脆弱性管理、コードレビュー、問い合わせ対応、教育など、多くの場面で活用できます。
一方で、同じ技術は攻撃者にも使われます。開発者を速くする道具は、攻撃者の試行錯誤も速くします。業務効率化のための自動化は、フィッシング、マルウェア、探索、恐喝の拡大にも使われます。
だからこそ、2026年はセキュリティの考え方を少し変えるタイミングだと思います。
従来の検知とパッチ適用だけに頼るのではなく、外部公開資産を減らす。不要な依存関係を減らす。CI/CDの権限を絞る。ソフトウェアの出所を確認する。長く使われている認証情報を整理する。
一つひとつは地味ですが、攻撃者にとってはやりにくい環境になります。
速さで競うより、攻撃が成立しにくい形へ
AI支援型攻撃は、もう先の話ではありません。
攻撃者の学習コストは下がり、攻撃の準備は速くなり、ソフトウェアサプライチェーンやCI/CD環境のような、企業活動の中核に近い場所が狙われています。
守る側が全ての攻撃より速く動き続けるのは、簡単ではありません。だからこそ、速さだけで勝とうとするのではなく、攻撃の入口を減らし、権限を絞り、信頼できるものだけを通す設計が重要になります。
派手な対策だけがセキュリティではありません。使っているパッケージ、公開している資産、CI/CDに置かれた権限、長く残ったトークン。そうした足元を見直すだけでも、攻撃者にとっての選択肢は確実に減ります。
AI時代のセキュリティは、検知して追いかけるだけではなく、最初から攻撃が成立しにくい環境を作ることに近づいていくはずです。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
