数量課金のシステム費用は妥当か｜段階見積もりを5つの軸で検証する

数量課金でシステム費用が決まる見積もりを渡されたとき、経営側が確かめにくいのは金額そのものではありません。「商品数が増えたので」「ユーザー数が1段階上がったので」「デバイスが1,000台になったので」という説明が、どの作業のどの費用に効いているのかが書かれていないことです。数量Xが2倍になったとき、本当に2倍になる費目と、まったく変わらない費目が、1枚の見積書の中に混ざっています。

この記事は、その混ざったものを5つの軸へ分けるための枠組みです。特定の業種の話ではなく、商品数・ユーザー数・店舗数・画面数・言語数・デバイス数・サイト数・ロボット数のいずれにも同じ手順を当てられるように書いています。

TL;DR｜数量が費用に効くかは、5つの軸で分かれる

数量Xが費用を動かすかどうかは、次の5つのどれに当たるかで決まります。先に「比例しないのが正しい」と決めつけないでください。 比例するのが妥当な費目は実在します。

判断の順番は、まず見積書の1行ずつをこの5軸のどれかへ割り当てることです。1行が複数の軸にまたがっていて、その内訳が示されていないなら、それは分解されていない行です。分解を頼むだけで、金額の話をする前に議論が進みます。

商品数・店舗数・画面数・ロボット数など、種類別の詳しい記事は、記事中盤の「5軸×4ケースの早見表」の直後にまとめてあります。

割り当ててみて、効き方が上表の定義と食い違う行が出てきたら、それは数量Xを取り違えている行です。たとえば試験費が対象ユーザー数ではなく権限パターン数で決まっているなら、軸4に置きつつ「数量Xはユーザー数ではない」と読みます。この記事ではそういう行を軸外（数量Xの取り違え）と呼びます。軸は残したまま、数量Xだけを読み替えます。 数量課金の見積書でもっとも金額が動くのは、実はこの取り違えです。

そして数量課金を名乗る契約なら、増えたときに上がる条件だけでなく、減ったときに下がる条件が書かれているはずです。上がる方向しか書かれていないなら、それが本当に数量連動と呼べるのかを確認する材料になります（詳細は後述の「数量が減ったとき、費用は下がるのか」）。

「数量が増えたから」という説明が、なぜ確かめにくいのか

数量課金の説明が確かめにくい理由は、ベンダーが不誠実だからではありません。数量Xという1つの数字が、見積書の中で複数の別々の数に化けているからです。

たとえば「デバイス1,000台」という1つの数字は、次のように分かれます。

• SIM 1回線あたりの初期費用と基本料金 → 1,000倍
• 管理画面の改修 → 1回（台数に関係しない）
• クラウド側の受信処理 → 台数だけでは決まらず、送信頻度とペイロードで決まる

同じ「1,000台」から、比例するもの・1回で済むもの・そもそも台数では決まらないものが、同時に出てきます。見積書に「デバイス数1,000台　◯◯円」と1行で書かれていると、この3種類が1つの数字に押し込まれて、どれがどれだけ効いているのか分からなくなります。

だから確認すべきは「高いか安いか」ではなく、その行の金額を決めている数は本当にデバイス数なのかです。

見積書では、数量課金はどう書かれているか

実際の見積書で数量連動が現れる書かれ方は、おおむね次の5パターンに収まります。左が見積書の記載、右が確認すべきことです。

これらに共通するのは、課金単位（数量）と原価単位（作業や実費）が同じだと仮定して書かれていることです。多くの場合その仮定は一部でしか成り立ちません。

見積書全体の分解手順そのものについては、開発費用の相場と見積もり妥当性の判断ガイドで工程・成果物・工数の側から扱っています。この記事は、そこに数量という軸を1本足すものだと考えてください。

数え方が違うと、同じ「1台」でも金額が変わる

5つの軸へ分ける前に、先に確かめることがあります。見積書に書かれた数量と、課金の対象になる数量は、しばしば別物です。

AWS IoT Coreの料金ページには、MQTTおよびHTTPのメッセージングについて次の記載があります（2026年8月25日取得。LoRaWANやSidewalkは別建ての料金体系です）。

送受信できるメッセージのサイズは最大 128 KB です。メッセージ数は 5 KB ごとに増加します。例えば、8 KB のメッセージは 2 件のメッセージとして計算されます。

同じ「1回の送信」でも、ペイロードが5KBを超えれば2件として数えられます。デバイス数が同じでも、1回に送るデータ量を変えると請求は変わります。

同じページのAWS IoT Core for LoRaWANの節には、ファームウェア更新（FUOTA）について「1,000 台のデバイスのグループに FUOTA タスクを作成すると、1,000 件のタスク分の料金が発生します」とも書かれています（同節には「最初の 100 件の FUOTA タスクを無料で利用できます」との併記もあります）。こちらは台数にそのまま比例します。同じ製品の同じ料金ページの中に、台数に比例する費目と、台数では決まらない費目が同居しているわけです。ただしこのFUOTAの課金ルールはLoRaWAN向けの節に書かれたものなので、他の接続方式にそのまま当てはめることはできません。

翻訳でも同じことが起きます。Cloud Translationの料金ページは、一括翻訳について次のように定義しています。

テキストとドキュメントの一括翻訳の場合、処理される文字数またはページ数は、ソース言語の文字数またはページ数にターゲット言語の数を乗じたものになります。

同ページの例では、5,000文字を2つのターゲット言語へ翻訳すると、処理される文字数の合計は10,000文字です。言語数がそのまま掛け算になることが明記されています。

だから確認質問の1問目は、金額ではなく数え方です。「その費用の数量は、何を1と数えていますか」と聞いてください。数え方が確定してはじめて、次の5つの軸へ分けられます。

5つの判断軸｜数量Xがどこに効くのかを分解する

軸1. 人手作業に効くか（登録・翻訳・設定・現地訪問）

人が1件ずつさわる作業は、数量にほぼ比例します。 ここは比例が妥当な代表例です。

分かりやすいのが翻訳です。日本翻訳連盟（JTF）が公開している「翻訳料金（クライアント企業の翻訳発注価格）の目安」では、単価の単位が英日は原文の英語1ワードあたり、日英は和文原稿の1文字あたりと定義されています（2026年8月25日取得、税別）。

原文が同じなら、対応言語を2つに増やせば翻訳量は2倍になります。ここに「1言語増えるごとに費用が増えるのはおかしい」という反論は成り立ちません。

ただしJTFはこの表について、「一般的な実例の平均値を分野ごとに示した翻訳料金の目安」であり、「専門性、難易度、翻訳量、納期、原文・訳文のデータフォーマットや処理の種類と程度、そして品質レベルなどによって大幅に異なります」「受注側の価格方針などによっても差が生じます」と明記しています。支払うべき金額の目安ではなく、単価を決めている変数の一覧として読んでください。 分野によって英日と日英の高低が逆転していること（特許明細書は日英のほうが高い）も、単価が分野と方向で決まっていることを示しています。

同じ考え方が、商品登録代行、店舗ごとの初期設定、拠点ごとの教育、デバイスの現地設置にも当てはまります。確認すべきは比例するかどうかではなく、1件に含まれる作業内容が何かです。 同じ「1件」でも、整形済みデータを流し込むのか、紙資料から起こすのかで作業量は数倍変わります。

軸2. 実費に効くか（ライセンス・通信・従量課金）

第三者へ支払う実費は、数量に比例することが多く、しかも比例が正当です。 ベンダーが利益を乗せているのではなく、そのまま払っている費用だからです。

ただし実費には、見積書からは読み取れない性質が3つあります。

（1）単価は数量で段階的に下がることがある。 Googleが公開しているCloud Translationの料金では、カスタムモデルのテキスト翻訳が次の階段になっています（2026年8月25日取得、米ドル建て。税の扱いは当該ページで確認できませんでした）。

数量が増えるほど1単位あたりは安くなります。数量が2倍になったのに費用も正確に2倍という見積もりが来たら、仕入れ側で効いている逓減がどこへ行ったのかを聞く根拠になります。 ただし、単価が下がらない体系も実在します（後述のkintone）。逓減があるかどうかは、実際に使っているサービスの公開価格で確かめてください。

株式会社ソラコムのIoT SIM料金にも同じ構造があります。plan-KM1の基本料金欄には、使用中（Active）・休止中（Inactive）の状態について「アクティブSIM 100枚まで 121円/月」「アクティブSIM 101枚以上 99円/月」と記載されています（2026年8月25日取得）。なお「表示の金額はすべて税込みです」という注記は同ページのplan-D／plan-K2／plan-DUの表の直下にあり、plan-KM1の表の下では確認できませんでした。

（2）使っていない分にも実費が発生することがある。 同じソラコムの料金ページにある状態別の表では、「休止中」はデータ通信が不可でも基本料金は「あり」、基本料金が「なし」になるのは「解約済み」だけ、と整理されています（plan-D／plan-K2／plan-DUの場合）。数量を減らしても、解約という手続きを踏まなければ実費は下がりません。 「使っていない端末の分は請求されない」と思い込んだまま契約すると、稼働台数と請求台数がずれ続けます。

（3）実費の単価そのものは値切れない。 ここを値引き交渉の対象にすると、ベンダーは別の費目で調整するか、実費を過少に見積もって後から精算することになります。実費部分は、値引きではなく数量そのものを減らせるかで検討するのが筋です。

だからこそ見積書では、第三者へ支払う実費と、ベンダーが提供する役務を必ず分けて書いてもらう必要があります。これは数量課金に限らず、保守費用全般の検証で中心になる論点です。

軸3. システム負荷に効くか（レンジで階段状にしか効かない）

プラン料金や資源の確保単位で決まる部分は、数量が増えても連続的には上がりません。 レンジをまたいだときだけ、階段状に上がります。（同じシステム側の費用でも、通信量や処理件数のように従量で課金される部分は軸2の実費として扱ってください。）

シックス・アパート株式会社のMovableType.netの追加オプションは、この階段が価格表にそのまま出ています（2026年8月25日取得、税込）。

※上記は同ページのオプション表11行のうち7行の抜粋です。原文には「オプションはビジネスプラン以上で追加でき」、上限は「ビジネス・エンタープライズそれぞれプラン内の数を含めた上限値」と明記されています。

ブログを1つ増やしたいときも、買えるのは5単位です。 オプションを購入できるビジネスプランにはブログ15が含まれるので、16個目を1つだけ増やしたい場合も5単位で買うことになり、16個目と20個目は追加費用が同じ550円になります。容量も5GB単位、転送量に至っては250GB単位です。

これは特定サービスの都合ではなく、資源を確保する側の設計が本質的に離散的だからです。ソラコムのplan-DUでも、使用中・休止中の基本料金はDU-10GBが月額1,452円、DU-50GBが月額3,509円、DU-100GBが月額6,534円という3段階で、通信量に応じて連続的に変わるわけではありません（2026年8月25日取得、税込）。

したがって見積書に「利用者が10%増えるのでサーバー費も10%増やします」と書かれていたら、その10%がどのレンジからどのレンジへの移動なのかを聞いてください。 プラン料金や確保単位で決まっている費目なら、レンジをまたいでいなければ増額の根拠が示せないはずで、またいでいるなら10%ではなく段階分の増額になっているはずです。どちらにしても、10%という数字は出てきません。従量課金の部分が混ざっているなら、そちらは軸2として分けて示してもらってください。

軸4. 試験・検証に効くか（実機台数・拠点数）

試験は数量に比例しますが、並列度で頭打ちになります。 ここは「比例が妥当だが、どこまで比例するかに上限がある」という中間の軸です。

Amazon Web Services, Inc.が公開しているAWS Device Farmの料金は、この構造を明示しています（2026年8月25日取得、米ドル建て。税の扱いは当該ページで確認できませんでした）。

• 従量制料金は1デバイス分あたり0.17ドル。同ページは「デバイス分は、使用するデバイス数と自動テストとリモートアクセスセッションの長さによって決まります」と説明しています。つまり台数×時間です。
• 定額プランは1デバイススロットあたり毎月250.00ドル。同ページの説明では、「自動化されたテスト用に Android デバイススロットを10個購入し、100台の Android デバイスでのテストをスケジュールする場合、Device Farm は、選択したデバイスですべてのテストが完了するまで、1度に最大10デバイスでテストを実行します」とされています。

後半が重要です。定額プランなら、100台を試験するのに100スロットは必要ありません。 待ち時間が延びるだけです。つまり定額プランで費用を決めているのは「同時に何台さわるか」であって、対象台数そのものではありません。

ただしこれは定額プランの話です。従量制の課金単位は前掲のとおり「デバイス分」＝台数×時間なので、1台あたりの試験時間が同じなら、費用は対象台数にそのまま比例します。 同じ試験でも、体制を固定して回すのか、台数分の時間をそのまま買うのかで、比例するかどうかが変わります。見積書の試験費がどちらの考え方で組まれているかを確認してください。

同じことが店舗数・拠点数・言語数の受け入れ試験にも当てはまります。100店舗のPOS試験で、100回分の出張費が計上されているなら、何店舗をまとめて確認できるか、リモートで確認できる範囲はどこまでかを聞いてください。 逆に、拠点ごとにネットワーク環境や周辺機器が違うなら、まとめられない理由が明確にあるので、比例に近い形が妥当になります。

OSの数も、この軸に入る数量です。 iOSとAndroidの両方に出すアプリでは、実機での確認とストアへの申請が2つぶん必要になります。どこが2回になり、どこが1回で済むのかはiOSとAndroidの同時開発で費用は2倍になるのかで分解しています。

軸5. 共通基盤か（数量に関係なく1回で済む）

共通基盤の作業は1回で全体に効くので、数量に比例させる根拠がありません。 ここが数量課金でもっとも問題になりやすい軸です。

具体的には次のようなものです。

• 共通機能の改修・不具合修正（全サイト・全店舗・全言語に一度で反映される）
• ミドルウェアやライブラリのパッチ適用
• テンプレート・共通コンポーネントの更新
• 監視設定・バックアップ設定の変更（対象が同一構成の場合）

MovableType.netの料金ページには、「契約はウェブサイト単位となり、1つのアカウントで複数のウェブサイトをご契約いただけます」と記載されています（2026年8月25日取得）。サイト数に比例する課金軸が実在すること自体は事実です。ただしそれは基盤の利用権に対する対価であって、ベンダーが行う保守作業が同じ倍率で増えることを意味しません。

ただし例外があります。待機体制は共有できません。 共通基盤であっても満額に近い費用が妥当になる条件は、ケース3で扱います。

4つのケースで、5軸をあてはめる

ここからは、数量課金がよく問題になる4つのケースに5軸をあてはめます。各ケースの表は「費目／軸／効き方」の3列で統一しており、数量Xを取り違えている行は「軸N＋軸外注記」で示します。

ケース1｜多言語サイトの構築×言語数

1言語目と2言語目以降では費用の構造が違います。

1言語目には、多言語化そのものを可能にする基盤の実装が含まれます。文言をコードから切り出す仕組み、言語切り替えの導線、URL設計、日付・数値・通貨の表示形式、フォント、右から左へ書く言語への対応可否といったものです。これらは言語数に関係なく1回です（軸5）。

2言語目以降で増えるのは次のものです。

法制度対応と税率・課税ルールの2行が要点です。 英語版を1つ足すことと、英語圏3か国で販売することは、費用がまったく違います。見積書が「言語数」で課金しているなら、法制度対応と税率・課税ルールの対応がその中に入っているのか、別なのかを必ず確認してください。ここが曖昧なまま進むと、公開直前に「対象国の表示義務は範囲外でした」という追加見積もりが出ます。

ケース2｜業務システムの保守×ユーザー数

ユーザー数課金では、第三者ライセンス（比例する実費）と、ベンダーの支援費（比例しにくい役務）を分けることが判断の中心になります。

サイボウズ株式会社が公開しているGaroonクラウド版の価格表は、ライセンス側の構造を示しています。価格表は「〜1,000ユーザー」と「1,001〜ユーザー」の2区分で、前者は1ユーザーあたり月額900円・年額10,800円、後者は「お問い合わせください」と記載されています（2026年8月25日取得。同ページに「価格に消費税は含みません」と明記）。同ページには「利用人数10人〜」「1ユーザー単位で契約できます」「5GB×ユーザー数」との記載があり、さらに同ページのよくある質問には「クラウド版 Garoonを1サブドメイン契約する場合、最低ユーザー数は10人です」と明記されています。この製品にも下限があります。

同社のkintoneでは、コースごとに1ユーザーあたりの月額が異なります（2026年8月25日取得。「上記はすべて税抜き価格です」と明記）。

ここから読めることが2つあります。1つは、数量が増えると単価が下がるとは限らないこと。 ワイドコースは最小1,000ユーザーで、1ユーザーあたりはもっとも高い設定です（含まれる機能や上限が異なるため、単価差のすべてが規模によるものではありません）。もう1つは、最小ユーザー数という床があること。 利用者が5人でも、10ユーザー分の費用は発生します。数量を減らしても、床より下には下がりません。

ではベンダーの支援費はどうか。ユーザー数が増えて実際に増える作業は、問い合わせ件数・アカウント発行と棚卸し・権限設計の複雑さ・教育です。このうち問い合わせ件数は、ユーザー数よりも「新規利用者の割合」と「操作の難しさ」で決まります。 3年使っている200人と、今月から使い始めた50人では、後者のほうが問い合わせが多いのが普通です。

したがって支援費がユーザー数に単純比例している見積もりは、導入直後は過少、安定期は過大になりやすいという性質を持ちます。確認すべきは「ユーザー数◯人あたり月◯件までの問い合わせ対応」といった形で、対価の単位が作業量で定義されているかどうかです。

ケース3｜複数サイトの保守×サイト数

同じ仕組みで作った2つ目のサイトに、1つ目と同じ保守費がかかるのは妥当か。答えは「何が独立しているか」によって変わります。

「共通基盤なのだから2サイト目は安くなるはずだ」という主張は、半分しか正しくありません。 2サイトが別々の事業部で運営され、それぞれ別のSLAで、片方の障害中にもう片方の問い合わせを受ける体制が必要なら、満額に近い費用が妥当です。

逆に、2つのサイトが同一構成・同一SLAで、更新も同時に行うなら、増えるのは実費とサイト固有作業だけになります。見積書がどちらの前提で作られているかを、SLAの記載で確認してください。 サイトごとに応答時間や復旧目標が別々に書かれていれば独立、1本しか書かれていなければ共有です。

ケース4｜IoTの保守×デバイス数

IoTでは、実費（通信）と人手作業（現地交換）がいずれもデバイス数に連動します。 比例が妥当な費目が多いぶん、比例しない費目まで一緒に比例させられていても気づきにくいテーマです。

株式会社ソラコムの日本カバレッジ IoT SIMの料金は、「初期費用（契約事務手数料＋SIM発行手数料）、基本料金、データ通信料金の3つから構成されます」と説明されており、初期費用は「1回線（SIM）あたり、送料別」と明記されています（2026年8月25日取得、税込）。1台増えれば1回線増えます。ここに比例しない理屈はありません。

現地交換も同様です。デバイスが1,000台あって年間故障率が1%なら、年10台の交換が発生します。台数が10,000台になれば年100台です。 この作業は人が現地へ行くので、比例します（軸1）。

一方で、比例しないものも同じ見積書の中にあります。

同じ「デバイス1台あたり月額◯◯円」の中に、この8種類が混ざっています。 比例する費目が多いテーマだからこそ、比例しない費目まで一緒に比例させられていないかを確認する価値があります。

なお、現地交換については「比例する」と「一定である」の両方が同時に起きることに注意してください。1拠点に100台ある現場なら、1回の訪問で複数台を交換できます。交換作業自体は台数に比例しますが、移動は拠点数に比例します。見積書が「1台あたりの出張費」で組まれているなら、同一拠点でまとめて対応する場合の扱いを聞いてください。

5軸×4ケースの早見表

ここまでを1枚にまとめます。自社の見積書の各行を、この表のどこに当たるかで仕分けてください。

商品数（EC）と店舗数（POS）、画面数（アプリ）、ロボット数（RPA）についても同じ表が作れます。それぞれの詳細は個別の記事で扱っています。

• ECサイトの開発費は商品数で上がるのか（開発時の商品数）
• ECサイトの保守費用は商品数で上がるのか（稼働後の商品数）
• アプリ開発費用と画面数の関係（共通部品・状態・権限で見る）
• POSシステムの費用と店舗数（現地作業と共通基盤を分ける）
• RPA保守費用とロボット数（変更頻度と失敗対応で見る）

その料金体系が合理的と言えるケース

数量課金が妥当なのは、次の条件を満たしているときです。ここに当てはまるなら、比例していること自体を問題にする必要はありません。

1. 課金対象が実費である。 第三者ライセンス、通信費、従量課金のクラウド利用料など、ベンダーが仕入れているものが数量で決まっている。
2. 課金対象が人手作業で、1件あたりの作業内容が定義されている。 「1件」に含まれる項目数・工程・品質基準が書面にある。
3. 数量が増えると、実際に待機や対応の負荷が増える。 SLAが対象ごとに独立している、拠点が物理的に分散しているなど、共有できない理由がある。
4. 段階の境目に、技術的な根拠がある。 レンジをまたぐと構成が変わる、プランが上位へ移る、といった説明ができる。
5. 数量が減ったときに下がる条件も、同じ契約に書かれている（詳細は後述の「数量が減ったとき、費用は下がるのか」）。

確認が必要なケース｜4状態への仕分け

数量課金の見積もりは、「妥当／不当」ではなく次の4状態で評価してください。判断不能を判断不能のまま残すことが、実務では一番役に立ちます。

高リスクに該当しやすいのは、次の3つです。

• 共通基盤の改修が対象数で掛け算されている。 5サイトあるからパッチ適用も5倍、というもの。
• 段階の境目に根拠がない。 「50ユーザーまで」「100ユーザーまで」という区切りが、ライセンスの区切りともサーバー構成の区切りとも一致していない。
• 減額条項がない。 数量が増えたときの増額だけが定義され、減ったときの扱いが書かれていない。

判断不能に該当した場合、金額を交渉する前に分解を求めてください。 分解されていない見積もりは、高くても安くても検証できません。手元の見積書を行単位で分解するところから始めたい場合は、見積もり内容のAIレビュー（登録不要）で費目の分解と確認質問の生成まで行えます。結果の閲覧までメールアドレスの入力は不要です。

「数量が多いのに安い」ときに疑うこと

数量課金では、高すぎる見積もりより安すぎる見積もりのほうが危ないことがあります。 数量が多いのに総額が抑えられている見積もりは、次のどれかが起きていることが少なくありません。

• 試験が数量に追随していない。 1,000台のデバイスや50店舗のPOSに対して、試験工数が試作機1台分・1店舗分しか入っていない。展開後に個体差や店舗差で不具合が出て、追加費用になる。
• 移行が含まれていない。 既存の商品データ・ユーザーアカウント・デバイス登録情報を新環境へ移す作業が、数量に関係なく「一式」で薄く入っている。
• セキュリティが対象外になっている。 台数や拠点が増えると、権限管理・鍵の配布・ログ保管の要件が変わる。この部分が範囲外のまま総額が安く見えている。
• プロジェクト管理費が入っていない。 拠点数・店舗数が多い案件は、調整だけで工数が発生する。ここが0円の見積もりは、調整を発注側が全部やる前提になっている。

安い見積もりを見つけたときこそ、数量に比例すべき費目が比例しているかを確認してください。 数量課金の議論は「比例させすぎ」を疑うことから始まりますが、逆方向の失敗も同じくらい起きます。

数量が減ったとき、費用は下がるのか

数量課金の契約でもっとも確認漏れが起きるのが、減ったときの扱いです。次の4点を契約書で確認してください。

1. 段階が下がる条件（何を下回れば下位段階へ移るか）
2. 判定のタイミング（毎月・四半期ごと・契約更新時のいずれか）
3. 下限の有無（最小ユーザー数のような床があるか）
4. 解約しないと止まらない費用の有無（休止しただけでは発生し続けるもの）

3と4は実在します。kintoneには最小ユーザー数が設定されています（2026年8月25日取得）。4については軸2で見たとおり、休止しただけでは基本料金が止まらず、解約してはじめて止まる料金体系が実在します。サービス提供元の料金体系にこの構造があるということは、それを組み込んだ保守契約にも同じ床が引き継がれている可能性があるということです。

回答が「一度上がった段階は据え置きです」であっても、それ自体は不当ではありません。ただし、その前提で総額と契約期間を見直す材料にはなります。

同じ「1,000台」でも、見積書はここまで違う

同じ規模の案件に対する2社の見積もりを、5軸で並べてみます。数値は構造の違いを示すための例であり、実在の見積書ではありません。

A社が高いとは限りません。 総額はA社のほうが安いこともあります。しかしA社の見積もりでは、台数を800台に減らしたときに何が下がるのかが分かりません。 数量課金を名乗る以上、下がる部分が特定できないのは説明不足です。

複数社の見積もりを比較するときは、金額を見る前に、まず5軸へそろえてください。軸がそろっていない見積もりどうしを金額で比べても、どちらが安いかは判定できません。

ベンダーへそのまま送れる確認質問9問

以下をそのままコピーして送れます。金額の交渉ではなく、分解の依頼として書いてあります。 どの質問がどの軸を確認するものかは、次項の「回答をどう読むか」の表にまとめてあります。

そのまま送れるメール文面

◯◯株式会社
◯◯様

いつもお世話になっております。△△株式会社の□□です。
いただいた見積もりについて、社内で費用構造を確認するため、以下9点についてご教示ください。
金額の妥当性を疑うものではなく、数量が変動した際の見通しを立てるための確認です。

1. 数量に連動している費目について、何を1と数えているかをご教示ください。
   （例：デバイス1台か通信1件か、商品1点か1SKUか、1言語か1対象国か）

2. 数量連動の費目のうち、第三者へお支払いになる実費と、御社の役務の対価を
   分けてご記載いただけますでしょうか。あわせて、人手作業として計上されている
   費目については、1件に含まれる項目数・工程・品質基準もご教示ください。

3. 実費部分について、数量が増えた場合に仕入れ側で適用される段階単価があれば、
   その反映方法をご教示ください。

4. 段階料金の境目（例：50／100といった区切り）を決めている技術的・契約的な
   根拠をご教示ください。

5. 全対象に一度で反映される作業（共通機能の改修、パッチ適用、テンプレート更新など）は、
   数量に連動しない費目として計上されていますでしょうか。あわせて、対象ごとにSLAが
   独立して定義されているかもご教示ください。

6. 受け入れ試験について、同時に検証できる台数・拠点数の上限と、それに基づく
   試験日数の考え方をご教示ください。

7. 現地作業が含まれる場合、台数で決まる部分と拠点数・移動で決まる部分を
   分けてご記載いただけますでしょうか。

8. 数量が減少した場合の費用の扱い（段階が下がる条件、判定のタイミング、
   下限の有無）をご教示ください。

9. 稼働を停止した対象について、解約手続きを行わない限り発生し続ける費用が
   あれば、その一覧をご教示ください。

お手数をおかけしますが、◯月◯日までにご回答いただけますと幸いです。
すべてを一度にご用意いただく必要はございませんので、ご対応可能な範囲と時期を
先にご教示いただく形でも差し支えありません。

5番と8番は必ず入れてください。 5番は共通基盤の重複計上を、8番は減額条項の不在を、それぞれ1問で確認できます。

回答をどう読むか

返ってきた回答は、次の基準で「説明済み」と「要確認」へ仕分けてください。

回答が「要確認」に寄った質問が3問以上あるなら、金額の議論に入る前に、分解された再見積もりを求めてください。 再見積もりが出てこないなら、それが4状態でいう「判断不能」です。

回答が揃ったあとの選択肢

質問への回答が揃ったら、4状態のどれに落ち着いたかで次を決めます。

いずれの場合も、既存ベンダーの継続が合理的という結論はありえます。 分解を依頼した結果、比例が妥当だと確認できたなら、それは交渉に失敗したのではなく、検証が終わったということです。

根拠資料と適用条件

本記事で引用した公開情報は次のとおりです。価格は改定されるため、実際の判断では取得日以降の最新情報を各発行元の公式ページでご確認ください。

本記事では、各社・各団体が公表した内容と、koromo編集部が整理した確認観点を区別して記載しています。前者は出典と取得日を明示し、後者は「確認観点」として提示しています。

あわせて、次の4点にご注意ください。

数量課金の「相場」は、本記事では示していません。 数量と費用の関係について、公的機関が公表した調査データを確認できなかったためです。検索結果に出てくる「1台あたり月額◯◯円」「1サイトあたり月額◯◯円」といった数字は、各社が自社の受注実績を集計したものであり、公的な相場ではありません。

引用した公開価格は、それぞれのサービスや事業者を推奨するものではありません。 課金の単位が事業者ごとに違うこと、そして同じ製品の中でも費目ごとに違うことを示すために引用しています。

引用したサービス料金を、受託開発・保守の見積もりへそのまま当てはめることはできません。 本記事が参照しているのは、サービス提供事業者が自社の原価構造に基づいて設定した公開価格です。受託の見積もりには、要件の複雑さ、体制、責任範囲といった別の変数が入ります。「この公開価格より高いから割高だ」という比較には使えません。

比較例の表に記載した費目構成は、実在の見積書ではありません。 分解されている見積書と分解されていない見積書で、確認できることがどう変わるかを示すための構成例です。金額を記載していないのはそのためです。

なお本記事は、法的・会計的・技術的な最終判断を提供するものではありません。契約解釈や費用の会計処理については、それぞれの専門家にご確認ください。

よくある質問