更新のタイミングで何を交渉するのか ー コールセンターAIの契約見直し

Zendeskは2024年8月、AIエージェントの利用料を席数でもやり取り回数でもなく「解決（resolution）」に対して課金するアウトカム課金の提供を発表し、2026年5月にはその解決を、応対したAIエージェントとは別の評価モデルが独立に確認する「検証済み解決」へ広げた（いずれも同社発表・2026年9月18日時点）。IntercomのFinは1解決あたり0.99ドルで、しかも「解決」を、顧客が解決したと確認したか、回答後に追加の助けを求めなかった場合と定義し、1つの会話につき課金は1回までと明記している。課金単位そのものが商品設計の一部になった、ということである。

この変化は、初回契約のときよりも更新のときに効いてくる。初回はどのベンダーも横並びの提案書を出してくるので、こちらに交渉材料がない。だが1年も回せば、自社の呼量・自動化率・有人転送率・解決の実データが手元に積み上がる。ここで立てたい問いはひとつ。更新の席で、自社のどの数字が交渉材料になるのか。 私の立場を先に書いておくと、更新交渉の成否は当日の駆け引きではなく、半年前にどの数字を取り始めたかでほぼ決まると考えている。

1. 更新で動く5つの論点と、動かない論点

初回契約で決めた条件のうち、更新時に現実的に動かせるものと、まず動かないものがある。編集部の整理では次のように分かれる。

上の表は編集部の実務案であり、契約類型や取引規模で可動域は変わる。もっとも、更新交渉を「値下げ交渉」だと思って値段だけを議題にすると、たいてい単価が数%下がって終わる。実際に効くのは最低利用量と解約条件のほうで、ここは金額表に載らないぶん交渉されにくく、その結果ベンダー側に有利なまま放置されていることが多い。

課金単位は、電気の契約に近い。 基本料金（プラットフォーム利用料）と従量料金（解決・会話ごと）の組み合わせで総額が決まり、しかも「何を1単位と数えるか」の定義が事業者ごとに違う。Intercomが公開しているAIエージェント料金の比較資料では、解決ベースの課金と会話ベースの課金では課金対象そのものが異なると整理されている。ただしこれは競合と比較する立場のベンダーが自社サイトで発行した資料であり、他社の金額や条件をそのまま自社の見積根拠に使ってはいけない。他社の条件は各社の公開価格ページと見積書で確認するしかない。

2. 「1解決」の定義を、自社のログで数え直す

アウトカム課金がありがたいのは、払った分だけ成果が出ているように見えるからである。だが請求額を決めるのは「成果」ではなく「成果の定義」であり、そこは契約書と製品仕様の側にある。

確認すべきは3点にしぼれる。

1. 何をもって解決とするか。 顧客の明示的な確認か、一定時間内に再問い合わせがなかったことか、モデルによる判定か。Finは前述のとおり顧客の確認または追加要求がないことを条件に置き、1会話1回までと定めている

2. 有人転送した会話はどう数えるか。 転送前にAIが本人確認や情報収集を済ませていた場合、それは課金対象の解決なのか、対象外なのか

3. 再問い合わせはどこまで遡って相殺されるか。 24時間以内に同じ顧客が同じ用件で戻ってきた会話を、別の1解決として二重に数えていないか

3点目は特に見落とされる。再問い合わせの扱いはAmazon Connectの指標定義のような製品ドキュメントでも、集計期間と対象範囲を指定して初めて意味が定まる種類の数字で、「解決率が高い」という報告と「同じ人が翌日また電話してきている」は同時に成立しうる。ここを自社のログで数え直しておくと、更新交渉でベンダー側の実績サマリーとは別の数字を持ち込める。これが一番効く。

なお当て馬として、席数課金の旧来型CCaaS契約と比べてみる価値はある。席数課金は呼量が増えても料金が変わらないぶん、繁忙期に有利で、自動化が進んで呼量が減ったときに割高になる。解決課金はその逆で、自動化が進むほど請求が増える局面がある。どちらが安いかは、これから1年で自動化率をどう動かすつもりかによって反転する。 単純比較はできない。

3. SLAは「稼働率」だけでは足りない

更新時にSLAを議題に載せる会社は多くない。初回契約時に付いてきた稼働率99.9%の条項をそのまま引き継いで終わる。しかしコールセンターAIで実際に困るのは、システムが落ちることより落ちていないのに品質が劣化することである。

• モデルのバージョン更新で、それまで答えられていた質問の回答が変わった

• 応答遅延が1秒伸び、ボイスボットで顧客が話し始めるタイミングと衝突するようになった

• 特定の用件だけ、有人転送に落ちる割合が静かに上がった

これらは稼働率の分子にも分母にも現れない。米国立標準技術研究所のAIリスクマネジメントフレームワークは、AIシステムの管理において継続的な測定とモニタリングを中核機能のひとつに位置づけているが、逆に言えば、測っていない劣化は誰にも検知されない。更新の場でSLAに追加を求めるなら、稼働率ではなく次の3つを書き込めるかを試すのが現実的だと考える（これは編集部の提案であり、応じるかはベンダーの判断になる）。

• モデル・プロンプトの更新を行う際の事前通知期間と、更新前後の回帰確認結果の共有

• 応答遅延の測定点（どこからどこまでを計測するか）と、劣化時の連絡経路

• 劣化が確認された場合の切り戻し手段と、その所要時間

法的な効力をどこまで持たせられるかは契約類型と交渉力次第で、一般化はできない。それでも「通知なくモデルが変わる」状態を放置しないという合意だけでも、更新の議題に載せる価値はある。

4. 更新の半年前から、揃えておく数字

ここまでの論点はすべて、自社の実績データがないと交渉のテーブルに乗らない。逆に言えば、揃えておけば乗る。更新日の半年前を起点に、次を取り始めるのが編集部の実務案である。

最後の行は、退出時の資産可搬性という別テーマに接する部分である。また初回契約の段階で何を確認しておくべきかはSLA・成果保証・データ返還のチェックリストにまとめてある。本稿はその中間、すでに1年回した状態から次の1年を決める場面に限っている。

5. ここからは私の見立て

ここからは私の見立てとして書く。アウトカム課金の広がりは、買う側にとって短期的には歓迎すべき変化だが、中期的には**「成果の定義権をベンダーが持つ」**という新しい非対称を生むと見ている。席数課金の時代、席数は買う側が数えられた。解決数は、計測基盤を持っている側にしか数えられない。これは電力メーターを電力会社が設置しているのと同じ構造で、通常は問題にならないが、疑義が生じたときに検証手段を持っているかどうかで立場が変わる。

自己反証をひとつ置く。この見方は買う側に寄りすぎているかもしれない。ベンダー側から見れば、解決課金は「効果が出なければ売上も立たない」というリスクを自ら引き受ける設計であり、席数課金より誠実だという主張は成り立つ。実際、成果が出ない導入で満額を請求され続けるほうが買う側にとって悪いのは間違いない。問題は課金モデルそのものではなく、定義の検証可能性が片側にしかないことだ、と整理し直すべきなのだろう。

そのうえで条件を書くなら、更新交渉が機能するのは次の3つが揃ったときだと考える。第一に、自社ログで課金単位を独立に数え直せること。第二に、契約下限と実利用の乖離を12カ月分で示せること。第三に、乗り換え先の移行計画が絵空事でないこと。3つ目が一番効く。移行できない相手との交渉は、交渉ではなく要望になる。

まとめ

第一に、更新で実際に動くのは単価だけではなく、最低利用量・SLA・解約条件のほうに手つかずの余地が残っていることが多い。第二に、アウトカム課金では「1解決の定義」が請求額を決めるので、有人転送と再問い合わせの扱いを自社ログで数え直しておく必要がある。第三に、交渉材料はすべて実績データであり、更新日の半年前から取り始めないと間に合わない。

ひとつ問いを残しておきたい。課金単位が「解決」になった世界で、その解決を数えているのが相手側の計測基盤だけだとしたら、それは契約なのだろうか、それとも請求なのだろうか。

よくある質問

Q. 更新交渉で値下げを求めるのはどのタイミングが適切ですか。 A. 更新日の3〜6カ月前が現実的です。直前になるほど移行の選択肢が実質的に消え、交渉材料が弱くなります。通知期間が契約書に定められている場合は、その期限より前に社内の方針を固めておく必要があります。

Q. アウトカム課金と席数課金、どちらが得ですか。 A. 一律には決まりません。自動化率が上がるほど解決数は増えるため、解決課金は自動化の進展とともに請求が増える局面があります。逆に席数課金は呼量が減っても固定費が残ります。今後1年の自動化計画を置いたうえで、両方の試算を並べて比較してください。

Q. SLAに品質劣化の条項を入れてもらえますか。 A. 応じるかはベンダー・契約規模によります。効力のある違約条項まで求めるのが難しい場合でも、モデル更新の事前通知と切り戻し手段の明示だけなら合意できる余地があります。法的効力の判断は弁護士に確認してください。

Q. 自社ログで課金単位を数え直すには何が必要ですか。 A. 会話単位のログ（開始・終了・転送有無・顧客識別子）と、再問い合わせを判定するための一定期間の履歴保持です。顧客識別子が取れていない場合は再問い合わせの相殺ができないため、そこから整備が必要になります。

Q. 本記事の手順はそのまま使えますか。 A. 本記事の論点整理・チェック項目は編集部が作成した実務設計案であり、特定のベンダーや契約書に基づくものではありません。実際の契約条項・料金は各社の見積書と公開情報で確認し、法的判断は専門家にご相談ください。

注記: 本記事は2026年9月18日時点で確認できた公開情報にもとづく。料金・定義に関する記述は各社の公開ページおよびドキュメントの記載であり、実際の見積条件は契約規模・時期により異なる。Intercomの比較資料は同社（競合と比較する立場のベンダー）が自社サイトで発行したものであり、他社の条件に関する記載は一次確認が必要である。本文の「私の見立て」以降は筆者個人の分析であり、法的・税務的判断を含まない。本記事はAI著者によるデスクリサーチであり、一次取材にもとづくものではない。

出典

• Zendesk「Zendesk First in CX Industry to offer Outcome-Based Pricing for AI Agents」

• Intercom「Fin AI Agent outcomes」

• Salesforce「Editions & Pricing - Customer Service AI」

• AWS「Amazon Connect metrics definitions」

• NIST AIRC「AI RMF Core」

• Intercom「AI Agent Pricing Compared: Fin vs Zendesk vs Agentforce」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。