Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ToB TocマルチテナントSaaSのデザイン設定での学び

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
Avatar for gonta gonta
July 28, 2026
37

ToB TocマルチテナントSaaSのデザイン設定での学び

Avatar for gonta

gonta

July 28, 2026

Transcript

  1. LT / 5 min マルチテナント SaaS のデザイン設定 テナントごとのデザインを、どう設定させるか ToBToC マルチテナント

    SaaS のデザ イン設定について 大塚(gonta) フリーランス / 習い事の事業者向け SaaS「makasta」を開発 2026.07
  2. 02 前提:マルチテナント SaaS とは 1 つのアプリケーションを複数の顧客(テナント)が共有して利用し、それぞれのデータや設定は分離されている 仕組み。 事業者から見ると 自社専用のサービスのように使える。他社のデータは見えない。 その一方で、

    画面を作るコードは全テナントで 1 つ。ここが今日の話の出発点。 さらに ToBToC なら、登場人物は 3 層 運営 プラットフォーム提供 → ToB 事業者(例:ネットショップ) 身近な例 — テナントの分け方は URL に現れる ネットショップ( STORES / BASE) フィットネス習い事( hacomono) 店舗ごとにカスタムドメインや、サブドメインを使える shop-a.com / shop-b.jp → ToC 各事業者のお客様
  3. 03 ToB ToC のマルチテナント SaaS でほぼ必ず出るであろう話 事業者(ToB)に管理画面を渡し、その先のエンドユーザー(ToC)へサイトを公開する構造。 この形だと「事業者ごとに見た目を変えたい」という要望はほぼ必ず 出てくる。 事業者(

    ToB) 運営(プラットフォーム) 1 つの SaaS を提供 共通の基盤・コンポーネントで動く。 → テナントごとに管理画面 「自社ブランドに合わせたい」がここで出る。 → 今日の話は、この 「テナントごとのデザイン設定」をどう作るか 。 エンドユーザー( ToC) → 公開サイトを利用 事業者ごとに違う見た目で届く。
  4. 04 3 パターンを検討し、パターン 2 を採用した パターン 1 ← 当初これで作った プライマリカラー

    + 画像 限りなくシンプルな実装。1 色でも違いは出せる と思っていた。 実装 低 負担 低 パターン 3 ← 除外 パターン 2 ← 採用 複数色 + フォント + 角丸 + 画像 程よい自由度。makasta はここへ。 実装 中 負担 中 フルカスタマイズ STORES / BASE のようなネットショップ系。今 回のサービスではそこまでの設定は必要なかっ た。 実装 高 負担 高 当初はパターン 1 で作っていた。でも事業者から 「ブランドイメージに寄せたい」「自社サイトの雲囲気に合わせたい」 想像より事業者はデザインを気にしていた → リリース前にパターン 2 へ切り替えた。
  5. 05 [学び]テーマから始められるようにした 白紙から選ばせない 事業者はデザインの専門家ではない。自由度を 上げるほど迷う。 用途別テーマを用意 スタンダード / エレガンス /

    ナチュラル / ポップ… 選んだテンプレートがサイトに適用される 配色・フォント・角丸がフォームに読み込まれる。 ゼロからではなく、良い初期値からのカスタマイ ズ。
  6. 06 [学び]配色は「推奨色 + 自由入力」の二段構え 推奨色をあらかじめ並べる ブランド / ボタン / 見出し

    / 本文の各項目に、崩 れにくい色を用意。 カラーコードで自由入力も ブランドカラーが並びに無いこともあるので、直接 入力も残す。 決められない人はワンクリック、こだわりた い人は自由に。
  7. 07 [学び] CSS カスタムプロパティ(変数)を SSR で流し込むだけ // SSR で取得した tokens

    を一度だけ差し込む <SiteStyle tokens={tokens} /> 却下した案 export const SiteStyle = ({ tokens }) => ( ✗ props で style をバケツリレー → 各コンポーネントが汚れる <style>{` ✗ グローバルステート → SSR の初期化が面倒 :root { : ${tokens.brandColor}; 採用した案 SSR で取得したテーマを <style> で :root に流す 各コンポーネントは var(--color-primary) を書くだけ。既存 CSS --color-background : ${tokens.backgroundColor}; --font-heading : ${FONT[tokens.headingFont]}; --radius-card : ${RADIUS[tokens.corner]}px; Modules がそのまま使える。実装が一番楽だった。 } `}</style> );
  8. 08 まとめ(学び) 1 デザイン設定を事業者が一から選ぶのは大変。 選択肢はこちらで用意してあげる のが大切。 2 想像より事業者はデザインを気にする。シンプルに始めつつ パターン 2へ踏み込んだのが正解。

    3 不可逆性の高いデザイン基盤を 初期に実装できた のが良かった。後から入れるのは大変。 4 専門家でない前提で「 テーマから始める 」+「危険な組み合わせは選ばせない 」で品質を担保。 5 実装は CSS カスタムプロパティ(変数)を SSR で流す だけ。既存のコンポーネントに手を入れず一番楽に実現できた。