101社の企業を調査した結果、大半が「AIエージェント」と呼んでいるシステムの実態はチャットボットのラッパーだった。この事実は、開発チームの計画立案や技術的負債の扱いを考えるうえで、見過ごしにくい問いを投げかけています。
「エージェント」という言葉が先走っている
AIエージェントとは、目標を与えられると自律的に計画を立て、ツールを呼び出しながら複数のステップを実行するシステムを指します。単に質問に答えるチャットボットとは根本的に異なります。チャットボットは「1ターンの入出力」で完結しますが、エージェントは「多段階のアクション連鎖」で目標を達成しようとします。
VentureBeatが調査した101社のうち、多くが社内で「エージェント」と呼んでいるシステムは、実際にはチャットボットにAPIを数本つないだ程度のものでした。プロダクトオーナーがバックログに「AIエージェント導入」と書いた瞬間から、チームはエージェントらしい自律動作を期待されます。しかし実装されるのはLLM（大規模言語モデル）に問い合わせるだけのラッパーであり、ギャップが生まれます。
このギャップはスプリント計画に直接影響します。「多段階の実行が安定して動くか」という検証コストを見積もりに含めないまま開発が進み、後から品質問題として浮上するパターンがあります。
オーケストレーション基盤の選択がチームの運用を左右する
エージェントオーケストレーションとは、複数のエージェントやツール呼び出しを調整・管理するコントロール層を指します。LangChainやLlamaIndex、CrewAIといったフレームワークがこの役割を担います。しかし調査結果では、企業の選択はモデルプロバイダーのプラットフォーム、なかでもAnthropicのClaudeに集中しつつあります。
その理由として挙げられるのが「モデルの重力」という概念です。モデルの精度や信頼性が高いほど、そのプロバイダーのオーケストレーション機能をそのまま使うインセンティブが生まれます。結果として、チームはフレームワーク選定の自由度を一部手放す代わりに、多段階実行の安定性を得ようとします。
開発チームの観点で問題になるのはベンダーロックイン（特定のサービスへの依存状態）のリスクです。調査対象企業のコントロールプレーンはハイブリッド構成、つまり複数のプロバイダーを組み合わせる形が意図的に選ばれています。一つのプロバイダーに全面依存することを避けるためです。アーキテクチャの選択がチームの長期的な運用コストに直結するため、初期の設計判断がのちの技術的負債の規模を決めることになります。
トークン消費のコスト制御が運用の盲点になりやすい
トークンとは、LLMがテキストを処理する際の課金単位です。1トークンはおおむね英単語1つ分に相当します。エージェントが多段階で動くと、1回のユーザーリクエストに対して数百から数千トークンが消費されることもあります。
調査では、リアルタイムでトークン消費をコスト管理できている企業は例外的な存在にとどまっています。多くのチームはスプリント単位の開発コストは把握していても、本番稼働後のトークン燃焼コストを継続的に監視する仕組みを持っていません。
この問題はアジャイル運用における「完了の定義（Definition of Done）」と関係します。機能が動くことだけをDoneの基準にすると、コスト効率の観点が抜け落ちます。トークン消費量の上限値やコストアラートをCI/CDパイプライン（継続的インテグレーション・デリバリーの自動化ライン）に組み込むことで、開発サイクルの中でコスト感覚を維持しやすくなります。
- 見積もりには「多段階実行の検証コスト」を明示的に含める
- 「エージェント」と「チャットボット」の定義をチーム内で合わせてからバックログに書く
- ベンダー依存を避けるため、オーケストレーション層の抽象化を初期設計で検討する
- Definition of Doneにトークンコストの監視基準を含める
「チャットボットをエージェントと呼ぶ」問題の本質は、命名の混乱だけではありません。期待値と実装の乖離がスプリントごとに積み重なると、技術的負債として残ります。プラットフォーム選定の議論より先に、チームが「何をもってエージェントと呼ぶか」を定義する作業が、実は最初の設計判断です。その定義が見積もり精度と運用コストの両方を決めます。