ソフトウェアデリバリーの新たな単位 — ワークフロー

本記事は 2025 年 11 月 25 日 に公開された「The New Unit of Software Delivery: The Workflow」を翻訳したものです。

エージェント型 AI は、ソフトウェアの設計とデリバリーに目立たないが大きな変化をもたらす。IT 部門はエンドユーザーとともに、アプリケーションやマイクロサービスを中心に据える代わりに、自動化されたワークフローを開発するようになった。

ワークフローを実装するエージェントは、より複雑なオーケストレーションの一部として他のエージェントと連携する場合もある。だがデリバリーの基本単位はあくまでワークフロー、つまりビジネスにとって意味のあるゴールを持ったエンドツーエンドのプロセスだ。CIO はワークフロー中心の体制がもたらす変化 — ビジネスユーザーとの協働、テストの進め方、IT 施策の組み立て方の違い — を考える必要がある。

ワークフローは何が違うのか

ワークフローはビジネスプロセスそのものだ。モノリシックなアプリケーションや粒度の細かいマイクロサービスには、そうは言えない。

アプリケーションは単体で動くことを前提に作られ、全体をまとめて呼び出す。多くのワークフローの構成要素になることも多い (ERP システムのように業務部門の壁を越えるケースはその極端な例だ)。アプリケーションは通常、多数のビジネス関係者を巻き込む大がかりな要件定義と設計を経て構築される。ユーザーが名前をつけたり、人格すら感じることもある。

歴史的にはそれで理にかなっていた。アプリケーションとは実行可能ファイルであり、かつてはコマンドラインから起動するものだった。パッケージソフトを購入することもあったし、ベンダーがブランドをつけた製品として販売していた。新しいアプリケーションの予算は、後から個別に機能拡張が予算化されるにせよ、まずモノリシックな一体物として — 製品を購入するかのように — 計上される。しかしアプリケーションには体裁を整えるための付随物 (メニュー、管理機能、ヘルプなど) が必要で、本来の機能を超えた負荷が加わる。一方ワークフローは、手元のタスクに絞り込まれた粒度の細かい投資単位になる。

アジャイルではユーザーストーリー単位で開発するが、実装した機能は既存アプリケーションや開発中のアプリケーションに組み込まれることが多い。ユーザーストーリーのバックログを消化した結果が「完成したアプリケーション」になるケースもある。モノリシックなアプリケーション中心の発想は残ったままだ。ユーザーストーリーは機能の単位ではあっても、運用の単位とは限らない。ワークフローは違う。エージェントとして単体で起動でき、自律的にも動作する。

ワークフローはユーザーストーリーに似て見える。どちらもビジネス上の意図があり、ユーザーに価値をもたらす。だがワークフローはプロセス全体を捉えているのに対し、ユーザーストーリーは粒度が細かく、実装がシステムの複数箇所にまたがることがある。ワークフローはプロセス改善を通じて継続的に洗練できるが、ユーザーストーリーはデリバリーされた時点でバックログから消える。

コードをモジュール化して分割するのは昔からの良い慣行で、構造化プログラミング、オブジェクト指向、サービス指向アーキテクチャ、マイクロサービスとテーマは繰り返されてきた。ポイントは単に小さく分けることではなく、分割した単位をビジネスの概念やドメインに対応させることにある。オブジェクト指向のオブジェクトは限定されたビジネスドメインをモデル化するものだし、マイクロサービスは API として提供できるビジネスロジックの一片をカプセル化するものだ。しかしマイクロサービスは粒度が細かく横断的なので、ビジネスワークフローときれいに対応することはまれだ。

エージェント型 AI とワークフロー

エージェント型 AI で状況が変わる。エージェントは範囲が明確なワークフロー — かつて従業員やチームが担っていたプロセス — を自動化する。コードとビジネスプロセスの距離が縮まり、実質的に両者は同じアイデアの異なる表現・実装にすぎなくなる。

Kiro はこの考え方を論理的な帰結まで押し進め、プロセス仕様とエージェントコードの間を滑らかに変換する。Amazon Quick Suite のようなツールを使えば、エンドユーザー自身がエージェント型ワークフローを作成できる。コードを書く力の「民主化」とよく言われるが、ユーザーが ERP のような完全なアプリケーションを構築するわけではない。自分のワークフロープロセスを改善・置換する方法を見つけるのだ。

「エージェント」とは定義上、責任を委任する相手であり、こちらの代わりに行動する。特定のタスクを任せるものだ。たとえば、サプライチェーンエージェントがサプライヤーの価格変動や在庫状況をモニタリングする。別のエージェントが需要パターンの変化を検知し、さらに別のエージェントが発注する。エージェント同士は人間の従業員と同じように連携する。各エージェントは従業員を支援する (Human-in-the-Loop) こともあれば、完全に自律的に動くこともある。いずれの場合も「タスク」(=ワークフロー) が仕様の単位であり、デリバリーの単位であり、テスト・検証・改善の単位だ。

IT 組織への影響

IT 組織にとって興味深い変化が起きる。従来、IT が導入したケイパビリティはビジネス価値を生むと言いつつ、本当の価値はその使い方にあることを心のどこかで分かっていた。価値はソフトウェアに合わせてビジネスプロセスを適応させること (そして適応を定着させる組織文化の変革) に左右されていた。だがワークフローは、プロセス自体と新しい機能の両方をカプセル化している。独立した価値の単位だ。

ソフトウェア開発は、ビジネス目標を自動化可能な (そして AI を使って自律化できる) ワークフロー変更に分解するところから始められるようになった。ビジネスケースは、特定のワークフローを自動化する投資対効果に集中できる。バックログは「自動化を待つワークフローの一覧」になる。関数の単体テストやアプリケーション全体の回帰テストの代わりに、ワークフロー単位でテストできる。ワークフローは明確に定義され、一つの単位として実装されている (エージェントを個別にテストすべき関数に分割することはある)。セキュリティも特定のワークフローに対する脅威モデリングに集中できる。

最も興味深いのは、ビジネスプロセスと技術的なソリューションが一致することだ。「どう実現するか」の多くをビジネスユーザーから隠しつつ、現在のワークフローがどうなっていて、新しいワークフローで何を達成すべきかの議論に集中できる。ビジネスユーザーは設計や構築のプロセスにより深く関われるようになり、AI を使えばより高い抽象度で取り組める。

IT の歴史は、マシン中心のオブジェクトコードからより高レベルな表現と抽象化への進歩であり、表現するビジネスドメインに少しずつ近づいてきた。エージェント型 AI はその次のステップだ。エージェント型ワークフローは文字どおりビジネスプロセスだからだ。テクノロジーとビジネスの整合を目指す CIO にとって、大きな追い風になる。

著者について