公開した数字は片側だった——読者が公開リポから数え直し、2 日で 3 回訂正した（5 面 → 訂正 4 面 → 翌朝そろったのは 2 面）

Posted at 2026-09-29

「誇張しない」ために、記事の元データを全部公開してきました。生成したコード 120 本・当方の裁定・検出器のルール・集計スクリプト。公開すれば読者が検証できる、と書いてきました。

実際に検証されたので、何が起きたかを書きます。読者は当方の成績表が片側しか無いことを見つけました。主要な訂正を 2 日で 3 回、追加の反映を 1 回入れました。同じ実験を扱う公開面は 5 つ、数字を持つ訂正対象は 4 面、翌朝そろっていたのは 2 面でした。

結果を先に書きます。

読者（本人の希望で「a reader」）が公開リポの gt.csv と生成コードから数え直し、3 通のコメントで指摘しました。2 通目には読者自身による 1 通目の言い直しも含まれます。3 通を通じて最終的に残った検証可能な指摘は、当方が現物で再確認して全部成立しました
初回の指摘で再現できなかった数字が 1 つありました。当方の台帳に「読者が再計算できる列」が無かったからです。列を 1 本足したら一致しました
訂正は主要 3 回＋追加反映 1 回（dev.to の本文を更新。手元の控えで数えて 25,614 字 → 32,933 字）。Lab・Qiita・リポの README と ARTICLE.md も更新しました
同じ実験を扱う公開面は 5 つ（dev.to・自サイトの Lab・Qiita・リポの ARTICLE.md・note）。数字を書いているのは 4 つ。翌朝に点検したら、4 つのうち 2 つが旧数字のままでした。うち 1 つは、索引で「正本」と書いていたファイルでした

n＝1 記事・1 スレッドの記録です。「公開すれば読者が検証してくれる」とは言いません。この 1 回では、そうなりました。

検出器の成績そのもの（何を拾い、何を巻き添えにしたか）は別の記事「同じ Python 60 本に検出器を 2 つ当てたら」に分けました（末尾の関連）。この記事は公開後に何が起き、訂正がどこまで届いたかだけを扱います。

この記事の位置づけ（2026-09-26 追記）

この記事で新しく示すこと: 公開リポから読者が数え直して見つけた「片側だけの成績表」と、訂正が 4 面のうち 2 面にしか届いていなかった経緯。
当てはまる範囲: 当方の 1 実験・読者 1 名です。
言葉: 本文の「器」＝点検や処理のための自作スクリプトのことです。

何を公開していたか

公開面	中身
Qiita（日本語）	元の記事。「AI が書いたコードは失敗を握り潰すか」——120 本を測った結果
dev.to（英語）	同じ内容の英語再構成
自サイトの Lab	別軸版（結論・検証の記録・evidence へのリンク）
公開リポ `ai-silent-defect-scanner`	生成コード 120 本・`results/gt.csv`（当方の裁定つき）・Semgrep のルール・集計スクリプト・ARTICLE.md
note	物語版。数字は書いていない

記事の主張は「検出器は 4 件を挙げ、4 件とも偽陽性だった。握り潰しは構文だけでは裁定できない」でした。

読者は何を見つけたか

1 通目（09-16）: 成績表の後半が無い

読者は Semgrep を持っていなかったので、当方のルールを AST の照合として書き直し、同じ 4 件を再現した上で書いてきました。

The detector's report card is missing its second half.

当方の記事は「4 件 flagged・0 件 TP」＝精度の側だけを書いていました。ところが当方自身の gt.csv には、真の握り潰しと裁定した行が 4 件あります。出荷したルールはその 4 件を 1 件も挙げていません。再現率 0/4 です。

当方が gt.csv で数え直した結果、挙げられた 6 つの数字のうち 5 つが一致しました。残る 1 つは、台帳の列からは途中までしか出ません。try/except を持つ行の「外側でも既定値を返しているか」を、当方の台帳は記録していなかったからです。

2 通目（09-17 未明）: 読者自身の言い直しと、列の提案

読者は自分の 1 通目を言い直してきました。「精度 0/4・再現率 0/4」は 1 つの 2×2 に見えるが違う。4 件 flagged は Python 2＋TypeScript 2、真の 4 件は Python だけなので、言語を分けて書くべきだ、と。

同時に、台帳に形の列（subtype）を足す提案が付いていました。当方は生成スクリプトに列を足し（commit 82e5130）、8 行が埋まり、1 通目で再現できなかった数字が再現しました。手で埋めた版と生成器の出力は 1 行だけ食い違い、生成器のほうが正しかったので生成器を採用しました。

3 通目（09-17）: 修正を当て直した上での 2 点

読者は当方の修正 2 つを元データに当て直して再現を確認した上で、当方が書いていなかった 2 点を足してきました。「4 件 flagged」は 1 つの検出器の出力ではなく 2 つのルールの和集合であること。TypeScript 側は Python と課題を 2 つしか共有していないので対照群として読むべきこと。

主張は 8 点。当方が集計スクリプトの出力と生成コードで照合し、8 点とも成立しました。README（a000ebe）と Corrections に反映しました。

訂正は主要 3 回＋追加反映 1 回

回	いつ	何を直したか	面
主要 1	09-16 夜	TL;DR と結果に再現率 0/4 を追加。「射程の穴」と「1 文アンカー」を分けた。TypeScript の列欠けを Limitations に	dev.to
主要 2	09-17 朝	言語を分けた。Corrections に 09-17 項	dev.to・Lab・リポ
主要 3	09-17 朝	TypeScript の形の列を追加。「11 本未裁定」を明記	dev.to・Lab・リポ
追加反映	09-17 昼	3 通目の 2 点を Corrections に	dev.to・README

（その後、09-18 に 4 通目の指摘で主要 4 回目が入りました＝「TypeScript は標本の構成上、正例が空」という当方の一文を撤回し、未裁定だった 2 本を legit_fallback と裁定、当方の「49 本」も読み違い（正しくは 22 本）でした。今度は dev.to・Qiita・README・記事・Lab の 5 面を同日に同期しています。本記事の数字は 09-17 時点のままです。）

dev.to の本文は、手元の控え（更新前 1 枚・更新後 4 枚）で数えて 25,614 字から 32,933 字になりました。増えた分の大半は Corrections 節です。誰の指摘で、当方が何を再現でき、何を再現できなかったかを書いています。

ここまでは順調でした。問題は翌朝です。

公開面 5 つのうち 2 つで止まっていた

同じ実験を扱う公開面は 5 つあります。訂正の当日に更新したのは dev.to と Lab でした。翌朝、残りを点検しました。

面	数字を書いているか	点検時の状態
dev.to	はい	更新済み
Lab（自サイト）	はい	更新済み
Qiita（日本語の元記事・同期の起点）	はい	旧数字のまま → 点検中に更新
リポの ARTICLE.md	はい	旧数字のまま。それどころか 7 月 14 日の訂正も入っていなかった
note（物語版）	いいえ	対象外

数字を書いている 4 つのうち 2 つが止まっていました。

ARTICLE.md は、当方の索引で「正本記事」と書いていたファイルです。Qiita の本文に 7 月 14 日の訂正を入れたとき、リポ側には入れていませんでした。「正本」と書いたファイルが、写しである Qiita より古かったわけです。今回の訂正で初めて気づきました。

同期の向きを Qiita → ARTICLE.md に決め、Qiita の本文で ARTICLE.md を上書きしてから 09-17 の訂正を入れました（db59832）。

何が効いて、何が効かなかったか

効いたもの:

生データと裁定を公開していたこと。読者は当方のルールを再実装し、当方の裁定表で当方の検出器を採点しました。当方が「4 件」と書いた数字を、当方の表が否定していました
Corrections 節に「再現できなかったこと」も書いたこと。1 通目で途中までしか出ないと書いたら、2 通目で列の提案が来ました

効かなかったもの:

訂正の伝播。5 つの面に置いた時点で、どの面が数字を持ち、どの向きに同期するかを決めていませんでした。決めたのは今回、止まっているのを見てからです
「正本」の札。索引は ARTICLE.md を「正本記事」と書き、運用は Qiita を起点に直していました。宣言上の正本と、運用上の更新起点が食い違っていたのです。ファイルに正本と書いても、更新の手順に組み込まれていなければ古くなります。7 月から 2 か月、誰も気づきませんでした

持ち帰り: 2 系統を分けて持つ

この 1 回で分かったのは、「公開後の訂正を完了させる」には別々の 2 系統が要る、ということです。

再導出可能性——読者が当方の数字を当方のデータから出し直せるか。

生データ・裁定表・ルール・集計コードを同じリポに置く
裁定表には「読者が再計算できる列」を入れる。今回は形の列が欠けていた
成績表は精度と再現率の両方を、言語ごとに書く

訂正伝播——直した数字が全部の面に届くか。

面の一覧と、数字を持つ面を先に書き出す
正本と更新起点を 1 か所に揃え、同期の向き（正本 → 写し）を決める
訂正のたびに全面を点検する表を持つ

今回使った 1 枚: 訂正の伝播表

面	数字あり	正本／写し	訂正日	点検日	状態
dev.to	○	写し（英語）	09-16, 17	09-17	✅
Lab	○	写し（別軸）	09-17	09-17	✅
Qiita	○	正本	09-17	09-17	✅（点検で発見）
ARTICLE.md	○	写し（Qiita から）	09-17	09-17	✅（点検で発見・7 月分も）
note	—	対象外	—	—	—

この表は今回の分です。次の訂正から使います。

この 1 本から言えること／言えないこと

言えること:

公開したデータで、読者が当方の成績表の片側の欠けを見つけました
3 通を通じて最終的に残った指摘は、当方の現物照合で全部成立しました。1 つの数字は当方の台帳に列が無く、足したら一致しました
5 つの公開面のうち数字を持つ 4 つで、点検時に 2 つが旧数字でした。1 つは「正本」と書いていたファイルで、7 月の訂正も欠けていました

言えないこと:

「公開すれば読者が検証してくれる」とは言いません。1 スレッドです
「面を増やすほど訂正が止まる」とは言いません。観測は 4 つ中 2 つです
「3 通の主張が最初から全部正しかった」とも言いません。2 通目は 1 通目の言い直しを含みます
読者の検出器の成績が「正しい成績表」だとも言いません。その評価は別の記事に分けました
読者の名前・所属は書きません

再現したい人へ

公開リポ ai-silent-defect-scanner の results/gt.csv で human_verdict == problematic_fallback を数えると 4。handling == swallow_cand の Python 行と突き合わせると交わりは 0
dev.to の記事末尾の Corrections 節に、3 通の指摘と当方の再現結果が日付つきで載っています
面の点検表は上の表をそのまま使えます。列は 6 つで足りました

AI の利用について

数え直し・列の追加・訂正の下書き・この記事の下書きは AI（Claude Code）が行い、裁定・返信・公開の判断は人が行っています。読者の指摘は読者のものです。