アリババエンジニア、汎用エージェントは「飲鸩止渴」だと警告

原文には記事本文が含まれておらず、著者名と日付のみが記載されています。したがって、リライトすべき内容がありません。

陳以強 2026年8月5日 18:18 浙江

現場のエンジニアとしての視点から、汎用エージェントに関する個人的な考察

2026 年、第 48 回記事

（本文の読了時間：約 15 分）

01

Agent Flow

最近、「Agent Flow」という小規模なプロジェクトに取り組んでいます。当初の目的は明確で、特定のシナリオやターゲット層において、既存の「Agent Skill」に代わるものを作ることでした。

この「Flow」は従来のフローを強化したものに過ぎませんが、その核心はユーザーがノードや接続線、JSON を理解することではありません。重要なのは、ユーザーが自然言語で目標を記述し、LLM がその目標を理解して Flow の生成・修正・実行を行う点にあります。

Flow 自体の重要性は相対的に低下しました。それは単なるオーケストレーション層であり、ノードや詳細な処理には責任を持ちません。役割はあくまでリンク制御、タスクの配信、結果の回収に限定されます。具体的な作業は各 Node が担当します。ここでいう Node は QwenWork 也可以是 Codex CLI、影刀（Yingdao）、千牛（QianNiu）の API、あるいはアリババ内部の運用 Agent など多岐にわたります。核となる理念は、タスクを細分化して配分し、各ノードが実行責任を負うというものです。

具体的な事例を見てみましょう。ある EC 事業者がレポート集計を行う際、QwenWork でデータを取得し、影刀 RPA でもデータを取得し、さらに千牛の API を通じてデータを取得します。その後、これら3つのデータを統合し、DWS（Data Warehouse Service）を経由して钉钉（DingTalk）のドキュメントに書き込み、最後にそのドキュメントを钉钉グループへ送信するという一連の流れが必要です。

従来の「Skill」を作成する際には、このような長距離かつ複雑なループ処理を単一のタスク内で完結させることはほぼ不可能でした。しかし、Agent Flow なら、このケースを実際に介入なしで、確実に実行することが可能です。

このアプローチは、すべての汎用能力や大規模言語モデル（LLM）に依存する一般的なエージェントとは一線を画します。「世界を司るエージェント」を作ろうとしたり、単に願望を伝えるだけで問題が解決すると期待したりすることはありません。代わりに、タスクの連鎖を適切なノードに分解し、「外部委託」のように各ノードに最適なエージェントを割り当てます。これにより、個々のエージェントに留まらず、オーケストレーション層や制御層へと視座を上げ、エージェントは「能力の一つ」として位置づけられ、すべてを担う存在ではありません。

なぜこのようにするのでしょうか。大規模モデルの波乱万丈な時代において、「汎用能力」「インテリジェント・アシスタント」「アーキテクチャ設計」といった用語があまりにも氾濫しているからです。ユーザーは期待を持って製品を利用しますが、エージェントが左右に揺れ動く汎用的なアップグレードを待つ間に望む結果を得られず、最終的には見放してしまいます。多くの顧客が本当に求めているのは、反復的なタスクの完了です。これらのタスクには固定されたフローと連鎖が存在し、特定のノード（例えばデータの抽出、文章の整理、結果の分析など）でエージェントが一部の操作を代行すれば十分なのです。

Flow と Agent を組み合わせることで、顧客の課題を迅速かつ効率的に解決できます。ユーザーは理解しがたい「スキル」や、Agent や LLM の独自能力のアップグレードを待つ長い時間をやり取りする必要がありません。これこそが、ユーザーを実際に留め置く方法です。

02

最小タスク単位と確定的な実行

Flow がエージェントノードにタスクを振り分けるこのロジックは、私が常に提唱する「最小タスク単位（最小の混沌ユニット）」という理念と非常に合致しています。

大規模モデルの出力は本質的に確率的であり、コンテキストウィンドウも限られているため、大規模モデルに毎回割り当てるタスクは、具体的な文脈を持ち、作業量が適切で、結果を閉じて確認できる単位であることが望ましいです。

Agent Flow において、Flow の各ノードがまさにこの最小タスク単位となります。これらのノードは、QwenWork に特定の動作を実行させることもあれば、外部ツールを呼び出して論理処理を行わせ、完了後に次のノードへ進むこともあります。この手法により、膨大で複雑なタスクが制御可能となり、システムのオーケストレーション能力も劇的に拡張されます。

さらに重要なのは、YAML、Flow、ハードコードは信頼性がある一方、純粋な自然言語は信頼できないという点です。YAML に基づく Flow の自己生成と自己維持は、緩やかな「スキル」よりもはるかにシンプルで効率的です。

現在の一般的なエージェントを深く使ったことがある人ならご存知の通り、同じタスクでも異なる会話で開始すると、エージェントは全く異なるアプローチを採用し、片方は成功して片方が失敗することがあります。

では、業界はこの問題に対処しようとしてどうしているのでしょうか？「メモリ（Memory）」システムを積み重ねることで解決を図っています。しかし、これはより大きな沼に陥ることになります。現時点で、どの一般的なエージェントも自らのメモリシステムが完全に問題を解決できると断言できるものはありません。

同様に、ユーザーが本当に求めているのは、大規模モデルがプログラマーのようにバグを修正するために「探索」することではありません。ユーザーが必要としているのは、最低限の認知負荷で、確定的かつ信頼性のある方法で複雑なタスクを完了させることです。

03

なぜユーザーはあなたのエージェントを選ぶのか？

以上の認識に基づき、現実的な問題に立ち返りましょう。「成熟した大規模モデルがこれほど多くある中で、なぜユーザーはある特定のエージェントを選ぶのか？」

理由はたった二つです。

第一に、「あなたしか解決できない問題がある」からです。

フレームワークの先進性を過信しないでください。LLM の時代において、優れたエージェントアーキテクチャを構築することは決して難しくありません。真に重要なのは、他社が持つことができない独自の資産を持っているかどうかです。

過去十数年間、スクレイピング技術と反スクレイピング対策は激しく対立してきましたが、この一連の技術は徐々に忘れ去られるかのように思われていました。しかし、LLM の台頭により、私は突然、スクレイピングやデータ取得が再び注目されるようになったことに気づきました。なぜなら、大規模モデルに正しくかつ中核的なデータがなければ、それは単なるチャットボットに過ぎないからです。膨大な数の LLM が訓練段階でデータを必要とするだけでなく、実際に実装されるエージェントも実行段階で真のデータを必要としています。

最も古典的な例として、「AI 元カノ」があります。一見すると非常にシンプルですが、本当に成功させた人は極めて少数です。その理由は、完全なチャット履歴を取得することが極めて困難だからです。

同様の理屈が、淘宝の商品データや釘釘のチャット記録にも当てはまります。これこそが Agent にとって最も貴重な資産です。

どんなに汎用的なモデルが賢くても、セキュリティ制限を突破してデータベースに侵入し、「チャット記録を自動的に要約し、指定された釘釘グループへ正確に配信する」といったことはできません。唯一可能なのは、独自の手に入れたデータと API を活用できる Agent だけです。

つまり LLM の時代において、誰が真の高品質なデータを保有し、誰が中核となる製品や機能に支えられているかが、他にはないユニークな Agent を生み出す鍵となります。

第二に、本当に問題を解決できているかです。

この言葉は「当たり前のこと」のように聞こえるかもしれませんが、多くの LLM 製品で最も本末転倒になりがちな部分でもあります。

汎用的な Agent 製品で使われる RAG、MCP、Tool Calling、Multi-Agent、Agent Loop……といった要素は、ユーザーにとっては本質的に意味を持ちません。ユーザーが関心を持つのはたった一つ、「自分の問題が解決されたか」という点だけです。

実際には、多くの顧客の真のニーズは、順序立てた LLM の呼び出し 3 回と API を 2 回使えば十分です。しかし市場に出回る多くの製品では、あえて汎用的な機能を詰め込み、複雑なループを構築します。その結果、莫大なトークンを消費して大量の不満を買うか、タスクが再現できず一度きりの機能に終わってしまうのです。

多くの Agent は「野心勃勃」です。「スーパーインテリジェントアシスタント」になり、ユーザーのあらゆる問題を解決し、「デジタル従業員」としてユーザーそのものを置き換える……そんな夢を描きます。しかし残酷な事実として、World Agent や World Model は、短期間で達成できるものではありません。

この目標が前向きで追求する価値があることを否定はしません。しかし、この長い道のりの中で、ユーザーの大小さまざまな具体的な問題を放棄してしまうのでしょうか？顧客や業務チームに問題が生じた際、真のニーズを無視して、アーキテクチャチームの「星と海」を邪魔しないようにしているだけでよいのでしょうか。

Agent の核心は、アーキテクチャでもループでもハーンセス（harness）でもありません。ユーザーがその Agent が解決する問題に対して支払い意欲を持つかどうかです。問題を解決できれば、ユーザーはアーキテクチャや技術の詳細、ハードコードの有無、サーバーに配置されたスクリプトの数、あるいは LLM を使っているかどうかを気にしません。問題を解決できるなら、顧客は喜んで支払います。顧客が支払うとき初めて、Agent は成功したと言えます。

04

Hardcode は美しい

私の視点では、汎用的な Agent よりも Hardcode の方が「美しい」です。なぜなら、私にとっての美しさとは「顧客がお金を払ってくれること」だからです。

ユーザーニーズに応えるという競争において、多くの場合、ユーザーの要望は非常に素朴なのに、私たちはこれまで通りの究極の解法である Hardcode を採用することを躊躇してしまいます。

Hardcode を排斥するのは、強い慣性によるものです。過去には人工でコードを書くコストが高く、カスタムロジックを実装するにもコストがかかり、メンテナンスや将来の拡張にもコストが必要でした。そのため、人々は抽象化や汎用性、プラットフォーム化を追求しました。その時代では、ある顧客のために if else を書くだけで「古臭い」「高級感がない」と見なされていたのです。

しかし LLM の時代になると、この前提は変わりました。コードは「安価」になったのです。フローを書くのは安価です。数回の固定された LLM 呼び出しも安価です。特定の有料顧客のために手作業で Agent Flow を構築することも安価です。なぜ Hardcode をしないのでしょうか。

Hardcode は非常に美しいと言えます。その理由は、コードの保守者が LLM に変わるからです。LLM にとって、10 個の if else は、膨大な抽象ファクトリよりもはるかに理解しやすいのです。

もしある顧客の問題が、順序立てた LLM の呼び出し 3 回と API を 2 回で解決できるなら、そう書けばよいのです。顧客のニーズが固定された承認支援フローであるなら、それをハードコードすればよいのです。顧客がお金を払い、システムに毎週信頼性の高いレポートを生成してほしいと願うなら、信頼性の高い Flow を提供すればよいのです。

ユーザーが問題を解決されれば、喜んで支払い、その費用でシステムコストもカバーできます。さらに、システムは実際の現場からさらに成長する機会を得るのです。

それとは対照的に、問題が未解決で顧客からの支払いもない段階で、汎用エージェントプラットフォームを設計し、Loop や Memory、Harness、MCP、RAG といった要素を無理やり詰め込みます。その結果、ユーザーは使いこなせず、コストも抑えられません。これこそが本末倒置です。

これが私が「Agent Flow」に取り組む理由です。Flow が Agent よりも先進的であることを証明するためではありません。Flow は、こうした実際的で具体的、あるいは多少ハードコード的なユーザーのニーズを受け入れることができるからです。if-else 分岐や LLM の呼び出し、エージェントノード、業務インターフェース、人間の確認といった要素を編成し、信頼できるタスクチェーンへと変えることができます。

05

AI Native / LLM Native

「AI Native」という言葉は今年の業界のホットトピックです。関係者たちは試行錯誤を繰り返しましたが、熱狂が冷め去ってもなお、その本質はまだ完全に理解されていないようです。

実は AI Native の本質は非常にシンプルです。LLM を基盤として、AI がユーザーの問題を解決することです。

製品に AI があるように見せかけることでも、アーキテクチャを先進的に見せることでも、ユーザーが Agent や Loop、RAG、MCP を学ぶことを強いることでもありません。ユーザーに真の問題があり、AI がそれをより手軽で、より信頼性が高く、より安価に解決する（あるいは少なくともより自然な形で解決する）ことで、ユーザーは継続利用し、さらに支払いに応じる。これが AI Native の真髄です。

現在の多くのケースは、旧来のシステムが突然大模型の存在を知り、慌てて AI という皮を被せたものに過ぎません。古いフレームワークはそのまま、古いプロセスもそのままだのです。ただ、ある工程で LLM を追加呼び出ししただけか、あるいはあるページにチャットボックスを追加しただけです。

具体的な例を挙げましょう。多くの AI 検索サービスは、LLM を無理やり推薦システムに組み込むものであり、典型的な「LLM の皮」です。一方、OneRec のように、ネイティブの推薦大モデルそのものを構築するアプローチこそが、真の LLM Native なソリューションに近いと言えます（注：著者は OneRec を賞賛しているわけではなく、単なる事例として挙げています）。

LLM の普及と浸透に伴い、多くのユーザーが自然言語で LLM と対話することに慣れてきました。やがて「インターネット新生世代」に代わり、「LLM 新生世代」と呼ばれる層が登場するかもしれません。ユーザー自身が AI Native であるならば、製品もまた AI Native でなければなりません。すべての人が Loop や Memory、RAG、MCP といった技術概念を理解しているわけではありませんが、「使いやすいか」「信頼できるか」「支払う価値があるか」は判断できます。AI Native な製品とは、大模型を基盤として、製品インタラクションやビジネスプロセス、顧客対応を再構築するものです。ユーザーはすでに AI Native への転換の途上にあり、製品もこれに追随する必要があります。

私たちは「邪魔なものはすべて排除する」という強硬な姿勢で臨むべきです。頭に残すべきはただ一つ、「ユーザーが自然言語で指示しただけで、このタスクを完遂できるか？」という問いだけです。

以上のことから、もう一度強調しておきます。AI Native とは、華々しいプロセスのことではありません。LLM を出発点とし、負担の軽減と使いやすさの向上を目標に、自社の製品がより確実にユーザーのために機能し、真の問題を解決し、ユーザーがその対価を支払う意愿を持つようになるかどうかが問われるのです。

06

プログラマーとしての修養

視点を開発側に戻しましょう。理念は依然として共通しています。技術に LLM を導入する目的は「効率化」です。

では、どのように効率化するのか？すべての「邪魔な」プロセス、承認フロー、権限管理を排除し、最良のモデルと Code Agent を活用して、LLM がコード作成、テスト、リリースのチェーンに真正面から参加できるようにします。

以前、社内運用エージェントのような WarRoom 開発アシスタントプロジェクトに取り組んだ際、その重要性を実感しました。当時の目標は、アラートの自動受信、問題分析、そしてコード記述と PR の提出を自動化することでした。つまり、プログラマーのための LLM アシスタントです。

しかし、プロジェクトがほぼ完成した段階で私はこれを断念しました。なぜでしょうか？現在のインフラストラクチャがこのシステムを支えられないからです。

ログを確認したいと思っても、ログシステムは手動での権限付与が必要であり、A2A（Agent to Agent）通信にも対応していません。

コードを見せるには手動で権限を開く必要があるし、ミドルウェアを管理するには AK/SK の管理機能が開通していない。

より強力なモデルに接続したいが、承認が下りず、外部モデルは社内ネットワークにもアクセスできない。

一歩一歩が壁にぶつかり、やっとの思いで作ったデモでは 3 つのアプリしか管理できず、制限されたモデルしか使えない。その結果、「人がループする」状態を強いられてしまうのだ。

当時、私が最も強く感じたのは「モデルが賢くないから」ということではなく、自分が再び「人肉の接着剤」になっているという事実だった。Agent がログを確認したいと言えば私がクリックし、権限を見たいと言えば私が申請し、結果を検証したいと言えば私がバックエンドを切り替えてスクリーンショットを撮り、コピーして Agent に渡す──理由など明白だ。過去 20 年間に作られたインフラはすべて「人間」のために設計されており、LLM（大規模言語モデル）には親和性がないからだ。だから至る所でぎくしゃくする。

私は真のスーパープログラマーアシスタントを作ることもできず、自分自身も「自由な存在」としてスムーズに活動することもできない。既存の枠組みの中に押し付けられているだけだ。

しかし、Aone チームが内部の運用 Agent を実現したことは喜ばしい。私の考えとほぼ同じアプローチだったのだ。ログやトレース、コードなどをそのまま既存の Code Agent に読み込ませるという手法だ。この運用 Agent が証明したのは、「インフラが LLM に対して十分に親和性を持っていれば、モデルと Agent は開発現場に入り込み、バグを修正し、要件を実装し、スーパーアシスタントとして活躍できる」ということだ。

この運用 Agent の立ち位置はもともと有利だった。より多くの権限を簡単に取得でき、インフラへのアクセスも広く、承認プロセスも通りやすいからだ。まさに「ロケーションが重要」であり、私が以前述べた「特定の課題を解決できるのはあなただけ」という話の核心だ。

ここで私の好きな言葉を二つほど添えよう。このシナリオに完璧に合致する言葉だからだ。「権力とは不動産とよく似ている。すべてはロケーション、ロケーション、ロケーションである。お金は 10 年後には崩れ始めるサラソタの McMansion（大規模住宅）のようなものだ。一方、権力は数世紀にわたって屹立し続ける古い石造りの建物なのだ」。

確かに、独立したプログラマーとして私ができるのは、特定の Code Agent を使ってコードを書く方法論を研究したり、「些細な」記事を書いたりすることくらいだ。インフラや権限といったより深遠で重要なレベルについては、発言する権利さえ持っていない。しかし、大模型の前では、すべての障壁は必ず消滅すると私は信じている。重要なのは、それが誰が先に実現するかというスピードの問題に過ぎないのだ。

07

A4 紙を 1,000 枚重ねても厚いままだ

インフラと権限の話が出た以上、組織構造についても触れざるを得ない。過去一年で私は、自分が次第に「Master Agent（マスターエージェント）」のようになっていると感じるようになった。継続的にタスクを受け取り、それを分解して Sub-agent（サブエージェント）に割り振って実行させるという状態だ。この状態において重要なのは、タスクのコンテキストが完全かどうかということだ。

情報が十分に与えられれば、大模型はよく受け止めてくれる。しかし、人間との確認を繰り返す必要があるタスクや、局所的だが深く、多くの対話と判断を要するタスクの場合には、私自身も Sub-agent も極めて苦しい思いをする。現在の組織構造とタスクリフローは、LLM にとって極めて非親和的なのだ。

「フラット化」を叫ぶ声はインターネット業界で何年も続いているが、LLM の時代になってついに無視できない「部屋の中の巨大な象」となった。A4 紙を 1,000 枚重ねても厚いままなのと同じだ。組織も同様で、どんなにフラット化を謳っても、タスク・権限・コンテキスト・フィードバックのリンクが長ければ、それは依然として「厚い」ままなのだ。

真のフラット化とは、物理的な距離が近いことではない。組織のリンクが十分に短いことだ。要件の伝達に転送者が一人減るだけで、元のコンテンツに対する理解は倍になる。一つのアイデアがトップダウンで現場まで届くまでに何層もの伝言が必要か？PM からの要件が開発者に伝わるときに何回も説明が必要か？権限が必要な状態から実際に取得するまでに、どのくらいのチケット数やチャット、承認プロセスを必要とするか？これこそが、フラットかどうかを決める本質だ。

理想状態とは、誰もが「スーパーフリーランサー」になれることです。部署や権限の制約に縛られず、何か問題があれば即座にコードを書き始め、プッシュしてデプロイし、その責任を全うする。タスク配分者は、複雑な階層を経由せず、直接最前線の開発者に完結したタスクを渡せばよいのです。（この考えは非常に過激ですが、小規模なスタートアップではすでに日常茶飯事です。一部のチームでも、こうした現実が広がりつつあります。）

もちろん、LLM を活用する開発者の視点からすれば、重要なのは人間を「エージェント（Agent）」へと進化させ、タスクとコミュニケーションを TCP/IP プロトコルのように、点对点で信頼性が高く、安定し、かつ十分な情報量を持つものに変えることです。私たちがエージェントと対話して必要なコンテキストを一度に入手できれば、タスクは極めてシンプルなゴール指向の形になります。率直に言って、この考え方はやや理想主義的ですが、今からでも始めることは決して損はありません。

08

Agent Flow へ回帰する

最後に、冒頭の問題に戻りましょう：なぜ Agent Flow を作るのか？

それは、より複雑なアーキテクチャを持つエージェントシステムを作ろうとするためではありません。Flow が Skill よりも優れていることを証明するためでもありません。また、ユーザーを縛り付けるために無理やり新しい技術用語を造り出すためでもないのです。

LLM の時代において、エージェントの方向性は派手な技術用語や複雑で汎用的なアーキテクチャ設計にあるべきではありません。ましてや「汎用エージェント」自体が適切な目標であるとも限りません。

ユーザーの問題から直接出発し、ハードコードであっても、if-else 分岐であっても、固定された LLM の呼び出し数であっても、それが LLM の激しい潮流の中でユーザーに問題をよりシンプルかつ確実に解決させることができるなら、それは優れたソリューションです。つまり「Good Agent」なのです。私が Agent Flow を作る理由もこれに尽きます。

大仰な用語や、人々を魅了する技術アーキテクチャを手放し、真摯にユーザーと対話しましょう。今こそ、彼らの問題を解決できるエージェントを設計・開発すべき時です。どんなに「醜く」てもハードコードであっても構いません。無数の技術用語の中で溺れるのではなく、実際に問題解決に取り組むべきです。

付録：

[01] Agent Flow

https://github.com/huisezhiyin/symphlo

[02] OneRec

https://arxiv.org/abs/2502.18965

*注：本記事は著者の個人的な技術的考察と経験の共有であり、会社の公式見解や立場を代表するものではありません。文中の一部の記述には、技術動向や発展方向に関する先見的な判断が含まれていますが、これらは執筆時点での著者の認知と経験に基づいたものです。すべての内容は交流・参考のためのものであり、読者は自らの状況に応じて独立して評価を行う必要があります。

コメント欄で一緒に議論しましょう〜

WeChat で開くにはこちらへ