実案件14件のうち、割引対象額を算定できたのは9件だった — 残り5件を止めていた3つの欠落

「請求書を見せていただければ、いくら下がるか試算します」——リセラーはだいたいこう言います。当社もそう言っています。

ただ、実際にやってみると、そもそも試算に入れられない案件が一定の割合で出ます。 資料が届かない、届いたけれど必要な列がない、そもそも比較対象になる請求実績が存在しない。理由はいくつかありますが、どれも「見積の前段で止まる」という点では同じです。

今回はそこを数えます。2026年に扱った実案件14件を、割引対象額を算定できたか／できなかったかの2値で分類しました。結論から書くと、算定できたのは14件中9件（64%）。残り5件は3つの理由に分かれました。

前回の記事との関係

前回（実案件9件の請求書で、リセラー割引の分母は請求総額の何%だったか）と数字が近いので、先に切り分けておきます。この2本は母数も論点も違います。

つまり前回の9件は、今回の14件の内側にあります。前回は「9件の中の精度」、今回は「9件に入れなかった5件」の話です。 前回の記事にある比率や中央値は、この記事では扱いません。

何をどう数えたか

母数は、2026年に当社で見積・分析の対象になった**実案件14件（13社）**です。1社がAWSとGoogle Cloudの両方を対象にしているため、社数より件数が1多くなっています。内訳はAWS 10件、Google Cloud 4件です。

各案件を、次の1点だけで2値にコーディングしました。

○ = 受領した資料から、割引対象額（＝リセラー割引が掛かる分母）を算定できた
× = 算定できなかった

×だったものは、何が欠けていたかで分類しています。この分類がこの記事の中身です。

前提として、割引対象額そのものの定義（何を分母に置き、何を対象外として外すか）はAWS版とGoogle Cloud版の記事に書いたルールをそのまま使っています。この記事はその手前、**「そのルールを適用できるデータが手元にあるか」**の話です。

社名・月額・実額は出しません。出すのは件数と分類だけです。

結果 — 14件中9件、AWSは6/10件、Google Cloudは3/4件

クラウド別の差は、母数が4件と10件なので差として読まないでください。1件動けば25ポイント動きます。読めるのは全体の水準だけで、請求内訳を前提にした試算は、3件に1件くらいは前段で止まる、という程度です。

算定を止めていた3つの欠落

算定できなかった5件は、次の3つに分かれました。

1. 請求内訳そのものが未受領（5件中3件）

最も多いのはこれで、5件中3件。資料の中身の問題ですらなく、授受が完了していないケースです。

3件の止まり方はそれぞれ違いました。1件は概算の見積までは出したものの、内訳の提出依頼の段階で止まったまま。1件は問い合わせフォームでの自己申告（月額レンジ）だけがあり、内訳の授受に入る前段で止まっています。1件は提出手順書を送付済みで、データの到着待ちです。

正直に書くと、この3件は当社側の問題でもあります。 「請求内訳をください」という依頼は、受け取る側からすると「どの画面から、どの権限で、どの形式で出すのか」が分からないと動けません。手順書を送っていてもなお止まっているケースがあるので、依頼の粒度がまだ足りていないということです。

もう1つ、出す側の心理的なハードルもあります。請求内訳は自社のインフラ構成がかなり読める資料です。契約前の相手に出すものとしては重い、という判断は当然あり得ます。当社では請求内訳の前に任意で秘密保持契約を結ぶ選択肢を用意していますが、必須にはしていません（必須にすると、それはそれで前段が1つ増えるためです）。

2. 受領したが金額が入っていない（5件中1件）

1件は、資料は届いたのに算定できませんでした。届いたのは使用量だけが入ったスプレッドシートです。列はサービス名・使用タイプ・使用量合計の3つで、行数は数百行。粒度としては十分に細かいのですが、金額の列がありません。

割引対象額は「金額から金額を引く」計算なので、使用量だけでは分母（請求総額）も分子（対象額）も出せません。使用量から金額を復元するには全SKUの単価表を当てる必要があり、それは請求書を読む作業とは別物です。

これは特殊な事故ではなく、コンソールから出せる出力の中に「使用量だけの形式」が普通に存在することが原因です。エクスポート画面で列を選ぶタイプの出力では、金額の列を含めずに書き出すことができてしまいます。依頼する側が「明細をください」としか言っていないと、この形式で返ってくる余地が残ります。

3. 実績請求が存在しない（5件中1件）

残る1件は、性質が違います。これから新規に構築する環境の費用試算で、インスタンス構成から積算したものでした。既存のAWS請求実績そのものが存在しません。

この場合、リセラー割引の分母を「請求書から」出すことは原理的にできません。積算表から仮の対象額を置くことはできますが、それは請求書の構造を読んだ数字ではなく、構成の前提が変われば動きます。請求実績のある環境と同じ精度では出せないということを、見積の前に共有しておく必要があります。

新規構築案件が悪いという話ではありません。「請求書を見せてください」というアプローチが最初から成立しない類型がある、というだけです。

どの形式が届いたときに算定できたか

受領した資料の形式ごとに、算定できたかを並べます。ここが次の記事（請求内訳が出せずに止まった5件に、1つずつ対応する）に直接つながる部分です。

金額が入った形式は、どれで届いても算定自体はできました。 PDFでもCSVでも、メール本文に貼られたサービス別の月次一覧でも通っています。逆に言えば、形式の綺麗さは算定可否を分けていません。 分けたのは「金額が入っているか」と「実績か」の2点だけでした。

「じゃあPDFで十分か」というと、そうとは限りません。次の節がその話です。

なお、AWSの明細エクスポートは現在 AWS Data Exports という機能名で、その標準的な出力形式が CUR 2.0（Cost and Usage Report 2.0） です。従来の「Cost and Usage Report（CUR）」という呼び方は、現在のドキュメント上は旧来の名称・形式として扱われています（AWS公式ドキュメント、2026年8月確認）。Google Cloud側は Cloud Billing コンソールの Cost table と Reports、およびBigQueryへの Cloud Billing data export to BigQuery が該当します。依頼するときは、この名前で指定したほうが早く届きます。

「算定できた」と「確定できた」は別

ここは誤解されやすいので分けて書きます。この記事の9件は「算定できた」であって、「1つの数字に確定できた」ではありません。

算定できた9件のうち、3件は幅または見込値でしか出せていません。 内訳は、請求書だけではReserved Instancesの内訳が分離できなかったもの、コスト削減プログラムの中身（Committed Use Discountか無料枠か）が判別できなかったもの、月中の実績を月次に換算したものです。前の2件については前回の記事に、なぜ請求書だけでは確定しないのかを書いています。

つまり資料の充足には2段階あります。

第1段階: 算定できるか   … 金額が入った実績データが届いているか（この記事）
第2段階: 確定できるか   … 予約・コミット型の内訳が分離できるか（前回の記事）

第1段階を通っても、第2段階でコンソール側の情報が追加で要ることがあります。 確定請求書のPDFが4件すべてで算定できているのに、そのうち1件は幅でしか出せなかったのはこのためです。PDFは第1段階には十分で、第2段階には足りないことがある、という関係になっています。

自分の請求書で試算できるかを判定する

見積を依頼する前に、手元の資料で試算できるかは自分で判定できます。3つ確認するだけです。

1. 金額が入っているか。 使用量・リクエスト数・時間数だけの出力になっていないか。列に通貨単位の値があるかを見る
2. 実績か、見込みか。 実際に請求された月のデータか、構成から積んだ試算表か。後者なら請求書ベースの試算は成立しない
3. 予約・コミット型の割引を使っているか。 Savings Plans・Reserved Instances・Committed Use Discountのいずれかを持っている場合、請求書だけでは分母が確定せず、コンソール側の情報（AWSならCost Explorerの Charge type 別内訳、Google CloudならSKU単位の明細）が追加で要る可能性が高い

この3点を実際にコンソールのどの画面から確認・出力するかは、次の記事にAWS / Google Cloudそれぞれの手順と必要権限を書いています。

1と2が満たされていれば、形式は問いません。 この集計でも、PDF・CSV・メール本文の一覧のいずれでも算定は通っています。「綺麗なCSVを用意してから相談する」必要はありません。

3に当てはまる場合も、相談を止める理由にはなりません。幅で出したうえで、確定に必要な情報をお伝えするというのが実際の進め方です。

この集計の限界

• n=14は少ないです。「業界の傾向」として扱わないでください。手元の14件がそうだった、以上のことは言えません
• クラウド別の割合（AWS 6/10、Google Cloud 3/4）は差として読めません。 Google Cloud側は母数が4件しかありません
• 「未受領」は最終状態ではありません。 3件のうち一部は現在も進行中で、資料が届けば算定できる側に移ります。この集計は2026年8月時点のスナップショットです
• 母集団に偏りがあります。 問い合わせや紹介を経て見積の話まで進んだ案件だけが母数なので、そもそも請求内訳の提出に強い抵抗がある層は最初から入っていない可能性があります。実態の「止まる率」は、この64%より低く出ている（＝止まる案件はもっと多い）ほうに振れているとみるのが自然です
• 当社側の依頼の仕方が変われば数字は動きます。 特に「未受領3件」は顧客側の属性というより、依頼の粒度の問題を含んでいます

まとめ

• 実案件14件（13社／AWS 10・Google Cloud 4）のうち、割引対象額を算定できたのは9件（64%）
• 算定できなかった5件は3分類 — 請求内訳そのものが未受領3件／金額が入っていない1件／実績請求が存在しない1件
• 最多は「未受領」。資料の中身以前に、どの画面からどう出すかが伝わっていないことが原因の一部
• 金額が入った実績データであれば、形式は問わず算定できた。 PDF・CSV・メール本文の一覧のいずれでも通っている
• 逆に、金額列のない使用量だけの出力と新規構築の試算表は、行数が十分でも算定できない
• 算定できた9件でも3件は幅・見込値。算定できることと確定できることは別の段階

「請求書を見せてください」と言われたとき、確認すべきは形式ではありません。金額が入っているか、実績か、コミット型の割引を持っているか。 この3点だけです。

CloudCutの場合

当社がお出ししているのはAWS / Google Cloudの請求代行を通じた10%以上の削減¹ですが、この10%は請求総額に対する削減率で、割引率そのものが掛かるのは請求総額ではなく割引対象額です。したがって、対象額を算定できないうちは削減額の提示もできません。この記事の5件に対しては、金額の入った見積をお出ししていません。

資料が揃わない段階でのご相談も承っています。「うちの請求書だと何が足りないか」の判定だけでしたら、お切り替えのご検討とは切り離してお答えできます。請求内訳を出す前に秘密保持契約を結びたい場合は、そちらを先に締結する形も可能です（必須ではありません）。

ご相談はこちらから。