藤田 拓 - ふじた たく
シニア・セールスエンジニア
2026年6月5日、Datadog Japan は現地・Zoom ウェビナーのハイブリッド形式のイベント「計装の標準化を知る Datadog における OpenTelemetry 活用事例の最前線」を開催しました。Datadog Tokyo オフィス（東京都千代田区 JPタワー19階）には現地参加者の方々が集い、Zoom ウェビナーを通じて全国から多くの方にご参加いただきました。
オープニングでは、司会の逆井（Datadog Japan セールスエンジニア）から一つの記念すべきニュースが紹介されました。OpenTelemetry が、2026年5月26日に CNCF の Graduated ステータスへと昇格したことです。「商用での利用がどんどん進んでいくことが期待されている。Datadog も対応を加速してきているので、それがこのイベントを企画した目的」という言葉とともに、イベントの幕が開きました。
セッション 1：Datadog × OpenTelemetry 入門と実践のあいだ
登壇者：戸松 研人（Datadog Japan - セールスエンジニア）
トップバッターは、Datadog Japan SE の戸松 研人による基礎解説セッションです。セッション冒頭では、参加者に Datadog や OpenTelemetry の利用状況を問いかける場面がありました。Datadog を活用している方は多く見られた一方で、Datadog と OpenTelemetry を組み合わせて使っている方はまだ少ない様子でした。セッションではまず、オブザーバビリティや OpenTelemetry の基本的な考え方を整理した上で、OTel Collector の構成パターンや、Datadog の新機能である Pipeline Visualization まで幅広く紹介されました。
OTel を使わない場合／使う場合
Datadog のみでトレースを取得する場合は、Datadog SDK で計装 → Datadog Agent が集約 → Datadog バックエンドへ送信という流れになります。一方 OTel を組み合わせる場合は、OTel API/SDK で計装 → OTel Collector の Processor で集約・加工 → Exporter で Datadog を含む任意のバックエンドへ送信という構成になります。OTel を使う利点として、計装の標準化（ベンダー非依存）・複数バックエンドへの同時送信・OTel Collector による柔軟なデータ加工の 3 点が挙げられました。
OTel Collector の構成パターン
OTel Collector には大きく 2 つの構成モードがあります。Agent モードはアプリと同じノードに Collector を配置し、ホスト名などのインフラ属性の付与に優れています。Gateway モードは中央集権的に Collector を立てることで、サンプリングや複雑な加工を一元管理できます。大規模環境では両者を組み合わせた多段構成（Agent ティア + Gateway ティア）が採用されますが、その分パイプライン管理が複雑化するという課題もあります。
注目の新機能：Pipeline Visualization
そういった課題を解決する機能として、Datadog が 4 月にリリースした Pipeline Visualization が紹介されました。OTel Collector のパイプライン構成を Fleet Automation 画面からビジュアルで確認できる機能で、Logs・Metrics・Traces それぞれのパイプラインが直感的に把握でき、どこでどの程度のデータ流量があるかも一目でわかります。「現在はパイプラインの可視化機能であるが、ロードマップ上では、パイプラインをUIから構成変更する機能も検討されている。続報をお楽しみに」という言葉でデモを締めくくりました。
参考：Datadog × OpenTelemetry 公式ドキュメント
セッション 2：ABEMA の Datadog × OTel 基盤、中から見るか？外から見るか？
登壇者：山本 哲也 様（株式会社 AbemaTV - SRE）
2021年入社後、SRE としてサービス全体の信頼性向上を担われている 山本 哲也 様が、ABEMA のオブザーバビリティ基盤刷新の全貌を語ってくださいました。
なぜ OTel × Datadog を選んだのか
ABEMA のマイクロサービス構成は 2018年から急速に拡大し、2023年時点では「人間にはもはや理解できないほど複雑」な依存関係になっていました。現在 Datadog で監視しているものだけでも、約 120 のサービスが存在しており、「このサービスマップ、意味もなく見るのが好きで」と笑いを誘いつつ、「人間が一個ずつログを見ていくだけでは対応できない」というリアルな課題も。
OTel を採用した最大の理由はベンダーロックイン回避です。「円高や物価上昇でサービスコストがどうなるかわからない。最悪 ABEMA が自前で運用できる状態を担保した上で、使いやすい SaaS を使う」という考え方が根本にあります。さらに、2024年に Datadog が OTel コミュニティへのコミットメントを明確にしたプレスリリースを出したことも後押しになったとのことでした。
DDOT × 多段構成によるコスト最適化
現在の構成は、マイクロサービス → OTel SDK → DDOT（Datadog Distribution of OpenTelemetry Collector） → OTel Collector（Gateway）→ Datadog という多段パイプラインです。ピーク時には毎秒 165 万スパンというトラフィックが発生するため、「全部 Datadog に取り込もうとすると大変な金額になる」と明かし、Gateway におけるテールベースサンプリングによるコスト最適化が不可欠だと説明しました。
また DDOT を使うことで「Datadog が Trace Metrics の生成などをサポートしてくれるので、その部分の設計を Datadog に任せて、ABEMA が本当に欲しいトレースデータの収集に集中できる」というメリットも強調されました。過去 3 年間で 4 つのオブザーバビリティツールを本番環境で切り替えた実績があり、いずれも「環境変数の変更だけでアプリケーション側には一切手をつけずに切り替えられた」と振り返りました。
利用者側へのメリットと組織展開
OTel の知見は Datadog にとどまらず AWS・Google Cloud など他クラウドベンダーにも共通して活用でき、「Claude Code もトークン使用量を OTel 形式で出力できるので、将来的には Datadog に送って確認することもできる」と今後の展望を紹介されました。SRE 4 名という少人数でも各チームへのファシリテーションを進め、各チームが自律的にオブザーバビリティを活用できる文化づくりを目指しているとのことです。
DDOT を使って Trace Metrics の生成を Datadog に任せつつ、その後段の OTel Collector で独自のサンプリング戦略を自由に組む。OTel と Datadog をそれぞれの強みが活きる場所で使い分けることで、コストと観測性を両立されている素晴らしい実践例でした。
参考：Datadog Distribution of OpenTelemetry Collector（DDOT）ドキュメント
セッション 3：多言語環境での計装戦略と実践 OpenTelemetry × Datadog APM
登壇者：見形 親久 様（株式会社ログラス - クラウド基盤チーム）
「良い景気を作ろう」をミッションに掲げ、経営管理 SaaS を提供するログラス。クラウド基盤チームで SRE の推進と開発を担われている 見形 親久 様が、4 言語環境での OTel 統一計装という多くの組織が直面しうるリアルな課題への取り組みを紹介してくださいました。
当初は Datadog SDK で困っていなかった
もともとログラスは Kotlin を中心に Datadog SDK を使っていたため、特段の課題はありませんでした。ところが一部のアプリケーションに Rust が採用され、「Datadog SDK は Rust をサポートしないため OTel を使わざるを得なかった。当時の Datadog はトレースIDの体系が OTel と異なっており、トレースIDを変換するコードを書いていた」と明かし、当時はアプリケーションがバックエンドの仕様に依存してしまう問題が生じていました。 （筆者注: 現時点では Rust SDK の提供（Preview）および OTel との トレースID 体系の統一、いずれも対応済みです）
プロダクト拡大 × マイクロサービス化 × 実装言語多様化
その後、事業拡大に伴いプラットフォームが EKS へ移行し、モノリスから完全なマイクロサービスへとリアーキテクトする大きな転換がありました。この過程で Go と TypeScript が加わり、Kotlin・Rust・Go・TypeScript の 4 言語のサポートが必要になりました。「2 言語から 4 言語になってサービス数も一気に爆発的に増えたので、計装基盤をゼロから再構築する必要があると判断した」と、見形様は振り返ります。
言語ごとの自動計装
そのような背景からスタートした計装基盤の再構築ですが、「思っていたより苦労はしなかった」というのが見形様の正直な感想だったようです。Kotlin（JVM）は自動パッチで計装コードが挿入されるため「ほぼ何もしていない」、TypeScript も Monkey Patch でほぼ自動、Go はミドルウェアの設定、Rust は手動での設定が必要ながら決まったパターンで対応できます。Datadog Agent 側もほぼワンライン設定で OTel サポートが有効になるため「悩む部分は少なかった」とのことです。
はまりどころ 2 選
最後に自動計装におけるはまりどころを 2 つ、紹介がありました。
Fat JAR + Shadow JAR 問題：gRPC 関連ライブラリのパスをリロケートした結果、JVM の自動計装が計装先のクラス名を見つけられず、gRPC インターセプターを自動で差し込めなくなりトレースが途切れる現象が発生。gRPC インターセプターを手動で差し込む対応を採用しました。
言語間での OTel SDK 対応速度のズレ：W3C TraceContext Level 2 の Random Flag への追従が Kotlin（対応）と Rust（非対応）で異なり、Kotlin から Rust に渡るスパンが途切れる問題が発生。Rust 側のリリース前パッチを利用して対応しました。
「OTel はデータの出し方であり、Datadog はデータの使い方を提供する基盤。OTel で綺麗なデータを送り、Datadog に集約することで最大の価値が出る」。セッションを締めくくった見形様の言葉が印象的でした。複数言語が混在する環境での実装上のはまりどころも赤裸々に共有いただき、非常に参考になるセッションでした。
参考：Datadog APM と OpenTelemetry の連携
セッション 4：AI プラットフォームを「運用し続ける」ための可観測性 OpenTelemetry × Datadog による実践
登壇者：谷村 祐樹 様（株式会社 LayerX - Ai Workforce 事業部 SRE）
大トリは、LayerX でエンタープライズ向け AI プラットフォーム「Ai Workforce」の SRE を担う 谷村 祐樹 様。AI エージェント時代のオブザーバビリティという最先端テーマに切り込みました。
AI エージェントが変えるオブザーバビリティの難しさ
従来のウェブシステムでは「何が起きたか」をメトリクス・ログ・トレースで把握できました。しかし AI エージェントを扱い始めると、リクエスト内で完結しない非同期処理が増え、エージェントが判断してツールを呼び出したり LLM に問いかけたりと処理が複雑化します。「最終回答だけ見ていても改善できない。なぜその判断をしたのかを見る必要がある」と問題を整理しました。
運用しやすいAI エージェント 3 つの状態
その上で AI エージェントが運用しやすい状態とはどういった状態のことなのか、LayerX での実例ベースでお話しいただきました。
説明できる状態：エージェントのワークフロー全体（検索結果の妥当性、ツール選択の判断、LLM の推論内容）をトレースで可視化する。
安全に調査できる状態：エンタープライズ顧客の機密情報（プロンプト・レスポンス・ドキュメント内容）をマスクした上で本番調査できる体制を整える。
チームで扱える状態：SRE だけでなく SWE・QA・FDE（顧客伴走型エンジニア）など全員が同じ情報をもとに調査・改善できるようにする。
OTel × Datadog による実装
フロントエンド（API）とバックエンド（ワークフローエンジン）はイベントストリームを挟んだ非同期構成なので、それぞれ別トレースとして作成し、OTel Span Links で紐づけるアーキテクチャを採用しているそうです。LLM の内部動作は Datadog Agent Observability で確認でき、谷村様は「オーケストレータエージェントが動いてサブエージェントが呼ばれて、インプットとアウトプットが一目でわかる。どこの判断が悪いのか一瞬で分かる」と、その機能を評価していました。機密情報はスパン転送前にマスク処理を入れ、本番環境でも安全に調査できるよう、きめ細やかに設計されていました。
"おてすき" SRE エージェントとコーディングエージェントの活用
チームで扱える状態を実現する工夫として会場の注目を集めたのが、社内 SRE エージェント「オテスキー」です。Datadog モニターがアラートをトリガーすると、このエージェントが Datadog MCP やソースコードを参照して「どこが怪しいか・トレースはどれか」を自動でレポートします。SWE が SRE に問い合わせることなく自律的に調査・実装に入れる体制を実現しており、「FDE やお客様と対面しているメンバーも、お客様からのフィードバックを自分で調査して一次回答できる」とのことです。さらに OTel 計装用の共通パッケージや、コーディングエージェント用のガードレールの整備も進めています。
AI エージェントによる開発は昨今のトレンドですが、それに伴って、AI エージェントの運用やオブザーバビリティの重要性もますます高まってきています。これから多くのお客様が直面するであろう課題に対する価値ある事例をご紹介いただきました。
参考：Datadog Agent Observability と OpenTelemetry
各セッションを通じて見えた共通テーマ
司会の逆井が閉会の言葉でまとめたとおり、「オブザーバビリティには、様々な現場における様々なプラクティスがある。事例を学び、自社に適したオブザーバビリティを検討する糧にしてもらうことが重要」というのが本イベントの核心でした。各セッションを通じて、以下の共通テーマが浮かび上がりました。
OTel によるベンダーニュートラルな計装の重要性
3 社とも「ベンダーロックインを避けつつ、Datadog のいいとこ取りをする」という姿勢で OTel を採用しています。ログラス 見形様が「OTel はデータの出し方、Datadog はデータの使い方」と端的に表現したように、両者は対立するものではなく相互補完する関係です。
コストと観測性の両立
ABEMA 山本様の事例「ピーク時 165 万スパン/秒」という数字が象徴するように、大規模環境ではテレメトリデータのコスト管理が避けられない課題です。テールベースサンプリングと多段 Collector 構成の組み合わせは、その一つの解決策となります。
組織全体へのオブザーバビリティ展開
導入だけでなく、開発者・運用者・顧客対応チームまで含めた組織全体での活用が、オブザーバビリティの本来の価値を引き出します。LayerX 谷村様の「SRE エージェントを使って全チームが調査できる」、ABEMA 山本様の「SRE 4 名で 120 サービスを横断支援する」といった取り組みは、その先進的な実例です。
最後に
今回は「計装の標準化を知る Datadog における OpenTelemetry 活用事例の最前線」の開催レポートをお届けしました。登壇をご快諾いただき、現場ならではの赤裸々な知見を共有してくださった山本様、見形様、谷村様、本当にありがとうございました。また、対面・オンラインを問わずご参加いただいたすべての皆様に感謝申し上げます。
Datadog Japan では今後もこのような実践的なイベントを開催してまいります。ご興味のある方はぜひ イベント & ウェビナーページ をご確認ください。
また、初めてDatadogをご利用になる方は 14日間の無料トライアル をご利用ください。
