概要

• LangChain と比べて DSPy の利用者数が少ない理由の分析
• DSPy の導入で得られるメリットと、現場でよく起こる「車輪の再発明」問題
• AIシステム開発が進むにつれて直面する 共通課題 とその進化段階
• DSPy による設計パターンの標準化と、その学習曲線の高さ
• 結論として、 DSPy の採用か、その設計思想を自前で実装する必要性

LangChainとDSPyの利用状況の比較

• LangChain の月間ダウンロード数は 2億2200万件、 DSPy は 470万件 という大きな差
• DSPy 導入企業は「新モデルの迅速なテスト」「保守性向上」「文脈重視の設計」といった 共通の利点 を報告
• DSPy が普及しない主な理由は、「間違っている」からではなく「難しい」から
• DSPy の抽象化は従来と異なる思考を要求し、初学者には 学習コスト が高い
• 多くの現場で、結局は DSPyの劣化版 を自前で作る羽目になるという「Khattab’s Law」現象

AIシステム開発の進化段階

• どのチームも最終的に「自家製DSPy」を実装する流れ
• 例として「企業名抽出タスク」の進化を段階ごとに説明
  • 第1段階: シンプルなAPI利用
    • OpenAI APIで企業名抽出関数を実装し、すぐに運用開始
  • 第2段階: プロンプトの柔軟管理
    • プロンプトをDB管理し、プロダクト側で即時変更できるようにUIやバージョン管理を追加
  • 第3段階: 出力フォーマットの構造化
    • Pydanticで型定義し、信頼性向上
  • 第4段階: 障害対応
    • 529エラーやパース失敗にリトライ処理を追加
  • 第5段階: RAG(検索拡張生成)導入
    • 企業情報ベクトルDBと連携し、文脈情報を活用
  • 第6段階: 評価基盤の必要性
    • 変更の効果検証や精度追跡のために評価コードを導入
  • 第7段階: モデル切り替え問題
    • APIクライアントやプロンプトの違いによる大規模リファクタリング発生

DSPyによる解決方法

• DSPy なら、上記すべてのパターンを一元的かつ宣言的に表現可能
  • モデルの切り替えは 1行 で完了
  • 入出力型定義（Signature）、モジュール化、RAG、評価、最適化まで 標準化
  • プロンプト管理やリトライ処理、APIクライアントの煩雑さから解放
• 例：DSPyでの企業名抽出タスク
  • 型定義・RAG・評価・最適化 が簡潔に記述可能
  • モデル切り替えもdspy.configure(lm=dspy.LM("anthropic/claude-sonnet-4-20250514"))の1行で可能
  • 最適化器がプロンプトや例示データも自動で調整

DSPyが内包する設計パターン

• Signatures
  • 型付き入出力スキーマによる明確なインターフェース
• Modules
  • 独立・再利用可能なモジュール設計
• Optimizers
  • プロンプト改善ロジックの分離と自動化
• これらは「関心の分離」「コンポーザビリティ」「宣言的インターフェース」といった ソフトウェア工学の基本

なぜ多くのエンジニアが悪いAIコードを書くのか

• フィードバックループの不透明さ
  • プロンプトの逐次デバッグが困難、確率的な出力で触りたくなくなる
• リリース圧力
  • LLMが動くこと自体がゴール化し、アーキテクチャの洗練は後回し
• 境界の不明瞭さ
  • プロンプトがコードでもありデータでもあるため、設計が曖昧化
• 結果として 場当たり的な実装 が積み重なり、半年後には複雑化したシステムに苦しむ

どうすればよいか

• 選択肢1: DSPyを使う
  • 学習コストを受け入れ、ドキュメントを読み、プロトタイプで抽象化に慣れる
• 選択肢2: DSPyの設計思想を盗む
  • 以下のパターンを自前実装
    • LLM呼び出しごとの型定義（Pydantic等）
    • プロンプトとコードの分離
    • テスト可能なコンポーザブル設計
    • 初期段階から評価基盤の導入
    • モデル呼び出しの抽象化（モデル切り替えを1行で）

結論：DSPyの本質

• DSPy が普及しないのは、「痛みを実感する前に考え方を変える」ことを要求するから
• DSPy が体現する設計パターンは 必須 であり、AIシステムが十分に複雑化すれば必ず必要となる
• 結局、 DSPyを使う か、 同様のパターンを自前で実装する か、どちらかを選ぶことになる