こんにちは、エス・エム・エスでカイポケコネクトのエンジニアをしている加我 (@TAKA_0411) です。
私事ではありますが、日本のDatadogコミュニティの活動や社外での登壇の実績を評価されまして、2026年度の Datadog Ambassadors に選出いただきました。
もともと好きが高じて続けてきた活動ではありますが、それらがオフィシャルに評価されたというのは感慨深いものです。今後も積極的なDatadog活用や知見の共有、仲間集めのためのコミュニティ運営を続けていきます。
そういえば、3月に開催されたJAWS DAYS 2026では私も登壇者・ブース担当者として参加していたのですが、Datadog社のブースにて非常に気になるデモを拝見しました。
DatadogのWeb UIから生成AIと会話し、データの調査や分析を行う機能……それが私とBits Chat（当時はBits Assistant）との初めての出会いでした。直感的にこの機能に可能性を感じ、担当営業の方を通じてPreviewにおけるBits Assistantの利用について相談しました。相談から少し時間が経ったタイミングで利用が可能になったので使ってみたところ、非常に便利でした。これは自分だけではなく開発組織全体に知ってもらいたい。そう思ったのがこの記事を書いたきっかけです。
Bits Chatについて
Bits ChatはDatadogのWeb UIからチャット形式でやり取りすることにより様々な支援を受けられる、生成AIを活用したサービスです。Datadogに蓄積されているデータに対し、下記の機能を提供しています。
- 問題の調査と対処
- テレメトリデータの探索と分析
- Datadogの概念や使い方の学習
- オブザーバビリティの設定と最適化
Bits Chatが活躍するユースケースとして、Monitorのエラー通知からの原因調査、ダッシュボードにおける特定期間のデータ分析、用途を伝えるだけで最適なダッシュボードを作成してもらうといったことが可能になります。つまり、これまで私たちが手動で行ってきた多くの作業をBits Chatがこなせるようになります。
余談ですが、Bits ChatはPreviewによるサービス提供当初はBits Assistantと呼ばれていました。2026年6月に開催されたDASH 2026にてBits Chatと名称変更がされ、BitsというAI機能群のうちの1つとなりました。Datadogには多くの機能があり、新機能も次々と追加されますが、Bits Chatをハブにして活用方法を学んだり実際に設定してみたりすることが可能になります。
さて、私はPreviewでの機能利用が可能になった段階から社内でもりもりBits Chatを使い込んできました。そんな私が得られた知見や開発チームの変化についてご紹介します。
Datadog民主化の鍵はBits Chatである
使ってみて気づいた1つめの大きなメリットがこちらです。Bits Chatを活用することにより社内のDatadog推進者 / Datadogチャンピオン *1 への依存が軽減され、開発者が自発的にDatadogを利用する文化の醸成に貢献してくれます。
Bits ChatはDatadogについて熟知しています。ユーザーが実現したいことや抱えている問題、テレメトリデータの分析方法、ダッシュボードの作成など、様々なテーマについてアドバイスを得ることが可能です。このような動きをするBits Chatを私は「Bits Chat as an Internal Datadog Champion」と表現しています。そうです、Bits Chatは社内で一番Datadogに詳しいチャンピオンなのです。
自社もしくは自分が担当しているプロダクトへのDatadog導入を推進したことがある方はご理解いただけるかと思いますが、Datadogを導入してから安定した運用に至るまでには下記のような多くの問題が発生します。挙げ始めたらキリがありません。しかし導入を推進する人は強い推進力とオーナーシップを持っているため、これらの問題を1つずつ解決し、社内のドキュメントに残し、設定をコード化することで安定したDatadog活用に導くわけです。
- そもそもDatadogの使い方がわからない（学習コスト）
- Datadogがあっても別のツールを使おうとする（ツールのサイロ化）
- UIが複雑で機能がどこにあるかわからない
- データの表示切り替え方法がわからない
- いい感じのダッシュボードを作るのが困難
- 意図したアラートを設定できない
Datadog推進者のSPOF問題
社内のDatadog推進者が色々な問題を解決し、運用を安定させていくにつれて発生する別の問題があります。それは「Datadogの社内活用の拡大が推進者に依存してしまう」「Datadog推進者がSPOFになってしまう」という問題です。
皮肉にもDatadog推進者が強いオーナーシップを発揮するほど「Datadog推進者の人がやってくれる」「Datadog推進者の人にお願いすれば良い」という空気感が出来上がってしまい、Datadogの民主化、ひいてはオブザーバビリティの民主化からどんどん離れていってしまうのです。解像度の高い話をしているなと思った読者のあなた、鋭いですね。これは過去の私自身への自戒です。
Datadog活用のあるべき姿
Datadogは開発組織全体で使うことにメリットがあると私は考えています。特定の誰かが使えるだけではDatadogを活用できている状態とは言えないのです。過去にDatadog推進者のSPOFという原因の一端を担ってしまった私がBits Chatを見て感じた可能性が「Bits ChatこそがDatadog民主化の鍵」でした。
開発者が自発的・自律的にBits Chatへ現在発生している問題や実現したいことを相談すれば、開発組織全体でDatadogを活用でき、結果としてサービスのオブザーバビリティが高まると私は信じています。
ちなみに、Datadogの民主化を促すために最近私が力を入れているのがBits Chat誘導員という役割です。以前はBits Assistantのアシスタントなどと言っていた時期もありました。開発者がDatadogの活用で困ったらすぐさまフォローに入りつつBits Chatへ誘導し、本人にBits Chatとの会話を通じて自身で課題を解決する体験をしてもらうことを率先してやっています。また、アラートが発生した場合は自分が積極的に調査に参加してBits Chatの活用事例を知ってもらう機会も作っています。
こうした取り組みの結果、開発者がBits Chatを活用して自発的に課題を解決したエピソードも生まれています。とある非同期処理をバックエンドで実装するにあたり、処理が別スレッドに移ったこと、そしてスレッドプールが溢れないことをテレメトリデータから確認したいというニーズがありました。これに対し、社内のエンジニアはBits Chatと対話することでSpanの計装とスレッドプールの監視を自力で完遂していました。ご本人曰くDatadogに特別詳しいわけではないそうですが、対話を重ねることで無理なく実装できたと言っていました。
私というDatadogチャンピオンの出番がないまま解決してしまったわけで、これは民主化の一歩と呼べる出来事でした。
テレメトリデータ分析会の活性化
私が所属しているチームでは定期的にサービスのCUJ (Critical User Journey) のデータをまとめたダッシュボードの分析会を行っています。しかし、以前はダッシュボードを見てもデータの分析方法がよくわからなかったり、どのデータを見たら問題発見や改善アクションに繋げられるのか迷うことも多く、価値のある時間であるとは言い難いものでした。テレメトリデータはDatadogに蓄積されているため、ダッシュボードを作り直そうかなどと考えていたのですが、このデータ分析自体をBits Chatにやらせてみようという取り組みを始めました。
分析の方法として、CUJのデータをまとめたダッシュボードに対してBits Chatから「ダッシュボードのデータの分析をしてください。分析するための条件は〜〜です。分析したデータはNotebookにまとめておいてください」といった形で分析を依頼していました。数回やっているうちにNotebookのCustom Templates機能を使えばある程度再現性のある形で実行・保存できるのでは？と気づき、最近では専用のNotebookテンプレートを用意し、そのフォーマットに沿って分析依頼を行っています。
分析用のプロンプト例 (クリックすると展開されます)
# 分析用のプロンプト例
CUJに関するデータについて下記の観点を中心に比較・分析し、Notebookとして保存してください。
Notebookのテンプレートは「CUJ分析レポート - {mm-1}月 vs {mm}月比較 」を使用し、テンプレート中の{mm}には当月の数字を、{mm-1}には前月の数字を、{対象サービス}には"sample-app" を入れて置き換えてください。
また、Notebookへのデータ追加時にはテンプレートのフォーマットを必ず遵守してください。
以下は分析対象です。
■ 分析対象
・CUJサービス: service:sample-app (GraphQL Operation別に集計)
・重点分析サービス: service:sample2-app
・RUM: sample-frontend
■ 条件
・分析対象の期間: 前月1日〜前月11日 vs 当月1日〜当月11日
・環境: production
・Operation: ◯◯関連のOperationName呼び出し回数Top10 + △△関連のOperationName呼び出し回数Top10
■ 比較観点
・GraphQL Operationの呼び出し回数の変化
・レイテンシ(P95)の変化
・エラー数の変化（エラー率も算出）
・CUJのLatencyのP95で500msecを超えるGraphQL Operationの有無
・sample2-appの新規Operation出現有無
■ RUM分析
・全体: ビュー数/セッション数/P95ロード時間/エラー合計
・遅延ページ: P95 > 1秒のCUJページ抽出
・XHRボトルネック: 最も遅い外部リクエストの特定
・エラー分類: Top10エラーの分類と対応要否判定
■ 計測単位
・呼び出し回数: リクエスト単位（@_top_level:1）
・エラー: 子スパン単位とリクエスト単位を併記
■ P95 > 1秒判定のデータソース
・custom.sample-app.graphql.request.duration メトリクス
（スパン保持期間を超える場合に対応）
■ 追加分析（可能であれば）
・アクティブユーザー数との相関
（データソース: Sheets「ユーザー数管理」）
■ 出力形式
・サマリー（全体評価テーブル + キーインサイト）を冒頭に
・推奨アクション（優先度高/中/ポジティブな変化）を末尾に
■ 関連リソース
・ダッシュボード: /dashboard/aaa-bbb-ccc/cuj-dashboard
この分析方法に変えてからダッシュボードの分析会に変化が見られました。Bits Chatがまとめてくれたデータを見つつ、データに対する疑問だったりデータの見せ方の工夫に関する意見が積極的に出るようになりました。
- なぜこのエンドポイントでのエラーがこんなに発生しているのか
- エラー数はリクエスト単位とスパン単位でデータを出し分けた方がいいのではないか（Next Actionへ）
- このエラーは原因を調べて対処したほうがいいのではないか（Next Actionへ）
- ユーザー数の増加とGraphQL Operationの実行回数に相関はあるのか
- フロントエンドのボトルネックは◯◯が原因そうなので調べてみてもいいのではないか
- ユーザーの利用増加を数字から感じられて良い
実際私もダッシュボードの分析会で発見したエラーの原因を調査し、バックエンドのエラーハンドリングを改善するといった対応を行うことができました。Bits Chatは具体的なソースコードの改善方法も提案してくれるので、私のような開発経験が少ない人間でも積極的にサービスの改善に繋げることができます。
最高のデバッガーを支えるBits Chat
とある日の午後、1つのアラートが発生しました。レスポンスタイムが基準値を上回っていました。私も調査に入りつつBits Chatにアラート原因の分析を依頼し、別のエンジニアはログの分析をしてくれていました。
Bits Chatを使いつつトレース・ログ・メトリクスのデータを分析してみます。どうやら別のチームがオーナーとなっているシステムが関連していそうです。そして私はあまりそのシステムの中身を知りません。Bits Chatがまとめたデータを見てみると該当の時間帯にECSのCPU使用率が高まっていることがわかりました。じゃあなぜこのタイミングで使用率が高まるのかを調べてみます。自分も実際に関係しそうなソースコードを見て、微力ながら議論に参加していたわけですが、結論としてはデプロイ中にリクエストを受けるとタイミング次第でリソース消費量が高まってしまうという現象であることがわかりました。
私はデータの拡充という観点からDatadog Continuous Profilerを有効化し、オーナーであるチームはリソース消費量を抑えるための具体的な施策について議論していました。また、デプロイ完了のタイミングも改善が可能では？という議論が続きます。
今回のアラート対応を経て、私が開発であまり携わっていないシステムのことについても少しだけ詳しくなり議論に加わることができました。自分がよく知らないシステムの調査は大変です。しかしBits Chatの助けを借りることで仕様の理解と現象の理解を無理なく行えるのがよくわかりました。
そしてこれは、私だからできたという話ではありません。書籍『オブザーバビリティ・エンジニアリング』では、オブザーバビリティを実践しているチームにおける最高のデバッガーは好奇心が強いエンジニアであると述べられていました。裏を返せば、デバッグに必要なのは深いシステム知識ではなく好奇心ということになります。その知識の差はBits Chatが埋めてくれます。開発経験が少ない私でも越境して調査に加われました。好奇心さえあれば、多くの開発者が同じように動けるはずです。Bits Chatの力と好奇心を武器に、どんどんアラート対応して学んでいきたい所存です。
まとめ
Bits Chatのユースケースや社内での活用例、その結果もたらされたものについて書いてみました。改めてBits Chatが私たちの開発組織にもたらしたものを3つ挙げます。
- 社内のDatadogチャンピオン（例えば私）を頼ることなく、開発者が自発的にBits Chatと対話し、エラーの原因分析や計装の改善を進めるようになりました。社内で一番Datadogに詳しいのはもう私ではなくBits Chatです。
- ダッシュボードの分析会が「データを眺めるだけの会」から「Next Actionが生まれる会」に変わりました。分析そのものをBits Chatに任せることで、私たちはデータへの疑問や改善アクションの議論、ひいてはユーザーへの価値提供に時間を使えるようになりました。
- 開発経験の多寡を問わず、担当していないシステムの調査にも越境して加われるようになりました。よく知らないシステムであっても仕様の理解と現象の理解を無理なく進められます。
Bits Chatは便利です。開発組織にとても多くのメリットをもたらしてくれます。Datadogを使っているけど上手く使い切れていないという課題を感じている方は導入をオススメします。一見コストが高いと感じられるかもしれませんが、利用することで得られるものは少なくないはずです。
今後の課題
一方でBits Chatはトークンを消費してアクションを行うので、どのように運用すればトークンが最適化されるのかを考えなければなりません。複数人でアラート対応をしている際、各自がばらばらにBits Chatへ質問をするとトークンが無駄になる可能性があるため、この場合の最適な運用フローを今後整備していく必要性を感じています。また、Bits Chatへ頼りきってしまい、ダッシュボードの整備が全くできていないという状況を招かないよう気をつけていきたいと思います。
私個人としましては、エンジニアが自分の言葉でBits Chatとやり取りして問題を解決する（もしくは解決の糸口を見つける）というのは大事な体験であると思っているので、あまり制限せずに効率的な運用ができたらなーと考えています。Bits Chat愛好家のみなさま、コスト最適化についてぜひディスカッションしましょう！
*1:強いモチベーションと推進力で導入を牽引する人。公式のDatadog Championsではありません
