Langflow

LLM・tool・retrieval・agentをvisual builderで接続し、実行経路をflowとして明示する

公式READMEはLangflowをAI-powered agentsとworkflowsの構築・配布platformとして位置づけ、visual builder、interactive Playground、multi-agent orchestration、retrievalを主要機能に挙げています。promptやmodel callだけでなく、data source、vector database、tool、memoryなどをcomponentとして接続し、処理順序と入出力をgraphとして追えるのが特徴です。

visual編集に閉じず、各componentのsource codeへアクセスしてPythonでcustomizeできます。既製componentで足りない処理をPython側へ降ろせるため、no-code専用builderというよりvisual authoringを持つPython workflow runtimeとして扱えます。

出典：[2][4]

複数model/providerをbundleで扱い、agent・RAG・外部toolを同じflowへ組み込む

1.12.1のpyprojectはOpenAI、Anthropic、Google、Azure、Amazon、Cohere、Ollama、vLLM、OpenAI-compatible providerなどのlfx bundleを依存関係として管理しています。特定LLM vendorへ固定せず、cloud APIとlocal model endpointを同じcomponent modelの中で選びやすい構成です。

agent、retrieval、vector database、外部APIを一つのflowにまとめられる一方、各providerのAPI key、model availability、rate limit、embedding互換性などはLangflowとは別の運用条件として残ります。

出典：[4][2]

作成したflowをAPIまたはMCP toolとして公開し、他アプリやcoding agentから再利用する

LangflowはflowをAPIとして実行でき、READMEはbuilt-in API serverを主要機能として挙げています。さらにproject単位でMCP serverを構成し、enabled flowをMCP toolとして公開できます。MCP serverはstreamable HTTPを標準transportにし、SSEをfallbackとしてサポートします。

MCP clientはtool nameとdescriptionを見て利用するflowを判断するため、Langflow側でflowを作るだけでなく、tool contractとして名前・説明・input/outputを設計する必要があります。認証を有効にしたserverではproject用API keyを生成でき、OAuth構成にも対応します。

出典：[2][5]

Desktop・Python package・Dockerから始め、同じflowをlocal開発からserver deploymentへ移せる

Langflow DesktopはWindows/macOS向けにdependencies込みで配布され、Python環境を用意せず試せます。OSS Python packageはPython 3.10〜3.14で動作し、uv pip install langflow -Uとuv run langflow runでlocal serverを起動できます。Docker imageも公式READMEから直接起動できます。

flowはJSONとしてexportできるため、visual editorで作った資産をversion管理や別環境へ移すworkflowも取りやすくなっています。UIだけを使うdesktop appではなく、server/API runtimeとしてdeploymentへ進められる点が特徴です。

出典：[2][4]

agentやRAGの構成をコードだけで抱えず、試行錯誤・共有・外部公開まで一つのflow資産で回したいチームに

複数LLMやretrieval/tool callを比較しながらagent workflowを組みたい場合、非同期に増えるprompt・model・toolの接続関係をgraphで共有したい場合、prototypeからAPI/MCP toolへ早く公開したい場合に向きます。Pythonでcustom componentへ降りられるため、visual builderとcode-first実装の間を行き来したいAI applicationチームにも適合します。

public serverでは認証を明示的に構成する。local向けAUTO_LOGINをinternet公開へ持ち込まない

公式authentication docsはLangflowのportをsecurity対策なしでinternetへ直接公開しないよう警告し、LANGFLOW_AUTO_LOGIN=False、非defaultのLANGFLOW_SECRET_KEY、authentication付きreverse proxyを推奨しています。application側のAUTO_LOGIN defaultはTrueで、公式Docker imageはfalseに設定されます。

Langflow API keyは作成userの権限を引き継ぎ、single-user環境ではsuperuser権限になります。API、webhook、MCP serverを外部へ公開する場合は、editor loginだけでなくAPI key/OAuth、signup、secret rotation、reverse proxyまで含めてaccess boundaryを設計する必要があります。

出典：[6][5][7]

visual graphは運用複雑性を消さない。provider version・credential・component bundleをflowと一緒に管理する

flowの見通しは良くなりますが、実行時にはmodel provider、embedding、vector database、外部tool、component bundleなど複数dependencyが関わります。1.12.1でもcurated lfx packageをversion rangeで管理しており、upgrade時にはcomponent registryやprovider側変更がflow behaviorへ影響し得ます。

production利用ではflow JSONだけで再現性が完結すると考えず、Langflow version、bundle/dependency version、environment variables、database、provider credentialsをdeployment設定として固定する方が安全です。

出典：[4][3]

custom Python componentは強力だが、importしたcomponentやflowを実行コードとして扱う

LangflowはPython sourceへのアクセスとcustom component作成を許可するため、visual workflowに見えてもserver側で実行されるcode boundaryを持ちます。信頼できないcustom componentやflowをそのままproduction serverへ持ち込まず、review・dependency policy・credential accessを分離する必要があります。

1.12系にはcode-execution component向けのopt-in microVM sandbox backendも定義されていますが、Python 3.12以上とQEMU 8+など追加要件があります。sandbox利用の有無を含め、実行可能componentのpolicyをdeploymentごとに決める必要があります。

出典：[2][4]