ハクソク

世界を動かす技術を、日本語で。

DSPyがそんなに素晴らしいなら、なぜ誰も使っていないのか？

46日前原文(skylarbpayne.com)

概要

  • 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を使う か、 同様のパターンを自前で実装する か、どちらかを選ぶことになる

Hackerたちの意見

昔、一度だけ「本気で」やってみたんだけど、実際に最適化したプロンプトが取り出せないことに気づいて、ちょっと怖くなって別の道に行っちゃった。フレームワークに完全にコミットしなきゃいけないって考えると、ちょっとビビるよね。コンピュータがプロンプトを最適化するっていうのは理にかなってるけど、基盤となる出力プロンプトを不透明な塊として扱うのは納得いかない。私の使い方のいくつかは、dspyが混乱させるほど普通じゃなかったから、余計に困ったし。最後に、dspyにコミットするってことは、将来的に他のフレームワークやツール、プロンプトアプローチを閉ざすことになる気がした。もしかしたら、使い方を誤解してたのかも。

└

誤解してたとは思わないよ。これ、私もDspyに対する一番の不満の一つだし。「プロンプトはパラメータ」っていう考え方をちょっと行き過ぎてると思う。Maximeのこのコミュニティプラグインをチェックすることを強くおすすめするよ。ギャップを埋めるのに役立つから：https://github.com/dspy-community/dspy-template-adapter

えー、これが情報提供の記事だと思ってたのに！結局、著者のコンサルティングビジネスの宣伝じゃん。

└

あ、これ実は前のテンプレートから古い情報だったわ。今はコンサルやってないんだよね :) 削除するね！

└

著者自体がAI生成かもしれないね。ブログの連絡先セクションはただのプレースホルダーの値だし。情報提供の記事の時代は終わったと思う。

DSPyを使う本当の問題は、多くの人がLLMs（エージェントやチャット）で解決しようとしている問題に、明確な評価の道筋がないことだと思う。DSPyに最適化させるためのトレーニングと評価データセットをどう構築するか、じっくり考えなきゃいけない。これにはかなりの前準備と慎重な思考が必要なんだよね。達成しようとしている目標が変わると、その新しいユースケースをカバーするためにトレーニングと評価データセットも更新しなきゃいけなくなる。これが逆にスピードを落とすこともあるよ。チームはプロンプトを最適化しようとしているわけじゃなくて、むしろ正しい質問や答えのセットを見つけるのに苦労していることが多い！

└

そうだね、Dspyは良い「自動メトリック」ができるまでは本当の利点が見えないことが多いと思う。残念なのは、コードの構造を促す方法が、他の理由では良いけど、そんなに「急性」の痛みじゃないこと。時間が経つにつれて、結局それに似たものを作ることになるのは避けられない気がする。

彼らが言ってるほど使いやすくはないよね。入力と出力のシグネチャをまとめなきゃいけないし、全てが動的型付けされてるから、型アノテーションがあちこちにあるコードベースでは使いづらい。しかも、彼らの標準のエージェントループはずっと冗談みたいなもので、自分で書くのも可能だけど、pydantic-aiで何かをやろうとすると全然違うからね。いいところがたくさんあるのに、もっと人気が出てほしいな。

└

そうだね！これには同意するよ。ここに改善された使いやすさがあるね。

"テキストから会社名を抽出してみて。" LLMツールの中で失われていることの一つは、LLM一択になってしまって、他のMLアプローチ、例えばエンティティ認識のようなものがうまく機能することをみんな忘れてしまったことだと思う。すべての問題をLLMに投げるのは簡単だけど、オフ・ザ・シェルフのML/NLP製品が遅延やコストなしで同じように機能することもあるんだよね。

└

それ、100%同意！この問題（これも含めて！）は、LLMに最適じゃないものがたくさんあると思う。みんなが理解しやすいシンプルな例を選ぼうとしてただけなんだ。

└

脆弱でないトランスフォーマー以外のエンティティ抽出ソリューションってあるのかな？私の理解では、エンティティ抽出の最先端（例えばspaCy）は小さなBERTモデルで、特定のことにはすごく強いけど、タイプミスやスペルミスを扱うための世界知識が足りないんだよね。

└

エンティティ認識について 伝統的なNLPの仕事を15年間やってきた者として、LLMは以前のNLPオプションに比べて圧倒的に優れたNERソリューションを提供していると思う。あなたの全体的な意見には賛成で、しばしば人々は優れたオプションがすでに存在しているのに急いでLLMを選ぶことがある（特に埋め込みの力を活用できる分類は大きな例だね）。でも、NERに関してはLLMが絶対的に優れた選択肢だよ（遅延やコストの要件があって、質を犠牲にせざるを得ない場合を除いて、今はLLMをデフォルトにすべきだと思う）。

└

トランスフォーマー以前のNLPがどれだけひどかったか、わかってないと思うよ。昔のエンティティ認識は非常に脆弱で、ほとんど機能しなかった。コンピュータビジョンも同様で、ディープラーニング以前の物体認識は白い背景と一定の角度が必要だったんだ。2014年のこのXKCDを覚えてる？ https://xkcd.com/1425/

└

でも、間接的な参照でエッジケースにぶつかると、エンティティ認識モデルはそれに対処できるほど賢くなくて、また苦い教訓を受けることになるんだよね。

全然そうは思わない。 > "すべてのLLM呼び出しに対して型付きI/Oを使え。Pydanticを使って、入出力を定義しろ。" 確かにDSPyとは関係ないし、基本的なことだよね。それに、この記事が世界で唯一の言語はPythonだと仮定している理由もわからない。 > "プロンプトをコードから分けろ。" プロンプトを別のものとして考えることを強制する。プロンプトが.mdや.json、.txtの拡張子のファイルに存在する必要は全くないし、.py/.ts/.go/...でもいいはずだよ。もし誰かがこれが良いアイデアだと思うシナリオを考えられるなら、教えてほしい。プロダクションで実行中のコードを編集するのと、どこが違うのか全然わからない。 > "コンポーザブルユニット。" すべてのLLM呼び出しはテスト可能、モック可能、チェイン可能であるべき。 > "抽象モデル呼び出し。" GPT-4をClaudeに置き換えるのが一行の変更で済むように。LiteLLMやai（Vercel）、実際に最も使われているパッケージはそうじゃないの？ダウンロード数をLangchainと比較してるけど、Langchainはここ10年で人気を得るのが最も難しかったパッケージだと思う。市場に出たのが早かっただけで、その後すぐにほとんどの人がその設計がひどいことに気づいて、今は昔の名前の認知度に頼っているだけで、実際に物事を進めたい人は上記の二つのような軽いものを使ってるよ。 > "早期に評価インフラを整えろ。" 初日から。変更が役立ったかどうかどうやってわかるの？確かに、ある程度はそうだね。プログラミング以外のほとんどのことは、LLMが実際の価値を提供する場面では非常に非決定的で、正解がない。まさにそれが彼らの提供するものだよ。LLMがその質を判断できないものもたくさんある。基本的な評価があるのは役立つけど、開発にかかる時間がそれに見合わないこともある。だけど、何よりも…この投稿のコメントは、DSPyの最大の差別化要因がプロンプトの最適化だってすぐに明らかにしてるよね。それなのにこの記事はそれに触れてないの？変だね。

└

"この記事全体が世界で唯一の言語はPythonだと仮定している。" これも私の意見だわ。うちの会社は最近Dspyを使い始めたけど、なんと、Python用に新しいリポジトリを立ち上げなきゃいけなかったんだ。だって、うちのコードの大半はPythonじゃないから。

└

これらのことはすべて基本的なことだと思うけど、多くの会社で実装やサポートが不十分なのは見て取れる。言いたいのは、ここには重要なパターンがあって、それを理解した上でAIシステムを構築するのが理にかなってるってこと（Dspyを使うかどうかは別としてね） :)

└

私の経験では、モデルやプロバイダーごとの挙動の違いが結構あるから、「ワンラインスワップ」のアイデアはシンプルなケースにしか当てはまらないと思う。でも、プロンプトのライフサイクルはコードと同じだね。今のところ、テキストテンプレートをコードと一緒にチェックインして使ってる（ハンドルバーズだけど、あんまり関係ないかな）。テンプレート名やコンテキストデータ、出力スキーマ、ターゲットモデルを入力として受け取るラッパーを使って、無視してもいい挙動の違いを内部でカバーしてる。ほかの実践者がどうしてるのか気になるな。

└

確かに、DSPyとは関係ないし、完全に当たり前のことだけど。賛成だけど、静的型付けに反対する人がどれだけいるか驚くよ。少なくとも3回はそういうことがあって、いつもお決まりのセリフが出てくるんだ。「早いから」、「テストがあればいいじゃん」、「YOLOポリモーフィズムは素晴らしい」、「GoogleがPythonを書くから大丈夫」とかね。文化的なものかもしれないけど、いつも特定のPythonやECMAScriptの開発者たちがこういう議論をしてる気がする。タイプヒントやTypeScriptが注目されてるのは嬉しいな。私はこの議論の反対側にいるから。LLMのコーディングワークフローの普及は、型がモデルにとって貴重なローカルコンテキストを提供するから、採用を加速させたんじゃないかな。

└

なぜこの記事全体が世界で唯一の言語はPythonだと仮定しているのかわからない https://github.com/ax-llm/ax （もしあなたがTypeScriptの世界にいるなら）

└

一度DSPyを試してみたんだけど、すごく良いと思ってプロンプト最適化に挑戦したんだ。評価を何十ドルかかけて実行したけど、毎回改善がなかった。何度も評価を実行したけど（詳細は今は覚えてないけど、去年のこと）、変化はなかった。きっと使い方を間違えてたんだろうけど、間違えやすいのは良くないよね。

https://www.tensorzero.com/docs は似たような抽象化があるけど、Pythonを必要とせず、フレームワークや言語にコミットする必要もない。オンボーディングはかなり難しいけど、同じ問題をより良く解決して、モデルやプロンプトの変更を評価するのがずっと簡単になるよ。

└

これ、前に見たことある！個人的には外部DSLがあまり好きじゃないんだ。一般的に複雑さを引き起こすと思うから、あまり価値がないと思ってスキップしちゃった。それがBAMLに対しても「まあまあ」な理由だね。

└

そうそう、彼らがプロンプトをパラメータから切り離してるのには感心したよ！

記事が大好き！5段階目までの過程がまさにその通りだったから！全体の流れや旅を見せてくれてありがとう！DSPyの問題は、彼らが「全体のプロダクト」という概念を知らないことだと思う。https://en.wikipedia.org/wiki/Whole_product を見て、https://mastra.ai/ と https://www.copilotkit.ai/ のページがどれだけ魅力的か見てみて。会社は製品そのものだけでなく、製品の周りのすべてのものを売っている＝「全体のプロダクト」。開発者ツールでも、ドキュメントがプロダクトという似たような概念があるよね。私もフルスタックのJavaScriptエンジニアで、Pythonは使ってない。ドキュメントには通常、上部に言語の切り替えがあるよね。Stripe.comはドキュメントと開発者体験で有名だよ：https://docs.stripe.com/search#examples。他の優れたプロダクトを研究して、インスピレーションを得たり、自分のプロダクトに関連するベストな特徴をコピーするのは素晴らしいことだよ。

└

「全体のプロダクト」というアイデアはすごく納得できる。これが普及の大きな障壁になってることが多いと思う！

記事はDSPyとLangChainの月間ダウンロード数の比較から始まって、その後はDSPyを基本的なインフラと比較してるけど、正直言ってそれはどの成熟度の低いセットアップでも大したことじゃないよね。DSPyのコアバリューはオプティマイザーにあるのかな？でも、記事ではそれについて重要なことには触れてない。どうやって動くの？自分のプロダクションにどう統合すればいいの？普通のユースケースにとって価値あるの？リトライを追加するのは問題じゃないけど、AIコントロールプレーンを作って維持するのは大変だよ。LangChainは可観測性、オンライン・オフライン評価、プロンプトエンジニアリング、デプロイなど、いろんなサービスを提供してるし。

└

コメントでこれを言ってる人がたくさんいるのが見えるね :) 個人的には、これがDspyの「本質」を見逃してると思う。Dspyはコードを書きやすくして最適化を促進するけど、これはDspyに特有のことじゃない。正しいパターンを適用すれば同じメリットが得られるし。実際、みんなが無意識に実装してるパターンだと思うし、Dspyをもう少し理解すれば、より良い実装ができると思うよ :)

DSPy大好き！でも、LLMに特化してるせいでPython側がちょっと awkward で weird になってるのが難点だね。この予測をしておくよ：これは明らかに基本原則から作られていて、そのアイデアはフレームワーク自体よりも長生きすると思う。

└

同意！そして、他の多くのフレームワークでもこの原則が現れて、みんなの生活が少しでも簡単になることを願ってる。