JDDUG Meetup #21 AIにデバッグさせて気づいた、 「正しい計装」がAIの精度を決めるという話 出町 陽平 フリーランス / SRE・可観測性 2026.08.26 1 / 9 

前提 入っている現場では、 Devin に調査を投げています。 各種SaaS・クラウドに繋がっていて、「このエラー何？」と投げる。 勝手に横断して調べて、返してくる。 この運用は、もう回っています。 でも、AIは間違える。 2 / 9 

原因 間違う原因の多くは、AIの限界ではなく こちらの計装の穴 データが足りない場所で、AIは黙って埋めにいく。 計装不足 ＝ データ不足 ＝ ハルシネーション率が上がる。 Garbage In, Garbage Out。AIが賢くなるほど、入力の質がそのまま出力の質になる。 3 / 9 

主張 APM・ログ・RUM が 最初から1箇所に揃っている。 そこが Datadog の強み。 だからこそ、こちらが線さえ通せば、AIは「ここだけ」見れば足りる状態に なる。 逆に言えば、その1本の線が切れているところで、AIの調査は止まる。 その線が切れていた実例を、2つ持ってきました。 4 / 9 

実例 A / 識別が無いと、絞れない 429 の「発生源」を特定できるか 計装前 2026-01 計装後 ResourceExhausted = 429 と発生メソッドまでは到 変えたこと 発生源の upstream をログに記録する 達。 しかし発生源は、 「外部API A か B か C の 2026-07 → 同じ問いに対して、 「発生源は〈これ〉です」 いずれかだと考えられます」 たぶん、このどれか これ AIは何も変えていない。足したのは、1つのフィールドだけ。 5 / 9 

実例 B / 連結が切れると、辿れない AIが自分で「データが足りない」と言った 計装前 2026-06-09 計装後 調査中のAIが、こう言って止まった。 変えたこと 「この service のログに trace_id の ctx を outbound の各クライアントに配線 （Go） 紐付けが無く、trace → ログの 直接的な相関がとれない」 2026-07-28 実測 → 原因は outbound ログが ctx を引き回しておらず、ト レースに乗っていなかったこと。 入口ログ〜downstream が 同一 trace_id で連結 トレースからログへ降りられない 1本の線で辿れる AIが穴を指摘して、塞いだら通った。計装が効いたことの、これ以上ない実証。 6 / 9 

よく聞かれること / 「AIが自分で繋ぎ直せるのでは？」 できなくはない。でも 繋ぎ直せるのと繋がっているのは違う。 線が切れている trace_id が通っている ¥ 推論で埋めにいく × 推論で埋めにいく ¥ トークンを払う × トークンを払う ¥ 時間を払う × 時間を払う ¥ 毎回、調査のたびに × 毎回、調査のたびに Datadog が APM とログを相関させてくれているぶん、その支払いは丸ごと消える。 平常時なら誤差です。でも障害対応で、一分一秒が惜しいときは？ 7 / 9 

計装が決めているのは、どこか 原因が分からなければ、改善策は打てない 04 改善策が打てる 再発しない形に直せる 03 原因を突き止められる なぜ起きたかが分かる 計装がここを決める 識別（Span タグ）／連結（ctx 伝播・Trace 相関） 02 症状を止める 再起動・切り戻し。原因が分からなくてもできる 01 気づく Monitor たいてい、ここは置いてある 計装が無ければ、AIでも原因は突き止められない。 ケースA も B も、詰まっていたのは③。 8 / 9 

まとめ AIが賢くなるほど、 計装の価値は上がる。 賢いAIほど、足りないデータを推論で埋めようとする。 その時間とトークンは、線を通しておけば最初から要らない。 線が1本通っているか。 それだけで、AIの答えは変わる。 Datadog は、最初から1箇所に揃っている。 出町 陽平 フリーランス / SRE・可観測性 ありがとうございました 9 / 9