TECH PLAY

AWS

AWS の技術ブログ

3151

本記事は 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 を中心としたマルチテナント基盤の信頼性と運用効率の向上に取り組んでいる。
2026 年 3 月 27 日、Chat Agent や Flows をはじめとする Amazon Quick の AI Agent 機能の東京リージョンローンチを記念したイベント「Amazon Quick Event」が開催されました。本イベントでは、Amazon Quick の製品紹介や Amazon 社内での活用事例に加え、AWS パートナー企業やお客様による具体的な導入事例が共有されました。会場には多くのお客様にお越しいただき、オンラインでも多数の方にご参加いただきました。本記事では、イベントの模様をレポートします。 オープニングご挨拶 イベント冒頭では、 AWS Japan Data &amp; AI 事業統括本部 の井形健太郎がオープニングの挨拶を行いました。 本イベントの趣旨として、Amazon Quick&nbsp;が東京リージョンで利用可能になったことを紹介し、参加者の皆様への感謝を述べました。 Amazon Quick&nbsp;のご紹介と&nbsp;Amazon&nbsp;内部での活用紹介 AWS Head of GTM, APJ-C, AI &amp; Agents&nbsp;のMichael Armentano&nbsp;は、ハーバードビジネススクールの&nbsp;Karim Lakhani&nbsp;教授の言葉「AI&nbsp;を活用する人間が、AI&nbsp;を活用しない人間を置き換える」を引用し、Amazon Quick&nbsp;が目指す世界観を示しました。生成&nbsp;AI&nbsp;がチャットボットから単一エージェント、そして複数エージェンティックシステムへと進化してきた流れを解説し、Amazon Quick&nbsp;が提供する&nbsp;4&nbsp;つのチームメイト(インサイトアシスタント、データアナリスト、PhD&nbsp;リサーチャー、オートメーションエキスパート)を紹介しました。Amazon Quick&nbsp;は&nbsp;AWS&nbsp;コンソールだけでなく、Word、Outlook、Slack&nbsp;などのプラグインからもアクセス可能です。 続いて AWS Sr. WW Specialist, Amazon Quick, WWSO Generative AIの Jihwan Ko が、Amazon 社内で 20 万人以上が Amazon Quick を利用し、30 万以上のワークフロー自動化を実現している実績を紹介しました。導入にあたっては、ステップバイステップの展開、ユーザー理解に基づくユースケース選定、チェンジマネジメントの徹底、社内ユースケースライブラリの構築という 4 つの戦略を実行しました。具体的な事例として、Amazon カナダの税務チームが Amazon Quick を使い、複数システムに散在していた税務データを統合ダッシュボードに集約し、コードを書かずに情報の可視化と分析を実現した事例を紹介しました。 Chat Agent&nbsp;から始める&nbsp;Amazon Quick&nbsp;におけるデータの活用 AWS Japan&nbsp;技術支援本部&nbsp;テクニカルアカウントマネージャー&nbsp;の服部&nbsp;洋明&nbsp;は、EC&nbsp;サイトを題材にした&nbsp;3&nbsp;つのデモを通じて、チャットエージェントの活用を実演しました。デモ&nbsp;1&nbsp;の売り上げ分析では、ダッシュボードの概要把握から時間帯別・日次の特徴分析、さらに分析手法の提案まで、チャットエージェントとの対話で段階的に深掘りしていく様子を示しました。Amazon Quick&nbsp;リサーチを用いて本格的な分析レポートを自動生成する流れも紹介しました。 デモ&nbsp;2&nbsp;のサポートデスク対応では、カスタムエージェントを使い、注文ステータスの確認からマニュアル参照、Slack&nbsp;への通知、顧客への一報作成、Salesforce&nbsp;へのケース登録までを&nbsp;Amazon Quick&nbsp;の中で一気通貫で完結する内容を紹介しました。 デモ&nbsp;3&nbsp;のシステム運用では、アラートの一次調査や&nbsp;AWS&nbsp;コスト分析をチャットエージェントで効率化する様子を紹介しました。服部は「Amazon Quick&nbsp;の中で完結できていることが重要」と強調し、Amazon&nbsp;Aurora、Amazon&nbsp;CloudWatch、Google&nbsp;Drive、Salesforce、Slack&nbsp;など多様なコネクターとの連携を紹介しました。 Flows&nbsp;と&nbsp;Automate&nbsp;でデータ活用を自動化し効率アップ AWS Japan&nbsp;技術統括本部&nbsp;Sr. Solutions Architect&nbsp;加藤&nbsp;菜々美は、Amazon Quick&nbsp;の&nbsp;Flows&nbsp;と&nbsp;Automate&nbsp;を使ったデータ活用の自動化をデモで紹介しました。 Flows&nbsp;のデモでは、商品の売り上げ分析を題材に、Amazon&nbsp;S3&nbsp;や&nbsp;SharePoint&nbsp;上の散在データを専門エージェントが横断的に活用し、週次売り上げの分析からリスク判定、Notion&nbsp;への自動アラート通知、Amazon Quick&nbsp;リサーチによる深い分析レポート生成までを、ノーコードで一つのフローとして構成する様子を示しました。 Automate&nbsp;のデモでは、受注時の顧客与信リスク判定を題材に、REST API&nbsp;による基幹システム連携、AI&nbsp;エージェントによる名寄せとリスク評価、構造化アウトプットによる正確なデータ引き継ぎ、そしてリスクレベルに応じた並列処理(ローリスクは自動承認、ハイリスクはヒューマン・イン・ザ・ループで人間が介入)を実演しました。加藤は「まず&nbsp;Flows&nbsp;で小さく始めて、Automate&nbsp;で本格的な自動化にチャレンジしてほしい」とまとめました。 AWS&nbsp;の&nbsp;AI&nbsp;エージェントと一緒にチャレンジする車両保全&nbsp;DX 東急電鉄株式会社の清水 想太 氏からは、鉄道車両保全業務における Amazon Quick 活用事例を紹介いただきました。東急電鉄様は 2024 年 3 月 25 日に公表した 2024 年度 ~ 2026 年度中期事業戦略において、データ活用による DX(CX・EX・CEX)推進を掲げています。車両部では、これまで取得してきたデータの分析による故障予防と、ベテラン社員の暗黙知の形式知化を目指し、車両の走行データや故障履歴データの活用に 2023 年からチャレンジをしています。一方でデータ分析には業務経験やシステム知識、 BI ツール習得、データ集計等の負荷が伴い、高いハードルが存在しました。今回 Quick を活用し、簡単なデータクレンジングやグラフ化、仮説検証を自然言語を用いて簡単に自動化することで複数のユースケースを試みています。以下はご紹介内容の抜粋です。 (1)故障履歴のテキストデータから AI が装置名を推定・補完し、機器分類表を根拠に正しくカテゴリー分け。これまではベテラン作業員が時間をかけていた作業を約 5 分で完了し、故障による遅延防止や安全性を考慮した保全優先度の算出をサポート (2)別の AI ツールも組み合わせながら、車両のコンプレッサーデータ 378 万行を分析し、蓄圧時間の乖離から故障兆候を把握する検証 清水氏は「Amazon&nbsp;Quick&nbsp;を使うことで分析のゴールイメージが早期に見え、それが学習意欲の向上につながる」と述べられ、今後は&nbsp;AI&nbsp;とベテランの経験を組み合わせた「共存型のデータ駆動保全」の実現を目指されています。 業務改革を実現する&nbsp;Amazon Quick&nbsp;戦略&nbsp;〜個人の知見を組織知へ〜 株式会社ポーラ・オルビスホールディングスの佐々木&nbsp;哲哉&nbsp;氏からは、Amazon Quick&nbsp;を組織変革の武器として選択した戦略についてご紹介いただきました。佐々木&nbsp;氏は、AI&nbsp;活用において「個人の生産性向上」にとどまることの危険性を指摘され、RPA&nbsp;導入時の経験も踏まえ、組織の生産性に貢献できるツールとして&nbsp;Amazon Quick&nbsp;を選択いただきました。 また、Amazon Quick を選択いただいた理由を4つ挙げていただきました。第一に、ほぼすべてのシステムが AWS 環境にあるため Amazon Quick から直接データに接続できるシームレスなデータ連携が可能ということ。第二に、Amazon QuickSight の統合により「観測→解釈→実行→記録→再学習」のサイクルを回し、個人の学びを組織知へ変換できる点。第三に、お客様データへのアクセスを厳格に制御する AWS のセキュリティ設計。第四に、最適なモデル選択による将来のコスト最適化の可能性です。 2026 年度はまず 500 名に教育とセットで展開し、2027 年には本社従業員への展開を目指されています。KPI を起点に部門の枠を超えた業務プロセスの一気通貫の変革を目標とされています。 Amazon Quick&nbsp;で実現する”脱管理”と&nbsp;CRM&nbsp;の未来 ソフトブレーン株式会社の富岡 大裕 氏は、国内シェア上位の CRM/SFA 製品 eセールスマネージャーに Amazon Quick を組み込んで顧客に提供する立場からの発表をされました。同社は 2019 年から Amazon QuickSight の SaaS 埋め込み機能を活用し、ギャップ分析や行動マネジメントなどの営業データ可視化基盤として組み込みを行っており、現在は月間 15 万回以上利用されていると話されました。 ユーザーからは&nbsp;Amazon Quick&nbsp;を使っていると意識されないレベルでシームレスに統合されているとフィードバックがあるとのこと。また、SaaS&nbsp;に&nbsp;Amazon Quick&nbsp;を組み込めるレベルで豊富なインターフェースが用意されているため、企業が&nbsp;Amazon Quick&nbsp;を単純利用する際にも将来的な拡張に対応できる安心感があると強調されました。 同社では「オートインプット・ジャストアウトプット(AI-JO)」をコンセプトに、AI&nbsp;議事録からの商談情報自動反映や見積書のドラッグ&ドロップによるデータ展開など、入力の自動化と分析の即時活用を実現されています。 富岡氏は、Amazon Quick&nbsp;のチャットエージェントで「今期の予実を出して」と話しかけるだけでグラフが自動生成される世界を示し、SFA&nbsp;が「脱管理」のツールへと進化すると展望されました。 複数社パートナー企業による&nbsp;Amazon Quick&nbsp;に関する支援内容のご紹介 後半のパートナーセッションでは、5社のパートナー企業がライトニングトーク形式で&nbsp;Amazon Quickの活用支援サービスを紹介しました。なお、本イベントでご紹介できなかったパートナー企業の&nbsp;Amazon Quick&nbsp;活用支援サービスについては、本記事末尾にリンクを掲載しておりますので、そちらもぜひご覧ください。 KDDIアイレット株式会社: Amazon Quick&nbsp;で加速させる現場の&nbsp;DX(北野涼平氏) KDDI&nbsp;グループの一員として、Amazon Quick&nbsp;の標準機能と独自のサーバーレス構成を組み合わせたデータ利活用アプローチを紹介。現場のワークフローまで見据えた設計を強みとしています。長崎ブルーエコノミー様のブリ養殖&nbsp;DX&nbsp;基盤では、IoT&nbsp;センサーデータの可視化、Bedrock&nbsp;連携による養殖場状況の言語化、画像のセキュアな組み込みを実現した事例が共有されました。 株式会社サーバーワークス:&nbsp;痒いところに手が届くサーバーワークスの&nbsp;Amazon Quick&nbsp;活用支援(村上博哉氏) Amazon Quick&nbsp;の多彩な機能から顧客のやりたいことに最適な組み合わせを提案し、すぐに使える実践的なユースケースによるジャンプスタート支援を紹介。建設業・製造業向けの入札情報の自動チェック・優先度付けや、請求書などの書類チェック業務の自動化などのユースケースに加え、初期費用無償の伴走支援キャンペーンも案内されました。 株式会社電通デジタル:&nbsp;可視化の先へ&nbsp;— Amazon Quick&nbsp;が変えるデータ分析の深さ(田中淳朗氏) 電通グループの総合デジタルファームとして、デジタルマーケティング領域で散在するデータの統合・分析を&nbsp;Amazon Quick&nbsp;で実現する支援を紹介。観光情報サイトの多言語チャットボット分析で&nbsp;Amazon Quick&nbsp;リサーチにより数十分で示唆を導出した事例を共有し、ライト・ミドル・フルコンサルの&nbsp;3&nbsp;段階の支援プランを案内されました。 株式会社&nbsp;TOKAI&nbsp;コミュニケーションズ:&nbsp;ハイブリッドクラウド活用術(山本祐也氏) 自社の専用接続回線「ブロードライン」を活用したハイブリッドクラウド構成で、オンプレミスのデータを&nbsp;FSx&nbsp;for NetApp ONTAP&nbsp;の&nbsp;S3&nbsp;アクセスポイント経由で&nbsp;Amazon Quick&nbsp;に連携するアーキテクチャを紹介。静岡・東京・大阪・名古屋・岡山の営業拠点を活かした伴走型サポートと、接続回線から運用までワンストップで対応するパッケージも案内されました。 富士ソフト株式会社: AI&nbsp;カメラと&nbsp;Amazon Quick&nbsp;で実現する新たな価値(吉田祐史氏) AI&nbsp;カメラソリューション「ビジョン&nbsp;AI&nbsp;ナビ」と&nbsp;Amazon Quick&nbsp;の連携を紹介。カメラや&nbsp;IoT&nbsp;センサーで人・設備の動きを検知し、異常検知からチャットエージェントによる対処提案、レポート自動生成、Automate/Flows&nbsp;によるフロー管理、ナレッジベースによるトラブル対応の標準化まで、検知のその先の自動化を実現する構成が示されました。 クロージング 最後に、&nbsp;AWS Japan&nbsp;Data&amp;AI&nbsp;事業統括本部&nbsp;の井形&nbsp;健太郎がクロージングを行い、東京リージョン&nbsp;GA&nbsp;の技術的意義を補足しました。 今回の&nbsp;GA&nbsp;により、Amazon Quick&nbsp;の推論処理通信が国内に閉じるようになり、企業データを生成&nbsp;AI&nbsp;で活用する際のセキュリティ・コンプライアンスが大きく向上しました。 ただし、インターネット検索機能のみ海外リージョンで処理されるため、必要に応じて機能をオフにすることが可能です。日本語サポートについては UI・チャット入力・対象データいずれも対応済みで、実用上快適にご利用いただけるレベルであると説明しました。また、生成 AI 実用化推進プログラムとして、お客様の生成 AI の利活用を加速させるための支援プログラムとして、モデルカスタマイズコースとモデル活用コースの 2 つを紹介しました。 パートナー Expo 今回ライトニングトークに参加いただいたパートナー企業5社による、それぞれの強みを活かしたAmazon Quickの活用のデモンストレーションを行いました。 アイレット:デザインからインフラまでワンストップ、現場のワークフローを見据えた一気通貫の支援 サーバーワークス:痒いところに手が届く実践的なユースケース提供と伴走支援 電通デジタル:最大規模のデジタルファームとして、データを「動かす」ための段階的支援 TOKAIコミュニケーションズ:ハイブリッドクラウドと地方企業への伴走型支援 富士ソフト:エッジとクラウドの両面から AI カメラ × Amazon Quick で現場 DX を実現 おわりに 本イベントでは、 Chat Agent や Flows をはじめとする Amazon Quick の AI Agent 機能の東京リージョンローンチ という節目に、製品の全体像から社内活用事例、お客様による実践的な導入事例、そしてパートナー企業による支援サービスまで、幅広い内容が共有されました。鉄道車両の保全 DX、化粧品企業の組織変革、CRM/SFA への組み込みなど、業種を超えた多様なユースケースが紹介され、Amazon Quick がビジネスの現場で具体的な価値を生み出しつつあることが実感できるイベントとなりました。 AWS&nbsp;ジャパンは、今後も&nbsp;Amazon Quick&nbsp;をはじめとする生成&nbsp;AI&nbsp;サービスの活用支援を通じて、お客様のビジネス変革を後押ししてまいります。 本ブログは、テクニカルアカウントマネージャーの服部洋明が担当しました。
本ブログは 株式会社スギ薬局様 とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの吉田です。 「生成 AI を業務に活用したいが、一過性の PoC で終わってしまう」「成果を組織全体に広げるにはどうすればいいか」——こうしたご相談をいただく機会が増えています。 今回ご紹介するのは、株式会社スギ薬局様の事例です。現場の業務課題と技術を組織として結びつけながら、 Amazon Bedrock を活用した年末調整 QA ボットと調剤医薬品在庫確認エージェントを構築されました。これらの成果が次の AI 活用を呼ぶサイクルが回り始め、AI 利活用が組織に根付いていく過程をご紹介いたします。 企業概要とデジタル変革への取り組み 株式会社スギ薬局様は、ドラッグストアと調剤薬局を全国に展開する企業です。近年、ドラッグストア・調剤薬局業界では、薬剤師不足や調剤・介護領域への事業拡張を背景に、経営統合や M&amp;A による規模拡大が進んでいます。スギ薬局様もグループ再編により調剤薬局が合流し、店舗数・従業員数がさらに拡大しました。 こうした事業環境の変化に対応するため、スギ薬局様は DX を積極的に推進しています。各務 CDO は、DX の方針・ビジョンについて次のように語ります。 「会社の OS をアップデートし、2030年までに AI DX を外部に提供できる武器へ進化させる」ことです。デジタル技術で効率化し、創出した「可処分時間」を人間らしい接客に再投資できるようにします。組織横断の「サービス型チーム」を核に、自律的に人が成長し続ける場作りを目指しています。 組織体制:OneSUGI PJ × CTO as a Service このビジョンを実現するため、スギ薬局様では DX・AI 推進本部のもと、業務課題の把握から技術的な解決までを組織的に推進する体制を構築しています。 OneSUGI PJ :現場の業務課題を集約・精査し、ソリューションのリリースまでを主導します。 CTO as a Service :技術アドバイザーとして、課題に対する最適なソリューションの方向性を提案します。 AI 推進部 :CTO as a Service の技術方針をもとに実装・運用を担い、OneSUGI PJ にサービスを提供します。 この体制により、現場のニーズと技術的な実現性を両輪で回せる仕組みが確立されています。 図:スギ薬局様の AI 活用推進体制 以降でご紹介する年末調整 QA ボットと調剤医薬品在庫確認エージェントは、この組織体制から生まれた具体的な AI 利活用の取り組みです。 取り組み①:年末調整 QA ボット 課題 スギ薬局様では毎年、年末調整期間中に派遣社員6〜7名をローテーションで雇用し、人事部と合わせて約10名体制で年末調整に対する社内電話問い合わせ対応を行っていました。昨今のグループ再編により対象者が約4,000人増加し、問い合わせ件数のさらなる増大が見込まれていました。 こうした状況の中、人事部から「AI による問い合わせ対応業務の効率化を、年末調整が始まるタイミングに間に合わせたい」という要請があり、約1ヶ月後までに RAG チャットボットを用意する必要がありました。まず世間で評判の高いツールを評価しましたが、既存のデータソースに対応しておらず、別の手段を検討することになりました。 解決策:Bedrock Chat による迅速な構築 既存データソースを用いた RAG を実現したいという明確な目的と、人事部側である程度ボットを管理したいというニーズがありました。そこで採用したのが、 Bedrock Chat です。 Bedrock Chat は、Amazon Bedrock を基盤とした AWS のサンプルチャットアプリケーションです。 ワンクリックで AWS 上にデプロイ でき、Web UI から RAG 用のナレッジ追加やボットのカスタマイズが可能です。人事部側でファイルの追加やボットの編集ができるため、運用負荷を最小限に抑えられる点が決め手となりました。 RAG のデータソースには年末調整 FAQ リストを使用し、社員1人が2日で環境を構築、人事部と連携して数日でリリースを実現しました。この際、スギ薬局様の運用要件に合わせたカスタマイズは、AI コーディングアシスタントの Kiro を活用して実施しました。 図:実際の年末調整 QA ボットの利用イメージ。従業員が年末調整に関する質問を入力すると、FAQ を検索する様子。 成果 年末調整 QA ボットは年末調整の期間中、約40日間の稼働で以下の成果を上げました。 定量的な成果: 指標 結果 問い合わせ処理件数 期間を通して約2万件 人事工数の削減 1件10分換算で3,000時間以上 入電率の変化 1.21% → 1.08%(対象者が約4,000人増加したにもかかわらず低下) 電話対応体制 昨年と同じ約10名体制で問題なく対応 コスト SaaS 製品では1,200万円かかる想定だったところを、AWS のマネージドサービスを活用して社員1人が2日で構築し運用費は約10万円程度に収まった 定性的な成果: 年末調整 QA ボットは現場から好評を得ました。ボットのクローズ後には、人事全般の問い合わせサポートツールとしての利活用検討が開始されたほか、他部門からも問い合わせ対応に AI エージェントを活用したいという要望が上がるようになりました。 また、年末調整シーズンの終了後には本ボットのリソースを削除しています。必要な時に立ち上げ、不要になれば停止できるクラウドの従量課金モデルを活かし、迅速かつコストを最小限に抑えた運用を実現しました。4万人を超える従業員が利用対象となる一方、一人あたりの利用頻度は限定的です。こうした利用パターンには、ユーザ単位で課金される完成型のサービスよりも、Amazon Bedrock のトークン単位の課金をはじめとする AWS の従量課金モデルがマッチしていました。 今回構築した環境は役目を終えましたが、「AI でここまでできる」という体験が社内に広まり、次の取り組みを加速させることになります。 取り組み②:調剤医薬品在庫確認エージェント 課題 年末調整 QA ボットの好評も追い風に、OneSUGI PJ への次の AI 活用案件として調剤医薬品在庫確認エージェントが舞い込みました。 調剤薬局のグループ統合直後、在庫管理システムは会社間で統合されておらず、調剤薬局の薬剤師が近くのスギ薬局店舗に電話をかけて在庫を確認していました。電話がつながれば数分で済む作業ですが、実際には「相手が忙しくて対応できない」「忙しいだろうから遠慮して電話しづらい」という心理的な課題を抱えていました。 薬剤には使用期限があるため過剰に在庫を置くことはできず、普段の消費ペースにない薬剤は欠品になりやすい状況です。患者様に必要なお薬をお渡しできなければ、他の薬局に足を運んでいただくことになり、患者様への負担は大きくなります。 解決策:基幹システムデータを活用した AI エージェント まず年末調整 QA ボット同様 Amazon Bedrock による RAG を検討しましたが、構造化された在庫データに対しては毎回結果が異なり、期待する回答を得られなかったため、別のアプローチを模索しました。 最終的に採用したのは、Text2SQL のアプローチです。エージェントフレームワークには Amazon Bedrock Agents を選びました。フルマネージドで運用負荷が低く、モデル呼び出しと Lambda の実行費用のみで済むため、限られた時間の中でツール開発という本質的な価値提供にフォーカスできる点が決め手となりました。自然言語の問い合わせを SQL に変換し、データウェアハウスである Amazon Redshift に集約された在庫データを検索する構成としました。 図:調剤医薬品在庫確認エージェントのシステム構成 この構成の肝は、基幹システムに蓄積されたエンタープライズデータ(在庫データ・店舗マスタ・医療薬品マスタ)を AI エージェントから直接活用できることです。AWS 上にデータ基盤と AI 基盤が共存しているからこそ、お客様ご自身で迅速かつ手軽にデータ活用を実現することができました。なお、データへのアクセス制御については、全店舗共通で参照可能なカラムのみを対象とし、Lambda 関数の中でアクセス範囲を制限する設計としています。 Text2SQL の精度は、LLM の性能だけでは決まりません。既存のデータマートスキーマの正確な理解、業務用語のプロンプトでの伝え方、生成された SQL の評価方法——これらを短いサイクルで試行錯誤しながら求める回答精度へとチューニングしていくことが重要でした。また、短期間で評価・改善を繰り返すために、近隣店舗の検索には Amazon Location Service を活用し、フロントエンドには年末調整 QA ボットでも利用した Bedrock Chat の Agent 連携機能 を用いて迅速に構築しています。 図:実際の在庫確認エージェントの利用イメージ。薬剤師が店舗名と薬品名を入力すると、対象店舗および近隣店舗の在庫数と位置関係が返されます。 成果 約1ヶ月で構築し、200店舗に公開。2026年4月初旬から本番展開を開始しています。 現場では AI エージェントに対する抵抗感はなく、年配の方もスムーズに問い合わせができています。 最も大きな変化は、業務フローそのものの転換です。 Before After 在庫確認の方法 近くの店舗に電話 AI エージェントに問い合わせ 心理的な障壁 「忙しいだろうから遠慮して電話しづらい」 自分のタイミングで気兼ねなく検索 情報の範囲 電話した1店舗の情報のみ 近隣店舗の在庫と距離を一覧で把握 お客様の声 各務様コメント(取締役 / DX・AI推進本部長 兼 CDO): 今後も AI の本質を理解し、そこに対応をできる組織力が勝負になると考えています。何故ならばその組織力は1日ではできないためです。AI がその組織力強化にも一役買ってくれると考えており、その視点で使い倒していく予定です。 有路様コメント(DX・AI推進本部 AI推進部 課長): 技術選定では、世の中の事例にある製品を実際に利用して比較しました。その結果、AWS が最も精度が高く、導入とランニングコストが一番安いと判断しました。日々アップデートがある中で安定して業務に利用するには苦労もありますが、評価の結果安定していると判断したら導入メリットは高いので、今後も積極的に試行錯誤して業務改善へと活用していきたいと思っています。 高階様コメント(DX・AI推進本部 OneSUGI PJ リーダー): AI を特別なものではなく、店舗や本部の日常業務に溶け込む当たり前のツールとして浸透させることを重視しています。現場起点での活用と小さな成功体験の積み重ねを通じて、主体的に AI を使いこなす文化の醸成を進めています。今後も現場に寄り添いながら、変革を着実に推進していきます。 今後の展望 スギ薬局様では、在庫確認エージェントを調剤薬局の全店舗に展開し、現場からのフィードバックをもとに改善を進めていく予定です。 また、数年後には数百の AI エージェントを本部メンバが自ら構築できるようになることをゴールとしています。その基盤として Amazon Bedrock AgentCore の活用も検討いただいています。 まとめ 今回は、スギ薬局様が組織横断のチームで現場業務課題と技術を結びつけ、Amazon Bedrock を活用して年末調整 QA ボットと調剤医薬品在庫確認エージェントを構築した事例をご紹介しました。 特に注目すべきは、以下のサイクルが組織として回っている点です。 組織体制の確立 :業務課題と技術をつなぐ体制を整備する 現場課題の集約 :OneSUGI PJ が現場の声を拾い上げる 技術による迅速な解決 :CTO as a Service が最適なソリューションを短期間で選定する 成果が次の取り組みを加速 :成功体験が社内に広まり、新たな AI 活用の要望につながる AI 活用を成功させるには、技術だけでなく、業務課題と技術をつなぐ組織体制が鍵です。スギ薬局様の取り組みは、AI を組織に根付かせたいと考えている多くの企業にとって、参考になる事例ではないでしょうか。 AI 活用推進の体制づくりを含め、生成 AI の業務利用や、業務データを活用した AI エージェントの構築にご興味・ご関心のあるお客様は、ぜひ AWS までお気軽にご相談ください。 著者 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。
本記事は「 Planview saves 40+ hours per audit cycle by automating SOC 2 compliance with Kiro CLI 」を翻訳したものです。 コンプライアンス管理は、時に圧倒的な負担に感じることがあります。多くのエンジニアリングチームにとって、継続的に大きな注意を払い続ける必要がある業務です。チームは年間サイクルごとに 40 時間以上をかけてエビデンスを収集し、クラウドプロバイダーのコンソールを操作し、監査期限が迫る中でスプレッドシートを作成しています。 戦略的ポートフォリオ管理のリーダーとして世界中で 3,000 社以上の顧客にサービスを提供する Planview も、同じ課題に直面していました。マルチサービスの AWS インフラストラクチャ全体で SOC 2 コンプライアンスを維持するために、顧客向けの機能開発に充てるべきエンジニアリング時間が消費されていたのです。ここでは、Planview が Kiro CLI を使ってコンプライアンスワークフローをどのように変革し、コンプライアンスサイクルあたり 40 時間以上を削減したかをご紹介します。 コンプライアンスは大変 Kiro 導入前の Planview のコンプライアンス管理は、以下のような状況でした。 エンジニアが手動でエビデンスを収集 — 20 以上のクラウドサービスにまたがり、コンソールや API からデータを取得していました。 チームがスプレッドシートの発掘作業を実施 — セキュリティコントロール、タイムスタンプ、監査証跡を追跡していました。 監査準備サイクルに 40 時間以上を消費 — エンジニアをプロダクト開発から引き離していました。 複数のチームメンバーにまたがる調整オーバーヘッド — クラウドプロバイダーと SOC 2 要件の両方に精通した専門知識が必要でした。 クラウドコンプライアンスを管理する多くのエンジニアリングチームが、同様の課題に直面しています。監査に費やす時間、コンテキストスイッチ、手動エラーの可能性、四半期サイクルの計画が、コストを複合的に増大させています。 コンプライアンスへの新しいアプローチ Planview は、また別のコンプライアンスダッシュボードを構築するのではなく、異なるアプローチを選びました。Kiro CLI を使って、コンプライアンスの自動化を開発ワークフローに直接組み込んだのです。 当初、Planview の SOC 2 コンプライアンスプロセスは完全に手動で、セキュリティチームとエンジニアリングチームに多大な時間とリソースを要していました。コンプライアンスワークストリームの効率化のため、チームは 2025 年第 1 四半期に商用の継続的コンプライアンスプラットフォームを評価しました。Planview は長期的には継続的コンプライアンス機能の導入を計画していますが、フル商用プラットフォームのオーバーヘッドなしに迅速に価値を提供できる暫定的なソリューションが必要でした。このニーズに Kiro は最適でした。Kiro は Planview の既存ワークフローに直接統合され、フルコンプライアンスプラットフォームへの移行の道を閉ざすことなく、すぐに自動化のメリットを提供しました。 Kiro CLI でカスタムコンプライアンスエージェントを作成する Planview は、Kiro CLI の組み込み aws ツールとカスタムエージェント機能を使用して、クラウドサービスへのきめ細かな読み取りアクセスを設定しました。Kiro のカスタムエージェントを使うと、ユースケースに合わせた特定のコンテキストとツール権限を持つ、目的特化型の AI アシスタントを作成できます。Planview の場合、SOC 2 コンプライアンスワークフローに関連する技術的エビデンスを取得するために、クラウドサービスへの事前承認済みの読み取り専用アクセスを持つエージェントを作成しました。事前承認とは、エージェントが各読み取り操作に対して手動の承認を必要としないことを意味します。これにより、監査サイクルやエビデンス収集タスクごとに手動で権限を付与する必要がなくなり、以前は 40 時間以上かかっていた手動プロセスが自動化されたワークフローに変わりました。この統合は読み取り専用の非侵襲的なアクセスで動作するため、インフラストラクチャのセキュリティは確保され、変更されることはありません。これはコンプライアンスに限った話ではありません。例えば、CloudWatch メトリクス、S3 バケット設定、Lambda 関数ログをクエリするインフラストラクチャ監視用のカスタムエージェントを作成し、AWS サービスへの事前承認済み読み取りアクセスを付与して、運用ヘルスレポートを自動生成することもできます。 カスタムエージェントの作成方法 と 設定例 をご覧ください。 以下の例は、 ~/.kiro/agents/soc2-compliance.json に保存するカスタム soc2-compliance エージェント JSON の参考例です。これを SOC 2 コンプライアンスプロセスを支援するアシスタントとして活用でき、CLI で kiro-cli --agent soc2-compliance (またはカスタムエージェント名)を使って起動できます。 { "name": "soc2-compliance", "description": "セキュリティコントロール、監査準備、ポリシー適用のための SOC 2 コンプライアンスアシスタント", "prompt": "file://./prompts/soc2-expert.md", "tools": [ "read", "write", "aws" ], "allowedTools": [ "read" ], "toolsSettings": { "write": { "allowedPaths": [ "docs/compliance/**", "policies/**", "audit/**", "security/**" ] }, "aws": { "allowedServices": [ "iam", "cloudtrail", "config", "guardduty", "securityhub", "inspector", "kms", "s3" ], "autoAllowReadonly": true } }, "resources": [ "file://policies/**/*.md", "file://docs/compliance/**/*.md", "file://audit/**/*.json", "file://security/controls/**/*.yaml" ] } この JSON は、セキュリティコントロール、監査準備、ポリシー適用を支援するために設計された特化型エージェント設定を定義しています。各セクションの意味は以下の通りです。 name — エージェントの識別子/名前 description — エージェントの目的を説明する人間が読める説明文(SOC 2 コンプライアンス業務) prompt — エージェントのシステム指示/動作を含むマークダウンファイルへのパス( ./prompts/soc2-expert.md ) tools — エージェントがアクセスできるツール: read(組み込みツール)— ファイル/ディレクトリの読み取り write(組み込みツール)— ファイルの作成/変更 aws(組み込みツール)— AWS CLI 呼び出し allowedTools — ユーザー承認を必要としないツール(ここでは read のみ自動承認。write と aws は確認が必要) toolsSettings — 各ツールのきめ細かな権限設定: write.allowedPaths — エージェントが書き込みできるディレクトリを限定(コンプライアンスドキュメント、ポリシー、監査ファイル、セキュリティファイル) aws.allowedServices — エージェントが操作できる AWS サービスを限定(IAM、CloudTrail、Config、GuardDuty、SecurityHub、Inspector、KMS、S3 — すべてセキュリティ/コンプライアンス関連) aws.autoAllowReadonly — 読み取り専用の AWS 操作(describe-*、list-*、get-* など)は承認不要 resources — エージェント起動時に自動的にコンテキストに読み込まれるファイル: ポリシーのマークダウンファイル コンプライアンスドキュメント 監査 JSON ファイル セキュリティコントロール YAML ファイル あるいは、エージェント設定 JSON を手動で作成する代わりに、Kiro CLI の /help エージェントを使用できます。これは、自然言語の説明からスマートなエージェント設定の推奨を生成する組み込みアシスタントです。Kiro CLI 内で /help Help me create a custom agent for soc-2 compliance を実行すると、Kiro が SOC 2 コンプライアンスを支援するための初期ドラフトを自動的に生成します。 /help Help me create a custom agent for soc-2 compliance を実行すると、以下のことが起こります。 Kiro は組み込みの /help エージェントに切り替わります。これは Kiro CLI に関する質問に答え、設定を生成するために特化されたエージェントです。 /help エージェントは Kiro の内部ドキュメントを参照して正しいエージェント設定スキーマを検索し、生成される設定が有効なフィールドを使用し、ベストプラクティスに従っていることを確認します。 /help エージェントは、ツール、権限、リソースパターン、カスタマイズされたシステムプロンプトを含む推奨設定を、手動の JSON 作成なしに生成します。必要に応じてこれを調整できます。 Kiro CLI でカスタムエージェントを使用する 開発者がターミナルで kiro-cli --tui --agent soc2-compliance を使ってこのカスタムエージェントを起動すると、チャットセッション開始時に「aws」ツールの allowedServices、resources、allowed paths のコンテキストと権限が読み込まれます。 --tui フラグを使用すると、Kiro CLI の新しい UX が読み込まれます。通常の kiro-cli ターミナル体験を使用したい場合は、 kiro-cli --classic --agent soc2-compliance を使用するか、Kiro ターミナル内で /agent soc2-compliance を使用できます。 プロンプト例: 「すべての S3 バケットの暗号化ステータス、パブリックアクセス設定、アクセスログ設定を示す SOC 2 CC6.1 コンプライアンスレポートを生成してください。」 Kiro の機能を活用して、Planview は SOC 2 および ISO エビデンスのタイムスタンプ収集を簡素化しました。システムがタイムスタンプ付きの情報を取得できるようになり、Kiro は以下を自動的に実行できるようになりました。 すべてのリージョンにわたる S3 設定のクエリ、または同じ結果を生成するクエリの実行を支援するスクリプトの作成 暗号化設定とキー管理の確認 アクセスコントロールリストとバケットポリシーの検証 タイムスタンプ付きのフォーマットされたコンプライアンスエビデンスの生成 エージェントが複雑さを処理し、チームは必要なエビデンスを取得できます。 注意: AI が生成するコンプライアンス出力は、エージェントに提供されるプロンプトの具体性と範囲に大きく依存します。これは監査プロセスを加速するためのツールであり、決定論的なコンプライアンスツールの代替となるものではありません。AI が生成したすべての推奨事項、ポリシーテキスト、監査エビデンスは、本番環境での使用や監査人への提出前に、資格のあるコンプライアンス専門家によるレビューと検証を受ける必要があります。 成果 以前は手動でのデータ収集が必要だった作業が、自動的に行われるようになりました。Kiro はタイムスタンプ付きのコンプライアンスエビデンスを取得し、上記の AWS 許可サービスを使用してセキュリティスキャンを実施し、特定の SOC 2 および ISO コントロール要件に沿ったアーティファクトを整理します。 このワークフローは、開発環境の変更を必要とせずに Planview の既存プロセスに統合されます。以前は手動だったエビデンス収集が、Kiro CLI の組み込みツールを通じて実行され、フィードバック用の対話型インターフェースが提供されます。Planview チームは、すぐに大きく測定可能な効果を実感しました。 コンプライアンスサイクルあたり 40 時間以上を削減 — 節約された時間は、エビデンス収集ではなく顧客価値の構築に活用されています。 自動化による全体的な効率 60% 向上 — チームは監査リクエストに 3〜4 倍速く対応できるようになりました。 チームメンバーあたり 1〜1.5 SDE スプリント分の時間を節約 — 機能開発や改善に振り向けられています。 オンデマンドのエビデンス収集 — 特定の時間を確保するのではなく、年間を通じて監査に備えることができます。 しかし、本当の成果は、エンジニアリングリソースが本来あるべき場所に戻ったことです。スプレッドシートの作成ではなく、プロダクトの構築に集中できるようになりました。 まとめ Planview のアプローチは、コンプライアンス業務が負担である必要はないことを示しています。コンプライアンス要件を仕様として提供し、AI を開発ワークフローに直接組み込むことができます。 カスタムエージェント のような機能は、セキュリティ基準を維持しながら、チームが顧客への価値提供に集中できるよう支援します。 Planview は、コンプライアンス管理以外のユースケースにも Kiro CLI のカスタムエージェントの活用を拡大しています。これにより、組織全体のより多くの開発者が再現可能なワークフローを使用し、効率化の効果を倍増させることができます。 Kiro CLI を 今すぐ 始めましょう。
前回の Week in Review に、2026 年、お客様との AI-Driven Development Lifecycle (AI-DLC) ワークショップに多くの時間を費やしたことを書きました。これらのセッションに共通するテーマは、コストの可視性を高める必要があるということです。チームは AI の導入を急速に進めていますが、実験段階から本番環境に移行するにつれ、財務部門と経営陣は、誰がどのリソースをどの程度のコストで使用しているかを把握する必要があります。だからこそ 2026 年 4 月 13 日週、 Amazon Bedrock による IAM ユーザーとロール別のコスト配分のサポートの開始 を知って、とてもワクワクしました。これにより、IAM プリンシパルにチームやコストセンターなどの属性をタグ付けし、それらのタグを請求およびコスト管理コンソールでアクティブにすることができます。結果のコストデータは AWS Cost Explorer と詳細なコストと使用状況レポートに送信されるため、モデル推論の支出を明確に把握できます。チーム間でエージェントをスケールする場合でも、部門ごとに基盤モデルの使用状況を追跡する場合でも、 Claude Code on Amazon Bedrock のようなツールを実行する場合でも、この新機能は AI 投資の追跡と管理に大きな変革をもたらします。この設定に関する詳細は、 IAM プリンシパルコスト配分ドキュメント に記載されています。 それでは、2026 年 4 月 13 日週の AWS ニュースを見ていきましょう。 ヘッドライン Amazon Bedrock が Claude Mythos Preview の提供を開始 これまでで最も洗練された Anthropic の AI モデルを、Project Glasswing を通じてゲート付きリサーチプレビューとして Amazon Bedrock で利用できるようになりました。Claude Mythos は、サイバーセキュリティに焦点を当てた新しいモデルクラスを提供します。これにより、ソフトウェアの高度なセキュリティ脆弱性を特定し、大規模なコードベースを分析して、サイバーセキュリティ、コーディング、複雑な推論タスク全体で最先端のパフォーマンスを実現できます。セキュリティチームはこれを利用して、脅威が出現する前に重要なソフトウェアの脆弱性を発見して対処することが可能になります。現在、アクセスは許可リストに登録されている組織に限定されており、Anthropic と AWS はインターネットクリティカルな企業やオープンソースのメンテナーを優先しています。 エージェントの検出とガバナンスを一元化するための AWS Agent Registry (現在プレビュー中) AWS は Amazon Bedrock AgentCore を通じて Agent Registry を立ち上げました。AI エージェント、ツール、スキル、MCP サーバー、カスタムリソースを発見して管理するためのプライベートカタログを組織に提供しています。レジストリは、セマンティック検索、キーワード検索、承認ワークフロー、CloudTrail 監査証跡により、チームが既存の機能を重複することなく見つけるのを支援します。AgentCore Console、AWS CLI、SDK からアクセスできます。また、IDE からクエリ可能な MCP サーバーとしてアクセスすることも可能です。 2026 年 4 月 6 日週のリリース 2026 年 4 月 6 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 S3 バケットをファイルシステムとしてアクセス可能にする Amazon S3 Files の発表 – Amazon S3 Files は S3 バケットを、任意の AWS コンピューティングリソースと S3 データを直接接続する共有ファイルシステムに変換します。Amazon EFS テクノロジーに基づいて構築されているため、低レイテンシーのパフォーマンスで完全なファイルシステムセマンティクスを提供し、使用頻度の高いデータをキャッシュして、1 秒あたり数テラバイトの総読み取りスループットを実現します。アプリケーションは、コードを変更したりデータを移行したりすることなく、ファイルシステムと S3 API の両方から同時に S3 データにアクセスできます。 Amazon OpenSearch Service が Managed Prometheus とエージェントトレースのサポートを開始 – Amazon OpenSearch Service は、メトリクス、ログ、トレース、AI エージェントトレースを 1 つのインターフェイスに統合した、統合型オブザーバビリティプラットフォームの提供を開始しました。このアップデートには、Prometheus のネイティブ統合と PromQLクエリの直接サポート、RED メトリクスのモニタリング、LLM 実行の可視化を実現する OpenTelemetry GenAI セマンティック規約サポートが含まれています。運用チームはツールを切り替えることなく、スロートレースをログに関連付け、ダッシュボードに Prometheus メトリクスをオーバーレイすることができます。 Amazon WorkSpaces Advisor が AI を活用したトラブルシューティングで利用可能に – AWS は Amazon WorkSpaces Advisor を立ち上げました。これは、生成 AI を使用して IT 管理者が Amazon WorkSpaces パーソナルデプロイのトラブルシューティングを行うのに役立つ、AI を活用した管理ツールです。WorkSpace の設定を分析し、問題を自動的に検出して、サービスの復旧とパフォーマンスの最適化に役立つ推奨事項を提示します。 Amazon Braket が Rigetti の 108 量子ビット Cepheus QPU のサポートを追加 – AmazonBraket は、プラットフォーム上の最初の 100 量子ビット以上の超伝導量子プロセッサである Rigetti の Cepheus-1-108Q デバイスへのアクセス提供を開始しました。モジュラー設計は、位相誤差に対する耐性が強化された CZ ゲートを備えた、12 個の 9 量子ビットチップレットを備えています。Braket SDK、Qiskit、CUDA-Q、Pennylane などの複数のフレームワークをサポートしており、研究者向けのパルスレベル制御も可能です。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Amazo S3を使用した自動 AWS リージョン可用性チェックの構築 – Amazon S3をコアインフラストラクチャとして使用し、AWS リージョン全体でサービスの可用性を監視する自動化システムの実装に関するストレージブログ記事です。 Amazon Bedrock モデルのライフサイクルの理解 – 機械学習のブログ記事では、Bedrock の基盤モデルが入手可能になったり廃止されたりするまでの段階について説明しています。これは、チームがモデルのアップデートを計画したり、本番環境でのバージョン依存関係を管理したりするのに役立ちます。 AWS Lambda Managed Instances を使用したメモリ集約型アプリの構築 – コンピューティングのブログ記事では、Lambda マネージドインスタンスがプラットフォームを軽量ワークロード以上に拡張し、サーバーレスのメリットを維持しながらメモリを大量に消費するアプリケーションをサポートする方法について説明しています。 OpenClaw を AWS でデプロイ: お客様の AI ワークロードに適したオプションを選択 – Builder Center ガイドでは、OpenClaw の 4 つの AWS デプロイオプションを比較しています。4 つのオプションとは、個々のデベロッパー向けの Amazon Lightsail、より深い AWS 統合を必要とするスタートアップ向けの Amazon EC2、サーバーレスのマルチユーザーシナリオ向けの Amazon Bedrock AgentCore、VM レベルの分離と高度なオーケストレーションを必要とするエンタープライズ向けの Amazon EKS です。 Kiro スタートアップクレジットプログラム復活のお知らせ – Kiro はスタートアップクレジットの取り組みを再開します。対象となる初期段階の企業は、Kiro Pro+ を最大 1 年間無料で利用できるようになります。3 段階のプログラム (Starter、Growth、Scale) は、チームの規模に応じて 2〜30人のユーザーを対象としています。また、ローリングアプリケーションは世界中で受け付けています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS の次のイベント (4 月 28 日、バーチャル) 午前 9 時 (太平洋標準時) に配信されるこのライブストリームに参加して、エージェンティック AI がビジネスの運営方法をどのように変えているかについて率直に議論しましょう。AWS CEO の Matt Garman、SVP の Colleen Aubrey、OpenAI のリーダーが、新しいエージェント機能、Amazon 社内での経験、新しいエージェンティックソリューションとプラットフォーム機能について語ります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 4 月 13 日週のニュースは以上です。2026 年 4 月 27 日週にお届けする次回の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。
AI の業務活用が広がる中、多くの企業が次の課題に向き合っています。個別の AI 活用は始まっているものの、組織全体として推進する仕組みが追いついていない。「何から手をつけるべきか」が見えにくい ― そんな声は少なくありません。 パナソニック エレクトリックワークス株式会社 (以下、同社)も、こうした課題意識のもとで動き出した企業の一つです。同社は、電気設備を起点に、Well-Being や Energy Management などの新たな価値を創出し、持続可能な豊かな社会づくりに挑戦しています。その中で、ソフトウェア開発領域での AI 活用も積極的に推進してきました。 2026 年 4 月、同社はAI・クラウド開発センター(以下、AICDC )を新設しました。AICDC は「AI 技術活用によるソフトウェア開発に変革を起こし、ソリューション事業を加速する」をミッションに掲げ、活動を開始しています。本記事では、AICDC の立ち上げに向けて同社が取り組んだ AI 駆動開発ライフサイクルの実践 ( AI-DLC Unicorn Gym ) と AI 成熟度診断 ( AI Foundation Pack ) について、その内容と得られた気づきをご紹介します。 AI 駆動開発ライフサイクルの実践 ― AI-DLC Unicorn Gym AICDC の立ち上げに向けて、同社は新組織に必要な準備を多面的に進めました。その一つとして、2026 年 1 月に AWS と連携して、 AI 駆動開発ライフサイクル(以下、 AI-DLC )を組織的に実践するワークショップ型プログラム「AI-DLC Unicorn Gym」を実施しました。AI-DLC は、AI を開発プロセスの中心に据え、企画から実装までをチーム全員で協働しながら高速に進める開発手法です。同社の企画と開発から計35 名が参加し、4 つのチームが実際のプロダクトや新規サービスに関する課題をテーマに取り組みました。実質 2.5 日という限られた時間の中で、全チームが動作するシステムの初期版を完成させています。 参加した企画部門と開発部門の組織責任者からは、こんな声が聞かれました。 「古来から企画と設計は異なる人種で何かと衝突が起こり、折り合いがつかない場面を数多く目の当たりにしてきました。しかしこの 3 日間で、それが解消する第一歩になったと感じています」 「エンジニアが高度なレベルを要求されることを体感し、仕事の基本に立ち返れたのではないでしょうか。今日が始まりだと思って引き続きやっていきましょう」 AI-DLC の実践を通じて見えてきたのは、AI が開発の中心になることでエンジニアにはより高い技術的判断が求められるようになること、そして企画と開発が一体となってチーム全体で価値を生み出す働き方が可能になるということです。同社にとって、AI 活用がもたらす開発プロセスの変化を実感する機会となりました。 Unicorn Gymの様子 (AI-DLC の詳細については、 こちらの Blog をご参照ください。) AI 成熟度診断の実践 – AI Foundation Pack もう一つの取り組みとして、同社は 2026 年 3 月に AI Foundation Pack を実施しました。これは、AWS Cloud Adoption Framework for AI(以下、CAF-AI)に基づく成熟度アセスメントを中心とした AWS の Professional Services が提供するプログラムで、今回が日本で初めての実施となりました。同社が、ビジネス目標の一つとして掲げる顧客新価値創造の達成に向けて、ソフトウェア開発領域に焦点を当てて実施しています。 CAF-AI は、プラットフォーム、セキュリティ、オペレーションといった技術面に加え、ビジネス、ピープル、ガバナンスといった非技術面も含む 6 つのパースペクティブから、AI 活用に必要な組織能力を体系的に評価するフレームワークです。 CAF-AIの概念図(CAF-AI の詳細については、 こちらの Blog をご参照ください。) AI Foundation Pack は 2 日間のプログラムとして実施されました。当日の議論を円滑に進めるため、AICDC の部課長等が 6 つのパースペクティブに沿ったアセスメントシートに事前回答しています。 Day 1 では、新組織である AICDC のセンター長、各部長、課長クラスのメンバーや、関連する部門である R&amp;D 、IT の部門メンバーなどのステークホルダーが一同に会し、ワークショップ形式でアセスメントを実施しました。普段は個別に業務を進めている関係者が、AI 活用の現状と課題、目指す姿について同じテーブルで対話することが、新組織の土台となる目線合わせの場となりました。 Day 2 では、アセスメント結果をもとに AWS から施策の方向性とロードマップ案を提示し、参加者全員で優先度を議論しました。 アセスメントで見えたこと Day1 のアセスメントの結果、同組織の AI 活用は初期段階にあることが確認されました。ただし、これは同組織に限った話ではありません。AWS がグローバルで約 100 社に実施してきたアセスメントにおいても、多くの企業が同様の段階からスタートしています。重要なのはスコアそのものではなく、現在地を把握した上で目指す姿とのギャップを特定し、取り組みの優先順位付けに活用していくことです。また、定期的にアセスメントを実施することで、取り組みの進捗を定量的に把握し、必要に応じて施策の見直しに活かすこともできます。 アセスメントを通じて、同組織の現状が 6 つのパースペクティブで構造的に整理されました。パナソニックグループとして AI に関する規定や方針は示されており、今後の取り組みの方向性を支える土台となっています。一方で、AI 活用における戦略や推進体制、現場で運用できる粒度のガイドライン、人材の役割定義など、組織横断で取り組むべき領域が明確になりました。 優先実施事項を議論する Day 2 のワークショップでは、アセスメント結果をもとに参加者全員で優先度マッピングワークを実施しました。ビジネス目標への貢献度と実現性の 2 軸で各テーマをマッピングし、「最初の 3〜6 ヶ月で何に取り組むべきか」を議論しました。 この議論の中で、特に優先度が高いテーマとして位置づけられたのが、AI 活用戦略の策定と推進体制の構築でした。まず戦略を定め、それを推進する体制を整えることが、他の施策を進める上での土台になるという認識が共有されました。加えて、人材育成において既存の組織体制の中に AI スキルを組み込んでいく方向性や、AI 活用に伴うガバナンスやセキュリティの整備も重要な論点となりました。 AWS からは他社の事例も紹介され、AI CoE の立ち上げからユースケース展開までの時間軸や、共通する進め方のパターンが共有されました。自社だけでは見えにくい課題の優先度や取り組みの時間軸の目安を得られたことで、より現実的な計画策定に繋がります。 この 2 日間を通じて、まず AI 活用戦略の策定から着手し推進体制を構築していくことが、次のアクションとして明確になりました。 これからの AI・クラウド開発センター ― 益子部長インタビュー 2026 年 4 月に新設された AICDC で、クラウドソリューション開発と AI 活用推進を担当する益子部長にお話を伺いました。 ― AI Foundation Pack では、ステークホルダーが一同に会してアセスメントと優先度の議論を行いました。この 2 日間を通じて、特に価値を感じた点はどこでしたか? 価値を感じたのは、AI 活用の目指す姿とレベル感を関係者全員で共有できたことです。 もし AI Foundation Pack がなかったら、AI 駆動開発の標準化と育成しかやっていなかったかもしれません。中期計画に書かれた項目を、各自が重要だと思うものから個別に進めるだけの状態が続いていたと思います。今回、CAF-AI のフレームワークを使うことで、AI 活用に必要な能力や体制、目指す姿、活用レベルを関係者全員で認識合わせできました。また、プログラムの事前準備を通じて、新組織が担うべきミッションの範囲を社内関係者とすり合わせられたことも良かったです。Day 2 では優先度を議論し、まず小さく PoC から始めて標準化へと進むステップを合意できました。自分たちのレベルに合った進め方を、センター長を含めた全員で議論して決められたことに、大きな意味があったと思っています。 ― AICDC が始動しました。今後の取り組みへの思いと、AWS への期待をお聞かせください。 AI やデータをしっかりと使いこなせる組織にしていきたいです。そのために、AWS には引き続き伴走していただきたいと思っています。アカウントチームや Professional Services のメンバーに伴走していただくことで、課題や取り組みに対する支援はもちろん、第三者視点でのレビューや助言をいただけることが大きなメリットだと感じています。アカウントチームとの接点を多く持てており、当社への理解が深まっていると感じているからこそ、今後も当社のビジネスの背景や課題、AICDC のミッションを理解した上での提案を期待しています。 また、グローバルで活動されている AWS だからこそ知っている最先端の知見を共有いただき、私たちもキャッチアップしていきたいです。サービス面でも、業務がより楽に、より安全に進められるものをこれからもどんどん出していってほしいと思っています。 後列 左から2人目より… AICDC 益子氏、向井氏、川本氏 まとめ AI 活用をビジネス成果に繋げていくためには、個別のツール導入や PoC だけでは十分ではありません。AI 活用における戦略と目標を策定し、経営陣を含めた関係者間で合意して進めていくこと。そのためにまず、自社の現在地を客観的に把握し、「何から始めるか」を議論することが重要なステップになります。同社の取り組みが、同じ課題に向き合う企業の皆様にとって何かの参考になれば幸いです。 AICDC(AI・クラウド開発センター)の挑戦はまだ始まったばかりです。AWS は、AI-DLC による開発プロセスの変革支援、AI Foundation Pack による成熟度アセスメントと戦略策定の伴走、そして様々な Coding Agent の活用支援を通じて、パナソニック エレクトリックワークス社の AI ネイティブなエンジニア組織への変革をこれからも共に歩んでまいります。 パナソニック エレクトリックワークス株式会社の企業ページは こちら 著者について &nbsp; 佐山 朝葉 (Sayama Asaha) ソリューションアーキテクト 製造業のお客様をご支援しています