Amazon Web Services ブログ
AWS Summit Japan 2026：完全自律型 AI Agent が変える SaaS の世界
2026年6月25日・26日の2日間、AWS Summit Japan 2026 が開催されました。本ブログは、AWS Expo エリア内にてデモを展示した「完全自律型 AI Agent が変える SaaS の世界」ブースの内容をご紹介します。デモの背景にある課題認識、技術的な仕組み、来場いただいたお客様の反応、そして本テーマに興味を持つ方向けの次のステップを記載します。
なぜこのデモを展示したのか
Agent 時代の SaaS に想定される 2 つの変化
AI Agent の台頭により、SaaS に求められる要素が変わりつつあります。この変化は大きく 2 つの側面に分けられます。
- Agent に使われる SaaS — 外部の AI Agent が MCP や API 経由で SaaS を操作する。SaaS 側は「Agent-Ready」なインターフェースを整備する
- Agent を取り込む SaaS — SaaS 自体が AI Agent を内包し、業務を自律的に遂行する。人間は結果を確認・承認する
本ブースでは 後者の 「Agent を取り込む SaaS」 に焦点を当てました。
お客様との会話から見えた課題
これまで我々がお客様を支援し、会話してきた中で、多くの SaaS 事業者が Agent に強い興味を持ちつつも、顧客満足度向上・解約率低下・ARR 向上といった自社のビジネス目標の達成に Agent をどう結びつけられるかで悩まれていることがわかりました。具体的には下記のようなお悩みです。
- 「どこに Agent を入れることで、顧客体験をより良くすることができるのか」
- 「Agent 活用について検討してみると、個々の機能はワークフロー + LLM で実現できるもので、Agent にする意味があまりなかった」
- 「Agent に任せなくても良いタスクまで Agent に任せてしまい、コストやスケーラビリティの課題が生じた」
これらに対する 1 つの Agent 活用の具体的な提案を、デモとして展示することを目指しました。
ユーザー体験の変化 — Agent を取り込むと何が変わるか
本デモでは架空の AI CRM サービスを想定したデモを構築しています。Agent が組み込まれた CRM によってどのような顧客体験を目指すかを具体例で見てみましょう。下記の画像は、BtoB SaaS 企業の営業チームに 1 通の問い合わせメールが届いた場合のフローです。
従来の CRM ではすべてのステップを人間が担い、返信まで 2 時間を要しますが、AI CRM の場合は人間が実行するのは CRM 上での「承認」のみで、一連の流れは 5 分以内で完了します。
ここでのポイントは、AI が担っているステップの中身です。メールの分類、顧客情報の調査、回答文の生成 — これらを単純な if/then のルール分岐や LLM の呼び出し、RAG の活用等によって個別に実現することは可能です。しかし、実際の営業現場では「分類 → 調査 → 生成 → アサイン → 提案」が一連の流れとして連鎖し、途中の結果によって次のアクションが変わります。すべてのパターンを事前にルール化しようとすると分岐が膨大になり、新しいケースが生まれるたびにルール追加が必要となります。
Agent の価値は、各ステップの結果をコンテキストとして保持しながら、次のアクションを実行時に判断できることです。パターンの事前網羅が不要であるため、事業成長に伴って業務パターンが増えた場合でも、メンテナンスコストが雪だるま式に増えることがありません。
デモの全体像
デモで展示した AI CRM の機能
本デモでは、AI CRM を実装しました。架空の BtoB SaaS 企業の営業チームが日常業務で AI CRM を使う想定です。以下の機能を含むデモを展示しました。
CRM の価値は単体の機能だけでなく、メール・サポートツール・マーケティングツールなど、業務で日常的に使われている複数のソリューションからの情報を集約し、横断的に活用できる点にあります。本デモでも、メールやチケット管理といった機能は AI CRM 自体の機能ではなく、既存のソリューションとの連携を意識して設計しています。SaaS が他のサービスと繋がりやすい構造を持つことで、Agent がそれらの情報を横断的に処理できるようになります。冒頭で触れた「Agent に使われる SaaS」の観点からも、SaaS が外部から情報を取り込んだり連携されたりするためのインターフェースを整備しておくことは、Agent 時代における重要な設計要素と言えます。
受信箱：イベントを集約 各種イベントを 1 箇所に集約し、確認する画面 |
受信箱：Agent の処理過程 マルチ Agent 処理の過程を確認できる |
承認待ち：判断ポイント 人間が承認カードに対して承認・修正・却下で判断 |
承認待ち：判断内容の確認 AI の判断理由確認やフィードバックも可能 |
メール 送信済みのメールを確認する画面、AI の判断メモで引き継ぎが容易 |
サポートチケット ナレッジベースを参照し、問い合わせの回答を自動で生成 |
シグナル 見込み顧客の行動からリードスコアを付与 |
担当者アサイン 新規顧客の場合は、Agent が最適な営業担当を提案 |
ナレッジベース・スキル ドキュメントを追加して AI の精度を向上 |
ボード 業務フローを俯瞰し、滞留している案件を確認 |
エージェントモニター マルチ Agent の稼働状況をリアルタイム表示 |
システム構成
本デモのアーキテクチャはこちらです。
本デモのアーキテクチャ上のポイントは、 Amazon Bedrock AgentCore を活用している点です。Agent は AgentCore Runtime で実行、ツールは AgentCore Gateway で管理、メモリは AgentCore Memory で保持、可観測性は AgentCore Observability でトレーシング、Agent の行動制約は AgentCore Policy で実現しています。
マルチエージェント構成
本デモでは、下記の画像に記載する 6 種類の Agent が協働しています。受信したイベントの内容を判断して適切な専門 Agent に振り分ける Orchestrator Agent を中心に、それぞれの Agent が異なる業務領域を担当します。
Agent Ready な SaaS を構築する 4 つのポイント
本デモでは、Agent を SaaS に取り込むうえで重要な 4 つの設計ポイントを実装しています。
| # | ポイント | 概要 |
|---|---|---|
| 1 | コンテキスト蓄積 | Agent が正しく動くためのデータを使える状態にする |
| 2 | 業務実行のためのツール | 提案ではなく業務を「完了」する仕組み |
| 3 | ガバナンス・証跡の保持 | Agent が暴走しないための安全な設計 |
| 4 | マルチテナント分離 | 複数テナントに安全に提供するための基盤 |
① コンテキスト蓄積 — Agent が正しく動くためのデータを使える状態にする
Agent が問い合わせに対応するには、「この企業は初めての問い合わせか？」「過去にどんな要望があったか？」「どのようなトーンで回答すべきか？」といった多様なコンテキストが必要です。これらを人間が手動で投入し続けるのは現実的ではないため、自動で蓄積されていく仕組みを整えておく必要があります。
本デモでは、3 つの層でコンテキストを蓄積・活用する仕組みを設計しました。
| 層 | 仕組み | 例 |
|---|---|---|
| 人間が登録・フィードバック | ナレッジベース / スキル | ドキュメント追加で回答精度向上。フィードバックボタンからのフィードバックを収集し、定期的に Skills を改善 |
| 業務で自動蓄積 | CRM の業務データ + ツール化 | 通常の SaaS と同様に蓄積されるデータを、Agent がツールで確実に参照できる設計にする（ツール化については②で後述） |
| Agent が自動蓄積 | AgentCore Memory | 対話のたびに顧客ごとの経緯・属性・好みを自動で記録・更新 |
特に AgentCore Memory により「利用するほど賢くなる」Agent を実現しています。AgentCore Memory の保存キーをテナント ID × 顧客 ID で構成することで、対話のたびに顧客固有の経緯や好みが自動で蓄積され、対応の質が自然に向上していきます。
② 業務実行のためのツール — 提案ではなく業務を「完了」する仕組み
Agent が業務を「完了」するには、データベースや外部 API といったリソースに Agent 自身がアクセスする必要があります。しかし Agent に直接アクセスさせるわけにはいきません — 権限管理、監査、テナント分離の観点から、「ツール」として定義し、それ経由で扱わせる設計が求められます。
本デモでは、AgentCore Gateway を利用してツールを整備しました。AgentCore Gateway を利用するメリットは主に 3 つあります。
- MCP サーバーの自前実装が不要 — 既存の Lambda 関数や API をそのまま Agent が呼べるツールに変換できる。MCP プロトコルの実装やインフラ管理は Gateway が吸収する
- セマンティック検索によるツール発見 — ツール数が増えても、Agent が自然言語クエリで適切なツールを検索・発見できる（
x_amz_bedrock_agentcore_search）。ツールが数百に膨らんでも Agent が迷わない - 認証の一元管理 — Inbound（Agent の身元確認: CUSTOM_JWT）と Outbound（ツール接続先への OAuth）を Gateway 1 箇所で管理。Agent ごとの権限分離も容易
それぞれのツールは AWS Lambda の関数として Python で実装し、名前・説明・入力スキーマを定義して AgentCore Gateway に登録しています。Agent はこのスキーマをもとに、どのツールをいつ呼ぶかを自律的に判断します。たとえば企業情報の取得（get_company_info）、リードスコアリング（score_lead）、提案文の生成（generate_proposal_content）、商談ステージの更新（update_deal_stage）、承認の起票（enqueue_approval）など、情報収集から判断・生成・実行まで 22 のツールを整備しています。
③ ガバナンス・証跡の保持 — Agent が暴走しないための設計
Agent を業務に組み込む際の主要な懸念は、「意図しないアクションを実行される」「根拠なく間違った回答が行われる」「アクションの記録が残らない」の 3 つです。
ガードレール — 意図しないアクションの実行を阻止する
Agent がツールを呼び出す際は、すべて AgentCore Gateway を経由します。Gateway 上では 2 つのチェックが行われます。1 つ目は「誰が呼んでいるか」— Agent ごとに最小権限を付与し、たとえば Customer Support Agent は CRM への書き込みができません。2 つ目は「条件を満たしているか」— Cedar Policy でビジネスルールを宣言的に定義し、金額上限超過やテナント境界不一致を deny します。deny された場合、Agent は迂回せず承認カードとして人間に判断を委ねます。チェックを通過したアクションは承認キューに入り、人間が承認するか、条件を満たせば自動承認で実行されます。
品質検証 — 根拠のない間違った回答を阻止する
サポート回答では Generator-Verifier パターンを採用しています。回答を生成する Agent と、その回答をナレッジベースと照合して検証するプロセスを分離し、検証に合格しない限り回答が顧客に届かない構造です。不合格の場合は自動で再生成を試み、それでも合格しなければ人間にエスカレーションします。
全 action 記録 — アクションの記録を残す
全 Agent の全意思決定が監査ログに記録され、ダッシュボードからリアルタイムで閲覧可能です。
④ マルチテナント分離 — 複数テナントに安全に提供するための基盤
当然マルチテナントについて考慮することが必要ですが、SaaS に Agent を取り込む場合は、従来のデータ分離に加えて「Agent の行動範囲の分離」という新しい課題が生まれます。本デモでは認証からデータ、Agent のセッションまで、全レイヤーで tenant_id を利用して分離を実現しました。
| 分離するもの | 避けたいこと | 分離方法 |
|---|---|---|
| 認証 | 他テナントになりすましたリクエスト | Cognito JWT に tenant_id を埋め込み、リクエストごとに「この人はどのテナントか」を識別。自テナント以外のリソースへのアクセスは拒否 |
| データ | 他テナントの顧客情報・商談を閲覧する | Aurora: WHERE tenant_id = ?、DynamoDB: PK に tenant_id を含める |
| Agent のメモリ | 他テナントの対話履歴や好みが Agent の応答に影響する | AgentCore Memory の保存キーを「テナント ID × 顧客 ID」で構成し、別テナントの記憶は読めない構造にする |
| Agent のアクション | Agent が他テナントのデータを操作する | Cedar Policy で「操作者のテナント ≠ 操作対象のテナント」である場合にツールの実行を禁止する |
| Agent の処理状態 | あるテナントの処理途中のコンテキストが、異なるテナントの処理に引き継がれる | 処理ごとにテナント専用のセッションを生成し（セッション ID にテナント ID をプレフィックスとして含める）、他テナントの処理状態を参照できない構造にする |
これらの多層防御により、Agent が意図せず他テナントのデータにアクセスすることを防いでいます。
来場いただいたお客様の反応
2日間のブース展示を通じて、多くのお客様と対話させていただきました。特に多かったご質問・反応を共有します。
AgentCore をどのように使っているか？
サブタイトルが「AgentCore で実現する Agent Ready な SaaS アーキテクチャ」であることから、Amazon Bedrock AgentCore に興味を持たれているお客様からの、「どのように AgentCore を活用しているか？」といったご質問が多く、特に関心が高かったのは以下の 3 点です:
- AgentCore Gateway によるツール化 — 既存の API や関数を Agent が呼べる「ツール」として Gateway に登録し、MCP サーバーの自前実装なしで Agent にアクションを実行させている点
- マルチエージェント構成での AgentCore Runtime 活用 — 1 つのコンテナイメージを共有しつつ、Agent ごとに独立した Runtime を立てて権限とスケーリングを分離している点
- AgentCore Evaluator による回答検証 — 生成された回答をナレッジベースと照合して自動検証し、品質が閾値を下回る場合は送信せず再生成またはエスカレーションする仕組み（AgentCore Evaluator における Built-in の Faithfulness や Helpfulness といった指標）
特に、3 つ目の Evaluator に関連して「AI が勝手にメールを送ってしまわないか」という懸念が多く挙がりました。前述の③で紹介した承認フロー（Human-in-the-Loop）、Cedar Policy、Generator-Verifier、監査証跡の多重チェックをデモ画面で実際に見せながら説明したことで、「具体的にどこで人間が介入できるのかが分かった」「段階的に自動化レベルを上げていけるイメージが持てた」という反応をいただきました。
Agent-Ready な SaaS にするには？
「サブタイトルに記載している “Agent Ready な SaaS アーキテクチャ” とは何か？」といったご質問もいただきました。
前述した 4 つのポイント（コンテキスト蓄積・業務実行のためのツール・ガバナンス/証跡の保持・マルチテナント分離）が SaaS への Agent 組み込みのポイントとなりますが、これまでお客様との会話の中で特に事前に整えておくべき実装上の懸念として挙がったのは、2 つ目の 「業務実行のためのツール」 です。
既存の SaaS で業務ロジックがアプリケーションから直接 DB クエリとして実行されていたり、コンポーネント間が密結合で Agent からのアクセスを負荷的に受け入れられない構造になっている場合、Agent が利用できるインターフェースが存在しません。Agent は「ツール」を通じてのみ外界に作用するため、ツールとして切り出せるインターフェースがなければ、そもそも Agent を組み込む起点がないということになります。
Agent 導入を見据えるなら、まず業務ロジックを API や関数として分離し、Agent にツールとして与えられる状態を作ることが必要です。本デモではこの考え方に基づき、22 のツールをすべて独立した関数として定義し、AgentCore Gateway に登録しています。
おわりに
おすすめの Next Action
ワークショップ
マルチテナント AI Agent のアーキテクチャを段階的に学べるワークショップ「マルチテナント AI エージェント構築ワークショップ」を公開しています。ワークショップでは、Strands Agents SDK を使った Agent の構築から、AgentCore Runtime へのデプロイ、マルチテナント分離の実装、Human-in-the-Loop の承認フロー組み込みまでを一通り体験できます。
また、Amazon Bedrock AgentCore の各機能を学べる「Amazon Bedrock AgentCore ワークショップ」もあわせてご確認ください。
ブース配布資料
Summit 会場でお配りした資料も公開しています。本デモの内容についての資料ではなく、SaaS x AI Agent 関連で参考にしていただける資料を作成しています。
- AWS Summit Japan 2026 SaaS ブース配布資料
- 「SaaS アーキテクチャの設計思想 AI Agent との共創」
- 「SaaS × AI Agent プロダクト戦略の具体化」
- 「SaaS 業界での製品への AI Agent 組み込み」
ブースデモ開発における AI の活用
本題とは逸れますが、本デモは、AWS に所属するソリューションアーキテクトが Coding Agent を全面的に活用して開発しました。4 名のメンバーが約 1 ヶ月で、フロントエンド・バックエンド・インフラ・Agent 実装を含むシステム全体を構築しました。開発を加速するうえで特に効果が大きかった工夫を 3 つ紹介します。
1. 複数人・短期間での効率的なデモ開発のための工夫
本ブース開発においては短期間で複数人が AI Coding Agent を使って並行開発を実施したため、下記の Skill を共有して進めました。
- 着手宣言 — Issue に取り組む前に「どのファイルを触るか」「方針は何か」をコメントで宣言します。AI が生成するコードの影響範囲が事前に可視化され、同じファイルを複数人が同時に編集する事故を防止します
- 開発プロセスの明文化 — 「テストを先に書く」「API 設計はこのパターンに従う」等のルールを Skill ファイルとして定義しました。チーム全員の AI が同じプロセスに従い、誰が依頼しても同じ品質が再現されます
もちろん、これらの工夫をしてもコンフリクトは起こり得ます。しかし、デモという性質上スピードを優先できる場面も多く、Coding Agent を使った開発では人がコーディングするよりもはるかに速く実装が進むため、多少の手戻りやコンフリクト解消のコストを許容して前に進めることができました。
2. Agent を実装する前に、決定論処理で実装する
Agent の実装では、最初から LLM に判断を委ねるのではなく、まず決定論的なロジックで全体のフローを構築し、テストを十分に書いてから、段階的に LLM 呼び出しに置き換えていきました。
Agent は LLM の出力に応じて次のアクションが分岐するため、最初から LLM を組み込むと「どこで意図しない動作が起きたか」の切り分けが困難になります。決定論でフローを確立し、テストで期待動作を固めてから LLM 化することで、問題の発生箇所を即座に特定できます。
3. Agent の責務境界を明示的に定義する
マルチエージェント構成では「どの Agent が何を担当するか」の境界設計が最重要です。この境界が曖昧なまま AI にコードを書かせると、責務が重複したり、あるべきでないデータアクセスが生まれたりと言ったことが有り得ます。
本プロジェクトでは、Agent の責務分担・使えるツールの範囲・メモリの境界を設計書として先に定義し、AI がそれを参照しながら実装する形を取りました。設計書が「Agent の契約」として機能することで、実装段階での判断ブレがなくなり、複数人が別々の Agent を並行開発しても全体の整合性が保たれます。