再帰的自己改善とは｜AIと人間の担当や制約を6工程の表で確認

再帰的自己改善では、AIがどの工程を担うのか

Anthropicは、コード作成や実験などのAIによる開発支援が広がることと、次世代モデルを完全に自律開発することを区別して説明しています。（2026年9月14日確認） Anthropicの再帰的自己改善の説明 AIの担当を読むときは、研究全体を一語で評価せず、どの作業を任せたかから確かめます。

開発支援・完全自律開発・持続的加速の意味を分ける

開発支援の拡大、後継モデルの完全自律開発、加速の持続は、別々に確かめる必要があります。再帰的自己改善には定義の幅があり、人間が関わるだけで対象外になるとは限りません。本記事は、改善を次の開発へ戻す広い意味の循環を入口にします。METRによる再帰的自己改善の定義と論点

今回確認したAnthropicの公開説明では、次世代の最先端モデルを完全に自律開発する段階にはまだ到達していないとしています。これは同社の説明で示された現在地であり、非公開の研究を含む世界全体の達成状況を確認したものではありません。（2026年9月14日確認） Anthropicが区別する開発支援と完全自律開発

6工程でAI・人間・残る制約を照合する

各行の研究名から原典へ戻れます。AIと人間の分担は各研究の条件であり、全システムや将来に共通する分担ではありません。

この表は、1つのAIが全工程を担った実証ではありません。研究を進めるAIと、訓練されるモデルが別の場合もあります。部分工程の短縮だけでは、開発全体がどれだけ速くなったかは決まりません。

発表を読んだら、まず該当する行を選び、その行のAIの担当と残る制約を一緒に確認します。改善が次の研究方針や実装へ戻ることで循環になりますが、反復するたびに成果が上がるとは限りません。

AIの「自己改善」は何を書き換えているのか

DGMは、基盤モデルの重みを固定したままエージェントのコードを改良する研究であり、2026年3月12日版の論文では基盤モデルの再訓練を実証していません。（2026年9月14日確認） DGM論文v3 AIエージェントとは、モデルを使ってツールの操作や複数の作業を進めるシステムです。モデルの重みとは、学習によって調整される内部の数値パラメータです。同じ「自己改善」という言葉でも、コード、訓練の工程、学習されるモデルを分けると、成果の範囲が見えてきます。

DGM：基盤モデルを固定したコードの改良

DGMは自分のコードを修正して評価し、コンパイルが通り、コードを編集する能力を保つ候補を保存します。現在の最高得点に届かない候補も、次の探索の出発点になります。（2026年9月14日確認） DGMの候補保存と探索の仕組み

DGMでは、候補の保存や探索元の選択を管理する外側の仕組みは変更対象に含まれません。コードの自己変更を、研究全体の設計を自由に書き換える能力まで広げて解釈しないでください。固定部分を含むDGMの研究条件

この区別を詳しく整理したい場合は、モデルと実行基盤（ハーネス）の違いが参考になります。DGMについては、論文が変更可能としている部分を基準に読む必要があります。

AlphaEvolveとAAR：訓練工程と実験用モデル

Google DeepMindのAlphaEvolveは、コードの候補を作り、評価結果を次の候補生成へ使うシステムです。研究者が初期コードや評価方法を用意し、Geminiを使って候補を探索します。モデル訓練に使う処理の効率化も報告されていますが、訓練を速くするコードと、訓練されるモデルは同じ対象ではありません。（2026年9月14日確認） AlphaEvolveの公式発表・AlphaEvolveの技術報告

AnthropicのAARでは、研究を進めるAIと実験で学習させるモデルが分かれています。制御役はClaude Opus 4.6で、弱い側のQwen1.5-0.5B-Chatからの情報を使い、強い側のQwen3-4B-Baseを学習させる研究を進めます。研究者が課題や初期の方向性を設定したうえで、AIが実験方針を選び、実験を実行する構成です。（2026年9月14日確認） Anthropicの自動研究者AARの報告

したがって、モデルを訓練する実験が自動化された場合も、「AIが自分自身の基盤モデルを改良した」とは限りません。何を動かすAIが、何を変更・訓練したのかを、モデル名だけでなく役割とともに確かめると判断できます。

「開発が速くなった」という数値をどう読むか

AlphaEvolveの2025年の技術報告は、対象カーネルの平均23％高速化とGemini全体の訓練時間1％短縮を別に示しており、部分工程と全体の改善は区別が必要です。（2026年9月14日確認） AlphaEvolveの高速化の技術報告 カーネルとは、計算機上で特定の計算を担う処理単位です。数値の大きさを比べる前に、何を測った値かを確認します。

部分工程の高速化と全体の短縮を分ける

比較相手は、対象の計算処理で使われていた専門家設計の既存手法です。報告された二つの値は、その処理とGeminiの訓練全体で測定範囲が異なります。現在の全モデルに共通する仕様や、研究全体の進歩率には置き換えられません。（2026年9月14日確認） AlphaEvolve技術報告の比較条件

コード量・自己評価・METRの時間指標

コード量と社員の自己評価は、開発活動を知る手掛かりですが、技術進歩の速度そのものではありません。Anthropicの説明にある開発活動の指標も、何を数え、誰がどの条件で評価したかと一緒に読む必要があります。コードが増えたという観測だけでは、有効な研究成果や修正に要した時間まで分かりません。（2026年9月14日確認） Anthropicが示す開発加速の指標と注意点

METRの時間指標は、一定の成功率に対応する課題の長さを、人間の所要時間で表します。人間なら長時間かかる課題を解けることと、AIがその時間ずっと自律的に稼働したことは別です。AIの実行時間や、あらゆる研究開発を任せられる時間として読むのは適切ではありません。（2026年9月14日確認） METRの時間指標の定義と対象

筆者の判断基準：「何倍速い」という発表では、対象工程、比較対象、測定方法をそろえて確認します。そこが分からなければ、開発全体の加速率への換算は保留します。自己評価は自己評価として残すことで、観測された成果を過大に読まずに済みます。

計算資源や実験時間は、加速を止めるのか

METRは、2026年7月の論考で計算資源や実験などの制約を検討し、それらが持続的な加速を防ぐと結論づける決定的な根拠はないと整理しています。（2026年9月14日確認） METRの再帰的自己改善に関する論考 制約が存在することと、加速がどの時点で止まるかを断定することは分けて考えます。

計算資源・供給網・実験待ちを切り分ける

研究の自動化が進んでも、計算設備や実験に必要な時間が同じ割合で減るとは限りません。コード候補を増やせても、実行する計算資源、設備を増やす供給網、結果を得るまでの実験待ちは別の制約です。METRは、こうした制約が加速へ与える影響を検討しています。（2026年9月14日確認） 計算資源と実験などの制約の検討

誤りを見つけ、成果を確かめる作業にも負荷がかかります。Google DeepMindの論考は、AIによる提案が増える一方で、その妥当性を確かめる検証が制約になる問題を扱っています。これは検証の重要性を論じるもので、あらゆる研究で検証時間が何倍不足するかを測った結果ではありません。（2026年9月14日確認） Google DeepMindの科学研究と検証の制約に関する論考

自動化だけで進歩が加速し続けるとは限らない

自動化できる工程が増えることと、進歩の速度が上がり続けることは同じではありません。確認した2026年7月13日版の経済分析も、研究の自動化と持続的な加速の条件を分けて検討しています。制約の存在だけを停止の証明にせず、自動化だけを加速の保証にもしない読み方が必要です。（2026年9月14日確認） 再帰的自己改善の経済分析・2026年7月13日版

筆者の判断基準：実験待ちが制約なら、候補を作る速度に加えて、結果が出るまでの時間を確認します。検証が制約なら、次の開発への反映前に評価が済んだ範囲を確認します。その情報がなければ、候補数の増加から研究全体の加速率は判断しません。制約の存在だけを、加速が必ず止まる根拠にも使いません。