結論から言うと、AIエージェントの監視で一番怖いのは「エラーが出る故障」ではなく「エラーが出ない故障」だ。
自分はフリーランスエンジニアとして自作のAIエージェントシステムを半年以上運用しているが、一番ヤバかったのは「全部正常に見えるのに、実は何もしていなかった」という状況だった。プロセスは動いている。エラーログはゼロ。CPU使用率も正常。なのに成果物が出てこない。
この記事はこんな人に向けて書いている。
- AIエージェントを動かしてるけど、ちゃんと仕事してるか不安
- API代が想定より高いけど原因が分からない
- 監視やモニタリングをどこまでやればいいか分からない
- 「動いてるから大丈夫」で済ませてしまっている
ここで止まってる人ほど読んでほしい。
AIエージェントには「見えない壊れ方」が3パターンある
従来のサーバー監視といえば「プロセスが落ちたら通知」「CPU使用率が高かったらアラート」が定番だ。Webサービスならこれで十分なことが多い。
でもAIエージェントは根本的に違う。プロセスは元気に動いていて、CPUもメモリも正常で、エラーログもゼロ。なのに実際には何の成果も出していない、という状態がふつうに起こる。
自分の経験と海外のエンジニアが共有していた事例を合わせて、大きく3つのパターンに整理してみた。Webサービスの運用経験がある人ほど盲点になりやすいポイントだと思う。
パターン1: 静かに死ぬエージェント（ログに何も残らない）
一番シンプルだけど、一番気づきにくい故障がこれだ。
エージェントのプロセスがある日突然終了する。でもエラーログは何も残らない。クラッシュダンプ（異常終了時に出力される診断情報）もない。Pythonの例外トレースバック（エラーの発生箇所を示す情報）もない。プロセスがただ消えている。
原因はOSレベルのメモリ不足だ。OSがメモリを使いすぎたプロセスを強制終了する、いわゆるOOM Kill（Out of Memory Kill）が発生している。OSがプロセスを問答無用で殺すので、アプリケーション側でログを残す暇がない。
LLM系のライブラリはレスポンスをメモリにキャッシュするものが多い。最初は200MB程度だったメモリ使用量が、数日かけてじわじわ膨らんで、ある日突然限界を超える。そして深夜3時にOSに殺される。朝起きて「あれ、止まってる」と気づく頃には、6時間分の仕事が消えている。
従来の監視ツールがこれを検知できない理由は単純だ。ログに何も残らないから。ログ監視はログがある前提で動いている。存在しないログは監視できない。プロセス監視ツール（systemdやsupervisorなど）は終了コードを記録してくれるが、それに気づくのは翌朝だ。深夜3時にダッシュボードを見ている人間はいない。
パターン2: 生きてるけど働いてないゾンビエージェント
個人的にはこれが一番タチが悪いと思っている。
プロセスは動いている。CPU使用率は正常。メモリも安定。ヘルスチェック（定期的な生存確認）のエンドポイントに問い合わせても「正常」と返ってくる。あらゆる指標が「健康」を示している。
でも実際には、メインの処理ループが4時間前から止まっている。
典型的な原因は、外部APIへのHTTPリクエストがハング（応答待ちのまま固まる）することだ。接続先のAPIがTLS証明書を更新したタイミングでハンドシェイクがデッドロック（互いに待ち合って永久に進まない状態）を起こし、リクエストが永遠に返ってこなくなる。タイムアウトを設定していなければ、そのまま無限に待ち続ける。
なぜヘルスチェックでは検知できないのか。ヘルスチェック用のスレッドは別で動いているからだ。そっちは元気に「正常です」と答え続ける。でも実際に仕事をしているメインのスレッドは完全に停止している。健康診断では異常なしだが、仕事は一切していない。まさにゾンビだ。
自分も似た経験がある。自作のAIエージェントシステムで、ある処理が想定外のタイミングで実行されたことがあった。表面的にはシステムは正常に動いていたが、内部のロジックが意図しない順序で走っていて、結果として期待した成果物が別のものに差し替わっていた。ログを見ても「正常に処理完了」としか書いてない。見た目は健康、中身は機能不全。気づくまでに数時間かかった。
この手の問題は、経験上「何かがおかしい」と人間が直感で気づくまで発覚しない。監視ツールは全て「正常」と言っているのだから。
パターン3: 元気すぎるエージェント（API代が爆発する）
これが一番財布に直撃するパターンだ。フリーランスにとっては死活問題になりうる。
エージェントは動いている。仕事もしている。LLMのAPIを呼んで、レスポンスを処理して、また呼んで、処理して…を繰り返している。エラーは一つも出ていない。ヘルスチェックも正常。あらゆる指標が「快調に稼働中」を示している。
ただし、トークン消費量が通常の200倍になっている。
何が起きているかというと、外部APIから不正なレスポンスを受け取ったエージェントが、LLMにパース（解析）を依頼し、LLMの出力が同じ処理をトリガーし、またLLMを呼び、同じ結果になり…という無限ループに入っている。全ての呼び出しが正常に成功しているので、エラーは一つも出ない。
海外のエンジニアが共有していた事例では、通常1分あたり200トークン程度の消費が40,000トークン/分まで跳ね上がり、40分間で約50ドル（日本円で約7,500円前後）のAPI代が消えたという。40分で7,500円。これが深夜に発生して朝まで気づかなかったら、数万円が蒸発する計算になる。
怖いのは、従来の監視指標が全て「正常」を示すことだ。プロセスは動いている。ハートビート（定期的な生存報告）も正常に送信されている。エラー率はゼロ。CPUとメモリも正常（LLMの呼び出しはネットワーク通信が中心なので、CPU負荷は上がらない）。唯一異常なのは請求額だけ。そして請求額をリアルタイムで監視している人はほとんどいない。
じゃあどう監視すればいいのか：3つの監視の考え方
ここまでの3パターンに共通しているのは、従来のインフラ監視（プロセスの生存確認、CPU/メモリのダッシュボード、エラーログの監視）では検知できないということだ。
理由はシンプルで、従来の監視は「インフラの症状」を見ているから。AIエージェントの故障は「仕事をしているかどうか」というアプリケーションレベルの問題であり、インフラは正常なまま発生する。
必要なのは以下の3つの監視だ。
監視1: ポジティブ・ハートビート（サイレント停止対策）
「エラーが出たら通知」ではなく「定期的な生存報告が途絶えたら通知」という逆転の発想。エージェント自身がN秒ごとに「生きてます」と報告する仕組みを作る。報告が止まったら、理由が何であれ（OOM Kill、カーネルパニック、正常終了）、即座に異常と判定する。
従来の監視が「悪いシグナルを検知する」のに対して、ポジティブ・ハートビートは「良いシグナルの消失を検知する」。この発想の転換が重要だ。
監視2: 作業進捗ハートビート（ゾンビ対策）
ハートビートにもレベルがある。バックグラウンドスレッドからの生存報告だけでは、ゾンビは検知できない。なぜなら、ヘルスチェック用のスレッドは元気に動き続けるから。
ゾンビを検知するには、実際に仕事をしているメインループの中から生存報告を送る必要がある。メインループが止まれば報告も止まる。「プロセスが生きてるか」ではなく「仕事が進んでるか」を確認する仕組みだ。
監視3: コスト監視（暴走ループ対策）
これがLLMベースのエージェント特有の監視項目だ。従来のWebサービスには「1リクエストあたりのコストが200倍に跳ね上がる」という概念自体が存在しなかった。
ハートビートごとにトークン消費量を記録し、通常の10倍〜100倍に跳ね上がったらアラートを出す。API提供元のダッシュボード（OpenAI APIやClaude APIの管理画面）で日次の使用量を確認するだけでも、かなりの異常は早期発見できる。
整理するとこうなる。
| 監視の観点 | Webサービス | AIエージェント |
|---|---|---|
| 生きてるか | プロセス確認 | ポジティブ・ハートビート |
| 仕事してるか | レスポンス速度 | 作業進捗ハートビート |
| 健全か | エラー率 | コスト（トークン消費量） |
Webサービスの運用経験がある人は、左の列の感覚で監視を組みがちだ。でもAIエージェントには右の列の発想が必要になる。
フリーランスこそ「コスト監視」を最優先にすべき理由
会社員としてAIを触っている分には、API代が多少膨らんでも会社の経費で吸収される。でもフリーランスは違う。API代は全額自分の財布から出る。
自分は自作のAIエージェントシステムを日常的に運用していて、LLMのAPIを毎日使っている。正直なところ、最初の頃はコスト監視が甘かった。「まあ動いてるし大丈夫でしょ」で済ませていた時期がある。
ある日、想定していない処理が走って、別のタスクが意図しない順番で実行されたことがあった。結果的に大きな金銭的被害にはならなかったが、「これが深夜にAPI呼び出しの無限ループだったら」と思うとゾッとした。それ以来、処理の実行状況とコストの推移は必ずチェックするようにしている。
AIエージェントの運用コストは、VPS代（月額数百円〜数千円程度）よりもAPI代の変動幅のほうがはるかに大きい。Claude APIやOpenAI APIの料金は、モデルやトークン数によって大きく変わる。特にClaude OpusクラスやGPT-4クラスのモデルを使っている場合、暴走ループが発生したときのダメージは深刻だ。
フリーランスでAIエージェントを運用するなら、以下は最低限やっておいたほうがいい。
- APIのダッシュボードで日次の使用量を確認する習慣をつける
- 月額の上限設定（スペンディングリミット）を設定する。OpenAI APIもClaude APIも上限設定機能がある
- 処理ループには必ずタイムアウトとリトライ上限を設ける
- 深夜帯に動く処理は特に注意する。人間が寝ている間の暴走が一番怖い
「動いてるから大丈夫」は、AIエージェント運用において一番高くつく油断だ。
まとめ
- AIエージェントには「エラーが出ないのに壊れている」という故障パターンが3つある（サイレント停止、ゾンビ化、暴走ループ）
- 従来のインフラ監視ではこれらを検知できない。「仕事をしているか」をアプリケーションレベルで監視する必要がある
- フリーランスは特にコスト監視が重要。API代の暴走は事業継続に直結する
「正常に動いてます」を信じるな。「ちゃんと仕事してるか」を確認しろ。AIエージェント時代の監視は、そこが出発点になる。
【PR】フリーランスエンジニアにおすすめのツール
確定申告や経理作業は弥生シリーズでサクッと終わらせましょう。フリーランスの定番です。
AIエージェントの運用にVPSを使うなら、サポートが手厚いエスツーサーバがおすすめです。
※この記事にはアフィリエイトリンクを含みます
コメント