11 月 10 日、 AWS Backup での Amazon EKS のサポート が発表され、他の Amazon Web Services (AWS) サービスで信頼されているものと同じ一元化されたプラットフォームを使用して Kubernetes アプリケーションをセキュア化する機能が提供されるようになりました。この統合は、コンテナ化されたアプリケーションを保護しながらクラスター構成とアプリケーションデータの両方にエンタープライズグレードのバックアップ機能を提供するという複雑性を解消します。 AWS Backup は、AWS ワークロードとオンプレミスワークロードの全体でデータ保護を一元化し、自動化するためのフルマネージドサービスです。 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes クラスターの可用性とスケーラビリティを管理するためのフルマネージド Kubernetes サービスです。この新しい機能を使用することで、他の AWS サービスと並行して Amazon EKS 環境全体でのデータ保護の一元的な管理と自動化を行えます。 これまで、お客様が EKS クラスターをバックアップするにはカスタムソリューションやサードパーティツールに頼らなければならず、クラスターごとに複雑なスクリプト作成とメンテナンスが必要でした。AWS Backup での Amazon EKS のサポートは、EKS クラスター (Kubernetes デプロイとリソース) およびステートフルデータ ( Amazon Elastic Block Store (Amazon EBS) 、 Amazon Elastic File System (Amazon EFS) 、 Amazon Simple Storage Service (Amazon S3) のみに保存されているもの) の両方を保護する単一の一元化されたポリシー主導のソリューションを提供し、クラスター全体でカスタムスクリプトを管理する必要をなくことで、このオーバーヘッドを解消します。復元に関しては、これまでお客様は EKS バックアップをターゲット EKS クラスター (ソース EKS クラスターまたは新しい EKS クラスター) に復元しなければならず、復元する前に EKS クラスターインフラストラクチャをプロビジョニングしておく必要がありました。この新しい機能では、EKS クラスターバックアップの復元時に以前の EKS クラスターの構成設定に基づいて新しい EKS クラスターを作成し、この新しい EKS クラスターに復元するオプションもお客様に提供され、EKS クラスターのプロビジョニングは AWS Backup がお客様に代わって管理します。 このサポートには、単一または複数の EKS クラスターを保護するためのポリシーベースの自動化が含まれます。 この単一データ保護ポリシーは、AWS Backup がサポートするすべてのサービスで一貫したエクスペリエンスを提供します。そのため、悪意のある変更や不注意による変更を防ぐためのイミュータブルバックアップの作成が可能になり、お客様が規制コンプライアンスのニーズを満たすために役立ちます。顧客データの損失やクラスターのダウンタイムが発生した場合でも、お客様は使い勝手の良いインターフェイスを使用することで暗号化されたイミュータブルバックアップから EKS クラスターデータを簡単に復元し、EKS クラスターを大規模に実行する事業継続性を維持できます。 仕組み 以下は、AWS Backup で EKS クラスターのオンデマンドバックアップのサポートを設定する方法です。最初にバックアッププロセスのウォークスルーを説明してから、EKS クラスターの復元を実際に行っていきます。 バックアップ AWS Backup コンソール の左側にあるナビゲーションペインで [ 設定 ] を設定してから [ リソースを設定 ] を選択し、AWS Backup での EKS クラスター保護オプションを有効にします。 Amazon EKS が有効になったので、[ 保護されたリソース ] で [ オンデマンドバックアップを作成 ] を選択し、既存の EKS クラスターである floral-electro-unicorn のバックアップを作成します。 [設定] で EKS を有効にすることで、EKS クラスターのオンデマンドバックアップの作成時に EKS が [ リソースタイプ ] として表示されることを確実にします。EKS リソースタイプとクラスターの選択に進みます。 残りの情報はデフォルトのままにしておき、[ IAM ロールを選択 ] を選択して、 私に代わってバックアップを作成および管理するときに AWS Backup が引き受ける必須の許可 を用いて作成およびカスタマイズされたロール ( test-eks-backup ) を選択します。[ オンデマンドバックアップを作成 ] を選択してプロセスを完了します。 ジョブが開始され、EKS クラスターの状態と永続的ボリュームの両方をバックアップし始めます。Amazon S3 バケットがバックアップにアタッチされている場合は、 追加の Amazon S3 バックアップ許可 AWSBackupServiceRolePolicyForS3Backup をロールに追加する 必要があります。このポリシーには、AWS Backup が任意の Amazon S3 バケットをバックアップするために必要な許可が含まれています。これには、バケット内のすべてのオブジェクトと、関連する AWS KMS キーへのアクセスが含まれます。 ジョブが正常に完了し、 floral-electro-unicorn EKS クラスターが AWS Backup によってバックアップされました。 復元 AWS Backup コンソールを使用して、EKS クラスターバックアップの復元プロセスを開始するための EKS バックアップ複合リカバリポイントを選択してから、[ 復元 ] を選択します。 [ EKS クラスターを完全に復元 ] を選択して、EKS バックアップを完全に復元します。既存のクラスターに復元するには、[ 既存のクラスターを選択 ] し、ドロップダウンリストからクラスターを選択します。個々の Kubernetes リソースが復元される順序として、[ デフォルトの順序 ] を選択します。 その後、永続的ストレージリソースの復元を設定します。このリソースは EKS クラスターと共に復元されます。 次に、復元アクションを実行するための [ IAM ロールを選択 ] します。デフォルトでオンになっている [ 保護されたリソースのタグ ] チェックボックスはそのままにしておき、[ 次へ ] を選択します。 [ 復元 ] を選択してプロセスを完了し、ジョブを開始する前に、すべての情報を確認します。 ドロップダウン矢印を選択すると、EKS クラスターの状態とアタッチされている永続的ボリューム両方の復元ステータスの詳細が表示されます。このウォークスルーでは、個々のリカバリポイントのすべてが正常に復元されました。バックアップの一部が失敗した場合でも、正常にバックアップされた永続ストア (Amazon EBS ボリュームなど) とクラスター構成設定を個別に復元することが可能です。ただし、EKS バックアップを完全に復元することはできません。正常にバックアップされたリソースを復元用に利用できるようになり、EKS クラスターのリカバリポイントの下にネストされたリカバリポイントとして一覧表示されます。部分的な失敗が発生すると、失敗した部分の通知が行われます。 メリット 以下は、AWS Backup での Amazon EKS のサポートによって実現されるメリットです。 カスタムスクリプトやサードパーティソリューションの管理に伴うオーバーヘッドを解消するフルマネージド型のマルチクラスターバックアップエクスペリエンス。 バックアップのライフサイクル管理を簡素化し、EKS を含めた AWS サービス全体でアプリケーションデータのバックアップとリカバリをシームレスにする一元化されたポリシーベースのバックアップ管理。 バックアップボールト を使用してバックアップを保存し、整理する機能。バックアップボールトにポリシーを割り当てて、バックアッププランやオンデマンドバックアップを作成するためのアクセス権をユーザーに付与するとともに、リカバリポイントの作成後にそれらを削除する能力を制限します。 知っておくと便利な情報 以下は、知っておくと役に立つ情報です。 AWS Backup を使用した EKS クラスターの保護には、 AWS Backup コンソール 、API、または AWS コマンドラインインターフェイス (AWS CLI) を使用します。また、クラスターの作成後にクラスターのオンデマンドバックアップを作成することも可能です。 いくつかの異なるアカウントや AWS リージョン に EKS バックアップのセカンダリコピーを作成して、バックアップが誤って削除されるリスクを最小限に抑えることができます。 EKS バックアップの復元は、AWS Backup コンソール、API、または AWS CLI を使用して実行できます。 復元は非破壊的であるため、既存のクラスターに復元しても Kubernetes バージョンやデータが上書きされることはありません。その代わりに、バックアップリソースとソースリソース間の差分の復元が作成されます。 Kubernetes リソースはクラスターレベルでスコープされている可能性があるため、復元が正常に行われるようにするためにも、名前空間は既存のクラスターにのみ復元できます。 お客様の声 Salesforce の Sr.Director of Engineering である Srikanth Rajan 氏は、「バックアップと復元の堅実な計画がない状態でソフトウェアのバグやクラスターの意図しない削除に起因する Kubernetes コントロールプレーンの損失が発生すると、致命的な結果を招くことになりかねません。AWS による EKS の新しいバックアップと復元特徴量のリリースが非常にすばらしいのはこのためです。これは、Kubernetes プラットフォームの重大なレジリエンシーギャップの解消に向けた大きな前進です」と語っています。 今すぐご利用いただけます AWS Backup での Amazon EKS のサポートは、AWS Backup と Amazon EKS が提供されているすべての AWS 商用 リージョン (中国を除く) と AWS GovCloud (米国) で本日からご利用いただけます。今後の更新については、 全リージョンのリスト をご確認ください。 詳細については、 AWS Backup 製品ページ と AWS Backup の料金ページ をご覧ください。 AWS Backup で EKS クラスターを保護するためのこの機能をぜひお試しいただき、 AWS re:Post for AWS Backup 、または通常の AWS サポート担当者を通じてフィードバックを提供することで、皆さんのご意見をお聞かせください。 – Veliswa 原文は こちら です。

はじめに AWS上でSAPワークロードの真の可能性を解き放つ準備はできていますか？パズルの最も重要なピースの一つを解決しましょう：企業ネットワークとクラウドERPワークロード間の安全で信頼性の高いネットワーク接続の確立です。 AWSでは、お客様がSAP Cloud ERP Private ワークロード（旧RISE with SAP）の実装を支援する中で、3つの質問が当然のように浮上します： 「プライベートクラウドERP環境への安全な接続をどのように確立すればよいか？」 「私たちのユースケースに最もコスト効率の良いネットワークアーキテクチャは何か？」 「Direct Connect、Site-to-Site VPN、またはその両方を実装すべきか？」 これらの質問をお持ちの方は、あなただけではありません。今日行うネットワーク接続の決定は、システムパフォーマンスから災害復旧機能まで、あらゆることに影響を与え、今後何年にもわたってSAP運用に影響を与えます。 このガイドでは、複雑さを取り除き、特定のビジネス要件に合致するアプローチで、既存のインフラストラクチャをAWS for SAP Cloud ERP Privateに接続する方法をお示しします。 開始：責任共有モデルの理解 SAP Cloud ERP Privateのワークロードを実装する際、責任は分担されます： SAPがCloud ERP Privateが動作するAWS環境を管理 お客様がインフラストラクチャとAWS内のSAP Cloud ERP Private環境間のネットワーク接続を管理 この分担は、実装を開始する前に明確な接続戦略が必要であることを意味します。 ビジネスニーズに対応しましょう すべての組織は、SAP Cloud ERP Privateの旅において独自の要件を持っています。私たちは以下の出発点を見ています： 集中実装：ネットワークインフラストラクチャをAWS for SAP Cloud ERP Private環境と迅速に接続するための、直接的で安全なネットワーキングソリューションをお探しです。このアプローチは、セキュリティを維持しながらシンプルさを優先します 既存のAWSインフラストラクチャ：確立されたAWS接続があり、SAP Cloud ERP Privateをネットワークアーキテクチャに効率的に統合し、現在の投資を最大化したいとお考えです マルチリージョン運用：ビジネスが複数のリージョンまたは複雑なハイブリッド環境にわたって高度なネットワーキング機能を必要とし、強化された制御と自動化を求めています 3つのアプローチすべてがセキュリティと信頼性を提供します。主な違いは、即座のニーズ、運用の複雑さ、将来のスケーラビリティのバランスをどのように取るかです。 この投稿で扱う内容 異なるビジネス要件に合致する3つの接続アーキテクチャを説明します： 基盤アーキテクチャ：セキュリティと信頼性を維持しながら迅速に実装できる、合理化された安全な接続ソリューション。迅速な展開を優先する組織に最適 統合アーキテクチャ：既存のAWS投資を最適化し、自動フェイルオーバー機能を提供するハイブリッド接続アプローチ。SAP Cloud ERP Privateワークロードを現在のAWS環境に組み込むのに最適 包括的アーキテクチャ：AWSベストプラクティスと高度な自動化を組み込みながら、複雑なマルチリージョン展開に最大の柔軟性を提供するエンタープライズランディングゾーンアプローチ 各ソリューションについて、以下を学習します： 主要なビジネスドライバーとユースケース 図表付きの詳細なアーキテクチャパターン 実装の考慮事項とベストプラクティス 各アーキテクチャはセキュリティと信頼性を提供します。選択は、特定のビジネス要件、運用の好み、成長計画によって決まります。 最適なネットワークアーキテクチャを構築する準備はできましたか？詳しく見ていきましょう。 オプション1：AWS Direct Connectでミッションクリティカルな接続を構築 図1：顧客ネットワークとAWS for SAP Cloud ERP Private環境（AWS for RISE with SAP）間の回復力のあるDirect Connect構成 SAPワークロードが一貫した高性能接続を要求する場合、 AWS Direct Connect （DX）が提供します。このソリューションは、インフラストラクチャとAWS上のSAP Cloud ERP Private間の専用プライベートネットワーク接続を提供し、最も要求の厳しいワークロードに対して予測可能なパフォーマンスと信頼性の高いスループットを保証します。 なぜDirect Connectを選ぶのか？ ミッションクリティカルなSAP環境において、DXは以下を提供します： 一貫した低レイテンシパフォーマンス 予測可能なネットワーク動作 専用帯域幅 プライベート接続によるセキュリティ強化 重要：スムーズな展開を確保するため、予定されている本稼働日の少なくとも6〜8週間前にDirect Connectの実装を開始してください。 以下が必要な場合にDXを検討してください： 一貫した低レイテンシパフォーマンスを必要とする本番SAP環境 定期的な大容量データ転送（1日2TB以上） 複数のリージョンにわたる信頼性の高い帯域幅 ミッションクリティカルな運用における予測可能な応答時間 Direct Connection オプションの選択： AWS Direct Connectは接続への2つのパスを提供します： ホスト接続 AWS Direct Connectパートナーを通じた迅速な展開 コスト効率の良い実装 50 Mbpsから25 Gbpsまでの帯域幅オプション 実装時間の短縮（数日から数週間） ほとんどのSAP Cloud ERP Private展開に最適 専用接続 接続に対する最大限の制御 最大100 Gbpsのカスタム帯域幅 より長い実装タイムライン（数週間） より高い初期費用 大容量、レイテンシに敏感なワークロードに推奨 重要なセキュリティ注意事項：どちらの接続タイプも組み込み暗号化は含まれていません。強化された保護のためにMACsecなどの追加のセキュリティ対策の実装を検討してください。 回復力のある接続の構築 ミッションクリティカルなワークロードについては、高可用性のために複数のDX接続の実装をお勧めします。方法は以下の通りです： AWS Direct Connect回復力推奨事項 を使用して最適なモデルを選択 冗長接続のために AWS Direct Connect回復力ツールキット を実装 最大の回復力のために異なるプロバイダーからの接続を展開 本稼働前にフェイルオーバー構成をテスト コストの考慮事項 複数のDX接続は単一リンクと比較して初期費用と継続費用の両方を増加させますが、以下を提供します： より高い可用性 強化されたSLAコンプライアンス より良いビジネス継続性 接続中断のリスク軽減 注意：AWS for SAP Cloud ERP Privateへのネットワーク接続を実装する際、Direct Connect接続管理をSAPに委任すると、将来の接続変更の柔軟性が制限される可能性があることに注意してください。 オプション2：Direct Connect + VPNフェイルオーバーでコストと信頼性を最適化 図2：顧客ネットワークとSAP Cloud ERP Private（RISE with SAP）環境間のAWS Direct Connectプライマリ接続とSite-to-Site VPNバックアップ AWS for SAP Cloud ERP Privateワークロードの接続を計画する際、ビジネス継続性を実現するために常に複数のDirect Connect接続が必要というわけではありません。AWS Direct ConnectとSite-to-Site VPNを組み合わせることで、パフォーマンスとコスト効率のバランスを取った回復力のあるネットワークアーキテクチャを作成できます。 ハイブリッド接続戦略の構築 このソリューションは、Direct Connectをプライマリパスとして使用し、SAPワークロードに期待される一貫したパフォーマンスを提供します。一方、 AWS Site-to-Site VPN （VPN）は自動フェイルオーバーオプションとして待機し、プライマリ接続に中断が発生した場合にインターネット経由で暗号化された接続を提供します。このアプローチにより、冗長Direct Connectリンクのコストなしに高い信頼性を得ることができます。 組織は以下の場合にこのハイブリッドモデルが特に価値があると感じています： 複数のリージョンにわたってSAPワークロードを展開する場合 開発およびテスト環境をサポートする場合 グローバルの従業員からSAPアプリケーションへのアクセスを可能にする場合 ビジネス継続性を維持しながらコストを管理する場合 Site-to-Site VPNの開始 AWS Site-to-Site VPN を組み込む主な利点の一つは、迅速な展開機能です。Direct Connectの実装が進行中（6〜8週間かかる場合があります）の間に、数日でVPN接続を確立できます。これにより、チームはSAP Cloud ERP Privateでの作業をすぐに開始し、準備ができたらDirect Connectをプライマリパスとして移行できます。 VPN接続は以下を提供します： 安全なデータ転送のための組み込みIPSec暗号化 インターネット接続に基づく柔軟な帯域幅 従業員のグローバルなアクセシビリティ 従量課金制の価格モデル ビジネスに適した選択をする このハイブリッドアプローチは、以下が必要な組織に特に適しています： パフォーマンス要件と予算制約のバランスを取る さまざまな帯域幅ニーズを持つリモートオフィスをサポートする 開発チームに即座の接続を提供する 災害復旧機能を確立する 帯域幅とレイテンシはインターネット接続によって変動しますが、お客様はSite-to-Site VPNが開発、テスト、バックアップシナリオに十分以上のパフォーマンスを提供することを発見しています。自動フェイルオーバー機能により、プライマリ接続に問題が発生してもチームは重要なSAPシステムへのアクセスを維持できます。 実装の計画 このハイブリッド接続アプローチを検討する際は、以下の重要なポイントを念頭に置いてください： 要件から始める： 予想されるトラフィック量 異なる環境のパフォーマンス要件 従業員の地理的分布 予算制約 タイムラインを考慮する： 即座の接続のためにまずVPNを実装 並行してDirect Connect展開を計画 テストと検証期間をスケジュール フェイルオーバー手順を準備 成長について考える： 将来の帯域幅要件 追加の場所の接続 潜在的なワークロード拡張 詳細な構成手順とアーキテクチャパターンについては、 オンプレミスネットワークからRISE with SAPへの接続 に関する技術文書をご確認ください。 オプション3：AWSランディングゾーンでエンタープライズ基盤を構築 図3：オンプレミスネットワークとSAP Cloud ERP Private（RISE with SAP）間の集中化された接続管理を提供するAWSランディングゾーン SAP Cloud ERP Privateへの旅がより広範なクラウド戦略の一部である場合、ランディングゾーンの実装により、ビジネスとともに成長する基盤が作成されます。このアプローチは、AWS環境全体でセキュリティと制御を維持しながら複雑さを管理するのに役立ちます。 なぜランディングゾーンアプローチを検討するのか？ ランディングゾーンを組織のデジタル都市計画と考えてください。個々の構造（ワークロード）をスペースが許す場所に構築するのではなく、現在のニーズをサポートしながら将来の成長に備える、よく設計されたインフラストラクチャを作成しています。SAP Cloud ERP Privateにとって、これは接続ソリューションがより大きな戦略的アーキテクチャの一部になることを意味します。 エンタープライズ基盤の構築 その核心において、ランディングゾーンはベストプラクティスに従う Well-Architected なマルチアカウントAWS環境です。以下を提供します： 集中化されたセキュリティ制御と監視 標準化されたネットワークアーキテクチャ 自動化されたアカウントプロビジョニング リージョン間での一貫したガバナンス 柔軟な統合オプション Landing Zone Accelerator（LZA） は、この基盤を迅速かつ安全に実装するのに役立ちます。オープンソースツールとして、LZAはAWSの最新のベストプラクティスを組み込みながら、ニーズに基づいてカスタマイズする柔軟性を提供します。 接続された環境の作成 ランディングゾーン内で、AWS Transit Gatewayは洗練された企業ネットワークバックボーンと同様に、ネットワークトラフィックの中央ハブとして機能します。この設計により、以下が可能になります： 複数のVPCの接続 オンプレミスネットワークの統合 一貫したセキュリティポリシーの実装 トラフィックパターンの集中監視 必要に応じた接続のスケール 実世界での応用 組織は以下の場合にランディングゾーンアプローチを実装します： 厳格なセキュリティとコンプライアンス基準を維持する必要がある コアSAPワークロードを超えて拡張する計画がある 複数の地理的リージョンで運用している 高度なトラフィック管理が必要 追加のAWSサービスを活用したい 集中化された監視と管理が必要 例えば、グローバル製造業者はAWS for SAP Cloud ERP Privateから始めるかもしれませんが、IoT機能、分析プラットフォーム、機械学習サービスを追加する計画があります。ランディングゾーンアプローチにより、これらの追加がよりスムーズで安全になります。 ランディングゾーンの計画 ランディングゾーンは直接接続オプションよりも多くの初期計画が必要ですが、Landing Zone Acceleratorがプロセスを簡素化します。開始方法は以下の通りです： 要件の評価 現在および将来のワークロードニーズ セキュリティとコンプライアンス基準 地理的分布 統合要件 アーキテクチャの設計 アカウント構造 ネットワークトポロジー セキュリティ制御 管理ツール 展開の計画 実装フェーズ リソース要件 タイムラインの考慮事項 テストアプローチ 必要な時にサポートを受ける Landing Zone Acceleratorは自動化とガイダンスを提供しますが、この旅において一人ではありません。 AWSプロフェッショナルサービス と AWSパートナー が以下をサポートできます： 最適なアーキテクチャの設計 セキュリティベストプラクティスの実装 ネットワーク接続の構成 運用手順の確立 将来を見据えて ランディングゾーンアプローチは直接接続オプションよりも大きなステップのように見えるかもしれませんが、組織の将来への投資です。以下に必要なフレームワークを提供します： 効率的なスケール セキュリティの維持 コストの制御 イノベーションの実現 ビジネス成長のサポート AWS for SAP Cloud ERP Privateに特化した詳細なガイダンスについては、 AWS上でRISE with SAPのためのエンタープライズ対応ネットワーク基盤の構築 に関するドキュメントをご覧ください。 すべてをまとめる：最適なネットワーク戦略の構築 AWS for SAP Cloud ERP Private（旧RISE with SAP）を使用する各組織の旅は独特です。そのため、AWSは特定のニーズに合わせて組み合わせることができる柔軟な接続オプションを提供しています。これらのオプションがどのように連携して包括的なソリューションを作成するかを探ってみましょう。 エンタープライズ成功のための強力な組み合わせ パフォーマンス + 回復力 – Direct ConnectとSite-to-Site VPNの組み合わせ（オプション1 + 2） 重要なワークロードは専用接続で実行 リモート拠点はVPN経由で接続 組み込みフェイルオーバー保護 コスト効率的なグローバルリーチ エンタープライズ制御 + 信頼性 – 冗長Direct Connectを持つランディングゾーン（オプション3 + 1） 環境に対する最大限の制御 最高レベルの可用性 業界標準のセキュリティ制御 将来対応の基盤 柔軟性 + コスト最適化 – ハイブリッド接続を持つランディングゾーン（オプション3 + 2） スケーラブルなアーキテクチャ スマートなコスト管理 自動フェイルオーバー 簡素化された管理 完全なエンタープライズソリューション – 包括的アプローチ（オプション1 + 2 + 3） 最大の柔軟性 完全な冗長性 グローバルリーチ 将来対応設計 決定を下す 最適なネットワーク戦略は、いくつかの重要な要因によって決まります： ビジネスクリティカルな要件 パフォーマンス要件 予算の考慮事項 実装タイムライン 将来の成長計画 地理的分布 行動を起こす：次のステップ 結論として、AWS for SAP Cloud ERP Private（RISE with SAP）へのネットワーク接続は、プレッシャーの下では複雑に見えるかもしれません。しかし、この投稿と言及されたリソースの助けを借りて、より情報に基づいた出発点を持つことができます。最適なネットワーク接続の選択は、ビジネス目標、実装時間枠、予算、AWSやネットワーキングの習熟度、その他の制限事項によって決まります。行動を起こす方法は以下の通りです： 要件の評価 現在のネットワーク要件をマッピング パフォーマンス要件の文書化 重要なワークロードの特定 将来の成長を考慮 アプローチの計画 接続戦略の選択 実装フェーズの定義 タイムラインの確立 ステークホルダーの調整 実装の準備 技術要件の作成 AWSとの早期エンゲージメント アーキテクチャレビューのスケジュール テスト計画の開発 結論： AWS for SAP Cloud ERP Private（旧RISE with SAP）への成功した接続への旅は、シンプルなDirect Connect実装から始めるか、包括的なランディングゾーンを構築するかに関わらず、まず一歩から始まります。。 始める準備はできましたか？AWSアカウントチームに連絡するか、AWSサポートポータルでケースを開いて、最適なネットワークアーキテクチャの構築を開始してください。 追加リソース： AWS上でRISE with SAPのためのエンタープライズ対応ネットワーク基盤構築のガイダンス 接続 – 一般的なSAPガイド 安全でスケーラブルなマルチアカウントAWS環境のセットアップ – AWS P… AWS Direct Connect + AWS Transit Gateway + AWS Site-to-Site VPN – Amaz… オンプレミスネットワークからRISE with SAPへの接続 本ブログの翻訳はAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。 <!-- '"` -->

はじめに 数千のお客様が AWS上でSAPワークロード を実行しており、お客様はAWS上でクラウドネイティブなアプリケーション拡張を構築することで、ビジネスプロセス変革を加速することを求めています。お客様は200を超えるAWSサービスを活用して、ERPシステムのクリーンコアを維持し、アップグレードを合理化し、AWSネイティブ機能を使用して進化するビジネスニーズに合わせてペースよくイノベーションを行っています。 セキュリティはAWSの最優先事項です。このモダナイゼーションの旅において、お客様の重要な焦点は、最小権限を順守し、複雑なシステム境界を越えてアイデンティティを伝播することで、セキュリティ体制を強化することです。一つのユースケースは、ユーザーがAWS上でホストされているクラウドネイティブアプリケーション拡張からSAPリソースにアクセスする場合です。 より良いユーザーエクスペリエンスの重要な実現要因は、プリンシパル伝播です。これは、AWSのApplication Load Balancer（ALB）などの初期認証ポイントから、再認証を必要とせずにSAPなどのバックエンドシステムまで、検証されたアイデンティティを運ぶ能力です。これにより、SAPリソースがALBによって検証されたアイデンティティを信頼し、ユーザー認可を通じて最小権限アクセスを担保することができます。 このブログ投稿では、 Application Load Balancer（ALB） 、X.509証明書、およびMutual Transport Layer Security（mTLS）が、AWS上でホストされているクラウドネイティブ拡張からミッションクリティカルなSAP ERPシステムのSAPリソースにアクセスするSAPユーザーに対して、シングルサインオン（SSO）エクスペリエンスを可能にする方法に焦点を当てています。 プリンシパル伝播とは？ プリンシパル伝播により、ユーザーは一度サインインするだけで複数のシステムに安全にアクセスでき、複数回ログインする必要がなくなります。これにより、ユーザーが一度認証されると（例：ALBでのクライアント証明書による認証）、そのアイデンティティがSAPなどの下流システムによって一貫して認識され、信頼されることが保証されます。これにより、冗長なログインプロンプトの必要性がなくなり、ランドスケープ全体で安全なユーザーコンテキストが維持されます。システムユーザーではなく、ユーザーのアイデンティティの下でアクションが実行されることを保証し、トークンベースの認証に依存することでセキュリティを向上させ、アイデンティティをシステムに転送することでシングルサインオン（SSO）を可能にします。 プリンシパル伝播の主要なメリット シングルサインオン（SSO）によるより良いユーザーエクスペリエンス： ユーザーは複数のシステムやアプリケーションにアクセスするために一度だけ認証すればよく、繰り返しのログインプロンプトの煩わしさを排除し、異なるプラットフォーム間での生産性を維持できます。 セキュリティの強化： 複数の認証情報を保存する必要性を排除し、認証タッチポイントを削減することで、プリンシパル伝播はセキュリティ体制を強化します。明確な監査証跡を維持し、統合されたシステム全体で一貫したセキュリティポリシーを強制する統一されたセキュリティコンテキストを作成し、潜在的な攻撃者が環境を侵害することを困難にします。 コンプライアンスとガバナンス： 組織は、包括的なユーザーアクティビティの追跡と説明責任を通じて、規制要件へのより良いコンプライアンスを維持できます。プリンシパル伝播により、ユーザーアクションがすべてのシステムで適切に帰属し、ログに記録されることが保証され、監査プロセスと規制報告が簡素化されます。 管理効率： ITチームは、単一の制御ポイントからユーザーアクセス、権限、認証情報を管理でき、ユーザーライフサイクル管理を簡素化し、日常的な管理タスクを合理化できます。 システム統合： プリンシパル伝播は、異なるシステムとプラットフォーム間の橋渡しとして機能し、システム境界を越えて一貫したユーザーコンテキストと認可を維持します。この統合は、アプリケーションが複数のプラットフォームとクラウドサービスにまたがる現代のハイブリッド環境において特に価値があります。 コスト削減： 組織は、ヘルプデスクチケットの削減、セキュリティ実装の簡素化、および集中管理によるより効率的なリソース利用から恩恵を受けます。 mTLS認証はプリンシパル伝播をどのようにサポートできるか？ Mutual Transport Layer Security（mTLS）認証は、クライアントとサーバー間で安全な双方向暗号化接続を確立します。サーバーのみが証明書を提供する標準的なTLSとは異なり、mTLSでは両方の当事者がデジタル証明書を提示する必要があります。このメカニズムにより、ユーザーはクライアントとサーバー間でより良いセキュリティ体制を持つシームレスな認証を体験できます。 図1. クライアントとサーバー間のmTLS認証フロー mTLS認証シナリオでは、両方が信頼されることを保証するために、認証局（CA）を使用してクライアントとサーバー証明書をプロビジョニングする必要があります。認証プロセスは以下のように動作します： クライアントがサーバーへの接続を要求します。 サーバーがその証明書を提示します。 クライアントがサーバーの証明書を検証します。 クライアントがサーバーの検証と認証のためにその証明書を提示します。 クライアントとサーバー間で安全な接続が確立されます。 Application Load BalancerでのmTLSクライアント認証 ALBはmTLS認証をサポートしています。パススルーモードと検証モードの2つのモードを提供します。 安全なデータフローを確保するために、ALB、SAP Web Dispatcher、S/4HANAシステムを含むインフラストラクチャ全体で使用されるすべてのSSL（Secure Socket Layer）またはTLS証明書は、これらの証明書の実装と保守を容易にするために、単一の信頼できるルート認証局から発行される必要があります。 mTLSパススルーモード mTLSパススルーモードでは、ALBはクライアントの証明書チェーン全体をバックエンドターゲットに転送します。これは X-Amzn-Mtls-Clientcert という名前のHTTPヘッダーを介して行われます。リーフ証明書を含むチェーンは、+、=、/を安全な文字として使用してURLエンコードされたPEM形式で送信されます。mTLSパススルーモードを使用する際の考慮事項は以下の通りです。 クライアント証明書が存在しない場合、ALBはヘッダーを追加しません。バックエンドがこれを処理する必要があります。 バックエンドターゲットがクライアント認証とエラー処理を担当します。 HTTPSリスナーの場合、ALBはクライアント-ALB TLSを終端し、ターゲットにインストールされた証明書を使用して新しいALB-バックエンドTLSを開始します。 ALBのTLS終端により、ロードバランシングにALBの任意のルーティングアルゴリズムを使用できます。 mTLS検証モード mTLS検証モードを有効にするには、CA証明書バンドルを含むトラストストアを作成します。これは AWS Certificate Manager（ACM） 、AWS Private CA、または独自の証明書をインポートすることで実現できます。Amazon S3に保存され、トラストストアにリンクされた証明書失効リスト（CRL）を使用して、失効した証明書を管理します。 ALBはトラストストアに対するクライアント証明書の検証を処理し、不正なリクエストを効果的にブロックします。このアプローチにより、バックエンドターゲットからmTLS処理をオフロードし、システム全体の効率を向上させます。ALBはS3からCRLをインポートし、S3への繰り返しフェッチなしでチェックを実行し、レイテンシを最小限に抑えます。 クライアント認証を超えて、ALBは HTTPヘッダー （例： X-Amzn-Mtls-Clientcert-Leaf ）を通じてクライアント証明書メタデータをHTTPヘッダー経由でバックエンドSAP Web Dispatcherに送信します。これにより、SAPサーバーが元の「ホストヘッダー」情報を保持する要件を満たすために、証明書の詳細に基づいてバックエンドターゲットで追加のロジック実装が可能になります。 これにより、SSL接続を終端するAWSロードバランサーなどの非SAPソースから発信された場合でも、サーバーがクライアント証明書メタデータを一貫して処理できるようになります。ALB – SAP Web Dispatcher – SAPサーバー間でエンドツーエンド暗号化を実装している場合は、 icm/HTTPS/client_certificate_header_name などのSAP Web Dispatcherプロファイルパラメータを設定する必要があります。詳細については、 このリンク を参照してください。 推奨事項 AWS上でのSAPワークロードデプロイメントには、mTLS検証モードの実装を推奨します。これにより、可能な限り早期（ALBレイヤー）で検証と認証をオフロードできるためです。mTLS検証モードは、RISE with SAP on AWSでもサポートされています。 mTLS検証モードのアーキテクチャパターン 図2. AWS上のSAPワークロードのmTLS検証認証データフロー 上記のアーキテクチャは、AWS Direct Connectを通じて閉鎖されたオンプレミスとAWS VPCでmTLS認証がどのように実装されるかを説明しています。mTLS認証は、インターネット接続を持つリモートユーザーに対しても実装できます。 アーキテクチャフロー ユーザーは、クライアントデバイス（ラップトップおよび/またはモバイル）にX.509証明書をインストールします。 クライアントデバイスはALBへの接続を開始し、それぞれの証明書を共有して、両方が互いを検証できるようにします。ALBの検証はAmazon S3をトラストストアとして活用します。 検証が完了すると、ALBは検証と認証のためにSAP Web Dispatcherに接続を転送します。 SAP Web Dispatcherは、検証と認証のためにSAPインスタンス（S/4HANA、ABAPスタックなど）に接続を転送します。 実装手順 詳細な実装手順はこちら で確認できます。これらの設定手順は、安全なクライアント-サーバー認証の基盤を確立します： Amazon S3を使用してトラストストアを設定します。 プライベート認証局（CA）と中間証明書を保存するために Amazon S3バケットを作成 します。 EC2コンソールを通じて トラストストア を設定し、S3バケットにリンクします。 ネットワーク接続に対する追加のセキュリティ制御のために証明書失効リスト（CRL）を実装します。 Application Load Balancer（ALB）を設定します。 AWS Certificate Manager を使用してALB用の SSLパブリック証明書を要求 します。 要求されたSSLパブリック証明書に関連付けることでmTLSを有効にする HTTPSリスナー を作成します。 ALBからのトラフィックのみを許可するインバウンドルールを設定して、 SAP Web Dispatcher専用のセキュリティグループを作成 します。 SAP Web Dispatcher用の ターゲットグループを作成 し、ALBにマッピングします。 SAPインスタンス（SAP S/4HANAなど）をバックエンドとしてターゲットするようにSAP Web Dispatcherを設定します。 sapgenpseコマンド を使用して、ルートおよび中間証明書をSAP WebDispatcherにインポートします。 SAP Web Dispatcher用のSSLパブリック証明書を（同じプライベートCAから）生成し、 sapgenpseコマンド を使用してインストールします。 SAPパラメータ icm/HTTPS/client_certificate_header_name = x-amzn-mtls-clientcert を実装します。 SAPドキュメント を参照してください。 安全な接続を受け入れるようにSAP S/4HANAを設定します。 SAP S/4HANAのSTRUSTトランザクションにルートおよび中間証明書をインポートします。 SAP Web Dispatcherに割り当てられたSSL証明書の詳細でSAPパラメータ icm/trusted_reverse_proxy を実装します。 SAPドキュメント を参照してください。 料金 Application Load Balancerの料金に関する詳細情報は このリンク で確認できます。mTLS認証に特に関連して、mTLS検証ユースケースシナリオに基づいてALBに関連付けられたトラストストアあたりの追加の時間料金があります。 S/4 HANAアプリケーションが平均して1秒あたり1つの新しい接続を受信し、それぞれが2分間持続すると仮定できます。クライアントは平均して1秒あたり5つのリクエストを送信し、リクエストとレスポンスの処理バイト数の合計は1秒あたり300 KBです。ロードバランサーでクライアントリクエストをルーティングするために1つのルールを設定し、Mutual TLSシナリオ用に1つのトラストストアを関連付けています。 米国東部（バージニア北部）リージョンの料金を使用して、月次Application Load Balancerコストを以下のように計算します： 新しい接続（1秒あたり） ：各LCU(Load Balancer Capacity Unit)は1秒あたり25の新しい接続を提供します（1時間の平均）。アプリケーションが1秒あたり1つの新しい接続を受信するため、これは0.04 LCU（1秒あたり1接続 / 1秒あたり25接続）に相当します。 アクティブ接続（1分あたり） ：各LCUは1分あたり3,000のアクティブ接続を提供します。アプリケーションは1秒あたり1つの新しい接続を受信し、それぞれが2分間持続します。これは1分あたり120のアクティブ接続、または0.04 LCU（1分あたり120アクティブ接続 / 1分あたり3,000アクティブ接続）に相当します。 処理バイト数（1時間あたりGB） ：各LCUは1時間あたり1 GBの処理バイトを提供します。各クライアント接続が1秒あたり300 KBのデータを転送するため、これは1時間あたり1.08 GBまたは1.08 LCU（1.08 GB/1 GB）に相当します。 ルール評価（1秒あたり） ：10の無料ルールのため、この次元は料金に影響しません。 これらの値を使用して、時間料金は4つの次元で消費される最大LCUを取ることで計算されます。この例では、処理バイト次元（1.08 LCU）が新しい接続（0.04 LCU）、アクティブ接続（0.04 LCU）、ルール評価（0 LCU）よりも大きく、1時間あたり$0.00864（1.08 LCU * LCUあたり$0.008）または月額$6.22（$0.00864 * 24時間 * 30日）の合計料金となります。 $0.0225（ALB時間）の時間料金と0.0056（トラストストア）の時間料金を追加すると、Application Load Balancerの総コストは： 1時間あたり$0.03674（$0.0281時間料金 + $0.00864 LCU料金）；または 月額$26.4528（$0.03114 * 24時間 * 30日） 。 まとめ Application Load BalancerのmTLSサポートは、SAPランドスケープでプリンシパル伝播を実装するための堅牢な基盤を提供します。この統合により、AWSのマネージドサービスを活用しながら、安全でスケーラブル、かつ保守可能なSSOソリューションが可能になります。 主要なポイント： ALBのmTLSサポートがプリンシパル伝播の実装を簡素化します。 SAP Web Dispatcherとの統合により、認証情報の適切なマッピングが保証されます。 AWSマネージドサービスが運用オーバーヘッドを削減します。 証明書ベースの認証によるセキュリティの強化。 ALBを使用してmTLS認証を実装することで、組織は従業員により良いユーザーエクスペリエンスを提供しながら、SAPアプリケーションのセキュリティ体制を向上させることができます。このソリューションは、アプリケーションランドスケープ全体で安全で効率的な認証メカニズムを維持する必要があるAWS上でSAPワークロードを実行している企業に特に関連があります。 AWS Well Architected Framework（SAP Lens） に含まれるセキュリティのベストプラクティスに常に従い、証明書とトラストストアを定期的に更新することを忘れないでください。 SAP投資からより多くの価値を得る方法についてのインスピレーションを得るために、 AWS for SAPブログ で詳細をお読みください。 SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、最近 re:Post – AWSコミュニティのための再構築されたQ&amp;Aエクスペリエンスを開始しました。AWS for SAPソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティの知識ベースに貢献することを検討してください。 クレジット 貢献してくれた以下のチームメンバーに感謝します：Derek Ewell、Sreenath Middhi、Rajendra Narikimelli、Joachim Aumman、Arne Knoeller、Adam Hill。 <!-- '"` --> 本ブログの翻訳はAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

こんにちは。ソリューションアーキテクトの大南です。 2025 年 11 月 6 日に「AWS 秋のオブザーバビリティ祭り 2025 〜最新アップデートと生成 AI × オブザーバビリティ〜」と題したイベントを開催しました。AWS オブザーバビリティ祭りはこれまで半年ごとの春と秋に継続して実施しており今回で 5 回目のイベントとなります。ご参加いただきました皆様には、改めて御礼申し上げます。今までの開催報告ブログはこちら( 2023秋 、 2024春 、 2024秋 、 2025春 )。 本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開いたします。今回のイベントでは、前回のオブザーバビリティ祭り以降のアップデートのご紹介、また AWS オブザーバビリティサービスに組み込まれた生成 AI エージェントの活用や運用のユースケースを想定した MCP Server の活用、Amazon CloudWatch GenAI Observability を活用した AI エージェントのためのオブザーバビリティ、クロスアカウントやクロスリージョン環境での CloudWatch 機能の活用、X-Ray SDK と Daemon のサポート終了に伴う移行方法のガイド、という実際の運用ですぐ活用できる内容を中心にご紹介しました。日々の運用にすぐ活かせる内容となっておりますので、ぜひご活用ください！ セッションの紹介 AWS オブザーバビリティサービスアップデート アマゾン ウェブ サービス ジャパン 合同会社 スペシャリストソリューションアーキテクト 加藤 正樹 セッション資料 セミナー開始は、Specialist SA 加藤より、AWS オブザーバビリティアップデートと題して、モニタリングとオブザーバビリティの違いや、オブザーバビリティで必要となるデータ、AWS の提供するオブザーバビリティサービスについておさらいをし、春のオブザーバビリティ祭り以降の最新機能アップデートについてご紹介しました。Amazon CloudWatch Logs のログイベントサイズの増加や、Amazon CloudWatch Metrics Insights のメトリクスデータのクエリ可能な期間が3時間から2週間へ拡大されたアップデートなど運用業務で嬉しいアップデートについて解説しました。Database Performance Insights のサポート終了に伴う CloudWatch Database Insights への移行ガイドなども確認しておきたいポイントです。機能アップデートをまとめておさらいしたい方は、ぜひご確認ください。 生成 AI で進化する AWS オブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 梅津 寛子 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大石 美緒 セッション資料 次に、SA 梅津よりオブザーバビリティにおける運用課題への解決手段として AIOps を活用するアプローチをご紹介しました。Amazon CloudWatch へ組み込まれた AI 機能(CloudWatch Investigations、Query Generator、CloudWatch Logs Anomaly Detection、CloudWatch Anomaly Detection)を活用してこれまでのインシデント調査および対応をより効率化できることを示しました。加えて SA 大石より、CloudWatch に関する MCP Server(Amazon CloudWatch MCP Server、Amazon CloudWatch Application Signals MCP Server)を Amazon Q Developer CLI を利用してインシデント調査からレポーティングを行うデモをご紹介しました。CloudWatch Investigations と MCP Server の使い分けが気になる方は必見です。 Amazon Bedrock AgentCore で実現！お手軽 AI エージェントオブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大西 朔 セッション資料 SA 大西より、AI エージェントの開発・運用を楽にするための Amazon Bedrock AgentCore を活用した AI エージェントのオブザーバビリティについてご紹介しました。2025 年 10 月 13 日に GA となった Amazon Bedrock AgentCore の全体像に触れた後、AgentCore Observability にフォーカスし、AI エージェントを扱う際に必要な観点を解説しました。CloudWatch GenAI Observability 機能を通して AgentCore におけるトレースのデータ構造をはじめとして取得可能な情報について共有いたしました。既に AI エージェントを開発・運用中の方やこれから導入を検討される方におすすめです！ クロスアカウント/クロスリージョンのオブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大南 賢亮 セッション資料 次に SA 大南より、クロスアカウントやクロスリージョン環境で活用できる CloudWatch の機能についてご紹介しました。これまで CloudWatch クロスアカウントオブザーバビリティと、クロスアカウントクロスリージョン CloudWatch コンソールという2つの機能がありましたが、2025年9月のアップデートにより、クロスアカウントクロスリージョン環境化でログデータを一元化する機能が追加されました。それぞれの機能について特徴と適したユースケースを解説し、実装パターンを提示しました。クロスアカウントやクロスリージョンでの CloudWatch を活用したオブザーバビリティについてご興味がある方はぜひご確認ください。 X-Ray SDK と Daemon のサポート終了と移行ガイド アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 津和崎 美希 セッション資料 最後は SA 津和崎より、サポート終了がアナウンスされた AWS X-Ray SDK と Daemon の移行方法についてご説明しました。X-Ray の中でも API やコンソールは従来通り利用でき、今回のサポート終了の対象は SDK と Daemon が対象であることやサービス上変更のない部分、それを踏まえて X-Ray の概念を OpenTelemetry に置き換える必要があることを詳細にご紹介しました。移行に関する具体的なアプローチにも触れ、すぐ作業にとりかかれる内容を網羅しています。現在 AWS X-Ray と Daemon をご利用の方には必見の内容となっていますので、 こちら のAWS X-Ray SDK /Daemon サポート終了に関するブログとともにご確認ください。 まとめ 今回は、「最新アップデートと生成 AI × オブザーバビリティ」というテーマで様々な立場の方がすぐ活用できる実践的な内容を中心に様々な機能やユースケースをご紹介しました。本イベントをきっかけにより皆様の業務が効率化でき、より高度な取り組みにつながるよう貢献できましたら幸いです。今後も、お客様のシステム運用を少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大南 賢亮

概要 AWS では、金融機関のお客様が AWS 上でシステムを構築する際の参考となる「 金融リファレンスアーキテクチャ日本版 」を提供しています。このたび、生成 AI に関する新たなコンテンツを追加しました。 金融機関における生成 AI の活用は、業務効率化と顧客体験向上の両面で大きな期待が寄せられています。一方で、機密情報の取り扱いやコンプライアンス要件への対応など、金融機関特有のセキュリティ要件を満たす必要があります。 今回、以下の 2 つのコンテンツを追加しました： 1. 生成 AI ワークロードのリファレンスアーキテクチャ : セキュリティ要件に対応したサンプル実装 2. 金融機関での生成 AI ユースケース : 具体的な活用例の紹介 1. 生成 AI ワークロードのリファレンスアーキテクチャ 概要 AWS Samples で公開されている「 Generative AI Use Cases (GenU) 」の閉域版をベースに、金融機関のセキュリティ要件に対応するためのカスタマイズを施したサンプル実装です。AWS CDK によるデプロイ手順を提供しており、実際に環境を構築して動作を確認できます。 GitHub : doc/reference-arc-genai GenU は、チャット、文章生成、要約、翻訳、RAG（Retrieval-Augmented Generation）、画像生成、動画生成など、多様な生成 AI ユースケースを提供するオープンソースアプリケーションです。本リファレンスアーキテクチャでは、これを金融機関で安全に活用するための実装パターンを示しています。 金融機関向けセキュリティ強化 本サンプル実装では、GenU 閉域版に対して以下のカスタマイズを施しています： 閉域ネットワーク構成 : システム間の通信を閉域ネットワーク内に閉じる構成 暗号化の強化 : AWS KMS カスタマーマネージドキーによるデータ保護 Amazon Bedrock Guardrails の設定強化 : 機密情報の検出・ブロック、金融業界向けトピックフィルタ、日本語対応 監視とガバナンス : Amazon CloudWatch による利用状況の可視化 詳細なアーキテクチャ構成については、アーキテクチャ解説書をご覧ください。 提供コンテンツ アーキテクチャ解説書 : GenU の主要機能と金融機関での活用方法、セキュリティ強化の詳細 FISC マッピング : FISC 安全対策基準（第 13 版）への対応状況 デプロイ手順書 : サンプル実装のデプロイ方法 2. 金融機関での生成 AI ユースケース 概要 生成 AI の具体的な活用例として、金融機関での実践的なユースケースを紹介しています。各ユースケースでは、Amazon Bedrock を中心とした AWS サービスを活用した構成例と、実装のポイントを解説しています。一部のユースケースについては、AWS CDK によるデプロイ手順を提供しており、実際の業務で利用可能なアプリケーションとして環境を構築できます。 GitHub : doc/fsi-case-study/reference-arc-genai-usecase 文書・コンテンツ審査 詳細はこちら | デプロイ可能 金融機関における膨大な文書審査業務を、AI と人間の協働（Human in the Loop）で効率化するソリューションです。 審査基準となるガイドライン文書をアップロードするだけで、AI が自動的にチェックリストを生成し、審査対象の文書を自動審査します。金融商品広告の法令・規制チェック、営業資料の社内コンプライアンス審査、マーケティング資料のブランドガイドライン準拠確認、ESG 報告書の業界ベストプラクティス準拠確認などに適用できます。 導入メリット : 審査時間の短縮、審査品質の標準化、判断根拠の明確化 AI を活用した営業・窓口対応トレーニング（ロールプレイ） 詳細はこちら | デプロイ可能 営業担当者や窓口担当者のトレーニングを、AI を活用したロールプレイで効率化します。AI が顧客役を演じ、様々なシナリオ（クレーム対応、商品説明、契約手続きなど）での対応練習を可能にします。24 時間いつでも利用でき、対応履歴の記録と振り返りができます。 導入メリット : トレーニングコストの削減、新人教育の効率化、対応品質の標準化 契約書業務アシスタント 詳細はこちら 契約書関連業務を包括的に支援する AI アシスタントシステムです。複数の専門 AI エージェント（スーパーバイザーエージェント、契約書作成エージェント、既存契約確認エージェント、契約 Q&amp;A エージェント）が連携して動作し、ユーザーの要求を自動的に適切なエージェントに振り分けます。 新規契約書の作成や既存契約状況の確認、契約関連質問への対応を自然言語での操作で実現します。 導入メリット : 契約書作成時間の短縮、問い合わせ対応の迅速化、専門知識の組織的活用 ATM 不正検知（高齢者電話利用） 詳細はこちら ATM 周辺での不審な行動（電話をしながらの ATM 操作など）を検知し、特殊詐欺被害を未然に防ぐソリューションです。Amazon Bedrock 上のマルチモーダルモデル活用して、既存の防犯カメラ映像からリアルタイムで不審な行動を検知し、店舗スタッフに即座に通知します。 導入メリット : 特殊詐欺被害の未然防止、顧客保護と信頼性の向上、既存インフラの有効活用 まとめ 今回追加した生成 AI に関するコンテンツは、金融機関における生成 AI 活用の第一歩として、セキュリティ要件に配慮したサンプル実装と、具体的な活用例を提供しています。 リファレンスアーキテクチャ では、GenU をベースに金融機関のセキュリティ要件に対応した実装パターンを示し、 ユースケース では、実際の業務での活用イメージを具体的に紹介しています。デプロイ手順も提供していますので、ぜひ実際に環境を構築して動作を確認してみてください。 金融リファレンスアーキテクチャ日本版の全てのコンテンツは GitHub リポジトリ から利用できます。フィードバックや質問については、GitHub の Issue としてご登録ください。皆様からのご意見をお待ちしております。 参考リンク 生成 AI ワークロードのリファレンスアーキテクチャ アーキテクチャ解説書 FISC マッピング デプロイ手順書 金融機関での生成 AI ユースケース ユースケース一覧 文書・コンテンツ審査 AI を活用した営業・窓口対応トレーニング（ロールプレイ） 契約書業務アシスタント ATM 不正検知 その他 金融リファレンスアーキテクチャ日本版 GitHub リポジトリ Generative AI Use Cases (GenU) 本ブログ記事は、AWS のソリューションアーキテクト 都築了太郎 が執筆いたしました。

このブログは Transform your MCP architecture: Unite MCP servers through AgentCore Gateway の翻訳記事です。 — AI エージェントが大規模に利用されていく中で、独自の Model Context Protocol (MCP) サーバーを作成し、特定のユースケースやドメイン、組織の機能やチーム向けに AI エージェントをカスタマイズするケースが増えています。また、既存の MCP サーバーやオープンソースの MCP サーバーを AI ワークフロー用に統合する必要もあります。カスタムビルド、パブリック利用可能、オープンソースなどの様々な形態の MCP サーバーを、AI エージェントが容易に利用できる組織全体で統一されたインターフェースに効率的に統合する方法が必要です。 今年の初めに AWS は Amazon Bedrock AgentCore Gateway を発表しました。これは完全マネージド型サービスで、中央集約型の MCP サーバーとして機能し、エージェントがツールを発見、アクセス、呼び出すための統一されたインターフェースを提供します。そして直近では、 AgentCore Gateway に既存の MCP サーバーをターゲットタイプとしてサポートする機能拡張を実施しました。この機能により、複数のタスク固有の MCP サーバーを、単一の MCP ゲートウェイインターフェースの背後にグループ化できます。これにより、個別のゲートウェイを維持する運用の複雑さが軽減され、(AgentCore Gateway のターゲットとしてこれまで利用可能であった) REST API や AWS Lambda 関数と同様に中央集約型のツールおよび認証管理が提供されます。 中央集約型のアプローチを取らない場合、1) 組織全体でツールを発見し共有することが困難となる、2) 複数の MCP サーバー間での認証管理が複雑になる、3) 各サーバーに対して個別のゲートウェイインスタンスを維持する管理工数、が課題となります。Amazon Bedrock AgentCore Gateway は、既存の MCP サーバーをネイティブターゲットとして扱うことでこれらの課題を解決し、ルーティング、認証、ツール管理のための単一の制御ポイントを顧客に提供します。これにより、MCP サーバーの統合が他のターゲットをゲートウェイに追加するのと同じ様に簡単に実現できます。 MCP のサイロを打破する: エンタープライズチームが統一された Gateway を必要とする理由 複数のチームが特定のドメイン用に特化した MCP サーバーを運用する e コマース注文システムのケースを考えてみましょう。 ショッピングカートチームはカート管理ツールを持つ MCP サーバーを運用しています。 製品カタログチームは製品の閲覧と検索のための MCP サーバーを運用しています。 プロモーションチームはプロモーションロジックを処理する MCP サーバーを運用しています。 以前は、注文エージェントはこれらの各 MCP サーバーに個別に接続し認証コンテキストを管理する必要がありました。AgentCore Gateway の MCP サーバーターゲットにより、単一のゲートウェイの下に統合しながら、チーム固有の所有権とアクセス制御を維持できるようになりました。このアプローチの威力は、組織利用における MCP サーバーの設計を柔軟にできることです。複数のロジックに基づいて MCP サーバーをグループ化できます。 ビジネスユニットとの整合 : MCP サーバーをビジネスユニットごとに整理します。 製品機能の境界 : 各製品チームがドメイン固有のツールを持つ MCP サーバーを所有し、明確な所有権を維持しながらエージェント用の統一されたインターフェースを提供します。 セキュリティとアクセス制御 : 異なる MCP サーバーには異なる認証メカニズムが必要です。ゲートウェイが認証の複雑さを処理し、認可されたエージェントが必要なツールに簡単にアクセスできるようにします。 次の図は、注文エージェントが AgentCore Gateway を通じて複数の MCP サーバーとやり取りする様子を示しています。エージェントはゲートウェイに接続し、利用可能なツールを発見します。各チームはドメイン固有のツールを管理しながら、組織全体での一貫したエージェント利用体験に貢献します。ゲートウェイはツール名の競合、認証を処理し、ツール全体で統一的なセマンティック検索を提供します。 AgentCore Gateway は、最新のエージェントアーキテクチャにおける統合ハブとして機能し、多様なエージェント実装を幅広いツールプロバイダーと接続するための統一されたインターフェースを提供します。図に示されているアーキテクチャは、ゲートウェイがエージェントとツール実装アプローチの間のギャップを埋める方法を示しており、現在は MCP サーバーターゲットを直接統合する機能が強化されています。 AgentCore Gateway 統合アーキテクチャ AgentCore Gateway では、ターゲットがエージェントに提供するツールを規定します。ターゲットには Lambda 関数、OpenAPI 仕様、Smithy モデル、MCP サーバー、その他のツール定義を指定することができます。 アーキテクチャのターゲット統合側は、ツール統合におけるゲートウェイの汎用性を示しています。MCP サーバーターゲット機能により、ゲートウェイはパブリック MCP サーバーからのツールを直接組み込むことができ、他のターゲットタイプと同等に扱います。この機能は、ある AgentCore Gateway インスタンスが別のインスタンスのターゲットとして機能するフェデレーションシナリオにも拡張され、組織の境界を越えた階層的なツール編成が可能になります。ゲートウェイは、ツールとして公開されるエージェントを持つ AgentCore Runtime インスタンス、プライベート MCP サーバー、従来の AWS Lambda 関数、Smithy および AWS サービス API の両方とシームレスに統合できます。 ターゲットの多様性に加えて、ゲートウェイの認証アーキテクチャは更なる運用上のメリットを提供します。ゲートウェイは、インバウンド認証をターゲットシステムから切り離し、エージェントが単一のインターフェースを通じて複数の ID プロバイダーを使用するツールにアクセスできるようにします。この中央集約型のアプローチにより、AI エージェントの開発、デプロイ、メンテナンスが簡素化されます。MCP サーバーターゲットにも同じアプローチを使用でき、ゲートウェイがターゲット用に構成された ID プロバイダーを使用してサーバーとのインターフェースの複雑さを管理します。 ゲートウェイが提供する認証機能により、統一されたアーキテクチャでツールを管理することができます。エージェントがツールの発見を要求すると、ゲートウェイはターゲットの種類によらず一貫したツール情報を提供します。セマンティック検索機能はツールタイプ全体で動作するため、エージェントは実装に関係なく関連するツールを発見できます。ツールの呼び出し中、ゲートウェイは必要なプロトコル変換、認証フロー、データ変換を処理し、異なるターゲットシステムの複雑さを管理しながら、エージェントにクリーンで一貫したインターフェースを提示します。 MCP サーバーターゲットサポートの追加は、ゲートウェイの機能における重要な進化を表しています。従来の API や Lambda 関数を維持しながら、MCP ネイティブツールを直接統合できるようになりました。この柔軟性により、段階的な移行戦略が可能になり、チームは既存の統合を継続的に運用しながら、独自のペースで MCP ネイティブ実装を採用できます。ゲートウェイの同期メカニズムは、異なるターゲットタイプ間でツール定義が最新の状態を保つことを保証し、その認証および承認システムは、基盤となるツール実装に関係なく一貫したセキュリティ制御を提供します。 ゲートウェイは、MCP サーバー、従来の API、サーバーレス関数を一貫したツール環境に統合します。この機能は、エンタープライズグレードのセキュリティとパフォーマンスとともに、エージェントコンピューティングにとって有益なインフラストラクチャとなります。 ソリューションのウォークスルー このセクションでは、AgentCore Gateway で MCP サーバーターゲットを設定する手順をご紹介します。MCP サーバーを AgentCore Gateway に追加することで、大規模な MCP サーバーを管理する際のツール管理、セキュリティ認証、運用のベストプラクティスを一元化できます。 AgentCore Gateway へ MCP Server を追加する AgentCore Gateway を作成し、MCP Server をターゲットとして追加します。 前提条件 次の前提条件を確認してください。 Amazon Bedrock AgentCore アクセス権を持つ AWS アカウント。詳細については、 Permissions for AgentCore Runtime のドキュメントを参照してください。 Python 3.12 以降 OAuth 2.0 の基本的な理解 複数のインターフェースを通じてゲートウェイを作成し、ターゲットを追加できます。 AWS SDK for Python (Boto3) AWS Management Console AWS Command Line Interface (AWS CLI) 高速で簡単なセットアップのための AgentCore starter toolkit 次の実用的な例とコードスニペットは、Amazon Bedrock AgentCore Gateway のセットアップと使用方法を示しています。インタラクティブに操作したい場合は、 GitHub の Jupyter Notebook サンプル をご参照ください。 ゲートウェイを作成する ゲートウェイを作成するには、AgentCore starter toolkit を使用して、JWT ベースのインバウンド認証用に Amazon Cognito を使用した デフォルトの認証構成を作成 できます。Cognito の代わりに別の OAuth 2.0 準拠の認証プロバイダー を使用することもできます。 import time import boto3 gateway_client = boto3.client("bedrock-agentcore-control") # 認証構成を作成します。この Gateway へのアクセスを承認されるクライアントを指定します auth_config = { "customJWTAuthorizer": { "allowedClients": ['&lt;cognito_client_id&gt;'], # クライアントは Cognito で構成された ClientId と一致する必要があります "discoveryUrl": '&lt;cognito_oauth_discovery_url&gt;', } } # create_gateway API を呼び出します # この操作は非同期なので、Gateway の作成に時間がかかる場合があります # この Gateway は CUSTOM_JWT オーソライザー、つまり auth_config で参照する Cognito User Pool を活用します def deploy_gateway(poll_interval=5): create_response = gateway_client.create_gateway( name="DemoGateway", roleArn="&lt;IAM Role&gt;", # IAM Role には Gateway の作成/一覧表示/取得/削除の権限が必要です protocolType="MCP", authorizerType="CUSTOM_JWT", authorizerConfiguration=auth_config, description="AgentCore Gateway with MCP Server Target", ) gatewayID = create_response["gatewayId"] gatewayURL = create_response["gatewayUrl"] # デプロイを待機します while True: status_response = gateway_client.get_gateway(gatewayIdentifier=gatewayID) status = status_response["status"] if status == "READY": print("✅ AgentCore Gateway is READY!") break elif status in ["FAILED"]: print(f"❌ Deployment failed: {status}") return None print(f"Status: {status} - waiting...") time.sleep(poll_interval) if __name__ == "__main__": deploy_gateway() # &lt; &gt; の値は実際の値に置き換える必要があります サンプル MCP Server を作成する 例として、静的な応答を返す 3 つの簡単なツールを持つサンプル MCP サーバーを作成しましょう。サーバーは stateless_http=True を指定した FastMCP を使用しており、これは AgentCore Runtime の互換性に必要 です。 from mcp.server.fastmcp import FastMCP mcp = FastMCP(host="0.0.0.0", stateless_http=True) @mcp.tool() def getOrder() -&gt; int: """注文を取得します""" return 123 @mcp.tool() def updateOrder(orderId: int) -&gt; int: """既存の注文を更新します""" return 456 @mcp.tool() def cancelOrder(orderId: int) -&gt; int: """既存の注文をキャンセルします""" return 789 if __name__ == "__main__": mcp.run(transport="streamable-http") AgentCore Runtime デプロイを構成する 次に、starter toolkit を使用して AgentCore Runtime デプロイを構成します。このツールキットは、起動時に Amazon ECR リポジトリを作成し、AgentCore Runtime へのデプロイ用の Dockerfile を生成できます。この実装は例として示しているもののため、実際には独自の MCP サーバー実装を使用してください。実際の環境では、MCP サーバーのインバウンド認証はゲートウェイの構成とは異なる可能性があります。その場合、 Runtime 認証用の Amazon Cognito ユーザープールを作成する サンプルコードを参照してください。 from bedrock_agentcore_starter_toolkit import Runtime from boto3.session import Session boto_session = Session() region = boto_session.region_name print(f"Using AWS region: {region}") required_files = ['mcp_server.py', 'requirements.txt'] for file in required_files: if not os.path.exists(file): raise FileNotFoundError(f"Required file {file} not found") print("All required files found ✓") agentcore_runtime = Runtime() auth_config = { "customJWTAuthorizer": { "allowedClients": [ '&lt;runtime_cognito_client_id&gt;' # クライアントは Cognito で構成された ClientId と一致する必要があり、Gateway Cognito プロバイダーとは別にすることができます ], "discoveryUrl": '&lt;cognito_oauth_discovery_url&gt;', } } print("Configuring AgentCore Runtime...") response = agentcore_runtime.configure( entrypoint="mcp_server.py", auto_create_execution_role=True, auto_create_ecr=True, requirements_file="requirements.txt", region=region, authorizer_configuration=auth_config, protocol="MCP", agent_name="mcp_server_agentcore" ) print("Configuration completed ✓") # &lt; &gt; の値は実際の値に置き換える必要があります MCP サーバーを AgentCore Runtime 上で起動する Dockerfile ができたので、MCP サーバーを AgentCore Runtime 上で起動しましょう。 print("Launching MCP server to AgentCore Runtime...") print("This may take several minutes...") launch_result = agentcore_runtime.launch() agent_arn = launch_result.agent_arn agent_id = launch_result.agent_id print("Launch completed ✓") encoded_arn = agent_arn.replace(':', '%3A').replace('/', '%2F') mcp_url = f"https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT" print(f"Agent ARN: {launch_result.agent_arn}") print(f"Agent ID: {launch_result.agent_id}") AgentCore Gateway のターゲットとして MCP サーバーを作成する AgentCore Gateway が AgentCore Runtime 上の MCP サーバーへアクセスする際のアウトバウンド認証用に、AgentCore Identity Resource Credential Provider を作成します。 identity_client = boto3.client('bedrock-agentcore-control', region_name=region) cognito_provider = identity_client.create_oauth2_credential_provider( name="gateway-mcp-server-identity", credentialProviderVendor="CustomOauth2", oauth2ProviderConfigInput={ 'customOauth2ProviderConfig': { 'oauthDiscovery': { 'discoveryUrl': '&lt;cognito_oauth_discovery_url&gt;', }, 'clientId': '&lt;runtime_cognito_client_id&gt;', # クライアントは Runtime オーソライザー用に Cognito で構成された ClientId と一致する必要があります 'clientSecret': '&lt;cognito_client_secret&gt;' } } ) cognito_provider_arn = cognito_provider['credentialProviderArn'] print(cognito_provider_arn) # &lt; &gt; の値は実際の値に置き換える必要があります MCP サーバーを指すゲートウェイターゲットを作成します。 gateway_client = boto3.client("bedrock-agentcore-control", region_name=region) create_gateway_target_response = gateway_client.create_gateway_target( name="mcp-server-target", gatewayIdentifier=gatewayID, targetConfiguration={"mcp": {"mcpServer": {"endpoint": mcp_url}}}, credentialProviderConfigurations=[ { "credentialProviderType": "OAUTH", "credentialProvider": { "oauthCredentialProvider": { "providerArn": cognito_provider_arn, "scopes": ["&lt;cognito_oauth_scopes&gt;"], } }, }, ], ) # ゲートウェイターゲットを非同期に作成します gatewayTargetID = create_gateway_target_response["targetId"] # &lt; &gt; の値は実際の値に置き換える必要があります ゲートウェイターゲットを作成した後、 get_gateway_target API 呼び出しを使用してゲートウェイターゲットのステータスを確認するポーリング処理を実装します。 import time def poll_for_status(interval=5): # READY ステータスをポーリングします while True: gateway_target_response = gateway_client.get_gateway_target(gatewayIdentifier=gatewayID, targetId=gatewayTargetID) status = gateway_target_response["status"] if status == 'READY': break elif status in ['FAILED', 'UPDATE_UNSUCCESSFUL', 'SYNCHRONIZE_UNSUCCESSFUL']: raise Exception(f"Gateway target failed with status: {status}") time.sleep(interval) poll_for_status() Strands Agents フレームワークでゲートウェイをテストする MCP サーバーからツールをリストするために、 Strands Agents でゲートウェイをテストしてみましょう。異なるエージェントフレームワークで構築された他の MCP 互換エージェントも使用できます。 from strands import Agent from mcp.client.streamable_http import streamablehttp_client from strands.tools.mcp.mcp_client import MCPClient def create_streamable_http_transport(): return streamablehttp_client(gatewayURL,headers={"Authorization": f"Bearer {token}"}) client = MCPClient(create_streamable_http_transport) with client: # listTools を呼び出します tools = client.list_tools_sync() # モデルとツールを使用してエージェントを作成します agent = Agent(model=yourmodel,tools=tools) ## 任意のモデルに置き換えることができます # サンプルプロンプトでエージェントを呼び出します。これは MCP listTools のみを呼び出し、LLM がアクセスできるツールのリストを取得します。以下は実際にツールを呼び出しません。 agent("Hi , can you list all tools available to you") # サンプルプロンプトでエージェントを呼び出し、ツールを呼び出して応答を表示します agent("Get the Order id") AgentCore Gateway での MCP サーバーのツール定義の更新 SynchronizeGatewayTargets API は、MCP サーバーターゲットからのツールのオンデマンド同期を可能にする新しい非同期操作です。MCP サーバーは、エージェントが発見して呼び出すことができるツールをホストします。時間の経過とともに、これらのツールを更新する必要があったり、既存の MCP サーバーターゲットに新しいツールを導入する必要があったりする場合があります。プロトコルハンドシェイクを実行し、利用可能なツールをインデックス化する SynchronizeGatewayTargets API を通じて外部 MCP サーバーに接続できます。この API により、MCP サーバーのツール構成を変更した後に、ツール定義を更新するタイミングを明示的に制御できます。 ターゲットが OAuth 認証で構成されている場合、API はまず AgentCore Identity サービスとやり取りして、指定された認証情報プロバイダーから必要な認証情報を取得します。これらの認証情報は、MCP サーバーとの通信を開始する前に、鮮度と利用可否について検証されます。認証情報の取得が失敗した場合、または期限切れのトークンが返された場合、同期操作は適切なエラー詳細とともに即座に失敗し、ターゲットは FAILED 状態に遷移します。認証なしで構成されたターゲットの場合、API はツール同期に直接進みます。 ツール処理ワークフローは、セッションを確立するための MCP サーバーへの初期化呼び出しから始まります。初期化が成功した後、API は MCP サーバーの tools/list 機能にページ分割された呼び出しを行い、パフォーマンスとリソース使用率を最適化するために 100 個のバッチでツールを処理します。各ツールのバッチは正規化を受け、API はターゲット固有のプレフィックスを追加して、他のターゲットからのツールとの命名の競合を防ぎます。処理中、ツール定義は異なるターゲットタイプ間での一貫性を促進するために正規化されますが、元の MCP サーバー定義からの重要なメタデータは保持されます。 同期フローは次のときに開始されます。 運用管理者が SynchronizeGatewayTargets API を開始し、AgentCore Gateway をトリガーして構成された MCP ターゲットを更新します。 ゲートウェイは MCP ターゲットへの安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。 SynchronizeGatewayTargets API は、AgentCore Gateway 内で MCP ターゲットを管理する際の重要な課題に対処します。それは、システムのパフォーマンスとリソース使用率を最適化しながら、利用可能なツールの正確な表現を維持することです。この明示的な同期アプローチが価値がある理由は次のとおりです。 スキーマの一貫性管理 : 明示的な同期がない場合、AgentCore Gateway は ListTools 操作中に MCP サーバーへのリアルタイム呼び出しを行う必要があるか (レイテンシと信頼性に影響)、古いツール定義を提供するリスクがあります。 SynchronizeGatewayTargets API は、新しいツールをデプロイした後や MCP サーバーで既存のツールを更新した後など、戦略的なタイミングでツールスキーマを更新できる制御されたメカニズムを提供します。このアプローチにより、ゲートウェイのツール定義がパフォーマンスを損なうことなくターゲット MCP サーバーの機能を正確に反映することが保証されます。 パフォーマンスへの影響のトレードオフ : API は、不整合な状態につながる可能性のある同時変更を防ぐために、同期中に楽観的ロックを実装しています。これは、競合がある場合に複数の同期リクエストが再試行する必要がある可能性があることを意味しますが、このトレードオフは次の理由から許容されます。 ツールスキーマの変更は、通常の実行時の発生ではなく、頻度の低い運用イベントです 同期のパフォーマンスコストは、通常のツール呼び出し中ではなく、明示的に要求されたときにのみ発生します キャッシュされたツール定義により、同期している間でも ListTools 操作に一貫して高いパフォーマンスが得られます。 SynchronizeGatewayTargets API を呼び出す 次のサンプルコードを使用して、SynchronizeGatewayTargets API を呼び出します。 gateway_client = boto3.client('bedrock-agentcore-control', region_name=REGION) synchronize_gateway_response = gateway_client.synchronize_gateway_targets( gatewayIdentifier=gatewayID, targetIdList=[gatewayTargetID] ) print(synchronize_gateway_response) ツールスキーマの暗黙的な同期 CreateGatewayTarget および UpdateGatewayTarget 操作中、AgentCore Gateway は明示的な SynchronizeGatewayTargets API とは異なる暗黙的な同期を実行します。この暗黙的な同期により、MCP ターゲットが有効で最新のツール定義で作成または更新されることが保証され、READY 状態のターゲットはすぐに使用可能と保証されます。これにより、作成/更新操作が他のターゲットタイプよりも時間がかかる可能性がありますが、検証されたツール定義のないターゲットを持つことの複雑さと潜在的な問題を防ぐのに役立ちます。 暗黙的な同期フローは次のときに開始されます。 運用管理者が CreateGatewayTarget または UpdateGatewayTarget 操作を使用して MCP ターゲットを作成または更新します。 AgentCore Gateway は新規または更新された MCP ターゲットを構成します。 ゲートウェイはツール定義を更新するために非同期で同期プロセスをトリガーします。 ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。 MCP ターゲットの ListTools の動作 AgentCore Gateway の ListTools 操作は、MCP ターゲットから以前に同期されたツール定義へのアクセスを提供し、パフォーマンスと信頼性を優先するキャッシュファーストアプローチに従います。ツール定義が静的に定義されている従来の OpenAPI または Lambda ターゲットとは異なり、MCP ターゲットツールは同期操作を通じて発見され、キャッシュされます。クライアントが ListTools を呼び出すと、ゲートウェイは MCP サーバーへのリアルタイム呼び出しを行うのではなく、永続ストレージからツール定義を取得します。これらの定義は、ターゲット作成/更新中の暗黙的な同期、または明示的な SynchronizeGatewayTargets API 呼び出しを通じて事前に取得したものです。この操作は正規化されたツール定義のページ分割されたリストを返します。 MCP ターゲットの InvokeTool (tools/call) の動作 MCP ターゲットの InvokeTool 操作は、 ListTools を通じて発見されたツールの実際の実行を処理し、ターゲット MCP サーバーとのリアルタイム通信を管理します。キャッシュベースの ListTools 操作とは異なり、tools/call は MCP サーバーとのアクティブな通信を必要とし、特定の認証、セッション管理、エラー処理が発生します。tools/call リクエストが到着すると、AgentCore Gateway はまず、ツールが同期された定義に存在することを検証します。MCP ターゲットの場合、AgentCore Gateway は MCP サーバーとのセッションを確立するために初期化呼び出しを実行します。ターゲットが OAuth 認証情報で構成されている場合、AgentCore Gateway は initialize 呼び出しを行う前に AgentCore Identity から新しい認証情報を取得します。これにより、ListTools が期限切れの認証情報を持つキャッシュされたツールを返した場合でも、実際の呼び出しは有効な認証を使用することが保証されます。 インバウンド認証フローは次のときに開始されます。 MCP クライアントは MCP プロトコルバージョンを使用したリクエストを AgentCore Gateway に初期化します。 次に、クライアントは tools/call リクエストをゲートウェイに送信します。 ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 ゲートウェイは MCP サーバーとの安全なセッションを初期化して、ツールの実際の実行を呼び出して処理します。 MCP ターゲットの検索ツールの動作 AgentCore Gateway の検索機能により、MCP ターゲットを含む異なるターゲットタイプ全体でツールのセマンティック検索が可能になります。MCP ターゲットの場合、検索機能は同期操作中にキャプチャされ、インデックス化された正規化されたツール定義で動作し、リアルタイムの MCP サーバー通信なしで効率的なセマンティック検索を提供します。 ツール定義が MCP ターゲットから同期されると、AgentCore Gateway は各ツールの名前、説明、パラメータの説明に対して自動的にベクトル表現を生成します。これらのベクトル表現は正規化されたツール定義と一緒に保存され、検索クエリの意図とコンテキストを理解するセマンティック検索を可能にします。従来のキーワードマッチングとは異なり、正確な用語が一致しない場合でもエージェントは関連するツールを発見できます。 ゲートウェイを通じて MCP サーバーツールを検索する 次の例を使用してゲートウェイを通じてツールを検索します。 import requests import json def search_tools(gateway_url, access_token, query): headers = { "Content-Type": "application/json", "Authorization": f"Bearer {access_token}" } payload = { "jsonrpc": "2.0", "id": "search-tools-request", "method": "tools/call", "params": { "name": "x_amz_bedrock_agentcore_search", "arguments": { "query": query } } } response = requests.post(gateway_url, headers=headers, json=payload, timeout=5) response.raise_for_status() return response.json() # 使用例 token_response = utils.get_token(user_pool_id, client_id, client_secret, scopeString, REGION) access_token = token_response['access_token'] results = search_tools(gatewayURL, access_token, "math operations") print(json.dumps(results, indent=2)) まとめ 最近発表された Amazon Bedrock AgentCore Gateway でのターゲットタイプとしての MCP サーバーサポートは、エンタープライズ AI エージェント開発における進歩です。この新機能は、セキュリティと運用効率を維持しながら MCP サーバー実装をスケーリングする際の重要な課題に対処します。既存の MCP サーバーを REST API や Lambda 関数と一緒に統合することにより、AgentCore Gateway は大規模なツール統合のためのより統一された、安全で管理しやすいソリューションを提供します。組織は、統一された認証、簡素化されたツール検出、削減されたメンテナンスオーバーヘッドの恩恵を受けながら、単一の中央集約型インターフェースを通じてツールを管理できるようになりました。 詳細情報と高度な構成については、 GitHub のコードサンプル 、 Amazon Bedrock AgentCore Gateway 開発者ガイド 、 Amazon AgentCore Gateway の料金 を参照してください。 著者について Frank Dallezotte は AWS の Senior Solutions Architect で、独立系ソフトウェアベンダーと協力して AWS 上でスケーラブルなアプリケーションを設計および構築することに情熱を持っています。彼はソフトウェアの作成、ビルドパイプラインの実装、クラウドでのこれらのソリューションのデプロイに関する経験があります。 Ganesh Thiyagarajan は Amazon Web Services (AWS) の Senior Solutions Architect で、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験があります。彼は ISV が AWS 上でアプリケーションを変革し、モダナイズするのを支援しています。また、AI/ML テクニカルフィールドコミュニティの一員として、顧客が Gen AI ソリューションを構築および拡張するのを支援しています。 Dhawal Patel は Amazon Web Services (AWS) の Principal Generative AI Tech lead です。彼は、Agentic AI、Deep learning、分散コンピューティングに関連する問題について、大企業から中規模のスタートアップまでさまざまな組織と協力してきました。

本ブログは 株式会社ほくつう 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWSアカウントマネージャーの井沼です。 昨今の異常気象により、日本の地方自治体では、市民の安全を確保するために道路状況の可視化が重要な課題となっています。 特に豪雨や豪雪など気象条件が厳しい地域では、リアルタイムの道路情報が県民の安心・安全な生活に不可欠です。 今回は、福井県様と株式会社ほくつう様が共同で取り組まれた「 みち情報ネットふくい 」の AWS を活用した事例をご紹介します。 お客様のサービス概要 「みち情報ネットふくい」は、福井県内に設置された300を超えるカメラから、リアルタイムの渋滞状況や冬期間の除雪状況を県民に提供するウェブサイトです。 国や自治体向けの総合防災情報プラットフォームを提供し、多種多様な情報通信システムの設計・システム開発・施工・メンテナンスまでのワンストップサービスを手掛ける株式会社ほくつう様が、福井県土木部道路保全課様からの依頼を受けてシステムを構築されました。 「みち情報ネットふくい」は道路管理者の垣根を超えた一元的な交通状況の把握のために、国土交通省やネクスコ、市町、隣接県である滋賀県とも連携を進め、公開するカメラ画像を大幅に増加させています。 従来の課題と背景 福井県は過去に多くの豪雨災害や雪害を経験しています。こうした状況下で、県民が安全に生活するためには、リアルタイムの道路情報が不可欠です。 しかし、従来のシステムでは、全てオンプレミス環境で実現しており、以下のような問題に直面していました： 1.[伸縮性] 悪天候時のアクセス集中に伴うカメラ画像の表示遅延 2.[信頼性] システム障害時における長時間停止のリスク 3.[俊敏性] 配信サーバーのリソース調達に要する時間 解決策の検討と AWS 採用理由 これらの課題を解決するため、ほくつう様は柔軟に拡張が可能な俊敏性を持つクラウドサービスへの移行を検討されました。 複数のクラウドプロバイダーを比較検討した結果、AWSサービスの持つ高い信頼性と伸縮性、豊富な実績とそれに伴う情報量の多さからAWSの採用を決定されました。 実装の詳細 採用した AWS サービスとその役割 「みち情報ネットふくい」のシステム構築には、以下のAWSサービスが活用されています： ・Amazon Elastic Compute Cloud (EC2)：ウェブアプリケーションの実行環境として利用 ・Amazon Simple Storage Service (S3)： システム全体のログデータの収集・保存に活用 ・Amazon CloudFront：画像データなどのコンテンツの高速配信を実現 システム構成の概要 今回の刷新により、画像の配信環境の全てをオンプレミスからAWSに切り替えています。 システムは、カメラから送信される画像データをAmazon CloudFrontを通じて配信することで、アクセス集中時にも安定的にレスポンスできる構成となっています。 特筆すべき点として、東京リージョンと大阪リージョンの両方に同一の環境を構築し、マルチリージョン構成を採用しています。 Amazon CloudFrontのオリジンフェイルオーバー機能を活用することで、プライマリのサーバーにアクセスできない場合は自動的にセカンダリに切り替わる仕組みを実装しており、ダウンタイムを最小化させています。 この構成により、アクセス集中時でも安定したパフォーマンスの提供および、サーバー障害などのシステムトラブル時においてもサービスを継続できる高信頼性を実現しています。 カメラからの画像収集は引き続きオンプレミスを併用していますが、将来的にはこちらもAWS化を検討しています。 (画像配信環境の構成イメージ ) 導入効果 AWS クラウド基盤の導入により、以下の効果が得られました： 1.ピーク時の表示時間遅延解消 (1分以上 → 最大5秒以内、高負荷でも遅延無く表示) 2.従来環境と同等のコストで高い信頼性を実現 3.急増する需要に対して俊敏にリソース拡張を実現 (2週間 → 数分) お客様の声 福井県土木部道路保全課様の声 「道路は県民の生活や経済活動を支える欠かせないインフラです。『みち情報ネットふくい』は、そうした重要な情報を県民やドライバーの皆様にリアルタイムで分かりやすく提供できる、重要な仕組みです。AWSに移行してから、アクセスの集中しやすい冬の期間においてもリアルタイムで画像表示ができるようになり、県民の方々により一層安心してご活用いただけるようになりました。今後も、より多くの方に活用いただけるよう、さらなる機能強化を図ってまいります。」 株式会社ほくつう様の声 「従来、道路情報はそれぞれの機関が個別に公開しており、災害時などに一目で全体状況を把握できる仕組みがありませんでした。そうした不便さや県民の不安を解消したいという思いが、今回のシステム開発の原動力となりました。国・県・市町・高速道路といった異なる管轄の情報を一括して確認できる『みち情報ネットふくい』は、まさに“生活の安全・安心”を支えるインフラとして、県民に寄り添うことを意識して構築したものです。従来の環境ではシステム構築に半年以上かかるところを、AWS のクラウドサービスを活用することで約 1 か月という短期間で迅速に対応することができました。さらに、AWSのマルチリージョン構成を採用することで運用負荷軽減と高い信頼性を同時に実現することができました。」 今後の展望 ほくつう様と福井県土木部道路保全課様は、今後もAWSのサービスを活用して「みち情報ネットふくい」の機能拡張を計画されています。具体的には、AI を活用した道路状況の自動分析や、より詳細な気象情報との連携など、県民の安全をさらに確保するための取り組みを検討されています。 また、このシステムの成功事例を基に、他の地方自治体への展開も視野に入れており、地域の安全確保に貢献する取り組みを拡大していく予定です。 まとめ 本事例は、AWSのクラウドサービスが地方自治体の公共サービス向上にどのように貢献できるかを示す好例です。特に災害時など、情報が最も必要とされる緊急時にこそ真価を発揮するシステムの構築は、市民の安全を守るという公共サービスの本質的な価値を高めるものと言えるでしょう。 AWSの柔軟なスケーラビリティと高い信頼性を持つサービスは、今後も多くの地方自治体が直面する課題解決に貢献していくことが期待されます。 株式会社ほくつう（右から）：社会インフラ事業本部 事業統括部 部長 山口 博文 様　営業部 社会インフラ営業課 西野 茜 様 営業部 社会インフラ営業課 森 将光 様 Amazon Web Services Japan : アカウントマネージャー 井沼 孝輔（左）

はじめに 株式会社ジャパン・インフォレックス （以下、ジャパン・インフォレックス）は、食品業界のメーカーと卸売り等の取引先の間に立つ企業である。同社は240 万件を超える商品マスターを業界標準に基づき一元管理して提供する業界最大のデータベースセンターを保持している。このデータベースは、8,000 社超のメーカーが直接登録するデータと、大手食品卸が代行登録する共有データの 2 種類のデータで構成されている。ジャパン・インフォレックスは、食品卸売業の商品マスターセンターとして業界の標準化と合理化に貢献し、流通 BMS (流通ビジネスメッセージ標準) に準拠した共通 EDI システムで流通デジタル化の推進を担っている。本ブログではジャパン・インフォレックスが実施した商品マスター刷新事例の概要と、その中でどのように AWS が活用されているかを紹介する。 &nbsp; 背景と新システムのコンセプト 関係会社と共有している現行システムは、稼働開始から 20 年以上が経過しており、これまで度重なる改修を行ってきた結果、その限界が顕在化してきていた。根本となるアーキテクチャ設計は 30 年以上前のものであり外部環境に適合しづらく、複雑化したシステムはブラックボックスになりメンテナンスに多大な労力とコストがかかっていた。食品業界全体で「デジタル化」が進むなかで、環境の変化に柔軟に対応し、安定した事業基盤を構築することが急務であった。従来のレガシーシステムを脱却し「業務効率化」「データ精度の向上」に加え新たなニーズへ対応し、商品マスターの機能・サービスの強化を図るために、現行システムの再構築が必要であった。 新システムへの刷新にあたって、以下の４点を基本コンセプトとして検討した。 持続性のあるシステム基盤に移行 HW・OSの保守終了（EOL）に備え、長期的に安定稼働できる基盤と保守体制を構築する。また多様な利用ユーザーの拡大や、多種な通信プロトコルやネットワークへの対応を見据えたシステム基盤を整備する。 保守性の高いアプリケーションに移行 レガシー開発言語を廃止し、機能改善によるセキュリティ強化をする。 利用ユーザーの利便性向上 関係会社と共有するシステムは機能改修時の障壁となるため、機能配置によるサービス独立性の確保をする。また、個別最適化したシステムではなく標準・共通化したサービスを提供する。 デジタル化に備えて新技術を採用 業務の運用負荷や、マスタ項目拡充に向けたメンテナンス負荷を下げるために、業務生産性向上と拡張性を確保する。 ソリューションの概要 新システムの基本コンセプトを実現するにあたり AWS へのシステム移行を決定した。常務取締役 情報システム部の我妻部長によると「AWS を選定した理由は、①インフラとしての堅牢性が高く、②セキュリティ対策も充実している。GuardDuty、Security Hub などのサービスがある。また、③連携パートナーが多いことも決め手となった」とのことである。 商品マスター管理システムは、IBM AIX 上で稼働しており、Micro Focus COBOL や、KornShell などレガシーなシステムとなっていた。また、対象システムは100万ステップ近くのプログラムとなっており、まずは老朽化したシステムのクラウド化への移行を優先し、その後次期システム構想に向けたモダナイゼーションを実施することとした。AWS 上のシステム構成としては、Amazon EC2（Windows Server 2019）、Amazon RDS for Oracle（Oracle 19c）を中心にしつつ、KornShell から PowerShell への変更、Micro Focus COBOL の新バージョン対応、Oracle 9i からOracle 19c への対応など古い資産の改善も図った。 ・移行元、移行先の環境 プロジェクトは複数のベンダーで構成され、エスカレーションルートを明確にして全ての情報を共有できる仕組みを整えた。また、我妻部長は、「AWS の知見が全くないところからこのプロジェクトが始まっている。AWS のソリューションアーキテクトの支援のおかげで、自分たちだけだと調査に半年かかっていたと思うが、1ヶ月程度で情報の整理ができた」と語っている。 その後、3日間にわたる開発資産や大容量データ・ファイルの移行作業において、課題発生時には迅速に対応し、タイムスケジュール内に完了した。その結果、無停止で切り替えを実現し、業務影響ゼロで本番稼働した。 ITインフラ領域を担った富士通株式会社の関根シニアマネージャーからは、「今回のプロジェクトは複数ベンダーでプロジェクトを進行したことで、技術的な検討や設計方針の調整が必要だった。しかし、AWS はサービスが豊富で、お客様の要件に合わせてカスタマイズしやすく、柔軟に対応することができた。特に Amazon RDSの利用は構築・運用面で大きなメリットがあった。」と語っている。 ・システム構成図 導入効果と今後の展開 AWS 移行プロジェクトは1年半を要したが、確立されたプロセスおよび体制により、最終的にタイムスケジュール通りの完了を実現した。我妻部長は将来の構想として①意思決定のスピードを上げること、②コストを抑えながらシステムを高度化することの2点を重要なポイントとして語っている。今後は、5 年や 10 年に一度の大規模更新などは避け、継続的な小規模アップデートによる運用を重視する。段階的な改善により総コストを抑制する戦略を採用していく方針である。 今後の展開として技術面では、データベースの OSS 化、API Gateway や AWS Lambda などを活用したサーバーレス化も目指しており、運用コストを削減していく方針である。また、S3 などを活用しデータ活用を高度化し、ビジネス面でも付加価値を高められる仕組みも目指している。そのためには、自社でコントロール可能な範囲でシステムを開発・運用・維持管理できる必要があり、組織・人材面での技術力向上と自社開発能力の強化を進めている。すでに AWS 資格取得者の社員も複数名出てきており、今後更なるスキル向上を図っていく予定である。 ジャパン・インフォレックスが持つ商品マスターは、業界の基本情報だけでなく、品質情報や市場データなどを組み合わせ、より付加価値のある情報を提供していくことで、様々なニーズへ対応しながら強化を図っていく方針である。さらに、生成AI を活用していくことで新たなサービス創出の基盤となることも期待されている。 ・ジャパン・インフォレックス様オフィスにて撮影 (ジャパン・インフォレックス様、富士通様、AWS) まとめ 本ブログでは、ジャパン・インフォレックスで実施した商品マスター刷新事例と、その中で AWS がどのように活用されているかを紹介した。AWS を利用することで 30 年間使用したレガシーシステムからの移行を実現し、技術的な課題解決だけでなく、AI 時代に対応した新たな価値創造基盤の構築が可能になった。本ブログがシステム刷新を検討している皆様の参考になりましたら幸いです。 本ブログは、ジャパン・インフォレックス様、メインベンダーである富士通様、 AWS 中村達也が共同で執筆しました。 著者について 中村 達也（Nakamura Tatsuya） SIerやWeb企業で経験を積んだ後、2019年よりAWSのソリューションアーキテクトとして従事。クラウド活用によるシステム移行や新技術でのイノベーション推進に携わる。現在はエンタープライズ企業の支援を担当し、AWSを最大限活用したデジタル化支援を行っている。

本稿は、2025 年 10 月 1 日に公開された Embracing AI-driven operations and observability at re:Invent 2025 を翻訳したものです。 組織がクラウドプレゼンスを拡大し続ける中、効果的な運用が成功の鍵としてますます重要になってきています。AWS re:Invent 2025 のクラウドオペレーショントラックでは、業界の専門家、AWS のリーダー、お客様が一堂に会し、監視とオブザーバビリティのモダナイゼーションに関する知見を共有します。このブログ記事では、運用とオブザーバビリティの主要なテーマについて説明し、クラウド運用戦略の変革に役立つセッションを紹介します。 モニタリングとオブザーバビリティトラックの参加を計画する 5 つの主要テーマにわたる 30 のセッションを提供するオペレーション管理トラックでは、ハンズオンワークショップから専門家レベルのディスカッションまで、すべての方に向けたコンテンツをご用意しています。re:Invent での参加経験を最大限に活用するために、以下をお勧めします。 優先順位を重点に : 組織の直面している運用上の課題に沿ったセッションを選択してください 形式を組み合わせる : 講義形式のセッションと、双方向対話型のワークショップ、ビルダーズセッションを組み合わせてください スキル開発を計画 : 現在のスキルレベルに合ったセッションと、スキルを伸ばすためのセッションを選択してください 早めに予約 : 人気のセッションはすぐに満席になるため、登録開始と同時に予約を入れてください 生成 AI とインテリジェントな運用 クラウドオペレーションの未来は AI が牽引しており、今年のセッションでは画期的な実装例を紹介します。 COP334 | Accelerating incident response through AIOps | Breakout Session 場所: 12 月 2 日 (火) 午後 3:00 – 4:00 PST | Wynn 生成 AI がテレメトリーデータを自動的に分析し、パターンを特定し、アクションにつながる知見を提供し、AI エージェントを活用することで、運用手法をどのように変革しているかを学びます。最新の AI 機能により、複数のシステムにまたがる何時間もの手動トラブルシューティングを、数分で解決できる効率的な調査に変換する方法を学びます。 COP326 | Elevate application and generative AI observability | Breakout Session 場所: 12 月 3 日（水）午後 2:30 ～ 3:30 PST | Wynn このセッションでは、従来のアプリケーションと生成系 AI ワークロードの両方に対して、Amazon CloudWatch の包括的なオブザーバビリティ機能をどのように活用するかをご紹介します。生成系 AI を活用したワークロードを構築するお客様は、エンドユーザーの成果、AI のパフォーマンス、稼働状態、精度、品質の問題を大規模に理解する上で課題に直面しています。 COP335 | Observability for AI Agents and Traditional Workloads | Breakout Session 場所: 12 月 3 日 (水) 午前 8:30 – 9:30 PST | Wynn このセッションでは、AI エージェントの意思決定や行動パターンから、CPU やメモリ使用率などの従来型インフラストラクチャメトリクスまで、アプリケーションスタック全体を Amazon CloudWatch で観測する方法をご紹介します。AI エージェントのパフォーマンスを既存のアプリケーション監視と併せて追跡する実践的なテクニック、AI コンポーネントと従来型サービス間の問題の相関関係、そして Amazon CloudWatch の検索機能を使用して問題を迅速に特定する方法について学びます。CCC Intelligent Solutions による講演です。 COP403 | Automate cloud operations with AI agents | Workshop 場所: 12 月 2 日 (火) 午後 12:30 – 午後 2:30 PST | Wynn この技術ワークショップに参加して、AI エージェントを使用したクラウドオペレーションの自動化ソリューションを構築しましょう。Amazon CloudWatch の調査と Amazon Bedrock Agents を使用して、合理化されたデバッグとインテリジェントな分析を体験するハンズオン学習ができます。 COP405 | Building agentic workflows for augmented observability | Code Talk 場所: 12 月 2 日火曜日 午前 11:30 – 午後 12:30 PST | Wynn このライブのインタラクティブなコーディングセッションでは、生のテレメトリーを実用的な情報に変換する AI エージェントを構築します。Amazon CloudWatch からメトリクス、ログ、トレースを相関分析するシステムを構築します。このエージェントはパターンを分析し、必要な監視設定を作成し、複雑な問題を自然言語で説明します。エージェントを本番環境に展開して運用イベントに自律的に対応し、予防的な観測ワークフローを作成する方法を紹介します。 COP418 | Monitor the quality and accuracy of your generative AI workloads | Code Talk 場所: 12 月 4 日火曜日 午後 2:00 – 3:00 PST | Wynn このライブコーディングセッションに参加して、Amazon CloudWatch が AI の可視性とトラブルシューティングをどのように実現するかを学びましょう。AWS Distro for OpenTelemetry (ADOT) を通じて自動的に計装された、Amazon Bedrock AgentCore と Amazon EKS を Strands Agent SDK で使用する AI エージェントアプリケーションを構築します。CloudWatch の生成系 AI ダッシュボードでエージェントとモデルの監視データを可視化し、レイテンシー、エラー、スロットリング、トークン使用量などの一般的な課題のトラブルシューティングを行う方法を学びます。信頼性の高い AI アプリケーションを構築・維持するための実践的なスキルを身につけて帰りましょう。 オブザーバビリティとパフォーマンスモニタリング モダンアプリケーションでは、スタック全体にわたる包括的なオブザーバビリティが必要です。 COP336 | Elevating application reliability | Breakout Session 場所: 12 月 3 日水曜日 午後 4:00 – 5:00 PST | MGM Amazon CloudWatch、AWS Systems Manager、AWS CloudTrail などの AWS ネイティブサービスを使用して、レジリエントなインフラストラクチャを構築・維持する方法をご紹介します。自動異常検出と予防措置の実装を実演します。迅速なインシデント調査と継続的な運用可視性を実現するための堅牢なロギングアーキテクチャについて説明します。生成型 AI を活用したインシデント分析の高速化と自動応答プレイブックの使用方法を学びます。インフラストラクチャの障害、セキュリティインシデント、性能劣化など、さまざまな課題に対応します。 COP404 | Build full-stack observability from applications to databases | Workshop 場所: 12 月 1 日（月）午後 3:00 ～ 5:00 PST | MGM このハンズオンワークショップでは、Amazon CloudWatch Application Signals と Database Insights を使用して包括的なオブザーバビリティを実装します。アプリケーションを流れるリクエストをトレースし、データベースのパフォーマンスメトリクスと相関付け、ボトルネックを素早く特定する方法を学びます。CloudWatch を使用して、統合ダッシュボード上でアプリケーショントレース、メトリクス、ログを監視し、SQL を使用して Aurora データベースのパフォーマンスを分析する実践的な体験ができます。 COP329 | Application Performance Monitoring: From design to implementation | Chalk Talk 場所: 12 月 1 日（月）午後 4:00 ～ 5:00 PST | Wynn このチョークトークでは、実際の現場におけるアプリケーションパフォーマンスモニタリング (APM) の課題と、Amazon CloudWatch を使用した解決方法について探ります。アーキテクチャ設計を深く掘り下げ、一般的な落とし穴を特定し、分散システムへの深い可視性を得る方法を紹介する、この参加型セッションにぜひご参加ください。 COP367 | Design effective Amazon CloudWatch dashboards and alarms | Chalk Talk 場所: 12 月 3 日（月）午後 3:00 ～ 4:00 PST | Mandalay Bay このチョークトークでは、ワークロードに適切な可視性とアクションを設計するために、Amazon CloudWatch のダッシュボードとアラームの機能について探求します。このセッションでは、SLO、カスタマーエクスペリエンス、インフラストラクチャの観点から、何を監視するかを決定する方法から始めます。Amazon CloudWatch を使用して、インシデント発生時のノイズや認知負荷を軽減し、チームがワークロードにとって重要な事項を素早く特定できるようにする方法を見ていきます。 セキュリティとコンプライアンス セキュリティは引き続き最優先事項であり、統合されたセキュリティオペレーションに焦点を当てたセッションが用意されています。 COP307 | Enhancing security visibility: building scalable log analytics | Chalk Talk 場所: 12 月 3 日（水）午前 9:00 ～ 10:00 PST | MGM このインタラクティブな Chalk Talk では、包括的なログ分析とリアルタイムな脅威検出のためのスケーラブルなソリューションをご紹介します。カスタムセキュリティダッシュボードの作成、自動アラートの実装、コンプライアンス監視ワークフローの確立に関する実践的なテクニックを説明します。 COP417 | Scale security monitoring using AWS CloudTrail with generative AI | Chalk Talk 場所: 12 月 3 日 (水) 午前 10:30 – 午前 11:30 PST | MGM このインタラクティブなチョークトークでは、AWS CloudTrail を使用したエンタープライズ規模のセキュリティ監視の構築について探ります。参加者は、VPC エンドポイントのネットワークイベント、AI を活用した自然言語クエリ、統合されたコンプライアンスダッシュボードを活用する包括的なセキュリティアーキテクチャの設計について議論します。 COP337 | Correlating compliance signals across AWS | Chalk Talk 場所: 12 月 5 日金曜日 午前 11:30 – 午後 12:30 PST | Caesars Forum このインタラクティブな対話形式のセッションでは、Amazon OpenSearch Service の新しいゼロ ETL を使用して、データサイロを排除し、組織全体で包括的なガバナンスの可視性を実現する方法を探ります。データの移動や複製を行うことなく、オンプレミスやマルチクラウド環境を含む Amazon S3 からデータを直接クエリするデータ間の関連性を分析するワークフローの設計について学びます。 オープンソースと現代的な運用 オープンソースツールを活用しているチームの場合: COP333 | Scaling open source observability stack feat. Warner Bros Discovery | Breakout Session 場所: 12 月 1 日（月）午前 11:30 ～午後 12:30 PST | Wynn このセッションでは、Amazon Managed Service for Prometheus、Amazon OpenSearch Service、Amazon Managed Grafana、OpenTelemetry などの AWS マネージド型オープンソースサービスを活用して、これらの課題を効果的に解決する方法をご紹介します。Warner Bros. Discovery が、セキュリティとコスト効率を維持しながら、大規模なテレメトリーデータの取り込みと処理のためのモダンなアーキテクチャパターンを使用して、オープンソースのオブザーバビリティを実装し、インシデント対応を加速させた方法について学びます。 COP412 | Observability: The open source way | Workshop 場所: 12 月 3 日水曜日 午後 3:30 – 午後 5:30 PST | Venetian Prometheus、OpenSearch、Grafana 向けの AWS マネージドサービスを実践的に体験します。サンプルアプリケーションをデプロイし、OpenTelemetry を使用してインストルメンテーションを行い、オブザーバビリティデータの収集、保存、分析、可視化を行います。インフラストラクチャ管理の負担なく、使い慣れたツールを使用して、コスト効率の高いスケーラブルなオブザーバビリティソリューションを構築する実践的な経験を得ることができます。 特集: AWS の舞台裏 COP415 | AWS Behind the Scenes: How AWS drives operational excellence &amp; reliability | Breakout Session 場所: 12 月 1 日（月）午後 1:30 ～ 2:30 PST | Caesars Forum この技術的な深掘りセッションでは、AWS サービスがどのように運用されているかを舞台裏からご紹介します。サービスの計測方法や監視方法について詳しく説明し、日々の運用において Amazon CloudWatch や Amazon OpenSearch の最新機能をどのように活用しているかをご紹介します。実際の運用事例と、サンプルアプリケーションを使用した実践的なデモンストレーションを通じて、AWS チームが信頼性を維持するために活用しているパターンとプラクティスについて学びます。 参加者向けの実践的な推奨事項 高度なトピックに進む前に、COP328「Implementing Observability at Scale」のような基礎的なセッションから始めましょう。 ハンズオンワークショップをお見逃しなく – COP403、COP404、COP408 では貴重な実践的な経験を得ることができます。 AI オペレーションに興味がある方は、COP334、COP335、COP413 のセッションシリーズで包括的な概要を学ぶことができます。 re:Invent 2025 にご参加いただき、AWS が AI、自動化、高度なオブザーバビリティによってクラウドオペレーションをどのように革新しているかをご覧ください。登録は現在受付中です – 今すぐお席を確保してください！ また、Venetian の AWS Village にある Monitoring &amp; observability と AIOps のキオスクにもぜひお立ち寄りください！ まだ登録していませんか？まだ参加に間に合います！ re:Invent ポータルから登録してください。 この記事の翻訳はソリューションアーキテクトの 原 が担当しました。 Jean Velez Torres Jean Velez Torres は、AGS チームの AWS ソリューションアーキテクトです。プエルトリコを拠点としており、ソフトウェア開発、DevOps のベストプラクティス、ERP システムにおいて豊富な経験を持っています。ソフトウェアエンジニアリングの技術的バックグラウンドとクラウドアーキテクチャの専門知識を組み合わせ、組織がデジタルソリューションを構築・改善することを支援しています。

本ブログは株式会社ジェネコム様と Amazon Web Services Japan 合同会社が共同で執筆しました。 みなさん、こんにちは。Amazon Web Services（以下 AWS）アカウントマネージャーの岩上です 。 株式会社ジェネコム （以下、ジェネコム）様において、顧客体験を起点としたFileMakerソリューション開発の強化とAWSクラウドサービスの活用促進を目指す取り組みの一環として、AWS主催の「Working Backwardsワークショップ」を開催しました。Claris FileMaker開発のPlatinumパートナーとして3,000以上のプロジェクト実績を持つジェネコム様の営業部門・開発部門から10名の社員の皆様にご参加いただき、顧客中心の発想やチームビルディング、実践的なアイデア創出を体験していただきました。 この記事では、ジェネコム様にご参加いただいたワークショップの模様についてご紹介させていただきます。 ジェネコム様について ジェネコム様は、Claris FileMakerを活用したシステム開発とAWSクラウドサービスの提供を通じて、お客様のDX推進を支援する企業です。特に、独自のAWS定額制サービス「 gcmCloud 」により、FileMakerシステムのクラウド環境を迅速かつ柔軟に提供しています。 本セッションを開催するにあたり、ジェネコム様からは以下のような課題とご期待を頂戴しました。 顧客視点の価値の明確化への課題感 ：事業成果を意識したサービス設計は進んでいるが、顧客視点での価値創出にはさらなる注力が必要だと認識している。本セッションを通じ、お客様の本質的な課題から逆算して考えるプロセスを体験し、顧客中心の発想を組織に根付かせたいという強いご要望がありました。 gcmCloudサービスの拡販強化 ：gcmCloud は Claris FileMaker と AWS の強みを活かした高品質なクラウドサービスです。しかし、認知度はまだ低く、さらなる普及が課題ですClaris FileMakerの運用に加え、AWSサービスとの柔軟な連携という優位性を活かし、多様なビジネス課題解決に貢献できる点を広く発信することで、認知向上と拡販施策を強化したいという強いご要望がありました。 11月開催予定の Claris カンファレンスでの効果的なアピール ：本セッションで得た知見を活かし、AWS と Claris FileMaker 連携によるセキュアな生成 AI 導入など、新しいユーザー体験を事例とともに発信したい。これにより、ジェネコム様の技術力を示し、gcmCloud サービスの認知向上と市場展開の加速を目指したいというご要望がありました。 体験版 Working Backwards セッションについて Amazonの「Working Backwards」とは、「お客様は誰ですか？」 から始まる5つの質問を通じて、本当に必要なサービスを企画・開発していく手法です。具体的には、最初にプレスリリース（以下 PR）を書くことで、これからつくるプロダクトやサービスを明確にします。このPR文章とFAQ（よくある質問）を通じ、顧客起点のサービス価値について深く考えます。 今回実施した「体験版Working Backwardsセッション」は、お客様を中心とした創造的課題解決アプローチのエッセンスを簡易に体験いただくワークショップです。個人ワークを中心とした約2.5時間のマイクロ版と、個人ワーク・グループワークの両方を行う約4時間のミニ版セッションがありますが、今回は前述の顧客中心の発想を組織に根付かせたいという課題に取り組むため、グループワークを含むミニ版をご選択いただきました。 セッションは具体的には以下の流れで進行しました。 セッションテーマの設定。今回は事前に 「FileMaker × AWSを活用した利用者の新たなユーザー体験とは？」 と合意 「お客様は誰か」「どんな課題をどう解決するか」を個人で考え、グループで議論しつつ定義 初期のアイデアを深掘りし、解決策を考え、それらを盛り込んだPR文案を作成 グループ間でPR文をレビューし、アイデアを更に発展させるためのディスカッション このプロセスを通じて、参加者はお客様中心のサービスデザインや、課題から考える逆算思考を体感し、実際の業務への応用イメージを膨らませることができました。 また参加者の理解度にばらつきがあることを考慮し、前半パートではAWS岩上によるAWS基礎、ジェネコム高岡CEOによる FileMaker の基礎について座学を組み込み、理解度の底上げを図りました。 体験版 Working Backwards セッションのワーク内容 実施効果と参加者の声 参加者は2つのチームに分かれ、対面とリモート参加のハイブリッド形式で実施。各チームには営業・開発両部門のメンバーを配置し、多様な視点からの議論を促進しました。 ワークショップ中議論の模様 実施効果と参加者の声 ワークショップ後のアンケートでは、全体満足度4.77（5点満点）と非常に高い評価をいただきました。参加者からは以下のような声が寄せられています： 「難しかったですが、何回も同じようなワークを繰り返すことで改善できるものと思うので、今後対応していきたい」（営業部門） 「当社スタッフに足りないスキルを学ばせていただきました。スタッフ達は、このワークショップを経験したことで、いくつもの気付きを得ることができたと思いますので、本日教わったことを社内でさらに煮詰めていきたいと思います。」（CEO） 特に、顧客視点でのサービス価値の創出プロセスや、部門を越えた協働の重要性について、深い気づきを得られたとの評価をいただきました。 今後の展望 本ワークショップを通じて得られた知見を活かし、ジェネコム様はFileMakerとAWSを組み合わせたソリューションの更なる進化を目指されています。AWSは引き続き、パートナー企業様と連携しながら、ジェネコム様のビジネス成長とイノベーション推進をご支援してまいります。 本記事公開時点では、体験版Working Backwardsセッションは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。

こんにちは。ソリューションアーキテクトの松本侑也です。 パブリックセクター技術統括本部で自治体のお客様の技術支援を担当しています。 2025 年 10 月 31 日に「第 2 回 自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 大阪」を開催しました。第 1 回は 2025 年 6 月 17 日に東京で開催されています。第 1 回のイベントについて知りたい方は下記のブログをご参照ください。 【開催報告】自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 東京 | Amazon Web Services ブログ このイベントは、第 1 回に引き続き、ガバメントクラウドへの標準化対象業務システムの移行を進める上で必要となる技術について深く学び (Dive Deep)、実践的なワークショップを通じて技術スキルを高め、さらに参加者同士の交流 (Have Fun) を目的としています。 本ブログでは、イベント内容を簡単にご紹介しつつ、当日のセッションやワークショップの様子を共有いたします。 本イベントは、夜に開催された 第 4 回 Gov-JAWS の参加者も合わせ、総勢 91 名が参加する大規模なイベントになりました。 イベント概要 「自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 大阪」は以下のような形で実施しました。 日時 : 2025 年 10 月 31 日 (金) 13:00-18:30 (懇親会 + Gov JAWS: 18:30-20:30) 場所 : アマゾン ウェブ サービス ジャパン合同会社 大阪オフィス 参加対象 : 運用管理補助者、ASP、自治体向けパッケージ開発者の方々、自治体 1. 事例・デジタル庁 セッション まず前半では、注目度の高いテーマについてセッションを実施しました。 生成 AI によるガバメントクラウド運用管理補助業務の効率化 – 株式会社アイネス 田中 翔 氏 GCAS Connectと公共SaaSについて – デジタル庁 宮川 亮 氏, 西村 毅 氏 2. テーマ別ワークショップ 後半は、参加者が以下の4つのワークショップから自身の関心や課題に合わせて選択できる形式を採用しました。 ワークショップ名 主な内容 クラウドにおける可用性設計の考え方と FISによるテスト実践 AWS Fault Injection Service (FIS) を利用した障害試験と障害調査における生成 AI 活用について コスト最適化 Dive Deep！インスタンス自動停止・起動の実装方法詳解 インスタンス自動停止・自動起動の実装例のご紹介、ハンズオンを通した活用方法の習得 ⽣成 AI による開発・運用効率化ワークショップ 生成 AI による業務効率化と開発支援の実践、Amazon Bedrock を利用したアプリケーション開発入門 つくば市事例から考える、自治体生成AIビジネスの作り方 自治体における生成AI活用方法を、具体的な業務課題とそれを解決するソリューション含めてご紹介 具体的に手を動かしたり、自治体職員の方から生の声を聞ける場になっており、参加者からは「割と長丁場でしたがあっという間でした。選択肢が沢山あったのも非常に良かったです。」というコメントをいただきました。 3. 特別セッション セキュリティインシデントへの備え: AWS Security Solutions Architect 中島 章博 ガバメントクラウド運用改善からSaaS製品の開発へ: 株式会社大崎コンピュータエンヂニアリング 久保田 亨 氏 事例セッション – ハイライト 生成 AI によるガバメントクラウド運用管理補助業務の効率化 株式会社アイネスの田中 翔氏から、ガバメントクラウド上で100以上の自治体システムを運用する中で直面した課題と、生成 AI を活用した解決策についてご紹介いただきました。 同社では、システム数の増加に伴い「運用監視チームの拡大には限度がある」「障害が集中した場合に SLO 内での対応が困難になる」という課題に直面していました。この課題を解決するため、AWS Failure Analysis Assistant (FA2) を Amazon Bedrock のエージェント機能と組み合わせた「エージェント版 FA2」を開発しました。 Amazon CloudWatch からアラームが発生すると、Bedrock エージェントが自動的に Amazon Athena のログやインスタンスの稼働情報を確認し、障害の発生原因と解決策を提示します。導入効果として、障害調査にかかる時間が10分の1に減少し、障害調査ができる人数が10倍に増加しています。 GCAS Connectと公共SaaSについて デジタル庁から、西村 毅氏による公共 SaaS の共通要件と、宮川 亮氏による GCAS Connect についてご紹介いただきました。 西村氏からは、2025 年 9 月 30 日に公開された「公共SaaSの共通要件にかかる技術方針 (1.0版)」について説明がありました。公共 SaaS とは、ガバメントクラウド上で稼働し、制度官庁等が標準仕様を定める情報システムを SaaS として構築したものです。アーキテクチャ要件では、カスタマイズを行わずマルチテナント構成とすること、業務アプリケーションのソースコードは全テナント共通とすること、外部システムとのデータ連携は API 連携とすることなどが必須要件として定められています。 宮川氏からは、ガバメントクラウドの利用をネットワークの面から支援する GCAS Connect についてご紹介いただきました。GCAS Connect は、同一団体内の異なる CSP 間を閉域ネットワークで接続する機能と、公共 SaaS などの共通サービスに閉域ネットワークで接続する機能を提供します。IPv6 アドレスを利用することで複雑なアドレス変換なしですべての共通サービスへ接続が可能となり、それぞれの共通サービスと個別のネットワーク回線を準備することなく、GCAS Connect という1つのネットワークで接続できるようになります。 テーマ別ワークショップ つくば市事例から考える、自治体生成 AI ビジネスの作り方 つくば市の横田 雅代氏と AWS の岩田 尚徳から、自治体基幹系システムにおける生成 AI 活用の実証事例についてご紹介しました。 実証では、AWS が公開しているオープンソースの生成 AI アプリケーション Generative AI Use Cases を活用し、2つの業務で検証を行いました。1つ目は、ひとり親相談業務での相談経過の要約です。 Amazon Transcribe による音声の書き起こしと Amazon Bedrock による要約機能を組み合わせた検証を実施しました。2つ目は、保育所入園申請の審査業務です。申請書と添付書類 (PDF) を生成 AI で照合し、不備確認を自動化する仕組みを検証しました。 つくば市においては個人番号利用事務系の領域で生成 AI を利用するにあたり、PIA (特定個人情報保護評価) の実施やセキュリティポリシーの見直しも並行して進めており、実用化に向けて着実に前進しています。 また、つくば市の事例紹介の後には Generative AI Use Cases を使ったハンズオンを行いました。画像生成やチャットなど基本的なユースケースのほか、つくば市で実証が進んでいる音声書き起こし・要約機能の実践を行いました。 参加者からは「実例を含めた内容で非常にわかりやすく、今後のビジネス化に向けて、とても勉強になりました」「身近な団体の生の事例、対応を直接伺う機会は非常に貴重で参考になるものでした」といった感想が寄せられました。 コスト最適化 Dive Deep！インスタンス自動停止・起動の実装方法詳解 AWS から、ガバメントクラウドにおけるコスト最適化の手法として、インスタンスの自動停止・起動の実装方法について詳しく解説しました。 ガバメントクラウドの費用の大半を占める Amazon EC2 、 Amazon RDS 、 AWS Fargate といったコンピュートリソースに対し、夜間休日などシステム稼働の必要性がない時間帯にリソースを停止することで、大幅なコスト削減が可能です。ただし、実装にあたってはメンテナンスウィンドウ、バックアップ、パッチ適用等の時間帯等、個々のシステムごとに考慮すべき点もあります。 本ワークショップでは、 Amazon EventBridge と AWS Step Functions を組み合わせた自動停止・起動の仕組みを解説しました。タグベースで対象リソースを管理し、EC2、ECS on Fargate、RDS などのサービスを対象に自動停止・起動を実現できます。また、Step Functions を介することで、システム固有の動作確認等の組み込みや、緊急時の手動による環境起動にも対応可能です。 参加者からは「実際でガバクラで課題になっている問題の対策となる勉強内容であった」「EventBridge も普段触ることがなかったので勉強になった」といった感想が寄せられました。 クラウドにおける可用性設計の考え方と FISによるテスト実践 AWS から、クラウドレジリエンスの考え方と AWS Fault Injection Service (FIS) を活用した障害試験、生成 AI を使った障害調査について解説しました。 従来の「壊れない」システムを目指す堅牢性のアプローチから、「壊れてもすぐ回復する」システムを目指すレジリエンスのアプローチへの意識変革が重要です。AWS FIS を使用することで、アベイラビリティーゾーンの停電シナリオなど、実環境の条件で障害注入テストを簡単に実行できます。 また、障害調査・対応の効率化として、 Amazon Q Developer と Amazon CloudWatch investigations を紹介しました。CloudWatch investigations は、関連するメトリクスやログ、 AWS CloudTrail などの情報を自動で収集・分析し、調査結果から「仮説」と「アクション」を提案することで、迅速な障害対応を支援します。 参加者からは「すぐにでも使いたい内容だった」「実際に手を動かせたので記憶に残りやすいと思いました」「新たな障害対応のアプローチが増えて非常に参考になりました」といった感想が寄せられました。 ⽣成 AI による開発・運用効率化ワークショップ AWS から、生成 AI を活用した開発・運用業務の効率化について、実践的なハンズオン形式で解説しました。 ワークショップは3つのパートで構成されました。 1つ目は、運用業務への導入として、 株式会社大崎コンピュータエンヂニアリング様の取り組み を参考にした AWS CloudTrail ログの要約機能を体験しました。 Amazon Bedrock を使用することで、大量のログから特定の操作を抽出し、確認すべきログをメール送付する仕組みを実装し、運用管理補助業務の効率化を実現します。 2つ目は、Amazon Bedrock を使った生成 AI アプリ開発の基礎として、API の呼び出し、プロンプトエンジニアリング、RAG や Tool Use の実装を体験しました。3つ目は、 Amazon Q Developer を使った AI コーディング体験です。TODO アプリや　CloudTrail 分析アプリ、AI エージェントアプリなどの開発を通じて、Amazon Q Developer が自律的にコード生成、デバッグ・エラー修正を行う様子を体験しました。 また、Amazon Q Developer CLI と Model Context Protocol (MCP) を組み合わせることで、 Amazon CloudWatch や AWS ドキュメントの情報を活用した高度な調査や開発が可能になることも紹介しました。 参加者からは「Bedrock の使い方がハードルが高いと思っていたが簡単に使えそうなことが分かったので是非社内で展開できるようにしたい」「エラーの原因究明にかなり有効性があると感じた」といった感想が寄せられました。 特別セッション – ハイライト セキュリティインシデントへの備え AWS の中島 章博から、ガバメントクラウドにおけるセキュリティインシデントへの備えについて解説しました。 脆弱な公開サーバーは短時間で攻撃され、侵害されたワークロードは暗号資産マイニングや踏み台として悪用される可能性があります。これらの脅威に対し、初期設定で有効になっている AWS CloudTrail 、 Amazon GuardDuty 、 AWS Security Hub CSPM などのセキュリティサービスを活用することが重要です。 インシデント対応に備えるため、ログの取得を確実に行うこと、セキュリティ担当者連絡先の設定と AWS からの通知への適切な対応、生成 AI を活用した効率的なログ分析などを紹介しました。 参加者からは「改めてセキュリティ対策に関する意識を向上させるきっかけとなりました」「セキュリティに関しての知見が深まりました」といったコメントをいただきました。 ガバメントクラウド運用改善から SaaS 製品の開発へ 株式会社大崎コンピュータエンヂニアリングの久保田 亨氏から、ガバメントクラウド運用における課題と、それを解決するための自動化ツール開発についてご紹介いただきました。 ASP 運用管理補助では、バッチジョブの状況やアラートメールを当番制で毎日目視確認しており、業務 SE の運用負荷が非常に高いという課題がありました。この課題に対し、 Amazon Connect を活用した運用フロー自動化を実現しました。 Amazon SES 、 AWS Lambda 、 Amazon SNS 、 Amazon EventBridge 、 Amazon DynamoDB を組み合わせることで、メール確認、切り分け、対応状況管理、連絡といった一連のフローを自動化しました。 さらに、これらの取り組みで作成したツールを SaaS サービスとして製品化しています。 参加者からは「現在人的対応を実施しているため、弊社でも同様の自動化を検討したいと思います」といったコメントをいただきました。 Gov-JAWS コミュニティの活動紹介 ワークショップと併せて、 Gov-JAWS の活動も行われました。 Gov-JAWS は、AWS のユーザーコミュニティ「 JAWS-UG 」の支部として、公共分野における AWS 利用に焦点を当てた新しいコミュニティです。政府や自治体が進める公共分野のクラウド利用に関連する知識やノウハウを共有するための場として設立されました。 &nbsp; イベント当日は夜の部として Gov-JAWS 第 4 回 Meet Up が開催され、懇親会と併せて多くの参加者が交流を深めました。このコミュニティを通じて、今後も公共分野でのクラウド活用に関する情報共有と横のつながりの拡大が期待されています。 まとめ 今回のワークショップでは、ガバメントクラウド特有の知見を共有すること・最先端の生成 AI を公共領域でどう活用していくかに焦点を当てました。自治体やデジタル庁職員の方をお招きし、様々な観点からガバメントクラウドや生成 AI の活用についてを深掘りすることができました。 参加者からは「このような場を次回も開催していただけると大変ありがたい」「大きすぎず、直接事例が聞けるイベントはありがたく今後も継続してほしいです」といったフィードバックが寄せられました。 ご参加いただいた方におかれましては、お忙しい中ご足労いただき誠にありがとうございました。 今後も、AWS ではガバメントクラウドの活用を支援するためのイベントや情報提供を継続して実施してまいります。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けております。 ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 松本 侑也 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、自治体のお客様の技術支援を担当。ガバメントクラウドにおける標準化対象業務システムの移行支援や生成 AI の活用支援に取り組んでいる。

本ブログは 2025 年 10 月 4 日に更新された Amazon News “ How AWS Wickr is helping save lives in crisis situations ” を翻訳したものです。 アフガニスタンからの避難活動からハリケーン・ヘレンの救援活動まで、AWS Wickr は非営利団体と米国陸軍の活動を支援し、戦闘地域でのセキュアな通信を実現しています。 この記事は、2023 年 3 月 23 日の初版公開以降、更新されています。 主なハイライト AWS Wickr は、タリバンの監視から保護された安全な暗号化通信を通じて、非営利団体の Operation Recovery が約 4,000 人の危険にさらされたアフガニスタン市民を避難させることを支援しました ハリケーン・ヘレンの際、米国陸軍は 15 分以内に AWS Wickr をデプロイし、複数の民間機関にわたるセキュアな通信を確立しました Wickr の HIPAA 準拠の暗号化により、COVID-19 パンデミック中に、リソースが限られた病院と遠隔地の専門医との間で重要な遠隔医療接続が可能になりました AWS Wickr は、エンドツーエンド暗号化と管理制御を通じて通信を保護するように設計された、セキュアなコラボレーションアプリケーションです。データのプライバシーとセキュリティの最高基準を維持しながら、チーム間での機密メッセージング、ファイル共有、通信を可能にします。 Wickr では、各メッセージは新しいランダムキーで暗号化されます。テキスト、ファイル、音声、動画を含むメッセージコンテンツは、転送中は解読不可能な状態を保ちます。意図された受信者以外の誰も (AWS でさえも) それを復号することはできません。 AWS Wickr が 4,000 人の危険にさらされたアフガニスタン市民の避難を支援 1 年以上にわたり、Jawid は妻と再会できるかどうか疑問に思っていました。アフガニスタン出身の元通訳である彼は、米国市民権を取得する前に米国陸軍で働いていました。Jawid は、妻の Farzana がビザ手続きを完了したら彼女を迎える計画で米国に移住しました。しかし、2021 年 8 月 15 日にタリバンがアフガニスタンを制圧したとき、彼らの計画は打ち砕かれました。Farzana は、他の何千人ものアフガニスタン市民と同様に避難できず、夫が米国陸軍とつながりがあったため、タリバンの報復の危険にさらされていました。 「昼も夜も、どうやって家族をアフガニスタンから脱出させるか考えていました」と Jawid は振り返ります。「妻はいつも『解決策は見つかった？』と聞いてきました」 タリバンの制圧後、Jawid は Operation Recovery に助けを求めました。これは、海外にいる苦境に立たされた米国人と米国の同盟者を支援することを使命とする米国を拠点とする非営利団体です。Farzana は、Operation Recovery の避難リストに載っているアフガニスタンの 7,500 人以上の申請者の 1 人でした。 「タリバンがインターネットを管理していたため、メールは信頼できる通信手段ではありませんでした」と、Operation Recovery の社長兼 CEO である Jon Collette 氏は述べています。「私たちにはセキュアな通信が必要でした」 これを実現するために、Operation Recovery は AWS Wickr に注目しました。 コンサルティング会社 UNCOMN と共に、AWS チームは Operation Recovery の既存の避難者管理システムと統合し、支援ボランティア (シェパード) と避難者にエンドツーエンド暗号化通信を提供するソリューションを開発しました。また、避難者が自分の位置情報を共有してから情報を削除できるように「閲覧後自動削除」メッセージも提供し、ウェブトラフィックを AWS トラフィックに偽装することで発見されることを回避しました。このソリューションには、避難者の避難状況に関するよくある質問に答えるボットも含まれていました。これにより、シェパードは人手を介さずに、いつでも Operation Recovery のシステムから情報を照会できるようになりました。 Operation Recovery は AWS Wickr を使用して、2021 年に Farzana を含む約 4,000 人の危険にさらされたアフガニスタン市民の避難を支援しました。3 年間離れ離れになった後、彼女はついに米国で Jawid と再会し、夫婦は新しい生活を築いています。 2021 年のタリバン制圧時に避難する危険にさらされたアフガニスタン市民。写真提供: Operation Recovery AWS Wickr は他の危機的状況でも重要な通信課題を解決 2024 年のハリケーン・ヘレン対応活動中、陸軍は地元の民間機関と連携するための通信ソリューションとして AWS Wickr の実装に成功しました。 2024 年 9 月に嵐がノースカロライナ州を襲ったとき、第 18 空挺軍団はわずか 10～15 分でセキュアな通信ネットワークを確立し、地元の法執行機関、警察、消防署がネットワークに迅速に参加できるセルフサービスオンボーディングウェブサイトを作成しました。これにより、即座に各組織間でのコミュニケーションが可能になりました。AWS Wickr は個人用デバイスと政府用デバイスの両方で機能し、民間機関が完全な軍事デバイス管理を必要とせずに参加できる階層型アクセス制御を提供し、数分以内の迅速なデプロイを可能にしました。 COVID-19 パンデミック中、 米国陸軍遠隔医療・先端技術研究センター (TATRC) は AWS Wickr を使用して命を救うソリューションを開発しました。Wickr のエンドツーエンド暗号化機能により、機密医療データを扱うための HIPAA 要件と国防総省のセキュリティ要件の両方への準拠が保証されました。彼らの National Emergency Tele-Critical Care Network (NETCCN) は、セキュアなメッセージング、ビデオ通話、ファイル共有を通じて、リソースが限られた病院と遠隔医療専門家を接続しました。このセキュアなネットワークは米国全土の 60 以上の病院に正常にデプロイされ、ミズーリ州の病院ではわずか 3 時間でソリューションが稼働しました。米国陸軍は後に、グアムでの COVID-19 急増に対応してこの重症治療ネットワークをデプロイしました。そこの看護師は、サンディエゴの ICU 医師と接続して治療を指導してもらい、緊張性気胸に苦しむ患者を救うためにこれを使用しました。 この成功を基に、米国陸軍は AWS Wickr と AWS Private 5G を組み合わせて遠隔戦闘環境で機能する Military Emergency Tele-Critical Care Platform (METCC-P) として、この技術を軍事用途に適応させました。これにより数百人の命が救われたと推定されています。軍の医学生がトレーニングに使用し、15 秒以内に使い方を習得したこの直感的なプラットフォームは、衛生兵が訓練レベルを超えたケアを提供できるようにしました。利用者の一人は「ポケットに集中治療医がいるようなもの」と表現しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 12 月 1 ~ 5 日にかけて、 AWS re:Invent 2025 が開催されます。これに伴い、 2025 年 AWS re:Invent 速報 &nbsp;が YouTube ライブで配信されます。re:Invent は日本時間の深夜からスタートしているので、なかなか情報のキャッチアップが難しいところがありますが、この速報は金曜日の 12:00 – 13:00 に開催され、お昼時間帯にスマホなどでご覧いただきやすいと思います。ぜひ事前登録のうえご覧ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年11月3日週の主要なアップデート 11/3(月) Amazon Kinesis Data Streams が On-demand Advantage モードを開始 Amazon Kinesis Data Streams で新しい On-demand Advantage モードをサポートしました。従来提供していた On-demand Standard モードでは、通常のトラフィック量の 2 倍まで即座にスケーリングされましたが、2 倍を超える場合、最大 15 分のスケーリング時間がかかっていました。新しい On-demand Advantage モードでは、Warm Throughput と呼ばれるリソースを事前準備する機能があり、そのリソースに基づいて即座にスケーリングが可能となります。また、料金の面では、新しい On-demand Advantage で各種料金の単価が安価になっています。最低の利用料金 (25 MiB/秒) が発生するため、中規模以上の使い方の場合に安価になる可能性が高い、という考え方になります。従来の On-demand Standard と比較して 60% 削減され、データ取り込みが 0.032 ドル/GB とコストが安価となります。詳細は こちらの Blog 記事をご参照ください。 Mountpoint for Amazon S3 と Mountpoint for Amazon S3 CSI driver に監視機能を追加 Mountpoint for Amazon S3 に監視機能が追加され、CloudWatch や Prometheus などの観測ツールでリアルタイム監視が可能になりました。OpenTelemetry Protocol (OTLP) を使用してリクエスト数やレイテンシなどのメトリクスを自動出力できるため、以前のようにログファイルを手動解析する手間が削減できます。S3 アクセス権限エラーなどの問題を EC2 インスタンス単位で詳細に把握でき、アプリケーションの障害対応が楽になります。詳細は こちらの手順書をご参照ください。 Amazon Cognito が Machine-to-Machine アプリクライアント価格ディメンションを削除 Amazon Cognito の machine-to-machine (M2M) 認証における料金の考え方が更新され、シンプルになりました。アプリクライアント単位の固定課金（月額 $6 /クライアント）が廃止され、トークンリクエスト数のみに基づいて課金されるようになります。多数のサービス連携が必要な環境の場合、クライアントあたり $6 の料金が気になることがありましたが、今回の廃止に伴いコスト削減が可能となります。トークンリクエストの料金は、$0.00225/1,000トークンリクエストとなっています。詳細は こちらの価格ページをご参照ください。 11/4(火) Amazon Bedrock AgentCore Runtime で Direct Code Deployment をサポート Amazon Bedrock AgentCore Runtime で Direct Code Deployment (直接コードデプロイ) という新しいデプロイ方式が追加されました。従来のコンテナベースに加えて、zip ファイルを直接アップロードしてデプロイできるようになり、コンテナ知識がない方も素早く開発が可能になります。 Amazon Bedrock AgentCore starter toolkit を利用すると。「agentcore launch」コマンドを実行するだけで、裏側で自動的に zip 化とアップロードをしてくれる機能があり、開発と動作確認のサイクルを早く回すことができます。東京リージョンなど 9 つのリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle が R7i メモリ最適化インスタンスで利用可能に、最大 64:1 のメモリ対 vCPU 比を提供 Amazon RDS for Oracle で R7i メモリ最適化インスタンスが利用可能になりました。最大 64:1 のメモリ対 vCPU 比のリソースを提供します。Oracle データベースで高メモリが必要な一方、 CPU 処理能力はそれほど必要ないワークロードに最適です。従来よりも少ない vCPU でアプリケーション性能を維持できるため、Oracle のライセンス費用を削減できます。R7i インスタンスは、Oracle Database Enterprise Edition と Oracle Database Standard Edition 2 の、Bring Your Own License (BYOL) で利用できます。License Include は利用できません。詳細は こちらのドキュメントをご参照ください。 AWS Service Reference Information で SDK オペレーションからアクションへのマッピングをサポート AWS Service Reference Information と呼ばれる、各 AWS サービスに関する情報を JSON で取得できるサービスにアップデートがあり、SDK Operation to Action Mapping (SDKオペレーションから IAM アクションへのマッピング) 機能が追加されました。AWS Service Reference Information は聞きなれないかもなのですが、プログラム上から各種自動化をするための JSON 形式の情報を取得できるサービスです。この新しい機能により、開発者は「特定の SDK オペレーション（例：boto3 の s3.get_object）を呼び出すには、どの IAM パーミッションが必要か？」という質問に対して、プログラマティックに答えを得られるようになりました。IAM ポリシー管理の自動化に活用しやすくなるアップデートです。すべてのサービスに対応しているわけではないですが、EC2、EBS など主要なサービスは対応しているように見えます。詳細は こちらのドキュメントをご参照ください。 ブラウザからもアクセスすることができて、 こちらの URL を開くと、JSON で取得できる様子が確認できます。 EC2 Auto Scaling が混合インスタンスポリシーを持つ Auto Scaling グループでのウォームプール対応を発表 EC2 Auto Scaling で、複数のインスタンスタイプを使用する Auto Scaling グループにおいてウォームプール機能が利用可能になりました。ウォームプールは事前に初期化されたインスタンスのプールで、アプリケーションの起動時間を短縮できる機能です。これまでは単一インスタンスタイプでのみ利用できましたが、今回のアップデートにより複数のインスタンスタイプと組み合わせることで、可用性を高めながら効率的にスケールアウトできるようになりました。詳細は こちらのドキュメントをご参照ください。 11/5(水) Amazon CloudFront が Anycast Static IP で IPv6 サポートを追加 Amazon CloudFront の Anycast Static IP で IPv6 サポートが追加されました。従来は IPv4 のみでしたが、今回のアップデートで IPv4 と IPv6 の両方を同時利用できるようになりました。CloudFront は通常、トラフィックを配信する能力を高めるために、動的に IP アドレスが変化します。Anycast Static IPs 機能を利用することで、固定の複数静的 IP アドレスを利用して、コンテンツの配信ができるようになります。詳細は こちらのドキュメントをご参照ください。 新しい EC2 R8a メモリ最適化インスタンスの発表 AWS が新しいメモリ最適化 EC2 R8a インスタンスの提供を開始しました。AMD EPYC 5世代プロセッサを搭載し、従来の R7a と比較してパフォーマンスが 30% 向上、コストパフォーマンスも 19% 改善されています。メモリ帯域幅も 45% 増加し、データベースやインメモリキャッシュなど大量のメモリを必要とするアプリケーションでより高速な処理が可能になります。現在バージニア北部、オハイオ、オレゴンリージョンで利用できます。 Amazon CloudWatch Database Insights がオンデマンド分析で異常検知を拡張 Amazon CloudWatch Database Insights のオンデマンド分析で異常検知機能が拡張されました。従来はデータベース負荷に基づくメトリクス分析のみでしたが、今回のアップデートでデータベースレベルや OS レベルのカウンターメトリクス、さらに負荷の高い SQL 文ごとのメトリクスでも異常を検知できるようになりました。機械学習により自動でベースライン性能と比較し、パフォーマンスのボトルネックを特定して具体的なアドバイスを提供します。これにより障害の原因特定時間を短縮でき、データベース管理者の運用負荷軽減に繋がります。詳細は こちらのドキュメントをご参照ください。 11/6(木) Amazon CloudFront が VPC オリジンのクロスアカウントサポートを発表 Amazon CloudFront で VPC オリジンのクロスアカウントサポートが開始されました。VPC オリジン機能は、CloudFront と連携するオリジンのリソースを、VPC の Private Subnet に配置できるセキュリティ向上のための機能です。これまでは同一 AWS アカウント内の VPC オリジンにしかアクセスできませんでしたが、AWS Resource Access Manager (RAM) を使用することで、異なる AWS アカウントの VPC 内にある ALB や EC2 インスタンスにもアクセス可能になります。マルチアカウント環境でもプライベートサブネット内のリソースを CloudFront 経由で配信できます。詳細は こちらのドキュメントをご参照ください。 Amazon S3 が S3 Tables でのタグをサポート開始 Amazon S3 Tables にタグ機能のサポートを発表しました。この機能により、S3 Tables に対して属性ベースアクセス制御 (ABAC) とコスト配分が可能になります。Amazon S3 Tables は、2024 年12 月の AWS re:Invent 2024 で発表された、分析ワークロードに最適化された新しい S3 の機能です。最近注目されている Apache Iceberg をネイティブサポートしていて、ACID トランザクションでデータの書き込み削除、タイムトラベルで過去のデータにアクセス、といった特徴があります。今回のアップデートで、柔軟なアクセス制御が可能となり、「Aプロジェクトに関係するメンバーは、この S3 Table のみアクセス可能」といったコントロールをタグと属性ベース (ABAC) でコントロールできるようになりました。詳細は こちらのドキュメントをご参照ください。 AWS が Builder Center で新しいリージョン計画ツールを発表 Builder Center で新ツール AWS Capabilities by Region の提供を開始しました。このツールを使うと、各リージョンで利用できる AWS サービスや機能を簡単に比較できます。特徴は、現在の提供状況に加えて、将来のロードマップも一部提供している点にあります。ロードマップなので時期がずれることもありますが、「拡張する予定があるのだな」という目安レベルでご活用いただくのがよさそうです。実際にブラウザからアクセスしてご覧いただけます。閲覧してみると、Bedrock AgentCore の Osaka region での提供が「2026 Q2」と記載があるのを発見できました (確定ではなく、目安というレベルでご確認いただければ幸いです)。 こちらの URL からアクセスが可能です。 11/7(金) AWS Advanced .NET Data Provider Driver が一般提供開始 AWS が .NET 向けの高度なデータベースドライバーを一般提供開始しました。Amazon RDS と Aurora の PostgreSQL、MySQL データベースに対応し、フェイルオーバー時間を大幅に短縮することでアプリケーションの可用性が向上します。従来は接続が切れてしまう場面でも、このドライバーを利用すると自動的に新しいプライマリデータベースに素早く再接続できます。また IAM や Secrets Manager など複数の認証方式に対応し、セキュリティも強化されています。詳細は こちらの GitHub をご参照ください。 Amazon Cognito ユーザープールが AWS PrivateLink によるプライベート接続をサポート Amazon Cognito ユーザープールが AWS PrivateLink に対応しました。これまでパブリックインターネット経由でのアクセスが必要でしたが、VPC 内からプライベート接続で Cognito にアクセスできるようになりました。セキュリティが大幅に向上し、ファイアウォール設定に頼らずに済むため、企業での採用がしやすくなります。この機能は、ユーザープール管理操作 (ユーザープールの一覧表示、ユーザープールの詳細表示など)、管理操作 (管理者によるユーザー作成など)、およびユーザー認証フロー (Cognito に保存されたローカルユーザーのサインイン) をサポートします。OAuth 2.0 認可コードフロー (Cognito 管理ログイン、ホストされた UI、ソーシャル ID プロバイダー経由のサインイン)、クライアントクレデンシャルフロー (Cognito マシン間認可)、および SAML と OIDC 標準による連携サインインは、現時点では VPC エンドポイント経由ではサポートされていません。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに みなさん、こんにちは。ソリューションアーキテクトの稲田です。 本記事は、2024 年 11 月に公開した「 三菱電機グループエンジニアが作る新しい風 “Mitsubishi Electric AWS User Group (通称:MAWS-UG)” の軌跡 」の続編です。前回記事では、三菱電機の一人のエンジニアの小さな行動から 300 人を超えるコミュニティ「MAWS-UG」へと成長した誕生ストーリーをお届けしました。MAWS-UG とは何か、どのように誕生したかについては、まずは前回記事をお読みください。 私はソリューションアーキテクトとして三菱電機グループを 4 年間担当させていただいており、MAWS-UG の成長をサポートさせていただきました。前回記事の公開から約 1 年。MAWS-UG は単なる技術交流の場を超えて、三菱電機グループの変革を牽引するコミュニティへと進化を遂げています。さらに、 2025 年 1 月には AWS とデジタル領域における戦略的協業に向けた覚書を締結 し、MAWS-UG の活動がより大きな枠組みの中でも重要な役割を担うことになりました。本記事は、大企業での技術コミュニティ形成や組織変革にご関心をお持ちの経営層や管理職の皆様、他社で同様の取り組みをご検討中の皆様にとっても参考になる内容となっています。 本記事では、MAWS-UG がもたらした具体的な成果と変化、そして次世代への継承に向けた新たな挑戦について深掘りしていきます。数字が物語る成長の軌跡、実務への昇華、そして経営層との対話まで。MAWS-UG が示す大企業変革の可能性を、メンバーの生の声とともにお伝えします。 扉が開いた瞬間 – 社外との出会いが変えたもの 前回記事の反響により、AWS 公式ユーザーグループ「JAWS-UG」や他社との技術交流機会が生まれました。これが、MAWS-UG にとって新たな扉が開かれた象徴的な出来事となりました。 AWS 公式コミュニティでの活動拡大 JAWS-UG 初心者支部・千葉支部合同 LT 会の企画中に、太田さん宛に「MAWS-UG の話をしてくれないか？」と打診あったことがきっかけに、MAWS-UG としてのはじめての JAWS-UG 初心者支部での登壇 をすることになりました。このイベントを皮切りに MAWS-UG メンバーたちは積極的に AWS 公式コミュニティの運営側に参加するようになりました。 太田さんは「JAWS-UG 初心者支部運営として社外コミュニティ活動を続けていますが、数年前まで三菱電機は “AWS を活用する会社” としての存在感は薄かったと思います。イベント出展などの全社的な取り組みの成果もあると思いますが、今では MAWS-UG メンバの活躍や前回ブログをきっかけに三菱電機の AWS に対する取り組みに言及されることもかなり増えてきており、”AWS を活用する会社”としての認知度の向上を感じます」と語ります。 小川さんは「JAWS-UG 京都を夏から運営メンバーとして参加し、当社京都事業所メンバーも参加いただくことで、内的コミュニティから外的コミュニティへの遷移を促しています。また、本京都イベントから他社 Jr. Champion と交流が生まれ、現在では関西 Jr. Champion 会のアドバイザーを務めています」と語ります。 辻尾さんも JAWS-UG 横浜支部や E-JAWS 人材育成・クラウド推進体制分科会の運営メンバーとして活動し、「三菱電機のデジタル基盤『 Serendie 』の共創空間である Serendie Street で開催することで、社外と社内のエンジニアたちを繋げる場もつくることができています」と、その意義を語ります。 塚田さんは JAWS-UG AI/ML 支部で「オフラインイベントを主催するなどユーザーに対して貢献できるように対応しています。外部コミュニティ登壇の内容がきっかけで、商業誌出版なども実現しました」と、個人のキャリアにも大きな影響をもたらしています。 会社を越えた製造業の新たな架け橋 この社外への広がりで最も注目すべきは、JAWS-UG を超えて他の製造業企業との交流に発展したことです。これは日本の製造業全体にとって重要な意味を持ちます。 オムロン、村田製作所との交流では「E-JAWS をきっかけに同じ京都にある会社、３社で集まりました。製造業ならではの悩みなどを共有し、互いに刺激をもらっています」と小川さんは語り、新たな技術領域でのコミュニティ展開も計画しています。 AWS 京都異業種交流会 – オムロン、村田製作所との交流 さらに、同業他社であるパナソニック、ダイキンとの交流会も実施し、「同業他社ではありますが、同じ日本を支える製造業として一緒に日本を盛り上げていきたいと考えています。お互いの悩みやチャレンジを共有し、刺激しあっています。交流会をきっかけに関西内製化コミュニティを本格的に立ち上げ中です」と小川さんは語ります。 辻尾さんは「MAWS-UG のような 1 つの会社を横通しできるコミュニティの他、会社間の横通しも大事だと思います。日本の製造業をグローバルで盛り上げるには、共創と競争をうまく使い分ける必要があると思います。特に AWS の活用に関しては、性質上、情報そのものよりも鮮度が大切なのでそれらを業界で共有していくことで、もっと大きな社会課題に注力できるようになると思っています」と、その普遍的な価値を語ります。 一人の記事から始まった小さな波紋が、今や三菱電機と外部コミュニティ、そして他の製造業企業を繋ぐ大きな架け橋となっていたのです。これは、日本の製造業におけるデジタル変革の新たな可能性を示しています。 AWS 製造コミュニティラウンジ – パナソニック、ダイキンとの交流 信頼が生む力-コミュニティから実務への展開 MAWS-UG で培った人間関係が、ついに実際のビジネスの場で真価を発揮する瞬間が訪れました。コミュニティでの交流を通じて築かれた信頼関係が、今度は会社の重要プロジェクトを支える力となっていたのです。 コミュニティから生まれた実働チーム 紅林さんが推進する三菱電機グループ全社の IT インフラのモダナイゼーションプロジェクト。この挑戦に、MAWS メンバーたちが続々と手を挙げました。 プロジェクトチームは順調に拡大し、50 名規模のチームに成長。数字以上に驚くべきは、そのメンバーたちの姿勢でした。従来とは異なるベンチャー気質な雰囲気やスピード感の中で、メンバーからは「このプロジェクトが楽しい！」という声が聞かれます。 MAWS-UG で培われた文化—フラットなコミュニケーション、失敗を恐れないチャレンジ精神、そして何より「楽しさ」を重視する姿勢が、プロジェクト運営にも自然に活かされていたのです。月 1 回開催されるプロジェクト懇親会も好評で、メンバーが業務時間中も終業後も楽しみながら取り組んでいる様子が伝わってきます。 会社がコミュニティを認めた日 – DXイノベーションアカデミー 「まさか会社から正式に依頼が来るとは思いませんでした」と小川さんは驚きを隠しません。 2025 年 4 月、 三菱電機が DX イノベーションアカデミー（DIA）を新設 し、2030 年までに DX 人財 2 万人を育成する壮大な計画を発表した時、そこで MAWS-UG に白羽の矢が立ったのです。クラウド人財育成のための AWS 講座の設計と講師を、MAWS-UG が担当することになりました。 この依頼によって、MAWS-UG は単なる 「業務外の有志コミュニティ」 からひとつ進化を遂げました。「本事例は会社からコミュニティへの業務依頼であり、会社としても MAWS-UG をトップエンジニアが集まる集団として認知しているという証拠です。まさに、会社とコミュニティが融合した事例と言えます」と小川さんは誇らしく語ります。 現場を知る講師たちの挑戦 MAWS-UG メンバーが設計した研修は、従来の座学中心の内容とは一線を画すものでした。「AWS 認定 SAA レベルの知識と現場での実践力を目指して、座学とオンライン自習、チーム実践演習のハイブリッド型研修を設計し、上期に約 40 人が受講し好評でした」 特に杉村さんは講師として強い想いを抱いていました。「DIA では、現場経験がある MAWS-UG メンバーが講師を務め、実際の現場で必要なスキルを厳選して講座を作っています。受講生のセキュリティ系のスキルがちょっと足りないかも…と感じたので AWS を安心・安全に使ってほしいという願いを込めて、そのポイントを教材に盛り込みました」 現場のエンジニアならではの実践的な視点を重視する姿勢が、この発言からも伺えます。 辻尾さんにとっても、この体験は特別なものでした。「自分が AWS に対して抱いているワクワク感を伝えつつ、受講者に現場で実践してもらえるような体験や学びを提供したいと考え、より実践的な内容としました。クラウドのご経験がない方も AWS でシステム構築できるぐらい、アウトプット中心の研修にしています。私たちも講師としては素人なので AWS より研修設計ができるようになるまでご支援をいただきました」 MAWS-UG の講師活動は、より大きな枠組みの中でも重要な役割を果たしています。2025 年 1 月に締結された三菱電機と AWS の戦略的協業に向けた覚書では、「AWS 教育プログラムを用いた DX 人財育成」が協業項目の一つとなっており、MAWS-UG が培ってきた講師経験や実践的な教育ノウハウが活かされることになります。 DIA で講師として登壇する相川さん 数字の向こう側にあるドラマ – 成長の軌跡 MAWS-UG の成長は、定量的なデータからも明確に読み取ることができます。しかし、数字の向こう側には、一人ひとりのドラマが隠されています。 飛躍的な資格取得と公式プログラム選出 最も象徴的な成果が AWS 全認定資格取得者（All Certification Enginerrs）の数です。「2024 年は 11 名だったのが 2025 年は 21 名まで成長しました。自分自身も刺激を受け、All Certification Engineers の１人となりました」と紅林さんは報告します。 さらに、AWS 公式プログラムでも躍進が目立ちます。 AWS Jr. Champion に 2 名 、 AWS Top Engineer に2 名 、 AWS Community Builders に 2 名 がそれぞれ選出されました。 小川さんは「Jr. Champion および次期 Jr. Champion の熱意はすごいです。現在、関西立ち上げから月 1 回ペースで開催し、多くの若者が参加しています」と、次世代育成への手応えを語ります。 活発な対外活動と地理的拡大 外部登壇も大幅に増加しました。小川さんは「年間 20 件程度の外部登壇を行い、AWS Summit 2025 では Community ブースでの登壇、AWS re:Invent 2025 では DevChat での登壇も予定しています」 と語ります。塚田さんも「個人で取り組んだ生成 AI に関連した内容だけで 2025 年は 10 件弱登壇させていただきました。中には多くの反響のいただけたものもあり、モチベーションや自信につながっています。三菱電機としてもAWS Summit 2025 Breakout Sessionをはじめ、様々な機会といただき多くの方と交流する“きっかけ“となっています」と活発な発信を続けています。 関西 MAWS-UG も順調な発展を見せ、「関西でのイベントが多く、三菱電機モビリティ株式会社 三田事業所 で開催したときは 30 人くらい増えました。首都圏から離れた地域での MAWS-UG イベントを増やすことで、製造業でのクラウドシフトや会社全体での文化醸成を達成することができます」と小川さんは分析しています。 対等な議論が生まれた場-経営層との新たな関係 「事業部門の壁をテーマに幹部 VS MAWS-UG の構図でディスカッションを実施しました。ポスターで大分遊んでしまいましたが、幹部も面白がって企画に乗っていただけました（この遊び心が大事！普通の部門なら恐ろしくてできません！）」 小川さんが振り返るこの出来事は、MAWS-UG が達成した最も画期的な変化の一つでした。経営幹部とエンジニアコミュニティが対等に議論する場の実現—それは従来の三菱電機では考えられないことでした。 経営層と MAWS-UG メンバーによるディスカッション 発見された視座の共通性 ディスカッションを通じて興味深い発見がありました。「MAWS-UG メンバーの意見は幹部に近いところがかなりありました。つまり、MAWS-UG 運営を通じて、共創や人財育成などのマインドセットが備わったことにより、幹部に近い視座を獲得できたといえます」 小川さんはこの体験から深い学びを得ています。「コミュニティの運営をするということは、人を巻き込むためのマネジメントをイベントを通じて経験していくということです。人として成長していくためには、こうした実践を通じた経験をどれだけ濃密に詰めるかなので、コミュニティのような小規模で経験を積んでいくのは得るものが多いと言えます」 Melco Day – 三菱電機グループ最大の技術イベント この新たな関係性を象徴するのが、三菱電機グループ向け AWS 社内イベント「Melco Day」です。2019 年に開始されたこのイベントは、参加者が 100 名程度から 2025 年には 2100 名を超える大規模イベントに成長しました。2025 年で第 5 回目を迎えるこのイベントは、2 つの基調講演、5 つの事例セッション、8 つのライトニングトークで構成され、基調講演には 三菱電機 専務執行役 CDO・CIO、デジタルイノベーション事業本部長 武田聡氏 や DX イノベーションセンターセンター長の朝日宣雄氏 が登壇し、事例セッションでは実際のクラウド活用事例を、ライトニングトークでは全国の製作所からクラウド利用のチャレンジ事例が発表されました。 Melco Day 2025 での基調講演風景 辻尾さんは、このイベントの意義を次のように語ります。「MAWS-UG ができる前から開催してきた三菱電機内の事業や業務の AWS 活用事例やノウハウを共有するイベントとして「Melco Day」があります。この中で、MAWS-UG のメンバーも登壇や企画の面で積極的に関わっており、さまざまな事業や業務の現場リーダーと横のつながりを更に強化できたことは、三菱電機のサイロ打破に繋がっていると感じています」 「この場においても、MAWS-UGのメンバーが複数名登壇し、技術的な話題だけでなく組織横断で仲間を作ることの重要性についても多くの方に伝えられました」と紅林さんは語ります。そして何より印象深いのは、紅林さん自身の感慨です。「前回の Melco Day 2023 の懇親会で知り合ったメンバーと MAWS-UG を立ち上げ、Melco Day 2025 でこのように注目を集めることができたことは、非常に感慨深いものでした」 MAWS-UG を立ち上げた頃は「少数の AWS 好きの集まりの様に見えたかもしれませんが、今では社内でも重要なグループであると捉えていただいていると思います」と紅林さんは振り返ります。 “お節介おじさん”たちの想い – 次世代への継承 「やや愚痴ですが、後継者がいません」- 小川さんのこの言葉には、MAWS-UG を築いてきた先駆者たちの切実な想いが込められています。成功を収めた MAWS-UG が直面する最大の課題。それは、この文化と情熱をどう次世代に引き継いでいくかということでした。 “お節介おじさん”としての覚悟 小川さんは関西 Jr. Champion 会での体験を振り返ります。「なんてキラキラした若手がいるんだ！と毎回感動してしまいます。でも彼らに話を聞くと、『先輩に連れてこられた』『先輩に薦められて登壇した』という人が多く、早くから Top Engineer や先輩 Jr. Champion に触れる環境が大切だと言えます」 この気づきが、小川さんに新たな使命感を与えました。「正直、だいたい頭の中にあった自分のやりたいことは概ねできました。ここからは次の世代につなげることが大事です。メンバー数をやみくもに増やすことはせず、しっかりとした三菱電機の新しい文化として次の 100 年に向けて確立していくことが必要です。そのためにも、若手を MAWS-UG の場に引きずり出す”お節介おじさん”としての役割を担っていくこととします」 この”お節介おじさん”という表現に込められたのは、単なる世話焼きではありません。それは、若い才能を見出し、背中を押し、機会を作り出す。そんな積極的な関与への意志でした。 好循環の設計図と門戸開放 紅林さんも、同じような想いを抱いています。「ユーザーコミュニティができたことで、社内の横のつながりが拡大してきています。このつながりを活かして、技術的な相談をもっと活性化させたいと考えています」 そのビジョンは具体的でした。「相談が活発になれば、相談を受ける側はスキルアップでき、相談する側は悩みが解消されて前に進めます。そこから新たな社内事例が生まれ、社内外で発表する機会につながります。発表を通じてメンバーのモチベーションが上がり、コミュニティがさらに活性化する。このような好循環を作りたいと考えています」 また、紅林さんは初心者への配慮も忘れません。「まだまだクラウドに触れたことが無い方も多く社内にはいますので、最初の一歩を踏み出しやすい環境・雰囲気作りができればと思います。楽しい雰囲気を伝えること、また自分たちも楽しいと感じることが重要だと思います」 技術レベルに関係なく、「やってみたい」という気持ちを大切にする文化—それこそが、次世代への最大の贈り物なのです。 最後に辻尾さんは、日本の製造業の変革について語ります。「日本の製造業も時代に合わせて変化していく必要があると考えています。従来はリソース効率にとらわれすぎていましたが、いまは社会やお客様の課題解決につながる活動が必要です。そのためには、広範囲のスキルセットに対する学びの場と、個性やスキルを発揮できるビジネスの場が重要です。MAWS-UG のようなコミュニティは、個人レベルで広範囲に学びはじめるきっかけの場として機能し、製造業におけるリソースマネジメントの変革につながると考えています」 最後に、三菱電機 専務執行役 CDO・CIO、デジタルイノベーション事業本部長 武田聡氏から MAWS-UG への期待のメッセージをいただきました。 「MAWS-UG の皆さんの活動を見ていて、まさに『変革は現場から始まる』ということを実感しています。技術への情熱を持った一人ひとりのエンジニアが、部門の壁を越えて自発的につながり、学び合い、そして実際のビジネス成果につなげている姿は、まさに私たちが目指す DX 人財の理想の形です。皆さんには、これまで培ってきた横のつながりと実践的なノウハウを活かして、より多くの仲間を巻き込み、三菱電機グループ全体のデジタル変革を牽引していただきたいと思います 」 Kiro について語り合う専務執行役 CDO・CIO、デジタルイノベーション事業本部長 武田聡氏と MAWS メンバー おわりに 前回記事から 1 年、MAWS-UG は単なる技術コミュニティを超えて、三菱電機グループの変革を牽引する存在へと進化しました。50 名規模のプロジェクトでの実働、経営層との対等な議論、他社との連携拡大。認定資格全冠保有者の倍増、AWS 公式プログラム選出者の輩出、年間 20 件を超える外部登壇—これらの成果が語るのは、一人ひとりの情熱が組織全体を変革する力となったドラマです。 しかし、真の価値は数字の向こう側にあります。部門の壁を越えた協業、失敗を恐れないチャレンジ精神、そして「楽しさ」を重視する文化。これらは単なる AWS の技術習得を超えて、三菱電機の働き方そのものを変革する力となっています。若手を MAWS の場に「引きずり出す」”お節介おじさん”たちの想いが、次の 100 年に向けた新しい文化として根付こうとしています。 他の大企業や組織で同様の課題を抱える皆様にとって、MAWS-UG の軌跡は一つの道標となることでしょう。「一人のエンジニアの小さな行動」が「組織全体の変革」へと発展する可能性—それは、”お節介おじさん”たちの情熱があれば、どこにでも実現できるのです。ぜひみなさんも一歩踏み出してみてください。 今回インタビューをさせて頂いた MAWS の運営メンバーの方々 小川 雄喜 IoT・ライフソリューション新事業推進センター所属。 AWS Top Engineer 2025 、 AWS Community Builders 、Japan AWS All Certifications Engineers 2025 選出。 JAWS-UG 京都 運営メンバー、関西 Jr. Champion 会アドバイザーとして活動。年間 20 件を超える外部登壇を通じて アジャイル や コミュニティのあり方 などを発信中。 相川 奈槻 通信システムエンジニアリングセンター所属。Japan AWS All Certifications Engineers 2024 , 2025 選出。三菱電機のテクニカルアーキテクトとして、社内 DX 部門への技術支援とネットワーク市場の動向調査・サービス拡販を推進。 辻尾 良太 DX イノベーションセンター所属。 AWS Top Engineer 2025 、Japan AWS All Certifications Engineers 2024 , 2025 選出。三菱電機のデジタル基盤「 Serendie 」の開発に従事。普段は鶏肉とたまごをよく食べますが、野鳥たちとは仲良しのつもりです。 JAWS-UG 横浜支部 や E-JAWS 人材育成・クラウド推進体制分科会の運営メンバーとして社外コミュニティでも活躍。 紅林 俊之 デジタルイノベーション事業本部所属。Japan AWS All Certifications Engineers 2025 選出。三菱電機のクラウドマイグレーションとプラットフォーム再構築を推進する 2 つの大型プロジェクトをリード。MAWS-UG 立ち上げの発起人の一人。 杉村 みさき 通信システムエンジニアリングセンター所属。Japan AWS All Certifications Engineers 2024 , 2025 選出。ネットワーク・セキュリティシステムの提案支援を担当。DX イノベーションアカデミーで AWS 講座の講師として現場視点のセキュリティ教育に注力。写真撮影が趣味で MAWS-UG ではイベントの配信・撮影を担当。 塚田 真規 AI 戦略プロジェクトグループ所属。 AWS Community Builders 2025 、Japan AWS All Certifications Engineers 2024 , 2025 選出。生成 AI 開発基盤整備と LLMOps 推進を担当。JAWS-UG AI/ML 支部でのイベント主催や商業誌出版など多方面で活動。 太田 亮 三菱電機デジタルイノベーション株式会社、経営システム事業部所属。 2019 年から JAWS-UG 初心者支部 運営に参加するベテランコミュニティ活動家。三菱電機およびグループ会社向けシステム開発を担当し、特にビル事業向けシステムの提案・開発・保守を専門とする。 インタビュアー 稲田 大陸 – いなりく AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

AWS re:Invent 2025 まであとわずか 3 週間となりました。カンファレンスでの新しいリリースや発表を今から楽しみにしています。2024年は世界中から 60,000 名もの参加者がネバダ州ラスベガスに集まり、すばらしい雰囲気の中で開催されました。AWS re:Invent 2025 への 登録 はまだ受け付けています。12 月 1 日から 5 日までラスベガスで開催されるこのイベントにぜひご参加ください。基調講演、ブレイクアウトセッション、チョークトーク、インタラクティブな学習機会、世界中のクラウド実践者とのネットワーキングが予定されています。 AWS と OpenAI は、高度な AI ワークロードを実行することを目的として AWS インフラストラクチャへの即時アクセスを OpenAI に提供する、複数年にわたる戦略的パートナーシップを 発表 しました。380 億 USD 相当のこの契約は 7 年間にわたるもので、数十万の NVIDIA GPU で構成される AWS コンピューティングリソースに対するアクセスが含まれており、エージェンティックワークロードのために数千万の CPU にスケールできます。AWS が OpenAI のために構築しているインフラストラクチャデプロイは、AI 処理の効率とパフォーマンスを最大限に高めるために最適化された高度なアーキテクチャ設計を特徴としています。同一ネットワーク上の Amazon EC2 UltraServer を使用して NVIDIA GPU (GB200 と GB300 の両方) をクラスタリングすることで、相互接続されたシステム全体で低レイテンシーのパフォーマンスが実現し、OpenAI は最適なパフォーマンスでワークロードを効率的に実行できます。これらのクラスターは、ChatGPT のための推論の提供から、次世代モデルのトレーニングまで、さまざまなワークロードをサポートするように設計されており、OpenAI の進化するニーズに柔軟に対応できます。 AWS は、Jane Goodall Institute の 65 年にわたる霊長類研究アーカイブをデジタル化するために、 Generative AI Innovation Fund を通じて 100 万 USD を拠出 しました。このプロジェクトでは、 Amazon Bedrock と Amazon SageMaker を利用して、チンパンジーとヒヒに関する手書きのフィールドノート、フィルム映像、観察データをアナログからデジタル形式に変換します。このデジタルトランスフォーメーションでは、マルチモーダルの 大規模言語モデル (LLM) と埋め込みモデルを採用し、初めて、世界中の科学者が研究アーカイブを検索およびアクセスできるようにします。AWS は Ode と協力してユーザーエクスペリエンスを構築し、Jane Goodall Institute が AI テクノロジーを導入して研究と保全活動を促進するのをサポートしています。私は、世界的に有名な霊長類学者の Jane Goodall 氏が亡くなったと聞き、深い悲しみに暮れました。このプロジェクトによって同氏の生涯の研究が保存され、世界中の研究者がアクセスできるようになると知り、心が慰められました。これは、同氏のすばらしい功績にふさわしいプロジェクトです。 クラウドと AI を通じて数十年にわたる研究を変革しています。Jane Goodall 博士とフィールドスタッフが、タンザニアのゴンベ渓流国立公園でゴブリンを観察しています。提供: Jane Goodall Institute 11 月 3 日週のリリース では、11 月 3 日週の新しい発表を見てみましょう: Amazon S3 が S3 Tables でタグをサポート – Amazon S3 は、属性ベースのアクセス制御 (ABAC) とコスト配分のために、S3 Tables でタグをサポートするようになりました。ABAC のタグを使用すると、テーブルバケットやテーブルにアクセスするユーザーとロールの許可を自動管理できるため、AWS Identity and Access Management (IAM) または S3 Tables のリソースベースのポリシーの更新を頻繁に行う必要がなくなり、アクセスガバナンスが大規模に簡素化されます。さらに、個々のテーブルにタグを追加することで、AWS Billing and Cost Management を利用して AWS のコストを追跡および整理できます。 Amazon EC2 R8a メモリ最適化インスタンスの一般提供を開始 – R8a インスタンスは、最大周波数 4.5 GHz の第 5 世代 AMD EPYC プロセッサ (旧コード名: Turin) を搭載し、R7a インスタンスと比較して最大 30% 高いパフォーマンスと最大 19% 優れた料金パフォーマンスを実現し、メモリ帯域幅は 45% 増加しています。第 6 世代 Nitro Card を使用した AWS Nitro System 上に構築されたこれらのインスタンスは、SQL および NoSQL データベース、分散型ウェブスケールインメモリキャッシュ、インメモリデータベース、リアルタイムビッグデータ分析、Electronic Design Automation (EDA) アプリケーションなど、高パフォーマンスでメモリを大量に消費するワークロード向けに設計されています。R8a インスタンスは SAP 認定を受けており、2 つのベアメタルサイズを含む 12 のサイズを提供します。 EC2 Auto Scaling が混合インスタンスポリシーのウォームプールのサポートを発表 – EC2 Auto Scaling グループは、混合インスタンスポリシーが設定された Auto Scaling グループのためにウォームプールをサポートするようになりました。ウォームプールは、事前に初期化された EC2 インスタンスのプールを作成し、アプリケーショントラフィックを迅速に処理できるようにすることで、アプリケーションの伸縮性を高めます。この特徴量は、大量のデータをディスクに書き込んだり、複雑なカスタムスクリプトを実行したりするなど、初期化プロセスに時間がかかるアプリケーションで役立ちます。ウォームプールとインスタンスタイプの柔軟性を組み合わせることで、Auto Scaling グループは、複数のインスタンスタイプにアプリケーションをデプロイしながら、最大サイズまで迅速にスケールアウトし、可用性を高めることができます。この特徴量は、手動のインスタンスタイプリストまたは属性ベースのインスタンスタイプの選択を通じて複数のオンデマンドインスタンスタイプ向けに設定された Auto Scaling グループで動作します。 Amazon Bedrock AgentCore Runtime が直接コードデプロイをサポート – Amazon Bedrock AgentCore Runtime は、AI エージェント向けにコンテナベースのデプロイと直接コードアップロードの 2 つのデプロイ方法を提供するようになりました。迅速なプロトタイピングとイテレーションではコードを含む zip ファイルを直接アップロードし、カスタム設定が必要となる複雑なユースケースではコンテナベースのオプションを選択できます。AgentCore Runtime は、エージェントとツールを大規模に実行するためのサーバーレスフレームワークとモデルに依拠しないランタイムを提供します。コードを含む zip の直接アップロード特徴量にはドラッグアンドドロップ機能が含まれており、プロトタイピングのイテレーションサイクルを高速化しながら、エンタープライズセキュリティと本番デプロイのスケーリング機能を維持できます。 リージョン別の AWS 機能がリージョンレベルのプランニングで利用可能に – リージョン別の AWS 特徴量は、リージョン全体の AWS のサービス、特徴量、API、AWS CloudFormation リソースを検索して比較するのに役立ちます。このプランニングツールは、インタラクティブなインターフェイスを提供し、サービスの可用性を詳しく確認したり、複数のリージョンを並べて比較したり、将来を見据えたロードマップ情報を表示したりできます。特定のサービスや特徴量を検索したり、API オペレーションの可用性を確認したり、CloudFormation リソースタイプのサポートを確認したり、特殊なインスタンスを含む EC2 インスタンスタイプの可用性を確認したりできます。このツールは、[利用可能]、[計画中]、[拡張なし]、[四半期ごとの方向性レベルでのリリース計画] などの可用性の状態を表示します。また、リージョン別の AWS 機能に関するデータは、AWS Knowledge MCP サーバーを通じてアクセスでき、リージョン拡張計画のオートメーション、開発ワークフローや継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインへの統合を可能にします。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent 2025 – 12 月 1 日から 5 日は、最新の AWS イノベーション、ピアツーピア学習、エキスパート主導のディスカッション、貴重なネットワーキングの機会のために世界中のクラウドパイオニアが米国ラスベガスに集結する AWS re:Invest に参加しましょう。 イベントカタログ もぜひご覧ください。 AWS Builder Loft – サンフランシスコにあるテクノロジーハブ。ビルダーがアイデアを共有し、学び、コラボレーションする場所です。このスペースでは、AI から新興テクノロジーまで、さまざまなトピックをカバーする、業界エキスパートによるセッション、ハンズオンワークショップ、コミュニティイベントが開催されます。 開催予定のセッション を閲覧して、関心のあるイベントにぜひご参加ください。 AWS Skills Center Seattle 4 周年記念イベント – 11 月 20 日に開催される、基調講演、専門家パネル、採用担当者によるインサイト、抽選会、仮想参加オプションなどが盛りだくさんの無料公開イベントです。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。今後開催される AWS 主催の対面およびバーチャルイベント 、 デベロッパー向けイベント 、 スタートアップ向けイベント については、こちらをご覧ください。 11 月 10 日週のニュースは以上です。11 月 17 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS には、「各 リージョン ではどの AWS 機能が利用できますか?」という質問がよく寄せられます。 これは、リージョンレベルの拡張を計画している場合、データレジデンシー要件へのコンプライアンスを確保している場合、またはディザスタリカバリのためのアーキテクチャを構築している場合に、非常に重要な質問です。 11 月 6 日、リージョン間で AWS のサービス、特徴量、API、 AWS CloudFormation リソースを見つけて比較するのに役立つ新しい計画ツールである リージョン別の AWS 機能 をご紹介します。インタラクティブなインターフェイスを通じてサービスの可用性を確認したり、複数のリージョンを並べて比較したり、将来に向けたロードマップに関する情報を確認したりできます。この詳細な可視性は、グローバルデプロイについて十分な情報に基づいた意思決定を行い、プロジェクトの遅延やコストのかかるやり直しを回避するのに役立ちます。 リージョンレベルの比較の開始方法 開始するには、 AWS Builder Center にアクセスし、 [AWS 機能] と [探索を開始] を選択します。 [サービスと特徴量] を選択すると、ドロップダウンリストから最も関心のある AWS リージョンを選択できます。検索ボックスを使用すると、特定のサービスや特徴量を迅速に見つけることができます。例えば、 Amazon Simple Storage Service (Amazon S3) の特徴量を比較するために、米国 (バージニア北部)、アジアパシフィック (ソウル)、アジアパシフィック (台北) リージョンを選択しました。 これで、選択したリージョンでのサービスと特徴量の可用性と、リリース予定時期を確認できます。 [共通の特徴量のみを表示] を選択すると、選択したすべてのリージョンで一貫して利用可能な特徴量を特定できるため、どこでも利用可能なサービスを使用して設計できます。 結果には、次の状態を使用して可用性が示されます: [使用可能] (リージョンで稼働中)、 [計画中] (リリース戦略を評価中)、 [拡張なし] (リージョンではリリースされません)、 [2026 Q1] (指定された四半期の、方向性レベルのリリース計画)。 リージョン別の AWS 特徴量は、サービスと特徴量の検索に加えて、利用可能な API と CloudFormation リソースの検索にも役立ちます。例として、 API オペレーション を調べるために、欧州 (ストックホルム) と中東 (UAE) のリージョンを追加し、さまざまな地域での Amazon DynamoDB の特徴量を比較しました。このツールを使用すると、各リージョンで API オペレーションが利用できるかどうかを表示および検索できます。 [CloudFormation リソース] タブは、テンプレートを記述する前に、特定のリソースタイプ向けのリージョンレベルのサポートを確認するのに役立ちます。 [サービス] 、 [タイプ] 、 [プロパティ] 、 [設定] で検索できます。例えば、 Amazon API Gateway のデプロイを計画しているときに、 AWS::ApiGateway::Account などのリソースタイプの可用性を確認できます。 また、Graviton ベース、GPU 対応、メモリ最適化バリアントなどの特殊なインスタンスを含む、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプの可用性などの詳細なリソースも検索できます。例えば、第 7 世代コンピューティング最適化メタルインスタンスを検索すると、 c7i.metal-24xl インスタンスと c7i.metal-48xl インスタンスがすべての対象リージョンで利用可能であることがわかりました。 インタラクティブなインターフェイスを超えて、リージョン別の AWS 機能データは、 AWS Knowledge MCP サーバー を通じてアクセスすることもできます。これにより、リージョン拡張計画の自動化、リージョンとサービスの選択に関する AI を活用したレコメンデーションの生成、リージョンレベルの機能チェックの、開発ワークフローと CI/CD パイプラインへの直接統合が可能になります。 今すぐご利用いただけます AWS Builder Center でリージョン別の AWS 機能 を今すぐ探索できます。また、Knowledge MCP サーバーは無料で一般公開されており、AWS アカウントは必要ありません。使用量にはレート制限が適用されます。セットアップの手順については、 開始方法ガイド に従ってください。 皆様からのフィードバックをお待ちしております。 ビルダーサポート ページを通じてご提案をぜひお寄せください。 – Channy 原文は こちら です。

はじめに 近年、金融機関や公共機関をはじめとする多くの組織では、クラウドネイティブなアプリケーション構築のメリットが広く認識され始めています。一方で、セキュリティやガバナンス上の理由から、依然として「インターネットに接続しない閉域環境でのシステム構築」が求められるケースも少なくありません。 特に Web アプリケーションを閉域環境で提供する場合、静的コンテンツのホスティングをどのように実現するかが課題となります。これまで、ALB（Application Load Balancer）、S3、PrivateLink を組み合わせて閉域環境で SPA（Single Page Application）をホスティングする構成が一般的に利用されてきました（参考： ALB、S3、PrivateLinkによる内部 HTTPS 静的ウェブサイトのホスティング ）。 しかし、この構成には S3 のバケット名と ALB のカスタムドメイン名を一致させる必要があるという制約が存在していました。2025 年 10 月 15 日に Application Load Balancer の「 URL およびホストヘッダーの書き換え機能 」が追加され、この制約が解消されました。アップデートの詳細については下記の記事をご参照ください。 参考： AWS Application Load Balancer で URL とホストヘッダーの書き換えが可能に 本記事では、これまで紹介してきた閉域 SPA 構成をベースに、新たな ALB の機能を活用した最新アーキテクチャと、その仕組みがどのように成り立っているのかを解説します。 全体構成 以下は、閉域環境で静的ウェブサイトをホスティングする構成例です。 この構成では、ALB・S3・PrivateLink を組み合わせて、インターネットに接続せずに HTTPS での静的コンテンツ配信を実現しています。設定のポイントは以下のとおりです。 ALB の IP ターゲットとして S3 の Interface Endpoint の IP アドレスを登録 リスナールールにホストヘッダー・URL 変換のルールを追加 次の章では、それぞれの設定ポイントについて詳しく解説します。 ALB のターゲットに S3 の Interface Endpoint の IP を登録 S3 には Gateway Endpoint と Interface Endpoint の 2 種類の VPC エンドポイントが存在 します。この構成では、Interface Endpoint のプライベート IP アドレスを ALB のターゲットとして登録します。 Interface Endpoint のネットワークインターフェイスは、VPC エンドポイントの存続期間中は同じプライベート IP アドレスを維持する ため、安定したルーティングが可能です。 設定のポイントとして、 ALB のヘルスチェックは GET メソッドで実行されます が、S3 の Interface Endpoint へのリクエストはリダイレクト（ 307 ）で返されるため、ヘルスチェックの正常判定コードを 307 に設定する必要があります。 例えば、curl コマンドで S3 の Interface Endpoint へアクセスした例を見てみましょう。 $ curl -v 10.0.1.xx * Trying 10.0.1.xx:80... * Connected to 10.0.1.xx (10.0.1.xx) port 80 &gt; GET / HTTP/1.1 &gt; Host: 10.0.1.xx &gt; User-Agent: curl/8.5.0 &gt; Accept: */* &gt; &lt; HTTP/1.1 307 Temporary Redirect &lt; x-amz-id-2: TS9ySeNbBtaQsWaK1EZ3WyKR2lkgQ5bm4llTfUX+TTjFfCuIxxxxxxxxxxxxxxx= &lt; x-amz-request-id: GDV3AZME5xxxxxx &lt; Date: Tue, 04 Nov 2025 05:25:14 GMT &lt; Location: https://aws.amazon.com/s3/ &lt; Content-Length: 0 &lt; Server: AmazonS3 これを踏まえ、Target Group のヘルスチェックの設定例は下記のようになります。 プロトコルは HTTP、ポート番号は 80 番、ヘルスチェックの成功コードは 307 を設定しています。 リスナールールとホストヘッダー変換 ALB にアクセスした際、リクエストのホストヘッダーには通常、ALB 側で設定されたカスタムドメイン名が含まれます。一方、 S3 の Interface Endpoint ではホストヘッダーを元にアクセス先のバケットを特定 します。 例えば、VPC Endpoint 経由で sample-bucket という名前の S3 バケットへアクセスしたい場合はホストヘッダーにバケット名を入れる必要があります。この際、VPC Endpoint へのアクセスは IP アドレスでも構いません。 curl -v \ http://10.0.1.xx/test.txt \ -H "Host: sample-bucket" そのため、従来の構成では ALB のドメイン名と S3 バケット名を一致させる必要がありました。今回追加された ALB の「ホストヘッダー書き換え」機能を利用することで、ALB 内でホストヘッダーを動的に変換できるようになり、ALB のカスタムドメイン名と S3 バケット名を一致させる制約が不要になりました。 設定例は下記の通りです。「トランスフォームホストヘッダー」においてホストヘッダーを S3 のバケット名へ変換しています。 これにより、運用や証明書管理の柔軟性が大きく向上します。 SPA 側の考慮事項 フロントエンドのライブラリで URL のパスに依存するようなルーティングを行なっている場合（React の場合、 BrowserRouter など）、 /index.html 以外のパスに直接アクセスした場合に XML のエラーが表示されます。 この場合、URL のハッシュを利用したルーティング（React の場合、 HashRouter など）を利用することで、トップページ以外へも URL で直接アクセスができるようになります。URL の表示は https://app.example.local/index.html#/about のようになります。 また、今回導入された URL パス変換の機能を利用すれば、 app.example.local/ のように URL を表示することができます。 URL のハッシュを利用したルーティングをしている場合は、URL の表示は https://app.example.local/#/about のようになります。 ただし、ハッシュを利用したルーティングを利用している場合でも、存在しない URL へ直接アクセスした場合（例: app.example.local/test ）は XML のエラーが表示される点には注意が必要です。 まとめ 本記事では、ALB の URL・ホストヘッダー書き換え機能 を活用した、閉域環境での最新の静的ウェブホスティング構成を紹介しました。このアップデートにより、これまで制約となっていた S3 バケット名とカスタムドメイン名の一致要件が解消され、閉域環境でもより柔軟でシンプルなサーバーレス構成が可能になりました。 金融・公共分野をはじめ、セキュリティ要件の高い環境でのクラウド利用において、ぜひこのアーキテクチャをご活用ください。 参考情報 閉域網で AWS のサーバーレスアーキテクチャ (SPA) を利用する方法 ALB、S3、PrivateLinkによる内部HTTPS静的ウェブサイトのホスティング 著者について 松本 侑也 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、自治体のお客様の技術支援を担当。ガバメントクラウドにおける標準化対象業務システムの移行支援や生成 AI の活用支援に取り組んでいる。

本ブログは 2025 年 10 月 21 日に公開された AWS Blog “ The attendee guide to digital sovereignty sessions at AWS re:Invent 2025 ” を翻訳したものです。 AWS re:Invent 2025 は、 Amazon Web Services (AWS) が主催する最高峰のクラウドコンピューティングカンファレンスで、2025 年 12 月 1 日から 5 日までネバダ州ラスベガスで開催されます。このフラッグシップイベントでは、世界中のクラウドコミュニティが一堂に会し、複数の会場で学習、コラボレーション、イノベーションに没頭できる 1 週間を体験できます。クラウドエキスパート、ビジネスリーダー、テクノロジー愛好家など、どなたであっても、re:Invent は最先端のクラウドソリューションを探求し、AWS のエキスパートと交流し、世界中の仲間と貴重なつながりを築く比類のない機会を得られます。 技術的な深掘りから戦略的なビジネスセッションまで、re:Invent 2025 は最先端のクラウドテクノロジーを理解し活用するための入口です。 Expo では、AWS Village のデジタル主権とハイブリッドクラウドのキオスクを訪れて、今後提供される AWS European Sovereign Cloud やその他のデジタル主権ソリューションについて学び、AWS のエキスパートに質問できます。 クラウド業界の最新イノベーションを発見し、技術的な深い洞察を得て、デジタル主権のためにクラウド投資を最適化する方法を学びましょう。今年のセッションでは、 AWS Nitro System の強化されたセキュリティ機能、拡大するデジタル主権ソリューションのポートフォリオ、 AWS European Sovereign Cloud の最新開発など、AWS のデジタル主権に対応した設計アプローチを包括的にカバーします。デジタル主権への関心が高まる中、AWS がどのようにソブリンクラウドソリューションでイノベーションを続け、お客様がクラウドの全機能を活用しながらデータの管理を維持できるようにしているかをご覧ください。 今すぐセッションの参加を登録 して、参加者ポータルまたは AWS Events モバイルアプリにサインインすることで、学習パスをカスタマイズできます。 ブレイクアウトセッションとコードトーク AWS re:Invent のアジェンダにセッションを追加し、時間と場所の情報を確認するには、セッションタイトルのリンクを選択してください。 セキュリティトラック SEC201 | ブレイクアウトセッション | AWS European Sovereign Cloud: From concept to reality (AWS European Sovereign Cloud: コンセプトから現実へ) Colm MacCárthaigh、VP/Distinguished Engineer – EC2 Networking、AWS、Addy Upreti、Principal Technical Product Manager – EC2 Core Product Management、AWS AWS European Sovereign Cloud を直接ご確認ください。この新しい独立したインフラストラクチャの専用アーキテクチャ、EU ベースの運用管理、このクラウドを支える運用管理とガバナンスおよび法的フレームワークを探求します。このクラウドソリューションがどのようにヨーロッパ内で完全に構築、運用、保護されているかを学びます。 クラウドオペレーショントラック COP409 | コードトーク | Building Sovereign Cloud Environments (ソブリンクラウド環境の構築) Bo Lechangeur、Pr. Delivery Engineer – STCE、AWS、Randy Domingo、Sr. Software Development Manager – STCE、AWS 組織がグローバルに事業を拡大する中で、進化するデータレジデンシー、セキュリティ、コンプライアンス、事業継続性の要件を満たす必要があります。このセッションでは、 AWS Control Tower と Landing Zone Accelerator on AWS が、国固有のコンプライアンスフレームワーク、リージョンサービスの選択、データ移動の自動制御、越境データ転送など、主要なデジタル主権要件をどのようにサポートするかを探ります。実際の例を通じて、組織が AWS を活用して国固有のセキュリティ制御を実装し、マルチリージョンデプロイ全体で運用の一貫性を維持し、クラウドコンプライアンスを加速し、セキュリティとコンプライアンスを大規模に自動デプロイする方法を示します。 ハイブリッドクラウドとマルチクラウドトラック HMC202 | ブレイクアウトセッション | AWS wherever you need it: From the cloud to the edge (必要な場所で AWS を: クラウドからエッジまで) Spencer Dillard、Director, Software Development – EC2 Edge、AWS、Madhura Kale、Senior Manager, Technical Product Management – EC2 Core、AWS ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、デジタル主権のニーズにより、一部はオンプレミスまたはエッジに残ります。このセッションでは、AWS Outposts、AWS Local Zones、AWS 専有ローカルゾーン、AWS IoT などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像、スマートマニュファクチャリング、データレジデンシー要件を持つ生成 AI アプリケーションなどのハイブリッドクラウドとエッジコンピューティングワークロードをどのようにサポートするかを学びます。 HMC308 | ブレイクアウトセッション | Build generative and agentic AI applications on-premises and at the edge (オンプレミスとエッジでの生成 AI およびエージェンティック AI アプリケーションの構築) Chris McEvilly、Senior Solutions Architect – Hybrid Edge、AWS、Pranav Chachra、Principal Technical Product Manager – EC2 Core、AWS、Fernando Galves、Senior Solutions Architect – Generative AI、AWS お客様が生成 AI とエージェンティック AI の実装をパイロットから本番環境にスケールする際、イノベーションのスピードとデータ主権要件、低レイテンシーのエッジ処理ニーズ、スペース、電力、コスト効率のバランスを取る必要があります。このセッションでは、AWS Local Zones、AWS Outposts、AWS 専有ローカルゾーンを使用して生成 AI とエージェンティック AI ソリューションを構築する方法を探ります。分散ロケーション全体に基盤モデルをデプロイするためのアーキテクチャパターンとベストプラクティスを発見してください。ローカルに保存されたデータを使用した Retrieval Augmented Generation (RAG) の実装方法を学びます。モデル選択と最適化の戦略に関する洞察を得ます。 HMC310 | ブレイクアウトセッション | Digital sovereignty and data residency with AWS Hybrid and Edge services (AWS ハイブリッドおよびエッジサービスによるデジタル主権とデータレジデンシー) Mallory Gershenfeld、Senior Technical Product Manager – S3、AWS、Ben Lavasani、Senior Specialist – Hybrid and Edge、AWS、Majd Aldeen Masriah、Director of Enterprise – Architecture、Geida 世界中の国々で、少なくとも 1 つのコピー、または場合によってはすべてのデータを特定の地理的またはソブリンな場所に保存または処理することを要求するデータレジデンシーとデジタル主権に関する法律が導入または更新されており、お客様に新たな課題をもたらしています。このセッションでは、AWS 専有ローカルゾーン、AWS Local Zones、AWS Outposts などの AWS サービスが、デジタル主権のユースケースにどのように役立つかを探ります。エッジでのデプロイ全体におけるデータレジデンシー、セキュリティ制御、運用の一貫性のベストプラクティスを検討します。 インタラクティブセッション (チョークトークとワークショップ) セキュリティトラック SEC301 | チョークトーク | Architecting for Digital Sovereignty: From Foundation to Practice (デジタル主権のためのアーキテクチャ設計: 基礎から実践まで) Eric Rose、Principal Security SA – Global Services Security、AWS、Armin Schneider、Digital Sovereignty Specialist SA – Global Services Security Digital Sovereignty セキュリティの基礎とクラウドにおけるデジタル主権の実装のための実践的なアーキテクチャ戦略を橋渡しするこのチョークトークにご参加ください。アラブ首長国連邦サイバーセキュリティ評議会や今後提供される AWS European Sovereign Cloud の実例を通じて、組織が AWS のデジタル主権機能を効果的に活用する方法を探ります。データレジデンシー、運用管理、お客様がデータを完全に管理できるようにするセキュリティ対策のための実践的なアーキテクチャパターンを取り上げます。クラウドアーキテクトやセキュリティチームに最適なこのセッションでは、政府機関や企業のデプロイ事例を用いて、デジタル主権要件とクラウドの利点のバランスを取るソリューションを設計する方法を紹介します。 ハイブリッドクラウドとマルチクラウドトラック HMC301 | ワークショップ | Build and operate resilient and performant distributed applications (耐障害性と高性能な分散アプリケーションの構築と運用) Saravanan Shanmugam、Senior Solutions Architect – Hybrid Edge、AWS、Sedji Gaouaou、Senior Solutions Architect – Networking、AWS このワークショップでは、データレジデンシーとパフォーマンス要件を満たしながら、マルチジオ運用のためのアプリケーションを設計および実装する方法を探ります。限られたハードウェアリソースで分散ロケーション全体にわたる耐障害性とレイテンシーに敏感なアプリケーションを設計する方法を学びます。また、分散ハイブリッドアーキテクチャ、エッジネットワーキングの実装、規制要件と高可用性ニーズのバランスを取るトラフィック管理ソリューションを探ります。分散ロケーション全体でデータ主権を維持しながらパフォーマンスを最適化するための実践的な戦略を学びましょう。 HMC302 | ワークショップ | Implementing agentic AI solutions on-premises and at the edge (オンプレミスとエッジでのエージェンティック AI ソリューションの実装) Fernando Galves、Senior Solutions Architect – Generative AI、AWS、Kyle Palasti、Senior Solutions Architect – Hybrid Edge、AWS 政府機関や標準化団体がデータ保護とプライバシー規制を策定する中、組織はクラウドでの生成 AI ツールの使用と、データレジデンシー要件を満たすためにオンプレミスに保持する必要がある規制対象データを組み合わせる必要性が高まっています。このワークショップでは、 Amazon Bedrock AgentCore を AWS Outposts や AWS Local Zones などのハイブリッドおよびエッジサービスに拡張し、Model Context Protocol (MCP) とエージェント間 (A2A) 通信を使用してオンプレミスデータで分散エージェンティックアプリケーションを構築し、モデルの結果を改善する方法を学びます。Amazon Bedrock と Strands Agents を使用したハイブリッドエージェンティック AI を実際に体験しながら、AWS のハイブリッドおよびエッジサービスを探求してください。 HMC305 | ワークショップ | Low-latency SLM deployment: Optimizing inference on AWS Hybrid and Edge Services (低レイテンシー SLM デプロイ: AWS ハイブリッドおよびエッジサービスでの推論の最適化) Leonardo Solano、Principal Solutions Architect – Networking &amp; Hybrid Edge、AWS、Obed Gutierrez、Senior Solutions Architect、AWS このハンズオンワークショップでは、AWS Local Zones と AWS Outposts を使用してエッジで Small Language Model (SLM) を実行するための完全なローカルデプロイアプローチを実演します。この実装は、低レイテンシー推論の実現と、ローカルインフラストラクチャ内での Retrieval Augmented Generation (RAG) アプリケーションを通じたデータ主権コンプライアンスの実現に焦点を当てています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと公開されているモデルを使用して、エッジ環境で SLM をデプロイ、最適化、管理する方法を学びます。本番環境シナリオにおける厳格なレイテンシーとデータレジデンシー要件を満たすために、RAG システムと言語モデルがローカルで動作することを確認します。 HMC312 | チョークトーク | Implement RAG while meeting data residency requirements (データレジデンシー要件を満たしながら RAG を実装する) Lakshmi VP、Solutions Architect、AWS、Akshata Ketkar、Senior Product Manager – EC2 Edge、AWS 政府機関がデータ保護とプライバシー規制を策定する中、組織はデータ主権要件を満たすためにオンプレミスに保持する必要がある規制対象データで生成 AI を活用する必要性が高まっています。このセッションでは、オンプレミスおよびエッジデータで Retrieval Augmented Generation (RAG) を実装する方法を探ります。ハイブリッド RAG アーキテクチャのために Amazon Bedrock AgentCore を AWS Outposts と AWS Local Zones に拡張する方法、またはより厳格なデータレジデンシー要件のためにローカル RAG アーキテクチャを構築する方法を学びます。モデルサイズを増やすことなく精度を向上させ、推論コストを削減し、プロンプトの結果に対するガバナンスと制御を強化するための、リランカーモデルなどの最新技術を発見してください。 HMC314 | チョークトーク | Deploying for resilience: HA/DR strategies for AWS Outposts and Local Zones (耐障害性のためのデプロイ: AWS Outposts と Local Zones の HA/DR 戦略) Afaq Khan、Senior Product Manager – EC2 Edge、AWS、Brianna Rosentrater、Senior Solutions Architect – Hybrid Edge、AWS エッジでのミッションクリティカルなワークロードには、堅牢な高可用性 (HA) とディザスタリカバリ (DR) 戦略が必要です。このチョークトークでは、AWS のハイブリッドクラウドおよびエッジコンピューティングサービスを使用して、回復力のあるデプロイを計画および実装する方法を学びます。AWS Local Zones と AWS Outposts を使用したエッジインフラストラクチャのアーキテクチャ設計方法を検討し、ネットワーキング、コンピューティング、ストレージの冗長性の主要な側面を取り上げます。実際のお客様の事例とリファレンスアーキテクチャを通じて、障害モード全体でビジネス継続性を維持するためのデプロイパターンとベストプラクティスを探ります。エッジデプロイで RPO/RTO 目標を達成するための実践的な戦略を学びましょう。 HMC403 | コードトーク | AI を活用したエッジアーキテクチャの構築と回復性の最適化 (AI による耐障害性のあるエッジアーキテクチャの構築と最適化) Jesus Federico、Principal Solutions Architect – Generative AI、AWS、Robert Belson、Senior Solutions Architect &amp; Developer Advocate、AWS このライブコーディングセッションでは、AI を使用してエッジインフラストラクチャの運用を自動化する方法を探ります。最新の AWS Outposts と AWS Local Zones API を使用して、真に回復力のあるアーキテクチャを構築する方法を発見してください。Outposts のハードウェアインベントリのクエリ、インテリジェントなリソース配置の実装、フェイルオーバー設定の自動化に関する実際のコード例を紹介します。Amazon Bedrock がアーキテクチャパターンを分析し、最適なコンポーネント配置のための Infrastructure as Code (IaC) の推奨事項を生成する方法を学びます。API 統合、自動ヘルスチェック、動的リソース割り当ての実践的な手法に加えて、適応性の高い高可用性エッジソリューションを構築するための実用的なコードサンプルとデプロイテンプレートを持ち帰ることができます。 HMC316 | チョークトーク | Addressing digital sovereignty with hybrid cloud solutions (ハイブリッドクラウドソリューションによるデジタル主権への対応) Sherry Lin、Principal Product Manager – EC2 Core、AWS、Enrico Liguori、Solutions Architect – Networking、AWS 組織が革新的なソリューションをグローバルにスケールする際、複雑なデジタル主権要件に対応する必要があります。このセッションでは、規制要件を満たしながらグローバルなスケーリングを加速するために AWS がどのように役立つかを探ります。AWS Local Zones、AWS 専有ローカルゾーン、AWS Outposts、AWS European Sovereign Cloud に焦点を当てて、さまざまなソブリンインフラストラクチャオプションを比較します。デジタル主権のニーズに最適なオプションを選択し、データレジデンシーと回復性のためにアプリケーションを設計する方法を学びます。データの保存、処理、転送方法を規制し、不正なデータアクセスを防ぐためのセキュリティ制御を実装する方法を発見してください。 パートナーとのセッションを含むデジタル主権コンテンツの全体像については、 AWS re:Invent カタログ を参照し、デジタル主権の関心領域でフィルタリングしてください。直接参加できない場合は、 追加費用なしで提供されるバーチャル限定パスに登録 して、基調講演とイノベーショントークをライブストリーミングで視聴し、今すぐオンデマンドのブレイクアウトセッションにアクセスできます。ラスベガスまたはライブストリームでお会いしましょう! Brittany Bunch Brittany は、アトランタを拠点とする AWS セキュリティマーケティングチームのプロダクトマーケティングマネージャーです。デジタル主権に焦点を当てており、Amazon での雇用者ブランディングを含む 10 年以上のブランドマーケティング経験を持っています。AWS に入社する前は、いくつかの大規模エンタープライズ企業でブランドマーケティングイニシアチブを主導していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

このブログ記事は、フリー株式会社様 AI プロダクトマネージャー木佐森氏へのインタビュー内容をもとに、AWS ソリューションアーキテクトの福本が執筆し、フリー株式会社様が監修しています。 「スモールビジネスを、世界の主役に。」をミッションに掲げるフリー株式会社。創業時から「AI CFO」というビジョンを描いてきた同社は、LLM (Large Language Models、大規模言語モデル) 登場を機に、生成 AI を活用した AI ネイティブな組織への本格的な変革に乗り出した。技術選定、組織体制の構築、そして何より「成功基準」という独自のフレームワークを確立し、全社で AI 活用を推進。チャットサポートの解決率約 50% 向上、営業効率の劇的な改善、そして BPaaS (Business Process as a Service) 事業での構造改革など、着実に成果を積み重ねている。AI プロダクトマネージャーの木佐森氏に、その変革の全貌を聞いた。 「AI ネイティブ」を実現する組織づくりと取り組み 統合型経営プラットフォームとしてのビジョン ──まず、freee の事業概要と AI 活用の位置づけについて教えてください。 木佐森氏： freee は「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームを提供しています。単なる会計ソフトではなく、バックオフィス業務全般を統合し、経営を誰でもできるようにするプラットフォームを目指しています。 実は、freee の前身は 1 年だけ「CFO株式会社」という社名だったんです。これは「Chief Financial Officer」ではなく「Cloud Finance Officer」を意味しており、クラウドからあらゆるビジネスの CFO になれるサービスを作りたいという想いが込められていました。創業者の佐々木が描いていた将来像として「AI CFO」というコンセプトがあり、これが現在の AI 戦略の原点になっています。 この「自動化」という創業以来のビジョンが、LLM の登場によって大きく進展しました。私たちは今年から「AI ネイティブカンパニー」へのシフトを本格化させています。私たちにとって生成 AI、特に AI エージェントは、創業当初からの念願であった「自動化」を実現するためのラストワンマイルを埋めるものだと位置づけています。これまではシステム化が難しかったコミュニケーションや、導入・使いこなしといった非構造化された課題を AI が解決することで、スモールビジネスの皆様が特別なスキルを意識することなく、自然体でなめらかに業務を自動化できる。その世界の実現に向けて、全社で取り組みを加速させています。 AI ラボの組織体制：横串で支える専門家集団 ──freee では AI 活用をどのような組織体制で推進されているのですか？ 木佐森氏： AI ラボという横串組織で推進しています。ML (Machine Learning、機械学習) の専門性を持ったメンバーが集結し、縦串である各プロダクトチームに出向いて協働し、AI 機能を実装していくスタイルです。 LLM が登場する前は、OCR (Optical Character Recognition、光学的文字認識) や勘定科目の推定など、モデルを学習させる古典的な ML 中心でした。しかし LLM 登場後は役割が大きく変わりました。RAG（Retrieval-Augmented Generation、検索拡張生成）などの周辺開発や、各プロダクトへの「イネーブルメント活動」、そして LLM 基盤の整備など、活動範囲が広がっています。 今年に入って SLM (Small Language Models、小規模言語モデル) が注目され始め、ファインチューニングの重要性が再認識されたことで、ML 専門性の価値が再確認されました。領収書の読み取りなど、freee のコア機能においては、汎用モデルよりもタスクに特化した SLM をファインチューニングした方が精度が出る。実際にやってみると、精度向上に加えて、レスポンスが圧倒的に速く、コストも安い。適材適所で最適なモデルを使い分けることを重視しています。 ── なぜ freee さんが技術的かつ専門性的に難易度の高いファインチューニングに意欲的に取り組まれているのかと思っていたのですがお話を伺って、もともと機械学習の専門家チームがいて、そういう素養があったからこそ実現できたのだと理解できました。 技術とビジネスを繋ぐ：AI プロダクトマネージャーの役割 ──木佐森さんご自身は freee でどのような役割を担っているのか教えてください。 木佐森氏： 私は AI ラボに所属し、「AI プロダクトマネージャー」として活動しています。これは技術とビジネスの両面を理解した上で、AI 活用によるユーザー価値創出を推進する役割です。 私のバックグラウンドとしては、物理学で博士を取った後、機械学習アルゴリズムの研究に移り、企業で研究をしてきました。その後、自分で開発したアルゴリズムを事業化するために起業した経験もあります。この技術理解とビジネス視点の掛け算が、freee での AI 活用推進において活きていると思います。 具体的な役割は大きく 3 つあります。第一に、経営陣と密に連携して「解くべき課題」を定めること。技術的なフィージビリティを見極めながら、経営インパクトがある領域にピン止めしていく。第二にプレーヤーとしてその定めた領域の新規プロジェクトのゼロからイチを作ること。企画から初期のプロトタイピングまでを高速に行って蓋然性を示し、リリースまで走り抜ける。第三に、各プロダクトチームがボトムアップで始めた AI 活用案件に対して、レビュアーとして入り込み、成功基準の策定支援や評価方法のアドバイスを行うことです。 ──各チームの取り組みをどのようにサポートされているのですか？ 木佐森氏： いくつかの仕組みを並行して回しています。 まず「AI サロン」という場を作っています。数年前に比べるとだいぶ意識が変わってきましたが、プロダクト担当によっては、解きたい課題に対する手段としてAIが想起されるが、具体的な方法や進め方がわからないケースがあります。「壁打ちウェルカム、知識教えてあげるよ」という雰囲気でサポート活動をしています。 他にも、各プロダクトチームに対して、勉強会やハッカソンを実施してきました。AWS の方にご協力いただいた勉強会やハンズオンもありましたね。 また、属人化しないための工夫として、自分が考えたことや学んだことを丁寧に書き出して、ドキュメント化しています。社内では、そのドキュメントを食わせた LLM アプリを構築し、誰でも気軽に知見へアクセスできるようにしています。こうした仕組み化は、AI ラボのノウハウをスケールさせ、組織全体の AI リテラシーを引き上げるために不可欠です。 AI 活用の具体的成果 ──これまでの AI 活用でどのような成果が出ていますか？ 木佐森氏： いくつか代表的な事例があります。 まず、チャットサポートでの LLM 活用では、質問への解決率を約 50% 向上させました。これは 2023 年の早い段階から取り組んできた成果です。 セールス支援では、社内外の会議内容の自動要約から CRM への情報入力を行うAIシステム「つばめAUTO」を構築しました。このシステムでは、商談の事後処理時間を 45.2％、架電の事後処理時間を 56.2％ それぞれ削減できています。これによって営業の効率が大幅に向上し、今年の夏には Forbes の外部評価*もいただきました。 *Forbes JAPAN NEW SALES OF THE YEAR2025で「AIトランスフォーメーション賞」 また、AWS の 生成 AI 実用化推進プログラム で成果報告させていただいた「AI クイック解説」という機能もあります。これは財務データの分析を手助けする機能で、ジュニア層の場合は 月 10 時間以上、シニア層でも数時間の作業負荷軽減が期待できます。 他にも様々な施策に取り組んできました。現在最も力を入れているのが、BPaaS 事業を中心とした AI エージェントを使ったOCR 関連技術です。 成功を支える要因 最大の要因：経営層の深い理解とコミットメント ──こうした成果を生み出せた要因は何だと考えていますか？ 木佐森氏： これは迷わず答えられます。「経営トップの AI に対する理解とコミットメントが強い」ことです。 freee の経営陣は、技術バックグラウンドの有無にかかわらず、自分で AI を使うのはもちろん、AI コーディングのツールなどを使って自分で API を叩いて実装を試しています。CEO の佐々木に呼び出されて「これ Cline (AI コーディングツール) で作ったんだけど、なんか精度上がらないからどうしたらいい？」と相談されたこともあります（笑）。 この理解があるからこそ、AI を使うことの必然性や、むしろ危機感を持って進めていかなければならないという共通認識ができているんです。 ──確かに貴社の経営層の熱意は我々もひしひしと感じています。経営層がそこまで深い理解を持つに至った背景について教えてください。 木佐森氏： グローバルとのギャップですね。freee がベンチマークとする企業において、彼らがどれだけ AI に投資しているかを追っている中で危機感につながりました。 それがきっかけで、経営層も自分で手を動かすことに時間を充てるようになりました。 ──経営層の深い理解があることは素晴らしいですね。経営層の理解に加えて、現場での AI 活用を組織全体に広げると言った観点ではいかがですか？ 木佐森氏： おっしゃる通りです。経営層だけでなく、そもそもの話として企業全体に挑戦の文化が根付いていることが重要だと思います。freee では「マジ価値」という考え方があり、その中には「アウトプット→思考」と呼ぶ指針があります。これは『まず、アウトプットする。そして考え、改善する。』という指針です。失敗は責められるものではなく、あえてやる/挑戦することが推奨されています。この文化に加えて、AI の活用が進むような組織的な仕組みも整えています。 ※マジ価値: ユーザーにとって本質的な価値があると自信を持って言えることをする ──AWS でも「Customer Obsession（顧客への執着）」というリーダーシッププリンシプルを掲げており、顧客のために挑戦し、失敗から学ぶ文化を大切にしています。また「Bias for Action（行動を重視））」という、計算されたリスクテイクを評価する考え方もあります。こうした文化的な土台があってこそ、AI のような新しい技術への挑戦が組織全体に広がっていくのだと、改めて実感しました。 「成功基準」というフレームワークの確立 ──組織全体に AI 活用を浸透させる上で、どのような工夫をされてきましたか？ 木佐森氏： 最近特に力を入れているのが「成功基準」の策定と浸透です。よく言われることかもしれませんが、一周回って、これをブラッシュアップした状態で組織に徹底することが最も重要だと確信しています。 成功基準というのは、精度などの品質指標と、それが顧客価値やビジネスインパクトにどう繋がるかを明確に結びつける指標です。具体的には、コスト、精度、レイテンシ、品質といった技術的な要素が、どれだけのユーザー価値を生み出すのかを定量化します。 ──具体的にはどのように定量化するのでしょうか？ 木佐森氏： 私は担当チームに「精度が 1% 上がったら、ユーザーの価値はどのくらい上がるんですか？」という問いを投げかけています。これを考えてきてください、と。 この問いは簡単には答えられません。でも、顧客の十分な理解と技術の十分な理解の両面が揃って初めて答えられる。これを事前に定めておくことが重要なんです。 よくあるアンチパターンは、担当チームが「精度 90% を目指します！」と言ってくることです。私は必ず聞き返します。「なんの指標をどう測って 90% なの？ 90% 出たら何のユーザー価値が出るの？」と（笑）。 ──ビジネスとテックで知識が組織をまたがっているので、この答えを揃えるのは難しいですよね。 木佐森氏： まさに。だからこそ、AI ラボのような横串組織が機能するんです。これからの時代、どんどんこういったビジネスと技術の両方を理解して、データドリブンにユーザの業務をモデリングして、マイルストーンを立ててプロジェクトマネージメントができる人材が強く求められると感じています。 成功基準の実践知：「確認コスト」と「修正コスト」の分離 ──成功基準を設定する上で、見落としがちなポイントはありますか？ 木佐森氏： 一つ重要なのが、「確認コスト」と「修正コスト」を明確に分けることです。これは意外と見逃されがちなんです。 例えば、100 枚の領収書を処理する場合を考えてみてください。AI の精度が 80% だろうが 90% だろうが、結局 100 枚全部を確認しなければいけないですよね。つまり確認コストは変わらない。精度が上がっても、間違っている 20 枚や 10 枚の修正時間が減るだけで、100 枚を見るという確認時間は変わらないんです。 さらに厄介なのが、「AI によって便利になったようで、実は確認コストが増えている」というケースです。AI がやったことを確認するのに手間がかかっているのに、それに気づいていない。これも撤退基準として重要な視点です。 撤退基準は、成功基準とセットで事前に決めておくべきです。「今より悪くなる」というのは明確な撤退基準ですが、意外と見逃されがちなんです。サンクコストを払うのは誰でも苦手なので、事前に決めておくことが重要です。 この考え方は、OCR に限らず様々な AI 活用シーンで重要です。例えば、AI が生成した文章のチェックや、AI による分類結果の確認など、「全件を見る必要があるのか」「間違いだけを修正すればいいのか」という違いによって、価値は大きく変わります。AI 導入の ROI を正しく評価するためには、この業務フロー全体のコスト構造を深く理解することが不可欠です。 AI 導入の ROI を正しく評価し、プロジェクトを成功に導くには、AI を組み込んだ後の「業務フロー全体」を設計し直し、その総コストで評価することが不可欠です。そして、このコスト構造の分析を、プロジェクト初期に定める「成功基準」と「撤退基準」に明確に組み込むこと。これこそが、AI 活用を PoC (概念実証) で終わらせず、真の価値創出につなげるための重要な鍵となります。 AIデータ化β での実践と成功基準の進化 記帳作業のコスト構造を変える：AIデータ化β の挑戦 ※AIデータ化β：複数の AI エージェントが協調して OCR の読み取り精度を検証・改善する仕組み 木佐森氏： これは単なる精度向上ではなく、先ほど話した「確認コスト」の問題を解決し、税理事務所・会計事務所の記帳作業全体のコスト構造を根本から変えるプロジェクトです。まさに成功基準の考え方を実践した取り組みと言えます。 そこで私たちが導入したのが読み取り精度に対する「自信」の評価と、それを元にしたアラート機能です。読み取りが簡単な典型的な証憑もあれば、複数税率や人が見ても判断が難しい証憑もあるわけです。読み取った結果に対して、別の LLM が客観的に「この結果、本当に自信ある？」と評価するんです。これによって、「確認すべきもの」と「そのまま通していいもの」を分けることができました。アラートが出た 20% だけを確認すればよくなり、確認時間を 80% 削減できるわけです。「確認時間」と「修正時間」を切り分けたことがポイントです。 ──LLM の活用が真の意味で活きるような発想ですね。 木佐森氏： ここで重要なのが、「強弱をはっきりつける」ことです。グレーゾーンを作らない。例えば、アラートを出す閾値を中途半端なところに設定すると、「これで本当にいいのか」という議論が後から起きやすくなる。 最初は「80% は人手で見てもいいから、残り 20% は本当に 99% の精度で保証できるものを作りましょう」と、強弱を明確につけたんです。どっちつかずではなく、こっち、と決める。そうすることで、後で成功基準を修正するときも判断がしやすくなります。 さらに、日付や金額は絶対にズレてほしくないが、摘要欄は意味が分かればいい、というように、項目ごとに精度の基準を変えています。「落とすところは落とす」という判断も重要なんです。すべてを完璧にしようとすると、結局どれも中途半端になってしまう。 成功基準の進化：仮説検証のサイクル ──成功基準は一度決めたら固定なのですか？ 木佐森氏： いいえ、それは違います。我々はユーザーの方々と一緒にプロダクト作りをする思いで開発をしています。成功基準は仮説であって、早い時点でプロトタイピングを実際にユーザーに当ててみて修正していくものです。 例えば AIデータ化β の取り組み では、数値の読み取り精度とテキストの読み取り精度が全然違うことが分かりました。それなら分けて評価しよう、と基準を分解していったんです。「あ、ここが違ったわ」「ここもっと深掘りできるわ」という発見を基に、成功基準をブレイクダウンしていく。 成功基準を作るための内容を落とし込んだ成功基準シートを作成して、「これ埋めてきてください」と言って渡し、自律的に成功基準を作成できるような仕組みを整えています。 ただ、結局は使ってもらえないと分からない部分も多いので、成功基準を作るためのプロンプトも用意しています。LLM にこのプロンプトを投げると、成功基準のドラフトが出てくるんです。自分自身もこれを使って整理しています。 ──LLM を活用して成功基準を作る、というのは興味深いアプローチですね。 木佐森氏： この成功基準を自分で一回二回作ると「ああ、こういう風に作ればいいんだ」という感覚が掴めるんですが、その感覚をプロンプトに落とし込んだものを社内の LLM アプリとして公開しています。ただ、この LLM アプリでも一定はワークはするんですが、結局のところ、やっぱり人に聞きたくなるんですよね（笑）。なので、現在は単なるプロンプトではなく、よりエージェンティックなものを作成して実験中です。「実質、木佐森エージェント」を作ろうと。 こうした仕組みを通じて、AI ラボや私だけができるのではなく、組織として誰もが AI でユーザー価値を届けられる体制を作っていきたいと考えています。 AWS との協業と今後の展望 AWS との協業 ──AWS との協業について、改めてお聞かせください。 木佐森氏： AWS からは技術・ビジネス・運用の各領域で専門チームによる多角的なサポートをいただいており、非常に助かっています。 技術面では、プロジェクトの立ち上げ段階からの相談対応や、実際にハンズオンで協働いただくなど、壁にぶつかったときにすぐ相談できる体制が整っています。ビジネス面では、生成 AI 活用推進プログラムを通じて、技術提供だけでなくビジネス価値創出の視点での提案を多数いただいています。運用面では、Amazon Bedrock のクオータ調整やコスト最適化など、本番運用を見据えた細やかな調整を迅速に対応していただいています。 AWS も「Customer Obsession」を掲げていますが、今回の支援はまさにこちらの課題を多面的に理解して、それぞれの側面から伴走していただいていると感じています。いつも週次でめちゃくちゃな要望を上げて対応していただいて、ありがとうございます（笑）。 ──技術基盤として Amazon Bedrock を選ばれた理由について、改めて詳しく教えていただけますか？ 木佐森氏： 率直に言うと、プロダクトのインフラが AWS 上で構築されていたからというのが大前提です。ただ、それ以外にも重要な理由があります。 まず、セキュリティとコンプライアンスですね。お客様の大切な情報を扱っているので、データが勝手に保存されず、学習にも利用されないなどの点は必須事項でした。また、PrivateLink を用いて閉域接続のオプションが取れることも重要でした。 次に、対応の速さです。例えば Anthropic が Claude Sonnet 3.5 を発表した次の瞬間には、Amazon Bedrock でも Claude Sonnet 3.5 が使えるようになっていました。これからもどんどん新しいモデルが出てくると思いますが、新しいモデルが出てきたときに私は社内で「1 日で評価して 1 週間でリリースしよう」と言っているのですが、AWS の対応の早さがこれを可能にしてくれています。 そして、キャパシティが潤沢にあることです。AWS の Amazon Bedrock を利用することで、可用性や信頼性のおけるシステムを構築することができます。 ──ありがとうございます。freee 様の挑戦的な取り組みに、チーム一丸となって関わらせていただけることは、私どもにとっても大変有意義であり、多くの学びをいただいております。引き続き全力でご支援させていただきます。 他社へのアドバイス ──これから AI 活用に取り組む、あるいはうまくいっていない企業へのアドバイスをお願いします。 木佐森氏： 「とりあえずやってみよう」というフェーズは終わったと思っています。今は本当に顧客価値やインパクトがあることをどう作るか、というフェーズです。 まとめると、3 つのポイントがあります。 第一に、経営インパクトがあるところに取り組むこと。 小さな課題で AI を活用しても、次のステップに繋がりません。経営層を巻き込んで、本当に価値があることに取り組む必要があります。 第二に、成功基準をプロジェクト初期にしっかり決めること。 精度などの品質指標と、それがどう顧客価値に繋がるかを明確にする。そして ROI を可視化する。 第三に、各フェーズでギャップを分析し、何を落として何を伸ばすかを戦略的に選ぶこと。 グレーゾーンではなく、強弱をはっきりつけた閾値にすることで、後で成功基準を修正しやすくなります。 これは決して簡単なことではありません。でも、本当に価値を出すためには、これらに真摯に取り組むしかないと思っています。 今後の展望 ──今後の展望を教えてください。 木佐森氏： まず、各プロダクトチームが自律的に AI 活用できる組織を作りたいです。今はボトムアップで様々なプロジェクトが始まっていますが、それらの質を組織全体で高めていく。成功基準という共通言語を使って、誰もがユーザー価値を届けられる組織にしていきます。 技術的には、SLM のトレーニングをさらに進化させ、エージェンティックなアプローチで各タスクを最適化していきます。最近のトレンドで言えば、もはやモデル性能よりも人間・組織のイネーブリングがボトルネックですよね。小型化・ルーティング・運用最適化で、エージェントの再現性・安定性やコスト効率に焦点が移っています。 そして何より、「AI CFO」というビジョンの実現に向けて、本当に顧客価値を生み出すAIを量産していきます。これは AI ラボだけでなく、組織全体で取り組んでいくことです。 ──本日は貴重なお話をありがとうございました。 木佐森氏： ありがとうございました。多くの企業が AI 活用で成果を出せるようになることを願っています。 左から freee 木佐森氏、AWS ソリューションアーキテクト 福本、アカウントマネージャー 服部、テクニカルアカウントマネージャー 舟橋 本ブログの執筆はソリューションアーキテクト 福本健亮、撮影はソリューションアーキテクト 伊藤威が担当しました。

本記事は米国時間 2025 年 11 月 4 日に公開された「 Stop Repeating Yourself: Why Global Steering is the AI Context Layer You’ve Been Missing 」を翻訳したものです。 あなたは、関数型の React コンポーネントを使った欲しいことを AI アシスタントに 47 回も伝えました。セミコロン付きの Prettier を使っていることを 23 回。そして、テストファイルは __tests__ ディレクトリに配置し、ソースコードと並べないことを少なくとも 15 回。 聞き覚えがありませんか？ ここで実際にかかっているコストについて考えてみましょう。これは単にイライラするだけではなく、 生産性を下げています。 新しいプロジェクトをセットアップするたびに、すでに何十回も説明してきたプロンプトを再び説明するのに 10 〜 15 分を費やしています。年間 20 のプロジェクトに取り組む開発者にとって、それは 5 時間以上の単純な繰り返し です。50 人のチーム全体では？ワークスペース間で同じ基準をコピー＆ペーストするのに 年間 250 時間 を費やしていることになります。 そして、さらに状況は悪化します。コンテキストが一貫性がないと、コードも一貫しません。あるプロジェクトではセキュリティ基準が適用されます。別のプロジェクトでは、そのファイルをペーストし忘れたためにセキュリティ基準が欠落しています。テストカバレッジは大きく変動します。コードスタイルもずれていきます。 不整合は技術的負債として蓄積されます。 AI を使ってコーディングしているなら（正直、2025 年に誰もがしているでしょうが）、この壁にぶつかっているはずです。 すべての新しいプロジェクトがゼロからスタートします。 AI はあなたの好み、チームの規約、会社の基準を覚えていません。あらゆるワークスペースに同じ指示をコピー＆ペーストするか、さらに悪いことに、毎回手動で入力し直すしかありません。 これが Kiro グローバルステアリングが解決する問題です。 Kiro グローバルステアリングは、AI コンテキストのための個人用の .bashrc のようなもので、どこにいても付いてくる、必要なときに準備ができている設定だと考えてください。好みを一度書けば、それがあなたが触れるすべてのプロジェクトの基盤になります。コピーも、忘れることも、不整合もありません。 影響は？開発者は毎月数時間を節約できます。チームは自動的に一貫性を達成します。組織は規模に応じて基準を適用します。 そして最も重要なことは、AI アシスタントが毎回、初日からあなたを理解するようになることです。 そもそもステアリングとは何か？ グローバルステアリングに入る前に、ステアリングが実際に何をするのかを明確にしましょう。 ステアリングは永続的な AI コンテキストです。 これは、AI エージェントが作業を開始する 前に 、あなたの好み、基準、決定事項について伝える一連のMarkdown ファイルです。すべての会話で同じことを説明する代わりに、ステアリングファイルに一度書けば、AI は作業を開始するリクエストを受けたときに自動的にそれを読み込みます。 現状：ワークスペースステアリング 現在、Kiro はワークスペース固有のステアリングを使用しており、以下の場所に保存されています。 &lt;project&gt;/.kiro/steering/ このアプローチは、プロジェクトごとに設定を指定する必要がある場合にうまく機能します。 しかし、問題があります。 AI に伝えることのほとんどは、プロジェクト固有ではありません。 あなたのコーディングスタイルの好みは、すべてのプロジェクトで同じです。テストの哲学はどこでも一貫しているべきです。普遍的なセキュリティ基準が必要です。なぜそれをすべてのワークスペースで繰り返す必要があるのでしょうか？ グローバルステアリングの登場：個人用 AI 設定レイヤー グローバルステアリングはあなたのホームディレクトリに存在します。 ~/.kiro/steering/ このステアリングファイルは永続的です。普遍的です。どこにでも付いてきます。 ここに置いた Markdown ファイルは、ワークスペースレベルで明示的に上書きされない限り、 すべての プロジェクトで Kiro が利用できるようになります。 グローバルステアリングに何を入れるべきか？ プロジェクトに関係なく、あなたの仕事全体で一貫しているものについて考えてください 個人的なコーディングスタイル ~/.kiro/style.md （グローバル） # style.md ## コード整形 - 常にセミコロン付きの Prettier を使用 - JS/TSは2スペースインデント、Python は 4 スペース - 複数行の配列/オブジェクトには末尾のカンマ ## React の好み - 関数コンポーネントのみ（クラスコンポーネントは使わない） - 再利用可能なロジックにはカスタムフック - コンポーネント上部で props を分割代入 ## 命名規則 - 関数と変数は camelCase - コンポーネントとクラスは PascalCase - 定数は SCREAMING_SNAKE_CASE - 簡潔さよりも説明的な名前 テストのルール ~/.kiro/testing.md （グローバル） # testing.md ## テスト基準 - ビジネスロジックには最低80%のカバレッジ - テストファイルは`__tests__/`ディレクトリに配置 - Jest + React Testing Library を使用 - 外部依存関係はモック化 - クリティカルパスには統合テスト ## テスト構造 - Arrange-Act-Assert パターン - 説明的なテスト名（it should...） - 可能な限り 1 テストにつき 1 つのアサーション セキュリティ要件 ~/.kiro/security.md （グローバル） # security.md ## セキュリティの基本 - 秘密情報は絶対にコミットしない（環境変数を使用） - すべてのユーザー入力を検証 - SQL/HTML レンダリング前にデータをサニタイズ - パラメータ化されたクエリを使用、文字列連結は禁止 - API にレート制限を実装 - HTTPS のみ、混合コンテンツは禁止 ドキュメンテーション基準 ~/.kiro/docs.md （グローバル） # docs.md ## コードドキュメンテーション - すべての公開関数に JSDoc - 複雑なロジックのみインラインコメント - セットアップ手順を含む README をすべてのプロジェクトに - OpenAPI/Swagger を使用した APIドキュメンテーション - "Keep a Changelog" のサイトに従った変更履歴 アーキテクチャ原則 ~/.kiro/architecture.md （グローバル） # architecture.md ## 設計原則 - 関心の分離 - DRYだが明確さを犠牲にしない - 継承よりコンポジション - 説明的なエラーで早期に失敗 - 単一責任の原則 ## コード構成 - 機能ベースのフォルダ構造 - 関連ファイルの近接配置 - クリーンなインポートのためのバレルエクスポート このパターンは、何を構築するかではなく、どのように作業するかを定義します。 実世界のシナリオ：個人開発者 実際にこれがどのように機能するか見てみましょう。 Jane Doe さんの場合 Jane は、React とNode を使った顧客プロジェクト、オープンソースへの貢献、個人的なサイドプロジェクトに取り組んでいるフリーランスのフルスタック開発者です。すべてのプロジェクトで異なるビジネスロジックがありますが、 彼女の基準は同じままです。 Janeのグローバルステアリング設定 Jane の ~/.kiro/steering/ フォルダ ~/.kiro/steering/ ├── style.md # コーディングスタイルの好み ├── testing.md # テストアプローチ ├── security.md # セキュリティベースライン ├── docs.md # ドキュメンテーション基準 ├── git.md # コミットメッセージ形式 └── accessibility.md # アクセシビリティ要件 主 要なファイル： ~/.kiro/git.md （グローバル） # Git 規約 ## コミットメッセージ Conventional Commits に従う： - feat: 新機能 - fix: バグ修正 - docs: ドキュメント変更 - refactor: コード再構築 - test: テストの追加/変更 形式：`type(scope): description` 例：`feat(auth): OAuth2サポートを追加` ## ブランチ戦略 - `main` - 本番環境対応 - `develop` - 統合ブランチ - `feature/xxx` - 新機能 - `fix/xxx` - バグ修正 ~/.kiro/accessibility.md （グローバル） # アクセシビリティ基準 ## 要件 - 最低限 WCAG 2.1 AA コンプライアンス - セマンティックな HTML要素 - 適切な見出し階層（h1 → h2 → h3） - すべての画像に alt 属性 - キーボードナビゲーションのサポート - フォーカスインジケーターを可視化 - 最低 4.5:1 のカラーコントラスト比 ## テスト - キーボードのみでテスト - スクリーンリーダーを使用（NVDA/JAWS） - コミット前に axe DevTools を実行 ワークスペース固有のステアリング さて、Jane は新しいクライアントプロジェクトであるEコマースプラットフォームを開発を開始します。彼女のプロジェクト固有のステアリングファイルは /.kiro/steering/ に配置されます。 &lt;project&gt;/.kiro/steering/ ├── product.md # E コマースのビジネス要件 ├── tech.md # Next.js、Stripe、PostgreSQL の選択 └── structure.md # このプロジェクトのフォルダレイアウト &lt;project&gt;/.kiro/product.md （ワークスペース） # Eコマースプラットフォーム ## コア機能 - 検索機能付き商品カタログ - 永続化されたショッピングカート - Stripe 決済統合 - 注文履歴と追跡 - メール通知 ## ユーザーロール - ゲスト：閲覧と購入 - 顧客：保存されたアドレス、注文履歴 - 管理者：商品管理、注文処理 &lt;project&gt;/.kiro/tech.md （ワークスペース） # 技術スタック ## フロントエンド - Next.js 14（App Router） - TypeScript - Tailwind CSS - 状態管理にZustand ## バックエンド - Next.js API ルート - Prisma 経由の PostgreSQL - 決済に Stripe - メールに SendGrid ## インフラストラクチャ - Vercel にデプロイ - データベースに Supabase - 画像に Amazon S3 どのように連携するか Jane が「新しい ProductCard コンポーネントを作成して」と Kiro に依頼すると以下のものを読み込みます。 Kiro が読み込むもの： グローバルステアリング （ ~/.kiro/steering/ ） style.md → 関数コンポーネント、Prettier 設定 accessibility.md → セマンティック HTML、alt 属性要件 testing.md → テストファイルの配置とカバレッジ ワークスペースステアリング （ /.kiro/steering/ ） tech.md → Next.js、TypeScript、Tailwind を使用 product.md → 商品データ構造と機能 structure.md → コンポーネントは src/components/ に配置 結果として、Kiro は、TypeScript を使用した Tailwind CSS クラスの関数型 React コンポーネント、適切なセマンティック HTML とアクセシビリティ属性、対応するテストファイルと共に正しいディレクトリに配置、Jane のコーディングスタイルに一致、すべてを自動的に生成します。 Jane が好みを設定を繰り返し指示することなく、すべてが実行されます。 チームシナリオ：組織全体の基準 では、これをスケールアップしましょう。50 人の開発者がいるチームではどうなるでしょうか？ AnyCompany の場合 AnyCompany には、8 つの開発チームがあり、混合技術スタック（React、Vue、Python、Go）にわたる 30 以上のアクティブなリポジトリを管理し、厳格なセキュリティとコンプライアンス要件を持っています。 課題： すべての開発者が会社の基準に従う必要がありますが、異なる技術を使用した異なるプロジェクトに取り組んでいます。 AnyCompany のグローバルステアリング戦略 展開アプローチ 組織は、グローバルステアリングファイルをチームに配布する方法の柔軟性を持っています。重要な制約は、Kiro が&nbsp; ~/.kiro/steering/ ディレクトリからのみグローバルステアリングファイルを読み取ることですが、ファイル自体はコピーまたはシンボリックリンクを通じてどこからでも取得できます。 バージョン管理を使用するチームの場合、AnyCompany は、セキュリティポリシー、SOC2 および GDPR コンプライアンス要件、コードレビュー基準、オンコール手順、アクセシビリティ要件、UI/UX ブランドガイドラインを含む会社全体のステアリングファイルを含む共有リポジトリを維持しています。開発者はオンボーディング中にこのリポジトリをクローンし、ファイルを ~/.kiro/steering/ に直接コピーするか、中央リポジトリが変更されたときに自動的に反映されるシンボリックリンクを作成します。シンプルなセットアップスクリプトがこのプロセスを自動化し、手動コピーなしですべての開発者が同じベースラインを取得できるようにします。 setup-kiro.sh #!/bin/bash # setup-kiro.sh echo "AnyCompany Kiro グローバルステアリングをセットアップしています..." # 会社のステアリングをクローン git clone &lt;チームのグローバルステアリングファイルのURLをここに&gt; ~/.kiro/company-steering # グローバルステアリングへシンボリックリンク（更新が自動同期） ln -s ~/.kiro/company-steering/* ~/.kiro/steering/ echo "グローバルステアリングが設定されました！" Jamf や Intune などのモバイルデバイス管理ツールを使用する企業の場合、展開は完全に自動化できます。MDM スクリプトは、内部サーバーからファイルをダウンロードし、適切な権限を設定し、必要なファイルが存在し続けることを強制することで、 ~/.kiro/steering/ に直接入力できます。または、MDM は /opt/company/kiro-steering/ のような中央の場所にファイルを展開し、 ~/.kiro/steering/ へのシンボリックリンクを作成できます。これにより、ファイルを管理された場所に保ちながら、集中更新が提供されます。このアプローチは、開発者の手動セットアップが不要になり、集中ポリシー管理、ポリシーが変更されたときの自動更新、コンプライアンスのための監査証跡を提供します。 #!/bin/bash # MDM 経由で AnyCompany Kiro グローバルステアリングを展開 USER_HOME="/Users/$USER" STEERING_DIR="$USER_HOME/.kiro/steering" COMPANY_NAME="会社名をここに" mkdir -p "$STEERING_DIR" # 内部サーバーから会社のステアリングファイルをダウンロード curl -o "$STEERING_DIR/security.md" "https://internal.$COMPANY_NAME.com/kiro/security.md" curl -o "$STEERING_DIR/compliance.md" "https://internal.$COMPANY_NAME.com/kiro/compliance.md" curl -o "$STEERING_DIR/code-review.md" "https://internal.$COMPANY_NAME.com/kiro/code-review.md" chown -R $USER "$STEERING_DIR" chmod 755 "$STEERING_DIR" echo "AnyCompany Kiro グローバルステアリングが正常に展開されました" 実際のチーム例：フロントエンドチーム AnyCompany のフロントエンドチームは独自のレイヤーを追加します。 チーム共有ステアリングリポジトリ（フロントエンド） frontend-steering/ ├── react-patterns.md # チームの React 規約 ├── component-api.md # Props パターン ├── state-management.md # Zustand と Context をいつ使うか └── performance.md # バンドルサイズ、遅延ロードルール 個人開発者：John Doe John は AnyCompany のフロントエンド開発者です。 John の完全なステアリング設定： # チーム固有および会社全体（グローバルステアリング内） ~/.kiro/steering/ ├── security.md # 会社のセキュリティ（中央の場所からシンボリックリンク） ├── compliance.md # SOC2/GDPR（中央の場所からシンボリックリンク） ├── code-review.md # PR の基準（中央の場所からシンボリックリンク） ├── react-patterns.md # フロントエンドチームの React 規約 ├── component-api.md # チームの Props パターン ├── style.md # John の個人的なスタイルの好み └── shortcuts.md # John のカスタムスニペット # プロジェクト固有（現在のワークスペース） &lt;project&gt;/.kiro/steering/ ├── product.md # この製品の要件 ├── tech.md # このプロジェクトのスタック └── structure.md # このコードベースのレイアウト John が何かを構築するよう Kiro に依頼すると、Kiro はワークスペースステアリングがグローバルステアリングに優先して、ファイルを読み取ります。ワークスペースステアリングはプロジェクト固有で、競合が存在する場合に優先されます。グローバルステアリングには、John の個人的な好み、チーム規約、会社基準が含まれ、ワークスペースの上書きが存在しない場合に使用されます。結果として、John は会社のセキュリティコンプライアンスが自動的に適用され、プロジェクト全体で共有されるフロントエンドチームの基準、彼の個人的なワークフローの好み、現在のワークスペースからのプロジェクト固有のコンテキストを取得します。これらのレイヤーはすべてシームレスに連携します。 シナリオ：複数言語を利用する開発者 別のシナリオは、複数の技術スタックで作業する場合です。React とTypeScript を使用したフロントエンド開発、Python と FastAPI を使用したバックエンドサービス、React Native で構築されたモバイルアプリケーション、Terraform を通じて管理されるインフラストラクチャ。これらのエコシステム全体で共通の問題は、それぞれが異なる規約を持っているため、コードベース全体で一貫性のない実践に陥りやすいことです。 以下に示すソリューションは、言語に適した実装で、さまざまなコーディング言語にわたって基準を指定する方法を示しています。これで、テスト基準は一貫していますが、実装は言語に応じて適切に変化します。 グローバルステアリングのソリューション： # テスト基準（すべての言語） ## カバレッジ - ビジネスロジックには最低80% - 決済/セキュリティコードには100% ## テスト構造 - Arrange-Act-Assertパターン - 説明的な名前 - テストごとに1つのアサーション ## 言語固有 ### TypeScript/JavaScript - Jest + Testing Library - `__tests__/`ディレクトリにテスト ### Python - pytest - `tests/`ディレクトリにテスト - セットアップに fixture を使用 ### Go - 標準の`testing`パッケージ - テーブル駆動テスト - `_test.go`サフィックス ~/.kiro/naming.md （グローバル） # 命名規則（すべての言語） ## 普遍的なルール - 巧妙さよりも説明的 - 完全な単語、略語は使わない（標準的なものを除く） - ブール変数：`is`、`has`、`should` 接頭辞 - 配列/リスト：複数形の名詞 - ブール名に否定形を避ける ## 言語固有 ### TypeScript/JavaScript - 変数/関数は camelCase - クラス/コンポーネントは PascalCase - 定数は SCREAMING_SNAKE ### Python - 変数/関数は snake_case - クラスは PascalCase - 定数は SCREAMING_SNAKE ### Go - エクスポートされる名前は PascalCase - エクスポートされない名前は camelCase 一般的なステアリングのガイドライン ステアリングに入れてはいけないもの API キーや秘密情報、データベース認証情報、内部 URL やエンドポイント、顧客データや PII 、独自のアルゴリズム（ステアリングファイルを共有する予定がある場合）を含めてはいけません。これは、グローバルステアリングファイルは平文の Markdown であり、多くの場合共有または同期され、デフォルトでは暗号化されていないためです。 含めても安全なもの 一般的なセキュリティプラクティス、コードパターンと好み、テストアプローチ、ドキュメンテーション基準、公開 API 設計原則、フレームワークとライブラリの選択をステアリングファイルに含めることは安全です。 始めよう：最初のグローバルステアリングファイル グローバルステアリングを試して実際に動作を見る準備はできましたか？以下は、実際に確認できる簡単な例です。 ステップ1：最初のファイルを作成する 最も頻繁に繰り返すことを選びます。ほとんどの開発者にとって、それはコーディングスタイルです： nano ~/.kiro/steering/style.md ステップ2：テストする Kiro で新しいプロジェクトを開いて、「新しいコンポーネントを作成して」と依頼します。Kiro は、あなたが言及しなくても、 ~/.kiro/steering/style.md からのスタイルの好みに従うはずです。 ステップ3：徐々に拡張する 繰り返しのパターンを発見したら、より多くのファイルを追加し、有機的に構築します。 # 来週、テスト基準を追加 nano ~/.kiro/steering/testing.md # その次の週、セキュリティベースラインを追加 nano ~/.kiro/steering/security.md まとめ これで、Kiro があなたの全体的なスタイルと好みを理解するために グローバルステアリング を使用して、より効率的に作業する方法ができました。唯一残された課題は、何時間もの時間と繰り返しの指示を節約するために、Kiro プロジェクトに適用し始めるグローバルステアリングファイルに何を書くかです。今日、最初のグローバルステアリングファイルを作成しましょう。二度と同じことを繰り返さない体験をしてみてください。 グローバルステアリングに何を入れますか？ハッシュタグ #codewithkiro でセットアップを共有 するか、 X 、 LinkedIn 、または Instagram で @kirodotdev をタグ付けし、 Bluesky で @kiro.dev をタグ付けしてください。