10のサイトを1つの管理画面で運用する — マルチテナントCMS Plovant
上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。
10のサイトを1つの管理画面で運用する — マルチテナントCMS Plovant
結論
- 何を作ったか: 10を超えるWebサイトを、1つのリポジトリ・1つの管理画面から運用するマルチテナントCMS
Plovant（https://plovant.com ）です。ブロックベースのCMS、AIによるページ・画像・ロゴ生成、ブロック単位の多言語翻訳、自社IdPによる統一SSO認証、組織・権限・ドメインを束ねるSaaSコントロールプレーンを持ちます。 - なぜ作ったか: AWS Amplifyのホスティングは従量課金で無料同然だからと、サイトごとに別アプリを足していったら、ビルド費用と管理対象がサイトの数だけ増えたからです。mainへのpushで7サイトが同時に再デプロイされる無駄も起きていました。
- 何が要点か: サイトとアプリの1対1対応をやめ、アクセスされたホスト名でどのサイトを出すかを振り分ける単一アプリへ集約したこと。サイトを増やしても、管理は1か所のままです。
本文（読了 約13分）
前回の続き — 「画面から直せる仕組みが要る」の答え
以前、旧webサイト移行をAIにまかせたという記事を書きました。古いWordPressや素のHTMLのサイトをAIで移行し、自分たちで運用を始めたら、4つのサイトで同じお問い合わせ機能をそれぞれ作っていることに気づいた。そして、日々の運用にはAIに頼むより、WordPressのように画面から直せる仕組みが向いていると分かった——という話です。
この記事はその続きです。あのとき見えた必要を、1つの製品に育てました。移行の実体験があの記事、育てた製品の中身がこの記事、という関係です。
サイトは増える。仕組みも一緒に増えていいのか
会社のWebサイトは、気づくと増えます。コーポレートサイト、製品ごとのLP、採用ページ、キャンペーンページ。私たちも10を超えるサイトを抱えるようになりました。
最初は素直に、サイトごとに別々のアプリとして配信していました。配信基盤はAWS Amplifyです。Amplifyはサーバーを常時借りる方式ではなく、使った分だけの従量課金。小さなサイトならホスティング費用はほぼゼロです。だから当時は「無料なのだから、サイトはいくつ乗せてもいい」と考えて、サイトが増えるたびにAmplifyアプリを1つずつ足していきました。
この前提が崩れます。ホスティングは無料同然でも、ビルドには課金されるからです。Amplifyはビルド時間に応じて費用がかかるので、アプリが増えるほどビルドの回数と費用が増える。加えてサイトを1つ増やすたびに、ドメイン設定が増え、環境変数の管理が増え、費用の請求行が増える。管理画面もサイトごとにバラバラです。ある時期は、mainブランチへpushすると7つのサイトが同時に再デプロイされる構成になっていました。1行の修正で7回のビルドが走り、ビルド時間分の費用が7サイト分かかる。「無料だから乗せ放題」は、ビルドの費用と管理の現実で成り立たなくなりました。
サイト運用の費用は、実は「表示するための費用」より「サイトごとに分かれた仕組みを維持する費用」が支配的になっていきます。ここを直さない限り、サイトを増やす提案のたびに費用の説明が要る会社になってしまいます。
「それならWordPressを10個立てれば」という案も検討しました。画面から直せるという要件は満たせます。でも、10個のWordPressは10個の管理画面・10回のアップデート・10か所のセキュリティ対応を意味します。放置されたWordPressが攻撃の入口になる事故は、コンサルティング先でも何度も見てきました。マルチサイト機能を使う手もありますが、認証を自社のSSO基盤に統一したい・課金や通知など自社基盤へ接続したい、という要件まで含めると、既製品のカスタマイズ費用が自作を上回ると判断しました。この判断が成り立つのは、後述するとおり接続先の基盤群が既に自社にあったからです。前提が違う会社では結論も違ってきます。
発想の転換 — アプリを分けず、ホスト名で振り分ける
そこで、サイトとアプリの対応を切りました。Amplifyという配信基盤を捨てて別の仕組みへ移るのではなく、同じAmplifyの上でどう実現するかを考えた答えです。全サイトを1つのAmplifyアプリに集約し、アクセスされたホスト名（どのドメインで来たか）を見て、どのサイトの内容を返すかを振り分けます。
- 配信面は1つ: Amplifyアプリは1つだけ。サイトを増やすときは、管理画面でサイトを作り、ドメインを割り当てるだけです。配信アプリは増えません。
- 管理画面も1つ: どのサイトのどのページも、同じ管理画面（web-admin）から編集します。
- 費用は集約で下がる: pushで走るビルドは1回になり、サイトごとに増えていたビルド費用と管理対象が1つ分に畳まれます。7アプリを1つに集約するこの決定は、コスト削減を最優先に置いた設計判断でした。
移行は、何も起きずには終わりませんでした。ドメインを旧アプリから新基盤へ移す作業では、実際に1サイトを一時的に落としています。削除したはずの旧配信設定が残り続ける「ゾンビ」状態とも戦いました。使われていない5サイトはこの機会に完全に削除しました。集約は、動いているものを動かしながらの引っ越しです。事故ゼロでは済まないことも、正直に書いておきます。
編集は「ブロック」でする
Plovantの編集単位はブロックです。文章のブロック、画像のブロック、お問い合わせフォームのブロック。ページはブロックの並びとして作られ、管理画面で並べ替え・差し替え・公開ができます。
ブロックの部品は、複数製品で共有する共通パッケージとして切り出してあります。ブロックエディタ自体を複数のリポジトリで別々に作らない、というこの連載でおなじみの集約です。よく使うセクション（導入・特徴・料金・FAQなど）は仕上げ済みのプレミアムブロックとして9種類用意し、テンプレートは「ブロックの組み合わせのプリセット」として実装しました。テンプレートという別の仕組みを作らず、既存のブロック機構に乗せたことで、テンプレートから作ったページも後から1ブロック単位で直せます。
AIを載せる — ページも画像もロゴも画面の中で
その上に、AIを載せました。
- AIページ生成: 作りたい内容を伝えると、内容からページの種類（LPか、案内ページか）をAIが判断し、構成を選んでブロックを組み立てます。構成を人が指定するのではなく、内容が構成を決める方式（content-first）にしています。
- AI画像・ロゴ生成: LPに使う画像を画面から生成できます。ロゴは拡大しても荒れないベクター形式で生成します。
- ブロック単位の翻訳: ページ全体ではなくブロック単位で多言語化します。一部の文言だけ直したときも、差分のブロックだけ翻訳し直せば済みます。多言語対応は自動テストを303件から331件へ増やしながら段階導入しました。
このAI画像生成では、生成に時間がかかりタイムアウトする問題と3日間格闘しています。重い生成を裏側のジョブに逃す構成は、promptflowで学んだ教訓の再利用です。製品をまたいで同じ失敗を2度しない——これが多製品を1人で回すときの生命線です。
実際の使い方 — 新しいLPが1日で出るようになった
集約とブロック化とAIで、日々の運用はこう変わりました。
例1: 製品LPの新設。 以前は「LPを作る」と決めてから、リポジトリを用意し、デザインを発注または流用し、実装して、配信を設定して……と数週間単位の仕事でした。いまは管理画面でサイトを作り、AIページ生成に製品の説明を渡して初稿のブロック列を出させ、文言と画像を差し替えて公開ボタンを押すまで、その日のうちに終わります。ドメインの割り当てとDNS設定はサイト作成時に自動で行われます。
例2: 文言の修正。 「料金の表記を直したい」という日常の修正は、該当ブロックを開いて直すだけです。以前のようにリポジトリを特定して、コードを直して、ビルドを待つ必要はありません。ビルドを待たないので、修正のついでに7サイトが再デプロイされることもありません。
例3: 多言語ページの維持。 日本語ページの1ブロックを直したら、そのブロックだけ再翻訳します。ページ全体を訳し直さないので、翻訳のたびに他の箇所の訳文が揺れる問題が起きません。
社内で言う「LPの外注をやめられた」は、デザイン会社への支払いが消えたという意味だけではありません。修正のたびに発生していた依頼・待ち・確認の往復が消えたことが、体感としては一番大きい変化です。
AIでLPを作る、の現実 — 生成と編集の分担
「AIがLPを作ってくれる」という宣伝は世の中に溢れています。実際に自社の全サイトで運用してみて分かった現実を書きます。
AI生成が一番効くのは初稿です。まっさらな画面を前に構成から考えるのは、人間には重い仕事です。製品の説明を渡して、それらしい構成のブロック列が数分で出てくるだけで、着手の心理的な壁が消えます。content-first方式（内容からページ種別をAIが選ぶ）にしたのも、人が「LPを作るぞ」と構成を決め打ちするより、内容に合った構成が出てくる方が初稿として使えるものになったからです。
一方で、仕上げは人間の仕事として残ります。価格の正確な表記、法的な文言、ブランドとしての言い回し。ここをAIに任せると、それらしいが正しくない文章が公開されます。だからPlovantの設計は「AIが生成し、人がブロック単位で直し、人が公開ボタンを押す」という分担で固定しています。全自動公開は意図的に作っていません。
画像も同じです。生成画像はLPの雰囲気づくりには十分ですが、製品の実画面はスクリーンショットでなければ嘘になります。生成と実物を混ぜて使い、どちらを使うかは人が選ぶ。AIは選択肢を増やす係、人は選ぶ係——この分担は、当社の他の製品ともまったく同じ思想です。
ロゴのベクター生成は、予想以上に役立ちました。ラスター画像（拡大すると荒れる形式）のロゴは印刷や拡大表示で使い物にならないため、従来はデザイナーへの発注が必須でした。ベクター形式（拡大しても荒れない形式）で直接生成できるようになったことで、新しいサイトの立ち上げ時にロゴの発注待ちがなくなりました。
サイト運用をSaaSにする — コントロールプレーンと統一SSO
Plovantは自社サイトの運用基盤から始まりましたが、いまは社外提供（SaaS化）へ進めています。そのために作ったのが管理の中枢（コントロールプレーン）です。
- 組織・チーム・権限（RBAC）: 誰がどのサイトを編集できるかを、組織→チーム→メンバーの構造で管理します。
- 統一SSO認証: ログインは自社IdP（ELN ID）へ委譲し、OAuth 2.0＋PKCEで統一しています。Plovant自身はログインフォームを持ちません。この連載の認証基盤の記事で書いた「利用側にログインフォームを作らない」原則の実例です。
- APIキーとサブドメインの台帳: 機械連携用のキー発行と、
*.sites.plovant.com配下のサブドメイン割り当てを台帳で管理します。 - 持ち込みドメイン: 顧客が自分のドメイン（APEXドメイン含む）をそのまま使える仕組みも、実際に検証済みです。ゾーン設定の罠を含めた検証の顛末は別の記事に書いています。
「CMS」と言うと編集画面の話に聞こえますが、複数の組織に貸し出すには、編集の外側——誰に何を許すか、どのドメインを誰が持つか——の作りが本体です。
開発の裏側 — 準備の2か月、実装の1か月
Plovantの開発史には特徴的な形があります。2月に初コミットした後、4月はコミット2件、5月も5件。ほぼ止まって見えます。この間にやっていたのは開発の進め方の整備です。5月末に標準ツールチェーン（品質チェックの自動化と仕様先行の開発プロセス）を導入し、既存の型エラーを全部解消しておきました。
そして6月に、観測記録2,633件・コミット125件と一気に実装が進みます。SaaSマルチテナントの要件を確定した日には、設計判断4本と基本設計3本を一気に書き、組織・権限・サイト・APIキー・サブドメイン台帳を実装しています。7アプリ→1 hub の集約決定もこの月です。準備の2か月と実装の1か月という形は、狙ったものではありませんが、結果として「型を先に入れると実装が速い」のきれいな実例になりました。
ブロックCMSの本体は、複数製品で共有する共通パッケージ群（ブロック定義・エディタ・配信）として別リポジトリに正本を置き、Plovantはそれを利用する側です。共通基盤の記事で書いた「provider（提供側）とconsumer（利用側）を分ける」構造そのままで、LP機能を共有パッケージへ移した際は60ファイルの変更で、利用側の重複実装15ファイルを削除しています。
前史 — SEOプラットフォームからの転換
実はPlovantはCMSとして生まれたわけではありません。初期はSEO（検索エンジン最適化）のプラットフォームとして生まれ、後にSEO機能を別製品（aio-helper）へ分離して、CMS基盤へ転換しました。「1つのリポジトリに2つの製品が同居し始めたら分ける」という判断で、この分離があったから、PlovantはCMSとしての作り込みに集中できました。
そして冒頭に書いたとおり、決定的だったのはELNW-017の経験です。移行で「同じものを4回作っていた」ことに気づき、運用で「画面から直せる仕組み」の必要を確信した。製品の種は、構想からではなく運用の困りごとから生まれました。
読者の会社でやるなら — 集約の分岐点
同じ悩み（サイトが増えて管理が散らかる）を持つ会社は多いはずなので、うちの経験から分岐点を整理します。
サイトが1〜2つなら、集約は要りません。 WordPressでも静的サイトでも、個別に持つ方が単純です。集約の仕組み自体に初期コストがかかるからです。
3つを超えて、しかも増え続ける見込みなら、集約を検討する価値があります。 判断材料は3つ。①サイト同士で同じ機能（お問い合わせ・アクセス解析・多言語）を複製し始めていないか。②サイトごとの配信費用・証明書・ドメイン設定の管理が誰かの頭の中にしかない状態になっていないか。③「サイトを増やしたい」という提案に、技術側が渋い顔をする状態になっていないか。3つとも当てはまるなら、集約の効果は確実に出ます。
自作するか、既製のマルチサイトCMSを使うか。 一般論としては既製で始めるのが正解です。うちが自作したのは、認証基盤・課金基盤・通知基盤を既に自社で持っていて、そこへ接続する前提だったからです。この連載で書いてきたとおり、基盤が揃っている会社では「つなぐ自作」の費用が下がります。逆に言えば、基盤なしでCMSだけ自作するのはおすすめしません。
移行で一番怖いのはDNSです。 うちはドメイン移行で1サイトを一時的に落とし、消したはずの旧配信設定が生き残る事態も経験しました。移行するサイトごとに「戻す手順」を書いてから切り替えること。切り替えは一斉ではなく1サイトずつ。この2つだけで、事故の大半は避けられます。
いまの状態と、これから
Plovantは自社の10超のサイトを実際に支えている運用基盤であり、同時にSaaS化を進めている製品です。配信面と管理面を分けたドメイン構成に整理し、顧客の持ち込みドメインも検証済み。ブランド名Plovantへの統一も完了しています。
SaaSとしての外部提供はまだ準備中の段階です。自社利用で鍛えた「集約・ブロック・AI生成・多言語」の型を、他の会社でもそのまま使える形に磨いているところです。dogfooding（自社の道具を自社で使い倒すこと）で先に運用の弱点を潰す——この順序は、この連載で紹介してきた他の製品と同じです。
転用できる教訓
- サイトとアプリを1対1にすると、サイトの数だけ費用と管理が増えます。ホスト名で振り分ける単一アプリへの集約は、サイトが3つを超えたら検討する価値があります。
- ホスティングが従量課金で無料同然でも、ビルドと管理はアプリの数だけ増えます。「無料だから乗せ放題」は成り立ちません。基盤を乗り換えるのではなく、同じ基盤の上で構造を集約する解決もあります。
- 「pushで7サイトが再デプロイされる」ような構造の無駄は、気づいた時点で構造ごと直します。運用でかわし続けると費用が固定化します。ただし集約の移行では事故も起きます。落ちる想定と戻す手順を先に用意してから動かします。
- 編集単位をブロックに揃えると、AI生成も翻訳もテンプレートも「ブロックを作る・差し替える」操作に統一でき、機能追加が単純になります。
- 複数組織へ貸すSaaSの本体は編集画面ではなく、権限・認証・ドメインの管理側です。認証は自前で持たず、IdPへ委譲する構造が安全です。
- 製品の種は運用の困りごとから生まれます。「同じものを4回作っていた」という発見が、この製品の始まりでした。
この Plovant についての記事は、開発の経緯・どんな機能があるか・どう実装したかを、順次シリーズとして公開していきます。 興味のある方は、ぜひ「いいね」と記事の購読をお願いいたします。
Plovant は、複数サイトの運用と SSO 認証を1つの基盤にまとめるマルチサイト CMS・SaaS プラットフォームです。詳しくは https://plovant.com をご覧ください。 そのほかの自社プロダクトは https://www.eln.ne.jp/products にまとめています。
筆者について
上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。
また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。
EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。
→ EarthLink Network が自社でつくっている18のプロダクト
会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。