AgentSwarmsとは｜18種ノードで組むマルチエージェント群制御と、書き出し互換性の実測

「マルチエージェント基盤」を名乗るOSSは毎週のように増えるが、その多くはCLIやSDKで、群の形はコードの中にしか存在しない。AgentSwarms-fyi/agentswarms は違う入口を選んでいる。群の形をキャンバス上のノードグラフとして描き、そのグラフをそのまま実行する。しかも実行の相手は、コードベースではなく自分たちの業務データ（PostgreSQLやSnowflakeなどの接続先）だ。

エージェントの設計思想そのものを俯瞰したい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を先に読むと、AgentSwarmsがどの位置に立つツールなのかが掴みやすい。

AgentSwarmsとは — Supabaseの上に載せる「エージェント＋BI」の自前基盤

AgentSwarmsは2026年7月21日に公開されたリポジトリで、2026年8月3日時点で★38・fork 6という規模である。言語構成はTypeScriptが7,865,907バイトと圧倒的で、次いでPLpgSQL（243,804バイト）、Python（79,132バイト）が続く。PLpgSQLが大きいのは、バックエンドをSupabase（Postgres＋Auth＋Storage）に寄せ、スキーマとRLSをマイグレーションとして持っているためだ。

設計上の特徴は「別建てのバックエンドを作らない」点にある。APIサーバーを自前で立てる代わりに、Supabaseプロジェクトを1つ用意すればそれがバックエンドそのものになる。フロントエンドはTanStack Start（React 19）で、Dockerコマンド1つで起動する構成だ。モデルは持ち込み方式（BYOK）で、OpenRouter・OpenAI・Anthropic・Gemini・Bedrock・Azure・OCI・Qwen・Grok・Groq・Ollama・vLLMなどのキーを自分で設定する。

機能面は「エージェント側」と「データ／BI側」の2枚看板になっている。

・エージェント側：エージェントチャット、swarmキャンバス（本記事の主題）、ナレッジベース（pgvectorによるRAG）、MCPサーバー接続、MCPビルダー、ガードレールと評価、実行トレース
・データ／BI側：22種のDB／DWHへの読み取り接続、データカタログ、セマンティックレイヤー、ドラッグ&ドロップのBIダッシュボード、スケジュール更新、行レベルセキュリティ付きの共有

この2枚看板が同じ製品に同居しているのが、他のマルチエージェント基盤との一番大きな違いだ。エージェントが触る対象が「コードベース」ではなく「業務データ」に寄っている。

数字を出すAIで一番困るのは「その値がどこから来たのか分からない」ことだが、生成SQLを併記して検算できる形にしているのは素直に良い設計だと感じる部分である。

swarmキャンバスの18種ノード — LLMを呼ぶ7種と、呼ばない11種

ここからが本題だ。「swarm（群）」を名乗るツールは多いが、群制御の具体は結局「どんな部品でグラフを組めるか」に尽きる。AgentSwarmsのキャンバスに置けるノードの種類を、レンダラの登録テーブル（src/routes/_authenticated/swarms.tsx）から数えると18種ある。

そして重要なのは、この18種が一様ではないことだ。ノード設定パネル（src/components/swarms/NodeInspector.tsx）を読むと、プロバイダ／モデルの選択欄が表示されるノードは限られている。

18種のうち、モデルを呼ぶのは7種、呼ばないのが11種という配分になる。これは群制御を考えるうえで示唆的な数字だ。「マルチエージェント」と言うと全ノードがLLMで判断しているような印象を受けるが、実際に組んでみると、グラフの骨格を作っているのはモデルを呼ばない決定論的なノードのほうが多い。分岐や反復をLLMに任せると挙動が揺れるので、揺らしてよい場所とそうでない場所を分ける設計になっている、と読める。

実行エンジン側（src/utils/swarmExecute.server.ts、1,019行）を確認すると、この18種すべてに対する処理分岐が存在する。つまりキャンバスに置けるノードは、すべて実行される。描けるが動かない飾りのノードは無い。

実行の骨格 — チェックポイントと承認待ち

群の実行で効いてくるのが approval ノードとチェックポイントの組み合わせだ。README上は「デプロイされた実行は進行に応じてチェックポイントを取るため、再起動やデプロイをまたいでも実行が生き残る」「人間承認ステップは実行を保留する」と説明されている。リポジトリ側にも supabase/migrations/20260755000000_swarm_run_checkpoints.sql や 20260724100000_swarm_approvals_and_runs.sql といったマイグレーションが実在し、承認と実行の状態がDBに持たれる設計であることが確認できる。

「途中で人間に止められること」と「途中で落ちても再開できること」は、業務データに触るエージェントでは機能というより前提条件に近い。そこがDB側のテーブルとして設計されているのは、キャンバスUIの見た目以上に地味に重要な部分だと思う。

他フレームワークへの書き出しを実測した — LangGraph・CrewAI・OpenAI Agents SDK・Strands

READMEには「swarm export to LangGraph/CrewAI/OpenAI SDK/Strands」と書かれている。ここが本記事で一番確かめたかった点だ。キャンバスで組んだ群は、他のフレームワークへ本当に持ち出せるのか。

エクスポータは src/lib/ 配下に実装されており、buildLangGraphPythonSwarm など6つの生成関数がある。いずれもグラフのJSON（PortableSwarm）を受け取って文字列を返す純粋関数なので、プラットフォームを起動しなくても単体で動かせる。そこで18種すべてのノードを1本のグラフに並べ、6つの書き出しを実行して、生成コードに何が残るかを数えた。

エージェント中心の3フレームワークでは、agentだけが残る

CrewAI・OpenAI Agents SDK・Strandsの出力では、実行されるコードになるのは agent ノードだけだった。他の制御ノードはコード化されず、次のようなコメントとして列挙される。

CrewAI向けの出力に実際に現れたのは、Agent(...) と Task(...) の定義が1組と、「このswarmにはこのフレームワークへ直接マップできない制御フローノードもあります。手動で繋いでください」という注記に続く condition / loop / approval / a2a_remote / function / evaluate の6種の名前だった。そして残り11種は、名前すら出力に残らない。

これは実装の手抜きというより、フレームワーク側の表現力の差から来る構造的な帰結だ。ソースコードのコメントにも、その事情と対処が明記されている。CrewAI等は「agent」という概念しか持たないため、Researcher → [condition] → Writer のような経路は、素直に変換すると両端のエッジが両方とも失われて Writer が孤児ノードになってしまう。そこで bridgeAgentEdges() という関数で、非対応ノードを通り抜けて両側のagentを繋ぎ直し、途中で省略されたノードを記録して、その場所にコメントとして名前を出す——という作りになっている。

LangGraphでは18種すべてが「登場」するが、グラフに追加されるのは6種

一方LangGraphは、状態グラフという抽象がAgentSwarmsのキャンバスとほぼ同じ形をしているため、事情が異なる。ソースコードのコメントにも「LangGraph can represent every node kind, so it exports the graph verbatim（LangGraphはすべてのノード種別を表現できるため、グラフをそのまま書き出す）」と書かれている。

実際、18種すべてのノード名が生成ファイルのどこかには登場する。だがグラフに追加される（add_node() が呼ばれる）のは6種だけだった。ノードを1種類ずつ「agent → 対象ノード → agent」の形で挟んで書き出し、生成コードでの扱いを分類すると次のようになる。

最後の9種が問題になる。add_node() されていないノードに対して add_edge() だけが書かれるため、生成されたPythonはグラフを構築できない。

これは推測ではなく、実際に確認した挙動である。input → agent → tool → agent → output というごく普通の5ノード構成（agent間にツール実行を1つ挟んだだけ）を書き出し、生成されたPythonをLangGraph 1.2.10で実行すると、次のように落ちる。

Traceback (most recent call last):
  File "realistic.py", line 78, in <module>
    app = graph.compile()
  File ".../langgraph/graph/state.py", line 1127, in validate
    raise ValueError(f"Found edge starting at unknown node '{source}'")
ValueError: Found edge starting at unknown node 'WebSearch'

興味深いのは、リポジトリ自身がこの種の不具合を既に知っていることだ。エクスポータのソースには次の趣旨のコメントが残っている——「以前は無視されていた種別。これらが無いと、その種別に出入りするエッジが、追加されていないグラフノードを参照してLangGraphのコンパイルエラーになる。だからトポロジーを保つために実行可能なパススルーのスタブを出している」。つまり evaluate / function / a2a_remote の3種については同じ問題が起きていて、すでに修正されている。残る9種には、その修正がまだ適用されていない、という状態だ。

「実行可能なSTARTER」という但し書きをどう読むか

公平を期すために書いておくと、生成ファイルのヘッダには最初から但し書きが入っている。要点は「これは1:1のコピーではなく実行可能な出発点である」「ツールの中身はスタブ」「ナレッジベース／RAGの検索は接続されていないので自分のretrieverを繋げ」「ガードレールとメモリ設定は再現されない」「条件分岐とループ本体はTODOスタブ」の5点だ。加えて「ここに出るモデルIDはAgentSwarms AI Gatewayの名前であり、各プロバイダの公開モデル名と一致するとは限らない」という警告も出力される。

期待値の設定としては誠実だと思う。ただし「実行可能な（runnable）出発点」という表現に限って言えば、上記の9種のいずれかを含むグラフでは文字通りには成り立たない。移行の下書きとして設計意図を運ぶ用途——ノードの並びとプロンプトを新しいフレームワークへ持っていく足がかり——と捉えるのが、現時点の実装に対する正確な期待値だろう。

なお、この結果は2026年8月2日時点のコミット（0924572）に対する計測である。公開から2週間足らずのプロジェクトなので、この部分は今後変わる可能性が高いことは付け加えておきたい。

接続先とデータ面 — 22のDB/DWHとナレッジベース

エージェント側と並ぶもう一枚の看板がデータ接続だ。READMEは「22 databases and warehouses」と書いているが、この数字は型定義（src/utils/warehouse/types.ts）の WarehouseProvider union から数え直しても22件で一致した。

内訳は、PostgreSQL・MySQL・MariaDB・Microsoft SQL Server・Oracle・Redshift・Snowflake・Databricks・BigQuery・Azure Synapse・Trino・Athena・ClickHouse・CockroachDB・TimescaleDB・AlloyDB・Greenplum・YugabyteDB・SingleStore・StarRocks・Apache Doris・PlanetScaleである。Postgres互換が多めだが、Snowflake・Databricks・BigQueryといった主要DWHが一通り揃っている。接続は読み取り専用で、認証情報は暗号化して保存される。

これに加えて、Google Sheets・Stripe・Shopify・HubSpot・Salesforceの5つがスケジュール取り込み型のデータソースとして用意されており、合計27コネクタというREADMEの表現になる。

ナレッジベースはpgvectorによるRAGで、ドキュメントをアップロードしてチャンク化・埋め込みを行い、エージェントの根拠として使う。secretsマネージャがあり、認証情報を一度登録すればウェアハウス接続やプロバイダキーから参照名で呼び出せる（値そのものは書き込み専用で読み出せない）。

開発者向けにはPythonノートブックのワークスペースがあり、サンドボックス化されたサーバーカーネル上で langchain / langgraph / llama_index が実際に動く。設計として面白いのは、モデル呼び出しとナレッジベース検索をプラットフォーム側が仲介するため、サンドボックス内にプロバイダキーが一切存在しない点だ。ノートブックから自分のエージェントやswarmを呼び出すこともでき、ノートブック自体をAPIとして公開することもできる。

もう一つ、エージェントチャットから編集可能なPowerPoint・Word・Excelを生成する機能がある。Excelは値を貼り付けたスナップショットではなく、全行を数式付きで引ける形で出力できるとされている。この機能はサーバー側レンダラ（--docgen オプション）を有効にした場合に使える。

インストール手順 — SupabaseプロジェクトとDockerで起動する

導入で最初に理解しておくべきなのは「別建てのバックエンドは作らない」という前提だ。Supabaseプロジェクトを1つ作り、そのキーを .env に入れる。あとはスクリプトが依存関係・マイグレーション・スタック起動まで面倒を見る。

公式のセットアップスクリプトを使う場合はこうなる。

cp .env.example .env      # Supabaseキーを記入してから実行する
bash scripts/setup.sh                 # Dockerスタック → http://localhost:8080
# bash scripts/setup.sh --dev         # ローカル開発サーバーで起動する場合
# bash scripts/setup.sh --docgen      # PowerPoint/Word/Excel のサーバー側レンダラも起動
# Windows PowerShell: powershell -ExecutionPolicy Bypass -File scripts\setup.ps1

手動で進める場合は、クローンして依存関係を入れ、スキーマを一度だけ適用する流れになる。

git clone https://github.com/AgentSwarms-fyi/agentswarms.git
cd agentswarms
npm install
cp .env.example .env   # Supabaseキーとプロバイダキーを記入
# データベーススキーマを一度だけ適用する
npx supabase login && npx supabase link && npx supabase db push
npm run dev            # → http://localhost:8080

VPSやFly・Railway・Render・Kubernetesなど、Nodeが動くホストへ載せる場合はDocker Composeで起動する。

cp .env.example .env   # Supabaseキーを記入し、マイグレーションを一度適用しておく
docker compose up --build
# → http://localhost:8080

動作要件はNode.js 20.19以上。公式のシステム要件では2 vCPU / 4GBのVMで足り、GPUは不要とされている。モデルは外部プロバイダのAPIを叩くので、ローカル推論用のリソースが要らないという構成だ。インスタンス全体で使うOpenRouterキーを1つ設定しておけば、そのインスタンスの利用者は各自の設定なしで使い始められる。

類似ツールとの違い — ruflo・TAKT・Langflowとの棲み分け

「マルチエージェント」というくくりは広すぎるので、何を対象に群を組むのかで並べると輪郭がはっきりする。

同じ「群」でも、ruflo｜Claude Code/Codexにネイティブ統合する100エージェント・スウォーム基盤が相手にしているのはコードベースであり、開発者のローカル環境で動く。AgentSwarmsが相手にしているのは業務データで、動く場所はチームで共有するサーバーだ。同じ言葉で呼ばれていても、使う人も置き場所も違う。

工程の統制という観点では、TAKTとは｜AIコーディングエージェントの工程をYAML状態機械で統制するCLIの仕組みと使い方を徹底解説がYAMLで状態機械を書くのに対し、AgentSwarmsはGUIのグラフで同じことをする。テキストで書けばdiffが読めてレビューに乗るし、GUIで描けば非エンジニアにも見える。どちらが優れているという話ではなく、チームの構成で選ぶところだと思う。

見た目が最も近いのはLangflow 使い方・とは｜ノーコードでAIエージェント・RAGワークフローを構築するチュートリアル2026で、どちらもノードキャンバスでフローを組む。違いは射程で、Langflowが汎用のLLMアプリ構築なのに対し、AgentSwarmsは接続先DBとBIダッシュボードまでを1つの製品に含んでいる。データ分析の文脈で使うなら、後者は最初から必要な部品が揃っている。

なお、自然言語からSQLを作る用途に絞るならWrenAI、SQLクライアントとして使うならChat2DBのほうが専門的で、機能の深さでは分がある。AgentSwarmsの強みは個々の機能の深さではなく、エージェント・データ・ダッシュボードが1つの製品に載っていて自前インフラに置けることにある。

ライセンスと成熟度 — Elastic License 2.0とv0段階で気をつけること

導入判断で先に押さえるべきはライセンスだ。AgentSwarmsはElastic License 2.0（ELv2）で、OSI承認のオープンソースではなくsource-availableである（GitHubのライセンス判定は「NOASSERTION」と表示される）。READMEも一貫して「source-available」と書いており、OSSを名乗ってはいない。

ELv2の中心的な制限は1つで、「ソフトウェアの実質的な機能群を利用者に提供するホスティング／マネージドサービスとして第三者に提供してはならない」というものだ。自社で立てて自社で使う分には引っかからず、これをそのままSaaSとして他社に売る場合に効く。リポジトリ内の説明ページには、別途の商用ライセンスが用意されている旨の記載もある。

ELv2にはもう1つ「ライセンスキー機能を回避・無効化してはならない」という条項があるが、これはELv2の定型文である。リポジトリ全体を検索した限り、license key という文字列はLICENSE本文と、製品内のライセンス説明ページ（src/routes/license.tsx / src/routes/terms.tsx）にしか現れず、ライセンスキーを検査する実装は見当たらなかった。現時点で機能が鍵で制限されている様子はなく、実質的に効いてくるのは前述のホスティング条項のほうだと考えてよさそうだ。

逆に言えば、この規模のプロジェクトでチェックポイント・人間承認・IAM・行レベルセキュリティ・監査ログといった「運用側の部品」が最初から設計に入っているのは珍しい。MCPビルダーでは、再デプロイでツール名・説明・スキーマのいずれかが変わった場合に再承認するまで呼び出しをブロックする仕組み（いわゆるrug pull対策）まで用意されている。方向性としては、実験用ではなく運用を前提に置いた作りを目指しているように見える。

まとめ — AgentSwarmsで「群を描ける」ことと「群を持ち出せる」ことは別の話

AgentSwarmsを一言でいえば、業務データに接続されたエージェント基盤を自前インフラに丸ごと載せるための製品である。18種のノードでグラフを描き、そのグラフがそのまま実行され、チェックポイントと人間承認が付いてくる。データ接続からダッシュボードまで同じ製品に入っているので、データ分析の文脈では最初から部品が揃っている。

導入を検討するなら、判断の順序は「機能の一覧」ではなく次の3点で見るのが早い。第一にライセンスで、自社利用なら問題になりにくいが、これを外部へサービスとして提供する計画があるならELv2のホスティング条項が先に効く。第二に置き場所で、Supabaseプロジェクトを1つ用意できるか、チームで共有するサーバーを持てるかが前提になる。第三が本記事で測った移行性で、将来的に別のフレームワークへ移す想定があるなら、書き出し機能を保険と見なさないほうがいい。

ただし本記事で実測したとおり、「他フレームワークへ書き出せる」という機能は、設計の下書きを運ぶものであって、動く群をそのまま移植するものではない。LangGraphで6種、CrewAI系で1種——この数字を知ったうえで使えば期待を裏切られることはないし、逆にここを移行の保険と見込んで採用を決めると、後で困ることになる。群を「描ける」ことと「持ち出せる」ことは、実際に書き出してみるまで区別がつかない。

参照ソース

・AgentSwarms-fyi/agentswarms（公式リポジトリ・README） — 機能一覧・クイックスタート・自己ホスト版とホスト版の対比（2026-08-03閲覧）
・LICENSE（Elastic License 2.0 全文） — ホスティング提供の禁止条項とライセンスキー条項（2026-08-03閲覧）
・docs/INSTALL.md（公式インストール手順） — macOS/Linux/Windowsの導入手順とトラブルシュート（2026-08-03閲覧）
・docs/SYSTEM_REQUIREMENTS.md（公式システム要件） — 2 vCPU / 4GB・GPU不要の記載（2026-08-03閲覧）
・Elastic License 2.0（Elastic公式ライセンス本文） — ELv2の原文（2026-08-03閲覧）