アマゾン式 AIエージェントOS開発と実装のリアル
9月ですね。AIエージェント元年と言われた2025年も、残すところあと4か月。7月にソフトバンクの孫正義氏が「年内に10億個のAIエージェントを作る」と発表し話題になりましたが、各企業でのAIエージェントの導入は、どこまで進んでいるのでしょうか。
アマゾンでも、非エンジニアが使える社内AIエージェントOSの開発が進められています。上半期はベータ版だったこのOSは、その後社内で一般提供され、瞬く間に数千ものAIエージェントが作られました。私もベータ版から参加させてもらい、2週間ほど前に、チームの業務を代替するAIエージェントのプロトタイプがようやく出来上がりました。一連の流れを経て、AIエージェントOSの課題や、今後目指す姿が見えてきたので、今日はこのテーマについて感じたことを共有したいと思います。
非エンジニアでも使えるローコード・セルフサービスOS
アマゾンでは、「知識オペレーション業務」の自動化により、社員が最も創造的かつ重要な意思決定に集中できる環境を用意することを目指しています。「知識オペレーション業務」とは、「物理的な動作を伴わずに、情報の作成・整理・共有・活用を行うタスク形式の業務」のことを指します。ざっくり言うと、タスク形式のデスクトップワーク全てです。このビジョンに基づき、アマゾンでは、社内のどんなタスク形式業務でも担える汎用的なAIエージェントOSの開発を進めています。
現時点の活用例を挙げると、「出品者が提出した情報が、政府に登録されている情報と合致しているかを確認するAIエージェント」、「出品者のエコバッジ認定を審査するAIエージェント」、「カスタマーサービス業務で発生するチケットの重複を排除し、適切な部署にリクエストを送るAIエージェント」など、多岐に渡ります。今後も、カスタマーサポート、コンテンツ生成、財務分析、監査、不正行為検出、需要創出など、あらゆる分野で利用されると想定されます。
多岐に渡るタスクを担うために、OSには「ケイパビリティ」と呼ばれる基礎機能が数多くあり、ユーザーはそれらをレゴのブロックのように組み合わせてワークフローを設計できます。例えば、「ウェブページ解読」、「データ解析」、「光学文字認識」、「テキスト分類」、「画像分類」といった機能です。
よりイメージを沸かせたい方は、Zapier、Lindy、Relay、Make、Agentforceといった汎用AIエージェントOSを見て頂くと、どんな形で業務が設計できるか理解しやすいと思います。
「対外的にはAWS Bedrock AgentsやAWS Strands Agentsを提供しているのに、なぜ別のAIエージェントOSを？」と思った方もいるかもしれません。主な理由は、非エンジニアでも使えるローコード・セルフサービスなOSを用意することで、エンジニアがいない数多くのオペレーションチームでも迅速にAIエージェントを利用できる環境を整えたいからです。実際、非エンジニアの私も、社内版Claudeに毎日質問を聞きまくり、それでも分からないことはOS開発チームに助けをもらいながら、AIエージェントを作ることができました。
実装のハードルを下げるプロダクト面の工夫が必要
数千ものAIエージェントが社内で作られると、多くのAIエージェントに共通する課題が見えてきました。特に、非エンジニアにとっては実務で使えるAIエージェントの構築は容易でなく、そのハードルを下げるプロダクト面での様々な工夫が求められています。
①アクセス権限設定の難しさ
新入社員が入社すると、様々な社内システムへのアクセス権が必要ですよね。AIエージェントも同様に、必要なデータ、API、及びツールのアクセス権を適切に付与する必要があります。しかし、このプロセスは非エンジニアにとっては馴染みのあるものではありません。特にAPIに関しては、具体的に必要なAPI名や、システム環境、処理能力を定義する必要があり、私も手探りで進めていました。必要なアクセス権限を特定し、全ての権限を取得するのは、想像を超える長い道のりでした。
ユーザーとしては、こんなことに手間取ることなく、「まずこのAIエージェントOSで何ができるのかを知りたい」ですよね。OSを普及させるには、権限を設定しなくても触れる簡易テスト環境や、非エンジニアでも分かるコンソール内のガイダンスなどが必要となりそうです。また、AIエージェントを人間と同様の「社員」と認識し、手動のAPIアクセス承認を必要としない認証の仕組みなども求められそうです。
②業務フロー設定の分かりにくさ
様々な業務をこなすために定義されたケイパビリティ（機能ブロック）ですが、人は通常、「私は日々『光学文字認識』をした上で、認識した文字を『テキスト分類』している」などと考えません。AIエージェントOSを普及させるには、「私の業務フローを書き出したから、これを基にAIエージェントの設計を考えて」と指示できる変換機能も必要かもしれません。
また、社内外の例を見ていると「テンプレート」の重要性も感じます。「あ、このAIエージェントテンプレートは自分がやりたかった業務に似ている」と認識できれば、ゼロから作らずに、テンプレートを使って試して、できたらカスタマイズ、といくつかのステップに分解することができます。
③他ツールとの統合・連携
社員に代わって業務を担えるAIエージェントのPOCは数多くできたものの、本格的に日々運用できているチームの割合はまだ少ない状況です。特に大きな理由としては、社内の他ツール（ダッシュボード、ストレージ、等）との統合が不十分なことや、イベントのトリガー設定（「これが終わったら、次このタスクを始めて」といった指示）機能が足りないことが挙げられます。本格運用には、これらの機能の拡充が必要となります。
④成果の数値化
多くのAIエージェントがPOC段階であることもあり、まだ各エージェントの効果が可視化できていないのも課題です。費用対効果を数値化するための共通フレームワークや、1タスク完了あたりの価値を定義・測定していく必要がありそうです。社外に目を向けると、カスタマーサービスAIエージェントSierraのように、社員を介さずに顧客の要望を解決できたらいくら支払う、といった成功報酬モデルも見られます。このような実際の成果に基づく価値評価が今後一般的になってくるのかもしれません。
新たな働き方への適応も鍵。導入支援サービスの出番か
また、実用化に向けては、技術面だけではなく、関係者間での新たな働き方が求められることも見えてきました。
①実用化には、AIから社員への橋渡しや、双方の精度把握が不可欠
実用化のハードルとして「他ツールとの統合・連携」を挙げましたが、その上でさらに必要なのは、「どこから人が介入するか」、そして「AIの精度をどう把握するか」の業務設計です。「ミスもあるけど、大体あっていればOK」なんて仕事は普通、存在しないからです。
実用化においては、まず、AIエージェントが裁けない・分からないと判断したタスクは社員に回さなくてはなりません。さらに、AIエージェントの成果物をモニタリングし、間違っていたら、AIエージェントがその間違いを犯さないよう、プロンプトなどの指示を改良する必要があります。モニタリングにおいては、別のAIエージェントによる検証（「LLM-as-a-judge」と呼ばれる手法）や、人間による監査などの方法があります。
私のチームでは、「どれくらいの精度ならAIエージェントに任せられるのか？」という問いに対し、「社員の精度かそれ以上ならOK、但し抜き打ちチェックがある前提で」という結論に辿り着きました。すると、「社員の精度ってどれくらい？」という質問に繋がり、社員の精度はあまり厳格に把握できていないことに気が付きました。現在は定期的な社員の精度評価も導入でき、今後はAIと社員の双方の精度をモニタリングしていく予定です。
②プロンプトの作成・評価は、ビジネスパーソンのコアスキルに
AIエージェントに求められるプロンプト力は、日常的にAIと会話する際のプロンプト力とは性質が異なります。何百、何千、何万回のタスクをできる限り正確にこなすには、LLMの潜在能力を最大限に引き出すプロンプト設計とテストが不可欠です。
一方、プロンプトエンジニアリングを引き受けてくれるサイエンティストやエンジニアが潤沢にいる企業はそう多くないでしょう。AIエージェントOSが急速に普及しつつある今、実装に求められるギャップを埋めるには、ビジネスパーソンが自らこのスキルを学ぶしかありません。
今後別途「プロダクト作りに求められる良いプロンプト」について深堀りしたいと思いますが、大きくは以下のようなステップが必要となります：
絶対やってほしいことと、絶対やってほしくないことを定義する
人と機械の両方が読める形で構造を整理する（XML、JSONなど）
プロンプトが書けたら、プロンプトの自己改善をLLMに指示する
100件ほどサンプルデータをテストし、間違いを特定・分析する
精度の測定方法を定義し、プロンプトのバージョンごとに精度を測る
精度が十分に高まったら、プロンプトを簡略化して推論コストを下げる
③関係者の理解や信頼を得るのは一苦労
AIは従来のソフトウェアとは異なり、同じ指示を出しても毎回答えが違う、非決定性の特性を持ちます。そんなAIに重要な業務を任せることは、特にオペレーション側の関係者にとっては大きな心理的ハードルです。私のチームでは、オペレーションのニーズに基づいた迅速なプロンプトの更新はどんな役割分担で行うのか、アウトプットはどんな形で出力され、どのように精度をモニタリングするのか、といった実務面まで何度も話し合いを重ね、要件に落とし込む必要がありました。同時に、サイエンティストとは、どの指標をゴールにするのが適切で、どのレベルに達すれば合格なのか、サンプルはいくつ見れば良いのか、といった統計的な議論を進めました。振り返ると、要件が固まるまでに計10回程度のミーティングとその前後の精緻な文章化を要しました。
上記のような細かい連携を考慮すると、PalantirやAccenture、そして最新の報道ではOpenAIのように、プロフェッショナルサービスを通じた導入支援がビジネスになる理由も納得できます。AIエージェントOSをプロダクトとして提供するなら、序盤は手厚いプロフェッショナルサービスもセットで提供し、徐々に顧客のフィードバックをプロダクトに反映させて自動化を図ることが、成功への道筋になりそうです。
どこまでセルフサービスにできるか
今後AIエージェントOSを真に普及させるためには、何と言ってもユーザーが自律的にAIエージェントを設計・導入・管理できることが鍵となるでしょう。そのためには、上述のような技術的課題をクリアし、エージェントの作成、バグ検出、評価、トリガー設定などの各ステップが直感的に行える設計とインターフェースが必要となります。
とはいえ、これらの要件は技術的には解決可能です。だとすると、AIエージェントOSの普及も時間の問題。来年の今頃には、きっと多くの業務がAIエージェントによって自動化されていることでしょう。人はAIを設計・管理する立場に回りながら、より創造的かつ戦略的な業務に集中できるようになっているはず。。。とすると、ますますリスキリングは重要になりそうな予感がします。では、今日はこの辺で。
