D4直前対策チートシート——プロンプト設計・信頼性・パフォーマンス（試験比率20%）【CCA Foundations対策】

試験比率20%。few-shot設計・プロンプトの明確さ・ツール説明文の品質・一貫した出力フォーマットの確保が主な出題範囲。

---

few-shot：「理由付き例」が曖昧ケースに効く

• 宣言的ルール（「〜の場合は〇〇ツールを使う」）→ 明確なケースには機能する
• 理由付きfew-shot（「なぜそちらを選ぶか」を例の中に含める）→ 曖昧ケースの推論パターンを教える
• 一貫したフォーマットが必要な場合：詳細な指示より3〜4個のfew-shot例が効果的
• 曖昧なツール選択が問題なら：まずツール説明文を充実させ、それでも解決しなければ理由付きfew-shotを追加

例（理由付きfew-shot）:
ユーザー: 「最近購入した商品について問い合わせたい」
→ get_customerを使う
  理由: 注文番号の言及がないため、まず顧客を特定する順序が正しい

→ 詳細: エージェント信頼性の設計 / プロンプトの書き方②

---

明確な基準：曖昧な指示を具体的な条件に変える

曖昧な指示	具体的な基準
「コメントが正確かどうか確認する」	「コードの実装と矛盾するコメントのみフラグを立てる」
「深刻度を評価する」	「各深刻度レベルにコード例を添えた基準を定義する」
「必ず具体的な修正案を含める」	「問題点・コード箇所・具体的な修正案のフォーマット例を3つ示す」

• 「〜してください」という指示だけでは一貫性が得られない場合、具体的な判断基準または例示に置き換える
• 曖昧さを残すと、同じ入力に対して出力がランダムに揺れる

→ 詳細: プロンプトの書き方①

---

ツール説明文の設計

• ツール選択の精度はツール説明文の品質に直結する
• 最小限の説明（「顧客情報を取得する」）では類似ツールとの区別がつかない
• 充実させるべき内容：
  • 典型的な使用例（どんなクエリのときに使うか）
  • 入力形式と期待する値
  • 類似ツールとの使い分け（「〇〇の場合はこちら、△△の場合はget_customerを使う」）
• ツール誤選択の最初の対処：ツール説明文を見直す（前処理分類器を作る前に）

→ 詳細: Tool Use基礎① / Tool Use応用

---

XMLタグの使いどころ

• 長いプロンプトやドキュメントを渡すとき、構造を明示して混同を防ぐ
• <instructions>, <examples>, <context>, <output_format> のように意味でタグを付ける
• 短いプロンプトでは不要。複数のコンテンツを渡すときに効果が出る

→ 詳細: プロンプトの書き方②

---

一貫性を高める手法の優先順位

1. ツール説明文を充実させる（ツール選択の問題）
2. 明確な基準を定義する（評価・分類の問題）
3. few-shot例を追加する（フォーマット・推論パターンの問題）
4. プロンプトを詳細化する（ガイドラインの問題）

• 指示だけで解決できる問題は指示で解決する
• 指示で一貫性が得られない場合は例示（few-shot）に切り替える
• CLAUDE.mdのような永続的な設定に入れると全セッションで効く

---

system prompt vs CLAUDE.md vs Skills

手法	適用範囲	使いどころ
システムプロンプト	そのAPIコールのみ	APIアプリケーションのペルソナ・ルール
CLAUDE.md	全セッション（プロジェクト共通）	コーディング規約・常時有効なガイドライン
Skills（オンデマンド）	呼び出したときのみ	PR review・デプロイ手順など特定タスク
.claude/rules/（glob）	該当ファイル編集時	ファイルタイプ別の規約

常時適用 → CLAUDE.md、タスク時のみ → Skillsが基本の切り分け

→ 詳細: カスタムコマンド・スキル・MCP・GitHub連携

---

よくある誤解まとめ

誤解	実際
指示を詳細にすれば必ずフォーマットが揃う	詳細な指示より3〜4個のfew-shot例のほうが一貫性が高い
ツール選択が不安定なら前処理分類器を作る	まずツール説明文を充実させる（低コストで直接効果がある）
「必ず〜を含めること」と書けば含まれる	含まれないときはfew-shotで形式を示す
「正確であること」という指示で精度が上がる	「どのケースがフラグ対象か」の具体的な基準が必要
宣言的なルールでも曖昧なケースは処理できる	曖昧ケースには推論過程を示す理由付きfew-shotが必要