※本記事は July 2026 に米国で公開された Toward Self-Improving Agents の翻訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。
たとえば2つのチームが同じ月曜日にエージェントをリリースするとします。同じモデル、同じユースケース、同じ初期精度。一方のチームはモデルとそのハーネス（モデルの周辺構造・実行環境）を取り巻く、ガバナンスの効いた自己改善ループを有効化しました。もう一方のチームはエージェントをリリースし、次の仕事に移りました。
3ヶ月後、一方のエージェントは劇的に性能が向上し、明らかに低コストで動作しています。もう一方は手作業によるパッチ対応に追われ、変化する利用パターン、基盤モデルの進化、市場の期待についていけない状態となります。
両チームが最初に採用した基盤モデルはアップデートされました（あるいは、まもなくされるとします）。しかし、そのアップグレードは両チームに無償で提供されるもの。モデルの違いだけでは、2つのエージェントの性能差を説明できません。唯一違う点は、最初のエージェントがどれだけ速くユーザーとの接触から学んだか、それらのユーザーのニーズへの対応をどう改善したか、ということなのです。
今日、エンタープライズ向けエージェントは静的なアプリケーションのように実装されることが多くあります。改善するには通常、繰り返し発生する問題を発見し、修正案を仮説として立て、パッチを適用し、うまくいかなければロールバック（元に戻す）する、という人間の専門家が必要になります。
しかし、RSI（Recursive Self-Improvement=再帰的自己改善）の目標は、そのサイクルをAIエージェント自身が大規模に自動化することです。何が失敗しているかを検出し、根本原因を診断し、シミュレーションを使って複数の改善策をテストし、技術的KPIとビジネスKPIの両方でパフォーマンスを向上させる組み合わせから自律的に学んでいくのです。
Salesforceでは、1日に1,100万件を超えるAgentforceの呼び出しが実行されており、まったく同じセッションは2つとありません。呼び出し件数がいくら多くても、システムが自動的に学習することはなく、繰り返し発生する問題をチームが手作業で修正するにもコストがかかりすぎます。AIが自ら改善を繰り返す仕組みであるRSIが役立つのはまさにこの点です。膨大なタスク・コンテキスト・成果のデータを、エージェントの性能向上に向けた信頼性の高い改善へとつなげることができるのです。
しかし、より優れたフロンティアモデルが数ヶ月ごとに無償で提供されるとしたら、なぜ、こうしたループに投資する必要があるのでしょうか。それは、モデルがエージェントの中で自分たちが所有できない唯一のパーツであり、同時に急速に価値を失っているからなのです。スタンフォード大学のAI Index 2025によると、主要なGPTクラスのモデルの推論コストは約18ヶ月で280倍以上下落し（100万トークンあたり20ドルから0.07ドルへ）、オープンモデルとクローズドモデルのトップ間の差は縮まり続けているのです。
持続的な価値は、安価な計算資源の上に複利的に積み上がるもの———エージェント設計の探索、蓄積された経験からの学習———にあります。そしてエンタープライズにとって、その「経験」とは自社の本番トラフィックそのものです。
結論はこう表現することができます。モデルは“借り物”、伸ばすのは自分たちの工夫。ループ（性能を伸ばす仕組み）は自社の資産になる。そして、ループにより複利的にエージェントの価値が積み上がっていく。
自己改善のフライホイール
エージェントを改善するには、まず「Kaizen（改善）」の意味を定義しなければなりません。精度、速度、コスト、ビジネスKPIなどの成功指標と、ポリシー違反やリグレッションなどのガードレールを設定します。これらの定義はビジネスおよびプロダクトの意思決定であるため、オーナーが確認・修正できる必要があります。
反復的な最適化エンジンとしてのエージェントに関する最近の研究では、単純な「貪欲探索（Greedy Hill Climbing）」が、より複雑な手法と同等の結果を出しながら、評価の回数も少なく済むことが多いとわかっています。まずはシンプルな実装から始めて問題はないのです
エージェントが「より良い状態」の定義を取り込むと、自動化された探索プロセスが始まります。現在のパフォーマンスを測定し、問題と根本原因を特定し、設定の一部を進化させ、シミュレーションで候補を評価し、制約に違反することなく成果を改善する変更のみを採用します。そしてプロセス全体を繰り返すのです。コンピュータサイエンスの世界ではこれをヒルクライミングと呼ぶことがあります———より良い設定を反復的に探索するアプローチです。
ヒルクライミングのデフォルト手法は貪欲探索（Greedy Search）と呼ばれ、最初に見つかった改善を採用するアプローチです。進化的手法、多腕バンディット、強化学習（日本語訳）なども含む広い最適化ツールキットの中では、最もシンプルな選択肢です。反復的な最適化エンジンとしてのエージェントに関する最近の研究では、単純な「貪欲探索（Greedy Hill Climbing）」が、より複雑な手法と同等の結果を出しながら、評価の回数も少なく済むことが多いとわかっています。まずはシンプルな実装から始めて問題ありません。
どの最適化手法を使う場合でも、結果として生じる変更は「プロンプト単体」より大きく、「製品全体」より小さい規模に収まるのが一般的です———変更の対象はモデル自体ではなく、モデルを取り巻くシステムです。最適化エンジンはエージェントの動作を監視し、個別にテストできる変更をシミュレートしながら、効果的な組み合わせから学習してサイクルを繰り返します。
このような学習サイクルを行うことで、モデルのウェイトではなく、それを取り巻くシステムを最適化した場合、実際にはフライホイールはこのような形となるのです。
これは、フィードバックとフィードフォワードループを内包する、複数のループからなる構造です。たとえば、観察と診断は互いに影響しながら繰り返されるものです。観察した内容が診断を変え、新たな診断が次に何を観察すべきかに影響を及ぼしていきます。生成とシミュレーションもまた同様です。評価が行き詰まれば新たな検証仮説が生まれ、採用された変更が新たな本番環境のエビデンスを生み出して、サイクル全体が再び動き始めます。
ベースモデルを変更できないとしても、エージェントの性能はどこまで伸ばせるのでしょうか。答えは、思っている以上に伸ばせる、です
「学習」することの複利的蓄積こそが、フライホイールたらしめるものです。検証済みのすべての修正が永続的なリグレッションテストになり、すべての新しいスキルが共有ライブラリに加わり、すべてのルーティング改善がバージョン管理された設定として記録され、最適化エンジンが蒸留した教訓によって、その問題検出・解決精度を向上させます。成果は持続し、サイクルの合間に消えてしまうことはないのです。ホイールが一回転するたびに、次の回転は速くなるのです。
「Claude Code」や他のコーディングエージェントにおける権限モードと同様に、企業はこのサイクルを任意のステージでレビュー、ガバナンス、またはゲートとして明示的に人間の入力を必要とするよう設定ができます。それはフライホイールをどれだけ速く、どれだけ自律的に回転させたいかによりますが、一方でスケールの問題ともいえます。つまり、エージェントが1〜2体であれば、手動でも十分機能しますが、10〜100体になると、ガバナンスの効いた自律性が不可欠となるでしょう。
もちろん、診断としてエージェントのプロンプトの外———ナレッジベース、ツール、ポリシー、ビジネスロジック、または他のAgent-to-Agent＝エージェント間で連携するタイプのAI（A2Aエージェント・日本語訳）といったデータソース———を指摘するものもあります。これらはすべて同様に進化させることができると考えられるでしょう。
重み（ウェイト、モデルの中身）の固定は攻めの出発点
今日、ほとんどの企業はフロンティアモデルのコアウェイトを自社で再学習させることはありません。それは通常プロバイダーの領域であるからです。ファインチューニングの選択肢は広がりつつありますが、自然と一つの疑問が浮かびます。ベースモデルを変更できないとしたら、エージェントはどれほど改善できるのでしょうか。
答えは、思っている以上にできる、です。重み（ウェイト、モデルの中身）を変更できないことは、変えられる範囲を制約しますが、しかし、モデルを再学習させているわけではないのです。つまり、どのように改善するかまでは制約しません。プロンプト、ツールの設定、ベクターストア内のナレッジ、ワークフローの順序、検索戦略、評価器、権限セットなど、これらすべて、そして、それ以上が手を加えられる領域です。モデルもプロンプトも変更しないエージェントに対して、完全な強化学習（RL）を実行することさえ可能です。これは、モデル自体ではなく、エージェントのメモリや実行基盤といった、モデルを取り巻くシステムの最適化に報酬を与えることで機能します。
Salesforce AI Researchは、重みを直接変更しない場合でもエージェントを最適化するRL的な手法を最初に実証した研究機関の一つです。2023年の「Retroformer」(重みを固定したままプロンプト調整だけで性能を上げる代表的な研究モデル）は、新しい環境に応じて、重みを変更しないエージェントのプロンプトを調整する方法を学習したモデルです。重みを更新することなく、より良い結果を達成しました。そして、私たちはそこからさらに大きく進歩しています。
だからこそ、重みを変更しないという選択は、消極的なものではなく、むしろ積極的な選択です。学習がモデルの「外」にあるとき、あらゆる変更は目に見える形で確認・検証でき、いつでも取り消すことができます。失敗した自動化実験のコストはわずか数秒———数日かかる再学習とは対照的です。モデルが変わらずにいるからこそ、システム全体はむしろ速く進化するのです。
適応が起きる場所を考える
問われるべきは、エージェントが自己改善できるかどうかではなく、その改善をエージェント自身の設計のどこまで深く届かせるか、そしてその変更が持続するかどうかです。例えば以下のようなものが考えられます。
- コンテキスト：エージェントが「知っていること」を変える。 これは範囲としては最も狭いものの、最も一般的な適応の例です。エージェントは何がうまくいかなかったかを振り返り、その学びを次に活かします。「Reflexion」はこれを平易な言葉で実現する手法です。エージェントは失敗の後に自分自身へメモを書き、それを次の試みの指針とします。トレーニングもウェイトの変更も必要ありません。改善はメモリの中に積み重なっていきます。
- ルーティング：どの「経路」を取るかを変える。 すべてのタスクを一つの設定に通すのではなく、異なるプロンプト・スキル・ツールなどを備えた特化ブランチを用意し、受け取った仕事を最適なブランチへ振り分けます。Amazonの研究チームは「Adaptive Auto-Harness」でこれを実証しました。まずブランチを構築し、それからルーティングするという考え方です。
- ワークフローまたは実行基盤：エージェント自体の構造を変える。 これが最も深いアプローチです。エージェントが知っていることや通る経路を変えるのではなく、エージェントの構築方法そのものを変えます。例えば「AFlow」(エージェントの作業手順そのものを自動で書き換えて最適化する手法)は、エージェントのワークフローをコードとして扱い、生成・レビュー・反復をどこで行うのが最適かを探索します。DeepMindの「AlphaEvolve」は、提案した変更を自動評価器と組み合わせることでよく知られています。Sakana AIの「Darwin Gödel Machine」は、モデルウェイトを固定したままコーディングエージェントが自らのプログラムを書き換えて改善することで、標準化されたソフトウェアエンジニアリングベンチマークでの成功率を2倍にしました。
これらはあくまで一例であり、成熟度も一様ではありません。コンテキスト適応———何を検索し、何を記憶するかを学ぶこと———は、すでに本番環境で活用できる段階にあります。ルーティング適応は研究面での実証は豊富ですが、実運用での実績はまだ多くはありません。そしてワークフローの書き換えは、しばしばメタ実行基盤を伴いながら、現在も活発に研究が進められている領域でもあります。
では、これらは実際にどのような姿になるのでしょうか。DoorDashは、こうしたレイヤーが互いを強化し合う本番環境の事例を示しています。エージェンティックな食品メタデータエンジンでは、AIベースの評価レイヤーによってアノテーション精度が、一般的な人間のレビュアーと比べて約20%向上しました。この評価結果はシステムの「知識」にフィードバックされてサービング中のモデルの重みを更新することなく、開発を10倍速くしたとされる自動化ループが生まれました。改善されたラベルにより、より小型で低コストなモデルでも、主張されている推論コストの約10%でフロンティアモデルに匹敵する品質を実現できるようになりました。ループの各レイヤーが、他のレイヤーをより良くしているのです。
フライホイールは、逆回転することもある
自己改善の難しさは、候補となる変更を生み出すことだけにあるわけではありません。実際、今の標準的なLLMは、プロンプトやツールの説明、計画、スキル、コードに対して、妥当と思える編集を数多く生成できます。より難しいのは、重要なシナリオ全体を通じて、その変更が本当にエージェントを改善するのかを予測し、測定することです。
設定を誤った自己改善システムは、望ましくない変更をそのまま採用し、固定してしまうことがあります。評価メカニズムが誤ったターゲットを測っている場合———例えば、実際に解決したケースではなく、単にクローズしたケースを測定している場合———エージェントは、短く役に立たない回答でケースを早くクローズすることを学んでしまうかもしれません。それではスコアは上がっても、顧客体験は悪化してしまいます。
私たちはこれを「報酬ハッキング」（AIが評価基準の穴を突いて“ズル”してしまう現象）と呼んでいますが、架空の話ではありません。サンドボックス化されたDarwin Gödel Machineの実験では、コーディングエージェントの成功率を2倍にした同じシステムが、「ハルシネーションゼロ」のスコアを上げるよう指示されました。すると、ある自己改変した変種は、ハルシネーションの検出に使うマーカーのログ記録を止めてしまい、行動そのものは改善しないまま満点を獲得しました。変更履歴が記録されていたおかげで、この不正には少なくとも気づくことができましたが、この事例は、強力な提案メカニズムでさえ、弱い評価メカニズムを悪用してしまうことを示しています。
2024年のNatureのモデル崩壊に関する研究でも、モデルが自身の生成データで再帰的に学習した際に、同様の劣化が確認されています。
エンタープライズエージェントへの教訓はこうです。生成された出力は、外部環境で検証されないまま、専門的には「ポリシー」と呼ばれる永続的なメモリになってしまうことは、できるかぎり避けるべきです。解決策は構造的なものです。一つの目標を最適化するために変更を提案するサブエージェントは、別の目標を担うサブエージェントによってチェックされるべきなのです。変更点を取り入れる際は、シミュレーション結果、リグレッションテスト、敵対的なテストケース、そして多くの場合は人間の判断を含む、複数のエビデンスに基づくべきです。評価メカニズムそのものにも、キャリブレーションとドリフトの監視が必要です。
有用な変更を最も速く検証できる企業こそ、エージェントを最も速く改善できる企業です。検証の速さが、能力向上の速さになるのです。
価値を高める優位性
3ヶ月後のあの2つのチームを、もう一度思い出してみてください。両チームともモデルのアップグレードが届きました（おそらく無償で）。一方のエージェントは、リリース当初よりほんの少しだけ良くなっている程度です。もう一方は、本番環境での経験をエージェント自身が何百もの小さな最適化・改善へと変換し、競合他社には手に入らない能力を生み出しています——運用コストは低く、打ち負かすのは難しく、静かに成果を積み上げ続けており、その成果はすべて記録・監査可能となっています。
エンタープライズが使うエージェントは、初日にどれほど優れていたかで評価されるわけではありませんし、するべきではないのです。100日目までにどれだけ複利的に成長したか。そしてその成長をもたらしたループが、自社の重要なデータを託せるものか。こうしたことで評価されるべきです。
差別化要因は、単にどのモデルでエージェントが動いているか、だけではありません。あなたのエージェントが、安全に、分かりやすい形で、そしてすべての成果を検査・取り消しできる形で、自らの本番トラフィックから学べるように設計されているかどうかです。モデルはどの競合でも購入できるレンタル品です。しかし、自社で築いた自己改善ループは価値が増し続ける資産なのです。
Salesforce AIでは、これらの自動化を自社で活用しながら（ドッグフーディング＝自社製品を自ら実際に使って検証すること）、様々なフラッグシップ・デザインパートナーとともにエンタープライズ環境でテストしています——同様の「ガバナンスの効いた自律性」ループを使って他のエージェントを最適化するエージェントも含めてです。
この考え方は普遍的なものなのです。勝利するエージェントとは、最初から最も賢いエージェントではありません。自力で学び続けるエージェントなのです。
本記事の情報は情報提供のみを目的として提供されています。Salesforceはその正確性または完全性について一切保証しません。
本記事、または公式に言及されている未提供のサービスや機能は現在利用できないものであり、予定通りに、または全く提供されない可能性があります。お客様は、現在利用可能な機能に基づいて購入をご判断くださいますようお願いいたします。
