D2直前対策チートシート——Claude API・SDK実装（試験比率18%）【CCA Foundations対策】

試験比率18%。Messages APIの基本構造・ストリーミング・構造化出力・Batch APIの制約が主な出題範囲。

---

Messages APIの基本構造

• roleはuserとassistantを交互に並べる（連続するuserメッセージは不可）
• systemはmessages配列の外で渡す（最初のuserより前の役割設定）
• max_tokensは出力の上限。コンテキストウィンドウは入力+出力の合計
• stop_sequences：指定した文字列が出現したら出力を打ち切る

→ 詳細: Claude APIをPythonで動かす / マルチターン会話

---

ストリーミング

• 最初のトークンが早く届く → UXが向上する（応答が「来ている感」が出る）
• stream=TrueでSSE（Server-Sent Events）形式で受け取る
• ツール使用時はfine-grainedオプションでツール入力のストリーミングも可能

→ 詳細: レスポンス制御と構造化出力

---

構造化出力

• JSONを確実に得る方法：ツール定義にJSONスキーマを渡してtool_useとして呼ばせる
• tool_choice: {"type": "tool", "name": "..."} で特定ツールを強制呼び出し
• プロンプトで「JSONで返して」と指示するだけでは不安定（スキーマ強制にならない）

→ 詳細: レスポンス制御と構造化出力

---

tool_choice の3モード

モード	挙動	使いどころ
auto（デフォルト）	Claudeが判断してツールを使うか決める	通常のエージェント
any	いずれか1つのツールを必ず使う	ツールなし応答を防ぎたいとき
tool（特定指定）	指定したツールを必ず呼び出す	構造化出力の強制

---

Batch API：使っていいケースと使えないケース

条件	Batch API	理由
夜間バッチ・週次レポート	✅ 適切	latency許容・ポーリング設計済み
誰かがブロックして待つ処理	❌ 不適切	最大24時間の遅延が発生しうる
ツール呼び出しループが必要	❌ 不適切	アーキテクチャ的に非互換（遅延の問題ではない）

Batch APIはfire-and-forgetモデル：リクエスト送信後、ツール結果を受け取りながら処理を続けるループは成立しない。「遅延が許容できれば使える」は誤り。

→ 詳細: Message Batches APIの設計制約

---

コンテキストウィンドウ管理

• 長い会話は古いやりとりを要約してウィンドウを節約する（progressive summarization）
• 要約は数値・日付・金額などの具体的な数値が失われやすい
• 重要な事実（金額・注文番号・日付）は要約の外の「永続ブロック」に保持する

→ 詳細: マルチターン会話 / コンテキスト最適化

---

よくある誤解まとめ

誤解	実際
max_tokensを増やすとコンテキストが広がる	出力の上限を増やすだけ。入力は変わらない
Batch APIはlatencyが問題なければツールループでも使える	fire-and-forgetのアーキテクチャ上、ツールループ自体が成立しない
プロンプトで「JSON形式で返して」と書けば構造化出力になる	不安定。tool_useを使ったスキーマ強制が確実
systemパラメータはmessages配列に含める	messagesの外で渡す別パラメータ
stop_reasonは無視してよい	tool_use/end_turnでループ継続か終了かを制御する重要なフィールド