AI エージェントとの長時間セッションが「遅かった」と感じたとき、体感で原因（レビューが長い、生成が遅い等）を決めつけず、セッションログのイベントタイムスタンプから時間内訳を実測してから対策を選ぶ。コーディングエージェントのセッションログは各イベント（ユーザー入力、アシスタント応答、ツール開始・終了、ターン所要時間の記録、離席時サマリ、入力キューの enqueue/dequeue）にタイムスタンプを持つため、連続イベント間のギャップを「直前のイベント種別＝何を待っていたか」で分類集計できる。

手順

• ツール呼び出しはツール開始イベントと対応する結果イベントを id で突き合わせ、実行時間を出す。
• それ以外のギャップは直前イベントで分類する: アシスタント最終応答→次のユーザー入力はユーザー応答待ち、ユーザー入力・ツール結果→アシスタント応答はモデル生成時間、委譲エージェントからの報告待ちは委譲待ち。
• ログにターン所要時間の記録イベントがあれば、それがアシスタント実働時間の正解値になり、ギャップ分類の検算に使える。

落とし穴

• 壁時計時間にはユーザーの離席が丸ごと含まれる。実測すると壁時計の大半（今回の実測では約8割）がユーザー応答待ちで、実働の内訳と壁時計の内訳はまったく別物になる。改善対象を選ぶ前にまず両者を分離する。
• 一律間隔で並ぶギャップ（数分刻みの同一イベント種別の連続など)は、ハーネスの周期処理（離席サマリ生成等）であることがある。ギャップを分類へ算入する前にイベントの中身を確認し、待ち時間と周期処理を混同しない。
• ツール実行時間の合計は体感より圧倒的に小さいことが多く（今回の実測では7時間半のセッションで約3分）、遅さの主因は生成時間・委譲待ち・人間の応答待ちのいずれかに出やすい。

検証

分類済みカテゴリの合計が壁時計時間とほぼ一致すること、ターン所要時間の記録値と「生成時間＋ツール実行」の推定が近いことを確認する。ずれが大きければ分類ルール（どのイベント種別をどの待ちに割り当てたか）を見直す。