Article

Claude Codeでデプロイ戦略やキャッシュ設計を相談するときの観点

Claude Codeにデプロイ戦略・キャッシュ設計・ロールバック手順を相談するときの観点を整理します。ブルーグリーン／カナリア／ローリングの比較、キャッシュ層ごとの設計、無効化と整合性、ロールバック条件と監視、本番に触れる前の権限設定までを依頼文テンプレートとあわせて、本番運用設計にAIを使いたい上級者向けに解説します。

This article is not published in this language yet, so the Japanese version is shown instead.

デプロイとキャッシュは、設計を誤ると本番障害につながり、戻すコストも高い領域です。本記事は、Claude Codeにデプロイ戦略とキャッシュ設計を相談するときの観点を整理し、AIに任せてよい部分と人間が必ず確定すべき部分を分けて扱います。

結論：AIには「案出しと比較」、人間が「採用と実行」を持つ

デプロイ・キャッシュ設計をClaude Codeに丸投げすると、教科書的なアーキテクチャ図と一般論が返ってきます。これらは判断材料にはなっても、そのまま本番に適用できる成果物ではありません。

本記事の前提は3つです。

AIは案出しと比較に使う：複数のデプロイ戦略やキャッシュ層の選択肢を、トレードオフ表として出させる
採用判断は人間が持つ：データ整合性・障害時の影響範囲・ロールバック可否は事業判断とつながるので、AIに決めさせない
本番に触る操作はAIに実行させない：相談・計画・PR作成までで止め、デプロイ自体は人間がCIや手動で行う

設計相談の進め方全体は「Claude Codeで大規模開発の設計相談をするときの進め方」、本番に触る前の権限・ログ整備は「障害対応でClaude Codeを使うときの安全な進め方」が土台になります。本記事はデプロイ／キャッシュに特化した観点を扱います。

相談前に揃える3つの前提情報

AIに筋のよい設計を出させるには、相談の前に環境情報を揃えておく必要があります。これがないと、Claude Codeは「クラウドはAWSだと仮定して」のような前置きから始めるので、毎回ぶれます。

最低限、次の3つを依頼文に書きます。

前提	例
インフラとデプロイ環境	AWS ECS／Cloudflare Pages／Vercel／オンプレ Kubernetes など
トラフィックと許容ダウンタイム	1日10万リクエスト／ピーク同時1000／月次メンテ枠あり／無停止必須
既存のキャッシュとデータストア	CDN（Fastly ／Cloudflare）／Redis／Memcached／DBクエリキャッシュ／アプリ内メモリキャッシュ

依頼前に、これらをまとめた短いinfra.mdを用意して@infra.mdで参照させると、毎回貼り直す手間が減ります。書き方は「Claude Codeに伝わるプロンプトの基本構造：目的・制約・完了条件の書き方」の入力ブロックの考え方を流用できます。

デプロイ戦略：3案を比較表で出させる

「無停止デプロイにしたい」だけだと、ブルーグリーン・カナリア・ローリングのどれを選んでも回答が成立してしまいます。比較を依頼するときは、Plan Modeで2〜3案を並べさせ、トレードオフを表にさせます。

依頼文の基本形は次のとおりです。

目的: 本番のデプロイ戦略を決めるための案出し

対象環境: @infra.md

依頼:
ブルーグリーン／カナリア／ローリングの3案について、以下の観点で比較表を作る
- ダウンタイムの有無
- ロールバックの所要時間と方法
- 必要なインフラコスト（待機系の有無など）
- DBマイグレーション中の整合性
- 失敗時の影響範囲（全ユーザー／一部ユーザー）
- 監視で見るべき指標

各案の「向くケース」と「向かないケース」を1〜2行で書く

禁止事項:
- 実装やインフラ設定を変更すること
- 3案以外の方法を勝手に追加すること
- 「最適な案は◯◯です」と断定して採用判断を出すこと

最後の禁止事項は重要です。AIに採用判断を書かせると、その判断は表面的な一般論になりがちで、読み手も「AIがそう言ったから」で流してしまいます。比較表だけ作らせ、採用は人間が決めます。

戦略	ダウンタイム	ロールバック	コスト	向くケース
ブルーグリーン	なし	ルーターを旧環境へ戻すだけ	待機系のぶん高い	切替が頻繁／瞬時の切戻しが必要
カナリア	なし	比率を0%に戻す	中（監視に投資）	段階的に確認したい／ユーザー影響を局所化したい
ローリング	短時間あり/なし	旧バージョン再デプロイ	低い	コスト抑制が優先／無停止要件が緩い

これは記事内のサンプル表です。実際の比較は、自分の環境とトラフィック特性をもとにAIに出させてください。

DBマイグレーションを絡めて検討する

デプロイ戦略を語るうえで、最も事故が出るのがDBスキーマ変更との組み合わせです。「無停止デプロイ」と言っていても、ALTER TABLEで長時間ロックが掛かれば実質止まります。

Claude Codeには次の観点で点検させます。

新旧バージョンが同じスキーマで動けるか（破壊的変更を一発で入れていないか）
マイグレーションの順序設計（add column → deploy → backfill → switch read → drop column のような多段化）
大きなテーブルでのロックとオンラインDDL（pt-online-schema-changeやgh-ostなどの選択肢）
マイグレーション失敗時のロールバック手順（自動ロールバックは原則使わず、forward fixで戻す前提か）

「自動ロールバック」をAIに気軽に提案させない、というのが意外と効きます。本番DBの自動ロールバックは別の障害を呼ぶことが多く、人間の判断を挟むのが原則だからです。

キャッシュ設計：層ごとに分けて相談する

キャッシュは一括で語ると失敗します。CDN・リバースプロキシ・アプリ内・DBの各層で目的も無効化方針も違うので、層を固定してから観点を絞ります。

代表的な層は次のように整理できます。

層	目的	典型的なTTL	無効化の難しさ
CDN（Cloudflare／Fastly／CloudFront）	静的アセット・パブリックなHTMLの配信高速化	数分〜長期	パージAPI／キーで管理
リバースプロキシ／アプリゲートウェイ	認証付き応答・APIレスポンスの短期キャッシュ	数秒〜数分	内部キー設計に依存
アプリ内・分散キャッシュ（Redis／Memcached）	DB負荷の軽減・セッション・計算結果	秒〜時間	鍵設計と書き込み経路に依存
DBクエリキャッシュ・マテビュー	重い集計の高速化	分〜日	再構築コストが高い

依頼文では、層を1つに絞って次のように書きます。

目的: APIレスポンスの分散キャッシュ層（Redis）の設計レビュー

対象:
- @docs/cache-design.md
- @src/cache/

依頼:
以下の観点で問題を Critical / Should / Nit ラベルで指摘する
- 鍵設計（衝突・ユーザー混在・テナント分離）
- TTL妥当性（短すぎ／長すぎの判断基準）
- 書き込み経路（cache-aside／write-through／write-behind）と整合性
- 障害時の挙動（Redisが落ちたとき、原本DBへフォールバックするか）
- 鍵の総量とメモリ上限・eviction戦略
- 機微情報をキャッシュしていないか

禁止事項:
- 実装を変更すること
- 「いい感じに」のような曖昧表現で済ませること

Critical／Should／Nitのラベル分けは、「Claude Codeをコードレビューに使う方法と人間が見るべきポイント」のレビュー観点の出し方をそのまま流用しています。

キャッシュ無効化と整合性

キャッシュの設計で最も事故るのは無効化です。Phil Karltonの有名な格言通り、「コンピュータサイエンスで難しいのはキャッシュ無効化と命名」です。AIに相談するときに必ず固める観点を挙げます。

書き込み経路と無効化の対称性：書き込みパスごとに対応する無効化パスがあるか
ステイル時間の許容：何秒までステイルでよいか（強整合が必要なら、そもそもキャッシュしない判断）
タグ・グループ単位の無効化：複数キーをまとめて落とせるか
無効化失敗時のフォールバック：パージAPIが落ちたときの動作
キャッシュスタンピード対策：同時アクセスでオリジンに殺到する問題への単体ロックや確率的早期更新

整合性が事業要件にぶつかる場面（例：価格・在庫・残高）は、AIに「キャッシュしない」という選択肢も出させます。「全部キャッシュする前提」で詰めると、整合性が壊れた状態に気づきにくくなります。

ロールバック条件と監視指標

「戻せる」かどうかは、デプロイそのものより重要です。Claude Codeには次の観点でロールバック計画を書かせます。

ロールバックを発動する閾値（エラーレート◯%以上が◯分続いたら、p95レイテンシが◯ms以上に張り付いたら、など）
ロールバック手順の所要時間と自動／手動の境界
ロールバックすると戻せないもの（マイグレーション、外部APIに発火済みの副作用、課金、メール送信）
ロールバックが現実に難しいときの代替（フィーチャーフラグOFF、トラフィック比率ゼロ）

「ロールバック手順がデプロイ手順と同じくらい詳細に書かれているか」を、依頼文の完了条件に入れるのが効きます。完了条件の作り方は「Claude Codeの成功率を上げる制約条件と受け入れ条件の作り方」を参照してください。

監視指標についてもAIに案出しさせます。よくある最低セットは次の通りです。

指標	目安
HTTP 5xx率	平常時0.1%以下／閾値超で警報
p95／p99レイテンシ	エンドポイント別／前バージョンとの差
キャッシュヒット率	デプロイ直後にヒット率が暴落しないか
バックエンド負荷	DB CPU・コネクション数・キュー深さ
ビジネス指標	注文数・ログイン成功率など事業に直結する数字

「ビジネス指標」は技術指標だけ見ていると見落としますが、最終的に事故を判定するのはこちらです。AIには技術指標を任せ、ビジネス指標は人間が選びます。

本番に触る前の権限設定

設計の相談はAIに任せても、本番に触る操作はAIに実行させないのが原則です。Claude Codeのpermission modesではautoモードのclassifierが「production deploys and migrations」と「mass deletion on cloud storage」を既定でブロックすると明記されています。これは強力な防波堤ですが、明示的にdenyを仕込んでおく方が安全です。

.claude/settings.jsonのdeny例（「障害対応でClaude Codeを使うときの安全な進め方」で扱った内容をデプロイ視点で拡張したもの）：

{
  "permissions": {
    "defaultMode": "default",
    "deny": [
      "Bash(kubectl apply *production*)",
      "Bash(kubectl delete *)",
      "Bash(helm upgrade *production*)",
      "Bash(terraform apply *)",
      "Bash(aws *)",
      "Bash(gcloud *)",
      "Bash(flyctl deploy *)",
      "Bash(vercel --prod *)",
      "Bash(wrangler deploy *production*)",
      "Bash(redis-cli flushall *)",
      "Bash(redis-cli flushdb *)"
    ]
  }
}