みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 9月に入り暑さもだいぶ和らいできましたね。秋の気配を感じる今日この頃ですが AI 関連サービスに多数の熱いアップデートが発表されております。また、今週の builders.flash では、9 月 2 日に生成 AI 関連の記事が 6 本公開されました。実際に動く仕組みの裏側を知りたい方は、ぜひご覧ください。 CAD の知識ゼロでも AI エージェントと自然言語で 3D モデリング — AWS Summit Japan 2026 展示の裏側 FreeCAD MCP サーバーを Kiro に接続し、自然言語の指示から 3D モデルを設計・出力する方法を紹介しています。CAD の専門知識がない方が、AI エージェントとオープンソースツールを組み合わせる際の入り口になります。 5人の AI 審査員が議論して優勝者を決める ! AWS Summit Japan 2026 Builders’ Fair「大喜利 Dojo」の裏側 Amazon Bedrock で回答生成と画像 OCR を行い、Amazon Bedrock AgentCore 上の 5 人の AI 審査員が採点・議論・投票する展示の構成を解説しています。AI エージェント同士の役割分担を体験に落とし込む例として楽しめます。 コードは一行も書かない。AI にタスク整理を任せる仕事術 ~ Amazon Quick のデスクトップアプリで始めるタスク自動管理 Amazon Quick のデスクトップアプリを使い、Slack、メール、カレンダーなどに分散したタスクを AI エージェントに見つけさせ、To-Do に整理する方法を紹介しています。定期実行と通知までコードなしで組み立てる実例です。 Amazon 社員 3.9 万人の日常業務を支える AI エージェント Kiro Crew の使い方大公開 ブラウザや Slack などから常駐実行できる Kiro Crew の活用例を紹介しています。Outlook の未読メール整理、定期ジョブ、メモリ、Skills を組み合わせ、判断は人に残したまま探す作業を自動化する考え方が参考になります。 AWS DevOps Agent の「スキル」を使いこなそう カスタム Skills とマネージド Skills の違い、発動条件となる説明文の書き方、調査時間を短縮する手順を解説しています。調査結果からエージェント自身に新しい Skill を作らせる運用方法も紹介されています。 「AI 現場監督『安全ヨシ！』」― AI に見守られながら作業する、フィジカル AI 時代のエッジ × クラウド エッジ上の視覚言語モデルで作業の前後関係を読み取り、リアルタイムに危険を警告し、Amazon Bedrock で記録全体を再監査・採点するデモを紹介しています。現場の安全支援とクラウド側の評価を分担する設計が見どころです。 それでは、8 月 31 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 2026年8月31日の週の主要なアップデート さまざまなニュース 「フィジカル AI 開発支援プログラム by AWS ジャパン」最終成果発表会を開催しました AWS ジャパンが 51 社を採択して約 6 か月支援したプログラムの最終成果発表会です。13 プロジェクト・14 社が、ロボットの動作データ、シミュレーション、GPU 学習、現場実証の成果を紹介しました。ZEALS 様の病院実証、FastLabel 様のシミュレーションデータ拡張、メルカリ様の検品自動化など、日本の現場技術と生成 AI を組み合わせる具体例が並んでいます。 2 週間で 12 万人規模へ – NEC が Claude Desktop on Amazon Bedrock で実現したセキュアな全社 AI 環境 NEC 様は、全社員が使える Claude Cowork の環境を、要件定義から全社リリースまで 2 週間で構築しました。Amazon Bedrock 経由で推論とデータを国内に閉じ、監査証跡やコスト管理も整備。2026 年 8 月 18 日時点で 11,000 名が利用しており、今後は AI エージェントの本番活用へ拡張する計画です。 AI-DLCで取り払った組織の壁 ― DeNAと取り組んだ分析業務領域での初事例 DeNA のヘルスケア事業部門にある DeSC ヘルスケア様は、分析企画部とデータサイエンス部など 24 名で 3 日間の AI-DLC Unicorn Gym に取り組みました。AI に要件定義書作成や集計を任せながら部門間の認識をそろえ、共有された Claude Code の Skills は 5 か月間の 1 件から、その後 2 か月で 6 件に増加。次は AI-BPR へ取り組みを広げています。 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 手袋を外せない、騒音が大きい、レシピ変更が属人化するといったセントラルキッチンの課題に、AmiVoice と Amazon Bedrock AgentCore Runtime、Strands Agents を組み合わせました。調理スタッフは音声でレシピを進め、在庫を減算し、タイマーや工程メモを操作できます。Amazon DynamoDB と AWS Lambda に記録が蓄積され、現場の改善にもつながります。 【開催報告】AI エージェントは創薬研究をどう変えるか: 製薬企業向け Claude Code on AWS ワークショップ 10 社以上の製薬企業が参加したワークショップで、調査・分析から Web アプリケーションの構築までを Claude Code で実践しました。アンケートの総合満足度は 4.70 / 5.00。第一三共様では 92% の研究員が利用の影響を実感し、ＪＣＲファーマ様ではイベント体験から約 10 日で Amazon Bedrock 経由の環境をリリースしています。 構造化されたビジネスロジックとエージェンティック AI を組み合わせ、心地よい会話体験を届ける Amazon Connect Customer の agentic CX designer を使い、自然な会話や意図理解はエージェンティック AI に、本人確認やクレジット適用など正確さが必要な処理は決定論的なロジックに分担させる方法を紹介しています。REST と MCP の連携、テスト、ビルド、ロールバックまで一貫して設計する際の参考になります。 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 画像生成 AI による企画、Kiro と Blender による 3D モデリング、Design Doc と Steering を使ったクラウドアプリケーション開発を紹介しています。Mock-first 設計で実機がなくても開発を進め、短期間で展示を統合したプロセスを確認できます。 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 Amazon Bedrock AgentCore 上の AI エージェントが判断し、AWS IoT Core 経由で ROS 2 / MoveIt 2 のエッジ制御へ指示を渡す構成を解説しています。シミュレーション、安全制約、実機の検証を組み合わせ、Summit の 2 日間で障害物ピックを失敗ゼロにした考え方が学べます。 AWS Skill Builder で AI 駆動開発ライフサイクル (AI-DLC) を学ぼう: 日本語版学習コースが公開されました AWS Skill Builder に、AI-DLC の基礎からインセプション、コンストラクションの Deep Dive までを扱う全 8 モジュールの日本語コースが公開されました。無料で自分のペースで学べ、修了後の Assessment に合格するとナレッジバッジを取得できます。AI ツールを個別導入するだけでなく、開発プロセス全体を変えたい方に向いた教材です。 サービスアップデート サービスアップデート – エージェント基盤と Amazon Bedrock エージェントの検出とガバナンスを一元化する AWS Agent Registry の一般提供を開始 AWS Agent Registry が一般提供となり、組織内のエージェント、ツール、Skills、MCP サーバーなどを検索・統制するプライベートカタログとして利用できます。CloudFormation、Terraform、CDK、タグ、AWS RAM 共有、AgentCore の自動検出にも対応しました。既存の機能を見つけて再利用しやすくなります。 AWS Agent Registry のエージェントと MCP サーバーが Amazon Quick で利用可能に Amazon Quick から組織のレジストリにあるエージェントや MCP サーバーを検索し、接続情報を手入力せず数クリックで有効化できます。東京を含む Quick と AgentCore の提供リージョンが対象で、技術チームとビジネスユーザーの連携を簡単にします。 Anthropic の新しいフロンティアモデル Claude Fable 5.1 が AWS で利用可能に Claude Fable 5.1 が一般提供され、コーディング、科学研究、エンタープライズワークフロー向けの長時間タスクを扱えるようになりました。コードベース全体の作業やレビューを進め、行き詰まりを成功と誤報したり失敗テストを無効化したりする近道も抑えます。Amazon Bedrock と Claude Platform on AWS から利用できます。 Claude Fable 5.1、Anthropic の新しいフロンティアモデルが AWS GovCloud (US) で利用可能に Claude Fable 5.1 が規制産業向けの AWS GovCloud (US) にも提供されました。Covered Model として追加のデータ保持・安全性レビュー・アクセス制御の対象となり、Enterprise Frontier Safeguards によって顧客が管理するクラウド環境内にデータを保持して利用できます。 Amazon Bedrock Managed Knowledge Base が ServiceNow をネイティブデータソースコネクタとしてサポート ServiceNow のナレッジ記事やサービスカタログ、添付ファイルをクロールするネイティブコネクタが追加されました。メタデータ抽出と増分同期に対応し、対象ナレッジベースやカテゴリを sys ID で絞り込めます。社内 IT や HR のアシスタントを構築しやすくなります。 Amazon Bedrock Managed Knowledge Base が SharePoint、OneDrive、Confluence のデータソース向けユーザー管理セットアップを導入 既存のサードパーティー認証情報でサインインする 3LO 方式が追加されました。管理者に 2LO 用のサービスアカウントを用意してもらわなくても、SharePoint、OneDrive、Confluence のデータを数分で接続して試作できます。 Amazon Bedrock Managed Knowledge Base がデータソースコネクタの自動同期スケジュールをサポート ネイティブコネクタに日次・週次・月次の同期を設定できるようになりました。頻繁に変わるナレッジは日次、規程は週次、参照資料は月次というように、データの更新頻度に合わせて RAG の鮮度を保てます。 Amazon Bedrock の Web Search が AWS GovCloud (US-West) で利用可能に OpenAI GPT モデルが Web 情報を参照して回答をグラウンディングし、利用した出典を返す組み込みツールが GovCloud に広がりました。IAM で利用可否やリージョンを管理でき、リクエストデータを AWS 境界内に保ったまま、最近の出来事や最新リリースなど変化する情報を扱えます。 サービスアップデート – Amazon SageMaker AI と GPU Amazon SageMaker Unified Studio CI/CD がノートブックの昇格と AI 支援マニフェスト生成を追加 プロジェクトの接続、ストレージ、ワークフローを調べてデプロイ用マニフェストを生成する Agent Skill が加わりました。最小権限や環境変数を適用し、Notebook も開発・テスト・本番へ昇格できます。データチームが環境ごとの設定を手作業で整える負担を減らします。 Amazon SageMaker Unified Studio Workflows が Python および Bash オペレーターをサポート サーバーレスワークフローのキャンバスから Python 関数やシェルコマンドを直接実行できるようになりました。データ変換やスクリプト処理のために、別途 Lambda や ECS の実行環境を用意する必要を減らせます。既存のワークフローに処理を追加しやすくなるアップデートです。 Amazon SageMaker AI Batch Transform が G6e インスタンスをサポート 最大 8 基の NVIDIA L40S GPU を搭載する G6e を、永続エンドポイントを必要としない大規模バッチ推論に利用できます。S3 のデータセットに対して LLM や画像・動画・音声の拡散モデルを実行でき、米国、ムンバイ、ハイデラバードなどで提供されます。GPU を使うオフライン推論の選択肢が増えました。 サービスアップデート – Amazon Quick と Amazon Connect Amazon Quick で自然言語によるカスタムアプリケーションの構築が可能に 作りたいアプリケーションを自然言語で説明するだけで、Salesforce、Jira、Asana、ServiceNow、Microsoft 365 などのデータと接続した業務アプリを作成できるようになりました。既存の ID・認可・アクセス制御を引き継ぎ、データの変更も反映します。コードを書かずに、分断された表計算やツールを目的別アプリへ変えたい業務部門に適しています。 Amazon Connect Customer が agentic CX designer の一般提供を開始 ノーコードのキャンバスで、自然な会話や意図理解を AI に任せつつ、本人確認、承認、ルーティング、コンプライアンスなどは決定論的なステップで固定できます。設計、テスト、デプロイを同じ場所で行えるため、ビジネス部門がエンジニアリングへの引き渡しを待たずにセルフサービス体験を改善できます。東京を含む 9 リージョンで利用可能です。 Amazon Quick がコネクタ向けの新しいツール設定と Model Context Protocol (MCP) 同期を追加 管理者はコネクタ内の個別ツールを有効・無効化し、同意が必要な操作も設定できるようになりました。MCP サーバー側のツール追加や説明更新も同期されるため、承認済みの能力だけを提供しながら最新状態を保てます。 Amazon Quick Max を導入: Quick を最大限に活用したいパワーユーザー向けに利用量を 5 倍に Plus の 5 倍の利用量とストレージを持つパワーユーザー向けプランです。複数のエージェントやワークフローを同時に動かす利用者が、月途中の利用制限を気にせず Quick を活用しやすくなります。 サービスアップデート – その他の生成 AI 活用 Amazon WorkSpaces Applications が NVIDIA Blackwell GPU インスタンスのサポートを追加 Graphics G7 で NVIDIA RTX PRO 4500 Blackwell を利用でき、従来世代の G6 と比べて最大 2.1 倍のグラフィックス性能を発揮します。CAD、3D、科学可視化、動画編集、AI 支援設計などを高いフレームレートでストリーミングしたいチームに向いた選択肢です。 AWS MCP Server が AWS Lambda 関数向けのサーバーレス機能を追加 Claude Code や Kiro から、Lambda と API Gateway、EventBridge、S3、DynamoDB、SNS、SQS、Step Functions の接続関係をまとめて調査できます。7 日間の基準値との比較、エラー傾向、デプロイ設定、変更履歴、レイテンシを 1 回の呼び出しで確認でき、調査時のトークン消費も抑えます。追加料金なしで利用可能です。 AWS Transform が Amazon FSx for NetApp ONTAP の一般提供を開始 コンピュートやネットワークと同じ移行ウェーブで、ブロックストレージを FSx for NetApp ONTAP へ移行できるようになりました。中間ストレージや別ツールを組み合わせる工程を減らし、移行ワークフローを一本化できます。エージェントを活用した移行自動化を検討する際の対象範囲も広がります。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。3 つのコースから選べて、AWS クレジットの付与や技術支援も用意されています。ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が実施する「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。お客様のニーズに合わせ、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマイズコース」、公開モデルによるビジネス課題解決を狙う方向けの「モデル活用コース」をご用意しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2026 年 8 月 27 日に開催されました。2024 年 11 月の 第 1 回 、2025 年 2 月の 第 2 回 、2025 年 4 月の 第 3 回 、2025 年 8 月の 第 4 回 、2025 年 11 月の 第 5 回 、2026 年 2 月の 第 6 回 、2026 年 5 月の 第 7 回 に続き、今回が第 8 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 戦略事業開発本部 プリンシパル 戦略事業開発マネージャー 塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、塚本が開会の挨拶を行いました。 塚本はまず、AI を取り巻く環境の急速な変化について言及。日本政府が AI と半導体を含む戦略分野へ 2040 年までに官民累計 370 兆円超を投資する方針を示したことや、自律型エージェントを運用するインフラが整いつつある現状を説明しました。 一方で、S&P Global の調査を踏まえ、AI 実証実験の 46% が現場ニーズとのミスマッチや組織的な準備・運用体制の不足で本番導入前に打ち切られている課題もあると指摘。AWS はこのギャップを埋めるべく、構築から運用、セキュリティまで包括的なサポートを強化してきたと語りました。加えて、OpenAI 社との連携拡大や Amazon Quick のような自律型エージェントの進化についても触れました。 続いて、「LLM 開発支援プログラム」や「生成 AI 実用化推進プログラム」、「フィジカル AI 開発支援プログラム」など AWS のこれまでの支援実績の歩みを振り返りました。経済産業省と NEDO が主導する「GENIAC」プロジェクトへの継続的な支援実績を報告するとともに、今後は「フィジカル AI 開発支援プログラム」を「生成 AI 実用化推進プログラム」へ統合して窓口を一本化し、より柔軟な開発支援を提供していく方針を示しました。 最後に、本ミートアップを通じた AI 活用の加速に期待を寄せて挨拶を締めくくりました。 AWS セッション AWS セッションの前半パートでは、ゲストスピーカーである Weights & Biases Japan AI ソリューションエンジニア 山本 祐也 氏（写真上）が登壇。後半パートでは、AWS ジャパン プリンシパル スタートアップ ソリューションアーキテクト 針原 佳貴（写真下）をモデレーターに、対談形式でセッションが行われました。 山本氏はまず、ディープラーニングの実験管理ツールを提供する同社の歩みを紹介した上で、3 年以上にわたり運営を続けている日本語 LLM リーダーボード「Nejumi」の取り組みについて語りました。「Nejumi」は日本経済新聞社の「AI モデルスコア」にもデータ提供を行うなど、国内の生成 AI 開発における重要な指標となっています。山本氏は「網羅的かつ継続的に評価を続けること自体が業界貢献になる」と、その意義を強調しました。 続いて、LLM 評価トレンドの変遷を解説しました。2023 年から 2024 年頃は人間が比較採点する形式が主流でしたが、AI が高度化するにつれて人間の採点限界を超えてきています。そのため、API の利用実績をベースにした OpenRouter や、多面的に測定する Artificial Analysis など多様な手法が登場しています。 一方で、現在の評価における大きな壁として「ベンチマークのデータ汚染」と「評価コストの爆発」を挙げました。特にエージェント機能の評価においては、1 つのモデルの評価だけで最大 100 万円規模の費用が発生する「ベンチマーク破産」のリスクに言及。同社では、難易度を分散させたハイローミックス設計を行うことや、トレースデータを分析して極端に負荷のかかるタスクを特定・改善することで、コストと信頼性を両立させている旨を解説しました。 対談パートでは、針原からの問いかけに応じる形で、日本語モデルの現状や実践的な評価設計について議論を行いました。山本氏は、米中モデルが先行する中でも国内モデルは着実に進化していると言及。一般的なビジネスユースケースでは十分な実用性を備えていることに加え、データ主権を守る「ソブリン AI」としての需要も高まっていると説明しました。AWS 側からも、 Amazon Bedrock Marketplace 等を通じた国内モデルの普及支援の重要性が語られました。 さらに議論は、製造やロボティクスといった物理空間で動作する「フィジカル AI」の領域にも波及。実世界でのタスク遂行に向けたモデル開発や、現場導入を見据えた評価の重要性についても意見が交わされました。 最後に山本氏は Weights & Biases 社のサポート体制に言及。「基盤モデルの開発だけでなく、Claude Code や Codex などの API 利用のトレースまで幅広くカバーしている」と語り、あらゆるフェーズの生成 AI 開発者を支援する姿勢を示してセッションを終えました。 カスタマー事例 ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、自社の取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 AI Specialist SA の鯨田 連也（写真右）と Senior GenAI / Agentic AI Sales Manager の官能 翔一（写真左）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社みずほフィナンシャルグループ デジタル戦略部 テクノロジー第二チーム ヴァイスプレジデントの皆川 拓 氏は、同行が推進する「みずほ LLM」の開発と実務活用の取り組みを紹介しました。 独自 LLM を開発する背景として「データの機密性・主権の確保」「金融規制・法令対応の担保」「専門業務への適用・競争力の源泉化」の 3 点を提示。AWS 上に構築された基盤「みずほWiz Base」を軸に、内製開発体制で迅速な実装を進めている体制を説明しました。 開発プロセスにおいては、行内資料等を活用した追加学習によって金融基礎知識の正答率を約 9 割まで高めた後、実務適用フェーズへと移行。融資判断など複雑な業務に対応すべく、社内有識者の知見をもとに確認論点や次アクションを評価するデータセットを作成し、ファインチューニングや RAG を組み合わせて精度を向上させている現状を解説しました。 今後は行員が実際にモデルを試用できる環境を整え、現場のフィードバックを反映した改善を継続するほか、独自 LLM を組み込んだ安全かつ高効率な AI エージェントの技術検証を進めていくと展望を語りました。 株式会社Sapeet AI Solution 事業部 Senior Project Manager / Senior Systems Architect の村上 大昌 氏は、仰星監査法人における「監査リスク分析 AI」の開発事例をもとに、ノーコードからコードベースへの移行戦略と実践知見を語りました。 立ち上げフェーズではノーコードツールの Dify と Amazon Bedrock を採用し、非エンジニアも巻き込んだ迅速なプロトタイピングにより作業時間 87% 削減を達成。しかし、プロダクトの成長に伴い「ワークフロー肥大化による見通しの悪化」「複数人開発におけるコンフリクトやバージョン管理の難しさ」「標準チャット UI の表現力の限界」という 3 つの課題に直面しました。 そこで同社はコードベースへの移行を決断。実行基盤に Amazon Bedrock AgentCore 、エージェントのワークフロー記述に Strands Agents を採用しました。Dify の資産を活かした設計により実質 2 週間という短期間で移行を完了し、業務に最適化したダッシュボード UI も実現しました。 村上氏は「フェーズに応じた適切な技術選択が重要」と強調。初期に求められるスピード感と成長後の拡張性・保守性を両立させる実践的なアプローチを示しました。 株式会社rh labo R&D部 プロダクトマネージャーの金田 洋平 氏は、既設の防犯カメラと生成 AI を活用し、賃貸住宅のゴミ置き場における放置・散乱問題の解決に挑む取り組みを発表しました。 ゴミ出しのルール違反は物件の資産価値や入居率に直結する一方、従来は定期巡回や通報頼みで対応が後手に回る課題がありました。そこで同社は、防犯カメラ画像を Amazon EventBridge や Amazon ECS を介して取得し、Dify と Amazon Bedrock を連携させて画像解析・Slack 通知を行う仕組みを構築。個人情報保護法への配慮として Amazon Rekognition を前段に配置し、人物が写り込んだ画像を除外する設計を施しました。 運用においては「誤検知しても人に無駄な通知が飛ばない」設計思想を徹底。前日画像と比較する 2 段階判定や AI の確信度スコアを活用することで、PoC において誤アラート率を 0.41% まで抑え込み、低コストでの本番稼働を実現しました。 金田氏は、本取り組みによりゴミ問題の発生率や放置日数が指標化できたと説明。「今後は注意喚起や回収手配までを AI エージェント化し、より自律的な課題解決を進めたい」と展望を語りました。 株式会社BTM DX推進事業 ITエンジニアリング事業部 部長補佐の瀬崎 優太朗 氏は、「非エンジニアでもできる障害調査」をテーマに、AI エージェントを活用したシステム運用保守の効率化ソリューションを紹介しました。 システム障害の問い合わせ対応では、その連絡を受けた非エンジニア（営業やカスタマーサポート）と技術チーム間で複数回のやり取りが発生し、解決までに多くの時間とコミュニケーションコストを要する課題がありました。 同社はこれを解消すべく、チャットツールから自然言語で入力するだけで、AI エージェントが Amazon CloudWatch Logs や Amazon Aurora を直接調査・要約して即座に返答する仕組みを構築。電話対応中に約 1 分で一次回答できる体制を整え、調査工数を最大 95% 削減しました。 システム基盤には Amazon Bedrock AgentCore  を採用して疎結合な運用管理を実現。破壊的 SQL の実行を遮断するツール側の制限や各種ガードレールを組み合わせた「多層防御」により、安全性を確保しています。瀬崎氏は「専門知識を要する調査を AI が代替することで属人化を解消できる」と語り、さらなる業務改善を進める姿勢を示しました。 クロージング クロージングでは塚本より、次回の「生成 AI Frontier Meetup」が、2026 年 11 月 10 日に開催予定であることを説明しました。加えて、生成 AI 関連の開発・運用において参考になる技術ブログも紹介しました。 Bedrock Managed Knowledge Base を MCP Tool として利用する際のテナント分離・アクセス制御まとめ   Amazon Bedrock Managed Knowledge Base は、フルマネージドで RAG を実現するためのサービスで、 AgentCore Gateway のネイティブコネクタとして MCP Tool 化し、Agent から利用することも可能です。 Amazon Bedrock AgentCore で Agent をプロダクション利用する際の実装ノウハウ   AWS Summit Japan 2026 にて、「Bedrock AgentCore で実現する AI エージェントの最前線」というタイトルでブース（A105）を出展させていただき、ブース展示用に AWS Specialist Agent を開発しました。これは、AWS に関することなら何でも解説できる Agent で、Amazon Bedrock AgentCore の機能や、AWS Summit New York City 2026 で公開された新機能をフル活用しています。 Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway 非決定論的に動作する Agent に対して、実行可能なツールやアクセス可能なデータを制御することは重要な課題です。本記事 (Global Blog) では、Amazon Bedrock AgentCore を利用し、ユーザーやロール、テナント属性に応じたツールアクセス制御 (Fine-grained access control) に加えて、テナント境界を越えたデータアクセスを防ぐための最小権限設計など、セキュアな Agent の実現方法を解説しています。 参加者交流会の様子 ネットワーキングの時間では、各セッションで議論されたテーマを踏まえ、参加者同士が知見を共有し合う熱気あふれる交流が行われました。業界の垣根を越えて「学びと繋がり」を深める本イベントらしい活気にあふれ、新たな共創の可能性を感じさせる場となりました。 会場内には、技術的な相談に応じる「Ask an Expert」コーナーや、各種の疑問を気軽に相談できる「よろず相談」コーナーも設けられ、参加者の方々の質問に回答いたしました。 おわりに 第 8 回を迎えた本イベントでは、生成 AI の最新技術トレンドや実践的な評価手法について深い知見が共有されたほか、参加者の方々がネットワークを広げる貴重な機会となりました。AWS ジャパンは、今後もコミュニティの活性化や技術支援を通じて企業の生成 AI 活用を後押しし、その実用化と発展に貢献してまいります。

ローカルで始めた作業が、クラウドへ移っていくことがあります。 ちょっとした変更のつもりが、思ったより大きくなったり、時間がかかったり、あなたが席を離れた後も動き続けたり、当初想定していたよりも広くコードベースに及んだりすることがあります。 ここ数か月で、クラウド実行は Kiro での働き方の中でより大きな位置を占めるようになりました。本日（2026 年 9 月 3 日）、Kiro Web とクラウドセッションが一般提供 (GA)になりました。あわせて、すでに構築済みの Kiro のセットアップをローカルとクラウドの両方のセッションで使えるようにする cloud configuration も提供します。これらにより、あなたのエンジニアリング作業のより多くを、Kiro とともに自然にクラウドで実行できるようになります。 これまでに提供してきたもの 5 月のプレビュー以降、多くの開発者が Kiro Web を日々の働き方の一部に取り入れてきました。ちょっとした修正から、複数リポジトリにまたがるマイグレーション、席を離れている間や就寝中に動き続ける作業まで、用途はさまざまです。PR にレビュースレッドが付いて返ってきたら、 /kiro fix が一度の実行でそれらを片付けます。1 つのセッションが複数リポジトリ、それも GitHub と GitLab をまたいで変更を調整します。繰り返し発生するメンテナンスは Automations によってスケジュール実行され、誰かが同じ作業を再び始める必要はありません。Playwright はブラウザ由来のバグを再現し、変更が反映される前に UI の変更を検証します。 8 月には、 クラウドセッション をプレビュー提供しました。Kiro Web は常にクラウドサンドボックス上で動いていましたが、クラウドセッションはそれを CLI と IDE にまで広げます。CLI や IDE から開始したクラウドセッションは、あなたのマシン上ではなくクラウド上で、同じ Kiro エージェントハーネスを実行します。接続を切ってもエージェントは動き続けます。セッションは Kiro アカウントに紐づいたまま残るので、ブラウザ、エディタ、ターミナル、モバイルから同じセッションに戻ることも、まったく別のマシンで再開することもできます。 今回のアップデートの新機能 Kiro Web とクラウドセッションが一般提供になりました。有料プランのすべての開発者・チームが、ブラウザから構築・委任し、IDE や CLI からクラウドセッションを開始し、モバイルを含むあらゆる Kiro のサーフェスから続きに取りかかれます。チーム向けには、Kiro Web はサンドボックスアクセスのための IAM ロール、および Okta と Microsoft Entra ID による認証にも対応し、開発環境へのアクセスをよりきめ細かく制御できます。 あわせて cloud configuration を導入します。steering、custom agents、skills、powers、hooks など、ローカルですでに構築したセットアップをクラウドセッションに持ち込めるようになりました。この個人設定は、リポジトリとともに移動する既存のプロジェクト設定と併用できます。configuration sync は、あなたのクラウド設定を新しいローカルの IDE・CLI セッションに読み込むこともできます。その際、ローカルのファイルはそのまま残り、両者が重なる部分ではローカルが優先されます。 より面白いのは、これらを組み合わせたときに起きることです。 実際に使ってみる Kiro Web、IDE・CLI でのクラウドセッション、そして cloud configuration を組み合わせることで、作業がブラウザで始まる場合でも、IDE や CLI からクラウド実行へ移る場合でも、エンジニアリング作業をクラウドで動かす手段が増えます。試せる方法をいくつか紹介します。 実装の次の一区切りをクラウド実行に移す。 IDE や CLI で変更を進め、実装が独立して動かせる状態になったら、そこからクラウドセッションを開始します。セッションは Kiro のクラウドサンドボックスで実行され、後から同じクラウドセッションを Kiro Web、IDE、CLI、モバイルで開いて、進捗確認、指示の追加、作業の継続ができます。 ブラウザ由来のバグを再現から検証まで通す。 Kiro Web で作業を開き、クラウドサンドボックスでアプリケーションを実行します。Kiro は Playwright で問題を再現し、変更を加え、実際のブラウザで再度フローを動かして修正を検証します。提案されたパッチの段階で止まりません。 大規模なリファクタやアップグレードをやり切る。 フレームワークのアップグレード、依存関係のマイグレーション、大きな API 置き換え、テスト量の多いリファクタのために、IDE や CLI からクラウドセッションを開始します。ローカルの .kiro 設定を cloud configuration にアップロードすれば、そのクラウド作業は、作業実行中もローカルで構築したのと同じセットアップを使います。 1 つの本番変更をリポジトリ横断で運ぶ。 サービスや API の変更がバックエンドサービス、SDK、クライアント、フロントエンドにまたがるときは、Kiro Web で作業を始めます。クラウドセッションは関係するリポジトリをまたいで動き、各リポジトリを無関係なジョブとして扱うのではなく、実装を pull request・merge request まで通します。 繰り返しのエンジニアリング作業を、手作業の定例に変えずにクラウドで動かす。 Kiro Web で、依存関係の保守、issue のトリアージ、changelog の更新、ドキュメントのドリフト、契約チェックといった作業の Automations を作成します。各実行はあなたの cloud configuration とともにクラウドサンドボックスで動くので、誰も見ていないときでも同じ steering とセットアップが適用されます。 今日から使う IDE やターミナルで中断したところから再開するのも、 app.kiro.dev で新しく始めるのも自由です。詳しくは ドキュメント をご覧ください。 クラウドセッション は Kiro Web、IDE、CLI のいずれからでも開始でき、モバイルを含むあらゆるサーフェスから再開できます。IDE や CLI からの作成・アタッチには最近のバージョンが必要です。 cloud configuration をセットアップするには、 Settings でローカルの .kiro 設定をアップロードし、configuration sync を有効にして新しいローカルセッションに自動で取り込まれるようにします。スコープと同期の仕組みについては cloud configuration のドキュメント を参照してください。 Kiro Web 、 クラウドセッション 、 cloud configuration は US East (バージニア北部) リージョンで利用でき、Pro、Pro+、Pro Max、Power の各サブスクリプションに含まれます。クラウドセッションは共有クレジットを使用し、クラウドコンピュートに対する追加料金はありません。 チーム・組織向けには、Kiro Web、クラウドセッション、cloud configuration は、チームがすでに使っている同じ SSO(AWS IAM Identity Center、Okta、Microsoft Entra ID)を通じて、IDE・CLI・Web の全体でアクセスできます。管理者が Kiro コンソールの単一のトグルで Kiro Web とクラウドセッションを有効にすれば、開発者はあらゆるサーフェスからクラウドセッションを開始できます。セットアップについては エンタープライズ向けドキュメント を参照してください。 次に取り組む作業を Kiro に渡して、 app.kiro.dev でクラウド実行してみてください。

本稿は、2026 年 8 月 19 日に AWS Blog で公開された “Disaster Recovery for VMware Workloads on Amazon EVS” を翻訳したものです。 ビジネスクリティカルなワークロードを VMware 上で稼働させている多くの企業が、たった 1 度の障害が業務を中断し、顧客に影響を与え、収益と信頼を危険にさらし得ることを認識しています。 災害復旧 （DR）はその解決策であり、プライマリサイトがダウンした際に引き継ぐ準備が整ったセカンダリサイトを指します。しかし、従来その構築には多額の初期投資、長いハードウェアのリードタイム、そして本番環境との乖離が避けられない環境が必要であったため、プロジェクトは先送りにされてきました。 Amazon Elastic VMware Service（Amazon EVS） はこれらの障壁を取り除きます。AWS 上で完全な VMware 環境（VMware Cloud Foundation）をオンデマンドでデプロイでき、ハードウェアの購入もリードタイムも環境の乖離も不要です。使用した分だけ支払い、チームは既に慣れ親しんだ VMware のツールとプロセスをそのまま使い続けることができます。AWS が基盤インフラストラクチャを管理し、ワークロードは変更なしで復旧します。 この記事では、Amazon EVS を使用した災害復旧ソリューションの実装における 6 つのフェーズを解説します：戦略と目標の定義、復旧環境の作成、本番環境のミラーリング、ワークロードの保護、必要に応じた復旧、そして切り替えです。その過程で、ビジネスに適した DR 戦略を選択するためのトレードオフについても取り上げます。 図 1: Amazon EVS 上で DR ソリューションを構築するための 6 つのステップ フェーズ 1：災害復旧の目標と戦略の定義 何かを構築する前に、一歩引いて、何を保護するのか、なぜ保護するのかを考える必要があります。 スコープ： どのワークロードがビジネスにとって重要でしょうか？いくつのワークロードに保護が必要で、それらがダウンした場合の影響はどれくらいでしょうか？これが DR 設計全体のスコープを決定します。 復旧目標： ビジネスはどれくらいの時間ダウンを許容できますか？どれくらいのデータ損失を許容できますか？これが目標復旧時間（ RTO ）と目標復旧時点（ RPO ）です。 地理： 本番環境は現在どこで稼働していますか？1 つの 災害 で両サイトがダウンしないよう、復旧環境はどこに配置すべきでしょうか？データ所在地とコンプライアンスの要件が、利用可能な AWS リージョンを絞り込みます。 ツール： DR サイトでワークロードを運用するために、チームはどのようなツールを必要とするでしょうか？使い慣れたツールを拡張することで、新たな学習コストや未検証の障害モードを回避できます。 環境の忠実度： アプリケーションは本番環境の完全なコピー（同じ IP、同じポリシー）で動作する必要がありますか？それとも変更を許容する柔軟性がありますか？これがネットワーキングと構成のアプローチを決定します。 予算： 予算上限はありますか？コミット型キャパシティとオンデマンドの柔軟性、どちらが適していますか？これが、災害発生前にどれだけの待機環境を維持するべきかを決定します。 事業継続： 会社に 事業継続計画（BCP） はありますか？ある場合は、DR 計画をそれに合わせます。BCP が優先順位、許容可能なダウンタイム、復旧順序を設定します。 ランサムウェア対策： 復元前にワークロードがクリーンであることを検証する必要はありますか？イミュータブルストレージと隔離された復旧環境が再感染を防止します。 これらを検討し終えれば、戦略はほぼ自動的に決まります。正しい戦略とは、全体で最も低い RTO を持つものではなく、全てのワークロードがビジネスに必要なレベルの保護を受け、持続可能なコストで、チームが自信を持って実行・テストできるプロセスを備えたものです。以下の表に 4 つの一般的なアプローチを示します。 Cold (オンデマンド) Pilot Light (最小構成) Warm Standby (部分構成) Hot (アクティブ)* 事前デプロイされるもの なし (EVS は災害時にデプロイ) 最小限の EVS 環境 (2 〜 4 ホスト) 縮小クラスター (重要ワークロード向け) フルクラスター (本番同等の容量) コスト $ $$ $$$ $$$$ RTO** 最も高い(8 時間以上) 中‑高(~ 4 時間以上) 中-低(~ 2 時間以上) 低 (~ 15 分以上) RPO 数時間〜数日（最終バックアップ） 数分（最終レプリケーション） 数分（最終レプリケーション） ほぼゼロ（継続的同期） 復旧アクション* EVS デプロイ → 本番ミラーリング → VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え テストの信頼性 低（災害時まで未テスト） 中（クラスター検証済み） 高（部分的フェイルオーバーテスト） 非常に高（継続的検証） 最適な用途 RTO に余裕のある非重要ワークロード 標準的な本番ワークロード 厳格な SLA を持つ重要アプリケーション ゼロダウンタイムのミッションクリティカル * Hot（アクティブ）：アプリケーション層では実現可能ですが、インフラストラクチャレベルでは vSAN ストレッチクラスタリングが必要です（EVS では未対応）。 ** RTO は災害時に残っている復旧アクションの数に依存し、復旧アクティビティが少なく短いほど RTO は低くなります。 フェーズ 2：DR 環境の作成 復旧環境の作成は 3 つの決定に集約されます：どこにデプロイするか、何をデプロイするか、事前にどれだけ稼働させておくかです。完全なデプロイワークフローについては、 Amazon EVS のドキュメントを参照してください。 どこに： Amazon EVS を、プライマリサイトとは別の AWS リージョン またはアベイラビリティゾーンに、自身の VPC 内にデプロイします。そこから、必要に応じて AWS 内の他のサービスやオンプレミスに接続します。 何を： インフラストラクチャ基盤となる EC2 ベアメタルインスタンス と、ワークロードが期待するソフトウェア定義データセンターを提供する VMware Cloud Foundation のバージョンを選択します。 どれだけ： 上限と下限を把握し、その間のどこに位置するかを決定します。 上限： 上限を算出するには、前のフェーズで作成したワークロードインベントリから、重要なワークロードが消費するリソースを合計し、VCF 管理オーバーヘッドを考慮します。これにより、全てを一度に復旧するために必要なホストの最大数が得られます。 下限： 一方、下限は VCF のバージョン、ストレージタイプ、 フリートフットプリント に応じて Broadcom が定義します。最新の値については VCF のドキュメント を確認してください。現在、VCF 5.2 および 9.x では、Broadcom は本番環境向けに 4 ホストと vSAN ストレージによる 高可用性デプロイメント を推奨しています。VCF 9 では、vSAN で 3 ホスト、または外部ストレージで 2 ホストから始められる シンプルデプロイメント も提供しており、管理プレーンの冗長性よりもコストが重要な環境に適しています。 ティアの選択： これらの上限と下限の間で、現時点でどこに位置するかを決定します。これがコスト対速度の核心的な判断です。事前にデプロイしておくホストが多いほど復旧は速くなりますが、そのアイドル状態のキャパシティを維持するコストも増えます。何もデプロイせず災害発生時に完全に構築する方法（Cold）もあれば、小規模なフットプリントを稼働させておき必要時にスケールアウトする方法（Pilot Light または Warm Standby）もあります。また、DR サイトで日常的に非重要ワークロードを稼働させ、災害発生時にそれらをシャットダウンしてキャパシティを回収するという、一般的な手法もあります。 フェーズ 3：本番環境構成のミラーリング Amazon EVS がデプロイされたら、ワークロードがソースサイトとまったく同じように動作するよう構成します。ネットワーキング、セキュリティ、コンピュート、ストレージ、アイデンティティです。これらが本番環境と一致していれば、ワークロードはクリーンに復旧し、プライマリサイトと同じように動作します。 図 2: 災害復旧の概要 これらの中で、ネットワーキングが最も難しく、最も重要な部分です。フェイルオーバー後に VM が期待するセグメント、ゲートウェイ、ファイアウォールルールに到達できなければ、何も機能しません。このサービスは、復旧サイトで本番ネットワークを再現するための確実な選択肢を提供します。最も一般的な 2 つのモデルを以下に示します： コード駆動型ネットワークレプリケーション このアプローチは、 Terraform 、 Ansible 、 PowerCLI 、 VCF Automation などの Infrastructure as Code（IaC）ツールを使用して、本番ネットワーク構成を復旧サイトにレプリケートします。動作方法は準備する戦略によって異なります。復旧サイトがまだ存在しない場合は、本番ネットワークをコードとしてキャプチャし、サイトのデプロイ時に実行します。既に稼働している場合は、IaC パイプラインが両サイトを自動的に同期させます。いずれの場合も、DR が起動すると、VM は既に配置されているネットワークに接続します。すべてのティアで機能します。 NSX Federation NSX Federation を使用すると、両サイトのネットワーキングを 1 つの中央拠点、NSX グローバルマネージャーから管理できます。セグメント、ファイアウォールポリシー、セキュリティグループを一度定義すれば、両方のロケーションに自動的にプッシュされます。VM が DR サイトで復旧すると、同じ IP、同じファイアウォールルール、同じセキュリティポリシーが適用されます。IP の再割り当て、再構成、乖離は不要です。 これには、両サイトにネットワーキングインフラストラクチャが既にデプロイされ稼働している DR 環境が必要です。初期セットアップが必要であり、一部のポリシーは VM が復旧サイトに登録されて初めて有効になります。それでも、両サイトを常に同期させる必要がある環境にとって、即座のネットワーク準備完了への最もクリーンなパスです。 NSX Federation コード駆動型ネットワークレプリケーション ネットワーク同期 自動、リアルタイム 手動または IaC 駆動、定期的 フェイルオーバー時の IP 再割り当て なし（同じセグメントがストレッチ） あり得る（マッピングに依存） インフラストラクチャオーバーヘッド 高い（両サイトにグローバルマネージャー + Edge） 低い（クロスサイト NSX インフラ不要） 乖離リスク なし（グローバルマネージャーが強制） 自動化されていなければ存在する 最適な用途 Warm Standby、Hot — 頻繁な変更、IP 再割り当てゼロ Cold、Pilot Light、Warm Standby — 安定したネットワーク、IaC の成熟度 フェーズ 4 & 5：ワークロードの保護と復旧 復旧環境が作成され、本番環境と一致するよう構成されたら、次の問題はワークロードデータをどのようにそこに移すか、そしてその時が来たときに仮想マシンをどのように復旧するかです。Amazon EVS で動作するソリューションは複数あります。以下の表は、最も重要な基準に沿って利用可能なソリューションを比較しており、続くセクションでそれぞれを詳しく解説します。 VMware Live Recovery Veeam FSx for NetApp ONTAP AWS Backup カバー範囲 保護 + 復旧 保護 + 復旧 保護 + 復旧 保護のみ レプリケーション層 ハイパーバイザー(vSphere Replication) ハイパーバイザー(I/O フィルタ + プロキシ) ストレージ(SnapMirror、ブロックレベル) スケジュール(S3 へのスナップショット) RPO 5 分 – 24 時間 ~2 秒 (CDP)、 分 (レプリケーション)、時間 (バックアップ) 5 分 数時間〜数日 自動化 高 (復旧計画、スクリプト、再 IP) 高 (切替計画, 即時 VM 復旧) 中-高 (BlueXP でワンクリック) 最小 (スケジュールバックアップ、手動復旧) テスト 非破壊、隔離ネットワーク 非破壊切替テスト FlexClone ゼロスペースコピー 組み込みテスト無し 粒度 VM 単位 VM 単位 ストレージボリューム単位 VM 単位 DR サイト必要？ Yes Yes (CDP/Replication)、No (Backup) Yes No 複雑さ 低 中 低 – 中 最低 ライセンス VM – VCF アドオン VM GB 単位の従量課金 GB 単位の従量課金 最適な用途 統合ソリューションを求める VMware チーム すべてのティアで 1 つのサービスを求めるチーム 既に NetApp ONTAP を使用している組織 ベースライン保護とコンプライアンス層 ハイパーバイザーレベルのレプリケーション これらのソリューションは、ハイパーバイザーレベルで仮想マシンのディスクへの変更をインターセプトし、復旧サイトに転送することでレプリケーションを行います。通常、データの管理と移動のために両サイトにアプライアンス VM をデプロイします。このアプローチは最もタイトな RPO を提供し、復旧環境が既に稼働していることを必要とします。保護と復旧は同じサービス内で処理されます。 図 3: ハイパーバイザーベースのレプリケーション — 仮想アプライアンスを通じた DR オーケストレーションとデータレプリケーション VCF Protection and Recovery これは VCF における統合 DR プラットフォームであり、2 つのワークフローを持ちます：1 つは運用継続に焦点を当て、もう 1 つはサイバー攻撃後の安全な復旧のために設計されています。Disaster Recovery Orchestration：従来型の DR を処理します。各サイトにアプライアンスをデプロイし、vSphere Replication、vSAN Data Protection、またはストレージアレイでレプリケーションを行います。復旧計画が残り、つまり IP の変更、ネットワークマッピング、起動順序を処理します。RPO はレプリケーション方式に依存します：vSphere Replication で約 5 分、vSAN DP では設定したスケジュール、同期アレイではほぼゼロです。DR サイトが既に稼働していれば、RTO は通常わずか数分です。Cyber Recovery はランサムウェアからの復旧のための隔離された場所を提供します。小さなコネクターが重複排除された VM スナップショットをイミュータブルなクラウドファイルシステムに送信します。問題が発生した場合、隔離された復旧環境を起動し、Live Mount を使用してクリーンなスナップショットを即座に起動します。完全な復元は不要であり、DR サイトを 24 時間 365 日稼働させる必要もありません。 パートナーソリューション 複数のパートナー製品が Amazon EVS で動作します。Veeam は最も一般的なものの 1 つであり、単一のサービスで複数のティアにわたる保護と復旧の両方を処理します。保護については 3 つのモードを提供します：Amazon S3 へのスケジュールバックアップ（RPO は数時間）、スタンバイ VM へのほぼ継続的なレプリケーション（RPO は数分）、そしてハイパーバイザーレベルですべての書き込みをキャプチャする Continuous Data Protection（RPO は約 2 秒）。復旧については、フェイルオーバー計画がブートシーケンスと IP 再割り当てルールを自動的に処理し、Instant VM Recovery はフルリストアがバックグラウンドで完了する間にバックアップから直接マシンを起動できます。バックアップモードは事前の DR 環境を必要としません。レプリケーションと CDP モードは DR 環境を必要とします。粒度は VM 単位。複雑さは中程度で、1 つのコンソールですべてを管理しますが、3 つのモードすべてを同時に運用するには計画が必要となります。イミュータブルバックアップがランサムウェアから復旧ポイントを保護します。ライセンスは VM 単位です。 ストレージレベルのレプリケーション ストレージベースのレプリケーションはブロックレベルで動作し、両サイトに同じストレージサブシステムが必要です。Amazon FSx for NetApp ONTAP は 1 つの選択肢であり、EverPure などのパートナーからも同等のソリューションが利用可能です。 図 4: ストレージレベルのレプリケーション — 本番環境と復旧ストレージアレイ間のブロックレベル同期 Amazon FSx for NetApp ONTAP このソリューションは両サイトに FSx for NetApp ONTAP が必要であり、保護と復旧の両方を処理します。保護については、 SnapMirror がブロックレベルでストレージボリュームを 5 分ごとにレプリケートし、VM に対して完全に透過的で、ゲストレベルのオーバーヘッドはありません。完全な EVS 環境は復旧時のみ必要です。 復旧については BlueXP がフェイルオーバーをオーケストレートします：SnapMirror の関係を切断し、レプリカボリュームを書き込み可能にし、DR サイトにデータストアとしてマウントし、vCenter に VM を登録し、定義した順序で電源を入れます。プロセス全体がワンクリックまたは API 駆動です。粒度はボリューム単位で、通常は VM のグループを意味します。複雑さは低〜中程度。価格は GB 単位の従量課金で、大規模ではコスト効率が高いです。既に NetApp ONTAP を使用しており、最小限の運用オーバーヘッドでストレージ効率の高いレプリケーションを求める組織に最適です。 スケジュールバックアップ 最もシンプルかつ安価な保護形態で、耐久性のある外部ストレージに保存される定期的なスナップショットです。RPO はバックアップ頻度に応じて数時間から数日です。事前に DR 環境を稼働させておく必要はありません。 図 5: バックアップとリストア — リモートリポジトリへのスケジュールスナップショットとオンデマンド復旧 AWS Backup このオプションは保護のみを処理します。VM のスケジュールスナップショットを取得し、Amazon S3 に保存します。オプションの Vault Lock によるイミュータビリティにより、ランサムウェアを含め誰も復旧ポイントを削除または変更することができません。復旧は完全に手動です。オペレーターが仮想マシンを復元し、ネットワーキングを構成し、ブート順序を設定し、検証します。オーケストレートされたフェイルオーバーはありません。そのため、復旧時間が重要なワークロードには単独では不向きですが、他のアプローチの下にあるベースライン保護およびコンプライアンス層としては上手く機能します。ポリシー駆動、エージェント不要で、すべての操作が CloudTrail にログとして記録されます。粒度は VM 単位で、複雑さは最小限です。 フェーズ 6: 切り替えとテスト 最終フェーズは 2 つのことに関するものです：ユーザーを復旧サイトに切り替えること、そして実際の災害が発生した際にプロセスがまだ機能することを確認するために、十分な頻度でテストすることです。 切り替えの実行 切り替えとは、シンプルに DNS を更新して、ユーザーとシステムがプライマリサイトへの参照を停止し、復旧サイトへの参照を開始することです。Route 53 のヘルスチェックとフェイルオーバールーティング、加重レコード、またはオーケストレーションツールによってトリガーされる DNS 更新を使用します。重要なレコードの TTL は低く保ちます（60 秒以下）。長い TTL は、レプリケーションツールが提供する値をはるかに超えて実効 RTO を延ばす可能性があります。また、ランブックには外部依存関係への対応も記載して下さい。パートナー連携や、ハードコードされた IP を持つアプリケーション、管理外のサードパーティ DNS ゾーンなどです。 DR 計画のテスト テストされていない DR 計画は単なる推測に過ぎません。実際の復旧が失敗する最も一般的な理由は乖離です。レプリケーションから漏れたアプリケーション、本番環境でのみ変更されたファイアウォールルール、数ヶ月前にリネームされたものを参照しているスクリプトなどです。ほとんどのレプリケーションツールは、隔離ネットワークやサンドボックス環境を通じた非破壊テストをサポートしているため、スケジュールに従って使用します。重要ワークロードは毎月、その他は四半期毎。実際の RTO を目標と比較して追跡し、テストごとの想定外の事象の数を記録します。想定外の事象の傾向こそが、DR 成熟度の真の指標になります。ランブックの実行者をローテーションし、壊れた自動化が宣言時ではなく訓練時に発見されるようにします。 本番環境へのフェイルバック 実際のフェイルオーバー後、プライマリサイトが復旧したら、最終的にワークロードを本番環境に戻す必要があります。保護に使用したのと同じレプリケーションツールが逆方向に機能します：DR 環境を本番環境にレプリケートし、整合性を検証してから、トラフィックを切り戻します。フェイルバックは最初から計画しテストして下さい。テストされていないフェイルバックは、テストされていないフェイルオーバーと同じリスクを伴います。 結論 Amazon EVS 上の災害復旧は、単一のツールや単一の決定ではありません。6 つのフェーズにわたる一連の選択であり、それぞれが RTO、RPO、コスト制約、運用の現実によって形作られます。復旧環境をどこにどのようにデプロイするか、本番環境をどれだけ忠実にミラーリングするか、データをどのように移すか、ワークロードをどのようにオンラインに戻すか、そしてすべてが機能することをどのように証明するかを選択します。良いニュースは、Amazon EVS が小さく始めて成長する柔軟性を提供することです。優先度の低いワークロードには最小限のフットプリントとスケジュールバックアップから始め、ダウンタイムを許容できないワークロードには継続的レプリケーションとフルオーケストレーションを段階的に追加できます。すべてを一度に解決する必要はなく、すべてのキャパシティを一度にコミットする必要もありません。唯一省略できないのはテストです。ドキュメントの中にしか存在しない DR 戦略は負債です。テストを実行し、想定外の事象を追跡し、ギャップを埋め、繰り返します。目標は初日から完璧であることではありません。検証済みの復旧を1回ずつ積み重ねて信頼を築いていくことです。 Amazon EVS を始める AWS 上の VMware ワークロードのための災害復旧を構築する準備はできましたか。Amazon EVS を探索し、今日から復旧戦略の計画を始めましょう。 Amazon EVS のオファリングを Amazon EVS 製品ページ で確認してください。 技術的な詳細を Amazon EVS ドキュメント で掘り下げましょう。 最初の EVS 環境を Amazon EVS コンソール からデプロイしましょう。 この投稿の翻訳は Solutions Architect の有岡が担当いたしました。原文記事は こちら です。 Akshay Joshi AWS の Worldwide Public Sector チームのシニアソリューションアーキテクトであり、政府および教育機関の顧客が VMware 環境をモダナイズするのを支援しています。IT インフラストラクチャ（サーバー、ネットワーキング、ストレージ）で 15 年以上の経験があり、VMware を専門とし、そのキャリアの最後の 5 年間を AWS で過ごしてきました。公共セクターチームと協力し、既存の VMware 投資をスケーラブルでセキュアな AWS アーキテクチャに引き継ぐ支援を行っています。 Erick Meneses AWS の移行とモダナイゼーションに特化したスペシャリストソリューションアーキテクトです。大規模な変革プログラムのリードで 20 年以上の経験を持ち、EMEA 全域のエンタープライズ顧客がクラウドジャーニーを進め、成功した成果の達成を支援しています。 Ben Lipman 仮想化、ストレージ、ネットワークを管理する IT インフラストラクチャエンジニアリングで 25 年のバックグラウンドを持ち、あらゆる規模のエンタープライズを担当してきました。AWS で過去 10 年間を過ごし、現在はワールドワイド VMware テクニカルリーダーを務めています。

はじめに 英国最大級の銀行である NatWest Group にとって、一貫したカスタマーエクスペリエンスの提供はビジネス上の優先事項であると同時に、規制上の要件でもあります。カスタマーエクスペリエンス業務を中断なく維持することは、事業継続と災害復旧の義務を果たすための基盤です。 NatWest は当初、AWS のヨーロッパ (ロンドン) リージョンに Amazon Connect Customer で カスタマーエクスペリエンスプラットフォームを構築しました 。Amazon Connect Customer は単一リージョンのアーキテクチャの場合も、少なくとも 3 つのアベイラビリティーゾーン (AZ) でアクティブ-アクティブ-アクティブ構成で稼働し、さらに各 AZ は 1 つ以上のデータセンターで支えられています。このマルチ AZ 設計により、大多数のケースにおける Amazon Connect Customer の利用で高いレジリエンスと可用性を達成しています。一方、さらに最高レベルのレジリエンスが必要な場合や、厳格なコンプライアンス要件および地理的冗長性を満たす必要がある場合に向けて、Amazon Connect Customer は Amazon Connect Customer Global Resiliency (ACGR) を提供しています。NatWest は厳格なコンプライアンスとレジリエンス要件を持つ金融機関として、 AWS と連携して Amazon Connect Customer Global Resiliency (ACGR) を導入し、Amazon Lex を活用した会話 AI 体験を含む、完全なアクティブ-アクティブのマルチリージョンカスタマーエクスペリエンスプラットフォームのアーキテクチャへの変革を実現しました。本記事では、その実現までの道のり、構築した自動化ユーティリティ、克服した課題、そして得られた教訓を紹介します。 「NatWest にとって、レジリエンスはオプションではなく、毎日何百万人ものお客様にサービスを提供するための基盤です。Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency によるマルチリージョンコンタクトセンターへの移行は、リージョン障害時でもサービスを中断させないために不可欠でした。この変革により、お客様からの信頼を守り、自信を持ってスケールし、大手金融機関に求められるレジリエンス基準を満たせるようになりました。」 ビジネスコンテキストと推進要因 NatWest の Amazon Connect Customer インスタンスは月間 300 万件以上の音声通話を処理し、重要な銀行業務を支えています。お客様はこのシステムを不正行為の報告、影響を受けたカードのブロック、緊急資金へのアクセス、その他の時間的制約のあるリクエストの解決に利用しています。さらに、カスタマーエクスペリエンスプラットフォームは 26 の異なるサービスと連携しており、必要な時に有人エージェントが対応できるようエージェントのスケジューリングを支援するワークフォース管理、不正防止のための音声バイオメトリクス認証、定型的なリクエストをセルフサービスで処理する会話 AI などが含まれます。これらのミッションクリティカルな業務の性質と、金融サービスの可用性に対する規制上の厳しい監視を踏まえると、あらゆるシナリオでのサービス継続性の維持は譲れない要件です。 本取り組みの主な推進要因は以下のとおりです。 規制コンプライアンス: 英国の金融規制当局は、目標復旧時間 (RTO) の定義を含む、実証可能な事業継続・災害復旧 (BCDR) 能力を要求しています 単一リージョンへの依存軽減: ロンドンの単一リージョンに限定された運用では、万一リージョン障害が発生した場合、サービス継続性に関する厳格な規制要件を持つ組織にとって課題となります お客様の信頼保護: お客様は、特にストレスの高い状況において、銀行サービスへの中断のないアクセスを期待しています ミッションクリティカルな業務: NatWest のカスタマーエクスペリエンスプラットフォームは、機密性の高い銀行取引の主要チャネルであり、サービス継続性がお客様の成果に直結します ソリューションアーキテクチャ NatWest は AWS ヨーロッパ (ロンドン) リージョンの既存のコンタクトセンターを拡張し、AWS ヨーロッパ (フランクフルト) リージョンに完全に同期されたレプリカを作成しました。両リージョンはアクティブ-アクティブ構成で同時に稼働します。つまり、エージェントとお客様からの通話はどちらのリージョンでも処理可能です。一方のリージョンで障害が発生した場合も、もう一方を通じてトラフィックが流れ続け、お客様やエージェントが体感できる影響はありません。このアーキテクチャは 2 つの主要な AWS 機能を活用しています。 Amazon Connect Customer Global Resiliency (ACGR) ACGR により、組織は 2 番目の AWS リージョンに Amazon Connect Customer のレプリカインスタンスを作成できます。NatWest が活用した主な機能は以下のとおりです。 自動構成レプリケーション — Amazon Connect Customer リソースのネイティブな準リアルタイム双方向レプリケーション。リージョン間で一貫したエクスペリエンスを提供するために不可欠です。 Traffic Distribution Groups (TDG) — 設定可能な割合に基づいて、電話番号とエージェントのトラフィックを ACGR インスタンス間で分配します。 グローバルエージェントサインイン — エージェントはグローバルサインイン URL を使用して ACGR インスタンス間で認証を行い、代替リージョンに容易に移動できます。 レプリカのリザーブドキャパシティ — 制約なくトラフィックを移動できるよう、2 番目の AWS リージョンにキャパシティを予約します。 Amazon Connect Customer Global Resiliency は会話 AI レジリエンスにも対応しており、Lex V2 ボットをリージョン間で準リアルタイムにレプリケートします。これにより、対話型音声応答 (IVR) とセルフサービス体験の一貫性を、アクティブ-アクティブデプロイメント全体で保つことができます。 図 1: AWS ヨーロッパ (ロンドン) と AWS ヨーロッパ (フランクフルト) リージョン間で Amazon Connect Customer Global Resiliency を使用した NatWest のマルチリージョンアーキテクチャ。Traffic Distribution Groups が通話とエージェントを両リージョンにルーティングする様子を示しています。 カスタム自動化ユーティリティ ACGR は Amazon Connect Customer と Amazon Lex の構成レプリケーションをネイティブに処理しますが、NatWest は Traffic Distribution Groups を大規模に管理するための運用ツールの必要性を認識しました。6 つの TDG 管理ユーティリティと 1 つの Amazon Lex 有効化ユーティリティを開発し、ネイティブの Amazon Connect Customer API を使用してカスタム自動化機能を構築しました。すべてのユーティリティは複数の環境 (dev、test、preprod、prod) にわたる CI/CD パイプラインステージとして実装され、効率的なリージョン切り替えを可能にしています。 ユーティリティ 目的 エージェントの TDG への関連付け エージェントを Traffic Distribution Group (TDG) に追加 電話番号の関連付け 電話番号を TDG にリンク エージェントの TDG からの関連付け解除 エージェントを TDG から削除 TDG 更新 ロンドンとフランクフルト間のトラフィック分配率を変更 TDG 一覧表示 すべての TDG と現在のトラフィック分配状況を表示 Amazon Lex Global Resiliency (ALGR) ボット有効化 Lex V2 ボットの Amazon Lex Global Resiliency をリージョン間で有効化 各ユーティリティは環境パラメータとインスタンスパラメータを受け取り、手動の構成変更なしにすべてのデプロイメントステージで一貫した運用を可能にしています。 導入の道のり NatWest は 20 週間で実装を完了し、その後 3 か月間のフェーズ分けした番号ポーティング期間を設けました。 フェーズ 期間 主なアクティビティ フェーズ 1: 計画と現状把握 1〜4 週 運用準備の要件分析、チーム編成、サービスクォータのレビュー、AWS Well-Architected レビュー フェーズ 2: 開発環境のセットアップ 5〜8 週 Dev 環境での ACGR 設定、シングルサインオンの検証、Terraform パイプラインの更新 フェーズ 3: テストとプレプロダクション 9〜16 週 非レプリケートリソースの処理、TDG テストシナリオ、モニタリングの設定、ステージング環境での検証 フェーズ 4: 本番デプロイ 17〜20 週 サービスクォータの調整、本番環境での ACGR 有効化、段階的なトラフィック移行 フェーズ 5: 番号ポーティング 本番後 3 か月間にわたる電話番号の TDG への段階的なポーティング 「非本番環境で開始したことで、統合の問題、特に非レプリケートリソースに関する問題を、お客様への影響が出る前に早期に発見できました。」 「Amazon Connect Customer Global Resiliency はコアのコンタクトルーティング機能をリージョン間で自動レプリケートする強力な基盤を提供してくれますが、マルチリージョン戦略の真の成功は責任共有モデルの理解と実践にあります。NatWest にとってそれは、Amazon Connect Customer の境界を超えるすべてのものに対してオーナーシップを持つことを意味しました。AWS が管理する部分と自社が管理する部分を明確に分離することで、運用上および規制上の期待に応える、レジリエントで再現性のある、厳密に管理されたグローバルアーキテクチャを構築できました。」 技術的な課題とその解決方法 非レプリケートリソース Amazon Connect Customer Global Resiliency (ACGR) は責任共有モデルで運用されます。AWS は、リージョン間で音声トラフィックをルーティングするために必要な特定の Amazon Connect Customer 構成リソースを自動的にレプリケートしますが、DynamoDB や AWS Lambda など Amazon Connect Customer のリソース境界外にあるリソースについては、お客様が外部でレプリケーションパイプラインを維持する必要があります。 NatWest のマルチリージョンデプロイメントでは、この責任共有モデルによりいくつかの主要コンポーネントの準備が必要でした。 サーバーレスインフラストラクチャ: AWS Lambda 関数は、環境間で一貫した Infrastructure-as-Code (IaC) デプロイメントを維持するため、拡張された Terraform CI/CD パイプラインを使用してレプリカリージョンに独立してデプロイが必要でした。 静的コンテンツ: オーディオプロンプトや静的アセットを含む Amazon S3 のコンテンツは、S3 クロスリージョンレプリケーションを使用してリージョン間で効率的にレプリケートしました。これにより、元のバケットとレプリケーション先のバケット間でオブジェクトが自動的に同期されます。 リアルタイムストリーミング: Nuance Gatekeeper の音声バイオメトリクス機能の統合などをサポートするため、各リージョンに個別の Amazon Kinesis Video Streams の構成が作成されました。これらは ACGR の自動レプリケーション範囲外のためです。 言語と語彙リソース: Amazon Lex カスタム語彙と Amazon Connect Customer カスタム語彙の両方とも、リージョン間で同期するための外部のレプリケーションパイプラインが必要でした。これらのリソースは標準的な ACGR および ALGR のレプリケーション範囲を超えており、お客様側でオーケストレーションの管理が必要です。 カスタム Contact Control Panel (CCP) の修正 NatWest は Amazon Connect Customer Streams API を使用して構築されたカスタム CCP を運用しています。チームは認証ロジックをリージョンに依存しない形に適応させ、エージェントがアクティブなリージョンに容易に接続できるようにしました。 メトリクスとモニタリング NatWest が ACGR をデプロイした当時、Amazon Connect Customer はネイティブな統合クロスリージョンメトリクスビューを提供していませんでした。このギャップに対処するため、NatWest はカスタムの Amazon CloudWatch ダッシュボード と Amazon QuickSight レポートを構築し、両リージョンの運用メトリクスを単一の運用ビューに統合しました。 現在、ACGR は統合されたエージェントメトリクスとコンタクトメトリクスをネイティブに提供しており、効率的なコンタクトセンター運用のための統合コンタクト検索ページも含まれています。 セキュリティに関する考慮事項 セキュリティは AWS とお客様の間の責任共有で実現されます。NatWest は ACGR 実装全体を通じて以下のセキュリティベストプラクティスを適用しました。 NatWest は EU のデータレジデンシーコンプライアンスを維持するためにフランクフルトをレプリカリージョンとして選択しました。これは組織の規制上の義務における重要な要件です。NatWest は転送中および保存時のすべてのデータを AWS マネージドキーで暗号化し、暗号化キー管理のさらなる制御がポリシー上必要な場合にはカスタマーマネージド KMS キーを適用しています。 すべての自動化ユーティリティと Lambda 関数は最小権限の IAM ロールで動作し、各オペレーションに必要な最小限の権限にスコープされています。ロールを設定する際は、IAM ベストプラクティスガイドを参照して、実装が AWS のセキュリティ推奨事項に従っていることを確認してください。チームはリージョン間のトラフィック切り替え時の認証失敗を防ぐため、本番デプロイ前に非本番環境で ID プロバイダーの設定を検証しました。 NatWest は両リージョンで AWS CloudTrail を有効化し、構成変更とリージョン切り替えイベントの完全な監査証跡を維持しています。これにより、コンプライアンスとトラブルシューティングの目的ですべてのアクティビティを追跡できます。 「セキュリティと規制コンプライアンスは、AWS でのクロスリージョン実装の基盤でした。EU データレジデンシー要件を満たすためにフランクフルトを選択し、転送中および保存時のデータの暗号化の徹底、包括的な CloudTrail 監査により最小権限の IAM を適用することによって、レジリエンスや俊敏性を損なうことなく厳格な規制要件を満たすことができました。厳密な本番前検証により、最高のセキュリティ基準を維持しながらスムーズなリージョン間トラフィック切り替えを実現しました。」 2 番目の AWS リージョンの依存サービス設定の一環として、NatWest は定期的に代替リージョンへのトラフィック切り替えを実施し、設定が正確でビジネスが 2 番目のリージョンで一貫して運用されることを確認しました。この取り組みは設定が常に同期されていることを検証し、リージョン切り替えが発生した場合にビジネスが一貫したエージェントおよびお客様体験を提供できると確証を得るために不可欠でした。NatWest はこのフェイルオーバーテストを四半期ごとに実施し、ランブックを最新の状態に保ち、リージョン切り替えへの自信を維持しています。 成果 この実装により、レジリエンス、コンプライアンス、運用全体にわたって測定可能な改善が実現しました。 ほぼ瞬時の RTO — Traffic Distribution Groups により、Recovery Time Objective を 30 分超からほぼ瞬時に短縮しました。手動介入なしに通話が自動的に再ルーティングされます。 負荷下でのフルキャパシティ — シミュレーションされたリージョン障害テスト中に 3,500 件以上の通話のフルキャパシティを維持しました。 規制コンプライアンス — コンプライアンス義務を満たす、文書化されテスト済みのマルチリージョンアーキテクチャを実装し、BCDR 要件を達成しました。 エージェント体験の簡素化 — 単一のグローバルサインイン URL により、3,500 人以上のエージェントが必要に応じてリージョンや ACGR インスタンス間をスムーズに移動できるようになりました。 運用オーバーヘッドの削減 — 自動構成同期が手動のマルチリージョンデプロイメントに取って代わり、エンジニアリングチームを反復的な管理タスクから解放しました。 エンドツーエンドのサービス継続性 — 両リージョンで 26 の統合サービス全体の継続性を維持し、リージョン切り替え時も依存するアプリケーションが正常に動作し続けました。 得られた教訓 NatWest の事例に基づき、同様の実装を計画するチームに以下をお勧めします。 1. 非本番環境で開始 — レプリケートされていないリソースにおける統合の問題を本番環境に到達する前に発見する 2. SAML/SSO の早期検証 — ACGR レプリカ作成とグローバルサインインの開始前に、ID プロバイダーの設定を完了しテストする 3. すべての統合を監査 — Amazon Connect Customer と統合するすべてのサービスを文書化し、開始前にレプリケートされる対象とされない対象を分類する 4. 本番稼働前にモニタリングを構築 — 本番トラフィックの移行前にクロスリージョンの運用ダッシュボードを整備する 5. 定期的な障害注入テストを実施 — 定期的なフェイルオーバー訓練を予定し、トラフィックの再ルーティング、エージェントのサインイン、 すべての統合サービス (NatWest の例では 26 のサービス) がシミュレーションされたリージョン障害時に正しく機能することを検証する。NatWest は四半期ごとに障害注入演習を実施し、現実的な条件下で RTO 目標を検証しています。 6. 段階的なトラフィック移行を実施 — ハードカットオーバーではなく、TDG 更新ユーティリティを使用してレプリケート先リージョン (フランクフルト) のトラフィック割合を徐々に増加させ、ロールアウトを制御 7. 各フェーズゲートで AWS Well-Architected レビュー を適用し、信頼性の柱およびレジリエンスレンズに照らしてアーキテクチャ決定を検証 まとめ NatWest による Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency の実装は、大規模な金融機関がオペレーションの簡素さを犠牲にすることなく、金融規制基準を満たすコンタクトセンターレジリエンスを実現できることを示しました。AWS ネイティブのレプリケーション機能と、目的に応じた自動化ユーティリティ、そして規律あるフェーズアプローチを組み合わせることで、NatWest は単一リージョンアーキテクチャを完全にレジリエントなマルチリージョンコンタクトセンターへと変革し、規制要件を満たしつつカスタマーエクスペリエンスを保護しました。 この取り組みには 20 週間の集中的なエンジニアリング作業が必要でしたが、その結果、完全なリージョン障害にも、お客様が体感できる影響なしに、手動介入せずとも耐えられるアーキテクチャを確立しました。 次のステップ Amazon Connect Customer コンタクトセンターにマルチリージョンレジリエンスを組み込む準備はできましたか？まずは Amazon Connect Customer Global Resiliency のドキュメント と Amazon Lex Global Resiliency ガイドをご確認ください。また、 AWS Well-Architected 信頼性の柱 を活用して現在のアーキテクチャを評価し、実装開始前にレジリエンスのギャップを特定することもできます。 筆者について Prateek Guleria は NatWest の DevOps リードです。自動化の実行、CI/CD パイプラインの開発・実装の監督、AWS プラットフォーム上のクラウドインフラの維持を担当しています。 Srinath Chandrasekharan は NatWest のリリーストレインマネージャーです。プログラム実行の戦略的オーケストレーターとして、すべてのテクノロジーデリバラブルがビジネスおよびテクノロジー OKR に直接整合する形で、正確に計画・同期・実行されることを確保しています。 Baraa Elkosh はイギリス・ロンドン拠点の AWS シニアテクニカルアカウントマネージャーです。エンタープライズ顧客と連携してクラウド導入を加速させ、コンタクトセンターのモダナイゼーションと AI 統合を専門としながら、大規模な運用安定性を確保しています。 Abhay Kumar は NatWest のエンジニアリングディレクターです。コンタクトセンタープラットフォームのアーキテクチャ、開発、保守、品質、セキュリティを担当しています。 Kapil Arora は NatWest のプリンシパルエンジニアで、ソフトウェア業界で 21 年以上の経験を持ち、多彩な技術的バックグラウンドが特徴です。ソフトウェアエンジニアリング、ソリューション設計、データエンジニアリング、クラウドエンジニアリング、DevOps、コンテナ化、AI エージェントおよびエージェンティックアプリケーションフレームワークにわたる経験があります。 Manoj Srinivas はアメリカ・ワシントン州シアトル拠点の Amazon Web Services のプロダクトマネージャーです。Amazon Connect Customer Global Resiliency の開発を推進しており、これは企業が事業継続性とコンプライアンスのために AWS リージョン間でシームレスに Amazon Connect Customer を運用できる機能です。仕事以外では、旅行とサッカーを楽しんでいます。 Abilashkumar P C  はロンドン拠点の Amazon Web Services の Applied AI シニアスペシャリストソリューションアーキテクトです。サーバーレステクノロジーを活用したコンタクトセンター全体で、レジリエントな AI 搭載ソリューションの設計・構築を顧客と共に行っています。 Prabhakar Rajasekar はドイツ・アーヘン拠点の Amazon Web Services WWSO の Applied AI ソリューションアーキテクトです。顧客のデジタルトランスフォーメーションを支援する傍ら、庭や森で子どもたちと過ごす時間を大切にしています。 本記事は 2026 年 7 月 9 日 に公開された「 How NatWest built multi-region resilience with Amazon Connect Customer 」を翻訳したものです。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。

顧客が本来受けるべきセルフサービス体験と、その作り方 Mateo Jackson は AnyCompany Internet で顧客体験 (CX) を統括しています。この 2 四半期、彼のチームは同じ光景を見続けてきました。顧客が状況を説明しても対応できないボットがいて、次のボットに同じ説明を繰り返し、最後は保留のまま待たされた末に、何も知らない担当者と一からやり直す。カスタマーエフォートスコアは悪化し、応対時間は伸び、そして二度目の問い合わせをした顧客は離脱していきます。 Mateo は理想の姿を分かっています。通信障害、請求への異議、機器の交換といったケースを AnyCompany がどう扱うべきか、その方針と応対スクリプト、エスカレーションのルールを何年もかけて書いてきました。ツールが追いついてくれれば世界水準のセルフサービスになると信じて投資してきたのです。ただ、その蓄積を会話型 AI の体験に落とし込む手段が、半年以上の開発プロジェクトを立ち上げる以外に存在しませんでした。 それが今月変わりました。障害対応の手順書はすでに文書化されていて、システム連携も整っていたため、Mateo は火曜日に最初のエージェンティックなセルフサービス体験を構築し、水曜日に数百件の模擬通話でテストし、木曜日には初版を本番稼働させました。彼が実現した体験を紹介します。 朝 6 時 40 分、嵐で町の北側の光ファイバーが切断されました。7 時 15 分には問い合わせが入り始めます。Sofía もその 1 人でした。応答した音声は彼女を名前で呼び、アカウント番号の下 4 桁を確認し、日頃の利用に感謝を伝えます。彼女の通りでは障害が確認済みで、作業員が現場に入っており、復旧見込みは 11 時 30 分です。音声は前夜から残っている別件の問い合わせにも自ら触れ、それがまだ未解決で今回とは別の案件であることを伝えます。さらに、モデムのランプが点灯しているのか点滅しているのかを尋ねます。それによって次の対応が変わるからです。クレジットが適用され、金額と適用条件が途切れずに読み上げられます。彼女のモデムは 3 世代前のものなので、交換の対象になります。通話を続けたまま、スマートフォンに通知が届きます。3 つのルーターの選択肢が並び、それぞれの横に月額料金が表示されます。彼女は真ん中を選びます。音声はその製品名を読み上げて確認し、当日出荷になると伝えます。3 月分の請求について異議を申し立てると、規定により担当者への転送が必要です。電話を取った担当者の画面には、通信障害の状況、クレジット、彼女が選んだルーター、3 月の請求の件がすべて表示されています。Sofía は同じ説明を一度も繰り返していません。最初から最後まで、3 分と少しでした。 この会話体験を構築したのは 2 人です。Nikki Wolf は AnyCompany の Amazon Connect Customer インスタンスの管理者で、システム連携、モデルと権限の設定、会話が動く基盤を担当しています。Mateo は Sofía が耳にする内容そのものを担当しています。どちらも相手の作業を待つ必要はありませんでした。 デモは簡単だ Sofía の通話のように聞こえるものをデモとして作るなら、半日で足ります。プロンプトをいくつか書き、ドキュメントサイトを参照させ、声を選べば、よくある質問にはそれらしく答えてくれます。しかし同時に、それは本番稼働することのないバージョンでもあります。 先ほどの通話をもう一度確認してみてください。重要だった判断のほぼすべては、モデルが決めるべきものではありませんでした。 Sofía には未解決の問い合わせがすでにあった。AI は 2 件目を新規に開始するのか、既存の 1 件を引き継ぐべきか。 彼女はクレジットの対象だったが、先月も受け取っている。それは認められるのか、認められるならいくらまでか。 彼女はまだ本人確認を済ませていなかった。確認前に AI はどこまで話してよいのか。 クレジットの適用条件は途中で区切らず全文を読み上げなければならない。AI が要約して伝えることは許されるのか。 彼女は開始 3 語で担当者を呼ぶよう頼むこともできた。AI はもう一度自力で対応を試みるべきか、即座に転送すべきか。 これらには AnyCompany としての正解があり、Mateo は何年もかけてその答えに辿り着きました。「モデルに任せる」が答えになるものは 1 つもありません。一方でモデルが担う部分、つまり Sofía の苛立ちを読み取ること、通話が切断されたことに彼女が言及したときにトーンを合わせること、4 つの異なるシステムを横断しながら自然な会話を保つことも、同じくらい重要です。しかもそれらは、厳密さと共存した状態で自然に感じられなければなりません。デモが省略するのはまさにこの部分であり、会話型 AI のプロジェクトが止まるのは技術的な理由よりも構造的な理由によります。会話は 1 つのシステムに、業務ルールは別のシステムに、実行結果はさらに別のシステムにあり、実行経路の全体を 1 つのトレースで見られる人がいません。変更のたびに、業務側の要求を各ツールが受け付ける形に誰かが翻訳する必要があります。そうして数週間が過ぎます。出てくるのは可もなく不可もない体験か、あるいは何も出てきません。 Amazon Connect Customer のエージェンティックなセルフサービスの新機能 ここから Amazon Connect Customer で何ができるようになったかを説明します。会話、業務ルール、実行結果が 1 か所にまとまり、答えを知っている人がそれを所有します。 agentic CX designer が一般提供を開始しました。ノーコードのビジュアルキャンバス上で会話を構築できます。柔軟さが求められる部分 (意図の理解、会話の進行、ナレッジの検索など) は、エージェンティック AI が担い、正確さが求められる部分 (本人確認、クレジットの適用可否、法令・規約上の説明など) は、決定論的なルールベースのステップによって厳密に管理されます。エージェンティックなステップと決定論的なステップは同じキャンバス上に並び、AI が推論する箇所とポリシーが適用される箇所を目で確認できます。 Live Sync は、音声での会話とデジタルの画面表示をリアルタイムで同期させる、初の完全統合型エンタープライズ CX テクノロジーです。チャネルを切り替える必要はありません。顧客は通話を続けたまま選択肢を確認し、操作できます。 Touchpoint はデジタルチャネルで顧客が目にする画面を描画します。Amazon Connect Customer 向けの組み込み型クライアント SDK で、自社の Web サイトやモバイルアプリに埋め込みます。同一の会話の中で Web チャット、アプリ内音声、Live Sync のマルチモーダル機能を提供し、顧客が画面で操作した内容をフローに返します。 agentic voice は会話に声を与えます。50 を超える言語と 100 種類以上の音声に対応します。1 つの音声がその場面に応じて口調を変え、人間と同じように割り込みを処理し、顧客が言語を切り替えれば会話の途中でも追随します。別途の調達や個別のシステム連携は必要ありません。 この後は、Mateo がこの体験をどう構築したのか、そして顧客が使い始めた後に何に注目すべきなのかを解説します。 構築する 障害対応のプロセスはすでに文書化されています。障害をどう確認するか、どういう場合にサービスクレジットを適用するか、機器がどの条件で交換対象になるかが書かれています。構築はその文書から始まります。初版を立ち上げるためのラベル付き学習データも、学習させるインテントモデルも必要ありません。 ペルソナから始める Mateo はペルソナから着手します。アシスタントがどう聞こえるべきか、最初に何をすべきか、何を提示してよいか、そしてどの時点で対応を止めて人につなぐべきか。これはプロンプトの設計であり、その中身は新しくチームに加わったメンバーに渡す指示書とよく似ています。 次にモデルを選びます。キャンバス上のエージェンティックなステップごとに、Mateo はドロップダウンからモデルを選び、そのタスクに合わせて調整します。速く自然な会話が必要なステップには応答速度重視のモデルを、複数のツールをまたいで推論し複数ターンにわたる解決策を組み立てるステップには思考の深さに向いたモデルを割り当てます。同じフローの中でも部分ごとに異なるモデルを使えるので、会話のその瞬間に本当に必要な性質に合わせられます。 Amazon Connect Customer はモデル単位やトークン単位の課金ではありません ( 料金ページ を参照してください)。したがって考えるべきことは、どのモデルが Sofía にとって最良の体験になるかだけです。 エージェンティックな推論と決定論的な制御を組み合わせる 続いて Mateo は、解釈の余地を残せない部分に取りかかります。顧客がクレジットの対象になるか、なるとしていくらかは、判断ではありません。それはルールであり、所有者が決まっており、その所有者はモデルではありません。 そこで彼は、会話と判断を別の方式で扱うことにします。 エージェンティックなノード (Generative Journey) は会話の文脈をもとに推論し、許可されたツール群の中から選択して、動的に応答を生成します。Sofía の通話では、Generative Journey ノードが彼女の話を聞き、必要としているものを解釈し、モデムについて確認の質問をし、障害の状況を説明します。彼女の口調やアカウントの個別事情にも自然に合わせます。 決定論的なノードは、明示的な検証ルールを持つスロットを使います。agentic CX designer には日付、メールアドレス、電話番号、英数字文字列といった値に対応する組み込みスロットタイプが用意されています。値の範囲が限られる場合は、はい/いいえ、料金プランの区分、有効な PIN の短いリストなど、独自のスロットタイプも作成できます。各スロットは正規表現による検証、リトライ回数の設定、検証に失敗した場合のエスカレーション経路を明示的に指定できます。Sofía のクレジットについては、決定論的なノードが彼女のアカウントを適用条件に照らして確認し、正確な金額を返します。曖昧さはなく、通話ごとのばらつきもありません。 2 種類のノードはキャンバス上で隣り合って配置されます。両者の接続は視覚的に確認でき、キャンバスは両者をまたいで会話の状態を完全に保持します。収集したスロット、設定した変数、呼び出したツール、そして顧客が手続きのどこまで進んでいるかです。この状態は会話がエスカレーションしても引き継がれ、文脈が担当者や別の AI エージェントに一緒に渡ります。 薬剤師を思い浮かべてください。あなたは薬剤師に話を聞いてもらい、他に何を服用しているか尋ねてほしいし、声から鼻づまりに気づいてほしいと思うでしょう。一方で用量をその場の思いつきで決めてほしいとは思わないはずです。それが決定論的な制御とエージェンティック AI を組み合わせるということです。各ステップで AI にどこまで判断させるかを選べて、同じワークフローの中でいつでも変更できます。 ナレッジ: アシスタントが知っていること Sofía がインターネットが使えない理由を尋ねたとき、アシスタントは AnyCompany の障害対応手順に基づいて答えます。モデルの学習データからではありません。ナレッジはワークスペース内に置かれ、よくある質問には Q&A エントリ、参照量の多い資料には文書のアップロードという形で管理します。アシスタントは実行時にこの承認済みのコンテンツから情報を取得します。 アクション: 実際に処理を行うシステムにつなぐ アシスタントは Sofía のアカウントを照会し、ネットワーク運用システムから障害の状況を確認し、サービスクレジットを登録する必要があります。ここで Nikki の担当範囲になります。 agentic CX designer のデータリクエストノードが外部システムを呼び出します。一般提供の時点で 2 つの連携方式が使えます。 REST データリクエストは、アクセス可能なエンドポイントを持つ任意の API を GET / POST / PUT / DELETE で呼び出します。Nikki はアカウント照会、障害状況の確認、クレジットの登録という 3 つを設定します。それぞれについてエンドポイント、認証、リクエストのペイロード、レスポンスのマッピングを定義します。呼び出しが失敗したときの挙動、つまりリトライするのか、代替経路に進むのか、エスカレーションするのかも定義します。 MCP 経由の呼び出し (MCP egress) では、リモートの Model Context Protocol エンドポイントが公開しているツールを呼び出します。すでに AgentCore Gateway でツールを公開しているなら、管理者がワークスペースの設定で MCP エンドポイントを一度登録するだけです。Lambda のラッパーも、間に挟む API Gateway も不要で、designer が MCP プロトコルで直接ツールを呼び出します。 いずれの方式でも、API キーやトークンといった秘密情報はワークスペースに保存し、ノードごとに直接書き込むのではなく、データリクエストのヘッダーから参照します。 この役割分担が重要です。Mateo は会話の 1 ステップとしてデータリクエストを配置するだけです。何を渡し (アカウント ID)、何が返ってくるか (クレジット額、障害状況) は見えますが、エンドポイントの URL や認証の設定を知る必要はありません。Nikki は会話の設計に手を触れずに、認証情報をローテーションし、エンドポイントを変更し、レスポンスのマッピングを直せます。一度設定すれば、複数のフローやアプリケーションで再利用できます。 音声を設定する Mateo が構築している体験は音声で顧客に提供されるため、彼は Connect Customer のフロー内で「音声の設定」(Set Voice) ブロックを使って音声ペルソナを設定します。designer は会話を組み立て、Connect Customer はどの音声を使い、どう聞こえるかを制御します。 agentic voice は話者交代をリアルタイムで処理し、顧客が訂正のために割り込んでいるのか、考えながら声に出しているだけなのかを見分けます。音声は会話の展開に応じて感情を調整し、悪い知らせを伝えるときは穏やかに、解決を確認するときは明るくなります。顧客が文の途中で言語を切り替えても、音声は間を置かずに追随し、50 を超える対応言語と 100 種類以上の音声から使い分けます。 この役割分担によって、応答速度の調整、割り込みの挙動、フェイルオーバーといった音声配信の側面は基盤の所有者が持ち、会話のロジックは CX の所有者が持つ形になります。デプロイのサイクルも権限も別です。 聞かせるだけでなく、見せる — Live Sync 聞くよりも見るほうが分かりやすいものがあります。Sofía はルーターの交換対象で、月額料金の異なる 3 機種が候補にあります。3 つの選択肢を、しかも 2 度読み上げるのは、顧客を離脱させる典型的なやり方です。 Live Sync を使うと、アシスタントが通知を送り、3 つの選択肢が Sofía のスマートフォンに表示されます。通話は続いたままです。彼女が 1 つをタップすると、会話はそのまま進み、選んだ内容が会話に反映されます。別のアプリも、「一度切って Web サイトをご覧ください」も必要ありません。音声と画面をまたいだ 1 つの連続した体験になります。 Touchpoint が画面側を描画します。Web サイトやモバイルアプリに埋め込むクライアント SDK で、同一の会話セッション内に Live Sync のマルチモーダルなカードを表示し、タップやフォームの送信といった顧客の操作をフローに返します。 文脈ごと引き継ぎ、やり直させない 人につなぐこと、あるいは別の AI エージェントにつなぐことが正しい答えである場合もあります。そのとき、会話がそれまでに確定させた内容はすべて一緒に渡ります。アカウント、確認済みの障害、クレジット、顧客が選んだルーターです。収集済みのスロット、変数、ツールの実行結果を含むキャンバスの状態が、引き継ぎ先に渡ります。顧客に一からやり直させることはありません。 キャンバスは形になりました。次に Mateo が確かめるべきなのは、正しく動くかどうかです。 テストする テストは 2 つの層で行い、互いを補完します。 設計しながらキャンバス上でテストする designer には 4 つのテストモードがあります。会話全体を通すアプリケーションテスト、単一フローを試すフローテスト、発話とフローの対応を確かめるルーティングテスト、そして回帰テストとして保存しておくフローロジックのテストです。4 つはいずれもターンごとのデバッガー上で動き、会話が通過した各ノードについて次の内容を確認できます。入力と出力、蓄積されていくスロットと変数の値、Generative Journey / Generative Text / Transform ノードの推論内容 (モデルが何を検討し、どのツールを選び、なぜそうしたか)、ガードレールの判定 (何が評価され、何が通過し、何が遮断されたか)、ナレッジの検索結果 (どの Q&A エントリや文書の断片が取得されたか)、そしてデータリクエストの結果 (呼び出しのペイロード、レスポンス、発動したエラー処理) です。 変更は再デプロイなしでテストチャットに即座に反映されます。フローを保存し、テストを実行し、結果を見る、という流れです。クレジットが 30 ドルではなく 15 ドルで返ってきたとき、モデルが Sofía の意図を読み違えたのか、データリクエストがアカウントシステムから誤った値を取得したのかが分かります。バグの種類が違えば、直すべき担当者も違います。 まずは決定論的なステップと会話の出口をテストしてください。クレジットの金額、規約上の説明、エスカレーションの発動条件です。間違っていたときに損失が出るのはここです。ガードレールの判定結果はターン単位で確認できるため、プロンプトインジェクションの試行や方針違反が、実際のトラフィックが体験に届く前に捕捉されていることを確かめられます。CI/CD パイプラインを運用しているチームであれば、このテスト機構をデプロイの承認ゲートの前段で会話ロジックの検証に使えます。 トラフィックを流す前に、コンタクト全体の経路をテストする designer がテストするのは会話です。Amazon Connect Customer のテストとシミュレーション機能は、コンタクト全体の経路をテストします。通話を振り分ける Connect Customer のフロー、「音声の設定」ブロック、Agentic CX ブロックの呼び出し、そしてエスカレーション先のキューの設定までが対象です。テストは自然な文章で記述し、実際には呼び出したくない外部システムはモックに置き換え、変更のたびに再実行されるようスケジュールできます。意味的な一致で判定するため、プロンプトの言い換えによって、本来通るべきテストが落ちることはありません。 テストとシミュレーション機能は、複数の会話をまたぐエンドツーエンドのテストケースに対応します。コンタクト属性の検証、Lambda や Agentic CX の挙動の上書き、キューや営業時間の上書き、顧客としてのテキスト入力や DTMF 入力の送信ができます。2 つの機能を併用してください。設計時の会話ロジックの検証には designer のキャンバスを、デプロイ後の組み上がった体験の検証には Connect Customer のシミュレーションを使います。 公開、デプロイ、そして変更 テストが通ったら、Mateo はビルドを作成します。ビルドはその時点のすべてのフロー、アプリケーションの設定、ガードレールの割り当てを固定した、変更不可のスナップショットです。2 つのビルドを比較すると、変更されたノード、更新されたガードレールの割り当て、新たに追加された連携といった差分が分かります。管理者は、レビュー済みのビルドだけが本番に到達するよう担保できます。 ビルドをデプロイすると本番稼働します。以前のビルドは保持されるため、本番で問題が起きた場合のロールバックは 1 操作で済みます。 Connect Customer のフローは Agentic CX ブロックを通じて designer のアプリケーションを呼び出します。このブロックをつなげば、同一のビルドが音声、チャット、SMS を担います。どのチャネルになるかは Connect Customer フローのチャネル設定で決まります。電話をかけた顧客は agentic voice を通して同じ内容を聞き、チャットで入力した顧客も同じロジック、同じ決定論的なガードレール、同じ結果を得ます。1 つのビルドで、サポート対象のすべてのチャネルに対応できます。 最適化する いま、実際の顧客が既に利用しています。分析オーバーレイは、Mateo が構築したフロー上にトラフィックと離脱率を直接表示します。つまり、同じキャンバスに数値が表示されるということです。もし発信者の 3 分の 1 が同じステップで離脱していれば、どのステップかが分かり、その場で開けます。このフィードバックの循環によって、初版が良い版になるまでの時間が数か月ではなく同じ週の中に収まります。 ガードレールはターンごとに評価され、記録されます。顧客のプロンプトが方針の境界を押している状況を検知できます。モデルの出力が決定論的なノードと矛盾した場合 (業務ルールと一致しないクレジット額など)、決定論的なノードの結果が優先されます。権限を持つのはモデルではなくフローです。 会話分析では、個々のコンタクトを 1 回のやり取りとその背後にある推論の単位まで掘り下げて把握できます。モデルがなぜその経路を選んだのか、どのナレッジを取得したのか、どこで引き継いだのかを追跡できます。パフォーマンス評価は自社の品質基準に照らしてコンタクトを採点し、人手の抜き取り確認ではなく一貫した基準で評価します。ガードレールの評価結果と監査ログはコンプライアンス関連のツールに書き出せます。すべての書き込みと削除の操作は、実行者、時刻、対象リソースとともに記録されます。 翌週に起きたこと 翌週の月曜日、Mateo が分析オーバーレイを開くと、発信者の 28% がクレジットの説明のステップで離脱していることが分かりました。いくつかの会話を聞いてみると、顧客は「利用規約」という言葉を聞いて、担当者につながるまで待たされると受け取っていたのです。 彼はそのノードのプロンプトを書き直します。「これから利用規約を読み上げます」ではなく、「お客様のクレジットの詳細をご案内します。15 秒ほどで終わります」と言わせるようにしました。保存し、キャンバス上でテストし、新しいビルドを作成して、昼までにデプロイします。 水曜日には、そのステップの離脱率が 9% まで下がっていました。体験そのものは、2 週間前の火曜日に彼が構築したものと同じです。ただ良くなったのです。顧客にいちばん近い人が、端から端まで所有しているからです。 始めましょう 障害を確認する手順、サービスクレジットの適用方針、機器が交換対象になる条件といったプロセスがすでに文書になっているなら、いちばん時間のかかる部分はもう手元にあります。 体験を所有している方は、 Amazon Connect Customer のコンソール を開き、agentic CX designer で最初のアプリケーションを作成してください。セットアップの手順は 管理者ガイド で確認できます。順を追って学びたい場合は AWS Skill Builder のコースも用意されています。 プラットフォームを所有している方は、同じ 管理者ガイド で連携のパターン、REST と MCP の設定、ワークスペースの管理、ビルドとデプロイのパイプラインを確認できます。 Web の体験を追加する場合は、 Touchpoint のクライアント SDK を導入して、自社の Web サイトやモバイルアプリでチャット、音声、Live Sync を提供してください。 チームで評価する場合は、 ガイド付きワークショップをリクエスト してください。アーキテクチャの解説と、自社のユースケースに沿ったハンズオンでの構築を体験できます。 著者について Alex Schrameyer (he/him) は Amazon Web Services (AWS) の Worldwide Solutions Architect Lead for Agentic Experience で、シカゴ近郊を拠点としています。優れた応対担当者の体験こそが優れたカスタマーサービスの基礎であると考え、人間の担当者と AI エージェントの双方が滞りのない顧客体験を提供できるようにするソリューションの設計に取り組んでいます。世界各地を旅するのが好きで、地元の野球場やテーマパークで見かけることがあるかもしれません。 本記事は 2026 年 9 月 2 日に公開された「 Blend structured business logic with agentic AI to deliver delightful conversational experiences 」を翻訳したものです。この記事はソリューションアーキテクトの夏堀京司が翻訳しました。

本ブログは 2024 年 11 月 24 日に公開された AWS Public Sector ブログ Deploying AWS Modular Data Center: From ordering to delivery and installation を翻訳したものです。 Amazon Web Services (AWS) Modular Data Center (MDC) とは、AWS のマネージドデータセンターを迅速にデプロイするサービスで、インフラが限られた場所でも、ロケーション依存型アプリケーションやレイテンシー依存型アプリケーションの実行が可能になります。遠隔地でのデプロイ時間を短縮し、最大 5 ラック の AWS Outposts や AWS Snow Family デバイスを収容します。MDC は 20 フィートの輸送用コンテナ 2つで構成され、ICD-705 （米国の情報機関が機密情報を扱う施設の物理的・技術的セキュリティ基準を定めた指令）準拠のシールド筐体に配電機能、冗長冷却 (N+1)、セキュリティ、監視、消火設備など、重要なインフラ要素を備えたデータセンターとして機能する自己完結型ソリューションです。AWS MDC サービスは、現場で低遅延のアプリケーションを実行する必要があるものの、データセンターを置く十分なスペースがないお客様向けに設計されたものです。例えば、防衛、国家安全保障、人道支援機関では、MDC を導入することで計算負荷の高いワークロードやストレージ負荷の高いワークロードをタクティカルエッジで実行でき、AI や機械学習によって大量のデータ処理を行い、わずかな遅れも許されない状況でもリアルタイムの意思決定が可能になります。 本投稿では、MDC を導入するためのエンドツーエンドのプロセスについてご説明します。合わせて、 Amazon Web Services (AWS) とお客様の役割や責任の分担についても解説し、デプロイメントの成功、運用可用性の向上、セキュリティ体制の強化に向けて明確な指針を提供します。サイトへの MDC の導入方法を 6 つのステージで示しておりますので、ぜひ最後までお読みください。  6 つのデプロイステージ 導入方法はお客様ごとに異なるものです。そのため、AWS はお客様とプロセス全体で常に緊密に連携し、MDC の納入を確実かつ円滑に行います。MDC のデプロイプロセスは次の 6 つのステージで構成されます。 リクエストの送信 現地調査結果の確認および現地準備 発注承認 納品 設置および試運転 政府セキュリティ認定 図 1.MDC 導入の工程: エンドツーエンドの全 6 ステージ。 以下では、各ステージの詳細を説明します。導入プロセスを理解いただくことで、効率的な準備にお役立てください。 （注：以下のプロセスはアメリカ国内のお客様を対象とした説明となっており、また、日本のお客様にはアクセスができないURL等がございます。ご不明な点がありましたらAWSアカウントチームまでお問い合わせ下さい） ステージ 1: リクエストの送信 このプロセスでは、お客様固有のニーズに対応するためのコンサルティングを行います。まず、 AWS マネジメントコンソール の AWS MDC ページからお問い合わせフォームに入力いただき、AWS に送信します (図 2)。フォームを送信後、2 営業日以内に AWS からプライマリアカウントオーナーにご連絡いたします。組織内でプライマリアカウントオーナーが不明の場合は、AWS アカウントチームまでお問い合わせください。 このステージでは、AWS はお客様と連携して、MDC のユースケースを明確にし、サイト準備アンケートなどで設置サイトの情報を収集します。これには、インフラの依存関係を特定するために、導入場所、気象条件、電力、ネットワーク接続、セキュリティ要件などのサイト特性に関する情報も含まれます。また、お客様のニーズに最適な MDC 構成と AWS Outposts または AWS Snowball Edge のデバイス容量を決定するためのお手伝いもします。事前定義された構成がお客様のニーズに合わない場合は、お客様の要件に合わせたカスタム構成を作成するために協力させていただきます。 図 2.AWS マネジメントコンソールのお問い合わせフォーム。 ステージ 2: 現地調査結果の確認および現地準備 お客様からのリクエストとサイト情報の確認後、AWS の技術者または AWS の資格を持つ技術者を派遣し、サイト準備アンケートの内容を基に現地調査を実施します。この現地訪問は、そのサイトが MDC の各要件 (以下の一覧参照) に対応しているかを確認することが目的となります。そのため、現地訪問にあたり、お客様には AWS チームに現地の連絡先と立ち入り権限をご提供いただく必要があります。現地では、設置を進めるための情報を収集し、MDC 設置前に解決すべき問題を特定します。現地調査を完了したのち、その結果を確認し、サイトの準備に向け追加対応が必要な場合はお客様にお知らせします。サイトの MDC 設置要件への対応は、お客様の責任において行っていただくものですが、AWS は対応を完了していただくための必要な情報を提供し、設置前には現地の状況を確認させていただきます。サイトでの MDC の設置と試運転を行うにあたり、お客様には AWS のチームと協力の上、当該サイトがすべての要件を満たしているかどうかを確認し、現地調査結果の検証をすべてクリアしていただく必要があります。 カテゴリ 要件 設置場所 (据付面) 設置には、20 フィート × 30 フィートのコンクリート基礎面または砕石地盤が必要。 離隔スペース MDC 設置面積は 16 フィート × 20 フィート (4.9 m x 6.1 m)。全周囲に少なくとも 8 フィート (2.4 m) の保守スペースを確保。ラック搬入を容易にするため、エリア全体においてフォークリフトなどの荷役機器の移動が可能であること。 耐荷重 MDC の設置および撤去を行う場所と搬入動線は、MDC、荷役機器、配送車両の合計重量に耐えられること。設置場所の据付面そのものは、沈下することなく最低 50,000ポンドの耐荷重があること。 耐震補強 施設への MDC 設置期間中は、規制または建築基準法で定める範囲において、適切な耐震ブレースまたはアンカーの設置、維持が必要。 施設へのアクセス MDC 設備に対し、AWS による MDC への物理的アクセス、保守、MDC の撤去を阻害するような変更を行わないこと。フェンスやセキュリティカメラなどの追加のセキュリティ対策が必要な場合は、AWS の担当者までご相談ください。 温度および湿度 周囲の外気温は -20°F (-30°C)～127°F (53°C) の範囲とし、相対湿度は 5%～95% であること。MDC を屋内に設置する場合、十分な空気循環を行い、動作中は一定の温度と湿度の範囲を維持すること。 標高 MDC の設置場所は、海抜 10,000フィート (3,050メートル) 未満の標高にあること。 電源 二重化構成の場合、MDC には三相 400/480 VAC、50/60Hz、175A の電源が 2 系統必要。冗長性を下げた構成の場合は、単一の電源系統で動作可能。 ネットワーク MDC のネットワーク要件は、お客様のニーズによって異なる場合があります。AWS の担当者までご相談ください。MDC のネットワークラックには、お客様支給のネットワーク機器および暗号化ハードウェアを最大 10U まで収容可能。ラックはUPSで保護された冗長A+B電源の供給も可能。 サイトの要件について、より詳しくは AWS Modular Data Center User Guide をご参照ください。 ステージ 3: 発注承認 現場調査結果の確認後、サービス利用規約に同意いただき、発注書の発行をもって発注手続きを完了します。そこから、MDC の構築、事前設定、出荷準備をサービスチームが行います。MDC は製造プロセス完了後、お客様の現地ご担当者と納品日および設置日を調整したうえで出荷されます。 ステージ 4: 納品 MDC の準備が整い次第、ユニットを現地に配送し、組み立てと設置作業を行うための調整をお客様と進めます。MDC は、不正開封防止シールや不透明梱包など、標準的な商業用セキュリティ対策を講じて非機密扱いとして出荷されます。機密扱いでの配送が必要な場合は、お客様と連携のうえ、MDC を米国本土 (CONUS) の空港または出発港まで護送する運送業者の手配もお手伝いいたします。MDC の輸送は、車両、鉄道、船舶、軍用機 (C-17 または C-5 のみ) から選択できます。 AWS は、運送業者との調整、積み込みおよび荷降ろし作業、お客様のサイトへの MDC の配送を含む、CONUS 内での輸送と物流の統括責任を負います。また、現場要件を満たした水平な据付面上に MDC を設置するためのクレーンやフォークリフトなどの重機も手配します。サイトが米国本土外 (OCONOUS) である場合、運送業者との調整、積み込みおよび荷降ろし、配送、登録輸入者としての手続きなど、輸送と物流に関する対応はお客様にて行っていただきます。また、MDC を水平な据付面上に設置するための機器類もお客様手配となります。  ステージ 5: 設置および試運転 MDC の設置は、AWS チームがサイトに到着し、お客様の指定担当者と到着確認を行った後すぐに開始されます。荷解き作業を開始する前に、AWS チームが最終的なサイト確認を実施し、現地の状況が MDC の要件に合致しているかをあらためて確認します。 サイトが必要な要件を満たしていない場合、作業は延期となります。作業を延期することがないよう、お客様には MDC の納品前にサイト準備作業をすべて完了いただくことが極めて重要です。 また、AWS チームがサイトにアクセスするための許可手続きは、お客様側で行っていただく必要があります。MDC をデプロイする場所に AWS がアクセスできない場合、AWS のサポートが限定される場合があります。 AWS チームが MDC を指定のコンクリートまたは砕石基礎に配置し、組み立てと設置を進めます。所要期間はサイトの状況にもよりますが、通常 1〜2 週間です。機器類および電気システムを含むすべての MDC コンポーネントの組み立て、設置、テストは、AWS にて管理します。また、AWS が提供する機器に使用するすべての光ファイバーは、AWS が準備し、MDC 内に敷設します (電気設備の検査やテストも含みます)。お客様には、MDC を正常に動作させるための、電源、ネットワーク、緊急管理システム用など、すべての外部ファイバーケーブルと電源ケーブルを用意いただき、接続作業を対応いただきます。設置作業時において MDC への接続および通電は、お客様側の有資格電気技術者が実施することが義務付けられています。お客様は、AWS 起動手順のほか、関連法令、電気規程、建築消防法規に従って MDC への通電と接続を実施する責任を担います。 試運転が完了すると、メンテナンスサービスが開始されます。MDC は物理的にお客様のサイトに設置されているため、本体のメンテナンスは AWS とお客様との責任共有となります。AWS は、AWS の技術者または AWS 認定の技術者による定期検査や修理など、予防および是正保守を提供します。重要なスペアパーツの準備、保管も行い、納品に時間がかかる部品類でもすぐに使えるよう常備します。さらに AWS は MDC 内に消火システムを設置し、この保守も行います。お客様は MDC の定期的な検査、監視を行い、エラー状態が発生した際は AWS に速やかに報告する責任を負います。また、問題発生時にはサイト常駐担当者にアラート発報するよう、消火・警報システムとオペレーションセンターを接続しておき、即時対応を徹底する必要があります。MDC の物理的なセキュリティ維持もお客様側の責任となります。なお、MDC にはモニタリングシステムが組み込まれています。MDC を AWS リージョン に接続すると、 Amazon CloudWatch と連携でき、MDC の状態をリモート監視できます。 MDC は、ICD-705 に基づく機密情報隔離施設 (SCIF) の要件を満たすように設計されており、TS/SCI (Top Secret/Sensitive Compartmented Information ) レベルまでのデータをホストする認定を取得することができます。MDC は、電磁波盗聴対策 (TEMPEST)、無線周波数 (RF) シールドに加え、音響や熱に関する各種要件に完全準拠した構築、試験が行われています。MDC を SCIF として認定する必要がある場合、AWS は試運転の完了後に、お客様の承認担当者 (AO) が実施する認定審査に対応できる状態に準備します。適切な AO の選定と必要な認定取得は、お客様の責任にて進めていただきます。 ステージ 6: 政府セキュリティ認定 特定の政府機関で MDC を使用する場合、お客様は適切な AO から必要な運用権限 (ATO) や接続権限 (ATC) を取得する必要があります。認定の手続きにおいて、AWS は必要な書類を提供し、お客様をサポートします。認定が必要な場合、MDC に収容する機密ワークロード用の AWS ラックの設置およびテストは、必ず認定取得後に実施することになります。認定が下り次第、ラックの設置が可能になり、AWS が MDC 内の AWS ラックの組み立て、設置、テストを行います。  まとめ 本投稿では、リクエストの送信から納品、設置まで、AWS Modular Data Center をデプロイするための 6 つのステージについて説明しました。MDC の導入をスムーズに達成するためには、各ステージで以下のポイントを押さえることが重要です。  リクエストの送信 — AWS マネジメントコンソールのお問い合わせフォームにご記入ください。お客様の要件をもとに、AWS と連携して MDC の構成を確定させます。また、サイト準備アンケートにもご回答いただきます。 現地調査結果の確認および現地準備 — AWS とともに現地調査を実施します。現地調査の結果から、サイトに必要な作業を行い、MDCの設置と試運転の前に完了させます。 発注承認 — サービス利用規約への同意と発注書の発行をもって発注を確定します。AWS は MDC の構築、事前設定、出荷準備に進みます。 納品 — 輸送、物流は AWS との調整が必要です。サイトが米国本土外の場合は、物流と重機類はお客様にて手配いただきます。また、サイトが MDC の到着を受け入れ、設置を開始できる状態にしておきます。 設置および試運転 — AWS がサイトに立ち入るためのアクセス権を確保いただきます。設置チームが作業できるよう、電源接続をご準備ください。MDC の組み立て、設置、テストは AWS が実施します。 政府セキュリティ認定 — 認定が必要な場合は、お客様の AO から ATO および/または ATC を取得してください。AWS はドキュメンテーションを支援し、認定取得後にラックの設置を完了します。 注意: AWS Modular Data Center は現在、米国 Joint Warfighting Cloud Capability (JWCC) 契約に基づく政府機関のお客様のみがご利用いただけます。AWS Modular Data Center は現在、AWS GovCloud (米国西部) リージョンと AWS GovCloud (米国東部) リージョンでサポートされています。 AWS Modular Data Center の詳しい情報は、お客様の AWS アカウント担当者までお問い合わせください。 タグ:  Amazon CloudWatch ,  AWS GovCloud (US) ,  AWS Management Console ,  AWS Outposts ,  AWS Public Sector ,  AWS Snow Family ,  AWS Snowball Edge ,  defense ,  government ,  security ,  storage ,  technical how-to

2026 年 8 月 4 日、「製薬企業向け Claude Code on AWS ワークショップ 〜創薬研究を加速する AI コーディングエージェントの活用〜」を開催しました。10 社以上の製薬企業から創薬研究者と研究 IT のご担当者にお集まりいただき、ハンズオンを中心に、実際に Claude Code on AWS の導入を進める第一三共株式会社とＪＣＲファーマ株式会社、および Anthropic Japan 合同会社による登壇セッションも実施しました。 参加者は、AI コーディングエージェントを初めて使う方から、既に研究業務で Claude Code を活用している方まで様々でしたが、アンケート（回答 47 件）の総合満足度は 4.70 / 5.00 であり、「ワークショップに参加して世界が変わった」「わずか半日で欲しい研究アプリが作れたことに感動した」「自社で利用していく際のイメージが掴めた」といった声をいただくなど高い評価をいただくことができました。 本記事では、イベントの背景や当日の様子をお届けいたします。 目次 ワークショップのゴール 開催の背景：AI for Science の現在地と実践 ハンズオンの内容: 創薬研究の仕事はどう変わるか ハンズオン実行環境：Claude Code を組織で安全に活用するには お客様登壇: 先行する創薬研究現場での実践 第一三共株式会社 ＪＣＲファーマ株式会社 Anthropic Japan 合同会社様登壇: 研究者自身が AI エージェントを使う意義 体験を組織の実践へ まとめ ワークショップのゴール 本ワークショップが目指したのは、Claude Code の細かな機能やプロンプト技法の習得ではありません。参加者自身の研究テーマや興味のある題材を用いて、AI とともに創薬研究の様々な業務に取り組み、研究の進め方や研究者の役割がどう変わるかを体感していただくことです。何を AI に任せられ、何を人間が行うべきかは、実際の業務に近い領域で使い込んでこそ初めて見えてきます。そのため、いち早く実践を始め、 AI が創薬研究にもたらす可能性と人が担うべき役割を見極め、今後の研究の進め方を考える契機にしていただくべく、本ワークショップを企画しました。 開催の背景：AI for Science の現在地と実践 ライフサイエンス業界を取り巻く現状として、AI が具体的な創薬成果につながり始める一方、組織展開には大きな隔たりがあります。  Deloitte 社の調査 によると、ヘルスケア・ライフサイエンス企業を対象とした調査で、AI をうまくスケールできたとの回答は 22%、AI への取り組みで大きなビジネス成果を得たとの回答はわずか 9% にとどまりました。その一方で、例えば Insilico Medicine は AI で創出した特発性肺線維症の治療薬候補について  Phase III 臨床試験を開始したと発表 しているなど、AI 活用を実際の創薬成果に繋げる企業と展開に苦戦する企業との差が開きつつあります。 一度の回答から情報収集、計画、作業、検証という一連の仕事へと広げる AI エージェントは、仮説を立て解析や実験を行う創薬研究とも重なり、研究者は問いと判断に集中するという新しい役割分担を可能にします。ただ多くの企業が同じフロンティアモデルを利用できるいま、差を生むのはモデル性能やツール導入ではありません。自社の知見や業務の型を AI エージェントに正確に与え、AI エージェントに何を任せどこで人が介入するかを設計して初めて、研究現場で大きな成果を生む形になります。こうした設計の力は、実際に近い業務で試行錯誤しなければ体得できず、その第一歩になればと今回のイベントの企画に繋がりました。 今回題材としたのは、Anthropic が開発する代表的な AI コーディングエージェントである Claude Code です。コード生成に限らず、調査や分析、成果物の作成など研究の様々な業務で活用できます。AWS と Anthropic は戦略的協業を結んでおり、AWS は Anthropic のプライマリクラウドプロバイダーとして、お客様が Claude をセキュアかつ大規模に活用できる環境を提供しています。 ハンズオンの内容: 創薬研究の仕事はどう変わるか ハンズオンは二部構成でした。前半では研究上の判断を支える調査とレポート作成を行い、後半ではその判断プロセスないし関心のある研究業務を Web アプリケーションとして AWS 上に構築しました。用意されたプロンプトを順番に貼り付けるのではなく、参加者自身が目的と基準を言葉にし、Claude Code に作業を任せ、結果を確かめながら方向を調整しました。詳しいシナリオや当日の操作手順に興味のある方は、 こちらの URL をご覧ください。 前半の題材は、薬の作用先となる複数の分子候補の中から研究で優先するものを選定する「Target Prioritization ( 標的の優先順位付け) 」です。例えば 「原発性高コレステロール血症」という疾患では、 HMGCR、NPC1L1、PCSK9 などが標的候補となりますが、対象患者、既存治療との違い、安全性など、重視する基準を複数定めることによってアプローチするべき候補の優先順位が変わります。 今回、創薬研究者の方々には、関心のある疾患や実際の研究テーマを自ら選んでいただき、選定基準と 2〜5 件の標的候補を Claude Code と対話しながら決めていただきました。創薬研究に馴染みのない方には、AWS 側で事前にシナリオを用意しました。 テーマと基準が固まると、Claude Code が Open Targets、Europe PMC、ClinicalTrials.gov などの公開 API や、AWS が幅広いオープンデータの公開と利用を支援する Registry of Open Data on AWS に掲載されたデータセットも参照しながら根拠を集め、候補比較のレポートを作成します。参加者は出典や反証を確認し、条件を変えた際の順位を検証しながら、判断の理由と不確実性を判断メモにまとめていきました。 実際のハンズオン操作画面。研究アシスタントとして動く Claude Code（右側）と対話しながら、Target Prioritization の分析レポート（左側）を作成していきます。 後半では、前半の判断プロセスや参加者が関心を持つ研究業務を題材に、AI エージェントが動くアプリケーションを AWS 上に構築しました。Claude Code の質問に答えながら要件を固め、設計書を確認して GO を出すと、コード作成、テスト、インフラ構築、デプロイまでが進みます。参加者はコードを書かず、作るものを人と AI で合意してから実装へ進むプロセスを体験しました。 ハンズオン実行環境：Claude Code を組織で安全に活用するには 当日は、Claude の呼び出しに Amazon Bedrock を利用しました。Amazon Bedrock では、入力と出力はモデル提供者に共有されず、基盤モデルの学習にも使用されません。 AWS IAM による権限管理、 AWS CloudTrail による操作記録、 AWS PrivateLink によるプライベート接続など、既存の AWS のセキュリティ統制の中で Claude Code を利用できます。さらに、データレジデンシー要件がある場合は、対応モデルで 日本国内クロスリージョン推論 (Japan Cross Region Inference) を利用することで、推論処理を国内リージョンに限定しデータを日本国内に留めることもできます。 一方、組織への展開には、モデル利用のガバナンスや、会社支給 PC への導入、研究データの扱い、認証・権限、利用者ごとの環境差といった課題があります。研究部門の方々と普段お話しするなかでも、こうした点が個人の試行から組織利用へ進む際の壁として挙がります。 それを解決する選択肢の一つが、今回利用した RADS ( Remote AWS Development Station ) です。 RADS は、 Amazon EC2 ベースのクラウドワークステーションを Web ポータルから構築・管理することができる AWS 公式サンプル実装であり、 GitHub で公開 されています。Web ポータルから Claude Code などがインストールされた AI コーディング環境を作成・起動・停止し、Amazon DCV によるリモートデスクトップ、ブラウザの Code Editor、SSH 等で接続して使うことができます。以下のような特徴があります。 AI 環境がプリセット済み：Claude Code などを Amazon Bedrock 向け設定込みで導入済み API キー配布や初期設定が不要：ワークステーション (EC2) の IAM ロール経由で自社アカウント内の Bedrock を呼び出す PC を閉じても稼働継続：長時間タスクをエージェントに任せられ、マシン性能も変更可能 ローカルに影響しないサンドボックス: 各環境が独立した EC2 インスタンスのため手元の PC に影響が及ばない お客様登壇: 先行する創薬研究現場での実践 当日は、ハンズオンでの体験を実際の業務へつなげる材料として、Claude Code on AWS の研究現場への導入・展開を進める 2 社に、研究部門と IT 部門それぞれの視点からご登壇いただきました。 第一三共株式会社 第一三共株式会社の田村様からは、「Coding Agent で変わる創薬 DRY 解析」と題してご発表いただきました。田村様が所属されている研究部門にて取られた DRY 研究員への社内アンケートでは、92% が「Coding Agent がなくなると業務に影響する」、85% が「時間やスキルが理由で以前はできなかった業務を遂行できた」と回答したとのことです。具体例として、十分な作業時間を確保できず、4 か月間着手できずにいた大量の化合物データの SAR 解析を Claude Code との対話で約 1 時間で完了した事例や、100 件以上の非構造情報を含む文献や特許からデータを抽出した事例、 AWS Parallel Computing Service (AWS PCS) と連携した解析の取組みなどを紹介いただきました。また、定型業務は Agent Skills や プライベート Plugins として GitHub 上のプライベートレポジトリで共有し、個人の成功パターンをチームで再利用できる仕組みも整備されています。ハルシネーションを 100% 防ぐことは原理上できなくても、後段の解析や実験で結果を検証できるため、創薬研究は AI エージェントを活用しやすい領域ではないかとの見解も示されました。 ＪＣＲファーマ株式会社 ＪＣＲファーマ株式会社の東本様からは、「Claude Code on AWS で創薬研究・業務を加速する」と題してご発表いただきました。チャット型 AI では、提示された手順やコードの実行、エラー対応を利用する人間側が担わねばなりません。AI エージェントは、作成・テスト・修正までを自ら進めます。その様子を AWS から提供したワークショップで実際に体感されたことで、自律実行への懸念から、従来の手間を解決できるという見方へ変わったといいます。 導入には、自社の AWS 環境から Amazon Bedrock 経由で Claude を利用する構成を選択しました。国内でのデータ保管、既存のセキュリティ運用の踏襲、従量課金で小さく始められることが決め手となり、AWS のイベントで体験してから約 10 日でリリースに至りました。研究者が環境構築やエラー対応から離れ、解析そのものに集中できる環境を整えられたとのことでした。実際に触れることが、構成の判断と迅速な導入につながった事例です。 詳しくはご寄稿いただいた こちらの記事 もご参照ください。 Anthropic Japan 合同会社様登壇: 研究者自身が AI エージェントを使う意義 2 社の実践に続き、Anthropic Japan 合同会社の渡部様には「信頼できるフロンティア AI」と題してご登壇いただきました。Constitutional AI を含むモデル設計、能力の向上に応じて安全対策を強化する責任あるスケーリング、顧客データを学習に使用しない方針など、規制産業で活用するための信頼性への取り組みと、Anthropic が一般提供する中で最も高性能なモデルである Claude Fable 5 の最新動向が紹介されました。 Claude Code のハッカソン「Built with Opus」では、入賞した上位 5 組のうち 4 組が職業エンジニアではない非技術者だったといいます。実装の障壁が下がる現在、課題を深く理解している人の知見が成果を左右することを示す 1 つの事例と言えるでしょう。創薬研究でも、ドメインエキスパートである研究者自身がエージェントを使い、課題設定と評価を担うことが成果を生み出す鍵になります。 体験を組織の実践へ クロージングでは、このハンズオンの中で、何故短い指示からエージェントが一連の作業を進められたのか、その背景をご紹介しました。今回のハンズオンでは、対象とする業務の前提や判断基準をコンテキスト（ CLAUDE.md など）として与え、定型作業を Agent Skills として登録し、MCP で研究データベースや文献検索のツールにつなぎ、計画・実行・検証までのループを回す仕組みをあらかじめ設計し、参加者がハンズオンで利用する操作環境のなかに組み込んでいました。参加者には、その土台の上で Claude Code を使い一連の操作を進めていただきました。こうしたモデル周辺の仕組みは一般に「ハーネス」と呼ばれます。 同じモデルを利用できても、社内の知見、業務手順、システムとの接続は企業ごとに異なります。今回の環境のように、自社の知見や業務の型をハーネスに組み込み、実際に使いながら継続的に更新することで、モデルの進化を研究現場の成果へ素早く反映できます。その準備には、今から使い、学び、改善を重ねる時間が必要です。 エージェントが一連の作業を担うと、人はループの中ですべての工程を実行する立場から、ループの上で目的と進め方を設計し、結果を監督する立場へ移ります。任せる範囲を決め、結果に責任を持つのは引き続き人です。目指すのは、一工程ずつ数十 % の効率化を積み上げるだけでなく、仕事の形そのものを組み替えて数十倍の成果を生み出すことです。 では、こうした変化に向けて何から始めるべきでしょうか？ 今回の参加者には、体験を各社へ持ち帰り、参加できなかった方も含めて、自社の研究テーマで AI に何を任せ、人がどこで判断するかを話し合う機会を作っていただきたいとお願いしました。対象者・人数・題材などを要望に合わせて、AWS とともに個社向けワークショップを企画・実施することも、その議論を具体化する選択肢になります。 また、今の人間中心の業務のやり方を変えていくことも重要です。業務プロセスを AI エージェント前提に組み替える  AI-BPR (AI-driven Business Process Re-Engineering)  や、開発サイクル全体を AI 主導で進める  AI-DLC(AI-driven Development Life Cycle; AI 駆動開発ライフサイクル)  の実践が選択肢の一つです。さらに、今回利用した RADS などを活用して、 Claude Code on AWS を組織的に利用・展開できる環境を早期に整えることで、個人の体験を組織の変革へつなげられます。 AWS は、お客様とともに課題と目指す姿を整理し、進め方の検討から実践、展開まで支援していきます。 まとめ Claude Code のような AI コーディングエージェントが変革するのは、解析コードの書き方ではなく、創薬研究の進め方そのものです。AI が調査や実装を担い、研究者が問いと判断に集中する働き方は、すでに現実になりつつあります。 その変化を先取りするには、いち早く自らの研究テーマで触り、AI への任せ方と人の判断を組織で学ぶことが欠かせません。AI コーディングエージェントが自社の創薬研究をどう変え得るのか、まずは実際の題材で確かめてみてください。 AWS は、こうしたワークショップを起点に、AI エージェントへの理解と活用を組織に広げ、プロセスの変革と創薬加速につなげる取り組みを今後も支援していきます。ワークショップの実施やその先の組織展開などにご関心をお持ちの方は、担当の AWS アカウントチームまでご相談ください。 執筆者 森下 裕介 (Yusuke Morishita) ライフサイエンス領域や医療機器領域のお客様を担当するソリューションアーキテクトです。医用画像の機械学習研究を経て、現在は生成 AI や AI エージェント領域を得意分野として活動しています。趣味は旅行と映画鑑賞。 原田 裕平 (Yuhei Harada) 製薬・ライフサイエンス領域のお客様を担当し、AI エージェントを活用した研究開発の高度化や、近年は Physical AI 分野での活動も精力的に行っています。 石尾 千晶 (Chiaki Ishio) 製薬・医薬品卸領域のお客様を担当し、クラウドや生成 AI の活用の技術支援を行っています。 川合 広喜 (Hiroki Kawai) 主に製薬業界のお客様を中心に営業支援を行っております。クラウド移行から生成 AI の活用まで、お客様の課題に応じたご支援を心掛けています。 亀田 俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略 (DTx 含む) を得意としています。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

現在、 AWS Graviton5 プロセッサを搭載した  Amazon EC2 の R9g インスタンスと R9gd インスタンスが一般的に利用できるようになっています。R9g インスタンスはメモリ最適化されており、AWS がこれまでに構築した中で最もエネルギー効率の高いプロセッサを搭載した Graviton4 ベースの R8g インスタンスと比較して、コンピューティングパフォーマンスが最大 25% 向上します。 R9g インスタンスは、データベース、インメモリキャッシュ (Valkey、Redis、MemCached)、リアルタイムのビッグデータ分析、コンテナ化されたマイクロサービスベースのアプリケーション (Kubernetes、Docker、EKS、ECS など) を含む Linux ベースのワークロード、C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションなど、メモリを大量に消費するワークロードに最適です。 R9gd インスタンスには、ローカルの NVMe ベースの SSD ブロックレベルストレージが含まれており、オープンソースデータベース、分散型リアルタイムビッグデータ分析、大規模なインメモリデータベース、大規模なキャッシュワークロードなど、高速で低レイテンシーのローカルストレージを必要とするメモリ集約型のワークロードに最適です。 現在 R8g インスタンスでワークロードを実行している場合、R9g を使用すると、消費電力を抑えながら、より高速なメモリ、より高いネットワークと Amazon EBS の帯域幅、大きな L3 キャッシュにより、vCPU あたりのパフォーマンスが向上します。 R9g は何が違うのか Graviton5 プロセッサは、Graviton4 に比べていくつかのハードウェア改善をもたらしています。 vCPU あたりのコンピューティングパフォーマンスが最大 25% 向上 DDR5 8800 MT/s メモリ（Graviton4 の 5600 MT/s から増加）、クラウドで利用可能な最速のメモリ L3 キャッシュが 5 倍大きく、データの局所性が向上 最大のインスタンスサイズでは最大 2 倍のネットワークと EBS 帯域幅 (最大 100 Gbps のネットワーク、48 xlarge では最大 72 Gbps の EBS) 最大 3 倍のパケット処理パフォーマンス R9g インスタンスと R9gd インスタンスは、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを 25% 調整できるインスタンス帯域幅設定 (IBC) をサポートしています。これにより、データベースやキャッシュなど、特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 すべての R9g および R9gd インスタンスは AWS Nitro System 上で動作し、仮想化、ストレージ、ネットワーキングを専用ハードウェアにオフロードします。これにより、インスタンス間の強固なセキュリティ分離を維持しながら、アプリケーションはベアメタルに近いパフォーマンスを実現できます。 R9g インスタンスと R9gd インスタンスには、今年初めに C9g と M9g インスタンスで導入された Nitro System と同じ拡張機能である Nitro Isolation Engine (NIE) が搭載されています。Nitro Isolation Engine (NIE) は、インスタンスの分離を強制し、正式な検証を利用して数学的な精度で分離を保証します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。対象範囲や前提条件を含む形式検証の結果の詳細については、 テクニカルホワイトペーパー を参照してください。 EC2 R9g および R9gd インスタンスの仕様 R9gとR9gdのインスタンスはそれぞれ、ミディアムからメタル 48XL まで、11種類のサイズでご利用いただけます。次の表は、各サイズの完全な仕様を示しています。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9g.medium 1 8 EBS のみ 最大 15 最大 12 r9g.large 2 16 EBS のみ 最大 15 最大 12 r9g.xlarge 4 32 EBS のみ 最大 15 最大 12 r9g.2xlarge 8 64 EBS のみ 最大 17 最大 12 r9g.4xlarge 16 128 EBS のみ 最大 17 最大 12 r9g.8xlarge 32 256 EBS のみ 17 12 r9g.12xlarge 48 384 EBS のみ 25 18 r9g.16xlarge 64 512 EBS のみ 34 24 r9g.24xlarge 96 768 EBS のみ 50 36 r9g.48xlarge 192 1536 EBS のみ 100 72 r9g.metal‑48xl 192 1536 EBS のみ 100 72 R9gd インスタンスは、高速で低レイテンシーのスクラッチスペースまたは一時キャッシュを必要とするワークロード向けに、ローカル NVMe ベースの SSD ストレージを追加することで、R9g と同じコンピューティング性能とネットワークパフォーマンスを提供します。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ (NVMe SSD) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9gd.medium 1 8 1 x 59 GB 最大 15 最大 12 r9gd.large 2 16 1 x 118 GB 最大 15 最大 12 r9gd.xlarge 4 32 1 x 237 GB 最大 15 最大 12 r9gd.2xlarg 8 64 1 x 474 GB 最大 17 最大 12 r9gd.4xlarge 16 128 1 x 950 GB 最大 17 最大 12 r9gd.8xlarge 32 256 1 x 1900 GB 17 12 r9gd.12xlarge 48 384 3 x 950 GB 25 18 r9gd.16xlarge 64 512 1 x 3800 GB 34 24 r9gd.24xlarge 96 768 3 x 1900 GB 50 36 r9gd.48xlarge 192 1536 3 x 3800 GB 100 72 r9gd.metal‑48xl 192 1536 3 x 3800 GB 100 72 使用の開始 サポートされている任意の ARM ベースの AMI を使用して、 Amazon EC2 コンソールから R9g インスタンスと R9gd インスタンスを起動できます。R9g インスタンスは、Amazon Linux 2023、Amazon Linux 2、Ubuntu 22.04+、RHEL 8.4+、SUSE Linux エンタープライズサーバー 15 SP3+、Debian 12+、およびその他の主要な Linux ディストリビューションをサポートしています。 R8g から移行する場合、ほとんどのアプリケーションではコードを変更する必要はありません。同等の R9g インスタンスサイズを選択すると、アプリケーションのパフォーマンスが向上します。コンテナ化されたワークロードの場合、R9g は Amazon EKS、 Amazon   ECS 、および標準の Kubernetes デプロイメントと連携します。Arm64 用に構築されたマルチアーキテクチャコンテナイメージは変更なしで動作します。 始めるのに役立つリソースはいくつかあります。 AWS Graviton 入門ガイドでは 、Graviton ベースのインスタンスでワークロードを構築、実行、最適化する方法について説明しています。 Graviton節約ダッシュボードは 、コスト削減を追跡するのに役立ちます。 AWS Transform は Java アプリケーションを x86 から Graviton に移行するためのコード変換を自動化します。詳細については、 AWS Graviton プロセッサをご覧になるか、AWS Graviton でコンピューティングをレベルアップしてください 。 料金と利用可能なリージョン Amazon EC2 R9g および R9gd インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンで利用可能です。 R9g および R9gd インスタンスは、Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から R9g インスタンスを起動してください。詳細については、 Amazon EC2 R9g インスタンスページを参照してください 。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 Amazon EC2 用 AWS re:Post でフィードバックを共有するか、通常の AWS サポートの連絡先から連絡してください 。 – Daniel Abib 原文は こちら です。

2026 年 8 月 24 日週に私が最も興味を持ったニュースは、DuckLabs の買収でした。 AWS は、Parquet、CSV、JSON などのファイルに対してインプロセスで実行され、SQL を直接実行する人気のオープンソース分析データベースである DuckDB の背後にあるアムステルダムを拠点とする企業である DuckLabs を買収する最終契約を締結しました 。DuckDB は、独立した基盤と MIT ライセンスの下でオープンソースを維持しており、時間の経過とともに、AWS は日常のクエリの速度と、Amazon S3、Amazon Redshift、Amazon Athena などのエンタープライズ規模のサービスを組み合わせる予定です。 ハネス・ミューライゼンとマーク・ラースベルトが共同設立した DuckDB は、ローカルまたは Amazon S3 上で稼働しています。そのため、現実世界の分析の大部分を占める日常のクエリ (1 テラバイト以下) の処理速度が非常に速くなります。また、AI エージェントとの相性も抜群です。AI エージェントは、人間と同じようにデータを「調べて」実験します。AWS が DuckDB のスピードと Amazon EMR、AWS Glue、Amazon SageMaker などの分析サービスを組み合わせている間、共同創設者は引き続き技術的な方向性をリードしていきます。なぜこれが重要なのかをより大局的に説明するために、バイスプレジデント兼著名なエンジニアであるアンディ・ウォーフィールドが、 ポスト DuckDB と All Things Distributed で変化する分析 の物理現象についての考えを共有しました。 それでは、8 月 31 日週の AWS ニュースを見ていきましょう… 8 月 24 日週のローンチ 8 月 24 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon ECS は、エージェントとの接続を失ったコンテナインスタンスを自動的に検出して回復するようになりました。Amazon ECS は、エージェントのコントロールプレーンへの接続を継続的に監視し、新しい AGENT_CONNECTIVITY ヘルスイベントを AWS Fargate、Amazon ECS マネージドインスタンス、および EC2 上の Amazon ECS 全体にわたって検出するようになりました。Fargate とマネージドインスタンスでは、ECS が自動的にリカバリ、タスクの排出、代替インスタンスの起動、障害のあるインスタンスの登録解除を行います。EC2 では、イベントを独自のワークフローに接続できます。すべての AWS コマーシャルおよび AWS GovCloud (米国) リージョンで追加料金なしで利用できます。 AWS Lambda では、Node.js 26 と Python 3.15 からパブリックプレビューランタイムが導入されました。今後の Lambda ランタイムが一般公開される前にテストできるようになりました。プレビューランタイムは最終的な GA バージョンと同じ識別子を使用するため、関数はアクションなしで自動的に段階的に終了します。サードパーティのツールやデプロイメントフレームワークでも、GA に先立って互換性を検証できます。まだ本番環境向けではありませんが（重大な変更が可能です）、次のアップグレードに先んじるには最適な方法です。すべての AWS コマーシャル、AWS GovCloud (米国)、および中国リージョンでご利用いただけます。 AWS IoT Core にネイティブ InfluxDB ルールアクションが追加されました — カスタムコードを記述したり、中間サービスをセットアップしたりしなくても、IoT デバイスから InfluxDB (Amazon TimeStream マネージドまたはセルフホスト) に時系列データを直接ルーティングできるようになりました。IoT Core はデータを InfluxDB のラインプロトコルにフォーマットし、デバイス側とサーバー側のバッチ処理をサポートします。Amazon Timestream for InfluxDB が提供されているすべての AWS リージョンで利用できます。 Amazon GameLift Servers に DDoS 保護機能が強化されました — ゲームサーバーは、ネットワークとトランスポートレイヤー (レイヤー 3 と 4) の DDoS 攻撃 (UDP リフレクション、SYN フラッド、および同様のベクトル) から自動的に保護されるようになりました。有効にしたりオプトインしたりする必要はありません。ゲーム用に最適化されたトラフィックシェーピング機能を備えた AWS Shield Standard 上に構築されているため、追加費用なしでサーバーの稼働を開始した瞬間 (Server SDK 5) に起動します。中国 (北京) と中国 (寧夏) を除き、サポートされているすべてのGameLift Serversリージョンで利用できます。 Amazon SageMaker HyperPod が Ray のサポートを拡大する — 組み込みのオブザーバビリティ、レジリエントなトレーニング、高速推論により、SageMaker HyperPod で Ray ワークロードを実行できるようになりました。Amazon SageMaker Studio から Ray クラスターを作成および管理し、JupyterLab またはローカル IDE をアタッチしてマルチノードクラスターがローカル開発環境のように動作するようにし、Grafana ダッシュボードを自動プロビジョニングします。ノードの自動リカバリ、ハングジョブの検出、階層化されたチェックポイントにより、大規模なトレーニングを正常に実行できる一方、Ray Serve は推論用に階層化された KV キャッシュを追加します。既存のオープンソース Ray コードは変更されずに動作します。Amazon EKS によってオーケストレーションされたハイパーポッドクラスターで使用できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 20 歳の誕生日おめでとう、Amazon EC2! — アマゾン EC2 が 20 周年を迎えます。Channy Yun は、EC2 が 1 つのリージョンの単一の m1.small インスタンスタイプから 39 のリージョンにわたって 1,200 を超えるインスタンスタイプに成長した経緯と、最初の Graviton から Graviton5 と Trainium3 へのカスタムシリコンの移行について振り返ります。Amazon ECS、Amazon EKS、AWS Lambda、Amazon SageMaker、Amazon Bedrockなど、今でも AWS の多くを支えているこのサービスについて、楽しくて読む価値があります。 エージェントリソースディスカバリー (ARD): エージェントディスカバリーのオープン仕様 — 組織がエージェント 、ツール、MCP サーバーをスケールアップするにつれて、これらのリソースはクラウド、オンプレミスインフラストラクチャ、SaaS プラットフォームに分散し、それぞれが独自のレジストリとメタデータを持つことになります。ARD は新しいオープン仕様（Apache 2.0）で、エージェントのリソースを記述して発見する一般的な方法を定義しています。そのため、パブリッシャーは「一度説明すると」、コンシューマーは「あらゆる場所で発見する」ことができます。DNS はエージェント向けです。AWS はフィードバックを提供しましたが、この仕様は独自のものではありません。また、移行せずに複数のカタログを統合できるため、AWS Agent Registry が補完されます。 AWS CLI で Agent Toolkit for AWS を使い始めましょう – 単一の AWS CLI コマンド ( aws configure agent-toolkit ) で、Kiro、Claude Code、Codex、Cursor などの AI コーディングエージェントに、厳選された最新の AWS 知識と AWS MCP サーバーを介した何千もの AWS API への安全な接続が可能になりました。AI コーディングアシスタントを使用してビルドすると、適切なサービスを選択し、最新の API を使用し、セキュリティのベストプラクティスに従うのに役立ちます。そのため、初めてでも AWS コードを正しく理解できることが多くなります。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 開発者が集まってクラウドと AI の最新情報を学び、交流し、探求する無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。直接参加できない場合 セッションは、 グローバルライブストリームとオンデマンドハブ からストリーミングできます。サンパウロサミットでは、生成 AI と Amazon Bedrock に関する2つのセッションを発表します。参加されたら、ぜひご挨拶ください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントとして、 東京（9月5日）および ポーランドのワルシャワ （9月8日）での「JAWS SONIC 2026」が予定されています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 8 月 31 日週のニュースは以上です。9 月 7 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

イベント概要 Amazon Aurora DSQL に関心をお持ちのお客様に向けて、「Aurora DSQL Day Tokyo」を開催します。本イベントでは、Aurora DSQL の開発を率いる Eric Kraemer のキーノートと AWS のスペシャリストによる Deep Dive セッション、そして日本のお客様 4 社から DSQL の採用事例についてお話いただきます。Aurora DSQL がどう動いているのか、実際の現場でどのように使われているか――ぜひこの機会に体感してください。 皆さまのご参加を心よりお待ちしております。 開催情報 開催日時 2026年9月14日（月）14:00 – 18:00 （13:30 受付開始） 開催場所 AWS 麻布台オフィス（麻布台ヒルズ 35F） 〒106-0041 東京都港区麻布台1丁目3-1 麻布台ヒルズ 森JPタワー 東京メトロ日比谷線 神谷町駅 直結・東京メトロ南北線 六本木一丁目駅より徒歩約4分 ※入退館等詳細は別途ご連絡いたします 参加対象者 分散データベースやマルチリージョン構成に関心のあるエンジニア、アーキテクト、技術リーダーの方々 言語 Keynote: 英語（逐次通訳）、他セッション: 日本語 参加申し込みについて 以下のページよりお申し込みください。 お申し込みはこちら 特にこのような方々に最適なイベントです マルチリージョンでの高可用性データベース構成を検討されている方 分散 SQL データベースのアーキテクチャや設計パターンに興味のある方 Aurora DSQL の具体的な実装方法やベストプラクティスを知りたい方 既存のリレーショナルデータベースからの移行を検討されている方 他社の Aurora DSQL 導入事例を参考にしたい方 プログラム内容 時間 内容 13:30-14:00 受付 14:00-14:05 オープニング 14:05-14:50 What’s Next for Aurora DSQL ― Aurora DSQL が目指す世界 Aurora DSQL サービスチームのプロダクトマネージャーから、プロダクトビジョンや設計思想、今後の方向性、海外のお客様による採用事例などをご紹介します。※逐次通訳付き AWS, Senior Manager PMT – Aurora Distributed SQL Eric Kraemer 14:50-15:40 将来不要になるデータベースタスクから考える Aurora DSQL ― アーキテクチャ・制約・適用判断 ― DB を選定するアーキテクトやエンジニア向けに、Aurora DSQL を「選定後に不要になるタスク」という観点から解説。キャパシティプランニング、シャーディング設計、スキーマ変更に伴う停止時間の調整、フェイルオーバー設計がなぜ不要になるのか、分散アーキテクチャから説明します。同時に、トランザクション競合時のリトライ設計や処理サイズの制限など、アプリケーション設計上の考慮点と適用判断のチェックリストもお持ち帰りいただきます。 アマゾンウェブサービスジャパン合同会社, データベース スペシャリスト ソリューション アーキテクト 永末 健太 15:40-15:50 休憩 15:50-16:15 実践 Rails + Aurora DSQL Ruby on Rails で実際に Aurora DSQL を利用して customer facing なシステムを新規開発・運用する中でのハマり所や工夫、また既存データの AWS Database Migration Service を利用した移行といった様々なエピソードを紹介します。 株式会社 IVRy, Platform & Systems Principal Software Engineer Sorah Fukumori 氏 16:15-16:40 ネットスーパーサービスにおいて AWS DSQL を選定した理由とその後の運用についてのリアル retail HUB ネットスーパーサービスにおいて商品のピッキングシステムを新規に開発する際、ストレージサービスとして DSQL を選定。選定時の検討内容や、開発で遭遇した課題、その後の運用の状況について小売業界の実態も含めつつ実際のところをお話しします。 株式会社エブリー, 開発本部 開発2部 部長 内原 章 氏 16:40-17:05 サッカークラブの広報写真選定システムと Aurora DSQL FC 東京では試合のたびに大量の写真が発生し、記事や SNS に適した写真を探す作業に多くの労力がかかっていました。Amazon Rekognition による人物特定と Amazon Bedrock のマルチモーダル LLM によるシーン・表情・パートナー企業露出の分類を組み合わせた写真選定システムを開発。分類結果を保存する DB として採用した Aurora DSQL について、運用のしやすさや負荷変動が大きい場合のコスト面でのメリットなど、実際に利用して得られた知見をご紹介します。 株式会社 MIXI, ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ マネージャー 數藤 智幸 氏 17:05-17:30 有事の”切り替え判断”を、なくす。 ― Aurora DSQL で実現する Active-Active DR 戦略 2026年4月の AWS Data & AI イノベーションフォーラムで「DR 戦略の進化」として DSQL 採用の第一歩をお話しいただきました。あれから数ヶ月、検証は着実に進んでいます。マルチリージョン稼働のシステムを構築する中で直面した、ロングトランザクション制限やマルチリージョン設計での整合といった技術課題を、AWS と共に乗り越えている現在地をアップデートしてご紹介いただきます。 東京海上日動システムズ株式会社, IT インフラサービス本部 スペシャリスト 松本 幸大 氏 17:30-17:35 クロージング 17:35-18:00 個別アーキテクチャ相談会 AWS スペシャリストに直接ご相談いただけます。Aurora DSQL に関する具体的な設計・導入のご質問にお答えします。 Amazon Aurora DSQL とは Amazon Aurora DSQL は、事実上無制限のスケーラビリティ、最高の可用性、ゼロインフラ管理を備えた、PostgreSQL 互換のサーバーレス分散 SQL データベースです。Active-Active のマルチリージョン構成で 99.999% の可用性を提供し、従来のデータベースに必要だったインフラストラクチャの管理、キャパシティプランニング、パッチ適用、レプリカ管理などのタスクが不要になります。 強力な一貫性を持つ分散トランザクションを、リージョン内では低レイテンシー（数ミリ秒）で、マルチリージョンでもインタラクティブなレイテンシーで処理できます。PostgreSQL のワイヤプロトコルに対応しているため、既存の PostgreSQL 互換ドライバーやツールをそのまま利用可能です。 お申し込みはこちら

こんにちは、AWSの嶺、篠原、鈴木です。2026年5月、DeNAのヘルスケア事業部門のDeSCヘルスケア株式会社（以下、DeSC）の皆さまと、AI-DLC（AI-Driven Development Life Cycle）の3日間プログラム「Unicorn Gym」に取り組みました。AI-DLC は、AWS が提唱する「ソフトウェア開発に対する AI 中心の革新的なアプローチ」であり、AI の能力を開発プロセスの構造そのものに組み込む新しい方法論ですが、その方法論をソフトウェア開発ではなく「データ分析業務」へ適用しました。 AI-DLC では、要件定義や実装の主役を AI が担い、人間は「何を作るか」という意図のすり合わせと重要な判断に集中します。詳しくは  AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築  をご覧ください。また、この AI-DLC を座学ではなく自社の実テーマで3日間走り切る形で体験するプログラムが Unicorn Gym です。 3日間を終えて印象に残ったのは、AI の性能そのものよりも、部署をまたいでメンバーの認識をそろえていく営みに対してAIを用いるポテンシャルの大きさです。 インタビューさせていただいた DeSC ヘルスケア株式会社の皆様。 左より、嶺（AWS） 山田真里香（インダストリー統括部分析企画部）、伊藤 康太郎（製品開発統括部 統括部長） 、香村 和宏（インダストリー統括部分析企画部 部長） 、河野 愛樹（製品開発統括部プロダクトマネジメント室） 、鈴木（AWS） 1. なぜ「データ分析業務」を選んだのか 嶺: まず、AI-DLC に取り組むことになった経緯を教えてください。 河野 氏: AWS さんから「AI-DLC というものがある」とご提案いただいたのが最初です。実は、最初に話を聞いた伊藤は「これがどこにはまるのか、他の研修と何が違うのか」とピンときていない様子でした。一方で私は、これまで組織を俯瞰して見る中で感じていた大きな「壁」を乗り越えるきっかけになるのでは、という期待を感じていました。 部門間、特にビジネス側とシステム側のように大きくロールが異なる組織の間でコミュニケーションギャップが昔から各所で存在しており、認識合わせに時間がかかったり、同じ言葉を使っていても「これって実はこんな認識だった」というズレが起きている。同じベクトルを向ききれていない、一体感を作りたいのに作り切れていない、といったモヤモヤを感じていました。そこに拍車をかけたのがAIです。DeNA社長の南場が「AIオールイン」と発したのを皮切りに、ヘルスケア事業部門でも「AI活用をやっていくぞ」と掲げたものの、前のめりで使う人と、様子を見ながらゆっくり始める人とで差がある。その差がどんどん開いていっていることに危機感を感じていました。 「同じ体験を共にすることで、共通言語を持てるようになるのではないか」、「できる人がどう使っているのか、どう指示や操作をしているのかを、ちょっと隣で見せてもらうだけでも変わるんじゃないか」と思っていたところに、AI-DLC と Unicorn Gym を耳にして、「これははまるんじゃないか」と伊藤に持ちかけたんです。 嶺: 最初に検討されたテーマは、実はシステム開発だったと伺いました。 河野 氏: そうなんです。ちょうどその頃、新しい分析環境を作るプロジェクトが走っていました。分析環境そのものや運用ツールセットを作る必要があったので、そこに適用するのがテーマ的にも丁度良いのではないか、というところから始まりました。でも伊藤から「システム開発でやるなら別にUnicorn Gymじゃなくてもいい。どうせやるなら、その新しいシステム上で行う予定の分析業務にフォーカスを当てるのはどうか」とカウンターが来たんです。 伊藤 氏: できるかできないかよりも「どうせやるならペインが強いところをやった方がいい」と。参加者全員が自分事にできるテーマならば、面白い取り組みになるだろうという直感がありました。そしてもう一つ。AI活用のボトルネックは組織・部門の繋ぎ目で発生することは分かっていました。当時はデータサイエンス部とビジネス部門である分析企画部間の連携の難しさが表面化していた時期でした。私たちはハイブリッドワークで、顔を突き合わせて作業する機会が普段は多くありません。部門を跨いだ共同作業の機会や経験は特に少ない。お互いのバックグラウンドも実はよく分かっていない。一方で、新しい業務・新しいプロジェクトだからこそ「最悪、失うとしてもこの3日間だ。だったらやってみよう」と、リスクをとって動くことにしました。 嶺: まさにそこなんです。AI-DLC はソフトウェア開発の文脈で語られがちですが、本当に言いたいのは、実装を AI が担うようになると、ボトルネックが実装から「人と人の合意形成」に移る、ということなんです。別々に動いていると意思疎通がうまくいかず、手戻りが起きる。これはソフトウェアに限らず、どの業界でも起きています。だから、データ分析でも同じことが起きているはずで、そこで成立すれば AI-DLC の使いどころは大きく広がる、と考えていました。 AI-DLC に取り組んだ経緯を語る河野氏（右） 2. 3日間で、何をしたのか 嶺: どのようなメンバーで、どんな3日間だったのか教えてください。 河野 氏: Unicorn Gymには、分析企画部と、データサイエンス部を中心に、合わせて24名で参加し、部門混成・AI活用の度合い混成で4チームを編成しました。 香村 氏: 分析企画部は、ヘルスビッグデータを用いた分析の企画を行っている部署です。私たちが製薬企業様などのニーズ（ある疾患の治療実態把握など）をヒアリングし、そこで定義したお客様の問いから、どのデータをどう集計・加工すれば答えになるのかに翻訳した「要件定義書」を作成します。この要件定義書を元に、データサイエンス部が実際の集計を行います。 河野 氏: 今回のUnicorn Gymは、AIを活用した要件定義書作成をメインコンテンツにしました。初日の午前は座学の時間。AWSさんからAI-DLCの考え方を教わりながら、簡単なハンズオンを行いました。以降はチームごとに分かれ、モブワーク（1つの画面を全員で見ながら、同じ作業を一緒に進める進め方）の時間。AIをフル活用して、質の高い要件定義書をどれだけ無駄なく苦労なく作れるかを試行錯誤しました。 山田 氏: モブワークを通して、「AI にどこまで任せるか」が具体的になりました。最初は自分たちで考えた結果を AI に渡していたのですが、AWS さんから「それだと AI が待っている時間が多い。もっと AI に考えさせて」とアドバイスを貰って。全部いったん AI に投げて、その間に自分たちで議論する形に変えたら、スピードが一気に上がった。これを初日に教われたのは大きかったです。 3. ビジネス部門へ波及した影響 嶺: 実際にやってみて、いかがでしたか。ビジネス部門からの視点でお伺いさせてください。 香村 氏: 私は正直なところ、Unicorn Gymに参加して起きることの解像度が、河野や伊藤よりも更に低かったです。「参加した結果、具体的にどんな変化が起きますか」と伊藤に確認したら、「やってみないと分からない部分もあるけど、信じて飛び乗ってくれ」と。弊社メンバーとAWS さんへの信頼だけで飛び乗った、というのが正直なところです。 ですが、やってよかったと自信を持って言えます。私たち分析企画部は、データサイエンス部やエンジニアと比べるとAI 活用では一歩後ろにいました。それが、一緒に作業することで、ミーティングで話すだけでは分からない「こういうときに使えば良いんだ、という具体的な使い所」、「こういう時は、こう AI に聞けばいいのか」という手触り感まで得られました。 嶺: 分析企画とデータサイエンス、普段は分業されている両者が同じチームで動いた意味は大きかったのでしょうか。 山田 氏: 大きかったです。これまでは分業制で、私たち分析企画部が定義を決めてからデータサイエンス部にパスしていました。私たちが書く定義書は、お客様との対話に必要な情報としては十分に書けているつもりなんです。ただ、SQL の設計という目線で見ているデータサイエンス部からすると「ここはもっと細かく決めておかないと書けない」と映ることがある。 一緒に動いてみて改めて感じたのは、必要な詳細さの基準が立場によって違うということでした。私たちはお客様と向き合う立場から、データサイエンス部はデータを集計する立場から、同じテーマを見ている。その上で、お互いがどう情報を組み立てているのかを理解できたので、どこをどう補い合えばいいのかが見えてきました。「その組み立て方なら、業務フローをこう変えた方がいいよね」という気づきも生まれましたし、私たちがお客様とどう情報を組み立てているかを共有できたことで、要件定義書を作る AI をどう組み立てればいいかのヒントも見えました。データサイエンス部が普段どう AI を使っているかも学べて、お互いにいい影響がありました。 嶺: Unicorn Gymの3日間で、特に印象に残っている場面はありますか。 香村 氏: コンペ形式となった最終成果発表です。各チームがそれぞれの工夫を施したAIエージェントに要件定義書を作らせ、できあがった要件定義書を元に別のAIエージェントに集計作業を行わせました。ここでは、AIエージェントの実力を測る目的で、実業務では必ず入れる「人の目による要件定義書のレビュー」を外すルールで実施しました。 4チームそれぞれの画面を大きなスクリーンに並べ、4つのAIエージェントが動いている様子をみんなで眺めていた時が特に印象的でした。正直、最初は「AI が質の高い要件定義書を作るのは難しいのではないか」と思っていたんです。それが次々と要件定義・集計を進めていき、その光景は圧巻で素直に驚きつつ、データ分析業務の品質やスピード感を高める具体的なイメージを持つことができました。この会社に入ってから、一番ワクワクした時間だったと思います。 最終成果発表。4チームのAIエージェントが動く様子 4. DeNAの事業への向き合い方 嶺: 今回、印象的だったのは、皆さんが「何をやるか」から自分たちで考え、全体を引っ張っていかれたことです。他のお客様ではなかなか見られません。このオーナーシップはどこから来ているのでしょうか。 伊藤 氏: 大前提として、ノープランで挑むと期待した成果は出ないと思ったので、拠り所になるベースラインは用意しました。ただ「作るけれど、出たとこ勝負になる」というのは織り込み済みでした。私たちは普段から、仮説を立てて、観察した事実から軌道修正していく進め方が体に染みついているんです。だから、計画どおりに進まないこと自体には抵抗がなかった。 嶺: 通常の Unicorn Gym では、チームごとの進行はお客様が、全体を束ねる役割は AWS が担うことがほとんどです。その全体を束ねる役割まで、お客様側が担われたのは珍しいことでした。 伊藤 氏: AI 活用や開発生産性の話は、トップマネジメントのコミットメントが決定的に重要だと考えています。組織にとっての未知の経験はリーダーが前に立ってリスクを取らないと物事は進まない。「よく分からないだろうけど、まず信じて3日間を賭けてくれ」と言えるかどうかです。失敗を許容できない組織だと、このやり方は取りづらいと思います。 AI-DLC への向き合い方を語る伊藤氏 5. AI-DLC Unicorn Gymを経た変化 嶺: 3日間を経て、業務にはどんな変化が出ていますか。 香村 氏: Unicorn Gymで各チームが作成したClaude CodeのSkills（業務の手順やノウハウをまとめてAIに読み込ませる仕組み）から厳選したものを、実業務にも取り入れて活用しています。また、分析企画部内でもSkillsを新たに作成・部内で共有される光景が日常的なものとなりました。今年に入ってUnicorn Gymの前までの5か月間では1件だったのが、その後2か月で6件が共有され、今後もこの流れは加速する見込みです。Skillsの共有を通して、属人化していた勘所や専門性が組織の資産となり、我々が提供するサービス品質の安定・向上に寄与し始めています。 山田 氏: ビジネス側は GitHub に馴染みがないところからのスタートでしたが、Skills を GitHub で共有して使う、という動きが浸透しました。「これは自分でやるしかないか」と思っていた課題を「AI で解けるかも」とスキル化する発想も増えました。そして何より、データサイエンス部とのやり取りが円滑になりました。以前はお客様と合意した要件定義書を渡すだけだったのですが、「顧客面談に同席しませんか」と声を掛けることが増えました。要件定義書が決まり切る前段階でのコミュニケーションが増えたことで、よりスピード感を持った対応ができるケースも実際にありました。 伊藤 氏: この流れは社内で連鎖しています。AI-DLC で手応えがあったので、続けて業務プロセスをAIで革新する「AI-BPR」も進めていて、次回は参加人数が40名規模になりそうなほど期待が高まっています。参加した人が手応えを持ち帰り、役職関係なく周囲を巻き込んで、あちこちで動きが広がっています。 3日間を経た変化について語る香村氏（右） 6. 製薬・ヘルスケア業界へのメッセージ 嶺: 最後に、AI 活用を検討されている製薬・ヘルスケア業界の方々へメッセージをお願いします。 香村 氏: 私たちはサービスを通じた生活者の健康増進を目指していますが、データを分析するだけでは、その実現にはつながりません。製薬・ヘルスケア業界の皆さまとヘルスビッグデータを活用し、生活者の健康増進に繋がるエビデンスを創出し、社会に還元していきたい。AIについても、それを加速させるために、皆さまと活用方法を学び合っていけたらと思います。 伊藤 氏: 近年は、1社だけでは解けない課題が増えています。医療機関、自治体、健康保険組合、そして私たちのようにデータソリューションを提供する立場と、それぞれに得意・不得意がある。健康寿命の延伸も医療費の適正化も、各社の強みを持ち寄らないと解けません。AI はあくまで手段です。どの会社にもある組織の壁を、モブワークで取り払って初めて課題解決が進む。それを社内だけでなく、業界全体に広げていきたいと考えています。 まとめ AI-DLC の中心にあるのは、人と人が認識をそろえていく営みです。「何を作るか」、「どのように人と人の合意形成をするのか」という命題に対して、AIを介在者として活用する威力を大いに実感した3日間でした。今回はデータ分析ドメインでのAI-DLCの活用でしたが、ソフトウェア開発におけるAI-DLCについての記事もぜひご覧ください。現在DeNA様はAI-BPRも推進されておりますので、そちらについての記事もお待ちください。 Unicorn Gym には DeSC から24名が参加した 著者自己紹介 伊藤 康太郎 DeNA の主要子会社であるDeSCヘルスケアの最高技術責任者兼製品開発統括部長。彼はDeSCヘルスケアが提供するデータヘルス関連サービス及びデータ利活用サービスの製品・技術・データサイエンスを統括しています。     香村 和宏 DeSCヘルスケア株式会社インダストリー統括部分析企画部部長。健康・医療データの利活用を推進する事業において、製薬企業、アカデミア、生命保険会社のお客様を中心に、DeSCデータベース等のリアルワールドデータを用いた分析のニーズヒアリングから要件定義、結果のご報告までを担当しています。     嶺 行伸 Developer TransformationチームのスペシャリストSAとして、主にAI-DLCを中心に、お客様の開発チームを支援しています。       鈴木 賢人 デジタル・エンターテインメント領域のお客様を担当するAccount Managerです。趣味は旅行と身体作りです。       篠原 聡志 ゲーム企業を経て AWS に入社。ソリューションアーキテクトとしてゲーム業界のお客様を担当し、ゲームバックエンドの設計や生成 AI の活用をご支援しています。好きな AWS サービスは Amazon Bedrock、Amazon S3 です。趣味はリズムゲームと VR ゲームです。

本ブログは、株式会社アドバンスト・メディア様と Amazon Web Services Japan が共同で執筆いたしました。 1. はじめに みなさま、こんにちは。AWS ソリューションアーキテクトの本田・戸塚と、アカウントマネージャーの兼子です。 本ブログでは、 AWS Summit Japan 2026  で展示した、食品調理現場における業務課題を、音声 AI とマネージドエージェント基盤で解決するアーキテクチャをご紹介します。 Amazon Bedrock AgentCore Runtime と Strands Agents SDK による AI エージェント、 AmiVoice による高精度な日本語音声認識、 Amazon DynamoDB や AWS Lambda によるサーバーレスバックエンドを組み合わせ、「手を使わずにレシピを操作できる」ハンズフリーオペレーションを実現しています。 AWS 側ではエージェント設計・クラウドアーキテクチャ・リアルタイム通信の観点から、アドバンスト・メディア社側では音声認識エンジン AmiVoice の技術特性・業界特化チューニング・認識精度向上の観点から、それぞれ解説します。 2. 飲食業界における現場オペレーションの課題 食品調理の現場、特にセントラルキッチン（複数店舗向けの集中調理施設）では、以下の構造的な課題が存在します。 2.1 手が塞がる環境でのデータ入力障壁 調理作業上、両手は鍋・包丁・計量器などで塞がっています。加えて、衛生管理の厳しい調理現場では衛生手袋を着用しながら調理するため、レシピ確認や在庫記録のたびに手袋を外してタブレットを操作する必要があります。セントラルキッチンでは複数ホテル・複数レシピ向けに大量の食材を一括管理する必要があり、在庫記録の重要性がより高い一方で、以下の問題が連鎖的に発生します: 手袋着脱による作業中断と衛生リスクの増大。また、食品安全のために中心温度の測定・記録が義務付けられているが、手作業での記録は漏れやすく、コンプライアンス違反のリスクがある 紙・Excel 依存によりデータがデジタル化されず、経営判断に活用できない 配布されたレシピを調理現場で調整しているが、現場でカスタマイズされ、記録されずに属人化している レシピは調理現場に持ち込まず、バックヤードに置いているため、新人や不慣れなメニューの場合は頻繁にバックヤードと調理場を往復することになり、作業効率の低下を招く 調理工程の進行状況が在庫管理システムと連動しておらず、食材の消費を都度手入力で記録する必要がある。入力が漏れると在庫の把握精度が下がり、食材切れへの対応が遅れる 2.2 音声認識活用のハードル 音声入力は「手が塞がる環境」の自然な解決策ですが、キッチン特有の課題があります。換気扇・鍋の音などの騒音環境、食材名の専門用語（食品業界固有の表現や略称）、そして方言やイントネーションの多様性です。汎用の音声認識エンジンでは認識精度が業務品質に達しないことが多く、業界特化の音声認識技術が求められます。また、騒音やノイズのある環境下で、正確に発話の意図を把握して操作する精度も求められます。 2.3 レシピ一括管理の困難さ これらの課題は、「現場で変更された変更がレシピ側に伝達されないこと」につながります。調理器具の違いや材料不足、その日の気温といった外的要因からしばしばレシピの変更が発生しますが、手袋着脱や両手作業による入力障壁がデータ不在を生み、それが管理者の可視性欠如、ひいては経営判断の根拠不足へと連鎖していきます。本ソリューションは、高精度な音声認識とAI エージェントによる入力障壁の解消とオペレーションの容易さを起点に、アプリの利用を通じてデータを構造化して蓄積することでこの課題を解決します。 2.4 調理工程の分担・シフト管理の非効率 セントラルキッチンでは、複数の調理スタッフが並行して異なる工程を担当します。しかし担当者の割り当てやシフトの組み合わせは現状では管理者が手動で判断・調整しており、以下の問題が生じやすい状況です: 各スタッフの習熟レベルや当日の人員状況を考慮した工程分担の最適化が属人化しており、担当管理者の経験と勘に依存している 突発的な欠員や工程の遅れが発生した場合の再割り当て判断に時間がかかり、他工程への連鎖遅延が発生する 調理実績データ（誰がどの工程に何分かけたか）が記録されないため、シフト最適化のための根拠データが蓄積されない 3. ソリューション概要 本ソリューションは、ハンズフリーで操作できるレシピ管理ソリューションです。調理者が音声だけで指示した内容を汲み取り、レシピ工程を進め、AIエージェントが次の工程へのナビゲーションや原材料チェック、工程メモといった操作を判断します。 AmiVoice が調理スタッフの発話を高精度にテキスト化し、AI エージェント（Amazon Bedrock AgentCore + Strands Agents）が意図を解釈して、レシピナビゲーション・在庫減算・履歴記録を自律的に実行します。調理スタッフは「ちょっと楽になった」と感じるだけですが、裏側では構造化データが自動的に蓄積され、管理者のリアルタイム可視化と意思決定を支援します。 3.1 主要機能 レシピ操作機能 音声レシピナビゲーション — 「次へ」「戻る」で工程を進め、工程完了時に使用食材の在庫を自動減算 AI 代替食材提案 — 「玉ねぎがない」と伝えると、レシピ文脈と在庫を踏まえた代替案を提示 原材料チェック — 「原材料チェック、玉ねぎ300グラム」で食材を照合。玉ねぎ/タマネギ/オニオンといった発話の表記ゆれも吸収 調理タイマー — 音声で開始・停止・リセット 工程メモ — 音声でレシピ工程にメモを追加し、ナレッジの蓄積に繋げる 図1 : 個別レシピ画面 レシピの変換機能 現状、Excelで管理しているレシピから、システム管理できる形式への変換 紙管理しているレシピを読み取り、システムで管理できる形に変換 図2 : レシピ取り込み画面 ダッシュボード機能 調理工程ごとの時間をアプリ側で測っておき、ダッシュボード上で可視化 図3 : ダッシュボード画面 アプリケーションは以下のように動作します。 4. システムアーキテクチャ 4.1 全体構成 図4 : システムアーキテクチャ システムは以下の 3 層で構成されています。 層 担当 主要技術 通信プロトコル プレゼンテーション層 ブラウザ画面・音声UI・BLE連携 Amazon S3 + Amazon CloudFront + AmiVoice API HTTPS / WebSocket / Web Bluetooth AI 判断層 音声コマンド解釈・ツール選択・応答生成 Bedrock AgentCore Runtime + Claude Sonnet 4 WebSocket (双方向ストリーミング) データ層 レシピ・在庫・履歴・チェック記録 Amazon DynamoDB + AWS Lambda + API Gateway HTTPS REST アーキテクチャはAI Agent基盤をはじめ、フルサーバレス構成を採用しています。そのため、インフラストラクチャの管理をAWSにオフロードすることができ、運用負荷を抑えつつ、使われていない時間帯のコストも低く抑えながら利用できます。 AI エージェントを通さない単純な読み取り操作は Amazon API Gateway から AWS Lambda を介して処理し、レイテンシを数百ミリ秒に抑えています。一方、音声を通じた操作は、 AmiVoice API を介して発話内容をテキストに起こしたのち、Amazon Bedrock AgentCore で処理しています。なお、ビジネスロジックは同等の Lambda 関数を呼ぶことで、同じロジックを複数の入口から再利用しています。 4.2 AWS リソース構成 全リソースは AWS CDK で定義しています。 カテゴリ リソース 用途 AI エージェント Bedrock AgentCore Runtime (Docker/Python) Strands Agent + Bedrock Claude Sonnet 4 コンピュート AWS Lambda (Python 3.12, ARM64) ビジネスロジックを実行 データベース Amazon DynamoDB Recipes / Inventory / History / IngredientChecks といったデータを保存 API Amazon API Gateway REST API Cognito Authorizer 付きデータ読み取りエンドポイント 認証 Amazon Cognito User Pool + Managed Login OAuth2 PKCE フロー、JWT 発行 CDN Amazon CloudFront, Amazon S3 SPA配信 + AgentCore リバースプロキシ + 画像CDN シークレット AWS Secrets Manager AmiVoice 認証情報を格納 IaC 補助 CloudFront Function SPA フォールバック + AgentCore パス書き換え 音声合成 Amazon Polly レシピ工程の読み上げ音声生成 4.3 AI エージェント設計 本システムの核となる AI エージェントは、Amazon Bedrock AgentCore Runtime 上で動作する Strands Agentsで実装しています。 エージェントは、中央のオーケストレーターがいて、ツールを @tool デコレータ でラップし、必要に応じて呼ぶ構造です。プログラマが分岐を記載するのではなく、判断そのものを LLM に任せるのが従来との大きな違いです。@tool は Strands SDK のデコレータで、関数の引数名・型とdocstringが自動的に LLM 向けの「ツール仕様」に変換されます。したがって、docstring は人間が読む際のコメントであると同時に、LLM が呼び方を理解するための仕様書にもなります。 ■ ツール定義 ツール名 役割 get_recipes レシピ一覧取得 get_recipe レシピ詳細取得 update_step_memo 工程メモ更新 get_inventory 在庫一覧取得 get_inventory_item 食材単品在庫取得 deduct_inventory 在庫減算（工程完了時） rollback_inventory 在庫ロールバック（戻る時） record_history 調理履歴記録 get_history 調理履歴取得 check_ingredient 原材料チェック照合 record_step_time 工程実績時間の記録 clear_ingredient_checks セッション配下の原材料チェックを全削除 invalidate_step_time 「戻る」時に工程の実時間記録を無効化 answer_recipe_question 調理に関する質問をナレッジベースから検索して返答 ■ プロンプト設計 システムプロンプトはハイブリッド方式を採用しています: 指示文（条件分岐、制約、スキーマ定義）: 英語で記載。トークン効率が高い コマンド例、出力メッセージ、食材名 : 日本語。ユーザー体験を優先 message フィールドは必ず日本語で出力するよう明示的に制約 この設計により、日本語のみのプロンプトと比較して入力トークン削減を実現しつつ、日本語での自然な応答品質を維持しています。 ■ 音声認識から画面操作までのフロー 図5:音声の発話からAI Agentが動作するイメージ 発話した内容をもとにページ操作を行うまでのフローは、下記の通りです。 音声入力 マイクまたはテキスト入力で文字列を受け取ります。 コンテキストの付与 発話テキストだけ送っても、LLMは「今どのレシピの何工程目か」という情報を知りません。そのため、コンテキストとしてページの位置情報、工程の調理内容や使用する食材も送付しています。このような構成にすることで、ユーザーが「省略した言葉」を補うことができます。人間同士の会話で「次」と言えば通じるのは、お互いが状況を共有しているからです。LLMにも同じ状況を渡すことで、人間相手のように省略して発話しても操作することができます。また、騒音で音声認識が乱れてユーザーの発話を正確に書き起こしできない場合でも、表記ゆれや誤変換を吸収してLLMが意図を汲んで操作することができます。 LLMが遷移先を判断 システムプロンプトのルールに従い、context を見て遷移先を決定します。JSON形式で返答します。 { "action": "navigate", "page": "recipe", "params": { "recipeId": "recipe-001", "stepNumber": 4 } } しばしばLLMの出力をアプリケーションで扱うとき、プロンプトで「JSON形式で出力して」と指示しても、余分な説明文が付加されていたり、フォーマットが微妙に崩れていたりと出力がぶれることがあります。そこで、Amazon Bedrock の Structured outputs を利用して一貫性のあるJSON出力に強制しています。Structured outputs は、必要な形式を事前に指定してそれに一致するレスポンスを受け取ることができる機能です。 フロントエンド側でページを遷移 フロントエンド側のコードで、返ってきたJSONの action を見て処理を振り分けます。対応するページコンポーネントの再描画や、ページ遷移を実施します。 4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み 音声の認識には、アドバンスト・メディア社の提供する AmiVoice を採用しています。 マイクの起動 音声認識特化型Bluetoothマイク AmiVoice Front WT01 を介してマイクを起動します。AmiVoice Front WT01は物理ボタン付きのデバイスで、ボタンを押すと Web Bluetooth API を介してブラウザ上のアプリケーションに接続します。Web Bluetooth APIはブラウザからBluetooth機器に接続する仕組みです。 発話内容の読み取りと発話区間の自動検出 AmiVoice APIを利用して発話した内容をテキスト化します。AmiVoice APIには同期・非同期 HTTP と、WebSocket インタフェースがありますが、WebSocketインタフェースを利用して中間認識結果をリアルタイムで表示しています。ユーザーの体感速度を大きく左右する要因です。 また、音声の中で発話区間を自動検出しているため、話し終えたタイミングでボタンを押すことなく発話の終了を検知しています。AmiVoiceの発話検出では深層学習モデルを使って、 人の声とそれ以外を区別していることが特徴 です。 最終的に、テキスト化されたコマンドを Amazon Bedrock AgentCore に送信します。 5. 音声認識エンジン: AmiVoice の技術 (1) AmiVoice の技術的特徴 音声認識には、音声から特徴量を抽出する音響分析と、特徴量を入力として認識結果のテキストを得る認識デコーダの二つのステップがあります。様々な周波数で構成されている波形データを音響分析で音の特徴に数値化して、その特徴量を認識デコーダに入力しています。 AmiVoice APIは、認識デコーダのタイプにより、「DNN-HMMハイブリッド型（以下、ハイブリッド型）」「End-to-End型」の2つのタイプがあります。伝統的な統計モデルである、「発音辞書」「音響モデル」「言語モデル」を組み合わせて音声認識を行うハイブリッド型に対して、End-to-End型は音声入力から直接文字列を出力する一体型の処理という大きな違いがあるのですが、どちらのタイプでもDNNというディープラーニングモデルが使われています。 図6 : ハイブリッド型認識デコーダのイメージ DNN（Deep Neural Network：ディープニューラルネットワーク）は、多層構造を持つニューラルネットワークです。ニューラルネットワークは、生物の神経回路網を計算機上で模した技術であり、音声認識の分野ではDNNを用いた音響モデルが、音声特徴量から音素を推定する仕組みとして従来のGMM-HMMに代わって主流となりました。その後、音声認識技術は、時系列データを扱いやすいLSTMやBiLSTM、さらに広範囲の文脈を効率的に学習できるTransformerへと発展してきました。これらのモデルは構造こそ異なりますが、いずれも音声と発話内容の関係を学習し、入力音声から発話内容を推定するという基本原理は共通しています。 AmiVoice APIは、音声認識技術をシンプルにご利用いただけるAPIサービスです。インターネットからの簡単な登録だけで、すぐに利用を開始できるため、音声認識機能を手軽かつスピーディーにアプリケーションやサービスへ組み込むことができます。日本語に対する高い認識精度を特長とし、ビジネス利用を想定した言語モデルにより誤認識の低減を実現しています。また、医療・金融・保険・コンタクトセンターなどの業界特有の専門用語に強く、製品名や固有名詞の登録にも対応しています。特別な知識や発声の訓練を必要とせず、普段どおりの自然な会話を高精度に認識できます。また、話者による発音の傾向やイントネーションの違いの影響を受けにくく、騒音環境や電話音声でも安定した認識性能を発揮します。国内で開発・運用されているため、音声データを国内環境で安全に管理できる点も大きな特長で、セキュリティを重要視するお客様にも多数選ばれています。 図7 : AmiVoiceの音声認識技術 AmiVoice APIを選んでいただいたお客様に高く評価されているのがリアルタイム性を追求したWebSocket API のストリーミング型音声認識です。AmiVoice APIのWebSocketインタフェースでは、クライアントが開始s・音声送信p・終了eの各コマンドを段階的に送る一方、サーバーは発話開始S、終話E、認識開始C、途中結果U、確定結果Aをイベントとして逐次返します。これにより、音声を最後まで送り切ってから一括変換するのではなく、発話区間ごとに認識を進めながらテキストを即時更新できます。さらに、発話検出で無音と発話を細かく切り分け、resultUpdatedIntervalなどの設定で途中結果の返却タイミングを制御できるため、ユーザー画面には短い間隔で認識文が反映されます。結果として、リアルタイム音声送信に対して遅延のない逐次テキスト化を実現できる点が大きな特長です。 3つの発話区間を検出した場合の、コマンドとイベントのシーケンスは以下のようになります。 図8 : コマンドとイベントのシーケンス (2) 食品製造現場への適用と認識精度の向上 アプリケーションはキッチン等の騒音の多い環境で利用されることが想定されるため、人の声と不要音を分別して認識できる精度が必要不可欠です。AmiVoice APIは、セグメンタ（VAD）により人の発話区間を高精度に検出し、調理場などノイズの多い環境でも不要音の影響を抑制。背景音・機械音・保留音などを認識対象から適切に除外し、必要な音声だけをテキスト化します。さらに利用シーンに応じたパラメータ調整も可能で、現場で使える安定した音声認識を実現します。 AmiVoice APIは、長年にわたって蓄積した音声認識のノウハウをもとに、高精度な言語モデルを構築しています。最新のニュースや業界文書などのテキストコーパスを活用し、新語や業界特有の用語にも迅速に対応します。また、不要データの除去、専門用語の読み登録、表記統一、誤認識分析、パラメータチューニングなどを継続的に実施することで、変化する言語環境に適応しながら高い認識精度を維持します。これにより、食材名・調理用語など業界特化の語彙への対応も可能です。 同じ用語の表記ゆれに対応する際、音声認識だけでなく生成AI（LLM）を活用する方が効果的な場合があります。例えば、品種名である「ヒノヒカリ」を単語登録し、”ひのひかり”の認識精度を上げることは有用と思われます。しかし、”なす”を「茄子」や「ナス」に変換する目的で単語登録すると、意図しない箇所で「茄子」や「ナス」が誤って出現する可能性があります。このような場合の表記ゆれの統一は、単語登録ではなく、文脈を理解できるLLMに任せることで副作用を抑えながら「なす」「茄子」「ナス」を同じ食材として柔軟に扱うことができ、より高い効果が期待できます。 (3) 今後の展望 AmiVoiceは、クラウド環境だけでなく、スマートフォンやタブレット上で動作するオンデバイス型、お客様環境内で音声認識を完結できるオンプレミス型SDKも提供しています*1。音声データを外部へ送信できないセキュリティ要件の厳しい環境や、ネットワーク帯域が限られる現場でも、高精度な音声認識を実現します。利用環境や運用ポリシーに応じて最適な構成を選択できるため、製造、物流、医療、食品業界など幅広い業務シーンにおいて、安心・安全な音声活用による業務効率化を支援します。 今後は、これまで進めてきた業種・業務に特化したSaaSソリューションとの連携・組み込みをさらに拡大し、音声認識技術の活用シーンを広げていきます。加えて、新たな取り組みとして、AIエージェントが業務プロセスの中で音声認識を活用し、自律的に業務を遂行できる次世代ワークフローの実現を目指していきます。 *1 AWSMarketPlaceではクラウド型AmiVoiceAPI(AmiVoiceCloud Platform)のみの提供となっております 6. 他インダストリーへの応用可能性 本ソリューションのコアパターン「音声認識 (AmiVoice) × AI エージェント (Bedrock AgentCore) × 構造化データ自動記録」は、手が塞がる業務環境全般に適用可能です: インダストリー 応用例 期待効果 食品製造全般 外食チェーンのセントラルキッチン、給食センター、食品工場 在庫自動管理、HACCP 準拠記録、熟練者依存の解消 ホテル・宿泊業 ルームメイキング手順ナビ、備品在庫管理、設備点検記録 品質標準化、記録工数削減 医療・介護 手術室での手順確認、投薬チェック、バイタル記録 衛生環境維持しつつ情報アクセス、記録自動化 製造業 組立作業手順ナビ、品質検査記録、設備保全チェック 教育期間短縮、技能伝承のデータ化 物流・倉庫 ピッキング指示、検品記録、入出庫管理 ハンズフリーオペレーション、誤出荷防止 フィットネス・スポーツ トレーニング指示、フォームチェック、セッション記録 指導品質の標準化、データドリブンな改善 技術的な拡張ポイント: Strands Agents のツール定義 (@tool デコレータ) を差し替えるだけで異なるドメインのエージェントを構築可能 AmiVoice の単語登録を実施することで、医療用語・製造用語などの独自の用語にも精度改善が期待できる AgentCore Runtime のマネージド環境でスケーラブルに運用でき、マルチテナント化も容易 7. まとめ 本ブログでは、セントラルキッチンの業務課題を、AmiVoice による高精度音声認識と Amazon Bedrock AgentCore による AI エージェントの組み合わせで解決するアーキテクチャを紹介しました: AmiVoice — 騒音環境・食品業界用語に対応した高精度な日本語音声認識で、現場の「声」を確実にテキスト化 Amazon Bedrock AgentCore Runtime + Strands Agents SDK — マネージド環境で AI エージェントを運用し、WebSocket ストリーミングによるリアルタイム対話を実現 Claude Sonnet 4 の Tool Use — 14 個のツールを自律的に使い分け、曖昧な音声コマンドから適切なアクションを導出 構造化 JSON レスポンス設計 — エージェントとフロントエンドの明確なインターフェース契約により、UI 制御の信頼性を確保 サーバーレス従量課金構成 — DynamoDB On-Demand + Lambda ARM64 + CloudFront でコスト効率を最大化 「手が塞がっている環境でのデータ入力障壁」は、食品製造に限らず多くの業界で共通する課題です。高精度な音声認識と AI エージェントの組み合わせは、この課題に対する有力なソリューションパターンです。本アーキテクチャが、音声 AI エージェントシステムの設計を検討されている方の参考になれば幸いです。 著者について 戸塚 智哉 (Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 本田 光来 (Miku Honda) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行っているソリューション アーキテクトです。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。 兼子 友里朱 (Yuria Kaneko) AWS Japanのアカウントマネージャーです。主にサービス業・SIer業界のエンタープライズ企業をご支援しています。新規案件創出数アジア太平洋地域1位（FY24 第1四半期・上半期）、生成AI案件創出金額日本1位（FY25 第4四半期）。趣味はクラシックバレエで、コンクールでは第2位を受賞しました。薬剤師免許保有。 吉田 明日香 (Asuka Yoshida) 株式会社アドバンスト・メディアのセールスマネージャーです。音声認識サービス「AmiVoice API」の提案・活用支援・協業推進を担当しています。幅広い業界においてお客様の音声データ活用や生成AI活用をご支援しています。 小出 泰久 (Yasuhisa Koide) 株式会社アドバンスト・メディアのエンジニアです。オフィスソリューションや医療機器開発のプロジェクトマネージャーとしての経験を活かし、現場視点での音声認識技術の活用に注力しています。

AWS Japan パブリックセクター技術統括本部では、2026年4月よりセキュリティワークショップを月次で開催しています。第1回・第2回では「 ランサムウェア対策ワークショップ 」として Amazon GuardDuty による脅威検知と AWS Security Hub による統合セキュリティ管理を、第3回・第4回では「 Claude Mythos 時代の脅威対策ワークショップ 」としてフロンティア AI を悪用した攻撃への対策と脆弱性管理をテーマにしてきました。 第5回となる今回はテーマを「信頼性」に拡大し、システムの 「耐障害性（レジリエンス）」 を継続的に向上させるアプローチをお伝えしました。 サイバー攻撃への「防御」と並び、障害が発生しても迅速に回復できる「耐障害性」は、ミッションクリティカルなシステムを運用するうえで不可欠な要素です。近年はリリース頻度の増加や AI を活用した開発の加速により、システム環境の変化がこれまで以上に速くなっています。故障しないことを前提とする堅牢なシステムを目指すだけでは十分ではなく、 継続的にレジリエンスを強化し続ける仕組み が求められています。 本記事では第5回の開催レポートと、次回（第6回）のご案内をお届けします。 ワークショップの概要 項目 内容 テーマ FlyWheel で回す継続的なレジリエンス強化 日時 2026年8月21日（金）14:30 – 17:30 形式 オンライン（WebEx） 主催 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 対象 システムアーキテクト、運用担当者、耐障害性（レジリエンス）向上に関心がある方 関連サービス AWS Resilience Hub, AWS Fault Injection Service, Amazon CloudWatch など 座学では「耐障害性ライフサイクル」と「FlyWheel」の考え方を学び、AI を活用した各ステージの効率化や AWS 支援プログラムもご紹介しました。ワークショップでは、たこ焼き注文システムを題材に、耐障害性ライフサイクルの各ステージを実際に体験いただきました。講師はシニア ソリューションアーキテクトの小本昌兵が務めました。 座学: 耐障害性ライフサイクルと Resilience FlyWheel 「壊れない」から「壊れても素早く回復する」へ Amazon CTO の Werner Vogels が語る “Everything fails, all the time.”（すべてのものは、いつでも壊れうる）という原則に基づき、稼働期間中に要件が変化していく中で、故障しないことを前提とする堅牢なシステムを目指すのではなく、 障害が起きても素早く回復するシステム を目指すことが重要になっていきます。座学では、まずこのメンタルモデルの変化をお伝えしました。 耐障害性ライフサイクルフレームワーク — 5つのステージで具体的に取り組む この考え方を実践に移すために、AWS が規範的ガイダンスとして公開している「 耐障害性ライフサイクルフレームワーク 」に沿って、5つのステージを解説しました。 目標を設定 — ビジネスインパクト分析（BIA） を通じて RTO（目標復旧時間）/RPO（目標復旧時点）/SLO（サービスレベル目標）を設定し、ユーザージャーニーとクリティカルパスの視点で目標を定義します。サービス視点で、「どのサービスが止まると、どれだけの影響が出るか」を定量的に把握するところから始めます。 設計と実装 — AWS Well-Architected Framework の信頼性の柱を基に、障害分離境界（データプレーン/コントロールプレーン）の区分、静的安定性（障害時にコントロールプレーンに依存せず、元の設定のままワークロードが動き続ける設計）の確保といった設計原則を適用します。座学では耐障害性モデリング（SEEMS: 5つの一般的な障害カテゴリ）についても具体的に紹介しました。 評価とテスト — 「目標を達成できるか？」を本番相当の環境で検証していきます。評価は、一度きりではなく、継続的に仮説検証を行います。AWS Fault Injection Service（AWS FIS）による障害注入の実行/管理や、AWS Resilience Hub を活用した耐障害性の評価が役に立ちます。 運用 — オブザーバビリティ（可観測性）を確保し、カスタマーエクスペリエンス指標を継続的にモニタリングします。異常を早期に検知し、影響が拡大する前に対処するための体制を整えます。 対応と学習 — インシデントが発生した場合、その体験から学ぶことが重要になります。インシデント発生後に、CoE（Correction of Errors）を使って振り返りと再発防止策を文書化し、組織として学びを蓄積します。この学びが次のサイクルの「目標設定」にフィードバックされます。 Resilience FlyWheel — 継続的に回し続け、加速する 上記5ステージを1回実施して終わりではなく、 FlyWheel（フライホイール）として継続的に回し続ける ことが本ワークショップのコアメッセージです。Amazon のビジネスモデルフライホイールに着想を得たこのアプローチでは、初回のサイクルこそ重たいですが、サイクルを回すたびに複利でレジリエンスが向上し、回転が加速していきます。 さらに、 AI を活用して耐障害性フレームワークを効率化する方法 や 次世代の AWS Resilience Hub 、ビジネスインパクト分析(BIA)、レジリエンススコアプログラム(RCP)など、AWS の支援サービスもご紹介しました。BIA は耐障害性ライフサイクルフレームワークを開始するための目標設定をサポートするプログラムです。ご関心ある方は担当の AWS アカウントチームにお問い合わせください。 ワークショップ: たこ焼き注文システムで体験する耐障害性ライフサイクル ワークショップの狙い 座学で学んだ耐障害性ライフサイクルの各ステージを、参加者自身が実際に手を動かして体験することが本ハンズオンの狙いです。抽象的なフレームワークを具体的なプロセスとして体感し、自組織のシステムに当てはめてイメージしていただくことを目指しました。ワークショップ教材は こちら からご確認いただけます。 具体的に何を体験できるか 架空の「たこ焼き注文システム」を題材に、耐障害性ライフサイクルに基づき、Active/Active アプリケーションの目標設定から運用まで、包括的に体験をしました。 目標の設定 : アプリケーションのダウンタイムにより発生する売上の損失から、具体的なRTOとRPOの値を決定。レジリエンスポリシーを作成して、Resilience Hub に設定 設計の見直し : マルチAZ で自動復旧を実現するため、オートゾーンシフトの有効化 運用監視の設定 : アプリケーションの監視のための、Amazon CloudWatch Synthetics Canary の作成とアラート設計 評価とテスト : Resilience Hub による評価と回復力テストの実践（AZ で電源が中断されたというシナリオで、ゾーンシフトが設計通りに動作するかを確認する） インシデント対応 : 障害発生時の対応フローのレビュー 参加者からのフィードバック 参加者からは、「ハンズオンについては、やや難しかったが、更に耐障害性を高めていく上で参考になった」など、ポジティブなご意見をいただけました。また、AWS Resilience Hub の利用状況を伺ったところ、大半の方がまだ利用されていない状況でした。ワークショップ後には、約70%の方が Resilience Hub を「利用してみたい」と回答いただきました。定量的な目標設定と継続的な評価はレジリエンス改善の基礎となります。今後も個別案件の支援などを通じて、耐障害性を高めるお手伝いをしていきたいと考えています。 まとめと次回のご案内 本ワークショップのキーメッセージ 本ワークショップを通じて、以下の3点をお伝えしました。 メンタルモデルの変化 : 「障害がおきないシステムを作る」アプローチの限界を認識し、「障害がおきても素早く回復するシステムを作る」ことに意識を向ける。障害は起こりえる前提で備える。 実践のフレームワーク : AWS 規範的ガイダンス「耐障害性ライフサイクルフレームワーク」（目標設定→設計・実装→評価・テスト→運用→対応・学習）の5つのステージが、具体的な取り組みの指針となる。 継続的な改善 : ライフサイクルを一度回して終わりではなく、FlyWheel として継続的に回し続けることで、レジリエンスを加速度的に向上させる。AI や AWS の支援サービスを使って、このサイクルをさらに効率化する。 耐障害性の向上は、一度きりの対策ではなく日々の運用の中で磨き続けるものです。本記事がその第一歩を踏み出すきっかけになれば幸いです。ミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド活用で課題をお持ちの場合は、担当の AWS アカウントチームにご連絡ください。 第6回: AWS WAF 実践ワークショップ — AI時代のWebアプリケーション防御を学ぶ 項目 内容 日時 2026年9月28日（月）14:30〜17:30 形式 オンライン（WebEx） 座学 AWS WAF を活用した Web アプリケーションの保護 ハンズオン WAF ルールの設定からログ分析・可視化 対象 システムアーキテクト、セキュリティ担当者、Web アプリケーション運用担当者 関連サービス AWS WAF, AWS Shield, Amazon CloudWatch, Amazon Athena AI Bot の急増や DDoS 攻撃の高度化により、Web アプリケーション防御の重要性は、ますます高まっています。次回は AWS WAF のマネージドルール、Bot 対策、各種 AWS サービスと連携したログ管理の仕組みなど、実践的な AWS WAF の活用手法をご紹介します。座学のみ、ハンズオンのみのご参加も可能です。ご関心ある方は担当の AWS アカウントチームにお問い合わせください。 著者 日吉 康仁 (Koji Hiyoshi) — AWS Japan, Public Sector, Senior Solutions Architect 今井 真宏 (Masahiro Imai) — AWS Japan, Public Sector, Senior Solutions Architect

本記事は 2026 年 8 月 27 日 に公開された「 A year of expanding choice for VMware customers on AWS 」を翻訳したものです。 Amazon EVS が一般提供 (GA) を開始してから 1 年以上が経ちました。人材やツール、運用ワークフローへの既存の投資を維持しながらクラウドでより多くの選択肢を求めていた VMware ワークロードのお客様にとって、Amazon EVS の GA 開始は大きな節目でした。Amazon EVS を使用すると、AWS 環境と統合された Amazon EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を実行できます。チームは VMware のソリューションを継続して使用しながら、AWS の機能とグローバルな展開力を活用できます。 この 1 年間で新しい VCF バージョンのサポートを追加し、デプロイの自動化機能をリリースし、新しい EC2 インスタンスへの対応も拡大してきました。VCF 9 の Memory Tiering や NSX Federation の設定に関するガイダンスも公開し、新しい Windows Server ライセンスの権利オプションも導入しました。これらの機能追加により AWS で稼働する VMware ワークロードのデプロイ、運用、スケーリング、保護をお客様がより細かく制御できるように取り組んでいます。 ここからは最初の 1 年間でお届けした内容を詳しく紹介します。 VCF 9 を思い通りにデプロイ 今年に入って Amazon EVS での VCF 9.0 および 9.1 のサポート を発表しました。VCF 9 では Amazon EVS が VPC 内に EC2 ベアメタルインフラストラクチャをプロビジョニングし、アーキテクチャや設定はネイティブの VCF Installer でお客様自身が管理します。この制御レベルは VCF のライフサイクル全体に及ぶため、オンプレミスと同じ VCF の機能を Amazon EVS でも利用できます。 自動インストールを好むチーム向けには Solutions for Amazon EVS GitHub リポジトリ で Amazon EVS Deployment Orchestrator を公開しました。Amazon EVS Deployment Orchestrator には Amazon EVS 上に完全に構成された VCF 9 環境をデプロイするためのエンドツーエンドの自動化が含まれています。今後も計画、デプロイ、移行、運用のための新しいソリューションを追加していきます。 新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール 4 月には i7i.metal-24xl のサポート を追加して EC2 インスタンスの選択肢を拡大し、本日 i7i.metal-48xl のサポート を発表します。この新しいインスタンスは物理コア 96 個、メモリ 1.5 TB、ローカル NVMe ストレージ 45 TB を備え、負荷の高い VMware ワークロードに対応する大きなキャパシティを提供します。 第 5 世代 Intel Xeon Scalable プロセッサーを搭載した i7i インスタンスは、i4i インスタンスと比べてコンピューティング性能が最大 23% 向上し、料金性能比も 10% 以上向上しています。i7i.metal-48xl はコア数とメモリ容量が増えているため、ホストあたりでより多くの VM を実行でき、少ないホスト数でも環境を拡張できます。 また Amazon EVS の対応リージョンを 22 の AWS リージョンに拡大し、エンドユーザーの近くにワークロードを配置したり、ビジネス目標やデータ主権の要件に合わせたデプロイができるようになりました。さらに環境の最大サイズを 16 ホストから 32 ホストに増やしました。1 つの環境内で大規模な単一クラスターを構築することも、複数の小規模クラスターに分けることも、要件に合わせて自由に組み合わせることもできます。 Memory Tiering でクラスター密度を向上 VCF 9 は、ホストがローカル NVMe ストレージを追加メモリとして利用できる Memory Tiering を導入しました。同じホスト数でもクラスターが実質的に最大 2 倍のメモリを扱えるようになり、VM の密度を高めながらハードウェアとライセンスのコストを削減できます。Memory Tiering は i4i および i7i の両インスタンスファミリーに対応しています。 Memory Tiering の詳細解説 ではこの機能の仕組みや、Amazon EVS でのサイジングと有効化について説明しています。 Windows Server のライセンスをシンプルに Windows Server のライセンスは VMware の移行を計画する際に障壁となることがあります。 Amazon EVS Windows Server Licensing では Windows VM を実行するための 2 つの選択肢を用意しています。対象となる Windows Server ライセンスと移行権を持つお客様は、そのライセンスをそのまま Amazon EVS に持ち込めます。移行権のない VM については、Amazon EVS で Windows Server ライセンスの権利を追加し、使用した分だけ vCPU 時間単位で料金を支払えます。権利は環境の変化に応じて追加・削除できるため、個々の VM 単位でライセンスを付与し、ホスト全体にライセンスを付与するコストを回避できます。 Amazon EVS で VMware ワークロードを保護・復旧 Amazon EVS を使うと、チームが既に使い慣れた VMware のツールとプロセスのまま、AWS 上で VMware ワークロードを柔軟に保護・復旧できます。オンデマンドで復旧環境をデプロイし、ワークロードを変更せずに稼働させ、復旧目標に合わせてキャパシティをスケールできます。 Amazon EVS における VMware ワークロードの災害復旧ガイド では復旧方法と保護オプションを比較しており、ワークロードごとに復旧時間、復旧時点、コスト、運用要件のバランスを取れます。 サイト間でネットワークとセキュリティを拡張 またオンプレミスの NSX 環境と Amazon EVS 環境を単一のコントロールプレーンで管理できる NSX Federation のサポートも発表しました。NSX Federation により拠点をまたいでネットワークセグメントとセキュリティポリシーを拡張し、データセンターと AWS の間で統一されたネットワーキング基盤を構築できます。大規模なレイヤー 2 拡張、統一された Distributed Firewall ポリシー、簡素化された災害復旧のフェイルオーバーを必要とするお客様にとって、NSX Federation は HCX の移行ワークフローを補完する長期的なネットワーキングと復旧の基盤となります。 NSX Federation の詳細解説 では両方の技術がどのように連携し、それぞれがどのような場面に適しているかを説明しています。 より広い選択肢を提供した 1 年間 今年リリースしたすべての機能はチームが使い慣れた VMware のツールと運用ワークフローを維持しながら、Amazon EVS でより多くの制御、選択肢、柔軟性を提供するという目標を支えるものです。VMware を利用している組織であれば、Amazon EVS を VMware ベースのワークロードを実行する世界最高の場所にしたいと考えています。 次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください 最新の取り組みを実際にご覧になりたい方は、8 月 31 日から 9 月 3 日までラスベガスの The Venetian で開催される VMware Explore 2026 にぜひお越しください。 今すぐセッションをスケジュールに追加してください 。 ブレイクアウトセッション [CLOB2172LVS] Amazon EVS with VCF 9: Expanding choice and flexibility for VMware on AWS – 9 月 2 日(水) | 午後 3:15 – 午後 4:00 | Level 3, San Polo 3505 20 分間シアターセッション [CLOQT2319LVS] 20-minute guide to running VMware Cloud Foundation 9 on Amazon EVS – 8 月 31 日(月) | 午後 5:30 – 午後 5:50 | The Hub Theater VMware Explore にご参加の有無を問わず、皆様が取り組んでいる内容についてぜひお聞かせください。 Amazon EVS の製品ページ にアクセスして利用を開始するか、AWS のアカウントチームに連絡して次のステップを検討してください。 著者について Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とトランスフォーメーションを担当しています。マーケティングとテクノロジー分野で7年以上の経験を持ち、複雑な技術を分かりやすく伝えるストーリーづくりに情熱を注いでいます。AWS の業務以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーとして、VMware、SAP、Red Hat OpenShift のワークロードを担当するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアの分野で25年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis AWS のシニアテクニカルプロダクトマネージャーとして、インフラストラクチャの移行と Amazon Elastic VMware Service を担当しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS のサービスを活用してお客様がビジネス成果を達成することを支援することに情熱を注いでいます。プライベートでは、旅行を通じて様々な場所や人々、文化に触れることを楽しんでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

AI 駆動開発ライフサイクル (AI-DLC) の基礎を体系的に学べるコース「 AI-DLC Foundations 」の日本語版として「 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ 」が、AWS Skill Builder で公開されました。この記事では、コースの概要と全 8 モジュールの内容を紹介します。 今すぐコースを受講する場合はこちら コースの概要 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ は、AI-DLC について基礎から体系的に学べる全 8 モジュールのオンラインコースです。動画とスライドを使い、自分のペースで受講できます。概念の理解から始まり、原則、ワークフロー、ベストプラクティス、そしてインセプション・コンストラクション各フェーズの Deep Dive まで段階的に学びます。全モジュール完了後の Assessment に合格すると AI-Driven Development Lifecycle Knowledge Badge を取得できます。どなたでも無料で受講可能です。 AI 駆動開発ライフサイクル(AI-Driven Development Lifecycle, AI-DLC) とは 多くの企業が AI コーディングツールを導入していますが、「コーディング工程の時短は実現できても、開発ライフサイクル全体のアジリティには繋がっていない」という課題が聞かれます。AI-DLC は、この課題に対する AWS の回答です。 AI-DLC (AI 駆動開発ライフサイクル) は、AWS が提唱している、AI 駆動型ソフトウェア開発の方法論です。AI が開発プロセス全体をオーケストレーション (計画策定、タスク分解、アーキテクチャ提案など) し、人間が検証・意思決定・監督の責任を保持します。 これは、既存のプロセスに AI を狭い範囲で後付けする「AI 支援型 (AI-Assisted)」アプローチとも、AI が自律的にソフトウェアを構築する「AI 管理型 (AI-Managed)」アプローチとも異なります。AI-DLC では、AI がプロセス全体をオーケストレーションしながらも、人間が意思決定と監督に集中することで、開発速度・品質・アジリティのパラダイムシフトを実現します。 開発はインセプション (Inception) フェーズ、コンストラクション (Construction) フェーズ、オペレーション (Operation) フェーズの 3 つのフェーズで進みます。インセプションではビジネスの意図を精緻な要件・設計・作業計画に変換し、コンストラクションでは AI がコード・テスト・設計を生成して人間が検証し、オペレーションではデプロイ・監視・運用を自動化します。 AI-DLC の方法論について詳しくは「 AI-DLC 入門 ― 開発の未来を形づくる新しいアプローチ 」および「 AI駆動開発ライフサイクル（AI-DLC）の本質は組織、文化、プロセスの変革 〜AI-DLC導入のアンチパターン〜 」もご参照ください。 モジュールの一覧と概要 本コースは以下の 8 モジュールとAssessment で構成されています。 1. AI-DLC の概要: AI-DLC とは何か、なぜ必要なのか、AI-DLC の中核となる概念を学びます AI コーディングツールが普及した今、なぜ組織全体のアジリティが上がらないのか – その問いへの答えから始まります。AI 支援型・AI 管理型とは何が根本的に異なるのかを明確にし、AI-DLC の中核であるワークフローの全体像を掴みます。 2. 従来の SDLC (ソフトウェア開発ライフサイクル) からの進化: ソフトウェア開発の方法論の歴史を振り返り、なぜ AI 時代に「再構築」が求められるかを学びます ウォーターフォールからアジャイルへの転換は、ハードウェアの高速化やインターネットの普及がビジネスのスピードを変えた結果として現れました。同じ構造が今、AI によって繰り返されています。AI が数時間でコードを生成・検証できるのに、翌日のスタンドアップミーティングまで議論を待つ意味があるのか ? この問いを通じて、開発プロセスへの再構築が必要な理由を理解します。 3. AI-DLC の原則: AI-DLC を定義する 9 つの原則を学びます AI-DLC は「既存プロセスを速くする」のではなく「AI 時代にネイティブな新しいプロセスを作る」という根本的な発想の転換に基づいています。このモジュールでは、AI がリードし人間が意思決定に集中する対話モデル、設計を方法論の DNA として組み込む考え方、AI の強みと限界に合わせてプロセスを最適化するアプローチなど、AI-DLC を支える 9 つの原則を一つずつ解説します。 4. AI-DLC ワークフローとコラボレーション: AI と人間の継続的なワークフローと、チームのコラボレーションパターンを学びます AI が数時間で十分な実装を生成する世界では、チームが迅速で質の高い決定を下す能力がボトルネックになります。このモジュールでは、AI が計画を作成し人間が承認するサイクルの詳細と、プロダクトオーナー・開発者・セキュリティ・運用が一体となって意思決定を加速するコラボレーションパターンを学びます。Amazon の リーダーシッププリンシプル に由来する One-Way Door / Two-Way Door の意思決定フレームワークも扱います。 5. AI-DLC ベストプラクティス: 実践で検証された 7 つのベストプラクティスを学びます AI-DLC を実プロジェクトで運用してきたチームが蓄積した知見をご紹介します。AI に一度にすべてを解決させようとしない、AI に渡すコンテキストの質を高める、AI が勝手に範囲を広げないよう境界を設定する、レガシーシステムを扱う際の注意点など、明日から使える実践的なガイドラインを学びます。 6. AI-DLC の準備、測定: 組織で AI-DLC を始めるための準備と、成功の測定方法を学びます AI-DLC を組織で始めるには何が必要で、その効果をどう測るかを解説します。まず事前準備として、技術環境の整備、役割を横断した同じ場所での作業体制、ドメイン固有の知識の 3 つの要素を確認します。そして効果の測定では、各フェーズでの削減時間と、要件の精度・設計の安定性・コードの受け入れ率の 2 つの軸で評価する方法を学びます。重要なのは、作業ごとの AI のスピードではなく、開発ライフサイクル全体への影響を測定するという考え方です。 7. インセプションフェーズ Deep Dive: インセプション (Inception) フェーズを深掘りします 「何を作ろうか」という会話から、チーム全員が「何を作るべきか」を明確に共有するまでのプロセスを、従来の数日〜数週間から数時間レベルに圧縮します。チーム全員が AI と共にリアルタイムで要件を精緻化するモブエラボレーション (Mob Elaboration) や、インテント (意図) から作業ユニット (Unit of Work) への分解手法を具体的に学びます。 8. コンストラクションフェーズ Deep Dive: コンストラクション (Construction) フェーズを深掘りします インセプションで定義した作業ユニットを、テスト済みでデプロイ可能なソフトウェアへ変換するフェーズです。従来のスプリントに代わる高速イテレーション「ボルト (Bolt)」の進め方、最初のボルトで End-to-End のアーキテクチャを証明する Walking Skeleton、そしてチーム全体がリアルタイムで設計に取り組むモブコンストラクション (Mob Construction) の実践方法を学びます。 Assessment: 全モジュール完了後に受験できる理解度確認テストです。合格すると AI-Driven Development Lifecycle Knowledge Badge を取得できます。 受講方法 AWS Skill Builder に無料アカウントを作成 (または既存アカウントでサインイン) こちらのリンク からコースに直接アクセス、または「AI-DLC」で検索 各モジュールは動画＋テキストコンテンツで構成されています。自分のペースで受講してください まとめ AI-DLC 学習コースの日本語版が無料で利用可能になりました。AI を活用した開発の新しいアプローチに興味がある方は、ぜひ受講してみてください。 コースを受講する (日本語) AI-DLC のさらに詳しい実践方法に興味がある方は、「 AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 」もご覧ください。

本記事は Physical AI デモ開発の技術解説シリーズ Part 2 です。 Part 1: 企画からステージ制作、アプリケーション開発まで では、企画からクラウド側アプリケーションまでの開発と、その過程での生成 AI 活用を紹介しました。Part 1 のまとめに「プロセスの型が品質を守る」という言葉があります。本記事はその続きです。実機のロボット開発では、この型に安全と物理世界の検証が加わります。 AWS Summit Japan 2026 の展示エリア「AWS EXPO」で私たちは、FANUC の協働ロボット CRX-20iA/L （以下、CRX）2 台と配送車両を使い、AI エージェントが配送経路上の障害物を見つけ、つかんで運び、配送を復旧するデモを展示しました（ 展示紹介記事 ）。2 日間の Summit 期間中、障害物のピックは失敗ゼロでした。ロボット向けの追加学習は行っていません。 本記事でわかることは次の 3 つです。 クラウド上で動く AI エージェントと、従来のロボット制御の役割分担 — 何を任せ、何を任せなかったか 開発者の手元で動くコーディングエージェント（Kiro や Claude Code のような AI コーディング支援ツール）を、実機が動く開発で安全に使うためのルール ROS 2 ベースの標準スタックとシミュレーター上での検証で、実機の試行錯誤を最小にする方法 — 豊富な公開情報がある OSS を活用することで、コーディングエージェントによる適切な提案が可能になります 図 1: AWS Summit Japan 2026 の展示フィールド。2 台の協働ロボットと配送車両、周回路を配置 ロボットシステムの構成 — 2 台の CRX と 1 つの AI エージェント このデモの設計は一言で表せます。判断はクラウド、実行はエッジ。状況を見て次の行動を決めるのは、 Amazon Bedrock AgentCore （AI エージェントの実行基盤）の上で動く AI エージェント（Claude Sonnet 4.6 / Claude Haiku 4.5）で、その判断が物理世界の動作に変わります。指令は AWS IoT Core を経由してエッジの ROS 2（センサーや制御機能を連携させるロボット向けのソフトウェア基盤）へ届き、その上で動作計画と衝突判定を担うライブラリである MoveIt 2 が軌道を計画して実機が動きます。本記事で扱うのは、このクラウドからエッジまでの一本の経路の作り込みです。クラウド側の作りは Part 1 をご覧ください。 エッジ側の構成はシンプルです。この ROS 2 スタックを載せた Ubuntu 24.04 の制御 PC が、CRX のコントローラーと 1 対 1 で接続します。1 対 1 に固定したのは、同じコントローラーへの二重接続を構成上防ぎ、トラブル時の切り分けを単純にするためです。アーム先端のカメラは、障害物の観察と位置・向きの計測の両方に使います。 このロボット側の仕組みは、ロボットチーム 4 名、およそ 2 か月の集中開発で作りました。以降の章では、この体制で本番 2 日間を走り切るために、どのようにエッジとクラウドの役割分担を決め、何を検証したかを工程順に紹介します。 図 2: 開発フィールドの全体像。2 台のロボットを背中合わせに配置し、中央の ChArUco ボード（チェスボードとマーカーを組み合わせた校正ボード）を共通の原点にした 設計 — 何をどこに任せるか 判断と動作の分離 クラウドの AI エージェントは、「アームを動かしてカメラの視点を変え、状況をさらに調べる」「アームで障害物を持ち上げて取り除く」「人に支援を求める」という選択肢から、次の行動を一つずつ選びます。観察も除去も実体はアームの動作であり、AI エージェントの選択がそのまま実機の動きになります。 ただし、任せるのは判断だけです。画像と言語による指示を入力として、動作指令までを一つのモデルで生成する VLA（Vision-Language-Action）モデルは採用せず、クラウドとエッジで役割を分けました。クラウド側では、Claude Haiku 4.5 がアーム先端のカメラ画像から障害物が何かを認識し、その結果を踏まえて Claude Sonnet 4.6 が次の手順を決めます。決めるのは「どの動作を、地図上のどこに対して行うか」までです。指令は、あらかじめ実装した動作（通路の探索、障害物の把持と搬送など）の指定と、フィールド共通の地図座標の組で届きます。受け取ったエッジ側は、その地図座標を自分のロボット座標系に読み替えます。そこへ至る軌道は、MoveIt 2 がその都度計画して実行します。 アームの姿勢や移動経路を AI エージェントに生成させることはありません。AI エージェントが指す障害物の位置も地図上の大まかな指定にとどめ、把持に使う正確な位置と向きは、エッジ側で、障害物に付けたマーカーをアーム先端のカメラで捉え、その見え方から OpenCV で計算した値で確定させます。クラウドが状況を見て意図を決め、エッジが意図を安全な動作に翻訳します。 この分け方で足りるかどうかは、扱う対象の性質で決まります。VLA が向くとされるのは、布を畳むように対象の形が変わり続け、見た目に応じて動きを作り続ける必要がある操作です。一方、今回のデモで扱う把持対象の障害物は形の変わらない剛体としました。把持の直前に位置と向きを計測してしまえば、あとの動きは事前に定義した把持動作と動作計画で組み立てられるため、AI エージェントの出力をロボットの動作指令に直結させる必要はありません。汎用モデルの判断と既存のロボット制御を組み合わせることで、追加学習なしに、柔軟な判断と実績ある制御の確実な動きを両立しました。 図 3: Claude Haiku 4.5 が画像から障害物を認識し、Claude Sonnet 4.6 が次の手順を判断する。クラウドの指令は AWS IoT Core を介してエッジ側の 2 台のロボットへ届く インターフェース仕様の先行合意 — 座標系・単位・通信 クラウドとロボットのインターフェース仕様で、機能一覧より先に固定したのは座標系と単位です。原点の位置、各軸の向き、右手系か左手系か、位置の単位（mm の整数）、角度の表現（度ではなくラジアン）。とくに座標軸の向きの取り決めが食い違うと、同じ数値が鏡写しの別の位置を指します。こうした座標系や単位の誤りは、数値としては正常なまま、ロボットが誤った場所へ動く形で現れるため、JSON の形式検証では見つかりません。 2 台のロボットの座標系は、フィールド中央に固定した校正ボード（図 2）を共通の原点として突き合わせています。障害物の位置計測に使うマーカーとは別物です。マーカーで測った位置を自分のロボットの座標へ正しく変換できるかは、この校正の精度で決まります。本番前に校正をやり直した際の実測は、校正点への当てはまり（RMSE）で 1〜4 mm でした。校正のずれは実行時のエラーとしては現れず、静かに精度だけを損ないます。 そこで、合意した値が現物と一致しているかを起動時に検証します。たとえば位置計測に使うマーカーは、印刷倍率が少しずれていても検出自体は成功してしまい、座標だけが誤った値になります。マーカー寸法の実測値と設定値を照合して、一致しなければ先へは進まず、担当者が設定を直して測り直すか、中止するかを選びます。人の注意力に頼らず、機械が先に気づく形にしておくのが要点です。 座標系と単位に加えて、通信も用途で分けました。 用途 手段 指令 AWS IoT Core の MQTT 5 Request/Response 配送車両の状態 AWS IoT Device Shadow （デバイスの最新状態をクラウドに写しとして保持する機能） 画像・深度 Amazon Simple Storage Service (Amazon S3) （大きなデータは指令の経路に載せない） 指令の配信方式では同じメッセージが重複して届き得るため、識別子を記録して重複実行を防いでいます。認証には AWS IoT Core の証明書ベースの仕組みを使い、長期のアクセスキーをデバイスに埋め込まずに一時的な認証情報を取得する構成にしています。 自前実装の最小化 ロボット制御スタックは、 FANUC 公式の ROS 2 ドライバー を土台に、エンドエフェクター（開閉式グリッパー）、仮想壁、クラウド連携などデモ固有の機能だけをパッケージとして追加しました。ドライバーは、Stream Motion という通信機能を使って動作データをやり取りします。これは FANUC のロボットコントローラー向けに提供される固有のインターフェースで、外部 PC から短い周期で動作指令を送り続けることで、コントローラーの外からリアルタイムに近い制御を可能にするものです。MoveIt 2 が計画した軌道は、この周期通信に載って実機で実行されます。ドライバー本体のコードは 1 行も変えず、設定の変更だけで 2 台を運用しました。動作計画・衝突判定は MoveIt 2、座標変換は ROS 2 の標準機能です。 図 4: MoveIt 2 による動作計画の様子（ROS 2 標準の可視化ツール RViz の画面）。白が現在姿勢、オレンジが目標姿勢で、黄色の線が自動生成された軌道。仮想壁（フィールド境界）などの制約を考慮した経路を自動で計画する 標準スタックを選んだ効果は、もう一つあります。ROS 2 も MoveIt 2 も OpenCV も公式ドライバーも、公開情報が豊富な OSS です。コーディングエージェントが学習し、参照できる情報が最も多い土俵であり、次章で紹介するコーディングエージェント活用の効果は、この選択に支えられています。 実装 — コーディングエージェントに任せる範囲の線引き ロボット側の開発でも、設計文書、実装、テスト、運用手順の多くをコーディングエージェントとともに作りました。実装リポジトリだけを数えても、約 7 週間で 400 を超えるコミットを重ねています。新規実装（feat）と修正（fix）が同数規模で回った週もあります。会場での現地調整も含めた追い込みの 3 日間には、100 件を超えるコミットが入りました。この開発スピードを維持しながら、実機の安全をどう確保するか。それが本章の主題です。Part 1 で紹介したクラウドアプリケーションの開発と違うのは、誤った変更が物理的な事故につながり得ることと、検証の最終段に「実機で動かす」という共有リソースの制約があることです。そこで、コーディングエージェントを速く走らせる工夫より先に、守るべき前提を毎回読み込ませる形で渡すことに時間を使いました。 開発ルールの文書化 多くのコーディングエージェントには、リポジトリに置いた文書を作業の最初に読み込む仕組みがあります。この文書に、コーディング規約だけでなく次を明文化しました。 一次情報の参照ルール: ロボット固有の挙動に関わる変更は、公式ドキュメントと公式ドライバーの実装を確認してから行う 禁則: 過去の事故につながった変更は、経緯とともに禁止事項として残す 完了条件: コード上のテストが通っただけでは不十分とする。実機をつながず、シミュレーター上のロボットモデルに軌道を実行させ、関節が動くことを RViz（ROS 2 標準の可視化ツール・図 4）の画面で確認する。スクリーンショットやログを検証エビデンスとしてリポジトリの所定の場所に残すところまでを条件とする この確認を回すために、シミュレーション用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを検証環境として用意しました。環境の構築には、開発者ごとのリモート開発環境を AWS 上に用意するサンプルソリューション Remote AWS Development Station (RADS) を使っています。ROS 2 や MoveIt 2、コーディングエージェントまでセットアップ済みの GPU 環境をチームの各メンバーがすぐに使えるため、検証環境の整備に時間を取られません。この手順を開発ルールの文書に書いておくことで、コーディングエージェントは自分が書いた変更をこの環境で自律的に検証します。問題がなければリポジトリに push します。エッジ PC への接続とデプロイも AWS Systems Manager のセッション経由で同じ環境から行い、実機での実行だけは人の承認を得たうえで行います。実機に触れられる時間が限られていても、コードを書く速度と検証の速度を釣り合わせられます。 この文書はコーディングエージェントへの指示であると同時に、4 名のチームの合意の置き場でもあります。人もコーディングエージェントも同じ文書を参照するため、誰の作業でも判断が揃います。あわせて、影響の大きい設計判断は ADR（Architecture Decision Record、設計判断の記録）として残しました。クラウドと ROS 2 の間の通信で「一度目は動くのに二度目から応答しなくなる」問題にはまった際も、原因と結論を ADR に残したことで、以後の変更で同じ議論を繰り返さずに済んでいます。 影響範囲の大きい変更では、いきなりコードを書き始めず、まず仕様と設計上の懸念をコーディングエージェントに徹底的に洗い出させ、設計を固めてから実装に進むのも有効でした。2 台のロボットの座標系を統一する変更では、この段階で、誤った座標でも後述の安全制約を通過してしまう設計バグを実機に触れる前の机上で検出できています。 安全制約の先行実装 アームの進入を禁じる仮想壁、手先の向きを保つ姿勢拘束、関節角のリミットといった安全制約は、コーディングエージェントに考えさせる対象ではなく、人が最初に設計して実装しました。その上で、コーディングエージェントの作業範囲を 3 つに分けています。 変更できる: ROS 2 ノードの実装、説明ドキュメント 人の承認が要る: 座標系、校正値、プランナー設定、テストの変更、仮想壁や姿勢拘束など先行実装した安全制約の変更・無効化、開発ルール文書の禁則と完了条件の変更、実機での実行 コーディングエージェントの外で強制される: ロボットに標準搭載の接触停止機能、非常停止ボタンなどの物理 E-stop コーディングエージェントが必ず安全な変更をするとは限りません。先に制約を実装し、変更できる範囲と実行できる範囲を分けたため、その内側では思い切って任せられます。試行錯誤の速度と実機の安全は、この権限の分離で両立しました。 シミュレーションでの検証の必須化 実機を占有できる時間は限られます。個々の機能はコード上のテストで、動作計画はシミュレーター上での実行と RViz での目視で確認し、実機の時間は、グリッパーの把持力の加減や画像認識の精度といった、実物でしか確かめられない項目に充てました。 あわせて、軌道計算まわりの変更には、シミュレーター上での確認を検証ゲートとして毎回適用するのをチームのルールにしました。実機に触れる前に、シミュレーター上での実行が門番になる形です。 ただし、シミュレーター上の合格をそのまま信用はできません。シミュレーター上のロボットモデルは受け取った指令にそのまま応答するだけで、実機の条件の一部を省略しているからです。実際、ロボットに取り付けた周辺機器のケーブルやコネクターは、挙動のモデル化が難しく衝突判定に含めていませんでした。計画上は問題のない経路でも、実機ではこのコネクターがロボット自身の機体に当たりかけ、人が気づいて止める場面がありました。対処として、コネクターを覆う少し大きめの円柱を衝突判定のモデルに加え、計画の段階で自己干渉として避けるようにしています。シミュレーターが省略している条件は仕様に明記し、シミュレーター上で確認できる範囲と実機で確認すべき範囲を線引きしました。 安全要件の多層防護 開発中、動作計画が失敗し続けた際に、コーディングエージェントが原因を「手先を下向きに保つ」姿勢拘束だと誤判断し、一度無効化したことがあります。計画は通るようになりましたが、実機では障害物を持ったまま大回りして手先の向きが崩れる経路が選ばれてしまいました。原因は 2 つあり、別の変更で到達判定の許容誤差が厳しくなりすぎていたことと、姿勢を拘束した状態では既定の経路探索が解を見つけにくいことでした。許容誤差を直したうえで、探索アルゴリズムの変更や、失敗時に経由点を挿入する工夫によって、拘束を外さずに解決しています。「安全制約の先行実装」で述べた権限区分が、まだ固まっていなかった頃の出来事です。 トラブル対応では、コーディングエージェントも人も、早く解決するために制約を緩めがちです。だからこそ、安全要件は個々のプロンプトや作業指示に委ねず、層で守る形にしました。 動作計画上の制約: 仮想壁、姿勢拘束、関節角のリミット（「安全制約の先行実装」で人が先に実装したもの） ロボット側の保護機能: 接触停止機能、非常停止ボタンなどの物理 E-stop リポジトリの規約: 失敗の切り分け手段として拘束を外すことの禁止と、代わりに試す手順（規約自体の変更には人の承認が要ります） 検証: 実機に送る前の plan-only（実機へ送らず経路だけを計画）確認 この一件を機に、「禁止」と「代替手順」をセットで開発ルールに追記しました。禁止だけを書くと、行き詰まったコーディングエージェントや開発者は制約を回避しやすくなります。代替手順とセットで残すことで、次に同じ症状に出会っても、同じ近道を選ばずに済みます。なお、ここで挙げた拘束や仮想壁は動作計画上の制約であり、安全規格に基づく安全機能ではありません。接触停止や物理 E-stop の代わりにはならず、生産環境への適用では別途リスクアセスメントが必要です。 図 5: 姿勢拘束を維持しながら障害物を把持して退避させる動作 まとめ 今回の実装で重要だったのは、AI エージェントとコーディングエージェントに任せる範囲を広げることではなく、線を引くことと、検証することでした。AI エージェントには判断だけを任せ、動作は既存のロボット制御に。コーディングエージェントにはルールを文書で渡し、先に実装した安全制約の内側だけを任せる。そしてシミュレーター上での検証と起動時検証が、実機と本番を守ります。 同じ構成での検証は、実機がなくても今日から始められます。 ROS 2 と、その上で動く MoveIt 2 をセットアップする（いずれも公開されています。RADS を使うと、ROS 2 / MoveIt 2 / コーディングエージェント入りの環境を AWS 上にすぐ用意できます。実機をつなぐ段階で、ロボットのメーカー公式ドライバーやカメラのドライバーを加えます） コーディングエージェントに開発ルールの文書を渡し、シミュレーター上のロボットモデルで動作計画が解けるところまで作る AWS IoT Core でエッジとクラウドをつなぎ、Amazon Bedrock AgentCore 上の AI エージェントから動作の指令を受け取れるようにする（クラウド側の作りは Part 1 で紹介しています） 想定外への対応など、事前のルールでは書き切れない判断を含む業務（検査で不合格になった製品を、状態に応じて手直し・再検査・廃棄に振り分ける作業など）を一つ選び、判断を AI エージェントに、動作を既存制御に割り当てる クラウドに判断を置く構成は、この先に広がります。ロボットへの指令のインターフェースを揃えれば、判断の仕組みはそのままに、AI エージェントが扱うロボットの種類や台数を増やしていけます。生産管理や倉庫管理といった業務システムと連携した例外対応の仕組みも組めます。そしてコーディングエージェントが使う検証環境も、シミュレーターも、実機へのデプロイも、AWS の上で揃えられます。今回の開発で使った検証環境の仕組みは、 RADS として aws-samples で公開しています。 本記事が、お手元の産業用ロボットと AI エージェントを組み合わせる検討の出発点になれば幸いです。進め方や構成に迷う点があれば、ぜひ AWS にご相談ください。 関連リンク AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで Physical AI – AI エージェントが現実世界で「見て、考えて、動かす」自律オペレーションの実現 Remote AWS Development Station (RADS) 著者について 河田 武之（Takeyuki Kawata） 河田 武之（Takeyuki Kawata）は、製造業のお客様をご支援しているソリューションアーキテクトです。電機メーカーやロボットベンチャーでロボット開発に携わったのち AWS に入社し、現在も Physical AI の領域で、VLA モデルの学習からシミュレーション、実機検証まで自ら手を動かしています。 大前 遼（Ryo Omae） 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習やロボティクスで、最近は Physical AI に注力するあまり、部屋にロボットが溢れています。 西亀 真之（Saneyuki Nishigame） 西亀 真之（Saneyuki Nishigame）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。好きな領域は IoT とロボットで、Physical AI に注力しています。 原田 裕平（Yuhei Harada） 原田 裕平（Yuhei Harada）は、製薬業界のお客様を中心にご支援しているソリューションアーキテクトです。技術領域では Physical AI や AI for Science を軸に、最近は自律開発や自律実験など、AI の自律性をどこまで高められるかの実践に取り組んでいます。

本記事は、AWS Summit Japan 2026 で展示した Physical AI デモの開発の裏側を紹介する技術解説シリーズの Part 1（企画立案、ジオラマステージ制作、クラウド側アプリケーション開発）です。 Part 2 では ROS 2 + MoveIt 2 によるロボットアーム制御を解説します。デモのコンセプトとアーキテクチャは 事前紹介ブログ をご覧ください。 はじめに AWS Summit Japan 2026（2026年6月25日〜26日、幕張メッセ）の展示エリア「 AWS EXPO 」で、私たちは「Physical AI — AI エージェントが現実世界で『見て、考えて、動かす』自律オペレーション」と題したデモを展示しました。ミニチュアの街を舞台に、来場者が自由に配置した障害物を AI エージェントが自律的に発見・除去し、配送を復旧させるデモです。 ▲ 図1: 企画段階で画像生成 AI を使って作成したブースのコンセプトイメージ。ミニチュアの街をロボットアームと配達車両が動き回り、奥の 3 画面に「現実の障害」「AI エージェントの認識世界」「AI の思考」を映す構想。本番ブースはほぼこのイメージ通りに実現した Summit 開催前に公開した 事前紹介ブログ では、デモのコンセプトとシステムアーキテクチャの概要をお伝えしました。本シリーズでは、その開発の裏側——「どうやって作ったのか」に焦点を当てて振り返ります。 テーマは「 AI を活用した開発プロセス 」です。「AI がロボットを動かすデモ」を「AI を使って作る」。デモの中身だけでなく、デモを作る過程そのものでも AI をどう使い倒したかをお伝えします。この記事でわかることは次の 3 つです。 企画・設計・モデリング・実装・ドキュメントの 全フェーズで生成 AI をどう使ったか の具体例 ジオラマステージ制作の舞台裏—— 3 回の方向転換 と 3D プリントの試行錯誤から得た教訓 Kiro を使ったクラウドアプリケーション開発の実践ノウハウ（Design Doc を正とした Issue 駆動開発・Steering・Mob Construction） 開発タイムライン — 実質 1 ヶ月の統合戦 企画は 2026 年 2 月の初回ブレスト会議から始まり、4 月にはシナリオの大枠が決まりました。チームは 10 名、全員がふだんの業務と兼務です。そして 5 月 18 日に 麻布台オフィスへの移転 があり、実際のロボットを使った開発が本格化できたのは、新オフィスにロボット開発拠点を構えてからになります。 Summit 本番（6 月 25 日）まで約 1 ヶ月 です。この 1 ヶ月で、各コンポーネントの統合・連続運転テスト・ステージ制作・搬入準備のすべてをやり切る必要がありました。 ▲ 図2: 開発タイムライン（2026年2月〜6月）。オフィス移転から本番までの約 1 ヶ月が実機統合の期間だった（本図は生成 AI で作成） この短期決戦を可能にしたのが、次章で紹介する「生成 AI をあらゆるフェーズに組み込んだ開発プロセス」と、実機がなくても開発を止めない「Mock ファースト設計」（アプリケーション開発の章で後述）でした。 生成 AI をどこで使ったか — 全フェーズ一覧 本デモの開発では、企画から本番までのあらゆるフェーズで生成 AI を活用しました。全体像を 4 つのフェーズに分けて示します。気になる項目があれば、本文の該当章で詳しく紹介しています。 1. 企画・設計 コンセプトの可視化 — 画像生成 AI でイメージ画像（図1）を作り、言葉より先に世界観を共有 シナリオの壁打ち — 対話型 AI と案を出し合い「配送網の障害復旧」に絞り込み 寸法・制約の整理 — ステージや障害物のサイズ条件を AI と洗い出し、結合時のずれを防止 2. ステージ制作 3D モデリング — 建物や小物のモデルは、AI にスクリプトを書かせる方法で量産（Kiro + Blender） レイアウト設計 — 4 つの通りと建物の配置を AI と対話しながら検討 塗装の参考画像 — 街の色合いのリファレンスも Kiro + Blender で作成し、作業の方向性を統一 3. コーディング・テスト アプリ実装 — クラウド側アプリ一式を Kiro で実装 並行開発 — チーム間のインターフェース仕様を AI と先に固め、実機なしで同時開発 コード読解・テスト生成 — 既存コードの把握やテストケース作成を AI に任せて時短 4. ドキュメント FAQ・説明員資料 — 来場者からの想定質問と回答、デモの説明トークを AI と推敲 設計ドキュメント — 設計書の初稿を AI と共同執筆し、チームレビューで仕上げ ブログ執筆 — 事前紹介ブログや本記事の構成・草案づくりも AI と一緒に AI を使ったデモの企画立案 「配送網の障害復旧」コンセプトに至るまで デモの企画は「Physical AI で何を伝えたいか」の議論から始まりました。チームで議論を重ねて出した体験要件は次の 3 つです。 来場者が参加できる — 見るだけでなく触れる体験 AI の思考が見える — ブラックボックスではなく、判断過程を可視化 毎回違う結果になる — 決められた台本の再生ではなく、AI 自身の判断で動く 技術的な方向性としては、カメラ映像から直接ロボットの動きを生成する VLA（Vision-Language-Action）のような最先端のモデルではなく、 LLM（大規模言語モデル）による計画 + 実績ある従来のロボット制御 の組み合わせに絞り込みました。現時点で産業現場に適用可能な堅実なアプローチを示すことが、来場者にとっての持ち帰り価値になると判断したためです。 AI との壁打ちで磨いたデモシナリオ シナリオづくりの序盤は、AI を「発散」に使いました。製造・物流・建設・農業・小売といった産業別に「AI エージェント + ロボットが活きる障害対応シナリオ」を網羅的に挙げさせ、「ブースの広さで再現できるか」「1 サイクル 3〜4 分に収まるか」「来場者が介入できる余地があるか」の 3 つの物差しで評価していきます。人間だけのブレストでは案が数件で止まりがちですが、AI との壁打ちなら 1 時間で数十パターンの棚卸しができます。 最終的に「ラストワンマイル配送の障害復旧」を選んだ決め手は、次の 3 点です。 説明が要らない — 荷物が届く/届かないは誰でも知っている世界。専門知識ゼロで状況が伝わる 起承転結が短い — 「配送中 → 障害発生 → 調査・復旧 → 配送再開」が 3〜4 分で一周する 来場者が主役になれる — 障害物を「どこに置くか」は来場者の自由。毎回違う展開が生まれる 一方で「収束」はアナログでした。2026 年 4 月 21 日、会議室のホワイトボードの前にチームで集まり、AI と広げた案を物理的な制約に照らして刈り込んでいきました。配送ルートと障害ポイント、アーム 2 台の担当範囲といったデモフローの原型に加えて、「カメラは 2 台必要」「ハンドは 2 本指」というハードウェア構成の決定も、この日のホワイトボードから生まれています。発散は AI、意思決定は全員が同じ盤面を見られる対面で——この役割分担は、以降のフェーズでも繰り返し使いました。 ▲ 図3: 2026年4月21日のシナリオ検討ホワイトボード。FC（配送拠点）から目的地 A / B への配送ルート、障害物の発生ポイント、除去した障害物を運ぶ「ガレキ置場」、アーム A / B の担当範囲など、本番のデモフローの原型がすでに見えている 生成 AI による企画の可視化 企画の初期段階から、画像生成 AI でデモのイメージ画像を作成しました。冒頭の図 1 のような「ミニチュアの街 + ロボット + 配送車両」のビジュアルを言葉での説明より先に見せることで、社内の関係者・協力会社との認識合わせが一気に進みます。「よく分からないが面白そう」から「これならこう手伝える」へ。 絵が先、仕様が後 。これが少人数プロジェクトで多くの協力を引き出せた理由のひとつだと考えています。 ジオラマステージの設計と制作 木工ステージ — 市販合板 8 枚の「加工最小化」設計 まず土台となるステージです。設計の前提には、展示ならではの制約がありました。 オフィスの会議室で組み立てて動作検証し、 分解して幕張メッセへ搬入し、再度組み立てる 必要がある ロボットアームは可搬質量 20kg 級。 アームの荷重や反力をステージに載せるのは危険 制作は本職の大工ではなくチームメンバー。 加工の腕前に頼らない設計 にしたい この制約を AI と対話しながら整理し、たどり着いたのが「市販のサブロク合板（910 × 1,820mm）8 枚を ほぼ無加工で並べる 」という設計です。 方針 実現手段 加工最小化（市販品そのまま） 合板 8 枚のうち、切り抜き加工が必要なのは 4 枚のみ。総加工時間は 約 60 分 組立・分解・再組立できる 骨組みの棒材はすべて 910mm 以下・全ボルト接合。合板はオフィスのドアを通過できるサイズ ロボット荷重は受けない アーム 2 台は専用の台座で床に自立。ステージ側は開口部でアームを避け、構造的に独立 ▲ 表1: ステージ設計の 3 本柱 ▲ 図4: ステージ上面図（設計書より）。合板 8 枚（2 列 × 4 列）で 3,640mm 四方を構成し、ロボットの台座が入る開口部を 2 箇所確保。左右 2 ユニットに分離でき、搬送時はユニット単位で運べる ▲ 図5: 分解図。2×4 材の格子フレームに合板を載せてボルト・金物で固定する。全部材が 910mm 以下なので、エレベーターと会議室のドアを通り、再組立は約 1 時間 天板高さは 765mm。アーム台座の上面（795mm）とジオラマ表面がほぼ同じ高さになるよう、柱底のアジャスターボルトで ±30mm 調整できるようにしています。アームがミニチュアの街から「生えている」ように見えるのはこの高さ合わせのおかげです。精度が必要な箇所（ロボット周辺の高さ、走行路の白線）と、多少ずれても問題ない箇所（外装、建物の配置）を最初に区別しておいたことで、統合時の現物合わせを最小限にできました。 ▲ 図6: オフィスの会議室で組み上げたステージ（2026年5月末）。ロボットアーム 2 台は専用台座（レオンアルミ製）で床に自立し、ステージの開口部から「生えて」いる。荷重と動作反力はステージに一切伝わらない ミニチュアの街 — コンセプトは 3 回変わった ステージの上に載る「街」のほうは、木工のように一直線には進みませんでした。企画から完成までの約 6.5 週間の間に、コンセプトレベルの方向転換を 3 回経験しています。 ▲ 図7: ミニチュアの街 — コンセプトの変遷（2026年5月〜6月）。「配送拠点から住宅街へ届ける」というデモの文脈が一目で伝わる構成が最後の決め手になった（本図は生成 AI で作成） 特に案 2 は、公開されている 3D 都市モデルから建物の形状データを取り出して 1/200 スケールで印刷する工程まで確立していたのですが、実在の建物を商業イベントで展示することの権利面の確認に時間がかかると分かったことに加え、街のすべてを 3D プリントで作ると工数・コスト・時間が見合わないという判断もあり、約 1 週間分の作り込みごと手放しました。案 3 も机上の比較では最有力だったものの、試作と配置検証を重ねるうちに、「配送拠点から住宅街へ荷物を届ける」というデモの文脈が直感的に伝わる 機能別 4 エリア構成 へ自然に置き換わっていきました。紙の上の評価はプロトタイプ 1 回でひっくり返る——方向転換 3 回は迷走ではなく、検証が機能していた証だと捉えています。 3D プリンタによるミニチュア制作 — AI アシストの実際 街のミニチュア（建物・車・木・信号機・道路サイン）は、有志メンバーが家庭用 3D プリンタで分担製作しました。3D モデリングソフト（Blender）はほぼ全員が未経験でしたが、モデルを手で作る代わりに 「モデルを生成するスクリプト」を AI に書かせる 方法で量産しています。「サイズと意図を日本語で伝える → AI がスクリプトを生成 → 実行して形を確認 → 直してほしい点を指示」というループです。 下の図は、実際に本番ステージを構成した 4 エリアの建物モデルです。この記事のために、当時の制作データをそのままレンダリングしました。トラックドックを備えた配送拠点から、のこぎり屋根の工場、住宅と公園、高層ビルが並ぶオフィス街まで、すべて AI が生成したスクリプトから生まれています。 ▲ 図8: 本番ステージを構成した 4 エリアの 3D モデル（AI が生成したスクリプトによる制作データを、本記事用にレンダリング）。左上: FC（配送拠点）、右上: 工場エリア、左下: 住宅街 + 公園、右下: オフィス街 もうひとつ、小物の例として道路名プレートも紹介します。4 つの通りの名前を彫り込んだ三角柱のプレートです。一見シンプルですが、最初のバージョンは文字の彫りが深すぎて裏面まで貫通してしまい、彫りの深さと壁の厚みをスクリプトで管理する方式に改めて作り直しました。 ▲ 図9: 道路名プレートの 3D モデル（AI が生成したスクリプトによる制作データを、本記事用にレンダリング）。シンプルな見た目に反して「文字の彫り込み」は失敗の多い難所だった 「型抜き」で形が壊れる — モデリング最大の難所と乗り越え方 モデリングで最も苦しんだのが、窓やドアの作成です。3D モデルでは、壁のかたまりから窓の形を 「型抜き」 して作ります（Blender では Boolean 演算と呼ばれる処理）。ところがこの型抜きは繊細で、条件が悪いと抜きたい場所以外が消えたり、モデル全体が崩れたりします。数十回の失敗から得た教訓は、次の 3 つに集約できます。 一度に大きく抜かない — 型抜きは回数と範囲を小さく分けるほど壊れにくい 細かい部品は避難させる — 屋上設備などの小さな部品は一度外し、型抜き後に戻す 抜き型は最小限の深さに — 壁を突き抜ける深さで抜くと、反対側の面まで消えてしまう この試行錯誤も AI との二人三脚でした。壊れたモデルのスクリーンショットとスクリプトを AI に渡して原因の見当をつけさせ、対策を反映したスクリプトを再生成する。人間は「どれが正しく印刷できる形か」の判断に集中する。この分業により、モデリング未経験のチームでも約 6 週間で建物・小物あわせて数十パーツを完成させました。 対象 経緯 作り直し FC（配送拠点） 初版 → 改良版 → 最終版とファイル名の世代が進んだ 3 回 道路名プレート 彫りの貫通事故を経て、彫り深さ管理方式で再作成 2 回 工場 スケール拡大 → のこぎり屋根化 → 印刷用の分割 3 段階 ▲ 表2: 主要パーツの作り直しの記録。一発では決まらない前提で、作り直しやすい仕組み（スクリプト生成）にしておいたことが効いた 走行路の設計 — 配達車両が迷わない道 配達車両（TurtleBot3 Burger という小型の自律走行ロボット）は、カメラではなく赤外線センサーで路面の白線をたどって走ります。派手さのない仕組みですが、2 日間確実に動き続けることを最優先にした選択です。道路側の設計要素は次の 3 つです。 白線 — 幅 30mm。黒地マット仕上げの道路面に敷き、センサーが検知する明暗差を最大化 停止線 — 3 つのセンサーが同時に白を検知する横断ラインで、配送先・積荷ポイントを識別 障害物検知 — 前方のセンサーが障害物を検知すると停止し、クラウドの AI エージェントに通知 ▲ 図10: 走行路シートを敷いた状態（会議室での検証時）。白線・停止線・コーナーの曲率は、この面材に印刷して敷くだけで再現できる。ステージ 8 分割に合わせてシートも分割されている 道路幅は 250mm（車体幅 178mm + 左右の余裕 36mm）、コーナーは半径 200mm。この数値も机上で決めた後、実走で「曲がりきれるか」「白線を見失わないか」を検証して確定しています。障害物を検知した車両が停止する——この瞬間こそが、事前紹介ブログで紹介した AI エージェントの自律調査フローが動き出すトリガーです。 アプリケーション開発 — Kiro との二人三脚 システムアーキテクチャ — 3 レイヤー構成のおさらい 事前紹介ブログ で解説したアーキテクチャを、実装の観点から一枚に整理します。設計原則は次の 3 つです。 知性はクラウド — 状況判断・計画立案は LLM の推論力を活かしてクラウドで実行 動作はエッジ — ロボットの動作計算やセンサー処理は、現場に置いた PC（エッジ）で実行 通信断耐性 — クラウドとの通信が切れてもアームは安全停止し、復旧後に再開 ▲ 図11: 3 レイヤー構成 — 知性はクラウド、動作はエッジ。AWS IoT Core がクラウドとエッジを安全につなぐ（本図は生成 AI で作成） Kiro を使ったアプリケーション開発の実際 クラウド側の AI アプリケーション（インフラ、AI エージェント、ダッシュボード画面）は、AI エージェント型 IDE の Kiro を使って実装しました。単に「コードを書かせた」のではなく、開発プロセスの型として活用したのがポイントです。 Design Doc を正とした Issue 駆動開発 — 「仕様が先、コードが後」を AI と徹底する 「仕様を固めてから実装に入る」という進め方は守りつつ、要件・設計・タスクを形式的に分けて管理するのではなく、 チームで共有していた Design Doc を唯一の「正」とする 運用にしました。実装したい機能が出てきたら、Design Doc に沿った実装計画を GitLab の Issue に書き出し、Issue 単位で実装を進めます。Coding Agent には GitLab の CLI ツール経由で GitLab を操作させ、Issue の参照から実装までを一連の流れとして回しました。 効果が大きかったのは 並行開発 です。アームロボットチーム・TurtleBot チーム・フロントエンドチーム・バックエンドチームの 4 チーム間の結合点は、通信メッセージの仕様として Design Doc に固定されているため、実機がなくても各チームが同時に走れます。アプリケーションの内部でも、担当者同士が干渉しないように領域を分けた担当分けを最初に設計し、お互いの作業を邪魔せず並行開発できるようにしました。仕様の議論は Design Doc に、個々の実装計画は Issue に残るので、「なぜこの仕様なのか」を後から追跡でき、キャッチアップも速くなりました。 Steering — プロジェクトの「暗黙知」を明文化してブレを防ぐ Kiro の Steering（プロジェクト固有のルールを Markdown で記述し、AI が常に参照する仕組み）には、次のようなルールを書き込みました。 通信メッセージの型定義ルールと命名規約 インフラ資源（AWS CDK で管理）の命名規約と分割方針 複数人が同じコードベースで AI にコードを書かせると、通常は書き手ごとの流儀が混ざって崩れていきます。Steering に規約を集約したことで、「誰が Kiro に書かせても同じ流儀のコードが出てくる」状態を維持できました。 Mob Construction — 3 日間 109 コミットの裏側 統合フェーズの山場では、チームで同じ部屋に集まり、その場で仕様を決めながら Coding Agent を回し続ける「Mob Construction」と呼ぶ進め方をとりました。ホワイトボードで仕様を合意 → その場で Kiro に実装させる → 実機つなぎ込みで検証 → 次の仕様へ。この高速ループで 3 日間 109 コミット （コードの変更履歴 109 件）を積み上げています。人間がキーボードを打つ時間ではなく、意思決定の速度が開発速度を決める体験でした。 デバッグでも AI が活躍しています。エージェントとロボットがお互いの応答を待ち続けて処理が止まる問題では、Kiro にコード全体を読ませて待ち合わせが衝突しうる箇所を列挙させ、原因を特定。また、エージェントの判断が不安定だった時期には、AI への指示文の中の曖昧な表現（「適切に」「必要に応じて」など）を AI 自身に洗い出させて具体的な条件に書き換え、判断のブレを抑えました。 実機がなくても開発は止めない — Mock ファースト ロボット実機に触れる時間は本番前の約 1 ヶ月だけ。そこで、ロボットと同じインターフェースで応答する疑似デバイス（Mock）を AWS Lambda で実装し、クラウド側はデモシナリオ全体を実機なしで回せるようにしました。あわせてデモ当日の調整パラメータ（タイムアウト、リトライ回数、走行速度など）を AWS Systems Manager Parameter Store に外出しし、プログラムを配布し直さずに現地チューニングできる構成に。本番 2 日間の運用でこの仕込みが効きました。 使用した主なサービス・フレームワーク コンポーネント 技術スタック AI エージェント実行基盤 Amazon Bedrock AgentCore Runtime エージェント SDK Strands Agents SDK （Python） 推論モデル Claude Sonnet 4.6（計画・判断） / Claude Haiku 4.5（画像認識） インフラ AWS CDK （TypeScript）— 60 以上のリソースを一括デプロイ フロントエンド React + Cloudscape Design System + Vite 通信 AWS IoT Core （MQTT 5 + Device Shadow） 音声 Amazon Polly ▲ 表3: クラウドアプリケーションの技術スタック ▲ 図12: 本番デモより。AI エージェントの指示を受けたロボットアームが障害物をつかみ、回収エリアへ移動させて道路を開通させる。このアーム制御の実装は Part 2 で詳しく解説する まとめ 約 5 ヶ月間で「AI エージェントが現実世界で自律的に問題を解決する」デモを作り上げました。振り返って強調したいのは次の 3 点です。 生成 AI は「作る対象」であり「作る道具」だった — 企画の可視化、シナリオの壁打ち、3D モデリング、コーディング、ドキュメントまで、AI を全フェーズに組み込むことで、少人数・兼務・実質統合 1 ヶ月という条件でも本番に間に合わせることができました。 方向転換を恐れない — ミニチュアの街はコンセプトが 3 回変わりました。早く作って早く見る。紙上の評価より実物の説得力です。 プロセスの型が品質を守る — Design Doc と Issue で仕様と結合点を固定し、Steering で規約を明文化し、Mock で実機依存を断つ。AI に書かせる開発だからこそ、人間は「型の設計」に力を注ぐ価値があります。 Part 2（ロボット開発編） では、ROS 2 + MoveIt 2 によるアーム制御、クラウド連携、マーカーを使った精密な位置合わせ、つかむ動作の実装について詳しく解説します。クラウドの「判断」が物理世界の「動作」に変わる瞬間の作り込みを、ぜひご覧ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野 貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 8月26日に AWS と NVIDIA が戦略的協業の大幅な拡大を発表 しました。2027 年から 2028 年にかけて NVIDIA GPU を新たに 200 万基 AWS のグローバルインフラに追加配備する計画で、エージェント型 AI ワークロード向けの NVIDIA Vera CPU の AWS への導入も進められます。16 年にわたる両社の協業がフルスタックへと広がっていく動きで、お客様のワークロードに合わせて NVIDIA GPU と AWS Trainium を自由に選べる環境がさらに強化されていきそうです。気になる方はニュースリリースをチェックしてみてください。 それでは 8月 24日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社 Sapeet がプロダクトの成長に合わせて生成 AI 基盤をコードベースへ ― Dify で築いた資産を活かし、Amazon Bedrock AgentCore と Strands Agents SDK への移行を 2 週間で実現 」 ノーコード AI プラットフォームの Dify で立ち上げた監査業務向けの生成 AI 環境分析ツールを、プロダクトの成長に合わせて Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースのアーキテクチャへ移行した事例です。Dify のブロック繋ぎ型ワークフローと Strands Agents SDK のノードベース実行が構造的に類似する「ノード親和性」により、約 1 年間かけて磨き上げたワークフローの設計思想をそのまま移行資産として活かし、実質 2 週間で基盤移行を完了しました。移行後は Git ベースの差分管理とプルリクエストベースのコードレビューフローが確立され、AWS CDK の L2 Construct によりインフラを含めた一元管理を実現しています。 AWS生成AI国内事例ブログ「 株式会社 JAPANNEXT 様の AWS 生成 AI 事例「Amazon Connect と Amazon Bedrock で営業業務とカスタマーサポート業務を刷新。対応件数を 15% 増加、引き継ぎ工数ゼロを実現」のご紹介 」 液晶ディスプレイメーカーの JAPANNEXT 様が、クラウド型コンタクトセンターサービスの Amazon Connect Customer と Amazon Bedrock を活用し、営業とカスタマーサポートの電話対応業務を刷新した事例です。通話の文字起こしと Amazon Bedrock によるカスタマイズされた要約を組み合わせ、AWS Lambda で担当者が日常的に使うチャットツールへ終話後数分で連携する仕組みを構築しました。先行して運用を開始した営業部門では、1 日の電話対応件数が 15% 増加し、自動ルーティング機能により担当者への電話引き継ぎに要していた時間がゼロになったほか、担当者の残業時間も 15% 削減されています。 イベントレポート「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 札幌編（#7/8）開催レポート 」 2026 年 4 月から 5 月にかけて全国 5 拠点・計 8 回で開催された「AWS Local Executive Roadshow」の第 7 回、札幌開催のレポートです。事例セッションでは、クラスメソッド株式会社が開発した、個人の知見・思考パターン・判断基準をインタビューと分析を通じて AI エージェントとして再現するデジタルツインサービス「ghoost」と、北海道文化放送株式会社（UHB）が視聴率分析などで生じていたナレッジの属人化の解決に向けて取り組んだ PoC が紹介されました。クラスメソッドでの早期検証では、生成された ghoost の回答の 92.3% が「本人らしい」と第三者に評価されています。検証前に撤退基準を設け、ROI の見える化と本人らしさの二軸で評価する UHB 様の進め方など、導入判断の実践的な知見が語られています。 イベントレポート「 AI ツールで実現する継続収益ビジネス​ 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 札幌編（#8/8）開催レポート 」 同シリーズ最終回となる第 8 回、札幌での IT 企業向け開催のレポートです。株式会社アドウイック様は、5 名の少人数チームで複数のコーディングエージェントを比較検証して Cursor を採用し、取り組み開始からの 1 年でファイル送受信サービス、名刺管理アプリ、議事録作成アプリという 3 つのサービスをゼロから開発しました。名刺管理アプリでは、従来の OCR サービスから Amazon Bedrock 上の Claude による文字認識に切り替えたことで、縦書きも横書きも問題なく読み取れるほど精度が向上しています。「低い点数でもいいのでまず試してみる」「小さく始める」「メンバーを巻き込む」という 3 つの考え方のもと、小さな成功体験の積み重ねが、AWS 資格の取得数がメンバー全体で 1 年に 20 個近くにのぼるといった組織の変化につながった様子が語られています。 ブログ記事「 Amazon Quick と Snowflake Cortex AI によるマネーロンダリング対策のアラートトリアージの自動化 」 金融サービスで最も労働集約的なワークフローの 1 つであるマネーロンダリング対策（AML）のアラートトリアージを、Amazon Quick Flows と Snowflake Cortex を Amazon Quick の MCP（Model Context Protocol）統合で接続して自動化する手順を解説しています。アナリストがアラート ID を入力すると、フローが Snowflake Cortex Agent を呼び出して取引データやコンプライアンス文書を横断的に調査し、リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを生成します。テスト環境では、アラート調査に要する時間が 30〜90 分から 5 分未満に短縮されました（実際の結果はアラートの複雑さやデータ量によって異なる場合があります）。プロンプトの表現によって出力が変動するチャットエージェントと異なり、誰が実行しても同じ構造化されたステップをたどるため、監査対応可能な一貫した調査ブリーフが得られる点もポイントです。 ブログ記事「 パート2: Amazon AthenaとCUDOSを使用したAmazon Bedrockのコスト配分 」 Amazon Bedrock のきめ細かなコスト配分機能で得られる IAM プリンシパル別のコストデータを、Amazon Athena と CUDOS ダッシュボードで可視化・分析する方法を解説する記事です。IAM プリンシパルデータを含む CUR 2.0（Cost and Usage Report）データエクスポートの設定から、Athena による SQL クエリパターン、CUDOS ダッシュボード バージョン 5.8 の AI/ML タブに追加された Amazon Bedrock セクションまでを段階的に紹介しています。ユーザー別・使用タイプ別のコスト分解や、IAM プリンシパルタグによるチーム・プロジェクト別の集計、100 万トークンあたりのコストのトレンド追跡ができ、「誰がどのモデルを呼び出していて、いくら使っているか」という質問に答えられるようになります。（ パート1はこちら ） ブログ記事「 Amazon Bedrock のきめ細かなコスト配分の導入 」 Amazon Bedrock が、推論コストを API コールを実行した IAM プリンシパル（IAM ユーザー、アプリケーションが引き受けたロール、フェデレーテッド ID）に自動的に紐付けるようになりました。CUR 2.0 のデータエクスポートで IAM プリンシパルデータを有効にすると、line_item_iam_principal 列でユーザーごと・アプリケーションごとの支出を確認でき、オプションのコスト配分タグを使えば AWS Cost Explorer や CUR 2.0 でチーム別・プロジェクト別に集計することもできます。記事では、IAM ユーザーや API キーを使う開発者、IAM ロールを使うアプリケーション、フェデレーテッド認証、LLM ゲートウェイという 4 つのアクセスパターン別にセットアップ方法を解説しています。本機能は追加費用なしで商用リージョンで利用できます。 ブログ記事「 ラップトップを閉じても、エージェントは動き続ける。cloud sessions で開発する 」 Kiro がリリースした cloud sessions（プレビュー）は、AI エージェントをローカルマシンではなくクラウドのサンドボックス上で実行する機能です。エージェントがリポジトリをクローンして作業を進めるため、ラップトップを閉じても処理は継続し、CLI・IDE・ブラウザーのどれからでも同じセッションの進捗確認と再開ができます。記事では、既存の EC アプリに決済 API を追加するタスクを題材に、CLI から --cloud フラグでセッションを起動し、音声入力機能 /voice でプロンプトを伝え、Kiro Web で進捗を確認して IDE で成果物をレビューするまでの一連の流れを紹介しています。Cloud Sessions は米国東部（バージニア北部）の us-east-1 リージョンでのみ利用できます。 ブログ記事「 継続的なプロンプト評価: LLM ジャッジとライブシグナルを使って Kiro エージェントの品質を高める方法 」 Kiro の開発チームが、システムプロンプトの変更を LLM ジャッジと実際の利用データで継続的に評価している仕組みを解説した記事です。診断・設計・テスト・評価の 4 ステージからなるサイクルを回し、社内の会話をタスクの完遂度や主張の正確性など 15 の挙動ディメンションでスコアリングして、プロンプト変更の効果を A/B 実験で検証します。社内の実験レベルの比較では、Kiro IDE で挙動品質の問題が 20% 減少、コードスタイルの不一致が 54% 減少するなどの結果が観測されました。同じプロンプト変更でも効果はモデルに依存するため、モデルアップグレードのたびに再検証が必要になるという知見も共有されています。 ブログ記事「 本番インシデントのトリアージを AI エージェントに任せられるようになるまで 」 Kiro のデータプレーンを運用するチームが、本番チケットキューのトリアージを Kiro CLI 上で動く AI エージェントに任せられるようになるまでの道のりを紹介しています。システムは専用のオーケストレーションフレームワークやファインチューニングしたモデルを使わず、Kiro CLI と markdown のステアリングファイル、MCP（Model Context Protocol）サーバー、スキルで構成されています。ある日曜日の深夜に発報したアラームでは、13 分 35 秒後には根拠のある診断がチケットに投稿されており、オンコールエンジニアの仕事は調査を始めることから、完了した調査をレビューして意思決定することへと変わりました。代表的な 1 か月では約 250 件の調査が無人で、中央値 13.6 分で完了しています。ドキュメントのバグをエージェントがマシンの速度で受け継いでしまうといった失敗談も含めて共有されています。 ブログ記事「 AI コーディングエージェントは本当に良くなっているのか？ 」 Kiro IDE の diagnostics ツール（エージェントがコードを書いたり変更したりした際に静的解析器で出力をチェックする仕組み）の呼び出しデータ約 40.6 万件を、2026 年 1 月から 6 月までの 6 か月間・7 つの Claude モデルにわたって分析した記事です。ファイルあたりのエラー数は両モデルファミリーとも最新版で約 1.2 に収束して低下傾向にある一方、エラーの構成は変化しており、解決できない import が全エラーの約 30〜58% を占めること、テストコードは実装コードより正しく書くのが 3〜4 倍難しいように見えること、言語別では Java のファイルエラー率（26.7%）が Python（4.0%）の 6.7 倍にのぼることなどが明らかになっています。 サービスアップデート OpenAI GPT-5.6 Terra および Luna が AWS GovCloud (US) の Amazon Bedrock で利用可能に OpenAI の GPT-5.6 Terra と Luna が、AWS GovCloud (US-West) および AWS GovCloud (US-East) の Amazon Bedrock で一般提供を開始しました。バランスの取れた性能の Terra と、高速でコスト効率の高い推論の Luna という 2 つの能力ティアをカバーし、Terra は GPT-5.5 レベルの性能を半分のコストで提供します。両モデルとも 100 万トークンのコンテキストウィンドウをサポートするため、コードベース全体や長大なドキュメントを 1 回のリクエストで処理できます。明示的なキャッシュブレークポイントによるプロンプトキャッシュにも対応しており、繰り返し利用されるコンテキストは 90% 割引で課金されます。 SpaceXAI Grok 4.6 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock が、コーディング・エージェントタスク・ナレッジワーク向けに構築されたフロンティアモデルである SpaceXAI Grok 4.6 をサポートしました。500K のコンテキストウィンドウと、4 段階（low / medium / high / xhigh）で設定可能な推論エフォートを備えています。 bedrock-runtime エンドポイントで Responses、Chat Completions、Converse の各 API をサポートし、両方の AWS GovCloud (US) リージョンにまたがるクロスリージョン推論により大規模に利用できます。AWS GovCloud (US-East) では bedrock-mantle エンドポイント経由でも利用可能です。 Amazon Bedrock AgentCore Memory がきめ細かなアクセス制御をサポート Amazon Bedrock AgentCore Memory が、きめ細かなアクセス制御（FGAC）をサポートしました。カスタムの認可ロジックを構築することなく、AgentCore Gateway を通じてユーザー単位・テナント単位のメモリ分離を実現できます。OAuth（JWT）認証を構成した AgentCore Gateway を Memory リソースの前段に配置し、Cedar ポリシーをアタッチすることで、認証された呼び出し元のアイデンティティに基づくアクセス制限が可能になり、アクセス制御の実施をアプリケーションコードからインフラレイヤーに移せます。 Amazon Bedrock AgentCore Memory が柔軟な名前空間変数をサポート Amazon Bedrock AgentCore Memory で、柔軟な名前空間変数を定義できるようになりました。組織・テナント・チーム・環境といったアプリケーション固有のディメンションで長期メモリをスコープでき、メモリ戦略（会話から抽出する情報の種類を決める設定）の重複作成や組み込み変数の使い回しが不要になります。メモリリソースにキーを定義し、メモリ戦略の名前空間テンプレートで参照して、実行時に CreateEvent API で値を渡す仕組みで、メモリリソースあたり最大 5 つのキーを定義できます。AgentCore Memory が一般提供されているすべての AWS リージョンで、追加料金なしで利用できます。 Amazon Bedrock AgentCore が新たに 2 つのリージョンに拡大 AI エージェントの構築・接続・最適化のためのプラットフォームである Amazon Bedrock AgentCore が、米国西部（北カリフォルニア）リージョンとアジアパシフィック（ハイデラバード）リージョンで新たに利用可能になりました。エージェントランタイム、アイデンティティとアクセス制御、ポリシー管理、セッション永続化、ツール接続、評価、可観測性といった AgentCore の機能を提供開始時点から利用でき、これらのリージョンの顧客はエンドユーザーにより近い場所で低レイテンシーにエージェントを構築・実行できます。 Amazon SageMaker HyperPod が Ray のサポートを強化 Amazon SageMaker HyperPod が、AI ワークロードをスケールさせる人気のオープンソースフレームワーク Ray のサポートを強化しました。Amazon SageMaker Studio の Web ベースのインターフェイスから Ray クラスターを作成・管理し、JupyterLab や Code Editor、ローカル IDE を実行中のクラスターに接続して対話的に開発できます。可観測性では Grafana ダッシュボードのプロビジョニングと Ray Dashboard へのワンクリックアクセスが提供され、大規模学習ではノード自動復旧・ハングジョブ検知・階層化チェックポイントが長時間の学習を障害から守ります。Ray Serve による推論では、階層化された KV キャッシュが最初のトークンまでの時間を短縮します。Amazon EKS でオーケストレーションされる HyperPod クラスターを対象に、SageMaker HyperPod がサポートされる AWS リージョンで利用できます。 SageMaker MLflow がカスタマーマネージドキーをサポート SageMaker MLflow が、AWS Key Management Service（KMS）のカスタマーマネージドキー（CMK）によるデータの暗号化に対応しました。厳格なセキュリティ・コンプライアンス要件を持つ組織が自らの暗号化キーを管理できるようになり、AWS CloudTrail との統合によりデータアクセスをトレースする監査も可能です。キーは MLflow App と同じ AWS アカウント・リージョンで作成する必要があり、対称 KMS キーのみがサポートされます。MLflow App が利用できるすべての AWS リージョンで一般提供されています。 Muse-Glimmer-30B および Qwen 3.8-27B モデルが Amazon SageMaker JumpStart で利用可能に Meta の Muse-Glimmer-30B と Alibaba の Qwen 3.8-27B が Amazon SageMaker JumpStart で利用可能になりました。Muse-Glimmer-30B は、複数ステップの推論・ツール利用・失敗からの回復を備えた自律的なエージェントタスク向けに設計された 30B パラメータの密モデルで、131K 超のコンテキストウィンドウと選択可能な推論強度（low〜extra-high）を持ち、Apache 2.0 ライセンスで公開されています。Qwen 3.8-27B は、コーディング・複数ステップのエージェントタスク・テキスト/画像/動画にわたるマルチモーダル理解に優れた 27B パラメータのネイティブなビジョン言語モデルで、262K のコンテキストウィンドウ（YaRN スケーリングで約 1M まで拡張可能）を備え、SWE-bench Pro で 61.7 のスコアを記録しています。 Cosmos3-Edge、Cosmos3-Nano、Cosmos3-Super モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA の Cosmos3-Edge、Cosmos3-Nano、Cosmos3-Super が Amazon SageMaker JumpStart で利用可能になりました。3 つのモデルは、フィジカル AI（物理世界を知覚・推論・計画・行動する AI）向けのオープンなオムニモーダル世界モデル「Cosmos 3」ファミリーを構成し、ロボット・自律走行車・ビジョン AI の構築に活用できます。Cosmos3-Edge はエッジハードウェア上でのオンデバイスのロボット制御とリアルタイムの視覚推論向けの 4B パラメータモデル、Cosmos3-Nano は物理法則の理解を踏まえた世界生成と物理推論に優れる 16B パラメータモデル、Cosmos3-Super はファミリー内で最高精度の世界生成・シミュレーションを担う 64B パラメータモデルです。 Kiro CLI : フルスクリーンのスペックタスク実行とスクロールバックの保持 Kiro CLI の本リリースでは、V3 のスペック実行に、リアルタイムの進捗表示とタスクスコープ選択を備えたフルスクリーンのタスク実行ビューが追加されました。 /spec run でスペックを実行すると専用のフルスクリーンビューが開き、実行開始前にタスクの範囲を選択して、進捗をリアルタイムに追跡できます。また、新しい「Preserve scrollback」トグルを有効にすると、画面のオーバーフローやリサイズによる再描画が発生してもターミナルの履歴が保持されます。 Kiro IDE : サードパーティ拡張機能との互換性と、より信頼性の高い MCP サインイン Kiro IDE の本バージョンでは、サードパーティ製の拡張機能を Kiro と併用できるようになりました。あわせて、最新の MCP（Model Context Protocol）プロトコルリビジョンのサポートによりサインインの信頼性が向上したほか、大きなエージェントレスポンスの処理中に発生していた拡張機能ホストのクラッシュが減少し、ネットワークが一時的に切断されてもエージェントのターンが継続されるようになっています。 生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

2026 年 8 月 31 日、AWS ジャパンは「フィジカル AI 開発支援プログラム by AWS ジャパン」の最終成果発表会を AWS 麻布台ヒルズオフィスで開催しました。 1 月 27 日に発表 し、 51 社 ( うち半数以上がスタートアップ ) を採択、 3 月 3 日のキックオフ から約 6 ヶ月支援してきました。 6 ヶ月をふりかえって プログラムでは、フィジカル AI 領域スペシャリストによる技術支援、コスト最適化支援、ロボティクス・生成 AI コミュニティ形成、Go-To-Market 支援の 4 つの柱で参画企業への支援を行いました。アマゾングループが世界 300 以上の施設で約 100 万台のロボットを運用してきた経験も、この 4 つの柱の設計に反映しています。 技術支援の中心は、アカウント担当とスペシャリスト Solutions Architect (SA) チームによる個別の伴走です。週次の定例を設けたり、開発の現場まで伺った企業もありました。あわせて Prototyping & AI Customer Engineering (PACE) チームによるプロトタイピング支援やサンプルコード Physical AI Scaffolding Kit (PASK) の公開、 生成 AI イノベーションセンター (GenAIIC) による支援も進めています。 コスト最適化の面では、開発の初期段階での試行錯誤がしやすいよう総額 600 万 US ドル規模の AWS クレジットをご用意しました。 コミュニティ形成では、 Physical AI on AWS のアーキテクチャ や NVIDIA Robotics Solutions 、グローバルトレンドとロボットに関する勉強会と、 コミュニティミートアップ を開催しました。 Go-to-market の面では、AWS Summit Japan 2026 でのデモ展示など、採択企業の露出と連携の機会づくりを行いました。参加企業からは、AWS 経由で紹介した顧客との商談につながったという声もいただいています。 以下では、8 月 31 日最終成果発表会について、第一部 (記者向け成果発表会)・第二部 (参加企業向け成果発表会) にわけて紹介します。 記者向け成果発表会 冒頭、AWS ジャパン 代表執行役員社長の白幡 晶彦が登壇し、プログラムを総括しました。 AWS ジャパンは、日本への投資を「技術」「信頼性」「人と社会」の 3 本柱で進めており、本プログラムはその 1 つ目である技術への投資の中核にあたります。今年 1 月には「日本のために、社会のために、その先へ」という目標を掲げました。日本はロボティクスで世界をリードしてきており、ハードウェア設計、精密制御、製造技術には数十年の蓄積があります。この強みに生成 AI を掛け合わせることが日本にとって最大の機会であり、世界に対する最大の競争力になる。この領域は日本政府も重要施策のひとつとして位置づけており、AWS はクラウドでフィジカル AI の実用化を支えていると話しました。 そのうえで、フィジカル AI による日本の社会課題解決に不可欠な要素を 3 つ挙げました。1 つ目はスピードです。採択した 51 社のうち半数以上がスタートアップで、完璧な計画を立ててから動くのではなく、仮説を立てて試し、学んで改善するサイクルを高速に回す機動力が社会実装を牽引しています。ハードウェアの開発から手がける企業も複数ありました。2 つ目は現場の力です。テクノロジーだけでは現場で役に立つロボットは生まれません。物流や建設、製造の現場で数十年にわたり蓄積されてきた知見とデータ、そしてスケールが、スタートアップの機動力と組み合わさることで一気に前へ進みます。3 つ目はクラウドです。基盤モデルの学習、大量のデータの収集と前処理、何百通りものシミュレーションを並列で走らせることをオンプレミスだけで行うのは、時間もコストも現実的ではありません。必要なときに必要な規模の計算資源を確保できることは、フィジカル AI の開発において選択肢のひとつではなく不可欠である、と述べました。 最後に「日本発のフィジカル AI イノベーションが、ここから生まれることを期待しています」と締めました。 各社の取り組み 13 プロジェクト・14 社が成果を発表しました。以下社名 敬称略、五十音順。文中の専門用語と固有名は末尾の注釈にまとめています。 株式会社アトム — 日本発のヒューマノイドメーカーを目指すスタートアップです。歩行と全身の制御をシミュレーター※1 の上で学習させ、実機で通常歩行と早歩きを確認しました。あわせて、人が遠隔操作した動きを記録し、そのデータから研究開発用途の自社モデル※2 を学習させて、荷物の仕分け作業などで一定の精度に到達。人の視点で撮影した映像のみを用いる学習は難航しましたが、遠隔操作のデータに加えることで学習が進むことを確認し、現在その精度を検証しています。8 月 28 日には物流作業を対象に 24 時間の連続稼働デモを実施しました。AWS は計算リソースの計画と提供、フィジカル AI チームとの技術ディスカッションで支援しています。今後は 200 台規模のロボットと 30 万時間のデータ、数十億パラメーターの基盤モデルという規模で、台数・データ量・モデルの規模を増やせば性能が向上するのかを検証する計画です。同社はこれを、日本で初めてのロボット基盤モデルのスケーリング則の証明と位置づけています。 オムロン サイニックエックス株式会社 — オムロングループで先端技術の研究開発を担う会社です。今回は、フィジカル AI の土台にあたる研究の成果を発表しました。現在のフィジカル AI 開発では、AI の能力評価、動作データの準備、大規模モデルの構築に多くの人手と計算資源が必要です。そのハードルを下げるため、「理解・行動・振り返り」に対応する 3 つの成果を示しました。1 つ目は、AI がどの程度まで動画を正しく理解できるかを測る評価用ベンチマークの開発です。規模の大きいモデルでも時間の前後関係を取り違えやすく、しかも自身が生成した誤りには気づけないことが明らかになっています。2 つ目は、規模の小さいモデルでも言葉を理解する能力を活かしてロボットを動作させる手法。3 つ目は、動作中の失敗をその場で検出して理由を出力し、その失敗を活かして精度を自己改善する仕組みです。この 3 つは「状況を理解する」「行動を生成する」「振り返る」という一連のループの各工程に対応しており、ループとしてつなぐことで動作の精度が自ら上がり、モデルの軽量化によって速く安く回せるようになる、という構想が示されました。AWS からは高性能な GPU リソースの提供と、AWS 環境を利用するための補助 (コンソールの操作ガイド、GPU をまとまった期間確実に予約できる Amazon EC2 Capacity Blocks for ML の活用提案) を受けており、約 3 ヶ月の利用を通じて特許・論文を 3 件投稿しました。インスタンスの確保からセットアップまでを通した支援やガイダンスの充実があれば研究開発をさらに加速できる、という要望もあわせて示されました。 株式会社ZEALS — ヒューマノイド本体から専用のソフトウェア基盤、動作用のモデルまでを自社で開発するスタートアップです。3 月の採択時点ではソフトウェアに特化し、他社製の機体を活用していました。現場のデータを取得するには現場に入れる身体が必要ですが、日本の狭い廊下を通れ、人と同じ空間で安全に動き、現場が導入できる価格の機体は、当時中国にもアメリカにも見つからず、自社開発に踏み切りました。8 月にローンチした準国産コンパクトヒューマノイド「D1」は、全高 129.3〜159.3cm、走行ベース幅 48cm で、2 本の腕を備えます。機体に加え、会話や自律移動を支える「Omakase OS」、物の操作を担う AI と学習・改善を支えるモデル・データ基盤「Omakase Zen」を揃え、現場データの収集から学習・評価、現場への再投入までを回す土台が整いました。AWS はモデル開発に使うデータ処理基盤の構築、学習の分散処理への対応、データ変換の高速化を支援しており、データ変換は 10 倍に高速化しています。発表会の直前には病院で 3 日間の実証を行い、自律移動、受付前での案内、配茶機の操作、ドアの開閉を D1 が実行しました。2026 年度は販売台数ではなく現場での稼働時間を指標に置き、100 台の量産と 10,000 時間の稼働を掲げました。 株式会社ダイフク・株式会社JDSC — 物流現場の完全無人化に向けて、マテリアルハンドリングのリーディングカンパニーと、AX・データ活用を手がける企業が共同で取り組みました。物流では入荷から出荷まで各工程に人の判断と手作業が残っており、加えて事前に登録したものしか扱えず、品目が変わるたびに設定を作り直す必要があることが、完全無人化の障壁の一つになっています。今回取り組んだのは、ロボットの基本動作と安全条件をあらかじめ用意しておき、作業手順は事前に定義しない方式です。「棚 A の 3 段目に品を 2 個補充して」という作業者の言葉を AI がその場で作業単位に分解し、各段階で成否を判定して失敗した部分のみを再実行します。学習は Amazon SageMaker AI、検証済みアセットの展開は CI/CD で自動化し、シミュレーションでの検証サイクルを高速に回す構成を AWS 上に構築しました。検証では、指示に沿って仕分け先を判断するタスクを対象に、シミュレーション環境において、学習していない商品と仕分け先の組み合わせでも 100 回中 97 回、適切な仕分けまで成功しました。物流における完全無人化の実現に向け、今後は実機での検証を含むフィジカル AI の研究開発を進めていきます。 株式会社竹中工務店 — 日本建設業連合会の長期ビジョンでは、建設業の技能労働者が 2035 年度に 129 万人不足すると見込まれる一方、建設投資額は拡大が見込まれています。この人手不足を補う手段のひとつとして、建設業に特化したモデル※2 を開発し、塗装作業への適用可能性を検証しました。難所はデータでした。建設現場で使う道具の 3D データが存在しないため、道具の 3D データを自社で用意し、実際の現場を撮影した映像から三次元で再現したデータと組み合わせて「壁をローラーで塗装する」作業の学習データを構築しています。遠隔からデータを収集できる環境も整えました。AWS 上に構築したシミュレーション環境のなかに、収集から公開モデル※3 の調整、検証までを一貫して行う仕組みを構築しました。シミュレーション上での塗装動作 (物体操作の部分) の精度は現時点で 10〜15% 程度で、移動をともなう動作は検証中です。残る課題は、学習データが不足していて収集も難しいこと、そして検証と、シミュレーションで学習した動きを実機で通用させること※4 です。今後は建設技能労働者を支援するロボットの実現に向けて、言語モデルを介した人とロボットの会話にも取り組む方針です。 Telexistence 株式会社 — ロボットの基盤モデルを自社で開発するスタートアップです。基盤モデルには、言語モデルを土台にする方式と、動画生成モデルを土台に世界の動き方そのものを学習する方式※5 の 2 系統があり、同社は両方を開発しています。今回は後者を実機に載る形で確かめるため、10 億パラメータの軽量なモデルを自社開発しました。Amazon の研究チーム (Frontier AI & Robotics) の成果も取り込んでいます。AWS 上には、データの蓄積から学習、構成とデータの指紋を記録して再現性を担保するチェックポイント管理、学習を止めずにシミュレーション上で性能を測る評価までをつないだ仕組みを構築。設計の異なるモデルを同時に学習させ、条件を揃えて比較できるようにしたことが検証速度に直結したとのことです。結果として、大量のロボット動作データによる事前の学習を経ていない自社モデルの成功率が 86% となり、事前学習を済ませた公開モデル※6 の 80%、同じモデルを事前学習なしで初期化した場合の 50% に対して、事前学習済みのモデルと同等の水準に到達しました。大量のロボット動作データに依存せずに動作するモデルを構築できれば、開発の初期投資を抑えられます。 株式会社野村総合研究所 — フィジカル AI という言葉が広まる前からロボティクスに取り組んでおり、環境や用途に応じて適切な技術を選定できることを強みに挙げています。2025 年 10 月から 12 月には成田空港にお土産販売のロボット店舗を出店し、完全無人での販売を実施した実績があります。今回は 3 つのアプローチを並行して探索しました。実機を使った学習ではペットボトルのピッキングに成功。実環境を再現したシミュレーションで学習させて実機を動かす手法※7 では、映像の質感が実環境と異なるという課題を改善し、シミュレーション上で学習したモデルで実機を動かせる可能性が見えています。3 つ目は人の一人称視点で作業を記録したデータを用いる方法で、人の作業データからロボットのモデルを構築できることを確認しています。将来的には、現場スタッフの作業データによってロボットを導入できる状態を目指しています。データ収集からチーム内でのデータ共有、モデルの訓練と評価までを AWS 上に構築し、必要な計算資源を短期間で確保できたとのことです。 株式会社Highlanders — 四足歩行ロボットとヒューマノイドを、機体から AI、量産までを一体で開発する 2023 年創業のスタートアップです。危険・過酷な現場の「移動」を四足歩行ロボット「HLQ PRO」で置き換え、その先の「作業」をヒューマノイド「N」で担う二本立ての事業を掲げ、機械設計、電装・制御、通信・クラウド、AI、量産・品質までを同じチームで手がけています。今回は、自社開発のモデル「Kepler」を支える一連の仕組みを AWS 上に構築しました。「Kepler」は、ロボットが周囲を捉えて次に起きることを予測し、行動を決める 100 億パラメータのモデルで、じっくり計画を立てる層と素早く反応する層を組み合わせ、量産で集まるデータをもとに自ら改善していく構成です。AWS 上には、遠隔操作などで生まれる大量のロボット動作データを集約して整える処理、実機での収録だけでは足りない例外的な状況をシミュレーター※1 の並列実行で補って学習用のデータを生成する処理、AWS ParallelCluster による大規模な GPU クラスタでモデルを学習させる処理までをつなぎ、学習を 24 時間 365 日動かし続ける体制を実現しています。構築にあたっては AWS の Solutions Architect とフィジカル AI の専門チームが議論に加わりました。あわせて 2026 年 6 月 25 日・26 日の AWS Summit Japan では、四足歩行ロボット「HLQ PRO」の実機による実演デモを行いました。 FastLabel 株式会社 — AI 開発用のデータを専門に扱う会社です。フィジカル AI でも、学習データを増やせば性能が伸びるという関係が示されつつありますが、ロボットを実際に動かして集めるデータは容易には増やせません。そこで、シミュレーター※1 上で作成した少量の動きのデータを大量に増やし、実データと混ぜて学習データセットを作る仕組みを構築し、その効果を検証しました。遠隔操作により作成した 90 パターンの動きを約 100 倍に拡張し、不正な動作や失敗を除いて 10,000 パターンを取得。シミュレーション上で条件をランダムに変えることで、規模だけでなく多様性も確保しました。実データのみで学習した場合と比べ、データを収集した環境での作業成功率が平均 14.2% 向上し、データを収集した環境とは異なる環境でも、対象物に手を伸ばす動作の達成率が改善して汎化性の向上が確認されています。学習したときの環境から条件が変わると精度が落ちるという、現場導入の障害となる課題に対して改善が見られたことになります。一方で、シミュレーションデータの量が最も多い条件では成功率が下がっており、シミュレーション環境への過適合の可能性が残るとして、現在も分析と検証が進められています。データ構築の費用と性能の関係も定量化され、シミュレーションによってデータ収集のコストを下げられる可能性が示されました。学習は AWS 上の GPU インスタンスで行い、AWS からはシミュレーション技術の知見と計算リソースの提供を受けています。 株式会社豆蔵 — システム工学・ソフトウェア工学・ロボット工学を強みとし、ソフトウェアから AI、機構、電気までを自社で手がける技術者集団です。産業向けに開発してきた「ヒューマノイドロボットでの板金整列アプリ」について、これまで対応できていなかった 2 つのテーマに取り組みました。上半身は、遠隔操作で 359 パターンの動きを収集してモデル※2 に学習させました。ただし映像だけを頼りにした制御では衝突が発生したため、力の強さを測るセンサーを使って柔らかく当てる制御を追加しています。無作為に積まれた部品から 1 枚を取り出す動作はモデルでは成功率が低かったため、取り出しは従来のプログラム、整列はモデルという分担にして、整列の成功率は板金の上下整列で 85%、左右整列で 80% を達成。下半身は、メーカー標準の制御では実現できなかったしゃがみ動作・前傾動作を、シミュレーション上での強化学習によって独自に実現しました。全身の制御も、作業に必要な 10 の関節に絞ることで 43 パターンの動きで実現しています。全身の関節すべてを使って同じことを行う場合には一般に 2,000 パターン以上が必要とされる (NVIDIA Isaac GR00T の FAQ による目安) ので、学習に必要なデータを大幅に減らせたことになります。公開モデル※3 の調整は約 8 時間、下半身の強化学習は約 32 時間で、いずれも AWS 上の GPU インスタンスで回しました。すべてをモデルで解決せず、従来のプログラムと相互に補完するハイブリッド構成が現実的だという結論は、産業での実用を前提に置いた発表でした。 株式会社MW — 住宅そのものを開発し、そこに AI とロボットを組み込む会社です。照明やエアコンの制御は同社のスマートホーム基盤「MW intelligence」によって自動化できていますが、物理的な作業をともなう家事は依然として人の時間を奪っています。ここを自動化するために開発しているのが、住宅に組み込むガントリー型の半人型ロボット「MW bot」です。人のように動きながら、家具のように暮らしに溶け込みます。家事は手順の決まっていない非定型の作業なので、そのためのモデル※2 を自社で開発しています。データ収集の専用拠点を設け、年間 5 万時間規模の家事データの収集を開始しました。最終的には 2.5 PB の学習データを集める予定です。本プログラムではモデルの追加学習までを実施し、日次で集まるデータを Amazon S3 に蓄積し、Amazon SageMaker HyperPod で学習したモデルを実機で検証して次の学習に戻す循環を構築しています。今後は大量の学習データの管理と、大規模なモデル学習の面で AWS との連携を深めていく方針です。 株式会社メルカリ — 越境取引の拡大にともない、海外へ発送する商品をいったん国内の自社倉庫に集めて検品する作業が増え続けています。検品は倉庫の他の工程に比べて約 10〜60 倍の時間を要し、ロボットを投入したときの効果が最も大きい工程です。今回はこの検品・出品作業の自動化に取り組みました。いまのロボットを動かすモデル※2 には、力加減の制御が難しい、カメラの位置が変わると精度が落ちる、学習データを集めるのが困難という 3 つの限界があります。それぞれに対して、力の強さを測るセンサーと触った感触を捉えるセンサーをモデルに統合する、どの位置から撮った映像でも学習したときの視点に投影しなおしてからモデルに入力する、力加減や触感も一緒に記録できる専用の収集機器で人の作業を取り込む、という 3 つの手法でモデルの開発に取り組んでいます。まずは同じカテゴリのなかでばらつきが小さい靴の検品に注力し、箱を開けて靴を取り出し、全面を確認して戻し、箱を閉じて元の位置に戻すまでの 9 工程を対象としました。学習は AWS 上の分散学習で進め、立ち上げをスムーズに行えたとのことです。靴の検品については 2026 年度中の実証実験に向けて製品設計を進めている段階で、2028 年には自社倉庫の約 20% を自動化し、社内コストを年間最大 2 億円削減する計画です。 株式会社リコー — 現場の文書の AI 化から始め、定型業務、非定型業務へと AI の適用範囲を広げ、その 4 段目として現場作業への実装を掲げています。課題として置かれたのは、ロボットの行動データが質・量・多様性のいずれの面でも不足していること、さらにロボットの機種 (アーム型や人型など本体の構成) が変わるたびにデータ収集と学習を繰り返す必要があり、それが規模の拡大と普及の足かせになっている点でした。そこで、公開されているモデルを土台に、機種に依存しない共通の動作表現をいったん学習し、機種ごとに差し替えるのは出力側だけにする方式を検証しています。AWS 上に GPU サーバー 5 台の学習環境を構築し、1 回の試行を約 4 日、モデル改良を週 1 サイクル回せる体制を確立しました。結果として、ひとつの共通表現をもとに 3 種類のロボットをシミュレーション上で動作させられることを確認し、うち 1 機種は実機でも自社部品のピックアンドプレースを実行できることを確認しました。あわせて公開ベンチマークでの評価では、モデルの規模※8 を約 3 分の 1 に抑えても性能が保たれることを示しました。同じ性能を小さなモデルで出せれば、ロボット側に載せる計算資源の選択肢が広がります。本プログラムでの実施範囲は技術の蓄積までで、共通の動作表現を用いたモデルの使いこなしと改良のノウハウを獲得した段階です。今後は自社工場での事例づくりを進めたうえで、お客様との共創に移り、自社とお客様の環境に適したハードウェアへ広げていく方針です。 注釈 ※1 シミュレーター: NVIDIA Isaac Sim / Isaac Lab。ロボットと現場をソフトウェア上に再現し、実機を損傷させずに大量の試行を行える環境です。アトムはこれに MuJoCo を併用しています。 ※2 ロボットを動かすモデル: 正式には Vision-Language-Action (VLA) モデル。カメラの映像と人の言葉を受け取り、ロボットの動きを直接出力するモデルを指します。 ※3 公開モデル (竹中工務店・豆蔵): NVIDIA Isaac GR00T。NVIDIA が公開しているロボット向けの基盤モデルで、各社が自社の作業に合わせて調整のうえ利用します。 ※4 シミュレーションで学習した動きを実機で通用させること: Sim2Real と呼ばれます。シミュレーション上では成功しても、摩擦や照明などの条件の違いにより実機では動作しないことが多く、フィジカル AI 共通の課題です。 ※5 動画生成モデルを土台に世界の動き方そのものを学習する方式: World Action Model と呼ばれる系統で、Diffusion Transformer と呼ばれる構造を用います。言語モデルを土台にする方式と比べ、時間の流れを扱いやすい一方で、推論にかかる計算コストが大きくなります。 ※6 事前学習を済ませた公開モデル (Telexistence): Physical Intelligence の π0.5。大量のロボット動作データで事前に学習された基盤モデルです。 ※7 実環境を再現したシミュレーションで学習させて実機を動かす手法: real2sim2real と呼ばれます。 ※8 モデルの規模: パラメータ数で表します。今回は共通の動作表現を用いない 70 億パラメータのモデル (81.3pt) と、20 億パラメータのモデルに共通の動作表現を加えたもの (81.5pt) を、ロボット操作の公開ベンチマーク LIBERO-10 で比較しています。 総括 13 プロジェクトの発表のあと、AWS ジャパン プリンシパル スタートアップ ソリューションアーキテクトの針原 佳貴がまとめを話しました。 AWS ジャパンの生成 AI 開発支援は、2023 年に日本のスタートアップから「日本語に特化した基盤モデル・大規模言語モデルを自社で開発したい」という声を受け、4 つの柱で LLM 開発支援プログラムを立ち上げ、国内 17 社のモデル開発を支援したことから始まりました。その後、モデル開発だけでなく利活用を支援する生成 AI 実用化推進プログラムやグローバルのアクセラレータでも支援を行い、並行して経済産業省 GENIAC に採択されたお客様の基盤モデル開発を支えるなど、官民で連携した取り組みを続けてきました。 フィジカル AI 開発支援プログラムは、その延長線上にあります。昨年秋ごろからスタートアップの皆様と話すなかで、日本にも画像や動画を扱う基盤モデルの開発実績があり、現場のデータを使えば国産の VLA を作れるのではないか、ただしスタートアップ単独では難しいので AWS からの支援があると嬉しい、という声をいただいたことが出発点でした。お客様のニーズから逆算してプログラムを設計し、1 月に発表、3 月から半年間の開発を進めてきたことになります。プログラム期間中に AWS 社内でもフィジカル AI のワークロードを支援する体制が手厚くなったため、今後は生成 AI 実用化推進プログラムの枠組みのなかでフィジカル AI の支援を続けていきます。 閉会後は、ロボット展示会場へ移動しました。展示したのは 2 機です。 ZEALS の準国産コンパクトヒューマノイド「D1」は、病院・商業施設・物流施設・製造現場などへの導入を前提に設計された機体で、日本の病院の廊下を通れるコンパクトさと、人がぶつかっても安全な柔軟さが特徴です。 Highlanders のヒューマノイド「N」は、人向けの設備や道具をそのまま扱える身体と 5 指ハンドを備え、製造や物流の現場での軽作業を想定しています。いずれも動作に必要なデータ処理とモデル開発に AWS のクラウドをご活用いただいています。 参加企業向け成果発表会 参加企業向けの成果発表会では、冒頭 AWS ジャパンの針原と、経済産業省 商務情報政策局 AI 産業戦略課 課長補佐の秋元氏による挨拶の後、AWS ジャパンの木村がモデレーターを務め、以下の企業の成果が発表されました。以下社名 敬称略、五十音順。 株式会社アイシン／ブレインズテクノロジー株式会社 株式会社ACCESS 株式会社APTO SCSK株式会社 株式会社Enactic 株式会社カミナシ カラクリ株式会社・Upstage Co., Ltd.・株式会社ジェイテクト クラスメソッド株式会社 大日本印刷株式会社 株式会社PKSHA Technology 株式会社MIXI 三菱電機株式会社 Muso Action株式会社 株式会社メルカリ 得られた知見 3 月のキックオフの時点では、現場のデータを使って国産の VLA を作れるのか、作れたとして現場で使えるのかが、まだ見通せていませんでした。第一部の発表を通して見えたことを、白幡が挙げた 3 つの要素に沿って整理します。 まずスピードです。アトム、ZEALS、Highlanders、MW と、自社ハードウェアの開発から取り組んだ企業が複数ありました。ZEALS は 3 月時点では他社製の機体を活用していましたが、8 月に「D1」をローンチし、発表会の直前には病院での実証まで行いました。アトムは発表会の 3 日前に、物流作業で 24 時間の連続稼働デモを実施しています。速く回すには、安く早く測れることが前提になります。オムロン サイニックエックスは動作中の失敗をその場で検出して次の動作に反映するループを設計し、Telexistence は設計の異なるモデルを同時に学習させて条件を揃えて比較できるようにしたうえで、学習を止めずにシミュレーション上で評価を回す仕組みを組みました。FastLabel はデータ構築の費用と性能の関係まで定量化し、リコーは 1 回の試行を約 4 日に収めてモデル改良を週 1 サイクル回せる体制を作りました。何を測れば「できた」と言えるのかを先に決めて評価側を作り込むことが、複数の発表で共通していました。 次に現場の力です。技術だけでは足りないという認識が、具体的な形で出てきました。竹中工務店は、建設現場で使う道具の 3D データが世の中に存在しないという壁にぶつかり、自分たちで用意しています。メルカリは自社倉庫を実証環境として使い、他の工程の約 10〜60 倍の時間がかかる検品を対象に選びました。そして AI だけで解こうとしない判断も共通していました。ロボットの基本動作と安全条件を用意したうえで、手順の組み立てと各段階の成否判定をモデルに任せたダイフク・JDSC、古典的なロボット制御と AI を組み合わせて従来は難しかった柔軟な作業に取り組んだ野村総合研究所、取り出しは従来のプログラム・整列はモデルという分担にした豆蔵。とくに豆蔵は、学習した環境と実際に動かす環境が同じでないと成功率が落ちる、対象物がカメラから見えなくなると動作が破綻する、複数の作業を学習させると成功率が下がるといった限界を挙げたうえで、90 点でも許される作業やリトライできる作業がモデルに向く、という切り分けの基準まで示しました。どこを学習に任せ、どこを作り込み、どうつなぐかが、そのままシステムの構成を決めます。 そしてクラウドです。計算の規模で制約を押し返した例が並びました。Telexistence は複数 GPU での分散学習で軽量モデルを学習させ、FastLabel は 90 パターンの動きを 10,000 パターンに拡張してタスク成功率を平均 14.2% 改善しました。MW は年間 5 万時間規模で集まる家事のデータを日次で蓄積して学習に回す循環を組み、リコーは GPU サーバー 5 台の学習環境で 1 試行を約 4 日に収めています。必要な規模を必要なときだけ確保する使い方も見られ、オムロン サイニックエックスは GPU をまとまった期間確実に予約できる仕組みを使って 3 ヶ月分の計算資源を確保しました。 3 要素の外側では、コミュニティが具体的な成果につながりました。野村総合研究所からは、勉強会での最新情報の共有が助かったという声をいただきました。豆蔵は、類似の取り組みを行う参加企業とのコミュニティが形成されて情報交換ができたこと、相互に得意分野を活かした協業関係の構築が進んでいること、AWS から紹介した顧客との商談につながったことを挙げています。 これから フィジカル AI の開発支援は今回で終了ではありません。お客様からいただいたご要望を踏まえ、 生成 AI 実用化推進プログラム に統合して引き継ぎます。 3 月のキックオフイベントで、私たちは日本発のフィジカル AI イノベーションが生まれる大きな可能性があるとお話ししました。6 ヶ月後の今日、第一部と第二部をあわせて 26 のプロジェクトと、実際に現場で動くロボットを紹介できることとなりました。ものづくりと現場の技術に生成 AI を掛け合わせるという道筋が見えたことが、このプログラムの成果です。AWS は引き続き、日本のお客様とともにこの領域に取り組んでまいります。 関連リンク プログラム発表 / キックオフ Physical AI Scaffolding Kit 生成 AI 実用化推進プログラム 木村 公哉（Kimura, Koya） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 シニアスタートアップソリューションアーキテクト 2023 年よりディープテックスタートアップを担当。支援プログラムの立ち上げなどに尽力し、2025 年よりフィジカル AI をはじめとしたロボティクス関連領域にも支援を拡大。2026 年 1 月に「フィジカル AI 開発支援プログラム by AWS ジャパン」を発足。VC・政府とのディスカッションを通じ、フィジカル AI・ディープテック領域のエコシステム形成にも取り組んでいる。 針原 佳貴（Haribara, Yoshitaka） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 プリンシパル スタートアップ ソリューションアーキテクト AWS Japan にて、ユニコーン企業を含む生成 AI スタートアップ企業を中心に 2019 年頃から技術支援を担当。2020 年よりマルチモーダル生成 AI 技術に携わり、生成 AI 大喜利「写真で一言 ボケて電笑戦」を企画・開催、広告賞である ACC ブロンズを受賞。2023 年の「AWS LLM 開発支援プログラム」立ち上げ、2024 年に発表された Amazon Bedrock Marketplace への日本発の基盤モデルのクラウド公開、2026 年発表の「フィジカル AI 開発支援プログラム」などを通じて、日本国内の生成 AI 技術発展に携わる。 生成 AI 分野に加え、日本におけるクラウド量子コンピューティングサービス Amazon Braket の普及や、量子スタートアップ・ハードウェア開発コミュニティとの連携により国産量子コンピュータのクラウド公開にも尽力。2024 年 11 月より、大阪大学 量子情報・量子生命研究センター 招へい准教授。東京大学 大学院 情報理工学系研究科 博士課程修了。博士 (情報理工学)。