街づくり12日目｜Web公開を安全に運ぶ経路を整える
2026年8月26日、街づくり12日目。
この日は新しい画面を増やす代わりに、KOGAMAI JUNCTIONのWebを安全に更新する経路を整えました。変更を速く届けることと、公開してよいものだけを届けることを、同じ仕組みで確かめます。
sourceと公開物を分ける
正式文書は一つのprivate repositoryで管理し、Webはreview済みのexact commitだけを読み取ります。公開対象に選ばれた文書だけを抽出してから、publicとadminを別々にbuildします。内部文書はbuild、検索index、feedへ渡しません。
Pull Requestでは、まず秘密を渡さないbuildを行います。その成果物を信頼済みのcodeでもう一度監査し、PRのidentityとcommitが一致した場合だけPreviewへ進めます。Pull Requestを閉じた後のPreview終了も、公開と同じ契約で確認します。
CIも役割ごとに分ける
品質検査と公開処理は、用途を分けたself-hosted runnerで実行します。通常の品質検査へproduction credentialを渡さず、公開処理だけが保護されたEnvironmentを使います。
一つのgreenだけを完成の証拠にはしません。formatter、型、test、静的build、公開境界監査、Workerのdry-runを通し、Previewで表示とrouteを確かめます。production publicationと、その後のread-backはさらに別の証拠です。
現在のWorkers境界
publicとadminは別々のCloudflare Workersとしてbuildします。公開面のWorker codeが先に扱うのは限定したAPI routeだけで、通常のページとassetは静的に配信します。現在のWeb公開経路にはD1を接続していません。永続dataや認証機能を、技術紹介のためだけに追加することもありません。
この分離により、公開ページの更新がそのまま管理面や将来のPortal機能を有効にすることはありません。
FiveM resourceも境界から作る
FiveM側では、first-partyのTypeScript packageとvendor resourceを同じものとして扱いません。導入元とdigest、起動順をlockで固定し、vendorのpristine treeへ直接変更を重ねず、localな差分はoverlayやadapterへ分離します。
game session、money ledger、KOGAMAI Payのようなfirst-party resourceは、server-authoritativeなrule、contract test、E2E、bundle smoke testを実装と一緒に管理しています。Webと同じく、merge済みのsource、検証済みartifact、DEVでの観測を別々の証拠として扱います。
observabilityもcodeで検査する
共有Infrastructureでは、Zabbixをmetricsとtrigger、VictoriaLogsをlog、Grafanaを表示面として分担させています。監視対象の台帳、log envelope、dashboard、preflightとplan validator、guarded workflowを同じrepositoryで管理します。
観測画面が見えることだけを健全性の証拠にはしません。収集契約とprivacy境界をtestし、変更前のplanと変更後のread-backを分けることで、観測基盤自身の変更もrollback可能にします。
rolloutとrollbackを同じ精度で考える
公開前にはWebと文書sourceのexact commitを固定し、変更対象と非対象を確認します。公開後はURL、source metadata、必要なAPI responseをread-backし、想定と違えば成功扱いにしません。
rollbackも「前に戻す」だけではなく、直前の既知commitへ戻す変更をreviewし、同じbuild、監査、承認、read-backを通します。credential、内部topology、詳しい運用logは公開記事へ持ち込みません。
次の変更も小さく確かめる
Webの安全性は、大きな仕組みを一度作って終わりではありません。公開物、identity、実行環境、runtime観測を別々に確かめることで、小さな更新を積み重ねても境界を保てるようにします。