Claude Certified Architect – Foundationsの練習問題（当サイト作成）

正解：イ（tool_use ブロックの内容に従ってツールを実行し、結果を tool_result として返して、もう一度リクエストする。）　当サイトの解答

• ア × 誤り tool_use の応答でも、文章が出ていれば回答が完了していると考えた

  tool_use は、Claude がツールの実行を求めている状態です。ループは tool_use 以外の stop_reason（end_turn など）になるまで続けます。

• イ ○ 正しい

  クライアント実行のツールでは、Claude が呼び出しを依頼し、アプリが実行して結果を返します。これを stop_reason が tool_use でなくなるまで繰り返します。

• ウ × 誤り 自作のツールも、Anthropic のサーバーが実行すると考えた

  Anthropic のサーバーが実行するのは web_search などのサーバーツールです。自作の関数は、アプリ側で実行する必要があります。

• エ × 誤り ツール呼び出しの依頼を、失敗として扱うものだと考えた

  tool_use はエラーではありません。それまでの会話と tool_result を含めて送り直さないと、Claude は続きの回答を作れません。

正解：エ（get_order_status だけ。）　当サイトの解答

• ア × 誤り ツールは種類によらず、すべてアプリ側で実行するものだと考えた

  web_search は Anthropic のインフラで実行されます。アプリ側が実行を用意するのは、自作のツールなどのクライアントツールです。

• イ × 誤り 実行する側が逆だと取り違えた

  web_search はサーバーツールで、Anthropic が実行します。利用者は有効にして、最終的な回答を読めばよいツールです。

• ウ × 誤り 自作のツールも、モデルが中身まで実行できると考えた

  モデルは呼び出しの依頼（tool_use）を出すだけで、自分では何も実行しません。自作ツールの中身は、モデルに渡されません。

• エ ○ 正しい

  自作のツールはクライアントツールで、アプリが実行して tool_result を返します。web_search は Anthropic が実行するので、結果を作る処理は不要です。

正解：ア（ログの調査をサブエージェントに任せ、メインの会話には調査結果の要約だけを戻してもらう。）　当サイトの解答

• ア ○ 正しい

  サブエージェントは別のコンテキストで動きます。途中のツール呼び出しや長い出力はそこに残り、メインの会話には最終結果だけが戻ります。

• イ × 誤り CLAUDE.md を、一時的な調査データの置き場として使えると考えた

  CLAUDE.md は毎回のセッションの開始時に読み込まれる、継続的な指示のためのものです。巨大なログを入れると、かえってコンテキストを圧迫します。

• ウ × 誤り 同じ会話で作業を続ければ、出力が増えてもコンテキストの問題は起きないと考えた

  メインの会話で読んだ出力は、すべてそのコンテキストに積み上がります。出力を分離するのが、サブエージェントの目的です。

• エ × 誤り /init を、会話のコンテキストを整理する操作だと取り違えた

  /init は、コードベースを調べて CLAUDE.md を作る機能です。会話にたまった出力を減らす機能ではありません。

正解：ウ（各ツールの説明に、何をするか、どんなときに使うか（使わないか）、何を返すかを具体的に書く。）　当サイトの解答

• ア × 誤り 名前を短くすれば、どちらを選ぶかが明確になると考えた

  名前を短くしても、2 つのツールの違いは伝わりません。公式のガイドは、サービスなどの接頭辞で曖昧さを減らす方法を挙げています。

• イ × 誤り 入力の項目の数が、ツールの選択を左右すると考えた

  選択を決めるのは、主にツールの説明です。入力を削っても、どんなときに使うのかは伝わりません。

• ウ ○ 正しい

  公式は、詳しい説明がツールの性能で最も重要な要素だとしています。使う場面と、返す情報を書くことで、2 つの違いが伝わります。

• エ × 誤り 強制すれば、正しいツールが選ばれると考えた

  any は「どれかのツールを使う」指定で、どのツールを使うかは決めません。選び間違いの原因である、説明の曖昧さは残ります。また、モデルによっては、強制的にツールを使わせる指定そのものが使えない場合があります。

正解：イ（Resources）　当サイトの解答

• ア × 誤り 情報を渡すことも、関数の呼び出しとして実装するものだと考えた

  Tools は、クエリの実行など、AI アプリが呼び出して処理をさせる関数です。スキーマのようなデータの提供には、Resources が向いています。

• イ ○ 正しい

  Resources は、ファイルの内容やデータベースの記録など、文脈になる情報を提供する基本要素です。公式の例でも、スキーマは resource として公開されています。

• ウ × 誤り 「文脈を渡す」ものはすべて Prompts だと考えた

  Prompts は、システムプロンプトや few-shot の例など、対話を構造化する再利用可能なテンプレートです。データそのものを提供する要素ではありません。

• エ × 誤り クライアント側の機能を、サーバーが公開する基本要素と取り違えた

  Elicitation は、サーバーがユーザーに追加の入力や確認を求める、クライアントの機能です。サーバーが公開する基本要素ではありません。

正解：ア（PreToolUse フックを設定して、該当するコマンドの実行前にブロックする。）　当サイトの解答

• ア ○ 正しい

  フックは、決まったタイミングで動くスクリプトです。PreToolUse は、ツールの実行前に動いて、実行を止められます。権限設定の deny ルールでも止められますが、ここでは扱いません。

• イ × 誤り CLAUDE.md の指示は、確実に守られる設定だと考えた

  CLAUDE.md は文脈として読み込まれるもので、強制される設定ではありません。守られやすくはなりますが、確実には止められません。

• ウ × 誤り /init で、禁止事項が強制されるようになると考えた

  /init は、コードベースを調べて CLAUDE.md の初版を作る機能です。操作を禁止する仕組みではありません。

• エ × 誤り 自動メモリを、操作を制限する仕組みだと考えた

  自動メモリは、Claude が訂正や好みから書き留める学びです。CLAUDE.md と同じく、強制力のない文脈として読み込まれます。

正解：エ（プロジェクトのルートに置く CLAUDE.local.md。.gitignore にも追加する。）　当サイトの解答

• ア × 誤り プロジェクトの CLAUDE.md に、個人の設定も書いてよいと考えた

  プロジェクトの CLAUDE.md は、リポジトリでチームと共有するものです。コミットされるので、個人専用の情報には向きません。

• イ × 誤り 個人用のファイルなら、範囲はどれでも同じだと考えた

  ~/.claude/CLAUDE.md は、自分のすべてのプロジェクトに適用されます。このプロジェクトだけの設定という条件に合いません。

• ウ × 誤り 管理ポリシーの CLAUDE.md を、個人が使う設定の置き場と取り違えた

  管理ポリシーの CLAUDE.md は、IT 部門などが組織全体に配る指示のためのものです。

• エ ○ 正しい

  CLAUDE.local.md は、個人のプロジェクト固有の好みを書くファイルです。CLAUDE.md と一緒に読み込まれ、.gitignore に加えればコミットされません。

正解：ウ（構造化出力で JSON スキーマを指定し、応答をそのスキーマに沿わせる。）　当サイトの解答

• ア × 誤り プロンプトでの依頼だけで、形式が保証されると考えた

  依頼だけでは、項目の欠けや余計な文章が混ざる可能性が残ります。形式を保証するには、スキーマを指定する構造化出力を使います。

• イ × 誤り 出力を安定させれば、形式も保証されると考えた

  temperature は出力のばらつきに関わる設定です。一般に、温度設定は JSON の項目や型といった形式を保証するものではありません。

• ウ ○ 正しい

  構造化出力は、応答を指定した JSON スキーマに沿わせる機能です。通常は解析できる有効な JSON が返るので、解析エラーによる再試行を減らせます。ただし、出力が max_tokens で途切れたときや、回答が拒否されたときは例外です。

• エ × 誤り 出力の上限を上げれば、形式の問題も解決すると考えた

  max_tokens は出力の長さの上限です。JSON の項目や型には関係しません。

正解：イ（出力が途中で切れている可能性があるので、max_tokens を増やして再試行する。）　当サイトの解答

• ア × 誤り スキーマを指定すれば、出力が途中で切れることはないと考えた

  出力の長さの上限に達すると、JSON が途中で切れることがあります。スキーマの指定は、上限による打ち切りを防ぎません。

• イ ○ 正しい

  max_tokens で止まった応答は、途中で切れていることがあります。公式は、max_tokens を増やして再試行するよう勧めています。

• ウ × 誤り max_tokens を、refusal（回答の拒否）と同じ意味だと取り違えた

  回答の拒否は、stop_reason が refusal で示されます。max_tokens は、出力の長さの上限に達した印です。

• エ × 誤り 形式の指定が原因で、出力が切れたと考えた

  切れた原因は出力の長さの上限です。指定を外しても原因は変わらず、後続の処理で必要な JSON の形式も失われます。

正解：ア（サーバー側のコンパクションで、古い部分を要約する。）　当サイトの解答

• ア ○ 正しい

  公式は、長い会話の主な手段としてサーバー側のコンパクションを挙げています（ベータ機能です）。コンテキスト編集で、古いツール結果を消去することもできます。

• イ × 誤り ウィンドウが大きければ、中身の量は問題にならないと考えた

  トークンが増えると精度や想起の確かさが落ちる、コンテキストロットが起こります。ウィンドウの大きさとは別に、中身を絞ることも重要です。

• ウ × 誤り キャッシュすると、その分がウィンドウから外れると考えた

  キャッシュした接頭辞も、コンテキストウィンドウを占めます。キャッシュが変えるのは料金の扱いで、ウィンドウの使用量ではありません。

• エ × 誤り 履歴を捨てる以外に、整理の手段はないと考えた

  すべて捨てると、作業の途中の状態も失われます。要約や、古い結果だけの消去なら、必要な情報を残しながら整理できます。