AI が先に山頂に着く数学の時代 — 積み上げ理解と遅延学習のハイブリッドで追いかける

2026 年 9 月 8 日、OpenAI は社内モデルが 3 次元 Navier–Stokes 方程式に有限時間特異性を見つけたことを発表しました。Clay 数学研究所の Millennium Prize Problems の 1 つで、賞金 100 万ドル（約 1.5 億円）の問題です。報道によれば、1 万体規模の自律エージェントが並行で動き、約 88 時間（3 日半）で解に到達し、Lean による形式化と検証にさらに 17 時間を費やしています（Quanta Magazine、AIwire）。AIwire の見出しが「90 年間未解決」と書く問題を、モデルは 3 日半で片付けた格好です。

翌月の 2026 年 10 月 6 日には、OpenAI は内部モデルが生成した 372 ファミリー・722 本の論文草稿を GitHub リポジトリに一括公開しました。その中には、Riemann ゼータ関数を含むすべての Dirichlet L 関数が実部 7/8 より大きい領域に零点を持たないことを示す「quasi-Riemann hypothesis」の証明（Riemann 予想そのものではなく、零点のない領域を広げる部分的な結果）や、4 次元 Kakeya 集合の Hausdorff 次元予想の解決とされる成果が含まれています。すべてが Lean で形式化されているわけではなく、翌 10 月 7 日には 3 本が取り下げられ、その時点で主要結果のうち Lean で形式化済みなのは 719 本中 300 本（約 42%）とされています。

この一連の発表で引っかかったのは、結論そのものよりも到達の仕方でした。途中の思考過程は Lean で証明としては確認できるものの、人間が追体験しやすい説明にはなっていません。IEEE Spectrum の報道や WIRED の 9 月の記事は、独立に同種の爆発解を研究していた NYU の Tristan Buckmaster と Anthropic の Levent Alpöge の先行研究との扱いをめぐって、クレジットの議論が起きたことを伝えています。WIRED の 10 月の記事は、査読を経ずに GitHub やブログで成果を公開するスタイルへの反発に加え、OpenAI の Sébastien Bubeck が「自社の技術で大半の数学者のキャリアが早々に終わる」と考えているようだ、という関係者の証言も報じています。

どこでもドアで山頂に出てくる AI

こうした AI の出力を眺めていると、山を順に登る過程を人間に見せるのではなく、どこでもドアで山頂に出てきた、という体験に近い感覚があります。「速く登った」ではなく、「気付いたら頂上にいた」が近いです。

Terence Tao のブログに 2026 年 10 月に掲載された Jeremy Avigad のゲスト投稿「The Future of Mathematics」は、アラスカの奥地のバックパッキング旅行のアナロジーを使っています。トレイルヘッドまでの飛行機の予約を AI に任せても旅行の価値は失われないが、ハイキングそのものを AI に歩かれてしまうと旅行の目的が消える、という切り分けです。

Tao 自身は、“proof indigestion”（proof の消化不良）という概念を ICM 2026 の講演スライドで取り上げ、AI に関する発言のまとめページでも関連記事として挙げています。モデルが証明を書き、形式検証系で正しさを確認するところまでは自動化が進んでいるが、その証明を人間が「読んで、噛み砕いて、ほかの定理と繋げる」工程 (proof digestion) だけが置いていかれる、という指摘です。山頂に着いたことは証明できるが、どう登ったかを人間がまだ飲み込めていない状態、と言い換えてもよさそうです。

同じ構造は、コードや製品開発の文脈にも現れています。コーディングエージェントが数分で返した差分がテストを通過したとき、CI が緑でも、「どうしてこの実装でよいのか」を自分の中でまだ再構成できていない、という感覚が残ることがあります。差分をレビューして受け入れる工程と、差分を自分の理解に取り込む工程は別物で、CI が通ったからといって後者が済んだわけではありません。

以前書いた 3 層体制の記事では、参謀層・意思決定層・実行層を分けた話をしました。この構成は「意思決定層で Human が判断するための情報が揃うか」を軸に組んでいて、「山頂に先に着いた AI の答えを、Human がどう学び直すか」までは明示していませんでした。この記事はその続きで、Human が参謀と実行層から戻ってきた成果物をどう学ぶか、を 2 つのモードに分けて書き留めます。

積み上げ理解モード: 人間が登り方を再構成する

一つめは、人間が従来やってきた、着実に理解を積み上げるモードです。前提から順に読み、途中の分岐を自分で評価し、結論に至る道筋を自分の中で再構成します。

このモードが向くのは、次のような状況です。

判断ミスの影響が広い: 権限・課金・外部送信・プロダクトの価値判断。3 層体制の記事で Human に残していると書いた判断群がここに入ります
他者に説明する責任がある: 顧客・候補者・コミュニティ・経営判断など、第三者に対して理由を言語化する場面
対象領域にまだ自分の仮説が立っていない: 他の案件に転用するために「なぜこうなるのか」を内部に蓄積したい場面

このモードでは、AI の出力は「候補」として扱います。モデルが先に山頂に出てきていても、Human は参謀層の助言を聞きながら自分で登り直し、途中で立ち止まって分岐を評価する、という流れです。所要時間は AI 単独の数倍かかりますが、意思決定の精度と、別案件への転用可能性を取れます。

遅延学習モード: 山頂を先に受け取り、後から経路を学ぶ

もう一つは、AI の到達点を先に受け取り、後から経路を自分の中に落とし込むモードです。

このモードが向くのは、次のような状況です。

判断ミスの影響が局所的で巻き戻しやすい: 単発のリファクタ・スクリプト・ドラフトのような、戻しても他に波及しない差分
時間的な制約が強い: 定型作業で手数を増やしたい局面、または調査の初手を広く取りたい局面
自分の学習コストを後払いしても困らない: 判断より先に成果物を回したいが、理解はあとで追えば十分なもの

このモードでの Human の役割は、AI が返してきた成果物を、自分が後から思い出せる形に圧縮し直すことです。コードであれば、差分を読む過程で設計上の判断を SKILL.md 側に書き戻す、別の記事やノートに短くまとめる、といった操作です。数学で言えば、Tao が言う proof digestion に相当する工程を、Human が明示的に時間を取ってやるということです。

このモードを扱うときに気を付けているのは、「CI が通った」「レビューを通した」で学習フェーズを終わらせないことです。遅延学習のステップを飛ばすと、次に似た問題が来たときに、またゼロから AI に投げ直す羽目になります。

ハイブリッドで切り替える

実務では、この 2 つのモードを案件ごとに切り替えて使っています。切り替えの判断は、おおむね次の 3 つの問いで決めています。

flowchart TD
  Q1{"他者に説明する責任があるか"}
  Q2{"別案件で類似判断に使うか"}
  Q3{"1 回のレビューで巻き戻せる範囲か"}
  Q2b{"別案件で類似判断に使うか"}
  Build["積み上げ理解モード<br/>Human が登り直す"]
  Delayed["遅延学習モード<br/>先に反映して後で学ぶ"]
  Either["その日の時間配分と<br/>チームの手持ちタスクで決める"]
  Q3 -- No --> Build
  Q3 -- Yes --> Q1
  Q1 -- Yes --> Q2
  Q1 -- No --> Q2b
  Q2 -- Yes --> Build
  Q2 -- No --> Either
  Q2b -- Yes --> Either
  Q2b -- No --> Delayed

3 つめが No の場合、積み上げ理解モードを選びます。たとえば、権限設計・課金導線・プロダクトの価値判断に関わる差分は、たとえ参謀層と実行層が整った出力を返してきても、Human が自分で登り直してから採用します。

一方で、1 つめと 2 つめが No で、3 つめが Yes の場合、遅延学習モードで速度を取ります。依存ライブラリのバージョン上げ・ログ出力のフォーマット統一・スクリプト 1 本で済むデータ移行、こういった差分は、AI が出した成果物を先に反映し、後からコードを読んで理解を更新する、という順にしています。

3 つめが Yes でも、1 つめと 2 つめがどちらも Yes なら、説明責任と再利用の両方があるので積み上げ理解モードを選びます。

難しいのは、3 つめが Yes で、1 つめか 2 つめのどちらか一方だけが Yes の場合です。他者への説明や別案件での再利用が必要だが、1 回のレビューで巻き戻せる場合、積み上げ理解で時間を取るか、遅延学習で速度を取るかは、その日の時間配分やチームの手持ちタスクで決めています。デイリースタンドアップやチームミーティングで「どの差分を自分で登り直し、どの差分を遅延学習に回したか」を共有するようにしていて、個人の判断が偏ったら戻せるようにしています。

遅延学習を回すための小さな仕組み

遅延学習モードを選んだとき、学習工程を飛ばさないために置いている仕組みは、次のとおりです。

差分ごとに短いメモを残す: その差分で学んだこと・理解できなかったこと・追加で確認したいことを 3 行以内で残す
週次でメモを畳む: 似た内容のメモを束ねて、記事やノートに短くまとめる。この記事もそういうメモの一つから書き起こしています
繰り返し出てきた判断はスキル化する: 3 層体制の記事に書いた、Hermes Agent 用スキルへの固定ループ。スキル化すると、同じ判断を次回以降は AI に任せる判断に昇格できます

この仕組みの目的は、山頂に先に着いた AI の答えを、Human が後から「読み物」ではなく「操作可能な知識」に変換することです。proof digestion に相当する人間側の工程を、個別の意志でなく運用の中に組み込む、という置き方をしています。

まだ解いていない課題

ハイブリッドで回していても、残っている課題があります。

遅延学習の負債が溜まる: 遅延学習モードで積み残したメモが、週次の畳み込みに追いつかない場面がある。差分の生成速度が、人間の学習速度を上回っているため
「どちらのモードで扱うか」の判断自体を間違える: 速度を取るつもりだった差分が、後になって他者に説明が必要になり、積み上げ直す局面がある
参謀層と実行層の分業と、遅延学習の相性: 参謀層が計画を Human に渡した時点で遅延学習に回してしまうと、計画の前提まで学び損ねる

これらは、デイリースタンドアップやチームミーティングで振り返りながら、1 つずつ運用を直しています。今のところ共通している直し方は、「学習工程を飛ばして進めた結果、同じ領域で 2 回目の問い合わせが発生した」が起きたとき、その領域はしばらく積み上げ理解モード側に戻す、という手直しです。

数学の世界で Tao が言う proof indigestion は、形式検証が通った proof を人間がまだ飲み込めていないという話でした。コードと製品開発の現場でも、CI が通った差分を Human がまだ飲み込めていない、という同じ形の問題が起きています。山頂に先に着いた AI の出力に対して、人間側の学習工程を省略しないよう、積み上げ理解と遅延学習のモードを切り替えながら追いかけていく、というのが今の運用の形です。

以上、OpenAI の Navier–Stokes 発表と 722 本の論文公開、そして Tao の proof indigestion を手がかりに、人間が山を登る過程を見せない AI の出力に対して、積み上げ理解と遅延学習をハイブリッドで運用する考え方を書き留めた、現場からお送りしました。

サイト内検索