AIと運用するコーポレートサイトで、記事更新のたびに何をテストするか

記事の一文を書き換えたときと、サイト全体のヘッダーを書き換えたときでは、壊れうるページが違います。一方、公開日時を変えるだけでも、記事の詳細、一覧、検索結果に同じ時刻の判定が必要です。変更したファイルの数だけでは、確認すべき範囲は決まりません。

フィールフロウでは、AIエージェントを使いながらこのコーポレートサイトを更新しています。2026年10月には、予約公開のテストで繰り返していた検査を整理しました。変更後のコードと実行記録をもとに、何をまとめ、何を記事ごとに確かめ続けているかを紹介します。

10月に運用していたサイト

10月末の本番用ブランチには、10月付の日本語ブログが22本ありました。ブログとは別にニュースや業界レポートもあり、公開時刻を指定した記事は、時刻が来るまで詳細URLや一覧、検索などに出さないようにしています。記事を追加するたびに、このような読者の入口をどこまで確かめるかが運用上の判断になります。

変更の規模を示す補足として、同月にマージしたプルリクエスト（PR）は、変更の統合先である develop 宛てが431件、本番用の main 宛てが68件でした。develop 宛てにはGitHub上でBotと分類されたアカウントによる6件を含みます。同じ変更が両ブランチを通るため、宛先別の件数として扱います。

予約公開の個別テスト38ファイルを共通化した

改修前は、公開済みのレポートも含め、記事ごとのブラウザテストが同じ一覧ページやサイトマップを繰り返し取得していました。記事ごとに確認したいことはありますが、一覧の同じページを何度も読み込む必要はありません。

そこで、38本の個別テストファイルを、共通テストと記事ごとの期待値・専用の検査へ移しました。たとえば一覧やサイトマップは共通で取得し、各記事が載るべき状態かを同じ結果から照合します。検索と詳細URLも各記事の公開状態に合わせて確かめます。ニュース・ブログ用のRSSでは、業界レポートが混ざっていないことを確認します。

記事に設定した公開時刻はテスト用の一覧と照合し、その一覧の時刻も独立した記事ごとの期待値と突き合わせます。公開後に見える本文や図表、出典リンクも記事固有の確認項目です。たとえば人材サービスのレポートには、出典リンクの件数と個々のURLを確かめる専用の検査が残っています。公開ページで図表と出典を見る

変更の種類に応じて検証範囲を決める

次の表は10月の改修時点の運用です。ゲートとは、変更をGitHubへ送る前にローカルで動く自動検査を指します。ブラウザ検証（E2E）は、ビルドしたサイトをブラウザで開き、ページや検索などが期待どおりに動くかを確認します。

変更	何を検証するか
ブログのMDX（記事ファイル）だけ	記事データの形式や公開条件を自動テストで確認し、サイトをビルドして記事に関係するブラウザ検証を実行する。
影響先と対応するテストが分かるサイトコード	型やビルドを確認し、変更したコードを読み込むページをたどる。そのページに登録したブラウザ検証を選ぶ。著者の表示設定の変更が一例。
共通レイアウト・公開判定・依存関係、または影響先を判定できない変更	全体検証に戻す。影響先が分かっていても、対応するブラウザ検証が登録されていないページを含む場合はここで扱う。

全体検証や予約公開面が検証対象に入る一部の変更では、予約公開の境界も検査します。予約公開テストに登録したレポート全件で、設定時刻を境に公開判定が切り替わるかを確かめ、代表例では公開直前と公開時刻を再現してサイトをビルドします。公開前の確認用ビルドも、通常の公開面とは別に検査します。

変更ごとの検証とは別に、全体検証を週次で実行する手順があります。10月の改修では、最終差分に対して全体ゲートを実行し、通常のブラウザ検証と予約公開境界の検査が通った記録があります。この記事で確認した全体検証の実行記録は、その改修時のものです。週次ジョブの起動履歴は集計していません。

ローカルゲートの2つの実測

同じマシンの別の作業コピーで共通の基準コミットを固定し、依存関係を導入済みでビルドキャッシュがある状態で計測しました。それぞれのファイルにコメントを1件加え、通常のローカルゲートを各1回実行しています。検証範囲はゲートの自動判定に従い、2件とも部分検証として記録しました。

変更（各1回）	実行した検査	経過時間
ブログのMDX 1ファイル	記事データの形式・公開条件などを確認するテスト、ビルド、記事に関係するブラウザ検証	106秒（1分46秒）
著者定義 1ファイル	全単体テスト、型、ビルド、関連するブラウザ検証、予約公開境界、公開前の確認用ビルドでの検査、通常のビルド成果物への復元	360秒（6分）

出典はフィールフロウの2026年10月のローカル検証記録です。時間に含めたのはゲートの起動から終了までです。2件で変更ファイルと検査の構成が違うため、同じ変更の改善前後を比べるデータはここにはありません。記事の執筆・レビュー・本番反映や、人が手を動かした時間も、この計測の対象外です。

自社で見直すなら、変更1件から始める

まず普段の変更を1件選び、読者に影響するページを挙げます。たとえば記事の公開日時を変えるなら、詳細URLだけでなく、一覧や検索から早く見つかってしまわないかも確認します。次に、公開前の非掲載など、残すべき検査を決めます。

時間を見直すなら、ゲート全体と、その中のビルド・ブラウザ検証を分けて測ります。どこに時間がかかったかが分かれば、同じページの再取得を減らせるのか、そもそも関連する検査だけで足りるのかを、別々に検討できます。短縮幅を確かめるときは、同じ変更を同じ環境で測ります。

データの集め方と確認範囲

期間は2026年10月1日0時以上、11月1日0時未満（日本時間）です。対象はフィールフロウのこのサイト1件です。
ブログ22本は、10月末の本番用ブランチに収録された日本語ブログのうち、記事データ上の日付が10月で、下書きフラグが立っていない固有URLの数です。英語ブログ・ニュース・業界レポート・メディア記事は集計対象外です。22 URLは11月7日に本番サイトマップと照合しました。記事データの日付と確認時の掲載状況から数えており、初回公開の実時刻は集計していません。本番サイトマップ
PRの件数はGitHubの記録をマージ時刻で絞り、マージ先のブランチ別にPR番号を数えたものです。未マージのPRは除きました。これは変更の統合記録で、デプロイの成功回数やAIの関与割合を測った指標は含みません。
テストファイル数と時間は、改修前後のコード差分とローカル検証記録から確認しました。PRと検証ログの原本は社内資料です。公開ページでは記事と出典リンクの表示を確認できます。月全体の運用工数やAI導入の前後差を算出できる計測は、この調査では揃いませんでした。