News

CMSを使わずにニュースを運用する、
静的サイトのつくり方

コーポレートサイトにニュース欄を作るとき、反射的にCMSの導入が検討されます。しかし月に数本の更新頻度であれば、CMSの契約・アップデート・権限管理・セキュリティ対応は、得られる便益に対して重すぎることが多い。弊社サイトのニュースは、外部サービスを一切契約せず、静的HTMLとコーディングエージェントだけで運用しています。本記事では、その具体的な構成と、公開を制御するビルド時フィーチャーフラグの実装まで含めて解説します。

ひとつのソースから、フラグで公開経路を分岐する

構成: 1記事1ファイルの割り切り

記事は1本につき1つのHTMLファイルです。データベースもテンプレートエンジンもなく、一覧ページとトップページの新着枠は記事追加のたびに更新します。この「手作業」が成立するのは、更新者が人間ではなくコーディングエージェントだからです。

鍵になるのは、更新手順を「エージェントが読んで実行できる手順書」としてリポジトリに置くことです。雛形のコピー、メタ情報とOGPの書き換え、一覧への追加、サイトマップへのURL追記、複数幅での表示確認、コミットまで。手順書に落ちていれば、「この内容で記事を追加して」という一言が更新作業のすべてになります。弊社の実績では、プレスリリース6本の移植と一覧の再構成が、指示から確認込みで1時間かからず完了しています。

公開制御: ビルド時フィーチャーフラグ

運用を始めると、「コンテンツが溜まるまで本番からは一時的に隠したい。ただし開発は続けたい」という要求が出てきます。ソースから削除すると復元が大変で、ブランチを分けると差分管理が地獄になります。弊社が選んだのは、ビルド時に公開物から取り除く方式です。

実装は3つの部品でできています。第一に、ソース側の該当箇所(ナビのリンク、トップの新着枠)をHTMLコメントのマーカーで囲む。第二に、ビルド成果物からマーカー間のブロック・記事ファイル・関連画像・サイトマップの該当URLを削除する除去スクリプトを用意する。第三に、デプロイのワークフローに環境変数のフラグを立て、フラグがオフのときだけ除去スクリプトを実行する。

# デプロイワークフロー(要点のみ)
env:
  NEWS_ENABLED: "false"   # 公開するときは "true" に変えるだけ

steps:
  - name: Assemble public site   # 公開物を組み立てる
  - name: Strip news
    if: env.NEWS_ENABLED == 'false'
    run: python3 scripts/strip_news.py _site

この方式の利点は、開発ブランチが常に「完全な状態」を保つことです。デザインも記事も消えないので、公開の再開はフラグを一語書き換えるだけ。公開・非公開の切り替えがコンテンツの破壊を伴わない、という安心感は運用上とても大きいものでした。

合わせて決めておくべき運用規約

  • キャッシュバスト: CSS・JSを更新したら全ページの版数クエリを一括更新する。静的サイトはCDNキャッシュが強く効くため、これを規約にしないと「更新が届かない」事故が起きます
  • サイトマップとOGP: 記事追加の手順書に組み込み、エージェントの作業として自動化します
  • 非公開領域のマーカー規律: 非公開中にニュースへの新しい導線を追加する場合は、必ずマーカーで囲む。囲み忘れは本番への露出事故になるため、手順書に明記します

この構成の適用範囲

正直に言えば、この構成は万能ではありません。非エンジニアの担当者が複数人で日常的に投稿するなら、権限管理と編集画面を持つCMSが正解です。弊社の構成が効くのは、更新頻度が月数本で、更新の実務をコーディングエージェントが担い、公開前にレビューの目が入る体制の場合です。保守対象はHTMLとスクリプト数本だけで、外部依存はホスティングのみ。「守るものが少ない」ことの価値は、小さな組織ほど大きいはずです。

ニュース一覧へ戻る