Anthropic公式『Prompting 101』完全ガイド — Code w/ Claude 2025 で語られた10要素プロンプト設計とイテレーション実演を15章で再現

動かないプロンプトをどう直せばいいか分からない——AI で開発する全エンジニアが一度はぶつかる詰まりです。Anthropic がこの問いに 14 分の決定版回答を出したのが、2025 年 5 月 22 日に米サンフランシスコで開催された開発者会議 Code w/ Claude のセッション "Prompting 101"^[1] です。Applied AI チームの Hannah Moran 氏と Christian Ryan 氏が、スウェーデン語の交通事故報告書を Claude に分析させるという実題材を使い、ナイーブなプロンプトを 5 回のイテレーションで本番品質まで磨き上げる過程を Anthropic Workbench 上でライブ実演しました。本記事は、その 14 分すべてを 15 章にわたり詳細再現し、当日スライドで提示された 10 要素プロンプトアナトミー、<tasks> や <final_verdict> などの XML タグ運用、ハルシネーション防止、Extended Thinking との使い分け、Prefill Assistant Response まで——「動画を見なくても本質をすべて持ち帰れる」リファレンスとして整理します。所要時間は約 22 分です。

you@code-w-claude:~/prompting101 ❯ 01_tldr.md結論：Prompting 101 を 90 秒で

動画を再生する時間がない読者のために、まず Anthropic の Hannah / Christian が 14 分で示した結論を 90 秒に圧縮します。

1. プロンプト工学は経験科学である。書く → 走らせる → 失敗を観察する → 直す、というループを回す以外に上達のショートカットはない^[1]。
2. 良いプロンプトは構造で決まる。スライドで提示された 10 要素アナトミー（タスクコンテキスト / トーン / 背景データ / 詳細指示 / 例示 / 会話履歴 / 直近のタスク / 思考ステップ / 出力フォーマット / プレフィル）の順に並べると、Claude の遵守率が劇的に上がる^[1][3]。
3. 背景知識はシステムプロンプトに「教える」。今回のデモでは、スウェーデン語フォームの 17 種類の運転行動・記入ルール・列構造をシステムプロンプトに書き下ろした瞬間、Claude が「Vehicle B is clearly at fault（B 車に明らかな過失あり）」と確信を持って判定できるようになった^[1]。
4. XML タグでセクションを区切る。<form_structure> <driving_actions> <tasks> <final_verdict> のように囲うことで、Claude にも読み手にも構造が一目で伝わる。これは Anthropic 公式が一貫して推奨するベストプラクティス^[4]。
5. 「ステップバイステップ」を明示的に書く。<tasks> ブロックに task id=1 から順番に「フォームを読む → 解釈する → スケッチを読む → 結論する」と並べた瞬間、Claude の思考過程が透明化され、後段で検証可能になる^[6]。
6. ハルシネーションは「言わせない」設計で止まる。「自信がないなら『分かりません』と答えてよい」「人間のオペレーターに引き継いでよい」と明示的に逃げ道を与えると、Claude は無理矢理結論を捏造しなくなる^[1]。
7. Extended Thinking はデバッガであり本番ではない。Claude の頭の中を覗いて推論ロジックを盗み、それをシステムプロンプトに焼き直すのが正しい使い方^[7]。本番に Extended Thinking を残すと毎回車輪を再発明することになり、レイテンシも費用も膨らむ。
8. Prefill Assistant Response で出力先頭を強制できる。Assistant ターンの先頭に <itinerary> や { を書き始めるだけで、Claude はその続きを書く。出力フォーマットを 100% 制御したい時の最終兵器^[5]。

you@code-w-claude:~/prompting101 ❯ 02_about.mdこの動画について — 登壇者・日時・なぜ決定版なのか

本記事が題材とするのは、2025 年 5 月 22 日に米国カリフォルニア州サンフランシスコで開催された Anthropic 主催の開発者会議 Code w/ Claude^[2] のセッションです。

このセッションが「Anthropic 公式・プロンプト工学の決定版」と評されるのには、3 つの構造的な理由があります。

1. 登壇者が Applied AI チームである。研究部門の理論ではなく、実際の Anthropic 顧客のプロンプトを毎日触っているチームの実装ノウハウである、という重みがある。
2. 題材が「うまくいっている事例」ではなく「うまくいかなかった事例」から始まる。最初のプロンプトで Claude がスウェーデンの街路名「Köpmangatan」をスキー場と誤認識した瞬間から動画が始まり、そこから一歩ずつ修正していく構成。これがプレゼンとしての説得力を最大化している。
3. すべての改善が Workbench のスクリーンキャプチャで残る。スライドだけの抽象論ではなく、System Prompt 欄・User Prompt 欄・Response 欄が画面遷移するライブ感が、見ている開発者に「自分も今夜やってみよう」という再現意欲を直接植え付ける。

you@code-w-claude:~/prompting101 ❯ 03_definition.mdプロンプト工学とは何か — Anthropic 自身の定義

動画の冒頭、Hannah 氏はプロンプト工学を次のように定義しています^[1]。

The practice of systematically improving prompts for LLM applications — through testing, evaluation, analysis, and optimization of prompts.

Hannah Moran, "Prompting 101" (Anthropic Code w/ Claude, 2025) / [1]

ここで重要なのは、「systematically」と「testing, evaluation, analysis」という単語の選び方です。プロンプト工学は感覚やアートではなく、再現可能な手順であると Anthropic 自身が宣言しています。彼らは続けて、これは複数の領域にまたがる学際的なスキルだと整理します。

裏を返せば、これらのスキルセットを持ち合わせずにプロンプトを書くと、本番で破綻しやすいということでもあります。本記事の以降の章は、これら 5 領域それぞれのチェックポイントを、デモを通じて具体化していくものとして読んでください。

you@code-w-claude:~/prompting101 ❯ 04_scenario.md課題シナリオ：スウェーデン交通事故報告書を Claude に分析させる

デモの題材は、Anthropic の実顧客から着想を得たと Hannah 氏は説明しています^[1]。具体的には、欧州の保険会社がスウェーデンで発生した自動車事故の報告書を Claude に分析させ、保険金査定担当者の判断を補助したいという業務シナリオです。

分析対象は2 種類の画像です。

1. 標準化されたチェックボックス式の事故報告書。スウェーデン語のフォームで、A 列と B 列の 2 つのドライバー欄があり、それぞれに 17 種類の運転行動（例：「parkerade / stannade till = 駐車していた／停止した」）がリストアップされ、該当する箇所にチェックを入れる形式。
2. ドライバーが手書きで描いた事故現場のスケッチ。方眼紙に 2 台の車両（A・B のラベル付き）と矢印、そして街路名 KÖPMANGATAN やスウェーデン語の動詞 stillastående（停止中）körde（運転中）が走り書きされている。

業務上のゴールは明確です。

1. 2 枚の画像から事実情報を抽出する。
2. 誰に過失があるかを確信を持って判断する。
3. 確信が持てない場合は、その旨を明示し、人間のオペレーターにエスカレーションする。

このゴールが、後の章で「Claude に逃げ道を与える」というガードレール設計に直結します。本番システムに Claude を組み込む際の「不確実性の取り扱い」のお手本として記憶しておいてください。

you@code-w-claude:~/prompting101 ❯ 05_v1_skiing.mdv1 — 素朴な投入で起きた「スキー事故」幻覚

動画の中で最も印象的な瞬間が、この v1 です。Hannah 氏は Workbench にサンプル画像をアップロードし、User Prompt 欄にたった 1 行の指示を書きました。

Please analyze the images and tell me what happened.

画像を分析して、何が起きたのか教えてください。

System Prompt は空、Model は claude-sonnet-4-20250514、temperature = 0。ハルシネーションのリスクを最小化する保守的な設定で送信されました。

結果——Claude の応答は、保険査定の現場ではとても受け入れられない内容でした。

This appears to be a skiing accident that occurred on a slope or street called Köpmangatan...

Claude (v1 response, paraphrased) / [1]

事故報告書を「スキー事故」と判定し、街路名「Köpmangatan」をスキー場の名前と誤解した。temperature = 0 で、最先端モデルでも、これが起こります。

この失敗は、本セッション全体のレッスンを 1 つに凝縮しています——「Claude は文脈なしには正しく推論できない。文脈を与えるのは、あなたの仕事である」。

you@code-w-claude:~/prompting101 ❯ 06_anatomy.mdプロンプトの 10 要素アナトミー

v1 の失敗を受けて、Christian 氏がスライドで提示するのが、本セッション最大の知的資産である「10 要素プロンプトアナトミー」です。これは Anthropic が長年の顧客実装から蒸留した、複雑なプロンプトを構造化する 10 個のコンポーネントです。

この 10 要素アナトミーは Anthropic 公式 Docs の "Prompt engineering overview"^[3] ともほぼそのまま整合します。本セッションは Docs の「順序」と「優先順位」を、ライブデモで具現化したもの——と理解すると位置づけがクリアになります。

you@code-w-claude:~/prompting101 ❯ 07_v2_context.mdv2 — タスクコンテキスト + ガードレールを書く

v1 の「スキー事故」幻覚を解消する最初の打ち手は、10 要素アナトミーの #1（Task context）と #4（Rules / Guardrails）の追加です。Hannah 氏が Workbench に書き加えたのは次のような内容です。

You are an AI assistant helping a human claims adjuster review
car accident reporting documentation written in Swedish.

When analyzing accident materials, please state whether or not you can
fully confidently determine that one vehicle was clearly at fault, or
if the human adjuster needs to follow up on additional information.

あなたは、人間の保険査定担当者がスウェーデン語で書かれた
自動車事故報告書を確認するのを支援する AI アシスタントです。

事故関連資料を分析する際は、一方の車両に明確な過失があると
確信を持って判断できるか、あるいは人間の査定担当者が追加の
確認をすべきかを、必ず明示してください。

追加された情報量は、わずか数行。けれども、Claude の挙動は劇的に変わります。

v2 の Claude の応答は、要約すれば次のようなものです。「これは確かに自動車事故の報告書のようです。フォームと手書きスケッチを確認しましたが、現時点では一方の車両に明確な過失があるとは判断できません。人間の査定担当者の追加確認をお願いします」。

you@code-w-claude:~/prompting101 ❯ 08_v3_system.mdv3 — システムプロンプトに背景知識を注入する

v2 で Claude は「分からない」と答えるようになりました。これは安全ですが、ビジネス的には「使えない」状態です。査定担当者は Claude に判定してもらいたい。けれど Claude はスウェーデン語の保険査定フォームの構造を知らないため、判断材料が足りない。

そこで v3 では、10 要素の #3（Background data）を System Prompt に大量注入します。Hannah 氏が書き下ろしたのは次のような構造のシステムプロンプトです（実際の動画では各セクションが大幅に詳しく書かれていました）。

You are an AI assistant helping a human claims adjuster review
car accident reporting documentation written in Swedish.

<form_structure>
The Swedish accident report form is a standardized document with two
columns labeled A and B, representing the two drivers involved.
Each column contains 17 numbered rows. Each row corresponds to a
specific driving action, and drivers mark the checkbox in their
column if that action applies to them at the time of the accident.
</form_structure>

<driving_actions>
The 17 driving actions on the form are:
  1. parkerade / stannade till — was parked / stopped
  2. lämnade parkering — was leaving a parking space
  3. var på väg in i parkering — was entering a parking space
  ...（17 まで全項目を列挙）
</driving_actions>

<form_completion_rules>
- Drivers may use checkmarks (✓), filled circles, or X marks.
- Handwriting is often imperfect; accept reasonable approximations.
- A driver may mark multiple rows if multiple actions apply.
- Empty rows mean the action does NOT apply to that driver.
</form_completion_rules>

When analyzing accident materials, please state whether or not you can
fully confidently determine that one vehicle was clearly at fault, or
if the human adjuster needs to follow up on additional information.

あなたは、人間の保険査定担当者がスウェーデン語で書かれた
自動車事故報告書を確認するのを支援する AI アシスタントです。

<form_structure>
このスウェーデン式事故報告書は、A・B の 2 列で構成された標準
フォームで、それぞれ事故に関わった 2 名のドライバーを表します。
各列には番号付きの 17 行があり、各行は特定の運転行動に対応します。
ドライバーは、事故時に該当する行動の自分の列のチェックボックスに
印を付けます。
</form_structure>

<driving_actions>
このフォームに含まれる 17 種類の運転行動は次の通りです：
  1. parkerade / stannade till — 駐車していた／停止した
  2. lämnade parkering — 駐車場から出るところだった
  3. var på väg in i parkering — 駐車場に入るところだった
  ...（17 番まで全項目を列挙）
</driving_actions>

<form_completion_rules>
- ドライバーはチェックマーク（✓）、塗りつぶし円、X 印などで記入する。
- 手書きは必ずしも整っていないので、妥当な範囲で柔軟に解釈すること。
- 1 人のドライバーが複数の行動に該当する場合、複数行にマークすることがある。
- 空欄は「その行動に該当しない」ことを意味する。
</form_completion_rules>

事故関連資料を分析する際は、一方の車両に明確な過失があると
確信を持って判断できるか、あるいは人間の査定担当者が追加の
確認をすべきかを、必ず明示してください。

追加されたのは 3 つの XML セクション——フォーム構造、17 種類の運転行動の意味、人間がフォームを記入する際の癖。これらは「Claude には自明ではないが、業務エキスパートには自明な」ドメイン知識です。

このシステムプロンプトを置いた瞬間、Claude の応答は劇的に変わります。

I can confidently determine fault in this accident. Vehicle B is clearly at fault.

Claude (v3 response) / [1]

同じモデル、同じ画像、同じ temperature。違うのは「Claude が事前に知っている知識」だけ。これがシステムプロンプトの本質的な役割です。

you@code-w-claude:~/prompting101 ❯ 09_v4_tasks.mdv4 — <tasks> でステップバイステップ思考を強制する

v3 で Claude は正しい答えにたどり着きました。けれども問題が 1 つ残っています——「なぜそう判断したのか」が出力に書かれていない。本番の保険査定では、判定そのものよりも判定根拠の追跡可能性が重要です。査定担当者は Claude の答えを鵜呑みにできず、結局自分でゼロから検証することになります。

この問題を解くのが、10 要素アナトミーの #8（Thinking step by step）。User Prompt に <tasks> ブロックを置き、Claude に「順番に考える手順」を強制します。

I have attached two images:
  1. The accident report form (checkbox sheet, Swedish)
  2. The hand-drawn accident sketch by the driver

Please analyze them by following these tasks IN ORDER.

<tasks>
  <task id="1">
    Examine the checkbox form for both Vehicle A and Vehicle B.
    List which numbered actions are marked for each vehicle, and
    translate each marked action into English.
  </task>
  <task id="2">
    Summarize what the form alone tells you about the accident.
    Explicitly state any ambiguity.
  </task>
  <task id="3">
    Examine the hand-drawn sketch. Describe the relative positions
    of Vehicle A and Vehicle B, the direction of any arrows, and
    any handwritten notes (translated from Swedish).
  </task>
  <task id="4">
    Combine the form and sketch evidence. Conclude whether one
    vehicle is clearly at fault, and explain your reasoning.
  </task>
</tasks>

2 枚の画像を添付しました：
  1. 事故報告書フォーム（スウェーデン語のチェックボックス用紙）
  2. ドライバー本人が描いた手書きの事故スケッチ

これらを以下のタスクに沿って、必ず順番通りに分析してください。

<tasks>
  <task id="1">
    A 車両と B 車両それぞれについて、チェックボックスフォームを
    確認してください。各車両がチェックを入れた番号付き行動を
    すべて挙げ、その内容を日本語に翻訳してください。
  </task>
  <task id="2">
    フォームだけから事故について読み取れる事実を要約し、
    曖昧な点があれば明示してください。
  </task>
  <task id="3">
    手書きスケッチを確認し、A 車両と B 車両の相対位置、
    矢印の方向、手書きメモ（スウェーデン語からの翻訳）を
    記述してください。
  </task>
  <task id="4">
    フォームとスケッチの証拠を組み合わせて、一方の車両に
    明らかな過失があるかを結論し、推論の根拠を説明してください。
  </task>
</tasks>

結果、Claude の応答は4 つのセクションに自然に分割されます：「Form Analysis」「Form Summary」「Sketch Analysis」「Conclusion」。それぞれにタスク番号が振られ、推論の流れが透明化されます。

you@code-w-claude:~/prompting101 ❯ 10_v5_verdict.mdv5 — <final_verdict> で機械可読な出力に整える

v4 で Claude の出力は人間にとって読みやすくなりました。次の課題は「下流のシステムが処理できるか」です。保険会社の査定システムに Claude の出力を流し込むには、最終結論の場所が決まっていなければなりません。これが 10 要素アナトミーの #9（Output formatting）です。

v5 で Hannah 氏は、User Prompt の末尾に次の 1 行を追加します。

Important guidelines:
- Do NOT make assumptions beyond what is visible in the form and sketch.
- If two interpretations are equally plausible, state both.
- If the evidence is insufficient, say so explicitly.

Wrap your final verdict in <final_verdict> XML tags so the
downstream system can extract it programmatically.

重要なガイドライン：
- フォームとスケッチに見えていること以外を仮定しないでください。
- 2 つの解釈が同等にあり得る場合は、両方を併記してください。
- 証拠が不十分な場合は、その旨を明示してください。

最終判定は <final_verdict> XML タグで囲んでください。
下流のシステムがプログラム的に抽出できるようにするためです。

結果として Claude の応答は次のような構造で返ってきます。

## Form Analysis
（タスク 1 の出力 — 各車両のチェック項目とその英訳）

## Form Summary
（タスク 2 の出力 — フォームから読み取れる事実と曖昧さ）

## Sketch Analysis
（タスク 3 の出力 — 車両位置・矢印・手書きメモの解釈）

## Conclusion
（タスク 4 の出力 — 結論と推論の経路）

<final_verdict>
Vehicle B is clearly at fault. Vehicle A was stationary
(stillastående) at the time of impact, while Vehicle B was
in motion (körde) and approaching from behind, as confirmed
by both the checkbox marks (rows 1 and 12) and the sketch.
</final_verdict>

## フォーム分析
（タスク 1 の出力 — 各車両のチェック項目とその日本語訳）

## フォーム要約
（タスク 2 の出力 — フォームから読み取れる事実と曖昧さ）

## スケッチ分析
（タスク 3 の出力 — 車両位置・矢印・手書きメモの解釈）

## 結論
（タスク 4 の出力 — 結論と推論の経路）

<final_verdict>
B 車両に明らかな過失があります。衝突時、A 車両は停止
（stillastående）しており、B 車両は走行中（körde）で
背後から接近していました。これはチェックボックスの記入
（1 行目と 12 行目）とスケッチの両方で裏付けられます。
</final_verdict>

この <final_verdict> 1 つで、下流のシステムは正規表現 1 行で結論を抽出できます。Claude の前段は分析、後段は判定として明確に分離され、人間も機械も読める応答が完成しました。これが v1 から v5 までの旅の到着点です。

you@code-w-claude:~/prompting101 ❯ 11_xml_fewshot.mdXML タグと Few-shot：「言葉で説明するより、見せる」原則

5 回のイテレーションを通じて、デモでは <form_structure> <driving_actions> <tasks> <final_verdict> という4 種類の XML タグが登場しました。これらは思いつきではなく、Anthropic 公式の "Use XML tags to structure your prompts"^[4] ベストプラクティスに基づいています。

なぜ XML タグなのか

Hannah 氏が動画中で説明する根拠は 3 つあります。

1. Claude が XML 構造を学習で重点的に見ている。Anthropic は学習過程で意図的に XML 形式の指示を多く与えており、Claude は「タグで囲まれたセクション」を 1 つの意味的塊として認識する精度が高い^[4]。
2. Markdown より曖昧さが少ない。Markdown の見出し（##）は本文中にも自然に登場し得ますが、<form_structure> のような明示タグは混同しません。
3. 動的コンテンツの差し込み点が一目で分かる。テンプレート化する際、{{LOCATION}} のようなプレースホルダーをどこに置くべきかが明確になります。

動画では汎用例として、旅行プランナー型のプロンプトが提示されました。

<location>
{{LOCATION}}
</location>

<num_days>
{{NUM_DAYS}}
</num_days>

<user_preferences>
{{USER_PREFERENCES}}
</user_preferences>

Present your itinerary within <itinerary> tags.

<location>
{{LOCATION}}
</location>

<num_days>
{{NUM_DAYS}}
</num_days>

<user_preferences>
{{USER_PREFERENCES}}
</user_preferences>

旅行プランは <itinerary> タグで囲んで提示してください。

Few-shot Examples — 言葉で書くより 1 つの実例

10 要素アナトミーの #5（Examples）については、Christian 氏が動画中で次のような重要な原則を述べています^[1]。

If you find yourself writing long descriptions of how the output should look, stop. Just show one example.

Christian Ryan, "Prompting 101" (paraphrased) / [1]

これはトークン効率と記述正確性の両面で大きな差を生みます。

you@code-w-claude:~/prompting101 ❯ 12_hallucination.mdハルシネーション防止の 3 実践テクニック

v1 で起きた「スキー事故」幻覚は、Claude のハルシネーション（事実でないことを自信たっぷりに答える挙動）の典型例です。動画後半で Christian 氏は、ハルシネーションを止めるための 3 つの実践テクニックをまとめます^[1]。

1. 「分からない」と言う権利を明示的に与える。「If you're not confident, say 'I don't know'」「If the evidence is insufficient, escalate to a human」と書くだけで、Claude は無理矢理結論を出すのをやめる。これは v2 で実装した内容そのもの。
2. 「自信がある時だけ答えて」と前提を置く。「Only provide an answer if you are highly confident based on the evidence shown」と明示。確信度が低い時の挙動を事前に契約しておく。
3. chain-of-thought で根拠を吐き出させる。Claude に答えだけを求めると、確率分布の最尤候補を「それっぽく」出してしまう。<reasoning> や <evidence> ブロックで根拠を先に書かせると、根拠が薄い時に Claude 自身が気づき、結論を保留する確率が上がる。

you@code-w-claude:~/prompting101 ❯ 13_extended_thinking.mdExtended Thinking と プロンプト工学の使い分け

2025 年に入って、Claude にはExtended Thinking（拡張思考）モードが追加されました^[7]。Claude が回答する前に、独立した「思考用トークン」を消費して内部で長く推論するモードです。これがあれば「プロンプト工学はもう不要では？」という質問が会場から飛んだことも想像に難くありません。

動画では、この問いに対する Anthropic の明快な答えが提示されます。

動画で Christian 氏が示した結論はシンプルです——「Extended Thinking はデバッグツールであり、本番システムの心臓部に置くものではない」^[1]。

正しい使い方は次のフローです。

1. 難しいタスクで一度 Extended Thinking を ON にして実行する。
2. Claude の「思考トレース」を読み、どんな推論経路で正解にたどり着いたかを観察する。
3. その推論経路を、システムプロンプトに「順番に考えて」型のステップとして焼き直す（v4 でやった <tasks> がまさにこれ）。
4. 本番では Extended Thinking を OFF にし、固定化されたステップで安定的・低コストに実行する。

you@code-w-claude:~/prompting101 ❯ 14_prefill.mdPrefill Assistant Response — 出力先頭を固定する裏技

10 要素アナトミーの最後のピース、#10（Prefilled response）。動画の最終盤で紹介される、「出力フォーマットを 100% 強制したい時の最終兵器」です^[5]。

仕組み

Anthropic API の messages 配列は、通常 user ロールで終わって Claude（assistant ロール）が応答を返します。けれどもあなたが assistant ロールのメッセージを最後に置いて API を呼ぶと、Claude はそのメッセージの続きから書き始めます。

{
  "model": "claude-sonnet-4-20250514",
  "system": "...（先述のシステムプロンプト）...",
  "messages": [
    { "role": "user", "content": "Generate a 3-day travel itinerary for Tokyo." },
    { "role": "assistant", "content": "<itinerary>\n" }
  ]
}

{
  "model": "claude-sonnet-4-20250514",
  "system": "...（先述のシステムプロンプト）...",
  "messages": [
    { "role": "user", "content": "東京の 3 日間旅行プランを作成してください。" },
    { "role": "assistant", "content": "<itinerary>\n" }
  ]
}

この呼び出しを送ると、Claude は <itinerary> タグの中身から書き始めます。「JSON で答えて」と頼んでも前置きを書きたがる Claude を、強制的に黙らせる手段です。

典型ユースケース

1. JSON 強制：{ や {" で始めると、Claude は JSON オブジェクトを書き始めるしかなくなる。Markdown のコードフェンスでラップする悪い癖をそのまま封じられる。
2. XML タグの強制：<final_verdict> で始めると、verdict 以外のことを書かない応答に強制できる。
3. キャラクターの一貫性：「Yes, my lord. ...」のようなロールプレイ用のフレーズで始めれば、Claude は途中でキャラクターを崩しにくくなる。

you@code-w-claude:~/prompting101 ❯ 15_summary.mdDO / DON'T セルフチェック 12 項目とまとめ

本記事の内容を、明日からのプロンプト設計レビューにそのまま使えるチェックリストに落とし込みました。各項目は対応する章番号付きで、迷ったら戻って読み直せます。

1. 役割と業務文脈を最初の 2〜3 行で宣言する。Claude に「あなたは誰で、何のために働いているか」を伝える（Ch07）
2. ドメイン知識は System Prompt に置く。XML タグでセクション化し、プロンプトキャッシュで再利用する（Ch08, Ch11）
3. 「分からない時の正解」を明示的に教える。「I don't know」「人間にエスカレーション」と言う権利を与える（Ch07, Ch12）
4. 業務固有の正しいステップを <tasks> で書き下ろす。Claude に発見させない（Ch09）
5. 下流システムが拾える形で結論をマークする。<final_verdict> や JSON で出力位置を確定させる（Ch10）
6. 形式が複雑なら言葉で説明せず Few-shot で見せる。3〜5 個の多様な実例で示す（Ch11）

1. 素朴な 1 行プロンプトで本番運用しようとする（Ch05）
2. System Prompt を空にしたまま User Prompt に全部詰める（Ch08）
3. 「step by step に考えて」とだけ書いて業務ステップを Claude に発見させる（Ch09）
4. JSON 強制を Markdown のコードフェンス指示だけで実現しようとする（Ch14 — Prefill 使え）
5. Extended Thinking を本番に常時 ON のまま置く（Ch13）
6. ハルシネーションをプロンプトだけで封じようとする（Ch12 — 後処理層が必要）

本記事の本質を、最後に 3 行に圧縮します。

1. プロンプトは「自然言語のコード」であり、構造・モジュール化・テスト・リファクタの対象である。アートではなく工学である。
2. 10 要素アナトミー（Task / Tone / Background / Rules / Examples / History / Task / Steps / Format / Prefill）の順序に沿って必要なものだけ足していけば、ほぼあらゆる業務プロンプトは v1 → v5 のような段階的改善で本番品質に到達する。
3. Claude が間違えた時、悪いのは Claude ではなくプロンプトである。"garbage in, garbage out" を真摯に受け止め、システムプロンプトに知識を注入し、<tasks> でステップを与え、<final_verdict> で出口を確定させる。

あなたが今日から書く 1 通のプロンプトは、未来の自分とチームの業務 AI 体験の品質そのものです。Claude が期待外れの応答を返した時、まずプロンプトを開き、本記事の 15 章のどこに対応する欠落があるかを問い直してみてください。プロンプト工学は、感覚ではなく、今夜から再現できる手順です。