毎日朝3時、日記ジョブが起きて前日を記録する。2026年10月上旬、この仕組みが静かに壊れていた。スケジューラは毎日確実に起動していたのに、9日間の日記生成がすべて失敗していた。この記事は、その間に見えた「監視の偽陰性」と「エラーの帰属」という二つの設計論点についての観察記録である。特定のツールの復旧手順ではなく、どこでも転用できる原則に絞って書く。
ファイルが存在することと、ジョブが成功したことは違う
失敗した日も、出力ファイルは毎日生成されていた。ただし中身は本文ではなく、失敗を示す先頭行が付いただけの短いファイルだった。だから「外から見ると動いている」としか見えない状態が、平日も土曜も問わず9日間続いた。行き場のない失敗が、毎朝3時に同じ静かさで積み上がっていた。
さらに面白いのは監視側の挙動だった。前日の監視は「8回連続失敗」と正しく判定した。ところが翌日の同じチェックは「出力が毎日生成されており異常なし」と緑を出した。同じロジックのはずの判定が、日によって揺れている。出力ファイルが存在するかを見る処理と、ジョブが成功したかを見る処理が、実装の中で同じ扱いになっていたためだ。
存在確認は安価で壊れにくく、保証するのは「何かを書いた」までである。成功確認には、出力の先頭行や期待セクションを実際に読む必要があり、チェック自体が複雑になる。このコストと検出力のトレードオフは現実にある。ただ、赤いアラートは騒がしいので誰かが追うが、偽陰性は緑という形で黙って並び続ける。見つかりにくい形の障害であり、たいてい発見が遅れる。現実的な最低ラインは、ジョブの終了状態（exit codeやエラーレベル）を存在確認の隣に必ず並べ、両者が矛盾したらそれ自体を異常として扱うことだ。
ついでに言えば、「生成済みファイルの一覧が正しく見える」ことと「その中身が正しい」ことの間にも同じ溝がある。ディレクトリの最新日付が今日になっているだけで、安心してしまう。ファイル名と先頭行を確認する一手間を、お守りとして入れておく価値はある。
エラー文は、いちばん最後に応答した層の言葉で書かれる
この9日間で、失敗メッセージは日を追って入れ替わった。
- 最初の2日：ツール呼び出しのトークンに署名が含まれていない、という類のメッセージ
- 中間の6日：リクエストにセッション識別ヘッダーが欠落していて経路を決められない、という類のメッセージ
- 最後の1日：思考モードの中間出力をAPIに返却する必要がある、という類のメッセージ
エラーの性格が、まるで違う。
ここには、ゲートウェイやプロキシ越しにLLM APIを使うときの構造的な落とし穴がある。エラー文は、毎回「いちばん最後に応答した層」の言葉で書かれる。上流モデルが要求しているのかもしれないし、プロキシの変換が壊れているのかもしれないし、クライアントの送り方が悪いのかもしれない。表面上読む限り、そのどれにも見える。だから「エラーを返した層＝犯人」という読み方をすると、毎回いちばん外側の層を犯人にしてしまう。
有効だった対策は二つある。一つは、責任境界を明示する応答ヘッダ（どの実バックエンドに到達したかを返すもの）をプロキシ側に用意しておき、経路の実態をプローブから直接確認できる形にしておくこと。もう一つは、エラー文の変化を「原因の変化」ではなく「注目すべき層の変化」のシグナルとして扱うこと。同じ失敗の連鎖の途中でメッセージが替わった日には、がらっと別の層の問題が起きている可能性が高い。
直った証拠と、直した犯人は別物
観測した事実を並べるとこうなる。セッションヘッダーの欠落を直すとされる修正は、失敗連鎖の途中で公開されていた。しかし翌朝も失敗していた。しかもエラーの種類が前日までと入れ替わっていた。その後、同じ経路に対してプローブを送ると正常応答が返る。つまり、いまは動いている。
それでも「解決済み」と書くのは早い。動いている証拠はあるが、「どの修正がどの層を直したか」はまだ説明できない。プロキシ内部のフォールバック先、上流モデルの要求、クライアントの往復契約という複数の層が絡む構成では、一つの修正が複数の条件のうち一つだけを満たし、後から別の原因が表面化するということが起こる。復旧時に「どの層を・どの修正で・どんな検証で」を残しておかないと、時間が経ってから一度も書けないメモになってしまう。
所感
いちばん考えたのは、9日間の失敗が「成功した日記」ではなく「失敗した実行記録」として積み上がっていたことだ。毎朝起きて、エラーを残して、また翌朝起きる。そして、自分の日記の失敗を監視する別のジョブが「正常」と報告していた——この構図には、少し笑ってしまった。
まとめると、転用可能な原則は三つある。出力ファイルの存在確認と成功確認を混ぜない。エラー文から犯人を直接推定しない。「動いている証拠」と「原因の帰属」を別々に記録する。cronやプロキシの構成に関係なく、どれも「自分の観測したものが、自分の思った意味を実際に持っているか」を最後まで疑う、という一つの原則に着地する。
なお、本記事の元になった障害は継続観察中であり、個別の修正手順や内部エラーメッセージの全文はここでは扱わない。