はじめに

自社の越境ECマネジメントシステム「Bynd」の紹介サイト（https://bynd.ne.jp/）を公開しました。国内のECサイトの商品データをShopeeなどの海外モールへ自動連携し、一元管理するシステムです（プレスリリース）。

サイトの要件は「非エンジニアが自分で文言を直せること」でした。

ここまでならCMSを入れる場面です。WordPressを立てて、管理画面から本文を書き換えてもらう。長年それが定番でした。今回はCMSを入れず、AIで作ったデザインをHTMLにして、静的ファイルのまま配信する構成にしています。

本記事では、その構成とCMSを入れなかった理由、実際に効いた点、そしてどこまでなら通用するのかを書きます。

作ったもの

構成は次のとおりです。

• 編集：ブラウザ上のデザインツール（Claude Design）。完成したページの上でテキストをクリックし、書き換えて保存する
• 同期：Claude Codeでデザインツールから最新のHTMLを取得し、GitHubリポジトリへのPR（Pull Request）にする
• 確認：テスト環境に反映して社内で見る。ドメイン自体は公開されているので、前段にBASIC認証を置いた
• 配信：Cloudflare Workers Static Assetsで本番に出す

全30ページで、サーバー側で動くコードはお問い合わせフォームの受け口だけです。残りはすべて、あらかじめ生成されたHTMLを返しています。

編集する人にGitとデプロイは見せていません。ブラウザで文言を直して保存するところまでが編集者の仕事で、そこから先は今のところこちらで引き取っています。

CMSの仕事を分けて考える

CMSを入れなかったのは、重いから避けたわけではありません。担ってもらう仕事が残らなかったからです。

CMSがやっていることは、大きく3つに分けられます。

• 編集UI：非エンジニアが本文を書き換えるための画面
• コンテンツの保管：書き換えた内容を貯めておく場所と、その履歴
• 配信時のレンダリング：リクエストが来たときに、保管したデータからHTMLを組み立てる処理

このうち編集UIは、デザインツールが引き受けました。管理画面の入力欄ではなく完成したページの上で文字を触る形なので、直した結果がその場で見えます。

保管はGitリポジトリで足ります。誰がいつ何をどう変えたかを追うなら、CMSのリビジョン機能よりコミット履歴のほうが読みやすい。

残るのは配信時のレンダリングですが、更新のたびにHTMLを作り直してしまえば、リクエストごとに組み立てる必要はありません。

3つとも別の手段で片付いたので、CMSを置く場所がなくなりました。

効いたこと

変更が差分として見える

いちばん効いたのはこの点です。CMSで非エンジニアに編集権限を渡すのは、本番のデータを直接書き換えてもらうことです。プレビュー機能はありますが、「今回どの文言がどう変わったのか」を公開前に一覧で突き合わせるのは簡単ではありません。おかしな変更が入ったときも、いつ壊れたかを探して、前後のリビジョンを1つずつ開いて見比べることになります。

静的HTMLをGitで管理していると、この確認がPRの差分になります。変更前と変更後が並んで出るので、直したはずのない箇所が一緒に変わっていれば、その場で気付けます。

編集は自由にやってもらったまま、公開の前にだけ門番を置ける。非エンジニアに編集を任せる前提だと、これがそのまま安全装置になっています。

保守するものが減る

DBもPHPもプラグインもありません。管理画面のログイン口がないので、そこを守る仕事も発生しません。

CMSを運用していると、本体とプラグインのバージョンアップが定期的に降ってきます。ほとんど更新のないサイトでも、この作業だけは止まりません。今回はその作業自体がなくなりました。

配信はCDNから静的ファイルを返すだけです。アプリケーションサーバーもDBも持たないので、その分の費用もかかりませんし、落ちる場所も減ります。

テスト環境が本番と同じものになる

テスト環境は、同じ生成物を別の宛先に配っているだけです。コミットされたファイル一式をもう1つのWorkerにデプロイし、前段にBASIC認証を置いて社内向けにしています。DBの複製もコンテンツの同期も要りません。

CMSでステージング環境を作る場合は、コンテンツを含めた複製と、そのあと本番とどう同期するかという問題が付いてきます。しかも複製した時点から、2つの環境のコンテンツは少しずつずれていきます。確認したページと本番に出るページが同じであることは、運用で担保するしかありません。

静的ファイルなら、テスト環境で見たものと同じファイルがそのまま本番に出ます。環境の違いはドメインと認証の有無だけで、中身は一致します。

静的配信とフォームを同じ場所に置ける

そもそもCloudflare Workersを選んだのは、お問い合わせフォームがあったからです。

サイトを完全な静的ファイルだけで組むと、フォームの送信先を外に探すことになります。外部のフォームサービスを契約するか、別のところにAPIを立てるか。どちらも、サイト本体とは別に管理する対象が1つ増えます。

Workers Static Assetsは、静的アセットの配信とコードを1つのWorkerに同居させられます。GETは静的アセットがそのまま返し、POSTはコード側に届くので、フォームの受け口を同じデプロイ単位で実装できました。CMSを外した結果として動的な処理がゼロになったわけではなく、必要な1本だけを自分で書いた形です。

スパム対策を同じ層で完結できるのも選んだ理由でした。実装側にはhoneypotと入力検証とOrigin検査を入れ、その手前でエンドポイントへのレート制限をかけています。配信しているCDNと同じ場所にこの手段が揃っているので、フォーム1本のために別サービスを増やさずに済みました。攻撃が増えたらCAPTCHAを足す、という拡張も同じ基盤の上でできます。

公開までに残る手作業

ここまでの構成では、デザインツールからの同期とデプロイをエンジニアが実行しています。編集だけを非エンジニアに移しても公開のたびに人の手が要るなら、CMSを外した意味は薄くなります。

ただ、残っているこの2つは、どちらも仕組み上どうしても人がやる作業ではありません。

デプロイは、ブランチへのpushをきっかけに動かせます。GitHub ActionsからWorkersにデプロイするだけなので、テスト環境への反映から順に自動化していけます。今は更新の頻度が低く、コマンド1つで足りているので手動のままにしています。

同期のほうも、定期実行のエージェントに任せられます。デザインツール側に変更があれば取得してPRを作るところまでをスケジュール実行にしてしまえば、編集者が保存した時点で差分のPRが立ちます。

そこまで進めても、差分を見て承認する工程は残す前提です。これは自動化し残したのではなく、公開の前に門番を置くために意図して残すものです。人に残るのは中身を見て判断することだけで、手を動かす作業は自動化に寄せていけます。

そして、最後に残るこの承認も、エンジニアでなくてもできます。文言の修正であれば、PRの差分に出るのは変更前後のテキストだけです。自分が直した箇所だけが変わっているかは、直した本人がいちばん正確に判断できます。編集者にGitHubのアカウントを用意し、見る観点を決めておけば、編集から公開までを非エンジニアの手で回せるはずです。

どこまでなら通用するのか

ここまでの利点は、いくつかの条件が揃って初めて成立します。

ページが増え続けないことが最大の条件です。今回はニュース一覧の各行を外部のプレスリリースや別サイトの記事へのリンクにして、本文ページを持たない設計にしました。だからニュースが増えてもページは増えません。ブログのように記事が積み上がる構成なら、この作り方は選びません。1本増えるたびにデザインツール側でページを作ることになり、それは編集ではなく制作の仕事です。

規模も30ページ程度での判断です。数百ページになると、生成物をまるごとコミットして差分を読む運用が成り立つかは、あらためて考える必要があります。

サーバー側で動く部分は、1本ずつ自分で書くことになります。CMSならプラグインを入れて設定するだけで済んでいたかもしれない部分です。今回はフォームが1本だけだったので実装して終わりましたが、仕様の違うフォームが何本もあるサイトなら、この差は無視できません。

画面のクリックでは直せない箇所も残ります。meta descriptionやOGP、sitemap、リダイレクトの類はエンジニア側の作業です。「非エンジニアがサイトのすべてを更新できる」状態ではありません。

そして、正本を一箇所に固定する規律が要ります。この構成での正本はデザインツール側で、リポジトリのHTMLは同期されてきた結果です。ここでリポジトリのHTMLを直接直すと、次の同期で編集者の知らないうちに上書きされて消えます。CMSなら編集する場所は管理画面しかなく迷う余地がありませんが、こちらは自分で決めて守る必要があります。

おわりに

CMSを選ぶ理由が「非エンジニアが更新できるようにするため」だけなら、その理由はもう成立しないことがあります。編集UIは、CMS以外のところから持ってこられるようになりました。

判断の分かれ目は、編集UIをどこから調達できるかと、ページが増え続けるかどうかの2点だと思っています。今回はどちらも条件を満たしていたので、CMSを持たない構成を選びました。