Chidori: すべての副作用を記録して実行を再現するRust製エージェントランタイム
The agent framework where every run is durable, replayable, and resumable by default.
ひと目でわかる
- これは何？
- TypeScriptで書いたエージェントのLLM呼び出しやHTTPリクエストをホストコールとして記録し、チェックポイント、リプレイ、再開をデフォルト動作にするランタイム。 durable execution をワークフローエンジンではなく言語ランタイム側で解こうとしている点が特徴で、向き不向きがはっきりしている。
- 誰に向いている？
- 採用を検討すべきなのは、長時間走るエージェントのデバッグで同じトークンを何度も課金しているチーム、あるいはクラッシュや人間の承認待ちで実行を失いたくないチームだ。逆に、単発の短いプロンプト呼び出ししかしない用途や、既存のPython製エージェントコードをそのまま動かしたいだけの場合は、TypeScriptで書き直すコストに見合わない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
エージェント開発のどの痛みを狙っているか
READMEはエージェントの性質を「非決定的で、高コストで、長時間動く」の三つに要約し、その組み合わせが開発を苦しくすると述べている。三回実行して初めて出るバグは再現できない。デバッグのたびに同じトークンが請求される。多段の実行が途中でクラッシュすると全部失われる。人間の承認を待つために何時間もプロセスを生かしておくことになる。
対象読者は、LLM呼び出しを含む処理を本番や検証で繰り返し走らせる必要がある開発者だ。とくに、実行の再現性をテストとして固定したい人、承認フローを挟むためにプロセスを常駐させたくない人に向く。逆に、一回呼んで結果を表示するだけのスクリプトには仕組みが重すぎる。
ホストコールという一点に集約した設計
仕組みの中心は境界が一つだけという点にある。エージェントが行う副作用、つまりLLM呼び出し、ツール呼び出し、HTTPリクエストは、すべてランタイムを経由する記録済みのホストコールとして流れる。エージェントは世界に直接触れないため、ランタイムがすべてを記録できる。
記録があれば、ログ、キャッシュ、リプレイ、一時停止、再開がすべて同じ仕組みから出てくる。リプレイは呼び出しログという決定的な記録に対して同じコードを再実行するもので、READMEによればLLM呼び出しゼロ、出力はバイト単位で同一になる。決定性は固定クロックとシード付き乱数というランタイムポリシーで担保されると説明されている。チェックポイントは各ホストのセーフポイントで取られ、プロセスを途中で殺しても新しいプロセスでログを一時停止点まで再生してからライブに戻る。`chidori.input()` と名前付きシグナルは実行をディスクに中断させ、人間や別のエージェントが後から答えると続きから再開する。
インストールと実行までの実際の手順
配布物は自己完結した単一バイナリで、NodeもPythonもRustツールチェーンもネイティブバインディングも不要とREADMEは説明している。もっとも速いのはプリビルド版で、次のコマンドを実行する。
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
macOSのApple SiliconまたはIntel、Linuxのx86_64またはarm64向けのバイナリが最新リリースから取得され、`~/.chidori/bin` に置かれ、必要ならPATHの一行が表示される。確認は `chidori --version` で行う。
ソースからビルドする経路も用意されている。crates.ioからなら安定版のRustツールチェーン1.95以降が必要で `cargo install chidori`、リポジトリをcloneする場合は `cargo build --release` で `./target/release/chidori` にバイナリが出る。リポジトリは rust-toolchain.toml でツールチェーンを固定しているため、cargoが自動でそれを使う。
ここで混同しやすいのは、インストールする `chidori` バイナリはランタイムであり、npmの `@1kbirds/chidori` とPyPIの `chidori` はHTTP経由でランタイムを操作する薄いSDKだという区別だ。SDKは必須ではない。
TypeScriptをそのまま書かせるという選択
ChidoriはエージェントをグラフやDSLではなく普通のasync TypeScriptとして書かせる。if、for、tryといったネイティブな制御フロー、型付き入力、実際のimport、エディタの補完がそのまま使える。durabilityはラッパーではなくデフォルトで、ステップに注釈を付けたりアクティビティを定義したりする必要はない。`await chidori.*` の一つ一つが durable でリプレイ可能なセーフポイントになる。
この設計は、既存のTypeScriptコードベースにエージェントを足したい場合に素直だ。一方で、Pythonで書かれたエージェント資産をそのまま持ち込みたい場合、ランタイムが実行するのはTypeScriptなので書き直しが発生する。Python SDKはランタイムを駆動するクライアントであって、Pythonでエージェント本体を書けるという意味ではない。ここは採用判断で見落とされやすい点だ。
リプレイとプロンプトキャッシュが効く場面、効かない場面
READMEは構造的なプロンプトキャッシュを組み込みで持つと述べている。安定したプレフィックスがプロバイダのキャッシュ向けに自動でマークされ、Anthropicでは基本入力レートの約10%になるとされている。リプレイ時はそもそも課金が発生しない。
ただしこれは、副作用がすべてホストコールを通っていることが前提だ。エージェントがランタイムを迂回して直接ネットワークを叩いたり、独自のHTTPクライアントを素で使ったりすれば、その部分は記録から漏れる。記録に漏れた処理はリプレイで再現されず、決定性も崩れる。フレームワークが保証するのは境界の内側だけであり、境界の外側の振る舞いを守る仕組みは提供されていない。
もう一つの制約は記録の保存だ。チェックポイントはディスクに書かれ、gitにコミットしてテストとして使うことも想定されている。長く走るエージェントや大きなツール応答を扱う場合、チェックポイントのサイズと保存先の管理は利用者側の設計問題になる。READMEはこの点の指針をほとんど示していない。
既存のワークフローエンジンとの違い
代表的な比較対象はTemporalのような durable execution エンジンだ。Temporalではワークフローとアクティビティを分けて定義し、決定性を保つためにワークフローコードに制約を課す。ステップの境界を開発者が明示する必要がある。
Chidoriの取り方は逆で、境界をホストコールという一箇所に寄せ、あとは普通のTypeScriptとして書かせる。ステップの注釈もアクティビティ定義も要らない。LLM呼び出しやツール呼び出しが最初からランタイムの管理下にあるため、プロンプトキャッシュやリプレイ時の課金ゼロといったLLM固有の利点を同じ仕組みから引き出せる。
代償は言語の固定だ。Temporalは複数の言語SDKを持つが、Chidoriのエージェント本体はTypeScriptに限られる。既存のワークフローをTemporalで運用しており、言語を選べることに価値を置いているなら、乗り換える理由は薄い。
メンテナンスとライセンスの見取り図
ライセンスはApache-2.0で、リポジトリのLICENSEにその旨が示されている。商用利用や改変を含む利用が許される条項だが、具体的な条件の解釈は利用者自身または法務の確認事項であり、ここで法的助言はできない。
更新の頻度は素材から読み取れる範囲では活発だ。v3.6.0が2026年7月7日、v3.7.0が7月29日、v3.8.1が8月30日で、直近のpushは2026年9月10日となっている。マイナー更新が約1か月間隔で並んでおり、破壊的変更の有無はリリースノートを確認する必要がある。
ランタイムは単一バイナリで、NodeやDeno、V8といった外部ランタイムに依存しないと説明されている。これはアップグレード時に追従すべき依存が少ないことを意味する。一方、SDKはnpmとPyPIで別々に配布されるため、ランタイムとSDKのバージョンの組み合わせは自分で管理することになる。crates.io経由でソースからビルドする場合はRust 1.95以降が必要で、この下限は将来上がりうる。
採用する前に確かめるべきこと
最初に確認するのは、自分のエージェントが使うツールとHTTPクライアントがホストコール経由になっているかどうかだ。ここが漏れていると、リプレイの決定性もキャッシュの利点も成立しない。次に、チェックポイントの保存先とサイズが自分の運用に収まるかを、実際に長めの実行を一度回して確かめる。
人間の承認を挟む設計を取るなら、docs/signals.md の名前付きシグナルの扱いを先に読んでおく。`chidori.input()` で中断した実行を、別プロセスからどう再開させるかが運用の要になる。
最後に、記録済みのチェックポイントをテストとしてgitに置けるかを試す価値がある。READMEはこれを「$0でミリ秒で走る統合テスト」と表現している。エージェントの振る舞いが変わっていないことを、トークンを消費せずに検証できるなら、リプレイの仕組みを導入する理由としてはこれが最も具体的だ。
編集部の結論
採用を検討すべきなのは、長時間走るエージェントのデバッグで同じトークンを何度も課金しているチーム、あるいはクラッシュや人間の承認待ちで実行を失いたくないチームだ。逆に、単発の短いプロンプト呼び出ししかしない用途や、既存のPython製エージェントコードをそのまま動かしたいだけの場合は、TypeScriptで書き直すコストに見合わない。導入前に確認すべきは、自分のエージェントが使うツールやHTTPクライアントがホストコール経由になっているか、そしてチェックポイントの保存先とサイズが運用に耐えるか。まず `chidori --version` で動くバイナリを手元に置き、docs/signals.md に目を通してから、記録済みチェックポイントをテストとしてgitに置けるかどうかを試すのが現実的な順序になる。
コミュニティノート