TL;DR
- 学習目的の個人アプリを Google Cloud で運用していたところ、月額が 1 万円を超えていることに気付きました。
- 緊急対応として DNS 以外の GCP リソースを停止・削除し、以後は Cloudflare を中心に再構築する方針に切り替えました。
- 代替は Cloudflare と Netlify を比較し、Next.js との相性と固定費の低さから Cloudflare を選定しました。
背景（なぜ Google Cloud で始めたか）
ポートフォリオ作成と学習を目的に、インフラから CI/CD、監視まで一通りを触ることを狙って始めた個人開発を行っていました。
採用技術は Google Cloud を中心に、Cloud Run、Artifact Registry、Cloud Scheduler、Logging/Monitoring を Terraform で管理していました。
アプリは Next.js ベースで、将来的な SSR やバッチ実行も見据えていました。
Google Cloud を採用した理由は、今まで触ったことがなかったので学習をきっかけに触ってみたかったのと、ドキュメントを読んでいて機能がシンプルで理解しやすく感じたからです。
何が起きたか（請求が 1 万円超）
ある日、何気なく請求ダッシュボードを確認したところ、当月見込みが 1 万円を超えていました。
個人開発としては継続が重い水準だと判断し、即座にコスト抑制に舵を切りました。
参考までに、JST 2025-11-19 20:35 時点のスナップショットは以下のとおりです。
- 費用: ¥7,833 / コスト削減: ¥713 → 総費用: ¥7,120
- 予想される総費用（当月見込み）: 約 ¥11,400（先月比 +240%）
- 最大節約の見込み: ¥2,189、FinOps スコア: 3.3 / 5.0（Medium）
- 上位プロジェクト: TechSnap Production ＞ TechSnap Staging ＞（未割当の請求）＞ techsnap-mgmt
- 上位サービス: Container Registry/Artifact（脆弱性スキャン）＞ Networking ＞ Cloud Domains ＞ Compute Engine ＞ Cloud Run
緊急対応で実施したこと
- DNS（ドメイン）のみ既存の Cloud DNS を継続利用しました。
- それ以外の GCP リソースは Terraform 管理から外し、Cloud 上の構築物も削除しました。
- 構成を「単一環境・DNS のみ」に縮小し、Cloudflare への移行準備を開始しました。
なぜここまで金額が跳ね上がったのか（推測）
今回は、個人開発で起きがちな「少額の固定費と見落としが積み上がる」パターンが重なったと考えています。
常時起動・アイドル課金の固定費が積み上がっていました。
最小インスタンスの維持やコールドスタート緩和の設定を有効にしていたため、トラフィックが少なくても一定の費用が発生していました。ログとメトリクスの取り込み・保存が過剰でした。
開発中の詳細ログをそのまま取り込み、保持期間の見直しもできていなかったため、Logging/Monitoring の費用がじわじわ増えていました。Artifact Registry にイメージが蓄積していました。
古いイメージの世代管理と自動クリーンアップを設定しておらず、ストレージと脆弱性スキャンのコストが積み上がっていました。スケジューラの定期実行コストが無視できない水準でした。
試験的に動かしていたジョブの頻度とリトライ設定を見直しておらず、実行回数に比例して費用が発生していました。ネットワークの外向き転送料・リージョン間転送料を軽視していました。
外部 API へのアクセスや別リージョンの利用が混在し、想定より Networking の比率が高くなっていました。
これらは一つひとつは小さく見えますが、月次では確実に効いてきます。
特に 「減らしにくい固定費」と「意図せず増える従量費」 を併発したことが跳ね上がりの直接要因でした。
代替案の検討と選定（Cloudflare / Netlify）
どちらも Jamstack と相性が良く、Next.js の対応も充実しています。
個人開発で効いてくるのは「固定費が低いか」「無料枠が広いか」です。
総合的に、Cloudflare は Pages/Workers/KV/R2/Images などの無料枠が広く、DNS やセキュリティとの一体運用も可能なため、今回は Cloudflare を選びました。
一方で、エッジランタイム特有の Node 互換性や SSR 設計の工夫は必要です。Netlify は DX が優秀で導入が容易ですが、超過時の価格階段やロックイン度合いを考慮して見送りました。
今回のリカバリとこれからの方針
実施済みの対応として、DNS 以外の GCP リソースを全量削除し（Terraform 管理からも外し）、Terraform を単一環境・DNS の最小構成に整理しました。
今後は Cloudflare Pages + Functions で Next.js をホスティングし、キャッシュは「HTML 短め・静的アセット長め・API はステータス/ヘッダで制御」という方針に整えます。
必要に応じて KV / D1 / R2 / Images を段階導入し、DNS は順次 Cloudflare へ移管します（TTL 短縮 → ゾーンエクスポート → インポート → 切替）。
今後の構築で注意すること（運用チェックリスト）
- 予算アラートを必ず設定します（月/週のしきい値）。
- ログの保持期間・サンプリング・除外ルールを明文化します。
- アーティファクトとコンテナイメージは世代・期間ルールで自動削除します。
- 定期ジョブは頻度・リトライ・タイムアウトを見直し、棚卸しを定例化します。
- 未使用 API/サービスを止め、不要リソースの検出をタスク化します。
コスト設計の深掘り（考え方）
- 固定費と変動費を分離して設計します。固定費は「削れる上限」を先に見積もり、スケールゼロ（使わない時は 0 円）を最優先にします。
- トラフィック・ジョブ・ログは P50/P95 の二軸で見ます。平均だけでなく高負荷時の天井を見積もることで、超過コストを抑えます。
- ネットワークは最初に予算化します。外向き通信とリージョン間転送料は“あと乗せ”になりやすく、設計初期に上限を決めます。
- 監視・ログは必要最小限から始め、保持期間とサンプリングを段階的に広げます。開発中の詳細ログは短期保持にします。
- アーティファクトは LRU/期間/世代で自動削除します。脆弱性スキャンやマルチリージョン保管のコストも計上します。
- タグ/ラベルを義務化し、プロジェクト・環境・機能でコストを配賦します。誰の費用かが即座に追える状態にします。
- 予算・しきい値は 3 段階（注意・警戒・緊急）で通知します。日次と週次の両方にメトリクスを用意します。
反省点（今回の学び）
- 「固定費が低い構成」への意識が不足していました。最小インスタンスやスキャンの既定値を見直すべきでした。
- ログ・メトリクスの保持と詳細度の管理が甘く、不要な取り込みが続いていました。
- コンテナイメージの世代管理と自動削除を後回しにしており、地味なコストを積み上げました。
- ネットワークとジョブ頻度の影響度合いを初期に見積もらず、増え方の想定が浅かったです。
まとめ
学習目的の個人開発こそ、固定費を抑える設計が重要だと痛感しました。
Cloudflare は「無料枠の広さ × エッジ実行 × DNS/セキュリティ統合」により、個人規模では有力な選択肢になりやすいです。
まずは最小構成から始め、必要に応じて段階的にサービスを足す方針に切り替えることで、開発の楽しさと継続性の両立を目指します。
あとがき（２０２５年１１月２９日現在）
いろいろあって、今回開発しようとしたアプリを断念することにしました。
理由としては、デプロイするごとに KV の無料枠が 90%をすぐに超えてしまい、Google Cloud で失敗してしまったことをまた繰り返しそうになるのを防ぐためです。
反省として、その技術を採用するに辺り事前にしっかり予習することを怠ってしまったため、次回に開発する際は事前のリサーチを怠らずに進めていきたいと思います。