AIエージェントでINPを修正する：ラボツールでは測定できない指標

Interaction to Next Paintは、AIエージェントにとって最も難しいCore Web Vitalsです。シミュレーションすることはできません。LighthouseにはINPスコアがありません。実際のユーザーデータを持たないAIエージェントは、どのインタラクションが遅いのか、誰がそれを経験しているのか、ページのライフサイクルのいつ発生するのかを伝えることができません。これは、フィールドデータがある場合にINPを修正する方法です。

最終レビュー：Arjen Karel (2026年3月)

なぜAIエージェントにとってINPは異なるのか

INPは、サイトがユーザーのインタラクション（クリック、タップ、キー入力）にどれだけ速く応答するかを測定します。セッション全体から最も悪い単一のインタラクションを抽出します。キーワードは「リアル」です。サードパーティの分析スクリプトが実行されている間に、ユーザーが製品ページのフィルタードロップダウンをクリックしたとします。その380ミリ秒の遅延が、そのセッションのINPになります。

これを再現できるラボツールはありません。LighthouseはTotal Blocking Time (TBT) を代用として使用しますが、TBTはページロード中のメインスレッドのブロックを測定します。INPは、セッション中の予測不可能なタイミングで発生するインタラクションへの応答時間を測定します。TBTがゼロのページでも、バックグラウンドのタイマーが不適切なタイミングで起動した場合、INPがひどい結果になる可能性があります。フィールドデータを持たないエージェントは、このことに気づきません。TBTを最適化して勝利を宣言しますが、実際のユーザーはクリックが登録されるまで400ミリ秒も待たされているのです。

3つのフェーズ、3つの異なる修正

INPは3つのフェーズに分かれます。それぞれが異なる修正を意味します。

Input Delay: ユーザーがインタラクションしたとき、メインスレッドがビジー状態でした。ローディング状態における一般的な原因は、大規模なJavaScriptバンドルの実行、分析スクリプトの初期化、またはフレームワークのハイドレーションです。完了状態（ページが完全にロードされた状態）では、バックグラウンドタイマー、更新をポーリングするサードパーティスクリプト、またはサービスワーカーのアクティビティが原因となります。

Processing: イベントハンドラー自体が遅すぎます。レイアウトスラッシング（DOMの読み取り、DOMの書き込み、DOMの読み取りをループで繰り返す）、ハンドラー内の同期的なDOMクエリ、コストのかかる再レンダリング、またはyieldせずに単一のタスクで単に多くの処理を行いすぎていることが原因です。

Presentation: ハンドラーの終了後、ブラウザの描画に時間がかかりすぎています。大規模なDOMツリー（スタイルの再計算が必要な何千ものノード）、CSSコンテインメントの欠如、またはハンドラーのDOM変更によって引き起こされるコストのかかるペイント操作が原因です。

どのスクリプトがページをブロックしているか

CoreDashは、実際のユーザーセッションからLong Animation Frames (LoAF) のアトリビューションをキャプチャします。これにより、エージェントは推測するのではなく、実際にINPを修正することができます。

LoAFは、正確なJavaScriptファイル、関数、および所要時間を特定します。エージェントは、どのスクリプトがメインスレッドをブロックしているかを推測しません。CoreDashがそれを教えてくれます：チェックアウトページのフィルターでのインタラクション中に、gtm-container.jsがメインスレッドを280ミリ秒ブロックしました。

「ページが遅い」という情報の代わりに、「このファイル、この関数、この時間」という情報が得られます。Total Blocking Timeが450ミリ秒であることを伝え、30個のスクリプトのうちどれが原因かを自分で突き止めるように委ねるLighthouseと比較してみてください。

エージェントはファイルを開き、コードを読み、修正を書き込みます：遅延させる、小さなタスクに分割する、または誰も必要としていない場合は削除します。

ロード中 vs ロード完了：2つの異なる問題

インタラクションがloading状態の間に発生したか、complete状態の間に発生したかによって、修正は完全に変わります。

ローディング状態でのみINPが悪い場合、問題はスクリプトのロード順序にあります。ページがインタラクティブになる前に実行されるJavaScriptが多すぎます。修正はスクリプトの遅延にあります：非クリティカルなスクリプトを遅延させ、コード分割を行い、パーサーをブロックするJavaScriptを減らします。

完了状態でINPが悪い場合は、ランタイムのJavaScriptの問題があります。完全にロードされたページで、何かがバックグラウンドで実行されています。更新をポーリングするサードパーティのスクリプト、ビーコンを送信するアナリティクス、または独自のコードがタイマーでコストのかかる操作を実行していることなどが挙げられます。

CoreDashは、すべてのINP測定においてページのロード状態を追跡します。CWV Superpowersはこれを使用して、スクリプトを調べる前に原因の半分を除外します。

INPにおける比例的推論

チェックアウトページでのINPは350ミリ秒です。フィールドデータからのフェーズ内訳は次のとおりです：

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

Presentationがボトルネックです。200ミリ秒という数字は、それ単体では驚くようなものではありません。しかし、全体の57%を占めています。Presentationを修正することは、Input DelayやProcessingを合わせて最適化するよりも大きな効果をもたらします。

パーセンテージがない場合、エージェントは70ミリ秒が何らかのしきい値を超えているという理由でInput Delayを追いかけます。内訳を示すと、エージェントはまっすぐ57%に取り組みます。結果として、INPを200ミリ秒未満に下げる1つの修正と、ほとんど効果のない3つの分散した修正という違いが生まれます。

フェーズ別の典型的な修正方法

ローディング中のInput Delay: 非クリティカルなスクリプトを遅延させます。未使用のJavaScriptを削除します。現在のページのコードのみがロードされるようにコード分割を行います。

完了時のInput Delay: ページロード後に実行されるサードパーティのスクリプトを監査します。CoreDashのLOAFデータを使用して、問題のあるスクリプトを見つけます。requestIdleCallbackを使用してアイドル時間に遅延させます。

Processing: scheduler.yield()またはsetTimeout(0)を使用してメインスレッドにyieldします。長いイベントハンドラーをより小さなタスクに分割します。強制的な同期レイアウト（DOMに書き込んだ直後にレイアウトプロパティを読み取ること）を避けます。

Presentation: ファーストビュー以下の大きなDOMセクションにはcontent-visibility: autoを使用します（2025年9月以降、すべての主要ブラウザでサポートされています）。ハンドラーの変更によって影響を受けるDOMノードの数を減らします。CSSコンテインメントを使用して、再描画をより小さな領域に分離します。

フィールドデータでの検証

INPの改善は、実際のトラフィックの1〜2日以内にCoreDashに表示されます。同じページとデバイスセグメントを照会します。p75が低下し、フェーズの分布がシフトするはずです。

ロード状態の分割にも注目してください。修正がローディング状態のINPをターゲットにしている場合は、完了状態の数値が後退することなく、ローディング状態の数値が改善していることを確認します。フィールドデータはこのような詳細度を提供します。ラボデータではそうはいきません。