AzureのダブルチェックをClaudeで自動化できたのでGCPにも横展開したら、GUI目視に戻ってきた話

はじめに

こんにちは、原田です。

私のチームでは、社内検証用としてAzureリソースグループやGoogle Cloudプロジェクトの払い出し等の運用をしています。
以前、Azureの「リソースグループ発行のダブルチェック」を Claude（AIプロジェクト）+ CLI で半自動化したところ、これがなかなか快適でした。
その時の記事はこちらです→Claudeプロジェクトでダブルチェック作業を半自動化してみた

「同じノリでGoogle Cloudのプロジェクト作成ダブルチェックも自動化できるはず」と横展開に挑戦したのですが
結論から言うと、少件数の日常運用では、GUI目視の方が速い、という判断になりました。

この記事では、GCP版を作ろうとして実際にハマったところと、
最終的に「これはGUI目視でいいな」と判断した理由を書きます。

同じように、AIやCLIで運用チェックを楽にしようとしている方の参考になれば嬉しいです。

背景：Azure版はうまくいっていた

Azureでは、以下のようなフローで運用していました。

1. AIプロジェクトに「ダブルチェックしたい」と入力
2. AIが数点ヒアリング（利用者・部門・リソースグループ名）
3. AIが穴埋め済みの PowerShellコマンドを生成
4. Azure Cloud Shellに貼って実行
5. 出力をAIに貼り戻すと、チェック表＋総合判定＋Slack報告文を返してくれる

az コマンドはCloud Shellの既定認証でそのまま通り、体験は「貼るだけ」でした。
これに味をしめて、GCP版も同じ設計で作り始めました。

やりたかったこと：GCPプロジェクト作成の完了チェック

GCP側でチェックしたい項目は以下です。

これを gcloud（bash / Google Cloud Shell）で取得し、結果をAIに判定させる想定でした。
しかし、実際にやってみると想定外の壁が続きました。

ハマりどころ

1. Billing Budgets API は「quota project」の指定が必須

一番ハマったのがこれです。
予算一覧を取ろうとすると:

ERROR: (gcloud.billing.budgets.list) [user@example.com] does not have permission to
access billingAccounts instance [XXXXXX-XXXXXX-XXXXXX] (or it may not exist):
Your application is authenticating by using local Application Default Credentials.
The billingbudgets.googleapis.com API requires a quota project, which is not set by default.
...
  metadata:
    consumer: projects/NNNNNNNNNNNN
    service: billingbudgets.googleapis.com
  reason: SERVICE_DISABLED

ログを見ていて、特に大事だったのはここでした。

• 今回の環境では、Billing Budgets API をADCで使う際に quota project の指定が必要でした。
• 未指定だと、consumer に出ていたプロジェクトがAPI利用元として扱われ、そこでAPIが無効だったため SERVICE_DISABLED になっていました。

要するに、「誰のお財布・利用枠でAPIを使うのか、Google Cloudにちゃんと伝えてね」ということです。
やっかいなのは、エラー文に does not have permission to access billingAccounts と出ることです。
直訳すると「請求先アカウントにアクセスする権限がありません」です。
なので最初は、ユーザー権限の問題だと思いましが、実際はquota projectの指定漏れが原因でした。
「quota project」はざっくり言うと、”このAPI利用をどのプロジェクトの利用枠として扱うか”です。

対策：対象プロジェクト自身を quota projectに使い、そこでAPIを有効化する。

gcloud services enable billingbudgets.googleapis.com --project="$PROJECT_ID"
gcloud config set billing/quota_project "$PROJECT_ID"

gcloud auth application-default login（Google CloudのAPIを使うために、自分のGoogleアカウントでログインし直すコマンド）で認証し直す方法もありますが、途中で認証コードを手で貼る必要があります。
ここで別のコマンドを貼ってしまうとMalformed auth code（貼られた認証コードの形がおかしいよ、というエラー）になるなど、作業ミスが起きやすそうでした。

そのため、運用では対話なしで実行できる
gcloud config set billing/quota_project（Billing APIを使うときの「利用枠の請求先プロジェクト」を指定するコマンド）を使うことにしました。

2. gcloud が実行途中で対話プロンプト（y/N）を出す

quota projectを直したら、今度は gcloud projects describe（作成後のプロジェクト番号を管理表に転記するためのコマンド）などが実行の途中で止まりました。

API [cloudresourcemanager.googleapis.com] not enabled on project [sample-project].
Would you like to enable and retry (this will take a few minutes)? (y/N)?  y
...
API [cloudbilling.googleapis.com] not enabled on project [sample-project].
Would you like to enable and retry ...? (y/N)?  y

「コピペして待つだけ」のはずが、途中で y を何度も求められて手が止まるようになりました。
地味にストレスだし、非エンジニアのチームのため、慣れない操作はなるべくさせたくない……。

対策：あとで必要になるAPIは、最初にまとめて有効化するようにしました。

gcloud services enable \
  cloudresourcemanager.googleapis.com cloudbilling.googleapis.com \
  billingbudgets.googleapis.com monitoring.googleapis.com \
  --project="$PROJECT_ID" --quiet

3. --filter のenum値はクォートが必要

フィルター条件の中で決まった文字列を指定するときは、値を "..." で囲む必要があるということです。

enumは「イーナム」と読みます。
自由入力ではなく、あらかじめ用意された選択肢の値（例：email / sms / webhook）です。

Monitoring の通知チャンネルを type で絞ろうとしたところ、以下のエラーになりました。

ERROR: (gcloud.beta.monitoring.channels.list) INVALID_ARGUMENT:
Invalid field "filter" [value == "type=email"]; ambiguous use of email on the right-hand side ...
please quote if you meant to refer to the literal string "email".

--filter="type=email" はNGで、filter内の値をダブルクォートする必要がありました。

gcloud beta monitoring channels list --project="$PROJECT_ID" \
  --filter='type="email"' \
  --format="json(displayName, labels.email_address, enabled)"

AIと一緒に作る過程での「往復」と誤診断

このツールは対話AI（Claude）と一緒に作ったのですが、そのやり取りでも学びがありました。
AIの提案をそのまま信じると危険という当たり前の話でもあります。

• 修正したはずの内容が反映されていなかった：--filter="type=email" の修正について「直しました」と返ってきたのに、実際に動かすと同じエラーが出ました。ログには正解である type="email" が出ていたのに、生成コードには反映されていませんでした。
• エラー原因の誤診断：4aの予算アラート作成時のエラーについて、AIは最初「請求先アカウントを見る権限が足りないのでは」と判断しました。しかし実際には権限ではなく、API利用に使うプロジェクトの指定が原因でした。エラー文に permission と出ていたため、それに引っ張られたようです。
• 最後は自分で動かして確認する必要があった：AIが「直りました」と言っていても、実際に使ってみると手入力が必要な箇所が残っていることがありました。運用で困らない形になっているかは、実機で確認して初めて分かりました。

ここで学んだのは、AIが出したコマンドや原因診断は、必ず実機のログと突き合わせて自分で確定することが大事ということです。
permission という文字だけを見て権限エラーだと決めつけず、reason や consumer などの詳しい情報まで見る必要がありました。

結局「目視項目」は消えなかった

上記を全部潰した結果、自動判定（0・2・3・4a・4b）は安定して通るようになりました。
最終的なセットアップ部分は以下です。

PROJECT_ID="sample-project"
USER_EMAIL="user@example.com"
BILLING_ACCOUNT="XXXXXX-XXXXXX-XXXXXX"

# 必要APIを事前に全部有効化＋quota project設定（対話プロンプトを出さない）
gcloud services enable \
  cloudresourcemanager.googleapis.com cloudbilling.googleapis.com \
  billingbudgets.googleapis.com monitoring.googleapis.com \
  --project="$PROJECT_ID" --quiet
gcloud config set billing/quota_project "$PROJECT_ID" --quiet

しかし、どうしても目視が残る項目がありました。

• フォルダ照合：親フォルダ名は取れるが、それが「部門一覧表の正しいフォルダ」かは表との突き合わせが必要 → 目視。
• 請求ロック（鍵マーク）：コンソールでの確認が確実 → 目視。
• 管理表への転記：誤字・空欄チェックは人の目 → 目視。

つまり、結局コンソールを開くなら、最初から全部コンソールで見た方が速いという地点にたどり着きました。

「自動化 vs GUI目視」をどう判断したか

1件あたりのコストで比較しました。

◆CLI自動化
Cloud Shellを開く → コマンドを貼る（初回はAPI有効化で数秒〜数分待ち）→ 出力を全選択コピー → AIに貼り戻す → 判定を読む → 目視の3項目。

◆GUI目視
コンソールで各ページを開いて見比べるだけ。
チェックリストがあれば迷わない。目視項目はもともとコンソールを見るので二度手間がない。

現状はダブルチェックが週に数件という規模です。
この量なら、往復と初期セットアップのコストが自動化のメリットを上回り、GUI目視の方が速いと判断しました。

Azureとの違い

「Azureで動いた成功体験を、前提の違うGCPにそのまま当てはめようとした」のが、今回ハマった大きな理由でした。

最後に

「自動化に挑んでみたけど、あえて手動に戻した」という判断も立派なアウトプットだと思っています。
この記事を読んで下さる方の遠回りを一つ減らせたら嬉しいです。

そして、もし「こんな解決方法あるよ！」という知見をお持ちの方がいらっしゃれば、ぜひ教えていただきたいです！

参考

• gcloud billing budgets
• gcloud services enable
• gcloud topic filters
• Application Default Credentials