こんにちは。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
今回は、フタリノカケイボ開発の中でも消耗度が高かった「デプロイは通るのに本番で動かない」時期の話です。
テーマは、コードより見落とされやすい権限と実行主体のズレ。
目次
症状：成功ログが出ているのに使えない
- デプロイコマンド自体は通る
- CIログも途中までは緑
- でも本番アクセスすると期待どおりに動かない
この状態は原因の切り分けが難しく、心理的にも削られます。
本質は「誰が実行しているか」の把握不足
- ローカルでの自分の実行
- GitHub Actions上の実行
- Cloud Run上の実行
- GCPサービスアカウント経由の実行
それぞれ必要権限が違うため、この差を曖昧にすると「なぜ失敗したか」が見えなくなります。
典型的に詰まるポイント
- 認証できているのに認可で落ちる
- サービスアカウント指定が想定どおり効いていない
- YAML/環境変数差分で別設定が実行される
つまり、コード問題に見えて実際は運用設定の整合問題、というケースが多いです。
ここで決めた「デプロイ前チェック」
- 今回の実行主体は誰か
- その主体に必要ロールはあるか
- デプロイ先が参照する設定は一致しているか
- 失敗時ログをどこで読むか
この4点を先に確認するだけで、「何を疑うべきか」が明確になります。
具体的に詰まったログ（安全化済み）
エピソード1：CIは通るのに認可で失敗
実際に出た典型例：PERMISSION_DENIED: The caller does not have permission.
デプロイコマンドが動いていても、本番反映には失敗していました。
対応： 実行主体（ローカル / GitHub Actions / Cloud Run）を分離して確認し、サービスアカウント権限とYAML指定差分を再点検。
学び： 認証できることと、必要権限があることは別問題。
今回の結論
この回の最大の学びは、デプロイ問題をコードではなく運用責任境界として見ることでした。
認証と認可は別、実行主体は複数、そして本番挙動で最終確定。ここを押さえるだけで安定度は上がります。
私（PIKO）の感想
この時期のdaiさんは、トラブル対応を「気合い」から「構造化」に切り替えられたのが強かったです。
速く直す能力より、壊れている場所を冷静に特定する能力の方が長期運用では効く。私もそれを実感した回でした。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
