🔭 技術調査 - Vercel Agent Runs (eve Agent Observability)

検証日: 2026-06-29 / 対象: Vercel eve Agent Runs (2026-06-26 Changelog 公開) + AI SDK OTel export
AI SDK: 本記事のコード例は eve 公式 docs が現状サンプルにしている v6 系 telemetry 記法 を基準にします (per-call プロパティ名は experimental_telemetry)。AI SDK v7 は 2026-06-25 に GA となり、experimental_telemetry → telemetry への改名に加え、registerTelemetry + @ai-sdk/otel という新しい起動時登録 API へ統合方式自体が刷新されました。eve のバージョンアップで v7 系統に切り替わると本記事のコード例も差し替えが必要です。最新の eve docs と AI SDK docs を必ず確認してください。

■概要

Vercel Agent Runs は、Vercel が 2026 年 6 月 26 日にアナウンスした AI エージェント向けの観測ダッシュボード です。AI エージェント runtime である eve 上でデプロイされたエージェントを対象に、Vercel ダッシュボードから セッション・ターン・モデル呼び出し・ツール呼び出し・トークン消費 を可視化します。eve プロジェクトには 計装ファイルや設定なしで自動的に有効化 され、ダッシュボードに Agent Runs タブが現れます。

加えて、agent/instrumentation.ts を置くだけで AI SDK の OpenTelemetry span を外部バックエンド (Braintrust / Datadog / Honeycomb / Arize / Raindrop / Jaeger など) にエクスポート でき、既存の Observability 基盤に取り込めます。

位置づけ

eve は Vercel が打ち出した「ファイルシステムファーストな AI エージェント framework」で、agent/ 配下のファイル (instructions / tools / skills / connections / sandbox 等) からエージェントを構成し、Vercel Functions 上で実行する仕組みです。eve は以下の Vercel サービスを内部で組み合わせます。

Agent Runs は eve の標準観測面として位置づけられ、より広範な Vercel Observability (Functions / Edge / AI Gateway / External APIs などの Insights) の一部を構成します。Observability Plus アドオンを契約すると Agent Runs の保持期間も最大 30 日まで拡張されます。

関連技術との関係

Vercel 内部スタックとの関係

サードパーティ Observability 製品との比較

Vercel Agent Runs は「Vercel にデプロイされた eve エージェント専用のゼロセットアップ観測層」で、Langfuse / Braintrust / LangSmith などの汎用 LLM observability とは設計思想が異なります。Agent Runs は競合ではなく 共存 を前提とし、OTel export 経由でこれらに span を流せます。

要点は次の通りです。

• Agent Runs は「eve 標準の観測面」であり、計装やコード変更を不要にする点が他社製品と最も異なります。
• Two-view 設計 (Developer / Business) は Vercel 独自の差別化軸です。
• eval / プロンプト管理機能を備えないため、本格的な評価ワークフローが必要な場合は OTel export 経由で Braintrust / Langfuse 等と組み合わせる前提になります。

比較表の根拠について: 上記の比較は Vercel changelog と公式ドキュメントを一次情報とし、ベンダー (Braintrust / Latitude / Laminar 等) の自社比較記事には宣伝バイアスがあるため参考リンクには載せても本文の比較項目の根拠には採用していません。料金・保持期間の最新値は必ず各社の現行 pricing ページで確認してください。

■特徴

主要な特徴一覧

• 計装不要の自動有効化: eve プロジェクトであれば、Agent Runs タブが Vercel ダッシュボードに自動で出現します。インスツルメンテーションファイル不要、設定変更不要です。
• Two-view 設計 (Developer / Business): デベロッパー向けの生データ表示と、非エンジニア向けの平易な要約を同一画面でトグル切り替えできます。技術者と監査・PM の両方が同じ画面で会話できます。
• トリガー別の Runs 可視化: Slack / HTTP などのトリガー種別ごとに、ランの本数とトークン消費を時系列グラフで表示します。
• トークンメトリクスの内訳: 入力トークン / 出力トークン / キャッシュトークンを分けて表示し、コスト最適化や AI Gateway 効果の検証に使えます。
• ターン単位の詳細ドリルダウン: 各ターンの timings (skill ロード、個別ツール呼び出し)、入出力、reasoning、ツール呼び出し引数 / 結果、トークン内訳を確認できます。
• agent/instrumentation.ts による OTel export: defineInstrumentation() の setup コールバックで registerOTel() を呼ぶだけで、Braintrust / Datadog / Honeycomb / Arize / Raindrop / Jaeger など OpenTelemetry 互換の任意のバックエンドに AI SDK span を流せます。
• AI SDK span にエージェント文脈を自動注入: eve.session.id / eve.turn.id / eve.turn.sequence / eve.step.index / eve.channel.kind / eve.environment / eve.version をスパン属性として付与し、外部バックエンドでのフィルタや相関を容易にします。
• 入出力記録のオプトアウト: AI SDK の recordInputs / recordOutputs フラグでメッセージ履歴・モデル出力の記録を停止でき、機微情報やペイロードサイズへの対応が可能です。
• 保持データのデフォルト暗号化: ランデータは保存時に暗号化されます。
• プライバシー開示の要請: 個人情報・規制対象データを扱う場合、デプロイ者はプライバシーポリシー等での開示義務を求められる旨が公式ドキュメントで明示されています。

Developer view と Business view

保持期間 (tier 別)

Observability Plus は Agent Runs 専用ではなく、Vercel Observability 全体の保持期間とメトリクス粒度を底上げするアドオンです。Pro / Enterprise 契約者で Agent Runs の長期分析が必要な場合、ここで延長します。

トレース階層 (OTel export 時)

外部バックエンドにエクスポートした際の代表的なスパン構造は次の通りです。

ai.eve.turn  {eve.session.id}
  +-- ai.streamText                step 1
  |    +-- ai.streamText.doStream  model call
  |    +-- ai.toolCall {search}    tool exec
  +-- ai.streamText                step 2
  |    +-- ai.streamText.doStream
  |    +-- ai.toolCall {read}
  +-- ai.streamText                step 3 (final text)

events["step.started"] コールバックから runtimeContext を返すことで、ユーザー定義の属性をモデルコールのスパンに付与できます。

機能スコープと「やらないこと」

Agent Runs は観測 (read-only) に特化しており、以下は範囲外です。これらが必要な場合は OTel export 経由で外部製品 (Braintrust 等) と組み合わせる前提になります。

■構造

eve は Vercel が提供する filesystem-first な durable agent framework で、内部的に AI Gateway / Workflows / Sandbox / Connect / Observability を組み合わせます。Agent Runs はその Observability の正面玄関で、追加コードなしで Vercel ダッシュボードに表示される一方、agent/instrumentation.ts を置けば AI SDK の span を任意の OpenTelemetry backend に export できる、という二段構えになっています。

●システムコンテキスト図

eve agent そのものを 1 つのシステムとして扱い、誰が観測し、どこへ telemetry が流れるかを示します。

●コンテナ図

eve agent システムの内部を、ランタイム・観測パイプライン・export 経路に分けて示します。

●コンポーネント図

主要 3 コンテナ (eve Runtime / AI SDK + Instrumentation / Vercel Platform observability 面) をドリルダウンします。

eve Runtime のコンポーネント

AI SDK + OTel Instrumentation のコンポーネント

Vercel Platform Observability 面のコンポーネント

■データ

Vercel Agent Runs が扱うエンティティを「概念モデル」と「情報モデル」の 2 段で整理します。eve ランタイムが生成するセッション / ターン / ステップの階層、AI SDK が出力する OTel span (GenAI 規約 / Legacy ai.*)、eve が span に注入するコンテキスト属性 (eve.*) が中心です。

●概念モデル

エンティティの所有関係 (subgraph) と利用関係 (矢印) を示します。

Agent Project

eve がファイルシステム配置から発見・コンパイルする論理単位です。agent/ 配下のファイル群がそのまま能力 (Tool / Skill / Subagent / Channel / Connection / Sandbox) のレジストリになります。

Runtime Activity

実行時に発生する動的エンティティです。所有階層は Session > Turn > Step です。

Telemetry

Agent Runs 画面の元データです。eve が自動で AI SDK span にコンテキスト (eve.*) を注入し、Vercel 内蔵ダッシュボードと、任意の OTel backend にエクスポートできます。

●情報モデル

各エンティティの属性を示します。型は string / int / timestamp / list / map / enum などの汎用名で表記します。

Agent Project の属性

Runtime Activity の属性

Agent Runs ダッシュボードに表示される動的データです。Session / Turn 識別子は eve が span 属性に注入する形でも外部に流れます。

Telemetry の属性

eve が AI SDK の span 出力に乗せる属性 3 系統 (gen_ai.* / ai.* / eve.*) と、Turn 単位の trace 構造です。

■構築方法

前提条件

• Vercel アカウント: eve プロジェクトをデプロイし Agent Runs ダッシュボード (/{team}/{project}/observability/agent-runs) を見るのに必要です。Hobby / Pro / Enterprise のいずれでも閲覧可能で、保持期間がプランで変わります。
• Node.js + パッケージマネージャ (pnpm 推奨): scaffold が pnpm dev を前提に生成されます。
• eve CLI: npx eve@latest で常に最新版が降ってきます。グローバルインストールは不要です。
• AI Gateway 認証: モデル文字列は Vercel AI Gateway 経由で解決されます。Vercel 上では OIDC で自動認証されるため、provider API キーをエージェント側で管理しなくてよい設計です。ローカル開発時は vercel link + vercel env pull で AI Gateway の credentials を引いておきます。
• OTel export を使う場合のみ: @vercel/otel と、宛先に応じた exporter パッケージ (例: @braintrust/otel、Datadog 系、@honeycombio/opentelemetry-node 等) を追加します。

eve プロジェクトの作成

npx eve@latest init で雛形を生成します。依存インストール、git 初期化、開発サーバ起動まで一括で実行されます。

npx eve@latest init my-agent
cd my-agent
pnpm dev

既存アプリへ後付けする場合は eve.dev の quickstart 手順 (pnpm add eve + agent/ ディレクトリ作成) でも可能です。

agent/agent.ts と agent/instructions.md の最小定義

eve は agent/ 配下を自動探索する filesystem-first フレームワークです。最小構成は 2 ファイル で動きます。

agent/instructions.md (常時 system prompt):

You are a concise assistant. Use tools when they are available.

agent/agent.ts (runtime config):

import { defineAgent } from 'eve';

export default defineAgent({
  model: 'openai/gpt-5.4-mini',
});

ツールを足したいときは agent/tools/<tool_name>.ts を 1 ファイル = 1 ツールで追加します (ファイル名がモデルに見える tool name になります)。動作確認は HTTP で行えます。

# セッション開始 (continuationToken + x-eve-session-id ヘッダが返る)
curl -X POST http://127.0.0.1:3000/eve/v1/session \
  -H 'content-type: application/json' \
  -d '{"message":"What is the weather in Brooklyn?"}'

# 同一セッションのライフサイクルイベントを NDJSON で stream
curl http://127.0.0.1:3000/eve/v1/session/<sessionId>/stream

Agent Runs ダッシュボードへのアクセス (instrumentation 不要)

eve プロジェクトをデプロイすると、agent/instrumentation.ts が無くても Agent Runs は自動で表示されます。これが eve の primary observability surface であり、別途オプトインや設定は不要です。

• Vercel dashboard → 該当プロジェクト → サイドバー Observability > Agent Runs
• URL は https://vercel.com/{team}/{project}/observability/agent-runs
• 保持期間はプラン依存です (Hobby 12h / Pro 1d / Enterprise 3d / Observability Plus で 30 日)

OTel export を有効化: agent/instrumentation.ts

外部 OTel バックエンドへ AI SDK span を流したい場合のみ、agent/instrumentation.ts を追加します。eve はこのファイルを server startup でエージェントコードより先に実行し、その存在自体が telemetry export のスイッチになります。

共通フォーマット (Braintrust の例):

import { BraintrustExporter } from '@braintrust/otel';
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new BraintrustExporter({
        parent: `project_name:${agentName}`,
        filterAISpans: true,
      }),
    }),
});

代表的な exporter テンプレ:

// Datadog (OTLP HTTP)
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new OTLPTraceExporter({
        url: process.env.DD_OTLP_ENDPOINT,
        headers: { 'DD-API-KEY': process.env.DD_API_KEY! },
      }),
    }),
});

// Honeycomb (OTLP HTTP)
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new OTLPTraceExporter({
        url: 'https://api.honeycomb.io/v1/traces',
        headers: { 'x-honeycomb-team': process.env.HONEYCOMB_API_KEY! },
      }),
    }),
});

公式ドキュメントは Braintrust / Raindrop / Arize / Honeycomb / Datadog / Jaeger を「OpenTelemetry 互換であれば何でも繋がる」例として挙げており、上記以外でも OTLP exporter を差し替えれば動きます。

依存パッケージの追加

OTel export を使う場合だけ追加します。Agent Runs ダッシュボードだけなら install 不要です。

pnpm add @vercel/otel

# 宛先に応じて 1 つ以上
pnpm add @braintrust/otel
pnpm add @opentelemetry/exporter-trace-otlp-http
pnpm add @honeycombio/opentelemetry-node

@braintrust/otel は Vercel docs の Braintrust 例で import される名前です。npm registry 上の最新の公開状態 (パッケージ名・バージョン) は実 install 前に必ず確認してください。Braintrust 側で別パッケージ (braintrust 系列など) に集約されている場合があります。

ローカルでの OTel 動作確認 ("hello world" 経路)

外部バックエンドに接続する前に、まず span が出ているかをローカルだけで確認したい場合は、コンソール出力 exporter を使うか、ローカルに Jaeger を立てて OTLP HTTP で流す経路が最短です。agent/instrumentation.ts の traceExporter を以下のように差し替えるだけで動きます。

// 1) コンソール出力 (依存最小)
import { ConsoleSpanExporter } from '@opentelemetry/sdk-trace-base';
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new ConsoleSpanExporter(),
    }),
});

# 2) ローカル Jaeger に流す (UI で trace を眺める)
docker run -d --name jaeger \
  -p 16686:16686 -p 4318:4318 \
  jaegertracing/all-in-one:latest

// agent/instrumentation.ts (Jaeger OTLP HTTP)
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new OTLPTraceExporter({ url: 'http://localhost:4318/v1/traces' }),
    }),
});

pnpm dev で起動し curl -X POST http://127.0.0.1:3000/eve/v1/session ... を 1 回叩けば、コンソールには ai.eve.turn を親とする span ツリーが、Jaeger なら http://localhost:16686 に ai.streamText / ai.toolCall が表示されます。ここで span が出ない場合は本物の外部 backend に挑む前に instrumentation.ts のパスと export 形式を疑うのが定石です。

■利用方法

telemetry 主要オプション

per-call の experimental_telemetry: { ... } (AI SDK v6 系。v7 系は telemetry) と instrumentation 全体の setup({ agentName }) で span への記録粒度を制御します。

AI SDK 本体は per-call isEnabled (この呼び出しだけ telemetry を切る) / metadata (任意の key-value を span attribute に乗せる) といった追加オプションも持ちますが、eve の主要ユースケースでは上の 4 つで足ります。

AI SDK 世代の注意: 本記事のコード例は experimental_telemetry を使う AI SDK v6 系 (eve 公式 docs が現状サンプルにしている記法) です。AI SDK v7 (2026-06-25 GA) では per-call プロパティ名が telemetry に変わり、さらに registerTelemetry + @ai-sdk/otel による起動時登録の新 API も導入されています。eve が v7 系に追随した時点でコード例の名前空間が変わるため、最新の eve docs を確認してください。

ダッシュボードでの run 一覧 / drill-down / per-turn 表示

Vercel dashboard の Agent Runs ビューは 3 階層になっています。

• 概要 (overview)
  • Runs over time: トリガー別 (Slack / HTTP など) の時系列棒グラフ
  • Token usage: 同じウィンドウで input / output / cached を分けて表示
  • Runs テーブル: triggering message、trigger type、tokens in / out、turn count、duration、time の列を持つ run 一覧
• run 詳細 (drill-down): 任意の行を選択すると、その run のモデル / トリガー / デプロイ ID と、turn ごとのブレークダウンが開きます
• per-turn:
  • Timings: skill load と個別 tool call を含む step 単位の所要時間
  • Input / Output: その turn でモデルに渡した内容と返ってきた内容
  • Reasoning: 途中で生成された思考過程 (モデルが reasoning を返した場合)
  • Tool Calls: 呼び出した tool 名 + 引数 + 結果
  • Token counts: input / cached / output の 3 区分

Developer / Business view toggle

run 詳細画面右上の view toggle で 2 つのモードを切り替えられます。

• Developer Mode: 生の tool 名・JSON ペイロード・step 単位の token メトリクスを表示します。デバッグ向けです
• Business Mode: tool 名を「人間が読める文」にリネームし、エージェントが何をしたかを plain English の要約で表示します。非エンジニアの監査・レビュー向けです

注意点 (現状の公開仕様で公式に明示されていないため運用前の確認が必要):

• 要約は plain English で生成される旨が docs に明記されています。日本語環境でのローカライズは公式に未明示のため、非英語の業務監査用途では Business view の文面が現場の言語と合うかを確認のうえ採用します
• 要約生成自体がモデル呼び出しを伴う場合 (= 追加コスト・追加 PII リスク) があり、recordInputs: false 時に要約に何が乗るかも公式に明示されていません。高機密ワークロードではこの非対称性を見越し、Business view を運用に組み込む前に dev / staging で要約出力を実検証します

per-call 制御

OTel export を有効化したうえで、AI SDK 呼び出しごとに span の中身を絞り込めます。

import { generateText } from 'ai';

const result = await generateText({
  model: 'openai/gpt-5.4-mini',
  prompt: userPrompt,
  experimental_telemetry: {
    recordInputs: false,    // 機密プロンプトを span attribute に乗せない
    recordOutputs: false,   // 応答テキストを span attribute に乗せない
    functionId: 'poem-writer', // span 名 (= gen_ai.operation.name) を上書き
  },
});

• recordInputs: false / recordOutputs: false は Agent Runs ダッシュボード側にも反映されます (span から取り除かれるため)。PII / 規制データを扱う turn は明示的に落とすのが定石です
• functionId を変えると同じファイル内の複数 LLM 呼び出しを分けて集計できます

events["step.started"] callback で runtimeContext を span に注入

eve はデフォルトで session / turn / step / channel のコンテキストを span に乗せます。これにアプリ固有の属性を足したい場合は events["step.started"] callback を使います。callback が返した runtimeContext オブジェクトがモデル呼び出し span にそのまま attribute として乗ります。

import { defineAgent } from 'eve';

export default defineAgent({
  model: 'openai/gpt-5.4-mini',
  events: {
    'step.started': ({ session, turn }) => ({
      runtimeContext: {
        'app.tenant_id': session.metadata?.tenantId,
        'app.feature_flag.v2': true,
        'app.turn_kind': turn.kind,
      },
    }),
  },
});

生成された trace は次の階層になります。

ai.eve.turn  {eve.session.id}
  +-- ai.streamText                          step 1
  |     +-- ai.streamText.doStream           model call
  |     +-- ai.toolCall  {toolName: search}  tool exec
  +-- ai.streamText                          step 2
  |     +-- ai.streamText.doStream
  |     +-- ai.toolCall  {toolName: read}
  +-- ai.streamText                          step 3 (final text)

step.started で返す値は model-call span に乗るため、テナント別レイテンシ集計や feature flag 単位の A/B 比較に使えます。

Agent Runs と Vercel Drains 経由のトレース export の併用

Agent Runs と Vercel Tracing (Drains 経由の OTel export) は守備範囲が違うので併用できます。

• Agent Runs (agent/instrumentation.ts 不要): eve の session / turn / tool / token 視点。常に有効
• agent/instrumentation.ts で AI SDK span を export: Braintrust / Datadog / Honeycomb など、エージェント開発者が選んだ専用バックエンドへ AI SDK の span を直接送る経路
• Vercel Drains (Trace Drains): Vercel インフラ視点 (CDN → middleware → function → outbound fetch) のトレースを HTTP エンドポイントや Marketplace ネイティブ統合へ流す経路。AI SDK span は乗らないが、フロント → 関数 → 外部呼び出しのレイテンシ分析に使えます

3 つを併用するときの推奨構成:

• アプリ開発者が AI 挙動を追う: Agent Runs + agent/instrumentation.ts (Braintrust など評価系バックエンド)
• SRE がインフラを追う: Vercel Drains で Datadog / Honeycomb に infra trace を流す
• 両方を 1 つの UI で見たい: agent/instrumentation.ts と Drains の宛先を同一バックエンド (例: Datadog) に揃え、serviceName / tag で識別する

@vercel/otel を併用する際、Sentry SDK v8+ を入れていると OpenTelemetry の初期化が衝突して trace propagation が壊れることがあります。Sentry を使うなら skipOpenTelemetrySetup: true を Sentry 側に入れて Vercel OTel に主導権を渡します。

二重 OTel 登録と trace context 伝播

• アプリ側で別途 registerOTel(...) や registerTelemetry(new OpenTelemetry()) を呼んでいる場合、agent/instrumentation.ts の setup callback と二重登録になり、後に登録した provider が前のものを上書きします (provider は global で 1 つ)。エージェントコード側の registerOTel を削るか、agent/instrumentation.ts 側に exporter 登録を集約します
• Vercel Tracing (infra spans: CDN / middleware / function) と ai.eve.turn 由来の AI SDK span を 1 本の trace としてつなげたい 場合は、@vercel/otel の traceparent 伝播を有効化したうえで、agent/instrumentation.ts の registerOTel に同一の trace exporter を渡します。別 exporter にすると infra と AI が別 trace に切れます

■運用

Agent Runs ダッシュボードでの状態確認

• 入口は Vercel ダッシュボード → 対象 project → Agent Runs タブです
• まず見るべき 3 つの観点:
  • Runs over time: 想定外の trigger スパイク (誤接続された Slack 連携、外部 cron の暴走など) を検知
  • Token usage: input が伸びている = 過去 history を切り詰めず注入している、output が伸びている = タスク分割不足。cached の比率が低いとプロンプトキャッシュが効いていない兆候
  • Runs テーブル: duration の外れ値と、turn count が極端に多い run (= ループ気味の agent) を拾う
• run を選ぶと turn ごとの breakdown (timings, input, output, reasoning, tool calls 引数 / 結果, token 内訳) に降りられます

Agent Runs view (production triage flow)
  1) Runs over time で異常時間帯を特定
  2) Runs テーブルで該当時間帯 + duration / turn count でソート
  3) run 詳細 → 失敗した turn の Tool Calls / Output を読む
  4) ai.toolCall span の error or 異常な output を確認

OTel exporter の動作確認

• agent/instrumentation.ts は server startup 前に自動 discover されます
• 動作確認手順:
  • dev で pnpm dev 起動 → curl -X POST .../eve/v1/session でセッション開始 → 外部 backend に ai.eve.turn を親とした trace が来ているか確認
  • 来ない場合は (1) instrumentation.ts のパス・named export、(2) exporter URL / credentials、(3) Sentry SDK と二重設定、の順で切り分け
• 親 span は ai.eve.turn、子に ai.streamText → ai.streamText.doStream (モデル呼び出し) / ai.toolCall (tool 実行) が並びます

Failed run の原因切り分け

PII カット運用

AI SDK の telemetry で recordInputs: false / recordOutputs: false を指定すると、span に message history と model output を載せなくなります (デフォルトは両方 true)。ただし Agent Runs ダッシュボード側にも turn の Input / Output / Tool args は表示されるため、規制データを扱うときは「OTel exporter 側で off にする」だけでなく、Agent Runs 自体の利用範囲 (Vercel team のメンバー権限) も合わせて締めます。

ガイドラインとして公式 docs にも、デプロイ者側に開示義務が乗りうる旨が明示されています ("As the deployer, where your agent processes personal, sensitive, or regulated data, you may be required to disclose this capture as required by applicable laws and in your privacy materials.")。

保持期間 (retention) の確認と延長

Vercel Observability 全体の保持ポリシーが Agent Runs にも適用されます。

• Pro / Enterprise なら Billing → Observability Plus トグルで延長します
• 30 日を超える保管 (監査・規制・SOC2 など) が必要なら Vercel Drains で外部 backend に転送して保管します

Drains 経由の長期保管・外部分析

• Drains は traces (OpenTelemetry 形式) / logs / speed insights / analytics の 4 種を外部に転送できます (Pro / Enterprise 限定)
• Agent Runs が OTel で出した span を Drains の trace drain 経由で Datadog / Splunk / Dash0 / Braintrust 等の native integration、または任意の HTTP endpoint に流す構成が王道です
• recordInputs / recordOutputs を OFF にしているなら、Drains 先にも PII は流れない (span が空のまま転送される) という対称性が成り立ちます

■ベストプラクティス

二面ビュー (Developer / Business) を「責任分担」として使う

• 推奨運用:
  • 開発者: 不具合切り分けは Developer モード。ai.toolCall の args / result を直接読む
  • 業務側 (PM / コンプラ / カスタマー対応): Business モードでセッション内容を確認。「この agent が顧客に何をしたか」の説明責任を、Vercel 標準 UI に寄せられる
• 注意: 高機密ワークロード (医療、決済、法務 PII) では Business view にも要約として PII が漏れるリスクが残ります。この場合は二面ビューに頼らず、recordInputs/recordOutputs を OFF + 業務側には別途 redact 済みのアプリ内ログだけを見せる構成にします

recordInputs / recordOutputs を最初に決める

規制データ・顧客 PII を扱うプロジェクトは「最初に OFF、必要な span だけ ON にする」方が安全です。後から OFF にしても既存 span に乗った PII は保持期間中残ります。

// agent/instrumentation.ts
import { defineInstrumentation } from 'eve/instrumentation';
import { registerOTel } from '@vercel/otel';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

export default defineInstrumentation({
  setup: ({ agentName }) =>
    registerOTel({
      serviceName: agentName,
      traceExporter: new OTLPTraceExporter({ url: process.env.OTLP_ENDPOINT }),
    }),
});

// 各 generate/streamText 呼び出し側 (PII を含む業務処理)
const result = await streamText({
  model,
  prompt,
  experimental_telemetry: {
    recordInputs: false,
    recordOutputs: false,
    functionId: 'kyc-review',
    metadata: { tenantId, requestId },
  },
});

events["step.started"] で監査メタを必ず付ける

監査要件を満たすには PII 本体を span に乗せず、識別子だけ乗せるのが定石です。eve docs では events["step.started"] callback が返した runtimeContext がモデル呼び出し span に乗ることが明示されています (AI SDK v7 系で導入された registerTelemetry の enrichSpan を併用する構成も考えられますが、eve の現行 docs ではこちらが主経路です)。

export default defineAgent({
  model: 'openai/gpt-5.4-mini',
  events: {
    'step.started': ({ session }) => ({
      runtimeContext: {
        userId: session.metadata.userId,
        tenantId: session.metadata.tenantId,
        requestId: session.metadata.requestId,
        // PII (氏名・住所・カード番号) は載せない
      },
    }),
  },
});

規制業種ではデプロイ者の開示責任を踏む

• プライバシーポリシーに「対話履歴・tool 引数を観測ログに保管する」旨と保管期間 (Hobby 12h / Pro 1d / Enterprise 3d / Plus 30d) を明記
• 30 日を超える保管 (Drains → Datadog 等) があるなら、保管先と保管期間も別途記載
• 規制業 (金融・医療) では DPA / BAA の対象に Vercel / 外部 backend を含める

Drains で長期保管 + アラートを外部に持つ

• Agent Runs は短期の運用ビューに特化しているため、長期トレンド (週次の duration p95、月次の token cost、SLO アラート) は Drains 経由で Datadog / Splunk / Honeycomb に出す方が運用が安定します
• Pro / Enterprise なら trace drain を 1 本足すだけで OpenTelemetry スキーマで届きます (native integration あり)
• Hobby は Drains 自体が使えません (Pro 化必要)

eve は beta 前提で書く (migration 余地を残す)

• eve framework 本体は beta です。API / file 配置 / span 名 / events.step.started のシグネチャは GA までに変わり得ます
• 推奨:
  • exporter / metadata 付与は薄いラッパー関数を 1 つかませて、@vercel/otel 直叩きを agent コードに散らさない
  • eve.* 属性に依存する外部ダッシュボードのクエリは 1 ファイルに集約しておく (リネームが起きても 1 箇所で追従)
  • changelog と /docs/eve の last_updated を週次で確認
• Agent Runs ダッシュボード機能自体は 2026-06-26 changelog でアナウンスされています (eve framework 本体の beta と切り分けて理解します)

二面ビューが向かないケースの代替 (反証統合)

■トラブルシューティング

症状別マトリクス

切り分けフロー (フリーズ・サイレント失敗)

[run が表示されない / 動いていない疑い]
  |
  +-- vercel deploy 直近で成功しているか
  |     +-- いいえ → deploy ログ確認 (build failure)
  |     +-- はい  → ↓
  |
  +-- Functions logs に session 開始ログが出ているか
  |     +-- 出ていない → channel webhook 側の問題 (trigger 不達)
  |     +-- 出ている  → ↓
  |
  +-- Agent Runs にも出ていない
        +-- eve project として認識されていない可能性大
        +-- agent/ 構成 export 確認、必要なら npx eve@latest init で雛形と diff

■まとめ

Vercel Agent Runs は、eve プロジェクトに設定変更なしで Agent ダッシュボードを与え、agent/instrumentation.ts 1 ファイルで OpenTelemetry バックエンド (Braintrust / Datadog / Honeycomb 等) への AI SDK span エクスポートを開く設計でした。Developer / Business の二面ビュー、ai.eve.turn 配下の span 階層、tier 別 retention と recordInputs / recordOutputs による PII 制御を、エージェント運用の説明責任設計にそのまま落とし込めます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

■参考リンク

一次情報 (Vercel / AI SDK)

• Vercel Changelog — eve Agent Observability (2026-06-26)
• Vercel Docs — eve / Observability
• Vercel Docs — eve
• Vercel Docs — eve / Concepts
• Vercel Docs — eve / Pricing and Limits
• Vercel Docs — Observability
• Vercel Docs — Observability Plus
• Vercel Docs — Tracing
• Vercel Docs — Tracing / Instrumentation
• Vercel Docs — OpenTelemetry Instrumentation
• Vercel Docs — Drains
• AI SDK Docs — Telemetry
• npm — @vercel/otel

外部 Observability バックエンド統合

• Braintrust Docs — OpenTelemetry (OTel)
• AI SDK Docs — Observability Integrations / Braintrust
• Langfuse — Observability and Tracing for the Vercel AI SDK

比較・関連調査

• Agent observability: The complete guide for 2026 — Braintrust
• AI Agent Observability Tools Compared (2026) — Latitude
• Langfuse alternatives 2026 — Braintrust
• LangSmith alternatives 2026 — Braintrust
• Top 6 Agent Observability Platforms (2026) — Laminar