AIプラットフォームの抽象化の境界――複雑さを最終的に引き受けるのは誰か
最近、Factoryを使っている。
Claude Codeが高い能力を持つCoding Agentだとすれば、Factoryが目指しているものはもっと大きい。ソフトウェア開発を、Agentが動かす一つの生産システムとして組織することだ。エンジニアがコードを書くのを支援するだけでなく、計画、実装、テスト、レビューまで扱おうとしている。より大きなタスクでは、Missionsが作業を分解してWorkerを割り当て、マイルストーンの完了時にはValidatorによる結果の検証も行う。
この設計の背後には、一つの問いがある。プラットフォームはユーザーに代わって複雑さを引き受けているのか。それとも、もとの複雑さを、別の学ぶべき概念に置き換えているだけなのか。
Difyはどのハードルを下げたのか
初めてDifyに触れたとき、多くのことが直感的に感じられた。いくつかのノードを置き、モデルとナレッジベースを接続し、必要なツールを加えれば、すぐにAIアプリを作れる。最初からコードを書くのに比べれば、確かにハードルは大きく下がった。
しかし企業環境に入ると、別の複雑さが少しずつ現れてくる。
利用者はWorkflow、Agent、検索拡張生成（RAG）、変数、ツール呼び出し、ナレッジベース、モデルごとの違いを理解する必要がある。自社環境に導入するなら、Kubernetes、データベース、ネットワーク、権限、バージョンアップ、プラグイン、ライセンスにも対処しなければならない。
DifyはAIアプリを作り始めるハードルを下げたが、現実の環境で運用する際の複雑さまで消したわけではない。複雑さの分担を変えただけだ。一部はプラットフォームが引き受け、残りはDifyを利用・運用するために必要な知識になった。
これは必ずしも製品設計の問題ではない。企業向けソフトウェアはもともと、権限、セキュリティ、安定性、他システムとの連携に向き合わなければならず、プラットフォームがそれらを無から消し去ることはできない。本当に注目すべきなのは、どの複雑さをユーザー自身が理解しなければならず、どの複雑さが製品の成熟とともにさらに吸収されていくかである。
同じ枠組みでFactoryを見る
Factoryは、Agent Systemを一から構築するよりはるかに簡単だ。Missionsはすでに計画、実行、検証を一つの流れとしてまとめ、システムにはWorkerとExplorerも組み込まれている。Subagentは標準でメインセッションのモデルとReasoning Effortを継承でき、タスクの複雑さに応じてモデルを選ぶこともできる。簡単なタスクにはMissionを起動せず、通常のセッションをそのまま使うよう、公式ドキュメントは勧めている。
こうした初期設定と組み込みの役割を見る限り、Factoryは編成のすべてをユーザーに委ねているわけではない。タスクに応じて、そのまま使える経路を用意しようとしている。
使い続けると、それでも利用者は新たな選択に直面する。
Orchestratorにはどのモデルが適し、Workerにはどのモデルが適するのか。
Validatorには、より高性能なモデルを使うべきか。それとも、より低コストなモデルを使うべきか。
Reasoning Effortはどの程度に設定すべきか。
どのタスクをSubagentに分け、どのタスクは一つのAgentに続けて処理させるほうがよいのか。
Agent Systemを研究するのが好きな人にとって、こうした問いは興味深い。より細かく制御できること自体が、製品の魅力にもなり得る。しかし多くのユーザーが本当に解決したいのは、おそらく「このバグを直してほしい」、あるいは「この要望をもっと早く本番環境へ届けたい」ということだ。関心があるのは成果であり、その前にモデルやAgentの編成に詳しくなりたいとは限らない。
プラットフォーム化は単純化ではない
プラットフォームには、能力を外に見せようとする自然な力が働く。ノード、モデル、Worker、検証方法をユーザーが設定できてこそ、十分に多くの用途を扱え、初期の専門的なユーザーにも応えられるからだ。
だから、初期段階の複雑さ自体は恐れるものではない。Kubernetes、Terraform、Datadogも、最初から簡単に使えたわけではない。専門的なツールは、まず必要な能力を成立させて初めて、実際の利用に合わせて複雑さを吸収していける。
本当に優れたプラットフォームは、いまユーザーに見せている複雑さを、最終的には再び内部へ取り込まなければならない。
いまユーザーが自分で選んでいるモデルも、将来はシステムがタスクとリスクに応じて自動的に振り分けられる。タスクを分割するか、Workerをどう構成するかも、システムが判断できる。同じことは検証にも言える。検証の強度は変更範囲と失敗時の代償に応じて決まるべきで、毎回ユーザーが一から設計する必要はないかもしれない。
Factoryはすでに、組み込みのWorker、モデルの継承、複雑さの段階分けによって、選択の一部を減らしている。Missionsも、もともと手作業で構築しなければならなかった複数のAgentによる協働を、ユーザーに代わって組織している。問題は、複雑さの吸収を始めているかどうかではない。この道を最終的にどこまで進めるかである。
ユーザーが伝えるのは実装ではなく制約
成熟したAI製品は、ユーザーにモデルをますます深く理解するよう求めるのではなく、自分の問題をますます正確に表現できるよう支えるべきだ。
たとえば、ユーザーが伝えるのは次のことだけでよい。
これは本番環境のバグである。
品質を最優先する。
2時間以内に完了する。
コストは最優先ではない。
Subagentに分けるか、Workerをいくつ起動するか、どのモデルを選ぶか、いつ検証するか、失敗後により強いモデルへ切り替えるかは、システムがこうした制約に基づいて判断できる。
ユーザーが本当に気にかけることは、それほど変わっていない。結果がよいか、速いか、コストが高いか。内部でどのモデルを使い、いくつのAgentを動かし、どう編成するかは、本質的には実装手段である。安定した結果を得るために、ユーザーがまずその手段を理解しなければならないのなら、製品の抽象化にはまだ進化の余地がある。
この製品を使う前に、それに固有の概念をどれほど学ばなければならないか。
ユーザーが学ぶのが、ソフトウェア開発、営業、カスタマーサポート、法律といった自分の仕事であれば、その知識は判断を直接改善できる。しかしNode、Worker、Mission、Validator、Router、Context Strategyを理解するために多くの時間を費やすのなら、製品はなお、内部の複雑さのかなりの部分をユーザー側に残している。
設定がすべて消える必要はない。専門的なユーザーにはデバッグの入口が必要であり、企業もコスト、セキュリティ、モデル利用のルールを管理する必要がある。よい抽象化とは、多くの人が設定しなくても信頼できる結果を得られる一方で、必要なときには介入できることだ。
AIプラットフォームを評価するなら、どれだけ多くの能力を見せているかだけではなく、最終的にユーザーからどれだけの複雑さを引き受けられるかを見るべきだ。
Factoryを面白いと感じるのは、まさにこの問いに、まだまったく決着がついていないからである。