気づくことと、直すことは、別だった ── 訂正が届かない 3 つの範囲

間違いに気づいたら、直す。直したら、終わり。
私たちはそう思っている。

ところが実際には、直したあとに残るものがある。訂正が届かなかった範囲だ。

この記事は、その「届かなかった範囲」が3種類あることを、実測で確かめた記録だ。②と③は AI Ron が自分で見つけて自分で報告してきたもの、①と4本目は私の側の実測になる。

ひとつ先に書いておく。この記事は公開前の監査で一度 止まって、①を全部 書き直している。最初に書いた①が、5日前に公開した別の記事と同じ事例を使っていた。その経緯も、記事の後半で扱う。

---

範囲①：同じ記録が2箇所にあって、片方だけ直した

いちばん分かりやすい形から。これは私の側の実測だ。

記事のネタは、2箇所で管理している。1件ごとの詳細ファイル（以下「カルテ」）と、全体を一覧する索引ファイルだ。記事を公開したら、両方に「公開済み」の印を付ける決まりになっている。

🔬 あるネタを公開したとき
   索引の「執筆待ち」テーブル  → ✅ 取り消し線を引いた
🔴 同じネタが「未整理」テーブルにも在った → 手つかずのまま残った

同じネタが2つの表に載っていた。片方だけ直したので、もう片方は「まだ書いていないネタ」として、そのあと1ヶ月半 残り続けた。

この形を全数で測ってみた。カルテ69件と、本番に公開済みの記事88本を突き合わせた結果がこれだ。

分類	件数
🚨 カルテの状態が「未公開」なのに、本番には出ている	5件
🔴 索引側だけが古いまま	3箇所
⚠️ 索引に一度も載っていないカルテ	2件
🔵 逆向き（公開済みなのに本番に無い）	0件

訂正の効力は、訂正した場所にしか及ばない。当たり前に聞こえる。だが実務では、この「当たり前」が抜ける。

理由は単純で、直した本人の頭の中では、もう直っているからだ。1箇所 直した時点で「対応済み」という感覚が出る。同じ内容が別の場所にもあることは、直している最中には視野に入らない。

「直した」と「直したい対象が全部 直った」は、別のことだ。

そして厄介なのは、残った側が正常に見えることだ。ファイルは開ける。読める。エラーも出ない。ただ、内容が実態より古いだけだ。次にそれを読んだ人は、書いてあるとおりに判断する。

---

範囲②：訂正の後に書いたのに、訂正が入っていなかった

①より厄介なのがこれだ。

8/18  表記の規律を訂正した
🔴 8/19 と 8/21 に書いた原稿が、訂正前の形のままだった
✅ 公開前に気づいて直した

訂正したのは本人。その翌日と3日後に、本人が古い形で書いている。

①は「直した内容が、別の場所に届かない」という場所の話だった。②は時間の話だ。訂正を書いた本人が、訂正のあとに、訂正前の形で書いている。

なぜこうなるか。規律を訂正したという事実は記憶に残る。だが「次に書くときにその規律を思い出す」という動作は、記憶とは別に発火しなければならない。訂正したことを覚えていても、書いている最中にそれが呼び出されるとは限らない。

これは私の判断だが、②は①より悪い形だと思う。①は仕組みで塞げる（同じ内容が何箇所にあるかを、直す前に数えればいい）。②は「気をつける」の領域に落ちてしまい、同じ人が何度でも踏む。

---

範囲③：気づいた直後に、同じ道具をまた使った

3つ目が、いちばん短い時間で起きる。

① 判定に使った検索パターンが誤検出した
   （「日本語が含まれている」を「翻訳がある」と読んでしまう作りだった）
🔴 ② 直後の再確認で、同じパターンをそのまま使って、また誤検出した

誤検出に気づいて、その場の判定は訂正した。だがパターンそのものは直さなかった。だから次に使ったとき、同じところで壊れた。

AI Ron はその日、検証に使う道具を11回 壊している。そのうち2回がこの形だったという。

気づくことと、直すことは、別だった。

これは彼の言葉だが、この記事の芯そのものだと思う。誤りに気づいた瞬間、人の注意は「目の前の判定を訂正すること」に全部 向く。道具を直すという作業は、その視野に入らない。訂正して満足すると、道具はそのまま残る。

---

3つを並べると、共通点が出る

	何が起きたか	気づいていた時点
①	訂正が別の場所に及ばない	直した瞬間
②	訂正がその後に及ばない	訂正した後
③	気づいた直後に同じ穴を踏む	気づいた瞬間

3つとも、気づいていなかったわけではない。気づいていて、届かなかった。

この違いは対処法を分ける。「気づけていない」問題なら、検知の仕組みを足せばいい。だが「気づいたのに届かない」問題に検知を足しても、検知が1つ増えるだけで何も変わらない。必要なのは、気づいた内容が、どこまで自動的に適用されるかを設計することだ。

---

【技術コラム】訂正が届いた範囲を、あとから測る

「訂正が届いているか」は、感覚では判定できない。実際にコマンドで数えるのがいちばん早い。

① 直す前に、同じ内容がいくつの場所にあるか数える

1箇所 直して満足しないために、直し始める前に件数を出す。

# その項目が、いくつのファイルに載っているか
grep -rl '<項目を一意に特定できる語>' ./records/ | wc -l
# → 2 以上なら、1 箇所 直しただけでは終わらない

数えるのは直す前がいい。直したあとだと「もう直した」という感覚が働いて、数える動機が消える。

② 記録側の状態と、実物側の状態を突き合わせる

①より広く効くのがこれだ。記録が「未完了」と言っているものが、実物では完了しているケースを全数で洗う。

# 記録側で「未完了」のものを列挙し、実物側に在るかを確かめる
grep -l '^status: *\(ready\|writing\)' ./records/*.md | while read -r f; do
  title=$(grep -m1 '^# ' "$f" | sed 's/^# //')
  if grep -qF "$title" ./published-titles.txt; then
    echo "🚨 $f  （記録は未完了だが、実物は完了している）"
  fi
done

ここで出た件数が、更新が届いていない範囲だ。0件なら届いている。

ただし「0件」を信じる前に、必ず陽性対照を置く。更新漏れがあると分かっているファイルを1本 指定して、同じ手順が1件 返すことを先に確かめる。返らなければ、対象がゼロなのではなく判定側が壊れている。

# 陽性対照：更新漏れが在ると分かっているファイルで、判定が鳴るか
grep -m1 '^status:' ./records/known-stale.md
# → 期待する値が返らなければ、読み取り方が間違っている

そして逆向きも測る。「記録は完了なのに、実物が無い」ほうだ。実測では0件になることが多いが、0件だと確認できていること自体に意味がある。片側しか測っていない状態は、測っていない側が「無い」ことになってしまう。

⚠️ ひとつ注意がある。この方法はタイトルで突き合わせているので、実物側でタイトルを変えていると一致しない。実測では69件のうち1件がこれに当たった。記録側の見出しと公開時のタイトルが別物になっていて、完全一致では引っかからなかった。IDや連番など、途中で変わらない値で突き合わせるほうが確実だ。

③ 道具そのものを直したかを、記録に残す

③は自動で測るのが難しい。誤検出に気づいた瞬間に「判定を訂正する」だけで終わらせず、道具を直したかどうかを、その場で1行 記録するのが現実的な対処になる。

# 誤検出に気づいたときのメモの形
# ❌ 「A は誤検出だった。正しくは B」        ← 判定だけ訂正
# ✅ 「A は誤検出だった。正しくは B。
#     原因は針が <X> を拾っていたこと。
#     針を <Y> に直した（直していないなら『未修正』と書く）」

「未修正」と書いてあれば、次に使うときに気づける。何も書かなければ、直したのか直していないのか、翌日の自分には分からない。

---

実害が出たのは、①の5件のうち1件だった

範囲①で「カルテの状態が未公開なのに、本番には出ている」が5件あったと書いた。数えただけなら、ただの整理漏れだ。だが1件は実害になった。

🔬 8/24  ある記事を公開した（🔴 カルテの状態を「公開済み」にし忘れた）
🔴 9/01  「まだ書いていない」と判定して、同じ記事をもう一度 書いた
🔴       タイトルまで完全に同じものが、本番に2本 並んだ

更新を忘れたのは1行だ。その1行が、8日後に同じ記事を書かせた。

しかも同じ日に、別の記事でも同型を踏んでいる。そちらは索引側の取り消し線が漏れていて、7月に公開した記事とタイトルが一致した（その日の経緯は前回の記事に書いた）。こちらは公開前に監査で止まったが、上の1件は本番に出てしまった。

これは①の派生形だ。①は「直した内容が、別の場所に届かない」だった。こちらは「作業が終わったことが、記録に書かれない」。記事は公開された。だが公開したことを示す印は、別のファイルに手で書く必要があり、そこが抜けた。

作業が終わったことと、終わったと記録されていることは、別だった。

そして「まだ書いていない」という表示は、疑う理由を与えてくれない。ファイルは開ける。読める。エラーも出ない。ただ、内容が実態より8日 古いだけだ。

この記事を書いている最中にも、同じ形をもう一度 踏んだ。素材のファイルに「別の記事とはテーマが違う。混ぜるな」と、私自身が半月前に書いていた。その一文を読んで、私は内容を確かめずに書き進めた。公開前の監査で「その主張は成立していない。5日前の記事と同じ実例を使っている」と止められて、この節の前半を全部 書き直している。

「確認済み」と書かれたラベルは、確認する動機を消す。それが自分で書いたものであっても。

---

読者の方が、明日 試せること

手元に「直したもの」「状態を管理しているもの」があるなら、次の3つを順番に測ってみてほしい。10分あれば終わる。

1. 直す前に、同じ内容が何箇所にあるか数える。 直したあとだと「もう直した」という感覚が働いて、数える動機が消える。
2. 記録側と実物側を、両方向で突き合わせる。 陽性対照を先に置いてから、0件かどうかを判定する。片方向だけだと、測っていない側が「無い」ことになる。
3. 判定に使ったパターンが1回でも誤検出したら、その場でパターンを直す。 判定の訂正だけで先に進むと、次の確認で同じところに落ちる。

「気づいた」で終わらせないための、いちばん短い手順がこれだ。

---

この記事を直しているあいだに、また同じ形が出た

最後にひとつ。監査で止められた①を書き直したあと、記事全体を検索してみた。

🔍 「①」に言及している箇所を数えた → 5 箇所
🔴 そのうち 2 箇所が、書き直す前の①の内容を指したままだった
🔴 さらに導入部の 1 文も古かった
   → だがそこには「①」の語が無いので、この検索では出てこない

①の本体は直した。だが本文の別の場所に「①は◯◯という話だった」と書いた行が2つ残っていて、そこは古い①を説明していた。

そして3つ目は、検索では出なかった。導入部に「3つとも AI Ron の実弾だ」と書いていて、①が私の実測に変わった時点で嘘になっていたのだが、その一文には「①」という語が入っていない。別の観点で読み返して、初めて見つかった。

検索で見つかるのは、検索語を含むものだけだ。同じ内容を指していても、語が違えば出てこない。

つまりこの記事の範囲①そのものを、この記事を直しながら踏んだことになる。1箇所 直して、同じ内容が別の場所にもあることを、直している最中には見ていなかった。

直したら、直した対象を検索する。それだけで、この記事の①は塞げる。

---

②と③の実弾は、AI Ron が自分の失敗として数えて、自分から共有してくれたものだ。「記事に使ってもらってかまわない」という返事つきで。①と4本目、そしていま書いた5本目は、私の分になった。

人の失敗を整理していると、自分の同じ形が見えてくる。整理している最中に、また踏む。それも、この記事で分かったことのひとつだ。