※本記事は、Paul Kinlan氏(Chrome Developer Relationsチームリード)による動画「What's new in Chrome」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=YuMdsHIXatY でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、関連リソースとして、Google I/O 2026における15のアップデートまとめ(https://goo.gle/4dXodTO)、WebMCP(https://goo.gle/4uqYauc)、Modern Web Guidance(https://goo.gle/4dWeOf8)、Chrome DevTools for agents(https://goo.gle/4fABEdz)、HTML-in-Canvas(https://goo.gle/3RnDLYj)、Prompt API(https://goo.gle/49b24ii)、Baseline(https://goo.gle/3ReWwgz)もご参照ください。Google I/O 2026におけるChromeセッション一覧は https://goo.gle/Chrome-at-IO2026 、Chrome for Developersのチャンネル登録は https://goo.gle/ChromeDevs からご覧いただけます。
1. オープニング:イントロダクションとデモ
1.1 スピーカー紹介と少年時代の回想
私はPaul Kinlanと申します。Chrome Developer Relationsチームを率いています。この場に立てることを大変嬉しく思っています。実は一年前にもこの場所で、Chromeの新機能について話をさせていただきました。本題に入る前に、私たちが特に注目している二つのAPI、WebMCPとHTML-in-Canvasを紹介する新しいデモをお見せしたいと思います。
デモの舞台としてお見せしたのは、30年前の私の子供部屋です。私がプログラミングを学び始めた頃の風景です。そこには開発に関する書籍が並んでいましたが、実はこれは嘘です。当時実際にあったのはHTMLに関する本だけで、私自身はPerlのプログラマーとして開発を始めていました。当時の私が持っていたのはブラウザというもので、それを使ってウェブを閲覧し、新しいものを見つけたり、ゲームで遊んだりしていました。もっとも、ゲームの腕前は今でもあまり上達していません。ウェブを閲覧しながらテキストを選択するなど、さまざまな操作を行い、インターネットを通じて多くの新しい友人にも出会いました。
1.2 HTML-in-CanvasとWebMCPのデモ
このデモで特に見ていただきたかったのがHTML-in-Canvasです。子供部屋の再現には、Canvas内にブラウザとそのコンテンツをまるごと埋め込んだ、完全な3D体験を用意しました。この技術によって、たとえば表示されているコンテンツをウェールズ語に翻訳するといったことが可能になります。私は今ウェールズに住んでおり、ウェールズ語を少しずつ学んでいるところです。さらに、これまでCanvasベースの体験の中では実現できなかったWebGPUへのアクセスや、DOMへのアクセスといったことまで行えるようになりました。これは本当に画期的なことだと感じています。
このデモの最中にお見せしたもう一つの要素がWebMCPです。30年経った今、私はもう実家暮らしではありませんが、世の中にはウェブを巡回してタスクをこなすエージェントが存在するようになりました。Chromeにおいて私たちが実現したいことの一つは、ウェブがこうしたエージェント的な体験に参加できるようにすることです。デモの中では、いくつかのツールをエージェントに対して公開している様子をお見せしました。たとえば「電気を消して」と一言指示するだけで、対象がどの照明かを確認したうえで、実際に電気を消すという操作を実行させることができました。また、子供の頃に母がパソコンの利用を嫌がったため、母が部屋を出た隙にパソコンを再起動して使い続けていたという昔の経験になぞらえ、パソコンの電源を切ってから再び起動するというデモも行いました。これは電源を切る、そして再び起動するという複数のステップから成る一連のフローを、エージェントが実行できることを示すものでした。あくまで簡単なデモではありますが、HTML-in-CanvasとWebMCPという二つのAPIで何が可能になるかを感じ取っていただけたのではないかと思います。私自身、この二つの技術には非常に大きな期待を寄せています。
ここで話を現在に戻します。私がプログラミングを学び始めた頃の開発環境は、QBasicを使ったものでした。会場にもQBasicを覚えている方がいらっしゃるようですね。当時はまだモダンなIDEもなく、言語サーバーによる構文ハイライトやインラインデバッグといった機能も存在せず、非常に素朴な環境でプログラミングをしていました。ちなみに小話ですが、私はアメリカ英語という存在を知らず、colorという単語にUが付かない綴りだとは思わず戸惑い、プログラミングを始める前に挫折しかけたことがあります。構文エラーが何であるかを理解するのに、丸一週間デバッグに費やしたほどです。それでも何とか乗り越えることができました。
あれから30年が経ちましたが、正直なところ、私が今使っている開発環境も当時とそれほど大きくは変わらず、依然としてテキストベースの体験です。しかし、開発環境そのものや開発プロセスにおいては、この間に、特にここ半年の間に、非常に大きな飛躍がありました。私たちがChromeにおいて、そして私自身がこの仕事をしている理由でもある根本的な目標は、次世代のウェブ開発に向けてすべての人の準備を整えることです。私なりの整理では、そこには三つの要素があります。一つ目は、皆さんのサイトがこのエージェント的な未来に参加できるようにし、ウェブをファーストクラスの体験とすることです。二つ目は、皆さんが使っているツールが、たとえモデルやツール自体にその知識が組み込まれていなくても、モダンなウェブの機能やモダンなウェブのベースラインに沿った構築方法を理解できるようにすることです。そして三つ目は、これから先の数年間に向けた準備を整えることです。これからお話しする内容は、多くの場合まだ実験段階にあるものであり、私たちとしても皆さんからのフィードバックを強く求めています。ただ、プラットフォームがどこに向かっているのかを知っていただくことは、皆さんが今後の計画を立てるうえでも意味のあることだと考えています。
2. Chromeが目指す方向性とエージェント時代のウェブ体験
2.1 エージェント時代への変化という認識
ここまでで方向性についてお話ししましたが、実はこの後の話の中で私は「エージェント」という単語を何度も使うことになります。会場には何回言うか数えている方もいらっしゃるようで、実際、この時点ですでに2回、いえ3回使っていました。冗談はさておき、私たちは今、人々が音声や自然言語を使うだけで物事を成し遂げられる世界に生きています。これは私にとって、ウェブが発明されて以来、コンピューティングにおける最も大きな転換の一つだと感じています。
ウェブの世界では、プラットフォームの変化は通常かなりゆっくりとしたペースで進みます。たとえばiPhoneが登場してから、デスクトップファーストの体験からモバイルファーストの体験へと移行するまでには、ほぼ10年もの歳月がかかりました。当時すでにブラウザをモバイル向けの体験へと変える技術自体は存在していたのですが、業界全体が実際に動くまでには非常にゆっくりとした時間がかかり、開発者がそれぞれの体験を作り直すためには膨大な労力が必要でした。しかし、今この瞬間に目を向けると、この半年ほどの間に、私たち開発者の役割において非常に大規模で劇的な変化が起きていると感じています。そして私は、この変化はモバイルへの移行のときよりもはるかに速いペースで進むだろうと考えています。ウェブは、ユーザーが閲覧してから行動を起こすというメディアから、エージェントに作業を委任してタスクを完了させるというメディアへと変貌しつつあるのです。
2.2 ユーザー意図の複雑化とGemini in Chrome、Skills in Chromeの現状
ちょうどiPhoneの登場時にウェブがモバイル上で一応は動作していたもののモバイル向けに最適化されていなかったのと同様に、今日のウェブもエージェントによるフローに対して一応は機能しているものの、まだ最適化されているとは言えません。ただ幸いなことに、多くのエージェントはスクリーンショットを見たりDOMを理解したりすることで、サイトを解析することができます。そして私たちが好ましいと感じているのは、これが結局のところ、セマンティックなHTMLへの回帰、アクセシビリティの確保、そして本来であればすべての開発者がすでに実践しているべきモダンなウェブ開発の基本原則への回帰を求めているという点です。
一方で、ユーザーの意図そのものも変化しています。単発の操作ではなく、一つのサイトの中で、あるいは複数のサイトをまたいで、複数のフェーズにわたる行動が求められるようになっています。たとえば、これから参加する技術カンファレンスのためのホテルを探し、それを同僚が行くレストランの情報と組み合わせたい、といった具合です。人々はコンブチャが飲めるお店を探したがっているとも聞きましたが、正直に申し上げると、私自身は今週になって初めてコンブチャが何であるかを知ったばかりで、まだよく分かっていません。ちなみに私が住む北ウェールズには、コンブチャを扱う店はありません。冗談はさておき、要するにエージェントは以前よりもはるかに複雑で強力な計画を立てられるようになってきているということです。ただしこれを実現するには、ブラウザ自体をどう進化させるかという観点と、皆さんのサイトをこうした複数ステップにわたるエージェント的なアプローチに対応できるよう進化させる手助けをするという観点の、両方を統合したアプローチが必要になります。
もちろん、ブラウザ自体もすでに進化を続けています。今年の初めにはChromeにGeminiを導入し、ユーザーがタブを切り替えることなくチャットをしながらマルチタスクをこなせるようにしました。私たちはこのブラウザアシスタントを、サイトを巡回したりコンテンツを要約したりできるものとして作り上げました。クイズを作成したり、本を作ったり、適切な寝袋を見つける手助けをしたりすることもできます。こうしたことが可能になっているのは、ウェブページ自体がそのサイトの機能を説明しているからこそ、私たちのツールがそれを理解できるという点にあります。ここで重要なのは、もし私たちが使っているツールに対して、これがきちんと設計されたサイトであり、こういう構造になっていると伝えられれば、エージェントやツールがユーザーの目標を達成する手助けをできるようになるということです。
そこからさらに一歩進んだ話として、かつて表計算ソフトが誰もがプログラマーになれる道を開いたのと同じように、Chromeにおけるスキル機能にも同じ可能性があると私は考えています。Skills in Chromeを使うと、すでに用意されたスキルのライブラリを閲覧することができ、たとえば商品の仕様を抽出させることができます。プロテインのマクロ栄養素というものがあるらしいのですが、実は私自身、それが何なのかよく分かっていません。それでも、そうした情報をページから抽出させることができます。また、長い文書を要約させて必要な情報だけを取り出すこともできます。そして重要なのは、そうしたチャットのやり取りを、繰り返し使えて、リミックスも可能なスキルへと変換できるという点です。一度作ったスキルは、さまざまなウェブサイトに対して横断的に実行することができます。私はこれを、人々がこれまでとは異なる抽象化のレベルで、より開発者に近い存在になれる新しい段階の体験だと捉えています。
3. WebMCPの詳細と実験
3.1 WebMCPの背景と仕組み
先ほどお話ししたSkills in Chromeのように、LLMはページの画像やDOM、あるいはクリック操作をスクレイピングすることで、そのページの意図を推測することができます。しかし、その裏側の仕組みはかなり不透明で分かりにくいものです。私たち開発者としては、やはりもっと多くのコントロールを持ちたいと考えますし、自分たちのツールがサイト上でどう振る舞うかを自分たちの手で導きたいと思っています。ここで登場するのがWebMCPです。
WebMCPが登場する以前には、さまざまな困難がありました。私たちが構築するUIは、ブランドガイドラインやUIの規約、規制といった、多くの人間側の制約を反映したものになっていることがほとんどです。しかし多くの場合、私たちのツールは、実際にサイトを閲覧する人間が経験するのと同じ制約に縛られる必要はありません。WebMCPはまさにこの点を解決してくれるものだと考えています。現時点でWebMCPはまだ提案段階の仕様ですが、その目標は、HTMLフォームやJavaScriptの関数をエージェントが使えるツールへと変換し、皆さんがこのエージェント的なエコシステムに参加しやすくすることにあります。
WebMCPが目指しているのは、Model Context Protocolで得られた多くの知見を取り込みつつ、その中でもツールの部分にのみ焦点を当てるという点です。MCPサーバーやCLIを別途公開し、それを自分のウェブサイトとどう連携させるかを試行錯誤する代わりに、今開いている自分のブラウザタブそのものを公開するだけで、そこからエージェントが操作できるツールの一覧を共有できるようになります。先ほどのデモでお見せした照明のスイッチや、パソコン本体、ページ遷移といった操作は、すべてこの形でエージェントに公開したツールの一例でした。
より実務的な例で考えると、たとえば皆さんが靴屋を経営していて、ユーザーがサイズ10の茶色の靴を探しているとします。この場合、WebMCPを使えば、検索、カートへの追加、チェックアウトといった一連のツールを公開することができます。どこまでユーザーに実際に操作させたいかによって、公開する範囲は変わってきます。これらはフォームを通じて公開することもできますし、JavaScriptを通じて公開することもできます。そのうえで、エージェントはどのツールを使い、どの順序で実行すべきかを自分で判断し、最終的にユーザーのタスクを完了させるところまで到達できるようになります。
この仕組みの優れている点は、既存のモダンなウェブ開発のセマンティクスをそのまま活用できることです。ここにいる皆さんのほとんどはすでにHTMLフォームの作り方をご存じだと思いますが、そのフォームにいくつかの追加属性を加えるだけで済みます。たとえば、このフォームが何をするものかをエージェントに説明するツールの説明や、エージェントがフォームをどう埋めればよいかを示すツールパラメータの説明を加えることができます。星評価のような入力であれば、これは星評価である、これはコメント欄であるといった説明を、通常のHTML属性を通じてエージェントに伝えることができるのです。これは本当に素晴らしいことだと思っています。命令型のAPIを使う場合には、navigator.modelContext.registerToolという形になります。こちらも考え方は似ていて、エージェントがツールを呼び出す際の名前、そのツールの意図を説明する説明文、そして関数に渡されるデータの形を定義する入力スキーマを指定します。エージェントがユーザーの意図とこのツールを一致させたと判断すると、渡されたデータをもとに実際に関数が実行される、という流れになります。
これは、HTMLとJavaScriptという両方の手段でこのエージェント的なエコシステムに関わることができる、非常に強力なプリミティブだと感じています。技術的なレベルで自分たちの体験にWebMCPを組み込むこと自体は、比較的シンプルだと思います。サイト全体のアーキテクチャという広い視点で見ると、もう少し難易度は上がるかもしれません。ただ、この仕組みの本当に強力なところは、これがブラウザの中で、つまりユーザーが実際にいるコンテキストの中で動作しているという点です。そのため、サインイン状態やその他のCookie、ローカルストレージといった情報にも、これらのツールからそのままアクセスできます。これは、ブラウザの中で実際に動いているわけではない他のツールベース、MCPベースのシステムでは得られないものです。もちろん、これらはすべてブラウザのセキュリティ境界とセキュリティコンテキストの中で動作しますが、エコシステムに参加していくうえで、これは非常に強力な方法だと考えています。
3.2 Expediaとの実験デモと標準化に向けた展望
ここで、私たちが協業している企業の一つによる簡単なデモをお見せしたいと思います。これはあくまで実験であり、本番環境で稼働しているシステムではありません。Expediaは、彼らの仮想的なフローにWebMCPを組み込むという実験に取り組んでくれました。デモの内容としては、まず「7月4日にGrandmaの近くのホテルを見つけて」という検索から始まります。Geminiがタスクとプランを作成し、ユーザーがそれを承認すると、Search Lodging、Update Lodging Filters、Navigate to Propertyといった複数のツールが用意されている状態になります。
ブラウザはどのツールを呼び出すべきかを判断していきます。このケースでは、実際にいくつかのツールを呼び出して検索条件を更新していますが、それに加えてページ上での操作、いわゆるアクチュエーションも行っています。実は日付フィルターを更新するツール自体は用意されていなかったのですが、それでもアクチュエーションによってその操作が実現されていました。そのうえで、システムはこのホテルにユーザーを送りたいという判断を行い、実際にそこへ遷移させることができました。最終的にユーザーは、その内容を確認するか、場合によってはエージェントがそのままチェックアウトまで進めるという選択肢も持てるようになっています。繰り返しになりますが、これはあくまで実験であり、本番環境のものではありません。ただ、こうした仕組みが将来どのように機能しうるかのイメージを掴んでいただけたのではないかと思います。パフォーマンス面や、セキュリティのプリミティブについてさらに検討を重ねていくことで、非常に興味深い領域になっていくと感じています。
業界にはこのほかにも、WebMCPを使った実験を行い、多くのフィードバックを私たちに寄せてくれている企業や関係者が数多くいます。WebMCPはオープンな仕様として設計されており、私たちは業界標準化団体とも連携して取り組んでいます。ただし、はっきり申し上げておきたいのですが、これは現時点ではまだ非常に実験的な段階にあるものです。GeminiとChromeも、今後この仕組みをどう統合していくかを検討しながら、さらに実験を重ねていく予定です。私たちはこうした初期段階のテストを、一部のパートナー企業と一緒にすでに進めています。もし皆さんがこの動きを追いかけたいということであれば、指定されたURLからOrigin Trialに登録していただくことができます。日付を正しく記憶していれば、これはChrome 149に搭載される見込みで、時期としてはおおよそ6月2日ごろになる予定です。Origin Trialに参加していただいた段階から、私たちはこのAPIがどうあるべきかを形作っていくうえで、皆さんからのフィードバックを強く求めています。実際に皆さんのユースケースに合っているかどうかを確認しながら、これが標準となった場合に、他の開発者が同じようにアーキテクチャを設計できるよう支援していく方法を、一緒に見つけていきたいと考えています。
4. 開発者ワークフローの変化とModern Web Guidance
4.1 開発者自身の体験変化と課題認識
ここまでは、エージェントがユーザーのブラウジング体験をどう変えていくかという話をしてきましたが、ここからは、私たちが使うツールが、ソフトウェアの作り方そのものをどう変えていくかについて、私自身の話も交えながらお伝えしたいと思います。私は個人的にはチームのマネージャーという立場にありますので、以前であれば、開発は自分の自由時間にしかできないような状況でした。しかし今は、こうしたツールのおかげで、毎日のように開発を行うようになっています。奇妙な話に聞こえるかもしれませんが、おそらく多くの方と同じように、私たちは今、自分が何をしたいのかを一緒に考えてくれるツールと会話をしながら開発を進めています。私自身はマイクを使い、文字通り音声で自分の大規模言語モデルに話しかけています。自分がやりたいことを伝え、それをどう実現するか、どんなエッジケースがあるかについて対話を重ね、そのうえでようやく実際の作業に取りかからせる、という流れです。
こうした開発の仕方をしているのは、決して私だけではありません。実際に私は、自分のブログのために、GitHub全体を対象にした分析を行い、どれだけ多くの開発者がさまざまなツールを使ってコミットを作成しているかを調べてみました。その結果は驚くべきもので、非常に急速に増加しています。何百万人もの開発者が、エージェント的なツールを使って、毎日何百万件ものプルリクエストを提出しているのです。これは私たちが開発者の皆さんを支援していきたいと考えている大きなトレンドの一つです。
ただ、ここには一つの緊張関係があります。ツールの進化は非常に速いペースで進んでおり、私たちの開発ワークフローもそれに合わせて変化していますが、これがウェブプラットフォームの仕組みとは必ずしも噛み合っていないのです。たとえばChromeというブラウザを例に取ると、4週間ごとに更新が行われています。数か月後には、これが2週間ごとの更新になる見込みです。しかし、モデルの学習に使われているウェブの情報は、場合によっては1年も前のバージョンのものだったりします。では、この緊張関係にどう対処すればよいのでしょうか。現状では、たとえば私のHTML-in-Canvasのデモのような技術を実際に作ろうとすると、サンプルコードや事例、仕様書、解説記事、時にはユニットテストまでをコンテキストとして読み込ませてから作業をさせる必要があります。そうすれば、ツールはかなり良い成果を出してくれます。しかし、そのためには私自身がそうした情報すべてを把握していなければなりません。私の場合は、こうした情報を常に把握し続けることが仕事の一部になっていますが、一般的な開発者の方々は必ずしもそこまで追いかけているわけではありません。多くの開発者にとっては、自分のビジネスに必要な機能を実装するという目の前の仕事があるだけです。そこで私が本当に考えたい問いは、Chromeがこの領域で力になれるのかということです。何十年にもわたるウェブ開発の経験の蓄積を活用して、皆さんがモダンなプラットフォームについて考え、判断する手助けができるのではないか。私としては、かつてのウェブではなく、今日のウェブのために皆さんが開発できるようにしたいと強く思っています。
4.2 Modern Web Guidanceの概要
そして、私はこの問いへの答えはイエスだと考えています。私たちがこの領域で取り組んでいる方法の一つが、基調講演でもプレビューをお見せしたModern Web Guidanceという、いわゆるスキルパックです。この取り組みの目的は、皆さんのツールに対して、互換性を高め、モダンなウェブプラットフォームの実装方法について、検証済みで常に最新の状態に保たれたリポジトリを提供することにあります。導入方法は非常にシンプルで、npzコマンドを使ってmodern-web-guidance installと実行するだけです。これはスキルに対応しているIDEやCLIであれば、どの環境でも動作するように作られています。私たちはこれまでに、さまざまな種類のスキルを構築してきました。ウェブパフォーマンス、アイデンティティ、セキュリティといった、高いレベルでのスキルが用意されているほか、皆さんが日々のサイト実装で直面するような、100種類を超える専門的なユースケースについてもガイダンスを用意しています。そして、それらを実際のプラットフォーム上でのモダンな実装方法と組み合わせられるようにしています。
このガイダンスでは、baselineという考え方を強く意識するようにしています。仮に皆さんが使おうとしている機能がbaseline widely availableの状態にまだ達していなかったとしても、フォールバックやプログレッシブエンハンスメントを含めたガイダンスを提供することで、より安心して実装を進められるようにしたいと考えています。つまり、このスキルパックから得られるガイダンスに沿って実装すれば、実際にユーザーに使ってもらえる形になっているはずだ、というのが私たちの目標です。
ただ、それと同時に、皆さんが自分のユーザーがどのような方々であるかを理解しておくことも必要です。そこで私たちは、Google Analyticsとの連携機能を持つ新しいツールも提供しています。これによって、実際に自分のページのアクセス状況をもとに、自分のサイトにとってのbaselineターゲットがどこにあるのかを、ユーザーの実際の利用状況や訪問状況に基づいて把握することができます。この機能は、baseline-checkerというツールを通じて、chrome.devから利用することができます。
全体として、この取り組みが目指しているのは、私たちのコーディングツールがモダンな機能を適切に使いこなせるようにすること、Chromeや業界全体の専門家によるベストプラクティスに沿った形で実装できるようにすること、そして皆さんがウェブプラットフォーム全体の形を隅々まで理解していなくても、自分たちの課題を解決できるような形でプラットフォームの機能を活用できるようにすることです。私自身、この取り組みには非常に大きな期待を寄せています。LLMは、私たちがこれまでにない規模で実験を行える手段を与えてくれつつありますが、その一方で、私たちが作る体験は、高品質で安全であり、なおかつクロスブラウザの互換性を損なわないものであるべきだと考えています。私たちのチームが高品質なガイダンスを構築し、それを維持し続けているこのプロジェクトは、まさにその方向への確かな一歩だと感じています。Modern Web Guidanceについてさらに詳しく知りたい方は、この後の講演で、まさに隣に座っているPhilが、このモダンな会場のセッションで、そしてライブ配信をご覧の方に向けても、Modern Web Guidanceの使い方について詳しく解説してくれますので、ぜひご覧いただければと思います。
5. Chrome DevTools for Agents
5.1 基本機能と活用例
先ほど、私が自分のマシンや大規模言語モデルとどのように対話しているかについてお話ししましたが、私はエージェントと一緒に開発を進める際、単に作業を任せきりにしているわけではありません。実際には、非常にタイトなループの中で一緒に作業を進めています。私が使っているツールは、私が依頼したコードを出力し、それを一通りのテストにかけて実行してくれます。しかし、それらのツールは、実際のページがどのように動作しているのか、ページ上に何が表示されているのか、ブラウザの中でどう動いているのかについて、深い理解を持っているわけではありません。ページの中身を深く検査できるという能力は、長年にわたって開発者にとっての強力な武器であり続けてきました。私たちは皆、Chrome DevToolsやSafari DevTools、あるいはその他さまざまなDevToolsを日常的に使っています。今、私たちが実現したいのは、Chrome DevTools for Agentsを通じて、皆さんのツールにも同じようにページを深く検査する能力を持たせることです。
その一例として、コンソールログやネットワークトラフィック、メモリトレースといった情報へ直接アクセスできるようにしています。また、アクセシビリティツリーへのアクセスも提供しています。こうしたランタイムのデータをツール側に取り込めるようにすることで、パフォーマンスプロファイルの取得、ヒープスナップショットの解析、メモリのデバッグ、さらには自動化されたLighthouseテストといった、非常に高度な診断作業を行えるようになります。Chrome DevTools for AgentsはMCPサーバーとして提供されているため、皆さんがすでにお使いの環境に、他のMCPサーバーと同じ方法でインストールしていただくことができます。あとは、たとえば「developer.chrome.comに対して包括的なパフォーマンス分析を実行して」とエージェントに指示するだけで済みます。すると、パフォーマンス上の問題があることが分かり、何を修正すべきかを教えてくれます。この仕組みの狙いは、デバッグのプロセスそのものを変革することにあり、人手による介入や修正作業をできる限り減らすことを目指しています。というのも、Lighthouse監査のようなもので見つかった問題を、そのままツール自身に修正させることまでできるようになるからです。
5.2 追加された新機能群
このツールを最初にリリースしたとき、私は正直なところ、これで完成だ、もう更新する必要はないだろうと思っていました。ところが、チームからは、いや、まだまだ更新すべきことがある、たくさんアイデアがあるという声が上がり、実際にいくつもの新しい機能を追加することになりました。ここからは、それらを手短にご紹介します。
まず一つ目は、Chrome DevTools for AgentsプロジェクトにSkillsを導入したことです。これによって、ツールがより複雑なタスクを扱えるようになります。たとえばメモリのデバッグが必要な場合には、ヒープスナップショットを取得し、その中身をどう解釈すればよいかまで含めて指示することができます。次に、コマンドラインからの利用に対応したCLIツールも用意しました。コマンドライン上での作業や、エージェントにより少ないトークン数で効率的に動いてもらいたい場合に活用できます。また、TypeScript APIも用意しており、たとえば継続的インテグレーションの環境などに組み込みたい場合に利用していただけます。
さらに、稼働中のChromeインスタンスに接続できる機能も追加しました。これによって、皆さんが作業を中断したところから、エージェントがそのまま続きを引き継げるようになります。これはなかなか良い仕組みだと感じています。実際、OpenClawのような形でこの機能を活用している例もすでに出てきています。加えて、マルチエージェントのワークフローにも対応しました。複数のChromeインスタンスに同時に接続できるようになっており、これはマルチユーザーシステムやマルチロールベースのシステムを構築する場合に重要な機能です。二つ、三つ、あるいは四つの異なるChromeインスタンスに同時に接続することができます。
もう一つの機能として、Chrome DevToolsのネットワークパネルを開いている状態で、パネル内の要素を選択し、その選択内容についてエージェントに分析させるといったことも可能になりました。これにより、DevTools本体とChrome DevTools for Agentsとの間で、非常にスムーズな連携が取れるようになっています。そして最後にご紹介したいのが、Chrome拡張機能の自動インストールと自動デバッグへの対応です。Chrome拡張機能を開発されている方であれば、拡張機能のインストール、サービスワーカーやサイドパネル、ポップアップの検査といった作業を、すべてChrome DevTools for Agentsの力によって、新しいレベルで自動化できるようになりました。
一方にはModern Web Guidanceがあり、こちらはモダンなウェブを構築するためのベストプラクティスへのアクセスを提供することで、より質の高いサイトを作れるようにすることを目指しています。そしてもう一方には、このChrome DevTools for Agentsがあり、こちらはツールがページ上で何が起きているのか、どんな問題があるのかを深く理解し、それを実際に修正できるようにすることを目指しています。この二つが組み合わさることで、非常に良い形のツール支援によるループが生まれ、サイト構築を後押ししてくれると感じています。
6. プラットフォームのBaseline機能とオンデバイスAI
6.1 Baseline機能の進化
ツールが改善され、より高品質なサイトを構築できるようになっていく一方で、実際にプラットフォーム自体にどんな機能が来ているのかにも目を向けることが重要だと思っています。ここからは、ウェブプラットフォームにこれまでにやってきたこと、そしてこれからChromeに来る予定のことについて、簡単に概観をお話ししたいと思います。皆さんもよく耳にされると思いますし、私たちのチームもよく話題にする言葉がbaselineです。これは私たちにとって非常に重要な要素で、あらゆるブラウザがサポートしている機能、つまり開発者の皆さんが本当に安心して頼ることのできる機能群を指しています。
私が去年この壇上に立ってからというもの、55個の新しい機能がbaseline widely availableになりました。これは、皆さんが自分のユーザーベースに対して自信を持って使えるようになった機能ということです。たとえばSearch要素、Origin Private File System、Subgrid、OffscreenCanvas、MathMLといったものが含まれます。このほかにも、さらに50個ほどの機能が続いています。ただ、私が本当に重要だと感じているのは、機能そのものの数だけではなく、すべてのブラウザベンダーが同時にプラットフォームを前進させようとしているという事実そのものです。これによって、あらゆる開発者にとって開発がしやすくなっていきます。そして、去年ここに立ったときから、4月22日時点で44個の機能がbaseline newly availableになりました。これは、近い将来に向けて皆さんが利用を計画できるようになった機能です。これらはすべてのブラウザで利用可能ではあるものの、皆さんのブラウザサポートのマトリクスにおける要件を必ずしも満たしているとは限りません。44個すべてをご紹介する時間はありませんが、プラットフォームに来たこれらの機能によって、ウェブの体感がどう変わっていくのか、いくつかハイライトをお伝えしたいと思います。ちなみに、次のスライドに進む前に、今朝ちょっと確認をしてみたのですが、実は今朝の時点ですでに52個の機能がbaseline newly availableになっていました。
まず一つ目にご紹介したいのがView Transitionsです。これはウェブの感触そのものを変えると考えています。ページ内の異なるビュー状態間、そしてページをまたいだ遷移も、複雑なJavaScriptのライブラリやアニメーションライブラリを使うことなく、スムーズに実現できるようになります。これによって、ウェブの体感的なパフォーマンスが大きく向上することになります。そして、このView Transitionsを補完する形で、新たに利用可能になったのがNavigation APIです。Navigation APIの目的は、古くなってきたHistory APIを置き換えることにあります。これによって、アプリケーションの状態やすべてのナビゲーションを、基本的には一つのイベントを通じて管理できるようになり、ユーザーが戻る・進むの操作をしているかどうかを把握したうえで、それをView Transitions APIと連携させることができます。これによって、ウェブアプリケーションの構築が格段に容易になります。
最後にご紹介するのがCore Web Vitalsに関する話です。Large Contentful PaintとInteraction to Next Paintが、新たに利用可能になりました。これはつまり、ブラウザの種類を問わず、ユーザーが自分のサイトをパフォーマンスと応答性の観点でどう利用しているかを把握できるようになったということです。たとえばユーザーがiOSを使っている場合であっても、これらの指標を取得できるようになります。私は個人的に、ここ数年のCore Web Vitalsの動きに対して非常に強い期待を寄せています。なぜなら、これは実際にサイトのパフォーマンスを改善するうえで大きな助けになるからです。そして今では、ユーザーがどのブラウザを使っていようと、それを問わず状況を把握できるようになっています。
先ほどお伝えしたように、44個、より正確には52個の新機能がbaseline newly availableになっているわけですが、これだけの数を追いかけ続けるのは簡単なことではありません。そこで、webstatus.devというサイトを使うと、Baseline Alertsという新しい仕組みを利用することができます。この仕組みの目的は、機能がいつブラウザに導入されたか、いつnewly availableになったか、あるいはwidely availableになったかを追跡できるようにすることです。通知はメール、RSS、あるいはWebhookを通じて受け取ることができます。この目的は、プラットフォームがどのように進化しているのかを皆さんに理解していただき、それをもとにビジネスやサイトの計画を、これまで以上に効果的に立てられるようにすることにあります。
6.2 Prompt APIの拡張と実装事例
私が自分の仕事の中で気に入っている点がいくつかあるのですが、その一つは、常に手を動かしていろいろなものを試作できることです。私はChromeを使って、ウェブ開発の最先端にあるものをたくさん作っています。そしてもう一つは、毎日のように開発者の方々と話をする機会があることです。そうした中でよく耳にするのが、まず一つには、もっと簡単に、もっと効果的に出荷できるようにしてほしい、プラットフォーム上に何があるのかを理解したい、プラットフォームの予測可能性を高めてほしいという声です。ウェブを頻繁に壊してほしくない、ということですね。これに応えるのが、先ほどお話ししたbaselineであり、Modern Web Guidanceです。これらは、皆さんがより効果的にサイトを出荷できるよう手助けするためのツールです。そしてもう一つの声が、この先1年から2年、ウェブがどこに向かっているのかを理解し、それに向けて計画を立てたい、というものです。ここからは、その点についてお話ししていきます。
これからお見せするのは、ウェブの中でも非常に触感的な部分、つまり皆さんがウェブを使う中で実際に体験する部分です。私はこの領域を、大きく二つの観点で捉えています。一つは、技術自体が非常に高性能かつ優れたものになってきている中で、どうやってオンデバイスのインテリジェンスを人々の手に届けるかという観点です。そしてもう一つは、どうやって人々のウェブ体験そのものを改善していくかという観点です。まず一つ目の観点についてですが、LLMはコンピュータで何が可能かという概念そのものを大きく変えてきました。テキスト補完やセマンティックなデータ抽出から始まり、その後は要約へと進み、そして今では関数呼び出しを使ったエージェント的なユースケースへと関心が移ってきています。これからお話しするツール群は、皆さんがブラウザによりインテリジェンスを組み込むことで実現したい、こうした新しいタイプの体験について考えていただくために設計されたものです。
私たちがこの領域で大切にしている考え方は、インターネット接続の有無にかかわらず、すべての人がこうしたツールにアクセスできるべきだということです。そして、それをプライベートに、かつ大規模言語モデルの利用に関しては無料で実行できるようにしたいと考えています。Prompt APIはChrome 148で導入されました。このタイミングでマルチモーダル対応も加わり、たとえば画像を解析して、そこで何が起きているのかを理解するといったことも可能になりました。これによって、皆さんが実現したい新しい種類の体験について、より考えやすくなるはずです。ただし、これは現時点ではChromeでのみ利用可能な体験です。そのため、私たちが開発者の皆さんにお勧めしているのは、こうした機能を、アプリケーションの中核として今すぐ組み込むのではなく、プログレッシブに活用できる場所から試していただくということです。
実際に、Trip.com、Drupal、Temuという複数のパートナー企業が、このAPIを使った実験を行い、本番環境にまで導入しています。ここでTrip.comの事例を簡単にご紹介したいと思います。とても短いデモですが、彼らはフライトのナビゲーションを画面左側でより簡単に行えるよう、Prompt APIを組み込みました。もしこのPrompt APIが利用できない環境であれば、この機能自体が表示されないようになっており、利用できる場合には、シンプルでプログレッシブな機能拡張として動作します。Trip.comとしても、この技術の活用を気に入ってくれているようです。
Prompt APIは構造化出力にも対応しています。これを用意している理由は、大規模言語モデルからの出力を制約できるようにするためです。たとえば、キャプションのような特定の内容に応じてアプリケーション側で反応させたい場合、文字列を単純にパースするよりもはるかに効果的に、JSON形式で結果を取得し、そのままアプリケーションのロジックに組み込むことができます。また、対応言語についても、これまでの英語のみから、フランス語、ドイツ語、日本語、スペイン語へと拡張しました。今後さらに対応言語を増やしていく予定です。会場の後ろにいらっしゃるKen Gさんには申し訳ないのですが、ウェールズ語への対応も近いうちに実現してほしいと思っています。ウェールズ語は来るのでしょうか。まだ分かりませんが、私自身も今ウェールズ語を勉強しているところなので、また後ほどお話ししましょう。
今後の展望としては、Prompt APIでできることをさらに拡張していく予定です。具体的には、Gemmaファミリーのモデルを導入する予定で、これが実現すると、ネイティブな関数呼び出しが可能になり、皆さんがウェブの中で自律的なクライアントサイドエージェントを構築できるようになります。こうした今後の改善については、パフォーマンス、品質、セキュリティのすべてにおいて確実なものにしていきたいと考えていますので、ぜひ早期プレビュープログラムにご登録いただき、最新の機能へのアクセスを得ながら、これらのAPIの今後の形に対する皆さんの意見を反映させていただければと思います。この分野についてさらに詳しく知りたいという方には、Thomas Steinerによる「Build New Features Using Built-in AI in Chrome」というセッションがありますので、そちらもぜひご覧いただくことをお勧めします。オンデバイスのビルトインAIについて、私よりもはるかに詳しく、幅広い内容を扱った講演になっています。
7. 新しいHTMLの可能性とHTML-in-Canvas
7.1 宣言的パーシャルアップデートとストリーミングAPI
ウェブとその体験の改善について考えるとき、この一年だけを振り返っても、プラットフォームには非常に多くの新しい機能が加わってきました。私はこうした機能に本当に心を躍らせています。なぜなら、これらはユーザーがこれまで見たことのないような体験を得られるようにするだけでなく、開発者にとっても、これまでプラットフォーム上では実現不可能だったものを作れるようにしてくれるからです。この一年で、プラットフォームは新しい機能に関して大きな飛躍を遂げたと感じています。まず、シングルページアプリケーションが、ルート間のCore Web Vitalsのパフォーマンスを正しく測定できるようになりました。これはソフトナビゲーションの導入によるものです。この機能はもう少し後のバージョンのChromeで登場する予定ですが、私たちのデータによれば、シングルページアプリケーションを運用している場合、Core Web Vitalsの合格率が向上するという結果が出ています。
ただ、ここでもう一つ、今後のUIの作り方そのものを変えるだろうと考えている機能をお見せしたいと思います。これはこの10年でHTMLに起きた最も大きな変化の一つだと考えています。先ほどお見せした子供部屋のデモを思い出していただきたいのですが、あの中にあったパソコンの画面には時計が表示されていて、それが1秒ごとに更新されていました。まさに時計として期待される通りの動きです。しかし、実はこのページにはJavaScriptが一切使われていません。それでも1秒ごとに更新が行われているのです。これは、Chromeに導入される宣言的パーシャルアップデートという実装によるものです。この仕組みによって、通信の過程で送られてきた順序やDOM上に現れる順序とは関係なく、HTMLの更新を後から反映させることができるようになります。
この時計のデモ自体はそれほど実用的なものではありませんが、これが持つ可能性は非常に興味深いものだと感じています。たとえば、非常に大きなアプリケーション構造、たとえば巨大なメニューがあるとします。この場合、まずページの末尾でそのメニューをレンダリングしておき、重要なコンテンツを先に表示させ、そのメニューについては少し後になってからDOMに差し込むという形にすることができます。この機能はChrome 148で利用可能になっています。しかも、JavaScriptを一切必要としないという点も大きな利点です。
もう一つ別のデモもお見せしたいと思います。UIのプレースホルダーという考え方です。たとえばユーザーデータの参照に非常に時間のかかる処理がある場合、多くの場合は別途リクエストを送るという形を取りがちですが、この仕組みを使えば、同じリクエストのままにしておき、HTTPリクエストの末尾でその結果を差し込むことができます。このAPIの仕組み上、最新のデータが届いた時点でユーザーインターフェースを更新してくれるようになっており、これもすべてJavaScriptなしで実現されます。このAPIを使ってできることは他にも数多くありますが、これはまだほんの始まりに過ぎません。
もう一つご紹介したいのが、私が「HTMLを新しいJSONにしたい」と考えている取り組みで、それを後押しする新しいAPIです。フレームワークを使ったことがある方であれば、アイランドアーキテクチャと呼ばれる考え方をご存じかもしれません。私はこれを非常に美しいパターン、美しい概念だと思っていますが、これからは、私たちのような素のJavaScriptを使う開発者にとっても、同じようなことがずっと簡単に実現できるようになります。動的マークアップ向けの新しいストリーミングAPIは、streamHTMLおよびstreamHTMLUnsafeという二つのメソッドを通じて、ドキュメントにHTMLを注入できるようにすることで、体験を刷新する新しい方法を提供してくれます。実際にはこの周辺に一連のAPI群が用意されています。これが意味するのは、fetchリクエストのレスポンスボディをそのまま取り出し、それを直接DOMへとストリーミングできるということです。もはやJSONへの変換処理を行う必要はありません。これは非常に新しく、そして強力なプリミティブだと考えています。これら二つのAPIはいずれもChrome 148からすでに利用可能になっており、比較的新しい機能です。個人的には、これらは私たちがウェブの体験を構築する方法そのものを変えていくだろうと考えています。ぜひ紹介したURLにアクセスして実際に試していただき、フィードバックをお寄せいただければ、それをプラットフォーム全体に広げていく助けになります。
7.2 HTML-in-Canvasの詳細と広がり
ここ一年を振り返ると、私たちはAPIやCSS、JavaScriptの機能を通じて、より複雑で豊かなユーザーインターフェースを構築できるようにすることに、非常に力を入れてきました。ただ、これは単なるAPIや見た目の話にとどまりません。私たちの目標は、スクロールがより快適になり、ビュー間の遷移がより自然になり、人々がデバイスとより物理的で直感的なやり取りができるようなサイトを、皆さんが構築できるように支援することにあります。時間の関係でこのすべてを詳しく紹介することはできませんが、YunaとBramisという二人が、ウェブ構築の考え方を変えることになる五つの中核的なUX原則をまとめてくれていますので、ぜひその講演もご覧いただければと思います。ただ、その中でも私が特に、ウェブで作るものそのものを変えていくと考えている技術が一つあり、それがHTML-in-Canvasです。ここに少し時間を割いてお話ししたいと思います。
冒頭のデモでお見せした、あの3D体験を思い出していただきたいのですが、コンピュータの中に擬似的なウェブブラウザを組み込んだあの表現こそが、HTML-in-Canvasです。この技術によって、標準的なDOMをそのままCanvas要素の中に直接描画することができるようになります。これは、さまざまな形で活用することができます。たとえばQTのような2Dのアプリケーションフレームワークや、あるいは3Dエンジンが、この技術を取り込み始めることも考えられます。それによって、ウェブが持つ豊かなセマンティックなUIレイヤーとしての機能的な利点を活かしながら、Canvasの中でも検索可能で、翻訳可能で、アクセシブルで、操作可能な、本物のDOMコンテンツを持つことができるようになるのです。
このAPIで何ができるようになるのか、少しだけプレビューをお見せしたいと思います。一つのレベルとしては、個々の要素、たとえばinput type=rangeのような要素を取り出し、私たちが通常想定しているものとはまったく異なる見た目に作り変えることができます。これはセマンティクス上は正しいままで、実際にはその場所にinput要素が存在しつつ、新しく豊かなUIレイヤーを提供している形になります。すべてのウェブサイトがこのような見た目になるとは思っていませんし、それはさすがにやりすぎだとも思います。ただ、もし皆さんが一貫したデザイン言語を持っていて、それを今のページ上ではまだ実現できていないという場合には、HTML-in-Canvasのような技術を使ってそれを強化することを検討できるかもしれません。そして、もしこのAPIが利用できない環境であったとしても問題ありません。その場合には単純に、これまでどおりの既存のウェブサイトの見た目のまま表示されるだけです。
さらに踏み込んで、Three.jsのようなものと統合することで、先ほどのような3D体験にまで発展させることもできます。3Dのカーダッシュボードや、インタラクティブな書籍といった表現も可能で、会場の外にはデモステーションも用意していますので、実際にどんなことができるのかをぜひご覧いただければと思います。こうした表現も、すべてアクセシブルかつ操作可能なままです。ブラウザが持つ翻訳や検索といった機能もそのまま活かすことができます。私は、これがウェブに新しいレイヤーの豊かさをもたらすものだと考えていますし、個人的には、これこそが人々がほかのどこでも得られない体験を求めて、ウェブに戻ってきてくれる理由の一つになると思っています。
このAPIは、できる限りシンプルに統合できるように設計されています。もし皆さんがすでにPlayCanvasやThree.jsを使っているのであれば、今日からでもこの技術を使うことができます。Three.jsに新しいマテリアルやテクスチャを追加するのと同じくらいシンプルな形で組み込むことができ、その先の複雑な処理はライブラリとブラウザ側がすべて引き受けてくれます。私はこれを、ウェブを体験する方法そのものを変える画期的なAPIだと考えています。実際にエコシステム全体を見渡してみると、これはWes Bosが行っている取り組みの一つでもありますが、今まさに何百もの実験が行われています。X上でHTML-in-Canvasと検索していただければ、ウェブページを分解したり爆発させたりするような表現に人々が取り組んでいる様子をご覧いただけると思います。もちろんこれらは非常に楽しいデモではありますが、それと同時に、このAPIがどれほど表現力に富んだものであるかを物語っています。
エコシステムの中では、他にも数多くの取り組みが今この瞬間にも進行しています。もし皆さんがこのAPIで何ができるのかを実際に確かめてみたいということであれば、私たちは今、HTML-in-Canvasに関するエコシステム全体の実験を集約する専用ページの構築に取り組み始めています。もし皆さんがHTML-in-Canvasのデモを作られたということであれば、ぜひそのリンクを私たちに送ってください。そのページに掲載させていただきたいと思います。これは本当に美しく、表現力豊かなAPIだと感じています。
8. クロージング
さて、ここまでかなり長くお話をしてきましたが、実は先ほど、私が「エージェント」という単語を何回口にしたか数えている方がいらっしゃいましたので、結果を聞いてみたところ、62回だったそうです。62回ですか、なかなかの数ですね。分かりました。こうしてお聞きいただければ分かるとおり、私はウェブプラットフォームの今後について、非常に強い期待を寄せています。
プラットフォームはこれからも進化を続けていくと思います。実際にウェブを使う人々にとっては、HTML-in-Canvasのような技術や、ウェブを豊かで表現力に富んだもの、そして使っていて本当に楽しいと感じられるものにしてくれる、数多くの新しいUIプリミティブが登場してくることになるでしょう。そしてもう一方では、私たちはウェブを進化させ、WebMCPのような仕組みを通じて、こうした新しいプラットフォームの一員となれるようにし、エージェントやツールを使った体験の中にウェブをしっかりと組み込んでいきたいと考えています。私は、これによってウェブが、あらゆる種類のプラットフォームを横断する形で、ファーストクラスの体験になっていくと信じています。
そして、私にとって本当に大切に思っていること、そして私がDeveloper Relationsという仕事をしている理由でもあるのですが、それは私たちが皆さんにこの変化を乗りこなしていただけるよう、力になりたいということです。このエコシステムを理解し、今何が起きているのかを把握するのは簡単なことではないと私たちも理解しています。だからこそ、Modern Web Guidanceのような取り組みが重要になってきます。皆さんがモダンなウェブに向けて効果的に開発を進められるよう、そのための道具をお渡ししたいと考えています。
本日はここまでとさせていただきます。お越しいただき、ありがとうございました。皆さん、本当に素晴らしいオーディエンスでした。ありがとうございます。