← 試験の目次へ
全11問。単一選択と複数選択があります。複数選択の問題には「2つ選んでください」と書いてあります。料金などの数字は2026年11月時点の公式ドキュメントの値です。解答と解説は最後にあります。
回答済み 0 / 11
スキル: LLM の基礎
Claude Haiku 4.5 から Claude Haiku 5.5 へ移行します。同じプロンプトなのに、usage の input_tokens が約3割増えました。最も適切な説明と対応はどれですか。
正解: C
Claude Haiku 5.5 は Claude 4.7 以降と同じ新しいトークナイザーを使い、同じ文章でも約30%多くトークンになります（増え方は内容による）。公式の移行ガイドは、古いモデルで測ったトークン数を使い回さず、使うモデルの ID で数え直すこと、古いモデルに合わせた max_tokens では同じ量の出力が途中で切れうること、コストの見積もりもやり直すことを挙げています。A と B は事実と違います。D は根本的な対応ではありません。
テストで、古いモデルに temperature 0 で同じプロンプトを2回送ったところ、少し違う答えが返ってきました。正しい説明はどれですか。
正解: A
公式の用語集は、temperature を 0 にしても結果は完全には決定的にならず、同じ入力でも API 呼び出しごとに違う出力になりうるとしています。これは Anthropic の API でもクラウド事業者経由でも同じです。だから品質は1回の結果ではなく、評価用データで何回か測って判断します。B と C は誤りです。D も誤りで、プロンプトキャッシュは入力の先頭部分を再利用するしくみで、応答をそのまま返すものではありません。
スキル: モデル選択とトレードオフ
古いモデル用に書いたコードを Claude Sonnet 5.5 に切り替えたところ、temperature: 0.2 と top_p: 0.9 を含むリクエストが 400 エラーになりました。最も適切な直し方はどれですか。
正解: D
Claude Sonnet 5.5 や Claude Haiku 5.5 の移行ガイドは、temperature、top_p、top_k を送るとエラーになるので外し、プロンプトで振る舞いを導くよう求めています。A と B は値を変えたり一部を残したりしているだけで、パラメータを送っている限りエラーは続きます。C は誤りで、400 はリクエストの誤りなので再試行では直りません。
Claude Opus 5.5 を使うコーディング支援ツールで、長い出力をもっと速く表示したいと考え、fast mode を検討しています。正しい説明はどれですか。2つ選んでください。
正解: B、D
fast mode は同じモデルを速い推論の設定で動かすもので、賢さや能力は変わりません（A は誤り）。効果は出力トークン毎秒が最大2.5倍になることで、TTFT ではありません。ストリーミングと一緒に使うと効果がいちばん見えます。料金は割増しで、例えば Opus 5.5 は通常の入力 $4 / 出力 $20 が $8 / $40 になります（C は誤り）。また、バッチ API では使えず、通常とは別の専用のレート制限があります。
問い合わせの分類を大量に処理しています。品質は十分ですが、コストと応答時間を下げたいです。公式ドキュメントの考え方に最も合う、最初の一手はどれですか。
正解: B
公式ドキュメントは、effort は1つのモデルの中で賢さと速さ・コストを交換するつまみで、モデルを変えるより effort の調整のほうがよい手であることが多いとしています。また、速さが大事な仕事や簡単な仕事には low が勧められています。下げたら評価用データで品質を確かめます。A は不要に大きな変更です。C はコストも時間も減りません。D は速くはなりますが、コストは上がるので目的に合いません。
スキル: コストとトークンの管理
長いシステムプロンプトをプロンプトキャッシュで再利用しているチャットアプリで、質問の難しさに応じて、会話の途中でリクエストの最上位の effort を low と high で切り替え始めたところ、キャッシュの読み込みが大きく減りました。最も考えられる理由はどれですか。
公式の effort のベストプラクティスは、最上位の effort の値をリクエストの間で変えるとプロンプトキャッシュが無効になると説明しています。キャッシュに頼る会話の中では最上位の effort を一定にし、変えるならワークロードごとに分けます。対応するモデルでは、キャッシュを保つメッセージ単位の effort の変更も使えます。A、B、D は事実と違います。
社内文書の要約で、毎回見出しの付け方や長さがばらばらになります。公式のプロンプトのベストプラクティスに最も合う改善はどれですか。
例（few-shot / multishot）は、出力の形式・口調・構造を導くいちばん確実な方法の1つです。公式ドキュメントは、例を「関係がある」「多様」「構造化（<example> タグ、複数なら <examples> タグ）」にし、3〜5個を勧めています。B はあいまいな指示をくり返すだけです。C は多様さがなく、意図しないパターンを覚えさせるおそれがあります。D はタグがないと、例と指示を区別しにくくなります。
新しい社内向け FAQ ボットを試作します。応答時間が大事で、予算も限られ、質問は単純なものがほとんどです。公式ドキュメントの「始め方」として最も適切なものはどれですか。
公式ドキュメントは「効率から始める」方法として、Haiku のような速くて安いモデルで作り、よくテストし、要件を満たすか評価して、特定の能力が足りないときだけ上げる手順を挙げています。試作、応答時間が厳しい場合、コストに敏感な場合、大量で単純な仕事に向くとしています。A と C はコストと応答時間の要件に合いません。B は評価になっていません。
1日1万件のリクエストを処理します。1件あたり入力 3,000 トークン、出力 500 トークンです。単価は入力 $2、出力 $10（100万トークンあたり）とします。キャッシュもバッチも使わないとき、1日の費用はいくらですか。
入力は 3,000 × 10,000 = 3,000万トークンで、3,000万 ÷ 100万 × $2 = $60。出力は 500 × 10,000 = 500万トークンで、500万 ÷ 100万 × $10 = $50。合計 $110 です。C の $60 は入力だけを計算しています。出力は入力より単価が高いので、出力を短くすることもコストに効きます。
トークンの使用量とコストの管理について、正しい説明はどれですか。2つ選んでください。
正解: A、C
トークン数を数える API（messages/count_tokens）は、Messages API と同じ形の入力を受け取って入力トークン数を返しますが、その値は見積もりで、実際とわずかに違うことがあります。トークナイザーがモデルで違うので、使う予定のモデルで数えます（B は誤り）。Usage and Cost API は、組織の過去の使用量と費用をプログラムで取得でき、経理との照合、監視、アラートなどに使えます（Admin API キーが必要）。D は誤りで、応答の usage でもリクエストごとの使用量がわかります。
スキル: 技術の基礎
Python のバックエンドで、Claude API を HTTP のライブラリで直接呼んでいます。ヘッダーの付け方や、一時的なエラーのときの再試行を自分で書いています。公式 SDK に切り替えたとき、SDK が引き受けてくれることとして正しいものはどれですか。
公式 SDK は Claude の REST API を包んだライブラリで、認証とバージョン（anthropic-version）のヘッダー、型、エラーの種類分け、ストリーミングの補助を引き受けます。Python SDK は初期設定で、接続エラー、408、409、429、500 以上のエラーを、短い待ち時間をはさんで2回まで自動で再試行します（max_retries で変えられます）。A: API は会話の状態を持たないので、SDK を使っても毎回会話を送ります。B: 公式 SDK は Python、TypeScript、C#、Go、Java、PHP、Ruby で用意されています。D: SDK も同じ REST API を呼ぶので、レート制限は同じようにかかります。
この分野の教材を読む