AgentOSのワークフローエンジンの仕組みを理解する

AgentOSは「AI」よりもワークフローエンジンに近い

SDD（仕様駆動開発）でAgentOSが語られるとき、多くの場合「AIが開発する仕組み」と説明されます。しかし内部構造を理解すると、実態はAIモデルそのものではありません。中心にあるのはワークフローエンジンです。

つまりAgentOSの本体はコード生成能力ではなく、「開発工程を状態遷移として管理するシステム」です。
LLMはその中の実行ユニットの一つに過ぎません。

この点を誤解すると、導入時に「思ったより自動化されない」「ただのコード生成と変わらない」と感じてしまいます。AgentOSは生成AIの代替ではなく、開発工程のオーケストレーション層です。

ワークフローエンジンとは何をしているのか

ワークフローエンジンは、開発作業を「イベント」と「状態」で扱います。
人間のプロジェクト管理では、以下を頭の中で行っています。

• どの作業が終わったか
• 次に何をするか
• 何がブロックしているか
• 誰が作業できる状態か

AgentOSはこれをシステム化しています。

具体的には、すべてのタスクが「状態」を持ちます。

状態	意味
pending	まだ開始条件を満たしていない
ready	実行可能
running	実行中
blocked	依存タスク待ち
done	完了
failed	失敗

この状態遷移を自動で管理するのがワークフローエンジンの役割です。

開発は直線ではなくグラフとして扱われる

従来の開発プロセスは、ウォーターフォールであれアジャイルであれ、人間は線形に理解します。

要件 → 設計 → 実装 → テスト → リリース

しかし実際の開発は直線ではありません。
AgentOSは開発をDAG（有向非巡回グラフ）として扱います。

例えばユーザー登録機能の場合：

• DB設計
• API設計
• UI作成
• バリデーション
• テスト

これらは完全な直列ではありません。一部は並列可能ですし、一部は前提条件を持ちます。
AgentOSはこの関係を依存関係グラフとして保持します。

{
  "create_signup_ui": ["define_signup_api"],
  "write_e2e_test": ["create_signup_ui", "create_signup_api"]
}

この構造により、作業の並列化と順序制御が同時に可能になります。

イベント駆動で動作している

AgentOSは定期実行ではなくイベント駆動です。
つまり「一定時間ごとに処理する」のではなく、「何かが起きたときに次の処理が走る」構造です。

主なイベント：

• 仕様変更
• タスク完了
• テスト失敗
• PR作成
• マージ

例えば、テストが完了すると次の処理が自動でトリガーされます。

テスト完了 → 実装確認 → PR生成 → レビュー待ち

この連鎖が自動的に進行します。

LLMの役割はワーカーに近い

ここでLLM（大規模言語モデル）は、判断主体ではありません。
AgentOSのワークフローエンジンがタスクを割り当て、LLMは作業を実行します。

人間のチームに例えると、次の関係です。

役割	対応
プロジェクトマネージャ	ワークフローエンジン
開発者	LLM
レビューア	検証ステップ
QA	テスト生成・検証

つまりAgentOSはAIが判断して動いているのではなく、状態機械が制御しています。

なぜこの構造が必要なのか

単純なコード生成ツールでは、次の問題が起きます。

• 同じファイルを複数回変更する
• 設計順序が守られない
• テストが後付けになる
• 修正で別の機能が壊れる

これは「順序」と「依存関係」が管理されていないためです。
ワークフローエンジンはこの問題を防ぐために存在します。

AgentOSはコードを生成するのではなく、開発工程を制御することでコード生成を安全にするという設計になっています。

実際の動作の流れ

仕様が更新されると、内部では次の処理が走ります。

1. 影響範囲解析
2. 依存タスクの再評価
3. 必要なタスクを再オープン
4. テスト更新
5. 実装更新

ここで特徴的なのは、既存コードを直接修正する前にテストが更新される点です。
これにより変更による破壊が検出されます。

注意点：すべてが自動化されるわけではない

AgentOSは万能ではありません。
特に次の領域では人間の判断が必要です。

• アーキテクチャ選定
• 非機能要件の優先順位
• UXの質的判断
• パフォーマンスチューニング

ワークフローエンジンは「正しさ」は管理できますが、「良さ」は評価できません。

CI/CDとの役割分担

AgentOSとCI/CDは競合しません。
役割が異なります。

AgentOS：作る工程の管理
CI/CD：完成物の検証と配布

AgentOSが生成した変更は、最終的にCI/CDに流れます。
つまりワークフローエンジンはCI/CDの前段に位置します。

開発スタイルの変化

この仕組みを導入すると、チームの作業内容が変わります。

• タスク管理ツールの使用が減る
• スプリント計画が軽くなる
• バグ対応が仕様修正になる
• レビュー対象がコードから仕様へ移る

ここで戸惑うポイントは「何をレビューすればいいのか」です。
コード量は減りますが、仕様の精度が求められます。

結局のところ何をしているのか

AgentOSの本質は、AIによる自動開発ではありません。
開発をプログラム可能にする仕組みです。

これまで開発工程は人間の管理能力に依存していました。
AgentOSはそれを状態遷移とイベント処理として扱います。

コードがコンピュータを動かすのと同じように、仕様が開発工程を動かす。
ワークフローエンジンはその実行環境です。

この構造を理解すると、AgentOSが「開発ツール」ではなく「開発基盤」と呼ばれる理由が見えてきます。