LLMエージェントの信頼性を劇的に向上させるDurable Executionの力

はじめに：AIエージェントの自律性と直面する課題

近年、AIエージェントはソフトウェア開発の様々な側面に革命をもたらしています。Replitが開発したAgent 3は、ビルドタイムにおける自律性において目覚ましい成果を上げています。例えば、Agent 3はテストの成否を判断し、バグを修正する能力を持っています。実際に、発見されたバグの40%を自律的に修正することに成功しており、これは自律性の観点から見れば非常に素晴らしい成果と言えます。また、テスト1回あたりのコストが平均20セントと非常に効率的であり、優れた投資対効果を実現しています。

エージェントは、人間が時間を費やしてクリック操作を行い、「これが〇〇だから失敗した」と説明する必要があったバグに対しても、その実行過程全体を観察し、何が問題だったのかを正確に把握して自己修復する能力を持っています。もちろん、これは完璧ではありません。例えば、CAPTCHA認証や他のサイトへのログインなど、特定の状況では約4%の人間による介入（エスカレーション）が必要となります。それでも全体としては、間違いなく大きな進歩です。このAgent 3の開発における自律性は、私たちReplitが最も誇りにしている点の一つです。

しかし、エージェントが持つべき自律性は、ビルドタイムだけにとどまりません。本記事では、このビルドタイムの自律性に加え、ランタイムの自律性、そしてエージェントが直面する避けられない「失敗」にどのように対処し、その信頼性を劇的に向上させるかについて掘り下げていきます。

エージェントがエージェントを構築するランタイムの自律性

Replit Agent 3のビルドタイムにおける自律性については先に述べましたが、ではランタイムの自律性、つまり「エージェントがエージェントを構築する」という概念はどうでしょうか？これは、エージェントが別の小さなソフトウェア（エージェント）にタスクを委譲できることを意味します。

Replitでアプリケーションを構築する場合、通常は半静的なものができ上がります。そこにはそれ以上の自律性はありません。しかし、もし異なる種類の自律性が必要になった場合はどうでしょう？例えば、毎日S&P 500の市場データを取得し、その情報を要約してメールで送信するようなシステムを構築する必要があるとしたらどうでしょうか。これは通常のウェブサイトやアプリケーションでは実現が困難です。より「エージェント的」な何かが必要になります。

このエージェントが構築するエージェントの内部ステートマシンは、基本的に以前ご紹介したReplit Agentのそれと似ています。コアとなるエージェントループは健在です。そこには依然としてLLM（大規模言語モデル）の呼び出しがあり、環境を変更したり利用したりする何らかのアクションやツール呼び出しがあり、そしてフィードバックが返されます。しかし、ユーザーへのエスカレーションに戻る代わりに、これが自動化を目的としているため、常に何らかの出力が返されます。時には「何かがうまくいかなかった」というエラーが出力されることもありますが、いずれにしても必ず出力がユーザーに送信され、「完了」と見なされます。

AIエージェントワークフローにおける不可避な失敗

このようなエージェントベースのシステムを構築する上で、私たちはある重要な事実に直面します。それは「失敗は避けられない」ということです。

想像してみてください。ある日目が覚めたら、S&P 500の市場データが届いていないことに気づきました。お気に入りのLLMプロバイダーのステータスページを開くと、今日はインシデントがあったと表示されています。モデルが関与するシステムでは、多くの失敗が発生する可能性があることをご存知の通りです。私たちは皆、モデルが非決定論的（nondeterministic）であることを知っています。つまり、同じ入力に対しても毎回同じ出力が保証されるわけではないため、このような事態は避けられません。

LLMの信頼性は、単体で見れば約99.8%と非常に高いと思われがちです。ほとんどの場合、うまく機能します。しかし、これはエージェントのワークフロー内でループとして何度も呼び出されることを意味します。この特定のLLMコールが、ワークフロー内で5回、10回、あるいは100回と繰り返される可能性があるのです。

この繰り返しが、単体の信頼性を大きく損なわせます。動画で示されたグラフが示すように、ワークフローのステップ数が0から100まで増えるにつれて、期待される信頼性がどのように低下するかを示しています。約50ステップで、信頼性は99.8%から90%にまで低下します。つまり、10回に1回はワークフローが失敗するということです。さらに100ステップまで進むと、信頼性は80%台前半にまで落ち込みます。これでは、システムが非常に不安定であると言わざるを得ません。

もちろん、LLMだけがシステム内の唯一の故障ポイントではありません。アクション自体も失敗する可能性があります。ウェブサイトをクロールする際、そのコードが失敗したり、メールの送信が失敗したり、プロセスのどの段階でも失敗は起こりえます。悲観的になりたいわけではありませんが、「失敗は選択肢ではない」のではなく、「失敗は避けられない」のです。私たちは失敗と向き合う必要があります。

失敗に立ち向かう：Durable Executionの導入

私たちはこの「失敗は避けられない」という事実を受け入れ、ではそれに対して何ができるのかを考えました。Replitがエージェントを構築する上で依拠した非常に重要な2つの柱があります。

Mastra: TypeScriptでエージェントを構築するための最も優れたフレームワークの一つです。
Ingest: 耐久性のある実行（Durable Execution）を提供するフレームワークです。

Durable Executionとは何か

Durable Executionの概念を簡単に説明します。通常のソフトウェア開発では、命令が次々に実行されていきます。しかし、Durable Executionを使用して何かを宣言する場合、ブロックの実行中に何らかの障害が発生しても、その実行中のある時点から再開することができます。

これは、ワークフローを最初からやり直す必要がなく、途中から再開できることを意味します。これにより、アプリケーションのリカバリーが格段に速くなり、より堅牢になります。

MastraとDurable Executionのシームレスな統合

Durable Executionを導入することは、少し複雑なプログラミング手法が必要で、コードの構造を少し変える必要があると思われるかもしれません。しかし、Mastraのおかげで、これは非常に簡単になります。

動画では、Mastraの正規のワークフロー例が紹介されました。これはドキュメントからそのままコピーされたもので、ステップを作成し、それらのステップをワークフローとして連結していく様子が示されていました。

このMastraワークフローにDurable Executionを追加するにはどうすればよいでしょうか？実際には、いくつかのインポート文を調整し、関数をラップしてワークフローやステップを作成するだけで済みます。残りのコードはそのままです。つまり、コードの大部分が維持されるという事実は、エージェントにとっても非常に重要です。なぜなら、モデルは通常、Durable Executionを考慮しない豊富なAPI例のコーパスでトレーニングされているからです。そのため、LLMの視点からはコードに変更がないことになり、非常に都合が良いのです。変更されるのは、コードの「前文」の部分だけであり、LLMにも人間にも、そして実際のワークフローにとっても素晴らしいことです。

Durable Executionによる劇的な成功と結論

Durable Executionを導入した結果、その影響は非常に大きなものでした。以前の悲観的な80%の成功率から、なんと**96%**にまで向上したのです。もちろん、これはLLMが書いたコードであるため、回復不可能な失敗は依然として発生しますが、これだけ回復できたという事実自体が大きな成功と言えます。

私たちは、このDurable Executionがユーザー向けに構築されたプリミティブであり、ユーザーがその存在について考える必要がない（すぐに利用できる）ことを非常に誇りに思っています。

まとめ：失敗は避けられないが、エンジニアリングによって克服できる

今回の内容から、皆さんにぜひ持ち帰っていただきたい点が2つあります。

テストは素晴らしい: 常にテストに投資しましょう。
Durable Executionは強力なツールである: ツールボックスにDurable Executionを入れておくことで、失敗の必然性について心配する必要がなくなります。

失敗は避けられない現実ですが、適切なエンジニアリング手法、特にDurable Executionを活用することで、その影響を大幅に軽減し、より堅牢で信頼性の高いAIエージェントシステムを構築できるのです。

参考動画: https://www.youtube.com/watch?v=3TqaDP63Qdk