日本企業を狙うAI攻撃ツール「ARTEX」の報告、どこまで分かっている？事実・推察・記載なしを表に分けて、取引先への確認メモを作ってみよう
AI実用ラボ
1. この記事で作るもの：3列の確認表と、取引先への質問メモ
「AIを使った攻撃ツール『ARTEX』で日本企業が狙われている」というニュースを見て、取引先から「うちは大丈夫でしょうか」と聞かれ、返事に困ったことはないでしょうか。
ニュースの文面には、確認された事実と、書いた人の推測と、どこにも書かれていないことが混ざっています。
この区別がつかないまま答えると、推測を事実のように伝えてしまい、あとで困ることになります。
そこでこの記事では、混ざった状態をほどく道具を2つ作ります。
1つは、報告の記述を「確認された事実／筆者の推察／記載なし」の3列に仕分ける表。
もう1つは、空欄になった「記載なし」を、取引先や社内のIT担当への質問メモに変えたものです。
不正アクセスの報告を読むとき、この2つがあると「何が分かっていて、何を聞けばよいか」を人に説明できます。
まず完成形を見てください。
以下は架空の例です。
佐藤さんはサンプル商会（これも架空の会社です）の事務担当で、GMOサイバーセキュリティ byイエラエが2026年10月19日に公開し、10月21日に更新した報告を読んで、次の3行に仕分けました。
| 報告に出てくる文 | 区分 | そう判断した理由 |
| 日本企業約20社が標的 | 確認された事実 | 報告に数として書かれている |
| 同じ手口で日本企業も攻撃されていると推察される | 筆者の推察 | 「推察される」と書かれている |
| 組織向けの対策 | 記載なし | 報告の中に見つからなかった |
3行だけでは物足りなく感じるかもしれませんが、この3行があれば、取引先に「分かっているのはここまでで、残りは確認中です」と説明できます。
準備するものは、報告を開くブラウザと、メモ帳か表計算ソフトだけです。
契約も申し込みも、社内システムの設定変更も要りません。
費用もかかりません。
作業は、報告の文を読みながら表に写し、区分を付けていくところまでです。
なお、この記事は自社や取引先に被害があるかどうかの判断と、防御の設定方法を扱うものではありません。
報告にも、被害企業の名前や漏えいした情報の中身は書かれていません。
扱うのは、書かれていることを読み分け、分からないことを質問として整理するところまでです。
次の章から、実際に何が書かれていたかを見ていきます。
ニュースを見ても、どこまでが本当なのか分かりません。
全部を判断する必要はありません。書かれていることを3つに分けるだけで、人に説明できる形になります。
2. 報告で書かれていたこと：確認された事実・推察・記載のないこと
最初に、確認した文書を挙げます。
GMOサイバーセキュリティ byイエラエの「相次ぐ不正アクセスの攻撃元の多くがAIであることを確認」（2026年10月19日公開、10月21日更新）、同じく「相次ぐ不正アクセスに備える３つのポイント」（2026年10月15日付）、そしてCrowdStrikeの「Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance」（2026年10月7日公開）です。
原文は次の3つのページで読めます。
10月19日付の報告に書かれているのは、次のことです。
ARTEXはAIによる自律型ペネトレーションテストシステムで、日本企業を狙った侵害事案の攻撃元インフラの調査で使用が確認されました（ペネトレーションテストは、許された範囲で弱点を確かめる検査のことです）。
前回の記事ではログからAIによる攻撃の可能性が高いと推定しており、今回の結果はそれを裏付けるものだと書かれています。
筆者らは、2026年9月下旬から韓国の金融機関を狙った攻撃キャンペーンがあり、CrowdStrikeがそこでのARTEXの使用を報じているとしたうえで、同じ手口で日本企業も攻撃されていると「推察される」としています。
報告は、観測できた範囲は筆者らが観測できる範囲に限られると断ったうえで、調べた攻撃元インフラはほぼ日本だけを標的にしていたと書いています。
最初に調べたインフラの標的は日本企業約20社で、うち9社は同業種のサイトでした。
標的と確認できた企業のうち8社が、2026年9月から10月に情報漏えいのリリースを出しています。
日本と韓国以外の国が狙われているかは調査中で、情報は法執行機関に共有したと書かれています。
ここで注意したいのは、どこまでが確認された事実で、どこからが書いた人の解釈かです。
「日本企業約20社が標的」「8社が漏えいを公表」は報告に書かれた内容です。
一方、「同じ手口で日本企業も攻撃されていると推察される」「同一の攻撃グループによる犯行で複数の被害が出ている表れ」は、筆者の推察・解釈として書かれています。
数字が並んでいても、観測範囲が限られていることは報告自身が断っています。
10月15日付の記事は、特定の事案ではなく、多くの相談事案の傾向分析から得たポイントだと明記されています。
ARTEXという語は出てきません。
内容は3点で、CVEに記載のないバージョンも影響を受ける「シャドー脆弱性」があること、外部からの検査ではバージョン番号が判別できないことがあり攻撃者はそれを気にせず攻撃コードを打ち込めること、一連の攻撃ではWAFをバイパスする手法が複数使われたことです。
WAFは通信を見て攻撃を遮断する仕組みですが、閾値ぎりぎりでIPアドレスを切り替えながら攻撃を続け、合計で数百のIPアドレスを使った例が挙げられ、「WAFを導入しているからパッチ適用は必要ない（または優先度を下げてもよい）と考えている方は要注意です」と書かれています。
攻撃にAIが使われたことは「ほぼ間違いない」とする筆者の判断も示されています。
ただし、その根拠になるログや件数はこのページには示されていません。
CrowdStrikeの報告は、韓国の金融機関を狙った標的型キャンペーンの件を扱ったもので、ARTEXは最近公開されたオープンソースのエージェント型ペンテストツールと説明され、攻撃者はLLMと併用したとされています。
韓国での侵害の経緯は報道ベースの伝聞として書かれ、影響を受けた組織の数は執筆時点で未確認とされています。
なお、10月19日付の報告には10月21日付の追記があり、オープンソースソフトウェアの開発者が中国のエンジニアであることと、そのソフトウェアを使って誰が攻撃しているかは一切関連がない、と書かれています。
ツールの開発者と攻撃者を結びつけて考えない、という趣旨です。
一方で、これらの文書に見つからなかった項目があります。
組織向けの具体的な対策、検知方法、侵入経路、悪用された脆弱性、標的企業・被害企業名、攻撃グループの帰属、漏えいした情報の内容や件数、AIが使われたとする判定の具体的な根拠です。
10月19日付の報告と10月15日付の記事、CrowdStrikeの報告が互いにどう関係するかも、どのページにも書かれていません。
10月19日付の報告がARTEXをオープンソースと明記しているかどうかも、読み取れませんでした。
ここは分けて考えてください。
「記載がない」ことは「存在しない」「起きていない」ことと同じではありません。
公表する必要がない、調べている途中である、あえて出していない、といった理由で載っていない場合があります。
だからこそ、記載がない項目は、被害の有無を推測で埋めずに、次章以降で確認の質問へ変えていきます。
「記載がない」なら、何も起きていないということですか？
いいえ。記載がないことは、起きていないという意味ではありません。分からないことは分からないまま、次の質問に回します。
3. 手順①：報告の文を『事実』『推察』『記載なし』の3列に仕分ける
用意するものは、報告を開くブラウザと、メモ帳か表計算ソフトだけです。
契約も設定変更も費用もかかりません。
スマートフォンのメモでも構いません。
まず表の形を決めます。
いちばん左に「知りたい項目」を置き、その右に仕分け用の3つの列を並べます。
- 知りたい項目(左端)
- 確認された事実(原文の短い引用)
- 筆者の推察・解釈
- 記載なし
右の3つの列が「3列に仕分ける」の3列です。
同じ行に事実と推察の両方を書かないのがコツです。
行ごとに、出典の記事名と日付を添えます。
たとえば「GMOサイバーセキュリティ byイエラエ「相次ぐ不正アクセスの攻撃元の多くがAIであることを確認」(2026年10月19日公開、10月21日更新)」のように、記事名と日付をセットで書いておくと、あとで読み返したときに迷いません。
URLは必須ではありませんが、同じページをすぐ開き直せるよう、書ける場合は添えておくと便利です。
仕分けの目安は文単位です。
数字や固有名詞を含む文――「日本企業約20社」「8社」など――は、まず「確認された事実」の候補に置きます。
逆に「推察される」「とみている」「ほぼ間違いない」「考察」といった語を含む文は、「筆者の推察・解釈」の列へ移します。
1つの段落に両方が混ざっていることも多いので、段落ごとではなく文ごとに切り分けてください。
どちらか迷った文は、いったん推察・解釈の列に置き、原文の言葉を短く引用として残しておくと、あとから判断し直せます。
「確認された事実」の列には、観測範囲の限定も書き添えます。
この報告では、調べた範囲は筆者らが観測できる範囲に限られるとされています。
日本企業約20社という数字も、その観測範囲で確認できた数です。
「日本全体で20社が狙われた」と読み替えないよう、行の隣に「筆者らの観測範囲での確認」と一言添えておきます。
次に、知りたい項目ごとに報告を探します。
何社か、どの業種か、どんな手口か、対策、被害企業名、漏えい内容、他国の状況――この並びで1行ずつ作り、報告の中を探します。
見つからなかったときは空欄にせず、必ず「報告に記載なし」と書いてください。
空欄のままにすると、あとで「探し忘れたのか」「書かれていないのか」の区別がつかなくなります。
ここで大事な前提を1つ。
記載がないことは「ない」「安全」「問題なし」を意味しません。
報告に書かれていないだけで、被害がなかった証拠でも、対策が不要という意味でもありません。
この行はそのまま次の章の質問メモの材料になります。
4. 手順②：『記載なし』を、取引先やIT担当への質問メモにする
前の章で「報告に記載なし」と書いた行が、そのまま質問メモのたねになります。
この報告には、組織向けの具体的な対策、検知方法、侵入経路、悪用された脆弱性、被害企業名、漏えいした情報の内容といった記載が見つかりません。
分からないことを推測で埋めるのではなく、関係先に聞く形に変えていきます。
質問メモの根拠は2つです。
1つは「報告に記載なし」とした項目。
もう1つは、GMOサイバーセキュリティ byイエラエの「相次ぐ不正アクセスに備える３つのポイント」(2026年10月15日)に示された筆者の見解です。
この記事は特定の事案ではなく傾向分析から得たポイントで、第2章で挙げたとおり、WAFをバイパスする手法が複数使われたことと、「WAFを導入しているからパッチ適用は必要ない(または優先度を下げてもよい)と考えている方は要注意です」という見解が書かれています。
だから質問は「WAFは入っていますか」で終わらせず、更新の運用まで聞きます。
聞く相手は、顧客情報や取引データを預けている取引先、システム会社、社内のIT担当です。
質問の例は次の5つです。
- 当社から預けている情報にはどのような種類があり、どこに保管されていますか。
- ソフトウェアの更新(パッチ適用)は、どのような方針で、どのくらいの頻度で行っていますか。
- WAFなどの防御策に加えて、更新も行っていますか。
- 異常があったときは、誰が、どの順番で、どこへ連絡する決まりになっていますか。連絡先も教えてください。
- 今回のような報告で当社に関係する情報が出た場合、どのように知らせてもらえますか。
文面は、答えを求めるものにし、相手を責める言い方にしないでください。
「被害に遭っていませんか」と問い詰めるのではなく、「当社として理解しておきたいので教えてください」という形が向いています。
メモには記録欄を用意します。
質問ごとに「回答」「回答日」「次に確認する時期」の欄を作り、口頭で聞いた場合もその日のうちに日付と相手の名前を書いておきます。
最後に2点。
質問に答えがなくても、それだけで被害があるとは限りません。
逆に答えがあっても、それが安全の保証になるわけでもありません。
このメモは、分からないことを分からないままにしないための道具として使ってください。
なお、具体的なコマンド、設定方法、検知ルールはここでは扱いません。
5. 具体例：佐藤さんの3列表と質問メモ
ここからは、会社名も人物もすべて架空の例です。
実在する企業や取引先は出てきません。
サンプル商会（従業員15人ほどの架空の会社）の事務担当・佐藤さんは、自社の顧客リストを取引先のクラウドサービスに預けています。
AIを使った攻撃のニュースを読み、「うちの顧客リストは大丈夫なのか」と気になりましたが、報告を読んでも自社に関係があるのか判断できません。
そこで、報告の文を3つの列に仕分ける表を作りました。
| 区分 | 報告に書かれていた文・項目 | 出典（記事名・日付） |
| 確認された事実 | 「標的は日本企業約20社」。調べた攻撃元インフラはほぼ日本のみが標的で、観測範囲は筆者らが観測できる範囲に限られる | GMO「相次ぐ不正アクセスの攻撃元の多くがAIであることを確認」2026年10月19日公開・10月21日更新 |
| 確認された事実 | 標的と確認できた日本企業のうち、2026年9〜10月に情報漏えいのリリースを出した企業は8社 | 同上 |
| 筆者の推察・判断 | 同じ手口で日本企業も攻撃されていると「推察される」 | 同上 |
| 筆者の推察・判断 | 攻撃にAIが使われたことは「ほぼ間違いない」。ログや件数などの根拠は示されていない | GMO「相次ぐ不正アクセスに備える３つのポイント」2026年10月15日 |
| 記載なし | 組織向けの具体的な対策 | 10月19日付の報告に見つからなかった |
| 記載なし | 侵入経路・悪用された脆弱性 | 同上 |
| 記載なし | 被害企業名 | 同上 |
読むときの区別は3つだけです。
「確認された事実」は記事にそのまま書かれていること、「筆者の推察・判断」は筆者が「推察される」「ほぼ間違いない」と書いていること、「記載なし」は報告に見当たらないことです。
「記載なし」の行があっても、被害がなかったり安全だったりする意味ではありません。
分からないことが分からないまま残っている、という意味です。
質問メモの3行目と4行目は、10月15日の記事にある筆者の見解を手がかりにしています。
これは傾向分析にもとづく見解で、サンプル商会の状況を証明するものではありません。
ただし、預け先に何を確認すべきかを考える手がかりにはなります。
その手がかりを、次の質問メモに変えました。
| 質問 | なぜ聞くか | 回答の記録（聞いた日／回答日） |
| 顧客リストを預けているサービスで、2026年9月以降、不正アクセスや情報漏えいの兆候はありましたか | 報告には侵入経路も被害企業名も記載がなく、預け先の状況は自社では分からないため | （記入欄） |
| 漏えいが起きた場合、誰からいつ、どのような順番で連絡が来ますか | 報告には連絡の仕組みについての記載がないため | （記入欄） |
| サーバーのソフトウェア更新（パッチ適用）は、どのくらいの頻度で、どの範囲まで行われていますか | 10月15日の記事で筆者がパッチ適用の優先度を下げることへの注意を述べているため | （記入欄） |
| WAF（ウェブサイトへの攻撃を防ぐ仕組み）に頼りきりになっていないか、当社側で確認すべき点はありますか | 同じ記事で、WAFをすり抜ける手法が複数使われたと書かれているため | （記入欄） |
数字は、報告に書かれている「約20社」「8社」だけを使います。
これを自社の被害確率に置き換えたり、「8社だから大丈夫」と読んだりはしません。
効果や実績も、報告に書かれていない以上は書き足しません。
取引先に聞いても、答えてもらえなかったらどうしますか？
答えがなかったことも記録します。質問を絞って、窓口を変えて聞いてみましょう。
6. 確認リストと、うまくいかないときの戻り方
表と質問メモができたら、送る前と聞いた後に、次の5点を確認します。
- 表のすべての行に、どの記事の記載か（記事名と公開日）が書かれているか。
- 「確認された事実」の列に、原文の短い引用があるか。
- 「推察される」「ほぼ間違いない」「考えられる」といった語を含む文が、「確認された事実」の列に混ざっていないか。
- 「記載なし」の列に置いた項目が、質問メモの行として移っているか。
- 被害の有無や防御策を、推測で書いていないか。
うまくいかないときの戻り方も、3つの場面で決めておきます。
事実と推察の区別に迷ったとき。 迷った文は推察側に置き、理由を一言そえます。たとえば「本文に『推察される』とあるため」と書きます。事実側に置けるのは、記事にそのまま書かれていることだけです。どちらか分からないものを事実側に入れると、後から読んだ人が事実だと誤解します。
報告が更新されたとき。 10月19日公開の記事は10月21日に追記されています。報告は後から書き足されることがあるため、質問を送る前に出典を開き直し、表に更新日を書きます。数字や言い回しが変わっていたら、表と質問メモもその日のうちに直します。古い内容のまま質問すると、的外れな質問になります。
取引先が答えてくれないとき。 質問を1〜2個に絞ります。事務の窓口で分からないと言われたら、IT担当や契約を結んだ窓口に聞きます。「分からない」という回答でも、その内容と日付を記録に残します。答えがないことと、問題がないことは別だからです。
最後に大事な点です。
顧客リストを預けているサービスが今回の報告の標的だったかどうかは、この記事では判断できません。
報告を読んで分かるのは、日本企業が標的として観測され、漏えいを公表した企業があるという範囲のことです。
自社の対応をどうするかは、取引先や専門家の回答を得てから決めます。
被害が疑われる場合は、契約先の窓口や専門機関に相談してください。
この記事が少しでも参考になったら、AI実用ラボをフォローしていただけるとうれしいです。初心者にも分かりやすいAI活用情報をこれからもお届けします。
この記事の販売者
