クラウドの費用の増え方を毎週追って、原因の候補と確かめる先を出す

処理の起点を決める

毎週決まった曜日と時刻を起点にします。

月曜の朝を推奨します。 週の初めに一覧が届けば、その週のうちに確認できます。金曜の夕方だと、週末を挟んで対応が遅れます。

費用データの反映には遅れがあります。 クラウド事業者の費用データは、確定までに数時間から1日程度かかります。直近1〜2日のデータは変動する前提で設計してください。

日次にしないでください。 費用は曜日によって変動します。土日に減り、月曜に増えるのは正常です。 日次で見ると、この変動が「増加」として出続けます。

月次にもしないでください。 それでは現状と変わりません。

もう1つの起点として、大きな増加の即時検出があります。 1日で前日比が一定の割合を超えた場合、週次を待たずに知らせます。 設定の誤りで大量の資源が立ち上がった場合を拾うためです。

この即時の検出は、閾値を高く設定してください。 前日比で2倍を超える、といった水準です。細かく設定すると、通知が毎日来ることになります。

月次のトリガーも置きます。 月初に、前月の判断の結果を集計します。「意図した増加」と「誤り」の割合が見えると、閾値の調整ができます。

入力データを集める

データの取得方法を決める

タグの規約が、この構成の質を決めます。 タグが付いていなければ、持ち主が分かりません。

ExpiresAt のタグが、実務では効きます。 検証用に立てた資源が消されずに残ることが、費用の増加のよくある原因です。期日を過ぎた資源を一覧にできます。

タグが付いていない資源が必ず残ります。 導入の前に、タグの付与率を測ってください。 7割を下回るようなら、まずタグを付ける運動から始めるほうが効きます。

命名規則も、タグの代わりになります。 prod-search-api-01 のような形なら、名前から環境とサービスが分かります。タグと命名の両方から持ち主を推定してください。

変更の記録との照合が、原因の候補を出す鍵です。

「同じ日に何があったか」が分かるだけで、原因の切り分けが大きく速くなります。

過去の判断： 運用を始めてからたまります。「このサービスのこの増え方は、毎月の定期処理によるもの」という判断が記録されていれば、次回から除外できます。

AIへ渡す前に整形する

1. 費用データの取得 … 日次の粒度で、アカウント・サービス・資源・タグ別に取ります
2. 通貨と税の扱いの統一 … 事業者によって表示が違います。税抜で統一してください
3. 割引・クレジットの分離 … 予約購入やコミットメントによる割引は、費用の変動として扱うと誤検出になります。分けて集計します
4. 移動平均の計算 … 直近4週の同じ曜日の平均を基準にします。曜日の変動を吸収するためです
5. 乖離の計算 … 基準からの差を、金額と割合の両方で出します
6. 閾値による絞り込み … 金額と割合の両方の条件を満たすものだけを候補にします
7. 持ち主の推定 … タグ、命名、作成者から候補を出します
8. 変更の記録との照合 … 増加した日の前後3日の変更を取ります

4の「同じ曜日の平均」が、誤検出を大きく減らします。 月曜と日曜では費用が違います。単純な直近7日の平均と比べると、曜日の影響が乗ります。

6の「金額と割合の両方」が重要です。 割合だけで見ると、月1,000円の資源が3,000円になったときに「3倍」として上位に出ます。金額だけで見ると、大きなサービスの小さな変動が埋もれます。

最後の行を入れてください。 大きなサービスで割合は小さくても、金額が大きければ確かめる価値があります。

AIに処理させる

計算処理にさせること（生成AIには任せない）：

Claude API にさせること：

原因を断定させません。 「設定の誤りです」「不要な資源です」と書かせないでください。候補を挙げるところまでです。

費用を減らす提案もさせません。 「このインスタンスを小さくすべきです」といった提案を禁じてください。構成の判断は、サービスを運用するチームが行います。

資源の削除や停止も指示させません。 「このインスタンスを停止してください」と書かせないでください。本番のサービスかもしれません。

計算もさせません。 金額、割合、移動平均は Code ノードで確定させます。

指示内容を固定する

あなたは情報システム部でクラウドの費用を管理する担当者です。
検出された費用の増加について、内容を言葉にし、原因の候補と
確かめる先を挙げることが役割です。

【厳守事項】
- 原因を断定しないでください。
  「設定の誤りです」「不要な資源です」「無駄な支出です」と書かないでください。
  候補を挙げ、「確かめる先」を示すところまでにしてください。
- 費用を減らす提案をしないでください。
  「インスタンスを小さくすべきです」「予約購入を検討すべきです」
  と書かないでください。
  構成の判断はサービスを運用するチームが行います。
- 資源の停止や削除を指示しないでください。
  「このインスタンスを停止してください」と絶対に書かないでください。
  **本番のサービスを止める事故につながります。**
- 計算をしないでください。
  金額、割合、移動平均、乖離はすでに計算済みです。
  与えられた数値をそのまま使ってください。
- 与えられていない資源や変更について書かないでください。
  推測でサービス名や構成を補わないでください。
- 原因の候補は、下の「同じ時期の変更の記録」に含まれるものだけから挙げてください。
  変更の記録にない原因を想像で挙げないでください。
  該当する変更がない場合は「同じ時期の変更の記録に該当なし」と書いてください。
- 確かめる先は、下の「持ち主の候補」に含まれる相手だけを挙げてください。
  持ち主が特定できない場合は「持ち主が特定できません。タグが付いていません」
  と書いてください。
- 確かめる内容は、問う形で書いてください。
  「この増加は意図したものか」「いつまで続く見込みか」を聞く形にしてください。
  対応を指示する形にしないでください。
- チームや個人を評価しないでください。
  「このチームは費用の管理ができていません」と書かないでください。
- 優先度は、金額の大きさと、過去に同じ増え方があったかで示してください。
  「緊急」といった強い言葉を使わないでください。

【検出された増加（アカウント / サービス / 資源 / 増加額 / 増加率 / 基準）】
{cost_increases}

【持ち主の候補（タグ / 命名 / 作成者から推定）】
{owner_candidates}

【同じ時期の変更の記録（デプロイ / 構成変更 / チケット / 障害）】
{change_records}

【過去の同様の事例（増加の内容 / そのときの判断）】
{past_cases}

【チーム別の予算の目安】
{budgets}

「資源の停止や削除を指示しない」の指示が、この構成でもっとも重要です。 一覧に「このインスタンスを停止してください」と書かれていて、担当者がそれに従った場合、本番のサービスが止まる恐れがあります。 この禁止は、テストで必ず確認してください。

「変更の記録にない原因を想像で挙げない」の指示も外せません。 「おそらくデータ量の増加によるものです」という推測が書かれると、それを前提に調査が進み、本当の原因を見落とします。

「対応を指示する形にしない」の指示が、関係との摩擦を防ぎます。 情報システムが開発チームへ「止めてください」と言う形になると、費用の管理が押し付けに見えます。 「意図したものか」を聞く形にしてください。

「チームを評価しない」の指示も入れてください。 費用の増加は、事業が伸びている証拠であることもあります。増加そのものを悪とする書き方をしないでください。

出力形式を固定する

{
  "run_date": "",
  "period": { "from": "", "to": "" },
  "findings": [
    {
      "cloud": "",
      "account": "",
      "service": "",
      "resource": "",
      "increase_amount": 0,
      "increase_rate": 0,
      "baseline": 0,
      "description": "",
      "owner_candidates": [
        { "team": "", "basis": "tag | naming | creator", "confidence": "high | low" }
      ],
      "possible_causes": [
        { "change_record": "", "date": "", "relation": "", "certainty": "possible | unclear" }
      ],
      "no_matching_change": false,
      "questions_to_ask": [],
      "past_similar_case": "",
      "priority": "high | medium | low",
      "priority_basis": ""
    }
  ],
  "unattributed_resources": [
    { "resource": "", "amount": 0, "reason": "no_tag | no_naming_match" }
  ],
  "summary": {
    "total_increase": 0,
    "findings_count": 0,
    "with_cause_candidate": 0,
    "without_cause_candidate": 0,
    "unattributed_amount": 0
  }
}

Claude API で出力をスキーマに沿わせるには、output_config の format に json_schema を指定します。 古い output_format は非推奨で、output_config.format に置き換わりました。

スキーマには制約があります。 enum は文字列・数値・真偽値・null に限られます。数値の minimum / maximum / multipleOf、文字列の minLength / maxLength / pattern は使えません。 金額を0以上に縛ることはスキーマではできないため、受け取った後に確かめてください。

最初にスキーマを使うときは、文法のコンパイルに時間がかかります。 結果は24時間キャッシュされますが、スキーマの構造やツールの構成を変えると無効になります。 週次の実行では、毎回コンパイルが走る可能性があります。

certainty を possible と unclear の2つにしていることが、設計上の意図です。 likely や confirmed を入れると、断定に近い表現が出ます。確からしさを表す語彙を、意図的に弱くしています。

no_matching_change のフラグが要ります。 変更の記録に該当がない増加は、むしろ注意して見るべきものです。 誰も何もしていないのに費用が増えているということだからです。

unattributed_resources が、この構成の副産物として重要です。 タグが付いておらず持ち主が分からない資源の一覧です。この金額を毎週見せることが、タグを付ける動機になります。

questions_to_ask は「問う形」で書かせます。 「この増加は意図したものか」「いつまで続く見込みか」「一時的なものか」です。

システムへ連携する

一覧を出すだけで、クラウドへの操作は一切行いません。

クラウドへの操作を絶対に自動化しないでください。 資源の停止、削除、サイズの変更。どれも本番のサービスに影響します。 この構成は読み取りだけです。

権限も読み取りだけにしてください。 費用データと資源の情報を読む権限で足ります。書き込みの権限を与えないことが、事故を防ぐいちばん確実な方法です。

各チームへの連絡も、担当者が行ってください。 自動で「あなたのチームの費用が増えています」と通知すると、意図した増加の場合に不要な負担をかけます。 情報システムが内容を見てから聞く形にしてください。

ただし、unattributed_resources の一覧は、全体へ共有して構いません。 「持ち主の分からない資源が月◯万円分あります」という情報は、特定のチームを指すものではないためです。

人が確認する

担当者が、原因を確かめて判断します。

確認を速くするための設計が効きます。

• 金額の大きい順に並べる
• no_matching_change に印を付ける
• 過去の同様の事例を併記する
• 持ち主の候補を連絡先とともに示す
• 判断の結果をその場で入力できるようにする

2つ目が効きます。 変更の記録に該当がないのに費用が増えているケースは、放置されている資源や、外部からの負荷の増加である可能性があります。 優先して見る価値があります。

判断の結果を必ず記録してください。 「意図した増加（新機能のリリース）」「誤り（検証用の資源の消し忘れ）」「様子見」の3択です。この記録が、次回の判定の精度を上げます。

月次で、判断の内訳を見てください。

例外に対処する

「クラウドへ書き込む権限を与えない」は、設計の原則としてください。 読み取りだけの権限で足ります。書き込みの権限がなければ、どんな不具合があっても資源は消えません。

記録を残す

この記録は、閾値と判定の精度を育てる材料になります。

• 実行日時と、取得したデータの範囲
• 検出した増加と、その金額・割合
• 原因の候補と、変更の記録との照合の結果
• 担当者の確認と、判断（意図／誤り／様子見）
• 誤りだった場合の、実際の原因と対処
• unattributed_resources の金額の推移
• 検出されなかったのに後で分かった増加

最後の項目が、この構成の弱点を示します。 月次の請求を見て初めて分かった増加が、週次の検出に引っかからなかったということです。 閾値が高すぎるか、集計の粒度が粗すぎます。

「誤りだった場合の実際の原因」を分類してください。

この分類が集まると、予防の手が打てます。 「消し忘れ」が多いなら、ExpiresAt のタグの運用を強めます。

費用データには、事業の状況が表れます。 どのサービスが伸びているか、どこに投資しているか。閲覧範囲を情報システム部と経営に限定してください。

外部のAIサービスへ渡す範囲も決めてください。 サービス名、資源名、金額。資源名に顧客名が含まれることがあります。 渡す前に確かめてください。