Jeff Dean：AI で作るための「1% ルール」
Y Combinator の Startup School 2026 に、Jeff Dean が登壇した。MapReduce、BigTable、TensorFlow、TPU、Gemini —— どれも彼が背後にいる。現在は Google のチーフサイエンティスト。
57 分間で一番価値があったのは経歴ではなく、今夜そのまま使える判断の道具だった。持ち帰った七つを書いておく。
一、1% ルール：成功率 20% が一番危ない
司会は、すべての創業者が抱えている問いをぶつけた。汎用モデルがどんどん強くなるなかで、2〜3 人のチームはどこで勝てるのか。
Dean の答えはエンジニアらしく、測定できる基準だった。
まず測る。最強の汎用モデルを持ってきて、自分の領域の問題を投げ、どこまでできるかを見る。
そして直感に反する部分が来る。
「まったくできないなら、それはおそらく良い兆候です。少しはできるがうまくない、という状態はむしろ良くない兆候です —— その能力がすでにモデルの中に現れ始めているということですから。学習データが増えたり、規模が大きくなれば、たいてい良くなってしまう」
「だから探すべきは、モデルの成功率が 0% か 1% の場所であって、20% の場所ではありません」
20% という成功率は「あと少し詰めればできそう」という錯覚を与える。実際には次のモデルのリリースと競走していて、しかも大抵は負ける。
では 0% の機会はどこにあるのか。彼は二つの形を挙げた。
一つ目は、モデルが到達できないデータ。 例えがうまい。Google は「世界の情報を整理する」をやっていて、そこは埋まっている。しかし**「あなた個人の情報を整理する」は空いている** —— 汎用モデルにはそのデータが見えないからだ。
二つ目は、専用モデル。 同僚の AlphaFold を挙げた。汎用ではないが、タンパク質折りたたみという領域を極めて良く処理する。似た形として材料科学とチップ設計を挙げていた。
そのうえで誠実な注意も添えている。「汎用モデルはより広い範囲で確実に良くなっています。だから、自分がやっていることが耐久性のあるものなのか、それとも最前線のモデルが 6 か月・12 か月で追いついてしまうものなのかを、見極める必要があります」
二、エネルギーこそが新しい単位
ここが技術的に一番密度が高かった。
1 回の計算はおよそ 1 ピコジュール。ところが、アクセラレータの HBM からデータを運んできてプロセッサが計算できる状態にするには、その約 1000 倍かかる。
この 1000 倍の差が、どんなプロダクトが成立するか、そして AI のアルゴリズムがどう設計されるかを静かに決めている。
最も直接的な帰結がバッチ処理だ。この 1000 倍の差がなければ、そもそもバッチ処理は要らない。差があるからこそ、多くのサンプルやトークンをまとめて、そのデータ移動のコストを「1000 ÷ バッチサイズ」に薄める必要がある。そして本当に低レイテンシが要る場面では、バッチ処理は相性が悪い。
だから問いはこうなる。創業者が「モデルの問題」と呼んでいるもののうち、どれだけが実はエネルギーとデータ IO の問題なのか。
彼は有名なリストも更新した。『Latency Numbers Every Engineer Should Know』の 2026 年 AI 版として挙げたのは —— アクセラレータのメインメモリからオンチップメモリ、そして乗算ユニットまでの帯域幅、1 回の乗算に要するエネルギー、チップ間のインターコネクト帯域とその帯域で何枚繋げるか、そして 500 枚ではなく 1 万枚と通信するときに帯域がどう落ちるか。
彼自身が今考えているのは推論だ。方向は三つ。データ移動を最小化する。極端に低い精度を使う。そして精度の種類をたくさんサポートしない —— 必要な精度が分かっているなら、それだけをハードウェアに焼き込み、他は入れない。
三、TPU の出発点は、ナプキンの裏の計算だった
これは理論ではない。彼は実際にやり、結果が TPU になった。
2013 年、深層学習ベースの音声モデルが機能し始め、誤り率を半分にした。 彼の表現では「音声認識の 20 年分の進歩が、モデルをいじって少し規模を上げ、より良いデータを得た数か月で起きた」。
そこで彼は心配になった。音声が使いやすくなれば、people はもっと使うからだ。
計算してみた。Google のユーザー全員が 1 日 3 分ずつスマホに話しかけたら、サーバー群を丸ごと倍にしなければならない。 音声だけのために。
結論は、CPU のままでは無理、だった。
そして TPU が生まれる。低精度の密な線形代数だけをやるチップだ。Chrome も Word も動かせない。しかしそれこそが、現代の機械学習アルゴリズムのほぼすべての核心にあたる。
2 年後に出たチップは、当時の CPU / GPU よりエネルギー効率が 30〜80 倍高く、レイテンシは 20〜30 倍低かった。
ただ、私が手を止めたのはそのトレードオフの方だ。TPU は Transformer が現れる前に作られている。なぜ今も通用するのか。
「だからこそ、汎用の線形代数システムとして作ったのです。ML のアルゴリズムはまだ進化中だと分かっていたので、過度に専用化したくなかった —— しかし劇的な性能上の利得を得られる程度には専用化したかった」
「ちょうど良いところまで専用化し、それ以上はしない」 —— これが全編で最も価値のあるエンジニアリング哲学だと思う。
四、彼自身が書いた skill
context engineering の話で、真似すべき具体例が出てきた。
まず好きな対比。モデルはシステム全体の一部でしかない。 そして context に入れた情報には特別な性質がある ——「その情報はモデルにとって明確です。学習データとは違う。あれは何兆ものトークンがスープのようにかき混ぜられて、数千億から数兆のパラメータの中に入っている。モデルが直接見る context ほど明確ではありません」
強くなる道筋は素朴だ。モデルで実際の問題を解かせ、どこで失敗するかを見る。
「多くの場合、モデルをそのクラスの問題で改善できます —— パラメータを調整するのではなく（外からは難しい）、より良いガイドラインを書き、skill を書いて、ツールの使い方を教えることによって」
そして具体例。数週間前、彼と Sanjay は低レベルライブラリの性能改善をしていた。 Google 内部にはマイクロベンチマークのライブラリがあり、そのデータ構造は Google 全体で何百万ものプロセスで動くので、性能は本当に重要だ。
agent がない時代の手順は、現状のベンチマークを測る → コードを直す → 再測定 → 改善点を見る → より広いベンチマークを回す → キャッシュのフットプリントを測る、というもの。
彼らはこの一連をモデルに教える skill を書いた。 その結果、モデルは「測定 → 変更 → 再測定 → 反復」という自己改善ループを自分で回せるようになった。
一番覚えておくべきは、彼のこの位置づけだ：
「これは要するに、私たちが人間として使うアプローチを、モデルが使える形で与えただけです」
司会が「その skill は無限の価値がある」と冗談を言うと、彼の答えは実直だった。数か月前に Sanjay と 30 ページの文書『Performance Hints』を公開している。 それを要約してモデルに渡した人たちが、モデルのコード性能に関する推論能力が上がるのを確認しているという。すべて無料で公開されている。
能力は skill というファイルの中にあるのではない。書き下された「やり方」の中にある。
五、agent が長く走れない本当の理由
司会が聞いた。agent が 30 歩・40 歩目で脱線するのは、context の問題か、評価器の問題か、それとも開ループ系で誤差が累積するからか。
彼の診断はこうだ。モデルは一揃いの分布の上で訓練されていて、そこから少し外れた瞬間に性能が急に劣化し始める。 快適圏から遠いほど失敗しやすい。
対応は三つ。
第一に、skill とヒントを与えて、「モデルが確かにやり方を知っている、明るく照らされた道」の上に留める。
第二に、複数 agent に別々のアプローチを並行させ、別のモデルにどれが有望かを評価させる。 有望なものを残し、脱線したものを捨てる。彼はこれを解空間の探索と呼ぶ。
第三に、その探索に推論時の計算を使う。 長時間動く agent フローの性能と信頼性を大きく上げる、非常に汎用的で有用な手法だという。
Google 社内もまさにこれをやっている。harness に加えて skill 一式を用意し、agent が社内のコーディングツール、コードレビュー、性能測定、ログ取得を使えるようにしている。基盤モデルは Google 独自のログ取得など学習していないが、適切な skill 定義があれば動く。
ここで、多くの人がまだ内面化していないと彼が言うことがある：
「agent は 1〜2 時間だけでなく、問題領域と十分に強力なモデル次第では、数日から数週間動かして、非常に複雑なタスクをこなせます」
例として挙げたのは、ソフトウェア一式を別のプログラミング言語で書き直させること。より良い安全性や性能特性を得るために。
そしてここから直感に反する結論が出る。agent がコードを書けるようになった後、「何が欲しいかを明確にする」ことの重要性はむしろ上がった。
最良の証拠が言語の翻訳だ。なぜ今のモデルは Python から Go への変換が極めて得意なのか。仕様が異常に詳細だからだ —— ソフトウェア全体そのものが仕様になっている。 テストを Go に翻訳し、全部通し、挙動の差分がなくなるまで突き合わせられる。
「その仕様がとても明確だからです」
裏を返せば、あなたの agent がうまく動かないのは、多くの場合モデルのせいではなく、あなたの spec が spec になっていないからだ。
六、希少なのは taste —— そして練習法は三つある
「全員が数百の agent を同時に回せるようになり、コードは全部書いてもらえるとしたら、何が希少なスキルになるのか」
「agent に何をやらせるか、についての極めて良い品味（taste）です」
研究者の視点からの説明が刺さる。
「研究者はあらゆるツールと技術を持ち得ます。しかし戦いの大部分は、どの問題に時間を使うかです。問題選びが正しくてそれを解けたなら、退屈な問題に対する研究を見事に遂行するより、はるかに良い」
「そしてモデルはこれが得意とは限りません。だから人間が大量の AI 支援計算を操舵することになります」
練習法は三つ。
一つ目は経験。 多くの異なる問題をやってきたことが、将来どんな問題が面白そうかを教えてくれる。そして過去の手法を繋ぎ合わせればぎりぎり届きそうなものが見えるようになる。
二つ目が最も実行可能だ。今後 12 か月で重要になりそうなことを書き出し、そのうち一つを選んでやる。そして 12 か月後に残りを振り返る —— どれが実際に重要になったか、どれが世界の誰かに作られたか、どれが今も誰もやっていないか。
「これはあなた自身の品味形成に、はるかに多くのサンプルを与えてくれます」
これは玄妙な問題を、フィードバック信号のある訓練ループに変える。しかもコストはドキュメント一つ分だ。
三つ目は、突飛な思考実験。 その場で挙げた例が見事だった。
60 年間、チップ設計と製造業界の根本的な前提は「同じ設計で作られたチップは、他のすべてと完全に一致していなければならない、ビット反転は許されない」だった。
しかしマクロなスケールでは、我々はそう仮定していない。 信頼できない部品から信頼できる大規模分散システムを作っている —— データを 3 つのラックの 3 台に 3 部保存すれば、どれかが落ちてもデータは残る。Reed–Solomon 符号もある。
「しかしトランジスタのスケールでは、これを極限まではやっていないように見えます」
そこで思考実験。100 万年に 1 回ではなく、1 日に 20 回エラーを出すトランジスタでシステムを作ったらどうなるか。
「それはまったく違う設計点になります」
信号の送り方も変わる。複数の冗長経路に同時に流して、少なくとも一本は届くようにするかもしれない。
司会が「脳みたいですね」と応じると、彼はこう返した。「まさに。脳の中の信号は、ある場所から別の場所へ届くのに特別信頼できるわけではありません。だから本当に重要なものには複数の経路があるのです」
誠実な限界も添えている。「この種の思考実験はしばしば成立しません。過去 50 年そうしてきたことには、たいてい良い理由があるからです。しかし時々見直すのは良いことです」
ちなみに MapReduce もこうして生まれた。 手書きの並列化と checkpointing のコードが、本当に単純な意図を覆い隠していた —— 全ウェブページを走査して URL から言語へのマッピングを計算したいだけなのに。関数型言語の訓練を思い出し、信頼性の仕組みを下層ライブラリに沈め、上には map と reduce だけを残した。
七、私たちが変える三つ
一つ、「1% ルール」を企画の判断基準にする。 汎用モデルのこの件での成功率は 0% か 20% か。20% は次のモデルとの競走を意味する。 そして耐久性の問いに答える —— 最前線のモデルは 6〜12 か月で追いつくか。
二つ、「人のやり方」を skill に書く。結果をモデルに外注しない。 「人間として使うアプローチを、モデルが使える形で与える」という言葉は、私たちの Builder と Reviewer という役割の定義にほぼ一致する。agent がうまく動かないときは、モデルより先に自分の spec を疑う。
三つ、今日そのリストを作る。 今後 1 年で重要になりそうなことを書き出し、一つ選び、1 年後に採点する。taste を訓練可能にする方法として、私が見た中で最も低コストだ。
最後に、ずっと考えている二つの数字を置いておく。
一つは評価器の速度。 量子化学では、密度汎関数の
シミュレータが分子 1 つに一晩かかる。彼の同僚はシミュレータの入出力からニューラル近似を訓練し、30 万倍速く、しかもほぼ同じ精度を得た。 結果として ——「1000 万件をスクリーニングしたいとき、6 か月がかりの事業ではなく、昼食に行っている間に終わらせられる」。彼の最適化目標は、投入計算量あたりいくつの発見が得られるか。
もう一つはデータ効率。 今の大規模モデルが見たデータは、18 歳の人間のおよそ 1000 倍。しかしその 18 歳は多くのことで上回り、少なくない領域で最前線のモデルと同等だ。
この 1000 倍の差は、まだ誰も解いていない —— 彼のルールで言えば、成功率 0% の問題そのものだ。
なお、2014 年に彼が Hinton、Oriol Vinyals と書いた「蒸留」の論文は、「重大な影響を持つ可能性は低い」という理由で却下されている。
今日の Gemini の Flash モデルは、より大きな Pro モデルから蒸留されている。
彼自身の評価は驚くほど穏やかだ。「却下されることは時々あります、それで構いません。arXiv に置けば、読まれて、使われて、それで良いのです」
出典：Y Combinator『Jeff Dean: The 1% Rule for Building in AI』（YC Startup School 2026、2026-07-30 公開、約 57 分）。引用は対談内の発言の翻訳であり、見解は発言者本人のものです。