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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

対象環境: @infra.md

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

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

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

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

これは記事内のサンプル表です。実際の比較は、自分の環境とトラフィック特性をもとに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の各層で目的も無効化方針も違うので、層を固定してから観点を絞ります。

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

依頼文では、層を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に案出しさせます。よくある最低セットは次の通りです。

「ビジネス指標」は技術指標だけ見ていると見落としますが、最終的に事故を判定するのはこちらです。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 *)"
    ]
  }
}

書く対象はあなたの環境に合わせます。「本番に触る可能性のあるコマンドは、AIには走らせない」が原則で、デプロイは人間がCI（GitHub Actionsなど）か手元から実行します。AIに任せてよいのは、設計案・PR本文・runbookの草案までです。

権限と人間ゲートの全体像は「AIに任せすぎないためのClaude Code運用ルール」も合わせて参照してください。

やってはいけないこと

デプロイ・キャッシュ相談でAIにやらせると事故るパターンを5つ挙げます。

1. bypassPermissionsで本番触る作業を回す：classifierも効かず、deny設定もすべて飛ぶ。隔離環境専用と公式が明示している
2. DBマイグレーションを「自動ロールバック付きで頼む」と一発で依頼する：多段化と人間レビューを挟まないと、戻せないマイグレーションが本番に出る
3. キャッシュ層を分けずに「キャッシュ最適化して」と頼む：CDNとアプリ内とDBが混ざった抽象論が返る
4. 「最適な戦略を選んで」と決定権を渡す：採用理由が「AIが最適と言ったから」になり、後から事業上の制約を反映できない
5. 本番のシークレットや接続文字列を依頼文に貼る：「Claude Codeに秘密情報を渡さないための実践ルール」の3層防御を必ず通す

これらは「AIの提案が悪い」ではなく、依頼の仕方の問題です。AIに案を出させ、人間が採用するという原則を守ると、ほとんどは避けられます。

デプロイ・キャッシュ相談のチェックリスト

• インフラ・トラフィック・既存キャッシュの3前提をinfra.mdに書いた
• デプロイ戦略は2〜3案で比較表を作らせ、採用判断は人間が下した
• DBマイグレーションは新旧両バージョンで動く設計で多段化した
• キャッシュは層ごとに観点を分けて相談した
• キャッシュ無効化と整合性の許容を、業務要件と突き合わせた
• ロールバック条件・所要時間・戻せないものを文書化した
• 監視指標は技術指標とビジネス指標の両方を選んだ
• 本番に触るコマンドは.claude/settings.jsonのdenyに入れた
• デプロイ実行はCIまたは人間が行い、AIには実行させない

次に読むおすすめ記事：

• 「Claude Codeで大規模開発の設計相談をするときの進め方」：案出しとトレードオフ比較の進め方
• 「障害対応でClaude Codeを使うときの安全な進め方」：本番に触る前の権限とログ整備
• 「AIに任せすぎないためのClaude Code運用ルール」：人間が必ず通る5つのゲート