AIサイト運用で「更新依
頼を止めない」CMS運用
設計と実装ログ

01.導入の背景

更新依頼が止まる主な原因は、確認作業・差し戻し・画像作成・公開手順の不明瞭さにあります。 AI支援型ヘッドレスCMSはこれらの工程を部分的に自動化し、一覧画面で次アクションを明示することで運用をスムーズにできます。 local hack の制作ログ（CMS/AIコンテンツ基盤の実装ログ）を一次情報候補として、実装で得た設計判断と、これから行う検証計画を共有します。

02.運用設計 — 更新依頼を止めないための原則

• 小さく自動化する：まず公開前チェック（必須項目、ブランド語句、数字整合）を自動化し、失敗率の高い工程から着手します。
• 可視化を最優先にする：記事一覧に「次にやること」と期限、担当を出し、滞留の原因を一目で分かるようにします。
• 人間の判断を残す：AIは下書き・画像案・チェック候補を出す役割に留め、最終承認は必ず人が行います。

03.公開前チェックの実装項目

1. 必須項目チェック（タイトル・リード・カテゴリ・著者・公開日時）。
2. ブランド語句・禁則語の自動検知。ルールは運用チームで編集可能にします。
3. 数字・通貨・リンクの整合性チェック（数値の単位、パーセントの表記、外部リンクのステータス）。
4. 画像の存在とALTの有無チェック。ALTはテンプレートで候補を生成して編集者に提示します。
5. 変更履歴の自動保存と差分レビュー機能。差分で重要な語句が変わった場合はフラグを立てます。

各項目は自動スコアをつけ、合格ラインを満たさない場合は公開ボタンを無効化するか、承認者の確認を必須にする設定にします。

クリックで拡大

04.本番反映確認とデプロイ検証

• プレビューデプロイ：編集完了時にステージングプレビューを自動生成し、担当者が1クリックで確認できるようにします。
• スモークチェック：デプロイ後にページステータス（200/404）と主要メタ（title、meta description、canonical）を自動取得して比較します。
• ロールバック設計：公開直後に問題検知時は自動で前バージョンに差し戻すか、即時非公開にできるオプションを用意します。

これらはCI/CDの一部として組み込み、公開イベントのログを残すことで「誰が」「いつ」公開したかを追跡できます。

05.画像生成と差し替えのワークフロー

• 画像案の自動生成：記事作成段階でALT候補とともに複数案をAIに生成させ、編集者がワンクリックで差し替えられるUIを用意します。
• 品質ルール：ブランドカラー、禁止表現、画像内テキストのフォント規則などをテンプレ化し、生成時にフィルタを通します。
• 生成タイミング：編集草稿段階で低解像度案を生成し、公開確定時に高解像度を生成・保存することでコストを分散します。

画像生成は現在制作ログとして実装済みのフローを参照しつつ、実際の品質評価は検証フェーズで定量化します。

06.記事一覧の次アクションUI設計

• 次アクションカード：一覧中に「次にやること」「期限」「優先度」「担当」を小さなカードで表示します。
• ステータスバッジ：公開前チェックのスコアを色で表現し、低スコアは目立つバッジで強調します。
• フィルタとレポート：滞留中の依頼を担当別・期日順でフィルタ可能にし、週次レポートに自動エクスポートします。

UIは運用チームのワークフローにあわせてカスタマイズ可能とし、まずは最低限の項目で運用を開始してから改善を繰り返します。

クリックで拡大

07.監視とKPI設計（検証プラン）

検証KPI（初期）：

• 編集開始→公開までの中央値（目標：短縮）
• 平均承認ラウンド数（目標：減少）
• 滞留中の依頼件数（目標：減少）
• 編集者当たりの作業時間（目標：削減）

方法：まず1〜2チームでベースラインを4週間計測、その後公開前チェック自動化＋次アクションUIを段階導入し、さらに4週間で比較します。必要なデータは編集ログ、承認ログ、デプロイログ、作業時間の自己申告です。

08.制作ログ（再現可能な実装手順）

1. CMS側に公開前チェックのエンドポイントを作成。チェックリストはJSONで定義し、編集画面からルールを更新可能にする。
2. 画像生成APIのインテグレーション（低解像度プレビュー→高解像度生成）。生成リクエストは公開イベントでキューイング。
3. ステージングプレビューはプレビューデプロイのWebhookで自動作成。URLは編集一覧で即時参照可能に。
4. 記事一覧に次アクションカードを実装。スコアリング結果を受けてカードの状態を変化させる。
5. 公開後スモークチェックをCIジョブとして実行し、異常検知時にアラートとロールバックをトリガーする。

この手順は site-content-agent-build-log の公開可能な部分を元に構成しています。実装中の設定値やシークレットは含めず、画面仕様とログフォーマットを公開する想定です。

クリックで拡大

09.今後の検証計画と公開予定データ

• フェーズ1（4週間）：ベースライン取得（編集・承認・公開の時系列ログ）。
• フェーズ2（4週間）：公開前チェックを稼働、KPIの変化を比較。エラー率・差戻し理由をタグ化して定量化します。
• フェーズ3（4週間）：次アクションUIと画像生成の本運用、ユーザ満足アンケート（reader-feedback-mini-survey）で定性的な評価を収集。

公開予定のデータ：週次KPI表、代表的な差戻しケースの匿名化ログ、改善前後の作業時間サンプル、UI変更のスクリーンショット。

10.実務担当者へのチェックリスト（すぐ使える）

• 導入前：現状の編集→公開プロセスをフロー図で可視化する。
• 初期実装：必須項目チェックとプレビュー自動生成を入れる。
• 運用開始：記事一覧に次アクションを表示し、滞留を週次でモニタする。
• 改善：差戻し理由をタグ化して多い順に対応策を作る。

11.編集上の注意と次のアクション

本稿は制作ログを元にした実装設計と検証計画を示しています。定量的な改善効果はこれからの計測で確定させる予定です。 次にやること：

• 小規模チームでベースライン計測を開始する。
• 制作ログ（公開可能箇所）を整理して実装テンプレート化する。
• reader-feedback-mini-survey を導入して定性的フィードバックを集める。

（編集者による人間の最終レビューが必要です。実装パラメータの決定と数値の公表はレビュー後に行ってください。）

— end of article · 2026.05.28 / updated 2026.05.28