Claude API を本番投入する前に決めておくインフラ要件 — 規模・SLA・コンプライアンスから逆算する設計判断

「動くプロトタイプはできました。来週から本番に出していいですか？」と相談を受けるたびに、私はいつも一拍置いて聞き返します。「想定ユーザー数は？SLAは？データはどこに保存されますか？」と。すると、3つとも即答できる方は意外と少ないのです。

Claude API のコードそのものは数十行で書けます。しかし「本番で持つ」ための設計判断は、コードを書き始める前に決めておかないと、後から構造を組み替えるのに何倍もの時間が必要になります。今回は、私が個人プロジェクトと受託案件で繰り返し使っている「インフラ要件を逆算する3軸」をまとめます。

トラフィック規模を3段階で見積もる

最初に決めるのはピーク QPS（Queries Per Second）と月間トークン量です。これが曖昧なまま始めると、Anthropic 側の組織レート制限・モデル選定・キャッシュ戦略すべてがぶれます。

私は3段階で粗く区切る方法を好みます。

Tier S（〜1,000 MAU・10 RPM 程度）: 個人開発の MVP や社内ツール。Tier 1 アカウントの初期上限内に収まることがほとんどで、特別な工夫なしに始められます
Tier M（1,000〜50,000 MAU・100 RPM 程度）: 一般公開された Web サービスの初期成長期。Tier 2 への昇格申請、プロンプトキャッシュ、バックグラウンドジョブの非同期化が要件になります
Tier L（50,000+ MAU・1,000 RPM 以上）: ここからは「単一リージョン × 単一モデル」の構成が成立しません。Bedrock や Vertex AI を併用したマルチクラウド、モデルのフォールバック設計が前提になります

ピーク QPS は「想定 DAU × 1人あたり1日のリクエスト数 ÷ 1日の有効秒数（私は10時間 = 36,000秒で計算）× ピーク係数3」で粗く出せます。たとえば DAU 10,000 で1人あたり3リクエストなら、ピーク QPS は約2.5。これを月間に直すとトークン量も逆算できます。

このあたりの詳細な見積もり式はClaude API 月額コスト計算とプロンプトキャッシュ設計ガイドも参考になります。

SLA から可用性アーキテクチャを逆算する

「99.5%」と「99.95%」の差は、月間ダウンタイムにすると約4時間と22分です。この差はそのまま「単一プロバイダで成立するか、フォールバックが必須か」という設計の分岐になります。

私が現場で使っている目安はこうです。

99.5%（月4時間以内）: Anthropic API 直接呼び出し + リトライ + 軽いタイムアウト管理で十分。社内ツールや無料サービスはこのラインで設計します
99.9%（月43分以内）: プロンプトキャッシュ + レスポンスキャッシュ + 同モデルの別リージョン経由（Bedrock 等）でフォールバック先を1つ用意します
99.95%以上（月22分以内）: 主モデル（Sonnet 4.6 等）→ サブモデル（Haiku 4.5）→ ローカル推論（Gemma 等）まで含めた階層的フォールバックが必要です。SLA 違反時の SLO レポートまで自動化することを前提に設計します

注意したいのは、SLA は「Claude API 側の SLA」と「自社サービスの SLA」を区別する点です。Anthropic 公式の Production SLA を直接保証しない限り、自社の数字は常に Claude 側より低くなります。ユーザーに約束する数字は、必ず内部で SLO（運用目標）として落とし込んでください。

実装パターンの詳細はClaude API マルチモデルフォールバック高可用性設計ガイドで扱っています。

データレジデンシーとコンプライアンスの判断

ここは「BtoB SaaS でつまずきがちな盲点」です。日本企業のクライアントから「データを国内に置いてほしい」と言われた瞬間に、Anthropic API 直接呼び出しは選択肢から外れます。理由は、執筆時点で Anthropic の API は米国リージョンが中心で、データレジデンシー保証は限定的だからです。

判断軸は3つです。

個人情報を Claude に送るか: 送るなら最低限、入力時の PII マスキングを設計に含める。電話番号・住所・カード番号はトークン化してから API に渡す
規制業界か（金融・医療・自治体）: 規制があるなら Bedrock 経由で AWS 内に閉じる、もしくは Vertex AI 経由で Google Cloud のデータレジデンシー設定を継承する選択肢を最初から検討する
顧客データの学習利用: Claude API は学習に使われない設定が標準ですが、契約書面で明示することを顧客から求められるケースが多いです。Enterprise プランなら DPA（データ処理契約）が結べます

PII マスキングの実装パターンはClaude API PII マスキング本番設計ガイドに詳しくまとめてあります。

コスト予測の最低限の式

「Claude API はいくらかかるんですか？」の答えは、最低限この式から始めます。

// 月間コスト概算（USD）
function estimateMonthlyCost({
  dau,                    // 想定 DAU
  requestsPerUser,        // 1人あたり1日のリクエスト数
  inputTokensAvg,         // 1リクエスト平均入力トークン
  outputTokensAvg,        // 1リクエスト平均出力トークン
  inputPricePerMTok,      // モデルの入力 $/Mトークン（Sonnet 4.6 = 3.0）
  outputPricePerMTok,     // モデルの出力 $/Mトークン（Sonnet 4.6 = 15.0）
  cacheHitRate = 0.5,     // プロンプトキャッシュのヒット率（実装後）
  safetyFactor = 1.3      // 安全係数（再試行・バースト分）
}) {
  const monthlyRequests = dau * requestsPerUser * 30;
  const monthlyInputTok = monthlyRequests * inputTokensAvg / 1_000_000;
  const monthlyOutputTok = monthlyRequests * outputTokensAvg / 1_000_000;
 
  // キャッシュヒット時は入力料金が10%（書き込み時は125%）
  const effectiveInputCost =
    monthlyInputTok * inputPricePerMTok *
    (cacheHitRate * 0.1 + (1 - cacheHitRate) * 1.0);
 
  const outputCost = monthlyOutputTok * outputPricePerMTok;
 
  return Math.ceil((effectiveInputCost + outputCost) * safetyFactor);
}
 
// 例: DAU 5,000・1人3リクエスト・入力2,000トークン・出力500トークン
// → 月額コスト概算 約 $3,800
console.log(estimateMonthlyCost({
  dau: 5000, requestsPerUser: 3,
  inputTokensAvg: 2000, outputTokensAvg: 500,
  inputPricePerMTok: 3.0, outputPricePerMTok: 15.0
}));

この式の重要な点は、安全係数1.3を必ず掛けることです。実運用では再試行・テスト・社内利用・想定外のバーストが積み重なって、見積もりの1.2〜1.5倍に膨らむのが通常です。最初から「想定の3割増」で予算化しておくと、月末の請求書で慌てません。

本番投入前の最終チェックリスト

3軸の判断が終わったら、以下を「決定済み」と「未決定」で仕分けしてください。未決定が1つでもあれば、本番投入は1週間延ばす価値があります。

[ ] ピーク QPS と月間トークン量の見積もりがある
[ ] 目標 SLA と、それに対応するフォールバック先が決まっている
[ ] PII の扱い方針（マスキング・送信可否）が文書化されている
[ ] 月額コストの概算と、超過時のアラート閾値が設定されている
[ ] レート制限を超えたときのユーザー向けフォールバック表示が決まっている
[ ] 障害時に人間（運用担当）に通知が届く経路がある
[ ] データレジデンシー要件（契約書）と実装が一致している

このチェックリストの「決定済み／未決定」を1枚のドキュメントにまとめて、関係者全員でレビューする会を1時間だけ持つことを強くおすすめします。実装より、この合意形成のほうが本番事故を防ぎます。

次の一歩

この記事を読み終えたら、まず「ピーク QPS の概算」だけを今日中に出してみてください。電卓で5分あれば終わります。その数字が出た瞬間に、Tier 判定・モデル選定・SLA 議論のすべてが動き出します。

Claude API のインフラ設計をさらに深掘りしたい方は、Claude API 本番投入インフラチェックリストで「動くコード」を「本番で持つコード」に変える8つの実装パターンを公開しています。設計判断（この記事）と実装パターン（チェックリスト記事）をセットで読むと、本番投入の手順が一通り揃います。

Claude API に限らず、外部サービスを本番に組み込む全ての設計に通じる視座が得られます。