欠けた一日を、日付で名指して AI に問う── 欠落を識別子で名指すと、AI の探索は一件の記録に絞られ、推測ではなく原因まで戻れる

01一日分だけ欠けた配信は、日付を挙げて尋ねたら原因まで届いた

2026 年 9 月、運営者が動かしている毎日の自動配信で、前日の分が公開されていなかった。運営者は仕組み全体の不調を訴えなかった。欠けている日付を挙げ、その日付の分が作られていない理由を AI に尋ねた。

返ってきたのは、動かない理由ではなく、その日付に何が起きたかだった。処理は走っていた。走ったという記録が残っていたため、次の実行はその日を対象から外していた。原因は処理の失敗ではなく、記録の扱いにあった。

修正は、残っていた記録の一部を消すことを含んでいた。AI は先に、次の収集の時刻までに直さなければ同じ理由でその夜も 0 本になる、という見通しを示した。運営者は、記録を消すところと、欠けた日の分を公開するところまで進めてよいかを確かめられ、承認した。

ここから取り出せる型は一つである。欠けているものを識別子で名指して問うと、AI の探索は仕組み全体ではなく、その一件の履歴に向かう。

02日付は、AI が履歴をたどるための手がかりになる

「出ていない」「動かない」という言い方は、対象を絞らない。受け取った AI は、仕組みのどこが壊れているかを広く探すことになる。日付を挙げると、探す対象は一件になる。

ここでいう識別子とは、一件を他と区別できる値である。日付、版の番号、受付の番号、通し番号がそれにあたる。識別子があれば、AI はその値で記録を検索できる。記録が残っていれば、いつ、何が、どう扱われたかが順に並ぶ。

この違いは、返ってくる答えの種類を変える。症状だけを渡すと、AI は考えられる原因を並べて推測する。識別子を渡すと、AI はその一件の履歴を読み、事実で答える。運営者の例では、答えは推測ではなく、その日付に残っていた記録の状態だった。

03範囲を一件に絞ると、原因の候補は数えられるほどに減る

仕組み全体を疑うと、候補は多い。収集の失敗、書き出しの失敗、時刻の設定、外部の応答、権限。どれも起こりうるので、どれから当たるかを決められない。

一件に絞ると、候補は「その一件だけに起きたこと」に限られる。ほかの日が動いているなら、仕組みそのものは動いている。残るのは、その日の入力、その日の記録、その日の時刻である。

Anthropic が公開している Claude Code の使い方の指針も、同じ向きを勧めている。「不具合を直して」ではなく、症状と、起きていそうな場所と、直った状態を書くこと。そして、症状を抑えるのではなく原因に当たること。指針は、直ったことを確かめる手だても一緒に渡すよう求めている。

04名指しが効くのは、ほかが動いていて一件だけ欠けているときである

この型を使う条件を決めておく。使えるのは、同じ処理が繰り返し動いていて、そのうちの一件だけが欠けている場合である。渡すものは四つある。

使えない場合もある。一度も動いたことがない仕組みでは、名指す先の記録がない。全部が欠けているときは、識別子で絞っても候補は減らない。その場合に必要なのは、動く例と動かない例を並べて、期待の範囲を先に示すことである。

もう一つの境界は、記録が残っていないときである。記録がなければ、識別子は検索の鍵として働かない。名指して問える状態は、記録を残している運用の上にしか成り立たない。

05資材審査では、欠番と版の飛びが同じ形で扱える

製薬企業の資材審査やメディカルの仕事でも、同じ形の欠落が起きる。承認済みの資材の一覧に、一件だけ載っていない。審査の受付の番号が飛んでいる。差し替えたはずの版が、公開されている側では前の版のままになっている。

こうした場面で「一覧が合っていない」と言うと、相手は一覧の作り方を疑う。「この受付番号の一件が載っていない」と言うと、相手はその一件の履歴を見る。どちらが速いかは、探す範囲の広さで決まる。

記録の側の要求も、同じ方向を向いている。米国食品医薬品局が 2018 年に出した製造管理と品質管理の基準とデータの信頼性についての手引きは、すべてのデータが信頼でき正確であることを求め、企業が自らの工程の理解に基づいてデータの扱いの危険を管理する方法を持つよう求めている。どの一件が欠けているかを後から特定できる状態は、この要求の一部である。

欠落を一件ずつ名指せるなら、直した後の確認も一件ずつできる。一覧全体を作り直して「たぶん直った」と言うのと、欠けていた番号がいま載っていると示すのは、証拠の強さが違う。

06一件だけ欠けるのは、処理よりも記録が食い違っているからである

なぜ、一件だけが欠けるのか。処理そのものが壊れているなら、全部が欠ける。一件だけが欠けるときは、その一件を「もう済んだもの」として扱う何かが残っている。

よくあるのは三つである。同じものを二度作らないための済みの印が、実際には作られていないのに残っている。処理の途中で止まり、前半の記録だけが書かれている。日付の境目と実行の時刻がずれ、その日が前の実行と次の実行の間に落ちる。

だから、この種の不具合を直す作業は、しばしば記録を書き換えることになる。運営者の例でも、直しの中身は記録の削除だった。削除は取り消しにくい。AI に任せきりにせず、人が承認する場所をここに置く理由がある。

米国の国立標準技術研究所が 2006 年に出したログ管理の手引きは、組織が記録を作り、集め、保つ仕組みをあらかじめ整えておく必要を述べている。記録は事故の後に読むためのものだが、ここで見たように、記録そのものが処理の進み方を決めていることもある。何を残すかを決める作業は、何が起きるかを決める作業でもある。

07明日からは、識別子と期限を 1 文にし、原因を先に述べさせる

手順は五つある。

1. 欠けている一件を識別子で書く。「この日付の分が出ていない」「この受付番号が一覧にない」。症状の形容をやめ、値を書く。
2. 期待と期限を添える。ほかと同じように出ているはずだ、次の実行の時刻までに要る、と一文で足す。
3. 原因を先に述べさせる。直し方の提案より前に、その一件に何が起きたかを記録で示させる。示せないなら、記録が足りないことが先に分かる。
4. 取り消しにくい修正は、承認を分ける。記録の削除、公開、差し替えは、実行の前に内容を確かめて人が決める。
5. 直った証拠を一件で示させる。欠けていた識別子が、いま在ることを見せてもらう。全体が動いたという報告では足りない。

Mozilla が公開している不具合の書き方の手引きは、再現の手順が報告のうちで最も大切だとし、問題が複数あるなら別々に報告するよう求めている。相手が人でも AI でも、この二つは変わらない。一件ずつ、値で名指す。

Anthropic の指針は、求める結果の形と制約をはっきり書くほど、返ってくるものが安定すると述べている。識別子は、その最も短い書き方である。日付は 10 字に満たないが、探す範囲を一件にまで狭める。