数年かけて貯めるつもりだった記録の、初日の話です。処理は動いていました。判定も成立していました。買い目も出ていました。それでも記録ファイルには一行も残っていませんでした。原因は、前日に自分で書いた一行の設定でした。
前回までの話
この検証では「掘る」のをやめて「貯める」に切り替えました。過去のデータをいじり回して出した数字は、どれだけ良く見えても選択に使った後の数字で、上振れしているからです。
そこで、これから走るレースだけを、決めた手順どおりに記録し続ける仕組みを作りました。判定は1年後と5年後に1回ずつ。条件は先に文書化して凍結してあります。
その記録の初日が、今日でした。
朝の時点では、うまくいっているように見えていた
朝の処理は正常に終わっていました。当日の全出走馬に指標を付けて、ログに書いています。前日の夜の決済処理も、2本とも正常終了していました。
数時間後、記録ファイルを開いて数えました。
本日の記録 45件
うち「見送り」 45件
うち「買い」 0件
最初はこう読みました。「この戦略は年間100件くらいしか買い目が出ない設計だから、今日0件でもおかしくない」。
念のため「見送り」の理由を集計しました。ここで話が変わりました。
見送りの理由（全45件）
「データが到達せず打ち切り」 45件
「条件を満たさなかった」 0件
一件も「条件で見送った」がありません。全部「オッズが取れなくて判定できなかった」でした。
一度目の診断：「データが取れていない」——これは間違いでした
ここで私は「判定そのものが一度も成立していない」と報告しました。過去に似た事故があったので、同じ形だと判断したのです。
間違いでした。
別のログ——処理の実行時間や取得元を記録している方——を開くと、こう出ていました。
同じレース・同じ判定タイミングで、2つの行が42秒差で並んでいた
09:34:03 取得元A 判定成立 （指標も頭数も記録されている）
09:34:45 取得元B データなし
判定は成立していました。それどころか、その日のうちに実際に買い目が出た回も6件ありました。閾値をきちんと超えています。
問題は「取得できていない」ことではなく、「成功した判定が記録されていない」ことでした。
何が起きていたか
処理を走らせている入口が2つありました。
入口① 観測用 → 速いデータ取得を使う → 判定は成功する → ・記録は書かない設定
入口② 記録用 → 別のデータ取得を使う → 判定に失敗する → 記録を書くのはこちらだけ
成功しているほうは記録しない設定で、記録するほうが壊れた経路にいました。
そして入口②が壊れた経路にいた理由は、前日に私自身が書いた一行です。
コメントまで残っていました。
取得の競合を避けるため、速い方は使わない。
こちらのデータ源は生きている。
二行目の前提が、翌日に崩れていました。そのデータ源は前日の夕方から止まっていて、復旧していませんでした。前日の私は「いま生きている」を根拠に選択し、その前提が明日も続くかを条件として書いていませんでした。
学んだこと
① 「0件」は理由まで見ないと意味が反転する
0件には二種類あります。
条件で0件 → 設計どおり。健全
届かなくて0件 → 記録が成立していない。障害
この二つは、件数だけ見ると区別が付きません。そして前者だと思い込むのは、こちらの都合がいいほうです。理由の内訳を必ず集計する、という一手間だけが両者を分けます。
② 成果物を一つだけ開いて結論を出さない
私は記録ファイルだけを見て「判定ゼロ」と結論しました。開いたこと自体は正しかったのですが、開いた成果物が一つだけでした。
もう一つのログには、成功した判定がすべて残っていました。二つ並べて初めて「取得の失敗」ではなく「保存の失敗」だと分かりました。問題の場所が、上流から下流に一段動いたわけです。
③ 「いま生きている」を前提に選ぶなら、それを条件として書く
これがいちばん効きました。
前日の判断そのものは、悪くありません。競合を避けたいのは正当な理由です。問題は、その判断が「いまの状態」に依存していたのに、依存していることをどこにも書かなかったことです。
書いていれば、こうなります。
この設定は、データ源Aが生きていることに依存する。
Aが止まったら、記録は空になる。
そう書いてあれば、Aが止まった時点で誰かが気づけました。依存関係を書かないと、前提が消えたことに誰も気づけません。
④ 監視は「動いているか」ではなく「成立したか」を数える
処理の生存確認は全部緑でした。プロセスは動いていたからです。動いていることと、仕事が成立していることは別です。
数えるべきは起動回数でも行数でもなく、成立した判定の件数でした。行数はエラーでも増えます。
失われたもの、失われていないもの
・失われた 「決めた手順どおりに記録された」という事実
🟢 残っている 判定の中身そのもの（別のログに全部ある）
情報は残っています。やろうと思えば、もう一方のログから組み直せます。
しかしそれはやりません。この記録は「条件を先に決めて、その手順どおりに貯める」ことに意味があります。後から別の場所のデータで埋めたら、それはもう同じ記録ではありません。都合の悪い日だけ別ソースで補うのを一度許すと、記録全体の意味が消えます。
空いた日は、空いたまま残します。
まとめ
- 「0件」は理由まで見る。条件で0件と、届かなくて0件は、件数からは区別できない
- 成果物を一つだけ開いて結論を出さない。二つ並べて初めて、失敗の場所が上流から下流に動いた
- 「いま生きている」を前提に選ぶなら、依存していることを書く。書かなければ、前提が消えたことに誰も気づけない
- 監視は「動いているか」ではなく「成立したか」を数える。行数はエラーでも増える
- 穴は埋めない。手順どおりでない記録は、記録として使えない
初日から空白ができました。気持ちのいい話ではありませんが、5年分貯めてから同じことに気づくよりは、初日で気づいたほうがずっと安いです。
食べた記憶はあるのに、伝票がどこにもない。
