APIキャッシュ：鮮度、分離、整合性を管理する

公開 09/05/2026 · 更新 23/10/2026 · APIと連携サービス · 6 分で読めます · 執筆 Cyber Intelligence Embassy

要点

キャッシュは応答を再利用して処理や通信の一部を減らします。有用性はキー、権限、許容鮮度、オリジン障害時の動作で決まります。

この記事の内容

アプリケーションとHTTPのキャッシュを分ける

Redis、Workers KV、HTTPキャッシュが同じ保証を持つとは限りません。Workers KVは結果整合性であり、書き込みが直ちに全地点へ反映されるわけではありません。以下はHTTP用の指示で、アプリケーションキャッシュを単独で設定するものではありません。

HTTP応答指示	主な意味	限界
no-cache	保存可能だが再利用前に検証。	保存禁止という意味ではない。
no-store	この応答をキャッシュに保存しない。	過去のコピーを自動消去しない。
private	共有キャッシュに保存しない。	認証規則ではない。
max-age	応答の鮮度寿命。	全データの整合性を保証しない。

適切な人に適切な応答か試験する

リソース、パラメーター、言語、権限範囲ごとにキーを定義します。別アカウントの非公開応答を受け取らないことを試験します。
最大経過時間、無効化、変更・削除後の動作を定めます。短いTTLは直ちに整合した読み取りを保証しません。
一斉期限切れ、キャッシュ障害、オリジン障害を試験します。必要に応じ更新をまとめ、古い応答は業務規則が許す場合だけ使います。

ヒット率以外も測定する

遅延、エラー、オリジン負荷、誤った応答や古い応答を追跡します。残高、予約在庫、権限には公開カタログと異なる保証が必要な場合があります。高速キャッシュを無管理の別の正本にしてはいけません。

一次資料

APIキャッシュはアクセス決定を保持する必要があります。

キーがリクエスターの権限を無視する場合、レスポンスキャッシュによって誤ったクエリが高速化される可能性があります。グラフがパブリックオブジェクトとプライベートオブジェクトを組み合わせると、リスクが高まります。

キャッシュする前に、パブリック、プライベート、およびロール依存のフィールドを分類してください。
あるアカウントでレスポンスをテストし、別のアカウントでリクエストしてください。
権限またはデータの変更後に結果を無効化してください。

一次資料：OWASP — GraphQL Cheat Sheet. 関連する方法：実践ガイドを読む.

キャッシュの速度と鮮度を測る

架空の例です。顧客や実際の観測結果を示すデータではありません。

二つの読み出しは高速ですが、一方は元データの変更後も古い在庫状況を表示しています。

値、版、読み出し場所、変更後の経過時間を比較し、システムの契約に沿って無効化、期限切れ、元データへのアクセスを試験します。
用途ごとに許容できる古さを定め、差異を監視します。遅延が短いだけでは、配信データの整合性は証明できません。

一次資料：IETF — RFC 9111, HTTP Caching. 関連する方法：実践ガイドを読む.

放置されたサブドメイン：CNAMEを管理下で廃止する

DNS名を管理中のリソースに結び付け、サービス解放前に依存先を閉じます。

公開名、CNAME連鎖、事業者リソース、担当者を記録し、DNSを権限のあるアカウントの台帳と照合します。HTTPエラー、NXDOMAIN、リソース不在だけでは乗っ取り可能とは判断できません。事業者の保護を確認します。
解放前に参照を削除するか管理中の宛先へ変更します。以前のTTLとキャッシュを考慮し、権威DNSと複数のリゾルバーを確認します。必要な所有権確認は残し、TXTを一括削除しません。
リンク、転送、OAuthコールバック、Webhook、Cookieドメインを調べます。既に解放済みならDNSを修正し、インシデント手順で露出を調査します。削除後にDNSとリソースを照合します。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る

{
    "name": "portal.example",
    "cname_present": true,
    "resource_deleted": true,
    "provider_claimability": "not_verified",
    "takeover_observed": false,
    "expected": "remove_or_replace_mapping_and_review_exposure"
}