シナリオ別模擬演習
試験では6つのシナリオから4つがランダムに出題されます。各シナリオの設計ポイントを押さえ、練習問題で判断力を磨きましょう。
試験攻略のポイント
形式
全問多肢選択式。正解1つ + 不正解3つ (distractor)。未回答はペナルティなし。
Distractor の特徴
「不完全な知識で選びそうな選択肢」が用意されています。実務経験があるとかえって「なんとなく正しそう」で引っかかるパターンが多い。仕様書の正確な記述に基づいて判断する。
判断の軸
迷ったときは、(1) 確定的 vs 確率的の判断、(2) stop_reason による制御、(3) コンテキスト分離の原則、(4) 構造化データの受け渡し、に立ち返る。
シナリオとドメインの対応
| シナリオ | D1 Agent 27% |
D2 MCP 18% |
D3 Code 20% |
D4 Prompt 20% |
D5 Context 15% |
|---|---|---|---|---|---|
| S1: サポートAgent | ● | ● | ● | ||
| S2: コード生成 | ● | ● | |||
| S3: リサーチ | ● | ● | ● | ||
| S4: 生産性ツール | ● | ● | ● | ||
| S5: CI/CD | ● | ● | |||
| S6: データ抽出 | ● | ● |
カスタマーサポート Resolution Agent
D1 Agentic Architecture / D2 Tool Design / D5 Context Management
シナリオ概要
Agent SDK で構築するカスタマーサポートAgent。返品、請求紛争、アカウント問題など曖昧性の高いリクエストを処理する。MCPツール: get_customer, lookup_order, process_refund, escalate_to_human。目標: 80%以上の初回解決率。
設計ポイント
process_refund は get_customer 完了後のみ実行可能にする (前提条件ゲート)▶
Q1. 顧客が「注文が届かないし、前回の返金もまだ反映されていない」と言った場合、最適な処理方法は？
A) 配送問題を先に解決してから返金問題に取り組む
B) 2つの問題を個別に分解し、lookup_order と get_customer を並行で呼び出して調査する
C) すぐに人間にエスカレーションする
D) 返金問題を先に処理する
Q1. 顧客が「注文が届かないし、前回の返金もまだ反映されていない」と言った場合、最適な処理方法は？
A) 配送問題を先に解決してから返金問題に取り組む
B) 2つの問題を個別に分解し、lookup_order と get_customer を並行で呼び出して調査する
C) すぐに人間にエスカレーションする
D) 返金問題を先に処理する
正解: B
複数の問題を含むリクエストは個別に分解し、独立した調査を並行実行します。AやDのような順序付けは不要で、Cは80%初回解決率の目標に反します。
▶
Q2. get_customer がエラーを返した場合に process_refund を試みると何が起こるべきか？
A) Claude が判断して process_refund を実行するか決める
B) 前提条件ゲートがプログラム的にブロックし、process_refund を実行不可にする
C) エラーをログに記録して process_refund を続行する
D) 自動的にエスカレーションする
Q2. get_customer がエラーを返した場合に process_refund を試みると何が起こるべきか？
A) Claude が判断して process_refund を実行するか決める
B) 前提条件ゲートがプログラム的にブロックし、process_refund を実行不可にする
C) エラーをログに記録して process_refund を続行する
D) 自動的にエスカレーションする
正解: B
本人確認 (get_customer) 前の返金処理は金銭リスクが伴うため、確定的保証が必要です。プロンプト指示 (A) は確率的で不十分。Hooks/前提条件ゲートによるプログラム的ブロックが正解です。
▶
Q3. エスカレーション時に escalate_to_human ツールに渡すべきデータとして不適切なものは？
A) 顧客IDと注文番号
B) 問題の根本原因分析
C) エージェントとの会話トランスクリプト全文
D) 推奨アクション
Q3. エスカレーション時に escalate_to_human ツールに渡すべきデータとして不適切なものは？
A) 顧客IDと注文番号
B) 問題の根本原因分析
C) エージェントとの会話トランスクリプト全文
D) 推奨アクション
正解: C
人間のオペレーターは会話全文にアクセスできないことが多く、大量のテキストを読む時間もありません。構造化されたサマリー (顧客ID、根本原因、試行済みアクション、推奨対応) を渡すべきです。
Claude Code でコード生成
D3 Claude Code Configuration / D5 Context Management
シナリオ概要
チームの開発ワークフローに Claude Code を統合。コード生成、リファクタリング、デバッグ、ドキュメンテーションに活用する。カスタムスラッシュコマンド、CLAUDE.md設定、plan mode を使いこなす。
設計ポイント
CLAUDE.md 設定例: チーム開発ワークフロー
チームで Claude Code を導入する際、プロジェクトルートの CLAUDE.md に記載する内容の典型パターンです。階層ごとに役割が異なり、ルート CLAUDE.md はリポジトリにコミットしてチーム全体で共有し、個人設定は ~/.claude/CLAUDE.md に分離します。
# プロジェクトルートの CLAUDE.md (チーム共有)
## ビルド・テスト
- ビルド: `npm run build`
- テスト: `npm run test` (単体), `npm run e2e` (E2E)
- リント: `npm run lint -- --fix`
## コーディング規約
- TypeScript strict mode。any 型は禁止
- React コンポーネントは関数コンポーネント + hooks
- エラーハンドリングは Result 型パターンを使用
## アーキテクチャ制約
- src/domain/ は外部ライブラリに依存しない
- API呼び出しは src/infrastructure/ 経由のみ
- 新しい依存は package.json 追加前にチームレビュー必須
この設定により、Claude Code はプロジェクト固有のルールを毎回のプロンプトなしに適用できます。サブディレクトリに別の CLAUDE.md を配置すると、そのディレクトリ内ではサブディレクトリ側の設定が優先されます。
▶
Q1. データベースの ORM 層を Sequelize から Prisma に移行する作業で、Plan Mode と直接実行のどちらが適切か？
A) 直接実行。ORM の移行は機械的な置換なので計画は不要
B) Plan Mode。複数ファイルに影響し、スキーマ変更やマイグレーション戦略の判断が必要
C) ファイルごとに直接実行で1つずつ移行
D) 先にテストを書いてから直接実行
Q1. データベースの ORM 層を Sequelize から Prisma に移行する作業で、Plan Mode と直接実行のどちらが適切か？
A) 直接実行。ORM の移行は機械的な置換なので計画は不要
B) Plan Mode。複数ファイルに影響し、スキーマ変更やマイグレーション戦略の判断が必要
C) ファイルごとに直接実行で1つずつ移行
D) 先にテストを書いてから直接実行
正解: B
ORM 移行はアーキテクチャ全体に影響する大規模変更です。マイグレーション順序、スキーマ互換性、テスト戦略など事前に計画すべき判断が多く、Plan Mode でユーザーの承認を得てから実行すべきです。
▶
Q2. チームの CLAUDE.md に「テストは pytest で実行」と書いているが、特定のサブディレクトリでは Jest を使っている。この場合の最適な対応は？
A) プロジェクトルートの CLAUDE.md を書き換えて両方を記載
B) そのサブディレクトリに CLAUDE.md を作成し「テストは Jest で実行」と記載
C) 毎回の会話で手動で指示する
D) Jest のサブディレクトリを除外リストに追加
Q2. チームの CLAUDE.md に「テストは pytest で実行」と書いているが、特定のサブディレクトリでは Jest を使っている。この場合の最適な対応は？
A) プロジェクトルートの CLAUDE.md を書き換えて両方を記載
B) そのサブディレクトリに CLAUDE.md を作成し「テストは Jest で実行」と記載
C) 毎回の会話で手動で指示する
D) Jest のサブディレクトリを除外リストに追加
正解: B
CLAUDE.md の階層構造を活用し、サブディレクトリに特化したルールを配置します。サブディレクトリの CLAUDE.md が優先されるため、そのディレクトリ内では Jest が使われます。
▶
Q3. チームで「新しい API エンドポイントを追加する際のボイラープレート」を標準化したい。カスタムスラッシュコマンドの設計として最適なのは？
A) コマンド内にルート定義、コントローラー、テストの全コードをハードコードしておく
B) コマンドに「エンドポイント名」と「HTTP メソッド」を引数で受け取らせ、プロジェクトの既存パターンを Glob/Read で参照してからコード生成する
C) 汎用的な「コード生成」コマンドを1つ作り、毎回プロンプトで詳細を指定する
D) テンプレートファイルを用意し、sed で置換するシェルスクリプトを呼ぶ
Q3. チームで「新しい API エンドポイントを追加する際のボイラープレート」を標準化したい。カスタムスラッシュコマンドの設計として最適なのは？
A) コマンド内にルート定義、コントローラー、テストの全コードをハードコードしておく
B) コマンドに「エンドポイント名」と「HTTP メソッド」を引数で受け取らせ、プロジェクトの既存パターンを Glob/Read で参照してからコード生成する
C) 汎用的な「コード生成」コマンドを1つ作り、毎回プロンプトで詳細を指定する
D) テンプレートファイルを用意し、sed で置換するシェルスクリプトを呼ぶ
正解: B
カスタムスラッシュコマンドの強みは、引数による柔軟性と、プロジェクトの既存コードを文脈として参照できる点です。ハードコード (A) は変更に弱く、汎用コマンド (C) はスラッシュコマンドの「繰り返し作業を自動化する」目的を果たしません。sed 置換 (D) はClaude の生成能力を活用できず、複雑なパターンに対応できません。既存パターンを読み取ることで、プロジェクトの規約に一貫したコードが生成されます。
▶
Q4. 50以上のモジュールを持つモノレポで「認証ロジックがどこでどう使われているか」を調査する際、Agent ツール (サブエージェント) を使う利点は？
A) Agent ツールの方が Grep より高速にファイルを検索できる
B) Agent ツールは独立したコンテキストで動作するため、大量のファイル内容を読み込んでもメインセッションのコンテキストを消費しない
C) Agent ツールは並列で複数ファイルを同時に読める
D) Agent ツールは Git の履歴にアクセスできる
Q4. 50以上のモジュールを持つモノレポで「認証ロジックがどこでどう使われているか」を調査する際、Agent ツール (サブエージェント) を使う利点は？
A) Agent ツールの方が Grep より高速にファイルを検索できる
B) Agent ツールは独立したコンテキストで動作するため、大量のファイル内容を読み込んでもメインセッションのコンテキストを消費しない
C) Agent ツールは並列で複数ファイルを同時に読める
D) Agent ツールは Git の履歴にアクセスできる
正解: B
Agent ツール (サブエージェント) の最大の利点はコンテキスト分離です。大規模コードベースの探索的調査では、多数のファイルを読み込みながら仮説を検証する必要がありますが、これをメインセッションで行うとコンテキストが肥大化し、後続のタスクに影響します。サブエージェントに調査を委任すると、調査結果の要約だけがメインに返され、途中の読み込みはメインのコンテキストに蓄積されません。速度 (A) や並列読み込み (C) はサブエージェント固有の利点ではありません。
マルチエージェントリサーチシステム
D1 Agentic Architecture / D2 Tool Design / D5 Context Management
シナリオ概要
Agent SDK で構築するマルチエージェントリサーチシステム。コーディネーターが Web 検索、文書分析、レポート生成の各サブエージェントに委任し、引用付きの包括的レポートを生成する。
設計ポイント
コーディネーター / サブエージェント データフロー
マルチエージェントリサーチの典型的な流れです。コーディネーターが中心となり、反復ループでギャップを埋めていきます。
リサーチ計画を策定
Web検索 Agent
URL + 日時 + スコア
文書分析 Agent
引用 + ページ + 信頼度
ギャップ評価: 不足があれば再委任
サブエージェントに再委任
レポート Agent
引用付きレポート
サブエージェント間で直接通信は行いません。全てのデータはコーディネーターを経由して受け渡されます。各サブエージェントの返却値には必ずメタデータ (URL、ページ番号、信頼度スコアなど) を構造化形式で含めます。
▶
Q1. Web検索サブエージェントの結果を合成サブエージェントに渡す最適な方法は？
A) 検索結果のテキストをそのまま全文渡す
B) 検索結果を要約してから渡す
C) 検索結果をソースURL、取得日時、関連度スコア等のメタデータと共に構造化形式で渡す
D) 共有データベースに保存して合成サブエージェントが読み取る
Q1. Web検索サブエージェントの結果を合成サブエージェントに渡す最適な方法は？
A) 検索結果のテキストをそのまま全文渡す
B) 検索結果を要約してから渡す
C) 検索結果をソースURL、取得日時、関連度スコア等のメタデータと共に構造化形式で渡す
D) 共有データベースに保存して合成サブエージェントが読み取る
正解: C
引用付きレポートを生成するには情報源の帰属 (attribution) が必要です。メタデータを構造化形式で含めることで、合成サブエージェントが正確な引用を行えます。サブエージェント間の共有DB (D) はAgent SDK の機能にありません。
▶
Q2. コーディネーターのプロンプト設計として適切なのは？
A) 「ステップ1で検索し、ステップ2で分析し、ステップ3で要約してください」という手順的指示
B) 「包括的で正確なリサーチレポートを作成してください。全ての主張に引用を付けてください」というゴールと品質基準
C) サブエージェントの名前と呼び出し順序の一覧
D) 「できるだけ多くの情報を集めてください」という網羅性重視の指示
Q2. コーディネーターのプロンプト設計として適切なのは？
A) 「ステップ1で検索し、ステップ2で分析し、ステップ3で要約してください」という手順的指示
B) 「包括的で正確なリサーチレポートを作成してください。全ての主張に引用を付けてください」というゴールと品質基準
C) サブエージェントの名前と呼び出し順序の一覧
D) 「できるだけ多くの情報を集めてください」という網羅性重視の指示
正解: B
コーディネーターのプロンプトはゴールと品質基準を指定し、手順ではなく目標を伝えるべきです。手順的指示 (A) はサブエージェントの適応力を奪い、固定パイプラインになります。ゴール指定により、コーディネーターが状況に応じて動的にルーティングできます。
▶
Q3. コーディネーターが検索サブエージェントと分析サブエージェントの結果を受け取った後、「競合他社の市場シェアデータが不足している」と判断した。次に取るべきアクションは？
A) 不足データについて「情報が見つかりませんでした」とレポートに記載する
B) 不足しているテーマに絞った追加検索クエリを指定して、検索サブエージェントに再委任する
C) レポートサブエージェントに「不足を推測で補って」と指示する
D) ユーザーに「情報が不足しています」とだけ返す
Q3. コーディネーターが検索サブエージェントと分析サブエージェントの結果を受け取った後、「競合他社の市場シェアデータが不足している」と判断した。次に取るべきアクションは？
A) 不足データについて「情報が見つかりませんでした」とレポートに記載する
B) 不足しているテーマに絞った追加検索クエリを指定して、検索サブエージェントに再委任する
C) レポートサブエージェントに「不足を推測で補って」と指示する
D) ユーザーに「情報が不足しています」とだけ返す
正解: B
コーディネーターの反復ループ (iterative refinement) パターンです。合成結果のギャップを評価し、不足があればより具体的なクエリで再委任します。推測 (C) はハルシネーションの原因になり、情報なし (A) や丸投げ (D) はリサーチシステムの価値を損ないます。ギャップ評価と再委任の反復は、マルチエージェントリサーチの品質を確保する設計上の核心です。
開発者生産性ツール
D2 Tool Design / D3 Claude Code Config / D1 Agentic Architecture
シナリオ概要
Agent SDK で構築する開発者向けツール。レガシーコードベースの理解支援、ボイラープレート生成、反復作業の自動化。Read, Write, Bash, Grep, Glob の組み込みツールと MCP サーバーを連携。
設計ポイント
動的適応分解: レガシーコードベース探索の例
レガシーコードベースを調査する際、あらかじめ手順を決めず、各ステップの結果に基づいて次のアクションを選択する動的適応分解のフローです。
構造マッピング
Glob("**/*.{py,js,ts}") でファイル一覧を取得し、ディレクトリ構成とファイル数を把握。package.json、requirements.txt 等の設定ファイルを Read で確認。
エントリポイント特定
Grep("main|app.listen|if __name__") でエントリポイントを探索。見つかった結果に応じて、フレームワーク固有のパターンを追加検索。
動的分岐
ここから先は結果に応じて変わります。Express アプリなら router 定義を追跡。Django ならurls.py から views を辿る。モノレポならパッケージ間の依存関係をマッピング。
高インパクト領域の詳細分析
変更頻度が高い、依存が多い、テストカバレッジが低い等の領域を重点的に Read で深掘り。
固定の手順ではなく「前のステップの結果を見て次に何をするか判断する」のがポイントです。これがワークフロー (固定パイプライン) とエージェント (動的判断) の違いを体現しています。
▶
Q1. 未知のレガシーコードベースの全体像を理解するために、エージェントが最初にすべきアクションは？
A) 全ファイルを順番に Read で読む
B) Glob でファイル構造をマッピングし、エントリポイントと主要な依存関係を特定する
C) テストファイルだけを読んで仕様を理解する
D) README があればそれだけ読む
Q1. 未知のレガシーコードベースの全体像を理解するために、エージェントが最初にすべきアクションは？
A) 全ファイルを順番に Read で読む
B) Glob でファイル構造をマッピングし、エントリポイントと主要な依存関係を特定する
C) テストファイルだけを読んで仕様を理解する
D) README があればそれだけ読む
正解: B
まず Glob でファイルパターンと構造を把握し、エントリポイントを特定します。全ファイル読み込み (A) はコンテキストを無駄に消費します。動的適応分解の第一段階は「構造のマッピング」です。
▶
Q2. エージェントに PostgreSQL のクエリ実行機能を追加したい。MCP サーバーの統合方法として最適なのは？
A) Bash ツールで直接 psql コマンドを実行する
B) MCP サーバーとして PostgreSQL クライアントを実装し、read_query と write_query をツールとして公開する。write_query は allowedTools で制限可能にする
C) データベースの接続情報をシステムプロンプトに記載し、Claude に SQL を生成させる
D) 全テーブルのダンプを事前にコンテキストに読み込む
Q2. エージェントに PostgreSQL のクエリ実行機能を追加したい。MCP サーバーの統合方法として最適なのは？
A) Bash ツールで直接 psql コマンドを実行する
B) MCP サーバーとして PostgreSQL クライアントを実装し、read_query と write_query をツールとして公開する。write_query は allowedTools で制限可能にする
C) データベースの接続情報をシステムプロンプトに記載し、Claude に SQL を生成させる
D) 全テーブルのダンプを事前にコンテキストに読み込む
正解: B
MCP サーバーとして実装することで、ツールの description にクエリの用途を明記でき、allowedTools による権限制御も可能になります。Bash 経由の psql (A) はセキュリティリスクが高く、インジェクション対策もありません。接続情報をプロンプトに記載 (C) するとシークレットがコンテキストに露出します。read_query と write_query を分離することで、読み取り専用エージェントと書き込み可能エージェントを権限レベルで区別できます。
▶
Q3. 以下の2つのツール description のうち、Claude がツールを正しく選択しやすいのはどちらか？
// パターン A
"description": "ユーザー情報を取得する"
// パターン B
"description": "メールアドレスまたはユーザーIDを指定して、該当ユーザーの氏名・所属部署・権限レベルを返す。ユーザーが見つからない場合は null を返す"
A) パターン A。簡潔な方がClaude の処理速度が上がる
B) パターン B。入力条件、出力内容、エッジケースの動作が明記されており、類似ツールとの使い分けが可能
C) どちらも同等。Claude は description よりもツール名で判断する
D) パターン A に加え、system prompt で詳細を補足するのが最適
Q3. 以下の2つのツール description のうち、Claude がツールを正しく選択しやすいのはどちらか？
// パターン A
"description": "ユーザー情報を取得する"
// パターン B
"description": "メールアドレスまたはユーザーIDを指定して、該当ユーザーの氏名・所属部署・権限レベルを返す。ユーザーが見つからない場合は null を返す"
A) パターン A。簡潔な方がClaude の処理速度が上がる
B) パターン B。入力条件、出力内容、エッジケースの動作が明記されており、類似ツールとの使い分けが可能
C) どちらも同等。Claude は description よりもツール名で判断する
D) パターン A に加え、system prompt で詳細を補足するのが最適
正解: B
Claude がツールを選択する際、description が最も重要な判断材料です。パターン B は入力に何を指定するか (メールアドレスまたはユーザーID)、何が返るか (氏名、所属、権限)、エッジケース (見つからない場合は null) が明確で、Claude が正しいツールを選択する確率が上がります。system prompt で補足する方法 (D) は description を読む段階ですでに判断が行われるため、タイミングが遅い。
CI/CD パイプライン
D3 Claude Code Configuration / D4 Prompt Engineering
シナリオ概要
Claude Code を CI/CD パイプラインに統合。PR ごとに自動コードレビュー、テスト生成、フィードバック提供。課題: アクション可能なフィードバックを提供し、false positive (誤検知) を最小化。
設計ポイント
claude --print (非対話モード) を使い、PR イベントで自動起動レビュープロンプトの比較: 効果的な設計 vs 問題のある設計
CI/CD でのコードレビューはプロンプトの品質が false positive 率に直結します。以下に良い例と悪い例を対比します。
問題のあるプロンプト
このPRをレビューしてください。
問題があれば全て指摘してください。
コードの品質を改善する提案も
お願いします。
問題点: レビュー基準が曖昧で、スタイルの好みやマイナーな改善提案まで大量に出力されます。開発者がレビューを無視するようになる原因です。
効果的なプロンプト
以下の diff をレビューし、次の基準に
該当する問題のみ報告してください。
報告対象:
- セキュリティ脆弱性 (SQLi, XSS等)
- 本番でクラッシュの原因となるバグ
- データ損失のリスクがある処理
報告しない:
- スタイルの好み、命名の提案
- パフォーマンス最適化の提案
- 既存コードの改善 (今回の diff 外)
出力形式:
ファイル名:行番号 | 深刻度 | 説明
報告対象と報告しない項目を明示することで、アクション可能な指摘のみに絞り込めます。出力形式を指定することで、自動処理にも対応できます。
▶
Q1. CI/CD でのコードレビューの false positive を減らすために、プロンプトに含めるべき指示は？
A) 「できるだけ多くの問題を見つけてください」
B) 「全てのスタイル違反を報告してください」
C) 「確信度の高いバグとセキュリティ問題のみ報告し、スタイルの好みは指摘しない」
D) 「前回のレビューと同じ基準で」
Q1. CI/CD でのコードレビューの false positive を減らすために、プロンプトに含めるべき指示は？
A) 「できるだけ多くの問題を見つけてください」
B) 「全てのスタイル違反を報告してください」
C) 「確信度の高いバグとセキュリティ問題のみ報告し、スタイルの好みは指摘しない」
D) 「前回のレビューと同じ基準で」
正解: C
CI/CD のレビューは開発者が毎 PR で受けるものなので、false positive が多いとレビュー自体が無視されるようになります。確信度の高い重要な問題のみに絞り、アクション可能なフィードバックに集中するプロンプト設計が正解です。
▶
Q2. 20ファイルを含む大きなPRのレビュー方法として最適なのは？
A) 20ファイル全てを1つのプロンプトに含めてレビュー
B) ファイルごとに個別分析し、その後クロスファイル統合パスを実行
C) ランダムに5ファイルを抽出してレビュー
D) diff の行数が多い順に上位5ファイルだけレビュー
Q2. 20ファイルを含む大きなPRのレビュー方法として最適なのは？
A) 20ファイル全てを1つのプロンプトに含めてレビュー
B) ファイルごとに個別分析し、その後クロスファイル統合パスを実行
C) ランダムに5ファイルを抽出してレビュー
D) diff の行数が多い順に上位5ファイルだけレビュー
正解: B
大規模レビューでは attention dilution を避けるため、ファイル単位のローカルパスで深い問題を検出し、クロスファイル統合パスでファイル間の依存関係や一貫性の問題を検出する2段階が推奨されます。
▶
Q3. GitHub Actions で Claude Code を使ったPRレビューを設定する際、最も重要な構成要素は？
A) claude --print で非対話モードを使い、PR の diff をパイプで渡す。ANTHROPIC_API_KEY はシークレットとして設定
B) claude --resume で前回のセッションを引き継ぎ、レビューの一貫性を保つ
C) Actions のランナーに Claude Code をグローバルインストールし、対話モードで実行する
D) API を直接呼び出し、Claude Code は使わない
Q3. GitHub Actions で Claude Code を使ったPRレビューを設定する際、最も重要な構成要素は？
A) claude --print で非対話モードを使い、PR の diff をパイプで渡す。ANTHROPIC_API_KEY はシークレットとして設定
B) claude --resume で前回のセッションを引き継ぎ、レビューの一貫性を保つ
C) Actions のランナーに Claude Code をグローバルインストールし、対話モードで実行する
D) API を直接呼び出し、Claude Code は使わない
正解: A
CI/CD 環境では対話的な入力ができないため、--print フラグを使った非対話モードが必須です。標準入力またはファイルから diff を渡し、結果を標準出力に受け取ります。API キーは GitHub Secrets に保存し、環境変数として渡します。--resume (B) は CI のステートレスなランナーでは前回セッションが存在しません。対話モード (C) は CI 環境では動作しません。
構造化データ抽出
D4 Prompt Engineering / D5 Context Management
シナリオ概要
非構造化ドキュメントから情報を抽出し、JSON Schema で検証し、高精度を維持する。エッジケースへの対応と下流システムとの統合が必要。
設計ポイント
tool_choice 強制スキーマの実装例
構造化データ抽出では、Claude にツールの使用を強制し、そのツールの input_schema で出力フォーマットを厳密に定義します。tool_choice に {"type": "tool", "name": "ツール名"} を指定すると、Claude は必ずそのツールを呼び出す形で応答します。
// API リクエスト例: 請求書からの情報抽出
{
"tools": [{
"name": "extract_invoice",
"description": "請求書から構造化データを抽出する",
"input_schema": {
"type": "object",
"properties": {
"vendor_name": { "type": "string" },
"invoice_number": { "type": "string" },
"total_amount": { "type": "number" },
"currency": { "type": "string",
"enum": ["JPY", "USD", "EUR"] },
"line_items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": { "type": "string" },
"quantity": { "type": "integer" },
"unit_price": { "type": "number" }
},
"required": ["description", "quantity", "unit_price"]
}
}
},
"required": ["vendor_name", "invoice_number",
"total_amount", "currency", "line_items"]
}
}],
"tool_choice": { "type": "tool", "name": "extract_invoice" }
}
tool_choice を {"type": "tool", "name": "extract_invoice"} にすることで、Claude は必ず extract_invoice ツールを呼び出します。input_schema の required フィールドと型制約により、出力構造は確定的に保証されます。enum で通貨コードを制限すると、不正な値が入らないようにもできます。この方法は「プロンプトでJSONを出力して」と指示するよりも信頼性が高く、stop_reason が tool_use になるため結果の判定も容易です。
▶
Q1. Claude に常に同じ JSON 構造で出力させる最も確実な方法は？
A) system prompt に「必ず JSON で出力してください」と書く
B) tool_choice で特定ツールを強制し、そのツールの input_schema で出力構造を定義する
C) temperature を 0 に設定する
D) 出力の先頭に { をプリフィルする
Q1. Claude に常に同じ JSON 構造で出力させる最も確実な方法は？
A) system prompt に「必ず JSON で出力してください」と書く
B) tool_choice で特定ツールを強制し、そのツールの input_schema で出力構造を定義する
C) temperature を 0 に設定する
D) 出力の先頭に { をプリフィルする
正解: B
tool_choice でツールを強制すると、Claude は必ずそのツールの input_schema に従った構造で出力します。プロンプト指示 (A) やプリフィル (D) は確率的です。temperature=0 (C) は出力の決定性を上げますが構造を保証しません。
▶
Q2. 100ページの契約書から条項を抽出する場合、最適なアプローチは？
A) 100ページ全体を1回のリクエストで処理
B) ページごとに個別抽出し、重複を除去して結果をマージ
C) 最初の10ページだけ処理して代表的な条項を抽出
D) 目次だけ読んで関連セクションを推測
Q2. 100ページの契約書から条項を抽出する場合、最適なアプローチは？
A) 100ページ全体を1回のリクエストで処理
B) ページごとに個別抽出し、重複を除去して結果をマージ
C) 最初の10ページだけ処理して代表的な条項を抽出
D) 目次だけ読んで関連セクションを推測
正解: B
100ページをコンテキストに収めるのは困難 (A)。意味的なまとまりでチャンキングし、各チャンクから条項を抽出、結果を統合して重複を除去するのが正しいアプローチです。C, D は情報の欠落リスクが大きい。
▶
Q3. 住所フィールドの表記ゆれが多い文書から構造化データを抽出する場合、few-shot examples の最適な使い方は？
A) 正規化された住所の例を1つだけ示す
B) 表記ゆれのバリエーション (全角/半角、ハイフン有無、丁目表記の違い等) を含む3-4個の入出力ペアを示し、全て同じ正規化形式に変換する例を提示する
C) few-shot examples は不要。system prompt に「住所を正規化して」と書けば十分
D) 可能な限り多くの例 (20個以上) を示す
Q3. 住所フィールドの表記ゆれが多い文書から構造化データを抽出する場合、few-shot examples の最適な使い方は？
A) 正規化された住所の例を1つだけ示す
B) 表記ゆれのバリエーション (全角/半角、ハイフン有無、丁目表記の違い等) を含む3-4個の入出力ペアを示し、全て同じ正規化形式に変換する例を提示する
C) few-shot examples は不要。system prompt に「住所を正規化して」と書けば十分
D) 可能な限り多くの例 (20個以上) を示す
正解: B
few-shot examples の目的は、Claude に期待する変換パターンを具体的に伝えることです。住所の表記ゆれは多様なため、代表的なバリエーションを3-4個示すことで、Claude が暗黙のルールを学習できます。1つだけ (A) では多様性が不足し、抽象的な指示 (C) では「半角ハイフン統一」「丁目を数字に変換」等の具体的ルールが伝わりません。20個以上 (D) はコンテキストを無駄に消費し、3-5個で十分な効果が得られます。
総合模擬テスト
複数ドメインを横断する難易度の高い問題です。シナリオのコンテキストを踏まえて解答してください。
▶
Q1. [S1] カスタマーサポートAgent で、顧客が「アカウントをキャンセルしたい。全返金してほしい」と言った。顧客のサブスクリプション残高は$800。この場合のエージェントの最適な動作は？
A) system prompt に従ってキャンセル処理と返金を実行する
B) get_customer で本人確認 → 返金額 $800 が上限 $500 超のため PostToolUse フックがブロック → 構造化サマリーで人間にエスカレーション
C) 顧客に「$500 まで返金可能ですが、それでよいですか？」と確認する
D) キャンセルだけ実行し、返金は別のチケットで処理すると伝える
Q1. [S1] カスタマーサポートAgent で、顧客が「アカウントをキャンセルしたい。全返金してほしい」と言った。顧客のサブスクリプション残高は$800。この場合のエージェントの最適な動作は？
A) system prompt に従ってキャンセル処理と返金を実行する
B) get_customer で本人確認 → 返金額 $800 が上限 $500 超のため PostToolUse フックがブロック → 構造化サマリーで人間にエスカレーション
C) 顧客に「$500 まで返金可能ですが、それでよいですか？」と確認する
D) キャンセルだけ実行し、返金は別のチケットで処理すると伝える
正解: B
Phase 1 で学んだ確定的保証パターンの適用。本人確認 (前提条件ゲート) → 金額チェック (PostToolUse フック) → エスカレーション (構造化ハンドオフ) の3段階が正しい流れです。
▶
Q2. [S3] マルチエージェントリサーチで、コーディネーターが3つのサブエージェントを起動する最も効率的な方法は？
A) ターン1で検索Agent → 結果を受けてターン2で分析Agent → ターン3でレポートAgent
B) 1レスポンスで検索Agent と分析Agent の Task を同時発行 → 結果を受けてレポートAgent
C) 3つ全てを1レスポンスで同時発行
D) 検索と分析をマージした1つのサブエージェントに任せる
Q2. [S3] マルチエージェントリサーチで、コーディネーターが3つのサブエージェントを起動する最も効率的な方法は？
A) ターン1で検索Agent → 結果を受けてターン2で分析Agent → ターン3でレポートAgent
B) 1レスポンスで検索Agent と分析Agent の Task を同時発行 → 結果を受けてレポートAgent
C) 3つ全てを1レスポンスで同時発行
D) 検索と分析をマージした1つのサブエージェントに任せる
正解: B
検索と分析は並行実行可能なので1レスポンスで同時に Task を発行します。レポート生成は検索・分析の結果に依存するので後続ステップ。A は全て直列で非効率。C はレポートAgentが依存データなしで動くので不適切。
▶
Q3. [S5] CI/CD のコードレビューで、Claude が「この変数名は分かりにくい」とコメントした。これは false positive に分類されるか？
A) いいえ。コードの可読性はレビューの重要な観点
B) はい。命名はスタイルの好みであり、バグやセキュリティリスクではない
C) プロジェクトの命名規則に違反している場合のみ報告すべき
D) 常に報告すべきだが、優先度を低く設定する
Q3. [S5] CI/CD のコードレビューで、Claude が「この変数名は分かりにくい」とコメントした。これは false positive に分類されるか？
A) いいえ。コードの可読性はレビューの重要な観点
B) はい。命名はスタイルの好みであり、バグやセキュリティリスクではない
C) プロジェクトの命名規則に違反している場合のみ報告すべき
D) 常に報告すべきだが、優先度を低く設定する
正解: C
CI/CD でのレビューは false positive を最小化する必要があります。命名がプロジェクトの規約 (CLAUDE.md に定義) に違反している場合は客観的な指摘として有効ですが、個人的なスタイルの好みは報告すべきでありません。
▶
Q4. [S6] 構造化データ抽出で、あるフィールドが文書中に存在しない場合、最適な処理は？
A) Claude に推測で埋めさせる
B) 空文字列 "" を入れる
C) JSON Schema で nullable を許可し、null を設定する
D) そのフィールドをJSON から省略する
Q4. [S6] 構造化データ抽出で、あるフィールドが文書中に存在しない場合、最適な処理は？
A) Claude に推測で埋めさせる
B) 空文字列 "" を入れる
C) JSON Schema で nullable を許可し、null を設定する
D) そのフィールドをJSON から省略する
正解: C
推測 (A) はハルシネーションの原因。空文字列 (B) は「存在するが空」と「存在しない」を区別できない。省略 (D) は下流システムでエラーになる可能性がある。nullable を Schema で明示し null を設定するのが、データの正確性と下流互換性の両方を確保する正しい方法です。
▶
Q5. [S4] MCP サーバーのツール定義で description を「データを取得する」と記述した。問題点は？
A) 問題ない。Claude は文脈から適切に判断する
B) description が曖昧すぎて、Claude が類似ツールとの使い分けを判断できない
C) description は必須でないので省略した方がよい
D) 日本語で書いたのが問題。英語にすべき
Q5. [S4] MCP サーバーのツール定義で description を「データを取得する」と記述した。問題点は？
A) 問題ない。Claude は文脈から適切に判断する
B) description が曖昧すぎて、Claude が類似ツールとの使い分けを判断できない
C) description は必須でないので省略した方がよい
D) 日本語で書いたのが問題。英語にすべき
正解: B
Claude はツールの description を読んでどのツールを使うか判断します。「データを取得する」だけでは、何のデータを、どの条件で取得するのか不明で、類似ツールとの使い分けができません。「指定された顧客IDに紐づく注文履歴を取得する」のように具体的に記述する必要があります。
▶
Q6. [S2] Claude Code で長いセッションの後、前回の分析ファイルが大きく変更されていた。最適な対応は？
A) --resume でセッションを再開し、そのまま作業を続ける
B) 前回の結果を構造化サマリーにまとめ、新しいセッションを開始する
C) fork_session で分岐してから変更を確認する
D) 全ファイルを再度 Read して最新状態を取り込む
Q6. [S2] Claude Code で長いセッションの後、前回の分析ファイルが大きく変更されていた。最適な対応は？
A) --resume でセッションを再開し、そのまま作業を続ける
B) 前回の結果を構造化サマリーにまとめ、新しいセッションを開始する
C) fork_session で分岐してから変更を確認する
D) 全ファイルを再度 Read して最新状態を取り込む
正解: B
stale なツール結果を含む長いセッションを再開 (A) すると、古い情報と新しい状態が混在してしまいます。前回の成果を構造化サマリーにまとめて新しいセッションに渡すのが、信頼性の高い方法です。
▶
Q7. [S3] コーディネーターの allowedTools に "Task" を含めないとどうなるか？
A) サブエージェントは起動できるが、ツール制限が緩くなる
B) コーディネーターがサブエージェントを生成できない
C) サブエージェントが自律的に起動する
D) エラーにはならないが、パフォーマンスが低下する
Q7. [S3] コーディネーターの allowedTools に "Task" を含めないとどうなるか？
A) サブエージェントは起動できるが、ツール制限が緩くなる
B) コーディネーターがサブエージェントを生成できない
C) サブエージェントが自律的に起動する
D) エラーにはならないが、パフォーマンスが低下する
正解: B
Task ツールはサブエージェントを起動するための仕組みです。コーディネーターの allowedTools に "Task" が含まれていないと、コーディネーターはサブエージェントを生成する権限がなく、全ての処理を自分1人で行うことになります。
▶
Q8. [横断] エージェントが「回答に自信がない」と判断した場合の最適なパターンは？
A) とりあえず回答し、「不正確な可能性があります」と注記する
B) 追加の情報収集ツールを呼び出して確信度を上げる
C) 自己評価で confidence: low を出力し、human-in-the-loop ワークフローにルーティングする
D) 温度を下げて再度生成する
Q8. [横断] エージェントが「回答に自信がない」と判断した場合の最適なパターンは？
A) とりあえず回答し、「不正確な可能性があります」と注記する
B) 追加の情報収集ツールを呼び出して確信度を上げる
C) 自己評価で confidence: low を出力し、human-in-the-loop ワークフローにルーティングする
D) 温度を下げて再度生成する
正解: C
自己評価パターンで信頼度を構造化出力し、低信頼度の場合は human-in-the-loop にルーティングするのが正しい設計です。不確かな回答を注記付きで出す (A) のは無責任。追加情報収集 (B) も有効ですが、そもそも情報が不足している場合は効果がありません。
▶
Q9. [S1/S6] 異なるMCPツールが返すタイムスタンプ形式がバラバラ (Unix epoch, ISO 8601, 自然言語) の場合、最適な対処法は？
A) Claude にプロンプトで「ISO 8601 形式で解釈して」と指示する
B) PostToolUse フックで全ツール結果のタイムスタンプを ISO 8601 に正規化する
C) 各 MCP サーバーの実装を修正して統一フォーマットにする
D) タイムスタンプを無視して処理する
Q9. [S1/S6] 異なるMCPツールが返すタイムスタンプ形式がバラバラ (Unix epoch, ISO 8601, 自然言語) の場合、最適な対処法は？
A) Claude にプロンプトで「ISO 8601 形式で解釈して」と指示する
B) PostToolUse フックで全ツール結果のタイムスタンプを ISO 8601 に正規化する
C) 各 MCP サーバーの実装を修正して統一フォーマットにする
D) タイムスタンプを無視して処理する
正解: B
PostToolUse フックによるデータ正規化は、異種フォーマットの統一に最適です。プロンプト指示 (A) は確率的で一貫性が保証されません。MCP サーバー修正 (C) は外部サーバーの場合不可能なことが多い。フックで一貫した変換層を設けるのが実用的です。
▶
Q10. [横断] ワークフロー (固定パイプライン) ではなくエージェント (モデル駆動) を選ぶべき場面は？
A) 毎日同じ形式のレポートを生成する処理
B) ユーザーからの多様な質問に回答し、必要に応じて複数のツールを組み合わせる処理
C) CSV ファイルを読み込んでデータベースに投入する処理
D) 定型メールを送信する処理
Q10. [横断] ワークフロー (固定パイプライン) ではなくエージェント (モデル駆動) を選ぶべき場面は？
A) 毎日同じ形式のレポートを生成する処理
B) ユーザーからの多様な質問に回答し、必要に応じて複数のツールを組み合わせる処理
C) CSV ファイルを読み込んでデータベースに投入する処理
D) 定型メールを送信する処理
正解: B
エージェントは「状況によって次のアクションが変わる」場合に適します。ユーザーの質問は毎回異なり、どのツールをどの順で使うかを動的に判断する必要があります。A, C, D は毎回同じ手順で済む定型処理なのでワークフロー (固定パイプライン) が適切です。
▶
Q11. [S2/S5] Claude Code を使った開発ワークフローで、CLAUDE.md に定義したルールと CI/CD のレビュープロンプトで矛盾がある場合、どう設計すべきか？
A) CLAUDE.md のルールを優先し、CI/CD プロンプトは最小限にする
B) CI/CD プロンプトを優先し、CLAUDE.md は開発者のローカル用と割り切る
C) CLAUDE.md をコーディング規約の「信頼できる唯一の情報源 (single source of truth)」とし、CI/CD のレビュープロンプトは CLAUDE.md を参照する形で設計する
D) 両方に同じ内容をコピーして同期を保つ
Q11. [S2/S5] Claude Code を使った開発ワークフローで、CLAUDE.md に定義したルールと CI/CD のレビュープロンプトで矛盾がある場合、どう設計すべきか？
A) CLAUDE.md のルールを優先し、CI/CD プロンプトは最小限にする
B) CI/CD プロンプトを優先し、CLAUDE.md は開発者のローカル用と割り切る
C) CLAUDE.md をコーディング規約の「信頼できる唯一の情報源 (single source of truth)」とし、CI/CD のレビュープロンプトは CLAUDE.md を参照する形で設計する
D) 両方に同じ内容をコピーして同期を保つ
正解: C
CLAUDE.md はプロジェクトにコミットされ、チーム全体で共有されるため、コーディング規約の「信頼できる唯一の情報源」として機能します。CI/CD のレビュープロンプトは「CLAUDE.md に定義された規約に違反するコードを検出する」という形で参照すれば、ルールの二重管理を避けられます。コピーの同期 (D) は必ず乖離が発生するため、メンテナンスコストが高い。
▶
Q12. [S1/S3/S4] エージェントの stop_reason が "end_turn" で返ってきた場合と "tool_use" で返ってきた場合の違いとして正しいのは？
A) "end_turn" はエラー終了、"tool_use" は正常終了を意味する
B) "end_turn" は Claude がこれ以上アクションを取らず応答を完了したことを意味し、"tool_use" は Claude がツールを呼び出そうとしており、ツール実行結果を返す必要があることを意味する
C) どちらも同じで、出力の形式が異なるだけ
D) "end_turn" はストリーミング完了、"tool_use" はバッチ処理完了を意味する
Q12. [S1/S3/S4] エージェントの stop_reason が "end_turn" で返ってきた場合と "tool_use" で返ってきた場合の違いとして正しいのは？
A) "end_turn" はエラー終了、"tool_use" は正常終了を意味する
B) "end_turn" は Claude がこれ以上アクションを取らず応答を完了したことを意味し、"tool_use" は Claude がツールを呼び出そうとしており、ツール実行結果を返す必要があることを意味する
C) どちらも同じで、出力の形式が異なるだけ
D) "end_turn" はストリーミング完了、"tool_use" はバッチ処理完了を意味する
正解: B
stop_reason はエージェントループの制御に不可欠なシグナルです。"tool_use" が返された場合、Claude はツールを実行してその結果を返すことを期待しています。開発者はツールを実行し、結果を次のメッセージとして渡すエージェントループを構築します。"end_turn" が返された場合、Claude はこれ以上ツールを使わず応答を完了しているため、ユーザーに結果を返せます。この判定ロジックがエージェントループの中核です。構造化データ抽出 (S6) では tool_choice でツールを強制するため、stop_reason は必ず "tool_use" になります。