Claude認定デベロッパー - ファンデーション（CCDV-F）の無料練習問題

CCDV-Fのサンプル問題

Claude認定デベロッパー - ファンデーションの無料練習問題10問を、以下ですべて確認できます。

1. Python FastAPIのバックエンドが、公式SDKを通じてチャットのリクエストをClaudeのMessages APIに転送しています。コードレビューの際、チームメイトが、任意の調整を加える前の段階で、呼び出しが受け付けられるためにリクエスト本文に必ず含めなければならないトップレベルのフィールドを尋ねました。すべてのMessages APIリクエストで必須となるフィールドの組み合わせはどれですか。

   • `messages`のみ（APIキーに紐づくワークスペースの設定から、サーバーがデフォルトのモデルと出力上限を決めるため）
   • `model`、`max_tokens`、`messages`（呼び出すモデル、出力の上限、会話のターンをAPIに渡す）
   • `model`、`system`、`temperature`（モデルの選択に加えて、ペルソナとサンプリングの設定をリクエストごとに定める必要があるため）
   • `prompt`と`stop_sequences`（Messagesエンドポイントが互換性のために今も受け付ける、テキスト補完形式のリクエスト）

2. LLMチームに加わったある開発者が、サポートボットの各Claudeリクエストに会話履歴と検索したドキュメントをどれだけ詰め込めるかを計画しており、モデルの「コンテキストウィンドウ」が実際に何の上限を定めているのかを尋ねています。コンテキストウィンドウの説明として正確なものはどれですか。

   • 新しいセッションがプラットフォームでキューに入れられるまでに、1つのAPIキーで同時にアクティブにしておける個別の会話の数
   • 長い生成の途中で、サーバーがアイドル状態とみなして閉じるまでに、ストリーミング接続を開いたままにしておける時間の長さ
   • レート制限によって429レスポンスが返され始めるまでに、組織がそのモデルに1分あたりに送信できるリクエストの数
   • 1回のリクエストで使用できる、入力プロンプトと生成される出力の両方を合わせたトークンの最大数

3. あるスタートアップは、アップロードされた請求書から、明確に定義された1つの抽出プロンプトを使って既知の3つのフィールド（取引先、日付、合計金額）を取り出しています。あるエンジニアはツールを備えた自律型のエージェントループを提案し、別のエンジニアは、この処理には固定された単一呼び出しのワークフローだけで十分だと主張しています。タスクが完全に定義された単一ステップのものであることを踏まえると、最も適したアプローチとその理由として正しいものはどれですか。

   • 1回のMessages API呼び出しで構築したワークフロー（タスクのどこにも、モデル自身が複数ステップの道筋を計画する必要がないため）
   • ツール使用ループを備えた自律型エージェント（ドキュメント中心のタスクでは、処理ステップをモデル自身に決めさせるほうが有利なため）
   • フィールドごとに1つずつ、3つのサブエージェントを持つコーディネーター（各抽出が分離されたコンテキストで実行され、エラーが互いに混入しないようにするため）
   • 永続的なメモリストアを持つエージェント（以前の請求書から学習したパターンによって、以降の請求書での精度が自動的に向上するため）

4. あるNode/TypeScriptのチャットボットは、エンドユーザーがURLで送信したWebページを取得して要約します。送信されたページの1つに、モデルへの指示を無視して会話履歴を攻撃者にメールで送るよう命じる隠しテキストが含まれていました。このプロンプトインジェクションのリスクを最も効果的に低減する実践はどれですか。（2つ選択してください。）

   • 取得したページのコンテンツを信頼できないデータとして扱い、システム指示から構造的に分離しておく。
   • ページのテキストをモデルに渡す前に、取得したHTMLからscriptタグとイベントハンドラーを取り除いてサニタイズする。
   • 要約ジョブのたびにワークロードのAPIキーをローテーションし、侵害された会話を後から再生できないようにする。
   • フックなどの最小権限のガードレールを適用し、注入されたテキストがメール送信ツールを一切起動できないようにする。
   • 指示への追従性が高いほど埋め込まれた命令に従いにくくなるため、最大のモデルティアに移行する。

5. カスタマーサポートアシスタントを構築しているある開発者は、ユーザーが何を入力しても、会話がどれだけ長く続いても、Claudeが毎ターン一貫したペルソナを保ち、同じエスカレーションのルールに従うようにしたいと考えています。こうした持続的で役割を定める指示を配置すべき、リクエストの中の場所はどれですか。

   • モデルが回答する直前に読むテキストが常にその指示になるよう、各ユーザーメッセージの末尾に追加する。
   • そのキーで行われるすべてのリクエストにプラットフォームが指示を付加するよう、コンソールでAPIキーのメタデータに保存する。
   • すべてのターンにわたって持続的な役割とルールの指示を伝えるために設計された、トップレベルの`system`プロンプトに記述する。
   • コンテキストウィンドウのトークンを消費せずにガイダンスを渡せるよう、`stop_sequences`と`metadata`に分けて記述する。

6. あるフィンテックのチームが、Messages APIを使ったカスタマーサポートのチャットのバックエンドをリリースしています。回答の品質を高めるために適応型思考を有効にしたところ、response.content[0].textを読み取るハンドラーが、本番環境で一部のレスポンスに対してのみ断続的に型エラーを出すようになりました。ログを見ると、失敗しているのは、モデルが回答の前に推論を行ったレスポンスです。原因はどれですか。

   • 思考を含むレスポンスでは、最終的な回答がレスポンスオブジェクトの専用のトップレベルフィールドに移り、content配列には推論のブロックしか含まれないため、テキストはそのフィールドから読み取る必要がある。
   • SDKのストリーミングのアキュムレーターはテキストの差分しか結合しないため、思考を有効にしたら、生のイベントのイテレーターに切り替え、個々のイベントから自分でメッセージを組み立て直す必要がある。
   • 思考はmax_tokensの予算の一部を消費するため、推論が長引いたレスポンスではcontent配列が空で返されてインデックス指定で例外が発生しており、max_tokensを引き上げれば解決する。
   • content配列ではテキストブロックの前に思考ブロックが来ることがあり、content[0]が常にテキストとは限らないため、コードはブロックを順に処理し、各ブロックの型で分岐すべきである。

7. ある配送アプリのプッシュ通知サービスは、配信の前に、受信したすべてのメッセージを緊急か通常かに分類しなければなりません。量はピーク時で1日あたり約200万件の分類に達し、各ラベルは単純な二択であり、プロダクトチームは追加のレイテンシを数百ミリ秒までに制限しています。このワークロードに最も適したモデルティアはどれですか。

   • effortを低く設定したOpus（effortを下げた最上位モデルは、能力の余力を残しながら小型モデルの速度に匹敵するため）
   • Opus（最も高性能なティアが最も信頼できるラベルを生成し、この量では分類の誤りがすぐに積み重なるため）
   • Sonnet（中位ティアは本番トラフィックの推奨されるデフォルトであり、ティアを下げるにはまず正式な精度の審査が必要なため）
   • Haiku（最も高速でコスト効率の高いティアであり、このタスクは単純で、量が多く、レイテンシが重視されるため）

8. あるリーガルテックのスタートアップは、受け取った契約書を処理しており、モデル呼び出しをハードコードしたパイプラインと、自らステップを計画する自律型エージェントのどちらにするかを決める必要があります。エンジニアリングリードは、エージェントのアーキテクチャが本当に正当化されるのはどのような条件のときかを尋ねています。固定のワークフローではなくエージェントを構築することを最も強く支持する条件はどれですか。（2つ選択してください。）

   • 作業は複数ステップにわたり、事前に完全に定義することが難しいため、モデルが契約書ごとに自ら道筋を選ぶ必要がある。
   • ビジネス上の優先事項は、ドキュメントのパイプライン全体で、リクエストあたりのコストとレイテンシを可能な限り低くすることである。
   • 成果がより高いコストとレイテンシに見合い、レビューや検証のチェックで誤った出力を検出できるため、誤りは回復可能である。
   • 後続のシステムが特別な処理なしにパースできるよう、すべてのレスポンスが1つの固定のJSONスキーマに準拠しなければならない。
   • 各契約書は同じ抽出、比較、要約の段階を経て処理され、チームはそれをリリース前にすべて書き出せる。

9. あるCIのコードレビューボットは、説明が"Posts a comment on the pull request."となっているpost_review_commentツールを定義しています。ステージング環境の実行では、モデルはテキスト出力の中で本物のバグを見つけているにもかかわらず、このツールをめったに呼び出さないため、指摘が失われています。適切な状況でのツールの呼び出し率を最も確実に高める変更はどれですか。

   • 説明を書き直し、作成者に指摘すべき具体的な欠陥、スタイル違反、リスクのある変更を見つけたときは必ずこのツールを呼び出す、といった呼び出しの条件を明記する。
   • レビューのルールの一覧をツールの説明からシステムプロンプトにすべて移し、モデルが差分の分析を始める前にそれを読むようにする。
   • すべてのレビューのリクエストでtool_choiceをtype anyに設定し、各レスポンスが完了する前に、少なくとも1回のツール呼び出しを必ず含むようにする。
   • 1つのツールを、セキュリティ、スタイル、パフォーマンスなどの問題のカテゴリごとのツールに分割し、モデルが指摘ごとにより具体的なアクションを選べるようにする。

10. ある旅行予約のバックエンドは、独自のRESTレイヤーの背後でMessages APIをプロキシしています。航空券のセール期間のトラフィックの急増中に、上流の呼び出しがretry-afterヘッダー付きのHTTP 429を返し始めましたが、他のリクエストは引き続き成功しています。失敗したリクエストの扱い方として適切なものはどれですか。

    • 上流側で容量が空いたらすぐに少なくとも1回の試行が通るよう、複数の並列接続で同じリクエストを短い間隔でリトライし続ける。
    • 制限はキーごとに適用され、キーを切り替えればすぐにスループットが回復するため、2つ目のワークスペースのバックアップのAPIキーに切り替えて即座に再送する。
    • 429はリクエストのペイロード自体がサイズの上限を超えたことを示し、再送しても成功しないため、恒久的なエラーとしてクライアントにそのまま失敗を返す。
    • 429を、SDKが自動的に処理することもできる一時的なレート制限の合図として扱い、retry-afterの待ち時間が過ぎるのを待ってからバックオフ付きでリトライする。