他社の訃報が見えてしまわない設計 ── 葬儀社ごとにデータを分けるということ

1つのシステムを複数の葬儀社でお使いいただく以上、境界を1本間違えれば、他社のご遺族情報が見えます。
2026年5月、私たちは外部の視点でセキュリティ監査を実施しました。結果は、最も重い区分で3件、次に重い区分で5件の指摘でした。この記事では、その中で葬儀社のデータを預かるうえで特に重要だった指摘と、実際に何を直したかを公開します。あわせて、業務システムを選ぶときにベンダーへ聞くべき質問を挙げます。

なぜ公開するのか

脆弱性を見つけて直したことを、わざわざ書く会社は多くありません。しかし、葬儀社の方がシステムを選ぶとき、判断材料が「大丈夫です」という言葉しかないのが現状です。

ご遺族のお名前、ご住所、ご逝去の日時と場所、宗派。これらは、他の業界で扱う顧客情報より明らかに機微です。どこまで真剣に考えているかを示すには、何を間違えて何を直したかを書くのが最も速いと考えました。

最も重かった指摘3件

1. 開発用の設定のまま動かすと、認証が丸ごと外れる

開発中は、認証を通さずに動かせると作業が速く進みます。そのため「認証を必須にするかどうか」を設定で切り替えられるようにしていました。

指摘は、その設定を切り忘れたまま本番で動かせてしまうという点でした。切り忘れれば、識別子を1つ付けるだけで、どの葬儀社のデータにもアクセスできる状態になります。

直し方は、設定の追加ではなく起動の阻止にしました。本番として起動するとき、必要な設定が揃っていなければ、その場でプロセスを終了します。中途半端に動き続けるより、起動しないほうが安全だからです。

この考え方は、あとで効いてきました。「設定を間違えたら止まる」という作りにしておくと、設定漏れが運用中に発覚するのではなく、デプロイの瞬間に分かります。

2. 電話の着信が、本物かどうか検証されていなかった

電話をつなぐ仕組みは、通話が来たときに私たちのサーバーへ通知を送ります。この通知には署名が付いていて、本物かどうかを検証できます。

問題は、開発中は検証に失敗しても警告を出すだけで、処理を続けていたことでした。これを悪用されると、実際には存在しない通話を偽装され、AIの利用料だけが積み上がる攻撃が成立します。

現在は、常に検証を強制しています。開発時に一時的に外したい場合は、明示的にそのための設定を書かなければ通りません。「うっかり外れている」状態を作らないことが目的です。

3. 通話録音のキャッシュ制御が緩かった

通話録音は、この業務で最も機微なデータです。ご遺族の声そのものが入っています。

当初の設定では、ブラウザや途中の経路に一定時間保存されうる状態でした。現在は、保存させない指定を複数の方式で重ねて付けています。共用のパソコンで担当者が録音を再生した場合でも、その端末に残らないようにするためです。

次に重かった指摘から、2件

監査ログに、電話番号がそのまま記録されていた

いつ、どこから、どんな通話があったかを記録することは、運用上どうしても必要です。しかし電話番号をそのまま書いてしまうと、ログ自体が個人情報の塊になります。ログは検索され、コピーされ、調査のために共有されます。

現在は、電話番号を不可逆な形に変換して記録しています。同じ番号からの着信は同じ値になるので「この番号から3回かかっている」という調査はできますが、値から番号を復元することはできません。調査に必要な機能は残し、復元だけを不可能にするという考え方です。

AIの詳細なエラーが、そのまま画面に返っていた

外部のAIサービスでエラーが起きたとき、その詳細をそのまま画面に返していました。開発中は便利ですが、内部の構成が推測できる情報が含まれます。現在は、詳細は記録にのみ残し、画面には一般的なメッセージだけを返します。

直していない指摘も、書いておきます

監査で挙がった項目のうち、まだ対応できていないものが2件あります。

設定ファイルに、外部サービスの認証情報が平文で残っている

葬儀社ごとの設定ファイルに、電話やチャットの連携に使う認証情報が、そのまま書かれています。本来は専用の保管庫に置き、設定ファイルには参照先だけを持たせるべきです。

影響範囲が広く、段階的な移行の設計が必要なため、別の作業として切り出しています。現時点では未着手です。

アクセス制限が、サーバー1台の中でしか効かない

短時間に大量のアクセスが来たときの制限が、サーバーの中のメモリで管理されています。サーバーを複数台に増やすと、台数の分だけ制限が緩くなります。今は1台構成なので実害はありませんが、増やす前に対処が必要です。

葬儀社の方が、ベンダーに聞くべき5つの質問

ここまでの話は、私たち固有の事情ではありません。複数社で1つのシステムを使う仕組みには、共通して同じ論点があります。次の5つは、どのベンダーにも同じように聞けます。

1. 他社のデータが見えないことを、どうやって保証していますか。「画面上で切り替えているだけ」なら、識別子を書き換えれば越えられる可能性があります
2. 設定を間違えたまま本番で動いてしまうことは、あり得ますか。「起動しません」と答えられるかどうかが分かれ目です
3. 通話録音は、どこに、どのくらいの期間、どんな形で保存されますか。暗号化の有無と、保存期間の設定可否を確認してください
4. 操作ログに、お客様の電話番号やお名前はそのまま残りますか。ログの管理は、本体のデータより手薄になりがちです
5. 外部のAIサービスに、どの範囲のデータが送られますか。どこの国のどの会社か、そしてお客様への告知はどうしているかまで聞いてください

5番目については、別の記事で詳しく書いています。音声AIでは、同意を取ることそのものが技術的な設計問題になります。

葬儀業界特有の論点

最後に、この業界に固有の点を1つ挙げます。削除のご請求です。

ご遺族から「記録を消してほしい」というお申し出があった場合、通話の録音だけを消せば済むわけではありません。会話の記録、そこから作った引継ぎメモ、ケースの情報、行政手続のために抽出したデータ。元のデータを消しても、そこから派生したものが残っていれば、消したことになりません。

私たちはこの受け口を作ってありますが、派生データまで確実に消えることの検証は、実運用が始まってから改めて確かめるべき項目だと考えています。同じ考え方を、他社にも確認されることをおすすめします。「消せます」と「全部消えます」は違います。

まとめ

• 複数社で使う仕組みは、境界を1本間違えると他社のご遺族情報が見えます
• 外部監査で最重要3件・重要5件の指摘を受けました。多くは「開発中の便利な設定が、本番でも効いてしまう」類のものでした
• 直し方の基本は、設定の追加ではなく間違っていたら起動しないことです
• ログは本体のデータより手薄になりがちです。調査に必要な機能を残しつつ、復元だけを不可能にするのが現実的な着地でした
• 未対応の課題も2件あります。設定ファイルの認証情報と、複数台構成でのアクセス制限です

ご相談ください

次のような状況でしたら、一度お話をお聞かせください。

• クラウドのシステムを検討しているが、他社と同じ基盤で大丈夫なのか判断がつかない。何を確認すればよいか分からない
• ご遺族から記録の削除を求められたときの手順が、社内で決まっていない。どこまで消せるのかを把握していない
• すでに使っている業務システムについて、上記5つの質問をしたことがない。この機会に確認したい