第47章 解決済みの嘘
- 山崎行政書士事務所
- 5月7日
- 読了時間: 16分
午前七時三十八分。
TrustDeskの未処理件数は、前夜より減っていた。
それだけ見れば、改善だった。
未処理。
1,284件 から 612件。
優先度Aは、すべて人間確認に回っている。優先度Bは、登録済み連絡先で照合中。優先度Cは、隔離キューへ移動。分類ルールも復旧した。旧BPO支援アカウントは停止済み。Webhook署名キーも失効済み。
問い合わせ箱の洪水には、排水路ができた。
三枝涼真は、その数字を見て、ほんの少しだけ息を吐いた。
しかし、次の列で手が止まった。
Resolved:384件
解決済み。
三枝は眉をひそめた。
昨夜の最終確認時点では、優先度BとCの大半は未処理または隔離だった。解決済みにしてよい問い合わせは、そこまで多くなかったはずだ。
彼は、Resolvedチケットの一覧を開いた。
件名が並ぶ。
偽メールか確認したい問い合わせ番号を入力してしまったかもしれない電子署名付き文書の確認受領確認番号が不明連絡先変更メールを受け取りました配送確認フォームについて
三枝の背中に冷たいものが走った。
これは、解決していない。
少なくとも、人間が確認した記録はない。
彼は、ひとつのチケットを開いた。
取引先からの問い合わせ本文。
昨日、駿河ML様名義の確認ポータル移行メールを受け取りました。リンク先を開きましたが、入力はしていないと思います。念のため確認をお願いします。
返信履歴。
TrustDeskからの自動返信があった。
本件は既に確認済みです。追加対応は不要です。今後、同様のメールを受信した場合も、通常どおり確認ポータルをご利用ください。
三枝は、椅子から立ち上がった。
「違う」
黒崎課長が顔を上げた。
「何だ」
「自動返信が、おかしいです。偽ポータルを通常どおり利用してくださいと返しています」
黒崎の顔が変わった。
「誰が返した」
三枝は、チケット履歴を確認した。
返信者。
auto-response-engine
テンプレート。
verification_followup_resolved_v3
更新者。
external-support-ops
更新時刻。
午前二時五十八分。
外部BPO支援アカウント。
前日に停止したはずのアカウントだった。
三枝は、ログをさらに見た。
アカウント停止は午前八時三十八分。テンプレート改変は、その前。午前二時五十八分。
つまり、攻撃者はアカウント停止前に、返信テンプレートを改変していた。
そして、夜間の自動処理がそれを使って、問い合わせを「解決済み」にしていた。
山崎行政書士事務所の山崎が、会議室に入ってきた。
三枝は、画面を指した。
「先生。今度は、自動返信です」
山崎は、数秒だけ画面を見て、ホワイトボードへ向かった。
黒いペンで書く。
解決済みの嘘
その下に、もう一行。
返信したことと、解決したことは違う。
三枝は、その文字を見た。
昨日は、届いた後の沈黙だった。今日は、解決したことにされている。
問い合わせは届いた。会社は返信した。チケットは閉じた。
しかし、問題は解決していない。
攻撃者は、沈黙の次に、偽の解決を作っていた。
三枝は時系列表を開いた。
07:42 TrustDeskでResolvedチケット384件を確認。複数チケットにauto-response-engineによる自動返信あり。本文に“確認ポータルをご利用ください”等、当社方針と矛盾する内容を確認。テンプレートverification_followup_resolved_v3は02:58に契約終了済みBPO支援アカウントexternal-support-opsにより更新。
保存。
画面右下。
保存しました。
午前八時五分。
緊急会議が開かれた。
望月社長、秋山法務総務部長、大石倉庫部長、営業部長、久我真琴、山崎。
三枝は、TrustDeskの自動返信履歴を共有した。
自動返信テンプレートは、三種類改変されていた。
verification_followup_resolved_v3偽ポータルを通常どおり利用するよう案内。
signature_document_no_action_v2電子署名付き文書は有効なら追加確認不要と案内。
delivery_receipt_closed_v1ePODがあれば配送完了として扱うと案内。
会議室は静まり返った。
これまで会社が必死に分けてきたものが、すべて元に戻されている。
鍵マークだけでは信じない。電子署名だけでは信じない。受領書だけでは信じない。登録済み連絡先で確認する。相互確認番号を使う。重要通知は止めない。
その全部を、自動返信が否定している。
山崎が、静かに言った。
「攻撃者は、当社の新しいルールを古いルールに戻す返信を出しています」
久我が頷いた。
「しかも、自動返信なので早い。人間が確認する前に、取引先へ誤った安心を与えます」
営業部長が、顔を青くした。
「取引先は、当社からの返信だと思います」
「はい」
山崎は答えた。
「だから、すぐ訂正が必要です」
望月は言った。
「対象件数は?」
三枝が答えた。
「現時点で自動返信送信済みが384件です。外部送信成功は312件。開封はまだ集計中です」
秋山が言った。
「誤返信の影響整理が必要です」
山崎は、ホワイトボードに書いた。
誤返信影響整理
送信先誤返信内容開封有無相手の行動可能性訂正要否優先度
「まず、誤返信の種類ごとに訂正します」
三枝は入力した。
08:08 TrustDesk自動返信テンプレート3件が当社方針と矛盾する内容へ改変され、自動返信312件が外部送信成功。偽ポータル利用、電子署名付き文書の追加確認不要、ePOD単独配送完了等を案内。誤返信影響整理と訂正通知を開始。
保存。
午前八時三十分。
Blue Heronからメールが届いた。
件名は、Solved。
本文は、短かった。
A closed ticket is a quiet customer.
閉じたチケットは、静かな顧客だ。
その下には、TrustDeskのResolved件数が貼られていた。
三枝は、保全した。
営業部長が、拳を握った。
「取引先を黙らせるために、解決済みにした」
山崎は頷いた。
「はい。昨日の沈黙リストと同じです。ただし、今回は“対応したように見える沈黙”です」
久我が言った。
「チケットを閉じること自体が攻撃に使われています」
三枝は、ホワイトボードに書かれた言葉を見た。
返信したことと、解決したことは違う。
その通りだった。
問い合わせへの返信は、解決の始まりでしかない。自動返信は、さらに弱い。問題の確認、相手の理解、必要な対応、再発防止までがなければ、解決とは言えない。
三枝は入力した。
08:30 不明差出人より件名“Solved”のメール受信。TrustDeskのResolved件数を提示。“閉じたチケットは静かな顧客”と記載。攻撃者が自動返信・自動解決により取引先問い合わせを沈黙させる意図の可能性。証跡保全。
保存。
午前八時五十五分。
TrustDeskの自動返信機能が緊急停止された。
ただし、全停止すると、本物の問い合わせ受付通知も止まる。
山崎が言った。
「完全停止ではなく、重要カテゴリの自動解決を停止します。受付確認だけは、人間確認前の一般文面に限定します」
秋山が文面を作った。
お問い合わせを受け付けました。現在確認中です。本返信は受付確認であり、内容の真正性、配送完了、文書の有効性、対応完了を示すものではありません。当社からの正式回答は、担当者確認後にお送りします。
山崎が頷いた。
「良いです。自動返信の限界を明示しています」
TrustDesk設定変更。
自動解決。
無効。重要カテゴリの自動返信。
受付確認のみ。テンプレート変更。
二名承認必須。外部アカウント編集。
不可。テンプレート履歴。
保全。
三枝は入力した。
08:58 TrustDesk重要カテゴリの自動解決を停止。自動返信は受付確認のみへ変更し、“本返信は受付確認であり、真正性・配送完了・文書有効性・対応完了を示さない”旨を明記。テンプレート変更は二名承認必須、外部アカウント編集不可へ変更。
保存。
午前九時二十分。
誤返信を受け取った取引先への訂正通知が作成された。
山崎が、慎重に文面を整えた。
本日未明から朝にかけて、当社問い合わせ窓口から一部の自動返信が送信されました。当該返信の一部には、当社の現行方針と異なる内容が含まれていた可能性があります。特に、偽確認ポータルの利用、電子署名付き文書の追加確認不要、ePOD単独での配送完了扱い等を案内する返信は、当社の正式回答ではありません。当社は現在、対象問い合わせを個別に確認しています。重要配送、偽サイト入力、電子署名付き文書、連絡先変更に関するお問い合わせについては、登録済み連絡先または本件専用窓口で改めてご確認ください。
望月は文面を読み、言った。
「自動返信が誤っていたことを、隠さない」
「はい」
山崎は答えた。
「誤った安心を与えた可能性があるため、訂正が必要です」
営業部長が言った。
「送ります」
三枝は、対象者リストを作った。
自動返信成功312件。そのうち、優先訂正対象。
偽ポータル関連。電子署名付き文書関連。ePOD関連。連絡先変更関連。個人情報関連。
訂正は、現行メール基盤と公式サイト、登録済み連絡先で実施。
時系列へ入力。
09:26 誤自動返信対象312件について訂正通知を準備。偽確認ポータル利用、電子署名付き文書追加確認不要、ePOD単独配送完了等の案内は正式回答ではない旨を明記。優先訂正対象を抽出し、登録済み連絡先・公式窓口で再確認。
保存。
午前十時。
TrustDeskのテンプレート履歴を深掘りすると、さらに別の機能が見つかった。
Auto-close rule
条件。
受付確認後、一定時間内に返信がない場合、チケットを自動解決。重要度Cは十二時間。重要度Bは二十四時間。重要度Aは自動解決しない。
昨夜の変更。
重要度Bの自動解決時間。
24時間 → 15分
変更者。
external-support-ops
三枝は、声を失った。
「Bの自動解決が十五分にされています」
営業部長が叫ぶように言った。
「十五分?」
「はい。優先度Bの問い合わせが、十五分返信がなければ解決済みになります」
久我が言った。
「本物の問い合わせを低優先度に落とし、さらに短時間で解決済みにする。二段階です」
山崎が、ホワイトボードに書いた。
低い箱へ落とす早く閉じる
「問い合わせを沈黙させるには、これで十分です」
三枝は入力した。
10:03 TrustDesk Auto-close rule確認。昨夜、external-support-opsにより重要度Bの自動解決時間が24時間から15分へ変更。分類ルールにより本物問い合わせを低優先度へ落とし、短時間で解決済みにする二段階の沈黙化が行われた可能性。
保存。
自動解決ルールは即時停止。過去二十四時間に自動解決された全チケットを再オープン。優先度再評価。
件数。
四百六十九件。
再評価により、優先度Aが十二件、Bが六十八件見つかった。
営業部の顔色が変わった。
山崎は言った。
「閉じられたチケットは、解決済みではなく、再確認済みになるまで閉じないでください」
三枝は、TrustDeskのステータス名を追加した。
再確認中
Resolvedから戻す。
入力。
10:14 過去24時間にAuto-closeされた469件を再オープンし、ステータスを再確認中へ変更。優先度再評価によりA 12件、B 68件を確認。
保存。
午前十時三十五分。
Blue Heronからメールが届いた。
件名は、Closed is closed。
本文は、短い。
Why reopen what is solved?
解決したものを、なぜ開き直す?
三枝は、保全した。
山崎が言った。
「解決していないからです」
望月も、すぐに言った。
「解決済みは、確認済みではありません」
山崎は頷いた。
「今日の社内標語ですね」
三枝は、ホワイトボードに書いた。
解決済み ≠ 確認済み
営業部長が頷いた。
「これをTrustDeskの上に出したいです」
「出しましょう」
三枝は入力した。
10:35 不明差出人より件名“Closed is closed”のメール受信。自動解決チケット再オープンに反応した可能性。“解決したものをなぜ開き直す”と記載。対応方針:解決済みと確認済みを区別し、自動解決済みチケットを再確認。
保存。
午前十一時二十分。
訂正通知への反応が返り始めた。
取引先A。
「自動返信を見て偽ポータルに入力しようとしていたが、訂正で止まった」
取引先B。
「電子署名付き文書を本物と判断しようとしていたが、再確認する」
県立東駿河医療センター。
「当院宛の自動返信には、ePOD単独確認の文言が含まれていた。病院側では、現物確認を継続する」
大石が、深く息を吐いた。
「間に合った部分もありますね」
山崎は頷いた。
「はい。誤返信を訂正したことにも意味があります」
三枝は、訂正効果記録を作った。
誤返信受領先訂正通知到達相手方行動二次被害有無追加対応
入力。
11:24 誤自動返信訂正により、複数取引先が偽ポータル入力、電子署名付き文書の誤信、ePOD単独確認を停止または再確認。訂正通知の効果を記録。
保存。
午後零時十五分。
CareLine Supportから追加回答が届いた。
external-support-opsのMFA承認経路は、旧BPO支援メールから旧オペレーター共有メールへ転送。その共有メールに、退職者アカウントがアクセス可能。昨夜二時五十五分にMFAリンククリック。TrustDeskテンプレート変更、Auto-close変更、分類ルール変更の前にログイン成功。
さらに、TrustDesk操作マニュアルの中に、自動返信テンプレートの編集方法とAuto-closeルールの説明が残っていた。
山崎が言った。
「問い合わせ対応マニュアルが、攻撃手順になりました」
営業部長が、苦い顔で言った。
「本来は、対応品質を上げるためのものです」
「はい」
山崎は答えた。
「だから、マニュアルをなくすのではありません。外部契約終了後のアクセスを閉じるのです」
三枝は入力した。
12:18 CareLine Support追加回答。external-support-opsは旧BPO支援メール→旧オペレーター共有メール転送経由でMFA承認。本日02:55にリンククリック、テンプレート変更・Auto-close変更・分類ルール変更前にログイン成功。TrustDesk操作マニュアルに自動返信・Auto-close編集手順が残存。
保存。
午後一時半。
TrustDesk統制方針に、新しい項目が加わった。
山崎が文案を作る。
問い合わせ応答統制
一 自動返信は受付確認に限定し、内容判断・真正性判断・完了判断をしない。
二 自動解決は原則禁止。利用する場合は低リスクカテゴリに限定し、監査対象とする。
三 重要問い合わせは、人間確認者、確認経路、対応根拠を記録する。
四 テンプレート変更、分類ルール変更、Auto-close変更は二名承認とする。
五 外部BPOは、作業者個別、範囲限定、録画、終了証明を必須とする。
六 誤返信が発生した場合は、影響先、内容、訂正、相手方行動を記録する。
七 解決済みは、確認済みと区別する。
三枝は、TrustDeskの画面に新しいステータスを追加した。
受付済み確認中要折り返し再確認中対応完了解決確認済み
Resolvedという曖昧な言葉を、使わない。
営業部長が言った。
「解決確認済みは、相手方確認まで?」
山崎は頷いた。
「重要問い合わせについては、はい。こちらが答えただけでは終わりません」
三枝は、ノートに書いた。
解決は、相手に届いて初めて近づく。
保存。
午後二時四十分。
Blue Heronからメールが届いた。
件名は、No auto peace。
本文は、一行。
You do not let machines calm people now.
今度は、機械に人を安心させないのか。
三枝は、保全した。
山崎が言った。
「重要なことです。機械が受付をすることはできます。しかし、機械だけで安心させてはいけない場面があります」
望月が頷いた。
「安心にも、根拠が必要ですね」
「はい」
久我が言った。
「自動返信は便利ですが、攻撃中は誤った安心を増幅します」
営業部長が言った。
「人間が確認して返すべき問い合わせを、機械で閉じない」
三枝は入力した。
14:40 不明差出人より件名“No auto peace”のメール受信。重要問い合わせへの自動返信・自動解決停止に反応した可能性。“機械に人を安心させない”と記載。対応方針:自動返信は受付確認に限定し、安心・真正性・完了判断は人間確認を必須化。
保存.
午後三時半。
再オープンしたチケットの中から、重大な一件が見つかった。
取引先は、東部検査センター。
内容。
偽確認ポータルに問い合わせ番号と担当者メールを入力した後、別メールで“再認証コード”を求められています。これは本物ですか。
この問い合わせは、自動分類で低優先度へ落ち、自動解決済みになっていた。
もし再確認しなければ、見逃していた。
営業部が登録済み連絡先で折り返した。
東部検査センターは、まだ再認証コードを入力していなかった。
山崎が言った。
「間に合いました」
三枝は、胸をなで下ろした。
この一件で、再オープンの意味が明確になった。
解決済みの嘘を開き直したから、本物の危険が見つかった。
三枝は入力した。
15:34 再オープンした自動解決済みチケットから、東部検査センターの偽ポータル入力後の再認証コード要求に関する問い合わせを確認。登録済み連絡先で折り返し、再認証コード未入力を確認。二次被害を回避。
保存。
営業部長は、静かに言った。
「閉じていたら、危なかった」
望月が頷いた。
「だから、開き直す」
山崎は言った。
「はい。疑わしい解決済みは、再確認します」
午後五時。
問い合わせ箱の洪水は、ようやく流れを取り戻し始めた。
未処理。
612件から、358件。
優先度A。
全件対応中。自動解決再確認。
進行中。誤返信訂正。
送信済み。重大二次被害。
現時点で確認なし。
TrustDeskのダッシュボードには、新しい指標が追加された。
本物問い合わせ救出件数誤返信訂正件数自動解決再確認件数低優先度誤分類復旧件数
三枝は、その指標を見て思った。
問い合わせ対応にも、救出という言葉があるのか。
本物の声を、沈んだ箱から救い出す。
それは、サイバーセキュリティの仕事だった。
山崎が言った。
「良い指標です。防御の成果が見えます」
三枝は頷いた。
「ただ件数を減らすだけではなく、本物を拾えたかを見る」
「はい」
午後六時半。
Blue Heronから、その日最後のメールが届いた。
件名は、Reopened。
本文は、短かった。
You keep reopening wounds.
傷を開き直してばかりだな。
三枝は、保全した。
望月は、画面を見て言った。
「必要なら開きます」
山崎が頷いた。
「閉じたふりをした傷は、治りません」
久我が言った。
「セキュリティでも同じです。誤った解決は、未解決より危険なことがあります」
営業部長が言った。
「取引先対応でも、そうです」
三枝は時系列表に入力した。
18:30 不明差出人より件名“Reopened”のメール受信。自動解決済みチケット再オープン・再確認に反応した可能性。“傷を開き直してばかり”と記載。対応方針:疑わしい解決済みは再確認し、誤った解決を放置しない。
保存。
午後八時。
その日の最終会議で、山崎はまとめた。
ホワイトボードには、今日の言葉が並んでいる。
解決済みの嘘返信したことと、解決したことは違う。解決済み ≠ 確認済み低い箱へ落とす/早く閉じる自動返信は受付確認に限定する誤った解決は、未解決より危険なことがある
山崎は言った。
「昨日は、問い合わせ箱に声を流し込む攻撃でした。今日は、その声を誤って安心させ、閉じる攻撃でした」
望月が頷いた。
「解決したように見せる」
「はい」
営業部長が言った。
「問い合わせ対応では、件数を減らすことが目標になりがちです。でも、今回は件数を減らすこと自体が攻撃に使われました」
山崎は答えた。
「その通りです。危機対応では、閉じることより、正しく確認することが優先されます」
三枝は、全員の発言を記録した。
会社は、また一つ学んだ。
閉じることは、解決ではない。
解決とは、相手と現実に届いた確認の積み重ねだ。
午後十時。
三枝は、一人でTrustDeskの「再確認中」キューを見ていた。
まだ多い。
だが、もう沈んでいない。
見える場所に戻ってきた。
問い合わせは、声だ。チケットは、その声を入れる箱だ。分類は、声を聞く順番だ。自動返信は、会社の第一声だ。解決済みは、終わりではなく、相手と確認して初めて近づく。
三枝は、自分のノートに書いた。
問い合わせを閉じるとは、声を止めることではない。相手がもう迷わない状態にすることだ。
保存。
山崎が、背後から言った。
「今日の結論ですね」
三枝は振り返った。
「問い合わせ対応って、難しいですね」
山崎は頷いた。
「はい。特に危機対応では、問い合わせ対応そのものが防御線です」
「件数を減らすのが仕事じゃない」
「本物の不安を拾い、正しく返すことが仕事です」
三枝は、静かに頷いた。
午前零時。
三枝は、時系列表の最後に入力した。
00:00 TrustDeskでResolvedチケット384件を確認し、一部に当社方針と矛盾する自動返信が送信されていたことを確認。external-support-opsにより02:58に自動返信テンプレート3件が改変され、偽ポータル利用、電子署名付き文書追加確認不要、ePOD単独配送完了等を案内。さらに重要度BのAuto-closeが24時間から15分へ短縮されていた。重要カテゴリの自動解決を停止し、受付確認のみへ変更。自動解決済み469件を再オープン・再確認し、重大二次被害につながり得る問い合わせを救出。誤返信訂正、問い合わせ応答統制、BPO終了管理を開始。
保存。
画面右下。
保存しました。
三枝は、自分のメモにも一行追加した。
閉じることより、確かめること。解決済みという言葉に、嘘を住ませない。
保存。
第三会議室の外では、倉庫が静かに動いていた。
箱は閉じられる。荷物は出荷される。問い合わせも、いつか閉じられる。
だが、閉じる前に確認する。
そこに、本物の声が残っていないか。
まだ迷っている人がいないか。
会社は、解決済みという言葉を、もう簡単には信じない。







コメント