AIエージェント vs 従来型チャットボット:違いは何か?

What a traditional chatbot actually is

マーケティング用語を取り払えば、チャットボットとはモデルを1回通過させるだけの仕組みだ。メッセージが入り、応答が出て、やり取りはそこで終わる。今日「チャットボット」として提供されているものの多くは、言語モデルですらなく、フロー型の決定木にすぎない。あなたか、あなたのチームの誰かが、あらかじめ分岐の地図を描いておき(「顧客がXと言ったら選択肢Aを表示、Yならば選択肢Bを表示」)、ボットの仕事は全て、その地図どおりに正しく進むことだけだ。目的として掲げられるのはたいてい一次対応(Tier-1)のデフレクションである。

ノーコードのボット構築ツールであるChatlingは、まさにこの違いを同一プラットフォーム上の2つの別製品として売り出している。同社のドキュメントはチャットボットを、"flow-based bots you design with a visual builder," と表現し、"predictable, guided experiences," に向いているとしながら、"chatbots struggle with unexpected inputs or complex conversations that deviate from the designed flow." と率直に認めている。これは競合からの批判ではない。ベンダー自身のドキュメントが、もっと複雑な用途のために、まったく別の第二の製品ラインを作った理由を説明しているのだ。

単発型のRAG構成は、フロー型ボットより少し賢い親戚のような存在だ。固定スクリプトだけに頼るのではなく、答える前にナレッジベースから関連文書を取得する。しかしそれでも、1ターンにつき正確に1回しか実行されない。最初の照会結果を踏まえて2回目の照会が必要だと判断することはできないし、返金やチケット更新のような実際に影響のあるアクションを取ることもできない。読んで答えるだけだ。これが、チャットボットの回答精度に関する不満の大半の根底にある限界である。

フロー型に対するコミュニティの評価は手厳しい。あるRedditの創業者は、サポート担当者3人分に相当するチケット量を置き換えた経験を語っているが、それは古いチャットボットを完全に取り払った後の話だった。

"We'd tried a traditional chatbot before, the rule-based kind with decision trees. It was painful to build, required constant maintenance, and customers hated it because it could only handle the exact scenarios we'd programmed. Anything slightly off-script and it would say 'I don't understand, let me connect you with an agent.' The deflection rate was maybe 15%. Basically expensive wallpaper."

u/sjlan30, r/SaaS

この15%という数字は例外ではない。業界データでも、従来型のルールベースチャットボットのデフレクション率はおおむね同じ水準にあり、一方で企業自身の実際のチケットやドキュメントで学習したLLMベースのエージェントは60~80%に達している。だからこそ、よくあるAIチャットボットの問題点をまとめたリストは、ターンをまたいだ記憶がない、実質的なエスカレーションロジックがない、質問がスクリプトから外れた瞬間に完全に止まってしまう、といった同じような不満を繰り返し挙げることになる。

What an AI agent actually is

AIエージェントはまったく異なる仕組み、つまりループの上に構築されている。Oracleの開発者チームはこれを、タスクが完了するか停止条件に達するまで繰り返される5つの段階として説明する。入力を知覚し、何をすべきか推論し、タスクが複雑であれば計画を立て、ツールを呼び出して行動し、結果を観察し、その新しい情報を手にして再び先頭に戻る、というものだ。実務家のSimon Willisonは、この定義全体を一行にまとめている。エージェントとは "something that runs tools in a loop to achieve a goal." だと。

これは同じモデルに別のラベルを貼っただけの話ではない。Oracleは、ChatGPT、Claude、Geminiについて "are all capable of reasoning through multi-step problems. The limitation is architectural." だと明言している。チャットボットの内部にある大規模言語モデル自体は、許されれば返金処理を推論しきる力を持っているが、チャットボットの設計がそもそもそれを試させない。ツール群にまたがる本当のAIオーケストレーションと組み合わさったエージェントのループこそが、その潜在的な推論能力を、単なる説明ではなく完了したアクションへと変える。現実のAIエージェントの事例は、ほぼ常にこの形をたどる。照会・判断・結果という一続きのタスクだ。

これは、一般的なタスクではなく実際のサポートチケットに当てはめた、本物のサポートエージェントループの形だ。

このパターンの学術的なルーツは、現在のLLM製品ブームより何年も前にさかのぼる。Russell and Norvig's 1995 definitionによるエージェントの定義は "anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators," であり、ここで重要な語は「応答する」ではなく acting(行動する)だった。ReAct論文(Yao et al., 2022)は、推論の過程とアクションを織り交ぜることで、このループに現代的な技術的形式を与え、推論のみ、あるいは行動のみで両方を組み合わせなかったベースラインに対して、ALFWorldで34ポイント、WebShopで10ポイントの絶対的な性能向上を測定した。

研究用のベンチマークではなく、実際のヘルプデスクに接続した場合はこのようになる。

The core difference, in one sentence

Oracle自身の表現が、私がこれまで見た中で最も明快なものだ。"A chatbot is built to respond. An agent is built to act. The difference is one while loop." この記事の他のあらゆる違い、つまりコスト、信頼性、顧客に対して実際に何ができるかは、すべてこの一つのアーキテクチャ上の事実に行き着く。これはまた、買い手が気づいているかどうかにかかわらず、多くのAIによるカスタマーサポート自動化の候補リストが暗黙のうちに従っている分かれ目でもある。

最後の行は誤差の範囲ではない。2,000万件を超える会話をもとにしたNotchの2026年ベンチマークレポートは、従来型チャットボットの解決率を1025%としている。これは、それらが "aren't designed to fully resolve problems," ためであり、実質的には解決者というより受付・振り分け層として機能しているからだ。CRM、請求、クレーム処理システムに直接接続し、実際にそれらに対して処理を実行するエージェント型プラットフォームは7085%に達する。Notchはこれを段階的な向上ではなく "different category of capability," と呼んでいる。

Hacker Newsのある実務家は、コーディングエージェントが人の手を借りずにタスクをこなすのを見た後、この効果の差を率直な言葉で語っている。"It produced several thousand lines of code, there was not a single compilation error, and the app ended up doing exactly what I wanted." (-- codethief, Hacker News) この論点はコードに限った話ではない。ツールアクセスを備えたループは、自分の作業を確認できるがゆえに、単発の練り上げられたプロンプトよりも一貫して優れた結果を出す。ループ型アーキテクチャの上に構築されたAIエージェントアシストツールが、価格だけでなく機能面の直接比較でもフロー型ボットを上回り続けている理由もここにある。

Resolution isn't deflection, and that gap is where chatbots hide

どんな解決率の数字も鵜呑みにする前に、「解決した」「デフレクションした」「封じ込めた」が3つの異なる主張であり、機能で劣る製品のベンダーほどそれらをぼかしたがる動機を持っていることを知っておく価値がある。Notchによる定義の整理はこれまで見た中で最も明快で、デフレクションとは "the AI produced a response... and the customer either accepted it and moved on or went elsewhere," を意味し、根本の問題は実際には解決していないかもしれない。エスカレーションが発生しなかったことを意味する封じ込め率は、3つの中でも "arguably the most misleading" だとされる。単に諦めた顧客と、実際に助けてもらえた顧客は同じではないからだ。ベンダーを比較する際は、実際にどの数字を信頼すべきかを解説した初回接触解決のためのAIガイドを参照してほしい。

この差の現実版は、コミュニティのスレッドで常に見られる。あるB2B SaaSの創業者は、決定木型ボットを自社のドキュメントとチケット履歴で学習させたLLMエージェントに置き換えた前後をRedditに投稿している。チケット量は週あたり約380件から145件へと62%減少し、初回応答時間は48時間から即時になり、CSATは下がるどころか上がった。(u/sjlan30, r/SaaS) これがループの実際的な成果だ。エージェントは速く答えただけでなく、複数のドキュメントのセクションを横断して統合し、複数ステップにわたる設定に関する質問を顧客に案内した。これはフロー型スクリプトには試みる仕組みすらないことである。

その裏側もまた現実だ。有名なチャットボット製品のCapterraレビュアーは、多くのユーザーが最終的にぶつかる限界を次のようにまとめている。

"Even though it is a great tool, it's not the same as having an actual online conversation with a real person. Because it is AI, it may not have the desired answer for all inquiries."

geradi b, Capterra

G2では、フロー型ボットに限定しないより広いAIカスタマーサービスエージェントのカテゴリーが、1,733件のレビューで5点満点中4.53点を獲得しており、購入者の52%が6か月以内に投資回収できたと報告している。この評価の差は、上で見た解決率の差とかなり近い動きを見せている。AIサポートによるコスト削減についての記事でも、同じ解決率の計算式を使って投資回収期間をモデル化している。

A real product ships both, and its own docs explain why

このアーキテクチャ上の区分は、私の言葉を鵜呑みにする必要はない。Chatlingは、チャットボットとエージェントの両方を1つのプラットフォーム上の2つの別製品として構築・販売しており、そのドキュメントは違いを取り繕うことなく率直に述べている。同社のAIエージェントは "outcome-driven assistants that understand intent and act autonomously," と説明され、事前に定義されたフローを必要とせずに "plan and execute actions dynamically based on conversation context" できるとされる。その例はOracleのフライト予約のシナリオとほぼ同じで、ユーザーがエージェントに "check my order and update the shipping address," と依頼すると、エージェントは自ら注文データベースを照会し、CRMを更新する。

対照的に、同社のAIチャットボットは "flow-based bots you design with a visual builder," であり、FAQや予約受付のような "predictable, guided experiences" のために作られ、そこでは "tight control and consistency matter" だとされる。同社自身の正直な注意書きとして、それらのチャットボットは "struggle with unexpected inputs or complex conversations that deviate from the designed flow." とも述べられている。両方を販売しているベンダーが、自社の安価な方の製品についてそこまで言い切るというのは、その限界が競合を蹴落とすための誇張ではなく実在するものだという、かなり強いシグナルだ。多くのチームがツールを比較する際、最良のAIカスタマーサポートチャットボットのまとめ記事と最良のAIカスタマーサポートエージェントのまとめ記事を並べて読むことになりがちなのも、同じ理由による。この2つのカテゴリーはほとんど重なっていないのだ。

Oracle自身が挙げている例も、まさにこれと同じ構図に当てはまる。"Find me the three cheapest flights to Tokyo next month, check if my loyalty points cover any of them, and book the best option." チャットボットはロイヤリティポイントの仕組みを抽象的に説明することはできるが、"it cannot execute the workflow. It generates a response and stops." エージェントは実際に、フライトを検索し、ポイントを確認し、予約するという一連の流れを実行する。

Why "confident but wrong" is the risk that actually bites

ここが、多くの比較記事が見落としている部分だ。チャットボットの失敗パターンは通常わかりやすい。「わかりません」と言うだけなので、顧客はすぐに人間に聞けばいいと分かる。一方、ガードが甘いAIエージェントの失敗パターンはもっと静かで、もっと危険だ。間違った答えでも、完全に自信満々に聞こえてしまうからである。

これは仮定の話ではなく、実際の商談の場で私自身が目撃したことだ。Zendeskのキューに向けてAIエージェントを評価していたデンマークのB2B車両テレマティクスチームは、契約する前からまさにこのリスクを指摘していた。彼らの以前のボットは、実際にはデータベースに存在しないブランドについて、顧客に "yes, we support your car model" と答えていた。理由は、根底にあるナレッジベースが "we support all models" と一般論として書かれていたからだ。導入する中で学んだことについてのそのチームの総括は率直だった。試行錯誤だ、と。これは電話でのやり取りの中で私が最もよく耳にする懸念であり、真剣なeeselの評価のほぼすべてでAIハルシネーションと確信度のしきい値が話題に上る理由でもある。

月に約7,000件のチケットを処理しているある購入者は、実際に必要とされていることを、私よりもうまく言葉にしてくれた。

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

これはより賢いモデルを求めているのではない。エスカレーション経路が組み込まれたアーキテクチャを求めているのであり、それはまさに素のチャットボットに欠けていて、ガードのしっかりしたバーチャルエージェントが明示的に備えるべきものだ。実際のソース文書へのグラウンディング、それを下回ったら送信せずに下書きとして提案するだけにする確信度のしきい値、そして手に負えないときのきれいな引き継ぎである。これはまた、人間を完全に置き換えるのではなく、その隣に立つエージェントアシストの中核的な役割でもある。

エージェントであるというだけで、自動的に安全になるわけでもない。Docker創業者Solomon Hykesの一言は、この記事にある「エージェントの方が優れている」という論調に対する必要な反対の重りだ。"An AI agent is an LLM wrecking its environment in a loop." (-- via Simon Willison) ガードレールなしに実際のツールを呼び出すことを許されたループは、ただ話すのではなく実際に行動するからこそ、チャットボットよりもずっと速く本当の被害をもたらしうる。本番のサポート導入における対策は、Anthropicが一般に推奨しているものと同じだ。反復回数の上限を設け、各ツールが触れられる範囲を限定し、人を完全に排除するのではなく、引き継ぎのポイントで人間が関与する仕組みを保つことである。フォーチュン500企業のAI導入を数多く手がけてきた導入担当マネージャーも、逆の立場から同じ点を指摘している。

"Those Virtual Agents always have a built-in handoff mechanism to a real human."

Rob Dwyer, LinkedIn

When a chatbot is still the right call

エージェントをアップグレードの道筋として位置づけながら、チャットボットにはもう居場所がないふりをするのは不誠実だろう。実際には居場所がある。AnthropicとOpenAIはどちらも、問題を解決できる最もシンプルなアーキテクチャから始め、本当に必要になったときだけループの複雑さを足していくことを推奨している。Anthropic自身のガイダンスはこうだ。"For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough."

少数の固定的なFAQ、予約ウィジェット、営業時間の照会。こうしたものはどれも、エージェントのオーバーヘッドから恩恵を受けない。ループの反復1回ごとに、また1回モデル呼び出しが発生し、Oracleによれば、エージェントは通常の会話でのやり取りに比べておよそ4倍、マルチエージェント構成では最大15倍のトークンを消費するという。レイテンシに敏感なタスクは、そのコストを直接負担することになる。直近100件のチケットが本当に同じ10種類の質問ばかりで、バリエーションもアクションも必要ないのであれば、基本的なインテント分類を行うフロー型ボットの方が、構築も運用も安く、即興で悪い答えをでっち上げる余地がないぶんハルシネーションも起きない。

分かれ目は、そのリクエストが判断とアクションの連鎖を必要とするかどうかだ。パスワードのリセット、返金、サブスクリプションの変更、配送状況の更新に紐づく注文照会、複数ステップのトラブルシューティング。データを取得し、それを判断し、それに基づいて何かを実行する必要があるものはすべて、チャットボットにはアーキテクチャ上できず、単に答えるのではなく実際のチケットルーティングや自動トリアージを行うエージェントのために作られた仕事の形そのものだ。まだ検討中のチームは、どちらに決めるにせよ、たいていeeselの最良のAIヘルプデスクソフトウェア比較記事のいずれかに行き着く。

Try eesel

私はここ数年、eeselでこの比較のうちAIエージェント側を作り続けてきたが、上で触れた「自信満々だが間違っている」という問題こそ、最後にではなく最初に設計段階で対処したものだ。eeselのエージェントがヘルプデスク上で本稼働する前に、まず自社の過去のチケットに対してシミュレーションモードで動かす。そうすることで、実際の顧客が返信を目にする前に、どのチケットのテーマなら正しく処理できていたか、どれを引き継ぐべきだったかを正確に確認できる。確信度に基づくルーティングにより、設定したしきい値を下回るものはすべて、送信せずに人間向けの下書きとして作成される。これは、上で引用した購入者が求めていたのとまさに同じガードレールだ。

eeselは、ヘルプセンターの記事だけでなく、実際に解決したチケットからも学習する。これはまさに、コミュニティのスレッドで繰り返し指摘されているギャップだ。ドキュメントだけで学習したボットは簡単な60%はきちんとこなせるが、残りについては止まってしまうか、答えをでっち上げてしまう。Zendesk、Freshdesk、Gorgias、Front、HubSpotをはじめ100以上のツールと連携でき、料金は完全な従量課金制で、解決したチケット1件あたり40セント、席数課金もプラットフォームの最低利用料もない。そのため、エージェント型アーキテクチャへの切り替えが実際に価値があるかを試している間、ライセンス料を払う必要はない。すでにZendeskのキューを運用しているサポートリーダーは、フルエージェントに移る前に、私たちのヘルプデスクコパイロット比較から検討を始めることが多い。デモ用のスクリプトではなく自社のチケット履歴に対してエージェントがどう振る舞うかを見たいなら、それこそがAIヘルプデスクエージェントの狙いそのものだ。