※本記事は、Philip Walton氏による講演「Unlock modern web capabilities in your AI coding workflows」の内容を基に作成されています。本講演はGoogle I/O 2026におけるChromeセッションの一つとして行われたものです。動画の詳細情報は https://goo.gle/Chrome-at-IO2026 でご覧いただけます。本記事では、講演の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、関連リソースであるModern Web Guidance(https://goo.gle/4uaZsJt)、およびChrome for Developersのチャンネル(https://goo.gle/ChromeDevs)もあわせてご参照ください。
登壇者紹介: Philip Walton氏 ― Google Chromeチームのエンジニア。本講演では、AIコーディングエージェントがモダンなウェブプラットフォームの機能を十分に活用できていないという課題を指摘し、その解決策としてChromeチームが開発した「Modern Web Guidance」を紹介しています。
1. オープニング:2つのデモ比較とAIコーディングエージェントが抱える3つの課題
1.1 同一条件で生成した2つのデモの比較
皆さん、こんにちは。Philip Waltonです。まず最初に、私が録画した2つのデモの画面収録をお見せしたいと思います。この2つのデモは、見た目も動作もまったく同じです。どちらもドロップダウンメニューが滑らかにアニメーションで開閉し、完全にキーボードでの操作に対応しており、どちらもライトディスミス(外側をクリックすると閉じる操作)にも対応しています。そして両方ともChrome、Firefox、Safariで問題なく動作します。さらに、この2つのデモはどちらもAIによって生成されたものです。それも、同じコーディングエージェント、同じモデル、同じプロンプトを使って生成しています。唯一の違いは、左側のバージョンはエージェントを標準のデフォルト設定、つまり何も手を加えていない状態で生成したものであり、右側のバージョンは同じエージェントに、ある1つのものだけを追加でインストールして生成したものだという点です。これについては後ほど詳しくお話しします。
しかし、この2つのデモにはもう1つ大きな違いがあります。DevToolsを開いてNetworkパネルを拡大してみると、左側のバージョンは172キロバイトを読み込んでおり、そのほとんどがJavaScriptであることが分かります。一方、右側のバージョンは3キロバイト未満しか読み込んでおらず、しかもJavaScriptを一切使用していません。念のため申し添えておくと、この172キロバイトという数字は、圧縮(minify)とgzip化を行い、本番環境向けの最適化をすべて有効にした状態でのネットワーク転送量です。そして私はこのコードにいっさい手を加えていません。これはAIが提案してきたそのままのものです。もちろん、これは設定メニューだけのアプリというのはほとんど存在しないという意味で、いくぶん作為的な例ではあります。実際にはもっと多くの機能を追加していけば、JavaScriptもある程度は必要になってくるでしょう。それでもなお、私はここに興味深い問いが浮かび上がると思っています。まったく同じ機能を、ブラウザ間の互換性を保ちながらJavaScriptをまったく使わずに実装できるにもかかわらず、なぜAIコーディングエージェントは172キロバイトものJavaScriptを必要とするソリューションを推奨してくるのでしょうか。
本日、先ほどまでの他のセッションに参加されていた方は、AIがいかに素晴らしいかという話を数多く聞かれたことと思います。誤解のないように言っておきますが、AIは本当に素晴らしいものです。私自身、毎日その進化に驚かされています。しかし、それは物事の一面に過ぎません。実際のところ、AIはソフトウェア業界を一変させ、私たち開発者がこれまでにないスピードでコードを書けるようにしてくれましたが、その一方でもう1つの側面も存在します。AIは決して完璧ではないのです。もし皆さんが私と同じように、著名なフロントエンド開発者たちをSNSでフォローしているなら、彼らの多くがこれらのAIコーディングエージェントがいかに不完全であるか、特にHTMLとCSSの記述に関していかに問題が多いかを、遠慮なく指摘しているのをご存知でしょう。そして、彼らの指摘は間違っていません。
1.2 課題1:レガシーな実装を推奨しがちな傾向
この数年間、ウェブの世界では実に素晴らしい進化が数多く起きてきました。それにもかかわらず、コーディングエージェントに何かをウェブ上で作ってほしいと頼んでも、たとえ最新のウェブプラットフォームの機能がその用途にとって最善の選択肢であったとしても、エージェントはまずそれを選んでは来ません。これは、これらのモデルの学習データの多くが、多くの開発者がInternet Explorerのようなレガシーブラウザをサポートしなければならなかった時代に書かれたものであることを考えれば、さほど驚くことではありません。しかし理由が何であれ、現実として、フロントエンドのウェブ開発においては、より優れたモダンな代替手段が存在するにもかかわらず、コーディングエージェントはレガシーなソリューションを推奨する傾向にあります。
1.3 課題2:モデルの知識ギャップ・盲点
私たちが見ているもう1つの大きな問題は、AIモデルには知識のギャップがあるという点です。すべてのモデルには学習データのカットオフ日があり、その日付以降にウェブ上で起きた新しい進展は、モデルの学習データにはまったく含まれていません。この1年だけを見ても、Chromeは50個以上のまったく新しいウェブ機能を出荷しています。しかし、こうした知識のカットオフのために、これらの機能の多くはモデルにとって完全に未知のものとなっています。RAGやWeb検索のような技術はこの問題の緩和に役立ちますが、問題を完全になくすことはできません。もしコーディングエージェントに、それが一度も聞いたことのない機能を使うよう指示すれば、たいていはWeb検索を行います。しかし、すでに知っていると思い込んでいることを指示された場合は、最新の情報を確認することなく、自信満々にそのまま答えてしまうことが多いのです。
一例を挙げます。これは、新しいInterest Invokers APIを使ってツールチップを作るようエージェントに依頼した際に生成されたコードです。ハイライトされた行をよく見ると、モデルがinteresttargetという属性を使用していることが分かりますが、これは正しくありません。interesttargetは、このAPIが2023年に最初に提案された当初の属性名でした。しかし、昨年秋にこのAPIがChromeに実装される直前に、属性名はinterestforへと変更されたのです。つまり、画面に表示されているコードはブラウザ上で実行しても静かに失敗してしまい、デバッグを非常に難しくしてしまいます。このAPIに関するこの特定の問題は、おそらく次世代のモデルでは修正されるでしょう。しかし、より大きな問題自体は、当面のあいだなくなることはありません。
1.4 課題3:クロスブラウザ対応判断が過度に保守的
私たちが見ている3つ目の問題は、AIモデルがクロスブラウザ対応をどのように判断しているかという点です。私たちが行ったテストでは、AIはクロスブラウザ対応に関して、必要以上に保守的な判断をしていることが分かりました。これらのモデルやツールの開発者が幅広い互換性を最適化しようとするのは理解できます。しかし今では、ほぼすべてのウェブ機能の互換性データを網羅しているBaselineのような取り組みがある以上、それを活用しない理由はもはやありません。エージェントは、画一的で一律のブラウザサポートの推奨を行うべきではなく、皆さんそれぞれのプロジェクトの実際の要件に合わせて推奨内容を調整すべきなのです。
以上が、モダンなウェブ開発に関してAIコーディングエージェントに見られる主な問題の概要です。まとめますと、第一に、AIコーディングエージェントは、より優れたモダンな代替手段が存在するにもかかわらず、レガシーなパターンを頻繁に推奨してしまいます。第二に、AIモデルには知識の盲点があり、最新のウェブプラットフォーム機能について認識していないか、誤った情報を持っています。そして第三に、AIモデルは、実態にそぐわない画一的なブラウザサポートの推奨をしがちです。しかし朗報なのは、私たちChromeとしては、これらの問題はすべて十分に解決可能だと考えているということです。
2. Modern Web Guidanceの概要と仕組み
2.1 2段階のガイダンス構成
そして、私たちはここChromeにおいて、こうした問題を解決するために懸命に取り組んでまいりました。本日はその成果として、早期プレビュー版を皆さんにご紹介できることを大変嬉しく思います。私たちはこれをModern Web Guidanceと呼んでいます。Modern Web Guidanceとは、モダンウェブの構築に関するChromeのベストプラクティスすべてを網羅した、包括的かつ専門家によって検証済みのスキル群です。このパッケージは、Chromeが長年培ってきたウェブプラットフォームに関する知見を、そのまま皆さんのコーディングエージェントに直接組み込むものです。そして、これはスキルというかたちをとっているため、どのAIコーディングプラットフォームでも動作します。
Modern Web Guidanceは、2つの異なるレベルのガイダンスから構成されています。まず1つ目は、パフォーマンス、アクセシビリティ、セキュリティ、ユーザーエクスペリエンスといった、ウェブ開発における幅広い分野のベストプラクティスを体系化した、高レベルのガイド群です。そしてこれに加えて、プラットフォームに最近追加されたウェブ機能を対象とした、非常に具体的な低レベルのガイド群も用意しています。私たちが確認したところでは、AIモデルはこうした新しい機能をどのように適切に使えばよいか、まだ十分に理解できていません。これらのガイドはすべて、Chromeチームのメンバーが、このプロジェクトのために採用した外部の専門家の方々と協力して作成したものです。そして、これらのガイドはコアとなるウェブプラットフォームの機能に焦点を当てているため、皆さんがどのフレームワークやスタックを使っていようと関係なく機能します。
2.2 インストール方法と他のスキルパックとの違い
こうしたガイドの具体的な内容に踏み込む前に、まずはこのツールが全体としてどのように動作するのか、簡単にご紹介しておきたいと思います。Modern Web Guidanceは、npx modern-web-guidance installという1つのコマンドでインストールできます。あるいは、画面に表示されているようなIDEやコーディングエージェントをお使いの場合は、それらのツール内から直接見つけてインストールすることも可能です。
正直に申し上げますと、今まさに市場は新しいスキルのリリースで溢れかえっています。開発者としては、これに追いつくのはなかなか大変で、時には圧倒されてしまうほどです。また、どのスキルが良質で使う価値があるのか、そしてどのスキルが正直なところ単なる「スロップ」に過ぎないのかを見極めるのも、特に難しいことです。ですから、ここで強調しておきたいのは、Modern Web Guidanceは皆さんが普段目にするような普通のスキルパックとは違うということです。これは私たちChromeチームがこの半年間、多大な労力を注ぎ込んできたものであり、そして長期にわたって投資を続けていくことを約束しているものでもあります。
2.3 通常フローとの比較
それでは、これに何が含まれていて、どのように動作するのか、もう少し詳しく見ていきましょう。皆さんが標準の状態でコーディングエージェントを使う場合、その流れは非常にシンプルです。ユーザーがツールにプロンプトを入力すると、そのプロンプトがAIモデルに渡され、モデルが出力結果を生成します。一方、Modern Web Guidanceを使用している場合は、AIが出力を生成する前に、Modern Web Guidanceのパッケージ内でローカルにセマンティック検索を実行し、プロンプトに含まれるユースケースに合致するガイドがないかを確認します。もし一致するガイドが見つかれば、それらのガイドがコンテキストウィンドウに追加されます。一致するものが見つからなければ、AIは通常どおりに応答します。
2.4 単一エントリーポイントスキル+CLI検索を採用した理由
ここで注意していただきたいのは、これはほとんどのスキルの仕組みとは少し異なるという点です。一般的なスキルでは、それぞれが独立した1つのスキルのMDファイルとして存在します。しかしModern Web Guidanceでは、単一のエントリーポイントとなるスキルを公開しており、そのスキルが検索を行うCLIにアクセスするという構成をとっています。このような設計にしている理由は、現時点ですでに100を超える個別のガイドが存在しており、今後さらに数百単位で追加していく予定があるからです。そのため、これらすべてを個別の最上位スキルMDファイルとして公開するというやり方は、単純にスケールしないのです。
3. 低レベルガイドの設計思想とクロスブラウザ・フォールバック戦略
3.1 「ユースケース」起点の設計思想
それでは、これらのガイドが実際にどのようなものなのか、もう少し詳しく見ていきましょう。先ほど、私たちは高レベルの分野別ガイドと低レベルの機能別ガイドの両方を用意しているとお話ししました。高レベルのガイドは、皆さんがこれまでにご覧になったことのあるであろう一般的なスキルと非常によく似たものです。しかし、低レベルの機能別ガイドについては、私が個人的に非常に画期的だと思っているアプローチを採用しましたので、これについてお話ししたいと思います。
まず1つ目の特徴として、私たちはこれらの機能そのものに焦点を当て、その機能がどのように動作するかを文書化するのではなく、それぞれのガイドを、ある機能によって実現される、あるいは実装が容易になる、明確な1つのユースケースに焦点を当てるかたちで構成しました。たとえば、View Transitions APIについて私たちが特定したユースケースの1つに、「異なるページの状態やナビゲーションをまたいで存続する要素を、サイズ、位置、その他のスタイルプロパティを滑らかにモーフィングさせることで視覚的につなげる」というものがあります。具体例を挙げると、商品一覧ページのサムネイル画像を、商品詳細ページのフルブリードのヒーロー画像へと展開させるようなケースです。
ここで注目していただきたいのは、このユースケースの説明には、View Transitions APIという言葉がまったく出てこないという点です。その代わりに、開発者が実装したい、あるいは達成したいタスクそのものを記述しており、たまたまそのタスクを実装するのに最適な選択肢がView Transitions APIであった、という構成になっています。これは非常に重要なポイントです。というのも、開発者は通常、特定の機能を使うようにコーディングエージェントにプロンプトを送るわけではないからです。開発者はそもそも、そうした機能が存在すること自体を知らない場合すらあります。その代わりに、開発者は実現したいユースケースをプロンプトとして伝えてきます。ですから、私たちのガイドは、開発者が実際に使うプロンプトの内容に合致するように設計する必要があったのです。
3.2 AI消費に最適化した記述
これらのガイドが持つ2つ目の側面は、AIによる読み込みに最適化されているという点です。具体的に言うと、それぞれのガイドは簡潔であり、要点をまっすぐに述べ、AIがそれに正しく従うために必要な最小限の情報だけを含んでいます。これは、Web検索を行うよりも効率的です。なぜなら、たとえエージェントがWeb上で最新かつ正確な情報を見つけられたとしても(それすら保証されているわけではありませんが)、その内容をすべて読み込み、大量のトークンを消費して、ようやく皆さんのユースケースに関連する部分を見つけ出さなければならないからです。あるいは、そもそも見つけられないかもしれません。それに対して、私たちのガイドはすでにユースケースに応じてスコープが絞り込まれており、すでに検証・テスト済みで正確性が担保されており、そして皆さんのデバイス上にすでにローカルに存在しています。
3.3 クロスブラウザ・フォールバック機能
そして3つ目に、それぞれのガイドには、そのユースケースの実装がブラウザ間でも確実に動作するよう、私たちの具体的な推奨事項とフォールバック戦略を記載したセクションを含めています。ここからは、このクロスブラウザ・フォールバックのガイダンスについて詳しくお話ししたいと思います。私個人としては、これがこのツールの中で最も優れた機能だと考えているからです。仕組みを説明させてください。
各ガイドでは、まず、利用可能な最も新しいソリューションを用いた理想的な実装を記述するところから始めます。このガイドのこの部分については、ブラウザサポートをいっさい考慮していません。私たちは、どのような機能でも使用できるという前提に立ち、そのタスクに最適な機能を選びます。このようにしている理由は、新しい機能を試している方々、ブラウザ拡張機能を作っている方々、Electronアプリを構築している方々、社内向けのツールを作っている方々など、クロスブラウザ対応が大きな関心事ではないあらゆる状況にある方々をサポートしたいからです。私たちは、皆さんの状況が許すのであれば、AIツールが新しいAPIの利用を妨げるようなことがあってほしくないのです。
3.4 Baseline基準とAGENTS.mdの活用
とはいえ、理想的な実装に含まれる機能のいずれかがBaselineの「Widely Available(広く利用可能)」に該当しない場合は、必ずフォールバックの推奨事項も併せて記載しています。そして可能な限り、そのフォールバックの推奨事項がブラウザ間で確実に動作するようにしています。唯一の例外は、WebMCPのように、そもそもクロスブラウザのフォールバックが存在しないようなケースです。しかしそれ以外のすべてのケースでは、クロスブラウザのフォールバックが存在する限り、私たちはそれを採用します。そして、フォールバックが存在しない場合は、その機能が一部のブラウザでしか利用できないことを明確に示し、適切なフィーチャー検出の方法を提示します。
このように、まず完全にモダンな実装から始めて、その後にフォールバックへと進むという2層構造のアプローチを採用しているのは、エージェントが皆さんのサイトのブラウザサポート要件に応じて、そのユースケースの実装方法を選択できるようにするためです。そしてこれが、このパッケージにおいて私が最後にお話ししたい機能、すなわちBaseline連携につながります。
先ほど申し上げたとおり、私たちはコーディングエージェントが、皆さんのブラウザサポート要件に基づいて実装をカスタマイズできるようにしたいと考えています。そしてこれを実現するためには、2つのことが必要です。まず1つ目に、皆さんが自分のエージェントに対して、どのベースラインターゲットあるいはどのブラウザをサポートしているのかを伝える必要があります。エージェントは、プロジェクト内のさまざまな設定ファイルからこの情報を推測したり、あるいは推し量ったりすることもできますが、私たちとしては、明示的に伝えていただく方が良いと考えており、この情報をAGENTS.mdファイルに直接記載することを推奨しています。もし皆さんが特定のブラウザサポート情報を宣言しない場合、エージェントは「Widely Available」を前提として動作します。
2つ目に、それぞれのガイドのフォールバックのセクションには、詳細なブラウザ互換性データを含めています。これにより、エージェントは、皆さんがAGENTS.mdファイルに記載したブラウザサポート要件に基づいて、特定のフォールバックが必要かどうかを判断できるようになります。たとえば、皆さんがElectronアプリを構築していて、AGENTS.mdにChrome 144以降のみをサポートすればよいと設定した場合、エージェントがChrome 115で実装されたscroll-driven animationsのようなもののフォールバックに遭遇したとしても、エージェントはその推奨事項を無視して、モダンな実装のままにしておくことができます。このようにして、常に最小公倍数的なアプローチをとるのではなく、それぞれのガイドの実装を皆さんのプロジェクトの具体的なブラウザサポート要件に合わせて、カスタムに調整することができるのです。
4. 評価(Eval)による効果検証と今後の展望
4.1 evalを重視する方針とeval suiteの規模
以上が、Modern Web Guidanceについての簡単な概要です。おそらく皆さんの多くは、この時点で「なるほど、素晴らしそうだけれど、実際のところどれくらいうまく機能するのか」と思っていらっしゃることでしょう。もちろん、実際に動作している様子をご覧いただけるデモもこの後ご用意していますが、その前に、この質問には直接お答えしておきたいと思います。私はこれが重要な質問だと考えているからです。私たちは業界として、自分たちが使っているスキルの効果を評価できるようにしておくべきだと思います。このプロジェクトを始めた当初から、私たちが掲げていた主な要件の1つは、私たちが使用するすべての機能について、厳密な評価(eval)を用意するということでした。
現時点で、私たちの評価スイートには、私たちのガイダンスのほとんどをカバーする554個の個別のアサーション(検証項目)が含まれています。そして、今年後半の安定版リリースまでに、これを完全なカバレッジへと拡張する計画です。
4.2 対象モデルと合格率比較
そして私たちは、この評価スイート全体を毎日、多くの人気のあるAIコーディングモデルに対して実行しています。現時点では、Gemini 3.1、Claude Opus 4.7、そしてGPT 5.5が対象に含まれています。画面には、これらすべてのコーディングモデルにわたる、これらすべての評価の集計結果を可視化したものを表示しています。右側の緑色の数字は、Modern Web Guidanceをインストールした状態で動作しているエージェントの、評価アサーションの平均合格率を示しています。そして左側の数字は、まったく同じアサーションの集合に対して、今度はModern Web Guidanceをインストールせずに動作しているエージェントの平均合格率を示しています。私たちはこれを「ガイドありとガイドなしの合格率」と呼んでいます。ご覧いただけるとおり、ガイドありのエージェントは、ガイドなしのエージェントよりも明確に優れたパフォーマンスを発揮しています。まだ100%には達していませんが、私たちはこの数字をできる限り高めるために、ガイドと評価の両方を積極的に調整し続けています。
では、これらの個々の評価は具体的にどのようなものなのでしょうか。それは実質的に、私たちがエージェントに与えるプロンプトと、そのエージェントの出力に対して実行する一連のアサーション、つまりテストのセットです。ここで、私たちのスクロール進捗インジケーターのユースケースに関する最近の評価の例をご紹介します。画面に表示されているプロンプトを実行し、以下のアサーションを実行してガイドへの準拠を検証しました。このユースケースでは、テストは、実装がscroll-eventリスナーに頼るのではなく、scroll-driven animationsを正しく使用しているかどうかを確認します。ご覧のとおり、この特定のインスタンス、この特定の実行においては、私たちのガイダンスを使用した場合はすべてのテストが合格しました。そして、ガイダンスを使用しなかった場合は、そのすべてが不合格となりました。
4.3 個別eval例と今後の運用方針
これは現時点でのこれらのモデルのパフォーマンスを示すスナップショットに過ぎませんが、これが将来変化していくことは十分に想像できます。モデルが進化し、ブラウザを取り巻く状況が変化していくにつれて、私たちのガイダンスがなくても、こうした評価の多くが合格するようになっていくことを私たちは十分に予期しています。そこで、先ほど申し上げたとおり、私たちはこれらの評価を毎日実行しているわけですが、私たちの方針としては、この状況を注意深く見守り、結果をモニタリングし続け、そして、主要なモデルすべてにおいてガイドなしのバージョンがガイドありのバージョンと一貫して同等のパフォーマンスを発揮するようになったユースケースについては、順次取り除いていくというものです。これによって、このパッケージをコンパクトかつトークン効率の良い状態に保ちながら、新しく登場したばかりでまだモデルにあまり知られておらず、学習データにも含まれていないような機能だけに焦点を絞ることができます。とはいえ、新しい機能は毎月のようにブラウザに実装され続けており、学習データのカットオフはそれに大きく遅れをとり続けています。ですから、私たちはこの種のガイダンスが、この先も長きにわたって必要であり続けると考えています。
4.4 プレビュー版の範囲と今後の展望
そして未来の話に触れたところで、今度はこのプロジェクトが今後どのように発展していくと私たちが見ているか、少しお話ししたいと思います。今回の早期プレビューでは、十数個ほどの高レベルの分野別ガイドと、100個を超える詳細なユースケースガイドを提供して開始しますが、私たちはもちろんそこで止まるつもりはありません。私たちの計画としては、既存のウェブプラットフォームに関するカバレッジをさらに充実させるべく、ガイドを追加し続けることに加えて、新しい機能が登場するのに合わせて、それらもカバーしていく予定です。実際、このツールにおける私たちの目標は、Chromeに新しいウェブプラットフォーム機能が実装されるたびに、それがChrome安定版に反映される時点までに、このツールでカバーされている状態を確実にすることです。chromestatus.comをご覧いただければお分かりのとおり、Chromeは毎回のマイルストーンごとに非常に多くの新機能をリリースしていますので、これは間違いなく野心的な目標だと言えます。しかし私たちは、これがこの新しいエージェント主導の世界において、ウェブの継続的な健全性と成功を支えるうえで、きわめて重要な目標だと考えています。また私たちは現在、他のブラウザベンダーとも協議を進めており、彼らが実装している機能についてもカバレッジを得られるよう取り組んでいるところです。
さて、ここで本日お話しした内容を振り返ってみましょう。まず1つ目に、AIモデルには知識のギャップと盲点があります。より新しく優れた代替手段が存在するにもかかわらず、レガシーなソリューションを推奨してしまうのです。2つ目に、Modern Web Guidanceは、Chromeの専門家によって検証された推奨事項によって、こうした知識のギャップを埋めます。これにより、コーディングエージェントがモダンなウェブプラットフォームについて完全かつ包括的な理解を持ち、それらの機能をブラウザ間で互換性を保ちながら実装するための明確な指示を得られるようになります。そして3つ目に、Chromeはプラットフォームの進化に合わせてModern Web Guidanceを最新の状態に保ち続けることにコミットしています。これにより、エージェントによるコーディングが、モダンなウェブ開発から常に遅れをとるのではなく、常にその最前線に立ち続けられるようにしていきます。
5. デモンストレーション実演:Antigravityを用いた実機テスト
5.1 デモ環境の設定
そして、それではデモをご覧になりたい方はいらっしゃいますか。皆さんの歓声、ありがとうございます。すみません、実は先ほど私のスマートフォンが鳴っていたのですが、聞こえましたでしょうか。本当は今この時間に息子を保育園に迎えに行く予定だったのですが、おそらく妻が対応してくれていることを願っています。それでは、始めさせていただきます。
まず、こちらのスマートフォンからお見せしたいと思います。私が現在開発しているアプリをご紹介します。画面の焦点が合っているかどうか、皆さんから見えていますでしょうか。このモニターは少し癖があるようです。これはメールアプリケーションです。アプリの内容自体が何であるかは、実はそれほど重要ではありません。私が取り組んでいるプロジェクトは、モバイルサイトを作るというもので、私の目標は、このモバイルサイトをスマートフォンで使ったときに、私が普段スマートフォンで使っているネイティブアプリと同じくらい滑らかで、洗練されていて、シームレスに感じられるようにすることです。私が思うに、業界全体として、モバイルファーストという考え方が15年ほど前に登場して以来、モバイルの画面サイズに合わせて見た目の良いインターフェースを作ることは非常に得意になりました。しかし、モバイルの画面サイズで実際に触って気持ちの良いインターフェースを作ることについては、まだあまり上手くなっていないと思うのです。ですから、これが私のこのプロジェクトにおける目標です。
そこで私は、Gemini、具体的にはAntigravityを使ってプロンプトを入力していました。Gmailに似たものを作ってほしいと依頼したところ、こちらのようなものができあがりました。そして次に、ハンバーガーメニュー付きのサイドバーナビゲーションドロワーを作ってほしい、ハンバーガーメニューをクリックしたらスライドして出てくるようにしてほしい、と依頼しました。すると実際にそのとおりに動作し、見た目も悪くありません。欲しかったリンクもすべて揃っています。しかし、ここに1つ欠けているものがあります。皆さんもおそらく想像がつくのではないでしょうか。ここに親指を置いてスライドして閉じようとしても、それがうまく動作しないのです。
おそらく皆さんも、これまでに一度はこうした経験をされたことがあるのではないかと思います。モバイルサイトにアクセスして、ナビゲーションドロワーをスワイプで閉じようとしても、閉じられない。文字どおり、あらゆるネイティブアプリケーションはこの機能に対応していますが、ほとんどのウェブサイトはそうなっていません。私はこれを変えたいと思っています。そしてAIはこの点であまり助けにはなってくれませんでした。私がこれをやってほしいと依頼すれば、プロンプトを重ねていくことはできますが、私としては、これがデフォルトの状態でそうなっていてほしかったのです。それでは、Modern Web Guidanceを使ってこれをどのように解決できるか、お話ししていきましょう。
それでは、私のノートパソコンに切り替えます。ここにAntigravityを用意しています。どのようにこれに取り組んでいくかをお話ししたいのですが、今回は少し変わったことをしてみたいと思います。実は、Antigravityを2つのバージョンで同時に起動しています。1つはこちら、ライトモードで動いているAntigravityで、これが私のエディタです。ライトモードになっているのが見分けるポイントです。そしてこちらが、ダークモードで動いているAntigravityです。右上をご覧いただくと、「unguided(ガイドなし)」と表示されています。そして切り替えると、こちらには「guided(ガイドあり)」と表示されます。つまり、私は1つの共通のブランチから分岐させた2つのブランチを用意しており、これらはまったく同じコードベースです。そして私はAntigravityを2つ同時に動かしていて、片方を「ガイドあり」、もう片方を「ガイドなし」と呼ぶことにします。
こちらのガイドありのバージョンで、まずターミナルを立ち上げてみましょう。すでに起動していますが、ここでModern Web Guidanceをインストールします。ご覧のとおり、npx modern-web-guidance installというコマンドを実行しています。見やすいように画面を広げますね。これがインストールされていきます。デフォルトのおすすめ設定をそのままクリックして進めます。プロジェクト内にインストールし、インストールを進めます。そしてこちらをご覧いただくと、.agentsというフォルダが追加されています。もし皆さんがこれまでにスキルを使ったことがあれば、この流れには見覚えがあるかと思います。これを開いてみると、ガイドありのバージョンにModern Web Guidanceがインストールされていることが分かります。そして、ガイドなしのバージョンに切り替えてみると、スキルは何も入っていません。というわけで、これが私たちのスタート地点です。
ブラウザのウィンドウも2つ開いており、片方はダークモードにしています。こちらがガイドなしバージョンのローカル開発サーバーで動作しているもの、そしてこちらがガイドありバージョンのローカル開発サーバーで動作しているものです。先ほど申し上げたとおり、両方ともまったく同じブランチからスタートしています。サイドバーを開いて、ここでスワイプして閉じようとしてみます。ご覧のとおり、指の動きに合わせて後ろに引きずられてはいますが、サイドバー自体は閉じません。それでは、これを修正していきましょう。皆さんに私がタイピングする様子を見ていただく必要がないように、いくつかプロンプトを事前に準備してあります。
それではAntigravityに戻りましょう。まずガイドなしのバージョンから始めます。ちなみに、今日、私たちのAntigravityはすべてアップデートされました。皆さんもおそらく発表を耳にされたと思います。というわけで、これをGemini 3.5 Flashで試してみようと思います。これはまだ一度も試したことがありません。うまくいくかどうか分かりませんが、試してみたいと思います。もしうまくいかなければ、3.1に戻します。ですが、まずは試してみましょう。
5.2 デモ1:ナビゲーションドロワーのスワイプ操作
このプロンプトを貼り付けます。まずこちらに入力し、次にガイドありのバージョンに切り替えて、そこでプロンプトを読み上げます。内容は次のとおりです。「このアプリのナビゲーションドロワーは見た目はいいのですが、スワイプで閉じられないのが気に入りません。直してもらえますか」。それでは、何が起きているか見てみましょう。このサイドバーを閉じておきます。何が起きているか見えるように、画面を拡大しますね。上部をご覧いただくと、npx Modern Web Guidanceが実行されており、先ほど申し上げた検索コマンドを実行しています。ガイドのデータベースを検索しているところです。ガイドが見つかったようです。少し画面を動かしてもよろしいでしょうか。「navigation drawer」という名前のガイドが見つかり、それを実装し始めています。
それでは、ガイドなしのバージョンに戻って、何をしているか見てみましょう。こちらも何か処理をしています。すでに完了しているようですね。変更を承認しておきます。ガイドありのバージョンに戻りましょう。こちらは終わっているでしょうか。npx buildを実行しているところなので、もうすぐ終わりそうです。見てください、こちらも終わりました。Flashを使うことにしたのは、処理がかなり速いからです。皆さんにこの処理が終わるのをただ座って見ていただくのは避けたかったのです。
それでは、こちらがガイドなしのバージョンです。これはAIのデモですので、かなりリスキーです。何が起こるか分かりませんので、その点はご了承ください。ハンバーガーメニューをクリックして、何が起こるか見てみましょう。それでは、スワイプで閉じてみます。ご覧のとおり、スワイプで閉じることはできました。ただ、皆さんには私が実際に何をしているか、感触までは伝わらないかもしれません。もう一度やってみましょう、少し違和感があったので。私はここでドラッグしています。後ろで見えているかどうか分かりませんが、これをドラッグしています。閉じました。指を離していないんです。指を下ろしたまま、ドラッグして、指を離さずに閉じてしまいました。このデモは何度か試したことがあるのですが、Flashも同じような挙動をしているようです。
おそらくここで起きているのは、スワイプジェスチャーを検知して、その後にクローズ関数を呼び出しているということだと思います。しかし私が求めていたのは、指の動きに合わせて文字どおりシートをピンで留めたように動かすことです。これが私の期待していた動作です。ですから、繰り返しになりますが、一応動作はするのですが、これは違う、これは私が求めていたものとはちょっと違います。何もないよりは確実に良いのですが、私が欲しかったものとは言えません。
それでは、ガイドありのバージョンに戻って、どうなっているか見てみましょう。うまくいくことを祈ります。よし、開きました。クリックしてみます。ドラッグしてみます。クリックしてドラッグ。(拍手)お気づきになったかもしれませんが、私がドラッグしている間、背景がわずかにフェードしていきます。これは、私がどのガイドが使われたか知っているので分かるのですが、これはscroll-driven animationsを使って背景のフェードを実現しています。そしてこれはスクロールのジェスチャーに連動しています。このドラッグの部分は、scroll snap pointsを使って処理されています。つまり、これは実際にはスクロールのインターフェースとして実装されているということです。これはブラウザ標準の物理演算と、スクロールに関するすべてのハードウェアアクセラレーションを活用できるということを意味します。ですから、スワイプして閉じることもできますし、こんなふうに動かすこともでき、とても良い感触です。
5.3 デモ2:メールメッセージのドリルダウン表示
さて、まだいくつか機能を追加する必要がありますので、先に進めましょう。次のプロンプトのコピーを追加します。まずガイドなしのバージョンに行って貼り付け、それからガイドありのバージョンに行って貼り付け、そして内容を読み上げます。プロンプトの内容は次のとおりです。「受信トレイでメールのリンクをクリックしたときに、Backボタンで受信トレイビューに戻れるようにしたうえで、メールメッセージの全文表示にドリルダウンするようにしてください。メッセージには、アーカイブ、返信、スターなどの標準的なメールのアクションボタンも表示してほしいのですが、それらの機能はまだ実装しなくて構いません。まずはBackボタンを機能させることだけをお願いします」。
さて、Modern Web Guidanceが処理を進めています。ガイドを探しているところです。ガイドなしのバージョンに戻って、何をしているか見てみましょう。こちらも同じく処理中です。そしてこちらでは、Modern Web Guidanceが「stack-drill-down」というガイドを取得しているのが見えます。これは取得しているユースケースのIDに過ぎません。もし時間があれば、ガイドの中身自体もお見せできるかもしれません。まだ終わっていないようであれば。あ、こちらは終わったようですね。まだ終わっていないようなので、ガイドなしのバージョンに戻って確認してみましょう。
受信トレイのメールメッセージをクリックして、全文を表示させてみます。全文が表示されました。しかし、遷移アニメーションは入りませんでした。先ほども申し上げたとおり、私はこれがネイティブアプリのように感じられるものにしたいのです。Backボタンは機能するでしょうか。はい、Backボタンは機能しますが、この遷移はかなり素っ気ないものです。
それでは、もう片方が終わっているか見てみましょう。ご覧のとおり、「stack drilldown transition moduleをメインに正常に統合しました」といったメッセージが表示されています。うまくいったようです。ここで何を使っているかの説明も出ています。それでは、実際にどのように見えるか確認してみましょう。もう一度、うまくいくことを祈ります。
よし、うまくいきました。滑らかに遷移して表示されました。Backボタンをクリックすると、遷移して戻ります。今度は、スワイプで戻る操作ができるか試してみましょう。できました、スワイプで戻ることができます。これは良いですね。(拍手)スワイプしている間、わずかにパララックス効果が起きているのにも気づきました。これもscroll-driven animationsを使って実現されています。それに、上部のナビゲーションバーを見ると、クリックすると履歴が更新されているのも分かります。そして、Backボタンをクリックすると、スワイプで戻ります。私はこの仕組みがどう実装されているのか、まったく知る必要がありませんでした。ただプロンプトに入力しただけです。
5.4 デモ3:受信トレイでのスワイプによるアーカイブ/スヌーズ操作、実機確認
もう1つだけ試してみましょう。ちょっとした「仕上げ」のようなものを見ていただきたいと思います。それでは、こちらに行って、いったんこの変更を承認しておきます。ガイドなしのバージョンに戻り、それから再びガイドありのバージョンに行きます。プロンプトの内容は次のとおりです。「受信トレイビューにおいて、メッセージを個別に開かなくても、左右にスワイプするだけで素早くアーカイブまたはスヌーズできるようにしてください」。
皆さんも私と同じかもしれませんが、メールアプリを使っていると、興味のないメールがたくさん届きますよね。私は普段、メールアプリを使う時間の大半を、未読メールをこんなふうにスワイプ、スワイプ、スワイプ、あるいは逆方向にスワイプすることに費やしています。1つ1つ個別にクリックして開きたくはないのです。こちらは終わったようですね。もう1つの方は終わっているでしょうか。まだ処理中のようです。それでは、ガイドなしのバージョンがどうなったか確認してみましょう。
これも先ほどと同じような挙動をしていますね。指に追従してドラッグされるのではなく、スワイプジェスチャーを検知する形になっています。正直に言うと、両方向にある程度対応しているようです。実は、このデモをこれまで何度も行ってきたのですが、これはこれまでのガイドなしバージョンの中でおそらく最も良い出来です。それでも、これはまだ完全に私が求めているものとは言えません。
それでは、もう片方が終わっているか確認してみましょう。ガイドありのバージョンに切り替えます。よし、終わっているようです。それでは、どうなったか確認してみましょう。かなり良くなりました。これはGmailの動きにとても近い感じがします。片側からスワイプしてすべて閉じることもできますし、もう片側からスヌーズすることもできます。
これは素晴らしいのですが、これは皆さんが私の操作を見ているだけでは、実際にどんな感触なのかは正直なところ分かりにくいと思います。ですので、スマートフォンに切り替えて、実際に私がスマートフォンでこれを操作する様子を見ていただき、その効果を実感していただきたいと思います。それでは見てみましょう。こちらをクリックすると、あ、少しお待ちください。ここに反射が映り込んでいますね。こんなふうにスワイプして閉じることができます。そして、これがポイントなのですが、途中まで動かして指を離すと、元に戻ります。そして半分より多く動かして指を離すと、そのまま閉じます。すみません、ちょうど半分を少し超えたところではなかったですね。顔の反射で少し見えづらいのですが、そういう感じです。
これはスクロールとして動作しており、その仕組みはネイティブアプリの物理演算とまったく同じで、半分より多く動かせばスナップポイントにぴったり収まるようになっていて、これが素晴らしいところです。メッセージをクリックすると、どのメッセージでもクリックできます。そして、戻るジェスチャーでも同じように機能するはずです。あまり得意ではないのですが、Pixelでの戻るジェスチャーです、できました。それから、メールをスワイプしていくと、スヌーズもできて、全体としてとても気持ちよく感じられます。とても滑らかで心地よい感触です。
そして、先ほどお話ししたことが嘘ではないことをお示しするために、こちらにiPhoneも用意しています。リフレッシュして、同じことをやってみます。スワイプします。メッセージをクリックして開きます。パララックス効果もあります。反射が映り込まないようにしているので、すみません。全体的にとても滑らかに感じられます。アドレスバーが下部に表示されていることを除けば、これがネイティブアプリではないと言われても分からないくらいです。(歓声、拍手)それでは、スライドに戻りましょう。
6. クロージング:Chromeのビジョンとフィードバック依頼
6.1 Chromeのビジョン
おっと、失礼しました。同時にボタンを押してしまいましたね。それでは、まとめに入らせていただきます。私たちChromeは、オープンウェブの健全性を非常に大切にしており、開発者の皆さんがより良い体験を構築できるように、そしてウェブを基盤としているビジネスが最終的により成功できるように、プラットフォームの改善に多大な投資を行っています。しかし実のところ、ウェブプラットフォームそのものを改善するだけでは十分ではありません。私たちは、実際にウェブそのものを改善しなければならないのです。なぜなら、ユーザーはウェブプラットフォームを訪れるわけではなく、彼らが実際に訪れるのは、今この瞬間に存在している、実際のウェブサイトだからです。ですから、もし私たちがウェブをより良いものにしたいのであれば、結局のところ、Chromeがこのプラットフォームに追加しているこれらの素晴らしい機能の数々を、開発者の皆さんができる限り簡単に使えるようにしなければなりません。
そして、これこそが私たちがModern Web Guidanceを作った理由です。しかしそれと同時に、これは私たちが皆さんからのご意見をぜひお聞きしたいと考えている理由でもあります。私たちは、このツールが皆さんにとって本当に役立つものであること、そして皆さんがより良い体験を構築する助けとなることを確認したいのです。
6.2 フィードバック依頼
ですから、ぜひ皆さん全員に、この早期プレビューをお試しいただき、フィードバックをお寄せいただきたいと思います。もし何か問題に遭遇された場合や、対応してほしいユースケースが不足していると感じられた場合は、ぜひ私たちにお知らせください。画面に表示されているリンクから、貢献方法やフィードバックの送り方に関する情報が掲載されたサイトにアクセスしていただけます。それでは、本日は誠にありがとうございました。(拍手)