第250号

AIカスタマーサポート、「解決1件」の基準から確認すべき理由

Finの成果課金条件と仮想の原価表をもとに、実際の解決件数と人の確認コストを併せて計算する方法を考えます。

ビジネスAIカスタマーサポート、「解決1件」の基準から確認すべき理由

「解決1件あたり0.99ドル」で確認すべきこと

顧客対応向けのFin AI Agentは、成果を基準に料金が請求されます。代表的な課金項目である「解決」は1件あたり0.99ドルです。対話の中で複数の質問を処理しても、請求は1回のみです。

私がまず確認したのは、価格よりも「解決」の定義でした。顧客が役に立ったと答えた場合だけでなく、Finの回答を受け取った後に追加のサポートを求めなかった場合も解決に含まれます。後者は「推定解決」と呼ばれます。

現在のFinのヘルプによると、最後の回答のあと顧客が24時間会話に参加しなかった場合、推定解決と見なされると説明されています。ただし、挨拶だけを交わしたケースや、Fin側が確認の質問をしたのに顧客が答えなかった場合は課金対象になりません。解決として集計された後でも、顧客が同じ会話に戻って追加のサポートを求めたなら、請求期間が変わっていても該当する解決件数は差し引かれるとのことです。Finの解決および請求条件

こうした補正ルールがあっても、回答を受け取って離脱した顧客が本当に満足したのかまで把握するのは困難です。問題が解決した可能性もありますし、回答に失望して別の手段を探した可能性もあります。契約上請求できる成果と、自社が求める業務結果が一致しているかを確認すべきなのは、まさにこのためです。

何を任せたかによって成果も異なる

Finの価格表には複数の課金項目があります。

課金項目意味1件あたりの価格
解決最後の回答の後、追加の支援を求めない0.99ドル
設定した手順の完了後に引き継ぎ顧客企業が人へ引き渡すよう設計した手順を完了0.99ドル
不適格リードの判定顧客企業が定めた営業対象の条件に合致しないと判定0.99ドル
適格リードの判定営業対象の条件に合致すると判定して連携9.99ドル

単に解決できずに人へ引き渡す場合と、必要な情報を集めたうえで人へ引き渡すよう設定された手順を完了した場合とでは意味が異なります。後者は任された業務を全うしたと見なされ、課金対象になり得ます。料金プランや連携するサポート用プラットフォームによって提供される機能も確認しておく必要があります。Finの価格表

同じ0.99ドルであっても、企業が得られる価値は異なる可能性があります。顧客の問題が完全に解消したのか、オペレーターが業務を始める準備が整ったのか、営業対象外のリードを振り分けたのかを分けて見なければなりません。成果課金という看板だけで、すべての失敗コストがベンダー側に転嫁されるわけではありません。人の手による後続処理や顧客離脱にかかるコストは、依然として購入側の負担として残る可能性があるのです。

1回成功することと、繰り返し成功することは異なる

私は、エージェントの結果を評価する際、成功率が何を意味しているのかも併せて確認すべきだと考えています。1回で完了させなければならない対応と、複数の回答案を作成してから1つを選べばよい作業とでは、求められる条件が異なるからです。

Anthropicはこの点を2つの指標で説明しています。pass@kはk回試行して1回以上成功する確率であり、pass^kはk回すべて成功する確率です。どちらが優れた指標かは業務によって異なります。複数回の試行から正しい結果を選べるなら前者の指標が有用ですし、毎回顧客に安定した結果を返さなければならないなら、繰り返しの成功可否が重要になります。Anthropicによるエージェント評価の解説

たとえば、同じタスクで毎回成功する確率が90%で、各試行が独立していると仮定してみましょう。10回中1回以上成功する確率はほぼ100%ですが、10回すべて成功する確率は約35%にとどまります。残りのケースですべて失敗するという意味ではありません。10回のうち少なくとも1回失敗する可能性がそれだけある、ということです。

実際に反復信頼性を測定した研究もあります。2024年のτ-benchによる小売対応実験では、GPT-4oベースのエージェントは単一試行の成功率が約61%でしたが、同じ課題を8回すべて成功させた割合は25%未満でした。当時のモデルと実験環境での結果であるため、現在のすべてのエージェントの失敗率として捉えるべきではありません。平均成功率だけでは反復業務の安定性を説明しきれないことを示す一例です。τ-benchの論文

再試行や検証を適切に設計すれば、こうしたブレを抑えられます。ただし、追加の呼び出し、レビュー時間、処理の遅延に伴うコストまで併せて計算する必要があります。

モデル利用料と実際の業務原価を切り分けて計算する

以下は実測データではなく、計算手法を示すための仮定です。あるチームが月に500件を処理し、定めた基準で確認したところ、実際に解決されたのは350件だったとします。

項目月間費用
モデル・ツールの呼び出し30万ウォン
モニタリング・保存・連携20万ウォン
人による確認 40時間 × 4万ウォン160万ウォン
失敗の復旧 10時間 × 4万ウォン40万ウォン
合計250万ウォン

モデル・ツール費用30万ウォンを処理件数の500件で割ると、1件あたり600ウォンです。総費用の250万ウォンを実際に解決した350件で割ると、約7,143ウォンになります。

この2つの計算は、費用の対象範囲も件数をカウントする基準もまったく異なります。成功件数だけを変えると、30万ウォン ÷ 350件で約857ウォンになります。ここに残りの運用費を含めると、7,143ウォンになるわけです。

この試算例では、人による確認と復旧のコストが全体の80%を占めています。そのため、モデルやツールの費用を半減させても、総費用は250万ウォンから235万ウォンへと6%しか減りません。すべてのAI業務において人のコストが80%を占めるという意味ではありません。自社の業務のコスト構造がこれに近い場合、モデルの単価交渉だけで削減できる幅は小さいということを意味しています。

改善策を選ぶには、2つの側面を併せて見る必要があります。同じコストでより多くの業務を正しく完遂できるか、そして品質を維持しながらレビューや運用にかかる時間を削減できるかです。レビューを減らした結果、再問い合わせや手戻り復旧が増えたのであれば、そのコストも再び算入しなければなりません。

成果課金への移行で見落としがちなポイント

私は以前の第147号で、シート(アカウント)ベースの料金体系から成果ベースの料金体系へと移行する潮流を取り上げました。その見立ては今も有効だと考えています。ただし、買い手の立場からはさらに掘り下げて確認すべき点があります。利用アカウント数ではなく成果に近い単位で支払うからといって、その単位が自社の成功基準と自動的に一致するわけではないのです。

成果の数値は企業の成長を説明する際にも使われます。Salesforceは6月15日、Finを約36億ドルで買収する合意を発表した際、Finがサポート業務量の平均76%を最初から最後まで解決した事例を紹介しました。発表時点での買収完了予定時期はSalesforceの2027会計年度第4四半期でした。Salesforceの買収合意発表

この数字を導入検討に用いるなら、どのような顧客企業や対応種別のデータなのか、何をもって解決とカウントしたのかを確かめる必要があります。発表資料だけを見て、自社でも76%が解決されると見なすのは早計です。請求基準や解決率の指標一つが買収額全体を決定づけたと解釈する根拠も十分ではありません。

私なら、単価とともに成果の定義、集計基準の変更手続き、再問い合わせが発生した際の控除条件、ログを確認できる範囲を検討します。とりわけ人への引き継ぎそのものを成果とする業務であれば、引き継ぎ以降に要する時間も別途算出するはずです。

見積書に運用とレビューのコストを組み込む

AIの導入コストを比較する際、私は以下の項目を確認するのが望ましいと考えています。

  1. モデルと製品のライセンス・利用料
  2. 外部ツールとAPIの呼び出しコスト
  3. ストレージ・検索・ネットワークコスト
  4. リトライや失敗した呼び出しのコスト
  5. 評価用データの作成と品質確認にかかるコスト
  6. 人によるレビューと承認に要する時間
  7. 障害やエラーの復旧に要する時間
  8. セキュリティ・教育・業務プロセスの変更にかかるコスト

製品の利用料にすでに含まれている費用を二重に計上する必要はありません。初期構築費用と毎月発生する運用費用も切り離して考えるべきです。重要なのは項目数を並べることではなく、比較する製品ごとに同一範囲のコストを算出することです。

件数をカウントする基準も、業務に合わせて定義する必要があります。カスタマーサポートであれば、定めた期間内に同一の件で再問い合わせが発生せずに完了した件数なのか、営業であれば担当者が引き継いだ適格リード数なのか、開発であれば必要なレビューとテストを通過して反映された変更件数なのかを決められます。すべての案件を人が全件検査する必要はありません。自動検証とサンプリング検査を組み合わせつつ、どのようなエラーを見落とすリスクがあるのかを把握しておく必要があります。

トークンあたりのコストは、技術を改善していく段階で有用です。実際に完遂した業務1件あたりのコストは、導入を継続するかどうかを判断する際に役立ちます。両方の指標を参照しつつ、それぞれが何を算出した数字なのかを明確にしておく必要があります。

私が削減額よりも先に見るもの

私はAIの導入検討資料に目を通す際、そのチームが何を「成功」とカウントし、その判定を誰が下しているのかをまず確認します。計算自体が正確であっても、結果の解釈を誤れば打つべき対策が変わってしまうからです。

たとえば、レビュー時間が40時間から10時間に短縮されたとしましょう。自動検証の精度が上がって人の出番が減ったのかもしれませんし、単に確認の手順を省いただけかもしれません。所要時間だけを記録していては、この2つを区別できません。併せて見るべきなのは、実際のエラー件数、再問い合わせ、手戻りや復旧に費やした時間です。

Finの推定解決も、こうした視点で捉える必要があります。ベンダーが提示する分類と事後控除のルールを理解したうえで、自社の顧客体験とどの程度合致しているか、サンプルを抽出して確認できます。ベンダー側の集計を鵜呑みにすることと、すべての会話ログを人が目視確認することの間にも、現実的な選択肢は存在するのです。

今週は、導入済みのAIツールを1つ選び、先月の処理件数、定めた基準に沿って解決された件数、そして人が追加で費やした時間を併せて確認してみてはいかがでしょうか。この3つの数字が揃えば、利用料が安価かどうかだけでなく、実際に業務負担を軽減してくれたのかを議論できるようになります。

💬 AIの出力結果の再確認に多くの時間を割いている業務はありますか? 何を確認していて、なぜそれが必要なのか、皆さんの体験談をお聞かせください。

参考資料と関連リンク

併せて読みたいバックナンバー

  • 第147号:シート課金から成果ベース課金への転換
  • 第180号:実作業時間と請求時間をめぐる問題

アン・グァンソプ(Oswarld)のイラスト

著者 アン・グァンソプ(Oswarld) は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月:HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI