AWS Summit Japan 2026 参加レポート：AI Agent を本番業務で使うために考えたこと

エンジニアの柿添です。
2026年6月25日,26日に開催された AWS Summit Japan 2026 に参加しました！！

今回、主に参加したのは AI Agent、Amazon Bedrock AgentCore、Strands Agents、評価、認証認可、本番運用に関するセッションです。結構な確率でトラック3に座っていたのではないでしょうか？笑

全体を通して感じたのは、AI Agent の話が「AI に質問する」段階から、 AI と一緒に業務を進める段階に移ってきていたところかなと思います。

これまでの生成 AI 活用は、文章生成、要約、社内文書検索、問い合わせ対応などが中心でした。もちろん、それだけでも十分に価値がありますが、AI Agent はそこから一歩進んでいます。

ユーザーの依頼を解釈し、必要な情報を探し、社内システムや外部サービスを操作し、業務フローの一部を進める存在になってきています。

AWS Summit Japan 2026 でも、AI Agent が「作れるか」よりも、 本番業務でどう安全に動かすか が大きなテーマになっているように感じました。

この記事では、AWS Summit Japan 2026 で参加したセッションをもとに、 AI Agent を本番業務で使うために必要だと感じた設計観点を整理したいと思います。

自分なりの結論

AI Agent の本番活用で重要なのは、AI に何を答えさせるかではなく、AI が安全に業務を進められる流れをどう作るか

私自身、少し前まで「AI が進化するとエンジニアの仕事がなくなるもしくはかなり減る」と思っていました。ただ、今回の AWS Summit に参加したことで、多少なりともその見方が変わりました。

たしかに、コードを書く作業や調査、ドキュメント作成などは、AI によってかなり効率化されていくと思います。一方で、AI Agent を本番業務に入れるには、むしろ考えることが増えるのではないでしょうか...？

何を見せるのか
どの Tool を使わせるのか
誰の権限で動かすのか
どこまで自動実行させるのか
どこで人間に戻すのか
間違えたときにどう止めるのか
後から説明できるログを残せるのか
品質をどう評価するのか

このあたりは、AI だけでは勝手に決まることはないと思います。業務を理解し、システムとして設計し、運用できる形に落とし込む必要があります。

そう考えると、エンジニアの仕事がなくなるというより、むしろ エンジニアが設計する範囲が広がっていく、という見方の方が近そうな気がしています。

「AIに聞く」から「AIと業務を進める」へ

AI Agent をチャットボットの延長で見ていると置いていかれると思っています。「AI使えない、精度が悪い」という声もAIの使い方がチャットボットくらいに止まってしまっていて、この辺りに近しいかなとも思っております

チャットボットであれば、AI が回答し、人間がそれを読んで判断、多少間違っていても、最終的には人間が確認する余地がありますが、 AI Agent が Tool を呼び出すようになると、話が変わります。

たとえば...

顧客情報を参照する
問い合わせチケットを更新する
社内文書を検索する
請求書と発注情報を照合する
承認フローに回す
外部 API を呼び出す
必要に応じてメールや通知を送る

ここまで来ると、AI の出力はただの文章ではなく、業務への作用になります。そのため、本番業務で使う場合は、単に「AI が賢いか」では足りません。

AI が使う情報、Tool、権限、実行範囲、停止条件、人間の確認ポイント
まで含めて設計する必要があります。今回の Summit で繰り返し出ていた論点も、まさにここでした。

今は Loop Engineering を考える段階に来ている

少し前までは、生成 AI 活用というと Prompt Engineering が中心でした。その後、AI にどの情報を渡すかを考える Context Engineering が重要になりました。さらに、AI Agent を実行するための環境や Tool、権限、監視を整える Harness Engineering の話も出てきました。ただ、今はそこからさらに進んで、Loop Engineering を考える段階に来ていると感じています。

Loop Engineering は、ざっくり言うと、

AI Agent が、目的に向かって考え、Tool を使い、結果を確認し、必要ならやり直す流れを設計すること

だと思っております。

Business Insider でも、Loop Engineering は人間が毎回プロンプトを書くのではなく、AI Agent がタスク完了まで動けるようにする仕組みとして紹介されています。
Google Cloud の Addy Osmani 氏も、Loop には automation、worktrees、skills、plugins/connectors、sub-agents といった要素があると説明しています。 Forget Prompts: 'Loop Engineering' Is All the Rage Now - Business Insider

業務で考えると...？

依頼を受ける
必要な情報を探す
判断する
Tool を実行する
結果を確認する
必要ならやり直す
条件を満たしたら完了する
危険な場合は人間に戻す

この流れを安全に回すことが、本番業務での AI Agent 活用では重要になります。 AI Agent は「1回答えて終わり」ではなく、業務の中では、判断と実行を繰り返します。だからこそ、Loop の設計が必要になりますが、便利な一方で、危険でもあります。

終了条件がないと、処理が止まらない...
失敗時の設計がないと、同じ誤りを繰り返す...
コスト上限がないと、気づかないうちに費用がとんでもないことに...！
承認条件がないと、本来人間が見るべき処理まで進むもしくは勝手にやる涙

AI Agent の本番運用では、Loop を作るだけでなく、Loop をどこで止めるか まで決める必要があります。

AgentCore は Loop を本番で回すための基盤に見えた

今回の AWS Summit で特に印象に残ったのが、Amazon Bedrock AgentCore です...！元々 Bedrock に触れたことはありましたが、ここまで進化して周辺が揃っていることは認識しておりませんでした！

AgentCore は、AI Agent を安全かつ大規模にデプロイ・運用するための基盤として説明されてます。
AWS の公式ページでも、Agent を作ること自体よりも、システム接続、Tool 呼び出しの保護、想定外の挙動のデバッグ、スケールといった部分が課題になると整理されています。 Amazon Web Services, Inc.

AI Agent は、モデルだけでは本番で動きません。

実行環境
メモリ
Tool 接続
認証認可
ポリシー制御
監視
評価
ログ
コスト管理

このあたりが必要になります。

AgentCore は、そのための部品をまとめて提供する基盤として見ると分かりやすいです。たとえば、AgentCore Harness のドキュメントでは、Agent にはモデルを呼び、Tool を選び、結果を受け取り、コンテキストを管理し、失敗を扱う orchestration loop があると説明されています。

そして、本番運用には compute、sandbox、安全な Tool 接続、filesystem、memory、identity、observability が必要だと整理されています。 AgentCore harness - Amazon Bedrock AgentCore

AI Agent の本番運用は、モデル単体の話ではありません。 AI Agent が業務の中で何度も判断し、Tool を使い、結果を確認する Loop を、安全に動かすための基盤が必要になります。

AgentCore は、その Loop を本番で回すための土台として見ています。

AgentCore の各機能を業務目線で見る

AgentCore には複数の構成要素があり、少し難しく見えますが、
業務目線で言い換えると分かりやすくなるかと思います！

要素	業務目線で見ると
Runtime	Agent が働く場所
Memory	必要な文脈や過去のやり取りを覚える仕組み
Gateway	社内システムや API を Agent から使えるようにする入口
Identity	誰の権限で動くかを管理する仕組み
Policy	やってよいこと・だめなことを実行前に判断する仕組み
Observability	Agent が何をしたかを後から見えるようにする仕組み
Evaluations	Agent が期待どおり動いているか評価する仕組み

AIM342 でも、AgentCore は Runtime、Memory、Gateway、Identity、Policy、Browser、Code Interpreter、Observability、Evaluations などの複数コンポーネントで構成され、本番運用では「基盤を作る」「高品質に磨く」「継続運用する」の 3 フェーズで考えると整理されています。

最初から大きな Agent を作るのではなく、まず基盤を作る！そして次に評価しながら品質を上げる、最後に監視しながら継続運用する、この順番でやっていく必要があるかと思います

Strands Agents は業務ロジックを書くための選択肢

AIM313 でも、Amazon Nova Act と Strands Agents による Agentic AI の構築が扱われていました。事前紹介でも、生成 AI 活用が質問応答や RAG から、AI が次の行動を判断して Tool を使う Agent へ広がっていること、さらにマルチエージェントの世界が現実になりつつあることが説明されています。

AgentCore が本番運用の基盤だとすると、Strands Agents は

Agent を実装するための SDK
少ないコードで Agent を作るためのものあたりになりますでしょうか...？

重要なのは、Agent の実装を通じて、 ↓のような設計をコードに落とせることが非常に重要かと思います。

どの Tool を使わせるか
Tool の入力をどうチェックするか
危ない操作をどう止めるか
どこで人間に戻すか
実行ログをどう残すか
AgentCore Runtime にどう載せるか

Strands Agents は AgentCore Runtime へのデプロイにも対応しており、 AgentCore Runtime は Strands Agents、LangChain、LangGraph、CrewAI などのフレームワークや、 MCP / A2A などのプロトコル、複数のモデルと連携できると説明されています。 aws-solutions-library-samples/guidance-for-multi-agent ...

開発時は Strands Agents で業務ロジックを作り、本番運用では AgentCore の Runtime、Identity、Gateway、Observability、Evaluations、Policy などと組み合わせる。

この分担が現実的に見えました！

評価は「回答」ではなく「行動」を見る

AIM311 では、生成 AI の評価について扱われていました。 Identify、Evaluate、Optimize の 3 ステップ、ゴールデンデータセット、LLM-as-a-Judge、さらに Agent の振る舞いを評価する手法が紹介されています。

ここで重要なのは、評価対象が「AI の回答」だけではないことです。 AI Agent の場合、最終的な文章だけを見ても不十分です。

途中で何を調べたのか。
どの Tool を使ったのか。
不要な操作をしていないか。
本来止まるべき場面で止まったか。
人間に確認すべき場面で確認したか。

ここまで見る必要があります。

AgentCore Evaluations も、Agent や Tool がタスクをどれだけ適切に実行できるか、エッジケースに対応できるか、出力の信頼性を保てるかを評価する機能として説明されています。

Overview - Amazon Bedrock AgentCore

本番で使う AI Agent は、「それっぽく答えられる」だけでは足りません。期待した手順で動き、危ないときは止まり、必要なときは人間に戻せるか。そこまで含めて評価する必要があると思います。

認証認可は避けて通れない

AI Agent が社内システムや外部サービスを操作するようになると、認証認可は避けて通れません。

SEC353 では、Agent が CRM やメール、SaaS にユーザーの代わりにアクセスする場合、過剰な権限付与、認可プロンプトの繰り返し、認証連携の自前実装が課題になると紹介されています。

これは、かなり現実的な話で、 AI Agent に強い権限を渡しすぎると、誤動作時の影響が大きくなります。一方で、権限を絞りすぎると業務は進められません、必要なのは、業務に必要な範囲だけを渡すことです。

たとえば、問い合わせ対応 Agent であれば、顧客情報の参照は必要かもしれません。しかし、契約変更や返金処理まで自動実行してよいかは別問題です。この線引きをしないまま Agent を業務に入れるのは危険です。

また、CNS315 では、AI Agent 時代でも OAuth2 / OIDC の基礎が重要であり、ユーザーを代理してアクセスする認可コードフローと、マシン間通信で使うクライアントクレデンシャルフローの違いが紹介されています。 MCP経由で API を呼ぶ場合にも、誰のリクエストなのかをどう伝えるかが課題になります。

AI Agent の認証認可は、新しい話に見えますが、土台には従来の API 認可の知識があります。むしろ、これまでの認証認可の理解が、AI Agent 時代にさらに重要になると感じました。

Policy は「実行前に止める」ために必要

AI Agent に「危ないことはしないでください」とプロンプトで書くだけでは弱いです、まず止まりませんし、日常使いのCodex, Claude では hook で危険Bashを止めているか、禁止コマンドを設定しているのではないでしょうか？

もちろんプロンプトも大事ですが、本番業務ではそれだけでは足りません。 Tool を実行する前に、決定的なルールで止める仕組みが必要になります。

たとえば...

参照系の操作だけ許可する
書き込み系の操作は承認後のみ許可する
一定金額以上の処理は必ず人間に戻す
特定部署のデータは特定ロールだけ参照できる
顧客情報を外部 Tool に渡さない

AIM201 でも、Guardrails は応答内容を精査するもの、Policy は Tool 呼び出し時に強制をかけるものとして紹介されていました。業務システムでは、どれだけ優秀な人でも承認フローや権限管理の中で仕事をします、AI Agent も同様です。

社内展開では「全社共通」と「業務特化」を分ける

AIM329 では、社内 AI Agent 展開の勘所が扱われていました。このテーマで重要なのは、すべてを一つの Agent で解決しようとしないことだと思います。

全社共通で使いやすいものには、次のようなものがあります。

社内文書検索
議事録作成
要約
下書き作成
一般的な問い合わせ対応

一方で、業務特化型の Agent は、より慎重に作る必要があります。

経理 Agent
法務 Agent
営業支援 Agent
カスタマーサポート Agent
データ分析 Agent
開発運用 Agent

これらは、扱うデータ、必要な権限、失敗時の影響がまったく違います。そのため、まず全社共通で使える範囲を広げ、リスクの高い業務は個別に設計する。この進め方が現実的だと感じました。

本番運用で見るべきこと

今回の AWS Summit の内容を踏まえ、AI Agent の本番運用では、少なくとも次を決める必要があるのではないかと感じております...！

1. 目的

まず、何の業務を改善したいのかを決めます。

「AI Agent を作りたい」ではなく、「問い合わせ一次対応を短縮したい」「申請チェックの手戻りを減らしたい」「請求書確認を効率化したい」

という形で目的を決める必要があるかと思います。

2. 情報

Agent に何を見せるかを決めます。

社内文書
FAQ
顧客情報
注文履歴
会話履歴
業務ルール

などなど...、必要な情報を整理します。

3. Tool

Agent が使う Tool を決めます。

検索だけさせるのか
チケット更新までさせるのか
メール送信までさせるのか
社内 API を呼ばせるのか
会計システムに登録させるのか

ここが曖昧だと、Agent の行動範囲が広がりすぎます。 Strands で Tool 定義も容易ですのでまずは日本語で列挙が良いかと思います。

4. 権限

Agent が誰の権限で動くのかを決めます。

本人の代理？
Agent 専用の権限？
部署や役職によって参照範囲を変える？

ここを曖昧にすると、セキュリティ事故につながりますので、最初にしっかり決めるべきではないでしょうか。

5. 評価

Agent が正しく動いているかを確認する方法を決めます。

回答が正しいかだけではなく、手順が正しいか、Tool 選択が正しいか、人間に戻すべき場面で戻せたか

を見る必要があります。

6. 運用

最後に、運用中の監視と改善方法を決めます。

コストが増えすぎていないか？
応答が遅くなっていないか？
失敗が増えていないか？
モデルやプロンプトを変えたときに品質が落ちていないか？

ここまで含めて、初めて本番運用と言えそうです。

まずは小さく始める

今回の学びを踏まえると、AI Agent 活用は大きく始めるより、小さく始める方がよさそうです。最初から「全業務を AI Agent 化する」と考えると、たぶん失敗するんじゃないでしょうか！

まずやれそうなことで言いますと...

業務手順がある程度決まっている
参照するデータが整理されている
失敗時の影響が限定的
人間の確認ポイントを置きやすい
効果を測定しやすい

たとえば、社内問い合わせの一次対応、ナレッジ検索、申請内容の事前チェック、議事録要約、チケット分類、請求書と発注情報の照合補助などは、検討しやすい領域です。一方で、送金、契約締結、顧客への最終回答、重要データの削除、対外的な意思決定などは、最初から完全自動化を狙うべきではないと思います。

まずは補助から始め、評価と運用を見ながら、少しずつ任せる範囲を広げる。その進め方が現実的ではないかなーと思います！

最後に

AWS Summit Japan 2026 に参加して、AI Agent は「作る」段階から「本番で安全に運用する」段階へ進んでいると感じました。

AI Agent は、単なるチャットボットではありません。業務データを見て、Tool を使い、業務に作用するシステムコンポーネントになりつつあります。

だからこそ、導入時には「何ができるか」だけでなく、次を考える必要があります。

何をさせないか
どこで止めるか
誰が確認するか
どう評価するか
どう運用するか

Context や Harness の考え方も重要ですが、今回特に感じたのは、AI Agent の Loop をどう設計するかです。

AI Agent が考え、Tool を使い、結果を見て、また次の行動を決める。その流れを安全に回すこと。そして、必要なところで止めること。ここが、本番業務で AI Agent を使う上でかなり重要になりそうです。

以前は、AI が進むとエンジニアの仕事はかなり減るのではないかと思っていました。ただ、今回の AWS Summit に参加して、少し見方が変わりました。実装の一部は AI に寄っていくと思います。一方で、業務、データ、権限、Tool、評価、監視、運用をつなげて、AI Agent が安全に動ける流れを作る仕事は、むしろ増えていきそうです。

エンジニアの仕事がなくなるというより、作る対象が変わっていく。そんなことを感じた AWS Summit Japan 2026 でした。

以上、参加レポートでした。