本番デプロイの最初のステップは何ですか？アプリケーションが準備完了かどうかをどのように評価しますか？
5つの次元での自己評価：セキュリティ（APIキーがenv varsに、異なる環境に異なるキー）；信頼性（リトライロジック、タイムアウト、フォールバック）；コスト管理（コンテキストウィンドウの制限、プロンプトキャッシング）；Observability（キーメトリクスのログ、費用アラート）；スケーラビリティ（レート制限処理）。
Batch APIを使用してバッチ処理タスクのコストを大幅に削減するには？
AnthropicのBatch APIは標準APIの50%安いですが、即時応答は保証されません（通常24時間以内）。即時応答を必要としないバッチタスクに理想的です。
使用方法：複数のリクエストをJSONLにパッケージ化；batch_idのために送信；完了したら結果をダウンロード。
費用見積もり：Batch APIは標準の50%のコスト。Prompt Cachingと組み合わせると、総コストを標準リアルタイムAPIの10〜15%まで削減できます。
ストリーミングの正しい実装とそれが必要な場合は？
ストリーミングにより、Claudeは生成するたびにいくつかのトークンをアプリケーションにプッシュします。
使用する場合：ユーザーが待機するシナリオ（チャットインターフェース、長いコンテンツ生成）；長いコンテンツの生成（200〜300語以上）。
使用しない場合：バックグラウンドバッチ処理；非常に短いアウトプット；処理前に完全なアウトプットが必要な場合。
Python SDKのwith client.messages.stream()コンテキストマネージャーが最もクリーンな実装方法です。
Claude APIアプリケーションのテスト戦略はどのように設計しますか？
AIアプリケーションのテストはより複雑です。LLMのアウトプットは非決定論的——正確なアウトプットマッチングは使えません。
機能テスト：アウトプットが要件を満たすかテスト——範囲内の長さ、必要な構造の存在、禁止コンテンツなし。
回帰テスト：期待されるアウトプット方向を持つゴールデンテストセットを維持します。
コストとパフォーマンステスト：各シナリオの平均トークン消費量、P95レイテンシ、エラーレートをベースラインとして測定します。
Claude APIの本番環境で最も軽視されているのは監視システムだ。レート制限・リトライ・コンテキスト管理は対処するが、API呼び出しごとのトークン使用量とレイテンシのログを残さない開発者が多い。コストが予期せず増加したとき、どの機能が原因かを特定するのに何時間もかかる。適切な可観測性インフラがあれば数分で済む問題だ。
セキュリティ： API認証情報は必ず環境変数に格納する。デプロイステージごとに別々のキーを使用し、コンソールで支出上限を設定する。
信頼性： リトライ機構、タイムアウト設定、プライマリ手段が失敗した際のフォールバックが必要だ。
コスト管理： 会話履歴の最大長を制限し、プロンプトキャッシュを有効にし、呼び出しごとのトークンを追跡する。
可観測性： 重要なメトリクスをログに記録し、コスト通知を有効にし、ユーザーインタラクションをトレースする。
スケーラビリティ： 大量リクエスト時のレート制限管理と並行リクエスト処理のキュー構造が必要だ。
Batch APIは標準価格の約半額だが、リアルタイム応答は保証されず、通常24時間以内に完了する。インタラクティブでないバッチ処理に適している。
処理の流れ：リクエストをJSONL形式でパッケージ化→バッチIDを取得して送信→完了ステータスをポーリング→完了後に結果を取得。
月間10万件以上のバッチ処理にプロンプトキャッシュを組み合わせると、コストは標準リアルタイム価格の10〜15%程度に削減できる。バックグラウンド処理、オフラインコンテンツ生成、大量の均一な分析作業に適しており、即時応答が必要なカスタマー向けインタラクションには向かない。
ストリーミングはClaudeがテキストを生成しながら出力を段階的に送信し、完全な生成を待たずに言葉が順次表示される。
使うべき場合： ユーザーインタラクティブなシナリオ（チャット、長文コンテンツ生成）、長い出力（200〜300トークン超）、厳格な応答性要件がある場合。
使わない場合： バックグラウンドバッチ処理、短い出力（50トークン未満）、下流処理の前に完成した出力が必要な場合。
Python SDKのwith client.messages.stream()コンテキストマネージャーが最もクリーンな実装で、トークンフラグメントとストリーム中断を自動で処理する。
モデル出力は非決定的なため、単純な完全一致検証は使えない。
API Keyのセキュリティ
アプリケーションコードに認証情報を直接埋め込まない。環境変数または専用のシークレット管理インフラを使用する。デプロイ環境ごとに個別の認証情報と独立した支出制限を維持する。
レート制限の処理
429レスポンス受信時は指数バックオフ＋ジッターを実装する：初回待機1秒、失敗ごとに2倍（2秒、4秒）、最大5回で終了。
コンテキストウィンドウ管理
会話履歴の上限を設定する（例：最新10往復または最大10万トークン）。上限超過時は古いエントリを削除する。usageフィールドのトークンメトリクスを常に記録する。
プロンプトキャッシュ
システムプロンプトが1,024トークンを超える場合、cache_control: {type: ephemeral}を適用する。そのセグメントのコストを90%削減できる。usage.cache_read_input_tokensでキャッシュヒットを確認する。
エラーハンドリング
| エラーコード | 対応 |
|---|---|
| 429 | 指数バックオフでリトライ |
| 500/529 | 1回リトライ後、ユーザーフレンドリーなメッセージを表示してログに記録 |
| 400 | リトライしない、詳細なエラーデータをログに記録 |
| タイムアウト | ストリーミング有効化、60〜120秒の閾値設定 |
可観測性
すべてのAPI取引を記録する：タイミング、モデル選択、入出力トークン数、応答時間、エラー分類、ユーザー識別子。ダッシュボードで平均レイテンシ・日次支出・失敗率・P99レイテンシを追跡する。日次コスト閾値・エラー率5%超・レイテンシ異常に対して通知を設定する。
可観測性はClaude API本番環境の中で最も過小評価されているインフラだ。レート制限・リトライ・コンテキスト管理は対処しても、リクエストごとのトークン使用量とレイテンシのログを残さない開発者が多い。これが重大な問題を生む：支出が予期せず増加したとき、原因の特定が長時間の調査になる。可観測性は単なるパフォーマンス向上ではなく、保守可能で問題解決が効率的なシステムを実現するための必須インフラだ。