【2026年最新】Flowise AgentFlow V2 完全ガイド

「Flowiseは試したことあるけど、AgentFlow V2に切り替えていいのか判断できない」

検証環境でV1とV2を比べてみた結果、設計思想がかなり異なることが分かりました。V1はLangChainやLangGraphのコンポーネントをUIで扱う「ラッパー」という性格が強かったのに対し、V2はFlowise自身がネイティブノードを提供する「独立したオーケストレーター」として設計されています。

この記事では、AgentFlow V2の14種ノード仕様、Supervisor/Workerマルチエージェントの実装手順、Difyとの用途別比較を、公式ドキュメントとGitHub情報をもとに整理します。Flowise v3.1.2（2026年4月14日リリース）時点の情報です。

結論ファースト：用途別おすすめ早見表

用途・状況	おすすめ	理由	料金目安（セルフホスト）
RAGチャットボットを最速で動かしたい	Flowise	軽量・すぐ起動・ノーコード	無料（インフラのみ）
マルチエージェントをビジュアルで設計したい	Flowise AgentFlow V2	14ノードで柔軟なフロー構築	無料（インフラのみ）
チーム複数人で本番RAGを管理したい	Dify	ユーザー管理・ワークスペース完備	RAM 4GB以上のサーバーが必要
ワークフロー自動化と組み合わせたい	n8n + Flowise	n8n MCP連携でトリガーを柔軟に設定	各インフラコストによる
LLMアプリの高度なモニタリングが必要	Dify	ノード単位の実行ログ・トークン消費を可視化	RAM 4GB以上のサーバーが必要

料金情報の最終確認: 2026-06-11。最新は各公式サイトで確認してください。

Flowiseとは何か — GitHubスター5万3,000超のOSS

Flowiseは「ビジュアルキャンバスでAIエージェントを構築する」オープンソースプラットフォームです。Node.jsで動作し、LangChain・LlamaIndexのコンポーネントをドラッグ&ドロップで組み合わせられます。

2026年6月時点でGitHubスター数は5万3,500以上（フォーク2万4,500以上）。最新の安定バージョンはv3.1.2（2026年4月14日リリース）です。

セルフホスト版は完全無料で使えます。クラウド版はFree（月0ドル・2フロー・月100予測）、Starter（月35ドル・無制限フロー・月1万予測）、Pro（月65ドル・月5万予測）の3プランが用意されています（2026年5月時点）。

セルフホストで起動する（3ステップ）

以下はローカル環境での起動手順です。Node.js 18以上が必要です。

# Node.js 18以上がインストール済みであることを確認
node --version

# npmでFlowiseをグローバルインストール
npm install -g flowise

# 起動（デフォルトでポート3000）
npx flowise start

動作環境：Node.js 18以上、npm 8以上。
アクセス：http://localhost:3000 でダッシュボードが開きます。

注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。本番ではデータベースの永続化設定（SQLiteまたはPostgreSQL）を行うことを推奨します。

AgentFlow V2 — アーキテクチャ変更の本質

V2が「根本的な変化」と呼ばれる理由は、外部フレームワーク依存の排除にあります。

V1とV2の設計思想の違い

項目	AgentFlow V1（廃止予定）	AgentFlow V2（現行）
基盤アーキテクチャ	LangChain/LangGraph依存	Floise独自ネイティブノード
ノード設計	外部ライブラリのラッパー	独立した専用コンポーネント
フロー制御	フレームワーク任せ	明示的な接続・実行キュー
データ共有	ノード間連携が複雑	Flow Stateで統一管理
Human-in-the-loop	標準サポートなし	Human Input Node標準搭載
マルチエージェント	Sequential/Multi-Agents（LangGraph依存）	Agent Node + Supervisor構成

公式ドキュメントでは「V1はDeprecating（廃止予定）」と明記されており、新規構築はV2を使うことが推奨されています。

実行キューとノード依存関係

V2では各ノードが「独立したユニット」として動作します。ノード間の接続がそのまま実行順序を定義するため、コードを書かなくても実行フローが視覚的に明確になります。複数の接続パスがある場合は、依存関係に基づいた実行キューが自動で管理されます。

14種のネイティブノード — 役割と使い分け

V2のキャンバスで使えるノードは以下の14種類です（公式ドキュメントより）。

ノード名	役割	主な使い所
Start Node	ワークフローの入口・Flow State初期化	全フロー共通（必須）
LLM Node	LLMを直接実行（ツール選択なし）	テキスト生成・要約・翻訳
Agent Node	自律的な推論とツール選択	調査・検索・API連携を含むタスク
Tool Node	特定ツールの決定的実行	常に同じ処理を実行したい場合
Retriever Node	ドキュメントストアから情報検索	RAGパイプライン
HTTP Node	外部API連携	REST APIコール・Webhook送信
Condition Node	ルールベースの条件分岐	スコア閾値・フラグ判定
Condition Agent Node	AI駆動型の動的分岐	文章の意図・感情に応じた分岐
Iteration Node	配列要素に対するループ処理	リスト内の複数アイテムを順次処理
Loop Node	前のノードへの後退実行	品質チェック通過まで繰り返す処理
Human Input Node	ユーザー入力の要求（実行一時停止）	承認フロー・確認ステップ
Direct Reply Node	最終応答を返して終了	回答生成後の終端
Custom Function Node	JavaScriptコードを実行	データ変換・カスタムロジック
Execute Flow Node	別ワークフローを呼び出し	サブフローの再利用

Flow State：ノード間データ共有の仕組み

V2のFlow Stateは「実行時のキー・バリューストア」です。Start Nodeで初期変数を初期化し、後続ノードから読み書きできます。

// Start Nodeでの Flow State 初期化（設定画面のイメージ）
{
  "flow_state": {
    "research_result": "",
    "confidence_score": 0,
    "approved": false
  }
}

後続ノードでの参照は {{ $flow.state.research_result }} という構文で行います。条件分岐（Condition Node）の判定条件にも使えるため、エージェント間でデータを受け渡す際に便利です。

Supervisor/Workerマルチエージェントを構築する

AgentFlow V2の最大の特徴が、Supervisor/Workerパターンのビジュアル構築です。Supervisorエージェントがタスクを判断・委譲し、複数のWorkerエージェントが並行して実行する構成を、コードなしに設計できます。

基本的な構成イメージ（擬似コード）

# マルチエージェント構成のフロー定義イメージ（YAML表現）
flow:
  - Start Node:
      flow_state:
        task: ""
        result_web: ""
        result_doc: ""

  - Agent Node (Supervisor):
      model: gpt-4o
      role: "タスクを分解し、Web調査とドキュメント検索の2つのWorkerに委譲する"
      outputs:
        - to: Agent Node (Worker A)
        - to: Agent Node (Worker B)

  - Agent Node (Worker A - Web調査):
      tools: [Web Search Tool]
      output_state_key: result_web

  - Agent Node (Worker B - ドキュメント検索):
      tools: [Retriever Node]
      output_state_key: result_doc

  - LLM Node (集約):
      input: "{{ $flow.state.result_web }} + {{ $flow.state.result_doc }}"
      role: "2つの結果を統合して最終回答を生成する"

  - Direct Reply Node

実際のキャンバス操作では、各ノードをパレットからドラッグして配置し、アウトプットポートとインプットポートを線で繋ぐだけです。

ステップバイステップ構築手順

以下の手順でSupervisor/Workerフローを構築できます。

# 手順1: Flowiseを起動してAgentFlow V2を選択
npx flowise start

# ブラウザで http://localhost:3000 を開く
# 「+ Add New」→「AgentFlow V2」を選択

1. Start Nodeを配置: キャンバス左上にドラッグ。「Flow State」タブで初期変数（research_result, confidence等）を設定する。
2. Supervisor Agent Nodeを追加: Start Nodeの右に配置し、使用するLLM（GPT-4o、Claude 3.7 Sonnetなど）を選択。ロールプロンプトでSupervisorとしての振る舞いを定義する。
3. Worker Agent Nodeを2つ追加: SupervisorのアウトプットポートからWorker A・Worker Bへ線を引く。各Workerに必要なツール（Web検索、Retriever等）を設定。
4. 集約用LLM Nodeを配置: 両WorkerのアウトプットをLLM Nodeに接続。プロンプトで「2つの入力を統合して回答生成」と指示。
5. Direct Reply Nodeで終端: LLM Nodeの出力をDirect Reply Nodeに接続して完成。

Human-in-the-loopの組み込み方

承認フローが必要な場合は、Supervisor Nodeと集約LLMの間にHuman Input Nodeを挿入します。

// Human Input Nodeの設定イメージ（JavaScriptでのAPI連携確認用）
// 実際の設定はFlowise UIのノード設定画面から行います

const humanInputConfig = {
  message: "調査結果を確認してください。処理を続けますか？",
  // ユーザーの選択肢（yes/no）に応じて異なるパスに分岐
  options: ["承認して続行", "中止"],
  timeout: 3600  // 秒（1時間）
};

// チェックポイントが保存されるため、
// アプリ再起動後も同じポイントから再開可能

ポイント：Human Input Nodeは実行スレッドをブロックせずに待機します。ユーザーが応答するまでチェックポイントが保存されるため、長時間のワークフローでも途中から再開できます。

よくある失敗パターンと回避策

失敗1：Flow Stateの初期化を忘れる

❌ Start Nodeで変数を未定義のまま後続ノードから参照しようとする
⭕ Start Nodeの「Flow State」タブで使用する全キーを宣言してから構築を始める

なぜ重要か：未定義キーへのアクセスはノードエラーになり、フロー全体が停止します。先に型と初期値を定義する習慣が重要です。

失敗2：SupervisorにWorkerを接続せずにデプロイする

❌ Agent NodeをSupervisorとして設定したが、Workerへの接続線を引いていない
⭕ キャンバスで接続を視覚的に確認してからテスト実行する

なぜ重要か：接続なしのSupervisorは単独のエージェントとして動作するため、委譲パターンが機能しません。V2は「明示的な接続」が実行フローを定義するため、線の確認が必須です。

失敗3：LLM NodeとAgent Nodeの使い分けを誤る

❌ ツール使用が不要な要約タスクにAgent Nodeを使う（不要な推論コストが発生）
⭕ ツール選択が必要な場合のみAgent Node、固定処理はLLM Node/Tool Nodeを使う

なぜ重要か：Agent Nodeはツール選択のための追加トークンを消費します。固定処理にはLLM Nodeが適切で、コストと速度を最適化できます。

失敗4：本番でSQLiteのみ使用してデータを失う

❌ デフォルト設定のSQLiteのまま本番運用し、コンテナ再起動でフロー設定が消える
⭕ 本番環境ではPostgreSQLを設定し、外部ストレージとの永続化を確保する

# PostgreSQL接続の環境変数設定例
export DATABASE_TYPE=postgres
export DATABASE_HOST=your-db-host
export DATABASE_PORT=5432
export DATABASE_NAME=flowise
export DATABASE_USER=flowise_user
export DATABASE_PASSWORD=your_password

# Flowiseを起動
npx flowise start

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

Dify vs Flowise — 用途別選択ガイド

FlowiseとDifyはどちらも「ノーコードでLLMアプリを構築するOSS」ですが、設計思想が異なります。ここでは2026年時点の両者を比較します。

機能比較表

項目	Flowise	Dify
言語・フレームワーク	Node.js（TypeScript）	Python + Next.js
最低メモリ要件	1GB RAMでも動作	4GB RAM推奨（8GB以上を推奨）
RAG機能	基本的なRetrieverノード	マルチ検索・ハイブリッド・リランク等高度なRAG
チーム管理	シングルインスタンス向け（V1比較）	ユーザーロール・ワークスペース完備
デバッグ機能	基本的なログ表示	ノード単位の実行時間・トークン消費を可視化
マルチエージェント	AgentFlow V2でビジュアル構築	ワークフローエディタで構築
API公開	Predictions APIとして自動公開	API Endpoint管理画面あり
セルフホスト難易度	低（npx一発起動）	中（Docker Compose推奨）

情報の参照先：Flowise公式ドキュメント、Dify vs Flowise 2026（Use Apify）。最終確認: 2026-06-11。

どちらを選ぶか — 3つの判断軸

軸1: チームの規模
個人・小規模チームでの実験的なRAGチャットボット、マルチエージェントプロトタイプには Flowise が適しています。部門横断の複数開発者が並行して作業し、ロール管理が必要な場合は Dify が候補になります。

軸2: インフラの制約
RAM 1GBの小さなVPSやローカルPC（M1/M2 Mac含む）では Flowise が動作します。Dify はRAM 4GB以上のサーバーを推奨しているため、インフラコストがかかります。

軸3: RAG要件の高さ
ドキュメントのカスタムチャンク・ハイブリッド検索・リランキングなど高度なRAGが必要なら Dify の方が機能が充実しています。基本的なドキュメント検索と回答生成で十分なら Flowise のRetriever Nodeで対応できます。

n8n連携でFlowiseを強化する

FlowiseはAPIエンドポイントを自動公開するため、n8nのHTTP Requestノードから呼び出せます。また、MCPサポートも追加されており、外部エージェントからFlowiseのフローをツールとして呼び出すことも可能です。

// n8nからFlowiseの予測APIを呼び出す設定イメージ
// n8nのHTTP Requestノードの設定値

const flowiseApiCall = {
  method: "POST",
  url: "http://your-flowise-host:3000/api/v1/prediction/YOUR_FLOW_ID",
  headers: {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json"
  },
  body: {
    "question": "{{ $json.input_text }}"
  }
};

// レスポンス: { "text": "...", "sourceDocuments": [...] }

n8nとの組み合わせについては、n8n MCPでAIエージェントワークフローを構築するガイドも参考になります。

マルチエージェント設計パターンとの接続

AgentFlow V2のSupervisor/Workerパターンは、Orchestrator/Workerパターンの具体的な実装手段のひとつです。より大きな設計観点から整理したい場合は、マルチエージェント設計パターン（Orchestrator/Worker）完全解説を合わせて読むと体系的に理解できます。

参考・出典

• Agentflow V2 | FlowiseAI 公式ドキュメント — FlowiseAI（参照日: 2026-06-11）
• FlowiseAI/Flowise — GitHub — FlowiseAI（参照日: 2026-06-11、v3.1.2）
• Dify vs Flowise: Self-Hosted LLM App Platform Comparison (2026) — Use Apify（参照日: 2026-06-11）
• Flowise 公式サイト — 料金プラン — FlowiseAI（参照日: 2026-06-11）
• Agentflow V1 (Deprecating) | FlowiseAI — FlowiseAI（参照日: 2026-06-11）

まとめ：今日から始める3つのアクション

1. 今日やること：npm install -g flowise を実行してローカルで起動し、AgentFlow V2のキャンバスでStart Node + Agent Nodeを配置してみる
2. 今週中：Supervisor/WorkerパターンでシンプルなWebリサーチ + 要約フローを構築し、Flow Stateによるデータ受け渡しを体感する
3. 今月中：Human-in-the-loopを組み込んだ承認フローを本番ユースケースに適用し、PostgreSQL永続化を設定して安定運用に移行する

---

あわせて読みたい：

• DifyでノーコードのAIエージェントを構築するガイド — FlowiseとDifyを実際に比較したい方向け
• マルチエージェント設計パターン（Orchestrator/Worker）完全解説 — 設計レイヤーを体系的に理解したい方向け

---

---

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人以上。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。SoftBank IT連載執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

あわせて読みたい

• ▸ Mistral Agentic Search｜精度3倍の理由【2026年】
• ▸ AIが実験ロボットを操作｜Anthropic「MHS」始動
• ▸ MCPロードマップ2026解説｜脱ポーリングと認証標準化へ
• ▸ Notion Agent APIの使い方｜Sessions実装4手順
• ▸ PM向けAIエージェント活用ガイド2026｜PRD・Jira運用を任せる方法