Dify・Langflow・Flowise比較 Flowise終了後の選び方と案件票の読み方
2026年9月時点で新しく学ぶ、または案件で採用する候補はDifyとLangflowの2つです。Flowiseは公式に運営終了が告知され、GitHubリポジトリはアーカイブされました。社内向けの業務アプリやRAGならDifyが扱いやすい選択です。顧客ごとにワークスペースを分けて渡すSaaSにするなら、Difyの書面許諾を確認するか、MITライセンスのLangflowを検討します。Pythonで独自の部品を作るならLangflowです。
案件の単価は、ツール名よりも担当範囲で差がつくと読むほうが安全です。以下では、選択を変える条件と、案件票で見る行を順に示します。
2026年9月時点の前提：Flowiseは比較の対象から「移行の対象」に変わった
FlowiseのコアチームはGitHub Discussion #6727で、次の対応を告知しました。
- 新機能の開発はただちに停止する
- リポジトリをPublic Archiveに移し、issueとPRをロックする
- npmパッケージとDockerイメージを非推奨にする
- コアチームによるDiscordとGitHubでの対応を終了する
GitHub上では、リポジトリは2026年8月13日にアーカイブされたと表示されています。公式のクローズ告知によると、ソースコードはGitHubに残り、Apache 2.0のコードは引き続き利用でき、フォークも推奨されています。
コードは使えても、公式の修正はもう出ません。新規案件でFlowiseを選ぶ理由は乏しいため、比較の対象はDifyとLangflowに絞れます。すでにFlowiseを動かしている場合は、後半の移行判断の節で扱います。
3ツールは何をするものか：共通点と得意な使い方
3つとも、画面上でノードをつないでLLMアプリを組み立てるオープンソースのツールです。RAG、エージェント、APIとして公開するワークフローなどを作れます。判断に関わる違いは次の表の範囲です。
項目 | Dify | Langflow | Flowise |
|---|---|---|---|
性格 | ワークフロー、RAG、エージェント、API提供がひとまとまりになった統合型 | Pythonで部品（コンポーネント）の中身を書き換えやすい | LangChain系のノードを組み合わせる構成 |
向く使い方 | 1組織の業務アプリ、社内RAG、他システムのバックエンド | コードで独自処理を足す開発、製品への組み込み | 新規採用は非推奨。既存資産の維持か移行 |
2026年9月の状態 | 開発継続 | 開発継続 | アーカイブ済み、サポート終了 |
機能の多さや操作性だけでは差がつきにくく、実際に選択を分けるのはライセンスとセルフホスト時の運用です。
顧客ごとにワークスペースを渡すか：Difyのライセンス条件で選択が変わる場面
DifyのLICENSEは、Apache 2.0に追加条件を付けたものです。他アプリのバックエンドや、企業向けの開発基盤としての商用利用は認められています。一方で、書面での許諾がない限り、Difyのソースコードでマルチテナント環境を運用することはできません。条文では、1テナントを1ワークスペースと定義しています。
もう一つの条件はフロントエンドです。web/ディレクトリまたはwebイメージを使う場合、ロゴと著作権表示を削除・改変できません。フロントエンドを使わない利用には、この制限は適用されません。
この条件を、利用パターンごとに当てはめると次のようになります。
- 社内向けに1ワークスペースで使う：追加条件に触れるのは、フロントエンドを改変する場合のロゴ表示くらいです。
- 単一のワークスペースから顧客にAPIを提供する：1つのワークスペース内で複数の顧客に提供するケースは、条文だけでは判断しきれません。GitHub issueでも質問が出ています。設計を固める前に、開発元のLangGeniusへ問い合わせます。
- 顧客ごとにワークスペースを分けるSaaS：条文上のマルチテナントに当たるため、商用ライセンスの書面許諾が前提です。
なお、ライセンスは開発元が変更できると明記されています。公開前に最新の条文を読み直してください。
比較のために他の2つも見ておきます。LangflowのLICENSEはMITです。改変・再配布・販売を含めて利用でき、条件は著作権表示と許諾表示を含めることです。ただし、確認できたのは本体リポジトリだけです。クラウド版や周辺リポジトリは、ライセンスが異なる場合があります。
FlowiseのLICENSE.mdは混在構成です。packages/server/src/enterpriseディレクトリと、明示的な著作権表示のあるファイルは商用ライセンスで、それ以外がApache 2.0です。フォークして使い続ける場合は、この境界を越えていないか確認が必要です。
AI時代、自分のスキルはどれくらい評価される？
現在の経験・スキルから、自分の市場価値や狙える案件の方向性を確認できます。
セルフホストで外部に公開するか：Langflowを選ぶなら先に決める運用ルール
Langflowでは、Pythonで部品を書ける自由度と引き換えに、攻撃されうる範囲が広がります。二次情報では、認証なしでコード実行につながる脆弱性が過去に報告され、悪用されたとも伝えられています。影響するバージョンと修正バージョンは、NVD、CISAのKEVカタログ、LangflowのGitHub Security Advisoryで、自分が使うバージョンに照らして確かめてください。
インターネットから到達できる形で公開するなら、採用前に次の項目の担当者と手順を決めておきます。
- バージョンを固定し、セキュリティ修正が出たときの更新手順と検証環境を用意する
- 認証を有効にし、初期設定のまま起動しない
- 管理画面とフロー編集のAPIは、VPNやIP制限の内側に置く
- 利用者に開放するのは、公開用のエンドポイントだけにする
- 任意のコードを実行できる部品を、誰が追加・編集できるかを決める
- アドバイザリーを監視する担当を置く
顧客ごとのユーザー管理や分離を、本体機能でどこまで賄えるかは、対象バージョンで事前に確かめます。足りない部分は自前で作る工数として見積もりに入れます。
既存のFlowiseをどうするか：凍結・フォーク・移行の判断
判断を分ける軸は2つです。外部に公開しているか、そして今後も改修が続くかです。
凍結して使い続けるのは、社内ネットワークに閉じていて、改修もほぼない場合に限られます。公式の修正はもう出ないため、外部に公開しないことと、依存関係の棚卸しを運用の条件にします。
コミュニティのフォークに乗る選択は、公式にも推奨されています。ただし、個々のフォークの品質や保守が続くかどうかは検証していません。フォーク元のコミット頻度とライセンスを見てから決める対象です。
DifyかLangflowで作り直すのは、外部に公開している場合、または改修が続く場合です。フローのJSONはそのまま取り込める前提で見積もらず、作り直しとして進めます。手順は次のとおりです。
- 既存フローのノード、プロンプト、接続先（LLM・ベクトルDB・外部API）を一覧にする
- 現行の入出力を検証データとして保存しておく
- 移行先で同じ入力を流して結果を比べる
説明用の例で考えます。仮に、社内ネットワーク内のFlowise製FAQボットを、取引先ごとに分けた有償サービスにしたいとします。この場合、凍結案は外部公開の時点で外れます。Dify案は取引先ごとにワークスペースを分けると書面許諾が前提になります。Langflow案は、前節の運用ルールと分離の実装工数を持てるかどうかで判断することになります。
案件票はどこを読むか：ツール名より担当範囲と条件で単価差を読む
Dify・Langflow・Flowiseを横並びにした、件数・期間・集計方法の明示された単価調査は見つかりませんでした。そのため、ここでは相場を示しません。案件サイトに出る数字は、そのサイトのその時点の掲載分と読むのが妥当です。
同じ「Dify案件」でも、次の行の中身で求められる役割は大きく変わります。
- 担当フェーズ：PoCのフロー作成だけか、要件定義から本番運用までか
- 連携先：外部APIや社内DBとの連携、認証基盤との接続があるか
- インフラ：セルフホスト環境の構築と保守を含むか。含むなら前節の更新作業も担当範囲に入る
- 評価：回答精度の評価方法の設計まで求めるか
- 講師・アドバイザリー：社内展開や教育が業務に入っているか
- 稼働条件と商流：週の稼働日数、精算幅、何次請けか
応募前には、ツール名の行ではなく業務内容の行を読み、上の項目のどれを自分が担えるかを照らし合わせてください。ライセンスの確認やセルフホストの保守が業務に含まれているのに、票に書かれていない場合もあります。その場合は面談で、誰がその判断を持つのかを質問します。
