すべてのプロダクトロードマップには、「AIエージェント」という項目が含まれています。その言葉は進歩を予感させます。チームが単に現状を維持しているのではなく、未来を築いているのだとリーダーシップ層にアピールできるからです。しかし、ほとんどのデモ動画が隠している不都合な真実があります。それは、エージェントとは仕事を完遂するための手段として、最もコストがかかり、最も予測不可能な方法であるということです。大半のビジネス業務において、それは全く不適切なツールです。優れたエンジニアとは、急いでエージェントを構築しようとする人ではありません。いつ構築を止めるべきかを知っている人なのです。

分類の罠

チームが最初のエージェントの要件を定義する様子を見ると、大抵次のようなものになります。サポートメールが届きます。大規模言語モデル（LLM）が件名と本文を読み、それが請求に関する質問か技術的なバグかを判断し、適切なキューに振り分けます。チームはこれを「エージェント」と呼びます。しかし、そうではありません。

彼らが構築したのは、単一のモデル呼び出しを含む決定論的なフローです。ステップは固定されています：メールの取り込み、モデルの呼び出し、キューへのルーティング。ループも、ツールの使用も、最初の試行が失敗したためにシステムが立ち止まって計画を再考する瞬間もありません。実行の途中でナレッジベースを検索したり、コードを書いたり、注文状況を確認したりすることはありません。一度判断を下したら、そのまま次に進むのです。その単一の呼び出しをマイクロサービスで包んだとしても、それはエージェントにはなりません。

フローをエージェントと誤認することの真のコストは、単なる追加のインフラではありません。それは、何の利益も得られないまま招き入れてしまった「非決定性」です。Temperature（温度パラメータ）がゼロでない、あるいはプロンプトがドリフトしているために、火曜日の午前中と水曜日の午後では、同じメールが異なるルートに振り分けられる可能性があります。分類ステップが一つあるだけのフローなら、より速く、より安価に問題を解決できるのに、あなたはレイテンシ、トークンコスト、評価のオーバーヘッドに対して「エージェント級」のコストを支払うことになるのです。

梯子を下るように考える

ほとんどの問題には、同じようにうまく解決できる、よりシンプルな代替案があります。これを梯子だと考え、下から始めてください。

プロセスを修正する。 時として、業務が存在するのは単に2つのシステム間で不一致があるからに過ぎません。CRMの顧客レコードがチケット管理プラットフォームと同期していないため、毎朝人間が手動でそのギャップを埋めなければならない、といったケースです。その「橋渡し」をエージェントで自動化してはいけません。そのギャップ自体を排除してください。データパイプラインが健全であれば、その業務は消滅します。

クエリを使用する。 回答が単純な検索や集計であるなら、そのように扱いましょう。「先週の火曜日に処理した返金は何件ですか？」という問いに推論は不要です。必要なのはSQLです。自然言語をSQLに変換するエージェントは、一見エレガントに聞こえますが、そのメンテナンス負荷が、チームがダッシュボードから実行する3つのドキュメント化されたクエリを書く手間を上回ってしまうことに気づくでしょう。

決定論的なフローを構築する。 ルールが固定されており、結果が再現可能である場合は、明示的なロジックを使用してください。注文額がしきい値を超えたら財務部門にエスカレーションする、ユーザーが30日間アクティブでなければ再エンゲージメントメールを送信する、といった具合です。コードであれば、ばらつきゼロで、完全な観測可能性を持ってこれを処理できます。ユニットテストも可能です。「雰囲気（vibe）」をユニットテストすることはできません。

単一のモデル呼び出しを含むフローを使用する。 これは、分類、感情タグ付け、データ抽出などが行われる領域です。モデルは厳格なスクリプトの中で一度だけ判断を下します。ドキュメントを取り込み、請求書番号を抽出し、データベースに書き込む。周囲のステップはハードコードされています。モデルは次に何をすべきかを選択するのではなく、見ているものにラベルを貼るだけです。これは強力なパターンですが、依然として「フロー」です。

エージェントの構築は最後にする。 このステップは、実行の途中でモデルが発見した内容によって、次のアクションが真に依存する場合のタスクのために取っておいてください。システムがメールを読み、物流APIで出荷状況を確認する必要があると判断し、出荷が遅延していることを発見し、その最新データに基づいてカスタムの返信案を作成しなければならない、というような場合は、エージェントの領域です。新しい事実が得られるたびにモデルが行動を決定するため、経路を事前に描くことはできません。

ホワイトボード・テスト

会議での議論を迅速に決着させる方法があります。チームに、ホワイトボードに意思決定の分岐図を描いてもらうのです。

モデルを実行する前にすべての経路をマッピングできるなら、フローを構築してください。ひし形の分岐図を描き、if文を書き、それで完了です。予測可能性は制限ではなく、機能（フィーチャー）なのです。

もしモデル自身が、次のステップが何であるかさえ決定しなければならない場合、つまりモデルがツールを選択し、パラメータを設定し、再考するためにループする場合、その時に初めてエージェントが必要になります。その「動的なルーティング」こそが境界線です。新しいAPIを使いたいという理由だけで、うっかりその線を越えてはいけません。

隠れた税金

デモでは、エージェントは摩擦のないスムーズなものに見えます。しかし、本番環境では、急速に累積していく4つの「税金」が明らかになります。

非決定性。 同じ