Google Cloud 18万円の請求から学んだこと

Google Cloud 18万円の請求から学んだこと── 課金の3分類と、Claude が絶対に従うルール「hook」

こんにちは、だいきです。

前回の記事では、個人でGoogle Cloudを持つと、だいたい何でも作れるという話を書きました。妻のITパスポート勉強用のLINEボットを例に、Cloud Run や BigQuery や Gemini が、個人の契約の中で全部使えますよ、と。

今日はその続きで、危ないほうの話です。

先に、自分の失敗から

便利さだけ書いて終わるのはフェアではないので、先に自分の恥を出します。

私は不注意で、18万円の請求を受け取ったことがあります。

内訳はシンプルで、1日6,000円の Cloud SQL を、30日間動かしっぱなしにしていました。

経緯を正確に書きます。勝手に課金が始まったわけではありません。全部、私の操作が原因です。

1. 最初の1ヶ月は、無料枠で Cloud SQL を動かしていました

2. 無料の期間が終わるタイミングで、そのデータベースが一旦停止しました

3. 焦った私が、マシンのスペックもろくに確認せずに、再起動しました

4. そのとき立ったのが、1日6,000円かかる構成でした

5. そのまま30日が経ちました

つまり、止まってくれていたものを、自分で起こし直したわけです。しかも何を起こしたのかを確認しないまま。

いま振り返ると、2番の「一旦停止した」はむしろ良くできた挙動でした。あそこで止まっていなければ、気づくきっかけすらなかったかもしれません。止まった時点で落ち着いて中身を見ていれば、それで終わっていた話です。

痛い勉強代でした。あの頃 Claude Code がいてくれれば、と本気で思います。

Google Cloud の課金は、だいたい3種類

同じ目に遭ってほしくないので、仕組みの整理をしておきます。GCPの料金は、何を数えて課金されるかで3つに分けて考えると見通しが良くなります。

1. 時間で課金されるもの

動かしている間、ずっと課金されます。使っていなくてもです。

代表は Cloud SQL のような、書き込みに強いテーブル型のデータベースです。この手のデータベースは「常に待機していて、いつ書き込みが来ても受け付けられる」ことに価値があるので、立てた瞬間から、止めるまで課金が続きます。

ここがいちばん危ないです。誰も使っていない深夜も、あなたが忘れている間も、メーターは回り続けます。私の18万円はこれでした。

2. 処理で課金されるもの

動かしたときだけ、動かした分だけ課金されます。

• Cloud Run ── プログラムを実行した分

• BigQuery の集計 ── クエリが読んだデータ量に応じて

• Vertex AI（Gemini） ── AIを呼び出した回数と量に応じて

こちらは使わなければ0円なので、時間課金よりは安心です。ただし裏返すと、動けば動くだけ増えます。

3. 容量で課金されるもの

置いてあるデータの量に応じて課金されます。

Cloud Storage や、BigQuery のデータ保存の部分がこれです。

容量課金は、3つの中でいちばん安心です。ファイルを置いた分しか増えませんし、昨日までと同じ使い方をしていて、今日だけ跳ね上がるということが起きません。じわじわ増えることはあっても、不意打ちは来ない。

うっかりの実例

私がやらかした、あるいは「危なかった」のはこのあたりです。

時間課金の見落とし ── さっきの18万円です。何を立てたのかを確認しないまま動かし続ける、という形で来ます。立てた瞬間ではなく、30日後に効いてくるのが厄介なところです。

処理課金の積み上がり ── Gemini の画像生成を、気持ちよく回しすぎたことがあります。1枚ずつは大したことがなくても、試行錯誤で何十枚も作ると、それなりの額になります。

裏側で回り続ける処理 ── ダッシュボードを作ったとき、画面を開くたびに裏で大量の集計が走っていたことがありました。見た目は同じグラフでも、裏で毎回データを読み直していれば、読んだ分だけ課金されます。これは画面を見ているだけでは分かりません。

どれも「気をつけていれば防げた」ものです。 そして、気をつけるという対策は続きません。だから仕組みにしたい。

Claude が絶対に従うルール「hook」

ここで一つ、知っておくと安心な機能を紹介します。

Claude のアプリ側には、Claude（エージェント）が絶対に従うルールを設定できます。 これを hook（フック） と呼びます。

いくつか種類があるのですが、何かコードを実行する前に発動するルールが PreToolUse の hook です。私の設定はこうなっています。

危険なもの、として挙げているのは4種類です。消す／権限をいじる／お金まわりを変える／外に公開する。前編で書いたとおり、Claude がクラウドを操作する手段は gcloud などのコマンドですから、コマンドの中身さえ見ておけば、危ない操作はここで全部つかまえられます。

そして大事なのは、これを Claude（エージェント）は無視できないということです。

私がどんなに「今日は信頼しているから全部任せる」という設定にしていても、このルールは別枠で効きます。Claude 自身が「これは安全だと判断しました」と思っていても関係ありません。アプリ側で止まります。

これは安心ですね。 自分の注意力ではなく、自分の判断の外側にあるもので守られている状態になります。

実際に止まると、どうなるか

Claude が危ないコマンドを打とうとした瞬間、実行される前に止まります。こんな画面になります。

データベースを消すコマンドが、実行される手前で止まっています。そして Claude には、止めた理由と、次に何をすべきかが返ります。

ここがよくできているところで、ただ止めるだけでなく、「人間に分かる言葉で説明してから聞け」まで書けるんです。私はセキュリティに詳しくないので、「このコマンドは何をするものなのか」を噛み砕いて説明してもらえないと判断できません。判断できる状態にしてから聞いてくるように仕込んであります。

どうやって設定するのか

設定は2つだけです。

1つめ、チェックする中身を書いたファイルを1つ置きます。私のは80行ほどのシェルスクリプトで、「コマンドの文字列に `delete` が入っていたら止める」といった判定が並んでいるだけです。これも Claude に書いてもらいました。

2つめ、設定ファイルに登録します。「ターミナルを使う前に、このファイルを呼んでね」と数行書くだけです。

止めたいときは、スクリプトが deny（拒否） という返事を返します。返事の種類は4つあって、使い分けられます。

• allow ── 許可する

• deny ── 止める（私が使っているのはこれ）

• ask ── 人間に判断を投げる

• defer ── 判断を後回しにする

さらにコマンドを書き換えてから実行させることもできます。「このコマンドが来たら、安全な別のコマンドに差し替える」といった使い方です。

hook は他にもいろいろある

今回使った PreToolUse（実行の前）がいちばん強力ですが、ルールを発動させるタイミングは他にもたくさんあります。実用的なものを挙げると、こんな感じです。

PreToolUse ── 何かを実行する前。止められる。関所。今回使ったもの
PostToolUse ── 実行が成功した後。ファイルを直したら自動で整形する
UserPromptSubmit ── 私が指示を送って、Claude が読む前。毎回必ず伝えたい前提を差し込む
SessionStart ── 作業を始めるとき。最初にやっておくことの実行
Stop ── Claude が応答を終えたとき。完了の通知を飛ばす

「このタイミングで、これを必ずやる（やらせない）」が全部仕込めるということです。

AIエージェントに仕事を任せるうえで、これはかなり重要な使いこなしだと思います。 お願いの仕方（プロンプト）を工夫するのは、相手の善意に期待するやり方です。hook はそもそも実行させない。性質がまったく違います。

ちなみに、この記事を書いている最中に止まりました

ここまで読んで「よくできた仕組みだな」と思われたかもしれないので、正直なところも書いておきます。

この記事の図を作っている最中に、関所が発動しました。

やろうとしていたのは、見出し画像に入れる図のHTMLファイルを1つ作ることだけです。Google Cloud には一切触っていません。ただ、その図の中に「コマンドの例」として `gcloud … delete` という文字を入れていた。それだけで止まりました。

つまり hook は、実行するコマンドなのか、ただの文章なのかを区別していません。 文字列として「gcloud」と「delete」が並んでいるのを見て、機械的に止めただけです。

そしてもう一つ。私は結局、文字の書き方を変えて通しました。 見た目は同じ `delete` ですが、裏の文字コードを変えると hook のチェックには引っかかりません。

この2つは、hook という仕組みの性格をよく表していると思います。

• 文脈は読まないので、関係ないものまで止める（＝安全側に倒れる。悪くない）

• 書き方を変えれば避けられる（＝完璧な封じ込めではない）

だから hook は「これさえあれば安全」というものではありません。うっかりを止めるための装置であって、それ以上ではない。そう理解して使うのが正しいと思います。

そのうえで、Claude に見てもらう

hook が「危ないことをさせない」仕掛けだとすると、もう一つ要るのが「危ない状態になっていないか見る」ほうです。

そこで、費用管理とセキュリティのチェックを、Claude に担当してもらっています。

やり方は、まったく難しくありませんでした。私がやったのは、相談したことだけです。

これを投げて、出てきた案を検討して、整えてもらいました。さっきの hook も、このとき一緒に出てきたものです。

できあがったのは、監査の役を専門に持つエージェントでした。構成や権限や公開設定や費用を、読み取り専用で点検して、報告してくれます。

視点は2つ。

• コスト ── 想定外の課金が始まっていないか。何にいくらかかっているか

• セキュリティ ── 意図せず外に公開されていないか。権限が緩すぎないか

タイミングも2つ。

• 毎週のルーティン ── 費用のチェック。忘れた頃に効かないと意味がないので、定期にしました

• デプロイの前 ── セキュリティのチェック。公開してしまってからでは遅いからです

セキュリティについて正直に書いておくと、私はそこまで詳しくありません。何が危ないのか、どこを見ればいいのか、自分の知識では心もとない。

ただ、ちゃんと堅牢な作りにしておくべきだということは分かります。だったら、詳しい側に見てもらえばいい。そう考えました。

どこまでの権限を渡すか

そして、ここがいちばん悩んだところです。

Claude に、クラウドのどこまでの権限を渡すのか。

本来の考え方でいけば、限定的な権限だけを与えるべきです。必要なことだけができて、それ以外はできない状態にしておく。セキュリティの世界では当たり前の原則です。

ただ、私の場合はそうしませんでした。

理由は単純で、私はClaudeに、オーナー権限に近い操作まで任せたいからです。ユーザーの権限設定も、費用まわりの操作も含めて。限定権限にしてしまうと、いちばんやってほしいことができません。

なので、リスクを承知の上で、Claude は私のオーナー権限でGCPを操作しています。

「セッションごとに権限を払い出す」案は、やめました

途中で、こういう案も考えました。Claudeのセッションやエージェントごとに、限定的な権限を都度払い出す。 作業が終わったら回収する。一見、良さそうに見えます。

でもこれ、よく考えると意味がないんです。

なぜなら、権限の申請も、付与も、Claude Code の中の世界で完結してしまうから。「この作業にはこの権限が必要です」と申請するのも、それを承認して払い出すのも、結局は同じ環境の中で起きます。鍵を預けている相手に、鍵の管理も任せている状態になる。それでは守りになりません。

だったら最初から、権限を渡していることを自覚した上で、別の方法（監査と、人間が決めること）で見張るほうが正直だと判断しました。

ここは人によって結論が分かれるところだと思います。私のは「オーナー権限を渡した上で、見張りを立てる」という選び方です。

自己責任で、ということ

最後に、大事なことを。

Google Cloud は、想定以上の費用が発生しうるサービスです。

私が18万円払ったように、使い方を間違えれば、普通に高額の請求が来ます。会社なら誰かが止めてくれるところが、個人には誰もいません。請求も事故も、全部自分に返ってきます。

そのあたりをしっかり理解した上で、自己責任で使ってください。前編で「ちょっと試してみませんか」と書いた私が言うのも何ですが、ここは譲れないところです。

その上で、こうも思います。

AIエージェントの時代に、AIにどんな権限を与えるか。それによってどんな利便性が手に入り、どんなリスクを負うのか。

ここをしっかり理解して、自分で判断できるようになっていきたい。これはクラウドに限った話ではなく、これから何度も問われることだと思っています。

便利さの話は前編に書きました。危なさの話が、今日の分です。両方込みで、手元に置いておく価値はあるというのが、いまの私の結論です。