Workflow と Autonomous Agent が長く共存する理由
Autonomous Agentが自ら計画し、ツールを呼び、例外まで処理できるなら、Workflowはいずれ置き換えられる。そう考えるのは自然だ。次の手順をAgentがその場で決められるのに、なぜ先にフローを描くのか。
この推論は、対話の入口と実行の仕組みを混同している。Agentが変えるのは、人がソフトウェアへどう要求を伝えるかだ。Workflowは、権限、順序、失敗処理、人の確認といった制約のもとで、システムがどう安定して仕事を完了するかを担う。Agentはユーザーの前に立ち、Workflowはシステムの中に残るだろう。
ユーザーはもう、目的に合うシステムを探し、フォームやボタンの使い方を覚える必要がない。やりたいことを Agent に伝えれば、Agent が意図を理解し、足りない情報を補い、適切な実行方法を選ぶ。その先で固定されたフローが呼ばれるのか、その場で動的なフローが作られるのかを、ユーザーが知る必要はないかもしれない。
だからといって、開発者の仕事がなくなるわけではない。Agent の背後に、2種類の Workflow を用意する必要がある。
ひとつは Fixed Workflow だ。Dify で人が組み立てるフローのように、返金、契約審査、コンテンツ公開といった安定した業務に向いている。どのノードを先に動かすか、どんな条件を満たせば次へ進めるか、どこで人の確認を必須とするかを、あらかじめ人が明確に決めておく。各ノードでモデルの出力が変わっても、プロセス全体はテストでき、後から追跡もできる。
もうひとつは Dynamic Workflow だ。大規模なコード移行、リポジトリ全体のレビュー、自由度の高い調査は、事前にすべての工程を切り分けるのが難しい。そこで Agent が現在のタスクに応じてフローを生成する。Anthropic の Dynamic Workflows もこの方式を採用している。Claude が JavaScript スクリプトを生成し、タスクを複数の Subagent に割り振ったうえで、レビューや再試行を組み込む。
この2種類の Workflow が解決する問題は異なる。Fixed Workflow は予測可能性をもたらし、繰り返し実行され、責任の所在が明確な仕事に向いている。Dynamic Workflow は適応力をもたらし、事前に固定できない経路を扱う。開発者が実行環境と権限の境界を担い、Agent がその場でタスクを組み立てる。
二つは排他的でもない。AgentがDynamic Workflowで問題を調べて案を作り、確定した操作をFixed Workflowへ渡せる。固定フローで例外が起きたときだけ、Agentに局所的な不確実性を処理させることもできる。
未来のソフトウェア画面は、ますますひとつの対話ボックスに近づくかもしれない。しかしシステムの内部に、何でもできる Agent だけが残るわけではない。開発者はこれからも、組織のルールを Fixed Workflow に落とし込み、Dynamic Workflow のためのツールと境界を整える必要がある。
返金や契約審査なら、安定部分をFixed Workflow、例外をAgentに任せられる。コード移行のような開かれた仕事ではAgentがDynamic Workflowを作り、確定した操作を固定フローへ渡す。どちらの経路にも、開発者が権限、失敗処理、人の確認点を定める必要がある。