Rivet Actorsとは｜AIエージェントの状態をメモリ常駐で永続化するactorランタイムを実測

AIコーディングエージェントに関する記事の多くは、GUIやターミナルといった「操作面」を扱う。だがその裏で、エージェント1セッションぶんの状態（会話履歴・進行中のタスク・ツール呼び出しの結果）をどこにどう持たせるかというインフラ層の話はあまり語られてこなかった。Rivet Actors（rivet-dev/actors）は、Cloudflare Durable Objectsに近いactorモデルを、セルフホスト可能なOSSとして提供するランタイムだ。README実測の数値と、実際に手を動かしたセットアップ結果をもとに、その設計を検証する。

なお「Rivet」という名前は、アニメーションツールの「Rive」など複数の同名・類似名プロダクトと紛らわしい。本記事が扱うのはrivet.dev・GitHub rivet-dev/actorsの、AIエージェント向けactorランタイムのRivetであり、アニメーションツールのRiveとは無関係だ。

エージェント自体の仕組みや代表的フレームワークをまず押さえたい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を入口にしてほしい。本記事はそのうち「エージェントの状態をどこに持たせるか」というランタイム選定の視点を扱う。

Rivet Actorsとは——AIエージェントの状態をactorに持たせる仕組み

Rivet Actorsは、READMEの見出しで自らを「the primitive for stateful workloads（statefulなワークロードのための基本部品）」と表現し、サブタイトルで「Built for AI agents, collaborative apps, and durable execution.」と訴求している。開発元はRivet社で、OSS（RivetKit・Rivet Engine）とマネージドSaaS「Rivet Cloud」を両輪で提供するハイブリッド構成だ。海外の設計解説では「actor model AI agent」という文脈で語られることが多く、日本語でいえばAIエージェント 状態管理の課題をactorモデルで解く試み、と位置づけられる。

actorの定義は実際にはこう書く。README「What is Rivet?」に掲載されているバックエンド側のコード例を引用する。

const agent = actor({
  // In-memory, persisted state for the actor
  state: { messages: [] as Message[] },

  // Long-running actor process
  run: async (c) => {
    for await (const msg of c.queue.iter()) {
      c.state.messages.push({ role: "user", content: msg.body.text });
      const response = streamText({ model: openai("gpt-5"), messages: c.state.messages });
      for await (const delta of response.textStream) {
        c.broadcast("token", delta);
      }
      c.state.messages.push({ role: "assistant", content: await response.text });
    }
  },
});

stateにオブジェクトを書けば、それがそのactorのメモリ上の状態として自動永続化される。クライアント側はclient.agent.getOrCreate("agent-123").connect()のようにactor IDを指定して接続し、queue.send()でメッセージを送る。実行が長時間続く一つのプロセスとして常駐し、アイドル時はスリープ、呼ばれたら再び起動するという設計だ。

仕組み：actor 1つ＝1セッションのメモリ常駐設計とベンチマーク実測

README「How Actors Compare」には、Rivet Actorと従来インフラ（Kubernetes Pod・VM）、および状態ストア（Redis・Postgres）を比較したベンチマーク表がある。数値はRivet社の計測環境（Node.js 24・FoundationDB・AWS EKS/EC2）に基づく自己申告値で、本記事では独自の再現検証は行っていない。表の内容をそのまま引用する。

README脚注（Benchmark details & methodology）によると、コールドスタート約20msは「actor keyを指定しないため、クロスリージョンのロック取得を含まない」条件での計測とされている。K8s Podの約6秒はNode.js 24 Alpineイメージ（圧縮56MB）をAWS EKSの事前プロビジョニング済みm5.largeノードで起動した内訳（イメージpull約1秒＋スケジューリング約3〜4秒＋コンテナ起動約1秒）。読み取り遅延0msは「actorと同一マシン上のSQLite/KVストレージから読むためネットワーク往復が無い」ことが根拠として説明されている。

actorが「1つのプロセスとして常駐し、呼ばれなければスリープする」挙動は、コンテナのようにイメージpullやスケジューリングをやり直さない点が従来インフラとの違いだ。ただし、この差が効くのはリクエスト頻度が高く同一actorへ繰り返しアクセスするワークロード（チャット・共同編集ドキュメント・エージェントのセッション）で、単発バッチ処理では体感差は小さいと考えられる。

インストールと起動：npm installから実際に動かす（実機検証）

READMEの「Just a Library」に従い、最小構成のプロジェクトを作って実際に動かした。検証環境はNode.js v22.23.2・npm 10.9.8、実施日は2026-08-20。

mkdir rivet-test && cd rivet-test
npm init -y
npm install rivetkit

index.tsにactorを1つ定義する。README「Getting Started」配下のhello-worldサンプルを簡略化したもので、incrementで加算、getCountで現在値を返すだけのカウンターactorだ。

import { actor, setup } from "rivetkit";

const counter = actor({
  state: { count: 0 },
  actions: {
    increment: (c, amount) => {
      c.state.count += amount;
      return c.state.count;
    },
    getCount: (c) => c.state.count,
  },
});

const registry = setup({ use: { counter } });
registry.start();

npx tsx index.tsで起動すると、ログにエンドポイントが表示されるまで約1.6秒だった（TypeScriptのトランスパイルを含むdevサーバーの起動時間で、README実測の「actorコールドスタート約20ms」とは別の数値であることに注意）。

  RivetKit 2.3.10 (Engine - Serverful)
  - Endpoint:     http://127.0.0.1:6420 (local native)
  - Actors:       1

npm install rivetkitは2026-08-20時点でRivetKit 2.3.10を解決した。http://127.0.0.1:6420/へ素のcurlでGETすると308リダイレクトが返るだけで、actorのアクション（increment等）を直接呼び出すにはクライアントSDK（WebSocket接続）が必要だった。README通りサーバー不要でその場で起動する体験は確認できたが、動作確認には公式クライアントライブラリを使う前提になる。

デプロイオプション：ライブラリ・セルフホスト・Rivet Cloud

README「Deployment Options」は3つの導入経路を並べている。

・ライブラリのみ：npm install rivetkitだけでよく、サーバー・インフラ不要。開発中はactorが自分のプロセス内で動く
・セルフホスト：Rust製の単一バイナリ、またはDockerコンテナ。Postgres・ファイルシステム・FoundationDBのいずれかと組み合わせられる
・Rivet Cloud：フルマネージド。Vercel・Railway・AWSなど既存のクラウドと接続できるグローバルエッジ提供

セルフホストのDocker起動コマンドはREADMEにそのまま載っている。

docker run -p 6420:6420 rivetdev/engine

もう一つ、READMEの「Use with Your Coding Agent」にはAIコーディングエージェント向けのセットアップコマンドがある。

npx skills add rivet-dev/skills

README曰くClaude Code・Cursor・Windsurfなど複数のAIコーディングツールに対応するskillsパッケージで、エージェントにRivet Actorsの使い方を教える目的のものだ。これは実際に動かして確認したわけではなく、README記載のコマンドをそのまま引用している。

料金体系（Rivet Cloudの無料枠の有無など）は本記事では未確認のため触れない。必要であれば公式サイト（rivet.dev）で確認してほしい。

Rivet Actorsと類似ツール・構成との比較

Rivet Actorsは「エージェントの状態をどこに持たせるか」というインフラ層の話であり、当サイトで扱ってきたAIコーディングエージェントの操作系ツール（GUI・ターミナル多重化）とはレイヤーが異なる。エージェントのループ内でモデル選択やコストを最適化するcascadeflow（AIエージェントのコスト・遅延・品質をエージェントループ内で最適化するin-processランタイム）とも対象が異なり、cascadeflowが「実行中の意思決定」を扱うのに対し、Rivet Actorsは「状態の永続化・スケーリング」を扱う。

人が複数のエージェント／タスクを一元操作するUI層の話は、holaOS｜AIエージェントと人が同居するOpen Agent Computer、Workspace中心設計を解読やruflo｜Claude Code/Codexにネイティブ統合する100エージェント・スウォーム基盤で扱っている。これらは「エージェントをどう束ねて操作するか」であり、Rivet Actorsの「1エージェントの状態をどう持たせるか」とは補完関係になり得る。

導入時の注意点と現時点で未確認のこと

リポジトリ名はrivet-dev/rivetからrivet-dev/actorsへ改名されており、rivet-dev/rivetで検索するとGitHubが自動的にrivet-dev/actorsへリダイレクトする。本文中のクローンコマンド・リンクは改名後のrivet-dev/actorsを使う。

まとめ：Rivet Actorsが向いている場面

参照ソース

・rivet-dev/actors（公式リポジトリ・README） — star数・ライセンス・ベンチマーク表・コード例の一次情報
・Rivet 公式サイト — プロダクト概要・デプロイオプション
・Rivet Actors - The Primitive for Stateful Workloads — actorモデルの設計思想