序章｜Difyマーケットプレイスは「流行」ではなく「現実」を映す
Difyに関する記事は、すでに十分すぎるほど出揃っている。
インストール手順、RAGの組み方、PDFを放り込んでそれらしく答えさせる方法。
どれも間違ってはいないが、正直に言えば、いまさら付け加えることは少ない。
しかし、Difyというプロジェクトの本質は、
「何ができるか」ではなく
「何が実際に使われているか」
にこそ現れている。
その最も率直な答えが、Difyマーケットプレイスだ。
マーケットプレイスは、思想や理想を語らない。
READMEも、スライドも、未来予測もいらない。
そこにあるのは、ただ一つ。
ダウンロード数。
それはユーザーが実際に選び、
時間や金銭、あるいは運用リスクを引き受ける覚悟で
手を伸ばした痕跡である。
本稿では、このDL数を
「人気ランキング」として消費しない。
また、ツール紹介やおすすめリストにもしない。
DL数を
行動経済の痕跡、
現実解の集合として読み解く。
・なぜ、あるモデルが選ばれ
・なぜ、あるツールが捨てられ
・なぜ、ある機能は“便利なのに”使われないのか
そこには、生成AIを取り巻く
2025年時点の冷えた現実が、そのまま露出している。
この分析は、
「Difyの使い方」を説明するものではない。
Difyを通して見える、生成AIインフラの現在地を記録する試みだ。
ハンズオンは行わない。
セットアップも書かない。
成功例も失敗談も出さない。
数字だけを頼りに、
静かに地層を掘り下げていく。
第1章｜モデル層：なぜ「OpenAI互換」がすべてを飲み込んだのか
Difyマーケットプレイスのモデルカテゴリを開いた瞬間、
最初に目に入るのは“多様性”ではない。
異様な集中だ。
Ollama、OpenAI、Tongyi、DeepSeek、SiliconFlow。
その直後に現れるのが OpenAI-API-compatible という一群。
ここに、ローカル勢も、OSS勢も、クラウド勢も、まとめて吸い込まれている。
この分布が示しているのは、
「どのモデルが賢いか」という競争ではない。
どの話し方をするか、
もっと正確に言えば、
どのAPIで話せるかという競争だ。
OpenAI互換とは、モデルの話ではない
「OpenAI互換」という言葉は、誤解を生みやすい。
これはOpenAIのモデルを使うことを意味しない。
また、性能や品質を保証する概念でもない。
指しているのは、ただ一つ。
OpenAIが定義したAPI仕様で会話できること。
- リクエスト形式
- ロール構造
- ストリーミング
- エラーハンドリング
この“話法”が、事実上の業界標準になった。
その結果、世界中のプロバイダとOSSが
「中身は違うが、喋り方は同じ」
という方向に収束していく。
Difyのモデル層における
OpenAI互換の圧倒的なDL数は、
この収束がすでに完了したことを示している。
賢さより、差し替え可能性
ここで重要なのは、
ユーザーは賢さを比較していないという点だ。
- 少し賢い
- 少し速い
- 少し安い
それらは選定理由の上位に来ていない。
選ばれているのは、
- APIを変えずに
- モデルだけ差し替えられる
- ベンダーを跨いでも壊れない
という 交換可能性 である。
この思想において、
モデルは“主役”ではない。
部品だ。
LM Studioが示す、匿名化という現象
この文脈で見ると、
LM StudioのDL数が相対的に低く見える理由も明確になる。
LM Studioが劣っているのではない。
むしろ逆だ。
LM Studioは、
OpenAI互換という大きな影の中に溶け込んでいる。
Difyユーザーは、
- LM Studioを選んでいるのではない
- OpenAI互換を選んだ結果、
その裏側としてLM Studioが使われている
この匿名化は、
価値が下がったことを意味しない。
価値が抽象化されたことを意味する。
モデル競争の終点
このモデル層が示している現実は、
生成AIの競争軸がすでに変わったことだ。
- 賢さ → 規約
- 独自性 → 互換性
- 主張 → 沈黙
Difyのマーケットプレイスは、
この変化を美化せず、そのまま提示している。
モデルは語らない。
ただ、差し替えられる。
ここに、
2025年の生成AIインフラの
冷えた成熟がある。
第2章｜ツール層：Playwrightが消え、API Key組が生き残った理由
Difyマーケットプレイスのツール欄を眺めていると、
ある種の“偏り”がすぐに見えてくる。
検索、スクレイピング、データ取得。
いずれも似た目的を持つはずのツール群だが、
DL数にははっきりとした勝者と敗者が存在する。
勝っているのは、例外なく API Key 前提 のツールだ。
Google SERP、Bing、Tavily、Firecrawl、Jina。
いずれも「契約」「課金」「制限」を前提にしている。
一方で、
ブラウザ自動化やローカル実行を想起させる手段は、
最初から主戦場にすら立っていない。
Playwrightが“消えた”理由
ここで誤解してはいけない。
PlaywrightやSeleniumが技術的に劣っているわけではない。
むしろ、できることは圧倒的に多い。
しかし、Dify文脈では
できすぎることが致命傷になる。
- 実行環境の差
- ブラウザ更新
- セレクタ破壊
- Bot対策
- 法的グレーゾーン
これらすべてを
「ツールとして内包する」瞬間、
Difyはアプリ基盤ではなく
運用地獄に変わる。
Difyユーザーは、そこまでを求めていない。
API Key がふるいにかける客層
API Key前提のツールが強い理由は単純だ。
責任の所在が明確だから。
- 料金は誰が払うのか
- 利用規約を誰が読むのか
- 失敗したとき誰が責任を持つのか
これらを、
ツール側ではなくユーザー側に押し戻す。
その瞬間、
客層が一段階、きれいに選別される。
- 無料で試したい人
- 魔法のボタンを探している人
こうした層は、
API Keyの入力画面で自然に脱落する。
結果として残るのは、
商用耐性を持ったユーザーだ。
画像生成ツールが語る、同じ構図
この構造は、画像生成ツールにもそのまま当てはまる。
- ComfyUI
- Stability系API
- SiliconFlow
これらはすべて
API利用、あるいは高度な前提知識を要求する。
一方、
Stable Diffusion WebUIのような
「ローカルで全部できる」構成は、
Dify文脈では扱いが難しい。
理由は単純だ。
素人に開放しても、碌な絵が出ない。
それだけではない。
- プロンプト地獄
- モデル地獄
- VRAM地獄
Difyが目指しているのは
“表現の自由”ではなく
結果の安定性だ。
ツール層が示す、冷静な割り切り
この層が語っているのは、
生成AIに対する一種の諦観だ。
- 完璧にやろうとしない
- 全部を内包しない
- 外部に責任を逃がす
その代わり、
- 壊れない
- 説明できる
- 請求書が出る
この3点を満たす。
Difyにおけるツールは、
能力拡張装置ではない。
運用可能性を担保するための境界線だ。
第3章｜トリガー層：誰も使っていないのではなく、使う人が違う
Difyマーケットプレイスの中で、
最も誤解されやすいカテゴリがトリガーだ。
DL数だけを見れば、
「誰も使っていない」
「不人気」
そう切り捨てたくなる。
だが、その解釈は浅い。
トリガーは、
“触って楽しい層”のための機能ではない。
トリガーが要求するもの
トリガーとは何か。
それは単なる「入力経路」ではない。
- Webhook
- 非同期処理
- 冪等性
- 再試行
- 障害時の振る舞い
こうした概念を、
前提として理解している人間にしか、
トリガーは開かれない。
つまり、トリガーは
PoCのための装置ではない。
DL数が少ない理由は、使われていないからではない
トリガーが伸びない理由は明確だ。
Difyの多くのユーザーは、
まだそこに到達していない。
- チャットで試す
- ワークフローで組む
- ツールを繋ぐ
この段階までは、
同期的・対話的な操作で事足りる。
だがトリガーは違う。
「AIが勝手に動き出す」世界を扱う。
それは、
責任と監視と運用を伴う世界だ。
それでもトリガーは“死んでいない”
興味深いのは、
DL数が少ない中でも
並んでいる名前が非常に実務寄りな点だ。
- Gmail
- GitHub
- RSS
- Stripe
- Calendar
これらは“遊び”ではない。
業務イベントそのものだ。
トリガーを使う人間は、
Difyを「話し相手」とは見ていない。
処理装置として見ている。
トリガーは沈黙するが、消えない
この層が示している現実は、
残酷で、しかし健全だ。
- 多くの人は、トリガーを必要としない
- 一部の人は、トリガーなしでは仕事にならない
その二極化が、
DL数にそのまま表れている。
トリガーは流行らない。
だが、廃れもしない。
それは、
使う人間が明確に限定されているからだ。
第4章｜拡張機能層：MCPの氾濫が示す「Dify中継港化」
拡張機能の一覧を見て、まず目につくのは
MCPの異様な存在感だ。
MCP server、MCP compatible tools、MCP agent。
名称違い、実装違いはあれど、
上位に並ぶ拡張の多くが、同じ方向を向いている。
それは「Difyを賢くする」方向ではない。
Difyを“通す”方向だ。
MCPは自律AIのための技術ではない
MCP（Model Context Protocol）は、
しばしば「エージェント進化の鍵」のように語られる。
だが、マーケットプレイスの数字が示しているのは
もっと冷静な役割だ。
MCPは、
- 思考を高度化する技術ではない
- 判断を任せる仕組みでもない
接続規約である。
Difyのワークフローやツールを、
外の世界に“規格化された形”で差し出すための
インターフェース。
つまり、
Difyを「完結するAI」にするためではなく
他のシステムに組み込むための出口
として使われている。
Difyは完成品ではなく、中継港になった
この傾向を素直に読むなら、
Difyの立ち位置は明確だ。
- 最終アプリではない
- 自律エージェントの終着点でもない
AI処理の中継港。
入力を受け、
必要な処理を行い、
結果を規約に沿って外へ渡す。
MCP拡張のDL数が伸びているのは、
この使われ方が
すでに実務で成立している証拠だ。
WebRTCが伸びない理由は「重いから」ではない
同じ拡張カテゴリにありながら、
WebRTC系の拡張は振るわない。
理由は技術的難易度ではない。
Difyユーザーに技術力が足りないからでもない。
思想が合っていない。
WebRTCは、
- 常時接続
- 状態管理
- レイテンシ制御
を前提とする。
それは、
Difyが避け続けてきた領域だ。
Difyは「会話」を扱うが、
通信インフラを背負う気はない。
拡張機能層が示す、明確な意思
拡張機能の分布が語っているのは、
次の一点に尽きる。
Difyは“考えるAI”ではなく
“渡すAI”として使われている
考えた結果を、
APIとして、
Webhookとして、
MCPとして、
外に渡す。
この割り切りがあるからこそ、
Difyは壊れにくい。
第5章｜データソース層：S3が選ばれなかった冷酷な理由
データソースの一覧は、
この分析全体の中でも、最も露骨だ。
Notion、Google Drive、Firecrawl、Jina Reader。
上位に並ぶのは、人間が日常的に使っている場所ばかりである。
その一方で、
クラウドストレージの王者であるはずの
AWS S3 は、驚くほど存在感が薄い。
これは技術の敗北ではない。
文脈の敗北だ。
Difyが欲しているのは「データ」ではない
ここで重要なのは、
Difyが求めているものが
「大量のデータ」ではないという点だ。
Difyが欲しているのは、
- 誰かが読んだ
- 誰かが整理した
- 誰かが意味を付けた
情報の置き場である。
NotionやGoogle Driveが強い理由は単純だ。
そこには、すでに人間の判断が介在している。
- このページは残す
- この資料は共有する
- この文章は最新版だ
そうした選別の痕跡が、
最初から存在する。
S3は悪くない。ただ、何も語らない
S3は優秀だ。
- 安い
- 壊れない
- いくらでも入る
だが、S3は沈黙している。
- これは何の資料か
- どれが正しいのか
- 今も使うべきか
そのどれにも答えない。
Difyの文脈では、
その沈黙は致命的だ。
RAG以前に発生する「意味付けコスト」
S3をDifyで使おうとした瞬間、
ユーザーはある事実に直面する。
RAGの前に、
人間がやることが多すぎる。
- フォルダを決める
- ファイルを分ける
- 名前を付ける
- 更新を管理する
これらは、
AIの仕事ではない。
そしてDifyユーザーは、
その労力をすでに別の場所で払っている。
だから、
- Notionが選ばれ
- Driveが選ばれ
- Firecrawlが選ばれる
S3は「意味を持たない」まま、
置き去りにされる。
決定打は、あまりにも現実的だ
この層を読み切るために、
難しい理屈はいらない。
バックアップを
Difyでわざわざやるか？
答えは明白だ。
Difyは保管庫ではない。
意味の入口だ。
データソース層が暴いた真実
この層が突きつけている現実は、
生成AI時代のストレージ観を根底から変える。
- 安さは武器にならない
- 容量は評価されない
- 意味がすべてだ
Difyはそれを、
無言のDL数で示している。
第6章｜エージェント戦略層：自律AI幻想の終焉
エージェント戦略のDL数分布は、
この分析の中で最も“正直”だ。
上位を占めているのは、
- 公式の Agent Strategies
- MCP対応の Agent
- Function Calling／ReAct 系
いずれも共通しているのは、
野心的でないという点である。
選ばれているのは「賢いエージェント」ではない
ここでユーザーは、
高度な思考や創発を求めていない。
選ばれているのは、
- 予測可能
- 分解可能
- 失敗しても説明できる
間違えにくい戦略だ。
Dialogue Agent のような
対話特化型が一定数に留まっているのも、
同じ理由による。
会話は楽しいが、
仕事を任せるには危うい。
MCP対応が示す、役割の確定
MCP対応エージェントが支持されている事実は、
エージェントの役割が
すでに確定していることを示す。
それは、
自律的に考える存在ではなく
規約に従って呼び出される存在
であるということだ。
エージェントは、
- 主体ではない
- 意志を持たない
- 責任も負わない
ただ、
定義された振る舞いを実行する部品として
扱われている。
自律AIが選ばれなかった理由
自律AIという概念は、
魅力的だ。
だが、マーケットプレイスの数字は
その魅力が実務に届いていないことを示している。
- 勝手に判断する
- 勝手に動く
- 勝手に失敗する
これらは、
プロダクトとしては致命的だ。
Difyのユーザーは、
そこまでAIを信頼していない。
それは悲観ではなく、
健全な現実認識である。
エージェント戦略層が告げる終点
この層が語っているのは、
生成AIにおける一つの区切りだ。
- エージェントは夢を見ない
- 主体性は持たない
- 思考は委ねられない
代わりに、
- 接続され
- 呼び出され
- 結果を返す
この役割に徹する。
Difyにおけるエージェントは、
人格ではなく、規約だ。
終章｜Difyが示しているのは「AIの未来」ではない
ここまで、モデル、ツール、トリガー、拡張機能、データソース、エージェント戦略と、
Difyマーケットプレイスの全レイヤーを数字だけで読み解いてきた。
そこに一貫して流れている思想は、驚くほど地味だ。
- 圧倒的に賢いものは選ばれない
- 夢のあるものは伸びない
- 完結するものは好まれない
代わりに選ばれているのは、
- 差し替えられる
- 壊れにくい
- 説明できる
という、極めて現実的な要件である。
Difyは未来を語っていない
Difyは、しばしば
「次世代AIアプリ基盤」
「ノーコードAI革命」
のような言葉で語られる。
だが、マーケットプレイスの数字は、
そうした未来志向の物語を一切支えていない。
ここにあるのは、
- 自律AIの夢ではない
- AGIへの期待でもない
- 創発への賛歌でもない
今この瞬間に、実務で使えるかどうか
という一点だけだ。
全レイヤーを貫く共通原理
全カテゴリを通して、同じ構図が繰り返されている。
- モデル層：賢さより互換性
- ツール層：自由度より責任の所在
- トリガー層：万能性より運用前提
- 拡張機能層：完結より中継
- データソース層：量より意味
- エージェント戦略層：主体性より規約
これは偶然ではない。
生成AIが“技術”から“インフラ”に移行した証拠だ。
Difyは「現在地」を可視化する装置である
Dify自身が優れているかどうかは、
本稿の主題ではない。
重要なのは、
Difyマーケットプレイスが
ユーザーの無言の選択を集約する装置になっていることだ。
そこには、
- 謳い文句はない
- 理想論もない
- 未来予測もない
ただ、
「使われた」という事実だけが積み上がる。
その地層を掘れば、
生成AIインフラの現在地が、
嫌というほど露わになる。
結論は、驚くほど冷たい
Difyが示しているのは、
AIの輝かしい未来ではない。
AIと人間が、どこで線を引いたか
という記録だ。
- 考えるのは人間
- 判断も人間
- 責任も人間
AIは、
- 呼び出され
- 処理し
- 返す
その役割に、静かに収まった。
Difyマーケットプレイスは、
その合意形成の結果を、
一切の感情抜きで提示している。
それこそが、
この数字群の持つ本当の価値だ。
