コンテナで本番に寄せたら、ビルドが OOM で笑う（04-30 の泥）

ローカルで動くのに、CI/本番で死ぬタイプのバグは心が折れやすい。daily-snap でも、コンテナとビルドパイプラインに寄せたタイミングで一気に表面化した。CHANGELOG に並ぶコミットが、まさにその旅行記になる。

ざっくり型を挙げる。Next.js の standalone 出力でイメージを作る（e5b7366）。Cloud Build がルートの Dockerfile を期待する（796d5a4）。ビルダーで prisma generate が足りないとランタイムが泣く（adb9111）。Next ビルドが OOM するので Node heap を上げる（72389ec）。ビルド時に ダミー DATABASE_URL を渡して Prisma のデータ収集を通す（11421d5）。Cloud Run の PORT を尊重する（6f40a63）。

個人開発でも、この並びは普通に起きる。しかも原因が複合していると、「Docker が悪いのか Prisma が悪いのか Next が悪いのか」で迷子になる。対策は地味で、再現手順を短くし、ログを分離して見ることだ。

ハマりどころを「型」として抜き出す

CHANGELOG に並んだコミットは、次のような 再現可能な型にまとめ直せる。

| 型 | 典型的なログ・症状 | 手を打つ方向 | | --- | --- | --- | | standalone 不足 | イメージは動くがファイルが足りない、パスエラー | Next の output: 'standalone' と Dockerfile のコピー対象を揃える | | prisma generate 抜け | ランタイムで Prisma Client が見つからない | ビルドステージで generate、成果物をランタイムに持ち込む | | Node heap OOM | JavaScript heap out of memory | NODE_OPTIONS=--max-old-space-size=... やビルドマシンのメモリ | | ビルド時 DATABASE_URL | CI で Prisma が DB に触ろうとしてコケる | ダミー URL で「スキーマ読み取りだけ通す」など、収集フェーズを分離 | | PORT 無視 | Cloud Run が期待するポートで listen しない | ランタイムが渡す PORT をアプリが読む（プラットフォームのドキュメントに合わせる） |

ローカルでの再現順（おすすめ）

1. docker compose（または同等）で 本番に近いビルドステージを走らせる
2. 失敗したら、ビルドログとランタイムログを分けて貼る（混ぜると Prisma と Next のせいにし損ねる）
3. 直したら、キャッシュなしビルドでもう一度（--no-cache 相当）

04-30 は華やかさがない分、将来の自分への短い手順書として残す価値が高い。

この連載の最後にこの話を置いたのは、フロントと AI と PWA が華やかな分、運用の地層がプロダクトの寿命を決めるからだ。snap.yutok.dev が読者にとって「ただの LP」じゃなく、実体として触れるものであるほど、ここが効いてくる。

ポートフォリオ側にも、同系統の記事として Cloud Build の接続トラブル（例: cloud-build-trigger-branch-sync）がある。別プロジェクトでも、“ソース接続が壊れる”系は同じ匂いがする。

個人開発でも「本番の型」は早めに

完全に整える必要はない。でも Dockerfile とビルド制約は、後回しにすると精神をすり減らす。だから mid で入れた。痛みのログが CHANGELOG に残っているのは、未来の自分への投資だと思っている。

小さな結論

本番はローカルの延長線じゃない。だから「動いた」を二回言う。ローカルで一回、コンテナで一回。そこを抜けると、あとが楽。

スクショで残すなら

docker compose ps 相当、Cloud Build のビルド履歴、Cloud Run のリビジョン画面、OOM だったログの抜粋（秘密はマスク）。「苦しみの可視化」は未来の自分への地図になる。

---

daily-snap 開発ログ（完）
前: Open-Meteo とカレンダーキャッシュで…
索引: 04-02 動機 · 04-05 ルーティング · 04-08 DB · 04-10 MAS · 04-11 AI/監査 · 04-14 PWA · 04-15 画像 · 04-17 認証