同一エンドポイントの一括処理で、件数あたりの処理時間が実測で大きくばらつく（例: 600件で2分、同じ時間帯の別トレースは10秒台）ときの切り分け手順。

切り分け: 遅いトレースと速いトレースを APM/フレームグラフで並べ、span 数を比較する（例: DB span 933 vs 247、検索エンジン span 29 vs 5）。単発の遅いSQLや検索障害でなく同じ処理単位が何度も繰り返されているなら、関連更新の展開量（fan-out）が数倍になっている。span 種別ごとの回数（例: bulk index が26回、設定取得系が30回台）で反復のホットスポットを特定する。

典型的な fan-out の原因: あるレコードの更新が集計依存項目に該当すると、関連オブジェクトの集計更新→さらにその関連レコードの検索インデックス再構築まで連鎖する。同じベンチマークの軽い更新と同じコストで見積もると、集計・再インデックスが大きく展開する worst-case パターンで大きく外す。

対応方向: 集計・再インデックスを伴う重い更新は、件数が少なくても非同期化するか同期/非同期の閾値を下げる。まずは実測で最悪パターンの展開量を把握してから判断する。