先に結論
AIエージェントの普及で、SaaSの「1人あたり月額いくら」という席数課金が揺らぐという観測が出ています。処理を実行するのが人ではなくエージェントになると、席を数えても支払額が読めなくなるからです。ただし、これは業界の予測・観測であって、すべてのベンダーが席数課金をやめると決まったわけではありません。特定のSaaSがいつ、いくらに変わるという話ではない点を、最初に区別しておきます。
中小企業がいますべきことは、話題のツールを慌てて追加することでも、値上げに驚いて解約することでもありません。次の契約更新のときに、課金の単位・上限・値上げの通知期限・解約の予告期間・データの持ち出し方・監査ログの費用負担を確認することです。この記事は、その確認項目と、ベンダーにそのまま投げられる質問文を用意しました。契約や見積もりの読み解きに不安がある場合は、システム開発の発注前相談や他社見積・提案書の第三者レビューもあわせて検討してください。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
この記事を読むべき人
- SaaSの契約が数本を超え、更新月や課金単位を一覧で把握できていない中小・中堅企業の経営者・CFO
- 「AIで自動化」を検討しているが、既存SaaSの課金がどう動くかを試算できていない情シス・SaaS管理者
- ベンダーから届く更新案内や値上げ通知を、内容を精査しないまま更新し続けている担当者
- 兼任・ひとり体制で、契約書の解約予告やデータ返還条件まで読み切れていない会社
いずれか一つでも当てはまるなら、次の更新前にこの記事の項目を埋めておくと、交渉の材料が手元に残ります。
何が報じられたのか（事実の範囲を確認する）
出発点になった報道は、業務を自律的に実行するAIが、これまでの「利用者数で料金を決める」やり方の土台を突き崩しつつあり、ソフト提供側は画面操作を中心に据えた作りから、エージェントの利用を織り込んだ料金・機能の設計へ舵を切る必要に迫られている、という主張を軸にしています。記事のなかでは、調査会社Gartnerの見立てとして、2030年までに相当規模のアプリケーション支出がエージェント型AIの影響を受けうる、という予測も引かれています。
ここで正確に押さえておきたいのは、報道が語っているのは「こうなるだろう」という予測と観測であって、確定した事実ではないという点です。記事は、特定のベンダーが席数課金をいつ廃止した、料金を何%上げた、という具体を断定していません。紹介されているGartnerの金額も、二次的に報じられた将来予測であり、実額の請求根拠ではありません。したがって本記事でも、「席数課金は必ず消える」「従量課金に全面移行する」といった断定はしません。あくまで、その変化が起きうる前提で、契約更新のときに何を確認しておけば損をしないかを扱います。
この慎重さ自体が実務では大事です。予測を確定事実のように受け取って一気に契約を組み替えると、まだ席数課金のほうが安い領域まで従量課金へ動かしてしまい、かえって費用が増えることがあるからです。変化の方向を見ながらも、判断は自社の実利用データに基づいて下す——これがこの記事の立場です。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
なぜ席数課金がAIエージェントと噛み合わないのか
席数課金は、「一人の担当者が一つの画面にログインして仕事をする」という働き方を前提に組み立てられています。この前提のもとでは、利用者の頭数を数えれば費用が読め、人が増えれば売上も増えるという、ベンダーにとっても利用側にとっても分かりやすい関係が成り立っていました。
AIエージェントが業務に入ると、この前提が単位のレベルでずれます。課金の単位は「人」なのに、実際に照会し、転記し、更新を走らせるのは人ではなくエージェントになるからです。エージェントは席を一つも占有しないまま、人間なら数十人分に相当する処理を短時間で回すことができます。すると、席数だけを見れば安く見えるのに、裏側では処理量やAPI呼び出しに応じた費用が別に積み上がり、月末の請求が読めなくなります。単位（人）と、費用を本当に動かしている量（処理回数）が、別々のものになってしまうわけです。
このずれに直面したとき、ベンダー側には課金の単位を「人」から「実行回数」「処理量」「成果」へ寄せていく動機が生まれます。人の頭数と売上が連動しなくなると、席数課金のままでは、自動化が進むほどベンダーの収益が目減りするからです。だから料金の設計を、利用量や成果に応じたものへ組み替えたくなる——これは構造から導かれる動機の説明であって、すべてのベンダーが実際にそう変更すると断定するものではありません。人が日々操作し続けるツールには席数課金が据え置かれる一方、機械が処理を代行する領域ほど利用量や成果に連動した料金へ傾いていく——こうした二つの料金観がしばらくは並び立つ、と捉えておくのが実態に近いはずです。
利用側にとって重要なのは、この併存のなかで、自社が契約している各SaaSが「どちらの世界にいるのか」を更新のたびに見分けることです。席数課金のまま据え置かれるものと、次の更新で課金単位が変わりうるものを区別できていないと、値上げ通知が届いてから慌てて判断することになります。判断を落ち着いてやるために、材料を前もって揃えておく——次の項からは、その材料の具体を並べます。
契約更新でまず確認する7項目
更新の案内が届いてから読み始めるのではなく、更新月の二〜三か月前に、契約中の主要SaaSについて次の7項目を埋めておきます。表計算1枚で足ります。埋まらない欄があれば、そこがベンダーに問い合わせるべき論点です。
横にスクロールして確認できます
| 確認項目 | 具体的に見ること | 埋まらない場合のリスク |
|---|---|---|
| 課金単位 | 席数か、実行回数か、処理量か、成果か。複数が併存していないか | 自動化で費用が動く軸を見落とす |
| 上限とアラート | 従量部分に上限を設定できるか。想定超過時に通知が来るか | 自動化が成功するほど請求が跳ねる |
| 値上げの通知期限 | 価格改定を何日前に通知する契約か | 交渉や乗り換えの時間が取れない |
| 解約の予告期間 | 何か月前に申し出れば解約できるか。最低利用期間や違約金は | 不要でも次期間を丸ごと払う羽目になる |
| データの持ち出し方法 | 解約・移行時にデータをどの形式で、いつまでに返すか | ロックインされ、乗り換えられない |
| エージェント利用時の追加ライセンス | 外部ツールやエージェントからAPI経由で使う場合の課金・条件 | 人の席とは別枠の費用が後から発生 |
| 監査ログの保持と費用負担 | ログは何日間残るか。長期保持や書き出しは有料か、誰が負担するか | インシデント時に追跡できず、後から高額なオプション費 |
この7項目のうち、AIエージェントの普及で新たに重みを増したのが下の3つ——課金単位、エージェント利用時の追加ライセンス、監査ログの費用負担です。人が画面を触る前提では意識しなくてよかった論点が、エージェントが処理を代行するようになると、そのまま費用と説明責任に直結します。特に監査ログは、エージェントが何をどの権限で実行したかを後から確認する唯一の手がかりになるため、「残る日数」と「誰が費用を持つか」を更新時に必ず押さえておきたい項目です。ログ設計や権限の考え方をもう少し掘りたい場合は、AI導入可否アセスメントやAIエージェント導入の要件整理の観点が参考になります。
「従量課金に変わったら」を試算する手順
課金単位が席数から従量へ動くかもしれない、と身構えるだけでは交渉になりません。「もし従量課金になったら、うちはいくらになるのか」を自分で試算できて初めて、ベンダーの提示が高いのか妥当なのかを判断できます。ところが、この試算に必要な自社の利用実態を測っていない会社がほとんどです。測っていないと、値上げの妥当性を検証できず、言い値をのむしかなくなります。
試算の手順はシンプルです。まず、対象のSaaSについて「誰が」「何を」「月に何回」使っているかを実測します。営業が見積書を作る、経理が請求データを照合する、サポートが問い合わせに一次回答する——こうした業務単位で、一か月あたりの処理件数を数えます。感覚ではなく、実際のログや件数で拾うのがポイントです。次に、そのうちどの業務をエージェントに任せる予定かを仕分けし、任せた場合に処理件数がどう増減するかを見積もります。人が手で回していたときは月100件だった照合が、自動化で回しやすくなって月400件に増える、というように、自動化はしばしば処理回数そのものを押し上げます。
最後に、その想定件数に、ベンダーが提示する（あるいは提示しうる）従量単価を掛けて、月額のレンジを出します。ここで大切なのは、単一の数字ではなく「最小・想定・最大」の3本で出しておくことです。自動化がうまくいって件数が伸びたときの最大額まで見えていれば、上限設定の交渉に説得力が生まれます。逆に、この最大額を出さずに従量契約へ移ると、自動化が成功するほど請求が膨らむという皮肉な結果を招きます。処理件数の実測値という一次データを持ってテーブルにつくこと——これが、値上げ交渉でも新規契約でも、中小企業が持てる最強の材料です。費用対効果を稟議まで持っていく段階では、システム開発の稟議・費用対効果診断の枠組みで、削減額と増加額を並べて示すと通りやすくなります。
SaaSコストが膨らむ典型パターン
契約更新の前に、自社がどのパターンで費用を膨らませているかを知っておくと、削るべき場所が先に見えます。中小企業でくり返し起きるのは、次の5つです。
第一に、使っていない席です。プロジェクトのために増やしたまま減らしていない席、試しに配ったまま定着しなかった席が、毎月そのまま課金され続けています。第二に、退職者のアカウントです。人事の退職手続きとSaaSの席の削除が連動しておらず、辞めた人の席が有効なまま残っている——これはコストだけでなくセキュリティの穴でもあります。第三に、部署ごとの重複契約です。営業部と管理部がほぼ同じ機能のツールを別々に契約している、といった重複は、全社のSaaSを一覧にして初めて見つかります。第四に、無料枠の超過です。無料で始めたツールが、いつのまにか利用量が上限を超え、気づけば従量部分で毎月請求が発生していることがあります。そして第五に、エージェント化による実行回数の増加です。自動化で処理が回りやすくなった結果、従量課金の対象となる実行回数が想定を超えて伸び、席数は減ったのに総額は増える、という逆転が起こります。
これら5つのうち、前の4つは以前から存在した無駄ですが、5つ目の「実行回数の増加」はAIエージェントの普及で新たに顕在化した論点です。人が手で操作していた頃は、処理回数は人間の作業スピードで自然に頭打ちになっていました。エージェントがその上限を外すと、便利になった分だけ回数が増え、従量課金がそれを拾います。だからこそ、席数を減らす話とセットで、実行回数に上限とアラートをかける話を進める必要があります。
棚卸しの手順：請求書・カード明細・SSOログインから実利用者を洗う
膨らんだコストを削るには、「契約しているつもりのSaaS」ではなく「実際に払っていて、実際に使われているSaaS」を突き合わせる棚卸しが要ります。中小企業で漏れなく洗い出すには、三つの情報源を突き合わせるのが実務的です。
一つ目は請求書です。ベンダーから届く請求を月単位で並べると、契約しているSaaSの全体像と課金単位が見えます。ただし、年払いのものや、代理店経由でまとまっているものは請求書だけでは拾いきれないことがあります。そこで二つ目、クレジットカードの明細を突き合わせます。担当者が個人裁量でカード決済している少額のSaaSは、経理の契約台帳に載っておらず、明細を見て初めて存在に気づく、というのが中小企業では珍しくありません。いわゆるシャドーITの温床です。三つ目はSSO（シングルサインオン）のログイン記録です。誰が、どのSaaSに、直近いつログインしたかが分かれば、契約上の席数ではなく「実際に使っている人数」が測れます。SSOを入れていない場合は、各SaaSの管理画面が持つ最終ログイン日時の一覧で代用できます。
この三つを突き合わせると、「請求は出ているのに誰もログインしていないSaaS」「台帳にないのにカードで払われているSaaS」「席は10あるのに実利用は3人のSaaS」といった、削減の候補が具体的に浮かび上がります。棚卸しは一度やって終わりではなく、退職や組織変更のたびにずれていくので、契約更新のタイミングに合わせて定点で見直す運用にしておくのが理想です。棚卸しから業務の自動化・システム統合まで一気通貫で相談したい場合は、DX・システム開発の観点で全体設計を検討できます。
ベンダーに投げる質問文（そのまま使える）
更新交渉や新規契約の商談で、聞きそびれると後から効いてくる論点があります。以下は、そのままメールや打ち合わせで使える質問文です。曖昧な回答が返ってきた項目こそ、契約前に文書で詰めておくべきポイントです。
- 「エージェントや外部ツールからAPI経由で利用する場合、課金の単位は席数ですか、それとも実行回数・処理量ですか。人の席とは別建ての費用が発生しますか。」
- 「従量課金部分に上限（キャップ）は設定できますか。設定できる場合、上限に近づいたときや超えたときにアラートは届きますか。」
- 「監査ログは何日間保持されますか。長期保持や外部への書き出しは追加費用ですか、標準機能ですか。費用が発生する場合、いくらですか。」
- 「価格を改定する場合、何日前までに通知される契約ですか。改定時にこちらが解約や乗り換えを判断する猶予はありますか。」
- 「解約する場合、何か月前の予告が必要ですか。最低利用期間や中途解約の違約金はありますか。」
- 「解約・移行の際、こちらのデータはどの形式（CSV・API・エクスポート機能など）で、いつまでに返還されますか。返還後、貴社側のデータは削除されますか。」
これらの質問は、相手を問い詰めるためのものではありません。むしろ、答えられるベンダーかどうかを見分けるための質問です。上限設定や監査ログ、データ返還条件を明快に答えられる相手は、エージェント時代の課金変化を自分たちでも整理できている、信頼に足るベンダーである可能性が高いといえます。ベンダーの見積もりや提案書そのものの妥当性を第三者に確認したい場合は、他社見積・提案書の発注前レビューを使うと、質問すべき抜けを補えます。
よくある誤解
契約更新の判断を鈍らせる思い込みが、いくつかあります。ここで正しておきます。
「席数課金なら予算は読める」 ——これは、人が画面を使う前提でだけ正しい話です。エージェントがAPI経由で処理を回す領域では、席数は据え置きでも従量部分が動くため、席の数を固定しても総額は読めません。予算を読むには、席数ではなく処理量を測る必要があります。
「使っていない席はいつでも減らせる」 ——契約によっては、席の削減が次の更新タイミングまで反映されなかったり、最低利用期間の縛りがあったりします。「いつでも減らせる」と思い込んで放置していると、減らしたいときに減らせず、次期間分を丸ごと払うことになります。減らせる条件とタイミングは、契約書で先に確認しておくべきです。
「値上げは通知が来てから考えればいい」 ——通知が届いた時点では、交渉や乗り換えの猶予がほとんど残っていないことがあります。値上げの通知期限が短い契約ほど、こちらの選択肢は狭まります。だから、通知が来る前に利用実態を測り、代替案を持っておくことが交渉力になります。
「SaaSはクラウドだからロックインされない」 ——技術的にいつでも解約できることと、実際に乗り換えられることは別です。データを扱いやすい形式で取り出せなければ、あるいは他システムとの連携を作り込んでいれば、事実上そのベンダーから離れられなくなります。ロックインは料金ではなく、データの持ち出し条件と連携の深さで決まります。
これらの誤解は、いずれも「席数」や「月額」といった目に見えやすい数字だけを見て、契約の条件面を読んでいないことから生まれます。エージェント時代に費用を左右するのは、席の数よりも、課金単位・上限・通知期限・解約条件・データ返還といった、契約書の条項のほうです。
GXOに相談する前に整理しておくこと
ここまでの項目を自社だけで埋めきれない、あるいは従量課金の試算や解約条件の読み解きで迷う場合は、契約更新や新規導入を決める前に、第三者の視点で棚卸しと契約レビューを行う価値があります。相談をスムーズにするために、次の三つを手元に用意しておくと話が早く進みます。
一つ目は、契約中のSaaSを一覧にした表です。課金単位・月額・更新月・実利用者数の4列だけでも構いません。二つ目は、自動化を検討している業務と、その月間処理件数の実測値です。三つ目は、ベンダーから届いている更新案内や値上げ通知、契約書の該当ページです。この三点があれば、「どこの課金が膨らむのか」「更新でどう交渉すべきか」を具体的に詰められます。要件整理の入り口としてはAI導入可否アセスメント、開発や統合まで見据える場合はシステム開発の発注前相談から始めるのが実務的です。
よくある質問（FAQ）
Q. 席数課金という仕組み自体が消えてしまうのですか。 A. 一斉に消えると考える根拠はありません。報道も、提供各社が席数課金を一律にやめると断定してはいません。人が日常的に画面を触るツールには席数課金が残り、機械が処理を担う業務ほど従量や成果に応じた料金へ移る、という二本立てが続くと見るのが実際的です。自社の各契約がどちらに属するかを、更新のたびに仕分けるのが現実的な対応になります。
Q. 最初の一歩は何をすればよいですか。 A. 契約中SaaSの一覧化です。特に「課金単位」と「実利用者数」の2列を埋めるだけで、席数課金のまま据え置けるものと、更新で条件が動きうるものが見分けられます。ツールの追加や乗り換えの検討は、その後です。
Q. まだエージェントを導入していなくても、いま確認する意味はありますか。 A. あります。むしろ導入前が最適なタイミングです。次の契約更新で、上限設定・監査ログの費用・データ返還条件を押さえておけば、後からエージェントを足したときに費用と説明責任の両面で慌てずに済みます。導入してから条件を交渉するより、更新の交渉材料として先に握っておくほうが有利です。
Q. 従量課金への変更を打診されたら、断るべきですか。 A. 一律に断る/受けるで判断するものではありません。自社の月間処理件数を実測し、席数課金と従量課金のどちらが安いかを試算したうえで決めます。処理量が少なく安定している業務は席数課金が有利なことが多く、変動が大きい業務は従量課金が合うこともあります。判断の前提は、あくまで自社の実測データです。
Q. 監査ログの費用まで気にする必要がありますか。 A. エージェントに処理を任せるなら必要です。エージェントが誰の権限で何を実行したかは、監査ログでしか後から追えません。保持日数が短かったり、長期保持が高額オプションだったりすると、インシデント時に追跡できず、後から想定外の費用が乗ります。更新時に保持日数と費用負担を確認しておくべき項目です。
Q. 情シスが兼任で、契約書まで読み込む余裕がありません。 A. 一覧化と実利用者の洗い出し（請求書・カード明細・SSOログイン記録の突き合わせ）は、業務側の担当者でも一次データを集められます。解約条件やデータ返還条項の読み解きなど、判断の要る部分だけを第三者に相談する切り分けが現実的です。
参考・出典
以下のURLは2026年7月10日に内容を確認しました。価格や課金モデル、法制度、ガイドラインは短期間で更新されることがあるため、契約や投資の判断を下す前に、各提供元の最新の公式情報にあたり直してください。なお、席数課金が崩れるという論点は業界の予測・観測であり、確定した事実ではありません。特定ベンダーの料金変更を裏づける一次情報が確認できたものではない点にご注意ください。
- ITPro「Agentic AI breaks the traditional SaaS seat licensing model」（Gartnerの予測を引用した二次報道）: https://www.itpro.com/software/agentic-ai-breaks-the-traditional-saas-seat-licensing-model-now-its-up-to-vendors-to-ditch-legacy-dashboards-and-build-with-agents-in-mind
- NIST AI Risk Management Framework（AIリスク管理・監査ログ設計の参考）: https://www.nist.gov/itl/ai-risk-management-framework
- OWASP GenAI Security Project（生成AI・エージェント利用時のセキュリティ参考）: https://genai.owasp.org/
