Flock：RustとTauriで作られたデスクトップ型マルチエージェントハーネスの実像

Flockが埋めるのは「チャットUIと実行環境のあいだ」の隙間

多くのLLMクライアントは会話の表示で止まる。エージェントにファイルを読ませ、bashを走らせ、ブラウザを操作させるところまで行こうとすると、実行環境、承認フロー、実行履歴の管理を自前で組むことになる。Flockはこの部分を1つのデスクトップアプリにまとめようとしている。READMEはFlockを「マルチエージェントハーネス」かつ「ビジュアルワークフローエディタ」と位置づけ、ファイル読み書き、bash実行、Web閲覧、パイプライン実行をローカルまたはサンドボックスコンテナ内でオーケストレーションすると説明している。対象読者は、GUIでエージェントの挙動を目視しながら試行錯誤したい開発者だ。CLIで完結する人や、エージェントをライブラリとして自分のサービスに埋め込みたい人には、デスクトップアプリという形自体が余分になる。

クレート分割に見る実行モデル：UIとエージェントエンジンの分離

READMEのアーキテクチャ図は、TauriのデスクトップUI（React + Mantine）とsrc-tauriのコアがIPCで繋がり、そこからJSONプロトコルでflock-agentへ渡る流れを示している。flock-agentがlanggraph-rustのステートグラフを回し、SQLiteのチェックポインタに状態を書き、flock-toolsのツールレジストリ経由でbash、ファイル、grepなどの組み込みツール、MCPサーバー、サンドボックスクライアントを呼ぶ。クレートはflock-core（設定スキーマ、SQLiteモデル、暗号化、IPCチャネル）、flock-agent（実行ループ、状態エンジン、チェックポインタ、メモリ）、flock-workflow（ノードロジックとJSONからLangGraph ASTへのコンパイラ）、flock-tools（ツールとVNC WebSocketプロキシ、サンドボックス管理）、flock-skills（システムプロンプトローダー）に分かれる。注目したいのは、ワークフローがJSONとして保存され、それをflock-workflowがLangGraphのASTへコンパイルする点だ。キャンバス上の図とエージェントの実行グラフが別物にならない設計になっている。

10種類のノードとストリーミング実行が意味するもの

ビジュアルエディタには10種類のノードが同梱される。startとanswerが入出力を定義し、llmは純粋な推論、agentはツール有効のLangGraphエージェントだ。classifierとifelseが意味ベースのルーティングと条件分岐を担い、codeはJS/Pythonのコード実行、humanは手動介入の割り込み、pluginとparameter_extractorがカスタムツールの公開と構造化データ抽出を担当する。READMEはバージョン管理と実行履歴の機能も挙げており、ワークフローの複数バージョン管理と実行パスの追跡ができるとしている。ここで実務上効くのはhumanノードだ。フローの中に承認ポイントを静的に埋め込めるので、ツール承認を毎回のポップアップに頼らず、パイプラインの設計として人間の判断を位置づけられる。ただし10種類という数は、ループやサブグラフ呼び出しのような制御構造をどこまで表現できるかという疑問を残す。READMEからはその範囲が読み取れない。

サンドボックスとVNC：実行の隔離と画面の覗き見

Flockの安全策はサンドボックスコンテナにある。危険なシェルスクリプトやコード実行を隔離環境で行い、そのデスクトップをx11vncとwebsockify経由でWebSocketストリームとしてUIに映す。ブラウザ自動化はPlaywright、OS操作はxdotoolを使い、エージェントがCAPTCHAなどで詰まったときはユーザーがマウスとキーボードを引き継げるとREADMEは説明する。ここは設計上のトレードオフがはっきり出る部分だ。隔離と可視性を得る代わりに、コンテナ実行環境、X11、VNCサーバー、websockifyといった依存をホスト側に用意する必要がある。手元のノートPCで気軽に動かすというより、Dockerなどが動く開発マシンを前提にした構成だと読める。VNCの引き継ぎは強力だが、それは同時に、エージェントの操作が完全に自動で完結しないことを意味する。無人運用を売りにするcronスケジューラと、人間の介入を前提とするVNCが同じ製品に同居している点は、用途の幅を示すと同時に、どちらの運用を主軸に置くか利用者側で決める必要があることを示している。

起動までの手順と、APIキー以外に必要なもの

READMEのQuick Startセクションは提供された範囲では省略されているため、具体的なインストールコマンドはここでは示せない。確認できるのは設定の考え方だ。READMEによれば、外部CLIツールのダウンロードや設定は不要で、OpenAI、Gemini、Anthropic Claude、AWS Bedrock、Ollama（ローカル）のいずれかのAPIキーを貼り付ければすぐ始められるとされている。スキルはYAMLフロントマター付きのプロンプトとして拡張でき、ファイル変更時にホットリロードされるとの記述がある。MCPサーバーは一度接続すれば、すべてのアシスタントとワークフローが新しく公開されたスキーマとツールを継承する。cronは標準的なcron構文をサポートするとされる。ただしこれらはすべてREADMEの記述であり、実際の設定キー名やファイルパスは提供資料からは確認できない。導入を決める前に、リポジトリのQuick Startとcrates/flock-coreの設定スキーマを直接読んで、APIキーの保存先と暗号化の扱いを確認してほしい。

langgraph-rustという単一障害点

Flockはlanggraph-rustの上に建っている。READMEはこれを作者自身によるLangGraphのRust実装だと明記しており、つまりFlockのワークフロー実行能力の上限は、このライブラリの成熟度に直接依存する。Python版のLangGraphと比べてノードやチェックポインタの挙動がどこまで揃っているかは、提供資料からは判断できない。もう1つの制約は出自だ。FlockはもともとPythonのLangGraph、LangChain、FastAPIで書かれたアプリケーションで、現在のRust版はゼロからの書き直しであり、旧コードはlegacy/pythonブランチに保存されている。書き直しは性能と信頼性の改善をもたらすとREADMEは主張するが、その主張を裏付ける数値は示されていない。第三者がエージェントのツール呼び出しやチェックポインタの挙動を調査した資料も、この範囲では見当たらない。基盤ライブラリとアプリの両方を単一の作者が維持している構成は、採用時にサポート体制の観点で意識しておくべき点だ。

代替としてのn8n：汎用ワークフロー自動化との違い

ビジュアルなワークフロー構築という括りでFlockと並べて比較されるのはn8nだ。アプローチはかなり違う。n8nはSaaSやデータベース、HTTPエンドポイントを繋ぐ汎用の自動化ツールで、ノードは外部サービス連携のために用意されている。Flockのノードはエージェントの推論ループを回すために設計されており、llm、agent、classifier、humanといった種類が中心で、ツール承認やSQLiteチェックポインタによる状態管理、サンドボックス内のVNC画面が実行モデルに組み込まれている。つまりFlockは「LLMエージェントを安全に走らせて観察する」ことに特化し、n8nは「既存サービス間のデータを流す」ことに特化している。エージェントのツール呼び出しを人間が承認しながら進めたいならFlockの設計が噛み合う。逆に、既存のSaaS連携を数百ノード規模で組み、セルフホストのサーバーで常時動かしたいなら、n8nの方が土台として素直だ。どちらが優れているという話ではなく、実行したい対象がエージェントかデータパイプラインかで選ぶことになる。

ライセンスと保守コストをどう見るか

FlockはApache-2.0で公開されている。商用利用や改変、再配布が許容される寛容なライセンスで、コピーレフトではない。ただし、同梱されるlanggraph-rustのライセンス条件は別途確認が必要だ。Flock本体がApache-2.0であっても、依存クレートの条件が同じとは限らない。これは法律解釈の話ではなく、依存関係を確認する作業として捉えてほしい。保守コストの面では、v0.3.1が2026年6月17日、v0.3.0が6月3日、v0.2.9が6月2日と、リリース間隔が短い。活発に動いている証拠である一方、破壊的変更が入る可能性もそれだけ高い。RustとTauriのデスクトップアプリを自前でビルドして追従する前提なら問題は小さいが、配布バイナリだけを使って設定を資産化する使い方をするなら、アップグレードのたびに設定スキーマの変更を確認する必要がある。

編集部の結論

Flockが向くのは、エージェントにローカルのファイル操作やbash実行を任せつつ、実行前に承認を挟みたい開発者、そしてワークフローをキャンバス上で組み立てて実行履歴を追いたい人だ。逆に、ヘッドレスなサーバ常駐やCIパイプラインへの組み込みを前提とするチームには、デスクトップアプリという形態がそのまま制約になる。採用前に確認すべきは、同梱のlanggraph-rustが自分のワークフローで必要とするノード種別をカバーしているか、サンドボックスが要求するコンテナとVNC関連の依存を自分の環境で用意できるか、そしてAPIキーやSQLiteの暗号化がどこで行われるかだ。

公式情報源

1. Issues
2. License: Apache-2.0
3. Onelevenvy/flock on GitHub
4. README
5. Releases