OpenRath 2.0.0: Session を中心に据えたマルチエージェント実行基盤を読む
An open-source, PyTorch-like runtime for dynamic multi-agent and multi-session workflows.
ひと目でわかる
- これは何？
- OpenRath は Session を第一級の値として扱う Python 製エージェントフレームワークで、v2.0.0 では PostgreSQL と Redis を前提にした耐久実行レイヤーが加わった。PyTorch の比喩が設計判断にどこまで効いているか、そして本番運用に何が足りないかを確認する。
- 誰に向いている？
- 多エージェントが複数の分岐セッションを共有し、その系譜を後から追いたいチームに向く。単一エージェントのチャットbotを短く書きたいだけなら、Session という抽象は学習コストにしかならない。
- 商用利用できる？
- できます。BSD-3-Clause は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 47 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Session を最初に置くという設計判断
多くのエージェントフレームワークはエージェントループから始まる。OpenRath は Session から始まる。README はこの違いを、ひとつのアプリケーションが複数エージェント、複数ブランチ、永続メモリ、サンドボックス実行、追跡可能な系譜を同時に必要とする場面で効いてくると説明している。Session は会話状態とエージェント間協調の系譜を運ぶ値で、Tensor の位置づけに重ねられている。Agent は Session を別の Session に写す変換層であり、メッセージ履歴を各エージェントが別々に持つのではなく、分岐・統合・再利用・追跡の対象を Session のデータフローに一本化する。向き先は明確で、単一エージェントの単一セッションではなく、多エージェントが多セッションを共有する構成を前提に組むチームだ。
PyTorch の比喩がどこまで実装に対応しているか
README の対応表は Tensor を Session、Device を Sandbox または Backend、Parameter を Memory、Function を Tool、nn.Linear を Agent、nn.Module を Workflow、制御フローを Selector に割り当てる。比喩として面白いだけでなく、Sandbox が「ツールが実際に走る場所」をローカルプロセスや OpenSandbox などのバックエンドから選ぶ点、Memory がエージェントまたはストアに束縛され実行をまたいで recall と commit を行う点は、それぞれ実行環境と永続状態という別々の関心事を分離している。Selector は自己記述的なワークフロー間を実行時にルーティングし、if や while の制御フローを素の Python のまま書けるようにする。ここで注意したいのは、比喩が効くのは構造の説明までで、Tensor のような自動微分やデバイス間転送の意味論があるわけではないことだ。
v2.0.0 で加わった耐久実行レイヤー
v2.0.0 の中心的な変更は、コンポーザブルな Python フレームワークから、本番配備を想定した耐久ランタイムへの移行だと README は述べている。既存の Session 優先の Python API はそのまま残り、その周囲に実行と運用のレイヤーが追加された。明示的な @step と @router の境界が不変の実行プランにコンパイルされ、Run、Event、Checkpoint がプロセスやワーカーの再起動をまたいで残る。リーズ、フェンシング、リトライ、キャンセル、デッドライン、再開可能なキューによって、古いワーカーが新しい状態を黙ってコミットするのを防ぐ。副作用は Effect Ledger が結果と冪等性キーを記録し、非冪等な副作用の結果が曖昧な場合は盲目的に再生するのではなく NEEDS_REVIEW で停止する。人間の承認は Durable Interrupt が Run を一時停止し、隠れたループ状態を再構築せずに再開する。PostgreSQL が耐久の真実の源、Redis がシグナリングの加速、S3 互換ストレージが成果物の保管を担うという分担である。
本番プロファイルの立ち上げ方
README が示す本番向けの構成は、LocalRuntime に effect_ledger を渡し production_mode=True を立て、AgentServer に store、runtime、auth、audit_sink を渡す形になる。インストールは pip install "openrath[server,postgres]" で、スキーマ移行は別操作として openrath-migrate を実行し、openrath-migrate --check で確認する。ランタイムの識別情報には DDL 権限が不要で、トークンには明示的なアクション許可が必要、オブジェクトアクセスはテナントとプロジェクトでスコープされる。運用、移行、セキュリティの文書は deploy/ 以下にあり、deploy/docs/operations-v2.md、deploy/docs/migration-v2.md、生成された deploy/docs/openapi-v2.json が参照先として挙げられている。埋め込みモードは信頼されたプロセス内で引き続き有用で、Agent Server モードが厳格な本番プロファイルという位置づけだ。
同期ステップのタイムアウトと Beta の HTTP 面
見落としやすい制約が二つある。ひとつは同期ステップが preemptive timeout を宣言できないことで、デッドラインを強制したい場合は非同期ステップか隔離されたエグゼキュータを使う必要があると README は書いている。デッドラインを SLA として扱う設計では、ステップの同期・非同期の選択が後から効いてくる。もうひとつは Agent Server の HTTP 面が Beta のままだという点で、v2.0.0 は本番配備向けとされながら、インターフェースの成熟度は明示的に区別されている。加えて v1 の JSONL インポートは再開可能なアクティブ Run ではなく履歴レコードとして扱われる。v1 から移行する場合、過去の実行をそのまま継続できると期待すると外れる。
LangGraph との設計の違い
比較対象として分かりやすいのは LangGraph だ。LangGraph はグラフのノードとエッジとして処理の流れを定義し、状態はグラフに沿って受け渡される。OpenRath は制御フローをグラフとして固定せず、Selector に実行時のルーティングを任せ、if や while は素の Python で書く。状態の単位も、LangGraph がグラフ実行に付随する状態なのに対し、OpenRath は Session そのものを分岐・統合・追跡する対象として前面に出す。どちらが優れているという話ではなく、フローを事前に確定できるならグラフのほうが読みやすく、実行時に経路が変わり複数セッションが絡むなら Session を値として扱うほうが素直だという違いである。
ライセンスと更新コストの見積もり
ライセンスは BSD-3-Clause で、表示義務はあるが派生物の公開義務は課されない。v2.0.0 は 2026-07-31 に公開され、その二日前に v2.0.0rc1 が出ており、v1.3.0 からは三週間ほどで major が上がっている。耐久実行レイヤーが加わった以上、PostgreSQL のスキーマ移行と、Redis や S3 互換ストレージという運用依存が新たに発生する。openrath-migrate が別操作として切り出されている点は移行を計画的に回せるという意味で助かるが、major 更新のたびにこのコマンドを実行する前提でデプロイ手順を組む必要がある。BSD-3-Clause なので法的な懸念は小さいが、ライセンス解釈の最終判断は自組織の法務に確認してほしい。
編集部の結論
多エージェントが複数の分岐セッションを共有し、その系譜を後から追いたいチームに向く。単一エージェントのチャットbotを短く書きたいだけなら、Session という抽象は学習コストにしかならない。導入前に確認すべきは三点。openrath-migrate --check が既存スキーマとどう差分を出すか、Agent Server の HTTP 面が Beta である前提でどの API を固定するか、同期ステップに preemptive timeout を宣言できない制約が自分のワークロードに効くかどうか。この三点が問題にならないなら、Effect Ledger と Interrupt の設計は自前で作り直したくない類のものだ。
コミュニティノート