Thinking Machines の John Schulman画面越しの全分野で、
トップ専門家超えは3〜4年。短い予測と、解けていない4つの課題。

Dwarkesh Podcastの回は、“AI researchers debate how close we are to recursive self-improvement”。AI研究の前線にいる3人が、自己改善の加速が想定どおり進まないとしたら、どの技術が障害になるのかを議論した。[1]

肩書きは出演時の紹介に準拠。9/14確認のCharlie本人サイトは、Basetenの研究組織「Base Labs」を率いると記載している。[12]

番組は1時間37分で、タイムライン質問の章は1:28:32から。この時刻は質問群の開始であり、「3〜4年」という一言の正確な発言時刻ではない。[1][2]

出典：公式対談 [1] ／ Apple Podcasts配信情報 [2] ／ 9/12付Techmeme掲載 [3] ／ Charlie本人の現行プロフィール [12]

出典：公式書き起こし・末尾Rapid-fire timelines [1]。表の最終列は、発言条件を読み違えないための本号の整理。年数の幅は、統計的な信頼区間ではない。

再帰的自己改善（RSI）を、このページでは「AIがAI研究を進め、その成果で改善したAIが、次の研究をさらに進める循環」として扱う。AIが自分のプログラムを直接書き換える場合に限らず、学習方法、データ、評価、研究手順の改良も含めて考える。[10]

たとえば「テストを高速化せよ」という課題で、テストの一部を削除すれば実行時間は短くなる。しかし、品質を落としたなら目的は達成していない。手元の点数の改善と、本当に欲しい成果の改善が一致するかを確かめる必要がある。

出典：対談の主題 [1] ／ DarioによるRSIの説明 [10]。循環図、テスト削除の例、部分自動化との比較は本号の解説。

一度説明したルールを次の仕事にも生かしてほしい。この要望には、情報の保存、必要な情報の取り出し、判断の改善が混ざっている。Charlieは9月2日の本人記事で、文脈、外部記憶、学習された表現を分け、継続学習は一つの問題ではないと論じている。[4]

外部記憶を使うシステム全体が経験から改善する形も考えられる。「継続学習なら必ず重みを更新する」と決めつけず、何を学び、どれほど長く、どの仕事に生かせるかで評価する。

出典：Charlie「Trying to actually define continual learning」（9/2）[4] ／ 継続的な事実学習の研究（7/14改訂）[5] ／ 可塑性の研究 [11]。3段の整理と業務例は本号の解説。

この対談のsim-to-realを、ロボットの話だけと考えると狭すぎる。PC上の仕事でも、整った課題と実務では条件が違う。問題が難しいことと、問題が現実に近いことは同じではない。以下は、その違いを業務に当てはめた例だ。[1]

「現場向けに整える」とは、基準を甘くすることではない

Millidgeの「AI向けの環境整備で、多くの仕事は早めに可能になる」という予測を実務へつなげるなら、まず情報の矛盾や不要な操作負担を減らすことが考えられる。合格条件を下げたり、AIの失敗を人が見えないところで全部直したりすることとは違う。

出典：対談のsim-to-realとリモートワーカーの議論 [1]。比較、予約システムの例、整備項目は本号の提案であり、番組中の具体例や既存システムの実測ではない。

数年かかる仕事には、実行する力だけでなく、途中で失敗を認め、何をやめ、何を調べ直すかを判断する力が要る。目標そのものが誤っていたら、速く進むほど手戻りが大きくなる場合もある。

Charlieは9月10日の本人記事で、AIが問題を解けるようになった後も、限られた計算資源を何の問題に向けるかを決める仕事が重要になると予想している。これは将来の仕事観であり、職業別の需要予測を実証した研究ではない。[8]

コードが10倍速くても、工程全体は10倍にならない

単純化して、作業時間の半分だけを10倍にできたとする。元の100時間のうち、その50時間は5時間になるが、残りの50時間は変わらない。合計55時間なので、全体の速さは約1.82倍だ。

出典：長期判断・目的設定という対談の論点 [1] ／ Charlie「The final form of work」（9/10）[8]。工程比較、計算機、実務の評価点は本号の分析。

「長い仕事ができる」の、時間の意味を確認する

METRのタスク完了時間地平は、人間の専門家なら何時間かかる課題を、AIが一定の確率で完了できるかという指標だ。50%時間地平なら、その難しさの課題に半分の確率で成功するという推定になる。AIをその時間ずっと動かしたという意味ではない。[6]

9/14に確認したMETRの公開ページは更新日を2026/05/08と表示し、主にソフトウェア課題の評価方法を説明している。同ページには、現行課題群で16時間を超える測定は信頼性が低いとの注記もある。本号は、これを現在の全モデルの最高性能を示すランキングとしては使用しない。

出典：METRの時間地平の定義・注記 [6] ／ METR「Have We Seen an Acceleration in Discoveries?」（8/14）[7]。委任との比較と結論は、これらに基づく本号の分析。

短いタイムラインと、開発速度を調整する提案は矛盾しない。早く能力が伸びると考えるほど、その前に評価や管理を整える必要があると考えることもできる。ただし「減速論が話題」という曖昧な表現ではなく、具体的な発信と対象を確認したい。

この2つを分けると、「技術課題が残るから備えは不要」「数年で到来する予測だから今すぐ全面委任」という両極端を避けられる。期限の予測を信じ切らなくても、評価や権限を整える理由はある。

出典：Beren「Many Benefits Of AGI Could Still Be Realized In A Pause」（9/8）[9] ／ Dario「We Must Pace the Frontier」（9月表示）[10]。両者の提案は別物であり、完全に同じ政策を支持しているという整理ではない。

最初から「1か月、全部お任せ」を試す必要はない。境界が明確な仕事を1つ選び、人の介入も含めて記録する。たとえば、公開のサンプルアプリの不具合修正と回帰テスト追加なら、合成データと検証環境だけで試す設計ができる。

これは公開コード・合成データだけを使う検証タスクです。

【目的】
利用者にとって改善したいこと：［記入］
対象リポジトリ／コミット：［記入］
正とする仕様・決定事項と、その適用日：［記入］

【完了の条件】
期待する動作・受入条件：［記入］
回帰テストと検証コマンド：［記入］
変更してはいけない範囲：［記入］

【実行の境界】
使ってよいデータ・ツール・環境：［記入］
時間・費用・再試行回数の上限：［記入］
仕様の矛盾、不明な前提、範囲外の変更が必要な場合は停止して質問する。
本番反映、外部送信、権限変更、秘密情報・個人情報の利用は行わない。
既存テストの削除や、評価を通すためだけの期待値変更はしない。

【報告と引き継ぎ】
変更点、検証結果、未解決事項、人へ戻した判断を報告する。
次回へ残すのは、確認済みの事実・採用理由・適用範囲と日付。
推測は推測と明記し、失敗・再試行を含む記録を残す。

この章は、対談と参照研究を踏まえた本号の提案。出演者の発言の翻訳、特定製品の保証、実測済みの導入効果ではない。