Note:
この記事は @jota_snchez さんによる以下の X ポストの動画（約25分）を日本語でまとめたものです。
元動画: https://x.com/jota_snchez/status/2049898145346105395
はじめに
Anthropic の Applied AI チームに所属する Hannah Moran と Christian Ryan が、プロンプトエンジニアリングのベストプラクティスを実際のコンソールデモを交えて解説したセッションです。
自動車保険の事故報告フォーム（スウェーデン語）を Claude に分析させるという実在の顧客事例をベースに、シンプルなプロンプトから段階的に改善していくプロセスをライブで見せてくれます。「スキー事故と誤認するレベル」から「確信を持った判定を返す本番品質」まで、5バージョンの変遷が非常に参考になります。
プロンプトの基本構造
Anthropic が推奨するプロンプトの基本構造は次の5要素です。
| # | 要素 | 内容 |
|---|---|---|
| 1 | タスク説明 | Claudeの役割と大まかなタスクを1〜2文で |
| 2 | 動的コンテンツ | 処理対象のデータ・画像・他システムから取得した情報 |
| 3 | 詳細な手順 | ステップバイステップの実行指示 |
| 4 | 例示（オプション） | Few-shot サンプル |
| 5 | 重要事項の再掲 | 特に守ってほしいルールのリマインド |
Note:
長いプロンプトでは、特に重要な指示を最後にもう一度繰り返すのが効果的です。
情報の整理：XML タグの活用
Claude は構造化された情報を得意とします。Anthropic が特に推奨するのが XML タグによる区切りです。
<user_preferences>
{{USER_PREFERENCES}}
</user_preferences>
- タグ内に何が入っているかを明示できる
- Claude がプロンプト後半で情報を参照しやすくなる
- Markdown より境界が明確でトークン効率が良い
乱雑なプロンプトは Claude が理解しにくく、出力の質が下がります。XML タグで整理するだけで大幅に改善できます。
実践デモ：プロンプトを段階的に構築する
デモの題材は「スウェーデン語の自動車事故報告フォームから過失車両を判定する」システムです。コンソールで次の要素を順番に積み上げていきました。
V1 → V2：タスクコンテキストとトーンを追加
V1 の問題点：「Chapman Gotham 通りでスキー事故が発生した」という的外れな出力。プロンプトに背景情報がゼロだったため。
V2 で追加したこと：
- これは自動車保険のクレーム処理システムであること
- 入力はスウェーデン語の事故報告書と手書きスケッチであること
- 確信が持てない場合は判定しないこと（ハルシネーション防止）
→ 車の事故と正しく認識するようになったが、まだ情報不足で判定が曖昧。
V3：システムプロンプトに背景情報を追加
フォームの構造（17のチェックボックス、左右2列が車両A・B）をシステムプロンプトに記述。
Note:
ポイント：変わらない情報はシステムプロンプトへ
フォームの構造は毎回同じです。このような静的な背景情報はシステムプロンプトに置くのが最適で、プロンプトキャッシュの効果も最大化できます。
→ フォームの読み取り精度が上がり、「車両Bが過失」と初めて明確な判定を出した。
V4：詳細な手順指示（処理順序が重要）
1. まずフォームを注意深く調べ、チェック済みのボックスをすべてリストアップせよ
2. 次にスケッチを分析せよ（フォームで得た知識を踏まえて）
3. 最終判定を下せ
「スケッチより先にフォームを読む」という順序が重要。手書きスケッチだけ見ても何の事故か判断できないが、フォームを先に読めばスケッチの意味が理解できる。人間が作業する順序と同じです。
V5：出力フォーマットの指定
最終判定を <final_verdict> タグで囲むこと。
→ アプリケーションが必要な情報（判定結果）だけを XML タグから取り出せるようになった。スキー事故誤認 → 曖昧 → 確信を持った構造化出力、という進化が完成。
その他の重要テクニック
Few-shot 例示
実際の難しいケースを人間がラベル付けして例示として追加すると、精度が大幅に向上します。画像も Base64 エンコードしてサンプルに含めることができます。本番システムでは数十〜数百の例示を持つことも珍しくありません。
会話履歴
ユーザー向けアプリケーションであれば、過去のやり取りをコンテキストとして渡すことで精度が上がります。
Pre-fill（出力の先頭を指定）
Assistant ロールに開始文字列を設定することで、Claude の出力形式を強制できます。
messages = [
{"role": "user", "content": "..."},
{"role": "assistant", "content": "<final_verdict>"} # ← pre-fill
]
Claude は <final_verdict> の続きから出力を開始します。JSON 形式で始めさせたい場合も同様です。
Extended Thinking（拡張思考）
Claude 3.7 以降で利用可能。<thinking> タグに Claude の推論過程が出力されます。
⚠️ Warning:
Extended Thinking はプロンプトの問題点を診断するためのツールです。思考過程を分析してどこで詰まっているかを確認し、そのパターンをシステムプロンプトの手順指示として組み込んでいくことで、最終的には Extended Thinking なしで同等の品質を出すことを目指しましょう。その方がトークン効率も良くなります。
まとめ
| テクニック | 効果 |
|---|---|
| タスクコンテキストを明示 | 的外れな解釈を防ぐ |
| 静的情報をシステムプロンプトへ | プロンプトキャッシュ最適化 |
| XML タグで構造化 | 情報の参照精度向上 |
| 処理順序を指定 | 人間の作業順序を再現 |
| 出力フォーマットを指定 | アプリ統合を容易に |
| Few-shot 例示 | 難しいケースの精度向上 |
| Pre-fill | 出力形式を強制 |
| Extended Thinking | 思考過程を可視化してデバッグ |
プロンプトエンジニアリングは反復的な実験科学です。テストケースを作り、失敗パターンを見つけ、システムプロンプトに落とし込む——このループを回し続けることが本番品質への近道です。
📝 動画全文書き起こし（日本語訳）
オープニング（0分）
皆さん、本日は「Prompting 101」にご参加いただきありがとうございます。私は Hannah、Anthropic の Applied AI チームのメンバーです。一緒に登壇しているのは Christian、同じく Applied AI チームです。
今日はプロンプティングのベストプラクティスをご紹介します。実際のシナリオを使い、一緒にプロンプトを作り上げていきます。
プロンプトエンジニアリングとは何か——おそらく皆さんはある程度ご存知かと思います。言語モデルとのコミュニケーション方法であり、モデルに意図した動作をさせるための実践です。具体的には、モデルへの明確な指示を書くこと、タスク完遂に必要なコンテキストを与えること、そして情報の最適な配置を考えること——この3点に集約されます。
今日は実際の顧客事例を参考に、画像分析と事実情報の抽出、そして Claude によるコンテンツ判定を行うシナリオを使います。なお、このフォームの言語は私には読めませんが、幸い Christian と Claude はどちらも読めます（笑）。
シナリオ紹介（1分）
Christian： 今回のシナリオはこうです。あなたは自動車保険会社の勤務者で、毎日自動車事故のクレームを処理しています。入力は2種類です——スウェーデン語の自動車事故報告書（何が起きたかを記録した17項目のチェックボックス形式）と、事故状況の手書きスケッチです。この2つを Claude に渡して、過失車両を判定させます。
最初は何もせずにコンソールにそのまま渡してみましょう。
コンソールでの設定： claude-sonnet（最新モデル）、temperature 0、max tokens 最大。
最初のプロンプト：「これは事故報告書です。何が起きたか、誰が悪いかを判定してください。」
結果：Claude が「Chapman Gotham 通りでスキー事故が発生した」と出力しました。スウェーデン語のフォームをスキーに関するものと誤認したのです。これは Claude を責めるべきではありません。プロンプトに何の背景情報も与えなかったため、Claude はベストを尽くしているだけです。
ベストプラクティス：プロンプト構造（4分）
プロンプトエンジニアリングは反復的な実験科学です。このケースでは「Claude が自動車環境であることを理解しているか」というテストケースを作り、そうでなければプロンプトを修正する、という形で積み上げていきます。
Anthropic が内部で実践し、他の方々にも推奨しているベストプラクティスを紹介します。
まず優れたプロンプト構造についてです。チャットボットとの会話スタイルのやり取りに慣れている方も多いかと思いますが、今回のようなタスクでは API を使って1つのメッセージを送り、Claude に一発で仕上げてほしい場面がほとんどです。
推奨する構造：
- タスク説明：Claudeの役割と今日何をするかを冒頭に
- 動的コンテンツ：今回は画像（フォームとスケッチ）。他のシステムから取得した情報もここに
- 詳細な手順：Claudeにどう作業を進めてほしいかのステップバイステップリスト
- 例示：受け取り得るコンテンツの例と、それに対してどう応答すべきかの例
- 重要事項の再掲：特に重要なことをClaudeに確認させ、「では作業を始めてください」で締める
V2の構築（6分）
Christian： タスクコンテキストから始めます。先ほどのデモでは背景情報が全くなく、Claude は多くを推測するしかありませんでした。明確な指示を与え、タスクを理解させることが重要です。
次に、トーンの設定です。Claude には事実に基づいた確信ある回答をしてほしい。確信が持てなければ、誤解を招く回答をしてほしくない。判定ができる場合は、できる限り明確に判定してほしい。
コンソールに戻ってV2を見てみます。データを明示的に示すことを追加しました——これが自動車事故報告書であること、左右の列が車両AとBであること。そして多くの情報をシステムプロンプトに追加しました。このシステムは人間の損害保険担当者がスウェーデン語の自動車事故報告書をレビューするのを支援するAIシステムである、と。確信が持てない場合は判定しない、とも明示しました。
実行結果：今度は自動車事故として認識できています。車両Aはチェックボックス1、車両Bはチェックボックス12にチェックがある、と読み取れています。ただ、まだ明確な過失判定に至るには情報が不足している、と Claude が言っています。これは正しい動作です——「確信がなければ言わない」という指示通り動いています。
V3：背景情報とプロンプト構造（9分）
Hannah： 次に追加するのは背景データ、ドキュメント、画像です。このフォームについて我々は多くを知っています。フォームは毎回同じ構造です。これはシステムプロンプトに入れるのに最適な情報です。フォームの構造を Claude に事前に教えることで、毎回フォームが何なのかを理解しようとする時間を省けます。
また、これはプロンプトキャッシングを使うのに最適なケースです——毎回変わらない情報だからです。
情報の整理方法についても触れたいと思います。Claude は構造を好みます。だから標準的な構造に従うことを推奨しています。XML タグを使うと、タグ内の情報が何であるかを指定できます。例えば <user_preferences> タグで囲めば、Claude はそのコンテキストでその情報を参照できます。
Markdown も有用ですが、XML タグの方がより境界が明確で、Claude がどこで何を参照すべきかを理解しやすいため推奨しています。
コンソールのV3では、システムプロンプトにフォームに関する情報をすべて追加しました。これはスウェーデンの自動車事故報告書です。スウェーデン語で書かれています。このようなタイトルがあります。2列構成です。各列が異なる車両を表します。そして17行それぞれの意味を説明しました。
さらに「人間が記入するため完璧ではない。○かもしれないし、殴り書きかもしれないし、チェックボックスに×とは限らない。様々な記入方法を探すこと」という指示も追加しました。
実行結果：フォームが何かを説明する時間が減り、分析に集中するようになりました。そして今度は明確に「車両Bが過失」と判定しています。
V4：詳細な手順指示（14分）
Hannah： 次のポイント：具体的な例示です。Few-shot は Claude を強力に方向付けるメカニズムです。難しい事故ケースや判定が難しいグレーゾーンを、人間がラベル付けして例示として追加することができます。画像も Base64 エンコードしてサンプルに含められます。こうした例示がシステムプロンプトの精度を大幅に向上させます。
会話履歴については今回は使っていませんが、ユーザー向けアプリケーションで長い会話履歴がある場合は、それをコンテキストとして渡すことが有効です。
次のステップは、タスクのリマインダーと重要なガイドラインの追加です。
ハルシネーション防止のために追加するのが理由の一つです。データに存在しない詳細を Claude に作ってほしくない。スケッチが判読不能な場合——描いた人が下手で人間でも判断できないケースもあります——Claude にそれを言えるようにしてほしい。
コンソールに戻ってV4を見てみます。システムプロンプトは変えず、詳細な手順リストを追加しました。重要なのは Claude が分析する順序です。
人間ならどう作業するか考えてみてください。まずスケッチを見ても何の事故かわかりません——ボックスと線が並んでいるだけです。でもフォームを先に読んで、自動車事故についての話であり、どの車両が何をしていたかを示すチェックボックスがあるとわかれば、スケッチの意味も理解できます。
だから Claude への指示は「まずフォームを丁寧に見て、チェックされているボックスを確認し、自分のためにリストを作れ。そしてスケッチに移れ」という順序にしました。
実行結果：「各ボックスがチェックされているか否か」を丁寧に確認する様子が出力に現れました。これは我々が指示した通りですが、アプリケーションによっては不要かもしれません。XML タグで構造化された分析、事故の概要、スケッチの分析も出力され、「車両Bが明らかに過失」という判定が続いています。
V5：出力フォーマットと Pre-fill（19分）
Christian： 最後のステップです。システムプロンプトの設定は変えず、重要なガイドラインのリマインダーを追加しました。要約を明確・簡潔・正確にすること。分析以外のことはしないこと。
そして出力フォーマット：最終判定を <final_verdict> XML タグで囲む指示を追加しました。アプリケーションにとって必要な情報だけを抽出できるようにするためです。
実行結果：はるかに簡潔な出力になりました。最後に <final_verdict> タグで囲まれた判定が出力されます。
このデモを通じて、スキー事故誤認 → 曖昧な判定 → 現在の明確で構造化された自信ある出力、という進化を見てきました。これを実際の自動車保険会社のアプリケーションに組み込めるレベルです。
Pre-fill とExtended Thinking（22分）
Christian： Claude の出力を形成するもう一つの方法が Pre-fill です。XML タグのパースは便利ですが、後続の処理で使いやすい JSON 出力が欲しい場合もあります。
シンプルな方法：Assistant フィールドに出力の開始テキストを書くだけです。例えば <final_verdict> や { を書けば、Claude はそこから続きを出力します。前置きなしに必要な情報だけを取得できます。
そして最後に、Claude 3.7 以降で利用できる Extended Thinking についてです。これはプロンプトエンジニアリングの「松葉杖」として使えます。有効にすると、Claude が thinking タグとスクラッチパッドに思考過程を出力します。この思考過程を分析することで、Claude がどのようにデータを処理しているかを理解できます。
先ほどのチェックボックスの例でも、Claude がステップバイステップで事故のシナリオを辿る様子を確認できます。これをシステムプロンプトの指示として組み込むことで、Extended Thinking なしでも同等の品質を出せるようになります。トークン効率も上がります。
それでは Q&A にまいりましょう。まだ時間があれば会場でもお声がけください。次のセッションは「Prompting for Agents」と「Claude plays Pokémon」のデモです。ありがとうございました！