エージェント型アプリケーションのためのインフラストラクチャパターン

クラウドを切り替えますか？最大1万ドルのクレジットとハンズオンサポートを入手してください。今すぐ申し込む 会社 2026年7月20日 会社 エージェント型アプリケーションのためのインフラストラクチャパターン Jacob Prall 2026年7月20日 Jacob Prall ほとんどのチームは、エージェントを他のWeb機能と同じように構築し始めます。モデルをルートハンドラでラップし、リクエストを解析し、応答を待ちます。これはデモには適しています。本番環境では、これが最初に壊れる部分でもあります。エージェントは長時間実行され、状態を持ち、非決定的です。ツールを呼び出し、外部APIを待ち、サブタスクに分岐し、レート制限に達し、マルチステップシーケンスの途中でクラッシュします。エージェントが単一のHTTPリクエストに縛られている場合、アプリケーションの信頼性を非決定的ループの壁時計時間に結合させていることになります。デモを超えて進むということは、その結合を断ち切ることを意味します。この記事では、脆弱なエージェントスクリプトをスケーラブルで回復力のある本番システムに転換するためにチームが使用する3つのコアパターンを説明します。 エージェントの性質 エージェントの中核にはループがあります。目標を受け取り、次に何をすべきかを決定し、モデルまたはツールを呼び出し、結果を観察し、状態を更新し、完了するまで繰り返します。そのループには、単純なWebアーキテクチャを敵視させるいくつかの特性があります。 エージェントは長時間実行されます。通常のAPIリクエストは迅速に完了する必要があります。エージェントはしばしばそうではなく、時には完了するのに数時間、あるいは数日かかります。 エージェントは状態を持ちます。実行は単一の関数呼び出しではありません。それは目標、計画、ツール呼び出しと出力、リトライ、エラー、決定、そして最終的な出力です。プロセスがクラッシュした場合、何がすでに起こったかを知る必要があります。そうでない場合、進捗を失うか、盲目的に作業を再実行することになります。どちらも、特に長時間実行されるエージェントにとっては、良いことではありません。 エージェントは非決定的です。従来のワークフローコードは次のように言います。 エージェントコードは次のように言います。 モデルは実行時に次のアクションを選択するため、回復、再生、デバッグがはるかに困難になります。実行は3ステップで終わることもあれば、30ステップかかることもあります。複数のツールにまたがって展開したり、人間の承認を待ったり、大きな中間成果物を生成したり、早期に停止したりすることがあります。インフラストラクチャは、タイムアウト、予算、チェックポイント、承認、明示的な終了条件で、その予測不可能性の周りに境界を設定する必要があります。 これらをまとめると、エージェントにはアプリケーションコードにラップされたモデル呼び出し以上のものが必要であることがわかります。実行をリクエストから分離するアーキテクチャと、進捗を維持し、決定を記録し、副作用を制御し、モデルコンテキストとは別に成果物を管理するインフラストラクチャが必要です。 パターン：Web-キュー-ワーカー 最初本番パターンは、エージェント全体を実行リクエスト内で実行するのをやめることです。リクエストはエージェント実行の寿命としては不適切です。それは永続的な実行レコードを作成し、作業をキューに入れ、すぐに返す必要があります。これにより、アプリケーションに単純な境界ができます。 APIがジョブをキューに入れます。 キューがジョブを永続的に保存します。 ワーカーがジョブを実行します。 データベースが進捗を記録します。 クライアントはすぐに実行IDを取得します。 エージェントは別の場所で実行されます。 ユーザーはステータスを確認したり、更新を購読したり、実行完了時にコールバックを受け取ったりします。 キューは、作業を作成するものとそれを実行するものとの間の永続的なバッファです。実行が通常の要求よりも長い場合、タスクがほとんど独立している場合、およびワーカーのスケーリング、リトライ、またはバースト吸収が必要な場合のデフォルトの開始点です。 落とし穴：キューはジョブが存在することを知っていますが、そのジョブが属する論理プロセスを知りません。バックグラウンドジョブが1つなら問題ありません。依存関係のある20ステップ、3回のリトライ、2つの分岐、および人間の承認の一時停止は、キューが管理してくれるものではありません。そのロジックは自分で構築する必要があります。後述するように、ワークフローエンジンが登場するのはこのためです。 信頼性：安全なリトライと部分的な失敗 作業をキューに移動すると、寿命の問題は解決されます。実行の永続性は解決されません。ほとんどの本番キューは「少なくとも1回」です。つまり、ジョブが複数回実行される可能性があります。これは、作業の損失を回避するための意図的なトレードオフであり、コードはそれに耐える必要があります。エージェントがツールを呼び出し、レコードを書き込み、メッセージを送信したり、リソースをプロビジョニングしたりできるようになると、リトライ動作はアプリケーションの正しさモデルの一部になります。最も重要な2つの規律があります。冪等性は、単一のステップが2回実行された場合に何が起こるかに答えます。補償は、実行がシーケンスの途中で停止した場合に何が起こるかに答えます。リトライは、リトライされる操作が安全でない限り、回復戦略ではありません。 冪等性：ステップが2回実行されても生き残る 悪いワーカーコードは、ステップ間にクラッシュがないと仮定します。 ``` # 悪い例 charge_card(card_id) provision_resource(resource_id) send_email(email_address) ``` より良いコードは冪等性の境界を作成します。 ``` # 良い例 if not charge_card_completed(card_id): charge_card(card_id) mark_charge_card_completed(card_id) if not provision_resource_completed(resource_id): provision_resource(resource_id) mark_provision_resource_completed(resource_id) if not send_email_completed(email_address): send_email(email_address) mark_send_email_completed(email_address) ``` エージェントにとって、副作用のあるすべてのツール呼び出しは同じ扱いが必要です。ツールを呼び出す前に完了レコードを確認し、「実行中」レコードをupsertし、ツールを呼び出し、完了とマークします。 補償：実行が途中で停止しても生き残る 5ステップのうち3ステップ（カード請求、リソースプロビジョニング、確認メール送信）を完了したエージェントを考えてみましょう。その後、ステップ4が永久に失敗します。最初の3ステップのいずれもデータベーストランザクションでロールバックできません。カードへの請求はデータベース行を削除しても元に戻せません。お金はすでに動いています。実行をステップ1から再開すると、カードが再請求され、メールが再送信され、冪等性が防止しようとしたまさにその重複副作用問題が再作成されます。 分散システムには、これに対する標準的な答えがあります。サガパターンです。エージェントが実行できる副作用のあるアクションごとに、効果を元に戻す補償アクションを定義します。請求は払い戻しで元に戻されます。メールは修正メッセージで元に戻されます。実行が永久に失敗した場合、オーケストレーターは完了したステップを逆順にウォークし、それらの補償を実行します。補償も同様に冪等である必要があります。補償もそれ自体で失敗する可能性があります。請求APIと同様に、払い戻しAPIが利用できない可能性があります。補償チェーンには、境界付きリトライ、完了しない補償のためのデッドレターパス、および手動のエスケープハッチが必要です。これらがないと、失敗した実行は、半分の完了ではなく、半分の未完了で終わる可能性があり、これは改善ではありません。 補償は、部分的な失敗に対する常に正しい応答ではありません。5つの並列サブオーダーのうち4つが成功し、1つが失敗した場合、5つをドロップして4つを完了する方が良い結果であることがよくあります。これにより、成功した作業を巻き戻すことを回避できます。補償は、部分的な成功が許容されない場合に構築する価値があり、任意の失敗に対するデフォルトの応答としてではありません。 冪等性は、2回実行されるステップをカバーします。補償は、途中で停止した実行をカバーします。どちらも、実行が単純なワーカーによって実行されるか、ワークフローエンジンによって実行されるかにかかわらず必要です。 キューは作業を分散しますが、実行の形状を記憶しません。ジョブが存在することを知っています。ステップ3がステップ2に依存していること、人間の承認が保留中であること、2つの分岐が合成前に結合する必要があること、または最終ステップが失敗した場合に補償を実行する必要があることを知りません。 パターン：ワークフロー 難しくなるのが「このジョブはどこで実行されるべきか？」ではなく、「すでに起こったことを考えると、次に何が起こるべきか？」となったとき、キューイングからオーケストレーションに移行したことになります。ワークフローエンジンは、そのオーケストレーションレイヤーを提供します。それは実行の履歴を保存します。どのステップが開始され、完了し、失敗し、リトライされ、タイムアウトしたか、または外部入力を待ったか。ワークフローでは、クラッシュは最初からやり直すことを意味しません。すべてのワークフローシステムは、コードを同じ2つの役割に分割します。次に何が起こるかを決定するコーディネーターと、実際の作業（モデル呼び出し、ツール実行、レコード書き込み）を行うステップです。名前はエンジンごとに異なりますが、責任の分割が重要な概念です。決定は1つのレイヤーに、効果は別のレイヤーにあります。コーディネーターには1つの厳しいルールがあります。同じ履歴が与えられた場合、常に同じ決定を下さなければなりません。これは、回復がどのように機能するかによるものです。クラッシュ後、エンジンは、記録された結果をすでに完了した作業に置き換えて、決定ロジックを最初から再実行することにより、実行を再構築します。再生は