down-skilling

ダウンスキリング：Opus → Haiku の蒸留

推論能力を、Haiku 5.5 が確実に実行できる、明示的で構造化された指示に変換します。あなたはコンパイラーです。入力はコンテキスト、意図、ドメイン知識であり、出力は判断手順と多様な例を備えた、Haiku 向けのプロンプトです。

基本原則

Opus は WHY から推論します。Haiku は WHAT と HOW に基づいて実行します。

あなたの仕事は、暗黙の推論、文脈に応じた判断、専門知識を、明示的な手順、具体的な決定木、実例へと変換することです。あなたが暗黙のうちに行う推論はすべて、Haiku には明示する必要があります。

コスト：例を惜しむ必要がない理由

Opus 5.5 のコストは、入力・出力の両方で Haiku 5.5 の40倍です（100K トークンまでのプロンプトの場合、1 MTok あたり $4/$20 対 $0.10/$0.50、2026-10 時点の価格）。Sonnet 5.5 は20倍です。Opus で $1.00 かかるタスクは Haiku なら約 $0.025 で済むため、再試行しても節約分がなくなることはありません。Haiku は何度失敗して再試行しても、Opus の1回の試行より安く済みます。（Haiku 4.5 が $1/$5 だったころは5倍で、1回再試行すると節約分は半分になりました。）今や失敗の代償は、主にコストではなく、検証で見つからなかった、もっともらしい誤答という 見えない エラーです。

重要な計算：

• 入力トークンは安価です（Haiku 5.5：入力は 1 MTok あたり $0.10、出力は $0.50）
• 例を2,000トークン追加しても、1回の呼び出しあたり約 $0.0002 です
• オーケストレーターには、検証器と、検証器の失敗出力を添えた前回の出力を使って再試行する仕組みを与えます。2026-10-07 の修復テストでは、Haiku 5.5 はその方法ですべての rung-1 の失敗を修復しました（agent-routing）
• 検証器では見つけられない失敗を防ぐのは、例をさらに増やすことではなく、リリース前にテストセットを実行することです（以下の「まずは何も追加しない」を参照）

プロンプト設計で重要なこと：

• 8K トークンのドキュメントを送る場合、3～4K トークン分の例を追加できます。例のコストはドキュメント自体より安価です
• 入力プロンプトが長くなっても出力コストは増えません。出力の料金は入力の長さとは無関係です
• 制約となるのはトークンのコストではなく、効果の逓減です。5～7個を超える例を追加しても、性能が向上することはほとんどありません

結論： 5.5 の価格では、トークンはもはや制約ではありません。高くつくのは、判断ルールを調整する例なしでリリースすることと、テストセットの代わりに例を使うことです。どちらも、誤答をそのままリリースすることにつながります。

Haiku 5.5：まずは最小限から始め、失敗を見て必要なものだけを追加する

2026-10-07 に、このスキル独自の要約プロンプト（フィードバック抽出、モデレーション、SQL）を3つ使って測定しました。それぞれ、配布時の状態で <examples> を削除し、最小限の状態（タスク、ラベル名、出力スキーマのみ）で実行しました。各条件を2回ずつ実行しました（oaustegard/experiments → downskill-shots）。

条件	ルールで決まる項目	例で決まる項目
配布時（ルール＋例）	40/40	22/24
最小限（ルールなし、例なし）	38/40	20/24
例なしでルールのみ	40/40	15/24

ここから3つのことがわかります。Haiku 5.5 は、ルールを適用するのに例を必要としません。例を多用するプロンプト向けに書かれたルールは、例を取り除くと誤解を招きます。モデルはルールを文字どおりに解釈するからです。「表面上の内容が敵意を示している → フラグを付ける」というルールは、記事に対する厳しい意見にもフラグを付けましたが、例では APPROVED と示されていました。また、モデルが推測できない独自の慣例（支出は完了済みの注文のみを数える）は、例を通じて2回の実行のうち1回でしか伝わりませんでした。そのため、ルールとして明記してください。

Haiku 5.5 での手順：

1. 最小限のプロンプトを作成します。役割、タスク、有効なすべてのラベル、出力スキーマを含めます。
2. 期待される出力を付けたテスト入力を10～20個作成し、そのうち少なくとも3分の1は判断の境界に関するものにします。最小限のプロンプトで実行します。
3. 失敗するたびに、それを修正する最小限の要素を追加します。
   • 明記されていない既定値や独自の慣例（「some」は LIMIT 10 を意味する、支出は完了済みの注文のみを数える）→ 明示的なルールを1つ追加します。
   • 判断の境界（意見と嫌がらせ、MIXED と NEGATIVE）→ その境界に関する例を1つ追加し、<reasoning> を付けます。判断ルールを追加する場合は、判断基準を示す例も必ず追加してください。
4. 再実行します。テストセットに合格したら終了します。典型的なケースの例は、ここでは何も追加しません。
5. 書き換えや要約では、明示的な創作禁止ルールを残します。これがないと、8件中3件の書き換えで、原文にない事実（「さまざまなワークロードでテストしました」）が記載されました。創作防止のために、事実を列挙する手順だけに頼らないでください。5.5 では、その手順をプロセス内に隠した場合、表示される <facts> ブロックにした場合、プロンプト内でリストを渡した場合、あるいは省略した場合のいずれでも、64件の書き換えのうち技術的な詳細を創作したものはありませんでした（2026-10-08 に再テスト）。創作防止の例（沈黙をモデル化する）も任意です。Haiku 4.5 で20件中19件の結果を出したセットでも、5.5 では8件中0件でした。
6. 事実リストによって書き換えで引き継ぐ内容が決まるため、意図して選んでください。
   • Haiku が自分で作成するリストには、原文が自らについて述べている主張も事実として記録されます（「チームはこれをパラダイムシフトだと説明している」）。そして、書き換えでもその内容が繰り返されます（8/8）。これらを含めたくない場合は、ルールとして明記してください。
   • プロンプト内で渡したリストは、記載漏れも含めてそのまま守られます。「リリース予定である」を含めなかったリストを渡したところ、8件中2件の書き換えで製品が「ベータ版」とされました。原文と照合済みの場合に限り、リストを渡してください。
7. Haiku 5.5 の推論の進め方を指示しないでください（「3～5段階で考える」、「推論では、まず……を列挙する」など）。Anthropic のシステムカードでは、自らの思考内容についての指示に従う割合は約0％と測定されています（図 6.4.2.4.A）。結果が必要な手順は、確認できるように表示される出力に含め、推論の長さは effort パラメーターで設定してください。

通常は例が0～3個で済み、4～7個にはなりません。このファイルの残りは Haiku 4.5 向けの方法です。Haiku 4.5 にはそれを使い、手順3で必要とされる境界例にも使ってください。

蒸留の前に：そのタスクに蒸留が必要か確認する（2026-07 校正）

このスキルのギャップカタログは、もともとモデルカードの事前知識に基づいて作成されました。 2026-07-15 に実施された実測校正（Haiku 4.5 で300回測定。データは agent-routing スキルの references/calibration-2026-07-15.md に記載）では、 機械的に検証可能な作業において、Haiku 4.5 はそうした事前知識からの予測を大幅に上回ることがわかりました。具体的には、入れ子になったモジュラー算術（16個の葉を持つ式ツリー）、30ホップの関数チェーン、25個の操作にわたる状態追跡、ひっかけの多い文章題、5つの同時制約を満たす文の生成（単語数の厳密な指定、必須／禁止トークン、リポグラム）で、effort: low において240/240を達成しました。また、1つの対照実験では、思考の連鎖を完全に抑制した状態でも同じ結果でした。同じテスト群で、Sonnet は低い努力レベルで17/20のスコアを記録し、Haiku が満たした厳密な文字数制約を満たせませんでした。

本格的な蒸留に取り組む前に、次の手順で振り分けてください。

1. 出力が機械的に検証可能（スキーマが検証に通る、テストを実行できる、個数を数えられる、正規表現に一致する）ですか？ → 最小限のプロンプトに決定論的な検証器を組み合わせ、失敗時に再試行または上位モデルへ切り替えるほうが、検証器なしで例を大量に含めたプロンプトよりも安価で信頼性が高くなります。例を書くことではなく、チェッカーの作成に労力をかけてください。「ちょうどN語」のような精度に関する制約は、プロンプトで数え方のルール（「語とは、文字またはアポストロフィが連続したもの」）を明示すると安定して守られました。効果があったのは定義の精度であり、足場かけの量ではありません。
2. 出力に判断が必要（トーン、関連性、品質、曖昧さの解消）ですか？ → このスキルの残りの部分は、まさにそのためのものです。手順、評価基準、nショットの例を含めて、徹底的に蒸留してください。
3. 両方が混在していますか？ → タスクを分割してください。検証可能な部分には（1）の方法を適用し、判断が必要な部分だけを蒸留します。

反復に関する警告（同じ校正での実測結果）： Haiku に、自身の出力を何も考えずにループ内で再改善させてはいけません。正しい回答では、再適用しても同一の出力が返されました（96組のループで変更は0件）。変化した1つの出力は、2回目の処理で品質が低下し、その後のすべての処理で劣化したテキストのまま固定されました。反復する場合は、各反復を外部のチェッカーまたは評価器で採点し、argmax を保持して、最初に品質が低下した時点で停止してください。

アクティベーション

起動時に、次の手順を実行します。

1. 会話からタスクのコンテキストを抽出します。ユーザーは何を達成しようとしていますか？どのような分野の知識が当てはまりますか？重要な品質基準は何ですか？

2. 推論の不足箇所を特定します。Opusなら自動的に推測するものの、Haikuには明示する必要があるのはどのような点ですか？よくある不足箇所は次のとおりです。

   • 曖昧さの解消（Opusは妥当な解釈を選びますが、Haikuには判断基準が必要です）
   • 品質の判断（Opusは「十分に良い」状態を把握しますが、Haikuには明確な基準が必要です）
   • エッジケースへの対応（Opusは新しい状況について推論しますが、Haikuにはケースの列挙が必要です）
   • 出力の調整（Opusは直感的にトーンや長さを合わせますが、Haikuには明示的な制約が必要です）

3. プロンプトの構成の構造に従って、要点を絞ったプロンプトを作成します。

4. 例を追加します。 Haiku 5.5では、まずは例なしで開始し、何も加えない状態での実行が失敗した境界ケースに限ります。通常は0～3件です。Haiku 4.5では、例の設計に従って、多様な例を4～7件作成します。これは、Haiku 4.5で最も効果の高い手順でした。

5. 提出前に例のセットを監査します。 次の2つのチェックに両方とも合格する必要があります。

   • 入力への根拠づけ： 各例の出力に含まれる具体的な事実（名前のある技術、数値、比較、引用された語句など）が、すべてその例の入力から推測できることを確認します。入力だけを読んで出力を再現できない場合は、入力に詳細を追加するか、出力から削除します。例に作り話が含まれると、Haikuは実行時にその捏造パターンを模倣します。
   • 長さの調整： 例の出力の長さが、指定した出力範囲内に収まっていることを確認します。「60～90語」と指定しているのに、例の平均が35語なら、そのルールは守られません。Haikuは例の中心的な傾向に従います。

   どちらかのチェックに失敗した場合は、提出前に該当する例を作り直します。例はルールより強く作用します。ルールと整合しない例は、整合するルールよりも強く作用します。

6. システムプロンプトとユーザープロンプトの各要素を適宜含めた、Haikuですぐ使える完全なプロンプトを、コピー可能な成果物またはファイルとして提出します。

プロンプトの構成

要点を絞ったプロンプトはすべて、次の要素をこの順序で構成します。Haikuは、この特定の順序に最もよく応答します。

<role>
[Single sentence: who Haiku is and what it does]
</role>

<task>
[2-3 sentences: the specific task, its purpose, and the deliverable]
</task>

<rules>
[Numbered list of explicit constraints. Be precise about:]
- Output format (JSON schema, markdown structure, etc.)
- Length bounds (word/token counts, not vague "brief"/"detailed")
- Required elements (must-include fields or sections)
- Prohibited behaviors (specific failure modes to avoid)
- Decision rules for ambiguous cases
</rules>

<process>
[Numbered steps. Maximum 7 steps. Each step is one action.]
[Include validation checkpoints: "Before proceeding, verify X"]
[Include decision points: "If X, do Y. If Z, do W."]
</process>

<examples>
[Haiku 5.5: 0-3 boundary examples, each calibrating a judgment rule]
[Haiku 4.5: 4-7 diverse examples; the LARGEST part of the prompt]
[See Example Design section for distribution requirements]
</examples>

<context>
[Task-specific data, reference material, or domain knowledge]
[Use labels: [Context], [Policy], [Reference]]
</context>

Haiku最適化ルール

Haikuを対象とするプロンプトを作成するときは、次のルールを適用します。

構造と構文

• 各セクションをXMLタグで囲みます。Haikuはラベル付きの境界を正しく認識します。
• 可能な限り、文は25語未満にします。
• 1文につき指示は1つにします。複数の指示を含む文は分割します。
• トークン数または語数の上限を明示します。「80～120語で回答してください」のように指定します。
• 手順は散文の段落ではなく、番号付きリストで示します。

推論の支援

• 自由形式の判断を、判断基準に置き換えます。
  • 悪い例：「コードが本番環境で使える状態か評価してください」
  • 良い例：「以下を確認します：（a）TODOコメントがない、（b）すべての関数にエラー処理がある、（c）ハードコードされた秘密情報がない。項目ごとに合格または不合格を判定してください。」
• 推論の深さを制限します。「3～5段階で考えてから回答してください」（Haiku 4.5の場合。上記の手順7で述べたように、Haiku 5.5では、これは指示に従う処理ではなく、指示の効かない推論に影響します。）
• 不確実な場合の代替手段を提示します。「Xを判断できない場合は、『不明：［簡単な理由］』と回答してください。」

コンテキスト管理

• 重要な指示を最初に配置します（Haikuは前方の情報を強く重視します）。
• 目安の予算（Haiku 4.5）：指示とルールは合計800トークン以下にします。残りを例に使います。8Kトークンの文書を処理するタスクでは、例に3～4Kトークンを使うことは十分に予算内であり、信頼性の向上に役立ちます。
• 文書全体ではなく、最も関連性の高いコンテキストの抜粋を1～3件だけ渡します。
• コンテキストと指示の間には、明示的な区切りを設けます。

出力の制御

• 抽出可能な結果には、構造化された出力（JSON、ラベル付きセクションなど）を要求します。
• Haikuが内容を記入できる出力テンプレートを用意します。
• 回答の最初に記載する内容を指定します。「回答は次の文で始めてください」のように指示します。
• 分類タスクでは、使用可能なカテゴリをすべて列挙します。

失敗の防止

• Haiku によくある失敗モードを予測し、ガードレールを追加します。
  • ハルシネーション：「提供されたコンテキストの情報のみを使用してください。 答えがコンテキストにない場合は、『ソースに見つかりません。』と答えてください。」
  • 冗長さ：「最大 150 語です。前置きや但し書きは追加しないでください。」
  • 形式の逸脱：出力スキーマをルールと例の両方に含めます
  • 指示の読み飛ばし：すべての制約に番号を付け、プロセスの手順で参照します：「 のルール 2〜4 を適用してください」

例の設計

Haiku 4.5 では、例への投資が最も効果の大きい取り組みでした。 Haiku 5.5 では役割が、判断ルールの調整と、何を言わずにおくべきかを示すことに絞られます。Start Bare を参照してください。このセクションの残りは、4.5 向けの手法です。 ルールは Haiku に何をすべきかを伝え、例は「正しい仕上がり」がどのようなものかを示します。ルールと例が矛盾する場合、Haiku は例に従います。 ルールが曖昧な場合、Haiku は例から推測します。そのため、例は主要な誘導手段です。ルールの補足ではなく、最も強いシグナルとなります。

コスト面（コスト を参照）を踏まえると、ここに十分な投資をするべきです。ルールが 800 トークンで例が 3,000 トークンのプロンプトは、ほとんどの場合、ルールが 2,000 トークンで例が 500 トークンのプロンプトより優れた結果を出します。

最低限の例の数：4（Haiku 4.5）

Haiku 4.5 では、蒸留したプロンプトごとに、多様な例を4〜7 個用意してください。4 個未満では投資が不十分です。例を 1 つ追加する限界コストは、信頼性の向上と比べてごくわずかです。次の内訳を使用してください。

#	役割	目的
1	典型的なケース	最も一般的で、単純な入力です。基本となるパターンを確立します。
2	2 つ目の典型的なバリエーション	#1 とは長さ、分野、構造が異なる、別の一般的な入力です。Haiku が単一のパターンに過剰適合するのを防ぎます。
3	エッジケース	空のフィールド、非常に長いテキスト、特殊文字、境界条件、曖昧な表現など、まれでも有効な入力です。
4	否定的なケース（BAD/GOOD のタグ付きペア）	Haiku がもっともらしいが誤った内容を出力する可能性のあるタスク（書き換え、要約、自然言語からコマンドへの変換、確信をもって具体的に答えるほど有利になるタスクなど）では、「BAD output:」と「GOOD output:」のタグを付けた例のペアを含め、このタスクで防ぎたい具体的な失敗モード（アーキテクチャの詳細、CLI フラグ、数値の捏造など）を示します。一般的な「悪い出力」の例よりも、Haiku が陥りやすい失敗の種類を明示した例のほうがはるかに効果的です。
5+	扱いにくいケース／境界ケース	判断の境界に近く、Haiku が最も失敗しやすい入力です。テストスイートに使うようなケースです。

2 つ目の典型的なケースが重要な理由： 典型的な例が 1 つだけだと、Haiku はその例に含まれる偶発的な特徴（長さ、言葉選び、分野）に引きずられることがあります。異なる観点からの 2 つ目の典型例を示すことで、タスクに関係する特徴と、偶然の特徴を Haiku に伝えられます。

例の形式

<example>
<input>
[Realistic input data — use real-world length and complexity]
</input>
<output>
[Exact format Haiku should produce — not a description, the actual output]
</output>
<reasoning>
[1-2 sentences: WHY this output is correct. Which rules applied.
 What Haiku might have gotten wrong without this example.]
</reasoning>
</example>

複雑なタスクでは、<reasoning> タグは必須です。 これは思考の連鎖を支える手がかりとなり、Haiku に従うべき推論パターンを示します。分類や抽出のタスクでは、推論の中で判断の根拠となる具体的なルール番号を参照してください。

入力が抽象的になり得る場合：情報のない部分を明示する

書き換え、要約、音声・文体の編集、原文に基づく説明などのタスクでは、入力元の内容自体が抽象的な場合があります。たとえば、マーケティング文、曖昧な説明、概要レベルの要約などです。こうしたタスクでは、原文にはないものの、その分野ではもっともらしく聞こえる具体的な詳細を Haiku が捏造する失敗が特に起きやすくなります。

**症状：**入力にないアルゴリズム名、技術の選択、パーセンタイルの数値、バージョンの比較などの詳細を、出力が確信を持って述べます。

**対策：**入力が本当に抽象的で、もっともらしい推測で空白を埋めるのではなく、何が指定されていないかを明示する出力例を含めます。パターン：

<example>
<input>
"We're excited to release our new search backend. We think it's a
massive upgrade over the old one."
</input>
<output>
New search backend released. The announcement does not specify the
underlying changes — whether they affect indexing, ranking, query
parsing, or operational characteristics is not stated. Migration
guidance will follow. The old search path remains available during
transition.
</output>
<reasoning>
The source provides only one factual claim ("released") and one
unverifiable claim ("upgrade"). The output stays at the source's
level of abstraction and explicitly names the categories of
information the source omits, rather than inventing plausible
specifics (algorithm changes, performance numbers, technology names).
</reasoning>
</example>

これと、上記の分布表の4行目にある BAD/GOOD タグ付きの否定例を組み合わせ、防ぎたい捏造を具体的に示します。音声の書き換えタスクでは、根拠のない例からこのパターンに切り替えたところ、Haiku のアーキテクチャに関する幻覚の発生率が95％から0％に低下しました（2つのプローブで計25件）。

例の規模に関する指針（Haiku 4.5）

タスクの処理対象…	推奨する例の量
短い入力（<500 tokens）	例として1,500～2,500 tokens（4～5例）
中程度の入力（500～4K tokens）	例として2,500～4,000 tokens（4～6例）
長い入力（4K～8K tokens）	例として3,000～5,000 tokens（5～7例）

ここではコンテキストは制約になりません。Haiku 5.5 のコンテキストウィンドウは1Mですが、100K tokensを超えるプロンプトは、入力側と出力側の両方で5倍の料金がかかります（MTokあたり$0.50/$2.50）。制約となるのは効果の逓減です。タスクの分類空間が非常に大きい場合を除き、例が7つを超えると追加による効果は急激に小さくなります。

例の品質基準

• 例はおもちゃのようなデータではなく、現実的なものにします。実際の入力の複雑さや雑然さに合わせてください
• すべての例で出力形式を完全に同一にします。Haiku は形式の不一致を、形式が重要ではないという合図として扱います
• Haiku に処理させると想定する最も難しいケースを含めます
• 長さ、複雑さ、分野、トーンなど、入力の特性に変化を持たせます
• ルールに反する例は決して含めません
• 例は最も簡単なものから最も複雑なものへと並べます。この段階的な難易度により、Haiku の理解が深まります
• **具体的な事実にはすべて原文の根拠を持たせます。**例の出力に含まれる具体的な名詞、数値、主張は、それぞれその例の入力から推測できるものでなければなりません。例の出力で、もっともらしいアーキテクチャの詳細を捏造すると、実際の入力に根拠がない場合でも、Haiku はその捏造パターンを模倣します。入力を隠して、「入力だけを知っていて、この出力を作れただろうか」と確認してください。できない場合は、入力か出力のどちらかを修正します
• **例の長さを指定した出力範囲に合わせます。**長さに関しては、ルールより例の影響のほうが大きくなります。ルールで「60～90語を出力」と指定していても、例の平均が35語なら、Haiku は約35語を出力します。例の出力の長さを、指定した出力範囲内（または少し上）に調整してください

提供形式

要点をまとめたプロンプトは、明確なセクション見出しを付け、コードブロックまたはアーティファクトとして提示します。以下を含めてください。

1. システムプロンプト（該当する場合）：役割と永続的なルール
2. ユーザープロンプトのテンプレート：可変の内容には {{placeholders}} を使用
3. 例：プロンプトに埋め込むか、独立した few-shot セクションとして記載
4. 使用上の注意：このプロンプトが失敗する可能性のある状況と、注意すべき点

API 用に生成する場合は、モデルパラメーターと推奨設定を含めます。

model: claude-haiku-4-5-20251001
max_tokens: [appropriate for task]
temperature: 0 (for deterministic tasks) or 0.3 (for creative tasks)

エージェントによるリソース選択

このスキルには、細分化された参照ファイルを含むディレクトリが2つあります。すべてを読まないでください。以下のインデックスを確認し、現在のタスクに関連するファイルだけを読んでください。

gaps/

各ファイルでは、Haiku が Opus と異なる推論パターンを 1 つ取り上げ、テスト済みの緩和策を示しています。タスクごとに 2〜4 個をお読みください。

ファイル	次のようなタスクで使用します…
ambiguity-resolution.md	複数の妥当な解釈が可能な入力、曖昧なユーザーリクエスト
code-generation.md	コード、スクリプト、クエリの生成、既存コードに合わせたスタイルの調整
comparative-analysis.md	選択肢の比較、メリットとデメリット、トレードオフの分析
conditional-logic.md	決定木、分岐ルール、ネストされた if/then ロジック
context-utilization.md	長いコンテキストウィンドウ、2K トークンを超えるドキュメント、位置に依存する情報
counting-enumeration.md	「正確に N 個を生成」、出現回数のカウント、リストの長さ
creative-generation.md	文章作成、トーンの調整、ペルソナの一貫性、スタイルの適合
implicit-constraints.md	トーン、対象読者、形式の規範が明示されていないタスク
instruction-density.md	8 つ以上の制約を同時に満たす必要があるタスク、複雑なルールセット
multi-hop-reasoning.md	3 段階以上の推論チェーン、原因・結果・帰結の分析
multi-turn-consistency.md	チャットボットの動作、状態を維持する会話、ペルソナの維持
negation-handling.md	「〜しない」「決して〜しない」「〜を避ける」と表現された制約、禁止事項
nuanced-classification.md	境界事例、複数ラベル分類、重複するカテゴリ
output-calibration.md	長さの調整、形式の正確さ、冗長さの管理（必ずお読みください）
parallel-consistency.md	類似する複数の項目の生成、形式を統一する必要があるリスト
partial-information.md	欠落フィールド、不完全な入力、任意のデータ、エラー状態
schema-adherence.md	エッジケースの入力にも対応する必要がある構造化出力（JSON、テーブル）
self-correction.md	検証が必要なタスク、出力前の品質チェック
summarization-fidelity.md	歪曲、位置バイアス、捏造を避けたドキュメントの要約
tool-use-planning.md	複数ツールのワークフロー、API のオーケストレーション、依存関係の順序付け

examples/

完成したビフォー・アフターの要約例です。それぞれ、Opus レベルのタスクから Haiku に最適化されたプロンプトへの変換を、注釈付きの例とともに示しています。現在のタスク領域に最も近いものを 1〜2 個お読みください。

ファイル	次のような内容を要約するときに使用します…
api-orchestration.md	依存関係や分岐を含む、複数ステップのツール／API ワークフロー
code-review-triage.md	重要度の分類と構造化された JSON 出力を伴う分析タスク
content-moderation.md	「不確かな場合」の既定の対応を含む、安全性が重要な分類
creative-rewriting.md	トーンの調整、対象読者を意識した書き換え、スタイル変換
data-extraction.md	非構造化テキストから JSON への、スキーマに準拠した抽出
document-qa.md	引用と「見つからない」場合の処理を伴う、RAG／検索根拠型の QA
email-summarization.md	会話／スレッドからセクションごとに情報を抽出
meeting-notes.md	議事録を、決定事項、アクション、次のステップに整理
resume-screening.md	並列スコアリング形式による、複数基準での評価
sql-generation.md	スキーマ制約とエラー処理を伴う、自然言語からコードへの変換
step-by-step-analysis.md	明示的な判断基準を用いた、複数ステップの分析的推論
text-classification.md	確信度の評価と曖昧さへの対応を伴う、複数ラベル分類

セルフチェック

完成したプロンプトを提出する前に、以下の基準に照らして確認してください。

• Opus のすべての推論を明示しています
• すべての制約に番号を付け、相互参照しています
• 一貫した出力形式で、4つ以上の多様な例を示しています
• 例には、典型例が2つ、エッジケースが1つ以上、否定／拒否のケースが1つ以上含まれています
• 例のトークン数がルールのトークン数の2倍以上です（プロンプトの大部分を例が占めるようにします）
• Haiku が「推測して理解する」ことを前提とする指示はありません
• 判断が必要な箇所には、自由形式の判断ではなく、明確な分岐があります
• 出力形式を説明するだけでなく、例で示しています
• <reasoning> タグで、各例の出力が正しい理由を説明しています