動いていた自動化が、ある日 音もなく止まる

自動化の仕組みを一度組んでしまうと、日々の運用ではその存在を忘れがちです。毎朝レポートを送る、毎晩データを同期する、決まった時間にAIが処理を実行する——動いていて当たり前になったころに、静かに止まります。

止まる引き金の多くは、自分が書いたロジックの不具合ではありません。連携している外部サービス側の変化です。具体的には次の4つに集約できます。

  • 認証の承認が取り消された、またはユーザー側の操作で失効した
  • アクセストークンやAPIキーが有効期限を迎えた
  • 外部サービスのAPI仕様（レスポンス形式・エンドポイント・必須パラメータ）が変更された
  • 利用料金プランや利用規約が改定され、従来の使い方が制限された

これらはすべて自分のコントロールの外側で起きます。コードのレビューをどれだけ丁寧にやっても、この種の停止は防げません。

「エラー監視を入れましょう」では捕まらない停止がある

自動化のトラブル対策として最もよく語られるのは「エラー監視を入れる」「ログを見る」という助言です。これは正しいのですが、実は前提条件があります。エラーが発生して初めて機能する、という前提です。

ところが外部依存の変化による停止には、エラーそのものが発生しないケースが少なくありません。

  • 認証権限を失った結果、処理が始まる前に静かに終了する
  • 権限不足でリクエストが弾かれても、例外を握りつぶす実装だと何も表に出ない
  • API仕様が変わり、以前とは違う空のデータが「正常終了」として返ってくる

いずれも、ログを見張る監視の網には引っかかりません。処理自体は「成功」した扱いのまま、中身が空だったり、実行そのものが行われなかったりするからです。

ここが対策の分岐点です。「失敗を検知する」設計だけでは足りません。必要なのは「成功が定期的に届いているかどうかを検知する」設計への反転です。自動化が最後に成果物を出したのはいつか、想定した間隔どおりに届いているかを、外側から数えておく仕組みを持つということです。処理の中身を信頼するのではなく、処理の到着を疑う姿勢に切り替えるとも言えます。

外部依存を棚卸しする

気づける設計の出発点は、点検ではなく棚卸しです。自分の自動化が何に依存しているかを、一度すべて書き出します。書き出す項目は次の4つです。

  • 何に依存しているか（サービス名・API・連携アカウント）
  • その依存はいつ切れる可能性があるか（期限があるか、通知なく変更され得るか）
  • 切れたら、具体的に何が止まるか（どの業務・どの数字が欠けるか）
  • 代替手段はあるか（手動で当座しのげるか、別の経路はあるか）

この一覧が無いまま自動化の本数だけ増やしていくと、止まったときに「何が」「どこまで」影響を受けているのかを把握するのに時間がかかります。棚卸しは一度作って終わりではなく、新しい自動化を組むたびに1行足していく台帳として扱うのが実務的です。

棚卸しの過程で気づきやすいのは、依存が思っていたより多層になっていることです。ひとつの自動化が、認証・API・通知先・保存先と、複数の外部要素を経由していることは珍しくありません。どれか一つが変化しただけで全体が止まるという構造そのものを、まず可視化することが対策の土台になります。

期限のあるものは、先に思い出す仕組みにする

棚卸しの中でも特に扱いやすいのが「期限が決まっているもの」です。次のようなものが該当します。

  • アクセストークン・リフレッシュトークンの有効期限
  • SSL証明書や各種認証情報の更新期限
  • 外部サービスとの契約・サブスクリプションの更新日
  • 無料枠・トライアル期間の終了日

これらは「いつか切れる」ことがあらかじめ分かっている点で、他の外部依存より対策しやすい部類です。切れる直前に慌てて思い出すのではなく、期限を一覧にしてカレンダーやリマインダーに先出しで登録しておく——これだけで、突然の停止のかなりの割合を「予定された作業」に変えられます。

逆に言えば、期限が明文化されていない依存ほど危険です。「なんとなく設定して以来、触っていない連携」ほど、いつ切れるかを誰も把握していないという状態に陥りがちです。棚卸しの段階で「期限が分からない」と判明したものは、それ自体をリスク項目として扱う必要があります。

仕様変更は、出力の形が変わったことで検知する

期限のように日付で管理できない依存もあります。外部サービス側のAPI仕様変更です。多くの場合、変更の告知は事前に出ますが、日々の運用の中でその告知をすべて追い続けるのは現実的ではありません。

告知を追いかける代わりに有効なのは、自動化が受け取っている出力の「形」を機械的に見張ることです。

  • 想定していたデータの項目（キー）が急に無くなっていないか
  • 件数が普段と比べて極端に少ない、あるいはゼロになっていないか
  • データ型や日付の形式が変わっていないか

これらは告知文を読解する必要がなく、「いつもと違う」という差分だけで検知できます。仕様変更そのものを予測するのは難しくても、仕様変更の結果として出力が崩れたことは、形の変化として捉えられます。

AIに任せる部分、人にしか判断できない部分

ここまでの棚卸し・期限管理・出力監視は、仕組みとしてAIやスクリプトに任せられる領域です。一方で、外部依存の管理には、人でなければ完結できない操作が残ります。

  • 認証の再承認（ログイン・二段階認証・本人確認を伴う操作）
  • 利用規約の同意・更新への合意
  • 料金プランの変更や契約更新の意思決定
  • 連携先サービスへの問い合わせ・サポート対応

これらは自動化がどれだけ賢くなっても、本人の同意や操作が前提になる領域です。だからこそ設計段階で線を引いておく必要があります。「ここまではAIが検知し、ここから先は人が実行する」という境界を先に決めておけば、停止に気づいたときに誰が何をするかで迷いません。逆に、この線引きが曖昧なまま自動化を増やすと、止まった後の対応そのものが属人化し、対応できる人が不在のときに復旧が遅れます。

私たち自身も、認証の承認が失効して自動実行が無音で全停止し、失敗ログすら残らなかった経験があります。それ以来、自動化が今も想定どおりに発火しているかどうかを点検する定期コマンドを持つようにしています。止まったことに気づくまでの時間を短くする、という一点に絞った仕組みです。エラーが出ないタイプの停止こそ、後から気づいたときのダメージが大きいというのが実感です。

止まる前提で、復旧手順を先に書いておく

依存を棚卸しし、期限を管理し、出力の形を見張っても、外部依存が変化する頻度そのものはゼロにできません。であれば、最後に整えておくべきは「止まった後にどう戻すか」です。

  • どの依存が切れたら、まず何を確認するか（棚卸し一覧のどこを見るか）
  • 再認証や再設定の手順を、止まる前の平常時に書いておく
  • 誰が対応するか（AIが検知した後の一次対応者）を決めておく

復旧手順は、止まってから慌てて書くものではありません。平常時に書いておけば、実際に止まったときは手順に沿って淡々と対応するだけになります。自動化を「壊れない仕組み」にすることは難しくても、「止まったことにすぐ気づき、早く戻せる仕組み」にすることは設計次第で十分に可能です。