AI時代のソフトウェア資産管理

Seat-based PricingからHybrid Pricingへ：AI Agentが変える管理単位

これまで多くのITAM/SAMでは、何ライセンス購入しているか、何人のユーザーが利用しているか、契約上のEntitlementを超過していないか、未使用ライセンスがどれだけ存在するか、更新時にどれだけ削減・最適化できるか、といった対象を管理してきました。これはユーザーやデバイス、プロセッサなど、比較的明確な「ライセンス単位」が存在することを前提としたモデルです。

ServiceNowをはじめとする一部のエンタープライズソフトウェアベンダーでは、この前提がすでに変わり始めています。ServiceNowはAIやData関連ソリューションについて、従来型のSeat-based Pricingだけでなく、Consumption-based Monetizationを組み込む方針を公式に示しており、経営陣は2026年の決算説明で、新規ビジネスの相当部分がすでにnon-seat-basedになっていると説明しています。ただし、すべてのライセンスがConsumption-basedになるわけではありません。実際には今後、Seat・Subscription・Infrastructure・Asset・Connector・AI Consumptionといった複数のメトリックが組み合わされたHybrid Pricing Modelが一般化していく可能性があります。従来のようにユーザー数やライセンス数だけを把握していても、将来コストを正確に予測できなくなる可能性がある点は、ITAM/SAMにとって重要な変化です。

従来のITSMでは、サービスデスク担当者やFulfillerがIncidentやService Requestを処理し、その担当者数がライセンス数やコストに直結していました。しかしAI Agentがこの作業を代替すると、人間のユーザー数とソフトウェアが処理する業務量の関係が崩れます。仮に100人分の作業をAI Agentが代替しても、システム上に「100ユーザー」が存在するわけではありません。一方でAI Agentは、Workflowの実行、Toolの呼び出し、APIの使用、判断、他のAgentとの連携といった処理を大量に実行します。この場合、ベンダーにとっては「ユーザー数」よりも実行量・処理量・Action数・Consumptionの方が、提供価値と価格を結び付けやすくなります。AI Agentの普及は単なる機能追加ではなく、ソフトウェア価格モデルの経済構造そのものを変える可能性があるということです。

ConsumptionとOutcomeを混同しない：AI時代の新しいShelfware

AIサービスではUsage-based、Consumption-based、Value-based、Outcome-basedといった言葉が使われますが、これらは同じ意味ではありません。特に注意すべきは、「AIを利用したこと」と「AIが価値を生み出したこと」は別であるという点です。例えばAI Agentが10回Toolを実行した場合、それはConsumptionとして計測できますが、その実行によって問題が解決したのか、顧客満足度が上がったのか、人間の作業が削減されたのか、SLAが改善したのかは別の問題です。したがってITAM/SAMとしては、少なくとも「Consumption＝実際にどれだけAIを使ったか」と「Outcome＝そのAI利用によって何が達成されたか」を分離して管理する必要があります。

従来のSAMでは、代表的な最適化対象としてShelfwareがありました。1,000ライセンス契約しているのに700人しか使用していなければ、300ライセンス分の削減余地がある、という「未使用＝無駄」という関係が比較的明確でした。ところがConsumption-based Modelでは逆の問題が生じます。AIは確かに利用されており、Consumptionも発生している。しかし、その処理が本当に必要だったのか、価値を生み出したのかが分からないというケースです。AI Agentが同じ処理を何度もRetryする、不要なTool Callが発生する、WorkflowがLoopする、Human Escalationが必要になる、AIが処理した後に人間がやり直す、といった状況では、Consumptionは発生していてもBusiness Valueは低い可能性があります。つまりAI時代には、Unused LicenseだけでなくLow-value Consumption（AI時代のShelfware）を新たな最適化対象として考える必要があります。

「月に10万件をAIが処理した」という数字だけでは、ITAM/SAMやベンダーマネジメントの観点では不十分です。本当に見るべきは、その処理のうち何件が正しく完了したのかです。例えばIncident Managementであれば、AI Resolution Rate、Reopen Rate、Failed Execution Rate、Human Escalation Rate、Rework Rateなどを同時に確認する必要があります。AIが100件のIncidentをResolvedにしても、そのうち30件が再度Openされたのであれば、単純に「100件の自動化に成功した」とは評価できません。Consumption KPIとQuality KPIを分離せず、関連付けて管理することが重要です。

Vendor DependencyとMetering Rule：更新交渉の新常識

AI Agentによって業務効率が向上すれば、企業は運用要員を削減できる可能性があり、これは合理的な経営判断になり得ます。しかしここで注意しなければならないのがVendor Dependencyです。AI Agentによって100人分の業務を自動化し、それに合わせて組織を縮小したとします。数年後にConsumption単価が変更される、Minimum Commitmentが増える、Packagingが変更される、Discount Policyが変更される、AI利用量が急増するといったことが起きても、簡単に人間中心の運用へ戻せない可能性があります。これは単なるSoftware Lock-inではなく、企業内部の業務遂行能力そのものが特定ベンダーのAI Platformに依存するOperational Capability Lock-inと呼ぶべき状態です。今後のVendor Risk Managementでは、「他社製品へ移行できるか」だけでなく、「このベンダーがなくても業務を継続できるか」という観点まで評価する必要があります。

従来の更新交渉ではUnit Price、Discount、Volume、Contract Term、Price Protectionなどが主要な交渉項目でしたが、Consumption-based Pricingではこれだけでは十分ではありません。最終的な支払額はUnit Price×Consumptionで決まり、Consumptionは「何を1 Unitとして数えるのか」によって大きく変わるからです。したがって今後の契約交渉では、価格そのものだけでなくMetering Ruleを管理対象とする必要があります。具体的には、Consumption Unitの定義、Metering方法、ActionやTool Callの数え方、AI Agentごとの消費係数、Retryの扱い、Failed Executionの扱い、Test/Development Environmentの扱い、Overageの扱い、Consumption Cap、Consumption Alert、Carry-over、Metering Error発生時のAdjustment、Consumptionデータへのアクセス権、将来のMetering Rule変更条件などを確認します。価格が変わらなくても、Metering Ruleが変更されれば実質価格は変わるという点が特に重要です。

Outcome-based Pricingが本格的に広がる場合、さらに重要になるのがOutcomeの定義です。AI AgentがIncidentをResolvedにした場合、それを成功と見なすのか、一定期間Reopenされなかった場合のみ成功とするのか、利用者が解決を確認した場合に成功とするのか、SLAを満たした場合まで含めるのか。同じ「Resolution」でも定義によって経済価値は大きく異なります。将来的にはBillable Outcomeの定義自体が契約交渉項目になる可能性があり、企業側はベンダーが定義するTechnical Completionと、自社が求めるBusiness Outcomeを明確に分けて考える必要があります。

SAMとFinOpsの境界はますます小さくなる

Consumption-based Pricingでは利用量がそのままコストに影響します。これはCloud Computingと非常によく似ており、FinOpsで一般的な「Usage → Cost → Allocation → Unit Economics → Business Value → Optimization」というサイクルは、AI時代のSAMにも適用できます。従来のSAMがUser → Role → Subscription → Entitlementを中心に管理してきたのに対し、今後はこれにAI Skill → AI Agent → Execution → Tool Action → Consumption Unit → Cost → Business Outcomeが追加されます。その結果、SAM・FinOps・Vendor Managementを別々の管理機能として運営することが難しくなっていくでしょう。

AIサービスでは単純な利用量だけでなくUnit Economicsを見る必要があります。Cost per AI Execution（AI実行1回あたりのコスト）、Cost per Successful Transaction（正常に完了した業務処理1件あたりのコスト）、Cost per Resolution（正しく解決されたIncident 1件あたりのコスト）、Cost per Automated Workflow（人間を介さず完了したWorkflow 1件あたりのコスト）といった指標を管理することで、「AI利用量が増えている」ではなく「AI利用量が増えた結果、1業務処理あたりの経済性が改善しているか」を見ることができます。これはFinOpsで一般的なUnit Economicsの考え方を、SAMに適用することでもあります。

経営層に報告するKPIと、今から準備すべき7つのこと

AI投資について「何人削減できたか」だけを経営KPIにすると、判断を誤る可能性があります。今後は少なくとも4種類のKPIを組み合わせる必要があります。

• Consumption KPI：Total Consumption、Consumption Growth Rate、Consumption per Transaction、AI Execution Volume
• Quality KPI：Successful Execution Rate、Resolution Rate、Reopen Rate、Failed Execution Rate、Human Escalation Rate、Rework Rate
• Financial KPI：Cost per AI Execution、Cost per Successful Resolution、Cost per Transaction、Human Cost Avoided、Net Savings
• Business Value KPI：SLA Improvement、Processing Time Reduction、Customer/Employee Experience、Productivity Improvement、Business Outcome Achievement

最終的に経営層が見るべきなのは「AIをどれだけ使ったか」ではなく、「AIに支払ったコストに対して、企業がどれだけ価値を獲得したか」です。AI Consumption Modelへの対応は次回更新直前に始めるべきものではなく、今から準備することが重要です。

1. Commercial Modelを把握する：現在の契約について、Seat、Subscription、Consumption、Infrastructure、Connector、AIなど、何が課金単位になっているのかを整理します。
2. Consumption Baselineを作る：AI Skill、AI Agent、Workflow単位で消費量を把握します。現在地を測定できなければ将来コストを予測できません。
3. CostとQualityを結び付ける：Consumptionだけでなく、Failure、Retry、Reopen、Escalation、Reworkと関連付けます。
4. Unit Economicsを算出する：単純なUnit Priceではなく、Cost per Successful Business Transactionを把握します。
5. Growth Scenarioを作る：AI利用量が20％、50％、100％増加した場合の将来TCOをシミュレーションします。
6. Contract Guardrailを準備する：Cap、Overage、Metering Rule、Auditability、Price Protectionなどを契約更新時の交渉項目として定義します。
7. Operational Dependencyを評価する：AIによる人員削減効果だけでなく、ベンダー依存によって失われる内部Capabilityまで評価します。

おわりに：「ライセンスを管理するSAM」から「デジタル労働力の経済性を管理するSAM」へ

AI Agentの普及によって、エンタープライズソフトウェアの役割が変わっています。これまでソフトウェアは人間が仕事をするためのToolでしたが、今後はソフトウェア自身が仕事を実行するDigital Workforceになっていきます。そうなればITAM/SAMの管理対象も変わります。これから管理すべきなのは、Entitlement → Consumption → Cost → Quality → Business Outcome → Vendor Dependencyという一連の経済構造です。

この変化は、ITAM/SAMを単なるライセンス管理やコンプライアンス管理から、より経営に近い機能へ進化させる可能性があります。そして今後、ITAM/SAMチームやベンダーマネージャに求められる最も重要な問いは、「何ライセンス購入しているか」ではなく、「AIにいくら支払い、そのAIからどれだけの価値を得ているのか」になっていくでしょう。

このトピックについて専門家に相談する

AI Consumption Modelへの対応方針の整理、Metering Ruleを踏まえた更新交渉、Consumption BaselineとUnit Economicsの設計まで、貴社の契約状況に合わせた実践的なアドバイスを提供します。まず現状のヒアリングからご相談ください。