とりあえず他の人に説明するのに良さそうなので、ChatGPTに書かせた記事です。
Agentic CodingでCLIを実装していると、機能要件がどんどん進められる反面、非機能要件がないがしろになりがちです。自分は最近静的解析CLIを育てているのですが、OpenTelemetryでtracesとeventsをexportできるようにしました。結果として「どこで遅いか」「どの実装が遅いか」を事実として掴めるようになり、最適化を迷わず打てるようになりました。さらにJargerを使えばスクリーンショットやJSONとして結果を取得できるため、人間はもちろんCoding Agentにとっても計測と改善のループを回しやすくなります。
traces（Span）とは
CLIの処理を「区間」に分けて、spanとして刻みます。例えば：
- 引数解析
- 入力列挙（ファイル探索など）
- 入力の読み込み
- 処理実行（処理ごとにspanを切る）
- レポート生成
- 出力（ファイル書き込みなど）
OTLPは、トレース・メトリクス・ログを運ぶための標準プロトコルで、Collectorや各種バックエンドに投げられます。CLIにexporterを組み込んで --otel http://localhost:4318/ などとcollector (Jarger)のURLを指定してやると、こうした情報がCLIのプロセスが終わった後もわかりやすい形で残るということです。イベント情報も紐づけて記録できるので、span処理中に何が起こったかをわかりやすく残しておくこともでき、ログファイルと突合しないと何がおこっていたか判断できない……みたいな状況も防げます。
Jaegerを合わせて使うと「記録」が一気に楽になる
OTLPで通信して情報を残しておくために、Jaegerをコンテナで立ち上げるのがおすすめです。Jaeger UIは、トレースを JSONとしてview/downloadできるので結果をそのままファイルに残せますし、スクリーンショットをPRやGitHub Releasesに添付しておくと人間にもわかりやすい形で改善を説明できます。こうした作業ももちろんCoding Agentに任せられます。
やりたいことできた。すげー。やっぱりNullness周りのルールはコストかかるんだなぁということが視覚化できた。classのスキャンを並列化することと、ルールの適用を並列化することが大事そうだな。 pic.twitter.com/6xxy0W1lbm
— 医療情報ｾｷｭﾘﾃｨとｴﾝｼﾞﾆｱﾘﾝｸﾞの人 (@Kengo_TODA) 2026年1月22日
さらに最近、Jaeger本体に MCP（jaegermcp extension）関連の機能追加が入ってきていて、span名探索やcritical path取得など“エージェントから触りたい操作”が揃っていくと期待できます。ここまで来ると、パフォーマンス調査 → レポート化 → 評価、まで自動化できる見込みが立ちます。自分は現時点ではスクリーンショット撮影についてはスキル化しています：
なおJargerはログの表示に対応してないので、自分はOpenTelemetryをtracesとeventsに絞って利用しています。
Agentic Codingと相性が良い理由：ループが速くなるだけじゃない
Agentic Codingの開発ループって、だいたいこうなります：
- エージェントに実装させる
- 動かす
- 遅い／失敗した／意図と違う
- 直す
ここでOTelがないと、ループの途中で毎回こうなります：
- 「多分ここが遅い」→ 当てずっぽう最適化
- 「ログ増やすか」→ ログが増えて余計見づらい
- 「再現条件なんだっけ」→ 記録がない
OTLPでtracesとeventsが取れると、ループがこう変わります：
- 「遅い場所がspanで見える」→ 直す場所が確定
- 「判断がeventで残る」→ 速さの理由が追える
- 「JaegerのJSON/スクショをPRに貼る」→ 変更の証拠が残る
自分のケースでも、“観察できる状態”を先に作ったことで、並列化や最適化を適時に打てて、エージェントから気軽に呼び出せる実行時間に寄せられました。
まず最初の一歩（最小構成）
- CLIにOpenTelemetry SDKを入れて、トップレベルspanを1本切る
- 主要フェーズだけspanを増やす（入力列挙／読み込み／処理本体／出力）
- “判断”だけevent（ログ）で残す
- OTLP exporterでCollector/Jaegerに投げる（ローカルでOK）
- Jaeger UIで遅いtraceをJSON保存（またはスクショ）
この段階でも、「速さの議論」が体感から事実に変わります。
