M.

個人開発の GCP で「やらなかった」コスト削減4つ(e2-small・東京リージョン・Nearline・Standard ティアの保留)

GCP の費用を見直すとき、「これをやれば安くなる」という定番の施策がいくつかあります。実際に検討してみると、自分の環境では見送った方がいいもの もいくつかありました。

やったことより、やらなかったことの方が他の人の判断材料になると思うので、その理由をまとめておきます。

前提:個人開発の GCP プロジェクトが5つほど。WordPress を動かす VM(e2-medium / us-central1)と、画像生成アプリの Cloud Run(GPU)が費用の大半です。

1. VM を e2-small にダウングレードする → 見送り

WordPress を動かしている VM は e2-medium(メモリ 4GB)です。e2-small(メモリ 2GB)にすれば、VM の料金はおよそ半分になります。

これは 過去に失敗した実績があるので見送り ました。以前メモリ 2GB で運用していたとき、WordPress で画像をアップロードすると処理が失敗することがありました。画像のリサイズやサムネイル生成でメモリを使うためです。

数百円を節約するために、記事を書くときに毎回ストレスを感じるのは割に合いません。メモリが多めで安いマシンタイプが新しく出たら、そのときに考え直すことにしました。

2. 東京・大阪リージョンに移す → 見送り

利用者は日本にいるので、VM を東京(asia-northeast1)や大阪に移せば応答も速くなりそうです。

ただ、Cloud Billing の SKU の単価を比べると、東京は us-central1 より約28%高い ことが分かりました。同じ構成でも、場所を変えるだけで3割近く高くなります。

このサイトは手前に Cloudflare があり、ページはほとんど Cloudflare のキャッシュから返されます。VM の場所が利用者から遠くても体感への影響は小さいので、料金の安い us-central1 のままにしました。

なお、us-central1・us-west1・us-east1 の e2-micro には常時無料枠があります。小さいサービスなら、米国リージョンの方がさらに有利です。

3. モデル置き場のバケットを Nearline にする → 見送り

画像生成モデルを置いている Cloud Storage のバケットは、Standard クラスです。Nearline にすれば、保存料金は半分くらいになります。

ただし Nearline は、データを読み出すたびに取得料金がかかり、最低保存期間(30日)もあります。月1回も読まないようなバックアップ向けのクラスです。

このバケットのモデルは、GPU での推論に使うために繰り返し読み出します。読み出しが頻繁なので、Nearline にすると取得料金で逆に高くなります。頻繁に読むデータは Standard のままが正解 でした。

4. Standard ティアへの切り替え → いったん保留(後で実施)

VM の外向き通信を Premium ティアから Standard ティアに切り替えると、月200GiBまでの無料枠が使えます。

最初の見直しでは、外部 IP アドレスが変わって DNS の書き換えが必要になる ことから保留にしました。その後、外向き通信の内訳を詳しく調べて、削減額(月 ¥600〜700ほど)がはっきりしたので、2回目の見直しで実施しています。

詳しくは GCP の請求で Networking は ¥0 なのに、VM の通信料がかかっていた に書きました。

確認して「問題なし」だったもの

「他にも削れるところはないか」と一通り確認して、費用が発生していなかった項目です。チェックリストとしてどうぞ。

項目確認結果
静的外部 IPどのプロジェクトでも予約なし(未使用の静的 IP は課金される)
Cloud SQL / Memorystore未使用(API 自体が無効)
Cloud NAT / VPN / Interconnect未使用
Cloud Scheduler未使用
Cloud Logging の取り込み量全プロジェクト合計で月63MB程度。無料枠(50GiB)の0.1%で課金なし
予算アラート全体・プロジェクト別ともに設定済み
Cloudflare のキャッシュSmart Tiered Cache が有効、画像は1年キャッシュでヒットしている

費用が発生しているサービスを見るだけでなく、「よく課金の原因になるもの」を一通り潰しておく と安心できます。特に、使わなくなった静的 IP や停止中の VM のディスクは、忘れた頃に請求が来がちです。

見送るときに考えたこと

見送った判断を振り返ると、基準は次の2つでした。

  • 過去にトラブルがあった設定には戻さない:数百円の節約より、運用中にまたトラブルが起きるリスクの方が高くつく。
  • 単価ではなく使い方で比べる:Nearline も東京リージョンも、カタログ上の単価だけを見ると判断を誤る。読み出し頻度や、Cloudflare を挟んでいるかどうかで結論が変わる。

GCP の費用見直し全体の流れは、Claude Code に GCP の課金を棚卸しさせたら、月1万円が半分になった にまとめています。

この記事をシェア

「GCP」の記事(7件)

  1. GCS の画像を Cloudflare Worker で中継してエッジにキャッシュする(バケット名を変えずに独自ドメインで配る)
  2. Artifact Registry が86GBに膨らんだ(「30日より古いものを削除」が効かない理由とクリーンアップポリシー)
  3. Claude Code に GCP の課金を棚卸しさせたら、月1万円が半分になった(失敗込みの記録)
  4. GCP の予算アラートで Cloud Run の GPU だけを自動停止する(maxInstanceCount: 0 では止まらなかった)
  5. ▶ 個人開発の GCP で「やらなかった」コスト削減4つ(e2-small・東京リージョン・Nearline・Standard ティアの保留)
  6. GCP の確約利用割引(CUD)を二重に買ってしまい、サポートに取り消してもらった話
  7. GCP の請求で Networking は ¥0 なのに、VM の通信料がかかっていた(404 の gzip 化と Standard ティア)

関連する記事

AI コード進行アプリを2年運用して分かったこと(GPT-4o から Claude へ、2024→2026)

キーワードからコード進行を作る Web アプリ Chord Eureka を、2024年12月の公開から2年近く運用してきました。GPT-4o 時代のコストと出力崩れへの対処、Claude への移行、temperature 廃止で本番が落ちた件、構造化出力、測ってから決めたモデル更新までを、git の履歴をもとに振り返ります。

claude -p を評価器にして、AI の生成結果を930件自動採点した

コード進行アプリのキーワードボタンが本当に効いているのかを確かめるため、Claude Code の `claude -p` で930件を生成し、プログラムで採点しました。API キーを使わない生成のしかた、本番に近づけるためのオプション、Windows での落とし穴、AI に採点させない集計の考え方をまとめます。

Claude に「敵対的レビュー」をさせて、指摘がどれくらい当たっていたかを数えた

個人開発では、Claude Code に「壊れるところを探して」と頼む敵対的レビューを何度も使っています。4つのリポジトリに残っていた再検証の記録から、指摘がどれくらい当たり、どう外れていたかを数えました。外れ方には決まった型がありました。

Claude Code 向けのドキュメントは3つに分ける(CLAUDE.md はルール、README はセットアップ、PROGRESS.md は次にやること)

Claude Code に任せて開発していると、CLAUDE.md・README・PROGRESS.md が同じ説明で膨らんでいきます。個人開発のリポジトリで役割を分け直したら、CLAUDE.md は117行から50行、README は172行から35行になりました。分け方と、書かないことにしたものをまとめます。

テーマから探す