※本記事は、Google I/O 2026にて実施されたセッション「Defining the agentic AI era」の内容を基に作成されています。本セッションは、Logan Kilpatrick氏の司会のもと、Koray Kavukcuoglu氏(DeepMind CTO、Google Chief AI Architect)、Liz Reid氏(Google Search担当)、Josh Woodward氏(Geminiアプリ、AI Studio、Google Labs担当)、Jeff Dean氏(Google Chief Scientist、Gemini共同リード)が登壇し、モデル能力の急速な進化がもたらす生産性と情報アクセスの変革、そしてプロアクティブなエージェントAIの新時代について議論した内容です。動画の詳細は https://goo.gle/AI-at-IO26(Google I/O 2026 AIセッション)、および https://goo.gle/Dialogues-at-IO26(Dialoguesセッション )でご覧いただけます。本記事ではセッションの内容を要約しております。原著作者・登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りが含まれる可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。あわせて、Google for Developers(https://goo.gle/developers)の登録・関連情報もご参照ください。
1. オープニング:Gemini 3.5とエージェント時代の幕開け
1.1 開幕あいさつと登壇者紹介
Logan Kilpatrick: おはようございます、皆さん。Google I/O2日目へようこそ。昨日発表された数々の内容に、私と同じくらい皆さんも興奮していてくれるといいのですが、本当に見どころ満載でした。私自身の受け止め方としては、昨日の発表からは「エージェントの時代がGeminiによっていよいよ本格化してきた」というテーマを強く感じています。皆さんも同じように感じていただけたのではないでしょうか。そのぶん、私自身もこの流れの詳細について聞きたいことが山ほどあります。今日は素晴らしいゲストの皆さんと一緒にお届けします。まずJoshは、GeminiアプリチームとAI Studio、そしてGoogle Labsを率いています。Korayは、DeepMindのCTOであり、GoogleのChief AI Architectでもあります。Lizは、非常に大きな責任と光栄を伴うSearchを率いています。そしてJeffは、Chief Scientistであり、Geminiの共同リードの一人でもあります。今日は楽しい議論になりそうです。
1.2 Gemini 3.5 Flashの開発方針と展開
Logan Kilpatrick: まずはGemini 3.5、そしてエージェント時代について伺いたいと思います。Koray、これを実現するために何が必要だったのでしょうか。
Koray Kavukcuoglu: ありがとうございます。皆さんとこうして素晴らしい環境でお会いできることを嬉しく思います。3.5シリーズは、まずFlashから始めました。私たちが最も注力したかったのは、コーディングとエージェント的なワークフローを大幅に改善することでした。6ヶ月前、つまり昨年9月に3.0をリリースしたときと比べると、非常に大きな進化を遂げていると実感しています。当時のモデルは、推論能力とマルチモーダル理解の面ではすでに高いレベルにありました。そこに今回、エージェント的な能力が加わったことで、まさにこの「エージェント時代」を誰もが利用できる形で実現できるシステムになったと考えています。私たちはこれを、開発者やビジネス向けにはAntigravityやGemini Sparkを通じて提供しています。今後さらに面白い時代が来ると感じています。社内では、コーディングタスクだけでなく、それ以外のタスクにおいてもモデルを非常に集中的に使い込むことで、実際のワークフローを深く理解することに多くの労力を割いてきました。私にとって、これこそが、本当のボトルネックがどこにあるのかを理解するための最大の原動力になっています。そしてそこで得られたフィードバックを研究者やモデル開発者に届け、そこから情報を抽出し、モデルをさらにスケールさせるための解決策を見出しています。というのも、長期にわたるタスク、いわゆるロングホライズンタスクを解決していく上では、依然として技術的に難しい課題が数多く残っているからです。ですが、チームの成果には本当に満足していますし、誇りに思っています。
2. フルスタックAI戦略:モデル・ハードウェア・レイテンシー
2.1 モデル・ハーネス・ハードウェアの共生とTPU
Logan Kilpatrick: Sundarがよく語っているテーマの一つに、Googleが持つ「フルスタックAI」というアプローチがあります。私が興味深いと感じているのは、エージェントを実現し、実際に機能させるためには、多くの点でまさにこのフルスタックAIのアプローチが必要になっているということです。今朝も話していたのですが、モデルとハーネス、プロダクト、そしてJeff、おそらくハードウェアの間には共生関係があると感じています。このスケールを実現するためにはハードウェアが必要になってきます。第8世代のTPUが利用可能になり、AntigravityやGeminiアプリの多くの体験を支えていることについて、何か反応はありますか。
Jeff Dean: そうですね、私たちはこれまで何世代にもわたってTPUを設計してきた、かなり確かな実績を積み上げてきています。当初は、学習と推論の両方に優れたシステムを作ることだけに注力していました。しかし今では、設計にある程度の分離が生まれてきています。学習は少し性質の異なる問題であり、推論には推論なりの合理的な分割があるため、この二つの異なるユースケースに対して、チップ設計上も相応の作り分けをするようになっています。そしてそれが、これらのモデルの推論速度に表れていると思います。まず土台として、非常に大規模なモデルを非常に高速に動かせる優れたハードウェアがあり、そこに優れたインターコネクトなど、さまざまな要素が組み合わさっています。ただそれだけでなく、推論サービングチームや、その上に乗るソフトウェアスタックに関わる多くの人たちの努力によって、これらすべてが噛み合って実現しています。そして私たちが分かっているのは、モデルを使っていて、それが非常に高速であれば、はるかに満足度の高い体験になるということです。逆に遅ければ、体験は損なわれます。これは、たとえそれがユーザーに代わって動くエージェントであっても変わらない事実です。
2.2 Searchにおけるレイテンシーと価値のバランス
Logan Kilpatrick: そうですね。Liz、おそらくSearchチームが誰よりも強く感じている部分だと思うのですが、レイテンシーへのこだわりと、ユーザーにできるだけ早く答えを届けるという点について伺いたいです。Searchにはバランスを取らなければならない要素がたくさんあるように感じます。ユーザーには素早く答えを届けたい一方で、Search自体がエージェントを持つようになり、エージェント的なプロダクト体験へと変わりつつあります。そのバランスをどう考えているのか、興味があります。そして今回のヘッドラインは「検索ボックスにとってこの25年で最大のアップグレード」というものでしたね。これは素晴らしいと思います。
Liz Reid: そうですね、これはKorayのチームとの非常に緊密な連携によって進めてきたことの一つです。興味深かった点の一つとして、レイテンシーがユーザーにとって非常に重要であることは以前から分かっていました。しかし実際には、ユーザーがそのタスクをどれくらい難しいと感じているか、そしてどれだけの価値を提供できているかについて、かなり深い理解が必要になります。ユーザーがどれだけ待ってくれるかは、その一部として、こちらがどれだけの作業を肩代わりしているかに左右されるのです。昨日もある人と話していて、「どれくらいの時間をかけられるものなのか」と聞かれました。それは、何を尋ねられているかによります。もしユーザーが頭の中で「これは一瞬で終わる質問だ」と思っているなら、こちらも稲妻のように速く答えなければなりません。そうでなければ、「なぜこんなに待たされるんだ」となってしまいます。逆に、ユーザーが自分でやれば15分から20分かかっていたようなことであれば、こちらが本当に見事な結果を出せるのであれば、10秒程度は喜んで待ってもらえます。そのため私たちは、どれくらいの時間が適切かということを、継続的に見直し、発展させてきました。そして、先ほど話に出たような、エージェント的なコーディングの要素を取り入れる場合を考えてみます。例えば、今後数週間使い続けるような週末の予定を組むプランナーを作ってもらうのであれば、1分待つことすら喜んで受け入れられるかもしれません。なぜなら、その間に別の作業をして、また戻ってきてそれを使えばよいからです。ですから、情報を扱うエージェントが裏側で動いているような場合には、こうした適応の度合いをきちんと作り込む必要があります。そうすることで、レイテンシーというものをまったく異なる視点で捉えられるようになります。重要なのは、状況が変化したときに、ユーザーに対して素早く反応できることです。そしてこれは常に、「ユーザーにとって何が価値があるのか」という問いに立ち返る作業になります。モデルが良くなっていくことは、その意味でも喜ばしいことです。以前は時間のかかっていたタスクが、より小さなモデルでもこなせるようになるからです。そして同時に、より大きなサイズのモデルに対しては、常により難しいタスクを与えるようになっていきます。
3. Gemini Spark:常時稼働エージェントの実像
3.1 Sparkの概要とJoshの利用変遷
Logan Kilpatrick: どんどん興味が湧いてきますね。私は、こうした新しい能力が実際に世の中に広まっていく過程には、大きな課題の一つとして「実際にプロダクトやサービスに展開していくこと」があると感じています。Josh、ステージに上がる直前にも聞いたのですが、昨日Geminiアプリがトラステッドテスターに公開され、Ultraの購読者にも来週提供される予定ですよね。
Josh Woodward: そうです、来週です。
Logan Kilpatrick: 来週ですね。Gemini Spark、つまり24時間365日稼働し続けるエージェントについてです。Sparkに、あなたが実際にどんなタスクをやらせているのか聞きたいと思っていました。私たちは皆、これから「エージェントに、ある程度長い期間、自分に代わってやらせてもいいと思えることは何か」という問いに向き合うことになると思います。逆に「いや、これは今すぐ自分で答えが欲しい」と思うことは何なのか。Gemini Spark、そしてGeminiアプリ全体について、どのように考えているのか、特にSparkについての知見を伺いたいです。
Josh Woodward: そうですね、これは本当に楽しい体験です。Sparkをテストしていく中で分かってきたことの一つなのですが、使う日を重ねるごとに、これに任せられることがどんどん増えていくんです。それがまさに面白いところです。最初に使い始めたころ、これはかなり前の話になりますが、私は定期的なスケジュールタスクをやらせていました。毎朝、いくつかの作業を代わりにこなしてもらうという感じです。それから、トリガーを設定するフェーズに入りました。例えば、Sundarから重要なメールが届いたら、それにP0のラベルを付けて、その質問についてリサーチを行い、返信の下書きを準備しておく、といった具合です。それから――
Logan Kilpatrick: メールは送らないでくださいね。
Josh Woodward: メールは送りません。
Liz Reid: それはとても重要なことですね、送らない、というのは。
Josh Woodward: そして、それはきちんと守ってくれます。それはいいことです。その後、情報系のタスクに関わるフェーズをいろいろと経験しました。例えば、私はオクラホマシティ・サンダーのバスケットボールの大ファンなのですが、チームに動きがあるたびに、ただ最新情報を届けてもらうようにしています。これは嬉しい驚きだったのですが、単に情報を伝えるだけでなく、まるで熱狂的なサンダーファンが話しかけてくるような口調で伝えてくれるんです。まるでパブか何かで、自分の好きなチームについて誰かとおしゃべりしているような感覚になります。チーム全体としても、他にもいろいろな取り組みを行っています。以前話したこともありますが、資料やスライドを作成してもらうこともあります。
3.2 具体的ユースケースと使用感
Josh Woodward: それは昨日ステージで見せたものの一部でもありました。それも本当に役立っています。実際に感じているのは、たいてい最初の下書きの時点でかなり良い出来になっている、ということです。そこから作業を始めて、必要に応じて編集や修正を加えていくことができます。見ていてとても楽しいです。皆さんにも早く試してもらいたいですね。来週にはできる限り早くスケールさせていきたいと思っています。ですので、楽しみにしていてください。
Logan Kilpatrick: いいですね、本当に気に入っています。
4. モデル展開の難しさとSearchの変革
4.1 全製品への同時展開という難題
Logan Kilpatrick: これは私も感じていることなのですが、こうした新しい能力が実際に世の中に出ていく過程では、大きな課題の一つとして、それをプロダクトやサービス全体に展開していくことがあります。Koray、モデルを作り、それを届けていく上でのプレッシャーについて伺いたいのですが。私たちは素晴らしいモデルを作ってきましたし、歴史的に見ればまだ少し楽だった時期もあったと思います。というのも、そのモデルを使うプロダクトの数自体がまだ少なかったからです。しかし今では、成功事例が積み重なるにつれて、私たちのモデルはGoogleのすべてのプロダクトと、外部のエコシステム全体が構築の土台として使うものになっています。今や、モデルを取り込んでGoogle全体に届けていく作業に関わる人が何千人もいますし、同時に「モデルにこれをやってほしい」と願う人も何千人もいます。モデルという観点から見て、Koray、誰もがGeminiにすべてを求める世界の中で、そのバランスをどう見つけているのか伺いたいです。
Koray Kavukcuoglu: 私自身にも、やってほしいことのリストがあるのですが、チームに話すと、いつも一番優先度が低い扱いを受けているように感じます。
Logan Kilpatrick: それはチームに直接言わないと。おそらく彼女もここにいると思いますよ。
Koray Kavukcuoglu: 私の見方としては、こうしたフィードバックをすべてきちんと取り込むことが重要だと考えています。これは確かに大きな課題です。というのも、私たちが今置かれている状況を見てみると、Gemini 3.5 Flashは、Geminiアプリ、Spark、Search、Antigravity、そしてAPIというように、リリースした瞬間に世界中のほぼすべての人に、初日から届く形になっています。ですから当然、全体の面で満たすべき最低限の基準を定めるという判断を下すことにはなります。ただ、最終的に重要なのは、これは常に「知性を作り上げていく」という旅の一部だということです。私たちが踏み出しているステップは、Geminiアプリであろうと、Sparkであろうと、Searchであろうと、どの面から見ても、皆が求めているものと共通しています。私たち一人ひとりが望んでいることも、ユーザーや開発者、ビジネスが望んでいることも、突き詰めれば「より高い知性」です。それが共通項であり、私たちが行うすべての原動力になっています。それが常に最優先事項です。そして、その知性はさまざまな形で現れてきます。もちろん推論能力も重要ですし、世界を理解する力も重要です。エージェント的な行動も重要です。ですから、私たちの最優先事項は、まず基礎的な部分を正しく作り上げることです。そのうえで、モデルがカスタマイズ可能であること、そしてユーザーとの関わり方が適切であることを両立させていく必要があります。モデルそのものを一つのプロダクトとして捉えるという戦略は非常に重要だと考えていて、そのために社内外のあらゆるプロダクトやインターフェースと連携しながらモデルを開発しています。ただ、これが現実です。私たちは今、純粋な学術研究でもなければ、完成しきった製品でもない、その中間に位置しています。イノベーションが止まった、停滞したプロダクトというわけでもありません。まさに、技術を世の中に送り出していくという、非常にエキサイティングな領域にいるのです。そして、技術を前進させることと、それを実際に役立つものにすることの両方を同時に成立させる、そのバランスを見つける必要があります。
Logan Kilpatrick: そうですね。人々がよく口にする緊張関係の一つとして――そしてこれこそが、I/Oのようなイベントを、モデルチームに対して共感を持って見るのを難しくしている理由でもあると思うのですが――先ほどのお話にも重なりますが、今日モデルを作るということは、従来型のソフトウェア開発やプロダクト開発とは違うということです。これは本当に研究そのものです。そして時には、研究であるからには、うまくいかないかもしれない賭けをすべき場面もあります。結果がどう転ぶか分からないのです。だからこそ、特定の日に、世界中のすべての人に向けてモデルを届けるというのは、非常に難しい問題になります。そして私たちはそれをやり遂げたわけで、これは本当に素晴らしいことだったと思います。
4.2 3.5 FlashによるSearchの変化
Logan Kilpatrick: 実際、Liz、私たちはそれをやり遂げましたね。私が驚き、そして非常に興奮したことの一つが、3.5 FlashがSearchの中で実際に全ユーザーに提供されたことです。これはおそらく、私たちのフロンティアモデルを全ユーザーに届けた初めての事例ではないかと思っています。知性の向上がSearchにとって何を可能にしているのか、伺いたいです。人々がSearchについて考える見方そのものを変えつつあると思うのですが、私が気に入っているタグラインは「Google SearchはAI Searchである」というものです。これは素晴らしいと思います。
Liz Reid: 3.5では、推論能力と指示追従性が本当に効いていると感じています。Searchは一つのものとして捉えられがちですが、その裏側には実際には数多くの異なるツールが存在しています。例えば、スポーツのバックエンドに問い合わせたり、金融データに問い合わせたり、ローカル情報や旅行情報に問い合わせたりしています。それらすべてを一つの体験としてまとめ上げる必要があるのです。モデルの推論能力が向上するにつれて、こうした要素をどう考え、どう情報をまとめ上げ、どうトレードオフを判断するかについて、より優れた理解ができるようになっています。Searchで前進を遂げる上で本当に素晴らしかったことの一つは、DeepMindと行き来しながら協業できていることです。私たちはこう伝えます。「こういう課題に直面しています」と。ただ、「この特定の機能をSearch向けに動くようにしてください」とお願いするのではなく、両チームの間でブレインストーミングのようなやり取りが生まれます。根本にある課題は何なのか、ツールの使い方の何が難しいのかについて何を学べるか、それを正しく解決するためにどう連携できるか、限界を押し広げるための適切な評価とはどのようなものか、といったことです。そうすることで、モデルを特定のプロダクト向けにではなく、全員にとって一般的な形で拡張しながらも、Searchが必要としていること、Geminiアプリが必要としていることを理解し、その機会や課題を見出し、前進させていく方法を見つけようとしています。
Koray Kavukcuoglu: それこそが本当に重要な点だと思います。私たちはアプリともSearchとも、そうした関係を築くことができました。個別の問題を解決するのではなく、根本にまで踏み込んでいくということです。ここは、はっきりと言っておきたいのですが、個々の問題だけを直そうとしてもうまくいきません。常に根本原因まで立ち返って、それを解決しようとする必要があるのです。
5. エージェント時代の技術的課題:ボトルネックとツール再設計
5.1 ツール速度のボトルネック仮説
Logan Kilpatrick: 興味深いテーマの一つとして、Jeff、あなたと三、四週間前に話していたことがあります。モデルの進化が続いていく中で、新しいボトルネックがどこに生まれてくるのか、というテーマです。これについて、あなたは非常に興味深い視点を持っていたと思っていて、ツールを構築したり使ったりする人たちが考えておくべきことだと感じています。その考えを伺いたいです。
Jeff Dean: そうですね。エージェントを基盤とした作業の見方の一つとして、こう考えることができます。エージェントは強力なモデルの上に構築され、そのモデルは非常に高速なハードウェア上で動くことが期待されています。そしてエージェント自体も、十分に軽量で、そこそこ高速かつ有能であるべきです。しかし、もし新しい技術や新しいハードウェアによって、モデルの中で費やす時間そのものが劇的に短縮されると考え始めると、話が変わってきます。これらのモデルが利用しようとしているツールの多くは、人間が使うことを前提とした速度感で作られています。例えば「ディレクトリ内のファイルを一覧表示する」「このファイルを取得して開き、何か処理をする」といった具合です。もしモデルを無限に高速化できたとしても、アムダールの法則が示す通り、作業時間の半分をツールの側で費やしているのであれば、たとえ現実には存在しないような魔法のハードウェアがあったとしても、得られる高速化はせいぜい2倍にしかなりません。
Logan Kilpatrick: それは私も、ぜひ手に入れたいですね。魔法のハードウェア。
Jeff Dean: ですから私は、エージェントをより多くの用途に使い、より幅広いツール群を構築していくにつれて、そのツール自体にも多くの注意を払う必要が出てくると考えています。どうすればそれらのツールをできる限り高速かつ堅牢にできるのか。あるいは、ツールが本来やりたいことに対して、近似的な手法を用いることも考えられます。本来の処理をそのまま行うのではなく、多少軽量な形にすることで10倍速く動かせるのであれば、それは構築の観点から非常に重要になってくると思います。もし、コードを書き上げるのに1週間かかるような長時間のタスクがあるのだとしたら、それを半日で終えられるようにしたいと考えるはずです。
Koray Kavukcuoglu: ここには、非常に良い循環があると思います。私たちはGoogle社内において、エンジニアリング環境全体が非常に自動化されているという恵まれた立場にいます。これはもちろん、Jeffをはじめとする人たちがこの環境を作り上げてくれたおかげです。ただ、多くのものは人間の頻度、人間のペースに合わせて設計され、作られてきました。ですから、今の状態にたどり着けたこと自体、最初の一歩としては驚くべきことです。しかし今、私たちは非常にエキサイティングな段階に入りつつあります。それは、自分たち自身のモデルを使って、スタック全体を見直し、この新しいエージェント的な世界に適応させていけるという段階です。そうすることでツールが速くなり、その結果モデルもより良く機能するようになります。そしてそれがまた別の循環を生み出す、という点に、私は期待を持っています。
5.2 内部ツール高速化の実例
Jeff Dean: ええ。実際に良い例を一つ挙げられます。私たちは以前、モデルが利用しようとしていた社内ツール群を数多く抱えていました。その多くはPythonで書かれていました。それが扱いやすく、良いやり方だったからです。ですが、Pythonは決して最速のプログラミング言語ではありません。ですから、ツールの起動時間そのものがかなり遅いという状態でした。しかし今では、モデルはそれに対応できるだけの能力を持つようになっています。自然言語のプロンプトでモデルにコードを書かせようとすると、それは多くの点で仕様が曖昧なタスクになります。モデル自身が多くの詳細を補って埋めなければならないからです。しかし、「これは機能を検証する多数のテストが揃ったPythonのプログラムです。このシステム全体をGoに翻訳してください」とモデルに頼むのであれば、これははるかに仕様が明確なタスクになります。なぜなら、Pythonという形ですでに完全に機能する仕様が存在しており、あとはそれを別の言語に置き換えるだけだからです。そして実際に、多くの社内ツールを、たった一晩の作業で10倍から20倍高速に書き直すことができました。
Josh Woodward: そして、これに関してもう一つ興味深いのは、ツールをどう速くするか、いわば人間の速度ではなく機械の速度でツールを動かすようにするという側面がある一方で、もう一つの側面として、Google Labsで新しいプロダクトを作る中で私たちが見出したのは、コンテキストに関する部分です。人間が読めるだけでなく、機械が読める形でコンテキストを準備するには、どうすればよいのか、ということです。今では、何ヶ月もの間PRDを書いていないチームが社内に丸ごと存在しています。それはもう古いやり方だからです。今では、MDファイルであれ他の形式であれ、モデルがそのまま読み取って作業を進められるような形で文章を書くようになっています。昨日のステージでも紹介した通り、Stitchもその一例です。私たちのラボの実験の一つですが、彼らはDESIGN.mdファイルというアイデアを導入しました。これは今ではオープンソース化されていて、「これが私たちのアプリのデザイン言語です」という内容をそのままコード化しておくことができます。そして、モデルはそれをそのまま受け取り、実行し、従うことができるのです。ですから私は、ツールの速度そのものと、コンテキストの両方が重要だと考えています。人間にも機械にも読み取れる形にすることは、非常に興味深いテーマです。
6. 働き方とエンジニアリング文化の変容
6.1 Korayのレビュー体験と非同期開発
Logan Kilpatrick: そうですね。ちょうど何か付け加えたいことがありましたか、Koray。
Koray Kavukcuoglu: そうですね。こうした変化全体が、ソフトウェアエンジニアリングのやり方そのものを大きく変えていくと思っています。実際、Google社内でもそれを目の当たりにしています。私はこれを、モデルにおける次のフロンティアが何であるかを理解するための機会だとも捉えています。だからこそ、私は外部・内部を問わず、プロダクトと一緒に仕事をすることにいつも興奮を感じるのです。モデルを開発する研究者やビルダーが持つべき、あのファーストパーティの体験というものは、代えがたいものだと思います。それが常に主要な原動力になっています。ですから、ここにいる多くの方々も、同じようなことを経験されていると思います。なぜコーディングが重要なのか。私たちはモデルをそうやってテストしているからです。ただ、今日私たちが目の当たりにしている大きな変革の一つは、これまで多くの制約のもとで設計されてきたインフラそのものを作り変えていくということです。この新しいエージェント的な世界において、私たちは自分たちのソフトウェアインフラ全体を、はるかに速いスピードで作り変えていくことができます。これこそが、エージェント的コーディングがもたらす最大の推進力の一つになると思っています。
Logan Kilpatrick: そうですね。エージェント的コーディングと言えば、Koray、あなたは昨日、私たちが話していた会話の中で、Googleに買収される前は、DeepMindのコードをすべて個人でレビューしていたとおっしゃっていましたね。
Koray Kavukcuoglu: それは初期の頃の話です。
Logan Kilpatrick: 初期の頃ですね。あなた自身が、すべてのプルリクエストや変更を個人でレビューしていたと。
Koray Kavukcuoglu: ええ、そしてある時点で、それはさすがに理にかなわないと気づきました。ですが、しばらくの間はそれを続けていました。
Logan Kilpatrick: そうですよね。その視点も踏まえて、皆さんそれぞれ、仕事の内容が時間とともにさまざまな形で変わってきたと思うのですが、AIツールの登場や、私たち全員の働き方そのものが、皆さん個人としてどう変わってきたのか、あるいはまったく変わっていないのか、伺いたいと思います。誰からでも構いません。
Koray Kavukcuoglu: ルネサンスが起きているような感覚があります。私自身について言えば、Googleに入る前はそれほどコードを書いていませんでした。いえ、正確には、Googleに入る前はたくさんコードを書いていたのですが、その後しばらくコーディングをしなくなりました。そして今回のAIコーディングの革命によって、また毎日ソフトウェアを書くようになりました。これは本当に素晴らしいことだと感じています。私も同じ感覚です。以前はたくさんコードを書いていましたが、キャリアが進むにつれて、それは徐々に少なくなっていきました。そして今では、何かを見たときに、「これは別のやり方でできるのではないか」とか、「こういうアイデアを試してみたい」と思ったときに、それを実行に移すのがとても簡単になっています。日々のさまざまな会話をしているのと同じように、今取り組んでいる部分について、エージェントと会話をするだけで済むからです。「今、この部分を変えようとしているのですが、見てもらえますか」というように。しかも、それを非常に非同期的に進めることができます。それが私にとって、大きな支えになっています。というのも、たとえ自分の時間が多くのことに分散していても、夜になってから戻ってきて、「エージェントは何をしてくれたのか」を確認し、その結果を見て気に入る、ということができるからです。そうすることで、より生産的な感覚を得られています。正直なところ、それが気に入っています。
Logan Kilpatrick: でも、そのコードは誰がレビューしているのですか。Jeffですか。いや、それが本当の疑問ですね。Liz、すみません。
6.2 コーディング復帰と職種の融解
Liz Reid: 興味深いことの一つは、職種の境界があいまいになっていく様子を目の当たりにしていることです。多くの場合、人はある程度の土地勘は持っているものの、そこにたどり着くまでの初期コストが非常に高いという状況があります。例えば、「このデータに関する疑問を理解したい」と思ったとき、そのためのツールがどこにあるのか分からない。そうすると、本来もっと高度な作業をすべきデータサイエンティストに、わざわざ声をかけて情報を探してもらうことになってしまいます。でも、なぜそんなことをしなければならないのでしょうか。それは単に、データがどこにあるのか自分では分からないからにすぎません。実際には何が起きているのか。今では、エージェントと一緒に作業するだけで済みます。エージェントがそれをやってくれて、そこから自分で作業を進められます。プロダクトに手を加えることもできますし、コードを変更することもできます。私自身、何年もコードを書いていませんでしたが、今ではまたコードを書けるようになりました。というのも、多くの初期コスト、つまり何がどこにあるのかという知識の部分は、Googleや Searchのように巨大なコードベースにおいては、すべてに精通することが難しい要因になっていたからです。ですが、アイデアそのものは持っていたわけです。そして、これは私のレベルだけでなく、その下のレベルでも同じように起きていると思います。例えば、PMがUXデザイナーに「なんだかしっくりこない」と伝え、それをエンジニアにどう説明すればよいか悩む、というプロセスの代わりに、PM自身がスキルファイルやデザインファイルを直接変更し、それを見て、自分のアイデアが思っていたものと違うと気づき、また試すことができるようになります。そして最終的に良いものができたら、それが十分なパフォーマンスを発揮できるかどうかなどを詰めるために、エンジニアと一緒に作業をすればよいのです。ですから、これは本当に素晴らしいことだと思っています。というのも、人々が自分の仕事のうち、これまでは小さな割合しか担えず、誰かに頼らざるを得なかった部分を、自分の手に取り戻せるようになるからです。そうすることで、より多くの人が「自分は単なるコーダーでもデザイナーでもなく、ビルダーなのだ」と感じられるようになります。そして実際には、他の人たちと連携しながら、一緒に何か面白いものを作り上げていくことができるようになるのです。
Jeff Dean: 私から言えることの一つは、これがソフトウェア開発や実験のスピードを本当に加速させているということです。特に、自分があまり詳しくない部分のコードベース、つまり自分自身が書いたわけではない大きな部分において、それが顕著だと感じています。例えば、あるパフォーマンスの問題に飛び込んで、「なぜこの処理がフリート全体でこれほど多くのCPUサイクルを消費しているのか」といったことを調べ始めることがあります。それは、自分があまり詳しくない部分のコードであることも少なくありません。ただ、そのパフォーマンスの問題が何であるかを見極めることはできますし、非常に高いレベルで、「このロッキングの仕組みを別のものに変えたら違うのではないか」「このデータ構造を別のものに置き換えたら良くなるのではないか」というアイデアを言葉にすることができます。実際にその変更を手作業で行うのはかなりの労力を要する作業です。しかし今では、そうしたアイデアを次々と口にして、エージェントにパフォーマンスへの影響を計測させ、すべてのテストを実行させることができます。それによって、はるかに生産性を高めることができます。そして、Korayが言っていたように、それを非同期的に行うこともできるので、それも非常に良い点だと思います。
Josh Woodward: ええ、それが大きな変化の一つだと感じています。私自身、以前よりもはるかに多くの作業を非同期で行うようになりました。そして、同期的に何かを行う時間については、しっかり確保し、守るようにしています。その時間は、私のスケジュールの中でより貴重なものになったと感じます。また、スマートフォン上で行う作業も増えましたし、音声を使って行う作業も増えました。ですから、それも変化した領域だと思います。以前はプロジェクトとして成立しないと感じていたようなことでも、今ではスマートフォンだけで完結できるようになっています。日々の変化として、そうした点を挙げられると思います。
7. 次世代インターフェースを巡る模索
7.1 非同期インタラクションという設計思想
Koray Kavukcuoglu: 少しだけ宣伝させてください。Sparkは、まさにこうした非同期的なやり取りのために設計されています。Geminiアプリのチャットや Searchを使うときは、対話が継続的に続いていくことを期待しますよね。ですがSparkは、エージェントが皆さんに代わって何かを実行しに行くという、非同期的なやり取りのためのものです。そして皆さんは後で戻ってきて確認することもできますし、エージェントの側から「終わりましたよ」というように通知してくれることもあります。これは大きな鍵になると思っています。
Logan Kilpatrick: そうですね、これはまさに、私がこれから伺いたかったインターフェースの未来についての質問への良い導入になります。モデルが変わり、能力が変わっていく中で、私たちは昨日Gemini Omniを発表しました。あらゆる入力を受け取り、あらゆる出力を生成できるようにするというもので、これは本当に画期的です。また、Google製品全体にわたって、新しい音声インターフェースも数多く発表しました。Josh、Labsチームは、こうした新しい能力を使って次に何をすべきか、音声ネイティブでこれらすべての課題を解決するような次のインターフェースがどういうものになるのかを模索する先頭に立っていることが多いと思います。皆さんが今取り組んでいて共有できることがあれば、あるいは一般的な感想でも構いませんので伺いたいです。
Josh Woodward: そうですね、私たちはいろいろと仕込んでいます。実際にうまくいくかどうかは、もう少ししたら分かると思います。私たちが取り組んでいることの一部は、例えば音声だけのインターフェースを取り上げて、それを極限まで突き詰めたときに、その先には何が生まれるのか、ということです。どんなプロダクトになるのか、どんな体験になるのか。というのも、現時点で、音声を伴ったモデルについては――昨日もその一部をお見せしようとしましたが――Sundarが紹介したDocs Liveでドキュメントを作成していく様子や、私がSparkで試みたもの、あるいはこの会場全体で今日皆さんが目にするであろう様々なものを見ても、そこはまさに私たちが探求していこうとしている領域の一つだと感じています。Korayが言っていたことに少し重ねると、私たちが歴史上ずっとコンピュータを使ってきたやり方の多くは、同期的なものでした。もちろん、必ずしもそうだったわけではなく、入力してミリ秒単位で答えが返ってくる場合もあれば、初期の大規模システムなどでは、コーヒーを淹れに行かなければならないほど時間がかかることもありました。ただ、これから先は、何かを「肩越しに放り投げる」ようにして任せられるという感覚が、私たちのデザインの考え方そのものを変えていくと思っています。実際、Sparkの最初のデザインは、どちらかというとダッシュボード的な見た目になっています。それが最終的な形になるとは思っていません。正直、それが最終形だったら逆に驚くくらいです。ですから、何らかの形が生まれてくるだろうと思っています。人によっては、これはダッシュボードなのか、それともコマンドセンターなのか、と話しています。どこで、これらすべてを采配していくのか、という話です。
Logan Kilpatrick: ミッションコントロールですね。
Josh Woodward: ミッションコントロールでしょうか。
Logan Kilpatrick: まるでNASAの管制室のような。
Josh Woodward: そうです、でもそれだと読み取るのが大変そうですね。
Logan Kilpatrick: モニターが1000台あって、そこに20人が張り付いているような。
Josh Woodward: その通りです。ただ、私は、より自然に感じられるインターフェースへと向かっていく流れも、あるのではないかと思っています。だからこそ、私は音声について強く期待を持っています。というのも、世界中の誰もが、人と話すという方法を子供の頃から学んできているからです。ですから、音声に加えて、物事がどこまで進んでいるのか、どこで自分の助けが必要なのかを教えてくれる、何らかの「状態」の感覚が組み合わさることで、そこに何か新しいものが生まれる可能性があると感じています。ただ、これから多くの実験をしていくことになると思います。どうなっていくか見てみたいですね。
7.2 ダッシュボードの限界と多様な最適解
Jeff Dean: そうですね、ダッシュボード的な見せ方というのは、ある程度のレベルまでは十分にスケールする良い方法だと思います。ただ、それは10件程度のことには適しているかもしれませんが、100件もの物事を同時にこなそうとする場合には、おそらく機能しなくなるでしょう。そうなると、「これらのタスクはすべて関連している」といった階層構造を導入する必要が出てくるかもしれません。あるいは、毎日エージェントたちとの間でスタンドアップミーティングのようなものを持つことになるかもしれません。それは誰にも分かりません。私が思うに、問いはこうです。もし一人ひとりが30人のバーチャルインターンと一緒に働くようになったとしたら、それをどう調整すればよいのでしょうか。
Koray Kavukcuoglu: あるいは、Lizがやっているような、Searchでのやり方をそのまま踏襲して、エージェント自身にインターフェースを設計させる、というのもあるかもしれませんね。
Logan Kilpatrick: そうですね、確かにそうかもしれません。
Liz Reid: インターフェースがすべての人にとって同じであるべきなのか、という点は興味深い問いだと思っています。実際、あなたがタスクを処理する際の考え方と、私が考える処理の仕方、あるいはJeffが考える処理の仕方は、それぞれ違うのではないでしょうか。もし本当にエージェントを持つのであれば、そのエージェントは、他の誰かが望む形ではなく、あなた自身が望む形で人々を組織化できるはずです。それがどう影響してくるのか、という点です。
Jeff Dean: それは間違いなく、人によって違うべきだと思います。教育の現場を考えても、人によって学び方は異なります。何かをポッドキャストのような形で説明するのと、実際に触って遊べるインタラクティブなツールとして提供するのと、教科書の一章として提供するのとでは、それぞれまったく異なる学び方になります。そして、それぞれが異なる人にとって、それぞれ適した形になっているのです。
8. 驚きのエピソード集とソフトウェアの未来像
8.1 登壇者それぞれの驚き
Logan Kilpatrick: そうですね。皆さんに反応を伺いたいことの一つがあります。私たちはこの動きにとても近いところにいるからこそ、感じることだと思うのですが、I/Oで発表したもの、あるいはここ数週間、数ヶ月の間に発表したもので、何か皆さんを驚かせたものがあれば、その視点を聞いてみたいです。まず私から簡単に一つ挙げると、Omniに関することです。私が驚かされた部分というのは――実は今朝もその話をしていたのですが――頭では、モデルが強力だということは理解していました。動画版のNano Bananaのようなものだと。ただ、実際にあのポッドキャストの導入クリップを見たときのことです。何人かがポッドキャストで話していて、私が猫と植物を持っていて、いろいろなものが飛び交っている、というあの例です。それを見た瞬間、腑に落ちたんです。「ああ、なるほど」と実感しました。私が驚いたのは、その使い方こそが、自分にとって「腑に落ちる」瞬間だったということです。そしてそれはおそらく、動画を撮って、そこに面白い加工を施すという応用の仕方であって、コンテンツの核となる内容自体は変えずに、それをより魅力的にする、あるいは補足的な要素を加える、というものだと思います。Jeffが言っていたように、教育的な文脈などでも活用できそうです。
Josh Woodward: では、皆さんに伺いたいのですが、ローンチしたモデルの能力という観点から、何か驚かされたことがある方はいますか。
Josh Woodward: では、私から一つ手短に。Google Flowが昨日ステージに登場しました。これは映画制作者向けに私たちが作ったツールです。その中でこっそり組み込まれていたものの一つが――I/Oのステージではすべてが本当にあっという間に過ぎていくのですが――製品の中に、ツールを自分で作れる新しい領域を用意したことです。これがうまく機能するかどうかは、これから見ていくことになりますが、私たちのプロダクトデザインの考え方における大きな飛躍の一つになると思っています。というのも、私たちはアプリの一部を丸ごと切り出して、「映画制作者やクリエイターであるあなた自身が、そのツールをバイブコーディングしてください」と言っているからです。これは3.5 Flashの推論力やコーディング力の進化をフルに活用したものです。人々は、まさにこの点において、自分自身のソフトウェアをそのツールの中で実際に作れるようになると思います。私たちにとっては、I/Oに向かう中で初めてこれを見たときに大きな転換点だと感じました。プロダクトチームとして、私たちはいわば薄いシェルのようなものを作り、その中でユーザーが道具を自分のものとして使いこなせる余地を残しているのです。これは非常にエンパワーリングなことだと思いますが、同時に、「すべての機能やツールを自分たちが設計しなければならない」という考え方とはまったく違う考え方でもあります。実際には、そうではなく、ただツールをテーブルの上に並べておけばいい、ということなのです。使う人たちは非常にクリエイティブな人たちですから、シェーダーやテキストオーバーレイ、ライティングエフェクトなど、欲しいものを自分たちで作っていくでしょう。今日から人々が使い始めて、これがどう広がっていくか、とても楽しみにしています。私たちのDiscordは、すでに創造的なアイデアで盛り上がっています。これが私にとっての一つの例です。
Logan Kilpatrick: それはいいですね。
Koray Kavukcuoglu: 私にとっては、Antigravityで見せたオペレーティングシステムのデモが驚きでした。私たちはこのモデルにしばらく取り組んできましたし、こうしたエージェント的な能力やコーディング能力にも長らく取り組んできました。ですが、「チームワーク、行っておいで、オペレーティングシステムを作ってきて」と言うだけで、実際に何百ものエージェントが1日半にわたって作業をし、実際に機能する動くものを持って戻ってくる、という能力には驚かされました。今でも、それを見るたびに感銘を受けますし、驚かされます。ある意味、いつも一歩引いて考えてしまいます。これができるということ自体が印象的ですし、それをこの規模で実現できることも印象的です。このスピードで実現できることも印象的ですし、Antigravityを使うすべての人にこれを提供できるという規模感で実現できることにも興奮しています。
Logan Kilpatrick: 素晴らしいですね。
Koray Kavukcuoglu: ええ。
Liz Reid: 私にとっては、エージェント的なコーディングの能力をどうやってSearchに取り入れるかを検討し始めたときのことです。最初はモデルと一緒に作業を進めていました。ですが、途中で「一部のより高度なユースケースについては、Antigravityを使ってみたほうがいいのではないか」という話になりました。そして、それが非常にうまくいったので、「では、もっと多くの場面で使ってみるべきではないか」という流れになっていきました。もし4ヶ月前に「Antigravityを持ってきて、それをSearchの中核に据える」と誰かに言っていたら、皆「一体何を言っているんだ」と思ったはずです。
Logan Kilpatrick: Lizがおかしくなってしまった、と(笑)。
Liz Reid: SearchとDeveloper向けのツールですよ、と。そんなものが一緒になるはずがない、と言われそうな組み合わせです。でも実際にやってみるのです。そして、非常に情報中心でありながら、それをきわめて個人的かつカスタマイズ可能な形に変えていく力を、実際に解き放てることが分かります。ですから私は、私たちがこれをどう取り入れられるかについて、これまで以上に理解を深めてきたと感じています。そしてそれは、見ていて非常にワクワクすることです。
Koray Kavukcuoglu: ここで少し補足させてください。私たちが「Antigravity」と言うとき、実はいくつかの異なるものを指しています。まず、開発者に提供しているユーザーインターフェースとしてのAntigravityがあります。ですが、それに加えてハーネスがあり、SDKもあります。私たちはそのSDKも提供しています。ですから、Searchがそのために使っているのとまったく同じ能力を、そのSDKの上に構築してSearchにエージェントを組み込んでいるのと同じように、私たちはすべての開発者やビジネスに対しても、Geminiと共同で開発された、まさに同じSDKを使えるようにしています。これによって、誰でもそれを使ってアプリケーションを構築できるようになっています。
Logan Kilpatrick: 素晴らしいですね。
8.2 ビスポークソフトウェアの未来
Jeff Dean: これまでのいくつかのテーマをまとめてみたいと思います。というのも、これらを合わせて考えると、非常にワクワクするビジョンになると思うからです。これまで、ソフトウェアというものは、ある程度標準化された形で作られ、さまざまな場面で使われるものでした。しかし、必ずしもその状況にぴったり合っているわけではない場合もありました。それでも、作るためのコストが非常に高かったので、「これでだいたい用は足りる、これで十分」というところに落ち着かざるを得なかったのです。しかし今では、長時間稼働するエージェントが、その場に応じたオーダーメイドのソフトウェアを自ら作り出せるようになりつつあります。それによって、自分自身の環境、Searchの中であれ、どのような場面であれ、実際に自分が本当に望んでいるものにより近い、非常にカスタマイズ可能なシステムを手にできるようになります。システムによって生成された、見栄えの良い可視化が得られることもありますし、メディア生成のためのツール作成の場面でも同様のことが起こります。長時間稼働するタスクが可能にしてくれる本当に良い点は、「こういうものが存在してほしい」と言うだけで、それが実現に向けて自律的に動き出してくれる、ということだと思います。そして、それができあがれば、それを使えるようになるのです。
Logan Kilpatrick: それは素晴らしいですね。
9. ライトニングラウンドとクロージング
9.1 4人への質問と回答
Logan Kilpatrick: 残り2分になりました。ここからは、質問にテンポよく答えていただくライトニングラウンドにしたいと思います。Jeff、あなたにこそふさわしい質問だと思うのですが、2026年において最も重要な開発者スキルとは何でしょうか。
Jeff Dean: コーディングツールやエージェントを使いこなし、生産性を大きく高め、素晴らしいものを作り上げる方法を学ぶことです。
Logan Kilpatrick: いいですね、気に入りました。Liz、今後数ヶ月から1年の間に、現時点ではまだできていないけれど、Searchがユーザーの負担を取り除いてくれるとしたら、どんなことを期待しますか。
Liz Reid: それは人によって少し違うと思います。ただ共通して言えるのは、リサーチや検索、情報収集の中で、単なる骨の折れる作業だと感じている部分を見極め、それを手放せるようにすることだと思います。そうすれば、自分が本当に探求したい、学びたいと思っていることに時間を使えるようになります。
Logan Kilpatrick: それは素晴らしいですね。Josh、この1ヶ月ほどの間で、Gemini Sparkがあなたを驚かせたことは何かありましたか。
Josh Woodward: ああ、ありますね。カレンダーを見て、キャンセルできそうな会議を提案してくれるのが、かなり優れています。しかもそれだけでなく――(拍手)――さらにすごいのは、その理由まで説明してくれることです。そして、必要であれば返信の文案まで提案してくれます。
Logan Kilpatrick: Loganとの1on1ですか。「そんなの誰も気にしない、キャンセルしましょう」ということですね。それはいいですね。そしてKoray、Gemini Ultraモデルはいつ登場するのでしょうか。いや、冗談です。ここまで大きな進化を遂げてきましたが、次に何が来ると思いますか。
Koray Kavukcuoglu: 次に何が来るか、ですか。開発者やユーザーの視点から言えば、これからさらに多くのエージェントが登場してくると思います。私たちは今、まさに、人々の生活のさまざまな場面において、エージェントをどのように適切な形で提供していくかを見極めている段階にいるからです。これはすべて、ユーザーにコントロールを委ね、それを正しく実現することが重要になってきます。今後さらに、こうした流れが広がっていくと見ています。そして、技術という観点から言えば、私たちはさらに多くの技術的なフロンティアが切り開かれていくのを目にすることになると思います。それは単に今日の課題を解決するだけでなく、技術そのものを押し広げていくことでもあります。私たちは知性というものを作り上げようとしています。学び、考え、理解し、創造的であること、そして限界を押し広げていく方法を理解する、そうした知性です。ですから、この二つのことが同時に進んでいくと考えています。
Logan Kilpatrick: ワクワクしますね。I/O 2027で、また答え合わせができればと思います。
9.2 締めのあいさつ
Logan Kilpatrick: 本当に素晴らしい時間でした。今朝、参加してくださった皆さん、そしてライブ配信でご覧いただいている皆さんも、ありがとうございました。ここで少し休憩を挟みまして、その後はJames Manyikaが、Google Quantum AIの創設者であるHartmut Nevenとともにステージに登壇する予定です。発音、合っていましたでしょうか――Hartmutさん。それでは、Josh、Koray、Liz、Jeffに、盛大な拍手をお願いします。
Koray Kavukcuoglu: ありがとうございました。