はじめに
先日、Datadog Live Tokyo 2026に参加してきました！
業務でDatadogを使用していることもあり、イベントで得たことや考えたことを参加メモとしてアウトプットしようと思います。
このイベントは、Datadogを使用している企業による取り組みの紹介と、オブザーバビリティの最新動向・AIネイティブ時代のIT開発・運用の取り組みや実践方法を共有するというイベントでした。
- イベント名:Datadog Live Tokyo 2026
- 開催日時:2026年5月20日
- 場所:東京国際フォーラム
公式Webサイト
想定する読者
- Datadogを業務で使用している方
- オブザーバビリティに興味がある方
- AIネイティブ時代のIT開発・運用に興味がある方
- Datadog Live Tokyo 2026に参加できなかった方
ピックアップセッションのレポート
New to Datadog（入門編）
このセッションでは、なんとなくの理解だった「オブザーバビリティ」や「トレース」という言葉について、理解を深めたり、AIを使用した運用についてお話がありました。
-
オブザーバビリティ
オブザーバビリティとは、「システムが出力したデータから、システムの内部で何が起きているかを理解する力」のことです。日本語では「可観測性」と呼ばれることもあります。
ここで、大事なことは、「システムが出力した様々な種類のデータを多角的に分析し、システムの内部状況を理解し、エンジニアが次のアクションを行えること」と言うことができそうです。
例でも紹介されていましたが、CPU使用率が90%を超過していたとしても、ただ単にリソースを効率よく使えているだけかもしれません。
この場合のように、データを単体で見るだけではシステム内部の状況を分析することはできず、アクションが必要な事象であるかを判断することはできません。
オブザーバビリティについては、「システム内部の状況を理解すること」までは知っていたのですが、「次のアクションを行える」と言い換えることで、
オブザーバビリティの重要なポイントがわかりやすくなったと感じました。
-
テレメトリデータのトレース
テレメトリデータのPrimary Signalsの1つであるトレースについても学びがありました。
Primary Signalsについては以下を参照
トレースとは、「１つのリクエストが投げられた時にシステム内部で行われた、個々の処理の順番や個々の処理ごとの成功可否をリクエスト毎に記録したもの」です。ユーザがサービスを使用した時のアクションを記録したものといえそうです。
このトレースを分析することで、ユーザがサービスを使用した時のアクションを分析することができます。聞いた感じだと、すごく便利な指標な気がしますね。
APMのTrace画面を見ることで、サービスの各コンポーネントがマップ化されているので、Datadogをハブにすることで、アプリチームとインフラチームが個々に調査を行い、伝言ゲームのズレが起きるというあるあるを防ぐことが出来そうです。
実際に、DatadogのRUMでのデモ画像を見ましたが、ユーザーからのバグ報告などがあったときに、「ユーザーの操作がまとまっている＝ユーザーの操作を再現できる」ので開発者にすごく重宝される指標な気がしました。Traceもだけど、RUMもすごい。。
ちなみにRUMは、フロントエンドの処理をDatadogに取り込み、Datadog内で再構成しているそうです。
業務では、まだAPM、RUMなどのアプリケーション関連の機能を触れていないので、触ってみたいと思います。
Datadog RUMのページ
-
Bits AI SREでの初動対応の時短化
Monitor発火と同時にBitsが調査を開始し、調査内容をslackなどで報告したり、Notebookにレポートとして出力させたり出来ます。
夜中にオンコールがあっても、slackを見るだけですぐに状況が把握できそうですね。。導入したい。。
システム、インサイト、そして「人」をつなぐ ～JAL の運用モダナイゼーションが目指す未来～
このセッションでは、JALさんが取り組んでいるIT運用のお話でした。
私の現場もITの運用部署で、Datadogを使用した運用設計を行なっていることから、すごく参考になることが多かったです。
正直言うと、抱えている課題もほぼ一緒で、構築されている運用プラットフォームも私が考えている案の1つと全く同じで、「やはり同じ考えになるよね笑」となりましたね。
引用：Datadog Live Tokyo 2026 登壇資料（セッション「システム、インサイト、そして「人」をつなぐ ～JAL の運用モダナイゼーションが目指す未来～） / 資料作成・著作権：JALデジタル株式会社
JALさんの講演については、以下のページでも紹介されていました。
「見える」から「わかる」へ - AI で進化する freee の Observability
このセッションでは、freeさんが直面した課題についてのお話がありました。freeさんは各種テレメトリーを1つのDatadog上に集めることが出来ましたが、膨大なデータ量となったことで以下の課題がありました。
引用：Datadog Live Tokyo 2026 配布資料（セッション「「見える」から「わかる」へ - AI で進化する freee の Observability） / 資料作成・著作権：free株式会社 大木竜勝 氏
この課題に対して、freeさんは以下の取り組みを行っていました。
-
Coding AgentからDatadog MCPを活用し、自然言語でLogやTraceを分析し、skillsに
どこに何があるか・各コンポーネントをどのように繋げれば良いかをskillsにするということです。
そして、SREチーム以外のメンバーも自発的にskillsを作成・社内公開すると言う取り組みです。
弊社でもやりたい。。 -
AI Agentによるアラートの自動トリアージ・分析
アラートが発生した際に、AI Agentにもwebhookで通知が送られ、原因分析に必要な情報にアクセスし分析結果をslackに投稿すると言うものです。
導入効果でDBREが20~30分かけていた初期調査の時間が5分に短縮された実績もあるそうです。
すごい。。弊社でもやりたい。。
以前、以下の記事でbotによるアラート調査を見たことがあったのですが、勝手に調査を行なってくれるところが手間いらずだと感じました！
-
Bits Assistantを使用してDDSQL作成
内容を詳しく、分かりやすくしようとするとSQLのクエリが複雑・長大になり、メンテナンスも大変になりますが、Bits Assistantに作成・解説し、ダッシュボードに落とし込むことで誰でも同じ分析結果を見られるようになったとのことです。DDSQLとBits Assistantの組み合わせを試してみたくなりました！！
これらの取り組みは全て、「なぜそうなったのかを理解する」から「データに基づいて次は何をすればいいか決められる」という構造になっています。
freeさんの言葉では、「決められる」まで、届いてObservabilityは価値を生む
と紹介されていました。
本記事冒頭の、オブザーバビリティであった内容です。
個人的にObservabilityを体現できていると感じました。
AI エージェントを見守る技術 ― 現場から考える LLM Observability
LLM Observabilityってなんだろ？と思って参加しました。
LLM Observabilityとは、LLMを使用したシステムのオブザーバビリティのことでした。
こちらについて、開発者とSREの方が登壇されていて、それぞれの目線でなぜ、LLM Observabilityを使用しているのか。導入するにあたっての障壁はあったかなどのお話がありました。
LLM Observabilityを導入・使用するにあたっての障壁としては、以下のようなものがあるそうです。
-
良くも悪くも全てのデータを送ってしまう
- お客様によってはDatadogにデータを送って欲しくないと言うご要望もあるため、キーによって送る送らないと言う仕組みを用意する必要があった。
確かにこれはよく聞く気がしますね。医療系とかでも直面する気がします。
- 契約周り的なことが大変だった
へええ。。って感じでした、未熟すぎてわからなかったです。
あとは関係ない話ですが、新しいバージョンがリリースされても、すぐに導入することで回答の質が変わったら困るや、開発者目線だとフレームワークの挙動が知れるからいいよね。とかハルシネーション率の他にもAgentが使用してるツールの選択率などもみて分析しています。などのお話もありました。
AI周りの知識が疎いので、キャッチアップしていこうと思います。
さいごに
Datadogのイベント参加は初めてでしたが、今後も積極的に参加したいと思います。それほど、得られた情報に価値があったと思います。
特に運用設計をしている立場として、他社のIT運用の方法やDevops・SRE的な取り組みは参考になる部分が多かったので、担当しているプロジェクトに取り入れたいと思います。
また、AIネイティブ時代のIT開発・運用についても、AIを使用して運用の効率化を図る方法なども知ることができたので、今後もキャッチアップしていきたいと思います。