ソフトウェアの値札は、たいてい記事のいちばん最後に小さな字で添えられる。ところがエージェント型のソフトウェアでは、この値札を製品設計よりも先に持ち出さなければならないことがある。
まずは一つの状況から始めよう。昨日まで担当者三人で分担していた仕事を、今日は担当者一人とエージェントが一緒に片づける。すると、このソフトウェアを売った会社は、誰に、何を基準に、いくら受け取るべきなのか。人数ぶん? 処理した仕事の量ぶん? 実際に完了した成果ぶん? 答えは簡単には出ない。そしてこの問いにどう答えるかが、そのまま「自分たちは何を売る会社なのか」を決めてしまう。この記事は、特定の会社の料金がいくらかを論じるものではない。課金の「単位」が変わるとき、競争の軸がどこへ移っていくのかを見ていく。
従来の定額制ソフトウェア(SaaS、毎月お金を払って使うソフトウェア)の基本単位は「シート」だ。シート課金とは、そのソフトウェアを使う人の頭数ぶん料金を取るやり方である。コラボツールを20人で使えば20人ぶん払う。シンプルで、買う側も売る側も計算しやすい。
この方式が長く持ちこたえた理由は一つだ。ソフトウェアが人の手を「補助する」道具だったからである。実際に働く主体は人であり、ソフトウェアはそのそばに置かれた道具にすぎなかった。道具を握る手が何本あるかで値をつけるのは自然なことだ。
エージェントでは、この前提が崩れる。エージェントとは、人が与えた目標を受け取り、複数のステップを自分で踏んで処理するソフトウェアだ。メールを読み、スケジュールを突き合わせ、在庫を照会し、下書きを書き、承認だけを人に上げる。手を補助するのではなく、手の一部を代わりに担う。
すると問いが生まれる。このエージェントの「シート」は誰なのか。エージェント自身なのか、それを監督する人なのか、それとも処理した件数なのか。一人がエージェントを五つ動かせば一シートなのか、五シートなのか。逆に、エージェントが夜間に人なしで仕事を終えたら、その時間のシートは何個なのか。単位が人から切り離された瞬間、シートという物差しはもう合わなくなる。
ここで一つ、はっきりさせておこう。課金単位を変えると会社が負う責任の範囲が変わり、責任の範囲が変わると作るべき製品が変わる。だから課金は、マーケティング担当が最後に決める数字ではなく、製品の方向をまず定める設計なのだ。
いま市場で混ざり合って使われている方式は、大きく三つだ。それぞれの方式が供給側にどんな圧力をかけるのか、その圧力が何に阻まれるのかを、あわせて見ていこう。
買う側は予算を組みやすい。今月25人が使えば25人ぶん、それで終わりだ。変動がないので財務部門は喜ぶし、売る側も売上予測が立てやすい。
問題は、エージェントが目指すものと課金が逆向きに動くところにある。エージェントは「人があまり張りつかなくても仕事が回る」ようにする代物だ。ところがシート課金は、人が多く張りつくほど多く取る。顧客がエージェントをうまく使って担当者を三人から一人に減らすと、供給側の売上はかえって減る。顧客の成功が供給側の損になるのだ。こうした構造では、供給側は通知を増やしダッシュボードを派手に飾って、人が毎日開かずにいられないように仕向けたくなる誘惑にかられる。自動化を売ると言いながら、自動化が進まない方向へ力がかかる。(この誘惑を完全に封じるものはないが、顧客が「ログインばかりさせる製品」に嫌気がさして離れうるという事実が、ある程度ブレーキをかける。)
処理した量ぶん受け取る方式だ。処理件数、あるいはトークン(大規模言語モデル——人の言葉を処理するAI——が文章を細かく区切って数える単位、おおよそ単語のかけら一つ)の量で値をつける。多く使えば多く払う。価値と課金の距離がシートよりも近い。
つまずくのは二か所だ。まず、顧客が不安がる。今月の請求がいくらになるのか前もってわからない。エージェントが何かのはずみで同じ作業を何度も回すと、コストが跳ねる。予算を固めておかねばならない組織にとっては、この不確実性そのものが購入を阻む。次に、供給側に「多く処理するほど得」という妙なインセンティブが生じる。一度で終わる仕事を三ステップに刻んでも、供給側は損をしない。効率を上げる理由が弱まる。
仕事が実際に終わったときにだけ、あるいは終わったぶんだけ受け取る方式だ。処理された問い合わせ一件あたり、予約が確定した一件あたり、回収された未収金の一定割合。一見、もっとも公正だ。顧客は結果にだけお金を払い、供給側は結果を出してはじめてお金を受け取るので、二つの利害が同じ方向を向く。
だから成果課金は、供給側に「最後まで責任を持て」という圧力をかける。ただし、この圧力がそのまま「最後まで責任を持つ製品」につながるわけではない。すぐ次に見る三つの壁があるからだ。むしろ同じ圧力が、供給側を見当違いの方向へ押しやることもある。
成果を数えるには、まず数えられるように定義しなければならない。ところが現場の仕事はきれいに区切れない。
顧客からの問い合わせを処理するエージェントを「解決された問い合わせ一件あたり」で課金するとしよう。では「解決」はいつなのか。エージェントが答えを送ったとき? 顧客が再び尋ねてこなかったとき? 顧客が「解決済み」ボタンを押したとき? 三つの基準はそれぞれ違う数字を出す。顧客があきらめて去ったのと、満足して去ったのとは、データ上ではどちらも同じ「もう尋ねてこない」に見える。
基準がゆるければ供給側は楽な方へ数字を膨らませられるし、厳しすぎればまともにこなした仕事さえ成果と認められない。だから成果課金の半分は、「成果をどう定義するか」を契約書にくっきり書き込む作業だ。とりわけ、やり直しをどう扱うかが抜け落ちると、同じ案件をめぐって請求の解釈が毎月分かれる。
結果が出たとき、それがエージェントのおかげなのかを見分けるのが難しい。
未収金を回収するエージェントがあるとしよう。今月、5千万ウォンが入った。供給側は「うちのエージェントが催促したから入った」と言う。ところが、そのうちのかなりの額は、エージェントが何もしなくても時期が来れば入ってくるお金だったかもしれない。エージェントが「上乗せで」引き寄せた金額だけが本当の成果なのに、この二つを切り分けるのが難しい。
きちんと測ろうとすれば、エージェントを使った側と使わなかった側を分けて比べる、実験に近い設計が要る。ほとんどの顧客企業には、そこまでやる余力がない。だから帰属はいつも当て推量になり、供給側は大きく貢献したと言い、顧客はもともとそうなる案件だったと言って、信頼が崩れる。
クリームスキミング(cream skimming)、日本語で言えば「おいしいところだけすくい取る」というこの言葉は、結果だけでお金を受け取るようになると、供給側が「確実に成功する仕事」だけを選んでやりたくなる、という意味だ。
成果課金の下では、供給側は損を避けようと、うまくいきそうな案件だけをエージェントに任せ、うまくいきそうにない難しい案件はこっそり人に回したり後回しにしたりする。その結果、「エージェント成功率95%」といった見栄えのよい数字が出る。だがその数字は、簡単な仕事だけをすくい取った結果にすぎず、肝心の、顧客が自動化したかった厄介な仕事はそのまま残る。顧客が買いたかったのは難しい仕事の処理なのに、課金構造が供給側を簡単な仕事の方へ押しやってしまったのだ。
だから成果課金を使うときは、完了率ひとつだけを見てはいけない。完了率のとなりに、やり直し率(手を入れ直した割合)と人に回した割合を並べて置いてはじめて、その成功率が難しい仕事を避けた結果なのかどうかが見えてくる。この三つの壁があるため、純粋な成果課金は、結果が数字できっちり割り切れ、帰属が明確で、難易度がそろっている、ごく狭い業務でのみきれいに機能する。現実の業務の大半はそうではない。
課金方式は、どの会社に有利な戦いかをあらかじめ決めておく。さきほど見た各方式の圧力が、会社のかたちによって違うふうに働くからだ。
さまざまな業務に幅広く使われる大きな道具(メール・文書・コラボツールのように全社員が毎日開くもの)をすでに持っている側は、シート課金が都合よい。彼らはエージェントを既存のシートに乗せて抱き合わせで売る。追加費用なしでバンドルで入ってくれば、特定の業務に集中する新興企業が「うちのエージェントのほうが賢い」と言っても、買い手は「わざわざ別に金を払う理由があるのか」と返しやすい。
モデルを動かす基盤を自前で持つ会社は、処理コストが低いので、従量単価を下げても持ちこたえる。この戦いはコスト競争へと流れ、規模の小さい側が不利になる。
特定の業務を深く知る専門業者は、成果で差別化する余地がある。成果に責任を持つには、その業務の結果がどう出て、どこで狂い、何が「終わり」なのかを正確に知らねばならないが、広く敷かれた汎用ツールは業務ごとに異なる「終わり」を定義しづらい。狭く深い側が、ようやく大きな側とは別の土俵で戦えるというわけだ。
三つの方式にそれぞれ欠陥があるので、実際の市場は一つに偏らず、混ざり合う。いま目に見える方向は、おおよそこう読める。これは筆者の判断であって、確定した事実ではない。
土台には小さな固定費を敷く。プラットフォームを維持し、接続を開けておくための費用だ。顧客に「少なくともこれだけは予測できる」という安心を与える。その上に、処理量や成果に連動する変動費を乗せる。成果の部分は、さきほど見た三つの壁があるため、測定と帰属が比較的はっきりしている業務に限って、慎重に付ける。成果課金は失敗した作業のコストを供給側がかぶる構造なので、製品がまだ不安定な初期の会社ほど、この変動性が致命的になる。だから小さな固定費でキャッシュフローをまず敷き、測定がくっきりしてきた業務から成果を乗せていく順序が安全だ。
単位を変えること自体も慎重を要する。課金単位を変えるのは実質的に契約の性格を変えることなので、財務担当がまず反発する。だから普通は、既存の単位を保ったまま新しい単位を「選択肢」として先に乗せ、移りたい顧客にだけ適用してデータを積んだうえで、全面切り替えを検討する。
この構造が定着すると、競争の問いも変わる。かつての問いは「機能が多いか、安いか」だった。変わった問いは「この会社は自分の成果を数字で示せるか、その数字を信じられるか」になる。
抽象的な話を、一つの場面で追ってみよう。念のため言えば、筆者はこの種のエージェントを作る側にいて、ONTLEは業務にPM(プロジェクトマネージャー)役のエージェントを付けるサービスだ。以下の事例は実在する特定顧客の契約ではなく、課金設計が製品の正体をどう浮かび上がらせるかを示すために構成した例である。
部品を納める中小メーカーがあり、取引先が電話をかけてきて「来月15日の納期を10日に早めてほしい」と言った。
シート課金の世界なら、この依頼は担当者の画面に通知として表示される。担当者が自分で在庫を確認し、生産スケジュールをのぞき、物流に電話し、取引先に返事をする。ソフトウェアはこの過程を見やすく補助するだけだ。担当者が一人張りついていてこそ仕事が回り、供給側の売上はその担当者がログインしているかぎり維持される。担当者がどれだけ速く、間違えずに終えたかは、課金とは関係がない。
同じ依頼をPMエージェントが受けるとしよう。エージェントは一人で複数のステップを踏む。早まった納期に必要な資材の在庫があるかを照会し、生産ラインの空きスロットをスケジュールと突き合わせ、早めると後ろにずれる別の注文は何かを探し、配送にかかる時間が間に合うかを確認する。そのうえで「10日納期は可能ですが、B取引先の注文が二日ずれます。Bに了承を求めるか決めてください」という整理された判断を人に上げる。人はそれを読んで承認する。
ここで課金をどう掛けるかが、このサービスの正体を浮かび上がらせる。シート単位で取れば、エージェントが担当者の二時間を5分に縮めるほど、顧客はシートを解約する。うまくやるほど売上が削れる。従量で取れば、複雑な納期調整ほど請求が跳ねるのを恐れて、顧客はむしろ複雑な案件でエージェントを使いたがらなくなる。
だから私たちが選んだ設計は、三つを混ぜつつ、その比重をはっきりさせる方だ。サービスを付けておく基本料は固定で取って顧客が予算を組めるようにし、その上に「人の承認だけで閉じた案件の数」を中核指標として変動を乗せる。成果で数える方を選んだぶん、測定の壁は私たちが先に引き受ける。「閉じた」をどの時点で見るか——取引先からの受諾の返信が入ったときとするか、生産スケジュールへの反映まで済んだときとするか——を契約の冒頭で釘を刺し、二つのうち後ろ(スケジュール反映)を基準に据えて、ゆるい集計で数字が膨らまないようにする。そのぶん私たちは、より遅く、より少なく請求される負担を引き受ける。
承認のあとのほうが、もっと重要だ。人が承認したのに、いざ実行段階で取引先が言を翻したり資材が欠品したりすれば、その案件は「閉じた」とは数えず、エージェントが再調整の手続きをもう一度回す。再調整が何度回ったかは、さきほど述べたやり直し率として別に集計し、私たちが難しい案件を避けなかったかどうかを顧客が確認できるようにしておく。これが、課金を製品設計より先に持ち出すべきだと言った理由である。
競争分析は、売る側だけの仕事ではない。エージェントを導入する買い手も、課金単位を読めば供給側の腹の内を推し量れる。まず、課金単位が自社の「成功」と同じ方向を向いているかを確認しよう。人をあまり張りつけずに済ませようとしてエージェントを買うのに、供給側は人が多く張りつくほど儲かるのなら、両者はいつか衝突する。
次に、提案書を閉じる前に、以下の三つを供給側に直接たずね、数字で受け取っておくのがよい。
この三つにはっきり答えられない成果数字は、マーケティングの惹句である可能性が高い。正解の課金方式が別にあるわけではない。予算を固めねばならない組織では変動費の比重が大きい提案は通りにくく、結果にお金を賭けたい組織には純粋なシート課金はもどかしい。自社の肌合いに合った課金構造を持つ製品が、その組織に合った製品なのだ。