LLMが自分のトレーニングデータを生成して自分を賢くする——そのループは、思っていたより地味な壁で詰まっている。
「再帰的自己改善」の構造を図で整理する
MIT Technology Reviewが今週報じたように、RSI（Recursive Self-Improvement）の仕組みは部分的には動いている。LLMがコードを書き、合成データを生成し、それで次世代モデルを訓練するループは現実のMLOpsパイプラインの中で走っている。問題は Verifier（評価関数） にある。
flowchart LR
A["既存LLM
（ベースモデル）"] -->|コード生成・合成データ作成| B["合成訓練データ"]
B -->|ファインチューニング| C["改良候補モデル"]
C -->|評価・検証| D{"Verifier
（評価関数）"}
D -->|合格| E["新LLMとして採用"]
D -->|不合格| F["破棄・再生成"]
E -->|次ループへ| A
style D fill:#e67e22,color:#fff
style F fill:#e67e22,color:#fff
style E fill:#2980b9,color:#fff
style A fill:#7f8c8d,color:#fff
エンジニアのワークフローで今日から変わること
合成データ生成→フィルタリング→継続的なファインチューニング、というパイプラインは今日から組める。自社プロダクトに特化した合成Q&Aデータを生成してfine-tuneする手順は、そのまま使える技術だ。ただし「何が改善されたか」の評価設計を先に固めなければ、このパイプラインは動かない——そこが今のRSIの実態でもある。
「改善できない」のではなく「改善を定義できない」が壁
RSIの本当のボトルネックは3層ある。①Verifier問題——「改善した」と判断する評価関数自体を人間が設計・検証する必要がある。コンテキストが曖昧なタスクは人間依存が続く。②モデル崩壊——自モデルが生成したデータで再訓練を繰り返すと、出力の多様性が徐々に失われる。③ベンチマーク過適合——スコアが上がる＝実用で使いやすい、にはならない。ICLR 2026のRSIワークショップでも、自由回答形式のオープンエンドタスクはまだAIには無理、という合意があった。
あなたのfine-tuneパイプライン、「改善」をどう定義している？
合成データで自分のユースケース向けにfine-tuneするとしたら、「改善したかどうか」をどう評価する設計にするか——その問いは、評価関数の設計こそがエンジニアが今一番手を動かせる場所だということを示している。
参考: AI’s recursive self-improvement might not come so quickly after all — MIT Technology Review