今回の論文
今回取り上げるのは、Stanford University などの Mert Yuksekgonul、Federico Bianchi、Joseph Boen、Sheng Liu、Pan Lu、Zhi Huang、Carlos Guestrin、James Zou による 2025 年の論文「Optimizing generative AI by backpropagating language model feedback」です。公開元は Nature で、研究分野は複合AIシステムの最適化、プロンプト最適化、エージェント的ワークフロー改善です。URL は https://doi.org/10.1038/s41586-025-08661-4 です。元の arXiv 版は「TextGrad: Automatic “Differentiation” via Text」というタイトルで公開されています。
この論文を選んだ理由は、単一モデルの性能比較ではなく、LLM を組み合わせたシステム全体をどう改善するかという実務的な課題に踏み込んでいるからです。RAG、エージェント、コード生成、業務自動化のどれでも、いま多くの開発者が困っているのは「部品をつないだ後の調整」です。TextGrad はそこに対して、自然言語による批評を勾配のように流すという、かなり実装に落とし込みやすい考え方を提示しています。
どんな技術か
TextGrad は、LLM が返す自然言語のフィードバックを「テキスト版の勾配」とみなし、AI システムの各部品を少しずつ改善していくフレームワークです。ニューラルネットワークでは損失関数から勾配を逆伝播させますが、複数の LLM 呼び出し、ツール利用、シミュレータ、コード実行などを含む複合システムでは、普通の微分はできません。そこで TextGrad は、数値勾配の代わりに「どこをどう直すべきか」という批評文を逆向きに伝播させます。
重要なのは、最適化対象が重みではないことです。TextGrad が更新するのは、プロンプト、回答文、コード、分子表現、治療計画のような、人間が読める離散的なオブジェクトです。つまりこれはモデル学習というより、LLM を使ったアプリケーションやエージェントを、実行しながら改善するための最適化レイヤーだと捉えるとわかりやすいです。
課題
この技術が解決しようとしているのは、複合AIシステムの改善が人手の試行錯誤に強く依存していることです。最近のAIアプリは、単に1回LLMを呼ぶだけではなく、検索、要約、自己評価、ツール呼び出し、コード実行、再試行などを組み合わせる構成が増えています。しかし、この手のシステムはニューラルネットワークのように end-to-end で微分できません。
難しいのは、性能が悪かったときに「どの部品をどう変えるべきか」が見えにくいことです。たとえば回答が間違っていた場合、原因は初期プロンプトかもしれませんし、中間要約の質かもしれませんし、ツール呼び出しの条件かもしれません。既存の方法では、プロンプトエンジニアリング、ルールベースの自己修正、探索的な最適化、あるいは人間によるレビューに頼る場面が多く、改善サイクルが属人的になりやすいです。
なぜこの課題を解く必要があるかというと、実際の AI システムでは「モデル自体の能力」より「部品のつなぎ方」がボトルネックになることが多いからです。社内ナレッジ検索、開発支援エージェント、問い合わせ自動化、コード生成、分析レポート作成などでは、良いモデルを使ってもワークフロー設計が甘いと安定しません。TextGrad は、そのワークフロー自体を最適化対象にする点に価値があります。
用語解説
- 計算グラフ
- 入力から出力までの処理のつながりをグラフとして表したものです。TextGradでは、各LLM呼び出しやツール実行をノード間の変換として捉え、どの変数にどんな批評を返すかを整理する土台になります。
- テキスト勾配
- 数値ベクトルの勾配ではなく、「この変数をどう直せばよいか」を自然言語で表した改善指示です。TextGradの中核概念で、通常の逆伝播の代わりに批評文を後段から前段へ流します。
- ブラックボックス最適化
- 内部の重みや微分可能性にアクセスできない対象を、入出力だけ見て改善する考え方です。API越しのLLMや外部ツールを使う現実のAI開発ではこの条件が普通なので、TextGradの前提理解に重要です。
- テスト時最適化
- モデルを再学習せず、推論時にその場で回答や解法を改善する方法です。TextGradはプロンプト最適化だけでなく、1問ごとの回答やコードを反復改善する使い方もできます。
- LLM-as-a-Judge
- 別のLLMに出力の良し悪しを評価させる設計です。TextGradでは評価モデルが単に点数を返すだけでなく、修正方針を含む批評を返すため、更新信号として機能します。
技術の仕組み
TextGrad の基本アイデアは、AI システムを PyTorch のような計算グラフとして扱い、各変数に対して「どう改善すべきか」を自然言語で逆伝播させることです。論文ではこの批評を textual gradients と呼んでいます。
基本アイデア
単純な例では、まず LLM が質問に答え、その後に別の LLM がその回答を評価します。通常なら評価文を読んで人間がプロンプトや回答を修正しますが、TextGrad はこの工程をフレームワーク化します。評価器が返した批評をもとに、まず回答を改善し、さらにその回答を生んだプロンプトにも批評を返せるようにします。
この流れは、数値勾配でいう chain rule の比喩に近いです。厳密な微分ではありませんが、「後段の失敗理由を前段の変数へ帰属させる」という構造を持っています。
モデル構造
TextGrad では、質問文、システムプロンプト、回答、コード断片などを Variable として持ちます。そして LLM 呼び出しや評価関数を、それらの変数を受け取って新しい変数を返す変換として扱います。つまり、重み付きニューラルネットワークの代わりに、テキスト変数とブラックボックス関数からなる計算グラフを作る設計です。
この抽象化の利点は、対象がテキストに限られないことです。論文ではコード、分子表現、放射線治療計画のような構造化対象も扱っています。要するに、最終的に LLM が読めて改善案を書けるなら、最適化変数として置けるわけです。
学習方法ではなく「更新ループ」を作る
TextGrad は通常の意味での学習アルゴリズムではなく、反復的な更新ループです。1 回のイテレーションは大まかに次の流れです。
1. Forward
現在のプロンプトや中間変数を使って、回答やコードなどの出力を生成します。
2. Loss の計算
評価関数を実行します。ここが TextGrad の面白いところで、損失関数は数値である必要がありません。自然言語で書かれた評価指示を LLM に与えて批評文を出させてもよいですし、ユニットテストの失敗ログやシミュレータの出力を使っても構いません。
3. Backward
評価結果から、どの変数をどう直すべきかという批評を生成し、依存関係に沿って前段へ伝えます。1つの変数が複数の後続ノードで使われている場合は、それぞれの文脈から来た批評を集約します。
4. Update
Textual Gradient Descent という更新器で、現在の変数値と批評文を入力にして新しい変数値を生成します。数値勾配のように x - lr * grad とは書けませんが、役割としては「改善方向に沿って次の候補を作る」処理です。
インスタンス最適化とプロンプト最適化
論文では大きく2種類の使い方をしています。1つはインスタンス最適化で、ある1問の解答、1本のコード、1つの分子をその場で改善するやり方です。これはテスト時最適化に近く、難問回答やコード修正に向いています。
もう1つはプロンプト最適化です。こちらは複数の訓練例を使って、全体に効くシステムプロンプトを更新します。通常の few-shot 最適化が例示データを増やして性能を上げるのに対し、TextGrad は命令文そのものを改良します。推論時に長いデモを毎回入れなくてよいので、コストやレイテンシの面でも利点があります。
重要な工夫
重要な工夫は、評価信号の形式を固定しないことです。たとえばコード生成ならユニットテスト結果を評価の根拠にできますし、推論問題なら批評専用 LLM を使えますし、科学計算ならシミュレータ出力を評価できます。つまり TextGrad は「LLM で全部やる」のではなく、外部評価器と LLM の言語的な改善能力をつなぐ接着層として働きます。
実験と結果
論文では、TextGrad が単なるプロンプト改善テクニックではなく、複数の最適化問題で機能することを示しています。評価対象はコード生成、難問QA、推論用プロンプト最適化、分子設計、放射線治療計画とかなり広いです。
コード生成の改善
LeetCode Hard を使ったコード最適化では、GPT-4o のゼロショット解答を起点に、ユニットテスト結果を手掛かりにコードを改善しています。成功指標は全テスト通過率です。
論文では、既存報告の GPT-4 ゼロショット 7%、Reflexion 15% に対して、再実験した GPT-4o ゼロショットが 23%、Reflexion が 31%、TextGrad が 36% でした。ここで重要なのは、TextGrad がゼロショット設定で動いており、Reflexion のようなデモ依存の自己反省ループより高い通過率を出している点です。コード生成の実務では、単に再試行するより「どこが危ないか」を明示的に批評させて修正する方が効く可能性を示しています。
難問QAのテスト時改善
Google-Proof Question Answering では、GPT-4o のゼロショット精度を 51% から 55% に改善したと報告されています。加えて、MMLU の Machine Learning と College Physics の難しいサブセットでも改善が確認されています。論文では、1回で正答を出させるのではなく、回答を数回セルフリファインし、最後に多数決で決める構成を使っています。
この結果から言えるのは、強いモデルでも難問では「最初の答えを少し疑って修正する」余地があることです。TextGrad はその修正を自由記述の自己反省ではなく、計算グラフに沿った更新ループとして管理しています。
プロンプト最適化
Big-Bench Hard の Object Counting、Word Sorting、GSM8K では、gpt-3.5-turbo のシステムプロンプトを gpt-4o の批評で改善しています。論文では、TextGrad は Word Sorting と GSM8K で DSPy と同程度、Object Counting では DSPy を 7% 上回ったと報告しています。
ここで面白いのは、DSPy が主に few-shot 例の選択で改善するのに対し、TextGrad は instruction-only、つまり命令文の改善だけで戦っていることです。さらに両者を組み合わせると GSM8K では 82.1% まで上がったとされており、最適化手法同士が競合ではなく補完関係にあることも示しています。
結果から何が言えるか
結果全体を見ると、TextGrad は特定ベンチマーク専用の裏技ではなく、評価信号を言語化できる問題で広く使える可能性があります。特に効いているのは、1発生成よりも「生成して、批評して、修正する」方が自然なタスクです。コード生成、難問推論、エージェント実行、プロンプト改善はまさにその代表例です。
何に使える？
TextGrad は研究用途だけでなく、AI アプリの改善ループにそのまま応用しやすい技術です。以下は実務で特に相性がよさそうな使い道です。
小さなモデルの底上げ
高価なモデルを常用できないプロダクトでは、強いモデルを評価器としてだけ使い、安いモデルのプロンプトや出力を最適化する構成が考えられます。論文の gpt-3.5 を gpt-4o で改善する実験は、そのまま SaaS の推論コスト設計に応用できます。
エージェントのワークフロー改善
検索、要約、ツール実行、最終回答のような多段エージェントでは、どのステップが失敗原因かを特定しにくいです。TextGrad 的な設計を入れると、各ステップの出力に対して「何が不足していたか」を返し、次回のステップ記述やツール選択条件を改善できます。これは社内業務エージェントや開発支援エージェントで特に有効そうです。
コード生成や自動修正
ユニットテスト、lint、静的解析の結果を評価信号として使えば、コード修正ループをかなり体系化できます。単なる再生成ではなく、失敗理由を自然言語に変換してコードへ戻すので、局所修正がしやすくなります。バグ修正補助や migration 支援にも向いています。
非テキスト最適化への橋渡し
論文は分子設計や治療計画も扱っており、外部シミュレータや業務ルールエンジンと LLM をつないで改善する方向性も見せています。実務では、価格提案ルール、問い合わせフロー、スケジューリング案、広告文生成など、最終評価が別システムにある領域で応用余地があります。ここは論文の直接検証範囲を超えるので推測を含みますが、「評価器が外にあり、改善案を言語で返せる」問題には広く展開できそうです。
開発や事業へのヒント
この論文の価値は、単に TextGrad という名前の手法よりも、「AI システムを最適化可能なオブジェクトとして設計する」という考え方にあります。
まず評価器を先に作る
AI アプリを作るとき、多くの場合は生成部分から先に作ります。しかし TextGrad 的には、先に評価関数を定義しないと改善ループが回りません。正解率、テスト通過、形式チェック、引用の妥当性、業務ルール違反など、何を良しとするかを明文化すること自体が重要だとわかります。
プロンプトを固定文ではなく可変パラメータとして扱う
実務ではシステムプロンプトを一度書いて終わりにしがちですが、TextGrad はそれを更新可能なパラメータとして扱います。小規模プロダクトでも、問い合わせ分類、要約テンプレート、抽出ルール、レビュー指示文の改善ループにこの考え方を入れられます。
強いモデルを「生成器」ではなく「改善器」として使う
強いモデルを毎回 front に置くとコストが重いですが、改善ループだけに使うと費用対効果が上がる可能性があります。これは事業面でも大きく、安価な運用モデルを維持しながら品質を上げる設計につながります。
エージェント評価の設計が重要になる
今後注目すべき方向性は、エージェントを賢くすること自体より、エージェントをどう評価し、どう改善信号を返すかです。TextGrad はその入口で、将来的にはログ、テスト、シミュレーション、ユーザーフィードバックを組み合わせた複合評価器が重要になるはずです。
限界
TextGrad にも明確な限界があります。まず計算コストです。1回の生成で終わらず、評価用 LLM 呼び出し、 backward 用の批評生成、更新後の再実行が増えるため、推論回数が膨らみます。高速なオンライン応答が必要なシステムでは、そのまま入れると遅延が問題になります。
次に、評価器への依存が強い点があります。批評が的外れなら、更新も誤った方向に進みます。LLM-as-a-Judge の信頼性や、外部テストの網羅性が不足していると、見かけ上は改善しても本質的には壊れる可能性があります。
再現性にも注意が必要です。LLM の出力は確率的で、同じ批評でも更新結果が安定しない場合があります。また、自然言語の批評は情報量が多い反面、曖昧さも含みます。数値最適化のように滑らかな収束保証があるわけではありません。
実装面では、どの変数を更新対象にするか、どこで止めるか、批評をどう集約するかの設計が難しいです。実運用では、無制限に自己修正させるとプロンプト肥大化、過剰最適化、ループ化が起きる恐れもあります。さらに、論文は多様なタスクで有望さを示していますが、業務システム特有の制約や長期運用での安定性については、まだ検証余地が大きいです。
よくある質問
Q. TextGrad はモデルの再学習と何が違うのですか？
A. モデル重みを更新するのではなく、プロンプト、回答、コードなどの離散的な出力を改善します。再学習には大量データやGPUが必要ですが、TextGrad は API モデルでも使える点が大きく違います。
Q. これはエージェント開発にも使えますか？
A. 使えます。特に複数ステップのエージェントで、検索語、ツール選択、要約方針、最終回答テンプレートなどを改善したい場合に相性が良いです。ただし、各ステップの良し悪しを判定する評価器設計が前提になります。
Q. TextGrad があればプロンプトエンジニアリングは不要ですか？
A. 不要にはなりません。初期プロンプト、評価指示、停止条件が悪いと最適化も崩れます。TextGrad は人手を完全に置き換えるというより、試行錯誤を体系化するための仕組みです。
Q. 小規模プロダクトでも活用できますか？
A. 活用できます。たとえば FAQ 分類、要約品質改善、コード修正、RAG 回答の根拠不足検出などは比較的小さな構成でも試せます。まずは offline バッチ改善から始めるのが現実的です。
Q. RAG に直接使える技術ですか？
A. 直接の検索アルゴリズムではありませんが、RAG パイプラインの改善には使えます。検索クエリ生成、再ランキング方針、回答テンプレート、引用形式の修正などを更新対象にすれば、RAG の品質改善ループとして組み込めます。
今日の学び
この論文は、複数の LLM やツールからなる AI システムを、どうやって人手頼みではなく改善していくかという課題を扱いました。そこに対して、数値勾配の代わりに自然言語の批評を逆伝播させる TextGrad という仕組みで解こうとしています。
得られるヒントは明快です。これからの AI 開発では、良いモデルを選ぶこと以上に、システムを評価可能に設計し、その評価を改善信号として回せるかが重要になります。RAG でもエージェントでもコード生成でも、「生成して終わり」ではなく「批評して更新する」前提で設計すると、プロダクトの伸びしろが大きくなりそうです。