AutoPodAutoPod

AIエージェントの可観測性と制御:新しい監視スタックの構築

1 分で読めます
音声記事
AIエージェントの可観測性と制御:新しい監視スタックの構築
0:000:00
AIエージェントの可観測性と制御:新しい監視スタックの構築

はじめに

企業が会話型アシスタントからタスク自動化ボットに至るまで、より多くの自律型AIエージェントを導入するにつれて、新たな課題が浮上します。それが可観測性です。これらのエージェントは、複数の意思決定を行い、APIを呼び出し、コンテキストを更新し、さらにはユーザーに代わって行動します。しかし、従来の監視ツールは限定的な視点しか提供しません。実際には、チームはエージェントの多段階の推論を捉えるように設計されていない、散在するログやダッシュボードに頼ることがよくあります。Dynatraceによる最近の調査では、AI駆動型プロジェクトの半数が、組織がエージェントを「ガバナンス、検証、または安全にスケールできない」ため、パイロット段階で頓挫していることが判明しました(www.itpro.com)。同様に、Microsoftのセキュリティ責任者は、「見えないものは保護できない」と警告し、AIエージェントの採用が増加するにつれて「可観測性コントロールプレーン」が必要であると強調しています(www.itpro.com) (www.itpro.com)。この記事では、自律型および半自律型エージェントにおける監視のギャップ(特にツール使用、メモリ、および意思決定パスに関して)を検証します。次に、エンドツーエンドのトレースを捕捉し、ポリシーを適用し、ワークフローをシミュレートし、安全でないアクションをロールバックできる、専門の可観測性・制御プラットフォームを提案します。このアプローチを従来のAPM(アプリケーションパフォーマンスモニタリング)ツールと比較し、エージェント固有のテレメトリーがなぜ重要であるかを説明し、価格/統合モデル(例:PagerDuty/Jira統合によるエージェント分課金)を概説します。

AIエージェントにおける監視のギャップ

AIエージェントは単一のAPI呼び出しではありません。これらは、不確実性のもとで計画を立て、情報を取得し、ツールを呼び出し、出力を合成する多段階ワークフローです(www.stackai.com)。この複雑さにより、従来の監視には盲点が生じます。

  • 断片化されたテレメトリー: ほとんどの環境では、テレメトリーはサイロ化されています。あるシステムはエンドポイントイベントをログに記録し、別のシステムはネットワークトラフィックを示し、さらに別のシステムは認証データを保持しています。TechRadarは、「ほとんどのAIエージェントは、アナリストが長年苦労してきたのと同じ断片化されたテレメトリースタックに依存している」と指摘しています(www.techradar.com)。これらのシグナルを相関させなければ、エージェントは正しく推論するためのコンテキストを欠いています。例えば、AIは、異常なログイン(ログから)と不審なネットワークパターンの両方を認識した場合にのみアカウント侵害を疑うかもしれません。しかし、これらのシグナルが異なるツールに存在する場合、エージェントは「単に十分な情報を知らない」ことになります(www.techradar.com) (www.techradar.com)。要するに、断片化されたデータは可視性のギャップを生み出します。エージェントは不完全な情報に基づいて行動し、検出されない間違ったアクションというサイレント障害につながります。

  • ツール呼び出しの盲点: エージェントはしばしば外部ツールやAPI(例:データベース、ナレッジベース、ウェブサービス)を呼び出します。従来の監視ではHTTPリクエストが発生したことしか記録しないかもしれませんが、エージェントを意識した可観測性どのツールが選択され、その理由は何だったのかをログに記録する必要があります。可観測性プラットフォームは、そのツール選択に至った正確なプロンプトやコンテキスト、渡された引数、そして完全な出力またはエラー応答を捕捉すべきです(www.braintrust.dev)。これがなければ、エージェントは誤ったパラメータを渡したり、ツールの応答を誤解したりする可能性があり、その問題は隠されたままになります。例えば、Braintrustの可観測性ガイドは、エンジニアが「幻覚パラメータ、欠落フィールド、または不正な形式」を発見できるように、各ツール呼び出しを入力と出力でトレースすべきであると強調しています(www.braintrust.dev)。

  • 不透明なメモリ操作: 多くのエージェントは、メモリや検索システム(例:ユーザープロファイル、RAGナレッジストア)を使用します。この動的なコンテキストは、「エージェントが何を読み書きしているか」をログに記録しなければ検出できない障害を引き起こす可能性があります(www.braintrust.dev)。例えば、エージェントが古いメモリ項目や間違ったユーザーのデータを取得した場合、応答はサイレントに悪化する可能性があります。可観測性は、検索クエリ、返されたアイテム、関連性スコア、および鮮度メタデータをログに記録すべきです。これにより、誤った出力を古くなった、またはターゲットを誤ったメモリ読み取りにまで遡ってトレースすることができます(www.braintrust.dev)。同様に、各メモリ書き込み(何が、どのキーの下に保存されたか)も記録すべきです。これにより、複合的なエラーやデータ漏洩(例:あるユーザーの情報が別のユーザーのセッションに表示されるなど)を捕捉できます(www.braintrust.dev)。

  • 見えない意思決定の軌跡: 「コードを入力して答えを得る」という明確なフローを持つウェブリクエストとは異なり、エージェントは通常、計画-実行-観察ループを実行します。計画を生成し、アクション(「ナレッジベースを検索」など)を実行し、結果を観察し、その後再計画するか継続するかを決定します。単純なログでは、この分岐パスを明らかにすることはできません。可観測性には、エージェントの各アクションに対する「理由」とともに、各ステップを順番に捕捉することが必要です。それがなければ、最終的な出力だけを見てすべてが順調だと考えるかもしれませんが、途中でエージェントがタスクから逸脱したり、行き詰まったりしている可能性もあります。例えば、Braintrustは、「計画の逸脱」(エージェントがサイレントに目標を変更する)や「無限ループ」を、ステップレベルのトレースでしか明らかにできない障害モードとして強調しています(www.braintrust.dev)。適切なトレースは、各サブエージェントの呼び出し、分岐決定、およびループ期間をログに記録し、エージェントが間違った質問に答えたのか、進捗なくステップを繰り返したのかを明確にします。

  • サイレントな品質障害: 多くのエージェントの障害は、HTTPエラーやクラッシュを引き起こしません。代わりに、エージェントはデータを幻覚したり、ユーザーの指示に違反したり、ポリシーから逸脱したりする可能性があります。従来のモニター(DatadogやNew Relicなど)は遅延やエラー率しかチェックしません(www.techradar.com)。そのため、応答が事実上誤っていたとしても、システムは「すべてグリーン」と報告します。StackAIは、従来のAPMツールは決定論的なソフトウェアを前提としているが、エージェントはその規則を破ると説明しています(www.stackai.com)。例えば、プロンプトの変更やモデルのアップグレードは、目立ったアラートなしに回答の品質を微妙に低下させる可能性があります(www.stackai.com)。したがって、可観測性はセマンティックチェックを含める必要があります。例えば、幻覚発生率やポリシー違反インシデントの追跡などです。要するに、通常のモニターはエージェントが時間通りに応答したことを示すだけで、応答が正確であったか、関連性があったか、安全であったかを示すことができるのは、エージェント固有のテレメトリーだけです。

  • ガバナンスとセキュリティリスク: AIエージェントは、プロンプトインジェクション、プライバシー漏洩、不正なアクションなど、新たなコンプライアンス上の課題をもたらします。カスタマイズされたテレメトリーがなければ、これらのリスクは見えません。StackAIは、可観測性とガバナンスが収斂すると指摘しています。「検出できないポリシーは強制できない」のです(www.stackai.com)。例えば、顧客サポートモードのエージェントが個人データを漏洩し始めた場合、詳細なトレースログのみが侵害の原因を明らかにすることができます。したがって、当社のプラットフォームはリアルタイムでポリシー違反を監視し(例:出力中のPIIにフラグを立てる、許可されていないAPI呼び出しをブロックする)、コンプライアンスのための監査証跡を提供する必要があります。

要するに、既存のAPMおよびロギングスタックは、AIエージェントがどのように考えているか(思考の連鎖、分岐ロジック、動的なコンテキスト)を単純に捕捉していません。これにより、ツール呼び出し、メモリ使用量、および意思決定の軌跡に盲点が生じます。これらのギャップに対処しなければ、企業はサイレントなエージェント障害、セキュリティ侵害、そして信頼の喪失のリスクを負うことになります。

AIエージェント可観測性・制御プラットフォームの構築

これらのギャップを埋めるため、当社は専用のAIエージェント可観測性・制御プラットフォームを提案します。このサービスは、エージェントをエンドツーエンドで計装し、ガバナンスを強制し、安全な実験を可能にします。主な機能は以下の通りです。

エンドツーエンドのトレースとロギング

すべてのエージェント実行は、完全な実行グラフを記録するトレースを生成すべきです。分散システムの実践に触発され、各エージェントのワークフローはトレースであり、各アクション(LLMプロンプト、ツール呼び出し、メモリクエリ、サブエージェントへの引き渡し)はそのトレース内のスパンです(www.stackai.com) (www.braintrust.dev)。これは、エンジニアが正確なシーケンス、つまりエージェントがどのようなプロンプトを認識し、タスクをどのようにステップに分割し、各ツールが何を返したかを把握できることを意味します。例えば、エージェントが文書ストアを照会した場合、トレースはクエリと取得されたコンテンツをログに記録します。その後、クエリを再定式化すれば、それは新しいスパンとなります。セッション識別子は、複数ターンの会話や長時間のタスクを結びつけます。OpenTelemetryのような標準プロトコルを使用することで、これらのトレースは既存のAPMバックエンドに流し込むことができます。あるガイドが指摘するように、「これらのプリミティブは、既存の可観測性パターンにますますうまくマッピングされる」のです(www.stackai.com)。実際には、これによりエージェントの動作と基盤となるインフラストラクチャを相関させることができます。CPUスパイク、ネットワークI/O、データベース呼び出しをエージェントの推論ステップと並行して表示することが可能です。

プラットフォームは、自由形式の生のテキストをログに記録するのではなく、構造化されたスパンを格納します。例えば、スパンは次のように記録するかもしれません:ツール: emailSender入力: JSONペイロード、出力: 成功またはエラー、遅延: 200ms。スパンをネストする(例:親LLM呼び出しの下にツール呼び出しを置く)ことで、エンジニアはどこで時間が費やされたか、どのステップが障害を引き起こしたかを深く掘り下げて調査できます。重要なのは、すべてのユーザー入力、システム指示、メモリ読み取りがそれぞれトレースデータになることです。この構造化ロギングは、手間のかかる「プリントデバッグ」に代わり、ログの検索やフィルタリング(例:エージェントがfinancialAPIツールを使用したすべての実行を表示)を可能にします。

リアルタイムのポリシー強制

このプラットフォームは、ガバナンスのためのコントロールプレーンとしても機能します。セキュリティおよびビジネスポリシーに照らして、エージェントのテレメトリーを継続的に検査します。例えば、エージェントが不正なワークフロー(本来アクセスすべきではない人事給与へのアクセスなど)を実行しようとした場合、ポリシーエンジンは直ちに介入できます。トレースデータに基づいてルールを定義できます。例えば、「出力にクレジットカードパターンが含まれている場合はアラートを出す」や「顧客サポート時間外の9時~17時以外はデータベースへの書き込みをブロックする」といった具合です。「検出できないポリシーは強制できない」のですから(www.stackai.com)、この可観測性データがポリシーの強制を可能にします。実際には、違反は自動的な封じ込めを引き起こす可能性があります。プラットフォームはエージェントを一時停止させたり、アラートをエスカレートしたり、行った変更を元に戻したりするかもしれません。組み込みの「エージェントキルスイッチ」により、管理者は不正な動作をするエージェントを停止または制限できます(リーダーシップ層が「キルスイッチは何?」と知るべきだというアドバイスを反映しています(www.techradar.com))。例えば、マルウェアスキャナーエージェントが暴走した場合、テレメトリーが異常な動作を検知すると、システムは直ちにその権限を隔離し、オンコールエンジニアに警告を発することができます。

ポリシー強制はプライバシーおよび安全チェックにまで及びます。システムは、すべての送信メッセージに対して自動PII検出器を実行したり、「LLM-as-a-judge」モジュールで幻覚やポリシーの逸脱を嗅ぎ分けたりすることができます。安全違反はすべてインシデントとしてログに記録されます。これらのチェックを可観測性レイヤーに組み込むことで、企業はパフォーマンスメトリクスに加えてライブ安全ダッシュボードを入手できます。

オフラインシミュレーションと「サンドボックス」テスト

重要な変更をデプロイする前に、シナリオをシミュレーションすることは有益です。当社のプラットフォームには、エージェントのワークフローをリプレイまたはモックするためのサンドボックス環境が含まれています。チームは、エージェントに一連のテストケース(一般的なユーザーリクエストやエッジケースを反映)を与え、ドライランでトレースログを収集できます。このオフライン評価は、新しいプロンプトやモデルのアップグレードがポリシーを破ったり品質を低下させたりしないことを保証します(www.braintrust.dev)。例えば、金融エージェントに新しいAPI権限を付与する前に、エンジニアは月末締め処理タスクをシミュレーションして、承認フローに従っていることを確認できます。システムはリグレッションも検出できます。更新されたエージェントバージョンが突然ツールを誤って設定した場合、テストトレースは本番環境にデプロイされる前にその誤りを明らかにします。

実質的に、これはAIのためのカオスエンジニアリングのようなものです。エージェントを意図的に脅威シナリオや誤ったデータに曝露させ、それが脱線するかどうかを確認します。TechRadarは、企業が「サンドボックス評価で準備状況を測定し…意思決定が行われ、回復時間が理解されるようにすべきである」と助言しています(www.techradar.com)。プラットフォームはこれらの訓練をスケジュールに基づいて自動化し、各実行をログに記録できます。これにより、隠れた障害(例:古くなったコンテキストインデックス)を早期に発見するのに役立ちます。評価を開発パイプラインに統合することで、チームはフィードバックループを実現します。本番環境のエラーが新しいテストケースとなり、各リリースはオフラインゲートをクリアしなければなりません。

実行制御とロールバック

予防策を講じても、間違いは起こり得ます。当社のプラットフォームは修復ツールを提供します。まず、リアルタイムの「停止」コマンドは、エージェントのアクションを即座に停止させることができます。長時間実行されるタスクや非同期タスクの場合、ポリシー違反が発生した場合にシステムはキャンセルポイントを呼び出すことができます(例えば、エージェントが承認なしに資金を引き出そうとした場合にトランザクションを中止するなど)。次に、すべてのアクションがトレースされるため、プラットフォームは効果をリプレイまたは元に戻すことができます。例えば、エージェントが誤って顧客にメールを送信したり、CRMを更新したりした場合、オペレーターはログを使用して変更前の状態を再構築できます。不変の監査ログと組み合わせることで、エージェントが行ったデータベーストランザクションやファイルシステム変更のロールバックが可能になります。TechRadarは、この必要性を強調しています。「組織は…AIを実装するたびにロールバックパスを再評価しなければならない」(www.techradar.com)。実際には、プラットフォームは実行前に状態をスナップショットしたり、バージョン管理されたデータストアと統合したりして、失敗したエージェントのアクションを欠陥のあるソフトウェア展開のように元に戻せるようにします。

インシデント対応とチケッティングとの統合

可観測性は戦いの半分に過ぎません。エンジニアは効果的にアラートを受け取る必要があります。プラットフォームは、最新のインシデント管理およびコラボレーションツールと統合されます。例えば、重大なポリシー違反が発生した場合、重要なエージェントアラートをPagerDutyにプッシュし、オンコールインシデントを作成できます。SlackMicrosoft Teamsチャンネルに要約を投稿することもできます(PagerDutyは、彼らのシステムにはレスポンダーが集中できるように「高度なSlackおよびMicrosoft Teams統合」があると述べています(www.pagerduty.com))。チケッティングシステムとの統合も不可欠です。アラートがトリガーされると、プラットフォームはトレースID、影響を受けた会話、ポリシーの詳細が事前に入力されたJiraまたはServiceNowチケットを自動的に作成できます。これにより、エージェントのインシデントが他の障害と同じトリアージワークフローに入ることを保証します。PagerDutyはまた、可観測性と対応を連携させるための700以上のツール統合(Datadog、Grafanaなど)を強調しています(www.pagerduty.com)。同様に、当社のプラットフォームはログ(例:Splunk)、メトリクス(Prometheus)、およびCI/CDシステムへのコネクタを提供し、すべてのテレメトリーが既存のダッシュボードやチャートに適合するようにします。

従来のAPMとエージェントテレメトリーの比較

これは、従来の**アプリケーションパフォーマンスモニタリング(APM)**ソリューションと比較してどうでしょうか?一言で言えば、従来のAPM(Datadog、New Relic、Dynatraceなど)はインフラストラクチャおよびコードレベルのメトリクスに優れていますが、エージェントをブラックボックスとして扱います。例えば、Datadogは「スタック全体のログを自動的に取り込み、解析し、分析」でき、そのAPMモジュールは「分散システム全体の要求をトレース」します(www.techradar.com)。同様に、そのネットワーク監視機能は、サーバー、CPU、メモリ、およびネットワークフローの鳥瞰図を提供します(www.techradar.com)。これらのツールは、エージェントがCPUを過剰に消費したり、例外をスローしたりした場合にアラートを発します。しかし、これらはいずれもエージェントが何を考えているかを捉えるものではありません。実際のプロンプトテキスト(プライバシー規則のため)やLLM呼び出しのシーケンスはログに記録されません。生成された回答が不正確なメモリに基づいているか、またはビジネスルールに違反しているかを知ることはありません。彼らの視点からは、API呼び出しが200 OKを返せばいつでも「すべてがグリーンに見える」のです(www.stackai.com)。

実際には、エージェントのためにAPMをハックしようとすることも可能です(例えば、各チャットリクエストにタグを付け、ログを検索するなど)。しかし、エージェント固有のスパンがなければ、ギャップは残ります。APMは決定論的なワークフローを前提としています。障害発生時にはコードパスをデバッグします。しかし、AIエージェントの場合、障害は例外をスローするのではなく、サイレント(誤った回答)またはセマンティック(ポリシー違反)です。StackAIは、エージェントが「多くの[APM]の仮定に違反する」と指摘しています。例えば、エージェントが単純に幻覚を起こした場合、エラーコードは存在しません(www.stackai.com)。さらに、多段階のエージェントチェーンは多くのコンポーネント(モデル、インデックス、ツール)にまたがります。最終的なウェブリクエストだけを監視した場合、エージェントがどのようにそこに到達したかというすべてのコンテキストを失います。最後に、APMツールは一般的にAI固有のコスト(トークン使用量など)や品質シグナルには盲目です。

これらの理由から、エージェントシステムを構築する企業は、専用のテレメトリーの必要性をますます認識しています。Dynatraceが報告したように、「可観測性は…エージェント型AI戦略の成功に不可欠な要素です。チームは、AIエージェントがどのように振る舞い、相互作用し、意思決定を行うかについてリアルタイムの可視性を必要としています」(www.itpro.com)。提案されたプラットフォームは、まさにAPMツールでは提供できない、エージェントの認知ステップに至るまでの高レベルなヘルス指標から詳細なレイヤードビューを提供します。それは本質的に、APMのゴールデンシグナル(遅延、エラー、スループット)を、エージェント固有の品質メトリクス(根拠の有無、完了率、幻覚発生率)で拡張するものです(www.stackai.com) (www.stackai.com)。

料金モデル

シンプルな料金モデルは従量制です。一つのアプローチは、エージェント分(エージェントがタスクを積極的に計算している時間)ごとに課金することです。例えば、このサービスはクラウド関数の課金と同様に、およそエージェント分あたり0.05ドル〜0.10ドルで価格設定される可能性があります。これにより、トレース/スパンデータの捕捉と保存、評価チェックの実行、およびログの保存にかかる費用がカバーされます。(プラットフォームアクセスに対する基本月額料金と超過料金が設定される可能性があります。)追加のデータ保持やログ容量はGBあたりで課金されるかもしれません。大量割引やエンタープライズプランでは、大規模なデプロイメントに対して分あたりの料金を低く提供できます。これにより、コストが消費量と一致します。断続的に活動するボットは、稼働するまで最小限の料金しか発生しません。参考までに、多くの監視およびサーバーレス製品はきめ細かい従量課金制を採用しています。当社の「エージェント分」メトリクスも同様です。ユーザーはエージェントの実行時間1時間あたりに何を支払うかを正確に知り、効率的な利用を促進します。

結論

自律型AIエージェントは大きな生産性向上を約束しますが、それは彼らの行動を可視化し、制御できる場合に限られます。AI可観測性の新興分野は、まさにこの課題に取り組んでいます。つまり、エージェントの「思考プロセス」を透明化し、管理可能にすることです。ツール呼び出し、メモリアクセス、および意思決定ステップをトレースとして計装することで、不透明な障害やガバナンスのギャップを洞察できます。目的別に構築された監視プラットフォーム(ポリシー強制、シミュレーション、ロールバック、IR統合を含む)は、エージェントが本番環境で安全に動作することを保証します。従来のAPMツールとは対照的に、エージェント固有のテレメトリーは、AIシステム自体を、単なるサーバーとしてではなく、第一級の存在として扱います。

調査や専門家が警告するように、可観測性の欠如はエージェント型AIのスケーリングを妨げる決定的な要因です(www.itpro.com) (www.itpro.com)。ここで述べた新しい監視スタックを構築することで、組織は「期待混じりの当て推量」を信頼できる自動化に変えることができます(www.techradar.com)。最終的に、このようなアプローチは、エージェントが意図したとおりに振る舞うという信頼を築き、自信を持って革新することを可能にします。何か問題が発生した場合、それはもはや謎の侵害や幻覚ではなくなります。トレースログとコントロールプレーンが障害モードを特定し、迅速な緩和と学習を可能にします。自律型エージェントの時代において、可観測性は選択肢ではなく、安全でスケーラブルなAIのまさに基盤なのです。

このコンテンツが気に入りましたか?

最新のコンテンツマーケティングのインサイトと成長ガイドを受け取るには、ニュースレターを購読してください。

この記事は情報提供のみを目的としています。コンテンツや戦略は、特定のニーズによって異なる場合があります。
AIエージェントの可観測性と制御:新しい監視スタックの構築 | AutoPod