更新履歴の書き方：いつ何を直したかを読者に伝える欄の作り方

まず押さえる検索側の前提（2026年10月29日に確認）

Googleの記事の公開日に関するガイド（ページ上の最終更新表記は2025年12月10日UTC）では、次の点が示されています。

• 日付は利用者に見える形で表示し、「Published」「Last updated」のようにラベルを付けることを推奨している。
• 構造化データでは datePublished と dateModified を使う方法が挙げられている。
• 見える日付と構造化データの日付は一致させる。
• 時刻は任意だが、正確なタイムゾーンを付けることが勧められている。
• 将来の日付は避け、ページ内で複数の日付が混在するときは整理を検討する。

Article構造化データのページでも、両プロパティはISO 8601形式で、タイムゾーン付きが推奨されています。どちらも必須ではありません。

さらに、Googleの役に立つコンテンツの考え方（ページ上は2026年10月5日UTC更新）には、「内容が大きく変わっていないのに、新しく見せるためにページの日付を変えていないか」という自己点検の問いがあります。内容が大きく変わっていないのに、新しく見せることを目的に日付を変えるのは避ける、という趣旨です。

ただし、「何文字以上直したら更新日を変える」といった基準は公式には示されていません。以降の判断表は、読者への説明責任を軸にした編集上の提案です。

軽微な修正か内容変更かを分ける判断表

迷ったら「読者の行動や判断が変わるか」で分けます。

• 誤字脱字、句読点、表記ゆれ、区分：軽微、更新日：動かさない、履歴への記載：不要（任意で月ごとにまとめる）
• リンク切れの差し替え（行き先の内容は同じ）、区分：軽微、更新日：動かさない、履歴への記載：一言で残す
• 画像の差し替え（内容は同じ）、区分：軽微、更新日：動かさない、履歴への記載：不要
• 手順の追加・削除・順序変更、区分：内容変更、更新日：動かす、履歴への記載：必須
• 数値、料金、上限、期限の変更、区分：内容変更、更新日：動かす、履歴への記載：必須（旧→新を書く）
• 結論や推奨の変更、区分：内容変更、更新日：動かす、履歴への記載：必須（理由も書く）
• 製品の仕様変更への追従、区分：内容変更、更新日：動かす、履歴への記載：必須（確認した公式ページも書く）
• 見直したが変更なし、区分：確認のみ、更新日：動かさない、履歴への記載：確認日だけ更新

「軽微」でも、リンク先が別の情報になっていたなら内容変更として扱います。

書き分けの文例（説明用の例）

履歴は新しい順に、1件1〜2行で並べます。

軽微な修正の書き方

2026年10月28日　誤字と表記ゆれを修正しました（内容の変更はありません）。
2026年10月28日　リンク切れを修正しました（参照先は同じ公式ページです）。

軽微な修正は、まとめて1行にして構いません。毎回書くと履歴が長くなり、重要な変更が埋もれます。

内容変更の書き方

2026年10月28日　手順3の画面名を新しい表記に合わせ、手順4を追加しました。
2026年10月28日　無料プランの利用上限の記述を、公式ヘルプの現行表記に合わせて修正しました（旧：○○ → 新：△△）。
2026年10月28日　結論を変更しました。以前は「A方式を推奨」と書いていましたが、条件によってはB方式が適するため、判断表を追加しました。

型は「何を（場所）＋どう直したか（旧→新）＋なぜか（任意）」です。「内容を更新しました」だけの行は、日付を動かす意味が伝わらないので避けます。

確認のみの書き方

2026年10月28日　公式ヘルプを再確認しました。記載内容の変更はありません。

確認日を出すなら、確認した対象を書きます。「最新の情報を確認済み」のような対象のない文は、読者が確かめようがありません。確認していない項目まで確認済みと読めないよう、範囲を限定してください。

日付表示の運用ルール

自分のサイトに合わせて調整する前提で、最小限のルールを挙げます。

1. ラベルを付ける：「公開日」「最終更新日」のように意味を明記します。ラベルなしの日付は、公開日か更新日か読み取れません。
2. 日付の種類を増やしすぎない：本文上部に公開日と最終更新日、末尾に更新履歴の欄、までに抑えます。確認日は履歴欄の中に入れます。
3. 表示と構造化データを一致させる：画面の「最終更新日」を変えたら、dateModified も同じ日に変えます。テーマやプラグインが自動で出力する場合、どちらが元になるかを確認してください。
4. 内容変更のときだけ更新日を動かす：判断表の「動かす」に該当した日が更新日です。
5. 未来の日付を入れない：予約公開も、公開された時点で日付が合っているか確認します。
6. 日付形式とタイムゾーンを固定する：表示は「2026年10月28日」、構造化データは +09:00 などのオフセット付きに統一します。

構造化データの書き方の例（説明用。Rich Results Testなどでの検証はしていません）：

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "説明用の記事タイトル",
  "datePublished": "2026-09-01T09:00:00+09:00",
  "dateModified": "2026-10-28T10:30:00+09:00"
}

この例の場合、画面にも「公開日：2026年9月1日」「最終更新日：2026年10月28日」と表示します。

AIに下書きを任せる依頼文と、人が確認すること

履歴の下書きは、修正前後の本文を渡せばAIで作れます。ただし、AIは「読者にとって重要か」「確認を実際にしたか」を知りません。そこは人が決めます。

渡す情報は、修正前の該当箇所、修正後の該当箇所、確認した公式ページのURLと確認日です。社内の非公開情報や個人情報が含まれる場合は、架空の値に置き換えてから渡します。

依頼文の例です。

次の修正前と修正後を比べ、更新履歴の1行案を作ってください。
- 軽微（誤字・表記ゆれ・リンク修正）か、内容変更（手順・数値・結論の変更）かを先に判定する
- 内容変更なら「場所＋旧→新＋理由」の形で、80字以内で書く
- 軽微なら「内容の変更はありません」と書く
- 修正前後に書かれていない理由や確認作業は推測で足さない
- 判定の根拠を1行添える

【修正前】（ここに貼る）
【修正後】（ここに貼る）
【確認した資料】（URLと確認日。なければ「なし」）

人が確認する点は3つです。

• 判定（軽微か内容変更か）が判断表と合っているか。
• 旧→新の数値や名称が、実際の記事と公式ページの両方に一致しているか。
• 「確認しました」と書く場合、本当にそのページを開いて見たか。

公開前チェックリスト

• [ ] 今回の修正を判断表で区分した
• [ ] 内容変更なら、履歴に「場所＋旧→新」を書いた
• [ ] 更新日の変更が、内容変更のときだけになっている
• [ ] 画面の最終更新日と dateModified が同じ日になっている
• [ ] 確認日を書く場合、確認した資料名を書いた
• [ ] 履歴の日付が未来になっていない