自動化

Langflowとは?ノーコードでAIエージェント・RAGを作る使い方とWebhook連携を実例で解説

Langflow(ラングフロー)は、ノードをドラッグ&ドロップでつなぐだけで、大規模言語モデル(LLM)を使ったAIアプリを構築できるオープンソースツールです。RAGやAIエージェント、外部システムからWebhookで起動するフローまで、コードをほとんど書かずに設計できます。この記事では、Langflowの定義と現在地(2025年にDataStaxごとIBM傘下入り)から、インストール・基本的な使い方・Webhookでのフロー起動・API連携・RAG構築までを、実際に動くコマンドと公式の現行仕様に沿って解説します。どの機能をどの場面で使うか、そして向かない場面まで踏み込みます。

まとめ:Langflowの要点

  • 正体:ノードベースのビジュアルUIでLLMアプリを組むOSS。2025年2月にDataStax(Langflow開発元)ごとIBMが買収し、現在はIBM watsonx陣営で開発が続く。
  • 導入:Python 3.10〜3.14環境に uv pip install langflowuv run langflow runhttp://127.0.0.1:7860 が起動。Dockerなら1コマンドで動く。
  • Webhook:Webhookコンポーネントを置くと POST /api/v1/webhook/{FLOW_ID} が生え、外部サービスのイベントでフローを非同期起動できる。既定でAPIキー認証が必要。
  • API連携POST /api/v1/run/{FLOW_ID} で作成済みフローをアプリから実行。GUIで試作し、そのままバックエンドに組み込める。
  • 向き不向き:試作・RAG・社内自動化には強いが、細かな分岐制御や大規模本番はコード実装(LangChain等)へ移す判断も要る。

以下で、各項目を導入からWebhook・API連携まで順に見ていきます。

Langflowとは何か:ノーコードLLM開発ツールの定義と現在地

Langflowは、Promptや言語モデル、検索、出力といった処理を「コンポーネント(ノード)」として画面上に並べ、線でつないでAIの処理フローを作るローコード/ノーコードツールです。内部ではPythonで各ノードが実行され、GUIで組んだフローをAPIとして外部に公開したり、Pythonから呼び出したりできます。オープンソース(MITライセンス相当のOSS)で、ローカルにも自社サーバーにも設置できる点が、SaaS型のノーコードAIツールとの大きな違いです。

開発元の変遷とv1.8系での現在地

Langflowは2023年に登場し、2024年にベクトルデータベースAstra DBを手がけるDataStaxが買収しました。さらに2025年2月25日、IBMがそのDataStaxごと買収すると発表し、現在LangflowはIBM watsonx陣営の製品として開発が続いています。OSSとしての公開・コミュニティ運営は買収後も維持されています。2026年時点の安定版は1.8系で、ドキュメントを取り込むKnowledge Base機能やモデルのグローバル設定が標準搭載されました。この記事のコマンドや仕様は1.8系の公式ドキュメントに基づきます。

LangChainとの関係の変化(1.7以降は任意バンドル)

初期のLangflowは「LangChainのGUI版」と説明されることが多く、LangChainのクラスがそのままノードになっていました。ただし1.7以降はMCP(Model Context Protocol)に対応し、LangflowはMCPサーバー/クライアントの両方として動くフレームワーク非依存の構成へ移りました。LangChainは必須の土台ではなく任意の追加バンドルという位置づけに変わっています。「LangChainが入っていないと動かない」という旧来の理解は現行版では正確ではありません。LangChain側でのRAG実装の考え方はLangChainを使ったRAG(検索拡張生成)の概要と実践方法で整理しています。

DifyやFlowiseとの違いと使い分け

ツール 形態 強み 主な用途
Langflow OSS / セルフホスト Python拡張・API公開・MCP 開発者寄りの試作〜組み込み
Dify OSS / SaaS アプリ運用・権限管理 社内アプリの公開運用
Flowise OSS / セルフホスト 軽量・Node.js系 手軽なチャットボット試作

3者はいずれもノードでLLMフローを組みますが、Langflowは生成したフローをPythonコードやAPIとして外に出し、既存システムに組み込む方向に強みがあります。逆に、非エンジニアが運用画面ごとアプリを配布したいならDify、とにかく軽く試すだけならFlowiseが向きます。「ビジュアルで作ったものをエンジニアが本番に持っていく」前提ならLangflowを選ぶ、という基準が実務では分かりやすい判断軸です。

Langflowのインストールと起動:uvとDockerの2通り

Langflowはローカル実行が基本で、無料で導入できます。動作にはPython 3.10〜3.14が必要です(旧記事にある3.9以上という記述は現行版では古いため注意してください)。導入方法は、Python環境を自分で管理するuvによる方法と、環境を気にせず動かせるDockerによる方法の2通りがあります。

uvでインストールして起動する手順

公式が推奨するのは高速なPythonパッケージマネージャuvです。仮想環境を作り、Langflowを入れて起動するまでは3コマンドで済みます。

# uv 未導入なら先に入れる
pip install uv

# 仮想環境を作成して有効化(Windows は langflow-env\Scripts\activate)
uv venv langflow-env
source langflow-env/bin/activate

# Langflow をインストール
uv pip install langflow

# 起動(http://127.0.0.1:7860 が開く)
uv run langflow run

起動後、ブラウザで http://127.0.0.1:7860 にアクセスするとビジュアルエディタが表示されます。最新版へ更新するときは uv pip install langflow -U、特定版に固定したいときは uv pip install langflow==1.8.0 のようにバージョンを指定します。ポート7860が使用中の場合は uv run langflow run --port 7861 のように変更できます。

Dockerで起動する手順

Pythonの環境構築を避けたい場合や、チームで同じ環境をそろえたい場合はDockerが確実です。公式イメージを使えば1コマンドで起動します。

docker run -p 7860:7860 langflowai/langflow:latest

コンテナ起動後、同じく http://localhost:7860 でアクセスできます。データを永続化したい場合はボリュームをマウントし、環境変数で保存先データベースやAPIキー認証の設定を渡します。ローカル環境を汚さず、削除・再構築が容易な点がDockerの利点です。

起動時につまずきやすい点

  • Pythonバージョン不一致:3.10未満や3.15以降だと依存解決に失敗する。python --version で範囲内か確認する。
  • ポート競合:7860が埋まっていると起動しない。--port で別ポートを指定する。
  • モデルAPIキー未設定:OpenAIなど外部モデルを使うノードはキーが必要。フロー実行前に各ノードまたは環境変数で設定する。

ローカルLLMを使えばキーは不要ですが、その場合は推論に足るメモリとモデルの準備が別途必要になります。

Langflowの使い方:主要コンポーネントと最小フローの作り方

Langflowの中心はビジュアルフロービルダーです。中央のキャンバスにコンポーネントを置き、出力ポートと入力ポートを線でつないで処理の流れを作ります。ここでは、まず押さえるべきコンポーネントと、最小構成のチャットフローを実際に組む手順を示します。

最低限おさえる主要コンポーネント

コンポーネント 役割
Chat Input / Chat Output ユーザーの入力受け取りと応答表示
Prompt プロンプトのテンプレートと変数定義
Language Model OpenAIやAnthropic等のLLM呼び出し
Webhook 外部からのHTTPリクエストでフロー起動
Parser 受け取ったデータを後続へ渡す形に整形

この5つに加え、後述するRAG向けのベクトルストアや検索系、エージェント向けのAgent/MCPツール系を組み合わせると、たいていのユースケースはカバーできます。ノードは種類が多いため、まずはこの中核だけ覚えて、必要になったら追加していくのが習得の近道です。

最小構成のチャットフローを作る

初めての1本は、Chat Input → Prompt → Language Model → Chat Output の4ノードで作るチャットが最短です。手順は次の通りです。

  1. 新規フローを作成し、キャンバスに Chat Input を置く。
  2. Prompt を置き、テンプレートに {input} のような変数を書き、Chat Input の出力をつなぐ。
  3. Language Model を置き、モデル名とAPIキーを設定し、Promptの出力をつなぐ。
  4. Chat Output を置き、Language Model の出力をつなぐ。
  5. 右上のPlaygroundを開き、メッセージを送って応答が返るか確認する。

この基本形が動けば、あとはPromptを差し替えたり、検索ノードを挟んだりして用途に合わせて発展させられます。テンプレートも用意されており、RAGやエージェントの雛形から始めて中身を学ぶこともできます。

ループや条件分岐の扱い

Langflowには繰り返し処理用のLoopコンポーネントがあり、リストを1件ずつ処理して集約する構成を組めます。条件によって処理を振り分けたい場合は、If-Elseなどの分岐コンポーネントで出力先を切り替えます。ただし、複雑な状態遷移や多段の分岐をすべてノードで表現しようとすると、かえって可読性が落ちます。分岐が入り組んでくる場合は、後述のようにフローをAPI化してアプリ側のコードで制御を持つ設計に切り替えるほうが保守しやすくなります。

WebhookでLangflowのフローを外部から起動する方法

Webhookコンポーネントを使うと、Langflowのフローを外部サービスのイベントから起動できます。フォーム送信、SlackやGitHubのイベント、他システムのバッチ完了通知などをトリガーに、フローを自動実行する用途に向いています。ここは公式ドキュメントに沿って、エンドポイント・呼び出し例・認証まで具体的に見ていきます。

Webhookコンポーネントとエンドポイント

フローにWebhookコンポーネントを1つ置くと、そのフロー専用のエンドポイント POST /api/v1/webhook/{FLOW_ID} が有効になります。典型的な最小構成は、Webhook(受信)→ Parser(整形)→ Chat Output(結果)の3ノードで、WebhookのData出力をParserのData入力へ、Parserの整形結果をChat OutputのText入力へつなぎます。エンドポイントのURLは、Webhookコンポーネントの設定欄、またはフローのAPIアクセスパネルの「Webhook」タブからそのままコピーできます。

curlでフローをトリガーする

受信側を用意したら、外部から次のようなPOSTリクエストを送るとフローが起動します。FLOW_ID は対象フローのIDまたはエンドポイント名、LANGFLOW_API_KEY は発行したAPIキーです。

curl -X POST "http://localhost:7860/api/v1/webhook/FLOW_ID" \
  -H "Content-Type: application/json" \
  -H "x-api-key: LANGFLOW_API_KEY" \
  -d '{"id": "12345", "name": "alex", "email": "[email protected]"}'

送ったJSONはWebhookコンポーネントのData出力として後続ノードに流れます。Parserで必要なフィールドだけ取り出し、Language Modelへ渡して要約・分類したり、別のAPIへ書き込んだりと、受信データを起点に処理を組み立てられます。

認証と非同期実行の注意点

Webhookは既定でAPIキー認証が有効です(環境変数 LANGFLOW_WEBHOOK_AUTH_ENABLETrue)。リクエストには x-api-key ヘッダー、またはクエリパラメータでキーを付けます。認証を切ることも可能ですが、信頼できる閉じた環境以外では避けてください。もう一つ重要なのが実行タイミングです。Webhookはリクエストを受け取ると即座に受理応答を返し、フロー本体はバックグラウンドで非同期に走ります。応答ボディにフローの最終結果は含まれません。結果を受け取りたいなら、フロー内から別のAPIへ書き込むか、結果を保存するノードを置く設計にします。外部入力をそのままLLMへ渡す構成は危うい。想定外の入力による誤動作を避けるため、Parser段で検証・整形しておくのが安全です。

Langflow APIでフローをアプリに組み込む

GUIで作ったフローは、試作で終わらせずAPIとして呼び出して本番のアプリに組み込めます。Webhookが「外部イベントで起動する入口」なのに対し、こちらは「アプリ側から能動的にフローを実行する」使い方です。「langflow api」で検索されるのは主にこの実行APIです。

REST APIでフローを実行する

作成済みフローは POST /api/v1/run/{FLOW_ID} で実行できます。入力値と入出力タイプを指定してPOSTすると、フローを通した結果が返ります。

curl -X POST "http://localhost:7860/api/v1/run/FLOW_ID" \
  -H "Content-Type: application/json" \
  -H "x-api-key: LANGFLOW_API_KEY" \
  -d '{"input_value": "こんにちは", "output_type": "chat", "input_type": "chat"}'

この呼び出しをWebアプリのバックエンドやバッチ処理に組み込めば、チャットボットの応答生成やドキュメント要約をLangflowのフローとしてAPI化して使えます。フロー画面のAPIアクセスパネルには、cURLやPython向けのコード例が用意されており、そのまま自分のコードに貼り付けて動かせます。

PythonやCLI、MCPサーバーとしての公開

Langflowはコマンドラインからの操作にも対応し、langflow run のほか設定やバージョン確認などをCLIで扱えます。さらに、フロー群をMCPサーバーとして公開すれば、MCPに対応したAIエージェントやIDEからLangflowのフローをツールとして呼び出せます。ビジュアルで組んだ処理を、コード側の資産としても、エージェントから使えるツールとしても再利用できるのが、単なるノーコードツールと一線を画す点です。

RAGとAIエージェントを構築する応用

Langflowが試作ツールにとどまらないのは、RAG(検索拡張生成)やAIエージェントをGUIで組めるためです。ここは各技術の勘所と、Langflowでの組み方を対応づけて説明します。

RAGフローの構成

RAGは、ユーザーの質問に対して外部の文書から関連箇所を検索し、その内容を根拠にLLMへ回答させる手法です。Langflowでは、文書をベクトル化して保存するベクトルストア系ノードと検索ノードを置き、検索結果をPromptに差し込んでLanguage Modelへ渡す構成にします。1.8系ではドキュメントを取り込むKnowledge Base機能が標準化され、社内文書を読み込ませたRAGの構築が以前より手数少なく行えます。

Knowledge Baseを使う場合の流れは次の通りです。

  1. Knowledge Baseに対象ドキュメント(PDFやテキスト等)を投入し、埋め込みモデルを指定してベクトル化・登録する。
  2. フロー側に検索ノードを置き、そのKnowledge Baseを参照先に設定する。
  3. Chat Inputの質問を検索ノードへ渡し、取得した関連チャンクをPromptに差し込んでLanguage Modelへ接続する。

これで、質問のたびに登録文書から根拠を引いて回答するRAGフローが動きます。回答が文書にない内容を作ってしまう問題への対処はハルシネーションを防止するための具体的な対策と運用上の工夫を、RAGそのものの設計は前掲のLangChain記事を併せて参照すると理解が深まります。

AIエージェントの構築

エージェントは、LLMが状況に応じてツール(検索、計算、外部API呼び出しなど)を選んで実行する仕組みです。LangflowではAgentコンポーネントを中心に、ツールとなるノードやMCPツールを接続して構築します。問い合わせ内容に応じて社内ナレッジ検索と外部API呼び出しを使い分けるボットなどが典型例です。エージェントを本格運用する際の制御設計の全体像はAIエージェントの制御基盤となるハーネス設計の全体像と構成要素で詳しく扱っています。定型的な問い合わせ対応に絞るなら、オープンソースのチャットボット開発フレームワークであるRasa(ラサ)のような選択肢と比較して決めるとよいでしょう。

Langflowが向く場面・向かない場面

ノーコードは万能ではありません。導入判断のために、Langflowが実力を発揮する場面と、別手段を検討すべき場面を切り分けておきます。

向く場面は、RAGやエージェントの試作を素早く回したいとき、非エンジニアを交えて処理フローを可視化・共有したいとき、そして社内文書検索や定型業務の自動化をセルフホストで完結させたいときです。GUIで組んだものをAPI化してそのまま組み込めるため、PoCから小規模運用への橋渡しがスムーズです。Webhook起点の社内自動化(フォーム受付や通知連携)も相性が良い領域です。

逆に向かない場面もはっきりしています。多段の条件分岐や複雑な状態管理を伴うロジックは、ノードで表現すると図が絡まり保守が難しくなります。大量リクエストをさばく大規模本番では、スケーリングや監視をアプリ基盤側で作り込む必要があり、フローをコード(LangChain等)へ移したほうが安定します。細かなバージョン管理やテストを厳密に回したい開発チームも、GUI主体だと差分レビューがしづらくなります。こうしたケースでは「Langflowで設計・検証し、確定したらコードに落とす」という使い分けが現実的です。自然言語からのSQL生成のように特定タスクに最適化された手法(Text-to-SQLなど)が要件に合うなら、そちらを軸にする判断もあり得ます。

よくある質問(FAQ)

Langflowは無料で使えますか?

はい。Langflowはオープンソースで、ローカルや自社サーバーに設置して無料で利用できます。ただし、OpenAIなど有料の外部LLMを呼び出す場合は、そのモデルのAPI利用料が別途かかります。ローカルLLMを使えばモデル側の費用は不要です。

Langflowは日本語で使えますか?

操作画面は英語中心ですが、扱うプロンプトやデータは日本語で問題なく動きます。日本語対応のLLM(GPT系やClaude、Gemini、日本語対応のローカルモデルなど)を選べば、日本語での質問応答やRAGを構築できます。

LangflowにLangChainは必須ですか?

現行版(1.7以降)では必須ではありません。MCPに対応し、LangChainは任意の追加バンドルという位置づけに変わりました。LangChainを使わずにフローを組むことも可能です。

Webhookで外部サービスと連携できますか?

できます。Webhookコンポーネントを置くと POST /api/v1/webhook/{FLOW_ID} が有効になり、SlackやフォームなどからのHTTPリクエストでフローを起動できます。既定ではAPIキー認証が必要で、フローはバックグラウンドで非同期実行されます。

作ったフローを既存アプリに組み込めますか?

組み込めます。POST /api/v1/run/{FLOW_ID} でフローをAPIとして実行できるほか、MCPサーバーとして公開してエージェントから呼び出すこともできます。GUIで試作し、そのまま本番のバックエンドへ載せる流れが可能です。

関連記事

資料請求

RELATED POSTS 関連記事