概念

テナント分離（Tenant Isolation）

1つのシステムを複数のテナントで共有しつつ、データ・履歴・生成物を利用者ごとに分離する設計原則。

テナント分離とは、1つのシステムを複数の利用者（テナント）が共有しながら、各テナントのデータ・プロジェクト・履歴・生成物を、他のテナントから参照・変更できないように分離する設計原則です。Kurageシリーズでは、公開Webサービスを kurage.exbridge.jp の PHP ゲートウェイに集約し、共通のX（旧Twitter）認証を基盤にこの分離を実現しています。

Kurageでの実装方式

Kurage の公開Webサービスは、kurage.exbridge.jp のPHPゲートウェイ（kurage-php-gateway）がXログインを検証し、確認済みのXユーザー名を内部 FastAPI バックエンドへ渡します。バックエンドはそのユーザー名をテナントIDとして扱い、SQLite台帳のテナント列や保存ディレクトリを分離します。

1テナント = 1 Xアカウント: ktajp（TradingAgents-JPのマルチユーザー版）や kfinanalyst（金融レポートSaaS）がこの方式を採用。PHPプロキシが検証済みユーザー名を X-Ktajp-User／X-Kfinanalyst-User のようなヘッダーと共有トークンで渡し、ブラウザへAPIトークンを公開しません。
プロジェクト単位の分離: karchitect は公開Web版でユーザーごとにプロジェクトを分離し、ブラウザへ内部トークンを渡さない構成です。
履歴・生成物の分離: kproofread は照査履歴と生成ファイルをログイン利用者ごとに分離します。
認証を2か所に置かない: kseo はX認証とCSRFを public/kseo.php だけに持ち、FastAPI側は内部トークンのみを検証します。
顧客サイト向けの読み取り分離: kurl2gr は、顧客サイトへ置く表示専用PHPが site_key で自分の記事だけを読む方式を採用。データベースやバックエンドを顧客サーバーに置かず、書き込み権限も不要にします。

なぜ必要なのか

マルチテナントSaaSでは、テナント間のデータ漏洩は致命的な信頼喪失につながります。Kurage がテナント分離を重視する理由は次のとおりです。

機密性: 金融レポート、文書校正結果、取引履歴、ウォッチリストは利用者自身のもの
説明責任: 誰がどのプロジェクト・履歴・課金を所有しているかを明確にする
課金との整合: 利用者単位のクレジット消費（例: ktajp の1分析=1クレジット、kurl2gr の調査1回=1クレジット）を正しく集計する

設計上のポイント

認証と分離の一体化: Xアカウントという強固な本人確認を使い、パスワード管理の負担を避けつつテナントを特定します。
境界の明示: テナント分離はtrust-boundaryの一部です。バックエンドはPHPゲートウェイからの検証済みユーザー名と共有トークンだけを信頼し、それ以外の経路を拒否します。
データベース分離: kfinanalystの「方式B（1プロセス・1SQLite台帳）」のように、テナント列を持つ共有台帳か、テナント単位の保存領域で分離します。
フロントエンド非公開: ブラウザにAPIキーや内部トークンを直接渡さず、kurage-php-gateway を中継して分離を維持します。

出典

kurage-repos — Kurage主要プロダクトのREADME集約。各サービスのテナント分離方式が記載されています。
kurage-lps — Kurage製品LPの概要

テナント分離（Tenant Isolation）

Kurageでの実装方式

なぜ必要なのか

設計上のポイント

関連する概念

出典