本記事では料金体系を扱います。Verified Work Series第4回では、その前提となる業務単位の経済性を扱います。

AIは、ソフトウェアの価値を「人のアクセス」から切り離しつつある

Software as a Serviceの時代において、シート単位の料金は合理的でした。

企業は、ソフトウェアへログインできる従業員の数に応じて料金を支払いました。

CRMは顧客情報を保存しますが、入力し、解釈するのは営業担当者でした。会計システムは記録を整理しますが、確認し、照合するのは経理担当者でした。ヘルプデスクは問い合わせを振り分けますが、解決するのはサポート担当者でした。

ソフトウェアが提供していたのは、アクセス、構造、生産性でした。仕事そのものを実行するのは、人間でした。

AIは、この関係を変え始めています。

AIワークフローが、請求書からデータを抽出し、発注書と照合し、不一致を検出し、会計入力を準備し、例外を正しい担当者へ送る場合、顧客が購入しているものは、単なるツールへのアクセスではありません。

仕事そのものの一部です。

これは、シート料金が消えることを意味しません。従業員数だけでは、ソフトウェアが生み出す価値を十分に表しにくくなるという意味です。

Menlo Venturesは、2025年の企業による生成AI支出を約370億ドルと推計しています。同社の現行手法による2024年の比較値は115億ドルで、2025年のうち約190億ドル、つまり半分強がアプリケーション層へ向かったと推計しています。これらは、米国企業の意思決定者約500人への調査と、ボトムアップ型の市場モデルを組み合わせたMenlo Ventures独自の推計であり、市場全体の監査済み確定値ではありません。

重要なのは、企業がAIへ多く支出していることだけではありません。

支出の多くが、調査、文書作成、分類、照合、応答、実行を行うアプリケーションへ向かっていることです。

AIが仕事を直接行う割合が増えるほど、商取引上の問いは、「何人がアクセスするのか」から、次へ変わります。

どの仕事が、どの品質で完了し、それをどの証拠で確認できるのか。

価値を測る単位は変化している

単純化すると、価値単位の変化は次のように表せます。

これは、すべての製品が必ず通る成熟段階ではありません。

利用者数に応じて価値が増える製品には、シート料金が引き続き適しています。利用量が測定可能で、費用と密接に結び付く場合には、利用量課金が適しています。明確な生産単位が存在する場合には、output単位の課金も成立します。

成果連動型の料金が成立しやすいのは、結果が具体的で、帰属可能で、品質条件を含み、期限が定義され、独立して検証できる場合です。

AIアプリケーション企業は、すでにseat、workflow、consumption、outcomeなど、さまざまな単位を試しています。2026年のAndreessen Horowitzの分析でも、顧客が成果との連動を求める一方で、予算の予測可能性も必要としているという緊張関係が指摘されています。

将来、すべてのAI製品が一つの料金モデルへ収束する可能性は高くありません。料金単位が、実際に提供された仕事と価値へ近づいていくと考える方が自然です。

一つに見えるが、実際には三つの問いがある

「成果課金」という言葉は、広い意味で使われがちです。実際には、三つの問いを分ける必要があります。

問い意味例
何が事業価値を生むのか顧客が求める運用上の結果請求書が正確に検証され、会計登録された
結果をどう測定するのか結果が発生したことを示す証拠会計システムに最終レコードが存在し、必要な確認に合格した
サービスをどう料金化するのか顧客と提供者の商業契約固定費、運用費、利用量、成果連動、またはその組み合わせ

この三つは関連しますが、同じものではありません。

企業は、成功を検証済み成果によって評価しながら、導入固定費と継続運用費を採用できます。

文書や取引件数に応じて料金を請求しても、その文書や取引が本来の事業成果を生んだかを確認していない場合、それは利用量・処理量課金であり、必ずしも成果課金ではありません。

中心となる区別は、次です。

成果で価値を測ることは、すべてを成果だけで課金することを意味しません。

契約には、業務分析と導入、システム連携、継続的な監視と保守、モデルとツールの利用、人による確認と例外処理、検証済み成果に連動する部分を合理的に含められます。

料金体系は、顧客へ提供される価値と、その価値を届けるための費用・リスクの両方を反映すべきです。

Outputは、必ずしもOutcomeではない

AIは、目に見える活動を大量に作れます。文書を作り、レコードを分類し、回答案を作り、APIを呼び出せます。

これらは有用な場合があります。しかし、業務プロセスが完了したことを意味するとは限りません。

AIの活動・生成物より意味のある業務成果
顧客への返信案を作った定義された基準に従って問題が解決した
請求書から項目を抽出した有効なレコードが会計システムへ正確に登録された
週次レポートを作った最新の正規データを使い、対象者へ届いた
見込み顧客を調査した定義された条件を満たし、根拠が記録された
返金を準備した正当な権限により返金が実行され、関連システムへ反映された
タスク完了と報告した目的となる最終業務状態が独立して確認された

有用な成果には、単なる件数以上の条件が必要です。

たとえば「削減された時間」は価値の推計に使えますが、実際のベースラインと、人が使っていた作業時間に基づく必要があります。AIが「この作業には3時間かかる」と主張しただけでは、十分な測定にはなりません。

正しいHandoffは価値がある。しかし業務完了ではない

信頼できるAIワークフローが、すべての案件を自動的に完了するわけではありません。

AIが請求書と発注書を比較し、税額の不一致を発見したとします。AIは支払いを停止し、証拠を保存し、財務責任者へ構造化された確認パッケージを渡しました。

システムは正しく動作しています。しかし、請求書処理はまだ完了していません。

この二つを同じ指標にまとめるべきではありません。

ワークフローの結果業務は完了したか正しい制御判断か
Verified completionはいはい
Appropriate human handoffいいえはい
Human-resolved handoff確認後に完了はい
False completionいいえいいえ
Missed escalationいいえいいえ

適切なhandoffは、高額な間違いを防ぎ、大きな事業価値を守る可能性があります。測定し、評価するべきです。

しかし、元の業務成果がすでに完了したかのように報告したり、同じ単位で請求したりすべきではありません。

契約上は、自動で検証済み完了した案件、人が確認できる状態まで正しく準備した案件、AIと人が共同で解決した案件、完了しなかった試行、回避可能な誤り、誤処理によるやり直しを別々に扱えます。

これらの定義は、請求期間が終わってから交渉するのではなく、導入前に合意する必要があります。

Pure Outcome-Based Pricingが難しい理由

成果課金の魅力は分かりやすいものです。顧客は、価値が提供された場合に支払う。

しかし、実装は複雑です。

1．提供者が最終成果のすべてを管理できるとは限らない

AIは見込み顧客を選別できますが、その顧客が購入するかは管理できません。正しい請求書パッケージを作れますが、相手が期限内に支払うかは管理できません。推奨案を作れますが、管理者が採用するかは管理できません。

料金指標が、システムが直接管理する業務から遠くなるほど、成果の帰属をめぐる争いが起きやすくなります。

より実務的なのは、近接した運用成果です。システムが大きく影響でき、価値があり、独立して検証できる結果を選びます。

たとえば、正確に登録された請求書、必要書類が揃ったコンプライアンスパッケージ、人が判断できる状態まで整理された案件、検証済みの顧客レコード、正しいデータと対象者が確認されたレポートです。

2．処理量が低品質を隠す可能性がある

「解決済み」の問い合わせごとに報酬を得る場合、早すぎる終了を促す可能性があります。処理文書ごとに報酬を得る場合、下流の従業員に修正作業を発生させながら、処理量だけを増やす可能性があります。

成果条件には、正確性、必要な承認、重複処理がないこと、許容されるやり直し、再オープン期間、ポリシー遵守、最終記録システムでの確認を含める必要があります。

そうしなければ、料金モデルは有用な仕事ではなく、目に見える活動量を報酬化します。

3．案件の難易度は同じではない

一つの請求書は標準的で、情報がすべて揃っているかもしれません。別の請求書には、複数通貨、不足書類、税額の相違、取引先情報の矛盾が含まれるかもしれません。

すべてを同じ単価にすると、利益が予測しにくくなったり、簡単な案件を優先する誘因が生まれたりします。

対応策として、案件クラス、複雑性の区分、明確な除外条件、例外案件の別料金、最低利用量、人による解決を含む場合の別扱いが考えられます。

4．記録後に結果が変わる可能性がある

顧客対応案件は再オープンされることがあります。会計入力は取り消されることがあります。最初は受理された文書が、後のコンプライアンス確認で不合格になることがあります。

そのため契約には、確認期間、再オープン・取り消し時の扱い、訂正方法、紛争解決方法、正規の記録システムが必要です。

5．費用と成果帰属を予測しにくい

AIサービスには、モデル利用、検索、ツール、インフラ、監視、人による確認などの変動費があります。

成果だけに課金する場合、完了が顧客の対応、外部データ、第三者システムに依存していても、提供者が費用を負担する可能性があります。

Andreessen Horowitzが2025年に、15業界のCIO 100人への調査と、20人を超える企業購入者との対話を基に行った分析では、成果課金について、事業目標に結び付く明確な成果が不足していること、費用が予測しにくいこと、成果帰属が難しいことが主な懸念として挙げられました。同調査では、多くのCIOがAIアプリケーションについて利用量課金を依然として好むとされています。

これは、成果連動型の料金が成立しないことを意味しません。成果の定義、telemetry、帰属、予測可能性を、料金の約束より先に設計する必要があるという意味です。

Hybrid Pricingは現実的な橋渡しになる

Bainは、生成AI機能を導入している既存SaaSベンダー30社超を分析しました。この調査にはAI-native企業は含まれていません。

その結果、約35％はAI機能を既存プランへ含め、シート料金を引き上げる・調整する方式を採用していました。約65％は、シート料金にAIの利用量や機能アクセスなどのメーターを追加するhybrid方式を採用していました。

同サンプルの中で、AI利用量または成果課金へ完全に移行した企業はありませんでした。Bainは、hybrid方式を主要な移行期の戦略として位置づけ、telemetry、請求機能、販売体制、顧客の予測可能性が必要だとしています。

Hybrid構成では、異なる価値と費用を分けられます。

商業要素対象になり得る内容
導入費業務分析、連携、設定、テスト、展開
基本プラットフォーム・運用支援費稼働、監視、保守、ポリシー更新、サポート、governance
利用量・処理量料金文書、案件、ワークフロー、ツール呼び出し等
成果連動部分検証済み完了、または合意した運用成果
Performance adjustment合意したベースライン・SLAに対する成功報酬または調整

すべての案件で、すべての要素が必要なわけではありません。

目的は料金を複雑にすることではありません。一つの指標に、複数の異なる意味を持たせないことです。

導入作業を成果報酬の中へ隠すべきではありません。変動する運用費を無視すべきではありません。検証できない成果に対して、顧客が成果プレミアムを支払うべきではありません。提供者も、合理的に管理できない事業結果まで責任を負うべきではありません。

料金より先にCompletion Contractを定義する

料金単位を決める前に、業務そのものを定義します。

実用的なCompletion Contractには、次を含めます。

契約要素確認する問い
業務単位1件の案件、取引、文書、ワークフローとは何か
Target state現実の業務システムで、何が成立すれば完了か
品質条件どの確認、承認、ポリシー条件が必要か
正規の証拠どのシステム・受領記録が結果を証明するか
成果帰属の境界提供者、顧客、第三者が管理する範囲はどこか
確認期間どの期間、結果が有効なら成果になるか
例外クラスどの案件が人の判断や別処理を必要とするか
訂正ルール結果が取り消された・誤りと判明した場合にどうするか
商業上の扱い完了、handoff、失敗、やり直しをどう料金化するか

料金は、完了定義の後に決めます。料金が、完了定義の代わりになるべきではありません。

一つの測定可能な業務から始める

業務上の問題が見えやすく、意思決定に関わる階層が少ないほど、この方式は試しやすくなります。

業務設計、システム連携、AI評価、継続監視にかけられる社内リソースが限られる場合ほど、対象範囲を限定することが重要になります。

最初の問いは、「AIにどの料金モデルを使うべきか」ではありません。次の問いです。

定義し、観測し、検証できる結果を生む、限定された業務はどれか。

開始例には、特定種類の請求書照合、定期的な業務レポート作成、標準的な顧客問い合わせ処理、書類の完全性チェック、定型的な社内承認の準備、明確なルールに基づくレコード更新があります。

料金単位を選ぶ前に、次を確認します。

パイロットによって、適切な単位がseat、workflow、case、document、action、verified completion、その組み合わせのどれかを確認できます。

Nova Epitomeが「成果で測る」と言うときの意味

Nova Epitomeにおいて、成果で測ることは、すべての契約を完全な成功報酬型にすることではありません。

プロジェクトの成功を、モデルを接続した、デモが動いた、利用者へアクセスを配布した、トークンを消費した、下書きを大量に作った、AIが多数のタスクを試みた、という指標だけで定義しないという意味です。

より意味のある問いは、目的とする業務状態が成立し、確認されたかです。

そのためには、測定可能な完了定義、限定された権限、関連システムからの証拠、必要に応じた独立確認、例外と人へのhandoffの別管理、false completionとやり直しの監視、実際の業務に合った商業条件が必要です。

私たちの方針

ご支援の成果は、検証済みの業務成果を中心に評価します。契約・料金体系は、導入範囲、利用量、運用支援、成果連動要素を組み合わせて設計します。

この区別は、双方を守ります。

顧客は、システムが実際に何を提供したかを明確に把握できます。提供者は、ワークフローの管理範囲外にある成果まで責任を負う必要がありません。そして双方が、業務を継続的に改善するための共通基盤を持てます。

将来は、一つの普遍的なAI料金モデルではない

シート料金は、今後も多くのソフトウェアで合理的です。利用量課金は、消費量が測定でき、費用と結び付く場合に有効です。Output課金は、明確な生産単位がある場合に成立します。

成果連動型料金は、結果が具体的で、観測でき、帰属でき、品質条件があり、期限が定義され、独立して検証できる場合に信頼性が高まります。

進んでいる方向は、単に「シート料金が消える」というものではありません。

ソフトウェアの価値と料金が、実際に行われた仕事と、届けられた価値へ近づいている。

購入者にとって、最初の問いも変わります。

「何人がアクセスする必要があるか」ではなく、次を問えるようになります。

システムはどの仕事を完了するのか。正しく完了したとどう確認するのか。価値とリスクをどのように分担するのか。

これは、従来より難しい商業上の対話です。同時に、より誠実な対話でもあります。

関連記事

信頼性の側面は、The Verified Work Seriesで扱っています。第1回 — なぜ業務の完了が最も難しいのか、第2回 — 改ざん検知可能な記録が証明できること・できないこと、第3回 — AIはいつ止まり、制御権を人へ戻すべきか。また、第4回 — Verified Workの経済性では、料金体系を選ぶ前に測定すべき費用モデルを扱っています。

参考文献

  1. Menlo Ventures, 2025: The State of Generative AI in the Enterprise — 約500人の米国企業意思決定者への調査と市場モデルに基づく推計.
  2. Bain & Company, Per-Seat Software Pricing Isn't Dead, but New Models Are Gaining Steam — 30社超の既存SaaSベンダーを対象とした価格モデル分析.
  3. Andreessen Horowitz, How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025 — 15業界のCIO 100人への調査と企業購入者へのヒアリング.
  4. Andreessen Horowitz, Surviving AI Price Wars Without Destroying Your Business — seat、workflow、consumption、outcomeなどの価格単位と予測可能性の分析.