Rivet: グラフで組むAIエージェントと、それをアプリに埋め込むTypeScriptランタイム

Rivetが埋めようとしている隙間

LLMを使った処理をアプリに組み込むとき、多くの場合コードは「プロンプト文字列を組み立て、APIを呼び、結果を分岐させる」という形になる。分岐が3つ4つと増えると、どの入力がどこへ流れるのかをコードを読み返して追う作業が発生する。Rivetはこの部分を、ノードとエッジからなるグラフとして画面上で組み立てる。READMEの冒頭は「the IDE for creating complex AI agents and prompt chaining, and embedding it in your application」と説明しており、作成と埋め込みの両方を射程に入れている。対象読者は大きく2種類いる。プロンプトの分岐を視覚的に把握しながら反復したい開発者と、その成果物を自分のTypeScriptアプリから呼び出したい開発者だ。前者はデスクトップアプリを、後者はnpmパッケージを使う。

IDEとランタイムが別物であるという設計

READMEはRivetを2つの層に分けて説明している。Rivet ApplicationはAIエージェントとプロンプト連鎖を作るためのデスクトップアプリケーションで、Rivet CoreはRivetで作られたグラフを実行するTypeScriptライブラリだ。READMEの表現を借りれば、Coreは「used by the Rivet application, but can also be used in your own applications」であり、双方向の呼び出しを想定している。つまりRivetのグラフから自分のアプリのコードを呼び、自分のアプリからRivetのグラフを呼ぶ、という関係になる。この分離は採用判断に直結する。GUIで作ったグラフはそのまま実行時の成果物になるので、プロトタイプと本番の間でロジックを書き直す工程が発生しない。一方で、グラフの編集はGUIが前提であり、テキストエディタやCIの中でグラフを組み替える手段はREADMEからは読み取れない。

対応モデルとベクトルDBの範囲

READMEが挙げるLLM対応は、OpenAIのGPT-3.5とGPT-4、AnthropicのClaude InstantとClaude 2、Claude 3ファミリのHaiku・Sonnet・Opus、そしてAssemblyAIのLeMURフレームワーク（音声データ向け）だ。埋め込みとベクトルDBはOpenAI EmbeddingsとPinecone。追加の連携としてAssemblyAIのSpeech-to-Textが挙がっている。ここで注意したいのは、この一覧がREADMEに書かれた時点のものであり、モデル名の粒度が揃っていないことだ。Claudeは世代とサイズまで書かれているが、OpenAIはGPT-3.5とGPT-4という括りで、より新しいモデル名は記載されていない。自分のスタックがこの一覧の外にある場合、対応状況はドキュメント側で確認する必要がある。

導入経路: バイナリとパッケージ

アプリケーションを使うだけなら、releasesページのlatest downloadからプラットフォーム別の成果物を取る。READMEが示すのはMacOS向けのRivet.dmg、Linux向けのRivet.AppImageとRivet.dmg、Windows向けのRivet-Setup.exeだ。Linuxのdmgという組み合わせが併記されている点は、READMEの記述をそのまま写したもので、実際にどちらを使うべきかは自分の環境で判断してほしい。ソースから動かす場合はCONTRIBUTING.mdを参照するよう案内されている。アプリへの埋め込みはnpm経由で、Rivet coreが@ironclad/rivet-core、Rivet nodeが@ironclad/rivet-nodeとして公開されている。設定キーやAPIの具体的な形はREADMEには載っておらず、Rivet Integration Getting StartedとAPIリファレンスを参照する構成になっている。つまりこのリポジトリのREADMEだけでは、最初の1本を動かすところまでは到達しない。

GUI前提という制約と、向かないケース

最もはっきりした制約は、グラフの作成がデスクトップアプリに依存している点だ。READMEのGetting Startedはバイナリのダウンロードとソースからのビルドの2択しか示しておらず、グラフをコードとして生成したり、既存のグラフをプログラムから書き換えたりする経路は記載されていない。このため、プロンプトの変更をプルリクエストのレビュー対象にしたい、CIでグラフの妥当性を検証したい、といった運用をそのまま組むのは難しい。もうひとつの注意点はバージョン体系だ。リリース一覧にはapp-v1.11.3とapp-v1.11.2というIDE側の番号と、v1.25.0というLibraries側の番号が並んでいる。IDEとライブラリが別々にバージョンを刻む構成であり、片方を更新したときにもう片方との組み合わせを意識する必要がある。

コードで組む場合との違い

比較対象として素直なのは、LangChainやVercel AI SDKのようにプロンプト連鎖をTypeScriptのコードとして書くライブラリだ。違いは成果物の形にある。コードで書く場合、分岐やリトライの構造はソースファイルに残り、差分レビューやテストの対象になる。代わりに、非エンジニアがフローを確認したり、プロンプトの分岐を図として眺めたりするのは難しい。Rivetは逆で、フローの全体像はGUI上で把握できるが、その構造はグラフファイルとして存在し、コードの差分として読むものではない。どちらが優れているという話ではなく、フローの編集を誰が行うかで決まる。エンジニアがコードレビューの流儀で管理したいならコード側、プロンプト調整の試行錯誤を短いサイクルで回したいならRivet側が素直だ。

ライセンスと保守の見取り図

ライセンスはMITで、リポジトリはアーカイブされておらず、最終pushは2026年8月26日、直近のリリースは2025年8月8日のapp-v1.11.3と2025年6月30日のv1.25.0だ。MITなので、組み込んだアプリの配布形態に対してソース開示を求めるタイプの条件は課されない。ただしこれは一般的な説明であり、依存パッケージを含めた最終的な判断は法務に確認してほしい。保守コストの面で意識しておきたいのは、IDEとライブラリで別々にバージョンが進むことによる追従の手間だ。アップグレードのたびに、手元のグラフが新しいランタイムで期待通りに動くかを確認する工程が入る。CONTRIBUTING.mdとCode of Conductが用意され、DiscordサーバーとGitHub Discussionsが案内されているので、詰まったときの相談先は確保されている。

編集部の結論

Rivetが向くのは、プロンプト連鎖の試行錯誤をGUIで回したい開発者と、その成果物であるグラフを@ironclad/rivet-node経由でTypeScriptアプリに埋め込みたいチームだ。逆に、CI上で完結するコード主体のパイプラインを求める場合や、対応LLMとベクトルDBの一覧に自分のスタックが入っていない場合は、このツールを選ぶ理由が薄い。導入前に確認すべきは3点。第一に、自分のアプリに組み込む際の実行経路が@ironclad/rivet-coreと@ironclad/rivet-nodeのどちらに当たるかをAPIリファレンスで特定すること。第二に、READMEの対応一覧に載っていないモデルやベクトルDBを使う予定がないか。第三に、app-v1.11.3とv1.25.0というIDEとライブラリで別系統のバージョン番号が並行して進むため、追従する側をどちらに固定するかを決めておくこと。

公式情報源

1. Ironclad/rivet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases