---
title: "Looking Back at Datadog Live Tokyo 2025「現場で活きる！Datadog によるオブザーバビリティ実践のリアル」パネルディスカッション開催レポート"
description: "過去の Datadog Live を振り返るシリーズ「Looking Back at Datadog Live」。今回は Datadog Live Tokyo 2025 のパネルディスカッション「現場で活きる！Datadog によるオブザーバビリティ実践のリアル」をお届けします。"
author: "木村 健人, 逆井 啓佑"
date: 2026-09-10
tags: []
blog_type_id: the-monitor
locale: ja
---
**「Looking Back at Datadog Live」**は、これまでに開催した Datadog Live のセッションをあらためて振り返り、当日会場でどんな話が交わされていたのかを記事として残していくシリーズです。イベントそのものは一日で終わってしまいますが、そこで語られた実践知はあとから読んでも役に立ちます。ご参加いただいた方には記憶の手がかりとして、参加が叶わなかった方には当日の空気に触れる入口として読んでいただければ幸いです。
2025年6月3日、Datadog は国内最大のユーザーイベントである Datadog Live Tokyo 2025 を開催しました。オブザーバビリティとセキュリティの最新動向や Datadog の製品アップデート、複数の Datadog ユーザーによる活用事例の発表が行われ、前回の Datadog Live Tokyo 2024 Reprise から会場規模も大きく広がりました。
当日は、Datadog Japan のセールスエンジニアである逆井と木村が、**「現場で活きる！Datadog によるオブザーバビリティ実践のリアル」**にてパネルディスカッションのモデレーターを務めました。
パネリストには、日々の現場で Datadog を活用されているエンジニアの方々として、**藤原 涼馬 様（MNTSQ株式会社）、大間 俊樹 様（株式会社ジンズ）、吉岩 祐貴 様（株式会社ヌーラボ）、金森 秀平 様（株式会社タイミー）**（写真同順）の4名をお迎えしました。導入から3ヶ月という方から5年ほど使い込んでいる方まで、利用フェーズの異なる4社にご登壇いただけたのが本セッションの特徴です。
本ブログでは、パネルディスカッションでお話した内容の一部を振り返りながら、写真とともに概要をお届けします！
## **オブザーバビリティ・Datadog があって良かったことは？**
最初のトピックは**「オブザーバビリティ・Datadog があって良かったことは？」**です。まずは率直なエピソードから伺いました。
タイミーの金森様からは、複数の SaaS のデータを1つのダッシュボードに集約できることが障害対応を変えたというお話がありました。サードパーティサービスへのリクエストがエラーになった際に、ログと APM からどの URL のどのサービスで問題が起きているのかを特定してアラートを発報し、エンドユーザーにどのような影響が出ているのかまで含めて通知できるようになりました。障害時に限らず、テレビ放映で SMS ツールのメトリクスが跳ね、同時に検索基盤の負荷も上がるといった複数のシグナルをつなげて見ることで、**プロダクトに起きていることを意味のある事象として捉えられるようになった**と語りました。
MNTSQ の藤原様には、マルチクラウド環境という切り口で伺いました。各メガクラウドにはネイティブなオブザーバビリティのマネージドサービスがありますが、それらは自社サービスの監視に注力して作られているため、クラウドを横断して見る観点ではどうしても機能面で物足りなくなります。**マルチクラウドで運用するなら、横断して見られる仕組みが別途必要になる**というのが藤原様の整理でした。加えて、MNTSQ は契約書管理のサービスを提供する会社であり、オブザーバビリティで収益を上げているわけではないため、**基盤の運用や機能追加を任せられること自体が SaaS としての価値**だとも述べました。
ジンズの大間様からは、技術というより組織の課題を解いた事例を共有いただきました。元々は少人数のプロジェクトマネージャーが協力会社に依頼してシステムを構築する体制が多く、中身が把握できていないために障害対応が長引く課題があったそうです。インフラ周りのプロダクトから Datadog を導入して可視化を進めた結果、エンジニアではないメンバーが「何か起きているので助けてください」としか言えなかった状態から、「このサービスのエラー率が高くなっている」と具体的に会話できるようになりました。**障害時間の短縮だけでなく、自分たちのシステムに対するグリップ力そのものが上がった**と語りました。あわせて、平常時を知らなければ異常時の判断ができないという考えから、ダッシュボードをみんなで眺める「サービスレビュー会」を月次で開催されていることも紹介いただきました。
ヌーラボの吉岩様には、導入から3ヶ月という最も早いフェーズならではのお話を伺いました。以前はトレースを Zipkin、メトリクスを Grafana、ログを OpenSearch と複数のツールを行き来する必要があり、しかもそれらのコンテキストが接続されていませんでした。Datadog に統合したことで一元的に確認できるようになり、**インシデント対応の質が大きく向上した**と振り返りました。週次の開発者ミーティングで行っているパフォーマンス分析も、アクセスログからの集計に時間がかかっていたところが即座に結果を得られるようになり、空いた時間を分析そのものに充てられるようになり、改善の芽が生まれやすくなったと述べました。
コスト面のエピソードも印象的でした。ヌーラボでは Cloud Cost Management のレコメンデーションを活用し、エンジニア1名が3人日ほどの作業で**年間約1,500万円の AWS 費用を削減**されています。MNTSQ でも、メトリクスをもとに Elasticsearch クラスターへ過剰に割り当てていたリソースを見直し、インスタンスタイプとクラスターサイズを段階的に縮小されたそうです。オブザーバビリティツールに支払うコストを、そのツールで見つけた削減が上回る。この構図は多くの参加者の関心を集めていました。
## **オブザーバビリティの取り組み前に戻れたらどうしたい？**
うまく推進されている4社ですが、ここまでたどり着くには相応の過程があったはずです。2つ目のトピックでは**「オブザーバビリティの取り組み前に戻れたらどうしたい？」**という角度で伺いました。
ヌーラボの吉岩様が挙げられたのは「『オブザーバビリティ・エンジニアリング』をもう一度読み直しておくこと」でした。特に第15章がよかったといい、話題はそのまま作るか買うかの議論に入っていきました。ヌーラボは Grafana や Prometheus を自前で運用してきた会社ですが、オブザーバビリティ基盤を本格的に作るとストレージにも性能にもコストがかかり、OSS を選べば「それを知っている人しか運用できない」という隠れたコストも発生します。上長に運用工数を問われて3人ほど必要だと答えたところ「だったら買うほうが安いね」となったそうで、**運用に3人かけるくらいならサービスの価値創造に3人かけたほうがいい**という判断をもっと早くできていれば、オブザーバビリティの価値にもっと早くたどり着けたと振り返られました。
ジンズの大間様からは2点挙げていただきました。1点目は、**導入したいプロダクトの社内事例と実績を早い段階で作っておくこと**です。ジンズではメトリクスやログは初期から使えていた一方、APM は便利そうだと分かっていても、自分たちのシステムで何が変わるのかがふんわりしているために開発の工程へ優先度高く入れてもらえなかったそうです。直近で内製の認証基盤リプレースに APM が入り改善活動が動き出したことで、聞ける相手と見える状態が社内にできたことが大きかったといいます。2点目は**ガイドラインの早期整備**で、実装例でもドキュメントでも構わないので「これはマストだ」「これは実装しないほうがいい」が分かる状態を作っておくこと。現在は実装したメンバー自身にガイドラインの更新と社内展開を担ってもらい、ひとりで推進するのではない文化づくりを進められています。
MNTSQ の藤原様には設計の観点から伺いました。アプリケーション開発ではテスタビリティが重視されますが、同じように**「このアプリケーションは観測しやすいのか」を設計段階で考えることが重要**だという指摘です。そして、最後に人が見るのはログになるのだから、どれだけ検索しやすく、クエリしやすい形にしておけるかがポイントになると続けられました。普段の運用を考えたときの理想像として、こう表現されています。
「正常に動いているときは静かに黙っていてもらっていい。処理がちゃんとできましたとさえ言ってくれればいい。一方で異常なときは、細かい情報でもいいのでとにかくたくさん出してほしい。雄弁に語ってほしいんですね」
そのために必要なのは、オペレーションに開発者がしっかり関わることだといいます。障害が起きること自体は避けられないのだから、MTTR をどこまで短くできるか、そのために異常時にどんな情報を出すべきかを、**開発者とオペレーターの全員で共有できる形にしておく**ことが鍵になります。
タイミーの金森様も、ログの重要性を挙げられました。リクエストログ、デバッグログ、分析用のログとさまざまなログが混在する状態で、すべてをバックエンドに送ればコストになります。**どのログをどれくらいの期間インタラクティブに分析できる状態にしておくのか、組織として合意を取っておけばよかった**という振り返りです。Datadog ではログのインデックスを属性ごとに分けて保存期間を設定でき、アーカイブもできるため、見えなくなることと消えることは同義ではありません。CS と「1ヶ月以内ならすぐ回答できる、それ以上の調査には時間を要する」と握っておければ、さらに保存期間を短くできたはずだといいます。トレースのサンプリングを送る側で絞るか送ったあとに絞るかも、取り組み前に決めておくとよいポイントとして挙げられました。
## **これから取り組んでいきたいことや、これまで得られた知見は？**
3つ目のトピックは未来の話です。**「これから取り組んでいきたいことや、これまで得られた知見は？」**を伺いました。
タイミーの金森様が挙げられたのはセキュリティです。セキュリティが複雑化するなかで現場がリスクのオーナーシップを負う場面が増えており、現場のエンジニアがツール選定に関わることも多くなっています。Datadog であればエージェントや既存のインテグレーションをそのまま活かせるため、**運用しやすさと組織が求めるリスク管理の担保を両立できる**という見立てでした。具体的には、WAF をすり抜けてアプリケーションに到達した攻撃を動的に検知できると、多層防御としてより堅牢な構成が組めるのではないかと語られました。
ヌーラボの吉岩様は、SLO ベースの意思決定に進みたいとのことでした。SLO を設定しただけでは、サービスレベルが下がった理由を闇雲に探すことになりがちです。**トレース、ログ、メトリクスがすべて繋がっている状態であれば、なぜ起きたのかを追跡しながら探索できる**という整理で、そのためにワークショップの企画や地道なイネーブルメントを重ねていきたいと語られました。
ジンズの大間様は、システム刷新が進行中というフェーズならではの展望を共有いただきました。認証基盤の事例では、API テストから Lambda、APM、インフラまでを Datadog で一気通貫に確認できる状態ができ、**RUM でお客様の操作の迷いを捉えて UI/UX を改善しながら、同時に APM で裏側の速度とエラー率を改善する**という動き方が生まれています。今後は CI/CD の可視化や DORA メトリクスにも広げたいとのことです。もう1点挙げられたのがビジネスメトリクスです。発注から在庫、倉庫から店舗への移動といったサプライチェーンのデータも可視化し、**システムを見ているメンバーとビジネスを動かしているメンバーが同じデータを見ながら会話できる状態**を目指されています。
MNTSQ の藤原様も、ビジネスサイドとのコラボレーションを挙げられました。MNTSQ ではコンサルタントがお客様ごとの定例会でニーズや不満を引き出していますが、**お客様が口にする不満はすでに言語化されたものであり、操作の分かりにくさのような言語化されない不満はサーバーサイドのログには残りません**。それを捉えるにはフロントエンドをきちんとモニタリングし、どの操作で迷い、詰まっているのかについて仮説を持ったうえで改善提案を提示できるようになりたい、という展望です。お客様と対面する立場からすれば究極的には UI/UX が全てであり、簡単に操作できること、レスポンスが速いこと、正常に処理されることの3点が重要になる。**その期待値をすり合わせる共通の材料として、メトリクスやトレースがビジネスサイドとの議論を可能にする**という整理でした。
## **ライブ Q&A**
Datadog "Live" Tokyo ということで、本セッションでも会場からリアルタイムに質問を集め、その場で回答する時間を設けました。時間内に拾いきれないほど多くの質問をいただきましたが、本ブログ記事では紙面の都合上、当日その場で取り上げた質問のうち2つをご紹介します。
1つ目は**「オブザーバビリティのチャンピオンは、どうやって作っていくのか？」**です。横断的な関心事を推進するにはチャンピオンと呼べる人物が必要になりますが、その人はどう生まれるのか、という質問です。吉岩様の答えは明快で、**素質があるのは好奇心のある人**でした。『オブザーバビリティ・エンジニアリング』にも、好奇心のある人はオブザーバビリティの世界で強いと書かれています。好奇心のある人がひたすら調べて使い、「こういう良いものがあった」と社内に広めていく活動が、結果としてチャンピオンにつながっていくという整理でした。吉岩様ご自身もトライアル期間中に Datadog のドキュメントを読み込み、担当していた逆井が驚くほどだったと述べました。
2つ目は**「経営層にコストをどう説明するか、投資対効果は出ているのか？」**という、最も多くの「いいね」を集めた質問です。藤原様の回答はシンプルで、**自前でやるか外に任せるかを積み上げて比較する**というものでした。自前で運用するなら、人件費に加えて動かすためのインフラ、データを保管するバックエンド、ログをアーカイブするストレージが必要になり、非機能要件の設計も避けられません。それらを丸めたコストと SaaS の利用料金のどちらが安いのか。この形に落とし込んで考えたほうがよい、と述べました。
## **最後に**
クロージングでは、登壇者の皆様から一言ずついただきました。MNTSQ の藤原様は300人ほどの前で話す緊張を振り返りつつ、他の登壇者の回答から学ぶところが多かったと語られました。ジンズの大間様は、何もないところからグリップ力をつける段階から、自分たちで作るものに組み込んでクイックに改善する段階へとフェーズが変わってきたご経験を共有くださいました。ヌーラボの吉岩様は「まだ全然話し切れていない」とネットワーキングでの再会を呼びかけ、タイミーの金森様からは、Datadog を使うことでエンジニアとして成長できたという実感と、**好奇心のある人が伸び伸びと活躍できる現場が増えてほしい**というメッセージをいただきました。
オブザーバビリティをテーマにしたセッションでしたが、実際に交わされたのはコストの話、フロントエンドの話、セキュリティの話、そしてビジネスの話でした。**オブザーバビリティを中心に置くことで、その周辺にあるさまざまな要素が良くなっていく**。それを4社の実践から感じ取っていただけたのではないかと思います。課題やアプローチは組織や文化によって異なるからこそ、生の体験談を引き出しとして持っておくことに意味があります。
改めまして、ご登壇を快諾いただき、とても貴重かつ赤裸々な事例共有をしていただいた藤原様、大間様、吉岩様、金森様、本当にありがとうございました。
**DATADOG LIVE** は今後も各地で開催予定です。2026年9月16日には [**DATADOG LIVE OSAKA**](https://events.datadoghq.com/ja/events/datadog-live-osaka-2026/)、2026年10月15日には AI にフォーカスした** **[**DATADOG LIVE TOKYO – AI Powers the Future –**](https://datadoglive-ai2026.bs-event.jp/) を開催します。
お客様の先進的な取り組みや、Datadog の最新ビジョン・製品アップデートとともに、オブザーバビリティや AI がもたらす変革の可能性をご紹介します。ぜひご参加いただき、最新の知見や、皆さまの次のアクションにつながる具体的なヒントをお持ち帰りください。