プロンプトエンジニアリング実践編：テクニックからメソドロジーへ

17回目のテスト結果が出た。

同じプロンプト——「このコードのパフォーマンスのボトルネックを分析して、最適化案を出してください」。月曜の午前、Claude は詳しく専門的に答えてくれたのに、金曜の午後には中身のない当たり障りのない答えを返してきた。別のモデルを試すと、ChatGPT はコードを勝手に書き換えてしまい、変更が必要かどうかも聞かず、なぜ変えるのかの説明もなかった。

プロンプトの効果はいつも「まあまあ」と「全然ダメ」のあいだを行ったり来たりする。AI 支援のコーディングや Agent アプリの構築をしていると、この不安定さは本当に頭が痛い。後になって一つの問題に気づいた。ずっと断片的なテクニックをつなぎ合わせてプロンプトを書いていただけで、本当のメソドロジーを築こうとは一度も考えていなかったのだ。

この記事は、まさにこの点をはっきりさせたいと思って書いている。「いくつかのテクニックを知っている」から「体系的なメソドロジーを身につけている」へとレベルアップするために、3層のプロンプト技術フレームワーク、思考連鎖と ReAct の原理、自動最適化の強力なツールである DSPy、そして Claude と ChatGPT でそれぞれどう違うプロンプトを書くべきかを語る。最後に、実践的な評価手法も共有する——プロンプトの効果が良いか分からなければ、最適化の議論はただの手探りにすぎない。

なぜ「テクニック」から「メソドロジー」へ進む必要があるのか

こんな「テクニック」を聞いたことがあるかもしれない。AI に「ステップごとに考えて」と言う、いくつか例を加えて真似させる、役割を設定して「あなたは専門家です」と言う……こうしたテクニックは確かに役立つが、問題は——効果があまりに不安定なことだ。

経験頼みの限界

2023年から2024年にかけて、ほとんどのプロンプト技術は経験頼みだった。経験頼みとはどういうことか。要するに「試してみる」ということだ——いくつか言葉を変え、走らせてみて、うまくいけば使い、ダメならまた変える。このやり方にはいくつかの明確な痛点がある。

効果が予測できない。同じプロンプトでも、モデルを変えると効かなくなることがある。同じモデルでも、異なる時間帯に呼び出すと出力品質がかなり違うこともある。多くの人（私自身を含めて）が何時間もかけてプロンプトを調整した結果、翌日には昨日の良かったバージョンがまた使えなくなっている、という場面を何度も見てきた。

再現や継承が難しい。とても良いプロンプトを調整できても、同僚が使うと効果が違う。なぜか。あなたのプロンプトには、自分でも意識していない文脈が暗に含まれているからだ——たとえば以前そのモデルとどんな話をしたか、あなたの書き方の癖など。こうしたものはドキュメントに書き起こせないので、他人には再現できない。

評価基準が欠けている。あるプロンプトは結局のところ良いのか悪いのか。多くの場合、感覚に頼るしかない。「今回の出力は悪くなさそう」——こんな判断はあまりに主観的だ。定量的な指標がなければ、体系的に最適化することはできない。

なかなか興味深いデータがある。ある金融テック企業は、体系的なプロンプト手法（彼らは「3C 公式」——Context、Constraint、Content と呼んでいた）を使う前、初回理解の正答率はわずか61%だった。体系的なフレームワークを採用した後、この数字は89%まで上がった。これは小さな改善ではなく、質的な飛躍だ。

2025〜2026年の転換

2025年から、プロンプトエンジニアリングは一つの転換を経験しつつある——「手作業の調整」から「体系的なエンジニアリング」へ。この転換には3つの重要なブレークスルーがある。

モジュール化設計。プロンプトを再利用可能なコンポーネントに分解し、コードを書くように組み立てる。毎回ゼロから長いプロンプトを書く必要はなく、いくつかの標準モジュールを組み合わせる。このやり方の利点は、コンポーネントを個別にテスト・最適化でき、全体の安定性が大きく高まることだ。

自動化最適化。フレームワークがプロンプトの最適化を手伝ってくれるようになり、手作業で調整する必要がなくなる。DSPy はこの分野で最も代表的なフレームワークだ——タスクと評価基準を定義しておけば、自動で反復して最適なプロンプト構成を見つけてくれる。この思想の核心は「Programming, not prompting」だ。

標準化された評価。定量指標とテストフレームワークができたことで、プロンプトの効果を客観的に測れるようになった。DeepEval や Promptfoo といったツールは評価の観点を提供している——正確性、一貫性、安全性、コスト効率。評価はもう感覚ではなく、データを見る作業になった。

正直に言うと、この3つのことが私の仕事の仕方を根本から変えた。以前のプロンプト調整は「運任せ」だったが、今ではもっとエンジニアリングに近い——設計があり、テストがあり、反復があり、データの裏付けがある。これこそが「テクニック」から「メソドロジー」への核心的な転換だ。

3層のプロンプト技術フレームワーク

プロンプト技術を3層に分けて理解すると、ずっとすっきりする。基礎層、推論層、システム層——それぞれが異なるタイプの問題を解決する。

基礎層：モデルに言葉を理解させる

この層の技術は最も基本的な問題を解決する。どうやってモデルに欲しいものを出力させるか、だ。

Zero-shot、ゼロショットプロンプティングは、例を一切与えず、直接モデルにタスクを完了させる。たとえば：

请解释什么是微服务架构。

このやり方はシンプルで直接的で、簡単なタスクや常識的な問題に向いている。ただし複雑なタスクや特定のフォーマットの出力が必要な場合、Zero-shot の効果はしばしば不安定になる。

Few-shot、フューショットプロンプティングは、モデルに2〜5個の例を与えて学習させる。たとえば、少し活発な文体で製品説明を書いてもらいたいとき：

请根据以下示例风格，为新产品写描述：

示例1：
产品：无线蓝牙耳机
描述：戴在耳朵上的小宇宙，音质清晰得像在现场听演唱会，续航给力到能陪你飞一趟跨国航班。

示例2：
产品：便携咖啡机
描述：把咖啡馆装进背包，随时随地来一杯手冲精品，咖啡渣都能精准控制。

现在请为"智能保温杯"写一个产品描述。

モデルは例の文体を真似て書いてくれる。Few-shot のポイントは、例が期待する出力の文体と一致していること。数は多くなくていい（2〜5個で十分）が、質が高いことが重要だ。

Role Prompting、ロールプロンプティングは、モデルに身分を設定する。このやり方は出力の文体と専門性のレベルを制約できる：

你是一位有10年经验的后端架构师，擅长性能优化和系统设计。
请分析以下代码的性能问题，指出具体瓶颈并给出优化建议。
代码：[粘贴代码]

役割を設定すると、モデルはより専門的な視点から考える傾向になり、出力もより構造化される。ただし役割設定は具体的に——「あなたは専門家です」では漠然としすぎる。どの分野の専門家で、どんな経験があるのかをはっきり言うほうがいい。

構造化出力は、モデルに特定のフォーマット（JSON、Markdown、表など）での出力を求める。このテクニックはデータ抽出や下流システムとの連携で特に役立つ：

请从以下文本中提取产品信息，以JSON格式输出：
{
  "product_name": "产品名称",
  "price": "价格",
  "features": ["特性列表"]
}

文本：[粘贴文本]

構造化の制約は出力の使い勝手を大きく高め、後続の処理の手間を減らせる。

推論層：モデルに「考えさせる」

この層の技術は、モデルが言葉を理解するだけでなく、複雑な推論を行えるようにする。

Chain-of-Thought (CoT)、思考連鎖は、モデルに推論過程を示させる。この技術の核心は、モデルに直接答えを出させず、まずどう考えたのかをはっきり言わせることだ。

2022年に Wei らが発表した論文は、CoT が複雑な推論タスクの正答率を大きく高められることを証明した。原理はかなりシンプルだ——複雑な問題は多段階の推論を必要とするので、その手順を書き出させることは、モデルに「思考のバッファ」を与えるようなもので、間違いにくくなる。

最もシンプルな CoT の使い方は、プロンプトの末尾に一文加えることだ：

请一步步思考这个问题，然后给出答案。

あるいは Few-shot CoT で、推論過程付きの例をモデルに見せる：

问题：小明有5个苹果，给了小红2个，又从树上摘了3个。现在小明有多少苹果？
推理过程：小明开始有5个苹果。给了小红2个后，剩下5-2=3个。从树上摘了3个后，有3+3=6个。
答案：6个苹果。

现在请用同样的方式解决：一个篮子里有12颗草莓，小明吃了4颗，小红又放进篮子6颗。篮子里现在有多少草莓？

ReAct、推論＋行動のループは、モデルに考えながら操作を実行させる。このフレームワークの流れは、Thought（次の一手を考える）→ Action（行動を実行する）→ Observation（結果を観察する）→ 再び考える、というものだ。外部ツールの呼び出しや情報検索が必要な場面に特に向いている。

你是一个能够搜索信息的助手。请用以下格式回答问题：

Thought: [当前需要做什么]
Action: search("[搜索内容]")
Observation: [搜索结果]
... (循环直到找到答案)
Final Answer: [最终答案]

问题：2024年奥斯卡最佳影片是哪部电影？

ReAct は Agent 開発で特に重要だ——Agent の核心はまさに「思考-行動-フィードバック」のループであり、ReAct はその標準テンプレートを提供する。

Self-Consistency、自己整合性は、モデルに同じ問題を複数回推論させ、投票で最も信頼できる答えを選ぶ。高い正確度が求められる場面で役立つが、コストは比較的高くなる（モデルを複数回呼び出す必要がある）。

Tree of Thoughts (ToT)、思考の木は、モデルに複数の推論経路を探索させ、最適な一本を選ばせる。創造的な案の生成や戦略立案など、複雑な意思決定の問題に向いている。

システム層：エンジニアリング化されたプロンプト管理

この層は単一の技術ではなく、プロンプト管理を一つのエンジニアリング体系にすることだ。

モジュール化プロンプト。複雑なプロンプトを複数の再利用可能なモジュールに分解する。たとえば Agent のプロンプトは、役割設定モジュール、タスク定義モジュール、出力制約モジュール、ツール呼び出しモジュールに分けられる。各モジュールを独立して管理し、組み合わせるときに柔軟に構成する。

自動化最適化。DSPy のようなフレームワークを使えば、手作業でプロンプトのパラメータを調整する必要がない。タスクのシグネチャと評価指標を定義すれば、フレームワークが自動で反復・最適化する。これは後で詳しく説明する。

標準化された評価。評価体系を築く。テストセットを用意し、評価指標を定義し、バッチテストを走らせ、反復ごとのスコアの変化を記録する。こうすればプロンプト最適化にデータの裏付けができ、感覚頼みではなくなる。

3層フレームワークの役立つ点は、判断を助けてくれることだ。今の問題はどの層に属するのか、どの技術で解決すべきか。簡単なタスクは基礎層、複雑な推論は推論層、システムの構築はシステム層を使う。

Chain-of-Thought 思考連鎖の徹底解説

思考連鎖というこの技術は、単独で取り上げて語る価値がある。現時点で最も成熟した推論強化技術であり、しかも使うハードルが高くない——複雑なフレームワークのコードを書く必要はなく、プロンプトに数文加えるだけでいい。

Zero-shot CoT vs Few-shot CoT

2つの使い方には、それぞれ向いた場面がある。

Zero-shot CoTは、例を加えず、誘導文を一文加えるだけ。最も有名なのはこの一文だ：

Let's think step by step.

あるいは中国語版：

请一步步思考这个问题。

このやり方はシンプルで低コストで、ほとんどの場面に向いている。研究によれば、この一文を加えるだけでも、複雑な推論タスクの正答率は20〜40%向上する。

Few-shot CoTは、推論過程付きの例を加える。例には「問題→推論過程→答え」のフォーマットを完全に示す必要がある：

问题：一个商店进货100件商品，成本每件20元。第一天卖出30件，售价35元。第二天卖出50件，售价30元。第三天剩余商品降价清仓，售价15元全部卖出。总利润是多少？

推理过程：
1. 计算总成本：100件 × 20元 = 2000元
2. 第一天收入：30件 × 35元 = 1050元
3. 第二天收入：50件 × 30元 = 1500元
4. 第三天剩余：100-30-50=20件，收入：20件 × 15元 = 300元
5. 总收入：1050+1500+300 = 2850元
6. 总利润：2850-2000 = 850元

答案：850元

现在请用同样的方式解决：
问题：某公司有员工200人，平均月薪8000元。年初裁员30人，裁员补偿每人2个月工资。裁员后招聘新员工50人，试用期月薪6000元，试用期3个月。问这一年公司薪酬支出变化是多少？

Few-shot CoT の利点は、モデルを特定の推論フォーマットと思考方法に誘導できることだ。ただし質の高い例を書くのに時間をかける必要がある——例の出来が悪いと、かえってモデルを誤った方向に導いてしまう。

どちらをいつ使うか？

• タスクが簡単で、推論経路が明確：Zero-shot CoT を使い、一文の誘導で十分
• タスクが複雑で、特定の推論フォーマットが必要：Few-shot CoT を使い、良い例をいくつか与える
• モデルの能力が高い（Claude 4 など）：Zero-shot CoT でたいてい十分
• モデルの能力が並みで、タスクの精度要求が高い：Few-shot CoT のほうが安定する

CoT が向いている場面

すべてのタスクに CoT が必要なわけではない。最も向いているのは次のような場面だ。

数学的推論と論理分析。この種のタスクは多段階の計算や論理の積み重ねが必要で、CoT を使えばモデルがステップを飛ばしたり漏らしたりしなくなる。

# 不用 CoT 的输出可能：
"答案是850元。"（直接跳到结果，中间可能算错了）

# 用 CoT 的输出：
"让我一步步计算..."
然后详细展示每一步。

多段階のタスク計画。たとえばモデルにプロジェクト計画を書いてもらう、システムアーキテクチャを設計してもらう、といった場合。CoT を使えば、モデルはまずタスクを分解し、それから段階的に展開できる。

コード生成における要件分析。モデルにまず要件を分析させ、案を設計させ、それからコードを書かせる。直接コードを吐き出させるのではなく。

请按以下步骤帮我实现一个用户认证系统：

步骤1：分析需求，列出核心功能点
步骤2：设计数据模型和接口
步骤3：给出具体实现代码
步骤4：说明测试方案

需求：[你的需求描述]

CoT のいくつかの変種

Auto-CoT、推論連鎖の自動生成。原理は、モデル自身に例の推論過程を生成させ、それを Few-shot の例として使うことだ。こうすれば手作業で例を書く手間を省ける。ただし Auto-CoT の品質は、モデルが最初に推論過程を生成する品質に左右される——最初の生成が間違っていると、その後の推論も連鎖的に間違ってしまう。

CoD（Chain of Debate）、議論連鎖。2つのモデルの役割に同じ問題を議論させ、互いの推論に異議を唱え合い、最後に総合して答えを導く。このやり方は複雑な問題やオープンな問題で効果が高いが、コストが高く時間もかかる。

CoT 使用時の注意点

私がハマったいくつかの落とし穴を挙げておく。

過度に推論を強制しない。簡単な問題に CoT は不要だ。たとえば「北京の人口はどれくらい」と聞くのに CoT を加えると、かえって出力が冗長になり、推論を誤ることさえある。判断基準は、タスクが多段階の推論を必要とするか、だ。

例はタスクと一致させる。与えた Few-shot の例が数学問題なのに、タスクが実は論理推論だった場合、モデルは数学的推論のやり方で論理問題を解こうとするかもしれない——効果は良くない。例のタイプはタスクと一致させること。

推論ステップは長すぎないように。CoT は正答率を高められるが、推論過程が長すぎると（たとえば十数ステップ）、途中で間違える可能性がある。特に複雑な問題に出くわしたら、段階に分けて処理することを検討するとよい。まずモデルに問題を分解させ、それから各サブ問題を別々に処理する。

総じて、CoT は最も実用的な推論強化技術だ。2つの使い方（Zero-shot と Few-shot）を身につけ、いつ必要でいつ不要かをはっきり判断できれば、プロンプトの効果は目に見えて向上する。

ReAct フレームワーク：推論と行動の結合

ReAct という名前は Reasoning + Acting の略だ。思考と行動を結びつけ、モデルが動的にツールを呼び出し、情報を取得し、意思決定を行えるようにする。CoT がモデルに「しっかり考えさせる」ものなら、ReAct はモデルに「考えながら手を動かさせる」ものだ。

Thought → Action → Observation のループ

ReAct の核心は一つのループ構造だ：

Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → ...

各ループが問題の解決を前進させる。検索強化型の質問応答の例を挙げよう：

任务：查询2024年诺贝尔物理学奖得主的研究领域。

模型执行过程：

Thought: 我需要先查2024年诺贝尔物理学奖得主是谁。
Action: search("2024 Nobel Prize in Physics winners")
Observation: [搜索结果] 2024年诺贝尔物理学奖授予John Hopfield和Geoffrey Hinton，表彰他们在人工神经网络领域的贡献。

Thought: 现我知道了得主是谁，需要进一步查他们的研究领域。
Action: search("John Hopfield research field")
Observation: [搜索结果] John Hopfield是物理学家，提出Hopfield网络模型...

Thought: 我已经获得了足够信息，可以回答问题了。
Final Answer: 2024年诺贝尔物理学奖得主John Hopfield和Geoffrey Hinton的研究领域是人工神经网络...

このループの仕組みにより、モデルは推論の過程で「情報を補える」——知らないことに出くわしても、当てずっぽうではなく、自ら調べに行く。この点が CoT との違いをはっきり示している。CoT はモデル内部の知識しか使わないが、ReAct は外部ツールを呼び出して新しい情報を取得できる。

ReAct vs CoT：重要な違い

観点	CoT	ReAct
情報源	モデル内部の知識	内部知識 ＋ 外部ツール
推論方式	純粋な思考	思考 ＋ 行動の交替
向いた場面	十分な情報がすでにある	検索やツール呼び出しが必要
実装の複雑さ	シンプル（プロンプトの変更）	複雑（ツール統合が必要）
コスト	単回呼び出し	複数回呼び出しの可能性

CoT はモデルがすでに十分な知識を持っている場面に向いている——たとえば数学的推論や論理分析。ReAct はリアルタイム情報が必要な場面に向いている——たとえば現在の出来事への回答、データベースの照会、API の呼び出し。

ReAct のプロンプト構造

標準的な ReAct プロンプトには、次のいくつかの部分が含まれる：

你是一个能够使用工具的智能助手。请用以下格式完成任务：

可用工具：
- search(query): 搜索互联网获取信息
- database_query(sql): 查询数据库
- calculate(expression): 执行数学计算

格式：
Thought: [你的思考过程，分析当前需要做什么]
Action: [工具名称和参数，如 search("查询内容")]
Observation: [工具执行结果，会自动填入]
... (可以多轮 Thought-Action-Observation)
Final Answer: [最终答案]

开始！

任务：[你的具体任务]

重要なポイント：

利用可能なツールを定義する。モデルにどんなツールが使えるか、どう呼び出すかを知らせる。ツールの定義は具体的に、名前、パラメータの形式、戻り値の型を含める。

出力フォーマットを規定する。Thought、Action、Observation のフォーマットを明確にする。そうすればあなたのシステムがモデルの出力を解析し、ツール呼び出しを実行し、結果をモデルに戻せる。

終了条件。モデルが十分な情報を得たら Final Answer を出力するようにし、無限ループに陥らないようにする。

Agent 開発における ReAct の応用

ReAct は現代の Agent アーキテクチャの基本パターンの一つだ。AI Agent を構築しているなら——カスタマーサポートボットでも、データ分析アシスタントでも、自動化運用システムでも——おそらく ReAct の考え方を使うことになる。

実際のプロジェクトでは、ReAct の実装は上のシンプルなプロンプトよりずっと複雑だ。次のものが必要になる：

1. ツール登録システム：ツールのインターフェース、パラメータ検証、権限制御を定義する
2. 実行エンジン：モデルの Action 出力を解析し、対応するツールを呼び出し、結果を整形して戻す
3. ループ制御：最大ループ回数やタイムアウトを設定し、デッドループを防ぐ
4. エラー処理：ツール呼び出しが失敗したら、何が起きたかをモデルに伝え、戦略を調整させる

ReAct 使用時の注意点

モデルが十分強いこと。ReAct はモデルが複数ターンの対話で文脈を保持し、妥当な行動の意思決定を下すことを必要とする。弱すぎるモデルは、むやみにツールを呼び出したり、タスクの目標から外れたりしやすい。Claude や GPT-4 系列のモデルは ReAct の効果が比較的良い。

ツールの定義は明確に。あるツールが何をできるかをモデルが知らなければ、呼び出さなかったり、呼び出し方を間違えたりするかもしれない。各ツールの説明は、API ドキュメントを書くように詳しくする。

ツールに過度に依存しない。一部の情報はモデル内部にあり、毎回ツールを呼び出す必要はない。プロンプトに判断ロジックを加えるとよい。「内部知識で十分答えられるなら、ツールを呼び出さず直接 Final Answer を出してください」。

コスト管理。ReAct は複数回のツール呼び出しを引き起こす可能性があり、API 料金が比較的高くなる。複雑なタスクには ReAct を、簡単なタスクには通常のプロンプトを使うほうが割に合う。

ReAct はプロンプトを「静的なスクリプト」から「動的なプログラム」へと変え、AI が本当に手を動かして問題を解決できるようにした。これは「対話型 AI」から「行動型 AI」への重要な一歩だ。

DSPy：プロンプトを自動最適化する

ここまで話した CoT や ReAct は、いずれも手作業でプロンプトを書く必要があった。だが一つだけ違うフレームワークがある——DSPy。その核心思想は「Programming, not prompting」だ。つまり、プログラミングの方法でタスクを定義し、フレームワークに自動でプロンプトを生成・最適化させる、ということだ。

DSPy とは何か

DSPy は Stanford NLP グループが開発したフレームワークだ。プロンプトエンジニアリングをプログラミングパラダイムに変えた——タスクの入出力構造（Signature）を定義し、適切なモジュール（Module）を選び、最適化器（Optimizer）を設定すると、フレームワークが自動で反復して最適なプロンプト構成を見つける。

この考え方の利点：

より信頼できる。手書きのプロンプトは漏れがあったり、フォーマットが合わなかったり、制約が不明確だったりしやすい。DSPy の宣言的な定義はより厳密だ。

より保守しやすい。プロンプトがコードになり、バージョン管理、ユニットテスト、継続的な反復が可能になる。

より移植しやすい。モデルを変えるときにプロンプトを調整し直す必要がない——フレームワークが新しいモデルの特性に自動で適応する。

DSPy の中心コンポーネント

Signature（タスクシグネチャ）：タスクの入出力構造を定義する。

import dspy

class QuestionAnswer(dspy.Signature):
    """回答问题，给出详细解释"""
    question = dspy.InputField(desc="用户的问题")
    answer = dspy.OutputField(desc="详细的答案，包含推理过程")

Signature は関数のインターフェース定義のようなもの——入力が何か、出力が何か、各フィールドにどんな要件があるかを示す。具体的なプロンプトのテキストを書く必要はなく、構造だけを定義する。

Module（モジュール）：特定のプロンプト技術をカプセル化した再利用可能なコンポーネント。

# 最基础的模块：直接预测
qa_basic = dspy.Predict(QuestionAnswer)

# 加思维链的模块
qa_cot = dspy.ChainOfThought(QuestionAnswer)

# 加 ReAct 的模块（需要配置工具）
qa_react = dspy.ReAct(QuestionAnswer, tools=[search_tool, calculator_tool])

モジュールはプロンプト技術をカプセル化している。CoT を使いたければ ChainOfThought モジュールを選べばよく、「ステップごとに考えてください」のような誘導文を自分で書く必要はない。フレームワークがモジュールのタイプに応じて対応するプロンプトを自動生成する。

Optimizer（最適化器）：プロンプト構成を自動で最適化する。

from dspy.teleprompt import BootstrapFewShot

# 准备训练数据
trainset = [
    dspy.Example(question="什么是递归？", answer="递归是函数调用自身..."),
    dspy.Example(question="解释冒泡排序", answer="冒泡排序通过相邻元素比较..."),
]

# 配置优化器
optimizer = BootstrapFewShot(max_bootstrapped_demos=3)

# 优化模块
qa_optimized = optimizer.compile(qa_cot, trainset=trainset)

最適化器は自動で Few-shot の例を生成し、プロンプト構造を調整し、反復して最適な構成を見つける。学習データと評価基準を与えれば、パラメータを調整してくれる——機械学習の訓練過程に少し似ているが、調整するのはモデルの重みではなくプロンプトだ。

完全な DSPy の例

プログラミングの質問に答えられる QA システムを書いてみよう：

import dspy

# 1. 定义 Signature
class CodeQA(dspy.Signature):
    """回答编程相关问题，给出清晰解释和示例"""
    question = dspy.InputField(desc="编程相关问题")
    answer = dspy.OutputField(desc="详细答案，包含概念解释和代码示例")

# 2. 配置语言模型
lm = dspy.LM("claude-3-5-sonnet-20241022", api_key="your_key")
dspy.settings.configure(lm=lm)

# 3. 创建模块（用 ChainOfThought 加推理能力）
qa = dspy.ChainOfThought(CodeQA)

# 4. 直接调用
result = qa(question="Python 里怎么实现装饰器？")
print(result.answer)

この例では、プロンプトのテキストを一切書いていない。ChainOfThought モジュールが思考連鎖の誘導付きプロンプトを自動生成した。出力される answer には推論過程と詳しい説明が含まれる。

効果を最適化したいなら、学習データと最適化器を加える：

# 5. 准备训练数据
train_examples = [
    dspy.Example(
        question="什么是 REST API？",
        answer="REST API 是一种网络应用程序接口设计风格..."
    ),
    dspy.Example(
        question="解释 Git 的分支概念",
        answer="Git 分支允许你从主线开发中分离出独立的工作线..."
    ),
]

# 6. 定义评估函数
def evaluate_answer(example, pred):
    """检查答案是否包含关键词、长度是否合理"""
    keywords = example.question.lower().split()
    has_keywords = sum(1 for k in keywords if k in pred.answer.lower()) >= 2
    length_ok = len(pred.answer) > 100
    return has_keywords and length_ok

# 7. 优化
optimizer = BootstrapFewShot(metric=evaluate_answer, max_bootstrapped_demos=4)
qa_optimized = optimizer.compile(qa, trainset=train_examples)

# 8. 用优化后的模块
result = qa_optimized(question="Python 里怎么实现装饰器？")

最適化器は学習データに基づいて、自動で Few-shot の例を生成し、プロンプトのフォーマットを調整し、出力品質を高める。この一連の過程に手作業のプロンプト調整は不要だ。

いつ DSPy を使い、いつ手書きでプロンプトを書くか

DSPy は万能ではない。フレームワークに向いた場面もあれば、手書きのほうが適した場面もある。

DSPy に向いた場面：

• AI アプリシステムの構築（同じ種類のプロンプトを何度も再利用する必要がある）
• タスク構造が明確（入出力を標準化して定義できる）
• 学習データがある（最適化に使える）
• モデル間の移植が必要（モデルによって挙動が異なる可能性があり、フレームワークが自動で適応する）
• プロジェクトの複雑度が高い（プロンプトの数が多く、手作業の管理が煩雑）

手書きプロンプトに向いた場面：

• 単発の使用（一度書いて一度使うだけで、再利用は不要）
• タスク構造が曖昧（入出力を標準化しづらい）
• 学習データがない（最適化できない）
• 素早いプロトタイプ検証（速く試行錯誤したく、フレームワークの設定に時間をかけたくない）
• 簡単なタスク（Zero-shot で済むので、フレームワークを使う必要がない）

私の経験では、プロジェクト規模のアプリや長期的に保守が必要なシステムには、DSPy の投資対効果が高い。初期の設定に少し時間はかかるが、その後の反復効率は大きく向上する。一度きりのタスクや簡単な照会には、手書きでプロンプトを書くほうが直接的だ。

DSPy 使用時の注意点

評価指標が重要。最適化器はあなたの評価関数に依存する。評価基準が妥当でなければ、最適化の方向が間違うかもしれない。良い評価指標の設計に時間をかけること。

学習データの品質。BootstrapFewShot は学習データに基づいて例を生成する。データの品質が悪ければ、生成される例も悪く、かえって効果を損なう。

過度に最適化しない。最適化の反復回数が多ければ良いとは限らない。最適化器が学習データに「過学習」し、新しい問題ではかえって性能が下がることもある。妥当な反復回数の上限を設定すること。

DSPy はプロンプトエンジニアリングの新しい方向性を代表している——手作業の調整から自動化最適化へ。AI アプリを体系的に構築したい開発者にとって、これは身につける価値のあるツールだ。

Claude vs ChatGPT：差別化されたベストプラクティス

Claude と ChatGPT は、現時点で最も主流の2つの大規模モデルだ。多くの人がこう尋ねる。同じプロンプトなのに、なぜ2つのモデルの出力が違うのか。どう別々に最適化すればいいのか。ここでは両者の違いと、それぞれに合わせたベストプラクティスを語る。

モデル特性の比較

まず重要な違いから：

観点	Claude	ChatGPT（GPT-4系列）
コンテキスト長	200K tokens	128K tokens
構造化出力	優秀、XML/JSON を好む	良好、明確な書式制約が必要
推論スタイル	より厳密、ステップが明快	より柔軟、時に飛躍する
コード生成	品質が高く、説明が詳しい	品質が高く、創造性が強い
創造性	比較的保守的	より創造的で文体が多様
中国語表現	自然で流暢	自然で流暢
複数ターン対話	文脈保持能力が強い	文脈保持能力が強い

これらの違いは絶対的なものではなく、バージョンやタスクによって変わる。だが全体として、Claude は厳密な推論と構造化出力に寄っており、ChatGPT は柔軟な創造性と素早い応答に寄っている。

Claude のベストプラクティス

1. XML タグで構造化制約をする

Claude は XML タグのフォーマットの理解が特に良い。内容をタグで包むと、出力品質を高められる：

请分析以下代码的性能问题：

<code>
function processData(data) {
  let result = [];
  for (let i = 0; i &lt; data.length; i++) {
    result.push(transform(data[i]));
  }
  return result;
}
</code>

请用以下格式输出分析结果：

<analysis>
[性能问题分析]
</analysis>

<suggestions>
[优化建议]
</suggestions>

XML タグの利点は、入力内容と出力フォーマットをモデルにはっきり区別させられることだ。Claude はタグ構造に厳密に従って出力し、分析を提案に混ぜたりしない。

2. 役割 ＋ 制約 ＋ 例のパターン

Claude は役割設定と制約への応答が非常に忠実だ。完全なプロンプト構造はこうなる：

角色设定：
你是一位资深性能优化工程师，有8年Java后端经验。你擅长识别性能瓶颈并给出可落地的优化方案。

任务约束：
- 分析时要指出具体的性能瓶颈（不要泛泛地说"可以优化"）
- 建议要包含代码修改示例
- 如果某个优化有风险，要明确说明

输出示例：
<analysis>
问题：循环中频繁创建对象，可能导致内存压力。
位置：第3-5行的for循环。
</analysis>
<suggestions>
建议1：使用预分配数组大小。
代码：let result = new Array(data.length);
风险：无明显风险。
</suggestions>

现在请分析以下代码：
[粘贴你的代码]

この構造は Claude に、あなたが誰で、何をすべきで、出力がどんな見た目になるかを伝える。その出力はあなたの期待により近くなる。

3. 長いコンテキストを活かして詳細な分析をする

Claude の 200K コンテキストは、長い文書や複雑なコードの処理にとても向いている。完全なファイルをそのまま貼り付けても、途中で切れる心配がない：

请分析以下完整的代码文件，找出所有可能的性能问题：

完整代码：
<code>
[粘贴整个文件，几百行代码]
</code>

请按模块逐一分析，指出每个模块的性能问题和优化建议。

ChatGPT の 128K もほとんどの場面で十分だが、超長文書のときは Claude のほうが有利だ。

ChatGPT のベストプラクティス

1. 明確な出力フォーマット制約

ChatGPT は柔軟なので、出力フォーマットが変わることがある。明確に制約する必要がある：

请分析代码性能问题，输出格式必须如下：

## 性能问题分析
- 问题1：[具体描述]
- 问题2：[具体描述]

## 优化建议
| 问题 | 建议 | 代码示例 |
|-----|-----|---------|
| [问题1] | [建议] | [代码] |

代码：
[粘贴代码]

Markdown フォーマット（## 見出し、| 表）で出力を制約すると、ChatGPT は厳密に従う。

2. 温度パラメータを調整する

ChatGPT の temperature パラメータは出力の創造性に影響する。temperature = 0 はより決定的で一貫性が強く、temperature = 0.7〜1 はより創造的で多様性が高い。

# 确定性输出（适合代码生成、数据分析）
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0
)

# 创意性输出（适合文案写作、创意设计）
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.8
)

Claude API にも同様のパラメータ制御があるが、ChatGPT のほうが温度の効果がより顕著だ。

3. ステップごとに誘導する

ChatGPT はときどきステップを飛ばし、直接結果を出してしまう。複雑なタスクでは、ステップごとに誘導するとよい：

请帮我完成以下任务，分步骤进行：

步骤1：先列出代码的主要功能模块
步骤2：分析每个模块的性能特点
步骤3：找出性能瓶颈
步骤4：给出优化方案

请先完成步骤1。

モデルを一歩ずつ出力させるよう誘導すれば、ステップを飛ばして間違えるのを避けられる。

同じタスクの異なるプロンプトの書き方

例を挙げよう。ある文章から製品情報を抽出させるタスクだ。

Claude 版：

请从以下文本中提取产品信息：

<text>
[产品介绍文本]
</text>

输出格式：
<product_info>
<name>[产品名称]</name>
<price>[价格]</price>
<features>
<feature>[特性1]</feature>
<feature>[特性2]</feature>
</features>
</product_info>

ChatGPT 版：

请从文本中提取产品信息，输出JSON格式。

文本：
[产品介绍文本]

输出格式示例：
{
  "name": "产品名称",
  "price": "价格",
  "features": ["特性1", "特性2"]
}

必须严格遵循此JSON结构，不要添加其他字段。

両者の違い：Claude は XML を使うほうが安定し、ChatGPT は JSON ＋ 明確なフォーマット制約を使うほうが有効だ。

選択のアドバイス

• 厳密な推論や構造化出力が必要：Claude を優先
• 創造的な出力や素早いプロトタイプが必要：ChatGPT を優先
• 長い文書や完全なコードファイルを処理する：Claude を優先（200K コンテキスト）
• コード生成や技術的な質問応答：どちらも優秀で、スタイルが少し異なる
• コピーライティングやクリエイティブ設計：ChatGPT を優先（温度を上げる）

実際のプロジェクトでは、タスクのタイプに応じてモデルを選んだり、2つのモデルを同時に使って効果を比較したりできる。2つのモデルのプロンプトの書き方は、確かにそれぞれに合わせた最適化が必要だ——モデルの特性を取り違えると、効果が大きく違うことがある。

プロンプトの評価と反復のメソドロジー

ここまでの章で多くのプロンプト技術を語ってきた。だが一つ解決していない問題がある。あなたのプロンプトの効果が良いかどうか、どうやって知るのか。評価がなければ、最適化は群盲象を撫でるようなものだ。ここではプロンプトの評価体系と反復のメソドロジーを語る。

評価の観点：4つの中心指標

良いプロンプトは、4つの観点で基準に達している必要がある。

正確性。出力内容は正しいか。この観点が最も重要で、評価方法も最も難しい。客観的なタスク（数学計算、事実照会）なら、正確性の評価は比較的簡単だ——出力した答えと正解を比べる。主観的なタスク（創作、案の設計）では、正確性は「期待に合っているか」になり、評価はより複雑になる。

評価方法の例：

• 数学問題：計算結果と正解を比べる
• コード生成：コードを実行し、テストを通過するか確認する
• 質問応答：答えに正しい情報点が含まれているか確認する
• コピー：人手で採点する、または主要指標（長さ、キーワードのカバー）を比べる

一貫性。同じプロンプトを複数回呼び出して、出力品質は安定しているか。一貫性の悪いプロンプトは今日は使えても明日は効かなくなることがあり、本番環境には向かない。

評価方法：同じタスクを10回走らせ、出力品質のばらつきの範囲を集計する。ばらつきが大きすぎれば、一貫性に問題がある。

安全性。出力に有害なコンテンツ、プライバシー漏洩、偏見的な発言が含まれていないか。この観点は特定の場面（カスタマーサポート、コンテンツ審査など）で重要だ。

評価方法：センシティブワード検出やプライバシー情報検出のルールを設計する、または専用の安全評価ツールを使う。

コスト効率。プロンプトのトークン消費は妥当か。長すぎるプロンプトはコストが高く、短すぎるプロンプトは効果が悪い。バランス点を見つける必要がある。

評価方法：呼び出しごとのトークン数を記録し、平均コストを計算する。異なるプロンプトバージョンのコストパフォーマンスを比べる。

評価ツール

主流のプロンプト評価ツールをいくつか挙げる。

DeepEval。オープンソースのプロンプト評価フレームワークで、複数の評価指標（正確性、一貫性、関連性など）を提供する。バッチテストと自動評価に向いている。

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

metrics = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

evaluate(test_cases, metrics)

Promptfoo。CLI ツールで、プロンプトのバッチテスト、異なるモデルの出力比較、評価レポートの生成ができる。プロンプトの効果を素早く検証するのに向いている。

promptfoo eval --prompts my_prompt.txt --providers openai:gpt-4 --tests test_cases.yaml

OpenAI Evals。OpenAI 公式の評価フレームワークで、主にモデルの能力を評価するが、プロンプトテストにも使える。

これらのツールに共通する特徴：テストセットを定義 → バッチ実行 → 自動採点 → レポート生成。ツールを使うほうが手作業のテストよりずっと効率が高い。

A/B テストの手順

プロンプトを改善するとき、A/B テストは科学的な方法だ。手順はおおよそ次のとおり。

ステップ1：テストセットを用意する。典型的なタスクのサンプルを20〜50個集め、さまざまな場面をカバーする。テストセットは多様にし、簡単なタスクだけにしてはいけない。

ステップ2：評価指標を定義する。タスクのタイプに応じて指標を選ぶ。たとえば質問応答タスクなら「答えの正答率 ＋ 情報のカバー率」、コード生成なら「通過率 ＋ コード品質スコア」。

ステップ3：ベンチマークテストを実行する。現在のプロンプトでテストセットを一通り走らせ、各指標のスコアを記録する。このスコアが最適化の出発点になる。

ステップ4：改善版を設計する。ベンチマークテストの問題点に基づいて、プロンプトの改善案を設計する。たとえば正確性が低ければ CoT を加え、一貫性が悪ければより厳密なフォーマット制約を加える。

ステップ5：比較テスト。改善版で同じテストセットを走らせ、指標の変化を比べる。改善版のスコアが高ければ、新バージョンを採用する。

ステップ6：反復ループ。改善効果が明確でなければ、原因を分析し、次の改善案を設計する。基準に達するまで繰り返し反復する。

簡略版のテスト記録表：

バージョン	正確性	一貫性	Tokenコスト	主な改善点
v1	65%	ばらつき大(±20%)	850	ベンチマーク版
v2	78%	ばらつき中(±10%)	920	CoT誘導を追加
v3	82%	ばらつき小(±5%)	1050	Few-shot例を追加
v4	85%	ばらつき小(±3%)	1050	例の品質を最適化

改善のたびにデータを記録すること。そうすれば最適化の過程を追跡できる。

プロンプトのバージョン管理

プロンプトもコードであり、バージョン管理が必要だ。提案：

バージョン番号。各プロンプトバージョンに番号（v1, v2, v3…）を付け、変更の時期と主な変化を記録する。

変更記録。修正のたびに記録する。何を変えたか、なぜ変えたか、テスト結果はどうだったか。

## Prompt 版本记录

### v3 (2026-04-15)
改动：添加3个Few-shot示例，优化输出格式约束
原因：v2一致性测试波动较大，输出格式不稳定
测试：准确率从78%提升至82%，一致性波动从±10%降至±5%

### v2 (2026-04-10)
改动：添加CoT引导语"请一步步思考"
原因：v1准确率偏低，复杂推理任务出错多
测试：准确率从65%提升至78%

### v1 (2026-04-05)
原始版本，无特殊优化
测试：准确率65%，一致性波动±20%

保存方法。プロンプトファイルとテストデータを一緒に置くと追跡しやすい。Git で管理してもよいし、専用のプロンプト管理ツールを使ってもよい。

反復最適化の重要ポイント

一度に多くを変えない。改善のたびに調整する変数は1つだけにする。そうすればどの変更が有効だったか判断できる。たとえば CoT の追加と Few-shot の追加を同時にやらない——まず CoT を加えてテストし、それから Few-shot を加えてテストする。

コストの変化に注意する。正確性が上がっても、トークンコストが倍になっていることがある。コストパフォーマンスを天秤にかけること。正確性は高ければ高いほど良いわけではない。

失敗した試みを記録する。すべての変更が効果を高められるわけではない。失敗した試みも記録し、今後同じ過ちを繰り返さないようにする。

最適化の目標を設定する。無限に最適化しないこと。目標（たとえば正確性80%）を設定し、達したら反復を止める。過度な最適化は時間の無駄で、限界効用は逓減する。

評価と反復はプロンプトエンジニアリングの「締めくくり」の段階だ。評価がなければプロンプトが良いか分からず、反復がなければ継続的に改善できない。この2つの段階を加えてはじめて、プロンプトエンジニアリングは本当に完全なエンジニアリングのプロセスになる。

まとめ

ここまで多くを語ってきたが、核心は実は一つのことだ。プロンプトエンジニアリングは「オカルト」から「エンジニアリング」へと変わりつつある。

3層の技術フレームワークは、どの技術を使うべきかの判断を助けてくれる——基礎層は「モデルに理解させる」問題を、推論層は「モデルに考えさせる」問題を、システム層は「プロンプトを管理可能にする」問題を解決する。CoT と ReAct は現時点で最も実用的な推論強化技術であり、DSPy は自動化最適化の新しい方向性を代表している。Claude と ChatGPT の書き方はそれぞれに合わせた調整が必要だ——Claude には XML タグで制約し、ChatGPT には明確な書式 ＋ 温度パラメータで誘導する。評価体系はこのメソドロジー全体の最後のピースであり、評価がなければ科学的な最適化はない。

次にできることをいくつか挙げよう。

今あるプロンプトを見直す。3層フレームワークに照らして、あなたのプロンプトはどの層にあるか。明確な問題点（効果が不安定、コストが高すぎる、出力フォーマットが乱れる）はないか。

DSPy を一度試す。あなたのプロジェクトがフレームワーク化管理に向いているなら、シンプルな DSPy モジュールを一つ設定し、自動化最適化の効果を体感してみる。

自分の評価基準を築く。テストセットを一つ用意し、いくつかの重要指標を定義し、あなたのプロンプトにベンチマークテストをしてみる。データがあれば、最適化に方向ができる。

プロンプトエンジニアリングというものは、確かに繰り返しの練習が必要だ。だがメソドロジーがあれば、少なくとも「感覚で手探り」ではなくなる。この記事があなたの体系的な思考の枠組みを築く助けになればうれしい。質問があればぜひ交流しよう。

---

参考資料

• PromptingGuide.ai — プロンプトエンジニアリング公式ガイド
• DSPy Official — Stanford DSPy フレームワーク公式サイト
• Claude Prompt Engineering Best Practices — Anthropic 公式ドキュメント
• Chain-of-Thought Prompting Elicits Reasoning — Wei et al. 2022 論文
• A Systematic Survey of Prompt Engineering — 2025 系統的サーベイ