みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2025 年 11 月 21 日に、株式会社LangGenius、株式会社リコー、アマゾンウェブサービスジャパン合同会社が登壇する「 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」のイベントが開催されます。Dify Enterprise の新機能紹介、機密性の高いデータを保有する企業システムと Dify の安全な連携手法、Dify 導入パートナーによる事例紹介を通じて、エンタープライズでの安全かつ効果的な生成 AI 活用の知見を提供します。物理開催のため、事前にお申し込みの上、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月6日週の主要なアップデート 10/6(月) 新しいコンピュート最適化 Amazon EC2 C8i および C8i-flex インスタンス AWS が新しいコンピュート最適化インスタンス C8i と C8i-flex の一般提供を開始しました。カスタム Intel Xeon 6 プロセッサを搭載し、従来の Intel ベースインスタンスと比較して最大 15% のコスト削減と 2.5 倍のメモリ帯域幅を実現します。Web アプリケーションでは最大 60%、AI 推論では最大 40% の性能向上を達成します。C8i-flex は Web サーバーやデータベース向けで、料金が少し安価で採用しやすいタイプです。C8i は、CPU 負荷の高いシステム向けのインスタンスタイプです。バージニア北部、オハイオ、オレゴン、スペインリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon EKS と Amazon EKS Distro が Kubernetes バージョン 1.34 をサポート開始 Amazon EKS と Amazon EKS Distro で Kubernetes version 1.34 のサポートが開始されました。Kubernetes 1.34 のアップデートの内容を一部取り上げると、コンテナイメージを取得する時のセキュリティが強化され、従来よりも安全にイメージの認証を行えるようになりました。また Pod 内の複数コンテナのリソース管理が簡素化され、より効率的なリソース配分が可能になります。既存クラスターは EKS コンソールや eksctl を使って簡単にアップグレード可能で、全ての AWS リージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 10/7(火) AWS Service Quotas の自動 Quota 管理が一般提供開始 AWS Service Quotas で自動クォータ管理機能が一般提供開始となりました。AWS Service Quotas は各サービスの利用上限 (Quota) を一元管理するサービスです。新しいアップデートで、Quota 使用量を監視し、上限に近づくと事前に自動通知を受け取れるようになります。これまでは Quota 超過でサービスが停止するリスクがありましたが、事前通知により計画的な対応が可能です。通知は email や SMS、Slack などで受け取れます。 AWS Marketplace が Channel Partner Private Offers の日本消費税サポートを拡張 AWS Marketplace で日本の消費税サポートが拡張され、Channel Partner Private Offers (CPPO) にも対応しました。これまで、日本に住所を持つ ISV 会社 (SaaS 系) や Channel Partner が、日本のお客様に販売する場合、AWS Japan が 10% の消費税を徴収して、日本の税務当局に送金をしています。今回のアップデートで、Channel Partner Private Offers (CPPO) の取引においても、日本の消費税のサポートが拡大されました。CPPO とは、AWS パートナーが、AWS Marketplace に出品されている ISV製品・SaaS製品を、各ベンダーに代わって販売することができるプログラムです。詳細は こちらの FAQ をご参照ください。 AWS Marketplace が使用量ベースのプライベートオファーで新しい通貨をサポート AWS Marketplace で Usage ベース (従量課金制) のプライベートオファーが EUR、GBP、AUD、JPY の 4 つの新通貨に対応しました。これまで、通貨が USD のみ利用可能でしたが、利用しやすい通貨で取引できるようになりました。外国為替リスクを回避でき、売り手は現地通貨での受取が可能となり、利用者は調達プロセスが簡素化されます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB (MongoDB 互換) が、アジア太平洋地域とメキシコの 4 つの新しいリージョンで利用可能になりました Amazon DocumentDB (MongoDB 互換) が大阪リージョン、タイリージョン、マレーシアリージョン、メキシコ中央リージョンで新たに利用可能になりました。Amazon DocumentDB は、MongoDB 互換のフルマネージドデータベースとなり、今回のアップデートでリージョンが拡張し、システムを構成しやすくなりました。 10/8(水) Amazon Q Developer がサービス料金の理解とワークロードコストの見積もりを支援 Amazon Q Developer に新しく「価格・コスト見積もり」を行うための機能が追加されました。自然言語で AWS サービスの料金情報を取得できるため、人間が複数の価格ページを確認する手間を削減しやすくなりました。「RDS 拡張サポートの料金は?」「SNS で月 100 万通知の見積もりは?」といった質問を投げかけられます。AWS Management Console のチャットパネルから利用可能です。詳細は こちらのドキュメントをご参照ください。 新しい汎用 Amazon EC2 M8a インスタンス AWS で新しい汎用 EC2 インスタンス M8a の提供が開始されました。5世代目 AMD EPYC プロセッサを搭載し、従来の M7a インスタンスと比較して最大 30% の性能向上と 19% のコストパフォーマンス改善を実現しています。メモリ帯域幅も 45% 向上し、レイテンシに敏感なワークロードにも対応できるようになりました。金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバーなどの高性能が求められる用途に最適で、オハイオ、オレゴン、スペインリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 10/9(木) Amazon DynamoDB が Internet Protocol version 6 (IPv6) をサポート開始 Amazon DynamoDB に VPC からアクセスする際に IPv6 がサポートしました。AWS PrivateLink Gateway および Interface エンドポイントを利用して VPC 内からアクセスする際に、IPv6 を利用した接続が可能となります。現在は米国リージョンで利用可能で、他のリージョンにも順次展開予定です。詳細は こちらのドキュメントをご参照ください。 Amazon Quick Suite の提供開始 従来あった Amazon QuickSight が Amazon Quick Suite に名前がリブランドされました。組織内の全従業員がデータに触れながら新しいインサイトを得やすくする方向性へのリブランドとなります。AI を活用した新機能を 3 つピックアップすると、Quick Research : インターネット上の情報と社内のデータをかけ合わせて質の高いレポートを作成、Quick Automate : 複雑な多段階のビジネスプロセスを自然処理で定義しながら自動的に処理、Quick Index : 組織内のデータを MCP、S3、Gmail、Sharepoint などと連携してナレッジべースとして提供、といった機能が含まれています。社内データと AI を連携する仕組みを、より統合された形で提供することで、社内でのインサイト発見に活用しやすくなります。最大 25 ユーザーまで 30 日間の無料トライアルが利用でき、バージニア北部、オレゴン、シドニー、アイルランドリージョンで提供中です。東京リージョンについては、Qucik Suite の UI に変更されていますが、新たな機能は現時点では利用できません。詳細は こちらの Blog 記事をご参照ください。 10/10(金) AWS Client VPN が macOS Tahoe をサポート開始 AWS Client VPN が MacOS Tahoe (バージョン 26.0) に対応しました。これまでも Mac 用の Client を提供していましたが、より最新の MacOS のバージョンに対応した形です。Client VPN ソフトウェアのバージョン 5.3.1 以降でサポートをしています。Client VPN は、リモートワークで自宅から会社のネットワークや AWS 環境に安全に接続したい場合に利用いただけるネットワーク系のサービスです。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

2025 年 9 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Reserved Instances Reserved Instances は、1 年または 3 年の期間で特定の使用量を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデルです。本セッションでは、Reserved Instances の概要、購入方法および購入計画などについて説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Reserved Instances の概要や購入方法を知りたい方 Reserved Instances の購入計画を立てたい方 データベースなどのワークロードのコスト最適化を促進したい方 本 BlackBelt で学習できること Reserved Instances の概要・購入方法について学んでいただけます 購入計画や購入後のモニタリングについても紹介します スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon Managed Grafana Amazon Managed Grafana は 拡張性、安全性、⾼可⽤性を備えたフルマネージドな Grafana 環境を提供する AWS サービスです。本セッションでは、Amazon Managed Grafana についてご紹介しております。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 上でオープンソースを利⽤したオブザーバビリティに関⼼のある⽅ Grafana の運⽤に課題を持っている⽅ Amazon Managed Grafana に興味のある⽅ 本 BlackBelt で学習できること Amazon Managed Grafana の特徴や機能 Amazon Managed Grafana のユースケース スピーカー 辻林侑 ソリューションアーキテクト Amazon Cognito Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito を使用するユースケースや機能についてご紹介します。 資料（ PDF ）  対象者 アイデンティティ管理に AWS の利⽤を検討している⽅ Amazon Cognito でできることを理解されたい⽅ Cognito ユーザープールと ID プールの違いや使い⽅を理解されたい⽅ 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito の使い方を学習いただけます Amazon Cognito ユーザープールと ID プールの違いについて理解を深めていただけます Amazon Cognito の機能や認証フローを習得いただけます スピーカー 鈴⽊ 理希也／海江⽥ 祥汰／吉⽥ 健⼈ クラウドサポートエンジニア Amazon GuardDuty Runtime Monitoring 編 Amazon GuardDuty の保護プランである Runtime Monitoring は EC2、ECS、EKS のワークロード内部の異常な動作をモニタリングし、セキュリティ脅威を検知できます。本セミナーでは Amazon GuardDuty Runtime Monitoring の概要と開始方法および検知例について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS ワークロード上のセキュリティ強化をご検討中の方 Amazon GuardDuty Runtime Monitoring の機能について知りたい方 Amazon GuardDuty Runtime Monitoring の開始方法や検出例について知りたい方 本 BlackBelt で学習できること ランタイムモニタリングをおすすめする理由 Amazon GuardDuty Runtime Monitoring の概要 Amazon GuardDuty Runtime Monitoring の開始方法 Amazon GuardDuty Runtime Monitoring による脅威検出の例 スピーカー 坂下 拓弥 クラウドサポートエンジニア Amazon Connect Global Resiliency Amazon Connect は東京リージョンで複数の要素により信頼性を高めていますが、地域的な災害や障害が発生した場合など、より高い要件に対応することが必要なお客様のために大阪リージョンを利用した Amazon Connect Global Resiliency によって事業継続計画にも対応できるようになりました。本セッションは Amazon Connect が備える信頼性を改めて解説し、Amazon Connect Global Resiliency で実現可能になることや注意事項について紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect が備えている信頼性を理解したい方 Amazon Connect における BCP の設計に関心のある方 Amazon Connect Global Resiliency の具体的な機能が知りたい方 本 BlackBelt で学習できること Amazon Connect が備える信頼性について Amazon Connect Global Resiliency の機能、動作、および運用上の注意事項 Amazon Connect Global Resiliency の具体的な切替方法 スピーカー 清水 幸典 Amazon Connect スペシャリスト ソリューションアーキテクト

本記事は米国時間 10 月 13 日に公開された AWS エージェンティック AI 担当バイスプレジデント　スワミ・シバスブラマニアン（Swami Sivasubramanian）の署名ブログ「 Make agents a reality with Amazon Bedrock AgentCore: Now generally available 」の日本語抄訳版です。 AIエージェントをプロトタイプから、セキュリティ、スケーラビリティ、信頼性を備えた本番環境へ 2006年に AWS を立ち上げた時、私たちはクラウドコンピューティングが組織のテクノロジーを構築し、スケールさせる方法を変革すると信じていました。現在、AI エージェントについても同様の転換点に立っています。私たちは、数十億もの AI エージェントが協働し、日常業務から複雑なビジネスプロセスまであらゆるものを変革する世界を思い描いています。しかし、これを現実のものとするには、フレームワークやローコードの開発者向けツール以上のものが必要です。企業がビジネスの基盤として信頼できるAIエージェントには、エンタープライズグレードの運用基盤が必要です。その基盤は、セキュアで信頼性が高く、スケーラブルで、AI エージェントの非決定的な性質を考慮して構築されている必要があります。AWS はミッションクリティカルなシステム構築支援の経験を活かし、多様な組織が自信を持ってエージェンティックシステムを本番環境へ移行できる包括的な基盤を Amazon Bedrock AgentCore を通じて提供します。 AgentCore: AIエージェントを迅速に本番環境へ AgentCore の一般提供開始により、すべての開発者がAIエージェントをパイロット環境からフルスケールの本番環境へ迅速に移行することが可能になります。AgentCore は AI エージェントの構築、デプロイ、運用に必要な基盤を提供します。エージェントに複雑なワークフローを処理するためのツール、メモリ、データを簡単に取り入れることが可能です。数行のコードを書くだけで、現在利用可能な最も安全でスケーラブルなランタイム環境の一つの選択肢にAIエージェントをデプロイすることが可能です。また、エンタープライズグレードでの展開に必要なコントロールとアクセス管理を備えてこれらのエージェントを運用できます。これらすべてをインフラ管理なしで実行でき、任意のモデルやエージェントフレームワークを使って簡単に開始できます。 AgentCore SDK は、多様な業界のあらゆる規模のお客様に既に100万回以上ダウンロードされています。初期のお客様には、Clearwater Analytics (CWAN)、Cox Automotive、Druva、Ericsson、Experian、Heroku、National Australia Bank、ソニーグループ、Thomson Reutersなど、その他多くのお客様が含まれます。AgentCore はまた、Accenture、Cisco、Deloitte、SalesforceなどのAWSパートナーによってサポートされ、すでに変革を実現する結果をもたらし始めています。 AgentCore: 包括的なAIエージェント基盤 AI エージェントの構築は簡単ではありません。例えば、ID プロバイダーとの統合方法、メモリと可観測性（オブザーバビリティ）の実現方法、ツールとの統合方法などを理解する必要があります。私たちのAIエージェント基盤は、構築からデプロイ、運用までのAI エージェント開発ライフサイクル全体にわたるフルマネージドサービスを提供します。任意のモデルやフレームワークを組み合わせることができ、エンタープライズグレードのインフラストラクチャとツールにアクセスしながら最大限の柔軟性を提供します。その主要な機能を見てみましょう。 自由自在にAIエージェント構築： AI エージェント分野は急速に進化しており、新しいフレームワーク、モデル、プロトコルがほぼ毎週のように登場しています。AgentCore のサービス群はモジュールとして提供されているため、必要に応じて組み合わて利用することも、単独で利用することも可能であり、開発者はAIエージェントを望む方法で構築できます。組織としては、チームが必要とするAgentCore のサービスを選択しながら、好みのフレームワーク（CrewAI、Google ADK、LangGraph、LlamaIndex、OpenAI Agents SDK、Strands Agentsを含む）とモデル（Amazon Bedrockで利用可能なモデルや、OpenAIやGeminiなどBedrock以外で利用可能なモデルを含む）を使用できるため、望む方法で自由に構築できます。 価値を生み出すAIエージェントのための基盤： AI エージェントは具体的なアクションの実行で価値を生み出します。例えば、コードの記述と実行、企業システムへの接続、ウェブサイトのナビゲーションなどです。AgentCoreはこれらに不可欠なサービスを提供します。AgentCore Code Interpreter により、AIエージェントは分離された環境でコードを安全に生成・実行でき、AgentCore Browserにより、AIエージェントはウェブアプリケーションを大規模に操作することができるようになります。また、AgentCore Gateway は既存の API や AWS Lambda 関数をエージェント互換のツールに変換し、既存の MCP サーバーに接続し、必要不可欠なサードパーティのビジネスツールやサービス（JiraやAsana、Zendeskなど）とのシームレスな統合を提供します。この統一されたアクセスポイントにより、企業システム全体にわたる安全な統合が可能になります。AgentCore Identity を使用すると、エージェントはOAuth 標準を使用した適切な認証と認可によって、これらのツール全体に安全にアクセスし、操作できます。 インテリジェントなメモリを備えたコンテキスト対応AIエージェント： AIエージェントが真に効果的であるためには、時間の経過とともに対話からコンテキストを維持し、学習する必要があります。例えば、企業向けソフトウェアを検討するお客様を支援する営業サポートAIエージェントの例を考えてみましょう。複数回にわたるお客様との会話から、お客様の業界、予算上の制約、技術要件を記憶し、同じ質問を繰り返すことを避けながら、お客様にパーソナライズされた提案を行う必要があります。同様に、複雑な技術的トラブルシューティングを支援する例では、AI エージェントは以前のデバッグ試行の結果を思い出し、より的を絞ったソリューションを提供しなければなりません。AgentCore Memory は、開発者が複雑なメモリインフラストラクチャを管理することなく、このような高度なコンテキスト対応エクスペリエンスの構築を支援し、AI エージェントがユーザーの好み、過去のやり取り、そして会話を豊かにする関連コンテキストの詳細な理解を構築・維持するのを支援します。 信頼できるエージェントのための包括的な可観測性： AI エージェントはリアルタイムで推論し、非決定的にアクションを実行します。そのため、開発者にはAIエージェントの推論とアクションに対して完全な可視性が必要です。AgentCore Observability は、リアルタイムダッシュボードと詳細な監査証跡を通じて包括的なモニタリングを提供します。組織はAIエージェントのすべてのアクションを追跡し、問題を迅速にデバッグし、パフォーマンスを継続的に最適化できます。AgentCore Observability は、メトリクス、ログ、トレースなどのテレメトリデータを収集してルーティングするための標準化されたプロトコルとツールを提供するオープンソースのオブザーバビリティフレームワークであるOpenTelemetry（OTEL）との互換性を提供しています。これにより、Dynatrace、Datadog、Arize Phoenix、LangSmith、Langfuseなどの既存のモニタリングツールと統合が可能です。 業界をリードする信頼性であらゆる規模に対応： 従来のアプリケーションとは異なり、AI エージェントのワークロード持続時間は本質的に予測不可能です。AgentCore Runtime はこうした変動性に対応するように設計されており、必要に応じてゼロから数千のセッションへと自動的にスケーリングし、長時間実行タスク向けに業界をリードする8時間のランタイムを提供します。 エンタープライズグレードのAIエージェントセキュリティ： AIエージェントはユーザーに代わって行動しながら、複数のシステムに安全にアクセスし、機密データを処理する必要があるため、堅牢なセキュリティと規制コンプライアンスの実現においては一切の妥協が許されません。AgentCore はAI エージェントが安全に運用できるよう、すべてのサービスにセキュリティを組み込んでいます。バーチャルプライベートクラウド（VPC）環境と AWS PrivateLink をサポートし、ネットワークトラフィックをプライベートで安全に保ちます。最も重要なことに、AgentCore Runtime は microVM 技術を通じて業界をリードするセキュリティを提供し、各AIエージェントのセッションに独自の分離されたコンピューティング環境を与え、データ漏洩を防止し、すべての相互作用の完全性を維持します。 AgentCoreでスピード、スケール、セキュリティを両立： AgentCore は、 Kiro や Cursor AI などの統合開発環境（IDE）で動作する MCP サーバーを通じて、本番環境対応の AI エージェントを簡単に構築できます。開始にはわずか数分しかかかりません。そして、これらは簡略化されたツールではありません。堅牢なセキュリティを維持しながら、ゼロから数千のセッションへと即座にスケールできる、フル機能の本番環境対応ソリューションです。つまり、お客様のチームは AI エージェントが実証済みの基盤上に構築されていることを理解した上で、アイデアからデプロイメントまで自信を持って迅速に進めることができます。 AIエージェントの価値を実現するお客様事例 Cohere Health の規制された医療環境から、Ericsson の複雑でテクニカルなシステム、そしてソニーグループのグローバル規模での変革まで、先進的な組織がAgentCoreを活用して業界を超えた次世代のAIイノベーションを推進しています。AI 時代に成功する組織は、未来を完璧に予測する組織ではなく、進化する柔軟性を維持しながら実証された基盤の上に構築する組織でしょう。AgentCore を基盤とすることで、AI エージェントの展開と運用のための専用サービスにアクセスできるだけでなく、グローバル規模でセキュリティを確保しながら、企業の変革を支援してきた約20年の経験を持つパートナーも得ることになるでしょう。 世界最大の広告会社 Publicis Groupe に所属するEpsilon が、AgentCore を使用して大手ブランドのキャンペーンをパーソナライズし、革新する様子を以下のビデオでご覧ください。同社の Intelligent Campaign Automation ソリューションは、複数のチャネルにわたるキャンペーン設計、オーディエンスターゲティング、リアルタイム最適化を自動化し、実行時間の短縮と顧客ターゲティング精度の向上を大規模に実現しています。 インテリジェントなワークフロー自動化による製造業の変革： Amazon Devices Operations & Supply Chain チームは、AI エージェントを活用した製造アプローチの開発にAgentCoreを使用しています。この新しいアプローチの一環として、AIエージェントは製品仕様を使って協働し、手動プロセスを自動化します。あるAIエージェントは製品要件を読み取り、品質管理のための詳細なテスト手順を作成し、別のエージェントは製造ライン上のロボットが必要とするビジョンシステムをトレーニングします。その結果、従来はエンジニアリング時間に数日を要していたオブジェクト検出モデルの微調整が、高い精度で1時間以内に完了できるようになりました。この実証実験は、AI エージェントが初期製品要件から最終生産までの過程を効率化するスマートな製造へのビジョンの始まりに過ぎません。 AIエージェントによる医療判断の迅速化： 医療現場では、1分1秒が重要です。Cohere Health® は臨床インテリジェンス企業で、保険者（Payer）、医療機関（Provider）の連携を強化し、ケア前後の臨床的意思決定のスピードと正確性を向上させることに焦点を当てています。同社の臨床トレーニングを受けたAIは、患者ケアへのアクセスを加速し、患者のアウトカムを改善し、医療機関の管理負担を軽減し、ケア継続全体にわたって医療サービス提供におけるエコノミクスを改善します。 例えば、Cohere HealthはAgentCoreを利用して、医療保険における医療の必要性審査の精度と効率を最適化するAI搭載コパイロットであるCohere Review Resolve を構築しました。Cohere Review Resolve は、臨床記録、患者メモ、FAX などの構造化データと非構造化データの両方を分析し、要求された治療の医学的必要性を検証するための証拠を迅速に特定して表示します。このコパイロットは、医療保険の審査担当者に事前承認リクエストの審査に向けて必要な臨床コンテキストを提供し、審査担当者の質問にもインテリジェントに対応します。 Cohere Health は、高度に規制された医療業界においてエージェンティックAIを初めて本番環境でデプロイするためのエンタープライズグレードのインフラを求め、AgentCore を選択しました。AgentCore で利用可能な包括的な監査証跡、拡張セッションサポート、複数時間にわたる複雑なワークフローを通じて履歴を維持する機能は、Cohere Health のユースケースに不可欠となっています。 Cohere Health は、Review Resolve が今後レビュー時間を30～40％短縮し、重要な義務付けられた処理時間を満たすのに貢献するだろうと予想しています。より迅速な意思決定は、患者にとりケアへのアクセスを早め、治療への順守を増やし、結果を改善し、コストを削減します。Review Resolve はまた、医療保険が臨床的決定の正確性を約30％向上し、それによって医療費の削減と患者のアウトカム改善に貢献する見込みです。 通 信業界におけるAIエージェント — 複雑なシステムの簡素化： 通信技術における世界的リーダーであるEricssonは、AIエージェントのデプロイにおける課題に取り組むためにAgentCore を使用しています。Ericsson で、ビジネスエリアネットワークにおけるAIと先進テクノロジーを担当する責任者であるDag Lindbo 氏は次のように述べています。「Ericsson において、私たちの3G/4G/5G/6Gシステムは数百万行ものコードで構成され、数千の相互接続されたサブシステムに及んでいます。これは、国レベルの重要インフラストラクチャにおける数十年にわたるエンジニアリングイノベーションを示しています。AgentCore は、データと情報の重要な融合を実現し、実世界のR&Dにおいて前例のない能力を持つAIエージェントを提供し、数万人規模の社員全体で二桁の価値創出につながるでしょう。また、AgentCore は任意のエージェントフレームワークを使用できるため、多くのチームとユースケースにわたって拡張する上で不可欠です」 エンターテインメント業界におけるエージェント活用： セキュリティ、オブザーバビリティとスケーラビリティを両立：世界有数のテクノロジー・エンターテインメント企業であるソニーグループでも、AgentCoreがインパクトを生み出しています。「Agentic AI は、これまでにないレベルでの業務の高度化と効率化を実現するために不可欠な技術です」とソニーグループ株式会社 D&Tプラットフォーム AI Acceleration 部門 部門長の大場 正博氏は述べています。「一方で、エージェンティックAI の活用には、多くの技術的課題があることも事実です。Amazon Bedrock AgentCore を活用することで、グループ全体のAgentic AI Platform を構築し、エンタープライズレベルのセキュリティ、オブザーバビリティそしてスケーラビリティを実現し、さらにクロスプラットフォームでのシームレスな AI リソースへの接続を実現しました。Amazon Bedrock AgentCore を 私たちの AI エコシステムの中核に置くことで、膨大なAIを管理・共有する能力を獲得し、確信と安全性を持ってAIトランスフォーメーションを加速することができます」 AgentCore は現在、アジアパシフィック（ムンバイ）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、ヨーロッパ（ダブリン）、ヨーロッパ（フランクフルト）、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）の9つの AWS リージョンで一般提供され、お客様の世界規模での展開をサポートしています。AgentCore上で動作するように予め設計・構築されたAIエージェントとツールを提供する AWS Marketplace を活用することで価値実現までの時間を加速することも可能です。 Amazon Bedrock AgentCoreをご利用の日本のお客様からのコメント （日本語抄訳版における追加記載、五十音順） 株式会社ウェザーニューズ　執行役員 テクノロジー・プロダクト責任者 出羽 秀章氏 ウェザーニューズでは、BtoC 向けの「お天気エージェント」やBtoB 向け SaaS サービスにおいて、AIエージェントの β 版をリリースし、天気に関連するデータやソリューションの提供を開始しています。正式リリース後により多くのユーザーに安心してご利用いただくためには、性能・セキュリティ・ガバナンス・スケーラビリティといった観点が不可欠です。今回、Amazon Bedrock AgentCore のマネージドサービスを活用することで、これらの課題解決に向けて大きく前進できると考えています。新たに提供されるフルマネージドなサービス群と共に、お客様へこれまで以上に大きなビジネス価値をお届けできることを楽しみにしています。 TIS株式会社 IT 基盤技術事業本部 IT基盤ビジネス事業部長　黒田 訓功氏 当社のお客様には、安全性とガバナンスを重視するエンタープライズ企業に加え、AI活用による成長を目指す中堅・中小企業まで、幅広い層が含まれます。Amazon Bedrock AgentCore によるアイデンティティ管理、セッション隔離、運用の透明性の確保は、そうしたお客様にとって“安心して業務を任せられる AI エージェント”の基盤となります。応答の質、対話の一貫性、サービスの稼働安定性が整うと、利用者にとって使いやすく、心地よい体験となります。そのような体験が信頼を育み、選ばれ続けるサービスにつながると考えています。Amazon Bedrock AgentCore があるからこそ、TIS はお客様から信頼される AI エージェントソリューションの提供者として、これからも期待に応え続けられると確信しています。 株式会社ディー・エヌ・エー ML Ops Engineer　外山 寛氏 弊社ディー・エヌ・エーでは AI オールインを掲げ全社で AI 活用を推進していきます。その際に大規模言語モデル（LLM）を業務で安全に活用するためにデータセキュリティに配慮したシステム設計が重要になってきます。 Amazon Bedrock AgentCore ではそのようなシステム設計を支援するための機能が提供されていると感じます。 今後のさらなるきめ細やかなデータセキュリティ機能の発展に期待しています。 株式会社野村総合研究所　AI 担当 経営役　生産革新センター　センター長　稲葉 貴彦氏 Amazon Bedrock AgentCore は、企業のデジタル変革を根本的に変える可能性を秘めています。多様なオープンソースフレームワークとの柔軟な連携や、独自の機能を提供する 7 つのサービスの選択肢、完全なセッション分離機能と最大 8 時間の長時間ワークロード対応により、より高度な業務での安定運用が期待できます。プレビュー版からの検証を経て、現在、社内外の複数プロジェクトで利活用を進めており、今後も検証を重ねながら、当社のお客様の競争優位性確保に貢献してまいります。 今すぐAgentCoreを始めましょう – aws.amazon.com/bedrock/agentcore/にアクセスして、エージェントの未来を構築し始めましょう！

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 来る 10/24 に AWS Japan AI Agent Day 2025 が開催されます。本日ご紹介するAmazon Quick Suite をはじめとして、 AWS でAgentを活用するための知見を学ぶことができます。ぜひ、 こちらの申し込みページ からご登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社情報戦略テクノロジー様、AIエージェント秘書「パイオにゃん」で情報探索業務を83%改善 株式会社情報戦略テクノロジー様は、IT コンサルティングやシステム開発を行う企業です。社員の情報探索業務の効率化とスキルアップという課題に対して、Amazon Bedrock を活用したAIエージェント秘書「パイオにゃん」を開発しました。その結果、情報探索業務を83%改善し、社員一人ひとりに寄り添いともに成長する仕組みを実現しています。さらに社員の成長の可視化にも成功し、組織全体の生産性向上に貢献しています。 AWS生成AI国内事例ブログ: 第一三共株式会社様、AIエージェント統合型創薬基盤の構築を開始 第一三共株式会社様は、製薬企業として次世代の創薬研究プロセスの実現に取り組んでいます。AWS と連携し、AIエージェントシステムを統合した創薬研究基盤の構築を開始しました。AI・クラウド・実験自動化技術を融合させることで、創薬研究プロセスの革新を目指しています。この取り組みにより、創薬の効率化と新薬開発の加速が期待されています。 ブログ記事「 ビジネスインテリジェンスの再解釈: Amazon QuickSight から Amazon Quick Suite への進化 」を公開 Amazon QuickSight が Amazon Quick Suite へと進化しました。この記事では、エージェンティックAIを搭載した新しいワークスペース機能について詳しく解説しています。ビジネスインテリジェンスの概念を再定義し、データ分析の新しい形を体験できる内容となっています。 ブログ記事「 Amazon Bedrockを活用したAWS サポート問い合わせ内容の自動集約ソリューションの実装 」を公開 AWS Support と Amazon Bedrock を組み合わせた、サポート問い合わせ内容の自動集約ソリューションの実装方法を紹介しています。生成AIを活用することで、サポート対応の効率を向上させる実践的な事例です。 ブログ記事「 Amazon Q Business ブラウザ拡張機能による組織の生産性向上 」を公開 Amazon Q Business のブラウザ拡張機能について詳しく解説しています。ブラウザから直接企業ナレッジにアクセスし、生成AIの支援を受けられる機能により、組織全体の生産性向上が期待できます。実際の使用方法と活用シーンを紹介しています。 ブログ記事「 AWS WAF で AI ボットを管理し、セキュリティを強化する方法 」を公開 生成AIボットの普及に伴い、ウェブサイトへのボットアクセス管理が重要になっています。この記事では、AWS WAF を使用して AI ボットを適切に管理し、セキュリティを強化する方法を解説しています。正規のAIボットと悪意のあるボットを区別する実践的な手法を紹介しています。 ブログ記事「 AWS re:Invent 2025 におけるクラウドガバナンスの必須ガイド 」を公開 AWS re:Invent 2025 で注目すべきクラウドガバナンス関連のセッションとトピックを紹介しています。生成AI時代におけるガバナンスのベストプラクティスについても触れられています。 ブログ記事「 [AWS Summit Japan 2025] 生成 AI を用いた自治体向けソリューションデモのご紹介 」を公開 AWS Summit Japan 2025 で展示された、生成AIを用いた自治体向けソリューションデモを紹介しています。公共セクターにおける生成AI活用の具体例を学べる貴重な機会です。 ブログ記事「 日本のヘルスケア・ライフサイエンス業界における戦略的ビジョン「Journey for 2030 データがつながる、価値を生む」を発表 」を公開 日本のヘルスケア・ライフサイエンス業界における AWS の戦略的ビジョン「Journey for 2030」を発表しました。データ連携による価値創出を目指す、業界の未来像を描いています。 ブログ記事「 ヘルスケア・ライフサイエンスの意思決定と業務の高度化を実現する HealthData x Agent を発表 」を公開 ヘルスケアとライフサイエンス分野向けの新しいソリューション「HealthData x Agent」を発表しました。AIエージェントを活用して医療データの分析と意思決定を支援し、業界の変革を加速させるソリューションです。この記事では、HealthData x Agent の機能と活用方法を詳しく解説しています。 ブログ記事「 生成AIで起こるSAP技術文書変革：Amazon BedrockでSAP Notesのナレッジ生成を加速 」を公開 SAP システムの技術ドキュメント作成に生成AIを活用する方法を紹介しています。Amazon Bedrock を使用して SAP Notes のナレッジ生成を自動化・高速化することで、ドキュメント作成の効率を大幅に向上させる事例を解説しています。 ブログ記事「 Amazon Bedrock での Claude Sonnet 4.5 のご紹介: Anthropic の最もインテリジェントなモデルで、コーディングや複雑なエージェントに最適 」を公開 Anthropic の最新モデル Claude Sonnet 4.5 が Amazon Bedrock で利用可能になりました。特にコーディングタスクと複雑なエージェント構築において優れた性能を発揮します。この記事では、Claude Sonnet 4.5 の特徴と活用方法、実際のユースケースを詳しく紹介しています。 サービスアップデート Amazon Q Developer がサービス価格の理解とワークロードコスト見積もりに対応 Amazon Q Developer に新機能が追加され、AWS サービスの価格を理解し、ワークロードのコスト見積もりを支援できるようになりました。開発者は自然言語で質問するだけで、使用予定のサービスのコスト情報を取得し、アーキテクチャ設計時のコスト最適化が容易になります。コスト意識の高い開発を支援する重要なアップデートです。 Amazon Quick Suite: エージェンティックAI搭載ワークスペースを発表 Amazon QuickSight が Amazon Quick Suite へと進化し、エージェンティックAIを搭載したワークスペース機能が追加されました。AIエージェントがデータ分析を支援し、ビジネスインサイトの発見を加速します。自然言語でのデータ探索、自動的なインサイト生成、インタラクティブなダッシュボード作成など、データ分析の新しい体験を提供します。 AWS Service Quotas で自動クォータ管理機能が一般提供開始 AWS Service Quotas に自動クォータ管理機能が一般提供開始されました。この機能により、サービスの使用状況を監視し、クォータ上限に近づいた際に自動的に引き上げリクエストを送信できるようになります。生成AIワークロードなど、急速にスケールするアプリケーションの運用において、クォータ制限によるサービス中断を防ぐことができます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近感動したものは帯広の豚丼です。

シニア GTM アナリティクススペシャリストソリューションアーキテクトの大薗です。 2025 年 7 月 15 日に「 Amazon SageMaker Roadshow –Japan 」を開催しました。本イベントでは、 Amazon SageMaker 開発チームが来日し、次世代の Amazon SageMaker を開発した理由やその機能紹介を行い、AWS Japan チームからデモやプレゼンテーションを通じて Amazon SageMaker の世界観を深堀りしました。さらに NX 情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様、ソニーグループ株式会社様、株式会社 NTT データ様より SageMaker を含めたデータと AI の具体的な活用事例についてお話がありました。本ブログでは当日の各発表内容について紹介します。 次世代の Amazon SageMaker とは？ 次世代の Amazon SageMaker は、2024 年末に開催された re:Invent 2024 で発表された、すべてのデータに対する統合アクセスとともに、分析と AI のための統合エクスペリエンスを提供するサービスです。モデル開発、生成 AI、データ処理、SQL 分析のために使い慣れた AWS ツールを使用して、統合スタジオ環境からの迅速なコラボレーションと構築を実現します。 アジェンダ Welcome and Keynote Navigating Modern Data Landscapes with Amazon SageMaker Amazon SageMaker エンドツーエンドデモ Amazon SageMaker によるデータ & AI ガバナンスの民主化 NX Data Station ～ Nippon Express ｘ キヤノン MJ グループによるデータ分析基盤構築（NX 情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様） Amazon SageMaker による生成 AI アプリケーション開発 ソニーグループにおける生成 AI の社内活用と今後の展望（ソニーグループ株式会社様） データから AI をつなぐオールインワンプラットフォーム「データレイクハウス」と Amazon SageMaker（株式会社 NTT データ様） 1. Welcome and Keynote イベントキーノートとして、Amazon SageMaker のプロダクトマネジメントの Director である William が登壇しました。William はまず、データ、AI、アナリティクスの融合が進む現代において、AWS のデータ基盤がどのように進化してきたかを語りました。 マネージドデータベースの導入から始まり、サーバーレス化、マルチリージョン展開、そして Amazon Aurora による高速トランザクション処理の実現まで、データベース技術の革新的な進化を時系列で解説しました。さらに、Amazon 社内での大規模 AI モデル開発経験が、現在の Amazon SageMaker AI という形で結実し、一般提供されているという歴史的な流れも紹介しました。そして生成 AI のテクノロジーとして Amazon Bedrock や Amazon Nova シリーズ、また、 Amazon Q Developer や Amazon Q Business 、 Amazon QuickSight など、開発者やビジネスアナリストが AI を活用するための具体的なサービスも紹介されました。 かつては個別に発展していたビッグデータ、SQL アナリティクス、機械学習、生成 AI の領域が、Amazon SageMaker という単一のプラットフォームで統合されつつある未来像を示し、次のスピーカーである Stephanie による Amazon SageMaker の詳細説明への期待を高めて締めくくられました。 2. Navigating Modern Data Landscapes with Amazon SageMaker 次のセッションでは、AWS のアナリティクス関連の Go-to-Market チームリーダーを務める Stephanie が登壇し、次世代 Amazon SageMaker の全容を紹介しました。 冒頭、Stephanie は現在の企業が直面している課題について触れました。第三社機関の調査を引用しながら、多くの企業が生成 AI の実験に取り組んでいるものの、その 70% が本番環境への展開に至っていないという現状を指摘。その根本的な原因の一つともなる、強固なデータ基盤の重要性を力強く訴えかけました。そして、これらの課題を解決するために開発された次世代 Amazon SageMaker の紹介へと話を展開。その中でも「 Amazon SageMaker Unified Studio 」という新しい統合環境の紹介に時間を割き、データエンジニア、ビジネスアナリスト、データサイエンティストが一つのプラットフォーム上で協働できる環境の中で、従来別々に存在していたツールやワークフローをシームレスに統合できることのメリットを説明しました。 データガバナンスの面では、 Amazon SageMaker Catalog という新機能を紹介。生成 AI を活用してメタデータを自動生成する機能や、データの品質管理、データリネージ管理の機能が組み込まれており、全社規模でのデータ活用を加速できる点を強調しました。さらに、 Amazon SageMaker のレイクハウスアーキテクチャ についても詳しく解説。オープンな設計思想に基づき、様々なデータソースを統合できる柔軟性と、 ゼロ ETL による効率的なデータ処理の実現について解説しました。 最後に、 Amazon SageMaker の料金 の考え方について、紹介した様々な機能が従量課金制で提供される点を解説しました。これによりコスト面での懸念を払拭しながら、企業のデータ活用と AI 導入への取り組みを進めやすいモデルとなっていることを強調しました。 まとめとして、次世代 Amazon SageMaker が企業のデータ活用と AI 導入を本質的に変革するプラットフォームとして位置づけられていることを強調してセッションを締めくくりました。 3. Amazon SageMaker エンドツーエンドデモ 続くセッションでは、AWS Japan BigData Architect 関山より、次世代の Amazon SageMaker のユーザー体験をエンドツーエンドで知っていただくために、架空の企業エニーカンパニービバレッジにおけるデータと ML/AI の課題解決のストーリーを Amazon SageMaker Unified Studio 上でデモしました。 Amazon SageMaker Unified Studio の各機能はネイティブで Amazon Q と統合されており、データディスカバリー、ETL ヴィジュアルパイプラインの自動作成、SQL の自動生成などが可能になっています。下のスクリーンショットは、画面右側の Amazon Q チャットウィンドウで自動生成したクエリをクエリブックから実行するデモです。 Amazon SageMaker Unified Studio におけるデータガバナンスの中核をなすのが Amazon SageMaker Catalog です。SageMaker Catalog を使用することで、データを簡単に発見・共有する仕組みを導入できます。また、生成 AI を活用することで新しく作ったテーブルにビジネスメタデータを自動生成することもできます。 SageMaker Catalog で共有されたデータを機械学習チームが利用して、今後の製品の売り上げを予測しグラフにプロットしています。このデモでは機械学習に加えて、生成 AI を活用したマーケティングコンテンツ (テキスト・画像) の自動生成も紹介しました。 このように、複数人で協働する具体的なユースケースを想定したデモを通じて、Amazon SageMaker Unified Studio を活用したデータと AI に関する一連の作業のイメージを披露しました。データと AI の活用に課題をお持ちの方には、ぜひ、次世代の Amazon SageMaker ならびに Amazon SageMaker Unified Studio をお試しいただき、データとAIをビジネス推進のために活用いただけましたら幸いです。 4. Amazon SageMaker によるデータ & AI ガバナンスの民主化 デモセッションに続いて、AWS Japan アナリティクススペシャリストソリューションアーキテクトの大薗よりデータ & AI ガバナンスの民主化をテーマにセッションを行いました。 セッションでは、まず AI 時代におけるテクノロジーの変化について説明し、生成 AI の進化について触れました。単純なチャットボットから、複雑なタスクを自動化する生成エージェント、さらには完全自立型のエージェンティックAIへと発展していく流れを解説し、今後ますます質が高く統制されたデータを最大限活用いる環境準備が不可欠である時代がきていることを提起しました。 データガバナンスに対する新しい考え方として、従来の「統制重視」から「データ活用促進のためのガードレール」という位置づけへの転換について説明し、企業全体でのデータガバナンスの民主化の必要性を述べました。組織面での取り組みでは、「データスチュワードシップ」の概念を中心に、クロスファンクショナルなチーム編成の必要性や、データドメイン駆動のガバナンスについて説明。これらを実現するための具体的な組織構造についても例を交えて解説しました。 技術面では、SageMaker Catalog の機能の詳解を行いました。このツールが「発見」「ガバナンス」「コラボレーション」という 3 つの主要機能を持つことを説明し、特に「発見」の機能については、メタデータの自動生成やデータ品質の可視化などの特徴と仕組みを紹介しました。最後に、プロジェクトベースの権限管理モデルや、様々なツールとの統合について説明を行い、データガバナンスのプラットフォームとしての SageMaker Catalog の位置づけを示してセッションを終えました。 5. NX Data Station ～ Nippon Express ｘ キヤノンMJグループによるデータ分析基盤構築（NX情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様） 本セッションでは日本通運株式会社 (NX) が AWS 上で利用しているデータ分析基盤である「NX Data Station」について、NX 情報システム株式会社 (NIS) からそのビジネスの狙いを、そして技術観点で伴走支援を提供しているキヤノンＩＴソリューションズ株式会社からは、どのような構成でどう進化させているかの説明がありました。 最初に登壇した NIS 第 5 アプリケーションマネジメント部 次長 髙 為彦氏からは、日本通運が置かれているビジネス的な課題とNX Data Station を活用することでどのように課題解決に取り組んでいるかについて説明がありました。 最初に、NX Data Station のアーティテクチャーの概要が説明されました。NX グループでは 2013 年からオンプレミスやプライベートクラウドから AWS へ移行を開始しており、それらとの親和性を鑑み、 Amazon Redshift や Amazon QuickSight などのサービスを利用し、データレイク、データウェアハウスを構築されてきました。 髙氏は、AWS は機械学習や AI などのサービス基盤がアドオンで追加可能で、基本的に従量課金であり、スモールスタートが可能であること、コストパフォーマンスの良さ、およびデータ利活用文化を醸成する上で必要となる PoC やトライ& エラーに適しているという運用面から、AWS を選定したと説明されました。 課題の例として、物流業界における労働力不足という社会課題について、日本通運がどう対応し、NX Data Station をどう活用しているかの説明がありました。自動倉庫といった機械による効率化もあるものの、まだ人手に頼ることも多くあり、24 時間稼働の大型倉庫などでは、一日の労働者数が延べ数百人規模になることもある業務です。髙氏は、労働力不足への対応で重要なのは適切な人員配置であると説明したうえで、繁忙期、閑散期、キャンペーンなどに適切な配置を実施するため、NX Data Station のデータレイクに蓄積したデータを BI の分析や機械学習により予測し、最適な配置を計算していると説明しました。商品カテゴリー、作業スペース必要の有無などを考慮したメッシュの細かい予測をし、その予測に対してフォークリフトに乗れる、特殊梱包ができる、など従業員の属性などを掛け合わせ、最適な人員配置を計算します。また、求人情報をダッシュボード化して分析し、それらの人員確保の戦略を練ることも合わせて行っています。 続いて、キヤノンＩＴソリューションズ株式会社 渡邊 哲也 氏より、NX Data Station のアーキテクチャについて、技術的な説明があった後に、それをどのように継続して改善しているかについて説明がありました。構成として、ETL は AWS Glue 、補足手法として Amazon AppFlow と AWS Database Migration Service (DMS)、データレイクとしての Amazon S3 、DWH として Amazon Redshift を活用する構成です。 また、 渡邊氏は、NX Data Station が活用され続けている理由として、キヤノンＩＴソリューションズが 1/サービスを常にアップデートすること、2/データ登録の障壁をなくすこと、そして 3/前向きなユーザーを待たせないこと、といった工夫を続けていることを説明されました。 これにより、SIer がなんでもやるのではなく、ユーザーによるデータ活用の 「自走」 が行われる環境を実現しているとし、最後に、利用している AWS サービスが含まれる、Amazon SageMaker への移行・活用を検討している事を説明されました。 6. Amazon SageMaker による生成 AI アプリケーション開発 AWS Japan の AI/ML スペシャリストソリューションアーキテクトである武田からは、Amazon SageMaker の AI 機能に深く踏み込んだ内容に関するセッションをお届けしました。 セッションは、現代の AI 活用の課題提起から始まりました。生成 AI の急速な発展により、顧客体験の改革や従業員の生産性向上など、様々な可能性が広がっている一方で、企業が直面している現実的な課題について説明。特に、単に基盤モデルの API を利用するだけでは、企業の複雑な課題解決や競合との差別化は難しいという点を強調しました。 さらに、現在の生成 AI の技術的背景について、歴史的な流れを交えながら説明が続きました。ニューラルネットワークから始まり、ディープラーニング、そして現在のトランスフォーマーモデルに至るまでの技術の変遷について説明を行ったうえで、なぜ Amazon SageMaker が必要になるのかといった点について解説しました。 セッションの後半では、実際のデモを用いて SageMaker Unified Studio における AI/ML 関連の機能を深堀りして紹介しました。チャットボット開発の手順からファインチューニングの方法まで、具体的な操作フローを示し、システムプロンプトの設定、ナレッジベースの統合、ガードレールの設定など、実務で必要となる機能が単一の画面で操作できる点、さらに、プロジェクトの共有機能など、チーム開発を意識した機能についても触れ、従来別々に管理されていた機能が一つの環境で扱えるようになった点について説明しました。 セッションを通じて、生成 AI の活用には技術的な理解と実務的なノウハウの両方が必要であり、Amazon SageMaker がそれらを統合的にサポートするプラットフォームとして機能していることを伝えました。 7. ソニーグループにおける生成AIの社内活用と今後の展望（ソニーグループ株式会社様） 本セッションでは、ソニーグループ株式会社からソニーグループにおける生成 AI の活用を推進するための取り組みの概要と、技術的な観点から RAG (Retrieval-Augmented Generation) の精度向上のための施策や Amazon SageMaker の活用についてご紹介いただきました。 ソニーグループでは、様々な事業領域にわたる AI の民主化を積極的に推進しています。ソニーグループの全社員が AI とデータの良き使い手となり、AI のビジネスへの適用を加速させることで、クリエイティビティと生産性向上の両立を狙っています。 AI の民主化を実現するため、ソニーグループでは主に Enterprise LLM と Playground という 2 つのソリューションを提供しています。Enterprise LLM はビジネスにおける安全な生成 AI 活用を可能にするプラットフォームであり、Playground はより実践的なビジネス適用を支援する環境です。これらのソリューションを通じて、ソニーグループは従業員が生成 AI を日常的なビジネス活動に取り入れやすい環境を整備しています。 Enterprise LLM のアーキテクチャは 130 以上のモデルへのアクセス、ローコード・ノーコードでエージェントを作成可能なワークスペース、カスタムデータパイプライン、外部検索 API などから成り、ソニーグループでの AI 活用を支えています。ソニーグループでの AI 活用において、ソニーグループ内の専門用語の理解は重要です。RAG の検索精度向上のために埋め込みモデルの Fine-tuning を検証しており、 Amazon SageMaker notebook instance を活用することでマネージドな Fine-tuning ジョブの実行が可能で、検証プロセス全体が数時間程度で完了できことが紹介されました。また、推論エンドポイントには Amazon SageMaker Serverless Inference を採用し、プロビジョニングされた同時実行を活用することでコールドスタートを最小限に抑えながらコストも削減することに成功しています。 また、Amazon SageMaker により、幅広いユースケースに対応可能な多様なモデルの提供や、Amazon SageMaker Unified Studio によるローコード・ノーコードでの生成 AI アプリケーション構築が可能です。将来的には SLM (Small Language Model) の進化により生成 AI のエッジ展開が予想されますが、その際にも Amazon SageMaker でのカスタムモデル構築が重要な役割を果たすことが期待されています。 8. データからAIをつなぐオールインワンプラットフォーム「データレイクハウス」とAmazon SageMaker（株式会社 NTTデータ様） 最後のセッションとして、株式会社 NTT データより、”データからAIをつなぐオールインワンプラットフォーム「データレイクハウス」と Amazon SageMaker” と題した発表がありました。 まずはじめに、オールインワンプラットフォームが必要とされるようになった背景について説明がありました。従来型のビルディングブロックによるデータ分析基盤では、利用するサービスの数が増え複雑化し、学習コストや運用負荷、データの分散管理といった課題が顕在化しています。そのため、あらゆるデータを一か所で管理できるデータレイクハウスアーキテクチャを持ち、複数のユースケースに対応した機能がオールインワンで提供されるデータプラットフォームが必要になってきています。これが次世代の Amazon SageMaker です。これまで各サービス個別で提供していた UI や資材管理を一元化する Unified Studio、複数サービス横断でデータの探索をしたり、一元的なガバナンス・セキュリティを提供する Catalog、データを Open Table Format で一元管理するレイクハウスアーキテクチャで構成されています。 上記を踏まえる形で、次世代の Amazon SageMaker について NTT データからの視点で解説がありました。次世代の Amazon SageMaker は多様なユースケースに対応するデータ・アナリティクス・AI サービスを統合し、オールインワンプラットフォーム化することで、よりデータ・AI を管理・活用しやすくする仕組みです。本プラットフォームは、データレイクハウスアーキテクチャを採用し、Amazon S3 上のデータを管理するだけでなく、Amazon Redshift のマネージドストレージを Apache Iceberg 互換の API で統合することができます。また、 Amazon DataZone を内包する Amazon SageMaker Catalog にて横断的なデータだけではなく AI モデルを管理し、ガバナンス・セキュリティをかけることができます。そして、最後に、AWS が持つアナリティクス・機械学習・生成 AI の多様なサービスを、Amazon SageMaker Unified Studio という、一元的なエントリーポイントで生産性高くデータと AI、アプリの開発を行うことができます。 最後に生成 AI 時代のデータ活用組織のあり方について説明されました。AI エージェントシステムの開発には、データ・AI・生成AI・アプリの要素が必要であり、これまで説明してきたオールインワンプラットフォームはすべての要素が含まれており、最適です。ただ、ツールがオールインワンプラットフォームである以上、組織側もオールインワンになる必要があります。すなわち、データエンジニア・データサイエンティスト・生成 AI エンジニア、アプリエンジニアがいかにサイロ化を防ぎ協力し合えるかが重要です。NTT データも例外ではなく、組織の壁を超える取り組みを行っているものの、その難しさに直面しています。そのためには、より広い視点から AI システムを俯瞰するアーキテクトのような職種も必要になってくるのではないでしょうか。NTT データでは、オールインワンプラットフォームの考え方や AI システムの全体像を理解している、このスーパーマンを育成し、お客様をご支援できるように尽力していると述べ、発表を締めくくりました。 まとめ 「Amazon SageMaker Roadshow –Japan」と題した本セミナーでは、近年注目されているデータと AI の統合というテーマに関連する、多様な観点を含むセッションが盛り沢山となりました。本セミナーにて紹介された AWS サービスにご興味ある場合は無料で個別相談会を開催しております。皆様からのお申込みをお待ちしております。 お申込みリンク 本ブログは、ソリューションアーキテクトの大薗が作成しました。

ゲーム業界は今、かつてない変革期を迎えています。モバイルゲームの普及、クロスプラットフォーム化、そしてメタバースの概念拡大など、従来のゲーム開発に求められる技術スタックでは対応しきれない課題や知識需要が次々と生まれています。特に、大規模なマルチプレイヤーオンラインゲームの開発においては、スケーラブルなサーバーサイド技術への需要が急速に高まっています。 しかし、こうした技術需要に対して、ゲーム開発に特化したサーバーサイド技術を持つプログラマーの育成には課題が山積しているのが現状です。多くのゲームプログラマーはクライアントサイドの開発に特化しており、サーバーサイド技術への理解が十分とは言えません。従来の Web アプリケーション開発とは異なる、リアルタイム性やスケーラビリティ、グローバル展開といったゲーム特有の要件、さらには可用性・レジリエンシーを確保した堅牢なシステム設計に対応できるプログラマーの育成が、業界の課題となっています。 ゲーム開発におけるクライアントサイド技術に加えて、サーバーサイド技術も身につけることで、ゲームプログラマーとしてのキャリアの可能性は大きく広がります。オンラインゲームの企画段階からアーキテクチャ設計に関わることができ、技術的制約を考慮した企画提案や、運用を見据えた実装が可能になります。 このような背景から、 株式会社コーエーテクモゲームス (以下、コーエーテクモゲームス) と、Amazon Web Services Japan は共同で、2025 年度新卒ゲームプログラマー向けに、次世代のゲームプログラマーを育成する「ゲームサーバー開発研修プログラム」を実施しました。その取り組みをご紹介します。 ゲームサーバー開発研修プログラムの設計 オンラインゲーム開発・運営では、ゲーム開発スキルに加えて、以下のネットワーク関連スキルの習得が不可欠です： サーバーサイド基盤技術：Linux、TCP/IP、HTTP/HTTPS プロトコル データベース設計：RDB、NoSQL、分散データベース リアルタイム通信：UDP、TCP ソケットを活用したゲーム通信プロトコル 分散システム設計：負荷分散、可用性・レジリエンシー対応 クラウドアーキテクチャ：AWS サービス群の適切な活用と組み合わせ 新卒ゲームプログラマーがこれらのスキルを効率よく身につけられるよう、コーエーテクモゲームスと協力して、ゲームサーバー開発の研修プログラムを作り上げました。 また、この研修では、 「オンラインゲームがどのような仕組みで動いているのかを理解し、それを他の人とわかりやすく話し合えるようになること」 を目標に掲げています。プログラミングスキルやネットワーク関連スキルを習得することはもちろん大切ですが、それだけではありません。習得した知識を使って、オンラインゲームの仕組み全体を理解し、チームメンバーや企画部門、運営チームなど、さまざまな立場のスタッフと技術的な意見交換ができるようになることに期待しています。その結果、企画段階から「この機能のトレードオフは性能面でどうか」といった技術的な観点での提案ができたり、「将来の運用負荷を考慮したシステム設計」ができる。そんな幅広い視点を持つゲームプログラマーを育成することでオンラインゲーム開発力を高めたいと考えています。 この目標を達成するための、新卒ゲームプログラマー向けの研修は以下の方針で行いました。 1. 段階的スキル構築 ：基礎から応用まで無理のない学習曲線を設定 2. ゲーム開発に即した学習 ：汎用的なWebアプリではなく、ゲーム開発の文脈で技術を習得 3. 実践重視 ：座学・ハンズオン・グループワーク・確認テストを効果的に組み合わせ 4. チーム開発体験 ：個人学習に加え、グループ内のディスカッションや他グループのプレゼンテーションを通じた学びを得る ゲームサーバー開発研修プログラムの実装 研修プログラムは5日間の集中プログラムとして行われ、具体的には以下の技術要素を実践的に学習しました。本研修ではオンラインゲームの主要機能 (ギルド作成・ギルド参加・ギルド内でのプレイヤー間メッセージ送信)を題材に、データベース設計から Linux サーバーの操作、 Web API とリアルタイムサーバーのソフトウェアを一通り開発することができ、オンラインゲームにおけるサーバーサイド開発を体験することができるカリキュラムとして実装しています。 1日目: データベース リレーショナルデータベースを活用したゲームデータ設計の基本概念 ゲームデータに対する SQL 操作 テーブル設計グループワーク 2日目: Linuxサーバー・TCP/IP Amazon EC2 インスタンスでの Linux OS 基本操作 パフォーマンス監視、プロセス管理、ログ分析 TCP/IP プロトコルスタック、パケット解析 3日目: ネットワークプログラミング① HTTP プロトコルの理解 PHP を用いた Web API の実装 Web API の設計グループワーク 4日目: ネットワークプログラミング② ゲーム開発におけるネットワーク通信手段の理解 Node.js を用いたリアルタイムサーバーの実装 リアルタイムサーバーにおけるスケーラビリティの考慮 5日目: クラウドとアーキテクチャ設計 クラウドコンピューティングの基礎 要件定義からアーキテクチャ設計に至るプロセス ゲームサーバーのアーキテクチャ設計グループワーク データベース研修の様子 グループワークの実施 研修の一部では、3〜4名のチームに分かれて、オンラインゲームを題材に以下の3つの設計課題に取り組みました： データベース設計：プレイヤーデータ、ギルド、メッセージ情報の設計 Web API 設計：ゲームクライアント・サーバー間通信、ギルド参加、メッセージ送受信の実装 クラウドアーキテクチャ設計：AWS サービスを活用したシステム設計 グループワークで作成した API 設計の一例 グループワークの成果物のプレゼンテーションが行われている様子 グループワークの実施により、個人学習では得られない以下の効果が確認されました： 技術的議論を通じた理解の深化 ：チームメンバー間での技術的議論により、個人学習では気づかない設計上の考慮点や最適化手法を発見する場面が見られました。特に、データベース設計においては「なぜこの設計にするのか」という根拠を説明し合い、他チームからのフィードバックを得ることで、理解が大幅に深まりました。 多角的な視点の獲得 ： 同一の技術課題に対して複数のアプローチを検討する機会が生まれました。これにより、単一の解決策に固執せず、トレードオフを考慮した柔軟な思考力が身につきました。 研修の成果と評価 参加者フィードバック 研修終了後のアンケートでは、「オンラインゲームのアーキテクチャを大まかに理解できたこと」「サーバーサイド技術への苦手意識の改善」など参加者から多くの前向きな評価をいただきました。実施後の参加者向けのアンケートでも想像以上の高い満足度が確認できており、新卒ゲームプログラマーの成長に合わせた学習カリキュラムの提供を今後もコーエーテクモゲームスと共同で計画しています。 以下に、フリーコメントの一部を抜粋して紹介します： サーバーサイドの分野について漠然としていた理解が、より具体的でクリアなものになりました。特にデータベース設計やアーキテクチャ設計については、パズルのような面白さがあり、アイデアや深い思考が求められる点に強く関心を持つことができました。 以前はプログラミングでネットワーク関連に触れる機会がなく、今回の研修でサーバーの構築や運用の概要を知ることができ、大変勉強になりました。「ネットワークが難しそう」という印象から、「ネットワークをもっと知りたい」という意欲的な姿勢に変化することができました。 オンラインゲームに必要な技術や考え方、さらにインターネットを介することで重要性が増すセキュリティについて、実感を伴う形で理解を深めることができました。 技術理解度の測定 技術理解度の測定には、 AWS Skill Builder Trivia を活用し、ゲーム感覚で学習効果を測定できる仕組みを導入しました。AWS Skill Builder Triviaは、リアルタイムでマルチプレイヤー競争が可能なクイズプラットフォームです。本研修では、5日間の学習内容の復習を目的として、研修で扱った技術要素に関するカスタムクイズを作成し活用しました。 特に効果的だった点： 即座のフィードバック：クイズ結果により、理解不足の領域を即座に特定できる 競争要素：リアルタイムリーダーボードによる学習意欲の向上 インタラクティブな体験：QRコードでの簡単参加により、全員がスマートフォンから気軽に参加できる AWS Skill Builder Triviaを活用した復習セッションの様子 今後の展望 今後の展望について、執行役員 エンタテインメント事業部 シブサワ・コウブランド長 澤田 圭輔 氏と、エンタテインメント事業部シブサワ・コウブランド シニアリーダー 冨士田 智仁 氏に、今後の展望について話を伺いました。 「5 日間の集中研修で基礎技術を習得した後、チームでミニゲームを作成し、ネットワーク機能を実装することにしました。クライアント・サーバー間の連携や、実際のコーディング経験の重要性を、実践的なゲーム開発を通じて体験してもらうことで、より実用的なスキルが身につくと考えています。新卒社員にとって、サーバーサイド技術との連携を実感できる貴重な機会になると期待しています。そして、今回の研修で得た技術・経験を活かして開発現場で活躍いただけることに期待しています！」 澤田 圭輔 氏 「研修の成功を受け、より高度な技術領域への展開を計画しています。 AWS のクラスルームトレーニング を活用し、専門コースの受講を検討中です。また、研修参加者のスキルの可視化と継続的な学習モチベーションの維持のため、 AWS 認定資格 の取得を推奨しています。既に一部の社員が積極的に資格取得に取り組んでおり、社内の AWS 技術レベルの向上に大きく貢献しています。」 冨士田 智仁 氏 初級クラウド人材育成おすすめラーニングパス おわりに コーエーテクモゲームスと Amazon Web Services Japan の共同研修である「ゲームサーバー開発研修プログラム」は、ゲーム業界特有の技術要件に対応できる人材育成において、貴重な一歩を踏み出すことができました。 リアルタイム性、スケーラビリティ、グローバル対応、継続的サービス運用といったゲーム特有の要件を満たすために、クラウドの理解と実践的活用スキルを磨き続けることがゲーム開発者のキャリアの幅を大きく広げると期待しています。 また、今回の取り組みが、ゲーム業界全体での技術人材育成のモデルケースとなり、より多くの企業で同様のプログラムが展開されることを期待しています。AWS は今後も、ゲーム業界のイノベーションを支える人材育成に積極的に貢献していきます。 この記事は、アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 大西 啓太郎が執筆しました。

この記事は Camilla Panni, Greg Breen によって書かれた AWS IoT Greengrass nucleus lite – Revolutionizing edge computing on resource-constrained devices の日本語訳です。この記事は ソリューションアーキテクトの川崎が翻訳しました。 AWS IoT Greengrass は、オープンソースのエッジランタイムです。このクラウドサービスは、マルチプロセスアプリケーションを大規模に構築 / デプロイ / 管理することができ、IoT フリート全体の運用を支援します。 AWS IoT Greengrass は2020 年 12 月に V2 をリリースし、 nucleus として知られる Java エッジランタイムを導入しました。 2024 年 12 月の release 2.14.0  では、 C 言語で書かれた追加のエッジランタイムオプションである nucleus lite を追加しました。 AWS IoT Greengrass nucleus lite は、リソース制約のあるデバイスを対象とした軽量な オープンソース のエッジランタイムです。スマートホームハブ、スマートエネルギーメーター、スマートビークル、エッジ AI、ロボティクスなどの大量生産アプリケーション向けに、低コストのシングルボードコンピュータで AWS IoT Greengrass の機能を拡張できます。このブログでは、2つのエッジランタイムオプションの利点を説明し、ユースケースに最適なオプションを選択するための指針を提供します。 nucleus と nucleus lite の主な違い AWS IoT Greengrass nucleus lite は、AWS IoT Greengrass の V2 クラウドサービス API と  プロセス間通信 (IPC)  インターフェースと完全に互換性があります。これは、1 つまたは両方の実行時を対象としたコンポーネントを構築してデプロイできること、また、クラウドサービスを使用してデバイスフリートを管理し続けることができることを意味します。ただし、nucleus lite には、いくつかの重要な違いがあり、特定のユースケースに適しています。 メモリ使用量 AWS IoT Greengrass nucleus は、 ディスク スペース 256 MB 以上、RAM 96 MB 以上 が必要です。 ただし、オペレーティング システムやJava 仮想マシン (JVM)、アプリケーションが動作するため、 RAM は最低 512 MB を推奨しています。昨今では、1GB以上のRAMを搭載したデバイスは一般的になってきています。しかし、限られたリソースで動作を求められるデバイスも数多く存在しています。物理的リソース条件が厳しいデバイスでも利用できるよう nucleus lite が誕生しました。 nucleus lite は非常に小さなフットプリントで動作します。 RAM 5MB 、ストレージ (ディスク/フラッシュ)  5MB のみ必要です。また、JVM を必要とせず、C 標準ライブラリのみで動作可能です。 図 1: nucleus と nucleus lite のメモリフットプリントの比較 リソース制約のあるデバイス上でも AWS IoT Greengrass を利用する新しい選択肢が生ました。 静的メモリ割り当て AWS IoT Greengrass nucleus lite  ランタイムのメモリフットプリントは、初期設定とビルドプロセス中に決定されます。ランタイムが開始すると、 nucleus lite は一定量のメモリを割り当て、その後はその量が一定のままです。 つまり、 nucleus lite はリソース要件が予測可能で再現性があり、メモリリークのリスクが最小限に抑えられ、ガベージコレクションを行う言語に関連する非決定論的な待ち時間がなくなります。 メモリ使用量が変動するのは、デプロイした AWS IoT Greengrass コンポーネントや AWS IoT Greengrass 外で実行するプログラムによる動的メモリ割り当てのみです。 ディレクトリ構造 Nucleus lite は、Nucleus lite ランタイム、Greengrass コンポーネント、設定、ログをディスク上の異なる領域に分離します。組み込み Linux システムでは、これらの異なる要素は通常、異なるパーティションまたは異なるボリュームに保存できます。 例えば: nucleus lite ランタイムは、OS イメージの更新を可能にするため、A/B パーティション分割の一部として、読み取り専用パーティションに格納される可能性があります。 AWS IoT Greengrass のコンポーネントと設定は、アプリケーションが AWS IoT Greengrass のデプロイメントによって管理できるように、読み書き可能なパーティションまたはオーバーレイに格納される可能性があります。 ログファイルは、ルートボリュームの限られたフラッシュメモリの書き込みサイクルを消費しないように、一時パーティションまたは別の物理ボリュームに格納される可能性があります。 この分離により、スケールでデバイス製造のための golden イメージを構築するのに役立ちます。詳細については、 Manufacturing devices at scale with AWS IoT Greengrass golden images をご覧ください。 systemd との統合 systemd  は Linux システムで一般的に利用可能なシステムとサービス管理フレームワークで、AWS IoT Greengrass nucleus lite には必須です。 nucles lite をデバイスにインストールすると、 systemd サービスまたはデーモンの集合体  としてインストールされます。nucles lite は、デバイスに展開する AWS IoT Greengrass コンポーネントごとに個別の systemd サービスとしてインストールします。nucles lite は、デバイスの多数のフリートにまたがってスケールするクラウド管理の systemd として考えることができます。 nucleus lite とコンポーネントを systemd サービスとしてインストールしているため、systemd がシステムログを処理し、集中管理します。つまり、一般的な Linux システムツールを使用して、デバイスソフトウェアを監視、保守、デバッグできます。 nucleus と nucleus lite の選択 nucleus ランタイムと nucleus lite ランタイムの選択は、使用ケース、デバイスの制約、必要な機能、および OS によって異なります。次の表は、選択の目安を要約したものです。 nucleus 利用ケース nucleus lite 利用ケース オペレーティングシステムに Windows を使用したい、または systemd が含まれていない Linux ディストリビューションを使用したい場合 アプリケーションコンポーネントが Docker コンテナである場合 アプリケーションコンポーネントが Lambda 関数である場合 スクリプト言語または解釈型プログラミング言語を使ってアプリケーションコンポーネントを開発する場合 nucleus lite でまだサポートされていない機能 を使用したい場合 AWS IoT SiteWise ゲートウェイ を作成する場合 デバイスのメモリが制約されており、RAM が 512 MB 以下の場合 デバイスの CPU のクロック周波数が 1 GHz 未満の場合 組み込み Linux ディストリビューションを作成し、OS イメージの更新や A/B パーティションなどの機能をサポートするため、パーティションスキームを正確に制御する必要がある場合 マシン語にコンパイルされるプログラミング言語を使ってアプリケーションコンポーネントを開発する場合 ava が適さないコンプライアンス要件がある場合 静的メモリ割り当てを好む場合 表 1: nucleus と nucleus lite を選択する際の指針 表 1 の指示は規範ではなく、一般的なガイダンスです。たとえば、ユースケースのニーズに基づいて、ギガバイトの RAM を搭載したデバイスで nucleus lite を使用することができます。また、デバイスのリソースが十分にある場合は、スクリプト言語やインタプリタ型言語で書かれたコンポーネントを nucleus lite にデプロイすることもできます。 シナリオとユースケース ユースケース メモリとプロセシング能力が制限された低コストデバイス、そして慎重に選別された組み込み Linux ディストリビューションに適しているのが、リソース要件のハードルが低い nucleus lite です。こうしたデバイスには、スマートホーム、産業、自動車、スマートメーターなど、さまざまな分野があります。 組込みシステム nucleus lite は、ローンチ時から meta-aws project によって提供される組み込み Linux のサポートを含むことで、組み込みシステム開発者にとって大きな前進を示しています。このプロジェクトには、 サンプルレシピ が含まれており、AWS IoT Greengrass を OpenEmbedded または Yocto プロジェクトにビルドインすることができます。このプロジェクトの姉妹プロジェクト meta-aws-demos には、 RAUC を使った A/B アップデートのデモ など、AWS IoT Greengrass の数多くのデモが含まれています。 コンテナ化された軽量 AWS IoT Greengrass nucleus lite によるマルチテナンシーのサポート nucleus lite はフットプリントが小さいため、マルチテナント IoT デプロイに対して効果的なコンテナ化を実現できます。独自の AWS IoT Greengrass ランタイムと一体化した複数の分離アプリケーションを実行できます。 図 2: マルチテナントのコンテナ化 アーキテクチャの利点は次のとおりです: セキュリティを考慮した分離 : それぞれのコンテナ化されたインスタンスは、アプリケーション間の厳格な境界を維持します。 リソース最適化 : 軽量なフットプリントにより、制約された環境でも複数のコンテナをサポートできます。 独立した運用 : アプリケーションを個別に管理、デバッグ、更新できます。 柔軟なデプロイ : デバイスの機能に基づいて、さまざまなコンテナ化の戦略をサポートします。 実装のベストプラクティス nucleus lite を使用するには、コンポーネントを書き直す必要はありません。ただし、メモリ効率を最大化したい場合は、コンポーネントを最適化または書き換えることを選択できます。 nucleus lite を使用するにあたり、以下の重要な考慮事項を確認ください。 プラグインの互換性 プラグインコンポーネント は、Java 版 の nucleus ランタイムと密接に統合された特殊な Java コンポーネントです。これらのプラグインは nucleus lite ランタイムでは使用できません。 コンポーネント言語の考慮事項 カスタムコンポーネント用のプログラミング言語を選択する際は、各言語のインタープリターまたはランタイム環境が全体のメモリフットプリントに影響することを考慮する必要があります。Python のような言語を選択すると、nucleus lite のメモリ節約効果がある程度相殺されます。Java を選択する場合は、システムに JVM を導入する必要があります。 異なるシナリオ向けの推奨事項 nucleus から nucleus lite に移行する際、既存のコンポーネントはそのまま動作します。そのため、nucleus lite への移行が簡単になり、最適化の計画を立てている間も機能が維持されます。 新規に作成する場合: 最大の効率を得るために、重要なコンポーネントを書き換えることを検討してください。 C、C ++、Rust などのランタイムオーバーヘッドが最小限の言語を選んでください。 開発の労力とメモリ最適化のニーズのバランスをとってください。 メモリ容量の計画を立てる場合: メモリ計算では、すべてのランタイム依存関係を考慮してください。 nucleus lite のサイズだけでなく、システム全体のフットプリントを評価してください。 適切な場合はコンポーネントの統合を検討してください。 将来の展望と結論 今後、AWS IoT Greengrass nucleus lite を活用することで、エッジコンピューティングの実装を再構築できます。 リソース要件を大幅に削減することで、次のようなことが可能になります。 リソースの制限のあるデバイスに IoT 機能をデプロイ より広範なハードウェアでのエッジコンピューティングソリューションの実装 機能を維持しながら運用オーバーヘッドの削減 リソース要件に制限されていた新しい使用例の実現 開発者にとって、nucleus lite はエッジで革新的なことを行う新たな機会を提供します。リソース制約のあるデバイスでエッジコンピューティングが可能かどうかを気にする代わりに、ビジネス価値を生み出すソリューションの実装に集中できます。 この AWS IoT ポートフォリオの強化により、より幅広いデバイスやユースケースに対応する効率的かつスケーラブルな IoT ソリューションを構築するというコミットメントが示されました。 AWS IoT Greengrass nucleus lite を使用して IoT ソリューションの開発に向けて以下を検討ください。 詳細を理解する : AWS IoT Greengrass のドキュメント を参照してください。 nucleus lite を試す : インストールガイド または Getting Started チュートリアル に従って実験と開発を始めましょう。 専門家に質問 : 質問やガイダンスが必要な場合は、AWS IoT の専門家に相談してください。 コミュニティに参加 : AWS IoT コミュニティフォーラムで体験を共有したり、他のユーザーから学びましょう。 コントリビュート : オープンソースリポジトリ にコードを投稿してください。 _________________________________________________________________________________ 著者について Camilla Panni は、 Amazon Web Services のソリューションアーキテクトです。彼女は、イタリア全土の公共部門の顧客がクラウド導入の取り組みを加速するのを支援しています。自動化とIoTにおける彼女の技術的背景が、顧客が新興技術でイノベーションを起こすのを支援することへの情熱を後押ししています。   Greg Breen は、Amazon Web Services のシニア IoT スペシャリスト ソリューションアーキテクトです。オーストラリアを拠点とし、アジア太平洋地域全体の顧客がIoTソリューションを構築するのを支援しています。組み込みシステムにおける豊富な経験を持つ彼は、製品開発チームがデバイスを市場に投入するのを支援することに特に関心を持っています。

本記事は、2025 年 10 月 9 日に公開された Reimagine business intelligence: Amazon QuickSight evolves to Amazon Quick Suite を翻訳したものです。翻訳は Solutions Architect の守田凜々佳が担当しました。 ビジネスインテリジェンス (BI) の領域は、変革期を迎えています。データ活用が進み、AI が日常生活におけるデータとの関わり方を大きく変えている今、顧客は重要な岐路に立っています。つまり、ビジネスを加速させるために AI の可能性を受け入れる必要がありますが、それを慎重かつ安全に行わなければなりません。多くの顧客が、いかに実質的な価値を生み出す形で AI を業務に統合するか、という課題に直面しています。構造化データの可視化とレポート作成を主な目的とした従来の BI ソリューションは、もはやこの新時代には十分ではありません。 顧客は 3 つの課題に直面しています。データの発見、分析、アクションの間で広がりつつあるギャップを埋めることができるソリューション、具体的なビジネス成果をもたらす形での AI 活用、さらにエンタープライズレベルのセキュリティとガバナンスを維持しながら組織全体のユーザーがアクセスできるソリューション、が必要です。多くの組織は、強力な AI 機能と、既存のデータやプロセスに適合する実用的で安全な実装との間で、適切なバランスを見つけることに苦闘しています。 本日、Amazon QuickSight が Amazon Quick Suite へと進化することを発表できることを嬉しく思います。これは、組織内の全メンバーが包括的なビジネスインサイトを容易に利用できるようにする大きな前進です。この進化は、BI の可能性を広げ、AI エージェントがユーザーと協働しながら複雑な質問への回答、詳細な調査、定型業務の自動化を行う統合された体験を実現します。またその際に企業が期待するセキュリティ、信頼性、ガバナンスを維持します。Quick Suite は、AI 時代における BI の再解釈を行う私たちのビジョンを表しており、組織がより良い意思決定をより迅速に行い、それに基づいて行動できるように支援します。 従来の BI 機能 (現在は Quick Sight と呼ばれています) に加えて、Quick Suite は複数の AI を活用した機能を導入しています： Quick Research – 企業内外のデータソースから、引用付きの包括的なインサイトを提供します Quick Flows – 自然言語でワークフローオートメーションを作成および共有します Quick Automate – 複雑な多段階のビジネスプロセスを処理します Quick Index – 企業のすべてのドキュメントとデータを共有ナレッジベースとして提供します これらの機能は、自然言語インターフェースの Quick chat を通じてアクセスでき、Quick spaces を通じて各チーム向けにカスタマイズすることができます。この統合環境では、ユーザーはデータ分析、詳細な調査、プロセスの自動化まで、全ての作業を同一アプリケーション内でシームレスに実行することができ、さらにエンタープライズレベルののセキュリティとガバナンスを維持できます。 なぜこの進化が重要なのか 冒頭で述べた企業が直面する 3 つの重要な課題 (データとアクションのギャップの解消、AI の実用的な活用、セキュリティの維持) に対して、Quick Suite は、企業がデータと AI を活用する方法を変革する包括的なソリューションを提供します。 あらゆるデータを統合するインテリジェンス – 従来の BI ソリューションは、指標と数値の活用に限定されており、ドキュメント、メール、エンタープライズアプリケーションに含まれる価値あるインサイトが活用できていませんでした。これにより、データの発見と有意義なインサイトの間に大きなギャップが生じていました。Quick Suite は、エンタープライズシステム、データベース、データレイク、チームの知見、リアルタイムのウェブインサイトなど、意思決定に必要なすべてのソースからのデータアクセスを統合することで、このギャップを解消します。経営者は、財務データベース、カスタマーフィードバックのメール、サポートチケット、市場調査文書にまたがる質問を行い、数秒で完全な回答を得ることができます。データの専門家は、利用可能なソースからコンテキストを取り込んだ高度な可視化と分析を作成し、より豊かで実用的なインサイトをステークホルダーに提供できます。 実用的な AI イノベーション – 企業が必要としているのは、単なる技術的な目新しさではなく、具体的なビジネス成果をもたらす AI です。Quick Suite は、強力な調査、分析、自動化エージェントを通じてこれを実現します。Quick Research は、社内データ、公開情報、専門データセットから情報を統合し、これまで数週間かかっていた包括的で引用付きのインサイト提供を数時間で実現します。Quick Flows を活用すると、議事録からアクション可能なタスクを作成する、最新のインサイトを含む週次レポートを自動で生成する、カスタマーサポートプロセスを効率化するなど、自然言語を使用して AI を活用したワークフローを作成できます。これらのワークフローを素早く共有することで、組織全体の生産性向上を実現できます。 セキュアでアクセスしやすい自然言語での体験 – Quick Suite は、エンタープライズレベルのセキュリティとガバナンスを維持しながら、AI へのアクセスを民主化します。強力なチャットインターフェースにより、自然言語での会話を通じて各機能にアクセスできます。組織は、技術的な質問に対応するトラブルシューティングアシスタントや、従業員に社内手続きをナビゲートするためのポリシーガイドなど、特定のニーズに合わせたカスタム AI エージェントを作成できます。これらのエージェントは、ドメインの専門知識と関連データソースを組み合わせ、必要とするすべての人が専門知識にアクセスできるようにします。各エージェントは、特定のペルソナ、データアクセス権、行動ガイドラインでカスタマイズでき、組織全体で一貫性のある、コンプライアンスに準拠した対話を実現します。 変更されない点 Quick Suite は強力な新機能を導入しますが、既存の BI 機能は変更なく維持されます。この進化は、現在の運用を妨げることなく、お客様が信頼する基盤の上に構築されています。 従来の QuickSight 環境は、ダッシュボード、データセット、分析を含めて、すべてがそのまま維持されます。データ接続、セキュリティ管理、ユーザー権限もすべて変更なく継続されます。既存の API 連携も以前と同様に機能し、データの移行も必要ありません。重要な点として、SOC、HIPAA、ISO 27001、ISO 27019、ISO 27018、ISO 9001、GDPR、FedRAMP を含む既存のコンプライアンス認証と認定が、引き続き有効です。Quick Suite は QuickSight の既存のコンプライアンス体制を継承します。また、データのプライバシーとセキュリティに対する AWS のコミットメントを強調したいと思います。私たちは、お客様のコンテンツをモデルのトレーニングに使用することはなく、新しいモデルプロバイダーも導入していません。お客様のデータは、信頼できるエンタープライズグレードのセキュリティとガバナンス管理により、お客様のものとして維持されます。このシームレスな移行により、ビジネスの継続性を維持しながら、お客様のペースで新機能を採用することができます。 リージョンの提供状況 Quick Suite は、すべてのお客様にスムーズな移行を提供するよう、段階的なアプローチで展開します。2025 年 10 月 9 日より、世界中の QuickSight のお客様は、新しい Quick Suite UI とブランディングが表示されます。新機能は、US East (N. Virginia)、US West (Oregon)、Europe (Dublin)、Asia Pacific (Sydney) でご利用いただけます。その他の AWS リージョンのお客様は、新しい Quick Suite インターフェイスが表示されますが、既存の BI 機能のみにアクセス可能な状態が維持されます。 新しいエクスペリエンスの操作方法 Quick Suite のインターフェースは、使い慣れた操作性を維持しながら強力な新機能を導入できるよう、慎重に再設計されました。このセクションでは、Pro ユーザー (Admin Pro、Author Pro、Reader Pro) と Author (Admin 含む) 向けの主要な変更点について説明します。 Quick chat が Quick Suite のホームページに目立つように配置され、Quick Suite の機能にすぐにアクセスできるようになっています。また、ダッシュボードから主要なビジュアルをホームページにピン留めできる新機能が追加され、パーソナライズされたレコメンデーションや最近アクセスしたアイテムにも引き続き簡単にアクセスできます。基本的な Reader ($3) の体験は変更されていませんが、重要なメトリクスをホームページにピン留めできる機能が追加され、最も重要な情報を追跡しやすくなりました。 従来の BI 機能は、ナビゲーションペインの Quick Sight の下に整理されています。コンテンツへの整理されたアクセスのための マイフォルダ と 共有フォルダ 、 ダッシュボード 、 ストーリー (旧 データストーリー )、 分析 、 データセット などです。 お気に入り は、素早くアクセスできるようにトップレベルに残され、グローバル検索は左上に配置されました。また、 Quick Research 、 Quick Flows 、 Quick Automate 、 Connections は、ナビゲーションペインの専用セクションからアクセスできます。 以下のスクリーンショットは、以前の QuickSight ナビゲーションペインと強化された Quick Suite ナビゲーションペインを比較したものです。 価値の向上 既存のお客様にとってのシンプルさを維持しながら、より多くの価値を提供するため、料金体系が変更されます。 お客様は、価格の引き下げと機能アクセスの拡充のメリットを得ることができます: Author Pro の料金が月額 50 ドルから 40 ドルに値下げされ、Author Pro ユーザーは Quick Suite の Enterprise ユーザーの機能 にアクセスできるようになりました Reader Pro (月額 20 ドル) ユーザーは Quick Suite の Professional ユーザーの機能 にアクセスできるようになりました 現在の Author および Admin ユーザーは、2026 年 4 月 30 日までプロモーションとして Quick Suite の Enterprise ユーザーの機能にアクセスできます Reader (3 ドル) および Author (24 ドル) の料金は変更ありません 専用インフラストラクチャ料金: 既存の月額 250 ドルのインフラストラクチャ料金は、引き続き以下のアカウントにのみ適用されます： Pro ユーザー (20 ドル/40 ドルプラン) が 1 つ以上存在 Topics または Dashboard Q&A がアクティブ 2025 年 10 月 9 日以降の新規 Pro ユーザーまたは Q&A 有効化を行ったアカウントについては、2025 年 12 月 31 日までプロモーションとして本料金が免除されます 機能導入の完全なコントロール 組織が AI 機能の採用を正確にコントロールする必要があることを理解しています。管理者は、カスタムアクセス許可を使用してアカウント、ロール、ユーザーレベルで機能の有効化や無効化を行い、新機能を導入しながら既存のセキュリティポリシーを維持し、API を通じて複数のアカウントに一貫したコントロールを適用できます。 Quick Suite は、お客様のペースで導入を管理できる柔軟性を提供します。すべての機能を直ちに有効化することも、異なるユーザーグループに段階的に導入するかを選択ことも可能です。 埋め込み分析 BI の埋め込み機能をご利用の場合、主要な機能は変更されません。埋め込み機能、API、および統合機能は、これまでと同様に動作し、既存の実装に変更を加える必要はありません。ただし Quick Suite に合わせて、フッターが「Powered by Amazon Quick Suite」に更新、カラースキームが青色から紫色に変更、標準的な配置に Quick Suite ロゴが表示されるというビジュアルの更新が行われます。 ブランドカスタマイズ機能をご利用の場合、カスタムスタイルは引き続き製品のデフォルトの外観を上書きします。QuickSight アプリケーション要素について現在の青色のカラースキームを維持したい場合は、アカウントレベルで設定されたブランドカスタマイズ、公開時のテーマカスタマイズの適用、SDK を使用した埋め込み呼び出しでの動的な適用、のいずれかの方法で実現できます。これにより、埋め込み分析においてエンドユーザーに一貫した体験を継続して提供できます。 リソースとサポート お客様がスムーズに移行できるよう、私たちは全力でサポートいたします。以下のリソースをご利用いただけます： Amazon Quick Suite User Guide における詳細なドキュメント AWS Support を通じたテクニカルサポート AWS アカウントチームによるコンサルテーション 今後の展望 Quick Suite への進化は、意思決定とビジネス成果を導くために必要なコンテキストを提供する、新しい働き方を実現します。AI が組織でのインサイト発見と戦略的な意思決定の方法を変革し続ける中、Quick Suite は安全で実用的な前進の道筋を提供します。私たちは、お客様とこの旅を共にし、これらの機能を活用して組織全体の価値を引き出していく様子を見ることを楽しみにしています。 BI の未来を体験する準備はできましたか？ Quick Suite の 30 日間無料トライアルを利用して、最大 25 ユーザーまでその機能を試すことができます。機能や料金について詳しく知るには Amazon Quick Suite をご覧いただくか、Quick Suite がお客様の組織のデータドリブンな意思決定をどのように変革できるかについて、AWS アカウントチームにお問い合わせください。 著者について Sindhu Chandra は、AWS の Amazon Quick Suite のシニアプロダクトマーケティングマネージャーで、マーケティングとテクノロジーの分野で 10 年以上の経験を持っています。現職に就く前は、Amazon、Uber、Google などのテクノロジー企業でマーケティングの職務を歴任し、クロスチャネルマーケティング戦略を主導してきました。B2B マーケティングをより親しみやすくし、インクルーシブなマーケティング施策を推進することに情熱を注いでいます。仕事以外では、愛犬と遊んだり、さまざまな産地のコーヒーを淹れたりすることを楽しんでいます。

10 月 8 日は、汎用 M インスタンスファミリーに最近追加された Amazon Elastic Compute Cloud (Amazon EC2) M8a インスタンスの提供開始についてお知らせしたいと思います。これらのインスタンスは、 第 5 世代 AMD EPYC (コードネーム「Turin」) プロセッサ を搭載しており、最大周波数は 4.5 GHz です。お客様は、M7a インスタンスよりも最大 30% 高いパフォーマンスと最大 19% 優れたコストパフォーマンスを期待できます。これらのインスタンスは、より広いメモリ帯域幅、改善されたネットワークスループットとストレージスループット、幅広い汎用ワークロードに対応する柔軟な設定オプションも提供します。 M8a の改善点 M8a インスタンスは、vCPU あたりのパフォーマンスが M7a インスタンスよりも最大 30% 優れているため、金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバー、シミュレーションモデリング、中規模のデータストア、アプリケーション開発環境、キャッシュフリートなど、高パフォーマンスと高スループットのメリットを活用する必要がある用途に最適です。 M7a インスタンスよりも 45% 広いメモリ帯域幅を提供し、インメモリデータベース、分散キャッシュ、リアルタイム分析を高速化します。 I/O 要件の高いワークロードには、M8a インスタンスが最大 75 Gbps のネットワーク帯域幅と 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供します。これは、前世代から 50% の向上です。これらの機能強化は、迅速なデータ転送と低レイテンシーのネットワーク通信が不可欠な最新のアプリケーションをサポートします。 M8a インスタンスの各 vCPU は物理的な CPU コアに対応するものです。つまり、同時マルチスレッディング (SMT) は行われません。アプリケーションベンチマークでは、M7a インスタンスと比較した M8a インスタンスのパフォーマンスが、 GroovyJVM の場合に最大 60%、 Cassandra の場合に最大 39% 高速になっています。 M8a インスタンスは、ネットワーク帯域幅と EBS 帯域幅間でリソースを割り当てる柔軟性を提供する インスタンス帯域幅設定 (IBC) をサポートしています。IBC は、ネットワーク帯域幅または EBS 帯域幅を最大 25% スケールし、データベースパフォーマンス、クエリ処理、ロギングの速度を向上させる柔軟性をお客様に提供します。 M8a は、10 個の仮想化サイズと 2 つのベアメタルオプション ( metal-24xl と metal-48xl ) で利用でき、小規模なアプリケーションから大規模なエンタープライズワークロードにスケールするデプロイ選択肢を提供します。これらすべての改善は、すべてのインスタンスサイズ全体で低い仮想化オーバーヘッド、一貫的なパフォーマンス、高度なセキュリティを実現する AWS Nitro System を基盤としています。 これらのインスタンスは、機能の I/O をオフロードして加速する最新の第 6 世代 AWS Nitro Card を使用して構築されており、全体的なシステムパフォーマンスを向上させます。 M8a インスタンスには複数のサイズがあり、最大で 192 個の vCPU と 768 GiB の RAM を備えています。詳しい仕様は次のとおりです。 M8a vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 最大 12.5 最大 10 large 2 8 最大 12.5 最大 10 xlarge 4 16 最大 12.5 最大 10 2xlarge 8 32 最大 15 最大 10 4xlarge 16 64 最大 15 最大 10 8xlarge 32 128 15 10 12xlarge 48 192 22.5 15 16xlarge 64 256 30 20 24xlarge 96 384 40 30 48xlarge 192 768 75 60 metal-24xl 96 384 40 30 metal-48xl 192 768 75 60 インスタンスのサイズと仕様の完全なリストについては、 Amazon EC2 M8a インスタンスページ を参照してください。 M8a インスタンスを使用する状況 M8a は、コンピューティング、メモリ、ネットワークのバランスを取る必要がある汎用アプリケーションに最適です。M8a インスタンスは、予測可能なパフォーマンスと効率的なスケーリングが重要となる、ウェブやアプリケーションのホスティング、マイクロサービスアーキテクチャ、データベースに理想的なインスタンスです。 これらのインスタンスは SAP 認定を受けており、金融アプリケーションやエンタープライズリソースプランニング (ERP) システムなどのエンタープライズワークロードにも最適です。コスト効率性と柔軟性が求められる開発環境やテスト環境に加えて、インメモリキャッシュや顧客関係管理 (CRM) でも同様の効果を発揮します。こうした汎用性を備えた M8a は、お客様がコストパフォーマンスを向上できるように支援しながら、幅広いワークロードをサポートします。 今すぐご利用いただけます Amazon EC2 M8a インスタンスは、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (スペイン) の各 AWS リージョン で 10 月 8 日からご利用いただけます。 M8a インスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス としての購入が可能です。M8a インスタンスは 専有ホスト でも利用できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 詳細については、 Amazon EC2 M8i インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Betty 原文は こちら です。

Amazon Elastic Compute Cloud (Amazon EC2) メモリ最適化 R8i および R8i-flex インスタンス 、ならびに汎用 M8i および M8i-flex インスタンス のリリースに続き、カスタムインテル Xeon 6 プロセッサを搭載し、持続的なオールコア 3.9 GHz ターボ周波数と 2:1 のメモリ対 vCPU 比を備えた、AWS でのみ利用可能なコンピューティング最適化 C8i および C8i-flex インスタンス の一般提供の開始をお知らせします。これらのインスタンスは、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 C8i および C8i-flex インスタンスは、 C7i および C7i-flex インスタンス と比較して、最大 15% 優れた料金パフォーマンスと 2.5 倍のメモリ帯域幅を提供します。C8i および C8i-flex インスタンスは、C7i および C7i-flex インスタンスと比較して、NGINX ウェブアプリケーションで最大 60%、AI 深層学習レコメンデーションモデルで最大 40%、Memcached ストアで 35% 高速です。 C8i および C8i-flex インスタンスは、ウェブサーバー、キャッシュ、Apache.Kafka、ElasticSearch、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高度にスケーラブルなマルチプレイヤーゲーム、動画エンコーディングなど、コンピューティングを多用するワークロードの実行に最適です。 他の第 8 世代インスタンスと同様、これらのインスタンスは新しい第 6 世代 AWS Nitro Card を使用しており、前世代のインスタンスと比較してネットワークと Amazon Elastic Block Storage (Amazon EBS) の帯域幅が最大 2 倍増加しています。また、ネットワークと Amazon EBS 帯域幅の間で 25% の割り当て調整を行う帯域幅設定にも対応しており、データベースのパフォーマンス、クエリ処理、ログ記録速度が向上します。 C8i インスタンス C8i インスタンスは、基盤となる物理ハードウェアへの専用アクセスを提供するベアメタルインスタンスを含め、最大 384 個の vCPU と 768 TB のメモリを提供します。これらのインスタンスは、CPU ベースの推論や、継続的に最大インスタンスサイズまたは高い CPU を必要とする動画ストリーミングなど、コンピューティングを多用するワークロードの実行に役立ちます。 C8i インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i.large 2 4 最大 12.5 最大 10 c8i.xlarge 4 8 最大 12.5 最大 10 c8i.2xlarge 8 16 最大 15 最大 10 c8i.4xlarge 16 32 最大 15 最大 10 c8i.8xlarge 32 64 15 10 c8i.12xlarge 48 96 22.5 15 c8i.16xlarge 64 128 30 20 c8i.24xlarge 96 192 40 30 c8i.32xlarge 128 256 50 40 c8i.48xlarge 192 384 75 60 c8i.96xlarge 384 768 100 80 c8i.metal-48xl 192 384 75 60 c8i.metal-96xl 384 768 100 80 C8i-flex インスタンス C8i-flex インスタンスは、C8i インスタンスの低コスト版であり、5% 低い料金で 5% 優れた料金パフォーマンスを実現しています。これらのインスタンスは、最新世代のパフォーマンスから恩恵を享受できるにかかわらず、すべてのコンピューティングリソースを完全に活用していないワークロード向けに設計されています。これらのインスタンスは、95% の確率で最大 CPU パフォーマンスを発揮できます。 C8i-flex インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i-flex.large 2 4 最大 12.5 最大 10 c8i-flex.xlarge 4 8 最大 12.5 最大 10 c8i-flex.2xlarge 8 16 最大 15 最大 10 c8i-flex.4xlarge 16 32 最大 15 最大 10 c8i-flex.8xlarge 32 64 最大 15 最大 10 c8i-flex.12xlarge 48 96 最大 22.5 最大 15 c8i-flex.16xlarge 64 128 最大 30 最大 20 現在、旧世代のコンピューティング最適化インスタンスを使用している場合は、アプリケーションやワークロードに変更を加えることなく、C8i-flex インスタンスを採用できます。 今すぐご利用いただけます Amazon EC2 C8i および C8i-flex インスタンスは、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (スペイン) の AWS リージョン でご利用いただけます。C8i および C8i-flex インスタンスは、 オンデマンド 、 Savings Plan 、 スポットインスタンス として購入できます。C8i インスタンスは、 ハードウェア専有インスタンス および 専有ホスト での利用も可能です。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で C8i および C8i-flex インスタンスをお試しください。詳細については、 Amazon EC2 C8i インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

10 月 6 日より、独自の AWS Key Management Service (AWS KMS) キーを使用して、 AWS IAM アイデンティティセンター の組織インスタンスに保存されているユーザー属性やグループ属性などの ID データを暗号化できるようになりました。 規制の厳しい業界で事業を展開している多くの組織は、暗号化キー管理を完全に制御する必要があります。アイデンティティセンターでは既に AWS 所有キーを使用して保管中のデータを暗号化していますが、監査やコンプライアンスのために独自の暗号化キーを管理する必要があるお客様もいます。 このリリースにより、 カスタマーマネージド KMS キー (CMK) を使用して、アイデンティティセンターの保管中の ID データを暗号化できるようになりました。CMK を使用すると、作成、ローテーション、削除など、キーのライフサイクルを完全に制御できます。 AWS Key Management Service (AWS KMS) キーポリシーと IAM ポリシーを使用して、キーへのきめ細かなアクセスコントロールを設定できるため、認可されたプリンシパルのみが暗号化されたデータにアクセスできるようにするのに役立ちます。起動時には、CMK は IAM アイデンティティセンターインスタンスと同じ AWS アカウントおよびリージョンに存在する必要があります。アイデンティティセンターと KMS の統合により、キーの使用状況を監査するための詳細な AWS CloudTrail ログが提供され、規制コンプライアンス要件を遵守するのに役立ちます。 アイデンティティセンターは、デプロイのニーズに合わせて、単一リージョンキーとマルチリージョンキーの両方をサポートしています。アイデンティティセンターインスタンスは現在単一のリージョンにのみデプロイできますが、会社のポリシーで単一リージョンキーに制限されていない限り、マルチリージョン AWS KMS キーを使用することをお勧めします。マルチリージョンキーは、各リージョンで独立したキーインフラストラクチャを維持しながら、リージョン間で一貫したキーマテリアルを提供します。これにより、暗号化戦略の柔軟性が高まり、デプロイが将来の変化にも対応できるようにするのに役立ちます。 始めましょう CMK を使用してアイデンティティセンターの組織インスタンスの ID データを暗号化するとします。私の組織では、アイデンティティセンターを使用して、 AWS マネージドアプリケーション ( Amazon Q Business や Amazon Athena など) へのアクセスを従業員に付与しています。 現時点では、一部の AWS マネージドアプリケーションは、カスタマーマネージド KMS キーで設定されたアイデンティティセンターでは使用できません。互換性のあるアプリケーションのリストは常に更新されるため、「 AWS managed applications that you can use with Identity Center 」で最新情報をご覧ください。 大まかなプロセスでは、まず AWS KMS で対称カスタマーマネージドキー (CMK) を作成する必要があります。このキーは、暗号化および復号オペレーション用に設定する必要があります。次に、アイデンティティセンター、AWS マネージドアプリケーション、管理者、およびアイデンティティセンターと IAM アイデンティティセンターサービス API にアクセスする必要がある他のプリンシパルにアクセスを付与するキーポリシーを設定します。キーにはポリシーを、IAM プリンシパルには IAM ポリシーを、それぞれアイデンティティセンターの使用方法に応じて定義する必要があります。 サービスドキュメントには、極めて一般的なユースケースをカバーするのに役立つ詳細が記載されています 。 このデモは 3 つのパートに分かれています。まず、AWS KMS でカスタマーマネージドキーを作成し、アイデンティティセンターと AWS マネージドアプリケーションがそのキーを使用することを認可する許可を設定します。次に、AWS アプリケーション管理者など、別の AWS アカウントのキーを使用するプリンシパルの IAM ポリシーを更新します。最後に、アイデンティティセンターがそのキーを使用するように設定します。 パート 1: キーを作成して、許可を定義する まず、AWS KMS で新しい CMK を作成しましょう。 キーは、アイデンティティセンターインスタンスと同じ AWS リージョンおよび AWS アカウントに存在する必要があります。AWS Organizations 内の組織の管理アカウントに、アイデンティティセンターインスタンスとキーを作成する必要があります。 アイデンティティセンターインスタンスと同じリージョンで AWS Key Management Service (AWS KMS) コンソールに移動し、 [キーを作成] を選択します。これでキー作成ウィザードが起動します。 [ステップ 1 – キーを設定する] で、キータイプとして、[対称] (暗号化と復号の両方に使用される単一のキー) または [非対称] (暗号化/復号と署名/検証用のパブリックキーとプライベートキーのペア) を選択します。アイデンティティセンターでは、保管中の暗号化に対称キーが必要です。私は [対称] を選択します。 キーの使用方法については、 [暗号化および復号] を選択します。これにより、キーはデータの暗号化と復号にのみ使用されます。 [高度なオプション] の [キーマテリアルのオリジン] で [KMS – 推奨] を選択し、AWS KMS がキーマテリアルを作成および管理するようにします。 [リージョン] で、[シングルリージョンキー] または [マルチリージョンキー] を選択します。 [マルチリージョンキー] を選択すると、キー管理者は、キーを他のリージョンにレプリケートできます。既に説明したように、アイデンティティセンターでは現時点ではこれは必要ありませんが、設定が将来の変化に対応できるようにするのに役立ちます。なお、シングルリージョンキーを作成した後で、マルチリージョンキーに変換することはできません (ただし、アイデンティティセンターによって使用されるキーを変更することは可能です)。 その後、 [次へ] を選択して、ラベルの追加、管理許可の定義、使用許可の設定、キー作成前の最終設定の確認などの追加の設定ステップに進みます。 [ステップ 2 – ラベルを追加する] で、キーの [エイリアス] 名を入力し、 [次へ] を選択します。 このデモでは、 ドキュメント で提供されているテンプレートを使用してポリシーステートメントを追加することで、キーポリシーを編集します。 ステップ 3 とステップ 4 はスキップし、 [ステップ 5 – キーポリシーを編集する] に進みます。 アイデンティティセンターでは、少なくともアイデンティティセンターとその管理者がキーを使用できるようにする許可が必要です。そのため、3 つのポリシーステートメントを追加します。1 つ目と 2 つ目はサービスの管理者を認可し、3 つ目はアイデンティティセンターサービス自体を認可します。 { "Version": "2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Allow_IAMIdentityCenter_Admin_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_IdentityCenter_admin_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_use_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:ReEncryptTo", "kms:ReEncryptFrom", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "<Identity Center Account ID>" } } }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ] } また、AWS マネージドアプリケーションの使用という私のユースケースを許可するために、ポリシーステートメントをさらに追加する必要があります。これらの 2 つのポリシーステートメントを追加して、AWS マネージドアプリケーションとその管理者が KMS キーを使用することを認可します。 このドキュメントには、追加のユースケースとそれぞれのポリシーがリストされています 。 { "Sid": "Allow_AWS_app_admins_in_the_same_AWS_organization_to_use_the_KMS_key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals" : { "aws:PrincipalOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_managed_apps_to_use_the_KMS_Key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "Bool": { "aws:PrincipalIsAWSService": "true" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] }, "StringEquals": { "aws:SourceOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" } } } キーの使用を特定のアイデンティティセンターインスタンス、特定のアプリケーションインスタンス、または特定のアプリケーション管理者にさらに制限することもできます。 このドキュメントには、お客様のユースケース向けの高度なキーポリシーの例が記載されています 。 許可セットの再作成時に IAM ロール名が変更されないようにするには、「 Custom trust policy example 」で説明されている方法を使用します。 パート 2: IAM ポリシーを更新して、別の AWS アカウントからの KMS キーの使用を許可する アイデンティティセンターの委任された管理者や AWS アプリケーション管理者など、別の AWS アカウントからアイデンティティセンターサービス API を使用するすべての IAM プリンシパルには、これらの API 経由での KMS キーの使用を許可する IAM ポリシーステートメントが必要です。 新しいポリシーを作成し、ユースケースに関連する IAM ロールにそのポリシーをアタッチすることで、キーにアクセスするための許可を付与します。これらのステートメントを IAM ロールの既存の ID ベースのポリシーに追加することもできます。 これを行うには、キーを作成した後、その ARN を見つけて、以下のテンプレートの key_ARN を置き換えます。その後、そのポリシーをマネージドアプリケーション管理者の IAM プリンシパルにアタッチします。このドキュメントでは、 キーにアクセスするための許可をアイデンティティセンターの委任された管理者に付与する IAM ポリシー についても説明しています。 マネージドアプリケーション管理者向けの例を次に示します: { "Sid": "Allow_app_admins_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "<key_ARN>", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } } ドキュメントでは、最も一般的なユースケース向けの IAM ポリシーテンプレートを共有しています 。 パート 3: キーを使用するように IAM アイデンティティセンターを設定する CMK は、アイデンティティセンターの組織インスタンスを有効にする際に、または既存のインスタンスで設定できます。また、CMK を切り替えたり、AWS 所有キーに戻したりすることで、いつでも暗号化設定を変更できます。 KMS キーの許可を正しく設定しないと、アイデンティティセンターの運用が中断され、アイデンティティセンターを通じた AWS マネージドアプリケーションおよびアカウントへのアクセスが中断される可能性があることにご留意ください。この最後のステップに慎重に進み、ドキュメントをよく読み、理解するようにしてください。 CMK を作成して設定したら、アイデンティティセンターを有効にする際に [高度な設定] でその CMK を選択できます。 AWS マネジメントコンソールを使用して既存のアイデンティティセンターインスタンスで CMK を設定するには、まず AWS マネジメントコンソール のアイデンティティセンターのセクションに移動します。そこで、ナビゲーションペインから [設定] を選択し、 [管理] タブを選択して、 [IAM アイデンティティセンターの保管中のデータの暗号化用のキー] セクションで [暗号化を管理] を選択します。 いつでも、同じ AWS アカウントから別の CMK を選択したり、AWS マネージドキーに切り替えて戻したりできます。 [保存] を選択すると、キーの変更プロセスが完了するまで数秒かかります。移行中もすべてのサービス機能は中断なく使用できます。何らかの理由でアイデンティティセンターが新しいキーにアクセスできない場合は、エラーメッセージが返され、アイデンティティセンターは引き続き現在のキーを使用し、既に暗号化で使用されている暗号化メカニズムで ID データを暗号化し続けます。 留意事項 作成した暗号化キーは、アイデンティティセンターの重要なコンポーネントとなります。保管中の ID 属性を暗号化するために独自のマネージドキーを使用することを選択する場合は、次の点を確認する必要があります。 KMS キーを使用するために 必要な許可 を設定しましたか? 適切な許可がない場合、CMK を有効にすると失敗したり、IAM アイデンティティセンターの管理や AWS マネージドアプリケーションが中断したりする可能性があります。 AWS マネージドアプリケーションが CMK キーと互換性があることを確認しましたか? 互換性のあるアプリケーションの一覧については、「 AWS managed applications that you can use with IAM Identity Center 」をご覧ください。 CMK と互換性のない AWS マネージドアプリケーションによって使用されるアイデンティティセンターのために CMK を有効にすると、それらのアプリケーションの運用が中断されます。互換性のないアプリケーションがある場合は、続行しないでください。 組織は、アイデンティティセンターおよび Identity Store API を利用するために追加の IAM ロール設定を必要とする AWS マネージドアプリケーションを使用していますか? 既にデプロイされているこのような各 AWS マネージドアプリケーションについて、マネージドアプリケーションのユーザーガイドを読み、IAM アイデンティティセンターの使用のための、更新された KMS キーの許可を確認し、指示に従ってそれらの許可を更新して、アプリケーションが中断しないようにしてください。 簡潔にするために、この記事の KMS キーポリシーステートメントでは、 暗号化コンテキスト を省略しています。暗号化コンテキストを使用すると、 特定のインスタンスを含むアイデンティティセンターへの KMS キーの使用を制限 できます。本番のシナリオでは、アイデンティティセンターに次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:sso:instance-arn": "${identity_center_arn}", "kms:ViaService": "sso.*.amazonaws.com" } } あるいは、Identity Store に次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:identitystore:identitystore-arn": "${identity_store_arn}", "kms:ViaService": "identitystore.*.amazonaws.com" } } 料金と利用可能なリージョン キーストレージと API の使用には、AWS KMS の標準料金が適用されます。アイデンティティセンターは引き続き追加料金なしでご利用いただけます。 この機能は、すべての AWS 商用リージョン、AWS GovCloud (米国)、および AWS 中国リージョンでご利用いただけます。詳細については、「 IAM アイデンティティセンターユーザーガイド 」にアクセスしてください。 セキュリティとコンプライアンスの要件を満たすために、この新しい機能をどのように使用するのかについて、ぜひお聞かせください。 – seb 原文は こちら です。

本稿は、JALデジタル株式会社システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループの梅本様、北様からご寄稿いただきました。 はじめに JALデジタル株式会社のプラットフォームチームでは、JALグループのITシステムとして必要な設計・運用を満たすためのAWSアカウントを「 CIEL/S 」(※1)として提供しています。 今回私たちのチームでは、複数のAWSアカウントにおける AWS サポートとのやり取りを組織全体で効率的に活用するため、Amazon Bedrock を活用したナレッジ集約のソリューションを開発しました。 本記事では、AWS サポート問い合わせ内容の自動収集、AI要約、ServiceNow（※2）への連携を実現したアーキテクチャについて解説します。 ※1：リンク先の資料内におけるJALインフォテックは2025年4月、JALデジタルに社名変更しています。 ※2：JALグループではITSMツールとしてServiceNowを利用しています。 導入背景 現在JALグループで利用しているAWSアカウント数は数百アカウントあり、エンタープライズサポートを活用して24時間365日の運用を実現しています。しかし、利用していく中でいくつかの課題が発生しました。 アカウントの制約 各アカウントから行った問い合わせ内容は、そのアカウントでしか閲覧もできません。そのため、複数のAWSアカウントでのサポート問い合わせ内容が分散することになり、組織全体での知見共有が困難となっていました。また、私たちのチームに「○○という内容で過去に問い合わせしているアカウントはいないか」と質問があっても、一元管理できていないため探すのが困難でした。 ナレッジ共有の壁 問い合わせした内容をドキュメント化して共有する場合、CIEL/SのAWSアカウント全体で平均60件/月の問い合わせが発生しており、それらを手動でナレッジとして作成することはコストがかかりすぎてしまいます。また問い合わせ履歴が多くなってしまったサポートケースをそのまま転記するだけでは、読み手の負担も大きいためある程度要約をする必要がありますが、要約作成もナレッジ化のハードルとなっていました。 AWS サポートケース保管期限の制約 解決から２年経過した問い合わせはAWSコンソール上から削除されるため、それ以上過去に遡って探すことができませんでした。 ソリューション概要 上記課題を解決するために、自動的にAWS サポートケース の集約と Amazon Bedrock を活用した問い合わせ内容の要約作成を行うソリューションの開発を行いました。開発したソリューションは、2種類のAWSアカウントと、3つの主要なコンポーネントで構成されています。 AWSアカウントの種類 集約実行アカウント 問い合わせ内容を集約し、ServiceNowに連携するAWSアカウント 集約対象アカウント 問い合わせを集約させたいAWSアカウント コンポーネント 既存の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入前に解決済みとなっている AWS サポートケース を集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 新規の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入後に解決済みとなった AWS サポートケース を自動で集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 集約した問い合わせをServiceNowに連携する処理 AWS サポートケース の ResolveCase を検知（集約対象アカウント） 集約対象AWSアカウントで解決済みとなった AWS サポートケース を集約実行アカウントに連携する処理 AWS Cloudformation StackSets を利用して複数AWSアカウントに Amazon EventBridge Rule を展開 AWS サポートケースの検索と表示（ServiceNow） 集約実行アカウントから連携された問い合わせの表示 AWSサポートケースの内容検索 アーキテクチャ詳細 既存の AWS サポートケース の集約の処理については、一度のみの処理となるため、メインとなる新規の AWS サポートケース の集約について詳細を解説します。 Step 1: サポートケースが解決したイベント検知（集約対象AWSアカウント） 集約実行アカウントの Event Bus をターゲットとした Amazon EventBrige Rule を作成します AWS サポートの解決処理をトリガーとして、Amazon EventBridge Ruleのイベントパターンに定義します { "detail-type": ["Support Case Update"], "source": ["aws.support"], "detail": { "communication-id": [""], "event-name": ["ResolveCase"] } } Step 2: Step 1 の検知を元にLambdaを実行（集約実行AWSアカウント） 集約対象AWSアカウントに対して、AWS Support API ( DescribeCases 、 DescribeSeverityLevels 、 DescribeServices 、 DescribeCommunications )を実行してサポートケース情報を取得 Amazon Bedrock API ( Converse ) を実行し サポートケース会話情報を要約 Amazon DynamoDB に登録 Step 3: ServiceNow連携（集約実行AWSアカウント） DynamoDB Stream から AWS Lambda 関数を実行 ServiceNow への認証処理 ServiceNow への記事の登録処理の実行 ①AWS サポートケースとServiceNow上のナレッジとのマッピング ②ServiceNow上でナレッジ検索する際イメージ 実装ポイント Amazon EventBridgeのリージョン制約対応 AWS サポートは us-east-1 リージョンのグローバルリソースであるため、EventBridge Rule の配置および Lambda 関数のデプロイも us-east-1 にまとめることが推奨されます。 セキュリティ権限の最小化 各AWSアカウントに必要な IAMロール・ポリシーは最小権限の原則に従い、AWS サポートケースの読み取り権限や EventBridge Rule の作成権限だけに限定することで安全性を確保してください。 システムプロンプトの設計 読み手が短時間で問題の本質と解決策を把握できるよう、要約生成のためのプロンプトは、以下のポイントを押さえて設計しています。 ユーザーが直面した問題、サポートの具体的な解決策、成功のための考慮事項を明確に区別して要約させる 日本語で簡潔に300文字以内に収める文字数制限を設定し、不要な情報を排除 「問い合わせ内容」「解決策」「考慮事項」という出力フォーマットを厳格に指定し、一貫性のある要約を実現 ナレッジ格納先にServiceNowを選定 本ソリューション実装前から、プラットフォームに関するナレッジを ServiceNow 上に乗せていた 標準となるナレッジの型があり、UI を一から作成する必要が無い 検索機能も ServiceNow 標準のものを利用できる(AIを用いた検索等は今後実装予定) ※AWS Support APIの利用条件 AWS Support APIの利用にはビジネスサポート以上のサポートプラン（ビジネス、エンタープライズ On-Ramp、エンタープライズ）が必要です。JALグループではエンタープライズサポートを利用しているため、本ソリューションで必要となるAWS Support APIの全機能を活用することができます。 導入効果 本ソリューションの導入により、以下の効果を実現しました。 ナレッジ共有の効率化 複数アカウントの問い合わせ内容を一元管理することで、組織全体の知見を活用できるようになりました。またAI要約を入れることで、すべてのやり取りを読む前に自分たちが探している情報かどうか判断することができるようになりました。 運用工数の削減 手動でのドキュメントや要約作成が不要になることで、ナレッジ作成に伴う運用コストを大幅に削減させることができました。また ServiceNow への自動連携により転記作業を削減した上で、解決済みになった問い合わせをリアルタイムでナレッジ化することが可能になりました。 問題解決の迅速化 一元管理により、各アカウントの担当者が組織全体の知見を活用して、調べたい情報や類似事例を直接検索-閲覧できるようになりました。これにより、プラットフォームチームやAWSサポートに問い合わせて回答を待つ時間を省略し、素早い問題解決が可能になりました。 まとめ AWS Support APIを利用した問い合わせ内容の取得と、Amazon Bedrock を活用した問い合わせ内容の要約作成を組み合わせることで、組織全体のナレッジマネジメントを大幅に改善することができました。AWS Lambda、 Amazon EventBridge、Amazon DynamoDB などAWSのマネージドサービスを最大限に活用、AWS利用料を最小限に抑えるアーキテクチャを実現しました。 今後は、要約精度の向上や、より高度な分析機能の追加を検討しており、継続的な改善を進めていく予定です。 著者略歴 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 梅本征宏 2019年入社　旅客系システムの開発・維持管理業務を担当。 2022年に現部署に異動して以降、Platform Engineeringを推進。 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 北修哉 顧客系システムの開発を担当。 2024年に現部署に異動し、プラットフォームチームの運用高度化を推進。

はじめに データドリブンエンタープライズの環境では、組織は 2 つの重要な要件を満たすデータベースソリューションを必要としています。1 つは、トランザクション処理と分析処理の両方のワークロードを扱える高性能性、もう 1 つはセキュリティとコンプライアンス要件への適合です。AWS 上で運用される SAP HANA Cloud は、 SAP Business Technology Platform（ SAP BTP ） のサービスの一つであり、フルマネージド型のクラウドネイティブな Database-as-a-Service として、これらの要件に応えます。 SAP HANA Cloud は主に 2 つの用途で活用されています。1つは、ERP、CRM、HR、ロジシティックスなどの基幹システムを単一の高速プラットフォームで支えること。もう 1 つは、高度な分析とデータアプリケーションを通じて、実践的なビジネスイノベーションを推進・支援することです。また、SAP HANA Cloud は、SAP Analytics Cloud、SAP Datasphere、SAP Cloud Application Programming Model（CAP）で開発されたアプリケーションなどの、様々な SAP BTP サービスの基盤でもあります。 このブログでは、AWS PrivateLink を通じて SAP HANA Cloud のセキュリティと接続性を強化することにフォーカスし、高性能と信頼性を維持しながらプライベートで安全なデータベースアクセスを必要とする組織の重要なニーズに対応します。 AWS が SAP HANA Cloud の稼働基盤として選ばれた理由 SAP HANA Cloud は  AWS Graviton プロセッサーによって対応しており、分析ワークロードで計算性能が最大 30% 向上しを提供し、計算コストを 15% 削減し、同等の EC2 インスタンスと比較して最大 60% 消費エネルギーを抑えることができます 。AWS Graviton ベースのインスタンスに移行することで、SAP は SAP HANA Cloud ワークロードの計算カーボンフットプリントを約 45% 削減できると見込んでおり、炭素排出量削減を支援する Amazon の The Climate Pledge の署名企業としての取り組みを支持します。SAP は将来的に AWS Graviton の使用を拡大し、これらの性能向上、コスト削減、エネルギー効率を継続的に活用する計画です。したがって、AWS 上の SAP HANA Cloud を使用するお客様は、性能向上のメリットを享受しながら、カーボンフットプリントを削減も実現できます。 AWS 上の SAP HANA Cloud への接続 SAP HANA Cloud に接続する際、オンプレミスまたは他のクラウド環境にあるクライアントアプリケーションやユーザーは、インターネットアクセス可能なエンドポイントを通じてパブリック API を使用してデータベースにセキュアにアクセスできます。 図1：デフォルトのパブリックエンドポイント経由でのSAP HANA Cloudへの接続 金融サービス、ヘルスケア、政府機関などの規制産業のお客様で、HIPAA、EU/US Privacy Shield、PCI DSS などの規制により、パブリックエンドポイントの使用が制限される場合があります。この場合、SAP HANA Cloud と AWS PrivateLink を組み合わせることをお勧めします。これにより、AWS の安全なネットワークインフラストラクチャを活用しながら、データベースとアプリケーション間の安全かつプライベートな通信を実現できます。また、プライベートIPアドレス範囲（RFC 1918）を使用することで、サービスへの攻撃リスクが低減できます。 このブログでは、AWS PrivateLink を使用したプライベート接続オプションを活用して、SAP HANA Cloud のデータ転送時のセキュリティを強化する方法について解説します。PrivateLink は、AWS 環境と SAP HANA Cloud 間の安全でプライベートなネットワーク接続を確立でき、パブリックインターネットへの通信を回避し、不正アクセスのリスクを抑制することができます。 AWS PrivateLink とは AWS PrivateLink を使うことにで、AWSサービス（ネットワーク、コンピューティング、サーバーレスアプリケーション、AI など）と SAP BTP サービス間の通信をインターネット経由せず、プライベート接続を実現できます。また、AWS PrivateLink を使用して、Direct Connect または VPN 経由で Amazon Virtual Private Cloud（VPC）に接続されたオンプレミスネットワーク間の安全でプライベートな接続を提供することもでき、パブリックネットワークやIPアドレスを完全に回避できます。 AWS PrivateLink により、異なるアカウントやVPC間でのサービス接続が簡単になり、ネットワークアーキテクチャを大幅に簡素化します。VPC 内のプライベート IP アドレスを持つ Elastic Network Interface であるインターフェースエンドポイント経由で、AWS サービス、他の AWS アカウントで稼働しているサービス（エンドポイントサービス）、AWS Marketplace パートナーサービスに接続できます。 インターフェースエンドポイントは、VPC のサブネット内の Elastic Network Interface と IP アドレスを使用して、VPC 内に直接作成されます。プロバイダーとコンシューマーは、IPアドレスの重複を避けるためにネットワークセグメントや CIDR ブロックを調整する必要がありません。VPC ピアリングや AWS Transit Gateway 経由の接続は通信に必要ありません。セキュリティグループを関連付け、AWS サービスのインターフェースエンドポイントにエンドポイントポリシーを設定することで、指定されたサービスへのアクセスを制御できます。AWS PrivateLink を使用すると、 AWS サービス や他の VPC が提供する他のサービスに、AWS ネットワーク内のプライベート接続を通じて安全にアクセスできます。すべてのネットワークトラフィックはグローバル AWS バックボーン上に留まり、パブリックインターネットを経由することはありません。 図2：AWS PrivateLink 経由での SAP HANA Cloud への接続 SAP HANA Cloudと AWS PrivateLink との接続するメリットをより理解するために、実際のシナリオでそのメリットを示すいくつかの実用的なユースケースを探ってみましょう。 SAP HANA Cloud と AWS PrivateLink を使うユースケース データセキュリティが重要なビジネス環境において、AWS PrivateLink の実装は、データ転送中の機密情報を保護するために不可欠です。AWS のインフラストラクチャが提供するプライベート IP エンドポイントサービスは、重要なセキュリティレイヤーとして機能し、ビジネスへ重大な影響をもたらす可能性のあるセキュリティ侵害を防ぐのに役立ちます。この統合は、現代のクラウドアーキテクチャの複雑な要件に対応するエンタープライズクラスのセキュリティソリューションを提供することに対する AWS のコミットメントを示しています。 ユースケース 1 – SAP HANA Cloud 管理アクセスセキュリティ SAP HANA Cloud PrivateLink を実装する重要なユースケースの 1 つは、安全なデータベースアクセスへの対応です。企業の環境では、オフィスで働くデータベース管理者と開発者は、テーブル管理、メンテナンス、開発タスクなどの重要タスクを実行するために SAP HANA Cloud への定期的なアクセスが必要です。これらの技術者は、一般ユーザーとは異なり、タスクに必要な広範なデータベース権限を付与されているため、接続セキュリティが特に重要になります。 図3に示すように、 AWS PrivateLinkを使用した SAP HANA Cloud は、組織が機密データの転送をプライベートネットワークでのみに制限できるようにする完璧なソリューションを提供します。データベース操作へのプライベートアクセスは、運用効率を維持しながらパブリック IP を使わず、厳格なアクセス制御を通じて組織のセキュリティを強化します。 図3：SAP HANA Cloud 管理アクセスセキュリティ ユースケース 2 – セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス SAP HANA Cloud と AWS PrivateLink の重要なユースケースは、AWS 上でデータプラットフォームを構築し、SAP HANA Cloud データを分析エコシステムに統合するケースです。AWS データプラットフォーム内で SAP HANA Cloud データにアクセスするには、主に2つの方法があります。AWS Glue ETL ジョブを使用してデータを抽出しAmazon S3 にロードする方法、またはフェデレーションクエリに Amazon Athena SAP HANA コネクタを使用する方法です。両方のアプローチには、AWS サービスと SAP HANA Cloud 間の安全で信頼性の高い接続が必要です。 これらのデータ統合パターンを実装する際、機密ビジネスデータがシステム間で転送されるため、セキュリティが重要になります。図4は、AWS PrivateLinkが必要なセキュアな接続レイヤーを提供することを示しています。AWS サービス（AWS Glue や Amazon Athena など）と SAP HANA Cloud 間のすべてのデータ転送とクエリがプライベートネットワークチャネルを介して行われ、パブリックインターネットへの通信を介さず、エンタープライズデータ統合シナリオの厳格なセキュリティ要件を満たします。 図4：セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス AWS PrivateLink を使用した SAP HANA Cloud の設定方法 ユースケース 1 のエンタープライズグレードの SAP HANA Cloud アクセスの設定手順を説明します。このブログでは、設定について SAP HANA Cloud 管理ガイド を参照しました。この設定は SAP BTP 有料ティアアカウントで利用可能です。このブログ執筆時点では、データレイクインスタンス用の SAP HANA Cloud PrivateLink はAWS でのみ利用可能であり、 SAP HANA Cloud PrivateLink ドキュメント に記載されているように、リージョン内の接続のみをサポートしています。以下は設定手順の概要です。 SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 AWS VPC で VPC エンドポイントを設定 AWS VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 Amazon Route53 でプライベートホストゾーンを設定 VPC 内から HANA Cloud へのプライベートルーティングをテスト インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでの使用例1でのみ必要） 各ステップの詳細は以下の通りです。さらなるステップバイステップガイダンスについては、 このワークショップ のラボを参照してください。 1. SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 SAP HANA Cloud の管理画面で、設定したい HANA Cloud インスタンスを選択し、 View Configuration をクリックします。 図5：SAP HANA Cloud – 設定を表示 接続タブで、AWS PrivateLink Endpoint ID を有効にするボタンをオンにします。これにより、AWS VPC への接続を設定するための PrivateLink Endpoint ID を取得できます。 許可する接続 で、「この BTP リージョンの Cloud Foundry からの IP アドレスのみを許可」または「特定の IP アドレスと IP 範囲を許可（BTP の Cloud Foundry に加えて）」を選択して、すべてのトラフィックがプライベート接続を通過するように制御します。 図6：SAP HANA Cloud – 接続 2. AWS VPC で VPCエンドポイントを設定 このステップでは、AWS VPC で VPC エンドポイントとセキュリティグループを設定して、Amazon VPC からこのエンドポイント経由で HANA Cloud へのアクセスを許可します。ご自身のAWS アカウントに VPC が設定されていない場合は、 Amazon VPC ドキュメント を参照して VPC を作成してください。SAP HANA Cloud インスタンスの設定タブで AWS PrivateLink Endpoint Service ID をコピーします。 図7: SAP HANA Cloud – PrivateLink Endpoint Service IDs AWS コンソールで、Amazon VPC サービスにアクセスし、 パートナーサービス用の VPC インターフェースエンドポイント を作成します。エンドポイント作成画面で、エンドポイントの名前を入力し、タイプに「PrivateLink Ready partner services」を選択します。サービス設定で、HANA Cloud インスタンスの AWS PrivateLink Endpoint Service ID をサービス名ボックスに入力します。次に、サービス確認ボタンをクリックします。 図 8: Amazon VPC – VPC エンドポイント作成 (1) 「サービス名が確認されました」という成功メッセージが表示されたら、ネットワーク設定を選択できるようになります。ネットワーク設定で、エンドポイントを作成したい VPC とアベイラビリティーゾーン、サブネットを選択します。SAP HANA Cloud インスタンスが複数の AZ で利用可能な場合、VPC で複数の AZ とサブネットを選択できます。 図 9: Amazon VPC – VPC エンドポイント作成 (2) このエンドポイントに、 https トラフィックを許可するセキュリティグループを割り当ててください。このブログでは、同 VPC 内のIP アドレス CIDR からの https トラフィックを許可するインバウンドルールを持つ https-from-sap-vpc という名前のセキュリティグループを作成しました。 図 10: Amazon VPC – VPC エンドポイント作成 (3) VPCエンドポイントが作成され、ステータスが「使用可能」になったら、エンドポイントの詳細ページからエンドポイント ID をコピーしてください。この ID は、次のステップで HANA Cloud の設定に使用します。DNS ネームをコピーして、後で Route 53 での DNS 設定時に使用します。プライベート IPv4 アドレスをメモしておいてください。これは、プライベートルーティングをテストする最後のステップで確認することができます。 図 11: Amazon VPC – VPC エンドポイントの確認 3. Amazon VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 HANA Cloud 管理画面に戻り、HANA Cloud インスタンスの設定を開きます。接続設定画面で、作成した VPC エンドポイント ID を許可リストに追加します。これにより、先ほどの VPC から作成された VPC エンドポイントで HANA Cloud PrivateLink エンドポイントサービスに接続できるようになります。 Figure 12: SAP HANA Cloud – VPC エンドポイント ID 許可 4. Amazon Route53 でプライベートホストゾーンを設定 このステップでは、VPC 用の Amazon Route 53 のプライベートホストゾーンを設定し、HANA Cloud インスタンスへのトラフィックを VPC エンドポイントに向ける DNS レコードを作成します。SAP HANA Cloud 接続の詳細から、SQL エンドポイントアドレスとランドスケープアドレスを確認します。Route 53 DNS 設定と接続テストで使用するため、これらのアドレスをメモしてください。 図 13: SAP HANA Cloud – 接続情報確認 Amazon Route 53 ホストゾーン設定で、以下のように値を設定します。 – ドメイン名として HANA Cloud ランドスケープ名を入力 – タイプとしてプライベートホストゾーンを選択 – ホストゾーンを VPC に関連付けるために VPC ID を選択 次に、ホストゾーンの作成ボタンをクリックします。 図 14: Amazon Route 53 – ホストゾーン作成 作成されたホストゾーン画面で、すべての HANA Cloud へのトラフィックを VPC エンドポイントにルーティングする新しい DNS レコードを作成します。 図 15: Amazon Route 53 – DNS レコード作成 5. VPC 内から HANA Cloud へのプライベートルーティングをテスト 設定完了後、VPC 内の EC2 インスタンスから dig または nslookup コマンドを実行して、HANA Cloud インスタンスへのトラフィックが VPC エンドポイントのプライベート IP アドレスに向かっていることを確認します。HANA Cloud エンドポイント URL でこれらのコマンドを実行すると、VPC エンドポイントのプライベート IP アドレスが応答されます。 図 16: コマンドでプライベートルーティングを確認 hdbsql コマンドで HANA Cloud エンドポイントへのデータベース接続を確認します。 図 17: hdbsql コマンドでデータベース接続を確認 6. インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでのユースケース 1 でのみ必要） Route 53 プライベートホストゾーンは AWS アカウントの VPC 内に設定されているため、この VPC からのトラフィックにのみ影響します。ユースケース 1 で、RISE またはオンプレミスネットワークから HANA Cloud へのトラフィックも VPC エンドポイントを通過させたい場合は、 Route 53 インバウンドリゾルバー を使用し、ネットワークからこのリゾルバーに DNS を転送する必要があります。 詳細な手順は Route 53 ドキュメント を参照してください。下記の画面は、VPC 内に作成されたインバウンドエンドポイントのサンプルで、2 つのサブネットに 2 つのプライベートIPアドレスが割り当てられています。これらの IP アドレスは、RISE やオンプレミスネットワークでの DNS 設定に使用することができます。 図 18: Amazon Route 53 – インバウンドリゾルバー 高可用性 AWS PrivateLink の高可用性アーキテクチャは、複数のアベイラビリティーゾーン（ AZ ）を通じて堅牢で回復力のある接続を提供し、重要なビジネス運用のための継続的なサービス可用性を確保します。図 19 は、複数の AZ にまたがるエンドポイントネットワークインターフェースで AWS PrivateLink を実装することで、自動フェイルオーバー機能を実現し、ネットワークアーキテクチャにおける単一障害点を排除できることを示しています。この分散設計により、ある AZ が使用不可能になった場合でも、トラフィックは自動的に正常なエンドポイントにルーティングされ、アプリケーションやサービスへのシームレスな接続が維持されます。 これにより、アプリケーションの信頼性が向上し、ダウンタイムのリスクが軽減され、パフォーマンスが安定するとともに、プライベート接続のセキュリティ上の利点も得られます。さらに、AWS PrivateLink と Amazon Route 53 DNS サービスとの統合により、インテリジェントなルーティングとヘルスチェックが可能となり、ソリューション全体の可用性と耐障害性が向上します。この包括的な高可用性の実装により、セキュアでプライベートなネットワーク通信を維持しながら、厳格なビジネス継続性要件を満たすことができます。 以下のアーキテクチャは、Network Load Balancer を通じて 2 つの AZ に跨って HA がどのように機能するかを説明しています。 図19：高可用性を備えた AWS PrivateLink 価格例 このブログの公開時点では、SAP HANA Cloud で AWS PrivateLink を有効にする際、SAP BTP で追加料金は発生しません。SAP が Network Load Balancer の実装と有効化を実施します。ご自身の AWS アカウントで作成されたリソースに対してのみ課金されます。 例えば、高可用性ありとなしでのお客様の AWS アカウントでの AWS PrivateLink のコストを比較してみましょう。両方のオプションは、この AWS 料金計算ツールリンク にあります。 図20: 料金の例 次のステップ AWS PrivateLink の詳細については、AWS ドキュメント 「AWS PrivateLink とは？」 、 「AWS PrivateLink を使用して VPC をサービスに接続する」 、およびAWSホワイトペーパー 「AWS PrivateLink」 を参照してください。 同様に、詳細については SAP HANA Cloud オンラインドキュメント と  SAP HANA Cloud データベース管理ガイド を参照してください。 AWS アカウントチームと AWS サポートチャネルに加えて、AWS コミュニティ向けの Q&A 体験である re:Post を開始しました。AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できる議論と質問について、AWS for SAP トピックを定期的に監視しています。質問がサポート関連でない場合は、re:Post での議論に参加し、コミュニティの知識ベースに貢献することを検討してください。 クレジット このブログへの貢献に対して、Derek Ewell、Ferry Mulyadi、Diego Lombardini、Eneko Bilbaoに感謝いたします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

9 月 29 日週、SWE-Bench によって世界最高のコーディングモデルと評価されている Anthropic の Claude Sonnet 4.5 が、 Amazon Q コマンドラインインターフェイス (CLI) と Kiro でご利用いただけるようになりました。このことに高揚感を覚えている理由は 2 つあります: まず、私は数週間前に世界中のお客様と 4 日間にわたって集中的に AI 支援開発ワークショップを開催し、 Amazon Q CLI がデベロッパーの生産性をいかに向上させるかを実際に体験しました。ワークショップ中、お客様は Amazon Q CLI を使用して 1 日でアプリケーションに新しい特徴量を追加することができました。これは従来であれば少なくとも 2 週間はかかっていた作業です。Amazon Q CLI で Anthropic の Claude Sonnet 4.5 が使用できるようになることで、デベロッパーの生産性がさらに向上すると確信しています。 2 つ目として、私は AWS re:Invent 2025 でのコードトークの準備を始めました。このコードトークでは、私と共同講演者が Kiro を使用してレガシーコードベースをモダナイズするライブコーディングを行います。Kiro で Anthropic の Claude Sonnet 4.5 を使用してライブデモを作成するのが待ちきれません。このデモや、クラウドと AI に関する 1,000 を超える他のセッションをご覧になりたい方は、12 月 1 日から 5 日までラスベガスで開催される AWS re:Invent 2025 にぜひご参加ください。 9 月 29 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock で Claude Sonnet 4.5 が使用可能に – コーディングと複雑なエージェントに最適な、Anthropic の最もインテリジェントなモデルが、Amazon Bedrock でご利用いただけるようになりました。Amazon Bedrock で Claude Sonnet 4.5 を利用することで、デベロッパーは、基盤モデル (FM) 用の統合 API を提供するだけでなく、セキュリティと最適化を実現するためのエンタープライズグレードのツールによってデータを完全に制御できるようにする、フルマネージドサービスにアクセスできます。 AWS Outposts が Dell および HPE とのサードパーティーストレージ統合をサポート – AWS Outposts のサードパーティーストレージ統合に、 Dell PowerStore および HPE Alletra Storage MP B10000 システムが含まれるようになりました。これらは、 NetApp オンプレミスエンタープライズストレージアレイ および Pure Storage FlashArray との既存の統合リストに加わりました。この統合には、主に 3 つの目的があります。1 つ目は、お客様が既存のストレージインフラストラクチャを維持しながら VMware ワークロードを AWS に移行するのをサポートすることです。2 つ目は、お客様が AWS サービスを利用しながらデータをオンプレミスに保持することで、厳格なデータレジデンシー要件を満たすのをサポートすることです。3 つ目として、この統合により、お客様は、AWS ツールを通じてサードパーティーストレージアレイとともに AWS Outposts を利用できます。 Amazon ECS マネージドインスタンスが利用可能に – コンテナ化されたアプリケーション向けの Amazon ECS マネージドインスタンスは、Amazon ECS 向けの新しいフルマネージドコンピューティングオプションであり、インフラストラクチャ管理のオーバーヘッドを排除しながら、Amazon EC2 の全機能を使用できるように設計されています。ECS マネージドインスタンスは、ワークロードを迅速に起動およびスケールするとともに、パフォーマンスを改善し、総保有コストを削減するのに役立ちます。 Amazon CloudWatch でアプリケーションマップの一般提供を開始 – Amazon CloudWatch は、設定とその関係に基づいてサービスを自動的に検出し、グループに整理することで、大規模な分散アプリケーションをモニタリングするのをサポートします。この新しいアプリケーションパフォーマンスモニタリング (APM) 機能を使用すると、分散アプリケーションのトラブルシューティング時に、どのアプリケーションと依存関係に重点を置くべきかを迅速に視覚化できます。 Amazon Bedrock AgentCore モデルコンテキストプロトコル (MCP) サーバーが使用可能に – ランタイム、ゲートウェイ統合、ID 管理、エージェントメモリのサポートが組み込まれた AgentCore MCP サーバーは、Bedrock AgentCore と互換性のあるコンポーネントの作成を高速化するために特別に構築されています。AgentCore MCP サーバーは、ラピッドプロトタイピング、本番 AI ソリューション、またはエージェントインフラストラクチャのスケールに使用できます。 その他のアップデート 以下では、私が興味深いと思った他のニュースやブログ記事をいくつかご紹介します: AWS ビルダー ID が「Google でログイン」をサポート –「Google でログイン」を使用して AWS ビルダー ID を作成できるようになりました。AWS ビルダー ID は、Kiro、AWS Builder Center、AWS トレーニングと認定、AWS re:Post、AWS スタートアップなどの AWS アプリケーションへのアクセスを提供する個人プロファイルです。 AWS API MCP サーバー v1.0.0 リリース – AWS API MCP サーバーは、AI アシスタントと AWS サービスの間のブリッジとして機能し、構文的に正しい CLI コマンドを作成して実行することで、基盤モデルが自然言語を通じてあらゆる AWS API とインタラクションできるようにします。AWS API MCP サーバーはオープンソースであり、 AWS ラボ GitHub リポジトリ で現在入手可能です。 AWS Knowledge MCP サーバーの一般提供を開始 – AWS Knowledge サーバーは、AI エージェントと MCP クライアントに、ドキュメント、ブログ記事、新機能のお知らせ、Well-Architected ベストプラクティスなどの信頼できる情報を LLM 互換形式で提供します。このリリースでは、AWS API と CloudFormation のリソースが利用できるリージョンに関する情報もサーバーに含まれます。 AWS Transform で VMware ネットワークオートメーションのために Terraform が使用可能に – AWS Transform は、VMware 環境からネットワークインフラストラクチャコードを自動的に生成するための追加オプションとして Terraform を提供するようになりました。このサービスは、ソースネットワーク定義を再使用可能な Terraform モジュールに変換し、現在の AWS CloudFormation と AWS Cloud Development Kit (CDK) のサポートを補完します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS AI Agent Global Hackathon – AWS の強力な生成 AI スタックを掘り下げて、目を見張るようなすばらしいソリューションを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成し、45,000 USD を超える賞金と独占的な市場参入の機会の獲得に向けて競い合いましょう。 AWS Gen AI Loft – 特別セッションで AWS の AI 製品とサービスについて学び、業界をリードするエキスパートと交流して、投資家や同業者との有益なネットワーキングの機会を得ることができます。最寄りの都市でご登録ください: パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日)。 AWS Community Days – 世界中の AWS ユーザーや業界リーダーによる技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにぜひご参加ください: ミュンヘン (10 月 7 日)、 ブダペスト (10 月 16 日)。 今後開催されるすべての AWS イベント と AWS スタートアップイベント をご覧いただけます。 10 月 6 日週のニュースは以上です。10 月 13 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

9 月 30 日、Amazon ECS マネージドインスタンスを発表しました。これは Amazon Elastic Container Service (Amazon ECS) の新しいコンピューティングオプションです。開発者はインフラストラクチャ管理の責任を Amazon Web Services (AWS) にオフロードしながら、 Amazon Elastic Compute Cloud (Amazon EC2) の全機能を使用できるようになります。この新しいサービスは、インフラストラクチャのオフロードによる運用のシンプルさと Amazon EC2 の柔軟性および制御を組み合わせたものです。つまり、お客様は総保有コスト (TCO) を削減し、AWS のベストプラクティスを維持しながら、イノベーションを推進するアプリケーションの構築に集中することができます。 弊社では、コンテナ化されたワークロードを実行しているお客様から、サーバーレスのシンプルさとセルフマネージド EC2 インスタンスの柔軟性を組み合わせたいというご要望をいただいていました。サーバーレスオプションは優れた汎用ソリューションを提供しますが、アプリケーションによっては GPU アクセラレーション、特定の CPU アーキテクチャ、またはネットワークパフォーマンスの強化など、特定のコンピューティング機能が必要となります。さらに、EC2 料金オプションを通じて既に Amazon EC2 キャパシティに投資してくださったお客様は、これらのコミットメントをサーバーレスサービスで十分に活用することができませんでした。 Amazon ECS マネージドインスタンスは、さまざまな EC2 インスタンスタイプと AWS サービスとの密な統合をサポートする、フルマネージドのコンテナコンピューティング環境を提供します。デフォルトでは、ワークロードに最適なコストの EC2 インスタンスが自動的に選択されますが、必要に応じて特定のインスタンス属性またはタイプを指定できます。AWS がプロビジョニング、スケーリング、セキュリティパッチ処理、コスト最適化など、インフラストラクチャ管理のすべての側面を処理するため、お客様はアプリケーションの構築と実行に集中することが可能です。 試してみましょう 新しい Amazon ECS クラスターを作成する AWS マネジメントコンソール のエクスペリエンスを見てみると、ECS マネージドインスタンスを使用するための新しいオプションだということがわかります。それでは、すべての新しいオプションについて簡単に見ていきましょう。 [Fargate とマネージドインスタンス] を選択すると、2 つのオプションが表示されます。 [ECS デフォルトを使用] を選択すると、Amazon ECS は保留中のタスクをグループ化して汎用インスタンスタイプを選択し、コストと耐障害性のメトリクスに基づいて最適なインスタンスタイプを選択します。これが最もわかりやすい、お勧めの開始方法です。 [カスタムを使用 – 詳細] を選択すると、Amazon ECS が使用するインスタンスの属性をファインチューニングできる追加の設定パラメータが開きます。 デフォルトでは、 CPU と メモリ は属性として表示されますが、さらに 20 個の属性から選択し、Amazon ECS がアクセスできる使用可能なインスタンスタイプのリストを引き続きフィルタリングすることができます。 属性を選択すると、選択に一致するすべてのインスタンスタイプのリストが表示されます。 ここから、通常どおり ECS クラスターを作成できます。Amazon ECS は、前のステップで定義した属性と基準に基づき、私に代わってインスタンスをプロビジョニングします。 Amazon ECS マネージドインスタンスの主な特徴量 Amazon ECS マネージドインスタンスでは、AWS がインフラストラクチャ管理の全責任を負い、インスタンスのプロビジョニング、スケーリング、メンテナンスのすべての側面を処理します。これには、14 日ごとに開始される定期的なセキュリティパッチの実装 (インスタンスの Connection Draining により、インスタンスの実際の存続期間が長くなる場合があります) や、アプリケーションの中断を最小限に抑えるために Amazon EC2 イベントウィンドウを使用してメンテナンスウィンドウをスケジュールする機能が含まれます。 このサービスでは、インスタンスタイプを非常に柔軟に選択できます。デフォルトではコスト最適化されたインスタンスタイプが自動的に選択されますが、ワークロードにおいて特定の機能が必要な場合、必要なインスタンス属性を指定することができます。これには GPU アクセラレーション、CPU アーキテクチャ、ネットワークパフォーマンス要件のオプションが含まれており、コンピューティング環境を正確に制御できます。 Amazon ECS マネージドインスタンスはコストを最適化するために、必要に応じて複数のタスクをより大きなインスタンスに自動的に割り当てることにより、リソースの使用率をインテリジェントに管理します。このサービスはタスク配置を継続的に監視および最適化し、ワークロードを少数のインスタンスに統合してアイドル (空の) 状態のインスタンスを枯渇させ、利用および終了することで、コンテナ化されたアプリケーションの可用性とコスト効率の両方を高めます。 既存の AWS サービス、特に EC2 料金オプションなどの Amazon EC2 特徴量との統合はシームレスです。この密な統合により、フルマネージドサービスの運用のシンプルさを維持しながら、既存のキャパシティ投資を最大限に活用することができます。 Amazon ECS マネージドインスタンスでは、引き続きセキュリティが最優先事項です。このサービスは、専用のコンテナオペレーティングシステムである Bottlerocket 上で動作し、自動化されたセキュリティパッチとアップデートを通じてお客様のセキュリティ体制を維持します。Bottlerocket OS イメージに適用されたすべてのアップデートとパッチは、 Bottlerocket のウェブサイト で確認できます。この包括的なセキュリティへのアプローチにより、コンテナ化されたアプリケーションを安全かつ管理された環境で引き続き実行することができます。 今すぐご利用いただけます Amazon ECS マネージドインスタンスは現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (ダブリン)、アフリカ (ケープタウン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) の AWS リージョンでご利用いただけます。マネージドインスタンスは、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または AWS Cloud Development Kit (AWS CDK) や AWS CloudFormation などの Infrastructure as Code (IaC) ツールから使用を開始できます。使用する EC2 インスタンスの料金と、サービスの管理料金が請求されます。 Amazon ECS マネージドインスタンスの詳細については、 ドキュメント をご覧ください。コンテナインフラストラクチャの簡素化を今すぐ始めましょう。 原文は こちら です。

はじめに みなさんこんにちは、ソリューションアーキテクトの眞壽田（ますた）です。2025年9月18日に開催された「Vector SDV Symposium Japan 2025」にて、AWSのソリューションアーキテクトとして「SDV時代の車載ソフトウエア開発を支えるAWSソリューション」というテーマでセッションを担当させていただきました。Software-Defined Vehicle（SDV）の波が自動車産業を大きく変革している今、クラウドテクノロジーがどのように車載ソフトウェア開発の課題を解決し、イノベーションを加速させるのか。本セッションでは、仮想開発環境や仮想ECU技術を使ったテストの効率化まで、AWSが提供するソリューションについて紹介しました。 この記事では、セッションの内容を詳しく解説するとともに、SDV時代におけるクラウドの可能性について掘り下げていきたいと思います。 これまでのSDV事例のおさらい SDV時代を見据え、AWSを活用して車載ソフトウエア開発の効率化を目指した自動車メーカー様の事例は次の通りです。詳細はリンクやブログを参照頂ければと思います。 1. ステランティス　Virtual Engineering Workbench（VEW）2022年 youtube blog 2. BMW Operating System 9 2023年 link 3. 本田技研工業株式会社　Digital Proving Ground 2023年 youtube これらの事例に共通するAWSのソリューションを、次の章でじっくり紹介していきたいと思います。 SDV開発を支援するAWSのソリューション 自動車産業がソフトウェア定義車両（SDV）へと急速に進化する中、AWSは自動車メーカーが直面する複雑な課題に対して、包括的な支援フレームワークを提供しています。この図が示すように、AWSの支援は三つの主要な柱を中心に構成されています。 これらの柱に加え、AWSはデジタル人材の育成支援やパートナーとの連携を通じて、自動車メーカーのSDV開発を包括的にサポートしています。この統合的なアプローチにより、お客様は従来の開発モデルからソフトウェア中心の開発へとスムーズに移行し、次世代モビリティの創造に専念することができます。 自動車業界におけるオンプレミスの開発環境に対する課題 以下の例は、AWSがお客様からよく聞く課題をAWSの生成AIのサービス（ Amazon Bedrock ）でストーリー調に仕立てたものです。 ある自動車メーカーの制御ECU開発部門では100名以上のエンジニアがモデルベース開発（MBD）環境を使って制御ソフトウェアの開発に取り組んでいます。「開発環境の構築と維持が私たちの最大の頭痛の種なんです」とAさんは語ります。 「昨年、新たなプロジェクトが始まった時、各エンジニアの開発PC調達だけで数ヶ月を要しました。そして機材が到着した後も、必要なツールのインストールに数週間を費やしました。開発に必要なツール群は多岐にわたり、互換性の問題も頻発します。詳細なインストールマニュアルを整備する専任スタッフまで配置したのですが、それでも約2割のエンジニアが環境構築に失敗し、Q&A対応に追われました」とAさんは振り返ります。 「さらに、一度環境を構築できても問題は続きます。シミュレーションやテスト実行中はPCリソースが占有されるため、他の作業が事実上不可能になります。また社外エンジニアとの協業においては、セキュリティ上の制約から開発PC利用に制限がかかることも少なくありません。また、すべての開発PCに対するセキュリティパッチの適用にも膨大な時間を要します。静的解析やテスト、シミュレーションの実行にも長時間を要し、開発サイクル全体が遅延する要因となっていました」とAさんは説明します。 このような開発環境では、ソフトウエアの開発量が増大するSDV時代に対応することは難しくなります。そこでAWSは、従来のオンプレミスでの開発環境の課題解決のために、主に次の２つのソリューションを提供しています。 開発環境課題を解決するためのAWSソリューション ２選 1. Research and Engineering Studio on AWS (RES) RESに関する情報　 GitHub 　 AWS Document 　 AWS Blog 　 YouTube RESの特徴的な機能として、 専用ウェブポータルからデスクトップ環境を簡単に作成 できることが挙げられます。 各プロジェクトでデスクトップイメージを保存 し、チームメンバーがそれを必要に応じてデプロイできる柔軟性も備えています。さらに、共有データストアを活用した共同作業環境の構築や、既存のID管理インフラ（AWS Managed Microsoft AD）との統合も実現しています。 先ほどの車載ソフトウエア開発の例では、RESを導入することで彼らの課題を以下のように解決できます： 迅速な環境構築 : 専用ウェブポータルからデスクトップ環境を短時間で作成でき、数ヶ月かかっていたPC調達・環境構築のプロセスを大幅に短縮 環境の標準化と再利用 : プロジェクト毎にデスクトップイメージを保存し、チームメンバーが即座にデプロイできるため、環境構築の失敗によるQ&A対応の負担が限りなく軽減される 共同作業の効率化 : 共有データストアを活用した共同作業が可能となり、OEM、サプライヤーが所属するチームのコラボレーションが促進される セキュリティの強化と簡素化 : 既存のID管理インフラ（AWSマネージドAD）との統合により、社外エンジニアとの協業におけるセキュリティ課題が解決され、一元的なセキュリティ管理が可能 メンテナンス作業の軽減: セキュリティパッチを当てた開発環境をイメージとして保存することで、開発者は最新の環境をデプロイすることが可能 2. Virtual Engineering Workbench (VEW) ステランティスの事例で紹介したVirtual Engineering Workbenchは、AWSのソリューションとしても展開しています。 このソリューションは、前述のRESで提供する開発環境やシミュレーション環境だけではなく、特定の仮想ECUのイメージも管理することで、今まで評価ボードを調達しなければECUのテストができなかった機能テストや結合テストが、仮想環境で実現することを可能とします。ステランティスの事例では、Github actionsやArtifactoryを用いたDevOpS環境の構築と、そのWorkflowで作成したアーティファクトの仮想ECUのバイナリファイルを、専用線で接続したオンプレミスのHILS環境へ連携するユースケースも実現しています。ご興味のある方は、こちらの ブログ もご覧ください。 Shift Leftを実現する仮想ECU技術 車載ソフトウエア開発のV字モデルの開発プロセスでは、ECU間の結合テストがV字の右側（後半）で実施されることがありました。右側の段階で不具合が発見されると、開発の手戻りが大きくなり、コストや時間の増大につながっており、多くのお客様が仮想ECUに興味を持っていただいています。 1. AWS Graviton と ARM on ARM技術 AWSはARMアーキテクチャを採用したデータセンター向けLSIであるGravitonを自ら設計し、2015年にLSI設計会社のAnnapuruna Labsを完全子会社化することでその技術基盤を強化しました。特に自動車開発において重要な点として、 AWS Graviton は、ARMとの協力により、実際のECUで使用されるARMのCortex-A、Cortex-M、Cortex-Rシリーズの命令コードをAWS Graviton上でそのまま実行できる「ARM on ARM技術」を搭載しています。これにより、仮想ECUの環境を正確かつ効率的に構築することが可能となっています。 このARM on ARMの技術を活用したソリューションがAWS Marketplaceで公開されました。Corellium社が提供する Atlas Private Cloud です。 詳細は、 Marketplaceのページ をご覧頂ければと思いますが、このAtlas Private Cloudは、 AWS Graviton 4 c8g.metal24xl EC2インスタンス上で、32ビットと64ビットのArm Cortex A、R、MコアをベースにしたARM Virtual Hardware（AVH）を実行することができます。2025年10月現在、AWS Graviton 4 c8g.metal24xl １つのEC2インスタンス上で動作可能なAVHは、トータル80 core分で、１つのEC2インスタンス上で複数の仮想ECUを起動することが可能です。今まで、制御系ECUを仮想化する場合、x86上のEC2インスタンスでエミュレーターを動かしいるのが通常でしたが、GravitonとARM on ARM技術を利用したソリューションで解決できるようになるケースが期待できます。 例えば、2025年のAWS Summit JapanのAutomotiveデモブースでは、下記の構成でコックピットとパワートレインのECUを仮想化し、Autosar APのSOME/IPで接続するデモンストレーションを紹介しました（下の図）。③の仮想ECUのスタックでは、AWS Graviton EC2 + Corellium上で、Cortex-R82AEのVirtual Hardwareを動作させ、パワートレインのアプリケーションを動作させています。 2. QNX Hypervisor on AWS Blackberry社のQNXが、 QNX Hypervisor 2.2 をAWS Marketplaceから提供しています。2025年10月現在、AWS上でQNX Hypervisor 2.2を利用するには、Blackberry社と別途ライセンス契約が必要になります。ご興味がある方は、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWS QNX Hypervisor 2.2 on AWSは、AWS Graviton EC2インスタンスである、c6g.metal, r6g.metal, m6g.metalインスタンスで稼働します。アプリケーションから周辺デバイスへのアクセスは、Hardware Abstraction Layer（HAL層）のVirtIO経由で行います。仮に、従来のアプリケーションを、QNX Hypervisor 2.2上で仮想化するには、そのアプリケーション内で、ハードウエアに依存した処理をVirtIOで分離させる必要があります。どのハードウエアへのアクセスを抽象化するかという点において、サポートするVirtIOのバージョンやQNXとのライセンス契約にも依存しますので、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWSに関する情報は以下のブログでもまとめられています。 Elevating cluster software development with QNX Hypervisor on AWS おわりに このブログでは、SDV時代を支えるAWSソリューションとして、開発環境と検証環境の２点に絞って紹介しました。特に、開発環境の課題については多くのお客様が解決したい課題ではないかと思います。量産開始後も継続してソフトウエアのアップデートが本格化する将来、開発環境を必要に応じて伸縮自在に調整することが望まれ、クラウドベースのエコシステムを構築していくことは多くのお客様において急務となっています。このブログを読んでAWSの人と少しお話してみたいなと思われる読者様がいらっしゃいましたら、お近くのAWSのアカウントチームや AWS for Automotive （チャット）までご連絡下さいませ。 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 自動車製造領域のお客様を支援するシニアソリューションアーキテクト。長年乗っていた車を最近買い替えたところ、車載ソフトウェアの目覚ましい進化に驚かされる日々を過ごしています。今後さらに高度な運転支援システムが普及することで、交通死亡事故ゼロの社会へと一歩ずつ近づいていくでしょう。そのような未来の実現に貢献すべく、自動車産業のお客様のイノベーションを技術面からバックアップしています。

イベント概要 AWS は Amazon の流通小売事業における知見と経験をもとにソリューションを提供しており、流通小売・消費財業界におけるイノベーションのカギとして、「カスタマーエンゲージメント」「デジタル コマース」「インテリジェント・サプライチェーン」「マーチャンダイジング & プランニング」「スマートストア」の 5 つのテーマを重視しています。 本イベントでは、この 5 つのテーマから、特に「カスタマーエンゲージメント」「デジタル コマース」 「スマートストア」の 3 つのテーマにフォーカスをして、AWS のテクノロジー、専門知識を活用して提供しているソリューションプロバイダーから業界に固有の課題と機会に応えるサービスやベストプラクティスをご紹介します。 「イノベーションを加速させたいが、スピードや人材が課題」といった状況でもすぐに活用できるソリューションを学び、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします。 日時：2025 年 11 月 25 日（火）16:00–19:00（15:30 受付開始） 場所：AWS 目黒オフィス 目黒セントラルスクエア 21 階（東京都品川区上大崎 3-1-1） 主催：アマゾン ウェブ サービス ジャパン合同会社 参加費：無料（要事前申込） 参加申込：こちらの お申込みフォーム からお申込みください。 展示テーマと出展企業 「カスタマーエンゲージメント」 カスタマー 360° によって顧客セグメントの関係性や特徴、顧客生涯価値を理解し、CRM、顧客データプラットフォーム、コンタクトセンター DX など、データ主導のインサイトによるカスタマーエンゲージメントの促進に役立つソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ Amplitude Analytics 合同会社 Braze 株式会社 株式会社電通デジタル 株式会社サーバーワークス トレジャーデータ株式会社 「デジタルコマース」 生成 AI を利用した魅力的なサイトや、俊敏なコマース基盤など、デジタルコマースソリューションへの投資は不可欠です。デジタルコマースのイノベーションを加速し、あらゆるチャネルでカスタマーエクスペリエンスを高めるためのソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ アジアクエスト株式会社 Contentsquare Japan 合同会社 「スマート ストア」 小売業に新たな収益の柱をもたらすことが期待される店舗内の先進ソリューションや、顧客接点の可能性を広げる POS データ活用、店舗省人化に応える最新のテクノロジーなどをご紹介します。 ＜出展企業（アルファベット順）＞ フォージビジョン株式会社 富士ソフト株式会社 株式会社インテック ソニー株式会社 株式会社ティールテクノロジーズ 株式会社 USEN Camera Solutions 来場者特典 事前お申込みのうえ当日ご来場いただきましたお客様へ 先着 150 名限定 で、イベント特製のステンレスマグカップ（AWS ロゴ入り）をプレゼントいたします！ ※ 画像はイメージです。実物と異なる場合がございます。 当日はパートナー各社のブースにて、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします この特別な機会をお見逃しなく。お申し込みは こちら から。 皆様のご参加を楽しみにお待ちしております！

本記事は、2025 年 9 月 17 日に公開された Supercharge your organization’s productivity with the Amazon Q Business browser extension を翻訳したものです。翻訳はテクニカルアカウントマネージャーの竹林聡が担当しました。 Amazon Q Business のような生成 AI ソリューションは、従業員の働き方を変革しています。あらゆる業界の組織が、意思決定プロセスを加速するために、ますます散在するデータから価値のある洞察を引き出すことができるこれらのツールを採用しています。しかし、生成 AI ツールの導入には課題もあります。 生成 AI ソリューションの実装において、2 つの障壁が浮上しています。1 つ目は、ユーザーが慣れ親しんだワークフローを放棄し、データを手動で AI アシスタントに転送して分析する必要に迫られることです。これにより、不要な手間が生じ、効果が得られるまでの時間が長くなってしまいます。2 つ目は、一般的に使用されているソフトウェアに生成 AI ツールが組み込まれていないため、従業員が AI で生産性を大幅に向上できる機会を見出すことが難しいという点です。 職場向けに特化した生成 AI アシスタントの Amazon Q Business が登場し、企業データやエンタープライズシステムにシームレスに接続することで、会話を行い、複雑な問題を解決し、アクションを実行できるようになりました。Amazon Q Business は、従業員に関連情報とアドバイスへの即時アクセスを提供し、タスクを効率化し、意思決定を加速し、職場での創造性とイノベーションを促進します。最近、Amazon Q Business でブラウザ拡張機能をリリースし、現在 Amazon Q Business の購読者 (Lite および Pro) が利用できるようになりました。Amazon Q Business ブラウザ拡張機能により、Amazon Q Business の機能を直接ブラウザで利用できるようになり、コンテキストを認識した生成 AI サポートを受け、日常のタスクに対する即時のサポートを得ることができます。 本ブログでは、チームが AI を活用したインサイトとサポートにスムーズにアクセスできるように、この解決策を企業に実装する方法をご紹介します。 Amazon Q Business ブラウザ拡張機能のユースケース Amazon Q Business ブラウザ拡張機能は、すべての Amazon 社員に展開されており、毎日数万人のユーザーの生産性を向上させています。このセクションでは、Amazon 社員が生産性を向上させるために Amazon Q Business ブラウザ拡張機能を使用している、最も効果的なユースケースをいくつかご紹介します。 Web コンテンツの分析 ビジネスチームと技術チームは、企業データ外にある各種レポート、競合分析、業界文書の情報を分析・統合して、インサイトと戦略を構築する必要があります。戦略に関する提言は、検証済みのデータソースと信頼できる業界情報に基づいていることを確認しなければなりません。さらに、複数のソースにまたがるパターンの特定は、時間がかかり複雑な作業です。Amazon Q Business ブラウザ拡張機能を使用することで、戦略担当者は人間の判断を活かしながら、信頼できる社内外のデータソースから数秒で業界のインサイトを生成し、トレンドを特定することができます。 以下のデモビデオをご覧ください: コンテンツ品質の向上 Amazon Q Business ブラウザ拡張機能は、生成AI アシスタントでは容易に利用できない背景情報を組み込むことができる独自の機能を提供します。Amazon Q Business ブラウザ拡張機能を使用すると、通常の生成AI アシスタントでは利用できない複数の異なるソースを問い合わせに含めることで、コンテンツの作成と品質向上が可能になります。さまざまなソースからのコンテンツをリアルタイムで確認し、Web ベースのスタイルガイドやベストプラクティスを組み込んでコンテンツ作成を加速することができます。 以下のデモビデオをご覧ください: ソリューションの概要 以下のセクションでは、組織で Amazon Q Business をすでに有効化している場合の Amazon Q Business ブラウザ拡張機能の使用開始方法について説明します。詳細については、 Amazon Q Business ブラウザ拡張機能の使用設定 をご覧ください。 前提条件 ブラウザ拡張機能をデプロイする前に、このセクションの前提条件の手順を完了してください。 Amazon Q Business アプリケーションの作成とユーザーのサブスクリプション設定 Amazon Q Business ブラウザ拡張機能は Amazon Q Business の機能であり、ブラウザ拡張機能を有効にする前に、お客様は Amazon Q Business アプリケーションを作成し、ユーザーのサブスクリプション登録を行う必要があります。Amazon Q Business の使用開始方法の詳細については、 Amazon Q Business の使用を開始する をご覧ください。 Amazon Q Business のWeb機能のセットアップ ブラウザ拡張機能は、Amazon Q Business の Web インターフェースクライアントを使用して、ユーザーの認証と Amazon Q Business の機能提供を行います。ブラウザ拡張機能を有効にする最初のステップは、Amazon Q Business の Web インターフェースを作成することです。すでにユーザー向けの Web インターフェースを作成している場合は、このステップをスキップできます。ただし、Amazon Q Business API を使用してカスタム Web インターフェースを開発している場合は、以下の手順に従って Amazon Q Business の Web インターフェースを作成してください： Amazon Q Business コンソールで、Amazon Q Business アプリケーションに移動します。 Web experience settings セクションには、Web エクスペリエンスがすでにデプロイされているかどうかが表示されます。Web エクスペリエンスがデプロイされていない場合、このセクションは空白で、「A web experience needs to be created before deploying.」というメッセージが表示されます。 アプリケーションの詳細ページの上部で、 Edit を選択します。 Outcome で、 Web experience を選択します。 Update を選択します。 この手順が完了するまでに数分かかる場合があります。 Web エクスペリエンスをデプロイすると、Amazon Q Business アプリケーションの詳細ページに、Web エクスペリエンスがホストされている URL が表示されます。この URL は後で使用するため保存しておいてください。 大規模言語モデルへのクエリ送信権限の付与 Amazon Q Business ブラウザ拡張機能は、ユーザーのプロンプトと共にWebページのコンテンツをファイル添付として渡すことで、ユーザーのWebページのコンテキストをクエリに含めることができます。ファイル添付機能は一般知識モードでのみ利用可能であるため、ブラウザ拡張機能の全機能を活用するには、Amazon Q Business の管理者がユーザーに対して大規模言語モデル (LLM) に直接クエリを送信する権限を付与する必要があります。この前提条件がない場合、ユーザーはブラウザ拡張機能を通じて自社の知識にのみアクセスでき、Webページのコンテンツについて Amazon Q Business に質問することはできません。 Amazon Q Business はユーザーの会話データを保存せず、クエリや会話を LLM のトレーニングに使用することはありません。会話はアプリケーション内に 30 日間のみ保存されます。以下のスクリーンショットに示すように、Amazon Q Business の Web インターフェースにアクセスし、ナビゲーションペインで Chat を選択することで、これらの会話を削除できます。 ユーザーが Amazon Q LLM に直接クエリを送信できるようにするには、以下の手順を実行します： Amazon Q Business コンソールで、アプリケーションに移動します。 ナビゲーションペインで Admin controls and guardrails を選択します。 Global controls セクションで、 Edit を選択します。  Allow end users to send queries directly to the LLM を選択します。   Save を選択します。 これでユーザー向けにブラウザ拡張機能を有効化する準備が整いました。 Amazon Q Business ブラウザ拡張機能の設定 ブラウザ拡張機能の前提条件を完了したので、以下の手順に従ってユーザー向けにブラウザ拡張機能を有効化してください： Amazon Q Business コンソールで、アプリケーションに移動します。 ナビゲーションペインの Enhancements から Integrations を選択します。 Browser extensions セクションで、 Edit を選択します。 有効にしたいブラウザ拡張機能のチェックボックスを選択します: Chromium チェックボックスは、Google Chrome と Microsoft Edge ブラウザをサポートする Chrome ストア拡張機能を有効にします。 Firefox チェックボックスは、Firefox 向けアドオンを有効にします。 それぞれの Learn more セクションにあるリンクを使用して、拡張機能の Chrome または Firefox ストアページを表示することもできます。 Save を選択します。 ユーザーは次回 Amazon Q Business の Web インターフェースにログインする際に、Amazon Q Business ブラウザ拡張機能のインストール手順が表示されます。まだの場合は、前のステップで取得した Web サービスの URL をユーザーと共有して、ブラウザ拡張機能をインストールするための手順に従えるようにしてください。 IAM フェデレーション認証を使用する場合の Amazon Q Business ブラウザ拡張機能の有効化 Amazon Q Business アプリケーションで外部のアイデンティティプロバイダー (IdP) を使用している場合、ユーザーがブラウザ拡張機能を使用できるようにするには、外部プロバイダーでブラウザ拡張機能を許可リストに追加する必要があります。ブラウザ拡張機能を有効にするには、IdP で以下の URL を許可リストに追加してください。 Chromium ブラウザ拡張機能 (Google Chrome と Microsoft Edge に対応) の場合は、 https://feihpdljijcgnokhfoibicengfiellbp.chromiumapp.org/ を使用します Mozilla Firefox ブラウザ拡張機能の場合は、 https://ba6e8e6e4fa44c1057cf5f26fba9b2e788dfc34f.extensions.allizom.org/ を使用します Amazon Q Business アプリケーションの認証ソリューションとして AWS IAM Identity Center を使用している場合は、前述の手順を実行する必要はありません。 ブラウザ拡張機能の使用開始 Web エクスペリエンス URL をユーザーと共有すると、ユーザーはそれを使用してブラウザ拡張機能のストアページを見つけ、ブラウザ拡張機能をインストールできます。ユーザーは以下の手順に従うことができます。 管理者から提供された Amazon Q Business の Web インターフェースにログインします。 管理者があなたのためにブラウザ拡張機能を有効にしたことを知らせるバナーが表示されます。 Install extension を選択します。 使用しているブラウザに応じて、リンクをクリックすると適切な Amazon Q Business ブラウザ拡張機能のストアページに移動します。 Add to Chrome を選択するか、お使いのブラウザに応じたインストールオプションを選択します。 拡張機能をインストールすると、ブラウザのツールバーの Extensions の下に表示されます。ピンアイコンを選択して、ブラウザ拡張機能をピン留めすることができます。 ブラウザ拡張機能を開くと、次のスクリーンショットのようなサイドペインが表示されます。開いているタブから正しい Web エクスペリエンス URL を自動的に検出し、サインインをサポートします。検出されない場合は、管理者から提供された Web エクスペリエンス URL を Amazon Q URL セクションに入力し、 Sign In  を選択してください。 サインインすれば、すぐに使用できます！生産性を向上させるためにこの拡張機能をどのように活用できるか、先ほどの Amazon のユースケースに関するセクションを参考にしてください。 ユーザーに代わって Amazon Q Business ブラウザ拡張機能をデプロイ 一部の管理者は、導入を効率化し加速させるために、ユーザーのブラウザに Amazon Q Business ブラウザ拡張機能を直接インストールすることを選択する場合があります。 企業は、さまざまなモバイルデバイス管理ソフトウェアを使用し、ブラウザポリシーに関する要件も異なります。 Amazon Q Business ブラウザ拡張機能を導入するには、以下のリソースを参照してください： Mozilla Firefox ポリシー設定 Google Chrome ポリシー設定 Microsoft Edge: ポリシー設定 リファレンスガイド エンタープライズ向け Amazon Q Business ブラウザ拡張機能のカスタマイズ 一部の管理者は、企業のニーズに合わせて Amazon Q Business ブラウザ拡張機能の外観と操作感をカスタマイズすることがあります。このセクションでは、拡張機能でサポートされているカスタマイズ機能と、ユーザーのブラウザで設定する対応するブラウザ拡張機能ポリシー値について説明します。 ブラウザ拡張機能のログインページにおける Amazon Q Business URL 入力の削除 ユーザーのサインイン時に Amazon Q Business Web エクスペリエンス URL の入力を求めたくない場合は、 Q_BIZ_BROWSER_EXTENSION_URL ポリシーにユーザー向けの適切な Amazon Q Business Web エクスペリエンス URL を設定することで、ユーザーに代わってデフォルト URL を設定できます。 ブラウザ拡張機能のツールバーアイコンの置き換え ブラウザー拡張機能のツールバーアイコンを変更するには、ユーザーに対して以下のブラウザーポリシーキーのいずれかまたは複数の値を、PNG や SVG 画像の URL、または有効な datauri に設定します。 Q_BIZ_BROWSER_EXTENSION_ICON_128 (必須) Q_BIZ_BROWSER_EXTENSION_ICON_16 (オプション) Q_BIZ_BROWSER_EXTENSION_ICON_32 (オプション) Q_BIZ_BROWSER_EXTENSION_ICON_48 (オプション) ブラウザ拡張機能ウィンドウのロゴまたはアイコンの置き換え ブラウザ拡張機能のウィンドウでロゴやアイコンを変更するには、 Q_BIZ_BROWSER_EXTENSION_LOGO ポリシーキーの値に、PNG または SVG 画像の URL、もしくはユーザー向けの有効な datauri を設定してください。 拡張機能のウィンドウに表示される名前の変更 ブラウザ拡張機能のウィンドウ内で「Amazon Q」、「Amazon Q Business」、「AWS」、「Amazon Web Services」への参照を任意の名前に置き換えるには、 Q_BIZ_BROWSER_EXTENSION_ENTERPRISE_NAME ポリシーキーの値にユーザー向けの新しい名前を設定します。 ブラウザ拡張機能のマウスオーバー時のテキストのタイトル変更 ブラウザ拡張機能にマウスオーバー時に表示されるテキストのタイトル (前のスクリーンショットで示した「Amazon Q Business has access to this site」) を変更するには、 Q_BIZ_BROWSER_EXTENSION_TITLE_NAME ポリシーをユーザーに適切な文字列に設定してください。 ブラウザ拡張機能のフッターにある AI ポリシーリンクの置き換え ブラウザ拡張機能のフッターにあるリンクテキストを置き換えるには、 Q_BIZ_BROWSER_EXTENSION_FOOTER_POLICY_NAME をユーザーに適した文字列に設定してください。 ブラウザ拡張機能のフッターにある URL を置き換えるには、 Q_BIZ_BROWSER_EXTENSION_FOOTER_POLICY_URL をユーザーにとって適切な URL に設定してください。 おめでとうございます！あなたとあなたの組織は、ブラウザ上の作業に対する 生成AI による支援を受ける準備が整いました。 リソースの削除 このセクションでは、ブラウザ拡張機能を無効化または削除する手順、およびユーザーのデプロイメントとカスタマイズを元に戻す手順について説明します。 Amazon Q Business コンソールを使用した Amazon Q Business ブラウザ拡張機能の無効化 Amazon Q Business ブラウザ拡張機能は、ユーザーがブラウザから拡張機能を削除する前でも、Amazon Q Business コンソールからいつでも無効化できます。手順は以下の通りです： Amazon Q Business コンソールで、 Applications に移動します。 ナビゲーションペインの Enhancements から Integrations を選択します。 Browser Extensions  セクションで、 Edit を選択します。 無効にしたいブラウザ拡張機能のチェックボックスを外します: Chromium チェックボックスを外すと、Google Chrome と Microsoft Edge ブラウザをサポートする Chrome ストア拡張機能が無効になります。 Firefox チェックボックスを外すと、Firefox ブラウザ用のアドオンが無効になります。 Save を選択します。 ユーザーに代わって Amazon Q Business ブラウザ拡張機能のデプロイを元に戻す 企業は、さまざまなモバイルデバイス管理ソフトウェアを使用し、ブラウザポリシーに関する要件も異なります。 ブラウザポリシー設定を更新してブラウザ拡張機能をデプロイした場合は、各ブラウザのポリシー設定に関するドキュメントに従って、これらのポリシーを削除する必要があります。 Mozilla Firefox ポリシー設定 Google Chrome ポリシー設定 Microsoft Edge: ポリシー設定 リファレンスガイド このブログで先述したように、ブラウザポリシーを変更して Amazon Q Business ブラウザ拡張機能をカスタマイズした場合、ブラウザポリシー設定から対応するポリシーエントリを削除するだけで、これらのカスタマイズを元に戻すことができます。 まとめ このブログでは、Amazon Q Business ブラウザ拡張機能を使用して、チームに AI を活用したインサイトとサポートをスムーズに提供する方法を紹介しました。このブラウザ拡張機能は、Lite サブスクリプションの一部として、US East (N. Virginia) および US West (Oregon) の AWS リージョンで Mozilla、Google Chrome、Microsoft Edge に対応しています。ブラウザ拡張機能の使用に追加コストはかかりません。 まず、Amazon Q Business コンソールにログインし、Amazon Q Business アプリケーション用のブラウザ拡張機能をセットアップします。詳細については、 Amazon Q Business ブラウザ拡張機能の使用設定 をご覧ください。 著者について Firaz Akmal は Amazon Q Business のシニアプロダクトマネージャーで、AWS に 8 年以上在籍しています。顧客の声を代弁し、AWS での検索や生成 AI のユースケースの変革を支援しています。仕事以外では、太平洋岸北西部の山々で過ごしたり、娘の視点を通して世界を体験することを楽しんでいます。 Abhinand Sukumar は、AWS の Amazon Q Business のシニアプロダクトマネージャーとして、革新的な生成 AI ソリューションのプロダクトビジョンとロードマップを推進しています。Abhinand は、ブラウザ拡張機能を含む統合を成功させるため、お客様とエンジニアリングチームと緊密に協力しています。教育、人工知能、デザイン思考に深い情熱を持ち、生成 AI エクスペリエンスと AI/ML 教育デバイスに関する専門知識を有しています。AWS に入社する前は、ネットワーク業界でエンベデッドソフトウェアエンジニアとして勤務し、テクノロジー分野で5-6年の経験があります。

本稿は、沖縄県の小売企業である株式会社サンエー（以降、サンエー）様の内製によるモダナイゼーションのお取り組みをご紹介する AWS との共同寄稿です（サンエー: 丸山氏、高原氏、宮良氏、AWS: 中島）。 はじめに サンエーは、1950 年創業、1970 年設立の沖縄県を拠点とする総合小売企業です。食料品、衣料品、家電、日用雑貨等の住居関連用品の小売業を主力事業とし、沖縄県内で78店舗（2025 年 10 月現在）の小売店舗および外食レストラン等のフランチャイズを展開しています。2025 年 6 月にはサンエー石垣シティをリニューアルオープンするなど、ビジネス拡大を進めています。また、2024 年度は過去最高益となる売上高 2,275 億円を達成しました。ビジネスが成長する中でシステムのモダナイゼーションへの機運も高まり、基幹システムのモダナイズを始められたサンエー様のこれまでの活動と AWS の支援を紹介します。 モダナイゼーションのきっかけ AWS 中島: モダナイゼーションの取り組みのきっかけを教えてください。 サンエー丸山氏: そうですね、きっかけをお伝えする前に、まずは弊社の内製化の歴史を少しご紹介させてください。もともとサンエーでは IBM AS/400 というメインフレームで社内システムを内製にて構築していました。それを約 10 年ほど前から、アプリケーションをスクラッチでつくり直しながら内製で AWS に移行し続けています。利用しているプログラミング言語がシェルスクリプト形式ということもあり、移行先のアーキテクチャは EC2 と EFS をメインで利用しています。DBを使わずにファイルを量産するプログラミング言語なので、どうしてもEFSの利用料が常に膨らんでいきます。モダナイゼーションの初期の検討では RDBMS を用いた IaaS での 3 層 Web を一度経由する案もありましたが、その構成の知見が社内に多いわけでもありませんでした。そのような背景もあり、今後、内製でスクラッチ開発するシステムでは、サーバレスを採用したいと考えていました。 AWS 中島: 2021 年に参加された ( ANGEL Dojo ) も同じような思いがあられたからでしょうか？ サンエー丸山氏: そうですね。サーバレスを知識としては知っていたものの、実際に作ってみたことがほとんどなくて。このイベントに参加して手触り感が欲しかったというのもあります。ただ、当時は今回のテーマのモダナイゼーションに本腰を入れていたというよりは、サーバレスという便利なものがある、AWSは EC2 と EFS だけじゃない、というのをチームメンバーや会社に知って欲しかったという意図の方が大きかったです。 AWS 中島: なるほど、ありがとうございます。では、モダナイゼーションに本腰を入れて活動を開始されたのはいつ頃からでしょうか？ サンエー丸山氏: 以前より検討はしていたのですが、2023年にパートナーの支援を受けながらポイントシステムをサーバレスで内製構築した経験がきっかけとなり、徐々に本格化し始めました。実際に組織体制を変更して、目にみえるかたちで活動し始めたのは 2024 年からだと思います。前述のコストの話だけではなく、これまでの技術スタックでは、社内からの開発要望に機能的に答えられないものが出てきたり、開発体験やシステム運用の課題に気づいたり、と、そういうものが積み重なってモダナイゼーションを本気で実行しないと先がないのではないかと思うようになりました。そういう意味ではトップダウンで発令されたとか、大きな事故があったとか、そういう大きなきっかけではないんです。でも、ビジネスをさらに成長させるためには必要だと感じていました。 モダナイゼーションへの一歩目を踏み出す AWS 中島: では、2024 年からの活動について教えてください。 サンエー丸山氏: サンエーのシステムのあり方は、今まで、世の中のベストプラクティスに則ったかたちがあまり取れていませんでした。ですので、自分たちのやり方で進める前にきちんと学んでみようと思ったんです。そこで出会ったのがストリームアラインドチームという考え方でした。マイクロサービスを技術として取り入れるだけでは成功せず、組織も変える必要があることを知ったんです。AWS との打ち合わせの中でも、そういうお話をしてくださいましたよね。 AWS 中島: はい、コンウェイの法則(※)などを含めてお話しさせていただきました。チームトポロジーの本を握りしめて会話したことを覚えています。その後、本当に組織を変えられたと聞いた時は正直驚きました。 ※ システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。 サンエー丸山氏: モダナイゼーションに必要なことはやろうと決めていましたので、上司に掛け合ってチームを再編しました。組織を変える目処がついた後に困ったのが EC2 + EFS からどういう形に変えていこうかということでした。サーバレスがいいなとは思っていたのですが、具体的にどういうかたちが良いのかについては不透明でした。社内エンジニアのスキルセットはバニラ (素の) html, js と sh をラップした有償製品のコマンドに偏っており、いわゆる Web アプリケーションフレームワークや汎用プログラミング言語に明るい人間もいない。そんな時、AWSからご提案をいただいたんです。 AWS 中島: 貴社を日々ご支援する中で、課題は広く難易度は高いが、それらが点になっており、うまく整理がついてないように感じました。そこで、1/デベロッパートランスフォーメーション (以降 DevTx) チームから Discovery ワークをご提供することによって課題の整理と短距離の目標を定義すること。2/内製メンバーで作れるようになるきっかけ作りのためにプロトタイピング (以降 Proto) チームと協業で開発してみること。3/協業の期間は短くそれだけで作れるようになるわけではないため、プロトタイピング後、実際の開発において伴走しながらスキルアップを支援してくれる AWS パートナーのご紹介。ここまでを 1 セットでご提案しました。 サンエー丸山氏: どこまでやれるのか不安もありましたが AWSの提案に乗ってみようと思いました。2024 年11月のキックオフ後、Discovery ワークを進める中で、コスト以外にも、開発テスト、運用、認証、UI など幅広い課題を整理することができました。また Proto の方をテックリードとして一緒に開発してみることで、サーバレス, REST, SPA + API, フロントエンド Framework, OSS の活用などの開発方法を実際に作りながら学ぶことができました。言語を全て TypeScript で統一したのもプロトタイピングの進め方として良かったと思います。様々な体験が得られましたが、ワークショップ後にモダナイゼーションへの投資を役員と合意することができたことはとても大きな成果でした。先述のとおり、モダナイゼーションはトップダウンで降りてきたものではないため、モダナイゼーションを進めるためには役員との合意が必須だったんです。役員合意が取れたのは 2025年3月のことでした。 図は プロトタイピングの成果物に対して DevTx チームと実施したリスクストーミングの一コマ AWS 中島: ここで、Discovery ワークとプロトタイピングにご参加いただいたメンバーの高原様と宮良様にご感想を聞いてみたいと思います。高原様いかがでしたか？ サンエー高原氏: 協業で開発したのは 2 週間という短期間でしたが、モダンな開発手法やツールに触れることができて非常に勉強になりました。Git の使い方や サーバレスに関する AWS のサービスについて実際に手を動かしながら学べたのは大きな収穫でした。TypeScript は フロントエンドでもバックエンドでも CDK でも使えることを体感したため、今後もしっかりと学習していく必要があると感じています。エラーメッセージを読む習慣やドキュメントを参照する姿勢は身についたので、これを継続していきたいと思います。チーム開発の楽しさも実感できました。モブプログラミングで他の人の考え方を知ることができたり、困った時にすぐに相談できる環境があったのは心強かったです。中島さんがライブラリの調査やドキュメント読みを実際にやってみせてくださったのが非常に参考になりました。本番開発に向けて、基礎的な部分をしっかりと固めて、チームにより貢献できるよう頑張りたいと思います。 AWS 中島: ありがとうございます。高原様はメンバーの中で IT 経験が一番少ない中でご参加くださいました。では、続いて宮良様、いかがでしょうか？ サンエー宮良氏: 2週間をとおして、一番の大きな変化は「調べる文化」が身についたことだと思います。既存の開発言語では調べても情報が少なく、誰かに聞くか、とりあえず書いてみるという文化でしたが、モダンな開発では豊富なドキュメントやコミュニティの情報があることを実感できました。技術的には、React の概念や TypeScript の型システムなど、既存の開発言語とはまったく異なる概念に苦戦し、従来の開発経験とのギャップが大きく、理解に時間がかかりました。ただ、何かを作る楽しさを久しぶりに感じることができたのは大きな収穫でした。コードの品質についても多くの気づきがありました。Proto 担当の和田さんからのレビューコメントで、命名規則や処理の順番、可読性の重要性を学びました。「動けばいい」から「他の人が読みやすいコード」を意識する必要があると強く感じました。本番開発に向けては、基礎的な概念の理解を深めることと、自分の理解を言語化する練習が必要だと思います。生成 AI に自分の理解が合っているか質問しながら学習を進めていきたいと思います。 AWS 中島: 宮良様ありがとうございます。宮良様は貴社独自の生成 AI プロンプト作成アプリの開発もしていただいているので、ぜひ基幹システムのモダナイゼーションでもご活躍いただきたいです。 基幹システム開発に向けて AWS 中島: それでは、Discovery ワーク・プロトタイピング後の活動について教えてください。 サンエー丸山氏: 現在、システムのモダナイゼーションに向けて社内の認証認可基盤を作り直しています。これは Discovery ワークで明らかになった認証認可の課題を解決してから、アプリケーション側をモダナイズするという方針にしたためです。認証認可基盤は AWS のパートナーに伴走いただきながら進めています。 AWS 中島: 今の活動において Discovery ワークやプロトタイピングの効果を感じていただけているでしょうか？ サンエー丸山氏: こちらを見てみてください。これは高原さんと宮良さんが パートナー企業と議論して書いたホワイトボードです。Discovery ワークやプロトタイピング後に 2 人が追加で学んだ部分もありますが、それでも EC2 と EFS の現行のアーキテクチャの説明もおぼつかなかった 2 人が、このようにホワイトボードにアーキテクチャを描き、パートナー企業と議論する姿を見ると、ご提案いただいた活動の効果を感じています。現在開発中の認証認可基盤が完成した後、アプリケーション側のモダナイズを実施する予定です。高原さんと宮良さんにはぜひこのプロジェクトを引っ張っていってもらいたいです。 最後に AWS 中島: 丸山様、高原様、宮良様、本日はありがとうございました。これからも是非 AWS と一緒にモダナイゼーションジャーニーを歩ませていただければと思っております。最後に我々アカウントチームへ今後期待することをお聞かせいただけないでしょうか？ サンエー丸山氏: AWSとの協業は、単なる技術導入に留まらず、私たちの開発文化そのものを変える大きなきっかけとなりました。深く感謝しています。 現在進めている基幹のモダナイゼーションは、その先に見据える AI 活用によるビジネス革新のための重要な布石です。この未踏の領域への挑戦においても、AWS には戦略的パートナーとして、最先端の知見と専門的な支援で私たちの成長を力強くリードしていただけることを期待しています。 AWS 中島: ありがとうございます。ちなみに今回、”序章” ということですが、次回があると思ってよろしいでしょうか？ サンエー丸山氏: そうですね。次回はモダナイズしたプロダクション環境がリリースされた後にまた寄稿させていただければと思います。 サンエー様 著者 丸山 海理 氏 高原 元来 氏 宮良 一輝 氏

デジタル資産決済により、迅速かつ低コストのピアツーピア取引が可能になります。 ブロックチェーンベースの決済システムは、従来の決済方法で企業が直面する主要な課題に対処します。 これには、高い処理手数料、キャッシュフローに影響を与える決済遅延、業務に影響を及ぼす複雑な国際取引などが含まれます。 この投稿では、ブロックチェーンベースのデジタル資産決済システムがどのようにコストと遅延を削減できるかを説明します。 USDC 、 PYUSD 、 USDG などのステーブルコインを例として、AWS 上でサーバーレス決済システムを構築する方法を紹介します。 このソリューションは、従来の決済方法に代わる低コストでスケーラブル、かつ分散型の選択肢を提供します。 実装は GitHub リポジトリ で公開されています。 この投稿は、デジタル資産決済ソリューションの技術的な概要を示すものであり、法的助言や規制上のガイダンスを意図したものではありません。 法的コンプライアンス、検証、確認の要件は管轄区域によって異なる場合があり、読者ご自身の責任です。 この投稿で説明されている決済ソリューションを実装または使用する前に、ご自身でデューデリジェンスを実施してください。 ブロックチェーンベースの決済のメリット デジタル資産決済を導入する企業には、魅力的なメリットがあります。 コスト管理 決済処理のオーバーヘッドの削減 決済効率 ブロックチェーンの確認後に資金にアクセスできます。正確なタイミングはネットワークによって異なります (数秒から数分) グローバル展開 複数の仲介業者を介さずに国境を越えた取引を実行し、為替手数料を排除します トランザクションの可視性 オンチェーン検証による完全なトランザクションの透明性により、監査の効率化 デジタル資産決済は、さまざまなステークホルダーにメリットをもたらします。 加盟店 – 高速で低手数料の決済により、EC （イーコマース）を効率化します。 金融機関 – 決済時間を短縮し、国際送金や資金管理を促進します。 共通のメリット – 通貨交換と決済処理の手数料を最小化します。 最終的に、デジタル資産決済は、マーチャントや金融機関が技術革新を進め、コストを最小化し、新たな機会を引き出すのに役立ちます。 ソリューション概要 このソリューションにより、企業は Ethereum を含む Ethereum Virtual Machine (EVM) 互換ネットワーク全体で、デジタル資産による消費者からの支払いを、完全な自動化と安全な資金処理で受け入れることができます。 テストネットとメインネット環境の両方に対応しています。 リポジトリ では、デジタル資産支払いソリューションをデプロイして使用する手順を順を追って説明しています。 このソリューションの主な機能は以下の通りです。 デジタル資産決済ソリューションの 3 つのコアコンポーネントについて、さらに詳しく見ていきましょう。 請求書ジェネレーター このコンポーネントを使用すると、請求書を生成し、顧客から直接支払いを受け付けることができます。 請求書ジェネレーターは以下の機能を提供します: 確定的な請求書生成 – 請求書ジェネレーターは、請求書とブロックチェーンアドレスの 1 対 1 のマッピングを容易にします。これにより、各支払いが対応する請求書に正しく紐付けられることが保証されます。このシステムは、 アトミックカウンター を Amazon DynamoDB に保存してウォレットインデックスを維持し、高い同時実行シナリオでもスレッドセーフなアドレス生成を維持します。 効率的な鍵管理 – BIP32 / BIP44 は、階層的決定性鍵導出関数を使用して、 AWS Secrets Manager に保存された単一のプライマリシードから多数の鍵パスを生成し、複数のアカウントとアドレスの構造化された管理を可能にします。 UI ですぐに使える出力 – 請求書ジェネレーターは、請求書の入金アドレスと Data URL 形式の Base64 エンコードされた QR コードの両方を返します。これは HTML の タグに直接埋め込むことができます。 セキュリティとプライバシーの強化 – 各顧客は一意の 1 回限りの支払いアドレスを受け取ります。これにより、アドレスの再利用を防ぎ、パブリックブロックチェーン上でユーザーのプライバシーを保護することができます。 簡素化された会計処理 – 合理化された追跡により、会計と監査が容易になります。 定期支払いのシナリオでは、安定した顧客識別子から支払いアドレスを導出するようにソリューションを拡張できます。 これにより、各顧客に対して一貫したウォレットアドレスが作成され、定期支払いが合理化され、顧客の許可リスト登録プロセスが簡素化されます。 支払いの自動検出 「The Watcher」は、自動的な更新情報とイベント駆動型通知による支払い状況の監視を可能にします。 自動支払い検出コンポーネントは、以下の機能を提供します。 最適化されたデータベースクエリ – DynamoDB グローバルセカンダリインデックス ( status-index ) を使用して、 pending 状態の請求書のみをクエリします。これにより、請求書の総量が増加してもクエリのパフォーマンスが維持され、DynamoDB の読み取り消費量が大幅に削減されます。 リアルタイム残高検証 – ETH および ERC-20 トークンの残高を請求書の金額と照合して検証します。 自動ステータス更新 – 十分な支払いが検出されると、請求書を自動的に paid としてマークします。(デフォルトでは、このソリューションはファイナリティやリオーグを考慮しません。より強力な保証が必要な場合は、Watcher の eth_getBalance に finalized ブロックタグを渡すことができます。) 即時通知 – 支払い確認時に Amazon SNS を通じて加盟店への通知をトリガーします。 資金照合 請求書の支払いを受け取った後、資金は安全な管理のために指定された財務ウォレット (できれば高度にセキュアなコールドウォレット) に自動的に移動されます。 これにより、数分以内にオフラインで支払いが安全に処理され、加盟店が選択したウォレットへの資金集約のための監査可能なメカニズムがサポートされます。 ファンド照合プロセスは、以下の機能を提供します。 DynamoDB Streams によるトリガー – フィルタリングされたストリームトリガーを通じて確認済みの支払いを検出します (ステータスが paid )。ネットワークの混雑や一時的なブロックチェーンの問題に対処するための組み込みメカニズムを備えています。 ガスの最適化 – コスト効率の高いトランザクションのために、ネットワークのガス価格を動的に計算します。 ガス補充メカニズム – 専用のホットウォレット「ガスタンク」が、ネットワークのネイティブトークン (例: ETH) の準備金を保持します。これは、ERC-20 インボイスを補充するためだけに使用され、最小限のガス料金で コールドストレージの金庫に集約できるようにします。 安全な転送 – 秘密鍵はメモリ内で決定論的に導出され、保存されません。これらは個々のインボイスからの転送を実行するために使用されます。これは Lambda 内で行われ、AWS は オペレーターによるアクセスはありません 。 ステータスの更新 – 正常に完了すると、インボイスのステータスを swept に更新します。 次の図は、ソリューションのアーキテクチャを示しています。 このアーキテクチャは、サーバーレスなデジタル資産決済処理の PoC （ Proof of Concept ）を目的としており、本番環境で使用できる状態ではありません。 セキュリティ、信頼性、コンプライアンス、監査可能性に関する本番環境の基準を満たすには、追加の機能強化が必要です。 以下のフローの各ステップの番号は、Ethereum ネットワーク上でのステーブルコイン決済を示しており、上記のアーキテクチャ図の番号に対応しています。 加盟店は、 Amazon API Gateway が提供する /create-invoice REST API へのリクエストを通じて、ステーブルコインのインボイスを作成します。これは API キーを使用して保護されています。 AWS Lambda 関数である Invoice Generator がトリガーされ、 AWS Secrets Manager からニーモニック シードフレーズ を取得します。シードフレーズは、インボイスに対応するキーペアを作成 (および復元) するために必要です。 Invoice Generator は Amazon DynamoDB のアトミックカウンターをインクリメントします。アトミックカウンターの値はインデックスを表します。これはシードフレーズと共に使用され、特定の支払いに対する 階層的決定性 (HD) ウォレットアドレスを決定論的に導出します。 Invoice Generator Lambda 関数は新しいインボイスを作成し、 status: pending として DynamoDB に保存します。データは AWS Key Management Service (AWS KMS) を使用して保管時に自動的に暗号化されます。 前のステップで生成された QR コードには、送金先アドレス、通貨、金額がエンコードされており、加盟店に返されます。加盟店は QR コードを顧客と共有します。顧客は、入金アドレスに適切な金額の資金を送信することで、ステーブルコインの支払いを行います。 Amazon EventBridge スケジュールを通じて、Watcher という Lambda 関数が毎分トリガーされます。Watcher は DynamoDB から保留中のインボイスを取得し、提供された RPC エンドポイントを通じて行われた支払いを確認します。支払いが到着した場合、インボイスを paid に更新します。 Watcher Lambda 関数は、 Amazon Simple Notification Service (Amazon SNS) を使用して、加盟店に支払い確認を送信します。 CryptoInvoices データベースで支払いが検出されると (ステータスが paid に遷移すると)、 Amazon DynamoDB Streams を使用してイベントが発行されます。これにより Lambda Sweeper 関数がトリガーされます。 Sweeper 関数は資金の集約トランザクションに必要なガスを計算し、これが ERC20 インボイスであるため Eth をリクエストします。 十分な Eth が利用可能になると、Sweeper 関数はインボイスに関連付けられたトークンをオフラインの保管用ウォレットに送信します。Sweeper 関数は、HD ウォレットのシードフレーズをリクエストし、トランザクションに署名するための秘密鍵を導出することでこれを行います。その後、インボイスは CryptoInvoices データベースで swept としてマークされます。資金の集約プロセス中にエラーが発生した場合、失敗がログに記録され、最大 3 回の再試行が行われます。 加盟店は、API Gateway を使用して公開された REST エンドポイントを通じてインボイスを管理できます (インボイスの現在のステータスを表示したり、保留中のインボイスをキャンセルしたりできます)。 支払い、支払い監視、資金の回収フローの詳細な図解については、 GitHub リポジトリ を参照してください。 まとめ このサーバーレスソリューションは、AWS 上でデジタル資産決済を処理するための安全で効率的、かつコスト効率の高いシステムを提供します。 AWS のサービスとブロックチェーン技術を活用することで、組織は決済処理コストを削減し、資金へのより迅速なアクセスを実現し、キャッシュフローを向上させ、グローバルに事業を展開できます。 本記事は、2025 年 10 月 2 日に公開された Processing digital asset payments on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 GitHub で完全なコードを確認し、AWS 上で安全なサーバーレスデジタル資産決済ソリューションの構築を始めましょう。 著者について Simon Goldberg Simon は、AWS のブロックチェーン/Web3 スペシャリストソリューションアーキテクトです。仕事以外では、音楽制作、読書、クライミング、テニス、ハイキング、コンサート鑑賞、Web3 テクノロジーの研究を楽しんでいます。 David Dornseifer David は、AWS のブロックチェーンおよびコンフィデンシャルコンピュートアーキテクトです。彼は、お客様がエンドツーエンドのブロックチェーンおよびコンフィデンシャルコンピュートソリューションの設計、開発、スケーリングを支援することに注力しています。主な専門分野は、デジタル資産の保管と鍵管理ソリューションです。