📣

Resilire Tech News 2025/11/14 — 作成者/更新者とRLS整理

に公開
resilire
technews
idea

サマリー

今週の社内ソフトウェアミーティングで注目されたのは「DBの作成者/更新者カラムをIDで持つかどうか」と「RLS（Row-Level Security）のロジックの整理」です。
ほかにESLint周りで消えたLintルールの話、barrel file（indexでexportをまとめるパターン）を削除して得られた恩恵、クライアント側のQueryライブラリのRetry挙動に関するログ改善の話題が出ました。

メインは、DB設計とセキュリティ境界の整理でした。

注目ポイント

  • CreatedBy/UpdatedByはユーザー名ではなくユーザーIDで統一する

    • 以前はIDベースだったが、アプリ側の循環参照を避けるため名前ベースへ移行していた経緯がある。
    • IDベースに戻すメリットとして、GDPR対応のしやすさや参照整合性の確保が挙げられる。
    • 課題は削除済みユーザー・論理削除ユーザー・権限で表示できないユーザーの扱い方。
    • 今後はADRを起票し、PdMも含めてデータモデルの扱い方を合意形成する方向。

  • RLSの適用範囲の"設計"を見直し、整理する方針

    現状、一部の内部処理やバッチ処理で、RLSが必要なシーンと不要なシーンが混在している。
    見直しの目的は、どの処理でRLSを用い、どの処理では別の仕組みで要件を満たすべきかを整理することだ。
    これにより、より安全で一貫した体系へ整理していく。

    • 基本方針として、"RLSを前提としたテナント隔離"を維持する。
    • バッチ処理や内部処理では、要件に応じた専用の安全なアクセス設計で扱う

  • 開発体験とコード品質の改善が進んでいる。

    • 以前にあったBool命名規約（has_xxx/is_xxx等）のLint設定がリファクタやアップデートで消えてしまった事例があり、必要なLintは復活させる。
    • barrel fileの削除により未使用コード検出やテストの差分実行がやりやすくなった恩恵があった。
    • TanStack Queryのretryデフォルトをfalseにする案があり、リトライ状況をログに残して把握したい。

社内MTGでの様子（雑感と細かい流れ）

  • 「ユーザーIDで保持したい」という発言がきっかけで議論が始まった。過去にID→名前へ変えた背景も共有されて理解が深まった。
  • 削除済みユーザーの扱いをどうするかで活発な議論が起きた。DBから完全削除するケース、論理削除で残すケース、権限上表示できないケースなどでどう運用するべきなのかパターンを整理する必要がありそう。
    • 「大変だけど、運用安全性が大きく高まる良い取り組み」という認識が共有された。
    • RLSが不要な処理や前段とサブスクライバで接続ユーザーが異なる歴史的事情のある経路は個別に対応が必要であり、テーブル設計やRLSルールの調整で対処する案が出ている。

最後に

今週のキーワードは「境界線の整理」でした。

•	データの持ち方（CreatedBy/UpdatedBy）
•	RLSと他のアクセス制御の役割分担
•	権限制御の位置づけ
•	RLSが不要な処理の安全な設計方法

これらを明確にしていくことで、システムの安全性と将来の変更耐性が大きく向上します。

小さく安全に進めながら、しかし着実に技術的負債を払っていく方針が支持されています。
チームではすでにADR起票や段階的なRLSロジックの整理の作業が進行しています。

Resilireではエンジニアを募集中です。

興味のある方は採用ページをご参照ください。
https://careers.resilire.jp/

それでは次回もお楽しみに！📻

Discussion