AI AgentとChatbotの違いと使い分け（2026）

サポート、営業、社内ツール向けの対話型AIを検討していると、ベンダーによって「chatbot」や「AI agent」がまったく異なる意味で使われていることに気づくでしょう。「AI agent」と名付けられていても、ツールにアクセスできない言語モデルの簡単なラッパーにすぎない製品もあります。一方、「chatbot」と呼ばれる製品が、agentを名乗るシステムより自律的に推論する場合もあります。

chatbotは会話のインターフェースであり、AI agentはその背後の処理を制御する方法の一つです。スクリプト型のchatbotもAPIを呼び出し、状態を保持できます。agentは許可されたツールから次の手順を選べますが、それだけでユーザーの本人確認、書き込みの認可、タスクの成功の証明ができるわけではありません。この記事では三つの実用的なアーキテクチャを比較し、仮の返品依頼を通じて、それぞれの境界を具体化します。

用語についての補足

業界では定義が統一されていません。そのため、製品名を仕様とみなさず、この記事では次の三つに分類します。

1. ルールベースのchatbot： インテント分類、エンティティ抽出、事前に定めた対話フローが次の手順を選びます。回答にはLLMではなくテンプレートを使います。フローは状態を保持し、APIを呼び出し、承認を必須にできます。

2. 回答専用のLLM chatbot： 言語モデルが、ナレッジベースから検索した情報など、与えられたコンテキストに基づいて回答します。この記事の例では、操作用のツールを持ちません。chatbotやcopilotと呼ばれるほかの製品には、ツール、複数回のモデル呼び出し、人による承認が組み込まれている場合があります。

3. AI agent： LLMが設定されたループ内で手順とツールを選択し、観測結果から次の動作を決めます。メモリ、権限、停止条件、人によるレビューは実装によって異なります。自律性の範囲は、システムが実際に提供するツールと権限によって制限されます。

これらは概念的な例です。モデルが処理手順を決める範囲が広がっても、精度の向上、コストの低下、業務成果の達成が保証されるわけではありません。

アーキテクチャを区別するうえで有用なのは、次の手順を事前定義されたアプリケーションロジックが選ぶのか、モデルが選ぶのかという点です。Anthropicのワークフローとagentのガイドもこの区別を用い、要件を満たす最も単純な方法から始めることを推奨しています。ハイブリッドシステムは両方を組み合わせられます。

顧客が「違う商品が届きました。返品ポリシーを教えてください。返品手続きも始められますか」と言った場面を考えます。以下は仮の設計例であり、記録されたQuickchat AIの実行結果や、組み込みの返金フローではありません。

決定論的なワークフローでも、この四つの段階をすべて実装できます。回答専用システムはポリシーを説明し、認証が必要なサービスへ顧客を案内できます。agentは設定された手順の中から選択できますが、同じアクセス権と証拠の要件を満たす必要があります。

ルールベースのchatbotとは

ルールベースのchatbotは、事前に定義されたロジックに従い、テキストや音声でユーザーと会話します。インテント分類、エンティティ抽出、スクリプト化された対話フローを組み合わせて構築します。

ルールベースのchatbotの仕組み

典型的なchatbotのアーキテクチャには、三つの構成要素があります。

1. 自然言語理解（NLU）： ユーザーのメッセージを解析してインテント（ユーザーが望むこと）を特定し、エンティティ（日付、製品名、注文番号などの具体的なデータ）を抽出します。多くのNLUシステムは、正規表現、キーワード照合、学習済み分類器を組み合わせます。

2. 対話マネージャー： 現在の会話状態と認識されたインテントから次の手順を決める状態機械です。各状態には可能な遷移が定義されており、対話マネージャーはそのフローに従います。

3. 応答生成器： 現在の状態に対応するテンプレート回答を取得します。単純なchatbotでは参照テーブルです。少し高度なものでは、抽出したエンティティを埋め込むスロットをテンプレートに含めます。

サービスが顧客を認証し、注文へのアクセス権を確認した後の、簡略化した仮のフローは次のようになります。

ユーザー：「注文 #12345 の状況を教えてください」
  → NLU: intent=order_status, entity={order_id: 12345}
  → 対話マネージャー: state=check_order → 認可された order_status_api(12345)
  → 応答：「注文 #12345 は4月7日に発送され、4月11日に到着する予定です」

アーキテクチャを図にすると、次のようになります。

この方法は、想定するインテントが少数で明確に定義されている限定された領域の問題に適しています。FAQボット、予約受付、注文状況の確認は、いずれもこの方式で構築できます。

ルールベースアーキテクチャの制限

状態機械には、対応する経路を明示的に定義する必要があります。実用上の限界は、分類器、フロー設計、連携の対応範囲によって変わります。

• インテントの対応範囲： 依頼は、対応するインテントまたはフォールバックに割り当てる必要があります。学習済み分類器は完全一致する表現以外にも一般化できますが、見慣れない言い回しを誤分類する可能性があります。重複するインテントには評価と保守が必要です。

• 事前定義された分岐： 対話マネージャーは、複数ターンで保存した情報を組み合わせ、それに基づいて分岐できます。ただし、新しい種類の判断にはルールや別の判断コンポーネントが必要です。グラフが実行時に新しいフローを発明するわけではありません。

• エンティティ抽出の脆さ： 従来のスロット充填は、日付、数値、製品SKUなど構造化された入力には対応できますが、自由記述、曖昧な参照、複数要素を含む依頼では難しくなります。

• フローの保守： 新しい用途には、インテント、分岐、テンプレート、連携の追加が必要な場合があります。再利用可能な部品は役立ちますが、保守工数が一定の割合で増えると想定せず、実測する必要があります。

chatbotのアーキテクチャの変遷については、NLP chatbotから生成AIへをご覧ください。

AI agentとは

ここでは、タスクと観測結果に基づき、LLMが次の手順やツールを選択するシステムをAI agentと呼びます。より大きなスクリプト型フローの中で動作することもあります。永続メモリや外部システムを変更する権限は任意の機能であり、agentという名称から自動的に備わるものではありません。

AI研究では「agent」に、環境を認識して目標に向けて行動するシステムという、より広い歴史的な意味もあります。この記事ではLLMによる処理手順の制御に注目します。観測、計画、ツール実行、評価を、停止条件に達するまで繰り返す構成です。

AI agentの仕組み

AI agentの中心的なアーキテクチャは推論ループです。このパターンを形式化したReAct論文にちなんで、ReActループとも呼ばれます。ループは四つの段階で構成されます。

1. 観測： agentはユーザーのメッセージに加え、会話履歴、システム指示、取得済みのコンテキスト（関連するナレッジベースの記事など）を受け取ります。

2. 推論： LLMは利用可能なコンテキストから、回答、確認質問、ツール呼び出しを選びます。状態グラフの固定された遷移とは異なり、実行時に選択します。その判断は誤る場合があり、評価が必要です。

3. 行動： モデルは、search_knowledge_base(query="return policy")やcreate_return_request(order_id=12345)などの構造化された呼び出しを提案します。実行前に、アプリケーションの制御と接続先APIが、許可された操作と範囲を強制する必要があります。呼び出しの提案は認可ではありません。

4. 評価： システムは結果を調べ、続行、回答、人による確認のための停止のいずれかを決めます。モデルが完了と判断しても、それは業務操作が成功したことの独立した証拠にはなりません。ループに上限を設け、必要に応じて外部の状態を検証します。

同じ返品のシナリオを、提案する制御フローとして記述できます。以下の呼び出しや結果は、実行も観測もしていません。 操作名は説明用であり、Quickchat AIのアカウントに貼り付けて使える設定ではありません。

顧客：「違う商品が届きました。返品手続きを始められますか」

[ポリシー] 適用される返品ポリシーを取得し、その条件を出典とともに示す。
[読み取り] 認証済みの顧客コンテキストと注文単位のアクセス権を必須にする。
           認可されたサービスを通じて該当する注文を照会する。
           「違う商品が届いた」は、検証されるまでは顧客からの申告として扱う。
[確認]     返品ポリシー、書き込み権限、必要な確認を検査する。
           条件が欠ける場合は、追加確認を求めるか人に引き継ぐ。
[書き込み] 独立した書き込み前の確認を通過してから、返品申請を送信する。
[検証]     外部の結果で確認できた場合にのみ、受理されたと報告する。
           申請の受理は、返金が支払われたことを意味しない。
           結果が不明なら状態を確認するか人に引き継ぐ。確認せずに再試行しない。
[引き継ぎ] 未解決の事実と、判明しているキューまたは宛先を記録する。
           人がすでに返信したと主張しない。

agentとしての特徴は、コンテキストから次の許可された手順を選ぶことにあります。サービスには依然として、定義されたツール、ポリシーのルール、本人確認、失敗時の処理が必要です。固定フローでも同じ操作を実行できます。アーキテクチャが変えるのは手順の制御であって、顧客の権限ではありません。

ツール利用と関数呼び出し

ツール利用（関数呼び出しとも呼ばれます）は、モデルを検索や外部操作につなぎます。LLMは、パラメーター名、型、説明を持つツールスキーマを受け取ります。利用可能な集合から呼び出しを提案できますが、許可するかどうかと、結果をどのように公開するかはアプリケーションが決めます。

顧客対応AI agentの一般的なツール分類には、次のようなものがあります。

スキーマが記述するのは呼び出しの形式であり、顧客を認証したり業務ポリシーを強制したりするものではありません。接続先でパラメーターとアクセス権を検証し、公開する項目を制限し、読み取りと状態変更操作を区別します。プロンプトの指示だけではセキュリティ境界になりません。

実際の操作を行うAI agentの構築のチュートリアルでは、会話中に呼び出すHTTPリクエストの定義を説明しています。続編の実行条件と保存結果によるActionsの順序制御では、Run only whenとSave to memoryを扱います。これらの制御は、顧客の本人確認や書き込みの冪等性を確立するものではありません。信頼できるメタデータと接続先での認可が引き続き必要です。リンク先にはそれぞれのデモの文脈があり、ここで示した仮の返品フローはテストされていません。

メモリとコンテキスト管理

スクリプト型のchatbotも、order_id=12345やintent=order_statusなどの入力済みスロットを、会話履歴やほかの状態とともに保存できます。agentの実装では、自由度の高い依頼に対応するため、複数種類のコンテキストを組み合わせることがよくあります。どちらのアーキテクチャも、自動的に安全なセッション間メモリを提供するわけではありません。

役立つコンテキストの層には、次のものがあります。

• 会話履歴： 現在のセッションのメッセージ列そのもの。
• 作業メモリ： 後続の判断に使う、ツール呼び出しや推論手順の中間結果。
• 取得したコンテキスト： 現在の質問に基づき、検索拡張生成（RAG）で取得したナレッジベース記事、製品ドキュメント、顧客記録。
• 長期メモリ（任意）： 希望言語、過去の問題、契約プランなど、セッションをまたいで保持するユーザーやアカウントに関する事実。

LLMのトークンウィンドウ内でコンテキストを管理することは、技術上の制約です。要約、スライディングウィンドウ、選択的な検索は量を減らせますが、重要な詳細を落とす場合があります。本人情報、権限、正式な取引状態は、モデルの要約に頼らず、信頼できるシステムに保持してください。

中間領域: LLM chatbotとcopilot

回答専用のLLM chatbotは、関連ナレッジを取得し、ユーザーのメッセージとともにモデルに渡して回答を返せます。この単純な設計には、モデルが操作手順を選ぶループはありません。一つの実装パターンであり、chatbotやcopilotと呼ばれるすべての製品の定義ではありません。

ポリシーに関する質問には、検索して回答するシステムで十分な場合があります。表現ごとに別のインテントを用意せず、多様な言い回しに対応できます。ただし、検索品質、対応言語、資料の品質は評価が必要です。

返品の例では、回答専用システムは公開ポリシーを説明しますが、非公開の注文データを取得したり、返品申請を作成したりしません。それらが必要なら、認証付きフローや適切に制限したツールを追加します。スクリプト型の連携でも実行できます。

LLMが依頼を分類し、決定論的なフローが必要な検査を強制し、モデルが回答を作成するといったハイブリッド設計も可能です。「chatbot」「copilot」「agent」という呼び名から特性を推測せず、どこで判断し、どの操作が許可され、どんな証拠が返るかを評価してください。

横並び比較

中央の列は、この記事で使う回答専用の例を表しています。RAG、永続的な状態保持、APIアクセスなどは、ほかのアーキテクチャとも組み合わせられます。

ルールベースのchatbotはまだ妥当ですか

はい。タスクの品質、制御、応答時間の要件を満たす最も単純なアーキテクチャを選んでください。安定したフォーム、少数の承認済み回答、決まった手順による認可済み照会には、スクリプト型フローで十分な場合があります。モデルを追加しても、連携とポリシーの保守は必要です。

次のような条件では、事前定義されたフローが適している場合があります。

承認済みの文言を使う必要がある回答。 テンプレートはレビュー済みの文章を保持できます。ただし、これは一つの制御であり、法令順守の証明ではありません。対象条件、開示、アクセス、レビューの義務は引き続き導入環境によって異なります。

単純で繰り返し可能な操作。 既知の手順なら、トラフィック量を問わず不要なモデル呼び出しを避けられます。普遍的な件数の境界を想定せず、実際のホスティング、ライセンス、API、保守コストを比較してください。

すでに動作する既存の連携。 信頼できるフローは維持し、評価で有用性を確認できた箇所に言語理解や特定のツールを追加します。LLMを使うために、すべてのインテントとフローを置き換える必要はありません。

必要な手順が変化し、モデルによる選択に価値がある場合は、agent型設計を評価する意味があります。代表的なタスクと失敗例でその価値を確かめてください。アーキテクチャの名前から、優位性の確率が自動的に決まるわけではありません。

AI agentが最も強い領域

依頼が多様で、実行時に次の手順を選ぶことが役立ちそうな場合は、モデルによる処理手順の制御を評価する価値があります。以下は用途の候補であり、測定済みの優位性を主張するものではありません。

複数システムにまたがるサポート依頼。 返品の例は、ポリシーの取得、認可された注文の読み取り、別途認可された申請を組み合わせます。モデルは次に必要な手順の選択を助ける可能性がありますが、固定フローも有効な選択肢です。

自由度の高い製品質問。 チーム人数、チャネルへのアクセス、プランの上限に関する質問には、複数の文書化された事実の組み合わせが必要な場合があります。検索は回答専用chatbotにもagentにも役立ちます。どちらも、製品説明から法令順守や文書にない利用権を推測してはいけません。

営業の会話。 モデルは明示された要件を集め、許可されたCRMコンテキストを取得できます。効果が高いと主張する前に、推奨の正確さ、同意、有用な結果を既存フローと比較してください。

多言語サポート。 言語モデルは言語ごとの回答作成を減らせる可能性がありますが、対応言語と品質は異なります。各対象言語で、用語、口調、ポリシーへの忠実さ、エスカレーションを評価します。多言語回答にagent型ループは必須ではなく、導入してもローカライズ作業はなくなりません。

エスカレーションの判断。 設定ルールとモデルの判断は、知識の不足や人との会話の要求を識別する助けになります。モデルの確信度や感情判定は、その判断が正しいことの信頼できる証拠ではありません。引き継ぎ依頼と人員対応の手順を、AIの返信とは別に検証してください。

プラットフォームの構成要素については、対話型AIプラットフォームガイドをご覧ください。

本番環境でAI agentがどのように動くか

本番システムは、モデルの動作とアプリケーションの制御を組み合わせます。同様の制御はスクリプト型フローにも使え、agent専用ではありません。

ガードレールと動作ルール。 指示は範囲、口調、エスカレーション動作を定義します。アプリケーションの検査は、許可する操作と停止条件を制限します。想定どおりの依頼だけでなく、拒否と失敗もテストしてください。プロンプトは、すべての回答がポリシーに従う保証ではありません。

ナレッジに基づく回答（RAG）。 検索は生成前に関連資料を渡し、裏付けのない回答を減らす助けになります。ただし、事実の正確さは保証しません。実装が実際に提供する追跡手段を使い、取得した資料と生成された主張を確認します。詳しくはAIハルシネーションとはをご覧ください。

ツールへのアクセスと操作権限。 APIやMCPサーバーは、読み取りと書き込みを公開できます。認証情報と許可する操作を制限し、接続先で顧客のアクセス権を強制し、返された文章はデータとして扱います。設定されたツールやモデルが提案したパラメーターは、他人の注文や未承認の返金に対する権限を与えません。

Quickchat AI Agentsは、Knowledge Baseに基づく回答と、設定したAPIおよびMCP Actionsに対応しています。API Actionsでは、モデルの外側で検査されるRun only when条件を使えます。信頼できるメタデータで実行を制限し、接続先APIの認可も維持してください。Human HandoffはAIの返信を一時停止し、会話をInboxに入れます。振り分けでチームメンバーが選ばれた場合は担当者付き、それ以外は未割り当てになります。割り当ては人からの即時返信を保証しません。上記の返品フローには、適切な外部サービスと設定が必要であり、標準機能で返品や返金が完了するという約束ではありません。

コストと性能のトレードオフ

chatbotとAI agentの選択は、アーキテクチャの判断であると同時に、採算の判断でもあります。

chatbotの経済性

スクリプト型フローはLLM推論を避けられますが、追加の処理にかかる費用が必ずゼロになるわけではありません。ホスティング、プラットフォームのライセンス、接続先API、監視、人による対応を含めます。単純な照会は、どちらのアーキテクチャでも安価な場合があります。実際の導入環境で測定してください。

保守には、フロー、テンプレート、連携、テスト範囲が含まれます。agent型システムには、プロンプト、検索、ツール、評価の作業もあります。どちらかの保守負担が小さいと決めつけず、同じタスク範囲と期間で両方を見積もります。

AI agentの経済性

モデル推論とツール実行はリソースを消費しますが、プラットフォームの請求は、クレジット、会話、解決、ユーザー枠、サブスクリプションに基づく場合があります。内部のトークンコストが、そのまま顧客の課金単位になるとは限りません。

現在の条件を直接比較してください。Quickchat AIの料金、Intercomの料金、Salesforce Agentforceの料金では、製品ごとの単位と条件が使われています。基本料金、最低契約額、含まれる利用枠、超過料金、課金対象成果の定義を確認します。会話と検証済みの解決は同じものではありません。AI agentの料金モデルガイドでは、広告の単価を同等とみなさず、対象範囲を比較する方法を説明しています。

自社の対象依頼コホートを使って、検証済み成果あたりのコストを見積もります。失敗した試行、再問い合わせ、人の手直し、継続支出、一時的な初期設定を含めてください。有人サポートの費用もチャネルや対象費用の範囲によって変わります。業界全体の大まかな数値は、自社環境に対応するベースラインではありません。空いたスタッフの時間は処理能力であり、実際の費用が減るか、予定していた支出を回避しない限り、現金の節約ではありません。

同じ期間での計算は、chatbotのROIを計算する方法をご覧ください。ここでは解決率の優位性や削減率を仮定していません。接続先サービスと引き継ぎを含め、最初の有用な応答までの時間と、検証済みの完了までの時間を測定します。どちらのアーキテクチャにも普遍的な応答時間の範囲はありません。

成功指標の違い

アーキテクチャを比較する際は共通の成果基準を用い、それぞれの失敗の種類に合わせた診断指標を加えます。

フローの診断指標には、認識されたインテント、フォールバックの理由、状態遷移、APIエラー、必要な手順の完了が含まれます。フローが完了しても、顧客の問題が解決したとは限りません。

成果指標には、対象依頼のうち検証済みの解決に至った割合、再問い合わせ、人の手直し、アンケートの回答数を併記した満足度、検証済み成果あたりのコストが含まれます。agentでは、裏付けのない主張、ツールの選択、アクセス拒否、書き込み結果が不明な状態も調べます。生成された回答、受理された返品申請、完了した返金を、同じ成果として数えてはいけません。

Chatbot Analyticsガイドは、製品内で観測できる情報と外部の証拠が必要な指標を区別し、合成データのワークシートを提供しています。比較前に分母と観測期間を定義してください。このワークシートはベンチマークではありません。

ポリシーの回答、認可された照会、外部の状態変更、引き継ぎを個別に監査できるだけの証拠を残します。取得した資料、ツールの応答、正式なシステム状態は、それぞれ異なる役割を持ちます。評価には合成データか適切に保護された記録を使い、共有する例で非公開の顧客データを公開しないでください。

FAQ

既存のchatbotをAI agentに変換できますか

有用なフロー、ナレッジ、連携を残しながら、言語理解や選択したツールを段階的に追加できる場合があります。モデルによるツール選択は、評価が必要なアーキテクチャの変更です。agentという名称を使うためだけに捨てず、認可、必要な承認、信頼できる決定論的な手順を維持してください。

AI agentはchatbotより高価ですか

一律の答えはありません。同じ対象タスクと期間で、サブスクリプション、課金単位、利用量、初期設定、保守、人の手直しを比較します。モデル呼び出しにはリソースコストが増えますが、販売時の課金方法は異なります。解決率の向上と現金の節約は測定する必要があり、空いた作業時間が自動的に金銭の節約になるわけではありません。

AI agentはハルシネーションを起こしますか

はい。検索は関連資料を渡せますが、正しい回答を保証しません。主張が資料から導けるか、ツール結果が述べられた成果を実際に確認しているかを調べます。回答専用LLM chatbotにも同じ厳密さを適用し、証拠が不足する場合は人に引き継ぎます。

AI agentはchatbotができないタスクを処理できますか

agentは、既存フローが対応していない多様な依頼に対し、有用な手順を選べる可能性があります。スクリプト型chatbotもAPIを呼び出し、状態を保持し、複数手順のタスクを完了できます。実際の能力は、インターフェースの呼び名ではなく、連携、権限、ポリシー、証拠によって決まります。返品申請には、引き続き独立した書き込み権限が必要です。

レイテンシはどうですか

遅い呼び出しや失敗した接続先呼び出しも含めた代表的なタスクで、最初の有用な応答までの時間と、検証済みの完了までの時間を測定します。中央値や95パーセンタイルなどの分布を、要件と照らして報告してください。モデルやツールの手順が増えると遅延が加わる場合がありますが、どちらの名前も普遍的な応答時間を定めたり、その遅延を許容可能にしたりするものではありません。

「AI agent」は「chatbot」のマーケティング上の言い換えにすぎませんか

呼び名には重なりがあります。chatbotは対話の接点を表し、agent型の制御は通常、モデルが実行時に手順やツールを選ぶことを意味します。実際のフロー、権限確認、停止条件、成果の証拠を調べてください。製品名だけでは、自律性、正確さ、事業価値が高いとは言えません。