AIの活用を考えるとき、営業資料の作成や顧客対応の効率化に目が向きがちです。ところが、攻撃する側もAIを利用しています。顧客情報を扱う企業として、既存システムの点検と、防御へのAI活用を一緒に考えたいと思います。
GMOサイバーセキュリティ byイエラエは10月19日、日本企業への侵害事案を調べる中で、攻撃元のインフラからAIを使う侵入テストツール「ARTEX」の使用を確認したと報告しました。CrowdStrikeも10月7日、韓国の金融機関を標的とする攻撃で、ARTEXの設定など、攻撃者側の作業記録を確認しています。GMOの調査、CrowdStrikeの報告
これは観測された攻撃についての報告です。国内で相次ぐ漏えいのすべてにAIが使われた、あるいは侵入から情報窃取までをAIだけで完遂した、と確認されたわけではありません。
企業側が取り組みたいのは、攻撃者がAIを使っているかの特定を待たず、公開したままの機能や未修正の問題を減らすことです。最新のAIサービスを導入していても、以前から使っているシステムの点検は欠かせません。
昔のキャンペーンサイト、顧客向けポータル、社外から使えるVPN。加えて、部署で契約したSaaSや、従業員向けの管理画面も確認の対象です。
JPCERT/CCは10月8日の注意喚起で、BIツールや従業員向け管理システムも被害に遭っていると説明しました。情報は限定的・断片的で、全事案が同じ攻撃手法によるものではないとの注記もあります。「一般向けに宣伝していないシステムだから大丈夫」とは判断できません。JPCERT/CCの注意喚起
たとえば担当者や委託先に、「インターネットから接続できるシステムと、保存している顧客情報を一覧にしてください」と依頼します。一覧には、管理責任者、保守期限、更新状況、ログの保存期間も含めると、その後の対応を決めやすくなります。
IPAの10月9日の注意喚起も、外部公開アプリや外部サービスの洗い出し、ログ、未適用の修正、不審なアカウントの点検を求めています。ログは直近1カ月、その後3カ月と範囲を広げる進め方を示しています。特定の製品やサービスの脆弱性を狙った攻撃と一括して断定しているわけではありません。IPAが示す点検・対策
古い業務システムには、更新すると連携先が動かなくなる、保守担当がいない、といった事情もあります。その場合は、更新までの対応を具体的に決める必要があります。
使っていない公開機能の停止、接続できる拠点の限定、他のシステムとの通信範囲の制限などが考えられます。業務への影響を担当者と確かめながら、実施できる対策を選びます。接続制限は被害の可能性を減らすための措置であり、元の脆弱性を修正するものではありません。継続利用を認める責任者と、更新・移行・廃止の期限も残したいところです。
確認する成果物は、「対応しました」という報告だけでは不十分です。たとえば、更新後のバージョン、社外から管理画面へ接続できないことの確認、業務が正常に動くことの記録です。更新に失敗した場合の戻し方も、作業前に準備します。
顧客情報については、利用目的を終えたデータを保存し続けていないかも見直します。保存義務や契約条件を確認したうえで、不要な情報を減らすことは、漏えいした場合の影響を小さくする対策になります。
CRMを使う企業では、ログインする人の権限に加えて、外部サービスとの連携権限も点検したいところです。連携時に発行したAPIトークンが、退職者のアカウントや、使わなくなったサービスに残っているかもしれません。
たとえば「どのサービスが顧客情報を読めるか」「一括出力できるのは誰か」「連携を止めるときに、どのキーを無効にするか」を確認します。名前を変えた管理画面や、通常の画面からリンクしていないAPIにも、認証と権限の確認が必要です。
APIトークンはアクセスを認めるための情報です。用途に必要な権限だけを付け、期限や失効方法を決めます。JPCERT/CCも、APIごとのアクセス制御、利用回数の制限、必要最小限の権限、トークンの期限と無効化を対策に挙げています。APIを含む対策の詳細
委託先には「設定を確認してください」に加え、「一般利用者が他の利用者のデータを取得できないことを、テストで示してください」と依頼すると、確認する内容が明確になります。認証できることと、その人に閲覧・変更を認めてよいことは、それぞれ確かめる必要があります。
AIで短期間にアプリを作れるようになった分、動作確認から公開までを急ぎやすくなりました。画面で期待した操作ができても、権限の設定や情報の保管方法まで安全とは限りません。
公開前には、利用者ごとのデータが分かれているか、管理者だけの操作を一般利用者が実行できないかを確認します。APIキーがブラウザや公開ファイルに出ていないこと、利用する部品を更新できること、誰が何を変更したか記録できることも確認事項です。
NISTの開発・運用の実証プロジェクトでも、AIによるコード生成や検査とともに、人による監督と内容の検証を重視しています。AIが作った修正案も検証環境で確かめ、問題があったときの戻し方を用意してから公開する進め方です。NISTの実証資料
防御にAIを使う方法も具体化しています。Anthropicは10月6日、防御の専門家向け「Cyber Verification Program」を拡大しました。一般モデルでも、自社が所有するコードの脆弱性発見、既知の問題の修正、警告の仕分けなどを利用対象に挙げています。高度な利用には審査や対象システムの権限、データ保持などの条件があります。Anthropicの発表
一般企業での始め方としては、警告の整理から修正後の再検査までを、担当者の業務に組み込む方法が考えられます。
まず、AIに警告を分類させ、疑わしい箇所と判断の根拠を並べてもらいます。担当者が実際の設定やコードと照合し、問題が再現するか、外部に公開されているか、顧客情報に影響するかを確認します。そのうえでAIに修正案とテスト案を作らせ、人が承認して検証環境へ反映し、直ったことと業務への影響を再検査します。
ログ調査でも、「異常です」という要約だけで終わらせず、確認が必要な時刻や操作と根拠を示してもらいます。AIの誤検出や見落としを確かめられる形にしておくためです。最初は読み取りを中心にし、業務停止やデータ削除まで自動化する範囲は慎重に決めるのがよいと思います。
調査に使うAIサービスへ、顧客情報や認証情報をそのまま渡すことは避けます。入力できる情報、保存先、保持期間、利用権限を確認し、必要な情報に絞ります。
AIで問題を見つける量が増えても、対応する人が決まっていなければ改善は進みません。「未点検の公開システムはどれか」「重要な指摘を誰がいつ直すか」「修正後に何を確かめたか」を、経営側でも確認できるようにしたいところです。
復旧の準備も並行して進めます。バックアップは取得できたかに加えて、必要なデータと業務を戻せるかの確認が必要です。ただし、復元できても、すでに盗まれた個人情報の流出を取り消すことはできません。不要な情報を減らすこと、アクセスを絞ること、利用の痕跡を残すことも欠かせません。
私は、AIを使って点検や調査を進めながら、残っている問題と対応状況を人が把握できる運用が必要だと考えています。まずは担当者や委託先と、公開中のシステム、未対応の指摘、次に実施する作業を確認するところから始められます。
※2026年10月20日確認時点。点検表と運用手順は、公表資料を踏まえた編集上の提案です。