Azure Sponsorship を使っていると、Azure ポータルの Cost Management が「このアカウント種別ではサポートされていません」となり、リソース グループ別のクレジット消費が追えず困りがちです。本記事では、原因と制約を整理し、API と OSS（CAnalyzer など）で RG 別コストを可視化する具体策をまとめます。
Azure Sponsorship で「Cost Management が使えない」よくある症状
Azure ポータルで Cost Management + Billing を開くと、サブスクリプションがグレーアウトし、スコープに選べなかったり、「このアカウント種別では Cost Management はサポートされていません」といったメッセージが表示されたりします。
この状態だと、普段なら当たり前にできる次の作業がほぼ封じられます。
- コスト分析（Cost analysis）で リソース グループ別 / タグ別 / サービス別の内訳を見る
- Budget（予算）やアラートで「一定額を超えたら通知」を作る
- エクスポート（Exports）で請求・使用量データをストレージに自動出力する
結果として、現場のリソース グループ（RG）オーナーが「自分の RG がどれだけクレジットを溶かしているか」を自力で把握できず、気づいたときにはクレジット枯渇……という事故が起きやすくなります。
結論：Azure Sponsorship は Cost Management の対象外になりやすい
Azure のコスト管理機能（Microsoft Cost Management）は、契約（オファー）形態によって使える/使えないが分かれます。Microsoft Learn の「Cost Management のデータを理解する」では、Microsoft Azure Sponsorship（例：MS-AZR-0036P） が「サポートされないオファー」として明記されています。
また、同じく Microsoft Learn の概要ページでも、スポンサー（sponsorship）系サブスクリプションは Cost Management でサポートされない（MCA へ移行後にサポート予定）という整理がされています。
CLI や API でも 422 エラーになる理由
「ポータルがダメなら API で…」と考えて Azure CLI の az consumption usage list や Consumption / Cost Management 系の API を実行すると、Sponsorship では HTTP 422 で失敗することがあります。エラーメッセージは「EA / Web Direct / MCA などの特定オファーのみ対応」といった趣旨で、Sponsorship が対象外であることを示しています。
(422) Cost Management supports only Enterprise Agreement, Web direct and Microsoft Customer Agreement offer types.| 契約/オファーの代表例 | Cost Management | 補足 |
|---|---|---|
| Enterprise Agreement（EA） | 利用できる | 組織単位の請求・管理が前提 |
| Microsoft Customer Agreement（MCA） | 利用できる | 課金アカウント/プロファイル単位で管理しやすい |
| Pay-As-You-Go（Web Direct / MOSP など） | 利用できる | 一般的な従量課金。データ反映にタイムラグあり |
| Azure Sponsorship（MS-AZR-0036P など） | 利用できないことが多い | ポータルで「not supported」になりやすい |
さらに重要な注意点として、Cost Management は「請求に対してクレジットが適用される前の推定コスト」を扱う世界観が強く、Cost Management 上の金額に“クレジット残高”そのものは含まれません。つまり、仮に将来 Cost Management を使える状態になっても、「クレジット消費の残高管理」は別に考える必要があります。
「リソース グループ別に見たい」を叶える2つのアプローチ
Azure Sponsorship で RG 別のクレジット消費を追うには、現実的には次のどちらかになります。
| アプローチ | 何がわかる？ | 精度 | 準備コスト | 向いているケース |
|---|---|---|---|---|
| A. Sponsorship ポータルの使用量（Usage）をダウンロードして集計 | 日次/明細ベースの「実績」に近いコスト | 高い（ただしデータ項目次第） | 中（抽出・加工・共有が必要） | 請求に近い数字で追いたい、Power BI で運用したい |
| B. リソース棚卸し + 料金APIで「稼働コストの目安」を推定 | RG ごとの“最低限かかりそうな月額”の目安 | 中（利用量課金は弱い） | 低〜中（ツールを使えば低い） | 「どの RG が高いか」を早く掴みたい、ガードレールにしたい |
どちらも一長一短です。結論としては「Aで実績を追い、Bで日々のガードレール（異常検知）を作る」のが運用的に強いです。
アプローチA：Sponsorship ポータルの Usage データをダウンロードして RG 別に集計する
Azure Sponsorship の専用サイト（microsoftazuresponsorships.com）には Usage（使用状況）タブがあり、使用量データを CSV / JSON でダウンロードできるという情報があります。ダウンロードできる項目例として、サブスクリプション名、日付、リソース識別子（ResourceGuid など）、サービス名、リージョン、数量、コストなどが挙げられています。
注意点として、Sponsorship ポータルは「サブスクリプション（またはアカウント）所有者が中心に操作する」前提のことが多く、RG オーナーが自分の責任範囲だけを直接モニタリングするのが難しい場合があります。現実的には、所有者側でダウンロード→集計→共有を定期運用にして、各 RG オーナーが“自分のレポート”を受け取れる形にすると回りやすいです。
ただし、同じ情報源で「そのままでは リソース グループIDが入っていない」とも言及されています。つまり、RG 別にしたい場合は「使用量データ」と「Azure 上のリソース情報」を突き合わせる工程が必要です。
集計の基本手順
- サブスクリプション所有者（または権限を持つユーザー）が Sponsorship ポータルから Usage をダウンロード
- CSV/JSON を Power BI（Power Query）や Python で読み込む
- リソースを特定できる列（Resource ID 文字列 / ResourceGuid / サービス名＋リソース名など）から RG を推定・紐づけ
- RG 別に日次/週次/月次で合計し、急増を検知したら通知
Power BI / Power Query で「Resource ID から RG を抜く」例
もし CSV に ARM の Resource ID（/subscriptions/…/resourceGroups/…/providers/…）が入っているなら、リソース グループ名は文字列から抽出できます。以下は Power Query（M）で RG 名を取り出す考え方の例です（列名は環境に合わせて変更してください）。
let
Source = Csv.Document(File.Contents("usage.csv"),[Delimiter=",", Encoding=65001, QuoteStyle=QuoteStyle.Csv]),
Promoted = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),
AddRG = Table.AddColumn(Promoted, "ResourceGroup",
each Text.BetweenDelimiters([ResourceId], "/resourceGroups/", "/"), type text)
in
AddRG一方で、CSV に ResourceGuid しかなく Resource ID が取れない場合、突合が難しくなることがあります。その場合は「サービス名・リージョン・リソース名」など別の軸で突き合わせる、または後述の推定アプローチ（B）を併用して “原因 RG の当たり” を付けるのが現実的です。
アプローチB：Azure SDK + Retail Prices API で RG 別の目安コストを出す
Cost Management が使えない Sponsorship 環境でも、Azure Resource Manager（ARM）経由でリソースの棚卸しはできます。そこで「どの RG に、どの SKU のリソースが、どのリージョンで動いているか」を取得し、料金表（リテール価格）と突き合わせれば、RG 別の概算月額を出せます。
料金表の取得には Azure Retail Prices REST API が使えます。この API は Azure サービスの小売価格（list price）を取得するためのものです。
また、リソース グループとリソース一覧の取得は Azure SDK for Python のサンプルが公開されています。
「推定」が得意なもの / 苦手なもの
| カテゴリ | 例 | 推定しやすさ | 理由 |
|---|---|---|---|
| 固定/準固定の課金 | SQL Database の DTU/ vCore、App Service Plan、API Management など | 高い | SKU とリージョンが分かれば月額が比較的安定 |
| 時間課金 | Virtual Machines | 中 | “起動している時間”で変わるが、常時稼働前提なら目安を作りやすい |
| 利用量依存 | Storage（トランザクション/容量）、帯域（Data Transfer）、Log Analytics など | 低い | 実際の GB/回数がないと正確に出せない |
このアプローチは「請求額を完全再現」する目的には不向きですが、“高い RG をあぶり出す”にはかなり強力です。特に、検証用に作った高額 SKU の PaaS が放置されているケース（例：高い tier の APIM、SQL、分析系サービスなど）を早期発見できます。
Python で「RG 別の概算月額」を集計する最小サンプル
ここでは発想が伝わるように、あえて対応サービスを絞った簡易サンプルを載せます。実務では “自社で使うサービスだけ” を重点的に実装すると、労力対効果が上がります。
前提：認証（サービス プリンシパル or マネージド ID）
Azure の管理 API を読むには、読み取り権限が必要です。最小権限としては、対象サブスクリプションに Reader を付与したサービス プリンシパルを用意するのが一般的です（後述の CAnalyzer もこの方式です）。
概算の流れ
- RG を列挙する
- RG 内のリソースを列挙する
- リソース種別ごとに SKU/リージョンを取り出す（例：VM サイズ）
- Retail Prices API で単価を取得
- 時間課金なら「単価 × 730時間（目安）」、月額固定ならそのまま加算
# これは説明用の疑似コードです（そのまま実行できる完成版ではありません）
from azure.identity import ClientSecretCredential
from azure.mgmt.resource import ResourceManagementClient
import requests
TENANT_ID = "xxxx"
CLIENT_ID = "xxxx"
CLIENT_SECRET = "xxxx"
SUBSCRIPTION_ID = "xxxx"
cred = ClientSecretCredential(tenant_id=TENANT_ID, client_id=CLIENT_ID, client_secret=CLIENT_SECRET)
rm = ResourceManagementClient(cred, SUBSCRIPTION_ID)
HOURS_PER_MONTH = 730
def retail_price(filter_query: str) -> float | None:
url = "https://prices.azure.com/api/retail/prices"
r = requests.get(url, params={"$filter": filter_query}, timeout=30)
r.raise_for_status()
items = r.json().get("Items", [])
if not items:
return None
return float(items[0]["retailPrice"])
rg_totals = {}
for rg in rm.resource_groups.list():
rg_name = rg.name
rg_totals[rg_name] = 0.0
for res in rm.resources.list_by_resource_group(rg_name):
# 例：仮に VM だけ対応するとして…
if res.type.lower() == "microsoft.compute/virtualmachines":
# 実際には VM の size（armSkuName）を別 API で取得する必要があります
vm_size = "Standard_D2s_v3"
region = (res.location or "").replace(" ", "").lower()
# かなり単純化した filter 例（実務では条件調整が必要）
price = retail_price(
f"serviceName eq 'Virtual Machines' and armSkuName eq '{vm_size}' and armRegionName eq '{region}'"
)
if price is not None:
rg_totals[rg_name] += price * HOURS_PER_MONTH
print(rg_totals)ポイントは「自社の “高額になりやすいサービス” から優先的に対応する」ことです。すべての Azure サービスを網羅しようとすると、SKU 判定やメーターの選択が沼になりがちです。
OSS ツール例：CAnalyzer（CAnalyzer）で手早く可視化する
“自作は大変なので、まず結果が欲しい” なら、OSS の CAnalyzer を試す価値があります。Microsoft Q&A の回答でも、Azure Sponsorship で Cost Management が見えないケースの代替として、Azure SDK と Retail Prices API を活用する OSS ツールとして名前が挙がっています。
CAnalyzer は「Consumption API にアクセスできないサブスクリプション向けの Azure cost analyzer」をうたっており、サブスクリプション配下の RG とリソースを走査して、料金 API から価格を引いてレポートを作る、という思想です。
作者の解説記事では、CAnalyzer が サービス プリンシパル（Reader） を使い、設定ファイル（appsettings.json）や環境変数で認証情報を渡して実行できること、レポートを Markdown/CSV で出して HTML 化したり、CI で定期実行してメール送信したりできることが紹介されています。
CAnalyzer 導入のざっくり手順
- サービス プリンシパルを作成し、サブスクリプションに Reader を付与する
- 認証情報（Tenant / Client / Secret / Subscription）を設定する
- CAnalyzer を実行して、RG 別のレポートを出す
- HTML 化して共有（Teams、メール、社内ポータル、Power BI など）
サービス プリンシパル作成例（Azure CLI）
az ad sp create-for-rbac --name "CAnalyzer" --role "Reader" --sdk-auth true運用に落とし込むと強いパターン
| やること | 狙い | おすすめ頻度 |
|---|---|---|
| RG 別「概算月額」レポートを生成 | 高額 RG / 放置リソースの早期発見 | 毎日〜毎週 |
| 前回との差分（増加額）を算出 | “急に増えた RG” を即時に特定 | 毎日 |
| しきい値を超えたら通知 | クレジット枯渇の前に止める | 随時 |
特に Sponsorship では「RG オーナーがポータルで自分のコストを見られない」という運用課題が出やすいので、レポートを自動生成して共有する仕組みがあるだけで現場の自己管理が回りやすくなります。
ガバナンスの小技：コスト“監視”より先に、コスト“発生”を抑える
Cost Management が使えない状況では、監視だけでなく「そもそも高額になりにくい設計」に寄せるのが効果的です。特に Azure Sponsorship はクレジットという上限が明確なので、ガードレールが効きます。
おすすめのタグ設計（RG/リソース共通）
| タグキー例 | 値の例 | 使い道 |
|---|---|---|
| Owner | [email protected] | 通知先・責任者の明確化 |
| Project | myapp | プロジェクト別集計、棚卸し |
| Environment | dev / stg / prod | 検証環境の自動停止・削除対象の判定 |
| CostCenter | CC1001 | 社内チャージバック、部門別集計 |
| ExpireOn | 2026-03-31 | 期限切れ前に削除/縮退 |
Azure Policy で「危険な SKU を使わせない」
たとえば、検証環境で高額 SKU（上位 tier の APIM や分析系クラスターなど）が作られると一気に燃えます。Azure Policy で「特定 SKU の作成禁止」や「タグ必須」をかけておくと、Cost Management がなくても事故をかなり減らせます。
どうしても正確な請求額・Budget が必要なら：将来の移行も視野に
Azure Sponsorship は、クレジットが尽きる/期限が来ると Pay-As-You-Go（従量課金）へ自動移行するケースが案内されています。移行後は、契約形態によっては Cost Management が使えるようになり、Budget やエクスポート、Power BI 連携など “いつもの” コスト管理が戻る可能性があります。
なお、Microsoft for Startups などの制度で付与される Azure Sponsorship クレジットは MCA（Microsoft Customer Agreement）には適用できないと案内されています。つまり「MCA に移行して Cost Management を使う」という正攻法が、クレジット運用中には取りにくいケースがあります（この場合は本記事で紹介した “集計・推定” の仕組みがより重要になります）。
ただし、Cost Management の数字は「クレジット適用前の推定コスト」ベースである点は変わりません。クレジット残高の管理は、引き続き別途（請求・残高の仕組み）で押さえるのが安全です。
参考リンク（公式/一次情報）
- Cost Management の概要（Microsoft Learn）
- Understand Cost Management data（サポート/非サポートのオファー一覧）
- Azure Retail Prices REST API
- Azure SDK for Python：RG とリソースの一覧取得例
- Azure Credits and Billing FAQs（Microsoft for Startups）
- Q&A：Azure Sponsorship で RG 別コストを見たい
- CAnalyzer（GitLab）
まとめ
Azure Sponsorship では Azure ポータルの Cost Management が使えないケースがあり、RG 別にコストを追うには工夫が必要です。現実解は「Sponsorship ポータルの Usage を集計して実績に寄せる」か、「Azure SDK + Retail Prices API（または CAnalyzer）で概算を出してガードレールにする」か、そして可能なら “Cost Management が使える契約形態へ寄せる” という三段構えです。クレジットは有限なので、まずは RG 別の見える化を作り、増加の兆候を早めに掴める運用にしていきましょう。
コメント