グーグルAIトップに聞く、AIの進化と計算資源、エージェント時代

Google Researchのジェフ・ディーン氏

Googleとそのクラウド部門であるGoogle Cloudでは、AIとそれに関連する技術の開発が続けられている。現在もっとも競争が激しい分野であり、Googleの生き残りがかかったジャンルでもある。

先日Goole Cloudの年次イベント「Google Cloud Next 25」を取材してきたが、そこで、AI関連開発のキーパーソンに単独インタビューすることができた。

お話を伺ったのは、GoogleのAI研究部門であるDeepMindとGoogle Researchのチーフサイエンティストであるジェフ・ディーン氏。AIに使うハードウェアであるTPUからAIのモデル開発まで、様々な研究をリードするレジェンドだ。彼の言葉から、Google全体のAI技術戦略の今をひもといてみたい。

生成AIの「計算資源」はどうなる

まず、Googleの差別化要素の1つである「演算資源」について考えてみよう。

同社は自社のAI開発のみならず、Google Cloudを介して他社に提供するためにも、独自の演算基盤を構築している。比較的ストレートな機械学習のための基盤から始まったものだが、現在はご存じのように、急拡大する生成AI向けの演算基盤として使われる場合が多い。

その中でもGoogle独自の取り組みとして、機械学習関連の処理を効率的に行なう独自アクセラレータ半導体である「TPU」の開発がある。

今年は新型である「Ironwood(開発コード名)」を公開。2018年に発表した初代TPUに比べ、電力効率は約29倍に向上しているのが特徴だ。

Ironwood

また、Ironwoodは外部公開用としては初めて、強く「推論処理」の効率を意識した半導体ともなっている。

TPUを含めた演算資源開発については、どのように考えているのだろうか?

ディーン氏(以下敬称略)：新しいIronwood TPUシステムは、推論とトレーニングの両方に向いています。つまり、推論の時代に備えたTPU、とも言えます。従来のものよりはるかに高い推論能力を持つ必要が出てきたためです。

より多くのユーザーが、より能力の高い大規模なモデルを使うようになりました。そしてまた、この種のモデルの傾向として、単に推論(inference)を出力するのではなく、より論理的な回答(reasoning)を必要としています。

この点については少し補足をしたい。

生成AIでは一般的に、AIモデルを作る作業を「学習(learning)」、AIに処理を行なわせて結果を得ることを「推論」と呼ぶ。ただ、日本語では「推論」ではあるが、英語では「inference(インファレンス)」と「reasoning(リーズニング)」があり、どちらも同じ言葉として訳されがちだ。

生成AIに関して言えば、inferenceは「AIモデルから出力を得ること」自体を指し、reasoningは複数の処理から複雑な思考や推論を得ることを指す。単純に絵を描くことや文章を要約させることはinferenceだが、Deep Researchのような多段的・多層的推論とその結果をまとめる作業はreasoningである。

reasoningは多数のinferenceを行なった結果であり、reasoningの需要が増えていくということは、それだけinference＝推論の需要が劇的に増えていくという話でもある。

ディーン：推論の需要は、数年前よりも、1年前よりも、はるかに重要になっています。Ironwoodは、推論と学習の両方に対し、非常に優れています。

最大9,216基の構成では、42.5EFLOPS(エクサフロップス)という信じられない能力を発揮します。しかしもちろん、従来と同様に、64基しか必要としないお客様もいるでしょう。それでも単一のコンピューティング要素として使用できます。

私はGeminiを担当する技術リーダーの一人であり、前世代のTPUを複数使って、最大規模モデルについて、学習を行なっています。

内部でスケーリングできる構造というのは、学習には非常に効果的な戦略です。

GoogleがAI関連のインフラとしてTPUを強調する背景には、消費電力性能の高さがある。Ironwoodも電力効率の高さをウリにしているが、TPUは一貫して「いかに効率を上げるか」がテーマだったという。

ディーン：過去10年近くにわたってTPU開発においては、可能な限り電力効率・エネルギー効率の高いプロセッサを作りたい……という点が根底にあります。最初のTPU v1は、現在のCPUやGPUよりも30倍から80倍も電力効率が良かったんです。さらにエネルギー効率を高めるために、多数の機能を追加してきました。

一つの転換点は、液体冷却をTPU v3(2018年)で導入したことです。表面に届く小さな水のパイプがあり、空気冷却ではなく、この種の液体冷却でより高密度の計算を実行できるようになりました。

機能の呼び名こそ変わりましたが、この方針は今も続いています。

現状、私たちは「水冷」にこだわっています。油浸のような、もっとエキゾチックな解決策があるのは間違いありません。しかし、現状水以外の素材は使っていません。

私たちの研究開発チームは常に、エネルギー効率を上げるために、クロックレートを上げるために、次世代の技術はどうあるべきか、様々な方法を検討しています。冷却素材の探索もその中に含まれます。

コンテクストウィンドウと「長期記憶」に向けて

生成AIの基盤モデルを賢くする方法は色々ある。中でも、アウトプットの質を高めるために重要なのが、コンテクストウィンドウの長さだ。一般には一度に処理できるトークン数の上限を指し、会話の文脈保持や長文処理能力、動画生成時の長さや緻密さに影響する。

Gemini 2.5 Proは100万トークンをサポートし、今後200万トークンに拡張される。

Sphere向け『オズの魔法使』の生成リマスター作業には、200万トークンのモデルが使われているという。

では、今後の生成AIの「賢さ」担保の中で、トークン長の拡大はどのような意味を持っているのだろうか。

ディーン：ご存知のように、大きなコンテキストウィンドウは非常に便利なものです。Gemini 2.5 Proで100万トークンを採用したことで、多くの人がその価値を理解したと思います、

100万トークンとは、大体1,000ページのテキストに匹敵します。

トークン長の大きさは、特にコーディングにとって重要です。大きなトークン長で作業する場合、コード全体がコンテキストウィンドウ内に収まることが多いからです。そのため、そのコードに精通した人間のパートナーが作業する場合と同じように、生成AIのモデルがコードベース全体から推論できるため、効率が良くなるのです。

ディーン：長いコンテキストウィンドウを効率的に処理できる理由の一部は、基盤となるTPUハードウェアとチップ間の相互接続にあります。

100万トークンを扱うと考えましょう。1つのチップで100万個のトークンをすべて行なうのではなく、たくさんのチップがあり、そこから複数のネットワークを構築できるという事実は、基本的にモデルのコンテキストウィンドウ・モデルパラメーターを分割できることを意味します。つまり、異なるチップに異なる専門家を配置し、混合したモデルを構成できる、ということであり、複数のバリエーションを構成できます。

重要なのは、経路を構成するインフラです。

これは2016年以来、社内で開発してきたもので、Geminiの大規模モデルのトレーニングや、より大きな構成でのGeminiの推論の多くを実行するための鍵となっています。

オープンソースのソフトウェアシステムであるJax(GPUやTPUなどのアクセラレータを活用し、大規模な計算や並列処理を行なえるもの)を活用していますが、経路システムとの統合により、1つのJaxプロセスで複数のチップを統合的に処理できます。

どの処理も複数のチップで行なわれていますが、Jaxプロセスからは、1つのTPUであろうが1000のTPUであろうが、1万個のチップであろうが同じように扱えます。ソフトウェア開発者にとって本当に素晴らしいプログラミングモデルです。

これはDeep Mindの内部研究にとって非常に強力な要素でした。そして今では、Google Cloudを介してクラウドTPUを使うお客様にも利用できるようにしています。

ただそれでも、生成AIには人間にはない弱点がある。それは「長期記憶」が苦手だということだ。長期記憶とは、単純に過去に行った作業の履歴ではない。「これまでに聞かれたことや行ったことを踏まえて考える」ということだ。次の大きなテーマであり、多くの企業が目指している。

ディーン氏もその点に同意する。そして、「大きなコンテクストウィンドウと長期記憶の関係」を次のように語った。

ディーン：大きなコンテキストウィンドウがあることは、長期記憶の獲得に、明らかに役立ちます。しかし、ある時点で、あなたが覚えておきたいことの量、あなたの人生のために知っていることなどは、100万トークンのコンテキストだけでは収まらないでしょう。

だから、私たちが考えている方法は、ある程度の記憶があり、重要なものを保存して、それを参照できるようにしたいということです。そしてユーザーのリクエストに答える過程で、記憶の中のなにが本当に重要かを判断し、それをコンテキストに配置する方法です。

例えば、10万の文書や写真などを持っているとしましょう。検索プロセスを経て、これらのうち37のことが本当に重要だと判断し、それらのコンテキストに置きたい……と考えるようなものです。さらにそこから、プロンプトに答えるために適切な情報が自動的に入力されているようなものです。

その後、フォローアップの質問をして、他の何かが重要になった場合は、記憶からさらに多くのものを取り出すようになるでしょう。

画像生成を高度化するには

生成AIのモデル開発においては、画像・動画生成に関する競争も激しい。Googleも「Veo 2」を公開しており、かなり品質が向上している。

Veo 2

では、画像生成における品質向上には、どのような点が重要になってきているのだろうか。

ディーン：高品質のビデオを生成するためには一定量の計算を適用する必要があり、より高い解像度を望むほど、より多くの計算を行なう必要があります。各方向の解像度を2倍にすると、突然、4倍の計算量が必要になります。

そこで私が好きな手法は、解像度が低い映像を基盤モデルが生成し、そこからスケールアップすることです。この考え方を元にした様々なテクニックがあり、Googleの研究論文でも使っています。

また、基盤モデルが動画に入れたい要素をちゃんと学習している……ということも重要です。

人がどのように動くか、車がどのように動くか、犬が何であるかなど、動画に入れたいと思うようなあらゆる種類のことを、トレーニング中に体験して学ぶことができるようにする必要があります。

その方法の一つは、世界の様々な動画でモデルをトレーニングして、3次元の物事がどのように機能するかを理解することです。

そして、物体がどのように動くかだけでなく、生成するために、その動きを必要な言語へとマッピングする必要があります。

例えば「スクールバスを飛び越えるユニコーン」を生成したいならば、ユニコーンとは何か、スクールバスとはなにかを、基盤モデルが知っている知る必要があります。

特定のスタイルのビデオが必要な場合は、ベースモデルを使用して、それを少し微調整することができます。そうすれば、あなたが望むスタイルのビデオがより多く見られるようになります。『オズの魔法使』の例はご存知ですよね?

他方、ベースモデルを可能な限り機能的にすることも重要です。微調整するのではなく、特定のスタイルを適応できるよう、促すことができるかもしれません。

スタイルごとに1つのモデルを用意するのではなく1つのモデルで済むので、多くの人々にとっては扱いやすく、展開もしやすくなります。

マルチモーダルは生活を変える

画像と生成AIという意味では、「マルチモーダル」も大きな潮流だ。特に日常の中での利用を考えると、スマートフォンとの連動は一大テーマと言えそうだ。

Googleは昨年のGoogle I/Oで、マルチモーダルを活用した将来の技術である「Project Astra」を発表している。

この技術を含めた、Deep Mindの考えるマルチモーダルモデルの将来はどのようなものだろうか?

ディーン：おっしゃる通り、マルチモーダル性は今後非常に重要な要素です。

そこで私たちは、初期段階のプロトタイプとしてProject Astraを作りました。しかし実際には、その多くの側面が現在ローンチされています。Gemini Liveはスマートフォンから使える、非常に便利な機能です。画面を見て入力したり、画面に表示されているものについて話しかけたりすることができます。

ディーン：こうした技術には多くのトリックがあります。

例えば「適切なデータ」です。トレーニングデータには、通常多くの動画が含まれていません。ある程度の量のトレーニングデータを用意して、モデルがそのようなデータをどう解釈するかを把握し、経験を積んでいる必要があります。

我々は音声入力と音声出力の両方について、遅延の小ささとリアルさにかなり力を入れています。これは本当に重要な要素です。モデルの回答が遅れ、その結果がいかにもコンピュータ化された声だったら、興醒めしますよね。

利用する人がどんなことをしてもらいたいかを理解し、「あのバスはどこ行き?」「このデモビデオで語られているのはどういうこと?」「あの像の謂れは?」みたいに対話したいはずです。

これはGemini Liveの例ではないですが、先日いい例を見ました。100年くらい前に書かれた、手書きの非常に古い気象記録です。その画像をGeminiに入れるだけで、JSON(データ形式)として内容を抽出してくれます。

マルチモーダルは本当に重要です。自分が見ているものを理解できるようにしたいですよね。この分野の能力は非常に急速に向上しており、非常にエキサイティングです。

もうすぐ、さらに多くの進歩が見られるでしょう。

そして「AIエージェントの時代」へ

現在、各社はAIを活用した「エージェントモデル」が注目を集めている。「Google Cloud Next」のメインテーマもAIエージェントの開発だった。

その本質はどこにあり、今後どうなるかを最後に聞いた。

ディーン：現在は、エージェントベースのワークフローが機能し始めている段階だと考えています。要は、複雑な作業を15ステップに分解し、システムと対話してデータを取得し、ウェブページに移動して作業してくれるようになった、ということです。

つまりエージェントベースのシステムで可能にしたいことは、何をしたいのかを非常に高いレベルで説明し、あなたに代わってそれを実行してもらうこと、と言えます。

その結果、今後数年間でさまざまな側面が明らかになるでしょう。

重要な要素の1つは、エージェントが他のエージェントと対話することです。そこでは、標準化されたプロトコルが非常に役立ちます。エージェントがどのように対話するかについてHTTPのようなプロトコルを用意する必要がある、ということです。これにより、人々は一度そのサポートを実装し、その上に多くのものを構築することができます。

これが、「Agent to Agentプロトコル」であり、Google Cloudが主導して発表した技術である。Anthropicが発表したMCP(Model Context Protocol)と相互補完する形で、AIの基盤モデルとそれを使うエージェントが、相互に情報をやり取りしながら動作することになる。

ディーン：個人的なレベルでは、1つのエージェントに何かをしてもらうだけではないかもしれません。一旦は作業を中断しても、次のタイミングでまた関連する作業に取り組むかもしれません。

旅行を例に考えてみましょう。

フランクフルト行きの便を予約してくれと言われたけど、直行便は見つかりませんでした。そこで「経由はロンドンかリスボンがいい」のか、それとも「何でもいいからフォローアップしてくれ」ということなのか。そこでどちらを選ぶのか、理解して動いてほしいはずです。

そこでコンピュータが実際にどう動いたか、人の側は完全には把握していないと思います。しかし、実際にはおそらく20人のエージェントに何かを依頼して、最終的な結果がもたらされる……という世界になるはずです。

そのような環境が整備された時、AIエージェント同士には、どのような相互作用が起こるのでしょう? かなりワクワクするようなことが起きると思いませんか?