OTel × Datadog で 「AI活用」を計測し、改善に繋げる

# About me
- X
- https://twitter.com/shihochan_jp

- Github
- https://github.com/shihochan

- Youtrust
https://youtrust.jp/users/shihochan

# Links
- Event Page
- https://aid.connpass.com/event/397141/

Transcript

1. 2026/06/25, AIオブザーバビリティ スペシャル #1 Observability for AI Dev OTel × Datadog で 「AI活⽤」を計測し、改善に繋げる - 可視化した"その先"、分析と改善を"仕組み"にする話 - 志甫 侑紀
2. 志甫 侑紀 / Yuki SHIHO Software Engineer at Tribeau, Inc. @shihochan @shihochan_jp Cat LOVER @shihochan ©Tribeau, inc. ｜ 02
3. • 利⽤⾯が分散している ◦ Claude Code / Codex / Cursor / CIレビュー / AIエージェント基盤 • ⾒える粒度が揃っていない ◦ ユーザー‧チーム‧モデル‧コスト‧レイテンシ • 数字を⾒ても改善に繋がらない ◦ 「使った量」だけでは、次に何を変えるべきか決められない ©Tribeau, inc. ｜ 03 AI活⽤が広がるほど、改善のための情報は散らばる 今日の話: AI利用を一つの計測網に集め、指標をチームの改善サイクルに乗せた話
4. • 話すこと ◦ AI活⽤の計測基盤をどう作ったか ◦ 可視化で何が⾒えたか ◦ ⾒えた数字を決める場に乗せて改善を回す仕組み • 話さないこと ◦ OpenTelemetry そのもの ◦ Datadog / OTel の具体的な設定⼿順 ◦ 監視SaaS‧AIツールの⽐較∕選定の⼀般論 今⽇話すこと‧話さないこと ©Tribeau, inc. ｜ 04
5. 利⽤⾯ 開発⽀援 Claude Code‧Codex‧Cursor CIコードレビュー Bedrock経由のAIレビュー (GHA) アプリ内 / AIアシスタント機能 アプリ内AIアシスタント (Bedrock+MCP) ⾃社AIエージェント基盤 Slack常駐エージェント基盤 (OpenClaw) 共通属性 service_id user team model token cost latency tool Datadog ‧Dashboard化  ‧全エンジニアに配布 ‧MCP⾃然⾔語分析  ‧現状を分析する  ‧改善を確認する 計測基盤の⽬的は、ログ収集ではなく「改善に使える粒度」に揃えること ©Tribeau, inc. ｜ 05 AI活⽤を1つの計測網に集約する OTel 計測 OTLP 送信
6. • 利⽤の主戦場はコード開発 ◦ Bedrock -> Teamプランへの移⾏に よるコスト削減 • コストは⼊⼒コンテキストに寄る ◦ コード読み込み‧⻑いセッション‧ キャッシュ未活⽤を確認 • 平均値では改善対象が⾒えない ◦ モデル別‧ツール別‧ユーザー別に 分けて論点化 • コスト単体では判断できない ◦ レイテンシ‧成果‧品質と並べて 「改善すべきか」を⾒る 計測して⾒えてきた傾向 ©Tribeau, inc. ｜ 06
7. AI活⽤を改善できる指標として読む 観点 ⾒る指標 読み⽅ 次の改善 ⼊⼒効率 cache hit率 / cache未活⽤ / ⼊⼒トークン / cost per prompt 毎回同じ情報を読ませすぎていないか CLAUDE.md、プロジェクト設定、不要コンテキス ト整理 作業粒度 prompts/session / cost/session / compaction間隔 / session時間 1セッションが肥⼤化していないか /clear、/compact、タスク分割 使い⽅の型 MCP⽐率 / tool mix / Skill / Subagent / @file ⾃然⾔語だけで頑張っていないか、機能 を使えているか MCP‧Skill‧Subagent‧ファイル参照の使い⽅共 有 実⾏設定 ‧失敗 Opus⽐率 / xhigh⽐率 / tool失敗率 / latency p95 重い設定や失敗が特定パターンに偏って いないか モデル選択、effortルール、権限‧Hook設定の⾒直 し ©Tribeau, inc. ｜ 07
8. 必要だったのは、数字を読む場と、改善を決める場 ① 分析を習慣にする ② 定例で振り返り、 改善する ③ 成果‧品質まで 計測する "⾒える"だけでは改善は回らない ©Tribeau, inc. ｜ 08
9. 一部の人だけが見るダッシュボードではなく、全員が同じ指標を見て深掘りできる状態にした DESIGN 何を設計したか 1 Datadogアカウント配布 業務委託含め、閲覧できる状態に 2 計測指標を提示する コスト / トークン / モデル レイテンシ / ユーザー / ツール 3 自然言語で分析できる Datadog MCPで自然言語分析 ENABLEMENT 分析できる状態を作る 3点セット 全員が見られる Datadogアカウント 正社員・ 業務委託 + 同じ指標を見る cost / token / model latency / user / tool + 聞ける Datadog MCP 「なぜ増え た？」 分析の入口を属人化させない 誰でも同じ指標を起点に、自然言語で深掘りできる OUTPUT 数字が、定例で扱う「改善の論点」になる ① 分析を習慣にする ©Tribeau, inc. ｜ 09
10. 数字を見て終わりにせず、定例の中で要因・振り返り・次アクションまで決める DESIGN 何を設計したか 1 定例に数字を見る枠を作る AI活用を定例アジェンダに入れる 2 指標を深掘りして要因を見る 増減の理由をモデル・ツール別に確認 3 次回確認指標まで決める 改善アクションを検証可能にする LOOP 定例の中で改善ループにする 1. 指標を見る Dashboard / Report 2. 要因を深掘る model / tool / user 開発定 例 4. 改善を決める 次アクション / 確認指標 3. 振り返る KPT / 定例 OUTPUT 改善アクションが、次回の検証対象になる ② 定例で振り返り、改善する ©Tribeau, inc. ｜ 10
11. 「どれだけ使ったか」だけでなく、「開発 (事業)成果と品質リスク」まで判断できるようにする DESIGN 何を設計したか 1 利用量だけで判断しない トークン / コストは入口にする 2 成果指標と並べて見る AIコード貢献率 / サイクルタイム 3 品質リスクも一緒に見る 誤承認率 / 人の介入率 / 失敗 率 METRICS 判断軸を「使った量」から広げる USAGE 利用量 request / token cost / model 使った量を見る OUTCOME 開発(事業)成果 AIコード貢献率 サイクルタイ ム 良くなったかを見る RISK 品質リスク 誤承認率 介入率 失敗率 コスト単体ではなく、成果・品質と並べて「続ける / 見直す」を判断する OUTPUT AI活用を増やす領域と、制御すべき領域が見える ③ 成果‧品質まで計測する ©Tribeau, inc. ｜ 11
12. • AI活⽤を1つの計測網に集約する ◦ ツールごとの差を、⽐較できる共通属性に揃える • 数字を改善できる指標として読む ◦ 「⾼い/低い」ではなく、「なんのために、どう改善できるか」 に変換する • チームで読み、決め、改善する仕組みに乗せる ◦ 分析習慣‧定例改善‧成果品質の判断軸で回す まとめ: ダッシュボード化はゴールじゃない Zenn: zenn.dev/p/tribeau · X: @shihochan_jp ©Tribeau, inc. ｜ 12