「該当0件でした」と報告したあとで、ふと不安になる。あれは本当に、見に行ったうえでの0件だったんだろうか。
その不安は当たっています。「0件」には意味が3つあって、そのうち「異常なし」と書けるのは1つだけ。見分け方は決まっていて、覚えることも多くありません。
⚠️ この記事の情報は2026年8月時点のものです。記事に出てくる株のシステムは相場を観測・研究するためのもので、自動発注はしません（read-only）。実際のお金での発注はしていません（仮想発注のみ・実発注なし）。
Excelのフィルタをかけたら0件。COUNTIFが0。AIに頼んだら「確認しました、問題ありません」。手応えのないまま「異常なし」で閉じてしまう——ここが一番危ない瞬間です。
- 「該当0件」の3つの正体と、「異常なし」と書けるのはどれか
- 結果を「合格／不合格／不明」の3つで持つと空振りが見えるようになる理由
- AIに確認を頼む依頼文と、その依頼が効いているか自分で確かめる方法
結論を先に。0件を受け取ったら、まず「何件を照合したうえでの0件か」を聞き返す。照合件数が0なら、それは「異常なし」ではなく「未確認」です。この一手だけで、空振りのほとんどはその場で見つかります。
【早見表】「0件」を受け取ったら、この順で見る
上から順に。途中で引っかかったら、そこで止まって構いません。
| 見るもの | そこで0件だった意味 | 次にやること |
|---|---|---|
| 対象データの行数（母数） | 0行なら比べる相手がいない＝未確認 | データを入れてから再実行 |
| 条件に使った列名と範囲 | ずれていれば照合できていない＝未確認 | 列名を完全一致で確認し、範囲を指定し直す |
| 条件式のほうに、確実に当たる値を1つだけ入れて試した結果（データは書き換えない） | それでも0件なら条件そのものが壊れている | 条件式を作り直す |
| 上の3つが問題なく、それでも0件 | これだけが「本当に該当なし」 | 「◯件を照合して該当0件」と母数つきで書く |
「該当0件」には3種類ある
同じ「0」でも中身はまったく違います。混ぜて扱うから事故になる。
本当に該当がない
対象データがちゃんとあり、条件も範囲も正しく、そのうえで0件。これが本来の「異常なし」です。ただし胸を張って書けるのは、母数（何件を調べたか）を一緒に示せるときだけ。「◯件を調べて該当0件」と「0件」は別の報告です。
条件がずれていて拾えていない
照合は動いた。でも的が外れていた、というパターンです。
- 列名が「日付」と「基準日」で食い違っている
- 参照範囲が途中で切れていて、増えた行が範囲外になっている
- 数値のつもりが文字列で入っている（見た目は同じ）
- 前後に空白や全角スペースが混ざって一致しない
どれも画面上は静かです。エラーは出ません。0件という「それらしい答え」が返ってくるので、疑うきっかけが与えられない。
そもそも対象データが1行も入っていない
いちばん見落とされるのがこれ。仕組みは完璧に動いていて、比べる相手だけが存在しない状態です。処理は最後まで走る。エラーも出ない。結果は0件。全部、正常に見えます。
でも実際には、一度も照合していない。
実録：仕組みは動いていた。ただし照合した行数が0だった
筆者は株の値動きを観測・研究するためのシステムを作っています（観測・研究用で、自動発注はしません＝read-only。実際のお金での発注もしていません＝仮想発注のみ・実発注なし）。
そこには「証跡の日付が古すぎないか（決めた日数以内か）」を確かめる仕組みがありました。ただし筆者が知りたかったのは別のことです——まだ起きていないこと、つまり未来の日付の記録が混ざっていないか。使えそうな仕組みが既にあるなら、それで確かめられるはずだと思って読みに行きました。
仕組み自体は想定どおりに動いていました。形式が曖昧な日付は受け付けず、読めないときは通さずに止まる。ここは問題なし。
ただし読んでいるうちに、片側しか見ていないことに気づきます。古すぎる証跡は弾くのに、未来の日付は経過日数がマイナスになるので、上限だけを見る判定では素通りしてしまう。つまりこの仕組みは「古すぎる」は防げても、「未来の日付」は防げません。筆者が知りたかった問いには、そもそも答えられない作りでした。
問題はもう一つありました。その仕組みが読みに行く先に、条件を満たす記録が1行も無かった。記録にはこう残っています。
照合した行数: 0 ／ 未来日付の混入: 不明
なお、さきほどの「片側しか見ていない」穴のほうは、欠陥としては起票していません。理由は単純で、未来の日付のデータが実際に使われた場面を1件も見ていないから（そもそも対象が0件）。実際に起きたと確かめていないものを不具合として登録すると、こんどは「直したことになっている未確認」が増えます。なので観察として書き残すだけに留めました。
そして「0件だったので問題なし」とは書かず、「照合した行数：0」「未来日付の混入：不明」のまま閉じました。この書き方は、このあと出てくる12項目の見直しでもそのまま使っています。
「きれいだと分かったからではなく、比べるものが無いから不明」と書く
理由づけとして、記録にはこの一文を添えました。きれいだと分かったからではなく、比べるものが無いから不明である。
たった一文の差です。でも読み手に渡るものが正反対になる。「確認は終わった」と読ませるか、「まだ確認できていない」と読ませるか。
判断のよりどころにしたのは、あらかじめ決めてあった「作り物の検証データだけで確認を済ませて合格にしてはいけない」という取り決めです。当たり前に聞こえますが、先に決めて書いておかないと、締切が近いときにこの一線は簡単に溶けます。結果、この項目は合格にせず保留のまま終えました。
もう一つの空振り：「ファイルがあるか」しか見ていない確認
同じ根の問題を、もっと大きな規模で踏みました。
存在しても不在でも、常に「不明」を返していた12項目
確認項目が12個ありました。どれも「成果物のファイルがあるかどうか」しか見ていない。中身は開かない。だから、ファイルが無くても「不明」、あっても「不明」。何をしても答えが変わらない確認が12個並んでいました。
動いてはいるんです。エラーも出ない。ただ、一度も判定していなかった。
Excelで言えば、ブックを開いたことだけ確認して「チェック済み」と書いているようなもの。開いた事実は本当ですが、中身を見たかどうかは報告から分かりません。
直し方：結果は「合格／不合格／不明」の3つで持つ
直し方はシンプルで、判定の入れ物を2択から3択に変えるだけです。「OK／NG」の2択にすると、判定できなかったものが必ずどちらかへ寄ります。たいてい甘い方へ。3つ目の「不明」を用意すると、そこに溜まって目で見えるようになる。
判定規則を例外なしの表にする
修正では、判定の規則を例外なしの表にしました。「ここは人が見て決める」という余地を残さない。
| 対象の状態 | 判定 |
|---|---|
| 見つからない（不在） | 不明 |
| 読めない・壊れている | 不明 |
| 古い（決めた鮮度の条件から外れている） | 不明 |
| 合否が読み取れない | 不明 |
| 明示的に「未達」「不完全」と書かれている | 不合格 |
| 有効で、鮮度が条件内で、合格条件を満たす | 合格 |
ポイントは、迷う余地のあるものを全部「不明」へ倒していること。判断がつかないときは通さずに止める（fail-closed）という考え方です。
基準が決まっていない項目は「不明」のまま残すのが正解
12項目のうち3つは、そもそも「何をもって合格とするか」が正式な資料のどこにも書かれていませんでした。
ここで「たぶんこのくらいだろう」と基準を発明したら、そのチェックは以後ずっと嘘をつきます。しかも作った本人ですら、半年後には根拠を思い出せない。
なので勝手な基準を足さず、「合格の基準が正本に無い」という専用の理由コードを付けて不明のまま残しました。空欄でも合格でもなく、決まっていないと書いてある状態です。
「ファイルがあれば合格」に緩めない
3択に直すとき、いちばん誘惑が強いのがここです。「不明ばかりで見栄えが悪いから、ファイルがあれば合格にしてしまおう」。
これは直したことになりません。空振りしていた確認を、空振りしたまま合格印を押す装置に変えるだけ。前は「不明」と正直に言っていたぶん、悪化です。
だから「ファイルがあれば合格」へは変えていないことを、実装とテストの両方で固定しました。片方だけだと、あとで誰かが静かに緩めます。未来の自分を含めて。
報告の作法：必ず母数（チェックした件数）を併記する
ここからは、Excelでも人への報告でもそのまま使える話です。
0件のときは「合格」ではなく「未確認」と書く
「異常なし」と「未確認」は、読んだ人が次にやることが違います。前者は閉じる。後者は続ける。この差を報告の一行で作れるかどうかが、空振りに気づけるかどうかの分かれ目です。
書き方を先に決めておくと迷いません。「◯件を照合して該当0件」なら異常なし。「照合した件数：0」なら未確認。数字を1つ足すだけで、読んだ人が自分で判断できるようになります。
確認結果を1枚にまとめる形はAIに毎朝の運用チェックを任せた記録に書きました。ああいうレポートも、母数が抜けると安心材料に変わります。
合格数を増やすこと自体を目的にしない
12項目を直したあと、確認項目全27個の合格・不合格・不明の件数は1件も変わりませんでした（合格5／不合格8／不明14）。件数表だけ見れば、何も進んでいない。
ただし実際のデータに当てて確かめると、12項目のうち3つは「不明」ではなく明示的な「不合格」を返すようになっていました。件数表は動かないのに、判定はできるようになった。変わったのは数ではなく、判定できる状態かどうかです。だから記録にも「合格数を増やすこと自体を目的にしていない」と明記して閉じています。
進捗を「合格の数」で測ると、判定を緩めるのが一番手っ取り早い改善になってしまいます。測る対象を間違えると、まじめにやるほど質が下がる。
AIに確認を頼むときの依頼文（そのまま使える型）
AIに確認を頼むと、たいてい「確認しました。問題ありません」と返ってきます。この返事だけでは、見て問題なかったのか、見に行けなかったのかが区別できません。だから依頼文の側で区別を強制します。
「あるか」ではなく「合格・不合格・不明のどれか、根拠つきで」
【確認のお願い】
対象：（何を確認してほしいか）
判定は必ず「合格／不合格／不明」の3つのどれかで返してください。
■ 判定の規則（例外なし）
- 見つからない／読めない／古い／合否が読み取れない → 不明
- 明示的に基準を満たしていないと書いてある → 不合格
- 有効で、鮮度が条件内で、合格条件を満たす → 合格
- 合格の基準が資料に書かれていない項目は、基準を推測せず
「基準が資料に無い」と理由を書いて不明にしてください
■ 必ず一緒に返してほしいもの
- 実際に照合した件数（0件なら「0」と書く）
- 各判定の根拠（どの資料のどこを見たか）
- 照合件数が0のときは「合格」ではなく「未確認」と書く
■ やらないでほしいこと
- 見つからないものを「問題なし」として扱う
- 判定できないものを合格の側へ寄せる
- 作り物のデータだけで合格にする効くのは最後の3行です。ここが無いと、AIは親切に「たぶん大丈夫です」と埋めてくれます。悪気なく。
指示文そのものの組み立て方はClaude Codeへの指示文の書き方にまとめています。上の型は、そこから「確認を頼む」場面だけを切り出したものです。
わざと1件だけ壊して、ちゃんと不合格になるか確かめる
依頼文が効いているかは、正常なデータでは分かりません。全部「合格」で返ってきても、本当に判定した結果なのか、なんとなく合格にしただけなのか区別がつかない。そこで、データを1件だけわざと壊して試します。
⚠️ この作業は必ず「名前を付けて保存」で複製した別ファイルで行ってください（原本のファイルは開かない）。同じブックの中でシートを複製して列を消すと、Ctrl+Sや自動保存で原本ごと壊れます。試し終わったら、そのコピーはファイルごと捨てます。
- 日付の欄を空にする（コピーしたファイルで）
- 必須の列を丸ごと消す（コピーしたファイルで）
- 明らかに古い日付に書き換える（コピーしたファイルで）
これを渡して「不合格」か「不明」が返ってくれば、その確認は生きています。全部「合格」で返ってきたら、もともと何も見ていません。
筆者はこれを8系統（不在・空・破損・古い・明示的な不合格・必須欄の欠落・存在だけある・そもそも対象が空）へ広げ、12項目それぞれに当てました（8×12＝96件）。これに「正常なデータならちゃんと合格になるか」の12件と、個別のシナリオ・用語のズレを見つけるテスト20件を足して、テストは合計128件です。「緩めたのではなく、判定できるようにした」ことを、あとから誰でも確かめられるように。個人の作業ならそこまで要りません。1件壊して、1回試す。それで十分です。
Excelでの自己点検：フィルタとCOUNTIFの空振りを見つける
同じ考え方はExcelでそのまま使えます。手順は5つ。
- 母数を先に数える。COUNTA関数（空白でないセルを数える）で、対象の列に何件入っているかを出す。ここが0なら以降の判定は無意味です。
- フィルタ後の件数を出す。SUBTOTAL関数の103番（隠れた行を除いて数える指定）で、絞り込んだあとの件数が出ます。見出し行を範囲に入れずに
=SUBTOTAL(103,A2:A1000)と書いてください（見出しを含めると母数が1件ずれます）。「該当0件」の隣に「母数◯件」が並ぶ形に。 - わざと1件マッチさせる。書き換えるのは条件式のほうだけです。COUNTIFの条件に、確実に当たる値を1つだけ入れて結果が1になるか見る（データ側には試験用の行を足しません）。ならなければ条件か範囲が壊れています。どうしても試験用の行を足して試すなら、その行に色をつけ、確認後に必ず削除してください。
- 範囲をテーブルにする。固定のセル番地だと、増えた行がまるごと範囲外になります。テーブル（Ctrl+T）にして名前で参照すればズレにくい。
- 型と空白を疑う。数値と文字列、全角と半角、前後の空白はすべて別物です。そろえる順番が大事で、まずASC関数（全角→半角）、そのあとTRIM関数（前後の空白を落とす）の順にします。逆にすると、全角スペースが半角に変わる前にTRIMを抜けてしまい、そろえたつもりで一致しません。作業列を1つ用意して
=TRIM(ASC(A2))と書き、その作業列どうしで比べてください。
特に1番。「0件でした」と言う前に「母数は何件？」と自分に聞く癖だけで、空振りの大半は消えます。
なお、AIに作らせた数式そのものを点検する話はAIが生成した数式のチェック方法で別に整理しています。この記事は「その数式が何件に当たったか」を見る側の話でした。
非エンジニアが得た教訓
- 0件は結果ではなく質問。「何件を調べたうえでの0件か」に答えられないうちは、まだ結果になっていない
- 判定の入れ物は3つ用意する。2択だと、判定できなかったものはたいてい甘い方へ流れる
- 決まっていない基準を発明しない。「基準がまだ無い」と書き残すほうが安全
- 合格の数を進捗の指標にしない。判定を緩めるのが最速の改善になってしまう
- 直したら、わざと壊して試す。正常なデータだけで確かめた確認は、確かめたことにならない
まとめ
「該当0件」を「異常なし」と書き換えた瞬間、そのチェックが空振りしていた可能性は報告から消えます。消えるだけで、無くなってはいない。
- 0件には「本当に該当なし」「条件がずれて拾えていない」「対象が1行も無い」の3種類がある
- 結果は「合格／不合格／不明」の3つで持ち、迷うものは全部「不明」へ倒す
- 報告には必ず母数を書く。照合件数が0なら「合格」ではなく「未確認」
- 基準が決まっていない項目は、基準を発明せず「決まっていない」と残す
- AIには判定の3択と照合件数を必ず返させ、1件わざと壊して効いているか確かめる
チェックが増えるほど安心が増える、とはかぎりません。増えているのが「判定していないチェック」なら、増えたのは安心だけ。今日足すのは、チェックの数ではなく母数の一行で十分です。
関連記事
- 直したのに結果が変わらない｜前の答えが使い回されているときの見分け方｜「直したはずなのに変わらない」も、チェックが空振りしているサインの一つです
- Claude Codeへの指示文の書き方｜上の依頼文の土台になる、指示文の基本の型
- AIが生成した数式のチェック方法｜AIが書いた計算式そのものを点検する側の話
- AIに毎朝の運用チェックを任せた記録｜確認結果を1枚にまとめ、承認だけを人がやる形にした話
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年8月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント