はじめに
Googleが2026年1月、公式ブログとポッドキャスト「Google AI: Release Notes」を通じて、AIモデルGeminiのインフラストラクチャを支えるエンジニアリングチーム「Smokejumpers」の活動を紹介しました。本稿では、この発表をもとに、世界最大規模のAIサービスを支える技術的な取り組みと、チームの運営哲学について解説します。
参考記事
- タイトル: In our latest podcast, hear how the “Smokejumpers” team brings Gemini to billions of people
- 発行元: Google Blog
- 発行日: 2026年1月27日
- URL: https://blog.google/products-and-platforms/products/gemini/release-notes-podcast-smokejumpers/
要点
- SmokejumpersはGeminiのサービング、トレーニング、インフラ全般を担当する10〜16名の精鋭チームである
- チーム名は火災の前線に降下する消防士に由来し、高強度な問題解決を担う組織として2022年頃に結成された
- Gemini 2.5 ProからGemini 3シリーズまで、モデルローンチの度に予測困難な課題に直面しながらもスケーリングを実現している
- GoogleのTPU戦略は完全垂直統合型であり、チップ設計からサービングまで一貫した最適化が可能である
- キャッシュヒット率やコンテキストウィンドウの提供は、グローバル最適化とユーザー体験のトレードオフを伴う技術的判断である
詳細解説
Smokejumpersチームの成り立ちと役割
GoogleフェローであるEmanuel Taropa氏は、ポッドキャストの中でSmokejumpersチームの結成経緯を説明しています。2022年頃、大規模言語モデル(LLM)のサービング業務に特化した機動的なチームの必要性が明確になり、当時のSRE組織責任者Ben Treynor氏と相談の上、10〜16名規模のチームを立ち上げたとのことです。
チーム名の「Smokejumpers」は、山火事の炎より先に煙を抜けて降下し、火災に対処する消防士に由来します。Taropa氏によれば、実際の業務強度は当初の想定を上回る「プレッシャークッカー」のような環境であり、この名前が適切だったと振り返っています。
チームメンバーはSREラダー、エンジニアリングラダー、PMラダーなど異なるキャリアパスから集められており、LLMサービングの細部への理解と強いオーナーシップを持つ人材が選ばれました。モデルのトレーニングからサービング、依存システムまで、Geminiを「普遍的にアクセス可能で有用なもの」にするためのあらゆる業務を担当しています。
また、フロントエンド相当の組織として「Fire Starters」という名前のチームも存在し、クエリが発生する起点での対応を行っているとのことです。この2つのチーム間には強い連帯感(esprit de corps)があり、共同で問題解決にあたる文化が形成されていると言います。
Geminiスケーリングの技術的変遷
Taropa氏は、2022年10月から11月にかけて「この分野で明らかに何かが起きている」と認識し、迅速に行動を開始したと述べています。初期段階では、どのモデルをサービングするか、異なるタイプのモデル間でどうルーティングするか、キャパシティをどう配分するかといった基本的な問題から着手しました。
その後、信頼できるテスターへの展開、グローバル展開、Geminiプログラムの開始、社内の利用可能なキャパシティの発見、最初のMoE(Mixture of Experts)プログラムの開始と、段階的に規模を拡大していきました。現在では、非常に高速で安価にサービングできる大規模モデルと、頻繁に使用されるフロンティアモデルの両方を提供する体制が整っていると説明されています。
Googleが過去に構築してきた大規模システムのスケーリングに関する知見、システム内での努力の集中方法、継続的なコスト削減と高速化、スケーラビリティの実現といったノウハウが、Geminiのインフラストラクチャにも活かされているとのことです。また、Googleが持つ製品・サービスの配信網も、このプロジェクトを特別なものにしている要因として挙げられています。
モデルローンチにおける課題と学習
Gemini 3 Proを例に、Taropa氏はモデルローンチのプロセスについて語っています。モデルのトレーニングとサービングの担当者は分離されているわけではなく、事前トレーニングからモデル設計、サービングに至るまで、統合されたチームとして意思決定を行っていると強調しました。
トレーニングにどれだけ投資するか、サービングにどれだけ投資するか、コストはいくらか、どのようにサービングするか、潜在的な顧客、採用率、トラフィック成長など、すべてを考慮する必要があります。ただし、Taropa氏は「何度も間違える」と率直に認めています。当日でさえ、次に行うことのコストが予測と異なり、その差異がどこから来るのかについて驚きがあったと述べています。
トラフィックの変化、アプリケーションでの使われ方、クエリのボリュームと分布、モデルの品質向上に伴う使用パターンの変化など、すべてが動的に変化するため、完全に予測することは困難だと説明しています。それでも、事前トレーニング用のキャパシティ配分や、最終製品のイメージについて、ある程度の見通しを持とうと努力しているとのことです。
具体的な改善の例として、最初は良さそうに見えたものが2週間後には2倍速くなり、3週間後には4倍速くなるといったケースがあるそうです。これは、トレーニングからサービング、依存システムに至るまで、多くの人々の努力の結果であり、ショートコンテキストとロングコンテキスト間のトレードオフをより適切に行う方法の発見なども含まれます。
Gemini 2.5 Proから3 Proへの移行については、「多くの改善があったが、根本的には変わっていない」とTaropa氏は述べています。Gemini 3 Proは「ridiculously good model(馬鹿げたほど良いモデル)」であり、期待通りの使われ方と、驚くような使われ方の両方がされていると言います。この状況を「子供の成長を見るようなもの」と表現し、大量の利用を得られることが日々解決する価値のある楽しい問題だと語っています。
インフラストラクチャのトレードオフとグローバル最適化
新しいモデルのリリースは、トラフィックの新しいベースラインを設定します。Gemini 2.5 Proが大きな変曲点となり、新しいキャパシティの発見と最適化が行われましたが、これが新しいトラフィックの最低ラインとなり、その後のすべてがその上に積み重なっていきます。Gemini 3 Flashのような新モデルが登場しても、2.5シリーズのモデルは依然として大量に使用されているため、「チップはどこから来るのか」という問題が常に存在します。
Taropa氏によれば、いくつかの自由度があり、トレードオフを行うことができます。例えば、あるキャパシティをレイテンシと交換したり、製品全体を見渡して、より従来的な部分でのレイテンシとコストを削減する方法を見つけたりします。これには、システム全体がどのように機能するかについての多くの組織的記憶と知識が必要です。
異なる時点で、システム全体に異なる圧力がかかります。時には、いくつかのトリックで何とか切り抜け、後で修正することを祈ることもあります。また、新しいモデルファミリーが登場すると、それらが一部の圧力を吸収することもあると説明されています。
開発者コミュニティからは「古いモデルを削除しないでほしい」という声があります。Taropa氏はこれを「孫を見るようなもの」と表現し、ユーザーが気に入っていることを喜ばしく思う一方で、最適化されたサービングフットプリントとのバランスを取ることの難しさを認めています。
キャッシュヒット率の技術的課題
開発者からの一般的なフィードバックとして、「なぜGeminiのキャッシュヒット率が他のプロバイダーより低いのか」という質問があります。Taropa氏は、「競争力を持たなければならない」と明言し、ユーザーにとってコストが高い、遅い、品質が劣るものを使ってもらうのは不公平だと述べています。
技術的には、キャッシュをクラスターレベルまたはグローバルレベルで複製し、キーがどこにあるかを正確に把握することは可能であり、Googleの主要なシステムでは非常にうまく機能しています。SpannerやWeb検索などでは優れたキャッシュヒット率を達成していると言います。
しかし、LLMサービングでは構造が若干異なり、キャッシュの計算方法や、キャッシュしたい部分の計算方法が異なります。Googleは、既存の高性能なキャッシュシステムをLLMサービング用に適応させる作業を行っているとのことです。
もう一つの課題は、サーバー間でリクエストをどのようにルーティングするか、単一インスタンスとマシンプールレベルでリソースを最大限に活用し、キャッシュヒット率を最大化する方法です。Gemini Appでは、ツールの使用、ツールフロー、コンテキスト、ターンごとのコンテキスト変更方法が異なるため、使用パターンが異なります。
Taropa氏は、「製品が本質的に異なるため、使用法も同じではない」と説明しつつ、全体として優れたキャッシュヒット率を達成できれば、コストが削減され、高速化され、最終的にはすべての人にとって安価になると述べています。
GoogleのTPU戦略と垂直統合
第7世代TPUフリート「Ironwood」について、Taropa氏は、Amin Vahdat氏が率いるチッププログラムを「世界で最高のチッププログラムの一つ」「この惑星で唯一の完全垂直統合ショップ」と評価しています。
2008年の最初のFlashデバイスから関わってきた人々が、その後のハードウェアバージョンにも取り組み、多くがプログラムに留まり続けています。これらの人々は組織的記憶と、非常に迅速に動くための結合組織を持っており、今回のサービングで誰が関与しているか、何が必要か、ロードマップをどのように変更する必要があるか、どのような調整が必要かを正確に把握していると言います。
このレベルの洞察は、業界の他の誰も持っていないものだとTaropa氏は強調しました。そして、「これは我々がさらに改善していくためのものだ」と述べています。
完全垂直統合アプローチは、チップ設計からトレーニング、サービングまで一貫した最適化を可能にします。これにより、各層での個別最適化ではなく、システム全体としての最適化が実現できると考えられます。また、ハードウェアとソフトウェアの緊密な連携により、新しい要件に対して迅速にロードマップを調整できる柔軟性も、Googleの強みとして機能していると思います。
MKと協働文化
ポッドキャストでは、Google内の「MK」と呼ばれる協働スペースについても言及されています。数週間前にSundar Pichai氏と話した際、MKがGoogleのような大企業を実際には非常に小さく感じさせる方法について議論されました。
Taropa氏は、MKに命を吹き込む人物の一人として言及されており、意思決定を行い、協働する素晴らしい雰囲気があると評されています。また、ロンドンにも同様のコラボレーションゾーンがあり、「第7コラボレーションスペース」として知られる場所で、初めて「全員を集めてこの問題を解決しよう」という取り組みが行われたとのことです。
現在では定期的に、全員が一つの場所に集まって問題に集中するイベントが開催されており、これがプログラムのesprit de corps(団結心)に驚くほど貢献していると言います。多くの楽しみがあり、同僚以上の非常に良い友人関係が築かれ、これらの関係は20年間続いています。そして、それらの人々の多くが、現時点でもこのプログラムに参加しているとのことです。
Taropa氏は、ロンドン、ニューヨーク、そしてカリフォルニア(おそらくマウンテンビュー)にこのような高強度エリアがあり、非常に明確な運用ケイデンスを持っていると述べています。これらの物理的な協働スペースが、複雑な技術的問題を解決する上で重要な役割を果たしていると考えられます。
コンテキストウィンドウとWorkspace embeddings
「なぜ200万トークンのコンテキストウィンドウモデルがなくなったのか」という質問に対し、Taropa氏は、必ずしも200万トークンのコンテキストウィンドウである必要はないと答えています。Gmailのローンチを例に挙げ、「すべてのコンテキストを一か所に集めることができる」と説明し、実際にはそれは確実に200万トークン以上を見ていると述べています。
また、このタイプのことのための新しいハードウェアタイプも開発されていると言及しています。しかし、重要な判断として、「世界中の最大限の人々に圧倒的な差で最高のものをサービングするか、それともそのユーザー人口の10%にほとんどの場合区別がつかない可能性があるものをサービングするか」という選択があると指摘しました。
ある時点で、これらの決定を行わなければならず、Taropa氏は「ほとんどの人々にほとんどの価値を、できればすべてを提供したい」と述べています。Googleのマンデートは、非常に大規模なオーディエンスにアクセス可能にすることであり、限られたキャパシティの中で、すべてのモデルをすべての構成で提供することはできないというトレードオフがあると認めています。
Workspaceについては、従来のトークンベースの検索システからembeddingベースのシステムへの移行が重要だと述べています。これは、Googleが検索で行っていることと比較して新しいものではありませんが、Googleが持つすべてのインフラストラクチャで最高クラスのものを使用するという方針です。このようなシステムを持っているのに、それを使わないのはもったいないと言います。
Embeddingsには、大規模で無制限の入力に取り組み、そこから良い価値を引き出す異なる方法があるため、大きな可能性があると考えられています。すべてのプロパティにわたるすべてのコンテキストを使用して、必要なものに対して生成AIレスポンスを調整できることを想像すると、Workspaceを可能な限り成功させることが絶対に重要であり、embeddingsはこのパズルの重要なピースの一つだとTaropa氏は説明しています。
Gemini Flashのパフォーマンスと効率
1.5 Flash(80億パラメータ版)から3 Flashへの進化について、Taropa氏は「ビーストモデル」と表現しています。Flashは、その重量級をはるかに超えるパンチ力を持っているとの評価です。ただし、「特定のコンテキストでは少し強すぎるかもしれない」とも付け加えています。
Taropa氏は、「このレベルの品質、このレベルの効率を提供できることは驚くべきことだ」と述べています。誰でも比較できるように、お気に入りのベンチマークを見るか、Taropa氏が好むアプローチである「実際に触ってみる」ことを推奨しています。1.5の80億パラメータモデルと最近ローンチしたものを比較し、さらには前世代のフロンティアモデルと比較すれば、その違いが分かると言います。
「簡単だったか?」という質問に対しては「いいえ」と答え、「今日でもサービングするのは興味深いか?」には「はい」と答えています。「望んでいたほど安価か?」については「いいえ、しかしそれでも驚くべきモデルだ」と述べています。
このレベルの品質が比較的アクセス可能であることは、チームを非常に幸せにすることだとTaropa氏は語っています。また、ローンチが近づくたびに「ローンチできないのではないか」「チップがない」「実現できない」と感じるものの、これまでのところ毎回実現させてきたとホストのLogan Kilpatrick氏が付け加えています。
Flashモデルの提供は、技術的な困難さと、多くのユーザーに高品質なAIを民主化するというGoogleの使命との間のバランスを示していると考えられます。80億パラメータという比較的小さなモデルサイズで、フロンティアモデルに匹敵する性能を実現することは、サービングコストの削減とアクセシビリティの向上に直結する重要な成果だと言えます。
チームの人間的側面
ポッドキャストの終盤で、Taropa氏は自身の自転車事故について語っています。ロードバイクで坂を下っていて事故に遭い、かなり深刻なクラッシュだったものの、幸運にも比較的早く回復したとのことです。
印象的だったのは、チームメンバーの反応です。Taropa氏が2日目には機能的に回復し、3日目には在宅で仕事を開始(「医師がこれを見ないことを願う」とジョークを交えて)、2週間後にはオフィスに戻っていたにもかかわらず、チームメンバーは彼をオンコールローテーションから外し続けました。オンコールローテーションとは、特定の時間内にページが発生した場合、5分以内に対応する責任を持つスケジュールのことです。
Taropa氏が実際には24時間7日(実際には20時間7日、4〜5時間の睡眠を取っているため)働いていたにもかかわらず、チームは彼をローテーションに戻すことを拒否し続けました。ある時点で、それが気まずくなったとTaropa氏は振り返ります。彼が「十分に回復したと思うので、もし望むならローテーションに戻りたい。まだ資格があると思う」と言ってようやく、チームは彼をローテーションに戻しました。
Taropa氏は「それが友人がすることだ」と述べ、15年、20年一緒に働いてきた人々がいて、それが楽しく、そのような集団の一部であることを非常に個人的なレベルで幸せに感じていると語っています。
最後に、Taropa氏は「職業的満足度という点で間違いなくトップクラス、いや、職業的ですらなく、人間的な満足度だ。しかし、概して、この仕事から得られる最大の満足は、築いた友情だ」と締めくくっています。
このエピソードは、最先端のAI技術を支えるエンジニアリングチームが、単なる技術的な卓越性だけでなく、深い人間関係と相互サポートに基づいていることを示しています。高強度の環境で働く中で形成される信頼関係と友情が、実は技術的成功の基盤になっているのかもしれません。
まとめ
Googleが公開したポッドキャストを通じて、Geminiのインフラストラクチャを支えるSmokejumpersチームの活動と、そこから見えてくる大規模AIサービスの技術的・組織的課題が明らかになりました。完全垂直統合型のTPU戦略、グローバル最適化とユーザー体験のバランス、そして強い結束力を持つチーム文化が、Geminiを数十億人に提供する基盤となっていることが分かります。今後、さらに高度なモデルが登場する中で、このようなインフラストラクチャとチームの取り組みが、どのように進化していくのか注目されます。
