この章で分かること: 複数の顧客のデータを1つのシステムで預かるとき、なぜデータが「混ざる」のか。その本当の原因と、混ざらないようにする2段構えの対策。
聴く台本
複数の会社のデータを、ひとつのシステムでまとめて預かる。これをマルチテナントって言うんだ。テナントっていうのは「借り主」、つまり一人ひとりの顧客のこと。ビルにいろんな会社が入居しているのを思い浮かべるといい。問題は、隣の部屋のデータが自分の部屋に漏れたら大事故だ、ということ。AIに業務データを預ける事業では、これが起きたら一発で信用を失う。会社が即死する。
じゃあ、どうやって分けるか。いちばん固い方法は「物理分離」だ。顧客ごとに、まるごと別の箱を用意する。一人の顧客に対して、専用のデータベースをひとつ。隣と物理的に繋がっていないから、コードがどう動いても隣のデータには届かない。これが土台になる。
ところが、ここに落とし穴があった。実際に「データが混ざるかもしれない」という懸念を調べてみたら、原因はコードのバグじゃなかったんだ。仕組みは正しかった。じゃあ何が危なかったか。顧客を増やすたびに、秘密の鍵を人間が手で貼り付ける作業だ。新しい顧客を追加するとき、その顧客のデータベースに繋ぐための鍵を、だいたい十個くらい、手でコピーして設定ファイルに貼る。このとき、二人目の顧客の設定欄に、うっかり一人目の顧客の鍵を貼ってしまったら、どうなるか。コードは何も間違えない。間違えないまま、まるごと別の顧客のデータベースに繋ぎにいく。
ここが本質だ。物理分離は「コードが顧客を取り違えない」ことは保証してくれる。でも「人間が正しい値を入れる」ことまでは保証してくれない。だから、いくらコードのバグを探しても直らない。バグじゃないんだから。危険は、仕組みそのものじゃなく、仕組みを動かすための設定を、誰がどう入れるかという運用のところに宿っていた。
この教訓は一般化できる。データが混ざる心配が出たら、まず「分ける仕組みは正しいか」を疑いたくなる。でも本当に問うべきは、「分けるための鍵が、ちゃんと正しい相手を指しているか」なんだ。仕組みの正しさと、運用の正しさは、別の話だ。
じゃあ対策はどうするか。二段構えになる。
ひとつめは「予防」。鍵を手で貼る作業そのものを、消してしまう。人間が手で触る工程がなくなれば、貼り間違いも起きない。これが根っこからの解決、つまり根治策だ。自動化して人手をゼロにする。
ふたつめは「検出」。予防が完成するまでの間、もし間違いが起きても、それを途中で見つけて止める仕組みを置く。具体的には、顧客に答えを返す直前に「いま繋がっている相手は、本当にこの顧客で合っているか?」を実物と照らし合わせる。もし食い違っていたら、答えを返さずにそこで止める。
この「異常があったら止める」という設計を、フェイルクローズドって言う。フェイル、つまり何か失敗や異常が起きたとき、システムを「開いたまま」、つまり処理を続けるんじゃなく、「閉じる」、つまり止める側に倒す、という意味だ。迷ったら止める。混ざるくらいなら、答えを返さないほうがマシ、という思想だね。予防が工程を消して、検出が消し残しを止める。この二段で守る。
ただし、ここでもう一段深い落とし穴がある。混ざりかけたことを記録に残そうとすると、その記録、つまりログに、繋ぎ先のアドレスや秘密の鍵そのものが書き込まれてしまうことがあるんだ。そうすると、安全のために作ったはずのログが、今度は秘密情報を平文で残す新しい漏れ口になる。対策のために足した仕組みが、別の穴を開ける。これはセキュリティでくり返し起きるパターンだ。だから鉄則がひとつ増える。セキュリティの仕組みをひとつ足すたびに、「この仕組み自体が、新しい漏れ口にならないか?」を問うこと。ログも、監査記録も、エラー出力も、ぜんぶ「安全のため」に作られる。でも中身に秘密が混じれば、逆効果になる。
最後に、事業としての構えも押さえておこう。人間が運用する以上、ミスを完全にゼロにはできない。最初のミスは、いつか必ず起きる。だったら発想を変える。「ミスをゼロにする」んじゃなく、「最初の必ず来るミスを、いちばん被害の小さいところで起こす」。顧客のデータを、機密度で色分けするんだ。緑、黄色、赤、そして永久にダメなもの。いちばん安全な緑のデータから預かりはじめる。緑で無事故の実績を積んでから、黄色、赤へと上げていく。これは、リスクを時間軸でばらまく設計だよ。いちばん危ない時期、つまり運用がまだ固まっていない初期のミスを、いちばん軽いデータにぶつける。そうすれば、致命的な漏れを構造的に避けられる。
この章のまとめ（3点）
- データ混入の真因は、コードのバグより「運用（鍵の手貼り）」に宿る — 仕組みの正しさと運用の正しさは別物
- 対策は二段構え — 予防（人手ゼロ化＝根治）＋ 検出（fail-closed＝異常なら止める）
- 対策が新しい穴を開けないか常に問う（ログ漏れ）／最初のミスは軽いデータで起こす（段階導入）
元ノート（arscontexta）
- マルチテナント混入の真因はコードのバグではなく顧客追加ごとに秘密鍵を手で貼る運用ミスでありゼロ化が根治策になる
- RAG応答前に接続先テナントを実体照合しfail-closedで止める設計は秘密鍵貼り間違いによる混入を検出できる
- セキュリティ対策のログ自体が新たな漏洩経路にならないかを常に問う
- 段階的データ預かりは最初の必然的ミスを被害の小さい低機密データで起こしリスクを時間軸で分散する