生成AIを組み込んだサービスの料金設計では、「利用者が使うほど自社の原価が増える」という性質を前提に置くことが出発点です。従来のSaaSのように、利用者が増えても原価がほとんど増えない前提で定額の料金を決めると、一部の利用者の大量利用で利益が消えたり、AIの利用料の改定で採算が崩れたりします。料金は、原価の構造を把握したうえで、定額・従量・ハイブリッドのどれを選ぶかを、利用者にとっての予測しやすさと、自社にとっての原価リスクのバランスで決めます。
多くのAIサービスで現実的なのは、基本料金に一定の利用量を含め、それを超えた分を追加課金する、または上位プランへの移行を促すハイブリッド型です。ただし、どの型を選ぶにしても、利用量の単位を利用者に分かる言葉（文書の件数、処理回数、ユーザー数など）で定義すること、原価を利用者ごと・機能ごとに計測できるようにしておくこと、AIの利用料が変わったときに見直せる余地を残しておくことの三つが欠かせません。
この記事は、生成AIを使ったサービスや機能の提供を企画している事業担当者、既存のSaaSにAI機能を追加して料金をどうするか検討している方に向けて書いています。AIサービス特有の原価の考え方、料金体系の型と選び方、価格の決め方、原価を管理する仕組み、よくある失敗とチェックリストを整理しました。
AIサービスの料金設計が従来のSaaSと違う点
従来のSaaSでは、サーバー費などの原価は利用者数に応じてゆるやかに増える程度で、売上に占める割合も比較的小さいのが一般的でした。そのため、ユーザー数や機能の範囲で定額のプランを作れば、採算を大きく外すことは少なかったと言えます。
生成AIを組み込んだサービスでは、事情が変わります。
- 利用のたびに外部のAIの利用料がかかる：多くの場合、AIモデルの提供元に、処理した文字量（トークン）に応じた利用料を払います。
- 利用者によって利用量の差が大きい：同じプランでも、毎日大量の文書を処理する利用者と、月に数回しか使わない利用者が混在します。
- 1回あたりの原価が処理内容で大きく変わる：短い質問への回答と、長い文書を読み込んでの要約では、処理量が大きく違います。
- 原価の単価が外部要因で変わる：AIモデルの提供元の価格改定、新しいモデルへの切り替えによって、同じ処理の原価が上下します。
- 品質を上げると原価も上がりやすい：より高性能なモデルを使う、参照する資料を増やす、出力を検証する処理を追加する、といった品質向上の施策は、原価の増加を伴います。
このため、AIサービスの料金設計は「売上の設計」であると同時に「原価リスクの設計」でもあります。
原価の構造を把握する
料金を決める前に、1回の利用でどんな費用がかかっているのかを分解します。AIの利用料だけを見て原価とするのは不十分です。
| 原価の要素 | 内容 | 利用量との関係 |
|---|---|---|
| AIモデルの利用料 | 入力と出力の処理量に応じた外部への支払い | 利用量にほぼ比例 |
| 検索・参照の費用 | 社内文書などを検索して参照する仕組みの費用 | 利用量と保存データ量に連動 |
| インフラ費 | サーバー、データベース、ストレージ | 利用者数と利用量にゆるやかに連動 |
| 外部APIの費用 | 文字起こし、画像処理、翻訳など他の外部サービス | 機能の利用量に比例 |
| 人による確認・サポート | 出力の確認、問い合わせ対応、品質改善の作業 | 利用者数と問題の発生数に連動 |
生成AIを組み込んだシステム全体の費用の見積もり方は、生成AIを組み込んだシステム開発の費用とAPI利用料の見積もり方で詳しく解説しています。
「1単位あたりの原価」を出す
料金の基礎になるのは、利用者に課金する単位あたりの原価です。たとえば「文書1件の要約」を単位にするなら、平均的な文書の長さ、使うモデル、参照する資料の量、出力の長さから、1件あたりの原価を見積もります。このとき、平均値だけでなく、長い文書や複雑な処理の場合の上振れ幅も把握しておきます。料金の設計で問題になるのは、多くの場合、平均ではなく上振れする利用者です。
原価を下げる設計の余地を確かめる
原価は料金だけでなく、設計でも下げられます。簡単な処理には軽いモデルを使い、難しい処理だけ高性能なモデルを使う。同じ指示文を繰り返し送る場合はプロンプトキャッシュを活用する。参照する資料を必要な部分に絞る。こうした工夫で原価が下がれば、料金設計の自由度が増します。料金を決める前に、開発担当者と原価を下げる余地を確認しておきます。
料金体系の型と選び方
AIサービスで使われる主な料金体系は次の四つです。
| 料金体系 | 仕組み | 利用者にとって | 提供者にとって |
|---|---|---|---|
| 定額（使い放題） | 月額固定で利用量の制限なし | 費用が予測しやすく、気軽に使える | 大量利用者で原価割れするリスクが大きい |
| 定額（上限付き） | 月額固定で、プランごとに利用量の上限 | 予測しやすいが、上限を意識する必要がある | 原価の上限が読める |
| 従量課金 | 利用量に応じて課金 | 使った分だけ払うので公平だが、予算を組みにくい | 原価と売上が連動し安全 |
| ハイブリッド | 基本料金＋一定量を含み、超過分を従量またはプラン変更 | 予測しやすさと公平さの中間 | 原価リスクを抑えつつ安定収益を得られる |
従量課金の一般的な考え方は従量課金モデルでも整理しています。
どの型を選ぶかの判断基準
- 利用者が法人で、予算の承認が必要：定額や上限付き定額が好まれます。従量課金だけだと、稟議の段階で「月にいくらかかるか分からない」と止まりやすくなります。
- 利用量の個人差が大きい：使い放題は避け、上限付き定額かハイブリッドにします。
- 1回あたりの原価が大きい：従量課金かハイブリッドにして、原価と売上を連動させます。
- AIは補助的な機能で、利用量が少ない：既存プランに含める、または上位プランの特典にする方法が使えます。ただし利用上限は設けておきます。
- 利用者が開発者で、APIとして使う：従量課金が受け入れられやすい傾向があります。
利用量の単位をどう定義するか
AIサービスの料金で特に重要なのが、課金や上限の単位です。提供者側の原価はトークンで発生しますが、利用者にとってトークンは分かりにくい単位です。利用者が自分の業務の言葉で理解できる単位を選びます。
- 処理件数：文書1件、問い合わせ1件、議事録1回など。業務の単位と一致し、分かりやすい。
- ユーザー数：利用する人数で課金し、1人あたりの利用上限を設ける。従来のSaaSに近く、法人に受け入れられやすい。
- クレジット：機能ごとに消費量の異なるポイントを月に付与する。機能によって原価が違う場合に使えるが、説明が必要。
- 成果：自動で解決した問い合わせの件数など。価値と連動するが、成果の定義と計測が難しい。
処理件数を単位にする場合、1件の大きさに大きな幅があると原価がぶれます。「1件あたり一定の文字数まで」といった条件を設けるか、大きさの区分ごとに消費量を変える設計を検討します。
価格を決める手順
- 単位あたりの原価を見積もる：平均と上振れの両方を出し、AIの利用料以外の原価も含める。
- 利用者の価値を見積もる：AIで置き換えられる作業時間や外注費、品質の向上による効果を、想定利用者へのヒアリングで確かめる。
- 利用量の分布を想定する：軽い利用者、標準的な利用者、大量利用者の割合と、それぞれの利用量を仮置きする。試験提供ができれば実測に置き換える。
- 料金体系と単位を決める：判断基準に沿って型を選び、利用者に分かる単位を定める。
- プランごとの粗利を計算する：利用量の分布ごとに、売上と原価から粗利を出し、大量利用者でも赤字にならないかを確かめる。
- 上限と超過時の扱いを決める：上限に達したら止めるのか、追加課金か、上位プランへの案内かを決め、利用者に事前に通知する仕組みを用意する。
- 原価の変動に備える：AIの利用料が上がった場合、どこまで吸収でき、どこから料金を見直すかの基準を決めておく。
- 試験提供で検証する：一部の利用者に提供し、利用量の実測、上限への到達率、料金への反応を確かめてから正式な価格を決める。
手順5で、大量利用者の粗利がマイナスになる場合は、上限の設定か、プランの区分を見直します。一部の利用者の赤字を、他の利用者の黒字で埋める設計は、大量利用者が増えたときに崩れます。
原価を管理する仕組みを作る
料金設計は、原価を計測できる仕組みとセットで初めて機能します。サービスの開発段階で、次の仕組みを入れておきます。
- 利用者ごと・機能ごとの原価の記録：どの利用者がどの機能でどれだけの処理をしたかを記録し、月次で原価を集計できるようにする。
- 上限の制御：プランごとの上限に達したら、処理を止める、警告を出す、管理者に通知する、といった制御を自動で行う。
- 異常な利用の検知：短時間に大量の処理が行われた場合に検知し、悪用や不具合を早く見つける。
- モデルの切り替えの余地：特定のAIモデルに依存しすぎず、価格や性能の変化に応じて切り替えられる構成にしておく。
これらの仕組みが後回しになると、月末に請求額を見て初めて赤字に気づく、という事態になりかねません。最初の版から、最低限の記録と上限の制御は入れておくことをおすすめします。AIサービスの最初の版にどこまで含めるかは生成AIサービスのMVPでも整理しています。
料金の見せ方と、改定への備え
AIサービスの料金は、設計が正しくても、伝え方を誤ると不満の原因になります。特に上限と超過の扱いは、利用者が事前に理解していないと、「急に使えなくなった」「想定外の請求が来た」という問い合わせにつながります。
料金ページと管理画面で伝えること
- 上限の目安を業務の言葉で示す：「月に何件の文書を処理できるか」「何時間分の会議を処理できるか」など、利用者が自分の業務に当てはめられる目安を書く。
- 現在の利用量を見える場所に置く：管理画面に、今月の利用量と上限までの残りを常に表示する。法人の場合は、管理者が利用者ごとの内訳を確認できるようにする。
- 上限に近づいたときの通知：一定の割合に達した時点で、利用者と管理者に知らせる。通知のタイミングを料金ページにも明記する。
- 超過時の挙動を明記する：処理が止まるのか、追加料金で継続するのか、自動で上位プランに切り替わるのかを、契約前に分かる場所に書く。勝手に追加料金が発生する設計は避け、利用者が選べるようにする方が信頼につながります。
料金改定に備えた規約と運用
AIの利用料が大きく変わったとき、提供者側の判断で料金を見直す必要が出ることがあります。そのときに慌てないよう、利用規約には料金改定の手続きと告知期間を定めておきます。改定の手続きが法令や契約の条件に照らして適切かどうかは、専門家に確認してください。
運用面では、原価の推移を月次で見る習慣を作っておきます。AIの利用料の改定、利用者の使い方の変化、新機能の追加によって、粗利は少しずつ変わります。プランごとの粗利を定期的に確認していれば、改定が必要かどうかを早い段階で判断でき、利用者への告知にも十分な時間をかけられます。
また、より安価で性能の近いモデルが登場した場合に、品質を確かめたうえで切り替えられる体制を作っておくことも、料金を守る手段になります。切り替えの前には、評価用のデータで出力の品質を比べ、利用者の体験が損なわれないことを確かめます。
具体的な場面の例：議事録作成サービスの料金を見直す
架空の例で考えます。あるスタートアップが、会議の録音から議事録を自動で作るサービスを、1ユーザーあたりの月額定額・使い放題で提供していました。
運用を始めてしばらくすると、利用量の偏りが明らかになりました。大半の利用者は週に数回の会議で使う程度でしたが、一部の利用者は毎日長時間の会議を処理しており、その利用者の原価が月額料金を上回っていました。
そこで、次のように見直しました。
- 1ユーザーあたりの月額に、一定時間分の処理を含める形に変更する
- 上限に近づいたら利用者と管理者に通知し、超過分は追加の時間パックで購入できるようにする
- 長時間の会議が多い利用者向けに、処理時間の多い上位プランを用意する
- 既存の利用者には一定の移行期間を設け、変更の理由と新しいプランの内容を事前に説明する
料金の単位を「録音の時間」という利用者に分かる言葉にしたことで、上限の説明がしやすくなり、大量利用者の原価も売上と連動するようになりました。
あわせて、原価そのものを下げる見直しも行いました。録音の文字起こしと要約を同じ高性能なモデルで処理していたのを、文字起こしの後の整形には軽いモデルを使い、要約と決定事項の抽出にだけ高性能なモデルを使う構成に変えました。評価用の会議データで出力を比べ、品質が保たれていることを確かめてから切り替えています。料金の見直しと原価の見直しを同時に進めたことで、既存の利用者の多くは、変更後も従来と同じ費用感で使い続けられるようになりました。料金だけで採算を合わせようとすると値上げしか手段がなくなりますが、原価の設計にも手を入れると選択肢が広がります。
よくある失敗と避け方
- 使い放題の定額で始めてしまう：上限のない定額は、大量利用者の原価が読めない。上限付きかハイブリッドで始める。
- 原価をAIの利用料だけで見積もる：検索、インフラ、外部API、人による確認も含めて積み上げる。
- 平均の利用量だけで採算を判断する：上振れする利用者の原価を確かめ、プランの区分と上限で吸収する。
- トークンなど利用者に分かりにくい単位で課金する：処理件数や時間など、業務の言葉で単位を定義する。
- 原価の記録の仕組みがない：利用者ごと・機能ごとの原価を最初から記録する。
- AIの利用料の変動を想定していない：吸収できる範囲と見直しの基準を事前に決め、規約に料金改定の手続きを定めておく。
- 価値ではなく原価だけで価格を決める：原価は下限であり、価格は利用者にとっての価値から考える。
AIサービス料金設計のチェックリスト
- 単位あたりの原価を、平均と上振れの両方で把握している
- AIの利用料以外の原価も含めている
- 利用者にとっての価値（置き換えられる作業や費用）を確かめた
- 利用量の分布を想定し、大量利用者でも赤字にならない
- 利用者に分かる単位で、上限と超過時の扱いが決まっている
- 上限への到達を利用者に事前に通知できる
- 利用者ごと・機能ごとの原価を記録できる
- AIの利用料が変わったときの見直しの基準がある
- 試験提供で利用量と反応を確かめる計画がある
よくある質問
Q. 既存のSaaSにAI機能を追加する場合、別料金にすべきですか？
AI機能の利用量が少なく原価が小さいなら、既存プランに含めて解約防止や上位プランへの移行の理由にする方法があります。利用量が多い、または原価が大きい場合は、追加のオプションにするか、上位プランに限定します。どちらにしても、利用上限は設けておくことをおすすめします。
Q. AIの利用料が下がったら、料金も下げるべきですか？
必ずしも下げる必要はありません。利用料が下がった分を、品質の向上（より高性能なモデルの採用、処理の追加）や、上限の引き上げに使うという選択肢もあります。競合の動向や利用者の反応を見ながら判断します。
Q. 無料プランは用意すべきですか？
試してから導入を決めたい利用者が多い場合は、利用量を厳しく制限した無料枠や試用期間が有効です。ただし、AIサービスでは無料利用者にも原価がかかるため、無料枠の原価を獲得の費用として計画に組み込み、悪用を防ぐ仕組みも用意します。
Q. 成果報酬型の料金は現実的ですか？
成果の定義が明確で、計測が自動でできる場合には現実的です。たとえば自動で完了した処理の件数などです。ただし、成果の判定で利用者と認識が食い違うと紛争になりやすいため、定義と判定の方法を契約で明確にしておく必要があります。
Otsumuに相談できること
提供するAI機能の範囲が決まっていて、開発担当者と一緒に原価を見積もれる体制がある場合は、この記事の手順で自社で料金を設計できます。試験提供で利用量を実測し、プランごとの粗利を確かめるところまで進めば、正式な価格を決める根拠が整います。
一方で、原価の見積もりに自信が持てない、利用量の偏りで採算が崩れている、料金と機能の範囲を同時に見直したい、といった場合は、事業設計とAIの実装の両方を知る外部の視点が役立ちます。AIサービスの料金は、モデルの選び方や処理の設計で原価が大きく変わるため、価格だけを切り離して決めるのが難しいからです。
Otsumuは自らも事業を手がける立場から、新規事業開発コンサルティングとして料金体系と原価の設計を支援し、生成AIシステム開発で原価の記録や上限の制御を備えたサービスの開発まで一気通貫で対応します。料金への反応を顧客と確かめたい場合は、顧客検証 Sprint（98万円〜・税別、4週間）という進め方もあります。
料金設計の考え方を整理したい段階からご相談いただけます。まずは30分の無料相談で、提供したいサービスの内容をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01