Google Threat Intelligence Group（GTIG）と Mandiant は2026年10月30日、ARTEX をはじめとする AI エージェント型の侵入テスト用フレームワークが、複数の攻撃者によって実際の侵入に使われていると報告しました。標的には米国の製造業や化学・素材の企業も含まれています。この記事では、報告の事実を整理したうえで、AI エージェントによる攻撃に対して、業務アプリケーションを作る側は何を設計に入れるべきかを、システム開発会社の代表として論じます。
要点（事実のみ）
- GTIG によると、2026年8月下旬以降、ARTEX、PentAGI、Hexstrike、CAIRN などのオープンソースのマルチエージェント型侵入テスト基盤が、金銭目的の恐喝グループから中国関連とみられるクラスタまで、動機の異なる複数の攻撃者に使われている。ARTEX は Go で書かれ、6つの専門サブエージェントが攻撃の工程を分担する。元のリポジトリは悪用の広がりを理由に2026年10月に作者が削除したが、フォークや商用版を通じて拡散が続いている。
- GTIG/Mandiant のインシデント対応では、米国の政府、テクノロジー、化学・素材、製造業の組織に影響が出た。別に Wiz が追跡した攻撃者（GTIG の呼称 UNC7228）は、米国・欧州のエンタープライズソフトウェア、産業オートメーション、半導体の製造・設計、通信の各業種を狙っていた。
- 攻撃者は最初に侵害したアカウントから深いシステムアクセスまで、通常は約4時間、1件では15分で到達した。ARTEX の個々の実行は約2〜25秒の短いバーストで進んだ。
- 侵入後には、アプリケーションの通知機能を使って1,300人を超える社内ユーザーにテストメールを一斉送信させ、信頼された通知経路を社内への大量送信手段に変えた例もあった。
- GTIG は、こうしたツールは現状「隠密性より速度を優先している」ため痕跡が残りやすい一方、「検知と阻止・対応は別の機能」であり、時間内に検知するだけでは目的達成をほとんど妨げられないと指摘した。防御策は、管理プレーンの保護、ID と鍵の制限、構成の強化、アプリケーション開発の強化、振る舞いと量の変化の検知、の5層で示されている。
徐 聖博の見解
防御の5層のうち2つは、アプリを作る側の仕事になっている
今回の報告で私が一番注目したのは、推奨された5つの層のうち、少なくとも2つが情報システム部門ではなく、アプリケーションを作る側に向けた内容になっている点です。
1つは「外部ユーザーへのエラー情報を制限する」こと。スタックトレース、SQL エラー、内部パス、フレームワークの詳細を、未認証のユーザーに返さない。もう1つは「影響の大きい業務 API にガードレールを置く」こと。機密データの取得、メールや通知の送信、ユーザー作成、権限変更ができる機能には、レート制限、送信先数の上限、取引額のしきい値などを機能に応じて設ける、とあります。
どちらも新しい論点ではありません。ただ、相手が AI エージェントになると重みが変わります。人間の攻撃者なら、詳しいエラーメッセージを読んで次の手を考えるのに時間がかかります。エージェントはエラーを受け取った数秒後には修正版を投げてきます。報告でも、Web シェルの作成でエラーを手がかりにファイル名や中身を変えながら再試行していた様子が記録されています。詳しすぎるエラーは、攻撃側のエージェントにとって最良のデバッグ情報になるというのが、私の受け止め方です。
「正規の機能」がそのまま武器になる
通知機能から1,300人超へ一斉送信させた例は、開発会社として特に重く見ています。脆弱性を突いたのではなく、アプリが持っていた正規の機能を、正規の権限の範囲で大量に使われたからです。
業務システムの要件定義では、「管理者は全社員に通知を送れる」「担当者は CSV で一括登録できる」といった機能は、便利さの側からしか議論されないことがほとんどです。1回に何件まで送れるか、1時間に何回まで実行できるか、いつもと違う量が出たら誰に知らせるか、は仕様に書かれません。書かれていなければ、作る側も実装しません。
私は、テスト・セキュリティ・認証認可・本番環境の安定稼働は開発スピードと引き換えにしないと決めています。その延長として、一括送信・一括登録・権限変更・データの一括出力の4種類には、件数と頻度の上限を「非機能要件」として最初から書くことを、自社の設計の標準にすべきだと考えています。上限は後から緩められますが、上限が無い状態で本番に出た機能に、後から上限を足すのは利用部門との調整が大きくなります。
「検知したのに止められない」をどう設計で埋めるか
GTIG の「検知と対応は別の機能」という指摘も、作る側の目線で読むと具体的です。侵入から深いアクセスまで15分の例があるなら、アラートを人が見て判断する前に事が終わり得ます。
ここで作る側にできるのは、アプリ自身が止まれるようにしておくことです。普段の何倍もの量の操作が短時間に続いたら、その機能だけを自動で一時停止し、解除は人が判断する。監視ツールの導入とは別に、アプリの中に「自分を止める仕組み」を持たせておくという考え方です。報告が示す「認証元の変化 → 権限の探索 → ストレージの列挙 → 外部への接続」のような一連の流れを相関させる検知は監視基盤の役割ですが、最後の一手を遅らせるのはアプリ側の上限と自動停止です。
開発を生業にする会社の事業判断にどう効くか
この報告は、SIer や開発会社にとって見積もりと契約の問題でもあると私は考えています。
1つ目は、上限と自動停止を「標準仕様」として見積もりに含めるかどうかです。オプション扱いにすると、価格競争の中で真っ先に削られます。削った結果、納品したシステムの通知機能が社内への大量送信に使われたとき、発注側は「なぜ付けなかったのか」と問うはずです。私は、標準に含めて理由を説明できる会社のほうが、長期的には選ばれると見ています。
2つ目は、エラー表示の方針を設計書に残すことです。開発中は詳しいエラーを出したほうが速く直せるので、本番でもそのまま残りがちです。どの画面・どの API で何を返し、詳細はどのログに残すのかを決めておけば、レビューで確認できる項目になります。
3つ目は、AI エージェントを自社で作る側としての論点です。ARTEX は防御側の検証にも使われる侵入テスト用ツールで、構成としては業務を代行するエージェントとよく似ています。高レベルの目標を受け取り、サブエージェントに分け、エラーを見て自分で直す。私たちが顧客向けに業務自動化エージェントを作るときも、そのエージェントが「普段の何倍もの量を数秒で実行できる主体」であることは同じです。攻撃側のエージェントに備える上限設計は、自社のエージェントが暴走したときの安全装置にもなるので、作る側としては一度に両方を設計するのが合理的だと考えています。
まとめ
AI エージェントによる侵入は、侵入テスト用に公開されたツールを使い、数秒単位の速度で正規の機能まで使い切る形で進んでいます。製造業や化学・素材の企業が標的に含まれていることからも、特定の業種だけの話ではありません。情報システム部門の監視強化と並んで、業務アプリを作る側が、エラーの返し方と影響の大きい機能の上限・自動停止を最初から設計に入れることが、今回の報告から読み取るべき実務上の結論だと私は考えています。
委託先に渡したアプリ権限から侵入された事例は ConnectWise侵害に学ぶサプライチェーン攻撃対策——委託先に渡したアプリ権限は「連携を止めても残る」 で、製造業が侵入後に何を監視すべきかは APT28（Swallowtail）の造船・航空エンジンメーカー攻撃に学ぶ、製造業の標的型攻撃対策は「侵入後」の検知にある で整理しています。AI が攻撃のどの工程に使われているかの全体像は AIがサイバー攻撃をどう変えたか——Anthropicの1年間分析から読む「AIエージェント脅威」の本質 も参考になります。
