TextGradとDSPyの違いを一言で言うと

どちらも「プロンプトを自動改善する」——でも思想が違う

LLM アプリケーションの開発で、プロンプトを手動で調整し続ける作業は非常に手間がかかります。その課題に応えるフレームワークとして TextGrad と DSPy が注目されています。どちらも「自動でプロンプトを改善する」という目標を持っていますが、その設計思想はまったく異なります。

一言で整理すると：

• TextGrad：「損失を言語で逆伝播させる」
• DSPy：「プロンプトをコンパイルする」

TextGrad の考え方——微分の比喩

TextGrad のコアコンセプトは「テキストによる誤差逆伝播」です。

ニューラルネットワークでは、損失関数から計算した勾配をバックプロパゲーションして重みを更新します。TextGrad はこの仕組みをテキスト空間に持ち込みます。評価関数から受け取った損失（"このプロンプトは曖昧すぎる" といったフィードバック）を LLM が解釈し、文脈的な「勾配」として推定したうえでプロンプト自体を書き換えます。

勾配が数値ではなく自然言語であるという点が独特で、「なぜ悪かったか」という理由を言語として伝播させていくイメージです。プロンプト 1 つを集中的に改善したい場面に向いています。

DSPy の考え方——コンパイラの比喩

DSPy（Stanford NLP 発、GitHub スター 23,000 超）のコアコンセプトは「宣言的 LLM プログラミング」です。

開発者は「何を解くか」をコードで宣言するだけです。たとえば「質問に答えてチェーン・オブ・ソートで推論せよ」という シグネチャ を書くと、GEPA や MIPROv2 といったオプティマイザが、そのシグネチャを満たす最適なプロンプトを自動生成します。

比喩としては「コンパイラ」が近いです。開発者は高レベルな意図をコードで表現し、コンパイラ（オプティマイザ）が実行可能な形（プロンプト）に変換します。オプティマイザを差し替えるだけで最適化戦略を変えられるため、複数ステップの LLM パイプライン全体を扱うのに適しています。

まとめ——使い分けのポイント

「特定のプロンプトをとことん磨きたい」なら TextGrad、「LLM を組み合わせた処理フロー全体をシステマチックに最適化したい」なら DSPy が出発点として適しています。どちらも手動チューニングからの脱却を目指していますが、アプローチの起点が異なります。TextGrad は損失関数から逆算し、DSPy は意図の宣言からコンパイルします。この違いを押さえておくと、自分のユースケースに合ったツール選びがしやすくなります。