DEV Community

Cover image for Flowiseとは？LLMアプリ・AIエージェント向けオープンソースローコードビルダー
Akira
Akira

Posted on • Originally published at apidog.com

Flowiseとは？LLMアプリ・AIエージェント向けオープンソースローコードビルダー

Pythonで各コンポーネントを手動接続せずにLLMアプリやAIエージェントを作りたいなら、Flowiseを使うとノードベースのキャンバスでワークフローを構築できます。Flowiseはオープンソースのローコードツールで、チャットモデル、ベクトルストア、メモリ、ツールなどをドラッグ＆ドロップで接続し、REST APIとして公開できます。この記事では、Flowiseの基本、チャットフローとエージェントフローの使い分け、ローカル／Dockerでの起動、予測エンドポイントの呼び出し、APIテストの進め方を実装寄りに整理します。LangGraphがコードファーストの選択肢だとすれば、Flowiseはビジュアルファーストの選択肢です。ソースコードはGitHubのプロジェクトREADMEを参照してください。

今すぐApidogを試す

Flowiseとは

Flowiseは、AIエージェントとLLMワークフローを構築するためのオープンソースの生成AI開発プラットフォームです。Apache 2.0ライセンスで公開されており、ローカル実行、自己ホスト、フォークが可能です。

Flowiseの画面

Flowiseの中心はノードベースのキャンバスです。各ノードは次のようなビルディングブロックを表します。

  • チャットモデル
  • ベクトルストア
  • ドキュメントローダー
  • メモリ
  • リトリーバー
  • 外部ツール
  • カスタム関数

これらをキャンバスに配置し、出力と入力を接続することで、データの流れを定義します。フローを保存すると、FlowiseはそのフローをREST APIとして公開します。アプリケーション側は通常のHTTP APIとして呼び出せます。

内部的には、FlowiseはLangChainやLlamaIndexのようなフレームワークのコンポーネントを接続します。チェーン、エージェント、ベクトルストア、リトリーバー、クエリエンジンといった概念に馴染みがある場合、Flowiseのノードも理解しやすいはずです。

違いは実装方法です。コードでクラスをimportして組み立てる代わりに、UI上でノードを接続して構築します。細かい制御は一部失いますが、プロトタイプの速度と、チームで共有しやすい視覚モデルを得られます。

チャットフロー、エージェントフロー、アシスタントの使い分け

Flowiseには主に3つのビルダータイプがあります。最初にどれを選ぶかで設計が変わります。

ビルダータイプ 最適な用途 範囲
アシスタント 初心者向け。指示に従い、ツールを使い、アップロードされたファイルに対してRAGを行うチャットアシスタント 最も狭く、最もガイドされる
チャットフロー 単一エージェントシステム、チャットボット、シンプルなLLMフロー。Graph RAGとリランカーをサポート 単一エージェント
エージェントフロー ブランチ、ループ、ルーティングを備えたマルチエージェントシステムと複雑なオーケストレーション 最も広く、チャットフローとアシスタントのスーパーセット

チャットフロー

チャットフローは、従来のFlowiseフローです。

典型的な構成は次のようになります。

  1. ユーザーの質問を受け取る
  2. 必要に応じてドキュメントやベクトルストアからコンテキストを取得する
  3. LLMにプロンプトを渡す
  4. 回答を生成する
  5. APIレスポンスとして返す

単一エージェントのチャットボットやRAGアプリケーションには、まずチャットフローを使うのが現実的です。

エージェントフロー

エージェントフローは、より広いワークフロー向けです。Flowiseでは、チャットフローとアシスタントのスーパーセットとして扱われます。

次のようなケースではエージェントフローを選びます。

  • 複数のエージェントが役割分担する
  • 条件によって処理を分岐する
  • ループを含むワークフローを作る
  • ルーティング処理が必要
  • 複雑なタスクを段階的に処理する

たとえば「問い合わせ分類エージェント」「検索エージェント」「回答生成エージェント」を分けて連携させる場合は、エージェントフローが適しています。

アシスタント

アシスタントは最もガイドされたオプションです。

指示、ツール、アップロードファイルを指定するだけで、素早くチャットアシスタントを作成できます。複雑なグラフ構造を考えずに動くものを作りたい場合に向いています。

Flowiseでフローを構築する基本手順

Flowiseでチャットフローを作る流れは次の通りです。

  1. 新しいチャットフローを作成する
  2. 左側のパネルからチャットモデルノードを追加する
  3. OpenAI、Anthropic、ローカルモデルなどのプロバイダーを設定する
  4. RAGが必要な場合は、ドキュメントローダーとベクトルストアを追加する
  5. 会話履歴が必要な場合は、メモリノードを追加する
  6. 各ノードの出力を次のノードの入力に接続する
  7. 保存する
  8. チャットパネルで実行結果を確認する

RAGチャットボットなら、最小構成は次のようになります。

User Question
  -> Retriever
  -> Prompt
  -> Chat Model
  -> Answer
Enter fullscreen mode Exit fullscreen mode

会話履歴を持たせる場合は、メモリノードを追加します。

User Question
  -> Memory
  -> Retriever
  -> Prompt
  -> Chat Model
  -> Answer
Enter fullscreen mode Exit fullscreen mode

Flowiseのビジュアルエディターは、式、カスタムコードノード、分岐、ループ、ルーティングロジックもサポートしています。既存ノードだけで足りない場合は、小さなカスタム関数ノードを追加し、残りのオーケストレーションはキャンバス上で管理できます。

Flowiseをローカルで起動する

FlowiseはNode.jsアプリとして動作し、デフォルトではポート3000で起動します。

npmで開始する場合は次のコマンドを実行します。

npm install -g flowise
npx flowise start
# open http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

ブラウザで次のURLを開きます。

http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

再現性のある環境を作りたい場合はDockerを使います。

docker run -d --name flowise -p 3000:3000 flowiseai/flowise
Enter fullscreen mode Exit fullscreen mode

起動確認は次のように行えます。

curl http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Flowiseは自己ホスト型およびエアギャップデプロイメントもサポートしています。データを社内ネットワーク外に出せない環境では、自己ホスト構成が重要になります。

FlowiseのREST予測エンドポイントを呼び出す

フローを保存すると、FlowiseはそのフローをREST APIとして公開します。公式仕様はFlowiseの予測APIドキュメントで確認できます。

すべてのチャットフローとエージェントフローには、次の形式の予測エンドポイントがあります。

POST /api/v1/prediction/{id}
Enter fullscreen mode Exit fullscreen mode

{id}はフローIDです。最小リクエストでは、JSONボディにquestionを含めます。

curl -X POST http://localhost:3000/api/v1/prediction/<flow-id> \
  -H "Content-Type: application/json" \
  -d '{"question": "What are your store hours?"}'
Enter fullscreen mode Exit fullscreen mode

アプリケーションから呼び出す場合も、基本は同じです。たとえばNode.jsでは次のように実装できます。

const response = await fetch("http://localhost:3000/api/v1/prediction/<flow-id>", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    question: "What are your store hours?"
  })
});

const data = await response.json();
console.log(data);
Enter fullscreen mode Exit fullscreen mode

リクエストボディはquestion以外にも対応しています。

  • streaming: トークンストリーミングを有効化
  • overrideConfig: リクエスト単位でフロー設定を上書き
  • history: 過去の会話ターンを指定
  • uploads: 画像や音声などを送信

ストリーミングを有効にすると、Flowiseはstart、token、metadataなどのイベントを発行し、最後にendイベントを返します。

また、Flowiseはこの予測エンドポイントを扱う公式のPython SDKとTypeScript SDKも提供しています。

このエンドポイントが、Flowiseとアプリケーションの境界になります。フロントエンド、バックエンド、他サービスはすべてこのAPIを通じてフローと通信するため、通常のREST APIと同じようにテスト対象として扱うべきです。

ローコードが適するケースとコードファーストが適するケース

Flowiseは次のようなケースに向いています。

  • LLMアプリを素早くプロトタイプしたい
  • 社内向けチャットボットを短期間で作りたい
  • ドキュメントに対するRAGアシスタントを作りたい
  • 非エンジニアも処理の流れを確認できるようにしたい
  • デモやPoCを短いサイクルで改善したい

キャンバス上で処理の流れが見えるため、Pythonファイルだけで説明するよりもチーム内で共有しやすくなります。

一方で、コードファーストのフレームワークが適するケースもあります。

  • エージェントロジックをGitで厳密に差分管理したい
  • 各ステップに細かい単体テストを書きたい
  • 複雑な状態遷移を実装したい
  • 独自の制御フローが多い
  • 本番コードとして長期運用する前提が強い

この場合は、LangGraphやGoogle Agent Development Kitのようなライブラリの方が自由度があります。カスタムツール呼び出しが中心のエージェントでは、OpenAI Agents SDKも選択肢になります。

実務では、次のような進め方が現実的です。

  1. Flowiseでプロトタイプを作る
  2. 必要なノード、ツール、API呼び出しを検証する
  3. 要件が安定したら、一部または全部をコードファースト構成に移す
  4. Flowiseで十分な部分はそのまま運用する

FlowiseにもAPI、CLI、SDKアクセス、トレーシング、評価、ヒューマン・イン・ザ・ループ機能があります。単なるデモツールではありません。ただし、ロジックが本格的なソフトウェアに近づくほど、コードファーストの恩恵は大きくなります。

予測エンドポイントと外部APIをテストする

Flowiseで構築したエージェントの信頼性は、背後で呼び出すAPIの信頼性に依存します。

フローは通常、次のようなAPIを呼び出します。

  • LLMプロバイダーAPI
  • ベクトルデータベースAPI
  • 社内REST API
  • 外部SaaS API
  • カスタムツールAPI

本番で障害になりやすいのは、この境界部分です。ここはApidogでテストできます。

1. Flowiseの予測エンドポイントをテストする

まず、POST /api/v1/prediction/{id}を通常のRESTエンドポイントとして扱います。

テスト観点は次の通りです。

  • 正しいHTTPステータスが返るか
  • レスポンスJSONの構造が期待通りか
  • 回答本文のフィールドが存在するか
  • エラー時のレスポンスが扱える形か
  • overrideConfigなどの追加パラメータが期待通り動くか

たとえば、最小リクエストは次の形です。

{
  "question": "What are your store hours?"
}
Enter fullscreen mode Exit fullscreen mode

Apidogでは、URL、ヘッダー、ボディを設定し、レスポンスに対してAPIアサーションを記述できます。

チェック例は次のようになります。

status code == 200
response body contains expected answer field
response time < threshold
Enter fullscreen mode Exit fullscreen mode

これを自動テストとして実行すれば、フロー変更によるAPI契約の破壊をアプリ側に影響する前に検出できます。

2. フローが依存するAPIを個別にテストする

次に、Flowiseの背後で呼び出されるAPIを直接テストします。

対象は次のようなものです。

  • LLMプロバイダー
  • 社内検索API
  • 商品API
  • チケット作成API
  • CRM API
  • 外部ツールAPI

LLM APIや外部APIは、料金、レート制限、不安定な応答の影響を受けます。開発中に毎回実APIへアクセスしたくない場合は、モックAPIを使います。

たとえば、Flowiseのツール呼び出し先をモックAPIに向けることで、次のことを確認できます。

  • 期待したJSON構造をフローが処理できるか
  • エラー応答時に正しく分岐できるか
  • タイムアウトや空レスポンスに耐えられるか
  • LLMのトークンを消費せずにテストできるか

より詳しいテスト設計は、AIエージェントテストハーネスガイドを参照してください。

3. 環境ごとに認証情報を切り替える

APIテストでは、開発環境と本番環境でキーを分ける必要があります。

Apidogでは環境ごとに変数を設定できます。たとえば次のように分けます。

dev:
  FLOWISE_BASE_URL=http://localhost:3000
  LLM_API_KEY=test-key

prod:
  FLOWISE_BASE_URL=https://your-flowise.example.com
  LLM_API_KEY=real-key
Enter fullscreen mode Exit fullscreen mode

これにより、リクエスト定義を変えずに環境だけを切り替えられます。Apidogをダウンロードすれば、予測エンドポイントのテスト、外部APIのモック、環境変数の管理をまとめて設定できます。

よくある質問

Flowiseは無料ですか、オープンソースですか？

はい。FlowiseはApache 2.0ライセンスのオープンソースソフトウェアです。npmまたはDockerで自己ホストすれば無料で実行できます。インフラを管理したくない場合は、ホスト型クラウドオプションもあります。プライベート環境やエアギャップ環境では、自己ホスト構成によりネットワーク内で運用できます。

FlowiseはLangChainを使用していますか？

FlowiseはLangChainとLlamaIndexの両方のコンポーネントを接続します。キャンバス上のノードは、チェーン、エージェント、ベクトルストア、リトリーバー、クエリエンジンなどの概念に対応します。手動でグルーコードを書かずに、これらのビルディングブロックを利用できます。

チャットフローとエージェントフローの違いは何ですか？

チャットフローは、単一エージェントのチャットボットやシンプルなLLMパイプライン向けです。エージェントフローはそのスーパーセットで、分岐、ループ、ルーティングを含むマルチエージェントシステムに向いています。まずはチャットフローで始め、複数エージェントや複雑な制御が必要になったらエージェントフローに移行します。

FlowiseフローのAPIをテストするにはどうすればよいですか？

questionを含むJSONボディで、次の予測エンドポイントを呼び出します。

POST /api/v1/prediction/{id}
Enter fullscreen mode Exit fullscreen mode

curl、公式SDK、またはAPIテストツールで実行できます。Apidogを使うと、リクエスト送信、レスポンスアサーション、LLMやツールAPIのモック、CIでの自動実行をまとめて扱えます。LLMエンドポイントの認証やストリーミングの詳細は、ApidogでChatGPT APIをテストする方法も参考になります。

まとめ

Flowiseは、LLMアプリとAIエージェントをローコードで構築するための実用的な選択肢です。ノードキャンバスでフローを作成し、チャットフロー、エージェントフロー、アシスタントを用途に応じて選び、REST予測エンドポイントとして公開できます。

プロトタイプ、社内チャットボット、RAGアシスタント、チームで共有しやすいワークフローには特に向いています。一方で、厳密なテスト、細かい状態管理、長期運用のコード管理が必要な場合は、コードファーストのフレームワークも検討すべきです。

どちらの構成でも、最終的な信頼性はAPI境界で決まります。Flowiseの予測エンドポイントをテストし、背後で呼び出すLLM APIやツールAPIをApidogでモック／検証すれば、キャンバス上で動いたエージェントを本番環境でも安定して動かしやすくなります。

Top comments (0)