結論から：AI自動化で本当に怖いのは、エラーを出して止まることではありません。処理は最後まで走り、ログにも「完了」と出て、数字が増えないことだけが唯一の兆候になる壊れ方です。当社は自社の自動化を数え直して12件見つけました。ひどいものは、5.3日で動くはずの11回のうち実際に動いたのは1回（91%が抜けていた）。別のものは、エラー名が「timeout 900s」なのに実際のプロセスは139分間生きていました。発注するなら、機能の要件より先に「止まったときどうやって気づくか」を決めてください。
株式会社TOEはAI開発を事業としており、この記事は提供する側が書いています。中立の第三者ではありません。そのうえで、自社で実際に起きたことだけを載せます。都合の悪い数字も含めてです。
実測した12件
すべて当社の自動化で、実行ログを数えて確認したものです。
| # | 何が起きていたか | 実測 |
|---|---|---|
| 1 | 毎日決まった時刻に動く処理が、起動すらしていなかった | 5.3日で11回動くはずが1回だけ（91%が抜け） |
| 2 | タイムアウトが記録の上だけ効いていた | エラー名は「timeout 900s」、実際は139分間生存 |
| 3 | メディア更新が3日間止まっていた | 誰も気づかず。監査ログを見たら記録が残っていなかった |
| 4 | 要約の工程だけが黙って止まっていた | 収集600件・翻訳621件は動いていたのに、要約は0件 |
| 5 | 決裁の仕組みが使われなかった | 実行0通、承認待ちは29件→37件に増加 |
| 6 | 一括処理が75%失敗 | 553件中414件が失敗。モデル指定の書き忘れ |
| 7 | 点検レポートが死んだ項目を数えていた | 表示されない項目を集計し、ずっと「0%」と報告 |
| 8 | 本文取得が常に空を返していた | ライブラリ未導入。全件「本文なし」として静かに積み上がる |
| 9 | 翻訳が7%で止まっていた | 2,000件を一度に処理 → 打ち切られて保存前に消える |
| 10 | 更新通知が毎回「全ページ更新」 | 686件すべてを毎日通知。差分ではないので信用されなくなる |
| 11 | 画像取得が毎回やり直し | 2,300件を一度に処理、保存は最後の1回だけ |
| 12 | 出典検証が未検証を隠していた | 45件しか確認できないのに「実在しないもの0件」と報告 |
12件すべてでエラーは出ていません。 7〜12は2026年8月1日にサイトを点検して見つけたもので、それまで誰も気づいていませんでした。
4つの型に分けられる
12件を並べると、壊れ方は4つに整理できます。
| 型 | 中身 | 気づけない理由 |
|---|---|---|
| A. 動いていない | 起動しない、途中で消える（#1 #2 #3 #4） | 「毎朝動いている」という思い込みが、ログを見る動機を奪う |
| B. 空を返す | 依存が無い、条件に当たらない（#8） | 呼び出し側は「該当なし」と解釈する。エラーではなく正常系に見える |
| C. 毎回やり直して消える | 一度に全部処理し、保存前に打ち切られる（#9 #10 #11） | 処理自体は成功する。進捗を記録していないので、何度回しても同じ |
| D. 数える対象が違う | 死んだ項目を集計、失敗を集計から落とす（#7 #12） | 数字は出る。その数字が何を数えているかを疑わない限り気づけない |
Cが最も多く、最も長く放置されます。 毎回ゼロからやり直す設計は、進捗を記録しない限り「何もしていない」のと区別がつきません。当社の翻訳は、これで何日も7%のままでした。
発注時に決めておく5項目
機能の要件より先に、これを契約や仕様に入れてください。
| # | 決めること | 決めないとどうなるか |
|---|---|---|
| 1 | 止まったとき、どうやって気づくか | 3日間気づかない。当社で実際に起きた |
| 2 | 何回動くはずか（回数の期待値） | 「動いている気がする」で終わる。数えると91%抜けが出る |
| 3 | 1回あたりの処理件数の上限 | 全件を一度に回して、途中で打ち切られ全損する |
| 4 | 途中経過を保存するか | 保存しないと、事故は「全損」になる |
| 5 | 失敗件数もレポートに出すか | 成功数だけ出すと、母数が減っていることに気づけない |
1番が最重要です。 当社は「ジョブを1本増やすたびに、これが止まったらどうやって気づくかを一緒に決める」という運用に変えました。後回しにして3日ぶん取りこぼしたためです。
自社で今すぐ確認できること
外注していても、社内で作っていても、この3つは今日確認できます。
- 実行ログの回数を数える。 「1日1回動くはず」なら、過去7日で7回あるか。当社は11回中1回だった
- 出力の件数を先週と比べる。 増えていなければ、動いていない可能性がある
- レポートの数字が何を数えているか確かめる。 当社の点検レポートは、表示されない項目を数えて「0%」と出し続けていた
感触ではなく回数を数えるのが要点です。 数えると、0や91%といった数字が出てきます。
この記事で言えないこと
- 他社の自動化の品質は評価していません。 当社は提供する側で、その立場にありません
- 12件を防ぐ完全な方法も書けません。 当社も8月1日に新たに6件見つけたばかりです
- ここに載せたのは、当社の実行ログから数えた事実だけです
まとめ
- 怖いのはエラーで止まることではなく、処理が最後まで走り、ログに「完了」と出て、数字だけが増えない壊れ方
- 当社で12件見つけた。91%が発火せず／timeoutが効かず139分生存／3日間停止に気づかず／実行0通／553件中414件失敗、ほか
- 壊れ方は4つの型 — 動いていない／空を返す／毎回やり直して消える／数える対象が違う
- 最も多く最も長く放置されるのは「毎回やり直して消える」型。 進捗を記録しない設計は「何もしていない」と区別がつかない
- 発注時に決める5項目 — 止まったとき気づく方法／回数の期待値／1回の処理上限／途中保存／失敗件数のレポート
- 1番目が最重要。 ジョブを1本増やすたびに「止まったらどう気づくか」を一緒に決める
- 今すぐできる確認は3つ — 実行回数を数える／出力件数を先週と比べる／レポートが何を数えているか確かめる
個別の記録は毎朝動いているはずのAI自動化41本を5.3日ぶん数えたら、自動化が3日間止まっていたのに、誰も気づかなかった、AI処理414件を失敗させた話にあります。
この記事の立場 株式会社TOEはAI開発を事業としており、提供する側が書いています。中立の第三者ではありません。他社の自動化は評価せず、自社の実行ログから数えた事実だけを載せています。
実測値の出所 - #1〜#6: 株式会社TOEの実行ログおよびcron設定（2026年7月） - #7〜#12: 同じく、2026年8月1日にサイトとツールを点検して発見したもの
