2026 年 6 月 22 日、私たちは AWS Lambda 内の新しいサーバーレスコンピュートプリミティブである AWS Lambda MicroVMs を発表しました。これは、ユーザーまたは AI によって生成されたコードを、分離されたステートフルな実行環境で実行できるようにするものです。仮想マシンレベルの分離、ほぼ瞬時の起動および再開、そして環境のライフサイクルと状態に対する直接的な制御を得ることができ、インフラ管理や複雑な仮想化技術に関する専門知識は不要です。Lambda MicroVMs は  Firecracker によって支えられており、これは毎月 15 兆回以上の Lambda 関数呼び出しを支えている軽量仮想化技術と同じものです。 なぜこの機能が求められるのか ここ数年で、新しいクラスのマルチテナントアプリケーションが登場しており、それらはすべて共通して「各エンドユーザーに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する」という要件を持っています。AI コーディングアシスタント、インタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナー、そしてユーザー提供スクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在、このような機能を構築するには難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動できますが、共有カーネル構造のため、信頼できないコードを安全に隔離するには大幅な追加の強化が必要です。Function as a Service はイベント駆動型のリクエスト・レスポンス型ワークロードに最適化されていますが、ユーザー操作間で環境状態を保持する必要がある長時間のインタラクティブセッションには適していません。その結果、開発者はパフォーマンスと分離性のトレードオフを受け入れるか、あるいは低遅延な体験を提供しつつ分離実行を実現するために、カスタム仮想化基盤を構築・運用するための大規模なエンジニアリングリソースを投入するかの選択を迫られます。これは高度な専門知識を要求する取り組みであり、本来構築しようとしているプロダクト開発からエンジニアリング時間を奪ってしまいます。 Lambda MicroVMs はまさにこのギャップを埋めるために設計されています。各 MicroVM は、単一のエンドユーザーまたはセッションに対して専用の隔離環境を提供し、迅速に起動し、セッション期間中はメモリとディスク状態を保持し、ユーザーが離席すると低コストのアイドル状態へと一時停止します。同じ Firecracker 技術がすでに AWS Lambda 関数を支えているため、同サービスが大規模運用で培ってきた運用成熟度をそのまま継承できます。 試してみましょう 私はまず AWS Lambda コンソールにアクセスし、左側のナビゲーションメニューに新しく表示された「Lambda MicroVMs」を開きました。最初に MicroVM Image を作成する必要があります。 Flask Web アプリとその Dockerfile を zip ファイルにまとめ、それを Amazon Simple Storage Service (Amazon S3) バケットへアップロードしました。 私の Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) 私の Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] MicroVM イメージを作成するために、以下のコマンドを使用しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> 上記のように、AWS コンソールから MicroVM Image を作成することも可能です。コマンドを実行すると、Lambda は zip を取得し、Dockerfile を実行してアプリケーションを初期化し、実行中のディスクおよびメモリ状態を Firecracker スナップショットとして取得します。ビルドログはリアルタイムで Amazon CloudWatch にストリーミングされ、ロググループは /aws/lambda/microvms/<image-name> に記録されます。イメージの準備が完了すると、その Amazon リソースネーム (ARN) とバージョン番号がコンソールに表示されます。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも実行できます。私はイメージ ARN とアイドルポリシーを指定しました。このポリシーでは、15 分間操作がない場合に自動的にサスペンドし、次のリクエストで自動的に再開するよう設定されています。ネットワーク設定は不要でした。Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、私の Flask アプリがすでに起動した状態の新しい MicroVM を開始しました（スナップショットから復元されたためです）。起動が完了した時点で、私の Flask アプリはすでに稼働していました。完全に初期化済みのコンピュート環境を得るまで、API コールはわずか 1 回です。 トラフィック送信のために、CLI で短時間有効な認証トークンを生成し、それを X-aws-proxy-auth ヘッダーとして通常の HTTPS リクエストに付与しました。リクエストはただちに私の Flask アプリへ到達しました。その後、Micro VM をアイドル状態のまましばらく放置すると、しきい値を超えた時点でサスペンドされ、メモリとディスクの状態はスナップショットとして保存されました。その後再びリクエストを送信すると、アプリケーションの状態を完全に保持したまま再開されました。クライアント側から見ると、停止は一切発生していないように見えます。 仕組み 内部的には、Lambda MicroVMs はこれまで単一の AWS コンピュートサービスでは提供されていなかった 3 つの能力を統合しています。第 1 は仮想マシンレベルの分離であり、これは Firecracker によって実現されています。各セッションは専用の MicroVM 内で実行され、カーネルやリソースはユーザー間で共有されません。そのため、あるユーザーが提供した信頼できないコードはその実行環境内に閉じ込められ、他の環境や基盤システムへアクセスすることはできません。第 2 は高速な起動および再開です。この仕組みは「イメージ→起動（image-then-launch）」モデルです。MicroVM Image は、DockerfileとAmazon S3 にパッケージされた zip アーティファクトを指定して作成されます。Lambda は Dockerfile を実行し、アプリケーションを初期化した後、その実行状態（メモリおよびディスク）を Firecracker スナップショットとして取得します。このイメージから起動されるすべての MicroVM は、コールドブートではなく事前初期化済みスナップショットから復元されるため、起動およびアイドル復帰の両方がほぼ瞬時に行われます。数 GB 規模のインタラクティブセッションであっても、ユーザーにとって十分に応答性のある速度で復帰します。第 3はステートフル実行です。実行中の MicroVM は、ユーザーセッション中にメモリ・ディスク・実行中プロセスの状態を保持します。アイドル状態では MicroVM はサスペンドされ、メモリとディスク状態を維持したまま保存され、トラフィック再開時に復元されます。インストール済みパッケージ、ロード済みモデル、作業中ファイルセットは再開時にそのまま利用可能です。MicroVM は最大 8 時間の総実行時間をサポートし、アイドル状態は設定可能な時間で自動サスペンドできます。これにより、数分で完了する脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間アイドルを含むインタラクティブ開発環境など、多様なユースケースを容易に構築できます。MicroVM は事前初期化スナップショットから起動されるため、初期化時にユニークなデータ生成、ネットワーク接続、または一時データのロードを行うアプリケーションは、互換性のためサービス提供のフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、専用のAPI 体系を持ちます。Lambda 関数はイベント駆動型のリクエスト／レスポンス処理に最適であり、Lambda MicroVMs はユーザーまたはセッションごとに隔離された実行環境で信頼できないコードを実行する必要があるマルチテナントアプリケーション向けに設計されています。両者は相互に補完関係にあります。イベント駆動のバックエンドには Lambda 関数を使用し、隔離実行が必要な処理には Lambda MicroVMs を呼び出す構成が可能です。アプリケーションはそのまま持ち込み、実行環境はサービス側が提供します。 今すぐご利用いただけます AWS Lambda MicroVMs は現在、米国東部 (バージニア北部・オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) リージョン で利用可能です。アーキテクチャは ARM64 に対応し、MicroVM あたり最大 16 vCPU、32GB メモリ、32GB ディスクをサポートします。アイドル状態の MicroVM は API による明示的停止、またはライフサイクルポリシーによって自動的にサスペンドでき、実行コストを削減しつつ状態を保持したまま高速再開が可能です。料金の詳細は AWS Lambda 料金ページ を参照してください。 開始するには AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ をご覧ください。ドキュメントは Lambda ドキュメント（Developer Guide） を参照してください。 原文は こちら です。

こんにちは。AWS プロフェッショナルサービスの Spatial Computing (空間コンピューティング) 領域の担当チームです。普段主に企業様向けのゲーム、シミュレーション、トレーニング等の用途で利用する 3D 空間の AWS 上への導入・企画支援を行っています。 AWS Summit Japan 2026 の AWS Village にて展示ブースを出展予定です。本ブログではそちらの展示内容をご紹介します。 AWS Summit Japan 2026 登録はこちら ブース A160：SDMA で繋ぐ現実世界とAIシミュレーション Physical AIを支える3Dアセット管理基盤を体験 SDMA (Spatial Data Management on AWS) から取得した 3D パーツで障害物コースを自動生成し、仮想ロボットが AI で走り方を学ぶ様子をリアルタイムで体験できます。大量のロボットが同時に試行錯誤する学習の様子や、学習済み AI の自律走行の体験など、シミュレーションからロボット制御へつなぐ AI 開発の流れを体感いただけます。 こんな方におすすめ 来場者像 ブースで得られること ロボットエンジニア   ロボットモデルの学習向けシミュレーション環境の効率的な構築方法 デジタルツイン推進担当   デジタルツイン環境の構築と AI シミュレーションへの活用例 展示内容 以下の 2 つの AI ロボットデバイスを題材にしたデモをご紹介します。 自律走行車両 自律飛行ドローン 各デバイスは仮想空間上に構築されたシミュレーション環境で強化学習が行われています。本デモでは、その仕組みを説明しながら、Spatial Data Management on AWS (SDMA) を活用したシミュレーション環境の効率的な構築・管理方法についてご紹介します。 補足 : Spatial Data Management on AWS (SDMA) とは Spatial Data Management on AWS (SDMA) は、2025 年 12 月にリリースされた、3D アセットなどの空間データ (Spatial Data) 管理基盤を構成するための AWS ソリューションです。OBJ、GLB、USD、PLY といった空間を表現する多様なフォーマットのデータを AWS のベストプラクティス構成で一元管理でき、AWS サービスとシームレスに連携したパイプライン実行が可能です。 下の図が SDMA のアーキテクチャ図です。公式サイトで提供されている CloudFormation ベースのテンプレートから AWS サービス群をデプロイできます。他の AWS サービスとの違いとして、専用のデスクトップアプリケーションが用意されており、PC から簡単な操作でAWS 上に構成されたデータ管理基盤にアクセス可能です。 デモ 1. 自律走行車両 概要 障害物が散在する不整地環境を、AI が自律的にゴールまで走行するデモです。Aalborg 大学が開発したオープンソースの強化学習フレームワーク  RLRoverLab をベースに構築しています。 強化学習の仕組み 車両は強化学習により、障害物を避けながらゴールに到達するポリシー（状況に応じた自律的な行動の決定ルール）を獲得しています。NVIDIA の Isaac Sim を活用し、報酬を設定した上でパラメータを変化させながら、数百の車両が同時並列で強化学習を行います。 学習に関係する要素 説明 観測空間   車両周囲の地形の凹凸（LiDAR スキャン）、ゴールまでの方向と距離 行動空間   車両の側面についている 6 つの車輪の操舵角および角速度 報酬設計   ゴールに近づくほど高評価、到達でボーナス（加点）、障害物に衝突するとペナルティ（減点） シミュレーション環境の構成 車両が走行するシミュレーション環境は、 地面 と  障害物 の 2 つの要素で構成されています。地面は起伏のある 3D 地形、障害物は 3D モデルで作成された岩で、地面に無数に配置されています。 SDMA によるシミュレーション環境の自動生成 本デモでは、地面と障害物の組み合わせを変化させ、別のパターンのシミュレーション環境を構築します。地面と障害物に対応する画像から 3D データを生成するパイプラインを構築し、SDMA 経由で実行させる例をご紹介します。 SDMA のデスクトップアプリを使用し、地面と障害物に対応する画像をそれぞれ SDMA にアップロードします。 すると、事前定義した AWS Step Functions のワークフローが自動実行されます。 地面の画像から 3D Gaussian Splatting（写真や動画から高精細な 3D 空間を構築する技術 / 点群データで構成され、3次元ガウシアン分布で広がりのあるデータを持つ）形式で 3D 地形点群データを生成する（Image to 3DGS API を利用 – 例：Marble） 障害物の画像から 3D メッシュモデルを生成する（Image to 3D API を利用 – 例：Meshy AI） 生成した 3D 地形点群データから物理判定用のコリジョンメッシュ（車両が重力下の地面を走行し凹凸を認識するために必要）を生成する  3D 地形点群データとコリジョンメッシュを重ね、その表面に障害物の 3D メッシュモデルをランダムに配置し、シーンデータとして合成（USD 形式）した上で、 SDMA に登録する その後、EC2 インスタンス上から SDMA を経由して生成されたシーンデータがダウンロードされ利用されます。 新しいシミュレーション環境の利用 生成した新しいシミュレーション環境上で、学習済みモデルが自律走行する様子を確認できます。地形と障害物が異なる環境でどのように走行するかを見ることで、汎化性能（学習時と異なる環境でも適切に動作する能力）を評価できます。必要に応じて、そのシミュレーション環境で追加学習を行うことも可能です。 デモ 2. 自律飛行ドローン 概要 複数のゲート（通過ポイント）で構成されたコースを、AI ドローンが飛行しながらゲートを順番に通過するレースデモです。オープンソースの  isaac_drone_racer  をベースに構築しています。来場者はコントローラーでドローンを操縦し、AI とレースで対決できます。 強化学習の仕組み ドローンは強化学習により、ゲートを順番に通過しながらコースを完走するポリシー（状況に応じた行動の決定ルール）を獲得しています。最大 4096 機が並列にシミュレーションされ、大量の試行錯誤を短時間で行うことで高速に学習が進みます。 学習に関係する要素 説明 観測空間   機体の速度・角速度・姿勢、次ゲートへの相対位置・方向 行動空間   4 つのプロペラを駆動する各ローターの角速度（＝推力） 報酬設計   ゲート通過で加点、ゲートへの接近・後退で進捗評価、衝突・コース逸脱で減点 シミュレーション環境の構成 ドローンが飛行するシミュレーション環境は、 ゲート と 障害物 の 2 つの要素で構成されます。ゲートはコースの経路を定義する通過ポイントで、障害物はゲート間の飛行経路上に配置されることで回避行動を要求します。 SDMA による障害物の配置 障害物の 3D モデルは SDMA で管理されています。SDMA のデスクトップアプリから障害物に対応した 3D モデル（GLB 形式）をアップロードすると、AWS Lambda によるフォーマット変換（GLB → USD：NVIDIA Isaac Sim で利用される3Dフォーマット）が自動実行されます。 変換された 3D モデルは、ブラウザ上の Web UI から SDMA 経由でダウンロードできるようになり、シミュレーション環境上での障害物の種類や配置を自由にカスタマイズできるようになります。 新しいシミュレーション環境の利用 カスタマイズした新しいシミュレーション環境上で、学習済みのモデルでドローンがどのように飛行するかを確認できます。ゲート配置や障害物の有無の影響を見ながら、AI の汎化性能を評価することができます。必要に応じて、そのコースで追加学習を行うことも可能です。 システムアーキテクチャ 利用している AWS サービス・ソリューション Amazon EC2 — GPU計算基盤 Spatial Data Management on AWS — 3Dアセットの管理・検索・配信基盤ソリューション Amazon API Gateway + AWS Lambda — バックエンド API Amazon S3 — 3D アセットデータストア Amazon DynamoDB — メタデータストア Amazon EventBridge — 3D アセット操作イベント通知 AWS Step Functions — ワークフローオーケストレーション Amazon Cognito — 認証・認可 その他技術要素 Amazon DCV — EC2 上でのシミュレーションツールのリモートデスクトップ配信 NVIDIA Isaac Sim + NVIDIA Isaac Lab — 物理シミュレーション・強化学習の実行環境 活用ユースケース 本デモで紹介した 3D のシミュレーション環境の構築パイプラインは、以下のようなユースケースでの活用が考えられます。 分野 ユースケース 物流・倉庫   AGV/AMR におけるパスプランニング、レイアウト変更時の再学習 建設・インフラ   ドローン点検の飛行経路最適化、現場 3D スキャンデータの活用 製造   工場フロアでの自律搬送ロボット導入シミュレーション エンターテインメント・スポーツ   カメラドローン自律飛行、スタジアム運営シミュレーション ブース情報 ブース ID   A160 エリア   AWS Village（AWS Expo エリア内） 日程   2026 年 6 月 25 日 (木)・26 日 (金) 会場   幕張メッセ まとめ AWS Summit Japan 2026 の AWS Village（ ブース A160 ）にて、2026年6月25日（水）・26日（木）の両日展示します。 デモを通して AI シミュレーションの概要をご覧いただきながら、AWS を活用したシミュレーション環境構築をお気軽にお立ち寄りください。 AWS Summit Japan 2026 公式サイト

こんにちは。ソリューションアーキテクトの原田、鈴木、西亀です。 2026 年 6 月 25 日（水）〜 26 日（木）に幕張メッセで開催される AWS Summit Japan 2026 の AWS Builders’ Fair にて、私たちが制作したデモ「 Living Mart — AI エージェントが経営するお店 」を展示します。 本記事では、このデモを作った背景と、会場でどんな体験ができるのかをご紹介します。 技術的な詳しい解説は Summit 後の別記事で予定 していますが、まずは「面白そう！行ってみよう」と思っていただければ幸いです。 Living Mart — “A store that runs itself.” 6 体の AI エージェントがリアルタイムで経営中 なぜ「AI が経営する店」を作ったのか これまでの AI は「人間が指示を出し、AI がそれを実行する」という使い方が中心でした。最近は、ひとつのタスクを単発でこなすのではなく、 仕事の一連の流れ（ループ）そのものを AI に任せる という方向に変わりつつあります。一度きりの自動化ではなく、AI が継続的に意思決定し、実行し続ける形です。 Living Mart は、これを「お店の経営」という題材で実際に動かしてみた実験です。人間が与えるのは ビジネスの枠組み（ルール）だけ 。その中で何をするかは、AI が自分で決め、動かし続けます。 この発想は、いまソフトウェア開発の現場で起きている変化とも重なります。コーディングエージェントは、テストや型チェック、CI といった「 ハーネス（安全装置） 」で囲むことで、人間が安心して任せられる存在になりました。同じ考え方を、ビジネスの運営にも持ち込めるのではないか——それが Living Mart の出発点です。 Living Mart とは 人間が一切指示しなくても、AI だけでお店を回し続ける — それが Living Mart です。 6 体の AI エージェント（CEO・オペレーション・PR・コンシェルジュ・サイネージ・ベンダー）が、商品の仕入れから値付け、サイト運営、接客、広告まで、すべてを自分たちで話し合い、自分たちで決めて動かし続けます。 マルチエージェント — 役割を分担する Living Mart では、人間の会社と同じように 役割を分担 させています。経営方針を決める CEO、在庫と価格を管理する現場オペレーション、サイトと広告を作る PR、来場者に応対するコンシェルジュ……。エージェントたちは Slack のようなチャットでやりとりし、「これ発注しておいて」「了解、在庫はこうします」と会話しながら連携します。 さらに、商品を納める Vendor（サプライヤー）は 別会社（別テナント） として動いており、企業をまたいだ取引まで再現しています。 ハーネス — 「お願い」ではなく「仕組み」で動かす 最大のポイントは、AI を プロンプト（お願い）ではなく、構造（仕組み）で制約している ことです。 たとえば「赤字で売らないで」とプロンプトで頼んでも、AI は数日で忘れます。そこで Living Mart では、注文・在庫・会計を扱う ERP（基幹システム） をエージェントの後ろに置き、「原価割れの価格は受け付けない」「在庫はマイナスにできない」といったビジネスルールを システム側で強制 しています。AI がうっかり安売りしようとしても、ERP が「エラー」として突き返す。だから AI は忘れようがありません。 これは、コーディングエージェントをテストや型チェックで囲む「ハーネスエンジニアリング」を、そのまま ビジネスの世界に持ち込んだ 発想です。 私たちの賭け — Bitter Lesson に従う Living Mart の設計には、ひとつの「賭け」があります。それは AI 研究で知られる 「The Bitter Lesson（苦い教訓）」 に従う、という選択です。 画像認識でも囲碁でも、人間が手で作り込んだ知識よりも、計算（スケール）に賭けた汎用的な手法が最終的に勝つ——これは AI の歴史で繰り返し起きてきたパターンです。 「私たちが欲しいのは、私たちが発見したことを“内蔵”した AI ではなく、私たちのように“自ら発見できる” AI だ」 — Rich Sutton『The Bitter Lesson』(2019) そこで私たちはこう考えました。 自律的に動く AI のスケールが進むほど、巧妙なプロンプトや細かく作り込んだ手続きは、むしろ要らなくなっていくのではないか 。だから、そこには意図的に労力をかけませんでした。代わりに投資したのは、モデルが賢くなるほど効いてくる「 壊れない箱 」です。 あえて作り込まなかったもの 代わりに投資したもの（＝「壊れない箱」） 在庫しきい値（「10 個を切ったら発注」）、手順書、ハードコードした判断ロジック、細かいプロンプトチューニング 高可用で自己回復するインフラ、AI が破れないビジネスルール、エージェントに合ったシンプルなツール群 箱の中で「何を考え、どう動くか」は、すべて Claude に委ねています。役割分担すら固定せず、エージェント同士の合意で決まります。 モデルの自律性に賭け、人間は「壊れない箱」だけを用意する ——それが私たちの設計判断です。 会場で体験できること AI が経営するお店で実際にお買い物 来場者の皆さまには、 スマホからリアルタイムに動いている EC サイトでお買い物 をしていただけます。 「All Goods」— AI エージェントが企画・撮影・値付けした商品が並ぶ商品一覧ページ。カテゴリ・価格・在庫表示まですべて AI が決定し、PR エージェントがこのページ自体を編集しています 会場モニターに映るサイネージ — AI が在庫・売上を見て自律的にコンテンツを切り替え QR コードでアクセス — ブースに掲示された QR コードからスマホで EC サイトへ 商品を選んで購入 — AI エージェントが企画・値付けした商品が並んでいます 抽選に当選すると… 当選すると AI デザインのオリジナルステッカーをプレゼント 店頭に並ぶステッカーは、 Vendor Agent が Amazon Bedrock の画像生成モデル（Stability AI）でデザインしたもの です。来場者は気に入った商品を選んで購入し、 抽選に当選すると、その場で印刷したオリジナルステッカーをお渡し します。 AI が企画・デザイン・値付けした商品を、その場でシールにしてお持ち帰りいただけます。 動いている様子を、リアルタイムで覗けます Living Mart は Summit 当日だけの展示ではありません。 今もエージェントたちがリアルタイムで経営判断を行い、お店を動かし続けています 。 Mission Control — 6 体のエージェントの稼働状況をリアルタイムで監視 ダッシュボードでは各エージェントが： 今何を考えているか 直近に使ったツール トークン消費量・イベント数 が一目で確認できます。 #general チャンネル — エージェント同士が Slack のようにメッセージを交換して連携 エージェントたちは人間の Slack のようなチャットで連携し、CEO の方針決定から Ops の発注実行まで、すべてメッセージングで協調しています。 裏側の仕組み 「AI が止まらず動き続ける」と言っても、裏側はシンプルな AWS のマネージドサービスの組み合わせでできています。代表的な 3 つの工夫をご紹介します。 止まらない常駐エージェント — 各エージェントは AWS Step Functions と Amazon ECS（AWS Fargate）で、約 10 秒ごとに「自分自身を再起動する」永続ループとして動いています。誰かに呼ばれなくても、自ら動き続けます。 忘れない記憶 — コンテナは使い捨てですが、Amazon S3 をファイルシステムとしてマウントすることで、エージェントの記憶（役割定義・学び・スキル）をファイルとして永続化。セッションをまたいで「経験」を積み重ねていきます。 暴走させないハーネス — 注文・在庫・会計を扱う ERP の API（Amazon API Gateway + AWS Lambda）と Amazon Aurora Serverless v2（PostgreSQL）の制約 として、ビジネスルールを強制しています。「在庫はマイナスにできない」「原価割れの価格は受け付けない」といったルールに違反する操作は、システム側でエラーとして突き返される——AI が破れない決定論的なガードレールです。 エージェントの思考には Amazon Bedrock 上の Claude を、ステッカーのデザイン生成には Amazon Bedrock の画像生成モデルを利用しています。 AWS Summit Japan 2026 でお会いしましょう 項目 詳細 イベント名 AWS Summit Japan 2026 日程 2026 年 6 月 25 日（水）〜 26 日（木） 場所 幕張メッセ（AWS Builders’ Fair） ブース A080 デモ名 Living Mart — AI エージェントが経営するお店 来場特典: AI が経営するお店で実際にお買い物体験 抽選で AI 生成オリジナルステッカーをプレゼント ぜひブース A080 にお立ち寄りください。AI エージェントたちと一緒にお待ちしています！ 著者について 原田 裕平 (Yuhei Harada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。AWS では主にヘルスケア・ライフサイエンス業界のお客様を支援しているソリューションアーキテクトです。 鈴木 大樹 (Daiki Suzuki) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。データベース領域を得意としており、主に toC 向けのサービスを行っているお客様を支援しています。 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。好きな領域は IoT とロボット。趣味はボルダリングで、オフィスにあるボルダリングウォールにトライしています。

みなさんこんにちは。ソリューションアーキテクトの山田です。2026 年 6 月 25 日(木)、26 日(金)の 2 日間に渡って開催される AWS Summit Japan 2026 では今年も製造業に関する展示を数多く行なわれています。製造業に関連する全体的な展示やセッションに関しては こちらのブログ に全体がまとめられておりますので参照ください。 本ブログではその中でも製品設計開発に関するデモ展示について紹介します。 コンセプト : 生成 AI 時代の製品設計開発 CAE 解析や CAD 操作、過去ナレッジの活用など、製品設計開発の現場にはエンジニアの専門性に強く依存する業務が数多く存在します。本展示では、フィジカル AI 時代の到来を見据え、エンジニアの設計開発を加速する 2 つの切り口で実機デモをご覧いただきます。 1. Engineering Development Hub（ EDH ）による PC / Workstation / HPC 環境の俊敏な立ち上げ 2. 設計開発の現場ですぐに実践できる生成 AI ユースケース 「フィジカル AI 時代の研究開発をどう加速するか」を、現場のエンジニア目線で体感いただける展示です。 1. Engineering Development Hub（ EDH ) EDH は 専用 Web ポータルによって設計開発に従事する方が使用する PC / Workstation / HPC 環境をクラウド上にセルフサービスで立ち上げることができるシステムです。3D モデリング、大規模シミュレーション、 CAE 解析、 GPU を用いたモデル作成に至るまで、フィジカル AI 時代の研究開発においてはこれまで以上に多彩なツールチェーンと、それを効率よく実行する多種多様なコンピューティング環境が必要となります。EDH はクラウドの柔軟性を活かした多様な要件に対応できる仮想ワークステーション環境とスケーラブルな HPC 基盤を 1 つのシステムとして提供。専用の Web ポータルによりエンジニアは直感的に必要なデスクトップ環境を取り出し、大規模に CPU/GPU を使用した分散学習やシミュレーションを実行することができます。 EDH は以前 Scale-Out Computing on AWS（SOCA）として知られていたソリューションの後継で、2026 年 4 月にリブランドされ、新たにリリースされました。SOCAの派生としては RES (Research and Engineering Studio on AWS) もリリースされておりますが、RESはVDIに特化したソリューションです。VDIに加えてHPCの機能も統合して利用したい場合は今回ご紹介するEDHの利用をご検討ください。 Engineering and Development Hub (EDH) アーキテクチャ図 EDH の主な特徴 仮想デスクトップによるインタラクティブ処理 Amazon DCV を用いた高性能なリモートデスクトップ環境で、CAD ソフトウェアの 3D 描画もスムーズに操作できます。Windows と Linux の両方に対応し、GPU インスタンスを選択することで、>オフィスにいなくてもワークステーション級の作業環境にアクセスできます。 HPC を使った大規模バッチ処理 Slurm、OpenPBS、IBM LSF といった主要なジョブスケジューラに対応し、ジョブ投入に応じて計算ノードが自動的にスケールアウトします。EFA（Elastic Fabric Adapter）による低遅延ネットワークで、大規模並列処理のスケーリングも問題ありません。処理が完了すればノードは自動的に終了し、課金が停止します。  専用 Web インタフェースによる直感的な利用 EDH には専用の Web ポータルが付属しており、以下のような操作をブラウザから直感的に行えます。コマンドラインに不慣れなエンジニアでも、すぐに使い始められるのが特徴です。 仮想デスクトップの起動・停止 HPC ジョブの投入・状態監視 ファイルの管理とアップロード 利用状況の可視化とコスト確認 Amazon EC2 の高い汎用性 EDH の計算リソースは Amazon EC2 上に展開されるため、実行するアプリケーションや処理の規模に合わせて最適なスペックのインスタンスを選択できます。 CPU：x86（Intel / AMD）、Arm（Graviton） GPU：NVIDIA L4、A10G、A100、H100 etc. メモリ：数 GB から数 TB まで OS：Amazon Linux、RHEL、Ubuntu、Windows Server etc. EDH の仮想デスクトップ管理画面と HPC ジョブ投入画面 EDH のユースケース EDH は以下のような設計開発ワークロードで活用することができます。もちろんこれら以外にも仮想デスクトップや HPC 環境を必要とするワークロード全般に適用可能であり、汎用性の高いソリューションです。 CAD：3D モデリング、設計・製図 CAE：構造解析、流体解析、熱解析 材料シミュレーション：分子動力学、第一原理計算 EDA：半導体設計、論理合成、検証 フィジカル AI：ロボティクス開発、強化学習 EDH のリソース他 Engineering Development Hub（EDH）はオープンソースで公開されているため、すぐに試すことができます。 ソースコード: github.com/awslabs/engineering-development-hub ドキュメント: awslabs.github.io/engineering-development-hub-documentation AWS Summit Japan 2026 会場内の AWS for Industries Zone ブース (ブース ID：A021) で、EDH の実環境をご覧いただけます。ぜひ実際のデモをご覧ください。 2. 設計開発の現場ですぐに実践できる生成 AI ユースケース 自然言語による CAD/CAE 操作のアシストや、時間のかかるシミュレーションを AI で高速化するサロゲートモデルなど、明日からでも取り入れられる「使える AI」の活用例をご紹介します。 その場でご覧いただける動作デモに加え、後日体験できるワークショップもご用意しているので、AI が設計業務をどう変えるのかをじっくり実感いただけます。 生成 AI × CAD + CAE + NVIDIA Isaac による フィジカル AI シミュレーション 本デモでは、AWS の AI コーディングアシスタント Kiro に 自然言語で指示するだけ で、1 台の産業用 6 軸ロボットアームを題材に、 設計 → CAD 編集 → 強度解析（CAE） → ロボットの動作学習 までを一気通貫で実行する様子をご覧いただけます。 フィジカル AI 時代に求められる「設計してから、実際に動かして学習させるまで」の流れを、コードを 1 行も書かずに体感できる展示です。 設計開発の現場に多く存在する、専用ソフトの習熟や、複雑な製図・シミュレーションといった時間を要する業務を効率化する効果が期待できます。 注記：Kiro CLI の基盤モデルは検証を進めた期間中にアップデートが重なったため、工程ごとに Claude Opus 4.6 / 4.7 / 4.8 を使用しています（どの工程でどのバージョンを使ったかは、後述の詳細記事シリーズにそれぞれ明記しています）。 本デモ動画の撮影時点では Claude Opus 4.8 を使用しました。モデルのバージョンによって、生成されるコードの品質や挙動は変わる場合があります。 デモの流れ — 1 台のロボットアームを 4 ステップで設計 同じ 1 つの形状データを引き継ぎながら、すべての工程を Kiro への日本語の指示だけで進めます。 AWS Summit Japan 2026 展示動画（YouTube : 3分58秒） 1. 3D 形状をつくる 寸法を言葉で伝えるだけで、ロボットアームの 3D モデルを生成します。CAD ソフトを使わず Python だけで STL ファイル（※3D 形状のデータを見るのに向いた形式）を作り、関節角度から先端位置を求める順運動学（※各関節を何度曲げると腕の先端がどこに来るかを求めるロボット設計の基本計算）の検算まで Kiro が自動で実施。このモデリングを実時間 4 分 28 秒で完了しました。 技術詳細解説ブログ Kiro で AI 支援の設計開発 -自然言語指示だけで 3D モデリングや流体シミュレーション実行- プロンプト例： 産業用6軸多関節ロボットアームの3Dモデルを生成する generate_robot_arm.py という Pythonスクリプトを構築してください。 numpy-stl、numpy、matplotlib のみを使用してください。 ■ ロボットアーム構成（ベースから先端へ）： 1. ベース（J1軸: 旋回） — 固定台座: 円筒 直径300mm 高さ50mm、旋回部: 円筒 直径250mm 高さ100mm 2. ショルダー（J2軸: 前後傾動） — 関節ハウジング: 直径200mm 高さ150mm 3. 上腕（リンク1） — 長さ500mm、断面: 150mm x 120mm 4. エルボー（J3軸: 上下傾動） — 関節ハウジング: 直径160mm 高さ120mm 5. 前腕（リンク2） — 長さ450mm、断面: 120mm x 100mm 6. 手首（J4/J5/J6軸） — 3段の円筒 7. エンドエフェクタ（ツールフランジ） — 直径63mm（ISO 9409-1準拠）、ボルト穴6個 ■ 姿勢パラメータ： - J1〜J6の関節角度を変数化し、順運動学（FK）で各リンクの位置・姿勢を計算 Kiro が 3D モデリング用のコードを作成し実行している様子 完成したロボットアーム 3D モデル STL ファイル 2. 形を編集する CAD で編集できる STEP ファイル（※3D 形状の CAD ソフトで編集するのに向いた形式）に作り直し、オープンソースの 3D CAD ソフト FreeCAD で、角の丸め（フィレット）や穴あけといった加工を追加します。GUI 操作だけでなく、Kiro が FreeCAD Python API を用いてヘッドレス（GUI なし、コマンドラインとスクリプトだけ）でも編集を実行できることを示します。 技術詳細解説ブログ CADソフトの操作を自然言語指示でAIに任せる — Kiro で STEP 生成から FreeCAD 編集まで Kiro が作成したロボットアーム図面をベースに、FreeCAD で人間が編集操作を行っている様子 Kiro が自然言語指示によりヘッドレスでロボットアーム図面編集操作を行った結果（編集前後比較） 3. 強度を確かめる 完成した形に荷重をかけ、応力やたわみを計算する構造解析（CAE）を実行します。今回は材料をアルミ合金 6061-T6、ベース底面を固定し、先端のフランジに 100 N（約 10 kg 相当）の下向き荷重をかける条件で解析しました。部品の結合からメッシュ分割、材料・拘束・荷重の設定、ソルバー実行、結果の可視化までを Kiro が担当し、最大応力（フォン・ミーゼス応力）約 0.13 MPa・最大変位は 5.76 μm という結果を得ています。途中でエラーが出れば自ら原因を切り分け、手法を見直しながら解析を完走させます。 技術詳細解説ブログ AI が設計して、AI が強度検証する — Kiro × FreeCAD FEM でロボットアームCAE構造解析 Kiro が FreeCAD で CAE 実行した結果を人間が GUI で確認している様子 4. 動かして学ばせる 設計したアームに吸盤を付け、NVIDIA Isaac Sim / Isaac Lab 上で「キューブを持ち上げて運ぶ」動作を強化学習（※ロボットに動きを試行錯誤させ、うまくいくほど報酬を与えて自分で上達させる AI の学習方法）させます。4096 体のロボットを 1 枚の GPU で同時に動かし、学習開始直後はほぼ 0% だった成功率を、学習後にはピックアップ（持ち上げ）成功率 91.5%、目標位置への運搬・保持も 77.9% まで引き上げました。 技術詳細解説ブログ AI で設計した自作ロボット、NVIDIA Isaac で 4096 並列強化学習させた結果 4096 体のロボットを NVIDIA Isaac Sim / Isaac Lab 上でキューブピックアップ強化学習している様子 AIを活用した設計開発のポイント つくりたいものを、言葉にするだけ 専用ソフトの習熟や環境構築も AI が肩代わり。設計の参入障壁が下がる。 時間がかかる作業が、速く・再現性高く 日々の製図も解析も手間を大幅削減。初期検討を素早く回せる。 未知の領域にも、踏み込める 強化学習のような未経験分野も AI が調べて試す。学びながら新スキルが身につく。 仕上げと判断は、人 本番品質には専門家の判断と検証が要る。AI は作業役、決めるのは人。 著者について 山田 航司 (Koji Yamada) AWS のソリューションアーキテクトとして、製造業のお客様を中心にクラウド活用の支援を行っています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

はじめに 株式会社 MIXI は、コミュニケーションを軸に、ソーシャルネットワーキングサービスからゲーム、スポーツ、ライフスタイルサービスへと事業を多角化してきた日本の企業です。「モンスターストライク」や「家族アルバム みてね」といったサービスに加え、FC東京をはじめとするプロスポーツチームの運営を通じて、人と人との豊かなコミュニケーションの場を提供しています。 本記事では、MIXI が FC東京向けに開発した「写真選定業務効率化システム」のバックエンドデータベースとして、Amazon Aurora DSQL 採用の経緯と技術的な工夫、得られた効果を、お客様の声を交えて紹介します。 ※本画像は、FC東京様と MIXI 様の許諾を得て掲載しています 解決したかった課題 FC東京では、試合ごとに公式カメラマンが撮影した約 1 万枚の写真を、試合当日に Web 公開するマッチレポートといったマーケティング・広報用途に活用しています。これまでは担当者が写真を目視で 1 枚ずつ確認しながら選定する運用を行っており、選定に時間がかかることでタイムリーに写真素材を活用できないことが課題でした。そこで、画像認識モデルと生成 AI を組み合わせて自動的に写真を分析・選定し、Web UI から候補を素早くプレビューできるシステムを新規に構築することにしました。 ただし、その開発・運用を担うのは少人数のチームであり、データベースの管理に人手をかけられないという事情がありました。加えて、試合は基本的に週 1〜2 回、主に土日に開催され、そのたびに写真の取り込み・分析・選定が短時間に集中する一方、試合と試合の間には、データベースへのアクセスが発生しない時間帯が生じます。こうした稼働に波のあるワークロードでは、データベースにアクセスしない時間帯のコストを抑える最適化も必要でした。 なぜ Aurora DSQL を選んだのか これらの前提を踏まえ、データベースに求めたのは、少人数で無理なく運用でき、稼働の波にも無駄なく対応できる運用特性でした。決め手は次の点です。 メンテナンス・バージョン管理が不要 ：エンジンのバージョンアップやメンテナンスウィンドウを意識する必要がなく、専任 DBA を置かずに少人数のチームで運用できる 使った分だけの課金 ： 「リクエストベースの、使用量主導型の価格モデル」 を採用しており、データベースへのアクセスが発生しない時間帯は処理に対する課金が発生しないため、固定インスタンス（常時稼働）の構成と比べて利用に波のある本ワークロードでも無駄なコストを抑えられる 通常の RDB として利用できる ：使い慣れた SQL でデータを扱え、PostgreSQL のドライバー・ORM・ツールも活かせる（後述のとおり一部の対応を実施） アーキテクチャ概要 システム全体のアーキテクチャは以下の通りです。 技術的に工夫した点 本システムでは、JavaScript / TypeScript の ORM である Drizzle（ https://orm.drizzle.team/ ）を採用しています。Aurora DSQL が PostgreSQL 互換であることを活かして Drizzle をベースに実装を進めました。ただし、一部の PostgreSQL 機能との非互換 や トランザクションサイズなどの制限 があり、次のような対応を行っています。なお、本記事で触れる Aurora DSQL の制約・仕様は執筆時点のものです。Aurora DSQL は継続的に機能追加・改善が行われているため、最新の情報は公式ドキュメントをご確認ください。 1. ORM の Drizzle が出力する DDL を Aurora DSQL 互換形式に変換するスクリプトを内製 Drizzle が生成するスキーマ変更 DDL は通常の PostgreSQL を想定しており、Aurora DSQL の制約・仕様に合わない箇所があります。AWS は Aurora DSQL 向けに、 一部の ORM フレームワーク用のアダプター／ダイアレクトや、各種データベースドライバー用のコネクター を公開していますが、本システムで採用している Drizzle 向けのアダプターは執筆時点では提供されていませんでした。そこで、Drizzle が出力する DDL を Aurora DSQL の制約・仕様に合わせて変換するスクリプトを内製しました。主な処理は次の通りです。 インデックス作成 ：Aurora DSQL では単体の CREATE INDEX 文に非同期指定（CREATE INDEX ASYNC）が必須のため、Drizzle が出力する CREATE INDEX を CREATE INDEX ASYNC に変換する処理 外部キー制約 ：Aurora DSQL は外部キー制約をサポートしていないため、Drizzle が生成する外部キー制約の ALTER TABLE（ADD FOREIGN KEY）を削除する処理 トランザクションの分割 ：Aurora DSQL は 1 トランザクションにつき DDL を 1 つしか実行できないため、複数の DDL 変更を 1 つのトランザクションでまとめて適用しようとする Drizzle のマイグレーションを、1 つずつ個別のトランザクション（BEGIN … COMMIT）に分割する処理 これらの変換は、Drizzle のマイグレーションを実行するコマンド（npm script）に組み込んでいます。ローカルでも CI/CD パイプラインでも同じコマンドで実行されるため、開発者は通常の Drizzle のワークフローのままスキーマ変更を進められます。 2. トランザクションサイズ制限への対応：大きな更新を複数のトランザクションに分割 Aurora DSQL には、1 トランザクションあたりに変更できる行数に上限があります（3,000 行）。1 試合あたり約 1 万枚の写真それぞれに 5〜6 個のタグを付与します。レコード数はタグだけで約 5〜6 万件に達し、さらに写っている人物の関連付け（人数分のレコード）も登録します。これらをまとめて 1 つのトランザクションで反映すると上限（3,000 行）を超えてしまいます。本システムでは、一時的な不整合が許容できる処理を整理したうえで、分析結果の反映については複数の小さなトランザクションに分割して処理する方式にしました。これにより、1 トランザクションあたりの変更行数を上限内に抑えています。利用者には処理中かどうかの状態を画面に表示し、アップロード・分析の進捗を把握できるようにしています。 3. OCC（楽観的同時実行制御）への対応 Aurora DSQL は OCC を採用しており、コミット時に競合が検出された場合はトランザクションをリトライする必要があります。本システムでは、ドライバー層にリトライ処理を作り込み、競合時には数回リトライしたうえで、それでも成功しない場合はデッドレターキューへ退避させて後続のハンドリングを行っています。 開発・運用面で得られた効果 本システムの設計・実装は、「AWS Prototyping Program」の支援を受けて進めました。これは、AWS の Prototyping Engineer が課題に合わせてシステムのプロトタイプを開発するプログラムです。約 1 か月の開発期間を経て、プロジェクト開始から約 2 か月後には本番稼働まで到達できました。DSQL 採用後に開発チームが実感している効果は次の通りです。 メンテナンスウィンドウ・バージョン管理が不要 「DB の存在を意識せず開発・運用できる」ことが採用後最大のメリットでした。標準でマルチ AZ 構成になっており、実際、本番稼働後 DB 起因の障害は発生していません。従来型の（プロビジョンド構成の）RDB を採用していた場合は 0.5 人月程度を要すると想定していましたが、Aurora DSQL の採用後はこうした作業がほぼ不要となりました。 少人数チームでアプリ開発に集中できる DBA を専任で置く必要がなく、インスタンスのサイジングやスケーリングといったキャパシティ設計そのものが不要なため、少人数のチームでもアプリケーション機能の実装に集中でき、開発スピードを保てました。本システムはデータベースを含むアプリケーション全体を実質 1 名で開発していますが、サーバーレス構成によりキャパシティを意識せずデータベースを扱えたことが、開発の高速化に直結しています。なお、開発メンバーは PostgreSQL の利用経験があり、DSQL 自体の学習コストはほとんど発生しませんでした。DSQL 固有の制約事項についても理解・把握は短時間で済み、それらへの具体的な対応は前述の「技術的に工夫した点」のとおり実装で吸収しています。 使った分だけの課金で無駄のないコスト構造 稼働に波がある本システムでは、使った分だけの課金というコストモデルが特によく合致しました。アクセスが発生しない時間帯は処理に対するコストがかからないため、こうしたワークロードでも無駄なコストを抑えられています。 性能要件を十分に満たせている 複雑な検索条件を設定してもサムネイル一覧の初期表示は 1 秒以内に収まり、写真分析のスループットも実用上十分な速度で完了しています。実運用において、データベースがボトルネックになったことはありません。もちろん DB 性能だけで実現したわけではありませんが、Aurora DSQL がこれらの要件を性能面の問題なく支えられていることが、システム全体としての設計余地を広げてくれています。 さいごに 株式会社 MIXI では、FC東京向けの写真選定業務効率化システムのバックエンドに Aurora DSQL を採用し、利用が特定の時間帯に偏るワークロードを、運用工数を最小限に抑えながら短期間で本番稼働まで到達させることができました。株式会社 MIXI の數藤氏は次のように振り返っています。 「DB の存在を意識せずに開発・運用できることが一番のメリットでした。メンテナンスやスケーリングの設計から解放され、少人数のチームでもアプリケーション開発に集中できています。こうした特性を持つワークロードでは、今後も積極的に Aurora DSQL を活用していきたいと考えています。」 Aurora DSQL の採用を検討しているチームにとって、本事例が一つの参考になれば幸いです。 株式会社 MIXI ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ 數藤 智幸 氏

こんにちは、ソリューションアーキテクトのシャルノ ミカエルです。 本記事では、2026 年 6 月 25 日（木）と 26 日（金）の 2 日間、幕張メッセで開催される AWS Summit Japan 2026 のブース予告をお届けします。製造業に関する展示は AWS Expo 内の AWS for Industries です。このブログでは、その中から「 ソフトウェア定義型ファクトリー 」と題して、ソフトウェア PLC とコーディングエージェントで工場制御の開発を変革するテーマについてご紹介します。 製造業関連の全ブース紹介は こちらのブログ記事 をご覧ください。 このブースで体験できること 工場の設備を動かしているのは PLC (Programmable Logic Controller) です。ロボット、コンベア、バルブなど、あらゆる設備が PLC の制御ロジックに従って動作しています。PLC はリアルタイム制御と安定性に優れる一方で、 ロジックの変更には特殊なスキルセットを持つ技術者が必要 であり、 変更のリードタイムは長く、コストも多大 です。 さらに深刻なのは、検証を本番設備でしか行えないという制約です。変更のために生産ラインを長時間停止するか、小さな変更を小分けにして少しずつ適用するしかなく、結果としてビジネスニーズの変化に追従できない・・・これが多くの製造現場の実情です。 このブースでは、物理 PLC をソフトウェア PLC に置き換え、AI コーディングエージェントとシミュレーション環境を組み合わせることで、工場制御の「開発体験」を根本から変える取り組みの成果をご紹介します。 実際のミニチュアファクトリーとシステム構成を展示し、どのようなプロセスで制御ロジックの変更を実現したかをご覧いただけます。 物理工場 (左) と仮装工場 (右) このブースの注目ポイント ソフトウェア PLC と Structured Text (ST) コードによるソフトウェア開発ライフサイクル（SDLC）の実現 : 制御ロジックをラダーロジックから構成管理しやすい ST コード化し、バージョン管理・ロールバックを可能にします。これにより、ソースコード、デプロイメント、セキュリティを AWS で一元管理できます。 AI コーディングエージェントによる制御ロジックの自動生成 : 開発者が自然言語でやりたいことを伝えると、コーディングエージェントが既存のソースコードを解析し、修正案を提案・適用します。これにより、従来は熟練者が数時間〜数日かけていた制御変更を、対話だけで実現します。 シミュレーション環境での事前検証 :  クラウド上に PLC プログラムと工場設備を動かす仮想シミュレーション環境を構築し、本番適用前にリスクなく検証します。これにより、IaC（Infrastructure as Code）でオンデマンドに立ち上げ、コストを抑制します CADデータ活用による学習レス外観検査 : Amazon Nova を活用し、事前学習なしで外観検査を実現。これにより、CADデータから生成した形状をリファレンスモデルとして使用し、実物との差異を検出 展示の概要 本ブースでは、ミニチュアファクトリーと実際のシステム構成を展示し、以下の一連のプロセスをご紹介します。 ステップ 1：課題の発見 「 生産ラインの未来 」ブースでは、需要増による生産性向上の要求に応えるために AI エージェントが設備から収集されたデータの分析を行い、生産ラインのボトルネックを解消する改善案を導き出します。本ブースでは、その改善案を 実際に制御ロジックへ実装する 後続のプロセスをご紹介します。 ステップ 2：コーディングエージェントによる制御ロジックの実装 改善案（例：商品によって倉庫に入れるのではなく、直接加工ラインに流す分岐を追加する）を、コーディングエージェントで実装します。 開発者が自然言語で意図を伝えます ソフトウェア PLC プログラムの開発環境である CODESYS の MCP サーバー機能経由でプロジェクトのソースコードを解析 ソースコードの修正を提案し、承認後に適用できます ステップ 3：シミュレーション環境での検証 修正されたプログラムをいきなり本番に適用するのではなく、クラウド上の NVIDIA Isaac Sim によるシミュレーション環境で動作を検証します。 Isaac Sim 内のファクトリーモデルは、実際のソフトウェア PLC から本番と同じ Modbus/TCP で制御されています。PLC 上では本番と同一のプログラムが動作しており、シミュレーション環境側の動作プログラム（PLC との Modbus 通信連携部分）は Python で AWS に AI コーディングエージェントである Kiro  を使って実装しました。なお、クラウドとのシミュレーション連携のために TCP ベースのプロトコルを選定しています。 実環境の物理現象を完全に再現することは非常に難しく、シミュレーションは一定の再現性にとどめています。それでも、制御ロジックの大部分の問題を本番適用前に発見できるため、開発サイクルの大幅な短縮につながります。 ステップ 4：フィードバックとイテレーション コーディングエージェントの出力は、最初から完璧とは限りません。シミュレーション検証で不具合が見つかった場合は、ステップ 2 に戻り追加の指示を出します。たとえば今回の開発では、「奥のオーブンにパーツを持っていっても扉が開かない」「青と判定される前に自動倉庫が入荷モードに動いてしまい、キャンセル処理が漏れる」といった問題がシミュレーションで発覚し、エージェントに追加修正を依頼して解消しました。このように、 エージェントとの対話を繰り返しながら素早くイテレーションできる のが、ソフトウェア定義型ファクトリーの大きな利点です。 ステップ 5：本番環境での検証と適用 この工場環境は本番環境もソフトウェアPLCを採用しているため、そのまま、シミュレーションで十分に検証を重ねたプログラムを、物理環境のソフトウェア PLC にダウンロードし、本番環境での最終検証を行います。事前に仮想環境で多くの問題を解消しているため、本番環境での検証は短期間で完了でき、従来よりも質の高いオートメーションの変更を迅速に提供できます。 物理構成 ソフトウェア PLC : WAGO 社製 Industrial PC 上で CODESYS 社のソフトウェア PLC が動作 通信プロトコル : Modbus/TCP で WAGO 社製リモート IO と連携 リモート IO : WAGO 社製リモート IO がモーター・バルブ・センサーを制御 ミニチュアファクトリー : Fischertechnik 社製の学習用ファクトリーモデルを使用 使用している AWS サービス Amazon Bedrock : コーディングエージェントの推論基盤（LLM バックエンド） Amazon Nova : CADデータを活用した学習レス外観検査 Amazon EC2 : ソフトウェア PLC および CODESYS 開発環境の実行基盤 Amazon ECS : NVIDIA Isaac Sim の実行基盤（GPU を活用したコンテナベースのシミュレーション環境） AWS IoT Greengrass : エッジデバイスとクラウドの接続 AWS を活用するメリット シミュレーション環境の柔軟な提供 : IaC でオンデマンドに立ち上げ、必要な時だけ利用しコストを抑制 最新 GPU の提供 : シミュレーションに必要な最新 GPU インスタンスをすぐに利用可能 豊富な LLM の選択肢 : Amazon Bedrock を通じて工場の制御開発に適した LLM を選択可能 ソフトウェア開発のベストプラクティスを工場に適用 : バージョン管理、CI/CD、ロールバックなど、ソフトウェア開発で培われた手法を工場の制御開発にも展開 まとめ 「ソフトウェア定義型ファクトリー」ブースでは、 工場の制御をソフトウェアとして扱う という新しいパラダイムの成果をご覧いただけます。ソフトウェア PLC × AI コーディングエージェント × クラウドシミュレーションの組み合わせにより、従来数時間〜数日を要していた制御変更のサイクルを劇的に短縮し、工場を安全かつ継続的に進化させることができます。 AWS Summit Japan 2026 の AWS for Industries ブースにて、ぜひ実物のミニチュアファクトリーとシステム構成をご覧ください。皆さまのご来場をお待ちしております！ 著者について   Mickaël Charneau (シャルノ ミカエル) AWS とパートナーのソリューションを元に、自動車と製造のお客様の業務の効率化とデジタルトランスフォーメーションをサポートしているソリューションアーキテクトです。

本ブログは 2026 年 5 月 14 日に公開された AWS Blog “ Automating post-quantum cryptography readiness using AWS Config ” を翻訳したものです。 TLS エンドポイントを ポスト量子暗号 (PQC) に移行する際は、まず現在の TLS エンドポイントのインベントリと状態を把握することから始めます。本記事では、PQC Readiness Scanner を紹介します。これは Application Load Balancer (ALB) 、 Network Load Balancer (NLB) 、 Amazon API Gateway のエンドポイントをインベントリ化し、PQC 対応の観点から TLS 設定を継続的に監視する自動化ツールです。スキャナーは各エンドポイントを 3 階層フレームワークに分類し、PQC 移行の優先順位付けと計画立案を支援します。 量子コンピューティングの進展に伴い、データを長期的に保護するには耐量子暗号への移行が必要になります。PQC Readiness Scanner を使用すると、どのエンドポイントから移行すべきかを特定し、アカウント全体での進捗を追跡できます。ウェブトラフィックでは、PQC 鍵交換アルゴリズムは TLS 1.3 内でのみネゴシエートされます。つまり、耐量子接続を実現するには、TLS 1.3 と PQC 鍵交換をサポートするエンドポイントが必要です。 AWS 責任共有モデル のもとで、AWS はインフラストラクチャを保護し、各サービス全体で PQC サポートを実現します。一方、お客様は PQC 対応の TLS ポリシーを使用するようにリソースを設定する責任を担います。 Application Load Balancer (ALB) 、 Network Load Balancer (NLB) 、 Amazon API Gateway 、 Amazon CloudFront など、AWS が TLS 接続を終端するケースでは、お客様がセキュリティポリシー (リスナーがサポートする TLS プロトコルバージョンと暗号スイートを定義する AWS マネージドの設定) を選択します。このポリシーによって、TLS バージョンと暗号スイート、鍵交換、認証アルゴリズムのサポート範囲が決まります。 AWS が TLS を終端するエンドポイント向けに自動化された PQC Readiness Scanner は、 AWS Config コンフォーマンスパック を使用して構築されています。コンフォーマンスパックとは、AWS Config ルールと修復アクションをまとめたもので、アカウントとリージョン内の単一エンティティとして、または AWS Organizations の組織全体にデプロイできます。 ソリューションの概要 PQC Readiness Scanner は、コンフォーマンスパックを使用して AWS Config ルールをデプロイし、各エンドポイントの セキュリティポリシー を評価します。評価結果に基づいて、各リソースは 3 階層フレームワークに分類され、PQC 対応の TLS を実現するために必要な移行アクションの優先順位が付けられます。 PQC Readiness Scanner は、リソースごとに次の 2 つのチェックを実行します。 エンドポイントが PQC 対応のセキュリティポリシーを使用しているか エンドポイントがレガシーの TLS 1.0 または 1.1 をサポートしているか 各チェックは COMPLIANT または NON_COMPLIANT のステータスを、具体的なポリシー推奨事項とともに返します。 PQC では、エンドポイントが TLS 1.3 をサポートし、PQC 鍵交換アルゴリズムを使用する必要があります。3 階層フレームワークは、検出結果の解釈と修正の優先順位付けに役立ちます。目標は、エンドポイントで PQC 鍵交換を有効にした TLS 1.3 を使用することです。ただし、これを実現するにはクライアントとの下位互換性を維持する必要があります。 ティア 対応レベル TLS プロトコル PQC ステータス 移行優先度 ティア 1 PQC 対応 (最も強固な状態) PQC 鍵交換を使用する TLS 1.3 のみ PQC 対応 なし ティア 2 PQC 対応 (下位互換性あり) PQC 鍵交換を使用する TLS 1.2 および 1.3 PQC 対応 低 ティア 3 PQC 非対応 PQC 鍵交換なし PQC 非対応 高 移行の優先順位付け方法 ティア 1 は、PQC 鍵交換を使用する TLS 1.3 のみを使用する、最も強固なセキュリティを表します。これらのリソースは既に目標状態を満たしています。 ティア 2 は、下位互換性のある PQC 対応の構成を表します。エンドポイントは TLS 1.2 と TLS 1.3 の両方をサポートし、PQC 鍵交換は TLS 1.3 接続でネゴシエートされます。これらのリソースは、TLS 1.3 をサポートするクライアントに対して既に耐量子保護を提供しつつ、レガシークライアント向けに TLS 1.2 互換性を維持しているため、移行優先度は低くなります。クライアント側の分析によって、接続するクライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることが確認できたら、ティア 1 に移行してください。 ティア 3 は、PQC 非対応のリソースを対象とします。これには、TLS 1.3 をサポートしていないエンドポイントや、TLS 1.3 はサポートしているが PQC 鍵交換ポリシーを持たないエンドポイントが含まれます。これらのリソースには早急な対応が必要です。 評価範囲 このスキャナーは、お客様のアプリケーションに代わって TLS 接続を終端する、次の AWS エッジサービスを評価します。 エッジサービス: HTTPS、TLS、TCP SSL プロトコルを使用する Application Load Balancer (ALB)、Network Load Balancer (NLB) のリスナーが評価対象です。 API Gateway REST API は AWS リージョンエンドポイントとプライベートエンドポイントが評価され、あわせて API Gateway HTTP API (v2) と WebSocket API (v2) も評価されます。 評価対象外のエッジサービス: CloudFront ディストリビューションは PQC 対応の評価範囲から除外されます。これは、ビューワーからエッジへの接続について、既存の CloudFront TLS セキュリティポリシー全体でハイブリッドポスト量子鍵交換を使用する TLS 1.3 が自動的に有効になっているためです。CloudFront のインバウンド (ビューワー向け) PQC については、お客様による対応は不要です。 Classic Load Balancer の推奨アプローチ: Classic Load Balancer については、AWS は ALB または NLB への 移行 を推奨します。Classic Load Balancer は TLS 1.3 または PQC 鍵交換をサポートしておらず、PQC 対応にすることはできません。 ソリューションの仕組み AWS Config によって、継続的な監視と評価が可能になります。コンフォーマンスパックを使用すると、組織全体へのデプロイが可能になります。 AWS Lambda は、AWS Config ルールに基づいてセキュリティポリシー評価を行うコードを実行するサーバーレスコンピューティングサービスです。 AWS サーバーレスアプリケーションモデル (AWS SAM) は、AWS Lambda 関数のデプロイに使用するオープンソースフレームワークです。 図 1: PQC 対応ソリューションのアーキテクチャ PQC Readiness Scanner コンフォーマンスパックは、2 つの Lambda 関数によって動作する 4 つのカスタム AWS Config ルール を実装します。 ルール チェック内容 非準拠の結果 ELB PQ-ready ロードバランサーのリスナーが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます ELB legacy TLS ロードバランサーのリスナーが TLS 1.0 または 1.1 接続を許可しているか レガシープロトコルが設定されている場合、リソースにフラグが付けられます。 API Gateway PQ-ready API Gateway エンドポイントが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます API Gateway legacy TLS API Gateway エンドポイントが TLS 1.0 または 1.1 を許可しているか レガシープロトコルが設定されている場合、リソースにフラグが付けられます。 前提条件 このソリューションをデプロイする前に、次のものが必要です。 適切なアクセス許可を設定した AWS コマンドラインインターフェイス (AWS CLI) aws configure aws sts get-caller-identity # Verify Python 3.12 がインストールされていること。Lambda ランタイムにはこのバージョンが必要です python3 --version # Should show 3.12.x AWS SAM CLI がインストールされていること ( インストールガイド ) pip install aws-sam-cli # Verify sam --version 対象の AWS リージョンで AWS Config が有効になっていること 次のリソースタイプを記録するように設定する (アカウントがデフォルトですべてのリソースを記録している場合、このステップは不要です) AWS::ElasticLoadBalancingV2::LoadBalancer AWS::ApiGateway::RestApi AWS::ApiGatewayV2::Api AWS Config コンソール → Recorder → Recording Strategy → Select specific resource types から有効にします (特定のリソースタイプ向けの AWS Config 記録戦略については、手動セットアップの手順に従ってください) PQC Readiness Scanner のデプロイ手順 PQC Readiness Config Scanner は 3 つのフェーズに分けてデプロイします。完全なデプロイコマンドと設定の詳細は GitHub リポジトリ で確認できます。コンフォーマンスパックは Lambda 関数の ARN をパラメータとして参照するため、Lambda 関数を最初にデプロイする必要があります。詳細は GitHub リポジトリを参照してください。 シングルアカウントへのデプロイ クローンとビルド: git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git cd sample-PQC-Readiness-using-AWS-Config/installation sam build 1 つ以上のリージョンへのデプロイ: # Make script executable (first time only) chmod +x deploy-per-regions.sh # Deploy to a single region ./deploy-per-regions.sh us-east-1 # Deploy to multiple regions ./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1 図 2: これらのリソースに対して AWS Config 記録を有効にしているか、デフォルトですべてのリソースを記録している場合は、y を入力して続行します このスクリプトは、次の処理を自動的に行います SAM を介して Lambda 関数をデプロイ コンフォーマンスパックをデプロイ (Config ルールを作成) デプロイの成功を検証 明確なステータスメッセージを提供 このデプロイにより、PQC 対応およびレガシー TLS のチェックを実行する 2 つの Lambda 関数が作成されます。ELB、ALB、NLB、API Gateway の describe オペレーション用に、最小権限のアクセス許可を持つ IAM ロールがプロビジョニングされます。Lambda アクセス許可により、AWS Config が関数を呼び出せるようになります。 図 3: デプロイ成功時の画面の例 マルチアカウントデプロイ (Organizations) 複数の AWS アカウントにまたがる組織全体のデプロイには、CloudFormation StackSets を使用して各アカウントに Lambda 関数をデプロイします。 重要な制約: AWS Config の CUSTOM_LAMBDA ルールでは、Lambda 関数が Config ルールと同じアカウント内に存在する必要があります。1 つのアカウント内に集約した Lambda を使用して、他のアカウントのリソースを評価することはできません。 前提条件: 共有 S3 バケット パッケージ化の前に、組織内の各ターゲットアカウントからアクセスできる S3 バケットを作成します。このバケットには、CloudFormation StackSets が各メンバーアカウントに取り込む Lambda デプロイアーティファクトをホストします。 # Create the shared S3 bucket (run from management/central account) aws s3 mb s3://<your-org-shared-bucket> --region us-east-1 次のいずれかのオプションを使用して、ターゲットアカウントに読み取りアクセス権を付与します。 aws s3api put-bucket-policy \ --bucket <your-org-shared-bucket> \ --policy '{ "Statement": [ { "Sid": "BucketOwnerFullAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<bucket-owner-account-id>:root" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::<your-org-shared-bucket>", "arn:aws:s3:::<your-org-shared-bucket>/*" ] }, { "Sid": "CrossAccountReadAccess", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::<account-id-1>:root", "arn:aws:iam::<account-id-2>:root" ] }, "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::<your-org-shared-bucket>", "arn:aws:s3:::<your-org-shared-bucket>/*" ] } ] }' <account IDs> は、StackSets が Lambda 関数をデプロイする AWS アカウント ID に置き換えてください。 注 : バケットは StackSet のデプロイリージョンと同じリージョンに配置する必要があります。マルチリージョンデプロイの場合は、リージョンごとに 1 つのバケットを作成し、各リージョンに対して sam package を個別に実行します。 ステップ 1: Lambda パッケージのビルドと S3 へのアップロード installation/ ディレクトリからパッケージ化スクリプトを実行します。 cd installation # Make script executable (first time only) chmod +x deploy-stacksets.sh # Build, package, upload to S3, and generate resolved template ./deploy-stacksets.sh <your-org-shared-bucket> このスクリプトは、次の処理を自動的に行います。 SAM を使用して Lambda 関数をビルド ZIP パッケージを作成 ZIP を共有 S3 バケットにアップロード S3 の値が組み込まれた packaged-template.yaml を生成 (デプロイ時にパラメータは不要) 図 4: Lambda パッケージが S3 バケットに正常にアップロードされたときのサンプルスクリプト出力 ステップ 2: StackSets を介した Lambda 関数のデプロイ 管理アカウント (または委任管理者アカウント) から、次のコマンドを実行します。 # Create StackSet (--region sets the StackSet "home region" where it is managed) aws cloudformation create-stack-set \ --stack-set-name pqc-readiness-lambda-functions \ --template-body file://packaged-template.yaml \ --capabilities CAPABILITY_IAM \ --permission-model SERVICE_MANAGED \ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \ --region us-east-1 # Deploy stack instances to member accounts # --regions = target regions where Lambda functions are deployed in member accounts # --region = must match the StackSet home region above aws cloudformation create-stack-instances \ --stack-set-name pqc-readiness-lambda-functions \ --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \ --regions us-east-1 \ --region us-east-1 重要 — StackSet ホームリージョンとデプロイリージョンの違い: --region (各 CLI コマンド) = StackSet リソースが存在する StackSet ホームリージョン。後続のオペレーション (describe、update、delete) では、これと同じリージョンを指定する必要があります。 --regions ( create-stack-instances 上) = メンバーアカウントにスタックインスタンスが作成されるデプロイ先のターゲットリージョン これらは独立した値です。CLI のデフォルトリージョンへの意図しないデプロイを避けるため、 --region を明示的に指定してください。 注 : SERVICE_MANAGED StackSets は、管理アカウントまたは委任管理者アカウントから作成する必要があります。管理アカウント自体はスタックインスタンスのデプロイから除外されます。管理アカウントでスキャナーが必要な場合は、 deploy-per-regions.sh を別途使用してください。 ステップ 3: 組織コンフォーマンスパックのデプロイ aws configservice put-organization-conformance-pack \ --organization-conformance-pack-name pqc-legacy-tls-compliance \ --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml これにより、各メンバーアカウントに、ローカルの Lambda 関数を参照する Config ルールが作成されます。 移行のガイダンスと優先順位付け 3 階層フレームワークは、PQC 移行の優先順位を提供します。 高優先度 – ティア 3 (PQC 非対応): 対象: PQC サポートのないリソース。これには、PQC 対応のセキュリティポリシーを使用していないエンドポイントや、依然として TLS 1.0 または 1.1 を許可しているエンドポイントが含まれます。 アクション: 名前に PQ を含む PQC 対応のポリシー (たとえば -PQ-2025-09 で終わるもの) にアップグレードします (完全なリストは Elastic Load Balancing セキュリティポリシーの ドキュメント を参照してください)。 重要: PQC 対応のポリシーにアップグレードする前に、クライアントの TLS バージョンを監査してください。PQC 対応のポリシーには TLS 1.3 のサポートが必要です。TLS 1.2 以前のみをサポートするレガシークライアントは、接続のネゴシエーションに失敗します。まずティア 2 の下位互換性のあるポリシー (TLS 1.2 と 1.3 の両方を PQC とともにサポート) から始め、TLS ネゴシエーションの失敗がないか接続ログを監視します。クライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることを確認してから、ティア 1 の TLS 1.3 のみのポリシーに移行してください。 リスク: エンドポイントが転送中のデータに対してポスト量子暗号をサポートしていません。レガシー TLS プロトコルは、現在の暗号攻撃に対して脆弱です。 低優先度 – ティア 2 (PQC 対応、下位互換性あり): 対象: TLS 1.3 + PQC 対応のポリシーを使用し、下位互換性のために TLS 1.2 もサポートするリソース アクション: クライアント互換性の分析によって、接続するクライアントが TLS 1.3 をサポートしていることが確認できた場合、TLS 1.3 のみのポリシーを検討します。 リスク: 最小限です。これらのリソースは、TLS 1.3 接続で既に PQ-TLS をサポートしています。TLS 1.2 以前へのフォールバックは下位互換性を維持しますが、これは一部のクライアントが PQ-TLS でネゴシエートしていない可能性を示しているかもしれません。修復策としては、ログを監視してこれらの接続数とクライアント数を特定し、これらのクライアントが TLS 1.3 と PQ-TLS を使用するように移行計画を立てます。 対応不要 – ティア 1 (PQC 対応、最適な構成): 対象 : PQC 鍵交換を使用する TLS 1.3 のみを使用するリソース。これらのリソースは目標状態を満たしています。移行は不要です。 結果の表示 各メンバーアカウントで、デプロイしたリージョンの AWS Config コンソール に移動します。 コンフォーマンスパックビュー AWS Config → コンフォーマンスパックに移動し、次を探します。 OrgConformsPack-pqc-legacy-tls-compliance- 注 : 組織コンフォーマンスパックには OrgConformsPack- というプレフィックスが付き、ランダムなサフィックスが追加されます (例: OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0)。 図 5: PQC コンフォーマンスパックのコンプライアンススコアは、準拠しているルールとリソースの数の割合です コンフォーマンスパックをクリックすると、4 つすべてのルールにわたる全体的なコンプライアンス概要を確認できます。 個別ルールビュー AWS Config → ルールに移動し、プレフィックス pqc- が付いた 4 つのルールを見つけます。 pqc-elb-pqc-compliance-conformance-pack- pqc-elb-legacy-tls-conformance-pack- pqc-apigateway-pqc-compliance-conformance-pack- pqc-apigateway-legacy-tls-conformance-pack- 任意のルールをクリックすると、次を表示できます。 準拠リソースと非準拠リソースの数 各リソースの詳細な注釈 リソース ARN と現在のセキュリティポリシー設定 図 6: コンフォーマンスパック内の Config ルールステータスの可視化 図 7: 3 階層フレームワークに基づく移行ガイダンスを記述した Config ルールの検出結果と注釈のサンプル画像 まとめ PQC Readiness Scanner をデプロイすると、AWS エッジサービス全体の TLS 状態を可視化でき、手動の設定レビューを削減できます。ティアシステムは具体的なアップグレード推奨事項を提供するため、チームは暗号の専門知識がなくても次のステップを把握できます。スキャナーは設定変更を自動的に検出し、新しいデプロイが対応基準を維持できるように支援します。組み込みの AWS Config レポート機能は監査要件をサポートし、PQC 対応に向けた測定可能な進捗を示します。 PQC Readiness Scanner をデプロイし、 PQC Readiness Scanner で結果を確認してください。高優先度のティア 3 リソースから移行を開始し、AWS Config アグリゲーター を使用して、アカウント全体の進捗を監視してください。 追加リソース GitHub リポジトリ: PQC Readiness Config Scanner AWS Config ドキュメント: Lambda を使用したカスタムルール AWS SAM ドキュメント: サーバーレスアプリケーションモデル PQC 移行計画: NIST ポスト量子暗号標準 PQC 移行計画: AWS ポスト量子暗号移行計画 この記事に関するご質問がある場合は、 AWS Config re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Pravin Nair Pravin は、AWS でデータ保護とプライバシーを専門とするシニアセキュリティソリューションアーキテクトです。お客様と連携して、暗号化、インフラストラクチャ保護、プライバシーエンジニアリングにまたがる複雑なセキュリティ課題に対応する、安全でスケーラブルなクラウドソリューションを設計しています。専門分野は、保管時および転送中の暗号化、インフラストラクチャセキュリティ、プライバシーベースのアーキテクチャ、そして生成 AI セキュリティやポスト量子暗号を含む新興のセキュリティ領域にまで及びます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

[特別企画] もぐもぐ AWS お昼休みの30分で、AWSの最新トレンドをキャッチアップ。 ごはんを「もぐもぐ」しながら聞くだけ。 毎回30分 参加無料 Workshop Studio 3日間体験付き（先着50名） このシリーズについて 「もぐもぐ AWS」は、お昼休みの 30 分で AWS サービスの最新トレンドをキャッチアップできるウェビナーシリーズです。サービスごとに活用のヒント・構築の進め方・導入の始め方をコンパクトにご紹介します。 ■ 2026年7月 月 火 水 木 金 6 7 8 9 AI エージェントの権限管理 MCP サーバー・ツール・データ基盤の Fine grained access control 申し込む 10 Kiro で PM をラクに タスク管理もメールもコードも、全部 Kiro に繋いで PM をラクにしよう 申し込む 13 14 AWS DevOps Agent 自律型AIエージェントによるシステム障害調査の自動化 申し込む 15 Claude Code 活用術 Claude Code をAWSの構築、運用に活用しよう 申し込む 16 Open weights モデル Open weights モデルの進化と Amazon Bedrock 経由での利用方法を学ぼう 申し込む 17 AI 時代のセキュリティ 変わることと変わらないこと 申し込む 20 　海の日 21 AWS Security Agent AI 時代におけるプロアクティブセキュリティ 申し込む 22 Amazon Connect もう人だけで頑張らない — Agentic AI がコンタクトセンターを変える 申し込む 23 Amazon Quick 昼休みにQuickしよう 〜30分でサクッとわかるAI仕事術〜 申し込む 24 27 28 インダストリー編#1 Coming Soon 29 インダストリー編#2 Coming Soon 30 インダストリー編#3 Coming Soon 31 ▼ 【期間限定】アーカイブ視聴はこちら アーカイブを視聴する 【ご視聴・お申込みに関するご注意】 視聴にはメールアドレスのご入力が必要です ご登録いただいた情報は、AWSの Sales/Marketing Policy に基づき管理いたします AWSからのフォローアップにご同意いただける方のみご視聴いただけます

2026 年 6 月 15 日週、 AWS Summit New York City では、何千人ものお客様、パートナー、ビルダーが集まり、クラウドと AI のイノベーションの最新情報を紹介する無料の1日イベントを開催しました。Jane Goodall 博士とAWS のエージェンティック AI 担当副社長である Swami Sivasubramanianは、 基調講演 で一連のAIローンチを発表しました。これらはすべて、「時間の経過とともに価値を複合化するエージェント」という 1 つのテーマに基づいて構築されています。 作業用エージェント – Amazon Quickの新機能 により、自律型エージェントを起動し、よりスマートなアクティビティフィードにアクセスできます。これにより、デスクトップアプリで直接複数ステップのエージェントを作成して実行できるようになり、メール、Slack、カレンダー、タスクをパーソナライズされたルールで優先順位付けされた単一のビューに統合できます。 保護のためのエージェント – AWS Continuum は、 コードの脆弱性ライフサイクル全体 にわたってマシンスピードで推論し、検証し、行動する新しい AI ネイティブセキュリティサービスで、事後対応型から事前対応型のセキュリティに移行できます。AWS セキュリティエージェント（現在は AWS Continuum の一部）には、脅威モデリング、主要な Git プラットフォームでの修復を伴うプルリクエストコードスキャン、Kiro パワー、Claude Code プラグイン、MCP による IDE 統合などの 新機能 が追加されています。 ビルド用エージェント – Kiro、AWS DevOps エージェント、AWS Transform を使用すると、コードの記述、配布、モダナイズを 1 つの連続ループで行うことができます。Kiro は ネイティブ iOS アプリケーション を導入し、AWS DevOps エージェントは リリース管理機能 を追加して本番前にコードの変更を評価し、 AWS Transform の継続的なモダナイゼーション は技術的な負債を自律的に削減します。 お客様が作成するエージェント – Amazon Bedrock AgentCore を使用すると、エージェントのアイデアから本番稼働まで数分で完了できます。これには、インフラストラクチャとオーケストレーションのための GA ハーネス 、 ウェブ検索 、 マネージドナレッジベース 、 Guardrails とのポリシー統合 、組織のデータ関係をマッピングするための新しい AWS コンテキストサービス が含まれています。 詳細については、 トップアナウンスのブログ投稿 と Amazon ニュースの投稿 にあるサミットのまとめをご覧ください。 2026 年 6 月 15 日週のリリース 6 月 15 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 ベトナムのハノイにある AWS ローカルゾーン — この新しいローカルゾーンは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートするアジア太平洋地域初の AWS ローカルゾーンの1つで、データをローカルに保存してバックアップすることで、お客様がデータレジデンシーの要件を満たすことができます。まず、AWS グローバルビューの [リージョンとゾーン] タブから、または ModifyAvailabilityZoneGroup API を使用して、ハノイローカルゾーン ( ap-southeast-1-han-1a ) を有効にします。 AWS Blocks は、アプリケーション開発者向けのオープンソース TypeScript フレームワークです (プレビュー) — AWS Blocks は Postgres、認証、リアルタイムメッセージングを備えた完全に機能するローカル環境を実行します。AWS アカウントは必要ありません。デプロイする準備ができたら、同じアプリケーションコードが本番環境の AWS サービスでも変更なしで実行され、いつでも AWS CDK にアクセスして直接リソースを設定できます。 Amazon BedrockのxAiのGrok 4.3 — Amazon BedrockではGrok 4.3モデルを使用できます。これにより、推論、エージェント、およびエンタープライズワークフローにわたる生成 AI アプリケーションを構築する際に、さらに多くの選択肢が得られます。Grok 4.3 は、価格パフォーマンスを重視して設計された Bedrock の新しい推論エンジン上で動作し、ツール呼び出し、構造化出力、応答ストリーミングをサポートしています。 Amazon S3 アノテーション: 豊富でクエリ可能なコンテキストをオブジェクトに直接アタッチ – Amazon S3 ではアノテーションを使用して、最大 1 GB のリッチで変更可能かつクエリ可能なコンテキストをオブジェクトに直接アタッチできるようになりました。これは、個別のメタデータシステムを維持することなく大規模なデータを発見、理解、処理する必要のある AI エージェントや自律型ワークフロー向けに構築されています。 Amazon ECS がより高速なサービス自動スケーリングを発表 — Amazon ECS サービスの自動スケーリングは、高解像度 (20 秒) のメトリックスとメトリックス公開の最適化をサポートすることで、負荷の変化をより迅速に検出して対応できるようになりました。AWS のベンチマーキングテストでは、スケールアウトがトリガーされるまでの時間が 363 秒から 86 秒に短縮され (76% の高速化)、新しいタスクのスケールとプロビジョニングにかかる合計時間が 386 秒から 109 秒に短縮されました (72% の高速化) Amazon EC2 G7 インスタンスは NVIDIA RTX PRO 4500 ブラックウェルサーバーエディション GPU で高速化されています — AWS は、NVIDIA RTX PRO 4500 ブラックウェルサーバーエディション GPU をサポートした最初の大手クラウドプロバイダーです。G7 インスタンスは、これらの GPU と第 6 世代のカスタムインテル Xeon Scalable プロセッサを組み合わせることで高速化されており、G6 インスタンスと比較して、最大 4.6 倍の AI 推論パフォーマンスと最大 2.1 倍のグラフィックスパフォーマンスを実現します。 Strands Agents に新機能が導入されました — Strands はプロダクションエージェントを構築するためのオープンソースツールキットです。Strands Shell による新しい分離された実行環境である Harness SDK でより優れたコンテキスト管理が可能になり、Strands Evals ではカオステストとレッドチーミングを使用できるようになりました。 AWS マネジメントコンソールのプライベートアクセス — インターネットに接続していなくても VPC から AWS コンソールにアクセスできるため、企業は隔離された環境でも厳格なネットワークセキュリティ管理を維持しながら、コンソールから AWS インフラストラクチャを管理できます。 AWS Marketplace Storefront が一般公開されました – AWS パートナーは、独自のブランド化されたソリューションとサービスのカタログを作成し、自社のウェブサイトやアプリケーションに数時間でデプロイできます。チャネルパートナーと独立系ソフトウェアベンダーは、クラウドマーケットプレイスビジネスの管理方法を簡素化し、顧客が AWS Marketplace からソリューションを見つけて購入しやすくできるようになりました。 Amazon Route 53 Resolver DNS ファイアウォールでのパロアルトネットワークス (PANW) 高度な DNS セキュリティ (プレビュー) – 組み込みの AWS Marketplace ウィジェットを使用して DNS ファイアウォールコンソールから PANW にサブスクライブすることで、個別のファイアウォールをデプロイしたり VPC 設定を変更したりすることなく、パロアルトネットワークスの DNS 脅威保護を Route 53 DNS ファイアウォールルールに直接適用できるようになりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 価格引き下げ AWS は引き続き、お客様のためにパフォーマンスを向上し、価格を下げる方法を模索しています。6 月 15 日週、このような取り組みにいくつか気づいたので、それらを共有したいと思います。 Amazon S3 Vectors は、大規模なベクターインデックスのクエリ料金を最大 80% 削減します — この削減により、大規模な AI、RAG、およびセマンティック検索ワークロードにわたって類似検索を実行するお客様のコストが削減されます。新しい価格設定は自動的に適用され、アプリケーションを変更する必要はありません。 Amazon GameLift サーバーは無料のネットワーク帯域幅を導入します — Amazon GameLift Servers は、オンデマンドやスポットを含め、第 6 世代以降のすべてのインスタンスタイプについて、コミットメントなしで AWS 内外のネットワーク帯域幅を追加料金なしで提供します。Amazon GameLift Servers のインスタンス時間分のみのお支払いとなり、ネットワーク帯域幅はすべて無料になりました。 AWS Marketplace では、プロフェッショナルサービスの出品料が 2.5% から 0.5% に引き下げられました — この引き下げにより、コンサルティングパートナー、システムインテグレーター、マネージドサービスプロバイダー、独立系ソフトウェアベンダーが AWS Marketplace を通じてサービスを取引する際の費用対効果が高まり、調達や請求のメリットも維持されます。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 6 月 22 日週のニュースは以上です。6 月 29 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

6 月 25 日 (木)・26 日 (金) の 2 日間、千葉・幕張メッセにて開催される AWS Summit Japan 2026 の AWS for Games エリアにおいて、 Immersive Experience Platform のブースが出展されます。 本ブログではこちらの展示内容をご紹介します。 AWS Summit Japan 2026 登録はこちら ブース A012：Immersive Experience Platform アプリケーション × バックエンド × インフラ — イマーシブ空間に必要なすべてを、ひとつのプラットフォームで。 Immersive Experience Platform は、3D 空間の開発ツールから API、インフラ基盤までをフルスタックで提供するパートナーソリューションです。テンプレートやプラグインを活用することで、専門知識がなくても高品質なイマーシブ体験を短期間・低コストで実現できます。 こんな方におすすめ 来場者像 ブースで得られること 3D 空間エンジニア・ゲーム開発者・デザイナー   テンプレートを活用して簡単に 3D 空間を構築する方法 Web エンジニア・プロダクト開発者   既存 Web サイトに 3D コンテンツを組み込む方法 インフラエンジニア・SRE・CTO   自動化されたセキュアな AWS 基盤を自社環境に構築する方法 展示内容 Immersive Experience Platformは、アプリケーション、バックエンド、インフラストラクチャーの3つのレイヤーでビジネスの課題解決を支援するプラットフォームです。 1. アプリケーション – 特別な技術がなくても簡単に 3D 空間を構築できる テンプレートを活用しながら、簡単に3D空間制作が始められます。AIチャットを通して最適なテンプレートの検索や、クラウドで管理された3Dアセットの活用ができ、構築した空間はAWS上にデプロイし、URLを発行してすぐに共有することが可能です。 2. バックエンド – 便利な機能・コンテンツを既存サイトへ組み込むことができる 様々な機能を有効化し、既存 Web サイトに 3D コンテンツを組み込むことができます。3D ビューワー、AI チャットボットなどの機能を、専用の画面からカスタマイズすることで、簡単に導入することが可能です。 3. インフラストラクチャー – 自動化されたセキュアな AWS 基盤を自社環境へ構築できる 自動化されたセキュアな AWS 基盤を自社環境に簡単に立ち上げることが可能です。オンラインマルチプレイやチャット、AI支援分析ダッシュボード、統合開発環境といった機能を、用途に合わせて選択しながら導入可能です。 利用している AWS サービス・ソリューション 本プラットフォームは AWS プロフェッショナルサービス が開発を支援し、以下のような AWS サービス・ソリューションが利用されています。 Amazon CloudFront + Amazon S3 — Web コンテンツ配信 Amazon GameLift Streams — クラウドゲーミング（ゲームのストリーム配信） Amazon Elastic Container Service (ECS) — オンラインマルチプレイサーバー Amazon API Gateway + AWS Lambda — バックエンド API Amazon Cognito — ユーザー認証・認可 Amazon Bedrock  — AI チャットボット Amazon QuickSight — AI 支援ダッシュボード AWS CodePipeline + AWS CodeBuild — CI/CDパイプライン Spatial Data Management on AWS — 3D アセット管理基盤ソリューション ブースで得られること テンプレート × プラグインによる開発期間短縮のアプローチ — 専門の 3D エンジニアがいなくても簡単にイマーシブ体験を構築する方法 既存サービスにイマーシブ体験を組み込む設計パターン — 便利なイマーシブ機能・コンテンツを既存 Web サイトに組み込む方法 AWS 上で 3D アプリ配信基盤を運用するアーキテクチャ実例 — CI/CD で自動化されたセキュアな 3D 空間向け AWS 基盤の構築方法 ブース情報 ブース ID 　A012 エリア   AWS Industries Zone（AWS Expo エリア内） 日程   2026 年 6 月 25 日 (木)・26 日 (金) 会場   幕張メッセ まとめ Immersive Experience Platform ブース（A012）では、「アプリケーション」「バックエンド」「インフラ」の 3 レイヤーを横断して、イマーシブ体験構築の全体像をデモとともにご紹介します。業界エキスパートとの 1 対 1 のご相談も可能です。 皆さまのご来場を心よりお待ちしております。 AWS Summit Japan 2026 への登録はこちら

本記事では、AWS サンプルアセットである AI エージェント SMART（Store Manager Agent for Retail Tech） についてのご紹介と、それを活用した株式会社ユナイテッドアローズ（以下、ユナイテッドアローズ）の取り組みについてご紹介します。小売業にとって、店舗の声をどう本部に届けるかは永遠のテーマです。売上数字の裏には、現場スタッフだけが感じている気づきが必ずあります。しかし店舗の日報や週報のフォーマットだけでは、その気づきを届けるのは難しいのが実情です。SMART は、店舗の気づきを AI の力で引き出し言語化して、本部に届けることを支援するために誕生しました。 1. 現場の気づきをどう本部に届けるか 店長・店舗スタッフの皆さんは、毎日、たくさんの気づきを生み出されています。「今日は雨だったけれど、来店されたお客様の購買率は高かった」「新しいデザインの商品についてお客様の反応が予想以上にいい」「休憩の回し方を変えたら接客効率が上がった気がする」。こうした気づきは、売上や客数といった定量データだけでは見えない、店舗運営にとってかけがえのない手がかりです。 一方で、一日の売場で生まれる数多くの気づきを、閉店後の限られた時間のなかで日報の自由記述欄に記録するのは、仕組みとして難しいところがあります。接客、在庫確認、レジ締め、翌日準備をこなしたあとに、うまく言葉にしづらい感覚的な気づきまで文章化するのは、誰にとっても相応の負担がかかる作業です。現場で毎日生まれている観察の豊かさに対して、日報フォーマットが持つ受け皿で拾うには、自ずと限界があります。本部側としても、定型フォーマットの数字だけでは現場の肌感が読み取れず、良い兆候があっても背景までは見通しにくい状況があります。 このような課題は小売業界全体に共通しています。米国・カナダの小売業界のリーダー 227 人を対象にした Zipline 社の調査「Misaligned」2026 によれば、店舗施策が正しく実行される確率は 36% にとどまり、その主な原因としては 人員不足（51%） と 時間不足（32%） が挙げられています。店舗リーダーの 70% は「本部にフィードバックを伝える明確な手段がない」と答え、43% の小売リーダーが「実行不備による売上・収益の損失」を経験していると報告しています。 海外の調査ではありますが、日本の小売業の現場でも、似たような課題を感じておられる企業は多いのではないでしょうか。 業界も同じ課題に向き合っている — Tapestry の事例 こうした課題は、グローバルの大手企業も向き合ってきたテーマです。Coach や Kate Spade などのブランドを展開する Tapestry 社（ 2024 年時点で、世界 70 カ国以上で約 1,400 店舗を運営）は、店舗の第一線で生まれる気づきを本部に届ける仕組みの必要性を認識し、AWS 上で Tell Rexy というフィードバック収集アプリを開発しました。 Amazon Bedrock と Amazon Transcribe を組み合わせて音声入力に対応させ、1 年で 約 3 万件 の気づきを集め、マーチャンダイジングの改善に活かしています（ AWS Case Study: Tapestry ）。 SMART は、ユナイテッドアローズの店舗運営に関わる事業部門の声を伺いながら、AWS のプロトタイピングエンジニアがサンプルを開発し、AWS Samples として公開しました。 2. SMART のアプローチ — 本部の「問い」× AI の「深掘り」 なぜ “自由記入欄” では不十分なのか 忙しい閉店後の店舗スタッフに、日報フォーマットの自由記入欄や、普段コミュニケーションとして使っているチャットアプリケーション等に今日の気づきを書くのは難しいはずです。仮に仕組みとして「今日はどうでしたか」と問いかける形でも、返す答えは 「普通でした」「特に問題なし」 で終わるのではないでしょうか。一日の疲れのなか、自分の気づきを一から構造化して語るのは、誰にとっても負担が大きい作業のはずです。 SMART は、この前提を逆転させました。名前の通り、Store Manager Agent for Retail Tech — 店長を助ける AI エージェントです。ポイントは、本部からの “問い” を起点に AI が現場に深掘りする設計にあります。 3 層の設計 SMART は、次の 3 層で成り立っています。 本部の「問い」 — 本部は「今日気になったお客様の反応は？」「新しい商品の売れ行きは？」といった、確実に確認したい内容を定型質問として設定します。これはノーコードで編集可能で、キャンペーンや季節に合わせていつでも差し替えられます。 AI の「深掘り」 — 本部が設定した質問に対するスタッフの回答内容を起点に、AI が “なぜ？” を追いかけます。深掘りの仕方はプロンプトで調整でき、本部の仮説や関心を AI に埋め込むことができます。音声入力にも対応しており、閉店後、片手間でも答えられる設計です。 気づきがデータに — AI との一連の対話は、店舗名・日付・カテゴリといった構造化情報に変換され、売上などの定量データと同じ場所に蓄えられます。翌朝、店長や本部側には「売上データ × 現場の気づき」を掛け合わせたインサイトが届きます。 具体例：雨の日に何が起きたのか たとえば、本部が 「今日のお客様の反応で、気になったことは？」 と問いかけたとします。あるスタッフが「雨だったけど、購買率は高かった」と答える。ここで従来のアンケートなら、この回答は「雨 / 購買率高」とタグ付けされて終わります。SMART の場合、ここから AI が 「どんなお客様が来店されましたか？」 と深掘りします。「目的買いの方が多かった気がする。あ、今週発売した限定商品の T シャツを求めにきた若い男性が多く、それに似合うパンツも一緒によく売れました」という回答が返ってくる。この一連のやりとりから、「雨天 × 目的買い → 客単価が上がる可能性」 というインサイトが生まれます。翌朝、同じ問いへの回答が他店舗からも集まっていれば、本部は「この傾向は自店舗固有か、横展開できる学びか」 を、その日のうちに判断する材料として手にできます。 設計思想 — AI を介して、立場の異なる人どうしをつなぐ SMART が目指しているのは、立場の異なる人や組織を、AI やデータを介してつなぐという使い方です。興味深いのは、会話から生まれた気づきがデータ資産として蓄積される点にあります。元のコミュニケーションの当事者間（店舗と本部）を超えて、別の店舗や部門、別の AI エージェントがその資産を活用することができます。たとえば、商品企画の担当者が「去年の同時期、現場ではどんな気づきがあったか」を過去のデータから振り返る、あるいは別の AI が需要予測をするときに現場の声も参考材料にする、といった 他部門・他業務での再活用にも発展することが可能になります。 店舗の第一線と、本部の意思決定、そのあいだに AI エージェントを置くことで、本部の問いが現場に届き、現場の気づきが本部に還ってくる。さらに、その会話そのものが構造化されたコミュニケーションデータとして蓄積され、時間とともに双方の判断を支える資産になっていきます。 AI 任せでも、現場任せでもないこのバランスが、限られた時間のなかで豊かな気づきを引き出す鍵ではないかという仮説を持っています。AI がコミュニケーションを円滑にし、データを蓄積し、立場の異なる双方の意思決定を支える — SMART が目指しているのは、そうした関係性の支援です。 3. SMART を使うと何が起きるか — 画面と 1 日の流れ 3.1 3 つの画面と 1 日の流れ SMART は店舗スタッフと店長、それぞれの時間軸で主に  3 つの画面が連動して動きます。動画と合わせて利用シーンについて説明します。 閉店時に店舗スタッフが実施 ① 日次アンケート画面 — 定型質問に数分で回答 閉店後、店舗スタッフまたは店長がログインして最初に開く画面です。本部が事前に設定した定型質問（星評価・選択式・自由記述・数値）に、数分で回答します。画面上部には管理者や本部からの連絡事項も表示され、日報入力時に考慮して欲しい事項（新商品やキャンペーン、急な店舗オペレーションの変更など）を掲載することで、それに関連する気づきがあれば入力してもらうことを促すことができます。 ② AI チャット画面 — AI が “なぜ” を深掘りする アンケート回答を提出すると、AI チャット画面に移ります。本部が設定したプロンプトに沿って、AI がスタッフの回答を起点に “なぜ” を深掘りします。「なるほど、コラボ T シャツが売れたんですね。それは確かに珍しいから、お客さんも興味を持ちやすいですよね」といった自然な会話で追加ヒアリングが進みます。マイクアイコンから音声入力にも対応しており、片手間でも答えられます。 図1. 閉店時の店舗スタッフの実施イメージ — ① 日次アンケート（本部が設定した定型質問に数分で回答）→ ② AI チャット（本部が設定したプロンプトに沿って AI が追加ヒアリング） 翌朝に店長が実施 ③ Daily Insights 画面 — AI が売上 × 気づきを統合して分析する 翌朝、店長が確認できる AI からのフィードバック画面です。売上金額・購入件数・購入率（前日比・目標比）といった定量データに、前日の店舗スタッフによる日次アンケート回答と AI 対話から抽出した定性の「気づき」を統合し、AI が客観的分析結果を応答します。「売上達成／阻害要因の分析」「AI の気づき」「今日のアクション提案」という形で、本部の意思決定に直結するインサイトが 1 ページにまとまっています。AI に回答して欲しい内容は、プロンプトでチューニングが可能です。なお、売上などの定量データについては、すでにそのデータを管理する DB や DWH システムが別に存在することが一般的であるため、それらと連携するためのカスタマイズが必要となります。またこれらのデータは日次集計されているケースが多いため、翌朝にフィードバック確認の実施を想定しています。 図2. Daily Insights（AI が売上 × 定性データを統合して生成したフィードバック）を確認 3.2 リクエスト〜レスポンスのシーケンス 1 日の中で SMART が行う処理を、閉店後のアンケート入力と AI 対話、翌朝確認するフィードバックに分けて表現すると次のようになります。 図3. SMART のリクエスト〜レスポンスのシーケンス 閉店後はスタッフとの対話（ hearing エージェント）、翌朝は日報生成（ daily_summary エージェント）の 2 つが別のタイミングで動きます。 4. ユナイテッドアローズでの取り組み 4.1 導入の背景と取り組みの概要 ユナイテッドアローズは、1989 年の設立以来、日本のファッションアパレル業界をリードする小売企業です。同社でも「日報が手入力、週報作成には 2,3 時間要している」「店長の記憶頼りで報告粒度が店舗間で異なる」という、多くの小売業に共通する課題を抱えていました。解決するためのアイデアはあるものの、専任の内製開発体制があるわけではなく、企画からモック作成・PoC までに時間がかかることが、新しい仕組みを試すうえでのハードルになっていました。一方、 Kiro をはじめとした AI の活用を進めてきた中で、「今なら自分たちでも開発できるのではないか」という仮説のもと、AWS Prototyping Program を組み合わせて、プロトタイプの作成と内製開発力の獲得を同時に進めるアプローチを採りました。 取り組みは 2025 年 12 月から 2026 年 3 月にかけて、IT 部門、事業部門・店舗スタッフが連携して実施しました。SMART をベースに Kiro を活用して内製でカスタマイズをして、 4 店舗の協力のもと PoC を実行しました。目指したのは、現場の空気感や気づきを鮮度の高いうちに吸い上げ、構造化・データ化して戦略立案の土台にすることです。そして店舗スタッフが接客に集中できる環境を整えることでした。 4.2 店舗スタッフ・店長の声 PoC 後のアンケートでは、「誰もが直感的に操作できる」「曖昧で感覚的な表現を、具体化する質問で引き出してくれる」「『事実・考察・改善案』に分けて整理してフィードバックしてくれる」といった声が寄せられ、複数の設問で 8 割以上のスタッフが「当てはまる」と回答し、高い評価を得ました。 店長からは、こんな声がありました。「昨日の店舗がどうだったかを、わざわざ人に聞かなくてもすぐに把握できるようになった」。さらに想定していなかった変化として、「AI が『なぜ』を深掘りしてくれることで、スタッフ自身に『考える習慣』や『改善行動を意識する姿勢』が広がってきた」という気づきも語られました。日報の入力支援にとどまらず、現場の思考の質そのものに作用しはじめている点が印象的です。 4.3 本部スタッフの声 本部側にも変化がありました。「現場から直接ヒアリングする時間を減らせた」という業務効率の面に加えて、「店舗スタッフを効率よく配置するためのヒントが得られ、売上向上につながる気づきがあった」という、意思決定に直結する手応えも得られています。これまで数字だけでは見えなかった現場の “なぜ” が、定量データと並んで本部に届くようになったことで、施策の打ち手を考える材料が広がりつつあります。 4.4 加藤 大輔 氏のコメント — 開発視点での副次効果 「当初は、店舗スタッフの『日報業務の効率化』を主目的に始めましたが、実際にやってみて最も価値を感じたのは別のところでした。AI からのフィードバックを受けることで現場が能動的に改善を意識して行動するようになったと聞き、大きな手応えを感じています。また、AWS Prototyping Program という AWS さんからの支援 と Kiro を組み合わせたことで、内製開発の経験が少ない私たちでも、企画段階から事業部門とともに課題と要件の解像度を上げながら取り組みを進めることができました。後工程の手戻りや無駄な投資を抑えながらも、何よりチームメンバーの成長を感じることができたことは、今後の社内 DX を進めるうえで大きな財産になっています。」 — 加藤 大輔（IT ソリューション本部 IT セキュリティ部 副部長） 5. アーキテクチャと技術詳細 5.1 全体像 SMART のアーキテクチャーは、次の 3 点を軸に設計しました。 フルサーバーレス — DB・インスタンスなどサーバーレス構成のため、運用負荷が低く、また使われていない時間帯のコストを低く抑えることができます。 CDK ワンコマンドデプロイ — git clone して cdk deploy --all するだけで、約 20 分で環境一式が立ち上がります。 リージョン — デフォルトリージョンを ap-northeast-1 で指定しており、インスタンス・DB・LLM 実行などのデータを国内リージョンにとどめて利用が可能です（グローバル配信を担う Amazon CloudFront とそれに紐づく AWS WAF は us-east-1 に配置されます）。 図4. SMART の AWS アーキテクチャー 各サービスの役割は次の通りです。 レイヤ サービス 役割 フロントエンド配信 Amazon CloudFront + Amazon S3 + AWS WAF React アプリのグローバル配信、アクセス制御 認証 Amazon Cognito（User Pool） JWT トークンベースのユーザー認証、店舗所属グループ管理 Transcribe 認可 Amazon Cognito（Identity Pool） 認証済みユーザーに Transcribe Streaming の最小権限を払い出し 音声入力 Amazon Transcribe Streaming（ ja-JP ） ブラウザの AudioWorklet から送られた音声をリアルタイム文字起こし API エンドポイント Amazon API Gateway（REGIONAL）+ AWS WAF REST API、Cognito Authorizer で認証、WAF で IP・ドメイン制限 API 実行 AWS Lambda（Python 3.13、FastAPI + Mangum） ビジネスロジック、AgentCore Runtime の呼び出し AI エージェント実行 Amazon Bedrock AgentCore Runtime Strands Agents で書いた 2 種類のエージェントをサーバーレスでホスト 会話履歴の永続化 Amazon Bedrock AgentCore Memory セッション単位の短期記憶、actor 単位の長期記憶 LLM Amazon Bedrock（Claude） エージェントの思考・応答生成、日報マークダウンの生成 データ基盤 Amazon S3 Tables（Apache Iceberg）+ Amazon Athena アンケート・売上・チャット履歴・マスタを単一クエリで結合 ここでは、Agent 実行基盤・Agent 構成の 2 つについて解説します。 5.2 Agent 実行基盤 – Amazon Bedrock AgentCore Agent の開発・運用では、Agent の実行場所、メモリ戦略、ログの運用管理など様々な周辺機能が必要になります。特に、メモリ戦略では短期記憶・長期記憶をどう切り分け、どこまで遡り、何を要約するか。それらを自前で実装することもできますが、ここに手をかけすぎずに Agent のコアロジックの実装にできるだけ時間を割きたいと思われる方が多いと思います。 そこで SMART では、Agent を効率的に開発・運用するためのマネージドサービスである Amazon Bedrock AgentCore から、以下 2 つの機能を利用しています。 Amazon Bedrock AgentCore Runtime: AgentCore Runtime は Agent の実行基盤をすぐに立ち上げることができ、フルマネージドのため細かなインスタンスの運用管理が不要です。以下のように、Agent のコード内に Runtime のエントリポイントを定義することで実装できます。 BedrockAgentCoreApp が HTTP リクエストの受け口になり、 @app.entrypoint で関数を登録するだけで、ローカルでもクラウド（AgentCore Runtime）でも同じコードが動くため、ローカルでの検証やデバッグなど開発が行いやすいです。 # backend/store-agent/agentcore_main.py （一部抜粋） from bedrock_agentcore.runtime import BedrockAgentCoreApp from agent_router import route_agent_request app = BedrockAgentCoreApp() @app.entrypoint def invoke(payload, context): return route_agent_request(payload) if __name__ == "__main__": app.run() Amazon Bedrock AgentCore Memory: AgentCore Memory は、細かな Agent Memory ロジックの実装なしにすぐに立ち上げ、使い始めることができ、 Strands Agents とも簡単に連携できます。 AgentCoreMemorySessionManager を Strands Agents の Agent に渡すだけで、会話履歴の取得・保存が自動で行われます。アプリ側で「前回のセッションの取得」や、「プロンプトへの挿入」といったコードを書く必要がありません。 # backend/store-agent/hearing_agent.py （一部抜粋） from strands import Agent from bedrock_agentcore.memory.integrations.strands.config import AgentCoreMemoryConfig from bedrock_agentcore.memory.integrations.strands.session_manager import ( AgentCoreMemorySessionManager, ) def create_hearing_agent(session_id=None, actor_id=None) -> Agent: bedrock_model = get_bedrock_model() system_prompt = _load_system_prompt("hearing_system_prompt.txt") memory_id = config.HEARING_AGENTCORE_MEMORY_ID memory_config = AgentCoreMemoryConfig( memory_id=memory_id, session_id=session_id, actor_id=actor_id ) session_manager = AgentCoreMemorySessionManager( agentcore_memory_config=memory_config, region_name=config.REGION ) agent = Agent( model=bedrock_model, system_prompt=system_prompt, session_manager=session_manager, tools=[], ) return agent 5.3 Agent 構成 SMART の Agent は、 Strands Agents を使って以下の 2 つの Agent を実装しています。 SMART では、Agent のプロンプトをテキストファイルとして Amazon S3 に配置し、バージョニング管理しています。利用開始後にユーザーからのフィードバックや、業務要件の変化に合わせてプロンプトを修正したい時に、アプリケーションの改修なしにすぐにプロンプトを更新することが可能です。 ① ヒアリングエージェント（ hearing ） 閉店後の店舗スタッフへの追加ヒアリングを担います。事前にスタッフが回答したアンケート結果を Agent に渡し、回答の背景にあるコンテキスト情報を引き出す質問を考えます。質問の量や掘り下げる観点でプロンプトを記述しています（ cdk/prompt/hearing_system_prompt.txt ）。 ② 日次サマリエージェント（ daily_summary ）— ツールでデータを引いてレポート生成 翌朝の Daily Insights を生成するエージェントです。こちらは次の 2 つのツール を持ち、それぞれが Athena にクエリを投げてデータを取得します。 get_previous_day_survey_data — 前日の日次アンケート回答を取得（定性データ） get_store_sales_data — 前日の売上金額・来客数・購入件数・購入率・予算達成率などを取得（定量データ） この 2 つを組み合わせることで、「定量 × 定性」の両輪 で AI からのフィードバックを生成します。 6. 今すぐ試してみよう SMART は、 GitHub で公開しています。デプロイ手順や環境準備は、リポジトリの DEPLOYMENT.md をご覧ください。 自社に合わせるカスタマイズポイント SMART をそのまま使うのではなく、自社の業種・業態に合わせて調整するポイントは主に 3 つです。 質問項目 — 管理画面からノーコードで編集できます。 admin_survey テーブルに保存され、キャンペーンや季節などに応じて差し替え可能です。 AI の引き出し方（プロンプト） — 現行実装では cdk/prompt/ 配下のテキストファイルを編集します。自社で本格運用する際は、本部の運用担当者が管理画面から直接編集できる形に発展させることを推奨します。 データソース — backend/store-agent/tools.py に新しい @tool 関数を追加し、 daily_summary_agent.py の tools=[...] に並べれば、基幹システム側の在庫などのデータも AI に参照させて示唆を考えさせることが可能です。 まとめ 「現場の声をどう本部に届けるか」という課題は、小売業に限りません。たとえば飲食チェーンなら、営業後のヒアリングで「今日のランチ帯、満席で断ったお客様はいましたか？」といった本部からの問いに対して、AI が「その時間帯、待ち時間が長かったのは何組くらいですか？」とさらに深掘り。翌朝には、売上・原価率・回転率・スタッフシフトと前日の定性観察を統合した AI の気づきやアクション提案が店舗や本部に届けられます。ほかにも、ホテル・宿泊、物流・倉庫、医療・介護、製造業など、現場スタッフが定量データの裏にある “なぜ” を持っている業界であれば、SMART のひな型を自社に合わせてカスタマイズすることで、活用できるのではないかと考えています。 本記事では、店舗の気づきの言語化を支援し、本部に届ける AI エージェント SMART と、ユナイテッドアローズでの取り組みについてご紹介しました。忙しい店長を助ける仕組みのサンプルとして、ご活用いただけたら幸いです。 AWS Summit Japan 2026 でお会いしましょう 本記事の内容は、 AWS Summit Japan 2026 でも、AWS 濱上がユナイテッドアローズ 加藤氏とのセッションでご紹介します。 セッションID : AIM258（L200） タイトル : 忙しい店長を助ける AI エージェント「SMART」— ユナイテッドアローズと創る、現場の声がデータになる日 日時 : 2026 年 6 月 25 日（木）13:30 – 13:50 会場 : 幕張メッセ ホール7  Theater2 また会場では、ユナイテッドアローズの活用事例ブースでのデモ展示も実施します。 ぜひお立ち寄りください。 著者について 加藤 大輔（Daisuke Kato） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 副部長 セキュリティ、EA（エンタープライズアーキテクチャ）、データ活用領域を担当しています。社内システムの企画・運用や共通基盤の整備を推進しながら、生成 AI の活用による業務効率化や新たな価値創出に取り組んでいます。 好きな AWS サービスは Amazon Elastic Container Service です。 池添 雄起（Yuki Ikezoe） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 データ連携基盤、システム監視基盤を担当しています。好きな AWS サービスは Kiro です。 大橋 遼子（Ryoko Ohashi） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 業務効率化アプリの企画・開発に取り組んでいます。好きな AWS サービスは Amazon Bedrock です。 石橋 直樹（Naoki Ishibashi） アマゾン ウェブ サービス ジャパン合同会社 ML プロトタイピングエンジニア AWS では生成 AI・MLOps など AIML に関連するプロトタイピング開発、技術相談などの支援を中心に行っています。好きな AWS サービスは Amazon SageMaker AI です。好きなファッションブランドは、UNITED ARROWS green label relaxing です。 濱上 和也（Kazuya Hamagami） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 流通・小売業のお客様の技術支援を行っています。好きな AWS サービスは Amazon Connect Customer で、業界問わずコンタクトセンター関連の技術支援も行っています。好きなファッションブランドは、UNITED ARROWS green label relaxing です。

エンジニアリング組織で Claude Code のような AI コーディングエージェントを利用している場合、その利用は追跡できる速度を上回って増加している可能性が高いでしょう。トークン消費量、チームごとのコスト、開発者の生産性といった疑問に既存のダッシュボードが答えられないのは、テレメトリがそもそもオブザーバビリティバックエンドに届いていないためです。 Amazon CloudWatch の OpenTelemetry Protocol（OTLP）が 一般提供 となったことで、ベアラートークン認証によるメトリクスの取り込みが可能になりました。これにより、OTLP を出力するツールは通常、認可ヘッダー 1 つだけでメトリクスを直接 CloudWatch に送信できます。コレクターもサイドカーも、開発者マシン上での IAM 認証情報の配線も不要です。数分でシグナルを接続し、開発者ごとのコスト按分、チーム単位の利用分析、運用アラートを実現でき、すべて Prometheus Query Language（PromQL）でクエリできます。 本記事では、Claude Code 向けのエンドツーエンドのセットアップを解説します。ここでは Claude Code に焦点を当てますが、OpenAI Codex と GitHub Copilot に関する包括的なガイダンスは AWS Observability ベストプラクティス で提供しています。本記事では、開発者マシン上でのシンプルさを重視してベアラートークン認証に焦点を当てます。開発者認証に SSO（シングルサインオン）や OIDC（OpenID Connect）を必要とする組織は、フェデレーテッドアイデンティティのパターンやトークン更新ヘルパーについて ガイダンスリポジトリ を参照してください。 ベアラートークン認証 ベアラートークン（CloudWatch メトリクス API キー）を使用すると、AWS の外部で動作するツール（開発者のノート PC 上の Claude Code など）が、AWS SDK や IAM 認証情報チェーンを必要とせずに CloudWatch へメトリクスを送信できます。各トークンは、 CloudWatchAPIKeyAccess 管理ポリシーのみにスコープされた AWS IAM ユーザーに紐づけられます。 重要： ベアラートークンは長期的な認証情報です。本記事では、AI コーディングエージェントが AWS 外部の開発者ノート PC 上で動作するため、ベアラートークンを使用します。SigV4 認証では、中央集約型のコレクターを用意するか、すべての開発者マシンでコレクタープロセスを実行する必要があります。いずれの方式も運用上の複雑さを増します。ベアラートークンはそのインフラ要件を完全に排除します。短期的な認証情報を用いた SigV4 が実現可能な AWS 内部で動作するワークロードでは、より強固なセキュリティ態勢のためにそちらの方式を推奨します。CloudWatch の OTLP エンドポイントは HTTPS を必須とし、平文 HTTP でのリクエストは拒否されます。詳細は CloudWatch OTLP Metrics Bearer Token Auth を参照してください。 粒度（granularity）戦略 組織は、ベアラートークンをどのようにプロビジョニングするかによって、テレメトリ属性の粒度を制御します。最も細かいレベルでは、各開発者が専用の IAM ユーザーとベアラートークンを持つため、属性はトークン自体に内在します。より粗いレベルでは、単一のトークンをチーム全体や組織全体で共有し、アイデンティティの属性は代わりにクライアント側のリソース属性で処理します。次の図は、これら 3 つのアプローチを示しています。 図 1：トークン粒度戦略のオプション（開発者ごと、チームごと、組織全体＋クライアント側属性の 3 アプローチ） 3 つのアプローチはいずれも同一のダッシュボードと PromQL クエリを生成します。属性がトークン自体ではなくリソース属性によって駆動されるためです。まずは単一の共有トークンでパイプラインを検証し、その後セキュリティ態勢の要件に応じてチームごと、または開発者ごとのトークンに分割してください。コンプライアンス上、特定個人に紐づけ可能な認証情報が求められる場合や、クリーンなオフボーディング（単一 IAM ユーザーの失効）が必須要件である場合には、開発者ごとのトークンを推奨します。 前提条件 CloudWatch リソースを作成する権限を持つ AWS アカウント インストール・設定済みの AWS CLI v2 最新バージョンの Claude Code CloudWatch メトリクス API キー（以下で生成） コンソールでベアラートークンを作成する CloudWatch コンソールで、 セットアップ(Setup)  セクション配下の  設定(Settings) 配下の グローバル(Global)  に移動します。 API キー(API Keys)  までスクロールします。 作成(Create) を選択します。 API キーの有効期限(API key expiration) を選択します。 CloudWatch が、 CloudWatchAPIKeyAccess ポリシーをアタッチした関連 IAM ユーザーを代わりに作成します。 図 2：CloudWatch コンソールの Settings ページでベアラートークンを作成する CLI でベアラートークンを作成する あるいは、以下のコマンドで CLI を使ってトークンを作成します。 # CloudWatch メトリクス取り込み用の IAM ユーザーを作成 aws iam create-user --user-name cloudwatch-metrics-api-key-user # CloudWatchAPIKeyAccess 管理ポリシーをアタッチ aws iam attach-user-policy \ --user-name cloudwatch-metrics-api-key-user \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAPIKeyAccess # CloudWatch メトリクス取り込み用のサービス固有認証情報を作成 aws iam create-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-name cloudwatch.amazonaws.com レスポンスには ServiceCredentialSecret フィールドが含まれ、これがベアラートークンの値です。 AWS Secrets Manager または組織の Vault ソリューションに安全に保管してください。トークンは決してバージョン管理にコミットしないように注意してください。鍵の自動ローテーションには、 Lambda 関数を用いた AWS Secrets Manager のローテーション を利用してください。 クライアント側の設定 ベアラートークンを設定したら、メトリクスをエクスポートするように Claude Code を構成できます。このアプローチでは、各開発者が設定する（またはプロファイル管理で配布する）クライアント側のリソース属性を使用します。 # Secrets Manager からトークンを取得 BEARER_TOKEN=$(aws secretsmanager get-secret-value \ --secret-id cloudwatch-otlp-bearer-token \ --query SecretString \ --output text) export CLAUDE_CODE_ENABLE_TELEMETRY=1 export OTEL_METRICS_EXPORTER=otlp export OTEL_EXPORTER_OTLP_PROTOCOL=http/json export OTEL_EXPORTER_OTLP_ENDPOINT="https://monitoring.<AWS_REGION>.amazonaws.com" export OTEL_RESOURCE_ATTRIBUTES="user.id=$(whoami),user.email=${USER_EMAIL},team.id=${TEAM:-engineering},cost_center=${COST_CENTER:-default},department=${DEPARTMENT:-engineering},environment=${ENV:-dev}" # セキュリティ上の注意：環境変数はプロセス一覧やシェル履歴から露出する可能性があります。 export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer ${BEARER_TOKEN}" # エクスポート頻度の制御（テスト用に 2 秒） export OTEL_METRIC_EXPORT_INTERVAL=2000 <AWS_REGION> はお使いのリージョン（例： us-east-1 、 eu-west-1 ）に置き換えてください。 OTEL_RESOURCE_ATTRIBUTES の行は、すべてのメトリクスにアイデンティティのディメンションを付与します。開発者がこれらの属性を直接設定します。これらはダッシュボードやアラートでフィルタリング・グループ化するための PromQL ラベルになります。組織が必要とする任意の属性を使用してください。重要な要件は、集計が機能するようにフリート全体で一貫性を保つことです。 属性 目的 例 user.id 開発者ごとの属性 jdoe user.email 開発者ごとの属性（メール） jdoe@acme.com team.id チーム単位の集計 platform-eng cost_center 財務／チャージバックのグループ CC-4200 department 組織単位のロールアップ engineering environment dev／staging／prod の利用区別 production 利用可能な標準属性とメトリクスの完全な一覧は、 Claude Code のドキュメント で確認できます。 テレメトリ設定とプライバシー制御をフリート全体に強制するために、Claude Code は組織のプロファイル管理ソリューションを通じてデプロイ可能な 管理者管理の設定 をサポートしています。 メトリクスが流れていることを確認する 環境変数を設定したら、短い Claude Code セッションを実行します。 # 短いセッションを開始 claude -p "Let's conquer the world" --max-turns 1 メトリクスが流れていることを確認するには、 CloudWatch Query Studio を開いて claude_ と入力します。使用されたトークン数を追跡する claude_code.token.usage など、いくつかのメトリクスが表示されます。 図 3：CloudWatch Query Studio でメトリクスの取り込みを確認する サンプル利用状況ダッシュボード 前述の粒度戦略に関わらず、PromQL を使って Claude Code のテレメトリデータをクエリする CloudWatch ダッシュボード が用意されています。リソース属性がクライアント側設定セクションで説明したセマンティック規約に従っている限り、すべての値が自動的にダッシュボードに表示されます。 構築済みダッシュボードをデプロイします。 # ダッシュボード定義をダウンロード curl -o claude-code-dashboard.json \ https://raw.githubusercontent.com/aws-observability/aws-observability-accelerator/main/artifacts/cloudwatch-dashboards/claude-code/claude-code.json aws cloudwatch put-dashboard \ --dashboard-name claude-code-usage \ --dashboard-body file://claude-code-dashboard.json \ --output off \ --region <AWS_REGION> ダッシュボードが作成されたことを確認します。 aws cloudwatch list-dashboards --dashboard-name-prefix claude-code --region <AWS_REGION> ダッシュボードは 5 つのセクションで構成されています。まずステークホルダーが全体の健全性を一目で評価できるよう高レベルのサマリーから始まり、その後トークンの経済性、開発者の活動、組織のコスト配分、インフラの健全性へと段階的に掘り下げていきます。 概要 最上段には、消費トークン総数、アクティブユーザー数、総セッション数、キャッシュヒット率を含むサマリーが表示されます。OTel メトリクスを Amazon CloudWatch に送信するように構成したリージョンを選択してください。 図 4：総トークン数、アクティブユーザー数、セッション数、キャッシュヒット率を示す概要サマリーカード トークン使用量 このセクションは、エンジニアリングリーダーが最初に問う質問に答えます。「どれだけ消費していて、その内訳はどこにあるのか？」。トークン消費を時系列、種類別（入力、出力、キャッシュ読み取り、キャッシュ作成）、モデル別、ユーザー別、推定コスト別に分解します。これらのパネルを使って、どのモデルが支出を牽引しているか、どのユーザーが最も多く消費しているかを特定できます。 図 5：時系列の消費量、種類別の内訳、モデル別の使用量、上位ユーザー、ユーザーごとの推定コスト、アクティブユーザーの推移を示すトークン使用量セクション 開発者の生産性 コストにとどまらず、このセクションでは開発者がツールで実際に生み出しているものを追跡します。追加・削除されたコード行数、コミット数、アクティブなコーディング時間、作成されたプルリクエスト、コード編集パターンなどです。言語別の内訳円グラフは、コードベースのどの部分が AI 支援から最も恩恵を受けているかを明らかにします。コード編集の判断パネル（承認 vs 却下）は、エージェントの提案が開発者の意図とどれだけ合致しているかのシグナルになります。 図 6：コード行数、コミット数、アクティブ時間、プルリクエスト、言語分布、コード編集の承認／却下率を示す開発者生産性メトリクス 組織別の内訳 複数のチームや部門を持つ組織向けに、このセクションはコスト配分のビューを提供します。これらのパネルは、クライアント側設定セクションで構成した department および team.id リソース属性に直接対応します。チャージバック、予算計画、組織内のどこがツールを最も効果的に活用しているかの特定に活用してください。 図 7：部門別およびチーム別のトークン使用量を示す組織別内訳 Amazon Bedrock API の健全性 Claude Code のバックエンドとして Amazon Bedrock を使用している場合、ダッシュボードにはインフラの健全性パネルも含まれます。これらはモデル別に分類されたスロットリングイベント、クライアントエラー、サーバーエラーを表示します。開発者から報告された問題（応答の遅延、リクエストの失敗）を上流の API の挙動と関連付けるのに活用してください。 アラート ダッシュボードのすべてのパネルは PromQL クエリに支えられています。任意のパネルからアラームを作成するには、次の手順を実行します。 関心のあるパネル（例：ユーザー別トークン使用量）を開きます。 View in Query Studio を選択して、基になるクエリを開きます。 Query Studio から直接 Create alarm を選択します。 必要に応じてクエリやしきい値を調整します。 ダッシュボードが示す範囲を超えるシナリオに対して、カスタムの PromQL アラームクエリを記述することもできます。いくつか例を挙げます。 個人の支出スパイク ある人物が 1 時間で前日 1 日分の支出の 2 倍以上を費やした場合、それは異常を示します。これは暴走ループ、スタックしたエージェント、または侵害されたトークンを検知します。 sum by("user.email") (increase({"claude_code.cost.usage"}[1h])) > 2 * sum by("user.email") (increase({"claude_code.cost.usage"}[24h])) 図 8：ユーザーの 1 時間あたりの支出が 1 日分の支出を上回ったときにトリガーする PromQL アラーム チーム予算のしきい値 チームの 1 日の支出が定義した予算を超えたときにアラートを出します。 sum by ("team.id") (increase({"claude_code.cost.usage"}[24h])) > 500 利用の減少 チームの 1 日のセッション数が 7 日間平均の 50% を下回ったときに検知します。これはツールの問題やアクセスの問題の可能性を示すシグナルです。 sum by ("team.id") (increase({"claude_code.session.count"}[1d])) < 0.5 * avg_over_time(sum by ("team.id") (increase({"claude_code.session.count"}[1d]))[7d:1d]) Amazon Managed Grafana でダッシュボードを使用する Amazon Managed Grafana またはセルフマネージドの Grafana を使用している場合は、 Grafana からのクエリに関するドキュメント に従って CloudWatch を PromQL データソースとして追加し、 Grafana ダッシュボード JSON をインポートしてください。 コスト見積もり 各開発者が 1 日あたり約 20 セッションを実行し、それぞれがリソース属性付きで約 7 つのメトリクスデータポイントを出力し、開発者が月あたり約 22 日アクティブな、開発者 200 名の組織の場合： 10〜15 個の属性を持つ一般的な OTLP データポイントは 300〜600 バイトです。中間値として 450 バイトを使用すると： 200 開発者 × 20 セッション/日 × 7 メトリクス × 450 バイト = 12.6 MB/日 12.6 MB/日 × 22 日 = 約 277 MB/月 ≒ 0.27 GB/月 取り込み料金 $0.50/GB では、基本ケースで月あたり約 $0.14 です。高カーディナリティのメトリクス（100 倍のボリューム）でも、取り込み総額は月あたり $14 未満にとどまります。CloudWatch コンソールでの PromQL クエリは 無料 です。 この例における開発者 200 名分の総コストは、月あたり $15 未満 になります。 最新情報については Amazon CloudWatch 料金ページ を参照してください。 クリーンアップ 重要： CloudWatch はメトリクスを最大 15 か月間、無料で保持します。継続的なコストとセキュリティ上の露出を避けるため、アラームと IAM リソースを削除してください。 作成したすべてのリソースを削除するには、次のコマンドを実行します。 # ダッシュボードを削除 aws cloudwatch delete-dashboards --dashboard-names claude-code-usage --region <AWS_REGION> # CloudWatch アラームを削除 aws cloudwatch delete-alarms --alarm-names <alarm-name> --region <AWS_REGION> # サービス固有認証情報を削除 aws iam delete-service-specific-credential --user-name cloudwatch-metrics-api-key-user --service-specific-credential-id <credential-id> # IAM ユーザーからポリシーをデタッチ aws iam detach-user-policy --user-name cloudwatch-metrics-api-key-user --policy-arn arn:aws:iam::aws:policy/CloudWatchAPIKeyAccess # IAM ユーザーを削除 aws iam delete-user --user-name cloudwatch-metrics-api-key-user # Secrets Manager を使用している場合はシークレットを削除 # 警告：シークレットの削除は不可逆です。ベアラートークンは復元できません。 # 続行する前に、トークンが不要であることを確認してください。 aws secretsmanager delete-secret --secret-id <secret-name> --region <AWS_REGION> テレメトリのエクスポートを停止するには、環境変数の設定を解除するか、シェルプロファイルから削除します。 unset CLAUDE_CODE_ENABLE_TELEMETRY OTEL_METRICS_EXPORTER OTEL_EXPORTER_OTLP_ENDPOINT OTEL_EXPORTER_OTLP_HEADERS OTEL_RESOURCE_ATTRIBUTES まとめ 本記事では、ベアラートークン認証を使用して OpenTelemetry メトリクスを Amazon CloudWatch にエクスポートするように Claude Code を構成し、コストと利用状況を可視化する PromQL ベースのダッシュボードをデプロイし、支出の異常と利用の減少に対するアラートを設定しました。 同じ CloudWatch OTLP エンドポイントは、IDE エージェントだけでなく、OpenTelemetry で計装されたあらゆるワークロードからのテレメトリを受け付けます。複数のアカウントとリージョンを持つ大規模組織向けに、一般提供では クロスアカウント・クロスリージョンのメトリクス集約 も導入されました。これにより、統一された可視性を実現するために単一のオブザーバビリティアカウントへメトリクスを収集できます。 GitHub Copilot および OpenAI Codex 向けの IDE オブザーバビリティのセットアップ方法については、 完全ガイド をご覧ください。 TAGS: Amazon CloudWatch , Amazon Managed Grafana , Monitoring & Observability   本記事は、 Analyzing Claude Code usage with CloudWatch and OpenTelemetry を翻訳したものです。 翻訳は Solutions Architect の 津和崎 が担当しました。 Rodrigue Koffi Amazon Web Services のオブザーバビリティ担当スペシャリストソリューションアーキテクト。オブザーバビリティ、分散システム、機械学習に情熱を注ぐ。強力な DevOps とソフトウェア開発のバックグラウンドを持ち、Go でのプログラミングを好む。業務外では水泳と家族と過ごす時間を楽しむ。LinkedIn：/grkoffi Gianluca Cacace アイルランド・ダブリンの Amazon Web Services のプリンシパルエンジニア。オブザーバビリティを専門とし、大規模システムにおけるスケーラビリティと設計課題に情熱を注ぐ。余暇には旅行と個人プロジェクトを楽しむ。 Vadim Omeltchenko シニア AI/ML ソリューションアーキテクト。AWS のお客様がクラウドでイノベーションを起こすことを支援することに情熱を注ぐ。以前の IT 経験は主にオンプレミス環境でのもの。

re:Invent 2025 では、開発ライフサイクル全体を通じてあらゆる環境でアプリケーションをプロアクティブに保護するフロンティアエージェントである AWS セキュリティエージェント (現在は AWS Continuum の一部) を プレビュー公開しました 。アプリケーションに合わせてカスタマイズされたオンデマンドのペネトレーションテストを実行し、悪用可能性テストで検証されたセキュリティリスクを検出して報告できます。 プレビュー公開後、 オンデマンドのペネトレーションテスト の一般提供の開始と、コードベース全体に対してコンテキストを考慮した詳細なセキュリティ分析を実行する フルリポジトリコードレビュー のプレビューを発表しました。 6 月 17 日は、お客様からのフィードバックに基づき、さらに多くの機能をご紹介します: コードレビューのアップデート (プレビュー) – 是正、セキュリティ要件パック、シミュレーション検証とともに、プルリクエストスキャンを使用できるようになりました。新しい統合は、GitHub、GitLab、Bitbucket、Confluence をサポートします。 脅威モデリング (プレビュー) – AWS セキュリティエージェントは、設計ドキュメントまたはアプリケーションのソースコードを分析し、アプリケーションアーキテクチャのコンテキスト全体を理解して、STRIDE フレームワークを使用して脅威を特定し、推奨される緩和策を提示します。 Kiro パワー、Claude Code プラグイン、および MCP 統合 – オープンな MCP 統合を通じて、IDE、CLI、または AI を利用した IDE から直接、コードレビューの実行、脅威モデルの生成、および検出結果の是正を行うことができます。結果はコンテキストを切り替えることなく、インラインで表示されます。 各リリースの詳細を見てみましょう! コードレビューのアップデート GitHub に加えて、GitLab と Bitbucket にも接続できるようになりました。SaaS バージョンとセルフホストバージョンの両方をサポートしているため、コードが存在する場所にかかわらず、スキャンをトリガーできます。また、Confluence を統合して、既存のドキュメントをレビューのコンテキストとして参照することもできます。 開始するには、 [コードレビューを有効にする] を選択するか、または セキュリティエージェントコンソール でコードレビューの設定を更新します。 AWS セキュリティエージェントは、パターンマッチングでは検出できない複雑な脆弱性を特定するために、あらゆるプルリクエストとリポジトリ全体に対する高度な推論ベースの分析を提供します。組織のセキュリティ要件と一般的なセキュリティリスクに照らしてチェックすることで、他のツールでは検出できない脆弱性を検出します。開始するには、セキュリティエージェントのウェブアプリケーションにアクセスしてコードレビューを実行します。 セキュリティチームがモニタリング対象のリポジトリを設定し、重大な問題に介入している間、修正コミットと是正ガイダンスが GitHub、GitLab、または Bitbucket のワークフロー内で直接提供されます。AWS セキュリティエージェントは、悪用可能性を実証するために、シミュレーション環境で検出結果を検証します。これにより、すべてのリポジトリにセキュリティの専門知識が組み込まれ、開発パイプラインにおけるセキュリティ関連の遅延を削減できます。 新しいコードレビュー機能の詳細については、「AWS セキュリティエージェントユーザーガイド」の「 Create a code review 」にアクセスしてください。 設計レビューの更新 マネージドコンプライアンスパック ( AWS WAF 、 NIST CSF 、 PCI DSS 、AWS ベストプラクティス) を使用することで、あらゆる設計およびコードレビューにおいてセキュリティ要件を継続的に検証できます。また、社内ドキュメントや Confluence から直接、組織独自の要件をインポートすることも可能です。あらゆる検出結果はコンプライアンス体制にマッピングされるため、チームは構築を進めながら監査対応体制を維持できます。 詳細については、 設計レビューのドキュメント にアクセスしてください。 脅威モデリング AWS セキュリティエージェントは、設計ドキュメントまたはコードリポジトリに基づいて脅威モデルを生成し、データフロー、アーキテクチャ、信頼の境界など、アプリケーションに関するコンテキストを作成および構築します。アプリケーションのすべてのコンポーネントをマッピングし、潜在的な脅威アクターと攻撃ベクトルを特定するとともに、脆弱性が存在する可能性のある箇所を特定して、脅威に優先順位を付けることで、最初に対処すべき脅威を明確にします。 開始するには、 セキュリティエージェントコンソール で [脅威モデルを有効にする] と [ソースコードリポジトリを接続] を選択します。 詳細については、 脅威モデリングのドキュメント にアクセスしてください。 AWS セキュリティエージェント用の Kiro パワーおよび Claude Code プラグイン AWS セキュリティエージェントは、新しい Kiro パワー および Claude Code プラグイン (近日リリース予定) を導入します。アプリケーションを保護するために、オープン MCP 統合を通じてあらゆる AI IDE と統合できます。IDE から直接脅威モデルとコードレビューをトリガーでき、コンテキストを切り替えることなく、結果がインラインで表示されます。 開始するには、 Kiro パワー をインストールし、プロンプトを実行します。 Kiro パワーは、 AWS セキュリティエージェント MCP サーバー を使用します。「 Set up AWS Security Agent 」と指示することで、パワーの使用を開始できます。 Kiro は、エージェントスペースが存在するかどうかを確認し、既存のスペースを使用するか、または新しいスペースを作成するかをたずねます。 セキュリティエージェント向けの Kiro パワーを使用すると、 「 Run a full security scan on this repo 」と指示することで、構築する際にあらゆるプルリクエストで脆弱性を検出し、リポジトリ全体をスキャンして蓄積されたリスクを明らかにすることができます。セキュリティエージェントのパワーには、Kiro エージェントの処理完了後にコードレビュー差分スキャンを開始すべきかどうかを評価するエージェントフックが含まれています。本番にデプロイする前に、CLI からペネトレーションテストを実行して、ほとんどのスキャナーが見逃す脆弱性を見つけることができます。セキュリティエージェントは、あらゆる検出結果を検証し、すぐに実装できるコード修正を生成することで、ループを完結させます。 「 help me remediate my findings 」と指示することで、検出結果を開発環境にプルできます。AWS セキュリティエージェント用の Kiro パワーは、検出結果をローカルワークスペースにダウンロードし、最も重要な検出結果を優先して、バグ修正仕様セッションの開始を提案します。使い慣れた IDE と既存のツール、ステアリング、パワー、および MCP サーバーを使用して、検出結果の修正をイテレーションできます。 また「 Build a threat model for this application 」と指示することによって、IDE で Kiro パワーを通じて脅威モデルを実行することもできます。 生成された脅威モデルは .security-agent/threat_model.md に保存されます。 詳細については、 セキュリティエージェント用の Kiro パワー にアクセスしてください。 今すぐご利用いただけます AWS セキュリティエージェントは、設計段階のセキュリティ (設計レビューと脅威モデリングはプレビュー)、開発段階のセキュリティ (コードレビューはプレビュー)、デプロイ段階のセキュリティ (ペネトレーションテストは一般提供開始) を、単一の統合エージェントソリューションでカバーすることで、ソフトウェア開発ライフサイクル全体にわたる完全なセキュリティコンテキストを理解します。詳細については、AWS セキュリティエージェントの 製品ページ と 技術文書 をご覧ください。 これらの機能は、AWS セキュリティエージェントが利用可能な AWS 商用リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。料金に関する詳細と、2 か月間の無料トライアルオファーへのアクセスについては、 AWS セキュリティエージェントの料金ページ にアクセスしてください。 セキュリティエージェントのコンソール でお試しいただき、 AWS re:Post for Security Agent 宛てに、または通常の AWS サポートの連絡先担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

2026 年 6 月 18 日、AI 推論、グラフィックス、データ分析のワークロード向けに高性能な GPU アクセラレーションを提供する Amazon Elastic Compute Cloud (Amazon EC2) G7 インスタンスの一般提供の開始を発表しました。 AWS は、NVIDIA RTX PRO 4500 Blackwell Server Edition GPU をサポートする最初の主要クラウドプロバイダーです。G7 インスタンスは、これらの GPU と第 6 世代のカスタムインテル Xeon Scalable プロセッサを組み合わせることで高速化されており、 G6 インスタンス と比較して、最大 4.6 倍の AI 推論パフォーマンスと最大 2.1 倍のグラフィックスパフォーマンスを実現します。また、G7 インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 上の Amazon EMR における GPU アクセラレーテッド分析でも、より高速なパフォーマンスを発揮します。G7 インスタンスは、AI 推論、グラフィックスレンダリング、動画トランスコーディングおよび分析、空間コンピューティング、仮想デスクトップインフラストラクチャ (VDI)、データ分析など、GPU を活用する幅広いワークロードに適しています。 前世代と比較した G7 インスタンスの改善点は次のとおりです: より高速な GPU メモリ – NVIDIA RTX PRO 4500 Blackwell Server Edition GPU は、G6 インスタンスと比較して 1.33 倍の GPU メモリ容量と 2.45 倍の GPU メモリ帯域幅を提供します。GPU あたり 32 GB の GPU メモリ、第 5 世代 Tensor コア、第 4 世代 RT コアを搭載し、AI 推論およびグラフィックスパフォーマンスが向上しています。 高パフォーマンスのネットワーキングとストレージ – G7 インスタンスは、700 Gbps の EFA 対応ネットワーキングスループット (G6 と比較して 7 倍) を備えています。これにより、AI 推論、グラフィックス負荷の高いアプリケーション、GPU アクセラレーテッドデータ分析ワークロードが最高のパフォーマンスを発揮するために必要な、低レイテンシーで広帯域の接続を実現します。G7 インスタンスは最大 7.6 TB のローカル NVMe SSD ストレージをサポートしており、大規模なモデルやデータセットをコンピューティングの近くに保持することで、データ転送のオーバーヘッドを削減し、スループットを改善できます。 高度な動画エンコーディングおよびデコーディングエンジン – 第 9 世代 NVENC および第 6 世代 NVDEC エンジンは、高解像度動画ワークフロー向けの 4:2:2 エンコーディングおよびデコーディングをサポートしており、前世代の G6 インスタンスと比較して 1.5 倍の同時動画ストリームを実現します。 EC2 G7 インスタンスの仕様 G7 インスタンスには、最大 256 GB の合計 GPU メモリ (GPU あたり 32 GB のメモリ) を提供する最大 8 個の NVIDIA RTX PRO 4500 Blackwell Server Edition GPU と、カスタムインテル Xeon Scalable プロセッサが搭載されています。また、7 つのサイズでご利用いただけるほか、最大 192 個の vCPU、最大 700 Gbps のネットワーク帯域幅、最大 768 GiB のシステムメモリ、最大 7.6 TB のローカル NVMe SSD ストレージもサポートしています。 仕様は次のとおりです: インスタンス名 GPU GPU メモリ (GB) vCPU 数 メモリ (GiB) ストレージ EBS 帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) g7.2xlarge 1 32 8 32 1 x 600 最大 8 最大 60 g7.4xlarge 1 32 16 64 1 x 600 8 最大 100 g7.8xlarge 1 32 32 128 1 x 950 16 最大 100 g7.12xlarge 2 64 48 192 1 x 1900 20 175 g7.24xlarge 4 128 96 384 1 x 3800 40 350 g7.48xlarge 8 256 192 768 2 x 3800 80 700 g7.metal* 8 256 192 768 2 x 3800 80 700 * 近日リリース予定 G7 インスタンスは、マルチ GPU サイズ向けの NVIDIA GPUDirect P2P、EFA を使用した NVIDIA GPUDirect RDMA、および Amazon FSx for Lustre 向けの EFA を使用した GPUDirect RDMA をサポートしており、マルチ GPU およびマルチノードのワークロードにおいて低レイテンシーの GPU 間通信を可能にします。 G7 インスタンスの使用を開始するには、AI 推論やグラフィックスワークロード向けに事前パッケージ済みの GPU ドライバーを備えた AWS Deep Learning AMI (DLAMI) または NVIDIA Workstation AMI を使用できます。Amazon EKS で G7 インスタンスを使用するには、 EKS が提供するオートメーション を使用して、NVIDIA ドライバーバージョン R595 を含む EKS AMI を構築してください 。 G7 インスタンスは、Amazon Linux、Ubuntu、RHEL、Windows Server など複数のオペレーティングシステムをサポートしており、包括的な NVIDIA ドライバーの統合により、DirectX、Vulkan、OpenGL などの業界標準のグラフィックスライブラリとの互換性を提供します。 今すぐ始めましょう Amazon EC2 G7 インスタンスは、米国東部 (オハイオ) と米国西部 (オレゴン) の 2 つの AWS リージョンで今すぐ利用を開始できます。今後のリージョン展開計画を確認するには、「 AWS サービス (リージョン別) 」ページの CloudFormation リソースタブでインスタンスタイプを検索してください。 G7 インスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス など、複数の購入オプションを通じて提供されています。 12xlarge 、 24xlarge 、 48xlarge のサイズでは、 ハードウェア専有インスタンス もサポートされています。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から G7 インスタンスを起動してください。詳細については、「 Amazon EC2 G7 instances 」ページをご覧ください。フィードバックをぜひお寄せください。 AWS re:Post for EC2 で共有いただくか、または通常の AWS サポート担当者を通じてご連絡ください。 – Daniel Abib 原文は こちら です。

2026 年 6 月 17 日、 Amazon Bedrock マネージドナレッジベース を発表しました。これは、デベロッパーが所有データを使用してエンタープライズグレードの生成 AI アプリケーションを数分で構築できるようにする新しい機能セットです。エージェンティック AI アプリケーションを構築する組織は、正確かつ迅速で信頼性の高い結果をもたらすために、企業全体のデータへの、セキュアで信頼性の高い最新のアクセスを必要とします。マネージドナレッジベースは、検索拡張生成 (RAG) パイプラインの構築と管理の複雑さを抽象化し、デベロッパーがインフラストラクチャ管理ではなく、ビジネス成果の実現に注力できるようにします。 今日、エージェント向けのナレッジベースを構築するデベロッパーは、3 つの主要な課題に直面しています: エンタープライズデータへの接続 – エンタープライズナレッジは、コンテンツタイプ、アクセスコントロールリスト、ドキュメント形式が異なる、さまざまなシステムに分散して存在しています。各ソースごとにカスタムコネクタを構築および維持することは、開発の複雑さを増大させ、開発速度を低下させます。 RAG 精度の最適化 – 検索拡張生成に関するベストプラクティスは進化し続けています。デベロッパーは、データから正確な回答を得るために、さまざまな解析戦略、チャンキングアプローチ、埋め込みモデル、エージェンティック検索動作を実験する必要があります。 インフラストラクチャの大規模な管理 – 組織は、数百万のドキュメントを含む大規模なナレッジベースを運用したり、チーム間で数千の小規模なナレッジベースを管理したりする必要があります。いずれのパターンでも、信頼性の高いインフラストラクチャ、セキュリティ対策、コスト管理が不可欠です。 これらの課題により、デベロッパーは、アプリケーションに注力するのではなく、差別化につながらない作業を繰り返し実行せざるを得なくなります。 Amazon Bedrock マネージドナレッジベースは、デベロッパーが従来自らアセンブルおよび維持しなければならなかった複数のインフラストラクチャコンポーネント (ストレージ、検索、埋め込み、再ランキング、基盤モデルの選択など) を単一のマネージドプリミティブに抽象化することで、これらの課題を解決します。デフォルトでは、サービスがデフォルトの埋め込みモデル、再ランキング付けモデル、基盤モデルを自動的に選択および管理するため、お客様は、モデルを選択したり、管理したりすることなく、すぐに使用を開始できます。このマネージド基盤に加えて、使いやすさと精度をさらに高める 3 つの主要なイノベーションがあります: ネイティブデータコネクタ – エンタープライズデータと許可を SaaS アプリケーションからネイティブにプルする 6 つの事前構築済み取り込みコネクタにより、デベロッパーがアプリケーション固有の要件を管理する際のオーバーヘッドがなくなります。リリース時点では、Amazon S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive がサポートされています。 Smart Parsing – コンテンツのタイプやソースによって、正確な検索を実現するために必要なアプローチは異なります。Smart Parsing は、この複雑さを自動的に処理し、各データタイプとコネクタに適したパーシング戦略を選択することで、エージェントのために極めて高い精度を提供します。 Agentic Retriever – 単一のナレッジベース内、または複数のナレッジベースにまたがる、マルチターン、マルチホップの検索を必要とする複雑なクエリ向けに最適化されています。Agentic Retriever は、エンドユーザーの意図を自動的に推測し、複数のデータソースやモダリティにわたって分散した組織のナレッジから関連するコンテキストを抽出します。 わずか数行のコードで、Amazon Bedrock マネージドナレッジベースは、エンタープライズナレッジエージェントを支えるエンドツーエンドの RAG パイプラインを自動的に管理およびスケールします。エージェントビルダー向けに、 Amazon Bedrock AgentCore Gateway で事前構築済みのターゲットタイプとして利用可能となっています。これにより、統合はわずか数行のコードで済むほか、ロールベースの許可が自動生成され、AgentCore Observability ダッシュボードでオブザーバビリティと評価メトリクスが提供されます。 Amazon Bedrock マネージドナレッジベースの開始方法 マネージドナレッジベースの作成は簡単です。 Amazon Bedrock AgentCore コンソール または Amazon Bedrock コンソール に移動し、 [ナレッジベース] ページを開いて、 [マネージド KB を作成] を選択します。操作感はいずれのコンソールでも同じです。既に慣れ親しんでいるかもしれない他のナレッジベースのタイプに加えて、推奨オプションとして [非構造化ベクトルストア KB] が利用可能になっています: 図 1 – Amazon Bedrock AgentCore コンソールのナレッジベースのリストページ。[タイプ] 列にさまざまな KB タイプが表示されており、[マネージド KB を作成] ボタンも確認できます 新しいナレッジベースを作成する際には、ドロップダウンで直接、サポートされているコネクタのリストから選択することで、エンタープライズデータソースに直接接続できます。 AWS Identity and Access Management (IAM) ロールが自動的に作成され、必要に応じてこれらの許可を編集することを選択できます: 図 2 – [ナレッジベースを作成] ページ。データソースのドロップダウンリストが展開されており、Amazon S3、Confluence、カスタム、Google Drive、OneDrive、SharePoint、Web Crawler といったサポートされているすべてのコネクタが表示されています 最適化されたデフォルト設定セットが表示されるため、わずか数回のクリックでナレッジベースを作成できます。データが同期されたら、ナレッジベースをエージェントと統合したり、基盤モデルのツールとして指定してクエリを開始したりできます。 正確なデータインジェストのための Smart Parsing ナレッジベースの構築における主要な課題の 1 つは、多様なデータタイプを正確に検索できるように準備することです。マネージドナレッジベースをデータソースにポイントすると、Smart Parsing が各データタイプとコネクタに最適なパーシング戦略を自動的に決定します。追加の設定は不要です。 Smart Parsing は、次の複数の手法を組み合わせています: コネクタ固有のデータモデル – 各データソースのために最適化された処理。例えば、Web Crawler コネクタは、埋め込み画像やテーブルを含む HTML 構造を保持し、取り込み中にリッチコンテンツが失われないようにします。SharePoint コネクタは、ドキュメントの階層とファイル間の関係を維持します。 マルチモーダル処理 – ドキュメント内のさまざまなコンテンツタイプの自動検出と処理。システムはドキュメント内のバウンディングボックスを識別し、データ抽出、キャプション生成、動画ファイルのシーン記述のために基盤モデルに送信します。 最適化されたチャンキング – Smart Parsing は、基盤モデルを活用してドキュメント構造を理解し、意味のあるコンテンツを抽出します。これにより、複数のフォーマットが混在する複雑なドキュメントも適切にインデックス化されます。インテリジェントなデフォルト設定はドキュメントのタイプとコンテンツ構造に基づいて検索の精度とパフォーマンスのバランスを取り、上級ユーザーは必要に応じてチャンキング戦略をカスタマイズできます。 この自動化されたアプローチにより、通常、本番レベルの質の検索精度を実現するために必要となる数週間に及ぶ実験が不要になり、必要に応じてカスタマイズできる柔軟性も維持されます。 複雑なクエリでの Agentic Retriever の使用 データの取り込みが完了したら、ナレッジベースへのクエリを開始できます。生成 AI アプリケーションは、推論、再帰的な複数ステップの検索、および結果の中間評価を必要とする複雑なユーザークエリの処理に苦慮することがよくあります。ユーザーが「ML プラットフォームチームのクラウドインフラストラクチャ予算はどうなっていますか?」と「当社の経費ポリシーでは、年間契約の事前払いは認められていますか?」という 2 つの関連する質問をする場合を考えてみましょう。 単一の検索ステップでは、ML プラットフォームチームに関するドキュメントは見つかるかもしれませんが、質問に完全に答えるために必要な予算に関する情報と経費ポリシーを結びつけることができない場合があります。 図 3 – Agentic Retriever は、複雑なユーザークエリをステップバイステップのプランに分解し、複数のナレッジベースでマルチホップ検索を実行して結果を組み合わせ、根拠がある正確な応答を提供します Agentic Retriever は、ステップバイステップのクエリプランを作成することでこれを解決します: 1.どのチームが ML プラットフォームを所有しているか? また、そのチームのクラウドインフラストラクチャの予算はどうなっているか? 2.年間契約の事前払いに関する経費ポリシーはどうなっているか? 3.ML プラットフォームチームがこの予算から事前払いすることはポリシーで認められているか? システムは各ステップでマルチホップ検索と推論を実行し、十分な関連パッセージが収集されたら検索プロセスを停止して、上位の結果を返します。このアプローチは、個別のマルチホップ推論パイプラインを構築する複雑さを抽象化することで、複雑なクエリの精度を劇的に高めつつ、デベロッパーがオーケストレーションロジックではなく、エージェンティック検索アプリケーションに注力できるようにします。 Amazon Bedrock AgentCore コンソールのナレッジベースのテストパネルから、Agentic Retriever を直接お試しいただけます。ナレッジベース全体にわたる複数ステップのクエリをシステムが自動的に計画および実行できるようにするには、検索タイプとして [エージェンティック検索のみ] を選択します: 図 4 – [ナレッジベースをテスト] パネル。検索タイプとして [エージェンティック検索 (回答生成あり)] が選択されており、モデルの選択、および最大エージェンティックイテレーションオプションが表示されています Bedrock AgentCore で MCP を有効にする Amazon Bedrock マネージドナレッジベースは、ネイティブターゲットタイプとして AgentCore Gateway とシームレスに統合します。この統合により、手動での統合が不要になり、組み込みのオブザーバビリティ、ポリシーの強制適用、および自動許可管理が提供されます。 Amazon Bedrock AgentCore コンソールまたは SDK に移動して、AgentCore Gateway を作成したり、既存のゲートウェイを選択したりできます。ゲートウェイにターゲットを追加する際、MCP サーバー、Lambda ARN、REST API、および他の統合オプションとともに、新しい事前構築済みターゲットタイプとして [ナレッジベース] が表示されます。ゲートウェイを通じて公開するために必要なのは、ナレッジベース ID を選択することだけです: 図 5 – AgentCore Gateway の [ターゲットを追加] ページ。ナレッジベース ID セレクタとランタイム検索モードオプションを備えた、新しい事前構築済みターゲットタイプとしてナレッジベースが表示されています AgentCore Gateway の [ターゲットを追加] ページ。ナレッジベース ID セレクタとランタイム検索モードオプションを備えた、新しい事前構築済みターゲットタイプとしてナレッジベースが表示されています ゲートウェイは標準のモデルコンテキストプロトコル (MCP) を公開するため、ナレッジベースツールは、 Strands Agents 、 LangChain 、 CrewAI 、 LlamaIndex 、 LangGraph など、MCP 互換フレームワークのクライアントによって自動的に検出されます。カスタム統合コードは不要です。 モデルの選択と柔軟性 Amazon Bedrock マネージドナレッジベースは、デベロッパーが Amazon Bedrock に期待する柔軟性を維持します。Bedrock で使用可能なすべての基盤モデルは生成ステップで使用でき、デベロッパーはさまざまな埋め込みモデルと再ランキングモデルから選択して、特定のユースケースに合わせて検索を最適化できます。これにより、チームはインフラストラクチャを変更することなく、精度とコストパフォーマンスをファインチューニングできます。 特定のモデルプロバイダーにロックインされるマネージドソリューションとは異なり、Amazon Bedrock マネージドナレッジベースは、インフラストラクチャ管理 (コネクタ、解析、ストレージ、検索オーケストレーション) とモデル選択を分離します。これは、次が可能であることを意味します: 最新モデルを活用する – 最新の埋め込みモデル、再ランキングモデル、基盤モデルが利用可能になり次第、それらを採用することで、RAG パイプラインを再構築することなく、アプリケーションの精度、レイテンシー、コストを改善できます。 料金パフォーマンスを最適化する – 同じナレッジベースインフラストラクチャを使用して、シンプルなクエリにはより小型で高速なモデルを、複雑な推論タスクにはより高性能なモデルを選択できます。 Bedrock 埋め込みモデルを使用する – Smart Parsing は最適化されたデフォルト設定を提供しますが、ドメインで特殊な意味論的理解が必要な場合は、Bedrock 埋め込みモデルを設定できます。 既存アプリケーションとの一貫性を維持する – Bedrock ナレッジベース API ( Retrieve 、 StartIngest 、 StopIngest 、 IngestKnowledgeBaseDocuments ) を既に使用している場合、マネージドナレッジベースは同じ API を使用するため、移行にはコードの変更は不要で、新しいナレッジベース ID をポイントするだけで済みます。 このアプローチにより、進化する要件や新しいモデル機能に基づいてモデルを変更する能力を失うことなく、生成 AI アプリケーションに時間を割けます。 今すぐ始めましょう Amazon Bedrock マネージドナレッジベースは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー、東京)、欧州 (ダブリン、フランクフルト、ロンドン)、および AWS GovCloud (米国西部) リージョンで現在利用可能です。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 Bedrock マネージドナレッジベースでは前払いの義務はなく、お支払いいただくのは使用した分の料金のみです。料金は、保存されるインデックス付きデータのサイズと、実行される検索回数 (オンデマンド) の 2 つの要素に基づきます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。また、Bedrock は AWS 無料利用枠 の一部でもあり、AWS の新規のお客様は無料で利用を開始し、主要な AWS サービスを試すことができます。 これらの機能は、CreWAI、LangGraph、LlamaIndex、Strands Agents などのあらゆるオープンソースフレームワークと、あらゆる基盤モデルで動作します。Bedrock サービスは一緒に使用することも、単独で使用することもできます。 AgentCore オープンソース MCP サーバー を使用して、お気に入りの AI 支援開発環境の使用を開始できます。 詳細を確認し、すぐに使用を開始するには、「 Bedrock ナレッジベースデベロッパーガイド 」にアクセスしてください。 Daniel Abib 原文は こちら です。

2026 年 6 月 17 日、 Amazon Bedrock AgentCore での Web Search の一般提供の開始を発表しました。これは、エージェントがお客様の保護された AWS 環境からデータを一切外部に持ち出すことなく、出典が明示された最新のウェブ知識に基づいて応答を生成できるようにするフルマネージドツールです。 Web Search は、モデルコンテキストプロトコル (MCP) を使用する Bedrock AgentCore Gateway で組み込みコネクタターゲットを使用します。エージェントが自然言語クエリを送信すると、Web Search は最も関連性の高いスニペット、ソース URL、タイトル、公開日を返します。モデルはこれらの情報に基づいて推論し、根拠に基づいた応答を生成します。 これは、Amazon の検索インフラストラクチャを基盤として構築されており、 Alexa+ 、 Amazon Quick 、 Kiro において長年にわたってエージェンティック検索エクスペリエンスを支えてきた経験に基づいています。Amazon のウェブインデックスと構造化されたナレッジグラフデータを組み合わせたマルチソースグラウンディングアプローチを採用しています。これは、標準的なウェブ検索の結果に加えて、検証済みの事実を含む Amazon Knowledge Graph へのアクセスをエージェントに提供するため、従来のウェブ検索のみの場合よりも、より関連性が高く正確な応答を取得するのに役立ちます。 今回のリリースにより、Bedrock AgentCore 上のエージェントにウェブ検索を手動で追加したり、そのインフラストラクチャを管理したりするのではなく、エージェントの構築に注力できます。AI エージェントはユーザーの質問を分析し、最新の事実を取得した後、モデルのトレーニングデータだけでなく、最新の動向に基づいて必要なアクションを実行します。また、AWS 以外の外部検索 API プロバイダーにユーザープロンプトや検索クエリを送信することなく、エンタープライズガバナンスポリシーを満たすことができます。 Bedrock AgentCore での Web Search が実際に機能している様子 開始するには、 Bedrock AgentCore コンソール で Web Search ツールターゲットを含む Bedrock AgentCore Gateway を作成します。ゲートウェイ URL が作成されると、API コール、コマンドラインインターフェイス (CLI)、または MCP Inspector を使用して操作できます。 ゲートウェイの作成時に Web Search ツールターゲットを追加するには、ターゲットプロトコルとして [MCP ターゲット] 、ターゲットタイプとして [コネクタ] を選択します。リンク、スニペット、メタデータなど、最も関連性の高いウェブ検索の結果を取得するには、 Web Search ツール を事前設定済みターゲットとして選択できます。 ゲートウェイを作成すると、ゲートウェイの詳細ページで Web Search ツールターゲットを確認できます。既存のゲートウェイに新しい Web Search ツールターゲットを追加することもできます。 Web Search ツールを操作するには、 [呼び出しコードを表示] セクションにあるサンプル呼び出しコードを使用します。API リクエスト、MCP Python SDK、Strands MCP Client、および MCP Inspector で、Python コードを通じてコードスニペットを使用できます。 例えば、MCP サーバーのテストとデバッグのためのインタラクティブなデベロッパーツールである MCP Inspector を操作できます。  ゲートウェイリソース URL を通じて MCP サーバーに接続すると、ゲートウェイ上の各コネクタターゲットに対応する Web Search ツールが表示されます。ウェブ検索クエリを入力し、 [ツールを実行] を選択すると、結果が表示されます。 Bedrock AgentCore での Web Search の使用方法の詳細については、 Bedrock AgentCore Gateway のドキュメント にアクセスしてください。 お客様の声 一部のお客様には、この新機能への早期アクセスが付与されていました。これらのお客様から寄せられたご意見を次にご紹介します: Benchling は、科学者が R&D を加速するのをサポートし、科学データの一元化、チーム間のコラボレーション、インサイトへのアクセスを容易にしています。Benchling の Head of AI Agents である Nicholas Larus-Stone 氏は次のように述べています。「Benchling AI を利用する科学者は、現在取り組んでいる研究対象について質問することで、Benchling に存在する自らの組織内データと公開文献の両方に基づいた回答を得ることができます。その結果、より包括的な科学的知見が得られ、仮説生成も適切に行われます。当社は Amazon Bedrock AgentCore の Web Search ツールを使用しているため、お客様はセキュアで統制された環境を使用して、データ管理方法に妥協することなく、質の高い公開データをワークフローで利用できます」。 Gen Digital は、消費者および小規模企業向けのサイバーセキュリティをリードしており、ウイルス対策、マルウェア対策、ID およびプライバシー保護、仮想プライベートネットワーク (VPN)、クラウドバックアップを提供しています。Gen Digital の Senior Director of AI & Innovation である Iskander Sanchez-Rola 氏は次のように述べています。「Amazon Bedrock AgentCore の Web Search ツールを活用することで、Norton Revamp は、現在の世の中の動きに基づく最新かつ的確なコンテンツアイデアにより、プロフェッショナルがオンラインでの評判を築くのを支援します。当社が最も高く評価しているのは、AWS が独自の検索インデックスを使用し、信頼できる AWS 環境内にクエリを保持する点です」。 その他のお客様事例については、「 Amazon Bedrock Customers 」にアクセスしてください。 今すぐご利用いただけます Amazon Bedrock AgentCore での Web Search は、米国東部 (バージニア北部) リージョンで本日より一般提供が開始されます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 Bedrock AgentCore の Web 検索は、初期費用なしですぐに使い始めることができます。料金体系はシンプルで、使用量に基づいています。エージェントが Web 検索に送信する検索クエリの数に応じて料金が発生します。Web 検索の料金は、1,000 クエリあたり 7 ドルです。AWS の新規のお客様は、最大 200 ドルの無料利用枠クレジットもご利用いただけます。詳細については、 Amazon Bedrock AgentCore の料金 ページをご覧ください。 Amazon Bedrock AgentCore コンソール でお試しいただき、 AWS re:Post for Amazon Bedrock AgentCore 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本記事は 2026 年 6 月 18 日に公開された Kyle Seaman、Alex Jia による “ Introducing automations in Kiro Web ” を翻訳したものです。 仕事の中には、決まった間隔で繰り返しやってくるものがあります。依存関係は週を追うごとに最新の状態から取り残されていき、ドキュメントはマージのたびに少しずつ遅れをとり、サービス間の API コントラクトは静かに食い違いを広げ、やがてステージングで何かが壊れます。同じことが巡ってくるたびに、同じファイルを開き、同じ diff を読み、同じような修正を書くことになります。 本日（2026 年 6 月 18 日）、Kiro Web にクラウドで動作する Automations 機能を追加しました。これにより、こうした繰り返しタスクの自動化を Kiro に任せられるようになります。Automations は自律型エージェントによって管理されます。Kiro は実行ごとにサンドボックス内で autonomous セッションを作成し、完了すると自動的にプルリクエストをオープンします。 仕組み Kiro Web の Automations に移動し、繰り返しタスクに名前を付けて、対象のリポジトリを GitHub または GitLab（あるいはその両方）から選びます。あとは実行したい内容を記述し、スケジュールを設定するだけです。 1 つの automation につき最大 5 つのスケジュールを追加できます。Daily や Weekly のような組み込みオプションから選ぶか、より細かい指定をしたい場合は cron 式を記述します。スケジュールの実行時刻になると、Kiro はクラウドサンドボックスを立ち上げ、リポジトリをクローンし、作業を実行して、変更内容を含むプルリクエストをオープンします。各実行は独立したサンドボックスを持つセッションであり、他のセッションやローカル環境から隔離されています。 Automations がプルリクエストをオープンするので、作業が完了したらレビューするだけです。 作成した automation はいつでも編集できます。スケジュールを変更したり、リポジトリを更新したり、実行内容を書き直したりできます。変更は次回のスケジュール実行に適用されます。automation を削除せずに無効化することもでき、準備ができたら再度有効化できます。 自動化できること main ブランチで変更されたコードと既存のドキュメントの間にあるギャップを見つけます。Kiro は毎朝、古くなった部分をチェックし、更新が必要なものがあれば PR をオープンします。 今週変更されたファイルのうち、対応するテストカバレッジがないものを確認します。Kiro は毎日、テストでカバーされていないパスを探し、見つかった場合は自動生成したテストを含む PR をオープンします。 コードベースに長く居座っている古い TODO や FIXME をスキャンします。毎週月曜日、Kiro が対応できるものを片付け、レビュー用に PR をオープンします。 今すぐ始めましょう すでに繰り返し発生している作業があれば今すぐ試してみてください。毎週月曜日に実行しているチェック、数日おきに見つけている食い違い、後回しにし続けている依存関係の整理などです。Kiro Web の Automations に移動して 1 つ設定し、走らせてみましょう。最初の実行は、次回のスケジュール時刻に開始されます。使い心地は、アプリ内の Feedback アイコンまたは GitHub からお知らせください。 Automations は現在、Pro、Pro+、Pro Max、Power プランのサブスクライバー向けに、Kiro Web で利用可能です。組織で AWS IAM Identity Center を使用している場合、automation を作成する前に管理者が Kiro Web へのアクセスを有効化する必要があります。 翻訳は Solutions Architect の吉村が担当いたしました。

2026 年 6 月 17 日、 AWS Transform の新機能である AWS Transform – 継続的モダナイズ (プレビュー) を発表しました。これは、技術的負債の継続的かつ自律的な分析と是正を大規模に可能にする機能です。AWS Transform は既に、企業がデータセンターからの移行、メインフレームおよび Windows アプリケーションのモダナイズ、および Java バージョンのアップグレード、非推奨フレームワークの置き換え、サポート終了前の AWS Lambda ランタイムの更新といった、差別化につながらないソフトウェアメンテナンス作業の処理をサポートしています。この新しいエクスペリエンスは、これらの機能をさらに強化するものです。お客様は、数千のリポジトリにわたるコードベースの状態、優先順位付けされた検出結果、および修正を行うプルリクエストを完全に可視化できます。 エンジニアリング組織は通常、IT 予算の最大 30% を消費します。お客様は、依存関係の問題を検出するツール、脆弱性を検出するツール、コード品質を管理するツールといった個別のツールを組み合わせて使用しています。しかし、既存のツールでは、技術的負債を継続的かつ大規模に検出、優先順位付け、および是正することはできません。その結果、アプリケーションごとの手動サイクルが発生し、エンジニアリングのキャパシティが消耗します。リーダーは、現実と乖離しており、リグレッションを隠蔽する、チームが自己申告する状況に頼らざるを得ません。AI 支援開発はこれをさらに悪化させます。すなわち、コーディングエージェントが変更のペースを加速させるにつれて、技術的負債はデベロッパーが追いつけないほどの速さで蓄積されます。お客様は、継続的、自律的、大規模に技術的負債を検出し、優先順位付けして、是正する機能を必要としています。 継続的分析 可視性の課題に対処するため、AWS Transform のこの新機能は、設定可能なベースラインに照らしてコードリポジトリを自動的にスキャンし、数週間ではなく数時間で検出結果を生成します。AWS Transform – 継続的モダナイズには、サポート終了の依存関係、非推奨となったフレームワーク、および他の一般的な技術的負債の原因を検出するための、すぐに使用できるポリシーが含まれています。また、組織に固有の独自の是正パターン (承認済みライブラリ、社内コーディング標準、プラットフォームチームが既に強制適用している技術的負債に関するポリシーなど) でこれらを拡張することもできます。例えば、チームが社内ライブラリを非推奨にした場合や、特定のログ記録パターンを推奨している場合は、それをポリシーとしてコード化し、すべてのリポジトリで継続的に実行できます。 定期的な手動作業とは異なり、継続的な分析はコードから直接、グラウンドトゥルースを提供します。リポジトリがベースラインから遅れた場合、チームがどのように対処することを選択するかにかかわらず、どのコンポーネントがどの程度遅れているのかを即座に把握できます。これにより、状況確認や手動でのコンプライアンス追跡が不要になり、プラットフォームチームは常に、最新の技術的負債の状況を把握できます。 大規模な自律的是正 検出結果を特定して優先順位を付けたら、影響を受けるリポジトリについてプルリクエストを自動的に生成する自律的な是正を設定できます。この新しい AWS Transform 機能は、Java バージョンのアップグレード、SDK の移行、ライブラリの更新などの一般的なシナリオに対応する、すぐに使用できる是正変換を提供します。また、組織固有のパターンに合わせてカスタム変換を作成することもできます。 是正を実行すると、継続的モダナイズ機能によって影響を受ける各リポジトリについてプルリクエストが作成され、次のようなメッセージで担当チームに通知が届きます:「このリポジトリは、この依存関係に関する組織のベースラインに遅れています。この問題を解決する PR はこちらです」。 チームは PR を確認してマージするか、または独自のアプローチを使用して是正することを選択できます。いずれの場合も、継続的分析によって修正が適用されたタイミングが検出され、手動での確認を必要とすることなく、グラウンドトゥルースが得られます。 AWS Transform – 継続的モダナイズは、 AWS セキュリティエージェント と統合し、ソースコードレベルでセキュリティの脆弱性を検出および是正します。そのため、セキュリティに関する検出結果は、他の技術的負債と同じ優先順位付けされたリストとプルリクエストのワークフローに反映されます。 試してみましょう 私はまず、AWS Transform のウェブアプリケーションにアクセスしました。ダッシュボードでは、組織のリポジトリの概要と、設定したベースラインに対する現在のステータスを確認できます。 最初に、ソース管理システムを接続し、指定したポリシーに基づく分析を開始しました。数時間以内に、リポジトリ全体に対する分析の検出結果が返され、どのリポジトリがベースラインからどの程度遅れているのかが示されました。重大度、影響を受けるファイルの数、検出された特定の技術的負債のパターンを確認できました。 ここから、優先度の高い検出結果のグループを選択し、是正キャンペーンを開始しました。AWS Transform – 継続的モダナイズは、影響を受ける各リポジトリについてプルリクエストを生成しました。キャンペーンの進捗状況をリアルタイムでモニタリングし、作成された PR、マージされた PR、コンプライアンス準拠状態に戻ったリポジトリを確認できました。 画像 1: AWS Transform – 継続的モダナイズのダッシュボード。接続されているすべてのリポジトリにおける技術的負債に関する検出結果のポートフォリオの概要が表示されています。 画像 2: 詳細な検出結果ビュー。個々の技術的負債の項目が、重大度、カテゴリ、リポジトリごとに一覧表示されており、利用可能な是正オプションも表示されています。 画像 3: ソースビュー。継続的モダナイズが分析のために追跡している、GitHub およびローカル環境の接続済みリポジトリが表示されています。 より迅速にモダナイズする方法 これらの機能は、コードモダナイズに対する 2 つの異なるアプローチをサポートします。継続モードでは、ベースラインの進化に合わせてコードベースを最新の状態に保つために、継続的モダナイズを使用できます。これは、ライブラリのアップグレード、セキュリティパッチの適用、組織全体でのコーディング標準の強制適用といった日常業務であるとお考えください。 あるフレームワークから別のフレームワークへの移行や、数百のアプリケーションにわたる主要なランタイムバージョンのアップグレードなど、大規模なモダナイズプロジェクトには、キャンペーンモードを使用して、ターゲットを絞ったプロジェクトベースのモダナイズを実施できます。AWS Transform カスタムは、これらの大規模な取り組みのための柔軟な基本機能を提供し続けます。AWS Transform – 継続的モダナイズは、プラットフォームチームが日々管理する、繰り返し発生する大量の作業のために特別に設計されています。 今すぐご利用いただけます AWS Transform – 継続的モダナイズ (プレビュー) は本日よりご利用いただけます。AWS Transform ウェブアプリケーション、AWS Transform Kiro パワー、または既存のコーディングエージェントと統合するための MCP とスキルを通じて、利用を開始できます。詳細については、 AWS Transform のドキュメント にアクセスしてください。 原文は こちら です。

2026 年 6 月 17 日、プレビューで提供が開始となった AWS DevOps エージェント に新しいリリース管理機能が追加されました。AWS DevOps エージェントは、AWS、マルチクラウド、オンプレミス環境にわたってソフトウェアの変更と運用をカバーする、いつでも利用可能なチームメンバーです。DevOps の慣行は、ソフトウェアの変更と運用を円滑でますます自律的にすることを目的としています。AWS DevOps エージェントは、お客様の環境、サービス、それらの依存関係、本番での動作の深い理解を活用することで、変更と運用の両方においてこの目的を実現します。デプロイ後の運用については既に一般提供されており、インシデントを自律的に調査し、根本原因分析と緩和ステップを提供して、問題の再発を防止するための的確なレコメンデーションを提示します。今回のプレビューでは、AWS DevOps エージェントに、コード変更のリリース準備状況レビューと自律リリーステストが追加されました。これらの新機能は、DevOps エージェントに対して指定する自然言語標準に照らしてあらゆる変更を検証し、本番のような環境で変更に固有のテストを実行します。AWS DevOps エージェントは、コードの作成から本番への移行まで、チームをサポートし、レビュー担当者とテスターが AI 生成コードの量に対応するのをサポートするようになりました。 開発チームが AI コーディングツールを採用するようになる中で、デリバリーパイプラインを通過するプルリクエストの量は、レビューおよびテストプロセスが処理できる速度を上回って増加しています。チームが対応に追われる状況では、徹底した検証なしでレビューが承認され、テスト環境が本番からドリフトしてしまいます。コーディングエージェントが生み出す価値は、エンドユーザーに届くことなく、レビューキューで待機状態のままになります。同時に、AI モデルは、人間のレビュー担当者が時間的プレッシャーの中で見落とす可能性のある、機能面やセキュリティ面の問題を検出する能力をますます強化しており、迅速かつ安全なデリバリーは、トレードオフではなく要件となっています。 リリース準備状況レビュー機能は、あらゆるコード変更を、本番の要件、依存関係の安全性、および DevOps エージェントに提供する標準とベストプラクティスに照らして評価します。エージェントは、他のサービスに影響を及ぼす可能性のあるリポジトリ間の依存関係リスクの確認、AWS Well-Architected フレームワークのベストプラクティスに照らしたアクセスコントロールの変更の確認、およびお客様が定義した標準への準拠の確認を行います。標準が指定されていない場合は、エージェントは一般的なベストプラクティスを適用します。また、レビューの一環として、エージェントは、AWS マネージドの隔離された環境でソフトウェアを実行して、軽量なユーザージャーニーテストを実行し、変更がパイプラインに入る前に、ソフトウェアがビルドされ、実行でき、基本的な機能チェックに合格することを検証します。検出結果は AWS DevOps エージェントコンソールと、GitHub または GitLab のプルリクエストに対するコメントとして表示されます。さらに、Kiro パワーまたは Claude Code プラグインを通じて IDE から直接レビューを呼び出すこともできるため、デベロッパーは、変更がバージョンコントロールにコミットされる前に、依存関係のリスク、標準に対する違反、アクセスコントロールの問題を特定して修正できます。 自律リリーステスト機能はさらに一歩進んで、変更がマージされる前に、お客様がプロビジョニングした本番のような環境において、ウェブアプリケーションおよび API ベースのアプリケーション向けに、変更固有のテストプランを生成して実行します。エージェントは、静的なテストスイートを実行するのではなく、変更内容を推論し、それに合わせたテストを構築します。これにより、手動で管理するテストプランでは想定できない可能性のある機能の正しさ、動作のリグレッション、統合シナリオをカバーします。テスト実行ごとに、メトリクス、ログ、トレース、実行の概要などの構造化されたアーティファクトが生成され、レビュー担当者は、テスト内容と結果の一貫した記録を得ることができます。 AWS DevOps エージェントのリリース管理の開始方法 このチュートリアルでは、AWS DevOps エージェントウェブアプリケーションを使用してオンデマンドのリリース準備状況レビューを実行する方法を説明します。開始する前に、少なくとも 1 つの GitHub または GitLab リポジトリがエージェントスペースに接続されていることを確認してください。リポジトリが接続されると、AWS DevOps エージェントはコードをインデックス化し、リポジトリ間およびクラウドの依存関係のナレッジグラフを構築します。 ウェブアプリケーションを開くには、 AWS DevOps エージェントコンソール に移動し、 [エージェントスペース] を選択して、 [ウェブアプリケーション] タブを選択します。ウェブアプリケーションを開くには、 [オペレーターアクセス] を選択します。 標準が設定されていない場合、エージェントは一般的なベストプラクティスを適用します。レビューを社内基準に合わせてカスタマイズするには、 [ナレッジ] に移動し、 [手順] タブを選択します。指示セットの一覧が表示されます。各指示セットは、特定のエージェントまたはタスクにスコープが設定されています。本番に向けた準備状況を確認するための変更レビューに関する指示を編集するには、 [リリース準備状況レビュー] の横にある [表示] を選択します。社内標準は平易な言葉で記述してください。例えば、暗号化やネットワークアクセスルールに関するインフラストラクチャおよびデータ標準、ログ記録やオブザーバビリティの要件など、ブロックせずに警告を発するベストプラクティス、より高度なセキュリティ対策が必要なアプリケーションやリソースを識別する機密データ分類に関するベストプラクティスを定義できます。スペース内のすべてのエージェントに指示を適用するには、 [すべてのエージェント] の横にある [表示] を選択します。 リリース準備状況レビューは、接続されているリポジトリにプルリクエストを送信する、またはチャットインターフェイスでオンデマンドクエリを入力する、という 2 つの方法でトリガーできます。チャットからオンデマンドレビューを実行するには、 [新しいチャット] を選択し、次のようなリクエストを入力します: Perform a production risk analysis on my repository branch エージェントは、分析対象のリポジトリとブランチをたずねます。ブランチ名、プルリクエスト番号、またはコミット SHA を提供できます。選択を確認すると、エージェントはレビューをキューに入れ、インフラストラクチャへの影響、設定の変更、潜在的な問題など、変更を分析して、本番のリスクがないかを確認します。 レビューが完了したら、チャットで直接フォローアップの質問をして、検出結果をより詳細に確認できます。例えば、どの下流のコンシューマーが変更の影響を受けるのかについて質問すると、エージェントは、リポジトリ内およびリポジトリ間の、動作しなくなるコンシューマーの構造化された内訳、影響を受ける特定のファイルと行番号、デプロイ前に問題を解決するための推奨ステップを返します。 レビューリクエストを送信したら、左側のナビゲーションペインの [変更] に移動します。 [提案された変更] テーブルには、実行された各レビューが表示されます。これには、提案された変更の説明、ソース、カテゴリ、ステータス、作成日時が含まれます。カテゴリまたはステータスでフィルタリングして特定のレビューを検索したり、検索バーを使用して名前で検索したりできます。いずれかのエントリを選択すると、完全な実行の詳細が開きます。 [タイムライン] タブには、エージェントのステップバイステップの推論プロセスが表示されます。これには、呼び出したツール、参照した依存関係、各ステップで行った観察が含まれます。各エントリにはタイムスタンプが付与されているため、エージェントが変更をどのように理解し、結論に至ったのかについての完全な記録が得られます。 [レポート] タブを選択すると、最終的なレコメンデーションが表示されます。レポートが開くと、推奨されるアクション、検出された重大な問題の数、コミットのリビジョン、変更されたファイルの数を示す概要ヘッダーが表示されます。推奨されるアクションは、 [ブロック] 、 [注意して続行] 、または [安全にリリース可能] のいずれかです。 概要ヘッダーの下にある [分析] セクションでは、レコメンデーションが作成された理由が説明されており、具体的なリスクと、エージェントが結論を裏付けるために見つけた証拠が示されます。 [問題] セクションでは、各検出結果が重要度別に一覧表示され、変更を進める前に対処する必要のある事項が優先順位付けされた形で確認できます。 [レコメンデーション] セクションでは、デベロッパーが各問題を解決するために実行できる具体的かつ実用的なステップが示されます。最後に、 [変更] セクションでは、変更された各ファイルが、変更のタイプ、該当するカテゴリ、および変更内容の説明とともに一覧表示されるため、レビュー担当者は、マージ前に変更内容を完全に把握できます。 また、チャットインターフェイスから直接、自律リリーステスト機能を呼び出すこともできます。ウェブアプリケーションまたは API ベースのアプリケーションで自律リリーステストを実行するには、 [新規チャット] を選択し、次のようなクエリを入力します: Run a release test on my application deployed at [application URL] エージェントは変更固有のテストプランを生成し、プロビジョニングされた環境で実行します。結果は [変更] に表示され、実行ステップとテスト内容の構造化された概要を確認できます。 今すぐ始めましょう AWS DevOps エージェントのリリース準備状況レビュー機能と自律リリーステスト機能はプレビューで提供されています。米国東部 (バージニア北部) リージョンでは、これらの機能はプレビュー期間中、追加料金なしでご利用いただけます。AWS DevOps エージェントの他の機能の料金に関する情報については、 AWS DevOps エージェントの料金 ページにアクセスしてください。 設定の詳細については、「 AWS DevOps エージェントユーザーガイド 」にアクセスしてください。 – Esra 原文は こちら です。

Amazon Elastic Container Service (Amazon ECS) サービス自動スケーリング は、包括的なスケーリングポリシーを使用して、ワークロードの需要に合わせてタスク数を自動的に調整します。これには、繰り返されるトラフィックパターンのための予測スケーリング、計画されたイベントのためのスケジュールされたスケーリング、およびリアルタイムメトリクスに基づいて動的にスケールするターゲット追跡スケーリングが含まれます。 予測スケーリング (自動) や スケジュールされたスケーリング (お客様が定義) を使用したプロアクティブなスケーリングや、スケールする基準となるターゲットを指定するだけの ターゲット追跡 を使用したリアクティブなスケーリングを選択できます。Amazon ECS サービス自動スケーリングは、 Amazon CloudWatch メトリクス (平均 CPU/メモリ使用率、ターゲットあたりのリクエスト数、キューの深さなどのカスタムメトリクス) や、高度な機械学習 (ML) アルゴリズムを使用した需要急増の予測に基づいて、ECS サービスのタスク数を調整します。 2026 年 6 月 18 日のリリースにより、高解像度 (20 秒間隔) メトリクスとメトリクス発行の最適化がサポートされ、Amazon ECS サービス自動スケーリングは、負荷の変化をより迅速に検出して、これに対応できるようになりました。AWS のベンチマーキングテストでは、スケールアウトがトリガーされるまでの時間が 363 秒から 86 秒に短縮され (76% の高速化、4.2 倍)、新しいタスクのスケールとプロビジョニングにかかる合計時間が 386 秒から 109 秒に短縮されました (72% の高速化、3.5 倍) このリリースは、アプリケーションに 3 つの重要な利点をもたらします: パフォーマンスの改善と信頼性の向上 : スケーリングが高速化することで、アプリケーションは需要の急増により迅速に対応できるようになり、エンドユーザーのために、急増時のレイテンシーや障害を低減します。 妥協のない適切なサイジング : 事前に余分なキャパシティを確保しておかなくても、トラフィックの急増に対処するのに十分高速なスケールアウトが可能になったため、ワークロードによっては、ベースラインのタスク数を削減できます。これにより、アプリケーションのパフォーマンスと可用性を維持しながら、コンピューティングコストを直接削減できます。 よりシンプルなスケーリング設定 : 高解像度メトリクスを使用したターゲット追跡により、以前はカスタムスケーリング設定 (ステップスケーリングポリシーの使用など) を必要としていた、積極的なスケーリング動作が可能になります。設定を 1 つ変更するだけで、カスタムエンジニアリング作業を代替できます。 仕組み ECS の高速化されたサービス自動スケーリングを使用するには、まず ECS サービスのために高解像度メトリクスを有効にし、次に高解像度メトリクスを使用するターゲット追跡スケーリングポリシーを設定します。ECS の高速化されたサービスオートスケーリングは、 AWS Fargate 、 ECS マネージドインスタンス 、 Amazon Elastic Compute Cloud (Amazon EC2) といった ECS におけるすべてのコンピューティングオプションで利用可能です。これらのメトリクスは、 Amazon ECS コンソール で、または AWS SDK およびツール や AWS CloudFormation を使用して ECS サービスを作成または更新する際に有効にすることができます。 コンソールでサービスを作成する際には、 [モニタリング設定] セクションで 20 秒間隔のメトリクスを追加してください。標準の解像度 (60 秒間隔) は無料ですが、これらのメトリクスには CloudWatch の追加料金が発生します。 [サービス自動スケーリング] セクションで [サービス自動スケーリングを使用] にチェックを入れ、スケーリングポリシータイプとして [ターゲット追跡] を選択します。これにより、リアルタイムデータを使用して、サービスが需要に基づいて実行するタスク数をスケールできます。 その後、ターゲット追跡の [スケーリングポリシータイプ] を選択します。新しいメトリクスとして、 ECSServiceAverageCPUUtilizationHighResolution または ECSServiceAverageMemoryUtilizationHighResolution を選択できます。 これで完了です – ECS サービスは、自動スケーリングのために高解像度メトリクスを使用するようになります。 既存の ECS サービスをより高速な自動スケーリングを使用するように更新するには、まず [サービスを更新] を介して高解像度メトリクスを設定する必要があります。デプロイが完了すると、サービスは高解像度メトリクスを生成するようになります。その後、サービスの詳細の [サービスと自動スケーリング] タブに移動し、より高解像度のメトリクスを使用するようにスケーリングポリシーを更新できます。 必要な手順はこれだけです。これで、ECS サービスは 20 秒間隔でスケーリングに関する決定を評価するようになります。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、Application Auto Scaling を通じて ECS サービスで新しいメトリクスを有効にすることもできます。詳細については、 より高速な自動スケーリングに関するドキュメント にアクセスしてください。 今すぐご利用いただけます Amazon ECS 向けの、高解像度メトリクスを使用したより高速なサービス自動スケーリングは、6 月 18 日よりご利用いただけます。機能自体に追加料金はかかりませんが、高解像度 CloudWatch メトリクスについては新しい料金ディメンションが導入されます。詳細については、「 CloudWatch の料金 」ページをご覧ください。 ぜひ今すぐお試しいただき、 AWS re:Post for ECS 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。