公開日: 2025 年 1 月 14 日
昨年の Google I/O 2024 で、Chrome DevTools 初の AI 機能であるコンソールの分析情報をリリースしました。コンソール分析情報は、ログ メッセージに関連するネットワーク データ、ソースコード、スタックトレースを Google の大規模言語モデル（LLM）である Gemini に送信することで、コンソールに記録されたエラーと警告を理解するのに役立ちます。Console Insights は、Gemini に 1 つのプロンプトを送信します。Gemini は 1 つのレスポンスを返しますが、デベロッパーがフォローアップの質問をすることはできません。この単一のインタラクション フローは、エラー メッセージの説明には比較的適していますが、AI がサポートするために検査対象のページからどのようなデータを必要とするかが明確でない、DevTools 内のより複雑なデバッグ ユースケースには対応していません。
そのようなユースケースの 1 つが、スタイルの問題のデバッグです。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 Console の自動入力機能でも同じチェックが使用されます。ページの状態を変更しない限り、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 の回答に続いて、コンテキストに応じた関連する候補も提示します。これらの候補は、次のデバッグ手順のアイデアを提供したり、ユーザーが推奨される修正を 1 回のクリックで直接実行したりすることで、会話を効率化します。
当初、AI アシスタンスでの手順のタイトルと候補を生成するために、要約専用の小さな個別のモデルの使用を検討しました。しかし、Gemini の推論を「思考」と「アクション」のループに構造化する ReAct パターンを効果的に拡張できることがわかりました。そのため、レイテンシが増加する 2 つ目のモデルを導入するのではなく、プロンプトを変更して、Gemini にコアとなる「考え」と「アクション」だけでなく、同じ ReAct ループ内で簡潔なタイトルと有用な候補を生成するよう指示しました。
評価ドリブンの開発
スタイル設定の AI アシスタントの開発は、厳格な評価プロセスに基づいて行われました。パフォーマンスを測定し、改善できる部分を特定するために、一般的なオーバーフローの問題、ウェブ コンポーネント、アニメーションなどに触れた、実際のウェブ デバッグ例を包括的に収集しました。これにより、ウェブ デバッグの問題領域の広範囲をマッピングし、関連する課題を徹底的に把握できました。ただし、この作業は終わりがありません。ウェブ プラットフォームには新しい機能が定期的に追加されるため、今後もこれらの例を最新の状態に保つ必要があります。
これらのサンプルは自動評価パイプラインに送られ、Gemini のレスポンスが記録されます。これらの自動テスト実行のデータは、カスタムビルドのツールで利用可能になります。このツールでは、事前定義された評価基準に基づいて Gemini の AI 支援のパフォーマンスを手動で評価し、その後の開発作業に役立てています。
この評価主導型のアプローチでは、既存の動作の改良や新しい機能の導入など、すべての変更が慎重に検証され、意図した改善を達成し、既存の機能の回帰を防ぐことができます。
評価プロセスをさらに強化するため、Google は次のような自動検証方法を検討しています。
- 修正が正しく適用されていることを確認するアサーション
- 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 アシスタント クイックスタート ガイドをご覧ください。このガイドには、ご自身のページで試すことができるデモ プロンプトが多数掲載されています。また、オープンなディスカッション バグで、ご意見をお寄せください。