Observe by Snowflake：オブザーバビリティとAIデータクラウドの融合
3か月前にObserveがSnowflakeに加わって以来、私たちはペースを上げ、新規ユーザーのオンボーディングを進めるとともに、オブザーバビリティへのアクセスを拡張する新機能の構築を進めてきました。しかし、Observeが解決しようとした根本的な課題は変わっていません。私たちのミッションは引き続き、大規模なオブザーバビリティの実現です。これは今日、多くの企業が直面している課題です。
大規模なオブザーバビリティがデータの問題である理由
モダンシステムによって生成されるログ、メトリクス、トレースといったテレメトリの量は、従来のアプローチの処理能力を上回っており、主要な企業では毎日数百テラバイトのデータを取り込んでいます。AI生成コードの普及とAIエージェントの増加に伴い、テレメトリの規模と複雑さは増す一方です。この問題を放置すれば、オブザーバビリティのコストは維持できなくなり、トラブルシューティングの時間は増大します。
レガシーシステムの問題はアーキテクチャにあります。問題は多岐にわたります。
- オーバーヘッドの高いインデックスベースのシステム
- 密接に結合されたストレージとコンピュート
- プレミアムストレージへの依存
- 独自のフォーマットでサイロ化されたデータ
大規模なオブザーバビリティはデータの問題であるため、オブザーバビリティソリューションがデータプラットフォームと密接に統合されることが、アーキテクチャ上最も理にかなっています。Observeでは、Snowflake上にモダンなオブザーバビリティアーキテクチャを構築することを早い段階で決定しました。Snowflakeの豊富な機能を活用することで、従来のアーキテクチャのコストやパフォーマンスの制約に縛られないオブザーバビリティを提供します。
Observe by Snowflakeとは
Observeは、AIを活用したオブザーバビリティプラットフォームであり、当初から大規模に動作するように設計されています。AI SRE、Observability Context Graph、Telemetry Lakehouse Foundationで構成されるモダンなオブザーバビリティアーキテクチャにより、レガシーシステムの欠点を解決するように設計されています。その結果、より低コストで迅速なトラブルシューティングが可能になります。
プログラマブルなAI SRE
Observeは、ビルトインのAI SREを通じて、またMCPやCLI（近日提供予定）を介して、AI主導のオブザーバビリティを提供します。SRE、開発者、サポートエンジニア、自動化されたエージェントは、それぞれのワークフローに最適なインターフェイスを通じてテレメトリにアクセスし、操作できます。このプログラムによるアクセスにより、組織はオブザーバビリティデータ上にエージェント主導のカスタムワークフローを構築できます。
精度を高めるために設計されたコンテキスト
Observability Context Graphは、環境全体のセマンティクスと関係性をモデル化します。サービスやインフラストラクチャ全体でログ、メトリクス、トレースを接続し、ビジネスやコードのコンテキストを含めるように拡張します。その結果、オブザーバビリティのために構造化およびキュレーションされたコンテキストを使用して、より迅速かつ正確な推論が可能になります。
コスト効率の高いスケール実現
Telemetry Lakehouse Foundationは、Observeのアーキテクチャの基盤です。低コストのクラウドストレージと、コンピュートとストレージの分離を提供します。Snowflakeのコア特性を継承することで、Observeがペタバイト規模のテレメトリをより低コストで取り込み、保存、分析できるようにします。
AI SREエージェントが効率的に機能するために必要なオブザーバビリティコンテキスト
AIを活用した効果的なオブザーバビリティには、コンテキストが不可欠です。チームが運用ワークフローにエージェントを組み込み始めると、エージェントにコンテキストが不足している場合、課題に直面することになります。クエリがタイムアウトしたり、応答の信頼性が低かったり、トークンの消費量が予想以上に多くなったりする可能性があります。
適切なオブザーバビリティコンテキストにアクセスできれば、エージェントははるかに効率的になります。エージェントは曖昧な用語の意味を特定し、複雑な関係性をたどり、検索スペースを絞り込むことができます。これにより、大幅に低いコストでより正確な結果を返すことが可能になります。これが、エージェント主導のワークフローを実際に可能にする要素です。Observeにおいて、Observability Context Graphは、クエリの精度、速度、コスト効率を促進するアーキテクチャ上の根本的な違いです。
実際の動作例
コンテキストを備えたAI SREエージェントは、トラブルシューティングのプロセスをどのようにスピードアップするのでしょうか。サービスがエラーを返し始め、影響範囲が不明なインシデント調査を考えてみましょう。
一般的なワークフローでは、エンジニアは次のような作業を行います。
- 1つのツールからIDを抽出する
- 別のツールでクエリを実行する
- データをエクスポートして相関付ける
- 複数のシステムにわたって繰り返す
時間の大部分は、単にどこを見るべきかを把握するためだけに費やされます。
コンテキストを認識するエージェントを使用して同じ調査を実行する場合、エージェントがアラートを受信した後の流れは次のようになります。
- エージェントがコンテキストグラフにクエリを実行する
- エージェントが影響を受けるサービスを特定する
- エージェントが依存関係をたどる
- エージェントが変更イベントを切り分ける
- エージェントが関連するログとトレースを抽出する
エージェントが返すのは、生シグナルのリストではなく、何が壊れたのか、そしてそれをどう修正するのかに関する、範囲が絞られた調査結果のセットです。
Snowflakeの一部としてのオブザーバビリティの成長
Snowflakeに加わって以来、オブザーバビリティに関与する人々に変化が見られます。データリーダーたちは積極的に関与しており、テレメトリを主要なデータアセットとして扱うことへの関心が高まっています。テレメトリをエンジニアリングツール内に孤立させるのではなく、企業の他のデータとともに保存、ガバナンス、分析することに強い関心が寄せられています。
同時に、AI SRE、DevOps、およびソフトウェアエンジニアリングのワークフローに対する関心も加速しています。オブザーバビリティが運用においてより積極的な役割を果たすようになるにつれて、これが既存のお客様内での利用拡大を促進しています。また、先進的なチームが従来のオブザーバビリティインターフェイスを介さずに、Observeに保存されたデータとコンテキストの上に直接、ObserveのMCPサーバー上で独自のオブザーバビリティエージェントを構築するケースも見られます。
新規のお客様のオンボーディングと利用拡大の両方におけるこの勢いの大部分は、導入時の負担が軽減されたことによるものです。Snowflakeのお客様は、既存のSnowflakeクレジットを制限なくObserveの利用に充てることができるようになり、より広範なSnowflakeデータプラットフォームの一部としてオブザーバビリティを導入することがはるかに容易になりました。
オープンなデータと柔軟なアクセス
私たちは、エージェントネイティブなアクセスと、オープンフォーマットを使用したデータ相互運用性という2つの方向でプラットフォームを拡張しています。両者を通じた私たちの目標は、テレメトリデータと、その上に構築されたコンテキストに、ユーザーが好む環境から、それぞれの働き方に合ったアクセスパスを通じてアクセスできるようにすることです。
Observe CLI：オブザーバビリティコンテキストへのプログラムによるアクセス
開発者は、IDE、ターミナル、およびコーディングエージェントとともに作業することが増えています。オブザーバビリティは、そのフローの中に存在する必要があります。
私たちは、エージェント主導のワークフロー向けに設計されたCLI（近日提供予定）を導入します。これにより、開発者がテレメトリを操作するための新たな手段が提供され、おそらくそれが最も自然な選択肢となるでしょう。コンテキストの認識はエージェントの効率にとって不可欠です。そして重要なことに、Observeは、CLIを通じてタスクを実行するエージェントがContext Graphにクエリを実行できるようにします。
Observe CLIにより、ユーザーとエージェントの両方が、増え続ける再利用可能なスキル（インシデントの調査、障害のトレース、変更の検証などの一般的なタスク向けの構造化されたワークフロー）を通じて、オブザーバビリティデータとコンテキストを操作できるようになります。これらのワークフローの一部はバックグラウンドで自律的に実行でき、その他はインタラクティブに呼び出されます。この仕組みは、ルーチンタスクを処理するエージェントと、Claude Codeのような環境からより複雑な調査を直接実行およびガイドするエンジニアの両方をサポートします。CLIはこのシステムのコントロールサーフェスとして、Observeの機能へのきめ細かいプログラムによるアクセスを提供し、オブザーバビリティを長期的に構成、自動化、拡張できるようにします。
Apache Iceberg：すべてのテレメトリへのオープンなアクセス
また、Apache Icebergの読み取りおよび書き込みサポートの進捗状況も紹介しています。オブザーバビリティデータは、独自のデータレイク内のIcebergテーブルに直接書き込み、オブジェクトストレージに保存して、Observe UI、CLI、MCP、または互換性のある任意のエンジンを使用してアクセスできます。これは、Observeが取り込み、処理するテレメトリをユーザー自身が所有することを意味します。このデータは、ユーザーの管理下で他のデータとともに存在し、チームがすでに使用しているツールを通じてアクセスできます。
組織全体のチームは、テレメトリを別のシステムに抽出したり複製したりすることなく、他のデータと組み合わせてクエリを実行できます。同時に、エンジニアリングチームは、その同じデータの上でObserveのネイティブなオブザーバビリティワークフローを使用する機能を維持します。オブザーバビリティワークフローは、Icebergテーブル上でもObserveネイティブデータ上と同様のパフォーマンスで実行されます。その結果、データがどのように保存および統制され、どのようにアクセスおよび使用されるかについての柔軟性が向上します。
オブザーバビリティの今後の展望
私たちは常に、オブザーバビリティはデータの問題であると考えてきました。AIによってシステムの複雑さとテレメトリの量が増加するにつれて、このプレッシャーは強まり、基盤となるデータプラットフォームの規模と経済性を圧迫します。
チームは2つの面で対応しています。第一に、持続不可能なコストの増加を招くことなく、大量のテレメトリを保存、処理、およびクエリするためのより効率的な方法を必要としています。第二に、MTTRを削減し、よりプロアクティブな信頼性エンジニアリングへと移行するために、AI主導のワークフローを採用しつつあります。
Observeは、これらのニーズに対応するために構築を進めています。Icebergのサポートにより、チームは低コストのクラウドストレージ上のデータレイクにテレメトリを保存できるようになり、幅広いアクセスを可能にしつつベンダーロックインを回避できるため、オブザーバビリティコストの管理における柔軟性が高まります。Observe CLIは、オブザーバビリティの利用方法が、キュレーションされたUI主導の体験から、CLIやMCPを介したプログラムによるアクセス（Claude CodeやChatGPTなどのツールからの利用を含む）へと移行していることを示しています。
オブザーバビリティのユーザーとそのアクセスパターンが進化し続ける中、大規模なテレメトリとコンテキストの必要性は変わりません。Observeは、お客様がデータを保存、アクセス、活用する方法を継続的に拡張しながら、その基盤を提供します。
詳しくはこちら
Snowflakeのオブザーバビリティ担当GM、Jeremy Burtonが主催するObserve by Snowflakeのローンチイベントをご覧ください。
将来予想に関する記述
このページには、Snowflakeが将来提供する製品に関する記述を含め、将来の見通しに関する記述が含まれていますが、これはいかなる製品の提供も約束するものではありません。実際の結果や提供内容は異なる場合があり、既知および未知のリスクや不確実性の影響を受けます。詳細については、最新の四半期報告書（10-Q）をご覧ください。
