この記事でわかること

• マルチテナントLLMアプリで最初に決める4つの論点
• 分離レベルの選び方（論理分離・スキーマ分離・インフラ分離）
• 認証・レート制限・コスト按分・監査ログの実装確認項目
• 導入前チェックリストと運用開始後に見る指標
• SaaS型LLMアプリや社内共有基盤で見落としやすい落とし穴

結論：LLMマルチテナント設計は「分離レベル×レート制限×コスト按分」で決まる

まず判断のショートカットを示します。

分離設計は、後から乗せ替えるほど高くつく論点です。稼働前に決めておくと、営業要件が変わっても改修範囲を抑えられます。

※LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。

マルチテナントLLMアプリとは？基本を整理する

マルチテナントとは、1つのアプリを複数の顧客・組織・部門で共有する運用形態です。LLMアプリでは、認証・データ・コスト・ログの分離設計が特に重要になります。

用語を先に整理します。

シングルテナント運用と比べて、次の3点が難しくなります。

• 1つの障害が全テナントに波及するリスクがある
• 顧客ごとの利用量差が大きく、コストと性能に偏りが出やすい
• 監査・権限・削除依頼はテナント単位で対応する

なぜ稼働前に分離設計を決める必要があるか

LLMアプリは実証実験（PoC）では顧客1社分で動きますが、複数社に広がると設計負債が一気に顕在化します。稼働後に分離を変えると、ログ・キー・権限・履歴を作り直しになります。

主な理由は3つです。

• 入出力ログが混在すると、後から顧客別に切り出すのが難しい
• 1社の大量利用で他社の応答遅延やAPI上限枯渇が起きる
• 月次コスト按分ができないと、粗利が把握できず契約条件に影響する

社内共有基盤でも同じ問題が起きます。「PoCで1部門用に作ったが他部門から使いたい要望が来た」段階で、分離とコスト管理が同時に課題になります。

判断軸：4つの分離レベルを比較する

分離レベルは、コストと分離の強さのトレードオフで決めます。データ機密度と契約条件で選びます。

分離を強くするほど安全になりますが、運用コストは上がります。すべてを最上位で分ける必要はありません。

以下は実務判断向けの比較です。

実装で確認すべき5項目

分離レベルを決めたら、次の5項目を稼働前に具体化します。

認証とAPIキー

LLMアプリのAPIキーは、テナントID・利用者ID・スコープの3層で管理します。テナント別のキー無効化と再発行を運用フローに組み込みます。

• キーはテナントごとに独立して失効できる
• ユーザーID単位で権限（管理者・利用者・閲覧のみ）を分ける
• LLMプロバイダー側のキー（Anthropic・OpenAI等）はアプリのキーとは別に管理する
• テナントの管理者が自分のキーを回転できる導線を用意する

レート制限とクォータ

テナント別のレート制限は、リクエスト数・トークン数・同時実行数の3軸で設計します。1社の大量利用で他社が遅くなる問題を防ぐためです。

• リクエスト/秒、トークン/秒、同時実行数のどこで律速するかを決める
• プラン別クォータをテナント設定として持つ
• クォータ超過時の挙動（キュー待機・エラー・課金加算）を明示する
• LLMプロバイダー側のレート制限も同時に確認する

コスト按分

LLMアプリのコスト按分は、モデル別トークン単価と入出力トークン数から算出します。ログにテナントIDとモデル名を必ず含めます。

• リクエスト単位で入力トークン・出力トークン・モデル名を記録する
• 月次でテナント別のトークン数とコストを集計できる
• キャッシュヒットや失敗リクエストの扱いをルール化する
• 顧客提示用のレポート項目を稼働前に決める

監査ログとデータ保持

監査ログは、入出力・時刻・ユーザー・モデルの4項目を最低限含めます。保持期間と閲覧権限は、契約と個人情報保護規程に合わせて設計します。

• 入力プロンプト・モデル出力・ユーザーID・時刻・モデル名を残す
• テナントごとに保持期間を設定できる
• 監査時の閲覧権限は最小に絞る
• LLMプロバイダーの学習利用条件を確認し、必要ならオプトアウトする

モデルとプロンプト

テナントごとに使えるモデル・システムプロンプト・コンテキスト長の上限を切り替えます。プラン差別化と誤爆防止の両方に効きます。

• モデルの利用可否をテナント設定で管理する
• システムプロンプトはテナント別テンプレートを持つ
• コンテキスト長の上限を設定できる
• テナント別のNGワードや保護対象データを設定できる

リスクと限界：マルチテナントで見落としやすい落とし穴

マルチテナント設計は、決めた瞬間に完成するものではありません。運用中に落とし穴が現れます。

• プロンプトインジェクションで別テナントの情報が漏れる：システムプロンプトや外部データ取得を挟む場合、テナント境界を超えたアクセスが起きないかを検証する
• LLMプロバイダーの上限枯渇で全テナントが止まる：API側のレート制限は組織単位で共有される。プロバイダー側でも組織上のクォータを確認する
• ログの肥大化でストレージコストが膨らむ：ログ量は指数的に増える。保持期間とサマリー化を先に決める
• 1社向けカスタマイズが他社に影響する：機能フラグとテナント設定で切り分けられない改修は本体に入れない

「後で分離すればよい」で始めたPoCが、そのまま本番に持ち込まれるのがLLMアプリ運用の最大リスクです。稼働前に採用しないラインを決めておきます。

導入前チェックリストと運用開始後の指標

稼働前に確認する項目と、運用開始後に見続ける指標を分けます。

導入前チェックリスト:

• 分離レベルを1つ選び、選定根拠を残しているか
• テナント設定として保持する項目を全て列挙したか
• 認証・レート制限・コスト按分・監査ログの実装担当が決まっているか
• 監査ログの保持期間と閲覧権限の運用ルールがあるか
• LLMプロバイダー側の利用規約とデータ保持条件を確認したか

運用開始後に見る指標:

• テナント別のリクエスト数・入出力トークン数・モデル別コスト
• レート制限到達回数とキュー待機時間
• エラー率と障害の波及範囲（1テナントか全体か）
• 監査ログのサイズと保管費用
• プロンプトインジェクション疑いの検知件数

採用しないほうがよい条件:

• LLMプロバイダー側のデータ保持条件を確認していない
• 監査ログの保持期間を決めずに稼働させる
• 1社向けカスタマイズを本体コードに直接埋め込む
• 契約プランと技術仕様が対応していない

Blackfordの見解：業務設計とデータ基盤に接続する

マルチテナントLLMアプリは、技術設計だけでなく、業務・契約・データ基盤・運用責任にまたがる設計です。Blackfordでは、次の観点で全体最適を整理します。

• 業務課題：どの部門・顧客が、どの用途で使うか
• 扱うデータ：機密度・規制・監査・保持期間
• コスト上限：契約単価と粗利の関係
• セキュリティ要件：データ保持・権限・監査・閉域性
• 運用責任者：障害対応・変更管理・レビュー頻度
• 既存クラウド・既存システムとの接続：認証基盤・監視・ログ基盤

社内ナレッジ検索やRAG（社内文書を検索して回答する仕組み）基盤としてマルチテナントを展開する場合はDataRoidやDataRoid Cloudを検討できます。営業・商談用途ではSalesRoidを選択肢に加えられます。

LLMアプリ開発の相談は、業務要件と分離設計から一緒に整理します。

よくある質問

Q. マルチテナントLLMアプリでは、テナントごとにAPIキーを分ける必要がありますか？
A. 原則として分けたほうが安全です。テナント別のキー失効やレート制限が実装しやすくなります。共通キーで運用する場合も、リクエスト時のテナントIDタグを必ず付与し、監査ログでテナント追跡ができる状態にしてください。

Q. 分離レベルは最初から最上位を選んだほうがよいですか？
A. 必ずしも最上位を選ぶ必要はありません。データの機密度・契約条件・運用コストで決めます。PoC段階では論理分離で始め、規制業種向けや大企業契約ではスキーマ分離やインフラ分離への切り替え可否を先に検討しておくと現実的です。

Q. コスト按分はモデル別トークン数で計算すれば十分ですか？
A. 基本はモデル別の入出力トークン数で計算します。ただしキャッシュヒット・失敗リクエスト・外部ツール呼び出しの費用も按分方法を決めておくと、月末の顧客提示がぶれません。

Q. 監査ログはどのくらい保持すべきですか？
A. 契約と個人情報保護規程で決まる範囲を守ります。目安は3〜12か月ですが、規制業種や訴訟リスクのある業務では長期保持が必要になる場合があります。テナントごとに保持期間を設定できる設計にしておくと運用しやすくなります。

Q. 中小企業でもここまでの設計が必要ですか？
A. 提供先が1社1部門であれば軽量な論理分離で始められます。ただし複数顧客・複数部門への展開が見えた段階で、認証・レート制限・監査ログの3点は先に整えることをおすすめします。後から乗せ替えると改修範囲が広がるためです。

まとめ

LLMアプリのマルチテナント設計は、分離レベル・認証・レート制限・コスト按分・監査ログの5点を稼働前に決めるかどうかで、後の運用コストが大きく変わります。

分離を強くするほど安全になりますが、運用負荷は上がります。用途と契約条件で選ぶことが重要です。

ただしテナント境界を超えるプロンプトインジェクションや、LLMプロバイダー側の上限共有など、運用後に見えるリスクもあります。単なる技術設計ではなく、業務要件・契約・データ基盤・運用責任と合わせて設計しましょう。

自社での設計や既存アプリのマルチテナント化に迷う場合は、業務要件とデータ整理から一緒に整理できます。

＼LLMアプリのマルチテナント化を業務要件から相談できます／
Blackfordに相談する