DSPy完全ガイド2026｜Stanford NLP発の宣言的LLMプログラミングと自動プロンプト最適化

DSPyとは｜「プロンプトを書く」から「LLMをプログラムする」へのパラダイムシフト

DSPy(Declarative Self-improving Python)は、Stanford NLPが開発したLLMを「プログラム」するためのオープンソースフレームワークです。プロンプト文字列を手書き・微調整する代わりに、Python のクラスとシグネチャで「何を入力して何を出力するか」を宣言的に書き、最適化器(Teleprompter)が自動でプロンプトと例示を最適化します。

2022年2月に Stanford NLP で研究開始、2022年12月に DSP として初版リリース、2023年10月に DSPy へ進化。2026年4月時点でGitHub スター約23,000・コントリビューター約300名、500以上の OSS プロジェクトが依存する、LLM プログラミングの新標準として急成長しています。Dropbox は実際に Dash の Relevance Judge を DSPy で最適化した事例を公開しています。

本記事ではDSPyの3核心抽象(Signature/Module/Optimizer)、主要オプティマイザ(MIPROv2/GEPA/BetterTogether)、従来プロンプト管理との違い、ユースケース、そしてrenue独自視点として「DSPy採用判断7原則」を解説します。

従来のプロンプト管理 vs DSPy

観点	従来(プロンプト手書き+管理ツール)	DSPy
記述	自然言語のプロンプト文字列	Python の Signature クラス
主体	人間がプロンプトを微調整	オプティマイザが自動最適化
変更単位	プロンプト文字列	モジュール構造+メトリック
再利用	テンプレート化	クラス継承・コンポーザブル
モデル非依存性	モデル毎にプロンプト書き直し	シグネチャは共通、オプティマイザがモデルに合わせて最適化
パイプライン構築	プロンプトチェイン手書き	モジュール組合せで宣言的に記述
学習曲線	低い(自然言語)	中(Python+ML思考)
本番品質	属人的・揺らぎあり	メトリック駆動・再現性高

DSPyの3核心抽象

1. Signature(シグネチャ)｜入出力契約

「何を入力して何を出力するか」を Python クラスで宣言します。プロンプトの内容ではなく入出力の型と意味を定義する点が革新的です。

class Summarize(dspy.Signature):
    """文書を3文以内で要約する"""
    document: str = dspy.InputField()
    summary: str = dspy.OutputField(desc="要点を3文以内で")

このシグネチャから、DSPy がモデルに合わせた具体的プロンプトを自動生成します。

2. Module(モジュール)｜再利用可能なLLM呼び出し単位

シグネチャを実行可能にした単位がモジュールです。ChainOfThought / ReAct / ProgramOfThought 等の推論パターンが組み込みで用意されています。

class QA(dspy.Module):
    def __init__(self):
        self.retrieve = dspy.Retrieve(k=5)  # RAG 検索
        self.generate = dspy.ChainOfThought(GenerateAnswer)  # CoT で回答

    def forward(self, question):
        context = self.retrieve(question).passages
        return self.generate(context=context, question=question)

モジュールを組み合わせるだけで、RAG+CoTパイプラインが完成します。

3. Optimizer(オプティマイザ/Teleprompter)｜自動プロンプト最適化

DSPy の最大の革新が**自動最適化**です。タスク・データ・評価メトリックを与えると、オプティマイザがプロンプトと例示(Few-shot examples)を自動で最適化します。

オプティマイザ	仕組み	得意
BootstrapFewShot	成功例から Few-shot 例を自動生成	初期の素早い改善
MIPROv2	Bayesian Optimization で命令文+例示を同時探索	本番品質の最適化
GEPA	LLM がプログラムの実行軌跡を反省し、改善プロンプトを提案	失敗パターンからの学習
BetterTogether	プロンプト最適化+重み最適化(ファインチューニング)を組み合わせるメタ最適化器	精度上限の引き上げ
BootstrapFinetune	成功軌跡から自動で fine-tuning データセット作成	小モデルへの能力蒸留

DSPy の典型的ワークフロー

Signature 定義:タスクの入出力契約を Python クラスで書く
Module 構築:既存モジュール(Predict/ChainOfThought/ReAct/Retrieve等)を組み合わせる
Metric 定義:成功条件(精度・F1・LLM-as-a-Judge等)を関数で書く
データ準備:Train/Dev のサンプルを揃える(20〜500件で十分なことが多い)
Compile(最適化実行):Optimizer に Module + Metric + データを渡して最適化
Save & Load:最適化済みプログラムを保存、本番でロード
Monitor:本番ログから新たな成功/失敗例を集めて再 Compile

主要ユースケース

RAG パイプライン:検索+CoT+構造化出力を宣言的に組合せ、自動最適化
分類器:手書きプロンプトでは到達しにくい精度を Optimizer で叩き出す
抽出タスク:文書から構造化情報を取り出す、Few-shot 例を自動生成
多段推論:複雑な数学・論理問題を Module 組合せで解く
評価器(LLM-as-a-Judge):評価LLM自身を DSPy で最適化する(メタ的活用)
小モデルへの能力蒸留:GPT-4 で生成した成功軌跡から Llama 等を fine-tune する

DSPyが向くケース・向かないケース

向くケース

Golden Set を持っており、メトリックが定量化できる
プロンプト手書きで品質が頭打ち
モデルを乗り換える可能性が高い(モデル非依存性が効く)
本番運用で再現性・自動改善を重視
Python + ML 知識のあるチーム

向かないケース

ワンショットの単純タスク(Optimizer の効果が限定的)
評価メトリックが定量化困難(クリエイティブライティング等)
非エンジニアがプロンプトを編集する運用(PromptLayer 系の方が向く)
低レイテンシ要件が極めて厳しい(Optimizer のオーバーヘッドではなく実行時の話、本番ではないがコンパイル時間が長い)
Python以外の主要言語チーム

事例: Dropbox Dash の Relevance Judge 最適化

Dropbox は社内検索プロダクト「Dash」の検索結果関連性判定器(Relevance Judge)を DSPy で最適化した事例を公開しています。手書きプロンプトでは到達しにくい精度を Optimizer で大幅改善し、本番投入したと報告されています。詳細は本記事末尾の参考情報を参照。

renueの視点｜DSPy採用判断7原則

renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、複数のLLMアプリケーションでDSPyの採用可否を検証してきた経験から、7原則を確立しています。

(1) Golden Set がない段階では DSPy を使わない:DSPy の最大の価値はメトリック駆動の自動最適化です。Golden Set が無いと Optimizer が何を最大化すべきか分からず、ただのプロンプトFWに堕します。先に評価セットを作ります。

(2) プロンプト手書きで頭打ちになってから検討:単純なタスクは LangSmith/PromptLayer 系のプロンプト管理(比較)で十分。手書き+Few-shot で 80% に達した後、残り20%を埋めるのが DSPy の出番です。

(3) モデル乗り換えが頻繁にあるなら DSPy:GPT-5 → Claude → Gemini と乗り換えるとプロンプトを書き直す手間が発生します。DSPy はシグネチャ共通+モデル別 Optimizer 実行で乗り換えコストを大幅削減できます(LLM API比較)。

(4) MIPROv2 から始める:オプティマイザの中で本番品質に最も近づきやすいのが MIPROv2 です。BootstrapFewShot は素早い初期改善向け、GEPA は失敗パターンが豊富な場合に効きます。

(5) コンパイル時間とコストを試算:Optimizer は Train/Dev データに対して数十〜数百回の LLM 呼び出しを行うため、コンパイル時間は数十分〜数時間、コストは数千〜数万円規模になります。FinOpsSLO に組み込みます。

(6) BetterTogether で蒸留も視野に:GPT-5 で動くコンパイル済みプログラムから、BetterTogether 経由で Llama/Qwen 等の小モデル fine-tuning データを生成し、本番は安価モデルで動かす蒸留パターンが強力です(LoRA/QLoRA)。

(7) 本番運用では Save/Load+モニタリングを必須化:コンパイル済みプログラムは JSON/Python オブジェクトで保存し、本番ロード→Observability でメトリック追跡→劣化検知で再 Compile のループを回します。

よくある失敗パターン

Golden Set なしで導入:Optimizer が動かず単なる重いプロンプトFWに
コンパイルコスト無視:数万円の LLM 費用が一晩で発生
単純タスクに過剰投入:プロンプト手書きで足りる課題に複雑性を持ち込む
非エンジニアが触れない:Python が読めないチームには不向き
モデル固定で運用:DSPy の最大の強みであるモデル非依存性を活かせていない
Save/Load なし:コンパイル結果を保存せず毎回再最適化

よくある質問（FAQ）

Q1. DSPy は LangChain の代わりですか？

補完関係です。LangChain は「コンポーネント集」、DSPy は「自動最適化レイヤー」。LangChain で組んだパイプラインを DSPy で最適化するパターンも可能です。

Q2. プロンプトを書かないなら何を書くのですか？

Signature(入出力契約)と Metric(成功条件)を書きます。具体的なプロンプト文字列は Optimizer が自動生成します。

Q3. データはどれくらい必要ですか？

20〜500件で十分なケースが多いです。LoRA/QLoRA(数千〜数万件必要)よりはるかに少ないデータで効果が出ます。

Q4. 日本語タスクで使えますか？

使えます。シグネチャ・メトリック・データを日本語で書けば日本語タスク向けに最適化されます。

Q5. renue は DSPy 導入を支援していますか？

はい。Golden Set 設計・Signature 設計・Optimizer 選定・コスト試算・本番運用統合まで一貫して支援しています。「本当に DSPy が必要か」の判断から一緒に検討します。

DSPy導入・LLMプログラミングのご相談はrenueへ

renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、DSPy 採用判断・Signature 設計・Optimizer 選定・コスト試算・本番運用統合までワンストップで支援しています。プロンプト手書きで品質頭打ちの段階を突破したい方はお気軽にご相談ください。

AIエージェント開発の事例を見る