こんにちは、ソリューションアーキテクトのシャルノ ミカエルです。 本記事では、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 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。6 月 15 日に Kiro 公式グッズストアが shop.kiro.dev にオープンしたのをご存じでしょうか？ アパレルや小物、アクセサリーの 15 アイテムがそろい、ラバーダックの代わりに Kiro のぬいぐるみでデバッグする、なんて楽しみ方もできそうです。Kiro を「使う」だけでなく「身にまとう」選択肢も生まれた今週も注目のアップデートをまとめています。 そしてAWS Summit Japan の開催（6 月 25 – 26 日）が近づいてまいりました！ 登録がまだの方は こちら から登録しぜひ来場ください！ それでは 6月 1 5日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Kiro Pro Max の紹介 (月額 $100): クレジットは多く、コストの迷いは少なく 」 Kiro に、月額 $100 で月 5,000 クレジットを利用できる新プラン「Kiro Pro Max」が加わりました。月額 $40 の Pro+ と月額 $200 の Power の間を埋めるプランで、Claude Opus 4.8 や Sonnet 4.6、Auto を含むすべてのプレミアムモデル（地域ごとの提供状況に準じます）と、スペック・カスタムサブエージェント・Powers・フック・CLI といった Power と同等の機能セットを利用できます。価値は、料金の予測しやすさにあります。Pro+ のクレジットを常に大きく超過していたり、超過料金が $60〜70 に達していたりする開発者にとって、Pro Max は定額で余裕のある利用を実現します。1 日を通じて複数プロジェクトでコーディングやスペック実行、デバッグを行うような、業務の中核として Kiro を使う開発者に向いた選択肢です。6 月 11 日からアカウント設定画面で切り替えでき、月の途中のアップグレードは差額が日割り計算となります。 ブログ記事「 Kiro Web の新機能: Spec、GitLab、その他のアップデート 」 ブラウザから使える Kiro Web に、開発者から要望の多かった 2 つの機能が加わりました。構造化されたスペックワークフローをブラウザで実行できるようになり、さらに GitHub に加えて GitLab に対応しました。1 つのセッションで GitLab と GitHub のリポジトリを混在させることもできます。スペックは、コードを書く前に「何を作るか」「どう動くべきか」「何を含めないか」を Kiro と定義する進め方です。Kiro が要件・設計・タスクリストのドキュメントを生成し、ブラウザ上でレビューしながら磨き上げ、準備が整ったらサンドボックス内でタスクを実行してプルリクエストを開けます。GitLab はパーソナルアクセストークンで接続でき、Kiro がプロジェクトをクローンして変更を加え、マージリクエストを開きます。共有ライブラリとそれに依存するサービスが別々のプロバイダーにある場合でも、横断的に変更を調整できる点が便利です。Kiro Web は Pro、Pro+、Pro Max、Power の各サブスクライバー向けにプレビュー提供中です。 ブログ記事「 Kiro for iOS のご紹介 」 本格的な開発業務に対応するネイティブ iOS アプリとして Kiro が提供開始されました。スマートフォンから直接、Kiro セッションの起動・監視・軌道修正・対話ができ、ノート PC を開かなくても、差分のレビューや変更の承認といった作業を進められます。chat、spec、autonomous の 3 つのモードを選べます。アプリを開くとクラウドセッションのライブな状態が読み込まれ、エージェントの応答がリアルタイムにストリーミング表示されます。差分はファイルヘッダー付きのネイティブな差分カードとして描画されるため、小さな画面でもコードを読みやすくしています。Kiro Web や CLI、IDE で始めたセッションは、同じ ID・設定・モデルで自動的に同期されるため、接点をまたいでも作業が途切れません。Kiro Pro、Pro+、Pro Max、Power のお客様向けに、早期アクセスのリクエスト順に案内されます。iOS 26 以降が必要です。 ブログ記事「 AWS WAF に AI トラフィック収益化機能が追加され、コンテンツ所有者が AI ボットにコンテンツへのアクセス料金を請求することが可能に 」 AWS WAF の内容ですが運用の観点で有用です。AI ボットやエージェントが保護対象の Web コンテンツへアクセスした際に課金できる「AI トラフィック収益化」機能が追加されました。オリジンインフラの変更やアプリケーションコードの作成なしに、コンテンツパス・ボットカテゴリ・検証階層ごとにリクエスト単位の料金を AWS WAF コンソールから設定できます。背景には、AI ボットが Web トラフィックの 50% 以上を占めるケースがある一方、従来の検索エンジンと違い元サイトへの送客がほとんどないという課題があります。仕組みは AWS WAF Bot Control の新機能として提供され、GptBot や Claude-Web、Perplexity-Bot を含む 650 種類以上の AI ボットを分類し、検証済み・未検証の階層を割り当てます。収益化ルールに一致したリクエストには HTTP 402 応答を返し、機械間決済向けの x402 オープンプロトコルで価格情報を提示します。決済・検証フローは Coinbase の x402 Facilitator が提供し、支払いはステーブルコインで自社管理のウォレットに回収できます。Amazon CloudFront のお客様であれば、標準の AWS WAF 料金を超える追加料金なしで利用できます（収益化アクションは CloudFront に関連付けた Web ACL でのみ対応）。 ブログ記事「 VR × モーションキャプチャ × AI でパデルフォームを可視化する ── AWS Builders’ Fair 展示のご紹介 」 AWS Summit Japan 2026 の AWS Builders’ Fair で展示される、パデルフォーム分析アプリを紹介する記事です。VR ヘッドセット（Meta Quest）、モーションキャプチャ（HaritoraX）、カメラによる骨格推定（MoveNet）を組み合わせ、バーチャル空間でのパデルの動作を計測し、DTW アルゴリズムでトッププレーヤーのフォームと比較して、5 指標のスコアカードと Amazon Bedrock による改善アドバイスを返します。技術的な見どころは、AI 駆動の 3D 開発です。3D 空間のプログラミングは従来、空間座標やベクトル演算など専門性が高い領域でしたが、本プロジェクトでは Godot Engine 上のロジックを Kiro を使った自然言語プログラミングで実装しています。「ボールを放物線で飛ばしてラケットの当たり判定を追加して」といった指示で 3D の挙動を構築でき、3D/VR 開発の経験が浅くても複雑なアプリを素早く試作できることを示しています。クラウド側は Amazon Bedrock や AWS Lambda、Amazon S3、Amazon DynamoDB、AWS IoT Greengrass などで構成され、このコア（モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック）はスポーツ全般やリハビリ、製造業の技能伝承など幅広い分野に応用できると述べられています。 ブログ記事「 AI が Arm SoC 間で組み込みコードベースを移行を支援 」 Arm SoC（System on a Chip）間での組み込みコードベース移行を支援する新しい Kiro Power「Arm SoC Migration Power」が、Arm と AWS の共同開発として紹介されました。Kiro は AWS の AI 搭載 IDE で、Powers は繰り返し発生する課題にドメイン固有のガイダンスを提供する仕組みです。変更を自動化するのではなく、アーキテクチャの違いや制約を明示し、エンジニアの判断を支援します。複数の Arm プラットフォームでコンパイル・実行できるコードでも、CPU マイクロアーキテクチャやメモリ階層、SIMD サポートの違いにより、特に安全性に関わるシステムでは挙動が変わることがあります。この Power は移行を発見・分析・計画・実装・検証のガイド付きワークフローとして構造化し、こうした違いを早い段階で明示します。記事では自動車産業を例に、AWS Graviton 搭載 EC2 での開発から、低コストな Arm ハードウェアでのプロトタイプ、NXP i.MX 8M Plus のような車載 SoC への移行という 3 段階を解説しています。Arm の数百の Learning Paths を参照できる Arm MCP Server の機能も含まれます。  イベント開催レポート 「 日立グループ合同「AI-DLC Unicorn Gym」開催レポート ── 日立 AI駆動開発のキーマンに聞く、グループ展開への道筋 」 2026 年 5 月 18〜20 日に日立のオフィスで開催された「日立グループ合同 AI-DLC Unicorn Gym」の開催レポートと、推進キーマンへのインタビューです。AI-DLC は、AI を要件定義から実装・テストまでの開発ライフサイクル全体に組み込みつつ、人間が主導権を握る（Human-in-the-Loop）開発手法で、3 日間で体験するワークショップが Unicorn Gym です。日立製作所・日立ハイテク・日立産業制御ソリューションズの 3 社・8 チーム・52 名が、実際の業務テーマを持ち寄って参加しました。全体満足度は 5 点満点中 4.67、回答者の 90% が開発工数の「70% 以上の削減」を体感したと報告されています。インタビューでは、「動くものをデプロイするまでの速さ」と「本番リリースまでの工数」は別物であり、日立が積み上げてきた品質保証の工程を AI-DLC の進め方に織り込んだ「日立版 AI-DLC」を作る必要があるという議論が語られています。AWS が GitHub で公開する AI-DLC Workflows をベースに汎用版を整え、各事業部が Fork してカスタマイズする構想や、グループ横断の AI 駆動開発ワーキンググループ立ち上げの方針も紹介されています。 「 【開催報告】通信事業者向けカスタム AI エージェントワークショップ開催しました！ ( 2026 年 4 月 23 日 ) – ネットワーク開発・運用を AI エージェントで変える 」 2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催された、通信事業者向けカスタム AI エージェントワークショップの開催レポートです。NTTドコモ、KDDI、ソフトバンク、楽天モバイルに NTT、ソニーを加えた事業者から 121 名・6 グループが参加し、Autonomous Network 実現に向けた参考アーキテクチャや事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、ユースケース議論が行われました。事例では、NTTドコモが AI エージェントと GitOps を組み合わせ、5G コアネットワークの設計・構築のリードタイムを約 80% 短縮した取り組みや、NTTドコモビジネスがルータ連携 AI エージェントで設定作業の所要日数を 6 日から 1 日に短縮した事例が共有されました。ハンズオンでは、数行で実装できる Strands Agents でエージェントを作り、AgentCore Memory と AgentCore Runtime で永続的なメモリとサーバーレスのスケールを備えた本番対応構成へ発展させる流れを体験。ユースケース議論では、業務領域ごとに専門エージェントを分ける発想、既存社内ツールとの接続、AI に任せきれない判断ポイントの設計が、各社共通の論点として浮かび上がりました。 サービスアップデート Amazon Bedrock Managed Knowledge Base が一般提供開始 フルマネージドの RAG サービス Amazon Bedrock Managed Knowledge Base が一般提供を開始しました。ベクトルデータベースやデータパイプライン、検索インフラを自前で管理せずに、企業データに根ざした本番品質の AI エージェントを構築できます。データの取り込みやストレージの最適化、高度な検索を自動で引き受けてくれるため、プロトタイプから本番へ素早く移行できます。Amazon S3、SharePoint、Confluence、Google Drive、OneDrive、Web Crawler の 6 種のコネクタに対応し、複雑なマルチホップの問い合わせにはクエリプランニング、暫定応答の評価、再ランキングを自動で組み合わせるエージェント型検索も使えます。東京リージョンを含むアジアパシフィック（シドニー、東京）、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（ダブリン、フランクフルト、ロンドン）、AWS GovCloud（米国西部）で利用できます。 Amazon Bedrock Guardrails がエージェント型 AI ワークフロー向けの新しい API を発表 Amazon Bedrock Guardrails が、エージェント型 AI アプリケーション向けの新しい InvokeGuardrailChecks API を発表しました。ガードレールのリソースを作らずに、ワークフローの好きな地点で個別のセーフガードを呼び出せます。エージェント型 AI は計画・ツール呼び出し・出力処理を繰り返し、1 リクエストで数十ステップに及ぶこともあり、各ステップでリスクの種類も変わるため、こうした細かい制御が役立ちます。リクエストごとにどのチェックを走らせるかを細かく選べ、重大度と信頼度のスコアが返るので、ブロック・通過・再試行・記録といったアクションを自前のしきい値で実装できます。コンテンツフィルター、プロンプト攻撃検出（脱獄・プロンプトインジェクション・プロンプト漏洩）、機密情報フィルターに対応し、ガードレール ID やバージョンの管理が不要なのも扱いやすい点です。東京リージョンを含むアジアパシフィック（東京、シドニー）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（ロンドン、ストックホルム）で利用できます。 Amazon Bedrock Guardrails がシドニーで Automated Reasoning checks に対応 Amazon Bedrock Guardrails の Automated Reasoning checks が、新たにアジアパシフィック（シドニー）リージョンで利用できるようになりました。これは形式的検証（数学的な手法）で AI の出力を検証する機能で、大規模言語モデルの正しい応答を最大 99% の精度で見極められるとされています。サンプリングに頼る確率的なテストとは異なり、数学的な裏付けで応答を検証できるため、金融・ヘルスケア・法務といった規制の厳しい領域での要件対応を後押しします。本番デプロイ前の応答チェックやビジネスルール準拠の確認に使え、Amazon Bedrock コンソールまたは SDK から利用できます。既存の提供リージョンである米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（フランクフルト、アイルランド、パリ）に、今回シドニーが加わりました。 AgentCore harness が一般提供開始 Amazon Bedrock AgentCore の managed agent harness が一般提供を開始しました。モデルが「脳」なら、ハーネスは「体」にあたる管理レイヤーで、オーケストレーションループの実行、ツールの実行、コンテキストウィンドウの管理、ターンをまたぐ状態保持、障害復旧、セッション分離を引き受けます。コードを書く代わりに、使うモデル・呼び出すツール・従う指示を設定として宣言すれば、本番品質のエージェントが数分で立ち上がります。モデルとハーネスが分離されているため、セッションの途中でもコンテキストを失わずにモデルを切り替えられ（計画はあるモデル、コード生成は別のモデル、といった使い分けが可能）、独自のオーケストレーションが必要になれば CLI コマンド一つで Strands ベースのコードへエクスポートできます。AgentCore が利用できるすべての AWS 商用リージョンで使えます。 Amazon Bedrock AgentCore が本番環境のエージェントを継続的に改善する最適化機能を追加 Amazon Bedrock AgentCore が、本番環境のトレースをエージェントの継続的な改善につなげる最適化機能を発表しました。エラーを出さずダッシュボード上は正常に見える「サイレントな障害」も対象に、本番データから改善点を見つけられます。繰り返し起きる障害パターン（サイレントな障害を含む）を見つけて根本原因を説明し、影響の大きさで順位づけする「失敗インサイト」、ユーザーの意図でリクエストをまとめる「意図インサイト」、エージェントがタスクをこなす経路をまとめる「トラジェクトリインサイト」で、エージェントの挙動を数分で把握できます。さらに、実際の挙動に基づいてシステムプロンプトやツール記述の改善を根拠つきで提案し、バッチ評価や本番トラフィックを分割した A/B テストで効果を統計的に検証できます。AgentCore ランタイムだけでなく、AWS Lambda、Amazon EKS、AWS 以外の環境でも動作します。失敗・意図・トラジェクトリのインサイトは 13 の AWS リージョンでプレビュー、バッチ評価・レコメンデーション・A/B テストは 14 の AWS リージョンで一般提供されています。 Amazon Bedrock AgentCore がポリシーで Bedrock Guardrails をサポート AI エージェントの実行可能なアクションを制御する認可機能 AgentCore policy が、Bedrock Guardrails をサポートするようになりました。認可済みアクションの出力や、ゲートウェイ先のツール・エージェント・モデルへの入力をリアルタイムで評価します。プロンプトインジェクション攻撃や有害コンテンツ、機密情報の漏洩を、下流システムに到達する前に検出・ブロックでき、評価はエージェントのコードの外、AgentCore ゲートウェイの境界で行われます。既存の AgentCore ゲートウェイ環境でそのまま動き、新たなインフラは不要です。ポリシーは自然言語でも policy-as-code でも記述でき、評価は従量課金制です。東京リージョンを含むアジアパシフィック（東京、シドニー）、米国東部（バージニア北部）、欧州（ロンドン、ストックホルム）で利用できます。 AWS DevOps Agent がリリース管理機能を追加（プレビュー） AWS DevOps Agent が、リリース管理機能をプレビューで追加しました。これにより、このエージェントがデリバリーと運用の両方をまたいで支援するようになります。機能は 2 つです。コード生成時に変更を本番安全性の観点で評価する「リリースレディネスレビュー」は、内部標準からのドリフトや依存関係への影響、アクセス制御を確認し、リポジトリをまたいだ依存関係を地図化してコミット前に破壊的変更を検出します。「リリーステスト」は、Web や API ベースのアプリ向けにテスト計画を生成・実行し、回帰や UX の問題、統合の失敗を見つけます。コードリポジトリとパイプラインを AWS DevOps Agent space に接続すれば始められ、プレビュー期間中は追加費用なしで、米国東部（バージニア北部）リージョンで利用できます。 CLI v3 への早期アクセス Kiro CLI 2.8 で、Kiro V3 の早期アクセスプレビューが導入されました。kiro-cli –v3 でオプトインでき、新しいハーネスを既存の 2.x 環境と並行して試せます。オプトインするまで 2.x の設定はそのままです。V3 は、Kiro の IDE と Web を動かすのと同じ統合エージェントハーネス上に構築されており、ハーネスへの改善がすべての面に同時に届くようになります。ターミナルでのスペック駆動開発、ケイパビリティベースの権限モデル、独立したファイル形式を持つ強化されたフック、タグベースのエージェント設定が新たに加わりました。 Automations の提供開始 Kiro on the web で、繰り返し作業をスケジュール実行できる Automations が使えるようになりました。オートメーションを作り、タスクを記述して GitHub または GitLab のリポジトリを選び、スケジュールを設定すれば、決めた周期で Kiro が自前のサンドボックス内で自律的に実行します。各実行は独立したサンドボックスを立ち上げてリポジトリをクローンし、作業を進めて、完了するとプルリクエストを開きます。1 つのオートメーションにつき最大 5 つのスケジュールを設定でき、毎時・毎日といった組み込みオプションのほか cron 式も使えます。編集・無効化・削除はいつでも可能で、変更は次回の実行から反映されます。 Amazon S3 Vectors が 1 クエリあたり最大 10,000 件の類似検索結果に対応 Amazon S3 Vectors が、1 クエリあたりの類似検索結果（topK 最近傍）を最大 10,000 件まで返せるようになりました。従来の上限から 100 倍の拡大です。これにより、より大きく網羅的な候補セットを一度の検索で取得でき、再ランキングや集約、重複排除を組み込んだ多段階のリトリーバルパイプラインを組みやすくなります。結果は複数ページに分けて返るため、最初のページをすぐ処理しながら後続を取得することもできます。最初の 512KB 分の返却データは無料です。Amazon S3 Vectors が利用できるすべての AWS リージョンで使えます。 Amazon S3 Vectors が大規模ベクトルインデックスのクエリ料金を最大 80% 削減 Amazon S3 Vectors が、1,000 万を超えるベクトルを持つインデックスへのクエリで、データ処理料金を最大 80% 削減しました。新しい料金は自動で適用され、アプリケーション側の変更は必要ありません。大規模な AI、RAG、セマンティック検索のワークロードで類似検索のコストを抑えられるのが利点です。なお、クエリ性能を高めるために、ベクトルを複数のインデックスに分散させることは引き続き推奨されています。この料金は、Amazon S3 Vectors が利用できるすべての AWS リージョンで適用されます。 Amazon Quick が自律エージェント、マルチデータセット分析、刷新されたアクティビティフィードを発表 AI アシスタントの Amazon Quick が、自律エージェント、マルチデータセット分析、刷新されたアクティビティフィードの 3 つを発表しました。自律エージェントは、自然言語でタスクを記述し、ステップごとの承認から目標ベースの幅広い実行まで承認の粒度を選べて、停滞中の取引のフォローアップや発注書の処理などを継続的に自動化します。マルチデータセット分析では、Snowflake やリレーショナルデータベースなど複数のデータソースを、事前のデータ結合なしに自然言語で横断的に問い合わせでき、既存の権限を尊重します。刷新されたアクティビティフィードは会話型のインターフェースで、メールや Slack への返信、リクエストの承認をアプリを切り替えずに行えます。 Amazon Quick が Adobe、Figma、WhatsApp などの新しいコネクタで連携を拡大 Amazon Quick が新たに 16 のツールと連携できるようになり、それらの情報をもとにアプリを切り替えずにアクションを起こせます。追加されたのは Adobe、Figma、WhatsApp、Snowflake、Shopify、Smartsheet、Zapier、Dun & Bradstreet、Moody’s、ZoomInfo など、生産性・デザイン・分析・データ基盤・金融・コマース・コミュニケーションにまたがる各種ツールです。たとえば営業チームなら、Dun & Bradstreet でアカウント情報を補強し、Snowflake のデータと突き合わせ、Smartsheet でアウトリーチのタスクを管理する、という一連の流れを Quick から離れずに進められます。新しいツールは数分でワークスペースに追加でき、すぐ使い始められます。 セマンティック検索・文類似度向けの all-MiniLM-L12-v2 が Amazon SageMaker JumpStart で利用可能に Sentence Transformers の all-MiniLM-L12-v2 モデルが、Amazon SageMaker JumpStart で利用できるようになりました。文章や段落を 384 次元の密ベクトルに変換するモデルで、セマンティック検索、テキストクラスタリング、文類似度に向いています。コンパクトな構造で高速な推論と高い埋め込み品質を両立しており、情報検索やドキュメントクラスタリング、重複検出、言い換え識別といった本番ワークロードに適しています。SageMaker Studio の Models セクション、または SageMaker Python SDK から数クリックでデプロイでき、高品質なセマンティック検索アプリを AWS インフラ上に構築できます。 マルチモーダル推論・エージェント AI 向けの Ministral-3-14B-Instruct が Amazon SageMaker JumpStart で利用可能に Mistral AI の Ministral-3-14B-Instruct-2512 が、Amazon SageMaker JumpStart で利用できるようになりました。14B パラメータのコンパクトな構造で、エッジでのデプロイに最適化されています。テキストに加えて画像を分析して知見を返せるほか、ネイティブの関数呼び出しと JSON 出力によるエージェント機能を備え、日本語を含む数十言語の多言語理解に対応します。SageMaker Studio の Models セクション、または SageMaker Python SDK から数クリックでデプロイでき、高度な AI アシスタントやエージェントシステム、画像対応のアプリケーションを AWS インフラ上で構築できます。 Amazon SageMaker AI が推論エンドポイント向けの新しいオブザーバビリティ機能を発表 Amazon SageMaker AI が、推論エンドポイント向けの新しいオブザーバビリティ機能を発表しました。生成 AI 推論の本番ワークロードを、安心して運用できるよう支援します。Time to First Token、トークン間レイテンシ、キュー深度、秒間トークン数などのパフォーマンス指標をリアルタイムで追跡し、Amazon CloudWatch 内の構築済み「SageMaker AI Insights」ダッシュボードで、トークンレイテンシや GPU 使用率、推論コンポーネントのコピー数、スケーリングイベント、コールドスタートの内訳を一画面で見られます。OpenTelemetry ネイティブのメトリクスが計装なしで自動公開され、問題の特定・解決が数時間ではなく数分で進みます。東京リージョンを含むアジアパシフィック（ムンバイ、シンガポール、シドニー、東京、ソウル、ジャカルタ）、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン、北カリフォルニア）、カナダ（中部）、南米（サンパウロ）、欧州（アイルランド、フランクフルト、ロンドン、ストックホルム、チューリッヒ）で利用できます。 AWS Marketplace が AI 支援による製品リスティングを発表 AWS Marketplace が、Partner Assistant チャット内で使える AI 支援の製品リスティング機能を発表しました。独立系ソフトウェアベンダー（ISV）やコンサルティングパートナーが対象です。Web サイトの URL や PDF、ケーススタディ、製品ドキュメントといった既存の資産から情報を取り込み、必要な製品情報の各項目を自動生成します。AWS Marketplace のサイズ・フォーマット要件に対する検証や検索向けの最適化、項目ごとの推奨も行い、掲載内容の水準を示す品質スコアを提示します。これにより、手作業の入力や要件を満たすための推測の手間を減らせます。AWS Partner Central、AWS Marketplace Management Portal、プログラム連携向けの Partner Agent MCP server から利用でき、AWS GovCloud（米国）と中国リージョンは対象外です。 AWS Partner Central のエージェントが新規パートナーを登録から販売準備完了まで案内 AWS Partner Central agents のオンボーディング機能が一般提供を開始し、新規パートナーを登録から販売準備の完了まで導きます。従来は AWS で販売を始める最短ルートを知るために複数の資料を調べる必要がありましたが、その手間を減らします。企業の Web サイトから情報を取得して対応業界や提供ソリューションを自動入力し、販売準備に必要なことと、その理由を提示します。税務・銀行・コンプライアンスの要件をステップごとに案内し、検証や支払い設定の完了、Marketplace での出品準備までを支援します。常時利用できるアドバイザーとして、オンデマンドでパーソナライズされたロードマップを得られるのが利点です。AWS Partner Central コンソール内、または Model Context Protocol（MCP）経由で利用でき、すべての商用 AWS リージョンで使えます。 Amazon EC2 G7 インスタンスが一般提供開始 Amazon EC2 G7 インスタンスが一般提供を開始しました。NVIDIA RTX PRO 4500 Blackwell Server Edition GPU を最大 8 基（各 32GB メモリ）と、カスタムの Intel Xeon 6 プロセッサ、最大 700 Gbps の Elastic Fabric Adapter（EFA）を備えます。前世代の G6 と比べて AI 推論性能が最大 4.6 倍、グラフィックス性能が最大 2.1 倍とされ、言語翻訳や動画・画像解析、音声認識、レコメンダーシステムといった AI 推論から、リアルタイムの高品質グラフィックスやゲームストリーミング、大規模データ処理まで幅広く使えます。オンデマンド、Savings Plans、スポットの 3 つの購入オプションに対応し、米国東部（オハイオ）、米国西部（オレゴン）の各リージョンで利用できます。 Amazon EC2 P6-B200 インスタンスがアジアパシフィック（ムンバイ）リージョンで利用可能に Amazon EC2 P6-B200 インスタンスが、新たにアジアパシフィック（ムンバイ）リージョンで利用できるようになりました。NVIDIA Blackwell GPU を 8 基、1,440 GB の高帯域幅 GPU メモリを搭載し、第 5 世代 Intel Xeon プロセッサと最大 3.2 Tbps の EFAv4 を備えます。AI のトレーニングと推論で、P5en インスタンスと比べて最大 2 倍の性能が得られ、GPU メモリ帯域幅は 60% 向上しています。Amazon EC2 UltraClusters 内で数万 GPU 規模まで安全かつ確実にスケールでき、これまでの米国西部（オレゴン）、米国東部（バージニア北部、オハイオ）、AWS GovCloud（米国西部、米国東部）に加えて、今回アジアパシフィック（ムンバイ）が加わりました。 最後に「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近作っただし巻き卵焼きを褒められました。

はじめに 建設業界では、設計・施工・維持管理の各フェーズで BIM（Building Information Modeling）の活用が広がっています。一方で、実際は「BIM に必要なデータをどのように定義して、工程間で受け渡していくか」「受発注者で求める情報をどう揃えるか」という、データの要件をめぐる悩みが尽きません。発注者が思い描く BIM の姿と、実際に納品される BIM の中身が噛み合わず手戻りが発生する、というケースもあります。 この課題に対するアプローチの一つが IDS（Information Delivery Specification） です。建設分野のオープンな BIM 標準を策定する、国際的な非営利団体である buildingSMART が策定し、2024 年に v1.0 が承認された IDS は、「BIM に何が含まれているべきか」をコンピュータが解釈可能な形で定義するための仕様です。IDS があれば、納品された IFC ファイルが要件を満たしているかをツールで自動チェックできます。 本ブログでは、自然言語で書かれた BIM の要件定義書から、生成 AI が IDS を自動生成するソリューションを、実装レベルで解説します。核となる工夫は、 Amazon Bedrock AgentCore Runtime と AWS Step Functions を組み合わせ、要件ごとに IDS specification を並列生成するアーキテクチャです。 なお本ブログは、1〜3 章で「なぜこの構成にしたのか」という課題とアプローチの考え方を、4 章で「どう実装したか」という詳細を扱い、5 章で適用上の考慮点に触れる構成になっています。 1. BIM 要件をどう揃えるか BIM が業界に普及するにつれ、「納品された BIM モデルに、本当に必要なデータが入っているか」を確認する作業が、どのプロジェクトでも悩みどころになっています。例えば、以下のような課題が挙げられます。 受発注者間の要件ミスマッチ : 受注者が作る BIM と、発注者が求める要件が噛み合わない。納品段階で欲しい情報が入っていないと手戻りが発生する チェック業務の煩雑さ : 標準ルールはあるものの、完成物が仕様に沿っているかの確認を人手で行う必要があり、大規模な BIM ほど工数がかさむ 後工程での作り替えの難しさ : 設計時の BIM を施工や維持管理で活用しようとすると、データ要件が合わず作り替えが必要になる。そもそも「どんなデータを入れれば良いか」の定義自体が難しい これらの課題の根底にあるのは、「BIM に必要なデータ要件を、誰もが同じ解釈で共有できる形にできていない」 ことです。Excel の要件定義書や PDF の仕様書は人間には読めますが、機械が自動で検証するには情報が構造化されていません。 2. IDS とは何か ここで登場するのが IDS（Information Delivery Specification） です。IDS は buildingSMART が策定する国際標準で、「BIM の IFC ファイルに何が含まれているべきか」を XML 形式で機械可読に定義 します。IDS に対応する検証ツール（ IfcTester など）を使えば、IFC ファイルが IDS の要件を満たしているかを自動で判定できます。 BIM 活用が拡大するなか、発注者・設計者・施工者・維持管理者の間で BIM に求める情報を共通フォーマットで共有できる IDS の重要性は、今後さらに増していくと考えられます。 IDS の基本構造 IDS の中身は、specification と呼ばれるルールの集まりです。1 つの specification は次の 2 つの要素から構成されます。 applicability（適用対象） : どの IFC 要素に対するルールか。たとえば「IfcWall (壁) すべて」「外部に面した IfcDoor (ドア) だけ」など requirements（要件） : 対象要素が満たすべき条件。たとえば「Pset_WallCommon の FireRating プロパティが存在する」「Uniclass の分類コードが付与されている」など 両者で使える facet（ファセット、チェック項目） は 6 種類あります。 ファセット 意味 entity IFC エンティティの種別 (IfcWall, IfcDoor など) attribute IFC 標準属性 (Name, Description, GlobalId など) property プロパティセット内のプロパティ (Pset_WallCommon の FireRating など) material 材料の定義 classification 分類コード (Uniclass, OmniClass など) partOf 親子関係 (ある要素が何の下に属しているか) 実際の IDS ファイルは XML です。たとえば「すべての壁に、Pset_WallCommon の FireRating プロパティが必須」という specification は、次のように表現されます。 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS http://standards.buildingsmart.org/IDS/1.0/ids.xsd"> <ids:info> <ids:title>耐火等級を持つ壁</ids:title> </ids:info> <ids:specifications> <ids:specification ifcVersion="IFC4" name="耐火等級を持つ壁"> <!-- applicability: どの要素に適用するか（すべての壁） --> <ids:applicability maxOccurs="unbounded"> <ids:entity> <ids:name> <ids:simpleValue>IFCWALL</ids:simpleValue> </ids:name> </ids:entity> </ids:applicability> <!-- requirements: 満たすべき条件（FireRating プロパティが必須） --> <ids:requirements> <ids:property dataType="IFCLABEL"> <ids:propertySet> <ids:simpleValue>Pset_WallCommon</ids:simpleValue> </ids:propertySet> <ids:baseName> <ids:simpleValue>FireRating</ids:simpleValue> </ids:baseName> </ids:property> </ids:requirements> </ids:specification> </ids:specifications> </ids:ids> applicability の entity で「壁 (IFCWALL) すべて」を対象に指定し、 requirements の property で「Pset_WallCommon の FireRating プロパティを要求する」という意図を表しています。 IDS 作成の難しさ IDS の強みは明確ですが、自分たちの要件を IDS として書き起こす 作業には、いくつかの壁があります。 IDS は XML ベースの仕様で、書くには IFC スキーマの専門知識 が必要になる（どのエンティティが何のプロパティを持つか、正確な名前は何か、など） 要件が自社の Excel や PDF に「全ての壁に耐火等級を指定」といった自然言語で書かれているケースが多く、そのままでは IDS にならない プロジェクトのフェーズやユースケースごとに必要な IDS が異なるため、量的にも無視できない数の specification を作る必要がある つまり「IDS が使える」ことと「IDS を作れる」ことの間には、まだ距離があります。この距離を埋めるのが、本ブログのソリューションです。 IDS を用いたチェックを実施する上での課題と、それぞれに求められる仕組みを整理すると、次のようになります。 3. 課題の性質から設計を考える 具体的な AWS サービスの話に入る前に、まず「この課題をどういう考え方で解くか」を整理します。2 章までで見た IDS 作成の難しさを性質ごとに分解すると、取るべき打ち手が見えてきます。 要件は数十〜数百件ある → 1 件ずつ逐次で AI に処理させると、待ち時間が積み重なって現実的な時間に収まらないため、要件ごとに並列で処理する必要がある IDS を正しく書くには IFC スキーマの専門知識が要る → 「耐火等級」が IFC のどのプロパティ名にあたるか、といった知識を AI に与えないと正確な IDS にならない。そのため、専門知識を参照できる道具（ツール）を持った AI エージェントが適している（AI に単純なプロンプトを与えるだけでは精度が出にくい） 生成結果にミスがあると実用にならない → スキーマに違反した IDS は検証ツールで検証出来ないため、AI 自身が出力を検証し、誤りがあれば直すループが必要になる これらを踏まえ、次のアプローチが考えられます。 自然言語で書かれた要件一覧を構造化し、要件ごとに専門知識を持った AI エージェントが並列で IDS specification を生成し、検証済みの結果を 1 つの IDS ファイルにまとめる。 機能の流れだけを抜き出すと、次のようなステップになります。具体的にどの AWS サービスで実現するかは 4 章で詳述します。 このアプローチのポイントは、「専門知識の付与（ツール）」「並列処理」「自己検証」という 3 つの仕組みを組み合わせ、人手では負担の大きい IDS 作成を自動化している点にあります。次章では、これを AWS 上でどう実装したかを見ていきます。 4. AWS 上での実装 ここからは、3 章のアプローチを AWS 上で具体的にどう実現したかを解説します。まず全体のアーキテクチャを示し、その後で実装上のポイントになる 3 点、すなわち「IDS 生成エージェントをどう書くか」「AgentCore でどう動かすか」「要件ごとに並列実行するオーケストレーション」を順に見ていきます。 4.1 アーキテクチャ全体像 3 章で説明した流れを、次のような構成で実装しています。 処理は大きく 3 つのフローに分かれます。要件の構造化と IDS 生成（3 章の①〜③）に加えて、生成した IDS で IFC を検証するフローも実装しています。 (1) 要件構造化フロー ユーザーがフロントエンドから要件定義書をアップロード 構造化用 AWS Lambda が Amazon S3 から要件定義書を取得し、生成 AI で要件を抽出・構造化 構造化された要件一覧を Amazon Aurora に保存 (2) IDS 生成フロー ユーザーが IDS 生成を実行すると、Step Functions の IDS 生成ワークフローが呼び出される Step Functions が「(1) 要件構造化フロー」で構造化された要件一覧を受け取り、要件 1 件ごとに並列で Amazon Bedrock AgentCore Runtime を起動 各 AgentCore Runtime が生成した specification を Aurora に保存 全要件の処理完了後、集約用 Lambda が specification を 1 つの IDS ファイルにまとめて S3 に保存 ユーザーは生成された IDS ファイルを確認する (3) 検証フロー ユーザーがチェック対象の IFC ファイルと、生成済みの IDS を指定して検証を実行 検証処理を AWS Batch 上で起動し、IFC ファイルが IDS の要件を満たしているかを判定（ IfcTester を利用） 検証結果をユーザーに返し、要件を満たす/満たさない要素を一覧で確認 ここで出てきた「Amazon Bedrock AgentCore Runtime」は、2025 年に GA した、AI エージェントをデプロイ・実行するための AWS のサーバーレス環境です。Strands Agents、LangGraph、CrewAI など任意のフレームワークで書いたエージェントを、セッションごとに専用 microVM（分離された CPU・メモリ・ファイルシステム）で動かせるため、セッション間でデータが混ざりません。リアルタイムの対話だけでなく、最大 8 時間の長時間処理にも対応します。本実装では Strands Agents で書いた IDS 生成エージェントを AgentCore Runtime 上で実行しています。 4.2 IDS 生成エージェントの構造 3 章で挙げた「専門知識の付与」と「自己検証」を担うのが、この IDS 生成エージェントです。 Strands Agents （AWS がオープンソースで公開しているエージェントフレームワーク）で記述し、Claude Sonnet 4.5 をモデルとして使用しています。エージェントには以下の 4 つのツールを与えています。 schema_instruction_tool : IDS の TypeScript インタフェース定義、スキーマ制約などを返す ifc_knowledge_tool : IFC のエンティティ / プロパティ / 分類を検索するためのツール。たとえばエージェントが「wall」と検索すれば IfcWall が、「耐火等級」と検索すれば FireRating がヒットする（＝「専門知識の付与」を担うツール） example_tool : 条件に応じたサンプルの Specification（25 件の実例）を返す。Few-Shot 学習の材料として、エージェントがプロンプトに取り込む validation_tool : 生成した仕様を jsonschema で検証し、エラーを AI にフィードバックする。エージェントは自己修正して再生成できる（＝「自己検証ループ」を担うツール） エージェントの本体は、Strands で記述されており、次のようなシンプルな書き方で定義できます。 # ids_generator_agent.py（抜粋・簡略化） from bedrock_agentcore.runtime import BedrockAgentCoreApp from strands import Agent from strands.models import BedrockModel from tools import ( schema_instruction_tool, ifc_knowledge_tool, example_tool, validation_tool, ) app = BedrockAgentCoreApp() agent = Agent( model=BedrockModel( model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0", temperature=0.3, ), tools=[ schema_instruction_tool, ifc_knowledge_tool, example_tool, validation_tool, ], system_prompt=SYSTEM_PROMPT, ) @app.entrypoint async def agent_invocation(payload): user_message = payload.get("prompt") result = await agent.invoke_async(user_message) return result.message if __name__ == "__main__": app.run() システムプロンプトには「出力は必ず純粋な JSON のみ」「markdown コードブロックや説明文を混ぜない」「IFC 用語は ifc_knowledge_tool で必ず検証する」といった細かい指示を含めており、出力の一貫性を担保しています。また、プロンプトで validation_tool を必ず最後に呼んでから返すよう指示することで、スキーマ違反の specification が保存されるリスクを防いでいます。 4.3 AgentCore Runtime へのデプロイ Strands で書いたエージェントを AWS 上で動かすには、通常であれば Amazon ECS や Lambda のコンテナイメージを組み、 Amazon API Gateway を前段に置いて…と手順が多くなります。AgentCore Runtime を使うと、こうしたデプロイ周りの作業が非常に簡単になります。AWS が提供する AgentCore Starter Toolkit （ pip で導入できる CLI ツール）を使えば、ローカルでの開発・テストから本番デプロイまでを、次のようなコマンドで実現できます。 # ローカル開発 (ホットリロード付き) agentcore dev # ローカルテスト agentcore invoke --dev "All walls must have a fire rating" # 本番デプロイ agentcore configure --entrypoint ids_generator_agent.py agentcore launch 4.4 Step Functions Map で IDS specification を並列生成する ここが本実装の中心です。3 章で述べたとおり、BIM の要件定義書には、1 件のプロジェクトで数十〜数百件の要件が含まれることも珍しくありません。これを逐次で処理すると、AI 呼び出しの待ち時間が積み重なり、現実的な応答時間に収まりません。 そこで本実装では、 Step Functions の Map ステート を使い、要件ごとに AgentCore Runtime を並列で呼び出します。Map ステートは「配列の各要素に対して同じ処理を実行する」ための制御で、並列度を制限したり、各要素のエラーを個別にハンドリングしたりできます。 処理フローを図にすると次のようになります。要件一覧を受け取った Map ステートが要件を 1 件ずつ並列レーンに割り当て、各レーンで AgentCore のエージェントが IDS を生成し、すべて出揃ったところで集約 Lambda が 1 つの IDS ファイルにまとめます。 この並列化のポイントは 3 つあります。 AgentCore Runtime が「セッション分離」を前提とした設計のため、並列呼び出しが安全 : 各セッションが専用の microVM で動くため、状態が混ざる心配がない。Lambda でエージェントをホストする場合のように「同じインスタンスでの実行順序」を考慮する必要がない 個別要件の失敗が全体を止めない : Map 内の各要件の処理は独立しているため、1 件の要件が失敗しても残りの要件は処理が続く。失敗した要件は DB に error ステータスで記録され、ユーザーは後で個別に再実行できる リトライ戦略を Step Functions 側で完結させられる : AgentCore の一時的なスロットリングや Claude のタイムアウトは、Step Functions の自動リトライ（指数バックオフ）に任せられる。Lambda のコードに再試行ロジックを書く必要がない これらの並列度・エラーハンドリング・リトライの設定は、すべて AWS CDK 上で宣言的に定義しています。Map ステートの並列処理を「アプリケーションのコードではなく、ワークフロー定義として外側に持てる」ことが、実装をシンプルに保つことに繋がっています。 4.5 動作イメージ ここまでの仕組みを、実際の画面で一連の流れとして見てみます。 まず、要件定義書（PDF）をアップロードすると、生成 AI が内容を解釈し、要件を 1 件ずつ構造化して一覧に展開します。 次に、構造化された要件のうち、IDS specification を生成する対象を選択します。 「生成」を実行すると、AgentCure Runtime により、選択した要件ごとに specification が並列で生成され、各要件の状況（処理中 / 完了など）がリアルタイムに更新されます。 生成された specification は、要件ごとに内容を確認できます。 最後に、生成した IDS を使い、チェック対象の IFC ファイルが要件を満たしているかを検証します。本ソリューションでは、検証処理は AWS Batch 上で実行しています。 5. 考慮点: 条件分岐の多い要件への対応 本ブログで紹介したアプローチは、「全ての壁に耐火等級」「外部ドアは防火性能 60 分以上」といった、独立したルールが多数並ぶタイプの要件定義に有効です。一方で、用途・地域・構造などの組み合わせで要求内容が変わる、条件分岐が多い領域（たとえば建築基準法のような規定群）には、IDS の仕様上の制約から、そのままでは適用しづらい点があります。 理由は、IDS の設計思想にあります。IDS は「情報デリバリー仕様」という名前のとおり、「何が含まれているべき/いないべきか」を記述するのがスコープで、1 つの specification の中に if-then-else のような条件分岐を入れ込む機能は持ちません。条件によって要求が変わるルールは、条件の組み合わせごとに別々の specification として分割する必要があります。 チェックのスコープや内容によっては、様々な条件の組み合わせで要求内容が変わるため、これらを素朴に specification として展開すると、その数は膨大になります。本ブログのアプローチは個々の要件を IDS 化する部分を自動化しますが、こうした「条件分岐をどう整理して IDS に落とすか」という設計の問題は依然として残ります。分岐の多い領域へ適用を広げる際の検討課題と言えるでしょう。 6. まとめ 本ブログでは、BIM の要件定義を巡る課題と、それに対する国際標準 IDS の位置づけを整理した上で、「自然言語で書かれた要件定義書から IDS を自動生成する」 ソリューションを、実装レベルで解説しました。要点は次のとおりです。 IDS は buildingSMART が 2024 年に v1.0 として承認した国際標準で、IFC ファイルに何が含まれているべきか/いないべきかを機械可読に定義する IDS 作成には IFC スキーマの専門知識が必要で、自然言語の要件定義からの変換は手作業では負担が大きい 課題の性質（要件が多い / 専門知識が要る / ミスが許されない）から、「並列処理」「専門知識ツールを持つ AI エージェント」「自己検証ループ」という 3 つの仕組みを組み合わせるアプローチを紹介 建築基準法のように条件分岐が多い領域には、IDS の仕様上、条件の組み合わせごとに specification を分割する必要があり、その整理が適用範囲を広げる際の検討課題となる このアプローチの利点は、既存の要件定義資産（自然言語の Excel / PDF）をそのまま活用しながら、機械可読な IDS に変換できることです。本ブログでは IDS を題材にしましたが、同じ並列エージェントパターン（「自然言語の要件 → 構造化 → 要件ごとの並列 AI 処理 → 集約」）は、仕様書からのテストケース生成、要件定義からのチェックリスト生成など、大量の個別要件を AI で処理する場面に応用できます。

はじめに 建設業界における BIM（Building Information Modeling）の導入は着実に進んでいます。BIM は建物の 3D 形状に加えて、各部材の寸法・材料・性能といった属性情報を一元的に持つ、いわば「建物のデータベース」とも言える存在です。しかし、その豊富なデータは、後述するいくつかの理由から、十分に活用されていない、という声もよく耳にします。 こうしたなか、BIM データ活用に向けた一つのアプローチとして注目されているのが生成 AI です。近年の生成 AI の発展により、「自然言語で BIM データを読み書きする」「AI エージェントが建物データを解釈して次のアクションに繋げる」といった使い方が現実的になりつつあります。本ブログでは、AWS Summit Japan 2025 の建設・不動産ブースで展示した IFC Viewer with GraphRAG を題材に、IFC ファイルをグラフに変換してグラフデータベースに格納し、生成 AI エージェントが情報を問い合わせる仕組みを、実装レベルで解説します。 なお本ブログは、1〜2 章で「なぜこの構成にしたのか」というアプローチと設計の考え方を、3 章で「どう実装したか」という詳細を扱い、4 章で発展的な拡張に触れる構成です。3 章以降は RDF グラフのモデリングや AI アプリの実装に踏み込む内容のため、グラフデータベースや生成 AI の開発経験があると読み進めやすくなりますが、各節の冒頭に要約を置いているため、詳細を読まなくても全体の流れは追えるようになっています。 1. BIM データを AI から扱うアプローチ BIM が普及するにつれ、3D 形状と属性情報を一元的に持つ「建物のデジタルデータ」が、案件ごとに蓄積されるようになりました。生成 AI を活用することで、こうしたデータに自然言語で問い合わせたり、AI エージェントに解釈させて次の作業へ繋げたりといった応用に繋げることができます。 その入口としてまず候補になるのが、各種 BIM プラットフォームが提供する REST API を、AI エージェントの Tool、あるいは MCP（Model Context Protocol）サーバー経由で渡す方法です。BIM データに API 経由でアクセスできるサービスは増えており、データを別の形式に変換したり外部に書き出したりせず、プラットフォームに置いたまま AI から参照できます。導入の手間が小さく、認証認可の仕組みや、ビューワーまで BIM プラットフォームで完結する利点があります。半面、取得できるデータやロジックは、ベンダーが提供する API の範囲に縛られます。API が想定していない切り口での集計や、他システムのデータとの突き合わせといった使い方には対応しにくいという制約があります。 （補足: MCP はアプリケーションが AI にツールやデータソースを提供するための共通プロトコルで、対応していれば異なる AI クライアントから同じツールを使えます） オープンフォーマットな BIM (IFC) を起点にする 特定ベンダーの API 範囲に縛られたくない場合、業界標準のオープンフォーマットである IFC（Industry Foundation Classes） を起点にする方法があります。IFC は、建設分野のオープンな BIM 標準を策定する、国際的な非営利団体である buildingSMART が定めた国際標準フォーマットで、特定ベンダーの製品に依存せず建物データを表現・交換できます。主要な BIM ツールは IFC のエクスポートに対応しているため、特定の製品で作成した BIM モデルであっても IFC 形式に変換できます。 ただし、IFC は AI がそのまま解釈できる形式にはなっていません。IFC は STEP 物理ファイル形式というテキスト形式で、中身は次のように、エンティティを #1234= のような ID 番号で繋いだフラットな構造になっています。 #129= IFCBUILDING('0w984V0GL6yR4z75XVLWOr',#41,'',$,$,#32,$,'',.ELEMENT.,$,$,#125); #138= IFCBUILDINGSTOREY('0w984V0GL6yR4z75YWgVfX',#41,'Nivel 1',$,'Nivel:Nivel 1',#136,$,'Nivel 1',.ELEMENT.,0.); #186= IFCWALLSTANDARDCASE('2idC0G3ezCdhA9WVjWemc$',#41,'Muro básico:Partición con capa de yeso:163541',...,#155,#182,'163541'); #6723= IFCWINDOW('2idC0G3ezCdhA9WVjWe$OB',#41,'Ventana simple:100 x 100 cm:164193',...,#25036,#6717,'164193',2.3,1.); 壁 ( #186 ) が所属する階 ( #138 ) は #136 経由でたどり、窓 ( #6723 ) が埋まっている壁は IFCRELVOIDSELEMENT / IFCRELFILLSELEMENT を介して参照する、といった具合です。エンティティの量（上記は数万行のうちの一部です）も相応にあり、AI にこの生テキストを渡してそのまま解釈させるのは現実的ではありません。 この IFC を扱いやすくするアプローチが、大きく 2 つあります。1 つは IFC を解釈できるライブラリを使ってその場で読む方法（A）、もう 1 つは IFC を別のデータモデルに変換し、データベースに格納してから問い合わせる方法（B）です。 (A) IFC を扱えるライブラリを AI のツールとして渡す 1 つ目は、IFC を扱えるオープンソースソフトウェア（OSS）を Tool として渡し、エージェントに探索させる方法です。代表的な OSS が IfcOpenShell で、先ほどのような生の STEP テキストを直接たどる必要はありません。 by_type("IfcWall") で壁を一覧したり、 #136 のような番号ではなく wall.Name のように属性名でアクセスしたり、ある要素を参照している関連要素を逆向きにたどったりと、IFC の構造を扱いやすい形で読み取ることができます。先ほど挙げたフラットさや参照の複雑さの多くは、こうしたライブラリが吸収します。 一方で、このアプローチには考慮すべき点もあります。問い合わせのたびに IFC ファイルを読み込んで探索する形になるため、エージェントにライブラリの API を組み合わせて目的の情報までたどらせると、問い合わせの内容によっては探索の手数が読みにくく、応答時間も安定しません。また、複数の建物をまたいだ横断検索や、大量要素の集計のように「あらかじめ整理されたデータ」を前提とする用途とは相性がよくありません。1 ファイルを対象とした素朴な参照には手軽で有効である一方、規模や横断性が増すほど追加の工夫を要する、という位置づけです。 (B) IFC を構造化してデータベースに格納し、AI が問い合わせる 2 つ目は、IFC を一度解釈し、用途に合わせたスキーマでデータベースに格納してから、エージェントには「データベースを問い合わせる Tool」を渡す方法です。問い合わせのたびにファイルを探索する代わりに、あらかじめ整理した状態を用意しておく、という発想です。 データの構造を案件・用途に合わせて設計できるので、カスタマイズの自由度が最も高くなります。複数ファイルをまたいだ横断検索や集計を書きやすい形に整えたり、他システムのデータと突き合わせやすいスキーマにしたりと、(A) では難しかった用途にも対応できます。半面、変換パイプラインとデータベースの両方を用意・運用する必要があり、導入コストは最も高くなります。 本ブログで扱うアプローチ ベンダー API（最初に触れた方法）、ライブラリでの直接探索（A）、データベースへの構造化（B）と、後ろにいくほど構築の手間は増えますが、その分、任意の構造でデータを格納でき、検索・集計・横断分析の自由度が高くなります。本ブログでは、この (B) のアプローチを採用した実装例を取り上げます。次の章では、データベースとして何を選び、どう組み立てたかを見ていきます。 2. IFC をグラフに変換して、グラフデータベースに格納する 採用したアプローチを一言でまとめると、「IFC をグラフ (RDF グラフ) に変換してグラフデータベース (Amazon Neptune Serverless) に格納し、AI エージェントがクエリ言語 (SPARQL) で問い合わせる」というものです。 (B) のデータモデルとして RDF グラフを選んだ理由は、BIM データの性質にあります。BIM データは「壁が窓を含む」「階が要素を持つ」といった、モノ同士の関係の集まりで、構造的にはグラフそのものです。また、検索する際も、関係をいくつもたどっていく問い合わせが中心になります。こうした「関係をたどる」処理は、テーブルを JOIN し続けるリレーショナルデータベースよりも、関係をそのままエッジとして持つグラフデータベースのほうが素直に記述できます。 RDF（Resource Description Framework）についても簡単に補足します。RDF は、あらゆる事実を「主語 – 述語 – 目的語」の 3 つ組（トリプル）で表す W3C 標準のデータモデルです。たとえば「Wall_001 は Window_002 を含む」という事実は、 Wall_001 - hasSubElement - Window_002 というトリプルで表せます。これを大量に集めると、ノード（モノ）とエッジ（関係）からなるグラフになります。 グラフの表現方法は他にもありますが、今回 RDF を選んだのは、既存の資産をそのまま活かせるためです。建設業界で広く使われている IFC を Linked Building Data（LBD）系のオントロジーで RDF 化する考え方や OSS が整備されており、さらに Amazon Neptune がマネージドサービスとして RDF / SPARQL をサポートしています。これにより、変換パイプラインとデータベース運用のいずれも、ゼロから構築する必要がありません。 アーキテクチャ 全体のアーキテクチャは以下の通りです。 処理の流れは大きく 2 系統に分かれます。 (1) 取り込み系: IFC → RDF グラフ → Neptune へのロード ユーザーが IFC ファイルを Amazon S3 にアップロード S3 イベントを Amazon EventBridge で受け、AWS Batch で変換用コンテナを起動 コンテナ内で IFC → Turtle 変換ツールを実行し、IFC を Turtle 形式（RDF を表現するテキスト形式の 1 つ）のファイルに変換して S3 へ書き戻す Turtle ファイルの S3 PUT イベントが AWS Lambda を起動し、Amazon Neptune の bulk loader API でグラフをロード 同じ Lambda が、後段の問い合わせで使うメタデータを Turtle から抽出して Amazon DynamoDB に保存 (2) 問い合わせ系: ユーザーの質問 → SPARQL → 自然言語回答 ユーザーがフロントエンドから自然言語の建物に関する質問を投げる Amazon API Gateway を経由して、エージェント実装の Lambda を起動 Lambda は対象 IFC のメタデータを DynamoDB から読み出し、Amazon Bedrock（Anthropic Claude）で SPARQL クエリを生成 生成した SPARQL を Neptune 上で実行し、結果を Bedrock で自然言語に整形してユーザーに返す 中間結果と最終回答は AWS AppSync Events で配信し、フロントの 3D ビューワー上で対象オブジェクトをハイライト なお、ここで出てきた「Turtle（タートル）」は RDF を表現するファイル形式の 1 つで、人間が読み書きしやすいように設計された構文です。次章で実例を載せます。 3. 主要コンポーネントの実装 ここからは実装の中身に入ります。(B) のアプローチで実装上のポイントになるのは、「IFC をどんな形の RDF グラフにするか」と「AI にどう SPARQL を書かせるか」の 2 点です。この章では RDF グラフのモデリングや AI アプリの実装に踏み込むため、グラフデータベースや生成 AI の開発経験があると読み進めやすい内容です。各節の冒頭に要約を置いているので、詳細を飛ばしても流れは追えるようにしています。 3.1 IFC を RDF グラフに変換する 要約 : IFC を RDF に変換すると、「建物 → 階 → 要素」という階層構造が、そのままグラフのノードとエッジになります。リレーショナルデータベースのような JOIN なしで関係をたどれるので、後段の問い合わせが書きやすくなります。 本ブログで紹介するソリューションでは、IFC からの RDF 変換に IFCtoLBD という OSS を使用しています。これは、IFC ファイルを、グラフとして扱いやすい RDF（Turtle 形式）に変換してくれるツールです。変換後のデータは、Linked Building Data（LBD）で整備されている公開オントロジー（建物データの語彙を定めたもの。建物トポロジーを表す BOT など）に沿った形になります。本実装では、この変換作業を AWS Batch のコンテナで実行しています。 変換後の Turtle は、たとえば次のようになります（1 章で示した IFC と同じ建物の変換結果からの抜粋です）。 @prefix bot: <https://w3id.org/bot#> . @prefix props: <http://lbd.arch.rwth-aachen.de/props#> . @prefix inst: <https://lbd.example.com/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . # 建物（Building）— 配下に階が 2 つ inst:building_3a24811f-0105-46f1-b13d-1c585f560635 a bot:Building ; bot:hasStorey inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 , inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9ff4b ; props:numberOfStoreys_property_simple 2 ; props:globalIdIfcRoot_attribute_simple "0w984V0GL6yR4z75XVLWOr" . # 階（Storey）が要素（Element）を含む inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 a bot:Storey ; rdfs:label "Nivel 1" ; props:elevationIfcBuildingStorey_attribute_simple "0."^^xsd:double ; bot:containsElement inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf , inst:slab_76178dce-ff53-4da5-b52a-f5f1ad7930e7 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f63e . # ... (door, furniture など同階の要素が続く) # 壁（Element）— 9 つの窓をサブ要素として持つ inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf a bot:Element ; rdfs:label "Muro básico:Partición con capa de yeso:163541" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" ; props:objectTypeIfcObject_attribute_simple "Muro básico:Partición con capa de yeso" ; props:loadBearing_property_simple false ; props:isExternal_property_simple false ; bot:hasSubElement inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f608 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f673 . # ... (計 9 個の窓が続く) # 窓（Element）— IFC 由来の属性がリテラル値で並ぶ inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b a bot:Element ; rdfs:label "Ventana simple:100 x 100 cm:164193" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWe$OB" ; props:objectTypeIfcObject_attribute_simple "Ventana simple:100 x 100 cm" ; props:overallWidthIfcWindow_attribute_simple "1."^^xsd:double ; props:overallHeightIfcWindow_attribute_simple "2.3"^^xsd:double ; props:thermalTransmittance_property_simple 6.7069 . 注目してほしいのは次の点です。 bot:Building / bot:Storey の階層と bot:Element のフラットな要素集合 : 建物 → 階など、馴染みのある階層関係が bot:hasStorey でグラフ化されます。各階が直接持つ部材は bot:containsElement で壁・スラブ・窓・扉・家具・方立などを指し、これらはすべて bot:Element クラスでラベル付けされます 壁と窓のようなサブ要素の関係 : 壁に埋まっている窓は bot:hasSubElement で壁と関係性を持ちます。上の壁は 9 個の窓を含む要素で、これをたどれば「この壁には窓が何個あるか」という質問がそのまま 1 ホップのグラフ走査になります props: 接頭辞の属性 : 寸法・面積・体積・グローバル ID・熱貫流率（ thermalTransmittance ）・外部面かどうか（ isExternal ）といった IFC 由来の属性は、 props: 名前空間配下のプロパティとしてリテラル値で付与されます。 props:globalIdIfcRoot_attribute_simple は IFC の GlobalId にあたり、ビューワー上のハイライトなど、3D モデルのオブジェクトと紐付ける際のキーになります。 このように、「Wall ノードが Window ノードを hasSubElement で含み、寸法はリテラル属性として持つ」というシンプルなモデルで建物全体を表現できます。リレーショナルデータベースのように「壁テーブル」「窓テーブル」を JOIN する必要はなく、関係をそのまま辿ることができます。 3.2 ファイル単位で名前空間を分ける（Named Graph） 要約 : 複数の IFC を 1 つの Neptune に同居させると要素 URI が衝突します。RDF の Named Graph でファイルごとにグラフ空間を分けておくと、衝突を防ぎつつ「特定の建物だけに問い合わせる」のも簡単になります。 複数の IFC ファイルを 1 つの Neptune クラスタに同居させると、要素 URI が衝突したり、特定のファイルだけを対象にした問い合わせが書きづらくなったりします。本実装では RDF の Named Graph を使い、ファイルごとに専用のグラフ空間を割り当てています。 ファイル building-A.ifc → Named Graph URI http://example.com/graphs/ifc/building-A ファイル building-B.ifc → Named Graph URI http://example.com/graphs/ifc/building-B SPARQL では GRAPH <...> 句で対象を絞り込めるため、後述のクエリも基本的にこの形になります。Neptune の bulk loader はリクエストパラメータの parserConfiguration.namedGraphUri でロード先のグラフを指定できるので、ロードの時点で分割しています。 3.3 自然言語を SPARQL に変換する（text-to-SPARQL） 要約 : ユーザーの質問を AI が SPARQL に翻訳し、Neptune で実行し、結果を再び自然言語に戻します。LangChain の既製チェーンをベースに、LangGraph で 2 ノード構成にまとめています。クエリの精度を上げるうえで一番効くのは、「お手本のクエリ例（Few-Shot）」をプロンプトに同梱することです。 問い合わせ系の中心は、ユーザーの自然言語の質問を SPARQL クエリに変換し、結果を再び自然言語で返す、いわゆる text-to-SPARQL の処理です。 本実装のベースには LangChain の create_neptune_sparql_qa_chain を採用しています。これは「スキーマを AI に渡して SPARQL を生成 → Neptune で実行 → 結果を AI に渡して自然言語化」という一連のチェーンが実装されています。 全体の処理フローは以下のとおりです。 実装上は、LangGraph を使って ① の要素選択ノード と ② 〜 ⑤ をまとめた SPARQL 処理ノード の 2 ノードにまとめており、後者のノードの中で LangChain のチェーンを順に呼び出しています。 AI に SPARQL を生成させるときに効果的になるのが Few-Shot プロンプティング 、つまり「こういう質問にはこういうクエリを書く」という例題をプロンプトに同梱することです。本実装では、IFC ファイルをロードするタイミングで、その IFC に含まれる要素タイプを参考にしながら、問い合わせ例の質問・SPARQL ペアを自動生成して DynamoDB に保存しています。問い合わせ時にはここから読み出してプロンプトに差し込みます。 3.4 必要なスキーマだけを DynamoDB から読み出す 要約 : 既製チェーンをそのまま使うと、DB 上の全クラス・全述語をプロンプトに載せてしまい、IFC のように要素が多いと応答が遅く、コストもかさみます。本節では、必要なスキーマだけを事前に切り出して持っておく工夫を紹介します。 LangChain の create_neptune_sparql_qa_chain をデフォルトのまま使うと、内部の NeptuneRdfGraph が、対象データベース上のすべてのクラスと述語をスキーマとして取得し、まるごとプロンプトに含めます。小さいオントロジーなら問題ありませんが、IFC のように要素タイプ・属性が多い場合は、初回応答の遅さとプロンプトサイズの増加が問題になります。既製チェーンの「全スキーマをそのまま渡す」前提が、IFC の規模では合わなくなる、ということです。 そこで本実装では、 NeptuneRdfGraph を継承した NamedGraphAwareNeptuneRdf クラスを用意し、次の 2 点を変えました。 スキーマクエリを Named Graph 単位に絞る : GRAPH <namedGraphUri> { ... } で囲み、ファイル単位のスキーマだけを取得する DynamoDB から事前ロード済みスキーマを使う : IFC ロード時にスキーマを抽出して DynamoDB に保存しておき、問い合わせ時は Neptune ではなく DynamoDB から読み出す DynamoDB には、IFC ファイル 1 つにつき 1 レコードの形でメタデータを保存しています。1 レコードには、そのファイルのスキーマ（登場するクラスや述語の一覧）、Few-Shot 用のサンプルなどをまとめています。中身のイメージは次のとおりです。 { "loadStatus": "READY", "fileName": "small-l1-p", "namedGraphUri": "http://example.com/graphs/ifc/small-l1-p", "schema": { "classes": [ {"uri": "https://w3id.org/bot#Building", "local": "Building"}, ... ], "rels": [ {"uri": "https://w3id.org/bot#hasSubElement", "local": "hasSubElement"}, ... ], "dtprops": [ {"uri": ".../thermalTransmittance_property_simple", "local": "..."}, ... ], "oprops": [] }, "resourceTypes": { "wall": 3, "window": 10, "door": 1, "slab": 2, ... }, "examples": "<question>...</question><sparql>...</sparql>" } これにより、Neptune へのスキーマ問い合わせの往復が省けて応答時間が短くなり、プロンプトに載せるスキーマもそのファイルに必要な分だけになるので、コンテキストの消費とトークンコストを抑えられます。 参考までに、最終的に AI が生成する SPARQL は次のような形になります（ユーザーの質問は「特定の壁に含まれる窓の数は？」）。 PREFIX props: <http://lbd.arch.rwth-aachen.de/props#> PREFIX bot: <https://w3id.org/bot#> PREFIX inst: <https://lbd.example.com/> SELECT (COUNT(?window) AS ?windowCount) WHERE { GRAPH <http://example.com/graphs/ifc/small-l1-p> { ?wall props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" . ?wall bot:hasSubElement ?window . FILTER(STRSTARTS(STR(?window), STR(inst:window_))) } } GRAPH <...> で対象 IFC を絞り、 hasSubElement で壁配下の要素をたどり、URI 接頭辞 inst:window_ の一致で窓に絞る、という意図がそのままクエリになっています。先ほどの 9 個の窓を持つ壁にこのクエリを実行すると、 windowCount = 9 が返ります。 3.5 動作イメージ ここまでの仕組みを通すと、ユーザーから見た動作は次のようになります。自然言語で質問を投げると、AI が SPARQL を生成・実行して自然言語で回答を返し、同時に該当する建物要素が 3D ビューワー上でハイライトされます。 質問する側は SPARQL や IFC の内部構造を知らなくても、「窓の熱貫流率を教えて」「家具は全部で何個ある？」と尋ねるだけで、回答と該当箇所の表示を同時に得られます。1 章で触れた、IFC の構造を知らないと素朴な問い合わせすら難しいという問題が、この画面の中で解消されていることが見て取れます。 4. GNN（Graph Neural Network）と組み合わせた発展 要約 : text-to-SPARQL は「決まった問い合わせ」に強い一方、BIM の繋がり方そのものから何かを予測するタスクは、生成 AI 単体では扱いづらい領域です。同じ RDF グラフを訓練データとして GNN を併用すると、干渉解消・熱負荷予測・意味付け補強といった、研究実績のあるタスクに広げられます。 生成 AI の発展により、「以前は自前で機械学習モデルを訓練していたタスクも、AI エージェントに任せれば対応できる」場面は増えています。本ブログの text-to-SPARQL もその流れの上にあります。 一方で、BIM のように、ノードとエッジの繋がり方そのものに意味があるデータに対しては、グラフ構造を学習する Graph Neural Network（GNN）が効果的なタスクも残っています。GNN は、各ノードの属性と隣接ノードからの情報を集約してベクトル表現を学習する深層学習モデルです。グラフデータベースに格納したデータをそのまま訓練データに利用できるため、本ブログのアーキテクチャと組み合わせやすい拡張先です。 BIM の分野で GNN が効果を発揮するユースケースを、3 つ紹介します。いずれも「答えが既存データの検索では得られず、予測が必要になる」という点で、GNN が効果的な領域です。 4.1 干渉解消（クラッシュ・レゾリューション）の予測 干渉チェックツールが出力する大量の候補のうち、多くは無視できる重なりで、本当に対処すべき干渉の仕分けと、どのコンポーネントを動かすかの判断に時間がかかります。これが GNN に向いているのは、「どれを直すべきか」が周辺コンポーネントとの関係に左右され、単体の属性だけでは決まらないからです。Hu ら（2023, Clash context representation and change component prediction based on graph convolutional network in MEP disciplines ）は、干渉が起きたコンポーネントと周辺の依存関係をグラフで表現し、Graph Convolutional Network で「どのコンポーネントを修正すべきか」を予測する手法を提案しています。周辺への波及を加味して判断できる点が特徴です。 4.2 部屋やゾーンを跨いだ熱負荷・エネルギー予測 従来の機械学習モデルは、建物全体を 1 ゾーンとして扱うか、各ゾーンを独立に扱うかのどちらかで、ゾーン間の熱の相互作用を捉えきれないという課題がありました。GNN はゾーンをノード、ゾーン間の隣接関係をエッジとしてグラフ化できるので、熱伝達を構造として取り込んだ上で予測できます。Lu ら（2023, Temporal graph attention network for building thermal load prediction ）は Graph Attention Network と GRU を組み合わせ、多ゾーンの熱負荷を同時に予測するモデルを提案しています。 4.3 BIM の意味付け補強（セマンティック・エンリッチメント） BIM モデルは、設計者やツールの違いによって要素の分類ラベルや属性が不揃い・不完全になりやすく、これが下流の数量積算や確認申請の自動チェックに影響します。Tarabishy & Sacks ら（2024, Incorporating Context into BIM-Derived Data—Leveraging Graph Neural Networks for Building Element Classification ）は、GNN ベースの要素分類が、幾何特徴のみを見る従来手法（SVM など）よりも精度で上回ることを示しています。「予測ラベルと登録ラベルが食い違う要素」を要レビュー候補として抽出する整合性チェックにも応用でき、ルールエンジンだけでは難しい BIM データの品質維持に有効な領域です。 AWS でのアプローチ GNN を AWS で動かす場合、まず候補になるのが Amazon Neptune ML です。Neptune に格納したグラフから、GNN モデルを訓練・推論できる機能で、ノード分類・回帰、エッジ分類・回帰、リンク予測が標準でサポートされています。 5. まとめ 本ブログでは、BIM データ（IFC）に AI エージェントからアクセスさせる 3 つのアプローチを整理した上で、そのうちの「IFC をグラフに変換してグラフデータベースに格納し、AI エージェントが問い合わせる」という構成を、実装レベルで解説しました。要点は次のとおりです。 IFC → Turtle の変換を AWS Batch で実行し、 bot: / props: 系のオントロジーで「建物 → 階 → 要素」のグラフを生成 自然言語の質問から SPARQL を生成して回答する仕組み（text-to-SPARQL）を構築。各ファイルのスキーマやサンプルクエリを事前に用意しておくことで AI エージェントが素早く正確に情報を取得できる 建物のグラフデータは、Amazon Neptune ML で GNN を組み合わせて、干渉解消の優先度予測・多ゾーンの熱負荷予測・BIM の意味付け補強といった、生成 AI 単体では解決しにくいタスクに広げられる可能性がある このアプローチの一番の利点は、データ構造を自分たちの用途に合わせて設計できることです。1 章で見たアプローチの比較に戻ると、ベンダー API の範囲で実現する方法や、ライブラリで IFC をその場で読む方法に対して、本ブログで紹介した手法は IFC を予め整理した状態で持っておくことで、複数ファイルの横断検索や集計の書きやすさも、他システムのデータとの突き合わせもスキーマ設計で吸収できます。一方、柔軟性と引き換えに変換パイプラインやデータベースを設計・運用するコストがかかるため、ユースケースに応じて、上手く使い分けるのが良いでしょう。

本ブログでは、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースで展示するデモを題材に、AWS のクラウドサービスと産業用ロボットを組み合わせた自律オペレーションの実現方法をご紹介します。 はじめに Physical AI とは、ハードウェアを通じて物理世界を知覚し、ソフトウェア側で理解・推論・学習を行い、再びハードウェアを通じて物理世界に働きかける技術です。テキストの内容を返すデジタル AI とは異なり、ロボットやヒューマノイド、AGV といったハードウェアを通じて、物理的なアクションを自律的に実行します。AI とロボティクスの双方が同時に進化しブレークスルーを迎えた今、製造・物流・インフラ管理など、あらゆる産業の現場オペレーションが変革されようとしています。 従来の産業用ロボットは事前にすべての動作をプログラミングする必要があり、予期せぬ状況や形状が変化する対象物には対応できないという壁がありました。Physical AI は状況を自ら判断し、不確実性の高い環境にも適応できます。ここに、AI エージェントが自律的に「調査し、判断し、実行する」能力が加わることで、真に自律的なオペレーションが可能になります。 Physical AI とは — Agentic AI が現実世界に出るとき 本デモにおける Physical AI の中核 — Agentic AI 本デモにおける Physical AI の中核は、AI エージェント（Agentic AI）です。ソフトウェアの世界で発展してきたエージェントの能力 — ツール呼び出し、メモリへの学習蓄積、計画立案と実行 — を、カメラやセンサーによる「知覚」とロボットアームや自律走行車両による「行動」へと拡張し、知覚 → 判断 → 行動のループを自律的に回します。 なぜ今 Physical AI なのか Physical AI が注目される背景には、いくつかの技術的ブレークスルーがあります。 LLM の推論能力の飛躍的向上 — 複雑な状況判断や計画立案が可能に Agentic AI フレームワークの成熟 — ツール呼び出し、メモリ管理、マルチエージェント協調が実用レベルに クラウド-エッジ連携の高度化 — 低遅延通信と安全な制御の両立 協働ロボットの普及 — 人と同じ空間で安全に動作するロボットが入手可能に これらが揃った今、AI エージェントが現実世界で自律的にオペレーションを遂行する時代が到来しています。 デモコンセプト — 「知らない状態」から自律的に解決する 概要 現実世界とつながった AI エージェントが、想定外の障害に対して自ら調査し、自ら考え、ロボットを動かして解決する。 私たちが構築したデモは、空想の街に Amazon のラストワンマイル配送を模した配送網を作り、来場者が自由に障害を仕掛けることで、AI エージェントの自律的な問題解決能力を体験してもらうものです。 重要なのは、これが 事前にプログラムされたシナリオではない という点です。来場者が自由に障害物を配置するため、毎回異なる状況が発生します。AI エージェントは障害の存在も位置もあらかじめ知らない「ゼロ」の状態から、調査・判断・実行を自律的に回していきます。 来場者体験の設計 来場者の目の前には2つの画面が並びます。 画面 内容 AI エージェントの思考 AI エージェントがいま何を考え、次に何をしようとしているかをリアルタイム表示 AI が認識している世界 AI エージェントが現時点で認識している世界。調査が進むにつれて実際の状態に近づく この2つを見比べることで、AI がまだ何を知らず、いま何を考え、どう行動しようとしているかが一目でわかります。リアルタイムダッシュボードではエージェントの調査計画・復旧方針が逐次可視化されます。 デモフロー — 5ステップの自律オペレーション デモは1サイクル約3〜4分で、以下の5ステップで進行します。 Step 1: 通常配送（デモの起点） 空想の街で、配達車両（TurtleBot）が物流・倉庫エリアから配送先へルートを巡回しています。配送網は正常に動いており、来場者にはまずこの「通常状態」を見てもらいます。 Step 2: 来場者が障害を発生させる 来場者が配送ルート上に障害物を配置すると、配達車両が障害物を検知して停止し、配送が止まります。障害の場所は来場者が自由に決めるため、毎回パターンが異なります。 Step 3: AI エージェントが調査を開始する 配送停止を検知した AI エージェントが、障害の特定に動き出します。FANUC CRX-20iA/L 協働ロボットのアーム先端カメラ（FRAMOS D435e）でトラブルが起きた通りを探索し、段階的にデータを収集します。 以下のループで段階的に進みます。 周辺調査 — トラブルが起きた通りをカメラで撮影する 認識の更新 — 得られたデータをもとに AI が自分の地図を更新する 次の調査計画 — 追加で調べるべき箇所があるかを判断する 一発で全容がわかるわけではなく、このループを繰り返しながら障害を見極めます。 Step 4: 復旧の実行 障害物を特定した AI エージェントが、FANUC ロボットに除去を指示します。ロボットが障害物を把持し、ステージ上の回収エリアへ移動させることで道路を開通させます。把持できない障害物を発見した場合は、オペレーターに支援を要請します。 Step 5: 配送再開 復旧が完了すると、AI エージェントは配達車両に配送再開の指示を出します。来場者が止めた配送網が、目の前で復旧されます。 システムアーキテクチャ 設計原則 本システムは以下の原則に基づいて設計されています。 知性が必要な処理はクラウドで実行 — 物体認識、コンテキスト判断、アーム制御指示、車両の再開指示は LLM の推論力を活かしクラウドから発行 物理的な動作実行はエッジで処理 — クラウドからの指示を受けたモーションプランニング（MoveIt 2）やセンサー処理はエッジ PC 上で実行 通信断に耐える設計 — クラウドとの通信が切れた場合、アームは安全停止し、復旧後にクラウドから再開指示を受ける 全体構成 ▲ 知性が必要な処理はクラウド（Amazon Bedrock AgentCore / Amazon Bedrock / Amazon Polly）で実行し、物理的な動作実行はエッジ（ROS 2 / MoveIt 2）で処理。AWS IoT Core がクラウドとエッジをセキュアに接続します。 通信方式 通信経路 プロトコル 理由 FANUC ロボット AI エージェント AWS IoT Core（MQTT 5）Request/Response 低遅延・双方向制御。TLS 相互認証による安全性 配達車両 クラウド AWS IoT Core（Device Shadow） Named Shadow で走行状態・停止/再開・バッテリー・温度などを管理 ダッシュボード UI クラウド AWS IoT Core（MQTT 5）+ HTTPS エージェントの思考過程をリアルタイムに配信 使用する AWS サービス Amazon Bedrock AgentCore Runtime — AI エージェントの実行基盤 Amazon Bedrock AgentCore は、AI エージェントをインフラ管理不要でデプロイ・運用できるマネージドサービスです。本デモでは、AgentCore Runtime 上で動作する AI エージェントが、推論モデルに Amazon Bedrock の Claude Sonnet 4.6 を使用し、ツール呼び出し（ロボット制御 API）、メモリ（調査結果の蓄積）、データ（地図情報）を統合的に管理して、調査計画の立案から復旧指示までを自律的に遂行します。 Amazon Bedrock（Claude 4.5 Haiku）— 視覚認識と推論 Amazon Bedrock 上の Claude 4.5 Haiku が、D435e カメラから取得した画像をもとに周囲の状況を認識します。障害物の有無や周囲の状況を考慮した最適な行動の推論を担当します。 AWS IoT Core — エッジとクラウドの架け橋 AWS IoT Core が、会場内のロボットとクラウド上の AI エージェントをセキュアに接続します。MQTT 5 の Request/Response パターンによるアーム制御と、Device Shadow による配達車両の状態管理を実現します。通信断が発生しても最後の既知状態から安全に復帰できます。 Amazon Polly — AI の声 Amazon Polly により、AI エージェントの判断内容を音声で来場者に伝えます。「状況を確認します」「障害物を探します」「障害物を発見しました」「障害物を取り除きます」といったナレーションがデモの臨場感を高めます。 ハードウェア構成 FANUC CRX-20iA/L 協働ロボット × 2台 FANUC CRX-20iA/L は、可搬質量 20kg、リーチ 1,418mm の協働ロボットです。人と同じ空間で安全に動作します。 項目 仕様 リーチ 1,418 mm 制御装置 R-30iB Mini Plus 安全機能 接触検知による即時停止 ロボットハンド OnRobot 2FG7（ストローク 最大 68mm） カメラ FRAMOS D435e（RGB + Depth） 2台の CRX はそれぞれ担当エリアを持ち、AI エージェントの指示のもとで協調動作します。調査時はアーム先端の FRAMOS D435e カメラで隣接エリアを撮影し、復旧時はロボットハンド（OnRobot 2FG7）で障害物を把持して回収エリアへ移動します。 TurtleBot3 Burger — 配達車両 配送網を走行する自律走行ロボットです。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 ジオラマステージ 3,640mm × 3,640mm の木工ステージ上に、3D プリンタで製作したミニチュアの街を配置します。周回トラックには「オレンジ通り」「ブルー通り」「グリーン通り」「パープル通り」の4つの通りがあり、配達車両の走行ルートとしています。 道路は黒地マット仕上げの上に白線（幅 30mm）を敷設し、配達車両がライントレースで追従します。配送・積荷のポイントには配達車両のための停止線を配置しています。 AI エージェントの意思決定 — 調査し、学習し、適応する 1ターン = 1アクション AI エージェントは毎ターン、以下のアクションから1つを選択して実行します。 アクション 内容 調査 FANUC ロボットの FRAMOS D435e カメラで対象エリアを調査 障害物除去 FANUC ロボットで障害物を把持し、回収エリアへ移動 エージェントは MAP の構造（道路レイアウト）とスタート/ゴール位置は既知ですが、障害物の位置は一切知りません。 調査の選択 調査を行うかどうかは、AI エージェントが自律的に判断します。配達車両が障害物を検知した後、AI エージェントは FANUC ロボットのカメラで状況を確認し、把持可能な障害物かどうかを見極めてから行動を計画します。これは事前にプログラムされた手順ではなく、状況に応じた AI エージェントによる自律的な判断です。 障害物除去戦略の判断 障害物を発見した AI エージェントは、カメラ画像から障害物の形状・サイズを認識し、ロボットハンドで把持可能かを判断します。把持可能と判断すれば、ロボットに除去を指示し道路を開通させます。把持が困難と判断した場合は、オペレーターに支援を要請します。 まとめ 本ブログでは、AWS Summit Japan 2026 の Physical AI ブースで展示するデモを通じて、AI エージェントが現実世界で自律的にオペレーションを遂行する仕組みをご紹介しました。 このデモのポイントは以下の通りです。 想定外への対応力 — 事前に定義されたシナリオではなく、予測不能な状況に AI が自律的に対応する 調査から解決まで一気通貫 — 障害の検知・調査・判断・復旧までを AI エージェントが自律的に完走する リアルタイム可視化 — ダッシュボードにより、エージェントの思考と行動が常に可視化される クラウド AI × ロボットの協調 — クラウド上の AI エージェントが判断し、現場のロボットが実行する新しいオペレーションモデル Physical AI は、AI が「考える」だけでなく「行動する」時代の到来を示しています。AWS のクラウドサービスとロボティクスの組み合わせにより、この未来は今まさに実現可能になっています。 体験機会のご案内 Physical AI デモの実物は、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースでご覧いただけます。AI エージェントが現実世界で自律的に問題を解決する様子を、ぜひ目の前で体験してください。 AWS を活用した Physical AI ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 いよいよ、今週 6/25(木)、26(金) で AWS Summit Japan 2026 が幕張メッセで開催されます。私もブース対応や登壇を行いますので、現地で私を見たらぜひお声かけください。Builders Fair のコーナーで、VR ゴーグルと体にセンサーをつけて計測するパデルフォームのコーチングシステムを展示しています！詳細は こちら 。私が所属する Retail CPG でも Retail エリアがあり、私はスマートグラス、音声 AI を使った店舗業務改善のデモも担当しております。Retailブースエリアの紹介もこちらの ブログ を参照ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月15日週の主要なアップデート 6/15(月) AWS WAF が AI トラフィック収益化機能を発表 AWS WAF が Bot Control 機能の一部として AI traffic monetization を発表しました。この機能により、コンテンツ所有者やパブリッシャーは、AI ボットやエージェントがコンテンツや API にアクセスする際に、エッジで直接価格設定、計測、決済を行うことができます。x402 オープンプロトコルを使用した machine-to-machine 決済により、AI エージェントは自律的に支払いを行い、コンテンツにアクセスできます。決済は Coinbase の x402 Facilitator を通じて USDC (stablecoin) で処理され、CloudFront のすべてのエッジロケーションで利用可能です。追加料金はなく、標準の AWS WAF 料金のみが適用されます。 AWS DevOps Agent がカスタム SRE エージェントと MCP/A2A プロトコルに対応 AWS DevOps Agent は、カスタム SRE エージェント、bring-your-own sub-agents、MCP (Model Context Protocol) および A2A (Agent-to-Agent) プロトコル経由のヘッドレスアクセスに対応しました。これにより、チームは定期的な SRE ワークフローの自動化、他のエージェントとの接続による DevOps Agent の拡張、Kiro、Claude、その他のコーディングアシスタントなど既存ツールからの機能アクセスが可能になります。カスタム SRE エージェントでは、Agent Space 内でスケジュール実行されるエージェントを作成できます。また、チャット機能の強化、カスタマー定義ルールによるインシデントスキップ、メモリーと Git 管理スキルによる知識強化、タスク品質追跡用の人手ラベリングとカスタマーダッシュボードが追加されました。こちらは、5 つの新リージョンで追加対応されています。 Amazon CloudWatch Log Analytics を発表 Amazon CloudWatch は Log Analytics という統合コンソール体験を提供開始しました。これは CloudWatch Logs Insights (ログクエリと分析)、Live Tail (リアルタイムログストリーミング)、Contributor Insights (トップコントリビューター分析) を 1 つの画面に統合したものです。複数のタブで異なるクエリを同時実行でき、パターン分析、パラメータ付き保存クエリ、ファセット、自然言語クエリ生成、ビジュアライゼーションなどの既存機能もすべて利用できます。Log Analytics はデフォルトの体験となり、すべての商用 AWS リージョンで利用可能です。料金は基盤となる各機能 (Logs Insights クエリ、Live Tail、Contributor Insights) と同じです。 Amazon Bedrock AgentCore Memory が long-term memory に厳密に一貫したメタデータをサポート Amazon Bedrock AgentCore Memory の long-term memory に、メタデータの抽出タイプとして STRICTLY_CONSISTENT が追加されました。これにより、アプリケーションから直接設定したメタデータ値が LLM の推論を経ることなく、そのまま long-term memory レコードに記録されるようになります。この機能は、部署別のスコープ検索、コンプライアンス境界の管理、マルチテナント環境でのテナントごとの独立処理を実現します。戦略ごとに最大 3 個の STRICTLY_CONSISTENT キーを設定でき、semantic、user preference、episodic 戦略で利用可能です。 AWS Transform が技術負債の自動検出と修復を行う continuous modernization 機能を発表 AWS Transform は、エンタープライズのソフトウェアポートフォリオ全体で技術負債を自動的に検出・優先順位付け・修復する continuous modernization 機能 (プレビュー) を発表しました。数千のリポジトリを対象に、古い依存関係、非推奨フレームワーク、セキュリティ脆弱性を自動で修復し、プルリクエストを自動生成します。料金は $0.035 / エージェント分で、US East (N. Virginia) と Europe (Frankfurt) で利用可能です。GitHub、GitLab、Bitbucket と統合し、Kiro、Claude Code、Cursor などの agentic IDE から利用できます。 6/16(火) Amazon Quick が Adobe、Figma、WhatsApp など 16 の新しいコネクタで統合を拡大 Amazon Quick は 16 の新しいツールとの統合を開始しました。これにより、チームはデータ、分析、デザイン、コミュニケーションアプリからのインサイトに基づいて、コンテキストを切り替えることなくアクションを実行できるようになります。新しいコネクタには Adobe、Figma、WhatsApp、Snowflake などが含まれ、生産性、デザイン、分析、データインフラ、金融インテリジェンス、コマース、コミュニケーション領域をカバーします。チームは数分で新しいツールをワークスペースに追加し、Quick Flows、Chat、Spaces で既存の統合と組み合わせて利用できます。 AWS Blocks、アプリケーションバックエンドを構成するオープンソースフレームワーク (プレビュー) を発表 AWS は、インフラツールの学習を不要にするオープンソース TypeScript フレームワーク AWS Blocks のパブリックプレビューを発表しました。ローカル環境では AWS アカウント不要で Postgres、認証、リアルタイムメッセージングが動作し、本番デプロイ時もコード変更なしで AWS サービス上で実行できます。開発者は単一セッション内でデータベーステーブル、ユーザー認証、AI エージェント、ファイルアップロード、バックグラウンドジョブを追加し、フルスタックをローカルでテストした後、準備が整った段階で AWS にデプロイできます。料金は AWS Blocks 自体に追加費用はなく、使用した AWS サービスの料金のみが発生します。 Amazon S3 Vectors が類似性検索で最大 10,000 件の結果返却に対応 Amazon S3 Vectors の QueryVectors API が、1 回のクエリで最大 10,000 件の類似性検索結果を返却できるようになりました。これは以前の制限値 100 件から 100 倍の増加です。結果は複数ページに分割して返却され、最初のページから順次処理を開始できます。クエリごとに最初の 512 KB のデータ返却は無料で、超過分には $0.01/GB のデータ返却料金が適用されます。この改善により、リランキング、集約、重複排除などのマルチステージ検索パイプラインで、より包括的な候補セットを取得できるようになります。 6/17(水) Oracle Database@AWS が Oracle Autonomous AI Database Serverless に対応 Oracle Database@AWS が Oracle Autonomous AI Database Serverless (ADB-S) に対応しました。ADB-S は、Exadata インフラや VM クラスターのプロビジョニングが不要で、AWS Management Console、CLI、API から直接データベースを作成できる完全マネージド型 Oracle データベースサービスです。コンピュートとストレージが独立してスケールし、AI Transaction Processing、AI Lakehouse、AI JSON Database、Oracle APEX の 4 つのワークロードタイプに対応します。AWS Marketplace の公開オファーおよびプライベートオファーで利用可能で、BYOL (Bring Your Own License) と License Included の両方をサポートします。現時点では US East (N. Virginia) と US West (Oregon) リージョンで提供されています。 AWS Secrets Manager が Agent Toolkit for AWS に安全なシークレット処理スキルを導入 AWS Secrets Manager は、Agent Toolkit for AWS の aws-core プラグインの一部として、secret safety skill を提供開始しました。このスキルにより、開発者は AI コーディングエージェントのワークフロー内でシークレット値を LLM のコンテキストやセッションログに公開することなく使用できます。2 層アプローチ（スキルガイダンスと PreToolUse フック）により、プレーンテキストのシークレットがモデルコンテキスト、セッションログ、エージェントメモリに一切表示されなくなります。Claude Code、Codex、Cursor などのエージェントで利用可能で、Secrets Manager が提供されているすべての AWS リージョンで今すぐ使用できます。 Amazon Bedrock AgentCore harness が一般提供開始 Amazon Bedrock AgentCore のマネージドエージェントハーネス (harness) が一般提供を開始しました。エージェント開発において最も時間がかかるオーケストレーションループ、実行環境、ツール統合、メモリ管理を設定ファイルだけで定義できるようになり、数分でプロダクション対応のエージェントを構築できます。モデルはセッション途中でも切り替え可能で、ツールやスキルの追加も設定変更のみで対応します。harness 自体に追加料金はなく、利用した CPU やメモリなどのリソース分のみ課金されます。 Amazon Bedrock AgentCore のポリシーで Bedrock Guardrails をサポート AWS は Amazon Bedrock AgentCore のポリシー機能で Bedrock Guardrails のサポートを発表しました。これにより、本番環境で AI エージェントをスケールする際に、より深いセキュリティと安全性の制御が可能になります。AgentCore ポリシーは、AI エージェントが実行を許可されるアクションを制御する認可機能です。Guardrails は、プロンプトインジェクション攻撃や機密データの露出を含む、AI エージェントワークロードにおける主要なセキュリティおよび安全性リスクに対する防御を提供します。Guardrails は、許可されたすべてのエージェントアクションの出力と、ゲートウェイターゲット（ツール、エージェント、モデル）へのすべての呼び出しの入力をリアルタイムで評価し、ダウンストリームシステムに到達する前にプロンプトインジェクション攻撃、有害コンテンツ、機密情報の露出を検出してブロックします。 AWS Glue Data Catalog がビジネスコンテキストとセマンティック検索をサポート（プレビュー） AWS Glue Data Catalog に、ビジネスコンテキストの付与とセマンティック検索機能がプレビューとして追加されました。Glossary terms、custom metadata fields (Forms)、Skill assets の 3 つの仕組みでテーブルやカラムに業務的な意味を付与でき、新しい Search API で semantic meaning による検索が可能になります。Claude Code などの MCP 互換エージェントは、Agent Toolkit for AWS の aws-data-analytics plugin を使うことで、ほぼセットアップなしで Data Catalog にアクセスできます。現在、US East (N. Virginia、Ohio)、US West (Oregon)、Europe (Ireland) の 4 リージョンでプレビュー提供中です。 Amazon Bedrock AgentCore に継続的改善機能を追加、プロダクション環境のエージェントを最適化 AWS は Amazon Bedrock AgentCore に新しい最適化機能を追加し、プロダクション環境のトレースからエージェントを継続的に改善できるようになりました。この機能は「サイレント障害」（エラーを出さないが実際には失敗している動作）を検出し、データに基づいた修正案を生成し、統計的に検証します。Failure insights、Intent insights、Trajectory insights の 3 つの分析機能は本日 13 リージョンでプレビュー提供開始、Batch evaluation、Recommendations、A/B testing は本日 14 リージョンで一般提供開始されました。AgentCore Runtime、AWS Lambda、Amazon EKS、非 AWS 環境など、実行環境を問わず利用できます。 AWS DevOps Agent がリリース管理機能を追加 (プレビュー) AWS DevOps Agent がリリース管理機能のプレビューを開始しました。この機能は、コード変更のリリース準備状況を評価し、自律的なリリーステストを実行することで、本番環境へのコードデプロイを安全に行えるようにします。リリース準備レビューでは、内部標準からの逸脱、依存関係の影響、アクセス制御をチェックし、決定論的証明を使用してインフラ変更が AWS Well-Architected のベストプラクティスに準拠しているか検証します。リリーステストでは、Web および API ベースのアプリケーション向けにテスト計画を生成・実行し、回帰、UX の問題、統合の失敗を検出します。プレビュー期間中は US East (N. Virginia) リージョンで追加費用なしで利用できます。 6/18(木) Amazon GameLift Servers がコンテナフリートの新機能を追加 Amazon GameLift Servers は、コンテナフリートに 2 つの重要な機能強化を実施しました。1 つ目は、コンテナグループ定義で Linux capabilities をカスタマイズできるようになり、NET_RAW や SYS_PTRACE といった特殊な権限を付与できます。2 つ目は、新しい Server SDK API である ListContainersNetworkInfo() を追加し、同一インスタンス上で実行される全コンテナのネットワーク情報 (コンテナ名、ID、ローカル IP アドレス、コンテナグループタイプ) を取得できるようになりました。これにより、ゲームサーバーとメトリクス収集コンテナ、ログエージェント、キャッシュシステムなどの補助サービス間の自動サービス検出と通信が簡素化されます。 AWS Compute Optimizer が EBS ボリューム推奨で IOPS とスループットスパイクの可視性を強化 AWS Compute Optimizer は、Amazon EBS ボリュームのライトサイジング推奨を提供する際に、IOPS とスループットのスパイクに対する可視性を向上させました。新たに VolumeIOPSExceededCheck と VolumeThroughputExceededCheck という 2 つの CloudWatch メトリクスを分析対象に追加し、ワークロードがプロビジョニングされたパフォーマンスを超えて IOPS やスループットを要求したかどうかを 1 分単位で検出できるようになりました。この機能により、バースト性の高いワークロードにおいて、コストとパフォーマンスのバランスを取ったライトサイジング判断が可能になります。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。