※本記事は継続的に最新情報へアップデートしています（履歴は末尾参照）。
5年前なら、SaaSの成長はシンプルでした。顧客が増え、チームが増えれば、席も増え、売上も伸びる。
ところがAIエージェントが一次対応・分類・入力を担い始めると、仕事は増えているのに、ログインする人は減り始めます。 問い合わせは増える。処理件数も増える。けれど、席は増えない。このズレが、シート圧縮です。
シート課金とは、SaaSの利用人数に応じて料金が決まる課金モデルです。 本記事では、AIによって席と成果が分離する構造、SaaSベンダーとユーザー企業が取るべき対策を整理します。
この記事の結論：
シート圧縮とは、AIエージェントによって「席」と「成果」が切り離され、シート課金SaaSの成長前提が揺らぐ現象です。
- シート課金とは：SaaSの利用人数、つまり「席」の数に応じて料金が決まる課金モデルです。
- 何が変わるのか：AIエージェントが一次対応・分類・入力を担うと、仕事量は増えても、必要な席数は増えにくくなります。
- ただし一律に危ないわけではない：Atlassianのように、AIを「席の価値を上げる設計」に変えた企業では、むしろ席数や利用量が伸びるケースもあります。
- 対策は“席を守る”ことではない：価値単位を「席→使用量→タスク→成果」へ段階的に移すことが重要です。
この記事の著者・監修者 ケニー狩野（Kenny Kano）
役職：(株)アープ取締役。Society 5.0振興協会・AI社会実装推進委員長。中小企業診断士、PMP。著書『リアル・イノベーション・マインド』
シート課金とは何か？ なぜ今「シート圧縮」がSaaSの収益を直撃するのか
シート課金の前提が揺らぎ始めた背景には、AIエージェントによる業務代行と、市場の急速な再評価がある。
2026年前半、海外メディアではAIエージェントによるソフトウェア株の売りを「SaaSpocalypse」と呼ぶ議論が広がりました。2月初旬には、SaaS・データ・ソフトウェア関連企業から約3,000億ドル規模の時価総額が失われたとの報道もあります。
もっとも、これは「SaaSが終わる」という単純な話ではありません。その後は好決算やAI活用の進展を受け、ソフトウェア企業への見方が揺り戻す場面もありました。市場が見ている本質は、AIエージェント時代に、SaaSがどの単位で価値を課金するのかです。
シート課金（per-seat pricing）とは、SaaSの利用人数、つまり「席」の数に応じて料金が決まるモデルです。たとえば、月1万円/席のCRMを20人で使えば月20万円、10人なら月10万円という考え方です。
シート圧縮（Seat Compression）とは、AIエージェントや業務自動化によって必要な利用者数が減り、成果が維持されてもSaaSの売上が伸びにくくなる現象です。営業20人で使っていたCRMを、AIによる入力・見積作成・一次フォローの自動化によって10人で回せるようになれば、成果は維持されても契約席は20→10に減ります。これがシート圧縮です。
補足：「シート圧縮（Seat Compression）」という語は、現時点で厳密な業界標準用語ではありません。本記事では、海外のSaaS課金・AIエージェント・投資家向け分析で語られている論点を、日本企業向けに整理した概念として扱います。
「ユーザーが増えれば売上も増える」は、いつまで真実か
シート課金は、SaaSの“黄金律”でした。顧客企業が成長して従業員が増えれば、席が増え、売上も増える。ところがAIが「人の代わりに業務を回す」段階へ進むと、この相関がほどけます。増えるのは人ではなく、エージェント（実行主体）になるからです。
重要なのは、シート圧縮が「一部のコスト削減の話」ではなく、課金単位そのものが時代に合わなくなる可能性をはらむ点です。
もちろん、すべてのSaaSが一律に崩れるわけではありません。人の操作が前提のプロダクトも当面は残ります。
ただし、チケット処理・文章作成・一次レビュー・定型オペレーションなど、AIエージェントが得意な領域を多く抱えるSaaSほど、席と成果の分離が早く進みます。
さらに重要なのは、シート圧縮が「AIエージェントを本格導入してから」だけ起きる現象ではない点です。AI活用が社内で話題になった時点で、調達部門は次の問いを前倒しで投げます。「今の席数は本当に必要か」「未稼働の席はどれか」。更新前の棚卸しと削減交渉そのものが、圧縮の引き金になります。
何が起きているか：シート圧縮のメカニズムを分解する
シート圧縮は、成果を生む主体が「人」から「AIエージェント」へ移り始めたことで起きる。
図：「人が操作することで売上が上がる」従来モデルから、「AIエージェントが介在することで席数が減っても成果が維持される」構造への変化を視覚的に示していますシート圧縮は、乱暴に言えば「成果の生産能力が、席数から切り離される」現象です。これを理解するために、まず“席が売上に直結する”前提条件を分解します。
図の要点まとめ：
・従来は「人が操作する＝席が増える＝売上が増える」の相関が強かった
・AIエージェントがタスクを肩代わりすると、成果と席数が分離する
・対策は「席を守る」より、価値の単位を“移す”こと（使用量／タスク／成果）
なぜAIで圧縮が起きるのか（3つのドライバー）
ドライバーは大きく3つです。ポイントは「AIが賢いから」だけではありません。運用・購買・組織の動きが連鎖して、圧縮を加速させます。
① 1人あたりの処理能力が上がり、席が余る
AIエージェントがチケット分類、一次対応、文書の下書き、要件整理、一次レビューを担うと、同じチーム人数でも処理量が増えます。その結果、以前は“人数”で回していた業務が、より少ない人員と席で回るようになります。
ここで発生するのは「人が減る」だけではなく、「システムにログインする主体が減る」という変化です。
② 低利用席が可視化され、棚卸しが起きる
生成AIの普及は、IT予算の再配分を伴います。新しいAI予算を作るには、どこかを削る必要がある。そこで最初に見直されるのが、低利用席・放置アカウント・重複ツールです。調達部門が「10〜20%の削減」をまず狙う、という動きは現場感としても自然です。
③ レイオフ/採用抑制が、そのまま席減に直結する
企業がAIで効率化すると、採用計画が変わります。ここでSaaS側に起きるのが“共食い”です。顧客が効率化するほど、席が増えない。
席課金の成長エンジンが、顧客の成長ではなく「顧客のヘッドカウント増」に依存していた場合、圧縮は避けにくくなります。
こうした構造が顕在化した結果として、議論の焦点は次に寄っています。“エージェントが増えるほど売上が増える”設計にできているか？
（As of 2025–2026 / 市場分析の論点）。
ハイライト：影響を受けるSaaS／受けにくいSaaSをどう選別するか
※重要（免責）：
本記事はシート課金SaaSにおける「シート圧縮（Seat Compression）」を構造として解説する一般論です。本文中で触れるツール名・カテゴリ例は概念説明のための代表例であり、特定企業・特定製品の優劣、将来の売上、価格改定の成否等を断定するものではありません。実際の影響度は、導入範囲・運用設計・契約条件・最新仕様・データ（利用ログ／更新交渉）により変動します。
この課題の肝はここです。シート圧縮は「AI導入の必然」だとしても、同じSaaSでも“圧縮される側”と“されにくい側”が分かれます。ただし、2026年時点では「カテゴリ名だけ」で安全／危険を決めるのは危険です。
結論：操作UI（人がログインして処理する画面）よりも、裏側のタスク実行（分類・一次対応・入力・受付）で価値が出る比率が高いSaaSほど、席と成果が分離し、圧縮が早く出ます。
補足：共通広場型アプリ（Shared Commons）は「操作量」ではなく協働の集約が価値の中心になりやすく、席数“だけ”に単純比例しにくい傾向があります。ただし2026年現在、SlackやZoomはAIエージェントの活動舞台としてもハブ化が進んでおり、人主導からエージェント主導のUIへの過渡期にあります。
直感で分かる例：
- 圧縮が遅いプロダクト：Figma / Miro など、人間の創造的協働や視覚的な合意形成そのものが価値になっているSaaSです。ここでは、AIが補助しても「人が集まり、見て、判断する」価値が残りやすく、席ゼロにはなりにくい領域です。
- 分類に注意が必要なプロダクト：Slack / Zoom などのコミュニケーション層は、かつては「人が集まる広場」として席が残りやすい領域でした。しかし2026年現在は、AIエージェントが会話・会議・ワークフローのハブとして動く方向に進んでおり、席課金からエージェント課金・使用量課金へ移行する最前線でもあります。
- 圧縮が早いプロダクト：サポート、受付、入力、分類、一次対応など、「処理を終わらせること」が価値になっているSaaSです。ここではAIエージェントが件数をこなすほど、人がログインする理由が薄くなり、席数は削減候補になりやすくなります。
※上記は構造の説明のための代表例であり、特定製品の優劣・将来を断定する意図はありません。影響度は導入範囲、運用設計、AI機能の実装状況、契約体系で変わります。
| 評価軸 | 圧縮が遅い／価値が残りやすい | 過渡期／分類に注意 | 圧縮が早い／棚卸しされやすい |
|---|---|---|---|
| 価値の中心 | 創造的協働・視覚的合意形成（設計・レビュー・意思決定） | 人の会話＋AIエージェントの活動舞台（会議・チャット・ワークフロー） | 処理が回ること（分類・一次対応・定型文・受付・入力） |
| アウトプットの測り方 | 質・合意・意思決定（席＝参加者の価値が残る） | 会話量・会議数・AI実行回数・ワークフロー消化量 | 件数・処理時間（席と切り離しやすい） |
| 代替のされ方 | AIは補助（Copilot）になりやすい | AIが会話・会議・実行のハブになりやすい | AIが実行主体（Agent）になりやすい |
| 見分ける一問 | 「人が操作しないと価値が出ない」のか、「AIが処理しても価値が出る」のか。さらに、AIで席の価値が下がるのか、逆に高まるのかを見極める | ||
1分でできる“圧縮リスク”セルフチェック
- 成果が「件数」や「処理時間」で測れる（例：チケット件数、一次返信時間）
- 手順がテンプレ化されている（分類・受付・定型文が多い）
- 例外対応だけ人が残れば回る
- 「UIを触る理由」が実は“処理のため”になっている
YESが多いほど、席と成果が分離しやすく、更新時の“席の棚卸し”が起点になりやすいです。
危険度を見抜くKPI：シート圧縮は数字で予兆が出る
ここからが実務です。シート圧縮は、契約・利用ログ・更新交渉に必ず痕跡が出ます。
結論：「低利用席の増加」と「更新時の削減要求」が同時に増えたら、圧縮は“すでに始まっている”サインです。
| 評価軸 | 圧縮が起きにくい状態 | 圧縮が進みやすい状態 |
|---|---|---|
| アクティブ率（席） | 購入席の大半が週次で使われる（利用者が分散） | 低利用席が目立つ／使う人が固定／部門偏りが大きい |
| 更新交渉の論点 | 機能追加・拡張（席追加や上位プラン）が中心 | 「席の棚卸し」／「同等成果で席削減」／“席単価の再交渉”が中心 |
| NRR（実態） | 既存顧客内で拡張（アップセル・席増が回る） | ダウングレードが増える／拡張が止まる／価格改定が通らない |
| 判定根拠 | 席の未稼働が増え、更新で削減要求が増えるほど、席課金の伸び代は先細ります | |
押さえるべき追質問（現場ヒアリング用）
- このプロダクトは「人が操作するUI」が価値の中心か？それとも「裏側のタスク実行（自動化）」が価値の中心か？
- 更新交渉で「席の棚卸し」が論点になったのはいつからか？（直近2回の更新議事録で確認）
- AI活用が進んだ部門ほど、席が減っていないか？（部門別アクティブ率と、一次対応・定型作業の自動化率で突合）
反証：圧縮は「カテゴリ」だけでは決まらない――Atlassianの逆説
理論上、ITSMやチケット処理系SaaSは「圧縮が早い側」に分類されやすい領域です。しかし、Atlassianの2026年Q3決算は、単純な席減少ストーリーとは異なる現実を示しています。同社はCloud売上11億ドル超・前年比29%増を達成し、Service CollectionはARR 10億ドル超、前年比30%超成長。さらにTeamwork Collection導入顧客は席数を10%以上拡大し、Rovo顧客のAIクレジット利用も月次20%超で伸びています。
ここに本質があります。圧縮されるかどうかは「カテゴリ」だけで決まるのではありません。 AIを「席を奪うもの」として実装するのか、それとも「席の価値を上げるもの」として再設計できるのか。その差が、シート圧縮の影響を分けます。
「席」から「成果」へ：4ステップで価値単位を移すロードマップ
シート圧縮への対策は、席を守ることではなく、課金と価値の単位を段階的に引っ越すことだ。
本記事のコアメッセージはシンプルです。シート圧縮に負けないSaaSは、「席」を守るのではなく、価値の単位を次の4ステップで“引っ越し”させていきます。
- 席：ログインする人の数
- 使用量：処理件数・生成回数・ワークフロー実行数
- タスク：自動化された業務単位
- 成果：解決チケット・商談前進・SLA遵守などのビジネスアウトカム
以下では、SaaSベンダー／ユーザー企業の両方の立場から、この「席→使用量→タスク→成果」への移行ステップを具体的に解きほぐします。
SaaSベンダー向け：席→使用量→タスク→成果（段階移行）
提供側の本質は「席を守る防衛戦」ではなく、価値の単位を“席以外”へ移す設計です。ただし、いきなり成果報酬に飛ぶのは多くのSaaSで現実的ではありません。実務では、次の順番が安全です。
まず前提（本記事で挙げた例の読み替え）
- 圧縮が早い側：一次対応・分類・受付・入力の比率が高い領域。ただし、AtlassianのようにAIで席の価値を高める設計ができると、逆に利用量や席数が伸びるケースもあります。
- 圧縮が遅い側：創造的協働・視覚的合意形成・意思決定が中心（例：Figma / Miro など）
- 過渡期：Slack / Zoom などのコミュニケーション層。人が集まる広場であると同時に、AIエージェントが動く業務ハブになりつつあります。
※ツール名は構造の説明のための代表例です。個別の影響度は導入範囲・運用設計・AI機能・契約体系で変わります。
ステップ1：席の実態を“棚卸し前”に可視化する
圧縮の主導権を顧客の調達部門に渡すと、削減圧力は強く出ます。だからこそ、棚卸しが来る前に、アクティブ率・利用頻度・権限設計を可視化し、「削る」ではなく「再配分」の選択肢を先に提示しましょう。
- サポート系SaaSの示し方：エージェント（人）ごとのログではなく、チケットの流れ（分類→一次返信→解決→再オープン）で価値を見せる
- CRM系SaaSの示し方：入力席の稼働率だけでなく、商談前進に寄与した自動化（追客・記録・要約）を「実行回数」で出す
ステップ2：席プール／ロール段階化で“席の弾力”を作る
典型パターンは「一部のヘビーユーザーが価値を生み、残りは薄く使う」です。席を固定せず、役割（ロール）や機能で段階化し、席の入れ替えを許容する運用にします。削減要求が来ても“価値を落とさず”調整できる状態が理想です。
- 受付・ITSM領域：受付・承認・閲覧などをロールで分け、「フル席」＋「ライト席」の構成にする
- サポート領域：一次対応担当とレビュー担当を分け、例外対応だけフル席に寄せる（＝削減要求を“設計変更”に変える）
ステップ3：課金を“席”以外へ拡張する（ハイブリッド化）
次に、使用量（例：処理件数、生成回数、ワークフロー実行回数）やタスク単位のメーターを導入します。ここで重要なのは、顧客にとって「予算化しやすい」こと。完全従量は嫌われやすいので、上限付き（バンドル）や段階課金が現実解です。
おすすめの“逃げ道付き”メーター設計（例）
- サポート系SaaS：解決チケット数、自動応答の採用回数、エスカレーション回避数（＝人を呼ばずに終えた数）
- ITSM・受付系SaaS：受付→分類→割当の自動化回数、SLA短縮分のバンドル
- CRM系SaaS：自動ログ更新、メール下書き、要約生成などの「実行回数」＋月額上限（バンドル）
ステップ4：エージェントの価値を“成果”に接続する
最終形は成果連動ですが、成果定義が難しい領域もあります。そこで、成果に近い代理指標（KPI）を先に用意し、更新交渉で「席」ではなく「成果（に近い指標）」を会話の中心へ移します。
- サポート系SaaS：一次解決率、平均処理時間、再オープン率、CSAT改善
- ITSM・受付系SaaS：SLA遵守率、バックログ消化速度、一次振り分け精度
- CRM系SaaS：商談滞留日数、フォロー漏れ率、入力工数削減（人時）
すでに実例があります。IntercomのFinは、1アウトカムあたり0.99ドルの成果ベース課金を採用しています。Intercomは、顧客が問題解決を確認した場合、Finの応答後に追加支援を求めなかった場合、またはワークフローを完了した場合を「アウトカム」と定義しています。これは、席ではなく「解決された仕事」に値付けする方向への明確な移行です（Fin pricing: Outcomes / As of 2026）。
これにより、AIが進むほど顧客価値が上がり、売上も上がる構図に近づけます。逆に言えば、席課金だけに閉じたままだと、AIの普及が“成長の天井”になり得ます。
ユーザー企業向け：削減だけで終わらせない「購買・運用」
ユーザー企業の勝ち筋は「席を削って終わり」ではありません。重要なのは、AIで浮いた原資（席・工数・外注費）を、どこに再投資して成果を伸ばすかです。実務は次の3点に集約されます。
前提：ツールによって“削減の効き方”は違う
- 圧縮が早い領域：一次対応・分類・受付・入力など、処理件数や作業時間で価値を測りやすい領域
- 圧縮が遅い領域：創造的協働・共同設計・意思決定など、人間の参加そのものに価値が残りやすい領域
- 過渡期の領域：チャット・会議・ワークフローなど、AIエージェントの活動ハブへ変わりつつある領域
※実際の削減余地は運用設計と利用実態で変わります。
① 棚卸しは“削減”ではなく“再配分”として設計する
低利用席を機械的に切るだけだと、現場は「必要になったら増やせばいい」と考え、運用が崩れます。安全なやり方は、先にロール（役割）と権限を整理し、席の“回し方”を作ってから棚卸しすることです（As of 2026 / 一般的なSaaS運用）。
- サポート領域：一次対応（自動化）／例外対応（人）／品質レビュー（人）に分け、フル席は例外とレビューに寄せる
- 受付・ITSM領域：受付・承認・閲覧を分離し、「フル席」「ライト席」「閲覧席」を定義してから席を整理する
- CRM領域：入力担当を減らす前に、“誰が最終的に責任を持って更新するか”（責任者ロール）を決めてから席を削る
現場トラブルを防ぐ一言
「席を減らす」ではなく、「必要な人に必要な権限で席を回す」がゴールです。削減は“結果”としてついてきます。
② 価格交渉は「席」ではなく「アウトカムの代理指標」を握る
更新交渉のカードは席数だけでは弱いです。強いのは、“席を減らしても成果が落ちない（むしろ上がる）”を説明できるKPIです。席数の話を「値引き交渉」に矮小化せず、アウトカムの代理指標を握って交渉の軸を変えます。
| 領域（例） | おすすめ代理KPI | 交渉での言い換え |
|---|---|---|
| サポート領域 | 一次解決率、平均処理時間、再オープン率、CSAT | 「席ではなく、解決効率で価値を評価したい」 |
| 受付・ITSM領域 | SLA遵守率、振り分け精度、バックログ消化速度 | 「SLAと自動化が成果。席は最適化したい」 |
| CRM領域 | 商談滞留日数、フォロー漏れ率、入力工数（人時） | 「入力席より、商談前進に効く条件で契約したい」 |
結論：「席を減らしたい」ではなく、「成果（に近いKPI）で契約を再設計したい」と言えると、値引き以外の落とし所（プラン変更、ハイブリッド課金、上限バンドル）が作れます。
③ AI予算は“浮いた席”の再配置で作る
AI導入の予算を新規に確保できない場合、最も通りやすいのは「浮いた席の原資を、AIで増やせる成果に戻す」設計です。ポイントは、削減額を“消す”のではなく、成果に直結する場所へ“戻す”ことです。
- サポート領域：削減した席の一部を、ナレッジ整備・FAQ改善・品質レビューに再投資（＝自動化が加速して二段階で効く）
- 受付・ITSM領域：削減分を、分類ルール・テンプレ・ワークフロー整備に再投資（＝SLAが落ちずに圧縮できる）
- CRM領域：削減分を、営業プロセス標準化・自動フォロー・データ品質に再投資（＝入力削減でも失注しにくくなる）
社内合意を取りやすい言い方
「SaaS費を削る」のではなく、「SaaS費の内訳を“人の席”から“成果が増える自動化”へ組み替える」。これが通りやすい設計です。
結局、SaaSは死ぬのか？――“単位”が変わるだけだ
SaaSが終わるのではなく、価値を測る単位が「席」から「成果」へ移っていく。
シート圧縮は「AIが便利になった」という話ではなく、SaaSの“価値の単位”が変わる話です。これまでSaaSは「従業員数の増加＝席の増加＝売上の増加」という成長方程式に乗ってきました。
しかしAIエージェントが業務を回すほど、席（人）と成果（アウトプット）は分離し、席課金は伸びにくくなります。だからこそ重要なのは、まず影響を受けるSaaS／受けにくいSaaSを見分け、議論を「席」から「価値単位」へ移すことです。
落とし穴：AI機能が“自分の売上”を食べ始める瞬間
多くのSaaSが直面し始めているのは、「AI機能を足したことでユーザーの生産性が上がり、その結果として席数が削られ、ARRが減る」というパラドックスです。
「AI機能を足したのに席課金のまま」だと、顧客の効率化がそのまま減収トリガーになります。だからこそ、AIを実装するタイミングで、「席→使用量→タスク→成果」への課金単位の見直しを同時に設計することが、生き残りの前提条件になります。
最後にもう一度：見分け方はこれだけ
- 圧縮が早い：定型タスク処理が価値。AIが処理件数をこなすほど、人がログインする理由が薄くなる
- 圧縮が遅い：創造的協働・視覚的合意形成が価値。AIが補助しても、人間の参加と判断が残りやすい
- 分類に注意：コミュニケーション層やITSM領域。AIの実装次第で、席を削る方向にも、席の価値を高める方向にも振れる
※上記は構造理解のための整理です。個別の影響度は導入範囲・運用設計・AI機能・契約体系で変わります。
CxO向け（ユーザー企業）
- 次回更新までにやるべきは「棚卸し」ではなく「再配分の設計」です。先にロール/権限/席プールを整え、削減しても現場が回る形を作ってから席を最適化してください。
- 削減で浮いた原資は“消す”のではなく、ナレッジ整備・ワークフロー整備・データ品質など、AIで成果が増える場所に再投資すると社内合意が通りやすくなります。
開発統括/リード向け（SaaSベンダー）
- 席を守る防衛戦ではなく、価値の単位を移す設計が必要です。いきなり成果課金に飛ばず、席→使用量→タスク→成果の段階移行ロードマップを作りましょう。
- 指標（KPI）を先に引っ越すのがコツです。席数ではなく、タスク実行回数・品質（一次解決率、SLA、再オープン率など）を、更新交渉の共通言語にしてください。
実装担当向け（運用/IT購買）
- 利用ログを“更新交渉に耐える形”で整備してください（アクティブ率、利用頻度、機能利用、部門別偏り）。
- 予兆は「低利用席の増加」×「更新時の削減要求」です。この2つが同時に増えたら、圧縮は“すでに始まっている”と判断し、ロール設計と契約設計を同時に見直しましょう。
今日のお持ち帰り3ポイント
- シート圧縮は、AIで「席」と「成果」が分離することで起きる構造問題。
- カテゴリ名だけで危険度は決まらない。Atlassianのように、AIで席の価値を高める設計ができると、むしろ利用量・席数が伸びるケースもある。
- 対策は“席を守る”より“価値の単位を移す”（席→使用量→タスク→成果）。
専門用語まとめ
- シート課金（per-seat pricing）
- ユーザー数（席）に応じて料金が決まるSaaSの基本モデル。導入の分かりやすさが強みだが、成果と席が分離すると伸びが止まりやすい。
- シート圧縮（Seat Compression）
- AI導入や業務自動化、棚卸しにより必要席数が減り、ARR成長が鈍化・減収に転じやすくなる現象。更新交渉と利用ログに予兆が出る。
- AIエージェント（Agentic AI）
- 人の指示を待つ補助（Copilot）に留まらず、タスクを計画し実行まで担う自律型AI。業務処理主体が「人」から「エージェント」に移る。
- ARR（年間経常収益）
- サブスクの年間換算売上。シート課金では席数と強く相関しやすいが、圧縮が進むと相関が弱まり、成長性評価にも影響が出る。
- NRR（Net Revenue Retention）
- 既存顧客が翌年にどれだけ売上を残すかを示す指標。アップセルとダウングレードを含むため、シート圧縮の影響が出やすい。
- アクティブ率
- 購入席のうち、実際に利用されている比率。低利用席が増えるほど、更新時の削減要求が出やすい（棚卸しの材料になる）。
- ハイブリッド課金
- 席課金に、使用量・タスク・機能レベルなど別の単位を組み合わせる設計。いきなり成果報酬に飛ばず、移行の摩擦を減らせる。
- 共通広場型アプリ（Shared Commons）
- 顧客組織のメンバーが集まり、協働・合意形成・共同設計を行う「共有の場」。価値は操作量より協働の集約に依存し、席数だけに単純比例しにくい。
- 成果ベース課金（Outcome-based pricing）
- 利用者数ではなく、解決件数・完了タスク・成果指標などに応じて料金を決めるモデル。AIエージェント時代の有力な課金単位として注目される。
よくある質問（FAQ）
Q1. シート圧縮とは結局なに？
A1. AIや棚卸しで必要ユーザー数（席）が減り、シート課金SaaSの売上が伸びにくくなる（または減る）現象です。
Q2. 何が変わったの？（なぜ今？）
A2. AIエージェントが定型タスクを実行し、成果と席数が分離し始めたことで、席＝価値という前提が弱くなりました。
Q3. どうやって早期に気づける？
A3. 低利用席の増加と、更新交渉での「席の棚卸し・削減要求」がセットで出てきたら警戒信号です。
Q4. すべてのSaaSが危ないの？
A4. 危険度はプロダクト特性次第です。さらに、同じカテゴリでもAIを「席を奪うもの」として実装するか、「席の価値を上げるもの」として再設計するかで影響は変わります。
Q5. まず何から始める？
A5. 席の実態（アクティブ率・低利用席・重複）を可視化し、席プール/段階化で運用の弾力を作ったうえで、課金単位をハイブリッド化します。
Q6. 投資家視点では、シート圧縮はどこに現れる？
A6. NRRの鈍化、シートベースのアップセル減少、既存顧客内の席数拡張の停滞に現れます。一方で、AtlassianのようにAI活用によって席数やAIクレジット利用が伸びるケースもあります。したがって投資家は、単に「AIで席が減るか」ではなく、AIが既存顧客内の拡張を押し上げているか、逆にライセンス最適化を促しているかを見る必要があります。
主な参考サイト
本記事は一次情報・公式情報・主要メディアの報道を軸に執筆しています。公式発表・価格ページ・決算レター・市場分析を優先し、検証可能性を担保します。
- Our Q3 FY26 letter to shareholders（Atlassian / 2026）
- Fin pricing: Outcomes（Fin / Intercom / 2026）
- Intercom Pricing（Intercom / 2026）
- $300 Billion Evaporated. The SaaS-Pocalypse Has Begun（Forbes / 2026）
- SaaS As We Know It Is Dead: How To Survive The SaaS-Pocalypse（Forrester / 2026）
- Taking Control of Enterprise Software Costs（BCG / 2024）
- Agentic AI: The next frontier in gen AI（McKinsey / 2025）
合わせて読みたい
更新履歴
- GSCデータをもとに、SEOタイトル・メタディスクリプション・冒頭定義・内部リンク導線を改善。さらにSaaSpocalypseの市場文脈、Atlassianの反証、Intercom Finの成果課金事例、Slack/Zoom分類の精緻化、投資家向けFAQを追加
- 初版公開
