AgentGPT が運用現場で失敗する理由 — そして代わりに機能するもの

Reworkd が AgentGPT のリポジトリをアーカイブし、それとともに制約のない自律エージェントという幻想も消えた。1 日に 10 万件の顧客対応を実行すれば、オープンエンドなループはもはや賢いものではなくなる — 負債になる。本番環境での実行には、厳格な状態境界と決定論的なフォールバック経路が必要だ。実験的なタスク実行から状態を境界づけたアーキテクチャへの移行は、B2B の運用責任者にとってもはや好みの問題ではない。参加するための最低条件である。

自律エージェントのループが本番環境で破綻した理由

AgentGPT のアーカイブは事後検証として読むべきだ。構造化されていないエージェント — 自らサブタスクを考案するもの — を稼働中のエンタープライズデータベースに向ければ、筋道を見失う。予期しなかったスキーマ変更が 1 つ。処理できなかった null が 1 つ。エージェントは再帰的な修正ループを起動しはじめ、API エラーを LLM クエリの連打で直そうとする。

本番環境では、こうしたループはコストと運用という 2 つの軸で破壊的だ。基幹バンキングデータベースに接続された音声エージェントを想像してほしい。REST エンドポイントが、エージェントが JSON を期待していたところに 502 Bad Gateway を返す。オープンエンドなエージェントは、パラメータを少しずつ変えながら同じエンドポイントを叩き続けることで、それを「診断」しようとする。3 分もあれば、たった 1 回の実行が数百件の再帰的な LLM 呼び出しを発生させ、最大 $400 の OpenAI クレジットを消費し、組織全体のレート制限を食いつぶす。

[Client Call] -> [Voice Agent] -> [API Gateway (502 Gateway Error)]
                                      |
        +-----------------------------+
        | (Recursive Loop Started)
        v
[Agent attempts to self-correct]
        |-> Retry 1 with modified schema ($0.80 tokens)
        |-> Retry 2 with unstructured prompt repair ($1.50 tokens)
        |-> Retry 120 with recursive code generation ($400.00 exhausted)

スキーマ検証なしに自ら次のステップを選ぶシステムを本番投入する運用責任者はいない。債権回収やオンボーディングを実行するアウトバウンドエージェントに自分で API ペイロードを書かせれば、いずれ Salesforce や Freshdesk にゴミデータを書き込む。厳格な入出力検証を省けば、記録システムはもはや信頼できるものではなくなる。

音声では、同じ失敗がレイテンシとして現れる。エージェントが通話中に STT の聞き取り誤りを自己修正しようとすると — たとえばインドの地域なまりで読み上げられた郵便番号を聞き間違えた場合 — 制約のないモデルは内部の推論サイクルを回して 4〜8 秒停止する。エンタープライズ運用において 1.2 秒を超えるレイテンシは、顧客の即時離脱を意味する。

アーキテクチャの転換: オープンエンドなループからステートマシン実行へ

本番環境の AI エージェントをスケールさせるとは、オープンエンドなループを捨て、決定論的な有限ステートマシン (FSM) へ移行することだ。LLM が会話やワークフローの次の状態を決めることは決してない。LLM の仕事は 1 つ — ユーザー入力を読み、パラメータを抽出し、あらかじめ定義された遷移にマッピングすること。運転手ではなく、認知プロセッサだ。

エージェントはマッピングされていない状態には到達できない。予期しない回答が与えられた場合、ステートマシンは決定論的なフォールバックを強制する — 人間へのハンドオフ、または当該の質問の再確認 — モデルにまったく新しいフローを幻覚させるのではなく。

これを Pydantic の厳格な入出力スキーマで強制している。LLM の出力は、ネットワーク呼び出しが 1 件でも発生する前に、下流の RESTful API が期待する正確な構造と一致しなければならない。

from pydantic import BaseModel, Field, field_validator
import re

class CustomerVerification(BaseModel):
    account_number: str = Field(..., description="The 10-digit customer account number")
    verification_pin: int = Field(..., description="The 4-digit security PIN")

    @field_validator('account_number')
    @classmethod
    def validate_account_format(cls, value: str) -> str:
        if not re.match(r'^\d{10}$', value):
            raise ValueError("Account number must be exactly 10 digits")
        return value

スキーマ検証に失敗したものはすべてローカルで捕捉される。そこからシステムはローカルの再試行プロンプトを実行するか、安全な遷移へ落とす — 不正なデータを基幹トランザクションデータベースへ送り込むことは決してない。

また、これらのポリシーを本番投入前にテストするため、OpenAI Gym の環境パターンも取り入れている。ステートマシンに対して数千件のシミュレートされた敵対的な会話を実行すれば、エージェントが破綻する境界条件を正確に特定できる — 最初の実際の通話が転送される前に、99.9% 予測可能な実行経路が得られる。

フレームワークの比較: 構造化タスクにおける Voiceflow と AgentGPT

agentgpt の代替を探せば、最終的に Voiceflow のようなビジュアルフロービルダーと自律型のゴール探索エージェントを比較することになる。分かれ目は、誰が対話状態を所有するかだ。Voiceflow は決定論的なノードベースの対話マネージャーを実行する — すべての遷移を開発者がマッピングする。AgentGPT はそれを LLM に委ね、LLM は高レベルの目標から独自のタスクリストを立ち上げる。

ビジュアルビルダーは直線的なビジネスロジックを得意とします。しかし、ユーザーがターンの途中でコンテキストを切り替えた瞬間に破綻します。顧客が「待って、その前に、今の私の金利はいくら？」と割り込んでくると、硬直的なVoiceflowのダイアグラムは壊れるか、ユーザーを元の流れに引き戻すかのどちらかです。いずれにせよ、その体験はもう死んでいます。

私たちの解決策はハイブリッドです。メインの通話フローは決定論的なステートマシンの下に置いたまま、煩雑なサブタスクは専用の単一目的LLMマイクロエージェントにルーティングします。会話は自然に流れ、実行は制御された範囲に収まります。

ベンチマークもこれを裏付けています。このハイブリッド構成は、完全に自律的な構成と比べてレイテンシを最大70%削減します。マイクロエージェントは狭い意味的境界の内側で動作するため、トークン消費量は4分の1になり、高スループット環境での状態復旧率は99.4%に達します。

Blackboardパターン：無限ループを起こさずにマルチエージェントシステムをオーケストレーションする

複雑なエンタープライズ業務——たとえば複数保険会社にまたがる保険金請求——では、無限ループに陥ることなく複数の専門エージェントが協調する必要があります。Blackboardパターンは、トランザクション全体の単一の信頼できる情報源として機能する、中央集約型の読み書きストア1つで、この協調を処理します。

エージェント間の直接のやり取りは避けてください——その経路は障害点を指数関数的に増やします。代わりに、各エージェントはBlackboardから状態を読み取り、自分の1つのタスクを実行し、構造化された更新内容を書き戻して、そのサイクルを終了します。

[Central Blackboard Database]
   ^                      ^
   | (Reads/Writes)       | (Reads/Writes)
   v                      v
[Voice Intake Agent]    [Validation Agent]

Salesforceや FreshdeskのようなCRM上で、複数のエージェントが同じ顧客レコードに手を伸ばすと、競合が発生します。私たちは楽観的並行性制御でこれを防いでいます。Blackboardへのすべての書き込みにはバージョントークンの一致が必要となるため、更新は順序どおりに、かつ透明性を保って処理されます。

{
  "transaction_id": "tx_908124",
  "version": 4,
  "blackboard_state": {
    "account_id": "ACC-7712",
    "billing_dispute_status": "pending_validation",
    "disputed_amount": 1450.00,
    "voice_transcript_summary": "Customer disputes late fee from March invoice."
  },
  "active_lock": "agent_billing_validation_02"
} 

音声エージェントが請求に関する異議申し立ての通話を終え、構造化された要約と係争金額をBlackboardに書き込みます。その書き込みが非同期のバックグラウンド検証エージェントを起動します。検証エージェントは取引履歴を確認し、ステータスを「承認済み」または「エスカレーション済み」に切り替え、結果を書き戻します。それが最終的な自動アウトバウンド通知のトリガーとなります。この間、エージェントが別のエージェントを直接呼び出すことは一度もありません。

本番環境のAIエージェントを構築する：5ステップのデプロイメント設計図

大量処理を担うエンタープライズ向け音声エージェントは、偶然にはできあがりません。以下は、実運用に耐えるエージェントを構築・テスト・運用するために私たちが使っている5ステップの設計図です。

ステップ1：ハイパーメディアクライアントとRESTful APIの境界を定義する

プロンプトを1行でも書く前に、ツールアクセスのスキーマ境界を引いてください。エージェントがデータベースに直接触れることは決してなく、厳格に型付けされたRESTエンドポイントを公開するハイパーメディアクライアントを経由します。これにより、バックエンドはLLMの推論エンジンから疎結合のまま保たれます。

ステップ2：カスタムのOpenAI Gym環境を書く

エージェントに負荷をかけるためのGymシミュレーションを構築します。突然の電話切断、エージェントにかぶせて怒鳴る発信者、無効な英数字データといった敵対的な挙動をステートマシンに投げつけ、負荷のかかった状態でもステートマシンが正常に回復することを確認します。

ステップ3：STIR/SHAKENのアテステーションレベルBを実装する

米国向けのアウトバウンドトラフィックを運用していますか？その場合、SIPトランキングのプロバイダーがSTIR/SHAKENのアテステーションレベルB以上に対応している必要があります。発信者番号を暗号的に署名することで、エージェントは米国のキャリアのスパムリストに載らずに済み、応答率を45%以上に保てます。

ステップ4：Twilio Media Streams上でセマンティックドリフトとレイテンシを監視する

生の音声をリアルタイムで監視してください。Twilio Media Streamsを低レイテンシの文字起こしにつなげば、ユーザーが話し終えてからエージェントが話し始めるまでの正確な間隔を計測できます。セマンティックドリフトを追跡し、分類モデルの範囲外に逸れていくクエリを捉えましょう。

ステップ5：ヒューマン・イン・ザ・ループのトリガーを設定する

引き継ぎの明確なしきい値を設定してください。エージェントが有効なパラメータ——たとえば証券番号——を2回試しても取得できない場合、または感情スコアが設定した下限を下回った場合、通話はバンガロールやマニラの有人コンタクトセンターへ即座に転送されます。会話の完全な状態ペイロードは、人間のオペレーターが挨拶をする前にその画面に届きます。

規模の経済学：インドのキャリアルーティングとLLMトークン最適化

インド市場には、独自の規制とコストの計算が伴います。TRAIのガイドラインの下では、プロモーション向けおよびトランザクション向けのルーティングは、全国的な発信拒否登録制度（NDNC）と、特定の時間帯の配信ウィンドウに準拠しなければなりません。認可されたテレマーケティング帯域の外でルーティングすれば、トランクは即座に停止され、加えて重い罰則が科されます。

利益率はプロンプトのトークンオーバーヘッド次第で決まります。中核となるペルソナやAPIスキーマといった静的な指示は、プロンプトキャッシングによってエッジでキャッシュすべきです。これにより、反復的で大量処理のフローでは入力トークンのコストを最大50%削減できます。

[Incoming Call] -> [Edge Router] -> [Check Prompt Cache (HIT)] -> Only process delta tokens ($0.00015 / call)
                                 -> [Check Prompt Cache (MISS)] -> Process full system prompt ($0.00080 / call)

構造化出力を伴う音声タスクでは、専用のクラウドインフラ上で動作するLlama-3-8Bのようなファインチューニング済みのローカルモデルが、コスト面でプロプライエタリなAPIを上回ります。NVIDIA H100インスタンス上でファインチューニングされた8Bモデルは、最初のトークンまでの時間(TTFT)が50ms未満に達します。これは自然な音声に必要な低レイテンシを、はるかに低い価格で実現するものです。

Finnはハイブリッドなルーティングレイヤーを運用し、地域ごとに異なる通信ネットワーク全体でコスト、レイテンシ、精度のバランスを取っています。単純な本人確認のステップはローカルのファインチューニング済みモデルへ、重量級のプロプライエタリモデルは複雑な請求に関する係争のために確保されます。グローバルなエンタープライズ運用にとって最適なユニットエコノミクスです。

脆弱でオープンエンドなフレームワークからの脱却に成功する企業は、決定論的で状態が限定されたエージェントを、中核となるトランザクションシステムに直接接続して展開する企業でしょう。B2Bの自動化は予測可能な実行にこそふさわしく、LLMは厳格なエンジニアリング上のガードレールの内側にある認知プロセッサとして機能します。

よくある質問

なぜオープンエンドなエージェントループは運用の現場で失敗するのか? 次に何をするかに制限がないからです。何でも呼び出せるループは、いずれ誤ったものを呼び出します。しかもその失敗は封じ込められることなく、際限なく広がります。

ステートマシンは何を変えるのか? 次に取りうるアクションの集合を有限にし、検査可能にします。柔軟性をいくらか手放す代わりに、システムに何ができて何ができないかを明言できるようになります。

これはエージェントが運用業務に向かないという意味ですか? いいえ。自律性はタスク全体を包み込むものではなく、1つのステップの内側に属するという意味です。何をするかではなく、限定された1つのことをどうやるかをモデルに決めさせるのです。