💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「プロンプト一行でGPTを呼ぶ時代は終わった。2026年のLLMアプリは、RAG検索・ツール呼び出し・評価・ガードレール・コスト追跡が一つのグラフの中で結合されたシステムだ。ノーコードビルダーは、そのグラフを非エンジニアが組み立てられるようにするインフラである。」 — Jerry Liu、LlamaIndex CEO、AI Engineer Summit 2025 基調講演

LLMアプリを作るという行為は、2023年の「OpenAI API呼び出し＋プロンプト一行」から、2024年には「LangChainチェーン＋ベクターDB」、2025年には「エージェント＋ツールライブラリ＋評価パイプライン」、そして2026年現在は「RAG＋ワークフロー＋ガードレール＋コスト追跡＋可観測性」へと進化しました。同じ時期にノーコードAIビルダーのカテゴリは、Flowise・Langflow・Dify・Cozeが市場を定義し、非エンジニアが直接LLMアプリを構築できる時代を切り拓きました。

2026年5月現在、ノーコードAIビルダー市場の中心的な問いはもはや「どのLLMを使うか」ではありません。「どのツールを束ねてどのワークフローを作り、どう評価し、どうセルフホストするか」です。本稿では、ノーコードAIビルダーの市場地図、Flowise・Langflow・Dify・Cozeの4大ビルダーの深層比較、Microsoft Promptflow・Vectara・LlamaIndex Cloudなどのエンタープライズ／マネージドオプション、Vellum・Humanloop・LangSmith・Langfuseといった評価・可観測性の生態系、そしてOpenAI Custom GPTs・Anthropic Claude Projectsといったビッグテックのノーコード参入、韓国・日本のローカライゼーション事例までを一本にまとめます。

1. ノーコードAIビルダーが重要になった理由

2023年にはLLMアプリを作るために、Python・LangChain・ベクターDB・埋め込みモデル・評価スクリプトをすべて自分で書く必要がありました。2026年にはノーコードAIビルダーがこれらをすべてグラフ型キャンバスとして抽象化しています。この変化の意味は三つあります。

第一に、**ビジネスアナリストの直接構築（シチズンビルダー）**が可能になったことです。CSチームが自分のFAQをRAG化してチャットボットを作り、マーケティングチームが自分のコピーライティング規則をプロンプトに登録し、セールスチームが自分のリードスコアリングロジックをワークフロー化する時代です。

第二に、**プロンプト＋RAG＋ツール呼び出し＋評価が一箇所で**起きるようになりました。以前はプロンプトはGitHub、RAGはLangChain、評価は別のノートブック、運用は別のサービスに散らばっていました。ノーコードビルダーはこれを一つのグラフに統合し、「プロンプト一行を変えれば評価が自動で走り、本番環境も同時に更新される」一貫した環境を提供します。

第三に、**セルフホスティング選択肢が豊富になった**ことです。Flowise・Langflow・Difyはすべてオープンソースで、Docker一行で立ち上げられ、医療・金融・政府のような厳しいデータ残留要件を持つドメインでもLLMアプリを構築できるようになりました。

2. 2026年ノーコードAIビルダー市場地図

ノーコードAIビルダーは「ユーザー親和性」と「エンタープライズ親和性」の二軸で五つの象限に分けられます。

| カテゴリ | 代表的なツール | 対象ユーザー |

|---|---|---|

| グラフ型LLMビルダー | Flowise、Langflow、Rivet | グロースエンジニア、シニアIC |

| チャットボット＋ワークフローSaaS | Dify、Coze、Stack AI | 非エンジニア＋フルスタック |

| 対話型エージェントビルダー | Voiceflow、Botpress、Crewstack | CS・セールス運用チーム |

| 評価／可観測性 | Vellum、Humanloop、LangSmith、Langfuse、Helicone、Arize Phoenix | MLエンジニア、MLOps |

| マネージドRAG／プラットフォーム | Vectara、LlamaIndex Cloud、Microsoft Promptflow | エンタープライズIT |

これらの象限間の境界は急速にぼやけつつあります。Flowiseは単純なLLMビルダーとして始まったがマーケットプレイスとAgentflowを追加してDifyの領域に踏み込み、Difyは自前の可観測性ダッシュボードを強化してLangfuseの領域と重なるようになりました。LlamaIndexはSDKでしたが、LlamaCloudというマネージドRAGサービスへと拡張し、Vectaraの領域を狙っています。

**選択の最初の分岐点**は「チームにコードを書く人がいるか」です。いる場合はFlowise・Langflow・Rivet・Promptflowが強力です。いない場合はDify・Coze・Stack AI・Voiceflowが速いです。**二つ目の分岐点**は「データがクラウドを離れられるか」です。離れられない場合はセルフホスト可能なFlowise・Langflow・Dify・Promptflow・Botpressが候補に残り、離れられる場合はマネージドオプションも候補に入ります。

3. Flowise 2.x — LangChain JSベースのマーケットプレイス

Flowise（`flowise.ai`）は2023年にFlowiseAI Incが作ったオープンソースLLMビルダーです。ライセンスはMITで、GitHubスター約3.4万個と、ノーコードAIビルダーのカテゴリで最大のコミュニティを抱えています。2026年5月時点で2.xシリーズが本番稼働中です。

主な特徴を整理すると次の通りです。

- **ドラッグ＆ドロップのLangChain JSノード**：LangChainのすべてのLLM、ベクターストア、チェーン、メモリ、ツールノードをビジュアルキャンバスで組み立て可能。

- **ChatflowとAgentflowの二つのモード**：Chatflowは静的なLLMチェーン、Agentflowはツールを動的に呼び出すエージェント。

- **マーケットプレイス**：コミュニティが共有したテンプレートをワンクリックで取り込んで開始（Customer Support Bot、SQL Agent、Multi-PDF QAなど）。

- **埋め込み可能なウィジェット**：作ったチャットボットを一行のJavaScriptスニペットで自社サイトに埋め込み可能。

- **API自動生成**：ワークフローを保存すれば、自動的にREST APIとpredictionエンドポイントが生成される。

Flowiseの強みは**LangChain JSエコシステムの吸収力**です。LangChainに新ノードが登場すれば、ほぼそのままFlowiseにも追加されます。JavaScript/TypeScriptバックエンドを持つチームは、Flowiseワークフローをそのまま自社コードベースに埋め込めます。

弱点は**運用／評価機能の弱さ**です。可観測性は外部ツール（Langfuse、LangSmith）に依存しており、自前の評価パイプラインはまだ初期段階です。エンタープライズで運用するにはLangfuseやHeliconeを追加する必要があります。

Flowiseセルフホスト一行

docker run -d --name flowise -p 3000:3000 -v ~/.flowise:/root/.flowise flowiseai/flowise

4. Langflow 1.x — Pythonベース・DataStaxが買収

Langflow（`langflow.org`）は2023年にリリースされたPythonベースのLLMビルダーです。2024年にデータインフラ企業DataStaxが買収して本格的なエンタープライズ投資が始まり、2025年に1.x正式リリース以降急成長中です。ライセンスはMITです。

Langflowの主な差別化要素は**Pythonベース**である点です。FlowiseがJavaScript陣営であれば、Langflowは Pythonデータサイエンティストの自然な選択です。LangChain Pythonのすべてのノード、LlamaIndex統合、HuggingFaceモデル、Pinecone/Chroma/Weaviateベクターストアがすべて一級市民として扱われます。

2025-2026年の主要機能を整理すると次の通りです。

- **Visual Graph**：ノード＋エッジベースのグラフUI。分岐、結合、ループがひと目で見える。

- **JSON Export/Import**：ワークフローをJSONにエクスポートしてGitHubでバージョン管理。

- **Python カスタムコンポーネント**：自分のPythonクラスをコンポーネントとして登録してマーケットプレイスで共有。

- **Astra DB統合**：親会社DataStaxのAstra DBを一級ベクターストアとしてサポート。

- **Langflow Cloud**：マネージドホスティング選択肢。セルフホストなしですぐに開始可能。

Langflowの強みは**Pythonエコシステムとの滑らかな接続**です。作成したグラフをPythonにエクスポートして自社バックエンドに埋め込んだり、逆にPythonコードをコンポーネントに変換してグラフに入れたりできます。データサイエンスチームがノートブックで作ったRAGパイプラインをそのままノーコードグラフに変換するシナリオが強力です。

弱点は**JavaScript埋め込みの弱さ**です。フロントエンドにウィジェットを差し込むシナリオではFlowiseの方が滑らかです。またグラフが複雑になるとUIが重くなる傾向があり、50以上のノードを持つ大きなグラフは分割運用が推奨されます。

Langflowセルフホスト（uv推奨）

uv pip install langflow

uv run langflow run

5. Dify — ワークフロー＋エージェント＋ナレッジベースのフルスタックビルダー

Dify（`dify.ai`）は2023年に中国発でリリースされたオープンソースLLMアプリ開発プラットフォームで、Apache 2.0ライセンスで運用されています。2026年5月時点でGitHubスター約7万個と、ノーコードAIビルダーカテゴリの絶対的強者の一つです。

Difyの最大の差別化要素は**総合プラットフォーム**である点です。Flowise・Langflowが「グラフを作る」という一つのことに集中しているのに対し、Difyはワークフロービルダー、チャットボットビルダー、ナレッジベース管理、プロンプトIDE、可観測性ダッシュボード、利用量請求までをすべて一箇所に詰め込んでいます。

主要モジュールは五つです。

- **Workflow**：グラフ型の多段ワークフロー。分岐、ループ、並列処理すべてサポート。

- **Agent**：ReActベースの動的ツール呼び出しエージェント。OpenAI Function Callingと互換。

- **Knowledge Base**：ドキュメントアップロード → 自動チャンキング → 埋め込み → ベクターインデックス → クエリ。

- **Prompt IDE**：プロンプトのA/Bテスト、変数管理、バージョン管理。

- **API Backend**：すべてのアプリは自動的にOpenAI互換APIエンドポイントを持ち、即座にクライアントから呼び出し可能。

Difyの強みは**即時運用可能なパッケージ**である点です。モデルキーを入れるだけでチャットボットUI、ナレッジベースアップロード、ワークフロービルダー、APIキー発行、利用量ダッシュボードがすべて起動した状態で出てきます。小さなチームが素早くPoCを作るとき、圧倒的に速いです。

また**モデル抽象化**が強力です。OpenAI、Anthropic Claude、Google Gemini、Azure OpenAI、AWS Bedrock、Cohere、Mistral、Together AI、Replicate、Ollama、vLLMなど30以上のプロバイダーを統一インターフェースで使用できます。韓国のHyperCLOVA X、中国のQwen、Doubaoのような地域モデルも一級でサポートされます。

弱点は**カスタマイズの限界**です。パッケージの完成度が高い分、深くカスタマイズしようとするとPythonバックエンドとReactフロントエンドを直接修正する必要が出ます。またノード種類がFlowise・Langflowより少ないため、特殊なツールは直接APIで呼び出す必要があります。

DifyのDocker Composeセルフホスト

git clone https://github.com/langgenius/dify.git

cd dify/docker && docker compose up -d

6. Coze — ByteDanceのボットビルダーとDoubaoモデル

Coze（`coze.com`、中国本土は`coze.cn`）は、ByteDanceが2024年にグローバル公開したボットビルダーです。親会社VolcengineのDoubao（豆包）LLMシリーズをベースとし、グローバル版ではOpenAI GPT-4とAnthropic Claudeも使用可能です。

Cozeの主な差別化要素は**ボット＋プラグインマーケットプレイス**です。Flowise・Langflow・Difyが「グラフを作って運用する」ツールであれば、Cozeは「ボットを作ってプラットフォーム（Telegram、Discord、WeChat、Feishu、Lark）にデプロイする」ツールです。

主要機能を整理すると次の通りです。

- **Bot Builder**：チャットボットをノーコードフォームで設計。ペルソナ、開始メッセージ、FAQ、ツールを一画面で設定。

- **Plugin Marketplace**：200以上の事前統合プラグイン（画像生成、検索、翻訳、コード実行など）。

- **Workflow**：Difyスタイルのグラフ型多段ワークフロー。

- **Knowledge**：ドキュメントアップロード → RAG自動構成。

- **Multi-channel Deploy**：作ったボットをTelegram、Discord、Feishu、Lark、WeChat、Coze Storeへ即座にデプロイ。

- **Doubao LLMファミリー**：ByteDance自前のLLM。Doubao-pro-32kはGPT-4oに近い水準で、価格が非常に安価。

Cozeの強みは**B2Cチャットボットデプロイ速度**です。Telegramボットを30分以内に作って公開でき、Coze Store（グローバル）に投稿すれば追加のマーケティングなしでユーザーに発見されます。日本のLINEと韓国のKakaoTalk統合は弱いものの、Telegram・Discordベースのグローバルコミュニティボット市場では強力です。

弱点は**データレジデンシー**と**ベンダーロックイン**です。データはByteDanceインフラに留まり、セルフホスト選択肢がなく、医療・金融などの規制産業には不向きです。またワークフローを他のビルダーに移行することが難しく、一度作るとCozeの中に留まることになります。

7. n8n AIノード — ワークフロー自動化＋LangChain統合

n8n（`n8n.io`）は元々iPaaSですが、2024年にLangChainベースのAIノードパッケージを追加してノーコードAIビルダーカテゴリにも参入しました。別のiPaaS記事で詳しく扱っていますが、ここではAIノード部分のみ追加で整理します。

n8nのAIノードは次のように構成されます。

- **AI Agent Node**：LangChainのAgentExecutorをノードとして抽象化。ツールノードを接続して動的呼び出し。

- **LLM Chain Node**：単純なプロンプト → 応答チェーン。

- **Vector Store Nodes**：Pinecone、Qdrant、Weaviate、Supabase Vector、PGVector。

- **Embedding Nodes**：OpenAI、HuggingFace、Cohere。

- **Memory Nodes**：Window Buffer、Summary、Vector Store Memory。

- **Tool Nodes**：HTTP Request、Code、Vector Store Retrieval、Calculator、SerpAPIなど。

n8nの強みは**ワークフロー自動化＋AIの結合**です。Gmailトリガー → AI分類 → Slack通知 → Notionデータベース保存といったシナリオを一つのワークフローで作れます。600以上の統合とAIノードが同じキャンバスにあることが大きな強みです。

弱点は**AI専用機能の深さ**です。RAGパイプラインのチャンキング戦略、評価、ガードレールのような深い機能はDify・Flowise・Langflowに比べて弱いです。AIがワークフローの一部であるときに適しており、AIがワークフローの全部であるときには専用ビルダーの方が強いです。

8. Rivet — Ironcladのデスクトップ向けGUIグラフビルダー

Rivet（`rivet.ironcladapp.com`）は、契約自動化企業Ironcladが2023年にオープンソースで公開したデスクトップ向けLLMグラフビルダーです。ライセンスはMITで、他のビルダーと異なり**Electronベースのデスクトップアプリ**として動作します。

Rivetの差別化要素は**ローカルファースト**である点です。グラフファイルは.rivet-project拡張子のJSONとしてディスクに保存され、GitHubでバージョン管理されます。実行はローカルで起き、APIキーもローカル環境変数で管理されます。

主要機能を整理すると次の通りです。

- **Visual Graph Editor**：ノード＋エッジベースのビジュアルグラフビルダー。Subgraphで再利用可能なモジュール構成。

- **Plugin System**：TypeScriptベースのプラグインSDKで自前のノードを記述。

- **Embed in App**：Rivetグラフを自前のTypeScript/JavaScriptアプリに埋め込み、ランタイムで実行。

- **Debug Mode**：各ノードの入出力を可視化しながらデバッグ。ブレークポイント対応。

Rivetの強みは**開発者親和的UX**です。Subgraph、変数、デバッガー、JSONエクスポートはコード開発に近い体験を提供します。実際にIroncladは自社製品のLLMパイプラインをRivetで作って運用しています。

弱点は**マーケットプレイスとSaaSホスティングの不在**です。セルフホストSaaS UIがないためチーム単位の共有はGitHubのみ可能で、非エンジニアが直接触るには学習曲線があります。1人開発者や小さなチームのローカルツールに最も適しています。

9. Vectara — マネージドRAGサービス

Vectara（`vectara.com`）は2023年に創業されたマネージドRAGサービスです。自前のLLM「Boomerang」と自前の埋め込みモデルを使って、ドキュメントアップロードから検索・要約までフルパイプラインをマネージド提供しています。

Vectaraの差別化要素は**RAG-as-a-Service**です。ユーザーがすることは「ドキュメントアップロード → API呼び出し → 回答を受け取る」がすべてで、チャンキング、埋め込み、ベクターインデックス、クエリリライト、回答生成、引用挿入までVectaraがすべて処理します。

主要機能を整理すると次の通りです。

- **Boomerang LLM**：Vectara自前のファインチューニング済みLLM。RAG回答生成に特化。

- **Hallucination Detection**：HHEM（Hughes Hallucination Evaluation Model）という自前のハルシネーション検出モデルを無料提供。

- **Citation自動挿入**：回答に原文引用を自動挿入。

- **Vectara Console**：ノーコードダッシュボードでcorpus管理、クエリテスト、APIキー発行。

- **OpenAPI互換**：REST APIですべての機能を呼び出し可能。

Vectaraの強みは**運用のシンプルさ**です。RAGパイプライン運用に必要な意思決定（チャンクサイズ、埋め込みモデル、検索アルゴリズム、リランキング）をすべてVectaraが決定します。PoCを素早く作って運用負担を減らしたいエンタープライズに適しています。

弱点は**カスタマイズの限界**です。埋め込みモデル、チャンキング戦略、LLMをユーザーが直接選べないため、特殊なドメイン（法務、医療）では自前のLangChain/LlamaIndexパイプラインの方が適している場合が多いです。

10. Microsoft Promptflow — Azure ML統合のPython DAG

Microsoft Promptflow（`microsoft.github.io/promptflow`）はAzure MLチームが2023年にオープンソース公開したプロンプトDAGランタイムです。MITライセンスで、Azure ML Studioに統合されてマネージドホスティングも提供します。

Promptflowの差別化要素は**Pythonコードファーストのなかでのグラフ**です。Flowise・Langflowがビジュアルキャンバスを中心に置きPythonを補助として使うとすれば、Promptflowは YAML/Pythonで書かれたDAGが一級市民で、VSCode拡張とAzure ML Studioがビジュアルインターフェースを提供します。

主要機能を整理すると次の通りです。

- **Python DAG Runtime**：各ノードはPython関数、入出力はtyped argumentで明示。

- **Jinja Prompt Templates**：プロンプトファイルは.jinja2テンプレートとして分離。

- **Batch Run & Evaluation**：データセットに対するバッチ実行＋評価指標計算が一級機能。

- **VSCode Extension**：グラフ可視化、デバッグ、トレースビューア。

- **Azure ML Studio統合**：マネージドホスティング、エンドポイントデプロイ、A/Bテスト。

Promptflowの強みは**Azure陣営統合**と**評価ファーストの設計**です。Azure OpenAI・Azure AI Search・Azure MLすべてが一級統合されており、評価がツールの中核機能なのでRAG精度測定、ハルシネーション比較、別のプロンプトバージョン比較といった作業が速いです。

弱点は**非エンジニア親和性**です。本質的にコードファーストツールであるため、ビジネスアナリストが直接触ることは難しいです。またAzure依存性が強く、別のクラウドへ移行する際に一部統合を書き直す必要があります。

11. LlamaIndexとLlamaCloud — マネージドRAGの進化

LlamaIndex（`llamaindex.ai`）は元々RAG SDKとして始まりましたが、2024-2025年にLlamaCloud、LlamaParse、LlamaHubといったマネージドサービスを追加してフルスタックRAGプラットフォームに拡張しました。SDKはMITライセンス、クラウドはマネージドSaaSです。

主要プロダクトラインを整理すると次の通りです。

- **LlamaIndex (SDK)**：Python/TypeScript RAGフレームワーク。LangChainと並ぶ二大山脈。

- **LlamaParse**：PDF/Excel/PPTなど複雑なドキュメントをLLM親和的マークダウンに変換するマネージドサービス。表・画像・数式の保存が強力。

- **LlamaCloud**：マネージドインデックス＋クエリAPI。ドキュメントアップロード → 自動埋め込み → API呼び出しで回答を受け取る。

- **LlamaHub**：200以上のデータローダー、埋め込み、LLM統合のマーケットプレイス。

- **Create-LlamaApp**：CLIでRAGアプリのボイラープレートを即座に生成。

LlamaIndexの差別化要素は**ドキュメント処理の深さ**です。LlamaParseはPDFから表を正確に抽出し、数式をLaTeXで保存し、画像をマルチモーダルLLMが理解可能な形に変換します。複雑なPDFが多いドメイン（法務、学術、医療）で強力です。

弱点は**ノーコードUIの不在**です。SDKは強力ですが、非エンジニアが直接触るUIはLlamaIndex自体にはありません。Flowise/LangflowがLlamaIndexをノードとして吸収して提供する形が一般的です。

12. Stack AI — エンタープライズAIビルダーとSSO

Stack AI（`stack-ai.com`）は2023年にMIT出身の創業者が作ったノーコードAIビルダーで、2024-2025年にエンタープライズ市場に集中し、SAML SSO、RBAC、監査ログ、オンプレデプロイ選択肢を強化しました。

主な差別化要素を整理すると次の通りです。

- **ドラッグ＆ドロップビルダー**：Flowise・Langflowと類似のノードグラフUI。

- **Enterprise SSO**：Okta、Azure AD、Google Workspace統合。

- **On-prem & Private Cloud**：ユーザーのインフラにStack AIをデプロイしてデータが外に出ないようにする。

- **No-code Frontend**：作成したワークフローを自動的にホストされるフォーム／チャットボット／ダッシュボードUIに変換。

- **Document Q&A特化テンプレート**：50以上の事前ビルドテンプレート。

Stack AIの強みは**エンタープライズガバナンス**です。セキュリティ認証、ユーザー管理、監査ログ、データ残留がすべて揃っており、大企業のIT部署が導入意思決定を素早く下せます。

弱点は**オープンソース不在**と**価格**です。オープンソース選択肢がなく、エンタープライズプランが年間数万ドルから始まります。小さなチームやPoCにはFlowise・Langflow・Difyの方が適しています。

13. VoiceflowとBotpress — 対話型エージェントビルダー

Voiceflow（`voiceflow.com`）とBotpress（`botpress.com`）は、LLM浮上前からチャットボット／ボイスボットビルダーとして運用されてきたツールで、2024-2025年にLLM統合を強化してノーコードAIビルダーカテゴリに合流しました。

Voiceflowの特徴は次の通りです。

- **対話フロービルダー**：対話ノード、分岐、ユーザー変数をビジュアル設計。

- **NLU＋LLMハイブリッド**：精度が重要な分岐はNLUインテント分類、自由対話はLLMが処理。

- **多チャンネル**：Webチャット、WhatsApp、Telegram、Alexa、Google Assistant、Twilio音声。

- **API自動生成**：対話フローを外部システムから呼び出し可能なAPIとして公開。

Botpressの特徴は次の通りです。

- **オープンソースコア＋クラウド**：コアエンジンはAGPL、クラウドはマネージドSaaS。

- **LLM Studio**：自前のLLMベースのチャットボットビルダー。GPT-4、Claude、Geminiなど多モデル。

- **Knowledge Base**：ドキュメントアップロード → 自動RAG。

- **Channel Bridges**：Slack、Discord、WhatsApp、Telegram、Messenger、Teamsの即座な統合。

これら二つのツールの強みは**対話フローの精密な設計**です。単純なチャットボットではなく、CSエージェント、予約ボット、リード資格検証ボットといったビジネスシナリオで分岐・検証・ハンドオフを精密に作れます。

弱点は**ワークフロー一般化の弱さ**です。対話フローに特化している分、一般的なデータ処理ワークフロー（例：PDF一括分類、Slack通知生成）はFlowise・Langflow・Difyの方が自然です。

14. VellumとHumanloop — マネージドプロンプト＋評価

Vellum（`vellum.ai`）とHumanloop（`humanloop.com`）はノーコードAIビルダーの隣接カテゴリである**プロンプト管理＋評価プラットフォーム**です。ワークフローよりは「プロンプトのライフサイクル」に集中しています。

Vellumの中核機能は次の通りです。

- **Prompt Playground**：複数モデル・複数プロンプトバージョンを横並びで比較。

- **Workflow Builder**：プロンプトとツールを組み合わせた多段ワークフロー。

- **Test Suites**：データセットベースの自動評価（精度、レイテンシー、コストを同時に追跡）。

- **Production Monitoring**：本番稼働中のプロンプトのハルシネーション、レイテンシー、コストをリアルタイム追跡。

Humanloopの中核機能は次の通りです。

- **Prompt File**：プロンプトをコードのようにバージョン管理（Git親和的な.prompt形式）。

- **Evaluators**：ユーザー定義の評価者（LLM-as-judge、正規表現、コード評価）。

- **Logs + Datasets**：本番ログを評価データセットに自動変換。

- **Human Review**：人間の評価者が応答を検証してラベリング。

これら二つのツールの強みは**プロンプトエンジニアリングの産業化**です。プロンプト作成 → テスト → デプロイ → モニタリングの全過程を一箇所で管理し、新しいモデルリリース（GPT-5、Claude 4.5）が出たときに既存のプロンプトたちがどう動作するかを自動で比較できます。

弱点は**ワークフロービルダーの深さ不足**です。複雑なRAG＋ツール呼び出し＋分岐ワークフローはFlowise・Langflow・Difyの方が強力で、Vellum・Humanloopはその中の「プロンプト一つ」を深く管理する用途に適しています。

15. LangSmith・Langfuse・Helicone・Arize Phoenix — 可観測性

ノーコードAIビルダーで作ったLLMアプリは本番運用に入るとトレーシング、コスト追跡、エラーモニタリング、評価が必要になります。この領域の4大ツールを整理します。

- **LangSmith**：LangChain本家が作ったマネージドトレーシング。LangChain・LangGraph・LangServeと最も滑らかに統合。価格はやや高い。

- **Langfuse**（`langfuse.com`）：オープンソース（MIT）の代替。セルフホスト可能、Postgres＋ClickHouseバックエンド。トレーシング、評価、データセット、プロンプト管理をすべて含む。

- **Helicone**（`helicone.ai`）：OpenAI APIプロキシ方式。コード1行変更ですべてのLLM呼び出しを自動でロギング・キャッシュ・コスト追跡。

- **Arize Phoenix**（`phoenix.arize.com`）：Arize AIのオープンソース可観測性。OpenInference標準のトレーシング、Jupyter親和的なUI。

選択の分岐点を整理すると次の通りです。

| シナリオ | 推奨ツール |

|---|---|

| LangChain本陣、マネージド希望 | LangSmith |

| オープンソース＋セルフホスト＋フルスタック | Langfuse |

| OpenAI呼び出しシンプルプロキシ＋キャッシュ | Helicone |

| モデル運用＋評価中心、Python親和 | Arize Phoenix |

ほとんどのノーコードビルダー（Flowise、Langflow、Dify、n8n）はこれらのツールと統合されており、別途設定でトレースを送信できます。例：LangfuseはFlowiseの環境変数一行で有効化されます。

Flowise＋Langfuse統合（環境変数一行）

LANGFUSE_PUBLIC_KEY=pk-... LANGFUSE_SECRET_KEY=sk-... LANGFUSE_HOST=https://cloud.langfuse.com

16. OpenAI Custom GPTsとAssistants API

OpenAIは2023年11月のChatGPTカンファレンスで**Custom GPTs**と**Assistants API**を発表し、ビッグテックがノーコードAIビルダー市場に参入しました。

**Custom GPTs**はChatGPT Plusユーザーがノーコードで作るチャットボットです。

- 指示（Instructions）：ペルソナ、行動規則を自然言語で記述。

- 知識（Knowledge）：ファイルアップロードして自動RAG。

- アクション（Actions）：OpenAPIスペックで外部API呼び出しを定義。

- ビルダー対話：GPT自体と対話しながら作る（メタ）。

- 配布：GPT Storeで発見可能。ChatGPTの中でのみ使用。

**Assistants API**は開発者がOpenAIインフラ上でRAG・ツール呼び出し・threadsメモリをマネージドで使うAPIです。

- File Search（マネージドベクター検索）。

- Code Interpreter（Pythonサンドボックス）。

- Function Calling（ユーザー定義ツール）。

- Threads（対話メモリのマネージド）。

OpenAIノーコード選択肢の強みは**消費者へのリーチ**です。GPT Storeは数億人のChatGPTユーザーに直接露出されるチャンネルなので、B2Cボットの配布で強力です。またGPT-4o、GPT-5の最新機能が最も早く入ります。

弱点は**ベンダーロックイン**と**セルフホスト不在**です。ChatGPTに依存し、データがOpenAIインフラに留まり、モデルの選択肢がOpenAI一箇所に縛られます。マルチLLM、セルフホスト、データレジデンシーが必要なシナリオではDify・Flowiseの方が適しています。

17. Anthropic Claude ProjectsとClaude Skills

Anthropicは2024-2025年にかけて**Claude Projects**、そして2025年末に**Claude Skills**をリリースして、ノーコードAIビルダー市場に参入しました。

**Claude Projects**はClaude.aiユーザーが作るワーキングスペースです。

- システムプロンプト（Custom Instructions）とファイルコンテキストを束ねて保存。

- 一つのProjectの中の対話は同じシステムプロンプト＋同じファイルコンテキストで維持。

- Pro/Team/Enterpriseプランで使用。EnterpriseはProject単位の権限管理。

**Claude Skills**は2025年末にリリースされたモジュール式能力パッケージです。

- SKILL.mdファイルに自然言語で手順を記述。

- references/フォルダに補助資料、scripts/フォルダに実行可能なスクリプト。

- Claudeが作業コンテキストを検出して自動で適切なSkillを呼び込む。

- Anthropic公式Skills（docx、pdf、xlsx）とコミュニティのSkillsマーケットプレイス運営。

Claude Skillsの差別化要素は**自然言語ベースの能力構成**です。コードを書かずにマークダウンで「この作業が来たらこの手順に従って、必要ならこのスクリプトを呼び出せ」を定義するとClaudeがそのまま実行します。

強みは**Anthropicモデルの品質**と**Skillのモジュール性**です。Claude Opusは長文コンテキスト、精緻な推論、安全性で強力で、SkillはGitHubリポとして共有可能なのでコミュニティ成長が速いです。

弱点は**エージェントワークフロー不在**です。ProjectとSkillはいずれも「対話中にClaudeが使うツール」であり、Flowise・Difyのように外部トリガーで起動する自動化ワークフローではありません。その領域はClaude API＋Claude Agent SDK＋外部ビルダーの組み合わせで解決します。

18. Crewstack、Magic.AIといった新規参入者

2025-2026年にかけて新規ノーコードAIビルダーが急速に登場しています。主な新規参入者を整理すると次の通りです。

- **Crewstack**（`crewstack.ai`）：CrewAIベースのマルチエージェントビルダー。役割（Role）ベースのエージェントチームをノーコード設計。

- **Magic.AI**（`magic.dev`）：コード生成＋自動化結合ビルダー。AIが自身のワークフローをデバッグ・修正。

- **Sider AI Agent**（`sider.ai`）：ブラウザサイドバー＋マルチモデル統合。ノーコードボット生成。

- **Fixie**（`fixie.ai`）：LLMエージェント＋ツールマーケットプレイス。2024年Salesforceが買収。

- **GenAI Studio（Google Cloud）**：Vertex AI上のノーコードビルダー。Gemini・PaLM統合。

これら新規参入者の共通の流れは**エージェントチーム**です。単一のLLM呼び出しから「複数エージェントが協業するワークフロー」に移行しており、CrewAI・AutoGen・LangGraphといったマルチエージェントフレームワークがこの流れを下支えしています。

新規ツールを導入する際に考慮するチェックリストは次の通りです。

1. **データレジデンシー**：セルフホスト可能か？クラウドのみであればデータはどこに留まるのか？

2. **ベンダーロックイン**：ワークフローを他のツールにエクスポートできるか？

3. **モデル選択**：単一モデルか、30以上のプロバイダー抽象化か？

4. **運用可観測性**：自前のトレースか、Langfuseのような外部ツールと統合されているか？

5. **価格モデル**：使用量ベースか、ユーザーベースか、評価呼び出しも課金されるか？

19. セルフホスティングの意思決定 — Docker/K8sに載せる方法

オープンソースのノーコードビルダーの最大の強みはセルフホスティングです。Flowise・Langflow・DifyをDocker/K8sに載せる方法を整理します。

**Flowise**（Docker単独）：

docker run -d --name flowise -p 3000:3000 \

-e FLOWISE_USERNAME=admin -e FLOWISE_PASSWORD=secret \

-v ~/.flowise:/root/.flowise \

flowiseai/flowise:latest

**Langflow**（Docker Compose）：

services:

langflow:

image: langflowai/langflow:latest

ports:

- "7860:7860"

environment:

- LANGFLOW_DATABASE_URL=postgresql://user:pass@db:5432/langflow

depends_on:

- db

db:

image: postgres:16

environment:

- POSTGRES_USER=user

- POSTGRES_PASSWORD=pass

- POSTGRES_DB=langflow

**Dify**（公式Docker Compose）：

git clone https://github.com/langgenius/dify.git

cd dify/docker

cp .env.example .env

docker compose up -d

デフォルトポート80番でアクセス、管理者アカウント初期設定

**Kubernetesデプロイ**（Helm chart例）：

Flowise Helm chart

helm repo add flowise https://flowiseai.github.io/helm-charts

helm install flowise flowise/flowise --namespace flowise --create-namespace

Langflow Helm chart（DataStax公式）

helm repo add langflow https://langflow-ai.github.io/langflow-helm-charts

helm install langflow langflow/langflow-runtime --namespace langflow --create-namespace

セルフホスト時に考慮すべき運用要素は次の通りです。

- **Stateバックアップ**：FlowiseはSQLiteをデフォルト使用するがPostgresへ移すのが推奨。LangflowとDifyはPostgres必須。

- **Vector Store**：自前のPGVector、Qdrant、Weaviateを同時運用すればデータレジデンシー確保。

- **APIキー管理**：OpenAI/AnthropicキーはHashiCorp VaultやK8s Secretに保管。

- **トレーシング**：Langfuseを一緒にセルフホストすればフル可観測性が完成。

20. 韓国市場 — HyperCLOVA Studio、Kakao i RPA AI、Upstage

韓国でのノーコードAIビルダーの中核的流れは二つです。第一にグローバルのFlowise・Langflow・Difyの韓国語PoC導入が急速に増えており、第二にNaver・Kakao・Upstageといった国内プレイヤーが自前のノーコードツールを強化しています。

**Naver Cloud HyperCLOVA X Studio**：

- HyperCLOVA X韓国語LLMベースのノーコードビルダー。

- 韓国語データレジデンシー、金融業界認証。

- 韓国語RAG精度がグローバルモデルより強い（特に敬語表現、韓国固有表現）。

- Difyの韓国語オプションと比較して選択するシナリオが増えている。

**Kakao i RPA＋Kakao i Studio**：

- KakaoエンタープライズのRPAツールがLLM統合を強化。

- KoGPTベースのチャットボットビルダーがKakaoTalkチャネルと一級統合。

- 韓国企業メッセンジャー自動化で圧倒的なチャネル優位。

**Upstage Document Parse＋Conversation**：

- Upstage Solar LLMベース＋Document Parse（PDF抽出）結合ノーコードビルダー。

- 韓国語ドキュメント（特に表形式）処理精度がLlamaParseと比較しても優位。

- 韓国の医療・法務ドメインでPoC採用が急速に増えている。

韓国市場でノーコードAIビルダー導入時に最も重要な決定要素は**韓国語精度**と**KakaoTalk/Naverチャネル統合**です。グローバルツールは韓国語埋め込みが英語比で弱く、KakaoTalkチャネル連携が難しい場合が多いです。そのためグローバルビルダー＋国内LLM抽象化＋KakaoTalkチャネルアダプターの組み合わせが頻繁に採用されます。

21. 日本市場 — Microsoft Tokyo AI、SoftBank GenAI、Sakana AI

日本市場でのノーコードAIビルダーの流れは韓国と類似していますが、いくつかの特殊性があります。

**Microsoft Tokyo Research / Azure Japan**：

- Microsoftが東京にAI研究所拡張を発表（2024年）。

- Azure OpenAI Serviceの日本リージョン強化でデータレジデンシー確保。

- Promptflow＋Azure AI Searchの組み合わせが日本の大企業で採用率トップ。

**SoftBank GenAI / SB Intuitions**：

- SoftBankグループが作った日本語LLM「Sarashina」とノーコードビルダー。

- LINE、Yahoo! Japan、Rakutenチャネル統合が強い。

- 日本のSI（システムインテグレーター）会社との連携が強く、日本の大企業導入で速い。

**Sakana AI**：

- 東京拠点のAIスタートアップ。「AI Scientist」でグローバル認知度。

- 自前のLLMとオープンソースツール活用を強調しており、ノーコードビルダーカテゴリに直接参入はしていないものの、日本企業のFlowise/Langflow導入をコンサルティングで支援。

**日本市場の特殊性**：日本はグローバルツールの日本語精度が韓国語より相対的に高い（GPT-4oの日本語品質が韓国語より高い）ので、グローバルビルダー（Flowise、Langflow、Dify）をそのまま採用する比率が韓国より高いです。ただし日本のSI文化上、セルフホストとSI会社のパッケージ導入比率が非常に高く、Stack AI・Promptflow・Boomiといったエンタープライズオプションの選好が強いです。

22. 実際の使用事例 — カスタマーサポート、ドキュメントQ&A、内部検索、自動化

ノーコードAIビルダーで作られる代表的な使用事例4つを整理します。

**1）カスタマーサポートチャットボット**：

- トリガー：Webチャットウィジェット、KakaoTalkチャネル、Slack DM。

- ノードの流れ：ユーザー入力 → 意図分類 → FAQ RAG検索 → 回答生成 → 人間ハンドオフ（低信頼度時）。

- 推奨ビルダー：Voiceflow、Dify、Coze。

**2）社内ドキュメントQ&A**：

- トリガー：Slack/Teamsスラッシュコマンド、社内ポータル検索窓。

- ノードの流れ：質問入力 → Confluence/Notion/Google Drive RAG検索 → 回答生成＋原文引用 → Slack応答。

- 推奨ビルダー：Flowise、Langflow、Dify、Vectara。

**3）内部知識検索＋要約**：

- トリガー：従業員がクエリ入力。

- ノードの流れ：クエリ入力 → ベクター検索 → リランキング → LLM要約 → 引用表示。

- 推奨ビルダー：LlamaIndex Cloud、Vectara、Dify Knowledge Base。

**4）マルチチャネル自動化**（Slack/Email/CRM結合）：

- トリガー：Gmail新規メールまたはSalesforce新規リード。

- ノードの流れ：トリガー → AI分類 → CRM更新 → Slack通知 → 応答メール下書き。

- 推奨ビルダー：n8n＋AIノード、Zapier Agents、Make AI Agents。

各使用事例ごとに中核の意思決定は「RAGが正確であるべきか、ワークフローが多様であるべきか、チャネル統合が強いべきか」です。RAG精度が中核ならVectara・LlamaIndex Cloud、ワークフロー多様性が中核ならDify・Flowise・Langflow、チャネル統合が中核ならn8n・Zapier・Make＋AIノードが適しています。

23. ワークフローパターン — トリガー → RAG → LLM → 出力 → ハンドオフ

ノーコードAIビルダーで作るほぼすべてのLLMアプリは、次の5ステップパターンに従います。

**Step 1: トリガー（Trigger）**

- Webチャットウィジェット、REST APIエンドポイント、スケジュール（cron）、イベント（Slackメンション、メール受信）。

- ユーザー入力を受け取ってワークフローを開始。

**Step 2: RAG検索（Retrieval）**

- ユーザークエリをベクター埋め込みに変換。

- ベクターDB（Pinecone/Qdrant/PGVector）から類似ドキュメントtop-k検索。

- リランキングモデルで精度向上（例：Cohere Rerank、BGE Rerank）。

**Step 3: LLMプロンプト（Generation）**

- ユーザークエリ＋検索されたドキュメント＋システムプロンプトを結合。

- LLM呼び出し（GPT-4o、Claude Sonnet、Gemini 1.5）。

- 回答生成＋引用追加。

**Step 4: 出力（Output）**

- 回答をユーザーに返却。

- 同時にログ（Langfuse）、CRM更新、Slack通知などの副次効果。

**Step 5: ハンドオフ（Handoff）**

- 自動処理が困難な場合に人間にエスカレーション。

- Slackチャネル通知、メール送信、チケット作成。

このパターンがノーコードビルダーの標準になった理由は**シンプルさ＋拡張性**です。単純なチャットボットもこの5ステップで作れ、複雑なマルチエージェントシステムもこの5ステップが複数回呼ばれる形に拡張されます。

ノーコードビルダーの標準ワークフローをYAMLで表現する例

trigger:

type: webhook

path: /chat

nodes:

- id: retrieve

type: vector_search

config:

collection: company_docs

top_k: 5

- id: rerank

type: cohere_rerank

config:

top_n: 3

- id: prompt

type: llm

config:

model: gpt-4o

system: 'Answer the user question using only the provided context.'

- id: respond

type: webhook_response

24. Zapier/Make/n8n AIエージェントとの連携

ノーコードAIビルダーは単独でも運用可能ですが、しばしばiPaaS（Zapier、Make、n8n）と連携して使用されます。代表的な連携パターン3つを整理します。

**パターン1：iPaaSトリガー → ビルダー呼び出し**：

- ZapierがGmail新着メールを検知 → Dify API呼び出し → 回答生成 → Slack通知。

- iPaaSがトリガーとチャネルを担当、ビルダーがLLMロジックを担当。

**パターン2：ビルダーがツールとしてiPaaSを呼び出し**：

- FlowiseエージェントがMakeのwebhookをツールとして呼び出し。

- ユーザーが「顧客Xにメールを送れ」と言うとFlowise → Make → SendGridチェーンを実行。

**パターン3：サイドバイサイド運用**：

- iPaaSは単純な自動化（決まったトリガー-アクション）、ビルダーはLLM意思決定。

- 同じデータ（例：Salesforceリード）に対してiPaaSが日常自動化、ビルダーが分類／優先順位。

n8nの場合は**二つが一つに統合**されます。n8nキャンバスにワークフロー自動化ノードとLangChain AIノードが一緒にあって外部ビルダーが不要です。小さなチームがPoCを作るときに最も速い道です。

パターン1の例：ZapierがDify APIを呼び出し（Code by Zapier）

response = requests.post(

'https://api.dify.ai/v1/chat-messages',

headers={'Authorization': 'Bearer YOUR_DIFY_KEY'},

json={

'inputs': {},

'query': inputData['email_subject'],

'user': inputData['email_sender'],

'response_mode': 'blocking',

)

output = {'reply': response.json()['answer']}

25. 限界 — 複雑なマルチステップ、ベンダーロックイン、プロンプトドリフト

ノーコードAIビルダーの時代が来たからといってすべてのLLMアプリをノーコードで作れるわけではありません。限界を正直に整理します。

**限界1：複雑なマルチステップ＋分岐**

- 20以上のノードの複雑なグラフはビジュアルUIが逆に可読性を落とす。

- デバッグ、ユニットテスト、漸進的リファクタリングがコードより難しい。

- 100以上のノード規模は結局LangChain・LlamaIndexコードに移すのが合理的。

**限界2：ベンダーロックイン**

- Dify・Coze・Stack AIはワークフローをエクスポートしにくい（JSONで抜いてもその形式が自社ツール専用）。

- Flowise・LangflowはJSONエクスポートが標準だが、結局そのツールのノード定義に縛られている。

- セルフホスト可能なオープンソースオプションを好む理由。

**限界3：プロンプトドリフト**

- ノーコードUIでプロンプトを頻繁に修正していると、バージョン管理が難しくなる。

- 「昨日はうまくいったのに今日は動かない」のデバッグがコードベース＋Git管理より大変。

- Humanloop・Vellum・LangSmithのような外部プロンプト管理ツールを一緒に使うことが推奨される。

**限界4：評価の弱さ**

- ノーコードビルダー自体には評価機能が弱いかない。

- 本番運用に入るとハルシネーション、レイテンシー、コストを追跡する必要があるが、これは結局Langfuse・LangSmith・Heliconeのような可観測性ツールが必要。

**限界5：新機能導入速度**

- LLM陣営の新機能（例：GPT-5 reasoning、Claude tools、Gemini 2.0マルチモーダル）はSDKが最初に受け取る。

- ノーコードビルダーはSDKリリース後1〜2ヶ月後にノードを追加するのが一般的で、最新機能活用が遅い。

これらの限界のために結局ノーコードビルダー＋SDKコード＋可観測性ツールの組み合わせが標準になります。PoCと非エンジニア構築はノーコード、複雑な運用ロジックはSDKコード、運用追跡は可観測性。三つすべてが必要です。

まとめ — ビルダーは抽象化に過ぎず、結局LLMアプリの本質を理解する必要がある

2026年のノーコードAIビルダーは「LLM呼び出し＋RAG＋ツール＋評価」の四重奏を非エンジニアでも組み立てられるようにしました。Flowise・Langflow・Difyがオープンソース陣営の三大将になり、OpenAI Custom GPTs・Anthropic Claude Skillsがビッグテックのノーコード参入を始め、Vectara・LlamaIndex Cloud・PromptflowがマネージドRAG市場を定義しています。Vellum・Humanloopがプロンプトライフサイクルを産業化し、LangSmith・Langfuse・Helicone・Arize Phoenixが可観測性を埋めました。

しかしツールが抽象化するからといって本質が消えるわけではありません。RAGのチャンキング戦略を知らなければハルシネーションは減らず、プロンプトエンジニアリングのパターンを知らなければノードをいくらうまく配置しても回答品質は上がらず、評価指標を定義できなければ運用で何が壊れているか見えません。ノーコードビルダーは「簡単に」作れるようにするツールではなく「速く」作れるようにするツールであり、作った後の品質と運用は結局人の理解にかかっています。

2026年後半に注目すべき流れ三つを最後に整理します。第一に、**マルチエージェントビルダー**が単一LLMビルダーを急速に吸収するでしょう。CrewAI・AutoGen・LangGraphがノーコード陣営に拡散し、「エージェントチームをノーコードで設計」するシナリオが標準になります。第二に、**評価の標準化**が起きるでしょう。Vellum・Humanloop・LangSmithの評価形式がOpenInference標準と統合され、ビルダーを変えても評価データセットは持ち越せるようになります。第三に、**ローカルLLMとの結合**が強くなるでしょう。Ollama・llama.cpp・Mistral.rsで起動したローカルモデルをFlowise・Difyが一級市民としてサポートし、データレジデンシー＋コスト削減シナリオが標準になります。

ツールを選ぶ仕事はLLMアプリ開発の最初のステップに過ぎず、最後のステップではありません。自チームのデータレジデンシー要件、非エンジニアの比重、運用可観測性水準、そして何より「このLLMアプリが誰にどんな価値を与えるか」を明確にしてからツールを選べばよいです。その答えを持つチームにはノーコードAIビルダーが強力な武器になり、その答えを持たないチームにはビルダーがあっても良いLLMアプリは出てきません。

参考資料

- Flowise公式ドキュメント — https://docs.flowiseai.com/

- Flowise GitHub — https://github.com/FlowiseAI/Flowise

- Langflow公式ドキュメント — https://docs.langflow.org/

- Langflow GitHub — https://github.com/langflow-ai/langflow

- Dify公式ドキュメント — https://docs.dify.ai/

- Dify GitHub — https://github.com/langgenius/dify

- Coze公式サイト — https://www.coze.com/

- n8n AIノードドキュメント — https://docs.n8n.io/advanced-ai/

- Rivet公式サイト — https://rivet.ironcladapp.com/

- Vectara公式ドキュメント — https://docs.vectara.com/

- Microsoft Promptflowドキュメント — https://microsoft.github.io/promptflow/

- LlamaIndex公式ドキュメント — https://docs.llamaindex.ai/

- LlamaCloud — https://cloud.llamaindex.ai/

- Stack AI — https://www.stack-ai.com/

- Voiceflowドキュメント — https://docs.voiceflow.com/

- Botpressドキュメント — https://botpress.com/docs/

- Vellum AI — https://www.vellum.ai/

- Humanloop — https://humanloop.com/

- LangSmith — https://smith.langchain.com/

- Langfuse — https://langfuse.com/

- Helicone — https://www.helicone.ai/

- Arize Phoenix — https://phoenix.arize.com/

- OpenAI Custom GPTs — https://openai.com/blog/introducing-gpts

- OpenAI Assistants API — https://platform.openai.com/docs/assistants/overview

- Anthropic Claude Projects — https://www.anthropic.com/news/projects

- Anthropic Claude Skills — https://www.anthropic.com/news/skills

- CrewAI — https://www.crewai.com/

- Naver Cloud HyperCLOVA Studio — https://www.ncloud.com/product/aiService/clovaStudio

- Kakao i — https://kakaoi.kakao.com/

- Upstage Solar — https://www.upstage.ai/

- SB Intuitions — https://www.sbintuitions.co.jp/

- Sakana AI — https://sakana.ai/

- Microsoft Tokyo AI発表 — https://news.microsoft.com/ko-kr/2024/04/10/microsoft-announces-29-billion-investment-japan/