はじめに：プロンプト職人は廃業する運命なのか
前回の記事
『プロンプトで祈るのはもうやめる。Outlines / Guidance で LLM の出力を 100% 制御する技術』
では、LLMの 出力（Output） を論理的に制御する方法を解説しました。
多くの反響をいただき、現場のエンジニアがいかに
LLMの不安定な挙動に悩まされているか を再確認しました。
出力は制御できた。では入力は？
出力は制御できるようになりました。
しかし、入力（Input）＝プロンプト はどうでしょうか？
- 「もう少し丁寧に考えて」
- 「ステップ・バイ・ステップで」
- 「あなたは優秀なアシスタントです」
相変わらず、私たちは
文字列の魔術（プロンプトエンジニアリング） に時間を費やしています。
- モデルのバージョンが変わるたびに微調整
- Few-shot の例を手作業で入れ替え
- なぜ効いたのか分からないまま運用
これは本当に エンジニアリング と呼べるのでしょうか？
本記事では、スタンフォード大学発のライブラリ DSPy を紹介します。
DSPy は、
プロンプトを「手書き」するのをやめ、
評価指標に基づいて コンパイル（自動最適化） する
という、LLM開発の前提をひっくり返す技術です。
DSPy とは：LLMアプリを「PyTorch」のように書く
DSPy（Declarative Self-improving Language Programs）の核心は、
次の思想にあります。
プロンプトは文字列ではなく、最適化可能なパラメータである
従来の開発
- 長大なプロンプト文字列を f-string で結合
- 試行錯誤と勘に頼った調整
- モデルが変わると全部やり直し
DSPy の開発
- 入出力の型（Signature）を定義
- ロジック（Module）を書く
- データと評価関数を与えて Compile
これはまさに、
PyTorch でニューラルネットを定義して学習させる感覚
で、LLMアプリを書くという体験です。
仕組み：なぜ「コンパイル」で賢くなるのか？
DSPy の中核にあるのが
Teleprompter（Optimizer） という概念です。
構成要素
-
Signature
入出力の定義（例：質問 → 回答） -
Dataset
少量の教師データ（質問と正解） -
Metric
良し悪しを判定する評価関数 -
Compile
Optimizer が LLM を何度も叩いて最適化
Compile 中に行われていること
Optimizer は、以下を 自動探索 します。
- タスクに最適な Instruction（指示文）
- 問いに最も効果的な Few-shot 例示（Demo）
- 有効な Chain of Thought（思考ステップ）
人間が
「どの例を見せれば賢くなるかな……」
と悩んでいた部分を、
アルゴリズムが総当たりで最適化 してくれるわけです。
実践：DSPy で RAG の精度を上げる
今回は、単純な QA タスク（RAG 想定）で
DSPy がどのようにプロンプトを自動生成するかを見ていきます。
1. 環境構築
pip install dspy-ai
2. モジュール定義
ここでは dspy.ChainOfThought を使います。
これだけで「推論してから回答せよ」というロジックになります。
プロンプトを書く必要はありません。
import dspy
# LLMの設定（OpenAI / Local）
# turbo = dspy.OpenAI(model='gpt-3.5-turbo')
# dspy.settings.configure(lm=turbo)
# ローカルLLMの場合は HFClientVLLM などを使用
# 1. Signature（入出力定義）
class GenerateAnswer(dspy.Signature):
"""質問に対して、文脈を踏まえて論理的に回答する"""
context = dspy.InputField(desc="回答の根拠となる情報")
question = dspy.InputField(desc="ユーザーからの質問")
answer = dspy.OutputField(desc="短く簡潔な回答")
# 2. Module（処理ロジック）
class RAG(dspy.Module):
def __init__(self):
super().__init__()
self.generate_answer = dspy.ChainOfThought(GenerateAnswer)
def forward(self, context, question):
return self.generate_answer(context=context, question=question)
3. コンパイル（最適化）の実行
ここが DSPy のハイライト です。
今回は BootstrapFewShot を使います。
これは、
成功した推論プロセスだけを Few-shot として残す
最適化手法です。
from dspy.teleprompt import BootstrapFewShot
# 教師データ
trainset = [
dspy.Example(
context="Pythonは1991年にグイド・ヴァン・ロッサムによって開発された。",
question="Pythonの開発者は誰？",
answer="グイド・ヴァン・ロッサム"
).with_inputs('context', 'question'),
# ... 数件追加 ...
]
# 評価関数（簡易的に完全一致）
def validate_answer(example, pred, trace=None):
return example.answer == pred.answer
# コンパイル！
teleprompter = BootstrapFewShot(
metric=validate_answer,
max_labeled_demos=4
)
compiled_rag = teleprompter.compile(
RAG(),
trainset=trainset
)
検証結果：何が変わったのか？
pred = compiled_rag(context="...", question="...")
dspy.inspect_history(n=1)
Before（最適化前）
- 単純な
質問: ... 文脈: ... → 回答:
という素っ気ないプロンプト
After（最適化後）
- DSPy が自動選定した 成功した推論パターン が
Few-shot として複数挿入 - Instruction 部分も自動で微調整
DSPy は、こちらが一切指示していないにも関わらず、
「このタイプの質問は、この思考ステップを踏めば正解できる」
というパターンを発見し、
それをプロンプトにハードコードしてくれました。
精度比較（例）
手書きプロンプト（Zero-shot） : 正答率 60%
DSPy（BootstrapFewShot） : 正答率 85%
※ タスク・データによって変動します
まとめ：LLM開発のパラダイムシフト
プロンプトエンジニアリングは重要ですが、
人間が手作業でやるには限界 があります。
DSPy がもたらす変化：
-
モジュール化
ロジックとプロンプトの分離 -
移植性
モデル変更時は compile し直すだけ -
性能向上
人間が思いつかない Few-shot を発見
最強の組み合わせ
- 入力：DSPy で最適化
- 出力：Outlines で制御
これで私たちは、
- お祈りから解放され
- 作文からも解放され
- 真の意味での Software Engineering 2.0
に集中できるはずです。