AI を悪用した不正アクセスが急増しています。この記事では、AI による攻撃が具体的に何をしているのかを整理したうえで、守る側の優先順位をどう変えるべきかと、弊社が提供を始めた「不正アクセス抜き打ちテスト」を紹介します。
なぜ、いま攻撃が急増しているのか
国内の Web システムからの情報漏洩は、前年同月比21倍
国内の Web システムからの情報漏洩が急増しています。株式会社マクニカが公開している公表件数を四半期ごとに合計すると、2025年は1年間で84件でしたが、2026年は第1四半期が13件、第2四半期が27件、第3四半期が80件と増え、10月だけで168件になりました。2025年10月の8件の21倍で、1か月で2025年の1年間の2倍に達しています。
能力の源泉は、ハーネスではなくモデル
攻撃が急増している大きな要因の一つと考えられるのが AI です。AI による攻撃では、ARTEX のような、外部のシステムとの通信、ツールの呼び出し、並列の実行を担う枠組み(ハーネス)に注目が集まりがちです。しかし、能力の源泉はモデルのほうです。ハーネスを馬具、モデルを馬にたとえると、走る力を生むのは馬です。馬具はそのままに、Claude・DeepSeek・GLM・Grok といったモデルだけを付け替えられます。
セーフガードの弱いオープンウェイトのモデルが、最先端に並んだ
Claude・GPT・Gemini のような大手のクローズドなモデルには、強めのセーフガードが付いています。セーフガードは、サイバー攻撃につながる使い方を、安全のために拒否する仕組みです。大手のモデルには、次の特徴があります。
- 最も強いモデルは、一般には公開しない
- 攻撃的な用途には、審査制で提供する
- 既定のセーフガードで、攻撃を止める
一方、GLM・DeepSeek・Kimi のようなオープンウェイトのモデルは、モデルの本体が丸ごと配布されます。セーフガードが弱いことが多く、セーフガードを外した「無検閲」版も出回ります。手元で動かせば、提供元の監視も届きません。そのため、サイバーセキュリティに積極的に活用したい人にも、悪用したい人にも、オープンウェイトのモデルが好まれます。
Anthropic が2026年9月29日に公開した分析によると、攻撃コードを作るベンチマークで、オープンウェイトの GLM-5.3 は、Claude Mythos Preview に近い結果を出しています(ExploitBench で Claude Mythos Preview の14%に対して12%、Anthropic の社内のベンチマークで6%に対して4%)。Claude Mythos Preview に近い攻撃の能力が、数か月のうちに、セーフガードを外せる形で、誰でも使える状態になったことになります。こうしたモデルの進化も、最近の攻撃の激化の一因と考えられます。
オープンウェイトのモデルは、すでに攻撃にも防御にも使われている
オープンウェイトのモデルは、すでに攻撃と防御の両方で使われています。CrowdStrike が2026年10月7日に報告した韓国の金融機関への攻撃では、攻撃者が ARTEX に DeepSeek V4.1-Flash を載せ、GLM-5.3 と Grok 4.6 も併用していました。防御の側では、Hugging Face が、侵入を受けたときの解析で米国のモデルに安全機能で解析を拒否されたため、自社の環境で動かす GLM-5.2 に切り替えています。
本来は世界を守るためのセーフガードですが、攻撃が激化する中で防御側が十分に AI を活用できないという逆効果も生んでいます。
守る側の「猶予」は、もう残っていない
ここでいう猶予とは、攻撃される前に、守る側が脆弱性を見つけて直すための時間のことです。高い攻撃能力を持つモデルを誰でも使えるようになったことで、攻撃は速く、大規模になりました。OpenAI は「Defense Factory」と題したページで、防御側に残された猶予は少なくなっていると警告しています。実際には、猶予はもう残っていないと考えて備えるべき段階です。そのため同じページでは、守る側も、脆弱性を見つけて潰し、パッチを当てることを、自律的に継続して回す仕組みを持つべきだと提唱しています。
AI は、その会社固有の脆弱性まで突ける
「共通の脆弱性」と「固有の脆弱性」
AI が具体的にどう攻撃するのかを理解するには、まず脆弱性の種類を押さえておく必要があります。ソフトウェアにはバグがあり、そのうちセキュリティのリスクにつながるものを脆弱性と呼びます。脆弱性には、大きく2つの種類があります。
- 共通の脆弱性: ライブラリやミドルウェアなど、多くのシステムで使われる部品の脆弱性です。使っている会社のすべてが、同じ弱点の影響を受けます。例は、2026年10月に公開された PHP の脆弱性「php2shell」です。PHP を使う多くのシステムが影響を受けるため、世界中で大きな問題になりました。こうした脆弱性は、CVE として「この製品にこの脆弱性があるので、パッチを当ててください」と広く告知されることもあります。裏を返せば、攻撃者にとっては突きやすい脆弱性です。
- 固有の脆弱性: 自社で書いたコードや、クラウドなどの利用しているツール・プラットフォームの設定不備による脆弱性です。そのシステムにしか存在しません。
固有の脆弱性も、攻撃者にとって割に合うようになった
共通の脆弱性は、相手を選ばずに数を打てば、どこかで当たります。たとえば、WordPress の本体やプラグインの脆弱性を突くコードを、WordPress を使っていそうな Web サイトに手当たり次第に投げれば、どこかに当たります。
一方、固有の脆弱性を突くには、攻めのセキュリティの専門スキルが必要でした。そうしたスキルを持つ人は限られ、多くの場合は割に合いませんでした。AI の登場で、これが次のように変わりました。
- 共通の脆弱性: もともと1つの攻撃コードを何百社にも流せて割に合ううえ、AI に攻撃コードを作らせられるので、攻撃を実行に移すまでの速度も上がりました。以前はパッチが出てから数日以内に当てればよかったものが、今はパッチの公開から数時間で攻撃が始まるので、急いで対処しなければなりません。
- 固有の脆弱性: AI が自律的に脆弱性を見つけて攻撃できるので、割に合うようになりました。影響が大きいのは、こちらの変化です。
攻撃者の狙いは、共通の脆弱性だけから、どちらの脆弱性にも広がりました。ただし、AI は魔法を使っているわけではありません。これまで割に合わずにやらなかったことができるようになり、しかもそれが自動化された処理なので、いくらでも規模を広げられる。これが変化の本質です。
その結果、攻撃は、同じ攻撃コードを多くの会社にばら撒くものから、AI が1社ずつ調べ、固有の脆弱性を探して悪用するものへ変わっています。手当たり次第に石を投げてどこかに当たればよいという攻撃から、1社ずつ狙いを定めて撃ち抜く攻撃への変化です。狙いが正確になって固有の脆弱性まで突けるようになったうえ、その攻撃を多数の会社に同時に並行して仕掛けられます。もちろん、共通の脆弱性も変わらず悪用できます。
Web アプリの固有の脆弱性で多いのは、認証・認可・ロジックの脆弱性
インターネットに面していて最初の侵入口になりやすい Web アプリでは、固有の脆弱性の多くがロジックの脆弱性です。弊社の診断で2023〜2024年に見つかった脆弱性の内訳では、認可制御不備が28%、認証の設計・実装不備が17%、その他のロジックの脆弱性が13%で、上位3つで58%を占めます。AI が発達する以前の時期に、弊社のセキュリティエンジニアが見つけた脆弱性のデータです。
- 認可制御不備: 本来の権限ではできない操作ができてしまう。たとえば、一般の社員の権限で、管理者に相当する操作ができる
- 認証の不備: ログイン・ログアウトやパスワードのリセットなどの不備で、アカウントの乗っ取りにつながりやすい
- その他のロジックの脆弱性: たとえば EC サイトで決済を迂回して、0円で物が買えてしまう
典型的で分かりやすい脆弱性はエコシステムの発展で減ってきていて、今残っているのは、こうしたロジックの脆弱性が多くなっています。
AI は、ロジックの脆弱性を見つけられる
AI を使わない DAST や SAST のツールでは、ロジックの脆弱性は、ほとんど見つけられませんでした。AI のセキュリティツールは、ロジックの脆弱性まで見つけられます。これが、脆弱性診断の分野で AI が起こした大きな変化です。
弊社のセキュリティ AI エージェント Takumi byGMO が、2026年5月29日〜8月4日にブラックボックス診断で見つけた脆弱性の内訳では、その他のロジックの脆弱性が41%、認可制御不備が22%、認証の設計・実装不備が9%で、上位3つで72%を占めます。ソースコードを見ない、やや不利なやり方でも、この割合です。
ここで大事なのは、Takumi の性能そのものよりも、AI はロジックの脆弱性を見つけられるという、これまでの自動化されたセキュリティツールには無かったパラダイムシフトが起きたことです。Takumi にこれだけできるのなら、攻撃者が使う AI でも、ある程度はロジックの脆弱性を突けると考えられます。
Web アプリへの侵入の後も、プラットフォームを横断して攻撃する
Web アプリから最初の侵入に成功した後、侵害を広げるのも AI は得意です。Wiz の分析では、AI は Web アプリを入口にして、次のように横展開や影響の最大化を試みます。
- クラウド: 認証情報を自動で大量に発行し、組織全体の管理権限を奪う
- Kubernetes: クラスタの管理者に昇格し、Secret から認証情報を一括で取る
- CI/CD: パイプラインで秘密情報を集め、悪性のマニフェストを本番へ同期する
- IdP: 管理者のユーザーを作り、権限のグループに追加して、SSO で侵入する
これらすべてに精通したセキュリティエンジニアは、世の中ではまれです。人は Web アプリから入門して分野を広げていくことが多く、すべての分野のエキスパートになるのは簡単ではありません。AI にはそうしたキャリアの段階が無く、最初からさまざまなプラットフォームへの攻撃を並行して行えます。
専門家レベルの攻撃が、機械で増幅される
まとめると、AI はロジックの脆弱性を突くような専門家レベルの攻撃をしていて、プラットフォームを横断できることを考えると、専門家以上と言えるかもしれません。その攻撃が、次の要素で増幅されます。
- モデルへのアクセス: オープンウェイトのモデルに、誰でも簡単にアクセスできる
- 長時間の自律実行: 眠る必要のある人と違い、長い時間、同時に並行して動ける
- マシンスピード: 一つひとつの作業が、人の手より速い
守る側は、どう変わるべきか(今)
結論: 診断より先にペネトレーションテストを
結論から言うと、多くの会社には、脆弱性診断より先にペネトレーションテストを行うことをおすすめします。その理由は、両者の違いを押さえると分かります。
脆弱性診断とペネトレーションテストの違い
脆弱性診断は、1つのアプリケーションについて、縦に機能、横に脆弱性の観点を並べたマス(たとえば機能が5つ、観点が5つなら25マス)を網羅的に確認し、すべてのマスに○か×を付けます。アプリケーションが安全か、つまり出荷してよいかを判断するためのものです。リスクの高い脆弱性は出荷前に直し、リスクの低いものは組織の基準に沿って修正の優先度を下げる、といった判断に使えます。
ペネトレーションテストは、網羅的なチェックではなく、個人情報の漏洩のような特定の目標を達成できるかに絞ります。たとえば、社内のドメインで会員登録でき、そのアカウントで管理画面に入れてしまい、そこから SQL インジェクションで顧客の情報を全件取得できれば、個人情報の漏洩に至ります。このように3つの脆弱性をつなげて目標を達成した時点で、極端に言えば、25マスのうち残りの22マスは見ていません。見ていないマスがあることが、診断との大きな違いです。
- 脆弱性診断: 脆弱性をつなげた評価をするかは、ベンダーによります。実際には、予算の問題ですべての機能を見られないことも多くあります。デモ環境のアプリケーションを単体で見るので、アプリケーションの外は見ません。
- ペネトレーションテスト: 目的の達成に関係しない箇所・観点は検査しません。診断よりもさらに高価です。時には、対象のシステムの外の要素も悪用して、目標の達成につなげます。たとえばシナリオによっては、従業員にフィッシングを仕掛けて侵入することもあります。
| 脆弱性診断 | ペネトレーションテスト | |
|---|---|---|
| 問い | 脆弱性の網羅的なチェック | 攻撃者が特定の侵害目標を達成できるか |
| 向いている | 安全基準を満たしたかの確認(リリース判定) | 致命的なリスクの有無の検証 |
| 苦手 | 範囲外の資産、脆弱性の連鎖による侵害時のインパクトの見積もり | 網羅性の保証 |
これまでは「診断が先」、今は「ペネトレーションテストが先」
弊社はこれまで、まず各アプリの脆弱性診断で大小のリスクを把握して出荷を判断し、そのうえで余力があれば、想定外の要素や広い範囲のリスクを探す選択肢としてペネトレーションテストを、という順番をおすすめしてきました。外部から実際に攻撃を試せる人材は限られ、ペネトレーションテストは高価だったので、最初の一歩にはなりえなかったためです。しかし AI によって、次の2つが変わりました。
- 攻撃が激しくなった: 不正アクセスは、運悪く狙われた一部の会社だけが受けるものではなくなり、どの会社もいつ狙われてもおかしくありません。致命的なリスクを、一時も放置できなくなりました。
- 診断とペネトレーションテストのコストが下がった: AI で安く実施できるようになりました。弊社でも、従来は500万円からで提供していたペネトレーションテストを、200万円ほどまで下げられています。これは、攻撃者も同じように AI で安く攻撃できるということでもあります。
そこで弊社は、おすすめする順番を入れ替えました。まずペネトレーションテストで外部からどこまで侵入できるかを確かめて致命的な脆弱性を塞ぎ、その後に脆弱性診断でより完璧な状態を目指す、という順番です。すべての会社に当てはまるとは限りませんが、多くの会社にはこちらの順番が合っています。攻撃者はあらゆる面を狙ってくるので、外から見える範囲を広く、AI を活用して安くペネトレーションテストを行うことが必要です。
不正アクセス抜き打ちテスト
サービスの概要
こうした考えから、弊社は「不正アクセス抜き打ちテスト」の提供を始めました。攻撃者と同じ立場で、会社全体が不正アクセスされうるかを AI で検証するサービスです。
- 目的: 個人情報の持ち出しなど、重大な不正アクセスができてしまわないかを、実際に侵入を試みて確かめ、あわせて機微情報の漏洩も調べる
- 対象: 弊社が探索し、お客様に承認いただいた、会社全体のインターネット公開資産
- 期間: 30日間のいずれかのタイミングで、予告なく抜き打ちで実施する
- 実施者: 弊社のセキュリティの専門家が、1万件以上の脆弱性を見つけてきた AI エージェントを用いて実施する
- 成果物: 重大な問題の速報と、期間の終了後の最終報告書
- 費用: 一律98万円(税抜。2026年中のお申し込みに限った特別料金)
- 資産探索: ドメインを手がかりに、攻撃者と同じ方法で、インターネット上の公開資産を洗い出します。セキュリティの業界で ASM(Attack Surface Management)と呼ばれるものに当たります。
- ペネトレーションテスト: 見つけた資産すべてを対象に、AI が攻撃者と同じ手口で、実際に侵入を試みます。
- 機微情報の漏洩調査: GitHub など、インターネット上の公開情報から、お客様に関係するパスワードや API キーなどが漏れていないかを調べます。
資産を洗い出すところからペネトレーションテストまでを一気通貫で、しかも AI で行う点が要です。見つけた機微情報は、見つかった場所とあわせてお客様に報告します。
一般的な脆弱性診断との違い
| 不正アクセス抜き打ちテスト | 一般的な脆弱性診断 | |
|---|---|---|
| 資産探索 | あり | なし |
| 機微情報の漏洩調査 | あり | なし |
| 対象範囲 | 会社全体(アプリケーションからネットワークレイヤーまで、外部から到達しうるすべて) | アプリケーション単体 |
| 対象環境 | 本番環境を含む | 原則デモ環境 |
| 費用(税抜) | 98万円 | 100〜300万円 × アプリケーション数 |
| 検証できること | 個人情報漏洩やサーバーの乗っ取りなどの、致命的なリスクの有無 | 深刻度の低いものから高いものまで、網羅的なリスクの洗い出し |
表の最後の行の「検証できること」は、どちらが優れているかではなく違いです。抜き打ちテストは、広く言えばペネトレーションテストなので、致命的なリスクの有無を検証するものです。網羅的に見るのは、脆弱性診断のほうです。
本番環境も対象にする
対象の環境には、本番環境とデモ環境の両方のドメインを含めます。本番環境を含める理由は2つです。
- 攻撃者は本番環境を遠慮なく狙ってくる
- デモ環境と本番環境の差分は、気づかないうちに積み上がっていて、そこにリスクが潜んでいることがある
弊社は本番環境を細心の注意を払って検査していて、過去に本番環境にクリティカルな影響を与えてしまった事案はありません。ただし、影響が出る可能性を100%否定はできないので、実施の前に了承をいただきます(後述)。
費用
費用を一律98万円にできた理由は3つです。
- AI によってコストが下がったこと
- 2026年中のお申し込みに限った特別料金であること
- 完全に定型で提供していること。進め方や範囲のカスタマイズは基本的に無く、契約書も弊社のひな形を使う。需要が高まっている中で、1社でも多くの会社に届けるための形です
進め方
- 主要なドメインの共有(お客様): 必ず対象に含めたいシードドメインを共有します(例: flatt.tech、shisho.dev)。思いつく範囲で構いません。ASM のツールを使っていれば、そこから書き出したものでも構いません。
- 資産探索と一覧の共有(弊社): DNS の受動的な調査と最小限の HTTP リクエストで探索し、見つけた攻撃対象の一覧を共有します。
- 対象の承認(お客様): 他社が管理しているものなど、外したい資産を確かめて承認します。
- 抜き打ちテスト(30日間)(弊社): より深い資産探索、会員登録を含む実際のアプリの操作、脆弱性を悪用した侵入の試行を行います。
期間中に重大なリスクを見つけたら、期間の終了を待たずに速報を送ります。複数のシナリオで目標を達成して、速報を何回か出すこともありえます。期間の終了後には、最終報告書を送ります。最終報告書に書くのは、次の内容です。
- 発見資産の一覧: 資産探索で見つかった攻撃対象
- 判定と目的: 侵入・情報の取得を達成できたか
- キルチェーン: 最初の侵入から目的の達成までの手順
- システム構成図: 攻撃の経路を図で可視化したもの
- 取得できた情報: 実際に持ち出せたデータ
- 漏れていた機微情報: 公開情報から見つけたパスワードなど
どの穴を塞げばよいかを、分かりやすくお示しします。
お客様に了承・承認いただくこと
- 本番環境への影響の了承: 本番環境に、攻撃者と同じように実際に侵入を試みます。極力影響がないように行いますが、本番環境に影響が出る可能性があることを了承いただきます。データのバックアップの状況の確認もおすすめしています。
- 対象範囲の承認: 弊社が見つけた資産の一覧を確かめ、一覧の中への攻撃を承認いただきます。自社の資産でないものなど、攻撃の対象から外したいものは除けます。
守る側は、どう変わるべきか(これから)
AI ペネトレーションテストを、24時間365日へ
高まる脅威に対抗するには、抜き打ちテストのような AI ペネトレーションテストを継続的に行う必要があります。期間を区切った点検ではなく、24時間365日の検証へ移ることが求められます。弊社は、不正アクセス抜き打ちテストを年間プランとして提供する予定です。
特に内製で開発している会社では、AI で開発が速くなり、日々さまざまな差分がデプロイされているので、いつでも外からチェックされうる体制を作ることが重要です。今の攻撃の激しさが続くのか、さらに増えるのかは分かりませんが、減っていくことは考えにくいためです。
攻撃者にない優位、ソースコードを活かす
ペネトレーションテストを先にしても、脆弱性診断が要らなくなったわけではありません。理想を目指すには欠かせないステップです。外から見て致命的な穴がなさそうだと確かめられたら、次は、穴をそもそも生まないための脆弱性診断です。
そのときは、環境を外から見るブラックボックス診断ではなく、ソースコードを使ったホワイトボックス診断か、グレーボックス診断を行うことをおすすめします。グレーボックス診断は、ソースコードで網羅的にリスクを見つけ(ホワイトボックス診断)、その結果を受け渡して、悪用できるかを実環境で判定する(ブラックボックス診断)一連の流れです。ホワイトボックス診断とブラックボックス診断の欠点を、互いに打ち消し合えます。
ソースコードを使えることは、ソースコードが漏れない限り攻撃者にはできない、守る側の優位です。
脆弱性診断も、AI で精度と頻度を両立する
- 手動の脆弱性診断: 精度は高いが、回数が少ない。前回の診断から最大1年間、脆弱性が放置されるリスクがある
- AI を使わない DAST・SAST のツール: 回数は多いが、精度が低い。ロジックの脆弱性や認証・認可の不備は検出できない
- AI-SAST・AI-DAST: 精度が高く、回数も多い。ロジックの脆弱性や認証・認可の不備まで高い精度で検出し、1年に何度も繰り返し実施できる
Takumi には、Git の差分を見て、差分に継続的に脆弱性診断を回す機能もあります。内部で継続的にセキュリティのレビューを回しやすくなります。