検証ログの書き方｜抜粋元・判定・誤判定まで残す運用

検証は実行して終わりではない。何をどの原本と突き合わせ、どう判定したかを残して初めて、次の記事の検証に効く。本サイトでは記事13本とツール紹介ページ3本ぶんの検証記録を1本のログに積んでいる。本稿はその実物の形と、記録が実際に効いた場面である。

検証ログの形

ログの冒頭には目的が一文で置いてある。記事ごとに1節、節の頭に「方法」を1行で宣言し、続けて4列の表を置く。列は通し番号・本文位置・抜粋元・結果である。

# docs/hub-articles/article-verification-log.md から抜粋
# （冒頭の目的文と、記事01 節の方法宣言＋表 全5行のうち1行）
記事ごとに、本文のコードブロック・引用ブロックの検証方法と結果を記録する（articles-code-example-contract の申告）。

方法: writer 申告の抜粋元一覧に基づき、原本ファイルを Read して一字ずつ突き合わせ。

| # | 本文位置 | 抜粋元 | 結果 |
|---|---------|--------|------|
| 3 | コードブロック（記事ゲート条件） | `doand-hub\docs\hub-articles\articles-phase-plan.md` L74-79 | ✅ 一致（見出し行の `**` 強調記号のみ除去） |

要点は結果欄にある。「一致」だけでは記録として足りない。抜粋は原文そのままではなく、たいてい何かしら手が入る。強調記号を落とす、原本の折返し改行を結合する、長い表から数行だけ取る。だから結果欄には、一致という判定に加えて何をどう正規化したかを書く。「改行結合のみ」「全9行中5行・省略4行の内訳も明示」といった具合である。ここを書いておくと、後から読む人が原本を開いたときに差分の理由を推測せずに済む。

表の外には、揮発情報の扱いと、実行して確かめる必要があったコマンドの有無を、該当する節で書き添える。抜粋の照合で足りる記事と、実際に走らせないと確かめられない記事では検証の重さが違うので、「本記事には無し（抜粋のみ）」のように、無かったことも明記するのが望ましい。無記入と「無し」は読み手にとって別物である。正直に言えば、この点は本ログでも徹底しきれていない節がある。

何を残し、何を残さないか

残すのは五つである。第一に抜粋元の特定情報、つまりファイルパスと行番号。ファイル名だけでは再検証できない。第二に判定とその根拠、すなわち上記の正規化内容。第三に、誰の言い分かの区別である。抜粋元の一覧は書き手の申告であり、一致か否かは検証者の判定であり、そこに別コンテキストのレビュアーの独立確認が加わる。三者を区別せずに書くと、誰も原本を見ていない記述が「確認済み」の顔をして残る。第四に数値の出典と測り方。行数や本数を書いたなら、どう数えたかまで記す。第五に揮発情報の確認日と、記事の字数（統一基準）である。

残さないものもはっきりしている。本文の再掲はしない。原稿を開けば済むうえ、二重に持てば必ず片方が古くなる。会話上のやり取りも原則として残さない。判断の経緯は成果物か規約に落ちて初めて意味を持つので、ログの中心は照合できるファイル証跡とし、会話由来の記録はゲートに諮る申し送りと環境の注記に限っている。

記録が効いた場面

第一に、誤判定を消さずに残せる。検証者が「一致」と判定した行を、後からレビュアーが blocker として差し戻した事例が2件ある。その行は書き換えて✅にするのではなく、⚠から✅へ至った経過として1セルに畳んである。詳細はレビューの実録で扱った。

第二に、独立した経路の結果が並ぶ。上の2件でレビュアーがしたのは、検証者と同じ資料を同じ単位で読み直すことではなく、現物を測り直すことと、原文を別の単位で読み直すことだった。その結果もログの同じ節に書き足すので、一つの節に別経路の判定が併存する。ログは独立照合の入力ではなく、その着地点である。

第三に、教訓が規約へ還元される。数値のずれを起こした記事の節には教訓を1行で添えてあり、これが後日、記事制作コマンドの手順そのものに入った。

# .claude/commands/write-article.md 手順3 から抜粋（前後省略）
# …
   数値（行数・件数等）はインベントリ等の記録値でなく**現物を測り直して**照合する
   （2026-07-16 記事09 の教訓: 記録値は作成後にドリフトする。検証ログ参照）

教訓が出たのは自作スキルの記事を書いた 2026-07-16 で、手順への追記はその1か月半後、別の記事のレビュー対応（2026-08-30）である。ログに残っていなければ、間の期間で消えていただろう。

第四に、後続記事での素材の再利用を判断できる。ある記事が、以前の記事と同じ進捗表から抜粋したとき、ログには同じ資料の別断面であり意図的な選択だと記した。重複の指摘に対して、後から根拠を示せる。

検証ログの限界

ログもまた中間成果物であり、その時点の照合結果でしかない。数値のずれの事件は、まさに記録値との照合で起きた。ログを信じて現物を見なければ、同じ穴に落ちる。

だから日付を必ず付す。実際、後の再確認でスキルの行数はふたたび動いていたが、当該記事は「2026-07-16 の実測で」と日付を明示していたため依然として正確であり、修正不要と判定できた。日付のない「42〜78行」なら、この判定はできない。

ログは再検証の起点であって、検証の代替ではない。次の記事で同じファイルを扱うとき、ログが省くのはどこを見ればよいかを探す手間だけで、見に行く手間ではない。ログが正しいことの保証は、ログの外の現物にしかない。

よくある質問

記録のコストは見合うか。 1記事あたり表1つである。そもそも記事ゲートの条件が「抜粋元パス or 検証記録あり」なので、記録は検証の上に積む追加作業ではなく、ゲートを通過する根拠そのものである。

git の履歴で足りないのではないか。 差分は残るが、判断は残らない。なぜ一致と判定したのか、何を省略として扱ったのか、どの数値をどう数えたのかは、コミットの差分からは復元できない。

まとめ

残すのは、抜粋元のパスと行、正規化を含む判定の根拠、申告者と判定者の区別、確認日である。誤判定を消さずに残せば、次の手順を変える材料になる。ただしログ自体も古くなる。日付を付し、再検証の起点としてだけ使う。止める側の仕組みは別稿で扱った。止める仕組みと残す記録は対である。