Claude のプロンプトとは
Claude（および Claude Code / Claude API）に投げる指示文の総称です。非エンジニアにとっては「チャット欄に書く依頼文」と同じ意味で構いません。
一方で API や Claude Code では、system prompt（毎回最初に読まれる土台のルール）と user prompt（その時々の依頼）を別々に書ける仕組みがあり、ここの使い分けが品質に効きます。
推奨される 7 段プロンプト構造
ワークショップで提示された並びは次の通りです。上から順に積むのがポイントで、いきなり「Instructions」だけを書くのが多くの人がやってしまうアンチパターンです。
1. Task（タスク） — このプロンプトで Claude にやってほしい仕事を
一文で。例: 「次の議事録を 3 行で要約してください」。
2. Tone（トーン） — 出力の口調・フォーマル度。例: 「丁寧語で、
煽らない」「社内向けにフラット」。
3. Background（背景） — タスクが置かれている文脈。例: 「これは
経営会議用で、出席は CFO と事業部長」。
4. Instructions（手順・制約） — 守ってほしいルールを箇条書きで。
例: 「数値は元データのまま」「固有名詞を勝手に言い換えない」。
5. Examples（例示） — 良い出力 / 悪い出力の具体例。**ここが
一番効く**。例: 「良い要約: 〇〇」「悪い要約: △△」。
6. Reminder（再喚起） — 長いプロンプトの末尾で、最重要ルールを
再度短く言い直す。例: 「※必ず 3 行以内、見出しは禁止」。
7. Format（出力形式） — Markdown / 箇条書き / JSON / プレーン
テキスト等の最終形。例: 「Markdown の - 箇条書き、3 件まで」。
書き方のコツとして、それぞれの段は見出し（# Task # Tone …）で分けると、Claude が役割を取り違えにくくなります。
不変情報は system prompt、動的情報は user prompt に分ける
7 段構造を書いたあと、もう一つ重要なのが どこに書くか です。
・System prompt に置くべきもの（不変）: Tone、Background のうち毎回変わらないもの、Instructions、Reminder、Format。 → 「このアシスタントの恒久ルール」を担う部分。
・User prompt に置くべきもの（動的）: 今回処理する Task の本文、今回固有の Background（特定の議事録、特定の顧客名など）、Examples のうち今回ピンポイントで効かせたいもの。
非エンジニアでも、たとえば Claude のカスタムインストラクション欄や、ノーコードツール上の「システムメッセージ」欄にあたる場所が system prompt だと思って差し支えありません。毎回の依頼文に同じルールを書き続けるのではなく、一度 system prompt に固定するだけで、安定度が一段上がります。
Examples × Extended thinking でループを回す
ワークショップが強調していた 3 番目のポイントが、Examples（例示）と Extended thinking（じっくり考えるモード）の組み合わせです。
・まず Examples を 2〜3 件入れて Claude の出力を観察する。
・出力がズレていたら、その「ズレの実例」を悪い例として Examples に追加する。
・このとき Extended thinking（Claude の「じっくり考える」設定。 Claude の UI では拡張思考オプション、API では thinking パラメータに相当）を有効にしておくと、Claude が なぜその出力をしたかの推論プロセス が見えやすくなり、どこで誤解しているかが特定しやすい。
・修正された Examples を反映して再実行 → さらに観察 → さらに修正、というフィードバックループを 2〜3 周回すと、同じモデルでも出力のブレが大きく減る。
つまり Examples は「最初に書いて終わり」ではなく、出力を見て育てる資産 として扱うのが正解、という話です。
応用 ① Tone セクションを丁寧に書く例 — Role/Tone Before-After
7 段構造のうち Step 1（Task）だけを書いて投げる のは、もっとも多いアンチパターンです。Anthropic 公式ワークショップでは、症状そのものが紹介されています。「事故報告書を分析して」 とだけ書いた V1 プロンプトに対し、Claude は文脈を勝手に補完して 「スキー事故」 として分析を返してきた、というケースです。
V1（タスク文だけ）— 何が起きたか
V1 のプロンプトは、たった一文。
事故報告書を分析して
このプロンプトに、自動車保険のクレーム（保険金請求）の事故報告書を渡した場合、Claude は何を返すか。Anthropic 公式ワークショップの実演では、Claude は 「スキー事故についての分析」 を返してきたと紹介されています。
なぜそうなるのか。「事故報告書」だけでは、Claude にとって以下のような前提がすべて不明だからです。
・何の事故か（自動車？スキー？労災？）
・誰の立場で読むのか（被害者？保険会社？弁護士？）
・どんな粒度で分析すべきか（1 行サマリ？争点抽出？数値の妥当性チェック？）
人間なら「保険会社からの依頼なんだから自動車事故だろう」と察するが、 Claude には背景情報がない。確率的にもっとも“それっぽい”文脈を選ぶ。 Claude のデフォルト挙動は“足りないコンテキストを自分で勝手に埋める” だと押さえておくのが第一歩です。
V2（役割＋トーンを 2 行足した）— 何が変わったか
V2 で追加されたのは、本質的にたった 2 行。
あなたは自動車保険会社の Claim adjuster（クレーム査定担当）を補助する
AI アシスタントです。
自信がない時は推測せず、factual（事実ベース）に保ってください。
事故報告書を分析して
この 2 行が、それぞれ別の役割を担っています。
・1 行目（Role 指定）: 「自動車保険会社のクレーム査定担当を補助する AI」と書くことで、Claude にとっての 業務文脈が一意に決まる。事故 = 自動車事故。読み手 = クレーム査定担当。出力 = 査定担当が次のアクションを取れる粒度の分析。スキー事故の方向に推測が走る余地がなくなる。
・2 行目（Tone 指定）: 「自信がない時は推測しない／factual を保つ」と書くことで、不確かな部分を 断言せず保留する 挙動に切り替わる。報告書に書かれていないことを Claude が“それっぽく補完”するハルシネーション傾向を、明示的に抑え込める。
ワークショップでは、この 2 行を足しただけで Claude が車事故を 車事故として認識し、査定補助の出力に切り替わったと紹介されています。
この 2 行が効く原則
1. コンテキスト（役割）は省略してはいけない: モデルは省略された前提
を「もっともそれらしい確率分布」で勝手に埋める。業務で使う限り、業務文脈は毎回明示する。
2. トーンは“品質ガードレール”として機能する: 「推測しない」「factual...
応用 ② Examples セクションに Few-shot を入れる — グレーゾーン事例＋ラベル
7 段の Step 5（Examples） は、ワークショップで「Claude を誘導する最強テク」と呼ばれていた部分です。「丁寧に書いて」「JSON で返して」と言葉で説明するより、実際の例を 3 つ見せた方が早い。
グレーゾーン事例＋正解ラベルを組で入れる
初心者は「分かりやすい正例」だけを並べがちですが、ワークショップで強調されたのは グレーゾーンの過去事例 を入れることでした。
# system prompt の Examples 欄（イメージ）
例 1（グレー）:
入力: 「先日の対応について確認したいことがあります。
担当者の方の言い方が少し気になりまして…」
正解: クレーム
理由: 「気になりまして」は明示的な苦情ではないが、
担当者の言動への不満を含むためクレーム扱い。
例 2（グレー）:
入力: 「貴社のサービスは素晴らしいのですが、
〇〇の機能はいつ追加されますか？」
正解: 要望
理由: 褒め言葉が混ざるが本質は機能追加の要望。
ポイントは 「正解ラベル + なぜそう判断したかの一行理由」 を添えること。境界線にある事例を見せることで、Claude は「ここからこっちはクレーム、ここからは要望」という閾値を学びます。
画像も例示として渡せる（base64 で）
Claude API は画像入力を base64 形式で受け取れるため、「こういう画像が来たらこう判定する」のテンプレート を system prompt に埋め込めます。契約書スキャン・身分証 OCR・商品画像審査など、過去の判定事例（画像 + ラベル）をそのまま教師例として格納できる、という発想です。
「Claude が間違えた瞬間」を例として積み増す
ワークショップで紹介された姿勢は、「prompt engineering は empirical science（経験科学）だ」という言葉でした。一発で完璧なプロンプトは書けない前提で、
1. プロンプトを動かす
2. Claude が間違えた出力を捕まえる
3. その入力 + 正解ラベルを Examples 欄に追加する
4. 同じ間違いをしないか試す
5. 1 に戻る
というループを回し続ける。社内 Slack の問い合わせ仕分けエージェントを動かしながら、毎週「先週の誤判定」を 5 件ピックアップして Examples 欄に追記していくと、月単位で精度が伸びます。
Few-shot 運用の注意点
・数の目安は 3〜10 個。多すぎると context window を圧迫する。
・同じパターンの例ばかりではなく多様性を持たせる。
・個人情報の混入に注意: 過去の問い合わせや顧客対応ログを Examples に使う場合は、氏名・電話番号などをマスクしてから埋め込む。
・base64 画像は本当に判定が割れるパターンに絞る（context を食う）。
応用 ③ Format / 仕上げの 3 テクニック — 出力タグ・Pre-fill・Extended thinking スクラッチパッド読み
7 段の Step 7（Format） をさらに踏み込み、出力を「DB や次工程に直接流し込めるレベルまで安定化」させる 3 つの仕上げテクニックです。
③-1 Output formatting：結論を独自タグでラップする
Claude に「JSON で返して」と頼むだけでは、前後に「以下が JSON です」のような自然文が混ざることがあり、そのままシステムに流し込みにくい。
やること: 結論部分を 独自タグでラップ する（例: <final_verdict> 〜 </final_verdict>）。タグ内のフォーマットを明示（JSON / YAML / CSV / プレーンテキスト等）。必要なら JSON のキー名・型まで system prompt 側で固定する。
最終結論は必ず以下の形式で出力してください。
<final_verdict>
{
"decision": "accept" | "reject",
"reason": "1〜2 文の理由",
"confidence": "high" | "medium" | "low"
}
</final_verdict>
こうしておくと、後段のスクリプトやノーコードフローで <final_verdict> 〜 </final_verdict> の中身だけを抜き出して、データベースや次の処理に流し込めます。
③-2 Pre-fill：応答冒頭を強制してムダ書きを消す
Claude は親切な性格で、依頼に対して「承知しました」「以下のとおり要約します」のような前置きを入れがち。後段が機械処理だと邪魔です。
やること: API や Claude Code で assistant turn の冒頭 を、こちらが書いた数文字で始めさせる。JSON 配列で返してほしいなら [ から、上のタグ運用なら <final_verdict> から始めさせる。これにより前置き文章が 物理的に書けなくなる（Claude はその続きから生成するため）。
messages = [
{ role: "user", content: "次の議事録を JSON 配列で要約してください。…" },
{ role: "assistant", content: "[" } // ← ここが Pre-fill
]
注意: Pre-fill は API・Claude Code・Workbench でしか使えない機能で、通常の Claude チャット UI からは指定できません。ノーコードツール経由で Claude を呼んでいる場合は、ツール側に「assistant メッセージの冒頭を指定する」項目があるか確認してください。なければ ① の出力タグ指定で代替します。
③-3 Extended thinking：scratchpad から「足りないコンテキスト」を見つける
Claude 3.7 以降の Extended thinking では、最終回答の前に Claude が どう考えたか が見えます。これを「ただ眺めるもの」ではなく プロンプト改善の材料 として使うのが、3 つ目の仕上げです。...
誰にどう効くか
・業務文書を Claude に書かせている人: 議事録要約、顧客向けメール下書き、社内報告書など、毎回似たフォーマットを出すタスクで system prompt に 7 段の骨格を固定すれば、依頼文が「議事録ペーストだけ」で済むようになる。
・ノーコードで AI エージェントを組んでいる人: ツール側の「システムプロンプト」欄に Tone / Instructions / Format を入れ、ユーザー入力欄を Task 専用にすると、回ごとの品質が安定する。
・Claude Code を使っている開発担当者: プロジェクト側の指示文（CLAUDE.md など）に 7 段のうち恒久部分を、依頼ごとのチャットに Task と動的 Background を分けて書くことで、コーディング指示の取り違えを減らせる。
触ってみるには / 注意点
・コストはかからない: これは仕様変更ではなく 使い方のフレームワーク。今日から自分のプロンプトを 7 段に書き直すだけで適用可能。
・完璧を目指さない: 7 段すべてを毎回フルで書く必要はない。Tone と Background が自明なら省いてよい。Examples と Format は省かない のが実務的に効きやすい。
・Extended thinking の使いどころ: 全タスクで有効化する必要はなく、出力品質を上げたい・ループを回したいフェーズで使う。短い雑談やシンプルな単発要約には不要。
・モデル別の挙動: 本記事は Claude を前提とした構造ですが、 GPT 系・Gemini 系でも 7 段構造の発想自体は流用が効きます。ただし「system prompt と user prompt の分離」「Extended thinking 相当の推論オプション」は各社で名称・挙動が異なるため、移植するときは各社のドキュメントを確認してください。
参考
・7 段構造の総まとめ（24 分ワークショップ動画の要約スレッド 9/n）: <https://x.com/masahirochaen/status/2053313339980439687>
・Role/Tone Before-After（同スレッド 4/n）: <https://x.com/masahirochaen/status/2053313261643448602>
・Few-shot Examples の deep-dive（同スレッド 6/n）: <https://x.com/masahirochaen/status/2053313292568051740>
・仕上げ 3 テクニック（同スレッド 8/n）: <https://x.com/masahirochaen/status/2053313324218241208>
_Status: accepted — Anthropic 公式ワークショップ要約スレッドの 4 ポスト（4/n, 6/n, 8/n, 9/n）を 7 段構造を背骨に 1 本へ集約した版。_