【ITニュース解説】Should you harness the harness: what a workflow engine actually is

ソフトウェア開発の現場では、タスクやプロセスを効率的に自動化する仕組みが求められるが、その中でも特に注目されているのが「ワークフローエンジン」と呼ばれるものだ。これは、複雑な一連の処理を計画通りに進めるためのプログラムであり、特に人工知能（AI）を活用した開発プロセスにおいて、従来のやり方とは異なる大きなメリットをもたらす。

まず、従来の「オーケストレーター・スキル」という仕組みについて説明しよう。これは、AIモデル（例えば大規模言語モデル）が自然言語で書かれた指示（Markdownファイルなど）を読み解き、次にどんな作業をするべきか、どのツールを呼び出すべきかを自ら判断しながら処理を進める方法だ。この場合、作業の手順や流れはAIモデルの対話の中に存在し、AIモデル自身がその流れの主役となる。まるでAIモデルが人間と会話しながら、自力でタスクをこなしていくようなイメージである。結果は対話のログの中に蓄積され、実行中のAIモデルのセッション（対話のまとまり）が終了すれば、その時点での状態も失われることが多かった。また、どのAIモデルを使うかや、どんな環境で実行するかは、そのセッションを開始した時点の設定に依存する。

これに対して、ワークフローエンジンは考え方が根本的に異なる。ワークフローエンジンでは、一連の処理の手順（プロシージャ）が独立したプログラムとして定義され、それが自身のプロセスとして実行される。つまり、処理の流れをコントロールするのはAIモデルではなく、このワークフローエンジンそのものだ。AIモデルは、このエンジンが必要なときに「知性」、例えばコードの生成や特定の情報の判断といった部分だけを依頼する、いわば「サブルーチン」（呼び出される下位の機能）のような存在になる。図で例えるなら、オーケストレーター・スキルではAIモデルが運転手兼カーナビだったのに対し、ワークフローエンジンではエンジンが運転手となり、AIモデルは必要なときに道案内をしてくれるカーナビ役となる。

この「反転」した関係が、ワークフローエンジンに様々な利点をもたらす。まず、処理の流れが「グラフ」という構造化されたデータで定義されるため、実行前にその定義を機械的に検証できる。まるでプログラムの文法チェックのように、存在しないステップを参照したり、循環する依存関係があったりすれば、実行する前にエラーを発見できるのだ。これは、自然言語の指示では実行するまでエラーに気づけないオーケストレーター・スキルと比べ、圧倒的に信頼性が高い。

次に、並列処理の恩恵がある。各ステップ間の依存関係が明確に記述されているため、ワークフローエンジンはどのステップが他のステップの完了を待つ必要がないかを自動的に判断し、それらを同時に実行できる。これにより、タスク全体の実行時間を大幅に短縮することが可能となる。

さらに重要なのは、「モデルを含まないステップ」が実行できることだ。オーケストレーター・スキルでは、AIモデルがすべてのステップを判断するため、たとえ簡単なシェルコマンドの実行であっても、AIモデルの推論を介することになる。しかしワークフローエンジンでは、Bashスクリプトの実行や承認待ちのステップなど、AIモデルの介入なしに確実に実行されるステップを定義できる。これにより、タスクの実行がより予測可能で、信頼性が高く、そして効率的になる。AIモデルによる判断の余地がないため、「このステップはスキップされたかもしれない」といった不確実性がなくなり、結果として「決定論的」な実行が可能となるのだ。

また、ワークフローエンジンは「セッションを超えて実行を永続化」する能力を持つ。オーケストレーター・スキルでは、実行中のプロセスが終了すると、その状態も失われがちだった。しかしワークフローエンジンでは、実行状態が永続的なストレージに記録されるため、途中で中断しても後から再開したり、失敗したステップからリトライしたりできる。さらに、実行中のタスクを他の人に引き継ぐことも可能になる。これは、人間による承認が必要なステップなどで特に有効で、例えばスマートフォンから承認を行うといったことも実現する。

この永続化の特性は、ワークフローの実行を「外部からアドレス可能」にするというメリットにも繋がる。各実行には一意のIDが割り当てられ、このIDを通じて、ダッシュボードで実行状況を一覧表示したり、別のシステム（Slackなど）から承認を操作したり、他の実行が同じ作業ディレクトリを使用しないようにロックをかけたりできる。これにより、タスクの進捗状況の可視性や、複数タスクの協調が大きく向上する。

そして、各ノード（ステップ）ごとにAIモデルやプロバイダー、コンテキスト（対話履歴など）を柔軟に設定できる点も大きい。オーケストレーター・スキルではセッション全体でAIモデルが固定されがちだが、ワークフローエンジンでは、例えば計画立案は一つのAIモデルで行い、具体的な実装は別の、より得意なAIモデルで行う、といった使い分けが可能になる。これは、AIモデルの進化やベンダーのサービス変更に柔軟に対応するための重要な要素だ。

もちろん、ワークフローエンジンにもコストや課題は存在する。一つは「強制可能性と操作性の一体性」だ。制御フローが固定され、機械的に検証できるからこそ信頼性が高いのだが、その反面、一度定義されたフローは実行中に柔軟に変更することが難しい。例えば「このステップはスキップしたい」「別のやり方を試したい」といった要望があった場合、オーケストレーター・スキルならAIモデルに指示を出すだけで対応できたかもしれないが、ワークフローエンジンでは定義ファイルを変更し、場合によってはコードの修正として処理する必要がある。これは、信頼性と引き換えに失われる柔軟性であり、どちらを重視するかは組織や開発者の立場によって意見が分かれるだろう。

もう一つの課題は「相互運用性の維持」である。ワークフローエンジンは、外部のAIコーディングエージェントをヘッドレス（人間が操作しない状態）で呼び出すことを前提としている。しかし、AIモデルのベンダーがこのような利用形態に料金体系の変更や利用制限を設ける可能性は常に存在する。実際に過去にもそのような動きが見られたことがあり、複数のAIプロバイダーに対応できる柔軟性があったとしても、ベンダー側のポリシー変更によって利用が制約されるリスクはゼロではない。

最後に、世の中には「ワークフローエンジン」と名乗る様々なツールが存在するが、それらがすべて上記で説明した真のワークフローエンジンの特性を兼ね備えているわけではない。例えば、ArchonやConductor、Bernsteinといったツールは、制御フローをAIモデルの外に持ち、AIモデルを介さずにリポジトリ内でシェルコマンドなどを実行できるため、この定義におけるワークフローエンジンに該当する。

しかし、LangGraphのような「グラフフレームワーク」は、状態を管理し、条件分岐を持つグラフを構築するためのライブラリであり、ワークフローエンジンを「作るための部品」ではあるが、それ自体がリポジトリやシェルと直接連携してAIモデルを含まないステップを実行する機能を持つわけではない。同様に、CrewAIやAutoGenのような「エージェントループビルダー」は、複数のAIエージェントを協調させて複雑なタスクを実行させるが、その多くはAIアプリケーション構築が主目的であり、ファイルシステムへのアクセスや、AIモデルを介さない決定論的なシェルコマンド実行を直接サポートしているわけではない。

また、Claude Codeのダイナミックワークフローのように、AIモデルの内部で制御フローをJavaScriptスクリプトとして実行する仕組みもある。これは一部のワークフローエンジンの利点、例えば並列処理や長時間の実行を可能にするが、ファイルシステムやシェルにアクセスできない、実行がセッションに限定される、ユーザーがスクリプトを直接定義・管理できない、といった点で真のワークフローエンジンとは異なる。

このように、ワークフローエンジンはAIを活用した開発プロセスにおいて、タスクの信頼性、再現性、効率性を大幅に向上させる強力なツールだ。その本質は、AIモデルが主役だった処理の流れの制御を、独立したプログラムであるエンジンが担うことにあり、これにより様々なメリットが生まれる一方で、その固定化された性質ゆえの課題も理解しておく必要がある。どのツールが自分の目的と合致するかを見極めるためには、これらの特性を理解することが不可欠だ。