インターネットは、今年を「エージェントの年」と決めたようだ。LangGraph、CrewAI、AutoGenといった名前が、あらゆるエンジニアリングのロードマップに並んでいる。チームはオーケストレーション層の負荷テストを行い、ステートマシンかロールプレイかを議論し、どのライブラリが最終的に大規模言語モデルを自律化させるのかを模索している。

ここで不都合な真実を言っておこう。それらの比較のほとんどは時期尚早だ。フレームワークが難しいのではない。難しいのは、私たちが言葉の定義を止めてしまったことだ。今や人々は何でも「エージェント」と呼んでいる。ツールコールはエージェントではない。チャットボットもエージェントではない。その杜撰な定義が、質の低いエンジニアリング、過剰に構築されたシステム、そして単純なスクリプトで回避できたはずの本番環境の障害へと直結しているのだ。

フレームワークを選ぶ前に、自分が実際に何を作ろうとしているのかを定義せよ。

エージェントの真の定義

エージェントは、実行されるモデルやAPIコールの回数によって定義されるのではない。エージェントは、その「振る舞い」によって定義される。明確な目的を持たなければならない。人間が事前に経路をマッピングすることなく、次にどのステップを踏むべきかを決定できなければならない。そのステップが失敗したときに、失敗に対処できなければならない。そして、いつ停止すべきかを知っていなければならない。

受信したメールを読み、返金リクエストとして分類し、注文番号を抽出し、配送データベースに問い合わせ、返品ポリシーの期間を確認し、返信案を作成して、チケットを解決済みとしてマークするサポートシステムを考えてみてほしい。データベースがタイムアウトしたら、待機してリトライする。ポリシーの期間が曖昧であれば、人間にフラグを立てる。返信が送信されたら、停止する。これがエージェントだ。JSONを返すだけの単一のLLMコールのラッパーは、マーケティングチームがどれほど「エージェント」というステッカーを貼ろうとも、エージェントではない。

この区別が重要なのは、複雑さにはコストが伴うからだ。自律性を必要としないシステムが、そのための代償を払う必要はない。

本番環境におけるAIの真の姿

現在、本番環境で稼働しているAIシステムのほとんどは、特化型（narrow）だ。それらは一つのことをうまくこなす。サポートチケットをキューに振り分け、スキャンされたドキュメントから有効期限を抽出し、顧客のクエリを既存のナレッジベースの記事と照合する。それらは汎用的な推論エンジンではなく、そう思い込むことは最悪のオーバーエンジニアリングにつながる。

また、それはモデルのリリースに対する破壊的な執着も生む。チームは、あたかも最新の基盤モデルが杜撰なアーキテクチャを補ってくれるかのように、新しいモデルを追い求める。しかし、そうはならない。エラーハンドリングのない脆弱なループ内で動作する、より高性能なモデルは、単に「より高い自信を持って、より独創的なハルシネーションを起こす」だけだ。ベンチマークを追うのはやめよう。構造を追うのだ。

フレームワークは製品ではない

LangGraphは、明示的なステートマシンとサイクルを提供する。CrewAIは、エージェントがペルソナを採用するロールベースのオーケストレーションに重点を置いている。AutoGenは、問題を解決するために互いに会話する対話型エージェントを中心としている。これらはすべて有能なツールだ。同時に、制御フローに対する根本的に異なるアプローチでもある。

しかし、どのフレームワークを選ぶかよりも、その中でどのようなパターンを強制するかが重要だ。境界線を尊重することで、PythonとRedisだけで堅牢な自動化を実現しているチームを私は見てきた。一方で、フレームワークを設計の代わりとして扱ったために、凝ったオーケストレーションの重みに耐えきれず崩壊していくチームも見てきた。

もし、ハンドオフが曖昧で、ツールが脆弱で、リトライロジックが存在しないのであれば、requirements.txtに書かれたロゴがあなたを救ってくれることはない。

本当に時間を割くべき3つのこと

エージェント的なシステムを構築しているなら、以下の3つの領域に力を注いでほしい。

ツール設計（Tool design）。 エージェントが呼び出すことができるすべての関数は、インターフェースで包まれた「負債」である。それらを厳密に設計せよ。入力を積極的に検証せよ。500エラーのダンプではなく、実際に読み取り可能なエラーを返せ。優れたツールとは、何かがうまくいかなかったときに、エージェントがそれについて推論できるものである。

失敗への対処（Failure handling）。 すべてのLLM...