DeepMind 体制再編を運用者目線で読む — Hassabis 会長就任と Jeff Dean 退任

Hassabis が会長へ退き、Jeff Dean が 27 年で去る

結論から書きます。2026 年 8 月 5 日、Google DeepMind の体制が大きく動きました。CEO だった Demis Hassabis が会長（Chair）と Alphabet の Chief Scientist へ移り、日々の経営からは一歩引きます。そして 27 年 Google に在籍した Jeff Dean が退任し、新会社を立ち上げます。

一報を見たとき、正直に言えば「また大きいラボが揺れたな」と身構えました。フロンティアラボ（最先端モデルを出す研究組織）のトップ人事は、私のようにその API を業務で使う側にとって、対岸の火事では済まないからです。使っているモデルの供給元が、経営レベルで揺れる。そのニュースを、株価の話ではなく運用の話として読み直します。

事実関係を先に整理します。Hassabis は CEO を降りますが、DeepMind を去るわけではありません。会長として戦略と AGI（汎用人工知能）方面に軸足を移し、創薬子会社 Isomorphic Labs により多くの時間を割く。ロンドン拠点のまま、Sundar Pichai と AGI 戦略で組むと報じられています。「AGI は手の届くところにある」という趣旨の本人コメントも出ています。

誰が何を引き継ぐのか — Kavukcuoglu と Discovery Loop

日々の指揮は Koray Kavukcuoglu が引き継ぎます。ここが運用者にとって一番大事な一点です。

Kavukcuoglu は DeepMind に 13 年以上いた人物で、CTO や Chief AI Architect を務めてきました。今回 Senior Vice President として、Gemini のモデル開発、フロンティア研究、Gemini アプリ、そして開発者向けプラットフォームまでを統括します。平たく言えば、私たちが叩く Gemini API の意思決定ラインの頂点が、研究畑からエンジニアリング畑寄りの人物へ替わった、という読み方ができます。

一方 Jeff Dean は、Discovery Loop という独立した公益企業（public benefit corporation、株主利益だけでなく公益を定款に持つ会社形態）を立ち上げます。Google は出資者かつクラウド提供者として残り、機械学習と科学研究の加速を掲げる。共同創業には Sanjay Ghemawat、DeepMind VP の Oriol Vinyals、Google Brain 共同創業者の Quoc Le といった名前が並びます。MapReduce や Bigtable を生んだ Dean と Ghemawat の名が揃うと、それだけで「本気の分社」に見えます。

余談ですが、この 2 人の名前を論文や社内インフラの逸話で何度も見てきた身としては、退任というより「もう一度ゼロから作りたくなったのだろう」という感想が先に来ました。27 年いた場所を離れる判断は、外から思うより重いはずです。

「顔」が変わってもモデルは今日も動く、が本質ではない

まず落ち着くべき点を書きます。この人事で、明日から Gemini API が止まるわけでも、料金が跳ねるわけでもありません。既存の SLA も課金も、当面はそのままです。

トップ人事とプロダクトの供給は、時間軸が違います。CEO が替わったその日にエンドポイントの挙動は変わらない。だから短期的には、慌ててコードを書き換える必要はありません。ここで過剰反応して、動いている本番を触るほうがよほど危ない。

けれど本質は別のところにあります。組織再編は、中期的な「意思決定の重心」が動いた合図です。研究主導だったモデル開発が、プラットフォームと収益の論理により強く引っ張られる可能性はある。実際、少し前に Gemini の最新モデルで temperature や top_p といったサンプリングパラメータが無視されるようになった件を運用者目線で読んだときにも感じたのですが、フロンティアラボは「使う側の既存の前提」を、思ったより軽く変えてきます。その変更の速さが、経営の重心と無関係だとは思えません。

単一プロバイダ依存を、この機会に点検する

私が今回いちばん強く思ったのは、これは自分の「単一プロバイダ依存」を点検する良い口実だ、ということです。特定の 1 社の 1 モデルに、業務の根幹を預けきっていないか。

以前、Claude の一部モデルが突然停止した日に単一プロバイダ依存を点検したときと、確認すべき項目は同じでした。人事ニュースそのものは直接のリスクではありませんが、こういうタイミングでしか棚卸しはしない、というのが正直なところです。

具体的に私が見直すのは、次の 3 点です。第一に、モデル呼び出しが 1 箇所の抽象レイヤーに集約されているか。プロンプトとパース処理が各所に散っていると、乗り換えたくなった日に地獄を見ます。第二に、代替モデルで最低限のリグレッションが通る評価セットを持っているか。第三に、価格改定や API 廃止の告知を受け取る導線（リリースノートの購読やアラート）が生きているか。この 3 つが揃っていれば、経営が揺れても慌てずに済みます。

私ならどう動くか

結論として、今回やることは「乗り換え」ではなく「点検」です。人事で供給が止まるわけではない以上、行動は静かなものになります。

私の順序はこうです。まず Google Cloud と DeepMind のリリースノート、非推奨（deprecation）告知の購読状態を確認する。次に、手元の評価セットを別プロバイダのモデルで一度走らせ、切り替えコストを数字で把握しておく。そして、それ以上は何もしない。ニュースに合わせて本番を触るのは、たいてい悪手です。

フロンティアラボのトップが替わるのは、ここ数年でもう珍しくもありません。だからこそ、その都度うろたえるのではなく、「依存の棚卸しを定期的にやるための外部トリガー」として使うのが、運用者としては一番割に合う付き合い方だと考えています。橋の設計者が交代しても、渡っている最中の私たちがすべきことは、足元の板を確かめることだけです。