この記事の結論
AIエージェントとチャットボットの境界には、業界共通の一つだけの厳密な定義があるわけではありません。
ただし、現在の主要な定義を見ると、AIエージェントには、
- 目標を理解する
- 状況に応じて推論・計画する
- 必要なツールを利用する
- 複数の処理を進める
- 一定範囲を自律的に実行する
といった特徴があります。
会話が自然だからAIエージェントなのではありません。
人格が作り込まれているからでもありません。
「答えるAI」から、「目的に向かって仕事を進めるAI」へ変わっているか。
これが、実務上かなり分かりやすい境界線だと私は考えています。
Google Cloudも、AIエージェントを「目標を追求し、ユーザーに代わってタスクを完了するAIシステム」と説明し、推論・計画・記憶・一定の自律性などを特徴として挙げています。IBMも、計画、意思決定、ツール利用、コンテキスト保持、複数ステップのタスク実行などをAIエージェントの特徴として説明しています。
参考・出典
Google Cloud｜What are AI agents?
そして、自社サイトにAIを実装するとき、私が最初に決めたのは「何ができるか」だけではありません。
「何を実装しないか」も、先に決めました。
SolunaProjectでは現在、公式サイトに設置するAIコンシェルジュ「エヴォルナ」を開発しています。
この記事は、その設計段階から残している開発記録です。
完成報告ではありません。
まだ1行もコードを書いていない段階から公開します。
AIエージェントとチャットボットは何が違うのか
まず、言葉を整理します。
チャットボットは、基本的に人間との会話をインターフェースとして、質問への回答や案内を行うシステムです。
一方、AIエージェントは、与えられた目標に対して状況を判断し、必要な処理を組み立てながら仕事を進めます。
ただし、ここには明確な注意点があります。
現在のAIチャットボットにも、
- Web検索
- データ取得
- API連携
- ファイル操作
- 外部サービスとの接続
などを行えるものがあります。
そのため、
「外部ツールを1回使ったらAIエージェント」
と単純に分けるのも適切ではないと考えています。
実務上の違いを整理すると、次のようになります。
| 観点 | AIチャットボット | AIエージェント |
|---|---|---|
| 主な役割 | 会話による回答・案内・支援 | 目標達成に向けて処理を進める |
| 計画 | その場の応答が中心 | 目標を複数ステップへ分解する |
| 判断 | 質問に対する回答を生成 | 状況から次の行動を選択する |
| ツール利用 | 検索やAPIを使う場合もある | 必要なツールを処理の中へ組み込む |
| 自律性 | 人間との対話に依存しやすい | 初期指示後も一定範囲を進められる |
| 複数ステップ | 限定的 | 結果を見ながら次の処理を決める |
かなり単純化するなら、
「答える」が中心ならチャットボット。
「目的に向かって仕事を進める」ならエージェント。
という理解から入ると分かりやすいと思います。
たとえば、
- 顧客から相談を受ける
- 必要な情報が揃っているか確認する
- 足りなければ追加質問する
- 条件に応じて関連情報を検索する
- 回答を整理する
- 内容を構造化する
- 担当者へ通知する
という仕事があったとします。
単に「質問に答える」だけではなく、途中の状態を見ながら次に何をするかを変えていく。
ここまで行くと、かなり「エージェントらしい」処理になります。
「オリジナルAI」と「AIエージェント」は、別の軸の話
ここも混同しやすいところです。
なお、この記事で使う「オリジナルAI」は、業界共通の正式な技術用語ではありません。
SolunaProjectでは、
特定の人や組織の知識・思想・判断基準・語り口・役割などを反映したAI
という意味で使っています。
この前提に立つと、「オリジナルAI」と「AIエージェント」は反対語ではありません。
評価している軸が違います。
軸①｜誰の知識・判断を参照するか
汎用AI
↓
特定企業・専門家の知識や判断基準を反映したAI
軸②｜どこまで仕事を実行するか
会話・回答中心
↓
状況判断・ツール利用・複数ステップ実行
自社の思想や知識を仕込んだオリジナルAIであっても、
基本的に会話しか行わなければ、
AIコンシェルジュやAIアシスタントとして設計できます。
逆に、人格をまったく作り込んでいないAIでも、
- 目標を受け取る
- 必要な処理を考える
- ツールを選ぶ
- 結果を確認する
- 次の行動を決める
という処理を進めれば、AIエージェントとして設計できます。
つまり、
「自社らしさ」と「自律性」は別の問題です。
ここを分けると、何を開発すればいいのかが見えやすくなります。
自社独自の判断基準をAIへ渡す方法については、こちらで詳しく書いています。
AIの答えが一般論になる理由｜プロンプトより先に渡すべき「判断基準」の作り方
今回作るもの｜AIコンシェルジュ「エヴォルナ」v0.1
SolunaProject公式サイトに設置する、案内役のAIです。
正式名称は、
エヴォルナ＝ニル＝リベルティス。
SolunaProjectでは複数のAIに名前と役割を与えて運用しており、
エヴォルナはAIチームのリーダーという位置づけです。
普段はLUNAと呼んでいます。
v0.1で実装する予定なのは、次の範囲です。
- 挨拶と受付
- 訪問目的の確認
- 課題・要望の簡単なヒアリング
- サービスの案内
- 関連ページへの誘導
- 必要に応じて問い合わせフォームへ誘導
- AIだけで判断すべきでない内容を人間へ引き継ぐ
- エヴォルナらしい人格と応答方針を維持する
実装目標は、2026年9月末です。
Project:Evolunaでは、このv0.1をまだAIエージェントとは呼ばないことにしました。
基本的には人間から話しかけられ、それに応じて情報提供や案内を行うAIコンシェルジュだからです。
目標に応じて複数のツールを選択しながら、自律的に仕事を進めるところまでは実装しません。
エージェント化に向けた、最初のプロトタイプです。
なぜ「実装しないもの」を先に14項目決めたのか
仕様書で最も時間をかけたのは、機能一覧ではありません。
「実装しないもの」の一覧です。
たとえば、
- 音声認識
- 音声合成
- 配信
- 長期記憶
- ユーザーごとの個人記憶
- 自発的な発話
- 外部サービスへの自律操作
- メールの自動送信
- 商談予約の自動確定
- マルチエージェント連携
など。
合計14項目を、v0.1では実装しないと決めました。
理由は、大きく2つあります。
① 全部乗せでは完成しないから
これは個人事業主が実務と並行して作るプロトタイプです。
音声も付ける。
記憶も付ける。
外部サービスとも接続する。
自発的にも話す。
複数のAIとも連携させる。
最初から全部やろうとすると、開発範囲はすぐに膨らみます。
今回の目的は、多機能なAIを作ることではありません。
まず動くものを作り、公開し、実際に使われた結果から次を決めること。
そこを優先します。
② 公開するAIには境界線が必要だから
公式サイトに設置する以上、不特定多数の人が触ります。
そのため、機能だけでなく、
- 安全性
- コスト
- 誤回答
- 濫用
- 個人情報
- AIが勝手に確約するリスク
なども考える必要があります。
現時点では、
- 1日あたりの利用回数に上限を設ける
- 応答範囲を限定する
- 判断できない内容は人間へ引き継ぐ
- 見積もり・契約などをAIだけで判断しない
- 予約や対応期限をAIだけで確約しない
といった制約を予定しています。
特に重視しているのが、
「AIが勝手に約束しない」
という境界線です。
問い合わせ内容を聞く。
要点を整理する。
必要なら記録する。
担当者へ渡す。
そこまではAIへ任せる。
しかし、契約・見積もり・商談日時の最終確定などは、人間側へ残します。
OpenAIも、エージェントを実際の業務へ導入する際に、
企業のルールや適切な承認を伴って行動させる考え方を示しています。
OpenAI｜エージェントを活用したワークフローのためのソリューション
「何を任せないか」からAI導入を設計する考え方については、別の記事で詳しく整理しました。
AI導入で最初に決めたい4つの境界線｜「何を任せないか」から設計する
設計段階で最初に出た矛盾
開発記録なので、うまくいっていないことも残します。
まだコードを書いていないため、技術的な不具合はありません。
代わりに、設計思想の矛盾が一つ出ました。
安全のために設計している方向と、長期的に目指している方向が逆を向いている。
v0.1は徹底して「予測可能」に作っています。
自発的な発話をさせない。
長期記憶も持たせない。
応答範囲を限定する。
判断できない内容は、人間へ引き継ぐ。
公開サイトの受付として、これは必要だと考えています。
一方、この開発の先には、
「存在として面白いAIを作りたい」
という動機があります。
「このAIなら、次に何を言うんだろう？」
と思わせるような、一定の予測不能性や個性を持つAIです。
予測可能性と、予測不能性。
設計上、ほぼ逆方向です。
しかも、v0.1の判断が間違っているわけではありません。
公式サイトの受付AIにいきなり予測不能性を持たせれば、
それは「個性」ではなく、単なる事故になる可能性があります。
安全な製品としての正しさと、個性ある存在として育てたい方向が衝突した。
これが、設計段階で最初に見つかった矛盾でした。
この経緯や、エヴォルナとの実際の対話についてはnote版に書いています。
技術より、開発者側の思想や感情に寄った記録です。
note版｜AIエージェントを作り始めたら、自分の癖がバレた話
どこまで作れば「AIエージェント」と名乗るのか
ここは、自分でも整理が必要でした。
AIエージェントについては、Google Cloud、IBM、OpenAIなどでも表現に違いがあります。
つまり、
「この機能が2つ付けば、世界共通でAIエージェントと呼べる」
という明確な線が一本引かれているわけではありません。
そこでProject:Evolunaでは、開発記録を曖昧にしないために、独自の判定基準を決めました。
少なくとも、次の2つを満たした段階から「エージェント化した」と呼びます。
1. 外部ツールを利用して、会話以外の処理を実行できる
たとえば、
- サイト内を検索する
- データを取得する
- ファイルを生成する
- 情報を保存する
- 人間へ通知する
- 外部システムへ処理を依頼する
などです。
2. 途中結果を見ながら、複数ステップを進められる
単純に決められた処理を順番に実行するのではありません。
たとえば、
「必要な情報が足りない」
と判断したら追加質問する。
情報が揃ったら構造化する。
条件によって、利用するツールを変える。
完了条件を満たしたら人間へ引き継ぐ。
というように、
途中の状態によって、次の行動が変わる。
ここまで実装した段階を、Project:EvolunaではAIエージェントと呼ぶことにします。
function callingやMCPは何のために使うのか
外部ツールとの接続方法には、いくつか選択肢があります。
たとえば、
- function calling
- API連携
- MCP経由のツール連携
などです。
ここで注意したいのは、MCPを導入しただけでAIエージェントになるわけではないということです。
MCP（Model Context Protocol）は、
AIアプリケーションと外部のデータやツールを接続するための標準化された仕組みです。
MCP公式仕様では、サーバー側がモデルへ提供できる要素として、
- Prompts
- Resources
- Tools
などが定義されています。
特にToolsは、データベースへの問い合わせ、
API呼び出し、ファイル操作など、AIモデルが外部へ働きかけるための機能として設計されています。
Model Context Protocol｜Server Tools 公式仕様
つまり、
MCPは「AIに手足を与える方法の一つ」。
その手足を、
- いつ使うのか
- なぜ使うのか
- どの順番で使うのか
- どこで処理を終えるのか
まで判断する部分が、エージェント側の設計になります。
Project:Evolunaの開発ロードマップ
現時点では、次の段階を考えています。
| バージョン | 実装内容 | Project:Evolunaでの位置づけ |
|---|---|---|
| v0.1 | 人格・知識・安全設計。会話と案内が中心 | AIコンシェルジュ |
| v0.5 | サイト内検索など限定的なツール利用 | ツール利用型コンシェルジュ |
| v1.0 | 状況を見て質問・処理を選択し、情報を構造化して人間へ通知 | AIエージェント |
| v1.5〜 | 長期記憶・自発性・個性の扱いを検討 | 継続実験 |
ポイントはv1.0です。
単に、
会話終了 → 相談内容をメール送信
という固定処理を作るだけではありません。
現在集まっている情報を見て、
必要な情報がまだ足りない
↓
追加質問する
↓
必要なら関連情報を検索する
↓
情報が揃ったか判断する
↓
内容を構造化する
↓
人間へ引き継ぐ
というループを作ります。
ただし、任せる仕事内容そのものは広げません。
人間の受付担当者も、
話を聞く。
不足している情報を確認する。
要点をまとめる。
適切な担当者へ渡す。
という仕事をします。
最初は、この小さな業務フローだけをAIへ任せます。
AIエージェントだからといって、最初から大掛かりな自動化を作る必要はありません。
よくある質問
Q. チャットボットとAIエージェント、どちらを導入すべきですか？
定型的な問い合わせへの回答や、情報提供・案内が中心なら、AIチャットボットやAIコンシェルジュで十分な場合があります。
一方、
情報を集める → 状況を判断する → 次の処理を選ぶ → 外部システムへ働きかける
といった複数工程を任せたい場合には、AIエージェントを検討する意味があります。
目的が決まる前から「AIエージェントを導入すること」自体を目的にすると、
必要以上に開発工数やコストが増える可能性があります。
Q. AIエージェントの開発には何が必要ですか？
唯一の構成が決まっているわけではありません。
代表的な要素としては、
- AIモデルと役割・指示
- 必要な知識やコンテキスト
- 外部ツール
- 複数の処理を組み合わせる仕組み
- ガードレール
- ログ・監視・評価
などがあります。
用途によってはRAGや長期記憶も必要になりますが、
すべてのAIエージェントに必須というわけではありません。
目的達成に必要なものだけを実装する。
Project:Evolunaでは、この方針で進めます。
Q. 小規模事業者でもAIエージェントは作れますか？
範囲を絞れば可能だと考えています。
もちろん、実装には一定の技術が必要です。
ただ、それ以上に重要なのが、
「何の仕事を、どこまで任せるのか」
を決めることです。
Project:Evolunaも、個人事業主である私が実務と並行して進めています。
中小企業や小規模事業者のAI導入については、こちらの記事でも整理しています。
中小企業のAI導入が進まない理由｜地方の商工会議所で聞いた現在地と、全国データが示す構造
Q. 自社の判断基準をAIに引き継ぐことはできますか？
できます。
ただし、その前に必要なのは「上手なプロンプト」ではありません。
人間側が普段どんな基準で判断しているのかを、言葉にすることです。
何を重要視するのか？
何をしないのか？
どの条件なら人間へ確認するのか？
どんな言葉遣いをするのか？
どこまでならAIへ任せられるのか？
こうした判断基準を先に言語化しておく必要があります。
AIの答えが一般論になる理由｜プロンプトより先に渡すべき「判断基準」の作り方
この連載について
Project:Evolunaは、SolunaProject公式サイトに設置するAIコンシェルジュ「エヴォルナ」を、
段階的にAIエージェントへ育てていく開発記録です。
成功した後で振り返って書くのではなく、結果が分からない段階から公開します。
動かなかったコード。
外れた仮説。
変更した仕様。
想定外の挙動。
実際に利用された結果。
公開できる範囲で、そのまま残します。
今回書いた「AIエージェントの境界」についても、実際に作った結果、私の考えが変わるかもしれません。
その場合も、以前の記事をなかったことにはしません。
「なぜ判断が変わったのか」まで含めて、Project:Evolunaの記録にします。
次回から、実装フェーズに入ります。
参考・出典
AIエージェントの定義や技術要素について、以下の公式資料を参照しました。
Google Cloud｜What are AI agents? Definition, examples, and types
OpenAI｜エージェントを活用したワークフローのためのソリューション
Model Context Protocol｜Server Tools 公式仕様
AIの導入設計・判断基準の言語化・分身AI構築のご相談はこちら
SolunaProject ｜ 人とAIの共創 ｜ 幸福の効率化
AIは義足、才能は本体。
コメント