AgentKitの発表に対して
10/6にOpenAIからAgentKitの発表があり、それに対し10/7にLangChainのCEO：Harrison Chaseから、一見すると批判のようなタイトルのブログが出ていました。
“Not Another Workflow Builder”というタイトルですが、内容を見ると
AgentBuilderに向けてもポジティブな要素や示唆が多く、批判というより
方向性は良いんだけど、使い方を間違えるなよという警鐘だったみたいです。
要約はこちら。
LangChainはビジュアルなワークフロー・ビルダーを自社で作らなかった理由
非技術者向けに「誰でもワークフローを作れるようにする」ビジュアルツールへの要求は昔からあったが、LangChain はそれを追わず、他者（LangFlow や Flowise、n8n等）がそのレイヤで提供する形を選んだ。
理由として、ワークフロー・ビルダーには限界や設計の難しさがあると考えている点。
ワークフローとエージェント（agent）という考え方の対比
記事では「ワークフロー（visual workflows）」と「エージェント（prompts + tools を使ってループ実行するもの）」を対比している。ワークフローは予測性を重視し、エージェントは自律性を重視するという観点。
複雑な処理を可視化しようとするとノードとエッジが入り乱れて管理が難しくなるという「ビジュアル複雑性」の課題を指摘。
複雑なタスクには”コードで書くワークフロー”を勧める
中～高複雑性の課題には、純粋なノーコード・ビジュアル・ワークフローでは対応しきれないため、コードベース or ハイブリッドなアプローチ（LangGraph 等）を使うべき、という方向性が示されている。
一方、低複雑性のケースでは「ノーコード・エージェント（prompt + tools）」で十分に対応可能になる可能性があるとも述べている。
今後注目すべき方向性
ノーコードで「信頼できるエージェント（reliable agents）」を作るためのインターフェイス改善、モデルトレーニング、プロンプト設計支援などが、今後の焦点になるという予測。
ワークフロー・ビルダーをもう一度作ること自体が目的になってはいけないという警鐘。
ポジティブ要素
| 項目 | 内容 | 理由・裏付け |
|---|---|---|
| Agent（prompt＋ツール）重視の流れを後押し | 記事は、「ノーコード・エージェント」がよりシンプルで導入障壁が低くなる方向に向かうという見通しを示しており、AgentBuilder にとって有利な文脈を提供している | 記事では「ワークフローより、エージェント構築をノーコードで簡単にするべきだ」旨が述べられている。 |
| 複雑性の節目を明確化する視点 | 「ノードとエッジが多くなりすぎるビジュアル UI の限界」が説明されており、AgentBuilder が複雑なロジックを扱う際の設計指針（どこまで可視化して、どこから抽象化するか）を得るヒントになる | ユーザーが途中で “見えるグラフ” に疲れる／操作困難になるという指摘を提供。 |
| ノーコード操作性への課題認識共有 | 「ビジュアルワークフローは実は低い参入障壁ではない」という冷静な分析があり、AgentBuilder 側が想定ユーザー設計を過信せず、UX・教育支援を重視すべきという注意を促してくれる | 記事：「アベレージな非技術者にとって visual workflow builders も簡単ではない」点を指摘。 |
| ハイブリッド戦略の妥当性を支持 | 複雑な処理にはコードベースのワークフローを使うという考え方は、AgentBuilder が「コードへのブリッジ機能」や「エクスポート」機能を備える設計を考える際の正当性を与える | 記事で “ワークフロー in code” を推す部分が該当。 |
| 差別化／目指す方向の示唆 | 「ただのワークフロー・ビルダー」は世界にはすでに多数存在するという視点があり、AgentBuilder が差別化を狙うなら “信頼性高いエージェント生成UX” や “高度自動化支援” にフォーカスすべきという方向性の助言になる | 記事冒頭で「また別のワークフロービルダーは要らない（Not Another Workflow Builder）」と題している点。 |
ネガティブ要素
| 項目 | 内容 | リスク・懸念点 |
|---|---|---|
| 可視性・理解性に対する期待とのギャップ | ユーザー（特に非技術者）が「ビジュアルに見えるから分かるだろう」と思ってしまい、内部で何をやっているか見えづらい agent ロジックがブラックボックスになりやすい | 記事は “UI が複雑化”・“視覚的に煩雑化する” という欠点を指摘している。 |
| 複雑なロジックへのスケーラビリティ限界 | AgentBuilder があまりにも複雑な判断分岐や並列処理をビジュアル操作で扱おうとすると、設計が肥大化・操作性破綻に陥る可能性 | 記事中では「複雑タスクはビジュアル UI では管理が難しい」旨が記されている。 |
| 過度な期待の抑制 | 「誰でも簡単にエージェントを作れる」という宣伝文句が非現実的になる可能性を示しており、AgentBuilder の導入時にユーザーが挫折するリスクを示唆している | 記事冒頭で “visual workflow builders are not ‘low’ barrier to entry” と書かれている。 |
| 差別化が難しくなる | 多くの競合（LangFlow, Flowise, n8n, OpenAI の独自ツールなど）が同じステージを狙っているという前提があり、AgentBuilder が既存のワークフロービルダー群と差別化しにくくなる可能性 | 記事でそれら他のビジュアルツールを挙げており、それらとの差別化の必要性を示唆している。 |
| 技術仕様／コード統合とのギャップ | ノーコード環境だけで全て賄おうとすると、複雑な API 呼び出し・外部システム連携・カスタム処理を表現しきれないことがある | 記事中で“High Complexity: Workflows in Code” という節で、複雑処理はコードで扱うべきと主張している。 |
AIによるまとめ
良い方向性として、AgentBuilderは「ノーコードでエージェントを作るUX向上」や「信頼性ある自律動作の担保」などに重点を置くべきという助言が得られます。
一方で、過度な可視化や複雑なフローを無理にビジュアル操作で扱おうとする設計は、使い勝手や保守性の観点から弊害を招く可能性が高いという警鐘も含まれています。
つまり、AgentBuilderを設計・展開するなら「どこまでビジュアル化に任せ、どこからコード連携に委ねるか」というバランス感覚を持つことが重要、という結論を後押しする記事、という位置づけでしょう。
人によるまとめ
個人的には概ねこのブログにある指摘と内容に賛同しています。
ワークフローのビジュアル化が複雑という問題だけではなく、
業務をワークフロー化、
ワークフローをシステムに設計、
Agentic Workflowの設計、
実行環境、精度の担保、拡張性、汎用性、運用、・・・
と実導入の上での課題は様々あるとは思いますが、
AgentBuilderにより設計業務は残るがノーコードでのAgent作成という思想と、実行の部分は参考になることが多そうだなと。
元の記事を確認する
