deploy-check

name	deploy-check
description	データの欠損・古い値・期待と異なる表示など「データが正しく見えない」系の調査を始めるとき。クライアントコードに潜る前に、まず backend のデプロイ状態と、デプロイ環境側の構成（feature flag / config / 環境差分）を確認させる。ローカルの .env や secrets ファイルは読みに行かない。

Deploy Check

データ不整合系の調査で「いきなりクライアントコードを読み始める」失敗を防ぐためのトリアージ手順。

いつ使うか

以下のような症状を訴えられたとき:

• 期待した値が表示されない / 古い値のままになっている
• API レスポンスに欠けているフィールドがある
• 環境ごとに挙動が違う（staging では出る / prod では出ない 等）
• 直近の変更を取り込んだはずなのに反映されていない

手順

順番を守ること。1 → 2 で原因が特定できる場合が多く、3 まで進む前にクライアント側を疑わない。

1. Backend のデプロイ状態を確認

• 最新コミット (main / 当該リリースブランチ) が実環境にデプロイ済みか
• デプロイパイプラインの直近実行が成功で終わっているか
• ロールバック直後ではないか

2. デプロイ環境側の構成を確認

「デプロイ先の環境がどう構成されているか」を確認するフェーズ。ローカルの設定ファイルを読み込むのではない。

確認対象は以下のような デプロイ先側の情報源 に限る:

• デプロイコンソール / マネージドサービスの env 設定画面に表示されている値（プラットフォーム UI 上で）
• CI / CD ログに出力されている設定の出自・バージョン
• feature flag 管理画面の現在値
• 環境ごとの非機密 config 定義（リポジトリ内のコードとして管理されているもの）

確認すべきこと:

• 期待される値と実環境の設定が一致しているか（値そのものを読ませるのではなく、ユーザーに「期待値 vs 実環境」の差分を確認してもらう）
• feature flag / config が想定の状態か
• 環境ごとの差分が今回の症状を説明し得るか

やってはいけないこと

• ローカルの .env / .env.* / secrets/* / credentials* 等を Read しに行く
• CI ログから API キー・トークン・パスワードを抜き出して文脈に取り込む
• 秘密情報を Claude のコンテキスト・出力・ファイルに混入させる

シークレット値が「正しく注入されているか」を確認したい場合は、値そのものを見るのではなく、「シークレットが set されているか / 期待された名前で参照されているか」だけ をユーザーに尋ねること。

3. ここでようやくクライアントコードを読む

1 / 2 で原因が見つからなかった場合のみ、フロントエンド / SDK / ローカルキャッシュ等の調査に進む。