AI自動化ワークフローの可観測性とは、各処理の実行過程をトレースとして記録し本番の挙動を追える状態のこと。
AIエージェントやRAGを組み込んだ自動化フローは、ノードが増えるほど中身が見えなくなります。「昨夜のバッチが途中で止まった」「なぜか実行が遅い日がある」——ログを開いても、どのノードで何秒かかり、どこで失敗したのかまでは追えないことが多いのではないでしょうか。この不透明さを解消する考え方が可観測性であり、n8nはその実装手段としてOpenTelemetryのネイティブ対応を持っています。言葉の意味から実際の設定・送信先・限界までを整理します。
- 可観測性とは、ワークフローとノードの実行をトレース（スパン）として記録し本番の挙動を追える状態のこと
- n8nは実行トレースをOpenTelemetryでネイティブ出力でき、無料のCommunity Editionを含むセルフホスト環境で利用可能（カスタムスパン属性のみEnterprise限定）。設定は環境変数のほか、n8n 2.27.0以降はセルフホスト版のSettings画面からも可能
- 対象はワークフロー/ノード実行の可観測性であり、LLMのトークン数・コストの自動取得は現時点で未対応（公式が開発中と明言）
AI自動化ワークフローの可観測性とは：一言で言うと
AI自動化ワークフローの可観測性とは、ワークフロー全体と個々のノード実行を「スパン」という単位で記録し、どのステップにどれだけ時間がかかり、どこで失敗したかを外から観測できる状態を指します。監視という言葉が「稼働しているかどうか」の生死確認に近いのに対し、可観測性はもう一段深く、内部で何が起きたかを事後に辿れることに主眼を置いた概念。英語ではobservability（オブザーバビリティ）と呼ばれます。
自動化ツールにおける可観測性の中心にあるのがトレースです。1回の実行が入口から出口までどう流れたかを、時系列の木構造として残す。この木の各枝が「スパン（span、処理の一区間を表す記録単位）」で、親スパンの下に子スパンがぶら下がる形で全体像を描きます。n8nの場合、ワークフローの実行1件が親、その中で動いた各ノードが子、という関係になります。
なぜ「ログ」ではなく「トレース」なのか。ログは1行ごとの点の記録で、全体の流れやノード間の時間配分を再構成しにくい。トレースは実行の因果関係と所要時間を構造として保持するため、「どのノードが遅延の原因か」「どこでリトライが走ったか」を一目で切り分けられます。AI自動化のように分岐やループ、外部API呼び出しが絡む処理ほど、この構造化された記録が効いてきます。
仕組みをもう少し詳しく：n8nのOpenTelemetryトレース対応
n8nのOpenTelemetryトレース対応とは、ワークフロー実行とノード実行の記録を、OpenTelemetryという可観測性の標準規格に沿ってそのまま外部へ出力できる機能のこと。要するに、n8n内部の実行記録を「共通フォーマットのトレース」に変換して吐き出す仕組みです。公式ドキュメントはこの機能を「開発中（still under development）」と位置づけており、トレース自体は利用できますが、OpenTelemetry形式のメトリクス出力は今後対応予定（coming soon）とされています。
まず土台となるOpenTelemetry（OTel）から。OpenTelemetryはCNCF傘下の可観測性オープン標準で、かつて別々に存在したOpenCensusとOpenTracingが統合されて生まれました。トレース・メトリクス・ログを共通の形式で扱えるようにするのが狙いで、既定のコンテキスト伝播にはW3C Trace Context（後述のtraceparentヘッダ）を採用しています。特定ベンダーに縛られず、対応する監視基盤ならどれにでも送れるのが最大の利点。
n8nはこのOTelにネイティブ対応しており、設定に応じて2種類のスパンを出力します。ひとつが workflow.execute で、ワークフロー実行1件ごとの親スパン。もうひとつが node.execute で、各ノードの実行を表す子スパンです。子スパンは親のワークフロースパンにネストされるため、1回の実行が「ワークフロー → 各ノード」という階層で残ります。
それぞれのスパンが持つ情報も決まっています。workflow.execute スパンはworkflow ID・name・version・ノード数・実行モード・ステータス・エラー種別を記録。node.execute スパンはnode ID・name・type・version・入出力アイテム数を記録します。OpenTelemetryによるワークフロー／ノード実行のトレースはn8n 2.19.0から利用でき、この記事で説明する環境変数・2種のスパン・W3C伝播を含む構成が公式ドキュメント（Trace executions with OpenTelemetry）に明記されています。
ここで、混同しやすい境界を明示します。
node.execute スパンが持つのは汎用フィールドと入出力アイテム数であって、トークンやコストの自動記録は含まれません。トレースの中身と送信先：span種別・OTLP・W3C伝播
n8nのトレースは、出力された2種類のスパンをOTLPという規格で外部の観測基盤へ送り、W3C Trace Contextで外部呼び出しとも繋げる、という経路で動きます。ここが可観測性を「絵に描いた餅」で終わらせないための実装の核です。
有効化の入口は環境変数です。最小構成は2つで足ります。トレースそのものを有効にする N8N_OTEL_ENABLED=true と、送信先を指す N8N_OTEL_EXPORTER_OTLP_ENDPOINT。後者にはOTLPコレクタのエンドポイントを渡します。公式ブログの例ではOTLP/HTTPのポートとして4318番が使われています。なお既定では本番（production）実行のみがトレース対象です（N8N_OTEL_TRACES_PRODUCTION_ONLY=true、n8n 2.25.2以降で利用可能）。エディタからの手動実行やテスト実行も見たい場合は false に変更する必要があります。
# トレースを有効化
N8N_OTEL_ENABLED=true
# 送信先（OTLPコレクタのエンドポイント。ポート例は 4318）
N8N_OTEL_EXPORTER_OTLP_ENDPOINT=http://<collector>:4318
# 出力量を絞りたい場合（0〜1、既定は全トレース出力）
N8N_OTEL_TRACES_SAMPLE_RATE=0.2
# ワークフローレベルのスパンだけにしてノードスパンを止める場合
N8N_OTEL_TRACES_INCLUDE_NODE_SPANS=falseN8N_OTEL_EXPORTER_OTLP_ENDPOINT にはコレクタのbase URLを指定します。n8nが既定で /v1/traces を付加するため、URLに /v1/traces まで含めないよう注意してください。トレース量が多すぎると感じたら、N8N_OTEL_TRACES_SAMPLE_RATE で間引けます。取り得る範囲は0〜1で、既定は全トレース出力。ノード単位のスパンが不要なら N8N_OTEL_TRACES_INCLUDE_NODE_SPANS=false でワークフローレベルのスパンのみに絞れます。環境変数を触りたくない場合の選択肢もあり、UIからの設定（Settings > OpenTelemetry）はn8n 2.27.0以降で可能。ただし操作できるのはinstance owner/adminのみです。UIでの変更は再起動なしで反映され、queue modeではworkerやwebhook processorにも設定が再読み込みされます。
どのバックエンドに送れるか
送信先は、n8nが送るOTLP/HTTP（Protobuf）を受けられるコレクタやバックエンドであることが条件です。公式で名前が挙がっているものとして、Jaeger・Tempo・Datadog・Honeycomb・New Relic・Grafana Cloudがあります。ここで重要なのは、これらは例示であって「対応先の全て」でも「排他的な選択肢」でもない点。公式の立場は「任意のOTLP互換バックエンド」で、列挙されたものはあくまで代表例です。既にどれかを社内で運用しているなら、n8nのエンドポイントをそこへ向けるだけで実行トレースが流れ込みます（認証が必要なコレクタでは認証ヘッダとネットワーク到達性も確認してください）。なお外部SaaSやサードパーティの観測基盤に接続先を向けると、span属性・実行メタデータ・失敗時の例外メッセージ/スタックトレース・設定したカスタム属性がその送信先に渡ります。認証トークンは環境変数に直書きせず_FILE形式での分離を検討し、秘密情報や本文データをspan属性・例外メッセージに含めない設計にしてください。
W3C Trace Context で外部APIまで辿る
自動化が価値を持つのは、たいてい外部サービスと繋がるから。その繋がりの先までトレースを延ばすのがW3C Trace Contextです。仕組みはシンプルで、traceparent というHTTPヘッダにトレースの識別情報を載せてリクエスト間で受け渡します。n8nでは、Webhookで受けたリクエストの traceparent がワークフロースパンの親になり、逆にHTTP Requestノードなどn8nのHTTP helpersを使うノードが外部へ発信するときは、送信リクエストに既定で traceparent/tracestate を注入します（N8N_OTEL_TRACES_INJECT_OUTBOUND=false で無効化可能）。下流サービス側もW3C Trace Contextを受け取って継続する必要があります。
これにより、上流のシステムから飛んできた実行と、n8nが呼び出した下流のAPIが、1本のトレースとして繋がる。サブワークフローについても同様で、呼び出されたサブワークフローのスパンは呼び出し元ワークフローのスパンに親付けされます。複数のワークフローや外部サービスをまたいだ処理でも、全体を1つの木として追えるわけです。
可観測性が診断に効く具体シーン
可観測性が特に有効なのは、原因が見えないまま止まった処理を切り分ける場面です。node.execute スパンがノード単位の所要時間と状態を残しているため、「実行が遅い/失敗した」という漠然とした症状を、特定ノードの問題まで絞り込めます。
具体的に詰まりやすいのが、外部APIから巨大なJSONを取得するRAG系のパイプラインです（一例として）。たとえば新しい研究トピックの登録をトリガーに、学術データAPIから論文の全文やメタデータを引いてベクトルストアへ流し込む、といった構成です。この手のフローでは、1バッチのレスポンスが数MB規模に達することがあり、メモリ消費と処理時間が跳ね上がります。HTTP Requestノードで長時間実行になればタイムアウトのリスクが増し、リトライ設計を誤ると同じ重い処理を何度も繰り返してさらに詰まる。
ここでトレースがあると、切り分けが大幅に速くなります。ワークフロースパンの下に並ぶノードスパンを見れば、時間を食っているのがHTTP Requestノードなのか、埋め込み処理のノードなのか、ベクトルストアへの書き込みなのかが所要時間で分かる。失敗したときも、どのノードでステータスがエラーに変わったか、エラー種別が何かがスパンに残るため、「どこで止まったか」を推測せずに特定できます。原因のノードが分かれば、タイムアウト値の見直しなのか、データ分割の追加なのか、打つ手も具体的になります。復旧が速いというのは、この「当たりを付ける工程」が消えるということ。
AI Agentノードを含むワークフローでも同じで、エージェントを1つのノードとして見れば、そのステップにどれだけ時間がかかったかは追えます。ただし前述のとおり、エージェント内部のLLM呼び出しやツール呼び出しの細粒度までは現時点で見えません。「ノード単位までは診断できる／その内側は今後」という線引きを持っておくと、期待値のズレを避けられます。
セルフホスト前提での選択と本番グレード運用
n8nのOTelトレースは、セルフホスト版で環境変数、またはn8n 2.27.0以降ならUI（Settings > OpenTelemetry）から有効化できます。このOpenTelemetry実行トレースはセルフホスト版で利用できる機能で、n8n Cloudでは提供されていません（2026年7月時点、公式ドキュメント準拠）。自前のJaegerやTempoなど社内運用の観測基盤にトレースを閉じたまま組めるのは、インフラを自分たちで持つセルフホスト運用の強みです。
ビジネス自動化のプラットフォームはいくつか性格が分かれます。n8nはセルフホストで実行あたりのコストを抑えやすく、データを自社管理下に置ける方向。一方でMakeやZapierなどのSaaS型サービスは、creditsやtasksといった利用量に応じてコストが増える料金構造を持ちます。Makeはcredits消費、Zapierはtask従量課金という公式料金体系のため、具体的な単価や損益分岐は運用条件で大きく変わり、自社のワークフロー数で見積もるのが確実です。ここでは金額そのものより「コストが実行量にどう連動するか」という構造の違いを押さえてください。
n8n・Make・Zapier の位置づけ
可観測性の観点で3者を並べると、どこに向いているかが見えてきます。
| 比較項目 | n8n（セルフホスト） | Make | Zapier |
|---|---|---|---|
| ホスティング形態 | セルフホスト可（クラウド版もあり） | クラウドSaaS中心 | クラウドSaaS中心 |
| コスト構造 | Community Editionは自前インフラ費中心。有償Self-hosted（Business/Enterprise）は月間workflow executions枠＋超過課金 | credits消費型 | タスク従量課金型 |
| データ主権 | 自社管理下に置きやすい | 提供元基盤に依存 | 提供元基盤に依存 |
| トレース連携 | OpenTelemetryネイティブ対応（セルフホスト版、Community Editionを含む） | 提供機能に準拠 | 提供機能に準拠 |
| 向くケース | 自前の観測基盤で本番運用したい場合 | 手早く連携を組みたい場合 | 定番アプリ連携をSaaS上で手早く試したい場合 |
自前の観測基盤で本番のトレースを完結させたいなら、選択肢はセルフホストのn8nに寄ります。OTLPで自社のJaegerやTempoへ送り、可観測性のデータを外に出さずに運用できるからです。逆に、まず動くものを最短で作りたい段階なら、SaaS型の手軽さが勝る場面もある。可観測性を本番の要件に据えるかどうかが、分岐点になります。
本番グレードの運用は、トレースを有効化して終わりではありません。n8nの実践的なカリキュラム（In Practiceコース）でも、AI Agentノードの活用と並んで、ワークフローのテスト・デバッグ手法、他者が扱えるように整理・ドキュメント化する保守性が扱われています。トレースはそのうちの「動いている本番を観測する」層を担うパーツ。テストで壊れないことを確認し、ドキュメントで引き継げるようにし、可観測性で本番の挙動を追う——この3つが揃って初めて、本番で通用するワークフローになります。
| 対応 | ワークフロー/ノード実行のトレース（OpenTelemetryネイティブ） |
|---|---|
| span種別 | workflow.execute / node.execute の2種 |
| 初出バージョン | OpenTelemetryトレースは2.19.0から、production-only既定は2.25.2以降、UI設定は2.27.0以降 |
| 送信 | OTLPでOTel対応バックエンドへ（Jaeger / Tempo / Datadog / Honeycomb / New Relic / Grafana Cloud 等） |
| プラン | 実行トレースは無料のCommunity Editionを含むセルフホスト環境で利用可能（設定は環境変数、またはn8n 2.27.0以降はSettings画面から）／カスタムスパン属性のみEnterprise |
告知の中で、この「プランの線引き」ははっきり示されています。
Everything else shown in the video is available on all plans, including the free self hosted community edition.（動画で示したその他の機能は、無料のセルフホスト・コミュニティ版を含む全プランで利用できる）
— n8n公式告知 https://community.n8n.io/t/you-can-now-use-opentelemetry-with-n8n-production-tracing-for-workflows/301524
ここでの「その他」とは、直前で触れたカスタムテレメトリタグ（Enterprise限定）を除く、という意味です。
カスタムスパン属性（custom telemetry tags）はEnterpriseプラン限定で、告知動画では02:05の箇所で示されました。適用範囲もバージョンで分かれ、ノード単位のカスタム属性が2.22.0から、プロジェクト/ワークフロー単位が2.24.0から。LLMのモデル名や入出力トークン数がワークフロー内のデータとして取得できる場合は、Enterprise限定のカスタムスパン属性へ式を使って設定できます。ノード単位では各ノードのSettingsから追加でき、カスタムノードの実装は必須ではありません。ただし、n8nのネイティブOpenTelemetryトレースがこれらの値を自動収集するわけではありません。
まとめ
AI自動化ワークフローの本番監視の土台となる可観測性とは、ワークフローとノードの実行をスパンとして記録し、本番の挙動を後から辿れる状態のことでした。n8nはこれをOpenTelemetryでネイティブに出力でき、workflow.execute と node.execute の2種類のスパンをOTLPで自社の観測基盤へ送れます。HTTP Requestノードなどn8nのHTTP helpersを使う外部呼び出しではtraceparentを注入でき、下流サービス側もW3C Trace Contextに対応していれば、n8n外の処理と同じトレースとして関連付けられます。実行トレース自体は無料のCommunity Editionを含むセルフホスト環境で使え（設定は環境変数のほか、n8n 2.27.0以降はSettings画面から）、Enterprise限定なのはカスタムスパン属性だけ。ただし対象はワークフロー/ノード実行の可観測性にとどまり、LLMのトークン数・コストの自動取得は開発中で未対応という線引きは、導入前に必ず押さえておきたいところ。
進め方としては、まずn8nを2.19.0以降（UI設定なら2.27.0以降）に更新し、N8N_OTEL_ENABLED と送信先エンドポイントの環境変数だけで実行トレースを有効化してみる。次に既存のJaegerやTempoなどOTel対応の観測基盤へ向け、遅延や失敗が起きたときにノード単位で切り分けられる状態を作る。これで、AI自動化の「どのノードで何が起きたか見えない」問題に、具体的な観測手段で対応できます。
よくある質問
Q. n8nの無料版でもOpenTelemetryトレースは使えますか？
使えます。ワークフロー/ノード実行のトレース機能は、無料のCommunity Editionを含むセルフホスト環境で利用できます。Enterprise限定なのはカスタムスパン属性（custom telemetry tags）のみです。設定は環境変数のほか、n8n 2.27.0以降はセルフホスト版のSettings画面（Settings > OpenTelemetry）からも可能です。
Q. どのバージョンから対応していますか？「2.22.0が必要」と聞きましたが？
OpenTelemetryによるワークフロー／ノード実行のトレースはn8n 2.19.0から利用できます。production実行のみに限定する設定は2.25.2以降、UIからの設定（Settings > OpenTelemetry）は2.27.0以降で利用可能です。なお2.22.0はEnterpriseのノード単位カスタム属性が加わった版です。
Q. LLMのトークン数やコストも自動で見えるようになりますか？
2026年7月時点では自動取得に未対応です。ネイティブトレースの対象はワークフロー/ノード実行で、AI Agentノード内部のLLM呼び出しまで追う細粒度トレースは公式が開発中と位置づけています。必要な場合は、ワークフロー内で取得した値をEnterprise限定のカスタムスパン属性へ式で設定します。逆に言えば、LLM呼び出し単位の可観測性（トークン数・生成内容・呼び出しコスト）が主目的なら、それはn8nネイティブトレースの外側で解決する別レイヤーの話です。n8nのトレースは「どのノードで詰まったか」までを担い、その内側のLLM可観測性は別立てで組む、と二層で捉えると探す道具を間違えません。
参考資料
- n8n公式ドキュメント: Trace executions with OpenTelemetry
- n8n公式ブログ: Trace n8n workflow and node executions with OpenTelemetry
- n8n Community: You can now use OpenTelemetry with n8n（告知）
- n8n Community: N8N103 In Practice: AI, Testing & Best Practicesコース
- OpenTelemetry公式: What is OpenTelemetry?
- OpenTelemetry公式: Context Propagation
- W3C: Trace Context仕様
- OpenTelemetry: 分散トレーシング解説（Uptrace、補足記事）
