末尾改行でハッシュ不一致？成果物同一性と復旧

2026-07-212026-07-29

監査を通った成果物が、公開直前の照合で止まりました。文章が壊れていたわけではありません。比較する側が末尾改行を取り除いたため、記録済みの版だけが別物として扱われたのです。

自動化を運用していると、「見た目は同じなのにハッシュが違う」という停止に出会うことがあります。時間を優先すれば、成果物を作り直すか、記録を更新して先へ進みたくなる場面です。しかし、監査済みの成果物を扱う境界では、その判断は証拠を失わせます。

今回の復旧で確認できた原則は明確です。成果物の同一性は、便利な正規化より先に守る。監査対象を比較するときは、文字列を整えるのではなく、記録されたまま比較します。

監査済み成果物・作業中のファイル・記録済み版

照合には、少なくとも三者が関わります。

品質監査を通過した記事は、公開直前に不一致として判定され、処理はrc=1で停止しました。この時点で外部への送信は行われていませんでした。

調査すると、期待した成果物と作業中のファイルのSHA-256は一致していました。不一致を作ったのは、記録済み版を読む共通処理です。この処理だけが.strip()によって末尾改行を落とし、その値をハッシュ化していました。

人が画面で読む限り、末尾の改行はほとんど意識されません。けれども、ハッシュ比較では内容の一部です。1文字を取り除けば、同じ文章に見えても同じ成果物ではありません。

正規化そのものが悪いわけではありません。検索語の比較、一覧表示、入力欄の扱いやすさなどでは、前後の空白を整える処理が役立つことがあります。

ただし、監査・署名・ハッシュ・再開判定の境界は別です。そこでは、表示上の読みやすさより証拠の保存が優先されます。末尾改行、空白、改行コードは小さく見えても、content-addressedな照合では成果物を構成する情報です。

今回の修復では、記録済み版の本文を改変せずに読む専用の読み出しを用意し、末尾改行を保持する検証を追加しました。focused testは24件、構文チェック、差分の空白エラーチェックを通過しています。

表示と実体がずれる問題は、監視画面や集約表示でも起こります。状態をまとめるほど、古い情報や細部が見えにくくなる点は、先行する集約は化石を隠す — 粒度を割った初日に9日物が出るでも扱いました。今回の差分は画面の表示ではなく、証拠として扱う本文の読み出し境界にありました。

今回、照合が止まったこと自体は正しい挙動でした。不一致を「おそらく同じ」と見なして外部へ送るより、止めて調べるほうが安全です。

重要なのは、停止後の再開方法です。今回確認したのは、既存の記録済み版が対象の記事だけであること、そして監査済み成果物と記録済み版が改変なしで一致することでした。再生成や再記録、既存記録の上書きはしていません。

安全な再開には、次の順番が必要です。

ここでいう「そのまま」は、見た目ではなくbyte-exact、つまりバイト列まで一致していることです。監査の根拠を守るため、便利な補正を判断の前に入れないことが要点になります。

復旧後は、公開ページがHTTP 200を返し、意図したキャンペーンと一致することを確認しました。公開状態と当日分の処理もcompleteになりました。

この確認は、単に送信処理が成功したこととは別です。送信が成功しても、外部で読めなければ受け取り手にとって公開は完了していません。完了条件は少なくとも、記録との一致、送信、外部での可視化を分けて考える必要があります。

自宅サーバーや小規模な自動化では、停止を減らす工夫に目が向きがちです。しかし、監査対象を扱う処理では「止まる設計」と「安全に再開する設計」を一組で持つほうが、後から説明できる運用になります。

小さな空白や末尾改行を軽視しないことは、細部にこだわるためではありません。監査済みの成果物を、監査済みのまま受け渡すためです。便利な正規化は表示や検索に任せ、証拠を比較する境界では記録された内容を守ります。

この検証を回している環境

この検証は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。

よかったらシェアしてね！