KENSAI 製品アップデート: heartbeat 回復で 4月15日のコンテンツギャップを解消

KENSAI は 4月15日の同日公開を回復し、不足していた日次投稿を公開し、ブログインデックスを再構築し、必要な公開面で言語パリティが維持されていることを検証しました。

今日リリースした内容

今日のリカバリー作業は意図的に地味です。4月15日の公開ギャップを埋め、派生ブログインデックスを再構築し、公開されている言語セットが部分的な同日公開へ崩れることなく、ひとつのリリースとして動いていることを確認しました。

これは重要です。コンテンツの heartbeat はまず静かに壊れるからです。片方だけの投稿が存在したり、英語だけが必要な言語セットなしで公開されたり、HTML は出ているのにインデックスや overview ページが古いままだったりします。そうした状態はどれも published と見なすべきではありません。

1) Heartbeat 回復は、今ではファイル作成ではなく公開 proof を意味する

いちばん大きい変化は運用の正直さです。失われたコンテンツ heartbeat は、下書きファイルが存在するだけでは修復されたことになりません。レンダリング済みページが存在し、言語版が存在し、JSON インデックスがそれらを指し、公開ミラーが同じ日付を反映してはじめて修復完了です。

それにより、リカバリーは私的なチェックリストではなく、見える結果になります。ユーザーやクローラーが公開ツリーに到達して古い状態を見るなら、そのギャップは本当には閉じていません。

2) 言語パリティは修正条件のまま維持した

私たちは言語パリティを follow-up task ではなく release 条件として扱いました。アクティブな言語セットを今日の2本の投稿に結びつけたままにし、英語配信とローカライズ配信の間に新しいズレが生まれないようにしました。

これはプレッシャー下で最も安全なやり方です。まず英語だけを公開して他言語に後追いさせると、一時的なコンテンツギャップがそのまま恒常的なドリフトになります。

3) インデックス再生成は公開の一部であり、後片付けではない

HTML が出そろった後、派生ブログインデックスを再生成し、投稿一覧、メタデータ消費側、overview 面が同じ source of truth に戻るようにしました。インデックス再生成なしのリカバリーは、壊れ方をひとつ下の層に隠すだけです。

つまり workflow は今も proof-first のままです。実在するページ、実在する言語カバレッジ、再構築されたインデックス、その後に公開 output tree に対する検証です。

なぜ重要なのか

コンテンツエンジンが信頼を得るのは、きれいに回復できるときです。本当のテストは task が done と書かれているかではなく、公開システムが same-day set の存在と完全性を証明できるかどうかです。

守るべき基準はそこです。heartbeat が滑ったなら、修正はシステムが再び健全になったことを示す visible evidence を残すべきです。