Amazon Web Services ブログ

Amazon Quick on Desktop が東京リージョンに対応 – AWS Summit New York 2026 アップデート –

Hiroaki Hattori — Fri, 26 Jun 2026 05:47:48 +0000

この度、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 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。

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 をお試しください。

著者について

Hiroaki Hattori

Amazon Web Services Japan G.K. の AI Specialist Solutions Architect で、日本における全テリトリーの Amazon Quick を担当している。サウナは 1 ローテが Quick には終わらず、Strong スタイルで楽しんでいる。

CX向上に向けたコンタクトセンター変革 — 全国複数拠点・数千席規模の環境で挑む東京電力エナジーパートナーの Amazon Connect Customer × 生成 AI 活用

Yusuke Hashii — Fri, 26 Jun 2026 05:11:21 +0000

本ブログは東京電力エナジーパートナー株式会社サービスソリューション事業部今野拓也様の監修のもと、アマゾンウェブサービスジャパン合同会社橋井雄介が執筆いたしました。

みなさん、こんにちは。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 導入を技術面から支援している。

Open Governance for MySQL: A Step Forward for the Community

Yutaka Hoshino — Fri, 26 Jun 2026 00:56:56 +0000

この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

フルライフサイクル制御を備えた分離サンドボックスの実行：AWS Lambda が MicroVMs を導入

Micah Walter — Thu, 25 Jun 2026 07:25:51 +0000

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 Summit Japan 2026 : Physical AI – Spatial Computing 関連展示の紹介

Akinori Hiratani — Thu, 25 Jun 2026 00:40:50 +0000

こんにちは。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 公式サイト

AI が経営するお店で買い物しませんか？ — AWS Summit Japan 2026 Builders’ Fair で「Living Mart」体験

Saneyuki Nishigame — Wed, 24 Jun 2026 16:04:41 +0000

こんにちは。ソリューションアーキテクトの原田、鈴木、西亀です。

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 とロボット。趣味はボルダリングで、オフィスにあるボルダリングウォールにトライしています。

AWS Summit Japan 2026 ブース紹介 — 生成 AI 時代の製品設計開発

Koji Yamada — Wed, 24 Jun 2026 07:27:14 +0000

みなさんこんにちは。ソリューションアーキテクトの山田です。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東京の写真選定業務効率化システムを Amazon Aurora DSQL で実現

Momoko Asai — Wed, 24 Jun 2026 07:01:42 +0000

はじめに

株式会社 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 ライブエクスペリエンス事業本部企画推進部エンジニアリング支援グループ
數藤智幸氏

AWS Summit Japan 2026 ブース紹介ソフトウェア定義型ファクトリー

Mickaël Charneau — Wed, 24 Jun 2026 06:12:48 +0000

こんにちは、ソリューションアーキテクトのシャルノミカエルです。

本記事では、2026 年 6 月 25 日（木）と 26 日（金）の 2 日間、幕張メッセで開催される AWS Summit Japan 2026 のブース予告をお届けします。製造業に関する展示は AWS Expo 内の AWS for Industries です。このブログでは、その中から「ソフトウェア定義型ファクトリー」と題して、ソフトウェア PLC とコーディングエージェントで工場制御の開発を変革するテーマについてご紹介します。

製造業関連の全ブース紹介はこちらのブログ記事をご覧ください。

このブースで体験できること

工場の設備を動かしているのは PLC (Programmable Logic Controller) です。ロボット、コンベア、バルブなど、あらゆる設備が PLC の制御ロジックに従って動作しています。PLC はリアルタイム制御と安定性に優れる一方で、ロジックの変更には特殊なスキルセットを持つ技術者が必要であり、変更のリードタイムは長く、コストも多大です。

さらに深刻なのは、検証を本番設備でしか行えないという制約です。変更のために生産ラインを長時間停止するか、小さな変更を小分けにして少しずつ適用するしかなく、結果としてビジネスニーズの変化に追従できない・・・これが多くの製造現場の実情です。

このブースでは、物理 PLC をソフトウェア PLC に置き換え、AI コーディングエージェントとシミュレーション環境を組み合わせることで、工場制御の「開発体験」を根本から変える取り組みの成果をご紹介します。実際のミニチュアファクトリーとシステム構成を展示し、どのようなプロセスで制御ロジックの変更を実現したかをご覧いただけます。

物理工場 (左) と仮装工場 (右)

アーキテクチャー図

このブースの注目ポイント

ソフトウェア PLC と Structured Text (ST) コードによるソフトウェア開発ライフサイクル（SDLC）の実現 : 制御ロジックをラダーロジックから構成管理しやすい ST コード化し、バージョン管理・ロールバックを可能にします。これにより、ソースコード、デプロイメント、セキュリティを AWS で一元管理できます。
AI コーディングエージェントによる制御ロジックの自動生成 : 開発者が自然言語でやりたいことを伝えると、コーディングエージェントが既存のソースコードを解析し、修正案を提案・適用します。これにより、従来は熟練者が数時間〜数日かけていた制御変更を、対話だけで実現します。
シミュレーション環境での事前検証 : クラウド上に PLC プログラムと工場設備を動かす仮想シミュレーション環境を構築し、本番適用前にリスクなく検証します。これにより、IaC（Infrastructure as Code）でオンデマンドに立ち上げ、コストを抑制します
CADデータ活用による学習レス外観検査 : Amazon Nova を活用し、事前学習なしで外観検査を実現。これにより、CADデータから生成した形状をリファレンスモデルとして使用し、実物との差異を検出

展示の概要

本ブースでは、ミニチュアファクトリーと実際のシステム構成を展示し、以下の一連のプロセスをご紹介します。

ステップ 1：課題の発見

「生産ラインの未来」ブースでは、需要増による生産性向上の要求に応えるために AI エージェントが設備から収集されたデータの分析を行い、生産ラインのボトルネックを解消する改善案を導き出します。本ブースでは、その改善案を実際に制御ロジックへ実装する後続のプロセスをご紹介します。

ステップ 2：コーディングエージェントによる制御ロジックの実装

改善案（例：商品によって倉庫に入れるのではなく、直接加工ラインに流す分岐を追加する）を、コーディングエージェントで実装します。

開発者が自然言語で意図を伝えます
ソフトウェア PLC プログラムの開発環境である CODESYS の MCP サーバー機能経由でプロジェクトのソースコードを解析
ソースコードの修正を提案し、承認後に適用できます

ステップ 3：シミュレーション環境での検証

修正されたプログラムをいきなり本番に適用するのではなく、クラウド上の NVIDIA Isaac Sim によるシミュレーション環境で動作を検証します。

Isaac Sim 内のファクトリーモデルは、実際のソフトウェア PLC から本番と同じ Modbus/TCP で制御されています。PLC 上では本番と同一のプログラムが動作しており、シミュレーション環境側の動作プログラム（PLC との Modbus 通信連携部分）は Python で AWS に AI コーディングエージェントである Kiro を使って実装しました。なお、クラウドとのシミュレーション連携のために TCP ベースのプロトコルを選定しています。

実環境の物理現象を完全に再現することは非常に難しく、シミュレーションは一定の再現性にとどめています。それでも、制御ロジックの大部分の問題を本番適用前に発見できるため、開発サイクルの大幅な短縮につながります。

ステップ 4：フィードバックとイテレーション

コーディングエージェントの出力は、最初から完璧とは限りません。シミュレーション検証で不具合が見つかった場合は、ステップ 2 に戻り追加の指示を出します。たとえば今回の開発では、「奥のオーブンにパーツを持っていっても扉が開かない」「青と判定される前に自動倉庫が入荷モードに動いてしまい、キャンセル処理が漏れる」といった問題がシミュレーションで発覚し、エージェントに追加修正を依頼して解消しました。このように、エージェントとの対話を繰り返しながら素早くイテレーションできるのが、ソフトウェア定義型ファクトリーの大きな利点です。

ステップ 5：本番環境での検証と適用

この工場環境は本番環境もソフトウェアPLCを採用しているため、そのまま、シミュレーションで十分に検証を重ねたプログラムを、物理環境のソフトウェア PLC にダウンロードし、本番環境での最終検証を行います。事前に仮想環境で多くの問題を解消しているため、本番環境での検証は短期間で完了でき、従来よりも質の高いオートメーションの変更を迅速に提供できます。

物理構成

ソフトウェア PLC: WAGO 社製 Industrial PC 上で CODESYS 社のソフトウェア PLC が動作
通信プロトコル: Modbus/TCP で WAGO 社製リモート IO と連携
リモート IO: WAGO 社製リモート IO がモーター・バルブ・センサーを制御
ミニチュアファクトリー: Fischertechnik 社製の学習用ファクトリーモデルを使用

使用している AWS サービス

Amazon Bedrock: コーディングエージェントの推論基盤（LLM バックエンド）
Amazon Nova: CADデータを活用した学習レス外観検査
Amazon EC2: ソフトウェア PLC および CODESYS 開発環境の実行基盤
Amazon ECS: NVIDIA Isaac Sim の実行基盤（GPU を活用したコンテナベースのシミュレーション環境）
AWS IoT Greengrass: エッジデバイスとクラウドの接続

AWS を活用するメリット

シミュレーション環境の柔軟な提供: IaC でオンデマンドに立ち上げ、必要な時だけ利用しコストを抑制
最新 GPU の提供: シミュレーションに必要な最新 GPU インスタンスをすぐに利用可能
豊富な LLM の選択肢: Amazon Bedrock を通じて工場の制御開発に適した LLM を選択可能
ソフトウェア開発のベストプラクティスを工場に適用: バージョン管理、CI/CD、ロールバックなど、ソフトウェア開発で培われた手法を工場の制御開発にも展開

まとめ

「ソフトウェア定義型ファクトリー」ブースでは、工場の制御をソフトウェアとして扱うという新しいパラダイムの成果をご覧いただけます。ソフトウェア PLC × AI コーディングエージェント × クラウドシミュレーションの組み合わせにより、従来数時間〜数日を要していた制御変更のサイクルを劇的に短縮し、工場を安全かつ継続的に進化させることができます。

AWS Summit Japan 2026 の AWS for Industries ブースにて、ぜひ実物のミニチュアファクトリーとシステム構成をご覧ください。皆さまのご来場をお待ちしております！

著者について

Mickaël Charneau (シャルノミカエル)

AWS とパートナーのソリューションを元に、自動車と製造のお客様の業務の効率化とデジタルトランスフォーメーションをサポートしているソリューションアーキテクトです。

AWS Config を使用したポスト量子暗号 (PQC) 対応の自動化

中島章博 — Wed, 24 Jun 2026 03:57:57 +0000

本ブログは 2026 年 5 月 14 日に公開された AWS Blog “Automating post-quantum cryptography readiness using AWS Config” を翻訳したものです。

TLS エンドポイントをポスト量子暗号 (PQC) に移行する際は、まず現在の TLS エンドポイントのインベントリと状態を把握することから始めます。本記事では、PQC Readiness Scanner を紹介します。これは Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon API Gateway のエンドポイントをインベントリ化し、PQC 対応の観点から TLS 設定を継続的に監視する自動化ツールです。スキャナーは各エンドポイントを 3 階層フレームワークに分類し、PQC 移行の優先順位付けと計画立案を支援します。

量子コンピューティングの進展に伴い、データを長期的に保護するには耐量子暗号への移行が必要になります。PQC Readiness Scanner を使用すると、どのエンドポイントから移行すべきかを特定し、アカウント全体での進捗を追跡できます。ウェブトラフィックでは、PQC 鍵交換アルゴリズムは TLS 1.3 内でのみネゴシエートされます。つまり、耐量子接続を実現するには、TLS 1.3 と PQC 鍵交換をサポートするエンドポイントが必要です。

AWS 責任共有モデルのもとで、AWS はインフラストラクチャを保護し、各サービス全体で PQC サポートを実現します。一方、お客様は PQC 対応の TLS ポリシーを使用するようにリソースを設定する責任を担います。Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon API Gateway、Amazon CloudFront など、AWS が TLS 接続を終端するケースでは、お客様がセキュリティポリシー (リスナーがサポートする TLS プロトコルバージョンと暗号スイートを定義する AWS マネージドの設定) を選択します。このポリシーによって、TLS バージョンと暗号スイート、鍵交換、認証アルゴリズムのサポート範囲が決まります。

AWS が TLS を終端するエンドポイント向けに自動化された PQC Readiness Scanner は、AWS Config コンフォーマンスパックを使用して構築されています。コンフォーマンスパックとは、AWS Config ルールと修復アクションをまとめたもので、アカウントとリージョン内の単一エンティティとして、または AWS Organizations の組織全体にデプロイできます。

ソリューションの概要

PQC Readiness Scanner は、コンフォーマンスパックを使用して AWS Config ルールをデプロイし、各エンドポイントのセキュリティポリシーを評価します。評価結果に基づいて、各リソースは 3 階層フレームワークに分類され、PQC 対応の TLS を実現するために必要な移行アクションの優先順位が付けられます。

PQC Readiness Scanner は、リソースごとに次の 2 つのチェックを実行します。

エンドポイントが PQC 対応のセキュリティポリシーを使用しているか
エンドポイントがレガシーの TLS 1.0 または 1.1 をサポートしているか

各チェックは COMPLIANT または NON_COMPLIANT のステータスを、具体的なポリシー推奨事項とともに返します。

PQC では、エンドポイントが TLS 1.3 をサポートし、PQC 鍵交換アルゴリズムを使用する必要があります。3 階層フレームワークは、検出結果の解釈と修正の優先順位付けに役立ちます。目標は、エンドポイントで PQC 鍵交換を有効にした TLS 1.3 を使用することです。ただし、これを実現するにはクライアントとの下位互換性を維持する必要があります。

ティア	対応レベル	TLS プロトコル	PQC ステータス	移行優先度
ティア 1	PQC 対応 (最も強固な状態)	PQC 鍵交換を使用する TLS 1.3 のみ	PQC 対応	なし
ティア 2	PQC 対応 (下位互換性あり)	PQC 鍵交換を使用する TLS 1.2 および 1.3	PQC 対応	低
ティア 3	PQC 非対応	PQC 鍵交換なし	PQC 非対応	高

移行の優先順位付け方法

ティア 1 は、PQC 鍵交換を使用する TLS 1.3 のみを使用する、最も強固なセキュリティを表します。これらのリソースは既に目標状態を満たしています。
ティア 2 は、下位互換性のある PQC 対応の構成を表します。エンドポイントは TLS 1.2 と TLS 1.3 の両方をサポートし、PQC 鍵交換は TLS 1.3 接続でネゴシエートされます。これらのリソースは、TLS 1.3 をサポートするクライアントに対して既に耐量子保護を提供しつつ、レガシークライアント向けに TLS 1.2 互換性を維持しているため、移行優先度は低くなります。クライアント側の分析によって、接続するクライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることが確認できたら、ティア 1 に移行してください。
ティア 3 は、PQC 非対応のリソースを対象とします。これには、TLS 1.3 をサポートしていないエンドポイントや、TLS 1.3 はサポートしているが PQC 鍵交換ポリシーを持たないエンドポイントが含まれます。これらのリソースには早急な対応が必要です。

評価範囲

このスキャナーは、お客様のアプリケーションに代わって TLS 接続を終端する、次の AWS エッジサービスを評価します。

エッジサービス:
- HTTPS、TLS、TCP SSL プロトコルを使用する Application Load Balancer (ALB)、Network Load Balancer (NLB) のリスナーが評価対象です。
- API Gateway REST API は AWS リージョンエンドポイントとプライベートエンドポイントが評価され、あわせて API Gateway HTTP API (v2) と WebSocket API (v2) も評価されます。
評価対象外のエッジサービス:
- CloudFront ディストリビューションは PQC 対応の評価範囲から除外されます。これは、ビューワーからエッジへの接続について、既存の CloudFront TLS セキュリティポリシー全体でハイブリッドポスト量子鍵交換を使用する TLS 1.3 が自動的に有効になっているためです。CloudFront のインバウンド (ビューワー向け) PQC については、お客様による対応は不要です。
Classic Load Balancer の推奨アプローチ:
- Classic Load Balancer については、AWS は ALB または NLB への移行を推奨します。Classic Load Balancer は TLS 1.3 または PQC 鍵交換をサポートしておらず、PQC 対応にすることはできません。

ソリューションの仕組み

AWS Config によって、継続的な監視と評価が可能になります。コンフォーマンスパックを使用すると、組織全体へのデプロイが可能になります。AWS Lambda は、AWS Config ルールに基づいてセキュリティポリシー評価を行うコードを実行するサーバーレスコンピューティングサービスです。AWS サーバーレスアプリケーションモデル (AWS SAM) は、AWS Lambda 関数のデプロイに使用するオープンソースフレームワークです。

図 1: PQC 対応ソリューションのアーキテクチャ

PQC Readiness Scanner コンフォーマンスパックは、2 つの Lambda 関数によって動作する 4 つのカスタム AWS Config ルールを実装します。

ルール	チェック内容	非準拠の結果
ELB PQ-ready	ロードバランサーのリスナーが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか	ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます
ELB legacy TLS	ロードバランサーのリスナーが TLS 1.0 または 1.1 接続を許可しているか	レガシープロトコルが設定されている場合、リソースにフラグが付けられます。
API Gateway PQ-ready	API Gateway エンドポイントが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか	ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます
API Gateway legacy TLS	API Gateway エンドポイントが TLS 1.0 または 1.1 を許可しているか	レガシープロトコルが設定されている場合、リソースにフラグが付けられます。

前提条件

このソリューションをデプロイする前に、次のものが必要です。

適切なアクセス許可を設定した AWS コマンドラインインターフェイス (AWS CLI)
aws configure aws sts get-caller-identity # Verify
Python 3.12 がインストールされていること。Lambda ランタイムにはこのバージョンが必要です
python3 --version # Should show 3.12.x
AWS SAM CLI がインストールされていること (インストールガイド)
pip install aws-sam-cli # Verify sam --version
対象の AWS リージョンで AWS Config が有効になっていること
- 次のリソースタイプを記録するように設定する (アカウントがデフォルトですべてのリソースを記録している場合、このステップは不要です)
  - AWS::ElasticLoadBalancingV2::LoadBalancer
  - AWS::ApiGateway::RestApi
  - AWS::ApiGatewayV2::Api
- AWS Config コンソール → Recorder → Recording Strategy → Select specific resource types から有効にします (特定のリソースタイプ向けの AWS Config 記録戦略については、手動セットアップの手順に従ってください)

PQC Readiness Scanner のデプロイ手順

PQC Readiness Config Scanner は 3 つのフェーズに分けてデプロイします。完全なデプロイコマンドと設定の詳細は GitHub リポジトリで確認できます。コンフォーマンスパックは Lambda 関数の ARN をパラメータとして参照するため、Lambda 関数を最初にデプロイする必要があります。詳細は GitHub リポジトリを参照してください。

シングルアカウントへのデプロイ

クローンとビルド:

git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git

cd sample-PQC-Readiness-using-AWS-Config/installation

sam build

1 つ以上のリージョンへのデプロイ:
# Make script executable (first time only) chmod +x deploy-per-regions.sh # Deploy to a single region ./deploy-per-regions.sh us-east-1 # Deploy to multiple regions ./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1
図 2: これらのリソースに対して AWS Config 記録を有効にしているか、デフォルトですべてのリソースを記録している場合は、y を入力して続行します
このスクリプトは、次の処理を自動的に行います
- SAM を介して Lambda 関数をデプロイ
- コンフォーマンスパックをデプロイ (Config ルールを作成)
- デプロイの成功を検証
- 明確なステータスメッセージを提供

このデプロイにより、PQC 対応およびレガシー TLS のチェックを実行する 2 つの Lambda 関数が作成されます。ELB、ALB、NLB、API Gateway の describe オペレーション用に、最小権限のアクセス許可を持つ IAM ロールがプロビジョニングされます。Lambda アクセス許可により、AWS Config が関数を呼び出せるようになります。

図 3: デプロイ成功時の画面の例

マルチアカウントデプロイ (Organizations)

複数の AWS アカウントにまたがる組織全体のデプロイには、CloudFormation StackSets を使用して各アカウントに Lambda 関数をデプロイします。

重要な制約: AWS Config の CUSTOM_LAMBDA ルールでは、Lambda 関数が Config ルールと同じアカウント内に存在する必要があります。1 つのアカウント内に集約した Lambda を使用して、他のアカウントのリソースを評価することはできません。

前提条件: 共有 S3 バケット

パッケージ化の前に、組織内の各ターゲットアカウントからアクセスできる S3 バケットを作成します。このバケットには、CloudFormation StackSets が各メンバーアカウントに取り込む Lambda デプロイアーティファクトをホストします。

# Create the shared S3 bucket (run from management/central account)
aws s3 mb s3://<your-org-shared-bucket> --region us-east-1

次のいずれかのオプションを使用して、ターゲットアカウントに読み取りアクセス権を付与します。

aws s3api put-bucket-policy \
  --bucket <your-org-shared-bucket> \
  --policy '{
    "Statement": [
      {
        "Sid": "BucketOwnerFullAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::<bucket-owner-account-id>:root"
        },
        "Action": "s3:*",
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      },
      {
        "Sid": "CrossAccountReadAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": [
            "arn:aws:iam::<account-id-1>:root",
            "arn:aws:iam::<account-id-2>:root"
          ]
        },
        "Action": ["s3:GetObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      }
    ]
  }'

<account IDs> は、StackSets が Lambda 関数をデプロイする AWS アカウント ID に置き換えてください。

注: バケットは StackSet のデプロイリージョンと同じリージョンに配置する必要があります。マルチリージョンデプロイの場合は、リージョンごとに 1 つのバケットを作成し、各リージョンに対して sam package を個別に実行します。

ステップ 1: Lambda パッケージのビルドと S3 へのアップロード

installation/ ディレクトリからパッケージ化スクリプトを実行します。

cd installation

# Make script executable (first time only)
chmod +x deploy-stacksets.sh

# Build, package, upload to S3, and generate resolved template
./deploy-stacksets.sh <your-org-shared-bucket>

このスクリプトは、次の処理を自動的に行います。

SAM を使用して Lambda 関数をビルド
ZIP パッケージを作成
ZIP を共有 S3 バケットにアップロード
S3 の値が組み込まれた packaged-template.yaml を生成 (デプロイ時にパラメータは不要)

図 4: Lambda パッケージが S3 バケットに正常にアップロードされたときのサンプルスクリプト出力

ステップ 2: StackSets を介した Lambda 関数のデプロイ

管理アカウント (または委任管理者アカウント) から、次のコマンドを実行します。

# Create StackSet (--region sets the StackSet "home region" where it is managed)
aws cloudformation create-stack-set \
  --stack-set-name pqc-readiness-lambda-functions \
  --template-body file://packaged-template.yaml \
  --capabilities CAPABILITY_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --region us-east-1

# Deploy stack instances to member accounts
# --regions = target regions where Lambda functions are deployed in member accounts
# --region  = must match the StackSet home region above
aws cloudformation create-stack-instances \
  --stack-set-name pqc-readiness-lambda-functions \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1 \
  --region us-east-1

重要 — StackSet ホームリージョンとデプロイリージョンの違い:

--region (各 CLI コマンド) = StackSet リソースが存在する StackSet ホームリージョン。後続のオペレーション (describe、update、delete) では、これと同じリージョンを指定する必要があります。
--regions (create-stack-instances 上) = メンバーアカウントにスタックインスタンスが作成されるデプロイ先のターゲットリージョン
これらは独立した値です。CLI のデフォルトリージョンへの意図しないデプロイを避けるため、--region を明示的に指定してください。

注: SERVICE_MANAGED StackSets は、管理アカウントまたは委任管理者アカウントから作成する必要があります。管理アカウント自体はスタックインスタンスのデプロイから除外されます。管理アカウントでスキャナーが必要な場合は、deploy-per-regions.sh を別途使用してください。

ステップ 3: 組織コンフォーマンスパックのデプロイ

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pqc-legacy-tls-compliance \
  --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml

これにより、各メンバーアカウントに、ローカルの Lambda 関数を参照する Config ルールが作成されます。

移行のガイダンスと優先順位付け

3 階層フレームワークは、PQC 移行の優先順位を提供します。

高優先度 – ティア 3 (PQC 非対応):

対象: PQC サポートのないリソース。これには、PQC 対応のセキュリティポリシーを使用していないエンドポイントや、依然として TLS 1.0 または 1.1 を許可しているエンドポイントが含まれます。
アクション: 名前に PQ を含む PQC 対応のポリシー (たとえば -PQ-2025-09 で終わるもの) にアップグレードします (完全なリストは Elastic Load Balancing セキュリティポリシーのドキュメントを参照してください)。
重要: PQC 対応のポリシーにアップグレードする前に、クライアントの TLS バージョンを監査してください。PQC 対応のポリシーには TLS 1.3 のサポートが必要です。TLS 1.2 以前のみをサポートするレガシークライアントは、接続のネゴシエーションに失敗します。まずティア 2 の下位互換性のあるポリシー (TLS 1.2 と 1.3 の両方を PQC とともにサポート) から始め、TLS ネゴシエーションの失敗がないか接続ログを監視します。クライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることを確認してから、ティア 1 の TLS 1.3 のみのポリシーに移行してください。
リスク: エンドポイントが転送中のデータに対してポスト量子暗号をサポートしていません。レガシー TLS プロトコルは、現在の暗号攻撃に対して脆弱です。

低優先度 – ティア 2 (PQC 対応、下位互換性あり):

対象: TLS 1.3 + PQC 対応のポリシーを使用し、下位互換性のために TLS 1.2 もサポートするリソース
アクション: クライアント互換性の分析によって、接続するクライアントが TLS 1.3 をサポートしていることが確認できた場合、TLS 1.3 のみのポリシーを検討します。
リスク: 最小限です。これらのリソースは、TLS 1.3 接続で既に PQ-TLS をサポートしています。TLS 1.2 以前へのフォールバックは下位互換性を維持しますが、これは一部のクライアントが PQ-TLS でネゴシエートしていない可能性を示しているかもしれません。修復策としては、ログを監視してこれらの接続数とクライアント数を特定し、これらのクライアントが TLS 1.3 と PQ-TLS を使用するように移行計画を立てます。

対応不要 – ティア 1 (PQC 対応、最適な構成):

対象: PQC 鍵交換を使用する TLS 1.3 のみを使用するリソース。これらのリソースは目標状態を満たしています。移行は不要です。

結果の表示

各メンバーアカウントで、デプロイしたリージョンの AWS Config コンソールに移動します。

コンフォーマンスパックビュー

AWS Config → コンフォーマンスパックに移動し、次を探します。

OrgConformsPack-pqc-legacy-tls-compliance-

注: 組織コンフォーマンスパックには OrgConformsPack- というプレフィックスが付き、ランダムなサフィックスが追加されます (例: OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0)。

図 5: PQC コンフォーマンスパックのコンプライアンススコアは、準拠しているルールとリソースの数の割合です

コンフォーマンスパックをクリックすると、4 つすべてのルールにわたる全体的なコンプライアンス概要を確認できます。

個別ルールビュー

AWS Config → ルールに移動し、プレフィックス pqc- が付いた 4 つのルールを見つけます。

pqc-elb-pqc-compliance-conformance-pack-
pqc-elb-legacy-tls-conformance-pack-
pqc-apigateway-pqc-compliance-conformance-pack-
pqc-apigateway-legacy-tls-conformance-pack-

任意のルールをクリックすると、次を表示できます。

準拠リソースと非準拠リソースの数
各リソースの詳細な注釈
リソース ARN と現在のセキュリティポリシー設定

図 6: コンフォーマンスパック内の Config ルールステータスの可視化

図 7: 3 階層フレームワークに基づく移行ガイダンスを記述した Config ルールの検出結果と注釈のサンプル画像

まとめ

PQC Readiness Scanner をデプロイすると、AWS エッジサービス全体の TLS 状態を可視化でき、手動の設定レビューを削減できます。ティアシステムは具体的なアップグレード推奨事項を提供するため、チームは暗号の専門知識がなくても次のステップを把握できます。スキャナーは設定変更を自動的に検出し、新しいデプロイが対応基準を維持できるように支援します。組み込みの AWS Config レポート機能は監査要件をサポートし、PQC 対応に向けた測定可能な進捗を示します。

PQC Readiness Scanner をデプロイし、PQC Readiness Scanner で結果を確認してください。高優先度のティア 3 リソースから移行を開始し、AWS Config アグリゲーターを使用して、アカウント全体の進捗を監視してください。

追加リソース

GitHub リポジトリ: PQC Readiness Config Scanner
AWS Config ドキュメント: Lambda を使用したカスタムルール
AWS SAM ドキュメント: サーバーレスアプリケーションモデル
PQC 移行計画: NIST ポスト量子暗号標準
PQC 移行計画: AWS ポスト量子暗号移行計画

この記事に関するご質問がある場合は、AWS Config re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

Amazon Web Services ブログ

Amazon Quick on Desktop が東京リージョンに対応 – AWS Summit New York 2026 アップデート –

Amazon Quick on Desktop とは

Quick on Desktop でできること

ローカルファースト・アーキテクチャ

東京リージョン対応のメリット

1. 国内データレジデンシー

2. JP-CRIS による国内推論

3. 低レイテンシー

最新アップデート

Autonomous Agent — あなたの代わりに動き続ける AI

Activity Feed — 1日の始まりをトリアージから解放

Skills & Agents カタログ

Quick on Desktop の始め方

エンタープライズセキュリティとガバナンス

まとめ

著者について

Hiroaki Hattori

CX向上に向けたコンタクトセンター変革 — 全国複数拠点・数千席規模の環境で挑む 東京電力エナジーパートナーの Amazon Connect Customer × 生成 AI 活用

TEPCO EP が取り組むコンタクトセンターの課題

SEEDS Phase1 で実現したこと

技術ポイント: 生成 AI の活用

アーキテクチャ設計

各タスクの実装ポイント

生成 AI 活用を組織に定着させる

Phase2: よりエージェンティックなコンタクトセンターへ

まとめ

Open Governance for MySQL: A Step Forward for the Community

オープンガバナンスがオープンソースを機能させる

新しいガバナンスモデルの仕組み

AWSがこれを支持する理由

MySQLコミュニティにとっての意味

今後の展望

Get involved

フルライフサイクル制御を備えた分離サンドボックスの実行：AWS Lambda が MicroVMs を導入

AWS Summit Japan 2026 : Physical AI – Spatial Computing 関連展示の紹介

ブース A160：SDMA で繋ぐ現実世界とAIシミュレーション

Physical AIを支える3Dアセット管理基盤を体験

こんな方におすすめ

展示内容

補足 : Spatial Data Management on AWS (SDMA) とは

デモ 1. 自律走行車両

概要

強化学習の仕組み

シミュレーション環境の構成

SDMA によるシミュレーション環境の自動生成

新しいシミュレーション環境の利用

デモ 2. 自律飛行ドローン

概要

強化学習の仕組み

シミュレーション環境の構成

SDMA による障害物の配置

新しいシミュレーション環境の利用

システムアーキテクチャ

利用している AWS サービス・ソリューション

その他技術要素

活用ユースケース

ブース情報

まとめ

AI が経営するお店で買い物しませんか？ — AWS Summit Japan 2026 Builders’ Fair で「Living Mart」体験

なぜ「AI が経営する店」を作ったのか

Living Mart とは

マルチエージェント — 役割を分担する

ハーネス — 「お願い」ではなく「仕組み」で動かす

私たちの賭け — Bitter Lesson に従う

会場で体験できること

AI が経営するお店で実際にお買い物

当選すると AI デザインのオリジナルステッカーをプレゼント

動いている様子を、リアルタイムで覗けます

裏側の仕組み

AWS Summit Japan 2026 でお会いしましょう

著者について

AWS Summit Japan 2026 ブース紹介 — 生成 AI 時代の製品設計開発

コンセプト : 生成 AI 時代の製品設計開発

1. Engineering Development Hub（ EDH )

EDH の主な特徴

EDH のユースケース

EDH のリソース他

2. 設計開発の現場ですぐに実践できる生成 AI ユースケース

生成 AI × CAD + CAE + NVIDIA Isaac による フィジカル AI シミュレーション

CX向上に向けたコンタクトセンター変革 — 全国複数拠点・数千席規模の環境で挑む東京電力エナジーパートナーの Amazon Connect Customer × 生成 AI 活用

生成 AI × CAD + CAE + NVIDIA Isaac によるフィジカル AI シミュレーション

AWS Summit Japan 2026 ブース紹介ソフトウェア定義型ファクトリー

Mickaël Charneau (シャルノミカエル)