Restateは2026年9月30日、シリーズAで2,000万ドルを調達したと発表した。Singularが主導し、Redpoint VenturesとCapital One Venturesが参加した。
Apache Flinkの開発を手掛けたチームがRestateで目指しているのは、長時間動くAIエージェントやバックエンド処理の進捗を記録し、障害が起きても途中から処理を再開できる「Durable Execution（耐障害実行）」を、より広く使える基盤にすることだ。
AIエージェントは、モデルへの問い合わせや外部ツールの操作を何度も繰り返す。数十分、数時間にわたる処理の途中で障害が起きたとき、最初からすべてをやり直すのか、それとも完了済みの処理を引き継いで続きから再開できるのかで、費用や処理時間は大きく変わる。
Restateの仕組みを見ると、障害からの復旧を基盤側に任せられる部分と、それでも開発者自身が設計しなければならない部分の境界が見えてくる。
エージェントの「途中経過」を残す意味
Restateは2024年6月、700万ドルのシード資金調達と「Restate 1.0」の公開を発表している。
もともと同社が取り組んできたのは、複数のサービスやAPIをまたいで実行するバックエンド処理を、障害が起きても途中の状態を失わずに動かすという問題だ。
今回の資金調達は、その仕組みをAIエージェントを含む、より幅広いバックエンド処理へ広げようとする動きといえる。
例えば、注文内容を読み取り、在庫を確認し、担当者の承認を待ってから決済するエージェントを考える。
最後の決済直前にサーバーとの接続が切れた場合、処理全体を最初からやり直せば、それまでに取得したAIモデルの回答や在庫照会の結果まで再取得することになる。
これをアプリ側だけで防ごうとすれば、完了した処理を保存し、再試行時にどこまで終わっていたかを確認して、必要なところから再開する仕組みを開発者自身が作らなければならない。
Restateでは、モデルから得た応答やツール実行の結果などを実行履歴に記録する。
障害が発生した場合には処理を再び起動するが、すでに完了して履歴に残っている手順については、実際の処理をもう一度行わず、保存済みの結果を利用する。
これにより、すでに取得したモデルの応答を再び生成したり、完了済みの処理を繰り返したりする時間と費用を抑えられる。
ただし、結果が履歴に記録される前に失敗した処理まで、必ず再実行されないわけではない。AIエージェントの公式解説
開発者は通常の関数として処理を書き、HTTPリクエストやモデル呼び出しなど、実行するたびに結果が変わる可能性のある操作をSDKのctx.runで囲む。
Restateはその結果を記録し、障害から復旧するときには保存済みの結果を再利用する。
つまり、既存のプログラムをRestate上で動かすだけで、すべての処理に自動的に復旧保証が付くわけではない。どの処理を記録対象とするのかは、開発者が指定する必要がある。
公式のLangChain向け説明でも、ツール呼び出しのどの部分を耐障害化するかは開発者が選択する仕組みになっている。手順の記録方法
人間による承認待ちも、同じ考え方で扱える。
承認結果を受け取るための識別子を発行し、回答を待っている間は処理を一時停止する。承認が届けば、その識別子を使って処理を再開し、続きから実行する。
待機中に関数を動かし続ける必要がないため、サーバーレス環境では承認を何時間、何日も待つためだけに実行リソースを占有せずに済む。
もちろん、実行していない時間に計算料金が発生しないことと、Restateの保存領域やサービス利用料まで無料になることは別の話だ。
「一度だけ実行」の保証はどこまで及ぶのか
耐障害実行で特に注意が必要なのが、外部サービスへの操作だ。
例えば、決済APIへの請求が成功した直後に通信が切れ、成功したという応答だけを受け取れなかったケースを考える。
この時点では、決済サービス側ではすでに請求が完了していても、Restateの実行履歴には成功結果が記録されていない可能性がある。
その状態から処理を再試行すると、同じ決済要求をもう一度送る可能性がある。
Restateの公式ガイドでも、「外部操作には成功したが、その確認結果を受け取れなかった」というケースを想定した設計が必要だとしている。
Restateが保存済みの結果を再利用できることと、外部APIで同じ処理が二重に実行されないことは、別の保証だ。
後者には、外部API側の「冪等性」が必要になる。
冪等性とは、同じ識別子を使って同じ要求を何度送っても、請求や予約などの処理が重複しない性質を指す。
2026年10月1日時点のRestateの公式仕様を、何を基盤側で管理できるのかという観点で整理すると、次のようになる。
| 対象 | Restateが担うこと | 開発者側に残る設計 |
|---|---|---|
| 記録済みのモデル応答・処理結果 | 障害からの復旧時に保存済みの結果を再利用 | 結果が変わり得る処理を記録対象として指定する。記録前に失敗した処理は再試行される可能性がある |
| Virtual Objectの状態 | 同じキーに対する書き込み処理を直列化し、状態を保持 | 異なるキーは並行して動く。外部データベース全体を排他制御する仕組みではない |
| 人間による承認待ち | 待機状態を保持し、応答が届いたら処理を再開 | どの条件で承認を求めるか、誰に承認権限を与えるかはアプリ側で設計する |
| 外部APIへの請求・予約 | 呼び出し結果を記録し、障害時には必要に応じて再試行 | API側で同じ冪等キーを使って重複処理を防ぎ、必要に応じて取り消しや補償処理を実装する |
表は手順の記録、サービス種別と状態、承認待ち、冪等性と補償の各仕様をもとに整理した。
外部APIを利用する場合は、再試行しても同じ識別子を使い、API提供側がその識別子をもとに重複した要求を排除できることが重要になる。
また、すべての失敗が再試行で解決するわけでもない。
例えば在庫不足は、ネットワーク障害とは異なる。何度やり直しても商品が増えるわけではない。
すでに別の商品を予約していたり、料金を支払っていたりする場合には、それらを取り消すための「補償処理」が必要になる。
その補償処理そのものは、開発者が業務ルールに合わせて記述しなければならない。
Restateは処理の進捗を失わずに実行するための仕組みを提供するが、「この注文を成立させてよいか」「失敗したときに何を取り消すべきか」といった業務上の判断まで決めてくれるわけではない。
実行履歴を中心に、状態管理と復旧をまとめる
Restateの内部設計では、複製されたログが処理の記録と復旧の基盤になっている。
2025年に公開された設計解説によると、実行した処理やその結果をログへ記録し、その情報をもとにアプリケーションの状態を管理する。
状態データはRocksDBに反映され、定期的なスナップショットはオブジェクトストレージへ保存される。
処理を担当していたRestate Serverが失われても、保存済みの状態とログを使って復旧できる構造だ。
実際のアプリケーションロジックを実行するサービスと、実行履歴や状態、再試行などを管理するRestate Serverは分離されている。
一方、Restate Server自体は、外部のデータベースや分散ログシステムを別途必須とせず、必要な機能を一つのシステムにまとめている。
キュー、状態管理、再試行、処理のスケジューリングなどを複数の基盤製品へ分散させる箇所を減らせることが、この設計の狙いだ。
もちろん、管理すべき状態そのものがなくなるわけではない。これまでアプリケーションや複数の基盤製品が個別に扱っていた状態の一部を、Restateがまとめて管理する形になる。
会話セッションやAIエージェントの状態管理には「Virtual Object」を利用できる。
Virtual Objectはキーごとに状態を持ち、同じキーに対する書き込み処理は一度に一つだけ実行する。
例えば、一つの会話セッションに対して複数の処理が同時に状態を書き換え、内容が食い違うといった問題を防ぎやすくなる。
一方、異なるキーの処理は並行して実行できるため、ある利用者の会話を処理している間も、別の利用者の会話を同時に進められる。
長時間の処理では、コードのバージョン管理も必要になる
数時間や数日にわたって実行される処理では、実行中にアプリケーションのコードが更新される可能性もある。
ここでも、単純に最新コードへ切り替えればよいとは限らない。
Restateは、開始済みの処理を特定の変更されないデプロイ版に結び付ける。障害後に再試行するときも、原則として同じバージョンのコードへ処理を送る。
これは、実行途中で記録対象となる手順を追加したり、手順の順序を入れ替えたりすると、すでに保存されている履歴と新しいコードの処理順序が一致しなくなる可能性があるためだ。
新しいバージョンを公開しても、すでに進行中の処理は、それを開始した旧バージョンで最後まで完了できる状態を維持する必要がある。
長時間動くAIエージェントでは、障害復旧だけでなく、このようなコード更新との整合性も運用上の課題になる。
Replitでは、耐障害化する処理が前世代の10倍超に
Restateは今回の資金調達発表で、Replitが「Replit Agent」の実行基盤をRestateへ移行した事例を紹介している。
Restateによると、新しいアーキテクチャでは、前世代と比べて10倍を超えるdurable actionを利用している。
ここでいう「10倍超」は、Replit Agentの処理速度が10倍になったという意味ではない。
AIエージェント内部で、障害後に再利用できる形で記録する処理の単位が大幅に増えたという意味だ。
従来のようにエージェント全体を大きな一つの処理として耐障害化するのではなく、モデルへの問い合わせ、ツール実行、ガードレールの確認、状態変更など、エージェント内部の細かな処理まで記録対象にする。
記録する単位を細かくすれば、障害が起きたときにやり直す範囲を小さくできる。
20個の処理を終えたところで21個目に失敗した場合、最初から20個をやり直すのではなく、保存済みの結果を使って21個目付近から再開できるためだ。
どの処理で問題が起きたかも追跡しやすくなる。
一方、記録する処理が増えれば、そのたびに実行履歴を書き込む必要がある。
そのため、耐障害化する処理単位を細かくできるかどうかは、記録処理による遅延と費用が十分に小さいかにも左右される。
Restateが今回のReplit事例で強調しているのは、durable actionをAIエージェントの内部ループに組み込めるほど低遅延・低コストにするという設計だ。
Restateによると、Replitでは一つのエージェント実行に数千のdurable stepを組み込み、それぞれの処理に加わる遅延を数ミリ秒程度に抑えている。
ただし、Restateが今回の資金調達発表で示した「10倍超」については、比較対象となったアクションの絶対数や測定期間、移行前後の失敗率などは示されていない。
そのため、この数字だけから、処理速度がどれだけ改善したか、運用費用がどれだけ減ったか、エージェントの成功率がどの程度上がったかを計算することはできない。
導入を検討する企業にとって重要なのは、自社のエージェント処理をどこまで細かく記録し、そのときの追加遅延と費用を許容できるかだ。
Temporalとの競争では、細かな処理まで耐障害化できるコストが焦点に
Durable Executionへの投資が拡大しているのはRestateだけではない。
Temporalは9月、シリーズEで5億5,000万ドルを調達し、企業評価額は125億5,000万ドルに達したと発表した。
AIエージェントや長時間のバックエンド処理を、障害が起きても継続できるようにする実行基盤へ、大規模な資金が流れ込んでいる。
ただし、RestateはシリーズA、TemporalはシリーズEであり、企業の成長段階は大きく異なる。調達額や企業評価額を製品性能の比較に使うことはできない。
RestateがTemporalなど既存のDurable Execution基盤との差別化要因として強調しているのが、処理単位当たりの遅延とコストだ。
耐障害化する処理一つ一つの負担が大きければ、開発者は複数の処理をまとめて大きな単位として記録するようになる。
逆に一つの処理を記録するコストが十分に小さければ、モデル呼び出しやツール実行といったエージェント内部の細かな処理まで耐障害化できる。
Restateが目指しているのは、Durable Executionを一部の重要なワークフローだけに使う仕組みではなく、通常のバックエンド処理にも広く組み込める程度まで軽量化することだ。
その一つとして提供しているのが、利用企業自身のクラウド環境でRestateを利用する「BYOC（Bring Your Own Cloud）」である。
BYOCでは、実行環境を利用企業のクラウド内に配置
Restateは2026年7月7日、BYOCの提供を発表した。
BYOCでは、Restateの実行環境を利用企業自身のAWSやGoogle CloudのアカウントとVPC内に配置し、Restate側が管理する。
計算資源やストレージ、アプリケーションデータは利用企業のクラウド環境に置かれる。
金融情報や医療情報、ソースコードなど、機密性の高いデータを自社のクラウド環境外へ出しにくい企業でも、マネージドサービスとしてRestateを利用しやすくする狙いがある。
料金も、処理したアクション数をそのまま従量課金する方式ではなく、あらかじめ確保する処理能力を基準にする。
Restateが7月に示した試算では、平均で毎秒5,000アクションを処理し、余裕を持って毎秒1万アクションの処理能力を確保する場合、BYOCのライセンス料とクラウドインフラ費を合わせて月額約3万ドルになるとしている。
同じ平均毎秒5,000アクションをTemporalで処理した場合について、Restateはアクティビティ料金だけで月額約30万ドルになると試算し、約10倍の差があるとしている。
ただし、これはRestate自身が2026年7月時点の料金条件をもとに作成した比較である。
Temporal側について計算しているのはアクティビティ料金だけであり、両製品を同じ条件で運用した第三者による実測結果ではない。
また、どのような負荷や契約でも10倍の差になることを意味するものでもない。
処理能力をあらかじめ確保する料金体系は、高い負荷を継続して流せるサービスほど効率がよくなりやすい。
一方、利用量が少ない時間が長いサービスでは、確保した処理能力を実際にどれだけ使えるかが費用対効果を左右する。
さらに、AIエージェント全体の費用を比較する場合には、RestateやTemporalの料金だけでなく、モデル推論、アプリケーションを動かす計算資源、ストレージなども含めて考える必要がある。
細かな処理まで耐障害化することで再試行を減らせても、そのための記録処理にどれだけ費用がかかるかまで含めた総額で評価する必要がある。
AIエージェントに必要なのは「失敗しないこと」ではなく「失敗しても続けられること」
AIモデルそのものの性能が上がっても、数時間にわたるエージェント処理を一度も失敗させないことは難しい。
ネットワークは切れ、外部APIはタイムアウトし、サーバーは停止する。人間の承認を数時間待つこともある。
長時間動くAIエージェントでは、障害そのものを完全に防ぐより、障害が起きても完了済みの作業を失わずに続きから再開できることが重要になる。
Restateが提供するのは、そのための実行履歴、状態管理、再試行、待機と再開といった仕組みだ。
一方、外部APIで処理を重複させないための冪等性や、途中まで成功した業務を取り消す補償処理、どの操作を記録対象にするかといった設計は、依然として開発者側に残る。
RestateのシリーズAを実際の導入判断につなげるには、自社のエージェントで障害を発生させたとき、どの地点から処理を再開できるのか、外部APIへの重複要求をどこまで防げるのか、そのためにどれだけの遅延と費用が増えるのかを確認する必要がある。
そこまでを検証できれば、開発者は障害復旧のための管理コードを減らし、AIエージェントにどの仕事を任せるかという、本来のアプリケーション設計により多くの時間を使えるようになる。