コーポレートサイトの内製で、何を引き受けるのか

記事タイトルを変えると、本文だけでなく、一覧、canonical URLの参照、サイトマップ、構造化データ、事前生成されたHTML、llms.txt、ai-context.jsonの整合が必要です。どれかを手で直す運用では、更新するほど差が生まれます。

Corporate Siteでは、記事の構造化データを起点にこれらを生成し、CIで差を検出します。Productionでは、実際に配信された版、canonical、構造化データ、生成物をもう一度確認します。「公開ボタンを押した」が完成ではありません。

最初は、更新費を抑え、細かな修正を自分たちで行えることが大きな利点に見えます。実際に運用すると、より重要だったのは、観測から次の公開までが一つにつながることでした。

AnalyticsやSearch Consoleで入口を観測し、読まれていない理由を考え、文章や導線を直し、previewで確認し、CIを通し、本番で確かめる。判断と実装の距離が短いほど、小さな学びを次へ戻せます。

Gitのコマンドを全員が覚える必要はありません。しかし、誰が何を変え、previewでどう見え、検証に通り、いつ公開されたかは残したい。そこで入力UIや定型の編集経路を用意しても、同じ記事データと同じ検証を通します。

簡単にするために本番ファイルを直接編集すると、速さと引換えに履歴、preview、rollbackを失います。操作を簡単にしながら、公開契約は一つに保つことが、非開発者運用の設計です。

年に数回しか更新せず、担当者を置けない、法的・セキュリティ上の専門確認が常時必要、障害対応を自社で持てない。この条件では、管理型CMSや外部の保守契約が合理的です。

内製か外注かは、HTMLを書けるかで決めません。公開後に、誰が観測し、誰が判断し、何を証拠に公開し、失敗時に戻すか。その循環を自社で持つ価値が、継続費用を上回るかで決めます。

ページを一度作るだけなら、外部へ依頼した方が速い場面は多くあります。内製の価値は制作費そのものより、文章を直す、確認する、公開する、検索や利用状況を観測する、また直す、という循環を社内で途切れずに回せることにあります。

その循環には、デザインだけでなく、Git、preview、CI、公開、戻し方、canonical、サイトマップ、構造化データ、アクセシビリティ、分析を含みます。一行の文章を直しただけでも、検索エンジンやAIが読む生成物、公開ページ、関連導線に矛盾が出ないかを確かめる必要があります。技術者でない人が更新する場合も、別の管理画面を増やすのではなく、何を正本にし、誰が公開前に何を見ればよいかを整えます。

株式会社ピース・ビズのCorporate Siteでは、記事データからcanonical、sitemap、llms.txt、ai-context.jsonを生成し、公開前後の確認を行っています。これはWeb制作や運用支援の提供を示すものではありません。自社の情報を自社で正しく更新し続けるための仕組みです。