← 試験の目次へ
全10問。単一選択と複数選択があります。複数選択の問題には「2つ選んでください」と書いてあります。
回答済み 0 / 10
スキル: 4.1 明確な基準
自動コードレビューの指摘の6割を、開発者が「問題ではない」として却下しています。今のプロンプトは「重要な問題だけを、確信が持てるときに報告してください」です。最も効果の高い改善はどれですか。
正解: C
「控えめに」「確信があるときだけ」のような一般的な指示は、具体的なカテゴリの基準ほど精度を上げません。何を報告し何を飛ばすかを具体的に決めます。B の自己申告の確信度は調整されておらず当てになりません。D は本当の問題まで落とします。
スキル: 4.1 誤検知の多いカテゴリ
自動レビューには「セキュリティ」「バグ」「性能」の3カテゴリがあります。「性能」の指摘の誤検知がとても多く、開発者はセキュリティの指摘まで読み飛ばすようになりました。最も良い対応はどれですか。
正解: A
誤検知の多いカテゴリは、正確なカテゴリへの信頼まで壊します。問題のカテゴリだけを一時的に止め、プロンプトを直してから戻すのが試験ガイドの考え方です。B は役に立つ指摘まで失います。C と D は誤検知そのものを減らしません。
スキル: 4.2 few-shot
問い合わせを「請求」「技術」「アカウント」に分ける分類で、「ログインできず、請求書もダウンロードできない」のようなあいまいな問い合わせの扱いが毎回ぶれます。詳しい指示はすでに書いてあります。最も効果的な追加はどれですか。
正解: B
詳しい指示でもぶれるとき、few-shot 例が最も効果的です。特にあいまいなケースに的を絞り、選んだ理由と退けた理由を示すと、新しいケースにも判断が一般化します。C は簡単な例ばかりで、あいまいなケースの判断を教えません。D は誤った分類を固定します。
スキル: 4.3 構造化出力
プロンプトで「次の JSON 形式で答えて」と頼んで抽出していますが、1%ほどの応答で閉じかっこの抜けなど JSON の構文エラーが起き、下流の処理が止まります。最も信頼できる対策はどれですか。
正解: D
JSON スキーマ付きのツール利用は、スキーマに合う構造化出力を得る最も信頼できる方法で、構文エラーをなくします（strict: true の制約付きデコーディング）。A、B、C は確率的、または壊れた出力を後から何とかする方法で、根本的に防げません。
スキル: 4.3 スキーマ設計
契約書から「解約通知の期限」を抜き出すスキーマで、この項目を必須の文字列にしています。期限の書いていない契約書でも、モデルはもっともらしい日付を入れてしまいます。また「契約の種類」の enum にない種類の契約がよく来ます。正しい改善を2つ選んでください。
正解: A、C
文書にないかもしれない項目を必須にすると、モデルは必須を満たすために値を作ります。nullable にします（A）。想定外の分類は enum に "other" と詳細の項目で受け止めます（C）。B は作り話を増やします。D は下流で扱える決まった値がなくなります。
スキル: 4.3 tool_choice
文書を処理するパイプラインで、補強（外部データでの情報の追加）の前に、必ず extract_metadata ツールでメタデータを取り出させたいです。強制のツール選択が使える世代のモデルです。最初のリクエストで使う設定はどれですか。
特定のツールを必ず最初に呼ばせるには、そのツールを強制します。続く補強の手順は次のターンで処理します。D の "any" はどれかのツールを呼ぶだけで、extract_metadata とは限りません。なお Claude Opus 5.5・Sonnet 5.5 など新しいモデルでは強制が 400 エラーになるので、auto と strict とプロンプトの指示で導くか、決まった形が欲しいなら構造化出力を使います。
スキル: 4.4 検証と再試行
請求書の抽出で、明細の合計が総額と合わない結果が5%あります。スキーマ（strict）は満たしています。最も効果的な対処はどれですか。
スキーマが防ぐのは構文のエラーで、合計が合わないといった意味のエラーは防げません（A は誤り）。検証で見つけ、具体的なエラーを伝えて再試行すると、モデルは何を直せばよいかわかります。B は同じ間違いをくり返しがちです。D はデータを失います。
スキル: 4.4 再試行の限界
納品書から「注文番号」を抜き出す処理で、検証エラーのたびに最大3回まで再試行しています。ログを見ると、再試行しても直らないケースの多くは、注文番号が納品書には書かれておらず、別に送られてくる注文書にだけ書かれているものでした。最も適切な対応はどれですか。
必要な情報が元の文書にそもそもないとき、再試行は効きません（書式や構造のエラーとは違う）。情報のある文書を加えるか、null にして人に回します。A と B はむだで、B と C は値の作り話を招きます。
スキル: 4.5 バッチ処理
Message Batches API について正しい説明を2つ選んでください。
正解: A、D
バッチは50%安く、最大24時間で、SLA はありません（A）。結果は custom_id で対応づけ、失敗分だけ直して再投入します（D）。B は誤りで、バッチは1リクエストの中で複数ターンのツール呼び出しを回せません。C も誤りで、結果の順番は送った順とは限りません。
スキル: 4.6 複数パスのレビュー
Claude Code が新しい機能のコードを生成し、同じセッションで「自分のコードをレビューして」と頼むと、ほとんど問題が見つかりません。後で人のレビューで微妙なバグが見つかりました。最も効果的な改善はどれですか。
同じセッションのモデルは、生成のときの推論をコンテキストに持っているので、自分の判断を疑いにくいです。生成の文脈を持たない独立したインスタンスのほうが、微妙な問題を見つけやすいです。B と C は生成の文脈が残ったままです。
この分野の教材を読む