第46章 問い合わせ箱の洪水

午前七時四十五分。

第三会議室に入ると、三枝涼真は最初に問い合わせ管理画面を開いた。

昨日、会社は沈黙リストを見つけた。

重要取引先への正式注意喚起が、届かないようにされていた。販促通知、配送通知、安全通知、セキュリティ通知、法令・契約通知。それらが一つのPreference Centerで管理され、旧APIキーによってまとめて止められていた。

会社は、それを分けた。

沈黙にも真正性が必要だと知った。

そして、必要な声を必要な相手へ届けるために、通知分類を作った。

三枝は、昨夜の自分のメモを思い出した。

声は、出すだけでは届かない。届く道を守って、初めて説明になる。

今朝は、その「届いた後」を確認するつもりだった。

取引先が、公式問い合わせ番号を使って本当に確認できているか。偽メールを受け取った取引先が、正しく専用窓口へ連絡しているか。重要配送の相互確認番号が、正しい問い合わせ箱に入っているか。

問い合わせ管理画面が開く。

システム名。

TrustDesk

駿河メディカルロジスティクスの公式問い合わせ・確認窓口。

問い合わせ番号。取引先名。カテゴリ。優先度。担当部署。SLA。添付ファイル。返信履歴。エスカレーション。

昨日までなら、普通のサポート管理ツールに見えていた。

今は違う。

これは、会社の耳だ。

取引先からの不安、確認、異常、現物未着、偽メール通報、緊急配送確認が、ここへ入る。

耳が聞こえなければ、声を出しても意味がない。

三枝は、未処理件数を見た。

未処理：1,284件

一瞬、数字を読み間違えたと思った。

昨日の夜は、百件弱だった。

今朝、千二百八十四件。

そのうち、カテゴリはほぼ同じだった。

公式確認依頼偽サイト確認受領確認番号照会緊急連絡先確認問い合わせ番号確認電子署名確認配送状況確認

三枝は、椅子から立ち上がった。

「課長」

黒崎課長が顔を上げた。

「どうした」

「問い合わせが一晩で千件以上増えています」

黒崎の表情が変わった。

「取引先からか」

「見た目はそうです。でも、多すぎます」

三枝は、TrustDeskの受信ログを開いた。

午前三時十二分から、急増している。

送信元はバラバラ。

取引先ドメイン。個人メール。フリーメール。過去の取引先担当者名。存在しない部署名。英語の問い合わせ。日本語の丁寧な問い合わせ。妙に機械的な文章。

件名には、共通する言葉が入っていた。

確認お願いします問い合わせ番号の照合受領番号が不明です緊急連絡先の再確認正式窓口ですか偽メールか判定してください

そして、多くの本文に、同じような一文があった。

念のため、至急ご回答ください。

山崎行政書士事務所の山崎が、会議室に入ってきた。

三枝は、画面を見せた。

「先生。問い合わせ箱が洪水です」

山崎は、モニターを見た。

そして、ホワイトボードへ向かった。

黒いペンで書く。

問い合わせ箱の洪水

その下に、もう一行。

届きすぎる通知も、攻撃である。

三枝は、その文字を見た。

昨日は、届かない通知。

今日は、届きすぎる問い合わせ。

攻撃者は、沈黙の次に騒音を使ってきた。

午前八時十分。

緊急会議が始まった。

望月社長、秋山法務総務部長、大石倉庫部長、営業部長、久我真琴、山崎。

三枝は、TrustDeskの状況を共有した。

「午前三時十二分以降、TrustDeskへ大量の問い合わせが流入しています。件数は千二百八十四件。本文は取引先確認を装っていますが、送信元、文体、問い合わせ番号、受領番号に不自然なものが多いです」

久我が、ログを見ながら言った。

「これは問い合わせスパムというより、業務妨害に近いです。公式確認窓口を埋めることで、本物の問い合わせを遅らせる」

営業部長が言った。

「本物の取引先の問い合わせも混じっています」

「そこが厄介です」

久我は頷いた。

「全部を捨てるわけにはいきません。ノイズと本物を分ける必要があります」

山崎が、ホワイトボードに三分類を書いた。

本物の声偽物の声判断不能の声

「今朝必要なのは、全部を読むことではありません。まず、重要な本物の声を埋もれさせないことです」

大石が言った。

「重要配送や病院便の問い合わせを先に見る」

「はい」

山崎は続けた。

「優先順位を設定します。生命・安全、重要配送、現物不一致、偽サイト入力、個人情報、法令・契約、その他。この順です」

三枝は、TrustDeskのフィルタを作った。

優先度A

病院名が登録済み取引先マスタと一致。相互確認番号形式が正しい。重要配送IDが存在。登録済み連絡先からの送信。添付なし。本文に「現物未着」「温度異常」「受領不一致」「偽サイト入力」が含まれる。

優先度B

取引先候補。問い合わせ番号形式は正しいが送信元未確認。確認が必要。

優先度C

番号形式不正。類似文面大量。送信元不明。自動返信疑い。スパム隔離。

山崎が言った。

「分類基準も記録してください。後で、なぜ優先したかを説明できるように」

三枝は、時系列表に入力した。

08:12　TrustDesk公式問い合わせ窓口に午前03:12以降、大量問い合わせ流入を確認。未処理1,284件。取引先確認を装うが不自然な送信元・文体・番号多数。本物問い合わせ埋没リスク。対応方針：生命・安全、重要配送、現物不一致、偽サイト入力、個人情報、法令・契約を優先する三分類フィルタを設定。

保存。

画面右下。

保存しました。

午前八時三十五分。

Blue Heronからメールが届いた。

件名は、Loud inbox。

本文は短かった。

You wanted voices.We gave you many.

声が欲しかったのだろう。たくさん用意した。

その下には、TrustDeskの未処理件数らしき画面が貼られていた。

三枝は、保全した。

久我が言った。

「TrustDeskの内部画面が見えている可能性があります」

黒崎が、すぐに調べ始めた。

「TrustDeskの外部閲覧者を確認します」

管理者一覧。

support-adminsales-support-leadlegal-support-viewertrustdesk-integration-botcustomer-success-tempexternal-support-ops

三枝は、最後の二つで手を止めた。

customer-success-temp。external-support-ops。

用途。

過去の問い合わせ対応BPO支援。契約終了済み。

状態。

Active。

最終ログイン。

三週間前。そして、今朝三時十六分。

三枝は、低く言った。

「契約終了済みBPO支援アカウントが、今朝ログインしています」

営業部長が顔を青くした。

「問い合わせ対応BPOは、昨年の繁忙期に使いました。今は使っていません」

山崎が言った。

「問い合わせ箱にも、外部支援終了管理が必要でした」

三枝は入力した。

08:38　TrustDesk管理者一覧に契約終了済み問い合わせ対応BPO支援アカウントcustomer-success-temp、external-support-opsを確認。状態Active。最終ログインは三週間前および本日03:16。問い合わせ箱内部画面が攻撃者に把握された可能性。

保存。

保全後、二つのアカウントを停止。

customer-success-temp: Disabledexternal-support-ops: Disabled

TrustDeskの外部閲覧権限も一時停止。

午前九時。

TrustDeskの急増問い合わせの中から、優先度Aが抽出された。

件数。

二十三件。

そのうち、真正性確認済み。

八件。

病院便の温度異常疑いが一件。偽サイトへ問い合わせ番号を入力した報告が二件。重要配送の受領番号不一致が一件。電子署名付き偽通知受領が三件。登録連絡先変更に関する問い合わせが一件。

残り十五件は、未確認。

三枝は、営業部と連携して登録済み連絡先へ折り返しを始めた。

問い合わせメールに書かれた電話番号にはかけない。TrustDeskに表示された返信先にもそのまま返信しない。登録済み取引先マスタの、昨日確認済みの連絡先を使う。

山崎が言った。

「問い合わせ窓口でも、登録済み連絡先で確認する。これを徹底してください」

営業部長が頷いた。

「はい」

大石が言った。

「現場は、TrustDeskのチケットだけで動かないようにします」

三枝は入力した。

09:04　TrustDesk大量問い合わせから優先度A 23件を抽出。真正確認済み8件。内容：温度異常疑い1、偽サイト入力報告2、受領番号不一致1、電子署名付き偽通知受領3、登録連絡先変更問い合わせ1。未確認分は登録済み連絡先で確認中。

保存。

本物の声は、騒音の中にもある。

それを拾うことが、今日の仕事だった。

午前九時三十分。

TrustDeskのチケット自動分類ルールを確認すると、新たな問題が見つかった。

昨夜二十三時五十六分。

自動分類ルールが変更されている。

変更者。

trustdesk-integration-bot

変更内容。

件名に“確認お願いします”“問い合わせ番号”“受領確認番号”を含む問い合わせを、低優先度キューへ移動

三枝は、顔をしかめた。

「低優先度に落とすルールが入っています」

営業部長が、思わず声を上げた。

「何ですか、それは」

三枝は続けた。

「件名に、まさに本物の問い合わせにも使われる言葉が入っていると、低優先度へ送られるよう変更されています」

久我が言った。

「ノイズを送っただけではなく、本物の問い合わせも低優先度に落ちるよう分類ルールを変えた可能性があります」

山崎が、ホワイトボードに書いた。

分類ルールも、攻撃対象。

三枝は、trustdesk-integration-botの詳細を開いた。

用途。

外部メール、Webフォーム、取引先ポータルからの問い合わせ連携。

権限。

チケット作成。分類ルール更新。自動返信テンプレート更新。

所有者。

情報システム課。旧BPO支援連携あり。

認証。

Webhook署名キー。

Webhook署名キー名。

trustdesk-webhook-legacy

三枝は、深く息を吐いた。

「Webhook署名キーがlegacyです」

黒崎が言った。

「保全して止める」

久我が止めた。

「現行問い合わせ連携に使われている可能性があります。まず利用状況を確認」

三枝は確認した。

現行Webフォームは、新しい署名キー。旧外部メール連携が、trustdesk-webhook-legacy。直近三か月、正規利用なし。昨夜、分類ルール変更に使用。

望月が言った。

「保全後、失効してください」

三枝は入力した。

09:35　TrustDesk自動分類ルールが昨夜23:56にtrustdesk-integration-botにより変更され、“確認お願いします”“問い合わせ番号”“受領確認番号”を含む問い合わせを低優先度キューへ移動する設定が追加されていたことを確認。trustdesk-webhook-legacy署名キーが関与。直近三か月正規利用なし、昨夜の不審変更に使用。保全後失効。

保存。

分類ルールを元に戻す。低優先度へ落ちていたチケットを再評価する。

すると、優先度A相当の問い合わせがさらに六件見つかった。

三枝は、胸が冷えた。

攻撃者は、本物の声を低い棚へ落としていた。

午前十時十分。

Blue Heronからメールが届いた。

件名は、Sorting hat。

本文は短い。

A voice in the wrong queue is silence.

違う箱に入った声は、沈黙だ。

三枝は、保全した。

山崎が、静かに言った。

「正しい表現です。分類ミスは、沈黙を作ります」

望月が言った。

「問い合わせが来ていても、見なければ届いていないのと同じ」

「はい」

山崎は答えた。

「昨日の沈黙リストは配信停止でした。今日は、受信後の沈黙です」

三枝は、ホワイトボードに書いた。

届いた後の沈黙

山崎は頷いた。

「良いです。問い合わせ箱の中でも、沈黙が作られます」

三枝は入力した。

10:10　不明差出人より件名“Sorting hat”のメール受信。“違う箱に入った声は沈黙”と記載。TrustDesk分類ルール悪用により本物問い合わせが低優先度へ落とされるリスクを確認。証跡保全。

保存。

午前十時四十五分。

問い合わせBPO会社との緊急確認が始まった。

会社名は、CareLine Support株式会社。

過去の繁忙期に、取引先問い合わせ一次対応を委託していた会社だ。

相手は、業務責任者の榊原。

山崎が質問した。

「customer-success-tempおよびexternal-support-opsは、御社のアカウントですか」

榊原は答えた。

「はい。昨年の繁忙期支援時のアカウントです。契約終了後に削除されるべきでした」

「本日午前三時十六分のログイン、または問い合わせ急増、分類ルール変更は御社作業ですか」

「違います。弊社では実施していません」

久我が聞いた。

「MFA通知先、Webhook署名キー、手順書の管理状態は」

榊原は、苦しそうに答えた。

「旧BPO支援メールと、当時の連携手順書が残っている可能性があります。保全します」

山崎は言った。

「確認対象は、旧メール、転送設定、MFA受信・クリック履歴、連携手順書、Webhook署名キー、退職者アカウント、再委託先です。二時間以内に一次回答をお願いします」

榊原は頷いた。

「対応します」

三枝は入力した。

10:48　CareLine Support一次確認。customer-success-temp、external-support-opsは同社昨年繁忙期問い合わせBPO支援アカウント。契約終了済み。本日03:16ログインおよび分類ルール変更は同社作業ではない旨。旧BPO支援メール、転送設定、MFA、連携手順書、Webhook署名キー等の保全を依頼。

保存。

午前十一時二十分。

TrustDeskの問い合わせ本文を機械的に分類していた久我が、ある異常を見つけた。

大量問い合わせの一部に、微妙に異なる「問い合わせ番号」が入っている。

形式は本物に似ている。

正規。

SML-2028-INC-0421

偽物。

SML-2028-lNC-0421

I が小文字の l に置き換わっている。

また別のもの。

SML-2028-INC-04Z1

2 が Z に置き換わっている。

三枝は、顔をしかめた。

「問い合わせ番号の視覚偽装です」

久我が言った。

「本物の問い合わせ番号と紛らわしいものを大量に入れて、検索や照合を混乱させる目的かもしれません」

山崎が言った。

「問い合わせ番号も、信頼根ですね」

三枝は頷いた。

確認番号。受領確認番号。問い合わせ番号。

それらは、取引先と会社をつなぐ小さな鍵だ。

攻撃者は、その鍵に似たものを作っている。

山崎が続けた。

「番号体系を見直しましょう。人間が読みやすいだけでなく、機械的に検証できるものにします。チェックデジット、固定桁、読み間違いしにくい文字、QRの署名、照合API」

黒崎が言った。

「I、O、l、0、1は使わない方がいいな」

三枝は、問い合わせ番号ルールに追加した。

使用禁止文字。チェックサム。発行元署名。期限。用途。取引先紐づけ。

入力。

11:24　大量問い合わせ内に、正規問い合わせ番号に似せた視覚偽装番号を複数確認。I/l、2/Z等の置換。問い合わせ番号・受領確認番号を信頼根として扱い、禁止文字、チェックサム、発行元署名、期限、用途、取引先紐づけを検討。

保存。

午後零時。

Blue Heronからメールが届いた。

件名は、Numbers speak。

本文は、短い。

Numbers are voices too.Some stutter.

番号も声だ。いくつかは、どもる。

三枝は、保全した。

山崎が言った。

「番号の偽装を認めていますね」

久我が頷いた。

「問い合わせ番号の視覚偽装、検索汚染、チケット混乱。攻撃として成立します」

営業部長が言った。

「取引先が電話で番号を読み上げる時にも間違えます」

山崎は答えた。

「だから、番号設計は現場設計です。読み上げやすく、聞き間違いにくく、検証できる必要があります」

大石が言った。

「配送番号も同じです」

三枝は、時系列表に入力した。

12:00　不明差出人より件名“Numbers speak”のメール受信。問い合わせ番号の視覚偽装・混乱を示唆。“番号も声”と記載。対応方針：問い合わせ番号・受領確認番号・配送確認番号の真正性設計を見直し。

保存。

午後一時。

TrustDeskの優先度A対応が進んだ。

本物問い合わせ。

三十一件。

そのうち、即時対応済み。

二十二件。

未対応。

九件。

いずれも取引先へ折り返し中。

ノイズ問い合わせ。

九百件以上。

隔離。

判断不能。

約三百件。

再確認待ち。

営業部長は、明らかに疲れていた。

「人手が足りません」

望月が言った。

「臨時体制を組みます。ただし、外部BPOをすぐ入れることはできません」

山崎が頷いた。

「入れるなら、P-003のように条件付き許可が必要です。作業者個別、閲覧範囲限定、録画、二名確認、個人情報最小化、終了確認」

営業部長が言った。

「社内でできる範囲を増やします」

大石が言った。

「現場からも、重要配送の確認は協力します」

久我が言った。

「自動分類は使いますが、優先度Aは人間確認を残します」

三枝は、問い合わせ対応体制を記録した。

13:08　TrustDesk大量問い合わせ対応体制を再編。優先度Aは人間確認、Bは登録済み連絡先照合、Cは隔離。外部BPO再投入は現時点で行わず、必要時は条件付き許可・個別作業者・範囲限定・終了確認を必須とする方針。

保存。

午後二時二十分。

CareLine Supportから追加回答が届いた。

旧BPO支援メールは残存。MFAメールは三週間前と本日未明に受信。旧BPO支援メールから、同社の旧オペレーター共有メールへ転送されていた。その共有メールには、退職者アカウントがアクセスできた。本日三時十六分のログイン前に、MFAリンククリック履歴あり。TrustDesk連携手順書には、trustdesk-webhook-legacyの署名キーが記載されていた。

三枝は、もう驚かなかった。

だが、疲労は深くなった。

山崎が言った。

「同じ型ですが、ここでは問い合わせ箱に使われました」

三枝は入力した。

14:23　CareLine Support追加回答。旧BPO支援メールが残存し、MFAメールを三週間前・本日未明に受信。旧オペレーター共有メールへ転送され、退職者アカウントがアクセス可能。本日03:16ログイン前にMFAリンククリック履歴。TrustDesk連携手順書にtrustdesk-webhook-legacy署名キー記載。

保存。

黒崎が言った。

「旧BPO支援会社が持っていた手順書で、問い合わせ箱の分類を変えた」

久我が頷いた。

「その可能性が高いです」

山崎が言った。

「問い合わせ対応BPO契約にも、終了証明パックが必要です。アカウント、メール、MFA、Webhook、分類ルール、テンプレート、顧客情報、チケットアーカイブ」

秋山は、未了事項台帳に追加した。

U-176　問い合わせBPO終了管理・TrustDesk外部権限管理未整備

保存。

午後三時四十分。

Blue Heronからメールが届いた。

件名は、Help desk helped。

本文は、一行。

The help desk helped us too.

ヘルプデスクは、我々も助けた。

三枝は、保全した。

営業部長は、悔しそうに画面を見た。

「問い合わせ窓口は、取引先を助けるためのものです」

山崎が頷いた。

「はい。だからこそ守ります」

久我が言った。

「ヘルプデスクは、外部からの情報が集まる場所です。攻撃者にとっても、偵察、混乱、分類操作、個人情報取得、心理的揺さぶりに使えます」

望月が言った。

「TrustDeskも、重要システムに格上げします」

三枝は入力した。

15:40　不明差出人より件名“Help desk helped”のメール受信。問い合わせ窓口が攻撃者にも有用だった旨を示唆。TrustDeskを重要システムとして格上げし、外部権限、分類ルール、Webhook、テンプレート、チケットアーカイブを統制対象化。

保存。

午後四時半。

問い合わせ箱統制の方針案が作られた。

山崎が文面を整える。

問い合わせ箱統制方針

一　問い合わせ窓口は、会社の耳として重要システムに位置づける。

二　大量問い合わせ発生時は、生命・安全、重要配送、現物不一致、偽サイト入力、個人情報、法令・契約を優先する。

三　問い合わせ分類ルールの変更は、二名承認・ログ保全・変更理由記録を必須とする。

四　外部BPO支援アカウントは期限付きとし、終了時にアカウント、メール、MFA、Webhook、手順書、チケット閲覧権限を削除確認する。

五　Webhook署名キー、APIキー、連携ボットを台帳管理する。

六　問い合わせ番号は、視覚偽装しにくく、機械検証可能な形式にする。

七　重要問い合わせは、メール本文やチケットだけで判断せず、登録済み連絡先で確認する。

八　本物問い合わせが低優先度に落ちていないか、定期的に再評価する。

望月が頷いた。

「これを、すぐ運用に入れましょう」

営業部長が言った。

「TrustDeskの優先度Aは、朝夕で確認します」

黒崎が言った。

「分類ルール変更は、情シスと営業の二名承認にします」

久我が言った。

「ノイズ検知だけでなく、本物埋没検知も入れます」

三枝は、方針をTrustDesk運用手順へ追加した。

午後五時五十分。

Blue Heronから、その日最後のメールが届いた。

件名は、Quiet inbox。

本文は、短い。

The flood found drains.

洪水に排水路ができた。

三枝は、保全した。

営業部長が、疲れた笑みを浮かべた。

「排水路、できましたかね」

久我が答えた。

「少なくとも、流れは分けられています」

山崎が頷いた。

「重要なのは、洪水をゼロにすることではなく、本物の声を流さないことです」

望月が言った。

「問い合わせ箱にも、堤防と排水路が必要ですね」

山崎は答えた。

「はい。分類、優先度、確認経路、再評価です」

三枝は時系列表に入力した。

17:50　不明差出人より件名“Quiet inbox”のメール受信。大量問い合わせに対する分類・優先度・隔離対応に反応した可能性。“洪水に排水路ができた”と記載。証跡保全。

保存。

午後七時。

その日の最終会議で、山崎はまとめた。

ホワイトボードには、今日の言葉が並んでいる。

問い合わせ箱の洪水届きすぎる通知も、攻撃である。本物の声・偽物の声・判断不能の声届いた後の沈黙分類ルールも、攻撃対象。番号も声である。

山崎は言った。

「昨日は、必要な通知が届かない攻撃でした。今日は、問い合わせ箱に声を流し込み、本物の声を埋める攻撃でした」

望月が頷いた。

「説明の出口だけでなく、入口も守る」

「はい」

営業部長が言った。

「問い合わせ窓口を、ただの業務部門の道具ではなく、危機対応の基盤として扱います」

大石が言った。

「現場も、TrustDeskチケットだけで動かず、重要配送は登録済み連絡先で確認します」

黒崎が言った。

「分類ルール変更とWebhookは、特権扱いです」

秋山が言った。

「BPO契約終了時の削除証明も入れます」

三枝は、全員の言葉を記録した。

会社の耳にも、鍵がかかり始めた。

午後九時。

三枝は、一人でTrustDeskの画面を見ていた。

未処理件数は、まだ多い。

しかし、優先度Aは見える。本物の声は、ノイズの下から少しずつ拾われている。低優先度へ落とされた問い合わせも再評価された。偽番号は隔離された。本物の取引先は、登録済み連絡先で確認された。

洪水は止まっていない。

だが、流れはできた。

三枝は、自分のノートに書いた。

耳は、開くだけでは足りない。聞く順番を守らなければ、重要な声は沈む。

保存。

山崎が、背後から言った。

「今日の結論ですね」

三枝は振り返った。

「問い合わせ箱まで攻撃されるとは」

山崎は頷いた。

「会社が外と話す場所は、すべて攻撃されます。話す口、聞く耳、記録する手。全部です」

「今日は耳」

「はい」

三枝は、TrustDeskを閉じた。

午前零時。

三枝は、時系列表の最後に入力した。

00:00　TrustDesk公式問い合わせ窓口へ午前03:12以降、大量問い合わせが流入し、未処理1,284件を確認。契約終了済み問い合わせBPO支援アカウントcustomer-success-temp、external-support-opsのログイン、trustdesk-webhook-legacy署名キーによる分類ルール変更を確認。“確認お願いします”“問い合わせ番号”“受領確認番号”を含む問い合わせが低優先度へ移動されていた。優先度A抽出、分類ルール復旧、旧BPOアカウント停止、Webhook署名キー失効、真正問い合わせの登録済み連絡先確認、問い合わせ番号偽装対策、TrustDesk重要システム化を実施。

保存。

画面右下。

保存しました。

三枝は、自分のメモにも一行追加した。

会社の耳を守る。騒音の中で、本物の声を沈めない。

保存。

第三会議室の外では、倉庫が静かに動いていた。

ラベルの音。端末の音。電話の音。問い合わせ通知の音。

会社には、たくさんの音がある。

攻撃者は、その音を増やし、ずらし、低い箱へ落とそうとした。

だが、会社は聞く順番を覚え始めていた。

本物の声を拾うために。