← 試験の目次へ

Architect Professional ドメイン2: Claude のモデル・プロンプト・コンテキストエンジニアリング（13%）

この章で学ぶこと: トレードオフにもとづくモデルの選び方とモデルの組み合わせ、システムプロンプト・テンプレート・ガードレールの設計、zero-shot / few-shot / chain-of-thought の使い分け、コンテキストウィンドウとトークンの管理、プロンプトの再利用（キャッシュ、モジュール化、Skills）。

本番の63問のうち約8問です。

基礎はここで復習してください:

• 今のモデルの一覧、料金、effort、fast mode、破壊的な変化 → Developer F ドメイン5
• プロンプトの書き方、few-shot、context editing、圧縮 → Developer F ドメイン6
• プロンプトキャッシュの書き方と料金 → Developer F ドメイン2 第3.7節
• Skills の段階的な読み込み → Developer F ドメイン8 第3節
• few-shot、構造化出力、バッチ → Architect F ドメイン4
• 長いコンテキストの管理と信頼性 → Architect F ドメイン5

1. トレードオフでモデルを選ぶ

1.1 今のモデルの位置づけ（2026年11月時点）

数字は Developer F ドメイン5 第3.1節 の表をもとにしています。モデル名と料金はよく変わるので、本番前に公式の Models overview で確かめてください。

1.2 選ぶ軸

公式の考え方（Developer F ドメイン5 第3.2節）: 「効率から始める」（Haiku で作り、足りないときだけ上げる）と「能力から始める」（Opus で作り、あとで effort を下げたり小さいモデルにしたりする）の2つがあります。どちらでも、最後は自分の評価で決めます。

1.3 1つに決めない: 組み合わせる

1.4 データ保持の要件がモデル選択を決めることがある

公式の API and data retention によると、Claude Fable 5.1、Mythos 5.1、Fable 5、Mythos 5 は「Covered Models」で、30日のデータ保持が必要です。Anthropic が特に認めない限り ZDR では使えません。ZDR の組織でこれらを使うには、特定のワークスペースだけで30日保持を有効にします（既定のワークスペースは組織の設定に従うので別のワークスペースを使う）。

試験での使い方: 「ZDR が必須の組織で、いちばん能力の高いモデルを使いたい」→ そのまま使えるとは限らない。要件と機能の対応表を確かめる。

2. システムプロンプト、テンプレート、ガードレール

2.1 システムプロンプトの部品

2.2 テンプレート化

テンプレートは、変わらない部分と変わる部分（変数）を分けたプロンプトです。

2.3 ガードレールを何重にも

プロンプトだけに頼るのはガードレールとして弱い、が試験の定番です。

3. プロンプト手法の使い分け

3.1 今のモデルでの chain-of-thought

今の Claude のモデルは、thinking（考える過程）を API の機能として持っています（多くのモデルは適応型で、effort で考える量を調整）。そのため、

• 推論の量は、プロンプトで「段階的に考えて」と書くより、まず effort で調整する
• thinking を使わない場面でも、考える部分と答えの部分をタグ（例: <thinking> と <answer>）で分けさせると、答えだけを取り出せる
• 考えた過程をそのまま利用者に見せない。ログやデバッグには役立つ

注意: プロンプトでの CoT と API の thinking の関係の説明は、この教材の整理です。公式の最新の書き方は Prompting best practices を見てください。

3.2 選び方の流れ

1. zero-shot で試す → 評価する
2. 形式や判断の境目がぶれる → few-shot を足す
3. 多段階の推論で間違える → thinking / effort を上げる、または CoT を足す
4. それでも足りない → 仕事を分ける（プロンプトチェーン）、モデルを上げる

4. コンテキストウィンドウとトークン

4.1 「入るから全部入れる」は悪手

今のモデルはコンテキストウィンドウが 1M トークンですが、多く入れるほど、

• コストと遅延が増える
• 関係ない情報に気を取られ、精度が下がることがある（Anthropic の Contextual Retrieval の記事も「情報が多いと気が散る」と書いている）

4.2 管理の打ち手

4.3 新しいトークナイザーに注意

Developer F ドメイン5 によると、Claude 4.7 以降のモデルは新しいトークナイザーを使い、同じ文章でも約30%多くトークンになります。モデルを移行するときは、トークン数・コスト・コンテキストの予算を数え直します。

5. プロンプトの再利用

5.1 3つの方法の比較

5.2 キャッシュの設計（試験のサンプル問題2と同じ論点）

毎回同じ 8,000 トークンのシステムプロンプトと方針文書を送り、後ろに短いユーザーの質問がつくアプリ → 変わらない部分を前に置き、プロンプトキャッシュを有効にします。文書を短く切る、むやみに小さいモデルにする、few-shot に移す、はどれも両方（遅延とコスト）に効く打ち手ではありません。

5.3 モジュール化の例（考え方）

[共通] 会社の決まり（全アプリで同じ）     ← キャッシュの先頭
[共通] 出力の形式
[アプリ別] サポート用の役割と例
[毎回] 検索結果とユーザーの質問         ← 後ろ

共通部分を前に置くと、アプリをまたいでも同じ順番になり、キャッシュが効きやすくなります（キャッシュは組織やワークスペースの単位で共有されるかなどの細かい条件は、公式の Prompt caching で確かめてください）。

6. 試験に向けたまとめ

• モデルは評価で決める。ルーティングやリード・ワーカーで組み合わせる
• データ保持の要件（ZDR、Covered Models の30日保持）がモデルの選択を縛ることがある
• ガードレールは何重にも。権限とプログラムの検査が強く、プロンプトの指示は弱い
• zero-shot → few-shot → thinking / CoT → 分解 → 上位モデル、の順に試す
• コンテキストは「入るだけ入れる」ではなく「必要なものだけ」
• 同じ長い先頭部分 → 前に置いてキャッシュ。毎回変わる値を先頭に入れない
• くり返す専門の手順 → Skills（段階的に読み込む）

7. 用語集

出典

• Models overview（Claude Platform Docs）: 今のモデルと料金（数字は Developer F ドメイン5 の表を使用）
• API and data retention（Claude Platform Docs）: Covered Models の30日保持、ZDR、ワークスペース単位の設定
• Prompt caching（Claude Platform Docs）: 順番、TTL、料金、最小の長さ
• Prompt engineering overview / Prompting best practices（Claude Platform Docs）: 例、XML のタグ、thinking、プロンプトチェーンなどは best practices が最新の参考
• Agent Skills（Claude Platform Docs）: 段階的な読み込み
• Introducing Contextual Retrieval（Anthropic）: 情報が多いとモデルが気を取られることがある
• 試験ガイド サンプル問題2

注意: 第2.3節の「強さ」の評価、第3.1節の CoT と thinking の関係、第5.3節のモジュールの並べ方は、この教材の整理です。モデル名・料金・対応機能は変わりやすい情報です。