DSPy（ディーエスパイ）

DSPyとは

DSPyとは、Stanford NLP Groupが2023年に公開した宣言型のLLMプログラミングフレームワークである。従来のプロンプトエンジニアリング（手動でプロンプトを調整する作業）を排除し、プログラマが入出力の型（Signature）と評価関数（Metric）を定義するだけで、フレームワークが最適なプロンプト・Few-Shot例・パイプライン構成を自動探索する。2026年6月時点でGitHub Stars 22,000超、PyPIダウンロード月間80万。

従来手法との根本的な違い

DSPyの最大の利点は「モデルを変更してもプロンプトを書き直す必要がない」点である。GPT-4oからClaude 4 Sonnetに切り替える場合、DSPyはメトリクスに基づいて新モデル向けに自動再最適化する。

コア概念

Signature（シグネチャ）

入出力の型定義。Pythonの型ヒントに似た宣言的記法でモジュールのインタフェースを定義する。

例: "question -> answer" は質問を入力として回答を生成するシグネチャ。"context, question -> reasoning, answer" のように複数入出力も可能。

Module（モジュール）

Signatureを実装する処理単位。PyTorchのnn.Moduleに着想を得た設計で、以下の組み込みモジュールが提供される。

Optimizer（オプティマイザ）

モジュールのパラメータ（プロンプト・Few-Shot例・命令文）を自動最適化するコンパイラ。

Metric（メトリクス）

最適化の目標関数。正解ラベル付きの評価データセットに対して、生成結果の品質を0〜1のスコアで定量化する。完全一致・F1スコア・BERTScore・LLM-as-Judge等を利用可能。

実装ワークフロー

1. データ準備: 入出力ペアの評価データセット（最低30〜50件推奨）を用意
2. Signature定義: 入出力の型を宣言
3. Module構成: Predict・ChainOfThought等を組み合わせてパイプラインを構築
4. Metric定義: 評価関数を実装
5. Compile（最適化）: Optimizerを実行してパラメータを自動調整
6. 評価: テストデータで性能を検証
7. 保存・デプロイ: 最適化済みプログラムをシリアライズして本番投入

パフォーマンスベンチマーク

DSPy公式の報告によると、手動プロンプトエンジニアリングと比較して以下の改善が確認されている。

注意点と制約

• 評価データの質: DSPyの最適化品質は評価データセットに依存する。バイアスのあるデータで最適化するとバイアスが増幅される
• 計算コスト: MIPROv2の全探索は候補プロンプト×評価データ×LLM呼び出しで$10〜$100になることがある。max_bootstrapped_demosとnum_trialsで制御
• デバッグ困難性: 自動生成されたプロンプトは人間が読みにくいことがある。dspy.inspect_history()で中間ステップを確認可能
• ストリーミング非対応: 2026年6月時点でストリーミング出力は限定的。リアルタイムチャットには不向き

よくある質問（FAQ）

Q1: DSPyは少量データでも効果がありますか？ A: BootstrapFewShotは10〜30件程度でも改善効果がある。ただし、MIPROv2のようなプロンプト全体最適化には50件以上推奨。データが少ない場合はLLM-as-Judgeでの合成評価データ生成を検討する。

Q2: DSPyとLangChainは併用できますか？ A: 可能。DSPyでLLM呼び出し部分を最適化し、LangChainのRetriever・Tool統合と組み合わせる構成が一般的。dspy.LangChainModuleアダプタも提供されている。

Q3: DSPyで最適化したプロンプトを別のモデルに適用できますか？ A: 推奨しない。DSPyの最適化結果はモデル固有のものであり、GPT-4o向けに最適化したプロンプトをClaude 4で使うとパフォーマンスが低下する。モデル変更時は再コンパイル（再最適化）を推奨する。

まとめ

• DSPyはStanford NLP Group発の宣言型LLMプログラミングフレームワーク
• Signature（型定義）・Module（処理単位）・Optimizer（自動最適化）・Metric（評価関数）の4概念で構成
• 手動プロンプトエンジニアリングを排除し、評価データに基づく自動最適化で再現性と品質を向上
• モデル変更時は再コンパイルのみでプロンプト書き直し不要