Flowiseは、単純なFAQを超えて、検索、ツール実行、条件分岐、人への確認を組み合わせるヘルプデスクAIに向きます。公式にはAssistant、Chatflow、Agentflowの3つのビルダーがあり、難易度に応じて選べます。
FLOWISE FOR HELPDESK検索だけで終わらない、調査型サポート
Knowledge → Agent → API Tool → Human Input → 回答
3つの作り方
| ビルダー |
向くケース |
難度 |
| Assistant |
文書に答えるシンプルな担当者 |
低 |
| Chatflow |
検索器やプロンプトを細かく選ぶFAQ |
中 |
| Agentflow V2 |
分岐、ループ、複数Agent、人の承認 |
高 |
メリット／デメリット
メリット
- 高度なRAG部品が豊富
- 処理経路を視覚化
- Human in the Loop
- API・SDK・埋め込み対応
デメリット
- 設計の学習コストが高い
- 自由度が品質を保証しない
- 利用者管理は要件確認が必要
- フロー公開時の保護が必須
基本的な使い方
- まずAssistantで対象文書とモデルの相性を確認する。
- Document Storeへ文書を登録し、チャンクとメタデータを設計する。
- ChatflowでRetriever、Reranker、LLMを比較する。
- API調査や複数段階の切り分けが必要ならAgentflowへ移す。
- Human Input Nodeで送信前承認や追加入力を組み込む。
- Prediction APIまたは埋め込みUIで限定公開する。
推奨Agentflow
分類Agent→Document Store→診断Tool→Human Input→回答
ベストプラクティス
- シンプルな問い合わせにAgentを使いすぎず、決定的なフローを優先する。
- Agentへ渡すツールを最小限にし、説明と入力Schemaを明確にする。
- Retrieval、生成、最終回答を別々に評価する。
- Flow Stateへ個人情報を必要以上に保持しない。
- Human Inputは高リスク処理の直前に置き、承認内容をログへ残す。
- タイムアウト、ループ上限、最大ツール実行回数を設定する。
公開時の重要事項
Flowise公式資料では、構築したflowは初期状態で、Chatflow IDを知る人がEmbedやAPIから実行できると説明されています。必ずフロー単位のAPIキーを割り当て、リバースプロキシでTLS、レート制限、接続元制御を加えます。
参考資料
最終確認日：2026年9月13日