最良のバスとは、バスを使わないことである: ZeroBusがAIアプリケーションテレメトリの常識を変える理由

Posted at 2026-02-16

The Best Bus Is No Bus: Why ZeroBus Changes the Game for AI Application Telemetry | by AI on Databricks | Feb, 2026 | Mediumの翻訳です。

本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

著者: Jai Behl, Lead Solutions Architect and Brandon Kvarda, Lead Solutions Architect

要約: AIアプリケーションは大量に流れ込むテレメトリを生成します - トークン数、レイテンシーの計測、ツール呼び出し、コストのシグナル - そして従来のメッセージバスアーキテクチャはその重さに耐えきれなくなっています。ZeroBus、Databricksのサーバレス直接書き込みAPIは、ミドルウェアを完全に排除します。我々自身のAIを活用したツールを計測可能にするために内部で使用しており、その結果は説得力のあるものです: 1秒未満での取り込み、管理するインフラ不要、リアルタイム分析を支持する統合されたDeltaテーブル。これが、AIアプリケーションを構築するすべてのチームが注目すべき理由です。

誰も警告しなかったテレメトリの問題

従来のWebアプリケーションを出荷する際、可観測性は解決済みの問題です。Datadog、Prometheus、Grafana - スタックを選択し、メトリクスを吐き出させて、先に進みます。しかし、AIアプリケーションは違います。

LLMとのすべてのやりとりは、我々が10年標準化に費やしたメトリクス/ログ/トレースモデルにはうまくフィットしない、シグナルのカスケードを生成します:

トークンの考慮 - 入力トークン、出力トークン、キャッシュ生成トークン、キャッシュ読み込みトークン。それぞれは異なるコストの因数を持っています。一つが欠けると、あなたの請求を説明できなくなります。
ツールのオーケストレーション - 単一のユーザープロンプトは、bashコマンド、ファイル読み込み、Web検索、MCPサーバー呼び出しなど15のツールにファンアウトします。どのツールがユーザーが実際に必要とするものなのでしょうか？どれがデッドウェイトなのでしょうか？
セッションの経済学 - 期間、メッセージ数、モデル選択、セッション毎のコスト。数百の同時接続ユーザーによって倍増し、夜間バッチジョブではなくリアルタイムの集計が必要となります。
複数界面の属性 - 同じAIの能力は、CLI、デスクトップアプリ、APIを通じて公開されるかもしれません。パイプラインを重複させることなしに、界面ごとにスライスできるように統合されたスキーマが必要となります。

これは根本的には、可観測性の問題の皮をかぶっったデータエンジニアリングの問題です。そして、古典的な回答は - 「間にKafkaを置け」ですが、これは間違いなくAIチームが最も許容できないある種の運用のオーバーヘッドを引き起こします。

ZeroBusへようこそ: 直接書き込み、ホップゼロ

ZeroBus Ingest、DatabricksのLakeflow Connectの一部である本機能は、一見シンプルに見えて奥が深いコンセプトです: あなたのアプリケーションにgRPC経由でイベントデータを直接Deltaテーブルにプッシュさせ、間にメッセージバスは存在しません。

アーキテクチャはエレガントです:

サイジングするKafkaクラスターは不要です。トピックのパーティショニングに悩む必要はありません。お守りするSpark構造化ストリーミングジョブも不要です。あなたのアプリケーションがSDKを呼び出すと、ZeroBusがスキーマを検証し、堅牢性のためにWALに書き込みを行い、Deltaにマテリアライズします。データは5秒以内にクエリーできるようになります。

数字に語らせましょう:

そして、ネイティブにUnity Catalogに書き込むので、あなたのテレメトリデータはあなたのプロダクションテーブルが享受するのと同じガバナンス、アクセスコントロール、リネージを継承します。あなたのセキュリティ境界の外に存在する「テレメトリデータレイク」は不要です。

なぜこれが特にAIで重要なのか

こう思うかもしれません: 「これは汎用取り込みツールのように聞こえる。なぜこれが特にAIに適しているのか？」3つの理由があります。

1. AIテレメトリーはバーストし予測できません

単一のAIエージェントのセッションは、呼び出されるツールの数、生み出されるサブエージェントの数、どれだけ会話が継続したのかに応じて、3つあるいは300のテレメトリイベントを生成するかもしれません。従来のメッセージバスアーキテクチャでは、ピークの負荷に対したプロビジョニングが必要です。ZeroBusは自動でスケールし、アイドル状態のキャパシティにお金を払う必要はありません。

2. スキーマは複雑で進化します

AIテレメトリは単なる{timestamp, value}ではありません。典型的なセッションイベントには以下のようなものが含まれます:

{
  "event_type": "session_stats",
  "timestamp": "2026-02-09T18:30:00.000Z",
  "user": "engineer-42",
  "source": "desktop",
  "payload": {
    "session_id": "abc-123",
    "model": "claude-sonnet-4-5",
    "duration_ms": 45000,
    "token_usage": {
      "input": 12000,
      "output": 3800,
      "cache_read": 8400
    },
    "tools_invoked": {"Bash": 2, "Read": 5, "Grep": 3},
    "skills_invoked": {"data-query": 1},
    "agents_spawned": {"Explore": 1},
    "cost_usd": 0.05
  }
}

これは、動的なキー(能力を追加するたびにツール名は変化します)を持つネストされたJSONです。ZeroBusはネイティブにJSONレコードに対応し、Deltaに格納するので、フラット化なしにクエリーするためにfrom_json()と半構造化データアクセスパターンを活用することができます。お使いのAIアプリケーションに新たなツールを追加する際に維持が必要なETLパイプラインは不要です。

3. AIがすでに稼働している場所にデータが必要です

DatabricksでAIワークロードを実行しているのであれば、あなたのテレメトリは同じレイクハウスに到着し、モデルサービングのログ、特徴量ストアのテーブル、ビジネスメトリクスとセッションデータすべてをSQLで結合できることを意味します。特定のユーザーセグメントとトークンコストのスパイクを相関させたいですか？一つのクエリーで可能です。最も価値をもたらしているAIツールがどれかを示すダッシュボードを構築したいですか？そのためのDeltaテーブルです。

これは鍵となる洞察です: AIテレメトリはロギングの問題ではありません。分析の問題です。 そして、分析の問題はサイロ化された可観測性ベンダーにではなく、あなたのレイクハウスに属するものです。

内部で使って学んだこと

我々の内部でAIを活用するツール、データエンジニアリングワークフローでエンジニアを支援するために埋め込まれたエージェントとしてClaudeを使うアプリケーションからテレメトリを収集するために、プロダクション環境でZeroBusを実行しています。こちらが実践的な学びです:

ファイア・アンド・フォーゲットこそが正しいパターン

AIアプリケーションはレイテンシーセンシティブです。ユーザーはリアルタイムでストリーミングのレスポンスを見ています -　テレメトリの送出でUIをブロックすることはできません。我々の実装は、ファイア・アンド・フォーゲットパターンで非同期でイベントを公開します:

// Session complete → publish telemetry → never block the user
const stats = finalizeSession(durationMs, costUsd, usage);
if (stats) {
publish(stats).catch(() => { /* logged, never thrown */ });
}

ZeroBusの50ms未満の確認応答のレイテンシは、「ファイア」の部分すらも高速であることを意味しますが、鍵となる設計原則はテレメトリは決してユーザー体験を悪化させてはならないということです。ZeroBusが到達不可能な場合、アプリケーションは全く同じように動作します - テレメトリはシンプルにスキップされます。

グレースフルデグラデーションは絶対に譲れません

AIアプリケーションにおいては、SDK/ランタイムの依存関係ツリーはすでに複雑なものになっています。あなたのアプリをクラッシュさせうるテレメトリの依存関係の追加は許容されません。我々のインテグレーションでは、ZeroBus SDKを遅延処理でインポートし、利用できない場合にはサイレントにテレメトリを無効化します:

async function loadSdk(): Promise<boolean> {
  try {
    const module = await import('@databricks/zerobus-ingest-sdk');
    return true;
  } catch {
    console.warn('ZeroBus SDK not available — telemetry disabled');
    return false;
  }
}

このパターン - オプション機能としてのテレメトリは、決してハードな依存関係ではありません - はさまざまな環境において信頼性を持って動作するAIツールの出荷では重要となります。

統合されたスキーマ、複数の界面

我々は、ソースフィールドが異なる同じ論理的スキーマを用いて、CLI(Go)とデスクトップアプリケーション(TypeScript)の両方からテレメトリを放出します。両方は単一のUnity Catalogテーブルに書き込みを行います。これは、単一のSQLで以下に回答できることを意味します:

「どの界面が高いトークン効率を示している？」
「デスクトップユーザーはCLIユーザーと違うツールを呼び出している？」
「モデルと界面ごとの平均セッションコストは？」

ZeroBusはこれを簡単にしました - 2つのプロデューサー、1つのテーブル、スキーマ競合なし、マージジョブ不要です。

サービスプリンシパル認証はそのまま動きます

ZeroBusは認証にDatabricksサービスプリンシパルのOAuthを使用します。クライアントIDとシークレットを設定すると、SDKがトークン交換とリフレッシュに対応するので、認証のことを再び考える必要はありません。Databricksで認証済みのアプリケーションであれば、複雑性は全く増えません。

フック: ライフサイクルイベント経由でのゼロコードテレメトリ

我々が発見した最もパワフルなパターンは、AIアプリケーションのソースコードを全く変更することなしに、テレメトリを公開するためのライフサイクルフックを用いるということです。

Claude Codeを含む多くのAIコーディングツールはエージェントセッションにおける特定のポイント(SessionStart、Stop、PostToolUseなど)で発火するイベントであるライフサイクルフックを公開し、ユーザー定義のシェルコマンドを実行します。このフックは、どのツールが呼ばれたのか、どの引数を受け取ったのか、セッションのメタデータなどイベントを説明する構造化JSONをstdinで受け取り、それに基づいてアクションを実行します。

セッションのトランスクリプトを解析し、ZeroBusに集計した統計情報を公開する小さなCLIコマンドにStopフック(AIエージェントがレスポンスを完了した際に発火)を接続しました。設定は、ユーザー設定の単一のJSONエントリーです:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "your-cli telemetry publish --from-hook --quiet 2>/dev/null || true",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

フックが発火すると、AIツールはstdin経由でセッションのトランスクリプトのパスを引き渡します。CLIコマンドはすべてのメッセージ、ツール呼び出し、トークン使用量レコードを含むJSONLファイルであるトランスクリプトを読み込み、単一のテレメトリイベントに集約します:

// Parse the transcript JSONL → extract session stats
stats := &SessionStats{
    ToolsInvoked:    make(map[string]int),
    SkillsInvoked:   make(map[string]int),
    AgentsSpawned:   make(map[string]int),
    MCPToolsInvoked: make(map[string]int),
}

for scanner.Scan() {
    var record TranscriptRecord
    json.Unmarshal(scanner.Bytes(), &record)

    switch record.Type {
    case "user":
        stats.UserMessages++
    case "assistant":
        stats.AssistMessages++
        // Aggregate token usage, count tool invocations
        for _, content := range contentItems {
            if content.Type == "tool_use" {
                stats.ToolsInvoked[content.Name]++
            }
        }
    }
}

// One event per session → publish to ZeroBus
event := stats.ToEvent("session.stop")
zerobusPublisher.Publish(event)

この単一イベントはDeltaテーブルに到着し、すべてのキャプチャします: セッションの期間、メッセージ数、トークン使用料のブレークダウン、すべてのツール/スキル/エージェント/MCPの呼び出しとカウント、使用モデル、作業ディレクトリ。全体のパイプライン - フックの発火からクエリー可能なDeltaの行 - は5秒以内の処理です。

なぜこのパターンが重要なのか:

AIアプリ自身には計測用コードは不要です。 フックはコードの変更ではなく設定のエントリーです。ソースに触ることなしに、ライフサイクルフックをサポートする任意のAIツールにテレメトリを追加できます。
フェイルセーフの設計。 2>/dev/null || trueのサフィックスによって、フックがユーザーのワークフローを阻害しないようにします。ZeroBusがダウン、あるいはCLIがインストールされていない場合、セッションは通常通り完了します。
自動のインストールとヘルスチェック。 インストーラーはセットアップ過程でフックを追加し、doctorコマンドは適切に設定されていることを検証します - そうでない場合には修理します。
コンポーザブル。 同じイベントに対して複数のフックをスタックすることができます。ローカルファイルへの記録、Slack通知の送信、コンプライアンスチェックを実行したいですか？hooks配列に別のエントリーを追加しましょう。それぞれの実行は並列に行われます。

このフックベースのアプローチは、トランスクリプトファイルがディスクに存在さえしていれば、テレメトリ機能が存在する前に実行されたものを含む任意のセッションに訴求的に動作するので、CLI界面でのプロセス内のテレメトリよりも、さらに価値のあるものとなりました。

より大きな視点: データエンジニアリングの一分野としてのテレメトリ

AI業界はある理解に収束しています: AIアプリケーションの可観測性はSaaS製品ではない - データエンジニアリングの実践である。

OpenTelemetryコミュニティはAIエージェントの可観測性のためのセマンティック規約の開発にアクティブに取り組んでいます。企業は、AIワークロードがスケールするにつれて、可観測性のコストが月間$130,000を超えていることに苦慮しています。そして、分散したベンダーのランドスケープは、あなたのテレメトリデータが5つの異なるダッシュボードにおいてプロプライエタリなフォーマットにロックインされることを意味します。

ZeroBusは異なるパスを提供します: あなたのレイクハウスでオープンフォーマットで自身のテレメトリデータを所有し、Unity Catalogで管理しましょう。 アドホック分析ではDatabricks SQLを使いましょう。お好きなBIツールでダッシュボードを構築しましょう。自身の利用パターンに基づいてモデルをトレーニングしましょう。データはあなたのものです。

そして、ZeroBus OTELサポートがロードマップに乗ることで、OpenTelemetryで計測される既存アプリケーションは、コード修正不要で設定を変更を行うことでテレメトリをあなたのレイクハウスに転送できるようになります。

使い始める

DatabricksでAIアプリケーションを構築しているのであれば、スタートする方法はこちらです:

あなたのテレメトリイベントのためのUnity CatalogでマネージドDeltaテーブルを作成します
上記テーブルに書き込み権限を持つサービスプリンシパルをセットアップします
ZeroBus SDKをインストールします (Python、TypeScript、Java、Rust)
ファイアンドフォーゲットイベントの公開で、アプリケーションを計測可能にします
Databricks SQLでテレメトリをクエリーします - 同じワークスペース、同じガバナンス、同じツール

ZeroBusは現状パブリックプレビューであり、プレビュー期間は無料です。

結論

AIアプリケーションは、過去のパラダイムにフィットしないテレメトリの新たなカテゴリを作り出しました。トークンの経済学、ツールオーケストレーションのパターン、マルチエージェントセッションのダイナミクス - これらのシグナルは従来のメトリクスシステムでは複雑すぎ、サイロ化されたベンダーに送出するには高価すぎます。

ZeroBusによって、AIテレメトリをそのままの形で取り扱えるようになります: あなたのレイクハウスに属する高速なイベントデータ、あなたのプロダクションテーブルとともにクエリー可能、Unity Catalogで管理され、すでに動作している分析とAIワークロードで利用できるようになります。

最良のメッセージバスとは、バスをまったく使わないことです。

ソース:

はじめてのDatabricks

Databricks無料トライアル

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up