AI課金モデルとは？5つの主要パターンと選び方を解説

AI課金モデルとは、「AIサービスの提供価値を、どの単位で料金に換算するか」を定めた課金設計です。

生成AIを組み込んだサービスでは、従来のSaaSのように「1ユーザーあたり月額いくら」という設計だけでは成り立たないケースが増えています。AIの処理そのものに原価が発生するため、利用量が増えるほど提供側のコストも上がるからです。そのため、利用量に連動する課金と定額の課金を組み合わせた、複合的な料金設計が主流になりつつあります。

この記事では、AIサービスで採用されている代表的な5つの課金モデルと、自社サービスに適したモデルを選ぶための判断軸、そして運用時に発生しやすい課題をご紹介します。

　⇒資料「AI時代の従量課金導入ガイド」の無料ダウンロードはこちら

目次
AI課金モデルとは
AI課金モデルの5つのパターン
AI課金モデルの選び方 — 3つの判断軸
AI課金モデルの運用でつまずく3つのポイント
AI課金の請求課題を解決する「Scalebase」

AI課金モデルとは

AI課金モデルとは、「AIサービスの提供価値を、どの単位で料金に換算するか」を定めた課金設計です。従来のサブスクリプションサービスでは「定額課金」と「従量課金」の2つが基本でしたが、AIサービスではこの2つを組み合わせたり、成果そのものを課金対象にしたりと、より多様な設計が採用されています。

AIサービスの課金設計が複雑になる理由は、原価の構造にあります。一般的なSaaSでは、ユーザーが1人増えてもサーバー費用が大きく変わることはありません。一方でAIサービスの場合、利用のたびに大規模言語モデル（LLM）の処理が走り、その分の費用が提供側に発生します。利用量と原価が比例するため、料金にもその構造を反映させる必要があります。

また、AIサービスは提供価値を「利用回数」で測るべきか、「成果」で測るべきかがサービスごとに異なります。事業者は自社の原価構造と提供価値の性質を踏まえて、課金モデルを選択する必要があります。

AI課金モデルの5つのパターン

AI課金モデルと一括りにいっても様々な種類が存在します。ここでは「トークン・API従量課金」「クレジット前払い型」「シート課金＋利用量のハイブリッド型」「成果報酬型」「定額型」とそれぞれの具体例を紹介します。

トークン・API従量課金

トークン・API従量課金は、AIが処理したデータ量やAPIの呼び出し回数に応じて請求額を決める方法です。

生成AIの処理量を測る単位として「トークン」が用いられます。入力したテキストと出力されたテキストの量に応じて課金され、多くの場合、入力と出力で単価が異なります。原価とほぼ連動するため、提供側が損失を抱えにくいモデルです。

一方で、顧客側は事前に費用を見積もりにくくなります。そのため、上限料金を設けたり、一定量までは基本料金に含めるといった調整を併用するケースも多くあります。

（サービスの具体例）トークン課金の例として、OpenAIやAnthropicが提供するAPIがあげられます。いずれもモデルごとに100万トークンあたりの単価が設定されており、高性能なモデルほど単価が高くなる料金体系です。

クレジット前払い型

クレジット前払い型は、あらかじめ「クレジット」を購入してもらい、AIの利用に応じて消費させる方法です。

顧客は購入した分だけ利用できるため、支払額の上限が明確になります。提供側も先に入金を受けられるため、キャッシュフローの面で有利です。画像生成や動画生成のように、1回の処理の重さがばらつくサービスと相性が良く、処理の重さに応じて消費するクレジット数を変えられる柔軟性もあります。

ただし、入金のタイミングと売上を計上するタイミングがずれるため、会計処理には注意が必要です。購入時点では前受収益（負債）として扱い、クレジットが消費された分を売上として計上するのが原則です。詳しくは「前受収益とは？」の記事で解説しています。

→ 前受収益とは？

（サービスの具体例）クレジット前払い型の例として、画像生成AIのMidjourneyがあげられます。プランごとに割り当てられた生成時間を消費する形で、追加分は都度購入する仕組みが採用されています。

シート課金＋利用量のハイブリッド型

シート課金＋利用量のハイブリッド型は、1ユーザーあたりの月額料金を基本としながら、一定量を超えたAI利用分を従量で追加請求する方法です。

既存のSaaSにAI機能を追加する場合に多く採用されます。顧客はこれまでと同じ「1ユーザーあたりいくら」の感覚で予算を組めるため、稟議を通しやすいという利点があります。提供側も、基本料金で固定収益を確保しながら、AI原価の増加分を従量で回収できます。

ただし、基本料金に含める利用量の設定を誤ると、原価を回収できないケースが生じます。事業者は、平均的な利用量と上位の利用量の分布を見きわめて設計する必要があります。

（サービスの具体例）ハイブリッド型の例として、業務ツールに搭載されたAIアシスタント機能があげられます。1ユーザーあたりの月額に加えて、生成回数や処理件数の上限が設けられ、超過分は追加料金となる設計が一般的です。

成果報酬型

成果報酬型は、AIが処理を完了した件数や、実際に得られた成果に応じて請求が発生する方法です。

AIエージェントのように「業務を代行する」性質のサービスと相性が良いモデルです。顧客は成果が出た分だけ支払うため導入のハードルが下がり、提供側も価値に見合った金額を請求しやすくなります。人が対応していた業務を置き換えるサービスでは、人件費と比較されるため、単価を高く設定しやすい面もあります。

一方で、「何を成果とみなすか」の定義が曖昧だと、請求時に顧客との認識の齟齬が生まれます。契約時点で成果の定義と計測方法を明確にしておく必要があります。

（サービスの具体例）成果報酬型の例として、カスタマーサポート領域のAIエージェントがあげられます。問い合わせを自動で解決できた件数に応じて課金する料金体系が採用されています。

定額（無制限）型

定額型は、利用量にかかわらず請求金額が固定される方法です。

顧客にとって最も分かりやすく、予算も確定できるため、導入の意思決定が早くなります。提供側も収益予測が立てやすくなります。

ただし、AIサービスの場合は利用量に応じて原価が増えるため、ヘビーユーザーの存在によって採算が悪化するリスクを抱えます。そのため、完全な無制限ではなく、公平利用の範囲を定めたり、実質的な上限を設けたりするケースが多くあります。

（サービスの具体例）定額型の例として、対話型AIサービスの個人向けプランがあげられます。月額固定で利用できる一方、一定時間内の利用回数に上限が設けられています。

⇒資料「AI時代の従量課金導入ガイド」の無料ダウンロードはこちら

AI課金モデルの選び方 — 3つの判断軸

5つのパターンのうち、どれを採用すべきかはサービスの性質によって異なります。ここでは判断のための3つの軸を紹介します。

原価が利用量に連動するか

まず確認すべきは、自社サービスの原価構造です。

顧客の利用が増えるほどLLMの処理費用が増える構造であれば、料金も利用量に連動させるのが基本です。定額型を採用すると、利用量の多い顧客ほど採算が悪化し、事業が成長するほど利益率が下がるという状況を招きます。

反対に、AIの処理が軽く原価への影響が小さい場合や、事前に生成した結果を再利用できる仕組みであれば、定額型でも成り立ちます。原価に占めるAI処理費用の比率を把握することが、モデル選択の出発点になります。

顧客が予算を確定したいか

次に、顧客側の購買事情を踏まえます。

法人向けサービスでは、年度単位で予算を確保してから稟議にかけるケースが一般的です。請求額が毎月変動する従量課金は、この予算確保のプロセスと相性が良くありません。「上限が読めない」という理由で導入が止まることもあります。

こうした場合は、クレジット前払い型やハイブリッド型のように、支払額の上限が明確になる設計が有効です。上限付きの従量課金を採用し、一定額を超えたら課金しないという設計も、顧客の不安を解消する手段になります。

提供価値が使用量に比例するか

3つ目の軸は、サービスの価値が「使った量」に比例するかどうかです。

たとえば文章の要約であれば、処理した件数と顧客が得る価値はおおむね比例します。この場合は使用量に応じた課金が納得を得やすくなります。

一方で、AIエージェントが商談を1件獲得する、問い合わせを1件解決するといったサービスでは、処理にかかった回数よりも「成果が出たかどうか」が顧客にとっての価値です。処理回数で課金すると、成果が出ていないのに請求が発生し、顧客の納得を得にくくなります。この場合は成果報酬型を検討すべきです。

AI課金モデルの運用でつまずく3つのポイント

課金モデルを決めた後、実際の運用でつまずきやすいポイントが3つあります。

利用量データと請求が分断される

AIの利用量はプロダクト側のデータベースに蓄積されますが、請求業務は別のシステムやスプレッドシートで行われていることが多くあります。この2つがつながっていないと、毎月「利用量データを書き出し、顧客ごとに集計し、単価を掛けて請求額を出す」という作業が発生します。

契約数が10社程度であれば手作業でも回りますが、100社を超えると集計だけで数日かかるようになります。単価や上限が顧客ごとに異なる場合は、計算ミスのリスクも高まります。

前払いクレジットの収益認識

クレジット前払い型を採用すると、入金と売上計上のタイミングがずれます。購入時点の入金は前受収益として負債に計上し、実際に消費された分を売上に振り替える処理が必要です。

未消化のクレジットがどれだけ残っているかを顧客ごとに正確に把握できていないと、月次決算のたびに残高の確認に追われることになります。監査で説明を求められた際に、根拠を示せる状態にしておくことも重要です。

頻繁な料金改定への追随

AI領域では、モデルの性能向上やAPI原価の変動を受けて、料金プランを短いサイクルで見直すケースが少なくありません。

このとき、料金の計算ロジックをシステムに個別に作り込んでいると、改定のたびに開発対応が発生します。既存顧客を旧プランのまま継続させるか、新プランへ移行させるかといった運用も、契約ごとに手作業で対応することになり、バックオフィスの負荷が一気に高まります。

AI課金の請求課題を解決する「Scalebase」

AI課金モデルを運用する上での課題として、利用量データの集計や顧客ごとの請求金額の算出など、請求作業が煩雑になることがあげられます。そして請求管理をエクセル・スプレッドシートで行う場合、顧客数の増加次第ではかなり大きな負担になります。

エクセル・スプレッドシートを用いた請求管理の課題

• プラン変更などの契約の変遷・履歴が辿れない
• イレギュラー対応などのメモが担当者しか分からない
• セルのずれによって関数は機能しなくなる
• 件数が増えることで動作が遅くなる

そこでご紹介するのが「Scalebase」というサービスです。Scalebaseは、SaaSやサブスク・リカーリングなど、あらゆる継続課金ビジネスに特化した販売・請求管理SaaSです。

特に、AIの利用量に応じた課金の計算は、使用量データをインポートするだけ。トークン数やAPIコール数といった単位を商品マスタで定義しておけば、事前に設定した計算式をもとに自動で請求金額を算出するため、ミスなく迅速に請求データの確定が行えます。上限付きの従量課金や段階型の単価設定、「基本料金＋AI使用量＋成果報酬」のようなハイブリッドな料金体系にも標準で対応しています。

他にも、クレジットの前払いのように請求と売上計上のタイミングがずれるケースでも、商品ごとに設定した収益認識ルールに基づいて仕訳データを自動生成します。料金プランの改定時も、商品マスタの登録だけで新旧プランの並行提供や既存顧客の一括切り替えに対応できるため、価格戦略の変更をシステムが妨げることがありません。

⇒AI課金管理の業務効率化について詳しくはこちら

まとめ

AI課金モデルとは、「AIサービスの提供価値を、どの単位で料金に換算するか」を定めた課金設計です。トークン・API従量課金、クレジット前払い型、シート課金とのハイブリッド型、成果報酬型、定額型という5つのパターンがあり、自社の原価構造・顧客の購買事情・提供価値の性質という3つの軸から選択します。

AI領域では料金モデルの見直しが頻繁に発生します。課金モデルは事業を成長させるうえで重要な要素です。事業の拡大に耐えるためにも、社内の契約管理・請求業務のオペレーションの効率化をおすすめします。

Scalebaseの資料ダウンロードはこちら。