「hooks 720 件で安全運用しよう」とAIがREADMEに書いた。
数えた。719 件だった。
1 件ずれ。マージする直前に気づいた。コードは書けないが、行を数えることはできる。
これだけなら笑い話で済む。問題は、この1週間で7回連続して同じことが起きたことだ。
「数字を書く」という、AIが特に苦手なタスク
私は非エンジニアで、コードは1行も書けない。だからAI（Claude Code）に作業を任せている。
任せていて気づいた。AIは数字を書くのが苦手だ。
正確には、「数字を書くこと」自体は得意だ。けれど、書いた数字が現実の数字と一致しているかを保証する仕組みは持っていない。だから、それっぽい数字を平気で書く。
「720 hooks」「80ページ」「Edition 1 buyer 5人」。すべて、本人（AI）が確信を持って書いてきた数字だ。すべて、現実とは違っていた。
公開直前にひとつずつ気づいた。気づかなかったらどうなっていたかを考えると、いまでも背筋が冷える。
1週間で訂正した7つの数字
時系列で並べてみる。
| # | AIが書いた数字 | 実際の数字 | 影響範囲 | 気づいた経路 |
|---|---|---|---|---|
| 1 | hooks 720 件 | 719 件 | README、PR、SNS告知 | PR レビューで実測 |
| 2 | PDF 80 ページ | 89 ページ | LP、商品詳細、SNS | 別作業中に PDF を開いて発見 |
| 3 | 「buyer 5人」 | 0 人 | 内部メモ、戦略判断 | Gumroad 管理画面で確認 |
| 4 | PDF 254KB | 269KB（最新） | LP、cross-sell 表 | rebuild ログで発覚 |
| 5 | URL先「The Register」最新版 | リンク切れ | 商品本文 | curl で 404 検出 |
| 6 | YAML 末尾 closing quote 有 | 不足（parse error） | KPI tracking | 自動 lint で即検知 |
| 7 | Wiki ページ「~40 pages, English」 | 80 pages | OSS リポ README |
wc -l で実測 |
7件のうち、5件は外部に出る直前だった。1件は KPI 集計が壊れる直接バグだった。
数字の単位はバラバラだ。件数、ページ数、人数、バイト数、文字列。けれど、共通点がある。全部、AIが「自信ありげに」書いた数字だった。
なぜAIは数字で嘘をつくのか
不思議に思って Claude Code に直接聞いてみた。
返ってきた答えを意訳すると、こうだ。
直前のコンテキストで似た数字が出ていれば、それを引きずる。出ていなければ、「もっともらしい数字」を埋める。実測する命令が明示的に入っていない限り、確認はしない。
つまり、AIは「実測」と「補完」を区別しない。書く瞬間まで、自分が書こうとしている数字が「実測」か「補完」かを意識しない。
人間でも同じことは起きる。けれど人間は、数字を書いた後に「あれ、これ合ってたっけ」と一度立ち止まる癖がついている人が多い（少なくとも、痛い目を見た人は）。AIにはその癖がない。聞かれない限り、立ち止まらない。
検証 3 手順——公開前に1分でできる
事故を7件踏んだ後で、対策を3つに絞った。重いことはやらない。1分で終わるもの3つだけ。
1. 「数字だけ実測」 を独立タスクにする
AIに記事や README を書かせた後、別タスクで「この記事に出てくる数字だけを実測してくれ」と頼む。
ポイントは「別タスク」にすること。同じ会話の延長で「合ってる？」と聞いても、AIは自分が書いた数字を擁護する側に回る。新しい会話を開いて、コンテキストなしで実測させると、嘘がきれいに浮き上がる。
# 例: hook 数を実測
ls hooks/*.sh | wc -l
# → 719（README は 720 と書いてあった）
2. PR レビューを「数字専用パス」として運用する
私は直接 main に push しない。AI が書いた変更は必ず PR にする。
PR の説明欄に「変更で出てくる主要な数字3つ」を書かせる。レビューでその3つを git grep し、リポジトリの実物と照合する。
3つだけ。全部チェックしようとすると続かない。最も影響の大きい3つに絞る。
これだけで、上の表の#1〜#5は merge 前に検出できた。
3. 「自信ありげな数字」 ほど疑う
AIは、自信のない数字には「約」「およそ」「推定」を付けてくれる。逆に、「断定的な数字」 ほど補完で書いている可能性が高い。
「hooks 720 件」のような、桁数まで書ききった数字は要警戒。
公開前に、本文中の「具体的な数字」を蛍光ペンで塗るつもりで読み返す。塗った数字を全部、独立タスクで実測する。塗られなかった数字は、文章の流れで生まれた「装飾の数字」だから優先度は下げる。
1分の検証で防げるものは多い
7件の事故のうち、6件は1分の実測で防げる種類だった。残る1件（YAML closing quote）も、コミット前に python -c "import yaml; yaml.safe_load(open('...'))" を1回叩けば終わる。
1分。
「AIに書かせる」を選ぶ以上、「AIが書いた数字を1分で実測する」 はセットでやる。これを忘れた瞬間、信用を毀損する記事や README が世に出る。出てしまえば、訂正のコストは1分の100倍では済まない。
私は今のところ全部 merge 前に止めた。けれど7回は7回だ。人間の数倍のスピードで作業させる以上、検証も人間の数倍の頻度でやる。これが、AIと組んで仕事する人間の側の責任だと思う。
数字だけは、信じない。AIにも、自分の昨日の自分にも。
余談: hooks の数を 1 件ずれたまま公開していたら
もしレビューで気づかず「720 件」のまま公開していたら、こうなっていたはずだ。
- README、リリースノート、SNS、Discussion 告知、4 ファイルで「720」を主張
- 数日後に「数えたら 719 件しかなかった」と読者から指摘される
- 訂正コミット 1 件、訂正ツイート 1 件、信用毀損は数値化できない
事前の1分でこれを全部回避できた。安いものだ。
ここまで読んでいただいたあなたへ。今日、自分の README やドキュメントの「具体的な数字」を3つだけ、実物と照らし合わせてみてほしい。1個でもズレていたら、それは1週間後に誰かが指摘してくる予約済み案件だ。
私は明日、また AI にコードと文章を書かせる。けれど、書かせた数字は信じない。