ブログ

ポータル、サブアカウント、入れ子型組織 — 研修事業者にとってのマルチテナントの問い

ポータル、サブアカウント、入れ子型組織は別物です。どれを採るかが、クライアントに何をいくらで売れるかを決めます。

The Lurno teamAugmental2026年8月25日1 分で読めます

研修事業者が、自社ブランドのアカデミーを望むクライアントを獲得したとき、それが午後いっぱいの設定作業で済むのか6週間のプロジェクトになるのかを決めるのは、その下にあるプラットフォームのアーキテクチャです。マルチテナンシーとして売られているものは3種類あります。ポータル、サブアカウント、そして本当の意味で入れ子になった組織です。クライアントに独自のドメイン、独自の管理者、独自のレポート、そして開発者がフィルターを書き忘れても保たれるデータの境界を与えられるのは、3つ目だけです。

この区別は、クライアントがそのモデルでは表現できないものを求めてくるまで、ベンダーの豆知識のように読めます。求められた瞬間、これは商売の問題になります。何を売れるかは、何を分離できるかで決まるからです。

クライアントが実際に求めるもの

要件定義書を削ぎ落とすと、4つの要望が残ります。だいたいこの順番で届き、自社の人員の研修に対価を払うクライアントのほぼ全員がこれを求めます。

自社のドメイン。 `yourcompany.lms-vendor.com/acme` ではなく `learn.acmecorp.com`。しかもブラウザが文句を言わない証明書付きで。
自社の管理者。 まずあなたにメールを送らなくても、ユーザーを追加し、コースを公開し、レポートを取得できる、クライアント側の担当者。
自社のレポート。 自社の人員だけについての数字を、自社の役員会に出せる形で。
他のクライアントのデータからの分離。 たいていはセキュリティの質問として尋ねられ、購買部門が必ずエスカレーションする項目です。

どのアーキテクチャも、このうちのいくつかには答え、いくつかには答えられません。どのモデルの上に立っているかがわかれば、その失敗は予測できます。

マルチテナンシー

1つの稼働中のシステムのインスタンスが多数の顧客組織にサービスを提供し、各組織には自分のデータ、ユーザー、ブランディング、設定だけが見える状態。テナントはコードとインフラを共有しますが、レコードは共有しません。判定基準は、テナントごとに違うロゴが出せるかどうかではありません。あるテナントのデータに、別のテナントのセッションから何らかの経路で — 誤操作を含めて — 到達できてしまうかどうかです。

3つのアーキテクチャ、3つの天井

以下の3つのモデルは、成熟度の階段ではありません。買い手が違えば製品も違うというだけの話で、それぞれに、そこで止まるという明確な地点があります。

ポータル

ポータルとは、共有されたコンテンツとユーザーの山に対する、別の入口です。オーディエンス — 従業員、パートナー、1つのクライアント企業 — を定義し、URL とテーマを与え、人を割り当てます。いくつかの企業向けプラットフォームがこの形を中心に作られており、最もわかりやすい例が LearnUpon です。マルチポータルでの配信が製品の中核になっています。

ポータルは1つ目の要望にうまく答えます。クライアントは自社らしく見える入口を得られ、ログインした学習者がほかのオーディエンスを目にすることはありません。1つのアカウントから従業員、パートナー、顧客を研修する企業にとって、たいていはちょうど良い量の構造です。

ポータルの一覧はフラットで、止まるのはそこです。3つの地域とグループ全体の研修責任者を持つクライアントは、1つのポータルではなく、かといって無関係な3つでもありません。フラットなモデルを使う事業者は、足りない階層を名前に埋め込むことになり — `Acme`、`Acme - EMEA`、`Acme - APAC` — そして四半期ごとに、グループ全体のビューをスプレッドシートで手作業で組み立て直します。管理者ロールにも同じ問題があります。権限はポータル単位で付与されるため、グループの責任者には3件の付与が生まれ、ある地域が閉じたときに、それを取り消すことを誰も覚えていません。

Lurno

クライアントは、自身の地域を内包する1つの組織です。だから最上位で与えたロールはその下すべてに適用され、グループ全体のレポートは親ノードそのものです。

Not this

クライアントが、たまたま同じ接頭辞を共有するフラットな一覧の3行で、グループ全体のレポートが誰かに四半期ごとに作り直されるスプレッドシートである、ということではありません。

サブアカウント

サブアカウントは、たいていデータモデルではなく課金システムに由来します。支払いを行う1つのアカウントが子アカウントをいくつか所有し、通常は1階層の深さで、ユーザーテーブル、サブスクリプション、そしてしばしば1つのドメイン（子ごとにパスを分ける）を共有します。TalentLMS は、これがテナントごとのカスタムドメインを備えた完全なマルチテナンシーより軽い分離であることを率直に認めており、従業員を研修する小規模チームにとって、その軽さは欠陥ではなく利点です。

尋ねる価値のある問いは、境界がどこで強制されているかです。サブアカウントが行の1列にすぎないなら、分離とは、アプリケーションのコードが忘れずに絞り込んだ範囲でしかありません。

-- アプリケーションのコードの中にある境界
select * from enrolments where account_id = :current_account;

-- データベースの中にある境界
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

1つ目のクエリは、誰かが新しいエクスポートのエンドポイントを作り、`where` 句を書き忘れるその瞬間まで正しいままです。2つ目はいずれにせよ正しいままです。データベースが行を返すことを拒むからです。購買部門が、クライアントのデータをどう分離しているのかと尋ねるとき — たとえ認証や監査の語彙で尋ねてきたとしても — 探り当てようとしているのは、この差です。

サブアカウントはテナントと同じものですか

いいえ。サブアカウントは、1つのテナントの内側にあるグループ分けと課金の仕組みです。たいていは親のユーザーテーブル、ドメイン、設定、そしてしばしば管理者を共有します。テナントは境界です。独自のドメイン、独自の管理者、独自のブランディング、そして独自のデータを持ち、コードが適用するフィルターではなく、システムが強制するルールによって分離されています。プラットフォームがサブアカウントを備えていても、クライアントのセキュリティ審査にとって重要なあらゆる意味で、依然としてシングルテナントであることはあり得ます。

入れ子型組織

3つ目のモデルでは、組織が第一級のレコードであり、組織は親を持てます。ブランディング、ドメイン、ユーザー、ロール、コンテンツ、受講登録、レポートは、すべてそこにぶら下がります。あなたの研修会社は1つの組織です。各クライアントは、あなたの組織の中にある組織です。クライアントの各地域は、そのクライアントの中にある組織であり、実際の組織構造の深さのぶんだけ入れ子にできます。

Your training company              you administer everything below
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  regional admin, EMEA data only
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Public catalogue               open enrolments, your brand

ここから、フラットなモデルでは得られない2つのことが導かれます。1つ目は、クライアント自身の構造を、命名規則なしで表現できることです — 階層を文字列に埋め込む必要がありません。2つ目はスコープです。あるノードで付与したロールは、そのノードの下すべてに適用されます。Acme の研修責任者は Acme と両方の地域を見ます。EMEA のマネージャーは EMEA を見ます。あなたはそのすべてを見ます。Borden の誰も、そのどれも見ません。そしてそのどれも、誰かが手作業で書いたレポートではありません。

解約時の作業の意味も変わります。フラットなシステムからクライアントが離れるときは、誰かがポータル、ユーザー、グループ、レポートのチェックリストを上から順にたどり、そのリストに漏れがないことを願います。クライアントが部分木であれば、その部分木を削除すれば、ぶら下がっていたものはすべて一緒に消えます。

4つの要望に、各モデルはどう答えるか

自社のドメイン。 ポータル：たいていは可能で、ポータルごとに1つ、追加費用がかかることもあります。サブアカウント：クライアント自身のドメインではなく、ベンダーのドメインのパスかサブドメインであることが多い。入れ子型組織：プラットフォームが証明書を自動発行するなら、任意の深さで、組織ごとに1つのドメイン。
自社の管理者。 ポータル：可能ですが、そのポータル1つにスコープされるため、グループ全体の管理者にはポータルごとの付与が必要です。サブアカウント：たいていは親の管理者に、絞り込まれたビューを与える形。入れ子型組織：任意のノードに管理者を置け、その権限はノードの下すべてへ継承されます。
自社のレポート。 ポータル：ポータル単位で、ポータル横断の集計は製品次第。サブアカウント：たいていはフィルター付きの1つのレポートで、クライアントが自分で見たいと言い出すまでは問題ありません。入れ子型組織：すべてのノードがレポートのスコープなので、グループ全体のビューと地域のビューは、高さが違うだけの同じクエリです。
データの分離。 ポータルとサブアカウント：アプリケーションのコードが分離した範囲まで。入れ子型組織：プラットフォームがアプリケーションより下の層で強制した範囲まで — そのルールがデータベースにあるのかどうかを、名指しで尋ねてください。

これはポータルが間違っているという話ではありません。買い手が違えば製品も違う、という話です。間違いは、デモでロゴの差し替えを見せられたからポータル型のモデルを買い、地域を持つクライアントと契約した日にその天井を知ることです。

ベンダーにぶつける5つの質問

組織は別の組織を内包できますか。また、どこまで深くできますか。
あるノードで誰かに管理者ロールを付与した場合、それはその下すべてに適用されますか。それとも各階層で付与し直しますか。
テナントの境界は、データベースで強制されていますか、それともアプリケーションのコードで強制されていますか。
クライアントごとに独自のドメインと独自の証明書を持てますか。それとも御社のドメインのサブディレクトリだけですか。
クライアントが離れるとき、削除操作で正確に何が消えますか。そして、それを実際に見せてもらえますか。

答えは通話ではなく、共有ドキュメントで求めてください。特に2つ目の質問は、答えではなく画面のデモが返ってきがちです。そしてその両者の差は、1年分の手作業の権限付与です。

その答えが、何を売れるかを決める理由

プラットフォームが1つの入口にテーマを当てることしかできないなら、売っているのは自社システムの席です。クライアントの従業員はあなたのブランドにログインし、クライアントの研修責任者はあなたに数字を求め、更新のたびに、あなたのプラットフォームのユーザー単価についての会話になります。

クライアントにドメイン、管理者、レポート、そしてセキュリティ審査に耐える境界を渡せるなら、売っているのはそのクライアント自身のアカデミーです。それは別の契約です。更新の仕方も違います。その頃にはクライアントに自分たちの管理者がいて、自分たちのやり方が根づき、自分たちのコンテンツがその中にあるからです。そして、先方の担当者が代わっても契約は生き残ります。

もう半分は運用の話です。フラットなモデルでは足りなくなった事業者は、クライアントごとに1つのインストールを運用することになりがちです。Moodle は、マルチテナンシーがコア製品の一部ではないことを明言しています — キャンパスやクライアント組織を分けるということは、Moodle Workplace か、パートナー契約か、並行インストールを意味します。並行インストールは、並行するアップグレード、並行するバックアップ、並行するセキュリティパッチ、そしてプラットフォームの外に作り直すレポート層を意味します。これは、クライアントより従業員のほうが多いあいだは機能します。

クライアントごとに別のインスタンスを立てればよいのではないですか

できますし、それは実際、手に入るなかで最もきれいな分離です。コストはライセンスではなく運用です。クライアントが1社増えるたびに、テストすべきアップグレード、検証すべきバックアップ、回すべきパッチのサイクル、管理すべき認証情報が1式ずつ増え、クライアントをまたぐ問いはすべてシステムの外で答えることになります。個別インスタンスが理にかなうのは、クライアントの規制当局がそれを要求する場合です。成長中の事業者の既定のモデルとしては、契約を1件決めるたびに保守の負荷が上がっていきます。

研修事業者には実際いくつのテナントが必要ですか

独自のブランド、独自の管理者、あるいは独自のコンプライアンス義務を持つクライアント組織ごとに1つです。それより下の層は、クライアントのテナント内のサブ組織が、地域、部門、コホートを扱います。事業者がこれを間違えるのは、たいてい一方向です。コースごとやコホートごとにテナントを作ってしまい、分離の利点は何もないのにブランディング、ドメイン、管理作業だけが増える。クライアント自身のツリー内のノードで、同じ仕事ができたはずなのに。

Lurno の立ち位置

Lurno は3つ目のモデルの上に作られています。組織はサブ組織を内包でき、それぞれが独自のブランディングと、自動 TLS 付きの独自のカスタムドメインを持てます。組織の内側にはブランチという2つ目のツリーがあり、ある枝で付与した役割はその下へ継承されます — これが上のベンダーへの2つ目の質問への答えであり、グループ全体の研修責任者が、地域ごとに1件ではなく1件の付与で済む理由です。

境界はアプリケーションではなく Postgres で強制されています。676 のマイグレーションにわたる 868 の行レベルセキュリティポリシーがあり、新しいエンドポイントでフィルターが抜けていれば、他人の学習者を返す代わりに何も返しません。これは、どのベンダーに対しても — 私たちに対しても — 確かめる価値のある主張です。詳細はセキュリティのページに、ブランディングとドメインの側はホワイトラベルにあります。

社名は伏せますが、これがすでに動いている形が2つあります。1つのテナントから 15 のクライアント企業向けに研修を運営する企業内アカデミーと、単一のプラットフォーム上で 114 校を運営する K-12 の出版社です。どちらも、幅が違うだけの同じ構造です。

率直に書いておくべき制約が2つあります。評価を左右するからです。決済とチェックアウトは開発中です — 現時点でクライアントへの請求はプラットフォームの外で行うため、受講登録の時点で学習者にカードで支払ってもらう必要があるなら、それは機能ではなく話し合うべきことです。そしてパートナーサインオン（サイレント SSO）は利用できますが、SAML と OIDC はロードマップ上にあり、提供されていません。クライアントの情報システム部門が、従業員の認証方法をすでに決めているなら、まず何よりも先にその点を尋ねてください。研修を再販する事業者向けのモデルの残りの部分は、研修事業者向けのページにまとめています。

要約

ポータルはクライアントに入口を与えます。サブアカウントはクライアントに絞り込まれたビューを与えます。入れ子型組織はクライアントに境界を与え、値段を付けられるのはその境界です。自分のモデルでは言えないことをクライアントに求められる前に、自分が買っているのがどれなのかを見極めてください。