riceprompt-engine を YAML ワークフロー実行基盤として読む
YAML-native agent workflow execution engine, written in Rust
ひと目でわかる
- これは何？
- エージェントの処理手順を YAML で宣言し、Rust 側でグラフとして実行するライブラリ。0.1.x の仕様変動と、実行主体を自分で持つ前提の設計をどう評価するか。
- 誰に向いている？
- 既存のアプリやサービスにエージェントの処理手順を組み込み、その手順をコードではなく YAML として管理したいチームに向く。逆に、単発の LLM 呼び出ししかしない場合や、GUI 上でワークフローを組み立てたいだけの場合には、エンジンを直接導入する理由が薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 141 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
YAML を実行単位にするという設計判断
riceprompt-engine が解こうとしているのは、エージェントの処理手順がコードの中に散らばる問題である。README によれば、ノード、エッジ、プロンプト、データソース、MCP ツールをひとつの YAML ファイルに記述し、エンジンがそれを解析して依存関係を解決し、グラフとして実行する。LLM 呼び出し、スクリプト実行、データベース問い合わせ、MCP ツール呼び出し、データの反復、複数エージェントの計画実行までをこのグラフ上で扱うと説明されている。想定読者は、エージェントの手順をアプリケーションコードに直接書き、変更のたびにビルドとデプロイを回している開発者だ。手順を宣言ファイルに切り出せば、差分のレビューと差し替えがコード変更から独立する。README はこのエンジンが RicePrompt というビジュアル IDE を支えているとも書いており、GUI で組み立てたものを同じ YAML として書き出し、エンジン側でそのまま実行する導線が想定されている。
ノード種別が示す処理の粒度
README に列挙されているノード型は、このエンジンが何を「ひとつの処理」とみなすかをよく表している。generate は LLM 呼び出し、transform は Rhai スクリプトによる変換、iterator はデータの反復、supervisor は複数エージェントのルーティング、subgraph はワークフローの入れ子、data_connector は外部データソースへの接続、skill_set は段階的に開示される知識バンドル、mcp と mcp_tools は Model Context Protocol 経由のツール呼び出しである。注目したいのは transform に Rhai が採用されている点で、任意の Rust コードではなく埋め込みスクリプト言語に変換処理を寄せている。ワークフロー定義を配布物として扱いやすくする一方、複雑な文字列処理や外部ライブラリ呼び出しを transform だけで完結させるのは難しい。処理の重い変換は data_connector 側か、呼び出し元の Rust コードに逃がす判断が必要になる。ノードの正確なフィールド定義は docs/FLOW_SPEC.md が正とされており、README だけでは各ノードの設定項目は分からない。
実行の流れと結果の持ち方
実行の入口は Engine で、README の例では Engine::builder().build() でインスタンスを作り、engine.run_yaml(&yaml, json!({ "name": "Ada" })) に YAML 文字列と入力 JSON を渡す。戻り値は ExecutionResult で、serde_json で整形出力できる。README は ExecutionResult がソース YAML を含められる点を挙げ、下流のツールがトポロジーと各ノードの結果をひとつのファイルから描画できると説明している。実行結果と実行定義が同じ構造体に同居するため、実行ログの保存先を別途設計しなくても、どの定義で何が出たかを後から突き合わせられる。ノード間の値の受け渡しは YAML 側の参照で書く。例では generate ノードの variables に name: "start.name" を指定し、テンプレート内で {{name}} として展開している。start ノードの出力が greet ノードの入力になる、という対応を文字列参照で表現する仕組みである。参照名を間違えたときにどの時点で検出されるかは README からは読み取れない。
最小構成のワークフローを動かすまで
依存は Cargo.toml に riceprompt-engine = "0.1" を書く。README の例では version: "1.0" と name を持つ YAML に、providers、nodes、edges、templates の4つを定義する。providers では openai に対して api_key: "${OPENAI_API_KEY}" を設定し、環境変数から鍵を読ませる。ノードは start、generate、response の3つで、generate には provider、model、template、variables を config として渡す。edges で start から greet、greet から response へと向きを指定し、templates 側で user_prompt を書く。Rust 側は tokio の非同期 main の中で YAML をファイルから読み、Engine に渡すだけである。実行には cargo run 相当の手順と OPENAI_API_KEY の設定が要る。README は examples/ 以下に動く例があると述べているが、個々の例の内容までは示していない。プロバイダは OpenAI 以外に Anthropic、Gemini、DeepSeek、Qwen、Zhipu、Moonshot、MiniMax、xAI、Huoshan、および OpenAI 互換の任意のエンドポイントが挙がっている。
0.1.x を本番に置くときの前提
README の Project status は 0.1.x であり、仕様が安定するまでマイナーバージョン間で API が変わりうると明記し、安定性が必要なら正確なバージョンを固定するよう求めている。これは実務上かなり重い制約で、riceprompt-engine = "0.1" のようなキャレット指定のままだと、0.1 系の更新で ExecutionResult の形や run_yaml のシグネチャが動く可能性を許容することになる。Cargo.toml で =0.1.x のように固定し、更新は自分のタイミングで行う運用が素直だ。もう一点、README はユーザー向けの利用ガイド（skill guide）を別途公開すると書いており、執筆時点では docs/FLOW_SPEC.md が唯一の権威ある仕様である。ノード型の追加やプロバイダ固有の挙動を調べるには、この仕様ファイルを読む必要がある。README の Contributing は、YAML の表面に触る変更では同じ PR で docs/FLOW_SPEC.md を更新するよう求めており、仕様ファイルが実装と同時に保守される前提が置かれている。
向かない場面と、代替となる組み合わせ
このエンジンが過剰になるのは、LLM を一度呼んで結果を返すだけの処理である。その場合は公式 SDK を直接呼ぶほうが依存も学習コストも小さい。また、ワークフローの編集自体を GUI で行いたいだけなら、RicePrompt 側を使い、エンジンを直接組み込む必要はない。比較対象として、同じく処理の流れを宣言的に扱う仕組みに LangGraph がある。違いは実行主体の置き方で、LangGraph は Python 側でグラフを組み立てて実行するのに対し、riceprompt-engine は YAML を入力として Rust プロセス内でグラフを実行する。ワークフロー定義を非エンジニアと共有したり、アプリの外にファイルとして置いたりしたいなら後者、処理の途中で任意の Python ライブラリを挟みたいなら前者が素直である。もうひとつの現実的な代替は、YAML を自前の設定として読み、LLM 呼び出しを公式 SDK で順に書く方法だ。ノードが数個で分岐がないうちは、この自前実装のほうが依存を減らせる。分岐、反復、チェックポイント再開、複数プロバイダの切り替えが増えてきた時点で、エンジンに寄せる価値が出てくる。
採用判断で先に確かめること
最初に読むべきは docs/FLOW_SPEC.md である。README が列挙するノード型の名前は分かっても、各ノードが受け取るフィールドや、変数参照の解決規則、エラー時の挙動はこの仕様にしか書かれていない。次に、checkpoint / resume の粒度を確認したい。長時間動くワークフローを止めて再開するとき、どこまでが保存され、再開時に副作用のあるノードが再実行されるのかは、README の一文からは判断できない。データコネクタを使うなら、PostgreSQL、MySQL、MongoDB、Redis、Qdrant、S3 互換ストレージ、REST API のそれぞれについて、認証情報を YAML にどう書くか、資格情報を環境変数に逃がせるかを仕様で確かめる。ライセンスは Apache-2.0 と MIT のデュアルで、README は貢献が明示的に別条件を示さない限り同じデュアルで扱われると述べている。Apache-2.0 側には特許条項があるため、社内のライセンス確認フローに通す場合はどちらを選ぶかを決めておく必要がある。
編集部の結論
既存のアプリやサービスにエージェントの処理手順を組み込み、その手順をコードではなく YAML として管理したいチームに向く。逆に、単発の LLM 呼び出ししかしない場合や、GUI 上でワークフローを組み立てたいだけの場合には、エンジンを直接導入する理由が薄い。導入前に確認すべきは docs/FLOW_SPEC.md のノード定義が自分の用途に足りるか、そして Cargo.toml で riceprompt-engine のバージョンを固定する方針を取れるかである。
コミュニティノート