MapReduceの論文を初めて読んだとき、あるいはBigtableの設計を追ったとき、著者欄に同じ名前が繰り返し現れることに気づいた人は多いはずです。Jeff Dean——Googleのインフラを支えるシステムを次々と共著した人物で、ミームになるほど社内で伝説化したエンジニアでもある。
「すごい人らしい」という印象は持っていても、彼がいつ何を作り、どんな問題意識でそれを作ったのかを時系列で語れる人は意外と少ない。MapReduceからSpanner、TensorFlowからGeminiまで——一本の線として追ってみると、繰り返されるある種の設計判断のパターンが見えてきます。
ハワイ生まれの最適化マニアが1999年にGoogleに入った
ジェフ・ディーンは1968年、ハワイ生まれです。ミネソタ大学でコンピュータサイエンスの学士を取得し、ワシントン大学の博士課程へ進みます。指導教員はCraig Chambers。博士論文のタイトルは「Whole-program optimization of object-oriented languages（オブジェクト指向言語の全プログラム最適化）」——このタイトルだけで、彼のキャリアを貫くテーマが「最適化」であることが分かります。
博士号取得後、最初の職場はDEC（Digital Equipment Corporation）でした。コンパイラとプロファイリングツールの開発に携わります。次に移ったのが意外な場所で、WHO（世界保健機関）です。疫学データを解析するソフトウェアを開発していたという経歴は、純粋なシステムソフトウェアエンジニアとは少し異なる幅を感じさせます。
そして1999年、Googleに入社します。入社当時のGoogleは、まだ検索エンジンとしての地盤を固めている最中でした。ジェフが最初に取り組んだのは、検索・クロール・インデックスシステムの再構築です。Google Cloud Next 2026のプロフィールには「co-designed/implemented many generations of Google's crawling, indexing, and query serving systems」と明記されており、初期Googleのインフラを文字通り作り直した人物の一人であることが分かります。
この時期に始まったのが、Sanjay Ghemawat とのコンビです。Sanjayはジェフと並んでGoogleで最初期から活躍したエンジニアで、2人の協働は後のMapReduce、Bigtableといった主要システムにも続いていきます。「最適化」という問いを軸に、コンパイラからWebサーバーまで何でも書く——この姿勢が、以後のキャリアを理解する上での基点になります。
「道具が足りなければ、道具の層を一つ下げて作る」：MapReduceからSpannerまで
Googleが急成長するにつれて、既存のソフトウェアスタックは次々と限界を迎えました。ジェフとSanjayが繰り返し選んだ答えは、「既存の道具を使い回す」ではなく「必要な道具の層を一段下げて作り直す」でした。
その最初の大きな成果が MapReduce（2004年、OSDI発表）です。当時Googleは、Webのクロールデータを大規模に処理する必要がありましたが、数百台・数千台のマシンに処理を分散させる抽象化が存在しませんでした。MapReduceが解いた問題は「大規模バッチ処理の並列化を、分散システムの複雑さを意識せずに記述できる抽象を提供すること」です。エンジニアはMapとReduceの関数を書くだけでよく、フォールトトレランスや再実行の仕組みはフレームワーク側が吸収しました。
続く Bigtable（2006年、OSDI発表）は、ペタバイト規模の構造化データをどう格納するかという問いへの答えです。リレーショナルDBはGoogleのデータ量とアクセスパターンに合わなかった。Bigtableはスパースな巨大テーブルを低レイテンシで扱える設計で、後のNoSQLムーブメントに直接影響を与えました。Faces of Open Sourceにも「BigtableはNoSQLデータベースソフトウェアムーブメントに広く影響を与えた」と記されています。
そして Spanner（2012年、OSDI発表）。MapReduceとBigtableで「大規模処理」と「大規模格納」は解けましたが、「グローバルに分散したデータベースでトランザクションの一貫性を保つ」という問題は残っていました。Spannerはそれを解くために、原子時計とGPSを使った時刻同期（TrueTime API）という、ハードウェアレベルまで踏み込んだアプローチで実現しています。
3つのシステムが解いた問題を整理すると、こうなります。
- MapReduce: 大規模バッチ処理の並列化を、分散システムの複雑さを隠蔽した抽象として提供した
- Bigtable: ペタバイト級の構造化データを低レイテンシで格納・参照できるシステムを実現した
- Spanner: グローバル分散環境でのトランザクション一貫性を、ハードウェアレベルの時刻同期で達成した
この3論文はいずれもOSDI Test of Time Awardを受賞しています（MapReduce: 2015年、Bigtable: 2016年、Spanner: 2022年）。MapReduceはHadoopの直接の先祖であり、BigtableはNoSQLムーブメントの起点として広く認識されています。
Sanjayとの協働について、もう少し掘り下げておきます。James ManyikaのLinkedIn投稿には、ジェフのコードレビューについて「line by line、常に明確さを求めるが、トーンは決して否定的でない」という記述があります。品質への執着と他者への敬意を両立させるスタイルが、Sanjayとのコラボレーションにも表れていたのだと思います。
ジェフ・ディーン・ファクト：ミームになった男の実像
ある時期から、Googleの社内にジェフ・ディーンを主役にしたジョーク集が広まり始めました。Chuck Norrisジョークのパロディとして生まれたもので、Kenton Varda がWebアプリとして整備し、その後外部にも広まったことがHacker Newsのスレッドで本人によって証言されています。後にそのアプリはAri Wilsonに引き継がれ、Googleの誰もがジョークを投稿・評価できる社内ツールに育ったそうです。
代表的なファクトをいくつか見てみましょう。
gcc -O1: コンパイラは、コードのサイズと実行時間を削減するよう試みます。
gcc -O2: さらに最適化を行います。
gcc -O3: さらに一層、最適化を行います。
gcc -O4: 完全に書き直してもらうために、あなたのコードをJeff Deanに送信します。
gcc の最適化フラグは実際には -O3 までしか存在しないのですが、「-O4 はジェフ・ディーンにコードを送信して書き直してもらう」というジョークになっています。実際のところ、彼の博士論文のテーマはまさに「オブジェクト指向言語の全プログラム最適化」——コンパイラ最適化の研究者が本職だった人間へのジョークとして、これ以上ない精度です。
別のファクトに「コンパイラがエラーを出したら、それはコンパイラのバグだ」というものがあります。DECでコンパイラを実際に書いていた人間に向けると、笑いの解像度が一段上がります。さらに「バイナリを書いてから、他の人が読めるようにソースコードを書く」というファクトもあり、機械語レベルの最適化を実際に行うエンジニアとしての実像と重なります。
これらのジョークが面白いのは、完全な作り話ではなく、彼の実際の仕事ぶりの誇張として機能しているからです。社内でここまでのミームが生まれるということは、「伝説的な仕事を実際に目撃した人間が大勢いた」ということでもあります。
James ManyikaのLinkedIn投稿には、ジェフのコードレビューについてこう書かれています。「若いエンジニアたちは、あれほどのキャリアを持つ人物が自分たちの仕事をそれほど真剣に扱ってくれることに驚いた。それが彼らに、より難しい問題に挑む自信を与えた」。ミームが生まれるほどの伝説的地位は、コードの速さだけではなく、こういう姿勢の積み重ねにも由来しているのだと思います。
Google Brainの立ち上げから、Geminiまで
インフラの時代が一段落した2011年頃、ジェフは次の大きな問いに向かいます。Google Brain の立ち上げです。Andrew Ngとともに、大規模なニューラルネットワークをGoogleのインフラ上で動かす実験を始めました。YouTubeの動画フレームから「猫」を認識したニューラルネットの実験は、当時の機械学習コミュニティに大きな衝撃を与えました——ラベルなしデータから猫の概念を学習できることを示したからです。
2015年、Google BrainチームはTensorFlowをオープンソースとして公開します。Faces of Open Sourceにはジェフが「co-created TensorFlow」として紹介されており、この公開がAI開発を研究機関だけのものから実務エンジニアにも開いた転換点として位置づけられています。
TensorFlow以前、大規模なニューラルネットを動かすには独自の分散学習基盤を自前で構築する必要がありました。モデルの定義・勾配計算・分散実行をすべてスクラッチで組むか、研究室ごとに閉じたツールチェーンを使うかという状況です。TensorFlowのオープンソース化は、その基盤を外部に開放したという意味で、MapReduceが並列処理の抽象を提供したことと構造的に似ています。「道具の層を作って公開する」という判断が、ここでも繰り返されています。
その後のジェフの関与を整理すると、こうなります。
- Google Brain: 2011年頃に共同創設。大規模ニューラルネットの研究・実用化を主導
- TensorFlow: 2015年にオープンソース化。AI開発のインフラを外部に開放
- TPU・Pathways: TPU開発への関与と、Pathways（非同期分散データフロー、MLSys 2022 Outstanding Paper Award受賞）による次世代AIインフラの設計
- Gemini: Google DeepMindのChief Scientistとして、Gemini 1.5を含む次世代マルチモーダルモデルの開発を統括
2023年、DeepMindとGoogle Brainが統合されたタイミングで、ジェフはGoogleの Chief Scientist に就任しています（allamericanspeakers.comおよびGoogle Cloud Next 2026プロフィールに記載）。インフラエンジニアとして始まり、AIインフラの設計者として現在に至る——という軌跡は、「最適化とスケール」という一貫した問いが形を変え続けてきた歴史でもあります。
彼が繰り返し選んだ問いの立て方
MapReduceからBigtable、SpannerからTensorFlow、TPUからGeminiまで——振り返ってみると、ジェフが繰り返し選んできた問いの立て方には一つのパターンがあります。「今の道具では解けない問題に直面したとき、道具の層を一段下げて作り直す」という判断です。
既存のDBでは足りなければBigtableを作り、バッチ処理の抽象がなければMapReduceを作り、グローバル分散でのトランザクションが必要になればSpannerを作る。AIの学習基盤が足りなければTensorFlowを作り、ハードウェアが足りなければTPUを設計する。この反復は偶然ではなく、「問題が大きくなったとき、既存の抽象の上で頑張るのではなく、抽象そのものを作り直す」という設計判断の哲学です。
「スケールの問題は早めに直視する」 という姿勢は、彼が共著した論文 The Tail at Scale（Communications of the ACM, 2013年2月）にも表れています。この論文は大規模分散システムにおける「テールレイテンシ」——99パーセンタイルや99.9パーセンタイルの遅延が全体のパフォーマンスに与える影響を分析したもので、2025年にOSDI Test of Time Awardを受賞しています。「平均レイテンシが良くても、テールが太ければシステムは遅く感じられる」という問題意識は、スケールを扱うエンジニアなら一度は直面する話です。
「今使っている抽象が、本当に目の前の問題に合っているか」——ジェフ・ディーンが繰り返し立ち返ってきたのは、この問いです。スケールの大小は違っても、抽象の選択を問い直す習慣は、どんな規模の仕事にも持ち込める視点だと思います。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。「自分たちの仕事に合った道具を選ぶ・作る」という問いに向き合いたい方は、お気軽にお問い合わせください。