本ブログは 2026 年 6 月 24 日に公開された AWS Blog “ Restrict AWS Management Console access to expected networks with sign-in resource-based policies and RCPs ” を翻訳したものです。 Amazon Web Services (AWS) は 2026 年 6 月 16 日に、 リソースベースポリシー と リソースコントロールポリシー (RCP) を AWS サインイン でサポートすることを発表しました。リソースベースポリシーと RCP を使用すると、 AWS マネジメントコンソール へのサインインと aws login CLI セッションへのアクセスを、想定するネットワーク、オンプレミスのデータセンターネットワーク、およびお客様の Amazon Virtual Private Cloud (Amazon VPC) からのリクエストに制限できます。 サインインのリソースベースポリシーと RCP は、いくつかのセキュリティ目標に対応します。具体的には、コンソールサインインを企業ネットワークに制限すること、コンソールにサインインできるプリンシパルを限定すること、そして AWS Organizations の組織全体にわたって一貫した ネットワーク境界制御 を適用することです。 この記事では、一般的なユースケースを取り上げます。規制コンプライアンスのために、ある金融サービス企業がコンソールアクセスを企業ネットワークに制限するというケースです。単一アカウントに対してサインインのリソースベースポリシーを使用してこれを実装する方法、 AWS CloudTrail で制御を検証する方法、そしてこれらのポリシーが AWS Management Console Private Access やより広範な AWS データ境界フレームワーク とどのように統合されるかを説明します。 コンソールサインインアクセスを企業ネットワークに制限する ある金融サービス企業が、 AWS マネジメントコンソール へのサインインを企業ネットワークから行うことを求めているとします。この企業には次の要件があります。 ユーザーは、企業 VPN、オフィスネットワーク、またはお客様の VPC からのみコンソールにサインインする 個人ネットワーク、公衆 Wi-Fi、その他の想定外の場所からのサインイン試行は拒否しなければならない ロックアウトを防ぐため、指定したプリンシパルはどのネットワークからでもアクセスを保持できるようにする コンプライアンスの証跡として、すべてのサインイン試行 (許可および拒否) を CloudTrail に記録しなければならない 以下のステップでは、単一アカウントでこれらの要件を適用するリソースベースポリシーを作成する方法を紹介します。 前提条件 AWS Command Line Interface (AWS CLI) が最新バージョンでインストールされ、設定されていること サインインのリソースポリシーを管理する権限。AWS マネージドポリシーの AWSSignInResourcePolicyManagement をアタッチするか、各プリンシパルに次のアクションへの権限を付与します。 リソース許可ステートメントの管理: signin:PutResourcePermissionStatement , signin:DeleteResourcePermissionStatement , signin:ListResourcePermissionStatements , signin:GetResourcePolicy. コンソール認可の管理: signin:PutConsoleAuthorizationConfiguration , signin:GetConsoleAuthorizationConfiguration , signin:DeleteConsoleAuthorizationConfiguration 特定の企業ネットワーク: IP CIDR 範囲または VPC ID 除外する指定プリンシパルの Amazon リソースネーム (ARN)。これにより、ネットワーク条件が変わってもアクセスを保持できます 注: AWS サインインアクションの完全なリストについては、サービス認可リファレンスの AWS Signin のアクション、リソース、および条件キー を参照してください。 ステップ 1: リソース許可ステートメントを作成する ほとんどのリソースベースポリシーでは、作成者がポリシードキュメント全体 (JSON ステートメント) を入力する必要があります。サインインのリソース許可ステートメントは異なります。パラメータを指定すると、AWS サインインがポリシーを生成します。 次のコマンドでは、企業 IP 範囲、VPC、除外プリンシパルをパラメータとして指定します。AWS サインインはこれらのパラメータを使用して、コンソールサインインをそれらのネットワークに制限しつつ、除外プリンシパルがどのネットワークからでもサインインできるようにするポリシーを生成します。お客様が制御するのはパラメータの値であり、ポリシーの構造ではありません。生成されたポリシーは、 get-resource-policy コマンドでいつでも確認できます。 注: リソース許可ステートメントは、ステップ 2 でコンソール認可を有効にするまで効果を発揮しません。そのため、効果が発生する前に完全なポリシーを確認できます。なお、書き込み操作は us-east-1 を対象にする必要があります。 リソース許可ステートメントを作成するには、次の手順を実行します。 1. ターミナルを開き、最新の AWS CLI がインストールされていることを確認します。 2. 次のコマンドを実行し、プレースホルダー値 <my-vpc> 、 <my-vpc-region> 、 <my-corporate-cidr> 、 <excluded-IAM-principal-arn> を、お客様の具体的な設定に置き換えます。 aws signin put-resource-permission-statement \ --source-vpc <my-vpc> \ --requested-region <my-vpc-region> \ --source-ip <my-corporate-cidr> \ --excluded-principal <excluded-IAM-principal-arn> \ --region us-east-1 3. 出力に statementId があることを確認して、コマンドが成功したか検証します。 出力例: { "statementId":"b2HfHli9qCF1P4eGNll13CrZtusXlcPxxVBqz2aYLjlAcWtWQHP6Hg0" } 4. get-resource-policy コマンドを実行して、完全なリソースベースポリシーを確認します。 aws signin get-resource-policy 出力例: { "signinResourceBasedPolicy": { "Version": "2012-10-17", "Statement": [ { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]}, "StringEquals": {"aws:ResourceAccount": ["<account-id>"]}, "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]}, "StringEquals": {"aws:ResourceAccount": ["<account-id>"]}, "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]}, "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]}, "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]} } } ] } } 生成されたポリシーには 4 つのステートメントが含まれ、2 つのペアにグループ化されています。最初のペアはネットワークソースによってアクセスを制限し、企業 IP 範囲 (<my-corporate-cidr>) または VPC (<my-vpc>) の外部からリクエストを行うプリンシパルを拒否します。2 番目のペアは、VPC がターゲットにできる AWS リージョンを制限し、 <my-vpc> から発信されたリクエストを、 <my-vpc-region> に向けられたものでない限り拒否します。このリージョンへのバインディングが必要なのは、VPC ID が単一リージョン内でのみ一意であるためです。 AWS サインインはこれらのポリシーを 2 つのフェーズ、つまり認証前と認証後で評価します。認証後の評価は、コンソールセッションが新しい認証情報をリクエストするたびに繰り返されます。各ペアの中で、1 つのステートメントは認証前フェーズをカバーし、もう 1 つは認証後フェーズをカバーします。 認証前のステートメントは signin:Authenticate アクションを評価します。このフェーズではプリンシパルがまだ認証されていないため、ステートメントは signin:PrincipalArn 条件キーを使用して除外プリンシパルを免除します。このキーはすべてのプリンシパルタイプ (ルートユーザー、 AWS Identity and Access Management (IAM) ユーザー、フェデレーションユーザー、ロール) をサポートします。 認証後のステートメントは signin:AuthorizeOAuth2Access および signin:CreateOAuth2Token アクションを評価します。AWS サインインは、コンソールセッションを確立するトークンを発行する認証後に、これらのアクションを評価します。これらのアクションは signin:PrincipalArn キーをサポートしません。代わりに、認証済みのプリンシパルに解決される aws:PrincipalArn を使用します。 aws:ResourceAccount の値は受信側のアカウント ID です。AWS サインインが呼び出し元の認証情報から自動的に取得するため、お客様が自分で設定する必要はありません。サポートされるアクションと条件キーの完全なリスト (各フェーズと各プリンシパルタイプにどのキーが適用されるかを含む) については、 Controlling console access with resource-based policies and resource control policies および AWS Sign-In condition keys reference を参照してください。 ステップ 2: アカウントのサインインポリシー適用を有効にする このステップでは、ステップ 1 で作成したポリシーの適用を有効にします。このステップを実行するまで、ステップ 1 で作成したリソース許可ステートメントは効果を発揮しません。 5. 次のコマンドを使用して、サインインポリシーの適用を有効にします。 aws signin put-console-authorization-configuration \ --target-id <account-id> \ --region us-east-1 6. 出力に "consoleAuthorizationEnabled": true があることを確認して、コマンドが成功したか検証します。 出力例: { "Output": { "consoleAuthorizationEnabled": true, "scope": "ACCOUNT", "targetId": "<account-id>" } } 7. 以下のように get-console-authorization-configuration コマンドを実行して、設定を検証することもできます。 aws signin get-console-authorization-configuration \ --target-id <account-id> \ --region us-east-1 8. 適用を無効にしたり個別のステートメントを削除したりするには、 delete-console-authorization-configuration または delete-resource-permission-statement を使用します。詳細については、 AWS サインイン ユーザーガイド の Controlling console access with resource-based policies and resource control policies を参照してください。 実装の検証 適用が有効になったので、サインイン試行はリソースベースポリシーに照らして評価されます。さまざまなネットワーク条件からサインインをテストして、動作を検証しましょう。 シナリオ 1: 企業ネットワークからの許可されたサインイン 許可された企業 IP 範囲または VPC からサインインするプリンシパルは、正常にサインインできます。 CloudTrail イベント には ConsoleLogin:Success が表示されます。 コンソールサインイン成功時の CloudTrail イベント詳細の例: { "userIdentity": { "type": "AssumedRole", "principalId": "AROAEXAMPLEID:Dev1", "arn": "arn:aws:sts::123456789123:assumed-role/Developer/Dev1", "accountId": "123456789123" }, "eventTime": "2026-06-09T19:20:38Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.100", "responseElements": { "ConsoleLogin": "Success" }, "eventID": "dd004e78-6447-4f56-8d2d-a795da66f598", "readOnly": false, "eventType": "AwsConsoleSignIn", "managementEvent": true, "recipientAccountId": "123456789123", "eventCategory": "Management" } シナリオ 2: 想定外のネットワークからの拒否されたサインイン 許可された IP アドレス範囲、またはソース VPC にアタッチされた VPC エンドポイント以外のネットワークからサインインするプリンシパルはブロックされます。CloudTrail イベントには ConsoleLogin: Failure が表示され、拒否の原因となったポリシーを特定するエラーメッセージが含まれます。 コンソールサインイン失敗時の CloudTrail イベント詳細の例: { "userIdentity": { "type": "IAMUser", "accountId": "123456789123", "accessKeyId": "", "userName": "Dev1" }, "eventTime": "2026-06-09T19:20:38Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "198.51.100.76", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36", "errorCode": "AccessDenied", "errorMessage": "Authorization denied because of a resource-based policy", "requestParameters": null, "responseElements": { "ConsoleLogin": "Failure" }, "eventID": "d88a7543-ae89-4186-b1b6-d3116413f2ee", "readOnly": false, "eventType": "AwsConsoleSignIn", "managementEvent": true, "recipientAccountId": "123456789123", "eventCategory": "Management" } エラーメッセージフィールドには、拒否の原因となったポリシータイプが表示されます。 "Authorization denied because of a resource-based policy" (リソースベースポリシーにより認可が拒否されました)。 RCP による大規模展開 上記のステップでは、サインインのリソースベースポリシーを単一アカウントに適用します。多数のアカウントを管理する組織にとっては、RCP がより優れた方法です。RCP は AWS Organizations の組織、OU、またはアカウントレベルでアタッチでき、対象範囲内のすべてのアカウントに自動的に適用されます。RCP の例については、 こちら を参照してください。 RCP によってコンソールへのサインインが拒否された場合、エラーメッセージフィールドには拒否が "Authorization denied because of a resource control policy" (リソースコントロールポリシーにより認可が拒否されました) と表示されます。 Console Private Access とデータ境界による拡張 作成したサインインのリソースベースポリシーは、どのネットワークがお客様のアカウントのサインインフローに到達できるかを制御します。 AWS Management Console Private Access は補完的な制御を追加します。具体的には、お客様のネットワーク内から、コンソールアクセスを既知の AWS アカウントのセットに限定し、想定外の AWS アカウントへのサインインを防ぎます。 これらの機能を組み合わせることで、コンソールアクセスのデータ境界の形成に役立ちます。 ネットワーク境界: サインインのリソースベースポリシーと RCP は、コンソールサインインを想定するネットワーク (企業 IP 範囲、VPC) に制限します アイデンティティ境界: サインインのリソースベースポリシーと RCP は、信頼できるアイデンティティのみがコンソールにサインインできることを保証します。コンソール VPC エンドポイントポリシーとサインイン VPC エンドポイントポリシーは、信頼できるアイデンティティのみがお客様の VPC からコンソールを使用できることを保証します リソース境界: サインイン VPC エンドポイントポリシーとコンソール VPC エンドポイントポリシーは、お客様のネットワークからどの AWS アカウントに到達できるかを制限します この記事の制御はコンソールアクセスに焦点を当てています。これらの境界を他の AWS サービスやより広範な実装シナリオに拡張するには、 Data perimeter policy examples リポジトリと Data Perimeters Blog Post Series を参照してください。 まとめ サインインのリソースベースポリシーと RCP を使用することで、AWS マネジメントコンソールへのアクセスを想定するネットワークに制限できます。これらの制御は、すべての AWS 商用リージョンで追加料金なしで利用できます。 使い始めるには、 AWS サインイン ユーザーガイド を参照してください。組織全体での適用については、AWS Organizations ユーザーガイドの Resource control policies を参照してください。 Swara Gandhi Swara Gandhi は、AWS Identity Solutions チームのシニアソリューションアーキテクトです。安全でスケーラブルなエンドツーエンドのアイデンティティソリューションの構築に取り組んでいます。アイデンティティ、セキュリティ、クラウドに関するあらゆることに情熱を注いでいます。 Rishi Tripathy Rishi は、AWS Identity and Access Management (IAM) チームのプリンシパルプロダクトマネージャーです。企業が大規模に AWS 環境を保護するのに役立つアクセス制御メカニズムに焦点を当てています。導入が簡単で誤設定しにくいセキュリティプリミティブの構築に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は「 Introducing Agent Focus – Kiro 」を翻訳したものです。 開発者が AI と協働する方法は変わりつつあります。モデルは今や複数ステップの作業を計画し実行できるようになり、より多くの開発者が、自分で一行ずつコードを打ったり直接編集したりするのではなく、エージェントを導くことに一日を費やすようになっています。 IDE は別の場面のために作られたものです。IDE はコードを中心に据えますが、それはまさに「自分で編集しているとき」に欲しいものです。しかし、主な仕事がエージェントに実行させる作業を定義し、洗練し、方向づけることであるとき、それが必ずしも欲しいものとは限りません。 2026 年 6 月 25 日、私たちは Agent Focus を発表します。これは Kiro IDE における実験的な新しいビューで、エージェントとのやり取りを前面に押し出すものです。チャットファーストな働き方の基盤を築きます。やりたいことを記述し、会話を通じて洗練させ、作業を開始し、エージェントが進める様子を確認する——という流れです。これまでの IDE 体験がなくなるわけではありません。Agent Focus はそれと並んで存在し、いつでも両者を行き来できます。 Agent Focus でできること このビューの中では、複数のワークスペースをまたいで、独立して並行に動く複数のセッションを立ち上げられます。エージェントとチャットしてコードを書いたり、アイデアを探ったり、問題を解いたり——あるいはもっと構造が必要なときには仕様（spec）を定義・洗練したりできます。各セッションで何が起きているかを高い視点で把握し、対応が必要になったら介入する。じっくり見る必要がある作業のときには、コード中心のビューに戻って直接編集できます。 このビューは 3 つのパネルで構成されています。 エージェントパネル（左）: 新しいセッションを作成し、ワークスペースごとにグループ化して閲覧でき、各セッションの状態——作業中、入力待ち（ブロック中）、一時停止中——を一目で確認できます。終わったものはクリアできます。 チャットパネル（中央）: 刷新された新しいチャット体験。エージェントを導き、意図を洗練させ、作業が進む様子を見守れます。ファイルの変更はインラインのコード差分として表示されるので、ビューを切り替えることなく追えます。 補助パネル（右）: 必要になるまで非表示。エージェントが変更されたファイルや仕様のサマリーを示すために表示することもあれば、じっくり見たいときに自分で開くこともできます。 一部の機能はまだこのビューにネイティブ実装されていないため、Agent Focus は設定、powers、skills、MCP、ターミナル、完全な git、直接のファイル編集といったものについて、IDE へ戻る明確な経路を保っています。 これは実験であり、慣れ親しんだ IDE はそのまま残ります Agent Focus は実験的なリリースです。ぜひ試して、何がうまくいき、何がうまくいかないかを、インターフェース内の「Report issue」ボタン、 GitHub の issue、あるいは Discord で教えてください。ただし、中核となる IDE 体験は変わりません。IDE は引き続きデフォルトであり、今日あなたが行っていることはすべて今までどおりに動作し、好きなだけそこにとどまれます。Agent Focus は、私たちが早い段階であなたの手に委ねる「もう一つの働き方」です。 切り替え方法 切り替えは手間がかからないように作られています。Agent Focus はウィンドウ右上に常に 1 クリックで届く場所にあり、「Agent Focus」とラベル付けされています。戻りたいときは、同じ場所にあるコントロールが「IDE」とラベル付けされています。いつでも、どちらの方向にも、自分の作業位置を失うことなく行き来できます。 入手方法 Agent Focus は最新版の Kiro 1.0 に同梱されています。 Kiro ダウンロードページ から Kiro をアップデートし、新しいビルドになると Agent Focus がウィンドウ右上に表示されます。 Agent Focus は、Kiro におけるチャットファーストでエージェント中心の構築スタイルへの私たちの第一歩であり、ここから成長していきます。その最良の形は、あなたが実際にどう使うかによって形づくられるものです。 Kiro をダウンロード し、右上から Agent Focus を開き、いくつかセッションを動かして、気づいたことを私たちに教えてください。

本記事は「 One Task, Two Providers: Coordinating Changes Across GitLab and GitHub in one session 」を翻訳したものです。 Kiro Web は、既存の GitHub サポートに加えて、 GitLab でも動作する ようになりました。より興味深いのは、コードが GitLab と GitHub の両方にまたがって存在する場合に何が起きるかです。両方からリポジトリを同じセッションに追加し、単一の変更を記述すれば、Kiro がそれを両方にわたって実行し、一方にはマージリクエスト（MR）を、もう一方にはプルリクエスト（PR）を開いてくれます。これは、コードが 1 つのきれいな場所に収まっていないときに意味を持ちます。 2 つの場所に存在するコード 多くのチームはプロバイダーをまたいで分かれており、たいていそれには正当な理由があります。オープンソースの SDK はコミュニティが見つけられるように GitHub に置かれ、それが通信するサービスは GitLab 上にプライベートのまま残されている。あるいは買収によって、組織の半分が一方のプロバイダーに、もう半分が別のプロバイダーに分かれてしまった。あるいはフロントエンドとバックエンドのチームが、何年も前にたまたま別々のツールに落ち着いただけ、ということもあります。理由が何であれ、そのコストは変更が両方にまたがった瞬間に現れます。1 つの論理的な更新が、2 つのコンテキストで 1 つのプルリクエストと 1 つのマージリクエストになり、ステップを忘れて両者が同期からずれてしまう機会が 2 回生じるのです。 小さな例 ここで使うセットアップを示します。本物の代わりとして、あえてシンプルなものにしています。その場所に、あなたの実際のサービスと SDK を思い浮かべてください——数千行、本物のビジネスロジック、本物の利用者がいるものを。 GitLab 上のプライベートサービスがあるとします。 そして、 GitHub 上のパブリック SDK が、そのサービスをラップしています。 email フィールドをエンドツーエンドで追加したいとします。サーバー側の変更は GitLab に属し、SDK 側の変更は GitHub に属します。これは、2 つのリポジトリ、2 つのプロバイダーにまたがって、変更を加えないといけません。 1 つのプロンプト、両方のリポジトリ GitLab と GitHub の両方をすでに接続した状態で、セッションを開始し、両方のリポジトリ（GitLab の user-service と GitHub の user-sdk ）をアタッチします。そして、変更をシンプルな言葉で記述します。 両方のリポジトリがセッション内にあるため、Kiro はそれらを無関係な 2 つのタスクとして扱うのではなく、一緒に推論します。 隔離されたサンドボックスの中で作業し、両方のリポジトリを探索し、それぞれの側が何を必要とするかを把握し、変更を行います。サービスではレコードとレスポンスに email を追加し、SDK では User 型と使用例を更新します。各リポジトリにフィーチャーブランチを作成し、明確なメッセージでコミットします。 完了すると、2つの変更が待っています。サービス用の GitLab 上のマージリクエスト は以下のようになります。 そして、SDK 用の GitHub 上のプルリクエスト は以下のようになります。 それぞれが、何が変わったかと、そのアプローチの説明を伴っています。あなたは各変更を、それぞれのホームプロバイダー上で、チームがすでに使っているまさにそのワークフローでレビューしてマージします。レビュープロセスについては何も変わりません。ただ、クロスリポジトリの調整作業を自分でやらなくて済んだ、というだけです。 まとめ プロバイダーをまたぐ分割は、しばしば現実的で、維持する価値があります——パブリック対プライベート、あるチーム対別のチーム。維持する価値がないのは、1 つの変更を両方にわたって整合させるための手作業の労力です。Kiro Web に GitLab と GitHub を接続すれば、1 つのプロンプトが変更をエンドツーエンドで一貫させ、それでもあなたはすでに信頼しているプロバイダー上で、きれいな MR と PR をレビューできます。 Kiro Web で GitLab と GitHub を接続し、両方にまたがる変更を試してみてください。Kiro Web は app.kiro.dev で、Pro・Pro+・Power のサブスクライバー向けにプレビュー提供中です。さらに詳しくは GitLab ガイド をご覧になり、次に何がリリースされるかを知るには Kiro Web の changelog をフォローしてください。

本ブログは、2026 年 6 月 23 日に Tom Lawlor によって執筆された「 A new way to keep your AWS Certification current 」を翻訳したものです。 AWS 認定は、雇用主、クライアント、チームメイトに対してあなたの能力を証明するものです。クラウドと AI は急速に進化しているため、認定を維持するには、今あなたの役割にとって重要なことに対してスキルを磨き、常に最新の状態を保つ必要があります。 2026 年 6 月 23 日より、今までのように認定試験を再受験する代わりに、 AWS Skill Builder 上の厳選されたトレーニングとハンズオンラボを完了することで、AWS 認定を 1 年間延長して維持できるようになりました。 仕組み 認定の有効期限まで 90 日以内になると、あなたは今回追加された再認定方法の対象となります。再認定までの流れは以下のとおりです。 認定を選択する : AWS Skill Builder で 「詳しく見る > スキルを検証する > 再認定」 に移動し、維持したい認定を選択します。 トレーニングを完了する : 認定ドメインに関連する、進化し続けるトピックをカバーする厳選されたデジタルコースとハンズオンラボに取り組みます。 認定が自動的に延長される : 要件を満たすと、完了日から1年間、認定が延長されます。これは AWS 認定アカウントに即座に反映されます。 アソシエイトレベルの認定の場合、少なくとも 1 つの実践的なアクティビティを含めて 500 ポイントを獲得する必要があります。プロフェッショナルレベルの認定の場合、少なくとも 2 つの実践的なアクティビティを含め、700 ポイントが必要です。認定の有効期限が切れる前に、自分のペースですべてを完了してください。テストセンターの予約も、試験の受験も不要です。 単なる再認定ではなく、スキルを最新に保つトレーニング コースとラボは、AWS サービスを開発しているのと同じ AWS のエキスパートによって構築されています。何年も前に学んだ内容の焼き直しではなく、今まさにクラウドがどのように進化しているかを反映したトピックをカバーしています。実践的なアクティビティ (ハンズオン) では、実際の AWS 環境で構築、設定、トラブルシューティングを行うリアルなシナリオに取り組みます。認定の維持に費やす時間は、仕事のスキルを向上させる時間でもあるのです。 開始時のサポート対象 本再認定オプションは、以下の認定を対象にオープンベータとして 2026 年 6 月 23 日より利用可能です。 AWS Certified Solutions Architect – Associate AWS Certified Developer – Associate AWS Certified CloudOps Engineer – Associate (AWS Certified SysOps Administrator – Associate の維持に利用可能です) AWS Certified DevOps Engineer – Professional AWS Certified Solutions Architect – Professional 今年後半には、AWS Certified Data Engineer – Associate、 AWS Certified Security – Specialty、AWS Certified Machine Learning Engineer – Associate を含む追加の認定も対応予定です。 試験ベースの再認定との関係 従来どおり、認定試験の再受験、上位レベルの試験への合格、または (Cloud Practitioner の場合) AWS Cloud Quest の利用による再認定も引き続き可能です。トレーニングによる認定維持は、追加の選択肢であり、継続的かつ実践的な学習を重視するパスです。どちらのパスでも、有効でアクティブな資格が得られます。 認定延長のカスケード(連鎖) AWS 認定を維持すると、まだアクティブな関連する下位レベルの認定の有効期限も、維持した認定の有効期限に合わせて自動的に延長されます。たとえば、Solutions Architect – Professional を維持した場合、Solutions Architect – Associate も次の有効期限に合わせて延長されます(まだ有効で、1 年以内に期限切れとなる場合に限ります）。 始めるために必要なもの 有効な AWS Skill Builder サブスクリプション (個人サブスクリプション、またはチームサブスクリプション) 有効期限まで 90 日以内の認定 上記のサポート対象認定のいずれか 以上です。上記以外の追加購入も、別途の登録プロセスも不要です。 始め方 AWS Skill Builder にログインし、「 再認定 」に移動して、対象かどうかを確認し、メンテナンスパスを開始してください。 これは AWS 認定プログラムからの提供であり、AWS Skill Builder の体験を通じて提供されます。これは、AWS 認定があなたとともに進化する次のステップです。クラウドプロフェッショナルが求めてきた、継続的で実践的な学習を通じて資格を継続的に維持することができます。 最新の状態を維持し、認定を維持しましょう。今日から認定資格のメンテナンスを始めましょう。 この体験は現在オープンベータ版です。正式な一般提供の前に体験を改善し続けるため、フィードバックを収集しています。ご意見がありましたら、完了後のアンケートからお知らせください。 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

本記事は 2026 年 6 月 29 日に公開された “ Announcing Valkey 9.1 for Amazon ElastiCache ” を翻訳したものです。 Amazon ElastiCache で Valkey 9.1 がご利用頂けるようになりました。 Valkey オープンソースプロジェクト の最新のコミュニティ主導のイノベーションが、ElastiCache 上で低レイテンシーが求められ、高スループットかつ運用要件が厳しいインメモリワークロードを実行するお客様に提供されます。本投稿では、Valkey 9.1 が、要求の厳しいワークロードからさらに高いスループットとメモリ効率を引き出しながら、マルチテナントおよび共有クラスターのデプロイメントに対してより強力な分離を提供する方法について説明します。また、一般的なアプリケーションや運用ワークフローを簡素化する新しいコマンド、エンジンの動作に対するオペレーターの可視性を高める新しいオブザーバビリティ機能、そして ElastiCache が最新の Valkey オープンソースのイノベーションをフルマネージドサービスとして継続的に提供していく方法についても取り上げます。 オープンソースの Valkey コミュニティは、セキュリティ、可観測性、パフォーマンス、効率性、ツールの強化に重点を置いた貢献により、Valkey 9.1 を開発しました。アップストリームリリースの詳細な技術情報については、 Valkey 9.1 コミュニティ発表 をご覧ください。 大規模環境におけるコストパフォーマンスの向上 Valkey プロジェクトがコストパフォーマンスに注力していることは、大規模な ElastiCache デプロイメントを運用しているお客様にとって極めて重要です。スループット、レイテンシー、メモリ効率におけるわずかな改善でさえ、大きなコスト削減につながる可能性があるためです。例えば、 Samsung Electronics は、ElastiCache for Valkey へアップグレードすることで、グローバルサービスに必要なパフォーマンス、信頼性、開発者体験を維持しつつ、約 30% のインフラコスト削減を達成しました。Valkey 9.1 はこの方針を引き継ぎ、ノードあたりのリクエスト処理数を増やし、同じ容量により多くのデータを保存でき、ワークロードのスケールに応じてより予測可能な運用を実現するための機能強化を提供します。 スループットが制約となるワークロードでは、ノードあたりのパフォーマンスが向上することで、既存インフラ上でのトラフィック増加への対応、スケーリングイベントの遅延、または同じリクエスト量を処理するために必要なノード数の削減が可能になります。Valkey 9.1 には、さまざまなワークロードでスループットを向上させる、再設計された I/O スレッディング通信モデルが含まれています。アップストリームの Valkey ベンチマークテストにおいて、Valkey 9.1 は 512 バイトのペイロード、9 つの I/O スレッド、および 10 コマンドのパイプライン深度を使用して、単一サーバーで 1 秒あたり最大 210 万リクエストを達成しました。完全な結果を確認し、バージョン間で比較するには、 Valkey Performance Dashboards をご覧ください。また、アップストリームでテストされたワークロードにおいてスループットを最大 17% 向上させる I/O スレッディングの強化 も含まれています。 Valkey 9.1 では、一般的な高スループットのアクセスパターンのパフォーマンスも向上しています。これには、 XRANGE と XREVRANGE による 高速なストリーム範囲読み取り 、キャッシングワークロードにおける高スループットの文字列読み取り、リーダーボードやスケジューラ向けの高速なソート済みセットクエリ、そしてクライアント初期化のオーバーヘッドを削減するキャッシュ済み COMMAND レスポンスが含まれます。 メモリバウンドなワークロードでは、メモリ効率の向上により、同じノードサイズでより多くのデータを保存できます。また、アプリケーションの動作を変更することなく、メモリ圧迫を軽減することも可能です。Valkey 9.1 では、128 バイト未満の STRINGS のメモリ使用量が最大 20% 削減 され、 ソート済みセットのメモリ使用量 が最大 10% 削減されます。これらの削減は、大量の小さなキャッシュ値、ランキング、スケジュール、レート制限の状態を保存するワークロードにとって特に有用です。 Valkey 9.1 では、 内部のリハッシュ動作も改善 され、キースペースの拡大時におけるレイテンシーへの影響が軽減されています。さらに、 SREM 、 ZREM 、 HDEL などのバルク削除操作中には、不要なハッシュテーブルのリサイズが一時停止されます。これらの機能強化により、お客様はスループットの向上、メモリ負荷の軽減、運用の予測可能性の向上を実現し、ElastiCache インフラストラクチャからより大きな価値を引き出すことができます。ビジネスにとっては、インフラコストの削減、トラフィック増加への余裕の確保、ピーク需要時の安心感の向上につながります。エンドユーザーにとっては、パーソナライズされた体験の読み込み、リアルタイムランキングの表示、イベント処理、レイテンシーに敏感な AI 機能との対話など、いずれの場面においても、よりレスポンシブで信頼性の高いアプリケーション体験を提供できるようになります。 マルチテナントワークロードに対するきめ細かなアクセス制御 マルチテナントや共有クラスターのワークロードを運用するチームは、クラスターモードのスケーラビリティと可用性を犠牲にすることなく、アプリケーション、テナント、環境を分離する方法を必要としています。例えば MoEngage は、ElastiCache for Valkey を活用して、世界中の 1,350 以上のブランドにサービスを提供し、毎日数十億のパーソナライズされたメッセージを配信するカスタマーエンゲージメントシステムを支えています。Valkey 9.0 では、クラスターモードにおける番号付きデータベースを導入することでこの課題に対応し、論理的な分離とシャード間の水平スケーリングを両立させました。これにより、クラスターモードのメリットをすべて維持したまま、単一クラスター内でテナントや環境を分離できます。 例として、ユーザーを作成し、データベース 0 と 1 へのアクセスに制限することができます: ACL SETUSER app-user on >secretpass +@all ~* db=0,1 認証後、そのユーザーはデータベース 0 を操作できます: SELECT 0 OK SET mykey "hello" OK しかし、データベース 2 にはありません: SELECT 2 (error) NOPERM No permissions to access database Valkey 9.1 ではその基盤の上に、データベースレベルのアクセスコントロールリストが追加され、ユーザー権限を特定のデータベースに限定できるようになりました。これまでもアクセス制御ルールによって、ユーザーが実行できるコマンドやアクセスできるキーを制限することは可能でしたが、それらの権限はデータベース全体に広く適用されていました。Valkey 9.1 では、必要なデータベースに対してのみユーザーにアクセス権を付与できます。クラスターモードでの番号付きデータベースとデータベースレベルのアクセス制御を組み合わせることで、より強力な分離とガバナンスを維持しながら、共有クラスターに集約できるワークロードの範囲を広げられます。 新しいコマンドによる一般的なワークフローの簡素化 アプリケーションがスケールするにつれて、一時的な状態の消費、複数の有効期限付きキーの設定、クラスター全体のデータスキャンなどの一般的なワークフローを実装するために、チームはマルチステップのクライアントロジックに依存することがよくあります。これらのパターンは、複雑さを増し、ネットワークのラウンドトリップを増加させ、アプリケーションコードの保守を困難にする可能性があります。 Valkey 9.1 ではこれらのワークフローを簡素化する新しいコマンドが導入されました。 HGETDEL は、ハッシュから 1 つ以上のフィールドをアトミックに取得して削除します。これにより、一時的な状態、ワンタイムトークン、キューのようなデータを一度だけ消費するワークフローを構築できます。たとえば、ワーカーは他のジョブメタデータをそのまま残しつつ、ジョブの状態を 1 つのコマンドで取得して削除できます。 HSET job:42 status "pending" payload '{"action":"send_email"}' retries "3" HGETDEL job:42 FIELDS 2 status payload MSETEX は、共有の有効期限を持つ複数のキーを 1 つのコマンドで設定します。これにより、セッションキー、キャッシュフラグメント、レート制限バケット、その他一時的なアプリケーション状態を一貫した TTL で書き込むようなパターンが簡素化されます。 MSETEX 3 session:abc "user:1" session:def "user:2" session:ghi "user:3" EX 3600 Valkey 9.1 では CLUSTERSCAN も導入されており、クラスター全体でキーをスキャンするための統一された方法が提供されます。これまではクライアントが各ノードを個別にスキャンし、結果をマージする必要がありました。 CLUSTERSCAN は、キーを反復処理するためのクラスター全体のインターフェイスを提供することで、クラスター対応の運用ツール、デバッグ、インベントリジョブ、移行ユーティリティを簡素化します。 CLUSTERSCAN 0 MATCH "session:*" これらのコマンドを組み合わせることで、開発者や運用担当者は一般的なワークフローをより直接的に表現でき、クライアント側の複雑さを軽減し、大規模なクラスターモード有効デプロイメントとより自然に連携するアプリケーションやツールを構築できます。 大規模デプロイメントにおけるオブザーバビリティの向上 Valkey 9.1 では、大規模なデプロイをより効果的に運用できるようにする可視性の改善も新たに追加されています。新しいメインスレッドおよび I/O スレッドの使用率メトリクスにより、エンジンの稼働状況をより明確に把握できるようになり、実際のワークロードによる負荷と想定内のスレッド動作を運用者が見分けやすくなります。 本リリースでは JSON 形式のサーバーログも追加され、カスタムパースロジックなしでオブザーバビリティプラットフォームにエンジンログを取り込み、検索、分析することが容易になります。 これらの機能強化により、チームはクラスターのチューニング、パフォーマンス問題の調査、大規模な ElastiCache デプロイの管理をより自信を持って行えるようになります。 まとめ Amazon ElastiCache 向け Valkey 9.1 は、高性能キャッシュからリアルタイム性・共有性・運用面での要求が厳しいアプリケーションを支えるより広範な基盤へと、Valkey の進化をさらに推し進めるものです。ノードベースのクラスターを運用するお客様にとって、このリリースはインフラストラクチャの効率向上、ワークロードの分離強化、アプリケーションやツールの複雑さの軽減、そして大規模なデプロイをより高い信頼性で運用することに役立ちます。 まずは以下を試してみましょう: 初めての Valkey 9.1 キャッシュを作成する: 新しいキャッシュを起動するには、 ElastiCache 入門チュートリアル を参照してください。 既存のクラスターをアップグレードする: Valkey または Redis OSS を実行している既存の ElastiCache クラスターをアップグレードするには、 エンジンバージョンのアップグレードに関するドキュメント に従ってください。 既存のセルフホストワークロードを ElastiCache に移行する: Valkey または Redis OSS のオンラインマイグレーション を使用して、Amazon EC2 上のセルフホスト型オープンソース Valkey または Redis OSS から Amazon ElastiCache へデータを移行できます。 オープンソースリリースを確認する: 技術的な詳細については、 Valkey 9.1 のコミュニティ発表 をお読みください。 Amazon ElastiCache 向け Valkey 9.1 は、対応する AWS リージョンにて追加費用なしでご利用いただけます。 著者について Mas Kubo Mas は AWS のインメモリデータベースチームのプロダクトマネージャーで、Amazon ElastiCache のオープンソース高性能データストアエンジンである Valkey を担当しています。仕事以外では、フリーダイビング、パラグライディング、カイトサーフィン、セーリングを通じて風と海を追いかけています。 本記事は、 Announcing Valkey 9.1 for Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

本ブログは プリモグローバルホールディングス株式会社 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 はじめに みなさん、こんにちは。古山（アマゾン ウェブ サービス ジャパン合同会社）です。 「新人の接客スキルを底上げしたいが、教える側の負担が大きい」「研修で学んだことを実践する場が足りない」――小売・接客業界で人材育成に携わる方なら、一度はこうした課題に直面したことがあるのではないでしょうか。ブライダルジュエリーの販売を手がけるプリモグローバルホールディングス株式会社 様（以下、プリモGHD様）も、まさにこの課題を抱えていました。本ブログでは、AWS の生成 AI 勉強会をきっかけに同社が Amazon Bedrock を活用した AI ロールプレイサービスを導入し、接客研修を変革した取り組みについて、背景から導入効果、今後の展望までをご紹介します。 多くの接客企業が直面する「教育の属人化」という課題 プリモGHD様の販売店では、接客スキルの平準化が長年の課題でした。接客品質がスタッフ個人の経験やスキルに依存しており、店舗間・スタッフ間でばらつきが生じていたのです。新人教育は熟練スタッフが担当していましたが、教育に割く工数が大きな負担となっていました。営業マニュアルや社内レクチャー動画、商品販売のお手本動画など、教育コンテンツは整備されていたものの、それらはインプットが中心であり、学んだ内容をアウトプットする機会が限られていました。同社は社員定着率の向上も重要なテーマとして捉えており、キャリアマップを描きながらスタッフのレベルを段階的に引き上げる仕組みを構築したいと考えていました。同社には「プリモカレッジ」という既存の教育体系があり、この仕組みの中に新たなアウトプットツールを組み込むことが検討されました。 AWS の生成 AI 勉強会が転機に ― Amazon Bedrock を選んだ理由 2024 年末、AWS の古山よりプリモGHD様の全社向けに AI 勉強会を実施しました。この勉強会では、AWS のサービスや当時注目を集めていた生成 AI の活用可能性について紹介しました。勉強会の実施、その後のアンケート調査を通して、同社は生成 AI を活用した AI ロールプレイが自社の接客研修の課題解決に有効であると感じました。インプット中心だった研修に、実践的なアウトプットの場を加えることで、学びの定着を促進できると考えたのです。これを受けて、AWS から Amazon Bedrock を活用した AI ロールプレイサービスを展開するパートナー企業をご紹介し、プリモGHD様・パートナー企業・AWS の 3 社で検討を開始しました。デモンストレーションを実施したところ好感触を得られ、本格的な導入に向けたプロジェクトが動き出しました。Amazon Bedrock を基盤として選択した理由は、シーンやトーンに応じて複数の大規模言語モデル（LLM）を柔軟に使い分けられる点にあります。ブライダルジュエリーの接客では、お客様に寄り添う繊細なコミュニケーションが求められるため、シナリオに応じたモデルの選択が重要でした。 ソリューションの概要 ―短時間でコース草案が作れる AI ロールプレイ パートナー企業の協力を経て導入した AI ロールプレイサービスは、Amazon Bedrock などを基盤としたクラウドベースの研修ツールです。スタッフは PC やスマートフォンから AI を相手にロールプレイを行い、接客スキルを実践的に磨くことができます。このサービスの特徴は、研修コースの作成が容易な点です。シーン設定を入力するだけで AI が自動的にシチュエーションを生成し、コース草案の作成にかかる時間はわずか 5 分程度です（音声認識や論点抽出などの処理時間を除く）。これにより、研修担当者は多様な接客シナリオを素早く準備し、草案を元に現場の接客ノウハウを持つトレーナーとの協議を行うことができます。 技術的な構成と工夫 ― 多様な接客シーンへの対応 Amazon Bedrock による LLM の使い分け: シーンやトーンに応じて最適な LLM を選択できるため、カジュアルな来店対応から、プロポーズリングの相談といった情緒的な場面まで、多様な接客シナリオに対応が可能です。ロールプレイという特性上、最新のLLMを使うこと必ずしも正しいわけではないため、シーンに合わせて適切なLLMを選択しています。音声認識との連携: スタッフの発話を音声認識で取り込み、AI がリアルタイムに応答することで、実際の接客に近い体験を提供します。 AI によるフィードバック機能: ロールプレイ終了後、AI が論点を抽出しフィードバックを提供します。スタッフは自身の改善点を客観的に把握でき、次の練習に活かすことができます。また、フィードバックの内容については、新人スタッフの方たちも使用することから、まずは「上手くいっていることを褒める」という形に調整して現場での利用を促しました。 使うほど実感が深まる ― 利用回数と満足度の正の相関 導入後、5 段階評価のアンケートを実施した結果、教育効率化に対する評価が高いことが確認されました。高評価を得た上位 3 項目は以下の通りです。 1. 後輩への推奨: 自分が体験して良かったと感じ、後輩にも勧めたいという声 2. フィードバックの納得感: AI が提供するフィードバックの質に対する高い評価 3. 先輩の負担軽減: 教育担当の熟練スタッフの工数削減への貢献 一方、今後の改善が期待される項目として「コース数の不足」「音声認識精度」「会話の不自然さ」が挙げられました。 特筆すべきは、利用回数と満足度の間に明確な正の相関が確認された点です。1〜2 回の利用者が全体の 44.7% を占め、そのポジティブ率は 56.0% にとどまりましたが、6回以上利用した層では 91% 超の高い満足感を示しています。この結果は、AI ロールプレイが「使えば使うほど効果を実感できるツール」であることを裏付けています。 現場の新人スタッフが語る 3 つの変化 先輩の時間を奪わずに練習できる: 「先輩に申し訳ない」「忙しい先輩にお願いしづらい」という心理的ハードルが解消され、気兼ねなく練習に取り組めるようになりました。失敗を恐れず発言できる: AI が相手のため恥ずかしさや緊張が軽減され、積極的にトライできる環境が生まれました。インプットからアウトプットへの一貫した練習: 研修で学んだ内容を、記憶が曖昧になる前にすぐ実践できる点が高く評価されています。 教育体系への本格組み込みへ ― 今後の展望 プリモGHD様はこの成果を踏まえ、2026 年 4 月からの新入社員向け接客フロー研修において、AI ロールプレイをアウトプットツールとして本格活用を開始しています。既存の教育体系「プリモカレッジ」への組み込みを進め、接客スキルの底上げと教育工数の削減を両立する仕組みの確立を目指しています。今後はコース数の拡充や音声認識精度の向上にも取り組み、より実践的な研修環境の構築を進めていく計画です。 まとめ 本事例は、AWS の生成 AI 勉強会をきっかけに、プリモGHD様自身が社内課題を特定し、Amazon Bedrock を活用した AI ロールプレイの導入に至った取り組みです。接客業における人材育成は、熟練スタッフの暗黙知に依存しがちです。生成 AI を活用することで「いつでも・何度でも・気兼ねなく」練習できる環境を実現し、インプット中心だった研修にアウトプットの場を加えることができます。利用回数と満足度の正の相関は、継続的な活用を促す仕組みづくりが成功の鍵であることを示しています。 接客スキルの平準化や教育工数の削減に課題を感じている企業の皆様は、ぜひ AmazonBedrock の活用をご検討ください。AWS では、生成 AI を活用した業務改善についてのご相談を承っています。

本ブログは、キヤノンITソリューションズ株式会社とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさま、こんにちは。AWS ソリューションアーキテクトの戸塚、大久保、寺山です。 Amazon および AWS は、 The Climate Pledge を通じた2040 年までのネットゼロカーボン達成のコミットメントや、再生可能エネルギー活用の拡大などを通じて、事業運営に サステナビリティを組み込む取り組み を継続しています。ホテル・外食産業や流通小売業界等では、需要予測や在庫最適化によるフードロス削減が環境負荷の低減と収益性向上の両面で重要性を増しており、AWS ではフードロス削減を支援するアーキテクチャやお客様事例をご紹介しています。こうした文脈の中で、 Chronos-2 は、事前学習済みの時系列基盤モデルによるゼロショット推論を活用することで、個別モデル学習を必要とせず、計算リソースを抑えながら高精度な需要予測を実現します。さらに推論基盤として AWS Graviton プロセッサ搭載インスタンスを組み合わせることで、価格性能比および電力効率に優れた構成を採用でき、 Well-Architected Framework の持続可能性の柱 にも配慮したアーキテクチャとして、二酸化炭素排出量の抑制に貢献することが期待できます。 本ブログでは、こうした取り組みの一例として、キヤノンITソリューションズ様と共同で取り組んだ Chronos-2 による需要予測を起点としたフードロス削減 PoC について、アーキテクチャと技術的なポイントをご紹介します。 本取組の背景 令和 5 年度の日本全体のフードロスは約 464 万トンであり、そのうちホテルを含む外食産業由来のフードロスは約 66 万トンを占めています。中でもホテル業界では、以下のような特徴からフードロスが発生しやすい環境にあり、長年に渡り業界全体の課題となっていました。 ビュッフェ提供における過剰提供・見栄え重視 婚礼・宴会における需要変動の大きさ 宿泊客数の予測不確実性 サービス品質重視による欠品 NG の文化 ホテル業界では、仕入れ・調理・提供・食べ残しといった各工程でフードロスが発生する上に、昨今では SDGs への取り組みを企業側に期待する宿泊客も増加しています。フードロス削減は コスト削減・業務効率化・ブランド価値向上 の観点からホテル経営における重要テーマとなっています。 30 年以上にわたり PMS（※1）を中心としたホテル向けシステムを手掛けてきたキヤノンITソリューションズ株式会社様（以下、キヤノン ITS）にも、近年お客さまから「データはあるが、具体的な削減施策にどう結びつければよいか」という相談が増えています。こうした声を受け、ホテル事業を営むお客さまにご協力いただきながら、Chronos-2 を用いた需要予測によるフードロス削減の PoCに取り組みました。 （※1）「Property Management System（プロパティ・マネジメント・システム）」の略で、「宿泊予約の管理」「客室の管理」「顧客管理」「売上・請求管理」「データ分析」まで、宿泊施設の運営を支援するホテル管理システム フードロス削減のPoCについて すでにホテルにおけるフードロス対策は数多く展開されているものの、持ち帰りや販売など余った料理を活用する方法は食品衛生の観点から、やることに不安を持つお客さまもいます。また、新しい業務が増えることによる現場スタッフの負荷増大の懸念もあります。 そのため、キヤノン ITS は「料理を余らせない」「現場の業務に影響が少ない」アプローチとして需要予測の精度向上による最適な発注量・提供量によるフードロス削減のPoCに取り組みました。 PoCでは、複数のホテルブランドを展開するキヤノン ITS のお客さまにご協力いただきました。このお客さまは、各店舗で発生しているロス量の記録はできていたものの、具体的な対策までは着手ができていませんでした。 そこで、ロス量の実績データを受領して朝食ビュッフェにおける各品目の消費量の予測を試みました。予測には、時系列基盤モデル Chronos-2 を利用しました。 Chronos-2とは Chronos‑2 は、Amazon Science により開発された時系列基盤モデル（Time Series Foundation Model）です。大規模言語モデル（LLM）と同様に、膨大な時系列データで事前学習されており、個別データごとに学習モデルを構築・チューニングすることなく、過去データ（コンテキスト）を入力するだけで予測を実行できる（Zero‑shot forecasting）点が大きな特徴です。 Chronos-Bolt、Chronos も存在しますが、一番の大きな違いは、Chronos-2 では、複数系列・共変量・カテゴリ情報まで扱える「Universal Forecasting」モデルである点です。 今回 PoC で使用するモデルとして Chronos-2 を選定した理由は以下の通りです。 多変量予測 ：多品目 × 短期間データでも予測が可能 商品ごとにモデルを作り直す必要がなく、「クロワッサン・バターロール・ゆでたまご」といった複数品目を同一アプローチで扱える。 共変量付き予測 ：ターゲット（使用量）・日時情報に加えて、曜日・客数・朝食券配布数などの任意の共変量を入力として扱うことが可能 実績データに加え、業務的に意味のある指標を特徴量として投入することで精度向上が見込める ゼロショット予測 ：学習・再学習が不要なため、PoCから運用検討までが非常に短い モデル構築にコストをかけず、業務データを手軽に試すことができる 上記よりホテルの朝食ビュッフェのように「日次・多品目・需要振れが大きい」業務データに適した時系列予測モデルであると判断し、採用しました。 実行環境と検証アプローチ 今回の精度検証では、データ加工・可視化・分析を反復的に行う必要があったため、 Amazon SageMaker AI の Notebook インスタンスを実行基盤として採用しました。Notebook 上では Python 環境を用い、前処理・予測・評価までを一貫して実施しています。 図1：Chronos-2の検証用実行環境 具体的には、CSV や Excel といった時系列データを取り込み、欠損補完や時系列整形などの前処理を行った上で、Chronos-2 を用いた予測処理を実行し、結果の可視化および精度評価を行いました。この一連の流れにより、モデルの挙動やデータ特性を対話的に確認しながら、仮説検証を高速に回すことが可能となります。 Chronos-2 は以下のようにライブラリをインストールすることで簡単に利用できます。 !pip install -U 'chronos-forecasting==2.2.0' # 予測の実行 import pandas as pd from chronos import BaseChronosPipeline from chronos import Chronos2Pipeline pipeline = Chronos2Pipeline.from_pretrained( "amazon/chronos-2", device_map="cpu“, ) test_df = test_df.drop(columns=["使用量"]) predict_df = pipeline.predict_df( train_df, #コンテキストとなるデータ future_df=test_df, # 予測対象のデータ prediction_length=30, # 予測期間 quantile_levels=[0.1, 0.5, 0.9], # 確率的予測のための分位点（Quantiles） id_column="item", # 異なる系列を表すカラム(カテゴリカラムなど) timestamp_column="date", # 時系列情報を表すカラム target="target", # 予測対象となる時系列の値を格納するカラム（複数可） ) PoCから実運用への展開 一方で、Notebook インスタンス上での実行は、PoCや探索的分析には適しているものの、定常的な業務オペレーションとしての運用には必ずしも最適とは言えません。たとえば、定期実行やシステム連携、スケーラビリティといった観点ではより本番環境に適した構成が求められます。 そのため実運用においては、 Amazon SageMaker JumpStart を活用して Chronos-2 モデルを推論エンドポイントとしてデプロイする構成も有効です。これにより、PoC で検証した予測ロジックを業務プロセスへも容易に組み込むことができます。 PoC実施結果 本 PoC では、ご協力いただいたホテル様よりご提供いただいた過去約 3 年分の日次実績データを活用し、朝食ビュッフェにおける主要 3 品目（クロワッサン、バターロール、ゆでたまご）を対象として検証を実施しました。 本検証の特徴として、単に 1 回の予測を行うのではなく、精度がどの要素によって改善されるのかを確認するため、段階的なアプローチを採用し、以下の 3 ステップで検証を進めました。 Step1：最小構成によるベースライン予測 まず最もシンプルな構成として、以下の最小限のデータのみを用いて予測モデルを構築します。 日付 品名 使用量（ターゲット） このステップでは、モデルの性能評価に先立ち特に重要となる「時系列データの整備」を重点的に行いました。 Chronos‑2 では、入力データが一定間隔の時系列として整っていることが前提条件となるため、以下の前処理を行い分析に適したデータセットを整備しました。 品目ごとのデータにおける日付の欠損確認 損日付に対する補完レコードの追加 結果 このベースラインモデルの結果は以下の通りです。 MAPE MAE 80%区間被覆率(※2) 約56.6% 約13.4 約68.9% (※2) 80%区間被覆率とは予測された「80%の確率でこの範囲に収まる」とされる区間に、実測値がどれだけ含まれているかを示す指標 図2：ベースライン予測結果(予測 対 実測) 数値変動の大まかな傾向は捉えられているものの、以下 3 点の実業務における重要な要因を考慮できておらず、 業務で活用するには精度が不十分であることが確認されました。 平日と週末の需要差 宿泊客数による需要変動 直近の消費傾向 Step2：業務データを考慮した予測モデル 次に、実際のホテル業務において使用量を判断する際に利用されている情報を特徴量として追加し予測を行いました。追加したデータは以下の通りです。 前日宿泊者数 朝食券配布枚数 これらの項目は、単なる補助情報ではなく現場において「今日は宿泊者が多いから多めに作る」といった意思決定に直接使用されている重要な指標です。 また、特徴量の選定にあたって以下の観点で絞り込みを行いました。 使用量との相関確認 予測時点で取得可能なデータのみを利用（リーケージ防止） 図3：使用量に対する各特徴量の相関係数 結果 MAPE MAE 80%区間被覆率 約28.3% 約7.1 約78.9% 図4：重要指標を特徴量へ追加後の予測結果(予測 対 実測) ベースラインと比較して、誤差は約50%改善し、以下が適切に反映されるようになりました。 平日／週末の傾向 来客規模の影響 この結果から、業務知識に基づく特徴量の追加が予測精度に大きく寄与することが明確に確認することができました。 Step3：ラグ特徴量による最終的な精度向上 さらに精度向上を図るため、時系列データ特有のパターンである「連続性」と「周期性」をモデルに取り込むことを目的として、ラグ特徴量を追加しました。 本PoCでは、ラグ特徴量の追加を感覚的に行うのではなく、事前に以下の分析を行いました。 自己相関分析 偏自己相関分析 曜日単位の周期性の確認 図5：曜日周期性の確認と自己相関 この結果から、以下のような「連続性」と「周期性」を確認することができました。 「前日の影響を受ける（連続性）」 「1週間単位で繰り返される（曜日周期）」 朝食ビュッフェの需要特性を踏まえた上で、下記の特徴量を追加して予測を行いました。 使用量_lag1（前日の使用量） 使用量_lag7（1週間前の使用量） 結果 最終モデルの結果は以下の通りです。 MAPE MAE 80%区間被覆率 約20.3% 約5.05 約82.2% 図6：ラグ特徴量追加後の予測結果(予測 対 実測) この結果から、 予測精度のさらなる向上 と 予測の信頼性（区間被覆率） の改善実運用への適用が十分に検討可能な水準に到達することが確認できました。また、グラフ上でも、週末の需要ピークや品目ごとの変動特性が再現されており、モデルが単なる数値補間ではなく、需要構造そのものを捉えることができました。 技術的なポイント Chronos-2 における時系列カラムの注意点 Chronos‑2 を利用した時系列予測では、コンテキストとして入力されるデータが「一定間隔の時系列として整備されていること」が前提条件となります。例えば、日次データであれば、時系列カラム×種類カラム(今回の場合は、日付×品目)において、すべての日付が抜け漏れなく並んでいる必要があります。また、予測は、各種類カラムの最終日付から指定した日付分の予測が行われる点にも注意が必要です。 図7：異なる期間のデータを用いた場合の予測対象期間 実運用データでは、非営業日や記録漏れなどにより日付が欠損しているというケースも少なくありませんが、そのまま Chronos-2 に投入すると時系列として正しく解釈されず、エラーが発生する可能性が高いため注意が必要です。 図8：データ抜け日の確認と欠損補完イメージ このため、本 PoC では品目ごとに日付の連続性を確認し、欠損している日については 補完レコード（使用量 0 または NULL）を追加する前処理を行っています。た。Chronos‑2 を活用する際は、モデル以前に「時系列を等間隔に整えるデータ整備」もポイントになります。 リーケージを防ぐ設計 時系列予測や機械学習において注意すべき点のひとつがリーケージ（データリーケージ）です。リーケージとは、予測時点では本来入手できない未来の情報を、誤って特徴量として使用してしまうことを指します。 リーケージが発生すると、一見すると非常に高い予測精度が出るが、実際の業務運用では同じデータが取得できないため、検証時の精度が再現できないモデルになってしまうため注意が必要です。 図9：リーケージの危険性 本 PoC では、「前日終業時点で翌日の朝食使用量を予測する」という業務シナリオを前提とし、前日宿泊者数や朝食券配布枚数など、予測時点で確実に取得可能な情報のみを特徴量として使用しました。機械学習モデリングでも同様ですが、Chronos‑2 を業務に適用する際には、「その情報はいつ取得できるのか？」を意識し、リーケージを防ぐ設計が不可欠です。 ラグ特徴量の有効性 時系列予測では、過去の値が将来の値に影響するという特性をモデルに取り込むため、過去の値をずらして特徴量として使用する「lag 特徴量」がよく用いられます。lag 特徴量を追加することで、直前の傾向（連続性）や、曜日などによる周期的なパターンを表現することができます。 図10：ラグ特徴量のメリットと注意点 本 PoC では、自己相関の結果に基づき、lag1：前日の使用量、lag7：7日前（同じ曜日）の使用量を特徴量として追加しました。 これにより今回の検証では、短期的な増減や曜日単位の周期性を捉えやすくなり予測精度が向上しました。 一方で、lag 特徴量は設定次第でリーケージにつながる可能性があるため、「いつ予測を行うのか」という業務前提を明確にした上で、実運用で取得可能な範囲の lag のみを採用することもが重要になります。 Chronos-2 に関する考察 機械学習モデルの予測精度向上施策を打つことで、Chronos-2 でも同様に予測結果が向上させることが可能 機械学習モデリングの時と同様にコンテキストに含めるデータ項目が多いとより精度向上施策に幅がでて、精度改善に寄与することができる可能性が広がる FineTuningやクロースラーニングなどさらなる精度向上施策を手軽に試せる点も非常に使い勝手が良い 本検証の総括 今回の取り組みを通じ、ホテル業界におけるフードロスは「やむを得ないもの」ではなく、データ活用により削減可能であることを実感しました。現在の、食数予測においてはホテル従業員の経験や勘に依存する部分も多く、その結果として過剰な仕込みやロスが発生しやすい傾向にありましたが、今回の Chronos-2 による需要予測を用いることで需要変動の傾向が可視化され、ロス削減の余地があることが分かりました。 一方で、予測の結果だけですべてが解決するわけではありません。実際の現場では、お客さまへの満足度を考慮してある程度の余剰を持たせる運用が不可欠です。そのため、単に予測結果を提供するのではなく、「予測結果をどう使うか」「どこまでなら調整が出来るか」といった現場に寄り添った運用面もあわせて合わせて考えることが重要です。 今後は、予約状況やイベントなどの外部情報も取り入れながら精度を高めるとともに、予測結果を発注業務などに連携させる仕組みを作ることがより一層重要になると考えます。引き続き、現場に寄り添いながら、ホテル業界全体のフードロス削減に貢献できるよう取り組んで参ります。 まとめと今後の展望 今回の取り組みでは、Amazon Science が発表した時系列基盤モデル Chronos-2 が、ホテルの朝食ビュッフェという「日次・多品目・需要変動が大きい」業務領域において有効に機能することを検証しました。学習不要で即座に予測を開始できることに加え、特徴量の工夫により追加学習なしでも本番業務で活用できる精度に達することを実証しました。これにより、PoC から本番運用への移行を短期間かつ低コストで実現する道筋が示されたと考えています。 AWS では、Amazon SageMaker AI をはじめとする AI/ML サービスを通じて、Chronos-2 のような時系列基盤モデルを本番環境でスケーラブルに運用するための基盤を提供しています。本ブログで紹介した需要予測のアプローチは、ホテル業界に限らず、外食・流通小売・食品製造など、フードロスが課題となる幅広い業種への適用が期待されます。また、こうした需要予測での発生抑制に閉じるのではなく、 スマート廃棄物管理 など多面的なアプローチがフードロス削減を目指す上では不可欠です。 Amazon は、The Climate Pledge を通じて2040年までにネットゼロカーボンを達成することをコミットしており、AWS はその実現に向けて、エネルギー効率に優れたクラウドインフラストラクチャの提供、カーボンフリーエネルギーへの移行推進、そしてお客様のワークロード最適化による環境負荷低減の支援を行っています。本ブログでご紹介した需要予測によるフードロス削減も、テクノロジーを活用した持続可能性への貢献の一つです。同様の取り組みを検討されている皆さまの一助となれば幸いです。 執筆者 キヤノンITソリューションズ株式会社 ホテル業界向けのシステム開発を30年以上手掛けています （左から） 大原 諭 (Satoshi Ohara) 流通業界・サービス業界向けおよびデータマネジメントソリューションのマーケティング・企画担当 大竹 智礼 (Tomonori Otake) データマネジメント領域におけるデータサイエンティストとして、主に流通業界向けのデータ分析、 予測AI、生成AI開発を担当 辻 夏子(Natsuko Tsuji) ホテル業界向けソリューションのマーケティング・商品企画担当。本取り組みの推進リーダー 戸塚 智哉(Tomoya Tozuka) /@tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューションアーキテクトで、AI/ML、IoT を得意としています。最近ではAWSを活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています 大久保 裕太 (Yuta Okubo) 外食業界や飲料メーカーのお客様を支援しているソリューションア―キテクトです。好きなAWSサービスは AWS IoT Core。 最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています 寺山 怜志 (Satoshi Terayama) 外食業界や百貨店業界のお客様を支援しているソリューションア―キテクトです。 最近は、時系列基盤モデル Chronos-2 を始めとした機械学習領域での学びを深めています  

2026年2月6日から22日にかけて、イタリアのミラノ・コルティナにて世界的な冬季スポーツ競技大会が開催されました。本ブログでは、株式会社フジテレビジョン様（以下、フジテレビ）がこの大会において、地上波テレビ放送のライブ映像制作を AWS 上で行う「Live Cloud Production（以下、LCP）」を実現した事例をご紹介します。 テレビのライブ放送を支える3つの処理 Live Cloud Production とは、物理的な設備を削減しクラウド上でのライブ映像の制作を可能にする新しい放送・映像制作ワークフローです。Live Cloud Production を理解する上で、一般的なテレビのライブ放送がどのように行われているのかを最初にご紹介します。テレビのライブ放送で視聴者に届ける映像を制作する上で、主に3つの処理がリアルタイムに行われています。 1つ目は映像スイッチングです。スタジオ、競技会場、リプレイなど複数の映像ソースの中から、放送に乗せる映像をリアルタイムに選択・切り替えます。2つ目は音声ミキシングです。各出演者のピンマイク、会場の環境音、BGM、効果音など多数の音声チャンネルを適切なバランスに調整します。3つ目は CG 合成です。テロップ、スコア表示、バーチャルグラフィックスをリアルタイムに描画し、映像に重ね合わせます。従来はこれらの３つの処理は専用ハードウェアによって処理されていました。 図1: 実際のスタジオの様子。競技映像やスタジオセットの上半分などは CG 合成で作られていて、現地での設営を簡略化している。複数ソースからの映像スイッチングや音声ミキシングも行われている。(提供：株式会社フジテレビジョン) 国際中継における課題 海外で開催されるスポーツイベントの中継では低遅延かつ放送品質の安定した映像伝送を行う必要があるため、競技会場と国内のテレビ局の間に専用回線を敷設する必要があります。さらに、前述の3つの処理（映像スイッチング、音声ミキシング、CG 合成）を行うための専用ハードウェアも現地に輸送・設置しなければなりません。現地への機材輸送・設置には数ヶ月の期間を要し、専用回線の費用も含め大きなコストとなっていました。 フジテレビの取り組み — Live Cloud Production 近年は専用ハードウェアが持つ機能のソフトウェア化が進んでおり、ライブ放送に必要な処理（映像スイッチング、音声ミキシング、CG 合成）をオンプレミスのサーバーやクラウド上の仮想サーバーで実行できるようになってきています。 フジテレビは今回の大会で、ライブ放送に必要な処理を行うソフトウェアを Amazon EC2 上で、海外からの映像伝送を AWS Elemental MediaConnect で行い、LCP として AWS クラウドに集約する構成を採用しました。 ミラノの IBC（国際放送センター）に設置したエンコーダーで8台のカメラ映像を H.265 / 20Mbps の SRT (Secure Reliable Transport) ストリームに変換し、帯域保証付きの公衆インターネット回線2本（本番用・予備用）を通じて AWS フランクフルトリージョンに送出します。フランクフルトリージョンの Amazon EC2 上では、Sony M2L-X（映像スイッチング）、Waves Cloud MX Audio Mixer（音声ミキシング）、Vizrt Viz Engine（CG 合成）が稼働し、AWS Elemental MediaConnect がクラウド内外の映像ルーティングを担いました。完成した番組映像は AWS Direct Connect 経由でお台場のフジテレビ本社に SRT で伝送され、地上波で放送されています。クラウド障害時に備えたパリリージョン経由のバックアップパスも構築しました。 図2: Live Cloud Production の全体構成。ミラノ IBC からフランクフルトリージョン、お台場のフジテレビ本社までの映像・音声・制御の全系統を示す。(提供：株式会社フジテレビジョン) この構成により、IBC 側のスタジオにはスイッチャーやミキサーなどのコントローラーやモニターを中心に配置する形となりました。従来のハードウェアの機能をクラウドに移したことで、現地の設備は大幅に簡素化されています。 パリからミラノへ — 1年半にわたる検証 フジテレビと AWS は3年以上にわたり、段階的に LCP の取り組みを進めてきました。 2024年のパリで行われた夏季スポーツ競技大会では、ソニー製ソフトウェアスイッチャー M2L-X を AWS 上で利用する PoCを実施しました。その後、約1年半にわたり、様々なパートナーのソフトウェアを EC2 上で利用するための検証が重ねられました。各ソフトウェアを動かす EC2 間では、NDI (Network Device Interface) という高品質・低遅延の映像・音声データをリアルタイムで相互伝送する伝送方式が使われており、NDI 伝送の検証も進められました。 2025年8月にはフランクフルトリージョンにクラウド環境を構築し、実際のスタジオを使った最終検証を実施。9月末にはミラノ現地の IBC に設置する全機材の仮組みとクラウドシステムの統合検証を完了しました。 本番運用と結果 期間中は、イタリア国内各所で実施された多数の競技中継を LCP で制作しました。全期間を通じて放送品質を維持した安定運用を達成しています。クラウドを経由した全体の遅延は約 1.7 秒に収まり、従来のオンプレミス構成と遜色ない遅延量で制作することができました。 ネットワークコストは、過去大会の専用線費用と比較して 45% 削減されました（現地インターネット回線費用およびクラウドアプリケーションライセンス費用を含む）。また、現地入りからスタジオオープンまでの技術全体のセットアップ作業時間は、従来と比較して 21% 削減されています。 まとめ 今回は、フジテレビが世界的な冬季スポーツ競技大会で LCP を実現した事例についてご紹介しました。今回の実績を踏まえ、フジテレビは今後の国内外のスポーツ中継への LCP 展開を検討されています。 LCP や放送業界での AWS 活用にご関心のある方は、お気軽にお問い合わせください。 著者 北村 友（Yu Kitamura） アマゾン ウェブ サービス ジャパン合同会社 通信・メディア技術本部 ソリューションアーキテクト 放送局をはじめとしたメディア業界のお客様への技術支援を担当しています。

みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊AWS をお届けします｡ 先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡ それでは､先週の主なアップデートについて振り返っていきましょう｡ 2026年6月22日週の主要なアップデート 6/22(月) Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始 Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡ AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善 AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡ AWS Lambda MicroVMs で分離実行環境を提供開始 AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡ 6/23(火) Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡ Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview) Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡ Amazon CloudWatch Logs がマネージド syslog 取り込みに対応 Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡ 6/24(水) Amazon CloudWatch でダッシュボードのタグ機能をサポート Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡ Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡ AWS IoT Device SDK for Swift の一般提供開始 AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡ Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表 Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡ 6/25(木) AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡ それでは､また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

本記事は 2026 年 6 月 25 日に公開された Sumitha AP、Rajdeep Mukherjee による “ From OpenAPI/Swagger specifications to test suite in seconds with Kiro ” を翻訳したものです。 API は現代のアプリケーションの基盤です。チームが REST API を構築し改良していく中で、網羅的なテストカバレッジを維持することは継続的な課題となります。 OpenAPI/Swagger 仕様 は、API が どう振る舞うべきか を的確に記述します。エンドポイント、リクエストの形式、レスポンスのスキーマ、ステータスコードなどです。しかし、それらが実際に機能することを証明するものではありません。 そのギャップを埋める作業は、伝統的に開発者の肩にかかってきました。仕様を読み、各エンドポイントをテストケースに落とし込み、正常系とエッジケースを考慮し、テストランナーを組み立て、依存関係をモックし、結果を意味のある形で見せるためのレポート機能を構築します。中規模の API、例えばエンドポイントが 40 個あるとすると、製品コードを 1 行も書く前に 1 週間分の作業が必要です。しかも仕様が安定していることが前提ですが、実際にはほとんど安定しません。 根本的な課題は、API 仕様とそれに対応するテストスイートが独立して保守されていることです。時間が経つにつれ、両者は必然的に乖離していきます。リリース時に書かれたテストはエンドポイントの変更とともに陳腐化し、新しいエンドポイントはテストカバレッジを伴わずにリリースされていきます。 OpenAPI Generator のようなツールは仕様からテストのスキャフォルディングを生成できますが、通常は開発者自身が埋めるためのスタブを提供するだけです。Kiro は別のアプローチを取り、仕様をテスト生成の信頼できる情報源として扱います。OpenAPI/Swagger ファイルを入力すると、Kiro は動作するテストスイート、エンドポイントカバレッジ、エッジケース、スキーマ検証、レポート用スキャフォルディングを、テストファイルをセットアップする時間と同じくらいで生成します。さらに、Kiro は再生成を素早く低コストで行えるようにすることで、テストを仕様と同期させるコストを下げ、フックによってドリフトを早期に検出できます。本記事では、それがどのように機能し、何が生成されるのかを詳しく見ていきます。 Swagger と OpenAPI 仕様 Swagger は、構造化された JSON を使って REST API をドキュメント化する手段として作られました。どんなエンドポイントがあるか、各エンドポイントがどのパラメータを受け取るか、成功時に何を返すか、問題が起きたときに何を返すか、といった語彙を定義します。 最小限の OpenAPI ドキュメントは、各エンドポイントについて、URL パスと HTTP メソッド、受け取るパラメータ（型、位置（location）、必須／任意）、成功時のレスポンススキーマ、ありうるエラーレスポンスとそのコードを指定します。 # openapi.yaml: マシン可読な API の契約 openapi: "3.0.0" paths: /pet/{petId}: get: summary: "Find pet by ID" parameters: - name: petId in: path required: true schema: { type: integer } responses: "200": content: application/json: schema: { $ref: "#/components/schemas/Pet" } "404": description: "Pet not found" OpenAPI ドキュメントは単なるドキュメント以上のものです。REST API のインターフェースを完全に記述する構造化された定義ファイル（JSON または YAML）です。API の提供者と利用者の間の契約として機能し、マシン可読であるため、適切なツールがそれを解析し、推論し、実際の成果物を生成できます。この点は、以降の議論すべてに関わる重要なポイントです。 本記事では、エージェント駆動の開発システムである Kiro を使って、Swagger API 仕様から直接、モックサーバー・設定トグル・HTML テストレポートまで含む実行可能な Node.js テストスイートを自動生成する方法を示します。 既存ツールが力不足な理由 これまでに OpenAPI 仕様を扱ったことがあれば、OpenAPI Generator や Swagger Codegen に出会ったことがあるでしょう。背景として、OpenAPI Generator はガバナンスの違いから 2018 年に Swagger Codegen からフォークされました。両者は似た目標を持ちますが、独立して保守されており、リリース頻度や機能セットも異なります。どちらも仕様ファイルを受け取り、選択した言語のクライアントライブラリ、サーバースタブ、SDK コードを生成するオープンソースツールです。HTTP のボイラープレートを削減するには優れていますが、API の振る舞いを検証する目的では設計されていません。テスト生成に使おうとすると、通常はアサーションが最低限のメソッドスタブ、限定的なモック、わずかなスキーマ検証しか得られません。もっとも、具体的な出力は使用する言語、テンプレート、設定によって異なります。テストはコンパイルされ実行はされるかもしれませんが、エッジケース、エラーハンドリング、スキーマの契約を意味のある形でカバーしているとは限りません。 これは見た目以上に深刻な問題です。アサーションのないテストでも CI ではパスし、カバレッジにはカウントされます。しかし実際にはステータスコード、レスポンスの形、エラーケースをチェックしていません。ビルドは成功し、カバレッジ数値も高いのに、 400 が 500 として返されているといった特定のバグが見過ごされるということが起こり得ます。 Kiro はこの問題に異なるアプローチを取ります。仕様をテンプレート化するのではなく、仕様を推論します。enum の値を現実的なペイロードに解決し、実際のスキーマの契約に紐づいたアサーションを生成し、仕様で定義された振る舞いを反映したモックサーバーを作り出します。出力されるのは後で埋めるためのスキャフォルディングではなく、意味のあるカバレッジを持つ実行可能なテストです。 機能 OpenAPI Generator Kiro アサーション付きの実行可能なテストを生成 ◐ 限定的（テンプレート依存） ✓ あり 仕様に対応するモックサーバーを構築 ✗ なし ✓ あり スキーマから現実的なペイロードを推論 ◐ 部分的 ✓ enum の解決を含む チームのコーディング規約に適合 ◐ カスタムテンプレート ✓ ステアリングファイル経由 仕様のドリフトに応じて CI で再生成 ✗ 手動 ✓ ヘッドレスモード 自然言語の意図を理解 ✗ なし ✓ あり 機能比較: テンプレートベースのジェネレーター vs. Kiro のエージェント駆動アプローチ。 テンプレートベースのアプローチでは、特定の種類の問題が検出されないままになり得ます。例えば 400 エラーが 500 として返されたり、認証エンドポイントが不正な形式のトークンを受け入れたりするケースです。とくに、生成されたテストが実際にはエンドポイントへの呼び出しを行わず、レスポンスの検証もしない場合に顕著です。これらのツールは主にコード生成のために設計されており、振る舞いの検証のためのものではありません。一方で Kiro は、各エンドポイントを実際に呼び出し、レスポンスが仕様で定義されたものと一致するかを検証するテストを生成します。これにより、API の実際の準拠状況についてより信頼できるシグナルが得られます。 ソリューション概要 本ソリューションでは、サンプルの PetStore の Swagger/OpenAPI 仕様 URL を入力として受け取り、Kiro を使って完全に機能するテストプロジェクトを生成します。生成されるプロジェクトには以下のコンポーネントが含まれます。 axios を使用したテストクライアント ：Swagger 仕様で定義されたすべてのエンドポイントをカバーする HTTP テスト。GET、POST、PUT、DELETE 操作と、それに応じたリクエストペイロードおよびレスポンスアサーションを含みます。 Express のモックサーバー ：API をシミュレートするローカルサーバー。各エンドポイントに対して現実的なレスポンスを返すため、ネットワークアクセスや実サービスへの依存なしにテストを実行できます。 設定トグル ：同じテストスイートをモックサーバー（ローカル開発用）または実 API（統合テスト用）に対して実行できる簡単なスイッチ。 HTML テストレポート ：各テストケースの合否と詳細なエラー情報を表示する、スタイル付きで共有可能なレポート。CI/CD パイプラインやプルリクエストのレビューに適しています。 外部テストフレームワークゼロ ：テストは素の Node.js と軽量なカスタムランナーで動作し、フレームワークのバージョン競合をなくし、セットアップの手間を減らします。 前提条件 このウォークスルーを進めるには、以下が必要です。 Node.js Kiro のインストールと設定 Swagger/OpenAPI 仕様の URL（例として Petstore API を使用します） Kiro でテストスイートを生成する それでは、Petstore の Swagger 仕様から完全なテストスイートを生成しましょう。テスト生成のルールをすべてプロンプトに埋め込むのではなく、Kiro のステアリングファイルを使用します。ステアリングファイルは「 .kiro/steering/ 」に配置され、ワークスペース内のすべてのプロンプトで Kiro が従う永続的な指示を提供します。これにより、テスト生成の基準を一度定義しておけば、すべてのプロンプトでその恩恵を受けられます。本ブログでは このサンプル ステアリングファイルを使用しました。チームのニーズや基準に合わせてカスタマイズしてください。 ※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は 原文記事 をご参照ください。 サンプルプロンプト Kiro の vibe モードで使用するサンプルプロンプトを示します。 Generate a Node.js test suite from https://petstore.swagger.io/index.html using axios, Express for mocking, and no external test frameworks Kiro は Swagger 仕様を読み込み、すべてのエンドポイントを解析し、プロジェクト全体を生成します。 ※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は 原文記事 をご参照ください。 生成されたプロジェクト構造を確認する Kiro は以下のような構造のプロジェクトを生成します。 config.js ：設定トグルを含みます。 useMockServer: true に設定するとローカルの Express モックサーバーに対してテストを実行し、 useMockServer: false に設定すると実際の Petstore API を対象にします。 mock-server/server.js ：Petstore のすべてのエンドポイントに対するルートハンドラを持つ Express アプリケーション。各ハンドラは、Swagger 仕様で定義されたスキーマに一致する現実的なレスポンスデータを返します。 test/ ：API リソース（pet、store、user）ごとに整理された個別のテストファイル。各ファイルには、そのリソースのすべての操作に対するテストが含まれ、レスポンスのステータスコードとペイロード構造に対するアサーションがあります。 test-runner.js ：軽量な素の Node.js テストランナー。すべてのテストファイルを検出して実行し、合否のカウントを追跡し、エラーの詳細を取得します。 Kiro がどのように仕様を解析するかを理解する Kiro は汎用的なテストスタブを生成するだけではありません。Swagger 仕様とステアリングファイルの指示を読み込んで、次のことを行います。 すべてのエンドポイントと HTTP メソッドを識別する ：Petstore API の場合、POST /pet、GET /pet/{petId}、PUT /pet、DELETE /pet/{petId}、GET /store/inventory、POST /user/createWithList などの操作が含まれます。 スキーマ定義からリクエストペイロードを推論する ：POST および PUT 操作について、Kiro は仕様内のモデル定義に基づいて有効なリクエストボディを構築します（例えば、id、name、category、photoUrls、tags、status フィールドを持つ Pet オブジェクト）。 期待されるレスポンスコードに基づいて検証コードを生成する ：各テストは、仕様のレスポンス定義で定められた正しい HTTP ステータスコード（ 200 、 201 、 404 、 405 ）を検証します。 対応するモックサーバーのルートを作成する ：仕様内のすべてのエンドポイントに対して、定義されたレスポンススキーマに合致したデータを返す Express ルートハンドラが生成されます。 テストを実行する モックサーバーに対して実行する ローカルのモックサーバーに対してテストスイートを実行するには、チャットインターフェースで次のプロンプトを入力します。 Run the tests with the mock server 以下のような結果が表示されるはずです。 テストランナーはモックの Express サーバーを起動し、すべてのテストケースを実行し、レポートを生成します。生成された test-report.md をブラウザで開いて結果を確認してください。 テストの品質と分類 生成されたテストスイートには、Petstore の Swagger 仕様で定義されたすべてのエンドポイントをカバーするテストケースが含まれています。これらはユニットテストではなく統合テストです。各テストは axios 経由で実行中の Express サーバーに対して実際の HTTP リクエストを送り、TCP トランスポート、ミドルウェアのパース、ルートマッチング、ハンドラのロジック、状態の変化、JSON シリアライズといったスタック全体を使います。サーバー内部は関数レベルでスタブやモックされていません。複数のリクエストを連鎖させるテストも含まれます。例えば DELETE のテストでは、最初にリソースを POST し、次に DELETE し、最後に GET で 404 を確認するといった具合で、リクエストライフサイクルをまたいで副作用が正しく永続化されることを検証します。このマルチリクエストでブラックボックスなアプローチは、統合テストを統合テストたらしめる特徴です。 品質面では、このスイートには明確な強みがあります。各エンドポイントについて正常系と異常系の両方を体系的にカバーし、OpenAPI 仕様に記載された具体的な HTTP ステータスコード（ 200 、 400 、 404 、 405 ）を検証します。エフェメラルポートとインメモリのシードデータを使用しているため、スイートは完全に自己完結しており決定的です。ネットワーク依存もポートの衝突もなく、どのマシンでも再現可能です。破壊的な操作はレスポンスコードだけを信用せず、後続の読み取りで検証します。 要するに、これは API の形状とエラーハンドリングに対する CI の高速フィードバックに適した、実用的な契約レベルの統合スイートです。プロダクション品質の信頼性に到達するには、テストごとの状態分離、完全な JSON スキーマ検証、認証のカバレッジ、そして実サービスに対する定期的な実行が加わると良いでしょう。 詳細: 削除ライフサイクル全体のテスト Kiro が生成したテストの中でも、より興味深いものの 1 つは、単にエンドポイントを呼び出してステータスコードを確認するだけのものではありません。1 つのテストケースで、リソースのライフサイクル全体を検証します。 このテストが興味深いのは、DELETE のレスポンスだけを信用していない点です。多くの素朴なテストスイートは 200 ステータスコードを確認するだけで止まります。「サーバーが成功したと言ったのだから、成功した」というわけです。しかしそれは状態が実際に変化したかどうかを何も証明していません。バグのあるサーバーは 200 を返しつつ、レコードの削除に静かに失敗するかもしれません。 本当に消えている、ということです。 その代わりに、Kiro は 3 段階のテストを生成しました。 Arrange ：既知の ID を持つ新しい pet を POST し、正常に作成されたことを確認します。 Act ：その pet を DELETE し、サーバーが操作を受け付けたことを検証します。 Verify ：同じ ID を GET し、サーバーが 404 を返すことを検証します。 このパターンは「ラウンドトリップ検証」と呼ばれることがあり、うわべだけのテストと意味のある統合テストを分けるものです。API の状態が実際に遷移することを証明します。すなわち、存在するリソースは破棄でき、いったん破棄されれば本当に消えているということです。スタックのどこかの層（ルーティング、ハンドラのロジック、データストア）が削除を黙って取りこぼしても、GET による検証がそれを捕まえます。 これはテストが自己完結している好例でもあります。テストは、先行するテストによって書き換えられたかもしれないシードデータに依存するのではなく、自分自身でテストデータを用意します。これにより、テストの合否が実行順序に左右されなくなります。テストごとに状態をリセットしないスイートでは、これは小さくとも重要な品質シグナルです。 実 API に対して実行する 生成されたテストがモックの外でも通用するかを検証するには、1 つの環境変数を設定するだけで、開発者はスイートを実際の Petstore サーバーに向けることができます。 PETSTORE_URL=https://petstore.swagger.io npm test あるいは Kiro に「 Run the tests with the real server 」とプロンプトを与えます。これにより、コードを変更することなくまったく同じテストが実行されますが、対象がローカルの Express モックではなく実稼働の共有バックエンドになります。 失敗が発生したとき、それらは通常いくつかの認識可能なカテゴリに分類されます。 実 API が仕様より寛容な場合。 Swagger 定義では不正な入力に対して 405 を文書化していても、実サーバーはそれを静かに受け入れて 200 を返すことがあります。モックの方が現実より厳しかったというわけです。 エラーコードの意味が異なる場合。 モックは非数値 ID に対して 400 を返すかもしれませんが、実サーバーは 404 を返すかもしれません。どちらも擁護可能です。同じ仕様の異なる解釈を表しているだけです。 レスポンス形状が期待と一致しない場合。 テストが文字列として期待するフィールドが JSON オブジェクトとして返ってきたり、ネストされたプロパティが完全に欠落していたりします。 共有状態の前提が崩れる場合。 シードされたデータ（事前にロードされたユーザーや pet など）に依存するテストは、実サーバーがそれらのテストデータを持たないために失敗します。 このようなことが起きたときの推奨は、失敗をやみくもに「修正」しないことです。代わりに、それぞれを切り分けの問いとして捉えます。モックが間違っているのか、テストが間違っているのか、ドキュメントが間違っているのかということです。そこから次のように進めます。 実サーバーがより寛容な場合は、モックを緩めて合わせるか、テストをモック専用としてタグ付けするかを判断します。 エラーコードが異なる場合は、単一の信頼できる情報源（通常は実サーバーの実際の振る舞い）に揃え、モックとテストの期待値の両方を更新します。 共有状態が問題である場合は、テストを自己完結型にします。検証前に自分自身でテストデータを用意し、ローカルにしか存在しないデータに依存しないようにします。 ポイントは、初日から両モードで全テストを通すことではありません。両方のターゲットに対して実行することで、 前提が現実から乖離している箇所 が浮かび上がり、そのギャップを埋める道筋が体系的に得られるということです。 認証された内部 API に適応する Petstore API は認証を求めないパブリックなサンドボックスです。一方、実際の社内 API はほとんどの場合認証を必須とします。認証付きエンドポイントにこのアプローチを適応させる方法を示します。 まず、認証設定に対応できるようにテスト設定を拡張します。資格情報をハードコードするのではなく、外部から渡せるようにすることで、同じスイートを複数の環境で動かせるようにします。 // config.js module.exports = { baseURL: process.env.API_BASE_URL || 'http://127.0.0.1:3000', auth: { type: process.env.AUTH_TYPE || 'none', // 'none', 'bearer', 'apiKey', 'basic' token: process.env.AUTH_TOKEN, apiKey: process.env.API_KEY, apiKeyHeader: process.env.API_KEY_HEADER || 'X-API-Key', username: process.env.AUTH_USERNAME, password: process.env.AUTH_PASSWORD, }, }; 次に、設定された認証タイプに基づいて適切な資格情報を付与する共有クライアントファクトリーを構築します。 // client.js const axios = require('axios'); const config = require('./config'); function createClient() { const headers = {}; switch (config.auth.type) { case 'bearer': headers['Authorization'] = `Bearer ${config.auth.token}`; break; case 'apiKey': headers[config.auth.apiKeyHeader] = config.auth.apiKey; break; case 'basic': const encoded = Buffer.from( `${config.auth.username}:${config.auth.password}` ).toString('base64'); headers['Authorization'] = `Basic ${encoded}`; break; } return axios.create({ baseURL: config.baseURL, headers, validateStatus: () => true, }); } module.exports = { createClient }; これで、すべてのテストファイルが共有クライアントを使用し、資格情報はコードの外に保たれます。 # トークン認証のステージング API に対して実行 AUTH_TYPE=bearer AUTH_TOKEN=eyJhbG... API_BASE_URL=https://api.internal.example.com npm test # API キーで保護されたサービスに対して実行 AUTH_TYPE=apiKey API_KEY=sk-live-abc123 API_BASE_URL=https://gateway.internal.example.com npm test これを整えれば、認証の強制そのものを検証する専用テストも追加できます。資格情報なしのリクエストが拒否されること、期限切れトークンが 401 を返すこと、不十分なスコープが 403 を返すことなどです。これらは Petstore のサンドボックスでは試せないものの、内部サービスではしばしば最も重要となるテストです。 Kiro ヘッドレスモードでテスト再生成を自動化する テストスイートを一度生成できるだけでも有用ですが、本当の価値は、API が進化しても両者を同期させ続けられる点にあります。 Kiro CLI のヘッドレスモード を使えば、CI/CD パイプラインから Kiro をプログラムで実行できます。ブラウザもインタラクティブな端末も不要です。API キーを環境変数として設定し、プロンプトを渡せば、Kiro が一連の処理をエンドツーエンドで実行します。 まとめ 本記事では、Kiro を使って Swagger 仕様から完全な Node.js API テストスイートを数秒で生成する方法を示しました。生成されるプロジェクトには、HTTP テストクライアント、Express のモックサーバー、モック API と実 API を切り替える設定トグル、テストレポートが含まれ、外部のテストフレームワーク依存はありません。 このアプローチは、API 仕様をテストコードに手作業で翻訳する手間を取り除き、包括的な API テストカバレッジを達成するための体系的で再現可能な方法を提供します。Swagger または OpenAPI 仕様を持つあらゆる API に同じパターンを適用できます。 Kiro を始めるには、 kiro.dev をご覧ください。 翻訳は Solutions Architect の吉村が担当いたしました。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 6 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋・広島に続き、2026 年 4 月 28 日は福岡にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、実際に社内への生成 AI 展開に取り組まれた企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：株式会社オーレックホールディングス様 〜「禁止から活用へ」中堅製造業の現場主導 AI 展開〜 事例紹介は 株式会社オーレックホールディングス 様です。福岡県八女郡広川町に本社を置く農業機械・草刈り機のメーカーで、グループ全体での従業員数は約 580 名、創業 1948 年の中堅企業です。乗用草刈り機の部門で国内トップクラスのシェアを持ち、フランスの農業機械ブランドの展開を含めグローバルに事業を展開されています。当日は AWS 木村がモデレーターを務め、経営本部 ソリューションシステム部の岡原 徹 様・月足 浩騎 様・次郎丸 雪衣 様に、実際に社内で進められている生成 AI の展開についてパネルディスカッション形式でお話しいただきました。 きっかけは、全社的な AI 活用の方針転換 お取り組みのきっかけは、2024 年 7 月、社長から「競争力強化のため、安全な環境で生成 AI を積極的に活用していこう」という方針が打ち出されたことでした。実は、オーレックホールディングス様は、生成 AI が話題になり始めた 2022〜2023 年頃、社内情報が外部に学習されることに対する懸念から、社員による生成 AI の利用を一律で禁じていた経緯がありました。しかしながら、生成 AI の活用が世の中的にどんどん広がる中で、「禁止しているだけでは取り残されて競争力が落ちてしまう」という認識に変わり、安全な基盤のもとで活用していこうという方針の転換を経て、AI 活用のプロジェクトが始まりました。 セキュアな基盤と、社員のリテラシー向上の両輪で AI 活用を推進するにあたり、同社が重視したのは 2 つの柱です。1 つ目は、セキュアな AI 基盤を社内に整備すること。2 つ目は、利用者となる社員の AI リテラシーを引き上げることです。ツールを配るだけでは、機密情報の意図しない入力や、AI のハルシネーションを鵜呑みにしてしまうといったリスクが残ります。安心して使える基盤の構築と、正しく使うための教育を同時に進める方針を立てました。 社内 IT 基盤のツールとして選定したのが、AWS が公開する OSS の生成 AI アプリケーション Generative AI Use Cases(GenU) です。選定の決め手は「セキュアに利用できること」と「スモールスタートできる価格設定」の 2 点でした。経営層の方々は、AI 活用の初期の段階から大きな投資をするのではなく、効果を見極めながら段階的な投資をしたいという考え方があったため、トークン単位の従量課金で、比較的安価に利用開始できる GenU がニーズに即していると考えました。また、GenU は、すぐ使えるユースケースがあらかじめ用意されていて、非 IT の担当者でも使い方のイメージが持てた点も選定のポイントになりました。選定から導入までスピード感を持って進め、2024 年 12 月末には導入を完了、運用をスタートさせることができました。 「触ってもらう」から始めた段階的展開 展開にあたって、社員の皆様に段階的に利用を開始してもらうアプローチを取りました。AI 活用の第一期生として、英文ライティングが多い海外営業部門、すでに個人的に生成 AI を使っていた社員を含む 56 名に AI のアカウントを配布しました。少人数で自由に AI を活用した業務課題解決を探索してもらうことで、ユースケースの発見を促すとともに、早期のリスクの洗い出しにもつなげる戦略を取りました。その後、効果が出てきたタイミングで、第二期生として部課長や開発部門など 35 名に追加配布、さらに希望者には都度配布…といったように、利用範囲を段階的に拡大しました。 アカウント配布と同時に、AI の勉強会を実施しました。AI の得意不得意、業務利用時の注意点、プロンプトの作り方の基礎を利用者部門に伝え、より効果的な活用を促しました。さらに、「利用者同士の座談会」を開催し、活用率の高い社員が日頃どのように使っているかをざっくばらんに話してもらう機会を設けたり、アンケートを通して横展開を支援したりなど、細やかなケアを続けていきました。 もう一つ、ユニークな取り組みとして、チャットボットの名前を公募で選定した点を挙げられました。全社員が親しみを持てるよう、 自社製品の乗用草刈り機「ラビットモアー」 にちなんでウサギのキャラクターを設定し、名前を公募しました。最終的に、「AI ちゃびっと」という名称で社内で親しまれるようになりました。今では名前とキャラクターが広く浸透、定着しています。公募という形にしたことで、社員が自分たちのプロジェクトとして参加意識を持てたことも浸透を後押しできたと考えています。 成果：全社員の 40% が自発的に使い始めた 現在の利用状況は、全社員の約 40 %にあたる 200 名が活用しています。そのうち 100 名以上は「自分で使いたい」と手を挙げて始めたメンバーです。当初想定していた文章作成や検索だけでなく、特許調査への組み込み、営業向けのプロンプトの定型化、法令チェック、温暖化係数の計算・ライフサイクルアセスメント解析といった、より専門的な業務での活用まで広がっています。方針が出た時点では社内のどの業務に AI を使えるかというイメージが全く持てなかった状態からのスタートでしたが、情報システム部が一つひとつユースケースを発掘するのではなく、現場が自分たちの課題に AI を当てはめて使い方を見つけてくれた結果でした。 一方で残る課題として、3 点を率直に話していただきました。1 点目はリソース不足で、他のプロジェクトとの兼ね合いで生成 AI の推進が後回しになりやすいこと、また同じ立場で AI 展開を進めている社内外の仲間が少ないこと。2 点目は効果測定の難しさで、AI 活用の成果を定量的に示す手段がまだ整っていないこと。3 点目は社員の皆様への継続的な AI の知見のアップデートです。業務ツールへの AI 組み込みが増える中、継続的な取り組みの重要性を語っていただきました。月足様からも、「AI が質問者に寄り添った回答をしてしまう」という特性があるため、AI のリスクを正しく理解し、最終判断はあくまでも人間が下すという姿勢を社内に根付かせていく必要性を語られました。 横展開を支えた「信頼の土台」 岡原様は、「普段からクロスファンクションでコミュニケーションを取っていて、工場にはデジタルサイネージを設置して IT 部門の活動を発信していた。『IT 部門に頼めば、きっと期待に応えてくれる』という、社員の皆様からの信頼の土台があったから、今回の横展開もうまくいった」と振り返られました。AI のプロジェクトが始まる前から積み重ねてきた地道な活動こそが、全社展開の推進力になった——この話は、参加者の皆様にとっても示唆の大きいポイントでした。 写真: 株式会社オーレックホールディングス 岡原様・月足様・次郎丸様、AWS 木村（営業）によるパネルディスカッション まとめ セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。「IT に詳しくない担当者が手探りで進めた」というリアルな話に共感の声が多く、「同じ悩みを持つ方と話せた」「自分たちだけじゃないと安心した」といった声をいただきました。製造業・中堅企業という条件の中でも、小さく始めて着実に広げていくアプローチが確かに機能することを示してくれたセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした福岡編に続き、次回は北海道編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。 先週末、6月25日、26日に AWS Summit Japan 2026 が開催されました。今年も多くのお客様にご来場いただき有り難うございました。生成AI、Physical AIに関する説明やデモが多く展示され、このブログの読者の皆様はイベントを楽しめて頂けたのではと思います。AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日のご参加が出来なかった方や、ご来場頂いた方で視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただければ幸いです｡ それでは 6月 22日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ「 店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み 」 店舗スタッフの気づきを AI が引き出して言語化し、本部に届けることを支援する AWS サンプルアセット「SMART（Store Manager Agent for Retail Tech）」と、それを活用したユナイテッドアローズの取り組みを紹介する記事です。本部が設定した「問い」を起点に AI が「なぜ」を深掘りし、対話を店舗名・日付・カテゴリといった構造化データに変換して、売上などの定量データと掛け合わせたインサイトを翌朝に届けます。ユナイテッドアローズでは、SMART をベースに Kiro を活用して内製でカスタマイズし、4 店舗で PoC を実施しました。「昨日の店舗がどうだったかを人に聞かなくても把握できる」「AI の深掘りでスタッフに考える習慣が広がった」といった声が寄せられ、本部側でも現場ヒアリングの時間削減や売上向上につながる気づきが得られたとしています。 ブログ記事「 Amazon Bedrock AgentCore での Web Search を発表: AI エージェントを最新かつ正確なウェブ知識に基づかせる 」 Amazon Bedrock AgentCore の Web Search が一般提供を開始しました。保護された AWS 環境からデータを外部に持ち出すことなく、出典が明示された最新のウェブ知識に基づいて応答を生成できるフルマネージドツールです。MCP（モデルコンテキストプロトコル）を使う Bedrock AgentCore Gateway の組み込みコネクタターゲットとして提供され、自然言語クエリに対して関連スニペット、ソース URL、タイトル、公開日を返します。標準的なウェブ検索に加えて Amazon Knowledge Graph も組み合わせるマルチソースグラウンディングを採用しているため、ウェブ検索のみの場合より関連性が高く正確な応答を得やすいとしています。外部の検索 API プロバイダーにユーザープロンプトや検索クエリを送らずに済むため、エンタープライズのガバナンス要件にも対応できます。米国東部（バージニア北部）リージョンで一般提供を開始しました。 ブログ記事「 より高速かつ正確なエンタープライズ AI アプリケーションを実現する Amazon Bedrock マネージドナレッジベースのご紹介 」 所有データを使ってエンタープライズグレードの生成 AI アプリケーションを数分で構築できる、Amazon Bedrock マネージドナレッジベースが発表されました。RAG パイプラインに必要なストレージ・検索・埋め込み・再ランキング・基盤モデルの選択を単一のマネージドプリミティブに抽象化し、デフォルトでサービスが各モデルを自動選択・管理するため、すぐに使い始められます。主な特長は 3 つです。Amazon S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive をサポートする 6 つのネイティブデータコネクタ、データタイプやコネクタに応じて最適な解析戦略を自動で選ぶ Smart Parsing、そして単一・複数のナレッジベースをまたぐマルチターン/マルチホップ検索に最適化された Agentic Retriever です。AgentCore Gateway の事前構築済みターゲットとして数行のコードで統合でき、ロールベースの権限が自動生成されます。米国東部（バージニア北部）、米国西部（オレゴン）、東京リージョンを含むアジアパシフィック（シドニー、東京）、欧州（ダブリン、フランクフルト、ロンドン）、AWS GovCloud（米国西部）で利用できます。 ブログ記事「 AWS DevOps エージェントで、本番前にコード変更を評価するためのリリース管理機能が追加 (プレビュー) 」 AWS DevOps エージェントに、本番前にコード変更を評価するリリース管理機能がプレビューで追加されました。デプロイ後の運用（インシデントの自律調査や根本原因分析）はすでに一般提供されており、今回はコード変更の「リリース準備状況レビュー」と「自律リリーステスト」が加わりました。リリース準備状況レビューは、自然言語で指定した社内標準やベストプラクティスに照らして変更を評価し、リポジトリ間の依存関係リスクや AWS Well-Architected に沿ったアクセスコントロールの確認、コミット前の破壊的変更の検出を行います。結果は「ブロック」「注意して続行」「安全にリリース可能」のいずれかで示され、コンソールや GitHub／GitLab のプルリクエストへのコメント、さらに Kiro パワーや Claude Code プラグイン経由で IDE から直接確認できます。自律リリーステストは、変更内容を推論して固有のテストプランを生成し、本番のような環境で実行します。米国東部（バージニア北部）リージョンで、プレビュー期間中は追加料金なしで利用できます。 ブログ記事「 AWS セキュリティエージェントで、脅威モデリング、Kiro パワー、Claude Code プラグインなどが追加 」 開発ライフサイクル全体でアプリケーションを保護する AWS セキュリティエージェントに、新しい機能が追加されました。コードレビューはプルリクエストスキャンに対応し、GitHub に加えて GitLab、Bitbucket、Confluence と連携できるようになりました。新たな脅威モデリング（プレビュー）は、設計ドキュメントやソースコードを分析してアプリケーションのアーキテクチャを理解し、STRIDE フレームワークで脅威を特定して緩和策を提示します。また、Kiro パワーと Claude Code プラグイン（近日リリース予定）、オープンな MCP 統合により、IDE や CLI から直接コードレビューや脅威モデル生成、検出結果の修正を行い、結果をインラインで確認できます。AWS セキュリティエージェントが利用できる AWS 商用リージョンで使え、2 か月間の無料トライアルが用意されています。 ブログ記事「 コーディングは不要 ― ビジネスユーザーこそが顧客体験の新たな設計者に 」 顧客体験（CX）の設計を、エンジニアではなく顧客を理解するビジネスユーザーが主導できるようにする、という考え方を記載した記事です。これまで CX 業務は「キュー（待ち行列）」を前提に運営され、ビジネス側が作りたい体験もエンジニアリングのチケット待ちがボトルネックになっていましたが、エージェンティック AI がこの制約を変えつつあるとしています。記事では、企業が正しく取り組むべき 3 点として、機能単位ではなく顧客ジャーニー全体を支える統合アーキテクチャ、決定論的な処理とエージェンティックな推論を同一のガバナンス下で共存させること、そしてビジネスユーザーに設計の主導権を渡すことを挙げています。あわせて、コード不要でエンドツーエンドの対話体験を視覚的に構築できる Agentic CX Designer（プレビュー）と、音声と画面表示をリアルタイムに同期する特許技術 Live Sync（プレビュー）を、Amazon Connect Customer の機能として紹介しています。また Saks Fifth Avenue でビジネスアナリスト主導で 6 週間での本番稼働を実現した例が示されています。 ブログ記事「 Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 」 Claude Code のような AI コーディングエージェントの利用状況を、Amazon CloudWatch と OpenTelemetry で可視化する手順を解説した技術記事です。CloudWatch の OpenTelemetry Protocol（OTLP）が一般提供となり、ベアラートークン認証でメトリクスを取り込めるようになったため、コレクターやサイドカー、開発者マシンでの IAM 認証情報の配線なしに、認可ヘッダー 1 つで CloudWatch へメトリクスを直接送信できます。記事では、CloudWatch メトリクス API キー（ベアラートークン）の作成から Claude Code 側の環境変数設定、メトリクスの確認、構築済みダッシュボードのデプロイまでを一通り示しています。ダッシュボードはトークン使用量、開発者の生産性、部門・チーム別のコスト配分、Amazon Bedrock API の健全性などを PromQL で可視化でき、個人の支出スパイクやチーム予算超過、利用減少を検知するアラート例も紹介されています。 ブログ記事「 Accelerating Smart Product SDLC with AI Agent Workshop のご紹介 」 IoT やコネクテッドデバイスの普及で「スマートプロダクト」へと進化する製造業向けに、組込みソフトウェア開発のライフサイクル全体（Research → Plan → Development → Release → Operation）で AI エージェントを活用するワークショップを紹介する記事です。コーディングだけを速くしてもライフサイクル全体のボトルネックは解消されない、という課題意識から、各フェーズ固有の壁を越えるアプローチを提案しています。生成AI を「制御可能・追跡可能・学習可能」な形で開発全域に組み込むことを狙いとしています。 ブログ記事「 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU で高速化された Amazon EC2 G7 インスタンスのご紹介 」を公開 AI 推論、グラフィックス、データ分析向けの Amazon EC2 G7 インスタンスが一般提供を開始しました。AWS は NVIDIA RTX PRO 4500 Blackwell Server Edition GPU をサポートする最初の主要クラウドプロバイダーで、第 6 世代のカスタム Intel Xeon Scalable プロセッサと組み合わせ、前世代の G6 比で最大 4.6 倍の AI 推論性能、最大 2.1 倍のグラフィックス性能を実現します。AI 推論やグラフィックスレンダリング、動画トランスコーディング、VDI、データ分析など幅広い用途に向きます。米国東部（オハイオ）、米国西部（オレゴン）の各リージョンで、オンデマンド、Savings Plans、スポットの購入オプションで利用できます。 Kiro関連 ブログ記事「 Kiro Web の Automations 機能のご紹介 」 ブラウザで使える Kiro Web に、クラウドで動作する Automations 機能が追加されました。依存関係の更新やドキュメントの追従、テストカバレッジの確認など、決まった間隔で繰り返し発生するタスクを Kiro に任せられます。Automations は自律型エージェントが管理し、実行ごとにサンドボックス内で autonomous セッションを作成して、完了すると自動でプルリクエストを開きます。設定は、タスクに名前を付けて GitHub または GitLab（両方も可）のリポジトリを選び、実行内容を記述してスケジュールを決めるだけです。1 つの Automation につき最大 5 つのスケジュールを設定でき、Daily・Weekly などの組み込みオプションのほか cron 式も使えます。古くなったドキュメントの更新、テスト未カバーのパスへのテスト生成、古い TODO／FIXME の整理といった使い方が示されています。 ブログ記事「 Kiro でテスト駆動開発（TDD）：こうあるべき体験 」を公開 テスト駆動開発（TDD）の利点は理解していても、テストと実装の往復や規律の維持、テストを書く単調さが負担になりがちです。この記事は、Kiro の hook（IDE の特定イベントで自動実行される仕組み）を使って、red-green-refactor サイクルを Kiro に徹底させることで、その負担なく TDD の恩恵を得る方法を紹介しています。ファイル保存前に発火する hook を作り、テストを先に書いて失敗（red）を確認してから最小限の実装（green）に進むよう Kiro に促す、という設定例が具体的なプロンプトつきで示されています。 ブログ記事「 Agent Focus のご紹介 」を公開 Kiro IDE に、エージェントとの対話を中心に据えた実験的な新ビュー「Agent Focus」が導入されました。やりたいことを説明し、会話で調整し、作業を開始して進捗を確認する、というチャットファーストの進め方を実現します。画面は 3 つのパネルで構成されます。新規セッションの作成やワークスペース別の状態（作業中・入力待ち・一時停止）を確認する Agents パネル、ファイル変更をインラインの差分で表示する Chat パネル、変更ファイルやスペック要約を必要時に表示する Auxiliary パネルです。複数セッションを並行して独立に動かせ、設定や powers、skills、MCP、ターミナル、直接のファイル編集など IDE 側の機能へもすぐ戻れます。最新の Kiro 1.0 に実装されており、使用するにはダウンロードページからの更新が必要です。 ブログ記事「 Kiro で OpenAPI／Swagger 仕様から数秒でテストスイートを生成 」 OpenAPI／Swagger 仕様（JSON または YAML）を入力すると、Kiro が Node.js のテストスイートを自動生成する手法を解説した記事です。スタブを埋める必要のある従来のコード生成ツールとは異なり、Kiro は仕様の内容を推論し、スキーマ契約に紐づくアサーションを備えた、実行可能なテストを生成します。生成されるのは単体テストではなく、axios で実際の HTTP リクエストを行う統合テストで、ローカルのモックサーバー（Express）と切り替えられる設定や、軽量なテストランナー、HTML レポートが含まれます。たとえば DELETE のテストでは、POST → DELETE → GET と連鎖させて削除後に 404 が返ることまで検証します。環境変数を変えるだけでライブ API に対しても同じテストを実行でき、認証付き API への適応や、 .kiro/steering/ のステアリングファイル、CLI のヘッドレスモードによる CI/CD への組み込みも紹介されています。 ブログ記事「 1 つのセッションで GitLab と GitHub にまたがる変更を調整する 」 Kiro Web が GitLab に対応し、既存の GitHub 対応と合わせて、両プロバイダーのリポジトリを 1 つのセッションに追加できるようになりました。1 つの変更を記述すると、Kiro が両方のリポジトリに反映し、GitLab 側にはマージリクエスト、GitHub 側にはプルリクエストを自動で作成します。コードが 2 つのプロバイダーに分かれていると、両方にまたがる変更で手順を忘れて同期がずれるリスクがありますが、Kiro が横断的に変更を調整することでこれを防ぎます。記事では、GitLab の非公開サービスと GitHub の公開 SDK に、エンドツーエンドで email フィールドを追加する例を紹介しています。Kiro Web はプレビュー版で、Pro、Pro+、Power のサブスクライバー向けに提供されています。 サービスアップデート Amazon Bedrock AgentCore Memory がクロスアカウントアクセスに対応 Amazon Bedrock AgentCore Memory が、クロスアカウントアクセスに対応しました。メモリリソースと、それを利用するエージェントが複数の AWS アカウントにまたがるマルチアカウント構成を組めるようになります。リソースベースのポリシーをメモリリソースにアタッチすることで、あるアカウントのプリンシパルに、別アカウントのリソースに対してメモリのデータプレーン API を呼び出す権限を付与できます。設定後は、利用側アカウントのプリンシパルが、完全なメモリ ARN を参照してイベントの作成、メモリレコードの書き込み・取得、セマンティック検索を実行できます。また、メモリの配信先（Amazon S3、Amazon SNS、Amazon Kinesis Data Streams）を別アカウントに置く構成も可能で、ペイロードの配信やイベントのストリーミングを他アカウントのリソースに対して行えます。Amazon Bedrock AgentCore Memory がサポートされるすべての AWS リージョンで利用できます。 Amazon Bedrock Guardrails の Automated Reasoning checks に新しいポリシー改善ワークフローが追加 Amazon Bedrock Guardrails の Automated Reasoning checks に、ポリシーを自動で改善するワークフローが追加されました。Automated Reasoning checks は形式論理を使って生成 AI の応答の正確性を、定義したポリシーに照らして数学的に検証する機能で、ハルシネーションの検出や検証可能な説明の提示に役立ちます。検証結果の質はポリシーの定義の良し悪しに左右されるため、今回の機能で手作業を減らしながらポリシーを改善できます。追加されたのは 2 つのワークフローです。反復的なポリシー改善ワークフローでは、ポリシー向けに自然言語のテストを作成したお客様が反復改善を実行し、それらのテストにパスするために必要な変更をシステムに導き出させられます。曖昧さ削減ワークフローでは、曖昧な変換結果が頻発する場合に、変数の説明や型定義を自動的に調整して曖昧な変換の発生を減らせます。Automated Reasoning checks が利用できるすべての AWS リージョンで使えます。 Amazon SageMaker Studio ノートブックが G7e インスタンスタイプに対応 Amazon SageMaker Studio ノートブックが、Amazon EC2 G7e インスタンスに対応しました。G7e は最大 8 基の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU（GPU あたり 96GB メモリ）と第 5 世代 Intel Xeon プロセッサを備え、最大 192 vCPU、最大 1600 Gbps の Elastic Fabric Adapter ネットワーキング帯域幅をサポートします。大規模言語モデル（LLM）やエージェント型 AI、マルチモーダル生成 AI、フィジカル AI モデルのデプロイに使え、空間コンピューティングや、グラフィックスと AI 処理の両方を要するワークロードで高い性能を発揮します。米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）の各リージョンで利用できます。 Amazon SageMaker ノートブックインスタンスが G6e インスタンスタイプに対応 Amazon SageMaker ノートブックインスタンスで、Amazon EC2 G6e インスタンスが一般提供されました。G6e は最大 8 基の NVIDIA L40s Tensor Core GPU（GPU あたり 48GB メモリ）と第 3 世代 AMD EPYC プロセッサを搭載し、EC2 G5 インスタンスと比べて最大 2.5 倍の性能を発揮します。モデルデプロイのインタラクティブなテストや、生成 AI のファインチューニングといったインタラクティブなモデル学習に利用でき、最大 130 億パラメータの大規模言語モデル（LLM）や、画像・動画・音声を生成する拡散モデルのデプロイに使えます。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、中東（ドバイ）、欧州（フランクフルト、スウェーデン、スペイン）の各リージョンで利用できます。 Kiro関連 Kiro が AWS GovCloud (US) で FedRAMP High および DoD IL-4/5 認証を取得 Kiro が、AWS GovCloud (US) リージョンで FedRAMP High および米国国防総省クラウドコンピューティングセキュリティ要件ガイド（DoD CC SRG）の Impact Level（IL）4 および 5 の認証を取得しました。これにより、FedRAMP High や DoD CC SRG IL-4/5 のコンプライアンス要件を持つ連邦機関や公共部門の組織、企業が、機密性の高いワークロードに求められるセキュリティ・コンプライアンス基準を満たした形で、Kiro をエージェント型の開発パートナーとして利用できます。 Kiro-CLI : 設定のホットリロードとリソース継承の制御 Kiro CLI 2.10 では、MCP まわりの繰り返し作業の手間を減らし、カスタムエージェントの作者にコンテキストの制御手段を提供します。エージェントと MCP の設定が、ディスク上で変更を保存するとホットリロードされるようになりました。エージェント設定の編集や新規エージェントファイルの追加、 mcp.json の変更が、セッションを再起動せずに反映されます。再起動するのは影響を受けたサーバーのみで、会話のコンテキストは保持されます。設定の差分は順序に依存しないため、環境変数を並べ替えても不要な再起動は起きません。また、新しい設定 chat.disableInheritingDefaultResources が追加されました。カスタムエージェントがデフォルトの steering、skills、AGENTS.md を継承しないようにする設定で、グローバルリソースを取り込みたくない場合に true にします。v2.7.0 以降、カスタムエージェントはデフォルトリソースを自動的に継承していましたが、この設定でその継承をオフにできます。 Kiro-CLI : V3 (Early Access) の安定性修正と Entra ID のセッション更新 Kiro CLI 2.9 では、Entra ID（Azure AD）ユーザーのセッション期限切れの問題を修正しました。あわせて、V3 (Early Access)における複合シェルコマンドの承認プロンプトのループを解消し、サブエージェント呼び出し向けにコンパクトなツールカードのプレビューを追加しています。 Kiro-IDE : Agent Focus、権限、カスタムエージェント、その他のアップデート Kiro IDE 1.0 では、複数の機能が追加されました。実験的機能の Agent Focus は、チャット中心のレイアウトで複数のエージェントを並行して操作でき、セッションは独立・並列に動作し、ファイル変更はインラインの差分で表示されます。Spec、Plan、Bug Fix、Quick Spec といった構造化ワークフローやフリーフォームのチャットから開始でき、従来の IDE とは右上からワンクリックで切り替えられて、作業内容は双方向に引き継がれます。 最後に、「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

この度、Amazon Quick on Desktop が AWS アジアパシフィック (東京) リージョンでプレビュー利用可能になりました。2026年3月の東京リージョンローンチに続き、4月にプレビュー公開されたデスクトップアプリケーションも東京リージョンに対応しています。これにより、日本のお客様はデータを国内に保持しながら、デスクトップ上でよりパーソナルでプロアクティブな AI アシスタント体験を実現できます。 “Amazon Quick on Desktop は、本ブログ投稿時点では Preview であり、機能・仕様が変更される場合がございます。”  Amazon Quick on Desktop とは Amazon Quick on Desktop は、Amazon Quick をブラウザの枠を超えてお使いのコンピュータにネイティブに展開するデスクトップアプリケーション (macOS / Windows 対応) です。ローカルファイルへの直接アクセス、OS レベルのプロアクティブ通知、バックグラウンドエージェント、ブラウザ自動化、パーソナルナレッジグラフ といった機能を備えています。 Quick on Desktop でできること ローカルファイルと直接連携 : チャットエージェントにアップロード不要で、許可したフォルダ内のファイルを読み書き・検索・インデックス化。ドキュメント作成やデータ分析もローカルファイルを直接参照して実行できます。 バックグラウンドエージェント : スケジュールに基づいて自動実行されるエージェントが、チャネル監視・メールトリアージ・ミーティング要約・インシデント追跡などを代行します。 プロアクティブ通知とアクティビティフィード : 接続サービスを監視し、重要な情報をデスクトップに通知。アクティビティフィードで優先度順に一覧表示します。 ブラウザ自動化 : Chrome を起動・制御し、Web フォーム入力、スクリーンショット取得、データ抽出、Web アプリとの連携を Quick に委任できます。 パーソナルナレッジグラフ : Slack メッセージ、メール、カレンダーなどの連携サービスおよびローカルファイルからエンティティと関係性を自動抽出し、あなた専用のナレッジグラフを構築。Quick の回答がよりユーザーに沿ったものとなります。 MCP サーバー接続 : Model Context Protocol (MCP) で外部ツールやコーディングエージェントと連携し、Quick の能力を拡張できます。 ドキュメント生成 : Word、Excel、PowerPoint などをチャットから直接生成できます。 ローカルファースト・アーキテクチャ Quick on Desktop は ローカルファースト・アーキテクチャ を採用しています。AI バックエンドはお手元のマシンで実行され、ファイルもローカルに留まります。ネットワーク通信は API Gateway 経由の AI モデル呼び出し と、 接続済みサービス (Slack, Outlook, Gmail 等) への通信 のみです。この設計により、プライバシーを保護しつつ Quick の機能を活用できます。 東京リージョン対応のメリット 1. 国内データレジデンシー データが日本国内の AWS インフラストラクチャに留まるため、個人情報保護法 (APPI) やお客様組織の内部ガバナンス要件を満たしやすくなります。 2. JP-CRIS による国内推論 JP-CRIS (Japan Cross-Region Inference) により、東京リージョンからの推論リクエストは 東京 (ap-northeast-1) と 大阪 (ap-northeast-3) の AWS リージョン内のみでルーティングされます。推論が日本国外で実行されることはありません。 3. 低レイテンシー 日本国内ユーザーのネットワークレイテンシーが改善され、AI 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。 最新アップデート Amazon Quick on Desktop は継続的にアップデートされています。 AWS Summit New York で発表された最新機能を含め、注目のアップデートをご紹介します。 Autonomous Agent — あなたの代わりに動き続ける AI Quick に Autonomous Agent（自律型エージェント） が追加されました。自然言語で目的を記述するだけで、バックグラウンドで継続的にタスクを実行するエージェントを作成できます（ 公式ブログ ）。 特徴: ノーコード作成 : 自然言語で目的を伝えるだけで作成可能。プリセットライブラリからの選択にも対応 柔軟な自律レベル : ステップバイステップの指示から、ゴールだけを与えてエージェントに判断させるモードまで選択可能 常時稼働 : ミーティング中や退席中でもバックグラウンドで動作し続ける ガードレール制御 : エージェントごとにガードレールを設定し、動作を制御 学習と改善 : やり取りや修正を通じてエージェントは時間とともに賢くなる Activity Feed — 1日の始まりをトリアージから解放 Quick Desktop の Activity Feed が大幅に強化されました。メール、メッセージング、カレンダー、タスクを 1つの優先度付きビュー に集約し、AI がトリアージを代行します。 特徴: 統合ビュー : メール、メッセージング、カレンダー、タスクを横断的に一元表示 AI によるプライオリティ付け : どのメッセージに素早く返信するか、どのスレッドをスキップするか、どのトピックが重要か判断 サマリーカード : 複数の関連メッセージを返信ドラフト付きの1枚のカードに要約 その場でアクション : 返信、転送、承認、委任をフィードから直接実行（アプリ切替不要） Skills & Agents カタログ 組み込みの スキル・エージェント・コネクタのカタログ がローンチされ、数クリックで導入・共有が可能に。営業、財務、マーケティング向けの 30 以上の準備済みスキルが用意されています。 Quick on Desktop の始め方 Amazon Quick on Desktop を始めるのは簡単です。 アカウント作成 : quick.aws.com で Free または Plus アカウントにサインアップします（AWS アカウント不要、メールアドレスのみで登録可能） アプリダウンロード : ダウンロードページ から macOS または Windows 版のデスクトップアプリケーションをインストールします フォルダ許可 : Quick にアクセスさせたいローカルフォルダを設定します サービス接続 : Slack、Outlook、Gmail 等のビジネスアプリケーションを接続します ナレッジグラフ構築開始 : 使い続けるほどコンテキストが蓄積され、よりパーソナライズされた体験になります エンタープライズ (Professional / Enterprise) アカウントのお客様は、IAM Identity Center による SSO 連携や、管理者によるエンタープライズデプロイも可能です。 エンタープライズセキュリティとガバナンス Quick on Desktop は、ローカルファーストの設計思想に基づきセキュリティとデータプライバシーを確保しています。 ファイルはローカルに留まる : Quick on Desktop はローカルファースト・アーキテクチャを採用しており、ファイルがクラウドにアップロードされることはありません。ユーザーが許可したフォルダのみアクセスし、いつでもアクセスを取り消せます。 ネットワーク通信は最小限 : ネットワーク通信は API Gateway 経由の AI モデル呼び出しと接続済みサービス (Slack, Outlook 等) への通信のみ。データがモデルのトレーニングに使用されることはありません。 エージェントのガードレール : Autonomous Agent にはエージェントごとに自律範囲を設定でき、意図しないアクションを防止します。 フォルダ単位のアクセス制御 : ローカルファイルへのアクセスはフォルダ単位で許可/取り消しが可能。キーワード検索、セマンティック検索、ナレッジグラフ抽出もフォルダ単位で制御できます。 東京リージョンでの JP-CRIS : AI モデルへの推論リクエストは東京・大阪リージョン内に閉じてルーティングされるため、データが日本国外に出ることはありません。 まとめ Amazon Quick on Desktop の東京リージョン対応により、日本のお客様はデスクトップ上でも Quick の AI アシスタントを活用しつつ、データ保全と低レイテンシーの恩恵を受けられるようになりました。ローカルファイルとの深い統合、プロアクティブな通知、パーソナルナレッジグラフ、そしてバックグラウンドエージェントによる自動化が、日々の業務を根本から変革します。 ぜひ Amazon Quick on Desktop をお試しください。

本ブログは東京電力エナジーパートナー株式会社 サービスソリューション事業部 今野拓也様の監修のもと、アマゾン ウェブ サービス ジャパン合同会社 橋井雄介が執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの橋井です。 電気・ガスなど大規模なインフラを提供する企業にとって、コンタクトセンターはお客さまとの重要な接点となっています。だからこそ、その体験の質が企業への信頼に直結します。「コンタクトセンターに生成 AI を導入したいが、大規模環境で実用的な精度が出るのか」「導入後に組織として使いこなせるのか」——そんな課題をお持ちの方に向けて、 Amazon Connect Customer （旧 Amazon Connect）と Amazon Bedrock を活用した変革を推進している東京電力エナジーパートナー様（以下、TEPCO EP）の事例をご紹介します。 TEPCO EP が取り組むコンタクトセンターの課題 TEPCO EP は、電力・ガスの小売事業を担い、全国複数拠点・数千席規模のコンタクトセンターでお客さまの契約手続きや問い合わせに対応しています。サービスソリューション事業部は「人 × IT の融合により、パーソナライズされたサポートを安心と感動とともに届ける」というビジョンを掲げ、CX 向上を推進しています。 同社のコンタクトセンターでは、デジタルチャネルの比率が向上する中でも電話が約 4 割を占めており、以下の課題がありました。 IVR（Interactive Voice Response: 自動音声応答）が複雑でオペレーターに繋がるまでの導線がわかりにくい オペレータースキルと用件のミスマッチが発生しやすい 応対後の処理負荷が大きく、保留や管理者へのエスカレーションも多い 利用システムが拠点ごとに異なり、会話データの横断的な活用が困難 今回、オンプレミス環境の保守期限を迎えてシステムを刷新するタイミングで、CX 向上と業務効率化を同時に実現するプロジェクト「 SEEDS（Smart Engagement and Efficient Data System） 」を立ち上げました。 図 1 受付チャネルの現状と課題 SEEDS Phase1 で実現したこと Phase1 では、Amazon Connect Customer をベースとした新たな受電環境を構築し、全国にある拠点のうち 18 拠点の切替を完了しました。 要件整理からリリースまで約 10 ヶ月、拠点切替は約 3 ヶ月で完了しています。できる限り標準機能を活用してスクラッチ開発を最小限にしたこと、生成 AI のチューニングやオペレーター画面の構成は検討開始後、早期から実際の挙動などを確認しながら段階的に精度を高めていくアプローチをとったことが、このスピードの鍵でした。 Phase1 で導入した主な機能は以下のとおりです。 音声テキスト化 : お客さまとオペレーターの会話をリアルタイムで文字表示（課題 3, 4 に対応） 会話要約 : 生成 AI が応対内容を自動要約し、オペレーターが利用するカスタム CCP（Contact Control Panel）画面に表示（課題 3 に対応） コールリーズン分析 : 通話内容から問い合わせ理由を自動分類し、データ活用を促進（課題 4 に対応） 法令チェック : オペレーターの説明漏れ等を生成 AI で全件自動チェック（課題 3 に対応） ダッシュボード : リアルタイムの応答状況や実績データを可視化（課題 4 に対応） 図 2 会話要約の活用イメージ 図 3 コールリーズン分析・法令チェックの活用イメージ 技術ポイント: 生成 AI の活用 ここからは、SEEDS の中で技術的にチャレンジングだった要素の一つとして、生成 AI の活用について掘り下げます。 アーキテクチャ設計 Amazon Connect Customer を中心に、 AWS Lambda と Amazon Bedrock を連携させた構成です（図 4）。生成 AI の処理を Amazon Connect Customer の外部に配置し Lambda から Amazon Bedrock を呼び出す設計としたのは、AWS マネージドサービスの中で多様な AI モデルを柔軟に活用できるためです。電力・ガス事業特有の表現や複雑な業務ルールに対応するプロンプトを自由に設計・改善できる柔軟性を確保することを重視しました。また、業界知識の深い実務担当者が単独でプロンプトの修正や評価を行える環境を別途用意し、プロンプトの更新の際には直接プログラムを改修せずにプロンプトファイルの差し替えで環境に反映できる構成としています。 なお、同様のユースケースに取り組むお客さまにとっては、Amazon Connect Customer の ビルトイン AI 機能 （会話要約やテーマ検出など、日本語を含む多言語に対応）を活用し、カスタム実装なしで実現するアプローチも選択肢となります。 図 4 SEEDS Phase1 アーキテクチャ構成（ダイジェスト版） この構成には、タスクの特性に応じて 2つの処理系統 を設けています。 リアルタイム系統（会話要約） : 終話後すぐにオペレーターへ結果を返す必要があるため、通話中にストリーミングされるリアルタイム通話テキストを入力とし、高速な応答が得られる Anthropic Claude Haiku（Amazon Bedrock 上で利用可能な軽量・高速モデル）で処理します。レスポンス性を最優先とした設計です。 バッチ系統（コールリーズン分析・法令チェック・VoC 抽出） : 後続の分析処理は翌営業日以降に行われるため、終話後に確定した完全な通話テキストを入力とし、より高い推論能力を持つ Claude Sonnet（同じく Amazon Bedrock 上で利用可能な高性能モデル）で処理します。処理結果の品質を最優先とした設計です。 いずれの系統でも、Amazon Bedrock の Tool use（関数呼び出し） 機能を活用し、出力を JSON スキーマに沿った構造化データとして取得しています。自由形式のテキスト出力をパースする方式と比較して出力形式の安定性が高く、後続のデータベース保存やダッシュボード連携を一往復の API 呼び出しで確実に完結させています。 なお、基盤モデルはリリース時点では Claude 3.5 Sonnet / Claude 3 Haiku を使用していましたが、2026 年からはパフォーマンスが向上した Claude Sonnet 4.5 / Claude Haiku 4.5 に更新しています。マネージドサービスの利点として、このようなモデルの進化を迅速に取り込むことができます。 各タスクの実装ポイント 会話要約 : 終話後カスタム CCP 画面へ要約を表示します。プロンプト開発時には現場のオペレーターにヒアリングを行い、業務用途を明確にした上で出力フォーマットに反映しました。現場からは 「箇条書きで簡潔に読める」「応対後の処理業務などの参考になる」 と評価されています。要約情報はオペレーター間の通話転送時にお客さま情報を引き継ぐ用途にも活用されているほか、お客さまの声（VoC）の自動抽出も実施し、従来人手で拾いきれなかった細かなニーズやご不満の声を網羅的に収集できるようになりました。 コールリーズン分析 : 64 分類での自動判定を実現し、約 600 件のテストデータで 網羅性 95%・正解率 85% と、目標を上回る精度を達成しました。精度向上の工夫として、生成 AI の出力に対してルールベースの後処理を組み合わせ、AI 単体では解消しにくい誤分類を補正しています。分類結果は呼量分析や呼量予測の精緻化に活用され、オペレーター配置計画の改善につながっています。 法令チェック : 従来はサンプリングによるモニタリングでしたが、生成 AI により低コストで自動実行が可能になったことで、 全件の AI 自動検知 を実現しました。検知ロジックでは、プロンプト内に判断フローを定義し、生成 AI が各ステップの判断根拠を出力しながら段階的に判定を進めます。これにより、複数の条件が絡み合う複雑なルールに対しても精度の高い検知を実現し、応対品質の向上とコンプライアンス遵守の両立を図っています。 生成 AI 活用を組織に定着させる TEPCO EP にとって、コンタクトセンター業務への生成 AI 適用は参考にすべき前例がほとんどない技術チャレンジでした。業務で適切に活用できる高精度なプロンプトを作成するには、生成 AI の特性を理解した上で 業務課題と正面から向き合う 必要があります。そこで段階的に AWS の支援を活用し、生成 AI 活用を目的化せず業務課題の解消を明確に目的設定するプロセスを重視しながら、組織にノウハウを蓄積していきました。 まず、プロジェクト開始前に構築ベンダーと AWS Prototyping Team の支援のもと POC を実施しました。サーバーレスサービスを活用して最小限の MVP 構成を素早く構築し、 実務担当者を含むステークホルダーに生成 AI の使用感を早期に体感 してもらえたことで、その後の要件定義に大きく役立ちました。 次に、各ユースケースの課題定義と実現方法の検討にあたっては、 AWS 生成 AI イノベーションセンター を活用しました。「何を」「どのレベルで」実現するかという タスク設定を技術的に明確化し、評価の枠組みを整えた ことで、後続のプロンプト開発を効率的に進める土台ができました。 続いてプロンプト作成・精度評価については、 AWS Professional Services と協力して進めました。支援の前半は AWS 主導でプロンプトを開発し、後半は TEPCO EP のメンバーが主体となってプロンプト修正と結果分析の試行錯誤を繰り返す形をとりました。 データ準備の重要性やプロンプト評価の手法 など、プロジェクト全体を通じて幅広い知見を得ることができ、この過程で実務担当者 11 名が生成 AI の特性を理解した上でプロンプトを設計・評価するスキルを習得しました。2025 年 12 月の Phase1 完了以降は、 実務担当者が単独で継続的な改善を行える体制 が構築されており、今回の取り組みにより生成 AI 活用の基盤を築くことができたと考えています。 Phase2: よりエージェンティックなコンタクトセンターへ Phase1 で得られた知見をもとに、TEPCO EP では Phase2 としてさらに高度な AI 活用を推進します。Phase1 では主に課題 3・4（応対後の処理負荷、データ活用）にアプローチしましたが、Phase2 では課題 1・2（IVR の複雑さ、スキルミスマッチ）の解消にも踏み込みます。目指すのは「 オペレーター自己完結化 」、すなわちオペレーターが必要な情報に迅速にアクセスでき、応対に集中できる環境の構築です。 TEPCO EP が検討している具体的な取り組みは以下の二つです。 一次応対の自動化 : 従来の IVR を廃止し、自然な会話形式でお客さまの用件を聞き取り、適切なスキルを持つオペレーターに振り分けます。Phase1 で培ったコールリーズン分析の知見を活用し、お客さまが用件に合った窓口へスムーズに到達できるようにすることで CX 向上を図ります。 オペレーターのリアルタイム支援 : お客さまとの会話内容をリアルタイムに分析し、関連するナレッジや手続き情報を自動的に表示します。応対後の後処理についても、登録内容の自動入力や手順ガイドを提供することで、保留や管理者へのエスカレーションを削減し自己完結率を高めます。 これらの実現に向けて、技術的な選択肢を補足します。Amazon Connect Customer では Agentic AI 機能が大幅に強化されており、たとえば一次応対の自動化には自然言語による会話ボット機能が、オペレーター支援にはリアルタイムナレッジ検索やステップバイステップのガイド提供機能が、それぞれ活用できます。Phase1 で構築した Amazon Connect Customer 基盤の上に、これらの機能を段階的に追加していくアプローチが可能です。 図 5 Amazon Connect Customer の Agentic AI 機能概要 まとめ TEPCO EP の事例から、実務担当者が中心となった CX 改善の取り組みにおける重要なポイントを整理します。 CX を起点に技術を選定する : 業務課題を明確にし、それを解決する手段としてクラウドと生成 AI を位置づける マネージドサービス中心のシンプル構成 : 標準機能の活用で開発スピードと保守性を両立し、モデル更新も迅速に取り込む 実データで試行し段階的に精度を高める : 生成 AI のチューニングは実データで検証し、精度と実用性のバランスを追求する スキルを組織に定着させる : プロンプトチューニングや精度評価のスキルを内製化し、自走での改善体制を構築する コンタクトセンターの CX 向上や、Amazon Connect Customer と 生成 AI の活用にご興味のあるお客さまは、お気軽に AWS までご相談ください。 著者について 今野 拓也 東京電力エナジーパートナー株式会社 サービスソリューション事業部 副部長 2007 年東京電力入社。オール電化推進営業、顧客向け Web サイト企画・構築を経て、2019 年より新サービス関連業務・システム構築に従事。2020 年に AI コンタクトセンター（AICC）構築を担当。2025 年よりコール・チャット等運営の統括責任者として新規音声基盤の企画・構築を推進し、現在はサービスソリューション事業部 副部長としてシステム全体統括および SEEDS プロジェクト PM を務める。 橋井 雄介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト エネルギー・ユーティリティ業界を担当するソリューションアーキテクト。お客さまのクラウド活用と生成 AI 導入を技術面から支援している。

このBlog postは Open Governance for MySQL: A Step Forward for the Community の日本語訳です。 MySQL — 世界中の数百万のアプリケーションを支えるオープンソースデータベース — が新たな章を開きます。本日、Oracleは、より広範なコミュニティがプロジェクトの開発と方向性に参加するための道筋を作る、 MySQLのコミュニティガバナンスモデルを発表 しました。 このポストでは、AWSがこの動きを支持する理由と、MySQLコミュニティにとっての意味を説明します。 オープンガバナンスがオープンソースを機能させる 多様なコントリビューターと透明性のあるガバナンスを持つオープンソースプロジェクトは、より良いソフトウェアを生み出します。オープンガバナンスは、ユーザーからコントリビューター、そしてリーダーへの明確な道筋を示し、組織がプロジェクトの将来にエンジニアリングリソースなどを投資するを自信を与えます。 MySQLは約30年にわたり、インターネットインフラストラクチャの基盤となってきました。スタートアップから世界最大の企業まで、数十万の企業が最も重要なワークロードをMySQL上で実行しています。コミュニティの参加方法を明確化することで、その基盤が強化され、MySQLの利用者が将来を見据え、ビジネスを構築するための判断材料に役立ちます。 新しいガバナンスモデルの仕組み OracleがMySQLを買収して以来初めて、Oracle以外の組織がエンジンの構築方法と方向性において定義された役割を持つことになります。このモデルは、役割の段階を作ります：コントリビューターがコードと修正を提出し、コミッターが変更をレビューして承認し、プロジェクトリードがオプティマイザーやInnoDBなどの主要サブシステムを所有します。 これらの役割の上に、MySQLの長期的な方向性とリリースポリシーを設定するステアリングコミッティがあります。コミッティには、Oracle以外から4つの席があり、クラウドプロバイダー、MySQLの顧客、オープンソースコミュニティが占め、Oracleが過半数を持ちます。Oracleが最初のメンバーを2年の任期で指名し、その後、Oracle以外の席はコミュニティによる投票により決定されます。 これらすべてを支えるため、これまで存在しなかった外部コラボレーションとコントリビューションのためのチャネルとして、OracleはMySQLコミュニティのためのパブリックGitHubを立ち上げました。 AWSがこれを支持する理由 AWSは15年以上にわたり、ユーザーとして、コントリビューターとして、そしてMySQLに依存するサービスの構築者として、MySQLに深く投資してきました。今日、数万のお客様がAWS上でMySQLワークロードを実行しています。MySQLは私たちのエコシステムで最も重要なデータベースの一つであり、お客様はその長期的な健全性に直接的な利害関係を持っています。 AWSでは、オープンソースはすべての人にとって良いものであると信じており、オープンソースの価値をお客様に、そしてAWSの運用上のオペレーショナルエクセレンスをオープンソースコミュニティにもたらすことにコミットしています。そのコミットメントはシンプルな形で現れます：お客様がAWS上でオープンソースデータベースを実行して問題に遭遇した場合、私たちはアップストリームに対してMySQLを利用するすべてのユーザのために修正に取り組みます。 私たちにはまさにこれらを行ってきた実績があります。PostgreSQLでは、VACUUMを6倍高速化し、アップグレード時にレプリケーションスロットを維持し、autovacuum設定変更の再起動要件を削除しました。LinuxFoundationによるRedisのフォークであるValkeyでは、全文検索とハイブリッドクエリサポートを追加しました。そして、大量のテーブルを持つデータベースのアップグレード時のメモリ不足エラーの修正やヒストグラムエラーの修正など、MySQL自体にもすでにアップストリームに対し修正を貢献しています。 健全なアップストリームプロジェクトは、MySQLに依存するすべての人に利益をもたらします — 自ら運用する人、マネージドサービスを活用する人、またはそれらのシステムにツールや統合を構築する人。より多くのエンジニアがコードをレビューすれば、より多くのバグが発見されます。設計上の決定がオープンに行われれば、リリースされる機能はより幅広い実世界のユースケースを反映します。ガバナンスが透明であれば、組織はコントリビューションが評価され、声が聞かれるという自信を持ってプロジェクトに投資できます。 これは理論ではありません — OpenJDK、Valkey、その他数十のプロジェクトで、幅広い参加がソフトウェアをより良く、コミュニティをより強くした経験です。 私たちはMySQLにもそれを望んでいます。 MySQLコミュニティにとっての意味 このガバナンスモデルは、ユーザー、コントリビューター、エコシステム全体にとって、プロジェクトの長期的な健全性のシグナルです： 品質とセキュリティへのより多くの目 — コミッター、プロジェクトリード、コンポーネント横断的な監視による構造化されたレビュープロセスにより、コードがリリースされる前に、より多くのエンジニアが正確性、パフォーマンス、セキュリティを検証します。 より速いイノベーショ ン — 明確なコントリビューションパスとパブリックなコラボレーションにより、より広範なエコシステムが改善を提案し提供するための障壁が低くなります。 プロジェクトの将来への自信 — Oracle、エンドユーザー、オープンソースコミュニティからの代表を含むステアリングコミッティにより、MySQLの方向性は単一のベンダーだけでなく、それに依存する利用者の利益を反映します。 継続性と互換性 — ガバナンスモデルは、安定性、後方互換性、リリース品質を明示的に優先します。ユーザーとオペレーターは、破壊的な変更を心配することなく改善を採用できます。 より強力なアップストリームプロジェクトは、MySQL上に構築されたすべてのもの — マネージドサービス、セルフホストデプロイメント、ツール、そしてより広範なエコシステム — のより強力な基盤を意味します。 今後の展望 AWSはMySQLステアリングコミッティに席を持ち、プロジェクトのロードマップとリリース決定に直接的な発言権を持っています。私たちは、MySQLを利用しているお客様のためにその発言権を使うつもりです。 AWSは長期にわたってオープンソースコミュニティに貢献しており、お客様のワークロードに最も直接的な影響を与える分野でMySQLプロジェクトに積極的に関与しています： パフォーマンス — 実際のワークロードの実行速度を決定するエンジンの部分に焦点を当てています：クエリオプティマイザー、クエリ実行、インデックス作成、InnoDBストレージエンジン、およびその下のキャッシュレイヤー。 ベクトル検索とインデックス作成 — オープンソースデータベースのベクトル機能を強化してきたAWSの経験が、コミュニティ全体の共同作業に基づいて、MySQLの新しいベクトルサポートに貢献しています。 拡張フレームワーク — MySQLのコンポーネントインフラストラクチャにより、新しい機能はコアサーバーコードに組み込まれるのではなく、定義されたサービスインターフェースを通じて接続するロード可能なコンポーネントとしてリリースできます。これはコミュニティコントリビューションに最もオープンな分野の一つであり、ここに投資する予定です。 これらは、私たちがすでに行っているアップストリームへの貢献の上に構築されています。数十万のお客様のミッションクリティカルなワークロードを実行することで、MySQLの多くのユーザーに影響する実際の問題 — 正確性、安定性、信頼性の問題 — が表面化し、GitHubを通じてコミュニティ全体のための修正に取り組んでいます。 要点はシンプルです：MySQLの開発がオープンになり、AWSはその方向性を形作る席を持ち、すでにアップストリームで修正と改善の貢献をしています。お客様はMySQLをどこで実行してもこれらの恩恵を受けることができます。 Get involved MySQLエコシステム全体の開発者、ユーザー、組織の皆様に、ガバナンスモデルを読み、どのように参加したいかを検討することをお勧めします。オープンソースは人々が参加することで成長します — そしてこのモデルにより、コントリビューションがこれまで以上に簡単になります。 Read Oracle’s announcement Read the Governance model Pravin Mittal Pravin Mittal is Director of Engineering for Amazon Aurora at AWS, where he leads teams building managed MySQL and PostgreSQL services for hundreds of thousands of customers. He represents AWS on the MySQL Community Steering Committee.

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

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

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

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

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