2026-08-28 公開 ／ やらかした話

自動化は「エラーを出して止まる」より「黙って一部だけ動かなくなる」ほうが多い

個人で自動化を組んでいると、壊れ方には偏りがあることに気づきます。派手に落ちて通知が飛ぶ壊れ方は、むしろ楽なほうでした。厄介なのは、毎日動いていて、ログにも「完了」と出ていて、それでも中身の一部だけが出てこなくなる壊れ方です。この1か月で3回やったので、それぞれ何が起きて、どうすれば気づけたのかを書きます。

事例1: ファイルの権限が1つだけ違っていた

複数の処理を組み合わせた収集の仕組みがあり、そのうち補助的な1つの層だけが3日間動いていませんでした。ログにはこう出ていました。

原因は、更新の際にそのファイルだけ所有者と権限が他と違う状態で置かれていたことです。他のファイルが「所有者以外も読める」設定だったのに対し、そのファイルだけ「所有者とグループしか読めない」設定でした。

ここに、もう1つの事情が重なります。この仕組みは役割ごとに実行ユーザーを分けていました。調べる処理と、結果を取り込む処理は別のユーザーです。問題のファイルは取り込み側のグループが所有していて、実際に読もうとしたのは調べる側のユーザーでした。グループが違うので、「グループまで」の権限では届きません。

厄介なのは本体の処理は正常に完走していたことです。補助層は「落ちても本体は止めない」設計にしてあり、それ自体は正しい判断でした。ただ結果として、毎日「完了」と表示されながら、取れる情報が減っていました。

事例2: 実行ユーザーを変えたら、途中のディレクトリを通れなくなった

これは事例1と似ていますが、原因の階層が違います。セキュリティを見直したときに、いくつかの定期処理の実行ユーザーを、共用のものから用途別のものへ変更しました。方針としては正しい変更です。

ところが変更後、3つの処理が1週間まるごと止まりました。新しいユーザーが、必要なディレクトリを通り抜けられなかったからです。

ディレクトリの権限は、中のファイルを読む権限とは別に「そのディレクトリを通過してよいか」を持っています。目的のファイルが誰でも読める設定でも、途中のディレクトリを通れなければ届きません。ユーザーを変えるということは、そこまでの経路の権限がすべて変わるということでした。

直し方自体は簡単で、アクセス制御リスト（ACL）で通過だけを許可すれば済みます。問題は1週間気づかなかったことのほうです。

事例3: 監視が「失敗の記録」を新しさとして数えていた

これがいちばん反省した件です。私は自動処理の健康状態をまとめて確認する仕組みを持っていて、その中で「バックアップが最近成功しているか」を見ていました。判定の中身はこうです。

• ログファイルの最終更新時刻が古くないか
• ログに含まれる成功行の通算件数

一見それらしいのですが、これは失敗を検出できません。処理が毎回失敗していても、失敗したという行はログに書かれます。書かれるということはファイルの最終更新時刻は新しくなります。成功行の通算件数も、過去に成功した分が残っているので減りません。

つまり「毎日きちんと失敗し続けている」状態が、健全と判定されていました。実際、転送先が失われた後もずっと失敗し続けていた処理があり、それを検出できていませんでした。

直した判定はこうです。

ログが更新されているかではなく、成功が更新されているかを見ます。当たり前に聞こえますが、監視を書いているときは「動いていること」を確認したくなるので、つい更新時刻を見てしまいました。

同じ仕組みでもう1つ直したのは、失敗したサービスの一覧を見ていなかったことです。定期実行の中には、成果物を出さずに黙って終わるものもあります。それらが壊れても成果物が減るだけなので、「失敗状態のユニットが1つでもあるか」を直接見る項目を足しました。

3つに共通していたこと

並べてみると、原因はバラバラですが、気づけなかった理由は同じでした。

成果物を見て、正常だと判断していたことです。

• 事例1: 一覧は毎日出ていた（中身が少し減っていただけ）
• 事例2: 他の処理は動いていた（3つだけ止まっていた）
• 事例3: ログは毎日更新されていた（中身が失敗だっただけ）

成果物は「出たもの」しか映しません。出なかったものは、定義上そこに映らない。だから成果物をいくら眺めても、欠けている部分は見えません。

入れてよかった仕組み

1. 実行記録を、画面のいちばん上に常に出す

結果一覧の最上部に、前回の実行の要約を1行で出すようにしました。実行時刻、新規件数、更新件数、各層の成否です。そして2日以上更新が無い場合と、どこかの層が失敗した場合は、その行の色を変えます。

「見に行けば分かる」ではなく「見に行かなくても目に入る」のが要点です。私はこの一覧を毎日見るので、上に出しておけば異常はいずれ目に入ります。別に監視ダッシュボードを作るより、こちらのほうが自分には効きました。

2. 「聞いた対象」と「返ってきた対象」を別々に記録する

収集の自動化では、対象ごとに「最後に調査対象へ含めた日」と「最後に結果が取れた日」を別々に持つようにしました。この2つが揃うと、「調べたけれど無かった」と「そもそも届いていない」を区別できます。

3. 成否の判定は「最後の成功」で書く

これは事例3の教訓そのものです。更新されているか、ではなく、成功が更新されているか。ログの最終更新時刻、件数の累計、ファイルの存在チェックは、どれも失敗し続けている状態を素通りさせます。

やらなかったこと

逆に、やろうとしてやめたこともあります。検査項目を増やすことです。

事例3のあと、最初は「バックアップの中身も検査しよう」「サイズの変化も見よう」と項目を足そうとしました。ですが手を止めました。問題は項目の数ではなく、判定の作り方が間違っていたからです。同じ作り方のまま項目を増やすと、素通りする検査が増えるだけです。

実際にやったのは、既存の判定を「最後の成功」に書き換えることと、失敗ユニットを直接見る1項目を足すことだけでした。増やすより、既にある判定が本当に失敗を捕まえられるかを1つずつ確かめるほうが、費用対効果が高かったです。

持ち帰れること

• 自動化は「一部だけ黙って動かなくなる」壊れ方をする。通知は鳴りません。完了と表示されます
• 更新でファイルを置くときは、所有者と権限を明示する。手元の権限がそのまま持ち込まれ、サーバー側の実行ユーザーから読めなくなります
• 実行ユーザーを変えるときは、経路のディレクトリを通れるか確認する。ファイルの権限だけ見ても足りません
• 鮮度は「最後に成功した時刻」で見る。ログの更新時刻や累計件数は、失敗し続けている状態を健全と判定します
• 実行記録を成果物の画面の最上部に出す。別途ダッシュボードを作るより、毎日見る画面に混ぜたほうが気づきます
• 検査項目を増やす前に、既存の判定が失敗を捕まえられるか確かめる。作りが同じなら、素通りする検査が増えるだけです

個人の自動化は、止まっても誰も困らないので、止まったことに気づく機会がありません。だからこそ「動いている」ではなく「今日も成功した」を記録する必要がある、というのが3回やって得た結論です。