キャッシュとパージの考え方

中級約10分最終更新 2026-09-08

公開APIの応答は、エンドポイントによってキャッシュしてよいものとダメなものが分かれます。このガイドでは、まずその境界を整理したうえで、CDN・SSGでの具体的なキャッシュ設計、コンテンツ更新時のパージまでをまとめます。

前提：APIキーとサイトコードを取得済みで、クイックスタートのステップ2まで完了していること。

1. キャッシュしてよい応答・ダメな応答

一覧・詳細・マスタ系の応答はキャッシュしてかまいません。一方で、その場限りの状態やトークンを含む応答はキャッシュしてはいけません。

応答キャッシュ

posts.list / posts.get キャッシュ可

faqs.list キャッシュ可

contents.get キャッシュ可

postTypes.list / posts.categories キャッシュ可

forms.get 不可（毎回 speed_check_token を発行するため）

maintenance.get 不可（状態を即時反映する必要があるため）

posts.getPreview 不可（下書きのプレビューのため）

キャッシュ禁止の3つ：forms.get()（毎回 speed_check_token を発行）、maintenance.get()（状態を即時反映）、posts.getPreview()（下書き）は、そのままレスポンスをキャッシュしないでください。

キャッシュの置き場所は構成によって変わります。

SSG（推奨）：ビルド時に公開APIを呼び、結果を静的HTMLへ焼き込みます。実行時にAPIを呼ばないため、キャッシュ設計そのものが不要で最速です（Astroで作るガイド参照）。
SSRの前段にCDNを置く場合：一覧・詳細のレスポンスにCache-ControlでTTLを設定し、CDN側でキャッシュします。更新が反映されるまでの遅延はTTLの長さに依存するため、次節のパージと組み合わせます。
APIキーはサーバー側だけで保持：キャッシュをどこに置く構成でも、X-API-KEYはサーバーサイドのコードでのみ扱い、ブラウザに渡したりキャッシュキーに含めたりしないでください。

TTLだけに頼ると更新が反映されるまでに時間がかかります。「サイト設定 › 外部連携」で受け取れるイベントを契機に、該当パスのCDNキャッシュをパージするか、SSGなら再ビルドをトリガーします。

例：post.published を受け取ったら、一覧ページ /news と詳細ページ /news/{slug} の両方をパージします。
SSGの場合：パージではなく再ビルドそのものが更新を反映する手段になります。設定方法はWebhook / GitHub Actions でビルドを起動を参照してください。

FEEDBACK

改善要望・不具合・ドキュメントの分かりにくい点など、お気軽にお寄せください。いただいた内容は今後の改善に役立てます。