プロンプティング 101 — V1 から V5 で進化する現場のプロンプト (Hannah Moran × Christian Ryan / Anthropic)

Code w/ Claude (Anthropic) 2025/07/31

ハンナ・モラン × クリスチャン・ライアン / Hannah Moran × Christian Ryan · 09:44 「クロードは本当に構造が大好きで、組織が大好きなのです」

Anthropic 公式チャンネル (2025/07/31 公開、約 24 分)。 2025 年 5 月 22 日の Code w/ Claude SF イベントでの Applied AI チームによるライブワークショップ

スウェーデンの自動車保険会社で、毎日積み上がる事故請求を Claude に処理させる。入力は 2 つ — 17 個のチェックボックスを持つスウェーデン語の交通事故報告フォーム、そして人間が手描きの事故スケッチ。求める出力は事故の状況評価と過失判定。 Anthropic Applied AI チームの Hannah Moran と Christian Ryan が、この実在の顧客ユースケースを題材に、 1 つのプロンプトを V1 から V5 まで段階的に育てていくライブワークショップが本講演。

V1 はシンプルな依頼文 + 画像 2 枚。 Claude の応答は「スキー事故」と誤読、場所も実在しない通り名を生成した。「私たちのプロンプトでは、実際には舞台を整えるために何もしていなかった」 (03:03) と Christian が認める。 V2 で文脈を加え、 V3 でフォーム構造を事前説明し、 V4 で思考の順序を指定し、 V5 で出力フォーマットを XML タグで固定する。各バージョンでデモを走らせ、何を加えると何が改善するかをコンソール画面で見せていく構造。

講演を貫く一本の発想は「プロンプトエンジニアリングは、非常に反復的な経験科学」 (03:22)。完璧なプロンプトを 1 発で書こうとせず、テストケースを走らせながらモデルへの情報の渡し方を絞っていく。そして「Claude に何をどう考えさせるか」の設計が、「Claude に何を求めるか」の依頼以上に重要になる、という構え。 24 分で 10 要素のプロンプト構造を体系的に伝え切る Anthropic 公式の基礎教材で、シリーズとしては Code w/ Claude の起点に位置する回。

語るのはハンナ・モラン (Hannah Moran) — Anthropic Applied AI、 2025 年 3 月入社。元 PwC の Innovation Hub / AI & Emerging Technology で Technical Lead を務めた経歴で、企業向け AI 統合プロジェクトの経験から教育コンテンツを担当している。共同講演者はクリスチャン・ライアン (Christian Ryan) — Anthropic Applied AI Engineering Manager (ロンドン)、元 Voi Technology の Machine Learning Engineer 兼 Data Scientist。顧客のプロダクション統合をエンジニアリング側から支える立場。

着眼点

V1 が「スキー事故」と読んだ理由 — モデルは舞台が無ければ自分で組む (02:50)

V1 のプロンプトは事実上「これを分析して、過失を判定して」だけ。そこに 17 個のチェックボックスを持つ用紙と人間の手描きスケッチを渡すと、 Claude は「スキー事故」と読み、場所も「Schöpfanggatan」という実在しない通り名を出力した。この失敗が示すのは、 LLM は素材から最も自然な解釈を引き出すが、その自然な解釈は読者が想定するものとは限らない、ということ。

Christian の振り返り: 「クロードは確かに不可解な間違いをしたが、私たちは舞台を整えるために何もしていなかった、だからこの程度の失敗は理解できる」 (03:03)。これがフレームの転換点。プロンプトを「自分の頭の中の文脈をモデルが補ってくれる前提で書く」から、「Claude が読み取れる文脈は明示した分しかない前提で組み立てる」へ移行する。 24 分の残りはすべてこの転換に必要な部品の説明。

実用的含意として、評価データに「失敗したケース」を貯めるのが Applied AI チームの推奨パターン。「V1 がスキー事故と読んだ」は単なるエラーではなく、「テストケース」として登録する。 V2 以降のプロンプトを更新するたびに同じ入力を走らせて、「自動車事故と認識できるか」を測る。「あなたが解決しようとしている問題に実際に取り組んでいることを確認できる」 (03:36)。

タスク文脈とトーン文脈 — 役割と振る舞いを 2 段で渡す (03:44 - 06:00)

V2 で最初に追加されるのが 2 つの文脈要素。タスク文脈 = 「あなたは AI システムで、人間の請求査定人を支援する。スウェーデン語の自動車事故報告書を審査している。人間が描いた事故スケッチもある」。これだけで Claude の解釈空間が「保険業務における事故報告書の分析」に絞られる。

トーン文脈は別軸。「事実を述べる、自信を持って、推測しない、自信がない場合は評価しない」 — やってほしくない振る舞いを明示する。これは「幻覚を出すよりも『分からない』と言わせる」設計の機械的実装。 V2 の実演結果は「自動車事故と認識」「車両 A はチェックボックス 1、車両 B は 12」まで読み取り、「過失判定には情報不足」と Claude 自身が宣言した。不確実性の自己申告ができる状態に近づいた瞬間。

Hannah が強調するのは、役割定義だけでは足りない、という点。「ここで重要なのは、クロードに事実を伝えてほしいということ、自信を持ち続けるために」 (06:04)。役割 (= 何をする人か) と振る舞い (= どう振る舞うか) を 2 つに分けて書く、という指針が、後のすべてのバージョン改善のベースになる。

静的データはシステムプロンプト、動的データはユーザープロンプト (06:30 - 09:30)

V3 で追加されるのが「フォーム構造の事前説明」。 17 行のチェックボックスそれぞれの意味、列構造 (車両 A / 車両 B)、タイトルの場所、そして「人間が手書きで記入する、完璧にはならない、丸印 / 落書き / X 印など色々ある」という注意点まで含めて、フォームの読み方をシステムプロンプトに書き込む。

ここで重要な判断が 1 つ。この長い説明はシステムプロンプトに置く、ユーザープロンプトには置かない。理由は 2 つあって、第一に、フォーム構造は毎回変わらない静的データだから。「フォームは同じ、中身が違うだけ」という性質を活かして、プロンプトキャッシュを効かせる。第二に、 Claude にとって「フォームを毎回ゼロから読む」と「あらかじめ理解した形式の中身を読む」では認知負荷が大きく違い、後者の方が読み取り精度が上がる。

「次回もこのフォームを読む時間を Claude が短縮できる、そしてその間に蓄積された理解で読み取りも改善する」 (09:27)。効率 (レイテンシ・コスト削減) と精度 (読み取り誤りの低下) の両方が同じ設計判断で改善される、という稀少な例。 API でプロダクションパイプラインを組む時、「何が静的で何が動的か」をプロンプト設計の最初の問いに据える意味がここで言語化される。

XML タグで境界を引く — Markdown ではなく XML を選ぶ理由 (10:08 - 11:25)

Claude の訓練データには XML タグの解釈が多く含まれている (Anthropic 自身が訓練時に XML 形式の入出力を重視してきた経緯がある)。そのため <form>...</form> や <user_preference>...</user_preference> のような明示的タグは、「ここからここまでが特定の情報の塊」とモデルに伝わる。 Markdown も使えるが、タグの方が境界が明示的でブレない。

Hannah の説明: 「これからユーザーの好みに関するコンテンツを読み込む、これらの XML タグはタグで囲まれたすべてがユーザー設定であることを Claude に知らせる、そしておそらくプロンプトの後の時点で、 Claude がその情報を参照するのに役立つ」 (10:20)。タグは情報を「ラベル付き」で渡す装置として機能する。

実装の含意として、セクションごとに XML タグで包む癖を付けると、後でプロンプトを書き換えても境界がブレない。例えば <task> 内のタスク記述、 <context> 内の背景情報、 <examples> 内の例、という形で区切る。 LangChain や LlamaIndex の Prompt Template も裏で同様のことをしているが、自分でプロンプトを書くなら明示的にタグを使う方が制御しやすい。関連する Anthropic 公式リソースとして、 GitHub の anthropics/prompt-eng-interactive-tutorial が同じパターンで書かれている。

思考の順序を指定する — 一番大きな改善が起きた箇所 (17:00 - 19:30)

V4 で追加されるのは詳細なステップ指示。「まずフォームを見て、各ボックスごとに何が記されているかを注意深く確認する、そのリストを作る、そして次にスケッチを見る、これまでの事故についての理解を念頭に、フォームから学んだことをスケッチと照合する」という順序を明示する。

なぜこの順序指定が大きな改善を生むのか。 Hannah の解説: 「もしあなたが人間だったら、おそらく最初に図面を見て、何が起こっているのか理解しようとはしないでしょう」 (17:34)。スケッチは線と箱の集合に過ぎず、単独では曖昧。フォームを先に読んで「これは交通事故、特定の車両、特定のチェック項目」という骨格を得てからスケッチを見ると、図形に意味が乗る。 LLM も同じ。

実演結果: V4 ではフォーム読み取りが各ボックス個別の検査ステップに変わり、「ボックス 1 はチェックされていますか? チェックされていない? どうか?」と 1 つずつ確認する出力が生まれる。過失判定の自信度が上がり、「過失は車両 B」と明確な判定を出すようになる。 Hannah の評価: 「クロードのこの種の段階的な思考は、ここで正しい評価をするための能力において非常に影響力がある」 (19:32)。 Chain of Thought (CoT) プロンプティングの応用形だが、「考えろ」と曖昧に依頼するのではなく「これを先に、次にこれを、最後にこれを考えろ」と思考の順序まで指定する点が違う。

出力フォーマット = 「最終判定だけ XML タグで返す」 (19:30 - 21:30)

V5 で出力フォーマットを指定。「最終判定を <final_verdict>...</final_verdict> で囲む」。推論プロセスの説明は出してもいいが、アプリケーションが実際に必要とするのは判定だけ。タグ内の中身を正規表現や XML パーサで抽出すれば、 SQL データベースに保存したり、後続パイプラインに渡したりが安定する。

Christian の整理: 「派手な前置きは素晴らしいが、結局のところ、必要なのは情報。 SQL データベースに保存したい場所に保存する、そのために必要な情報。 Claude が判定を下すために考えた残りの部分は、実際にはアプリケーションには必要ない」 (20:30)。アプリケーションのコアが必要とする情報を明示的にラベル付けして返させる、という設計判断。

副次効果として、 Claude 自身も「最終判定で答える」ことを意識して推論を組み立てる。出力フォーマットを指定すると、モデルへの「ゴール宣言」として作用する。これは Anthropic Constitutional AI 系統の考え方で、「何をしてほしいかをモデルに直接書いて渡す」設計哲学が、プロンプトのフォーマット指定にも反映されている。

Pre-filled 応答 — クロードの口に言葉を入れる (22:10 - 23:00)

Pre-fill (事前入力された応答) の機能を使うと、 Claude の応答の最初の数トークンを事前指定できる。リクエストの assistant メッセージ枠に「<final_verdict>」を書いておくと、 Claude はそこから続けて出力する。前置き (「分かりました、では分析を始めます…」) は省かれ、タグの中身から直接始まる。

Christian の比喩: 「実際にクロードの口に言葉を入れている、つまり、事前に入力された応答」 (22:17)。抽象的な API 操作を直感的にする比喩が、講演中の小さな名フレーズの 1 つ。構文上は単なる assistant メッセージへの prefix 追加だが、効果は明確。

実用例として、 JSON 形式が必要な時は pre-fill でを入れると、 Claude は JSON で続けることを物理的に強制される。 XML 構造化出力でも同じ。プロンプト本文で「JSON で答えてください」と書くより、出力の物理的開始点を制御する方が確実で、パーサ側のエラー処理も簡潔になる。プロンプトキャッシュ + 構造化出力 + pre-fill の 3 点セットが、 API パイプラインの基本テンプレートになる。

拡張思考 = プロンプトエンジニアリングの「松葉杖」 (23:30 - 24:00)

Claude 3.7 / 4 系のハイブリッド推論モデルでは、拡張思考機能 (<thinking> タグ内のスクラッチパッド) を有効にできる。 Christian の表現が興味深い: 「これをプロンプトエンジニアリングの松葉杖として使える」 (23:33)。「足がかり」でも「補助輪」でもなく「松葉杖」 — 本来歩けるべきだが、まだ歩けない段階で使う支え。

使い方は 2 つ。第一に、単純に Claude に考える時間とトークン枠を確保させる。拡張思考をオンにすれば、最終応答までの間に Claude が <thinking> 内で問題を分解し、仮説を立て、検証する。結果として複雑な判定の精度が上がる。第二に、「思考過程を読めるデバッグログ」として使う。 Claude がどこで詰まっているか、どんな仮説に流れたかを <thinking> の中身で観察し、そこからプロンプト改善のヒントを得る。

「松葉杖」という選び方には含意がある。完璧なプロンプトを書けば拡張思考は不要、とも読める。 Christian の意図はおそらく「プロンプト設計の代替として頼り続けるのではなく、思考過程を観察して本来のプロンプト設計を上達させる足がかりにする」という意味。これは Anthropic Applied AI チームらしい姿勢で、「拡張思考でゴリ押し」ではなく「拡張思考で観察してプロンプトを直す」という運用ループを推奨する。

業界文脈

Anthropic Applied AI チームは、 Personality Alignment チーム (Amanda Askell が責任者) とは別軸の組織。 Personality Alignment が「Claude の人格・価値観・憲法の訓練」を扱うのに対し、 Applied AI は「顧客企業が Claude を製品にどう統合するか」のサポートと教育を担う。 Hannah Moran (元 PwC) や Christian Ryan (元 Voi Technology) の経歴が示すように、メンバーは企業 IT / B2B 製品開発のバックグラウンドを持つ。純粋研究組織ではなく、デプロイメント側の知見を蓄積する組織。

Code w/ Claude は Anthropic が 2025 年 5 月に SF で初開催した開発者向けイベント。 Boris Cherny (Claude Code リーダー) や Ami Vora (CPO) が登壇するメインキーノートに加え、本講演のような実践ワークショップが並行する構成だった。 1 年後の 2026 年 5 月には Code w/ Claude SF Extended が開催され、 Dickson Tsai (Claude Code エンジニア) が Remote Control / Voice mode / Auto memory / Routines などの新機能解説をする回まで続いている。「Anthropic 公式の体系的なプロンプト・コーディング教材を提供する」文化が、このシリーズで定着していった。

業界全体で見ると、 2025 年は「プロンプトエンジニアリングは不要になる」言説が広まっていた時期。モデルが賢くなれば、ユーザーの自然言語で十分、という主張。本講演はその逆の立場 — モデルが賢くなるほど高度な能力を引き出すには、入力の設計が出力の質を左右する割合は変わらない、むしろ責任が大きくなる。「Claude が読み取れる文脈は明示した分しかない」という前提から始める姿勢が、業界の楽観論への控えめな反駁になっている。

関連 Anthropic 公式教材との比較

Anthropic は同じテーマを複数の形式で提供している。本講演「Prompting 101」が単発タスクの基礎、続編の「Prompting for Agents」 (Code w/ Claude SF 2025 の別エピソード) が複数ターン・ツール呼び出しを含むエージェントの場合、 GitHub の anthropics/prompt-eng-interactive-tutorial が自分で実行して学ぶ対話型教材、 Anthropic Console の Prompt Generator が「タスクを与えると Anthropic 推奨フォーマットで Claude がプロンプトを書く」機能、という住み分け。

OpenAI 系の prompt engineering ガイドとの違いも明確。 OpenAI は「最良のプロンプトのチェックリスト」寄りで、「明確に書く」「例を与える」「段階的に考えさせる」といった原則を箇条書きで整理する。 Anthropic は「プロンプトを訓練データの一部として扱う」寄りで、 XML タグや system / user / assistant の役割分担、 pre-fill のような構造的な操作に深く踏み込む。後者は Constitutional AI の系譜から来る発想で、「モデルにルールを直接書いて渡す」という設計判断がプロンプト記法にも反映されている。

実装上の含意

API でチャットボットや LLM パイプラインを構築する場合、本講演の実用的示唆は 3 つに整理できる。

第一に、システムプロンプトとユーザープロンプトを意図的に使い分ける。静的データ (フォーム構造、ドメインルール、役割定義) はシステムプロンプトに。動的データ (ユーザー入力、タイムスタンプ、セッション ID) はユーザープロンプト経由で。プロンプトキャッシュが効くかどうかが、 1 リクエストあたりのコストに直結する (Anthropic API では cache_control パラメータで明示的にキャッシュ範囲を指定する)。

第二に、出力フォーマットを XML タグで指定 + pre-fill で先頭を強制する組み合わせを使う。自由形式テキストは見栄えは良いが、後続処理に苦労する。 <final_verdict> のような明示的タグを Claude に書かせ、さらに assistant メッセージの prefix で確実にそこから出させる。製品レベルでの再現性が確保される。

第三に、拡張思考を「デバッグ用ログ」として利用する。製品本番では拡張思考をオフにしてコスト削減してもいいが、プロンプト改善のテスト段階では <thinking> の中身を読むと Claude がどこで詰まっているかが見える。これがプロンプト改善ループの起点になる。拡張思考オンで観察 → プロンプト修正 → 再テスト → 修正に効果があれば拡張思考オフでも改善が残る、という運用パターン。

批評的な視点

本講演で示される V1 → V5 の進化は理想化されすぎている面もある。実プロダクトでは V2 から V3、 V3 から V4 への移行で「効果がない」「むしろ悪化した」という pivot もよく起きる。講演ではすべてがスムーズに改善するが、実際のプロンプト開発は試行錯誤の方が多い。評価データのテストケース 5-10 件を走らせて、「平均では改善したが特定ケースで悪化した」「Edge case がいくつか壊れた」という観察を経て次の判断をする、というループが実態。

題材選択にも偏りがある。スウェーデン自動車保険報告書は「明確な構造を持つ文書 + 明示的なルール体系」という、 LLM が比較的得意とする領域の典型例。自由文ベースの法律相談、医療診断、創造的執筆など「構造が曖昧な領域」では、同じ V1 → V5 アプローチが同じように効くとは限らない。例えば「思考の順序を指定する」効果は、順序が明確な問題ほど大きく、順序自体が問題の一部である問題では別のアプローチが必要になる。

「拡張思考は松葉杖」という表現にもニュアンスがある。講演者の意図は「プロンプト設計の足がかり」だが、実プロダクトでは「松葉杖に頼って本来のプロンプト設計を省く」ことになりやすい。拡張思考の動的トークン消費はコスト面でも影響が大きいので、本番投入時の判断材料として「いつ松葉杖を外すか」の指針があるとさらに有用だった。それでも、 24 分で 10 要素のプロンプト構造を体系的に伝え、ライブデモで効果を見せる回として、これは現時点で最も実用的な Anthropic 公式教材の 1 つ。

読者へのテイクアウェイ

既存のプロンプトを開いて、タスク文脈とトーン文脈が冒頭に書かれているか確認する。書かれていなければ、数行追加するだけで応答品質が変わる
静的データと動的データを区別して、静的データはシステムプロンプトに移す。 Anthropic API では cache_control パラメータでプロンプトキャッシュを有効化できる
構造化出力が必要な場合、出力フォーマットを XML タグで明示 + pre-fill で先頭を強制する。後続のパース処理が安定する
Claude が間違える時、まず拡張思考をオンにして <thinking> を読む。どこで判断を誤っているかが見える。そこから逆算してプロンプト側を修正する
「思考の順序」を明示する。「まずこれを見て、次にこれを見て、最後に判定する」と書くだけで、最終判定の質が変わる
失敗ケースをテストケースとして蓄積する。プロンプト改善のたびに走らせて、過去の失敗が再現しないか確認する

動画の構成

(00:00) 自己紹介とワークショップの趣旨。 Hannah Moran と Christian Ryan が Anthropic Applied AI チームから登壇し、「実例で学ぶプロンプトエンジニアリングのベストプラクティス」という方向性を提示する。スウェーデン自動車保険会社の事故請求処理という題材を導入
(01:42) 題材の詳細紹介。入力は (1) 17 個のチェックボックスを持つ交通事故報告フォーム (スウェーデン語)、 (2) 人間が手描きの事故スケッチ。 Hannah がスウェーデン語を読めないが Christian は読める、という補足が、 LLM ベースの解決策の必要性を浮かび上がらせる
(02:30) V1 のライブデモ。シンプルなプロンプト + 画像 2 枚を Anthropic Console に投入。 Claude 4 Sonnet モデル、 temperature ゼロ、 max tokens 大きめの設定。結果: 「スキー事故」と誤読、実在しない通り名を生成
(03:22) 「プロンプトエンジニアリングは反復的な経験科学」という再フレーミング。完璧なプロンプトを 1 発で書こうとせず、テストケースを走らせながら改善するループを回す、という姿勢の提示
(03:44) 10 要素フレームワークの導入予告。タスク文脈、トーン文脈、背景データ、詳細指示、例、会話履歴、即座のタスク説明、思考の段取り、出力フォーマット、 pre-fill された応答、の 10 要素を順に説明していく構造を提示
(04:32) タスク文脈とトーン文脈の解説。「あなたは AI システムで、人間の請求査定人を支援する」のような役割定義 + 「事実を述べる、自信を持つ、推測しない」のような振る舞い定義の 2 段構え。 V2 として再投入し、「スキー事故」から「自動車事故」への改善を実演
(06:30) 背景データ (フォーム構造) の事前説明を V3 として追加。 17 行それぞれの意味を Claude に伝える。静的データはシステムプロンプトに置く判断、プロンプトキャッシュとの相性、認知負荷の差が解説される
(09:30) 情報整理の方法 (XML タグ vs Markdown)。 Claude の訓練データには XML が多く含まれているため、構造境界を XML タグで引くのが効く、という設計判断。ユーザー設定や背景文書を <user_preference>...</user_preference> のようなタグで囲む例
(12:42) 例 (Few-shot プロンプト) の紹介。ライブデモではすべて含めないが、実際のプロダクトでは難しい判定基準を例で示す方が、言葉で説明するより効く。 Base64 エンコードされた画像例 + 説明を組み込む手法
(15:00) 会話履歴と詳細なタスク指示への移行。ユーザー向けアプリでは会話履歴を活用、バックエンドパイプラインでは詳細タスク指示を組み込む、という使い分け
(17:00) 思考の順序を指定する V4。「まずフォームを読む → ボックスリスト作成 → スケッチを見る → 最終判定」という人間の自然な解析手順を Claude に渡す。個別ボックスの注意深い検査が観察される
(19:30) 出力フォーマット V5。「最終判定を <final_verdict> タグで囲む」という指示で、 API で後続処理が安定する
(22:00) Pre-filled 応答の解説。「クロードの口に言葉を入れる」という比喩で、 Claude のターン開始時に最初のトークンを事前指定する技を紹介。 JSON / XML 構造化出力を確実にする手法
(23:00) 拡張思考機能の活用。 Claude 3.7 / 4 のハイブリッド推論モデルで、 <thinking> タグ内のスクラッチパッドを観察してプロンプト改善のヒントを得る。「プロンプトエンジニアリングの松葉杖」という表現が使われる
(24:00) 締めくくり。続編の「Prompting for Agents」への案内、 Claude Plays Pokemon の宣伝

重要な引用

「(プロンプトエンジニアリングとは) 言語モデルと通信し、望むことを実行させようとする方法」 (00:26)
「これを学ぶための最良の方法は、それを実践すること」 (00:47)
「私たちのプロンプトでは、実際には舞台を整えるために何もしていない」 (Christian、 V1 失敗の振り返り、 03:03)
「プロンプトエンジニアリングは、非常に反復的な経験科学」 (03:22)
「クロードに、何しに来たの? あなたの役割は何? 今日はどのようなタスクを達成しようとしている?」 (Hannah、 04:25)
「事実を述べる、自信を持つ、推測しない、自信がない場合は評価しない」 (V2 のトーン文脈、 04:34)
「クロードは本当に構造が大好きで、組織が大好きなのです」 (Hannah、 09:44)
「これらの XML タグは、タグで囲まれたすべてがユーザーの設定に関連していることを Claude に知らせる」 (Hannah、 10:20)
「人間がこのフォームに記入している、完璧にはならない、丸印 / 落書き / X 印を入れない、など色々なパターンがある」 (11:30)
「もしあなたが人間だったら、おそらく最初に図面を見て、何が起こっているのか理解しようとはしないでしょう」 (17:34)
「クロードのこの種の段階的な思考は、ここで正しい評価をするための能力において非常に影響力がある」 (19:32)
「派手な前置きは素晴らしいが、結局のところ、必要なのは情報」 (Christian、 20:30)
「実際にクロードの口に言葉を入れている、つまり、事前に入力された応答」 (Christian、 22:17)
「拡張思考をプロンプトエンジニアリングの松葉杖として使える」 (Christian、 23:33)
「これはトークンの効率が高いだけでなく、これらのインテリジェントなトークンがどのように機能するかを理解する良い方法」 (24:01)

出典

Prompting 101 | Code w/ Claude — Hannah Moran × Christian Ryan, Anthropic Applied AI

関連 Anthropic 公式リソース:

ハンナ・モラン

Hannah Moran

Anthropic Applied AI チーム / 元 PwC AI & Emerging Technology Technical Lead

クリスチャン・ライアン

Christian Ryan

Anthropic Applied AI Engineering Manager (London) / 元 Voi Technology Machine Learning Engineer

用語集

プロンプトエンジニアリング: 言語モデルへの入力 (= プロンプト) を設計する技術。モデルにタスクを完了させるための文脈、役割、指示、例、出力フォーマットなどを明示的に書き込む。 Anthropic は「反復的な経験科学」と位置付ける。
システムプロンプト (System Prompt): LLM の振る舞いを規定する最上位の指示文。 API リクエストの system フィールドに渡され、ユーザーメッセージとは別の層として扱われる。役割定義、トーン、静的な背景情報を置くのが定石。
ユーザープロンプト (User Prompt): ユーザーからモデルへの実際の入力。 system プロンプトの後に追加され、リクエストごとに内容が変わる動的データを置く層。通常はシステムプロンプトより短く、セッションや問い合わせ固有の情報を含む。
プロンプトキャッシュ (Prompt Caching): 同じプロンプト前半を複数リクエストで再利用する仕組み。 Anthropic API では cache_control パラメータで指定すると、ヒット時にレイテンシとコストが大幅に下がる。 1 時間程度の TTL を持つ。
XML タグ: <tag>content</tag> 形式の構造化マークアップ。 Anthropic の訓練データには XML 形式の入出力例が多く含まれており、 Claude は XML 境界を強く認識する。セクションごとに <task> <context> <examples> のようなタグで囲むのが Anthropic 推奨スタイル。
Markdown: 軽量マークアップ言語。 # で見出し、 * で強調、 - でリスト等。 Claude は Markdown も解釈できるが、構造境界の明示性では XML タグに劣る (見出しと本文の物理的境界が暗黙的)。
Chain of Thought (CoT): 思考の連鎖プロンプティング。 LLM に最終答だけでなく途中の推論ステップを出力させる手法。「Let's think step by step」のような誘導句で性能が上がるという 2022 年の論文以降、 LLM の標準テクニックの 1 つ。
Pre-fill (事前入力された応答): API リクエストの assistant メッセージ枠に、モデルの応答の冒頭を事前に書き込む技。 Claude はそこから続けて出力するため、前置きを省略させたり、 JSON / XML 等の特定フォーマットを物理的に強制したりできる。 Anthropic API では Messages API の最後のメッセージを assistant role で送ると pre-fill が有効化される。
ハイブリッド推論モデル: 同一モデルが「通常応答モード」と「拡張思考モード」を切り替えられるアーキテクチャ。 Claude 3.7 Sonnet (2025 年 2 月リリース) から導入。 API リクエスト時に thinking パラメータで有効化し、トークン枠と思考時間を確保する。
拡張思考 (Extended Thinking): モデルが応答前に内部スクラッチパッド (<thinking> タグ内) で問題を分解・推論する機能。 Anthropic は「extended thinking」と呼ぶ。拡張思考中のトークンも課金対象だが、複雑な判定の精度が上がり、思考過程をデバッグできる。
Constitutional AI: Anthropic が開発した訓練手法。モデルに「憲法」 (= 倫理原則の文書) を与え、モデル自身が出力候補を憲法に照らして自己評価・自己修正することで報酬シグナルを作る。人間ラベラーを介する RLHF に対し、 AI が AI を評価する RL-AIF (Reinforcement Learning from AI Feedback) と呼ばれる。
RLHF (Reinforcement Learning from Human Feedback): 人間のフィードバックによる強化学習。 LLM の応答候補に人間がランク付けし、そのデータで報酬モデルを訓練、さらに強化学習でモデルの応答を改善する手法。 InstructGPT (2022) で ChatGPT の中核技術として確立。
Few-shot プロンプト: プロンプト内にタスクの実行例を数件示してから、実際の問い合わせを置く手法。 0 件 (zero-shot)、数件 (few-shot)、多数件 (many-shot) の対比で語られる。例の示し方で出力の質が大きく変わる。
temperature: LLM の出力ランダム性を制御するパラメータ。 0 に近いほど決定論的 (毎回ほぼ同じ出力)、高いほど創造的 (出力にバラつき)。評価タスクや構造化出力では 0 が定石、ブレインストーミングでは 0.7-1.0 程度が多い。
max tokens: LLM の応答が出力できる最大トークン数。トークンは英語の場合おおむね 4 文字 ≒ 1 トークン、日本語は 1 文字 ≒ 1 トークン程度。設定が小さすぎると応答が途中で切れる。

comment is stripped from the HTML output. */}