「何ライセンス買っているか」から「AIにいくら払い、何を得ているか」へ
先日、ServiceNowの決算説明を読んでいて気になる一文がありました。新規ビジネスの相当部分が、すでに「non-seat-based」になっている、というものです。
これまでITAM/SAM（IT資産管理・ソフトウェア資産管理）の実務は、ユーザー数やEntitlement（契約上の権利数）という、比較的明確な「単位」を数えることが出発点でした。何ライセンス買っていて、何人が使っていて、超過はないか、未使用（Shelfware）はどれだけあるか。この数え方が、AI Agentの普及によって静かに崩れ始めています。
Seat-based PricingからHybrid Pricingへ
AI Agentが人間に代わって業務を実行するようになると、「ユーザー数」と「ソフトウェアが処理する業務量」の関係が崩れます。100人分の作業をAI Agentが代替しても、システム上に100ユーザーが存在するわけではありません。一方でAI Agentは、Workflowの実行、Toolの呼び出し、API使用、他Agentとの連携などを大量に実行します。
ベンダー側から見れば、「ユーザー数」よりも「実行量・処理量・Consumption」の方が、提供価値と価格を結びつけやすい。だからこそ、Seat・Subscription・Infrastructure・Connector・AI Consumptionといった複数のメトリックを組み合わせたHybrid Pricingが今後一般化していく可能性があります。ユーザー数だけを追いかけていては、将来コストを正確に見通せなくなるということです。
Consumptionは「使われた」だけで、「価値を生んだ」とは限らない
ここでITAM/SAM担当者が陥りやすい罠があります。AIが100回動いた、10万件処理した、という数字を「順調に自動化が進んでいる」と読んでしまうことです。
しかしAI Agentが同じ処理を何度もRetryする、不要なTool Callが発生する、Workflowがループする、Human Escalationが必要になる——こうした状態でもConsumptionはきちんと発生します。つまり「使われたこと」と「価値を生んだこと」は別物であり、これを分けて見ないと、AI版のShelfware（低価値な消費）を見逃すことになります。
Incident Managementで言えば、AI Resolution Rateだけでなく、Reopen Rate・Failed Execution Rate・Human Escalation Rateまで併せて見て初めて、その自動化が本当に機能しているかが分かります。
更新交渉の主戦場は「Metering Rule」に移る
もう一つ実務上重要なのが、更新交渉の中身が変わるという点です。従来はUnit Price・Discount・Volume・Contract Termが主な交渉項目でした。Consumption-based Pricingでは、最終的な支払額はUnit Price × Consumptionで決まるため、「何を1 Unitとして数えるか」というMetering Ruleそのものが交渉対象になります。
Consumption Unitの定義、Retryの扱い、Failed Executionの扱い、Test環境の扱い、Overageの扱い、Cap、Alert、Carry-over、Metering Error発生時のAdjustment——価格が変わらなくても、Metering Ruleが変われば実質価格は変わります。この点を押さえずに更新に臨むと、気づかないうちにコストが膨らみます。
また、AI Agentで人員を削減したあとにベンダー側の条件が変わっても、簡単に人間中心の運用に戻せないというリスクもあります。これは従来のベンダーロックインとは少し性質が異なる、「業務遂行能力そのものがベンダーに依存する」状態と言えます。
経営層に報告すべき4種類のKPI
「AI導入で何人減らせたか」だけをKPIにすると判断を誤ります。少なくとも次の4種類を組み合わせて見る必要があります。
Consumption KPI：Total Consumption、Consumption Growth Rate、AI Execution Volume
Quality KPI：Resolution Rate、Reopen Rate、Failed Execution Rate、Human Escalation Rate
Financial KPI：Cost per AI Execution、Cost per Successful Resolution、Net Savings
Business Value KPI：SLA Improvement、Processing Time Reduction、Business Outcome Achievement
最終的に見るべきは「AIをどれだけ使ったか」ではなく、「AIに払ったコストに対して、どれだけ価値を得ているか」です。
今から準備できること
更新の直前になって慌てて対応するテーマではありません。今から準備できることとして、原記事では次の7つを挙げています。
Commercial Model（何が課金単位になっているか）を把握する
2. AI Skill／AI Agent／Workflow単位でConsumption Baselineを作る
3. ConsumptionとFailure・Retry・Reopenを結び付けて見る
4. Cost per Successful Business TransactionでUnit Economicsを算出する
5. AI利用量が増加した場合の将来TCOをシミュレーションする
6. Cap・Overage・Metering Rule・Auditabilityを更新交渉の項目として準備する
7. 人員削減効果だけでなく、ベンダー依存で失われる内部Capabilityまで評価する
おわりに
ソフトウェアはこれまで「人間が仕事をするためのTool」でした。それが「ソフトウェア自身が仕事を実行するDigital Workforce」に変わりつつある。だとすればITAM/SAMが管理すべき対象も、Entitlement → Consumption → Cost → Quality → Business Outcome → Vendor Dependencyという一連の経済構造へと広がっていきます。
「何ライセンス買っているか」から「AIにいくら払い、そのAIからどれだけの価値を得ているのか」へ。この問いへの準備が、これからのITAM/SAM・ベンダーマネジメントに求められています。
本稿は、イタムス株式会社 代表コンサルタント 武内烈氏（Oracle License Master／SLAM Master）による記事「AI時代のソフトウェア資産管理」の内容をもとに、VMAJとして要点を再構成したものです。Metering Ruleを踏まえた更新交渉の考え方、Consumption BaselineとUnit Economicsの設計など、より実務的な整理は元記事をご覧ください。
▼元記事（イタムス株式会社）
