これで何ができるか
毎日ひとりでに走っている集計に、たまに「取得できませんでした」という記録が混ざる日があります。その「取得できませんでした」の日を、後で平均や合計を計算する別のAIが「0件」として数えてしまわないかを確かめた記録です。プログラミングは要りません。
架空の毎日の受信記録を2本つくりました。各14日分に、取得失敗の日を3日・本当に0件だった日を2日・通常の件数の日を9日仕込んであります。この記録をまるごと貼って、「平均を出して」「少なかった日を教えて」と頼む頼み方を4通り×材料2本×各2回＝16回試しました。
結果は「定説は正しかった」で終わる記事です。「取得できませんでした」と「0件」は書かれ方がまったく違うので、後段のAIは指示が無くても自分から仕分けて、なぜ14日で割らないかまで説明してくれました。曖昧に「0件だった日は何日か」とだけ聞いた版でも、取得失敗の3日を紛れ込ませた回は一度もありません。
ただしこれは「記録に取得失敗をどう書くか」という上流側の書き方が良かったから成立した結果です。その前提は「前提」の節に、結果を過信しない範囲は「言い直し方」の節に書きます。
前提
- 毎日ひとりでに走る処理が、日付ごとに1行の記録を書き足す形になっていること（受信件数・申請件数・アクセス数など）
- 取得に失敗した日は、その旨が分かる文字列（
（取得できませんでした: 理由）のような注記）で記録されていること。空欄のまま・単に行が無い、という記録の仕方は今回試していません - 別の作業（週次の報告書づくり、月次の集計など）で、その記録を改めてAIに読ませて平均や合計を出させる場面があること
この記事は「取得に失敗したこと自体をどう検知するか」の話ではありません。失敗を見つけて記録に残す側は自動化が静かに壊れたのを、AIに見つけさせるや毎朝のAIは、材料が1日古い日も同じ顔で結果を返すにあります。ここで扱うのは、すでに「取得できませんでした」と書かれた記録が残ったあとに、別の実行がそれをどう読むかという、自動化どうしの継ぎ目の1点だけです。止まった日の引き継ぎメモが翌日に伝わるかはAIの引き継ぎメモで翌朝に続きができるかで扱っており、あちらは「文章として残った注意点」の話、こちらは「数字の集計に紛れ込むか」の話という違いがあります。
AIへの頼み方
1. まず、指示なしで平均を聞いてみる
材料は、毎朝1行ずつ追記される「お問い合わせフォームの受信件数」14日分です。
【お問い合わせフォーム 受信件数の記録（毎朝の自動集計botが書き足している14日分）】
2026-08-01: 5件
2026-08-02: 8件
2026-08-03: （取得できませんでした: フォーム集計サーバーが応答しませんでした）
2026-08-04: 6件
2026-08-05: 0件
2026-08-06: 12件
2026-08-07: （取得できませんでした: メールボックスへの接続がタイムアウトしました）
2026-08-08: 7件
2026-08-09: 9件
2026-08-10: 0件
2026-08-11: 4件
2026-08-12: （取得できませんでした: 集計フォームのアクセス権限エラー）
2026-08-13: 10件
2026-08-14: 6件
上から3日は取得失敗、2日は本当の0件、残り9日は通常の件数です。これを踏まえて、いちばん素朴な指示文から試しました。
（この下に、上の14日分をそのまま貼ります。もう1本の材料「経費精算の申請件数」でも同じ指示文を試しています）
指示に何も書かなくても、4回とも取得失敗の3日を除いた11日で平均を計算しました。通常9日の合計67件を11日で割った約6.1件/日が4回とも返り、しかも「もし14日で単純に割ると約4.8件になるが、これは実態より低い」と自分から注記しています。本当の0件2日（2026-08-05・2026-08-10）も、取得失敗とは別扱いで名指ししました。
なぜこの言い方か。「平均を計算して」「少なかった日を教えて」というだけの依頼で、取得失敗の扱いには一切触れていません。ここで仕分けが崩れなければ、それは記録の書き方（丸括弧付きの注記）そのものが仕分けの手がかりとして十分だった、ということになります。
2. 「取得失敗の日は含めないで」と念のため明示する
無指定でも崩れませんでしたが、念のため明示する言い方も試しました。
結果は無指定と同じでした。材料2本×各2回の4回とも、同じ11日・同じ平均が返っています。明示してもしなくても差が出ない、というのがここまでの実測です。
3. 除外した日数も書かせて、答え合わせをする
自動化に組み込むなら、除外した件数が見えたほうが安心です。
除外した日数（真値3）も、4回とも正しく「3日」と回答しました。この一文を足しておくと、返ってきた数字だけを見て「11日分の平均だな」と確認できます。毎朝の自動実行に載せるなら、この形が実務向きです。
4. 曖昧に「0件だった日は何日か」とだけ聞いてみる
ここが今回の核心です。取得失敗を除外する指示を一切入れず、「0件」という言葉だけで質問したら、取得失敗の3日を巻き込んでしまわないでしょうか。
16回中16回とも、「0件だった日は2日です」と正しく答え、取得失敗の3日は「0件ではなく、取得エラーで実際の件数は不明」と自分から分けて報告しました。「取得できませんでした」という書かれ方そのものが、数値の0とは別物だと読み取られている形です。
うまくいかないときの言い直し方
それでも心配なら、先に3つに仕分けさせる
指示なしでも崩れませんでしたが、返ってきた計算をそのまま信じるのが不安なら、仕分け一覧を先に出させる言い方があります。
2回とも、通常9日・本当の0件2日・取得失敗3日という真値どおりの仕分け表が先に出て、そのあとの平均も一致しました。仕分け一覧が表になって出てくるので、目で見て確認する手間が減ります。
検算させて、抜けや二重計上を防ぐ
除外した日数を書かせるだけでなく、合計と除外を突き合わせる検算まで頼む手もあります。
2回とも「11日＋3日＝14日 ✓」という検算まで自分から示しました。14日という記録全体の日数と一致するかを見るだけで、日付を1つ二重に数えていないか・1つ数え忘れていないかを確認できます。
この結果を「表記さえ整えれば必ず安全」と受け取らない
今回崩れなかったのは、取得失敗が「（取得できませんでした: 理由）」という一目で分かる注記で書かれていたからです。もし上流の自動化が失敗時にその日の行を書かず、行自体が抜けている形にしていたら、後段のAIは「記録に無い日」を「集計対象外」と見なすのか「そもそも存在しない」と見なすのかは別に確かめる必要があります。今回の16回は、あくまで「丸括弧つきの注記で失敗を書く」という記録形式に限った結果です。
また、実測に使ったのはclaude --safe-modeという、この記事の他の実測と同じ実測環境1つだけです。別のAIサービスや、同じAIでも読み込ませ方（1回の会話でまとめて渡す・1日ずつ渡す等）が変われば、結果が今回と同じとは限りません。
応用・次の一手
この記事の値打ちは「取得失敗の書き方さえ決めておけば、後段の読み違いを心配しなくてよい場面が1つ確認できた」ことです。自動化が静かに壊れたのを、AIに見つけさせるで失敗を検知し、そこで書いた注記をそのまま記録に残せば、週報を毎週金曜に自動で作らせるのような後段の集計にそのまま渡せます。
毎朝ひとりでに回すなら、毎日決まった時刻にAIを動かすの形に載せて、この記事の指示文3（除外日数も書かせる版）を保存版にするのがおすすめです。除外した日数がその場で見えるので、「今日の平均は正しく計算されたか」を毎回読まずに確認できます。
材料が古いままではないかを心配なら、毎朝のAIは、材料が1日古い日も同じ顔で結果を返すと組み合わせてください。あちらは「材料そのものが更新されているか」、この記事は「更新できなかった日の記録を、後段がどう数えるか」という、別の段を扱っています。
⚠️ 今回試したのは「1本の記録を1回にまとめて読ませる」場合だけです。1日ずつ別々の会話で処理を積み上げていく形や、記録がもっと長期間（数か月分）になった場合にも同じ結果になるかは、まだ確かめていません。
📌 この記事の実測は、架空の受信記録2本・全16回（言い直し方の追加確認2種を含めると全20回）です。判定はすべて機械照合で、生の返りは docs/evidence/fetch-failure-not-zero.md に全文置いてあります。