Agent-as-a-Service（AaaS）は、エージェント型ソフトウェア：AI エージェントはソフトウェアのパラダイムをいかに再構築しているか が、商用ソフトウェア提供の第 3 世代であると論じるものに与えた名称である。同論文によるこの歴史の読み方では、各世代は複雑さをエンドユーザーから、それを最もうまく引き受けられる者へと移していく。ローカルにインストールするライセンス型ソフトウェアでは、インストールと保守は顧客の側に残された。SaaS はサブスクリプションと引き換えに、インフラと更新をベンダーに移した。AaaS は、システムを理解し、構築し、運用することをエージェントに移し、その価格は成果に基づいて設定される。
論文が、この段階を前の段階と区別するものとして主張するのは、移される複雑さの 種類 である。SaaS は企業をサーバールーム、つまり運用上の複雑さから解放した。論文の論によれば、AaaS は企業を、結果を どのように 生み出すべきかを指定すること自体から解放する。企業はどんな結果が欲しいかを指定するだけでよい。
用法
論文が示すインタラクションモデルでは、人間が意図と制約をエージェントに伝え、エージェントが自律的に計画し、実行し（必要に応じてコードを生成し）、検証して結果を届け、人間がその成果を監査してフィードバックを与える。エージェントは何千行ものコードを生成し、データベースクエリを実行し、外部 API を呼び出し、可視化を生成することもあるが、それらはすべて一時的なものである。残るのは中間的なコードではなく、エージェントの能力である。
この用語は単独で成り立つものではなく、同じ出典に由来する一連の関連概念の終端に位置する。エージェント型ソフトウェア は成果物を、エージェント型エンジニアリング はそれを構築し統制する分野を、そして AaaS はそれが顧客に届く際の商業的な形態を指す。論文がこの転換を圧縮して表した「AI → Software → Result」から「Agent → Result」へという言い方は、エージェント型ソフトウェアについて用いているのと同じものを、提供の側から読んだものである。
適用される場面
結果に至る道筋を指定せずに、結果そのものを指定し監査できる場面に適用される — そしてそれは同時に、そうでない場面では成り立たないという条件でもある。組織がまず取り組むべきものとして論文が挙げるリストは、その境界の実践版である。すなわち、明確な成功基準、明確に定義されたスコープ、既存のテスト基盤を備えたタスクである。論文は、すべてのソフトウェア作業が等しくエージェントによる自動化に適しているわけではないと明言している。
このモデルのもとでは顧客は実装を検査するのではなく結果を購入するため、提供された成果を判断するのに十分な質の評価シグナルがあることを前提とする。論文は、エージェントの出力の質は評価シグナルの質に決定的に依存すると明言しており、正しさにとどまらず、堅牢性、保守性、ビジネス上の意図との整合性まで測定するテストスイートを構築することを推奨している。
論文は経済的側面を確定したものとしてではなく、未解決のまま残している。価格設定を、差し迫ったものと考える未解決問題の 1 つに挙げている。成果ベースの価格設定 — 解決された Issue ごと、デプロイされた機能ごと — がサブスクリプションや従量課金のモデルに取って代わる可能性はあるが、インセンティブ構造とリスク配分には慎重な分析が必要だと述べている。用語としての AaaS は、境界について合意のある確立したカテゴリーではなく、進行中であると論文が主張する軌道についての、この論文独自の枠組みである。論文は各世代の代表例を挙げているが、それらをどのように選んだかは述べていない。
関連用語
- エージェント型ソフトウェア：AI エージェントはソフトウェアのパラダイムをいかに再構築しているか — この用語と 3 世代の流れを提案する論文
- エージェント型ソフトウェア — この提供モデルが届ける成果物
- エージェント型エンジニアリング — それを構築し統制する分野
- エージェント型エンジニアリングの 4 段階の進化 — このモデルが成り立つためにエージェントの能力がどこまで進歩する必要があるかについての、同じ論文によるロードマップ