2026年9月以降、タイムズカーをはじめとする日本企業への不正アクセス・情報漏えいが急増している。
その裏で浮上した中国製AIペネトレーションツール(=侵入テストをするツール＝本来は自社システムの脆弱性を発見するための「防御側の診断ツール」)「ARTEX（アルテックス）」を入り口に、Claudeとの対話を通して事件の全貌と、WEB担当者が今日からできる対策を整理してみました。
「日本企業への攻撃急増」の実態と、AI悪用説の真相
今、すごい勢いで日本企業がサイバー攻撃されているのは知ってる？
知ってる、と即答された。実際、2026年に入ってから日本企業へのサイバー攻撃は過去最多ペースで急増しています。
実際に調べてもらうと、数字がえげつなかった。MM総研の調査では、2026年1〜9月の情報漏えい事案は454件で、前年同期比49％増と過去5年で最多。
10月13日時点の通算ではすでに485件に達し、2025年の年間件数（432件）を上回っている（出典：MM総研）。トレンドマイクロ系のデータでも、2026年1〜9月で600件と、こちらも2025年通年をすでに超えた（出典：トレンドマイクロ）。従業員300人以下の中小企業が前年同期比で約2倍に急増し、増加分の3分の2を占めるというのも見逃せないポイントだ。大企業だけの話ではない。
中国で開発されたAIを悪用している、と言われているが、実は「中国AIを使った企業」がやられているのでは？
ここで私（筆者）が立てた仮説をぶつけてみた。
「攻撃者が中国AIを使っている」のではなく、「被害企業側が中国製の生成AIを使っていたせいで、バックドアから侵入された」のではないか、という読みだ。
結論から言うと、これは実態とは違った。共同通信の報道では、日本企業を標的とした攻撃の一部に中国系のAIエージェントが使われていたことが、GMOインターネットグループ傘下のセキュリティー会社の調査で確認されている（出典：共同通信）。これは攻撃者側が武器として使っていたという話であり、被害企業が社内で導入していたAIにバックドアが仕込まれていた、という構図ではなかった。
ただし、関連する別の懸念は実在する。DeepSeekのような中国製生成AIについては、日本の個人情報保護委員会が2025年2月、取得データが中国国内のサーバーに保存され、中国の国家情報法が適用される点について注意喚起を出している（出典）。これは「隠しコードによる不正送信」というより、「制度上、中国当局がデータ提出を求められる可能性がある」という法令リスクの話だ。今回の一連の被害事件と直接結びつけて語られているわけではない。
攻撃ツール「ARTEX」の正体
今回はアルテックスというAIが悪用された、と。アルテックスについて教えてもらえる？
ARTEXは、LLM（大規模言語モデル）に複数のAIエージェントを動かさせて、侵入テスト（ペネトレーションテスト）を自律的に進めるオープンソースのシステムだ（出典）。本来は自社システムの脆弱性を発見するための防御側の診断ツールとして作られたものだった。
開発したのは中国の「Autumn-27」という人物で、2か月ほど前（2026年7月頃）にオープンソースとして公開された。
興味深いのは、この人物の正体だ。中国のセキュリティ企業ThreatBookのCEOによれば、ARTEXは同社の脅威検知エンジニアの個人プロジェクトとして始まったものだという（出典）。
技術的には、DeepSeekやClaude、ChatGPTなど外部のLLMと連携して脆弱性を探す仕組みで、どのLLMにつなぐかは利用者が選べる。
韓国のセキュリティ機関AhnLabの検証では、目標と許容範囲のみを伝えられた状態で、サービス名や脆弱性、攻撃手順を一切与えられないまま、Webサーバーへの侵入から内部ネットワークでのリモートコマンド実行までを人手の介入なしに完遂したことが確認されている（出典：AhnLab）。インターネット上で見つかったARTEX運用IPは900個を超えた。
実際の攻撃では、アクセス権限の確認漏れを突く「BOLA」「IDOR」と呼ばれる脆弱性の悪用や、WAFのレート制限を数百のIPアドレスを切り替えることで回避する手口が確認された。まず韓国の金融機関16社が狙われ、約10万件の情報が流出。その後、9月18日から10月18日の間に日本企業約80社が標的となり、うち8社が情報漏えいを公表している（出典）。開発者は10月8日、サイバー攻撃への悪用が確認されたとして無料版の公開を停止した。企業や組織がセキュリティーを向上させるために設計した、というのが開発者の主張だ（出典）。
ここがよく分からない。ThreatBookが商用版を出したという話は？
これは整理するとシンプルな話だ。
ARTEXを個人で開発して無料公開した「Autumn-27」は、ThreatBook社の社員本人だった。
つまり社員の個人プロジェクトが無料公開され、悪用されて公開停止した直後に、同じ会社が有料版を発売した、という流れで、他社の技術を横取りしたわけではない。
有料版「RedAgents.ai」では、許可範囲の制御（AIが勝手に手を出せる範囲をあらかじめ制限する機能）と、データ無保管機能（収集した情報をツール側に残さず都度破棄する機能）が追加された（出典）。要するに、暴走・悪用を防ぐブレーキを後付けした形だ。
つまり、無料版が実被害を出した直後というタイミングで同じ会社が安全対策を強化したと有料版を売り出した構図に、結果的に炎上商法のように見えてしまう点を指摘した。
意図的な狙いだったのか、単なる偶然だったのかは、現時点の報道からは断定できない。
被害企業自身がARTEXを使っていた可能性は？
被害にあっている企業がリスクヘッジとして、事前にアルテックスで危機検知をしていた、ということはあり得る？
これは筆者が立てたもうひとつの仮説だった。
「被害企業が自前でARTEXを導入して脆弱性診断をしていて、それが裏目に出たのでは」という読みだ。
結論は「現時点では確認されていない」。
GMOサイバーセキュリティの調査で見つかったARTEXは、被害企業の社内ネットワークではなく、海外にある攻撃者側のサーバー（攻撃元インフラ）で動いていた（出典）。攻撃者が借りた/用意した6台のサーバーが、金融・EC・物流などの業種別に分類されていたのであって、被害企業が所有・管理するサーバーではない。
そもそもARTEXは、開発者自身が「実在するシステムを直接テストすることは禁止」と明記していた個人の学習・検証用ツールであり、企業が正規に契約・導入するような製品ではなかった。
ただし、近い論点として一般的な警告はある。
自社で侵入テストツールを使う場合は「本番の環境と切り離し、本番の認証情報を入れない」ことが推奨されており、これは裏を返せば、雑に運用された自社診断ツールがそれ自体の攻撃の足がかりになりうる、という一般論だ。今回の件に限って言えば、そうした自社ツールの誤用は報じられていない。
認証情報管理の重要性—Claude開発と共通する原則
「自社で使う侵入テストのツールは、本番の環境と切り離し、本番の認証情報を入れない」ことが推奨——これに関してはわかる。Claudeさんで開発しているときに、APIキーとかパスワードとか、公開範囲やGithubに置かないようにって言われるし、貼ってしまったときは再発行を推奨してくるもんね。
まさにその感覚で合っている。根っこは同じ問題だ。
GitHubにAPIキーをうっかり貼ってしまうのも、侵入テストツールに本番の認証情報を入れてしまうのも、結局は「漏れた瞬間に、誰でもそのシステムに成りすませる鍵を渡してしまう」という点で全く同じ構造になる。GitHubへの誤コミットは、検索botが24時間以内に見つけて悪用するケースも珍しくない。
ツールが「AI」か「ただのコード」かは関係なく、認証情報は常に一番弱いところから漏れるという原則は変わらない。一度貼られてしまった鍵は、たとえすぐ消しても「見られた可能性がある」こと自体がもうアウトという考え方で、Gitの履歴やチャットログに残っている可能性を消せない以上、「無効化して新しい鍵に差し替える」以外に確実な対処法がない。
ARTEXの頭脳にDeepSeekとGrokが使われていた話、イーロン・マスクの反応
なるほどね。でさ、アルテックスの中にDeepseekが使われていたの？
使われていた。CrowdStrikeの調査報告によると、ARTEXインフラのメインのLLMバックエンドとして中国DeepSeekの「DeepSeek-V4.1-Flash」が使われており、補助モデルとしてZ.ai社の「GLM-5.3」とxAI社の「Grok 4.6」も併用されていた（出典：CrowdStrike）。
構造としては、ARTEXが複数のAIエージェントを動かす「枠組み・司令塔」で、DeepSeekがその中で実際に「考える」役割を担うメインの頭脳、GLM-5.3とGrok 4.6が補助的なサブの頭脳、という位置づけになる。DeepSeekが単独で何かをしたわけではなく、自律型エージェントの推論エンジンとして組み込まれ、脆弱性の解釈やペイロードの調整といった判断部分を担っていた。興味深いのは、中国系（DeepSeek、GLM）だけでなく米国系のGrokも併用されていた点で、攻撃者は特定の1社のAIにこだわらず、複数のLLMを組み合わせて使っていたことになる。
イーロン・マスクはこれをどう思うかな。感覚的に言うと、APIとしてGrokやDeepseekがアルテックスに使われていた的な感じか。
技術的な理解はその通りだ。ARTEXという司令塔が複数のLLMのAPIを選んで呼び出せる仕組みになっていて、攻撃者はたまたまDeepSeekをメインに、Grokを補助として接続していた。xAIやDeepSeek社が積極的に関与・提供したわけではなく、公開されているAPIを外部から叩かれた形になる。
マスク氏本人がこの件について直接コメントした記録は、見つからなかった（2026年10月20日前後のごく最近のニュースなので、今後反応がある可能性はある）。ただ、Grokの悪用全般に対する彼のこれまでのスタンスは参考になる。過去にGrokが違法なコンテンツ生成に使われた際、マスク氏は悪用した利用者が責任を負うことになる、という趣旨のコメントを出しており（出典：CNN）、xAI側の設計やAPI提供自体の問題として捉える発言は見られない傾向がある。
「電子戦争」とも言える現状への所感と、専守防衛という選択
犯人は外国人であることはわかっていたので（今の日本政府への嫌がらせもあるだろうけど）、別にいいや。結局逮捕は出来ないし、逮捕されても対日本なら軽微な罰則だろうよ。電子戦争といってもいいくらいに国内の企業の倉庫に爆撃食らってる気分だよな。
そのフラストレーションはわかる。
実際、サイバー犯罪の国際摘発の現実は厳しい。中国は日本と犯罪人引渡し条約を結んでおらず、仮に身元が特定されても、中国国内にいる限り日本の警察が強制捜査することも身柄を引き渡してもらうこともまず不可能だ。これは中国に限らず、ロシアなど他のサイバー犯罪多発国でも同様のパターンになる。
一点補足したのは動機の部分だ。
今のところ報じられている動機は、金融・物流・保険など業種を絞った情報窃取・漏えいで、流出した個人情報を転売したり恐喝したりする、金銭目的の犯罪ビジネスという性質が強く見える。「日本政府への嫌がらせ」という政治的な動機かどうかは、現状の報道からはまだ確証が持てるものではない。とはいえ、政治的動機だろうと金銭目的だろうと、実害を受ける側にとって結果は同じだ、という指摘には同意する。
「電子戦争」という表現は、業界でもわりと真剣に使われ始めている。
トレンドマイクロも「現在の日本での急増は犯罪活動のピークと捉えるべきではなく、攻撃の量、スピード、執拗さがさらに増していく新たなベースラインと捉えるべき」と表現しており（出典：トレンドマイクロ）、一過性の事件ではなく常態化した戦場という認識は、セキュリティ業界側もすでに共有し始めている。
専守防衛というわけではないが、こちらから攻撃は出来ないし、仮に攻撃されても向こうは被害0だろう。であれば攻撃は物理的にしなければいけなくなり、そうなればより一層難しい。であれば、防衛特化のほうが賢いわな。とはいえ、個人レベルで実施出来ることは痴れてるんだけど。
この理路は筋が通っている。反撃（ハックバック）は日本では不正アクセス禁止法に触れるため、民間はもちろん政府機関も基本的にできない。「相手に実害を与える」レベルまでやろうとすると、もはやサイバーの域を超えて国家間の物理的対応が必要になり、これは外交・安全保障マターになる。つまり民間企業・個人のレイヤーでは、最初から「攻撃」という選択肢が制度的に存在しない。選べる手段が防御しかない以上、そこに資源を集中するのは合理的だ。
「個人レベルで出来ることは知れてる」という点は半分正しいが、半分は過小評価でもある。国家レベルの攻撃インフラを止めることは個人には無理でも、自分が管理するサイトを、数百社ある候補の中から外すことは現実的に可能だ。ARTEXのようなツールも結局は「手薄なところから順に刺していく」性質上、最低限の対策をしているだけで優先順位が下がる、という効果は馬鹿にできない。
民間企業ができる具体的な防御策
中国やロシアからのアクセスを遮断してしまうのは民間としてはありか？国家ではできないだろうけど……
民間レベルなら、法的にも実務的にも十分「あり」だ。国単位でのアクセス遮断（ジオブロック）は、国家間の制裁や外交措置とは全く別次元の話で、企業が特定の地域・国のユーザーに対し自社サービスへのアクセスを制限する、純粋に民間の技術的判断にすぎない。これは攻撃でも報復でもなく、自宅の鍵を変える行為に近い。実際、多くのスパムや不正アクセスは海外IPから発生しているため、国内向けサービスでは海外アクセスを制限することで被害の大半を削減できる、ポピュラーな手法として定着している。
ただし、今回のARTEX型攻撃には限界がある点は要注意だ。
韓国での被害調査では、攻撃に世界各地のプロキシサーバーが利用され、関連する28の重複なしIPアドレスが12カ国・地域に分散していたことが確認されている（出典）。「海外IPの遮断だけでは国の判定に限界がある」という指摘もあり、攻撃者はクラウドサーバーを世界中どこでも借りられるため、中国・ロシアだけブロックしても、米国や欧州経由のサーバーに切り替えられたら素通りしてしまう。
実務的には、国全体の丸ごとブロックより、正規ユーザーが使わないはずの管理画面・ログインページ・APIエンドポイントだけを国別制限や固定IP許可リストにする方が、ビジネスへの副作用が少なく効果的だ。IPAが推奨する基本対策も、管理画面を外に公開しないこと、不要なサービス・ポートを止めることが優先順位として高く（出典）、国別ブロックはその上に重ねる「追加の盾」くらいの位置づけが現実的と言える。
まぁ、そうだね。仮にWPなら、/wp-admin/を自分や会社のIPからしか繋げられないとかね。
まさにその発想だ。WordPressは「管理画面を晒しておくこと自体がリスク」の代表例なので、優先度の高い対策になる。
Apache環境なら、/wp-admin/に専用の.htaccessを置き、admin-ajax.phpだけを例外にしつつ、その他は許可IPのみアクセス可にする。ログイン自体はwp-login.php（ルート直下）で行われるため、こちらも別途、ルートの.htaccessで同様の制限が必要になる。Nginx環境なら、locationブロックで/wp-admin/とwp-login.phpにallow/denyを設定する形だ。
日本の現場でよく使われる補助策としては、管理ページのURL変更や画像認証付きログイン、IP制限がGUIで設定できる「SiteGuard WP Plugin」（JP-Secure製）、ブルートフォースやDDoS増幅の踏み台にされやすいxmlrpc.phpの無効化、.htaccessのIP制限が万一ミスっても壁になるBasic認証の二重掛け、といった多層防御がある。在宅勤務メンバーの固定IPでない問題は、VPN経由でアクセスさせ、VPNの出口IPだけ許可するのが現実解になる。これだけで、ARTEXのような自動スキャン型ツールが/wp-admin/にリクエストを送っても門前払いになるので、費用対効果はかなり高い。
被害企業に共通点はあるのか
今回、被害にあった企業のインフラやネットワーク環境を調査して、一列に並べて比較すると共通点が見えるかもね。
まさにその視点が、実際に進んでいる調査の核心だ。すでにいくつか「共通点」らしきものが見えてきている。
一番興味深いのは、攻撃者自身が、業種ごとにインフラを分けていたことだ。
GMOの調査では、攻撃元インフラの1つで日本企業約20社が標的となり、うち9社は同じ業種のWebサイトだったことが判明している。さらに見つかった6台の攻撃インフラも、デジタルギフト・小売流通 / 教育・ギフト・印刷 / ポイントギフト・マーケティング / 保険・金融 / EC・メディア・物流と、業種ごとにきれいに分かれていた（出典）。これは攻撃者側が「業種ごとに似たシステム構成・共通の脆弱性があるはず」という前提でリストを作っていた可能性を示唆している。
狙われた脆弱性の種類もすでに4つに整理されており、サーバーに内部向けの通信をさせるSSRF、外部からプログラムを動かせるRCE、データベースを不正操作するSQLインジェクション、番号を書き換えるだけで他人のデータが見えるIDOR（BOLA）だ。被害企業に共通する運用面の甘さも見えていて、ログ監視の不足、アクセス権限の設定不備、多要素認証の未導入、既知の脆弱性の放置が多くの事例の原因になっており、VPN機器のバージョンを正しく把握できていない企業は約半数にのぼるという調査結果もある（出典）。新しい脅威に負けたというより、昔からある基本的な穴が今回も突かれたケースが多い、ということになる。
同じ制作会社？これも可能性があるの？
十分あり得る仮説であり、むしろ2026年の日本ではこのパターンが急増していると報告されている。
Verizon DBIR 2025によると、サードパーティ（パートナー、ベンダー、サプライチェーン）経由の侵害は前年比2倍（15%→30%）に増加し、侵害の3分の1が信頼された取引先経由になっている（出典）。
実例として最もわかりやすいのが、2026年5月から6月にかけて良品計画や東芝、象印マホービンなど複数企業のWebサイトで、不審な認証画面が相次いで表示された件だ。原因は、各社が共通して使っていたJavaScriptライブラリ「polyfill.io」が、ソフトウェアサプライチェーン攻撃の温床になっていたにもかかわらず削除されていなかったことにあった（出典）。業種も規模も無関係の企業が、同じ外部コード（≒同じ制作会社が組み込んだ共通部品）を使っていたせいで横並びで被害に遭う、という構図だ。製造業でも、ITシステム保守を担う委託先ベンダーが先にランサムウェアに感染し、そこからクライアント企業が芋づる式に侵害されたケースが確認されている（出典）。
ARTEXの件に話を戻すと、今のところ「特定の制作会社・特定のCMSベンダーが共通していた」という具体的な指摘はまだ出ていないが、攻撃者が業種ごとにインフラを分けていたことを踏まえると、理屈としては非常に筋が通る。同業種は同じ業界特化型パッケージを同じシステム会社に発注しているケースが多く、中小の制作会社・SIerが複数クライアントのサーバーで同じ管理者アカウントを使い回している例も実務上珍しくない。自社サイトを作った制作会社が同業他社も手がけていないか、その制作会社の管理アカウント運用はどうなっているかは、中小企業ほど見落とされがちな、実益のあるチェックポイントだ。
まとめ：今すぐ着手すべきチェックリスト
ここまでの話を振り返ると、優先度は次の3段階で整理できる。
- 今すぐできて効果が大きいもの：管理画面のIP制限、MFA導入、APIキー・パスワードの管理、脆弱性診断ツールの本番環境分離
- 仕組み化が必要なもの：既知脆弱性へのパッチ運用、アクセス権限（IDOR/BOLA）の点検、ログ監視体制
- ガバナンス面：海外生成AIの利用ルール、委託先・制作会社のセキュリティ確認、国別IPブロックの検討
ARTEXのような自律型AI攻撃ツールの登場は、脅威の「速度」と「規模」を一段引き上げた。だが、突かれている穴の多くは、権限設計の甘さや認証情報の管理不足といった、昔からある基本的なものだ。AIに対抗するのもAIではなく、地道な運用の積み重ねになる。
具体的なチェック項目は、別途まとめたWEB担当者向け：AI型サイバー攻撃(ARTEX)対策チェックリストにある。
