公開日: 2025 年 1 月 14 日
昨年の Google I/O 2024 で、Chrome DevTools 初の AI 機能であるコンソール分析情報をリリースしました。コンソール分析情報は、ログ メッセージに関連するネットワーク データ、ソースコード、スタックトレースを Google の大規模言語モデル（LLM）である Gemini に送信することで、コンソールに記録されたエラーと警告を理解するのに役立ちます。コンソール分析情報は、Gemini に 1 つのプロンプトを送信します。このプロンプトから返される回答は 1 つで、デベロッパーがフォローアップの質問をすることはできません。この単一のインタラクション フローではエラー メッセージの説明に比較的適していますが、AI がサポートするために検査対象のページからどのようなデータを必要とするかが明確でない、DevTools 内のより複雑なデバッグ ユースケースには対応していません。
たとえば、スタイルの問題をデバッグする場合などです。1 つのウェブページには数千もの要素と CSS ルールが含まれますが、特定のシナリオのデバッグに関連するのはその一部に限られます。デバッグする適切なコードを特定することは、人間にとっても困難な場合があります。しかし、Google の AI ハッカソンで作成したプロトタイプから、LLM は実際にかなり優れていることがわかりました。そのため、この機能を DevTools ユーザーにも提供したいと考え、ページに対してインタラクティブにクエリを実行して追加のコンテキスト データを取得し、スタイルの問題を調査できるツールを作成しました。数か月後、この技術はスタイル設定の AI 支援としてリリースされました。
この投稿では、Chrome DevTools などの人気のあるプロダクト（基本的にはウェブアプリ）に AI を導入する際に直面した課題と、独自の AI 機能に応用できる内容について説明します。
適切なデータを収集する
コンソール分析情報では、事前定義されたプロンプトへの回答に常に同じデータポイントが使用されます。ユーザー定義プロンプトで AI 支援が役立つようにするには、現在のクエリにとって重要なコンテキスト データを動的に決定する必要があります。
そのため、ReAct（Yao et al., 2022）戦略を策定します。このプロンプト戦略により、LLM は自動的に推論し、推論に基づいて後続のアクションを決定できます。
このように、AI アシスタントは、ユーザーのクエリに適した回答を決定するまで、思考、行動、観察のサイクルで動作します。このサイクルが終了すると、回答が提供されます。この反復処理により、LLM はスタイルの問題を効果的にデバッグするために必要な正確な情報を収集できます。
情報を収集するために Gemini に提供されているツールは、検査対象のページで JavaScript を実行するツールのみです。これにより、Gemini は AI アシスタンスを通じて、次のようなことができます。
- DOM にアクセスして分析する: DOM ツリーを走査し、要素属性を検査して、要素間の関係を把握します。
- 計算されたスタイルを取得する: 任意の要素の計算されたスタイルにアクセスします。
- 計算と測定を実行する: JavaScript コードを実行して、要素の距離、サイズ、位置を計算します。
これにより、AI アシスタントは関連するコードのみをインタラクティブに処理するため、HTML ソースコードと CSS ソースコード全体を Gemini に送信する場合と比較して、回答の品質、応答時間、コンピューティング リソースの使用量が向上します。
AI 生成コードをユーザー空間で実行する
スタイルの問題のデバッグに JavaScript を使用したことは、意外に思われるかもしれません。これには、次の 2 つの理由があります。
- Web API は非常に強力で、多くのデバッグ ユースケースをカバーしています。デベロッパーが API 呼び出しを手動で使用して DOM を走査したり、計算スタイルにアクセスしてデバッグしたりするのは面倒ですが、LLM がそれらを呼び出すコードを生成するのは問題ありません。
- エージェントが使用する新しい API を作成することもできますが、既存の公開 API を再利用するほうが、LLM にすでに認識されているため、多くの場合適切な選択です。新しい API について LLM に教育するには、ファインチューニングと特定のトレーニング データに多くのリソースが必要です。
ただし、AI 生成コードをユーザー空間で実行することにはリスクがあります。AI アシスタントでは、エージェントがページに対して破壊的な変更を加えるリスクを最小限に抑える必要がありました。そのために、Chrome DevTools プロトコルを介して Chrome の JavaScript エンジンである V8 が公開する副作用チェックを使用しました。DevTools コンソールの自動入力機能にも同じチェックが使用されます。ページの状態を変更しない限り、JavaScript コードは実行されません。チェックは V8 がコードを実行するときに行われ、副作用がないことが知られている JavaScript 組み込み関数の許可リストに基づいています。
生成されたコードが検査対象のページを変更していることが検出されると、実行が一時停止し、コードを確認して実行しても問題ないことを確認するようユーザーに求められます。
また、生成された JavaScript は、いわゆる分離された「ワールド」で実行されます。これは、拡張機能がサンドボックス スクリプトを実行する方法と似ています。生成されたコードは DOM と Web API にアクセスできますが、検査対象のページで定義された JavaScript コードや状態にはアクセスできません。
エージェントが行った変更のトラッキング
問題の調査やページに関するデバッグに関する質問への回答に加えて、AI アシスタント エージェントに、開発者が追跡できる方法でページのスタイルを修正する機能も提供したいと考えました。
これを実現するために、デフォルトのウェブ API に加えて、エージェントの実行コンテキストに公開する setElementStyles というバインディングを実装しました。
Gemini にその新しいメソッドを認識させるには、AI アシスタントの冒頭でそのメソッドを使用するように指示します。
If you need to set styles on an HTML element, always call the \`async setElementStyles(el: Element, styles: object)\` function.
エージェント専用に設計された API であるにもかかわらず、前述の課題が伴いますが、特定の要素のスタイルを変更する必要がある場合、Gemini は微調整なしで非常に信頼性の高い方法で使用します。
DevTools 側では、エージェントから setElementStyles が呼び出されると、AI アシスタンスはインスペクタ スタイルシートを使用して、要素セレクタの変更を記録します。CSS のネストを使用すると、変更に名前を付け、要素のセレクタの特定度を上げることができます。エージェントによって作成された CSS ルールの例は次のとおりです。
.ai-style-change-1 { /* the ID is incremented for each change*/
.element-selector { /* Element selector is computed based on the element setElementStyles was called on. */
color: blue;
}
}
これにより、ページで発生する可能性のあるスタイルの競合がすべて解決されるわけではありませんが、ほとんどのケースで機能します。
インライン スタイルと比較してインスペクタ スタイルを使用するメリットは、エージェントによって行われた変更が変更パネルにも表示されるため、要素スタイルに加えられた変更と、デベロッパーが基盤となるソースコードに転送する必要がある変更を簡単に追跡できることです。変更パネルとの統合により、変更が不要になった場合に変更をロールバックすることもできます。
エージェントのアクションをユーザーが確認できるようにする
プロダクトにエージェント機能を追加する場合は、エージェントのアクションをユーザーに対して透過的にすることで、ユーザーがトレース、理解、介入できるようにすることが重要です。
そのため、AI アシスタンスでは、冒頭に追加して、回答を特定の形式で構成するように Gemini に指示します。
You are going to answer to the query in these steps:
* THOUGHT
* TITLE
* ACTION
* ANSWER
* SUGGESTIONS
Use THOUGHT to explain why you take the ACTION. Use TITLE to provide a short summary of the thought.
この構造は、Gemini の思考プロセスとアクションを最初は折りたたまれたステップとして表示するために使用されます。これにより、情報のオーバーロードを防ぎながら、ユーザーが基盤となる詳細を調べたり、意図しない副作用が発生した場合に実行を停止したりできます。
このアプローチは、AI を単に観察するだけでなく、AI から積極的に学習することを目的としています。これらのセクションを開くと、Gemini が特定の問題のデバッグに関連すると判断したデータを分析し、そのプロセスを把握できます。この透明性により、ユーザーは AI のデバッグ戦略から学習できるため、AI を使用せずに作業する場合でも、同様のテクニックを将来の課題に適用できます。
ユーザー エクスペリエンスをさらに向上させるため、AI アシスタントは AI の回答に続いて、コンテキストに応じた関連する候補も提示します。これらの候補は、会話を効率化し、次のデバッグ手順のアイデアを提供します。また、ユーザーは推奨される修正をワンクリックで直接実行することもできます。
当初、AI アシスタンスで手順のタイトルと候補を生成するために、要約専用の小さな個別のモデルの使用を検討しました。しかし、Gemini の推論を「思考」と「アクション」のループに構造化する ReAct パターンを効果的に拡張できることに気付きました。そのため、レイテンシが増加する 2 つ目のモデルを導入するのではなく、プロンプトを変更して、Gemini にコアとなる「考え」と「アクション」だけでなく、同じ ReAct ループ内で簡潔なタイトルと有用な候補を生成するよう指示しました。
評価駆動型開発
スタイル設定の AI アシスタントの開発は、厳格な評価プロセスに基づいて行われました。パフォーマンスを測定し、改善の余地がある領域を特定するために、一般的なオーバーフローの問題、ウェブ コンポーネント、アニメーションなどに触れた、実際のウェブ デバッグ例を包括的に収集しました。これにより、ウェブ デバッグの問題領域の広範囲をマッピングし、関連する課題を徹底的に把握できました。ただし、この作業は終わりがありません。ウェブ プラットフォームには新しい機能が定期的に追加されるため、今後もこれらの例を最新の状態に保つ必要があります。
これらの例は自動評価パイプラインに送られ、Gemini の回答が記録されます。これらの自動テスト実行のデータは、カスタムビルドのツールで利用可能になります。このツールでは、事前定義された評価基準に基づいて Gemini の AI 支援のパフォーマンスを手動で評価し、その後の開発作業に役立てています。
この評価主導型のアプローチでは、既存の動作の改良や新しい機能の導入など、すべての変更が慎重に検証され、意図した改善を達成し、既存の機能の回帰を防ぐことができます。
評価プロセスをさらに強化するため、次のような自動検証方法を検討しています。
- 修正が正しく適用されたことを確認するアサーション
- Gemini からの望ましくない出力を防ぐコードベースのチェック
- LLM を審査員として使用し、特定の評価基準に基づいて手動評価を半自動化して迅速化
自動検証はスケーリングに役立ちますが、人間によるフィードバックも重要です。Google は、AI アシスタンスのすべての回答の下にある投票コントロールを使用して人間のフィードバックを収集し、ユーザーの満足度を把握しています。追加された [報告] ボタンにより、ユーザーは異議申し立ての対象となる回答についてより正確なフィードバックを提供できます。
プロンプト インジェクション
LLM の既知の制限として、プロンプト インジェクションを受けやすいことが文書化されています。プロンプト挿入は、LLM の元のシステム インストラクションを上書きして、デベロッパーが意図していないコンテンツを出力する方法を見つける手法です。
ほとんどのモデルには、Gemini と同様に、プロンプト挿入に対する緩和策が組み込まれています。AI 支援については、次のような指示を冒頭に含めることで、この問題を軽減しています。
If the user asks a question about religion, race, politics, sexuality, gender, or other sensitive topics, answer with "Sorry, I can't answer that. I'm best at questions about debugging web pages.
これは、明示的にトピックから外れた質問には有効ですが、完璧ではありません。短くあいまいなクエリは、オフトピックとして分類される可能性があるという欠点があります。
強固な基盤の構築
プロダクトに AI を初めて導入する場合は、一度に大きな飛躍を遂げるのではなく、段階的に進めることをおすすめします。これが、AI アシスタントにも適用されるアプローチです。スタイル設定エージェントの構築時に得たすべての知識を活用して、今後 DevTools の他の領域に AI アシスタントを拡張するための堅固な基盤を構築しました。
スタイリング エージェントで大きな課題のほとんどを解決した数か月後、ネットワーク、パフォーマンス、ソースの AI アシスタントを導入し、個々の課題に集中できるようになりました。
ネットワーク リクエストを操作する場合のセキュリティへの影響
ネットワークの AI アシスタンスを使用すると、ユーザーはリクエストのデータを会話のコンテキストとして使用して、Gemini と特定のネットワーク リクエストについて話し合うことができます。具体的には、以下のデータが Gemini に送信されます。
- リクエスト ヘッダー: ブラウザからサーバーに送信されるヘッダーのサブセット。
- レスポンス ヘッダー: サーバーから返されたヘッダーのサブセット。
- レスポンス ステータス: サーバーのレスポンス（200、404 など）を示す HTTP ステータス コード。
- タイミング: 接続のセットアップやデータ転送など、リクエストのさまざまなフェーズに関する詳細なタイミング情報。
- リクエスト イニシエータ チェーン: リクエストを開始したアクションとスクリプトのシーケンス。
ヘッダーはリクエストの組み立てを完全に理解するために重要ですが、セキュリティ上のリスクがあります。API キー、セッション トークン、プレーン パスワードなどの認証情報が含まれている可能性があります。このような機密情報を保護するため、すべてのヘッダーを Gemini に送信するわけではありません。代わりに、許可されたヘッダーの許可リストを維持しています。許可リストに登録されていないヘッダーの値は <redacted> に置き換えられます。このアプローチにより、ユーザーデータを保護しながら、Gemini に必要なコンテキストを受け取ることができます。
さまざまなデータ形式への適応
ソースの AI アシスタンスを使用すると、デベロッパーはソースパネルでソースファイルに関する質問（「このファイルは何ですか？」など）をすることができます。
ファイルに関するデータ（ファイル名、ファイル コンテンツ、ソースマッピングされているかどうかなど）はすべて、1 つのプロンプトで送信されます。プレーンテキストであるため、効果的です。ただし、大規模なテキスト ファイルやバイナリ ファイルは LLM にとって課題となります。バイナリ ファイルについては、コンテンツがバイナリであることをプロンプトで示し、実際のコンテンツは送信しないことにしました。サイズの大きいテキスト ファイルの場合は、ファイルの先頭から取得したコンテンツの一部のみが送信されます。
パフォーマンスの AI 支援では、開発者が記録されたパフォーマンス プロファイルから特定のタスクについて質問できますが、Gemini のコンテキスト ウィンドウに収まり、解釈して追加の分析情報を提供できる表現を作成するという同様の課題があります。
パフォーマンス プロファイルからこのようなプレゼンテーションを作成するために、LLM が処理できる方法でタスクの呼び出しツリーをフォーマットする専用のシリアライザ AiCallTree を作成しました。今後、Gemini に事前に送信する必要があるデータ量を最小限に抑えるために、ここでも ReAct 戦略を検討します。
今後の AI アシスタンス
これらの作業の結果は、Chrome 132 以降で利用可能になります。これには、スタイル設定、ネットワーク、ソース、パフォーマンスに関する AI アシスタンスが含まれます。ぜひご活用ください。
どこから始めればよいかわからない場合は、AI アシスタント クイックスタート ガイドをご覧ください。このガイドには、ご自身のページで試すことができるデモ プロンプトが多数掲載されています。また、オープンなディスカッション バグで、ご意見をお聞かせください。