AI（Claude Code）に作業を任せていて、同じ日に「それはできません」を 4 回書かれ、4 回とも取り消しになりました。4 回とも、一次資料は既に手元にありました。別の日には、納品物のコード注記 908 行を数えたら、「無い」と主張する行が 40 行、そのうち探した範囲を書いている行が 0 行でした。

この 2 つから当方が変えたのは 1 つだけ。否定を書くときは、探した範囲を同じ文に残す。 そのための「書く前の 3 段階」（否定の種類で確かめる量を変える）と、否定文のテンプレート 1 行を書きます。

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

この記事で新しく示すこと: AI の「無い／できない」が 1 日に 4 回とも取り消しになり、否定の 40 行に探した範囲が 0 行だった数と、書く前の 3 段階。
当てはまる範囲: 当方 1 人の運用記録です。

数字の元データと再現の手順は、検証の記録（Lab）にまとめています。

何が起きたか

4 回の「できない」

回	取り消しの根拠になった一次資料	内／外
1	そのスクリプトの冒頭の説明文（機能が書いてあった）	内
2	手順書（手順が書いてあった）	内
3	PowerShell の現物（コマンドが存在した）	内
4	公式文書（口が書いてあった）	外

内 3・外 1。どれも 1〜2 コマンドか 1 ページで確かめられるものでした。「できない」と書く前に、その 1 コマンドを打っていなかった（AI が書いた否定の文そのものは記録に残していないので、ここには載せません）。

40 行の「無い」

納品物のコード注記 908 行を、「存在の否定を主張している行」で数えたら 40 行。そのうち「どこを、何で見て、無かったのか」を併記している行は 0 行。

これが示すのは「40 件の否定が間違っていた」ではありません。「40 件とも、探した範囲が残っていなかった」です。書式の欠陥であって誤り率ではない。ただし、その 40 行のうち複数が後続の判断の土台になっていました（「仕様に記載が無いので仮置き」「途中を補う手が無い」→ 機能を 1 つ切った）。範囲が残っていないと、次に読む人はどこまで確認済みか分からず、再探索が要るか、そのまま前提として流用されるかのどちらかになる。

別の日には、当方も同じ型を 1 日に 3 件踏みました。記号つきの語で grep して 0 件と言った（tp @s で引いて @p を取りこぼす）／現行のフォルダだけ見て「記録が無い」と言った（退避に残っていた）／スクリプトの説明文だけ読んで「こうなっているはず」と言った（実装は違った）。

書く前の 3 段階

否定の語（無い／できない／効かない／0 件）を書こうとした瞬間に当てる。3 つ全部を毎回やるのではなく、否定の種類で確かめる量を変える。

主張に対応する一次資料を引く。 自分の実装・運用の話なら内（スクリプトの説明・記録・現物）、製品の能力・仕様の話なら外（公式文書）。境界をまたぐ主張だけ両方。4 回の取り消しは内 3・外 1 で、どれも主張に対応する側を引いていなかった。
探した範囲を同じ文に書く（全種）。 「無い」ではなく「〈場所〉を〈手段〉で確認した範囲では見つからなかった」。範囲が書けないなら、まだ探していない。「コメント 0 件」のような件数の否定はここまでで足りる。
能力・効果を否定するときだけ、成功している現物を 1 つ開く。 「できない」「効かない」「取り込まれない」は、動いている実例との対照が要る。1 か所を見た不在から構造の結論を出さない。存在・件数の否定にこれは要らない。

否定文テンプレート（1 行）

〈場所〉を〈手段〉で確認した範囲では、〈対象〉は見つからなかった。

否定は 4 種あるので、発火語も 4 種で持つ。

種	発火語	要る段階	範囲つきの例
存在	無い・見つからない	①②	`src/` を `grep -rn "like"` で見た範囲では、その関数は無い
能力	できない・扱えない	①②③	このツールの `--help` と手順書 §3 を読んだ範囲では、その操作はできない（成功例: 別のスクリプトで同じ操作が通っている）
効果	効かない・取り込まれない	①②③	起動中に開いた 1 回では取り込まれなかった（閉じてから開く経路は未確認）
件数	0 件	① ②	09-17T11:20Z 以降・他者のコメントを API で数えた範囲では 0 件

「規律を場面（フォルダを触るとき、など）に紐付けると、別の場面で発火しない」——当方はこれで同じ日に 3 件踏みました。だから出力の語に紐付ける。

最近の 1 例

別の記事で、D1 の「1 文の UPSERT は原子的か」を書くとき、公式 2 頁（SQLite のトランザクション・D1 の API）を取得して、記事には「単一の prepare().first() の原子性を明示した文は、当方が読んだ範囲の公式には無かった」と範囲つきで書き、原子性を仕様として断言しませんでした。「公式に無い」と書いていたら、次に読む人は探さない。

⚠ この段落は最初、別の例（無料枠の日付）を「範囲つきで書いた」と書いていました。現物を確かめたら、その記事は上限の強制開始日は書かず、数字と「2026-09-18 時点」だけを載せていて、範囲つきの否定は原子性の方でした。否定の書き方を説く記事で、当方が事実と違う記述をしていた例として残します。

言わないこと

「AI は否定できない」「AI の否定の N% は誤り」とは言わない。4 回・40 行・3 件は当方 1 人の記録で、率ではなく件数。4 回（AI）と 3 件（当方）は別の日。
「否定は伝播が速い」「肯定は追認される」は測っていないので言わない。言えるのは、範囲の無い否定が判断の土台になった例が当方にあった、まで。
案件の内容には触れない（908 行・40 行という数だけ）。

この記事の本家（4 回の表・40 行の数え方・検証の記録）は Sumitsuke Lab → 否定の結論には探した範囲を残す——AI の「できない」4 回を取り消し、否定 40 行に範囲つきは 0 行。

AI の利用について

否定を書いたのも数えたのも AI（Claude Code）で、取り消しの判断・数え方の設計・公開の判断は人が行いました。案件由来の数字は件数だけです。

関連

この記事は、結論を書く前に探した範囲を確かめるチェック（当方は「門」と呼んでいます）の話でした。前は、ファイルを書き換える前後を見るチェックの話 → Windows で AI にファイルを書き換えさせたら触っていない行が変わった——5 つの型を 5 行のファイルで再現した。次は、規律を文書に書くだけでなく発火する場所に置く話 → 規律の置き場所——同じ規律を 5 つの置き場所に書いて効いたのは記憶の 1 行、公開直前のスクリプトに置いたチェックは初回で 2 本拾った。

次に読む: AI レビューを現物で照合する運用——3 回・17 件が全部正しくても、指摘されなかった穴が 2 件あった

この記事は Zenn にも同じ内容を掲載しています。