「本番でエラーが出た。ダッシュボードを開き、ログを検索し、トレースを辿り、該当コミットを探す」——この一連の作業は、観測ツールがどれだけ進化しても、結局は人間のスクロール作業として残り続けてきました。Traceway（tracewayapp/traceway）が面白いのは、ここに手を入れている点です。本番のテレメトリをAIエージェントが直接読める形で開き、Claude Codeにエラーのリンクを1本渡すだけで、根本原因の特定からコード修正までを走らせます。

ただし、最初に誤解を解いておきます。TracewayはAI専用のツールではありません。実体はOpenTelemetryネイティブの汎用オブザーバビリティ基盤で、ログ・トレース・メトリクス・セッションリプレイ・例外追跡を1つに束ねた製品です。公式が掲げる「AI Observability」は、READMEが並べる8つの機能のうちの1つに過ぎません。本記事はその事実を踏まえた上で、当サイトの読者にとって価値がある 「LLM監視」と「Claude Code連携」の2点に絞って、GitHubスター1,023・MITライセンスのこのOSSを一次情報から読み解きます。

30秒でわかるポイント
  • ・課題：本番エラーの原因究明は、人間がダッシュボードを何往復もする作業のまま。LLMのコストとアプリの障害も別々のツールに分かれている。
  • ・解決：TracewayはOTelで集めた本番テレメトリをAIエージェントが読める形で開き、Claude Codeが/tracewayでエラーを調べ、根本原因まで辿って修正する。
  • ・正体：AI専用ツールではなくOpenTelemetryネイティブの汎用観測基盤。AI Observabilityは8機能のうちの1つ。
  • ・LLM監視の実力：コスト・トークン・レイテンシ・全会話を追えるが、プロンプト管理や評価（Evals）は無い。Langfuseの代替ではない。
  • ・判定：MIT（BSLもオープンコアも無し）・docker compose up -dで自己ホスト可。ただし819コミット中699が1人＝バス係数は正直に低い。

まずは公式のデモGIFを見てください。これが本記事の主題そのものです。Tracewayのダッシュボードに出た本番エラーを起点に、Claude Codeが原因を突き止め、コードを直すまでが27秒に収まっています。

Traceway に出た本番エラーを起点に、Claude Code が根本原因を特定してコードを修正するまでのデモ
Traceway のエラーから Claude Code が本番障害を end-to-end で修正するまで（出典: tracewayapp/traceway 公式リポジトリ の traceway-ai-demo.gif。7倍速）

Claude Code全体の使い方は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き をご覧ください。

Tracewayとは？AI専用ツールではなくOTelネイティブの観測基盤

Tracewayを一言でいえば「OpenTelemetryネイティブのオブザーバビリティ基盤」です。公式READMEの冒頭は、それを次のように説明しています。ログ・トレース・メトリクス・セッションリプレイ／RUM・例外・AIトレーシングを1か所にまとめ、OTLPエクスポーターを向けるだけで動く。Collectorも、糊付けコードも、言語ごとのベンダーSDKも要らない——と。

ここで重要なのは設計思想の順番です。多くの監視SaaSは「まず自社SDKを入れてもらい、その中でOTelもサポートする」という形をとります。Tracewayは逆で、OTLP/HTTPでの受信そのものが第一級の入口です。この違いは後述するLLM監視の性格を決定づけるので、覚えておいてください。

READMEが挙げる「What’s in the box」は8項目あります。AI Observabilityはその最後の1つです。

機能 内容
Logs 構造化・トレース紐付け済み。OTel SDKからのOTLP/HTTPネイティブ取り込み
Traces サービス横断のスパンウォーターフォール。ログから該当スパンへ直接ジャンプ
Endpoints ルート単位のレイテンシ百分位（P50/P95/P99）・スループット・エラー率
Metrics ホスト・ランタイム・カスタムメトリクス
Exceptions スタックトレースを正規化しSHA-256でフィンガープリント化、issueへ集約
Profiling（実験的） CPU・ヒープ・goroutineのフレームグラフ。バージョン間差分
Session Replay エラー直前のユーザー操作を再生（Web全般とFlutter）
AI Observability LLMのコスト・トークン・レイテンシ・全会話をプロバイダ横断で追跡

GitHubのトピック欄も、この性格を裏付けています。observability-platform・otel・session-replay・exception-tracker・metrics・traces——aiもllmも入っていません。開発者自身がこれを「AIツール」として位置づけていないということです。

読み違えないための前提
「Claude Codeが本番障害を直すデモ」の印象が強いため、TracewayをAIネイティブの新種ツールだと受け取ると評価を誤ります。正確には汎用の観測基盤が、AIエージェントから使われることを設計に織り込んでいるという順序です。この記事が扱うのは、その汎用基盤の中の「AIに効く部分」に限定した切り口です。

技術スタックも堅実な構成です。バックエンドはGo 1.25とGin、フロントはSvelteKit 2／Svelte 5／Tailwind CSS v4、テレメトリDBはClickHouse（スタンドアロン構成）またはSQLite・DuckDB（組み込み構成）、リレーショナルDBはPostgreSQLまたはSQLite。取り込みはOTLP/HTTP（Protobuf＋JSON）です。

Traceway の Issues 画面。例外がフィンガープリントで集約され、影響度で並ぶ
例外はスタックトレースを正規化して SHA-256 でフィンガープリント化し、issue として集約・ランク付けされる（出典: 公式リポジトリのスクリーンショット）

デモを読み解く：Claude Codeが本番のnil mapパニックを直すまで

冒頭のGIFで実際に何が起きているのか、コマ単位で追ってみましょう。このデモは公式が用意したものであり、以下は画面に映っている内容の記述です。

1コマ目：エラーが上がる。 Tracewayのダッシュボード（cloud.tracewayapp.com）のIssues画面に、Goのランタイムパニックが1件並んでいます。runtime.plainError: assignment to entry in nil map——初期化されていないmapへの書き込み、Goでは典型的な本番クラッシュです。Events列は6件、直近24時間のトレンドが表示されています。

2コマ目：人間がやるのはリンクを貼ることだけ。 ターミナルのClaude Code（画面上ではv2.1.195／Opus 4.8）に、開発者が打ち込むのは1行です。

/traceway fix https://cloud.tracewayapp.com/issues/de3b5eec63abe029?projectId=...&preset=24h

ダッシュボードのURLをそのまま貼っている点に注目してください。エラーIDを転記したり、ログを手でコピーしたりする工程が消えています。

3コマ目：エージェントが調べて、直す。 Claude Codeがリポジトリを読み、Tracewayから当該例外の詳細を取得し、結論を述べます。画面の文言はこうです——「Now I’ll apply the fix: add the sync import, initialize the map, and guard the concurrent write with a mutex.」（これから修正を適用します。syncをインポートし、mapを初期化し、並行書き込みをミューテックスで保護します）。そしてcoupon.goの8行目に"sync"が追加される差分が緑色で表示されます。

つまりこのデモが示しているのは、エラーの表示ではなくエラーから修正までの経路が1本に繋がっているという一点です。従来なら「ダッシュボードを見る→スタックトレースを読む→該当ファイルを開く→原因を推測する→直す」と人間が担っていた5工程が、リンク1本の受け渡しに畳まれています。

デモを見るときの注意
①このデモは7倍速で、実時間ではありません。画面下の表示では、修正までに約1分13秒・4.5kトークンを消費しています。②デモの実行環境はTraceway Cloud（cloud.tracewayapp.com）で、セルフホスト環境ではありません。同じCLIはセルフホスト先にも向けられますが、GIFに映っているのはマネージド版です。③修正対象は意図的に仕込まれた分かりやすいバグ（nil map への並行書き込み）であり、あらゆる本番障害がこの手際で直るという意味ではありません。

なお、GIFで使われている/traceway fixという呼び出しは、現在のSKILL.mdが表として明示しているlogin／debug／perfには含まれません。SKILL.mdの規定では、それ以外の引数は「Query（CLIの読み取りで質問に答える）」フローへ流れます。スキルは活発に更新されているため、手元のバージョンで/tracewayのヘルプを確認するのが確実です。SKILL.md自身も「CLIは活発に開発中。ここに書かれたフラグがtraceway <command> --helpに出ないなら、バイナリを信じよ」と注意書きを置いています。

AI ObservabilityでLLM監視は何ができて、何ができないのか

ここが本記事の核心であり、もっとも誤解されやすい部分です。結論から書きます。TracewayのLLM監視は「受け取る」仕組みであって、「計装する」仕組みではありません。

公式ドキュメントのOpenRouter連携ページが、その構造を明快に説明しています。流れはこうです。

flowchart LR A["あなたのアプリ"] -->|LLM 呼び出し| B["OpenRouter
（モデルへルーティング）"] B -->|OTLP スパン
gen_ai.* 属性| C["Traceway
AI Traces"] C --> D["コスト・トークン
レイテンシ・会話内容"] A -.->|OTel SDK
同じトレース ID| C style C fill:#0f766e,color:#fff style B fill:#1e3a5f,color:#fff

ポイントは、計装しているのはTracewayではなくOpenRouter側だという点です。OpenRouterの観測機能が、補完（completion）ごとにgen_ai.*属性を持つOTLPスパンを送出します。Tracewayはそれを受け取って保存し、AI Tracesダッシュボードに表示する。ドキュメントが「SDKもコード変更も不要（No SDK or code changes needed）」と書けるのは、Traceway側が何も計装していないからです。

この構造から、強みと限界の両方が自動的に導かれます。

強み：ロックインが無い。 gen_ai.*はOpenTelemetryのGenAIセマンティック規約として標準化が進んでいる属性群です。つまりTracewayは「OpenRouter専用の連携」を作ったのではなく、標準に沿ったスパンを受ける口を開けているだけです。READMEが対応先を「OpenRouterおよび任意のOTel互換AIゲートウェイ」と書いているのはそのためです。ベンダー固有SDKに縛られない設計は、OmniRoute解説｜237プロバイダを1エンドポイントに束ねる無料AIゲートウェイとLiteLLM比較 のようなゲートウェイ層と組み合わせるときに効いてきます。

限界：AI連携の実装済みリストは、まだ薄い。 READMEの「Supported Integrations」を見ると、Backendは7つ、Frontendは6つ、Mobileは4つのフレームワークが並びます。対してAIの欄に載っているのはOpenRouterただ1つです。「任意のOTel互換ゲートウェイ」と書かれてはいるものの、手順が公式ドキュメント化されている経路は現時点でOpenRouterのみ、というのが正確な現状です。

そして、LLMOps固有の機能は存在しません。プロンプトのバージョン管理、評価（Evals）、データセット、実験の比較——Langfuseが備えるこれらの機能は、Tracewayの機能表のどこにもありません。Tracewayが提供するのは、あくまでLLM呼び出しをテレメトリとして観測することです。

取得できるものは具体的です。CLIの仕様書（SKILL.md）によれば、AIトレースは/ai-traces/<traceName>/<traceId>というルートを持ち、traceway ai-traces show <traceId>でトークン・コストの統計と会話の中身が返ります。設定面ではプライバシーモード・サンプリングレート・APIキーフィルタが用意されており、会話内容を保存したくない場合の逃げ道もあります。

「LLM監視ツール」として評価すると見誤る
TracewayのAI Observabilityを単体でLangfuseと比べると、機能数では勝負になりません。価値が出るのは「LLMのコストが、同じトレースIDでバックエンドのスパンやセッションリプレイと繋がる」という一点です。「このユーザーの操作 → このAPI呼び出し → このLLM呼び出しで $0.04 → ここで例外」が1本の線で追える。これは専用ツールを別に立てている限り手に入りません。
Traceway のスパンウォーターフォール画面。サービス横断でスパンが時系列に並ぶ
スパンウォーターフォール。AI トレースもこの同じトレース ID の体系に載るため、LLM 呼び出しとアプリの処理を1本の線で追える（出典: 公式リポジトリのスクリーンショット）

エージェント連携の設計：CLIとMCPサーバーが同じバイナリという答え

デモの裏側を支えているのが、Tracewayの「AI-First」セクションです。導入は1コマンドで済みます。

npx skills add tracewayapp/traceway

これでClaude Code・Cursor・Codex——SKILL.mdを読める任意のエージェントに、2つのスキルが入ります。

・/traceway-setup：リポジトリを読んで計装を配線する。バックエンドにはOTel、WebとモバイルにはTraceway SDK。そしてデータが実際に届いているかまで検証する
・/traceway：traceway CLIをインストールし、例外・ログ・エンドポイント・メトリクスを問い合わせる。バグ報告から根本原因まで

ここからが、設計として本当に面白い部分です。

発見1：CLIはエージェント向けに設計されている。 READMEは「The CLI is designed for agents first」と明言します。具体的には——パイプに繋がれたときはJSON、TTYではテーブルを出力。エラー識別子と終了コードが安定している。--fieldsでレスポンスを削れる。そして例外のアーカイブ以外は読み取り専用で、そのアーカイブすら明示的な--yesを要求する。SKILL.mdの「Ground Rules」はこれをさらに厳格に規定しています。「読み取りは安全：list／show／queryは自由に実行してよい。書き込みは明示的な指示を要する。『このエラーを見て』はアーカイブしろという意味ではない」。

エージェントに本番監視系を触らせるうえで、この権限の非対称性（読みは自由・書きは要明示）は理にかなった設計です。終了コードも branch しやすく整理されています（0=正常、4=認証、5=未検出、6=レート制限、7=サーバー5xx）。エラーは{"error":"<stable_id>","message":"...","hint":"...","exit_code":N}という安定した形でstderrに出るため、エージェントはerrorフィールドで分岐できます。

発見2：CLIとMCPサーバーは同じバイナリ。 SKILL.mdにはこう書かれています——「traceway MCPサーバーが接続されているなら、CLIを叩くよりそのツールを優先せよ。同じAPIを同じ意味論でラップしており、このスキルの知識はそのリソースとして利用できる。サーバーはこの同じバイナリだ（traceway mcp）」。

発見3：SKILL.mdは生成物である。 ファイル冒頭のコメントが種明かしをしています——「GENERATED FILE: assembled from cli/pkg/mcpserver/knowledge by cli/tools/skillgen」。つまりMCPサーバーの知識チャンクが単一の情報源で、そこからSKILL.mdが組み立てられている。

この3点を合わせると、Tracewayの狙いが見えてきます。

flowchart TD K["cli/pkg/mcpserver/knowledge
（単一の知識ソース）"] -->|skillgen| S["SKILL.md
/traceway・/traceway-setup"] K --> M["MCP サーバー
traceway mcp"] B["traceway CLI（同一バイナリ）"] --> M S -->|エージェントが読む| A["Claude Code / Cursor / Codex"] M -->|ツールとして呼ぶ| A B -->|シェル経由で叩く| A A -->|読み取りは自由 / 書き込みは --yes| T["Traceway（本番テレメトリ）"] style K fill:#0f766e,color:#fff style T fill:#1e3a5f,color:#fff

1つの知識ベースから、CLI・MCPサーバー・スキルという3つの表面が生えている——これが答えです。エージェントの接続方式（シェルを叩くのか、MCPを使うのか）が変わっても、意味論と知識は1か所に保たれる。MCPサーバーが実際にどんな通信をしているかを覗きたい方は MCPデバッグの通信を可視化するmcpsnoop｜MCP版Wiresharkでtool callを覗く も併せてどうぞ。

スキルの実体はskills/ディレクトリに置かれたただのMarkdownで、同じMITライセンスのリポジトリ内にあります。READMEはそこを強調しています——「マーケットプレイスも無い、ロックインも無い」。スキルをどう設計すると破綻しないのかという一般論は、ClaudeチームThariqが明かしたSkills設計9カテゴリ｜Anthropic社内で数百個動かす実践則 が参考になります。Tracewayの2スキルは、まさにこの「1スキル1ワークフロー・境界を明示する」型の実装例になっています。

LLM監視の観点で比較：Langfuse・Grafana+Tempo・Datadog

ここが最も正直に書くべき箇所です。「LLM監視ツールとしてTracewayが最良」とは言えません。比較軸を明確にすると、それぞれの立ち位置がはっきりします。

観点 Traceway Langfuse Grafana + Tempo/Loki Datadog
LLM専用機能（プロンプト管理・Evals・データセット） 無い 中核（専門） 無い LLM Observability製品として提供
LLMのコスト・トークン追跡 あり（gen_ai.*のOTLPスパンを受信） あり（専用SDK・詳細） 自前で構築が必要 あり
LLM計装の方法 他者が送るOTLPを受ける（OpenRouter等） 専用SDK＋OTel OTel Collector経由で自前 ベンダーSDK＋OTel
公式手順のあるAI連携先 OpenRouterのみ（＋OTel互換ゲートウェイ全般） 主要LLM SDKを幅広く — 幅広い
LLMとアプリ全体が同じトレースIDに載るか ○（1システム・1トレースID） △（LLM層が主） △（自前で配線すれば可） ○（ただし別製品の組合せ）
セッションリプレイとの接続 ○（同梱） × ×（別途） ○（別製品）
エージェントが直接問い合わせ可能 ○（CLI＋MCP＋公式スキル） △（API経由で自作） △（API経由で自作） △（API/連携経由）
ライセンス MIT（BSL・オープンコア無し） MIT＋一部有償機能 AGPL/Apache等の混在 プロプライエタリ
セルフホスト ○（docker compose up -d） ○ ○（複数OSSの組合せ） ×（SaaS）
構築の手間 1システム LLM層は容易・アプリ全体は別途 6ツールの糊付けが必要 言語ごとにベンダーSDK

この表から読み取るべきことは3つです。

1. 純粋なLLM監視の深さでは、Langfuseに分があります。 プロンプト管理・評価・データセット・実験管理を求めるなら、Tracewayは候補になりません。LLMアプリの品質を「評価して直す」ループとして回したいなら、その用途は専門ツールに任せるべきです。

2. Tracewayの差別化は「専門性」ではなく「地続きであること」です。 LLMのコストが、アプリのトレース・ログ・メトリクス・セッションリプレイと同じ画面・同じトレースIDに載る。Langfuseは（LLM層の専門ツールなので）アプリ全体は見ません。Grafanaスタックは配線すれば実現できますが、READMEが皮肉る通り「6つのツールを糊付けする」作業が要ります。Datadogは実現できますが、複数製品の組合せとプロプライエタリな課金が伴います。

3. 「エージェントが直接問い合わせられる」点は、現状ほぼ独自です。 LangfuseもGrafanaもDatadogもAPIは持っており、頑張れば同じことはできます。しかしTracewayは、公式スキル・MCPサーバー・エージェント向けCLIを最初から同梱しています。この差は機能表では小さく見えますが、実運用では「自作するかしないか」の差になります。

Traceway の正しい位置づけ
「LLM監視の専門家」ではなく、「エージェントから使える汎用オブザーバビリティのジェネラリスト」。LLM監視はその守備範囲に含まれる1機能であって、看板ではありません。Langfuse と競合させると負けますが、そもそも競合ではないと考えるのが正確です。両方を併用する構成（LLM評価は Langfuse、本番の全体観測は Traceway）にも矛盾はありません。
Traceway の Endpoints 画面。ルート単位のレイテンシ百分位とエラー率が並ぶ
Endpoints はルート単位の P50/P95/P99・スループット・エラー率を Apdex と5要素の影響度スコアでランク付けする。LLM 呼び出しもこの同じ基盤の上に載る（出典: 公式リポジトリのスクリーンショット）

Tracewayは使えるか：MIT・活性度・バス係数で判定する

OSSを本番に入れる判断は、機能表だけでは決まりません。実測値（2026年7月17日時点、GitHub API）で確認します。

判定軸 実測 評価
ライセンス MIT ◎ READMEも「No BSL. No open core.」と明言
スター ⭐1,023 ○ 若いプロジェクトとしては十分
コミット総数 819 ◎ 実体を伴う
リリース数 30（最新 cli/v1.9.1／2026-07-15） ◎ 継続的に出荷している
最終push 2026-07-16 ◎ 現役
作成 2025-12-18 △ 約7か月と若い
Fork / Issue 39 / 13 △ コミュニティはこれから
コントリビュータ 12人（うち1人が699/819＝約85%） ▲ バス係数は実質1
企業サポート Traceway Cloud（同じMITコードのマネージド版） ○ 収益源が存在する

◎の並びの中で、1行だけ▲があります。ここが最大の検討ポイントです。

バス係数（bus factor）は実質1です。 819コミットのうち699（約85%）がdusanstanojeviccsという単独の開発者によるものです。残りはGitHub Actionsのbot（78）、FrameAutomata（14）、traceway-bot（12）、jstojiljkovic（8）と続き、人間の実質的な共同開発者は数人にとどまります。Watch数（subscribers）も3です。

これが意味するのは単純です。この1人が離脱したら、開発は止まります。 MITライセンスなのでフォークは自由ですが、フォークして引き継げるかは別問題です。Goバックエンド＋SvelteKitフロント＋ClickHouse／SQLite／DuckDBの3系統ストレージ＋独自シンボリケーター——この規模を肩代わりできるチームは多くありません。

一方で、悲観に振り切るのも誤りです。判断材料を公平に並べます。

・「⭐だけ多い空リポジトリ」ではない：819コミット・30リリース・実験的機能を含む8領域の実装があり、実体が伴っている
・ライセンスの逃げ道が本物：BSLやオープンコアの留保がなく、全機能がMITで箱に入っている。将来のライセンス変更で人質に取られる構図が無い（過去に多くの監視OSSが辿った道と対照的）
・収益源がある：Traceway Cloudというマネージド版が併走している。「同じMITコードを我々が運用する」という建て付けで、機能を人質にしていない
・標準に乗っている：OTLPで受ける設計なので、仮にTracewayが止まっても計装side（アプリのOTel SDK）は捨てずに済む。これは移行コストを大きく下げる

最後の点は重要です。ベンダー固有SDKで計装していると、乗り換え時に全アプリの計装をやり直す羽目になります。OTelで計装してある限り、送り先を別のOTLPバックエンドへ向けるだけで済む。Tracewayを試すコストは、思ったより低いと言えます。

判定：どう使うか
・試す・サイドプロジェクト・社内ツール：積極的に候補。MITで全機能入り、OTel標準なので撤退も容易
・スタートアップの本番：条件付きで可。ただしバス係数1を経営リスクとして明示的に受け入れるか、Cloud版で運用を委ねるか
・大企業の基幹監視：現時点では推奨しにくい。単独開発・作成7か月・Watch 3という実態は、SLAを要求する用途とは噛み合わない
いずれの場合も、計装をOTel標準で行っておけば、判断を後から覆せます。

90秒セルフホストとLLM監視の接続手順

READMEの見出しは「Self-hosted in 90 seconds」です。手順自体は確かに2コマンドで、実際に検証しました。

git clone https://github.com/tracewayapp/traceway
cd traceway && docker compose up -d
# ✓ dashboard at http://localhost

起動後、任意のOTel SDKをhttp://localhost/api/otel/v1/traces（あるいは/metrics・/logs）へ向ければトレースが流れ始めます。Dockerイメージは Cosign で署名されています。

「90秒」を実測した（2026-07-17・編集部検証）
本記事の執筆にあたり、macOS＋Docker Desktop で実際に計測しました。結果は以下の通りです。
・初回（イメージ未取得の状態から）：178秒。ClickHouse と PostgreSQL のpullとアプリイメージのビルドが所要時間の大半を占めました
・2回目以降（イメージがキャッシュ済み）：7秒。3コンテナが healthy になるまで
・起動後、http://localhost は HTTP 200 を返し、ダッシュボードが表示されました
つまり「90秒」は誇張ではないが、初回は回線とマシン次第でそれを超える——というのが実態です。イメージさえ揃っていれば、体感は「90秒」よりむしろ速いと言えます。より軽く試すなら docker compose -f docker-compose.sqlite.yml up -d の SQLite 版（外部DB不要の最小構成）、または -f docker-compose.duckdb.yml の DuckDB 版（同じくゼロ依存で、列指向のテレメトリストアによりダッシュボードの余力が大きい）が用意されています。

起動後にhttp://localhostを開くと、次の初回セットアップ画面が出ます。以下は編集部が実際にセルフホストして撮影したものです。

セルフホストした Traceway の初回セットアップ画面。アカウント作成と最初のプロジェクト・フレームワーク選択を同時に行う
docker compose up -d 直後の http://localhost。アカウント作成と同じ画面で組織・プロジェクト・フレームワーク（Gin など）まで選ばせ、そのまま計装へ繋げる設計。タイムゾーンはブラウザから Asia/Tokyo が自動選択された（編集部が 2026-07-17 にセルフホストして撮影）

この画面が示す通り、初期設定はアカウント作成と最初のプロジェクト作成が1画面にまとまっています。ここでFramework（Gin・Node.js・OpenTelemetryなど）を選ぶと、次の画面でその言語向けの計装手順とプロジェクトトークンが提示される流れです。LLM監視を目的にするなら、ここで「OpenTelemetry」を選ぶのが公式ドキュメントの案内です。

なお、起動直後にhttp://localhost/api/otel/v1/tracesへ素のPOSTを投げると401が返ります（これも実測）。取り込みにはプロジェクトトークンが必要という設計で、想定どおりの挙動です。ダッシュボードで最初のプロジェクトを作り、発行されたトークンをOTelエクスポーターのヘッダに載せてから流し込んでください。

Goアプリなら、Dockerすら要らない組み込みモードもあります。go get github.com/tracewayapp/traceway/backendで取得し、自分のプロセス内でtracewaybackend.Run(...)をgoroutineとして起動する形です。裏側はSQLiteで、外部DBは不要。ローカル開発でオブザーバビリティを試すには、これが最短経路でしょう。

LLM監視（AI Observability）の接続は、公式ドキュメントによれば次の3ステップです。①Tracewayでプロジェクトトークンを取得する（プロジェクトが無ければ「OpenTelemetry」をフレームワークに選んで新規作成する）、②OpenRouter側の観測設定にそのトークンとエンドポイントを入れる、③Traceway側のAI Tracesで着信を確認する。アプリ側のコード変更は不要です。前述の通り、計装しているのはOpenRouterだからです。

プライバシーが気になる場合は、Privacy Mode（会話内容を保存しない）・Sampling Rate（送信割合の調整）・API Key Filter（特定キーのみ取り込む）が設定項目として用意されています。会話の中身が本番テレメトリに残ることを許容できない環境では、まずここを確認してください。

Traceway の Logs 画面。構造化ログがトレースに紐付いて検索できる
ログはトレースに紐付いており、ログ行から該当スパンへ直接ジャンプできる。エージェントが traceway CLI で読むのもこの同じデータ（出典: 公式リポジトリのスクリーンショット）

まとめ：Tracewayは誰のためのものか

Tracewayを評価する際、問いの立て方が結論を決めます。

「LLM監視ツールとして優れているか」と問えば、答えは「Langfuseほどではない」です。プロンプト管理も評価基盤もなく、公式手順のあるAI連携先はOpenRouter 1つ。LLMOpsの専門ツールとしては物足りません。

「AIエージェントが本番を調べられる観測基盤として優れているか」と問えば、答えは変わります。OTelネイティブで全部入り、MITで留保なし、CLIとMCPサーバーとスキルが1つの知識ベースから生えていて、読み取りは自由・書き込みは要明示という権限設計まで用意されている。この組合せを標準で持つ監視OSSは、現時点でほとんど見当たりません。

・向いている人：OTelで計装済み（またはこれから計装する）で、Claude Code等のエージェントに本番調査をさせたいチーム。LLMのコストをアプリ全体のトレースと地続きで見たいチーム。BSLやオープンコアの罠を踏みたくないチーム
・向いていない人：プロンプト評価・データセット管理といったLLMOps基盤が目的の人。SLAとベンダーサポートが必須の大企業基幹系。単独開発リスクを許容できない組織

そして冒頭のGIFへ戻ります。あのデモの本質は「AIが凄い」ことではありません。本番のテレメトリが、人間のスクロール前提のUIから解き放たれ、機械が読める形で開かれた——その一点です。監視ツールがエージェントを一級の利用者として設計に織り込み始めた、その最初期の実例として、Tracewayは見ておく価値があります。

参照ソース

・tracewayapp/traceway（公式リポジトリ） — README、機能一覧、技術スタック、Quick Start、比較表
・README.md（原文パーマリンク） — 「What’s in the box」8機能、「AI-First」、Supported Integrations（AI欄がOpenRouterのみである点の根拠）、Tech Stack
・skills/traceway/SKILL.md（原文パーマリンク） — /tracewayのフロー定義、Ground Rules（読み取りは安全／書き込みは要明示）、終了コード表、traceway mcpとの関係、生成元がcli/pkg/mcpserver/knowledgeである旨のコメント
・OpenRouter Integration（公式ドキュメント） — AI Observabilityの仕組み、gen_ai.*属性、Privacy Mode・Sampling Rate・API Key Filter
・Traceway 公式ドキュメント — セルフホスト、クライアントSDK、組み込みモード
・GitHub REST API /repos/tracewayapp/traceway および /contributors — スター1,023・819コミット・コントリビュータ内訳（699/819＝約85%が単独開発者）・最新リリースcli/v1.9.1。2026年7月17日 JST に編集部が取得した実測値
・OpenTelemetry Semantic Conventions for Generative AI — gen_ai.*属性の標準仕様

本記事の検証について
スター数・コミット数・コントリビュータ内訳は 2026年7月17日 JST に GitHub REST API から取得した実測値です。セルフホスト手順（初回178秒・キャッシュ後7秒・http://localhost が HTTP 200・OTLP エンドポイントが未認証で401）は、編集部が macOS ＋ Docker Desktop で同日に実行して確認しました。掲載しているセルフホスト画面のスクリーンショットは、その環境で撮影したものです。