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

Anthropicはanthropics/coursesというGitHubリポジトリで、実務レベルのプロンプト設計を学べる教材real_world_promptingを公開しています。医療記録の要約からカスタマーサポートボットまで、5本のノートブックを通じて「動くけれど雑なプロンプト」を段階的に改善していく過程を扱う内容です。このリポジトリは2026年9月15日にオーナーによってアーカイブされ、read-only状態になりました。

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は5つのうち3番目に位置し、READMEには「Prompt engineering interactive tutorialを先に終えていることを推奨する」という記載があります。単発のテクニックではなく、複数の技法を組み合わせた長いプロンプトを組み立てる回として設計されている点が特徴です。

なお、このコースにはGoogle Vertex AI向けの別バージョンも存在します。リポジトリのvertexブランチにreal_world_promptingと同名のディレクトリがあり、Vertex AI経由でClaudeを使う開発者向けに用意されています。本記事はGitHubのmasterブランチにあるAnthropic API版を対象にします。

受講前提と実行環境

各ノートブックは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の全ノートブックで共通しています。各.ipynbはGitHub上でそのままプレビューできます。

レッスン1: 6つの基本プロンプト技法を確認する

01_prompting_recap.ipynbは、前段の「Prompt engineering interactive tutorial」で学んだ内容の振り返りです。冒頭でAnthropicのPrompt Generatorツール(プロンプトの下書きを生成してくれるツール)を紹介したあと、6つの技法を順に振り返ります。

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

このレッスン自体は復習であり、実装は次のレッスン以降で行われます。

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

患者の医療記録を渡すので要約してほしい、という単純な指示から始まるのが02_medical_prompt.ipynbの課題です。架空の患者記録を要約する課題にこの指示で取り組むと、出力はそれぞれ長さも構成もばらばらになります。ある要約は長い段落、別の要約は箇条書き、という具合に出力形式が揺れる問題が起きます。

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

• システムプロンプトの追加: 「医療記録を要点にまとめる専門家」という役割を与える
• 入力のXML構造化: <patient_record>タグで記録本体を囲み、指示文と入力データを区別する
• 指示の具体化: 何を要約するかを明記する
• 出力形式の指定: 要約に含めるべき項目と長さを指定する
• 例の追加: <example>タグで入出力の対応例を示す
• 出力タグの指定: <summary>タグの中に要約本文だけを出力させる

これらを反映した後の出力は、どの記録でも同じ構成・同じ粒度の要約になります。ノートブックはさらに、同じ改善済みプロンプトをJSON出力に切り替える例も示しています。ここで「JSON出力を確実にする一番簡単な方法はツール使用機能を使うことで、それは別のtool_useコースで扱う」という注記があり、プロンプトだけで出力形式を制御する方法とツール使用で制御する方法が別物であることを示しています。

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

03_prompt_engineering.ipynbは技法ではなく、改善のプロセスそのものを次の5段階のサイクルで示します。

1. 初期プロンプトの作成
2. テストと問題点の特定
3. 適切な技法の選定(根本原因の診断 → 解決策の調査 → 技法の選択)
4. 改善の実装
5. 反復と改善

「基本的なプロンプト」と「エンジニアリングされたプロンプト」の違いは、複雑さ・精度・反復的な改善・スケーラビリティの4点で説明されています。単発の質問で満足するのではなく、テストケースを用意して結果を検証し、問題を診断してから初めて技法を選ぶという順序が強調されている点が、このレッスンの核です。

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

04_call_summarizer.ipynbはカスタマーサポートの通話記録を要約し、対応品質の分析に使えるJSONにする演習です。短い通話・解決済みの中程度の通話・未解決の長い通話という3種類のサンプルを使い、プロンプトを段階的に強化していきます。

最終的なプロンプトの骨格は、次のように整理されます。

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

このレッスンで重要なのは「対応できないケース」の扱いです。通話が言語の壁で成立しなかった場合・音声が乱れて聞き取れない場合・接続不良で途中で切れた場合・顧客が感情的になっている場合など、要約すべきでない通話をそのまま要約してしまうと、対応品質の分析結果が歪みます。ノートブックはこれらを{"status": "INSUFFICIENT_DATA"}というJSONで明示的にフラグ立てする方法を選び、その判定基準と対応する例をプロンプトに追加することで解決します。

なお、このノートブックの最後には「このプロンプトは本番投入できる完成品ではなく、少数の目視テストに基づく出発点にすぎない」という注記があります。実運用に投入するには、定量的な評価プロセスがまだ欠けているとしています。

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

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

• 「コンテキストに記載の情報によると」のように、参照元を口に出してしまう
• AcmeOSと無関係な質問(コードを書いて、など)にも普通に答えてしまう
• コンテキストに存在しない情報を、それらしく作り出してしまう(ハルシネーション)

対策として、システムプロンプトの役割定義を具体化し、<objection_conditions>タグの中で「質問がAcmeOSと関係するか」「有害な内容を含むか」を判定させ、当てはまる場合に返す定型の「拒否フレーズ」を用意します。さらに、回答を<thinking>タグでの検討と<final_answer>タグでの最終回答の2段階に分け、ユーザーに見せるのは<final_answer>の中身だけにします。この2段階構成によって、モデルが検討過程で口にする「コンテキストによると」という言い回しが、ユーザーの目に触れる最終回答からは消えます。詳しい抑制手法はClaude APIのプロンプトリーク対策でも扱っているので、システムプロンプトの漏えい対策を掘り下げたい場合はそちらも参考になります。

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

医療記録要約・コールサマライザー・サポートボットの3演習を並べると、個別の技法の羅列ではなく1つの型が繰り返し使われていることが分かります。まずXMLタグで指示・入力データ・出力形式を分離し、判断が難しい箇所(要約すべきでない通話、AcmeOSと無関係な質問)を専用のタグや判定条件で先に切り分け、その判定結果だけを最終出力に渡す、という順序です。

レッスン2は出力タグ(<summary>)で結果を絞り込むだけでしたが、レッスン4になると判定そのもの(INSUFFICIENT_DATAかどうか)が<thinking>タグの中で行われ、レッスン5では判定条件(<objection_conditions>)と検討過程(<thinking>)が完全に分離されます。5本を順番に読むと、この「判定を先に済ませ、その結果だけをユーザーに見せる」設計が、単純な出力タグの指定から、判定ロジックそのものをタグで切り出す形へと段階的に重くなっていく流れが見えます。プロンプトを改善するときにまず疑うべきは技法の追加ではなく、判定と出力のどこで分離が甘くなっているかです。

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

5本のノートブックはどれも独立して読めますが、自分の課題に近いものから読むと効率的です。

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

演習を進める際に注意したい点

コードをそのまま実行しようとすると、いくつか引っかかる点があります。

• モデル名が古い。claude-3-sonnet-20240229やclaude-3-haiku-20240307はすでに旧世代のモデルで、現行モデルの名前に置き換える必要があります。置き換え先を選ぶ際は、要約や分類のような軽い処理か複雑な判定を含むかで、コストの低いモデルと上位モデルを使い分けるのが妥当です
• APIキーと.envの用意が前提になっている。.envにAPIキーを書いていないとAnthropic()の初期化でエラーになります
• リポジトリがアーカイブ済みのため、コード自体に誤りを見つけても修正のPRは送れません。フォークして自分の手元で直すほうが現実的ですが、ライセンスはCC BY-NC 4.0(非営利)なので、フォーク後のコードを商用利用することはできません
• real_world_promptingはGitHub版(Anthropic API)とVertex AI版(vertexブランチ)で内容が分かれています。Google Cloud上でClaudeを使う場合はvertexブランチ側を確認したほうが、環境に合ったコード例になります

システムプロンプトの言い回しを固定したい場合は、Claudeの応答言語をシステムプロンプトで固定する方法も合わせて読むと、システムプロンプトの書き方の幅が広がります。

まとめ

real_world_promptingは、単発のテクニック紹介ではなく「雑なプロンプトを実運用に近づけるまでの改善過程」を追える点が特徴の教材です。医療記録要約・コールサマライザー・サポートボットという3種類の実務課題を通じて、システムプロンプト・XML構造化・例示・出力形式指定・エッジケース処理という技法が、どの順番で組み合わさっていくかを追体験できます。アーカイブされたリポジトリではありますが、コードとノートブックはそのまま読めるため、モデル名を現行のものに置き換えれば手元でも同じ流れを再現できます。