メインコンテンツへスキップ
メニュー

A&A INSIGHTS

経営・AIの活用方針経営者向け

改善しても満足度が上がらないとき:引き受けられる依頼が増えたかで測る

AIサービスを改善しても顧客満足の手応えが変わらないとき、開発を続けるか値上げ・対象業務の見直しへ回すかを、断った依頼の台帳で判定する手順を、GensparkとChatbaseの一次記述から示します。

AIサービス顧客満足改善の判断値上げ一人起業
Read in English
散らばった資料を整理し、比較表を作って判断につなぐ流れ
情報を集め、整理し、条件を比べて判断する流れを表した概念イラストです。 AI生成イラスト

この記事の要点

満足度が測っているのは引き受けた依頼だけで、その範囲は能力が上がるほど一緒に上へ動くため、満足度は能力の代理指標になりません。測るべきは「半年前は断っていた依頼を、いまは引き受けられるか」であり、引き受けられる依頼の種類が増えているなら、次の打ち手は改善の継続ではなく値上げか対象業務の拡大です。

答え:満足度ではなく、断っていた依頼を引き受けられるかで測る

A&Aの考え方

満足度は能力の代理指標になりません。満足度が測っているのは、あなたが引き受けた依頼だけです。能力が上がると顧客はより難しい依頼を持ち込み、引き受ける範囲も一緒に上へ動くため、分母が入れ替わったまま同じ数字が返ってきます。だから改善の成否を見る問いは一つに置き換わります。半年前は断っていた依頼を、いまは引き受けられるか。引き受けられる依頼の種類が増えているなら、次の打ち手は改善の継続ではなく、値上げか対象業務の拡大です。増えていないときに初めて、改善の方向そのものを疑います。ただし数えるのは「能力が足りない」という理由で断った依頼だけです。前提情報・責任・採算で断った依頼は、開発では動きません。

A&Aの考え方

この測り方の材料は、満足度調査の回答ではなく、断った依頼の記録です。断った依頼は、小さな会社でもっとも記録されていないデータです。見積もりを出さなかった問い合わせ、結局人が全部やってしまった作業、一部だけ受けて残りを返した案件。これらは売上にも満足度にも現れないまま消えます。小さな会社では、能力が上がった証拠はここにいちばん濃く残ります。以下では、その記録様式を五つの欄で示し、四半期ごとの読み方を三つの結論に分け、範囲が広がっていたときに値上げと対象拡大のどちらを先にするかを決めます。

満足度が動かないのは、評価されるのが「受けた依頼」だけだから

5行3列の比較表。見出しは「満足度は、効いたときと効かなかったときを同じ値で返す」。列は観点、満足度で読む、断った依頼で読む。第1行「測っている対象」は、満足度が「引き受けた依頼だけ」、断った依頼が「断った依頼」。第2行「分母の動き」は、満足度が「能力と一緒に上へ動く」、断った依頼が「動かない(過去に断った種類)」。第3行「改善が効いたとき」は、満足度が「横ばい」、断った依頼が「以前の行が通る」。第4行「効かなかったとき」は、満足度がやはり「横ばい」、断った依頼が「以前の行が通らない」。第3行と第4行で満足度の欄が同じ値になっていることが表の要点で、満足度という計器では改善が効いた場合と効かなかった場合を区別できないことを示している。第5行「次の打ち手」は、満足度が「決まらない」、断った依頼が「四つの理由ごとに分かれる」。満足度が横ばいになる理由として利用者が適応し難しい質問へ移ると説明されていることは、Anthropic が公開している Genspark の事例ページの記述に基づく。断った依頼を計器として使う整理と、理由を四種別に分ける記録様式はA&Aの設計案であり、当社が測定した効果を示す図ではない。同ページは、満足度を見るべきでないとは述べていない。

A&Aの考え方

満足度調査に答えるのは、あなたのサービスを実際に使えた人です。返ってくるのは、使えた依頼についての評価です。ここに構造的な抜けがあります。難しすぎて断った依頼、手で肩代わりした依頼、受けたものの作り直した依頼は、調査票に載りません。能力が上がって難しい依頼を引き受けられるようになると、引き受けた集合そのものが入れ替わります。前回と今回で、測っている対象が違うのです。同じ尺度で並べているつもりでも、中身が動いています。

出典に基づく事実

満足度が動かないという観察そのものは、Genspark の共同創業者で CTO の Kay Zhu が検索の分野について述べています。Anthropic が公開している同社の事例ページは、Zhu の見方として Search satisfaction in the field has hovered around 80% for a decade と紹介し、その理由をこう説明しています。Users adapt: as the system handles more, they ask harder questions, and the satisfaction rate stays flat。基盤がどれだけ良くなっても満足率は動かない、利用者が適応して難しい質問へ移るからだ、という説明です。同ページは Genspark 自身についても Genspark was seeing the same pattern と書いています。

Anthropic ↗

A&Aの考え方

ここから出てくる結論は「満足度は見なくてよい」ではありません。満足度は、改善が効いた場合と効かなかった場合の両方で横ばいになりうる、という点です。両方を同じ値で返す計器は、その二つを区別できません。横ばいを見て開発を止める判断も、横ばいを見て開発を続ける判断も、この計器だけでは支えられません。判断を変えるつもりがあるなら、別の計器が必要になります。

断った理由の種別ごとに、次の打ち手を分ける(A&Aの設計案。理由の種別も再試行の間隔も、どちらの出典にも書かれていません。そもそも記録がなければ判定できないので、断った時点で一行書く運用から始めます)
断った理由の種別モデルやコードの改善で解けるか解けないなら、次に直すもの
能力が足りない(出力の質、扱える形式、処理できる量)解ける場合がある。三か月後の再試行が一度ぶんの判定材料になる通れば値上げか対象拡大、通らなければ改善の方向を疑う
前提となる情報が顧客側にない(判断基準が文書化されていない)解けない。良くなっても基準が存在しないままになる引き渡し前の質問票。何を合格と呼ぶかを顧客に書いてもらう
責任を負えない(誤りが相手の損失に直結する)解けない。誤りの確率が下がっても責任の所在は変わらない契約条項。人の確認を挟む範囲と、負わない範囲の明記
採算に合わない(個別の様式や例外対応が主)解けない。安くはなるが、個別対応の時間は残る価格と範囲外の定義。別見積もりにするか、断る基準

出典:Gensparkでは、簡単な質問と難しい質問で壊れ方が違った

出典に基づく事実

同じ事例ページは、Genspark が以前使っていた設計の壊れ方を具体的に書いています。あらかじめ決めた工程を結んだ構造の下で、Simple questions ran through too many steps. Hard questions hit walls the workflow didn't know how to route around という状態だった、と記述されています。簡単な質問は余計な工程を通り、難しい質問は迂回路を知らない壁に当たる。そして The system that had taken Genspark to millions of users could no longer go where users wanted to go と続きます。

Anthropic ↗

出典に基づく事実

依頼の難度だけでなく、種類も動いたことが同ページに書かれています。提供側が計画していなかった用途を利用者が持ち込んだ例として、日本の水産業の経営者が国内需要の分析と新規の見込み客の発掘に使っている(Japanese seafood industry CEOs use Genspark to analyze domestic demand and source new leads)という記述があります。提供側が想定した用途の一覧と、実際に届いている依頼の一覧は、同じではありません。この点は、後で示す台帳の二列目、依頼を相手の言葉に近い一文で書くという欄の理由でもあります。自分の分類にない依頼ほど、言い換えた瞬間に見失います。

Anthropic ↗

A&Aの考え方

両端で壊れ方が違うことは、改善の方向を決めるときに効いてきます。簡単な依頼で余計な工程を踏んでいるなら、直すべきは速さと手数です。難しい依頼で壁に当たっているなら、直すべきは扱える範囲です。横ばいの満足度は、この二つのどちらが起きているかを教えません。どちらの端で断っているのかを知るには、断った依頼を端ごとに分けて持っておく必要があります。満足度の平均は、両端の情報を打ち消し合わせてしまいます。

出典:Chatbaseでは、顧客の要求が製品の範囲を動かした

出典に基づく事実

もう一つの事例は Chatbase です。AIで顧客対応を自動化する基盤を提供している会社で、Anthropic の事例ページは出発点と現在の差をこう書いています。What began as a document chat interface evolved as enterprise customers pushed for more sophisticated features。文書に質問できる画面として始まり、法人顧客がより高度な機能を求めたことで変わっていった、という記述です。同ページが範囲の変化の理由として挙げているのは、法人顧客の要求です。提供側の計画がどうだったかは、このページに書かれていません。

Anthropic ↗

出典に基づく事実

現在の範囲も具体的に書かれています。同ページは、業務システムと接続して実際の操作まで行えると説明し、例として from checking order status in Stripe to processing refunds with human oversight を挙げます。返金のような操作について同ページは with optional human oversight for sensitive operations と書いています。人の確認は必須ではなく任意として記述されています。なお同ページの別の箇所では optional を付けずに human oversight と書かれており、必須かどうかはページ上で一貫していません。応対の文言を返すことと、相手の支払いに関わる操作を実行することが、同じ基盤の上に並んでいます。

Anthropic ↗

出典に基づく事実

同ページには、顧客の反応をひとつの数字に潰さない扱い方も書かれています。創業者の Yasser Elsaid の言葉として、会話の分析が The AI can summarize exactly what customers want, what parts of the product they dislike, and how their sentiment changes over time をまとめられる、と紹介されています。要望、不満、感情の変化が、別々のものとして並べられています。

Anthropic ↗

A&Aの考え方

満足度という一つの数字は、この三つを足して潰したものです。潰す前の三つを別々に持っていれば、横ばいの内訳として何が動いたかを後から言えます。そのうえで注目したいのは、範囲が広がった証拠がどこに現れたかです。満足度の推移ではなく、「いま何を引き受けているか」のリストに現れています。文書への質問から、注文状況の確認、そして返金の実行へ。これは能力の増分を、受け入れ可能な依頼の種類として書き出したものです。読者が自分の事業で作るべき記録も、形はこれと同じです。違うのは一点だけで、一人や少人数の会社では「引き受けているもの」より「断ったもの」のほうが情報量が多いことです。引き受けているものは三行で書けてしまいます。

記録するのは断った依頼:五つの欄

A&Aの考え方

断った依頼の台帳は、五つの欄で足ります。一、日付。二、依頼の内容を相手の言葉に近い一文で。こちらの用語に言い換えると後で同じ依頼を見つけられなくなるので、原文に寄せます。三、断り方の種別。完全に断った/人が全部やった/一部だけ受けて残りを返した/受けたが作り直した、の四つです。四、断った理由の種別。能力が足りない/前提となる情報が顧客側にない/責任を負えない/採算に合わない、の四つです。五、再試行の予定日。再試行の間隔は、どちらの出典にも書かれていません。三か月は本稿が置く初期値です。表計算の一枚で足ります。専用の道具は要りません。

A&Aの考え方

四番目の欄が、この台帳の本体です。四つの理由のうち、モデルやコードの改善で解けるのは「能力が足りない」だけです。残りの三つは、サービスが良くなっても同じ依頼を断り続けます。前提情報がないなら必要なのは引き渡し前の質問票で、責任を負えないなら必要なのは契約条項で、採算に合わないなら必要なのは価格と範囲外の定義です。この区別をしないまま「断った件数が減らない」と読むと、開発で解けない問題を開発で追いかけることになります。下の表は、理由の種別ごとに次の打ち手を分けたものです。

仮想例

架空の例で埋めてみます。問い合わせメールを要約して担当者へ振り分けるサービスを、一人で提供しているとします。四月に断った依頼が四件あったとします。一件目、添付のPDF見積もりの金額も拾って要約に入れてほしい。断り方は完全に断った、理由は能力が足りない。二件目、至急かどうかも判定してほしい。断り方は一部だけ受けた(人が最終確認する前提で付けた)、理由は前提情報が顧客側にない。何を至急と呼ぶかの規則が、顧客の側に文書として存在していませんでした。三件目、要約が間違っていた場合の責任範囲を契約に書いてほしい。断り方は完全に断った、理由は責任を負えない。四件目、社内の三部署それぞれの様式に合わせて別々に出してほしい。断り方は受けたが作り直した、理由は採算に合わない。七月に一件目を再試行して通ったなら、扱える範囲は確かに広がっています。二件目から四件目が通らないのは、改善が効かなかった証拠ではありません。最初から開発の問題ではなかったからです。

A&Aの考え方

再試行で「通った」と言える条件は、先に決めておきます。出力が出たことではなく、その依頼を出した相手の業務で使える状態になったかどうかです。この合否の決め方は別の記事に分けています。「AIが「完了」と言ったあと、業務の成果をどう確かめるか」です。台帳の再試行欄には、その確認を通ったときだけ丸を付けます。ここを緩めると、台帳は能力の計器ではなく希望の記録になります。

四半期ごとの読み方:結論は三つに分かれる

A&Aの考え方

三か月後、台帳の「能力が足りない」行だけを再試行します。結論は三つに分かれます。一つ、以前は断っていた種類が通るようになった。扱える範囲は広がっています。このとき次の打ち手は改善の継続ではなく、値上げか対象業務の拡大です。広がった範囲を価格か売り先に換えないかぎり、改善は原価のまま残ります。二つ、通らない。ここで初めて改善の方向を疑います。満足度の横ばいではなく、再試行の不通が、方向を疑う根拠です。三つ、そもそも「能力が足りない」行が少なく、断りの理由が他の三つに偏っている。これは開発の問題ではありません。質問票、契約条項、価格のどれを直すかの問題です。

A&Aの考え方

件数の目安を一つ置きます。測定した根拠はありません。一人の会社なら、三か月で十数件の断りが溜まったあたりから読み始める、という程度の目安です。溜まらないなら、断りが起きていないのではなく記録されていないほうを先に疑ってください。丁寧に断ると、断ったことに自分でも気づきません。「それは今の範囲では難しいので、別途ご相談で」と返した時点で一行書く、という運用にしておきます。一行を書く手間は安い側です。費用の大半は、四半期ごとに十数件を実際に走らせ直し、それぞれ合否を決める側にあります。

A&Aの考え方

受けた依頼の側の分類は、別の記事で扱っています。「AIサービスの問い合わせを機能要望に直結させない:修正・説明・新機能を分ける」です。そちらは入ってきた問い合わせの行き先を決める話で、本稿は入らなかった依頼を計器として使う話です。二つの台帳は分けて持ったほうが混ざりません。入ってきたものは対応の優先度を決め、入らなかったものは開発を続けるかどうかを決めます。

広がっていたとき、値上げと対象拡大のどちらを先にするか

A&Aの考え方

範囲が広がっていたとき、値上げと対象業務の拡大は同時にはやりません。判定は一つで足ります。新しく通るようになった依頼の種類が、いまの顧客が実際に出している依頼かどうかです。いまの顧客の依頼なら、値上げが先です。すでに届いている価値に対価が付いていない状態だからです。いまの顧客が出していない依頼なら、対象の拡大が先です。価値は増えていますが、それを受け取る相手がまだいません。順番を逆にすると、既存顧客には理由の説明できない値上げが、新しい買い手には実績のない売り込みが届きます。

A&Aの考え方

値上げの根拠として相手に出すのは、満足度でも改善の件数でもありません。範囲の差分です。以前は対象外として断っていた依頼の種類を挙げ、それがいま契約の範囲内で通ることを示します。顧客にとっては、支払いが増える代わりに自分の依頼の通る範囲が広がる、という交換になります。改善の努力量や更新の回数を根拠にすると、この交換が成立しません。台帳の二列目・三列目・五列目、つまり依頼の内容、断り方、通った再試行が、そのまま値上げの説明文の材料になります。

A&Aの考え方

顧客獲得から継続までのどの位置でこの判断が起きるかは、全体像の側で整理しています。「AIネイティブGTMとは?一人・少人数で顧客獲得から継続まで回す実践ガイド」です。本稿が扱っているのは、そのうち継続と価格の境目にある一点です。改善の成果をどこで回収するかという問いは、獲得の側の打ち手とは別に考えたほうが混ざりません。

Gensparkの観測量は、一人の会社には移らない

出典に基づく事実

移らないものを先に書きます。同ページによれば、Genspark は AI Workspace の大きな版を shipping major versions of AI Workspace on a roughly two-month cadence で出しています。そのコードは roughly 50 engineers が produce all of the company's code through AI tools と記述される形で、全量を AI の道具を通して書いています。

Anthropic ↗

A&Aの考え方

観測量と改善の速度が違います。二か月ごとに大きな版が出る会社では、難度の分布の変化も版ごとに観測できます。一人の会社では、同じ観測を四半期に一度、十数件の再試行で代替します。頻度を落とす代わりに、記録する側を人の手で揃える、という置き換えです。精度は落ちますが、横ばいの満足度よりは二つの場合を区別できます。

A&Aの考え方

数字の扱いも区切っておきます。Zhu の「十年ほど80%前後」という記述は、同ページ上で出典・測定方法・対象範囲が示されていません。業界の見方として述べられた発言であり、検証された統計として扱えません。本稿はこれを数値の根拠には使わず、満足度が動かない理由が複数ありうるという論点としてだけ使っています。読者が自社の目標値をこの数字に合わせる根拠にはなりません。

Anthropic ↗

この測り方が成り立たない場合

A&Aの考え方

引用した二つのページは、どちらも対象企業と提供元による自己記述であり、独立した監査ではありません。Chatbase の Tripled user adoption since integration と 60-70% of customers in US/Canada には、母数・基準時点・定義がページに書かれていません。他社の見込みには使えませんし、本稿の判定基準の根拠にもしていません。

Anthropic ↗Anthropic ↗

A&Aの考え方

横ばいの理由は、能力の向上に伴う需要の移動だけではありません。価格が高い、競合が増えた、応対の質が落ちた、そしてそもそも改善が効いていない、のいずれもありえます。どちらの出典にも、これらを同時に否定する証拠はありません。断りの台帳は能力の軸だけを分離する道具で、他の原因を否定するものではありません。範囲が広がっているのに横ばいが続くなら、価格と競合の側を別に見る必要があります。

A&Aの考え方

台帳そのものの限界も二つあります。一つ、過去の分は作れません。今日始めた台帳で最初に正直な増分が出るのは三か月後です。二つ、記録の漏れは必ず「能力が足りない」側に偏ります。難しいから断った依頼は印象に残りますが、採算で断った依頼は見積もりを出さなかっただけなので記録に残りません。偏ったまま読むと、開発の優先度を過大に見積もります。最初の一四半期は、この偏りを前提に読んでください。

A&Aの考え方

最後に、当方が測っていないことです。この測り方を使った場合の継続率、値上げの受諾率、売上への影響をA&Aは測定していません。本稿は計器の選び方についての主張で、結果の予測ではありません。値上げ幅や対象拡大の目安も示していません。三か月分の台帳を読んでも断りの理由が混ざって切り分けられないときは、開発を進める前に一度、外から見て分けたほうが早い場面です。

改善しても満足度が動かないとき、最初に疑うのは開発の方向ではなく計器です。満足度が測っているのは引き受けた依頼だけで、その集合は能力と一緒に上へ動きます。測るべきは、半年前は断っていた依頼をいまは引き受けられるか。材料は、断った依頼を五つの欄で記録した台帳です。四半期ごとに「能力が足りない」行だけを再試行し、通ったなら値上げか対象拡大へ、通らないなら初めて改善の方向を疑い、そもそも能力以外の理由に偏っているなら質問票・契約条項・価格のどれかを直します。Genspark のページが述べているのは満足度の目標値ではなく、利用者が適応して満足率が動かないという点です。だから満足度は能力の代理にならない、という結論は本稿の主張です。Chatbase のページで範囲の変化が見えるのは「いま何を引き受けているか」のリストで、同ページは満足度に触れていません。今週できることは一つです。次に断ったとき、一行書いてください。

出典・編集情報

記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。

  1. Genspark's Super Agent orchestrates 150+ tools with Claude

    Anthropic · no date shown on page

    確認日 2026-10-05
  2. Chatbase helps companies deliver instant, personalized customer support with Claude

    Anthropic · no date shown on page

    確認日 2026-10-05

AIを活用した記事制作

調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。

編集上の確認日: 2026-10-05

← 記事一覧へ