「シートを何人分買うか」から「AIが読めるか」へ ── SaaSの評価軸とBizOpsの仕事が同時に変わる

株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。

御社にこんな心当たりはありませんか？

• SaaSを契約するとき、「何人分のシートを買うか」を最初に決めている
• 営業から「全社導入なら単価が下がります」と言われ、人数から逆算して予算を組んでいる
• 一方で、AIエージェントに任せる業務が増え、画面を直接開く人が減ってきているのに、契約の考え方は変わっていない
• 「AIに仕事を教える」作業が発生し始めているが、誰がその教材を作るのか決まっていない

一つでも心当たりがあるなら、今日の話は実務に直結します。

SaaSの評価軸が変わろうとしています。「人間が何人使うか」から「AIが正しく読み書きできるか」へ。この変化は、SaaSの選び方だけでなく、BizOps（部門を横断して事業のオペレーションを設計する機能）の仕事そのものを変えます。

私自身、月次の請求書作成や朝の情報収集を、AIエージェントに任せる仕組みとして実際に運用しています。この記事では、その具体的なやり方も含めてお話しします。

なお、シート課金というモデルそのものへの疑問は、以前こちらの記事で書きました。

シート課金のSaaSを疑う－SaaSの価値構造が変わる時代に企業はどう備え、BizOpsはどう変革をしていくか－

前回は「この課金モデルはいずれ揺らぐ」という問題提起までで止めていました。今回はそこから一歩進めて、では何を基準にSaaSを選び直し、社内で何を作るのかという実装の話をします。

この記事の要点（3行サマリ）

• シート課金は「人間が画面を操作する」ことを前提にした課金モデル。AIエージェントが操作を代行し始めると前提が崩れ、SaaSの評価軸は「UIの使いやすさ」から「APIの充実度」へ移る
• Skill（AIが読める業務マニュアル）を書けるかどうかが、これからのBizOpsの中核スキルになる。月次請求書作成・朝の情報収集を実際にSkill化し、実行をAIエージェントに任せている
• AIが代替するのは「操作」であって「設計」ではない。何を自動化し、何を人間の判断に残すかを決める力の価値はむしろ上がる

目次

1. シート課金とは何か、なぜ今まで成り立っていたのか
2. なぜシート課金は成り立たなくなるのか？
3. SaaSからBaaSへ ── 評価軸は「画面」から「バックエンド」に移る
4. Skillとは何か？ ── AIが読める業務マニュアル
5. 実際に使っているSkill：月次請求書と朝のダッシュボード
6. AIは何を代替し、何を代替できないのか？
7. BizOpsの仕事はどう変わるか
8. 経営者に伝えたいこと ── BizOpsはコストセンターではない
9. 今日からできること
10. よくある質問（FAQ）

1. シート課金とは何か、なぜ今まで成り立っていたのか

シート課金とは、SaaSを利用する人数（アカウント数）に応じて料金が決まる課金方式のことです。Salesforce、HubSpot、Notionをはじめ、多くのSaaSがこの方式を採用しています。利用者が10人なら10人分、100人なら100人分の料金を払う。人数が増えれば増えるほど、SaaS側の売上が伸びる仕組みです。

このモデルは、ある前提の上に成り立っています。

「人間がブラウザを開き、SaaSの画面を操作する」という前提です。

ログインし、ダッシュボードを見て、データを入力し、レポートを出力する。この一連の操作こそがSaaSの価値提供の中心であり、だからこそ「何人が操作するか」を基準に課金するモデルが成立してきました。

BizOps担当者がSaaSを選ぶときも、この前提に沿って判断してきました。画面が直感的か。操作を覚えるのに研修が要らないか。現場が迷わず使い始められるか。「使いやすさ」は、導入の成否を分ける最重要ポイントだったのです。

2. なぜシート課金は成り立たなくなるのか？

この前提を揺るがしているのが、AIエージェントです。

AIエージェントとは、人間の指示を理解し、複数のツールやサービスを組み合わせて業務を自律的に実行するAIのことです。人間がSaaSの画面を開いてクリックする代わりに、AIがAPI（ソフトウェア同士がデータをやり取りする窓口）を通じてSaaSを操作します。

一つ、考えてみてください。

営業担当者が毎朝SFA（営業支援システム）にログインし、商談の進捗を確認し、タスクを更新し、レポートを見る。この一連の作業をAIエージェントが代行するようになったら、どうなるでしょうか。

AIエージェントがSlackやメールでサマリーを通知し、「この商談は今週フォローが必要です」と提案してくれる。営業担当者はその提案を確認し、承認するだけで済むようになります。SaaSの画面を直接開く頻度は、確実に減っていきます。

画面を「見る人」「操作する人」が減る。つまり、シート数が減るのです。

これは、SaaSベンダーにとっては収益構造の危機です。シート課金の土台である「人間がUIを操作する」という前提そのものが崩れるからです。一方、発注する企業の側から見れば、SaaSに求める価値の重心が変わることを意味します。

3. SaaSからBaaSへ ── 評価軸は「画面」から「バックエンド」に移る

AIが人間の代わりにSaaSを操作する世界では、SaaSの「画面のきれいさ」や「操作のわかりやすさ」の価値は相対的に下がります。AIにとって、UIはどうでもいい。AIが見ているのは、APIのエンドポイントと、そこから返ってくるデータの構造だけです。

代わりに価値が上がるのは、SaaSの「バックエンド」――データの信頼性、APIの充実度、自動化基盤の柔軟性です。

私はこの変化を「SaaS（Software as a Service）からBaaS（Backend as a Service）への価値移転」と呼んでいます。BaaSとは、AIエージェントがAPIを通じてデータとロジックに直接アクセスし、業務を実行する基盤としてのソフトウェアのことです。SaaSのS（Software＝人間が使うソフトウェア）が、B（Backend＝AIが使う基盤）に置き換わっていくイメージです。

この変化は、SaaSを選ぶときの評価軸を根本から変えます。

誤解のないように補足します。UIが不要になるわけではありません。人間が確認・承認・例外対応を行う場面は残ります。しかし、SaaSの「主な操作者」が人間からAIエージェントに移っていく領域は確実に広がります。そのとき選ぶべきは、「人間にとって使いやすいSaaS」ではなく「AIにとって扱いやすいSaaS」です。

4. Skillとは何か？ ── AIが読める業務マニュアル

評価軸がAPIに移るなら、AIはどうやって「何をすべきか」を知るのでしょうか。

答えが「Skill」です。Skillとは、業務プロセスをAIエージェントが実行できる形式に落とし込んだ指示書のことです。「何を」「どの順序で」「どのツールを使って」「どんな条件で」実行するかを、構造化した形式で記述します。プロンプト（AIへの指示文）と業務手順とツール接続情報を一つにまとめた、いわば「AIが読める業務マニュアル」です。

従来の業務マニュアルとの違いを、飲食店にたとえて説明します。

従来の業務は、シェフが自分で材料を切り、火加減を調整し、盛り付けまで行う状態です。マニュアルは「玉ねぎをみじん切りにし、中火で5分炒める」という文章で書かれ、シェフ自身が読んで実行します。

Skillベースの業務は、シェフがレシピを書き、調理ロボットに実行させる状態です。シェフの仕事は「何を作るか」「どういう手順で作るか」を設計すること。包丁を握るのはロボットです。レシピ（Skill）の精度が、そのまま料理の品質を決めます。

この比喩に沿うと、BizOpsは「レストランのヘッドシェフ兼メニュー開発責任者」にあたります。一つひとつの調理を自分の手で行うのではなく、レシピを設計し、調理ロボットに配布し、料理の品質を監督する。ロボットがミスをすれば、レシピを直す。この役回りです。

5. 実際に使っているSkill：月次請求書と朝のダッシュボード

理屈だけでは実感が湧きません。私自身が1人会社の代表として実際に運用しているSkillを、二つ紹介します。

月次請求書作成のSkill

以前は、毎月こういう作業をしていました。Googleスプレッドシートの請求管理表を開き、対象を目視で確認し、会計SaaSの画面で一件ずつ請求書を作り、Slackで完了を報告する。この一連に、毎月それなりの時間がかかっていました。

今は、この業務をSkillとして定義しています。

1. Googleスプレッドシートの請求管理シートから、当月の請求対象を抽出する
2. 同一取引先に複数行がある場合は、1件の請求書にまとめる
3. 会計SaaSの請求書APIを使って、請求書を自動作成する
4. 作成完了後、Slackの指定チャンネルに通知を送る

この一連の処理を、私は「請求書を作成して」とAIエージェントに指示するだけで実行できます。私の仕事は、スプレッドシートを目視確認しながら手を動かすことから、AIが作成した請求書の内容を確認し承認することに変わりました。

朝のダッシュボードSkill

もう一つは、朝の情報収集です。以前は、複数のGoogleカレンダー、Slack、Gmailに個別にログインし、今日の予定と対応事項をかき集める作業を毎朝行っていました。

今はこう定義しています。

1. 複数のGoogleカレンダーから今日の予定を取得する（アカウント間の重複は除外する）
2. Slackの未読メッセージを要約する
3. Gmailの未読メールから、対応が必要なものを抽出する
4. これらを整理し、朝のブリーフィングとして提示する

この一声で、朝の情報収集がまとまった形で手元に届くようになりました。

二つのSkillに共通しているのは、「どのツールから」「何を」「どういう順序と条件で」処理するかを、あらかじめ言語化していることです。この言語化の作業こそが、Skill設計の中身です。技術的な実装はAIエージェントに任せられますが、「何を実行させるべきか」を決める仕事は人間にしか担えません。

6. AIは何を代替し、何を代替できないのか？

「AIがSaaSの操作を代行するなら、BizOpsの仕事もなくなるのでは」と思われるかもしれません。この疑問には、代替されるものとされないものを切り分けて答えます。

AIが代替するのは「操作」と「処理」です。

• SaaSに情報を入力する
• 定型レポートを出力する
• データをツール間で転記する
• 定型の請求書を発行する
• 重複排除や欠損補完などのデータクレンジング

これらは、ルールが明確で、手順が定まっており、例外のパターンが限られた作業です。AIエージェントがもっとも得意とする領域であり、BizOps担当者の日常業務の少なくない部分を占めてきた作業でもあります。

AIが代替できないのは「設計」と「判断」です。

• 事業全体のオペレーションを俯瞰し、どこにボトルネックがあるかを見極める
• 部門間のデータの流れを設計し、全体最適のアーキテクチャを描く
• 新しいSaaSを導入する際、既存のオペレーション全体への影響を評価する
• 各部門の利害が衝突したとき、全体として何を優先すべきかを判断する

AIは個別のタスクを高速に処理できます。しかし、事業全体を理解した上で「何を・どの順序で・どう変えるか」を判断することはできません。AIは、与えられた指示を実行する能力に長けていますが、「何を指示すべきか」は自分では決められないのです。

この「何を指示すべきか」を決める力こそ、Skillを設計する力の正体です。

7. BizOpsの仕事はどう変わるか

Skillという考え方が広がると、BizOpsに求められるスキルセットも変わります。

「従来」のスキルが不要になるわけではありません。業務プロセスを理解していない人がSkillを設計しても、使い物にはならない。SaaSの仕組みを理解していない人がAPIの評価をしても、判断を誤ります。土台は変わらず、その上にAI時代の新しい層が積み重なる、という理解が実態に近いはずです。

設計の対象が「人間の操作手順」から「AIへの指示設計」に移る。この変化を境に、BizOps担当者の時間配分は「操作する時間」から「設計し、確認し、承認する時間」へと移っていきます。

8. 経営者に伝えたいこと ── BizOpsはコストセンターではない

ここからは、経営者・意思決定者に向けた話です。

BizOpsを「業務を効率化してくれる支援部門」、つまりコストセンターとして位置づけている企業は少なくありません。効率化の成果が見えにくいとき、真っ先に予算を削られるのもこうした部門です。

しかし、AI時代のBizOpsは、戦略投資として位置づけるべきだと私は考えています。

理由は明確です。AIエージェントという実行エンジンを導入しても、Skillという設計図がなければ動きません。同じAIツールを契約していても、業務プロセスを深く理解した設計図があるかどうかで、実際に自動化できる範囲も、任せられる業務の質も変わります。AIツールへの投資効果を決めるのは、AI自体の性能だけでなく、それを使いこなす設計力です。

だからこそ、経営者に伝えたいことは三つあります。

第一に、BizOpsを経営直轄のポジションに置くこと。 AIエージェントが業務を横断して実行する仕組みの設計は、部門をまたぐ全体最適の視点がなければ成立しません。特定部門に閉じた自動化は、部分最適で終わります。

第二に、BizOpsにAIツールの投資予算を持たせること。 AIエージェントの利用料、API連携の開発費、Skill設計にかかる工数。これらを情報システム部門の予算だけに任せると、業務の文脈を欠いたまま導入が進み、「入れたけれど使われない」という結果になりかねません。

第三に、BizOpsの評価軸を「効率化の量」から「設計の質」に変えること。 「月に何時間削減したか」だけでなく、「新しいSkillの設計によって、何件の業務を自動化できたか」「オペレーション全体の自動化率がどれだけ向上したか」。経営に直結する指標で評価することです。

9. 今日からできること

理屈を並べても、明日からの行動につながらなければ意味がありません。BizOps担当者、あるいはBizOpsに近い役割を担っている方に向けて、今日からできることを三つ挙げます。

• 一つの定型業務を選び、手順を言語化する。 「何を」「どの順序で」「どんな条件で」実行しているかを書き出す。この言語化そのものが、Skill設計の第一歩です
• 契約中のSaaSのAPIドキュメントを一度確認する。 APIが充実しているか、Webhookに対応しているか。次にツールを見直すときの判断材料になります
• 「ミスに気付ける業務」から着手する。 AIの出力を人間がレビューできる業務を選べば、AIの精度を見極めながら安全に範囲を広げられます

小さく始め、確認し、範囲を広げる。この順番を守ることが、Skill設計を組織に根づかせる一番の近道です。

よくある質問（FAQ）

Q1. シート課金のSaaSは、もう使わない方がいいですか？

A. そうではありません。人間が確認・承認・例外対応を行う場面は残り続けるため、シート課金自体がすぐになくなるわけではありません。ただし、ツールを選ぶ際に「APIがどこまで充実しているか」を評価軸に加えておくことをお勧めします。中長期での自動化のしやすさが変わってきます。

Q2. Skillとプロンプト（AIへの指示文）は何が違うのですか？

A. プロンプトは一回一回の指示です。Skillは、業務の手順・条件分岐・使用するツールの接続情報までをまとめて構造化した、繰り返し使える設計図です。プロンプトを都度書く状態から、Skillとして一度定義しておけば、以後は「実行して」の一声で済むようになります。

Q3. Skillの設計は、エンジニアでないとできませんか？

A. 核心は「この業務をどういう順序で、どういう条件で実行すべきか」を定義することであり、業務設計の仕事です。APIの仕様を多少理解する必要はありますが、業務プロセスを一番理解しているのは現場に近いBizOps担当者です。技術者だけの仕事ではありません。

Q4. どの業務からSkill化すればよいですか？

A. ルールが明確で、手順が固定されていて、例外パターンが限られている定型業務から始めるのが安全です。加えて、AIの出力を人間がレビューできる業務であれば、ミスに気付きやすく、安心して範囲を広げられます。

Q5. 経営層にBizOpsへの投資を説明するには、何を伝えればいいですか？

A. 「AIツールを入れれば自動的に効率化する」わけではなく、「AIに正しく仕事を任せる設計図（Skill）」が伴って初めて投資が効果を生むことを伝えてください。AIツールと設計力はセットの投資である、という説明が有効です。

無料相談のご案内

SaaSの評価軸をどう見直せばいいかわからない、社内の業務をSkill化したいがどこから手をつければいいかわからない。そんな経営者・責任者の方は、お気軽にご相談ください。

現場に入って一緒に整理するところから始めます。初回のご相談は無料です。

お問い合わせはこちら

これまでの支援実績はこちら