Stanford NLP グループが開発したLLMプログラミングフレームワーク。プロンプトエンジニアリングを「プログラミング」に置き換え、LLMパイプラインのモジュール定義・自動プロンプト最適化・評価を体系的に行う。手動プロンプト調整からの脱却を目指す2023年公開のPythonライブラリ。

DSPyとは？（ディーエスパイ）意味・特徴をわかりやすく解説

DSPyとは

DSPy（Declarative Self-improving Language Programs in Python）は、Stanford大学のNLPグループが2023年に公開したLLMプログラミングフレームワークである。GitHub Stars 22,000超（2026年時点）。最大の特長は「プロンプトエンジニアリングからの脱却」で、LLMパイプラインの入出力をシグネチャとして宣言し、コンパイラ（Optimizer）が自動的に最適なプロンプトや少数ショット例を生成する。

主な特徴

シグネチャ（Signature）: LLMの入出力を question -> answer のように宣言的に定義。プロンプトの具体的な文面を書かない
モジュール（Module）: Predict・ChainOfThought・ReAct等のビルトインモジュールでLLM呼び出しパターンを定義。PyTorchのnn.Moduleに似た設計思想
オプティマイザ（Optimizer/Teleprompter）: 訓練データからプロンプト・少数ショット例・指示文を自動最適化。BootstrapFewShot・MIPRO・BayesianSignatureOptimizer等
メトリクス（Metric）: 出力の品質を評価する関数を定義。正解率・BLEU・カスタムLLM評価等
LMクライアント抽象化: OpenAI/Anthropic/Ollama/vLLM等のLLMバックエンドを統一APIで切り替え
コンパイル（Compile）: module + metric + training data → 最適化されたプログラムを自動生成。手動プロンプト調整が不要に
Assertions: LLMの出力に制約（長さ制限・フォーマット検証等）を追加し、制約違反時に自動リトライ
ライセンス: MIT

コード例

import dspy

# LMの設定
lm = dspy.LM("openai/gpt-4o-mini")
dspy.configure(lm=lm)

# シグネチャ定義（入出力を宣言するだけ）
class QA(dspy.Signature):
    """質問に正確に答えてください"""
    question: str = dspy.InputField()
    answer: str = dspy.OutputField()

# モジュール（ChainOfThoughtで推論）
cot = dspy.ChainOfThought(QA)

# 実行
result = cot(question="日本で最も高い山は？")
print(result.answer)  # "富士山（3,776m）"

# オプティマイザで自動最適化
from dspy.teleprompt import BootstrapFewShot

optimizer = BootstrapFewShot(metric=exact_match, max_bootstrapped_demos=4)
optimized_cot = optimizer.compile(cot, trainset=train_examples)

DSPy vs 従来のプロンプトエンジニアリング

観点	従来のプロンプト	DSPy
プロンプト作成	手動で試行錯誤	シグネチャ宣言→自動生成
少数ショット例	手動で選択・配置	オプティマイザが自動選択
モデル切替	プロンプト全面書き直し	シグネチャ同一で自動適応
評価	主観的・非体系的	メトリクス関数で定量評価
再現性	低（プロンプト職人芸）	高（コード化・バージョン管理可能）

ユースケース

RAGパイプライン最適化: 検索→リランキング→生成の各段階でシグネチャを定義し、end-to-end で最適化
分類タスク: 感情分析・意図分類等のシグネチャを定義し、少数の訓練データで自動プロンプト最適化
情報抽出: 構造化データ抽出のシグネチャ（text -> entities）を定義し、出力フォーマットを自動学習
マルチホップQA: ChainOfThought + Retrieve の組み合わせで複雑な質問応答パイプラインを構築
LLMパイプラインのA/Bテスト: 同一シグネチャで異なるオプティマイザ・LLMバックエンドを比較評価

選び方・注意点

学習曲線: DSPyの概念（シグネチャ・モジュール・オプティマイザ・メトリクス）を理解するのに時間がかかる。PyTorchの経験があると理解が早い
訓練データが必要: オプティマイザの効果を発揮するには50-200件程度の訓練データ（入力→期待出力のペア）が必要。ゼロショットではDSPyの恩恵が薄い
マルチエージェントとは異なる: DSPyは「LLMパイプラインの最適化」であり、LangGraph/AutoGen/CrewAIの「マルチエージェント協調」とはレイヤーが異なる。DSPyのモジュールをLangGraphのノードに組み込む併用パターンもある
デバッグ: オプティマイザが生成するプロンプトがブラックボックスになりやすい。dspy.inspect_history() で内部プロンプトを確認推奨
コミュニティ: Stanfordの研究プロジェクト発祥で学術色が強い。エンタープライズサポートはLangChain/CrewAI比で弱い

よくある質問（FAQ）

Q1: DSPyを使うとプロンプトエンジニアリングが完全に不要になる？ A: 「手動プロンプト調整」は不要になるが、シグネチャの設計（入出力の定義）とメトリクスの設計は人間が行う必要がある。プロンプトの「文面」を考える作業が、「インターフェース」を設計する作業に置き換わる。

Q2: LangChainとDSPyの違いは？ A: LangChainはLLMアプリケーションの「配管工事」（ツール接続・メモリ管理・チェーン構築）、DSPyはLLMパイプラインの「最適化エンジン」。両者は競合ではなく補完関係。LangChainで構築したパイプラインの各LLM呼び出しをDSPyモジュールに置き換える併用が理想的。

Q3: 小規模プロジェクトでもDSPyは有効？ A: LLM呼び出しが1回だけの単純なタスクではDSPyのオーバーヘッドが大きい。3段階以上のLLMパイプライン（検索→判断→生成等）で初めてDSPyの自動最適化が威力を発揮する。

まとめ

DSPyはプロンプトエンジニアリングを「プログラミング」に置き換えるStanford発のLLMフレームワーク
シグネチャで入出力を宣言し、オプティマイザが最適なプロンプトを自動生成
手動プロンプト調整の試行錯誤から脱却し、再現性のあるLLMパイプライン構築が可能
訓練データとメトリクス設計が必要で学習曲線は急だが、複雑なパイプラインでは大きな効果

DSPy（ディーエスパイ）