real_world_promptingで学ぶ実務プロンプトの書き方

Anthropicはanthropics/coursesというGitHubリポジトリで、実務レベルのプロンプト設計を学べる教材real_world_promptingを公開しています。医療記録の要約からカスタマーサポートボットまで、5本のノートブックで「動くけれど雑なプロンプト」を段階的に直していく過程を追えます。リポジトリは現在アーカイブされて読み取り専用で、最後のpushは2026年8月28日です。

最初に押さえたいのは、ノートブックのコードがそのままでは動かない点です。指定されているモデルが2本とも提供終了しているため、実行する前にモデル名の差し替えが要ります。

real_world_promptingとは何か

anthropics/coursesは5つのコースで構成されています。リポジトリ直下のREADMEが勧める学習順は次のとおりです。

1. Anthropic API fundamentals(SDKの基本、APIキーの取得など)
2. Prompt engineering interactive tutorial(プロンプト技法の入門)
3. Real world prompting(本記事が扱う教材)
4. Prompt evaluations(プロンプトの評価方法)
5. Tool use(ツール使用の実装)

real_world_promptingは3番目で、READMEは「2番目のチュートリアルを終えた経験者向け」と位置づけています。各レッスンは前のレッスンの内容を前提に進むため、最初のレッスンから順に読む構成です。単発の技法ではなく、複数の技法を組み合わせた長いプロンプトを組み立てる回になっています。

Google Vertex AI向けの版もあります。vertexブランチに同じ名前のディレクトリがあり、5本のノートブックが並んでいます。本記事はmasterブランチのAnthropic API版を対象にします。

ノートブックのモデルは提供終了済み

演習のコードを実行する前に、モデル名を確認する必要があります。ノートブックが指定するモデルは、レッスン2と4がclaude-3-sonnet-20240229、レッスン5がclaude-3-haiku-20240307です。リポジトリ直下のREADMEには「受講費用を抑えるため、最も低価格のClaude 3 Haikuを使う場面が多い」という注意書きもあります。

どちらもモデル廃止の一覧に載っていて、リクエストは通りません。

置き換えるのは主にmodel=の引数です。リポジトリはアーカイブ済みのため、修正のPRは送れません。手元にコピーして直す形になります。

実行環境と共通のコード

各ノートブックはPythonのanthropicパッケージとpython-dotenvを使い、.envに置いたAPIキーをAnthropic()クライアントに読み込む構成です。

pip install anthropic python-dotenv

from anthropic import Anthropic
from dotenv import load_dotenv
 
load_dotenv()
client = Anthropic()

このパターンはレッスン2・4・5で共通です。.envにAPIキーがないと、Anthropic()の初期化の時点でエラーになります。

レッスン1: 6つの基本プロンプト技法

01_prompting_recap.ipynbは、前段のチュートリアルで学んだ内容の振り返りです。冒頭でPrompt Generator(プロンプトの下書きを作ってくれるツール)に触れたあと、6つの技法を順に確認します。

• 明確で直接的な指示を書く(出力形式・長さ・スタイルを具体的に指定する)
• XMLタグでプロンプトを構造化する(指示・入力データ・例を区別する)
• 例を使う(望む出力形式や内容を実例で示す)
• Claudeに考えさせる(chain of thought。複雑な問題を段階的に分解させる)
• Claudeに役割を与える(回答の精度と口調を安定させる)
• 長いコンテキストを扱う

最後の技法には具体的な目安が付いています。長い資料を渡すのは3万トークン以上の場合を想定していて、資料を各XMLタグで囲み、長い資料をプロンプトの先頭に置いて指示や質問を後ろに回します。ノートブックは、資料が上にあるほうが指示の下にあるより性能が目に見えて上がりやすいと説明しています。この「長い入力は先頭」はレッスン4で実際に使われます。

レッスン2: 医療記録要約プロンプトを改善する型

患者の医療記録を渡して「要約してほしい」と頼むだけの単純な指示から始まるのが02_medical_prompt.ipynbの課題です。医師が翌日の診察に備えるための要約という設定で、5件の架空の記録を使います。最初のプロンプトでは、ある要約は長い段落、別の要約は箇条書きになり、中身の粒度も揃いません。

改善は次の順で積み重ねられます。

改善後は、5件すべてが指定した項目と順序の要約になります。ノートブックはさらに、同じプロンプトをJSON出力に切り替える例も示します。この切り替えの前に「JSONを確実に得る一番簡単な方法はツール使用機能で、それはtool_useコースで扱う」と断り書きがあります。プロンプトだけで形式を制御する場合とツール使用で制御する場合は別物で、このレッスンの目的は後者ではありません。

レッスン3: プロンプトエンジニアリングは反復設計である

03_prompt_engineering.ipynbは技法ではなく、改善のプロセスを扱います。冒頭でレッスン2を「技法をすべて盲目的に当てはめたプロンプト」と振り返り、技法を知るだけでは足りず、判断の枠組みが要ると述べています。

「基本的なプロンプト」との違いは、複雑さ・精度・反復的な改善・スケーラビリティの4点です。改善のサイクルは次の5段階で、テストの段階に具体的な見方が付いています。

1. 初期プロンプトの作成
2. テストと問題点の特定(正確性・一貫性・網羅性・指示への従順さの4指標で採点する)
3. 適切な技法の選定(根本原因の診断、解決策の調査、技法の選択の順)
4. 改善の実装(複数の変更は1つずつ入れて、効果を切り分ける)
5. 反復と改善(同じテストケースで再テストし、新たな問題が出ていないかも見る)

見落としやすいのは4と5です。改善を一度に入れずに1つずつ試すこと、直したあとに新しい問題が生まれていないかを確かめることが、手順として明記されています。

レッスン4: コールサマライザーで学ぶエッジケースの切り分け

04_call_summarizer.ipynbは、スマートホーム機器のサポート通話の記録を、対応品質の分析に使えるJSONにする演習です。短い通話、解決した中程度の通話、未解決の長い通話という3種類のサンプルでプロンプトを育てます。

最初の完成形が出力するJSONには、次の項目があります。

• status(要約できたかを示す値。この時点では常にCOMPLETE)
• summary(顧客の問題、解決内容、フォローアップの要否と内容)
• ambiguities(会話の曖昧な点の配列。なければ空)

指示には、顧客の個人情報(氏名・電話番号・メールアドレス)を含めないことと、各フィールドを100文字以内に収めることも入っています。ここまでの骨格は次のとおりです。

<transcript>
[通話記録]
</transcript>
 
<instructions>
- 一般的な指示とガイドライン
- 出力するJSON形式の説明
- データ不足(エッジケース)と判定する条件
<examples>
様々な入出力の例
</examples>
</instructions>
 
<thinking>タグで先に分析させ、その後<json>タグで結果を出力させる

通話記録は先頭に置かれます。レッスン1で確認した「長い資料は先頭」の使い方です。

ここからが本題です。ノートブックが想定するエッジケースは、接続が悪い通話、言語の壁がある通話、文字起こしが乱れた通話、感情的になった顧客の通話の4種です。実際に流すのは、言語が通じず音声も乱れた通話(1件)と、間違い電話の2つで、この段階のプロンプトに通すと、どれも中身のある要約が返ってきます。「顧客が理解できない言語(スペイン語)で話した」「音声が乱れて不明」といった内容がcustomerIssueに書かれ、statusはCOMPLETEのまま返ります。

ノートブックが選んだ対処は、要約できない通話を{"status": "INSUFFICIENT_DATA"}だけで返させ、後で人が見られるようにする方法です。判定基準は次のとおりです。

• やり取りが5回未満
• 顧客の問題が不明確
• 通話が乱れている、途中で切れている、または言語の壁がある

この基準と、要約できる通話・できない通話の入出力例を3パターン(フォローアップ不要で完結、フォローアップが必要で曖昧さを含む、データ不足)プロンプトに足すと、エッジケースが想定どおりに処理されます。

最後に「本番投入できる完成品ではなく、少数の目視テストに基づく出発点にすぎない」という注記があります。定量的な評価がまだ欠けているという趣旨で、次のPrompt evaluationsコースへの橋渡しです。

レッスン5: サポートボットでコンテキスト参照を抑える

05_customer_support_ai.ipynbは、架空の製品「AcmeOS」向けのチャットボット「Acme Assistant」を作る演習です。最初のプロンプトは、<context>にマニュアル情報を入れて参照させるだけの単純な構成です。テストすると、次の3つの問題が出ます。

• 「コンテキストに記載の情報によると」のように、参照元を口に出してしまう
• AcmeOSと無関係な質問(コードを書いて、など)にも答えてしまう
• コンテキストにない情報(サポートの電話番号や対応時間)を作り出してしまう

ノートブックは、無関係な質問に答えると、利用者が汎用チャットボットとして使い始めて費用が膨らむ点にも触れています。

最初の改善は、システムプロンプトの役割を具体化し、メインプロンプトに「関連する質問か」「有害・不適切か」を判定させる指示を足す形です。ここで、無関係な質問への回答とハルシネーションは減ります。

2つ目の構成では、判定条件を<objection_conditions>タグに書きます。条件は、有害または不適切な質問、コンテキストと無関係な質問、脱獄やサポート以外の利用の試みの3つです。当てはまるときは、決まった拒否フレーズ「I'm sorry, I can't help with that.」を<final_answer>の中にそのまま返させ、それ以外は何も言わせません。条件に当たらない質問も、情報が足りなければ同じフレーズで答えさせます。最後に、利用者へ表示するのは<final_answer>の中身だけにする関数が書かれます。

こうした抑制の考え方は、Claude APIのプロンプトリーク対策でも別の角度から扱っています。レッスン5の注記には、実際の利用者の入力で試していないため本番用のプロンプトではない、とあります。

3つの演習に共通する「判定してから出力させる」型

医療記録要約・コールサマライザー・サポートボットを並べると、1つの型が繰り返し使われています。XMLタグで指示・入力・出力形式を分け、判断の難しい箇所は専用のタグや判定条件で先に切り分け、その結果だけを最終出力に渡す順序です。

レッスン2では、出力タグ(<summary>)で結果を絞り込むだけでした。レッスン4になると、判定そのもの(INSUFFICIENT_DATAかどうか)が指示と例に組み込まれ、<thinking>の分析を挟んで<json>に出力されます。レッスン5では、判定条件(<objection_conditions>)と検討過程(<thinking>)が別のタグに分かれます。

レッスン5が示すのは、禁止の追記で足りなければ、出力の置き場所を設計し直すという順序です。プロンプトを直すとき、最初に疑うのは技法の追加ではなく、判定と出力のどこで分離が甘いかです。

目的別に見る演習の使い分け早見表

5本のノートブックはそれぞれ読めますが、READMEは最初から順に読む前提です。つまずいている課題に近いものから読む場合は、次の対応が目安になります。

長いプロンプトを一から組み立てる前に、分解プロンプトで質問の信頼性を上げる方法を知っておくと、レッスン3の診断の質が上がります。

演習を進める際の注意点

コードをそのまま実行するときは、ここまでに触れたモデル名とAPIキーのほかに、次の点でも引っかかります。

• リポジトリのLICENSEはCC BY-NC 4.0(非営利)です。フォーク後のコードの商用利用は、この条件の範囲に収まりません。
• Vertex AI上でClaudeを使う場合は、vertexブランチ側のノートブックのほうが環境に合います。

システムプロンプトの言い回しを固定したいなら、Claudeの応答言語をシステムプロンプトで固定する方法も参考になります。

まとめ

着手するレッスンは、いま困っている症状で決まります。出力の揺れならレッスン2、入力ごとの切り分けならレッスン4、禁止を書いても言い回しが消えないならレッスン5です。どこから始める場合も、実行前にモデル名を現行のものへ替えれば、アーカイブ済みのリポジトリで同じ流れを手元で再現できます。