AI エージェントのセッションが「体感で遅い」とき、往復の多さや委譲待ちなどワークフロー側を疑いがちだが、リーダー自身のテキスト生成が支配的なことがある。対策を選ぶ前に、セッションログ（イベントごとの timestamp と token usage が残る形式）から遅さの帰属を実測する。

手順

1. ツール呼び出しと結果イベントを id で突合してツール実行時間を出す。
2. 残りのイベント間ギャップを「直前のイベント種別＝何を待っていたか」で分類する: ユーザー応答待ち／委譲・バックグラウンド実行待ち／モデル生成。委譲先が動いている間の待ちをユーザー待ちと混同しないよう、バックグラウンドタスクの起動〜完了通知の区間と突き合わせる。
3. アシスタントメッセージの output_tokens を合計し、直前イベントからメッセージ完了までの経過時間で割って実効生成速度（tok/s）の中央値を出す。

切り分けの判断基準

• 「出力トークン合計 ÷ 実測 tok/s」がセッション実働時間に迫るなら生成起因。対策は出力量の削減（報告様式の規定・中間報告の差分化）か生成の速いモデルで、ワークフロー組み替えでは直らない。
• コンテキスト肥大が容疑のときは、キャッシュ読み取りのヒット状況とコンテキストサイズ推移×速度の相関を見る。キャッシュがヒットし続けていればコンテキストが数倍に育っても速度は落ちず、無罪と確定できる。
• ツール実行時間が小さい（合計数分・最長数十秒）なら環境側の最適化は後回しでよい。

実測例（一般化）

壁時計136分のセッションで、リーダー出力238kトークン×中央値45tok/s ≒ 約88分が純粋な生成時間だった。内訳では中間報告・完了報告・記録転記が3〜4割を占め、報告様式の規定だけでレビュー品質に触れずに削減できると判断できた。体感では委譲待ちが犯人に見えていたため、実測しなければ対策を誤っていた。

検証

対策導入後のセッションで同じ集計を再実行し、生成時間の比率と実働時間が下がったかを比較する。