問い合わせ窓口の異常通知が届いても、「誰に連絡するか分からない」と困ってしまいます。先に結論をお伝えすると、サービスの保守先、警告を受けた後の連絡先、更新と調査を分ける記録の三つを整えることが大切です。
DIVDの公表済み事案を入口に、店舗や小さな会社が担当者と確認する順番を整理します。自社の安全性を判定したり、攻撃を試す手順を紹介したりする記事ではありません。
問い合わせ管理ソフトの更新と、警告から人へつなぐ手順は別々に確認が必要です。DIVDの公表済み事案とZammadの修正案内をもとに、保守先・時間外連絡・更新と調査の記録を整理します。
この記事でわかること
- 使っている窓口と保守担当を確かめる
- 警告から判断までの連絡先を決める
- 更新完了と被害調査を分けて記録する
AIの話と、問い合わせ窓口への侵入を分けます
「AIが使われた」と「AIが侵入の原因」は同じではありません。
作業前の照合
利用形態から担当を確認
- 1自己運用版・配布形式・保守担当を確認
- 2提供元管理自社契約の対象案内を確認
- 3不明対象外にせず契約先へ照会
DIVDはオランダの脆弱性調査団体です。9月21日、問い合わせを案件ごとに管理するソフトZammadが侵入され、二つの脆弱性が使われたと公表しています。
脆弱性とは、悪用されるおそれのある仕組みの弱点です。本記事は10月の新事件を伝える速報ではなく、公表済み事案から自社の窓口管理を考えるものです。
DIVDは、攻撃者がサーバーの強い権限を得た後の活動でAIエージェントを使ったと判断しています。処理量や残された記録などが理由とされていますが、この記事で攻撃者やAI製品を特定するものではありません。
入口の弱点と、その後の活動を混ぜないことが大切です。お店の担当者が最初に確認するのは「自社も同じソフトを使うのか」「誰が管理するのか」です。
問い合わせメールが届くからといって、全店がZammadを使っているわけではありません。ホームページ制作会社や保守担当へ、窓口のサービス名を聞くところから始めましょう。
出典：DIVD事件記録。
更新は、古い案内だけで判断しないようにします
自己運用と提供元管理、製品の版と導入方法を確認します。
Zammadの10月5日の公式説明は、外部からの侵入につながる問題と、すでにサーバーへアクセスできる人が強い権限を得る問題を区別しています。後者は、それだけで外部から侵入できるという説明ではありません。
7系についても実行環境による違いが説明されており、すべての利用者を一括りにできません。10月8日の7.2.2案内は、DEB・RPMという配布形式の導入に関わる問題を修正しています。
さらに10月15日には、保守が終了した6.5系へ例外的な緊急修正6.5.5が出ました。これは7.2.2へすぐ移れない利用者向けの一時措置で、6.5系の保守期間が延びた意味ではありません。
6.5.5の入手には新しい配布先への切替が必要です。数字だけを見て自分で更新せず、担当者へ公式手順の確認を依頼してください。
同日の公式案内は自己運用に7.2.2への移行を推奨し、Zammad SaaSの利用者には対応不要としています。SaaSとは提供元が管理する形です。
別サービスへこの案内を当てはめず、利用形態と対象条件を照合します。出典：Zammad公式説明、7.2.2・6.5.5案内。
警告が届いた後、誰が判断するかまで決めます
通知を見つける仕組みと、人が動ける体制は別です。
机上で点検
警告から記録までの3手
- 1棚卸し窓口名と保守先
- 2引継ぎ時間外と代役
- 3別々に記録更新完了と影響調査
DIVDは検知19分、初動19時間、封じ込め9時間という異なる指標を公表しています。速く気づくことだけで対応が終わるわけではありません。
本文の経過も、通知、対応計画、実行を分けています。これらを単純に足した数字を一般的な目標時間にしたり、他社より安全という評価にしたりしないようにします。
ここからは小さな事業所への提案です。閉店後に窓口の異常通知が届いたら、店長へ連絡する人、店長につながらない場合の代役、保守会社へ相談する方法を書いておきます。
電話番号だけでなく「対応時間」「受付できる内容」も確認すると、緊急時の行き違いを減らせます。例えば予約受付を止める判断と、お客様へ案内を出す判断では担当が異なる場合があります。
保守会社への連絡文を一度作り、実際の異常を起こさず机上で確認しましょう。警告を受け取る人が、自分でサーバー操作まで行う必要はありません。
出典：DIVD事件記録。
サービス名、連絡先、二つの記録を一枚にします
設定を触る前に、担当と確認方法を整理することから始められます。
一手目は問い合わせ窓口の棚卸しです。サービス名、契約先、自己運用か提供元管理か、保守担当、対象確認日を一枚に書きます。
版が分からなければ「不明・担当へ照会中」と残します。空欄を「対象外」に置き換えてはいけません。
二手目は連絡の練習です。「誰が最初に見るか」「代役は誰か」「停止や再開を誰が決めるか」を、営業時間内と時間外で確認します。
共有するのは必要な連絡先と手順で、パスワードや認証コードをこの紙へ書く方法ではありません。三手目は更新完了と被害調査を別の欄にすることです。
保守担当へ、対象条件、作業予定、バックアップ、更新後に確認する版と動作を聞きます。調査欄には「ログ確認中」「影響範囲未確定」など、分かった段階をそのまま残します。
更新はこれからの悪用を防ぐための措置であり、過去に侵入されていない証明にはなりません。
「調査中」を、安全とも被害確定とも言い換えません
修正済みでも過去の影響確認は別に必要です。
被害調査には、確認が済んだ範囲と、まだ分からない範囲があります。問い合わせ窓口には顧客との連絡内容が入るため、更新の知らせだけで情報の影響まで判断しないようにしましょう。
他社の事件で使われた番号や手法が、自社にも当てはまるとは限りません。異常が疑われたら記録を勝手に消したり、出所不明の検査プログラムを動かしたりせず、保守担当や専門家へ相談します。
対象のサーバーへ試しに侵入するような確認は行いません。利用者へ案内する際も、確認日、分かったこと、未確認のこと、次の公式案内先を分けます。
問い合わせ窓口の安全は、更新と人への引継ぎを一緒に整えることが出発点です。noticaでは、お店が続けやすい情報整理とホームページ更新をお手伝いしています。
まず一つ確認するなら、閉店後の警告を受け取った人は、次に誰へ連絡すればよいでしょうか。情報確認日：2026年10月16日。
実際の作業時には提供元の最新案内を再確認してください。