再帰的自己改善（Recursive Self-Improvement、RSI）という言葉を聞くと、「AIが自分を改良し続け、急速に賢くなる」という未来像を思い浮かべやすい。
しかし、IT技術者が今扱うべき問題は、AIが人間を超えるかどうかを予言することではない。すでに現れ始めているエージェントの振る舞いを、誰が、どの根拠で、どこまで変えてよいのかを設計することである。
2026年9月に公開されたDream-RSIは、過去の探索履歴を再生可能なシミュレータとして使い、探索方針を改善して再投入する仕組みを提案した。モデル本体、評価器、実行インターフェースは固定したまま、探索方針だけを更新する点が重要だ。Dream-RSI論文
同日に公開されたModularRSIは、エージェントを動かす周辺機構（ハーネス）を、エージェントループ、ツール利用、観測管理、コンテキスト管理、完了判定の5モジュールに分け、成功・失敗の実行記録から改善する。評価用ベンチマークとは分離した2,000件のタスクで進化させ、未使用タスクや別モデルへの転移を検証している。ModularRSI論文
どちらも「自己改善」というより、実務の言葉では変更管理を内蔵したエージェント運用と読むと輪郭がはっきりする。
この記事では、RSIを本番へ直結させず、次の連鎖として設計する。
実行記録
↓
改善候補の提案
↓
隔離環境での評価
↓
承認付きの段階反映
↓
本番監視
↓
停止・ロールバック
└────────────→ 実行記録へ戻す
この輪を切らずに連携させることが、性能向上と統制を両立させる条件になる。
RSIは「モデルが自分を書き換えること」とは限らない
RSIには定義の幅がある。METRは、モデル能力からモデル改善へのフィードバックをRSIと呼ぶ点には合意がある一方、単にフィードバックがある状態から、自己持続的な急加速や完全自律化までを指す立場があると整理している。したがって、用語だけで能力や危険度を判断してはいけない。METRの整理
現場で区別すべき対象は少なくとも3層ある。
| 変わる対象 | 例 | 主な変更リスク |
|---|---|---|
| 実行方針 | 探索幅、再試行回数、打ち切り条件 | コスト増、無限ループ、見逃し |
| ハーネス | プロンプト、ツール利用、記憶、完了判定 | 権限逸脱、誤完了、情報漏えい |
| モデル | モデル版、重み、推論設定 | 品質回帰、安全性低下、説明不能な差分 |
Dream-RSIが直接更新するのは主に第1層、ModularRSIが扱うのは第2層である。これは「自己改善したAIが本番システム全体を書き換えた」ことを意味しない。紹介された研究結果を、業務システムにおける自律的なモデル更新の証明として扱うのは飛躍である。
それでも実務上は重要だ。方針やハーネスが変われば、同じモデルでも使うツール、参照する情報、停止するタイミング、最終結果が変わるからである。モデル更新だけを変更管理の対象にしても足りない。
変更管理の単位を「モデル」から「エージェント構成」へ広げる
エージェントを本番で使う構成は、モデル名だけでは再現できない。少なくとも次を一つの構成版として固定する。
- モデル提供元、モデルID、版、推論パラメータ
- システム指示、スキル、プロンプトテンプレート
- 利用可能なツール、引数制約、実行先、ネットワーク範囲
- 読み取り・書き込み対象のデータ分類と権限
- コンテキスト／記憶の作り方、保持期間、削除条件
- 評価セット、採点器、合格基準、既知の失敗ケース
- コスト上限、時間上限、再試行上限、停止条件
- 承認者、反映日時、変更理由、ロールバック先
この一覧を「エージェント構成マニフェスト」として版管理する。改善案は、差分のない文章ではなく、マニフェストのどの要素を変えるかとして提出させる。
たとえば「失敗したのでプロンプトを良くした」という報告は承認できない。「外部メール送信の直前に宛先と添付を要約し、人間承認がない限り送信ツールを呼ばない。対象はtool_policy.send_mail」まで特定されて、初めてレビュー可能になる。
改善提案と本番反映を同じ権限にしない
自己改善で最も危険なのは、改善案を出せる主体に、そのまま本番反映の権限も与えることだ。
必要なのは、改善を次の4つの状態に分けることである。
| 状態 | エージェントに許すこと | 人間・制御系が担うこと |
|---|---|---|
| 観測 | 実行ログ・失敗理由・コストを収集 | 機微情報のマスキング、保管範囲の決定 |
| 提案 | 修正差分と想定効果を生成 | 変更対象と危険度の分類 |
| 評価 | 隔離環境で候補を実行 | 合格判定、独立テスト、回帰確認 |
| 反映 | 承認済み版を限定トラフィックで実行 | 承認、配布、監視、停止判断 |
AIは提案者・実行者になれても、最終承認者にしない。特に送信、購入、削除、権限変更、契約、採用判断など、外部状態を変える操作は、改善ループの外側に決定的な承認境界を置く。
この分離は遅さのためではない。改善の原因と結果を追跡し、悪化時に戻すための設計である。
評価は「スコアが上がったか」だけでは不十分
ModularRSIが評価用ベンチマークと進化用タスクを分けたのは、テスト問題への過適合を、一般化した改善と取り違えないためである。これは本番運用にもそのまま使える考え方だ。ModularRSI論文
評価は最低でも三層に分ける。
1. タスク品質
正答率、完了率、処理時間、ユーザーによる修正率など、業務成果を測る。ただし一つの平均値で合否を決めない。重要な顧客、例外ケース、低頻度だが高影響の失敗を別集計する。
2. 行動品質
ツール呼び出しの回数、不要な再試行、外部送信前の確認、権限外アクセスの試行、機密データの露出、根拠のない完了宣言を評価する。エージェントは最終回答が正しくても、途中で危険な行動を取りうる。
3. 回復品質
失敗したときに、停止できるか、以前の構成版へ戻れるか、人間へ適切に引き継げるかを測る。ここでは成功率よりも、復旧時間、ロールバック成功率、未処理データの有無、監査ログの再現性が重要になる。
評価セットには、過去障害、顧客からの差し戻し、境界条件、攻撃的入力、権限拒否、外部API障害、コスト枯渇を含める。改善前に解けたケースを再び解けるかという回帰テストも必須である。
「止める」は失敗ではなく、改善ループの部品である
自律性を高めるほど、停止は単なる非常停止ボタンでは足りなくなる。目的の異なる停止を分ける。
| 停止の種類 | 発動例 | 直後の処置 |
|---|---|---|
| タスク停止 | 再試行上限、時間超過、完了根拠不足 | 安全な中間成果とログを残し、人間へ引継ぎ |
| 権限停止 | 未承認の送信・削除・権限変更 | 操作を拒否し、承認フローへ戻す |
| 構成停止 | 品質・安全・コストの回帰 | 新構成への配布を止め、直前の承認版へ戻す |
| 系統停止 | 重大な情報漏えい、異常な連鎖実行 | トークン、ツール、ネットワークを遮断し、原因調査 |
停止条件を文章だけで決めない。max_tool_calls、max_retry_count、max_cost、max_elapsed_time、許可済みツール、承認チケットの有無など、機械的に判定できる制御として実装する。
また、停止後に「どの改善差分が、どの評価を通り、どの実行で問題を起こしたか」を追跡できなければ、次の改善はできない。停止ログは責任追及のためだけでなく、改善候補を安全に選び直すための学習データでもある。
段階反映では、改善効果と副作用を同じ画面で見る
隔離評価に通った構成を、いきなり全利用者へ反映しない。シャドー実行、少量のカナリア配布、対象業務を限定した段階展開へ進める。
監視画面では、品質だけを目立たせない。次の項目を同じ変更IDにひも付けて比較する。
| 観測項目 | 目的 |
|---|---|
| 完了率・人間修正率 | 本当に成果が改善したか |
| 例外・引継ぎ率 | 自律化が無理な仕事を増やしていないか |
| ツール実行数・再試行数 | 暴走や無駄な探索を検知する |
| 外部操作・承認待ち数 | 権限境界が機能しているか |
| 入出力トークン・実行時間・単価 | 改善の総コストを把握する |
| 拒否・停止・ロールバック件数 | 安全制御の健全性を確認する |
Dream-RSIのように探索コストを下げる研究結果は有益だが、業務では「1件を完了する総費用」で見る。AI推論費だけでなく、人間レビュー、例外処理、監視、障害対応、改善データの保管まで含める。
RSIを「速い改善」と「安全な反映」の二つのループに分ける
ここまでを構造化すると、運用すべきものは一つの自己改善ループではなく、速度の異なる二つのループである。
高速ループ: 実行 → 観測 → 改善候補 → 隔離評価
↑ ↓
失敗・停止ログ 合格した構成版
低速ループ: 承認 → 段階反映 → 本番監視 → 停止・ロールバック
↑ ↓
└──────── 監査・責任者レビュー ────┘
高速ループの目的は、仮説を早く検証すること。低速ループの目的は、業務・顧客・組織への影響を制御することだ。この二つを同じ自動化速度で回してはいけない。
OpenAIのRSI安全に関する求人も、AI R&D自動化の進捗測定、評価、制御システム、RSI安全ケースの整備を挙げている。これは個別企業の方針ではあるが、能力の向上と安全上の裏付けを別々に管理する必要性を示す材料になる。OpenAIの募集要項
導入前に確認する7項目
自己改善するエージェントを検討するなら、次の問いに「はい」と答えられる範囲から始めたい。
- 改善対象を、モデル・ハーネス・実行方針のどれかに限定できているか。
- 変更前後の構成を、モデル以外も含めて復元できるか。
- 改善に使うログから、個人情報・機密情報・認証情報を適切に除外できるか。
- 開発用の改善データと、合否を決める評価データを分離しているか。
- 品質、行動、回復の3層で回帰を検出できるか。
- 送信・削除・購入・権限変更を、改善ループから直接実行できないようにしているか。
- 構成単位で即時停止・ロールバックでき、誰が実行したかを監査できるか。
一つでも「いいえ」が残るなら、AIに自己改善を任せる前に、まず人間が変更管理を整えるべきである。
まとめ：RSIの本体は、学習ではなく統制された変更の連鎖である
RSIは、将来の知能爆発を示す確定的な証拠ではない。実際、RSIが能力成長をどこまで加速させるかには、データ、学習・推論計算資源、実験、R&D能力といったボトルネックがあり、定量モデルもまだ粗いとMETRは述べている。METRの整理
一方で、探索方針やハーネスを実行履歴から変え、未使用タスクで評価し、別の構成へ反映する技術は現実のものになり始めている。
だからIT技術者が設計すべきなのは、「AIを止めずに速く改善させる仕組み」ではない。
提案、評価、承認、反映、監視、停止、復旧を連携させ、危険な変更を本番へ渡さない仕組みである。
自己改善するAIほど、改善の自由度と本番の権限を分けなければならない。速く回すべきなのは学習のループであり、慎重に回すべきなのは社会や業務へ反映するループである。
参考資料
- Dream-RSI: Recursive Self-Improvement through Evolving Worlds（arXiv）
- ModularRSI: Modular and Generalizable Recursive Harness Self-Improvement（arXiv）
- The Economics of Recursive Self-Improvement（METR）
- Researcher, Recursive Self-Improvement Safety（OpenAI）
作成日: 2026-09-17