Langflowとは？使い方とWebhook・APIでフローを動かす手順【1.12対応】

Langflow（ラングフロー）は、プロンプトやLLM、検索、出力といった部品を画面上で線でつなぎ、AIエージェントやRAGのフローを作るオープンソースのツールです。作ったフローはそのままHTTPのAPIになり、Webhookで外部サービスのイベントから起動することもできます。この記事では、2026年10月13日公開の最新版1.12.6をDockerで実際に起動し、Webhookと実行APIを叩いて確かめた応答をもとに、インストールから使い方、Webhook・API連携、公開前に必要な安全設定までを順に説明します。

まとめ：Langflow 1.12.6の要点

• 正体：ノードをつないでLLMアプリを作るMITライセンスのOSS。開発元DataStaxは2025年2月にIBMが買収を発表し、現在もほぼ毎週パッチ版が出ている。
• 導入：Python 3.10〜3.14で uv pip install langflow。公式Dockerイメージは自動ログインが無効なので、LANGFLOW_SUPERUSER_PASSWORD を渡さないと起動しない。
• Webhook：POST /api/v1/webhook/{フローIDまたはエンドポイント名}。受け付けると202を返し、処理は裏で走る。フローの結果は応答に入らない。
• 認証：1.9.1からWebhookもAPIキー必須が既定。1.7.0〜1.9.0は既定で認証なしだったため、古い版はフローIDだけで誰でも実行できた。
• 結果を受け取りたいとき：Webhookではなく POST /api/v1/run/{フローID} を使い、Webhookへ渡すはずだったJSONを tweaks で渡す。
• 公開前：Langflowは任意のPythonを実行できる設計で、未認証RCEの勧告が複数出ている。外部に出すなら最新版・認証有効・リバースプロキシ配下が前提。

Langflowとは：ノードでLLMフローを組むOSSと2026年の現在地

Langflowは、Chat Input、Prompt、Language Model、Chat Outputといったコンポーネントをキャンバスに置き、出力ポートと入力ポートを線でつないで処理の流れを作るツールです。各コンポーネントの中身はPythonで、画面で組んだフローは自動的にREST APIとして呼び出せる状態になります。ライセンスはGitHubのリポジトリにあるとおりMIT Licenseで、ローカルにも自社サーバーにも置けます。

開発元とリリースの速さ

Langflowを開発するDataStaxについて、IBMは2025年2月25日に買収の意向を発表しました。開発は買収後も続いており、その速さは数字に出ています。GitHubのリリース一覧では、1.12.0が2026年9月1日、1.12.6が10月13日で、6週間に6回のパッチ版が出ました。PyPIには10月20日時点で1.13.0rc2と1.14.0の開発版も上がっています。

更新が速いぶん、古い解説の手順はすぐ合わなくなります。この記事の手順は1.12.6で確かめたもので、版をまたぐ場合は公式のリリースノートの破壊的変更を先に読んでください。

1.12で変わった3点

• バンドルの分離：uv pip install langflow は全プロバイダーの部品を入れなくなった。足りない部品は画面に出るがフローが動かず、エラーに出たパッケージ名（例：lfx-exa）を追加で入れる。
• Admin Pageの廃止：画面からのユーザー管理が消え、Users APIで行う。
• 接続先の制限（1.12.4）：PGVectorを localhost や postgres などのホスト名で使っている場合、LANGFLOW_SSRF_ALLOWED_HOSTS に追加しないと接続できない。

Dify・Flowise・n8nとの選び分け

判断基準は「誰が何を運用するか」です。エンジニアが組んだフローを自社のバックエンドからAPIで呼ぶならLangflow、非エンジニアが画面からAIアプリを公開・運用するならDifyが合います。AIは処理の一部で、主役がSaaS間のデータ連携ならn8nのほうが部品がそろっています。DifyでのAIアプリ作成はDifyでチャットボットを作る手順、n8nのWebhook実装はn8nとは？読み方・料金・セルフホストの始め方とWebhook実装で扱っています。

Langflowのインストールと起動手順

導入方法は、デスクトップアプリ、Pythonパッケージ、Dockerの3通りです。手元で触るだけならデスクトップアプリ、サーバーに置くならDockerを選びます。

Langflow Desktop（macOS 13以降・Windows）

Langflow Desktopは依存関係の管理と更新を任せられる版で、macOS 13以降とWindowsに対応します。ダウンロードにはフォームへの入力が必要です。Shareable PlaygroundやVoice Modeなど一部の機能は使えません。Windowsでは「C++ Build Tools Required!」が出たら、案内に従ってMicrosoft C++ Build Toolsを入れます。

uvによるLangflowのPythonパッケージ導入

公式のインストール手順はuvを使います。1.12.6のPython要件は3.10以上3.15未満です。

uv venv langflow-env --python 3.12
source langflow-env/bin/activate   # Windows は langflow-env\Scripts\activate
uv pip install langflow==1.12.6
uv run langflow run                  # http://127.0.0.1:7860 で開く

上のコマンドは版を1.12.6に固定しています。最新版へ上げるときは uv pip install langflow -U です。ポートを変えるには uv run langflow run --port 7880 か環境変数 LANGFLOW_PORT を使います（CLIの指定が優先）。CLIリファレンスによると、指定したポートが使用中なら空いているポートを自動で選ぶため、起動ログに出たURLを確認してください。

Docker版Langflowの起動と必須パスワード設定

以前の解説によくある docker run -p 7860:7860 langflowai/langflow:latest は、1.12.6では起動しません。イメージ langflowai/langflow:1.12.6 を環境変数なしで起動したところ、コンテナは次のログを出して終了しました。

[error] Missing credentials: username=langflow, password=not set
ValueError: Username and password must be set
[error] Application startup failed. Exiting.

公式イメージは LANGFLOW_AUTO_LOGIN=false を既定にしており、スーパーユーザーのパスワードが必須です。Dockerの公式手順どおり、次のように渡すと起動し、/api/v1/version が 1.12.6 を返しました。ユーザー名は既定で langflow です。

docker run -p 7860:7860 \
  -e LANGFLOW_AUTO_LOGIN=false \
  -e LANGFLOW_SUPERUSER_PASSWORD='強いパスワード' \
  langflowai/langflow:1.12.6

このままではフローはコンテナ内のSQLiteに保存され、コンテナを消すと失われます。残すなら、リポジトリの docker_example/docker-compose.yml を使ってPostgreSQLとボリュームを付けた構成にします。版は latest でなく番号で固定すると、更新のタイミングを自分で決められます。

Langflowの使い方：最小フローとLoop

表示言語は1.12.6に日本語の翻訳ファイルが同梱されており、設定のGeneral画面で切り替えられます。

Chat InputからChat Outputまでの4ノード

1. 新規フローを作り、Chat Inputを置く。
2. Promptを置き、テンプレートに {question} のような変数を書いて、Chat Inputの出力をつなぐ。
3. Language Modelを置き、プロバイダーとモデルを選んでAPIキーを設定し、Promptの出力をつなぐ。
4. Chat Outputを置いてLanguage Modelの出力をつなぎ、Playgroundで質問を送る。

APIキーは各コンポーネントに直接書かず、設定のGlobal Variablesに登録して参照します。フローの中に値を直接書かないので、フローを書き出して共有するときにキーが混ざりにくくなります。

Loopによる一覧データの逐次処理

Loopコンポーネントは、CSVの行などのリストを受け取り、1件ずつItemポートへ流します。Itemにつないだ処理の最後をLoopのLoopingポートへ戻すと次の1件に進み、全件が終わるとDoneポートから集約結果が出ます。注意点は、If-ElseコンポーネントがLoopと組み合わせられないことです。条件分岐が必要なら、Loopの前でData Operationsを使ってデータを条件別に分け、それぞれを別のLoopへ渡す構成にします。

WebhookによるLangflowフローの外部起動

Webhookコンポーネントを置いたフローは、外部からのHTTP POSTで起動できます。フォームの送信や監視アラートを受けてLLMで分類・要約し、別のシステムへ書き込むといった使い方です。Webhookの仕組みそのものはWebhookとは？読み方・仕組み・APIとの違いで説明しています。

Webhook→Parser→後続の配線

公式のWebhook手順の基本形は、Webhook、Parser、後続の処理の3段です。WebhookのJSON出力をParserのデータ入力へつなぎ、ParserのTemplateに ID: {id} - Name: {name} のように受け取るJSONのキーを書きます。Parserの出力をLanguage ModelやChat Outputへ渡します。呼び出し先のURLはWebhookコンポーネントのEndpoint欄か、Share→API accessの「Webhook curl」タブからコピーします。

フローのURLにはフローIDの代わりに、API accessで設定したエンドポイント名も使えます。/api/v1/webhook/webhook-verify のような名前で呼んでも、IDと同じく202が返りました。作り直したフローに同じエンドポイント名を設定すれば、送信元のURLを直さずに済みます。

curlで叩いたときの応答（1.12.6で実測）

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"}'

2026年10月20日に、Colima上のDockerでLangflow 1.12.6を起動し、Webhookを置いたフローへ条件を変えて送った応答を並べます。

認証の失敗は401ではなく403で返ります。送信元のリトライ設定で「401だけ再送しない」としている場合は、403も止める対象に入れてください。JSONでない本文は失敗にならず、Webhookの出力が {"payload": "hello plain text"} の形になって後続へ流れました。Parserのテンプレートが {id} を待っていると、ここで組み立てに失敗します。送信元の形式が不確かなうちは、ParserのModeをStringifyにして中身を確認するのが早道です。

Webhookの202応答とフロー結果の確認先

202の応答本文は、どの入力でも {"message":"Task started in the background","status":"in progress"} だけです。1.12.6のソースでも、Webhookの処理は受け付けた時点で裏のタスクに渡し、すぐに応答を返す作りです。フローが途中で失敗しても、送信元には202が返ります。

実測では、Webhook→Parser→Chat Outputのフローに {"id":"12345","name":"alex"} を送ると、Chat Outputの結果「ID: 12345 – Name: alex」がメッセージ履歴（/api/v1/monitor/messages）に残りました。セッションIDはフローIDと同じ値です。結果を外へ渡したいなら、フローの最後にAPI RequestやDBへの書き込みを置くか、次章の /run に切り替えます。

Webhook認証の既定値と1.9.1での変更

現在はWebhookもAPIキーが必須です（LANGFLOW_WEBHOOK_AUTH_ENABLE=True）。ただし、これは1.9.1からの既定値です。GitHubのセキュリティ勧告GHSA-cf6m-vc3m-7cgm（深刻度Critical）によると、この設定が入った1.7.0から1.9.0までは既定値が False でした。その間はフローIDを知っている人なら誰でも、所有者としてフローを実行できました。フローにPythonを実行するコンポーネントがあれば、そのままサーバー上でコードを実行されます。

1.7.0〜1.9.0では、更新までの暫定措置として LANGFLOW_WEBHOOK_AUTH_ENABLE=True を明示してください。1.7.0未満にはこの設定がないため、1.9.1以降へ上げるしかありません。False にした場合、キーのない要求はフロー所有者が送ったものとして扱われます。閉じたネットワークで、フローに外部へ書き込む処理が無いときに限って選ぶ設定です。

GitHub・Stripeなど署名付きWebhookを受けるときの設計

LangflowのWebhookが確認するのはAPIキーだけで、送信元の署名（HMAC）を検証する仕組みはありません。1.12.6のWebhookコンポーネントの入力はPayload、cURL、Endpointの3つで、シークレットを設定する欄が無いことをソースで確認しました。GitHubやStripeのWebhookは送信側で任意のヘッダーを足せないため、直結するならキーをクエリパラメータに入れるしかなく、キーがアクセスログに残ります。

外部SaaSからのWebhookは、間に小さな中継を置くのが安全です。中継が送信元の署名を検証し、通ったものだけを x-api-key ヘッダー付きでLangflowへ転送します。署名の検証と再送への備え（冪等性）の実装はWebhookの作り方と実装方法｜受信側の署名検証・冪等性にコード付きでまとめています。社内のフォームや自前のバッチのように送信元を自分で作れる場合は、ヘッダーでキーを渡せば中継は要りません。

Langflow APIによるフロー実行と結果取得

Webhookが「外部のイベントで起動する入口」なのに対し、実行APIの POST /api/v1/run/{フローIDまたはエンドポイント名} は、アプリ側から呼んで結果をその場で受け取る入口です。各フローのShare→API accessに、Python・JavaScript・curlの呼び出し例が自動で出ます。

/runの主なパラメータ

X-LANGFLOW-GLOBAL-VAR-api-key のように渡した値は大文字の API_KEY として扱われ、OSの環境変数より優先されます。利用者ごとに外部サービスのキーを切り替えたいときに使えます。1.12からは LANGFLOW_TWEAKS_POLICY で、APIの呼び出し元が上書きできる項目を制限でき、拒否された上書きは422（TWEAKS_REFUSED）になります。

/runによるWebhook用フローの同期実行

Webhookの結果が応答に入らない問題は、同じフローを /run で呼び、Webhookコンポーネントへ渡すはずのJSONを tweaks の data に入れると解決します。Webhook用のフローを作り直す必要はありません。

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": "",
       "tweaks": {"Webhook-6d9bb": {"data": "{\"id\":\"777\",\"name\":\"run-api\"}"}}}'

Webhook-6d9bb はフロー内のコンポーネントIDで、コンポーネントの詳細やAPI accessの例で確認できます。data の値はJSONを文字列にしたものです。前章のWebhook→Parser→Chat Outputのフローに送ると、200が0.2秒で返り、outputs[0].outputs[0].results.message.text に「ID: 777 – Name: run-api」が入っていました（LLMを含まないフローでの計測）。キーなしで呼ぶと、こちらも403（An API key must be passed as query or header）です。

長時間かかるフローを非同期で投げ、あとから状態を取りたい場合は、ベータ版のWorkflow API（POST /api/v2/workflows）に sync・stream・background の3モードがあります。ベータのため仕様が変わる前提で使ってください。

APIキーの作り方と自動ログインの関係

APIキーは画面のSettings→Langflow API Keys→Add Newで作るか、スーパーユーザーとして uv run langflow api-key で作ります。--backend-only で画面を出さずに動かしている場合はCLIしか使えません。キーは作った人の権限をそのまま持ち、1人で使う環境では常にスーパーユーザー権限になります。

注意したいのは自動ログインとの関係です。認証の公式説明では、LANGFLOW_AUTO_LOGIN=True にしても画面へのログインが省かれるだけで、APIにはキーが要ります。APIのキーまで省くのは LANGFLOW_SKIP_AUTH_AUTO_LOGIN=true を併せて設定したときだけで、外から届くサーバーでは使わない設定です。

Langflowを公開サーバーに置く前の安全設定

公式のセキュリティ説明は、LangflowをIDEかつコード実行基盤と位置づけています。画面のコードエディタからサーバー上で任意のPythonを実行でき、1つのプロセスの中で利用者同士は隔離されません。社内の複数部署や社外の利用者に1台を共有させるなら、隔離はコンテナやネットワークの側で作る必要があります。

Langflowの未認証RCE勧告と修正版

GitHubのセキュリティ勧告は2026年10月20日時点で37件公開されており、うち17件が深刻度Criticalです（GitHub APIで集計）。とくに影響が大きいものは次のとおりです。

CVE-2025-3248は /api/v1/validate/code に認証なしでコードを送り込める欠陥です。CVE-2026-33017の影響範囲は1.8.2以下とされています。1.8系を「安定版」として使い続けている環境は、この時点で外に出してはいけない状態です。

外部に出す前の最低限の設定

• 最新のパッチ版に上げ、版番号で固定する（1.12系なら1.12.6以降）。
• LANGFLOW_AUTO_LOGIN=False、既定以外の LANGFLOW_SECRET_KEY、LANGFLOW_WEBHOOK_AUTH_ENABLE=True を明示する。
• 認証付きのリバースプロキシの後ろに置き、7860番を直接公開しない。
• 使わないなら LANGFLOW_ENABLE_SUPERUSER_CLI=False で langflow superuser コマンドを止める。
• 1.12以降は LANGFLOW_DEPLOYMENT_PROFILE=prod で、起動前の本番向けチェックを有効にできる。

Langflowを採用しない方がよい場面

画面で組めることと、本番で保守できることは別です。次のどれかに当てはまるなら、Langflowで試作したあとにコードへ移すか、最初から別の手段を選びます。

1つ目は、分岐や状態の管理が多い処理です。Loopの中でIf-Elseが使えないように、部品の組み合わせには制約があり、条件が増えるほど配線図が読めなくなります。状態と分岐をコードで書くならLangGraphでAIエージェントを実装する手順のほうが差分レビューもテストもしやすくなります。2つ目は、パッチ版の更新に追従する体制が無い場合です。6週間で6回のペースで更新が出て、その中に認証まわりの修正も含まれます。更新を止めたまま外部に公開し続けるのは、前章の勧告を見る限り危険です。3つ目は、送信元の署名検証が必須のWebhookを直接受けたい場合で、中継を作るなら最初から受信側をコードで書く方が部品は少なく済みます。

逆に、RAGやエージェントの構成をチームで試し、決まったフローを社内システムからAPIで呼ぶ使い方には合っています。RAGの検索部分をコードで組む場合の手順はLangChainでRAGを構築する手順、回答の誤りを減らす設計はAIハルシネーション対策を参照してください。Langflowで試作したチャットボットを業務システムへ組み込むところまで任せたい場合は、AIチャットボット開発として相談を受けています。

よくある質問

Langflowは無料で使えますか？

本体はMITライセンスのOSSなので、自分のPCやサーバーで無料で使えます。費用がかかるのは、フローから呼び出すOpenAIなど外部LLMのAPI利用料と、サーバーを置く場合のインフラ費用です。

Langflowは日本語に対応していますか？

1.12.6には画面の日本語翻訳ファイルが同梱されており、設定のGeneral画面で表示言語を切り替えられます。プロンプトや入力データは言語を問わず扱え、日本語の出来は選んだLLMの性能で決まります。

Webhookで起動したフローの結果はどこで確認できますか？

Webhookの応答には結果が入りません。Chat Outputまで流れた結果はメッセージ履歴（/api/v1/monitor/messages）に残り、画面のPlaygroundでも見られます。呼び出し元で結果を受け取りたいなら、同じフローを /api/v1/run で呼び、Webhookへのデータを tweaks で渡します。

Langflowの起動ポート7860は変えられますか？

変えられます。uv run langflow run --port 7880 か環境変数 LANGFLOW_PORT で指定し、両方あればCLIの指定が優先されます。Dockerでは -p 8080:7860 のようにホスト側のポートを変えます。

LangflowのWebhookにAPIキーは必須ですか？

1.9.1以降は既定で必須で、キーが無いと403が返ります。LANGFLOW_WEBHOOK_AUTH_ENABLE=False で外せますが、キーなしの要求がフロー所有者の操作として実行されるため、閉じたネットワーク以外では外さないでください。

関連記事

• Webhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説
• Webhookの作り方と実装方法｜受信側の署名検証・冪等性と送信側の再送をNode.js・Pythonで解説
• n8nとは？読み方・料金・セルフホストの始め方とWebhook実装を解説【2026年10月版】
• Difyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】
• LangGraphでAIエージェントを実装する手順：状態管理から承認フローまで