スケーラブルでAIエージェントに適したAPIインターフェースはどのように構築するのか？

エージェントに依存するAIアプリケーションには、従来のWebインターフェースとは異なる設計が必要だ。必ずしも新しいプロトコルが理由ではなく、トラフィックのパターンそのものが異なるためである。1つの会話が数十件の独立したリクエストに及ぶことがある一方、エージェントは、人間の待ち時間によってインフラへの負荷が軽減されることなく、機械的な速度で動作し続ける。

The New StackにOracleのスポンサー記事として掲載された本稿は、OpenAI互換でスケーラブルなインターフェースを構築するため、マイクロサービスにおける古くからの原則を再利用することを提案している。概念実証モデルでは、Oracle AI Database Freeを基盤としている。

エージェントのトラフィックはなぜWebアプリケーションと異なるのか？

ブラウザーは、ルーティングの固定性とユーザーの思考時間によって、1台のサーバー上でセッションを維持できる場合がある。一方、エージェントは40回連続で処理を実行することがあり、各サイクルは独立したHTTPリクエストとして到着するため、プロトコル上、同じサーバーへルーティングされる保証はない。会話履歴がローカルのプロセスメモリ内に残っている場合、別のサービスインスタンスへ移っただけで、次のリクエストはコンテキストを失う可能性がある。

また、ツール呼び出しは予期せぬ形で分岐する可能性がある。1つのリクエストが追加サービスをまったく呼び出さないこともあれば、複数のサービスを呼び出すこともあり、その中には400ミリ秒かかるベクトル検索が含まれる場合もある。エージェントは独自の再試行ポリシーによって負荷をさらに高める一方、トラフィックは連続的なバーストとして到来し、その量はユーザーの行動よりも同時実行数の上限とハードウェアによって決まる。

初期設計に潜む静かな問題

著者は、会話履歴をプロセス内の辞書に保持し、同時実行を制御するために単一のプールを使用し、リクエスト経路内でツール呼び出しを実行するプロトタイプを示している。この設計はテストでは機能するが、実際には会話のすべてのターンが同じマシンに到達することに依存している。

それぞれ4つのターンを持つ200件の会話を複数のインスタンスへ交互に分散すると、サーバーはHTTP 200を返し続ける一方で、モデルは正しい会話履歴なしに応答する可能性がある。そのため、この不具合は必ずしも明確な技術的障害として現れるとは限らず、ユーザーの観点では不正確な動作として現れる。

問題に対処する3つの原則

• 状態をプロセスの外部に出す：会話の状態とツール呼び出しの履歴を共有ストアに保存し、どのサービスインスタンスでも会話の任意のターンを処理できるようにする。
• 分離またはバルクヘッド：会話の完了やツール実行など、異なる経路と依存関係に対して独立した同時実行数の上限とタイムアウトを設定し、1つの障害がシステム全体を枯渇させるのを防ぐ。
• スマートなエンドポイントとシンプルなパイプ：OpenAI互換プロトコルを安定したトランスポート層として維持し、その上にルーティングロジック、予算管理、メモリ、ツール呼び出しポリシーを配置する。

実際には何が変わるのか？

概念実証モデルでは、システムを、OpenAIプロトコルで通信し状態を保持しないゲートウェイ、会話履歴と監査を管理するメモリサービス、独自の同時実行数上限とタイムアウトを持つ独立したツールサービス、共有ストアとしてのOracle AI Database Freeに分割している。この設計では、会話の同時実行に24スロット、ツール呼び出しに8スロットなど、独立した制御信号を使用する。

この分割により、ローカルファイルシステムやリクエストの固定ルーティングに依存せず、水平方向にスケーリングできる。また、プロトコルに互換性がある限り、OpenAIの公式クライアントはSDKを変更せずにインターフェースを利用できる。

編集上の結論は、AIエージェントのスケーラビリティは、単にインスタンス数を増やすだけでは解決できないということだ。本当のテストは、状態を維持し、遅い依存関係を制御し、再試行やツール呼び出しによってエージェントのバーストが連鎖的な障害へ変わるのを防ぐことである。なお、本稿はOracleのスポンサーコンテンツであるため、アーキテクチャ上のアプローチと概念実証モデルを提示するものであり、データベース間の独立した比較でも、あらゆる環境で特定の性能を保証するものでもない。