Claude Code Configuration
& Context Management
Claude Code の設定・カスタマイズと、コンテキスト管理・信頼性設計の2つのドメインを合わせて学びます。合計で試験の35%を占める重要領域です。
対応コース
Claude Code in Action
+ Features of Claude
試験シナリオ
Scenario 2, 4, 5
コード生成 / 生産性 / CI/CD
あなたの強み
最も強い領域
仕様の正確な名前を復習
Claude Code のアーキテクチャ
Claude Code は AI がコードベースとやり取りするための「ツール統合型アーキテクチャ」を採用しています。Claude がコードを直接読み書きするのではなく、専用のツール群を通じてファイルシステムやシェルにアクセスします。
素のAPI利用との違い
Claude API を直接呼び出す場合と、Claude Code を使う場合では、開発体験が根本的に異なります。
素の Messages API
- - テキストの入出力のみ。ファイルを操作したければ、開発者がツールを自作して tool_use で接続する必要がある
- - 1回のリクエストで1回のレスポンス。ループを回すには自分で stop_reason を判定してリクエストを再送する
- - コンテキスト管理、エラーリトライ、権限制御のすべてをアプリケーション側で実装する
Claude Code
- - Read, Edit, Bash, Grep など7種の組み込みツールが最初から接続済み。MCP で外部ツールも追加可能
- - エージェントループが内蔵されており、stop_reason が end_turn になるまで自動でツール呼び出しと推論を繰り返す
- - CLAUDE.md による永続設定、Hooks による安全制御、Skills によるカスタム自動化が統合されている
- - コンテキスト上限に近づくと自動で Compaction が発動し、会話を圧縮して継続する
ツール統合レイヤーの構造
Claude Code は Claude モデルとローカル環境の間に「ツール統合レイヤー」を置いています。全てのファイル操作やコマンド実行はこのレイヤーを経由し、権限チェックやフック処理が適用されます。
ツール統合レイヤー
動作の仕組み
ユーザーが指示を入力
「このバグを直して」「テストを追加して」など
Claude がコードベースを調査
Read, Glob, Grep ツールでファイルを検索・読み取り
変更を実行
Edit, Write ツールでファイルを変更。Bash でコマンド実行
結果を確認・修正
テスト実行、ビルド確認、必要に応じて修正を繰り返す
このプロセスは Phase 1 で学んだエージェントループそのものです。Claude Code の内部では stop_reason によるループ制御が動いています。tool_use が返ればツール結果を渡して再リクエスト、end_turn が返ればループ終了です。
試験での出題傾向
「Claude Code は何を抽象化しているか」が問われます。正解は、エージェントループ、ツール実行、権限管理、コンテキスト圧縮の4つです。モデルの推論能力そのものを変えるわけではない点に注意してください。
ツールシステムの全体像
Claude Code には組み込みツール群があり、Claude はタスクに応じてこれらを自律的に選択・組み合わせて使います。
| ツール | 役割 | 使い分け |
|---|---|---|
Read |
ファイルの読み取り | 特定ファイルの内容確認。画像やPDFも読める |
Edit |
ファイルの部分編集 | 既存ファイルの特定箇所を差分で変更。最もよく使う |
Write |
ファイルの新規作成/全書き換え | 新しいファイルを作成、または全体を書き直す場合 |
Glob |
ファイルパターン検索 | **/*.tsx のようなパターンでファイルを探す |
Grep |
ファイル内容の検索 | コード内のキーワードや正規表現でファイルを横断検索 |
Bash |
シェルコマンド実行 | テスト実行、ビルド、git操作などシェル操作全般 |
Agent |
サブエージェント起動 | 複雑なリサーチやコード探索を別のClaudeインスタンスに委任 |
ツールの組み合わせ: 実際のワークフロー例
「ログイン処理のバリデーションバグを修正して」という指示を受けた場合、Claude は以下のようにツールを連鎖させます。
Step 1: Grep でバグの場所を特定
// Grep ツール呼び出し
pattern: "login.*validat"
type: "ts"
output_mode: "content"
→ 結果: src/auth/login.ts:42 に一致
Step 2: Read で該当ファイルの文脈を確認
// Read ツール呼び出し
file_path: "src/auth/login.ts"
offset: 35
limit: 20
→ 42行目付近のコードを確認。email のバリデーションで
正規表現のエスケープ漏れを発見
Step 3: Edit で修正を適用
// Edit ツール呼び出し
file_path: "src/auth/login.ts"
old_string: "const emailRegex = /^[a-zA-Z0-9.]+@/"
new_string: "const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$/"
Step 4: Bash でテスト実行して確認
// Bash ツール呼び出し
command: "npm test -- --grep 'login validation'"
→ Tests: 5 passed, 0 failed
この4ステップの間、Claude は毎回 stop_reason: tool_use を返し、ツール結果を受け取ってから次のアクションを判断しています。これがエージェントループの実態です。
allowedTools によるツール制限
Claude Code を CI/CD パイプラインや自動化スクリプトから呼ぶ場合、使用可能なツールを制限できます。--allowedTools フラグで許可するツールを明示的に指定します。
# 読み取り系ツールのみ許可 (変更を禁止)
claude --allowedTools "Read,Glob,Grep" \
-p "このコードベースのアーキテクチャを分析して"
# Bash を禁止 (ファイル操作のみ許可)
claude --allowedTools "Read,Edit,Write,Glob,Grep" \
-p "READMEを更新して"
# 特定の MCP ツールも含めて許可
claude --allowedTools "Read,Edit,Bash,mcp__slack__*" \
-p "修正してSlackに通知して"
セキュリティ上の重要事項
CI/CD で Claude Code を使う場合、Bash ツールを許可すると任意コマンドが実行可能になります。本番環境に影響するパイプラインでは allowedTools で Bash を除外するか、PreToolUse Hook でコマンドをフィルタリングしてください。
ツール実行の権限レベル
Claude Code の settings.json では、各ツールに対して3段階の権限を設定できます。
確認なしで自動実行する。Read, Glob, Grep など読み取り系のデフォルト。
実行前にユーザーの承認を求める。Edit, Write, Bash のデフォルト。ユーザーが内容を確認してから Yes/No を選択する。
常にブロック。特定のコマンドパターンを完全に禁止したい場合に使う。
試験で問われるポイント
Claude Code はツールを組み合わせてマルチステップタスクを処理します。「バグを修正して」→ Grep でエラー箇所を検索 → Read で該当ファイルを読む → Edit で修正 → Bash でテスト実行。この連鎖はエージェントループそのものです。また、allowedTools による制限と権限レベルの使い分けも出題されます。
CLAUDE.md の階層構造
CLAUDE.md は Claude Code に永続的な指示を与える設定ファイルです。「このプロジェクトではTypeScriptを使う」「テストはpytestで実行する」のようなルールを記述し、毎回の会話で自動的に読み込まれます。
3つの階層
CLAUDE.md は3つのレベルで配置でき、より具体的な階層が優先されます。
1. グローバル: ~/.claude/CLAUDE.md
ユーザー個人の全プロジェクト共通設定。コーディングスタイルの好み、共通ツール設定、個人的な慣習など。
2. プロジェクト: ./CLAUDE.md (リポジトリルート)
プロジェクト固有の設定。ビルドコマンド、テスト方法、アーキテクチャ方針など。Git にコミットしてチーム全体で共有できる。
3. サブディレクトリ: ./src/components/CLAUDE.md
特定のディレクトリ固有のルール。フロントエンドコンポーネントの命名規則や、API層のエラー処理方針など。
CLAUDE.md に書くべき内容
書くべきもの
- - プロジェクトの技術スタック
- - ビルド・テスト・リントのコマンド
- - コーディング規約と命名規則
- - アーキテクチャ上の重要な判断
- - 避けるべきパターンやライブラリ
書くべきでないもの
- - APIキーやシークレット
- - 頻繁に変わる一時的な情報
- - コードから明らかに読み取れる情報
- - 過度に詳細な手順書
# CLAUDE.md の例
## プロジェクト概要
React + TypeScript のSPAアプリケーション。
バックエンドは Python FastAPI。
## ビルドとテスト
- フロントエンド: `npm run build` / `npm test`
- バックエンド: `pytest tests/`
- リント: `npm run lint && ruff check .`
## コーディング規約
- コンポーネントは関数コンポーネントで作成
- API呼び出しは `src/api/` に集約
- エラーハンドリングは Result 型パターンを使用
## 禁止事項
- any 型の使用禁止
- console.log のコミット禁止
階層の上書きルール
CLAUDE.md の上書き動作を正確に理解することは試験で重要です。以下の原則で動作します。
原則 1: 近接性の原則
操作対象のファイルに「近い」CLAUDE.md が優先されます。src/api/CLAUDE.md のルールは src/api/ 配下のファイルにのみ適用され、プロジェクトルートの CLAUDE.md を上書きします。
原則 2: 加算的マージ
矛盾しない指示は全階層から加算的にマージされます。グローバルで「日本語で回答」、プロジェクトで「TypeScriptを使用」と書けば、両方が適用されます。
原則 3: 矛盾時は具体的な方が勝つ
同じ事項に対して矛盾する指示がある場合、より具体的な階層が優先されます。グローバルで「スペース2つ」、プロジェクトで「スペース4つ」なら、そのプロジェクト内ではスペース4つが適用されます。
チーム設定と個人設定の競合解決
プロジェクト CLAUDE.md は Git にコミットしてチーム共有する一方、グローバル CLAUDE.md は個人ローカルです。この2つが競合した場合の解決例を見てみましょう。
# ~/.claude/CLAUDE.md (個人設定)
コミットメッセージは日本語で書く。
インデントはスペース2つ。
テスト実行前にリントを必ず実行。
# ./CLAUDE.md (チーム設定)
コミットメッセージは英語で書く。
インデントはスペース4つ。
テストフレームワークは Vitest を使用。
解決結果
- - コミットメッセージ: 英語 (プロジェクト設定が優先。チーム規約はプロジェクトレベルに書くべき)
- - インデント: スペース4つ (プロジェクト設定が優先)
- - リント実行: 適用 (競合していないので個人設定がマージされる)
- - テストフレームワーク: Vitest (競合していないのでプロジェクト設定がそのまま適用)
試験でのひっかけ
「グローバル CLAUDE.md が全てのプロジェクトで最優先される」は誤りです。グローバル設定は最も優先度が低く、プロジェクトやサブディレクトリの設定で上書きされます。ただし、矛盾しない指示は全階層から加算的にマージされる点も見落とさないでください。
Agent Skills の設定
Agent Skills は Claude Code にカスタムのスラッシュコマンドや自動化を追加する仕組みです。繰り返し行う作業をスキルとして定義し、チームで共有できます。
スキルの構成
スキルは SKILL.md ファイルで定義します。
# ~/.claude/skills/my-skill/SKILL.md
---
name: commit
description: 変更をコミットする。/commit で起動
---
# コミットスキル
以下の手順でコミットを作成してください:
1. git diff で変更内容を確認
2. 変更内容に基づいた日本語のコミットメッセージを作成
3. git add で対象ファイルをステージ
4. git commit を実行
ユーザーが /commit と入力すると、このスキルのプロンプトが展開され、Claude がその手順に従って作業します。
SKILL.md のフロントマターフィールド
YAML フロントマター (--- で囲んだ部分) で、スキルのメタデータを定義します。
| フィールド | 必須 | 説明 |
|---|---|---|
name |
必須 | スラッシュコマンドの名前。/name で起動する |
description |
必須 | スキルの説明。スキル一覧表示時やClaude がスキルを自動選択する際に参照される |
allowed_tools |
任意 | このスキル内で使用許可するツールのリスト。指定しなければ全ツール使用可能 |
args |
任意 | スキルが受け取る引数の定義。/deploy staging のように引数を渡せる |
複雑なスキルの例: PR レビュー
引数を受け取り、複数のツールを組み合わせる実践的なスキル例です。
# ~/.claude/skills/review-pr/SKILL.md
---
name: review-pr
description: GitHub PRをレビューする。/review-pr 123 で起動
args: "PR番号 (例: 123)"
---
# PR レビュースキル
引数として渡されたPR番号のレビューを実施してください。
## 手順
1. `gh pr view {PR番号} --json title,body,files` でPR情報を取得
2. `gh pr diff {PR番号}` で差分を取得
3. 変更されたファイルを Read ツールで全文読み取り、文脈を把握
4. 以下の観点でレビューを実施:
- バグの可能性があるコード
- セキュリティ上の懸念
- パフォーマンスの問題
- コーディング規約違反 (CLAUDE.md を参照)
- テストの網羅性
5. レビュー結果を構造化して出力
## 出力形式
- 重大な問題 (マージブロック) を最初に列挙
- 改善提案を優先度順に記載
- 良い点も1-2個コメント
ユーザーが /review-pr 123 と入力すると、引数 "123" がスキルのプロンプトに渡され、Claude がこの手順に沿ってレビューを実行します。
スキルの配置場所
CLAUDE.md と同様、スキルも3つの階層に配置できます。
~/.claude/skills/
個人のグローバルスキル。全プロジェクトで使える。コミットスキルや汎用レビュースキルなど。
.claude/skills/ (プロジェクトルート)
プロジェクト固有のスキル。Git にコミットしてチーム共有可能。デプロイスキルやDB移行スキルなど。
~/.claude/projects/{project}/skills/
プロジェクト固有だが個人ローカル。Git にコミットしたくない個人的なスキルに使う。
用語解説
- Slash Command (スラッシュコマンド)
/commitや/reviewのように、スラッシュ+コマンド名で起動する操作。スキルとして定義する。- Custom Automation
- 繰り返し行う開発タスクをスキルとして定義し、1コマンドで実行できるようにしたもの。
Hooks システム
Hooks はClaude Code のツール実行やイベントに割り込んでカスタム処理を実行する仕組みです。Phase 1 で学んだ Agent SDK の PostToolUse と同じ考え方を Claude Code レベルで実現します。
Hook の種類
PreToolUse
ツールが実行される前に発火。ツール呼び出しをブロックしたり、入力を検証したりできる。
例: rm -rf のような危険なコマンドをブロック
PostToolUse
ツール実行後に発火。結果を加工・検証してから Claude に渡す。
例: ファイル変更後に自動でリンターを実行
Notification
セッション開始・終了やエラー発生時に発火。ログ記録や通知送信に使う。
例: セッション完了時に Slack に通知
Hook の設定方法
Hooks は ~/.claude/settings.json に設定します。マッチャーパターンでどのツールに対して発火するかを制御します。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": "~/.claude/hooks/check-bash-safety.sh"
}
],
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "~/.claude/hooks/auto-lint.sh"
}
]
}
}
Hook の入出力フォーマット
Hook コマンドはツール呼び出しの情報を JSON で標準入力 (stdin) から受け取り、制御結果を JSON で標準出力 (stdout) に返します。
PreToolUse Hook が受け取る stdin
{
"tool_name": "Bash",
"tool_input": {
"command": "rm -rf /tmp/test",
"description": "Delete test directory"
}
}
Hook が返す stdout (ブロックする場合)
{
"decision": "block",
"reason": "rm -rf コマンドは安全ポリシーにより禁止されています"
}
Hook が返す stdout (許可する場合)
{
"decision": "allow"
}
decision の値
- -
allow: ツール実行を許可 - -
block: ツール実行をブロック。reason がClaude にフィードバックされる - -
ask: ユーザーに確認を求める (対話モードのみ) - - 何も出力しない (exit 0): 暗黙の allow
実装例: 危険コマンドをブロックするセキュリティ Hook
以下は、Bash ツールで危険なコマンドが実行されるのを防ぐ PreToolUse Hook の実装例です。
#!/bin/bash
# ~/.claude/hooks/check-bash-safety.sh
# stdin から JSON を読み取り
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')
# 危険なパターンのリスト
DENY_PATTERNS=(
"rm -rf /"
"rm -rf ~"
"chmod 777"
"chmod 666"
"> /dev/"
"mkfs"
"dd if="
":(){ :|:& };:"
)
for pattern in "${DENY_PATTERNS[@]}"; do
if [[ "$COMMAND" == *"$pattern"* ]]; then
echo "{\"decision\":\"block\",\"reason\":\"セキュリティポリシー違反: '$pattern' を含むコマンドは禁止されています\"}"
exit 0
fi
done
# 危険なパターンに該当しなければ許可
echo '{"decision":"allow"}'
このスクリプトが PreToolUse の Bash マッチャーに設定されていれば、Claude が rm -rf / のようなコマンドを実行しようとした際に自動でブロックされます。Claude はブロック理由を受け取り、別のアプローチを試みます。
全 Hook イベント一覧
| イベント | 発火タイミング | 主な用途 |
|---|---|---|
| PreToolUse | ツール実行前 | 安全チェック、コマンドフィルタリング |
| PostToolUse | ツール実行後 | 自動リント、結果の加工、ログ記録 |
| Notification | 通知イベント時 | Slack通知、メール送信 |
| SessionStart | セッション開始時 | 環境チェック、前回の状態読み込み |
| SessionStop | セッション終了時 | セッション要約の保存、クリーンアップ |
Plan Mode と直接実行
Plan Mode
Claude がコードを変更する前に計画を提示し、ユーザーの承認を得てから実行するモード。
向いている場面:
- - 大規模なリファクタリング
- - アーキテクチャに影響する変更
- - 複数ファイルにまたがる修正
- - 不慣れなコードベースでの作業
直接実行 Mode
Claude が計画と実行を連続して行う。高速だが、方向を誤ると手戻りが大きい。
向いている場面:
- - 小さなバグ修正
- - テストの追加
- - ドキュメントの更新
- - 明確で範囲の狭いタスク
試験での判断基準
「影響範囲が広い or 不確実性が高い」→ Plan Mode。「影響範囲が狭い and 確実」→ 直接実行。Scenario 2 (コード生成) で、plan mode をいつ使うべきかが問われます。
コンテキストウィンドウ管理
Domain 5: Context Management & Reliability
コンテキストウィンドウはClaude が1回の会話で処理できるテキスト量の上限です。エージェントでは会話が長くなるほどコンテキストが消費され、管理が重要になります。
コンテキスト消費の主な原因
ツール結果の蓄積
ファイル読み取りやコマンド出力の結果が会話履歴に追加される
大きなファイルの読み込み
数千行のファイルをそのまま読むとコンテキストを大量に消費
マルチターンの長い会話
会話が長くなるほど全履歴が毎回送信される
トークンカウントの基礎
コンテキストウィンドウの容量はトークン数で計測されます。トークンは単語の断片のようなもので、英語では1単語が約1.3トークン、日本語では1文字が約1.5-2トークンに相当します。
200K
Claude Sonnet/Opus の
コンテキストウィンドウ
~150K 文字
英語テキスト換算
(本 約1冊分)
~100K 文字
日本語テキスト換算
(文庫本 約0.5冊分)
注意点
エージェントの会話では、system prompt、CLAUDE.md の内容、ツール定義、会話履歴、ツール結果の全てがコンテキストを消費します。200K トークンのうち、ユーザーの作業に使えるのは実質的にその60-70%程度です。
会話中のコンテキスト増加パターン
エージェントの会話が進むにつれて、コンテキスト使用量がどのように変化するかを可視化します。
コンテキスト使用量 (200K トークンウィンドウの場合)
ツール結果の蓄積で急増 → Compaction で圧縮 → 再び増加のサイクル
管理戦略
Compaction (圧縮)
コンテキストが上限に近づくと、古い会話を要約して圧縮します。重要な情報 (変更したファイル、未完了タスク、ユーザーの指示) を保持しつつ、詳細を削減します。
選択的読み込み
ファイル全体ではなく必要な行範囲だけを Read で読む。Grep で該当箇所を特定してから Read する。
サブエージェントによるコンテキスト分離
Agent ツールでサブエージェントに調査を委任すると、その調査結果だけがメインのコンテキストに返り、調査過程の大量のツール結果はメインのコンテキストを汚さない。
Compaction の詳細戦略
Compaction は単なるテキスト切り捨てではなく、情報の優先度に基づく知的な圧縮です。
保持される情報 (高優先度)
- - system prompt と CLAUDE.md の内容 (毎回再注入される)
- - 変更したファイルのパスと変更内容の要約
- - 未完了のタスクとユーザーの最新の指示
- - ユーザーからの修正フィードバック (間違いの指摘など)
圧縮される情報 (低優先度)
- - ツール呼び出しの詳細なパラメータ
- - ファイル読み取りの生テキスト (要約に置き換え)
- - 中間的な試行錯誤の過程
- - 完了済みタスクの詳細手順
Compaction のカスタマイズ
CLAUDE.md に「compaction 時に必ず保持する情報」を指示できます。例えば「圧縮時は変更したファイルのパスと未完了タスクを必ず残すこと」のように記述すると、Compaction の品質を制御できます。
長文ドキュメント処理
分割処理のパターン
チャンキング (Chunking)
長いドキュメントを意味的なまとまりで分割し、各チャンクを個別に処理。結果を後で統合。
Map-Reduce パターン
Map: 各チャンクに同じ処理を並行適用。Reduce: 各チャンクの結果を1つの出力にまとめる。
段階的精査
まず全体を粗く読んで構造を把握 → 関連する部分だけ詳細に読む。コンテキスト効率が高い。
チャンキングの実装例
長文を固定サイズで分割する方法と、意味的境界で分割する方法があります。
固定トークン数チャンキング
def chunk_by_tokens(text, max_tokens=4000, overlap=200):
"""テキストをトークン数ベースで分割。オーバーラップで文脈を維持。"""
tokens = tokenizer.encode(text)
chunks = []
start = 0
while start < len(tokens):
end = start + max_tokens
chunk_tokens = tokens[start:end]
chunks.append(tokenizer.decode(chunk_tokens))
start = end - overlap # オーバーラップ分だけ戻る
return chunks
意味的境界チャンキング (セクション単位)
def chunk_by_sections(markdown_text):
"""Markdownの見出しで分割。各セクションが1チャンクになる。"""
sections = re.split(r'\n(?=#{1,3} )', markdown_text)
chunks = []
for section in sections:
if count_tokens(section) > max_tokens:
# 大きすぎるセクションは段落で再分割
sub_chunks = split_by_paragraphs(section, max_tokens)
chunks.extend(sub_chunks)
else:
chunks.append(section)
return chunks
戦略の比較
| 戦略 | コンテキスト効率 | 精度 | 向いている場面 | 注意点 |
|---|---|---|---|---|
| チャンキング + 逐次処理 | 高 | 中 | 要約、翻訳、情報抽出 | チャンク境界で情報が分断されうる |
| Map-Reduce | 高 | 高 | 分析、レビュー、比較 | Reduce フェーズの設計が重要 |
| 段階的精査 | 最高 | 高 | コードベース調査、特定情報の検索 | 最初のスキャンで見落とすリスク |
| 全文一括投入 | 低 | 最高 | 短い文書、文書間の相互参照が必要 | 200Kトークン以内に収まる場合のみ |
試験で問われるポイント
「100ページの法律文書から特定の条項を見つけて要約する」タスクに最適な戦略はどれか、のような問いが出ます。段階的精査が正解です。全文を投入するのはコンテキスト非効率で、固定チャンキングだと条項が分断される可能性があります。
Extended Thinking
Extended Thinking は Claude に「回答の前に深く考える時間」を与える機能です。複雑な推論、数学、コード分析などで精度が向上します。
使い方
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=16000,
thinking={
"type": "enabled",
"budget_tokens": 10000 # 思考に使えるトークン数
},
messages=[{"role": "user", "content": "..."}]
)
レスポンスには thinking ブロックと text ブロックの両方が含まれます。thinking ブロックには Claude の推論過程が記録されますが、通常はユーザーに見せずデバッグ用途に使います。
budget_tokens とは
Claude が「考える」ために使えるトークンの上限。大きいほど深い推論が可能だが、レスポンス時間とコストが増える。タスクの複雑さに応じて調整する。max_tokens の中に budget_tokens が含まれるため、budget_tokens は必ず max_tokens 未満にする必要がある。
使うべき場面と使わないべき場面
Extended Thinking が有効な場面
- - 数学やロジックの複雑な推論問題
- - 大規模コードベースの設計判断やリファクタリング方針
- - 複数の制約を同時に満たすコード生成
- - セキュリティ脆弱性の分析
- - 曖昧な要件からの仕様整理
- - デバッグで原因が特定しにくいバグの分析
Extended Thinking が不要な場面
- - 単純な質問応答やFAQ対応
- - テンプレート的なコード生成
- - 文章の翻訳や校正
- - ファイルの読み書きなど定型操作
- - レスポンス速度が重視されるリアルタイム処理
- - コスト最小化が優先される大量バッチ処理
Chain-of-Thought プロンプティングとの比較
「ステップバイステップで考えて」というプロンプト技法 (Chain-of-Thought) と、Extended Thinking は似ているようで異なります。
| 観点 | Chain-of-Thought | Extended Thinking |
|---|---|---|
| 実装方法 | プロンプトに「ステップバイステップで」と書く | API パラメータで thinking を有効化 |
| 思考の可視性 | 回答本文に推論過程が含まれる | thinking ブロックに分離。回答本文は結論のみ |
| トークン消費 | 出力トークン (max_tokens) から消費 | budget_tokens から消費。回答本文の容量を圧迫しない |
| 推論の深さ | モデルの通常の推論能力で処理 | 専用の推論モードで、より深い探索が可能 |
| 併用 | Extended Thinking 有効時は CoT プロンプトは不要。併用しても効果は限定的 | |
試験での判断基準
「複雑なタスクの精度を上げたい」→ Extended Thinking。「コストを抑えつつ推論を改善したい」→ Chain-of-Thought プロンプティング。両者は排他的ではないが、Extended Thinking が使える環境なら、単純な CoT プロンプトより優れた結果が期待できます。
プロンプトキャッシュ
Prompt Caching は、リクエスト間で共通するプロンプト部分をキャッシュし、コストとレイテンシを削減する機能です。
仕組み
system prompt や固定のコンテキスト (RAG の参照文書など) は毎回同じ内容を送ることになります。これをキャッシュすることで、2回目以降のリクエストでは処理済みの結果を再利用し、処理時間とコストを大幅に削減できます。
キャッシュに向いているもの
- - 長い system prompt
- - RAG で取得した参照文書
- - few-shot examples のセット
- - マルチターンの会話履歴 (先頭部分)
キャッシュのルール
- - プロンプトの先頭からの一致で判定
- - 途中が変わるとその後は全てキャッシュミス
- - 最小キャッシュ可能サイズ: 1024 トークン (Sonnet), 2048 トークン (Haiku)
- - TTL: 5分間。5分以内に再リクエストするとキャッシュヒット
cache_control パラメータの使い方
キャッシュしたいコンテンツブロックの末尾に cache_control を追加します。キャッシュの区切り位置 (ブレークポイント) を明示的に指定する仕組みです。
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
system=[
{
"type": "text",
"text": "あなたは法律文書の専門家です...",
},
{
"type": "text",
"text": large_reference_document, # 大量の参照文書
"cache_control": {"type": "ephemeral"}
# ↑ ここまでをキャッシュ対象にする
}
],
messages=[
{"role": "user", "content": "第3条の解釈を教えて"}
]
)
"type": "ephemeral" が唯一のキャッシュタイプです。「一時的な」という意味で、TTL 経過後に自動的に消えます。
マルチターンでの活用
# 会話履歴の前半部分をキャッシュして、後半だけ再処理する
messages = [
{"role": "user", "content": "第1条について..."},
{"role": "assistant", "content": "第1条は..."},
{"role": "user", "content": "第2条について..."},
{
"role": "assistant",
"content": [{
"type": "text",
"text": "第2条は...",
"cache_control": {"type": "ephemeral"}
# ここまでキャッシュ。次のユーザーメッセージだけ再処理
}]
},
{"role": "user", "content": "第3条は？"}
]
コスト削減効果
プロンプトキャッシュの料金構造を理解することは、プロダクション設計で重要です。
1.25x
書き込み
キャッシュに書き込む最初のリクエストは、通常の入力トークン価格の1.25倍。わずかな追加コストが発生する。
0.1x
読み込み
キャッシュヒット時は通常価格の10%。2回目以降のリクエストで90%のコスト削減。
具体例: 50K トークンの system prompt
キャッシュなし 10回: 50K x 10 = 500K トークン分のコスト。キャッシュあり 10回: 50K x 1.25 + 50K x 0.1 x 9 = 62.5K + 45K = 107.5K トークン分のコスト。約78%のコスト削減になります。さらにレイテンシも大幅に改善されます。
Human-in-the-Loop
全てを自動化するのではなく、重要な判断ポイントで人間の確認を挟む設計パターンです。エージェントの信頼性を大幅に向上させます。
人間を挟むべき場面
取り消し不可能なアクション: データ削除、メール送信、外部 API への書き込み
高リスクの判断: 金額の大きい処理、セキュリティに関わる変更
曖昧な判断: 複数の解釈が可能な顧客リクエスト
自己評価で低信頼度のケース: Claude 自身が確信を持てない場合
Self-Evaluation (自己評価パターン)
Claude に自身の出力を評価させ、信頼度が低い場合は人間にエスカレーションするパターンです。
# 自己評価の例
system = """タスクを完了したら、以下の形式で自己評価を出力してください:
<self_evaluation>
<confidence>high/medium/low</confidence>
<reasoning>判断の根拠</reasoning>
<needs_human_review>true/false</needs_human_review>
</self_evaluation>
confidence が low の場合は必ず needs_human_review を true にしてください。"""
実装パターン集
承認ゲート (Approval Gate)
特定のアクションの前に必ず人間の承認を挟む。Claude Code の権限システム (allow/ask/deny) がこのパターンの実装です。
# settings.json での承認ゲート設定
{
"permissions": {
"Bash": {
"default": "ask", # Bashは常に確認
"allow": ["npm test", "npm run lint"], # 安全なコマンドは自動許可
"deny": ["rm -rf", "chmod 777"] # 危険なコマンドは完全禁止
},
"Edit": "ask",
"Read": "allow"
}
}
レビューキュー (Review Queue)
エージェントの出力を直接適用せず、レビューキューに入れて人間が確認してから反映する。CI/CD でのPR自動生成に使われるパターンです。
# CI/CD でのレビューキューパターン
# 1. Claude Code がブランチを切って変更
claude --allowedTools "Read,Edit,Write,Glob,Grep,Bash" \
-p "issue #42 を修正してPRを作成して"
# 2. PRが作成される → 自動テスト実行
# 3. 人間のレビュアーがPRを確認 → approve or request changes
# 4. マージは人間が判断
段階的自律性 (Graduated Autonomy)
リスクの大きさに応じて自律性のレベルを変える設計パターン。低リスクは全自動、中リスクは事後レビュー、高リスクは事前承認とする。
権限チェックフローの実装
Agent SDK で Human-in-the-Loop を実装する場合、ツール実行の前に権限チェックロジックを挟みます。
async def run_with_approval(agent, task):
"""高リスクアクションに対して人間の承認を求めるラッパー"""
HIGH_RISK_TOOLS = ["database_write", "send_email", "deploy"]
async for event in agent.stream(task):
if event.type == "tool_use":
tool_name = event.tool_name
if tool_name in HIGH_RISK_TOOLS:
# 人間に承認を求める
print(f"承認が必要: {tool_name}")
print(f"パラメータ: {event.tool_input}")
approval = input("実行しますか？ (yes/no): ")
if approval != "yes":
# ブロック → エージェントに理由を返す
yield ToolResult(
error="ユーザーが実行を拒否しました"
)
continue
# 許可 → ツール実行
result = await execute_tool(event)
yield result
エスカレーション設計
構造化ハンドオフ
エージェントが問題を人間にエスカレーションする際、会話全文を渡すのではなく、構造化されたサマリーを渡します。人間のオペレーターは会話履歴にアクセスできないことが多いためです。
# エスカレーション時に渡す構造化サマリー
escalation = {
"customer_id": "CUST-456",
"issue_summary": "注文ORD-789の返金要求。金額$750で上限超過。",
"root_cause": "商品が破損した状態で届いた",
"attempted_actions": ["注文状況確認済", "配送履歴確認済"],
"recommended_action": "全額返金 + 再配送",
"urgency": "high"
}
試験で問われるポイント
Scenario 1 (カスタマーサポート) で、エスカレーション時に何を含めるべきかが問われます。顧客ID、問題の要約、根本原因、試行したアクション、推奨対応の全てを含む構造化サマリーが正解です。
確認テスト
▶
Q1. CLAUDE.md の階層で、プロジェクトルートの CLAUDE.md とサブディレクトリの CLAUDE.md が矛盾する場合、どちらが優先される？
A) グローバル (~/.claude/CLAUDE.md) が常に最優先
B) サブディレクトリの CLAUDE.md がより具体的なので優先
C) プロジェクトルートが常に優先
D) 最後に更新されたファイルが優先
Q1. CLAUDE.md の階層で、プロジェクトルートの CLAUDE.md とサブディレクトリの CLAUDE.md が矛盾する場合、どちらが優先される？
A) グローバル (~/.claude/CLAUDE.md) が常に最優先
B) サブディレクトリの CLAUDE.md がより具体的なので優先
C) プロジェクトルートが常に優先
D) 最後に更新されたファイルが優先
正解: B
CLAUDE.md はより具体的な (ファイルに近い) 階層が優先されます。サブディレクトリのルールはそのディレクトリ内のファイルに対して、プロジェクトルートのルールを上書きします。
▶
Q2. Plan Mode を使うべき場面として最も適切なのは？
A) 1つのファイルにコメントを追加する
B) 既存の関数名をリネームする (1箇所)
C) アプリケーションの認証方式を JWT から OAuth に変更する
D) README にインストール手順を追記する
Q2. Plan Mode を使うべき場面として最も適切なのは？
A) 1つのファイルにコメントを追加する
B) 既存の関数名をリネームする (1箇所)
C) アプリケーションの認証方式を JWT から OAuth に変更する
D) README にインストール手順を追記する
正解: C
認証方式の変更は複数ファイルに影響し、アーキテクチャ上の判断が必要な大規模変更です。Plan Mode で計画を提示し、ユーザーの承認を得てから実行すべきです。A, B, D は影響範囲が狭く直接実行で十分です。
▶
Q3. コンテキストウィンドウの消費を抑えるために、サブエージェントを活用する利点は？
A) サブエージェントは無制限のコンテキストを持つ
B) サブエージェントの調査過程がメインのコンテキストに追加されず、結果だけが返る
C) サブエージェントはキャッシュを共有するのでコスト削減になる
D) サブエージェントは自動でコンテキストを圧縮する
Q3. コンテキストウィンドウの消費を抑えるために、サブエージェントを活用する利点は？
A) サブエージェントは無制限のコンテキストを持つ
B) サブエージェントの調査過程がメインのコンテキストに追加されず、結果だけが返る
C) サブエージェントはキャッシュを共有するのでコスト削減になる
D) サブエージェントは自動でコンテキストを圧縮する
正解: B
サブエージェントに調査を委任すると、途中のツール結果 (大量のファイル読み取り等) はサブエージェントのコンテキスト内で処理され、メインのコンテキストには最終結果だけが返ります。これがコンテキスト保護の主要なメリットです。
▶
Q4. Hooks の PreToolUse と PostToolUse の違いとして正しいのは？
A) PreToolUse はツール実行前にブロック可能、PostToolUse はツール結果を加工可能
B) PreToolUse はユーザー承認用、PostToolUse はログ記録用
C) PreToolUse はBashツール専用、PostToolUse は全ツール対応
D) PreToolUse は同期実行、PostToolUse は非同期実行
Q4. Hooks の PreToolUse と PostToolUse の違いとして正しいのは？
A) PreToolUse はツール実行前にブロック可能、PostToolUse はツール結果を加工可能
B) PreToolUse はユーザー承認用、PostToolUse はログ記録用
C) PreToolUse はBashツール専用、PostToolUse は全ツール対応
D) PreToolUse は同期実行、PostToolUse は非同期実行
正解: A
PreToolUse はツール実行前に発火し、危険なコマンドをブロックできます。PostToolUse はツール実行後に発火し、結果をClaude に渡す前に加工・検証できます。どちらも全ツールに対応し、matcher でフィルタリングします。
▶
Q5. Extended Thinking の budget_tokens を大きくした場合の影響は？
A) 回答の文字数が増える
B) より深い推論が可能になるが、レスポンス時間とコストが増加する
C) コンテキストウィンドウの上限が拡張される
D) 使用可能なツールの数が増える
Q5. Extended Thinking の budget_tokens を大きくした場合の影響は？
A) 回答の文字数が増える
B) より深い推論が可能になるが、レスポンス時間とコストが増加する
C) コンテキストウィンドウの上限が拡張される
D) 使用可能なツールの数が増える
正解: B
budget_tokens はClaude が「考える」ために使えるトークン上限です。大きいほど複雑な推論が可能ですが、処理時間とAPIコストが増えます。回答のテキスト長 (max_tokens) とは別のパラメータです。
▶
Q6. エスカレーション時に人間のオペレーターに渡すべき情報として、最も包括的な選択肢は？
A) 会話のトランスクリプト全文
B) 顧客IDと問題の説明
C) 顧客ID、問題の要約、根本原因、試行したアクション、推奨対応を含む構造化サマリー
D) エラーログと技術的なスタックトレース
Q6. エスカレーション時に人間のオペレーターに渡すべき情報として、最も包括的な選択肢は？
A) 会話のトランスクリプト全文
B) 顧客IDと問題の説明
C) 顧客ID、問題の要約、根本原因、試行したアクション、推奨対応を含む構造化サマリー
D) エラーログと技術的なスタックトレース
正解: C
人間のオペレーターは会話全文にアクセスできないことが多いので (A は非実用的)、構造化されたサマリーが最適です。顧客特定情報、根本原因分析、既に試したこと、推奨アクションを含めることで、オペレーターが即座に対応を引き継げます。
▶
Q7. プロンプトキャッシュで cache_control を設定する際、キャッシュの有効期限 (TTL) はどのくらい？
A) 1分
B) 5分
C) 1時間
D) 24時間
Q7. プロンプトキャッシュで cache_control を設定する際、キャッシュの有効期限 (TTL) はどのくらい？
A) 1分
B) 5分
C) 1時間
D) 24時間
正解: B
プロンプトキャッシュの TTL は5分間です。5分以内に同じプレフィックスのリクエストを送ればキャッシュヒットとなり、入力トークンコストが90%削減されます。5分を過ぎると新たにキャッシュを書き込む必要があります。
▶
Q8. Claude Code の allowedTools で Bash を除外した場合、Claude はどのように動作する？
A) エラーが発生してセッションが終了する
B) Bash を使おうとするたびにユーザーに許可を求める
C) Bash が必要なタスクは Bash なしで代替手段を試みるか、実行不可能と報告する
D) 自動的に Edit ツールでスクリプトファイルを作成する
Q8. Claude Code の allowedTools で Bash を除外した場合、Claude はどのように動作する？
A) エラーが発生してセッションが終了する
B) Bash を使おうとするたびにユーザーに許可を求める
C) Bash が必要なタスクは Bash なしで代替手段を試みるか、実行不可能と報告する
D) 自動的に Edit ツールでスクリプトファイルを作成する
正解: C
allowedTools で除外されたツールは Claude のツール一覧に含まれなくなります。Claude は利用可能なツールの中で代替手段を探すか、そのアクションが実行できないことをユーザーに報告します。セッションが終了したり、自動的に別のツールに置き換えたりはしません。
▶
Q9. 100ページの技術仕様書から特定のAPI仕様を見つけて要約する場合、コンテキスト効率が最も高い戦略は？
A) 全文を1回のリクエストで送信する
B) 10ページずつ固定サイズで分割して順に処理する
C) まず目次や見出しレベルで全体構造を把握し、関連セクションだけ詳細に読む (段階的精査)
D) Map-Reduce で全ページを並列処理する
Q9. 100ページの技術仕様書から特定のAPI仕様を見つけて要約する場合、コンテキスト効率が最も高い戦略は？
A) 全文を1回のリクエストで送信する
B) 10ページずつ固定サイズで分割して順に処理する
C) まず目次や見出しレベルで全体構造を把握し、関連セクションだけ詳細に読む (段階的精査)
D) Map-Reduce で全ページを並列処理する
正解: C
段階的精査が最もコンテキスト効率が高い戦略です。まず構造をスキャンして関連箇所を特定し、必要な部分だけを詳細に読みます。全文投入 (A) はコンテキストを大量に消費し、固定分割 (B) は仕様が分断される可能性があり、Map-Reduce (D) は検索タスクには過剰です。