従来のWebアプリケーションのモニタリング思想は「サービスがオンラインか・APIが200を返すか」です。AIエージェントにこのアプローチを適用すると、ほぼ役に立ちません——Agentサービスは正常にオンラインで200を返しながら、完全に間違ったことをしている可能性があります：汚染されたデータに基づいて意思決定する・同じ失敗した操作を繰り返し実行する・または毎日1%ずつ静かに資金を消費する。
AIエージェントのモニタリングは根本的に再設計する必要があります：「システムが健全か」だけでなく「Agentが正しいことをしているか」を監視します。この記事は、Agentのユニークな失敗モードに対して設計された完全な4層モニタリングフレームワークを提供します。
従来のアプリケーションの失敗モードは列挙可能です：サービスクラッシュ（P0）・APIタイムアウト（P1）・データベース接続失敗（P1）。これらの失敗には明確なシグナルがあります——システムがクラッシュし、モニタリングが警告し、エンジニアが修正します。
AIエージェントの失敗モードは曖昧です：
静かな誤った意思決定：エージェントは技術的に成功した操作を実行しました（トランザクションがオンチェーン、ハッシュが確認済み）が、それは間違った戦略的決定でした。システムモニタリングの観点からは、すべて正常；ビジネスの観点からは、お金が失われています。
段階的なパフォーマンス低下：エージェントの戦略効果が3ヶ月でAPY 4%から1.2%に低下しますが、突然のクラッシュはなく、ただゆっくりと悪化するだけです。従来のモニタリングはこのトレンドベースの低下を検出できません。
コンテキスト汚染の累積効果：Prompt Injectionで汚染されたサブAgentが特定の操作に向けた偏見を1回の出力に埋め込み、その偏見が次の20回の推論サイクルで徐々に増幅され、21回目に異常な操作をトリガーします。
ツール呼び出しの静かな低下：依存しているDeFiプロトコルAPIが時々古いデータを返し始めます（データは更新されていないがHTTP 200が返る）；エージェントは古いレートデータに基づいてリバランス決定を行います。
各層のモニタリング目標・コアメトリクス・アラート閾値：
層1：インフラストラクチャ監視
目標：Agentサービス自体が実行中であることを確認。コアメトリクス：サービスアップタイム・APIリクエストレイテンシ（P50/P95/P99）・LLM API応答時間・データベース接続状態・メモリ/CPU使用率。アラート閾値：サービスダウンタイム>60秒→P0；LLM API P95レイテンシ>60秒→P1；データベース接続失敗→P0。
層2：ツール呼び出し監視
目標：Agentのツール使用行動が期待通りであることを確認。コアメトリクス：ツールごとの呼び出し頻度；ツール呼び出しフォーマットエラー率；ツール返却データの鮮度；ツールリトライ回数；ホワイトリスト違反のツール呼び出し試行。アラート閾値：ツールフォーマットエラー率>5%（30分ウィンドウ）→P1；ホワイトリスト違反ツール呼び出し試行>0→即座にP0。
層3：ビジネスロジック監視
目標：AgentのアクションとOperationがビジネスの期待に合致することを確認。コアメトリクス：日次/週次の戦略P&L（期待ベースラインとの比較）；操作ごとの実際vs期待実行コスト；操作頻度の異常；金額分布の異常；ホワイトリストアドレスのコンプライアンス率。アラート閾値：日次支出がハード上限を超過→P0即座に停止；ホワイトリストコンプライアンス<100%→P0。
層4：LLM推論監視
目標：Agentの意思決定プロセスを理解し、推論品質の低下やコンテキスト汚染を早期検出。コアメトリクス：推論ごとのThought Chainの完全性；意思決定の一貫性；推論パスの異常パターン；トークン使用量の突然の変化。実装の課題：この層は各推論の完全なThought Chainの記録と保存が必要で、コストが高くなります。推奨：LangSmithまたはWeave（Weights & Biases）を使用。
アラート設計で最も一般的なミスは「すべての異常をP1に設定する」ことです——その結果、アラート疲労が生じ、本当の問題がノイズの中に埋もれ、エンジニアがアラートを無視し始めます。
P0（即座に起こす、10分以内に対応）：ホワイトリスト外アドレスへの転送試行；日次支出がハード上限を超過；Agentサービスが5分以上完全に利用不能；データベース接続失敗；人間の確認なしに「資金転送」操作が正常に実行された。
P1（業務時間内に30分以内で対応）：ツールフォーマットエラー率>5%；LLM API P95レイテンシが異常に高い；データ鮮度が閾値を超過；戦略P&Lがベースラインを3日連続で下回る。
P2（24時間以内に確認）：ツール呼び出しリトライ回数の増加；トークン使用量のトレンド上昇；推論時間のトレンド増加。
P0アラートはPagerDutyまたはTelegramボット経由で直接起こします。P1はSlackまたはTelegramグループ通知経由。P2は毎朝のdaily digestで集約。
AIエージェントのObservabilityニーズに対する推奨ツールの組み合わせ：
インフラストラクチャ層：Railwayの組み込みモニタリング（Railwayでデプロイしている場合）はCPU/Memory/Uptimeをカバー；高度なニーズにはPrometheus + Grafana。限られた予算にはUptime Robot（無料）でUptimeモニタリング。
ツール呼び出し+ビジネスロジック層：自作ログテーブル（PostgreSQLのagent_operation_logsテーブル）+ Metabase（無料BIツール、PostgreSQL上でダッシュボードを構築可能）。各ツール呼び出しとビジネス操作に構造化ログを記録：timestamp・operation_type・tool_name・parameters・result・cost_usd・target_address。
LLM推論層：LangSmith（$39/月から）はLLM推論プロセスを記録するための最も成熟したツールです。オープンソースの代替：Phoenix（Arize AIのオープンソースLLM Observabilityツール）。
アラート送信：PagerDuty（P0）+ Slack Webhook（P1）+自作Telegramボット（P0/P1の両方をサポート、個人開発者に優しい、無料）。
「Agentは動き続けている、エラーは報告されていない、問題ないはず」は本番運用で最も危険なマインドセットです。AIエージェントの最も恐ろしい失敗モードはクラッシュではなく、静かに間違ったことをすることです——ビジネスの観点では毎日損失を出しているのに、技術的なモニタリングの観点ではすべてが正常に見えます。
最小限の実行可能なモニタリングセットアップ（個人開発者向け、2日以内に完了可能）：PostgreSQLにagent_operation_logsテーブルを作成して各ツール呼び出しとビジネス操作を記録する；毎日Pythonスクリプトを実行して今日のP&Lと支出が閾値を超えているかを計算し、超えた場合はTelegramに通知を送る；Uptime Robotを設定してAgentサービスのオンライン状態を監視する；ホワイトリストアドレスの検証ロジックをツール関数のPythonコードに入れる（System Promptではない）。
$10,000以上を運用するAgentには、LangSmithの推論トレースへの投資をさらに推奨します——これは推論の低下とPrompt Injectionの初期シグナルを検出する唯一の信頼できる手段です。