9月24日、The Next Webが「Knowing was never the problem': AWS's Sivasubramanian on AI agents」と題した記事を公開した。この記事では、AWSのAIエージェント担当バイスプレジデントであるSwami Sivasubramanian氏がAIエージェントの本番導入における失敗の実態と、Amazonの社内での取り組みについて詳しく紹介されている。
「プロトタイプの90%が本番に届かない」——AWSが直視する現実
AIエージェントへの投資が加速する中、現場の実態は数字として厳しい。Sivasubramanian氏はアムステルダムで開催されたカンファレンス「HumanX」で、Amazonが2年前に構築したAIエージェントのプロトタイプのうち、約90%が本番環境に到達しなかったと明かした。
業界全体でも似た状況だ。アナリストの調査によれば、AIエージェントの実運用に成功した組織は**17%にとどまり、そのROIを測定できている企業はわずか7%**だという。顧客企業のCTOや技術リーダーたちは、取締役会からROIについて問い詰められていると同氏は語る。
「似たようなプロジェクトのプロトタイプが15個ある。どれを推進すべきか判断できない」——Sivasubramanian氏が顧客から実際に聞いた言葉
同氏と同じカンファレンスに登壇したOpenAIのColin Jarvis氏も、エンタープライズAIは「モデルではなく、デプロイメントで詰まっている」と指摘している。
プロジェクトが止まる5つの根本原因
AWSは顧客サイトに「フォワードデプロイエンジニア（Forward Deployed Engineer）」と呼ばれる現場常駐型のエンジニアを派遣し、共同でソリューションを構築する活動を行っている。この6ヶ月にわたる取り組みの中で、失敗プロジェクトの原因が5つに絞られたとSivasubramanian氏は述べた。
- 間違った問題に取り組んでいる
- 成否を測定する方法がない
- ガバナンスが後回しになっている
- リーダーがFOMOと投資リスクの間で意思決定を先送りしている
- AIに合わせた組織設計をしていない
特に深刻なのが「測定できない」問題だ。ビジネス上のアウトカムが定義されていないと、チームはPoC（概念実証）の改善を繰り返すだけで、永遠に出口を見つけられない。同氏はこれを、ヨーロッパでの初ドライブ中にパリのロータリーを4〜5周し続けることに例えた。「AIの場合、燃料はトークンと予算だ」。
1人のエンジニアの副業プロジェクトが39,000人に届くまで
失敗から学んだAmazonが取った戦略は「千の花を咲かせ、どれが機能するかを測定する」というものだった。
Amazonのパーソナライゼーションチームのエンジニア、Bolin Chen氏は、夜間や週末を使ってSlack上で動くAIアシスタント「MeshClaw」をKiro（Amazonのエージェント型コーディングツール）上に構築した。MeshCrawはSlackのチャンネルやメッセージを入力として受け取り、Kiroのエージェント機能を介してコード生成・検索・タスク実行などを行う仕組みだ。社内Slackチャンネルでシェアしたところ、1人から4人の共同創業者へ、そして数千人のコントリビューターへと広がった。
AmazonのKiroチームは同時期に、3つの機能のプロトタイプを開発していた。常駐エージェント（セッションをまたいで継続的に稼働するエージェント）、永続メモリ（過去のやり取りや状態を記憶し次回以降の実行に活用する仕組み）、そしてマルチエージェント連携（複数の専門エージェントが役割分担して協調動作する構成）である。2つのグループは合流し、オープンソースプロジェクト「Kiro Crew」が誕生した。「Kiro Crew」はKiroとは別に提供されるマルチエージェント連携機能であり、Kiroの公式ドキュメント上でその詳細を参照できる。社内公開から30日以内に39,000人のAmazon社員が利用し、外部コントリビューターは500人に達したという。
さらに、KiroはKiro自身を改善することもある。システム内部のエージェントが「前回の実行から変更されていないファイルを再読み込みしている」という非効率を検出。エージェント自身が問題を診断し、修正を書き、検証した結果、その無駄を83%削減した。
「人間が問題を診断したのではない。システム自身が発見した」——Sivasubramanian氏
エージェントを「箱」に入れる——確定的なガバナンス
Amazonの社内では、EC2・EKS・SageMakerなど複数のサービス上にバラバラとエージェントが構築され、セキュリティやインフラチームに大きな負荷をかけていた。この問題に対し、AWSはAI推論をBedrock、エージェントホスティングをAgentCoreに集約する「ゴールデンパス（標準化された単一経路）」を確立した。
AWSのオープンソースエージェントフレームワーク「Strands」には、エージェントを「箱」に入れる機能が追加された。箱はエージェントの外側に置かれる決定論的なレイヤーで、エージェントが呼び出せるツールを制御する。エージェントの信頼性が証明されるにつれて、箱を広げていくことができる。
「確率的ではない。エージェントが境界を超えられないことは、常に決定論的かつ数学的に証明可能だ」——Sivasubramanian氏
なお、Google DeepMindのKareem Ayoub氏も同カンファレンスで、AIを「フェンスで囲む」アプローチの重要性を語っている。
6人・76日でBedrockを再設計
Sivasubramanian氏は「曖昧性の高いプロジェクトは、極めて小規模なチームから始めるべきだ」とも強調した。
Fortune 100企業の約80%がBedrockを利用しており、同氏はBedrockをAWSで最も成長が速いサービスと表現した。需要が急増した際、6人のエンジニアが76日でBedrockを再設計した。通常であれば30人のエンジニアが18ヶ月かける作業量だという。システムがスケールするにつれてチームは35人に拡大した。
Kiroが一晩で生んだ「Amazon Quick」
Bedrockの再設計と並び、小規模チームによるスピード開発の好例として紹介されたのが「Amazon Quick」だ。あるサイエンティストがKiroを使って一晩でデスクトップアプリを構築し、1週間以内に経営陣に披露。AWSは3ヶ月以内に外部向けにリリースした。Amazonの数十万人の社員が現在Quickを使っているという。BedrockとQuick、いずれの事例も「小さく始めて、成果が出たら広げる」というAmazonの共通原則を体現している。
すべてのAIプロジェクトに問うべき2つの質問
Sivasubramanian氏は聴衆に、AIプロジェクトを評価する際に必ず以下の2点を問うよう求めた。
- どのビジネスアウトカムに紐づいているか？
- すべてのレイヤーで複利的に積み上がっているか？
「知ることは、かつても今も問題ではない。問われるのは、実行するための厳密さと規律を持っているかどうかだ」——Sivasubramanian氏
詳細はKnowing was never the problem': AWS's Sivasubramanian on AI agentsを参照していただきたい。
