自社サイトの古い記載と社内の正本との食い違いを毎月点検して、ページ担当者への修正依頼にまとめる

処理の起点を決める

毎月1日の朝7時を起点にします。Schedule Trigger の月の間隔で、Day of Month を1、Hour を7、Minute を0にします。

タイムゾーンを必ず確かめてください。 Schedule Trigger は、ワークフローかインスタンスのタイムゾーン設定に従います。セルフホスト版の既定は America/New_York です。そのままだと、日本時間の1日の夜に動きます。 ワークフローの設定で Asia/Tokyo を指定します。

ワークフローは保存して公開（有効化）しないと、スケジュールでは動きません。 作っただけで安心して、1か月後に何も出ていないことに気づく、という取りこぼしが起きやすい部分です。

もう1つの起点として、正本が変わったときの臨時点検を置きます。料金表の改定や店舗の移転が決まったら、Web担当が手動で「旧い値の全ページ検索」を走らせます。これはAIを使わず、旧い値（「9,800円」「〇〇町1-2-3」）とその書き換え（「9800円」「1丁目2番3号」）を文字列で全ページから探す処理です。月次の割り当てを待つと、古い料金が最長で6か月残るため、この経路だけは別に作ります。

入力データを集める

旧い値を正本に残しておくことが、この構成の要です。 料金表に「今の料金」しか無いと、ページに書かれた「9,800円」が旧料金なのか、別のサービスの料金なのか区別できません。旧料金と終了日、旧住所と移転日の列を正本に足してください。 正本の持ち主にとっても手間は数分です。

ページ担当者表は最初に作る必要があります。 /shop/ 以下は店舗運営部、/column/ 以下はマーケティング部、のようにURLの階層で決めると、1,100ページでも表は30行程度に収まります。

データの取得方法を決める

ページの一覧： HTTP Request ノードで sitemap.xml を取得し、XML ノードの XML to JSON で変換します。サイトマップが複数に分かれている（サイトマップの目次がある）場合は、目次を読んでから各サイトマップを取り直します。 CMSのプラグインが作るサイトマップでは、ページ種類ごとに分かれていることが多いためです。

今月の対象の選び方： Code ノードで決めます。

• 重要ページ（トップ、料金、店舗一覧、会社概要、よくある質問など20本）は毎月
• 残りは、URLを6つの組に分け（URLの文字列から番号を作り、6で割った余り）、月ごとに1組ずつ
• 前回の点検から lastmod が新しくなったページは、組に関係なく今月に回す

3つ目で、書き換えた直後のページの取りこぼしが減ります。 担当者が料金だけ直して、注記を古いまま残す、ということが起こるためです。

本文の取得： HTTP Request ノードで取得します。Items per Batch を1、Batch Interval を2,000ミリ秒程度にし、順に取ります。「Include Response Headers and Status」をオンにして、ステータスコードも受け取ります。 「Never Error」をオンにすると、404や500が返ってもワークフローが止まらず、ステータスを見て「ページが消えている」という指摘に回せます。

自社のサーバーでも、事前に情報システムや制作会社へ連絡してください。 不正アクセスの防御機能が、巡回を攻撃と見なして止めることがあります。取得元の固定IPを許可リストに入れてもらうのが確実です。

本文の抽出： HTML ノードの Extract HTML Content で、本文の要素（main や article、CMSのテーマで決まるクラス名）をCSSセレクタで指定します。Skip Selectors に nav, footer, .sidebar, .related-posts のようにメニューや関連記事の枠を入れます。「Clean Up Text」で余分な空白を詰めます。

ヘッダーとフッターを除く理由は、同じ指摘が1,100回出るのを防ぐためです。 フッターの住所が古ければ、それは全ページに出ます。共通部品は、本文とは別に1回だけ点検します。

画像とPDF： 本文内の画像の代替テキストと、PDFへのリンクは拾いますが、中身は読みません。 「画像やPDFの中は未点検」と記録し、人が見る一覧に回します。

AIへ渡す前に整形する

1. 本文の長さの確認 … 抽出した本文が極端に短い（300字未満など）ページは、セレクタが合っていないか、JavaScriptで中身を描くページです。AIに渡さず data_gaps に入れます
2. 表記の正規化 … 全角数字、カンマの有無、「円」と「¥」、電話番号のハイフンを、照合用にそろえます。表示用には元の文字列を残します
3. 候補の抽出 … Code ノードの正規表現で、金額、日付（「2025年3月31日まで」「今春」）、電話番号、郵便番号と住所、製品名の辞書に当たる語を拾います
4. 正本の行を引く … 拾った値に関係する正本の行だけを取り出します。店舗ページなら、その店舗の行と、旧住所を持つ行。正本を丸ごとAIに渡さないためです
5. リンクの確認 … 本文内のリンクを重複を除いて集め、HEADで状態を確かめます。404・410、別ドメインへの転送、社外リンクのタイムアウトを記録します。同じ行き先は1回の実行で1度だけ確かめます
6. 前回の指摘との突き合わせ … 前回「修正済み」とされた箇所の文字列が、まだ本文に残っていないかを先に見ます

リンクの確認はAIにさせません。 切れているかどうかはステータスコードで決まる事実で、判断の余地がありません。

AIに処理させる

計算処理にさせること：

生成AI（Claude API）にさせること：

5つ目が、機械的な文字列照合では出来ない部分です。 「以前は9,800円でしたが、現在は7,800円です」という文は、旧料金を含んでいても正しい記載です。文脈を読んで、誤りと正しい言及を分けることを、AIに任せます。

「今春オープン予定」「来月から」のような相対的な時期表現も、AIに見させます。 書いた時点では正しくても、2年後には誤りです。ページの最終更新日と今日を渡して、その表現がもう古いかを判断させます。

文章の良し悪しや、言い回しの改善はさせません。 指摘が文体の話で埋まると、事実の誤りが埋もれます。「校正」は、事実の食い違いを直す範囲に限ります。

指示内容を固定する

あなたは自社サイトの記載内容を点検する担当者です。
下のページ本文を、社内の正本と照らし合わせ、
お客様に誤った情報を伝えている箇所を見つけてください。

【厳守事項】
- 指摘は、ページ本文にそのまま書かれている文字列を page_quote に引用してください。
  引用は本文から一字一句そのまま写し、要約や言い換えをしないでください。
- 正本の値は、下に与えた正本の行からそのまま写してください。
  与えられていない正本の値を推測で書かないでください。
- 本文の値が正本のどの行とも対応しない場合は、誤りと決めつけず、
  type を "正本に無い値" にしてください。
- 旧い値に触れていても、正しい文脈の記載は指摘しないでください。
  例：「以前は9,800円でしたが、現在は7,800円です」は正しい記載です。
- 「今春」「来月から」「新しく」のような時期の表現は、
  下に与えた最終更新日と今日の日付を比べ、すでに古くなっている場合だけ指摘してください。
- 文体、言い回し、誤字の直しは指摘しないでください。事実の食い違いだけを扱います。
- suggested_fix は、page_quote を正本に合わせて最小限に書き換えた文にしてください。
  周りの文章の書き直しや、新しい説明の追加をしないでください。
- 食い違いが無ければ findings を空にし、no_issue を true にしてください。
  **無理に指摘を作らないでください。大半のページは問題がありません。**
- 本文に書かれていない内容（画像やPDFの中身）について推測しないでください。

【指摘の種類】
終了したキャンペーン ... 実施期間表で終了日を過ぎたキャンペーンを、実施中として案内している
料金の不一致 ... 料金表の現行料金と違う金額を、現在の料金として書いている
営業時間の不一致 ... 店舗マスタと違う営業時間・定休日を書いている
住所・電話の不一致 ... 店舗マスタの現住所・電話番号と違う。移転前の旧住所を含む
提供終了の製品 ... 提供状況が「提供終了」の製品を、申し込める・買えるものとして書いている
旧名称 ... 名称変更前の製品名・店舗名・部署名を使っている
期限切れの時期表現 ... 相対的な時期の表現が、今日の時点で古くなっている
正本に無い値 ... 金額・住所などが正本のどの行とも対応せず、正誤を決められない

【重要度】
high ... 料金、住所、電話、営業時間、終了したキャンペーンの申込案内
medium ... 提供終了の製品、旧名称
low ... 期限切れの時期表現、正本に無い値

【今日の日付】{today}
【ページのURL】{url}
【ページの最終更新日】{lastmod}

【ページ本文】
{page_text}

【本文から機械的に拾った候補】
{candidates}

【関係する正本の行】
{master_rows}

「一字一句そのまま引用」の1行が重要です。 引用が本文と一致すれば、後段の Code ノードで「本文にその文字列が含まれるか」を機械的に確かめられます。一致しない引用は、AIが作った文である可能性が高いので、一覧に出す前に外します。

「正しい文脈の記載は指摘しない」も必須です。 料金改定のお知らせ記事には、旧料金が必ず書かれています。これを全部指摘すると、改定のたびにお知らせのページが誤りとして並び、担当者は一覧を読まなくなります。

「正本に無い値」という逃げ道を用意してください。 これが無いと、AIは本文の金額を、正本のいちばん近い行に無理に結び付けて「料金の不一致」と言います。正誤が決められないものは、決められないと言わせるほうが、確認は速くなります。

お知らせ記事の扱いを先に決めてください。 「2024年4月より料金を改定します」というお知らせは、当時の事実を書いた記録です。過去の日付で公開されたお知らせを今の正本と比べると、ほぼすべてが食い違いになります。

扱いは3つに分かれます。

2つ目をおすすめします。 古いお知らせそのものは誤りではありませんが、終わったキャンペーンの申込ボタンが生きていることは、明らかな誤りです。 お知らせのページでは、次の指示をプロンプトに足します。

【厳守事項（お知らせ記事の場合）】
- このページは {published_date} に公開されたお知らせです。
  公開日時点の事実として書かれた記載は指摘しないでください。
- 今日の時点で、読者に申込・来店・購入を促している箇所
  （リンク、ボタン、「お申し込みはこちら」などの文）だけを点検してください。

出力形式を固定する

{
  "page_url": "",
  "checked_at": "",
  "no_issue": false,
  "findings": [
    {
      "type": "終了したキャンペーン | 料金の不一致 | 営業時間の不一致 | 住所・電話の不一致 | 提供終了の製品 | 旧名称 | 期限切れの時期表現 | 正本に無い値",
      "page_quote": "",
      "master_value": "",
      "master_source": "",
      "suggested_fix": "",
      "severity": "high | medium | low",
      "reason": ""
    }
  ],
  "data_gaps": []
}

Claude API では、output_config.format に type: "json_schema" とスキーマを渡すと、応答をスキーマに沿った形に制約できます。type と severity は enum で固定します。公式の説明では、文字列の長さの制約（minLength maxLength）や数値の範囲の制約はスキーマでは使えません。 page_quote が空でないこと、長すぎないことは、後段の Code ノードで確かめます。

master_source に、正本のどの表のどの行かを入れさせます。 「料金表 行18（スタンダードプラン、2025年10月改定）」のように書かれていれば、Web担当は正本を開かずに確認できます。

suggested_fix は、ページ担当者がそのままCMSに貼れる文にします。 担当者の多くはWeb担当ではなく、店舗運営や事業部の人です。「料金が違います」とだけ言われても、どう直せばよいかで手が止まります。

data_gaps には、点検できなかった範囲を入れます。「本文が300字未満でJavaScript描画の可能性」「画像内の文字は未点検」「PDF 2件は未点検」といった内容です。これが多いページは、人が目で見る一覧に回します。

システムへ連携する

修正依頼の一覧をスプレッドシートに作ります。1行を1つの指摘にし、ページ担当者の部署ごとにフィルタで見られるようにします。

Web担当の確認を通ったものだけを、担当者へ依頼します。 Slack への通知は、確認が済んだ時点で担当部署のチャンネルへ、件数と一覧へのリンクだけを送ります。AIの出力をそのまま担当者に流さないでください。 誤検出が混ざった依頼を2回受け取ると、担当者は3回目から開きません。

共通部品（フッター・ヘッダー・サイドバー）の指摘は、別のシートにまとめます。 依頼先はページ担当者ではなく、CMSのテーマを管理する人か制作会社です。1か所直せば全ページが直るため、優先度は最上位に置きます。

同じ誤りが複数ページにある場合は、1つの依頼にまとめます。 旧住所が12ページに残っていれば、12行を1件の依頼にし、URLを並べます。担当者は1回の作業で全部を直せます。

CMSへの書き込みや、ページの非公開化は自動で行いません。 終わったキャンペーンのページも、非公開にするか、終了の注記を入れて残すかは、検索からの流入や問い合わせの扱いによって変わります。

人が確認する

severity が high の指摘と、正本に無い値 を、Web担当が確認します。

月200ページのうち、指摘が付くのは2〜3割程度のはずです。半分以上に付くなら、プロンプトか正本のどちらかに問題があります。

確認の深さを分けます。

• 終了したキャンペーンの申込案内 … お客様が申し込んでしまう。その日のうちに依頼する
• 料金・住所・電話・営業時間 … 正本の行と見比べて、その週のうちに依頼する
• 正本に無い値 … 正本の持ち主に確認する。正本の漏れであることが多い
• 提供終了の製品・旧名称 … まとめて月内に依頼する
• 期限切れの時期表現 … ページ担当者の判断に任せる

確認を速くするための設計が効きます。

• 本文の該当箇所と正本の値を、横に並べて表示する
• ページのURLを開くと、該当箇所へ飛べるようにする（URLの末尾に文字列の位置を付ける）
• 前回「誤検出」とした指摘と同じものには、印を付ける
• 共通部品の指摘を最上部に固定する

3つ目が効きます。 誤検出として外した理由を一覧に残しておくと、翌月同じ指摘が出たときに一目で外せます。同じ誤検出が3か月続くなら、プロンプトに例外として書き足します。

例外に対処する

記録を残す

この記録は、古い記載がどこから生まれているかを知る材料になります。

• 月ごとの点検対象、点検したページ数、指摘の件数と種類
• 各指摘の Web担当の判断（依頼した／誤検出／正本側を直す）と理由
• 修正までにかかった日数、翌月の再確認の結果
• data_gaps の内容と、点検できなかったページの一覧
• 正本が変わった日と、臨時点検で見つかったページ数
• AIの引用が本文と一致しなかった件数

「正本が変わってから、サイトが直るまでの日数」を必ず残してください。 料金改定から全ページが直るまで何日かかったかが分かると、改定の手順に「サイトの臨時点検」を組み込む根拠になります。

種類ごとの件数の推移も見てください。 「終了したキャンペーン」が毎月多いなら、キャンペーンのページを作るときに終了日を決めて、終了後の扱いまで先に決める運用に変えるべきです。点検で直すより、作るときに防ぐほうが安く済みます。