Blog件数が243→252→256と変わった――公開・更新・測定・主張の4つの時点を分けて残す

同じ記事の中に、少なくとも4種類の「時間」がある

記事やKnowledgeを長く運用していると、「いつの情報なのか」を1つの日付だけでは表せなくなります。海辺の部屋では、今回の実例を整理するために次の4つを区別します。

• Published Time：そのコンテンツが最初に公開された時点。
• Updated Time：本文や構造を後から更新した時点。
• Measurement Time：件数・数値・CMS状態などを実際に測定した時点。
• Claim Time：本文中の主張が、いつの状態について述べているかという時点。

この4分類はWix公式の分類名ではなく、海辺の部屋で時点の違うEvidenceを混ぜないための編集上の整理です。

2023年に公開した記事が、2026年に更新されている

2026年9月29日にWix Blog APIから公開記事を全件取得すると、公開記事は256本でした。最古の記事「『海辺の部屋』へ、ようこそ！」は、firstPublishedDateが2023年1月5日、lastPublishedDateが2026年9月27日です。

今回取得した256本はfirstPublishedDateが2023年から2026年に分布する一方、lastPublishedDateはすべて2026年でした。少なくとも現在のWix Blogデータ上では、「最初に公開された年」と「最後に公開・更新された年」を同じものとして扱えません。

ただし、lastPublishedDateだけから、各記事のどの文章を何文字直したか、なぜ再公開したかまでは分かりません。更新日時の存在と、更新内容の中身は別のEvidenceです。

243→252→256は、1つの数字が訂正されたのではない

過去の作業記録にはBlog記事数243、その後の引き継ぎ記録には252という値があります。そして2026年9月29日の再取得では256本でした。

この3つを「どれが正しい数字か」という1本の競争にすると、時間軸が消えます。記事数は増減するため、数値には「いつ測ったか」というMeasurement Timeが必要です。過去の243や252をすべて256へ書き換えると、その時点で何を見て判断していたかを後から追えなくなります。

一方で、243を測った正確な日時は今回確認できませんでした。そのため「2026年9月○日時点で243本だった」のように、Evidenceにない日付を追加しません。「過去の作業記録に243という値がある」までを確認済みとして残します。

Claim Timeを残すと、過去の監査記録を壊さずに済む

既存Knowledge「107 Knowledge監査で91件にlegacy categoryが残っていた――分類のSource of TruthをPrimary Clusterへ一本化した実例」は、2026年9月28日の107本監査時点を扱っています。

翌9月29日の本記事制作開始時、Wix CMSのKnowledgeは108本でした。それでも既存記事の「107」を108へ置き換えません。107という数値は「現在のKnowledge総数」を永久に表す数字ではなく、「その監査をした時点の母数」を表すClaim Time付きの数字だからです。

過去の主張を現在値へ更新する必要がある場合は、古い主張を消すのではなく、「当時は107」「現在は○○」のように時点を分けます。履歴を残す記事では、最新化と歴史保存を同じ編集操作にしません。

現在件数の置き場所と、過去の記録を分ける

記事が増えるサイトで、記事末の案内にも「このテーマには現在N件」と書いていると、集計欄を直しただけでは各記事の文まで更新されません。

後の118記事時点の監査報告には、その固定件数文が53記事にあり、42記事は分類の件数と一致せず、11記事は一致したと記されています。一致していた文も、記事が増えれば再び更新が必要です。今合っているかに加えて、同じ現在値を何か所で保守することになるかを考える必要があります。

この事例から整理した方法は、数字を置く場所と用途を次の3つに分けることです。

• 現在件数の集計項目：記事管理システム（CMS）の件数用項目を表示元とし、取得・再計算した時点を残す。海辺の部屋では、全体集計のKnowledgeStatsや、分類ごとの件数を保存するarticleCountがこれに当たります。
• 本文中の案内：更新のたびに「現在N件」を書き直す代わりに、その分類で何を読めるかを説明する。書き方の例は「この分類では、出典を確かめる方法をまとめています」です。
• 過去の監査や測定の記録：その時点の対象数として残し、現在値へ置き換えない。測定日が分からない場合は、不明のままにする。

当時のAIは、現在件数を説明する固定文を減らし、集計項目と過去の監査値を残したと報告しました。今回確認したのはこの方針と報告文であり、全変更の差分や保守工数の削減は独立に検証していません。

なお、数字をCMSから表示することと、その集計値が自動で更新されることも別です。更新する主体やタイミングを設計する場合は、KnowledgeStatsで分けた3種類の自動化へ進みます。

CMSの日付フィールドと、主張の時点は別に考える

海辺の部屋のKnowledgeでは、verifiedDateはEvidenceを確認した時点、updatedDateはKnowledge本文や構造を更新した時点として使っています。Wix CMSにはさらに、アイテム作成・更新のシステム日時である_createdDateと_updatedDateがあります。

しかし、これらの日時があるだけで、本文中の「107 Knowledge」という主張がいつの状態を指すかまで自動的に表せるわけではありません。Measurement TimeやClaim Timeが重要な数値は、Evidenceや本文の中にも「2026年9月28日の監査時点」のように対象時点を明示します。

確認できない時点は、無理に埋めない

時点管理の目的は、日付欄をすべて埋めることではありません。後から見たときに、「これは現在値か」「過去の測定値か」「当時の主張か」を区別できることです。

今回なら、256本は2026年9月29日のAPI再取得で確認済みです。243本の正確な測定日時は未確認です。この差をそのまま残す方が、確認できていない日時を推測で埋めるよりEvidenceとして強くなります。

GSCでの具体例：GSCがPASSならSEO改修は反映済みか？登録状態・再クロール・効果を分けて確認するでは、SEO変更日と最終クロール日時、改修前後の検索実績を分けて確認します。

このKnowledgeの関連知識

過去時点の数値を残す実例：107 Knowledge監査で91件にlegacy categoryが残っていた――分類のSource of TruthをPrimary Clusterへ一本化した実例。このKnowledgeで分けたMeasurement Time / Claim Timeを、2026年9月28日の107 Knowledge監査値を現在値へ書き換えず保持している実例で確認する。

検証状態と時点を別軸で管理する：出典URLがあることと、内容を事実確認したことを分ける。出典を知る・本文を確認する・主張と照合するという検証状態に加え、その事実がいつ成立していたかという時間軸を分けて扱う。

「いつ」と「何の日付を基準にしたか」を分ける：売上総額がほぼ同じでも、集計基準が違えば同じデータではない――注文日と発送日の実例。本Knowledgeは測定・主張の時点を扱い、売上記事は注文日・発送日という集計基準を扱う。どちらも時間情報だが別の問題であることを対比する。