相次ぐ不正アクセスはなぜ止まらない？原因と今すぐ確かめる8項目

様子を見る前に、穴の形を見る

2026年9月末から、不正アクセスなどによる情報漏えいの公表が相次いでいます。
民間企業（ウェステリア）がまとめた一覧には、9月25日から10月20日までに70件を超える公表が並びます。同社は、網羅的な一覧ではないと断っています。

10月7日から9日にかけては、8つの機関が相次いで注意喚起を出しました。
個人情報保護委員会、JPCERT/CC、警察庁、国家サイバー統括室、IPA（情報処理推進機構）、総務省、経済産業省、金融庁（国家サイバー統括室のまとめ）。

こうした報道が続くと、社内ではこんな声が出やすくなります。

「AIを業務に入れるのは、もう少し様子を見てから」

気持ちはよく分かります。
でも、私たちはそうは考えていません。

公表された情報を並べると、原因は二つの穴に分かれます。
一つは、既知の脆弱性が直されないまま残る、保守運用の穴。
もう一つは、誰に何を許すかという、設計の穴です。

そして二つ目の穴は、AIに業務を任せるときに、最初から正しく作れる部分です。
様子を見ていても、穴は塞がりません。
穴の形が分かれば、AIの導入は止める理由ではなく、守りを作り直す機会になると考えています。

では、何が起きているのか。事案から見ていきます。

狙われたのは、自社の外の入口

被害は業種を問いません。
一般向けのアプリだけでなく、BIツールや従業員向けの管理システムも狙われています（JPCERT/CCの注意喚起）。

次の表は、原因の型が異なる主な事案です。2026年10月27日時点の各社の公表によるもので、続報で変わることがあります。「原因の型」は、公表文をもとに私たちが分類しました。

侵入経路がまだ公表されていない事案も、多くあります。
ウェステリアの一覧（10月21日更新）では、9月25日から10月8日までに公表された36件のうち、20件で侵入経路が未公表です。一連の事案が同じ攻撃者によるものかも、公式には確定していません。

ただ、表を見ると目立つものがあります。
委託先のアカウント。APIの認可。
どちらも「誰に何を許すか」に関わる事案です。

大和証券の事案では、問い合わせ管理を受託していたスカラコミュニケーションズが不正アクセスを受けました。
影響は、シチズン時計、損害保険ジャパン、東武鉄道、オリックス生命保険にも及びました。
一つの委託先が、複数の会社に共通する入口になっていたわけです。

自社のシステムだけを見ていては、守りきれません。
では、二つの穴はそれぞれどう塞ぐのか。

二つの穴は、塞ぎ方が違う

JPCERT/CCは10月8日の注意喚起で、確認された攻撃を手口ごとに5つ（ケースA〜E）に整理しています。ケースEは、10月23日に追加されました。

既知の脆弱性を端から試す。APIを不正に呼び出す。BIツールの弱点を突く。サーバーに不正なプログラムを置く。そして、AIで攻撃を自動化するツールを悪用する。

これを塞ぎ方で分けると、次の図になります。

まず、左の穴から見ていきます。

見つかる速さに、直す速さが追いつかない

保守運用の穴は、直す側が追いついていないことから生まれます。

一番分かりやすいのは、見つかる脆弱性の数です。
脆弱性を登録・管理する米非営利団体MITREのデータを、共同通信が集計しました（デイリースポーツ掲載、10月24日）。
2026年は10月21日までに約8万5千件。前年同期の約2.2倍です。
2024年は約4万件、2025年は約4万8千件。毎年、過去最多を更新しています。

共同通信は背景として、生成AIの普及を挙げています。研究者が、短時間に大量の脆弱性を見つけられるようになったためです。

一方、直す側はどうか。
格付け会社Moody'sが、10月19日にレポートを公表しました（Infosecurity Magazine）。
悪用が確認されている脆弱性でも、修正にかかる期間の中央値は87日だったとしています。
半数は、3か月たっても直っていないことになります。

特定の会社の怠慢ではないと、私たちは見ています。
見つかる速さに、直す体制が追いついていない。構造の問題です。

AIの関与は、分かっていることと分かっていないことを分けて読む必要があります。

JPCERT/CCは、攻撃者がAIを使って既知の脆弱性を探したり、API経由で攻撃したりしていたことを確認したとしています。
セキュリティ会社のGMOサイバーセキュリティ byイエラエは、10月19日に公表しました。攻撃元のインフラで、AIによる攻撃自動化ツールが使われていたというものです。同社が観測できた範囲では、標的は約20社。そのうち8社が、9〜10月に漏えいを公表しています。
NICT（情報通信研究機構）も、同じ種類の攻撃がより多くのシステムに及ぶおそれを指摘しています。AIで、アプリの解析や脆弱性の探索が効率化されるためです。

一方で、個々の事案のどれにAIが使われたかは、2026年10月時点で公式には確定していません。
確かに言えるのは、一つだけです。
探す側が速くなるほど、修正の遅れは響きやすくなる。

だから、この穴は「作った後に誰が直し続けるか」を先に決めることで小さくします。考え方はAIで作ったアプリは誰が直す？パッチが追いつかない時代の保守運用で扱います。

では、右の穴はどうか。
こちらは、パッチを当てても塞がりません。

パッチでは塞がらない穴がある

表の事案で、公表された対象件数が最大だったのはソースネクストです。会員情報を取得するAPIが、不正に利用されました。
この種の攻撃は、ソフトウェアを最新に保っていても起こります。
APIが、本来は断るべき問い合わせにも応じてしまう作りになっているからです。

各機関の指摘は、3つにまとまります。

一つ目は、アプリに鍵を埋め込まないこと。
公開したアプリは、解析される前提で考えます。アプリに秘密の鍵が入っていると、正規のアプリを通さずにAPIを呼べてしまいます。
NICTは、アプリを解析してその裏のサーバーを狙う攻撃を「A2B攻撃」と名付けました。アプリ自体に脆弱性がなくても、サーバー側の認可に不備があれば漏えいにつながるとしています。

二つ目は、サーバー側で、操作の中身ごとに許可すること。
「正規のアプリから来たから安全」とは考えません。誰が、どのデータに、何をしようとしているかを、API自身が毎回確かめます。

個人情報保護委員会は10月7日、注意喚起の資料に1つの事例を加えました（個人情報保護委員会「WARNING」）。
ログインした攻撃者が、リクエストの会員IDを書き換えるだけで、他人の情報を取得できた事例です。
会員IDは連番。短時間の大量アクセスも、制限されていませんでした。
OWASP（国際的なセキュリティ団体）も、この種の不備をAPIの代表的なリスクに挙げています。

三つ目は、アカウントと委託先を管理すること。
盗まれた正規アカウントや委託先のアカウントで入られると、自社が更新を欠かさなくても防げません。
IPAは公表事例の傾向から、起点を2つ挙げています（IPA）。外部に公開しているアプリやサービスの侵害と、アカウントの侵害です。国家サイバー統括室は、委託先に渡すデータと権限を最小にするよう求めています。

どれも、後からパッチで足せるものではありません。
最初の設計で決まります。

ここからが、AIを業務に入れる会社にとっての本題です。

AIの経路は、最初から正しく作れる

AIエージェントに業務を任せれば、AIが業務システムを呼び出す経路が一つ増えます。
増えると聞くと、不安になるかもしれません。
でも、新しく作る経路だからこそ、さきほどの3点を最初から組み込めます。そうすれば、今回のような穴は開きません。

まず、許可を業務操作の単位で切ります。

顧客向けポータルで、AIが問い合わせに答える場合を考えます。
「顧客データベースを読める」という広い権限は渡しません。「ログインしている顧客本人の契約内容を表示する」という操作だけを許し、本人かどうかはサーバー側で毎回確かめます。

社内の管理システムでも同じです。
「担当顧客の契約更新日を一覧にする」はAIに任せる。「請求先の住所を変える」は、前提条件を確かめたうえで人の承認を通す。操作ごとに決めます。

こうしておけば、AIがだまされたり乗っ取られたりしても、被害は許した操作の範囲に収まります。考え方はAIエージェントの権限設計で詳しく扱います。

ただ、許した範囲の中でも、誤りは積み重なります。
これは許可の設計だけでは止められません。承認と判断ログで見つけます（AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール、AIエージェントの監視と停止）。

次に、AIに鍵を見せません。
今回の事案では、アプリに埋め込まれた鍵や、他で盗まれた鍵が使われました。
AIに外部サービスを使わせるときも、認証情報はプロンプトやコードに置きません。AIから読めない場所で管理します（AIエージェントは誰の権限で動くのか）。

最後に、保守を誰が持つかを、作る前に決めます。
内製するのか、基盤の事業者に任せるのか。それで修正の届き方は変わります。
事業者に任せれば、その事業者は新しい委託先の一つになります。国家サイバー統括室が求める「委託先との責任分界の確認」は、AIの基盤にも当てはまります。

少なくとも2点は、導入前に言葉にしておきます。
どこまでを事業者が直し、どこからを自社が設定するか。外部サービスの鍵をどこに置き、誰が失効させられるか。

どれを選んでも、AIに何を許したかの責任は、使う会社に残ります。統制を置く場所の選び方はAIエージェントの権限設計で整理しています。

導入がスムーズに進みやすいAIの選び方

次の基準を満たす基盤や作りなら、情シスへの説明が短く済み、導入がスムーズに進みやすくなります。

1. 許可の判定がサーバー側の1か所にある：画面から操作しても、AIが動いても、同じ判定を通る
2. 業務操作の単位で許可と承認を決められる：「表を更新できる」ではなく「この操作だけ」と言える
3. AIが鍵を見ない：認証情報はAIから読めない場所にあり、すぐに失効させられる
4. 基盤の更新を誰が持つかが明確：どこまでを事業者が直し、どこからを自社が設定するかを説明できる

自社の公開システムで確かめる8項目

AIの話とは別に、今ある顧客向けポータルや社内の管理システムも点検しておくと、AI導入の議論も進めやすくなります。

各機関の注意喚起を重ね合わせると、確かめることは次の8つです。
情シスや開発元と分担し、最初に1と6で守る対象とアカウントを洗い出します。外部に公開しているものは、2〜4を開発元や委託先に確かめてもらうと、順序よく進みます。

1. 外部に公開しているアプリとサービス、それらが使うAPIを洗い出す
2. 未適用のパッチや、使っていない公開機能・管理画面が残っていないかを確かめる
3. アプリに鍵を埋め込んでいないか、漏れたときすぐ無効にできるかを確かめる
4. APIの一つひとつが、操作の対象と内容ごとに許可を確かめているかを見る
5. 管理者アカウントに多要素認証をかけ、退職者や委託先のアカウントが残っていないかを確かめる
6. 委託先と外部サービスのアカウント、権限、ログを確かめる
7. 大量取得を止める制限をかけ、ログを取って保持する
8. 使い終えたデータを持ち続けていないかを確かめる（持っていないデータは漏れない）

自社で判断がつかないときは、外部に脆弱性診断を依頼します。

被害が疑われるときの報告先は、個人情報保護委員会の案内にまとまっています。
不正アクセスのように不正な目的のおそれがある個人データの漏えいは、件数にかかわらず報告の対象です。速報は、発覚から概ね3〜5日以内が目安です。
調査の相談先として、IPAは10月16日に不正アクセス特別相談窓口を開設しています。

情シスに説明するときの要点

• 相次ぐ事案の原因は「保守運用の穴」と「誰に何を許すかの設計の穴」の二つに分かれる。AIの導入で増えるのは後者の経路で、最初から正しく作れる
• AIには業務操作の単位でしか許可を渡さず、判定はサーバー側で毎回行う。乗っ取られても被害は許した操作の範囲に閉じる
• 許した範囲の中の誤りは、承認と判断ログで見つけて止める
• AIに鍵を見せない。認証情報はAIから読めない場所に置き、すぐ失効できるようにする
• 基盤の更新を誰が持つかを、導入前に決めて文書にしておく

穴の形が分かれば、前に進める

相次ぐ不正アクセスは、AIを業務に入れることへのブレーキに見えるかもしれません。
でも、原因を分けて見れば、やることははっきりしています。

保守運用の穴は、誰が直し続けるかを先に決めて小さくする。
設計の穴は、「誰が、どのデータに、何をしてよいか」をサーバー側で判定する作りで塞ぐ。

この考え方は、AIに業務を任せるときに最初から組み込めます。
まずは、読み取り中心の業務から始める。業務操作の単位で許可を決め、承認と記録で様子を見ながら、書き込みを伴う業務へ広げていく。

二つの穴への備えを先に決めておけば、AIの活用を止める必要はありません。
だから、AIに任せる範囲は広げられる。
私たちは、そう確信しています。

関連記事

• AIエージェントの権限設計：許可を業務操作の単位で切る考え方と、統制を置く場所の選び方
• AIで作ったアプリは誰が直す？パッチが追いつかない時代の保守運用：AIで作ったアプリを、誰が直し続けるか
• AIエージェントは誰の権限で動くのか：AIに鍵を見せない設計
• AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方：社内審査をスムーズに通すための準備
• AIエージェントのセキュリティ全体像：シリーズの全体像

参考資料

• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（10月8日公開、10月23日更新）
• JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（10月15日）
• 個人情報保護委員会「WARNING 不正アクセスによる個人データ漏えい防止のための注意喚起」（10月7日改訂）
• 個人情報保護委員会「漏えい等報告」
• 内閣官房 国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」（10月9日）、各機関の注意喚起のまとめ（10月14日）
• IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（10月9日）、不正アクセス特別相談窓口の開設（10月16日）
• OWASP API Security Top 10 2023「Broken Object Level Authorization」
• NEC（10月20日）、ソースネクスト（10月15日）、GMOリサーチ&AI「infoQ」第2報（10月14日）
• @IT：大和証券ほか5社に影響した「同じ委託先」への不正アクセス（10月10日）、@IT：タイムズカー
• ウェステリア「2026年9月末から相次ぐ情報漏えい｜公表された事案の一覧」（10月21日更新。民間企業がまとめた一覧で、同社は網羅的ではないと断っている）
• デイリースポーツ（共同通信の集計）：AIで欠陥発見、今年急増（10月24日）、共同通信（熊本日日新聞）：ITシステムの弱点、発見が急増（10月17日）
• NICT「相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」」（10月13日）
• ScanNetSecurity：GMOサイバーセキュリティ byイエラエ、攻撃元にARTEXを確認（10月21日）
• Infosecurity Magazine: Exploited Vulnerabilities Typically Take Three Months to Patch, Moody’s Finds（10月19日）

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

Askhubでは、誰に何を許すかの判定をサーバー側の1か所に置いています。画面から操作しても、AIが動いても、外部のツールから呼び出しても、同じ判定を通ります。画面でボタンを隠すのは使いやすさのためで、できるかどうかはサーバーが決めます。そのため、画面を改造したりAPIを直接呼んだりしても、権限は広がりません。外部のツールからの利用は既定で拒否し、どのツールにどこまで許すかはワークスペースの管理者が決めます。基盤の脆弱性対応と更新は当社が持ちます。新しく公開された部品は一定期間を置いてから採用し、既知の脆弱性の検査を通らないものは本番に出しません。緊急度の高い脆弱性は14日以内、重要な脆弱性は30日以内に修正を終える目標で運用し、外部の専門会社による脆弱性診断を年1回受けています。利用者データの漏えいなどが起きたときは、速やかにお知らせし、状況・影響の範囲・講じた措置を報告することを規約で定めています。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：製品の全体像、外部ツール連携