相席か個室か。1つの仕組みを何社で使うかを図にした

• 共有するかどうかは0か1ではない。層ごとに決められる
• 構成は大きく4つに分かれる
• どれを選んでも引き受けるものがある。有利な選択肢は無い

複数の会社が同じ仕組みを使う形を、どう組むか。「全部分ける」か「全部まとめる」かの二択だと思っていたが、層ごとに決められると知って見通しが変わった。

まず「誰が1件か」を決める

設計の前に決めるのは、技術ではなく何を1件として数えるかになる。

相手が会社なら、会社ごとに1件が素直になる。ただし部署ごとに要件が違う場合や、検証用と本番用を分けたい場合は、1社が複数件になる。

相手が個人なら、もっと難しい。家族やグループで一緒に使う可能性があるなら、個人＝1件では足りなくなる。

ここを曖昧にしたまま進めると、後から分けられなくなる。

4つの構成

「全部専用」の費用は想像より重い

解説の表現が的確だった。1社に必要な費用があるなら、100社ではおそらく100倍になる。

さらに、設定変更や更新といった継続的な作業も顧客数ぶん発生する。顧客をまたいだ集計をしようとすると、それも別の仕組みが要る。

「全部共有」は限界が先に来る

逆に、全部共有は安いが規模の上限に当たりやすい。

そして指摘されているのは、費用が直線的に増えるとは限らないことだ。1つの大きなデータベースを高い負荷で動かすと、必要な処理能力を上げるための費用が、途中から急に重くなる。

「隣がうるさい」問題

共有したときの典型的な困りごとが、これになる。1社が重い処理を流すと、他社の応答が遅くなる。

対処としてまとまっているのが横に分ける構成だ。負荷の大半を生んでいる層だけを個別にすれば、そこで止まり、共有している層まで響かない。

多くの場合、負荷が集中するのはデータを扱う層になる。画面は共有、データは個別という組み合わせが現実に多いのは、この理由による。

どの層が重いのかを先に測る話は索引の仕組みや処理の種類の違いに書いた。分ける前に、どこが重いかを知るのが順番になる。

決めるときに見るもの

解説では、技術だけの決定ではないと念を押されている。見る項目はこうなる。

• 事業の目標 — 1件あたりの費用を下げたいのか、体験を良くしたいのか
• 規制対応 — 顧客が共有を受け入れるか
• 規模 — 専用のままで将来の成長に耐えるか
• 自動化 — 運用する人数で、どこまで回せるか
• 約束した水準 — 稼働率などをどう保証するか

4番目が見落とされやすい。専用を選ぶなら、構築と更新を自動で回せることが前提になる。手作業のままで顧客数を増やすと、運用が先に破綻する。

最後に必ずやること

どの構成を選んでも、締めは同じになる。他社のデータが混ざらないことを、試験で確かめる。

共有している場合、分離はコードと識別子で保たれている。つまり間違えれば混ざる。「混ざらないように書いた」ではなく、混ざらないことを試す必要がある。

確かめ方は単純で、他人の番号を指定してみる。自分のものではない識別子を指定して、何が返るかを見る。

まとめ

• 設計の前に何を1件として数えるかを決める
• 構成は全部共有／横に分ける／縦に分ける／全部専用の4つ
• 全部専用は、顧客数ぶん費用も手間も増える
• 全部共有は安いが、規模の上限に当たる。費用も途中から重くなる
• 隣の影響を抑えたいなら重い層だけを個別にする
• 最後に他社のデータが混ざらないことを試験で確かめる

出典

• Microsoft Learn「マルチテナント ソリューションのテナント モデル」（1件の定義、4つの構成とそれぞれの利点・危険、分離の連続性、判断材料、試験の必要性。2026年10月13日に確認）

図は本記事のために作成したもの。