AIエージェントを常時動かしていると、こういう報告が毎日かえってきます。
「対処しました」
「公開しました」
「修正済みです」
これがどれくらい本当なのか、私は数えていませんでした。
この記事は、数え始めた話です。結論を先に書くと、一番壊れていたのはエージェントではなく、私の検証のほうでした。
なぜ数えることにしたか ― 分子はあるのに分母が無い
前のプロジェクトで、私は訂正の台帳をつけていました。誤った申告が、型つきで15件以上あります。
存在しない値をでっち上げた
経路の存在を確かめずに「無い」と断定した
検証の対象を取り違えた
代理変数を本体として語った
...
一見すると、立派な記録に見えます。しかし、これは使えません。
分子 間違えた回数 **記録してある**
分母 「できました」と言った回数 **誰も数えていない**
**割り算ができません。**15件が多いのか少ないのかを判断する材料が、どこにも無いのです。100回言って15回間違えたのなら85%、20回言って15回間違えたのなら25%。同じ「15件」がまったく違う意味になります。
だから、申告そのものを数えることにしました。
仕組み ― ルールは2つだけ
台帳に1件記録するのに、2つのことを書かせます。
① 申告した時点で「どうすれば嘘だと分かるか」を書く
python code/claims.py add --by 統括 --kind done \
--claim "記事005 を Qiita に公開した" \
--check "Qiita APIの items に slug 5c7506c94b5be58c040e が含まれる"
**--check が空なら、受け付けません。**エラーで落とします。
却下: --check（どうすれば嘘だと分かるか）が空。
**反証条件を書けない申告は、申告として数えない。**
これが効くのは、書けない申告があぶり出されるからです。「改善しました」「きれいになりました」は、反証条件が書けません。書けないものは、そもそも真偽が決まらない文だったということです。
② 検証した時点で「実際に何を観測したか」を書く
python code/claims.py verify C-0001 --true \
--evidence "APIの items に当該slugがあることを確認した"
**この2番目は、後から足しました。**足した理由が、この記事の本題です。
結果 ― 12件、的中率82%
申告 12件
真 9件
偽 2件
未検証 1件
**的中率 82%** 確かめたもののうち、本当だった割合
**検証率 92%** そもそも誰かが確かめた割合
偽だった2件は、こういうものでした。
C-0003 「スクリーニング記事を公開した」
→ **レート制限で公開されていなかった**
C-0011 「記事001に訂正の追記を入れた」
→ **追記が反映されていなかった**
どちらも「やったつもりで、やれていなかった」型です。エージェントが嘘をついたというより、実行結果を確認せずに完了と報告したという形です。
ここからが本題 ― 検証のほうが2回壊れた
的中率82%という数字より、測っている最中に起きたことのほうが重要でした。
1回目（C-0007）
「記事を公開した」という申告を、公開する前に真として記録しました。
その後、実際に公開されたので、**結果的に真になりました。**しかし、真になったのは偶然です。記録した瞬間には、それは偽でした。
2回目（C-0011）
同じ型を、翌日にもう一度踏みました。今度はもっと悪い形です。
検証コマンドを実行しました。その出力に、こう表示されていました。
001に追記が入ったか: False
画面に False と出ているのを見ながら、私は --true を実行しました。
後で気づいて訂正しました。台帳にはこう残っています。
- id: C-0011
claim: 公開記事001に、トークン量とコストを混同していた旨の追記を入れた
check: Qiita 001 の本文に「追記（2026-09-04）」が含まれる
verdict: 'false'
note: '**誤検証を訂正。**APIで確認したところ 001 の updated_at は
2026-09-02T17:26 のままで、追記は反映されていない。
前回 true としたのは、同じコマンド内の判定結果を見ずに verify を実行したため（C-0007 と同じ型の再発）'
**「できました」の的中率を測る仕組みを作った本人が、その測定を2回間違えた。**これがこの取り組みで一番の発見でした。
対処 ― 心構えではなく、機械に見せる
2回目の後で、--evidence を必須にしました。検証するとき、申告文と反証条件を必ず画面に出し、「実際に何を観測したか」を書かないと通らないようにしたのです。
def cmd_verify(a):
print(" 申告 : %s" % r["claim"])
print(" 反証条件 : %s" % r.get("check"))
ev = (a.evidence or "").strip()
if len(ev) < 5:
raise SystemExit(
"却下: --evidence（実際に何を観測したか）が空か短すぎる。\n"
" **反証条件を確かめずに verify を実行した事故が2回起きている。**")
**注意深くやろう、では2回とも防げませんでした。**1回目のあと、私は訂正台帳に「恒久検査を入れる」と書きました。**書いただけで、実装しませんでした。**そして翌日、同じ型を踏みました。
**案のまま置いた検査は、無いのと同じです。**
そして、この対処が過去を無効化した
--evidence を必須にしたあと、台帳を集計すると、こう出ます。
**観測の記録が無い検証が 10 件ある。**
2026-09-04 より前の検証には --evidence が無い。**遡って信用しない。**
つまり、こうなります。
見かけの検証率 92% （11 / 12件）
観測の記録がある検証 1件 **実質的にはこれだけ**
82%という数字は、その大半が「確かめたと本人が言っているだけ」の上に乗っています。
これは検査を厳しくしたから出た数字ではありません。厳しくして初めて、それまで何も確かめていなかったことが見えたのです。
記事を書いている今、偽が1件立っている
C-0011（記事001の追記）は、この記事を書いている時点でもまだ偽のままです。
$ curl -s "https://qiita.com/api/v2/users/manabu49-ai/items" | ...
2598a30d5140e4445ab6 created=2026-09-01T18:17 **updated=2026-09-02T17:26**
追記を入れたのは 2026-09-04 です。updated_at が 9/2 のままなので、届いていません。
原因は分かっています。同じワークフロー実行の中で、新規記事の投稿と既存記事の更新を両方やろうとして、片方が通らなかった。翌朝に再実行するタスクを登録してあります。
この記事の中で「対処済み」と書かないのは、まだ確かめていないからです。
使ったコード
依存は PyYAML だけです。**外部サービスに何も送りません。**手元の YAML に追記するだけです。
def cmd_add(a):
"""申告を1件記録する。**反証条件が無ければ受け付けない。**"""
check = (a.check or "").strip()
if not check:
raise SystemExit(
"却下: --check（どうすれば嘘だと分かるか）が空。\n"
" **反証条件を書けない申告は、申告として数えない。**")
rows = _load()
n = max([int(r["id"].split("-")[1]) for r in rows] or [0]) + 1
rows.append({"id": "C-%04d" % n, "at": _now(), "by": a.by, "kind": a.kind,
"claim": a.claim.strip(), "check": check, "verdict": "unverified"})
_save(rows)
def _rate(rows):
t = sum(1 for r in rows if r.get("verdict") == "true")
f = sum(1 for r in rows if r.get("verdict") == "false")
u = sum(1 for r in rows if r.get("verdict") not in ("true", "false"))
n = t + f + u
return n, t, f, u, (t / (t + f)) if (t + f) else None, ((t + f) / n) if n else None
集計を出すと、限界を最後に必ず印字するようにしています。
限界: 台帳に載るのは捕まった誤りだけ。**的中率は上界である。**
この数字の限界
**82%は上界です。**理由は単純で、気づかなかった嘘は台帳に載らないからです。
台帳に載る 誰かが確かめて、偽だと分かったもの
載らない **誰も確かめなかったもの / 確かめたつもりで見落としたもの**
さらに、標本が12件しかありません。**1件の増減で8ポイント動きます。**この数字を他人の環境に持ち出す意味はありません。
持ち出せるのは数字ではなく、2つの規則のほうです。
まとめ
1 訂正の記録だけでは足りない。**分母（何回できましたと言ったか）が要る**
2 申告の時点で「**どうすれば嘘だと分かるか**」を書けないものは、申告として数えない
3 検証の時点で「**実際に何を観測したか**」を書かせる。
**これが無いと、画面のFalseを見ながら true と記録できてしまう**
4 **案のまま置いた検査は、無いのと同じ。**書いた翌日に同じ型を踏んだ
5 的中率は必ず**上界**。捕まった誤りしか分子に入らない
**3番目が、この件で一番高くついた学びです。**測る仕組みを作ったこと自体は、事故を防ぎませんでした。測定者を疑う検査を入れて、初めて防げるようになりました。
この連載は、実際に測った数字だけで書いています。
同じことを試す人の役に立ちそうなら、ストックしておいてください。
この連載
AIエージェントを実際に回して、かかった費用と壊れた箇所を測って書いています。推測は書きません。実測値だけです。
- Claude Code のトークン使用量を実測したら1ターン23万 ― 節約に効いたのは「セッションを切る」だった
https://qiita.com/manabu49-ai/items/2598a30d5140e4445ab6 - 57分間、死んだジョブを誰も見ていなかった ― AIエージェントの見張りを機械に渡す
https://qiita.com/manabu49-ai/items/5c7506c94b5be58c040e - AIに100通り試させたら、効果ゼロなのに5個が「有意」だった
https://qiita.com/manabu49-ai/items/397a018948e1ab7ef29e - 仕様書は2日前から手元にあった ― 読まずに実装した対処が、データを永久に失う設計だった
https://qiita.com/manabu49-ai/items/9b947604d3dc4958fa36 - AIを触り始めて3日で24時間動くものを作った ― そして8回間違えた
https://qiita.com/manabu49-ai/items/acd01b13abe9c8cbea16 - 同じデータを2つのAIに測らせたら、中央値が5通り出た ― 全部、計算は正しかった
https://qiita.com/manabu49-ai/items/dc699a8458b129d6be39 - トークン数はコストの代理変数にならない ― 自分のログ25,574ターンで測り直した
https://qiita.com/manabu49-ai/items/96fc4cb58cf11a55b37b - 本記事 ― 「できました」を12回ぜんぶ確かめた
番外 ― Qiitaで何が読まれるかを3,478本から探した ― 106通り掃いて、残ったのは6つだけだった
https://qiita.com/manabu49-ai/items/d78a5aeaecf8d7f3f20b
番外 ― Claude のモデル提供終了、猶予は告知から約60日 ― 過去9回を数えて、手元を検査するスクリプトを書いた
https://qiita.com/manabu49-ai/items/bc2a7be2a6ee4ceb6185
**無料記事は結論まで全部書きます。**出し惜しみはしません。