はじめまして、株式会社MintSparkの堤です。当社では中小企業を中心に情報セキュリティの確保に向けてご支援をしております。
さて今回は、世間を賑わせている多くの日本企業が狙われている情報漏洩事故に関する記事になります。
みなさんはARTEXというワードをきいたことはありますか？
ARTEXとはAIが会社のシステムを調べ、弱点を探し、次の作業まで決める診断ツールになります。実はこれを悪用した攻撃が上記の情報漏洩事故でも使われているとの報告発表がありました。
そんなことをきくと「うちのホームページも狙われるのだろうか」と気になった方もいると思います。
私がこの話で気になるのは、攻撃に使われるAIの名前よりも、こちらが更新や確認を後回しにしている間にも、相手は作業を進めているという点です。ARTEXがどこから出てきたのかをたどりながら、自社の運用で確かめたいことをお話しします。
ARTEXとは？AIが計画し、ツールを動かす侵入テストの仕組み
ARTEXとは、冒頭お伝えしたとおり、AIを使って侵入テストの作業を進めるツール（システム）です。侵入テストとは、システムの弱点を調べ、どこまで影響が及ぶかを確かめる検査のこと。特定のウイルスや脆弱性の名前ではなく、AIと検査用のツールをつなぐ仕組み、と捉えると分かりやすいと思います。
中国で開発され、GitHubではAutumn-27という名前の開発者が公開していました。本人の2026年10月8日付の声明では、企業や組織が許可された範囲で安全性を検査することが、開発の目的だったと説明しています。
登場時期を調べると、公開版を保存したリポジトリの開発履歴に、2026年8月20日付のバージョン0.3.2が残っています。9月24日には0.3.14へ更新されており、少なくとも2026年夏には開発が進み、秋にかけて機能が追加されていたことが分かります。
その後、10月に金融機関への攻撃での利用が報告され、開発者は先ほどの声明で悪用を非難し、更新停止とクローズド化を発表しました。検査のために公開された仕組みが、攻撃する側にも使われたという経緯がなんとも悲しいですね。
このツールの中心は役割を分けたAIです。データインテリジェンス企業である韓国のS2Wによる分析では、利用者が目標と範囲を指定し、計画役のAIが作業を組み立て、実行役のAIがツールを動かす構成が説明されています。結果が返ると、計画役が次の作業を考えます。
チャットで攻撃方法を質問するだけの使い方から、AIがツールを動かし、結果を次の判断へつなぐ使い方へ進んでいる。防御する側にとっては、ここが押さえておきたい変化です。
韓国の金融機関を狙う活動で、何が見つかったのか
CrowdStrikeが10月7日に公開した調査は、9月下旬から10月上旬に活動した、韓国の金融機関を狙うキャンペーンを扱っています。同社は、攻撃者が管理する公開ディレクトリからARTEXの設定ファイルやAIツールのセッション履歴などを確認し、データの持ち出しがあったと報告しました。
この調査で見えているのは、AIツールと従来の攻撃手段を併用した活動です。被害組織数は報告の執筆時点で未確認で、侵入のすべてをARTEXだけが自動実行したと断定する内容でもありません。
一方、AhnLab ASECは10月14日の分析で、独立した検証環境にARTEXを入れて試した結果を公開しています。弱点のあるWebサーバーでプログラムを実行した例や、外部に公開したサービスを足がかりに、内部の複数ホストで処理を実行した例が示されています。（研究者が用意した環境下での実験）
実際の活動を追った調査と動作を確かめる実験の両面を踏まえて、
次のセクションでは自社で何を確認するべきかを一緒に考えましょう。
気になるのは、調べて試す作業をつなげられること
人が調べ、結果を読み、別の道具を選ぶというのは手間も時間もかかりますよね。
ARTEXのような仕組みでは、その作業をAIがつないでくれます。うまくいかなかった結果も、次に何を試すかを考える材料になります。
ただ、対象にある弱点や、使える権限、通信できる範囲によって結果は変わります。だからこそ、外から使えるサービスを必要最低限に制限することと、入られたとしてもその先で自由に動けない構成にすることに意味があります。
ログを見るときも、ツール名の文字列だけを探して終わりにはできません。ASECの検証では、通信に付くUser-Agentは使うツールによって異なりました。User-Agentはブラウザや通信ソフトが付与する情報で、実は変更もできてしまいます。そのためWebへのアクセス、ログイン、サーバーで動いた処理を合わせて追う必要があります。
11月2日追記：英語版の公開フォークと、AIの利用権を狙う動き
元の開発者が更新停止を表明した後も、公開コードを引き継ぐ動きが確認できます。11月2日に確認したBaaRai版のARTEXは、READMEでAutumn-27版から派生した英語訳のフォークと説明しています。操作画面、実行記録、AIの利用量をまとめる構成も紹介されています。
もう一つ注目したいのが、AIを使うための認証情報です。Wizが10月30日に公表した調査では、盗まれたAI関連のキーを確認していたインフラと、ARTEXのコンソールと題するページを公開していたインフラとの接点が示されています。同じIPアドレスで、10月8日にそのページが確認され、10月下旬には盗まれたキーの有効性を確かめる通信が観測されました。
MintSparkとして重視したいのは、システムへ入る入口と、その先で使われる認証情報・権限・請求先を一緒に点検することです。ここは、自社のAI機能でも確認しておきたいところですね。たとえば予約システムにAIの要約機能を付けているなら、キーの保存先、利用できる範囲、料金の通知先、無効化する担当を一組で確認します。制作会社や外部サービスにキーを登録している場合は、契約終了時の失効まで担当を決めます。AIの利用料が急増したときの確認先は、LLMjackingとAPIキー悪用への対応手順にまとめました。費用と権限を一緒に点検するときにご活用ください。
運営する側には、仕様や設定から調査対象を絞れる強みがありますね。どの機能がどのキーを使い、誰が管理しているかをたどると、点検する場所も絞りやすくなりますよ。利用権限、外部接続、費用の監視まで確認する。AIを使うシステムが増えるほど、こうした内部情報を生かしたホワイトボックスの点検が重要になります。
まず、外から使えるシステムを洗い出す
ホームページは制作会社、予約システムは別の業者、サーバーは社内で契約。
このように担当が分かれているときはまず「何を使っていて、誰が管理しているか」を一覧にまとめていくことが重要と考えています。
そのうえで、入口を適切に制限し、被害の広がりを抑え、異常に気づいた人が動けるようにします。S2Wが挙げる公開サービスの更新や通信制限も、この運用へ落として確認していきます。
| 確かめる場所 | 担当者に聞きたいこと | 手元に残したいもの |
|---|---|---|
| 公開サービス | ホームページ、API、管理画面、保守用の接続先に、使わなくなったものが残っていないか。 | サービス一覧と管理担当 |
| 更新とアカウント | 重要な修正版を誰が適用するか。管理者の多要素認証と、退職者のアカウントを確認しているか。 | 更新記録とアカウント一覧 |
| 社内へ届く範囲 | 公開サーバーから社内や他のシステムへ、どこまで通信・操作できるか。 | 構成図、通信と権限の設定 |
| 記録と通知 | アクセス、ログイン、サーバーの処理を何日分調べられるか。異常の通知は誰が見るか。 | ログの保存期間と確認担当 |
| 停止と復旧 | 誰が停止を判断し、どのバックアップからどう戻すか。 | 緊急連絡先と復元手順 |
多要素認証を有効にしていても、アプリのアクセス権が広すぎたり、別の機能に脆弱性が残っていたりすれば、その部分は確認が必要です。対策を一つ入れたことで安心せず、実際の設定と仕事の流れまで見ておきたいですね。
自社なら、仕様と設定を手がかりに調べられる
攻撃者が外から手がかりを集める一方で、運営する側には、使っている製品、設定、プログラム、契約を確認できる立場があります。私は、この情報を使えることが防御側の大きな強みだと考えています。
内部の仕様やプログラムを把握して調べる方法を、ホワイトボックス型の検証と呼びます。たとえば、予約フォームから届いた情報を「誰が見られる設計か」が分かれば、まずその権限判定へ対象を絞れます。自社で作った機能も、制作会社に頼んだ機能も、必要な資料と協力を得て確認する考え方です。 確認表を用意する際は、会員A・会員B・管理者で権限を点検する具体例も参考にしてください。自社の仕様を、利用者ごとの期待する動きへ落とし込む方法を紹介しています。
| 確かめたいこと | 外から得られる手がかり | 内部情報を使って確かめること |
|---|---|---|
| 更新の必要性 | 公開画面や応答に出る製品情報 | 実際の製品・バージョン、使っている機能と設定、修正版の適用記録 |
| 情報の閲覧・変更 | 利用者が操作できる画面や機能 | どの役割に何を許可する仕様か、サーバー側の権限判定、別の利用者の情報を分離する処理 |
| 異常の確認と復旧 | 表に見えている現象 | アクセス・操作記録、通知先、バックアップの対象と復元手順 |
外からの点検と内部の確認を組み合わせると、「使っているか分からない製品を広く探す」作業から、「この機能の、この条件を調べる」作業へ進めます。公開情報の診断結果に、社内の設定・運用の確認を重ねることが重要です。
まず一つの機能で、担当と確認記録を決める
以下は、会員向けの資料ダウンロード機能を点検する場合の設計例です。
- 運営責任者：「契約中の会員だけが自分の資料を閲覧できる」という仕様と、確認する機能を決める。
- 開発・保守担当：対象の版と権限処理を確認し、隔離した検証環境で、架空の会員A・Bとダミー資料を使って結果を確かめる。
- 確認記録：対象の版、仕様、試した条件、期待する結果、実際の結果、修正後の再確認を残す。
検証環境には架空のデータと専用の認証情報を用意し、メール送信や外部サービスとの接続先も検証用にそろえます。本番とは別の環境で、仕様と実際の動作を照らし合わせる計画です。
初回の相談では、こうした確認対象と、社内・制作会社の担当範囲から整理できます。具体的な調査や検証は、対象と費用を決めて進めます。
制作会社には、更新と記録の担当まで聞いておく
「AI攻撃に対応していますか」と聞くと、返事も大きな話になりがちです。今の契約で何を任せられるかを知るには、実際の作業について聞く方が役に立ちます。
- 重要な脆弱性が出たとき、当社への影響を確認し、更新を判断するのは誰ですか。
- 不審なアクセスがあったとき、どの記録を、どこまで遡って調べられますか。
- 営業時間外に問題が出たら、誰へ連絡し、誰が停止や調査を行いますか。
回答と一緒に、作業報告や設定、連絡先を確認します。契約に含まれる対応と、別途費用がかかる対応の境目も、平時に合わせておく方が慌てずに済みます。更新の聞き方は、制作会社に任せたWordPressの更新確認でも詳しく説明していますの是非ご参照ください。
不審な動作を見つけたら、調査できる状態を残す
知らない管理者が増えた、見覚えのないファイルが置かれている、普段と違うログインが続いている。すでにそんな現象がある場合は、予防点検を続けるより先に、社内の責任者と保守担当へ連絡してください。
発見時刻、対象のサービス、見つけた現象を控えます。自己判断でファイルを消したり、サーバーを初期化したりすると、経緯を調べる手がかりも失われますの控えることをお勧めします。通信の制限や機器の隔離は、業務への影響と記録の保全を踏まえて対応担当と判断します。
調査のためであっても、顧客情報や認証情報が入ったログを、そのまま一般の生成AIツールへ貼り付けるのは避けてください。誰に何を渡すかまで含めて対応を決めます。初動の手順を整える際は、IPAの中小企業向けガイドラインにあるインシデント対応の手引きも参考になります。
更新や確認を続けられる担当がいるか
AIを使う攻撃が話題になると、新しい対策製品を探したくなるかもしれません。ただ、使っているシステムも更新の担当も分からない状態では、製品を追加しても確認の抜けは残ります。私たちはまず、何を守り、誰が更新し、異常が出たら誰が動くかを確かめることが先決と考えています。
自社でAIへメールや社内資料をつなぐ場合には、そのAIが読める情報や実行できる操作も決めます。こちらはAIエージェントのセキュリティ対策で説明しています。
そうは言っても制作会社へ何を聞けばよいか、今の体制でどこまで守れているか。なんて整理できてない・・・
安心してください。当社では整理がついていない段階からご相談をお受けしております。MintSparkの初回30分のオンライン相談では、現在の使い方と担当体制を伺い、確認する対象と優先順位を一緒に考えます。詳細な調査や設定変更、改修は、作業範囲を確認して別途お見積もりします。是非お気軽にお問い合わせください。
資料の確認日：2026年10月20日。開発経緯は開発者の声明と保存された開発履歴、攻撃活動と検証結果は本文中にリンクした各社の一次報告を参照しています。