更新ログ：変更内容と変更日時を表示する

更新ログとは、実質的なページ変更の日付付き記録です：何が変わったか、なぜ変わったか、回答、推奨、または証拠が動いたかどうかを示します。

更新ログ

2026年8月27日 — 価格と推奨を更新 廃止されたStarterプランを現在のEssentialsプランに差し替え、比較表を更新し、監査エクスポートが必要なチーム向けの推奨を変更しました。ソースはベンダーのプラン文書に照らして再確認しました。

2026年5月12日 — エビデンスを更新、結論は変更なし 廃止された2つの機能参照を差し替え、残りのプラン制限を検証しました。推奨オプションに変更はありませんでした。

各日付は検証可能なイベントに関連付けられています。単なる「2026年8月27日更新」では説明が不十分であり、ログは作業の範囲と結果を明らかにします。

この要素が重要な理由

読者はすべての変更を同等に扱うわけではありません。見出しのスペルミスを修正することと、推奨を覆すこと、データセットを差し替えること、安全でない指示を修正することは同等ではありません。単一の更新日付はこれらのイベントを同じシグナルに圧縮します。支出、手順の実行、研究の解釈、またはポリシーの理解に使用されるページでは、読者は依存しているセクションが変更されたかどうかを知る必要があります。

更新ログは、読者にキャッシュされたコピーを比較させることなく履歴を保存します。次の4つの質問に答えます：ページはメンテナンスされたか？変更は自分に影響したか？エラーは公開された形で修正されたか？結論はまだ支持されているか？明確な回答は説明責任を生み出し、意味のある作業なしに日付が進められた偽りの新しさを防ぎます。

活動ではなく結果を報告してください。「リンクを更新しました」は行動を説明します。「2024年の市場総計のための撤回されたソースを差し替えました。値と結論は変更ありません」は読者に何が信頼できるままかを伝えます。結論が動いた場合は、その旨を明確に述べてください。

機械抽出可能性により、ソフトウェアは各イベントを日付、タイプ、要約、詳細、影響を受けるセクション、証拠参照に分離できます。安定したフィールドにより、監査は修正を見つけ、エージェントは変更された推奨を説明し、移行は履歴を保存できます。一貫性のない散文は、ソフトウェアにイベントの開始と終了を推測させます。

したがって、この要素の型付き目的は、視覚的に類似したタイムラインや箇条書きリストよりも優先されます。要素記述ルール に従ってください：コンテンツが現在のページへの改訂を記録する場合、更新ログとしてエンコードしてください。レンダラーはリスト、カード、または展開可能なアーカイブを使用する可能性がありますが、正規のイベントフィールドはすべての表現で存続しなければなりません。

使用すべき場合

読者が現在のページと以前のページを比較する必要がある可能性がある場合に更新ログを使用してください。トリガーには、変更された推奨、修正された事実、改訂された方法、差し替えられたデータセット、変更された計算、新しいバージョン、変更された対象資格、更新された価格モデル、修正された指示、またはアーカイブされたオプションが含まれます。

この要素は、権威が時間とともに蓄積される場合に最も価値があります。研究では修正された分母を受け取る可能性があります。ドキュメントでは新しいインターフェースをサポートする可能性があります。規制説明では修正を編集上の明確化と区別する可能性があります。黙ったままの書き換えは、戻ってくる読者が必要とする履歴を破壊することになります。

範囲を限定したレビューで変更が見つからなかった場合、レビューエントリを控えめに使用してください。「Reviewed」とラベル付けし、確認した内容を明記し、結論が変更されていないことを述べてください。これは変動の激しい統計、価格、製品機能、ルールに適していますが、活動をでっち上げる許可ではありません。

類似しているが異なるケースには別の対応が必要です：

• 公開日または修正日： フレッシュネススタンプ を使用して、正規のページ日付を公開します。スタンプとログは連携して機能することもありますが、一方が他方の代わりにはなりません。
• 製品リリース履歴またはプロジェクトタイムライン： これらは主題の変更を説明します。更新ログは現在のページへの編集上の変更を記録します。
• バージョン管理出力： コミットメッセージには実装上のノイズ、内部識別子、セキュリティに敏感な詳細が含まれます。これらは読者向けの編集記録ではありません。
• ソースリスト： ソースブロック は主張の出典を証明します。更新ログはそれらのソースや主張がいつ、なぜ変更されたかを示します。
• 軽微なメンテナンス： スペル、句読点、書式設定、画像圧縮、分析、トラッキングパラメータ、テンプレート移行は、変更が意味やアクセシビリティを変更しない限りログに記録しないでください。

実質的な改訂がないページには、空のパネルや架空の履歴ではなく、公開日が必要です。

配置場所

完全なログは、回答、証拠、結論、ソースの後、ただし関連コンテンツ、ニュースレターキャプチャ、またはクロージングコールトゥアクションの前に配置してください。読者はまず現在のページを必要とし、次にその履歴を必要とします。研究、統計、ポリシーページでは、ログは一般的にソースまたは方法論の後に続きます。

最新の変更がページの読み方に影響する場合は、ヒーロー日付の横に「変更点を見る」を追加し、完全なログにジャンプしてください。そこでエントリを複製しないでください。安全性、金銭、対象資格、または結論に影響する訂正には、修正された主張の横にも通知が必要です。

ログは、両者が明確に区別されている限り、著作者情報と同じメンテナンス領域を共有しても構いません。購入ボタン、期間限定オファー、カウントダウン、評価、推薦文、またはプロモーションバッジの隣に配置してはいけません。そうすると履歴が緊急性や暗黙の推奨に変わってしまいます。ソースブロックに統合しないでください：ソースが変更された理由は編集履歴であり、引用ではありません。

正規のログは1つだけ保持してください。サイドバーはリンクしても構いませんが、複製してはいけません。5エントリを超えたら、最新の3〜5件を表示し、残りは「以前の更新を表示」で公開してください。完全な履歴はページ上または安定した管理されたアーカイブに保持してください。

構造

1. 要素タイトル：「更新ログ」「改訂履歴」、またはページデザインの外でも明確な、承認された簡潔なラベルを使用します。
2. イベント日付： 絶対的なカレンダー日付を表示し、同じ値をISO 8601機械タイムスタンプとして公開します。
3. イベントタイプ： 色に頼らずにupdated、corrected、reviewed、method-changed、archivedを区別します。
4. 要約： 変更された対象と結果を1行で簡潔に示します。
5. 詳細： それらの情報が読者のページ解釈に役立つ場合、以前の状態、新しい状態、理由を説明します。
6. 影響を受けるセクション： オプションで、転用されないフラグメントを使用して、変更された安定した見出しや図にリンクします。
7. 結果： 回答、結論、推奨、対象資格、または指示が変更されたかどうかを示します。
8. エビデンス参照： オプションで、ページのソースブロックですでに定義されているソース識別子を指します。
9. アーカイブコントロール： 文書やアクセシビリティツリーから削除せずに以前のエントリを表示します。

エントリはスタイリングなしでも理解可能でなければなりません。アイコン、線、色だけでタイプや結果を伝えてはいけません。

デザイン例

バリエーションは情報密度と編集リスクを反映しています。

コンパクトな最新変更行

単一のシンプルな改訂には1つのコンパクトな行を使用します。日付、タイプ、要約、結果を含めます。説明が2文を超える場合は標準リストを使用してください。

標準改訂リスト

2〜5エントリには最新優先のリストを使用し、すべてのエントリで同じフィールド順序を維持します。

訂正先行バリアント

重大なエラーについては、「訂正」とラベル付けし、誤った状態と修正された状態、影響を示し、影響を受けるセクションにリンクします。アラーム的な言葉を使わずに強調してください。

方法またはバージョン変更

データセット、計算式、製品バージョン、管轄区域、または方法が変更された場合、旧バージョンと新バージョンを表示します。以前の結果が比較できなくなった場合にその旨を記載してください。

展開可能なアーカイブ

5エントリを超えたら、エントリ数と日付範囲でアーカイブにラベルを付けます。見出しとリスト構造を保持し、JavaScriptだけが記録にアクセスする手段にならないようにしてください。

狭いビューポート

日付、タイプ、要約、詳細を縦積みにします。モバイルで日付を切り詰めたり、結果テキストを非表示にしたりしないでください。

パラメータ

親フィールドがコレクションを制御し、繰り返されるアイテムフィールドが各イベントを説明します。

エントリは繰り返されるアイテムであり、単一のHTMLフィールドではありません。親の最初の見出しはtitleにマッピングされ、各アイテムの最初の見出しはsummaryに、残りの本文はdetailにマッピングされます。日付、タイプ、影響、参照、バージョンは属性として残ります。

impactは必須であり、読者が回答が動いたかどうかを推測しないようにします。資料に結論がない場合のみnot-applicableを使用してください。編集のないレビューではtype=reviewedとimpact=unchangedを使用します。

構文とコード例

すべての表現は同じフィールドを保持します。ソース識別子は正規のソースブロックを参照します。

ポータブルMarkdownディレクティブ

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Hugoショートコード契約

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

これは既存のショートコードではなく、アダプター契約です。すべてのパラメータは名前付きです。

WordPressブロック

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPressは日付、タイプ、影響、セクション、エビデンスに対して構造化されたコントロールを公開する必要があります。

例

良い更新エントリ

2026年7月18日 — 計算を訂正 「チャネルパフォーマンス」表において、コンバージョン率の分母を全セッションから該当製品セッションに訂正しました。オーガニック検索の値は3.1%から2.4%に変更されましたが、チャネルの順位と記事の結論は変更されていません。基礎となるセッション数には影響はありませんでした。

これは、エラー、新旧の定義、影響を受けるセクション、数値的な結果、結論のステータスを示しているため機能します。読者は以前の作業のレビューが必要かどうかを判断できます。

悪い更新エントリ

2026年夏 — 完全リフレッシュ！ このページをレビューし、すべてが最新であることを信頼していただけるよう、いくつかの改善を行いました。

これは、日付が曖昧で、「完全に」が範囲を過剰主張し、「いくつかの改善」が事実を隠し、「信頼」が獲得していない結論を要求するため失敗です。作業が見た目だけのものであれば、エントリを削除してください。実質的なものであれば、判断に関わるすべての変更を明記してください。

スキーママークアップとアクセシビリティ

更新ログには独立したSchema.orgタイプはありません。これは包含するArticle、TechArticle、またはReport内のコンテンツとして残ります。最新の実質的なイベントはdateModifiedをサポートする場合がありますが、変更のないレビューはサポートしてはいけません。datePublishedを置き換えないでください。

エントリをCreativeWork、Event、HowToStep、またはItemListとしてエンコードしないでください。これらのタイプはログにない意味を含意します。予測可能なHTMLを使用してください：ラベル付きセクション、リストアイテム、見出し、<time datetime="2026-08-27">2026年8月27日</time>、安定したフラグメント。

イベントごとに1つのリストアイテムを使用してください。CSSは順序を変更せずにタイムラインを描画しても構いません。エントリが最新優先であることを明示してください。色やアイコンだけでなくテキストでタイプを表示し、説明的なリンクを使用してください。

アーカイブには、その数または範囲でラベル付けされたネイティブのディスクロージャーが必要です。すべてのエントリはキーボードとスクリーンリーダーで到達可能でなければなりません。ARIAライブリージョンを使用しないでください。見出し順序とローカライズされた日付を保持してください。

影響を受ける主張箇所に訂正通知を配置し、ログにも記録してください。前者は直接の読者を保護し、後者は履歴を保存します。

記述ルール

変更された対象と正確な動詞で始めてください：「対象資格ルールを明確化」「データセットを差し替え」「計算式を訂正」。要約は4〜14語、詳細は25〜90語に抑えてください。変更と理由に1文、影響に別の1文を使用してください。ローカライズされた絶対日付と最新優先の表示を使用してください。

結果の前に理由を説明してください。「ベンダーがStarterを廃止したため、Essentialsに差し替えて推奨を再評価しました」は原因を記録します。「比較を改善しました」は意見を記録します。中立な過去形を使用してください。

すべての実質的なエントリは次の質問に答えるべきです：

• どの特定の事実、指示、方法、ソース、範囲、または結論が変更されたか？
• なぜその変更が必要だったか？
• ページのどこで発生したか？
• 主要な回答、推奨、または結論は変更されたか？
• 読者は以前のバージョンに基づいて判断やアクションをやり直す必要があるか？

編集イベントごとに1つのエントリを作成し、キーストロークごとには作成しないでください。1回のレビューからの関連する変更をグループ化し、無関係な作業、異なる影響、または異なる日付は分割してください。3〜5件を表示し、実質的な履歴を保持してください。

機密メモ、セキュリティ詳細、脆弱性、個人データ、責任の帰属、生のコミットハッシュ、説明のないチケット、マーケティング、緊急性、参考文献を含めないでください。「100%最新」を約束したり、訂正を消去したり、エントリを黙って書き換えたり、表面的な作業を再日付したりしないでください。

エントリに訂正が必要な場合は、その日付を保持し、訂正イベントを追加してください。プライバシー、セキュリティ、または法的義務により編集が正当化される場合があります。その場合は、記録が修正されたこととその理由を適切なレベルで記載してください。

使用する投稿タイプ

postTypesフロントマター配列がこの表のソースです。「必須」とは、実質的な改訂履歴がフォーマットの信頼契約の一部であることを意味し、「条件付き」とは、該当する変更が発生した時点でログが表示されることを意味します。

新しいページには空のログは必要ありません。該当する変更の後は、要素を保持してください。

QAチェックリスト

• 表示されているすべてのエントリが、表面的または自動化された変更ではなく、実質的な編集イベントを表している。
• イベント日付が正確で、有効で、未来でなく、承認された編集記録と一致している。
• 要約が変更された対象を明記し、4〜14語に収まっている。
• 詳細が、利益を説明する前に何が変わったか、なぜ変わったかを述べている。
• エントリが、回答、結論、推奨、対象資格、または指示が変更されたかどうかを特定している。
• 重大な訂正が影響を受ける主張の隣にも表示されている。
• セクションフラグメントとエビデンス識別子が、同じ正規ページ上の安定したターゲットに解決される。
• ログがメインコンテンツとソースの後、プロモーショナルなクロージングモジュールの前に表示されている。
• ログがCTA、オファー、評価、推薦文、またはソースブロックと視覚的に統合されていない。
• 日付はセマンティックな<time>値を使用し、イベントタイプと影響は色やアイコンに依存していない。
• アーカイブコントロールがキーボード操作可能で、明確にラベル付けされ、その完全なコンテンツを支援技術に公開している。
• レビュー専用エントリはdateModifiedを変更せず、実質的な最新イベントは正規の更新日付と一致している。
• 機密メモ、個人データ、セキュリティ詳細、生の実装履歴、マーケティング言語が存在しない。
• ページの投稿タイプと読者のリスクが要素を正当化している。

FAQ

すべてのコンテンツ編集が更新ログに含まれるべきですか？

いいえ。事実、指示、証拠、範囲、解釈、推奨、または読者の判断を変更する編集を記録してください。スペル、間隔、トラッキング、テンプレート、その他の実質的でない編集は省略してください。

更新ログは最終更新日とどう違うのですか？

最終更新日は実質的な変更が発生したことを示します。更新ログは何が変わったか、なぜ変わったか、回答や結論が動いたかどうかを記載するため、メンテナンスの主張を検証できます。

新しい更新と古い更新のどちらを先に表示すべきですか？

メンテナンスされているページでは、読者は通常現在の変更を必要とするため、最新のエントリを最初に表示してください。機械出力では時系列順を保持し、表示リストを短くする場合は明確にラベル付けされたアーカイブを提供してください。

更新ログは訂正通知の代わりになりますか？

いいえ。重大なエラーには、影響を受ける主張箇所での目立つ訂正と、永続的なログエントリの両方が必要です。ログは履歴を保存するものであり、ページ下部に訂正を隠してはいけません。

変更のないレビューはログに表示すべきですか？

レビューステータスが読者にとって重要であり、エントリが「Updated」ではなく「Reviewed」とラベル付けされている場合のみ表示してください。確認した範囲と実質的な変更が不要であったことを記載し、dateModifiedは変更しないでください。