azure-cost-calculator

Azure Cost Calculator

Azure 公開価格 API を使用した決定論的な Azure コスト見積もりです。価格を推測せず、必ずスクリプト経由でライブ API に問い合わせてください。

ランタイムの検出

利用可能な環境に応じて、スクリプトのランタイムを選択してください。

ランタイム	条件	価格取得スクリプト	探索スクリプト
Bash（推奨）	curl と jq が利用可能	scripts/get-azure-pricing.sh	scripts/explore-azure-pricing.sh
PowerShell 7+	pwsh が利用可能	scripts/Get-AzurePricing.ps1	scripts/Explore-AzurePricing.ps1
Windows PowerShell 5.1	powershell.exe が利用可能（Windows のみ）。-ExecutionPolicy RemoteSigned が必要です（重要なルール 6 を参照）。	scripts/Get-AzurePricing.ps1	scripts/Explore-AzurePricing.ps1

どちらも同一の JSON 出力を生成します。Bash のフラグは、PowerShell の -PascalCase パラメーターに対応する --kebab-case 形式を使用します（例：-ServiceName → --service-name）。

宣言型パラメーター

サービスのリファレンスファイルでは、クエリパラメーターを Key: Value のペアで指定します。Bash の --kebab-case または PowerShell の -PascalCase フラグに変換し、スペースを含む文字列値は引用符で囲んでください。パラメーターの全表、変換例、出力形式については、workflow.md を参照してください。

ワークフロー

Phase 1: 分析（API クエリなし）

1. 解析：ユーザーのアーキテクチャから、リソースの種類、数量、サイズを抽出します

2. 確認：次のいずれかに該当する場合は、処理を中断し、続行する前に質問します。

   • リソースがカテゴリには該当するものの、具体的なサービスが特定されていない（例：「データベース」）場合 → 2～4 個の選択肢を提示します
   • リソースの数、サイズ／ティア、またはワークロードの規模が不明な場合 → 詳細を尋ねます
   • リソースの想定月間ボリューム（転送／取り込みデータ量（GB）、トランザクション、リクエスト、メッセージ、トークン、ユーザー／デバイス）が不明な場合 → 推定ボリュームを尋ねます
   • 複数のモデルや機能を持つサービス（例：Azure OpenAI、AI Services、Defender for Cloud）で、モデルまたは機能のバリエーションが指定されていない場合 → どれを使うか尋ねます（コストが 15～30 倍変わることがあります）
   • ユーザーがホスティングモデルを指定せずに目標を説明している場合（例：「Web アプリ」） → トレードオフを含む 2～3 個の選択肢を提示します
   • 不足している情報はすべて 1 回のプロンプトにまとめます。妥当な選択肢（例：「月 100 GB ですか？」「GPT-4o と GPT-4o-mini のどちらですか？」）を具体的に提示します。質問は最大 1 回までとします。ユーザーが特定のパラメーターへの回答を控えた場合は、Safe-default の不足情報に限り安全なデフォルトを適用し、その旨を明示します。Never-assume の不足情報が残る場合は、処理を進めず、入力が不足しているため推定できない項目を伝えます。

3. shared.md の検索ワークフローに従って、各サービスへの参照を特定します。services/**/*<keyword>*.md を glob で検索し、該当が 0 件、または複数件あって曖昧な場合は、service-routing.md でサービス名／別名を grep し、一致した行に埋め込まれているパスを開きます

4. 一致したサービスファイルを読み、billingNeeds を確認して、依存関係をたどります（例：AKS → VMs → Managed Disks）

5. shared.md の Disambiguation Protocol に従って、各パラメーターを分類します。

   • Specified：ユーザーが値を指定しています（そのまま使用します）
   • Never-assume gap：必須パラメーターが不足しています（必ず質問します）
   • Safe-default gap：任意のパラメーターが不足しています（デフォルト値を適用し、明示します）

6. 仕様の確認：次の概要を提示します。

   サービス	指定済み	不足（質問する項目）	デフォルト（適用する項目）

   • Never-assume のパラメーターが 1 つでも不足している場合 → 続行する前にユーザーへ質問します
   • Safe-default の不足情報のみが残っている場合 → デフォルト値を明示し、Phase 2 に進みます
   • 単一サービスの簡略化：すべてのパラメーターが指定されている単一サービスの見積もりでは、この仕様確認テーブルを省略します。Phase 2 の「前提条件」ブロックは引き続き必須です

Phase 2: 見積もり

7. クエリ：サービスファイルのパラメーター、ユーザー入力、解決済みのデフォルト値を使用して、サービスごとに料金計算スクリプトを実行します
8. 計算：サービスファイルのコスト計算式を適用し、数量を乗じます
9. 計算を検算：明細項目ごとに、実際の数値を使って計算式を書き直し、計算結果を確認します。途中の計算で 10 を超える数値を 2 つ掛け合わせる場合は、手順を分けて計算します（例：14.5 × 640 → 14 × 640 → 10 × 640 = 6,400; 4 × 640 = 2,560; subtotal = 8,960; 0.5 × 640 = 320; total = 9,280）。複数桁の計算を暗算に頼ってはいけません。
10. 提示：次の内容を含めて見積もりを出力します。

• 前提条件ブロック（shared.md の Disambiguation Protocol を参照）。料金の数値より前に記載します
• 明細項目：サービス、単価、数量／時間、月額費用
• 合計：すべての明細項目の月額費用を個別に再合計します。差異がある場合は、再合計した値を使用します

見積もり後の反復

見積もりの提示後、ユーザーは変更（リージョンの切り替え、RI の追加、インスタンスのサイズ変更、サービスの追加／削除）を依頼できます。影響を受けるクエリのみを再実行し、ワークフロー全体を最初からやり直す必要はありません。

リファレンス索引（必要に応じて読み込む）

条件	読むファイル
常に（エントリーポイント）	references/shared.md：定数、カテゴリ索引、別名検索
クエリの結果が0件、またはデータが正しくない	references/pitfalls.md：トラブルシューティングと注意点
ユーザーが予約インスタンスまたは節約プランについて質問した場合	references/reserved-instances.md
米ドル以外の通貨、またはeastus以外のリージョン	references/regions-and-currencies.md
ユーザーがプライベートエンドポイントまたはプライベートアクセスを希望する場合。PEの意図をユーザーに確認してください	references/services/networking/private-link.md：PEの料金、references/services/networking/private-dns.md：DNSゾーンの料金
ファイル検索の結果が0件、または曖昧な場合	references/service-routing.md：名前／別名をgrepで検索し、一致した行に埋め込まれたパスを開きます。ファイル全体は読み込まないでください
スクリプトを初めて実行する場合、またはパラメーターに詳しくない場合	references/workflow.md：スクリプトのパラメーターと出力形式

重要なルール

1. 価格を推測しないでください：必ずライブ API に対してスクリプトを実行してください
2. ユーザーのコンテキストから通貨とリージョンを推定してください：指定がない場合は、ユーザーに確認するか、USD と eastus をデフォルトとして使用してください
3. 決めつける前に確認してください：必須パラメーターが曖昧、または不足している場合は処理を止め、確認してユーザーに質問してください。決して、決めつけ禁止のパラメーターに暗黙のデフォルト値を設定しないでください。リクエストのレベルでは、Step 2 の確認項目（たとえば月間ボリューム、データ転送量、モデル／機能のバリエーション）を使用してください。パラメーターのレベルでは、shared.md の権威ある「曖昧さの解消プロトコル」表を使用してください。
4. デフォルトの出力形式は Json です：エージェントから見えない Summary は決して使用しないでください
5. サービスの参照ファイルは必要な場合にのみ読み込んでください：ユーザーの問い合わせに直接必要な references/services/ 内のファイルのみ読み込んでください。特定のファイルを見つけるには、ファイル検索ワークフロー（Step 2）を使用してください。
6. PowerShell：-Command ではなく -File を使用してください：スクリプトは pwsh -File または powershell.exe -File で実行してください。Linux／macOS では、bash がインラインコマンドの OData 引用符を取り除きます。PS 5.1 の注意事項： (a) powershell.exe を使用する場合は、必ず -File の前に -ExecutionPolicy RemoteSigned を追加してください。デフォルトの Windows ポリシーでは、スクリプトの実行が警告なしにブロックされます。(b) 配列パラメーター（例：-Region 'eastus','australiaeast'）を渡す場合は、-File モードでは PowerShell の式構文が解析されず、配列が単一の文字列にまとめられるため、-File ではなく -Command を使用してください。
7. 正確なカテゴリー名を使用してください：項目は、shared.md に記載されている Category Index の名前（例：「Compute」、「Databases」、「AI + ML」）をそのまま使って分類してください。言い換えたり、省略したり、名前を変更したりしないでください。
8. ユーザーが指定したリソースに範囲を限定してください：ユーザーのアーキテクチャに明示的に記載されたリソースのみを含めてください。billingNeeds の関連リソースは、その数量が指定されているか、サービスファイルに記載されている場合に限り料金を算出してください。それ以外の場合は、別途課金される依存関係として一覧に記載し、合計から除外してください。指定されていない billingNeeds の数量は、決めつけ禁止事項の不足には該当しません。この例外は privateEndpoint のサブリソースには適用されません。
9. MeterId：ユーザーがメーター ID をリクエストした場合は、--include-meter-id ／ -IncludeMeterId を追加してください。追加の API 呼び出しは不要です。

サービスファイルのメタデータ

YAML フロントマターのフィールドです。任意のフィールドではデフォルト値の省略が可能で、省略するとデフォルト値が適用されます。

フィールド	必須	デフォルト	処理
billingNeeds	-	省略	一覧に記載された依存サービスを読み取り、数量がわかるものは料金を計算し、その他は別途課金として一覧に記載します
billingConsiderations	-	省略	計算前に、一覧に記載された料金要因についてユーザーに確認します
primaryCost	✔	-	費用をすばやく把握するための、1 行の料金概要
apiServiceName	-	省略	API クエリでは serviceName の代わりに使用します
queryServiceNames	-	省略	許可される追加のクエリパターン ServiceName 値
hasMeters	-	true	false → API をスキップし、「既知の料金」テーブルを使用します
pricingRegion	-	regional	global → Region: Global、api-unavailable → API をスキップ、empty-region → リージョンを省略
hasKnownRates	-	false	true → ファイルに手動の料金テーブルが含まれます
hasFreeGrant	-	false	true → コスト計算式から無料枠分を差し引きます
privateEndpoint	-	false	true → networking/private-link.md を介して PE の費用を集計します

あらゆるクエリでの注意点

以下はすべてのクエリに適用されます。

1. serviceName とすべてのフィルター値は大文字と小文字を区別します：サービス参照ファイルの正確な値を使用してください
2. フィルターなしのクエリでは、複数の SKU バリエーションが返されます：必要なバリエーションに絞るため、必ず productName／skuName でフィルターしてください
3. 複数のメーターを持つリソースには個別のクエリが必要です：-MeterName を使用して、メーターごとにクエリを実行してください

一括見積もりモード

3 つ以上のサービスを見積もる場合は、トークン消費を抑えるため、次のルールを使用します。

1. 部分読み込み：各サービスファイルのセクション見出し（^## ）を grep し、## Query Pattern セクションがどこで終わるか（次の ## 見出し）を確認してから、1 行目からその境界までを読み込みます。これにより、ファイルの残りを読まずに YAML フロントマター、トラップ、Query Pattern 全体（すべてのメーター）を取得できます。
2. フロントマターによるルーティング：YAML メタデータを使って不要な作業を省略します（API をスキップする、serviceName を置き換える、grants/PE を適用する）。上記の Service File Metadata テーブルを参照してください。
3. 全体読み込みの条件：部分読み込みでクエリパターンが見つからない場合、デフォルト以外の設定、結果が 0 件または想定外の場合、あるいは billingConsiderations が適用される場合です。
4. クエリの並列実行：独立したサービスのクエリは並列で実行します。ただし、API のレート制限を避けるため、同時リクエストは 3～5 件に制限します。5 つを超えるサービスをクエリする場合は、開始をバッチに分けてずらします。
5. 参照資料の重複読み込みを省略：shared.md と pitfalls.md はサービス間で読み直さず、最初に一度だけ読み込みます。
6. 段階的な情報集約：各サービスのクエリ結果が返るたびに、次へ進む前に次の形式で要約行を出力します。 | Category | Service | Resource | Unit Price | Unit | Qty | Monthly Cost | Notes | 複数のメーターを持つサービスは、明細ごとに 1 行を出力します。すべてのクエリが完了したら、集約した行から最終見積もりを作成します。全体読み込みの条件に該当する場合を除き、情報を集約済みのサービスファイルは読み直しません。見積もり後の反復処理でサービスを再クエリした場合は、対応する集約行を置き換えます。
7. コンパクトな出力：バッチクエリには OutputFormat: Compact（または Bash では --output-format Compact）を使用します。Compact では、コスト計算に必要な 9 つのフィールド（MeterName、ProductName、SkuName、UnitPrice、UnitOfMeasure、MonthlyCost、Currency、ReservationTerm、TierMinUnits）のみが返されます。クエリのエコーやサマリーブロックは含まれません。--include-meter-id を指定すると、Compact には 10 番目のフィールドとして MeterId も含まれます。想定外の結果のデバッグや、サービスファイルで Compact のフィールドセットに含まれないフィールドが必要な場合は、完全な Json 形式を使用します。