2026 年 7 月 20 日週、私はサンパウロで中南米各地のテクニカルビルダーと 3 日間過ごす機会に恵まれました。ここでは、深く掘り下げたセッション、ハンズオンワークショップ、お客様やパートナーとの会話が盛りだくさんの地域の技術イベントに参加しました。私が最も感銘を受けたのは、単一のセッションではなく、同じ部屋にいる機会はめったにない技術コミュニティのエネルギーでした。人々はコーヒーを飲みながらアーキテクチャのアイデアを交換し、ホワイトボードに解決策をスケッチし、到着したときよりも長い「試してみたいこと」のリストを手にして帰っていきました。私たちが構築するすべてのツールにおいて、それを取り巻くコミュニティこそがテクノロジーを定着させていることを思い出させてくれます。 このコミュニティの精神は、 7 月 27 日週の最大のインフラストラクチャニュースとうまく結びついています。それは、AWS をビルダーが実際にいる場所の近くに届けることに関するものです。 それでは、7 月 27 日週の AWS ニュースを見ていきましょう… 主なトピック ギリシャのアテネの AWS ローカルゾーン : AWS はギリシャのアテネに新しいローカルゾーンを開設しました。これは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートする EMEA の 2 番目のローカルゾーンです。これにより、ギリシャ国内でデータを保存および処理して、ローカルのデータレジデンシー要件を満たすのに役立ちます。アテネローカルゾーンは、Amazon EC2 (C7i、M7i、および R7i インスタンス)、ワンゾーン低頻度アクセスストレージクラスの Amazon S3、Amazon EBS、および Amazon ECS をサポートしています。 AWS ローカルゾーンは、AWS インフラストラクチャを大勢の人口や業界のハブの近くに配置しています。これにより、リアルタイムゲーム、メディア制作、金融サービスなど、数ミリ秒のレイテンシーを必要とするアプリケーションを、エンドユーザーが実際にいる場所で実行できるようになります。ギリシャのビルダーは、レイテンシーの影響を受けやすいワークロードをローカルで実行すると同時に、低レイテンシーを必要としないサービスのために最も近い AWS リージョンにシームレスに接続できるようになりました。これにより、独自のデータセンターインフラストラクチャを管理しなくても、レイテンシーが最適化されたハイブリッドアプリケーションを柔軟に設計できます。詳細については、 AWS グローバルインフラストラクチャと持続可能性に関するブログ投稿 をご覧ください。 7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS 上の Claude Opus 5 : Anthropic の Claude Opus 5 を使用できます。これは、これまでで最も先進的な Opus モデルであり、多くの分野で Claude Fable 5 のトップクラスのインテリジェンスに匹敵する、Opus レベルの料金体系でご利用いただけます。Amazon Bedrock では、デフォルトでゼロデータ保持 (ZDR) が有効になっている Claude Opus 5 を提供しています。これにより、Claude Fable 5 とは異なり、データガバナンス要件を満たしながら、Opus の最高レベルのインテリジェンスを提供できます。Claude Opus 5 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 詳細なブログ投稿 にアクセスしてください。 .NET 用の AWS Lambda 永続実行 SDK が一般公開されました : カスタムの進捗追跡を実装したり、外部のオーケストレーションサービスを統合したりしなくても、Lambda の永続関数を使用して、回復力のある長時間実行ワークフローを C# で構築できるようになりました。SDKは、支払い処理パイプライン、AI エージェントオーケストレーション、ヒューマンインザループ承認などの複数ステップのアプリケーションに最適です。進行状況を自動的にチェックポイントで確認し、実行を最大 1 年間停止できます。お客様がサーバーレスワークフローを構築している .NET 開発者である場合、これによって手作業で記述していたプラミングの大部分が不要になります。 Amazon Bedrock AgentCore では、トレースとログを 1 つのロググループにまとめることで、統一されたオブザーバビリティを実現できるようになりました : Amazon Bedrock AgentCore は、エージェントのトレースとプロンプトを、エージェントのログと同じ Amazon CloudWatch ロググループに配信するようになりました。以前は、テレメトリは送信先に分散され、トレーススパンは共有ロググループに送られ、プロンプト、入力、出力は別のロググループに送られました。そのため、1 回のエージェント呼び出しをデバッグするには複数の場所を検索する必要がありました。呼び出しを 1 か所でデバッグし、きめ細かなアクセス制御とカスタマーマネージドキー (CMK) 暗号化を個々のエージェントレベルで適用できるようになりました。 Amazon Connect がより自然なエージェント音声体験を提供 : Amazon Connect は、現在、ポルトガル語、スペイン語、フランス語、イタリア語、日本語、韓国語、タイ語を含む 50 以上の言語で、より自然で人間に聞こえるエージェント型音声体験をサポートするようになりました。100 を超える新しい音声オプションと会話の改善により、AI インタラクションがよりスムーズに聞こえるようになりました。Connect のエージェント型セルフサービスにより、AI エージェントは顧客の口調や感情に合わせて、音声やデジタルチャネル全体で理解し、推論し、行動に移すことができます。顧客が実際に話す言語のうち、これまでよりもはるかに多くの言語で、発信者に対して自然に感じられるコンタクトセンター体験を構築できるようになりました。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポートするようになりました : Amazon OpenSearch の検索データやログ分析データを、Amazon SageMaker Unified Studio の他のデータ資産と一緒に直接クエリして分析できるようになりました。この接続により、OpenSearch の運用検索データを Amazon Redshift、Amazon S3、リレーショナルデータベースなどのソースからのデータと、すべて単一の管理された環境内で組み合わせることができます。アプリケーションログをトランザクションデータと組み合わせてインサイトを引き出すなど、分析ワークロードと運用ワークロードを相互に関連付ける必要がある場合に特に役立ちます。 Amazon CloudWatch がコーディングエージェントのインサイトを発表 : Amazon CloudWatch により、エンジニアリングリーダーは AI コーディングツールが組織全体でどのように価値をもたらしているかを把握できるようになりました。コーディングエージェントインサイトは AWS 用の Claude アプリゲートウェイと統合されているため、追加のインストルメンテーションなしで Claude Code からテレメトリを収集できます。また、Codex や GitHub Copilot などのエージェントもサポートしています。チームが AI コーディングの採用を拡大するにつれて、OpenTelemetry で構築されたメトリクスを使用してその投資収益率を測定できるようになりました。カスタムインストルメンテーションは必要ありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: AI エージェントの評価: Strands と AgentCore を使った本番環境ブループリント : Strands Agents と Amazon Bedrock AgentCore を使用して、本番環境に移行する前後に AI エージェントを評価するための実践ガイド。エージェントをプロトタイプから本番環境に移行している場合、この投稿は上記の AgentCore Observability のアップデートに役立ちます。エージェントの品質を直感ではなく体系的に測定する方法を説明しています。 AWS CloudFormation カスタムリソースデプロイのためのマルチリージョンの耐障害性の構築 : 単一リージョンに問題が発生した場合でも、コードとしてのインフラストラクチャのデプロイの信頼性が維持されるように、マルチリージョンの耐障害性を実現するために CloudFormation カスタムリソースを設計する方法を学んでください。 Amazon Simple Email Service (SES) 料金プランのご紹介 : Amazon SES では、E メールの量が増えてもコストを予測できる料金プランが提供されるようになりました。大量に送信する場合、請求が大幅に簡素化されます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits : AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days : コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 7 月 27 日週のニュースは以上です。８ 月 3 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

こんにちは。流通小売・消費財・飲食業界を担当するソリューションアーキテクトチームです。 6 月 25 日（木）、26 日（金）の 2 日間にわたり、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されました。会場には Day 1 に 22,000 名以上、Day 2 に 20,000 名以上、Executive Forum も合わせると延べ 43,000 名以上の方にご来場いただきました。基調講演や数多くの事例セッションとともに、AWS Expo エリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただきました。 AWS Expo エリア内の AWS Industries Zone では、製造、金融、自動車、そして私たちの担当する流通小売・消費財・飲食など、業界別に特化したソリューションをご紹介しました。私たち流通小売・消費財・飲食業界担当チームのブースには、両日ともに終日、途切れることなく多くのお客様に足を運んでいただきました。デモを体験いただいたお客様からの多くのフィードバックを通じて、私たち自身もまた新しいアイデアと気づきを得ることができました。ご来場いただいた皆さま、本当にありがとうございました。 流通小売・消費財・飲食業界向けブースの様子。両日とも終日、多くのお客様にお立ち寄りいただきました 本ブログでは、流通小売・消費財・飲食業界向けブースの展示内容と当日の様子をダイジェストでご紹介します。展示内容に使われている AWS サービスやアーキテクチャの詳細については個別の解説ブログも公開しており、本ブログの中からそれらのブログもご案内しています。（ 事前のご案内ブログはこちら ） AWS 展示ブーステーマ 「AI エージェントが業務の主役になる日」 昨年の Summit では「The Future of Retail」をテーマに、カスタマージャーニーを軸とした店舗体験の “少し先の未来” をご紹介しました。今年、私たちが皆さまにお届けしたのは、その一歩先 — AI エージェントが、業務そのものの主役になっていく世界 です。 生成 AI を「試してみた」というお客様は、この一年で本当に増えました。一方で、実務での大規模な活用にまで踏み込めている企業は、まだ決して多くありません。そのあいだに横たわっているのは、多くの場合「いまの業務プロセスを全部つくり変えなければならないのではないか」という、心理的なブロッカーです。 今年のブースでご提案したのは、その逆の発想です。既存のプロセスはそのままに、まずは業務の “一部” に AI を組み込んでみる。そこから自律エージェント、そして複数のエージェントが連携するマルチエージェントへ少しずつ広げていくことで、やがて業務全体の最適化へたどり着く — この段階的な進化のステップを、実機デモで体感いただきました。 商品をつくり、届け、そして売る。流通小売・消費財・飲食業界のバリューチェーンのそれぞれの現場で、AI エージェントがどのように働き始めているのか。本ブースでは 「商品をつくる」「商品を届ける」「商品を売る・つながる」 の 3 つの切り口で、合計 6 つの展示テーマ（7 デモ）と 2 社のお客様事例展示をお届けしました。それでは、当日の様子を順にご紹介していきます。 商品をつくる — AI と共創する、これからの商品開発 バーチャル AI エキスパート — 専門家ペルソナたちが、あなたのアイデアを形にする CEO 視点、IT Director 視点、店舗マネージャー視点、顧客価値視点 — それぞれ異なる専門性と立場を持つ個性豊かな AI ペルソナたちが「バーチャル専門家チーム」を構成し、来場者が音声で伝えたビジネステーマについて、並列で Deep Research とディスカッションを重ねてベストなアイデアを提案するデモです。各ペルソナが独立に調査した結果を持ち寄り、モデレーターが議論を取りまとめ、レッドチームが厳しい指摘と改善案を入れる — その過程が縦型ホログラムディスプレイと 3D アバター、カード型 UI でリアルタイムに可視化され、エグゼクティブサマリーからアーキテクチャ案・コスト試算、さらには PoC 用サンプルアプリケーションまでが「数分の対話」で立ち上がります。 縦型ホログラムディスプレイに映る AI ペルソナたちの議論。可視化されるプロセスに多くの方が足を止めました 最も反響が大きかったのは「AI が議論する」という体験そのものでした。単なる Q&A ではなく、複数の視点が交わり「考えが深まっていくプロセス」が目の前で可視化される様子に、来場者からは「すごい壁打ちができるということですね」「社長に見せたら、やるって言いそう」といった声をいただきました。また、実在人物のペルソナ（上司や取引先など）を再現して壁打ち相手にしたい、という声も複数いただいています。マルチエージェントという概念が昨年より自然に受け入れられていることも印象的でした。 技術的には Amazon Bedrock AgentCore Runtime 上で Amazon Nova 2 Sonic による音声対話、 Strands Agents によるマルチエージェント、A2A / AG-UI プロトコルによるエージェント間通信と UI 可視化を組み合わせています。開発の裏側は以下のブログで詳しく解説しています。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート AI で加速する製品イノベーション — マルチエージェントで実現する製品開発 架空の鞄メーカー・アパレルメーカーを題材に、リサーチ・デザイン・製造の各工程を担う複数の AI エージェントが連携し、市場調査からターゲットの特定、デザイン生成、仮想ペルソナによる検証、そして製造コスト・収益予測まで — 通常であれば半年から 1 年を要する一連のプロセスを、わずか数分で駆け抜けるデモです。各フェーズで AI が多様な選択肢を提示し、戦略的な意思決定は人間が下す「Human-in-the-Loop」の考え方によって、スピードと品質を両立させる新しい商品開発の姿をご覧いただきました。 数分で製品デザイン案が生成される様子を体験いただきました 会場では、多くの来場者が数分のうちにオリジナルの製品デザインが生み出される様子をご覧になりました。製品開発やマーケティングに携わる方々からは「市場調査からデザイン、原価試算までを短時間で回せる」ことへの手応えの声が、経営層・事業責任者の方からは「専任チームがなくてもイノベーションを実行できる体制を作れる」という受け止めが、そして少人数のスタートアップの方からは「大手と同等の製品開発力を持てる、イノベーションの民主化だ」という反応もいただきました。自社の経営戦略資料や販売実績を Amazon Bedrock Knowledge Bases に連携することで「一般解」ではなく「わが社の解」が得られる、という点にも多くの関心が寄せられました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — AI で加速する製品イノベーション 〜マルチエージェントで実現する製品開発 商品を届ける — 止めない物流とサプライチェーンのために AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決 台風による広域配送停止、ドライバー不足、SNS でのバイラル化による需要急増、原材料の調達難。「想定外」が起きたそのとき、AI エージェントが外乱を検知し、影響を分析し、代替案を探索・提示し、人間が承認したうえで実行と通知までを一気通貫で行う — この次世代のサプライチェーン管理オペレーションをライブで実演しました。小売シナリオ（店舗の在庫不足に対する最適な振替ルートの提案）と消費財シナリオ（原材料供給停止時の代替サプライヤー探索）の 2 パターンをご覧いただき、Amazon Bedrock AgentCore と Strands Agents SDK の Interrupt 機能による Human-in-the-Loop の協調モデルがリアルな課題シナリオの中でどう機能するのかをお見せしました。 AI エージェントの思考プロセスと Human-in-the-Loop の承認フローをライブで実演 ブースを訪れたお客様のほぼ全員が、危機管理や BCP 訓練を「やりたいがリソースや手段がなくてできていない」とおっしゃっていたのが印象的でした。大雪や台風などで実際に困っている企業様からは「これまで担当者が各所に何本も電話をかけて対応していた。AI が初動を担ってくれるだけでもありがたい」という声をいただきました。エージェントの思考プロセスの可視化により「具体的なイメージが湧いた」「エージェントの処理を見て初めて理解できた」というフィードバックも多く、1 回あたり数百円程度というシミュレーションコストの低さにも「想像より安い」と好意的な反応をいただきました。既存システムを置き換えることなく、AI による分析の仕組みを「外付け」し、シミュレーション（レベル 1）から段階的に自動化レベルを上げていけるアプローチに、多くの共感が集まりました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 物流異常を Amazon Quick が自動解決 — 配送在庫の異常検知〜問合せまで一気通貫 基幹システム、受発注、在庫、配送 — 複数のシステムに分散しがちな物流のデータを Amazon Quick に統合し、業務の自動化と可視化を実現するデモです。Quick Automate が業務システムを横断的に監視して異常を自律的に検知し、Microsoft Teams へリアルタイムに通知。Quick Sight のダッシュボードで滞留の状況を一目で把握し、「ABC 運輸の大阪→福岡の遅延率を週別で出して」とチャットで聞けばその場でグラフが生成されます。物流専門家の Chat Agent が構造化データと SharePoint 上の報告書・SLA 合意書などの非構造化データをセキュアに横断して根本原因を深掘りし、最後は業者へのメール問い合わせまで自動生成・送信 — 「発見」から「対応」までが途切れなくつながる体験をご覧いただきました。 Quick Sight のダッシュボードで配送の滞留状況をご覧いただきました 従来なら報告書を探し、データを手動で突き合わせ、ベテランに聞いて半日かかっていた原因究明作業が、チャットで聞くだけで数分で完了する。データの散在・発見の遅れ・属人化という物流現場の普遍的な課題に対し、可視化・AI 分析・自動化・外部連携をひとつのサービス上で統合的に提供する Amazon Quick の姿に、多くのお客様から関心をお寄せいただきました。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫 商品を売る・つながる — コマースと店舗の、新しいかたち Future of Agentic Commerce — AWS で実現する新しい E-Commerce の形 いま US で吹き荒れている Agentic Commerce の旋風。AI プラットフォーマー側の Incoming Agent から EC サイトに流入し、自社 EC サイト上の Onsite Agent による接客を経て購入に至るまで、そして裏側で動く EC バックエンド・バックオフィスの仕組みまでを、一つの Demo システムとして統合してご覧いただきました。UCP、AP2、ECP、MCP Apps といった 2026 年に入って急速に整備が進むコマースプロトコル群への対応、エージェントへの決済権限の委任、さらには友達同士の AI エージェントが購入前に相談し合うコンセプトデモまで、6 つのストーリーで「来たる Agentic Commerce 時代」の実装イメージを具体的にお見せしました。 Incoming Agent から自社 EC への流入・購入までを一つの Demo システムで体験 印象的だったのは、「AI エージェントに決済まで任せたい」という声はそれほど多くなく、むしろ「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」 — まず「見つけてもらうこと」への関心の高さでした。また「Agentic Commerce という名前しか知らず、何のことかよくわからなかったが、このブースを見て完全に理解できた。自分たちが何を検討すればいいかが分かった」と言って帰られたお客様もいらっしゃいました。実際に触れられる実装例がまだ少ない日本市場において、ブースが一つの「アンサー」を示せたことは大きな成果だったと感じています。 詳細解説ブログ： 【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース Eyes On, Voice On — スマートグラスと音声 AI が融合する、フード・現場業務の未来形 実店舗やキッチンなど「手が使えない現場」の業務を、音声 AI エージェントとウェアラブルデバイスで支援する 2 つのライブデモをお届けしました。 スマートグラスでの音声問い合わせ、音声でキッチン工程を進める体験デモ 一つ目は スマートグラスによる店舗業務支援 です。店員がスマートグラスを装着し、「コーヒーはどこですか」「今日のセール品を教えて」と声で聞くだけで、 Amazon Nova 2 Sonic （Speech-to-Speech 統合モデル）と Amazon Bedrock AgentCore Gateway 経由の MCP Tools が連携して棚位置・在庫・セール情報を即座に音声とグラス表示で案内します。自店舗に在庫がなければ他店舗や EC サイトの在庫まで一声で案内し、タスク管理や英語対応、飲食店での予約確認・リマインド通知まで、スーパー・アパレル・飲食の 8 つのシナリオを体験いただきました。GPS やビーコンは不要、商品マスターと棚位置マッピングデータだけで実現できる導入ハードルの低さも、来場者への大きな訴求ポイントとなりました。併設した Agent Monitor で AI の思考プロセス（AG-UI）がリアルタイムに流れる様子は、このデモ最大の「おおっ」ポイントとして多くの注目を集めました。 詳細解説ブログ： スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援 二つ目は キッチン音声レシピナビ です。衛生手袋を着用したまま両手が塞がるセントラルキッチンの調理現場で、「次へ」「戻る」の音声だけでレシピ工程を進め、工程完了時には使用食材の在庫を自動減算。「玉ねぎがない」と伝えれば AI が代替食材を提案し、原材料チェックでは「玉ねぎ/タマネギ/オニオン」といった表記ゆれも吸収します。騒音の多い調理環境でも高精度な日本語音声認識を実現するアドバンスト・メディア社の AmiVoice と、 Amazon Bedrock AgentCore Runtime + Strands Agents による AI エージェントの組み合わせで、レシピ確認・在庫記録・HACCP 対応記録といった現場のデータ入力障壁を解消するアーキテクチャをご紹介しました。 「手が塞がっている環境でのデータ入力障壁」は食品製造に限らず、物流のピッキング、医療の手術室、製造の組立ラインなど多くの業界に共通する課題であり、幅広い業種のお客様から自社現場への適用イメージについてご相談をいただきました。 詳細解説ブログ： 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション お客様事例展示 — すでに現場で動いている、生成 AI コンセプトのご紹介だけではありません。展示エリアには、生成 AI を実際の現場で活用されているお客様 2 社の事例展示も併設しました。会期中はお客様ご自身による解説とその場での Q&A も行われ、実装の裏側や運用してみて初めて見えてきた気づきなど、現場の生の声を直接お聞きいただける貴重な機会となり、両日とも大変盛況となりました。 ユナイテッドアローズ様・カインズ様の事例展示。お客様ご自身による解説に質問が絶えませんでした 株式会社ユナイテッドアローズ 「Amazon Bedrock で実現 対話で深まる日報 AI」 日報につきものの「書く負担」と「うまく伝わらない」という相反する 2 つの悩みに対し、 Amazon Bedrock を活用した対話型 AI が店舗スタッフの思考整理を支援し、日報を自動で要約する PoC をご紹介いただきました。AI が深掘りの質問を投げかけることで報告内容の粒度と一貫性が高まり、本部の状況把握や店舗の行動改善にもつながる — 現場と本部、その双方の業務品質を高める生成 AI の活用事例に、多くの来場者が熱心に耳を傾け、質問が絶えない展示となりました。 本事例の元となっている AWS のサンプルアセット「SMART（Store Manager Agent for Retail Tech）」は GitHub で公開されており、どなたでもお試しいただけます。仕組みの詳細とユナイテッドアローズ様での取り組みは、以下のブログでご紹介しています。 詳細解説ブログ： 店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み 株式会社カインズ 「AI で進化する顧客体験 Amazon Bedrock 活用事例」 ホームセンター大手のカインズ様には、 Amazon Bedrock の画像生成 AI を活用した店頭サイネージ「CAINZ Fitting Room」による、インテリアの疑似 “試着” 体験の取り組みをご紹介いただきました。サイネージ上に表示された部屋の写真の中の家具・ラグ・カーテンなどをカインズ製品の画像に AI で置き換えることで、購入前に「自分の部屋に置いたらどう見えるか」をイメージしやすくし、店頭での訴求力向上と売上・客単価の引き上げを狙う取り組みです。2026 年 4 月ごろから埼玉県の吉川美南店など 3 店舗で試験運用を開始されています。 「お客様が実際に欲しいのは、自分の部屋にあるところを見ること」というご担当者の言葉のとおり、将来的には顧客自身の部屋写真を使った体験への進化も構想されており、画像生成 AI を “購買体験そのもの” に組み込む小売業ならではの活用事例に、多くのお客様にお立ち寄りいただきました。 おわりに — ご来場ありがとうございました 「まだ早い」から「もう始めている」へ。幕張メッセの AWS Industries Zone での 2 日間を通じて強く感じたのは、流通小売・消費財・飲食業界の現場で、AI エージェントが業務の主役になっていく日が、すぐそこまで来ているということです。 昨年と比べ、マルチエージェントという概念が特別な説明なしに受け入れられるようになったこと。「AI エージェントで何ができるのか」という問いが、「自社のどの業務から始めるか」という問いへと変わりつつあること。そして、エージェントの思考プロセスの可視化や Human-in-the-Loop といった仕組みが、AI 活用への心理的なハードルを確かに下げていること。これらは、ブースで数多くのお客様と対話させていただいたからこそ得られた実感です。 今年のデモでお伝えしたかったのは、新しい技術を次々と取り込まなければならない、ということではありません。AWS のサービスを組み合わせれば、皆さまの中にすでに蓄積されてきた知識と経験を起点に、業務の “一部” から無理なく始めていける — そんなアイデアばかりをご用意しました。ご参加いただけなかった皆さまも、「試してみたい！」と思われた方は、ぜひ AWS の担当者までお気軽にご相談ください。 今後も、流通小売・消費財・飲食業界の皆さまに向けたイベントの企画と情報発信を継続していきます。それではまた、来年の Summit でお会いしましょう！ 関連ブログ（各デモの詳細解説） 【開催報告】AWS Summit Japan 2026 — 「AI ペルソナ達がビジネス課題解決を加速する」バーチャル AI エキスパート 【開催報告】AWS Summit Japan 2026 — AI で加速する製品イノベーション 〜マルチエージェントで実現する製品開発 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫 【開催報告】AWS Summit Japan 2026 〜 Future of Agentic Commerce ブース スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 参考情報 AWS ブログ “流通小売” カテゴリー AWS ブログ “消費財” カテゴリー AWS 消費財・流通・小売業向けソリューション 紹介ページ 事前のご案内ブログ：AWS Summit Japan 2026 〜 流通小売・消費財・飲食業界向けブースのご案内 昨年の開催報告：【開催報告】AWS Summit Japan 2025 〜 流通小売消費財業界ブース 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

2026 年 06 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS FinOps Agent (preview) AWS FinOps Agent は、クラウド環境全体に対して、コストを継続的にモニタリング、コスト異常を調査、コスト最適化機会の発見を行うフロンティアエージェントです。自然言語でコストに関して質問ができ、スケジューリングされたレポート作成やイベントトリガーによるコスト異常分析などが実行可能です。 資料（ PDF ）  対象者 AWS FinOps Agent の概要・ユースケースを知りたい方 AWS FinOps Agent の利用方法を知りたい方 効率的に FinOps を推進したい方 本 BlackBelt で学習できること AWS FinOps Agent の概要・ユースケースについて学んでいただけます AWS FinOps Agent の設定方法について学んでいただけます スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon RDS for Db2 へのマイグレーション戦略 本セミナーでは、Amazon RDS for Db2 へのマイグレーション戦略についてご紹介いたします。 マイグレーション戦略の重要性や、実際にご利用いただける機能やツールをご紹介していきます。 また、マイグレーションを成功に導くためのポイントについてもご案内いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セミナーでは、以下のような方を対象としています。 オンプレミス環境や Amazon Elastic Compute Cloud (Amazon EC2) 上の IBM Db2 から Amazon RDS for Db2 (RDS for Db2) へ移行を検討されている方 今後、RDS for Db2 のご利用をご検討されている方 本 BlackBelt で学習できること マイグレーション戦略の重要性 具体的なマイグレーション方法 マイグレーション成功のポイント スピーカー 松原 睦美 クラウドサポートエンジニア Amazon Bedrock AgentCore runtime Dive Deep Amazon Bedrcok AgentCore runtime は、AI エージェント実行のためのマネージドなホスティング基盤サービスとなっており、完全なセッション分離や認証管理、長時間実行などの便利な機能を持っております。 本セミナーでは Amazon Bedrock AgentCore runtime の基本および AgentCore runtime の各種機能、サンプルコード、お問い合わせでよくあるポイントについて解説しています。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから Amazon Bedrock AgentCore のご利用を検討している方 Amazon Bedrock AgentCore runtime の概要を把握されたい方 すでにエージェントのコードを持っており、AWS へのデプロイを検討している方 本 BlackBelt で学習できること Amazon Bedrock AgentCore runtime の基本および AgentCore runtime の各種機能、サンプルコード、お問い合わせでよくあるポイント スピーカー 花澤 周平 Cloud Support Engineer AWS Direct Connect 詳細編 〜オンプレミスとの冗長化接続〜 AWS Direct Connect を利用したオンプレミスと AWS 間の冗長化接続について解説します。要件に応じた冗長構成パターン、BGP によるトラフィックコントロール、AWS Site-to-Site VPN を用いたバックアップ経路、マルチリージョン構成、障害テスト手法、Amazon CloudWatch によるモニタリングまで、信頼性の高いハイブリッド接続設計に必要な知識を体系的にご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者 AWS とオンプレミスのネットワーク設計を担当している方 AWS とオンプレミス間の冗長化設計について学びたい方 本 BlackBelt で学習できること AWS Direct Connect の冗長化構成のパターン AWS Direct Connect の障害テスト方法 AWS Direct Connect の CloudWatch モニタリング方法 スピーカー 齋藤 優弥 ソリューションアーキテクト Amazon GuardDuty Malware Protection for S3 Amazon GuardDuty Malware Protection for S3 は、S3 バケットにアップロードされたオブジェクトをスキャンし、マルウェアを検出する機能です。本セミナーでは、Amazon GuardDuty Malware Protection for S3 として、機能の概要、開始方法、また、本機能を用いた調査方法をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 S3 バケット内のマルウェア検出をご検討中の方 Amazon GuardDuty Malware Protection for S3 の機能や開始方法を知りたい方 本 BlackBelt で学習できること Amazon GuardDuty Malware Protection for S3 の機能や仕組みの理解 Amazon GuardDuty Malware Protection for S3 の開始方法について Amazon GuardDuty Malware Protection for S3 を使用した調査の流れについて スピーカー 岩垣 侑 クラウドサポートエンジニア AWS Network Firewall AWS Network Firewall の最新仕様を網羅的に解説する Black Belt セッションです。サービス概要から Firewall ポリシー設計、TLS インスペクション、主要アーキテクチャパターン（Egress/Ingress/East-West/ 複合構成）、モニタリング、クォータ、料金体系、コスト最適化まで幅広くカバーしています。 さらに 2025 年にリリースされた Transit Gateway ネイティブ統合や、プレビュー中の AWS Network Firewall Proxy についても紹介しており、新規導入から既存環境の設計見直しまで幅広くご活用いただける内容です。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セッションは、これから AWS を利用予定でネットワークやセキュリティを担当される方、および既に AWS 環境のネットワーク・セキュリティの設計や運用を担当されている方を対象としています。 VPC、サブネット、ルートテーブルなど AWS ネットワーキングの基本概念を理解されていることを前提としており、 AWS Network Firewall の新規導入を検討されている方から、既存環境の設計見直しを行いたい方まで幅広くご活用いただける内容です。 本 BlackBelt で学習できること AWS Network Firewall の基本的な仕組みから、Firewall ポリシー・ルールグループの設計方針、TLS インスペクションの考慮点まで体系的に学ぶことができます。 また、Egress/Ingress/East-West/ 複合構成といった主要アーキテクチャパターンや、マルチ AZ ・対称ルーティングの設計ポイントを理解できます。 さらに、モニタリング手法、クォータ、料金体系とコスト最適化の考え方に加え、Transit Gateway ネイティブ統合や Network Firewall Proxy といった最新機能についても学習できます。 スピーカー 田中 優多 ソリューションアーキテクト AWS CloudHSM 基礎編 AWS CloudHSM は、FIPS 140-3 Level 3 に準拠したシングルテナントの汎用 HSM をクラウドで提供するサービスです。お客様のセキュリティやコンプライアンス要件への対応に活用いただけます。本セッションでは、AWS における鍵管理サービスの選び方、CloudHSM の基本概念やアーキテクチャ、クラスター構成のベストプラクティス、およびセットアップ手順についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 HSM を使用する要件があり、AWS CloudHSM の利用を検討している方 オンプレミスなど既存の HSM からクラウドへの移行を検討している方 AWS CloudHSM を使用中で、概念やベストプラクティスを再確認したい方 本 BlackBelt で学習できること AWS KMS と AWS CloudHSM の使い分けや、AWS CloudHSM が必要となる要件を理解できます クラスター構成、ユーザータイプ、鍵の生成・インポート・エクスポート、鍵の属性など基本概念を習得できます Multi-AZ 配置やバックアップ活用など、可用性・耐久性のベストプラクティスを学べます クラスターの作成から初期化・アクティブ化までのセットアップ手順を把握できます スピーカー 服部 創 クラウドサポートエンジニア AWS CloudHSM 実践編 AWS CloudHSM は、FIPS 140-3 Level 3 に準拠したシングルテナントの汎用 HSM をクラウドで提供するサービスです。本セッションでは、CloudHSM を用いたコード署名のユースケースを題材に、実装上のベストプラクティスやパフォーマンスの最適化手法、よくある質問とトラブルシューティングについて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudHSM を用いたコード署名の実装方法を知りたい方 AWS CloudHSM を利用するアプリケーションの可用性やパフォーマンスを高めたい方 AWS CloudHSM の運用で発生しやすい問題とその対処法を知りたい方 本 BlackBelt で学習できること CloudHSM を使用したコード署名の具体的な流れや操作を確認できます リトライ実装、キーオブジェクトのキャッシュなど可用性のベストプラクティスやパフォーマンス最適化の手法を学べます HSM 台数の考え方、メンテナンス時の影響、キー耐久性チェックエラーなどよくある質問への回答を確認できます 接続エラーやパフォーマンス問題のトラブルシューティング手法を学べます スピーカー 沼田 裕太郎 クラウドサポートエンジニア

本記事は 2026 年 4 月 19 日 に公開された「 EngineLab AI: Production-ready AI for studios and creators on AWS 」を翻訳したものです。 スタジオは今、重大なジレンマに直面しています。AI ツールは制作ワークフローの加速を約束する一方で、導入にあたってはセキュリティ、知的財産 (IP) 保護、制作の安定性に関する現実的な懸念と向き合わなければなりません。本記事では、このトレードオフを解消するソリューションを紹介します。 ComfyUI のような AI ツールを活用すると、AI コンテンツ生成向けのオープンソースなノードベースのインターフェースを通じて、モデル、処理ツール、クリエイティブな操作を組み合わせ、本番グレードのワークフローとして複雑な AI 機能を視覚的に設計・制御できます。しかし、制作ワークフローの加速や新たな効率化をもたらす新興技術にありがちなように、リスクも伴います。急速に進化する AI の世界では、標準化、パイプライン統合、アプリケーションの安定性といった課題が生じます。セキュリティ面の懸念はさらに複雑です。使用するモデルの出所を把握して法的要件に対応しつつ、AI ワークフローを流れる IP を厳格なセキュリティ基準に従って保護する必要があるからです。モデルや関連アーティファクトを適切に審査・承認しなければ、未承認の、場合によっては悪意あるツールやコードが作業環境に持ち込まれるリスクがあります。 これまでクリエイターは、AI を本番環境に導入するにあたって、こうしたメリットとリスクのバランスを取ることを余儀なくされてきました。 AWS のメディア・エンターテインメント専門パートナーである EngineLab は、 EngineLab AI というマネージドデプロイメントプラットフォームを提供開始しました。AWS インフラストラクチャ上に構築され、ComfyUI などの AI アプリを安定した、セキュアで本番対応のツールセットとしてパッケージ化しています。メディア・エンターテインメント業界に特化して設計されており、ワークフローの特性を理解したうえで、ワークフローを高度に構築するユーザーから定型プロセスを活用したい一般ユーザーまで、チームのすべてのアーティストが強力な AI 機能を使えるようにします。 「スタジオからは、AI を本番環境で使いたいが、現状の不安定さとリスクは受け入れられないという声を聞いています。私たちは、そのハードルを取り除くプラットフォームを構築しています。業界が求めるセキュリティとコントロールを備えた形で、AI ツールをスタジオのワークフローに組み込んでいきます。」— Sam Reid、EngineLab 共同創業者 兼 CEO 本記事では、EngineLab AI でこれらの課題を解決する方法を紹介します。具体的には、完全なデータ主権を確保するために AWS アカウントへ直接デプロイする方法、最適な可用性とコストを実現するために AWS が提供するグローバル GPU リソースを活用する方法、そして IP を保護しながらワークフローに必要なクリエイティブな柔軟性を損なわないセキュリティ制御を統合する方法を説明します。 安定したスケーラブルな AI ワークフローの実現 スタジオにとって、高性能な GPU ハードウェアの調達はますます困難かつ高コストになっています。部品不足、価格上昇、オンプレミスインフラの維持管理にかかる負担により、AI ワークロードが必要とする GPU 容量を構築・維持することが難しくなっています。ハードウェアを調達できたとしても、多様なプロジェクトやチームにわたって安定的かつ効率的に割り当てるという課題が残ります。 ComfyUI の Web ベースアーキテクチャは、従来のリモートデスクトップソリューションに対して大きな優位性を持ちます。一般的なクラウドワークステーションは Virtual Desktop Infrastructure セッションを使用し、キーボード、マウス、Wacom タブレットなどの入力操作を含むデスクトップ画面をリモートからローカルクライアントにストリーミングします。一方、ComfyUI はローカルの Web ブラウザ上で動作し、処理負荷の高い演算はサーバー側で実行されます。ユーザーインターフェースはレイテンシーの影響を受けないため、重要なアーキテクチャ上の優位性が生まれます。つまり、レイテンシーを気にせずコンピューティングリソースをリモートでプロビジョニングできるのです。 EngineLab AI はこの柔軟性を活かし、 AWS グローバルインフラストラクチャ を動的に活用します。利用可能な Amazon Elastic Compute Cloud (Amazon EC2) 容量 (コンピューティング集約型ワークロード向けにオンデマンドの GPU インスタンスを提供する AWS のスケーラブルな仮想サーバーサービス) を持つ AWS リージョン (地理的に分離された AWS データセンターのクラスター) を活用します。これにより EngineLab AI は、 GPU 搭載の Amazon EC2 インスタンスタイプ のグローバルプールにアクセスできます。Blackwell、Ada Lovelace、Ampere などの NVIDIA GPU アーキテクチャを幅広くサポートし、vCPU 数やメモリ構成も多様なため、複数のリージョンにわたって可用性を高め、固定のローカルハードウェアをめぐるリソースの取り合いを減らせます。Amazon EC2 インスタンスを活用することで、AI ワークフローの固定費を削減し、必要なときに必要なだけ GPU リソースにオンデマンドでアクセスできます。 また、現在のタスクに合わせてコンピューティングリソースを最適化できます。クラウドインフラストラクチャが各ジョブに適切なリソースを動的に割り当てられるなら、すべてのアーティストがデスクの下に高性能グラフィックカードを置く必要はありません。GPU リソースを複数ユーザーで分割することでコストをさらに削減でき、パフォーマンスを犠牲にすることなく、オンプレミスハードウェアの固定費や運用負担なしに、大規模な GPU コンピューティングへの安定したアクセスを実現します。 EngineLab AI: スタジオとクリエイター向けマネージドプラットフォーム EngineLab は AWS グローバルインフラストラクチャを基盤に、メディア・エンターテインメント向けに一から設計されたマネージドプラットフォームを開発しました。AI ツールを本番環境に導入する際にスタジオが直面する固有の課題に対応しています。 図 1 に示すように、プロジェクト管理インターフェースではワークフローを一元的に把握できます。管理者はここから、アクティブなワークフローの確認、リソース使用状況の監視、アーティストのアクセス管理を行えます。 図 1: EngineLab AI のプロジェクト管理インターフェース。管理者がワークフローを追跡し、リソースを監視し、アーティストのアクセスを管理する様子を示しています 複雑な操作なしに即座にセッションを開始 AI ツールを使うためにクラウドインフラストラクチャの知識は不要です。EngineLab AI では、アプリを選択して起動するだけで AI アプリを使い始められます。適切なコンピューティングのプロビジョニング、環境の読み込み、安定したセッションの提供まで、すべてが自動で処理されます。セットアップも、トラブルシューティングも、待ち時間も不要です。スタジオはプロジェクト単位で作業を整理し、アーティストは必要なアプリをその中で起動するだけです。締め切りのある作業では、セッションが起動しなかったり途中で止まったりすることは許されません。一貫性と信頼性のある操作性が重要です。 アーティスト UI: すべてのアーティストが使える高度なワークフロー どのスタジオにも、複雑なノードグラフを使って高度なワークフローを構築する ComfyUI のエキスパート (技術的なパワーユーザー) がいます。しかし、大規模な運用では、アーティストは自分がエキスパートになることなく、そうしたワークフローの恩恵を受けたいと考えるのが一般的です。Artist UI は、入力・プロンプト・出力といった基本的なエンドポイントを提供することで、このギャップを埋めます。アーティストは画像をアップロードし、求めるものを言葉で伝えるだけで結果を得られます。ノードグラフを操作することなく、裏側でエキスパートのワークフローが動いているのです。 これはスタジオにとって重要な課題、すなわち IP の保護も解決します。カスタムワークフローは実質的な競争優位性を持つ資産であり、ワークフローとユーザーの間に何も介在しなければ、フリーランサーが次の仕事先にそれを持ち出すことを防ぐ手段がありません。Artist UI は境界として機能し、スタジオ全体がその機能を利用できる一方で、内部のワークフローが外部に露出することはありません。 データ主権: セキュリティの確保 本ソリューションはお客様自身の AWS アカウントおよび環境にのみデプロイされるため、包括的な制御とデータ主権が確保されます。顧客データがトレーニングに使用されることはなく、スタジオが制作したものはそのスタジオのものとして扱われます。その利用方法について曖昧さは一切ありません。多くのプラットフォームがデータの取り扱いについて意図的に曖昧な表現を用いる中、EngineLab AI は意図的に明確な姿勢を取っています。またこのアプローチは、コミュニティが開発した AI ワークフローを実行する際に生じるセキュリティリスク、特に不正かつ悪意のあるコードインジェクションへの対策も含んでいます。厳格なデータ要件を持つ主要クライアントと取引するスタジオにとって、これは本番環境に不可欠な要素です。 モデルトレーニング: セキュアな環境と完全な制御 プラットフォームにはトレーニングアプリが含まれており、スタジオは独自のコンテンツを取り込んで、ファインチューニング済みの基盤モデルや、特定のパラメーターのみを変更する Low-Rank Adaptation (LoRA) をトレーニングできます。LoRA はスタイルのカスタマイズにおいて、より高速かつコスト効率に優れています。トレーニングはプラットフォーム環境内で実行されるため、トレーニングデータがプライベートアカウントの外に出ることはありません。トレーニング完了後、カスタムモデルは ComfyUI ワークフローから直接利用可能になり、モデルとその作成に使用したデータの両方をスタジオが完全に管理します。これは、カスタム AI モデルの能力を活用しながらも、独自データが他の場所でのモデルトレーニングや競合他社への利益供与に使われるリスクを避けたいスタジオの重要なニーズに応えるものです。 完全な制御: アクセス管理とプロベナンス 管理者は最小権限モデルによってプラットフォームをきめ細かく制御できます。ユーザーとリソースには各タスクの実行に必要な権限のみが付与され、エキスパートと管理者はモデルのアップロードと承認が可能な一方、その他のユーザーのアクセスは制限されます。ベンダー固有の承認にも対応しており、特定のプロジェクトでは承認済みモデルのみが使用されます。これは、厳格なコンプライアンス要件を持つクライアントと取引するスタジオにとって不可欠な要件です。包括的な監査証跡によってプロジェクトごとのモデル使用状況を追跡し、クライアントへの報告やコンプライアンス検証に活用できます。また、プロベナンス追跡により、モデルの出所と組織全体での使用状況を正確に把握できます。 図 2 の AI Model Library インターフェイスは、モデルと LoRA の分類・承認・管理を一元的に行うビューを提供します。 図 2: EngineLab AI の AI Model Library 管理ページのスクリーンショット パイプライン統合: スタジオワークフロー全体でのコンピューティング EngineLab は、パイプラインに関する深い専門知識とハイエンドなクリエイティブワークフローにおける豊富な経験を持つチームをプラットフォームに結集しています。アーティストの時間が最も重要であるという認識のもと、チームは ComfyUI に関連する GPU および CPU コンピューティングを既存のレンダーファームワークフローに直接統合する取り組みを進めています。これには、ワークフローの需要に応じてコンピューティングリソースを自動的にスケールする完全マネージド型レンダーファームサービス AWS Deadline Cloud を活用しています。この統合により、ComfyUI フロントエンドは軽量なマシンで動作しながら、重い GPU タスクをレンダーファームにオフロードでき、インターフェイスと処理能力を切り離すことが可能になります。これは、ツールを本番環境に統合するための知見を持つ EngineLab が、その複雑さを引き受けることでスタジオの負担を軽減する、自然な進化の形です。 「私たちは EngineLab がプラットフォームを開発する過程でパートナーシップを築いてきました。社内にはすでに強力な ComfyUI の専門知識がありますが、スタジオ全体にそれをスケールできる、管理されたセキュアな環境、そしてクライアント業務に必要な制御とガバナンスを備えた環境こそ、私たちが求めていたものです。」– Sean Costelloe、マネージング・ディレクター、Selected Works まとめ EngineLab AI は ComfyUI を実験的なツールから本番対応のプラットフォームへと進化させ、スタジオが AI ツールを導入する際に直面する重要な課題に対応します。スタジオの AWS アカウントに直接デプロイすることで、包括的なデータ主権とセキュリティを確保しながら、AWS が提供するグローバルな GPU リソースを活用して最適な可用性と価格を実現します。スタジオは従来のアプローチに伴うリスクやコストなしに、本番グレードの AI 機能を手に入れられます。安定してセキュアな AI 生成へのアクセス、クライアント業務に必要な制御、そして使い慣れたワークフローへの統合が実現します。 AWS インフラストラクチャの詳細 EngineLab AI は、コンピューティング集約型のクリエイティブワークロード向けに設計された実績ある AWS サービス上に構築されています。 Amazon EC2 – AI およびレンダリングワークロード向け GPU インスタンスを備えたスケーラブルな仮想サーバー AWS Deadline Cloud – コンピューティングリソースのスケーリングに対応したマネージドレンダースケジューリングサービス 次のステップ AWS およびクリエイティブワークフローへのクラウドインフラストラクチャ活用の開始方法については、AWS アカウントチームにお問い合わせいただくか、 AWS for Media & Entertainment をご覧ください。 EngineLab AI にアクセスして、AWS 上でセキュアかつスケーラブルな AI ワークフローをスタジオで活用する方法をご確認ください。 Andy Hayes Andy Hayesは、AWSのシニア・ビジュアル・コンピューティング・ソリューション・アーキテクトです。VFX（視覚効果）とアニメーションの分野で20年にわたる経験を持ち、芸術・科学・技術の融合によって魅力的な映像を生み出すことに情熱を注いでいます。 Sam Reid SamはEngineLabのCEOであり、世界初となる完全クラウドネイティブなクリエイティブスタジオの立ち上げを主導しました。Untold StudiosではCTOとしてインフラをゼロから構築し、ロンドン、ロサンゼルス、ムンバイに拠点を置く500名以上のクリエイターを支える体制を整えました。現在は、テクノロジーを通じてクリエイティブなインパクトを生み出すことに注力し、EngineLabのビジョンと成長を牽引しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 6 月 30 日 に公開された「 How Outpost VFX Uses AWS to Accelerate AI Model Training for Visual Effects 」を翻訳したものです。 Outpost VFX の Tim Chauncey と Dheeraj Bhadani との共同執筆です。 ビジュアルエフェクト (VFX) 向けの AI モデルトレーニングには数週間を要することがあり、制作スケジュールのボトルネックになりがちです。英国、カナダ、インドにスタジオを構え、高品質な映画やエピソードコンテンツを手がける Outpost VFX にとって、1 日の遅延がクライアントへの納品やプロジェクトスケジュールに直接影響します。 本記事では、Outpost VFX が AWS インフラを活用してフェイスリプレースメントのワークフローを刷新し、トレーニング速度を最大 8 倍に向上させた方法、シングル GPU の制約を克服するために実装した技術アーキテクチャ、そして AWS マルチ GPU トレーニングで得られた具体的な成果について紹介します。 課題: AI トレーニングにおけるシングル GPU のボトルネック VFX 制作における従来のフェイスリプレースメントワークフローでは、監督承認用の初期バージョンを作成するだけで、コンポジットや専門的なビューティ・デエイジング作業に 5 日以上かかります。この手法は有効ではあるものの、制作スケジュールで最も重要な反復承認プロセスの初期段階でボトルネックが生じます。VFX の現場では、AI トレーニングの遅さがそのまま納期遅延、コスト増加、クライアントへのフィードバックサイクルの長期化につながります。 Outpost VFX は、撮影現場の映像を学習してフェイスリプレースメントを高速化できる AI モデルを独自に開発していました。しかし、シングル GPU のコンピューティング制約により効率が頭打ちになっていました。既存のフェイススワップツールは同時に 1 つの GPU しか使えず、モデルトレーニングで利用できるビデオランダムアクセスメモリ (VRAM) と処理能力が限られていました。そのため、AI 支援アプローチの潜在能力を十分に引き出せずにいました。 設計上の考慮事項 Outpost VFX は、AI ワークフローを最適化するうえで技術的に重要な要件を 3 つ特定しました。 コンピューティングのスケーラビリティ – 意味のある効率改善を実現するには、フェイスリプレースメントモデルのトレーニングを複数の GPU に並列化する必要がありました。シングル GPU によるトレーニングでは、モデルの反復サイクルに毎回数週間の遅延が生じていました。 インフラのセキュリティ – 2022 年から AWS を利用し、完全仮想化された技術スタックを運用する Outpost VFX にとって、機密性の高い制作データを扱うソリューションは自社の厳格なセキュリティ要件を満たす必要がありました。 パフォーマンスの最適化 – 単純な速度向上にとどまらず、より大規模なデータセットや高解像度画像にも対応できるアーキテクチャが、出力品質の向上に不可欠でした。 これらの要件に対応するため、Outpost VFX は AWS Generative AI Innovation Center の開発者と連携しました。同チームは Outpost VFX の技術部門と一体となって AI 学習アルゴリズムの刷新に取り組みました。AWS Generative AI Innovation Center は、ストラテジスト、データサイエンティスト、エンジニア、ソリューションアーキテクトで構成されるチームで、顧客とともに生成 AI の力を活かしたカスタムソリューションを段階的に構築します。チームへの参加方法については、 Generative AI Innovation Center のページをご覧ください。 アーキテクチャの実装 このソリューションでは、Outpost VFX の既存フェイススワップモデルのコードベースを改修し、複数 GPU での分散トレーニングに対応させました。実装には、Outpost VFX の既存インフラ要件に沿った、分離されたセキュアなクラウド環境内に AWS マルチ GPU の Amazon Elastic Compute Cloud (Amazon EC2) P5 インスタンスを使用しました。 もともと Outpost VFX は、GPU アクセラレーション対応のワークステーションでフェイススワップモデルをトレーニングしていました。俳優とスタントダブルの小規模なデータセットを収集し、RTX 3090 GPU でベースモデルをファインチューニングする手法です。この方法は機能していたものの、ファインチューニング 1 回あたり約 1〜2 週間かかるなど、トレーニング時間が長いという課題がありました。また、クラウドワークステーションの管理オーバーヘッドを考えると、スケールアップも容易ではありませんでした。そこで、P5 インスタンスでのトレーニングを検討することになりました。 P5 インスタンスには、分散トレーニングワークロード向けに設計された NVIDIA H100 GPU が搭載されています。GPU 間の通信に PCIe を使用する G シリーズインスタンスとは異なり、P5 インスタンスは NVLink インターコネクトを備えており、勾配同期に必要な帯域幅が大幅に向上しています。これは複数 GPU でのトレーニングにおいて重要な要素です。また、H100 の 14,592 個の CUDA コアと 80 GB の高帯域幅 HBM3 メモリは、従来のローカル RTX 3090 環境から大きく進化しています。 Outpost VFX は Generative AI Innovation Center と協力し、P5 インスタンス上でモデルを動作させました。6 週間のアドバイザリー期間を通じて、AWS のサイエンティストがモデルコードを PyTorch Distributed Data Parallel (DDP) トレーニング戦略に対応するよう変換しました。DDP は、各 GPU にモデルの重みをコピーする並列化手法で、各トレーニングバッチで処理できる画像数を増やせます。バッチあたりの画像数が増えることで、トレーニングプロセスが直接高速化されます。 技術的な実装内容には、フェイスリプレースメントモデルトレーニングのマルチ GPU 並列化、機密性の高い制作データに対応したセキュリティアーキテクチャの強化、そして Outpost VFX の既存 AWS ベース技術スタックとの統合が含まれます。Outpost VFX は AI パイプラインの進化を続けており、今後は Amazon SageMaker AI のマネージドトレーニング、モデルバージョニング、ホスト型推論などのサービスを活用して、グローバルなスタジオ全体でのモデル開発・デプロイをさらに効率化できると見込んでいます。 パフォーマンス改善の測定 マルチ GPU トレーニングの速度向上を検証するため、Outpost VFX はトレーニング用の画像データセットを収集し、モデルのハイパーパラメータを固定したうえで、特定の損失閾値に達するまでの時間を計測しました。ベースラインは G5 インスタンス上のシングル GPU とし、P5 インスタンスでの結果と比較しました。 Outpost VFX と AWS の共同開発により、フェイスリプレースメントモデルの学習速度は最大 8 倍向上しました。このパフォーマンス向上は反復サイクルの短縮に直結し、初期バージョンに対する監督承認プロセスをより迅速に進められるようになりました。高解像度画像や大規模データセットでのモデルトレーニングが可能になったことで、出力品質も向上しました。特筆すべき点として、初回レビュー用のクライアントへの v001 納品にかかる期間が、従来の 1〜2 週間から 2 日間に短縮されました。 「並列化されたワークフローと複数のハイエンド GPU を同時に活用できるようになったことで、イテレーションのスピードが大幅に向上しました」 と Outpost VFX の CTO である Tim Chauncey は述べています。 「VFX の仕事においてイテレーションの速度は非常に重要であり、このアーキテクチャは将来の開発に向けて、より堅牢でスケーラブルな基盤を提供しています。」 今後の改善点としては、画像出力の品質向上が考えられます。Outpost はモデルに渡す画像の解像度を上げ、より多くの VRAM を搭載した新世代の Amazon EC2 P5 インスタンスを使用することで、より大きな画像や大規模なデータセットを処理できます。 まとめ AWS に最適化されたアーキテクチャにより、Outpost VFX はハイエンド VFX 制作に求められるセキュリティとスケーラビリティを維持しながら、AI を活用したフェイスリプレースメント機能をクライアントに提供できるようになりました。ローカルのコンシューマー向け NVIDIA GPU からエンタープライズ向け NVIDIA GPU への移行を含む並列化ワークフローアーキテクチャは、Outpost VFX のグローバルスタジオ運営における AI ツールの開発とスケーリングの基盤となっています。 「私が最も興奮しているのは、これらのモデルがもはや研究段階の実験ではなく、現代の VFX パイプラインに不可欠な要素になりつつあるという点です」 と Outpost VFX のリードソフトウェアアーキテクトである Dheeraj Bhadani は述べています。 「マルチ GPU アクセラレーションは、次世代のクリエイティブツールが構築される基盤です。」 次のステップ AI トレーニングワークフローの高速化を検討している場合は、以下のステップを参考にしてください。 現在の GPU 使用率を評価する: シングル GPU の制約がトレーニングのパフォーマンスを制限していないか確認する マルチ GPU アーキテクチャを検討する: Amazon EC2 P5 インスタンスは、分散トレーニングワークロードに対してスケーラブルなコンピューティングを提供する AWS Generative AI Innovation Center に相談する: Outpost VFX のトレーニングワークフロー並列化を支援したチームに問い合わせる ユースケースとインフラ要件に合わせた分散トレーニング戦略を実装することで、同様の成果を得ることができます。 謝辞 著者一同、本プロジェクトにご協力いただいた Josh Chappatte、Laksh Puri、Ruchi Bhatia の各氏に感謝いたします。 著者について Alex Newton Alex は AWS Generative AI Innovation Center のデータサイエンティストとして、生成 AI と機械学習を活用してお客様の複雑な課題解決を支援しています。最先端の ML ソリューションを現実の課題に応用することに情熱を持っています。 Hanno Bever Hanno はロンドンを拠点とする AWS Generative AI Innovation Center のシニア機械学習エンジニアです。Amazon での 6 年間で、あらゆる業界のお客様が AWS 上で機械学習ワークロードを実行できるよう支援してきました。AWS Trainium および GPU インスタンスにおける分散モデルトレーニングのスケーリングと推論の最適化を専門としています。 Stephen Smith Stephen は英国を拠点とする AWS のシニアソリューションアーキテクトです。さまざまな業界のエンタープライズ顧客と連携し、モダンでスケーラブル、かつコスト効率の高いクラウドアーキテクチャの設計を支援しています。AWS での 7 年以上の経験を持ち、最新のデータおよび AI ソリューションの導入を通じてお客様のビジネス課題を解決することに情熱を注いでいます。 Tim Chauncey Tim は 2022 年より英国に本社を置く Outpost VFX の最高技術責任者 (CTO) を務めています。在任中、スタジオによるハイエンドの映画・エピソード作品の制作方法に大きな変革をもたらし、従来のオンプレミス環境から AWS 上でグローバルに稼働する統合クラウドインフラへの移行を成功させました。現在は、最先端の ML プロダクションツールとエージェントシステムを Outpost の制作ワークフローに統合するチームを率いています。 Dheeraj Bhadani Dheeraj は Outpost VFX のリードソフトウェアアーキテクトであり、VFX およびアニメーション業界で 20 年以上の経験を持ちます。技術革新に精通したベテランアーキテクトとして、Academy Sci-Tech Awards で表彰された技術的進歩に重要な役割を果たしてきました。構想から実装まで、高度に分散化されたスケーラブルで耐障害性の高いシステムの設計・構築に情熱を持っています。近年は、デジタルコンテンツ制作アプリケーションに統合されるプロダクショングレードの AI・機械学習ツールや、スタンドアロンソリューションとして展開されるシステムのアーキテクチャ設計と開発に注力しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 6 月 30 日 に公開された「 How Outpost VFX Uses AWS to Accelerate AI Model Training for Visual Effects 」を翻訳したものです。 Outpost VFX の Tim Chauncey と Dheeraj Bhadani との共同執筆です。 ビジュアルエフェクト (VFX) 向けの AI モデルトレーニングには数週間を要することがあり、制作スケジュールのボトルネックになりがちです。英国、カナダ、インドにスタジオを構え、高品質な映画やエピソードコンテンツを手がける Outpost VFX にとって、1 日の遅延がクライアントへの納品やプロジェクトスケジュールに直接影響します。 本記事では、Outpost VFX が AWS インフラを活用してフェイスリプレースメントのワークフローを刷新し、トレーニング速度を最大 8 倍に向上させた方法、シングル GPU の制約を克服するために実装した技術アーキテクチャ、そして AWS マルチ GPU トレーニングで得られた具体的な成果について紹介します。 課題: AI トレーニングにおけるシングル GPU のボトルネック VFX 制作における従来のフェイスリプレースメントワークフローでは、監督承認用の初期バージョンを作成するだけで、コンポジットや専門的なビューティ・デエイジング作業に 5 日以上かかります。この手法は有効ではあるものの、制作スケジュールで最も重要な反復承認プロセスの初期段階でボトルネックが生じます。VFX の現場では、AI トレーニングの遅さがそのまま納期遅延、コスト増加、クライアントへのフィードバックサイクルの長期化につながります。 Outpost VFX は、撮影現場の映像を学習してフェイスリプレースメントを高速化できる AI モデルを独自に開発していました。しかし、シングル GPU のコンピューティング制約により効率が頭打ちになっていました。既存のフェイススワップツールは同時に 1 つの GPU しか使えず、モデルトレーニングで利用できるビデオランダムアクセスメモリ (VRAM) と処理能力が限られていました。そのため、AI 支援アプローチの潜在能力を十分に引き出せずにいました。 設計上の考慮事項 Outpost VFX は、AI ワークフローを最適化するうえで技術的に重要な要件を 3 つ特定しました。 コンピューティングのスケーラビリティ – 意味のある効率改善を実現するには、フェイスリプレースメントモデルのトレーニングを複数の GPU に並列化する必要がありました。シングル GPU によるトレーニングでは、モデルの反復サイクルに毎回数週間の遅延が生じていました。 インフラのセキュリティ – 2022 年から AWS を利用し、完全仮想化された技術スタックを運用する Outpost VFX にとって、機密性の高い制作データを扱うソリューションは自社の厳格なセキュリティ要件を満たす必要がありました。 パフォーマンスの最適化 – 単純な速度向上にとどまらず、より大規模なデータセットや高解像度画像にも対応できるアーキテクチャが、出力品質の向上に不可欠でした。 これらの要件に対応するため、Outpost VFX は AWS Generative AI Innovation Center の開発者と連携しました。同チームは Outpost VFX の技術部門と一体となって AI 学習アルゴリズムの刷新に取り組みました。AWS Generative AI Innovation Center は、ストラテジスト、データサイエンティスト、エンジニア、ソリューションアーキテクトで構成されるチームで、顧客とともに生成 AI の力を活かしたカスタムソリューションを段階的に構築します。チームへの参加方法については、 Generative AI Innovation Center のページをご覧ください。 アーキテクチャの実装 このソリューションでは、Outpost VFX の既存フェイススワップモデルのコードベースを改修し、複数 GPU での分散トレーニングに対応させました。実装には、Outpost VFX の既存インフラ要件に沿った、分離されたセキュアなクラウド環境内に AWS マルチ GPU の Amazon Elastic Compute Cloud (Amazon EC2) P5 インスタンスを使用しました。 もともと Outpost VFX は、GPU アクセラレーション対応のワークステーションでフェイススワップモデルをトレーニングしていました。俳優とスタントダブルの小規模なデータセットを収集し、RTX 3090 GPU でベースモデルをファインチューニングする手法です。この方法は機能していたものの、ファインチューニング 1 回あたり約 1〜2 週間かかるなど、トレーニング時間が長いという課題がありました。また、クラウドワークステーションの管理オーバーヘッドを考えると、スケールアップも容易ではありませんでした。そこで、P5 インスタンスでのトレーニングを検討することになりました。 P5 インスタンスには、分散トレーニングワークロード向けに設計された NVIDIA H100 GPU が搭載されています。GPU 間の通信に PCIe を使用する G シリーズインスタンスとは異なり、P5 インスタンスは NVLink インターコネクトを備えており、勾配同期に必要な帯域幅が大幅に向上しています。これは複数 GPU でのトレーニングにおいて重要な要素です。また、H100 の 14,592 個の CUDA コアと 80 GB の高帯域幅 HBM3 メモリは、従来のローカル RTX 3090 環境から大きく進化しています。 Outpost VFX は Generative AI Innovation Center と協力し、P5 インスタンス上でモデルを動作させました。6 週間のアドバイザリー期間を通じて、AWS のサイエンティストがモデルコードを PyTorch Distributed Data Parallel (DDP) トレーニング戦略に対応するよう変換しました。DDP は、各 GPU にモデルの重みをコピーする並列化手法で、各トレーニングバッチで処理できる画像数を増やせます。バッチあたりの画像数が増えることで、トレーニングプロセスが直接高速化されます。 技術的な実装内容には、フェイスリプレースメントモデルトレーニングのマルチ GPU 並列化、機密性の高い制作データに対応したセキュリティアーキテクチャの強化、そして Outpost VFX の既存 AWS ベース技術スタックとの統合が含まれます。Outpost VFX は AI パイプラインの進化を続けており、今後は Amazon SageMaker AI のマネージドトレーニング、モデルバージョニング、ホスト型推論などのサービスを活用して、グローバルなスタジオ全体でのモデル開発・デプロイをさらに効率化できると見込んでいます。 パフォーマンス改善の測定 マルチ GPU トレーニングの速度向上を検証するため、Outpost VFX はトレーニング用の画像データセットを収集し、モデルのハイパーパラメータを固定したうえで、特定の損失閾値に達するまでの時間を計測しました。ベースラインは G5 インスタンス上のシングル GPU とし、P5 インスタンスでの結果と比較しました。 Outpost VFX と AWS の共同開発により、フェイスリプレースメントモデルの学習速度は最大 8 倍向上しました。このパフォーマンス向上は反復サイクルの短縮に直結し、初期バージョンに対する監督承認プロセスをより迅速に進められるようになりました。高解像度画像や大規模データセットでのモデルトレーニングが可能になったことで、出力品質も向上しました。特筆すべき点として、初回レビュー用のクライアントへの v001 納品にかかる期間が、従来の 1〜2 週間から 2 日間に短縮されました。 「並列化されたワークフローと複数のハイエンド GPU を同時に活用できるようになったことで、イテレーションのスピードが大幅に向上しました」 と Outpost VFX の CTO である Tim Chauncey は述べています。 「VFX の仕事においてイテレーションの速度は非常に重要であり、このアーキテクチャは将来の開発に向けて、より堅牢でスケーラブルな基盤を提供しています。」 今後の改善点としては、画像出力の品質向上が考えられます。Outpost はモデルに渡す画像の解像度を上げ、より多くの VRAM を搭載した新世代の Amazon EC2 P5 インスタンスを使用することで、より大きな画像や大規模なデータセットを処理できます。 まとめ AWS に最適化されたアーキテクチャにより、Outpost VFX はハイエンド VFX 制作に求められるセキュリティとスケーラビリティを維持しながら、AI を活用したフェイスリプレースメント機能をクライアントに提供できるようになりました。ローカルのコンシューマー向け NVIDIA GPU からエンタープライズ向け NVIDIA GPU への移行を含む並列化ワークフローアーキテクチャは、Outpost VFX のグローバルスタジオ運営における AI ツールの開発とスケーリングの基盤となっています。 「私が最も興奮しているのは、これらのモデルがもはや研究段階の実験ではなく、現代の VFX パイプラインに不可欠な要素になりつつあるという点です」 と Outpost VFX のリードソフトウェアアーキテクトである Dheeraj Bhadani は述べています。 「マルチ GPU アクセラレーションは、次世代のクリエイティブツールが構築される基盤です。」 次のステップ AI トレーニングワークフローの高速化を検討している場合は、以下のステップを参考にしてください。 現在の GPU 使用率を評価する: シングル GPU の制約がトレーニングのパフォーマンスを制限していないか確認する マルチ GPU アーキテクチャを検討する: Amazon EC2 P5 インスタンスは、分散トレーニングワークロードに対してスケーラブルなコンピューティングを提供する AWS Generative AI Innovation Center に相談する: Outpost VFX のトレーニングワークフロー並列化を支援したチームに問い合わせる ユースケースとインフラ要件に合わせた分散トレーニング戦略を実装することで、同様の成果を得ることができます。 謝辞 著者一同、本プロジェクトにご協力いただいた Josh Chappatte、Laksh Puri、Ruchi Bhatia の各氏に感謝いたします。 著者について Alex Newton Alex は AWS Generative AI Innovation Center のデータサイエンティストとして、生成 AI と機械学習を活用してお客様の複雑な課題解決を支援しています。最先端の ML ソリューションを現実の課題に応用することに情熱を持っています。 Hanno Bever Hanno はロンドンを拠点とする AWS Generative AI Innovation Center のシニア機械学習エンジニアです。Amazon での 6 年間で、あらゆる業界のお客様が AWS 上で機械学習ワークロードを実行できるよう支援してきました。AWS Trainium および GPU インスタンスにおける分散モデルトレーニングのスケーリングと推論の最適化を専門としています。 Stephen Smith Stephen は英国を拠点とする AWS のシニアソリューションアーキテクトです。さまざまな業界のエンタープライズ顧客と連携し、モダンでスケーラブル、かつコスト効率の高いクラウドアーキテクチャの設計を支援しています。AWS での 7 年以上の経験を持ち、最新のデータおよび AI ソリューションの導入を通じてお客様のビジネス課題を解決することに情熱を注いでいます。 Tim Chauncey Tim は 2022 年より英国に本社を置く Outpost VFX の最高技術責任者 (CTO) を務めています。在任中、スタジオによるハイエンドの映画・エピソード作品の制作方法に大きな変革をもたらし、従来のオンプレミス環境から AWS 上でグローバルに稼働する統合クラウドインフラへの移行を成功させました。現在は、最先端の ML プロダクションツールとエージェントシステムを Outpost の制作ワークフローに統合するチームを率いています。 Dheeraj Bhadani Dheeraj は Outpost VFX のリードソフトウェアアーキテクトであり、VFX およびアニメーション業界で 20 年以上の経験を持ちます。技術革新に精通したベテランアーキテクトとして、Academy Sci-Tech Awards で表彰された技術的進歩に重要な役割を果たしてきました。構想から実装まで、高度に分散化されたスケーラブルで耐障害性の高いシステムの設計・構築に情熱を持っています。近年は、デジタルコンテンツ制作アプリケーションに統合されるプロダクショングレードの AI・機械学習ツールや、スタンドアロンソリューションとして展開されるシステムのアーキテクチャ設計と開発に注力しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

2026年6月10日〜12日、AWS Japan オフィスにて「AI-DLC UnicornGym」を開催しました。参加いただいたのは、自動車部品・システムのグローバルメガサプライヤー Astemo 。SDVソリューション開発本部と技術開発本部から44名が集まり、7チームが実業務テーマでAI駆動開発を3日間体験しました。 AI-DLC の全体像については「 AI駆動開発ライフサイクル（AI-DLC） 」をご覧ください。 なぜ Astemo が AI-DLC に取り組んだのか 「これまでの成功体験をアンラーンし、自己破壊をしてほしい」 ワークショップ冒頭、UnicornGym のゴールとして参加者に投げかけられた言葉です。自動車のソフトウェア定義化（SDV）が加速する中、エグゼクティブは「これまでにない生産性」を目標に掲げ、最重要ミッションは技術開発ではなく 全従業員の行動変容 であると明言しました。44 名の参加者は、その変革の起爆剤として位置づけられています。 自動車業界では品質基準やプロセスが厳格に定義されており、新しい開発手法の導入にはどうしても慎重になります。「生成 AI は使ってみたが思ったようにいかない」「自分で書いた方が早い」という声も現場にはありました。今回の Unicorn Gym は、全社展開に向けた行動変容のきっかけづくりとして企画しました。 3日間で何をしたのか 1日目は Inception（構想）です。各チームが持ち込んだ実業務テーマに対し、Claude Code との対話でビジネス意図をユーザーストーリーに落とし込みます。AI が生成したモック画面をチーム全員で見ながら「これが欲しかったもの？」「ここは違う」と認識を揃えていきます。テキストだけでは抽象度が高すぎて合意に時間がかかりますが、目に見える画面があると議論が具体化し、意思決定のスピードが格段に上がりました。 2〜3日目は Construction（構築）です。前日の要件をもとに Claude Code が設計・コードを提案し、チームで集中的に実装を進めます。人間の役割は「コードを書く」から「レビューと意思決定」に変わり、AI の成果物を次々にジャッジしていきます。AI の実装スピードが速いため、むしろ人間同士の認識合わせや意思決定がボトルネックになる場面もありました。 全チームが自社の実課題を持ち込みました。架空のお題ではなく「普段困っていること」をそのまま3 日間でプロトタイプにする形式が、参加者の本気度と成果物の実用性を引き上げました。 成果 ワークショップ後のアンケートは、「同僚にも薦めたい」の推奨度は 4.88/5.0、「自分の働き方が変わると感じた」は 4.67/5.0 という結果でした。 7チームのテーマは、組込みソフトウェアのモデル解析、開発環境の構築、テスト仕様書の自動生成、セキュリティツールの評価自動化など多岐にわたりました。いずれも「今まさに現場で工数がかかっている業務」ばかりです。 具体的には、組込みモデルの挙動を AI で解析するクラウドサービス、要件定義からテスト仕様書を自動生成する AI エージェント、複数ツールの評価レポートを画像認識も含めて自動生成する仕組み、開発メトリクスを収集・可視化するダッシュボード基盤、クラウド環境の運用を統一 UI で自動化するシステムなどが生まれました。 代表的な数字を紹介します。 3 日間で 9 マイクロサービス / 4,500 行超 / 174 コミット / 76 PR 開発スピード 約200 %向上 7チーム全てがデモ可能なプロトタイプを完成させました。 さらに、あるチームはワークショップ翌週に早くも 本番リリースしました。3日間で生まれたプロトタイプが「やって終わり」ではなく、翌週からイテレーションが回り始めた事例です。AI-DLC で身につけた開発サイクルがそのまま実務に直結することを示しています。 参加者の声 「今までの自分を破壊することが出来た！」 「人間は選択に集中し、AIに任せるべき。ストレートに開発に響く学び」 「記事で読んでも実感できなかったが、体験で腹落ちした」 「初学者の私が一つのシステムを作り上げた達成感」 ベテランから若手まで共通して出てきたのが「体験しないとわからない」です。どれだけ説明を聞いても、実際にAI がコードを生成し、自分がレビューと判断に集中する体験をしないと腹落ちしません。AI-DLC の価値は、実際に手を動かして初めて実感できるものだと改めて感じました。 学び ① 設計判断は人間が握る — AI に任せきりにすると、並行開発でアーキテクチャが混在しチーム間の成果物が結合できなくなるリスクがあります。「どのアーキテクチャで行くか」を Inception の段階で人間が合意しておくことが、Construction のスピードを決めました。 ② インセプションの質が全てを決める — ユーザーストーリーの精度が甘いと AI の出力も曖昧になります。コーディングから解放された分、要件の言語化に集中できるのが AI-DLC の強みです。事前に AI-DLC の用語集やコンセプト概要を配布しておけば、初日からさらにスピードを出せたという反省もあります。 ③ 自動車業界の品質基準との共存は次の論点 — 自動車固有のプロセスゲートに対して、AI-DLC の学びを活かすために、パイロットプロジェクトを通じて段階的に評価を進めたいと考えています。 ④ UnicornGym の3日間は「起爆剤」であり「ゴール」ではない — エグゼクティブが強調したのは「全従業員の行動変容」です。参加者が社内 Champion となり各部門に展開していく仕組みづくりが次の課題になっています。 今後の展開 44名の参加者は、全社展開の起点になります。ここから AI-DLC Champion の育成、AI ツールの組織定着、品質保証部門との連携などを段階的に進めていきます。 エグゼクティブが掲げたのは「全従業員の行動変容」と「これまでにない生産性」です。3日間で7プロトタイプを完成させた今回のワークショップは、その実現可能性を示す最初の一歩になったと考えています。 — AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。AI-DLC を始めるためのワークフローやテンプレートを公開しています。 著者 山崎 徹 アマゾン ウェブ サービス ジャパン合同会社 テクニカルカスタマーソリューションズ マネージャー

こんにちは、ソリューションアーキテクトの田邊です。2026 年 6 月 25 日から 26 日にかけて幕張メッセで開催された AWS Summit Japan 2026 の AWS for Industries Zone（ブース番号 044 ）にて、スマートグラスと生成 AI エージェントを組み合わせた倉庫ピッキング支援デモを展示しました。本ブログでは、展示内容とその裏で動いている AWS サービス構成を、デモの体験に沿ってご紹介します。 背景：倉庫ピッキング業務の課題 倉庫のピッキング業務は物流オペレーションの中でも人手に依存する割合が高く、ハンディターミナル（専用の携帯端末）の導入は進んでいるものの、以下のような課題が現場に残っています。 両手が塞がる : 商品を持つ・置く動作と端末操作が競合し、重量物のハンドリング時に効率が落ちる 視線の移動 : 端末画面と棚を交互に見る必要があり、ピッキングミスや作業テンポの低下につながる 教育コスト : 新人・パート作業者が端末操作や棚配置を覚えるまで時間がかかる 多言語対応 : 外国人作業者が増える中、日本語のみの指示系統ではオンボーディングに時間がかかる これらの課題に対して、スマートグラスと生成 AI エージェントを組み合わせ、「見るだけ・話すだけ」で業務システムにアクセスできる新しい業務体験を提案するデモを企画しました。 デモの全体像 今回のデモでは、倉庫のピッキング業務を題材に、スマートグラスと生成 AI エージェントによるハンズフリー業務支援を紹介しました。特徴は以下の2点です。 1. 音声だけで完結する業務システム操作 「ピッキングリストをください」と話しかけるだけで、倉庫管理システム（ WMS ）から作業リストを取得し、音声で案内 商品の QR コードをスマートグラスでスキャンするだけで、ピッキング完了が自動で記録 端末画面のタップは不要。両手で商品を扱いながら業務を進められる 2. 自然な多言語対話 Amazon Nova 2 Sonic により、人と話しているような低遅延で自然な音声対話を実現 英語・スペイン語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語に対応（話した言語を自動判定して同じ言語で応答） 商品の取扱注意など業務ナレッジも、社内マニュアルから探して読み上げ 使用したスマートグラス 本デモでは、Android を搭載したスマートグラス 2 機種を用意し、来場者に体験いただきました。両機種とも AI エージェントと対話するアプリを単体で動作させることができ、それぞれ形状・視認性・装着感に特徴があります。 Vuzix M400 — Android11 を搭載し単体で動作するモノキュラー（単眼）型のスマートグラスです。1,280 万画素のカメラでバーコード読み取りに対応し、本体 68 g、IP 67の防水防塵性能で倉庫環境にも適しています。ノイズキャンセリングマイクを搭載しており、周囲に環境音がある現場でも音声を正確に拾うことができます。 RayNeo X3 Pro — Android を搭載したフルカラー MicroLED ディスプレイを持つ眼鏡型のスマートグラスです。バーコード読み取りに加え、音声・映像を組み合わせたマルチモーダルな対話に対応します。輝度 6,000 ニットの高い視認性で、明るい場所でも表示内容がしっかり見えます。装着感が眼鏡に近く、より日常的なユースケースにも馴染むデザインです。 なお、本デモのアプリは Android で動作する仕組みのため、Vuzix・RayNeo に限らず、Android 対応の他のスマートグラスやタブレット・スマートフォンでも同様の体験を実現できます。 アーキテクチャ構成 デモのアーキテクチャは以下のような構成になっています。 スマートグラス上の Android アプリはシンプルな役割に絞り、会話の理解・業務データの取得・回答生成といったロジックはすべてクラウド側の Amazon Bedrock AgentCore Runtime に集約しています。全体の処理の流れは次のとおりです。 認証 : 端末にクラウドの長期パスワード的な情報を置かず、Amazon Cognito と AWS Lambda により一時的な接続 URL を発行するセキュアな仕組み 音声送受信 : スマートグラスから作業者の音声をリアルタイムに Amazon Bedrock AgentCore Runtime へ送信。Amazon Nova 2 Sonic が音声を直接理解し、応答の音声を返す 業務データへの問い合わせ : エージェントが必要に応じて Amazon Bedrock AgentCore Gateway を介し、ツール（関数）を呼び出し、Amazon DynamoDB （ WMS データ）や Amazon Bedrock Knowledge Bases （社内マニュアル）からデータを取得 この構成により、スマートグラス側は音声とカメラの入出力に専念でき、エージェントの機能追加やプロンプト調整はクラウド側の変更だけで反映されます。以下、デモのシナリオを順に追いながら、各ステップで動いているサービスを見ていきます。 ① 音声でタスク取得 作業者がスマートグラスに「ピッキングリストをください」と話しかけると、生成 AI エージェントが WMS から作業リストを取得し、棚番号・商品名・数量を音声と画面で案内します。 裏側では、スマートグラスから送られてきた音声をクラウド上の Amazon Nova 2 Sonic が受け取ります。Amazon Nova 2 Sonic は音声を直接理解し、そのまま音声で応答を返せる生成 AI モデルです。従来の「音声を一度文字に起こしてから生成 AI に渡し、生成された文章を再び音声にする」という 3 段階の処理と違い、音声のまま処理するため、人と話しているような自然で低遅延なやり取りが可能になります。作業者の意図が「ピッキングリストの取得」だと判断されると、エージェントが WMS 用のツールを呼び出し、Amazon Dynamo DB からリストを取り出して音声で読み上げ、同時にタスク一覧を画面に表示します。 ② QR スキャンで商品照合・完了 案内された棚に移動し、商品のQR コードをスキャンすると、エージェントが商品を照合し、ピッキング完了を WMS に自動で記録します。次のアイテムがある場合は続けて音声で棚の場所を案内し、全アイテム完了時には作業時間もフィードバックします。 ここでは、音声とカメラという異なる入力を、同じ会話の流れの中で扱っています。QR スキャンの結果はテキスト情報として Amazon Nova 2 Sonic に渡り、エージェントは「今、この作業者は音声で受けたタスクの商品をスキャンした」と文脈を理解した上で、Amazon Dynamo DB に完了記録を書き込みます。作業者は「モードを切り替える」といった意識をせず、話す・スキャン・話す、というテンポで作業を進められます。 ③ 視覚支援と業務ナレッジ照会 「棚の場所が分からない」と聞けば倉庫マップで棚位置をハイライト表示、「タイミングベルトの取扱注意点は?」と聞けば社内マニュアルから該当箇所を音声で読み上げます。 業務ナレッジの音声応答は、Amazon Bedrock Knowledge Bases という機能で実現しています。これは、事前に社内のピッキングマニュアルなどのドキュメントを Amazon S3 に置いておくと、生成 AI が質問の意図に合わせて関連する記述を意味的に検索してくれる仕組みです。エージェントは検索結果をもとに要点をまとめ、Amazon Nova 2 Sonic を通じて自然な音声で回答します。マニュアルを更新しても、それを取り込み直すだけで、エージェントの回答が常に最新の内容に保たれます。 1 会話あたりのコスト ブース来場者から多くいただいた質問がコスト面でした。本デモの構成で、ピッキング 4 アイテムを約 3 分で処理する会話1回あたりのコストは、およそ 8.9 円（ 1 USD = 160 円換算）です。1 端末あたり 100 会話/日 × 30 日で月額約 26,720 円と、実運用に耐える水準です。コストの大半（約 78 %）は音声の生成（ AI の応答音声）が占めるため、AI の応答を簡潔にする工夫がコスト削減に最も効きます。 期待される効果 本ソリューションの導入で、以下のような効果が期待できます。 作業者の身体的・認知的負荷の低減 : 端末操作から解放され、視線を作業対象に集中できる 教育コストの削減 : 音声で作業指示・マニュアル照会ができ、新人・短期雇用者の即戦力化が容易 多言語対応による人材活用 : 外国人作業者にも母語で指示・案内が可能 既存 WMS を活かした導入 : 現行の業務システムを置き換えず、生成 AI エージェントから連携 本デモのコアである「生成 AI エージェント × ウェアラブルデバイス × 音声インタラクション」の組み合わせは、倉庫ピッキングに限らず、「両手を使う現場作業×システム連携」が求められる幅広い領域に応用可能です。製造ラインでの作業指示と部品照合、医療現場での検体照合と電子カルテ入力、設備点検・警備での手順書参照とレポート入力、店舗のバックヤード在庫確認など、応用先は多岐にわたります。 まとめ AWS Summit Japan 2026 で展示した「スマートグラス × 生成 AI エージェント」は、倉庫ピッキング業務における「両手が塞がる」「教育コストが高い」「多言語対応が難しい」という課題に対し、見るだけ・話すだけで業務システムにアクセスできる新しい業務体験を提案するものです。Amazon Bedrock AgentCore Runtime と Amazon Nova2 Sonic の組み合わせで、サーバレスで実装できます。物流業界は 2024 年問題をはじめ様々な課題に直面していますが、生成 AI エージェントを既存の業務システムに繋ぐことで、現場の負荷を減らしながら生産性を高めることが可能です。ご興味のある方は、担当ソリューションアーキテクトまでお気軽にご相談ください。 会場では倉庫ピッキング以外のユースケースについても多くのご相談やディスカッションをいただき、このソリューションパターンへの関心の高さを実感しています。 この展示は、ソリューションアーキテクト横山、駒野、山本、田邊が担当しました。

この記事は、”Reimagine your mainframe applications with Agentic AI and AWS Transform” を翻訳したものです。 本ブログでは、reimagine パターンによってメインフレームのレガシーアプリケーションをモダナイズする AWS のアプローチの概要を説明し、組織がレガシー COBOL アプリケーションをモダンなクラウドネイティブアーキテクチャに変換する方法を紹介します。 人材不足、コスト増加、ビジネスアジリティの制約により、組織はレガシーメインフレームアプリケーションをモダナイズする喫緊の課題に直面しています。 AWS は、メインフレームアプリケーションをモダナイズするための複数のアプローチをサポートしています。Reimagine パターンにより、組織はカスタマーエクスペリエンスを再構想 (reimagine) し、ビジネスプロセスフローを最適化し、新機能を導入することで、モダンなアプリケーションに機能的な変化をもたらすことができます。このプロセスで、メインフレームアプリケーションをモダナイズすることができます。この過程は、モダンなアーキテクチャとテクノロジースタックを使った、アーキテクチャの再設計 (rearchitecting) と、アプリケーションのリライト (rewriting) を伴います。トランスフォーメーションジャーニーを加速させるため、エージェンティック AI を活用したツール一式によって、メインフレームのモダナイゼーションの reimagine パターンがサポートされています。 メインフレームアプリケーションを再構想するときの戦略的課題 AWS は、メインフレームモダナイゼーションの特効薬が無いことを認識しています。戦術的アプローチは既存システムの拡張と維持に重点を置いていますが、戦略的モダナイゼーションには リプラットフォーム (replatform)、リファクタリング (refactor)、リプレース (replace)、reimagine という明確な道筋があります。Reimagine は最も変革的なアプローチを代表しており、組織はマイクロサービスやバッチプロセスからリアルタイム機能への移行などのモダンなパターンを使って、アプリケーションアーキテクチャを全面的に見直します。 ほとんどのお客様は、reimagine 戦略を検討する際に 80:20 の原則に従います。Reimagine は、ビジネスでアプリケーションの機能強化が必要な場合に適しています。お客様は、メインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、モダンな UI、リアルタイム機能、またはより高速なバッチ処理が望まれている可能性があります。また、現行のモノリス化したアプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標をお客様が持っている場合もあります。お客様は、自社のメインフレームアプリケーションの 20% が技術的な制約のせいでビジネスレベルの変更から真に恩恵を受けられない一方で、残り 80% は機能変更を必要としていないことに気付くかもしれません。ただし、一部の組織では、短期的な移行効率よりも長期的なビジネス変革を優先しており、パターンの選択は機能変更を必要とするアプリケーションの割合だけではなく、戦略的目標にも依存していることが実証されています。この洞察は AWS のマルチパターン戦略を推進する要素の 1 つです。AWS は複数の移行パターンをサポートしているので、お客様は各ワークロードに最適なモダナイゼーションアプローチを選択できるようになっています。 参考 5 AWS の reimagine 戦略の中心にあるのが AWS Transform for mainframe です。これは、エージェンティック AI を活用して、メインフレームアプリケーションのモダナイゼーションを加速するサービスです。このサービスにより、お客様は COBOL などの言語で記述されたモノリシックアプリケーションを、マイクロサービスのような、よりモダンなアーキテクチャスタイルに変換できます。AWS の reimagine 戦略の中心は、「Human in the Loop」原則に基づく検証です。この原則では、AI が生成したアプリケーション仕様とコードは、各分野の専門家によって継続的に検証される必要があります。AWS Transform for mainframe は強力なリバースエンジニアリングを提供し、Kiro はマイクロサービス仕様を生成します。ただし、プロセス全体を通して、人間の専門知識は依然として不可欠です。ビジネスロジックの解釈を検証し、アーキテクチャの境界を確認し、アプリケーションがすべての要件を満たしていることを検証するには、専門家が必要です。AI の機能と人間の判断によるこの協調的なアプローチは、AI を活用したモダナイゼーションのスピード上の利点を維持しながら、トランスフォーメーションのリスクを大幅に軽減します。 Strangler fig パターン: 進歩的なモダナイゼーションを可能にする手法 企業のお客様が、すべてのアプリケーションをメインフレームから同時に一括移行するようなビッグバンアプローチの大規模なモダナイゼーションを追求することはめったにないと認識されています。Strangler Fig アプリケーションパターンは、漸次的なモダナイゼーションの手法として実証済の選択肢です。このパターンは、トランスフォーメーション、共存、排除という 3 つの段階を経て、メインフレームアプリケーションをモダナイズするための安全なアプローチとなります。 Strangler fig パターンは、漸次的なモダナイゼーションアプローチです。これにより、組織は元のアプリケーションを実行したまま、モノリシックアプリケーションを徐々にマイクロサービスに置き換えることができます。このアプローチは、モノリスから機能を段階的に抽出することで機能します。抽出された機能は、既存のシステムを中心とした新しいマイクロサービスに変換されます。その後、統合パターンにより、新しいマイクロサービスとレガシーアプリケーションの間の接続が可能になります。 共存フェーズでは、メインフレームと AWS 上の新しいシステムの両方が同時に動作し、システム間の連携が行われます。連携パターンは、アプリケーション間の連携、アプリケーションからデータに対する連携、データ間の連携の 3 種類の統合をサポートします。 参考 4 このような連携アーキテクチャを構築し、共存に適した統合パターンを選択するには、お客様はハイブリッド環境全体におけるデータの一貫性、トランザクション管理、パフォーマンスに特に注意を払う必要があります。 メインフレームモダナイゼーションのためのマイクロサービスアーキテクチャの理解 マイクロサービスアーキテクチャーでは、従来のメインフレームのモノリシックなアーキテクチャーとは対照的に、システムを独立した小さなサービスに分割し、個別に開発、デプロイ、拡張できるようにすることを重視しています。メインフレームモダナイゼーションという文脈において、マイクロサービスには、明確なコンテキスト、独立したデプロイ、テクノロジーの多様性、スケーラビリティなど、重要な価値ある特徴があります。 マイクロサービスとイベント駆動型アーキテクチャを組み合わせると、バッチ処理からリアルタイム処理に移行する際に特に強力になり、変更に対してシステムが非同期で反応できるようになります。 マイクロサービスには大きなメリットがありますが、普遍的に最適なソリューションというわけではありません。データの一貫性やトランザクション性が必要な場合は、モジュラーモノリスやマクロサービスなどの代替アプローチの方が適している場合があります。重要なのは、現在のニーズと将来の願望の両方に適合するアーキテクチャを選択することです。 Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ Reimagine パターンでは、3 フェーズの方法論を通じて、現行のメインフレームアプリケーションをクラウドネイティブなマイクロサービスに変換します。 リバースエンジニアリング : AWS Transform for mainframe を使用してリバースエンジニアリングを行い、既存の COBOL / JCL コードからビジネスロジックとルールを抽出します フォワードエンジニアリング : AI エージェント / Kiro を使ってマイクロサービス仕様とソースコードの両方を生成します デプロイとテスト : 生成されたマイクロサービスを Infrastructure as Code (IaC) を使って AWS にデプロイしてテストし、モダナイズしたアプリケーションの機能をテストします Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ フェーズ 1: リバースエンジニアリング AWS Transform for mainframe を使ったリバースエンジニアリングのスコープを以下の図に示します。 AWS Transform を使ったリバースエンジニアリング モダナイゼーションを成功させるための基礎は、レガシーアプリケーションを深く理解することから始まります。AWS Transform は、メインフレームのソースコードと運用データ (スケジューラープラン、モニタリングデータ) など、複数のソースからの情報を組み合わせて分析します。このフェーズでは、次のような重要なアウトプットが得られます。 技術文書 : AWS Transform はソースコードを自動的に分析して、アプリケーションプログラムの詳細な文書を作成します。このドキュメントには、レガシーシステム内のプログラムロジック、フロー、連携、依存関係についての説明が含まれています。レガシーシステムに関する重要な知識を維持することで、退職するメインフレーム専門家への依存を減らすのに役立ちます。また、これまで分析や計画に費やされていたプロジェクト時間も短縮されます。 ビジネスロジックの抽出 : ビジネスロジックの抽出は、複雑なモノリシックアプリケーションをその構成要素であるビジネス機能に分解する、メインフレームのモダナイゼーションにおいて不可欠な機能です。AWS Transform は COBOL ソースコードを自動的に分析します。この分析は、レガシーアプリケーションに組み込まれているプロセスフローやビジネスロジックなど、重要なビジネス要素を特定して文書化するのに役立ちます。この分解プロセスは、モノリス化したメインフレームアプリケーションをより小さく、より管理しやすいビジネス機能に分解するための基本です。これらの機能は、reimagine の取り組みにおける後半の工程でマイクロサービスのスコープと境界を特定するための基礎となります。この機能は、技術ユーザーとビジネスユーザーの両方が理解できるエクスポート可能な自然言語で仕様を提供することで、モダナイゼーションの取り組みにおける複数のステークホルダーに役立ちます。 メインフレームデータモデル : AWS Transform には、データリネージ分析やデータディクショナリの自動生成など、メインフレームのモダナイゼーションを成功させるために不可欠な高度なデータ分析機能が備わっています。これらの機能が連携して、メインフレームデータの「場所」(使用法と関係) に付随する「内容」(構造と意味) を定義します。組織はデータ環境を完全に可視化できるようになり、情報に基づいたモダナイゼーションの意思決定が可能になります。技術チームは、重要なビジネスロジックとデータ間の関連性を維持しながら、自信を持ってデータアーキテクチャを再設計できます。 稼働分析 : システム管理機能 (SMF) を介してメインフレームから収集された実行時データによって、静的コード分析を補完することができます。SMF は z/OS サブシステム上のアクティビティデータを収集するための中心的なメカニズムです。これらの記録に含まれる情報は、モダナイゼーションの計画、優先順位付け、実行に不可欠です。AWS Transform は SMF データ (バッチ処理ではレコードタイプ 30、CICS トランザクションではレコードタイプ 110) を分析して、アクティブなバッチジョブと CICS トランザクションを識別できます。使用済み/未使用のトランザクション/バッチを検出し、トランザクション/バッチの MIPS 使用量を測定することで、組織は未使用のプログラムと消費量の多いリソースを特定できます。これにより、何を移行し、何を廃止するかについてデータ主導の意思決定が可能になり、メインフレームのリソース使用率をかつてないほど可視化できます。 フェーズ 2: フォワードエンジニアリング フォワードエンジニアリングは、抽出されたビジネスロジックをマクロサービス/マイクロサービスのアーキテクチャに変換することを目的としています。 AWS は、お客様組織内の多様なニーズを認識し、パートナー主導型およびお客様主導型の柔軟なコード生成アプローチを採用しています。AWS は、既存の開発者ツールと競合するのではなく、リバースエンジニアリングで得られた豊富な理解を 促進 することに重点を置いています。これにより、既存のコードを複数の方法でモダンなアプリケーションに正確に変換できるようになります。 Kiro やその他のコーディングアシスタントなどの好みの開発ツールを使用した、お客様主導またはパートナー主導の開発 AI を活用したコーディングアシスタントとしての Kiro や AI エージェントの活用 AWS Transform は Kiro のような AI を活用したコーディングアシスタントと連携して、仕様駆動型の開発をサポートします。これらのツールは互いに補完し合っています。AWS Transform が提供するアウトプットは、Kiro がマイクロサービス仕様とソースコードの両方を生成するためのインプットになります。 Kiro と AI エージェントのアプローチについて詳しく見ていきましょう。このアプローチは 3 つの異なるステップで構成されており、正しさと品質を Human in the Loop で 検証 します。 以下の図は、 Kiro または AI エージェントを使ったフォワードエンジニアリングのスコープを示しています。 Kiro / AI エージェントを使ったフォワードエンジニアリング ステップ 1: マイクロサービス仕様の生成 このステップでは、ビジネスロジックの抽出を入力として、AI エージェントまたは Kiro を使い、各マイクロサービスの詳細な仕様を作成します。Kiro の仕様駆動型のアプローチにより、アーキテクトはマイクロサービスを設計して正式な仕様を作成し、実装を開始する前に、アプリケーションの対象分野の専門家が各仕様を確認して改良することができます。プロジェクト固有のステアリング文書を作成することで、Kiro はインプット (ビジネスロジック、データ分析、非機能要件など) と要件についての理解を深めることができます。このステップでは、トレーサビリティとビジネスルールの包括的な適用範囲を検証する必要があります。これにより、特定されたすべてのビジネスロジックが適切に分析され、関連するマイクロサービス仕様に組み込まれたかどうかを追跡できます。 Kiro にマイクロサービス仕様の生成を依頼するステアリングファイルのサンプルを次に示します。 マイクロサービス仕様を生成するためのステアリングファイルのサンプル 【参考】日本語訳 ## Role: あなたはソフトウェア設計、特にドメイン駆動設計、マイクロサービスアーキテクチャ、システムモダナイゼーションの分野で 20 年以上の経験を持つシニアソフトウェアアーキテクトです。エンタープライズアプリケーションのモノリスからマイクロサービスへのトランスフォーメーションを何十回も成功させてきました。あなたは、境界コンテキストの特定、クリーンなドメインモデルの設計、効果的なサービス境界の構築に関する専門家です。ソフトウェア設計パターン、API 設計、イベント駆動型アーキテクチャ、フロントエンド統合戦略に関する深い知識を有します。 ## Action: … `input/bre_output` フォルダーとサブフォルダー内の提供された HTML ファイルと JSON ファイルを分析して、現在のビジネスロジック、データ構造、および暗黙的なドメインモデルを理解してください。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 `input/bre_output` フォルダーとサブフォルダー内の HTML ファイルと JSON ファイルにあるビジネスロジックに基づいて、主要なビジネスドメイン、サブドメイン、潜在的な境界コンテキストを特定します。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 ドメイン駆動設計の原則を適用して、独自のユビキタス言語、集合ルート、エンティティ、バリューオブジェクト、ドメインイベントを使用して明確な境界のあるコンテキストを定義します。 特定された境界コンテキストに基づいてマイクロサービスアーキテクチャを設計し、各マイクロサービスが単一の責務を担い、独自のデータを管理するようにします。 ステップ 2: ターゲットデータベースの生成 データベースのモダナイゼーションは、メインフレームトランスフォーメーションプロジェクトにおける極めて重要な課題です。レガシーメインフレームデータベースは、IMS/DB や IDMS などの階層型データベースやネットワーク型データベース、または Db2 などのリレーショナルデータベースを使って構成されています。これらのデータベースには、ビジネス上の重要なデータが何十年にもわたって蓄積されていますが、今となっては時代遅れのデータモデルに従って構造化されているものもあります。ターゲットデータベースの生成フェーズでは、これらのレガシーデータ構造を、データの整合性とビジネスルールを維持しながらマイクロサービスアーキテクチャをサポートするモダンなクラウドネイティブなデータベーススキーマに変換します。AWS Transform のデータ分析機能により、レガシーデータベース構造を包括的に理解できます。Kiro は、このデータ分析結果をターゲットアプリケーションの仕様と組み合わせてインプットとして使用し、ターゲットのモダナイズされたデータベースを作成します。 ステップ 3: ソースコード生成と Infrastructure as Code の生成 仕様を検証した後、Kiro は実装フェーズに移行し、本番環境ですぐに使えるマイクロサービスコードと Infrastructure as Code を生成します。実装プロセスは、要件定義、設計、実装タスクという Kiro の 3 フェーズのワークフローに従います。このフェーズでは、Kiro は実装タスクを自律的に実行できます。一方、開発者は生成されたコードのレビュー、フィードバックの提供、要件に対する実装の検証に集中できます。このプロセスにはステアリングファイルが不可欠です。これによって Kiro はプロジェクトの規約、ライブラリ、標準に関する永続的な知識を得ることができ、確立されたアーキテクチャガイドラインやコーディング標準に準拠することができます。この構造化されたアプローチにより、チームは実装戦略を見直し、改良することができます。また、品質保証活動のための包括的なテストケースとテストデータの生成にも役立ちます。 Kiro にマイクロサービスのターゲットソースコードの生成を依頼するステアリングファイルのサンプルを次に示します。 ターゲットソースコードの生成のためのステアリングファイルの例 【参考】日本語訳 ## Action: まず microservices-specs フォルダーから提供されたマイクロサービス仕様を分析し、必要な各マイクロサービス、その責務、データモデル、連携ポイントを特定します。 以下を含む customer-management-service マイクロサービスシステムの全体的なアーキテクチャを設計します。 サービスの境界と責任 データの所有権と共有のアプローチ 通信パターン (同期 vs 非同期) 各コンポーネントの AWS サービスの選択 仕様書に記載されている customer-service マイクロサービスの場合: 適切な Maven/Gradle 構成で Spring Boot プロジェクト構造を作成する データモデルフォルダの下にある顧客の DynamoDB テーブル定義をマッピングするデータモデルを実装する REST のベストプラクティスに従って RESTful API コントローラーを開発する サービス層のビジネスロジックを指定どおりに実装する 適切な例外処理、検証、ロギングを追加する AWS サービスインテグレーション (必要に応じて DynamoDB、SQS、SNS など) を設定する サービスのユニットテストを書く 以下は、マイクロサービスを実装するためのプロンプトとステアリングファイルから Kiro によって生成されたタスクファイルのサンプルです。 マイクロサービスを実装するタスクファイルの例 【参考】日本語訳 [x] 1. 顧客管理サービスのプロジェクト構造を設定する Maven のディレクトリ構成で Spring Boot プロジェクトを作成する マルチモジュールプロジェクト構造 (domain, application, infrastructure, web) を設定する さまざまな環境 (dev, staging, prod) に合わせてアプリケーションプロパティを設定する 重要な依存関係 (Spring Boot, Spring Data, AWS SDK, validation, testing) を追加する _要件: 1.1、2.1_ [x] 2. コアドメインモデルとバリューオブジェクトを実装する [x] 2.1 ドメインロジックによる顧客集約ルートを作成する すべての必須フィールドとビジネスメソッドを含む Customer エンティティを実装する バージョンフィールドによるオプティミスティックロックを追加する ドメイン検証ルールを実装する _必要条件:5.1、5.5_ [x] 2.2 データの一貫性を実現するためのバリューオブジェクトを実装する ID が 9 文字であることのチェックも含めて CustomerID バリューオブジェクトを実装する フォーマット検証と暗号化をサポートする SSN バリューオブジェクトを作成する 電話番号のフォーマット (XXX-XXX-XXXX) のチェックを含む PhoneNumber バリューオブジェクトを作成する 値の範囲が 300 ～ 850 になるチェックを含む FICoScore バリューオブジェクトを作成する _必要条件:5.3_ フェーズ 3: デプロイとテスト 最後のフェーズでは、生成されたマイクロサービスを、さまざまなコンピューティングオプションとストレージオプションを使用して AWS クラウドネイティブアーキテクチャにデプロイします。お客様は、コンピューティングサービスとして Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS Lambda、AWS Fargate の中から選択できます。データベースオプションには、NoSQL ワークロード用の Amazon DynamoDB、リレーショナルデータベース用の Amazon Aurora、またはその他の AWS データベースサービスが含まれます。デプロイでは、AWS CloudFormation、AWS Cloud Development Kit (CDK)、Terraform などの Infrastructure as Code ツールを使って AWS リソースのモデル化とプロビジョニングを行います。 以下は、AWS CloudFormation テンプレートを使って新しいマイクロサービスアーキテクチャを AWS クラウドにデプロイするように生成された Infrastructure as Code のサンプルです。 生成された Infrastructure-as-Code の例 再構想 (reimagine) された新しいアプリケーションは、この新しい AWS クラウドネイティブアーキテクチャでテストされ、すべてのコンポーネントが期待どおりに動作することを検証します。 以下の図は、新しく作り直されたアプリケーションをデプロイするための一般的な AWS クラウドネイティブアーキテクチャを示しています。 新しく reimagine されたアプリケーションのデプロイとテスト Reimagine パターンのための AI 駆動アプローチの主な利点 ディスカバリーと分析の加速 AWS Transform の AI エージェントは、複雑な COBOL コードベースを数時間または数日で分析し、アプリケーションドメインとビジネスロジックパターンを自動的に識別できます。組織はメインフレーム環境全体を分析するか、もしくは、特定のビジネスプロセスを対象として分析するか、選択することができます。 インテリジェントなマイクロサービス設計 AI を活用したアプローチでは、ドメイン駆動設計 (Domain-Driven Design: DDD) の原則を適用して、レガシーアプリケーション内の自然な境界のあるコンテキストを識別します。DDD は、中核となるビジネスドメインの理解、技術チームとビジネスチームの間に共通のユビキタス言語の構築、複雑なドメインを明確に境界付けられたコンテキストに分割することに重点を置いています。 高品質なコード生成 Kiro は、適切な階層型アーキテクチャ、REST API 設計、クラウドネイティブパターンなど、最新の開発標準に従った、本番環境に対応したマイクロサービスを生成します。 Infrastructure as Code このアプローチでは、アプリケーションコードと、マイクロサービスを AWS クラウドにデプロイして実行するために必要なインフラストラクチャ全体の両方が生成されます。さらに、この Infrastructure as Code アプローチは AWS Well-Architected Framework の原則に沿ったものであり、自動化され繰り返し可能なデプロイによって運用上の卓越性を促進し、生成されたすべてのインフラストラクチャコンポーネントにセキュリティ、信頼性、パフォーマンス効率、コスト最適化、ベストプラクティスを一貫して適用できるようにしています。 AWS メインフレームモダナイゼーションの専門知識とパートナーエコシステム メインフレームアプリケーションを reimagine するための AWS のアプローチは、AWS の AI 駆動の機能を活用し、パートナーの専門知識とスケールを補完するものです。AWS は、Global System Integrators (GSI) と専門技術パートナーの専門知識を組み合わせて、メインフレームモダナイゼーションプロジェクトに内在する複雑さに対処する強固なパートナーエコシステムを構築しました。 GSI パートナーは、さまざまな業界の大規模なメインフレームモダナイゼーションで成功を収めていることが実証済です。 AWS の戦略は、データ移行ユーティリティ、テストフレームワーク、言語変換ツールなどの AWS ネイティブ機能を補完する専用のモダナイゼーションツールを提供するテクノロジーパートナーに依存しています。 このような協業アプローチにより、お客様は AWS のクラウドネイティブ機能を活用しながら、複雑なモダナイゼーションの課題に対応する専門知識と実証済の方法論を活用できます。 まとめ AWS がメインフレームモダナイゼーションを再構想 (reimagine) するために進めているのは、お客様のトランスフォーメーションジャーニーを加速させる包括的な AI 駆動のアプローチです。AWS Transform は、レガシーソースコードに対する深い理解と柔軟なコード生成を組み合わせることで、組織がリスクを最小限に抑え、ビジネス価値を最大化しながらメインフレームアプリケーションを変革できるようにします。 メインフレーム向けの AWS Transform と Kiro に関するその他の参考情報 インタラクティブデモを試す AWS Transform for mainframe の詳細 入門ガイドを読む メインフレームから AWS への移行途中の過渡期に於ける両環境併存のための連携アーキテクチャ メインフレームアプリケーションのモダナイゼーションに関する包括的な視点と配置戦略 著者 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Cheryl du Preez Cheryl du Preez は、メインフレームとレガシーモダナイゼーションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、世界中のお客様を対象としたメインフレームのモダナイゼーションとトランスフォーメーションの取り組みにおいて、20 年以上にわたって技術的リーダーシップを発揮してきました。現在の役職では、AWS 独自の方法で生成 AI を活用したメインフレームのモダナイゼーションについて、お客様やパートナーに対して助言を提供しています。 Chris Poole Chris は Senior Partner Solutions Architect であり、メインフレームモダナイゼーションが大好きです! 彼は現在、EMEA 地域の AWS メインフレームパートナー戦略を推進していますが、以前はエッジコンピューティングテクノロジーに取り組む Principal Engineer の称号を持っていました。当時は、コミュニティや開発者支援の取り組みをリードし、クラウドセキュリティ製品のソリューションアーキテクトチームを率いたり、高スループットの金融取引処理システムにおける非同期 API を設計/開発したりしてきました。彼は理論物理学の博士号を取得しています。余暇には、香取神道流の武道やカリ (Kali) 等の格闘技を楽しんでいます。 Rao Panchomarthi グローバルのメインフレームモダナイゼーション組織のリーダー。Rao は、IBM メインフレーム、分散システム、クラウドテクノロジーにまたがる 20 年以上の経験を持つ経験豊富な IT プロフェッショナルです。Rao は大規模なビジネストランスフォーメーションをリードし、メインフレームアプリケーションのクラウドテクノロジーへの移行や、モダナイズするための戦略を策定しています。AWS に入社する前は、JPMorgan Chase のクレジットカード事業でアーキテクチャ責任者を務め、複数のトランスフォーメーションプロジェクトをリードしていました。 Souma Suvra Ghosh Souma は AWS でメインフレームモダナイゼーションを担当する Senior Specialist Solutions Architect です。AWS へのモダナイゼーションに関する複数の記事やソリューションガイドを発表し、AWS re:Invent や AWS Summit などのカンファレンスで発表を行ってきました。現在の役職では、メインフレームとレガシーシステムのモダナイゼーションに AWS のバリュープロポジションと生成 AI 機能を最大限に活用する方法について、お客様やパートナーに助言しています。 Subhajit Maitra Subhajit は AWS の Worldwide Mainframe Partner Solution Architect であり、メインフレームモダナイゼーションコンピテンシープログラムの構築を支援しました。また、IBM MQ 連携に寄与する AWS Mainframe Modernization サービスのビルダーでもあります。彼の専門分野には、メインフレームモダナイゼーション、メッセージ指向ミドルウェア、分散型イベントストリーミングプラットフォーム、マイクロサービスなどがあります。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 8 月 4 日（火）に、半導体業界向けのイベント EDA on the Cloud 2026 – Tokyo を AWS 麻布台オフィスで開催します。EDA ワークロードのクラウド活用に加えて、Cadence AI Super Agent による設計・検証フローや、Anthropic Japan による「半導体のためのフロンティア AI」など、AI 関連のセッションが揃っています。ソニーセミコンダクタソリューションズ株式会社様による「ソニー半導体 EDA 基盤の Cloud Journey」の講演も予定されています。定員 100 名、参加費無料です。ご興味のある方はお早めにご登録ください。 それでは、7 月 20 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース 寄稿：弁護士ドットコムにおける AWS DevOps Agent の活用事例 – インシデント対応の自動化と属人化の解消 弁護士ドットコム株式会社 様は、法律相談ポータル「弁護士ドットコム」や電子契約サービス「クラウドサイン」を運営する企業です。サービスの拡大とともにアラートが増える一方、調査は一部の熟練エンジニアに依存していました。これを解決するために、Datadog Monitor のアラートを起点に AWS DevOps Agent が自動で調査を始める構成を組み、Skills と Jira の MCP で起票までつなげました。その結果、あるレイテンシ障害では、従来 30 分ほどかかっていた根本原因の特定を約 10 分で終えています。今後は、繰り返すアラートへの予防策を提案する Proactive Incident Prevention の活用を本格化させるそうです。 ブログ記事「9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、「書く」から「決める」への転換」を公開 9 社 11 チーム・約 90 名が自社の実課題を持ち込み、 Kiro と Claude Code で AI 駆動開発ライフサイクル（AI-DLC）を 2 日間走り切った合同ワークショップのレポートです。「Kiro は 1 ヶ月と見積もった。私たちは 2 日で 80% 終わった」という声の一方で、生成物の正しさを判断し続ける負荷が人間に集中したという指摘も率直に載っています。満足度は 4.7/5.0、体感の工数削減率は平均 74.0%。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」に、2 日間の学びが凝縮されています。 ブログ記事「22社51名の参加者が2時間で業務アプリを自作し発表 ！Claude ・Kiro実践ワークショップの記録」を公開 22 社 51 名が 2 時間のハンズオンで自分の業務課題を題材にアプリを作り、その場で発表したワークショップの記録です。日本曹達株式会社様の広報課の方が、過去の問い合わせ回答を検索できる農業化学品 FAQ アプリを作られた例が取り上げられています。「このアプリを作ってください」というお題をあえて出さない設計が、満足度 100% につながったようです。社内で同じような会を企画される方のヒントになりそうです。 ブログ記事「【開催報告】AWS Summit Japan 2026 – AWS for Telcom 展示ブース」を公開 通信業界向けの 7 ブースをまとめた開催報告です。株式会社NTTドコモ様は AWS 上の 5G コアを国内初のハイブリッドクラウド構成で商用化し、 Amazon Bedrock AgentCore 上のエージェントと GitOps による構築自動化でリードタイムを 80% 短縮されました。100 万台超の機器を扱うネットワーク保守 AI エージェントでは、障害復旧時間を 50% 以上縮めています。KDDI株式会社様は基地局制御基盤の内製開発に AI-DLC を導入して開発期間を 70% 削減、ソフトバンク株式会社様は Amazon Neptune でネットワークトポロジーを時系列管理する様子を展示されました。 ブログ記事「スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援」を公開 「あの商品どこ？」に新人スタッフが即答できない、という店舗の困りごとをスマートグラスと音声 AI エージェントで解く展示の解説記事です。音声をそのまま受けて音声で返す Amazon Nova 2 Sonic がモデル内で Tool Use まで済ませ、Amazon Bedrock AgentCore Gateway に登録した 5 つの Lambda を MCP 経由で呼び出します。自店舗に在庫がなければ近隣店舗や EC まで自律的に探しにいく挙動が読みどころです。手が塞がる現場での情報アクセスという課題は、製造や物流にもそのまま当てはまります。 ブログ記事「【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫」を公開 複数システムにデータが散らばり、日次レポートの目視確認で異常発見が数日遅れる。そんな物流現場の課題に Amazon Quick で応える展示の紹介です。Quick Automate が業務システムを横断監視して Microsoft Teams へ通知し、Quick Sight で滞留状況を確認、Chat Agent が基幹データと過去報告書をまたいで原因を掘り、Connectors で業者へのメール送信まで完結します。半日かかっていた原因追及が数分になる流れを、4 ステップで追えます。 ブログ記事「AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告」を公開 建設機械 20 台のフリート管理を題材に、同じデータへの 3 つの異常検知アプローチを並べて比べた展示報告です。人手による報告、 Amazon SageMaker AI の古典的な機械学習、そして Amazon Bedrock AgentCore と Strands Agents によるエージェント型。「異常スコアは出るが、なぜ起きたのか、何をすべきかは分からない」という機械学習の限界に対して、対処指示まで含むアラートを返せる差が具体例つきで示されます。機械を止める判断は人間に残す、という線引きの考え方も参考になります。 ブログ記事「AWS Summit Japan 2026 に見る Resilience at AWS」を公開 レジリエンス関連のセッション 4 本とブース展示 6 本のまとめです。生成 AI 視点では、AI 駆動カオスエンジニアリング、AWS DevOps Agent による「調査は AI、判断は人」のインシデント対応、Kiro と AWS Resilience Hub を組み合わせて、マルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで生成するデモが目を引きます。ナレッジを整えたことで DevOps Agent の根本原因到達が 6 分 32 秒から 3 分 38 秒に縮んだ、という実測値も載っています。 ブログ記事「【開催報告】Neuron Community – 2026 Vol.1」を公開 AWS Trainium / Inferentia と AWS Neuron の知見を共有するコミュニティイベントの開催報告です。カラクリ株式会社様は、Amazon EKS 上の Neuron 分散学習プラットフォームと、NKI カーネル開発を自律的に進めるエージェントを発表されました。AWS 側からは、デバイス指定を変えるだけで PyTorch のコードを Trainium で動かせる Native PyTorch support（ベータ）や vLLM on Trainium、Neuron 2.31 の NKI 強化が共有されています。Project Rainier では 140 万個超の Trainium が稼働中とのことです。 ブログ記事「AI エージェントが変える AWS 運用の未来【AWS DevOps Agent & AWS サポート ランチタイムセミナー開催レポート】」を公開 「深夜にアラートが鳴っても調査する人手が足りない」というスタートアップの悩みに向けたランチタイムセミナーのレポートです。Amazon ECS の 500 エラーを題材にした AWS DevOps Agent のデモに加えて、一次調査はエージェント、判断が必要なところは AWS サポートの専門エンジニアへ、という組み合わせ方が解説されています。DevOps Agent からサポートチケットを直接起票できる点と、AWS Business Support+ や AWS Activate クレジットといったコスト面の選択肢も整理されています。 ブログ記事「今月の AWS オブザーバビリティ – 2026年6月」を公開 6 月に発表された Amazon CloudWatch と AI 駆動型オペレーションの新機能のまとめです。OpenTelemetry メトリクスと PromQL クエリの一般提供、Logs Insights への 23 コマンド追加、AWS DevOps Agent のカスタム SRE エージェントと MCP / A2A 対応などが並びます。Amazon EKS 上の AI/ML ワークロードを namespace やチーム単位で GPU コスト配賦するリファレンスアーキテクチャ、Claude Code のトークン消費量を追跡するパターンまでカバーしています。 ブログ記事「AWS Certified Machine Learning Engineer – Associate アップデート (MLA-C02) のお知らせ」を公開 AWS Certified Machine Learning Engineer – Associate が MLA-C02 に更新されます。ドメイン構成は変えずに、基盤モデルのファインチューニングや RAG アーキテクチャの実装、エージェンティック AI、 Amazon Bedrock のカバレッジ、責任ある AI の実践が加わります。ベータ版試験（英語のみ、170 分、85 問、75 USD）の予約は 9 月 1 日開始、現行 MLA-C01 の英語での最終受験日は 9 月 28 日です。日本語はベータ期間中も MLA-C01 で受験でき、全言語対応の標準版は 2027 年初頭の予定です。 ブログ記事「Claude Opus 5 が Kiro で利用可能になりました」を公開 （ changelog ） Kiro の IDE / CLI / Web すべてで Claude Opus 5 が使えるようになりました。時間のかかる作業に強くなり、並列で動かしたエージェントが互いの成果を上書きしてしまうケースが減っています。スタブやプレースホルダを残さずタスクを完走する点、コードレビューで誤検知を抑えつつ実バグを拾う点が Opus 4.8 からの差分です。あわせて、 Kiro で GPT-5.6 が利用可能に なった記事（前号で触れた英語版の日本語訳）も出ています。 サービスアップデート Claude Opus 5 が AWS で利用可能に Anthropic の Claude Opus 5 が AWS で利用可能になりました。数時間から夜通し動き続けるエージェント、コードベースを理解しながら戦略を組み替えるコーディング、長文ドキュメントの推論が強みです。ドキュメント中心の業務で最も伸びが大きいと説明されています。Amazon Bedrock 経由（ゼロデータ保持がデフォルト有効）と Claude Platform on AWS 経由（ゼロデータ保持はリクエストベース）の 2 つから選べます。 Amazon Bedrock AgentCore がトレースとログを単一ロググループにまとめた統合オブザーバビリティを提供 Amazon Bedrock AgentCore が、トレース・プロンプト・構造化ログ・標準出力をエージェントごとの単一の CloudWatch ロググループへ配信するようになりました。これまではトレースが共有の aws/spans、イベントログが別のロググループに分かれており、1 回の呼び出しをデバッグするために複数のロググループを探す必要がありました。エージェント単位で IAM ポリシーとカスタマー管理キーによる暗号化を適用できるようにもなっています。7 月 20 日以降に作ったエージェントはデフォルトで有効、既存分は環境変数と ADOT 0.17.1 以降への更新で移行できます。 Claude Sonnet 5 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock でも Claude Sonnet 5 が使えるようになりました。Claude Opus 4.8 とあわせて、GovCloud (US-West / US-East) の bedrock-runtime と、GovCloud (US-West) の次世代推論エンジン bedrock-mantle の両エンドポイントから呼び出せます。 Amazon SageMaker AI 推論の GPU インスタンスが拡充、G7e が東京リージョンでも利用可能に NVIDIA RTX PRO 6000 Blackwell を最大 8 基積む G7e インスタンスが、Amazon SageMaker AI 推論のアジアパシフィック（東京 / ソウル）、欧州（ロンドン）に広がりました。合計最大 768 GB の GPU メモリで、FP8 なら最大 70B パラメータのモデルをマルチノードなしで載せられます。推論性能は G6e 比で最大 2.3 倍。国内のユーザーに大きめのモデルを低レイテンシーで届けたいときの選択肢になります。同じ週に G7 インスタンス （米国 3 リージョン、G6 比で最大 4.6 倍、7B〜30B 向け）と G6 の AWS GovCloud (US-East) 対応 も発表されています。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポート Amazon SageMaker Unified Studio が Amazon OpenSearch をデータソースとして扱えるようになりました。プロジェクトに接続を追加すると data explorer に OpenSearch のデータが並び、クエリエディタやノートブック、ビジュアル ETL ジョブから Amazon Redshift や Amazon S3 のデータと突き合わせられます。アプリケーションログとトランザクションデータを、ツールを行き来せずに見たいときに便利です。Unified Studio が使えるすべてのリージョンが対象です。 Kiro IDE 1.0.182 と CLI 2.14.0 が公開 Kiro IDE 1.0.182 では、ユーザーレベルのグローバル hooks と検索できるセッション履歴パネルが加わり、企業プロキシ環境での安定性が上がりました。応答が中断したときの自動復帰と、MCP ツールの動的な再読み込みにも対応しています。CLI 2.14.0 では、V2 のカスタムエージェント設定を V2 / V3 共通の形式へ移す /upgrade-agent コマンドが入りました。 Kiro が AWS GovCloud (US) で Opus 4.8 / Sonnet 5 とユーザーアクティビティモニタリングに対応 AWS GovCloud (US) の Kiro IDE / CLI で、Claude Opus 4.8（1M コンテキスト、クレジット倍率 2.2 倍）と Claude Sonnet 5（実験的サポート、同 1.3 倍）が使えるようになりました。あわせて管理者向けに、利用状況ダッシュボードと、クレジットやモデル利用の日次 CSV を自分の S3 バケットへ配信するレポート、任意のプロンプトログが提供されます。データは自社アカウントに残り、S3 のストレージ以外の追加料金はかかりません。 Amazon CloudWatch がコーディングエージェントインサイトを発表 Amazon CloudWatch に、AI コーディングエージェントの利用状況を可視化するコーディングエージェントインサイトが加わりました。Claude apps gateway for AWS と統合されているため、計装なしで Claude Code のテレメトリが集まります。Codex や GitHub Copilot も対象です。トークン支出の傾向を追ってアラートを設定できます。エージェントの導入率とコミットやプルリクエストの速度との相関、費用対効果の高いモデルの見極めにも使えます。中東（UAE / バーレーン）とイスラエル（テルアビブ）以外のすべての商用リージョンで使えます。 AWS Data Exports が Amazon Bedrock の標準化された製品メタデータを提供 AWS Data Exports が、Amazon Bedrock のコストにモデルプロバイダー、モデル名、料金単位、推論タイプ、オンデマンドやバッチといった機能区分を、標準化された属性として付けるようになりました。Bedrock のコストは統一の「Amazon Bedrock」製品ファミリー名にまとまります。CUR 2.0 のメタデータを解析する自作ロジックなしで支出を配賦できます。追加料金なしで、デフォルトで適用されます。 AWS が AI エージェント向けのオープンソースベンチマーク aws-bench を発表 AI エージェントが実際の AWS タスクをどれだけ正確に、どれだけ効率よく片づけられるかを測るオープンソースのベンチマーク aws-bench が、リサーチプレビューで公開されました。テストケースは調査・トラブルシューティング・インフラ作成の 3 領域。自然言語のクエリ、クラウドリソースの状態、正解を組にしてあるので、任意のエージェントやモデルを同じ基準で採点できます。エージェントの実行基盤を自作している方は、改善の物差しとして試してみてはいかがでしょうか。 Amazon Connect のエージェンティック音声が 50 以上の言語に対応、日本語もサポート Amazon Connect のエージェンティック音声が、日本語を含む 50 以上の言語と 100 を超える音声オプションに対応しました。不自然な間を埋める応答ペーシング、同時発話を避けるターンテイキングの改善、速度・音量・感情の制御も入っています。日本語で自然な音声セルフサービスを組みたいコンタクトセンターには、大きな一歩です。 AWS パートナーセントラルのエージェントが資金調達ガイダンスをすべてのプログラムに拡大 AWS パートナーセントラルのエージェントが、すべての資金調達プログラムに対応しました。今回の拡張で戦略的協業契約（SCA）と AWS Growth Initiative（AGI）が加わっています。資格要件や申請プロセスについては、公式ドキュメントに基づく回答が数秒で返ります。適格性の検証、提出書類の要件照合、必要項目が埋まった申請書ドラフトの作成もエージェントが行うため、手入力とチェック漏れを減らせます。 生成 AI を活用したビジネス課題の解決に取り組むお客様を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング / モデルカスタマイズ / モデル活用の 3 コースから選べて、想定コストの半額を上限とした AWS クレジットの付与や技術支援も用意されていますので、ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。 a

本ブログは 2026 年 7 月 20 日に公開された AWS Blog “ Introducing the Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment ” を翻訳したものです。 Amazon GuardDuty の新しい調査エージェント (現在パブリックプレビュー) は、 Amazon Web Services (AWS) 環境全体のセキュリティ検出結果を調査し、調査にかかる時間を数時間から数分に短縮します。 GuardDuty は、AWS アカウントとワークロードを継続的にモニタリングして、不審なアクティビティ、悪意のある可能性のあるアクティビティ、不正な動作を検出するマネージド型の脅威検出サービスです。可視化と修復のために詳細なセキュリティ検出結果を提供します。 単一の不審な検出結果を調査する場合でも、組織全体のセキュリティポスチャを評価する場合でも、調査エージェントはリスクレベル、信頼度スコア、具体的な対応につながる推奨事項を含む構造化された評価を提供します。 セキュリティチームは、セキュリティ検出結果の調査や複数のツールにまたがるデータの関連付けに何時間も費やすことがあります。GuardDuty 調査エージェントはこの関連付けを自動化し、すぐに対応に活かせるインテリジェンスを提供します。この機能は GuardDuty に直接組み込まれており、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、AWS API、または AWS SDK を通じてオンデマンドでアクセスできます。 この記事では、以下の内容を説明します。 GuardDuty コンソールで調査エージェントを有効化する コンソールまたは AWS CLI を使用して最初の調査を作成する AWS MCP サーバーと調査エージェントを組み合わせて、AI 支援型のセキュリティオペレーションを実現する GuardDuty 調査エージェントの主な機能 GuardDuty 調査エージェントは、GuardDuty で既に使い慣れたパターンに沿った API を提供します。完了した各調査は、リスクレベル、信頼度評価、 MITRE ATT&CK® テクニックマッピング、リソースマッピング、優先順位付けされた推奨事項を返します。 コンソールからは、特定の検出結果、アカウント、または組織全体のすべてのアカウントを対象に調査のスコープを設定できます。また、AWS CLI と API では、最大 2,048 文字の自由形式のトリガープロンプトを受け付けます。これにより、調査対象を自然言語で記述し、懸念事項、疑わしい根本原因、調査の優先事項を指定して、エージェントの分析をガイドできます。 調査エージェントの API は、 Agent Toolkit for AWS の一部である公式の AWS MCP サーバー経由でも利用できるため、既存のセキュリティツールチェーンや AI を活用したワークフローに統合できます。エージェントを直接管理したり操作したりする必要はありません。API エンドポイントを呼び出すと、エージェントが検出結果を調査し、証拠を関連付け、複雑な設定を管理する必要なく評価を提供します。 調査エージェントによる検出結果の分析の仕組み 調査を作成すると、エージェントはクロスリージョン推論を使用してスコープに基づいて検出結果を処理し、構造化された出力を生成します。 クロスリージョン推論 – GuardDuty の調査は Cross-Region Inference Service (CRIS) を使用します。CRIS は、お客様の地域内で調査の評価を処理するのに最適な AWS リージョンを選択します。データは調査リクエストが発生したリージョンにのみ保存されます。ただし、調査データと概要結果は、そのリージョン外で処理される場合があります。データは、Amazon が提供する安全なネットワーク上で暗号化されて送信されます。 リクエストがルーティングされる可能性のある推論リージョンの詳細については、 Amazon GuardDuty ユーザーガイド の調査セクションにあるクロスリージョン推論ルーティングテーブルを参照してください。 調査の出力 – 完了した各調査では、以下のインサイトが生成されます。リスクレベル (Info、Low、Medium、High、または Critical)、信頼度 (Unknown、Low、Medium、または High)、概要 (検出結果と主な観察事項の説明)、調査の詳細 (追加のコンテキスト)、推奨アクション (AWS CLI コマンドを含む詳細なアクション) です。 アカウントのスコープ設定 – アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。組織全体などのより広いスコープの場合、アカウント ID は不要です。エージェントは、後述の認可モデルに従ってアクセスを許可されたアカウント内の検出結果のみを調査します。 前提条件 始める前に、以下の前提条件が満たされていることを確認してください。 アカウントで Amazon GuardDuty が有効になっていること サポート対象リージョンの AWS アカウントがあること (「利用可能なリージョンと料金」セクションを参照) 必要な IAM アクセス許可 3 つの新しいアクセス許可が必要です。新しい調査を開始するための guardduty:CreateInvestigation 、結果を取得するための guardduty:GetInvestigation 、特定のディテクターの調査を表示するための guardduty:ListInvestigations です。 IAM ポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:CreateInvestigation", "guardduty:GetInvestigation", "guardduty:ListInvestigations" ], "Resource": "*" } ] } 認可モデル 管理者アカウントは、自身とメンバーアカウントに対して、調査の作成、結果の取得、調査リストの表示を行えます。メンバーアカウントは、自身のアカウントの結果の取得と調査リストの表示のみが可能です。メンバーアカウントは調査を作成できず、他のアカウントや管理者アカウントに属する調査にはアクセスできません。アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。自身のアカウントや組織全体のアカウントを対象とする場合、アカウント ID は不要です。 調査エージェントを有効化して最初の調査を作成する 始める前に、前提条件に記載されている必要な IAM アクセス許可があることを確認してください。 サポート対象のリージョンで AWS マネジメントコンソールを開き、Amazon GuardDuty に移動します ナビゲーションペインで [Investigations] を選択します 図 1: GuardDuty 調査ダッシュボード 調査が有効になっていない場合は、 [Go to Settings] を選択し、 [Enable] を選択して調査を有効にします 図 2: GuardDuty 調査の有効化画面 調査を有効化したら、調査ページに戻ります ナビゲーションペインで [Initiate Investigation] を選択します 図 3: GuardDuty 調査の開始 調査のスコープを選択します GuardDuty Finding ID を入力: 特定の GuardDuty 検出結果を詳しく調査したい場合に使用します AWS Account ID を入力: 特定の AWS アカウントの全体的なセキュリティポスチャを評価したい場合に使用します All accounts : 組織全体のセキュリティ評価や、ラテラルムーブメント (横展開) の可能性を調査する場合に使用します [Initiate investigation] を選択します 図 4: GuardDuty 調査のセットアップ 調査が完了するまで待ちます (プレビュー期間中は、通常アカウントレベルの調査で 2～5 分、特定の検出結果の調査で 10～12 分かかります)。ステータスは自動的に更新されます 調査が完了したら、調査タイトルを選択して評価の全文を表示します 図 5: GuardDuty 調査完了メニュー 調査の評価には、全般情報、調査の概要、マッピング、脅威評価、推奨アクションなど、調査に関する詳細な情報が含まれています。 [General Information] セクションには、調査 ID、ステータス、トリガー元アカウント、作成日時が表示されます。 図 6: 評価の [General Information] セクション [Summary] セクションでは、主な観察事項と検出結果が説明されます。 図 7: 評価の [Summary] セクション [Mapping] セクションには、攻撃手法と影響を受けた AWS リソースが表示されます。 図 8: 評価の [Mapping] セクション (MITRE ATT&CK) [Threat Assessment] セクションには、リスクレベル、信頼度スコア、詳細な脅威分析が表示されます。 図 9: [Threat Assessment] セクション [Recommended Actions] セクションには、優先順位付けされた修復手順が一覧表示されます。 図 10: 評価の [Recommended Actions] セクション 調査は、以下の API エンドポイントを使用して AWS CLI または SDK からも実行できます。 CreateInvestigation – GuardDuty の調査を開始します。セキュリティ検出結果を自動的に分析し、関連するアクティビティを関連付け、アカウントレベルの分析を実行し、推奨される次のステップを含む構造化された調査概要を生成します GetInvestigation – 特定の調査のステータスと結果を取得します。完了時には、エージェントによる評価、関連付けられた証拠、推奨アクションが含まれます ListInvestigations – フィルタリングとページネーションを使って、環境全体の調査を表示します AWS CLI を使用して調査を実行する エージェントは複数のデータソースへのクエリ、サービス間での検出結果の関連付け、AI ベースの分析を実行するため、調査は非同期で行われます。調査を作成した後は、完了するまで定期的にステータスを確認する必要があります。 ステップ 1: ディテクター ID を確認する 各 GuardDuty のデプロイには、アカウントごと、リージョンごとに一意のディテクター ID があり、これによってお客様固有の GuardDuty 設定が識別されます。このディテクター ID はすべての AWS CLI オペレーションで必要になります。特に複数のリージョンで GuardDuty を有効にしている場合は注意が必要です。ディテクター ID は、GuardDuty コンソールの [Settings] で確認するか、リージョンを指定して以下のコマンドを実行することで確認できます。例えば、対象の GuardDuty ディテクターが us-east-1 (バージニア北部) リージョンにある場合は次のように実行します。 aws guardduty list-detectors –-region=us-east-1 想定されるレスポンス: { "DetectorIds": [ "12abc34d567e8fa901bc2d34eexample" ] } 注記: レスポンスの DetectorID の値は、以降のすべてのコマンドで使用します。 同じリージョンでのみ作業する場合は、繰り返しの入力を避けるため、セッションで環境変数を設定することもできます。例えば Linux では次のようにします。 export AWS_DEFAULT_REGION=us-east-1 その他のオペレーティングシステムでの設定方法については、 AWS CLI のドキュメントを参照してください。 ステップ 2: 調査を作成する 以下は、特定の検出結果を調査するコードの例です。 aws guardduty create-investigation us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt "Investigate this finding ID 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6" --trigger-prompt パラメータは、GuardDuty のメタデータには含まれておらず、API 経由でも取得できないコンテキストがある場合に役立ちます。 想定されるレスポンス: { "InvestigationId":"a1b2c3d4-5678-90ab-cdef-ef1234567890" } AWS アカウント全体の検出結果を調査するには、以下の例を使用します。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings in Account 123456789012” 組織全体の検出結果を調査するには、次のようにします。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings across my AWS Organization” ステップ 3: 調査のステータスを確認する 以下のように、 AWS CLI の --query オプションを使用して出力をフィルタリングし、 Status セクションのみを簡潔に表示して、調査のステータスを確認します。 aws guardduty get-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --investigation-id a1b2c3d4-5678-90ab-cdef-ef1234567890 --query 'Investigation.Status' Status フィールドに COMPLETED と表示されるまで、このコマンドを繰り返し実行します。 完了時のレスポンス出力の例: { "Investigation": { "InvestigationId": "a1b2c3d4-5678-90ab-cdef-ef1234567890", "Status": "COMPLETED", "TriggerPrompt": "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012", "TriggeredBy": "123456789012", "RiskLevel": "Critical", "Risk": "Active multi-stage runtime compromise on EKS worker node with root-privileged reverse shell, Docker socket access, malicious file execution, and 500 multi-tactic runtime signals — behavioral evidence is consistent with a genuine intrusion.", "Confidence": "High", "Summary": "{\"keyObservations\":{\"title\":\"...\",\"narrative\":\"...\",\"observations\":[...]},\"countermeasures\":[...],\"threatAssessment\":{...}}", "Cloud": { "Provider": "AWS", "Region": "us-east-1", "Account": "123456789012" }, "Metadata": { "Product": { "Name": "AmazonGuardDuty AI Analyst", "Feature": "Investigation" }, "Version": "1.0.0" }, "StartTime": 1705319400.0, "EndTime": 1705319700.0 } } ステータス値 – RUNNING 、 COMPLETED 、 FAILED 所要時間 – 調査時間は変動することがあります。30 秒ごとにステータスを確認すれば結果を得るのに十分です ステータスが FAILED の場合 – レスポンス内のエラーメッセージを確認し、アクセス許可が認可モデルの要件を満たしていることを確認してください 特定のディテクターのすべての調査を一覧表示するには、以下を実行します。 --max-results オプションは省略可能ですが、返される結果の数を絞り込むのに便利です。 aws guardduty list-investigations –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --max-results=10 手動で調査を実行するだけでなく、API ファーストの設計により、GuardDuty の検出結果をサードパーティのツールに送信するという一般的なお客様のパターンにも対応しています。既存のパイプラインに自動調査を追加できるため、チームは生のアラートではなく、コンテキストが付加され優先順位付けされたインテリジェンスを受け取れます。 GuardDuty の検出結果を Amazon EventBridge 経由でセキュリティ情報およびイベント管理 (SIEM) プラットフォームにルーティングし、アナリストが各アラートを手動で調査しているお客様を考えてみましょう。調査エージェントを使用すると、パイプラインに AWS Lambda 関数を組み込み、検出結果 ID を指定して CreateInvestigation を呼び出し、完了を待ってから、コンテキストが付加された結果 (リスクレベル、信頼度スコア、MITRE ATT&CK マッピング、推奨アクション) を元の検出結果とともに SIEM に転送できます。Critical の検出結果は、さらなる分析や自動化のために、お客様のインシデント対応キューに直接ルーティングされます。信頼度の高い低リスクの検出結果は、自動的にクローズしたり、週次レビュー用にまとめたりできます。これにより、アナリストは繰り返しのログ関連付け作業から解放され、評価の検証と確認済みの脅威への対応に時間を使えるようになります。 このパターンは、API や EventBridge のメッセージングを使用するようにカスタマイズできる SIEM、チケットシステム、自動化プラットフォームで機能します。調査エージェントは、パイプラインの最終地点としてではなく、処理ステップとして組み込むことができます。 このエージェントは、GuardDuty の検出結果を調査するようにファインチューニングされており、 AWS Security Agent や AWS DevOps Agent といった他の AWS フロンティアエージェントとは異なるものです。調査エージェントのスコープは、GuardDuty の検出結果に特化した分析を提供することに絞られています。 AWS MCP サーバーとの統合 Model Context Protocol (MCP) は、AI アシスタントが外部のデータソースやツールに安全に接続できるようにするオープン標準です。AWS MCP サーバーはこの標準を AWS のサービス向けに実装しているため、Kiro、Anthropic の Claude、その他の MCP 対応クライアントなどのツールを使用して、AI を活用したワークフローに GuardDuty の調査を組み込めます。 AWS MCP サーバーを設定する MCP クライアントが AWS MCP サーバー に接続するように設定します 自然言語を使用して調査を呼び出します (例: 「アカウント 123456789012 の最近の Unauthorized Access の検出結果を調査して」 ) MCP クライアントを通じて返される調査結果を確認します。結果は、使用するモデルやエージェント、設定、AI の非決定的な性質によって異なる場合があります 結果を既存のエージェント自動化に統合するか、検出結果に基づいて手動で対応します。 その他の使用例 「本番アカウントの最新の重要度が高い検出結果を調査して」 「アカウント 987654321098 の検出結果 ID abc123 の調査を作成し、何が起きたかを要約して」 「過去 24 時間の調査を一覧表示し、人によるレビューが必要なものにフラグを付けて」 調査エージェントと AWS Security Incident Response の関係 re:Invent 2024 で、AWS は AWS Security Incident Response (AWS SIR) を発表しました。これは、セキュリティインシデントへの準備、対応、復旧を迅速に行うためのマネージドサービスです。AWS SIR と GuardDuty 調査エージェントは、セキュリティワークフローの異なる段階に対応しています。GuardDuty 調査エージェントは、オンデマンドの評価機能を提供します。特定の検出結果、アカウントのセキュリティポスチャ、または組織全体のセキュリティポスチャについてより深いコンテキストが必要な場合に、調査を作成すると、リスクレベル、信頼度スコア、MITRE ATT&CK® テクニックマッピング、具体的な対応につながる推奨事項を含む構造化された評価が得られます。セキュリティアナリストはこれを使用して、GuardDuty が検出した内容の範囲と重大度をすばやく把握できます。 AWS SIR で AWS がサポートするケースを作成すると、SIR の調査エージェントがアクティブになり、AWS Security Incident Response のエンジニアと並行して証拠を収集し、数分以内に調査の概要を提供します。AWS SIR は、封じ込めと復旧を調整するために AI を活用した自動化と人間の専門知識の両方が必要となる、進行中のセキュリティイベントに特化して構築されています。 セキュリティチームはこれらの機能を活用することで、GuardDuty 調査エージェントによるオンデマンドでの検出結果の評価と優先順位付け、裏付けとなる証拠を添えた確認済みの問題の関係者へのエスカレーション、さらに追加のサポートが必要な場合には AWS がサポートするケースの作成または更新による AWS SIR チームの迅速な関与を実現できます。 利用可能なリージョンと料金 GuardDuty 調査エージェントのパブリックプレビューは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、アジアパシフィック (東京) を含む 10 の AWS リージョンで利用できます。 パブリックプレビュー期間中は、調査エージェントを無料で利用できます。使用量は、アカウントあたり 1 日 10 件の調査に制限されており、プレビュー期間中のアカウントあたりの累計上限は 100 件です。失敗した調査はこれらのクォータにはカウントされません。 今すぐ検出結果の調査を始める Amazon GuardDuty 調査エージェントは、調査にかかる時間を数時間から数分に短縮し、セキュリティチームが手動での関連付け作業ではなく、確認済みのセキュリティイベントに集中できるようにします。 開始手順 GuardDuty コンソールで調査エージェントを有効化する 最近の GuardDuty の検出結果を使用して最初の調査を作成する リスクレベルや推奨される次のステップを含む、構造化された評価を確認する AWS MCP サーバーを使用している組織では、お好みの AI アシスタントで自然言語を使って調査を呼び出すこともできます。 詳細情報 Amazon GuardDuty 調査エージェントのドキュメント – 設定と使用方法の詳細なガイダンス GuardDuty の IAM アクセス許可リファレンス – 調査オペレーションに必要なアクセス許可 Amazon EventBridge ユーザーガイド – 調査イベントを下流のシステムにルーティングする方法 MITRE ATT&CK® フレームワーク – 入門リソース AWS Security Incident Response – AWS セキュリティブログの記事 AWS Activation Days – AWS を使用して成果を達成するための具体的なガイダンスを提供する、今後開催される無料イベントに関する情報 Allan Holmes Allan は、セキュリティとコンプライアンス、ネットワーキング、DevOps にわたる 20 年以上の経験を持ち、現在はセキュリティスペシャリストとして活躍しています。この経験により、クラウドセキュリティの課題を包括的な視点で捉えることができます。AWS、ISC2、CompTIA の複数の技術認定資格と MBA を保有しており、深い技術的専門知識とビジネス戦略の橋渡しを行っています。仕事以外では、熱心なガーデナーであり電子工作愛好家でもあり、革新的なテクノロジーを実際に手を動かして探求することを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 7 月 14 日に公開された AWS Blog “ Security Hub adds AI workload protection and multicloud support for Microsoft Azure ” を翻訳したものです。 AWS Security Hub は、クラウドをまたぐフルスタックのエンタープライズセキュリティの基盤です。セキュリティ運用を一元化し、生のシグナルを優先順位付けされたインサイトに変換することで、チームはツールをつなぎ合わせる作業ではなく、実際のリスク管理に時間を使えるようになります。本日 (2026 年 7 月 14 日)、この基盤は、お客様から最も多くの要望をいただいた 2 つの方向に拡張されます。AI ワークロード専用の保護機能と、Microsoft Azure を対象としたセキュリティモニタリングの追加です。どちらも、優れたセキュリティツールは連携することでより賢くなるべきである、という大きな構想に向けた一歩です。 これらの拡張はお客様の声から直接生まれたものであり、セキュリティの過去ではなく、これから向かう先を反映しています。従来のセキュリティツールが約束していたのは、すべてを 1 つのビューに集約する場所でした。しかし、検出結果を集めること自体は難しい部分ではありません。難しいのは、それらを理解し、関連付け、攻撃者よりも先に行動すること、しかも現在の攻撃のスピードに合わせてそれを行うことです。これから成功するセキュリティプログラムは、最も多くのダッシュボードを持つものではなく、環境全体を見渡し、迅速に対応できるものです。それこそが AWS の目指すものであり、今回のリリースはその道のりの一歩です。 Microsoft Azure に対応するマルチクラウドセキュリティ管理 さまざまな業界のお客様が、AWS でのセキュリティ運用の中核として Security Hub を活用しています。その多くは何年も前から複数のクラウドを運用しており、Security Hub でセキュリティ環境の残りの領域もカバーしてほしいという明確な要望をいただいていました。本日、Microsoft Azure に対応し、他のクラウドにも順次対応していきます。 Security Hub は今回、Azure Virtual Machines、コンテナイメージ、Function Apps、アイデンティティを検出し、設定不備、インターネットへの露出、ソフトウェアの脆弱性を評価できるようになりました。また、CIS Microsoft Azure Foundations Benchmark に基づくポスチャチェックも行います。Azure の検出結果は、同じ検出結果フォーマット、自動化、対応ワークフローを使用して AWS の検出結果と並べて優先順位付けされるため、チームはセキュリティ環境全体にわたるリスクを 1 つの視点で把握しながら作業できます。Azure リソースの料金は、同等の AWS リソースと同じ料金体系で、追加料金はありません。また、Azure の監視には別枠で 30 日間の無料トライアルが用意されています。詳細については、 What’s New の投稿 を参照してください。 実は、AWS 以外への拡張はこれが初めてではありません。今年の初めに、 Security Hub Extended を発表し、9 つのセキュリティカテゴリにわたるベストインクラスのパートナーソリューションを、既にお使いのエクスペリエンスに統合しました。これらのパートナーソリューションは、あらゆるクラウド、オンプレミス、企業が事業を展開するあらゆる場所で、エンドポイント、アイデンティティ、E メール、ブラウザ、データを保護します。Extended は既に、マルチクラウドとマルチワークロードに向けた最初の一歩となっていました。本日、AWS 独自のネイティブ機能がカバーする範囲を広げ、この 2 つの取り組みは今後歩調を合わせて進化していきます。 AI ワークロードの保護 私がお話しするどのお客様も、AI を活用した構築を進めています。Amazon Bedrock での生成 AI、Amazon SageMaker でのモデルトレーニング、Bedrock AgentCore を通じてワークフローをオーケストレーションするエージェントなどです。これらのワークロードは、多くのセキュリティプログラムが追いつけないスピードで本番環境に到達しています。しかも、モデルの呼び出しをモニタリングしたり、エージェントの動作を追跡したり、組織全体にどのような AI 資産が存在するかを把握したりするツールを、チームがまだ持っていないことも少なくありません。あるセキュリティリーダーは、基盤モデルを何千回も呼び出していた侵害されたサービスアカウントに気づけたのは、経理部門が請求書に疑問を持ったからだと話してくれました。会計レビューを通じてセキュリティインシデントが発見されたのです。可視性のギャップは現実に存在し、既に高い代償を生んでいます。 この夏、AWS は 3 つのリリースでこのギャップを埋め始めます。2 つは脅威検出と調査のための GuardDuty の機能、3 つ目は新しい Security Hub AI inventory (AI インベントリ) です。 GuardDuty AI Protection (一般提供開始) Amazon GuardDuty AI Protection は、Amazon Bedrock と SageMaker 専用に構築された脅威検出を提供します。異常なモデル呼び出し、コストハーベスティング (盗んだ認証情報を悪用して推論を実行させ、お客様に費用を負担させる攻撃)、そして Amazon Bedrock Guardrails との統合によるプロンプトインジェクションの試みを検出します。 コストハーベスティングは急増しています。認証情報が侵害されると、攻撃者はそれを使って基盤モデルを呼び出すケースが増えています。推論は高コストで需要も高いため、盗んだアクセス権は、インフラストラクチャを一切デプロイすることなく、そのまま価値に変換できてしまうのです。GuardDuty は AWS CloudTrail のデータイベントを分析し、大規模な環境で正常な呼び出しがどのようなものかを学習し、侵害や悪用を示す逸脱を検出します。これは AWS の規模だからこそ実現できる検出です。何が正常かを知るには、何百万ものワークロードにわたるシグナルを見る必要があるからです。GuardDuty AI Protection は、30 日間の無料トライアル付きで、すべての GuardDuty のお客様が利用できるようになりました。 GuardDuty AI-powered investigations (プレビュー) AI を活用した調査 (AI-powered investigations) は、アラート疲れを引き起こし、対応を遅らせる要因となっていた手動の調査作業を引き受けます。この機能は、GuardDuty の検出結果とその周辺のアカウントを自動的に分析し、真の脅威と無害なアクティビティを切り分けます。 検出結果のコンテキスト、過去 90 日間の関連アクティビティ、影響を受けたリソース、脅威インジケーターを調査し、ナレッジグラフと脅威インテリジェンスを使用して、これまで数時間かかっていた作業を数分で完了します。各調査では、信頼度スコアを伴う判定評価、MITRE ATT&CK® 分類、裏付けとなる証拠、そして抑制、封じ込め、または修復のための明確な推奨事項が得られます。チームは、単一のアカウントでも AWS Organizations の組織全体でも、本物の脅威に集中でき、平均解決時間が短縮されます。GuardDuty AI-powered investigations は、10 の AWS リージョンでプレビューとして利用可能です。 Security Hub AI inventory (一般提供開始) 存在を知らないものを保護することはできません。Security Hub では、AI 資産とそのセキュリティポスチャを組織全体で継続的に最新の状態で確認できる AI インベントリ が利用できるようになりました。チームがモデル、エージェント、パイプラインをデプロイしても、セキュリティ部門は何が動いているのかを把握できないことが多く、それらの資産をアクティブな脅威や設定不備と関連付けなければ、何を最初に保護すべきかを判断するのは困難です。 Security Hub AI inventory は、AWS 環境全体の AI ワークロードを 2 つの方法で検出してカタログ化します。マネージドサービスについては、Amazon Bedrock、SageMaker、Bedrock AgentCore のリソースを AWS Config 経由でインベントリ化します。セルフホストおよび外部のワークロードについては、ランタイム分析を通じて Amazon EC2、Amazon ECS、Amazon EKS 上で実行されているモデルを発見し、ワークロードが呼び出している外部モデルのエンドポイントを特定します。各資産を、コンピューティング、ネットワーキング、IAM ロール、データストアなど、その基盤となるインフラストラクチャにマッピングし、GuardDuty の検出結果などのセキュリティシグナルと関連付けます。そのため、GuardDuty AI Protection が異常な呼び出しを検出すると、AI インベントリはどのインフラストラクチャが関与しているか、何がそれに接続されているか、優先順位のどこに位置するかを即時に表示します。 AI 資産は急速に増えていきます。ある開発者が概念実証のために Amazon Bedrock エージェントを立ち上げます。データサイエンスチームが内部テスト用に SageMaker エンドポイントを構築します。別のチームは AWS Lambda 関数を通じて外部モデル API を組み込みます。これが数百、数千のアカウントで起これば、すぐに把握しきれなくなります。AI インベントリは、組織内のすべてのアカウントを横断したビューを提供します。この機能は Security Hub エッセンシャルプランで追加料金なしで利用できます。 フルスタックセキュリティへの新たなアプローチ これらのリリースには、注目に値する共通点があります。AI 保護を別製品として調達する必要はなく、Azure 用に別の運用体制を立ち上げる必要もありません。既に運用している Security Hub にそれらを追加するだけで、優先順位付けされたリスクのビューに表示されます。この同じ考え方を、セキュリティ環境の残りの領域にまで広げるのが Security Hub Extended です。 Security Hub Extended には現在、9 つのカテゴリにわたる 21 のキュレーションされたパートナーが参加しています。 7AI 、 Britive 、 CrowdStrike 、 Idira (CyberArk) 、 Cyera 、 Island 、 LayerX 、 Native Security 、 Noma 、 Okta 、 Oligo 、 Opti 、 Proofpoint 、 SailPoint 、 SentinelOne 、 Splunk 、 Sublime 、 Upwind 、 Varonis 、 Zenity 、 Zscaler です。これらは、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用にわたるベストインクラスのソリューションです。どのパートナーも、無条件に選ばれたわけではありません。それぞれが、エンタープライズセキュリティの向かう先についての共通のビジョンにコミットし、AWS とともにそれを構築するために投資することで、その地位を獲得しました。キュレーションこそが重要なのです。選ばれないという結果があり得るからこそ、推奨には意味があります。 Extended のビジネス面のメリットは今すぐ得られます。従量制料金、AWS への一本化された請求、EDP (Enterprise Discount Program) の適用対象であること、長期契約が不要であることです。しかし、AWS が最も力を入れている取り組みはその先にあり、調達の話ではまったくありません。参加しているすべてのソリューションの検出結果は Open Cybersecurity Schema Framework (OCSF) 形式で出力され、Security Hub に集約されます。AWS は、それらすべてを横断する単一の相関分析の実現に取り組んでいます。これにより、エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルが、3 つのばらばらのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスとして統合されます。また、サブスクリプション登録から価値を実感するまでのデプロイとオンボーディングの手間を減らす取り組みも進めています。さらに、パートナーの検出結果が互いを強化し合う仕組みを構築しており、既に信頼しているベストインクラスのツールが、単独で使うとき以上の価値を発揮するようになります。これが、AWS が投資している差別化された未来であり、お客様の次の要望に導かれながら、オープンに構築を進めています。Extended の詳細については、 What’s New の投稿 を参照してください。 さらなる前進へ 一歩引いて見れば、全体像は明確です。Security Hub は、Azure を皮切りにクラウドプロバイダーを横断して拡大していきます。専用の AI 保護とインベントリにより、ワークロードタイプを横断します。そして、Extended とキュレーションされたパートナーを通じて、セキュリティカテゴリを横断します。AWS のセキュリティ検出結果を整理する手段として始まったものが、より多くの企業がフルスタックセキュリティを運用する方法へと発展しました。 検出と可視性が土台となります。その上に AWS が構築するのは、信頼するすべてのソースからのシグナルをつなぎ、より迅速な対応を支援するセキュリティエクスペリエンスです。まだ Day 1 であり、お客様の環境と直面する脅威が変化し続ける中、Security Hub は拡張を続けていきます。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年間にわたり AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、ビジネス開発、ソフトウェア開発のさまざまな役割を務めてきました。アリゾナ大学でコンピュータエンジニアリングの理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

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 を並行開発しても全体の整合性が保たれます。 著者について 守田 凜々佳 (Morita Ririka) Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心に、AWS をご利用になるお客様を技術面でサポートしています。好きなサービスは Amazon Quick です。週末はヴァイオリンの演奏を楽しんでいます。

本稿は、弁護士ドットコム株式会社 CTO 田中 慎司 氏、プロダクト開発本部 Platform & Reliability Engineering 部 (以下、PRE 部) 部長 熊谷 晃 氏、同 PRE 部 原口 慎太郎 氏による寄稿です。 はじめに 弁護士ドットコム株式会社は、『「プロフェッショナル・テック」で、次の常識をつくる。』というミッションのもと、国内最大級の法律相談ポータルサイト「 弁護士ドットコム 」や契約マネジメントプラットフォーム「 クラウドサイン 」などを運営しています。また、最近ではリーガル特化型 AI エージェント「 Legal Brain エージェント 」を開発し、AI を活用したリーガルサービスの進化にも取り組んでいます。PRE 部は、これらのサービスを支えるインフラの信頼性と運用効率の向上を担っています。本記事では、 AWS DevOps Agent を用いたインシデント対応の自動化と運用組織のあり方の見直しを進めている事例を紹介します。 導入のきっかけ 弁護士ドットコムでは、事業の拡大に伴いサービス数・トラフィックの増加が続いており、PRE 部として対応するアラートの量と種類も年々増えています。量の増加に加え、調査対応が一部の熟練エンジニアに依存していたため、属人化の解消も急務でした。そのため、検知から原因特定までを人手を介さずに、または非常に少ない労力で完結できれば、この課題を根本的に解消できると考えていました。 AWS DevOps Agent との出会い こうした課題の解決策として、GA 前から DevOps Agent のトライアルを開始しました。 DevOps Agent は MCP による機能拡張が可能です。連携可能なツールとして Datadog、GitHub、Slack といったサードパーティ製のツールもあります。Datadog Monitor のアラートをトリガーに DevOps Agent が自動起動し、検知から根本原因の特定までを人手を介さずに完結できるところが、弁護士ドットコムが抱えていた課題の構造そのものに合致するものでした。トライアル段階から本番環境に組み込むという判断にあたっては、「新しい技術に早期に触れ、自社の運用にフィットするかを実環境で見極める」という方針のもと、本番環境の監視データに DevOps Agent を接続する構成で試行運用を開始しました。DevOps Agent は参照権限のみで動作する点も、本番環境への適用を安心して行えるポイントでした。 AWS DevOps Agent について AWS DevOps Agent は、2026年3月31日に一般提供 (GA) が開始された「AI ベースの運用支援エージェント」で、マルチアカウント対応やオンプレミス、他社クラウド、サードパーティなどとの連携が可能です。詳細は AWS DevOps Agent の公式ページ をご覧ください。弁護士ドットコムでは、既に Datadog を中心とした監視基盤を構築していたため、MCP を活用することで既存の環境を変更することなく組み込むことができました。 導入後のインパクトと効果 ここからは、DevOps Agent がトライアル運用中に実際のインシデントで威力を発揮した事例を紹介します。 事象の発生 2026年3月のある日、弁護士ドットコムが運用するサービスの一つでパフォーマンスが大幅に劣化しているという報告が上がりました。「リクエスト数は増えていないのに、レイテンシだけが悪化している」という状態です。試行運用中だった DevOps Agent は、Datadog Monitor のアラート発火をトリガーに自動起動し、人手を介さず即座に調査を開始してくれました。 約10分で根本原因を特定 以下は、DevOps Agent が Slack に投稿した調査のタイムラインです。 経過時間 DevOps Agent のアクション 0 分 調査開始 (Investigation started) 約 3 分 レイテンシ劣化の定量分析完了。平均レイテンシが 0.67s から 1.85s に悪化 (2.8 倍)、P99 は 2.10s から 9.00s に悪化 (4.3 倍) していることを特定。同時にリクエスト数の安定も確認し、トラフィック起因ではないことを確認 約 4 分 ECS へのデプロイ履歴との相関分析を実施。直前のデプロイ完了時刻がパフォーマンス劣化開始時刻と完全に一致することを特定 約 8 分 APM トレースを分析し、該当デプロイで導入された機能がキャッシュなしの DB クエリを繰り返し呼び出す N+1 問題を引き起こしていることを特定。ページあたり20回以上の追加クエリが発生していた 約 9 分 ホスト単位の影響分析を実施。3秒超のトレースが特定の Spot インスタンスに集中しており、N+1 問題の影響が CPU 競合によって増幅されていたことを解明 約 10 分 調査完了 (Investigation complete)。根本原因、影響範囲、定量データを含む調査レポートを Slack に投稿 調査開始から根本原因の特定まで、わずか約10分でした。調査完了後は Jira に Issue も自動登録され、Slack の通知とあわせて迅速な対応が可能になりました。その結果、本事例では迅速なロールバックで影響を早期に収束させました。 DevOps Agent の分析の深さ DevOps Agent が出力した調査レポートの特筆すべき点は、その分析の深さです。まず、インシデント前後のリクエスト数を比較し、パフォーマンス劣化がトラフィック起因ではないことを数値で裏付けました。次に、ECS へのデプロイ履歴を確認し、直前のデプロイとの時間的相関を特定しました。さらに APM トレースを掘り下げ、該当デプロイで導入されたコードの N+1 問題まで踏み込んで原因を特定しています。全体では数倍のレイテンシ劣化でしたが、特定のタスクでは15倍まで増幅されていることを発見し、テイルレイテンシ (P90/P99) が不均衡に悪化した理由まで説明しました。 以下は、対象サービスのレイテンシをベースラインとインシデント時で統計値ごとに比較した表です。 統計値 ベースライン インシデント時 劣化倍率 Average 0.67s 1.85s 2.8x P90 1.10s 4.70s 4.3x P99 2.10s 9.00s 4.3x 特定 ECS タスク 0.50s 7.50s 15.0x 以下は、DevOps Agent が Slack 上で根本原因を特定した調査ログの一例です。 対応の加速 DevOps Agent が約10分で根本原因を特定した調査結果を開発チームに共有したところ、並行して調査していた開発チームの経験豊富なエンジニアの調査結果とも一致し、ロールバック判断を迅速に行うことができました。従来であれば、アラートを認知してから原因を特定し対応するまでの一連のプロセスに、慣れたエンジニアでも30分程度はかかっており、さらにこのプロセスを実行できるエンジニアは限られていました。DevOps Agent はその作業を短時間で完了し、誰でも読めるレポートとして出力してくれるため、対応時間を大幅に短縮することができました。 導入によって確認できた効果 トライアル運用開始以降、パイプライン全体で次の効果を確認できています。 チケット管理 アラートのたびに誰かが調査を開始し、あとから Jira に起票する運用では、対応の遅れや起票漏れが起きることがありました。今回、自動調査と自動起票をセットにしたことで、調査が完了した事象は必ず Jira 上に登録されるようになっています。これにより、対応漏れの懸念が解消されました。 属人化の排除 調査結果が構造化されたレポートとして Slack に投稿されるようになりました。これにより、アプリケーションの内部構造に詳しくないエンジニアでも、レポートを読んで対応方針を判断できるようになっています。人手による調査では、担当者の経験や知識によって分析の範囲にばらつきが生じてしまいますが、DevOps Agent はメトリクス、APM トレース、デプロイ履歴、ホスト単位の影響分析を毎回網羅的に実施するため、見落としのリスクが低減されています。 コード修正が必要なアラートでは、エージェント対応仕様により「何をどのリポジトリでどう直すか」が構造化されて届くため、仕様を確認して承認するだけで修正フローに進めます。調査結果の解釈から仕様の説明までを DevOps Agent に任せられることで、対応完了までのリードタイムも短縮されています。 効果を支えるアーキテクチャと運用フローの整備 ここまで紹介した効果は、既存の対応フローに合わせて DevOps Agent を組み込んだ以下の構成によって実現しています。 全体構成 DevOps Agent は外部からの通知を webhook で受けることができます。この機能を活用し、Datadog Monitor のアラートをトリガーとして DevOps Agent を自動起動する構成を採用しています。 監視基盤: Datadog トリガー: Datadog Monitor のアラート エージェント: AWS DevOps Agent 通知: Slack 連携による調査結果のリアルタイム配信 チケット管理: Jira 監視・調査対象: AWS 上で稼働するアプリケーションサービス Jira 連携 調査の自動化だけでは、アラート対応の記録や追跡は別途人手が必要になります。Skills は、DevOps Agent に社内の運用手順や判断基準を教え込むための拡張機能です。弁護士ドットコムでは、この Skills と Jira の MCP を組み合わせ、調査完了後に Jira へ Issue を自動登録する仕組みを構築しました。 調査完了時に Slack への投稿と Jira の Issue を自動作成する Skills を実装しています。 作成した Skills 例 弁護士ドットコムでは、Jira で Issue を登録するために以下の Skills を作成しました。 工夫した点としては、調査は完了しているのに Jira Issue が作成されないケースがあったため、Skills の終了条件に「既存 Issue の確認、または新規 Issue 作成の完了」を明示しました。Skills は今後、運用しながら最適化していく予定です。Skills には、調査の前後で踏むべき手順と「調査完了」の定義を記述しています。骨子は次のとおりです。 調査開始前: 関連するランブック (手順書) や過去のインシデント報告、サービスの所有者情報といった背景情報を収集する 調査実施時: 収集した知見とリアルタイムのテレメトリ・ログを照らし合わせ、過去の根本原因を参照して重複調査を避ける。ランブックがある場合は独自判断より優先する 調査完了時: まず既存チケットを検索し、見つからなければ新規 Issue を作成する。Issue には検出内容 (トリガー)、特定した根本原因または仮説、実施した対応、今後の推奨アクション、参照したリンク、重要度を日本語で記載する 終了条件: これらの Issue 作成 (または既存チケットの確認) が完了するまで、調査を「完了」と宣言させない データフロー ポイントは、Datadog Monitor のアラート発火から DevOps Agent の調査完了まで、エンジニアの介入なしに自動で進行する点です。アラート発生から調査結果の配信までのデータフローは以下のとおりです。 エンジニアが最初に目にするのは、Slack に投稿された調査完了レポートです。同時に Jira 上にも対応用の Issue が起票されているため、調査結果の共有とアラート管理を別作業として行う必要がありません。従来は「アラートに気づく → 誰かが調査を始める → 原因を特定する → チケットを起票する」という人手に依存したフローでしたが、DevOps Agent の導入により「アラート発火 → 自動調査 → 原因特定済みのレポートが届く → Jira に Issue が用意される」というフローに移行を進めています。 また、DevOps Agent に設定した IAM の権限に基づき Datadog のデータだけでなく、Amazon ECS のデプロイ履歴やタスク状態、Amazon CloudWatch のメトリクスなど、AWS リソースの情報も横断的に分析します。これにより、「いつデプロイされた何が原因か」まで踏み込んだ根本原因分析が可能になっています。 既存の修正フローとの組み合わせ 弁護士ドットコムでは、DevOps Agent を既存の修正フローと組み合わせて運用しています。 役割 担当 初動調査、根本原因分析 AWS DevOps Agent アラートのチケット起票・管理 AWS DevOps Agent コード・設定変更の仕様策定 AWS DevOps Agent 修正、PR 作成 既存の修正フロー (コーディングエージェント) DevOps Agent が「何が起きて、なぜ起きたか」を素早く明らかにし、Jira 上の Issue として記録を残すことで、調査結果の共有とアラート管理を同時に進められます。恒久対応が必要な場合は、DevOps Agent が出力する「エージェント対応仕様」を活用します。これは、コードまたは設定の変更に関する推奨事項を、コーディングエージェントに直接渡せる形式でまとめた構造化ドキュメントです。変更に必要なコンテキストが自動で揃うため、エンジニアは仕様を確認しコーディングエージェントに渡すだけで、迅速に修正に着手できます。これにより、「検知 → 原因特定 → チケット起票 → 仕様確認 → コード修正」までの一連の対応を、エンジニアがゼロから状況を説明し直すことなく進められるようになりました。 今後の展望 予防的改善の自動化 (Proactive Incident Prevention の活用) DevOps Agent はインシデント発生時の調査だけでなく、運用全体を改善するための「予防」機能も備えています。弁護士ドットコムで運用を始めると1週間ほどで、何度も繰り返されるアラートに対する予防策が提示されました。提案はオブザーバビリティ、インフラストラクチャ、ガバナンス、コード最適化の4カテゴリに分類されて届くため、優先順位を決めて対応することが可能になります。 現在はインシデント発生時の調査自動化を中心に活用していますが、今後はこの Proactive Incident Prevention 機能の活用を本格化させたいと考えています。この機能は、過去のインシデント調査をもとに「同じ種類の障害を防ぐにはどうすればよいか」を提案してくれるものです。 インシデント発生時にはすでにエージェント対応仕様で修正着手を加速している一方、予防提案と仕様生成が組み合わされれば、「検知 → 原因特定 → 改善提案 → コード修正」のサイクルを障害の前にも回せる可能性があります。 トポロジーによるインフラとアプリの可視化 弁護士ドットコムでは、長年運用してきたアプリケーションの内部構造の理解が属人化の一因になっています。「トポロジー」機能によってリソース間の依存関係が自動的に可視化されれば、インシデント調査時だけでなく、日常の運用においてもシステム全体の理解が深まります。PRE 部のメンバーからも、トポロジーによって担当外サービスへの理解が進んだという声が上がっています。 まとめ 今回の DevOps Agent の導入は、弁護士ドットコムにおける AI 活用の軸を、プロダクトから開発・運用プロセスそのものへと広げる取り組みと位置づけています。アラート発生からアラート管理・修正の仕様化までを一つのパイプラインとして実現した点も、運用面での大きな変化です。DevOps Agent に「調査・起票・修正仕様の整理」を任せ、エンジニアは「仕様の確認と判断・修正の承認」に集中する環境に大きく前進したと考えています。 正確性と信頼性が強く求められるリーガルテック領域において、運用の信頼性を AI エージェントとともに高次元で両立させることは、ユーザーがサービスを安心して使い続けられる環境を提供し続けるための至上命題です。同様の課題を抱えるチーム、および AI エージェントを運用領域に組み込むことを検討されている技術責任者の皆様にとって、本記事が一つの参考となれば幸いです。 執筆者 田中 慎司 弁護士ドットコム株式会社 執行役員 CTO NTT 研究所、はてな CTO、メルカリ (US, UK含む) VP を経て、2024 年より弁護士ドットコム CTO。エンジニア組織を活性化させ、一人一人のエンジニアのポテンシャルを生かせる組織にアップデート中。 AI 駆動開発を始めとする、昨今のLLMの進化と応用の可能性、その基礎となるニューラルネットワークの面白さにどハマり中。 熊谷 晃 弁護士ドットコム株式会社 Platform & Reliability Engineering部 部長 / Head of AI CoE 2023 年 12 月より弁護士ドットコム株式会社にて、SRE と Platform Engineering チームを束ねる部門長として活動。また、2026 年 5 月からは、新たに AI CoE を設立し、全社 AX の推進も担っている。 原口 慎太郎 弁護士ドットコム株式会社 Platform & Reliability Engineering 部 / AI CoE 2023 年 4 月より弁護士ドットコム株式会社にて SRE として業務に従事。プロジェクトマネージャーの経験を活かし、エンジニアリングに閉じない、組織横断の信頼性向上に取り組んでいます。最近は AI CoE としても活動中。モータースポーツが好きで、とくに F1 が大好き。

本記事は「 GPT‑5.6 is now available in Kiro 」を翻訳したものです。 Kiro で初めて OpenAI のモデルが利用可能になりました。あわせてこのローンチは Kiro の 1 周年でもあります。2025 年 7 月 14 日のパブリックプレビュー以降、Kiro は仕様駆動の IDE から IDE / CLI / Web にまたがるエージェンティック開発プラットフォームへ成長してきました。 本日（2026 年 7 月 14 日）より GPT-5.6 の Sol / Terra / Luna が Kiro の IDE / CLI / Web が利用可能になりました。性能とコストのカーブ上でそれぞれ異なるポイントにチューニングされた 3 段構成です。 モデルの選択肢が増える GPT-5.6 の設計思想は「タスクが求める以上のコストを知性に払う必要はない」というシンプルなものです。Sol / Terra / Luna でそのトレードオフを直接コントロールできます。 GPT-5.6 Sol (フラッグシップ) : Coding Agent Index 80、Terminal-Bench 2.1 88.8% で新たな SOTA。いずれも Claude Fable 5 を上回りつつ、出力トークンは半分未満・所要時間も半分未満。spec 駆動の実装、長期にわたるリファクタ、複雑なターミナル作業といった最難関の多段タスク向け GPT-5.6 Terra (バランス型) : Coding Agent Index 77.4 で Claude Fable 5 の 77.2 をわずかに上回り、コストは大幅に低い。日常のエージェンティック作業にフラッグシップ価格を払わずに済む GPT-5.6 Luna (最もコスト効率が高い) : Coding Agent Index で Claude Opus 4.8 を上回る (74.6 vs 72.5)、コストは Sol の約 1/4。より多くの実行・タスク・スループットを回せる 長時間のエージェンティック作業向けの設計 IDE / CLI / Web を通じて、GPT-5.6 は監督なしでより長く走り、自身のツール利用をより効率的に管理します。ツールを協調させ中間結果を処理する軽量なプログラムを自分で書いて実行できるため、往復回数が減り、無駄なトークンが削られ、少ない指示で複雑なタスクを完了できます。 IDE の 仕様駆動ワークフロー ではドリフトの少ない高忠実度な実装につながり、CLI / Web ではブラウジング・ターミナル操作・複数ファイルのリファクタといった多段タスクが行き止まりに陥りにくく、より確実に完走します。 提供状況 Kiro Pro / Pro+ / Pro Max / Power の顧客向けに、 実験的サポート として段階的にロールアウト 対象リージョンは AWS US-East-1 (北部バージニア) と AWS Europe (フランクフルト)、クロスリージョン推論に対応 3 モデルすべて 272K のコンテキストウィンドウ クレジット倍率: Sol 2.4x / Terra 1.2x / Luna 0.6x 注意: これらのモデルは隠れた chain-of-thought による推論を使うため、内部の推論ステップは表示されず最終出力のみが見えます。これは期待される挙動で、出力品質には影響しません IDE / CLI を再起動すると最新の利用可能モデルを確認できます。 Web ユーザー はブラウザをリロードするとモデルセレクタに Sol / Terra / Luna が表示されます

本記事は「 Claude Opus 5 is now available in Kiro 」を翻訳したものです。 Kiro の IDE / CLI / Web すべてで Claude Opus 5 が本日（2026 年 7 月 24 日）から利用可能になりました。Opus 4.8 からの意味のある進化として、時間のかかる作業に強くなり、並列エージェントの協調が改善され、長いセッションにおけるコストとレイテンシをより細かく扱える新しいコントロールが備わっています。 コーディングと知識労働で最高水準 Opus 5 は最も難しいエージェンティックなタスクのための働き手です。複数ファイルにまたがる機能追加、大規模リファクタリング、エンドツーエンドの機能開発に優れ、スタブやプレースホルダを残さずタスクを完遂します。 Kiro においては、IDE の仕様駆動ワークフローがドリフトの少ない高い忠実度で走り、多段のタスクがより少ない監督で確実に完了することを意味します。コードレビューでは 1 パスあたりの実バグ検出率が高く false positive が低く、effort 設定を下げても精度を保つため、コミット時の高速レビューと後段の精査の両方に有用です。Opus 5 は自身の作業を検証し、成功するまで慎重に反復します。 Deepak Singh (VP of Agentic AI, AWS) のコメント 「Opus 5 は長時間・多段の作業向けに作られた強力なエージェンティックコーディングモデルであるため、Kiro で提供することにした。コードベースを深く理解し、複雑なタスクを通して文脈を保持し、機能開発やバグ修正における要件の詰めを Opus 4.8 より効果的に行います。開発者がどう革新していくかを楽しみにしています。」 マルチエージェントの協調も大きく向上しています。エージェント同士が互いの作業を上書きしてしまうケースが減り、writer-verifier パターンをより有効に使えます。Kiro の CLI や IDE で並列エージェントを動かしているなら、まず試すべきモデルです。 セーフガードについて Opus 5 はサイバーセキュリティ関連のセーフガードを強化して提供されます。分類器はソースコードの脆弱性発見は許可しますが、バイナリベースの脆弱性スキャン、ペネトレーションテスト、エクスプロイト生成はブロックします。Anthropic のデータでは大半のセッションは影響を受けません。善意のタスクで false positive に当たった場合は、Kiro 内で別のモデルに切り替えてください。 提供状況 Kiro Pro / Pro+ / Pro Max / Power の顧客向けに、 実験的サポート として段階的にロールアウト 対象リージョンは us-east-1 (IAD) と eu-central-1 (FRA)、クロスリージョン推論に対応 1M のフルコンテキストウィンドウ、クレジット倍率は 2.2x Kiro をダウンロード するか、IDE / CLI を再起動して最新の利用可能モデルを確認してください。 Web ユーザー はブラウザをリロードするとモデルセレクタに Claude Opus 5 が表示されます

こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。  

みなさん、こんにちは。AWS Japan ソリューションアーキテクトの瀧澤ロナンです。 スマートファクトリーが進展し、製造現場でのOT とクラウドを連携する事例が最近増えています。こうしたアーキテクチャ変更は効率化を促進する一方、システム間の接続やデータ流通の拡大に伴い、考慮すべきセキュリティ境界も増えます。そのため、OT側とクラウド側のそれぞれについて、リスクに応じたセキュリティ要件を明確にすることが重要です。 この課題に対応する上で重要な標準が、 ISA/IEC 62443 です。ISA/IEC 62443は、製造、エネルギー、公共インフラなどで利用される産業用オートメーションおよび制御システム（IACS）のサイバーセキュリティに関する国際規格シリーズであり、製造現場のシステム全体にわたるリスク管理とセキュリティ対策の枠組みを提供しています。本記事では、製造業のお客様が OT をクラウドに接続する際に特に重要となるISA/IEC 62443 の様々な概念を、AWS サービスを使ってどのように実現するのかをご紹介します。お客様は、AWS サービスを活用した製造現場向けのクラウドアーキテクチャを構成することで、ISA/IEC 62443 に沿ったクラウド側のセキュリティ対策を実装できます。 なお、本記事では、ISA/IEC 62443 でのOT とクラウドの接続に関係するゾーンとコンジット、7つの基礎的要件（FR）、可用性を考慮した設計、および関係者間の責任分担を取り上げ、シリーズ全体を解説するものではありません。ISA/IEC 62443 でのリスク評価、セキュリティレベル、個別のシステム要件、セキュリティライフサイクルなどは本記事の対象外であり、詳細については同シリーズの各規格をご確認ください。 AWS における ISA/IEC 62443 のゾーンとコンジット ISA/IEC 62443 における重要な概念の一つが、ゾーンとコンジットです。ゾーンとコンジットとはISA/IEC 62443でのシステム全体をセキュリティ要件に基づいて分割する考え方です。こちらの図ではAWS上のゾーンとコンジットの設計例を表しています。 ISA/IEC 62443 に基づくシステム設計では、共通のセキュリティ要件を持つシステム部分をグループ化し、グループごとに必要なセキュリティ境界を定義します。このグループを「ゾーン（Zone）」と言い、ISA/IEC 62443は、システム部分を具体的にどのゾーンへ分割するかを固定的に規定しておらず、製造事業者はシステムの要件に応じてどのシステム部分を含めるかを決定します。AWSクラウドに繋いでいる製造現場ではPLC やセンサーを含む制御ゾーン、データヒストリアンや生産実行システム（ MES ）を含む製造運用ゾーン、AWS IoT Core によるクラウド側の取り込みゾーン、 Amazon S3 と Amazon Athena による分析・保存ゾーンに分けることができます。ここでいうクラウド側のゾーンは、必ずしも VPC やサブネットと一致するものではなく、共通のセキュリティ要件を持つ AWS リソースをまとめた論理的な境界です。 続いてゾーン間の制御された通信経路を「コンジット（Conduit）」と呼びます。 AWS Site-to-Site VPN や AWS Direct Connect などの通信経路そのものがコンジットになるのではなく、通信経路と、その経路に適用する認証、暗号化、アクセス制御などを合わせてコンジットとして扱います。AWSクラウドにコンジットを設計する際は、例えばAWS IoT Core が入るOT側とクラウド側の取り込みゾーンの間に制限のある通信経路設けることができます。具体的な制限としてAWS IoT Core にMQTT over TLSを使用して通信を暗号化、X.509証明書による相互認証、及びAWS IoTポリシーによるMQTTトピックへのPublish操作の制限などを組み合わせることによってクラウドに適切なコンジットが設計できます。また、インターネット経由のアウトバウンド接続を許容しないシステム要件や、帯域、遅延、可用性などの要件がある場合には、暗号化を利用したAWS Site-to-Site VPN や AWS Direct Connectをコンジットの伝送手段として選択できます。 AWS Network Firewall も複数のネットワークや VPC を横断する集中検査がセキュリティ要件で必要とされた場合にコンジット内に導入できます。 最後にOT とIT／クラウドの接続ではDemilitarized Zone(DMZ)という独立したゾーンを配置することも一般的に行われ、両者を直接接続せずに必要最小限の通信だけをコンジットとして中継するネットワーク領域を立てることができます。AWS では、 AWS IoT Greengrass を実行するエッジゲートウェイをDMZ に配置して、OTとクラウド間の境界ゲートウェイとして構成することができます。 AWS で ISA/IEC 62443 の7つの基礎的要件を充足する 7つの基礎的要件（FR：Foundational Requirement）も、ISA/IEC 62443 に欠かせない概念です。ISA/IEC 62443での7つの基礎的要件は、製造現場のシステムが満たすべき技術的特性をまとめたものです。次の表は、7つの基礎的要件と、それらを支援する代表的なAWS サービスを対応付ける一例です。これらのサービスは ISA/IEC 62443 との適合に必須ではなく、また利用するだけで ISA/IEC 62443への適合が達成されるわけでもありません。システムが該当する要件を満たしているかどうかを判断し、実証する責任は、製造事業者にあります。設計が基礎的要件を満たしているのかは、実際の製造現場システムを確認して評価する必要があります。 FR 要件の概要 FR を支援する代表的なAWSの機能 FR1 – 識別と認証管理 （Identification and Authentication Control） 利用者（人、ソフトウェアプロセス、機器）を正しく識別・認証する。 AWS IAM 、AWS IoT Core（デバイスごとの X.509 証明書）、 AWS Private CA 、 IAM Identity Center。 FR2 – 利用管理（Use Control） 利用者が許可された操作のみを実行するよう強制し、その実行を監視する（最小権限）。 AWS IoT Core の IoT ポリシーと MQTT トピック、IAM ポリシー／SCP、セッション制御、 AWS CloudTrail （監査）。 FR3 – システム整合性（System Integrity） 状態を意図した範囲内に保ち、改ざんや意図しない遷移を防ぐ。 AWS Systems Manager （構成・パッチの完全性）、 Amazon Inspector 、AWS IoT Device Defender、AWS Signer（エッジ／クラウドにデプロイするコードの署名）。 FR4 – データ機密性（Data Confidentiality） 通信中および保存時のデータの秘密性を保護する。 MQTTS（相互 TLS）など通信中の暗号化、 AWS KMS （鍵管理）、Amazon S3 のサーバー側暗号化。プライベート接続が必要な場合はAWS Site-to-Site VPN、または暗号化の構成を追加した AWS Direct Connect。 FR5 – データフロー制限（Restricted Data Flow） ゾーンとコンジットでセグメント化し、不要なトラフィックを防ぐ。 AWS IoT Core の IoT ポリシーと MQTT トピック。プライベート接続や集中検査が必要な場合は、 Amazon VPC 、セキュリティグループ、 AWS PrivateLink 、AWS Network Firewall。 FR6 – イベントへの適時対応（Timely Response to Events） 事象を検知・振り分け・トリアージし、証拠を保全して、対応を推進する（手順化、自動化）。 AWS IoT Device Defender、AWS IoT Core のログ、 Amazon GuardDuty （AWS 環境の脅威検知）、 AWS Security Hub （セキュリティ検出結果の管理）、 Amazon CloudWatch （監査）、保護されたログストレージと組み合わせた AWS CloudTrail（証拠保全）。完全な対応には、引き続き人による手順とオーナーシップが必要。 FR7 – 可用性（Resource Availability） 必須サービスの可用性を維持し、障害後の復旧を可能にする。 障害発生時の復旧に使用：AWS IoT Greengrass のローカル処理とバッファリング、AWS IoT Core や Amazon S3 などのマネージドサービス、必要に応じた接続経路の冗長化。 AWS Backup とAmazon S3 Object Lock は障害発生の回復時間に使用。 AWS における OT 可用性優先の設計 クラウドに接続した製造現場でISA/IEC 62443を実現する際、OTでの可用性優先も抑えておく必要があります。IT と OT は両方ともサイバーセキュリティの優先順位を整理するために、CIA三原則（機密性・完全性・可用性）の考え方を用いますが、それぞれの優先順位は異なります。IT では一般に機密性を最優先するのに対し、OT では可用性を最優先する場合が多く、その理由は制御の停止が、生産、安全、環境に影響を及ぼす可能性があるからです。OT では主に可用性を優先するため、クラウド接続が失われてもプラントは稼働を継続しなければならないという設計が多く見られます。 AWS Well-Architected の「 Modern Industrial Data Technology レンズ 」も、この可用性を重視した考え方に対応しています。「Modern Industrial Data Technology レンズ」のレジリエンスのベストプラクティス項目 MIDAREL02-BP01 では、クラウド接続が失われても重要な生産活動を継続できるよう、ローカル処理、データのバッファリング、自動復旧を求めています。 AWS IoT Greengrass は、この設計の実現に役立つサービスの一つであり、クラウドとの接続が失われた場合も、エッジでローカル処理を継続できます。データをローカルにバッファリングし、接続回復後に対応する AWSサービスへ転送するには、AWS IoT Greengrass の Stream Manager コンポーネントを使用し、ストレージ容量、保持期間、転送先などを要件に応じて構成します。 ISA/IEC 62443 と AWS における責任のマッピング 最後にISA/IEC 62443 における重要な概念はロールに基づく責任分担です。本規格シリーズでは、責任分担は役割により振り分けられ、各役割の責任と担当範囲はゾーンと違い固定的に定められています。ISA/IEC 62443 では、製造現場のセキュリティを扱う際の 4 つの役割として、資産保有者（Asset Owner）、構築サービスプロバイダー（Integration Service Provider）、保全サービスプロバイダー（Maintenance Service Provider）、製品サプライヤー（Product Supplier）を定めています。資産保有者はシステムを所有・運用し、主要な責任を担います。構築サービスプロバイダーはソリューションを設計・構築し、保全サービスプロバイダーは導入後の保守を担い、製品サプライヤーは機器や製品を提供します。これらの役割は製造現場の長期的サイバーセキュリティ維持全体に関わり、資産保有者が要件とリスクを評価し、構築サービスプロバイダーが実装し、保全サービスプロバイダーが運用・保守するという役割を果たします。 一方でISA/IEC 62443 の各役割と、AWS とお客様の間の AWS 責任共有モデル は、異なる責任分担を表しているため、1 対 1 で対応付けることはできません。AWS責任共有モデルは、セキュリティに関する責任を AWS とお客様の二者つの領域に分担するモデルです。AWSの責任領域は、AWS サービスを稼働させるインフラストラクチャを含む「クラウドのセキュリティ（security of the cloud）」に責任を負います。お客様の領域ではAWS上で使用するAWSサービスの選択と設定に加え、データ、アプリケーション、ID、アクセス権限などを管理する責任を負います。このように、ISA/IEC 62443の責任分担とAWS 責任共有モデルは異なるため、製造現場がAWSを利用する際にはどの領域が責任担当になるのは明確ではありません。この責任分担の明確化に役立つのが、先ほど紹介したAWS Well-Architected の「Modern Industrial Data Technology レンズ」です。このレンズでは、AWS 責任共有モデルを前提に、クラウド、IT、OT の各ステークホルダーの責務を分け、ワークロードに合わせた責任分担を定義することを推奨しています。このレンズを活用することで、AWS 責任共有モデルを土台としながら製造現場に応じてクラウド、IT、OT に関わる各責任者の担当範囲を具体的に定義することができ、責任分担を明確化することができます。 まとめ 本記事では、ISA/IEC 62443 の主要な概念を用いて、OT とクラウドを接続する際に保護すべき対象と必要となるセキュリティ対策を整理しました。そのうちクラウドに接続された領域における技術的対策と実装はAWSのサービスにより実現することができます。AWSサービスは、ゾーンとコンジットの設計に加え、7つの基礎的要件（FR1〜FR7）に関連するクラウド側の技術的対策や、可用性を重視した現場とクラウドの接続設計を支援します。ISA/IEC 62443 に基づいてAWS サービスを適切に活用することで、OTセキュリティ上のリスクを低減しながらクラウドを導入し、製造現場のデジタル変革を進めることができます。実際の検討を始める際は、まず対象システムの範囲、資産、データフローを可視化し、リスク評価に基づいてゾーン、コンジット、セキュリティ要件、および関係者間の責任分担を定義することをお勧めします。そのうえで、要件に適した AWS サービスと構成を選択し、設計した対策が期待どおりに機能することを検証すれば、OTセキュリティ上のリスクを管理しながら、製造現場におけるクラウド活用を進めることができます。 執筆者について 瀧澤ロナン / Ronan Takizawa 2026 年 4 月入社のソリューションアーキテクト ISA/IEC 62443 の全資格（Fundamentals, Risk Assessment, Design, Maintenance, Expert）を保有 お客様のOT セキュリティとクラウド活用の支援を目指している

はじめに 2026 年 6 月 25 日(木)、26 日(金)の 2 日間にわたって幕張メッセで開催された AWS Summit Japan 2026 では、AWS Expo の Industry Zone に「AWS for Telecom」として通信業界に関する展示ブースを出展しました。 本ブログでは、株式会社NTTドコモ、KDDI株式会社、ソフトバンク株式会社の各社と共に展示した全 7 ブースの内容をご紹介します。通信領域では NW 設計・構築から運用保守まで、非通信領域ではスマートシティやコンタクトセンターの領域で Agentic AI が通信業界をどう変えつつあるのか を、各社の最新の取り組みからご覧いただけます。 展示一覧 カテゴリ ブース ID 出展社 テーマ 通信領域 A063 株式会社NTTドコモ Agentic AI で AWS 上に 5G コア構築・運用開始 A064 KDDI株式会社 AI 駆動開発で加速する RAN 自動制御と品質改善 A067 株式会社NTTドコモ ネットワーク保守 AI エージェント A068 ソフトバンク株式会社 Amazon Neptune で実現する NW トポロジー可視化 A069 AWS エージェンティック AI が実現する自律運用 非通信領域 A065 KDDI株式会社 KDDI が創る、未来のスマートシティ A066 AWS AI で変革する通信業界の顧客体験 A063：Agentic AI で AWS 上に 5G コア構築・運用開始（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは AWS 上に 5G コアを構築し、国内初となるハイブリッドクラウド環境での商用サービスを開始しました。 この AWS 上の 5G コア構築は、 世界初となる Agentic AI と GitOps を組み合わせた設計・構築自動化 によって実現されています。膨大な過去コンフィグやドキュメントの確認、相互依存する複数コンフィグ間の整合性担保、手動作業によるデプロイ完了までの長期間化の課題がありましたが、AI エージェントが自律的にドキュメントを参照しながら設定ファイルを自動生成し、Git を介した CI/CD パイプラインで自動デプロイする仕組みへと変革することで、従来から 80% のリードタイム短縮と自動化による品質向上をを実現しました。 本展示では、この取り組みの概要や効果、技術要素をご紹介しました。 ポイント： 国内初：AWS 上での 5G コア商用構築・運用開始 世界初：AI × GitOps による 5G コアの設計・構築自動化 Amazon Bedrock AgentCore 上のオーケストレータエージェントが複数の専門 AI エージェントを統括 A064：AI 駆動開発で加速する RAN 自動制御と品質改善（KDDI株式会社） ＊資料ダウンロード 説明 | デモ画面抜粋 KDDI は、無線ネットワーク（RAN）の自動制御に向けて、O-RAN 標準インタフェースに準拠した基地局制御の共通基盤（SMO: Service Management and Orchestration）と、その上で動作するネットワーク制御アプリ（rApp）を AWS 上で内製開発しています。その開発において、 AWS が提唱する AI-DLC（AI-Driven Development Life Cycle）を導入 しました。 AWS が公開している AI-DLC ワークフロー（ aidlc-workflows ）をそのまま使うのではなく、社内のガイドラインやセキュリティ要件に合わせてカスタマイズしています。具体的には、開発スコープ・技術制約・質問事項を整理して議論のたたき台を作る事前フェーズの追加や、社内ルール対応のための Claude Code スキル化などを実施しました。 AI-DLC を取り入れた結果、要件定義からデプロイまでの開発期間を 70％ 削減しました。 この取り組みで開発した新 rApp により、 基地局パラメータの全国展開期間を約 50% 短縮 しています。 この展示内容については、 KDDI Tech note でも紹介されています。 ポイント： AI-DLC は導入して終わりではなく、社内要件に合わせて継続的にカスタマイズ コード生成だけでなく設計・レビュー・ドキュメントまで、開発ライフサイクル全体への AI 適用 要件定義からデプロイまでの開発期間を 70% 削減、パラメータ全国展開期間も約 50% 短縮 A067：ネットワーク保守 AI エージェント（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは、RAN からコアネットワークまで 世界最大級の 100 万台超の通信機器データを分析し、 ネットワークの保守運用を効率化する AI エージェントの商用利用を開始 しました。 本展示では、AI が自律的に異常を検知し、複雑な障害の原因特定から復旧手順の提案を行うまでの一連の動作をご紹介しました。本技術により 障害復旧時間を 50% 以上短縮 し、通信インフラの安定稼働および早期の異常復旧に貢献することで、お客様の通信をつなぎ続けます。 ポイント： 100 万台超の通信機器データをリアルタイム分析 異常検知 → 原因特定 → 復旧手順提案まで自律的に実行 障害復旧時間 50% 以上短縮を商用環境で実現 A068：Amazon Neptune で実現する NW トポロジー可視化（ソフトバンク株式会社） ＊資料配布はございません ソフトバンクは、ネットワークにおける障害検知から復旧までのプロセスを運用者の手を介さず自動で完結させるクローズドループの取り組みを紹介しました。また、この取組みのさらなる拡張のため、 Amazon Neptune を用いたトポロジーの時系列化 のアプローチを紹介しました。 即時性の高いトポロジー把握はネットワーク運用に有用ですが、ネットワークは計画作業に伴う変動に加え、障害起因の突発的な変動も発生します。そのため、設計情報や config 等の静的データに加え、実際のネットワークの状態変化を示す動的データを継続的に収集し、トポロジー情報へ反映することも重要です。トポロジーの時系列情報を扱うことができれば、障害調査の際にリアルタイムの状態だけでなく障害前後のトポロジー情報を原因の特定や迂回可否判断に活用できます。 ポイント： 静的データ＋ 動的データを取り込み Digital Twin と実ネットワークとの同期精度を向上 Amazon Neptune によるグラフデータベースでトポロジーを時系列管理 クローズドループをさらに拡張し、状態追従性、判断根拠の鮮度、判断の迅速性を向上 A069：通信ネットワーク運用の未来 — エージェンティック AI が実現する自律運用（AWS） ＊ 資料ダウンロード エージェンティック AI が通信事業者のネットワーク運用を自律的に監視・分析・実行し、 リアクティブからプロアクティブへ 変革するオペレーションセンターのデモを展示しました。すべて Amazon Bedrock AgentCore 上のマルチエージェントで実現し、専門エージェントが協調して RAN〜Transport〜Core の E2E 運用を担います。デモ全体のコンセプトは、 AI が分析・事項を行い、人間は戦略的な意思決定に集中 することです。 本展示では、来場者の関心に応じて4つのデモをご覧いただきました。 ① データ統合基盤の構築 ：4つのソースに分散したデータを AWS Glue で正規化・時刻同期・トポロジー相関付けし、Amazon DynamoDB・Amazon Timestream・Amazon Neptune・Amazon Bedrock Knowledge Bases に格納。エージェントが自律判断できる土台を整えます。 ② 障害の自動検知・復旧 ：バックホール回線の物理故障をアラームスパイクから検知し、グラフ解析で真因と巻き添えを切り分け。バックアップルート起動から故障機器の交換手配まで、人手の判断を待たずに数分で完結します。 ③ 予測に基づく最適化 ：Amazon SageMaker が大規模イベント時の需要急増を事前に予測し、サービス・インフラ・トランスポートの3層にまたがる最適化戦略を自動立案。人間の承認後にエージェントが並列実行します。 ④ 顧客別のプロアクティブ対応 ：障害の影響を SLA やビジネスインパクトで把握し、影響の大きいお客様を優先。代替経路への自動切替と、状況に応じたパーソナライズ通知の自動生成までを実行します。 いずれも最終判断は人間が行う Human in the Loop を前提とし、受動的な運用から AI 主導のプロアクティブな運用への変革をご体感いただきました。 ポイント： Amazon Bedrock AgentCore 上のマルチエージェントが、データ統合基盤から障害復旧・予測最適化・顧客対応までを自律実行 障害検知から復旧までを数分で完結し、需要急増は事前に予測して予防（リアクティブからプロアクティブへ） 重要な実行判断は人間が担う Human in the Loop——「AI が分析・実行、人間は戦略に集中」 A065：KDDI が創る、未来のスマートシティ（KDDI株式会社） ＊資料配布はございません KDDI は「つなぐチカラ」で、都市の価値を最大化するスマートシティを推進しています。「100年先の心豊かなくらしのための実験場」を掲げる TAKANAWA GATEWAY CITY では、JR東日本と共創し、都市OS「TAKANAWA GATEWAY URBAN OS」を核としたサービスを展開しています。 本展示では、この都市OS 上で動く 2 つのサービスをご紹介しました。 来街者向け：TAKANAWA GATEWAY CITY アプリ 都市OS のリアルタイムデータを活用し、街で働くワーカーや来街者に、街の中での“快適さ”を提供するアプリです。駅改札やオフィス入館ゲートとの連動で来街タイミングを捉えたレコメンドを実現し、Amazon Bedrock でコンテンツ訴求文章を自動生成しています。 事業者向け：「データダッシュボード」で街の状況を可視化するサービス 街の有事（防災・警備）と平時（マーケティング・イベント計画）を同一機能で可視化・分析するダッシュボードです。3D 人流シミュレーションやリアルタイム可視化に加え、Amazon Bedrock による AI 分析でイベントの成果や改善策を把握できます。 ポイント： JR東日本との共創による都市型デジタルツイン URBAN OS を核としたリアルタイムデータ連携 来街者と事業者それぞれに最適化された体験の提供 A066：AI で変革する通信業界の顧客体験 — Amazon Connect で実現する自律的な顧客支援（AWS） ＊ 資料ダウンロード 通信業界の顧客サポートを、AI エージェントで リアクティブからプロアクティブへ 、そしてコ ストセンターと捉えられがちなコンタクトセンターを収益に貢献するバリューセンターへ変革 するソリューションを、コンタクトセンターとデバイスの両面から実現する 2 部構成のデモでご紹介しました。 前半：コンタクトセンターの自律型顧客応対エージェント（日本語デモ） Amazon Connect 上の AI エージェントが、携帯電話料金の問い合わせを 日本語 で自律対応する様子をご覧いただきました。意図認識から本人確認、請求明細の取得、最適なプランの提案、プラン変更の実行まで、 Amazon Bedrock AgentCore Gateway（MCP） で業務システムと連携し、回答だけでなく手続きまでを一気通貫で完結します。人手が必要な場面では会話の文脈を引き継いで有人対応へシームレスにつなぎ、AI が担当者を支援します。 後半：Agentic AI で実現するコネクテッドデバイスケア デバイスを起点に、問題が起きる前に対応する体験もご覧いただきました。お客様の許可のもと、デバイス上の SDK が多数の診断テストでバッテリー劣化などの予兆を検知し、デバイス上で動く Agentic AI の音声エージェント（ Amazon Nova Sonic ）がプロアクティブに連絡してその場で解決します。解決しない場合も文脈を引き継いだまま有人対応へつなぐため、お客様が同じ説明を繰り返す必要はありません。海外の通信事業者での導入実績をもとにした発展形で、課題解決を起点に最適な料金プランや端末下取りといった次の提案（＝「ケアをコマースへ」）にもつなげられます。 ポイント： 前半：Amazon Connect の AI エージェントが日本語で自律対応し、Amazon Bedrock AgentCore Gateway（MCP）連携で手続きの実行まで完結（必要時は文脈を保ったまま有人へ） 後半：予測 AI と Amazon Nova Sonic による、デバイス起点のプロアクティブなケア リアクティブからプロアクティブへ、コンタクトセンターを収益に貢献するバリューセンターへ（＝「ケアをコマースへ」） まとめ 今回の AWS Summit Japan 2026 AWS Expo「AWS for Telecom」展示では、通信業界における Agentic AI の活用が、ネットワークの設計・構築から運用保守、顧客体験、さらにはスマートシティまで、幅広い領域で商用レベルで活用されていることをお伝えしました。 AWS は今後も通信業界の皆さまと共に、ネットワークの自律化と新たなサービス創出に向けた取り組みを加速してまいります。 著者 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト 小林 新一 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト

本ブログは、2026 年 7 月 14 日に Vandit Kothari によって執筆された「 Updates to AWS Certified Machine Learning Engineer – Associate (MLA-C02) 」を翻訳したものです。 近日公開 : AWS Certified Machine Learning Engineer – Associate アップデート (MLA-C02) AWS 認定は、AWS Certified Machine Learning Engineer – Associate を更新します。ベータ版試験の受験予約は、2026 年 9 月 1 日より開始されます (試験は英語のみ)。現在のバージョンの試験 (MLA-C01) を英語で受験できる最終日は 2026 年 9 月 28 日です。現在のバージョンの試験 (MLA-C01) は、ベータ期間中も日本語、韓国語、簡体字中国語で引き続き受験可能です。 機械学習 (ML) エンジニアの役割は進化しています。今日の ML エンジニアの役割は、モデルの構築とデプロイだけではありません。生成 AI ソリューションの実装、基盤モデルや大規模言語モデル (LLM) の活用、エージェンティック AIワークフローを編成し、AIを大規模に運用します。この進化に対応するため、更新された試験 (MLA-C02) では、従来の ML エンジニアリングに加えて、生成 AI、エージェンティック AI、基盤モデル / LLM ワークロードが含まれます。この認定は、Amazon SageMaker AI、Amazon Bedrock、その他のサービスを使用して、AWS 上で ML および生成 AI ソリューションを構築、デプロイ、保守、監視する能力を検証します。 この認定の対象者 更新された AWS Certified Machine Learning Engineer – Associate は、本番環境で ML および生成 AI ソリューションを構築・運用する専門家を対象としています。対象ロールは以下の通りです。 エンドツーエンドの ML ライフサイクル管理を担当する ML エンジニアおよび MLOps エンジニア 基盤モデルおよび生成 AI アプリケーションを運用する LLM 運用エンジニア ML データパイプラインを構築・管理するデータエンジニア ML / 生成 AI 機能をアプリケーションに統合するソフトウェア開発者 ML エンジニアリングの役割に移行するデータサイエンティスト ML システムを設計する ML アーキテクトおよびソリューションアーキテクト 推奨される経験: Amazon SageMaker AI、Amazon Bedrock、およびその他の AWS サービスを使用した ML エンジニアリングの 1 年以上の経験 バックエンドソフトウェア開発者、DevOps エンジニア、データエンジニア、データサイエンティストなどの関連ロールでの 1 年以上の経験 従来の ML と生成 AI の両方の経験 雇用主および AWS パートナーの皆様へ: この認定は、ML エンジニアおよび MLOps エンジニアが従来の ML と生成 AI の両方にわたる最新スキルを検証済みであることを保証し、チームが今日のビジネス目標を達成する本番環境レベルのソリューションを提供できることに確信を持てるようにします。 MLA-C02 での変更点とその理由 試験のドメイン構成は変わりません。新しいドメインは追加されていません。ただし、更新された試験には、ML エンジニアの役割が実務上どのように拡大しているかに沿った主要な追加事項が反映されています。 生成 AI の実装: 生成 AI ソリューションの構築とデプロイ、基盤モデルのファインチューニング、RAG (検索拡張生成) アーキテクチャの実装 エージェンティック AI: AI エージェントと複雑なワークフローのオーケストレーション 基盤モデルと LLM: 大規模言語モデルの選択、カスタマイズ、運用 Amazon Bedrock: 生成 AI ワークロード向け Amazon Bedrock 機能のカバレッジ拡大 責任ある AI の実践: 従来の ML と生成 AI の両方にわたる責任ある AI 実装に関するガイダンスの更新 既存のタスクステートメントとスキルは、現在の業界慣行に沿って更新されていますが、認定が常に検証してきた中核的な ML エンジニアリング能力は維持されています。 注記 : タスクステートメントの詳細を含む完全な試験ガイドは、2026 年 9 月 1 日のベータ登録開始時に公開されます。 主要な日程 2026 年 9 月 1 日: ベータ版試験の受験予約開始 (英語のみ)、試験ガイド公開 2026 年 9 月 28 日: MLA-C01 英語での最終受験日 (日本語、韓国語、簡体字中国語はベータ期間中も引き続き利用可能) 2026 年 9 月 29 日: ベータ版試験の受験開始 ベータ試験の詳細 試験時間: 170 分 問題数: 85 問 受験料: 75 USD 言語: 英語のみ 配信: Pearson VUE (テストセンターまたはオンライン監督付き) MLA-C01 と MLA-C02 のどちらを受験すべきか ? 英語で受験する方は、以下をご検討ください。 MLA-C01 (既存試験) を受験 (2026 年 9 月 28 日まで): すでに準備が整っており、今すぐ認定を取得したい場合はこちらをご検討ください。資格は元の有効期限まで有効です。 MLA-C02 (ベータ) を受験 (2026 年 9 月 1 日受験予約開始): 従来の ML と生成 AI の両方のスキルを認定で検証したい場合。 すべての試験言語について、更新版試験 (MLA-C02) の標準版は 2027 年初頭に利用可能になります。 今すぐ始めましょう ML エンジニアの役割は進化しており、この認定もそれに合わせて進化しています。レコメンデーションシステムの構築、基盤モデルのファインチューニング、エージェンティック AI ワークフローの実装など、MLA-C02 はあなたのスキルが今日の業界が求めるものを反映していることを証明します。 参考リンク AWS Certified Machine Learning Engineer – Associate の詳細を見る AWS Skill Builder で学習を始める AWS 認定パスを確認する   翻訳は Technical Instructor の 室橋 弘和 が担当しました。