重要なポイント
- MITライセンス — 許諾範囲が広く、セルフホスト可能、マルチテナントやロゴの制限なし
- 元々はLogspaceが開発。2024年4月にDataStaxが買収し、その後IBMがDataStaxを買収（2025年5月28日完了）
- GitHubスター数15万超、コミット履歴も活発。開発終了しアーカイブされたFlowiseとは対照的
- Pythonで構築されており、Node.js/TypeScriptベースのFlowiseより生のLangChainに近い
- Docker、pip/uv、またはLangflow Desktopアプリ（Windows/macOS）でセルフホスト可能
- ホスト版クラウド「DataStax Langflow」はIBM傘下のベクトルデータベースAstra DB上で稼働
- アーカイブされ保守されなくなったFlowiseからの移行先として現実的な選択肢
📍 一文で説明
LangflowはPythonベースのオープンソース（MITライセンス）ビジュアルビルダーで、LangChain/LangGraphエージェントとRAGパイプラインを構築でき、2025年のDataStax買収でIBM傘下となった現在も活発に開発が続いている。
💬 簡潔に説明
LangChainのコードを手書きする代わりに、LangflowはドラッグアンドドロップでLLM、ドキュメントローダー、ベクトルデータベースをつなぐキャンバスを提供し、IBMという大企業が継続的にメンテナンス費用を出している。
📌補足: LangflowとFlowiseは同一プロジェクトではない。どちらもLangChain/LangGraphの構成をビジュアルに生成するが、コードベースも運営会社も別である。
Langflowの運営元は？現在も保守されているのか？
IBMがLangflowを保有しており、プロジェクトは活発に保守されている。 LangflowはもともとLogspaceのオープンソースプロジェクトとして始まり、DataStaxが2024年4月にAIアプリケーションツールを拡充するため買収した。その後IBMは2025年2月25日にDataStax買収を発表し、2025年5月28日に買収を完了。これによりLangflowとDataStaxのベクトルデータベースAstra DBはIBM傘下となった。
この所有関係の連鎖は、継続性という点でFlowiseとは事情が異なる。Flowiseは小規模な独立企業（FlowiseAI）が保守していたが、2026年に自社事業を終了した。IBMはLangflowをwatsonx.aiポートフォリオに組み込み、IBM Graniteモデルなど各種プロバイダー上でエージェントを構築するローコード層として位置付けており、開発資金を出し続ける商業的理由を持っている。
Logspace → DataStax
- 日付:
- 2024-04
- 意味:
- Langflowの開発元が買収され、DataStaxが保守企業になる
IBM・DataStax買収発表
- 日付:
- 2025-02-25
- 意味:
- IBMがLangflowを含むDataStax買収の意向を発表
買収完了
- 日付:
- 2025-05-28
- 意味:
- DataStaxとLangflowが正式にIBM傘下となる
watsonx.ai統合
- 日付:
- 継続中
- 意味:
- IBMはLangflowをwatsonx.ai内でエージェントを構築するミドルウェアとして位置付け
📌補足: MITライセンスのコアプロジェクトは商標の所有者に関係なく完全にオープンソースかつセルフホスト可能なままである。IBMやDataStaxのホスト製品を利用するかどうかに関わらず、同じコードが動作する。
Langflowとは何か？
Langflow（github.com/langflow-ai/langflow、MITライセンス）はPythonで構築されたビジュアルなノードベースインターフェースを通じてAIエージェントとRAGアプリケーションを構築・デプロイするオープンソースのローコードプラットフォームである。サイトのタグラインは「Drag. Drop. Deploy.」で、リポジトリは15万GitHubスターを超えている。
- チェーンロジックを手書きせずにLangChain/LangGraphのフローを組み立てられるビジュアルキャンバス
- エージェント対応：エージェントはキャンバス上の他のコンポーネントをツールとして呼び出せ、マルチエージェントのオーケストレーションと会話メモリを備える
- Pythonカスタマイズ：ビジュアルライブラリでカバーできないロジックのために、各ノードは生のPythonで編集・拡張できる
- APIエンドポイント、エクスポートしたJSONフロー、またはMCP（Model Context Protocol）サーバーとしてデプロイ可能
- デプロイ前にフローを段階的にテストできるインタラクティブなPlayground
- エージェントの実行をトレースするLangSmithおよびLangFuseとのオブザーバビリティ連携
LangflowとFlowiseの違いは？
LangflowとFlowiseは同じ課題（LangChain/LangGraphのビジュアルなオーケストレーション）を、異なるコードベース、異なる言語で解決しており、現在は保守状況も大きく異なる。 LangflowはPythonベースで生のLangChainのセマンティクスに近く、FlowiseはNode.js/TypeScriptベースで、2026年時点ではアーカイブされ保守されていない。
Langflowが優位な点
資金力のある企業（IBM）の下で活発に開発が続いており、保守されないツールが抱える最大のリスク（脆弱性が放置され新規統合も追加されない）を回避できる。Pythonベースであるため、カスタムロジックも「Custom Function」ノードに押し込まれたJavaScriptではなく、通常のLangChainコードのように見える。
Flowiseが優位だった点（保守されていた頃）
終了前のFlowiseは、より幅広い統合ライブラリ、テンプレートマーケットプレイス、Chatflow/Agentflowの分離モード、さらに1インスタンスから複数の顧客向けボットをホストできる部分的なマルチテナンシーを備えていた。Langflowのバージョン管理はより手動的で、組み込みのマルチテナントホスティングに頼るのではなく、フローをJSONとしてエクスポートする形になる。
Flowiseから移行する場合
Langflowは妥当な移行先である。同じLangChain/LangGraphの概念、似たノードと配線のメンタルモデル、Apache 2.0の代わりにMIT（どちらも許諾範囲が広い）ライセンス、そして重要な点として、更新を続ける商業的インセンティブを持つ運営元がある。ただし自動インポートツールは存在しないため、フローを手作業で再構築する時間を見込む必要がある。
LangflowはRAGとAIエージェントに対応しているか？
対応している。RAGとエージェントオーケストレーションはLangflowの中核的なユースケースであり、後付けの機能ではない。 プラットフォームは両方に専用のコンポーネントカテゴリを用意しており、IBMの親会社であるDataStax自身のベクトルデータベース（Astra DB）もコンポーネントライブラリに直接組み込まれている。
- RAG：Vector Store RAGテンプレートは取り込みとクエリを2つのフローに分割する。一方はファイルを読み込みチャンク分割・埋め込み・インデックス化を行い、もう一方はユーザークエリを埋め込み最も近い一致を取得する
- ベクトルデータベース：DataStax/IBM自社製品のAstra DB専用コンポーネントに加え、他の一般的なベクトルデータベースにも対応し、RAGパイプラインが単一のバックエンドに縛られない
- ローカルLLM：専用のOllamaバンドルがチャットモデルコンポーネントと埋め込みコンポーネントの両方を提供し、フロー全体をクラウドAPIではなくローカルホストのモデルに対して実行できる
- エージェント：キャンバス上のどのコンポーネントもエージェントが呼び出せるツールとして公開でき、マルチエージェントオーケストレーションと複数ターンにわたる会話メモリに対応
- デプロイ：完成したフローは呼び出し可能なAPI、エクスポート可能なJSONファイル、または他のAIクライアントが接続できるMCPサーバーになる
Langflowをセルフホストする方法
LangflowのセルフホストにはIBMやDataStaxのアカウントは不要で、オープンソースパッケージは自前のハードウェア上で完全に動作する。 Dockerが最速の方法で、pip/uvとデスクトップアプリが代替手段となる。
- 1最低要件（デュアルコアCPUとRAM 2GB、推奨はマルチコアCPUと4GB以上）を満たしているか確認する。デスクトップアプリを使わない場合はChromiumベースのブラウザも必要。
- 2Dockerの場合：
docker run -p 7860:7860 langflowai/langflow:latestを実行し、コンテナ起動後にhttp://localhost:7860を開く。 - 3pip/uvの場合：Python 3.10〜3.14をインストールし、
uv pip install langflow -Uの後にuv run langflow runを実行してローカルサーバーを起動する。 - 4代わりにLangflow Desktop（Windowsまたは macOS 13以降）をインストールすることもできる。依存関係を自動管理するパッケージ版アプリだが、ブラウザ版のShareable PlaygroundとVoice Modeは含まれない点に注意。
- 5キャンバスにコンポーネントをドラッグしてフローを組む：LLMノード、プロンプト、RAGの場合はドキュメントローダー・埋め込みモデル・ベクトルデータベースのコンポーネントを配線する。
- 6完成したフローをAPIエンドポイントとしてデプロイするか、バージョン管理のためJSONとしてエクスポートするか、他のAIツールが呼び出せるMCPサーバーとして公開する。
Langflowをセルフホストするのに DataStax や IBM のアカウントは必要か？
不要。GitHubおよびPyPI上のオープンソースパッケージlangflowは、DataStaxやIBMのクラウドアカウントとは無関係に動作する。アカウントが必要なのは、ホスト製品のDataStax Langflowや、Astra DBをマネージドベクトルデータベースとして使う場合のみである。
Langflowの最低ハードウェア要件は？
ドキュメント上の最低要件はデュアルコアCPUとRAM 2GBで、実運用にはマルチコアCPUと4GB以上のRAMが推奨される。pip/uvでのインストールにはPython 3.10〜3.14が必要。
Langflowはどんな人向けか？
LangflowはPythonを手放さずにLangChainの上にビジュアル層が欲しい開発者に向いており、Flowiseから離れる人にとっても信頼できる選択肢となる。 標準機能として重厚なマルチテナントSaaSホスティングが必要なチームには不向きである。
Langflowを使うべき場合
- カスタムロジックのためにPythonを放棄せず、LangChain/LangGraphのエージェントとRAGパイプラインをビジュアルにプロトタイピングしたい場合
- Flowiseをセルフホストしていて、活発に保守されているビジュアルビルダーへの移行先が必要な場合
- チームがすでにAstra DBやIBM watsonx.aiを使っている（または使う予定がある）場合で、ネイティブな統合を求める場合
- 小規模な独立プロジェクトよりも、継続的なコミット履歴を持つ企業支援プロジェクトを重視する場合
Langflowを避けるべき場合
- 1つのインスタンスから多数の顧客向けボットを標準機能でマルチテナントホストする必要がある場合
- Pythonを使わず、カスタムロジックをNode.js/TypeScriptスタックで書きたい場合
- 基本コンポーネントからフローを組み立てるのではなく、大規模な既製テンプレートマーケットプレイスが必要な場合
- 大企業ベンダーがいずれロードマップを自社の商用製品（Astra DB、watsonx.ai）寄りに誘導することを懸念する場合
Langflow vs. 代替ツール
LangflowはLangChain系のエージェントとRAGパイプラインを構築する他のビジュアル・コードファーストツールと競合する。保守状況は特にFlowiseとの最も明確な違いである。
ツール | インターフェース | ライセンス | 運営元 | 保守状況 |
|---|---|---|---|---|
| Langflow | ビジュアル（Python） | MIT | IBM（DataStax経由） | 活発 |
| Flowise | ビジュアル、ドラッグ&ドロップ | Apache 2.0 | 独立（FlowiseAI） | アーカイブ済／なし |
| Dify | ビジュアル＋バックエンド | Apache 2.0＋制限 | 独立（LangGenius） | 活発 |
| LlamaIndex | Python／TSコード | MIT | 独立（LlamaIndex Inc.） | 活発 |
| n8n | ビジュアル、ドラッグ&ドロップ | Fair-code／Sustainable Use | 独立（n8n GmbH） | 活発 |
Langflowを評価する際のよくある誤解
これらの誤解は、LangflowとFlowiseを混同したり、企業所有であることが常にオープンソースとして劣ることを意味すると思い込むことから生じる。
誤解1：LangflowとFlowiseを混同する
名前もノードキャンバスのインターフェースも似ているため、実際に混同されやすい。両者は別々のGitHubリポジトリを持つ別プロジェクトであり、ライセンスも異なり（MIT対Apache 2.0）、2026年時点での保守状況も大きく異なる。Flowiseはアーカイブ済み、Langflowはそうではない。
誤解2：IBM所有＝オープンソース版が制限されると思い込む
Langflowのコアパッケージは引き続きMITライセンスで、IBMやDataStaxへの接続を必須とせず完全にセルフホスト可能である。IBMの商用製品はホスト版のDataStax Langflowクラウドとベクトルデータベースのアストラ DBであり、これらの利用は任意であってLangflowを動かすための必須条件ではない。
誤解3：自動化されたFlowiseインポートを期待する
FlowiseのChatflowやAgentflowをLangflowのフローに変換する組み込みの移行ツールは存在しない。ドキュメントローダー、埋め込みモデル、エージェントのツール定義はすべてLangflow独自のコンポーネントで再配線する必要があり、そのための時間を見込んでおくべきである。
よくある質問
Langflowの運営元はどこか？
IBMがLangflowを保有している。もともとLogspaceが開発し、2024年4月にDataStaxが買収、そのDataStaxが2025年5月28日にIBMに買収された。
Langflowはオープンソースか？
はい。LangflowはGitHub（langflow-ai/langflow）上で許諾範囲の広いMITライセンスの下に公開されており、一部の競合ツールにあるようなマルチテナント制限やロゴ制限はない。
Langflowは現在も活発に保守されているか？
はい。2026年にFlowiseAIが事業を終了したFlowiseとは異なり、Langflowはコミット履歴が活発で、IBMはこれをwatsonx.aiプラットフォーム向けのエージェント構築ミドルウェアとして位置付けている。
LangflowはFlowiseとどう違うのか？
LangflowはPythonベースで、現在はIBMが支援するチームが開発している。FlowiseはNode.js/TypeScriptベースで独立企業FlowiseAIが開発していたが、現在はアーカイブされ保守されていない。どちらもLangChain/LangGraph的な構成をビジュアルに生成するが、コードベースは別である。
IBMやDataStaxのアカウントなしでLangflowをセルフホストできるか？
できる。オープンソースパッケージlangflowはDocker、pip/uv、またはLangflow Desktopアプリでインストールでき、自前のハードウェア上で完全に動作する。IBMやDataStaxのアカウントが必要なのは、ホスト製品のDataStax LangflowやマネージドAstra DBを使う場合のみである。
Langflowは検索拡張生成（RAG）に対応しているか？
はい。Vector Store RAGテンプレートは、取り込み（ドキュメントの読み込み・チャンク分割・埋め込み・インデックス化）とクエリ（質問の埋め込み・最も近い一致の取得）を2つのフローに分け、Astra DBを含む差し替え可能なベクトルデータベースコンポーネントを使用する。
Langflowはマルチエージェントシステムに対応しているか？
はい。キャンバス上のどのコンポーネントもエージェントが呼び出すツールとして公開でき、複数ターンにわたって保持される会話メモリを伴うマルチエージェントオーケストレーションに対応している。
Langflowの最低システム要件は？
最低でもデュアルコアCPUとRAM 2GB、実運用にはマルチコアCPUと4GB以上のRAMが推奨される。pip/uvでのインストールにはPython 3.10〜3.14が必要である。
DataStax Langflowとは何か、オープンソース版Langflowとどう違うのか？
DataStax Langflowは、同じオープンソースプロジェクトをIBM/DataStaxがホストするクラウド版で、ベクトルデータベースのAstra DBと統合されている。セルフホスト版とまったく同じコアソフトウェアが動作し、違いはIBMがホスティングを管理し、デフォルトでAstra DBに接続する点である。
Flowiseから離れる人にとってLangflowは良い代替になるか？
なる。ただし条件付きである。基盤となる概念（ビジュアルなLangChain/LangGraphフロー、RAGコンポーネント、エージェントツール）は十分に近いため、Langflowは妥当な移行先だが、自動インポート機能はなく、フローを手作業で再構築する必要がある。
LangflowはMCPサーバーとしてデプロイできるか？
できる。完成したLangflowフローはModel Context Protocol（MCP）サーバーとして公開でき、他のMCP対応AIクライアントがツールとして呼び出せる。単純なAPIエンドポイントとしてのデプロイやJSONエクスポートも可能である。