LPは​「1本ずつ」​作らない。​──複数クライアントの​LPを​1つの​基盤で​出し分ける​マルチテナント設計の​制作事例

制作事例 ｜ AI駆動開発の、動く証拠

LP（ランディングページ）の制作代行を始めると、すぐにぶつかる壁がある。1本作るのは速い。でも"何本も"作り、"その後ずっと運用する"段になると、急に話が変わる。

クライアントごとにリポジトリを分け、ドメインを設定し、認証を貼り、公開・非公開を切り替え、解析を仕込み、「いつ何を直したか」を追う——この一式が、1本ごとに増えていく。10本あれば10倍の管理が乗る。これでは"早い・安い"を売りにしているのに、運用で溶ける。

そこで私たちが選んだのは、LPを「1本ずつのサイト」ではなく「1つの基盤の上のテナント」として扱う設計だ。あるLP制作代行サービスのために、複数クライアントのLPを1つの土台で出し分け・量産・運用するマルチテナント基盤を、設計から本番まで作り切った。この記事は、その制作の中身の記録である。

01LPは​「1本ずつ」​作らない、と​いう​決断

制作代行の本質は量産だ。だが「量産」を素朴に「同じ作業を人数分くり返す」と捉えると、案件が増えるほど運用コストが線形に膨らみ、人を増やす——つまり人月に逆戻りする。

私たちの答えは逆だった。繰り返し発生する部分（ホスティング・認証・公開判定・解析・履歴）を"基盤"に吸い上げ、案件ごとに変わるのは「中身（デザインと文言）」だけにする。こうすれば、2本目以降の限界コストは「中身を1枚作る」だけに近づく。基盤が育つほど、新規LPの追加は速く・安全になっていく。

この発想自体は、私たちが過去に作ったマルチテナントSaaSと地続きだ。「複数の顧客を、1つのシステムの上で、互いに混ざらないよう分離して載せる」——その設計を、今度はLP公開基盤に持ち込んだ。

関連記事 ｜ 同じ「マルチテナント分離」の設計予約システムを、ゼロから「作る」 ──マルチテナントSaaSを設計から本番まで駆け抜けた制作事例 →

021つの​土台で、​ホスト名ごとに​出し分ける

基盤の入口は、たった1枚のミドルウェア（すべてのリクエストが最初に通る関所）だ。ここで「どのホスト名で来たか」を見て、表示するLPを振り分ける。

• example.com → 事例ギャラリー（基盤のトップ）
• clientA.example.com → クライアントAのLP
• clientB.example.com → クライアントBのLP

リポジトリも、デプロイも、ドメインの土台も1つ。新しいクライアントが増えても、増えるのは「中身のフォルダ1つ」と「台帳の1行」だけだ。各LPは相対パスで自己完結させてあるので、他のLPと干渉しない。

重要なのは、ここで公開状態の判定も同時にやっていること。「まだクライアント確認中（＝認証をかけて関係者だけに見せる）」なのか、「一般公開済み」なのかを、土台のレベルで切り替える。LPごとに認証コードを書き散らさない——判定を1か所に集めることが、運用を軽くする要だ。

03台帳を​二層に​分ける​：速い​判定と、​案件の​正

「どのLPが、いまどの状態か」を持つ台帳は、性質の違う2つに分けた。混ぜると必ずどちらかが壊れる。

① 高速台帳（ホットパス）	② 案件データベース（正）
全リクエストが毎回読む	人が運用で読み書きする
公開/認証・ドメイン・閲覧パスだけ	クライアント情報・進捗・素材・履歴
エッジ配信・数十msで応答	権限はサーバー側に限定（保護）
編集すると数十秒で全世界に反映	案件の唯一の正（SoT）

※ ①は超低遅延の読み取り用ストア、②は案件の正＝Source of Truth（唯一の真実）。役割が違うものを1つにしない。

狙いは2つ。1つは速度。すべてのリクエストが通る判定は、本体DBに毎回問い合わせていては遅い。だから公開判定に必要な最小限だけを、エッジ（世界中の配信拠点）から数十msで読める高速台帳に置く。

もう1つは「再デプロイなしで公開・非公開を切り替えられる」こと。クライアントから「OK、公開して」と連絡が来たら、高速台帳の1項目を preview から live に書き換えるだけ。コードのビルドもデプロイも要らず、数十秒で全エッジに反映される。これが「営業のスピード」に直結する。

逆に、クライアント情報や進捗・素材といった案件の中身は、本体のデータベースを"唯一の正"とする。ここは権限をサーバー側に閉じ、一般公開のURLからは決して触れないように隔離した。「速く読むための台帳」と「正しさを守る台帳」は、目的が違うから分ける。——これは過去の制作でも繰り返し学んだ、二度と混ぜないと決めた原則だ。

04テナントは​「3系統」に​登録する、と​いう​設計

マルチテナント基盤でいちばん事故りやすいのが、ここだ。1つのLPを足すとき、登録すべき場所が3つある。どれか1つでも欠けると、エラーも出ずに"静かに"壊れる。

• A. ルーティング台帳：高速台帳に「このサブドメインは存在する／公開状態はこれ」を登録。無いとサブドメインが解決しない。
• B. 案件レコード：本体DBに案件の行を作る。無いと管理画面に出ず、事例ギャラリーのカードも崩れる。
• C. 個別の証明書（TLS）：これが伏兵だった。*.example.com のワイルドカード証明書を登録してあっても、サブドメイン単体は個別に追加するまで証明書が発行されない。すると——デプロイも台帳登録も完璧なのに、ブラウザがTLSの段階で接続を切る（curl でステータス 000）。404ですらない、文字どおりの"無音"だ。

この「3つ揃って初めて成立」を人間の手順に頼ると、必ずどこかで1つ抜ける。だから私たちは3系統の登録を1本のコマンドにまとめ、抜けが起きない形にした（次章）。設計の良し悪しは、こういう「忘れたら静かに壊れる工程」をどれだけ仕組みで潰せるかに出る。

05デザインは​"流し込む"：中身だけを​差し替える

基盤が固まれば、案件ごとの作業は「中身を1枚作って流し込む」に集約される。各LPのデザインは、AIで生成した本番レベルのデザイン²を、テナントのHTMLへ統合して作る。

ただし"コピペ"ではない。流し込むときに守るルールを決めてある。

• 解析タグと標準ヘッダーは必ず残す：雛形に最初から入れてある計測・SEO・OGP・favicon・言語設定を消さない。消すと解析が"無音で"欠ける（数字が取れていないことに後で気づく、最悪のパターン）。
• プロトタイプ専用の仕掛けは置換する：デザイン生成段階の編集パネルやプレビュー用スロットは本番には不要なので、画像の差し込み口は通常の <img> に、未支給の写真はプレースホルダに置き換える。
• 演出は削らない：スクロール連動の出現、縦書きのスタッガー、グレイン——デザインの"勝負どころ"を簡略化しない。動きが速さと品質の証拠になる。
• 画像は必ずWeb最適化：長辺を抑え、品質を保ったまま圧縮し、メタ情報を落とす。重い原本を本番に置かない。

こうして「基盤＝変わらない部分」と「中身＝案件ごとの部分」をはっきり分けたことで、新規LPの追加は"設計"の作業から"流し込み＋確認"の作業へ性質が変わった。デザインの質は上げたまま、追加の手間だけを下げる——これが量産の正体だ。

06量産を、​仕組みに​する​（スクリプト化）

「3系統に登録」「中身を流し込む」「事例サムネを作る」「公開前に検査する」「履歴を残す」——この繰り返しを手作業のチェックリストに残さず、スクリプトに落とした。覚えていないと壊れる工程ほど、機械にやらせる。

とくに効いたのが2つ。

• 公開前のプリフライト検査：「案件レコードはあるか／必要な説明文は埋まっているか／事例サムネは生成済みか／3系統のステータスは食い違っていないか」を機械が点検し、失敗0になるまで公開させない。「LPは公開したのに事例カードが無い」「事例カードはあるのにLPは認証下」といった不整合を、出る前に潰す。
• 変更履歴を、コミット履歴から自動生成：テナント別の履歴ファイルを人が書くのではなく、Gitのコミットを唯一の正として、どのコミットがどのテナントを触ったかを射影して履歴に焼く。二重管理が消え、テナントが100に増えても「いつ・何を直したか」が一望できる。

結果として、テナント追加〜クライアント確認用の公開までを一連のランブックとして一気通貫で回せるようにした。新人でも、AIでも、同じ手順で安全に1本足せる——これが「仕組みにする」ということだ。

07静かな​失敗を、​検査で​表に​引きずり出す

この基盤の制作でいちばん神経を使ったのは、機能の追加より「エラーを出さずに壊れる経路」を潰すことだった。マルチテナントは、失敗が"静か"になりやすい。記録として、実際に踏んで対策した3つを残す。

静かな失敗	症状	効いた対策
証明書の未発行	デプロイも台帳登録も正しいのに、サブドメインだけ繋がらない。404ですらなく、接続が 000 で無音	「ワイルドカード証明書があってもサブドメインは個別追加が要る」と理解し、登録を自動化。curl -v のTLSエラーで一発診断
クラウドビルドの取りこぼし	自動ビルドが、最も大きい1つの関数を無音で取りこぼす。その機能だけ 404 になる	ローカルで先にビルドして、その成果物をそのままデプロイ（プリビルド）。出力に当該関数があることを目視
HTTPコードの読み違い	「繋がらない＝コードのバグ」と思い込んで時間を溶かす	000＝TLS層／404＝ルーティング・関数不在／401＝到達して認証ゲートと切り分けを固定

※ いずれも制作・運用中に実際に踏み、原因を特定して対策・自動化した事象。

共通する教訓は、CAGがずっと書いてきたことと同じだ——「動いて見える」を信用しない。静かに失敗する経路を、検査と切り分けの手順で必ず表に引きずり出す。マルチテナントのように"片方だけ壊れる"構造ほど、この規律が効く。

08​締め：基盤が、​営業の​速さに​なる

この基盤を作ってから、LPの仕事の進み方が変わった。デザインが固まればその日のうちにクライアント確認用URLを発行でき、OKが出れば台帳を1項目書き換えるだけで即・一般公開。解析も履歴も土台が勝手に面倒を見る。「作る速さ」だけでなく「出す速さ・運用の軽さ」までを、設計で前借りした。

派手な機能の話に見えないかもしれない。だが制作代行をスケールさせる本当の勝負どころは、「2本目以降をどれだけ安く・速く・壊さずに足せるか」にある。1本ずつ作るのをやめ、繰り返しを基盤に吸い上げ、静かな失敗を検査で潰す——その設計判断の積み重ねが、結局いちばん効く。

電脳技巧集団（AI職人ギルド）は、こうした「作る」だけでなく「量産し、運用し続けられる」土台の設計を、AI駆動開発で速く形にする。LPでも、業務システムでも、考え方は同じだ。

LPは、1本ずつ作らない。従来のLP公開・運用と、マルチテナント基盤を一枚に。

観点	1本ずつ作る（従来）	マルチテナント基盤（CAG）
新規LPの追加	毎回リポ・ドメイン・認証を構築	中身1枚＋台帳1行＝限界コストが寝る
公開・非公開の切替	設定変更→再デプロイ	台帳を1項目書換＝数十秒で反映
解析・SEO・OGP	LPごとに貼り直し（抜け漏れ）	雛形に内蔵＝消さない限り常に付く
登録漏れ	手順書頼み＝静かに壊れる	3系統を自動登録＋公開前に検査
変更履歴	人が書く（二重管理）	コミット履歴から自動生成
運用コスト	本数に比例して人月が膨らむ	基盤が育つほど1本あたりが軽くなる

※ 本記事は、あるLP制作代行サービスの公開基盤の制作記録。クライアント名・サービス名・ドメイン・各種ID・接続情報・閲覧パスワードは伏せ、仕組みの説明に必要な範囲にとどめる（匿名ケーススタディ・v0・2026-05時点）。