AIの自動処理は静かに失敗する｜空振りに気づくためのチェック設計

AIに定期タスクを任せていると、ある日ふと「これ、本当に動いてる？」と不安になることがあります。私の場合は、不安になる前に実際に失敗していました。

前回の記事の失敗談で少し触れた、Wikiへの自動取り込みの件です。週に一度、WebクリップをAI用の知識ベースへ取り込むルーティンが、2週続けて「対象0件」で終わっていました。画面上はどちらも成功。エラーもありません。気づいたのは、私が「取り込み件数が合わない」と指摘したときでした。

こういう失敗は、派手に落ちるよりも厄介です。止まったことに誰も気づかないまま、時間だけが過ぎていくからです。

この記事では、静かな失敗のパターンと、気づくためのチェックの考え方を、私のVaultで回している仕組みを例に紹介します。完璧な監視の話ではなく、失敗のたびに「次は何で気づけるか」を足していった記録です。

静かな失敗は3種類ある

ひと口に「自動処理の失敗」と言っても、気づきにくさは型によって違います。エラーで止まってくれるなら、まだ親切なほうです。厄介なのは、何も言わずに終わる失敗でした。

私の経験と公式ドキュメントの仕様を突き合わせると、静かな失敗は次の3つに分けられます。

失敗の型	例	失敗の通知で気づけるか
実行されない	PCがスリープしていた／クラウド側の連携が切れていた	気づけない（履歴を見に行けば分かる場合もある）
途中で止まる	権限の承認待ちのまま止まる／応答しなくなる	気づけない場合がある
成功したが中身が空	対象0件のまま正常終了する	気づけない（表示は「成功」）

一般的なcron監視の記事が主に扱うのは、1つ目の「実行されない」型です。AIに任せる処理で特に注意したいのは、3つ目のほうでした。

「実行されない」は、そもそも何も起きない

Claude Codeの定期実行（この記事では「ルーティン」と呼びます。公式名は定期タスクで、画面によっては今も「ルーティン」と表示されます）には、ローカルで動くものとクラウドで動くものがあります。どちらにも、黙って実行が飛ぶ仕様があります（2026-11-07時点の公式ドキュメントで確認）。

• ローカル（デスクトップアプリ）：アプリが起動していてPCが起きている間だけ動く。スリープ中に予定時刻を過ぎた分はスキップされ、復帰時には直近7日以内の取りこぼしのうち最新の1回だけが実行される
• クラウド：GitHubとの連携が切れていると、再連携するまで実行がスキップされる。72時間を超えるとタスク自体がオフになる
• セッション内の定期実行（/loopなど）：作成から7日で自動的に失効する

どれも、失敗として通知されることはありません。スキップの記録が管理画面の履歴に残る場合もありますが、自分で見に行かない限り気づけないんですよね。ローカルとクラウドの使い分けそのものは、別の記事で詳しく扱う予定です。

履歴の「成功」は、仕事の完了ではない

3つ目の型を裏付けるのが、クラウドのルーティンの履歴表示です。履歴の一覧では、失敗や取り消しになった実行にだけ目印が付き、成功した実行には何も表示されません。絞り込みのステータス欄には「成功」「失敗」などの選択肢が並びます。

ただ、公式ドキュメントには、この「成功」は「セッションがどう終わったか」を表すもので、頼んだ仕事をClaudeが完遂したかどうかではない、と明記されています。ネットワークに弾かれた、ツールが使えなかった、作業を終えられなかった、といった事情はトランスクリプト（実行中のやり取りの記録）側に出るだけで、履歴の行には現れません。

実際に私のWiki自動取り込みの履歴を絞り込むと、7回すべてが「成功」で、失敗は0件でした。空振りした9月20日と27日の回も、ほかの回と並んで「成功」に数えられています。

冒頭の空振りも、まさにこれでした。原因は、Webクリップを置いていたフォルダが.gitignoreでGitの管理対象から外れていたことです。クラウドのルーティンは毎回リポジトリをクローンして動くため、管理対象外のフォルダはクラウド側に存在しません。

AIは「取り込む対象が0件でした」と正直に報告して、正常に終わっていました。嘘はついていないのに、仕事は何も進んでいない。トランスクリプトを読めば分かったはずですが、毎週それを読む人はいませんでした。

異常を探すのをやめて、正常の痕跡を探す

では、どうすれば気づけたのか。エラーを通知する仕組みを足しても、この空振りは拾えません。エラーが一度も出ていないからです。

そこで発想を逆にしました。「異常が起きたら知らせる」のではなく、「正常に動いた痕跡が無ければ疑う」ことにしたのです。

デッドマンスイッチという考え方

サーバー運用の世界には、この考え方を使った「デッドマンスイッチ」（ハートビート監視とも）という監視方法があります。ジョブが終わるたびに監視サービスへ「動いたよ」という合図を送り、決まった時間内に合図が来なければ警告を出す仕組みです。

Healthchecks.ioやCronitorのようなサービスが代表例です。合図の想定間隔と猶予時間を決めておくと、合図が遅れた時点で「遅延（Late）」、猶予も過ぎたら「停止（Down）」として扱われ、停止の段階で通知が届きます。

ポイントは、失敗した実行が無くても警告が出ることです。「実行されない」型にも効くのは、この仕組みならではの強みでしょう。

個人のVaultなら、ファイルそのものが痕跡になる

とはいえ、個人のVaultのために外部サービスを契約するのは大げさです。そこで私は、ルーティンが残すもの自体を痕跡として使うことにしました。

• 収集系のルーティンなら、決まった名前のノートが日付どおりに増えているか
• 取り込み系なら、取り込み記録（ログ）に処理済みの行が増えているか
• どのルーティンも、実行するとGitにコミットが残るか

ファイル名・コミット日時・ログのどれも、Vaultの中を見るだけで確かめられます。

私のVaultでの実装：週次メンテの「ループ稼働チェック」

この考え方を、毎週月曜に動く週次メンテナンス（これもクラウドのルーティン）の1項目として組み込みました。2026年10月5日に追加し、10月12日から本番で確認しています。

見ている対象は次のとおりです。

対象のルーティン	確かめる痕跡
AIニュースの日次収集	前週の平日分のノートが、日付ごとに揃っているか
週次レポート（2種類）	前日（日曜）の日付のレポートがあるか
Wikiへの取り込み	取り込み記録に載っていないクリップが、前週より前から残っていないか
月次の競合リサーチ巡回	月初を含む週だけ、ログとコミットの両方があるか

ここからは、作ってみて「これは入れてよかった」と感じた設計のポイントを紹介します。

「OK／異常」の間に「確認不能」を置く

一番大事にしたのが、判定を「OK／異常」の2つにしないことです。結果は「OK／異常／確認不能」の3つで記録しています。

検査の対象が0件だったとき、あるいはコマンドが失敗して何も取れなかったとき。これを「異常なし」と書いてしまうと、冒頭の空振りとまったく同じ構図になります。見張り役が空振りして「問題なし」と報告するわけです。

だから、0件や取得失敗は必ず「確認不能」として扱い、異常と同じく報告の対象にしています。「見ていないから問題が見つからなかった」と「問題なし」を区別するための、3つ目の状態です。

カナリア値で「急に減った」を拾う

もうひとつ、毎回の実行でフォルダごとのファイル数を記録しています。炭鉱のカナリアにちなんで、私は「カナリア値」と呼んでいます。

前回の記録より半分未満に減っていたら、「確認不能（急減）」にします。クリップを整理して正当に減ることもあるので、異常とは分けて扱うことにしました。

実行時間の下限で空振りを見つける方法も考えました。Cronitorでは、実行時間の下限を条件として設定し、短すぎる終了を検知することもできます。ただ、AIの実行は所要時間のばらつきが大きく、時間だけでは判断しにくいのが実情です。件数や成果物の有無で見るほうが、空振りには強いと感じています。

見張り役には修復させない

このチェックは、読み取りと報告しかしません。異常を見つけても、再実行や修正はしない決まりです。

見張り役が自分で直し始めると、「何が起きて、何を直したのか」が人から見えにくくなります。異常や確認不能があれば専用のフォルダにアラートのノートを1枚作り、私が開いて判断する形にしました。同じ対象が2週続けて引っかかった場合は、「継続」と明記されます。

試走で見つかった、チェック自体の空振り

組み込む前に手元で試走したところ、早速つまずきました。チェックそのものが空振りしたんです。

Gitでファイル一覧を出すと、日本語のファイル名がエスケープされた文字列で出てきます。そのせいで取り込み記録との名前の照合が成立せず、結果は「全部記録済み」。見張り役が、見張れていないのに「OK」を出した瞬間でした。

対処は、gitコマンドに-c core.quotepath=falseを付けるだけです。ただ、試走をしていなければ、この空振りに気づく手段はありませんでした。チェックを作ったら、一度は「わざと異常がある状態」で動かしてみるのがおすすめです。

動かしてみてどうだったか

2026年11月2日までの4回は、すべてOKでした。アラートのノートは、まだ一度も作られていません。

「それなら要らなかったのでは？」と思われるかもしれません。ですが、「確認した結果OK」と「誰も見ていないので問題が出ていない」は別物です。毎回のログにはカナリア値の推移も残り、Webクリップの数が26から35へ順調に増えていることまで追えます。何も起きていないと確認できることが、一番の安心材料になっています。

見張り役にも限界がある

ここまで書いてきた仕組みにも、穴はあります。最後に、私が把握している限界を正直に書いておきます。

見張り役が止まったら、誰も気づかない

ループ稼働チェックは、週次メンテナンスの1項目です。つまり、週次メンテナンス自体が動かなければ、このチェックも動きません。

その場合、アラートのノートは作られず、何も起きない状態になります。まさに「実行されない」型の静かな失敗です。見張り役を見張る仕組みは、現時点では用意できていません。今のところ、週に一度ログを目で見るという人の手に頼っています。

ガードも静かに素通しする

前回の記事で紹介した、Hooks（特定の操作の前に自動でスクリプトを走らせる仕組み）を使った「読まずに書く」ことへのガードにも、同じ種類の穴があります。

ガード役のスクリプトがエラーで落ちたり、時間切れになったりしても、既定では操作がそのまま通ってしまうんです。ガードが壊れたとき、ガードは何も言わずに道を開けます。これも静かな失敗のひとつです。

失敗時に操作を止める設定（"onFailure": "block"。Claude Code v2.1.295以降、2026-11-07時点）も用意されています。私自身は付けるかどうかをまだ保留にしていて、近いうちの振り返りか月一メンテナンスで判断する予定です。

「次は何で気づけるか」を足していく

見張り役の見張り役を作り、さらにその見張り役を……と考えると、きりがありません。どこかで人の目に戻ってくる設計は、避けられないと思っています。

なので私は、完璧を目指すのをやめました。失敗が起きたら、「次に同じことが起きたら、何で気づけるか」を考えて1つ足す。ループ稼働チェックも、試走で見つかったcore.quotepathの注意書きも、そうやって増えてきたものです。

まとめ

AIの自動処理は、エラーで止まるより「成功したのに中身が空」という形で失敗するほうが気づきにくいものです。今回のポイントをまとめます。

• 静かな失敗には「実行されない」「途中で止まる」「成功したが空」の3つの型がある
• 履歴の「成功」はセッションの終わり方であって、仕事の完了ではない
• 異常を探すより、正常に動いた痕跡（ファイル名・コミット・ログ）が無いことを疑う
• 0件や取得失敗は「問題なし」にせず、「確認不能」として報告する
• 見張り役にも限界がある。失敗のたびに「次は何で気づけるか」を足していく

まずは、自分のルーティンが「何を残せば正常と言えるか」を一つ決めるところから始めてみてください。痕跡が決まれば、それが無いことに気づく仕組みは後からでも作れます。