Claude APIのキャッシュ課金における3つの核心メカニズムをマスター:5分 vs 1時間キャッシュ書き込み価格比較とアカウント間キャッシュ分離の詳細解説

作者注:Claude APIのキャッシュ課金メカニズムを深く解析し、5分キャッシュと1時間キャッシュの書き込み価格差を比較、アカウント間でのキャッシュヒット問題を解説し、AWS BedrockとAnthropic公式APIのキャッシュ課金の違いを比較します。

Claude APIのPrompt CachingはAPI呼び出しコストを削減する核心的な手段ですが、多くの開発者がキャッシュ課金の詳細について疑問を持っています:5分キャッシュと1時間キャッシュは結局どちらを選ぶべき?アカウント間でキャッシュを共有できる?AWS Bedrockのキャッシュ課金は公式とどう違う?

核心的価値:この記事を読み終えると、Claude APIキャッシュ課金の3大核心メカニズムを完全に理解し、最適なキャッシュ戦略の選択方法を掌握し、不要なコストの浪費を避けることができます。

claude-api-prompt-caching-pricing-5min-1hour-aws-bedrock-guide-ja 图示


Claude API キャッシュ課金の核心ポイント

ポイント 説明 価値
5分キャッシュ書き込み 書き込み費用 = 基本入力価格 × 1.25 コスト最低、高頻度呼び出しに適す
1時間キャッシュ書き込み 書き込み費用 = 基本入力価格 × 2.0 TTLが長い、低頻度だが大量キャッシュに適す
キャッシュ読み取り(ヒット) 読み取り費用 = 基本入力価格 × 0.1 ヒット後コスト90%削減
キャッシュ分離 Workspaceレベルで分離、異なる組織は完全に分離 アカウント間でキャッシュを共有不可

Claude キャッシュ課金の基本倍率

Claude APIのPrompt Cachingは統一された倍率課金体系を採用しており、どのモデル(Opus 4.6、Sonnet 4.6、Haiku 4.5)を使用しても、キャッシュ操作の倍率ルールは完全に一致します:

  • キャッシュ書き込み(5分 TTL):基本入力価格 × 1.25
  • キャッシュ書き込み(1時間 TTL):基本入力価格 × 2.0
  • キャッシュ読み取り(ヒット):基本入力価格 × 0.1

これは、キャッシュがヒットするたびに、標準入力価格の10%のみを支払うことを意味します。Claude Sonnet 4.6を例にすると、標準入力価格は$3/MTokで、キャッシュヒット価格はわずか$0.3/MTokとなり、入力コストを90%節約できます。

Claude キャッシュ課金の元本回収計算

キャッシュのコストメリットを理解することは非常に重要です。キャッシュ書き込みには追加費用がかかりますが、キャッシュ読み取りは非常に安価で、鍵となるのは——キャッシュが何回ヒットしたら「元本回収」が始まるか?ということです。

  • 5分キャッシュ:書き込み1.25x + 読み取り0.1x = 初回書き込み後、1回ヒットすれば元本回収(通常読み取りは1x、キャッシュ読み取りは0.1xなので、0.9x節約 > 追加支払いの0.25x)
  • 1時間キャッシュ:書き込み2.0x + 読み取り0.1x = 初回書き込み後、2回ヒットして初めて元本回収(追加支払い1.0x、毎回のヒットで0.9x節約)

したがって、5分キャッシュはほぼ「確実に利益が出る」選択肢であり、1時間キャッシュは有効期間内に少なくとも2回ヒットすることを保証する必要があります。


Claude キャッシュ課金:5分 vs 1時間キャッシュ比較

claude-api-prompt-caching-pricing-5min-1hour-aws-bedrock-guide-ja 图示

5分キャッシュ vs 1時間キャッシュの価格差

以下に各モデルを例として、5分と1時間キャッシュの書き込みの具体的な価格をリストします:

モデル 基本入力価格 5分キャッシュ書き込み (×1.25) 1時間キャッシュ書き込み (×2.0) キャッシュ読み取り (×0.1)
Claude Opus 4.6 $5.00/MTok $6.25/MTok $10.00/MTok $0.50/MTok
Claude Sonnet 4.6 $3.00/MTok $3.75/MTok $6.00/MTok $0.30/MTok
Claude Haiku 4.5 $1.00/MTok $1.25/MTok $2.00/MTok $0.10/MTok

Claude キャッシュ課金の TTL 選択戦略

5分キャッシュと1時間キャッシュは二者択一の関係ではありません。実際のシナリオに応じて柔軟に選択でき、同じリクエスト内で混合使用することも可能です。

5分キャッシュが適したシナリオ

  • 高頻度のAPI呼び出し(毎分複数回のリクエスト)、キャッシュが5分以内に継続的に更新される
  • 対話型ダイアログシナリオ、ユーザーが継続的にメッセージを送信し、キャッシュが自動的に延長される
  • コストに敏感なプロジェクト、書き込み費用がより低い

1時間キャッシュが適したシナリオ

  • バッチ処理タスク、一連のデータが数十分間隔で実行される可能性がある
  • 大規模なシステムプロンプト、書き込みコストが高く、キャッシュを長く保持したい
  • スケジュールタスクシナリオ、15-30分ごとに実行される

重要な仕組み:5分キャッシュは、ヒットするたびにTTLが自動的に更新され、「延長」されます。したがって、呼び出し頻度が十分に高い場合(5分以内に少なくとも1回のリクエスト)、キャッシュは実際には常に存続し、1時間キャッシュを選択する必要はありません。

🎯 技術的なアドバイス:ほとんどのシナリオでは5分キャッシュで十分です。APIYI apiyi.com プラットフォームを通じてClaude APIを呼び出す際、キャッシュ課金ルールは公式と完全に一致し、複数のモデルのキャッシュ戦略を統一インターフェースで管理できます。

Claude キャッシュ課金における混合 TTL の使用

Anthropicは、同じリクエスト内で1時間と5分の両方のキャッシュ制御を同時に使用することを許可していますが、重要な制約があります:

TTLは長いものから短いものへ順に並べる:1時間キャッシュマーカーは、5分キャッシュマーカーの前に表示されなければなりません。

実際のアプリケーションでは、変化頻度の低いシステムプロンプトを1時間キャッシュに設定し、変化頻度がやや高いFew-shotの例を5分キャッシュに設定できます:

import anthropic

client = anthropic.Anthropic(
    api_key="YOUR_API_KEY",
    base_url="https://vip.apiyi.com"  # APIYI経由で呼び出し
)

response = client.messages.create(
    model="claude-sonnet-4-6-20260320",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "あなたはプロの技術文書アシスタントです...(大量のシステムプロンプト)...",
            "cache_control": {"type": "ephemeral", "ttl": "3600"}  # 1時間キャッシュ
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "以下は参考ドキュメントです...(大量のコンテキスト)...",
                    "cache_control": {"type": "ephemeral"}  # デフォルト5分キャッシュ
                },
                {
                    "type": "text",
                    "text": "上記のドキュメントに基づいて回答してください:Prompt Cachingとは何ですか?"
                }
            ]
        }
    ]
)

キャッシュヒットステータス確認コードを表示
import anthropic

client = anthropic.Anthropic(
    api_key="YOUR_API_KEY",
    base_url="https://vip.apiyi.com"
)

response = client.messages.create(
    model="claude-sonnet-4-6-20260320",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "あなたのシステムプロンプト内容(キャッシュをトリガーするには >= 1024 tokensが必要)",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": "こんにちは"}]
)

# キャッシュ使用状況を確認
usage = response.usage
print(f"入力 tokens: {usage.input_tokens}")
print(f"キャッシュ書き込み tokens: {usage.cache_creation_input_tokens}")
print(f"キャッシュヒット tokens: {usage.cache_read_input_tokens}")

# キャッシュステータスを判断
if usage.cache_read_input_tokens > 0:
    print("キャッシュヒット!入力コストの90%を節約")
elif usage.cache_creation_input_tokens > 0:
    print("初回キャッシュ書き込み、以降のリクエストでキャッシュヒットします")

💡 注意:キャッシュには最小トークン数の要件があります。Claude Opus 4.6 は少なくとも1024トークン、Sonnet 4.6 と Haiku 4.5 も少なくとも1024トークンが必要です。この閾値を下回る内容はキャッシュされません。


Claude キャッシュ課金:アカウント間キャッシュ分離メカニズム

多くの開発者が最も気になる疑問:A アカウントが書き込んだキャッシュは、B アカウントでヒットするのか?

Claude キャッシュ分離の基本ルール

答えは明確です:できません。 キャッシュは異なる組織(Organization)間で完全に分離されています。

2026年2月5日以降、Anthropicはキャッシュ分離の粒度を「組織レベル」からさらに細かい「Workspace レベル」に変更しました。これはつまり:

シナリオ キャッシュ共有可否 説明
同一 Workspace 内の異なる API Key ✅ 共有可能 同一ワークスペース内では、同じプロンプトでキャッシュヒット
同一 Organization 内の異なる Workspace ❌ 共有不可 同じ組織内でも、異なるワークスペースは分離
異なる Organization のアカウント ❌ 完全に共有不可 完全独立、プロンプトが100%同じでも
APIYIなどのAPI中継サービスを経由する異なるユーザー ❌ 共有不可 異なるユーザーのリクエストは異なるアップストリーム認証情報にルーティング

Claude キャッシュ分離の実際の影響

シナリオ分析:2つのClaude APIアカウント(異なるOrganizationに所属)があり、同時にデータ処理タスクを実行しているとします。

  • アカウントAがリクエストを送信、キャッシュ書き込みが発生、1.25倍の書き込み費用を支払う
  • アカウントBが5分後に全く同じプロンプトを送信
  • 結果:アカウントBはアカウントAのキャッシュをヒットせず、Bもキャッシュ書き込みが発生、再び1.25倍を支払う

これはセキュリティとプライバシーを考慮した設計です——キャッシュ内容には機密性の高いSystem Promptやビジネスデータが含まれる可能性があり、組織間での共有はデータ漏洩リスクを伴います。

claude-api-prompt-caching-pricing-5min-1hour-aws-bedrock-guide-ja 图示

最適化戦略:複数のサービスでキャッシュを共有してコスト削減したい場合は、異なるOrganizationアカウントを使用するのではなく、それらのAPI Keyを同じWorkspace下に配置すべきです。

🎯 実践アドバイス:APIYI apiyi.com プラットフォームでは、各ユーザーのリクエストは統一されたアップストリームチャネルで処理されます。複数のプロジェクト間でキャッシュを共有する必要がある場合は、Anthropic Console でWorkspace構造を適切に計画し、キャッシュ共有が必要なプロジェクトを同じWorkspace内に配置することをお勧めします。

Claude キャッシュヒットの条件

Workspace分離以外に、キャッシュヒットにはもう一つの重要な条件があります——プロンプトが100%完全に同じであることです。

キャッシュキー(Cache Key)は、プロンプト内容を暗号化ハッシュ化して生成されます。マッチング範囲には以下が含まれます:

  • tools(ツール定義)
  • system(システムプロンプト)
  • messages(メッセージ履歴)

上記3つの部分を順番に連結し、cache_controlマーク位置までが対象です。1文字でも異なれば(スペースや改行文字を含む)、キャッシュはヒットしません。


Claude キャッシュ課金:AWS Bedrock vs Anthropic 公式比較

AWS Bedrock と Anthropic API のキャッシュ課金の違い

多くの企業が AWS Bedrock を通じて Claude を利用していますが、そのキャッシュ課金は Anthropic 公式 API と以下のような違いがあります:

比較項目 Anthropic 公式 API AWS Bedrock
5分キャッシュ書き込み 基本価格の 1.25倍 基本価格の 1.25倍
1時間キャッシュ書き込み 基本価格の 2.0倍 基本価格の 2.0倍(一部モデルのみ)
キャッシュ読み取り 基本価格の 0.1倍 基本価格の 0.1倍
1時間キャッシュ対応モデル キャッシュ対応全モデル Haiku 4.5、Sonnet 4.5、Opus 4.5 のみ
キャッシュ分離レベル Workspace レベル Organization(AWS Account)レベル
地域別価格設定 グローバル統一価格 リージョンエンドポイントで約10%プレミアム
基本入力価格 公式標準価格 公式とほぼ同等

AWS Bedrock Claude キャッシュ課金の主な違い

違い1:1時間キャッシュのモデル対応範囲

2026年1月現在、AWS Bedrock では Claude Haiku 4.5、Sonnet 4.5、Opus 4.5 のみが1時間キャッシュ TTL に対応しています。最新の Opus 4.6 や Sonnet 4.6 は、Bedrock 上ではまだ1時間キャッシュオプションをサポートしていない可能性があります。最新モデルと1時間キャッシュの組み合わせが必要な場合は、Anthropic 公式 API を直接使用することをお勧めします。

違い2:キャッシュ分離の粒度

AWS Bedrock は Organization レベル(つまり AWS Account レベル)のキャッシュ分離を維持していますが、Anthropic 公式 API はすでに Workspace レベルまで細分化されています。これは、Bedrock 上では同じ AWS アカウント内のすべての呼び出しがキャッシュを共有できることを意味し、公式 API よりも粒度が粗くなります。

違い3:地域別価格の違い

AWS Bedrock のリージョンエンドポイント(例:us-east-1eu-west-1)は、グローバルエンドポイントよりも約10%の価格プレミアムが発生する場合があります。このプレミアムは、キャッシュ書き込みと読み取りの費用にも反映されます。

💰 コスト最適化の提案:主に Claude API を使用し、キャッシュ戦略を細かく制御する必要がある場合は、APIYI apiyi.com を通じて Anthropic ネイティブ API を呼び出すことがより柔軟な選択肢です。当プラットフォームは完全なキャッシュ制御パラメータの受け渡しをサポートし、よりお得な価格を提供しています。


よくある質問

Q1:5分キャッシュと1時間キャッシュは自分で選択できますか?

はい、選択できます。リクエスト内で cache_control パラメータを設定することで制御できます。TTL を指定しないデフォルトは5分キャッシュで、明示的に "ttl": "3600" を設定すると1時間キャッシュになります。同じリクエスト内で両方のTTLを混在させることも可能ですが、1時間キャッシュの内容が5分キャッシュの前に配置されている必要があります。ほとんどのシナリオでは、5分キャッシュ+自動更新で十分であり、追加費用をかけて1時間キャッシュを選択する必要はありません。

Q2:2つの異なる Claude API アカウントでキャッシュヒットを共有できますか?

いいえ、できません。キャッシュは Workspace レベルで分離されています(2026年2月以降)。2つのアカウントが異なる Organization に属している場合、キャッシュは完全に独立しています。同じ Organization 内の異なる Workspace に属している場合も、共有できません。同じ Workspace 内で異なる API キーを使用した場合のみ、同じプロンプトが同じキャッシュをヒットできます。キャッシュを共有してコストを削減したい場合は、複数の API キーを同じ Workspace 内に配置する必要があります。

Q3:キャッシュがヒットしたかどうかを判断するには?

API レスポンスの usage フィールドには、cache_creation_input_tokenscache_read_input_tokens の2つの指標が含まれます。cache_read_input_tokens > 0 の場合、キャッシュがヒットしたことを意味します。APIYI apiyi.com プラットフォームを通じて呼び出す場合、これらのフィールドはそのまま返されるため、キャッシュヒット率を直接監視してコストを最適化できます。

Q4:キャッシュ内容に最小トークン数の要件はありますか?

はい、あります。すべての Claude モデルのキャッシュ最小閾値は 1024 トークンです。System Prompt やコンテキストの内容が 1024 トークンに満たない場合、キャッシュは有効になりません。大規模なシステムプロンプト、Few-shot 例、または参照ドキュメントをキャッシュ内容として活用し、キャッシュメカニズムを最大限に活用してコストを削減することをお勧めします。


まとめ

Claude APIのキャッシュ課金の核心ポイント:

  1. 5分キャッシュ書き込み1.25倍、1時間書き込み2.0倍:ほとんどのシナリオでは5分キャッシュを選択すれば十分。高頻度呼び出し時はキャッシュが自動更新され、長期間キャッシュと同等の効果
  2. キャッシュ読み取りはわずか0.1倍:キャッシュヒット後は入力コストを90%削減。5分キャッシュは1回ヒットで元が取れる
  3. キャッシュはWorkspaceレベルで分離:異なる組織、異なるWorkspace間ではキャッシュを共有できず、Workspace構造の適切な計画が必要

Claude APIを大量に呼び出す必要がある開発者にとって、適切なキャッシュ戦略の使用はコストを大幅に削減できます。APIYI apiyi.comプラットフォームでのClaude API呼び出しをお勧めします。完全なキャッシュパラメータの受け渡し、統一されたインターフェース管理をサポートし、キャッシュ戦略の効果を検証するための無料テストクレジットを提供しています。


参考資料

  1. Anthropic Prompt Caching 公式ドキュメント:Claude APIキャッシュ機能の完全な説明

    • リンク:platform.claude.com/docs/en/build-with-claude/prompt-caching
    • 説明:キャッシュ価格倍率、TTL設定、最小トークン要件などの核心パラメータを含む
  2. Anthropic API 価格設定ページ:すべてのClaudeモデルの最新価格

    • リンク:platform.claude.com/docs/en/about-claude/pricing
    • 説明:基本入力/出力価格およびキャッシュ操作の詳細な価格設定を含む
  3. AWS Bedrock Prompt Caching ドキュメント:AWSプラットフォームでのClaudeキャッシュ使用ガイド

    • リンク:docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
    • 説明:Bedrock特有のキャッシュ設定方法とサポートモデル一覧
  4. AWS Bedrock 1時間キャッシュ発表:1時間キャッシュTTL機能リリース説明

    • リンク:aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-one-hour-duration-prompt-caching/
    • 説明:Bedrockで1時間キャッシュをサポートするモデル範囲と使用方法

著者:APIYI 技術チーム
技術交流:Claudeキャッシュ課金に関する質問はコメント欄でご議論ください。その他のAPI使用テクニックはAPIYI docs.apiyi.com ドキュメントセンターをご覧ください

コメントする