こんにちは、MA部配信基盤ブロックの田島です。配信基盤ブロックでは、ZOZOTOWNのPush通知・LINE・メールといったユーザへの配信を担う配信基盤を、Google Cloud上で開発・運用しています。 配信基盤ではPRD・QA・STG・DEVの4環境のGoogle Cloudプロジェクトを持ち、年度予算に対して毎月の見積もりと実績を管理しています。月次の予実管理では、SKU単位の数字を環境ごとに追い、見積もりとの差分の要因を1つずつ調べる必要があります。この作業には毎月数日かかっていました。 そこで、BigQueryの課金エクスポートとGoogleスプレッドシートを土台にして、月次のコスト管理をClaude Codeのスキルとして自動化しました。金額はクエリで機械的に集計し、AIには差分の要因の推定やコメントの記載を任せています。過去の数値とその根拠はすべてスプレッドシートに残し、スキルには作業の手順と処理だけを持たせています。人間の確認を入れながら運用し、問題ないとわかった作業から順に自動化してきました。 現在は、人間の確認・判断以外の作業をすべてスキルの呼び出しで実行しています。なお、本記事はわかりやすさを優先してClaude Codeに合わせた書き方をしていますが、同じことは他のAIエージェントでもできます。実際に、この仕組みも最初はCodexで運用していました。 本記事では、その仕組みと、運用しながら「AIにどこまで任せるか」を見直してきた過程を紹介します。 目次 目次 背景と課題 配信基盤のGoogle Cloudコスト管理 課題 全体像 設計で考慮したこと 金額はAIに取らせない 数値と根拠はスプレッドシートに残し、スキルには役割だけを持たせる 配信数のばらつきを追えるようにする SKUの中の内訳をラベルで追えるようにする 人間はレポートだけを確認する 確認しながら自動化する スプレッドシートの設計 課金エクスポートの取り込み 中間シートの2段構成 シート構成 変動予定メモと変動要因メモ 月次運用フロー 各ステップの仕組み 月次レポート 要因調査 見積もりの自動生成 見積レポート 運用しながら見直したこと AIに任せる範囲 失敗をスキルへ書き戻す 課金データを扱うときの注意点 開発時点でコスト影響を拾う 効果 月次の作業が数日から1〜2時間になった 見積もりと実績の差が小さくなった コストのかかっている場所を細かく追えるようになり、コスト削減が進んだ 今後の展望 まとめ 最後に 背景と課題 まずは、配信基盤のGoogle Cloudコスト管理の背景と、取り組む前に抱えていた課題を紹介します。 配信基盤のGoogle Cloudコスト管理 配信基盤ではCloud Run、Pub/Sub、Firestore、BigQuery、Cloud SQL、Cloud Loggingなど多くのサービスを利用しています。コストは配信数に比例して変動するものもあれば、インスタンスのサイズ変更などの構成変更によって段階的に変わるものもあります。 MA部では部全体のGoogle Cloudの年度予算を持っており、各チームは担当サービスの月ごとの見込みを部の予実管理シートへ反映しています。そのため配信基盤ブロックでは、毎月次の作業をしていました。 前月の実績を確認する 見積もりとの差分について、要因を調べて説明する 当月の見積もりを作る 部の予実管理シートへ見込みを反映する 課題 この作業には次のような課題がありました。 確認するSKUが多い 4環境それぞれに数十〜百程度のSKUがあり、すべてを目で追うのは大変 配信数のばらつきが、どのリソースのコストに効いているかを追う必要がある 配信数はおおむね決まっているが、月によってばらつきがある 配信数が変わると、Cloud Run・Pub/Sub・Firestoreなど複数のリソースのコストが変わる 同じSKUの中で、どのリソースにどれくらいの費用がかかっているかがわからない Cloud RunのCPUやBigQueryのクエリのように、1つのSKUに複数のサービスの費用が混ざっている 内訳を知るには、毎回BigQueryの課金エクスポートへ直接クエリを書いて調べる必要があった 差分の要因を調べるのに手間がかかる 配信数の増減、リリース、構成変更などが重なり、日次の推移とPRを突き合わせないと特定できない コストが変わる予定の情報が散らばっている PR、Slack、設計ドキュメントなどに分かれており、見積もりを作るときに拾い漏れる 月の日数の差を、SKUごとに考慮して計算する必要がある Cloud Runのインスタンスのように時間単位で課金されるSKUは、月の日数が多いほど費用が増える ストレージのように月単位で課金されるSKUは、月の日数に左右されない どのSKUがどちらに当たるかを分類し、SKUごとに計算し直すのは手間がかかる 前月実績をそのまま使う見積もりでは精度が出ない 月の途中で始まった変動や終わった変動が、翌月の見積もりに正しく反映されない 金額にずれがあってはいけない 予算に関わる数字のため、集計の誤りがそのまま部の予実管理に影響する 全体像 ここからは、これらの課題を解決するために作った仕組みを紹介します。全体像は以下の通りです。 図の要素 役割 BigQuery（課金データ） 課金エクスポートのテーブル。全環境の課金データの取得元 スプレッドシート（数値と根拠） 過去のすべての数値と根拠（実績・見積もり・メモ・レポート）の置き場所 Claude Code（スキル） 作業の手順と処理だけを持ち、スプレッドシートを読み書きする 人間（確認・判断） レポートを確認して判断し、スキルを呼び出す BigQuery（配信数など） 要因調査で参照する、配信数などの参考指標 GitHub（PR/Issue） 要因調査で参照する、変更や作業の記録 Google Cloudの課金データはBigQueryへエクスポートしており、これを Connected Sheets でスプレッドシートに取り込んでいます。スプレッドシートを置き場所にしたのは、コストの確認や見積もりの修正を、エンジニア以外のメンバーや管理者もそのまま見られるようにするためです。 Claude Codeのスキルは、作業手順と判断基準を書いた SKILL.md と、Google Sheets APIでスプレッドシートを操作するPythonスクリプトの組み合わせです。月次の集計やレポート生成のような決まった処理はスクリプトで行い、差分の要因の推定やコメントの記載のような判断が必要な処理はAIが SKILL.md の手順に沿って行います。スキル自体は、個別の月の数値や経緯を持ちません。 スキルは、要因調査のときにスプレッドシートの数値に加えて2つの情報を参照します。1つは、BigQueryにある配信数やログ件数などの参考指標です。コストの増減が配信数の増減で説明できるかを確かめるために使います。もう1つは、GitHubのPRとIssueです。課金が変わり始めた日の前後にどのような変更や作業があったかを調べ、変動の原因を特定するために使います。 人間は、スキルを呼び出して作業を進め、スキルがスプレッドシートにまとめたレポートを確認して判断します。数値の取得と集計、要因の推定はスキルに任せ、人間は確認と判断を担います。 スクリプトは、 gcloud コマンドで発行したアクセストークンを使ってGoogle Sheets APIを呼び出しています。このとき、 gcloud auth login には --enable-gdrive-access オプションを付けて認証します。 gcloud auth login --enable-gdrive-access このオプションを付けると、発行されるトークンでGoogle Driveにもアクセスできるようになります。付けずに認証したトークンではスプレッドシートを読み書きできないため、このオプションが欠かせません。サービスアカウントの鍵を別に用意しなくても、普段使っている gcloud の認証のままでスプレッドシートを操作できます。 なお、このトークンはGoogle Drive全体にアクセスできる権限を持ちます。AIエージェントにこのトークンを使わせることになるため、権限の範囲が気になる場合は、サービスアカウントを用意して対象のスプレッドシートだけを共有する方法も検討してください。 cloud.google.com 設計で考慮したこと 続いて、仕組みの詳細を説明する前に、設計で考慮したことを紹介します。仕組みを作るにあたって、次の6点を考慮しました。 金額はAIに取らせず、クエリで機械的に集計する 過去のすべての数値と根拠はスプレッドシートに残し、スキルには役割だけを持たせる 配信数のばらつきが、どのリソースに効いているかを追えるようにする 見積もりと集計はSKU単位で行い、SKUの中の内訳は要因調査用にラベルで追えるようにする 人間はレポートだけを確認すればよいようにする 人間の確認を入れながら進め、問題ないとわかった作業から自動化する 金額はAIに取らせない コストの数字は予算に関わるため、ずれがあってはいけません。そのため、金額の取得と集計はAIに任せず、すべてクエリとスクリプトで機械的に行っています。 処理 担当 実績の取得・集計 Connected Sheetsのクエリとスプレッドシートの数式 見積もりの計算 スクリプト（前月実績と変動予定メモから計算） レポートの数値 スクリプト（スプレッドシートの値を転記） 差分の要因の推定・コメントの記載 AI AIの役割は、クエリで取った数字を読んで要因を説明することと、手順に沿って見積もりの調整を判断することです。見積もりを調整するときも、日次の実績などクエリで取った値を基に計算させています。AIに金額を推測させることはしていません。また、AIが調整した見積もりは、根拠にした値と計算をコメント列に残し、人間が確認します。 数値と根拠はスプレッドシートに残し、スキルには役割だけを持たせる 過去のすべての数値とその根拠は、スプレッドシートに残しています。具体的には次のものです。 SKU単位の月次実績 見積もりと、その見積もりにした理由のコメント 変動予定メモ・変動要因メモと、その金額計算 月次レポートと、差分の要因のコメント AIは作業の前に毎回このスプレッドシートを読みます。そのため、前月までの経緯を踏まえて要因を推定できます。 一方で、スキルには「何をどの手順で行うか」という役割だけを持たせています。 SKILL.md に書くのは作業の手順と判断基準です。スクリプトが行うのは、集計や書き込みのような決まった処理です。月ごとの金額や変動の経緯は、 SKILL.md とスクリプトのどちらにも書きません。対象のGoogle Cloudプロジェクトやスプレッドシートは、設定ファイルで指定しています。 このように分けておくと、スキルの中身がチーム固有の数値に依存しません。そのため、対象のプロジェクトとスプレッドシートを差し替えれば、他の部署にもスキルを横展開しやすくなります。ただし、指標とGoogle Cloudサービスの対応表やラベルのキーは配信基盤に合わせたものなので、各チームの構成に合わせて作り直す必要があります。また、数値と根拠がスプレッドシートにまとまっているため、スキルを使わない人もスプレッドシートを見れば経緯を追えます。 配信数のばらつきを追えるようにする 配信基盤の配信数は、配信計画などからおおむね決まっています。しかし、月によってばらつきがあります。配信数が変わると、Cloud Run・Pub/Sub・Firestore・BigQueryなど複数のリソースのコストが変わります。そのため、コストの差分を見るときは、配信数のばらつきがどのリソースに効いているのかを切り分ける必要があります。 そこで、月次レポートに配信数などの参考指標を並べ、指標とGoogle Cloudサービスの対応表を SKILL.md に書きました。AIはこの対応表を使って、差分のあるSKUが配信数で説明できるかを確認します。配信数で説明できない差分だけを、リリースや構成変更の影響として深掘りします。対応表の中身は「月次レポート」の節で紹介します。 SKUの中の内訳をラベルで追えるようにする SKU単位の集計だけでは、同じSKUの中でどのリソースがどれくらいの費用を使っているかがわかりません。たとえばCloud Runで課金されるCPUのSKUには、配信基盤にある複数のサービスの費用がまとめて計上されます。そのため、あるSKUの費用が増えても、どのサービスが増えたのかはSKUの数字からは読み取れません。 そこで、リソースに付けたラベルを課金データの集計にも使うようにしました。Google Cloudの課金エクスポートには、リソースに付けたラベルが課金の行ごとに記録されます。この値を分類のキーにして、SKUの費用をラベル単位に分けて集計しています。 cloud.google.com ラベルで分けた内訳は、月次レポートにも表として出しています。これにより、要因調査のたびに課金エクスポートへクエリを書かなくても、レポートだけでSKUの中の内訳を追えるようになりました。 ただし、ラベルはあくまで要因調査の補助として使っています。見積もりと集計はSKUを最小単位として行い、ラベル単位では行いません。ラベルはリソースに自由に付けたり外したりでき、値も後から変えられるためです。ラベル単位で見積もると、ラベルを付け替えただけで見積もりと実績がずれてしまいます。 人間はレポートだけを確認する スプレッドシートには過去のすべての数値と根拠を残していますが、それらをすべて人間が確認するのは大変です。そこで、確認に必要な情報を月次レポートと見積レポートにまとめ、人間はレポートだけを確認すればよいようにしました。レポートで気になった箇所があれば、元のシートやメモをたどって根拠を確認できます。 確認しながら自動化する 数字のずれが許されないため、最初からすべてを自動にはしませんでした。はじめは人間がAIの出力を1件ずつ確認しながら進めました。毎月の運用で問題ないとわかった作業から、順に人間の確認を外して自動化しています。どの作業をどう見直したかは「運用しながら見直したこと」の章で紹介します。 スプレッドシートの設計 ここからは、仕組みの土台となるスプレッドシートの設計を紹介します。課金データの取り込みから、集計用のシート、メモのシートまでを順に説明します。 課金エクスポートの取り込み Connected Sheetsのデータソースには、以下のクエリを設定しています。参照している gcp_billing_export_resource_v1_* は、Cloud BillingのBigQueryエクスポートで作られる「詳細な使用料金」のテーブルです。テーブル名の末尾には請求先アカウントIDが付きます。データセット名は、エクスポートを設定するときに自分で決めます。 cloud.google.com WITH base AS ( SELECT project.id AS project_id, FORMAT_TIMESTAMP( ' %Y-%m ' , usage_start_time) AS month, service.description AS service, sku.description AS sku, -- リソースラベルを1つの分類キーに正規化する COALESCE ( ( SELECT value FROM UNNEST(labels) WHERE key = ' service ' LIMIT 1 ), ( SELECT value FROM UNNEST(labels) WHERE key = ' query_name ' LIMIT 1 ), ( SELECT value FROM UNNEST(labels) WHERE key = ' source ' LIMIT 1 ), ' (未分類) ' ) AS label, cost_at_list AS cost FROM `project.dataset.gcp_billing_export_resource_v1_*` WHERE project.id IN ( ' project-prd ' , ' project-stg ' , ' project-qa ' , ' project-dev ' ) AND _PARTITIONTIME >= TIMESTAMP ( ' 2025-10-01 ' ) AND usage_start_time >= ' 2025-10-01 ' ) SELECT project_id, month, service, sku, SUM (cost) AS cost, label FROM base GROUP BY project_id, month, service, sku, label HAVING cost > 0 ORDER BY project_id, month, service, sku, label ポイントは次の3つです。 全環境を1本のクエリで取り込み、 project_id 列で環境を区別する コストは cost_at_list （定価ベース）を使う リソースラベルを service → query_name → source の優先順で1つの値にまとめ、 label 列にする label 列は、同じSKUの中でどのワークロードがコストを使っているかを調べるために使います。たとえばCloud RunのCPUのSKUが増えたとき、どのサービスが増えたのかをラベル単位で確認できます。 ラベルのキーはリソースの種類によって異なります。Cloud Runのサービスには service 、BigQueryのクエリには query_name のように、リソースごとに付けているキーが違います。キーごとに列を分けると集計の行数が増えて扱いにくいため、優先順位を決めて1つの値にまとめています。どのキーも付いていない費用は (未分類) として、金額が見えるようにしています。 課金エクスポートへの金額の反映には遅延があります。そのため、前月分の金額が出揃うのを待ってから、データソースを更新して月次の作業を始めています。 中間シートの2段構成 取り込んだデータは、2段階の中間シートに展開しています。 シート 中身 用途 (label単位)BQコスト データソースのExtract（6列） 要因調査用のラベル単位の分析 (sku単位)BQコスト ラベル単位のシートを QUERY 関数で集計した数式（5列） 集計シートやスクリプトの参照元 SKU単位のシートは以下の QUERY 関数で、ラベル単位のシートからラベルを畳んで作っています。数式なので、Extractを更新すれば自動で追従します。 =QUERY('(label単位)BQコスト'!A:F, "select A, B, C, D, sum(E) where A is not null group by A, B, C, D order by A, B, C, D label sum(E) 'cost'", 1) 集計用のシートは、すべて SUMIFS で「月・サービス名・SKU名」をキーに中間シートを参照しています。中間シートの行数や並び順が変わっても、集計結果が崩れないようにするためです。 シート構成 スプレッドシートの主なシートは以下の通りです。 シート 役割 変動予定メモ これから変わる予定のコストを記録する 変動要因メモ 実績で確認できた変動の要因を記録する 見積もり SKUごとの月次の見積もりを入力する 月次コスト管理（SKU別・サービス別・label別） 月次の見積もり・実績・差分を表示する 年度予算比（サービス別） 年度予算と見積もり・実績を比較する レポート（YYYY-MM） 月次レポート 見積レポート（YYYY-MM） 当月の見積もりの共有用レポート 集計用のシートはスクリプトで再構築できるようにしています。新しいSKUが出たときや月を追加したいときはスクリプトを実行し直すだけで済みます。このとき、見積もりやコメントなど手で入力した値は保持されます。 以下は月次コスト管理（SKU別）のシートの例です。なお、本記事のスクリーンショットの数値は、すべてダミーの値です。 変動予定メモと変動要因メモ この仕組みで最も重要なのは、2つのメモシートです。 メモ 内容 変動予定メモ これからコストが変わる予定 変動要因メモ 実績で確認できた変動の要因 それぞれのメモは、次のタイミングで書きます。 タイミング 変動予定メモ 変動要因メモ 設計・計画の段階や、コストに影響する変更のPRを作るとき 変更による増減の見込みを書く 書かない 想定していないコストの発生に気付いたとき 書かない 発生した変動とその要因を書く 月次の要因調査の後 定常的に金額が変わる変動を追加し、予定どおりに効かなかったものにはその旨を書く 予定が実際にどうだったかと、予定に書かれていなかった変動を書く どのタイミングでも、書き手は人間の場合とAIの場合があります。設計や開発の時点では、開発者が書くこともあれば、AIエージェントがコストへの影響を見積もって書くこともあります。月次の作業では、主にAIが書き、人間が内容と記載漏れを確認します。 つまり、変動予定メモは主に設計や開発の時点で書かれ、月次の作業で実績と突き合わされます。実績で変動を確認できたものは、変動要因メモにも記録します。 列はどちらも共通で、影響開始日・影響完了日・project_id・サービス・SKU・変動要因・金額影響（$/月）などを持ちます。 変動要因メモも同じ列構成です。 金額影響の列は、スクリプトが読み取って見積もりへ反映します。そのため、書き方を以下の形式に統一しています。 【6月】 0 + 約540 = 約540 【7月以降】 540(6月実績) + 40 = 580 【金額計算】 ・定常日額 約$18 × 30日 対象月を 【x月】 や 【x月以降】 のブロックで明記する ブロック内は「前月実績 + 増分 = 結果」の式で書く 新規リソースは 0 + 増分 = 結果 と書き、新規であることが式でわかるようにする 計算の過程は 【金額計算】 の見出しの下に書き、スクリプトの読み取り対象から外す なお、上記の金額はダミーの値です。 この書き方の利点は、増減の金額と増減後の金額を1行で表せることです。たとえば上の 【7月以降】 の式からは、前月実績の540ドルに対して40ドル増え、580ドルになることが読み取れます。 最初は自由記述で書いていたため、「約206ドル増加」のように増減だけを書いた行と、「268ドルで着地予定」のように増減後の金額だけを書いた行が混ざっていました。増減だけの行からは変動後の金額がわからず、増減後の金額だけの行からはどれだけ変わったのかがわかりません。また、スクリプト側でもこの2種類の表記を読み分ける必要がありました。 今の書き方では、見積もりのスクリプトは対象月に当てはまるブロックを探し、式の右辺を「着地見込み」として扱います。 + や - 付きの値だけが書かれている場合は「前月実績への増減」として扱います。書き方を決めたことで、人間とスクリプトで読み取る意味がそろいました。 月次運用フロー 続いては、このスプレッドシートを使った毎月の運用フローを紹介します。毎月月初に、以下のフローでコストを管理しています。 Step 内容 担当 1 前月分の金額が出揃うのを待って課金データを更新 人間 2 前月の月次レポートの生成 AI 3 要因調査とレポートへのコメント記載 AI 4 要因調査の確認・深掘り 人間 5 サービス別コメントの記載 AI 6 変動要因メモ・変動予定メモの更新 AI 7 変動予定メモの記載漏れの確認 人間 8 当月の見積もり生成・調整と見積レポートの生成 AI 9 見積もりの確認 人間 10 年度予算比の理由の記入 AI 11 年度予算比の確認 人間 12 部の予実管理シートへの反映 人間 AIが担当するStepは、すべてスキルを呼び出して実行します。たとえばClaude Codeでは、月次レポートを次のように依頼します。 /notification-platform-gcp-cost 前月の月次レポートを出して このフローでは、 AIが先にスプレッドシートへ書き込み、人間は後から確認して必要な箇所だけを直す ようにしています。 各ステップの仕組み ここからは、運用フローのうち主なステップについて、それぞれの中身を紹介します。 月次レポート 月次レポートは、前月の実績を環境ごとに確認するためのシートです。環境ごとのブロックには、次の表を並べています。 変動要因の参考指標 サービス別の前月比 SKU別の前月比 label別の前月比 サービス別の見積差分 SKU別の見積差分 label別の見積差分 label別の表は、SKUの費用をラベル単位に分けたものです。見積もりはSKU単位でしか作っていないため、label別の見積差分では、SKUの見積もりを前月のラベルごとの構成比で按分した参考値と比べています。なお、 (未分類) のラベルの費用はlabel別の表の対象外にしています。 参考指標は、Push・LINE・メールの配信数やCloud Loggingのログ件数などです。レポート生成時にBigQueryから直接取得しています。コストの変動が配信数の増減で説明できるかを確認するために使います。 指標とコストの関係は、以下の対応表として SKILL.md に書いています。AIはこの表を見て、差分の大きいSKUに関係する指標を確認します。 変動要因（指標） 影響するGoogle Cloudサービス 影響度 Push配信数 Cloud Run、Pub/Sub、Firestore、BigQuery Streaming Insert 大 LINE配信数 Cloud Run、Pub/Sub、Firestore、BigQuery Streaming Insert 大 メール配信数 Cloud Run 小 Cloud Loggingのエラー以上のログ件数 Cloud Logging 中 Cloud Loggingの全ログ件数 BigQuery Streaming Insert 中 差分の確認と記録は「SKU別の見積差分」の表に集めています。差分が誤差程度のSKUは表に載せず、確認の対象から外しています。表のコメント列には、要因調査でAIが推定した要因を書き、人間が確認して直します。 全環境を合算したブロックでは、サービス単位の見積差分とそのコメントをまとめています。 要因調査 月次レポートを作った後、要因調査を依頼します。 /notification-platform-gcp-cost 要因調査をします AIは「SKU別の見積差分」のすべての行について、次の情報から要因を推定し、レポートのコメント列へ書き込みます。 課金エクスポートの日次推移 参考指標 変動予定メモ・変動要因メモ 日次推移を見るのは、変動が始まった日と、変動後の1日あたりの金額を知るためです。月単位の実績だけでは、月の途中で何が起きたのかがわかりません。変動の始まった日がわかれば、その前後にマージされたPRを gh コマンドで探し、原因となった変更を特定できます。 AIが書いたコメントを人間が確認し、気になる項目を対話しながら深掘りします。深掘りでは、必要に応じてコードや gcloud コマンド、Cloud Monitoringのメトリクスで裏付けを取ります。 確認が終わったら、レポートのコメントを基に変動要因メモと変動予定メモを更新します。この更新では、主に次の3つを行います。 変動予定メモに書いてあった予定が実際にどうだったかを、実績と突き合わせて確認する 予定どおりに変動していたものは、実際の課金開始日と金額で変動要因メモに書く 予定していたのに実績に現れなかったものは、変動予定メモ側にその旨を書く 変動予定メモに書かれていなかった変動を、変動要因メモに書く 開発時に書き漏れていた変動を、要因調査で見つけた分だけここで拾う 翌月以降も定常的に金額が変わる変動を、変動予定メモに追加する 翌月の見積もりで拾えるようにするため メモへ書くかどうかは、以下の基準で判断しています。 変動の種類 書く場所 施策・構成変更による変動 変動要因メモ（定常化する場合は変動予定メモにも） devでの動作確認・負荷試験のみの費用 レポートのコメントのみ 配信数など指標で説明できる変動 レポートのコメントのみ ストレージの蓄積による自然増 レポートのコメントのみ 実績に現れなかった予定はその旨を書いておくことで、翌月以降の突き合わせの候補から外れます。 見積もりの自動生成 当月の見積もりは、次のコマンドで生成します。 /notification-platform-gcp-cost 2026-10の見積もりと見積レポートを作成して 各SKUの見積もりは、基本的には以下の式で計算します。 見積もり = 前月実績 × 対象月の日数 / 前月の日数 + 変動予定メモの金額影響 ただし、 Storage を含むSKUのように月単位で課金されるSKUは日数の補正をかけず、前月実績をそのまま使います。月の日数によって金額が変わらないためです。 日数の補正をかけるかどうかの分類と、SKUごとの計算は、すべてスクリプトで行っています。以前は前月と当月の日数を見比べながら、SKUごとに手で計算していました。SKUの数が多いため、この計算だけでも手間がかかり、計算の誤りも起きやすい作業でした。見積レポートの前月比でも、同じ分類で日数の差を補正した値を使っています。 ただし、すべてのSKUがこの式に当てはまるわけではありません。生成した後は、変動予定メモやレポートのコメントを確認し、式に単純に当てはめられないSKUは個別に計算して見積もりを入力し直します。この点検と調整もAIが行い、調整した結果は人間が確認します。点検の観点は次の通りです。 月の途中で始まった変動が、満額で見積もられているか 月の途中で終わった変動や水準の下がったSKUを、過大に見積もっていないか すでに前月実績に反映されている変動を、もう一度加算していないか 前月に実績がない一時的な費用の見積もりが、古いまま残っていないか 前月に初めて出たSKUの行が、見積もりシートから漏れていないか これらの観点は、すべて実際に起きた見積もりのずれから追加したものです。具体例は次の章で紹介します。 点検と調整の結果は、見積もりのシートのコメント列に残します。 見積レポート 見積もりが確定したら、管理者に共有するための見積レポートを生成します。見積レポートでは、サービスごとに前月比と、その要因を一覧にします。前月比は、日数の差とストレージの課金の特性を補正した値で計算しています。 ここまでで作った見積レポートと月次レポートを基に、管理者へ報告します。 運用しながら見直したこと ここまでは、現在の仕組みを紹介しました。この仕組みは2026年4月に作り始め、毎月の運用で見つかった問題を反映しながら改善してきました。続いては、運用しながら見直してきたことを紹介します。 AIに任せる範囲 ここまで紹介した月次の運用フローも、最初から今の形だったわけではありません。AIに任せる作業の範囲は、運用しながら何度か見直してきました。基本的には、人間の確認を入れながら運用し、問題ないとわかった作業から自動化の範囲を広げてきました。一方で、人間に戻した作業もあります。 対象 当初 現在 変動予定メモの記録 レポート生成時にAIがPRを自動スキャンして記録 開発時に人間が記録し、記載漏れを月次で確認 要因調査 人間とAIが1件ずつ対話しながら調査 AIが全件のコメントを先に記載し、人間は後から確認 要因調査は、最初は人間がAIと対話しながら1件ずつ進めていました。AIの推定が間違っていたときは、人間がその場で正しい要因を伝えます。そのうえで、なぜ間違えたのかを SKILL.md の手順や判断基準に反映し、次の月から同じ誤りが起きないようにしていきました。これを数か月続けて、AIの推定がある程度正確になってから、AIが全件のコメントを先に書き、人間は後から確認して気になる箇所だけ深掘りする形に変えました。多くの差分は配信数の増減やメモに書いてある施策で説明できるため、人間は説明できていない行に時間を使えるようになりました。 失敗をスキルへ書き戻す 運用の中で見積もりがずれたときは、原因を調べて SKILL.md の手順へ書き戻しています。次の月から、AIが同じ観点で点検するようにするためです。書き戻すのは点検の観点と手順で、その月の金額や経緯はスプレッドシートの変動要因メモに残します。 たとえば、月の途中でMemorystore for Valkeyの課金が始まったときの例です。2026年5月20日から課金が始まったため、5月の実績は12日分しかありませんでした。6月の見積もりは、この12日分の実績に日数比をかけた約272ドルになりました。しかし6月の実績は約711ドル（1日あたり約23.7ドル×30日）で、約440ドルずれました。そこで「月の途中で始まった変動は、メモの定常額と突き合わせて満額に調整する」という手順を追加しました。 AIは手順に書いてあることを確実に実行します。一方で、書いていないことには気付けない場合があります。失敗した具体例ごと手順に残しておくことで、AIが同じ失敗を繰り返さなくなりました。 課金データを扱うときの注意点 課金データを扱う中で、次のような注意点も見つかりました。これらも SKILL.md に書いています。 課金エクスポートのテーブルへのクエリは、 _PARTITIONTIME で絞り込む usage_start_time だけで絞り込むと全期間をスキャンし、数十分かかることがある 中間シートとBigQueryの集計値を比べるときは、同じ集計方法で比べる 課金エクスポートの cost_at_list には、マイナスの金額の行も含まれている 中間シートはラベル単位で合計してから0以下を除いているため、行ごとにマイナスの行を除いて合計すると、数割ずれて見える 日次推移は日本時間で、月次の金額は協定世界時（UTC）で見る 課金開始日の特定は日本時間の方がリリース日と合わせやすく、月次の金額はシートの集計に合わせる必要がある 請求書の月は太平洋時間で区切られるため、シートの月次の金額とは少しずれる 変動予定メモに書いたSKU名と、実際の課金のSKU名は異なることがある たとえばMemorystore for Valkeyの課金は、実績では Cloud Memorystore の Highmem Medium Node Tokyo として出る SKU名の末尾に空白の入ることがある 見積もりと実績の突き合わせが外れたため、比較前に空白を除くようにした 開発時点でコスト影響を拾う ここまでは、月次の運用について紹介しました。ただし、月次の仕組みだけでは、コストが変わってから気付くことになります。そのため、開発の時点でもコストの影響を拾えるように、ルールとスキルを用意しています。もっとも、どちらもまだうまく回っているとは言えず、試している段階です。 1つめは、Terraformのファイルを編集するときのルールです。Claude Codeで .tf ファイルを編集すると、コストへの影響を確認するよう促すルールを読み込ませています。リソースのサイズ変更や新しいリソースの追加がある場合に、PRの説明にコストへの影響を書き、変動予定メモにも記録することを想定しています。 2つめは、コストの影響を見積もるための別のスキルです。設計の段階で変更内容を渡すと、課金エクスポートの実績単価や、Cloud Monitoringのメトリクスなどから月額の増減を見積もります。見積もりは「少なめ予測」と「大きめ予測」の2つを出し、変動予定メモにそのまま書ける案も作ります。 これらがうまく回るようになれば、開発時点で変動予定メモに書いた予定が翌月の見積もりに自動で反映され、さらに翌月の要因調査で実績と突き合わされる流れができます。 効果 ここまで紹介した仕組みを運用して、主に3つの効果がありました。 月次の作業が数日から1〜2時間になった 以前は、月次の予実管理に毎月数日かかっていました。今は、同じ作業が1〜2時間で終わります。要因調査や見積もりの点検をAIが先に済ませ、人間は主にレポートを確認して判断するだけになったためです。 見積もりと実績の差が小さくなった 見積もりの精度も上がりました。運用を始めたころは、全環境の合計で見積もりと実績が1割以上ずれる月もありました。直近の数か月は、そのずれが数パーセントに収まっています。月の途中で始まった変動や終わった変動を点検の観点として手順に書き戻し、AIが毎月同じ観点で見積もりを調整するようになったためです。 コストのかかっている場所を細かく追えるようになり、コスト削減が進んだ SKU単位の集計に加えて、SKUの中の内訳もラベルで追えるようになりました。そのため、どのサービスのどのリソースにコストがかかっているかを、毎月細かく確認できます。削減できる箇所を見つけやすくなったことで、コスト削減の施策も進みました。ただし、ラベルで内訳を追えるのは、ラベルを付けたリソースの費用に限られます。まだラベルの付いていない費用も多く、ラベル付けを進めている段階です。 今後の展望 ここまで紹介してきた仕組みにも、まだ課題が残っています。 まだ人間が介入している作業がある 要因調査の深掘り、変動予定メモの記載漏れの確認、見積もりの確認などは人間が行っている システムの変更や配信数の増加を自動で検知できていない 変動予定メモは開発者が書く前提のため、書き漏れると翌月の要因調査まで気付けない 開発時にコストの影響を拾うためのルールとスキルも、まだうまく回っていない 配信数の増加も、実績に出てから気付いている ラベルの付いていない費用が多く残っている 2026年8月の実績では、費用の7割ほどが (未分類) だった BigQueryのストレージ、Pub/Sub、Memorystoreなど、まだラベルを付けていないリソースがある 管理の単位がチームにとどまっている 部の予実管理シートへの反映は、人間が手動で行っている 今後は、まず人間が介入している作業を減らしていきたいと考えています。あわせて、ラベルの付いていないリソースにラベルを付け、SKUの中の内訳を追える範囲を広げていきます。また、システムの変更や配信数の増加を自動で検知し、見積もりと変動予定メモへ反映できるようにしたいです。さらに、チーム単位で作ったこの仕組みを部署単位に広げ、MA部全体のGoogle Cloudコストを管理できるようにしていきたいと考えています。スキルにはチーム固有の数値を持たせていないため、各チームが自分たちのプロジェクトとスプレッドシートを用意すれば、同じスキルを使い始められる形を目指しています。 まとめ 本記事では、配信基盤のGoogle Cloudコストの月次管理を、BigQueryの課金エクスポート・スプレッドシート・Claude Codeのスキルで自動化した取り組みを紹介しました。 仕組みを作るうえで考慮したのは、次の6点です。 金額はAIに取らせず、クエリとスクリプトで機械的に集計した 過去のすべての数値と根拠はスプレッドシートに残し、スキルには役割だけを持たせた 配信数のばらつきが、どのリソースに効いているかを参考指標と対応表で追えるようにした 見積もりと集計はSKUを最小単位とし、SKUの中の内訳は要因調査用にラベルで追えるようにした 人間はレポートだけを確認すればよいようにした 人間の確認を入れながら進め、問題ないとわかった作業から自動化した その結果、月次の作業で人間が行うのは主に確認と判断になり、数日かかっていた作業が1〜2時間で終わるようになりました。また、見積もりと実績の差が小さくなり、コストがどこにかかっているかを細かく追えるようになったことでコスト削減も進みました。 スキルが数値を持たない形にしたことで、他の部署にも横展開しやすい仕組みになりました。Google Cloudのコスト管理に悩んでいる方の参考になれば幸いです。 もしこの運用方法を気に入っていただけたら、ぜひこの記事をAIに読み込ませて、同じフローの構築をAIに任せてみてください。本記事には、スプレッドシートの構成、課金エクスポートを取り込むクエリ、メモの書き方、月次の運用フロー、運用で見つかった注意点まで書いています。自分たちのGoogle Cloudプロジェクトとスプレッドシートを用意すれば、AIと一緒に同じ仕組みを組み立てられるはずです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

ソフトウェアエンジニアとしての経歴を活かし、どのようにリクルート データ推進室でキャリアを構築できるのか。 今回の連載では、

こんにちは。QAコンサルタントのテストのひろさんです。 本記事では、テスト進捗自体は順調なものの、現場の役割にミスマッチが生じていたプロジェクトの改善事例を紹介します。当時テストPMだった私が、JSTQB AL-TM v3.0Jシラバスなどの知見を活用し、どのように体制再構築と再発防止に取り組んだのかをお伝えします。 現場の運用に課題を感じている方の気づきや、参考になれば幸いです。 対象プロジェクトの概要 当時のテストプロジェクトの基本情報は以下の通りです。 テストレベル: システムテスト 期間: 2か月 テスト環境: オンサイト プロジェクト計画: システムテストの後に、機能追加に対するシステムテストを計画 チーム構成: PM（私）1名、テストリーダー（TL）1名、ビジネスパートナー（BP）リーダー1名、BPテスター3名 役割分担: BPリーダー: 日々の進捗報告（TL宛）、QA・タスクリストの更新、ハンズオンでのテスト実施。進捗フォーマットやステータス管理手法はトレーニング済み。 BPテスター: テスト実行全般。 TL: 進捗管理、探索的テスト実施、機能追加のテスト設計、QA・タスクリストのチェックや回答。 PM: 複数テストプロジェクトの統括。 立ち上げ時、TLの業務負荷が潜在的なリスクとして見受けられました。しかし、以下の理由からそのような計画で進行することを決定しました。 システムテストの一次報告はBPリーダーが実施すること 機能追加に伴うテスト設計の規模が限定的であること 探索的テストの工数や時期を調整可能であること 具体的には、最初の2週間は進捗管理とQA対応に注力し、3週間目から機能追加のテスト設計および探索的テストを開始するスケジュールを設定しました。 進捗の裏側に生じていた問題 システムテスト開始後、BPリーダーからは予定を前倒しで進めていると報告を受けていました。しかし、詳細を確認していくと以下の状況でした。 テスト進捗は専用のツールで算出するのですが、私が改めて算出し直した進捗数と、実際に報告されている進捗数が異なっていました。また、課題管理表の内容とTLから報告されている内容が一致していなかったり、課題管理表そのものに記載が漏れている等の状況に気づきました。 起きていたことをまとめると以下の状況です。 実際の進捗数と報告された進捗数の不一致 タスク管理表と実際の作業状況のズレ、および記載漏れ TLはBPリーダーへ是正を何度か依頼しましたが改善されず、事実確認などの対応に追われることになります。結果としてTLの工数が圧迫され、予定していた機能追加のテスト設計や探索的テストに入れない状況が発生しました。 この時、現場では以下のような心理的・運用的課題が生じていたのです。 TLの心理: テスト設計も探索テストも進まず、進捗もまとまらないという状況から、自身の評価への懸念が生まれ、PMに相談できず一人で抱え込んでいた。 BPリーダーの心理: 上手く進捗報告ができていないという認識はあるものの、具体的な改善方法が見出せず困惑していた。 双方ともに悩んでいる状態でした。ここで少し私の考えを挟むと、悩むとは問題を認識して試行錯誤しているが出口が見えない状態であり、考えるとはゴールが見えていて、そこに向かっていく状態だと捉えています。当時の現場は、まさに前者の出口が見えない状態に陥っていました。 さらに、この是正がうまくいかない日々が続いたことで、テストリーダーとBPチームの間にも徐々に不穏な空気が流れ始め、コミュニケーションが膠着する二次災害も起き始めていました。 1. 捉え方の転換：個人の問題ではなく構造の問題 この状況に直面した際、私は起きている問題を個人の資質や特性に起因させないことが重要であると考えました。 一見すると報告が不正確なリーダー、抱え込んでしまうTLのスキル問題に見えますが、本質は違います。これは、現場の状況変化に対してプロジェクトの初期枠組みが適合しなくなったことによる構造的な問題であると捉えました。 ここでベースにしたのは、人を責めず、仕組みを改善するという方針です。書籍「スクラム」などにある「プレイヤーを憎むな、ゲームを憎め」という言葉の通り、個人を責めても本質的な解決にはならないと私は考えています。 JSTQB AL-TM v3.0J には、以下のような記述があります。 「テストチームは、プロジェクト開始時に、必要なスキルをすべて持っているとは限らない。完璧な人材がそろうとは限らないが、強力なチームであれば、個人の長所と短所のバランスを取ることができる。」 最初から完璧な人材がそろうチームは難しいことがあるため、個人のせいにせず、仕組みや役割によってバランスを取るという考え方から、システムテストの進行途中で以下のように役割と環境の再配置を行いました。 役割の再定義 BPリーダー: 進捗報告・管理業務から一旦離し、ハンズオンテストの割り当てを80%に増加。タスク管理の不備がスキルの問題なのか業務過多によるものなのかを切り分けるとともに、テスト実行の推進に集中するようにしました。残りの20%はPMやメンバーとのコミュニケーションに充てる割合に変更しました。 テストリーダー（TL）: テスト管理やBPチームとのコミュニケーションをタスクから切り離し、本来のミッションである探索的テストの実施と機能追加のテスト設計」に専念できる工数を確保しました。 PM（私）: このシステムテストの進捗管理を巻き取りました。BPリーダーとのコミュニケーションは、時間を固定して1日2回（各10分）の状況確認を実施する運用へ変更しました。 物理環境の変更（座席位置の調整） また、TLとBPチームの間で関係性の悪化（コミュニケーションの膠着）が見られたため、オフィスの座席配置を変更して物理的な距離を置きました。これにより、TLによるBPチームへの細かな確認や介入を構造的に抑制し、TLもBPチームも自分たちのタスクに集中できる環境を整備しました。 ガバナンスの再構築 正確な情報を把握するため、これまでチャットベースで済ませていた報告を「対面での同期」に切り替えました。これは指示命令を強化するためではなく、事実（ファクト）と報告の同期を目的としたものです。情報の透明性を確保することで、プロジェクトの正確な現状がステークホルダーやチーム全体に共有される仕組みへと変更しました。 2. 心理的安全性と規律の両立：1on1における対話 役割変更と並行して、TLとの1on1を実施しました。目的は、心理的安全性を確保した上で役割変更の背景を納得してもらい、機能追加テスト設計、探索的テストに集中してもらうことです。1on1では、特に以下の3つの軸を意識して対話を行いました。 評価の切り分け（安心感の醸成）: 今回の介入はあくまで、体制上の判断による役割の変更であり、TL個人の評価を下げるものではないことを明言しました。テスト期間中であり、最終的な品質やゴールに対する結果はまだ出ていないためです。 ティーチングの選択: 通常であれば自律的な成長を促すコーチングを採用しますが、今回は納期が迫る緊急時であったため、私のやり方を直接伝えるティーチングへと戦略的にシフトしました。山本五十六の「やってみせ、言って聞かせ、させてみせ、ほめてやらねば、人は育たず」の方針のもと、並走しながらサポートしました。 コミュニケーションの原則（アサーション）: 強い言葉で行動を縛るのではなく、仕組みで解決を図る姿勢（アサーションの原則）を大切にしたい旨をTLに伝え、目線を合わせました。 3. 再発防止：根本原因の特定と仕組みのアップデート プロジェクト完了後、次フェーズである機能追加テストに向けて、今回の問題の根本原因の特定と仕組みのアップデートを行いました。 根本原因：正しいデータが報告に繋がらない集計・出力構造 そもそも、なぜ進捗報告と実態の乖離が起きていたのか。仕組みとしてExcel上で予定と実績が10%以上乖離するとセルが赤字になるというアラートのルール自体は存在しており、Excel内の関数やシステム側の元データも正常でした。 しかし、最終的に算出されたデータを、報告用にアウトプットする（テキスト化する）段階で人為的なミスが発生していたことが根本原因でした。 当時の集計・報告フローは以下の通りです。 テスト管理システムから正しい実績データをCSVでダウンロードする 集計用のExcelへコピー＆ペーストする（Excel上の関数・アラート自体は正常に機能） Excelで算出された数値を、手作業で報告用のテキストに書き起こす（ここで転記ミスが発生） 最終的な報告テキストを作成するまでに手作業のプロセスが多く、結果としてExcel上ではアラート（赤字）が出ていても、報告段階でそれが消えてしまうという、人為的ミスを誘発しやすい構造になっていました。BPリーダー個人を責めるのではなく、ミスが起きる構造を変える必要がありました。 対策：集計・出力の自動化 手作業によるリスクを排除するため、CSVダウンロード後のデータ集約から、Excelでの集計、そして最終的な「報告用テキストの出力」までをワンクリックで行うVBAマクロを導入しました。 これにより、データの信頼性を担保した上で、PMやステークホルダーが日々のモニタリングで客観的な事実（定量データ）をそのまま受け取り、早期に異常（アラート）を検知できる仕組みへとアップデートしました。 4. 再発防止の効果：定量的・定性的アプローチ アップデートした仕組みの効果を現場の感覚で終わらせないために、JSTQB AL-TM v3.0Jのシラバスに記されている以下の格言を指針としました。 「マネジメントには『測定できるものは達成できる』という格言がある。同様に、測定されないものは、無視されやすいので、達成されることはないだろう。したがって、テストを含め、どのような取り組みに対しても、適切なメトリクスを確立することが重要である。」 この考えに基づき、定量的なメトリクス評価と定性的なアプローチ（心理的安全性の確保）の両面から効果を測定しました。 ① 定量的なアプローチ プロジェクトメトリクス: テスト実行数、実行率、ステータス（OK/NG/Block）の推移。自動集計化により、10%の乖離アラートが正しく機能するようになり、進捗の透明性が確保された。 プロダクトメトリクス: BPリーダーのテスト比率を上げたことによる進捗の加速、TLの探索的テストによる、欠陥検出数と修正数の推移。想定していた計画値と実績を比較することで、品質リスクの低減に繋がった。 プロセスメトリクス: 集計作業工数そのものが削減されたことによる相乗効果で、チーム全体の生産性が向上した。 ② 定性的なアプローチ（1on1による内面サポート） 一方で、数字には表すことが出来ないメンバーの悩みや心理的状況は、定性的にしか捉えることができません。ここでは1on1などの直接的な対話によるサポートが不可欠です。 ちなみに、JSTQB AL-TM v3.0Jのシラバスには「方法論的、社会的、個人の能力はテストに特化したものではないため、専門的能力の開発に重点を置く」といった旨も述べられています。つまり、1on1やアサーティブなコミュニケーションといったスキルもまた、マネジメント知識として意識的な習得やトレーニングが必要な領域です。トレーニングや考え方などについては「ヤフーの1on1」「成長マインドセット」などの書籍を参考にしています。 1on1を継続した結果、TLが問題を一人で抱え込まずに早めのアラートを出せる関係性が構築され、BPリーダーも何に困っているかを素直に共有してくれる環境へと変化しました。 おわりに 今回の取り組みを通じて、データの信頼性とアラートの定量化、心理的安全性の確保によって、仕事の側面と人の側面をマネジメントすることの重要さを実感しました。 人が間違えるのは、仕組みに問題があると捉えて、変化の激しいテストプロジェクトを計画したゴールへ導くことが、マネジメントの本質ではないでしょうか。 この記事が、現場の体制構築や運用に悩むエンジニア・マネージャーの皆さまにとって、少しでも新しい視点や気づきのきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。 （参考文献） JSTQB JSTQB-Syllabus.Advanced_TM_VersionV3.0.J02 スクラム 仕事が4倍速くなる世界標準のチーム戦術（ジェフサザーランド 著、石垣 賀子 訳） ヤフーの1on1 部下を成長させるコミュニケーションの技法（本間 浩輔 著） 成長マインドセット 心のブレーキの外し方（吉田 行宏 著） The post 心理的安全性とガバナンスを両立させるテストチームの改善事例 first appeared on Sqripts .