AIが3日間暴走していた。
本当に怖いのは、無限のトークン消費

最近、なんとなく違和感がありました。

「週次の利用制限に近づくの、ちょっと早くないか？」

普段からClaude Codeをかなり使っているので、トークンを消費すること自体は珍しくありません。

ただ、それにしても早い。

そのとき、社内では15本ほどのAIセッションが動いていました。

そこで、

「どのセッションが一番トークンを使っているのか調べて」

とAIに調査させました。

すると、原因が分かりました。

プログラムが3日間ループしていた

ある処理が正常に終了せず、ループ状態になっていました。

しかも、それが3日間。

その間ずっと、AIを呼び出し続けてトークンを消費していました。

完全に暴走です。

怖かったのは、暴走そのものよりも、

でした。

AIの自動実行を増やしていくと、人間が画面を見ていないところで処理が動くようになります。

これは自動化のメリットですが、逆に言えば、

「誰も見ていないところで壊れる」

ということでもあります。

今回、まさにそれが起きました。

自動処理を止めたくなかったので、追加トークンを購入

困ったのが、普段から動かしている自動実行処理です。

社内では、AIが定期的に動いて業務を処理する仕組みをいくつも作っています。

ここで利用制限に達すると、自動処理まで止まってしまう可能性があります。

それを避けるために、追加トークンを購入しました。

ところが。

追加購入したトークンの減り方が、とにかく速い。

すでに暴走していたプログラムは止めています。

普通に使っているだけなのに、

「こんな勢いで減るのか」

という状態でした。

暴走によって、それまでの利用枠をかなり食いつぶしてしまっていた影響もあります。

さすがにこれはまずい。

そこで今回、トークン管理の仕組みそのものを見直すことにしました。

「暴走を直す」だけでは足りない

今回の原因になったプログラムだけ直して終わり。

では、また別の場所で同じことが起きます。

なので、今回やったのは、

1. 暴走に気づく。
2. 暴走を止める。
3. そもそも暴走しにくくする。

この3段階です。

プログラムのループや異常実行を検知する仕組みを追加し、一定条件を超えた処理は止められるようにしました。

さらに、

「トークンが急激に減っている」

という状態自体を監視するようにしました。

つまり、

という考え方です。

これなら、今回とは別の原因でトークンを大量消費しても気づけます。

普段使うAIモデルも見直した

もう一つ見直したのが、通常利用時のトークン消費です。

これまでは基本的にOpusを使い、難しい処理が必要なときだけFableのサブエージェントを呼び出す構成にしていました。

今回はさらに、

簡単な仕事なら、自動的に軽いモデルへ下げる

仕組みも追加しました。

すべての仕事に一番高性能なAIを使う必要はありません。

• ファイルを確認するだけ。
• 簡単な集計をするだけ。
• 決められた処理を実行するだけ。

こういう仕事まで、毎回強いモデルを使わせるのはもったいない。

人間の会社でも、

「全部の仕事を社長がやる」

なんてことはしません。

AIも同じで、

これからは、AI組織でもこの考え方が重要になると思っています。

Claude Codeが止まっても業務は止まらない

幸い、今回の件で実際の業務が止まることはありませんでした。

以前から、

Claude Codeが止まった場合は、Codexが代わりに処理する

という仕組みを作っていたからです。

なので、業務上の大きな実害はありませんでした。

ただ今回、

「トークン切れもシステム障害の一種」

だと実感しました。

• サーバーが落ちる。
• ネットが切れる。
• APIが止まる。
• AIが利用制限に達する。

原因は違っても、

なので、この代替処理の仕組みについても念のため強化しました。

初めてAIのミスで「お金」という実害が出た

これまでAIが間違えることは何度もありました。

• 変な回答をする。
• プログラムを間違える。
• 指示を勘違いする。

そういう失敗は普通にあります。

ただ今回、

AIやプログラムのミスによって、直接お金が減る

という経験を初めてしました。

追加トークンを購入することになったので、完全に金銭的な実害です。

でも、これはいい経験だったと思っています。

自動化を進めれば進めるほど、

「AIを動かす仕組み」

だけではなく、

AIが失敗したときに被害を広げない仕組み

が必要になります。

今回の失敗をきっかけに、その部分をかなり強化することができました。