みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近1週間の生成 AI を巡っては、Anthropic Claude Opus 4.7 の Amazon Bedrock 対応や、東京リージョンでの提供開始をはじめとして、「より強いモデルを、より現場に近い場所で動かす」ためのアップデートが相次ぎました。また4月20日〜24日に開催された Hannover messe では、AI技術による生産プロセスの最適化、効率化、そして企業の競争力向上と持続可能性が主要なテーマとなっていました 。データ分析中心のAIから「物理世界で自律的に動くフィジカルAI」への移行の加速が進んでいます。そして、AWS界隈も目が離せません。 それでは 4月 20 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 富士通株式会社様との AI-DLC Unicorn Gym で見えた開発の未来 」 AWSが提唱するAI駆動開発ライフサイクル（AI-DLC）を実践的に学ぶプログラム「Unicorn Gym」に、富士通株式会社が参加した際の取り組みを紹介するブログです。7チーム40名弱が3日間、Amazon Bedrock AgentCoreやAmazon Connectなどを活用しながら、COBOLからJavaへの移行、ペーパーレス化システム、AIエージェントプラットフォーム、自動架電システムといった実課題に取り組んだ内容がまとめられています。記事では、COBOLからJavaへの移行で約4,300行のコードを自動生成した事例など、生成AIを活用した開発の具体的な成果が数字とともに語られています。あわせて、SE（システムエンジニア）の役割が「コードを書く力」から「仕様を策定する力」や「AIが生成した成果物をレビューする力」へとシフトしていく点にも触れられており、生成AIを使った開発プロセスを組織に取り入れたいユーザーにとって導入のヒントになる内容です。 ブログ記事「 【開催報告 & 資料公開】お試しから卒業！Kiro の仕様駆動開発を本格活用 in 大阪 」 2026年3月17日にアマゾン ウェブ サービス ジャパン 大阪オフィスで開催された「AWS Business Innovation Series – West Japan」第1回の開催報告ブログです。18社37名が参加し、AWSが提供するIDE「Kiro」を使った仕様駆動開発を、座学・ハンズオン・ハッカソンの3ステップで体験する内容が実施されました。参加者の約85%がIT部門、15%が事業部門で、開発経験者は全体の約10%と少数だった点が特徴で、普段コードを書かない参加者でも半日で動作するプロトタイプまで作れたという反応が紹介されています。「Vibe Coding」と「Specモード」の体験を通じて、要件定義から実装までの流れを掴める構成になっており、生成AIを使った開発に興味はあるが何から始めればよいか迷っているユーザーにとって、社内での取り組みを検討する際の参考になる内容です。 ブログ記事「 AUMOVIO が Amazon Bedrock 搭載のエージェント型コーディングアシスタントでソフトウェア開発を強化 」 自動車部品サプライヤーのAUMOVIO社が、AWSと協業してエージェント型のコーディングアシスタントを開発した事例を紹介するブログです。Amazon BedrockやAmazon SageMaker、AWS Lambdaなどを組み合わせ、自動車特有のコードベース（約7,000関数）でモデルをファインチューニングし、オープンソースの「Cline」を活用したエージェントとして実装されています。自動車業界のようにAUTOSARやMISRA-C/C++といった業界標準への準拠が求められる領域でも、ドメインに特化したファインチューニングとエージェント型のアプローチを組み合わせることで、コーディング支援の実用性を高められる点が特徴です。記事内ではシニア開発者が5日間かけていたバグ修正が数分で完了した例や、冗長なコードを削除してファイルサイズを半減させた事例も紹介されており、業界固有のルールを持つ組織で生成AIによる開発支援を検討しているユーザーにとって参考になる内容です。 ブログ記事「 AI for Science – AI がもたらす研究新時代 」 創薬・ゲノミクス・材料科学・気候科学・物理学といった科学研究の領域で、AI活用が実用段階に入りつつあるという「AI for Science」の潮流を解説したブログです。Amazon Bedrock、Amazon SageMaker AI、Amazon Textract、Amazon Comprehendなどを組み合わせた研究基盤の構成や、Genomics England、Allen Institute、LILA Sciences、アリゾナ大学といった海外の先進事例が紹介されています。文部科学省が推進する「SPReAD」事業の開始タイミングにあわせて、大学や研究機関の研究者に向けて書かれている点が特徴で、8〜12週間の小規模なPoC（概念実証）から始める段階的な進め方が示されています。研究データが基盤モデルの学習に利用されない仕組みなど、知的財産や個人情報に関するデータ保護の考え方にも触れられており、AI活用を検討している研究機関やそれを支援する立場のユーザーにとって参考になる内容です。 ブログ記事「 EngineLab AI: AWSで実現するスタジオとクリエイター向け本番制作AI環境 」 EngineLab社が提供するマネージドデプロイメントプラットフォーム「EngineLab AI」を、Amazon EC2のGPUインスタンスやAWS Deadline Cloud上で活用する方法を紹介するブログです。映像・メディア制作の現場でよく使われるComfyUIなどの生成AIアプリケーションを、本番環境で安定して運用するための構成が解説されています。顧客自身のAWSアカウント内にデプロイされるためデータがプラットフォーム外に出ず、知的財産（IP）を社内に留められる点や、必要なときだけGPUリソースを使うオンデマンド型の構成でオンプレミスの固定費を抑えられる点が特徴です。ノードベースの操作に慣れた上級者向けのUIと、技術知識のないクリエイター向けのArtist UIを両立している点にも触れられており、スタジオやクリエイター組織で生成AIを制作ワークフローに組み込みたいと考えているユーザーにとって、実装イメージをつかめる内容です。 ブログ記事「 開発現場から全社展開へ：Amazon Bedrock で Claude Cowork を動かす 」 Anthropic社が提供するデスクトップアプリ「Claude Cowork」を、Amazon Bedrockをバックエンドとして動かす方法を紹介するブログです。ドキュメントの読み取りや複数ステップのリサーチ、ファイル処理などをアプリ上で行いつつ、データを自社のAWSアカウント内に保持したまま利用できる構成が解説されています。Claude Codeのような開発者向けツールから一歩進んで、プロダクトマネージャー、オペレーションマネージャー、ファイナンスアナリストなど、社内のナレッジワーカー全体に生成AIの活用を広げていく展開イメージが示されている点が特徴です。MDM（モバイルデバイス管理）による一元的な設定配布や、シートライセンス不要の従量課金モデルにも触れられており、開発チームで始めた生成AI活用を組織全体にスケールさせたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 AI 駆動の業務変革手法：『課題は何ですか？』と聞くのをやめた日 」 AWSが開発した業務変革プログラム「AI BPR（AI-driven Business Process Re-Engineering）」について、試行錯誤の過程とともに紹介するブログです。初期の「課題解決型」アプローチが機能しなかった経験から、組織心理学の理論（Appreciative Inquiryなど）を取り入れて再設計し、Observe・Shift・Simulate・Forecastという4段階のフレームワークに行き着いた経緯が解説されています。生成AIの導入は技術的な問題よりも、組織が変化を受け入れる「適応課題」である点に焦点を当てている点が特徴で、AI活用を進めたいがなかなか現場が動かないと感じているユーザーにとって、アプローチを見直すヒントになる内容です。 ブログ記事「 IAM プリンシパルベースのコスト配分で Amazon Bedrock のコストを呼び出し元ごとに追跡する 」 Amazon Bedrockの利用コストを、呼び出し元のIAMユーザーやIAMロール単位で追跡できる新機能を紹介するブログです。Bedrock APIの呼び出しごとにIAMプリンシパルのIDが自動的に記録され、AWS Cost and Usage Report（CUR 2.0）やAWS Cost Explorerでプリンシパル単位のコストを可視化できるようになります。これまではBedrockの利用料金が単一の明細にまとまって表示されていたため、どのチームやプロジェクトがどれだけ使っているかを把握するにはAWS CloudTrailのログと突き合わせる必要がありました。この機能により、チャージバック（社内費用配賦）が正確に行えるようになり、複数チームで生成AIを活用している組織のコスト管理の負荷を下げられます。API Gateway経由でBedrockを呼び出す構成では中間ロールにコストが集約されるため、セッションタグでの動的な帰属が推奨されるといった実装上の注意点にも触れられています。 ブログ記事「 VPC 内のプライベートサービスに AWS DevOps Agent をセキュアに接続する方法 」 AWS DevOps Agentから、Amazon VPC内に閉じたプライベートなサービスに安全にアクセスする構成方法を紹介するブログです。Amazon VPC Latticeのリソースゲートウェイを経由して接続を確立し、セキュリティグループでトラフィックを制御する構成が解説されています。パブリックインターネットに公開することなく、エージェントから社内のプライベートなサービスにアクセスできる点がポイントで、具体例としてセルフホスト型Grafanaへの接続手順が紹介されています。これによりエージェントがオブザーバビリティ（システムの可視化）データを参照できるようになり、インシデント対応時の調査を自動化しやすくなります。AWS CLIとマネジメントコンソールの両方で設定手順が記載されているため、運用環境へのAWS DevOps Agent導入を検討しているユーザーにとって参考になる内容です。 ブログ記事「 Amazon Bedrock での Anthropic の Claude Opus 4.7 モデルのご紹介 」 Anthropic社の最新モデル「Claude Opus 4.7」がAmazon Bedrockで利用できるようになったことを紹介するブログです。米国東部（バージニア北部）、アジアパシフィック（東京）、欧州（アイルランド）、欧州（ストックホルム）の各リージョンで提供され、最大100万トークンのコンテキストウィンドウに対応しています。自律的にコーディングを進めるエージェンティックな用途での性能が向上しており、SWE-Bench Proで64.3%、Finance Agent v1.1で64.4%といったベンチマーク結果が紹介されています。Converse API、Invoke API、Messages APIといった複数の呼び出し方法に対応しているほか、新しい推論エンジンによる動的なキャパシティ割り当てやリクエスト数のスケールにも触れられており、長いドキュメントを扱う業務や、複数ステップにわたるコーディング・分析タスクにClaudeを組み込みたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Opus 4.7 が Kiro で利用可能になりました 」 Anthropic の最新モデル Claude Opus 4.7 が Kiro IDE および CLI に順次展開されました。Opus 4.6 の直接アップグレード版として、複雑で長時間にわたるタスクでのコーディング性能が向上し、複数ファイル・ツールにまたがるマルチステップ実装や自己検証機能を備えています。Kiro の仕様駆動開発との親和性も高く、大規模コードベースでの高忠実度な実装を実現します。 ブログ記事「 Kiro CLI をプログラムから実行する：ヘッドレスモードの紹介 」 Kiro CLIを、ブラウザを介さずにプログラムから実行できる「ヘッドレスモード」を紹介しています。APIキーを発行して環境変数に設定するだけで、CI/CDパイプラインやcronジョブなど無人の自動化環境でKiroを動かせるようになります。具体例として、GitHub Actionsと組み合わせてプルリクエストに自動でコードレビューを行う実装方法が紹介されています。コードレビュー以外にも、ドキュメント生成、依存関係の監査、マイグレーション支援など幅広い用途に応用できる点が特徴で、開発者の手元だけでなく、CIパイプラインの中に生成AIを組み込んでいきたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Kiro でビルドする：コミュニティハブと Kiro Labs の紹介 」 Kiroのエコシステム拡張として、「Kiro Community（コミュニティハブ）」と「Kiro Labs」の2つが発表されました。コミュニティハブは開発者の実験的なプロジェクトの共有や、Discord・イベントを通じた情報交換の場として機能し、Kiro Labsはアマゾン社員が構築したオープンソースプロジェクト群を公開する場として位置づけられています。Kiro Labsではカスタムワークフロー、UI、生産性向上ツールなどが「as-is」で提供され、アクティブ・メンテナンス・アーカイブの3段階のステータスが付与されるほか、Amazonのオープンソース基準に沿ったセキュリティレビューも行われます。Kiroをすでに使っているユーザーにとっては、他の開発者の実装例を参照してワークフローを組み立てたり、プルリクエストで貢献したりといった形で活用できるリソースが増える内容です。 サービスアップデート Claude Platform on AWSが近日公開 Anthropic社が提供するネイティブのClaudeプラットフォームを、AWSの認証情報と請求の仕組みでそのまま利用できる「Claude Platform on AWS」が近日公開として発表されました。Anthropic本家のプラットフォームと同じAPIや機能にアクセスできるため、Claudeの最新機能をいち早く利用できるのが特徴です。利用にあたっては、別途Anthropicとの契約や認証情報を用意する必要はなく、既存のAWSアカウントとIAMポリシーをそのまま使えます。APIコールはAWS CloudTrailに記録されるため、ほかのAWSサービスと同じように監査ログを一元的に管理でき、利用料金もAWSの請求書にまとめられます。Amazon Bedrockが「AWSの基盤上でClaudeを動かし、データをAWS内で処理・保持する」位置づけなのに対し、Claude Platform on AWSは「Anthropic側のプラットフォームをAWSの認証・請求で使う」という選択肢を提供する形で、ユースケースに応じて使い分けられる点がポイントです。 Amazon Bedrock AgentCoreが新機能を追加しエージェント開発を加速 Amazon Bedrock AgentCoreに、エージェント開発を加速するための新機能が追加されました。モデル・システムプロンプト・ツールを指定するだけで即座にエージェントを動かせる「マネージドハーネス（プレビュー）」、AWS CDK対応でコードベースのガバナンスを実現する「AgentCore CLI」、コーディング支援ツール向けの事前構築スキル「AgentCore Skills」の3つが提供されます。オーケストレーションコードを書かずにアイデアからプロトタイプまでを素早く立ち上げられる点が特徴で、プロトタイプの進化に合わせて評価・メモリ・ツールを段階的に追加していくこともできます。AgentCore SkillsはまずKiroから利用でき、Claude Code・Codex・Cursorにも順次対応予定です。マネージドハーネスは米国西部（オレゴン）、米国東部（バージニア北部）、欧州（フランクフルト）、アジアパシフィック（シドニー）の4リージョンでプレビュー提供されています。 Amazon QuickがVisierのVeeエージェントと統合し、ワークフォースインテリジェンス機能を提供 Amazon Quickが、Visier社の人材分析プラットフォームのAIアシスタント「Vee」とMCP（Model Context Protocol）経由で統合されました。これにより、Amazon Quickのワークスペース内から、Visierが管理する人員数・離職率・勤続年数・求人情報などのワークフォースデータに自然言語でアクセスできるようになります。人事・財務・オペレーション部門の担当者が、ツールを切り替えることなく組織の人材データを参照できるようになる点が特徴で、定期的なワークフォースレビューやドキュメント作成をQuick Flowsで自動化する使い方も想定されています。Amazon Quickがサポートする全リージョンで利用でき、組織全体の予算やポリシーデータと合わせて意思決定に活用したいユーザーにとって参考になる内容です。 Amazon Bedrock AgentCore GatewayとIdentityがVPC egress に対応 Amazon Bedrock AgentCore GatewayとAmazon Bedrock AgentCore Identityが、VPC egress（VPC内のプライベートリソースへの接続）に対応しました。マネージド型のVPC egressと、自己管理型のAmazon VPC Latticeリソースの両方から構成を選択でき、東京リージョンを含む14のAWSリージョンで利用可能です。これにより、Amazon EKS上でホストしているMCPサーバーや、社内ネットワーク内のプライベートなアイデンティティプロバイダー（IdP）、プライベートDNSで名前解決するリソースなどに、AgentCoreから直接アクセスできるようになります。エージェントからプライベートなエンタープライズシステムに安全に接続したいユーザーにとって、構成の選択肢が広がる内容です。 Amazon SageMaker HyperPodが自動Slurmトポロジー管理に対応 Amazon SageMaker HyperPodが、ネットワークトポロジーを自動で選択・最適化する機能に対応しました。GPUインスタンスタイプに応じてツリートポロジー（階層的な相互接続）とブロックトポロジー（均一な高帯域幅）を自動で選び、クラスターのスケール変更やノード置換の際にも継続的に最適化されます。これまでSlurm設定ファイルやトポロジーファイルを手動で管理していた運用から解放され、GPU間通信（NCCL集約通信）の効率を保ったまま分散学習を進められる点が特徴です。機能はデフォルトで有効化されており設定不要なため、大規模な分散学習を行うユーザーにとって運用負荷の軽減につながる内容です。 Amazon SageMakerがIAM Identity Centerドメインでノートブックとデータエージェントに対応 Amazon SageMaker Unified Studioで、これまでIAMドメインでのみ利用できたサーバーレスノートブックと組み込みのデータエージェントが、AWS IAM Identity Center（IdC）ドメインでも利用できるようになりました。Amazon Athena for Apache Sparkと連携し、SQL・Python・自然言語を単一の対話型ワークスペース上で組み合わせて扱えます。AWS IAM Identity Centerで認証・アクセス管理を一元化している組織でも、IAMドメインと同等の分析・機械学習機能が使えるようになる点がポイントで、AIデータエージェントが自然言語のプロンプトからコードを生成する機能や、ペタバイト規模のデータ処理にも対応しています。シングルサインオン環境を維持したままデータ分析基盤を整備したいユーザーにとって参考になる内容です。 Amazon QuickがSharePointとGoogle Driveを対象としたナレッジベースで複数所有者機能をサポート Amazon Quickで、Microsoft SharePointとGoogle Driveを対象とした管理者管理型のナレッジベースに、複数の所有者を追加できるようになりました。所有者には「オーナー」と「ビューアー」の2種類があり、オーナーは編集・同期・共有・削除を含む管理権限を、ビューアーはクエリのみの権限を持ちます。これまでナレッジベースが単一の所有者に依存していた運用から、チーム単位での共同管理が可能になる点が特徴で、既存のデータソース接続をそのまま再利用できるため、認証情報を再入力する必要もありません。東京リージョンを含む7つのAWSリージョンで利用でき、複数メンバーで社内ナレッジの整備を担当しているユーザーにとって運用がしやすくなる内容です。 Amazon QuickがACL対応ナレッジベースの権限検証機能をサポート Amazon QuickのACL（アクセス制御リスト）対応の知識ベースで、特定のユーザーが特定のドキュメントにアクセスできるかを検証するPermission Checker機能が追加されました。管理者は「Sync reports」タブからメールアドレスを入力することで、アクセス可否や、対象ドキュメントにアクセス可能なユーザー・グループ一覧を確認できます。これまではデータソース側の権限継承を手作業で追いかける必要があり、権限設定のトラブルシューティングに手間がかかっていました。機密情報が想定外のユーザーに参照されていないかを体系的にチェックできるようになるため、社内ナレッジを扱う知識ベース運用のセキュリティ確認を効率化したいユーザーにとって役立つ内容です。東京リージョンを含む7つのAWSリージョンで利用できます。 Amazon SageMaker Unified StudioがIAMドメインのプロジェクト内で複数コードスペースに対応 Amazon SageMaker Unified Studioで、IAMドメインの単一プロジェクト内に複数のコードスペース（個別に設定できる開発環境）を作成・管理できるようになりました。従来はプロジェクトあたりJupyterLabスペース1つとCode Editorスペース1つに限られていましたが、それぞれ独立したAmazon EBSボリュームを持つ複数のスペースを用意できます。長時間のデータ変換ジョブを動かしながら別スペースでモデル学習を進めるといった並行作業がしやすくなる点が特徴で、スペースごとに計算リソースやストレージをスケールさせたり、一時停止・再開したりできます。ブラウザからもローカルIDEからも接続でき、Amazon Q有料版にも対応しているため、1つのプロジェクト内で複数のワークストリームを回しているデータサイエンティストにとって作業効率の向上につながる内容です。 Amazon SageMaker AIがQwen3.5モデルのサーバーレスモデルカスタマイズに対応 Amazon SageMaker AIで、Alibaba Cloudが提供するQwen3.5モデル（4B・9B・27Bパラメータ版）に対するサーバーレスのファインチューニングがサポートされました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）の両方に対応し、クラスター管理を行わずにモデルカスタマイズを実行できます。自社の独自データでモデルを調整して業界特有の用語や品質基準に適応させたい場合でも、インフラの構築や運用はAmazon SageMaker AI側が担うため、データや評価設計に集中できる点が特徴です。利用した分だけの従量課金モデルで、東京リージョンを含む4つのAWSリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド））で提供開始されており、Qwen3.5を自社ユースケース向けに特化させたいユーザーにとって選択肢の一つになります。 Amazon SageMaker AIが生成AI推論レコメンデーション機能を提供開始 Amazon SageMaker AIに、生成AIモデルの推論環境を自動でベンチマークし、最適な構成を提案する「推論レコメンデーション」機能が追加されました。ユーザーがモデルとトラフィックパターン、性能目標（コスト最適化・レイテンシー最小化・スループット最大化のいずれか）を指定すると、システムが複数のインスタンスタイプを評価し、検証済みのメトリクスとともにデプロイ可能な構成を返します。初回応答時間（TTFT）、トークン間レイテンシー、スループット、コスト予測といった指標が一度にまとめて得られるため、手動でベンチマークを組んで比較する手間を省ける点が特徴です。東京リージョンを含む7つのAWSリージョンで利用でき、生成AIモデルを本番展開する際のインスタンス選定に悩んでいるユーザーにとって参考になる内容です。 Amazon SageMaker JumpStartで5つの新しいQwenモデルが利用可能に Amazon SageMaker JumpStartで、Alibabaが提供するQwenシリーズの新しい5つのモデルが利用できるようになりました。ツール利用や実行失敗からの復旧に対応する「Qwen3-Coder-Next」、思考モードの切り替えに対応した「Qwen3-30B-A3B」、数学・科学・コーディングの推論に特化した「Qwen3-30B-A3B-Thinking-2507」、エージェント型コーディング向けの「Qwen3-Coder-30B-A3B-Instruct」、マルチモーダルに対応する軽量モデル「Qwen3.5-4B」の5種類です。数クリックでデプロイできるJumpStartの特性を活かして、コーディングエージェントや多言語アプリケーション、軽量モデルでのコスト最適化された推論など、用途に応じたモデルを選択しやすくなっています。Qwenシリーズを自社のユースケースで試したいユーザーにとって、選択肢が広がる内容です。 Amazon EC2 G7eインスタンスがAWS Local Zonesロサンゼルスで利用可能に Amazon EC2のG7eインスタンスが、AWS Local Zonesのロサンゼルス（us-west-2-lax-1b）で利用できるようになりました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPUと第5世代Intel Xeon Scalableプロセッサを搭載しており、VFXや色補正などのクリエイティブ制作から、大規模言語モデルの推論といったAIワークロードまで幅広く対応します。ロサンゼルス周辺でスタジオワークステーションやポストプロダクション、エッジでのAI推論といった低レイテンシーが求められる用途に、地理的に近い場所からGPUリソースを利用できる点がポイントです。オンデマンドとSavings Plansの両方で購入でき、メディア・エンタテインメント業界やエッジAIの導入を検討しているユーザーにとって選択肢の一つになる内容です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

2026年4月20日（月）、AWS は完全招待制イベント「AWS Retail & CPG EXPO 2026 — Build the future with AI」を AWS 東京オフィスにて開催しました。48社・約100名のお客様にご来場いただき、盛況のうちに閉幕しました。AI エージェントのデモを日本向けにローカライズし、「見て、触れて、体感できる」場をご提供しました。18:00からは懇親会も実施し、参加者の皆さま同士の交流の場となりました。ご来場いただけなかったお客様にも、このブログでイベントの内容を振り返りながらご紹介します。 AI エージェントが変える業界の未来 AI の時代は AI エージェントの時代へと移り変わっています。AI エージェントをどれだけ自律的に稼働させ、私たちの業務に適用できるかが問われる時代です。AI エージェントを安全に動かす基盤とともに、流通小売・消費財、飲食業界においてどのように活用していくかが重要なテーマとなっています。一方で、日本では「わかっている、でも進まない」という現状があります。本イベントは、この壁を乗り越えるきっかけとして、AI エージェントの”実物”を体感し、挑戦する企業の事例から自社の次の一歩を見つけていただくことを目的に開催しました。 展示エリア — AI エージェントの”実物”を体感 展示エリアでは、NRF 2026 で発表されたデモを日本向けにローカライズし、流通小売・消費財、飲食業界のワークロードに沿って、製品開発と生産計画・価格戦略、サプライチェーン、店舗・サイトでの顧客体験の流れで4カテゴリ・7ブースをご紹介しました。すべてのデモに共通するのは「マルチエージェント × Human-in-the-Loop」というコンセプトです。AI エージェントが自律的に連携しながらも、重要な判断は人間が行うという設計思想を、実際に動くデモで体感いただきました。各展示の詳細資料は下記の各展示紹介からダウンロードいただけます。気になった展示がございましたら、担当営業まで個別デモをお気軽にご相談ください。 マーチャンダイジング — 製品開発・価格戦略 製品開発や価格戦略は、企業の競争力を左右する重要な領域です。2つのマルチエージェントデモをご紹介しました。 Luggage Lab：リサーチャー・デザイナー・プランナーの3つのエージェントが連携し、製品イノベーションを加速するデモをご覧いただきました。（ Luggage Lab 詳細資料 ） Luggage-Lab — エージェントの役割図 Luggage-Lab — アーキテクチャ Retail Pricing Agent：競合調査・需要分析・価格決定の3つのエージェントが連携し、生成 AI で価格戦略を自動化するデモをご紹介しました。（ Retail Pricing Agent 詳細資料 ） Retail-Pricing-Agents — 処理フロー Retail-Pricing-Agents — アーキテクチャ サプライチェーン — 混乱への自律的対応 サプライチェーンの混乱は、流通小売・消費財、飲食業にとって常に大きなリスクです。複数エージェントが連携して情報を収集・対策案を出し、人が判断するという形を体験いただきました。 Agentic Supply Chain：調達・在庫・計画・物流の4つのエージェントが連携し、サプライチェーンの混乱に AI エージェントが自律的に対応するデモを展示しました。（ Agentic Supply Chain 詳細資料 ） Agentic-Supply-Chain — 専門エージェントチーム構成 Agentic-Supply-Chain — アーキテクチャ オムニチャネル — 顧客体験の変革 デジタルと実店舗をシームレスにつなぐ顧客体験は、業界の重要なテーマです。3つのデモで、AI が「一人ひとり」に寄り添う新しい顧客体験をご紹介しました。 Smart Beauty：画像解析により肌質を16タイプに詳細分類し、改善提案を自動化するデモです。美容部員の知見を AI が再現しています。（ Smart Beauty 詳細資料 ） Smart-Beauty — 肌質+パーソナルカラー診断 Smart-Beauty — アーキテクチャ Fix&Fab：写真と説明だけで DIY の修理手順を生成し、ショッピングリストや専門家紹介まで提供するデモをご覧いただきました。（ Fix&Fab 詳細資料 ） Fix-and-Fab — 写真1枚でプロジェクト設計 Fix-and-Fab — アーキテクチャ リテール AI コンシェルジュ：商品提案から在庫確認、イベント案内、来店プランまで、EC から店舗へのシームレスな動線を実現するデモをご紹介しました。（ リテール AI コンシェルジュ 詳細資料 ） Retail-AI-Concierge — 新たな顧客体験 Retail-AI-Concierge — アーキテクチャ プロダクトイノベーション — 次世代パーソナライズ 返品問題やサイズ選びの課題は、EC・実店舗を問わず業界の大きなテーマです。 Bodd：Bodd社の提供する 60秒の非接触ボディスキャンによる精密採寸テクノロジーで、ブランド横断のサイズ提案を実現するデモを展示しました。 Bodd — ボディスキャンによる精密採寸 Bodd — カスタマージャーニー 気になった展示がございましたら、担当営業まで個別デモをお気軽にご相談ください。 セッション — 挑戦する企業に学ぶ セッションは、AWS によるオープニング（2セッション）、お客様事例（4セッション）、AWS セッション（1セッション）で構成しました。 AWS オープニングセッション Keanu Nahm / キアヌ ナン — 海外から見えてくる AI 活用成功の共通点と日本小売・消費財業界に示すチャンス Keanu Nahm / キアヌ ナン（AWS グローバル小売・消費財事業開発 日本ヘッド）は、NRF 2026 や ShopTalk 2026 のトレンドを踏まえ、グローバルの小売・消費財業界が AI の「実験の年」から「実装の年」へ移行している現状を紹介しました。AI が広く深く使われるための3条件として「使いやすさ（摩擦ゼロ）」「安心して任せられる」「習慣になる」を挙げ、日本の小売・消費財業界にとってのチャンスを示しました。（セッション資料は こちらからダウンロード いただけます。） 五十嵐 建平 — AI エージェントが変える小売の現場を体感し、挑戦する企業の事例から自社の次の一歩を見つけよう 五十嵐 建平（AWS インダストリソリューション本部 本部長）からは、AWS から見る AI エージェントの現状、AI エージェントが「道具」から「同僚」へと進化している潮流を紹介し、本イベントの展示・セッションの全体像をご案内しました。（セッション資料は こちらからダウンロード いただけます。） お客様事例セッション 株式会社コーセー — コーセーが挑む、生成 AI の全社展開 ～現場定着を実現する仕組み作り～ 横山 春佳 氏　情報統括部 DX推進課 生成AI推進リーダー 金田 実久 氏　情報統括部 基盤開発課 生成AI推進担当 (株)コーセーからは「いいシステムでも全員が使いこなせるとは限らない」という課題意識から、情報システム部門である情報統括部主導で生成 AI の全社展開に取り組んだ事例を紹介しました。システム構築と活用支援/教育を同時に進める全体構想のもと、社員が迷わず使える UI 設計、直感的なモデル選択、ゲーミフィケーションによる利用促進など、「自発的に使いたくなる」環境づくりを実現。AWS の Prototyping チームの協力で1ヶ月で基盤を構築し、生成 AI が組織の「共通言語」として定着した成果を共有いただきました。 株式会社 asken — Vibe Coding 起点での新機能開発で「あすけん」が乗り越えた壁 伊藤 拓哉 氏　プロダクト開発本部 AX推進部 シニアプロダクトマネージャー 岩間 良浩 氏　プロダクト開発本部 プロダクト開発部 シニアテックリード 食事管理アプリ「あすけん」を提供する asken 社から、PdM とエンジニアの新たな共創プロセスについて発表がありました。PdM が Vibe Coding で「動く PRD（プロトタイプ）」を作り、AWS 上の実験基盤「あすけんラボ」でユーザー検証を回すプロセスを構築。一方で、動く PRD をそのまま本番に流用しようとして開発工数が3倍に膨らんだ「悲劇」も共有。その失敗から、AI によるリバースエンジニアリングを活用したリファインメントプロセスを確立し、PdM とエンジニアがそれぞれの専門性を最大限に発揮できる「順序と境界の設計」に行き着いた経緯をお話しいただきました。 株式会社ゴールドウイン — AI。わかってるのに進まない ― 現場と経営のギャップを超えるには 末光 崇廣 氏　総合企画本部 シニアエキスパート ゴールドウイン社からは、多くの企業が直面する「AI が検索・要約で止まってしまう」問題について登壇いただきました。AI が実装まで進まない5つの壁（経営の期待の曖昧さ、現場の余裕のなさ、成功指標の不在など）を整理し、経営と現場の間にある「見えない溝」を可視化。突破口として「企画書で説明するより、動くものを見せる」アプローチを提唱し、実際に1日でプロトタイプを形にした事例を紹介しました。「説明して理解を待つフェーズはもう終わった。2026年は AI を業務に埋め込む年にしよう」というメッセージが印象的でした。 株式会社カインズ — 次世代店舗で実現する Fitting Room 体験 菅 武彦 氏　株式会社カインズ 情報システム事業部 CX統括部 統括部長 向井 剛志 氏　アジアクエスト株式会社 デジタルトランスフォーメーション事業部 デジタルエンジニアリング部 Eビジネスエンジニアリング課 マネージャー カインズ社とアジアクエスト社から、「買う前に試せない」という店内購買の課題に対し、生成 AI を活用した「CAINZ Fitting Room」の取り組みを紹介いただきました。過去にもコーディネートの可視化に挑戦してきたものの、質感の再現が課題でした。生成 AI の進化により、Amazon Bedrock を活用した画像生成でこの課題を解決。部屋の画像に家具やカーテンを仮想配置し、質感や影の映り込みまで再現できるようになりました。現在は店舗のタッチパネルで体験を提供しており、将来的にはお客様自身の部屋の写真での配置確認や、AI によるおすすめコーディネート生成なども構想されています。本取り組みは マイナビ TECH+ でも紹介されています。 AWS セッション 松本 鋼治 — Agentic AI 時代の広告・マーケティングの変革 松本 鋼治（AWS 戦略事業開発本部 プリンシパル事業開発マネジャー）は、リテールメディアの急成長、Agentic AI の台頭、AI 投資と実装のギャップという「3つの地殻変動」を解説。Amazon Ads の Creative Agent や Unified Campaign Manager など、Agentic AI で広告・マーケティングの民主化が進む最新動向と取るべき３つのアクションを紹介しました。（セッション資料は こちらからダウンロード いただけます。） ご来場ありがとうございました AWS Retail & CPG EXPO 2026 にご来場いただいた皆さま、誠にありがとうございました。AI エージェントは業務の中核に入り始めています。世界はもう動いています。自社の変革は、今日の「これ使えそう」から始まります。小さく始めて、AWS が伴走いたします。 ご来場いただけなかった皆さまも、ぜひ AWS の担当者までお気軽にご相談ください。皆さまの現場で AI エージェントが動き始めることを楽しみにしています。 イベント情報 名称：AWS Retail & CPG EXPO 2026 — Build the future with AI ～AIで未来を構築する～ 形式：完全招待制 会期：2026年4月20日（月）13:00〜18:00 会場：AWS 東京オフィス 参加：48社 約100名 主催：アマゾン ウェブ サービス ジャパン合同会社 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

本記事は2026年1月15日に公開された AUMOVIO Boosts Software Development with an Agentic Coding Assistant Powered by Amazon Bedrock を翻訳したものです。 本ブログ記事では、 AUMOVIO が Amazon Web Services (AWS) のサービスと知見を活用して、Software-Defined Vehicle (SDV) 領域における革新的な自動車向けコーディングアシスタントを開発した事例をご紹介します。AUMOVIO のソリューションは、複数の AI モデルを活用して開発ライフサイクルの各工程を加速させながら、自動車業界の標準と AUMOVIO 独自のコーディングベストプラクティスに準拠しています。可能な限りコードを再利用し、変更を最小限に抑えることで、このアシスタントは V 字モデル の他の工程に必要な作業を大幅に削減します。 AUMOVIO とその AWS 上の SDV ソリューションの詳細については、 こちら をご覧ください。 背景 車両がますますソフトウェアにより定義される中、自動車メーカーは複雑化するソフトウェア、イノベーションサイクルの高速化、厳格な品質要件という困難に直面しています。ハードウェア、拠点ごとのチーム、手作業に依存して構築された従来の開発手法は、制約となりつつあります。自動車メーカーは、現在世界中の拠点で勤務する数千人のエンジニアと連携しながら、様々な観点で検証が必要な膨大なコードベースを管理しなければなりません。さらに、開発チームは AUTOSAR 、 MISRA-C/C++ ガイドラインなどのドメイン固有のソフトウェア開発標準に加え、独自の社内標準にも準拠する必要があります。AUMOVIO の開発チームは、自社の組込みシステムプロセスをこの新しい現実に適応させるというプレッシャーにさらされています。 AUMOVIO は自動車向けのアプリケーションの厳格な基準を維持しながら、チームの生産性を向上させるインテリジェントなソリューションを求めて 、AWS と協業することにしました。 課題設定 自動車のベストプラクティスと規制によりよく適合させるため、AUMOVIO は V 字モデル に従ってソフトウェアを開発しています。各工程に費やされた工数を示す膨大な過去データのおかげで、AUMOVIO は効率化余地が最も高い工程を特定することができました。AWS の支援を受けて、AUMOVIO チームは以下を生成できるコーディングアシスタントの開発に取り組むことにしました： システム設計から自動車向けメソッド本体を生成（コーディングアシスタントの第 1 弾） システム設計からユニットテストを生成（コーディングアシスタントの第 2 弾） ソリューションの検討 AIコーディングアシスタントの実現可能性を検証するため、AUMOVIO は AWS の支援の下でハッカソンを開催しました。まず、AUMOVIO チームは RAG ベースのアプローチを試し、コードベースをベクトルストアに保存し、 Amazon Bedrock （サードパーティプロバイダーと Amazon の基盤モデルを簡単に使用できるフルマネージドサービス）を使用して、取得したチャンクに基づいてコードを生成しました。しかし、テストの結果、セマンティック検索では単一のクエリで与えられたタスクに関連するコードを取得できないことが判明しました。このアプローチの代わりに、チームはエージェント型アプローチを採用しました。このアプローチでは、コーディングアシスタント（強力な推論能力を持つモデルによって駆動）がコードベースから関連するコードコンテキストを段階的に取得します。言い換えると、エージェントは与えられたタスクに対して複数回検索を行い、各検索の結果を分析して必要な追加のコードコンテキストを決定し、コード生成などのタスクを完了するために必要なすべての関連情報を得るまで再度検索します。 このアプローチを実現するため、チームは Amazon Bedrock でホストされている Claude 3.7 Sonnet を搭載したオープンソースのコーディングアシスタント Cline を統合しました。エージェント型の構成は大きな可能性を示し、以下のような事例が得られました： シニア開発者が5日間かけた作業を数分でバグ修正 非常に大きなファイルをリファクタリングし、冗長性を削除してサイズを50%削減 同じ構成は既存コードの説明においても非常に優れたパフォーマンスを発揮しました。一方で、これらの標準モデルは、多くの再利用可能な API とベストプラクティスを含む AUMOVIO コードベースでファインチューニングされておらず、自動車特有のドメインにおいては限界も見られました。多くの場合、生成されたコードは良好であっても既存のライブラリを活用しておらず、既存実装の重複やわずかなバリエーションを引き起こしていました。 ワークショップの結果を踏まえて、AUMOVIO と AWS チーム (AWS の Generative AI Innovation Center を含む) は協力して、概念実証 (PoC) の一環としてエージェント型アーキテクチャを考案しました。PoC の目的は、自動車ソフトウェア開発向けの特化型コーディングアシスタントの実現可能性を探ることでした。このプログラムは、AI 駆動のイノベーション可能性を迅速に評価するため、事前に定めた成功基準と指標で評価する構造化されたアプローチを取りました。PoC フレームワークは、スコープ定義、開発、テスト、パフォーマンス評価、技術検証を包含し、期間内に測定可能な成果を提供するように設計されました。 チームは以下で構成されるエージェント型アーキテクチャを設計しました: ファインチューニングされたモデルまたはエージェント: コード生成やユニットテスト生成などの特定のV字モデルの工程に対して最先端の精度を提供するために使用。 オーケストレーターモデル (Claude Sonnet 3.7/4など): アプリケーションの対話ウィンドウで使用され、以下を実行: ユーザーからタスクに関する情報を収集 該当する場合、ファインチューニングされたモデルにタスクを委任 ファインチューニングされたモデルでサポートされていないタスクに応答（例: コード説明） パフォーマンスのベースラインを確立し、エージェントの取りうるさまざまな構成を理解するため、我々は多様な能力を持つ複数のモデルを評価しました。これには、迅速な応答に最適化された Nova Pro のようなプロンプトエンジニアリングのみを使用するモデルや、後に自動車特有のコードでファインチューニングのベースとして使用した Qwen3 32B のようなモデルが含まれています。 ソリューション この評価フェーズにおいて、柔軟なインフラストラクチャを用いてこれらの異なるモデル機能を統合するアーキテクチャの必要性が明らかになりました。アーキテクチャの概要は、以下の通りです： 図1：マルチモデル/マルチエージェント コードアシスタント アーキテクチャ AUMOVIO は、複数の拡張機能を備えた VS Code を標準の統合開発環境 (IDE) として採用しました。この既存の構成を基に、我々のアーキテクチャは Amazon Q Developer や Cline などのコーディング支援拡張機能を使用しています。 Amazon Q Developer は、開発者がアプリケーションを理解、構築、拡張、運用するのを支援する生成 AI アシスタントです。VS Code などの IDE で使用すると、Amazon Q はコードについてチャットし、インラインコード補完を提供し、新しいコードを生成し、セキュリティ脆弱性のためにコードをスキャンし、言語更新、デバッグ、最適化などのコードアップグレードと改善を行うことができます。Amazon Q Developer の推論とエージェント機能は、プレミアムモデルによってサポートされています。執筆時点では、Claude Sonnet 3.7 またはClaude Sonnet 4 で使用するように設定が可能でした。 同様に、オープンソースのプラグインの Cline は、IDE 内でエージェント型コードアシスタントのユースケースを実現するために、多くのエンドポイントをサポートしています。Cline は Claude Sonnet 3.7 や Claude Sonnet 4 など、 Amazon Bedrock でホストされているモデルで簡単に設定できます 。 さらに、このアーキテクチャは Model Context Protocol (MCP) を活用しています。MCP は、AI アシスタントが外部ツールやサービスと対話できるようにするオープン標準です。Cline と同様に、 Amazon Q Developer は MCP をサポートしており 、ユーザーはカスタムツールやサービスに接続することで Q の機能を拡張できます。我々のケースでは、ファインチューニングされたモデルを MCP エンドポイントとしてオーケストレーターモデルに公開しています。これにより、オーケストレーターモデルはユーザーから与えられたタスクの初期計画を行い、必要に応じてさらに情報を収集し、最終的に MCP プロトコルを介してファインチューニングされたモデルを呼び出すことができます。 以下は、図の番号付けに沿った Amazon Q Developer を使用した処理フローの例です： 1) 開発者は、 Amazon Q Developer が統合された VS Code に質問を送信します。 2) 基盤となるオーケストレーターモデルを使用して、Amazon Q Developer はタスクがメソッド生成に関するものであることを理解します。次に、オーケストレーターモデルは、関連するコードを生成するために一部の入力が不足していることを識別します。その後、Amazon Q Developer はさらなる入力 (不足している要件ドキュメントなど) を要求します。 3) 開発者とモデル間のメッセージ交換の後、Amazon Q Developer はすべての入力を収集します。次に、Amazon Q Developer は 「Method Generator 用 MCP クライアント」 を使用して、リクエストを Amazon API Gateway に転送します。Amazon API Gateway は、あらゆる規模で REST、HTTP、WebSocket API を作成、公開、維持、監視、保護するための AWS サービスです。 4) Amazon API Gateway は、クラウドネイティブ認証サービスである Amazon Cognito を使用してユーザーを認証します。 5) Amazon API Gateway は 「Method Generator」 AWS Lambda 関数 に委任します。これは、コードを実行するためのクラウドネイティブサーバーレスコンピューティングエンジンです。 6a) リモート MCP サーバーを立ち上げて、 「Method Generator」 Lambda 関数は Amazon Bedrock に推論リクエストを行います。Amazon Bedrock は、メソッド生成専用のファインチューニングされたモデルをホストしています。同様に、タスクがユニットテストの生成に関するものであれば、「Test Generator」が呼び出されます (6b)。 7) モデルからの応答は、AWS Lambda → API Gateway → MCP クライアントのパスを介して Amazon Q Developer に返され、ローカル IDE のコードを変更し、ユーザーに確認を求めます（読みやすさを向上させるため、図では番号付けが省略されています）。 別の処理フローでは、ユーザーが既存コードの説明を求める場合があります。この場合、オーケストレーターはタスクを処理するファインチューニングされたモデルがないと結論付け、独自の推論能力を使用して回答を提供します。 現在のソリューションの MCP エンドポイントは、単一のタスクを処理するモデルエンドポイントによってサポートされていることに注意してください。したがって、現在のイテレーションはマルチモデルですが、必ずしもマルチエージェントではありません。推論し、ツールを利用する唯一のエージェントはオーケストレーターモデルだからです。同時に、このアーキテクチャは MCP エンドポイントの背後に追加のエージェント(推論とオーケストレーション機能を持つ) の拡張をサポートしており、これによりマルチエージェントコーディングアシスタントが実現されます。 ファインチューニングの詳細 業界標準を考慮したドメイン特化型の自動車コードを生成するため、我々は人間が書いた高品質なコードで言語モデルをファインチューニングします。このセクションでは、ファインチューニングプロセスの詳細を説明します。 データの準備 効果的なモデルのファインチューニングの基盤は、高品質でドメイン特化型の学習用データです。我々は、生の自動車ソフトウェアリポジトリを、C/C++ コード生成に不可欠な豊富なコンテキストを保持する構造化された学習用データに変換する前処理パイプラインを構築しました。 前処理パイプラインは、AUMOVIO の C/C++ リポジトリを探索して、包括的なコンテキストとともに個々の関数を抽出することから始まります。このコンテキストには以下が含まれます： 関数ドキュメント： Doxygen スタイルのコメントとインラインドキュメントの両方が抽出され、対応する関数実装にリンクされます。 システム要件： パイプラインは DOORS が出力したXML ファイルを解析して、関数ドキュメントで言及されている要件識別子を完全な要件テキストにマッピングします。 アーキテクチャコンテキスト： ドキュメントで参照されている PlantUML 図が抽出され、挙動の仕様を提供するために含まれます。 API コンテキスト： 関連するヘッダーファイルとその関数シグネチャが収集され、利用可能な API とデータ構造に関する情報を提供します。 前処理を用いたアプローチの重要な工夫は、ヘッダーファイルと実装ファイルのインテリジェントな連携です。システムは各 C/C++ ソースファイルに対応するメインヘッダーファイルを識別し、含まれる依存関係から追加のコンテキストを抽出します。これにより、生成されたコードが既存の API を使用できることが保証されます。 # Example of context aggregation from the preprocessing pipeline def create_training_example(function_info): user_message = f"Implement the function: {function_info['signature']}\n\n" if function_info["documentation"]: user_message += f"with following specifications:\n{function_info['documentation']}" if function_info["requirements"]: user_message += f"\n\nRequirements tests:\n{function_info['requirements']}" if function_info["uml_diagram"]: user_message += f"\n\nThe behavior follows this UML diagram:\n{function_info['uml_diagram']}" return { "messages": [ {"role": "user", "content": user_message}, {"role": "assistant", "content": function_info["implementation"]}, 図2：抽出したコンテキストを集約するコード 前処理パイプラインは、いくつかの品質保証メカニズムも実装しています： 関数シグネチャの検証：ヘッダーファイルの宣言と照合することで、実装ファイルの関数シグネチャを自動的に修正します。 ドキュメントの完全性：包括的なドキュメントを持つ関数のみが学習用データセットに含まれます。 コードコンプライアンス：関数は、自動車の安全性とアーキテクチャパターンを含むカスタムルールセットに準拠しているか検証されます。 様々な複雑さを含むバランスの取れたコードを確保するため、前処理パイプラインは関数の長さと複雑さに基づく層別サンプリングを実装しています。このアプローチにより、一貫した分布特性を持つ学習用データセットとテスト用データセットが作成されます： # Stratified sampling ensures balanced complexity distribution stats = stratified_sample_jsonl( input_file="dataset-7037-funcs.jsonl", sampled_file="test-set-funcs.jsonl", remaining_file="train-set-funcs.jsonl", sample_size=1000, num_strata=5, ) 図3：層別学習用データサンプルの生成 結果として得られたデータセットには、完全なコンテキスト情報を含む約 7,000 の高品質な関数実装が含まれており、複雑さの分布を維持しながら学習用データセットとテスト用データセットに分割されています。 ファインチューニング ファインチューニングを用いたアプローチは、自動車ソフトウェア開発の計算リソース制約と精度要件に最適化された最先端の技術を活用しています。 プロジェクトチームは、コード生成タスクでの優れたパフォーマンスと適度な計算リソース要件から、Qwen3-32B をベースモデルとして選択しました。ファインチューニングプロセスは、モデルの一般的な能力を維持しながら効率的な学習を実現するために、Low-Rank Adaptation (LoRA) を採用しています： LoRA設定: アテンション層とフィードフォワード層に適用されるランク 8 アダプター (alpha=16) 量子化: BitsAndBytes を使用した 4 ビット量子化によりメモリ使用量を削減 ターゲットモジュール: クエリ、キー、バリュー、出力プロジェクション層に加えて、すべてのフィードフォワードネットワークコンポーネントに LoRA アダプターを適用 ファインチューニングでは、 Amazon SageMaker の分散学習機能と PyTorch DeepSpeed を利用しており、自動車コードベースでの大規模モデル学習の計算リソースの要件を満たすように特別に設計されています。我々は、 SageMaker の remote デコレーター を使用して、単一インスタンス内の複数の GPU 間で分散学習を構成し、マルチノード構成へのスケーリングのためのサポートを備えています。 @remote( instance_type="ml.p4d.24xlarge", volume_size=100, use_torchrun=True, pre_execution_commands=[ "pip install torch==2.5.1 transformers==4.51.3", "pip install peft==0.15.2 deepspeed bitsandbytes", ] ) def train_model(train_dataset, test_dataset, config): # Adaptive DeepSpeed configuration based on quantization settings stage = 2 if use_quantization else 3 deepspeed_config = { "zero_optimization": { "stage": stage, "overlap_comm": True, "contiguous_gradients": True, "offload_optimizer": {"device": "cpu", "pin_memory": True} } } if stage == 3: deepspeed_config["zero_optimization"].update({ "offload_param": {"device": "cpu", "pin_memory": True}, "stage3_prefetch_bucket_size": 1e6, "stage3_param_persistence_threshold": 1e4, }) # Training implementation... 図4: SageMaker のremoteデコレーターを介した LLM の学習 学習用のインフラストラクチャは、いくつかの重要な最適化を実装しています： 適応型メモリ管理: システムは、学習の設定に基づいて DeepSpeed ZeRO-2 と ZeRO-3 の最適化ステージの両方を採用しています。量子化を使用する場合、ZeRO-2 は4ビット量子化モデルとの互換性が優れているため優先され、モデルパラメータを複製したままオプティマイザの状態を GPU 間で分割します。フル精度学習シナリオの場合、システムは自動的に ZeRO-3 に切り替わり、モデルパラメータをデバイス間でさらに分割し、アクティブに必要とされない場合は CPU メモリにオフロードします。この適応型アプローチにより、限られた GPU メモリでも 320 億パラメータのフルモデルの学習が可能になり、各設定で最適なパフォーマンスを維持します。 高度なパラメータ管理: ZeRO-3のパラメータ分割機能により、包括的な関数ドキュメントや要件トレーサビリティに必要な大規模なコンテキストウィンドウの処理が可能になります。バケットサイズとパラメータ永続化の閾値を調整することで、過度な通信オーバーヘッドを発生させることなく、効率的なパラメータストリーミングを実現しています。 通信最適化: 分散セットアップでは、NVIDIA Collective Communication Library（NCCL）を使用し、最適化されたタイムアウト設定と通信オーバーラップにより、コード生成モデル特有の大規模かつ密な勾配を処理します。 耐障害性と信頼性: 長時間の学習を考慮し、インフラストラクチャには、モデルダウンロード時のエクスポネンシャルバックオフを用いた堅牢なエラーハンドリングと、一時的なハードウェア障害に対する自動リトライ機構を組み込んでいます。また、システムは中断時に最後に保存された状態から学習を再開するチェックポイント復旧機能を実装しており、ZeRO-3のパラメータ分割により、より細かい粒度でのチェックポイント戦略が可能になっています。 動的リソース割り当て: Amazon SageMaker 統合により、学習の計算負荷に基づく動的スケーリングが可能になり、学習の計算負荷がピークに達した時に追加の計算リソースを自動的にプロビジョニングする機能があります。 分散学習のセットアップは、安定した収束を維持しながら、すべてのデバイスで約 85% の GPU 使用率を達成し、AUMOVIO が効率的なリソース使用を通じてクラウドコンピューティングコストを最適化しながら、開発スプリントの時間軸でファインチューニングサイクルを完了できるようにしています。 学習完了後のモデルは、 Amazon Bedrock のカスタムモデルインポート機能 を通じてデプロイメント用にパッケージ化され、前述のマルチモデルアーキテクチャとのシームレスな統合が可能になります。ファインチューニングされたモデルは、IDE 統合に必要な会話能力を維持しながら、ドメイン特化型の精度で大幅な改善を達成しています。 評価結果 MCP エンドポイントとしてデプロイされたさまざまなコード生成モデルの有効性を評価するため、C と C++ の両方のコード生成に焦点を当てた包括的な評価を実施しました。このセクションでは、評価方法論と主要な結果について詳しく説明します。 図5：コンプライアンスとレイテンシに関するさまざまなモデルの評価 この表は、ファインチューニングされたモデルと汎用モデルなどさまざまなベースモデルと、人間が作成したコードを比較しています。我々は、プロンプトエンジニアリング (PE) とファインチューニング (FT) 戦略に焦点を当て、複数の評価指標を使用しています： カスタム自動車コーディングルールへの適合性: 正規表現ベースのカスタムビルド静的アナライザーを用いて測定 (関数あたりの平均エラー数で測定) カスタム自動車アーキテクチャルールへの適合性: 正規表現ベースのカスタムビルド静的アナライザーを用いて測定 (関数あたりの平均エラー数で測定) コード生成レイテンシ: 関数あたりの平均秒数 結果は興味深いパターンを示しています。 Qwen3 32B (PE) のような PE 重視のモデルは、C 言語 において Automotive Architecture Checker 準拠スコアで平均 1.22 の違反、Automotive Coding Checker 準拠スコアで 0.54 を示す強力な C コード 品質スコアを達成しましたが、FT 強化バージョンは C++ 生成で競争力のある結果を示しました。特に、Qwen3 32B – V2 (FT) は、C++ において優れた Automotive Architecture Checker 準拠スコア (0.02) と堅実な Automotive Coding Checker 準拠スコア (1.25) を達成し、ファインチューニングとプロンプトエンジニアリングを組み合わせる利点を示しています。 この結果は、MCP を通じて複数のコード生成モデルへの柔軟なアクセスを持つことの戦略的優位性を示しています。それぞれのモデルは異なるシナリオで優れた性能を示します: Nova Pro は 優れた C 準拠スコアと14.62 秒のレイテンシで迅速な生成を提供し、素早いプロトタイピングと C 重視の開発に理想的です。一方、Qwen3 32B 由来のモデルは優れた C++ 準拠スコアを示しています。PE と FT アプローチ間のシームレスな切り替えが可能なため、さらに最適化が可能です。開発者は、プロンプトのカスタマイズが鍵となる単純な API 実装に PE モデルを利用できます。より複雑な C++ コード生成の場合、学習されたパターンがより有益なので、 FT モデルに切り替えることができます。この柔軟性は、各モデルのコストパフォーマンスのトレードオフと組み合わせることで、開発チームがプロジェクト固有の要件に基づいてコード生成を調整できるようにします。 これらのコードの品質改善と標準への準拠は、SDV の複雑性の増大に追随しながらコード品質を維持するという冒頭で述べた課題に直接的に対処しています。 「 AUMOVIO のエンジニアリングアシスタントは、顕著に高速な開発サイクルとコード品質の向上を実現しながら、SDV の複雑化に対応するのに役立っています。このアシスタントは、開発スピードを犠牲にすることなく自動車業界の標準に準拠することが可能です。これはまさに、今日の競争の激しい自動車市場で我々が必要としていたものです。」 – Amir Namazi, AUMOVIO バーチャライゼーション クラウド & AI ソリューションマネージャー まとめ この最初のイテレーションで、AUMOVIO はコード生成のためのファインチューニングされたモデルを利用して高度に特化したコーディングアシスタントを開発しました。今後、AUMOVIO はコーディングアシスタントのイテレーションを続け、V 字モデル開発プロセスのさまざまな工程をより効果的にサポートするために機能を拡張していきます。この取り組みをさらに促進するため、AUMOVIO は、現在の構成のエージェント型コーディングアシスタント機能とともに、V 字モデルライフサイクルの複数の工程をカバーする 仕様駆動開発 をサポートする Kiro に徐々に移行しています。単体テスト生成は引き続き重要な関心領域ですが、AUMOVIO のより大きな目標は、このツールをAUMOVIO 社内チームと外部パートナーの両方に利益をもたらす統合された製品グレードのオファリングに進化させることです。長期的なビジョンとしては、特化したモデルとオーケストレーターが開発ライフサイクル全体でシームレスに連携するマルチエージェントフレームワークへの移行を目指しています。 詳細については、 AWS for automotive および Manufacturing ページをご覧いただくか、今すぐ AWS にお問い合わせください。 Levent Kent Levent Kent は、アマゾンウェブサービス (AWS) のシニア生成 AI ソリューションアーキテクトです。銀行、教育、ヘルスケアから自動車、製造に至るまで、さまざまな分野で 14 年以上にわたるサービス提供経験とアーキテクチャの専門知識を有します。現在は、自動車や製造業のお客様とのコラボレーションを通じて、スケーラブルで革新的な生成 AI ソリューションの設計と構築を支援することで成功を収めています。空き時間には、友達と踊ったり歌ったりするのが好きです。 Aiham Taleb, PhD Aiham Taleb, PhDは、Generative AI Innovation Centerのシニアアプライドサイエンティストとして、AWS の顧客と直接協力し、複数の重要なユースケースにわたって生成AIを活用しています。Aiham は教師なし表現学習の博士号を持ち、コンピュータビジョン、自然言語処理、医用画像処理など、様々な機械学習アプリケーションにわたる業界経験を有しています。 Amir Mahdi Namazi Amir は、AUMOVIO における高性能コンピュータ (HPC) 向けの仮想化、クラウド、および AI のソリューションマネージャー兼プロジェクトリーダーです。彼は TH Köln で工学とコンピュータサイエンス、および産業工学の学士号を、OTH Regensburg で機械工学の学位を取得しています。Amir は2017年に Continental にデータアナリストとして入社し、旧パワートレイン部門で NOx センサーに関する業務に従事しました。2019年にはソフトウェアエンジニアとなり、AUTOSAR Classic と Engine Control Units に注力しました。2020年以降、Amir は ANS PL1 において HPC のソフトウェアアーキテクトの職に就き、2023年からは現在の役職に就いています。 Brian Jensen Brian Jensen は、AWS Generative AI Innovation Center のアプライドサイエンスマネージャーで、15年の経験を持っています。彼は、アイデア創出からプロトタイプ、そして本番環境まで、革新的な生成 AI の顧客エンゲージメントの提供を主導し、製造業、旅行・運輸、金融サービス、自動車産業など、様々なセクターにわたって高価値の成果を推進しています。Brian は、コンピュータビジョン、ロボティクス、時系列予測、医用画像処理など、多様な機械学習アプリケーションにおける豊富な専門知識を有しています。 Daniel Schleicher Daniel Schleicher は、Continental を担当する AWS のシニアソリューションアーキテクトで、SDVに注力しています。この分野において、彼は自動車アプリケーションへのクラウドコンピューティング原則の適用と、仮想化ハードウェアを活用した自動車アプリケーションのソフトウェア開発プロセスの進化に関心を持っています。以前の役職では、Daniel は Volkswagen においてエンタープライズ統合プラットフォームの AWS への移行を主導し、プロダクトマネージャーとして、Mercedes Intelligent Cloud の中核サービスの構築に貢献しました。 Kim Robins Kim Robins は、AWS の Generative AI Innovation Center のシニア AI ストラテジストです。彼は、人工知能と機械学習における豊富な専門知識を活用し、組織が革新的な製品を開発し、AI 戦略を洗練させることを支援し、目に見えるビジネス価値を創出しています。 Liza (Elizaveta) Zinovyeva Liza (Elizaveta) Zinovyeva は、AWS Generative AI Innovation Center のアプライドサイエンティストで、ベルリンを拠点としています。彼女は、さまざまな業界の顧客が生成 AI を既存のアプリケーションやワークフローに統合するのを支援しています。AI/ML、金融、ソフトウェアセキュリティのトピックに情熱を持っています。余暇には、家族との時間、スポーツ、新しい技術の学習、クイズを楽しんでいます。 Martin Kraus Martin Krausは、AUMOVIOでハイパフォーマンスコンピュータ（HPC）のDevOps組織を率いており、CI/CD/CT、AI、仮想化のトピックをカバーしています。彼は世界中のすべての HPC プロジェクトの効率的な開発セットアップに責任を持っています。自動車ソフトウェアプロジェクトのリーダーとして15年以上の経験があり、AUMOVIOをより速く効率的な開発へと変革することに情熱を注いでいます。 Nikita Kozodozi, PhD Nikita Kozodozi, PhDは、AWS Generative AI Innovation Centerのシニアアプライドサイエンティストで、AI 研究とビジネスの最前線で活動しています。Nikita は、業界を超えた AWS の顧客の実際のビジネス課題を解決するための生成 AI ソリューションを構築しています。Nikita は機械学習の博士号を保有しています。 Samer Odeh Samer Odehは、AWS のテクニカルアカウントマネージャーで、自動車業界の顧客サポートを専門としています。IT およびクラウド技術において15年以上の経験を有します。Samerは自動車企業が AWS インフラストラクチャを最適化し、クラウドサービスを活用してソフトウェア定義車両（SDV）のイノベーションを推進することに注力しています。Samer の専門分野は、クラウドアーキテクチャ、DevOps プラクティス、コネクテッドカーソリューションのための戦略的IT計画です。Samer は、自動車組織が運用の卓越性を達成し、AWS サービス、特に SDV 開発と展開の領域を活用してデジタルトランスフォーメーションを加速することに情熱を注いでいます。 本記事は Solutions Architect の坂本 和穂 が翻訳しました。

本記事は、大学・研究機関の研究者、R&Dディレクター、ラボマネージャー、そして研究のデジタル化やAI活用を検討されている科学技術系のリーダーの方々に向けて書かれています。 文部科学省は 2026 年 4 月、「 AI for Scienceによる科学研究革新プログラム ( SPReAD ) 」の公募を開始しました。本事業は、あらゆる分野の研究者がAIを活用して科学研究の高度化・加速化を図れるよう、萌芽的・探索的な研究を支援するものです。1 課題あたり 500 万円以下の補助で計 1,000 件程度の採択が予定されており、計算資源やデータ整備、 API 利用料なども対象経費に含まれます。 AWS のクラウドサービスは、こうした研究に必要な計算基盤や AI サービスを柔軟に提供できる環境として、多くの研究者に活用されています。 AI for Science は将来的な可能性ではなく、すでに研究現場での活用が進みつつあるテーマとなっています。本記事では、各研究領域で具体的に何が起きているのかをユースケース中心にお伝えし、ご自身の研究に AI をどう取り入れるかを考えるきっかけとしていただければ幸いです。   1. タンパク質構造予測がノーベル賞を受賞した意味 〜 研究の現場で起きていること 2024 年、 AI を活用したタンパク質研究にノーベル化学賞が授与されました。AI モデルによるタンパク質の立体構造予測 – 分子生物学において「 50 年来の夢」と呼ばれてきた課題を、AIが解き明かしたのです。この出来事が示しているのは、AI が研究の効率化ツールにとどまらないということです。AI は、人間の研究者が数十年かけても到達できなかった科学的発見を、まったく新しいアプローチで実現する力を持っています。そしてこの力は、創薬、材料科学、ゲノミクス、気候科学、素粒子物理学といったあらゆる科学領域に広がり始めています。 すなわち、AI for Science が「使える技術」になったと考えています。背景として、3つの潮流があると考えています。 ひとつは、AI 自体の成熟です。基盤モデル、マルチモーダル学習 ( 画像、音、テキストなど異なる種類の情報をまとめて扱った学習 / モデル開発 ) 、エージェント AI などが、研究の現場で実用に耐えるレベルに達しました。２つ目は、フィジカル AI の台頭です。ロボットやセンサーに組み込まれた知能が、実験室の中で自律的に動作するようになりました。そして、３つ目ですが、クラウドコンピューティングの普及です。大規模なデータ処理、柔軟に拡張できる GPU 環境、国境を越えた共同研究基盤が、個々の研究室でも手の届くものになりました。 これら、６つの領域から事例をご紹介したいと思います。 1-1. 創薬：分子設計から臨床試験まで、パイプライン全体が変わる 創薬研究は、AI の恩恵を最も早く、最も深く受けている領域のひとつです。生成モデルを使った新規分子設計 ( de novo分子設計 ) では、特定の標的に最適化された新しい分子構造の候補を数時間で数千個生成できるようになりました。従来、化学者が経験と直感に頼って行っていた作業を、AIが広大な化学空間の中から最適解を探索する形で補っています。薬の体内での吸収・分布・代謝・排泄・毒性 ( ADMET )をパイプラインの早い段階で予測することで、後期臨床試験での失敗——最もコストのかかる失敗——を未然に防ぐアプローチも広がっています。 AI によるタンパク質と薬剤候補の結合予測は、両者がどれだけ強く結びつくかを高い精度で予測し、コンピュータ上で数十億の化合物を評価できます。実験室のリソースを、本当に有望な候補に集中させることが可能になるのです。 1-2. ゲノミクス：生命の設計図を読み解く ゲノミクス分野では、ディープラーニングによる遺伝子配列の解析が、変異の特定やパターン認識を大幅に加速しています。AlphaFold に代表されるタンパク質構造予測モデルは、アミノ酸の配列情報から立体構造を予測し、構造に基づく創薬設計の新たな道を切り拓きました。 注目すべきは、複数の生体データを統合する「マルチオミクス」の進展です。遺伝子、RNA、タンパク質、代謝物のデータを組み合わせて解析することで、病気のメカニズムの全体像を捉えることが可能になりつつあります。個人の遺伝子情報に基づくオーダーメイド医療の構築も、概念実証の段階を超え、実用化に向けて動き出しています ( 出典： AWS ゲノミクスソリューション ) 。 1-3. 材料科学：試行錯誤から、AI による逆設計へ 新材料の発見は、従来の試行錯誤では膨大な時間とコストを要しました。AI はこのプロセスを根本から変えつつあります。広大な化学空間を効率的に探索し、安定性や効率性に優れた新材料の候補を見つけ出す。硬さ、導電性といった材料の性質を機械学習モデルで予測する。さらに、「こういう性質を持つ材料が欲しい」という要求から逆算して材料を設計する「逆設計」も実現しつつあります。 AI とロボティクスを組み合わせた自律実験室では、材料の合成から性能評価までを 24 時間体制で自動化し、実験にかかる時間を桁違いに短縮しています。 1-4. 化学：合成経路の自動設計と自律実験 化学の分野では、ディープラーニングが反応の結果、収率、条件の予測を高い精度で実現しています。複雑な分子の合成経路を自動設計する AI は、数百万の候補ステップの中から最も効率的なルートを見つけ出し、危険な中間体を避けながらコストと収率を最適化します。 産業向けの新しい触媒の設計も加速しており、AI モデルとロボットを組み合わせた自律実験室では、実験の設計から実行、結果の評価、次の実験計画までを人手を介さずに行えるようになっています。 1-5. 気候科学：地球規模の課題に AI で挑む 気候変動への対応は、科学研究の中でも最も緊急性の高いテーマです。AI技術による高解像度の気候モデルは、地球全体の気候予測を地域レベルに落とし込み、地域ごとの適応策の立案を支援します。衛星やセンサーのデータをディープラーニングで分析する極端気象の予測は、従来より早い段階で、より高い精度で警報を出せるようになっています。 CO2 の回収・貯留 ( CCS )では、AIが吸着材の設計や貯留場所のシミュレーションを最適化し、エネルギー消費の低減に貢献しています。大量の衛星画像をほぼリアルタイムで分析する技術は、森林破壊の監視、生物多様性の追跡、カーボンオフセットの検証といった用途に活用されています (出典： AWS 地球観測 ) 。 1-6. 物理学：量子シミュレーションから核融合制御まで 物理学の最前線でも、AIは欠かせない存在になりつつあります。AI を活用した量子シミュレーションは、従来のコンピュータでは困難だった計算のボトルネックを克服し、波動関数の計算や量子状態の予測を高速化しています。LHC などの高エネルギー物理実験では、ディープラーニングが膨大な衝突データから珍しい粒子の反応をリアルタイムで選び出しています。 特に注目されているのが、強化学習によるトカマク型核融合炉の制御です。磁気コイルをリアルタイムで制御してプラズマの安定性を保ち、装置の損傷につながる不安定現象を防止 – 核融合エネルギーの実用化に向けた重要な技術的進展です。   2. AWS を活用して AI for Science を実践している先駆者たちの研究事例 ここでは、AI for Science を実践している 4 つの先進事例を紹介します。それぞれの研究がなぜ重要なのか、そして AI がどのような役割を果たしているのかについて説明したいと思います。 2-1. Genomics England — AI で遺伝子診断の精度を高める なぜ重要か： 希少疾患の患者にとって、正確な遺伝子診断は治療への第一歩です。しかし、一人の患者あたり数百万に及ぶ遺伝子変異を評価し、膨大な科学論文から関連するエビデンスを見つけ出すことは、人間の力だけでは限界があります。 AI の役割： Genomics England は、AWS 上に構築した基盤で機械学習を活用した文献分析を導入しました。その結果、人間のキュレーターが見落としていたエビデンスが発見され、複数の遺伝子が新たに診断レベルに昇格しました。従来は何年もかかったであろう成果が、数か月で実現したのです ( 出典 : Genomics England AWSカスタマーストーリー 、 AWS AIブログ：ゲノミクス変異解釈の加速 ) 。 2-2. Allen Institute for Brain Science — 世界最大の脳地図をつくる なぜ重要か： アルツハイマー病やパーキンソン病といった脳の病気を理解し治療するためには、まず脳そのものの構造を詳細に知る必要があります。Allen Instituteは、人間の脳全体を細胞レベルで地図化するという壮大なプロジェクトに取り組んでいます。 AIの役割： Allen Institute は、AWS 上に「Brain Knowledge Platform ( BKP ) 」を構築しました。高性能コンピューティングと生成AIを組み合わせることで、従来は数週間かかっていたデータ処理パイプラインを1日で実行できるようになり、扱えるデータセットの規模は1,000倍に拡大しました。世界中の 1,000 以上の研究機関がこのプラットフォームを通じてオープンデータにアクセスし、脳科学の発見を加速しています ( 出典： Allen Institute カスタマーストーリー 、 Allen Institute：ヒト脳マッピング 、 Allen Brain Observatory オープンデータセット ) 。 2-3. LILA Sciences — AI が仮説を立て、実験を実行する なぜ重要か： 科学研究のボトルネックのひとつは、仮説の立案から実験の設計・実行までに多くの時間と人手がかかることです。もし AI がこのプロセスを自律的に行えるようになれば、発見のスピードは飛躍的に向上します。 AIの役割： LILA Sciencesは「AI Science Factory」という新しい研究の仕組みを構築しています。AI が自ら仮説を提案し、実験を設計・実行する。大規模な推論処理をAWSの計算基盤上で実行し、発見の規模と速度を大幅に引き上げています。研究者がAIと協働して科学的発見を生み出す——その未来の姿を、今まさに体現しているプロジェクトです ( 出典 :  LILA Sciences AWSカスタマーストーリー 、 LILA Sciences 紹介動画 ) 。 2-4. University of Arizona — 「1週間の調査が1回の検索に」 なぜ重要か： 研究者にとって、自分の研究テーマに関連する知見や共同研究の相手を見つけることは、成果を左右する重要な活動です。しかし、膨大な論文や研究者情報の中から適切な情報を探し出すには、多大な時間がかかります。 AIの役割： University of Arizona が開発した「KMap」は、年間 41,000 人以上が利用するAI搭載の研究コラボレーション基盤です。大規模言語モデル ( LLM )が研究者の関心を自動的に把握し、質問に対してエビデンスに基づいた回答を返します。ある研究者は「1週間分の手動調査が1回の検索で済んだ」と語っています。分野を越えた共同研究チームの形成を促すこの仕組みは、AIがもたらすネットワーク効果の好例です ( 出典 : AWS パブリックセクター blog University of Arisona  KMap ) 。   3. AWSが支えるAI for Scienceの技術基盤/サービス ここまで紹介してきたユースケースや事例の多くは、AWS のクラウドインフラ上で実現されています。それは、AI for Science が求める「大規模な計算資源」「多様な基盤モデルへのアクセス」「研究データの安全な管理」「グローバルな共同研究基盤」のすべてを、AWS が包括的に提供しているからです。ここでは、前半で紹介した研究領域の具体的な課題と、それを解決する AWS サービスの対応関係を見ていきます。 3-1. 仮説生成・文献レビュー — Amazon Bedrock と基盤モデル 創薬研究者が数百万の論文から新たな標的を探索する、ゲノミクス研究者が複数の生体データの中からパターンを発見する——こうした仮説生成の場面で中核となるのが Amazon Bedrock です。Claude、Llama、Amazon Nova / Titanといった主要基盤モデルに単一のAPIからアクセスでき、サーバーレスで即座に利用を開始できます。Amazon Bedrock は東京リージョン ( ap-northeast-1 ) で利用可能なため、研究データを国内に保持したまま基盤モデルを活用できます。Genomics England が膨大な論文の壁を突破した文献分析も、こうした基盤モデルの推論能力があってこそ実現しました。 さらに、 Amazon SageMaker AI によるファインチューニングや継続的事前学習を通じて、特定の研究領域に特化したモデルを構築することも可能です。たとえば、化学反応の収率予測や材料特性の予測といった専門的な課題では、汎用モデルでは捉えきれない知見を自分たちの実験データで引き出すことが、研究の差別化につながります。 3-2. 実験設計・シミュレーション — HPC と AI コンピュート 材料科学の逆設計、気候モデルの高解像度化、量子シミュレーション、核融合炉のプラズマ制御——これらはいずれも膨大な計算資源を必要とします。AWS TrainiumとInferentia チップによる高性能な学習・推論インフラは、大規模モデルの開発と実行を高速・低コストで支えます。NVIDIA H100 GPU クラスタとElastic Fabric Adapter ( EFA ) による密結合 HPC クラスタは、分子動力学シミュレーションや気候モデリングといった計算集約型の研究に対応します。 Allen Institute が AWS 上で Brain Knowledge Platform を構築し、データ処理を数週間から1日に短縮できたのも、このスケーラブルな HPC インフラがあったからです。LILA Sciences が大規模な推論処理を実行する「AI Science Factory」も、AWS の計算基盤上で稼働しています。 Amazon SageMaker HyperPod を使えば、大規模モデルのゼロからの学習も、インフラ管理の負担なく実行できます。 3-3. 科学文書インテリジェンス — 眠っているデータの活用 研究機関に眠る膨大な非構造化データ——論文、ラボノート、実験記録——を活用するための技術も、AWS の強みです。 Amazon Textract はスキャンされた科学文書からテキスト、手書き文字、表データを自動で読み取り、研究論文特有の複雑なレイアウトにも対応します。 Amazon Comprehend のカスタムエンティティ認識を活用すれば、化学物質名、タンパク質、投与量といった科学用語の認識や関係性の抽出を行えます。 これらを統合的な知識基盤として構築し、 RAG ( 検索拡張生成 ) と組み合わせれば、数百万の文書を横断的に検索し、出典付きのエビデンスに基づいた回答を得ることが可能です。アリゾナ大学の KMap が「1週間分の手動調査を1回の検索に」短縮できたのは、まさにこの RAG の実践例です。 助成金申請の効率化に向けては、AWS とノースカロライナ大学の研究者が共同で開発したプロトタイプ「GROW ( Grant Writing Opportunity Wizard ) 」が注目されています。 Amazon Bedrockのエージェント技術 を活用し、研究者の専門性と利用可能な助成金を自動的にマッチングする仕組みで、GitHubで オープンソースとして公開 されています。研究者が業務時間の42%を費やしているとされる事務作業 ( 出典： FDP Faculty Burden Survey ) の負担を軽減する取り組みとして、今後の発展が期待されます。 3-4. データ基盤 — 研究データを戦略的な資産に AI for Science の成功は、データ基盤の質にかかっています。 Amazon S3 を中核としたストレージ基盤は、ゲノミクスの大規模な配列データから、気候科学の衛星画像、化学の分光データまで、あらゆる研究データを安全かつ柔軟に管理します。 AWS Glue Data Catalog によるデータの整理、 Amazon Athena によるサーバーレスでの検索、 Amazon Quick による可視化まで、一貫した基盤上でデータの価値を引き出せます。 Amazon Quick も東京リージョンで利用可能なため、研究データを国内に保持したまま分析・可視化を行うことができます。 Open Data on AWS では、300PB 以上の公開データセット——1000 Genomes Project、The Cancer Genome Atlas、Landsat 8、SpaceNetなど——に無料でアクセスできます。創薬研究者がゲノムデータベースを参照する、気候科学者が衛星画像を分析する、材料科学者が結晶構造データを探索する——いずれの場面でも、データ取得のコストと時間を削減し、分析そのものに集中できる環境です。 3-5. データセキュリティと知的財産の保護 研究データの保護は、AI for Science において最も重要な課題のひとつです。特に創薬研究における分子構造データや、ゲノミクスにおける患者由来データなど、知的財産や個人情報を含むデータを扱う場面では、セキュリティへの信頼が欠かせません。 ここで明確にしておくべきことがあります。 Amazon Bedrockでは、お客様のデータは基盤モデルの学習に一切使用しません。また、Anthropic等のサードパーティのモデルプロバイダーを利用した場合においても、モデルプロバイダーにデータは共有されません。 データは AWS Key Management Service ( KMS )  による保存時暗号化とTLS 1.2+による転送時暗号化で保護され、 IAM によるきめ細かなアクセス制御が可能です。 AWS PrivateLink を使えば、パブリックインターネットを経由せずにプライベート接続できます。そして、多くのAWSサービスにおいて、国内にデータを保持することが可能です。 3-6. AIの倫理とガバナンス AI for Scienceの推進にあたっては、技術的な能力だけでなく、AIの倫理的な利用とガバナンスの確保も重要です。研究の再現性、データの公正な取り扱い、AIが出す結果の説明可能性——これらは科学研究の信頼性を支える基盤です。 AWSは、制御可能性、プライバシーとセキュリティ、安全性、公平性、正確性と堅牢性、説明可能性、透明性、ガバナンスという8つの観点からなる 責任あるAIフレームワーク を提供しています。 Amazon Bedrock Guardrails による不適切な出力の防止や、 AWS CloudTrail による詳細な操作ログの記録を活用することで、研究の科学的厳密性を守りながらAIを活用するための仕組みが整っています。知的財産の漏洩リスクを心配することなく、安心してAIを研究に取り入れることができます。   4. 始めるなら、今 AI for Science の導入は、大きな投資や大がかりな体制づくりから始める必要はありません。 まず、ご自身の研究の中で、AI が役立ちそうな場面を見つけてください。文献レビューの効率化、繰り返しの多い分析作業の自動化、候補物質の絞り込みの高速化など、AIによって研究が具体的に前進する課題はどこにあるでしょうか。 次に、今の研究環境を振り返ってみましょう。手元のデータは十分に整理されているか、チームにはどのような知識や経験が足りないか。この振り返りが、具体的な計画を立てる出発点になります。 そして、小さく始めてください。8〜12 週間ほどの短期間で、テーマを絞った試験的な取り組み ( PoC )を行い、AI が実際に役立つかどうかを確かめます。AWSのマネージドサービスを活用すれば、インフラの構築や運用にかかる手間を最小限に抑えられます。手応えが得られたら、運用ルールや評価指標を整えながら、段階的に活用の範囲を広げていきましょう。 AWS では、研究者の方々が AI for Science を始めるための具体的な支援を用意しています。 短時間の相談会： 研究の進め方を整理し、AIが活用できそうなテーマを一緒に特定します 導入支援サポート： 文献検索の自動化や実験プロトコルの生成など、具体的なテーマで技術的な実現可能性を検証します。経験豊富なパートナーも紹介できます 生成AIイノベーションセンター ： 1億ドルの投資に裏打ちされた専門チームが、モデルの選定や研究への適用方法について助言します 文部科学省 SPReAD事業への応募 に関する支援： 計算資源やAPI利用料も対象経費に含まれており、AWSのクラウドサービスの利用費用も申請可能です。第1回公募は2026 年 5 月 18 日 ( 月 ) 正午締切です ( 第 2 回は 6 月上旬予定 ) ご関心をお持ちの方は、 AWSの担当チーム までお気軽にお問い合わせください。 次の科学的ブレークスルーは、AIとの協働から生まれます。   アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター技術統括本部長 瀧澤 与一 / Yoichi Takizawa

私は 4 月 13 日週、 University of Namur (uNamur) の 2025 年度の卒業式で祝辞を述べるという光栄な機会をいただきました。 私は卒業したばかりのコンピュータサイエンス専攻の学生たちの前に立ち、AI 時代のソフトウェア開発の未来について語りました。私のメッセージは次のようにシンプルなものでした: AI によって皆さんのスキルが時代遅れになるということはありません。ツールはパンチカードから、IDE、そして AI 支援コーディングへと、数十年をかけて進化してきましたが、作業はツールではなく、人々のものであり続けています。成功するデベロッパーは、好奇心を持ち続け、システム思考をし、正確なコミュニケーションを取り、自分が構築したものに責任を持つ人たちです。世界はコーディングスキルを持つ人材を、減らすのではなく、 さらに増やす 必要があります。AI は私たちが達成できることについての水準を引き上げてくれます。そして、それはすばらしいことです。 それでは、4 月 20 日週の AWS ニュースを見ていきましょう。 ヘッドライン Anthropic の Claude Opus 4.7 が Amazon Bedrock で利用可能に – Anthropic の最もインテリジェントな Opus モデルが Amazon Bedrock で利用可能になりました。コーディング、長時間実行エージェント、専門的な知識作業におけるパフォーマンスが改善しています。Claude Opus 4.7 は、SWE-bench Pro で 64.3%、SWE-bench Verified で 87.6% のスコアを獲得し、より強力な長期自律性と複雑なコード推論によって、エージェンティックコーディングにおける優位性をさらに強化しました。また、文書作成、財務分析、複数ステップの調査などの知識作業タスクにおいても、より優れたパフォーマンスを発揮します。 このモデルは、動的なキャパシティ割り当て、適応型思考 (リクエストの複雑さに基づいて Claude が思考トークン予算を割り当てられるようにする機能)、および 100 万トークンのフルコンテキストウィンドウを備えた Bedrock の次世代推論エンジン上で動作します。さらに、チャート、高密度ドキュメント、画面 UI における精度を向上させるために、高解像度画像のサポートも追加されました。Claude Opus 4.7 は、米国東部 (バージニア北部)、アジアパシフィック (東京)、欧州 (アイルランド)、欧州 (ストックホルム) でリリースと同時に利用可能となり、各リージョンでアカウントあたり最大 10,000 件のリクエスト/分まで対応できます。 AWS Interconnect の一般提供が開始され、ラストマイル接続を簡素化する新しいオプションが追加 – AWS Interconnect では、2 つのマネージドプライベート接続機能の一般提供が開始されました。1 つ目は AWS Interconnect – Multicloud です。これは、AWS VPC と他のクラウドプロバイダー (Google Cloud は現在利用可能であり、Azure と OCI は 2026 年以降に利用可能となる予定です) 間のレイヤー 3 プライベート接続を提供します。トラフィックは、AWS グローバルバックボーンとパートナークラウドのプライベートネットワークを経由して流れ、パブリックインターネットを経由することはなく、MACsec 暗号化、マルチファシリティの回復力、CloudWatch モニタリングが組み込まれています。AWS は、基盤となる仕様を Apache 2.0 で GitHub に公開しているため、どのクラウドプロバイダーでも Interconnect パートナーになることができます。 2 つ目の機能である AWS Interconnect – Last Mile は、既存のネットワークプロバイダーを通じて、支店、データセンター、リモート拠点から AWS への高速プライベート接続を簡素化します。2 つの物理拠点に 4 つの冗長接続を自動的にプロビジョニングし、BGP ルーティングを設定して、MACsec 暗号化と Jumbo Frames をデフォルトでアクティブ化します。また、再プロビジョニングなしでコンソールから調整可能な 1～100 Gbps の帯域幅を提供します。Last Mile は、米国東部 (バージニア北部) で Lumen を最初のパートナーとしてリリースされます。  4 月 13 日週のリリース  4 月 13 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: Amazon ECR のプルスルーキャッシュがリファラーの検出と同期のサポートを開始 – ECR のプルスルーキャッシュは、アップストリームレジストリから OCI リファラー (イメージ署名、SBOM、アテステーション) を自動的に検出し、プライベートリポジトリに同期するようになりました。これは、エンドツーエンドのイメージ署名検証と SBOM 検出ワークフローが、クライアント側の回避策なしで機能することを意味します。 AWS Transform が Kiro と VS Code で利用可能に – 移行とモダナイズのエージェンティックファクトリである AWS Transform が、Kiro (Power として) および VS Code (拡張機能として) を介してアクセスできるようになりました。Java/Python/Node.js のバージョンアップグレードや AWS SDK の移行などの一般的なパターンに対応したカスタム変換を IDE から直接実行でき、ジョブの状態はウェブコンソール、CLI、IDE 間で共有されます。 Aurora DSQL が PHP 用コネクタをリリース – 新しい Aurora DSQL Connector for PHP (PDO_PGSQL) は、IAM トークンの自動生成、SSL 設定の処理、接続プーリングの管理、エクスポネンシャルバックオフによるオプトイン方式の楽観的並行性制御リトライの提供により、Aurora DSQL 上での PHP アプリケーションの構築を簡素化します。 Amazon Q が Google Drive のドキュメントレベルのアクセスコントロールをサポート – Amazon Q は、Google Drive のナレッジベース用にドキュメントレベルのアクセスコントロールを強制適用するようになりました。高速な事前取得フィルタリングのためのインデックス付き ACL レプリケーションと、クエリ時の Google Drive に対するリアルタイムのアクセス許可チェックを組み合わせています。 AWS Secrets Manager がハイブリッドポスト量子 TLS をサポート – Secrets Manager は、現在および将来の量子コンピューティングの脅威からシークレットを保護するために、ML-KEM を使用したハイブリッドポスト量子鍵交換をサポートするようになりました。これは、Secrets Manager Agent 2.0.0 以降、Lambda 拡張機能 v19 以降、および CSI Driver 2.0.0 以降で自動的に有効になります。 Amazon EC2 C8in および C8ib インスタンスの一般提供を開始 – カスタムの第 6 世代インテル Xeon Scalable プロセッサと第 6 世代 AWS Nitro Card を搭載したこれらのインスタンスは、C6in と比較して、最大 43% 高いパフォーマンスを提供します。C8in は 600 Gbps のネットワーク帯域幅 (拡張ネットワーキング EC2 インスタンスの中で最高) を提供し、C8ib は最大 300 Gbps の EBS 帯域幅 (非アクセラレーション対応コンピューティングインスタンスの中で最高) を提供します。最大 384 vCPU までスケールします。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Amazon EKS Auto Mode でエンタープライズネットワーキングの課題を解決 – この記事では、EKS Auto Mode が VPC CNI 設定、ロードバランサーのプロビジョニング、DNS 管理など、Kubernetes ネットワーキングインフラストラクチャを自動化し、エンタープライズセキュリティコントロールを維持しながら、運用上のオーバーヘッドを削減する方法について説明します。 Amazon Bedrock のきめ細かいコスト帰属の導入 – 私の同僚である Micah が先週この機能について既に説明しましたが、ブログ記事は先週のまとめ記事の後に公開されました。Amazon Bedrock は、各 API コールを実行した特定の IAM プリンシパルに推論コストを自動的に帰属させるようになり、その結果は AWS コストと使用状況レポート (CUR 2.0) に反映されます。IAM プリンシパルタグとセッションタグを使用して、チーム、プロジェクト、またはコストセンターごとにコストを集計できます。 Amazon EBS Volume Clones を使用して開発ワークフローを加速 – EBS Volume Clones を使用することで、データ転送のために待機することなく、EBS ボリュームの即時のポイントインタイムコピーを作成できます。この記事では、開発/テスト環境の更新、ディザスタリカバリテスト、CI/CD パイプラインの加速など、さまざまなユースケースをご紹介します。 AWS Transform カスタムを利用して VB6 アプリケーションを大規模にモダナイズ – AWS Transform Custom のエージェンティック AI 機能を使用して、レガシー Visual Basic 6.0 アプリケーションを最新の C# ASP.NET Core ウェブアプリケーションに変換する方法を解説します。COM の依存関係、ADO から Entity Framework への移行、VB6 フォームから Blazor UI への変換などの課題にも対処します。 CloudFront を利用したダウンタイムなしでの API 移行と分解 – Strangler Fig パターンに基づいた、ユーザー認識型のインテリジェントトラフィックルーティングを実現する CloudFront KeyValueStore と CloudFront Functions を利用した、ダウンタイムなしの API 移行戦略。これは AWS Migration Hub Refactor Spaces が提供する機能と似ていますが、CloudFront とエッジ関数でのみ実装されています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Events – 今後お近くで開催される AWS 主催の実地およびオンラインイベント、スタートアップイベント、デベロッパー向けイベントをご覧ください。 AWS Power Hour – さまざまな AWS トピックをカバーする、Twitch での毎週のライブトレーニングセッション。 Community.aws – お近くで開催されるコミュニティ主催イベント、ミートアップ、ユーザーグループを検索できます。 4 月 20 日週のニュースは以上です。 4 月 27 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb 原文は こちら です。

本記事は 2026 年 4 月 19 日 に公開された「 EngineLab AI: Production-ready AI for studios and creators on AWS 」を翻訳したものです。 AI ツールは制作ワークフローの効率化を約束する一方で、スタジオは難しいジレンマを抱えています。AIツールを利用するためにはセキュリティ、知的財産 (IP) 保護、制作の安定性に関する現実的な懸念を伴うためです。本記事では、そんな制作現場でのトレードオフを解消するソリューションをご紹介します。 ComfyUI のような AI ツールを活用すると、モデル、処理ツール、クリエイティブな操作をつなぎ合わせ、本番レベルのワークフローを視覚的に設計・構築できます。ComfyUI は AI コンテンツ生成向けのオープンソースなノードベースのインターフェースです。しかし、制作ワークフローの加速や効率化を謳う新興技術にありがちなように、リスクも生じます。急速に進化する AI の世界では、標準化、パイプライン統合、アプリケーションの安定性といった課題が生まれます。セキュリティ面の課題はさらに複雑です。使用するモデルの出所を把握して法的要件に対応しつつ、AI ワークフローを流れる IP を厳格なセキュリティ基準に従って保護する必要があります。モデルやアーティファクトを適切に審査・承認しなければ、未承認の、場合によっては悪意あるツールやコードが作業環境に持ち込まれるリスクがあります。 これまでクリエイターは、AI を本番環境に導入するにあたり、こうしたメリットとリスクのバランスを取ることを余儀なくされてきました。 AWS のメディア・エンターテインメント専門パートナーである EngineLab は、 EngineLab AI というマネージドデプロイメントプラットフォームを提供開始しました。AWS インフラ上に構築され、ComfyUI などの AI アプリを安定した、セキュアな本番対応ツールセットとしてパッケージ化しています。メディア・エンターテインメント業界に向けに設計されており、ワークフローの特性を理解したうえで、ワークフローを構築する上級ユーザーから定型プロセスを活用したい一般ユーザーまで、チームのすべてのアーティストが強力な AI 機能を使えるようになります。 「スタジオは AI を本番環境で使いたいと言っています。しかし、現状の不安定さやリスクは受け入れられない。私たちは、その障壁を取り除くプラットフォームを構築しています。業界が求めるセキュリティとコントロールを備えた形で、AI ツールをスタジオのワークフローに組み込んでいきます。」 – Sam Reid、EngineLab 共同創業者兼 CEO 本記事では、EngineLab AI でこれらの課題を解決する方法を紹介します。具体的には、完全なデータ主権を確保するために顧客の AWS アカウントへ直接デプロイすること、最適な可用性とコストを実現するために AWS が提供するグローバル GPU リソースを活用すること、そしてワークフローに必要なクリエイティブな柔軟性を損なわずに IP を保護するセキュリティ制御を統合することです。 安定したスケーラブルな AI ワークフローの実現 スタジオにとって、高性能 GPU ハードウェアの調達はますます困難で高コストになっています。部品不足、価格上昇、オンプレミスインフラの維持管理負担により、AI ワークロードが必要とする GPU 容量の確保・維持は難しくなる一方です。ハードウェアを調達できたとしても、多様なプロジェクトやチームにまたがって安定的で効率的に割り当てるという課題が残ります。 ComfyUI の Web ベースアーキテクチャは、従来のリモートデスクトップソリューションに対して大きな優位性を持ちます。一般的なクラウドワークステーションは Virtual Desktop Infrastructure セッションを使い、キーボード、マウス、Wacom タブレットなどの操作を含むデスクトップ画面をリモートからローカルクライアントへストリーミングします。一方 ComfyUI はローカルの Web ブラウザ上で動作し、処理負荷の高い計算はサーバー側で実行されます。ユーザーインターフェースがレイテンシの影響を受けないため、重要なアーキテクチャ上の利点が生まれます。コンピューティングリソースをレイテンシを気にせずリモートでプロビジョニングできるのです。 EngineLab AI はこの柔軟性を活かし、 AWS グローバルインフラ を動的に活用します。利用可能な Amazon Elastic Compute Cloud (Amazon EC2) キャパシティ (オンデマンドの GPU インスタンスを提供する AWS のスケーラブルな仮想サーバーサービス) を持つ AWS リージョン (地理的に独立した AWS データセンターのクラスター) を活用します。これにより EngineLab AI は、Blackwell、Ada Lovelace、Ampere など多様な NVIDIA GPU アーキテクチャを搭載した GPU 搭載 Amazon EC2 インスタンスタイプ のグローバルプールにアクセスできます。vCPU 数やメモリ構成も幅広く、複数リージョンにまたがって可用性を高めることで、固定のローカルハードウェアをめぐる競合を減らせます。Amazon EC2 インスタンスを活用することで、AI ワークフローの固定コストを削減し、必要なときに必要なだけ GPU リソースをオンデマンドで利用できます。 また、スタジオはタスクに応じてコンピューティングリソースを柔軟に選べます。クラウドインフラが各ジョブに適切なリソースを動的に割り当てられる環境では、すべてのアーティストがデスクの下に高性能グラフィックカードを搭載した機器を置く必要はありません。GPU リソースを複数ユーザーで分割することでコストをさらに削減でき、オンプレミスハードウェアの固定費や運用負担なしに、スケールした GPU コンピューティングへの安定したアクセスを実現します。 EngineLab AI: スタジオとクリエイター向けマネージドプラットフォーム EngineLab は AWS グローバルインフラを基盤に、メディア・エンターテインメント向けに一から設計されたマネージドプラットフォームを開発しました。AI ツールを本番環境に導入する際にスタジオが直面する固有の課題に対応しています。 図 1 に示すプロジェクト管理インターフェースでは、ワークフローの状況を一元的に把握できます。管理者はここからアクティブなワークフローの追跡、リソース使用状況の監視、アーティストのアクセス管理を行えます。 図 1: EngineLab AI のプロジェクト管理インターフェース。管理者によるワークフローの追跡、リソースの監視、アーティストのアクセス管理の様子を示しています。 複雑な操作なしに即座にセッションを開始 アーティストが AI ツールを使うためにクラウドインフラを理解する必要はありません。EngineLab AI では、アプリを選択して起動するだけで AI アプリが使えます。適切なコンピューティングのプロビジョニング、環境の読み込み、安定したセッションの提供まで、すべてが自動で処理されます。セットアップも、トラブルシューティングも、待ち時間も不要です。スタジオはプロジェクト単位で作業を管理し、アーティストは必要なアプリをその中で起動するだけです。締め切りを抱えた現場では、セッションが起動しなかったり途中で止まったりすることは許されません。一貫性と信頼性のある操作性が重要です。 Artist UI: すべてのアーティストが使える高度なワークフロー どのスタジオにも、複雑なノードグラフを使って高度なワークフローを構築する ComfyUI の上級ユーザーがいます。しかし規模が大きくなると、多くのアーティストは技術的な専門知識を習得することなく、そのワークフローの恩恵を受けたいと考えます。Artist UI はその橋渡しをします。入力、プロンプト、出力といった基本的なエンドポイントだけを公開することで、アーティストは画像をアップロードし、やりたいことを記述するだけで結果を得られます。ノードグラフを操作しなくても、裏側では高度なワークフローが動いています。 これはスタジオにとって重要な IP 保護の課題も解決します。カスタムワークフローは実質的な競争優位性を持ちますが、ワークフローとユーザーの間に何も介在しなければ、フリーランサーが次の仕事先に持ち出すことを防ぐ手段がありません。Artist UI が境界として機能することで、内部の実装を公開せずにスタジオ全体がその機能を活用できます。 データ主権: 安心のセキュリティ 本ソリューションは顧客自身の AWS アカウントおよび環境にのみデプロイされ、包括的なコントロールとデータ主権を提供します。顧客データはトレーニングに使用されません。スタジオが制作したものはスタジオのものであり、その利用方法に曖昧さはありません。多くのプラットフォームがデータの取り扱いについて意図的に曖昧な表現を使う中、EngineLab AI は意図的に明確な姿勢を取っています。また、コミュニティが開発した AI ワークフローを実行する際に生じるセキュリティリスク、たとえば未承認または悪意あるコードインジェクションから保護するよう設計されたコントロールも含まれています。厳格なデータ要件を持つ大手クライアントと仕事をするスタジオにとって、本番環境では不可欠な要件です。 モデルトレーニング: セキュアな環境と完全なコントロール プラットフォームにはトレーニングアプリが含まれており、スタジオは独自のコンテンツを使ってファインチューニング済みの基盤モデルや、特定のパラメーターのみを変更することでスタイルのカスタマイズをより高速かつ低コストで実現する Low-Rank Adaptation (LoRA) をトレーニングできます。トレーニングはプラットフォーム環境内で実行されるため、トレーニングデータがプライベートアカウントの外に出ることはありません。トレーニング後、カスタムモデルは ComfyUI ワークフローから直接利用でき、モデルとその作成に使用したデータの両方をスタジオが完全に管理します。独自データが他所でのモデルトレーニングや競合他社の利益に使われるリスクを負わずに、カスタム AI モデルの力を活用したいスタジオの重要なニーズに応えます。 完全なコントロール: アクセス管理とプロベナンス 管理者は最小権限モデルによってプラットフォームをきめ細かく制御できます。ユーザーとリソースには各タスクの実行に必要な権限のみが付与され、上級ユーザーと管理者はモデルのアップロードと承認が可能な一方、一般ユーザーのアクセスは制限されます。ベンダー固有の承認もサポートしており、特定プロジェクトでは承認済みモデルのみを使用できます。これは厳格なコンプライアンス要件を持つクライアントと仕事をするスタジオにとって重要な要件です。包括的な監査証跡によりプロジェクトごとのモデル使用状況を追跡してクライアントへの報告やコンプライアンス検証に活用でき、プロベナンス追跡によってモデルの出所や組織全体での使用状況を正確に把握できます。 図 2 の AI Model Library インターフェースでは、モデルと LoRA の分類、承認、管理を一元的に行えます。 図 2: EngineLab AI の AI Model Library 管理ペインのスクリーンショット。 パイプライン統合: スタジオワークフロー全体へのコンピューティング提供 EngineLab は、深いパイプライン専門知識とハイエンドなクリエイティブワークフローの豊富な経験を持つチームをプラットフォームに結集しています。アーティストの時間が最も重要であるという認識のもと、チームは ComfyUI に関連する GPU および CPU コンピューティングを既存のレンダーファームワークフローへ直接統合する取り組みを進めています。これには、ワークフローの需要に応じてコンピューティングリソースを自動でスケールするフルマネージドのレンダーファームサービスである AWS Deadline Cloud を活用します。この統合により、ComfyUI のフロントエンドは軽量なマシンで動作しながら、重い GPU タスクをレンダーファームにオフロードでき、インターフェースと処理能力を切り離せます。EngineLab がツールを本番環境へ統合する方法を深く理解しているからこそ実現できる自然な発展であり、複雑な部分はプラットフォームが担うためスタジオが対処する必要はありません。 「プラットフォームの開発段階から EngineLab と協力してきました。社内にはすでに強力な ComfyUI の専門知識がありますが、クライアント業務に必要なコントロールとガバナンスを備えた、マネージドでセキュアな環境でスタジオ全体にスケールできることは、まさに私たちが求めていたものです。」　　　– Sean Costelloe、Selected Works マネージングディレクター まとめ EngineLab AI は ComfyUI を実験的なツールから本番対応プラットフォームへと変え、AI ツール導入時にスタジオが直面する重要な課題を解決します。スタジオの AWS アカウントへ直接デプロイすることで包括的なデータ主権とセキュリティを確保しながら、AWS が提供するグローバル GPU リソースを活用して最適な可用性と価格を実現します。スタジオは従来のアプローチのリスクやコストを負うことなく、本番対応の AI 機能を手に入れられます。クライアント業務に必要なコントロールを備えた安定したセキュアな AI 生成環境を、使い慣れたワークフローに統合して利用できます。 AWS インフラの詳細 EngineLab AI は、コンピューティング負荷の高いクリエイティブワークロード向けに実績ある AWS サービスを基盤としています。 Amazon EC2 – AI およびレンダリングワークロード向け GPU インスタンスを備えたスケーラブルな仮想サーバー AWS Deadline Cloud – コンピューティングリソースのスケーリングに対応したマネージドレンダースケジューリングサービス 次のステップ クリエイティブワークフローへのクラウドインフラ活用について詳しくは、AWS アカウントチームにお問い合わせいただくか、 AWS for Media & Entertainment をご覧ください。 スタジオで AWS 上のセキュアでスケーラブルな AI ワークフローを活用する方法については、 EngineLab AI をご覧ください。 Andy Hayes アンディ・ヘイズは、AWSのシニアビジュアルコンピューティングソリューションアーキテクトです。ビジュアルエフェクトとアニメーションの分野で20年の経験を持つアンディは、芸術、科学、技術の融合によって生み出される魅力的な映像表現に情熱を注いでいます。 Sam Reid サムはEngineLabのCEOです。彼は世界初の完全クラウドネイティブなクリエイティブスタジオの立ち上げを主導しました。Untold StudiosのCTOとして、ロンドン、ロサンゼルス、ムンバイに拠点を置く500名以上のクリエイターを支えるインフラをゼロから構築しました。現在は、テクノロジーを通じてクリエイティブなインパクトを生み出すことに重点を置き、EngineLabのビジョンと成長を牽引しています。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 4 月 21 日 に公開された「 From developer desks to the whole organization: Running Claude Cowork in Amazon Bedrock 」を翻訳したものです。 本日、Claude Cowork in Amazon Bedrock の提供開始を発表します。Amazon Bedrock を通じて、直接または LLM ゲートウェイ経由で Cowork と Claude Code Desktop を利用できます。 スタートアップからあらゆる業界のグローバル企業まで、多くの組織が Claude Code in Amazon Bedrock を活用して開発者の生産性を高め、デリバリーを加速しています。Amazon Bedrock では、既存の AWS 環境内で構築でき、エンタープライズセキュリティとリージョンのデータレジデンシーを維持しながら推論をスケールできます。データはお客様のアカウント管理下に置かれます。Amazon Bedrock はプロンプト、ファイル、ツールの入出力、モデルの応答を保存せず、基盤モデルのトレーニングにも使用しません。 Claude Cowork in Amazon Bedrock は、ドキュメントの読み取り、複数ステップのリサーチ、ファイル処理を行い、完成した成果物を返すデスクトップアプリケーションです。これにより、組織内のすべてのナレッジワーカーに AI 活用を広げられます。 本記事では、Claude Cowork と Amazon Bedrock の統合方法を説明し、ナレッジワーカーが実際にどのように活用しているかを紹介します。 Claude Cowork とは Claude Cowork では、デスクトップアプリケーションからリサーチ、ドキュメント分析、データ処理、レポート生成を Claude に委任できます。 Claude Desktop の主要機能である プロジェクト 、 アーティファクト 、 メモリ 、 ファイルのアップロードとエクスポート 、 リモートコネクタ 、 スキル 、 プラグイン 、 MCP サーバー を利用できます。Chat タブ、Computer Use、Skills Marketplace など Anthropic ホスト型推論を必要とする機能は含まれません。これは、Claude Cowork がモデル推論をお客様の AWS アカウント内の Amazon Bedrock のみを経由してルーティングするためです。Claude Enterprise との機能比較の詳細は、 サードパーティ向け機能比較ページ（Features on 3P） をご覧ください。 料金は既存の AWS 契約と請求を通じた従量課金制で、Anthropic からのシートライセンスは不要です。 Claude Cowork と Amazon Bedrock の統合 Amazon Bedrock は、お客様の AWS アカウントおよびサポート対象の AWS リージョンで推論バックエンドとして機能します。 Claude Cowork in Amazon Bedrock の設定は 2 ステップで完了します。まず、ユーザーが自分のマシンに Claude Desktop アプリケーションをダウンロードします。次に、デバイス管理システム（Jamf、Microsoft Intune、グループポリシーなど）を使って Claude Desktop に設定をプッシュし、推論モードを有効化します。この設定で、モデル ID、Amazon Bedrock 推論プロファイル、認証方法、組織ポリシーを指定します。 組織が LLM ゲートウェイ経由でモデルアクセスを一元化している場合は、同じ管理対象設定で Claude Desktop をゲートウェイ URL に向けます。 Amazon Bedrock で Claude Code を既に利用している場合、Claude Cowork でも同じセットアップを使用できます。 図 1: エンドツーエンドのフローを示す図 アプリケーションには 3 つのアウトバウンドパスがあり、いずれもお客様側で制御できます。モデル推論は設定した AWS リージョンの Amazon Bedrock に送信されます。MCP サーバー接続は、設定されている場合、承認済みのエンドポイントに接続します。Anthropic が受信するのは集計されたテレメトリデータ (トークン数、モデル ID、エラーコード、匿名デバイス識別子) のみで、設定オプションで無効化できます。 Amazon Bedrock では、リージョン内、地理的クロスリージョン、グローバルクロスリージョンの 推論プロファイル を提供しており、組織に適したデータレジデンシーのレベルを選択できます。 Claude Cowork は既に利用している AWS サービスと連携します。 AWS IAM または Amazon Bedrock API キー による認証 VPC エンドポイントによるネットワーク分離 OpenTelemetry から Amazon CloudWatch へのエクスポート によるオブザーバビリティ (オプション) AWS CloudTrail による監査 きめ細かなコスト配分 に対応した AWS 一括請求 MDM 設定、認証情報、MCP サーバー、プラグインの詳細は、 Claude Cowork Configuration Reference（設定リファレンス）  をご覧ください。 Claude Cowork の活用例 統合の設定が完了すると、ユーザーは Claude Desktop を開いて作業を委任できます。Claude Cowork は MCP サーバーを通じて外部データソースに接続でき、作業中に Claude が最新のドキュメント、ウェブ検索、その他のツールにアクセスできます。 例えば、あるプロダクトマネージャーが AWS でホストされている大学スポーツチーム向けアプリの新しい通知機能を企画しているとします。プロダクトマネージャーは方向性がそれぞれ異なる顧客ミーティングのメモとプロジェクト要件を抱えており、それらをすり合わせる時間は限られています。そこで Cowork にアップロードします。 Claude はそれぞれの異なるインプットを比較し、1 つのプロダクトブリーフに統合します。提案されたアプローチを評価し、代替案を調査し、技術的な課題を指摘し、推奨事項を具体的な根拠とともに提示します。 AWS Documentation MCP サーバー とウェブ検索 MCP サーバーに接続することで、Claude は最新のサービスドキュメント、市場動向、競合状況に基づいたブリーフを作成します。 図 2: プロダクトマネージャーが Claude Cowork でミーティングメモからプロダクトブリーフを作成する様子 数分で、プロダクトマネージャーは最新のソースに基づいた構造化されたブリーフを入手し、レビューに進められます。同じパターンは他のナレッジワーカーにも当てはまります。オペレーションマネージャーは散在するドキュメントを SOP にまとめられます。ファイナンスアナリストは生データをフォーマットされた月次レビューに変換できます。リサーチチームは複数のソースからの調査結果を 1 つのレポートにまとめられます。 まとめ Claude Cowork in Amazon Bedrock を使えば、データを AWS 環境内に保持しながら、組織内のすべてのナレッジワーカーに AI 活用を広げられます。Claude Cowork は macOS と Windows で利用可能で、 Amazon Bedrock で Claude モデルが提供されている AWS リージョン に対応しています。 利用を開始するには、 claude.com/download から Claude Desktop をダウンロードのうえ、 Claude Cowork セットアップガイド をご覧ください。 ぜひ Claude Cowork をお試しいただき、AWS re:Post for Amazon Bedrock または AWS サポート窓口からフィードバックをお寄せください。 著者について Sofian Hamiti 12 年以上にわたり AI ソリューションの構築に携わり、高パフォーマンスなチームを率いて顧客成果の最大化に取り組むテクノロジーリーダーです。多様な人材がグローバルなインパクトを生み出し、キャリア目標を達成できるよう支援することに情熱を注いでいます。 Ayan Ray AWS のプリンシパルパートナーソリューションアーキテクト兼 AI テクニカルリードで、AWS における Anthropic のグローバルテクニカルリードを務めています。クラウドアーキテクチャと人工知能の交差点で、組織が AWS 上で Anthropic のテクノロジーを導入・スケールできるよう支援しています。 Antonio Rodriguez AWS の Amazon Bedrock 担当プリンシパルスペシャリストソリューションアーキテクトで、エンタープライズ生成 AI アーキテクチャと規制業界向けデプロイメントを専門としています。 この記事は ソリューションアーキテクトの 大磯 がレビューしました。

本記事は、2026 年 1 月 28 日に公開された “ Innovation sandbox on AWS with real-time analytics dashboard ” を翻訳したものです。翻訳は Delivery Consultant の 馬庭龍一 が担当しました。 大規模なハッカソンのために数百の AWS アカウントをデプロイするにはどうすればよいでしょうか？経営陣にリアルタイムな可視化を提供するには？アカウント全体の支出を監視しながら、参加者のセルフサービスを可能にするには？ エンタープライズのイノベーションイベントでは、参加者のエンゲージメント、リソース使用状況、成果をリアルタイムで把握できないことがよくあります。リーダーはエンゲージメント指標を確認できず、ビルダーはアカウントや情報にオンデマンドでアクセスできません。オブザーバビリティとガバナンスがなければ、チームが達成できることは限られてしまいます。 このソリューションは、安全なアカウントガバナンスのための Innovation Sandbox on AWS 、迅速なプロビジョニングのための AWS Control Tower Automate Account Creation 、そして Amazon Q Business 生成 AI アシスタントを活用したカスタム分析ダッシュボードを組み合わせています。エンタープライズコントロールを備えたセルフサービスアカウントにより、参加者は機密データ処理を実験できるようになり、コンプライアンスを維持しながら AI の導入を加速させました。このアプローチは、イノベーションイベントを成果が見えにくい体験から、測定可能な成果を持つデータ駆動型の取り組みへと変革します。 このソリューションは、コアとなる課題を解決しました。それは、エンタープライズデータ、ガバナンス、リアルタイムの可視性を備えた大規模な AI イノベーションを可能にすることです。ビルダーにとっては、4 時間以内に 246 の AWS アカウントをプロビジョニングし、さらにセルフサービスリソース (ナレッジベース、生成 AI アシスタント、エキスパートサポートフォーム) を 213 名の参加者に提供しました。経営陣にとっては、23 のセッション全体でリアルタイムの可視性を実現し、基調講演では最大 153 名、技術ワークショップでは 41 名の参加者を記録しました。 課題 数百万の顧客を持つ欧州の大手通信事業者が、大規模な生成 AI ハッカソンを開催しました。その課題は、100 以上のチームに所属する 500 人以上の参加者が、エンタープライズグレードのセキュリティとガバナンスを維持しながら、AI イノベーションを迅速に開発できるようにすることでした。イベント開始までわずか数週間という状況で、チームは従来のアカウント準備方法では解決できない重大な技術的および運用上のハードルに直面していました。 この取り組みの規模と複雑さには、革新的なソリューションが求められました。 大規模な同時アカウント作成 – 標準プロセスでは通常数週間から数か月かかる 200 以上のセキュアな AWS アカウント作成を数日で実施 包括的なセキュリティ管理 – 各アカウントの適切な分離を維持しながら、組織全体のセキュリティポリシー、支出制限、アクセスコントロールを実装 幅広い技術レベルのサポート – AI 研究者からビジネスアナリストまで、各国から参加する様々なクラウド経験レベルの参加者をサポートするため、直感的なセルフサービス機能が必要 リアルタイムでの運用状況の可視化 – 経営陣に対して、参加者のエンゲージメント、リソース使用率、技術採用メトリクスを追跡する AI 支援ダッシュボードを提供するとともに、参加者にアジェンダ、連絡フォーム、ナレッジベースの情報を提供 データガバナンス要件 – 内部データを使用した AI 開発では、外部管理環境ではなく、顧客自身のガバナンス下にあるアカウントが必要 重要なのは、このソリューションが数時間以内に本番環境で利用可能な状態であることが求められました。これは、小規模なデプロイメントであっても困難なスケジュールでした。このタイトなスケジュールでは、設計、実装、テストの各フェーズにおいてミスが許されない状況でした。 技術チームは、これらの課題に対処するには、単に既存のプロセスを加速するだけでは不十分であることを認識していました。AWS アカウントガバナンス、自動プロビジョニング、リアルタイム分析を組み合わせた、新しいアプローチが必要でした。 ソリューションのアーキテクチャ 私たちのソリューションは、 Innovation Sandbox on AWS を基盤として活用し、カスタム自動化とリアルタイム分析機能で強化しました。Innovation Sandbox on AWS はアーキテクチャパターンとセキュリティコントロールを提供し、追加コンポーネントが迅速なアカウント作成と経営層への可視性を処理しました。このアーキテクチャは、自動化されたアカウントプロビジョニング、セルフサービスアクセスポータル、経営層向け分析ダッシュボードという 3 つのコアコンポーネントで構成されていました。 このソリューションは、プロンプトエンジニアリングと人間によるレビューを使用して、 Kiro CLI で実装しました。この記事では実際に使用したプロンプトの例を掲載しています。従来のコードスニペットを共有するのではなく、 Kiro CLI で使用した実際のプロンプトを提供しています。これらのプロンプトは、ソリューションに必要なダッシュボードコンポーネント、API 統合、インフラストラクチャコードを生成しました。 ソリューションのアーキテクチャ 1. 基盤としての Innovation Sandbox on AWS 一時的な AWS アカウントを大規模に管理するための重要なインフラストラクチャを提供するため、 Innovation Sandbox on AWS をデプロイしました。このソリューションは、 Entry と呼ばれる特定の組織単位 (OU) をデプロイし、アカウントをソリューションにオンボーディングできるようにします。事前定義されたセキュリティポリシー、支出管理、自動クリーンアップメカニズムを備えた組織単位を構成しました。サンドボックス環境には、機密性の高いサービスへのアクセスを制限するサービスコントロールポリシーが含まれており、オプションで利用期間（リース期間）と予算の管理が可能です。同時に、 Amazon Bedrock 、 Amazon SageMaker 、その他の AI/ML サービスを使用した生成 AI の実験を可能にしています。 2. アカウントの自動作成 AWS Control Tower Automate Account Creation を並行して使用し、数百のアカウントを迅速にデプロイしました。これにより、エンタープライズコントロールを備えたアカウントの一括プロビジョニングが可能になりました。この CloudFormation ベースのソリューションは、 AWS Service Catalog API を使用して複数のアカウントを同時に作成し、プロビジョニング時間をアカウントあたり数時間から数秒に短縮しました。 3. カスタム分析ダッシュボード Amazon Q Business 統合を活用して、リアルタイムのインサイト、アジェンダ、ナレッジベース、お問い合わせフォームを提供するカスタムダッシュボードを構築しました。このカスタム分析ダッシュボードは、データ収集と Amazon Q Business 統合を組み合わせて、インテリジェントなインサイトを提供します。使用したアーキテクチャは以下のとおりです: CloudFront による S3 での静的ウェブホスティング Amazon Q Business URL 生成 のための Lambda 関数 CORS 対応 エンドポイントのための API Gateway リアルタイムメトリクス計算のための JavaScript モジュール Amazon Q Business ナレッジベース のための自動データ集約 AWS Well-Architected Framework との整合性 このソリューションは、 AWS Well-Architected Framework の原則に従っています。 運用上の優秀性: 自動化されたプロビジョニングとリアルタイムモニタリングにより、手動作業を削減しました。 セキュリティ: 事前設定されたポリシーと分離されたサンドボックスアカウントにより、リソースを保護しました。 コスト最適化: 自動化されたクリーンアップと支出管理により、無駄を最小限に抑えました。 パフォーマンス効率: 並列化されたアカウント作成により、デプロイを高速化しました。 持続可能性: 自動化されたクリーンアップにより、アイドル状態のリソース消費を削減しました。 ウォークスルー お客様のクラウドチームと AI チームと緊密に連携し、お客様固有のセキュリティとガバナンス要件を満たすアカウントプロビジョニング戦略を、わずか 3 日間で迅速に改善を重ねました。 サンドボックス環境のセットアップ 私たちは、 Innovation Sandbox on AWS 実装ガイド に従い、クロスアカウント共有のための Resource Access Manager (RAM) と参加者への通知のための Amazon Simple Email Service (Amazon SES) の前提条件を含めて設定しました。 AppConfig の設定値をお客様の要件に合わせて変更し、参加者が使用するための 1 つのリースを作成しました。1 人が、 管理者 (アカウントプールと設定管理用)と マネージャー (リーステンプレートと承認用)の両方の役割を管理し、運用を効率化しました。 アカウントのプロビジョニング 管理アカウントに AWS Control Tower Automate Account Creation スタックをデプロイし、Innovation Sandbox on AWS によってデプロイされた専用の Entry 組織単位 (OU) にアカウントをプロビジョニングするように設定しました。 3 日間という期限を満たすため、複数の CloudFormation スタックを同時にデプロイすることでプロビジョニングを並列化しました。各スタックはアカウントのサブセットを処理します。このアプローチにより、プロビジョニングのスループットが 2 倍になり、213 名の確定参加者向けに 246 個の AWS アカウントを 4 時間未満で作成できました。これは、直列処理に比べて大幅に短縮されています。 400 のダミーアカウントの情報を含む複数の CSV ファイルを生成しました。各アカウントには、一意のアカウント名、アカウント用のメールアドレスと IAM Identity Center ログイン用メールアドレス、アクセス用のユーザー名、およびアカウント用の特定の組織単位が含まれています。自動化処理がアクセスできるように、CSV ファイルを S3 バケットに配置しました。次に、各 CSV ファイルに対して BatchAccountCreation.yaml CloudFormation スタックをデプロイしました。これにより、対応するアカウントファイルが処理され、各アカウントがそれぞれ作成されました。このシステムにより、アカウントの作成中に他のタスクに集中できるようになりました。 モニタリングダッシュボードの構築 ダッシュボードは Web ベースのインターフェースを提供し、参加者が以下のことを行えるようにしました: クイックスタートガイドとチュートリアルを表示 主要なメトリクスと参加者情報を可視化 アジェンダとデモを表示 追加サポートをリクエストするためにユースケースを提出 組み込まれた Amazon Q Business を通じて AI を活用した支援を受ける ダッシュボードを迅速に提供するために、 Kiro CLI を使用しました。このガイドでは、同様のソリューションを構築するために使用するプロンプトを提供します。 AWS CDK のコードを生成するプロンプトの例: [ 役割 ] あなたは AWS CDK (Cloud Development Kit) とサーバーレスダッシュボードアーキテクチャの専門家である AWS ソリューションアーキテクトです。 [ タスク ] Q Business API 統合と CloudFront ディストリビューションを備えた、安全なダッシュボードホスティングをプロビジョニングする完全な AWS CDK アプリケーションを TypeScript で生成してください。 [ コード出力形式 ] - 適切なコンストラクト依存関係を持つ TypeScript CDK スタック - 最小権限の原則に従った最小限の IAM 権限 - デプロイ自動化統合のためのスタック出力 [ 要件 ] - S3: バージョニング、BucketDeployment を使用したパブリックアクセスのブロックを備えたプライベートバケット - CloudFront: Origin Access Identity、API Gateway 統合を備えたディストリビューション - Lambda 関数: boto3 を使用した Q Business URL 生成のための Python 関数コンストラクト - API Gateway: /qbusiness-url エンドポイント用の CORS 設定を備えた LambdaRestApi - セキュリティ: 最小限の qbusiness:CreateAnonymousWebExperienceUrl 権限を持つロールコンストラクト [ 手順 ] 1. S3-CloudFront セキュリティには OriginAccessIdentity コンストラクトを必ず使用すること 2. BehaviorOptions を実装すること: 静的ファイルには S3、/api/* パスには API Gateway 3. ブラウザ API リクエスト用に CorsOptions を設定すること 4. バケット名、CloudFront URL、ディストリビューション ID の CfnOutput をエクスポートすること 5. 過度に許可的な PolicyStatement は使用しないこと - 特定の Q Business アプリケーション ARN にスコープを限定すること [ 成功基準 ] - CDK スタックが任意の AWS リージョンで cdk deploy により正常にデプロイされること - S3 バケットが OAI 経由の CloudFront のみのアクセスでプライベートのままであること - API Gateway が適切な CORS ヘッダーを持つ有効な Q Business URL を返すこと - デプロイ自動化スクリプト用にすべてのスタック出力が利用可能であること データ収集 データの更新には GitOps アプローチを採用しました。単一の JSON ファイルを信頼できる情報源として使用し、データポイントを自動的にクロスチェックして早期に障害を検出しました。ダッシュボードはこの集約されたデータを使用して Amazon Q Business ドキュメントを更新し、静的ウェブサイトからリアルタイムの計算や表示を提供しました。データはハッカソン中、継続的に更新されました。 ダッシュボードは、複数のソースからデータを集約し、イベント全体を可視化しました。セッションの出席状況は、仮想会議プラットフォームを通じて追跡されました。リアルタイムのエンゲージメントは、セッションへの参加状況から算出されました。お客様のリードクラウドアーキテクトと協力して、アカウントが存在する組織単位 (OU) から AWS アカウントのコストメトリクスを収集し、Kiro ダッシュボードから Kiro Pro サブスクリプション数を収集しました。Innovation Sandbox on AWS は、専用の組織単位(OU) を作成しアカウントプールとして利用します。そのため、OU 単位でコストを追跡することでハッカソン全体のコスト算出が容易でした。 リアルタイムデータ処理エンジンのプロンプト例: [ 役割 ] あなたはトレンド分析を備えたエグゼクティブダッシュボード向けのリアルタイム分析エンジンを作成するデータ処理スペシャリストです。 [ タスク ] ハッカソンのセッションデータを処理し、KPI を計算し、統計分析を備えた動的な UI コンポーネントを生成する JavaScript モジュールを構築してください。 [ コード出力形式 ] - データ計算用のモジュール化された JavaScript 関数 - 単一の信頼できる情報源としての JSON データ構造 - リアルタイム更新のための動的な DOM 操作 [ 要件 ] - ピーク計算: セッションデータからの技術セッションピーク、非技術セッションピーク - トレンド分析: 方向指標付きの前日比変化率 - KPI 生成: エンゲージメント率 (53%)、AWS 採用率 (21%)、Kiro Pro コンバージョン率 (7%) - 動的レンダリング: 参加者数とクリックハンドラーを持つセッションカード - データ構造: セッション、アカウント、統計情報を含む包括的な data.json [ 指示 ] 1. すべての統計は data.json から計算すること - ハードコーディングされた値は使用しないこと 2. null 値の処理を含む変化率計算を実装すること 3. モーダル統合を備えたセッションカードを動的に生成すること 4. すべての計算においてデータの整合性を検証すること 5. データを重複させないこと - JSON 構造内で単一の信頼できる情報源を維持すること [ 成功基準 ] - すべての KPI がソースデータから正しく計算される - 変化率のトレンドが適切な方向指標 (↑↓) で表示される - セッションカードが正確な参加者数で動的にレンダリングされる - データ検証により計算エラーが防止され、エッジケースが処理される これらのメトリクスにより、以下の KPI を設定し、それらを通じてハッカソンのヘルスを監視することができました。 ピーク時のセッション参加者数 (技術トラックとビジネストラック) 日別のエンゲージメント動向 AWS サービスの採用率 Kiro のサブスクリプション指標 アカウントの利用状況と支出パターン Day 1 を示すリアルタイムダッシュボード 生成 AI に焦点を当てたハッカソンであることから、主要な生産性指標として Kiro のサブスクリプションを特に追跡しました。技術ワークショップ後に Kiro Pro を有効化した参加者は、開発サイクルの加速とエンタープライズグレードの AI 開発スキルの構築への意欲を示しました。これらは、イベント後に生成 AI の取り組みを拡大するために不可欠な能力です。生成 AI の採用を支援するため、ダッシュボード内に Kiro のインストールガイドを提供し、お客様の AI 研究チームがダッシュボードリソースに統合された追加ドキュメントを作成しました。 重要な成功要因は、技術的なメトリクスをビジネス関係者にとって意味のあるものにすることでした。ダッシュボードには、各メトリクスに対する文脈に応じた説明が含まれていました。 AWS 支出の増加 : 「高度なサービスを使用するより複雑なソリューション」として説明されており、「ソリューションの複雑さとイノベーションの深さを示す」ことを示しています。 Kiro Pro サブスクリプション : 「参加者による高度な開発ツールの採用」として説明されており、「開発サイクルを加速し、エンタープライズグレードの AI スキルを構築する」ことを示しています。 アカウント使用量の増加 : 「より多くの参加者がハンズオン開発に参加している」として明確化されており、「実践的なクラウド開発経験」を提供します。 Kiro Pro メトリックの説明 AWS Accounts メトリックの説明 AWS Spending メトリックの説明 ナレッジベースとセルフサービスリソース メトリクスの追跡に加えて、ダッシュボードエコシステムには 3 つの重要なセルフサービスコンポーネントが含まれており、管理負荷を削減しながら参加者の体験を向上させました。 この Wiki は、重要なツール、セットアップガイド、よくある質問へのクイックリンクを備えたナレッジベースとして機能し、セッション中の参加者間での情報共有の第一の手段となりました。 インタラクティブなアジェンダにより、ユーザーは技術トラックとビジネストラックにまたがる複雑な 5 日間のスケジュールをスムーズに確認できました。Amazon Q Business の統合により、参加者の役割や興味に基づいてパーソナライズされたおすすめのセッションが提供されました。 ユースケース送信フォームにより、チームは追加の AWS エキスパートサポートを直接リクエストできるようになり、有望なプロジェクトと専門的な技術ガイダンスをつなぐことができました。 リアルタイム KPI を含むエグゼクティブダッシュボードのプロンプト例: [ 役割 ] あなたは AWS テーマのエグゼクティブダッシュボードとリアルタイムデータビジュアライゼーションを専門とするシニアフルスタック開発者です。 [ タスク ] インタラクティブな KPI カード、日別のセッショントラッキング、モーダル機能を備えた、ハッカソンの指標を表示する包括的なエグゼクティブダッシュボード HTML ページを作成してください。 [ コード出力形式 ] - CSS と JavaScript が埋め込まれた単一の HTML ファイル - データ処理と UI 更新のためのモジュール関数 - エグゼクティブ向けに最適化されたレスポンシブデザイン [ 要件 ] - AWS デザインシステム: #232F3E ダークブルー、#FF9900 オレンジ、Amazon Ember フォントを使用 - KPI カード: 技術セッションのピーク (82)、非技術セッションのピーク (353)、エンゲージメント率 (73%)、AWS 採用率 (41%)、Kiro Pro 採用率 (70%) - 日別トラッキング: 参加者数を表示するセッションカード付きの 5 日間のセクション - インタラクティブ要素: 詳細モーダルを開くクリック可能なセッションカード - データソース: すべての指標を data.json から単一の信頼できる情報源として読み込む [ 指示 ] - ホバー効果とスムーズなトランジションを持つ CSS Grid レイアウトを実装すること - トレンド指標 (↑↓) 付きの前日比変化率を計算すること - セッション詳細 (時間、トラック、形式、説明) を含むモーダルシステムを作成すること - null の参加者値を適切に処理すること - 指標をハードコーディングしないこと - 集中管理された JSON データから計算すること [ 成功基準 ] - すべての KPI が正しいトレンド計算で表示される - セッションモーダルが完全な情報とともにスムーズに開く - モバイルレスポンシブデザインが 320px 以上の画面で動作する - data.json が変更されたときにリアルタイムで更新される ユースケースの提出 アジェンダ Wiki ページ Amazon Q Business の統合 ダッシュボードには、チャットボットとしてインテリジェントなイベント支援機能を提供する Amazon Q Business が組み込まれていました。これは、クライアントが画面右下に「Talk to Dashboard」アイコンを表示することで機能しました。 クリックされると、クライアントは API (Lambda) にリクエストを送信して一時的な Amazon Q Business URL を作成し、クライアントが URL を受信すると、Amazon Q Business インターフェースを表示する iframe を動的に作成します。 ビジネス AI チャット統合のプロンプト例: [ 役割 ] あなたは Amazon Q Business とレスポンシブな iframe 実装の専門家であるフロントエンド統合スペシャリストです。 [ タスク ] 動的な URL 取得、レスポンシブ UI、セッション管理を備えた Amazon Q Business チャットを統合する JavaScript モジュールを作成してください。 [ コード出力形式 ] - CSS スタイリングを含むスタンドアロン JavaScript モジュール - Q Business URL 生成のための API 統合 - エラーハンドリングを備えたモバイルレスポンシブ iframe [ 要件 ] - トグルボタン: AWS オレンジスタイリングの「Ask Q about Hackathon ????」を右下に配置 - 動的 URL: 有効期限切れを避けるため /api/qbusiness-url から新しい Q Business URL を取得 - レスポンシブデザイン: モバイル (<480px) では全幅 iframe、デスクトップでは固定位置 - 状態管理: 「Ask Q」と「Close Chat」ボタン状態の切り替え - エラーハンドリング: ローディングインジケーター、API 失敗メッセージ、セッション回復 [ 指示 ] 1. チャットセッションを開くたびに新しい Q Business URL を取得すること 2. レスポンシブ iframe を実装すること: デスクトップでは最大幅 450px、モバイルでは全幅 3. URL 生成 API 呼び出し中にローディングインジケーターを表示すること 4. API 失敗時にユーザーフレンドリーなエラーメッセージを処理すること 5. Q Business URL をキャッシュしないこと - セキュリティのため常に新しい URL をリクエストすること [ 成功基準 ] - チャットが開閉状態間でスムーズに切り替わる - モバイルデバイスでオーバーフローなくチャットインターフェースが適切に表示される - API 失敗時に機能が壊れるのではなく、有用なメッセージが表示される - Q Business iframe がダッシュボードコンテキストで正常に読み込まれる Amazon Q Business との統合 クリーンアップとコスト管理 アカウントの廃止 ハッカソン後、Innovation Sandbox on AWS の自動クリーンアップメカニズムがアカウントの ライフサイクル管理 を実行しました。 アカウント凍結機能 : Innovation Sandbox は 14 日後に AWS アカウントへのユーザーアクセスを自動的に取り消しましたが、管理者は評価のためにアクセスを保持し続けました 自動クリーンアップ : Innovation Sandbox は、明示的に保存されない限り、21 日後にアカウントリソースを自動的に削除しました。 アカウントの移行 : 有望なプロジェクトを本番アカウントに移行し、すべてのリソースを保持しました。 コスト最適化の考慮事項 Innovation Sandbox の予算アラートを 50 米ドルと 100 米ドルのしきい値で設定しました。 Innovation Sandbox on AWS の事前設定されたサービスコントロールポリシーを使用して、高額なリソースタイプの作成を防止しました。 コスト配分のために自動リソースタグ付けを使用しました。 支出状況の可視化のために分析ダッシュボードを使用しました。 イベント全体のインフラストラクチャコストは 2,000 米ドル未満に抑えられ、アカウントの 89% が 100 米ドルの予算制限内に収まりました。 結果と結論 このソリューションは、すべての側面で測定可能な結果をもたらし、Innovation Sandbox on AWS がカスタム分析によって強化され、企業のイノベーションイベントを変革できることを実証しました。基調講演セッションには最大 153 名が参加し、ハンズオン技術ワークショップには 41 名が参加しました。これは 53% の技術的エンゲージメント率を示しています。 主要なメトリクスと成果 インフラストラクチャのパフォーマンス: 4 時間以内に 246 個の AWS アカウントをプロビジョニングしました セキュリティインシデントやポリシー違反はありませんでした 平均アカウントセットアップ時間が 2 時間以上から数秒に短縮されました 総インフラストラクチャコストは 2,000 米ドル未満で、89% のアカウントが 100 米ドルの予算制限内に収まりました 内部データガバナンスを維持 – すべてのアカウントが顧客のエンタープライズ管理下に留まり、内部データを使用した AI 開発を可能にしました 参加者のエンゲージメント: 21% が新しい AWS AI サービス を採用しました 7% が Kiro の使用を開始しました Amazon Bedrock は AWS ベースのプロジェクトの 71% で使用されました ビジネストラック参加者の 34% が動作するプロトタイプを作成しました イノベーションの成果: このハッカソンでは、技術的な卓越性が評価された 7 つの AI を活用した AWS ベースのソリューションが生まれました。数百万人の顧客にサービスを提供する AI を活用したコールセンターエージェントから、自律的なネットワーク管理システムまで、多岐にわたります。顧客体験ソリューションが平均スコア 7.7 で最も高いパフォーマンスを示しました。企業管理アカウントにより、86% のソリューションが社内データのユースケースをターゲットにすることができました。 ダッシュボードの影響と導入 分析ダッシュボードは、3 つの重要なフェーズに対応しました。イベント前のロジスティクスとアカウントアクセスのコミュニケーション、イベント中のリアルタイムモニタリング、そしてイベント後の ROI 分析のためのエグゼクティブレポートです。あるディレクターは次のように述べています。「ダッシュボードは素晴らしく、私は個人的に 1 日に 20 回更新していました。」この可視性により、経営陣はリソース配分と将来の革新的な取り組みについて、データに基づいた意思決定を行うことができました。 成功要因と再利用性 主な成功要因には、既存の AWS ソリューションを基盤として活用すること、再利用可能なモジュール式の分析を構築すること、そしてインテリジェントなアシスタンスのために Amazon Q Business を統合することが含まれていました。セルフサービスアプローチにより、管理オーバーヘッドを削減しながら、参加者がイベント終了後も学習を継続できるようになりました。 ここで示されたパターンは、あらゆる規模のハッカソン、トレーニングプログラム、イノベーションラボで再利用可能です。Innovation Sandbox on AWS は安全な基盤を提供し、カスタム分析により可視化とエンゲージメントの測定を変革します。 イノベーションイベントの実施準備はできましたか？ チームのスキルアップを図り、可能性の限界に挑戦する準備はできていますか？オンデマンドで数分以内に安全な AWS アカウントを提供し、必要な情報へのセルフサービスアクセスを提供することで、チームのイノベーションを可能にしましょう。リーダー層にリアルタイムで成果を確認してもらい、支援を受けましょう。次のイノベーションイベントを、本番環境に対応したソリューションの出発点に変えましょう。 Innovation Sandbox on AWS から始めて、組織のニーズに合わせたカスタム分析機能で強化しましょう。自動プロビジョニング、リアルタイム分析、AI を活用した支援を組み合わせることで、参加者がインフラストラクチャではなくイノベーションに集中できる、スムーズに進められる環境を実現します。 次のステップ: Innovation Sandbox on AWS 実装ガイド AWS Control Tower Automate Account Creation Amazon Q Business 連携ドキュメント Kiro の使用を開始する 謝辞: このプロジェクト期間中にサポートしていただいた Innovation Sandbox チームの Shu Jackson、Rakshana Balakrishnan、Todd Gruet、Kevin Hargita の各氏に感謝します。 Erkin Ekici Erkin Ekici は AWS のシニアソリューションアーキテクトであり、セキュリティアーキテクチャとクラウドセキュリティを専門とする認定セキュリティプロフェッショナルです。スタートアップから銀行、Fortune 500 企業まで幅広い組織のセキュリティを担当してきました。サイバーセキュリティカンファレンスでの講演や業界セキュリティイベントのモデレーターを務める傍ら、数百万ドルの運用コスト削減を実現する AI ソリューションやクラウドトランスフォーメーションの設計に携わっています。仕事以外では、オープンソースのセキュリティツールの開発や、サイバーセキュリティをより身近にするプロジェクトに取り組んでいます。 Adolfo Pica Adolfo Pica は、20 年以上にわたり複雑な IT システムとアーキテクチャの設計、実装、最適化に携わってきたクラウドコンピューティングのエキスパートです。急速に進化する生成 AI と基盤モデルの分野にも強い関心を持ち、実践的な経験を積んでいます。AWS クラウドサービス、DevOps プラクティス、セキュリティ、データ分析、生成 AI に精通しています。プライベートでは、テコンドーとサッカーに励む 2 人の息子たちのスポーツ活動を応援することを楽しんでいます。

Find the “bottleneck” in operations, replace it with an AI agent, measure the results with KPIs, and report. It took us a while to realize that this perfectly rational approach was a breeding ground for failure. In this blog, we share the insights gained over three months of developing AI BPR (AI-driven Business Process Re-Engineering) , a program offered by AWS. AI BPR is a 4–5 hour program designed to restructure business models and operational processes around AI agents. The entire process — facilitation, technical validation, and deliverable creation — is driven by AI agents, enabling rapid and effective business transformation. This blog is translated from the original Japanese article: AI 駆動の業務変革手法 :「課題は何ですか？」と聞くのをやめた日 Why “Doing It Right” Doesn’t Change Organizations AI BPR was born from a simple idea: could we apply the methodology for optimizing the entire software development lifecycle ( AI DLC ) to business operations? We initially launched it as a framework to accelerate the standard steps of business process optimization — designing target outcomes, analyzing workflows, identifying bottlenecks, implementing solutions with AI agents, measuring results, and compiling recommendations — all driven by AI. Step Description Duration Step 1: Goal Identify stakeholders, document adoption decision criteria 30 min Step 2: Focus Visualize scope of focus areas, identify bottlenecks, set constraints 30 min Step 3: Solution Generate and evaluate multiple options, create FAQ 30 min Step 4: Simulation Create scenarios, validate AI agent effectiveness via Kiro Power 30 min Step 5: Challenge Anticipate friction and plan resolution timelines 30 min When we began pitching the program, we received positive feedback about how generative AI accelerated deliverable creation and allowed participants to focus on decision-making. We saw tangible results. But there were also reactions we couldn’t ignore: Delegating operations to AI agents is dangerous from a BCP standpoint. Our business cannot afford downtime. We ran AI BPR, but the solutions stayed within the range of what we’d already considered. It doesn’t feel like a significant leap from our previous analysis. Both seem like legitimate concerns. Yet regarding business continuity, even human-dependent processes carry risks from illness or absence. If downtime is truly unacceptable, AI agents should logically be the more rational choice. As for the latter, it’s a fair assessment from practitioners who think about problems and solutions every day. What concerned us, however, was that they were evaluating generative AI’s proposals as critics rather than engaging with it as a co-creation partner. The surface-level feedback varied, but we noticed a common underlying structure. The first element is a visceral pushback rooted in deep expertise and experience with one’s own work. The suggestion that years of honed expertise might be replaced by AI is received not as a threat to capability, but as a threat to identity. This tendency is supported by Stanford research: among those using generative AI in the workplace, 45% cite concerns about AI accuracy and reliability, while 23% express fear of job displacement. In our conversations with efficiency-focused teams across various companies, this anxiety surfaced regardless of industry. The second element is the psychological desire to maintain trust in “people” as a way to stabilize interpersonal relationships and accountability structures within the organization. The notion that “so-and-so is the expert on this” reflects the organization’s division of responsibility. Delegating to AI agents isn’t merely about replacing tasks — it entails a transfer of accountability. In other words, when operations fail, the responsibility now extends more than ever to the IT function that oversees the AI agents. When these two forces combine, phrases like “this really requires a human touch” or “we need people in charge for crisis situations” function as a convenient “settling point” — one that simultaneously honors experienced practitioners and avoids the transfer of accountability. There are genuinely many tasks that are difficult without human involvement, but this seemingly rational settling point tends to be chosen over the harder challenge of actually confronting that difficulty. What these reactions made clear was that the current AI BPR could not address the real problem. The problem-solving process had simply gotten faster with AI, but the outcomes still landed at the “settling point” with no meaningful change. Speed has value, of course, but accelerating treatment while the diagnosis remains wrong will never lead to a cure. Tear Down, Investigate, Rebuild The first decision we made was to tear down the AI BPR framework. We chose to question the conventional problem-solving and efficiency optimization frameworks and commit to uncovering root causes and pursuing genuine solutions. We weren’t anxious about this because we had a strong intuition: this “something feels off about the right approach not working” couldn’t possibly be unexplored territory. The failure of business transformation has been a recurring structural challenge since BPR was first proposed in 1993. In an IBM survey of 1,532 transformation practitioners, only 41% reported that their projects fully achieved their objectives ( IBM, 2008 ). A 2021 McKinsey survey of 1,034 respondents found transformation success rates hovering around 30% ( McKinsey & Company, 2021 ). Success rates have remained at 30–40% for decades, meaning an enormous body of root-cause analysis and proposed countermeasures must have accumulated. After each AI BPR delivery, we deconstructed participant reactions across four layers: Surface (the words spoken), Experience (what happened during the AI BPR session), Psychology (prior expectations and biases), and Habit (personal experience and disposition). We analyzed which layer each piece of feedback originated from and cross-referenced it with precedents and research. The generative AI–powered analysis reports identifying specific improvements sometimes ran to tens of thousands of characters. The result: the reactions observed in Chapter 1 turned out to be theoretically predictable phenomena . Below, we describe the process of investigation and reconstruction. Theoretical Grounding for Our Observations (This section is somewhat academic, with citations from the literature. If you’re primarily interested in “what we actually changed,” feel free to skip ahead.) The “settling point” of “this really requires a human touch” observed in Chapter 1 has a name in the literature: organizational defensive routines , as discussed by Argyris (1990, 1991). Defensive routines are the actions, policies, and practices unconsciously adopted when individuals encounter situations that could cause embarrassment or threat — in this case, the prospect of job displacement by generative AI or expanded accountability from AI agent adoption. Argyris further noted that this avoidance operates as a refined skill, which he termed skilled incompetence . The problem lies precisely in the fact that because the avoidance is so skillfully executed, people become unaware that they are avoiding the problem at all. The desire for change on one hand, and the desire to protect the current stable state on the other — these opposing motivations cancel each other out, resulting in stasis. This dynamic of settling into equilibrium at the “settling point” is further corroborated by Kegan & Lahey’s (2001, 2009) concept of Immunity to Change . We also learned that breaking through the “settling point” in AI BPR would be difficult with the conventional “Solution”-proposal approach. In the step literally called “Solution,” generative AI “proposes and creates” while humans “review.” This approach is effective for technical problems — those solvable with established expertise and methodologies. However, challenges like anxiety over job displacement or avoidance of accountability transfer — where the transformation of organizational values and behavioral norms is itself what’s required — fall under what Heifetz calls adaptive challenges . Technical problems can be solved when an expert provides the answer, but adaptive challenges cannot be resolved unless the stakeholders themselves undergo a shift in perception. As Heifetz (1994) put it: “The most common cause of failure in leadership is produced by treating adaptive challenges as if they were technical problems.” It was inevitable that AI BPR — built on an approach rooted in software development, a fundamentally technical discipline — would hit this wall. Schein (1999), in his work on Process Consultation, classified problem-solving approaches into three models: 1) the “expert model,” which provides answers (prescriptions); 2) the “doctor-patient model,” which diagnoses and then prescribes; and 3) the “process consultation model,” which develops the client’s own problem-solving capacity. The third model is the best fit for adaptive challenges. Our investigation of the theoretical literature yielded two key findings. First, the “settling point” is not a problem unique to specific individuals or companies — it is a structural defensive response widely observed across organizations. Second, to move beyond the settling point, the entire program needed to be redesigned from a format where participants “receive proposals” to one that elicits their own awareness and judgment. This is the fundamental difference from the similarly named “AI BPO” — simply outsourcing work to AI. Rebuilding AI BPR Following our analysis, AI BPR at the time of writing is structured as a four-step framework characterized by three principles: Strengths-based starting point: Rather than asking “What’s wrong with your current operations?”, we discover the customer value being delivered and the strengths recognized in the market and internally. The question becomes: “How can we amplify these strengths to further enhance customer value?” Psychologically safe role shift: For each element of the business process, participants assess — based on the presence or absence of strengths — whether to “delegate to an AI agent or elevate to excellence.” They actively decide “what to let go of and what to focus on.” Immediate feedback: Through interactive dialogue with AI, deliverables are created with “zero take-home time.” The rebuilt 4 Steps are as follows: Step Description Duration Step 1: Observe Map strengths, value, and risks based on operational interviews and documentation 40 min Step 2: Shift Decompose sub-processes and design transformation scenarios for operations and customer experience based on deliberate judgment 50 min Step 3: Simulate Implement the Shift and measure evaluation improvements 60 min Step 4: Forecast Develop a Shift roadmap based on the velocity of evaluation improvements 20 min Getting started with AI BPR is simple. Each step is driven by prompts and a set of MCPs, so you can begin by simply telling Kiro: “Start AI BPR.” In the redesign, we again drew on prior research. As a concrete process consultation approach to adaptive challenges — which require shifts in mindset — we adopted Appreciative Inquiry , proposed by Cooperrider & Srivastva (1987). Rather than analyzing problems and fixing them, this methodology discovers an organization’s existing strengths and success experiences and amplifies them to drive transformation. Bushe (2007, 2013) argued that Appreciative Inquiry is particularly effective because of its generativity — the capacity for generative dialogue that produces new perspectives, vocabulary, and possibilities that participants did not previously hold, which in turn facilitates “adaptation.” What unexpectedly helped us implement generative dialogue in AI BPR — as dialogue with generative AI driven by prompts — was the well-known KonMari Method. In the KonMari Method, the focus is not on what to discard but on what “sparks joy.” This reframes the question from “What should we eliminate?” — which triggers defensive routines — to “What sparks joy?” (a generative question rooted in success experiences), thereby prompting behavioral change in people around the world when it comes to tidying up. The subject of judgment is always the individual or the organization itself. Items are examined one by one. The accumulation of judgments transforms self-perception. No other familiar success story was better suited for translating these principles into a concrete methodology. That said, the Appreciative Inquiry approach adopted here is not a silver bullet, and it has its critics. Bushe (2007) in particular noted that this approach risks being trivialized into merely “looking at the positive side,” potentially suppressing structural organizational issues and relational dynamics. This parallels how Edmondson’s (1999) concept of psychological safety has long been misunderstood as simply “having a friendly team.” Affirmative intervention is easily misread as superficial “niceness,” causing it to lose its true transformative power. Bushe responded to this critique by redefining the core of Appreciative Inquiry as generativity (Bushe, 2013), and in 2015, together with Marshak, systematized it as Dialogic Organization Development (Bushe & Marshak, 2015). AI BPR’s design — centering on inquiry through AI and deliberately posing “binary choices” of delegate-or-elevate to elicit new perspectives — stands in this lineage of Dialogic OD. Automating Hypothesis Validation for the “Rebuild” There was no guarantee that the radical changes to AI BPR would succeed. At the same time, when delivering to actual customers, we needed to deliver impact in a single session. To reconcile disruptive change with consistent quality, we implemented AI agent–driven dry runs of AI BPR. We created scenarios based on the target customer’s business, participants, and themes — outlining anticipated personas and potential risks. Using these scenarios alongside the AI BPR prompts, we had AI agents execute dry runs and predict reactions at each stage. This is analogous to automated testing (CI/CD) in software development. By validating in advance whether the intended changes, experiences, and effects would materialize, we stabilized quality. We ran a semi-automated cycle of pre-delivery simulation, deep four-layer analysis of actual delivery feedback, and theory-grounded improvement. Starting from a framework that had been reduced to zero, we refined it through this cycle. From the initial implementation in February, the framework underwent more than 40 changes — large and small — over approximately two months to reach its current form, and the refinement continues. The Results of No Longer Asking “What’s Your Problem?” The results showed up in the numbers. Below is a table of satisfaction scores and perceived transformation potential from key deliveries. Client Date Satisfaction Transformation Potential Delivered by Large manufacturer (initial design) March 4.2 / 5.0 4.40 / 7.0 DevRel IT company (early post-change) March 3.63 / 5.0 4.63 / 7.0 DevRel Major logistics company March 4.86 / 5.0 6.71 / 7.0 DevRel Large manufacturer April 4.62 / 5.0 6.08 / 7.0 DevRel Apparel company April 5.00 / 5.0 6.50 / 7.0 Account team From the initial design through the rebuild, satisfaction dipped to 3.63 at one point, but the latest delivery achieved a perfect score of 5.00/5.0, with transformation potential rising from 4.63 to above 6.0. Notably, the latest result came from a delivery led not by the DevRel team that developed the program, but by the account team responsible for the customer — demonstrating the non-person-dependent nature of the AI BPR approach. Here are a few notable episodes from our deliveries. Why a Logistics Executive Volunteered to “Replace” His Own Role In our delivery to a major logistics company, we discovered an AI agent capable of substantially replacing the information gathering and dissemination tasks performed by branch managers at logistics hubs. An executive actively expressed willingness to drive the replacement. Two factors prevented this from triggering defensive reactions. First, the source of the company’s strength was identified as a deep commitment to “keeping promises to customers.” Second, the idea was not proposed by generative AI — it was a “generative” idea that participants arrived at themselves through dialogue and Simulate-based validation. The framing of “What should we focus on to keep our promises?” worked effectively. The feedback we received confirmed this: “If we had approached this from a problem-first perspective, we probably wouldn’t have embraced it this positively.” Visualizing Business Processes in 40 Minutes — Earning Executive Praise at a Manufacturer During a delivery to a major manufacturer, an executive commented that “AI is overwhelmingly better than human consultants for business analysis and visualization.” The time spent organizing business process flows in the Observe step was just 40 minutes. What typically takes hours to days was completed in a fraction of the time. Having experienced this speed and the simplicity of progressing through Q&A, participants spontaneously requested to launch a second team. The experience of immediately conveying their intentions and walking away with deliverables — “zero take-home time” — was the moment that prompted participants’ own behavioral change. Perfect Scores Without the AI BPR Developer Present The delivery to an apparel company was the first case led by the account team rather than the DevRel team that developed the program. The result was the highest satisfaction score to date — 5.00/5.0 (every participant gave a perfect score) — with transformation potential reaching 6.50/7.0. Feedback included: “It felt like we accomplished three days’ worth of tasks in four hours today” and “The fact that you can drive process reform through a chat interface is remarkable.” A report to the CEO was scheduled on the same day. The key facilitation was embedded in the AI agent, allowing the human facilitator to focus solely on course corrections — and that made all the difference. A Refinement Still in Progress: Beyond 40 Years of Research Appreciative Inquiry, the theoretical core of AI BPR, has been supported by theory and has produced results for approximately 40 years. Yet two factors have been cited for why it never achieved widespread adoption: the difficulty of facilitation and clients’ instinctive demand for technical solutions. “Asking questions rather than giving answers” demands real-time responsiveness, unlike the expert model where “answers” can be prepared in advance. This requires high facilitation skill and is difficult to standardize. When organizations face adaptive challenges, they instinctively seek technical solutions. By demanding “Give us the answer” or “Show us the plan,” they externalize the psychological cost of decision-making. AI BPR offers a clear answer to both challenges. By designing the inquiry “in advance” through prompts, it reduces dependence on the facilitator. And through generative AI–powered Simulate and implementation, it can deliver proof of technical feasibility and a plan (Forecast) within hours. As AI BPR becomes more refined, the empirical validation of the theory will accelerate. To get there, we need more experience and more feedback. Co-Creating AI BPR We have begun co-creation activities with AWS Partners who share our conviction in the AI BPR concept and its evolution. With Accel Universe Corporation , we are hosting workshops that integrate data-driven AI agents into business processes through AI BPR. In March, five customers participated, and a second workshop is planned for May. Co-hosted Workshop with AWS Japan: Data Analysis with AI Agent Text2SQL Accel Universe Corporation is a partner with deep strengths in AWS and AI/ML, and we are collaborating on more advanced implementations of AI BPR. In the March session, a major change to AI BPR landed just days before the event — a testament to the kind of partnership that embraces rapid change as a given. This is fundamentally different from a traditional SI engagement of running standardized workshops and implementing fixed use cases. Our ultimate goal is for partners to lead end-to-end process optimization — from executive engagement through AI BPR proposals to enterprise-wide rollout. Additionally, with Stockmark , we are developing a more time-efficient and impactful approach that combines Stockmark’s strengths in manufacturing-focused solutions and models with AI BPR. We have already delivered AI BPR to Stockmark itself, gathering feedback and jointly refining the methodology. AWS positions this activity — delivering AI BPR alongside solution providers like Stockmark to refine both the methodology and the solutions — as the “Forward Deployment Support Program.” Internally at AWS, we have conducted AI BPR training so that account teams can propose and deliver it when they see the need, with over 60 participants to date. For large-scale organizations, this requires designing company-wide KPIs and orchestrating across stakeholders in each division. In some cases, enterprise-wide governance of the agents being built is also necessary. To address these needs, we are working with the ProServe team to develop a dedicated service offering. Amazon founder Jeff Bezos famously said that the key is to focus on “what won’t change in ten years.” As noted at the outset, the success rate of business transformation has remained stuck at 30–40% for decades — it hasn’t changed. We aim for the moment when this “thing that hasn’t changed” finally does — through the convergence of the theories that organizational transformation researchers have built over decades, generative AI, and the partnership of AWS Partners who embrace change and challenge. If you’re interested in applying AI BPR to your own business transformation, or if you’re motivated to co-create with AWS, please reach out to your AWS account team. If you’d like to discuss the theories and knowledge behind AI BPR presented in this article, I’d be happy to hear from you directly. References Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning . Allyn & Bacon. Argyris, C. (1991). Teaching smart people how to learn. Harvard Business Review , 69(3), 99–109. https://hbr.org/1991/05/teaching-smart-people-how-to-learn Bushe, G. R. (2007). Appreciative Inquiry is not (just) about the positive. OD Practitioner , 39(4), 30–35. https://www.gervasebushe.ca/AI_pos.pdf Bushe, G. R. (2013). Generative process, generative outcome: The transformational potential of Appreciative Inquiry. In D. L. Cooperrider, D. P. Zandee, L. N. Godwin, M. Avital, & B. Boland (Eds.), Organizational Generativity: The Appreciative Inquiry Summit and a Scholarship of Transformation (pp. 89–113). Emerald. https://gervasebushe.ca/AI_generativity.pdf Bushe, G. R., & Marshak, R. J. (Eds.). (2015). Dialogic Organization Development: The Theory and Practice of Transformational Change . Berrett-Koehler. https://www.bkconnection.com/books/title/dialogic-organization-development Cooperrider, D. L., & Srivastva, S. (1987). Appreciative Inquiry in organizational life. Research in Organizational Change and Development , 1, 129–169. https://www.researchgate.net/publication/265225217_Appreciative_Inquiry_in_Organizational_Life De Smet, A., Pacthod, D., Relyea, C., & Sternfels, B. (2021, December 7). Losing from day one: Why even successful transformations fall short. McKinsey & Company . https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly , 44(2), 350–383. https://doi.org/10.2307/2666999 Heifetz, R. A., Grashow, A., & Linsky, M. (2009). The Practice of Adaptive Leadership. Harvard Business Review Press. https://www.hks.harvard.edu/publications/practice-adaptive-leadership-tools-and-tactics-changing-your-organization-and-world IBM Global Business Services. (2008). Making Change Work: Continuing the Enterprise of the Future Conversation . IBM Corporation. https://public.dhe.ibm.com/software/be/Making_Change_Work_eff.pdf Kegan, R., & Lahey, L. L. (2001). The real reason people won’t change. Harvard Business Review , 79(10), 84–92. https://hbr.org/2001/11/the-real-reason-people-wont-change Kegan, R., & Lahey, L. L. (2009). Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization. Harvard Business Press. https://store.hbr.org/product/immunity-to-change-how-to-overcome-it-and-unlock-the-potential-in-yourself-and-your-organization/1736 Kondo, M. (2011). The Life-Changing Magic of Tidying Up . Ten Speed Press, 2014. https://www.penguinrandomhouse.com/books/240981/the-life-changing-magic-of-tidying-up-by-marie-kondo/ Schein, E. H. (1999). Process Consultation Revisited: Building the Helping Relationship . Addison-Wesley. Shao, Z. et al. (2025). Future of work with AI agents: Auditing automation and augmentation potential across the U.S. workforce. Stanford SALT Lab. https://arxiv.org/abs/2506.06576

業務の「ボトルネック」を見つけて AI エージェントに置き換える。成果を KPI で測り報告する。この至極正当なアプローチが「失敗の温床」であることに気づくのに時間がかかりました。 本ブログでは、AWS が提供している AI 駆動の業務変革手法である AI BPR (AI-driven Business Process Re-Engineering) というプログラムの 3 ヶ月の歩みの中で得られた知見を共有します。AI BPR は、ビジネスモデル/業務プロセスを AI エージェント前提に組み替えるための 4~5 時間のプログラムです。ファシリテート、技術検証、成果物作成といったプロセス全体を AI エージェント駆動で実施し迅速かつ効果的な業務変革を実現します。 なぜ「正しいアプローチ」で組織は変わらないのか AI BPR は、ソフトウェア開発サイクル全体の最適化手法 ( AI DLC )をビジネスに適用できないかという素朴なアイデアから生まれました。到達目標の設計、業務フローの分析、ボトルネックの特定、AI エージェントによる解決策の実装、計測、解決案のまとめ。これら業務プロセス最適化のステップを、AI 駆動で高速化するフレームワークとして当初開始しました。 Step 内容 所要時間 Step 1: Goal ステークホルダー特定、採用決定基準の文書化 30分 Step 2: Focus 注力業務範囲の可視化とボトルネック特定、制約条件設定 30分 Step 3: Solution 複数案生成・評価、FAQ 作成 30分 Step 4: Simulation シナリオ作成、Kiro Power による AI エージェント効果検証 30分 Step 5: Challenge 摩擦の予測と解決のスケジュール検討 30分 提案を始めると、生成 AI による成果物作成の高速化と意思決定への集中に期待の声をいただき、一定の効果も実感いただけました。その一方で、見逃せない反応もいくつかありました。 AI エージェントに業務を任せるのは、BCP の観点で危険である。我々のビジネスは止まることが許されない AI BPR を実施してみたが、予想した解決策の枠内にとどまった。これまでの検討に比べて大きな進歩を感じない いずれも正当な主張に思えます。しかし、事業継続性については人間にプロセスを残しても体調不良や欠勤によるリスクがあります。止まることが許されないならば本来 AI エージェントの活用は合理的なはずです。後者は、課題と解決策について常日頃考えている担当者であれば妥当な評価です。一方、生成 AI の提案を批評家目線でとらえて共創相手として扱っていない点が気がかりでした。 表面的なフィードバックは多様ですが、深層に共通する構造があることに気づきました。 1つは、担当している仕事に対する知見と経験から来る素朴な反発です。長年磨いてきた専門性が AI で代替されるかもしれないという示唆は、能力への脅威ではなくアイデンティティへの脅威として受け取られます。この傾向は Stanford の研究でも示唆されています。生成 AI を職場で活用する上で 45% が AI の精度・信頼性への懸念を、23% は職の代替への恐怖を挙げています。実際、様々な企業で効率化に取り組む部署の方とお話しすると、業種に限らずこの不安に直面していると言われます。 もう1つは、「人間」に信頼を置くことで組織内の人間関係や責任の所在を安定させたいという心理です。「この業務は○○さんが詳しい」という構造は、組織内の責任分担の現れであり、AI エージェントへの委譲は単に業務の代替だけでなく「責任の委譲」も伴います。つまり、業務停止時の責任が AI エージェントを管轄する IT にもこれまで以上に波及するということです。 この2つが合わさると、「やっぱり人間でないと難しい」「危機対応時を考えると人間が担うべき」といった言葉が経験者を尊重すると共に責任移動を回避する都合のよい「落としどころ」として機能します。人間でないと困難な業務は本当に多くありますが、その「困難」への挑戦よりこの一見合理的な落としどころが選択されやすくなります。 これらの反応を通じて認識したのは、現状の AI BPR では真の問題を解決できないということでした。問題解決プロセスが AI で速くなっただけで、そのアウトカムは結局「落としどころ」に留まり大きな変化が見られない。もちろん速くなることに価値はありますが、誤った診断のまま処置のスピードだけ速くなっても根治することはありません。 壊す、調べる、組み直す まず決めたのが、AI BPR の構成を壊すということでした。通常の問題解決や効率化のフレームワークを疑い、根本原因の解明と解決に向けたチャレンジを続ける選択をしました。 不安がなかったのは、この「正しいアプローチが機能しない違和感」が過去に一度も検討されたことがないはずはない、という予想があったからです。業務変革の失敗は 1993 年に BPR が提唱されて以来、繰り返し議論されてきた構造的な課題です。IBM が 1,532 名の変革実務者を対象に行った調査では、担当プロジェクトのうち目標を完全に達成したのは 41% ( IBM, 2008 ) に留まっています。McKinsey が 1,034 名を対象に 2021 年に実施した調査でも変革の成功率は 30% 前後です ( McKinsey & Company, 2021 )。数十年を経て成功率は 30~40% に留まっているといえ、この間に膨大な原因の分析と対策の提案が蓄積されているはずです。 AI BPR を提供するたびに、参加者の反応を 4 層で分解しました。Surface (発せられた言葉)、Experience (AI BPR 体験中の出来事)、Psychology (事前の期待・バイアス)、Habit (個人の経験や気質) に分解し、フィードバックがどの階層に由来するか分析し、先行事例と研究による裏付けを行いました。生成 AI による分析と具体的改善点を特定するレポートは、時に数万文字に及んでいます。 その結果、第一章で観測した反応は 理論的に予測可能な現象 であることがわかりました。以下では、調べ組み直す過程を記載します。 観察の理論的裏付け このセクションは論文の引用もあり少し専門的です。「具体的にどう変えたか」に関心がある方は読み飛ばして頂いて構いません 第一章で観察した「やっぱり人間でないと難しい」という「落としどころ」には Argyris (1990, 1991) が論じた 防衛的ルーティン(organizational defensive routines) という名前がついています。防衛的ルーティンは困惑や脅威を感じうる状況、この場合生成 AI による職の代替や AI エージェントの導入による責任範囲の拡大、が発生した際に無意識のうちに取られる行動・方針・慣行です。Argyris はさらに、この回避が磨き上げられた技術として機能する点を指摘し、これを 熟達した無能力 (skilled incompetence) と呼んでいます。熟達しているがゆえに、問題を避けていること自体に気づかなくなる点に課題があります。変化したい、一方で現在の安定状況を守りたい、という表裏の動機が相殺し結果として動かない、まさに「落としどころ」に安定する様は後続の Kegan & Lahey (2001, 2009) による変化への免疫 (Immunity to Change)でも裏付けられています。 AI BPR で「落としどころ」を抜けるには、従来の “Solution” 提案型では困難なこともわかりました。文字通り Solution という工程では生成 AI に「提案/作成」させ人間が「確認」する構造を取っています。これは既知の専門知識と方法論で解ける技術的課題 (technical problem) に有効なアプローチです。一方、業務代替への不安や責任移動の回避のように、組織や働く人の価値観や行動様式の変容そのものが求められる課題は、Heifetz の言う 適応課題 (adaptive challenge) に該当します。技術的課題は専門家が答えを提供すれば解けますが、適応課題は当事者自身の認識が変わらない限り解決しません。Heifetz (1994) はこう述べています。 “The most common cause of failure in leadership is produced by treating adaptive challenges as if they were technical problems.” ソフトウェア開発という技術的課題が主軸のアプローチをベースにした AI BPR がこの壁に直面するのは必然でした。 Schein (1999) はプロセス・コンサルテーションにて課題解決のアプローチを 1) 答え(薬)を提供する「専門家モデル」、2) 診断の上で処方を行う「医師 – 患者モデル」 3) クライアント自身の問題解決能力を開発する「プロセス・コンサルテーションモデル」の 3 つに分類しています。適応課題にはこの 3 が最も整合します。 理論研究の調査から判明したことは大きく 2 点です。一点目は、「落としどころ」で止まるのは個人や特定企業の問題ではなく、組織に広く観察される構造的な防衛反応であるということ。二点目は、落としどころを超えていくにはプログラム全体を「提案を受ける」場ではなく当事者自身の気づきと判断を引き出すアプローチに組み換える必要があるということです。ここに、似たキーワードである “AI BPO”、単に AI へ仕事をアウトソースする方式との最大の違いがあります。 AI BPR を「組み直す」 分析を経て、執筆時点で AI BPR は次の 3 点を特徴とする 4 ステップのフレームワークで構成されます。 強み起点 : 今の業務の何が「問題」か ? ではなく、提供できている顧客価値、市場や社内で認知されている強みを発見する。どのように強みを強化し顧客価値をより高めることができるのか ? を考える 心理的安全なロールシフト : 業務プロセスを構成する要素について、強みの有無から「AI エージェントに委譲するか価値を高め卓越させるか」を一つ一つ判断し「何を手放し何に集中するか」を能動的に決定する 即時的フィードバック : AI とのインタラクティブな会話で成果物を「持ち帰り時間ゼロ」で作成する 組み直し後の 4 Step は次の通りです。 Step 内容 所要時間 Step 1: Observe 業務ヒアリングと資料に基づく強み、価値、リスクのマッピング 40分 Step 2: Shift サブプロセス分解と判断に基づく業務と顧客体験の変革シナリオ設計 50分 Step 3: Simulate Shift の実装と評価の改善を計測 60分 Step 4: Forecast 評価改善の Velocity に基づく Shift 計画の立案 20分 AI BPR を始める方法は簡単です。各ステップの実行はプロンプトといくつかの MCP により駆動されるため、例えば Kiro に “AI BPR をはじめて” というだけで始められます。 組み直しにあたっても、先行研究を参照しました。考え方の変容を促す適応課題に対するプロセス・コンサルテーションの具体的アプローチとして、Cooperrider & Srivastva (1987) が提唱した Appreciative Inquiry を採用しています。これは問題を分析して修正するアプローチを切り替え、 組織の既存の強みと成功体験を発見し、それを増幅する ことで変革を実現する手法です。Bushe (2007, 2013) は Appreciative Inquiry が特に機能するのはその 生成性 (generativity) にあると論じています。参加者が従来持たなかった新しい視点・語彙・可能性を生み出す生成的対話が「適応」に有効であるということです。 生成的対話を AI BPR、プロンプトに基づく生成 AI との対話として実装するのに役立ったのは、意外にもよく知られるコンマリメソッドでした。コンマリメソッドでは、捨てるものではなく「ときめくもの (spark / not spark)」に注目します。これは、防衛的ルーティンを誘発する「何を捨てるか」という問いかけではなく、「何にときめくか」(成功体験に根付く生成的問い)を問うことで片づけに対する世界中の人の行動変容を促しています。判断の主語が常に本人/自組織にあること。一つ一つ手に取ること。判断の積み重ねで自己認識が変わること。上記の原則を具体的な方法論に翻訳するのに、この身近な成功例ほど適したものはありませんでした。 一方、今回取り上げた Appreciative Inquiry は銀の弾丸ではなく批判もあります。特に Bushe (2007) は、このアプローチが単にポジティブなところだけ見る活動に矮小化され、組織の構造的な課題や関係性を抑圧しうる点を指摘しました。これは、Edmondson (1999) の心理的安全性が長年「仲の良いチーム」と誤解され続けてきたことと構造が重なります。肯定的介入は、表層的な「優しさ」により容易に誤解され本来の変革の力を失うということです。 Bushe はこの批判に自ら応える形で、先に述べた通り Appreciative Inquiry の中核が生成性 (generativity)にあると再定義し (Bushe, 2013)、 2015 年に Marshak と共に Dialogic Organization Development として体系化しています (Bushe & Marshak, 2015)。AI BPR が AI との問いかけを中核に据え、委譲・卓越の識別を「あえて 2 択で問う」ことで新しい視点を引き出す設計は、この Dialogic OD の系譜に連なります。 「組み換え」の仮説検証の自動化 AI BPR の破壊的な変更は成功する保証がありませんでした。一方で、実際のお客様に提供する際は一回で効果を体験頂く必要があります。破壊的変更と効果の安定を両立させる方法として、AI エージェントによる AI BPR の Dry Run を実装しました。提供を予定しているお客様の事業内容や参加者、テーマから想定されるペルソナと発生しうるリスクをまとめたシナリオを作成します。そのシナリオと AI BPR のプロンプトを用い、AI エージェントに Dry Run を実行させ各工程の反応を予測させました。ソフトウェア開発での自動テスト (CI/CD) に近い仕組みです。この仕組みにより想定した変化・体験・効果があるかを事前に検証することで品質を安定させました。 事前のシミュレーションと、実際のデリバリーで得られたフィードバックを 4 階層で深掘りし、理論的裏付けを基に改善するサイクルを半自動で回転させました。一度ゼロベースになったフレームワークを、このサイクルで洗練させていきました。初回の実装を行った 2 月からの約 2 ヵ月で大小含め 40 回以上の変更を経て現在の形になり、その改善は今も続いています。 「課題は何ですか？」と聞くのをやめた成果 結果は、数字に現れました。以下がキーポイントとなった提供ごとの満足度、AI BPR を通じた業務変革の可能性を表にしたものです。 提供先 日付 満足度 変革可能性 提供者 大規模製造企業 (初期設計) 3月 4.2 / 5.0 4.40 / 7.0 DevRel IT 企業 (変更初期) 3月 3.63 / 5.0 4.63 / 7.0 DevRel 大規模物流企業 3月 4.86 / 5.0 6.71 / 7.0 DevRel 大規模製造業 4月 4.62 / 5.0 6.08 / 7.0 DevRel アパレル企業 4月 5.00 / 5.0 6.50 / 7.0 アカウントチーム 初期設計から組み直しを経て、一度満足度が 3.63 と下がったものの、最新では 5.00 のフルスコア、変革可能性は 4.63 から 6 点以上へ推移しました。特に最新の結果は開発した DevRel ではなくお客様を担当するアカウントチームからの提供であり AI BPR のアプローチの非属人性を示す例となっています。提供の中から、いくつか印象的なエピソードを紹介します。 物流企業の役員が自ら「置き換えたい」と言った理由 大規模物流企業様への提供では、物流拠点の支店長が行っている情報の収集と伝達業務を大幅に代替できる AI エージェントの発見に役員の方からも積極的な置き換え推進の意欲が示されました。このような防衛反応を生みかねない方針が生まれた背景には 2 つのポイントがありました。初めに、強みの源泉が「顧客との約束を守る」ことに対する強いコミットメントにあると特定されたこと。次に、生成 AI から提案したのではなく対話と Simulate による検証で自ら考え出した「生成的な」アイデアであったことです。約束を守るために何に集中すべきか、という問いのフレームが機能し、実際に「課題起点で考えていたらこれだけポジティブに受け入れられなかったかもしれない」とフィードバックを頂きました。 40 分で業務プロセスを可視化し、製造業役員から評価 大手製造業様へのデリバリーでは、役員の方から「業務分析・可視化は人間のコンサルタントより圧倒的に AI が良い」という評価をいただきました。この時、Observe で業務プロセスフローの整理にかかった時間はわずか 40 分でした。一般的に数時間から数日かかる業務整理が圧倒的短時間で完了しました。この速度と質問回答による簡易な進行を体験したことで、参加者側から自発的に 2 チーム目を立ち上げたい要望が上がりました。自らの意向を即時的に伝え「持ち帰り時間ゼロ」で成果物が手元に残る体験が参加者自身の行動変容を促した瞬間でした。 AI BPR 開発者なしの提供で全員満点の評価 アパレル企業様へのデリバリーは、プログラムを開発した DevRel ではなくアカウントチームが主導した初のケースでした。結果は、DevRel の提供も含めて過去最高の満足度である 5.00/5.0 (全員満点)、変革可能性も 6.50/7.0 に達しました。「今日 4 時間で 3 日分のタスクを終えた感覚」「チャットベースでプロセス改革ができてしまう」とフィードバックいただき、当日中に社長への報告会を設定することが決まりました。主なファシリテーションは AI エージェントに組み込まれており、人間のファシリテーターは注意点の修正のみに集中できることが大きな力を発揮しました。 途上にある洗練 : 40 年の研究の先へ AI BPR の中核となっている Appreciative Inquiry は約 40 年にわたって理論的に支持され成果もあげてきました。一方で広まらなかった理由にファシリテーションの困難さと顧客側の技術的課題への渇望が指摘されています。 「答えを与えるのではなく問いかける」ことは、事前に「答え」を作り込める専門家型のアプローチに比べその場での即時性が求められる。そのため高いファシリテーションスキルが必要で、標準化も難しい 組織が適応課題に直面したとき、本能的に技術的解決を求める傾向がある。「答えをくれ」「計画を出せ」と要求することで意思決定の心理的コストを外部化している AI BPR は、この 2 つの課題に明確な回答を提示します。プロンプトで問いの設計を「事前に」行うことでファシリテーターへの依存を下げ、生成 AI による Simulate/実装により技術的な課題についても解決の実証と計画 (Forecast) を数時間以内に出すことができます。AI BPR がより洗練されることで、理論の実証は加速度的に進むでしょう。そのためには、より多くの経験とフィードバックを得る必要があります。 AI BPR の共創 現在、AI BPR のコンセプトと進化に共感頂けた AWS パートナー様との共創活動を始めています。 アクセルユニバース 様とは AI BPR を通じデータ駆動の AI エージェントを業務プロセスに組み込むワークショップを開催しています。3 月には 5 社のお客様に参加いただき、5 月にも二度目のワークショップを開催予定です。 AWS Japan様と共催ワークショップ AIエージェントText2SQLでデータ分析 アクセルユニバース様は AWS はもちろん AI/ML の領域に強みを持つパートナー様で、AI BPR のより高度な実装に向け連携しています。3 月の開催では数日前に AI BPR の大規模な変更が発生するなど、激しい変化を前提に連携させて頂いています。型化したワークショップを開催し固まったユースケースを実装していく SI 的な連携とは根本的に異なります。最終的には、AI BPR 提案を通じた役員エンゲージメントからの全社プロセス最適化を主導頂けるようになることをゴールと考えています。 また、 Stockmark 様とは Stockmark 様の強みである製造業向けのソリューション・モデルと AI BPR を組み合わせたより短時間で実効性の高いアプローチを開発しています。すでに Stockmark 様自身へ AI BPR の提供をさせて頂き、フィードバックを得て共同で改善をしています。 AWS は、Stockmark 様のようなソリューションプロバイダのお客様と共に AI BPR を提供し AI BPR で得られたフィードバックでソリューションを洗練させる活動を支援しています。この “ AWS Forward Deployment 支援プログラム ” の提供もまさに始まっているところです。Forward Deployment 支援プログラムでは、サービス導入先のお客様への AI BPR 提供、そこから得られらフィードバックをプロダクト (Agent) に反映するプロセスを ML Enablement Workshop で支援させて頂きます。 AWS の内部でも、アカウントチームが必要と感じたときに提案・実施できるよう AI BPR のトレーニングを実施し、60 名以上に参加いただいています。大規模な組織では、全社的な KPI の設計や各部署のステークホルダーを把握したうえでのオーケストレーションが必要になります。また、構築される Agent の全社的な管理が求められるケースもあります。こうしたニーズに備え、ProServe のチームとも連携し専用のメニューを構築予定です。 Amazon の創業者である Jeff Bezos は、「10 年経っても変わらないものは何か」に集中することこそが重要と説きました。冒頭お伝えした通り、業務変革の成功率は数十年を経て 30~40% に滞留し変わっていません。この「変わらないもの」が、組織変革の研究者たちが積み重ねてきた理論と生成 AI、そして変化と挑戦を受け入れて下さる AWS パートナー様との連携により「変わる」瞬間を目指していきたいと思います。 AI BPR を自社の業務変革に活用してみたい方、あるいは AWS との共創活動に意欲をお持ちの方は、担当の AWS アカウントチームまでお気軽にお問い合わせください。本記事で紹介した理論や AI BPR のナレッジについて議論したい方は筆者までご連絡いただければ幸いです。 参考文献 Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning . Allyn & Bacon. Argyris, C. (1991). Teaching smart people how to learn. Harvard Business Review , 69(3), 99–109. https://hbr.org/1991/05/teaching-smart-people-how-to-learn Bushe, G. R. (2007). Appreciative Inquiry is not (just) about the positive. OD Practitioner , 39(4), 30–35. https://www.gervasebushe.ca/AI_pos.pdf Bushe, G. R. (2013). Generative process, generative outcome: The transformational potential of Appreciative Inquiry. In D. L. Cooperrider, D. P. Zandee, L. N. Godwin, M. Avital, & B. Boland (Eds.), Organizational Generativity: The Appreciative Inquiry Summit and a Scholarship of Transformation (pp. 89–113). Emerald. https://gervasebushe.ca/AI_generativity.pdf Bushe, G. R., & Marshak, R. J. (Eds.). (2015). Dialogic Organization Development: The Theory and Practice of Transformational Change . Berrett-Koehler. https://www.bkconnection.com/books/title/dialogic-organization-development Cooperrider, D. L., & Srivastva, S. (1987). Appreciative Inquiry in organizational life. Research in Organizational Change and Development , 1, 129–169. https://www.researchgate.net/publication/265225217_Appreciative_Inquiry_in_Organizational_Life De Smet, A., Pacthod, D., Relyea, C., & Sternfels, B. (2021, December 7). Losing from day one: Why even successful transformations fall short. McKinsey & Company . https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly , 44(2), 350–383. https://doi.org/10.2307/2666999 Heifetz, R. A., Grashow, A., & Linsky, M. (2009). The Practice of Adaptive Leadership. Harvard Business Review Press. https://www.hks.harvard.edu/publications/practice-adaptive-leadership-tools-and-tactics-changing-your-organization-and-world IBM Global Business Services. (2008). Making Change Work: Continuing the Enterprise of the Future Conversation . IBM Corporation. https://public.dhe.ibm.com/software/be/Making_Change_Work_eff.pdf Kegan, R., & Lahey, L. L. (2001). The real reason people won’t change. Harvard Business Review , 79(10), 84–92. https://hbr.org/2001/11/the-real-reason-people-wont-change Kegan, R., & Lahey, L. L. (2009). Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization. Harvard Business Press. https://store.hbr.org/product/immunity-to-change-how-to-overcome-it-and-unlock-the-potential-in-yourself-and-your-organization/1736 Kondo, M. (2011). 『人生がときめく片づけの魔法』 サンマーク出版. (English edition: The Life-Changing Magic of Tidying Up . Ten Speed Press, 2014.) https://www.penguinrandomhouse.com/books/240981/the-life-changing-magic-of-tidying-up-by-marie-kondo/ Schein, E. H. (1999). Process Consultation Revisited: Building the Helping Relationship . Addison-Wesley. Shao, Z. et al. (2025). Future of work with AI agents: Auditing automation and augmentation potential across the U.S. workforce. Stanford SALT Lab. https://arxiv.org/abs/2506.06576

本記事は 2026 年 4 月 17 日 に公開された「 Track Amazon Bedrock Costs by Caller Identity with IAM Principal-Based Cost Allocation 」を翻訳したものです。 Amazon Bedrock での生成 AI 利用が拡大すると、「Bedrock のコストを押し上げているのはどのチーム、アプリケーション、ユーザーか？」という疑問が生まれます。これまでは、 AWS CloudTrail ログと請求データを手動で突き合わせ、API コールを特定の ID にマッピングする必要がありました。時間がかかり、ミスが起きやすく、大規模な運用では維持が困難です。 AWS は Amazon Bedrock 向けの AWS Identity and Access Management (IAM) プリンシパルベースのコスト配分を発表しました。Bedrock API コールごとに呼び出し元 (IAM ユーザーまたはロール) の ID を AWS Cost and Usage Report (CUR 2.0) と AWS Cost Explorer に自動的に記録する機能です。カスタムツールなしで、API コールを実行した IAM プリンシパルごとに Bedrock モデルの支出を追跡、配分、最適化できます。 本記事では、この機能の仕組み、セットアップ方法、Amazon Bedrock コストをきめ細かく可視化する方法を説明します。 IAM プリンシパルベースのコスト配分が重要な理由 複数のチーム、アプリケーション、ユーザーが同じ AWS アカウントを共有して基盤モデルを呼び出すケースは珍しくありません。プリンシパルレベルのコスト帰属がなければ、Bedrock のコストは単一の明細項目として表示され、次のような疑問に答えることが困難です。 Anthropic Claude で最もトークンを消費しているチームはどこか？ 顧客向けチャットボットと社内の要約ツールでは、どちらのコストが高いか？ Bedrock のコストを正しい部門やプロジェクトにチャージバックできるか？ IAM プリンシパルベースのコスト配分は、Bedrock API コールの実行者を自動的に記録し、その ID と IAM プリンシパルに付与されたタグを対応するコストおよびトークン使用量に関連付けることで、上記の課題を解決します。 具体的には次のことが可能です。 Bedrock モデルを呼び出している IAM ユーザーやロールの特定 Bedrock モデルの使用状況を部門、チーム、プロジェクトなどの組織構造にマッピング Bedrock モデル費用の実際の利用部門への費用配賦（Chargeback）と部門別コストの可視化（Showback） プリンシパルごとの使用パターン分析による最適化機会の発見 仕組み CUR 2.0 データエクスポートで IAM プリンシパルデータを有効にすると、AWS は Bedrock API コールごとに呼び出し元の ID を自動的に記録します。有効化後、CUR 2.0 で次のデータを利用できます。 line_item_iam_principal : Bedrock API コールごとの呼び出し元の IAM ARN を含む新しいカラム (例: arn:aws:iam::123456789012:user/username や arn:aws:sts::123456789012:assumed-role/rolename/session-name ) IAM プリンシパルタグ: 呼び出し元の IAM プリンシパルに付与され、コスト配分タグとして有効化されたタグが、Tags カラムに iamPrincipal / プレフィックス付きで表示されます (例: department と costCenter をコスト配分タグとして有効化すると、 iamPrincipal/department 、 iamPrincipal/costCenter として表示) Cost Explorer でも IAM プリンシパルのコスト配分タグでコストのグループ化やフィルタリングが可能です。ディメンションとして Tag を選択し、該当する “IAM principal” タグ (例: iamPrincipal/department ) を選ぶと、部門、チーム、プロジェクトなど定義したタグディメンションごとに Bedrock モデルの支出を確認できます。 はじめに Amazon Bedrock の IAM プリンシパルベースのコスト配分は 3 つのステップでセットアップできます。 前提条件 開始前に以下を確認してください。 Amazon Bedrock API コールに IAM ユーザーまたはロールを使用していること IAM コンソールと Billing and Cost Management コンソールへのアクセス権があること CUR 2.0 データエクスポートが設定済みであること (または作成権限があること) 重要: IAM プリンシパルベースのコスト配分は、Billing and Cost Management コンソールで管理アカウントレベルで有効化する必要があります。 AWS Organization のメンバーアカウントが個別に有効化することはできません。 ステップ 1: IAM プリンシパルにタグを付与する まず、Bedrock API を呼び出す IAM ユーザーとロールに、わかりやすく標準化されたキーでタグを付与します。 1. IAM コンソールに移動します 2. Bedrock API を呼び出す IAM ユーザーまたはロールを選択します 3. Tags タブで department、costCenter、team、project などのキーでタグを追加します (図 1 参照) 4. 該当する IAM プリンシパルに対して繰り返します 図 1: IAM ロールにタグを付与する IAM コンソール画面 ヒント: 低カーディナリティで分かりやすいタグ値を使用してください。department=engineering や costCenter=CC-1234 のようなタグが理想的です。セッション ID やタイムスタンプのような高カーディナリティの値は、Cost Explorer でのカーディナリティ増大や CUR ファイルサイズの肥大化につながるため避けてください。 ステップ 2: コスト配分タグを有効化する 次に、Billing コンソールでタグを有効化し、コストレポートに表示されるようにします。タグが有効化の対象として表示されるのは、そのタグが付与された IAM プリンシパルが少なくとも 1 回 API コールを実行した後です。IAM ユーザー、ロール、ロールを引き受けたセッションのいずれでも同様です。 5. Billing and Cost Management コンソール に移動します 6. Cost Allocation Tags に移動します 7. ステップ 1 で付与した IAM プリンシパルタグを見つけます 8. タグを選択して Activate を選びます (図 2 参照) 図 2: Cost Allocation Tags の有効化ページを表示する Billing コンソール画面 注意: タグの有効化後、Cost Explorer と CUR レポートにタグが表示されるまで最大 24 時間かかる場合があります。 ステップ 3: CUR 2.0 で IAM プリンシパルデータを有効にする 最後に、CUR 2.0 エクスポートに呼び出し元の ID データを含めるよう設定します。 9. Billing and Cost Management コンソール で Data Exports に移動します 10. 新しい CUR 2.0 エクスポートを作成します 11. “Include caller identity (IAM principal) allocation data” オプションを選択します (図 3 参照) 12. エクスポート設定を保存します 重要: IAM プリンシパルのコスト配分を有効にしても追加料金は発生しません。ただし、この機能を有効にすると CUR ファイルサイズが増加します。以前は 1 行だったコスト明細項目が、使用量に貢献した IAM プリンシパルごとに複数行に展開されるためです。多数の異なるプリンシパルによる大量の使用パターンでは、S3 ストレージコストが大幅に増加する可能性があります。これを踏まえて、古い CUR ファイルに対する S3 ライフサイクルポリシーの適用を検討してください。 図 3: IAM プリンシパル配分データのチェックボックスを表示する Data Exports 設定ページ コストデータの確認 セットアップが完了しデータが流れ始めたら (最大 24 時間)、Cost Explorer と CUR 2.0 レポートの 2 つの方法で IAM プリンシパルごとの Bedrock コストを分析できます。 Cost Explorer での確認 13. AWS Cost Explorer に移動します 14. ディメンションとして Tag を選択します (図 4 参照) 15. 該当する “IAM Principal” タグ (例: iamPrincipal/costCenter ) を選びます 16. 選択したタグディメンションごとの Bedrock モデル支出の内訳を確認します 図 4: IAM プリンシパルタグごとの Bedrock 支出内訳を表示する Cost Explorer チャート CUR 2.0 レポートでの確認 Amazon Athena や任意の分析ツールで CUR 2.0 データをクエリします。 line_item_iam_principal カラムには Bedrock 推論コストごとの完全な IAM ARN が含まれ、Tags カラムの iamPrincipal/ プレフィックス付きタグでタグディメンションごとにコストを分割できます。 ゲートウェイアーキテクチャへの対応 多くの組織では、Amazon Bedrock API コールを Amazon API Gateway 、カスタムプロキシ、共有内部サービスなどの中間ゲートウェイ経由でルーティングしています。このアーキテクチャでは、CUR 2.0 に記録される IAM プリンシパルはエンドユーザーの ID ではなくゲートウェイの実行ロールになります。そのため、Bedrock コストが単一の IAM ロールに集約されて表示される場合があります。 Bedrock コストが 1 つの IAM ロールにまとまっている場合、ゲートウェイ経由のアクセスが原因と考えられます。ゲートウェイパターンでコストの可視性を維持するための戦略を紹介します。 コンシューマーグループごとに個別の IAM ロールを使用する ゲートウェイの背後にあるチームやアプリケーションごとに個別の IAM ロールを割り当てます。ゲートウェイの実装を変更することなく、コスト帰属の粒度を維持できます。 ゲートウェイの実行ロールにタグを付与する 共有ロールを使用している場合でも、IAM プリンシパルタグ (department や application など) を付与してコストを適切なビジネスユニットにマッピングできます。 セッションタグで動的な帰属を実現する ゲートウェイの背後で最もきめ細かなコスト帰属を実現するには、セッションタグが有効です。ゲートウェイが AssumeRole で共有 IAM ロールを引き受ける際、セッションタグをパラメータとして渡すことで、そのセッションのロールの既存タグを上書きできます。 仕組みは次のとおりです。 ゲートウェイアプリケーションが AssumeRole または同様の AWS Security Token Service (STS) API を呼び出します ロールの引き受け時に、アプリケーションがセッションタグ (例: department=engineering、project=devx-v2、costCenter=CC-1234) を渡します セッションタグがそのセッションの対応する IAM ロールタグを上書きします そのセッション中の Bedrock API コールがセッションタグの値で CUR 2.0 に記録されます 共有ゲートウェイロール経由でも、アプリケーション、プロジェクト、部門レベルでのコスト配分が可能になります 注意: Bedrock はタグの和集合、つまり複数のタグソースを統合して記録します。元の IAM プリンシパルタグ、上書きされたタグ、セッション中に追加された新しいタグが含まれます。セッションタグは一致するタグキーの上書きや新しいタグの追加が可能ですが、既存の IAM プリンシパルタグを選択的に削除することはできません。ロール引き受け時のセッションタグの渡し方の詳細は、 セッションタグに関する AWS ドキュメント を参照してください。 ベストプラクティス IAM プリンシパルベースのコスト配分を効果的に実装するためのベストプラクティスです。 低カーディナリティのタグキーを使用する 。department、costCenter、project のようなタグが理想的です。頻繁に変わる値やリクエストごとに一意な値は避けてください。 命名規則を標準化する 。コスト配分を有効にする前に、タグキーの大文字小文字、命名パターン、許容値を組織全体で統一してください。一貫性のない命名 (例: Department、department、dept の混在) をすると、コストの集計・分析が困難になります。 未使用のタグを定期的に確認・無効化する 。古いタグや未使用のタグはコストレポートのノイズになります。有効なコスト配分タグを定期的に監査してください。 チーム間のタグ使用状況を監視する 。Bedrock モデルを利用する新しい IAM プリンシパルに一貫してタグが付与されているか確認してください。 まとめ IAM プリンシパルベースのコスト配分により、Amazon Bedrock の支出を押し上げている ID を正確に把握できます。IAM プリンシパルへのタグ付与、コスト配分タグの有効化、CUR 2.0 での IAM プリンシパルデータの有効化を行うことで、組織全体で Bedrock コストの追跡、配分、管理が可能になります。今すぐこの機能を有効にして、24 時間以内にチーム、部門、プロジェクトごとの Bedrock 支出の分析を始めましょう。 詳細は IAM プリンシパルベースのコスト配分のドキュメント を参照してください。この機能に関する質問やフィードバックは、 AWS re:Post または AWS Support までお寄せください。 著者について Koushik Das AWS のシニアテクニカルアカウントマネージャー。お客様の戦略的イニシアチブの推進と生成 AI 導入を支援しています。クラウド財務管理 (CFM) とヘルスケア・ライフサイエンス分野の AI イノベーションを専門としています。 Anand Gaurav AWS の Billing and Cost Management チームのプリンシパルテクニカルプロダクトマネージャー。FinOps と生成 AI の交差領域におけるコスト管理のプロダクト戦略を担当しています。 翻訳はソリューションアーキテクト 大磯が担当しました。原文は こちら です。

本記事は 2026 年 4 月 20 日 に AWS Migration & Modernization Blog で公開された「 Amazon EVS now offers Windows Server Licensing: A step-by-step guide 」を翻訳したものです。 柔軟性、制御性、そして選択肢の豊富さは、 Amazon Elastic VMware Service (Amazon EVS) の根幹をなす重要な柱です。Amazon EVS では、VMware テクノロジーへの既存の投資を維持しながら、クラウドのメリットを活用できます。Amazon EVS なら、Amazon VPC 内の EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を直接実行でき、既存のツールや運用プロセスを維持したまま、ワークロードを迅速に移行し、老朽化したインフラストラクチャを廃止できます。 Amazon EVS で Microsoft Windows Server ライセンス の提供を開始したことをお知らせいたします。EVS 環境内で Microsoft Windows Server オペレーティングシステムを実行する仮想マシン (VM) を移行または作成できます。本記事では、移行における意味、仕組み、開始方法を説明します。 より柔軟な対応: Amazon EVS での Windows Server ライセンスオプション Amazon EVS で Windows ベースの VM を実行するには、状況に応じて 2 つのオプションがあります。 Bring Your Own License (BYOL):  ポータビリティ権を持つ対象の Windows Server ライセンス (例: 2019 年 10 月 1 日より前に購入した Windows Server 2016 または 2019 ライセンス) をお持ちの場合、EVS 環境にそのライセンスを持ち込めます。既に投資済みのライセンスを引き続き使用できます。 Amazon EVS の Microsoft Windows ライセンスエンタイトルメント: ポータビリティ権のない VM (Windows Server 2022 や 2025 を実行する VM など) については、Amazon EVS を通じて直接エンタイトルメント（使用権）を付与できるようになりました。vCPU 時間単位の課金で、エンタイトルメントはいつでも追加・削除でき、ニーズの変化に応じてコストを柔軟に管理できます。 開始前に知っておくべきコンセプト ライセンスを設定する前に、EVS コネクタと Windows Server ライセンスエンタイトルメントの 2 つのコンセプトを理解しておく必要があります。 EVS コネクタ: 今回のリリースで EVS コネクタが導入されました。コネクタにより、Amazon EVS サービスが EVS 環境内の VCF 管理アプライアンス (vCenter Server など) と通信できるようになります。各コネクタは 1 つの管理アプライアンスにマッピングされ、完全修飾ドメイン名 (FQDN) と AWS Secrets Manager に保存された認証情報で認証します。Windows Server ライセンスには、Amazon EVS 環境に vCenter コネクタが必要です。コネクタにより、Amazon EVS が Windows Server ライセンスの使用状況を追跡し、VM のライフサイクルイベントを監視できます。 Windows Server ライセンスエンタイトルメント: AWS 提供のライセンスを使用する Windows Server VM ごとにエンタイトルメントを作成する必要があります。作成後、Amazon EVS が VM の電源状態と vCPU 構成を監視するため、課金は実際の使用量に連動し、ワークロードの需要に応じて消費をスケールできます。 課金の仕組み: 監視はエンタイトルメント作成時に開始されますが、課金は VM の実行中の実際のリソース使用量に基づきます。Amazon EVS の Windows ライセンスは、エンタイトルメントを付与した VM の vCPU 時間単位で課金されます。AWS を通じてライセンスを取得した VM のみが課金対象です。Windows Server ライセンスのポータビリティ権の対象となる VM には、AWS からの追加ライセンスコストは発生しません。料金の例については、 Amazon EVS の料金ページ をご覧ください。 ステップバイステップガイド 以下の手順で、EVS 環境内のライセンスを設定します。 手順: VMware vCenter Server 内に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する。 EVS 内に vCenter コネクタを作成する。 VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する。 Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する。 ステップ 1: EVS 環境内の VMware vCenter Server に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する EVS コネクタは、EVS 環境内の vCenter Server アプライアンスとの認証に認証情報が必要です。コネクタを作成する前に、コネクタが使用する ReadOnly ロールを持つ専用ユーザーアカウントを作成します。 新しいユーザーの作成とロールの割り当てに必要な管理者権限を持つアカウントで、Amazon EVS 環境の vCenter Server にログインします。 ローカルの Single-Sign On ユーザー を作成し、 ReadOnly グループに割り当て ます。 図 1: 新しいユーザーのユーザー名、パスワード、説明 (推奨) を設定 図 2: 作成したユーザーを ReadOnlyUsers グループに追加 次に、EVS コネクタが vCenter アプライアンスと連携するために、作成した認証情報が必要です。認証情報を安全に保存し Amazon EVS と共有するには、特定のタグを付けて AWS Secrets Manager に保存します。 AWS マネジメントコンソール から AWS Secrets Manager にアクセスします。 「新しいシークレットを保存する」 を選択します。 「その他のシークレットのタイプ」 を選択します。 「キー/値のペア」 セクションで、完全なユーザー名を 「 キー」 に、パスワードを 「 値」 に入力します。入力後、「 次」  を選択します。 ユーザー名は username@vsphere.local の形式にします この例では、ユーザー名は evs-connector@vsphere.local です 「シークレットの名前と説明」 セクションで、シークレットの名前を入力します。説明はオプションで追加できます。 「タグ – オプション」 セクションで 「 追加する」  を選択します。 キー に EvsAccess 、値 に true を入力してタグを追加します。 注意: キー と 値 は大文字と小文字が区別されます。 図 3: シークレットに EvsAccess=true タグを付与 「ローテーションを設定する」 セクションはデフォルトのままにします。「 次 」 を選択します。 内容を確認し、「 保存」  を選択します。 ステップ 2: EVS 内に vCenter コネクタを作成する 次に、vCenter Server との通信を可能にする Amazon EVS コネクタを作成します。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「コネクタ」 タブを選択し、 「コネクタを作成」 を選択します。 図 4: 新しいコネクタを作成 Amazon EVS vCenter アプライアンス の FQDN を入力します。 先ほど作成した AWS Secrets Manager のシークレットをリストから選択します。 vCenter ユーザーのアクセスと権限を設定済みであることを確認するチェックボックスを選択し、「 コネクタを作成 」 を選択します。 図 5: EVS vCenter へのアクセス権を持つ新しいコネクタの作成フォームを送信 接続の検証には最大 10 分かかる場合があります。Amazon EVS 環境のコネクタタブでコネクタの状態を確認できます。 次のステップに進む前に、 「状態」  が Active 、 「ステータス」 が Passed になるまで待つ必要があります。 ステップ 3: VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する ユーザーアカウントとコネクタの設定が完了したら、VM に Windows Server ライセンスのエンタイトルメントを付与できます。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「使用権限」 タブを選択し、 Add entitlements を選択します。 図 6: エンタイトルメントを追加 .csv ファイルをアップロードするか、VM ID を手動で追加できます。このウォークスルーでは、手動で ID を追加します。 Note: vCenter では PowerCLI やその他のツールで VM Managed Object ID を取得できます。 Note: 各エンタイトルメントに含められる VM は最大 100 台です。100 台ずつバッチでエンタイトルメントをリクエストできます。 テキストボックスに VM ID をカンマ区切りで入力します。 Add entitlements を選択します。 図 7: 新しいエンタイトルメントに VM ID を送信 エンタイトルメントの 「ステータス」 が Active に変わったことを確認します。 ステップ 4: Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する Amazon EVS は、エンタイトルメントを付与した VM のアクティベーションに使用する Key Management Services (KMS) サーバーエンドポイントを提供します。エンタイトルメントの作成後、VPC エンドポイントを作成して Amazon EVS 提供の KMS サーバーへの接続を有効にできます。 このエンドポイントは、AWS 提供の Windows Server ライセンスを使用している Amazon EVS 環境が稼働中の場合にのみ作成できます。 AWS マネジメントコンソール から Amazon VPC にアクセスします。 左側のナビゲーションペインで、「 PrivateLink と Lattice」 セクションから 「 エンドポイント」 を選択します。 「エンドポイントを作成」 を選択します。 エンドポイントの名前を入力します。 「タイプ」 で 「 AWS のサービス」 を選択します。 図 8: Activation VPC エンドポイントを作成 サービス名が「 com.amazonaws.<region>.evs-windows-server-activation 」のサービスを選択します。 ネットワーク設定で、ドロップダウンメニューから Amazon EVS の VPC を選択します。 図 9: 新しいエンドポイントのアクティベーションサービスを設定 次に、 「サブネット」 セクションから サービスアクセスサブネット を選択します。 図 10: 新しいエンドポイントにサービスアクセスサブネットを関連付け エンドポイントにアタッチする セキュリティグループ を選択します。セキュリティグループは、AWS KMS サーバーに接続する Windows Server VM からの インバウンド TCP 1688 を 許可する必要があります 。 エンドポイントのステータスが 「 使用可能」 になったら、エンドポイント名を選択してスクロールダウンし、「 プライベート DNS 名」 を確認します。次のタスクで必要になります。 図 11: エンドポイントのプライベート DNS 名を取得 次に、エンタイトルメントを付与した VM が Amazon EVS 提供の KMS サーバーエンドポイントを Windows アクティベーションに使用するよう設定します。各 VM で手動で設定するか、PowerShell やグループポリシーでプロセスを自動化できます。本記事では、PowerShell による手動オプションを紹介します。 Windows Server VM にログインし、 PowerShell ウィンドウを開きます。 コピーした Private DNS name で、以下のコマンドにより VM が AWS KMS サーバーを使うよう設定します。 slmgr /skms <VPC Endpoint Private DNS Name>:1688 この例では、コマンドは以下のようになります。 slmgr /skms evs-windows-server-activation.us-east-2.amazonaws.com:1688 Key Management Service machine が AWS KMS サーバーに設定されたことを通知するダイアログウィンドウが表示されます。 図 12: Windows Server VM の AWS KMS サーバー設定が完了 次に、以下のコマンドを実行して Windows Server VM をアクティベートします。 slmgr /ato 成功すると、製品が正常にアクティベートされたことを通知するダイアログウィンドウが表示されます。 図 13: Windows Server VM のアクティベーション成功 Windows Server VM が正しく設定されたことを確認するには、以下のコマンドを実行します。 slmgr /dli 成功すると、以下のメッセージが表示されます。 図 14: ライセンスアクティベーションの確認 コマンドラインインターフェイス (CLI) を使う場合は、 ユーザーガイド を参照してください。 開始方法 今すぐ AWS への移行を始めましょう。戦略的なデータセンター撤退の計画、運用コストの削減、クラウドイノベーションの活用のいずれであっても、Amazon EVS で VCF ベースのワークロードをシンプルに移行できます。 さあ始めましょう: 今すぐ Amazon EVS コンソール にアクセス 詳細を確認: 技術ドキュメント で Amazon EVS とライセンスについて学ぶ 移行とモダナイゼーションのオプションを検討する: AWS for VMware ページ ですべての VMware ワークロードの AWS への移行・モダナイゼーションオプションを確認 計画を開始する: まずは お問い合わせ いただき、 無料のアセスメント から始めましょう。 著者について James Selwood AWS の Infrastructure Migration and Modernization チームのシニアスペシャリストソリューションアーキテクトです。19 年の業界経験を持ち、2019 年に AWS に入社。VMware、ネットワーク、コンピューティングインフラストラクチャのバックグラウンドを活かし、お客様のクラウド移行を支援しています。 Allan Scott AWS のシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、Infrastructure Migration and Modernization チームで 22 年の業界経験を活かして複雑な技術課題に取り組んでいます。VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。 Alex Pylnev AWS の Infrastructure Migration and Modernization チームのスペシャリストソリューションアーキテクトです。クラウド移行の計画・実行からレガシーインフラストラクチャのモダナイゼーションまで、お客様の技術課題を支援しています。VMware 環境での豊富な経験を持ちます。 Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とモダナイゼーションを担当しています。マーケティングとテクノロジー分野で 7 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの伊藤です。2026 年 3 月 17 日に、大阪オフィスにて「AWS Business Innovation Series – West Japan」の第 1 回を開催いたしました。本シリーズは、西日本のお客様のデジタル変革を加速することを目的に、生成 AI を活用した実践的なプログラムを約 3 ヶ月に 1 回のペースでお届けしていくものです。ご参加いただいた皆様に、改めて御礼申し上げます。 本ブログでは、イベントの背景や当日の様子、参加者の皆様からいただいた声をお届けいたします。 はじめに 2025 年は、関西を中心に流通・小売業界のお客様向けワークショップを 4 回開催し、生成 AI を活用したビジネス変革の実践機会を提供してまいりました。ありがたいことに非常に高い満足度をいただけたことから、2026 年も「AWS Business Innovation Series – West Japan」として継続開催しています。 継続にあたって大事にしたのは、参加者の皆様からいただいた声です。中でも「普段、他社の方と話せる機会が少ないので、こうした場はとても嬉しい」という声が想定以上に多くありました。技術を学ぶだけでなく、異なる企業の方々と課題や知見を共有できる場そのものに価値を感じていただいていました。 この声を受けて、2026 年は業界を特に問わず、幅広い企業の皆様にご参加いただける形に拡大しました。約 3 ヶ月に 1 回のペースで年 4 回の開催を予定しており、今回がその第 1 回です。 第 1 回のテーマには Kiro を選びました。Kiro は AWS が提供する IDE で、「仕様駆動開発（Spec-driven Development）」という独自のアプローチを備えています。詳しくは後述しますが、「AI コーディングツールは気になるけれど、何から始めればいいかわからない」「試してみたけれど、実務にどう活かせるかイメージが湧かない」――そんな方々に、半日で動くプロトタイプを作り上げる体験を通じて、最初の一歩を踏み出していただくことが今回のイベントの狙いでした。 イベント概要 項目 内容 テーマ お試しから卒業！Kiro の仕様駆動開発を本格活用 日時 2026 年 3 月 17 日（火）13:00〜18:00（懇親会 18:00〜） 場所 アマゾン ウェブ サービス ジャパン 大阪オフィス（中之島三井ビルディング 26F） 参加者 18 社 37 名 満足度 4.66 / 5 参加者の内訳は IT 部門の方が約 85%、事業部門の方が約 15% でした。開発者の方は全体の約 10% と少数で、多くの方が普段はコードを書かない立場からのご参加でした。 タイムテーブル 時間 内容 13:00 – 13:10 オープニング 13:10 – 13:30 座学：Kiro — 信頼できる AI 開発パートナー 13:30 – 15:00 Kiro IDE ハンズオン（休憩込み） 15:00 – 17:00 Kiro ワークショップ / ハッカソン（休憩込み） 17:00 – 17:40 全体発表・投票・表彰 17:40 – 17:50 LT「Kiro ともっと仲良くなろう」 17:50 – 18:00 クロージング 18:05 – 19:30 懇親会 当日の様子 Kiro — AI と共に考え、共に作る。信頼できる開発パートナー 発表資料： Kiro — AI と共に考え、共に作る。信頼できる開発パートナー 最初のセッションは、ソリューションアーキテクトの濱上より「Kiro — AI と共に考え、共に作る。信頼できる開発パートナー」と題して、Kiro の仕様駆動開発について座学形式でご紹介しました。 セッションの中で特に反響が大きかったのは、Kiro が生まれた背景の話です。AI コーディングツールに「ログイン画面を作って」と指示すればコードは出てくる。しかし、既存環境との統合やセキュリティ要件を満たすコードにはならない。いわゆる Vibe Coding の限界です。AWS のエンジニアたちも同じ壁にぶつかり、プロンプトを何度も書き直すうちに「これは仕様書だ」と気づいたことが、仕様駆動開発の出発点でした。 仕様駆動開発では、まず自然言語でやりたいことを伝えると、Kiro が要件を Spec（Requirement）として構造化します。次に、その Spec に基づいて設計ドキュメント（Design）を生成し、実装すべきタスク（Task）に分解します。開発者は各ステップでレビューと修正を行いながら進めるため、「AI が何をしているかわからない」という不安なく開発を進められます。 このセッションは当日のアンケートで最も高い満足度を記録しました。参加者の方からは「Kiro を使うと、要件から設計に落とし込むフローが可視化されるので、AI コーディングに慣れていない人にも理解しやすい」という声をいただいています。 ハンズオン — Vibe Coding から仕様駆動開発へ 座学の後は、実際に Kiro を使ったハンズオンです。参加者の皆様には事前に Kiro のサブスクリプションをご準備いただき、約 90 分かけて段階的に Kiro の機能を体験していただきました。 まず最初に体験したのは Vibe Coding です。Kiro の Vibe モードで「ゲーム作って」と一言入力するだけで、スネークゲームが動き始めます。会場からは「えっ、これだけで？」という驚きの声が上がりました。 しかし、ここで終わりではありません。座学で学んだ通り、Vibe Coding だけでは実務で使えるソフトウェアにはなりません。そこでハンズオンでは、Kiro をより実践的に活用するためのカスタマイズ要素も体験していきます。 Steering（ステアリング） ― 開発ルールや命名規則を Kiro に覚えさせる カスタムエージェント ― 「AWS SA の分身」を作り、特定の役割を持たせる こうした機能に触れながら、最後に到達するのが Spec モード です。同じスネークゲームを、今度は要件定義（Requirement）→ 設計（Design）→ タスク分解（Task）→ 実装という仕様駆動開発の流れで作り直します。 「一言で作る Vibe Coding」と「仕様を積み上げて作る Spec モード」の両方を体験することで、その違いと仕様駆動開発の価値を実感していただく構成です。参加者の方からは「Steering について学べてよかった」「ユースケースの手順を Kiro は迷わずに進めてくれるので良かった」といった声をいただきました。 ハッカソン — チームで作る、発表する 後半のメインイベントはハッカソンです。異なる企業の参加者同士でチームを組み、アプリケーション開発に挑戦していただきました。 テーマは AWS 側で 3 つの候補を用意しました。 クレーム / レビュー / VoC 分析 施設・設備の予約（社外向け来店予約など） 顧客向け説明資料の作成支援（営業提案資料など） この中から 1 つを選んでいただく形ですが、「自分の業務課題で試したい」という方は持ち込みテーマでの参加も OK としました。実際、独自テーマに果敢に挑戦するチャレンジャーも何組かいらっしゃいました。 ハッカソンでも仕様駆動開発の流れに沿って進めます。まず、今回ハッカソン用に壁打ち支援アシスタント（サブエージェント）をKiroに組み込み対話しながら、選んだテーマの 5W1H を整理し、要件を具体化していきます。「自社の XX さんが使うなら、こういう機能は必須だな」と、実際のユーザーを思い浮かべながら要件を詰めていく過程は、ハンズオンの決められたユースケースとは異なる難しさと面白さがあります。要件が固まったら Spec モードで Requirement → Design → Task → 実装と進め、最後にグループ内で発表し、代表者を選出して全体発表に臨みます。 限られた時間の中で、業務課題を解決するツールから遊び心のあるアプリまで、バラエティに富んだ作品が生まれました。特に印象的だったのは、普段コードを書かない事業部門の方が Kiro を使ってアプリケーションを作り上げ、グループの代表として全体発表に選ばれたことです。「やりたいことを書いていったら、本当に動くものができた！」という言葉が、Kiro の仕様駆動開発の可能性を端的に表していると感じました。 各チームの発表後には投票を行い、会場全体で盛り上がりました。最も多くの票を集めた方には「ベスト Kiro アイデア賞」として粗品を進呈し、拍手喝采で称えました。 LT「Kiro ともっと仲良くなろう」 発表資料： Kiro ともっと仲良くなろう ― Kiro カスタマイズのすすめ クロージング前の LT セッションでは、Kiro をもっと自分好みにカスタマイズする方法をご紹介しました。 Kiro には Steering、Skills、Powers、Agent など様々なカスタマイズ要素がありますが、正直なところ一度に説明されると「多すぎてわからない…」となりがちです。そこで本 LT では、これらを RPG の冒険者 に例えて整理しました。 Steering = 冒険者の人となり（性格・こだわり・ギルドのルール） Skills = 依頼の手順書（特定の任務のときだけ開く） MCP = 常備装備（常に身につけている武器・道具） Powers = 召喚獣（呼べば装備・知識・仕掛けを丸ごと持って現れる） Agent = ジョブ / クラス（装備・手順書をまとめた役割定義） 「Kiro は “あらゆる訓練を受けた冒険者”。能力はあるけれど、あなたのギルドのやり方はまだ知らない」――だからこそ、まずは Steering で “人となり” を教えてあげるところから始めましょう、というメッセージです。 ハンズオンとハッカソンで仕様駆動開発を体験した直後だったこともあり、「触ってないけど、なんとなくわかった！触ってみたい！」という反応をいただきました。 参加者の声 イベント後のアンケートでは、多くの方から前向きなフィードバックをいただきました。一部をご紹介します。 「IT 部門ではない人間でもとてもわかりやすかったです」 「普段ベンダーに委託している業務の裏側の一部を見ることができ、今後進める際に構造を理解する手助けになりました」 「Kiro を使うともっともっと色々な物を考えて作成できるなと。色々試したくなりました」 「こういうイベントをもっと若手に参加させたい。みんな興味あるだろうし、飲み込みも早いから」 IT 部門の方だけでなく、事業部門の方からも「わかりやすかった」「自分でも作れた」という声をいただけたことは、このイベントが目指していた「最初の一歩」を実現できた証だと感じています。 まとめ 今回のイベントでは、Kiro の仕様駆動開発を座学・ハンズオン・ハッカソンの 3 ステップで体験していただきました。「AI コーディングツールは気になるけれど、何から始めればいいかわからない」という方々が、わずか半日で動くプロトタイプを作り上げ、「すぐに社内で試してみたい」と感じていただけたことを大変嬉しく思います。 「AWS Business Innovation Series – West Japan」は、2026 年も継続開催いたします。第 2 回以降も、生成 AI を活用した実践的なテーマをご用意してお届けする予定です。 各回でテーマが異なりますので、リピーターの方にも新しい学びがあります。 ご興味のある方は、担当のアカウントチームまでお気軽にお問い合わせください。皆様のご参加をお待ちしております。 本ブログは、ソリューションアーキテクトの伊藤 一成が執筆いたしました。

AWS DevOps Agent は、24時間365日稼働する運用チームメンバーです。インシデントの解決・予防、アプリケーションの信頼性やパフォーマンスの最適化、オンデマンドの SRE タスクなどを、AWS・マルチクラウド・オンプレミスを問わず担います。既存のオブザーバビリティツールと連携してテレメトリ・コード・デプロイデータを横断的に分析し、平均修復時間（MTTR）の短縮とオペレーショナルエクセレンスの実現を支援します。 多くの組織では、カスタムの Model Context Protocol（MCP） ツールや各種インテグレーションで AWS DevOps Agent を拡張し、プライベートパッケージレジストリ、セルフホスト型オブザーバビリティ基盤、社内ドキュメント API、GitHub Enterprise や GitLab といったソース管理システムなど、内部リソースへのアクセスを実現しています。しかし、こうしたサービスの多くはパブリックインターネットに接続していない Amazon Virtual Private Cloud（Amazon VPC） 内で稼働しており、そのままでは AWS DevOps Agent からアクセスできません。 AWS DevOps Agent のプライベート接続 を使えば、Agent Space と VPC 内（または社内ネットワーク内）のサービスを、パブリックインターネットに公開せずセキュアにつなげられます。MCP サーバー、セルフホスト型の Grafana や Splunk、ソース管理システムなど、プライベートエンドポイントへのアクセスが必要なあらゆるインテグレーションに対応しています。 本記事では、プライベート接続の仕組みとセキュリティ上の特徴を解説したうえで、 AWS マネジメントコンソール と AWS CLI を使ったセットアップ手順を紹介します。 プライベート接続の仕組み プライベート接続は、AWS DevOps Agent と VPC 内の対象リソースの間にセキュアなネットワーク経路を確立する機能です。内部では Amazon VPC Lattice を利用しています。VPC Lattice は、VPC・アカウント・コンピュートタイプをまたいだアプリケーション間通信を、ネットワークインフラの管理なしに接続・保護・監視できるサービスです。 プライベート接続を作成すると、次の処理が行われます。 対象サービスと通信できる VPC、サブネット、および必要に応じてセキュリティグループを指定する。 AWS DevOps Agent がサービスマネージドの リソースゲートウェイ を作成し、指定サブネットに Elastic Network Interface（ENI）を配置する。 リソースゲートウェイ経由で、対象サービスの IP アドレスまたは DNS 名へプライベートにトラフィックを転送する。 リソースゲートウェイは AWS DevOps Agent が完全に管理しており、アカウント上では読み取り専用リソースとして表示されます。利用者側での設定やメンテナンスは不要です。VPC 内に作成されるのは、指定サブネット内の ENI だけです。ENI はプライベートトラフィックの入口として機能し、インターネットからのインバウンド接続は受け付けません。トラフィック制御は、利用者自身のセキュリティグループで行えます。 セキュリティ プライベート接続には、複数のセキュリティレイヤーが組み込まれています。 パブリックインターネットへの公開なし — AWS DevOps Agent と対象サービス間の通信はすべて AWS ネットワーク内で完結します。パブリック IP やインターネットゲートウェイは不要です。 サービス制御のリソースゲートウェイ — リソースゲートウェイはアカウント内で読み取り専用であり、AWS DevOps Agent だけが利用できます。他のサービスやプリンシパルがトラフィックを送信することはできません。 AWS CloudTrail ログにすべての VPC Lattice API 呼び出しが記録されるため、監査も容易です。 セキュリティグループによる制御 — ENI のアウトバウンドトラフィックは、利用者が所有・管理するセキュリティグループで制御します。DevOps Agent からの通信は、リソースゲートウェイ ENI に関連付けたセキュリティグループのアウトバウンドルールと、対象サービス側のインバウンドルールの両方に従います。 最小権限のサービスにリンクされたロール — AWS DevOps Agent は サービスにリンクされたロール でリソースゲートウェイを管理します。このロールの操作対象は AWSAIDevOpsManaged タグが付いたリソースに限定されており、アカウント内の他のリソースには影響しません。 DNS サポート — サービスを DNS 名で参照できます。なお、DNS 名はパブリックに名前解決できる必要があります。 リソース設定を独自に管理する場合は、 サービスコントロールポリシー（SCP） で VPC Lattice のアクションが許可されていることを確認してください。 アーキテクチャ 次の図は、プライベート接続のネットワーク経路を示しています。 Figure 1: AWS DevOps Agent プライベート接続 AWS DevOps Agent が対象サービスへリクエストを送信する。 リクエストはサービスマネージドのリソースゲートウェイを経由する。 VPC 内の ENI がトラフィックを受け取り、対象サービスの IP アドレスまたは DNS 名へ転送する。 セキュリティグループが ENI を通過するトラフィックを制御する。 対象サービスから見ると、リクエストの送信元は VPC 内の ENI のプライベート IP アドレスになる。 前提条件 プライベート接続を作成する前に、以下の準備が整っていることを確認してください。 アクティブな Agent Space — アカウントに Agent Space が必要です。まだ作成していない場合は、 AWS DevOps Agent の開始方法 を参照してください。 プライベートに到達可能な対象サービス — MCP サーバーやオブザーバビリティ基盤などの対象サービスに、リソースゲートウェイをデプロイする VPC からプライベート IP アドレスまたは DNS 名で接続できる必要があります。同一 VPC、ピアリング先の VPC、オンプレミスのいずれでも構いませんが、リソースゲートウェイのサブネットからルーティングできることが条件です。対象サービスは、接続作成時に指定する TCP ポートでリッスンしている必要があります。 VPC 内のサブネット — リソースゲートウェイ ENI を配置するアベイラビリティーゾーンごとに 1 つのサブネットを選びます。高可用性を確保するため、複数のアベイラビリティーゾーンにまたがるサブネットの選択を推奨します。各サブネットから対象サービスへ通信できることが前提です。 （オプション）セキュリティグループ — 特定のルールでトラフィックを制御したい場合は、ENI にアタッチするセキュリティグループ ID を最大 5 つ用意します。省略した場合は、VPC のデフォルトセキュリティグループが適用されます。 プライベート接続はアカウントレベルのリソースです。一度作成すれば、同じホストにアクセスする複数のインテグレーションや Agent Space で使い回せます。 プライベート接続の作成 AWS マネジメントコンソールまたは AWS CLI で作成できます。 AWS コンソールの場合 ステップ 1 : AWS DevOps Agent コンソール を開き、ナビゲーションペインで Capability providers を選択します。 Figure 2: DevOps Agent Capability Providers ステップ 2 : Private connections を選択します。 Figure 3: DevOps Agent プライベート接続 ステップ 3 : Create a new connection を選択します。 Figure 4: DevOps Agent – 新しい接続の作成 ステップ 4 : プライベート接続の各項目を設定します。 接続の詳細： Name — わかりやすい接続名を入力 リソースの場所： VPC where your resource is located — 対象リソースが配置されている VPC、またはアクセス可能な VPC を選択 Subnets — マネージドリソースゲートウェイ ENI を配置するサブネット（アベイラビリティーゾーンごとに 1 つ） IP address type — IPv4、IPv6、またはデュアルスタック Figure 5: DevOps Agent – プライベート接続の設定 アクセス制御： Security groups — DevOps Agent がプライベートリソースへアクセスする際に使うセキュリティグループを選択 （オプション）TCP port ranges — 接続に使用するポート範囲を制限（未指定の場合は全ポート許可） サービスターゲットの詳細： Host address — 対象リソースの DNS 名または IP アドレス。選択した VPC から到達できる必要があります。DNS 名の場合はパブリックに名前解決できることが条件です。 （オプション）Certificate public key — 対象サービスへのセキュア接続に使う証明書の公開鍵 Figure 6: DevOps Agent – プライベート接続の設定（続き） Create Connection を選択します。 ステータスが Create in progress に変わり、最大 10 分ほどで完了します。 Completed になればネットワーク経路の準備は完了です。 Figure 7: プライベート接続の作成成功 Create failed になった場合は、以下を確認してください。 指定サブネットに空き IP アドレスがあるか VPC Lattice のサービスクォータに達していないか サービスにリンクされたロールのリソース作成を妨げる IAM ポリシーがないか AWS CLI の場合 以下のコマンドでプライベート接続を作成します。各値は環境に合わせて置き換えてください。 aws devops-agent create-private-connection \ --name my-test-private-connection \ --mode '{ "serviceManaged": { "hostAddress": "mymcpserver.test.skipv5.net", "resourceGatewayConfig": { "create": { "vpcId": "vpc-00ef99bef2632b9ac", "subnetIds": [ "subnet-034f636837473de13", "subnet-00bdfb9edf7cc1ca7" ], "securityGroupIds": [ "sg-082788aaec0517905" ] } } } }' レスポンス例： { "name": "my-test-private-connection", "status": "CREATE_IN_PROGRESS", "resourceGatewayId": "rgw-0f7415325b107a945", "hostAddress": "mymcpserver.test.skipv5.net", "vpcId": "vpc-00ef99bef2632b9ac" } ステータスを確認するには describe-private-connection を使います。 aws devops-agent describe-private-connection \ --name my-test-private-connection Completed になれば利用可能です。 接続の確認 プライベート接続が Completed になったら、実際に対象サービスへ到達できるか確認しましょう。 AWS DevOps Agent コンソール で Agent Space を開く。 新しいチャットセッションを開始する。 プライベート接続を利用するインテグレーション経由でコマンドを実行する。たとえば、MCP ツールが社内ナレッジベースに接続している場合、そのナレッジベースの情報が必要な質問をエージェントにしてみる。 エージェントがプライベートサービスの情報を返すことを確認する。 うまくいかない場合は、以下を点検してください。 セキュリティグループルール — ENI にアタッチしたセキュリティグループが、対象サービスのリッスンポートへのアウトバウンドを許可しているか。また、対象サービス側のセキュリティグループが ENI からのインバウンドを許可しているか。 サブネットの疎通性 — 選択したサブネットから対象サービスへルーティングできるか。別サブネットで稼働している場合は、ルートテーブルの設定も確認する。 サービスの稼働状況 — 対象サービスが起動しており、想定ポートで接続を受け付けているか。 例: セルフホスト型 Grafana インスタンスへの接続 プライベート接続のよくあるユースケースが、セルフホスト型 Grafana への接続です。メトリクス・ログ・トレースの可視化のために、パブリックエンドポイントを持たない VPC 内で Grafana を運用しているチームも多いでしょう。組み込みの Grafana インテグレーションとプライベート接続を組み合わせれば、ダッシュボードやアラート、データソースへの読み取り専用アクセスをエージェントに付与できます。オンコールエンジニアがインシデント対応で頼りにしているのと同じオブザーバビリティデータを、エージェントも活用できるようになります。 AWS DevOps Agent には、公式オープンソースの Grafana MCP サーバー をホストする専用 Grafana インテグレーションが用意されています。MCP サーバーのインフラを自前で構築・運用する必要はありません。Grafana Cloud、Grafana Enterprise、セルフホスト型 Grafana OSS（v9.1 以降）に対応しています。 パブリックにアクセスできないセルフホスト型インスタンスの場合は、Grafana インテグレーションにプライベート接続を組み合わせることで、プライベートネットワーク経由のアクセスが可能になります。 ステップ 1: Grafana サービスアカウントを作成する Grafana インスタンスで Viewer ロールの サービスアカウント を作成します。これにより、ダッシュボード・アラートルール・データソースへの読み取り専用アクセスが付与されます。アクセストークンを生成し、次のステップ用に控えておいてください。 ステップ 2: Grafana インスタンスへのプライベート接続を作成する Grafana インスタンスはプライベートサブネットで稼働しているため、まずプライベート接続を作成します。 AWS コンソールの場合： 本記事の「プライベート接続の作成」セクションの手順に沿い、Grafana インスタンスのアドレスをホストアドレスに指定します。 AWS CLI の場合： aws devops-agent create-private-connection \ --name grafana-connection \ --mode '{ "serviceManaged": { "hostAddress": "grafana.internal.example.com", "resourceGatewayConfig": { "create": { "vpcId": "vpc-0123456789abcdef0", "subnetIds": [ "subnet-0123456789abcdef0", "subnet-0123456789abcdef1" ], "portRanges": ["443"] } } } }' ステータスが Completed になってから次へ進みます。 ステップ 3: Agent Space に Grafana インテグレーションを追加する Grafana サービスを登録し、Agent Space に関連付けます。 AWS コンソールの場合： AWS DevOps Agent コンソール で Agent Space を開く。 Integrations セクションの Add integration を選択する。 Grafana タイルを選択する。 Grafana インスタンスの URL（例: https://grafana.internal.example.com ）を入力する。 ステップ 1 で生成したアクセストークンを貼り付ける。 Save を選択する。 AWS CLI の場合： まず、Grafana サービスを登録します。 aws devops-agent register-service \ --service mcpservergrafana \ --private-connection-name grafana-connection \ --service-details '{ "mcpservergrafana": { "name": "grafana", "endpoint": "https://grafana.internal.example.com", "authorizationConfig": { "bearerToken": { "tokenName": "grafana-sa-token", "tokenValue": "<SERVICE_ACCOUNT_TOKEN>" } } } }' \ --region us-east-1 返却された serviceId を控え、Agent Space に関連付けます。 aws devops-agent associate-service \ --agent-space-id <AGENT_SPACE_ID> \ --service-id <SERVICE_ID> \ --configuration '{ "mcpservergrafana": { "endpoint": "https://grafana.internal.example.com" } }' \ --region us-east-1 レスポンスには、ステップ 4 のアラート通知設定に使える Webhook 情報が含まれます。エージェントは、ステップ 2 で作成したプライベート接続を通じ、ホストアドレスの一致をもとに Grafana インスタンスへトラフィックを転送します。 動作を確認するには、Agent Space のチャットで「最近の Grafana アラートをまとめて」と尋ねてみてください。ダッシュボードのアラートデータが返ってくれば、プライベート接続と Grafana インテグレーションの両方が正しく機能しています。 ステップ 4: Grafana Webhook 通知を有効にする（オプション） Grafana のアラート発火時に AWS DevOps Agent が自動で調査を開始できるようにするには、Grafana インスタンスに Webhook コンタクトポイントを設定します。Webhook の送信先を Agent Space の Webhook URL に指定し、インテグレーション設定の認証シークレットを設定してください。アラートが発火すると Grafana からエージェントに通知が届き、Agent Space 内の他のリソースと合わせて Grafana のデータを使った調査が自動的に始まります。 Grafana インテグレーションの詳細や、 AWS Managed Grafana（AMG） との連携方法については、 AWS DevOps Agent Grafana インテグレーションのドキュメント を参照してください。 DNS 解決とホストルーティングの仕組み プライベート接続の作成時に指定するホストアドレス（例: my-alb.us-east-1.elb.amazonaws.com ）は、VPC Lattice が対象へのトラフィック転送先を決めるために名前解決する DNS 名です。プライベート IP に解決される場合でも、パブリックに名前解決できる必要があります。 一方、サービスインテグレーション登録時に指定するエンドポイント URL（例: https://my-grafana.internal.corp ）は、TLS 接続の Host ヘッダーと SNI（Server Name Indication）に使われるもので、DNS 解決には使われません。 この仕組みにより、同じプライベート接続（たとえば同一の ALB）に対して、異なるエンドポイントホスト名を持つ複数のサービスインテグレーションを関連付けられます。ALB 側ではホストベースのルーティングルールを使い、リクエストを適切なターゲットグループに振り分けることが可能です。 具体的には、ALB の DNS 名をホストアドレスとする単一のプライベート接続を作成し、Grafana 用と MCP サーバー用のインテグレーションをそれぞれ別のエンドポイント URL で登録します。ALB は同じプライベート接続経由で両方のリクエストを受け取り、Host ヘッダーに基づいて正しいバックエンドへ振り分けます。 既存の VPC Lattice リソースを使った高度なセットアップ すでに Amazon VPC Lattice を導入済みで、リソース設定を独自に管理している組織では、セルフマネージドモードでプライベート接続を作成できます。AWS DevOps Agent にリソースゲートウェイを作成させる代わりに、対象サービスを指す既存リソース設定の ARN を指定します。 このアプローチが適しているのは、次のようなケースです。 リソースゲートウェイとリソース設定のライフサイクルを自分で管理したい 複数の AWS アカウントやサービス間でリソース設定を共有したい VPC Lattice のアクセスログで詳細なトラフィック監視を行いたい ハブアンドスポーク型のネットワークアーキテクチャを採用している リソースやサービスへのアクセスにゼロトラストのきめ細かな制御が必要 AWS コンソールでは、 Create a new connection から Use existing resource configuration を選び（下図参照）、ドロップダウンで既存のリソース設定を指定します。 Figure 8: 既存の VPC Lattice リソースを使った高度な設定 AWS CLI の場合： aws devops-agent create-private-connection \ --name my-advanced-connection \ --mode '{ "selfManaged": { "resourceConfigurationId": "rcfg-0123456789abcdef0" } }' VPC Lattice のリソースゲートウェイやリソース設定の詳細は、 Amazon VPC Lattice ユーザーガイド を参照してください。 クリーンアップ 使わなくなったプライベート接続は削除して、不要な課金を防ぎましょう。 AWS コンソールの場合： AWS DevOps Agent コンソール を開く。 ナビゲーションペインで Capability providers → Private connections を選択する。 削除したいプライベート接続を選ぶ。 Delete を選択する。 削除を確定する。 AWS CLI の場合： aws devops-agent delete-private-connection \ --name my-test-private-connection ステータスが DELETE_IN_PROGRESS になり、マネージドリソースゲートウェイと ENI が VPC から削除されます。完了後、該当の接続は一覧に表示されなくなります。 まとめ AWS DevOps Agent のプライベート接続は、Agent Space と VPC 内のサービスをセキュアかつマネージドに接続する仕組みです。Amazon VPC Lattice を活用し、すべての通信をパブリックインターネットから隔離しながら、既存のセキュリティ制御をそのまま維持できます。ネットワークアクセスの制御は、利用者自身のセキュリティグループに委ねられています。 さっそく AWS DevOps Agent コンソール を開いて、最初のプライベート接続を作成してみてください。詳しくは、AWS DevOps Agent ユーザーガイドの プライベート接続 をご覧ください。 著者について Alexandra Huides AWS ネットワーキングサービスプロダクトチームのプリンシパルネットワーキングスペシャリスト SA。スケーラブルでレジリエントな AWS 環境のネットワーク設計を支援。AWS のパブリックスピーカーとして IPv6 導入の推進にも取り組む。趣味はセーリング（特にカタマラン）、旅行、ランニング、読書。 Tipu Qureshi AWS Agentic AI のシニアプリンシパルテクノロジスト。運用の卓越性とインシデント対応自動化が専門。レジリエントで観測性の高いクラウドアプリケーションと自律運用システムの設計を支援。 Jordan Merrick AWS Agentic AI のシニアソフトウェアエンジニア。オブザーバビリティとアイデンティティ領域を担当し、セキュアでスケーラブルなエージェントシステムを構築。 Mohak Kohli Amazon Web Services のソフトウェア開発エンジニア。VPC Lattice と PrivateLink を中心に幅広い領域で開発に従事。 本ブログは 2026 年 4 月 1 日に公開された Securely connect AWS DevOps Agent to private services in your VPCs の日本語訳です。翻訳はソリューションアーキテクトの堀が行いました。

本記事は、2026 年 3 月 30 日に公開された Build high-performance apps with AWS Lambda Managed Instances を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

本記事は、2026 年 1 月 30 日に公開された Serverless ICYMI Q4 2025 を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

2026年4月14日（火）にコンテナサービスの基礎的な内容を扱うウェビナー「これから始める AWS のコンテナサービス活用」を開催しました。本セミナーでは、なぜコンテナが必要なのか、AWS コンテナサービスのラインナップや使い分けといった基礎的な内容から、生成 AI を活用したコンテナ環境の構築・運用や ECS/EKS の新機能のご紹介まで幅広くお届けし、170名の方々にご登録いただき、131名の方々に当日ご参加いただきました。セミナー中には参加者の皆様からさまざまなご質問をいただきました。セッション内容は以下の通りです。 【セッション1】クラウドネイティブな開発 ～ 認知負荷に立ち向かうためのコンテナ活用 【セッション2】ここから始める AWS コンテナサービスの理解 【セッション3】コンテナサービス技術基礎 – 用語と構成理解で全体像を掴む 【セッション4】Amazon ECS / Amazon EKS の最新機能と MCP で広がる活用シーン 以下にそれぞれのセッションの概要と資料ダウンロードのリンクを記載していますので、宜しければご活用ください。 【セッション1】クラウドネイティブな開発 ～ 認知負荷に立ち向かうためのコンテナ活用 ( 資料 ) このセッションでは、アマゾンウェブサービスジャパンのコンテナスペシャリストソリューションアーキテクト 林 政利が、クラウドネイティブな開発におけるコンテナ活用について解説しました。クラウドをサーバーの提供場所としてだけでなく、その機能をネイティブに活用することで認知負荷を削減し、テストの信頼性向上とデプロイの容易化を実現できることが示されました。特に、Testcontainers を用いた本番同等のテスト環境構築や、機能フラグによるデプロイとリリースの分離など、明日から実践できる具体的な手法が紹介され、高パフォーマンス組織への道筋が明確に示された魅力的なセッションとなりました。 【セッション2】ここから始める AWS コンテナサービスの理解 ( 資料 ) このセッションでは、アマゾンウェブサービスジャパンのシニア GTM スペシャリスト 中村 健太郎により、AWS コンテナサービスの基礎から実践までが解説されました。国内企業の4割超がコンテナを利用する中、Amazon ECS、AWS Fargate、Amazon EKS といった主要サービスの特徴や選定基準が紹介され、モバイルアプリケーションや銀行勘定系システムでの具体的なコンテナサービス活用事例を通じて、コンテナ技術がもたらす効率化とスケーラビリティの実現可能性が示されました。 【セッション3】コンテナサービス技術基礎 – 用語と構成理解で全体像を掴む ( 資料 ) このセッションでは、アマゾンウェブサービスジャパンのソリューションアーキテクト 多田 慎也が、Amazon ECS の技術基礎について解説しました。セッションは 3 部構成で、Part1 ではタスク定義・タスク・サービス・クラスターという 4 つの主要構成要素と、EC2・Fargate・ECS Managed Instances という 3 つの起動タイプの違いを説明し、Part2 では IAM ロール、ネットワークモード、ストレージオプション、スケーリング設定、ログとモニタリングなど実運用に必要な各種設定項目を詳しく解説しました。Part3 では実際に VPC 上に ALB と Amazon ECR を組み合わせた Fargate 環境を構築するデモンストレーションを実施し、参加者が ECS の用語と構成を理解して自ら設計を始められるよう、実践的な知識を提供する充実した内容となりました。 【セッション4】Amazon ECS / Amazon EKS の最新機能と MCP で広がる活用シーン ( 資料 ) 本セッションでは、アマゾンウェブサービスジャパンのテクニカルアカウントマネジャー 桐生 宜昭が、Amazon ECS と Amazon EKS の最新機能、そして MCP（Model Context Protocol）サーバーとの連携による新たな活用シーンについて解説しました。ECS Managed Instances では Fargate と EC2 の利点を組み合わせた第3の選択肢が提供され、GPU インスタンスや大容量メモリへの対応、AWS による自動的なインフラ管理と最適化を実現しています。また、ECS Express Mode ではコンテナイメージと IAM ロールのみでベストプラクティスに基づいた本番環境を即座に構築でき、EKS Auto Mode では Kubernetes クラスター全体のインフラ管理が自動化されることで運用負荷を大幅に軽減します。さらに、フルマネージド型の MCP サーバーにより、AI コーディングアシスタントとの連携を通じて開発効率の向上とトラブルシューティングの迅速化が可能となりました。 まとめ 今回のセミナーでは、「なぜコンテナを使うのか」という根本的な問いから、AWS コンテナサービスの全体像と選定基準、実運用に必要な技術基礎、そして ECS/EKS の最新機能や MCP 連携による新たな活用シーンまでを、4 つのセッションを通じて体系的にお届けしました。「コンテナは気になるけれど、何から始めればいいかわからない」という方々に、全体像を掴み、次の一歩を踏み出すきっかけとしていただけたなら大変嬉しく思います。

本記事は 2026/04/15 に公開された “ Accelerating physical AI with AWS and NVIDIA: building production-ready applications with simulation and real-world learning ” を翻訳したものです。 フィジカル AI をデジタルインテリジェンスを超えて定義する フィジカル AI は純粋な計算システムを超えて、物理世界を直接知覚、推論、相互作用する知的エージェントへと進化しています。チャットボットやレコメンデーションエンジンなどのデジタル領域で情報を処理する従来の AI システムとは異なり、フィジカル AI はセンサーとアクチュエータを備えたシステムにインテリジェンスを組み込み、実世界の環境で意味のある、適応的な、自律的な行動を取ることを可能にします。 ロボティクスはフィジカル AI の最も高度な応用例で、機械が複雑な操作、ナビゲーション、組立作業を行います。しかし、フィジカル AI は自律車両が動的な交通状況をナビゲートする、ドローンがインフラ点検を行う、スマート製造資産（パッケージの詰まりを防ぐために速度を自律的に調整するコンベアなど）など、多様な領域に拡がります。各アプリケーションは環境条件を感知し、リアルタイムで物理データを処理する能力を共有します。また、適応的な応答を実行する能力も共通の要件です。 この新興分野は、Morgan Stanley が 2050 年までに $5 兆ドル に達すると予測する市場機会を表しています。この成長は、AI ヒューマノイドのゼロショット製造能力によって推進されています。これらのヒューマノイドは人間のように自律的かつ直感的に働き、世界の労働コストのうち 30-40% を自動化する可能性があります。しかし、これらのヒューマノイドが自己バランスなどの基本的な能力を訓練されたとしても、特定の実世界のアプリケーションにはフィジカル AI のチューニングが必要です。ロボットアームやヒューマノイドを製造業務に導入する組織は、フィジカル AI を使用して実際のビジネス問題を解決するための実用的な方法を必要としています。 開発から導入への課題 DHL Supply Chain の 最近の研究 は、倉庫にロボティクスを統合する際の実装と管理の課題を強調しています。44% の組織がすでにロボティクスを導入していますが、サプライチェーン幹部の 34% のみが、自社の技術導入が適切に機能していると考えています。これは、フィジカル AI モデルの実世界でのデプロイメント、モニタリング、配布、ガバナンスが成功したパフォーマンスとビジネス成果に不可欠であることを強化しています。 Amazon Web Services (AWS) は、Amazon の倉庫やサプライチェーン全体でフィジカル AI を備えたロボティクスを広範に導入することで、これらの分野で実証された能力を示しています。 従来のフィジカル AI 開発には、自律システムの構築に多額の資本投資が必要でした。また、試行錯誤の学習中には安全上の懸念が生じ、反復速度が制限されるという重大な障壁がありました。このプロセスは、物理学と環境ベースのシミュレーションに置き換えることができます。これにより、並列で幅広いシナリオに対してトレーニングを行うことができます。しかし、シミュレーションだけでは、摩擦の変化、材料の変形、センサーノイズ、環境の予測不可能性など、実世界の物理の完全な複雑さを捉えることはできません。 このブログでは、シミュレーションから現実へのギャップを埋める包括的なリファレンスアーキテクチャを提示します。シミュレーションベースのトレーニングの速度と安全性、および実世界の学習の忠実性を組み合わせています。AWS インフラストラクチャと NVIDIA Isaac （オープンなロボティクス開発プラットフォーム）に基づいて構築されたこのアプローチにより、組織はフィジカル AI アプリケーションの開発、デプロイメント、継続的な改善を大規模に促進することができます。 シミュレーションと実世界学習を組み合わせた二段階アプローチ シミュレーションはスケールで迅速かつ安全な実験を可能にします。しかし、実世界のデプロイメントでは、予測不可能な物理条件を処理できるシステムが必要です。NVIDIA Isaac は、組織が物理的に正確な仮想環境でロボットポリシーを訓練およびテストし、エッジデプロイメントの成功に向けて準備することを可能にします。 NVIDIA Isaac は、 NVIDIA Isaac Sim や NVIDIA Isaac Lab などのオープンモデル、ライブラリ、オープンソースフレームワークで構成されています。Isaac Sim は NVIDIA Omniverse ライブラリに基づいて構築されたオープンソースのロボティクスシミュレーションリファレンスフレームワークであり、AI 駆動ロボットのための物理的に正確な、GPU アクセラレーション対応の仮想環境を提供し、設計、テスト、合成トレーニングデータの生成を行います。NVIDIA Isaac Lab は Isaac Sim に基づいて構築されたオープンソースの統合ロボット学習フレームワークであり、強化学習や模倣学習方法を使用して高度なロボットポリシーを訓練します。 Isaac Sim は物理的に正確なシミュレーション環境を提供し、Isaac Lab はその環境を数千の並列トレーニングシナリオにスケールします。これらが一緒になって、実世界のデプロイメントの前に迅速なポリシー開発を可能にします。 シミュレーションベースのトレーニングの力 シミュレーションはフィジカル AI 開発の効率的な出発点を提供します。Isaac Sim を使用することで、チームはロボットシステムと運用環境の デジタルツイン を作成できます。これにより、複数の物理プロトタイプを構築するコストと時間を省き、迅速な実験が可能になります。AWS インフラストラクチャ上で Isaac Sim を実行することで、フィジカル AI 開発者にいくつかの重要な利点がもたらされます： 迅速な反復とコスト効率： エンジニアは高価なハードウェアを危険にさらすことなく、何千ものシナリオを並列でテストできます。複数の物理プロトタイプを構築する代わりに、チームは仮想的に設計の代替案を評価します。壊れやすい物体を把持することを学ぶロボットアームは、シミュレーションで追加コストなしで何度も失敗できます。 物理シミュレーションによる学習の拡大： シミュレーションは初期のポリシー学習に十分な物理理解を提供します。膨大な並列トレーニングが可能になり、何百もの仮想環境を同時に実行することで、物理ロボットの学習時間を数週間から数時間に圧縮します。物理パラメータがトレーニング中に体系的に変化するドメインランダム化などの技術は、モデルが実世界の条件に一般化するのを助けます。 実世界の検証の必要性 シミュレーションの利点にもかかわらず、生産準備が整ったフィジカル AI アプリケーションには実世界のデプロイメントが不可欠です。sim-to-real のギャップは、シミュレートされた物理と実際の物理の違いを表し、パフォーマンス、安全性、信頼性、運用効果に大きな影響を与える可能性があります。 物理の忠実度と環境の複雑さ： 実際のセンサーは、シミュレーションでは近似しきれない微妙な違いを捉えます。表面のテクスチャの変化、照明条件、材料のコンプライアンス、動的な環境要因などが含まれます。また、生産環境では予測不可能なシナリオが発生します。 継続的な改善： システムが生産で動作するにつれて、モデルの改良に情報を提供する新しい状況に遭遇します。運用データは、モデルの改善を導くエッジケースとパフォーマンスギャップを明らかにします。包括的なセンサーフィードバック（力センサー、ジョイントエンコーダ、カメラ、加速度計）を備えた実世界のテストは、モデルの有効性を検証します。ミリ秒のデータストリーミングにより、継続的なパフォーマンスモニタリングが可能になります。 エンドツーエンドアーキテクチャの概要 以下のアーキテクチャガイダンスは、シミュレーションベースと実世界の強化学習の 2 つの補完的な経路を通じて、フィジカル AI ロボティクスアプリケーションの開発を可能にします。このソリューションは、NVIDIA Isaac または力、視覚、位置、動作センサーなどの実世界のインテリジェントセンサーデータを通じて物理を管理します。シミュレーションパスでは、実世界の実装前に仮想環境でモデルをトレーニングします。一方、実世界パスでは、センサーデータを通じて実際の物理的相互作用をキャプチャします。トレーニングされたモデルは、エッジデバイスにデプロイされ、推論ベースの制御ポリシーを実装し、反復学習のためにリアルタイムのセンサーデータを摂取します。これにより、人間のような知性を模倣し、指定されたタスクを自律的に実行するシステムが可能になります。 この リファレンスアーキテクチャ には、並行して動作する 2 つの補完的な学習ループが実装されています。 図 1: このガイダンスアーキテクチャは、AWS 上で高度な AI 機能を物理ロボティクスシステムと統合する方法を示しており、実世界の環境で自律的な操作を可能にします シミュレーショントレーニングループ – 構築と学習 GPU 搭載の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上でコンテナで実行される Isaac Sim から始まります。エンジニアはシステムの運動学をモデル化し、物理制約を定義し、運用シナリオを表す仮想環境を作成します。Isaac Lab は、物理パラメータ、環境条件、タスクの複雑さのバリエーションをテストしながら、トレーニングを複数の並列シナリオにわたってスケールします。 AWS Batch はシミュレーションワークロードを調整し、 Amazon EC2 自動スケーリング グループで GPU コンピューティングリソースを動的にプロビジョニングします。トレーニングの需要が変動するにつれて、インフラストラクチャは自動的にスケールし、集中的なフェーズでは追加のインスタンスを起動し、アイドル期間中はスケールダウンして、コスト効率を最適化します。トレーニングされたモデルと関連するポリシーは、 Amazon Simple Storage Service (Amazon S3) に保存されます。Amazon S3 は耐久性のあるバージョン管理されたストレージを提供します。 Amazon Elastic Container Registry (Amazon ECR) は、環境間での一貫したデプロイメントのためにコンテナイメージを管理します。 実世界の学習ループ – デプロイと監視 シミュレーショントレーニングで候補モデルが生成されると、エンジニアはそれを AWS IoT Greengrass が実行されているエッジインフラストラクチャにデプロイします。 NVIDIA Jetson Thor などの物理ロボットコントローラーでリアルタイムの推論を行います。これらのエッジデバイスは二重の目的を果たし、リアルタイム制御のための ML 推論を実行し、包括的なセンサーデータを収集します。 AWS IoT Greengrass コンポーネントは複数のセンサータイプからのリアルタイムフィードバックを処理します。 マルチモーダルデータは 2 つの経路で処理されます。時系列テレメトリを含む MQTT メッセージ形式の構造化センサーデータは、 AWS IoT Core と Amazon Data Firehose を経由して Amazon S3 データレイクに送られます。カメラからのビデオストリームは&nbsp; Amazon Kinesis Video Streams を介してキャプチャされます。 AWS Glue クローラーは運用データをカタログ化し、 Amazon Athena を通じてクエリ可能にし、 AWS Lake Formation を介して管理可能にします。 Amazon SageMaker AI は、実世界の運用データのバッチを処理してモデルを再トレーニングおよび最適化し、sim-to-real へのギャップを明示的に埋めます。 洗練されたモデルは AWS IoT Greengrass を介してエッジデバイスにデプロイされ、動作が改善されます。モニタリングレイヤーはパフォーマンスメトリクスを継続的に追跡し、モデルドリフトを検出します。パフォーマンスが低下すると、再トレーニングワークフローがトリガーされます。これにより、システムが運用データを生成し、モデルが実世界のパフォーマンスに基づいて洗練され、改善されたモデルが再デプロイされ、サイクルが繰り返される継続的な改善が実現します。 組み立て製造における実世界のアプリケーション 電子機器製造、自動車組立、精密工学で必要とされる、歯車部品を厳密な公差で挿入するような接触が豊富な操作タスクを含む一般的な産業の課題を考えてみましょう。これらのタスクには、リアルタイムで接触力に応答する高度な制御戦略が必要です。 Universal Robots (UR) は、Isaac ライブラリの統合を通じてこの機能を示しています。彼らのロボットアームは、適応的な力フィードバックと制御戦略を使用して、穴にペグをミクロンレベルの精度で挿入します。 シミュレーションフェーズ: シミュレーションフェーズでは、エンジニアは Isaac Sim で UR ロボットアーム、ワークピースの形状、組立フィクスチャをモデル化します。また、材料特性、摩擦係数、接触力学を含む物理パラメータを定義します。Isaac Lab で強化学習を使用して、システムはドメインランダム化、挿入角度、初期位置、摩擦パラメータ、部品公差の変化を含む何千ものシナリオでトレーニングします。これにより、力制御挿入の初期ポリシーが開発され、ロボットが接触を感知し、アプローチ角度を調整し、適切な力を適用するように教えます。 導入と改良: 導入と改良では、トレーニングされたポリシーモデルは、ロボットコントローラー上の AWS IoT Greengrass を介してデプロイされます。生産テスト中、力センサー、ジョイントエンコーダ、位置センサーは AWS にリアルタイムデータをストリームします。これにより、sim-to-real へのギャップが明らかになります。例えば、実際の摩擦がシミュレーション値を超えたり、実際の部品公差がモデル化された値よりも大きく変化したりします。 Amazon SageMaker は運用データを処理します。そして、実世界の物理を考慮したモデルを再トレーニングします。エンジニアは挿入の失敗が特定の力プロファイルと相関していることを発見し、ターゲットを絞った改善を可能にします。洗練されたモデルはエッジに再デプロイされ、成功率を向上させます。この反復プロセスは、ロボットが新しいバリエーションに遭遇するにつれて継続します。モニタリングシステムは主要なパフォーマンス指標を追跡し、メトリクスが許容範囲外にドリフトしたときに再トレーニングをトリガーします。 図 2: ロボットアームギアアセンブリ デュアルパスアーキテクチャは多様なフィジカル AI アプリケーションに適用されます。組織は医薬品取り扱いのための器用な操作システム、動的な倉庫ナビゲーションのためのモバイルロボット、物流施設の人型ロボットの開発時にこれらの原則を適用できます。 成功のためのベストプラクティス 堅牢なシミュレーションから始める: &nbsp;実際のプロトタイプに基づいた物理モデルの定義に投資することが重要です。ユーザーは、強化学習のための適切な報酬関数を開発します。シミュレーションループ内で物理パラメータを反復的に調整し、プロトタイプで精度を検証することで、最良の結果が得られます。実世界へのデプロイメントの前にドメインランダム化を適用することも、堅牢なトレーニング結果をサポートする別の方法です。複数のシミュレーション反復は、物理テストよりもはるかに安価です。 段階的にデプロイする: 完全な生産の前に、制御された環境で実世界のテストを開始します。初期データでシミュレーションの仮定を検証し、重要なギャップを特定します。 包括的に計装する: 多様なセンサーをデプロイしてマルチモーダルデータをキャプチャし、物理的な検証を行います。より豊かな実世界のフィードバックにより、より効果的なモデル改良と自動再トレーニングトリガーによる継続的なモニタリングが可能になります。 シミュレーション-リアルのパリティを維持する: 実世界のデータが物理の洞察を明らかにするにつれて、シミュレーションモデルを更新して将来のトレーニングを改善します。これにより、各ドメインが他方を情報提供する美徳のサイクルを生成します。 フィジカル AI の実務への展開 ロボティクスやその他の自律システムにおける物理 AI は、研究環境から生産使用に移行しました。このリファレンスアーキテクチャは、組織が製造、物流、ヘルスケアなどを超えて実際のビジネス問題を解決する自律システムを開発するための実用的でスケーラブルな道筋を提供します。 シミュレーションベースのトレーニングの速度と安全性を実世界の学習の忠実度と組み合わせることで、組織は開発サイクルを加速し、コストを削減できます。また、運用経験を通じて継続的に改善するシステムをデプロイできます。シミュレーション優先と実世界優先の両アプローチに対応するアーキテクチャの柔軟性は、多様なユースケースと組織の準備レベルに対応します。 フィジカル AI の採用が加速するにつれて、シミュレーションと現実を効果的に橋渡しし、それぞれの強みを使用してアプリケーションを構築する組織が成功するでしょう。AWS のスケーラブルなインフラストラクチャと NVIDIA の物理シミュレーションプラットフォームにより、その未来は今日利用可能です。 始める準備はできましたか？ AWS Guidance for Physical AI for Robotics でリファレンスアーキテクチャにアクセスしてください。追加リソースについては、以下をご覧ください。物理ベースの仮想環境でのシミュレーション、テスト、合成データ生成のための NVIDIA Isaac Sim ドキュメント、エッジデプロイメントのための AWS IoT Greengrass ドキュメント、モデル開発と継続的な改良のための Amazon SageMaker AI ドキュメント、および GPU アクセラレーテッドコンピュートのための AWS Batch ドキュメントがあります。 <!-- '"` --> Srinivas Nidamarthi Dr. Srinivas Nidamarthi は、AWS の自動車および製造業ビジネスユニットにおけるフィジカル AI、ロボティクス、およびソフトウェア定義ファクトリーの GTM 製品のグローバルヘッドおよび技術ビジネス開発リードです。彼は顧客の製造業の課題を解決することに焦点を当てた製品開発をリードしています。以前、Srinivas は ABB ロボティックシステムズの CTO を務め、多様な顧客と地域にわたって高度な製造自動化ソリューションを構築しました。彼は英国ケンブリッジ大学で博士号を取得しており、デジタルファクトリーの課題に取り組むため、彼の研究と専門知識を応用しています。 Alex Mevec Alex Mevec は NVIDIA のクラウドサービスプロバイダーチームのソリューションアーキテクトであり、顧客が ML および AI ソリューションを採用するのを支援しています。彼はロボティクスとフィジカル AI を専門としています。 Ali Shahrokni Ali Shahrokni は NVIDIA のシニア開発者リレーションズマネージャーで、Amazon および AWS チームとの戦略的技術コラボレーションをリードし、高度なロボティクス、AI、およびコンピュータビジョンソリューションを構築しています。彼はスイス EPFL でコンピュータビジョンの博士号を取得しています。Amazon、eBay、Magic Leap、およびオックスフォード大学で AI、3D 再構築、シーン理解、および拡張現実のイニシアチブを推進し、最先端の研究をスケーラブルな産業アプリケーションにもたらす重要なリーダーシップおよび技術的役割を担ってきました。 Brian Kreitzer Brian Kreitzer は Amazon Web Services (AWS) のパートナーソリューションアーキテクトです。彼はパートナーと協力して、AWS 顧客向けのアクセラレータとソリューションを作成し、技術的な共同販売機会にも取り組んでいます。 Raja GT Raja GT は Amazon Web Services (AWS) のワールドワイドシニアソリューションアーキテクトです。彼は製造パートナーや顧客と緊密に協力し、技術戦略を提供し、戦略的パートナーが AWS 顧客向けの業界ソリューションを構築およびスケールアップできるようにしています。彼は AWS 製造技術フィールドコミュニティのコアメンバーであり、製造クラウド採用に関する技術ガイダンスとソートリーダーシップを提供しています。彼は航空宇宙、自動車、ヘルスケア、エネルギー産業で 20 年以上の経験があり、クラウド上の製品ライフサイクル管理、サプライチェーン、スマート製造、産業データ/AI アプリケーションを専門としています。

2026 年4 月 14 日、 AWS Interconnect – マルチクラウド の一般提供についてお知らせします。これは、 Amazon Virtual Private Cloud (Amazon VPC) を他のクラウドプロバイダーの VPC に直接接続するマネージドプライベート接続サービスです。また、 AWS Interconnect – ラストマイル もご紹介します。これは、既存のネットワークプロバイダーを通じて、ブランチオフィス、データセンター、遠隔地から AWS への高速でプライベートな接続を簡単に確立できる新機能です。 専門サービスの利用、データレジデンシーの要件への対応、さまざまなプロバイダーで標準化されたチームのサポートなど、複数のクラウドプロバイダー全体でワークロードを実行する大企業が増えています。これまで、これらの環境を確実かつ安全に接続するには、VPN トンネルの管理、コロケーション施設との連携、サードパーティのネットワークファブリックの設定など、大幅な調整が必要でした。その結果、ネットワーキングチームは、ビジネスにとって重要なアプリケーションに集中するのではなく、差別化されていない面倒な作業に時間を費やすことになります。 AWS Interconnect はこれらの課題に対する答えです。これは、AWS への接続を簡素化するマネージド接続サービスです。Interconnect を使用すると、ハイブリッドおよびマルチクラウド環境全体で、専用帯域幅を使用して AWS との間でプライベートな高速ネットワーク接続を確立できます。場所、パートナー、またはクラウドプロバイダー、優先リージョン、および帯域幅要件を選択することで、AWS コンソールを通じて数回クリックするだけで、回復力のあるエンドツーエンドの接続を簡単に設定できます。これにより、パートナーを見つける手間が省け、手動でネットワークを設定する複雑さがなくなります。 2 つの機能を備えています。1 つは AWS と他のクラウドプロバイダー間のマルチクラウド接続、もう 1 つは AWS とオンプレミスのプライベートネットワーク間のラストマイル接続です。どちらの機能も同じ原則に基づいて構築されています。つまり、チームからインフラストラクチャの複雑さを排除する、完全に管理されたターンキーエクスペリエンスです。 AWS Interconnect – マルチクラウド AWS Interconnect – マルチクラウドを使用すると、お客様の AWS 環境と他のクラウドプロバイダーとの間で、プライベートでマネージド型のレイヤー 3 接続が可能になります。最初は Google Cloud からで、Microsoft Azure は 2026 年後半にリリースされる予定です。トラフィックはすべて AWS グローバルバックボーンとパートナークラウドのプライベートネットワーク上をフローするため、パブリックインターネットを経由することはありません。つまり、物理インフラストラクチャを自分で管理しなくても、予測可能なレイテンシー、一貫したスループット、およびインターネット輻輳からの隔離が可能になります。 セキュリティはデフォルトで組み込まれています。すべての接続では、相互接続施設にある AWS ルーターとパートナークラウドプロバイダーのルーター間の物理リンク上で IEEE 802.1AE MACsec 暗号化が使用されます。これらを個別に設定する必要はありません。各クラウドプロバイダーは独自のバックボーンで個別に暗号化を管理しているため、特定のデプロイの暗号化ドキュメントをレビューして、コンプライアンス要件を満たしていることを確認する必要があることに注意してください。耐障害性も組み込まれています。各接続は、少なくとも 2 つの物理施設に分散された複数の論理リンクにまたがっているため、1 つのデバイスまたは建物に障害が発生しても接続が中断されることはありません。 モニタリングについては、AWS Interconnect – マルチクラウドは Amazon CloudWatch と統合されています。各接続には Network Synthetic Monitor が付属しており、ラウンドトリップの遅延やパケットロスを追跡したり、キャパシティプランニングをサポートする帯域幅使用率メトリクスを追跡したりできます。 AWS は基礎となる仕様を Apache 2.0 ライセンスの下で GitHub に公開しており 、あらゆるクラウドサービスプロバイダーにAWS Interconnect – マルチクラウドとのコラボレーションの機会を提供しています。AWS Interconnect パートナーになるには、クラウドプロバイダーは技術仕様を実装し、耐障害性基準、サポートコミットメント、サービスレベル契約などの AWS 運用要件を満たしている必要があります。 仕組み 接続のプロビジョニングには数分かかります。私は、AWS Direct Connect コンソールから接続を作成します。私は、AWS Interconnect セクションから始めて、プロバイダーとして Google Cloud を選択します。私は、私のソースリージョンと送信先リージョンを選択します。私は、帯域幅を指定し、私の Google Cloud プロジェクト ID を指定します。AWS はアクティベーションキーを生成し、私はこれを Google Cloud 側で使用して接続を完了します。ルートは両方向に自動的に伝達され、私のワークロードはすぐにデータの交換を開始できます。 このデモでは、私は単一の VPC から始めて、それを Google クラウド VPC に接続します。私は、Direct Connect ゲートウェイを使用します。これは最もシンプルな方法です。1 つの接続、1 つのアタッチメントであり、両側のワークロードが数分で相互に通信を開始できます。 ステップ 1: AWS マネジメントコンソール で相互接続をリクエストします。 私は、 AWS Direct Connect 、 AWS Interconnect に移動し、[ 作成 ] を選択します。私はまず、接続したいクラウドプロバイダーを選択します。この例では、Google Cloud です。 私は、次に AWS リージョン ( eu-central-1 ) と Google Cloud リージョン ( europe-west3 ) を選択します。 ステップ 3 で、私は「 説明 」を入力し、 帯域幅 、アタッチする Direct Connect ゲートウェイ 、 Google Cloud プロジェクト の ID を選択します。 リクエストをレビューして確認すると、コンソールからアクティベーションキーが渡されます。私は、そのキーを使用して、Google クラウド側でリクエストを検証します。 ステップ 2: Google Cloud Platform (GCP) アカウントでトランスポートリソースと VPC ピアリングリソースを作成します。 私にはアクティベーションキーがあり、GCP 側でプロセスを続けることに注意してください。この記事の執筆時点では、ウェブベースのコンソールは使用できませんでした。代わりに GCP コマンドライン (CLI) を使用することを選択しました。私は、 europe-west3 リージョンの GCP VPC サブネットの CIDR 範囲に注目します。次に、私はターミナルを開いて、次のように入力します。 gcloud network-connectivity transports create aws-news-blog \ --region=europe-west3 \ --activation-key=${ACTIVATION_KEY} \ --network=default \ --advertised-routes=10.156.0.0/20 Create request issued for: [aws-news-blog] ... peeringNetwork: projects/oxxxp-tp/global/networks/transport-9xxxf-vpc ... state: PENDING_CONFIG updateTime: '2026-03-19T09:30:51.103979219Z' コマンドが完了するまでに数分かかります。コマンドが返されたら、私は GCP VPC と作成した新しいトランスポートとの間にピアリングを作成します。私は、これを GCP コンソールまたは gcloud コマンドラインで実行できます。前のコマンドではターミナルを使用していたので、そのコマンドラインを続行しました: gcloud compute networks peerings create aws-news-blog \ --network=default \ --peer-network=projects/oxxxp-tp/global/networks/transport-9xxxf-vpc \ --import-custom-routes \ --export-custom-routes ネットワーク名は私の GCP VPC の名前です。ピアネットワークは前のコマンドの出力に表示されます。 完了したら、私は GCP コンソールでピアリングを確認できます。 AWS Interconnect コンソールで、私はステータスが 利用可能 であることを確認します。 AWS Direct Connect コンソールの [ Direct Connect ゲートウェイ ] に、新しいインターコネクトへのアタッチメントが表示されます。 ステップ 3: 新しいゲートウェイを AWS 側で関連付ける 私は、[ ゲートウェイの関連付け ] と [ ゲートウェイを関連付ける ] を選択して、このデモを開始する前に作成した仮想プライベートゲートウェイ (VGW) をアタッチします (インターコネクトと同じ AWS リージョンの VGW を使用する場合は注意してください)。 GCP 側でネットワークルーティングを設定する必要はありません。AWS では、最後のステップがあります。VPC ルートテーブル でルートエントリを追加して、すべてのトラフィックを Virtual Gateway 経由で GCP IP アドレス範囲に送信します。 ネットワークのセットアップが完了したら。私は、2 つのコンピューティングインスタンスを起動します。1 つは AWS 上で、もう 1 つは GCP 上です。 AWS 上で、私はセキュリティグループが TCP:8080 で受信トラフィックを受け入れることを確認しました。私は、マシンに接続し、最小限のウェブサーバーを起動します: python3 -c \ "from http.server import HTTPServer, BaseHTTPRequestHandler class H(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200);self.end_headers() self.wfile.write(b'Hello AWS World!\n\n') HTTPServer(('',8080),H).serve_forever()" GCP 側で、私はマシンへの SSH セッションを開き、プライベート IP アドレスで AWS ウェブサーバーを呼び出します。 Et voilà! 私には 2 つのネットワーク間にプライベートネットワークルートがあり、すべてが 2 つのクラウドサービスプロバイダーによって管理されています。 知っておくべきこと 覚えておくべき設定オプションがいくつかあります: ネットワークを接続するときは、両側の IP アドレス範囲に注意してください。GCP と AWS VPC の範囲は重複できません。このデモでは、AWS 上のデフォルト範囲は 172.31.0.0/16 で、GCP 上のデフォルトは 10.156.0.0/20 でした。私は、これらのデフォルト値で続行できました。 IPV4、IPV6、またはその両方を両側に設定できます。両側で同じオプションを選択する必要があります。 最大転送単位 (MTU) は両方の VPC で同じである必要があります。AWS VPC と GCP VPC のデフォルト値はそうではありません。MTU は、ネットワークインターフェイスがフラグメンテーションなしで送信できる最大パケットサイズ (バイト単位) です。ピアリングされている VPC 間の MTU サイズが一致しないと、パケットのドロップやフラグメンテーションが発生し、サイレントデータ損失、スループットの低下、インターコネクト全体での接続切断につながります。 詳細については、 GCP Partner Cross Cloud Interconnect と、 AWS Interconnect ユーザーガイド を参照してください。 参照アーキテクチャ デプロイが拡大し、1 つのリージョンに複数の VPC がある場合、AWS Transit Gateway は、1 つのインターコネクトアタッチメントを通じてそれらすべてを接続する一元的なルーティングハブを提供します。クラウドの境界を越えるものを検査する必要がある場合は、環境間でトラフィックをセグメント化し、一貫したルーティングポリシーを適用し、AWS Network Firewall を統合できます。 また、複数の AWS リージョンと複数の Google Cloud 環境全体で分散しているワークロードを使用し、グローバル規模で運用している場合、AWS Cloud WAN は同じモデルを世界中に拡張します。一元化されたポリシー管理と、運用しているすべての場所で一貫して適用されるセグメントベースのルーティングにより、ネットワーク内のどのリージョンでも世界中のあらゆる Interconnect アタッチメントにアクセスできます。 私の同僚の Alexandra と Santiago は、これらの参照アーキテクチャをブログ投稿で文書化しています:「 AWS Interconnect – マルチクラウドで回復力がありスケーラブルなマルチクラウド接続アーキテクチャを構築する 」。 AWS Interconnect – ラストマイル AWS Interconnect – ラストマイルは、AWS Interconnect – マルチクラウドと同じアーキテクチャと設計に基づいており、参加しているネットワークプロバイダーのラストマイルインフラストラクチャを通じて、 AWS マネジメントコンソール から直接、オンプレミスまたはリモートロケーションを AWS に接続できます。 オンボーディングプロセスは AWS Interconnect – マルチクラウドを反映しています。プロバイダーを選択し、認証し、接続エンドポイントと帯域幅を指定します。AWS は、お客様がプロバイダーコンソールで提供するアクティベーションキーを生成して、設定を完了します。AWS Interconnect – ラストマイルでは、2 つの物理的な場所全体で 4 つの冗長接続が自動的にプロビジョニングされ、BGP ルーティングが設定され、MACsec 暗号化と Jumbo Frames がデフォルトでアクティブ化されます。その結果、ネットワーキングコンポーネントを手動で設定しなくても、ベストプラクティスに沿った AWS への回復力のあるプライベート接続が実現します。 AWS Interconnect – ラストマイルは 1 Gbps から 100 Gbps までの帯域幅をサポートし、再プロビジョニングせずにコンソールから帯域幅を調整できます。このサービスには、Direct Connect ポートの最大 99.99% の可用性 SLA が含まれており、接続状態を監視するための CloudWatch Network Synthetic Monitor がバンドルされています。AWS Interconnect – マルチクラウドと同様に、AWS Interconnect – ラストマイルは Direct Connect ゲートウェイにアタッチされ、仮想プライベートゲートウェイ、トランジットゲートウェイ、またはAWS Cloud WAN デプロイに接続されます。詳細については、 AWS Interconnect ユーザーガイド を参照してください。 Lumen Technologies の SVP Product である、Scott Yow 氏は次のように書いています: AWS Interconnect – ラストマイルを Lumen ファイバーネットワークおよび Cloud Interconnect と組み合わせることで、クラウドの採用を遅らせることが多いラストマイルの複雑さを簡素化し、お客様にとってより迅速で回復力のある AWS へのパスを実現します。 料金と利用可能なリージョン AWS Interconnect – マルチクラウドと AWS Interconnect – ラストマイルの料金は、お客様がリクエストしたキャパシティの定額時間料金に基づいており、時間単位で請求されます。ワークロードのニーズに合った帯域幅階層を選択できます。 AWS Interconnect – マルチクラウドの料金はリージョンのペアによって異なります。米国東部 (バージニア北部) と Google Cloud 北バージニア間の接続は、米国東部 (バージニア北部) とより遠いリージョン間の接続とは料金が異なります。AWS Cloud WAN を使用する場合、グローバルな Any-to-Any ルーティングモデルでは、トラフィックが複数のリージョンを通過できるため、デプロイの総コストに影響します。接続のサイズを決定する前に、 AWS Interconnect の料金ページ でリージョンペア別およびキャパシティ階層別のフルレートカードを確認することをお勧めします。 AWS Interconnect – マルチクラウドは現在、米国東部 (バージニア北部) から Google Cloud 北バージニア、米国西部 (北カリフォルニア) から Google Cloud ロサンゼルス、米国西部 (オレゴン) から Google Cloud オレゴン、欧州 (ロンドン) から Google Cloud ロンドン、欧州 (フランクフルト) から Google Cloud フランクフルトの 5 つのリージョンペアでご利用いただけます。Microsoft Azure のサポートは 2026 年後半に開始される予定です。 AWS Interconnect – ラストマイルが米国東部 (バージニア北部) でリリースされ、Lumen が最初のパートナーとなります。AT&amp;T や Megaport など、その他のパートナーも進行中で、リージョンも追加される予定です。 AWS Interconnect の使用を開始するには、 AWS Direct Connect コンソール にアクセスし、ナビゲーションメニューから AWS Interconnect を選択します。 お客様の環境で AWS Interconnect がどのように使用されているかをぜひお聞かせください。以下にコメントを残すか、 AWS re:Post コミュニティ を通じてお問い合わせください。 – seb 原文は こちら です。

本稿は、SBI ネオバンキングシステム株式会社による AWS EKS Auto Modeの活用について、主導されたSBI ネオバンキングシステム株式会社 新藤様より寄稿いただきました。 はじめに SBI ネオバンキングシステム株式会社（以下、弊社）は、地方銀行向けのインターネットバンキングサービスをマルチテナント型 SaaS として開発・運用しています。サービス基盤には Amazon Elastic Kubernetes Service（以下、Amazon EKS）を採用しており、従来は AWS Fargate（以下、Fargate）上でワークロードを実行していました。 本記事では、2024 年 12 月の AWS re:Invent で一般提供が開始された Amazon EKS Auto Mode（以下、EKS Auto Mode）を 2025 年 9 月に導入し、AWS Fargate からの移行によって実現した運用負荷の軽減効果についてご紹介します。 SBI ネオバンキングシステムについて 弊社は、地方銀行のお客様が残高照会や振込といった銀行取引をスマートフォンやブラウザから行えるインターネットバンキングサービスを開発・運用しています。マルチテナント型の SaaS として構築しており、2026 年 3 月時点で4行の地方銀行向けにサービスを提供しています。 提供先の銀行が増えるにつれ、リリース頻度や運用イベント（バージョンアップ、パッチ適用、監視対応など）も増加するため、少人数でも安定した運用を実現できるアーキテクチャが求められていました。 システムの規模としては、3 つのアベイラビリティゾーン（AZ）を活用し、東京リージョンをプライマリ、大阪リージョンを DR（災害対策）環境とするマルチリージョン構成を採用しています。本番環境に加えて 3 つの開発環境を運用しており、合計 8 クラスターを管理しています。本番環境のクラスターでは約 60 の Pod が稼働しています。 EKS Auto Mode 導入の背景 Fargate を中心とした従来の運用には、以下の 3 つの課題がありました。 課題 1: EKS バージョンアップの運用負荷 Amazon EKS のバージョンアップでは、コントロールプレーン、アドオン、データプレーンをそれぞれ更新する必要があります。弊社の環境では、東京リージョンでは Fargate、大阪リージョンでは当時の構成上マネージドノードグループを利用していたため、コントロールプレーンとアドオンに加えてマネージドノード側の更新も含めた複数箇所を手動で操作する必要がありました。アップデート中には他の本番適用作業を並行で進めますが、手動操作のために作業が中断されてしまうことがストレスに感じていました。また、金融サービスとして安全にアップデートを実施できる仕組みの確保も重要な要件でした。 課題 2: EKS アドオンの自前管理負荷 AWS Load Balancer Controller、CoreDNS、kube-proxy といったアドオンを自前で管理していました。Amazon EKS のバージョンアップのたびにアドオンの互換性を確認し、適切なバージョンを選定・更新する作業が発生していました。 課題 3: Fargate 固有の運用負荷 Fargate 環境では、以下の運用負荷が発生していました。 Datadog サイドカーコンテナの管理 : Fargate では DaemonSet が利用できないため、各 Pod に Datadog Agent をサイドカーとして配置する必要があり、マニフェストの記述量が増加するだけでなく、サービスに直接関係しない Datadog Agent の記述が混在することでマニフェストの見通しが悪化 Fargate 組み込みログルーターの設定 : Fargate の組み込みログルーター（Fluent Bit ベース）経由で Amazon CloudWatch Logs へ転送する構成のため、Pod ごとにロググループの管理が必要 イメージキャッシュが利用不可 : Fargate ではコンテナイメージのキャッシュが効かず、Pod 起動のたびにイメージを Pull する必要があり、起動が遅延 これらの課題を踏まえ、AWS にインフラ管理をより広く委ねることで運用負荷を大幅に軽減することを目指し、EKS Auto Mode の導入を決定しました。 アーキテクチャ概要 本節では、EKS Auto Mode 導入に伴うアーキテクチャの変化を説明します。 図: 移行後のアーキテクチャ（EKS Auto Mode 構成） EKS Auto Mode で変わったこと コンピュート: Fargate から EC2（Auto Mode 管理）へ EKS Auto Mode の導入により、データプレーンが Fargate から EKS Auto Mode が管理する Amazon EC2 インスタンスへ移行しました。ノードのプロビジョニング、スケーリング、パッチ適用は AWS が自動的に管理します。EKS Auto Mode はノードのプロビジョニングにオープンソースの Kubernetes ノードオートスケーラーである Karpenter を内部で利用しており、NodePool でインスタンスタイプや有効期限などのノード仕様を定義します。弊社の環境では、ビルトインの NodePool が提供するインスタンスタイプが要件に合わなかったため、カスタム NodePool を作成してインスタンスタイプを指定しています。ノードの更新サイクル（ expireAfter ）はデフォルトの 336h （14 日）です。また、EC2 ノードではコンテナイメージのキャッシュが有効になるため、Fargate で課題だった Pod 起動の遅延も改善します。 アドオン: 自前管理からビルトインへ EKS Auto Mode では、CoreDNS、Amazon VPC CNI、Amazon EBS CSI driver が AMI に内蔵された systemd サービスとして提供され、AWS Load Balancer Controller や kube-proxy も AWS によって管理されます。これにより、アドオンのバージョン管理や Amazon EKS バージョンとの互換性確認から解放されました。 バージョンアップ: 複数箇所の手動操作からワンクリックへ 従来はコントロールプレーン、アドオン、マネージドノードの各箇所を個別に操作する必要がありました。安全なアップデートの実現手段として、ブルー/グリーンデプロイメントによるクラスター切り替えも検討しましたが、2 つのクラスターの並行運用やエンドポイント切り替えに伴う運用負荷の増加に対し、EKS Auto Mode が提供するコントロールプレーンの自動ロールバックとノードの自動更新により、インプレースでも十分な安全性を確保できると判断しました。コンソールでのワンクリックで開始した後は自動で進行し、おおむね 30 分で完了します。コントロールプレーンのアップデートに失敗した場合は自動でロールバックされ、ノードも自動で更新されます。失敗時は旧ノードが継続稼働するため、サービスへの影響を最小限に抑えられます。 監視: Datadog サイドカーから DaemonSet Agent へ Fargate では各 Pod にサイドカーとして Datadog Agent を配置していましたが、EC2 ノード上では DaemonSet として Datadog Agent を配置し、ノードの IP アドレス（ hostIP ）経由で各 Pod と通信する構成に変更しました。これにより、Fargate の組み込みログルーターも不要になりました。 同時に行ったアーキテクチャ改善 EKS Auto Mode への移行にあたっては新規クラスターを作成し、旧クラスターからブルー/グリーン方式で切り替えました。日常のバージョンアップとは異なり、Fargate からの移行に加えて NLB から ALB への集約なども含む大規模な構成変更であったため、移行時に限りブルー/グリーン方式を採用しています。従来の構成には NLB ではゼロダウンタイムのローリングアップデートが実現できない点や、Amazon API Gateway に AWS Shield Advanced を適用できず DDoS 自動緩和機能が利用できない点といった課題があったため、クラスターを新規に構築するこのタイミングに合わせて、以下のアーキテクチャ改善も実施しました。 NLB から ALB への集約 従来は Amazon API Gateway と Network Load Balancer（NLB）をテナント数分用意する構成でしたが、Application Load Balancer（ALB）1 台に集約しました。Kubernetes の Ingress リソースと ALB のグルーピング機能を活用し、1 つの ALB に複数テナントを収容しています。これにより、AWS WAF の一元管理と AWS Shield Advanced による DDoS 自動緩和の適用も可能になりました。 IaC 管理の改善 ExternalDNS をマニフェスト管理から Terraform の Helm 管理へ移行し、Datadog Agent も同様に Terraform の Helm 管理に統合しました。変更内容の見通しと再現性が向上しています。 Before / After 比較 項目 Before(Fargate) After(Auto Mode) コンピュート AWS Fargate(東京)/ マネージドノード(大阪) EKS Auto Mode(EC2) ノード管理 不要(Fargate)/ マネージドノード(大阪) AWS 自動管理(パッチ適用・スケーリング) アドオン管理 自前管理(AWS Load Balancer Controller、CoreDNS 等) AWS 管理(AMI 内蔵 systemd) バージョンアップ 複数箇所の手動操作 ワンクリックで開始 → 約 30 分で自動完了 監視エージェント Datadog サイドカー(各 Pod) Datadog Agent DaemonSet ログ転送 Fargate 組み込みログルーター → CloudWatch Datadog Agent 直接転送 LB 構成 API Gateway + NLB × テナント数 ALB × 1 導入時に直面した課題と解決策 EKS Auto Mode の導入にあたり、いくつかの課題に直面しました。以下に事象、原因、対処をまとめます。 1. セキュリティグループの追加設定 事象 : Fargate から EC2 ノードへの移行に伴い、ネットワーク通信の設定変更が必要でした。 原因 : Fargate では各 Pod に専用の ENI（Elastic Network Interface）が割り当てられるため、弊社の構成ではセキュリティグループの明示的な設定は不要でした。EC2 ノードでは複数の Pod が同一ノードの ENI を共有するため、ノードレベルでの通信許可が必要になります。 対処 : EC2 ノードのセキュリティグループに以下の許可ルールを追加しました。 データベースへの接続許可 ノード間の Pod 通信の許可 2. ASCP の Pod Identity タイムアウト 事象 : AWS Secrets Manager のシークレットを Kubernetes の Secret として Pod に注入する ASCP（AWS Secrets and Configuration Provider）で、EKS Pod Identity を使用した際に認証がタイムアウトする問題が発生しました。 原因 : EKS Pod Identity のタイムアウト値（100ms）が短すぎるという既知の問題でした。 対処 : Pod に AWS IAM の権限を付与するもう 1 つの方式である IAM Roles for Service Accounts（IRSA）に切り替えることで回避しました。 3. ALB サブネットの自動検出 事象 : EKS Auto Mode の AWS Load Balancer Controller がサブネットを自動検出できず、ALB の作成に失敗しました。 原因 : VPC サブネットに EKS クラスター識別用のタグが設定されていませんでした。 対処 : サブネットに必要なタグを追加することで、自動検出が正常に動作するようになりました。 導入効果 運用負荷の大幅な軽減 EKS Auto Mode 導入による最大の効果は、運用負荷の大幅な軽減です。構成のシンプル化と合わせ、体感としては 50 ％程度の負荷軽減を実現できたと感じています。 EKS バージョンアップの簡素化 : 以前はクラスター、アドオン、マネージドノードを含む複数箇所の操作が必要でしたが、ワンクリックで開始した後は約 30 分で自動完了するようになりました。本記事の執筆にあたり実際にバージョンアップを実施しましたが、アップデート中に何度も戻る必要がないので他の本番適用作業を中断されることなく、集中して進められました。 EKS アドオンの管理不要 : AWS Load Balancer Controller、CoreDNS、kube-proxy 等が AWS 管理となり、バージョン管理や互換性確認の作業から解放されました。 ノード管理不要 : マネージドノードを運用していた大阪リージョンについては、パッチ適用やスケーリングが自動化され、ノードの運用管理が不要になりました。これは弊社固有の事情ですが、東京リージョンと大阪リージョンの構成が同じ EKS Auto Mode 構成になったことで、リージョンを問わず同一の運用手順で対応できるようになった点も嬉しいです。 構成のシンプル化 Datadog サイドカーの廃止 : 各 Pod からサイドカーコンテナを削除し、DaemonSet に集約したことで、マニフェストの記述量が削減され、Pod 構成がシンプルになりました。 Fargate ログルーターの廃止 : Fargate の組み込みログルーターと Pod ごとの CloudWatch ロググループが不要になり、ログ転送設定が簡略化されました。 Pod 起動の高速化 EC2 ノードのコンテナイメージのキャッシュを活用できるようになり、Pod の起動時間が短縮し、スケールアウト時の応答性向上にも寄与しています。 Pod 更新・ノードパッチ適用におけるゼロダウンタイムの実現 NLB から ALB への集約と合わせてローリングアップデート時のパラメータ調整（PreStop フック、登録解除遅延など）を実施し、ゼロダウンタイムでの Pod 更新を実現しました。また、ノードへの自動パッチ適用にあたってもエラーやレスポンスの遅延が発生することなく、安定して運用できています。 コスト削減（副次的な効果） 本取り組みの主目的は運用負荷の軽減でしたが、副次的な効果としてコスト最適化にも寄与しました。 課金単位が Pod 単位（Fargate）から EC2 インスタンス単位に変化し、ノードに複数 Pod を集約できるためリソース利用効率が向上 CloudWatch Logs への転送が不要になり、ログ関連コストが削減 NLB をテナント数分用意する構成から ALB 1 台への集約により、ロードバランサーのコストが削減 今後の展望 提供先の銀行が増加していく中で、マルチテナント基盤のさらなる拡充を進めていきます。EKS Auto Mode の機能拡張にも期待しており、AWS が提供するマネージドな領域が広がることで、弊社はアプリケーション開発とサービス品質の向上により集中できると考えています。 また、ローリングアップデートの安全性向上や、ノード・スケールの最適化（状況に応じたスポットインスタンスの活用検討を含む）にも継続して取り組んでいきます。 まとめ AWS Fargate から EKS Auto Mode への移行により、少人数の体制でも、金融 SaaS としての厳格な要件を満たしながら運用負荷を大幅に軽減できました。 EKS Auto Mode は、Kubernetes のメリットを活かしつつ、クラスター運用に伴う作業負荷を AWS に委ねたい場合に有力な選択肢となります。同様の課題を抱える方々にとって、本記事が参考になれば幸いです。 著者について 新藤 泰斗 SBI ネオバンキングシステム 株式会社 プラットフォーム・エンジニアリング部 SREグループ長 地方銀行向けインターネットバンキングサービスのインフラ基盤の設計・運用を担当し、Amazon EKS を中心としたマルチテナント基盤の信頼性と運用効率の向上に取り組んでいる。