日本企業を狙った不正アクセスで、AIツール「ARTEX」の使用が確認されました。
GMOサイバーセキュリティ byイエラエが2026年10月19日に公表した調査は、AIを使った攻撃という推定を、攻撃元の基盤調査で裏付けたものです。
ただ、標的になった企業と情報漏えいが確認された企業は同じ意味ではありません。
中国で開発されたツールが使われたことから、開発者や中国政府が攻撃を指示したとも結論づけられません。
ニュースを理解するには、被害の範囲、調査で得られた証拠、まだ分からない点を切り分ける必要があります。
本記事では日本の発覚経緯を軸に、韓国の先行事案、開発者の対応、国内の関連調査をつなぎ、企業と利用者が何を確認すべきかを解説します。
ARTEXは、中国で開発されたAIエージェント型のペネトレーションテスト用ツールです。
ペネトレーションテストとは、所有者の許可を得てシステムへの侵入可能性を確かめ、防御の不備を見つける検証を指します。
CrowdStrikeは、韓国の金融機関を狙った攻撃で、オープンソースとして公開されたARTEXとLLMが併用されたと報告しました。
ARTEXそのものが、ChatGPTのような独立した大規模言語モデルなのではありません。
外部のLLMと接続し、検査の判断や作業の実行を組み合わせる仕組みです。
文章による助言を受けるだけでなく、ツールを使った作業へ進める点が、一般的なチャット利用との違いになります。
こうした自動化は、限られた担当者で検査の範囲を広げたい組織に役立ちます。
同時に、許可のない第三者のシステムへ向ければ、その能力が攻撃の効率化に転用されます。
今回確認されたのは、その悪用です。
Reutersの10月9日付報道によると、開発者「Autumn-27」は10月8日、悪用を受けて更新を停止し、非公開へ移行すると表明しました。
今後のバージョンの一般公開と保守も行わないとし、本来の目的は企業や組織のセキュリティ検証だったと説明しています。
この説明は開発者側の見解であり、攻撃の捜査結果ではありません。
ただし、ツールを作った人物と、それを使って不正アクセスした人物は分けて扱う必要があります。
また、公開停止によって、すでに取得されたコードや複製まで一斉に消えるわけではありません。
防御側はプロジェクトの公開状況だけで安全性を判断できません。
GMOの発表を追うと、日本での確認は二段階に分かれます。
10月15日の記事では、複数事案の傾向とフォレンジックログの分析などから、AIが使われたとの判断を示しました。
フォレンジックは、コンピューターに残った記録などを調べ、侵害の経緯を解明する調査です。
その後、10月19日の続報で、攻撃元インフラを調査した結果、ARTEXの使用を確認したと公表しました。
ただし、どのファイルや設定を決定的な証拠にしたかという詳細は、同ブログでは開示されていません。
発覚の流れを時系列で見ると、韓国の先行調査、開発者の対応、日本の確認が続いています。
これは発生日と発表日を含む表です。
10月19日に利用が確認されたからといって、その日に攻撃が始まったという意味ではありません。
GMOが最初に調べた一つの攻撃基盤では、観測できる範囲でほぼ日本だけが狙われ、約20社のうち9社が同業種でした。
調査を広げると、国内企業を中心に狙うAIを使った攻撃基盤がさらに6台見つかっています。
約80社という数字はTBSの10月20日付報道によるもので、公開ブログの約20社と同じ集計範囲とは扱えません。
また、GMOは漏えい公表企業との重なりを踏まえ、同一の攻撃グループによる複数の被害と説明し、情報を法執行機関へ共有しています。
企業名の一覧や個別の因果関係は公開されておらず、最近漏えいを公表した企業を独自に当てはめることは避けるべきです。
韓国の事案では、攻撃者が管理するサーバーのディレクトリが外部から閲覧できる状態になっていました。
CrowdStrikeはそこからClaude Codeのセッション履歴、ARTEXの設定、AIの記憶ファイルを発見し、攻撃の進め方を分析しています。
同報告では、韓国のARTEX環境の主なLLMはDeepSeek v4.1-flashで、別のClaude CodeセッションではGLM-5.3やGrok 4.6も使われていました。
Claude Codeという実行環境の名称と、接続先のAIモデルは同じではありません。国内事案の具体的なモデルはGMOのブログには記載されていません。
被害側の通信記録だけでは、背後で人間が操作したのか、AIが判断したのかを確実に見分けられない場合があります。
攻撃者側の作業記録は、実際に何を指示し、どのツールを使っていたかを補う証拠になります。
ただし、日本のARTEX確認も同じ公開設定の不備によるものだったとは発表されていません。
韓国の調査で見つかった会話には、漏えいした韓国の情報はどこで売買されるのかをClaudeに質問し、Telegram上の販売グループを探す支援を求めた記録もありました。
侵入を助ける作業に加え、その先の収益化にもAIを使おうとしていたことが読み取れます。実際の売却成立は同報告から確認できません。
同社は、中国語の指示などを根拠に、中国語話者による金銭目的の攻撃である可能性を中程度の確信度で評価しました。
一方、特定の既知の攻撃組織への帰属は示していません。会話に人物情報も含まれていたものの、攻撃者本人との確実な関連づけはできないと明記しています。
したがって「中国人の特定人物が日韓を攻撃した」「中国政府が関与した」といった断定は、公開された証拠の範囲を超えます。
日韓で同じツールが見つかったことは関連を調べる手掛かりですが、それだけで同一犯とは決まりません。
JPCERT/CCは10月15日、国内で相次ぐ漏えいに関連して攻撃元を調査し、AIを使った既知の脆弱性の探索やAPI経由の攻撃を確認したと公表しました。
Androidアプリの配布ファイルを解析し、その接続先に弱点がないか調べた痕跡も報告されています.
APIは、アプリがサーバーへデータの取得や更新を依頼する窓口です。
利用者の画面には表示されなくても、アプリとサーバーの通信には使われます。
画面上のボタンを隠すだけでは、サーバー側のアクセス権限の確認不足を補えません。
NICTの共同分析チームLETTICEも、公開アプリの解析結果からバックエンドサーバーを狙う「A2B攻撃」を注意喚起しました。
アプリ自体に弱点がなくても、接続先の認証・認可や入力内容の検証に不備があれば、漏えいにつながるおそれがあると説明しています。
ここでの認証は「誰かを確かめること」、認可は「その情報や操作を許してよいか確かめること」です。
概念としては「公開アプリの構造を調べる→接続先と通信仕様を把握する→サーバー側の不備を検証する」という流れです。
AIによる解析の効率化は、これまで人手の制約で調べきれなかった対象にも検査・攻撃が及ぶ可能性を高めます。
ただし、JPCERT/CCとNICTの報告が、すべてARTEXによる攻撃を説明しているわけではありません。
GMOは関連事案の傾向分析で、脆弱性情報に記載されたバージョンだけを確認する運用や、防御機器への過信に注意を促しています。
既知の弱点と似た不備が別の版に残っていたり、サポート終了製品で情報が十分に更新されなかったりするためです。
通信元を多数切り替える攻撃も観測されています。
ここから導けるのは、防御の仕組みを一つ導入するだけでは確認漏れを埋めきれないということです。
更新、資産の把握、アプリとAPIの設計、アクセス監視を組み合わせる必要があります。
AIで攻撃を自動化できても、どんなシステムにも侵入できるわけではありません。成功には悪用できる弱点や設定不備などの条件が関係します。
なお、公開資料では国内事案の完全自動化率、攻撃一件の費用、熟練者との成功率比較は示されていません。
「誰でも無料で確実に侵入できる」と結論づける根拠はありません。
企業側は、自社が保有するWebサイトの一覧だけで点検範囲を決めないことが出発点です。
JPCERT/CCは、一般利用者向けアプリに加え、BIツールや従業員向け管理システムでも漏えいが起きていると注意喚起しています。
たとえばスマートフォンアプリを更新していても、古い版が接続するAPIや、委託先が運用するサーバーが残っていれば、点検が追いつかない可能性があります。
以下は公表された注意喚起を踏まえた、確認の優先順位です。
NICTも公開APIやサーバーの洗い出し、ログ確認、認可不備などの点検を推奨しています。
チェック項目を消化するだけでなく、「誰が、どのデータへ、どの条件でアクセスできるか」を実際の通信経路に沿って確かめることが必要です。
診断を行う場合は、所有者の許可と対象範囲を明確にし、稼働中サービスへの影響も管理します。
一般利用者が企業サーバーを点検することはできません。
まず、利用サービスの公式アプリやブックマークから告知を開き、対象者、漏えいした情報、事業者が求める対応を確認してください。
通知に便乗した偽メールも考えられるため、届いたリンクだけを頼りに操作しないようにします。
パスワードが対象なら、そのサービスと使い回した先を変更し、ログイン履歴や多要素認証も確認します。
カード情報や本人確認書類などが含まれる場合は、発行元・事業者の案内に従って個別に相談する必要があります。
氏名や連絡先だけの漏えいでも、本人らしく見せた電話やメールに警戒する理由になります。
具体的な対応は、AI TOP TIERの個人情報漏えい対処ガイドで、状況と情報の種類に応じて確認できます。
メールアドレスの既知の流出を調べる方法は、Have I Been Pwnedの解説も参考になります。
ただし、検索結果に出ないことは、今回の被害に遭っていない証明にはなりません。
ARTEXの事件を受けて企業が優先すべきなのは、自社のどのシステムが外部とつながり、そこから何の情報を取得できるかを確かめることです。
一般利用者は、利用サービスの公表内容を確認し、実際に漏えいした情報に合わせて対処してください。
今後の続報では、標的数の増減だけでなく、侵入が成立した経路、各社の被害との関連、日韓の攻撃者の共通性がどこまで裏付けられるかが判断材料になります。
確認済みの範囲を押さえつつ、未確定の人物像より先に、見直せる接続先や設定へ目を向けたいところです。
.png){kind=logo}
