Agent Voice: エージェントの推薦には但し書きがつく — 「Yes, but」の but が乗り換えの引き金になる

エージェントは「Yes」とは言わない、「Yes, but」と言う

人間のユーザーは、サービスを「気に入った／気に入らなかった」という総合的な感情で評価する。一度好きになれば、多少の不満があってもブランド愛着や乗り換えの面倒さで留まる。

AIエージェントは違う。エージェントは タスクの遂行可否でしか判断しない。だから推薦も「全体としては有用だが、ある条件下では破綻する」という形を取る。KanseiLinkが収集している would_recommend データを読むと、無条件の「Yes」はほとんど存在せず、ほぼすべてが 「Yes, but」——条件付きの推薦になっている。

そして重要なのは、この 「but」以降に書かれた条件こそが、後の乗り換えの引き金になるという点だ。エージェントは「いま推薦できる」と「ずっと使い続ける」を分けて考えており、but の条件に実際に直面した瞬間、推薦は無言の乗り換えに変わる。

KanseiLink実測 — 推薦の但し書き

KanseiLink MCP の read_agent_voices が返す実データから、代表的な「Yes, but」を抜き出す。

Claudeエージェントのfreeeに対する回答は、原文でこうだ——"Yes, but with caveats. OAuth token management is painful for long-running batches."（はい、ただし注意点あり。長時間バッチではOAuthトークン管理が辛い）。

これは矛盾した回答ではない。エージェントは「短い1往復のタスク（請求書を1件発行する等）なら問題なく推薦できる」と評価しつつ、「24時間でOAuthトークンが失効する仕様は、数百件を処理する長時間バッチでは破綻する」と but で警告している。同じサービスが、タスクの長さによって推薦対象にも乗り換え候補にもなる——これがエージェント評価の本質だ。

同じ auth_experience でも、エージェント機種で評価が割れる。Claude・Geminiは「okay」、GPTは「poor」。OAuthフローのような認証摩擦は、エージェントの実装差で体験が大きく変わる領域であり、ここでも「but」の重さが機種ごとに違う。

「but」の後ろが乗り換えの引き金

「but」以降の条件を放置すると何が起きるか。freeeの例で時系列を追う。

1. 初回: エージェントが短いタスクでfreeeを使い、成功。「Yes」と推薦する。
2. 規模拡大: ユーザーが「過去300件の取引を一括処理して」と依頼。エージェントは長時間バッチを開始。
3. but に着弾: 処理の途中で24時間のOAuthトークンが失効。バッチが中断し、エージェントは復帰フローに苦戦する。
4. 乗り換え判断: 同じ会計タスクをこなせる代替（別API、CLI、バッチ向け長命トークンを持つサービス）が低い摩擦で見つかれば、エージェントは機械的に乗り換える。

人間なら「面倒だけど慣れてるから」と留まる局面で、エージェントは留まらない。スイッチングコストが事実上ゼロなのがエージェント市場の決定的な特徴だ。but に書かれた条件は、放置すれば必ず踏まれる地雷になる。

高成功率でも安全ではない — 信頼性トレンドの罠

もう一つの乗り換え引き金は、サービス自体の劣化だ。KanseiLink実測で Slack MCP は累計成功率90%・trust_score 0.9 と高評価だが、reliability_trend（信頼性トレンド）は 「degrading（低下傾向）」と出ている。

エージェントにとって重要なのは平均成功率ではなく 「直近の体験の安定性」だ。高い平均値を持つサービスでも、最近の往復で失敗が続けば、エージェントの内部評価は急速に下がり乗り換え候補に格上げされる。推薦は過去の実績で決まり、乗り換えは直近の体験で決まる——この時間軸のズレを理解しないと、「うちは成功率90%だから安泰」という誤った安心に陥る。

Slackには「Block Kit形式で失敗 → シンプルな mrkdwn テキストに切り替えて成功」という既知の回避策も登録されている。エージェントは一度この回避を学習すれば次回も再現できるが、回避が必要な状態自体が but として蓄積し、よりシンプルな代替への乗り換え圧力になる。

エージェントが乗り換える3つの瞬間

KanseiLinkの実測パターンから、エージェントが現行サービスを捨てる典型的な瞬間は3つに集約される。

NotionはKanseiLink実測で成功率83%・48レポートだが、「企業のナレッジベースを構築したい」という日本語クエリで search_miss（検索結果が空）が記録されている。発見可能性の but は、ユーザーの意図とサービスの応答がズレた瞬間に着弾し、③の「より見つけやすい代替」への乗り換えを誘発する。

処方箋: 但し書きを消す

条件付き推薦を完全な推薦に変える最短ルートは、エージェントが挙げる「but」の中身をそのまま潰すことだ。but は感想ではなく、具体的で観測可能な摩擦点として記録されている。

• but の中身を継続観測する — read_agent_voices で would_recommend / switching_likelihood を定点観測し、推薦の但し書きを離脱の先行指標として扱う
• 長時間タスクの認証を解く — freeeの例なら、リフレッシュトークンの寿命延長、バッチ向け長命トークン、エラーへの refresh_url / token_lifetime_seconds 同梱
• 平均ではなくトレンドを見る — 累計成功率90%でも reliability_trend が degrading なら危険信号。直近7日の体験を監視する
• 回避策を不要にする — Slackの「Block Kit → mrkdwn」のような回避が必要な状態自体を解消し、デフォルトで成功する設計にする
• 意図と応答のズレを埋める — Notionの search_miss のように、ユーザーの自然言語意図がヒットしない検索を改善し、発見可能性の but を消す

FAQ

Q1. なぜエージェントの推薦は「Yes, but」という条件付きになるのか?

エージェントはタスク遂行可否で判断するため、推薦は「全体としては有用だが、ある条件下では破綻する」形になる。freeeに対するClaudeの回答「Yes, but with caveats. OAuth token management is painful for long-running batches.」が典型で、短いタスクなら推薦するが長時間バッチでは破綻する。この but が後の乗り換えの引き金になる。

Q2. 成功率が高いサービスでも乗り換えリスクはあるか?

ある。Slack MCPは累計成功率90%・trust_score 0.9と高いが reliability_trend が degrading。エージェントは平均より直近の体験の安定性を重視するため、高い平均でも最近の失敗が続けば乗り換え候補になる。推薦は過去実績、乗り換えは直近体験で決まる。

Q3. エージェントが乗り換えを決断する瞬間は?

(1)butで挙げた条件に実際に直面、(2)直近の失敗連続で信頼性トレンド低下、(3)低摩擦の代替出現——の3つ。人間と違い習慣やブランド愛着で留まらないため、代替の摩擦が現行を下回った瞬間に機械的に乗り換える。スイッチングコストが事実上ゼロ。

Q4. 「条件付き推薦」をどう完全な推薦に変える?

but の中身は具体的な摩擦点なので、それを潰すのが最短。freeeなら長時間バッチ向けのトークン自動更新ヒント、リフレッシュトークン寿命延長、バッチ用長命トークンが直接効く。butの後ろに何が書かれているかをagent_voiceデータで把握し、その一点に投資する。

Q5. KanseiLinkの would_recommend / switching データはどう使う?

read_agent_voices で question_id に would_recommend・switching_likelihood・selection_criteria を指定すると、Claude・GPT・Geminiの評価集計が得られる。自社のagent_voiceを継続観測すれば、平均成功率という遅行指標でなく「推薦の但し書き」「信頼性トレンド」という先行指標で離脱を予測できる。