はじめに
前回の記事（AWS Organizationsを使ったまま請求代行を検討する時の技術チェックリスト）で、AWS Organizationsを使っていても請求代行を諦める必要はない、という話を書きました。ただ、Organizations対応が確認できたとしても、それで評価が終わるわけではありません。むしろそこからが本題で、権限・割引の実質値・契約条件・導入スケジュールと、契約後に「思っていたのと違った」となりやすい論点がまだいくつも残っています。
今回はその続き、Organizations対応の確認が終わった前提で、契約前に潰しておきたい技術的な論点をチェックリストの形でまとめます。営業の場に持っていって、そのまま質問リストとして使ってもらえるように書きました。
📝 立場の開示：筆者はクラウドコスト合同会社 (CloudCost) で Google Cloud / AWS の請求代行とコスト最適化サービスを担当しています。本記事では自社サービスにも軽く触れますが、競合各社の記述は公開情報に基づく事実ベースで書いており、特定のサービスを売り込む意図はありません。技術的な内容として読んでいただければ幸いです。また、公開情報や実務に基づいて得た知識・情報を元に書いていますが、もし何か誤りがある場合はご指摘お願いします。
TL;DR（チェックリストの全体像）
- ✅ アクセス権限のスコープ — 何の権限が必要で、ルートアカウントは誰が持つか
- ✅ 割引・コミットメントの扱い — 既存RI/SPはどうなるか、割引は乗算か加算か、EDPへの影響は
- ✅ 契約条件 — 手数料モデル、最低契約期間、デポジット返金条件
- ✅ 現実的な導入スケジュール — マーケティング上のレンジではなく具体的な営業日数
（Organizations互換性そのものの確認方法は前回の記事にまとめてあるので、本記事では割愛します。）
以下、それぞれ深掘りします。
1. アクセス権限のスコープ
必要な権限は事業者によって差があります。Cost Explorerの読み取り権限だけで済むところもあれば、課金コンソールへのアクセスが必要なところ、フルの管理者・ルート権限を求められるところまで幅があります。
チェック項目：
- 具体的にどのIAMロール・権限境界を求められるか（Cost Explorer read-onlyか、課金コンソールアクセスか、フル管理者権限か）
- オンボーディング後、ルートアカウントの所有権は誰が持つか（自社のままか、ベンダー側に移るか）
- MFAの再登録や既存IAMユーザー・ロールの扱いに影響はあるか
注意したいのは、「請求代行＝みんなルート権限を渡す必要がある」と決めつけないことです。以前の記事でも触れた通り、権限提供不要のモデルを取っている事業者も実際に存在します。ここは決めつけずに、各社に個別に聞くべき質問として扱ってください。
参考までに、「最低限これくらいの権限で十分では」というたたき台のポリシー例を置いておきます。実際にベンダーに「このスコープで足りますか？」と聞く材料として使えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BillingReadOnly",
"Effect": "Allow",
"Action": [
"ce:Get*",
"ce:Describe*",
"ce:List*",
"aws-portal:ViewBilling",
"aws-portal:ViewUsage",
"invoicing:Get*",
"invoicing:List*"
],
"Resource": "*"
},
{
"Sid": "OrganizationsReadOnly",
"Effect": "Allow",
"Action": [
"organizations:Describe*",
"organizations:List*"
],
"Resource": "*"
}
]
}
あくまで議論の出発点としての例です。実際に付与する権限は、ベンダーが説明する要件と照らし合わせて個別に確定してください。
2. 割引・コミットメントの扱い
既存のRI/Savings Plansはどうなるか
移行のタイミングで既存のReserved InstancesやSavings Plansが「引き継がれるのか」「宙に浮くのか」「買い直しが必要になるのか」は事業者ごとに扱いが違います。
チェック項目：
- 既存RI/SPは移行後も引き続き適用されるか
- 適用されない場合、残存期間分はどう扱われるか（返金・無効化・自己利用継続など）
- 新規のRI/SP購入は今後どちらが主導するか
割引は乗算か、加算か
これはGoogle Cloud側の記事（Google Cloudのコスト削減で見落とされがちな「割引の二重構造」を整理する）で詳しく書いた内容と同じ考え方が、AWS側にもそのまま当てはまります。「RI/SPで40%オフ、さらに代行事業者の割引10%」と聞くと合計50%オフに見えますが、実際には乗算で効きます。
1 - (1 - 0.40) × (1 - 0.10)
= 1 - 0.60 × 0.90
= 1 - 0.54
= 0.46
→ 実質46%引き（50%引きではない）
「合計何%引きか」だけでなく、どの割引の上にどの割引が乗るのかを事業者に確認してください。
AWS EDP（Enterprise Discount Program）への影響
すでにEDPを結んでいる、または検討中の場合は特に重要な項目です。AWSと直接契約することで受けられる大口割引プログラムが、請求代行を利用することで適用条件が変わったり対象外になったりするケースがあります。これは請求代行モデル全体に共通する、あまり語られないデメリットなので、EDP対象の規模感の会社は必ず確認してください。
チェック項目：
- 現在または検討中のEDPは、請求代行の利用によって条件が変わるか
- EDPと請求代行は併用できるか、どちらか一方を選ぶ必要があるか
3. 契約条件
料金モデルは大きく3パターンに分かれます。
| モデル | 概要 |
|---|---|
| 従量手数料型 | AWS利用額に対して数%〜十数%程度の手数料を上乗せ |
| 定額型 | 利用額によらず月額固定の手数料 |
| 割引相殺型 | 事業者側のボリュームディスカウントと手数料を相殺する形で提示 |
チェック項目：
- 上記のどのモデルか、あるいは組み合わせか
- 最低契約期間はあるか、途中解約の違約金はあるか
- デポジットの金額基準（例：直近請求額の◯ヶ月分）と、解約時の返金条件・返金までの期間
4. 現実的な導入スケジュール
見積り段階で提示される期間はあくまで目安であることが多いです。契約後、実際に割引が適用されるまでの営業日数を、レンジではなく具体的な数字で聞くようにしてください。
チェック項目：
- 問い合わせから契約までの標準的な営業日数
- 契約からデポジット支払い、アカウント連携（招待）までの営業日数
- 上記が遅延した場合の連絡体制・エスカレーション先
まとめ：コピペ用チェックリスト
以下、そのまま持ち込んで使える形でまとめておきます（Organizations互換性のチェックは前回の記事のものと合わせて使ってください）。
□ アクセス権限のスコープ
□ 必要な権限の具体的な範囲（Cost Explorerのみ / 課金コンソール / フル管理者）
□ ルートアカウントの所有権は移行後どちらにあるか
□ 割引・コミットメントの扱い
□ 既存RI/SPの扱い（引き継ぎ / 失効 / 買い直し）
□ 割引は乗算か加算か、実質割引率はいくらか
□ EDPとの併用可否・条件変化
□ 契約条件
□ 料金モデル（従量 / 定額 / 割引相殺）
□ 最低契約期間・解約違約金
□ デポジット金額と返金条件
□ 現実的な導入スケジュール
□ 契約までの営業日数
□ 契約〜割引適用開始までの営業日数
Organizations対応さえクリアすれば安心、というわけではなく、実際には契約条件や割引の実質値の方が後々効いてくることも多いです。上のチェックリストを埋めていくと、「このベンダーは実際にうちにとって得なのか」がかなりはっきり見えてくるはずです。
弊社（クラウドコスト）もAWS・Google Cloudの請求代行を提供していますが、この記事はあくまで評価軸の整理が目的です。上のチェックリストは他社を検討する際にもそのまま使ってください。
質問やフィードバックがあればコメントでお気軽にお願いします。