見せる範囲を層で設計する ── 行・列レベルの制御をどこに置くか

「誰に何を見せるか」は、どの層で決めるかによって管理のしやすさが大きく変わります。

実現方法を並べると、単純なものから柔軟なものへという順に並びます。柔軟になるほど、管理と把握が難しくなります。

最下2行が強力ですが、把握が難しい。同じ表を参照しても、人によって結果が違います。これが便利さの源であり、同時に最大の難点でもあります。

最初から柔軟な方式を選ばないでください。必要になってから移行するのが原則です。

3行目が移行の境目です。人数分の表を作れなくなったら、制御に移ります。逆に言えば、表の数で管理できるうちは、そのほうが分かりやすい。

この判断は Snowflake 実践ハンドブック EP.08 で扱ったロール設計と同じ構造です。最初は少数から始め、実際に困ってから分ける。

最も重要な原則です。制御を複数の層に分散させない。分散すると、全体として誰が何を見られるかを、誰も説明できなくなります。

3行目と4行目が実際によく起きます。「念のため両方に入れておく」という判断の結果です。安全側に見えますが、どちらが効いているか分からなくなり、変更もできなくなります。

原則は、データベース側に寄せることです。直接接続されても効くのはこの層だけだからです。アプリ側の制御は、利便性のためのもの（見せない項目を出さない）と位置づけ、安全性はデータベース側で担保します。

制御方式の最大の難点は、存在が見えないことでした。これは明示的に可視化するしかありません。

1. 1どの表に、どの制御がかかっているかを一覧化する
2. 2制御の定義をコードで管理する — 画面で設定して終わりにしない
3. 3利用者に「絞られている」ことを伝える — 件数の脇に注記など
4. 4制御を含めたテストを書く — 役割ごとに期待する結果を確認
5. 5定期的に棚卸しする — Snowflake EP.08 と同じ

3番目が実務では効きます。利用者が「自分は絞られた結果を見ている」と知っているだけで、数字の食い違いの調査が大幅に短縮されます。

この一覧を定期的に出力して、想定と一致しているか確認してください。設定は増えていきます。「いつの間にか制御が外れていた」「意図しない表に制御が入っていた」を検知できます。特に前者は見えすぎる方向の誤りなので、指摘されるまで気づけません。

個人情報などの機微な列は、列レベルの制御か マスキング（Data Masking） で扱います。方式によって性質が違います。

3行目が検証環境で重要です。Snowflake EP.07 で扱ったとおり、本番の複製には本番と同じ機密性があります。置き換えたうえで配ると、開発の利便性と安全性を両立できます。

ただし一貫した置き換えであることが条件です。同じ人が常に同じ偽名になるようにしないと、結合や集計の検証ができません。ランダムに置き換えると、開発環境として使えなくなります。

最後に、設計の順序をまとめます。

1. 1まず表を分けられないか考える — 単純さは価値
2. 2分けられないなら、制御を検討する — 人ごとに違うなら行、列だけなら列
3. 3置き場は一箇所に決める — 分散させない（データベース側に寄せる）
4. 4設定を一覧化して定期確認する — 増えるものは棚卸しが要る
5. 5利用者に「絞られている」ことを伝える — 調査の短縮になる
6. 6制御を含めたテストを書く — 役割ごとの期待結果

6番目を忘れないでください。制御の設定を変えたときに、意図しない範囲が見えるようになっていないかを確認する必要があります。LLM時代のテスト戦略 EP.05 で扱ったリグレッションの対象として、最も影響の大きい部類です。見えすぎる方向の誤りはエラーにならず、指摘されるまで気づけません。