ジェフ・シャンパーニュ、CriblのField CTO – インタビュー・シリーズ

ジェフ・シャンパーニュ、CriblのField CTOは、観測可能性、エンタープライズ・データ、製品戦略、技術アーキテクチャの分野で深い経験を持っています。Criblに入社する前は、Databricksの製品管理ディレクターを務め、Splunkでは7年以上にわたってシニア・フィールド・プロダクト、建築、グローバル・システムズ・エンジニアリングの役割を果たしました。また、BNY ConvergExでのシステム・アーキテクチャのリーダーシップ、Premier Technology Solutionsでのシニア・エンジニアリング、Assist-2-Sellでの初期エンジニアリング・リーダーシップも経験しています。これらの経験から、エンタープライズが運用データを収集、管理、分析、活用する方法について幅広い視点を持ちます。

Criblは、エンタープライズ・テレメトリ・カンパニーであり、IT、セキュリティ、SRE、DevOpsチームが観測可能性とセキュリティ・データを単一のベンダーにロックインされることなく収集、処理、ルーティング、保存、分析できるように支援しています。同社は「テレメトリのためのAIプラットフォーム」として位置付けられており、Cribl Stream、Cribl Edge、Cribl Search、Cribl Lakeなどの製品を提供しています。同社の使命は、テレメトリの量が増加し、AIドリブンの運用が要求されるにつれて、エンタープライズがより多くのコントロール、柔軟性、効率性を得られるようにすることです。

スプランク、ダタブリックス、そして現在クリブルで働いてきた経験から、エンタープライズ・データ、観測可能性、インフラストラクチャーについての貴重な洞察を得ています。エージェント・ベースのAIが生み出す観測可能性の課題について、どのような点が本当に異なるのでしょうか。

アプリケーションの観測可能性では、複雑な分岐実行パス、ミクロサービスを介したリクエストの追跡、分散システム全体でのログの相関について扱ってきました。セキュリティ・オペレーションでは、高容量の異なるデータ・ソースを扱い、システム全体で脅威を検出してきましたが、これらのシステムは予測可能な動作を示します。エージェント・ベースのAIは、これらの問題を再定義しません。むしろ、それらを同時に爆発的に増大させます。

エージェントは、事前に決定されたものではなく、実行時に決定される方法で、決定を連鎖させ、外部ツールを呼び出し、サブ・エージェントを動的に生成します。実行グラフは複雑なだけでなく、毎回大きく異なる可能性があり、エージェントの動作を再構築するために必要なテレメトリの量は、各ホップで指数関数的に増加します。エンタープライズは、テレメトリの収集と操作が容易で、かつコスト効率が良い方法で行われる必要があります。そうでない場合、エンタープライズは可視性を制限してコストを抑えるという同じトレードオフを行うことになりますが、これは、盲目になる最悪のタイミングです。

エンタープライズがワークフローにエージェントを埋め込むとき、エージェントが行うことと実際に起こることの間に、最も大きな可視性のギャップはどこにありますか。

エージェントは、表面上では成功したように見えるワークフローを完了しますが、同時に、悪いツールの呼び出し、パラメーターの妄想、または元の目標からの逸脱を行います。結果は、後続のシステムで何時間も後に表面化します。

断絶は通常、解釈の段階で始まります。元の指令のわずかな曖昧さは、エージェントがメモリから取得するもの、利用可能なツール、または前のステップのコンテキストによって異なり、異なった方法で解決されます。また、エージェントが依存する下流システムをインストルメントする必要があります。なぜなら、エージェントは正しく形成されたデータベースの呼び出しを行うことができますが、下流のテーブルがサイレントに失敗したETLジョブのために更新されなかった場合、間違った答えを返す可能性があるからです。

エージェントは指示されたことを正確に実行しましたが、信頼されたデータは古くなっていました。

従来の観測可能性ツールは、エージェント・ベースのAIシステムの監視にしばしば不十分なのはなぜですか。

第一に、従来のツールは、柔軟性に欠け、独自のスキーマと予測可能なデータの形状を前提として構築されています。エージェントのトレースは、これらの期待に沿わないものです。大量で、構造が非常に可変であり、OpenTelemetryのGenAIセマンティック・コンベンションなどのオープン・スタンダードがこれに対処するために登場していますが、多くのレガシー・プラットフォームはこれらのスタンダードを活用するように構築されていません。

第二に、スケールとコストの計算が崩壊します。単一のエージェントが生産性の高いワークロードを処理するだけで、1時間で従来のアプリケーション・スタックが1日で生成するよりも多くのテレメトリを生成する可能性がありますが、多くの従来のプラットフォームはインジェストと保存されたボリュームに基づいて課金します。その結果、不可能なトレードオフが生じます。すべてをインストルメント化してコストが暴走するか、可視性を制限して最も必要なシステムの可視性を失うかのいずれかです。

エージェントが失敗したとき、組織は、根本的な原因がモデル、リトリーバ・レイヤー、APIの依存関係、権限の問題、または下流のインフラストラクチャーの問題であるかどうかをどのように判断できますか。

根本的な原因を特定するには、すべてのレイヤーを一貫してテレメトリを取得する必要があります。モデル・スパンの待機時間とエラー・シグナルは、LLM自体の問題を示します。リトリーバ・スパンの問題は、コンテキストが関連性のあるものであったか、古くなっていたかを示します。ツール・コール・スパンの問題は、失敗したAPIの依存関係や権限の問題を暴露します。

上記のように、エージェントが依存する下流システムからのテレメトリも必要です。なぜなら、エージェントは正しく形成された呼び出しを行うことができますが、信頼されたデータが更新されていなかった場合、間違った答えを返す可能性があるからです。単一のシグナルは全体の物語を語ることはできません。すべてのレイヤーを相関させることが、エージェントの障害を迅速にデバッグできるチームと、それでも推測しているチームを区別する鍵です。

エンタープライズがエージェントの動作を理解しようとするとき、どのような種類のテレメトリ・データが最も重要になりますか。

基盤は依然としてMELT（メトリクス、イベント、ログ、トレース）ですが、エージェント・システムに移行すると、トレースの重要性が大幅に増します。メトリクスは何かが間違っていることを示し、ログは何が起こったかを示しますが、どちらもエージェントが間違った答えに到達するまでの推論の連鎖を再構築することはできません。そのためにはトレースが必要です。

従来の分散システムでは、トレースはリクエストがサービスを通過する方法を示します。エージェント・システムでは、トレースはモデルが問題を推論する方法、呼び出されたツール、取得されたコンテキスト、分岐点、各ステップでの決定を示します。トレースがなければ、そこに到達する方法を説明する方法はありません。

他のMELTシグナルは消えません。トークン使用量と待機時間のメトリクスはコストとパフォーマンスのために重要であり、下流システムからのログは依然として不可欠です。しかし、トレースはエージェントの動作を大規模に理解する上で最も重要なシグナルです。

多くのAIの議論はまだ幻覚について強く焦点を当てています。運用上の障害、たとえば悪いリトリーバ、壊れた統合、待機時間のスパイク、またはコンテキストの欠如について、エンタープライズは過小評価していますか。

実稼働環境での多くの幻覚は、モデル・ファイルではなく、運用上の障害に仮装されています。悪いリトリーバは古くなったまたは不完全なコンテキストを返し、モデルはそのギャップを妥当なもので埋めます。壊れた統合は、エージェントが正しく推論するために必要なデータを最初から取得しなかったことを意味します。ETLジョブの失敗によるコンテキストの欠如は幻覚のように見えますが、実際にはインフラストラクチャーの問題です。

チームがその違いを見分けられない場合、制御可能なもの、つまりモデル自体にフォーカスします。システム・プロンプトを繰り返し、ガードレールを追加し、評価フレームワークを洗練しますが、これらのテクニックには実際の価値があります。私の経験では、最も高レバレージの投資はほとんど常にリトリーバ・レイヤーでのデータの品質と新鮮さです。新鮮なデータで根拠のあるエージェントは、古くなったコンテキストで推論する過度にプロンプト・エンジニアリングされたエージェントよりも常に優れています。

エージェントがより自律的になるにつれて、エンタープライズ・チームは、過度のノイズに圧倒されることなく、説明責任を維持するために何をログ、トレース、または監視する必要がありますか。

基盤は依然としてMELTですが、エージェント・システムの説明責任には、従来のテレメトリの上に評価フレームワークを重ねる必要があります。メトリクス、イベント、ログはインフラストラクチャーの障害や壊れた統合を浮き彫りにし、エージェントの動作を汚染する可能性があります。トレースは、エージェントが特定の答えに到達するまでの推論の連鎖を示します。しかし、どちらも答えが実際に正しかったかどうかを示すことはできません。そのギャップを埋めるのがLLM-as-judge評価です。エージェントを動かすAIの能力は、エージェントを評価するために使用できます。アウトプットを精度、根拠のある性、タスクの完了度の観点からスコア付けします。これは、人間のレビュー・プロセスが匹敵することのできないスケールです。

事前生産では、品質ゲートとして機能し、ユーザーに到達する前に後退を捕捉します。生産では、継続的なモニターとして機能し、ライブ・トラフィックをサンプリングし、許容可能なしきい値を外れた応答をフラグ付けします。ノイズを避けるための鍵は、すべてのエージェント・ワークフローが同じリスクを伴わないことを認識することです。つまり、統一的な監視から、業界が始めて呼び始めるヒューマン・オン・ザ・ループ・ガバナンスへの移行です。行動の基準と信頼性のしきい値を事前に定義し、エージェントを運用させ、人間の介入は例外的な場合にのみ予約します。

テレメトリ・パイプラインは、セキュリティ、SRE、データ、AIチームがエージェントの動作について共有されたビューで作業するのを助けるためにどのような役割を果たす可能性がありますか。

セキュリティ・チーム、SRE、データ・エンジニア、AIチームはすべて、異なるツールを通じて同じ問題の異なるスライスを見ていますが、誰もが全体の絵を見ているわけではありません。テレメトリ・パイプラインが現代のエンタープライズ・データ・アーキテクチャの標準的な部分になった理由は、正にこの問題を解決するためです。すべてのツールの上流にある単一の、適切に管理されたパイプラインは、すべてのチームが、カスタム・エージェントやコレクターを各チームに展開することなく、正規化された、豊富なデータで作業できることを保証します。

この柔軟性は2つのレベルで重要です。第一に、データ・ティアリングです。適切に設計されたテレメトリ・パイプラインは、データを適切なストレージと分析戦略にマッチングできるため、データを長期のコンプライアンス・リテンションのためにのみ必要とする場合に、分析用の価格を支払わないで済みます。第二に、AIツールのランドスケープが急速に進化し続けるため、オプション性が重要です。エンタープライズが観測可能性の戦略を単一のベンダーのエコシステムの周りに構築すると、より優れたツールが登場するたびに、高価な移行プロジェクトに直面することになります。

エージェント・ベースのAIの展開に既存の監視慣行をリトロフィットしようとするとき、エンタープライズはどのような間違いを犯していますか。

最も一般的な間違いは、コストの影響を考慮せずに、既存のプレミアム観測可能性プラットフォームを使用してエージェントのトレースを収集することです。エージェントのトレースは、従来のアプリケーション・テレメトリとは異なり、大量で可変でボリュームが大きいため、多くのプレミアム・プラットフォームはインジェストとストレージに基づいて課金します。その請求額は、チームが何が起こっているのかを理解する前に深刻な問題になる可能性があります。典型的な対応は、収集するものを減らすことです。その結果は、最悪の両世界です。コストが高く、可視性が不完全です。

第二の間違いは、監視が何を解決するべきかについて、間違ったメンタル・モデルを適用することです。従来のインフラストラクチャーの監視は「システムは稼働していますか?」と問いかけ、ダウンしている場合にアラートを上げます。その質問は必要ですが、エージェント・システムでは不十分です。エージェント・システムでは、インフラストラクチャーは完全に正常な状態で稼働しているかもしれませんが、エージェントは静かに悪い決定を下したり、古くなったデータを取得したり、元の目標から逸脱したりしている可能性があります。チームが既存のダッシュボードとアラートのしきい値をエージェントのワークフローにリトロフィットする場合、実際にはカバレッジがあると思っている場合でも、実際にはパイプだけを見ていることになります。

第三の間違いは、インストルメントを後回しにすることです。エージェントを迅速にパイロットし、観測可能性について考えることなく生産に移行するエンタープライズは、高価な修復サイクルに陥り、データの収集アーキテクチャを最初の重大な生産障害後に再構築することになります。エージェントの展開を最も成功裏に拡大するチームは、早期にインストルメント化し、トラフィックが低く、動作が予測可能な間に基準を確立し、必要になる前に評価フレームワークを構築します。

将来、インフラストラクチャーの可視性は、クラウドの観測可能性が大規模なクラウド・マイグレーションに不可欠になったのと同様に、エンタープライズのAIの採用の前提条件となるでしょうか。

クラウドとの類似性は非常に類似しています。最も重要なことは、顧客にクラウドへの移行について話すときに伝えることです。彼らはシフトアップやリフトアップをしていないのです。新しいアーキテクチャを展開し、新しい機能を実現しています。すべてがインストルメント化され、監視される必要があります。以前のツールではそうではなかったのです。クラウドにインフラストラクチャーを移行したが、インストルメント化と監視のステップをスキップしたエンタープライズは、診断できないカスケード・フェイルを経験し、説明できないコストのスパイク、防止できないダウンタイムに直面しました。観測可能性は、クラウドのスケール化を可能にする信頼の基盤となりました。同様のパターンが、より速く、より高いステークで、エージェント・ベースのAIで繰り広げられていました。

エージェントがこのような監視を必要とする主な理由は、設計上非決定論的であり、動作がランタイムにエマージェントし、ツールの統合ごとに有効な機能が増大することです。静的な事前展開認証では、統合ごとにアクション・サーフェスが変化するシステムをカバーすることはできません。エージェントは、信頼の境界内で動作します。信頼の境界は、観測可能性、ポリシー、評価インフラストラクチャーが成熟するにつれて拡大します。境界自体は決して消えません。それが失敗状態であるということではありません。それは、世界中のすべての重大な自律システムがすでに動作している方法です。

素晴らしいインタビュー、詳しく知りたい読者はCriblを訪問してください。