ここ、英国にも夏がやってきました! でも私は夏がちょっと苦手です。多くの人とは違い、外出時に「輝かしい太陽」を浴びることにそれほど熱心ではありません。とはいえ、夏は換気の良い快適な部屋でくつろぐための最高の口実になりますし、コーディングや最新の AWS リリースのキュレーションに集中して、皆様にハイライトをお届けすることができます。 また、7 月 13 日は日中 AWS Developers Podcast のエピソードを録画していたので、暑さから逃れることができました。このエピソードでは、素晴らしい Sebastien Stormaq と Tiffany Souterre からゲーム開発についてインタビューを受けました。まだご覧になっていない場合は、ぜひご視聴ください。このポッドキャストのエピソードは、AWS はもちろんお客様やコミュニティメンバーからの興味深い教訓やインサイトが満載です。リラックスした会話の中で、ストーリーや専門知識が共有されています。 さて、7 月 7 日週にリリースされた新しいサービスや製品を発見する準備はできていますか?  ハイライトをご紹介します。 AWS Builder Center AWS ビルダーとコミュニティメンバーのための新しいホームができました! AWS Builder Center は、クラウドビルダーがつながり、知識を共有し、リソースにアクセスして AWS ジャーニーを強化できる、新しい場所です。このプラットフォームにより、ユーザーはシングル Builder ID サインインを使用して、コミュニティプログラムへの参加、トレンドトピックの発見、AWS Skill Builder コースへのアクセス、技術的な課題への参加などを行うことができます。 私が個人的に最も楽しみにしている機能の 1 つが ウィッシュリスト です。要望書を作成して AWS の製品やサービスを改善する方法を直接 AWS に伝えたり、自分やチームの役に立つと思われる独創的なアイデアを共有したりできるようになりました。また、既存の要望を閲覧して賛成票を投じ、優先すべきだと思う提案をサポートすることもできます。AWS チームはこのウィッシュリストに注意を払います。関心を集めている要望は、検討される可能性があります! ニュースブログ投稿を読んで、 最もエキサイティングな機能のいくつかを簡単に確認 するか、 AWS Builder Center にアクセスし探索してみましょう。 AI AI の世界は、物事を行ったり生産性を高めたりするための新しくてエキサイティングな方法を提供することで、急速に変化し続け、私たちの世界を変え続けています。私が注目した先週のリリースを 2 つご紹介します。 AWS マネジメントコンソールの Amazon Q チャットで AWS サービスデータのクエリが可能に – Amazon Q Developer は、S3、DynamoDB、CloudWatch などの AWS サービス全体に保存されているデータに対して、AWS コンソール、Slack、Microsoft Teams、AWS コンソールモバイルアプリケーションから直接自然言語クエリを実行できるようにすることで、機能を拡張します。この機能強化により、ユーザーは会話型インターフェースからサービスデータにアクセスして分析できるようになり、アクセス制御は IAM 許可を通じて管理されるため、クラウドの管理とトラブルシューティングが合理化されます。 AI 支援トラブルシューティング用の Amazon CloudWatch サーバーと Application Signals MCP サーバー – AWS は、新しい 2 つのモデルコンテキストプロトコル (MCP) サーバーである CloudWatch MCP と Application Signals MCP をリリースしました。これにより、AI エージェントはオブザーバビリティデータを活用し、会話型インターフェイスを通じて自動トラブルシューティングを行うことができます。これらのオープンソースサーバーにより、AI アシスタントは AWS 環境全体のメトリクス、アラーム、ログ、トレース、サービスヘルスデータを分析できるようになるため、開発者が複数の AWS コンソールを手動で操作しなくても、インシデント対応と根本原因分析を合理化できます。 Oracle Database@AWS 7 月 13 日、Andy Jassy が Oracle Database@AWS を構築するための Oracle とのパートナーシップを発表したようです。Oracle Database@AWS は、AWS データセンター内の Exadata インフラストラクチャ上で Oracle データベースを直接実行し、AWS と Oracle の統一されたエクスペリエンスを提供する共同提供サービスです。先週、 Oracle Database@AWS は一般公開リリースで重要なマイルストーンに達しました 。現在、米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで利用することができ、今後さらに世界の 20 のリージョンに拡大する予定です。 さらに、 VPC Lattice は Oracle Database@AWS のサポートを追加 し、VPC とオンプレミス環境のアプリケーションと Oracle データベースネットワークとのシームレスな接続を実現しました。この統合によりネットワーク管理が簡素化され、複雑なネットワーク設定を必要とすることなく Oracle Database@AWS から Amazon S3 や Amazon Redshift などの AWS サービスに安全にアクセスできるようになります。 つまり、Oracle データベースのワークロードの移行を考えているなら、Oracle Database@AWS を検討する絶好の機会です。最小限の変更で、素晴らしい道を切り開くことができるからです。 その他のハイライト その他にも、多くの方が喜ぶと思われるリリースをいくつかご紹介します。 AWS Config が 12 種類の新しいリソースタイプのサポートを開始 – AWS Config では、BackupGateway、CloudFront、EntityResolution、Bedrock などのサービス全体で 12 種類の新しいリソースタイプのサポートを開始し、モニタリング機能が拡張されました。すべてのリソースタイプで記録を有効にしている場合、これらの追加は自動的に追跡され、AWS リソースの発見、評価、監査の能力が向上します。 Amazon SageMaker Studio が Visual Studio Code からのリモート接続のサポートを開始 – Amazon SageMaker Studio は Visual Studio Code からのリモート接続のサポートを開始しました。これにより、開発者は SageMaker のスケーラブルなコンピューティングリソースを AI 開発に活用しながら、使い慣れた VS Code セットアップを使用できるようになりました。 AWS Network Firewall: すべてのリージョンでネイティブ AWS Transit Gateway をサポート – AWS Network Firewall では、サポートされているすべてのリージョンで AWS Transit Gateway とのネイティブ統合が可能になり、VPC とオンプレミスネットワーク間の直接接続とトラフィック検査の簡素化が実現されました。この統合により、専用の VPC サブネットとルートテーブルを管理する必要がなくなるとともに、マルチ AZ の冗長性が提供され、セキュリティと信頼性が向上します。 AWS の今後のイベント AWS Summit New York – これは間違いなく視聴すべきイベントです! 定員に達したため、登録は締め切られましたが、 すべての発表とリリースをライブで視聴 できます! ネタバレするつもりはありませんが、エキサイティングな内容が多く含まれていますので、ぜひチェックしてください。 AWS Gen AI Lofts – AWS Gen AI Lofts は、生成 AI への取り組みを探求したい、または発展させたいと考えている開発者やビジネスリーダーを対象に、ハンズオンワークショップ、エキスパートによるガイダンス、ネットワーキングの機会を提供する、複数日にわたるイベントです。これらのイベントは、サンフランシスコ、ベルリン、ドバイ、ダブリン、バンガロール、マンチェスター、パリ、テルアビブなど、世界中の複数の場所で開催され、生成 AI の採用を加速させる機会を提供しています。 7 月 14 日週のニュースは以上です。 7 月 21 日週に、その他のハイライトをお知らせします。最新リリースを取り上げるので、ぜひ AWS に関する最新の知識をご覧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

2025 年 6 月 25 日、26 日の 2 日間に渡り、AWS Summit Japan 2025 が開催されました。私の所属する流通小売消費財のチームでは、 「The Future of Retail – AWS の提案するリテールの少し先の未来」 をテーマに展示を行い、e コマースサイトと実店舗を融合させ、パーソナライズされた、フリクションレスなショッピング体験を多くの方に体験いただきました。 その展示の一つとしてご紹介したのが、仮想試着、Virtual try-on です。オンラインショッピングの大きな課題の一つに、衣類やアクセサリーなどの身につけるアイテムは、実際に自分で着用してみないとイメージが湧きにくく、また自分が既に持っている洋服とのコーディネートが想像できないため、購入に踏み切れないという点があります。さらに、実店舗でも試着室に入って着替えるのが面倒と感じるお客様も少なくありません。Virtual try-on は、これらの課題を解決する技術として注目されています。実際に店舗に足を運ばなくても、また試着室で着替える手間なく、オンライン上で商品を自分の体や空間に合わせて試着・配置できる革新的な技術です。衣類や家具、アクセサリーなどを、店頭に飾ってあるデバイスや、スマートフォンの画面上でリアルに試すことができ、購入前に商品のフィット感や見た目を確認できる新しいショッピング体験を提供します。 この Virtual try-on の技術は、 Amazon Bedrock から利用できるモデルの、 Amazon Nova Canvas の Virtual try-on 機能 を使って実現することができます。 2025 年 7 月 2 日に一般公開 されたばかりの最新の機能です。Nova Canvas では、衣料や帽子、靴、アクセサリーの他にも、ソファなどの家具、商品をお部屋やお好みの背景画像に配置するケース、さらには好きな模様を T シャツなどに転送するケースなどにも活用することができます。 本ブログでは、AWS Summit での Virtual try-on 展示について、技術解説をしていきます。 Virtual try-on によるビジネス効果 小売業にとって、注目すべき調査結果があります。NRF（全米小売業協会）の推計によると、2024 年の返品額は、年間売上高の 17％ にも及び、小売全体の返品額は、140 兆円にものぼるそうです。この数字をご存知でしたか？返品率をいかに下げるかということは、売上に対して直接的な影響を与える重要な課題となっています。これは、e コマースサイトであっても、実店舗であっても共通の課題と言えます。 そこで Virtual try-on 技術の活用が一つの解決策になるのではないでしょうか。お客様が購入前に商品を仮想的に試すことで、「思っていたのと違った」「サイズが合わなかった」といった購入後のギャップを低減できる可能性があります。実際に自分の体型や顔に合わせた試着体験や、自宅の空間に家具を配置してみるなどのシミュレーションにより、より確信を持った購入決定につながるかもしれません。このような体験の提供が、返品率の改善に寄与することが期待されます。 「商品」を生成 AI で扱うことの難しさ 画像生成 AI モデルの進化により、簡単に高い品質の画像を生成できるようになりました。しかし、従来の方法では、商品画像を扱う際にいくつかの課題がありました。例えば「美しい画像は作りたいが、商品の画像が変わったら意味がない」という問題。ファッションアイテムや家具などの商品を AI で表現する場合、見た目の美しさだけでなく、実際の商品と同一であることが重要です。また「作ったはいいが、商品だけ浮かび上がって不自然になってしまった」というように、背景や人物との自然な融合が難しいという課題もありました。従来の方法では、複雑な画像の前処理や、高品質なマスクの生成、複数のワークフローによる試行錯誤が必要で、手間やコストがかかっていました。 Amazon Science では、この課題に対する 新しい画像モデルを発表 しました。その技術を皆さんにご利用いただける形で提供するのが、Nova Canvas の Virtual try-on 機能です。商品画像 1 枚と、人物や部屋などの写真を 1 枚用意して、Nova Canvas へ生成を依頼するだけで、商品の詳細な特徴を維持しながら、影、角度、照明などを自動で調整し、低コストで高品質な着せ替え画像が生成できます。 ファッション業界におけるリアルな試着 AWS Summit の展示では、等身大の筐体に表示された、大きな 3D のアバターに対して商品を仮想試着させることで、購買者が実際に着用したイメージを確認しながらショッピングを楽しめるようにしました。来場者の方々は、自分が選んだ衣類がどのように見えるかを視覚的に確認でき、試着室に入ることなく様々なスタイルを試すことができました。 また、スマホからアップロードした画像に対して、リアルタイムで着せ替えを行い、服の組み合わせを確認できるようなユースケースのデモも展示しました。お客様自身のスマートフォンで店舗に表示された QR コードを読み取り、表示された Web アプリ上で自分自身の写真を読み込むと、リアルな試着が表示される、というシーンを想定しています。これにより、お客様は商品と自分の服の組み合わせをすぐに試すことができ、よりパーソナライズされたショッピング体験が可能になります。 このような技術により、オンラインと実店舗の境界を超えた、新しい体験を提供することができるのです。リアルタイムの Virtual try-on アプリは以下のようなアーキテクチャで実現できます。 これを実現するには、Amazon Bedrock ランタイムの invokeModel API を使います。この API のリクエストとレスポンス構造、扱える画像サイズの詳細については、 Amazon Nova ユーザーガイド(英語) をご覧ください。Virtual try-on では、新しい taskType として、 "VIRTUAL_TRY_ON" を指定します。使用する画像はソース画像と参照画像の 2 枚で、Base64 文字列に変換する必要があります。AWS Summit で展示したこちらの生成例では、参照画像の正面を向いている女性が着ている黒いジャケットを、ソース画像の横を向いている女性に着せていますが、実際のコードはどうなっているでしょうか？ まずは以下のように、 virtualTryOnParams オブジェクトを使用して、推論パラメータを指定します。まずは、 maskType を選んでから、ソース画像のどの領域を差し替えて、どの領域を残すかというマスキングを指定します。 "GARMENT" という衣料品用のマスクタイプを選択し、トップスを意味する "UPPER_BODY" という garmentClass を選択しました。他にも、シャツ、ボトムス、全身、靴、など複数のタイプから選択できます。今回のケースでは、出力の様子を見ながら、 "LONG_SLEEVE_SHIRT" に変更し、調整しても良さそうです。また、高品質で出力させたかったので、 quality を “premium” として、選択しました。オプションの全リストは Amazon Nova ユーザーガイド(英語) を参照してください。 import base64 def load_image_as_base64(image_path): """画像データを準備するためのヘルパー関数""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("black_jacket.png"), "referenceImage": load_image_as_base64("model_01.png"), "maskType": "GARMENT", "garmentBasedMask": { "garmentClass": "UPPER_BODY" } }, "imageGenerationConfig": { "quality": "premium" } } 次に、Nova Canvas で生成をするのに、invokeModel API を呼び出して先ほどの推論パラメータを渡します。以下のコードをご覧ください。 import base64 import io import json import boto3 from PIL import Image # Bedrock Runtime クライアントの作成 bedrock = boto3.client(service_name="bedrock-runtime", region_name="us-east-1") # 推論ペイロードの準備 body_json = json.dumps(inference_params, indent=2) # Nova Canvas の呼び出し response = bedrock.invoke_model( body=body_json, modelId="amazon.nova-canvas-v1:0", accept="application/json", contentType="application/json" ) # レスポンスから画像を抽出 response_body_json = json.loads(response.get("body").read()) images = response_body_json.get("images", []) 着替え済みの画像が生成できました。参照画像の洋服が正面で、ソース画像が横向きであっても、Nova Canvas は自動的に角度を調整し、横向きの着用イメージとして生成します。黒いジャケットの丈の長さも、参照画像のイメージを崩さず、生成できていますね！ 家具や小物をお客様のお部屋に配置しイメージアップ お部屋の採光によって、家具の見え方も大きく変わります。店頭で見ただけでは部屋の色と花瓶の色がマッチするかイメージしづらいものです。また、イメージと違うソファだった時、返品も一苦労で、お客様体験が悪くなってしまいます。そんな時にも Virtual Try-on を活用できます。お客様自身のリビングルームや寝室の写真に、購入を検討している家具や小物を配置することで、実際の空間での見え方を事前に確認できます。 上記の例も、AWS Summit で展示した画像で、ソース画像のグレーのソファを、参照画像の茶色のソファーに置き換えたものです。このような体験を、お部屋の模様替えアプリとして、以下のアーキテクチャのように AWS サービスを組み合わせて提供することができます。お客様にお部屋の写真を提供していただき、お部屋にある家具などの類似商品を、自社の商品情報から検索して提示します。もしお客様が気に入った商品があれば、お部屋の写真に配置してシミュレーションすることが可能です。 今回のケースでは、先ほどの衣料品用の maskType 、 “GARMENT” は利用できません。そのような場合は、プロンプトでソース画像のマスク範囲を選択できる "PROMPT" や、独自のマスク画像を使用できる "IMAGE" タイプを使ってみましょう。衣料品以外の一般的な商品を簡単に差し替えたい場合は、 "PROMPT" をお勧めします。厳密に配置する範囲を指定したい場合は、 "IMAGE" がお勧めです。 今回は "PROMPT" タイプを使い、 promptBasedMask の “maskPrompt” を指定し、プロンプトとして「sofa with pillows」と指定しました。ソース画像のソファとクッションをマスクできるようにします。また、前後の差し替える商品の形が異なることを考慮して maskShape で、 "BOUNDING_BOX" を指定し、四角形のマスクを適用できるようにしました。さらに、商品の特徴をより細かく生成するため、 mergeStyle で、 "DETAILED" を選択しました。 あとは、先ほどの生成の例で示したコードを実行するだけで、お部屋に新しいソファを置いた時のイメージが生成できるはずです。このように Nova Canvas では、オプションの変更だけで、マスクの形や生成の詳細さなどを調整することができるようになっています。 import base64 def load_image_as_base64(image_path): """画像データを準備するためのヘルパー関数""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("room_image.png"), "referenceImage": load_image_as_base64("brown_sofa.png"), "maskType": "PROMPT", "promptBasedMask": { "maskPrompt": "sofa with pillows", "maskShape": "BOUNDING_BOX" }, "mergeStyle": "DETAILED" }, "imageGenerationConfig": { "quality": "premium" } } 生成された画像は、角度の異なるソファが参照画像だったにも関わらず、先ほどと同様に、角度が調整されて出力されました。さらに、商品の特徴もしっかりと反映されています。また、Nova Canvas では、光の当たり方や影も自動調整できるので、ソース画像の、窓やブラインドから漏れ出る光や影も、自然に生成されていますね！これで新しいソファがリビングにマッチするという事を、確認することができました。安心して購入することができます。 パーソナライズされた商品レコメンデーションにより更なる返品率削減を狙う AWS Summit 展示では、他にも、 Agents により EC サイトと連携してリアル店舗でレコメンデーションを行う という展示も行っていました。 自分の好みに合う商品が提示されて、さらに自分で簡単に試着できたり、お部屋に置いたイメージをつけられたら、イメージと違うという事態を避けられるかもしれません。パーソナライズされたレコメンデーションと Virtual try-on の組み合わせにより、お客様は自分に最適な商品を見つけやすくなり、購入後の満足度向上と返品率の低減が期待できます。これは小売業者にとっても、顧客満足度の向上とコスト削減の両面でメリットをもたらす可能性があります。 まとめ 今回は AWS Summit で展示した Amazon Nova Canvas の Virtual try-on について解説しました。この技術により、オンラインショッピングと実店舗体験の境界を超えた、新しい購買体験が可能になるとともに、返品率の低減にも貢献できるのではないでしょうか。衣類の試着から家具の配置まで、様々なユースケースに対応できる柔軟性と、商品の特徴を正確に反映する精度の高さが、Virtual try-on の大きな魅力です。 小売業界が直面する返品率の課題に対して、この技術が一つの解決策となることを期待しています。ぜひ皆様のビジネスでも、Virtual try-on を活用し、お客様に新しい体験を提供してみてはいかがでしょうか。 ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 AWS Summit Japan 2025 開催報告ブログ 【開催報告】AWS Summit Japan 2025 〜 流通小売消費財業界ブース 【開催報告】3D アバター とマルチ AI エージェント による新たな接客体験 著者について 加藤 菜々美 (Nanami Kato) アマゾンウェブサービスのソリューションアーキテクトです。エンタープライズの小売・消費財業界のお客様を支援しています。AI/ML や、サーバーレスの専門チームにも所属しています。お客様の業種業態に特化したビジネス課題に対して、テクノロジーを駆使した解決手段をお客様と一緒に検討・策定し、展開するご支援をしています。  

2025/7/16 更新：イベントが閉幕したため、イベント案内ブログを開催報告として更新しました。 6 月 25, 26日の 2 日間にわたり、幕張メッセにおいて AWS Summit Japan が開催され、会場では延べ 36,000人以上、オンラインも合わせると過去最高となる、延べ 69,000 人超の方の参加者を記録しました。基調講演、事例セッションをはじめとする各種セッションとともに、AWS Expo のエリアでは AWS サービス、ソリューションの最新活⽤事例や、実際に AWS を触れるワークショップなど、皆さまが様々な⾓度から AWS の可能性を体験できるコンテンツを展開しました。 その AWS Expo エリア内に今年は「インダストリー・パビリオン」のコーナーが設けられ、製造、金融、自動車、そして私たちの担当する流通小売消費財など 13 の業界別に特化したソリューションをご紹介しました。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決方法をご覧いただけるようになっており、また、業界に精通したエキスパートと具体的な活用シナリオについて、じっくりとご相談いただけるスペースも設けました。私たち流通小売消費財業界担当チームでは、このインダストリー・パビリオンにおいて、今年のテーマである「The Future of Retail」のもと、 NRF 、 リテールテック のデモをさらに進化させた展示を行い、両日ともに終日、ご来場者が途切れることなく多くのお客様に足を運んでいただきました。デモを体験いただいたお客様からいただいた多くのフィードバックから、私たちもまた新しいアイデアを考えることができました。 このブログでは、流通小売消費財業界ブースの展示内容をダイジェストでご紹介します。展示内容に使われている AWS サービスやアーキテクチャの詳細については個別の解説ブログも公開しており、本ブログの中からそれらのブログもご案内しています。 AWS 展示ブーステーマ 「The Future of Retail – AWS の提案するリテールの少し先の未来」 流通小売消費財企業は、商品開発製造から物流、多様なチャネルを横断したシームレスな購買体験の提供、進化する消費者のニーズと期待に応えるためのオペレーション最適化などを再発明 （reinvent） するための変革に直面しています。その変革において欠かすことのできない技術要素である生成 AI を中心として、3D 技術を拡張した AR/VR、デジタルツインによるシミュレーションといった技術を組み合わせることで、店舗体験を「少し先の未来」へと変えることができます。 大きなディスプレイは視認性抜群で、今回のブース展示で一番人気のデモでした！ ブース全体は次世代のアパレル店舗をイメージして設計しました。展示要素として「3D アバターによる接客」「最新の AI モデルによる仮想試着」「AI エージェントによるショッピングアシスタント」「フリクションレス・チェックアウト」など複数用意し、かつそれらを個別のデモとして配置するのではなく、カスタマージャーニーをコンセプトの中心に置いて一人のお客様が来店されてから購買に至るまでの一つのシナリオとして組み立てることで、最新技術に触れつつ現実の購買体験を実際にイメージいただける形でご紹介できたのではないかと思います。 今回の Summit にゲストとして各種イベントにご登壇の QuizKnock さんも、ブースにお立ち寄りくださり、一通りのデモをお楽しみいただきました！ ホログラフィックディスプレイのようなちょっと目を惹くデバイスもありますが、デモで使ったアプリケーションはディスプレイに依存しませんし、実装が非常に難しいなど特別な考慮点はありません。皆さまの環境でも実現していただくことが可能なものです。それぞれのアプリケーションのデザインや実装について、テーマごとに個別のブログでもご紹介していきます。AWS のサービスを組み合わせることで、皆さまのビジネスにもすばやく取り入れることができるものばかりですので、ぜひご活用ください。 ブース全体のカスタマージャーニー デジタル世界では 3D 技術の浸透によりモノの見え方やコミュニケーションが変化し、実物が手元になくても見たい角度や精度でリアルに確認できるようになってきました。店舗と e コマースや商品紹介サイトなどのデジタルを融合させる「オムニチャネル」や「OMO（Online-merge-Offline）」のトレンドに、この 3D 技術、生成 AI 技術を組み合わせることで、よりビジュアルにサービス体験の質を向上させることができます。 e コマースサイトであればサイトへのログインをトリガーにして、過去の購買履歴や好みに基づくレコメンデーションやお知らせを画面に表示することは珍しくありません。これを実店舗で同じように体験いただくために、来店するお客様（ご来場いただいた皆さまです）をリアルタイムに識別して、バックエンドでお客様情報などを収集し、3D アバターのショッピングアシスタントがレコメンデーションに繋げます。商品の試着もデジタル空間で実現します。店舗に在庫のないサイズや色などの試着、あるいは試着スペースの確保の難しいポップアップストアでの利用などのユースケースが考えられます。 商品が決まれば購入です。クレジットカードでお支払いをし、ポイントカードを提示してポイントを付与してもらう、スマートフォンを取り出してロックを解除し、QR コード決済アプリを開いて QR を見せてお支払いをする…キャッシュレスが進んだとは言え、レジでお客様が物理的に出さなくてはならないものが現金からスマートフォンに代わっただけ、とも言えます。そんなレジでの行動も、よりフリクションレスに実現できる時代です。昨年の Summit でも展示した手のひら認証デバイス、Amazon One を利用し、 Amazon Pay との連動により、手のひら一つで完了する決済を体験いただきました。手のひら認証と決済については昨年のブログ「 Amazon One Enterprise の機能とユニファイドコマースの実現 」で解説しているものと同じですので、そちらをご覧ください。 それではここから、「最新の AI モデルによる仮想試着」「AI エージェントによるショッピングアシスタント」「3D アバターによる接客」の 3 つの展示要素について見ていきましょう。なお、ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 Amazon Nova Canvas 最新モデルによる仮想試着 NRF の推計によると、2024 年の小売全体の返品額は 140 兆円にのぼり、これは年間売上高の 17% にもおよぶ規模とされています。購入者にとってもせっかく購入したのに、サイズなどが合わなくて返品をしなくてはならない…というネガティブなショッピング体験ですが、小売業者にとっても返品に関する一連のプロセス（返品を受け付け、返品された商品を検査し、返金手続きをするなど）に多くの手間がかかります。社会全体にとっても、不要な配送が発生することによる物流業や炭素排出量への負の影響があります。 特にアパレル領域での返品率の高さは e コマースにおける課題の一つで、多くの小売業者が没入型ショッピング体験への投資を増やしています。今回の仮想試着アプリケーションも、この課題に対する一つのソリューションのアイデアです。 仮想試着のデモ・アプリケーションは、Summit 閉幕直後に一般公開された、 Amazon Nova Canvas の最新機能、 ”Virtual try-on and style options（バーチャル試着とスタイルオプション）” を利用して開発しました。試着は店舗での特別な体験の一つではありますが、試着室まで何着も持っていっては試着して確認する、という時間がないときもあります。色の違いなどはぱっと画像で自分のイメージに合うのかどうかを確認できるだけでも十分なこともあります。試着の重要性を意識しつつ、それをより手軽な体験へと変えていくデモを今回開発しました。新機能により、より状況に合わせた商品の視覚化が可能になり、臨場感あふれるショッピング体験を提供することができます。選択した洋服の平面写真一枚から、モデルが自然にその洋服をまとっている様子をご覧いただきました。陰影や洋服のひだまで自然に生成されていることに、多くのお客様から驚きのコメントをいただきました。 この仮想試着アプリで使われているサービスや実現するためのアーキテクチャについては、ブログ「 【開催報告】AWS Summit Japan 展示 : Amazon Nova Canvas の Virtual try-on でリアルな商品試着と配置を実現し、返品率を削減する 」で解説しています。また Amazon Nova Canvas の新機能についてはブログ「 Amazon Nova Canvas update: Virtual try-on とスタイルオプションが一般公開 」で解説されています。東京リージョンでご利用いただけますのでぜひお試しください。 AI エージェントによるショッピングアシスタント Amazon は 2024 年、生成AIを搭載した新たな対話型ショッピングアシスタント Rufus （ルーファス）の導入を開始しました。Amazon アプリでご利用されていらっしゃる方も多いかと思います。また 2025 年に入ってからは新しい機能、 Buy for Me も導入しています。顧客は Amazon の e コマース内にいながら、他のブランドのサイト上にある商品を見つけ購入することができるようになります。これを支える技術の一つが、AI エージェントです。 Amazon Rufus 画面（出典: Amazon） 生成 AI 技術の深化と浸透は私たちの想像を超えるスピードで進んでいます。AI がより人間の意図を理解し、業務遂行を支援する、AI エージェントは今年の大きなトレンドです。ガートナーによると、2028 年までに、日常的な業務判断の少なくとも 15% が AI エージェントによって実行されるようになると予測されています。 前述したように e コマースであればログインした顧客の情報をもとにレコメンデーションをすぐに提示することができますが、実店舗のスタッフが同じ顧客体験を提供しようとするとどうでしょう。全スタッフが、お客様の好みや過去の購買履歴、付与されているキャンペーンの状態などをすべて覚えていることはとても難しいことです。今年のブースでは、AI エージェント技術を実店舗の購買シーンの裏方に組み込むことで、例えばこれまで長くお客様に対応してきたベテランスタッフのような対応を模倣できるようになっていくのではないか、そんなデモを開発しました。 この AI エージェントアプリで使われているサービスや実現するためのアーキテクチャについては、ブログ「 【開催報告】3D アバター とマルチ AI エージェント による新たな接客体験 」で解説しています。 3D アバターによる接客 Amazon では Amazon Beyond という没入型 3D テクノロジーを活用した仮想ショールームを体験いただくことができます。顧客は自宅にいながら、実店舗でのショッピングを楽しむような、デジタルツインの没入型仮想ショールームを体験することができます。日本では未展開ですが、米国 Amazon のサイトでは多くの Amazon セラーによる美しい仮想ショールムが公開されています。 Amazon のバーチャルホリデーストア では、2024/11/1–12/28 の 8 週間で 1,000 万以上のインタラクション、95 万以上のインプレッションなど、直接的なビジネス効果にもつながったことが報告されています。 Amazon Beyond デモ画面（出典: Amazon） Coresight のリサーチでは、ブランド、小売業者の 55% が今後 3 年間で没入型体験への投資を増やすと回答していることがわかっています。仮想試着、AI エージェントといった技術要素はその “見せ方” も重要です。Amazon Beyond のような「デジタル空間にいかにリアルな没入体験を再現するか」だけではなく、「リアルな空間（店舗）にいかにデジタル没入体験を統合するか」というテーマもこれからいろいろなアイデアが出てくるでしょう。 今回のブース展示ではこの点を意識し、仮想試着では、ホログラフィックディスプレイを利用することで試着モデルをより立体的に見せることができました。また AI エージェントによるレコメンデーション結果を画像に表示するだけではなく、デジタル空間の 3D アバターと連携させることで、より新鮮で魅力的な購買体験をもたらす工夫をしました。いずれのデモアプリも PC 画面上でも動かすことはできます。ですがこの見せ方の一工夫で大きく印象は異なったのではないでしょうか。 自由度高くフロントを支えるコマースバックエンド 紹介したような新たなフロントエンドのアイデアはこれからも次々と登場し、デジタル、リアル問わず小売現場で試されていくでしょう。そのフロントエンドの要求に柔軟に応えることのできるバックエンドも重要なポイントです。ここまでに紹介した 3 つのデモアプリケーションは、バックエンドとなるカートや決済といった主要なコマース機能として、一つのアプリケーションを利用して連携しています。 今回はこのコマースバックエンドとして、これまでに何度かご紹介している AWS の e コマースのサンプル実装である Retail Demo Store （こちらの ブログ で解説しています）を利用しました。Retail Demo Store では、Composable Commerce アーキテクチャが採用されており、既存のサンプル実装で用意された各マイクロサービスの API を呼び出すことで、短期間で開発することができました。 Retail Demo Store のコードは、Github aws-samples にて 公開 しています。またコンポーザブルコマースについては、2024 年の Summit セッション（[ 資料 | 動画 ]）で紹介しています。 AWS Summit JAPAN 流通小売消費財ブースにご来場いただきありがとうございました Born from Retail, Built for Retailers – AWS は、Amazon という小売業から生まれた、小売業のためのクラウドサービスです。そして、AI/ML は、Amazon において 25 年以上前から採用され磨かれてきた技術であり、お客様が Amazon.com で目にする機能の多くは AI/ML によって実現されています。AWS は、Amazon.com によって市場テストされた後、皆さまにご利用いただくために外部化された業界固有のサービスを継続的に開発しています。すべてのクラウドサービスプロバイダーが同じではありません。AWS は、小規模なスタートアップチームの俊敏性と、エンタープライズクラスの小売業リーダーの経験を独自に組み合わせています。この経験が、小売企業に大きな成長をもたらし、世界最大の小売企業が AWS 上でビジネスを展開している理由です。AWS ブースではご紹介してきたデモごとに、ユースケースに最適な生成 AI が選ばれて利用されていることもご覧いただけたと思います。 流通小売消費財業界におけるテクノロジーによるイノベーションは急速に多様化しつつあります。新しい技術を次々と取り込まなくては行けないように思われるかもしれませんが、今回のデモではそれだけでなく、AWS サービスを使えば簡単に実装、展開できる！と実感いただけるよう、これまでに皆さまの中に蓄積されてきた知識と経験があればすぐに始めていただけるアイデアを考えました。ご参加いただけなかった皆さまでも「試してみたい！」と思われた方は、すぐに AWS アカウントチームにご相談ください。 それではまた、来年の Summit でお会いしましょう！ 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開していきますのでご覧ください。 参考情報 [1] AWS ブログ ”流通小売” カテゴリー [2] AWS ブログ “消費財” カテゴリー [3] AWS 消費財・流通・小売業向けソリューション 紹介ページ [4] recap ページ、EIB ブログも紹介 このブログは、ソリューションアーキテクト 杉中 が担当しました。

AWS Summit Japan 2025 が 6 月 25 日、26 日の 2 日間、幕張メッセにて開催され、会場とオンラインを合わせて過去最高となる延べ 69,000 人超の方にご参加いただきました。Industry Pavilion 流通小売消費財ブースでは「The Future of Retail – AWS の提案するリテールの少し先の未来 ( 参考ブログ記事 )」をテーマに展示を行い、本ブログではその中のデモ、「マルチ AI エージェントと 3D アバターによる新たな接客体験」についてご紹介します。 このデモでは、小売業界の店舗接客をテクノロジーで進化させ、マルチ AI エージェントと連携した 3D アバターが顧客一人ひとりにパーソナライズされた買い物体験を提供する新しい小売の形を示しました。人手不足の解消や接客品質の均一化といった業界課題に対するソリューションとして、多くの来場者の注目を集めました。 3D アバター接客がもたらす小売業の新たな価値 流通小売消費財企業における接客スタッフは実店舗での最も重要な顧客接点です。しかし、日本の労働人口減少による深刻な人手不足や高い離職率、接客品質の均一化といった課題に直面しています。特に小売業界では、人材確保が経営課題となっており、持続可能な店舗運営のための新たなソリューションが求められています。 近年、生成 AI の技術進化とネットワークインフラの充実により、3D アバターによる接客が実用段階に入りつつあります。これによって 24 時間対応可能な接客、顧客データと連携したパーソナライズされたレコメンデーションなど、人間のスタッフだけでは実現困難だった体験が可能になります。アバターは自然な会話能力を持ち、実際に喋ることができるため、より人間らしいインタラクションを提供できます。 今回展示した 3D アバターシステムでは、Amazon One Enterprise ( 参考ブログ記事 ) で取得した認証情報を元に顧客の属性、購買履歴、カート情報のデータを分析し、最適な接客を提供する機能が実装されています。Amazon One は、手のひらと静脈の画像を ID にリンクすることで、ID を正確に認証できる非接触型 ID 認証サービスです。この技術は店舗接客だけでなく、オンラインショッピング、ホテル、医療機関、金融機関など、様々な顧客接点に応用可能です。 マルチ AI エージェントの連携がもたらす新たな顧客体験価値 流通小売消費財企業が人手不足や接客品質の均一化という課題に直面する中、複数の AI エージェントが連携するマルチ AI エージェントは効果的な解決策を提供します。顧客属性や商品データの取り扱いにに特化したエージェント、接客対応に長けたエージェントなどが状況に応じて最適な対応を行い、それぞれの専門性を活かした総合的なサービスを実現します。生成 AI を活用したエージェントは、従来のプログラミングによる細かな制御を必要とせず、ルールベースでは難しい柔軟な応答や多様な顧客ニーズへの対応も可能です。これらのエージェントは顧客の属性や購買段階を検知して柔軟に役割を切り替え、Amazon One で取得した認証情報と連携した 3D アバターを通じて、顧客一人ひとりの購買履歴や属性に基づいたパーソナライズされた接客を 24 時間提供します。さらには、各エージェントが収集したデータを共有・分析することで接客の質が継続的に向上し、来店ごとに進化する体験を可能にします。このように、マルチ AI エージェントシステムは単なる省人化ツールではなく、人間のスタッフだけでは実現困難だった柔軟性と専門性を兼ね備えた新たな顧客体験価値を創出し、実店舗からメタバースまで幅広い顧客接点における次世代の小売体験の基盤となることが期待されています。 展示内容 会場では 3D ホログラフィックディスプレイによる接客アバター(写真左)を展示し、AI エージェントと連携した少し先の未来へとつながる購買体験をお客様にご覧いただきました。お客様が Amazon One で認証を行うと、システムが顧客情報を取得し、AI エージェントが自動的に起動します。AI エージェントのプロセスについてはモニタリングされ(写真中央)、複数の AI エージェントが一貫した接客をどの様に行うのかを見ることができます。AI エージェントは取得した顧客情報をもとに、アバターへ会話内容を送信します。アバターはお客様の名前を優しく呼びかけながら、丁寧な挨拶で接客を開始します。さらに、AI エージェントが顧客の属性、購買履歴、カート情報を分析し、アバターがお客様へ最適化されたレコメンデーションを親しみやすい言葉で案内します。 図1 AWS Summit Japan 2025 流通小売消費財ブースの様子 図2 マルチ AI エージェントによる接客のプロセスをモニタリング 接客デモの全体アーキテクチャ 接客デモの構成について説明します。全体構成図は次のようになっています。 図3 接客デモの全体アーキテクチャ図 以下は構成図内の番号と対応した説明になります。 1. Amazon One の端末からユーザーの識別子を送信 お客様の来店時に Amazon One へ手をかざしていただき、Amazon One のユーザーレジストリと連携した認証を開始します。 2. 認証情報を Amazon EventBridge へ送信 認証されたユーザー ID を Amazon EventBridge へ送信し、AI エージェントを起動するイベントとします。 3. AI エージェントの起動 イベントから AWS Lambda が起動されます。Lambda ではAIエージェントを構築・実行するオープンソースの SDK「 Strands Agents SDK 」により、購買履歴等の取得、メッセージの作成、メッセージの送信を行うタスクに分解され、それぞれの処理が実行されます。 4. 仮想店舗よりデータを取得 「Retail Demo Store ( 参考ブログ記事 、および ソースコード )」と名付けられた仮想店舗よりユーザー ID を基に、ユーザー名、購買履歴、おすすめアイテムを取得します。 5. レコメンデーションメッセージの作成 識別したユーザーに応じた挨拶やレコメンデーションメッセージを、取得したデータから生成AIが作成します。 6. アバターが発話 アバターに話をさせるための API（Speak API）へメッセージを送信し、ホロフラフィックディスプレイデバイス上でアバターが発話します。発話の際の唇の動きといったアバターの細かな動きは、ホロフラフィックディスプレイ上のアプリケーションで描画をしいます。 7. おすすめアイテムをタッチパネルへ表示 手順 4 で取得したおすすめアイテムをタッチパネルへ表示し、追加購入へとつなげやすいインターフェースを提供します。 8. おすすめアイテムの商品選択 アバターによる接客で購買体験を得た流れで、選択された商品データを送信します。 9. 追加購入商品をカートへ 以上の一連の流れで、3D アバターによる接客を通じて少し先の未来へとつながる購買体験ができます。 マルチ AI エージェントのアーキテクチャ 接客デモのバックエンドで動くマルチ AI エージェントのアーキテクチャについて説明します。このアーキテクチャは接客シナリオに応じて最適な対応を実現するために設計されています。商品案内、顧客対応と異なる専門性を持つ複数の AI エージェントが連携し、AWS 上の生成 AI サービスやコンテナ技術を活用したフルマネージド環境で動作することで、拡張性と保守性に優れたシステムを実現しています。 主要な技術スタック サービス AI エージェント: Strands Agents SDK + Amazon Bedrock Claude 3.7 Sonnet メッセージング: RabbitMQ バックエンド: Node.js/TypeScript フロントエンド: React/TypeScript コンテナ実行環境: AWS Fargate (Amazon ECS) エージェント部分の処理を独立させるため、メッセージキューを使用して疎結合なアーキテクチャを採用しています。限られた期間での実装とデプロイを実現するため、ローカル開発環境では Docker Compose を使用し、AWS へのデプロイには AWS Copilot CLI を活用しました。この組み合わせにより、開発からプロダクション環境まで一貫したコンテナベースの運用を実現しています。 図4 マルチ AI エージェントによる接客体験デモ アーキテクチャ図 マルチ AI エージェントの構成 AI エージェントは3つのエージェントで構成され、それぞの接客を行うためのそれぞれの役割を担っています。 メインエージェント: 全体の接客フローを統括し、サブのエージェントへ役割分担と連携を実現 ECサイトエージェント: サブエージェントとして、メインエージェントから指示を受ける 顧客情報やおすすめ商品の取得などECサイト操作の専門性を発揮 顧客属性に基づくパーソナライズド情報を提供し、接客の質を向上 アバターシステムエージェント: サブエージェントとして、メインエージェントから指示を受ける 自然な言語生成によりアバターの会話を実現 対話型のタッチポイントを通じて、顧客とのエンゲージメントを高める メインエージェント エージェント定義 メインエージェントは Strands Agents SDK を通して、サブエージェントの振る舞いとなる役割を自然言語で指定し、利用できるツールの説明を記述し、サブエージェントがツールを適切に使えるようにしています: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[query_ec_agent, query_avatar_agent], system_prompt=""" あなたはマルチAIエージェントシステムのメインエージェントです。 重要なルール: 1. 自分でデータを生成・推測することは絶対に禁止されています 2. 全ての操作は専用ツールを通じて行う必要があります 3. ユーザ情報やレコメンド情報が必要な場合は必ず query_ec_agent ツールを使用 4. アバター関連の操作は必ず query_avatar_agent ツールを使用 利用可能なツール: - query_ec_agent: ECサイトのユーザ情報取得、レコメンド取得、カートID取得、カート内容取得、カート操作 - query_avatar_agent: アバターの挨拶生成、セリフ送信 必ずツールを使用してタスクを完了してください。 """, callback_handler=_callback_handler ) また、プロンプトにより一連の接客フローを指定しています: ユーザID: {user_id}必須タスク（順番に実行）:タスク1: ユーザ名取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} の名前を取得してください" タスク2: ユーザに挨拶 - query_avatar_agent ツールを呼び出してください - タスク1で取得したユーザ名を使用してください タスク3: カート内容取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} のカート内容を取得してください" タスク4: カート内容コメント - query_avatar_agent ツールを呼び出してください - タスク3で取得したカートの内容を使用してください タスク5: レコメンド取得 - query_ec_agent ツールを呼び出してください - リクエスト内容: "ユーザID {user_id} のレコメンド商品リストを取得してください" 各タスクで必ずツールを使用してから次のタスクに進んでください。 ツールを使用せずに推測や仮定で回答することは絶対に避けてください。 すべてのタスクを完了したら、作業の概要報告などは避けてすぐに終了してください。 このプロンプト設計により、メインエージェントは他の専門エージェントを適切な順序で呼び出し、一貫した接客フローを実現します。 EC サイトエージェント エージェント定義 ECサイトエージェントはメインエージェントから指示により役割を定義され、複数のツールを持つ専門エージェントとして実装されています: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[get_user_info, get_recommendations, get_cart_id, get_cart], system_prompt=""" あなたはECサイト操作エージェントです。 ユーザ情報の取得、レコメンド商品の取得、カートへの商品追加などの ECサイト関連の操作を担当します。なお通貨は米ドル (USD) です。 """, callback_handler=_callback_handler ) EC サイトの操作 Strands Agents SDK の @tool アノテーションを使用することで、Python 関数を簡単にエージェントのツールとして定義できます: @tool def get_user_info(user_id: str) -> dict: url = f"{_api_base_url}/users/id/{user_id}" try: return json.dumps(get_api(url, _api_region)) except Exception as e: logger.error(f"Error getting user info: {e}") return {"error": str(e), "user_id": user_id} @tool def get_cart(cart_id: str) -> str: url = f"{_api_base_url}/carts/{cart_id}" try: return json.dumps(get_api(url, _api_region), ensure_ascii=False) except Exception as e: logger.error(f"Error getting cart: {e}") return json.dumps({"error": str(e), "cart_id": cart_id, "items": []}) get_api という関数は、後述する Retail Demo Store に対する API アクセスを行うラッパー関数です。API のホストには Amazon API Gateway が利用されており、ラッパー関数内で SigV4 署名を行っています。 Retail Demo Store について 本デモでは Retail Demo Store と呼ばれる、AWS のサービスを利用したモダンなアーキテクチャにより構成された e コマース のリファレンス実装をバックエンドの EC サイトとして活用しています。実際のECサイトと同様のAPIを提供しており、デモ開発に最適なプラットフォームです。 Agent as Tools 重要な点として、ECサイトエージェント自体も @tool アノテーションを付与した関数内で定義することで、メインエージェントからツールとして呼び出される設計になっています。これにより、エージェント間の階層的な協調動作を実現しています。 アバターエージェント エージェント定義 アバターエージェントはメインエージェントから指示により、挨拶文の生成とアバターシステムへの挨拶文送信を担当します: agent = Agent( model=os.getenv('AGENT_MODEL_ID'), tools=[invoke_avatar_lambda], system_prompt=""" あなたはアバターシステム操作エージェントです。 依頼に応じてアバターが話すセリフを生成し、アバター操作用Lambdaを呼び出す役割を担当します。 セリフを生成したら、セリフ文を提示してからLambdaを呼び出してください。 セリフは2種類あります。 1. ユーザへの挨拶 2. カート内容へのコメント ユーザへの挨拶は以下のルールに従って生成してください。 - ユーザ名を含むこと - 「こんにちは、[ユーザ名]さま、（ひとこと）」など、簡潔であること - アラビア数字や漢字は使わないこと - ひらがなとカタカナのみ利用していること カート内容へのコメントは、以下のルールに従って生成してください。 - カート内の商品について触れること、ただし商品名を正確に復唱する必要はなく、すべての商品について述べる必要はない - 50文字程度の長さとすること - アラビア数字や漢字は使わないこと - ひらがなとカタカナのみ利用していること 以下のツールを使用できます: 1. invoke_avatar_lambda: 生成した挨拶文をアバターシステムに送信する """, callback_handler=_callback_handler ) ※ 本デモでは、アバターによる発音の都合上、文字種の指定も行っています。 アバターシステムとの連携は AWS Lambda を通じて行われ、以下のようなツールで実装されています: @tool def invoke_avatar_lambda(greeting: str) -> dict: try: lambda_client = boto3.client( 'lambda', region_name=os.getenv('PROTO_SPEAK_LAMBDA_REGION') ) payload = json.dumps({"text": greeting}) response = lambda_client.invoke( ...後略 この実装により、AI が生成した自然な挨拶文がリアルタイムでアバターに反映され、お客様に対してパーソナライズされた接客体験を提供できます。 なお、ブースの技術解説コーナーで利用していたデモ解説などの資料は、こちらの リンクからダウンロード いただくことが可能です。 まとめ 流通小売消費財企業は、商品開発製造から物流、多様なチャネルを横断したシームレスな購買体験の提供、進化する消費者のニーズと期待に応えるためのオペレーション最適化などを再発明 （reinvent） するための変革に直面しています。AWS Summit 2025 で展示された 3D アバターと マルチ AI エージェントの技術は、その変革において欠かすことのできない技術要素である生成 AI を中心に店舗体験を「少し先の未来」へと変えることができます。Amazon One による認証と AI エージェントを組み合わせ、顧客データを活用した高度なパーソナライゼーションと自然な会話による接客体験を実現しています。この技術は今後、小売業界だけでなく様々な顧客接点を持つ業界へと広がり、人間のスタッフ、生成 AI エージェント、3D アバターが共存する新しい接客の形として、顧客体験の向上と業務効率化の両立に貢献していくことが期待されます。 本記事著者およびデモの開発は、ソリューションアーキテクト 古山と小森谷が担当しました。

このブログは 2022 年 9 月 7 日に Arun Chandapillai、 Shak Kathir によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 データレイクの構築とスケーリングにおいて、増え続けるデータセットを効率的に管理・保持するには、費用対効果の高いデータストレージが不可欠です。適切なストレージアーキテクチャを選択することで、お客様は迅速に検証して AWS に移行することができます。 Amazon S3 Intelligent-Tiering は、データレイクワークフローのすべての段階で、お客様がデータアクセスパターンが変化したときに、パフォーマンスへの影響やオペレーションオーバーヘッドなしに、ストレージコストを自動的に最適化できるストレージクラスです。 このブログでは、開発者とクラウド運用マネージャーが S3 Intelligent-Tiering を使用してストレージコストを最適化する方法について説明します。まず、 S3 Intelligent-Tiering アクセス階層を紹介することから始めます。次に、個々のバケットから始めて、S3 Intelligent-Tiering にオブジェクトを直接アップロードするなど、複数のユースケースに焦点を当てます。続いて、S3 ライフサイクルポリシーを使用して、既存のオブジェクトを S3 Standard または S3 Standard IA から S3 Intelligent-Tiering に移行する方法についても説明します。 後ほど、多数のバケットに対して S3 Intelligent-Tiering ライフサイクルポリシーを大規模に有効化する方法について説明します。ここでは、既存バケットと新規バケットの両方において、アクセスパターンに基づいて S3 Intelligent-Tiering アクセス階層間でオブジェクトを移行する 2 つのシナリオについて説明します。これらのユースケースにより、開発者とクラウド運用マネージャーは、個々のバケットまたは AWS アカウント内の複数のバケットにまたがる大規模な S3 Intelligent-Tiering ストレージクラス設定を管理し、データアクセスパターンの変化に応じてストレージコストを自動的に最適化できるようになります。 S3 Intelligent-Tiering アクセス階層 S3 Intelligent-Tiering は、オブジェクトを次の 3 つのアクセス階層に自動的に保存します： 頻繁にアクセスされるデータ用に最適化された、 高頻度アクセス階層 アクセス頻度の低いデータ用に最適化された、低コストの 低頻度アクセス層 ほとんどアクセスされないデータ用に最適化された、非常に低コストの アーカイブインスタントアクセス階層 即時取得を必要としないストレージコストをさらに節約するには、オプションの アーカイブアクセス階層 と ディープアーカイブアクセス階層 を有効にできます。有効化すると、90 日間（90 ～ 730 日で指定可能）アクセスされなかったオブジェクトはアーカイブアクセス層に、180 日後（180 ～ 730 日で指定可能）にはディープアーカイブアクセス階層に移動します。 S3 Intelligent-Tiering ではデータ取り出し料金はかかりません。お客様は、 監視と自動化のためのオブジェクトごとの少額の月額料金 で S3 Intelligent-Tiering を実装できます。また、自動階層化の対象となる最小オブジェクトサイズは 128 KB です。Amazon S3 Intelligent-Tiering は、128 KB 未満のオブジェクトの最小ストレージ期間と、監視と自動化のための月額料金をなくすことで、ストレージコストをさらに最適化します。 高頻度アクセス階層（自動） ：作成された、または S3 Intelligent-Tiering に移行されたオブジェクトのライフサイクルが開始されるデフォルトのアクセス階層です。 低頻度アクセス層 （自動） ：オブジェクトが 30 日間連続してアクセスされない場合、そのオブジェクトは低頻度アクセス層に移動します。 アーカイブインスタントアクセス階層（自動） ：オブジェクトが 90 日間連続でアクセスされない場合、そのオブジェクトはアーカイブインスタントアクセス階層に移動します。 アーカイブアクセス層 （オプション） ：非同期的にアクセスできるデータに対してアーカイブアクセス層を有効にできます。有効化後にアーカイブアクセス層は、少なくとも 90 日間連続してアクセスされなかったオブジェクトを自動的にアーカイブします。アーカイブの最終アクセス時間は最大 730 日まで設定できます。このアクセス階層の標準取り出し時間は 3 ～ 5 時間です。オブジェクトへのより高速なアクセスが必要な場合は、 迅速取り出し が選択肢となります。 ディープアーカイブアクセス層 （オプション） ：非同期的にアクセスできるデータに対してディープアーカイブアクセス層を有効にできます。有効化後にディープアーカイブアクセス階層は、180 日間以上連続してアクセスされなかったオブジェクトを自動的にアーカイブします。アーカイブの最終アクセス時間は最大 730 日まで設定できます。このアクセス階層のオブジェクトの標準取得は 12 時間以内です。 ソリューションの概要（個々の S3 バケット） このセクションでは、以下の手順を説明します： S3 Intelligent-Tiering ストレージクラスへオブジェクトを直接アップロードする方法 S3 ライフサイクルポリシーを使用して、既存のオブジェクトを S3 Standard または S3 Standard-IA から S3 Intelligent-Tiering に移行する方法 この手順を実行するには、以下の前提条件が必要です： AWS アカウント Amazon S3 バケットの作成 / 変更権限 を持つ AWS IAM ユーザー / ロール AWS CLI version 2 1. オブジェクトを直接 S3 Intelligent-Tiering にアップロードする オブジェクトを直接 S3 Intelligent-Tiering ストレージクラスにアップロードするには、ストレージクラスを S3 Intelligent-Tiering として指定する必要があります。これを実行するには、以下の AWS CLI コマンドを使用します。 aws s3api put-object --bucket <bucket_name> --key dir-1/my_images.tar --body my_images.tar --storage-class INTELLIGENT_TIERING PUT API 操作を使用してオブジェクトを S3 Intelligent-Tiering ストレージクラスにアップロードするには、 x-amz-storage-class リクエストヘッダーでストレージクラスを指定する必要があります。 2. 既存のオブジェクトを S3 Intelligent-Tiering に移行する アクセスパターンに基づいて、オブジェクトは以下のように自動的にあるアクセス階層から別の階層に移動されます。 オブジェクトが S3 Intelligent-Tiering に配置されると、最初は高頻度アクセス階層に保存されます。 30 日間連続でアクセスがない場合：オブジェクトは低頻度アクセス階層に移動されます。 90 日間連続でアクセスがない場合：オブジェクトはアーカイブインスタントアクセス階層に移動されます。 S3 ライフサイクルルール は、 Amazon S3 がオブジェクトのグループに適用するアクションを定義する一連のルールです。以下の手順では、オブジェクトを S3 Standard クラスから S3 Intelligent-tiering に自動的に移行する方法を説明します。 Step 1: 以下のライフサイクルルールは、オブジェクト作成日に基づいてすべてのオブジェクトを S3 Intelligent-Tiering クラスに移行します。以下のように intelligent-tier.json ファイルを作成します。 { "Rules": [ { "ID": "Intelligent_Tier_lifecycle", "Prefix": "", "Status": "Enabled", "Transitions": [ { "Days": 0, "StorageClass": "INTELLIGENT_TIERING" } ] } ] } Step 2: 以下のコマンドを実行して、バケットに新しいライフサイクルルールを作成します。 aws s3api put-bucket-lifecycle-configuration --bucket <bucket_name> --lifecycle-configuration file://intelligent-tier.json 以下のコマンドを実行して、バケットに設定されたライフサイクルルールを確認/検証します。 aws s3api get-bucket-lifecycle-configuration --bucket <bucket_name> アーカイブアクセス階層へのオプトイン設定 即時取得を必要としないストレージコストをさらに節約するには、このセクションの手順に従って、個々のバケットでオプションである非同期のアーカイブアクセス階層およびディープアーカイブアクセス階層をアクティブ化できます。 90 日間（90 ～ 730 日で指定可能）連続でアクセスがない場合：オブジェクトはアーカイブアクセス階層に移動されます。 180 日間（180 ～ 730 日で指定可能）連続でアクセスがない場合：オブジェクトはディープアーカイブアクセス階層に移動されます。 Step 1: 以下の S3 Intelligent-Tiering のアーカイブ設定は、長期間ほとんどアクセスされないオブジェクト向けに最適化されたアーカイブアクセス階層とディープアーカイブアクセス階層にオブジェクトへ移動します。設定ルールをバケット内のすべてのオブジェクトに適用するか、フィルターを定義して範囲を制限するかを選択できます。フィルターを定義するための 2 つのオプションは、オブジェクトプレフィックスとオブジェクトタグです。以下のスニペットに示すように archive-tier.json を作成します： { "Id":"Archive_Tier", "Status":"Enabled", "Tierings":[ { "Days":90, "AccessTier":"ARCHIVE_ACCESS" }, { "Days":180, "AccessTier":"DEEP_ARCHIVE_ACCESS" } ] } Step 2(optional): 以下のコマンドを実行して、 S3 Intelligent-Tiering アーカイブ設定を作成します。 aws s3api put-bucket-intelligent-tiering-configuration --bucket <bucket_name> --id Archive_Tier --intelligent-tiering-configuration file://archive-tier.json 以下のコマンドを実行して、バケットの S3 Intelligent-Tiering アーカイブ設定を確認 / 検証します。 aws s3api get-bucket-intelligent-tiering-configuration --bucket <bucket_name> --id Archive_Tier Step 3 (optional): 以下の S3 ライフサイクル設定は、それぞれ 1 つのアクションを持つ 2 つのルールを指定しています。 移行アクションは、オブジェクト作成日にすべてのオブジェクトを S3 Intelligent-Tiering ストレージクラスに移行するように Amazon S3 に要求します。 有効期限アクションは、“ logs /” プレフィックスを持つすべてのオブジェクトを作成から 365 日後に削除するように Amazon S3 に要求します。 オブジェクト有効期限ルールを使用して定期的なオブジェクト削除をスケジュールすることで、削除対象のオブジェクトを特定して Amazon S3 に削除リクエストを送信するプロセスを構築する必要がなくなります。 オブジェクトがライフサイクルポリシーに基づいて有効期限に達すると、 Amazon S3 はそれを削除キューに入れ、非同期で削除します。 以下のように intelligent-tier_logs_expire.json を作成します。 { "Rules":[ { "ID":"Intelligent_Tier_lifecycle", "Filter":{ "Prefix":"" }, "Status":"Enabled", "Transitions":[ { "Days":0, "StorageClass":"INTELLIGENT_TIERING" } ] }, { "ID":"Logs_Expire_lifecycle", "Filter":{ "Prefix":"logs/" }, "Status":"Enabled", "Expiration":{ "Days":365 } } ] } Step 4 (optional): 以下のコマンドを実行して、バケットのライフサイクル設定を作成します。 aws s3api put-bucket-lifecycle-configuration --bucket <bucket_name> --lifecycle-configuration file://intelligent-tier_logs_expire.json 以下のコマンドを実行して、バケットに設定されたライフサイクル設定情報を確認 / 検証します。 aws s3api get-bucket-lifecycle-configuration --bucket <bucket_name> HeadObject HEAD アクションは、オブジェクト自体を返さずにオブジェクトからメタデータを取得します。この 操作 により、オブジェクトの ‘ ArchiveStatus ’ 属性と他のいくつかの属性が取得されます。 以下のコマンドを実行して、オブジェクトのメタデータを取得します。 aws s3api head-object --bucket <bucket_name> --key <object_key> ソリューション概要（大規模な S3 バケット） このソリューションでは、以下の対象に対して S3 ライフサイクル設定を作成し、非同期のアーカイブアクセス階層にオプトインする方法について説明します： AWS アカウントの既存の S3 バケット AWS アカウントの新しく作成された S3 バケット 1. 既存の S3 バケット 既存の S3 バケットについては、 Python スクリプトを使用してリソースタグフィルターに基づいて特定の S3 バケットの S3 ライフサイクル 設定を更新できます。 これには、以下の前提条件が必要です： AWS アカウント 適切な権限を持つ AWS IAM ユーザーまたはロール AWS CLI version 2 AWS リソースタグ付け 概略すると、このプロセスは以下のようになります。これらのステップを実行するために AWS CLI を設定します。 以下は使用される S3 ライフサイクル設定とアーカイブポリシーです。 S3 lifecycle configuration lifecycle_config_settings_it = { 'Rules': [ {'ID': 'S3 Intelligent Tier Transition Rule', 'Filter': {'Prefix': ''}, 'Status': 'Enabled', 'Transitions': [ {'Days': 0, 'StorageClass': 'INTELLIGENT_TIERING'} ]} ]} archive_policy = { 'Id': 'Archive_Tier', 'Status': 'Enabled', 'Tierings': [ { 'Days': 90, 'AccessTier': 'ARCHIVE_ACCESS' }, { 'Days': 180, 'AccessTier': 'DEEP_ARCHIVE_ACCESS' } ] バケットの特定のリソースタグに基づいて S3 バケットに設定が適用されます。 タグベースのフィルタリング bucket_tag_key = "storage.class" bucket_tag_value = "s3.it" 注：フィルターキーと値は、企業のタグ付け命名規則に基づいて変更できます。 Python スクリプトを実行する AWS IAM ユーザー/ロールに、 ListBuckets , GetBucketTagging , PutBucketLifecycleConfiguration , および PutBucketIntelligentTieringConfiguration の適切な権限があることを確認してください。 Python スクリプトは こちら からダウンロードできます。 2. 新しい S3 バケット 新しい S3 バケットについては、バケット作成イベント通知によってトリガーされる S3 ライフサイクル設定をバケットに適用する Lambda 関数の作成して対応します。 概略すると、手順は以下のようになります： Standard からS3 Intelligent-Tiering にストレージクラスを移行する Lambda 関数を作成する Lambda 関数には、 S3 バケットの特定のリソースタグに基づいて移行を適用するロジックを含める Lambda 関数をトリガーする S3 バケット作成イベントをキャプチャする EventBridge ルール を作成する AWS Lambda 関数の作成 ここでは、バケットタグに基づいて S3 バケットのストレージクラスを移行する Lambda 関数を作成します。この Lambda 関数は、ユースケース 1 で説明したものと同じ S3 バケットタグフィルターとライフサイクル設定を使用します。 Amazon EventBridge ルールを設定して、この Lambda 関数をトリガーすることができます。トリガーされると、 Lambda 関数ハンドラーは EventBridge（CloudWatch）イベントを処理し、S3 バケット名を抽出します。リソース タグフィルター に一致するバケットのみが S3 ライフサイクル 設定で更新されます。 AWS Lambda 関数実行ロール 最小権限の原則のベストプラクティスに従い、 Lambda 関数実行ロールには、 S3 バケットに新しいライフサイクル設定を適用するための最小限の権限が必要です。最低限、 PutBucketLifecycleConfiguration , PutBucketIntelligentTieringConfiguration , および GetBucketTagging の権限が必要です。サーバーレス Lambda 関数の ログ 記記録を有効にすることをお勧めします。AWS 管理ロール AWSLambdaBasicExecutionRole は、ログを CloudWatch にアップロードする権限を付与します。 Lambda 関数は こちら からダウンロードできます。 Amazon EventBridge ルールの作成 以下は、 AWS 管理コンソールを使用して Lambda 関数を呼び出す EventBridge ルール を作成する方法です。 CloudWatch コンソールを開き、左側のナビゲーションペインから イベント → ルール を選択し、 ルールの作成 ボタンをクリックします イベントソース で、 イベントパターン が選択されていることを確認します サービス名ドロップダウンで S3 を選択し、 イベントタイプ で バケットレベル操作 を選択します 特定の操作 を選択し、 バケットの作成 を選択します ターゲット で、先ほど作成した AWS Lambda 関数の名前を選択します ルールの 名前 と（オプション）説明を入力します。ルールをすぐにアクティブにするには、 有効化 ボックスを選択したままにします 最後に、 ルールの作成 を選択します クリーンアップ AWS アカウントでの継続的な料金発生を避けるために、このガイドに従って作成した AWS Lambda リソースを削除してください。 結論 このブログ記事では、特定の状況に応じてストレージコストを最適化するために、個々の S3 バケットまたは複数の S3 バケット全体で S3 Intelligent-Tiering を使用するさまざまな方法について説明しました。データアクセスパターンが変化した場合に、パフォーマンスへの影響や運用上のオーバーヘッドなしに S3 ストレージコストを最適化する方法についてガイダンスを提供しました。あらゆる規模の企業が、より広範なクラウドコスト最適化戦略の一環として、このプロアクティブなアプローチをストレージコスト削減に採用できます。 S3 Intelligent-Tiering は AWS 管理コンソール 、 AWS Command Line Interface(CLI) 、および AWS SDK を通じて有効にできます。お客様は、 監視と自動化のための少額の月額オブジェクト単位の料金 で S3 Intelligent-Tiering を実装できます。詳細については、 AWS Well-Architected Framework 、 ストレージのアーキテクチャベストプラクティス 、および コスト最適化のアーキテクチャベストプラクティス を参照してください。ストレージコスト最適化戦略についてさらに支援が必要な場合は、 AWS サポート と AWS アカウントチームにお問い合わせください。 TAGS: Amazon EventBridge , Amazon S3 Event Notifications , Amazon S3 Intelligent-Tiering , Amazon S3 Lifecycle , Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage , AWS Command Line Interface (AWS CLI) , AWS Lambda Arun Chandapillai Arun Chandapillai は、ダイバーシティ ＆ インクルージョンの推進者であるシニアクラウドアーキテクトです。彼は、ビジネスファーストのクラウド導入戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャを上手に構築、デプロイ、管理できるよう支援することに情熱を注いでいます。 Shak Kathir Shak Kathirvel は AWS ProServe のシニアクラウドアプリケーションアーキテクトです。顧客との共同作業やアプリケーションの近代化と最適化の取り組みの支援、エンタープライズクラウド管理とガバナンス戦略の指導、ワークロードのクラウドへの移行を楽しんでいます。エンタープライズアーキテクチャ、サーバーレステクノロジー、AWS のコストと使用状況の最適化に情熱を注いでいます。彼はやりがいのある仕事と、刺激的な顧客や同僚と仕事をする機会があることからとても気に入っています。

本記事は アメリカ太平洋時間の2025 年 7 月 14 日に公開された “ Announcing the Code with Kiro Hackathon ” を翻訳したものです。翻訳はデベロッパーアドボケイトの山口能迪が担当しました。 賞金総額 10 万ドル、AI 開発の未来を拓きましょう Code with Kiro Hackathon が始まります。 Kiro は、あなたのコードを理解する AI の開発環境へのシームレスな統合により、あなたの開発ワークフローを変革します。 Kiro の AI IDE をさまざまに試しながら、賞金 10 万ドルを懸けて、スペック主導型開発がどのようなものか見てみませんか。 Kiro は、コンテキストを考慮したインラインコーディング、マルチモーダルチャット、スペック駆動型開発、また、あらゆる種類のタスクを自動化できるインテリジェントエージェントフックなどのAI機能を通じて、あなたのアイデアを拡張します。 Kiro のユニークな AI 機能 についてはウェブサイトで確認してください。 （ほとんど）なんでも開発できます あなたの創造的な自由を最大限に引き出すためには、プロジェクトの主な要件は、単純に Kiro を使用して動作するアプリを構築することです。 あなたの創造力を引き出すために 4 つのカテゴリーを想定していますが、これらに縛られないでください。 生産性とワークフローツール ：あなたが夢見た CLI や、あなたがほしいすべての機能を実装したタスクトラッカーアプリケーションを構築したり、チームのプロセスを合理化するスクラムボードを設計しましょう。 ゲーム＆エンターテインメント ：ローグライクからリアルタイム マルチプレイヤー ゲームまで、ぜひ作ってみてください。 教育用アプリ ：インタラクティブなコーディング チュートリアル、アルゴリズム ビジュアライザー、あるいは学習を楽しく魅力的にするものなら何でも。 その他 ：他にはないユニークなアイデアがありますか。あなたの自由に作れます。私たちが驚くようなものを作ってみてください。 スキルレベルに関係なく参加を歓迎します もしあなたが想像しているものがあるのなら、Kiroはそれを実現する手助けができます。 1 人でもチーム（3 名まで参加可能）でも、どのようなスキルレベルの開発者にも参加をおすすめします。 これがあなたにふさわしいハッカソンかどうか、まだ不明瞭ですか？ このハッカソンでは、成功するアプリケーションを構築するためのあらゆる種類のスキルが必要です。 開発者 スタートアップの創業者または起業家 デザイナー 学生（高校生から大学院生まで） 基本的にすべてのビルダー 現代における AI 主導のソフトウェアエンジニアリングの素晴らしさは、さまざまなレベルの技術スキルにアクセスできることです。 Kiro は、あなたのもっとも得意とするスキルを引き出し、あなたのプロジェクトをアイデアから本番レベルのコードまで引き上げることを可能にするために、あなたに協力してくれます。 しかし、私たちの言葉を鵜呑みにしないでください。 ぜひご自身で試してみてください！そしてあわよくば賞金も獲得してしまいましょう！ 他になにかお伝えすることがありますか？…では AI がかつてないほど私たちを取り巻く世界を形成しつつあることは周知の事実です。 多くのツールが AI によるコーディングの高速化を謳っていますですが、今こそそれ以上のものを求める時です。 Kiro はエージェント型 IDE であり、あなたの開発パートナーとして、単にコードを速く書くだけでなく、あなたの仕事の次元を上げるために作られています。 Kiro を使って AI 開発 の最前線に参加し、強力なソリューションを世界にもたらしながら、あなたのスキルを成長させましょう。 参加する理由がもっと必要ですか。 コミュニティに参加して、AI を使った開発の未来を形作ろうとしている仲間の開発者や業界の専門家と新しいつながりを作りましょう。 私たちは、 kiro.dev/docs にある私たちの技術文書やチュートリアルに加えて、毎週オフィスアワーとDiscordを用意してあなたをサポートします。 ハッカソンの審査員には、 Tim Ruscica 、 Aishwarya Srinivasan 、 Angie Jones 、 Santiago Valdarrama 、 Jeff Barr のような専門家を含む、コミュニティでもっとも優秀な人たちがいます。 審査員は、潜在的な価値、Kiro をうまく活用した実装、そしてアイデアの質に基づいてプロジェクトを評価します。 また、インフルエンサー審査員賞、最優秀 Kiro 活用賞、その他各優秀賞などの多彩な賞を用意しています。 主な日程と提出書類の詳細 ハッカソンは 2025 年 7 月 14 日にスタートし、提出期限は 2025 年 8 月 25 日午後 12 時（訳注: 本文日時はすべてアメリカ太平洋標準時）です。 入賞者は 2025 年 10 月 1 日に Kiro のソーシャル チャンネルの X 、 Bluesky 、 LinkedIn 、 Instagram で発表されます。 応募作品には、なぜそれが価値あるソリューションなのか、そしてそれを構築するためにKiroがどのように使用されたのかを審査員に説明するデモビデオ（最大 3 分）、オープンソースコードを含む公開 GitHub リポジトリ、および詳細なプロジェクトドキュメントを含める必要があります。 完全なルールと応募の詳細については、 kiro.devpost.com をご覧ください。 Kiroはプレビュー期間中は無料で利用でき、複数のオペレーティング システムとプログラミング言語をサポートしているため、開発者は単なる概念実証ではなく、実際のアプリケーションを構築できます。 ハッカソンを始めるには次の手順で進めてください。 Code with Kiro ハッカソンへの登録 Kiro をダウンロード し、設定する あなたのプロジェクトを構築するために使用できる機能について 学ぶ あなたの創造性に火をつけて、開発を始めましょう！ アイデアからプロダクションに移行する準備はできていますか？ AI を活用した開発の可能性を探るエキサイティングな旅に参加しませんか。 AI を活用した開発革命の最前線に立ち、ソフトウェア創造の未来を形作るチャンスです。 今すぐ kiro.devpost.com に登録し、何か素晴らしいものを作り始めましょう。 あなたが何を考え出すか、私たちは待ちきれません！ まだ質問がありますか。 公式ハッカソンルール を読んでみてください。 チュートリアル を確認してください。 Kiro Discordコミュニティ をブックマークしましょう。 X 、 LinkedIn 、 Instagram では @kirodotdev を、 Bluesky では @kiro.dev をタグ付けし、ハッシュタグ #codewithkiro を使って進捗状況を共有しましょう。 有償プランの購入の必要はありません。 18 歳以上のみ参加できます。参加資格に制限があります。 利用規約 を参照してください。

AWS ジャパンの 広域事業統括本部では、中堅・中小企業のお客様のデジタルトランスフォーメーション（DX）、クラウドや生成 AI の利活用などを支援しています。過去 2 年間、 AWS では7月の「中小企業魅力発信月間」に合わせて、最新のテクノロジーがどのように中堅・中小企業の成長に貢献するのか、どういった成功事例があるのかなどを定期的にご紹介してきました。 2023年は、鶴見酒造株式会社様に、 AWSクラウドを活用した温度センシングシステム「もろみ日誌クラウド」を導入し、10分ごとに温度データを自動収集しリアルタイムで可視化することで、24時間どこからでも温度管理が可能になったことに加え、酒質の向上、泊まり込み勤務の解消、若手への技術継承という3つの課題を解決した事例をご紹介頂きました。2024年は、 AWSの生成AIサービスを活用した事例として、株式会社やさしい手様に、介護関連文書の処理自動化により、個別化されたサービス提供と高い説明責任を実現した事例と、株式会社ネイティブキャンプ様には、英会話レッスンの音声データを自動要約して改善点を提案する機能を構築した事例をご紹介いただきました。 本ブログでは、中堅・中堅企業のお客様のビジネス成長や新たな価値創出に向けた、2025年度の新たなAWSの取り組み、生成 AI の事例について解説いたします。 経済産業省は2025年5月に公開したレポート 「レガシーシステムモダン化委員会総括レポート」 において、依然として日本の多くの企業組織におけるDXの進捗はスピード感に欠け、進化するデジタル技術の導入や連携の遅れは諸外国との隔たりを一層拡大させ日本の産業競争力が低下の一途を辿ると問題提起しています。日本の産業構造に目を移すと、中堅・中小企業が全企業数の99.7%、売上高に占める割合が78%*となっており、少子高齢化や人口減少、労働者不足などの課題を抱える日本の競争力を向上させるためには、中堅・中小企業が成長の源であり、そのDX推進は急務であると考えます。 AWSジャパンでは、中堅・中小企業のお客様が、変化を続ける顧客や社会のニーズを捉えて対応していくために、 クラウドを中核としたデジタル技術やAI技術を駆使して新たな価値を創出するご支援をしていくことが必要だと考えています。そしてこのような支援を、企業全体の99％以上を占める中堅・中小企業に対して継続的に行うことが、日本全体の成長に寄与することに繋がると確信しております。その具体的な支援策としては、以下の4つを注力領域として全国のAWSパートナーと共に全国の中堅・中小企業のお客様のDX、クラウド民主化に向けた取り組みを一層強化しています。 生成AIをはじめとした最新技術の導入と業務プロセスのデジタル化 レガシーシステムからの脱却ーマイグレーション＆モダナイゼーション デジタル人材の育成　 地域創生に向けた取り組み ＊2024年発行 帝国データバンク「『中堅企業』の実態分析」ならびに東京商工リサーチ「TSRレポート」参照 １．生成AI をはじめとした最新技術の導入と業務プロセスのデジタル化 AI 活用の最新動向と職場におけるスキル習得のニーズを把握するため AWS は2024年、Access Partnership 社に委託して 「加速する AI 活用、AI スキルに関するアジア太平洋地域の雇用主および労働者の意識調査」 を実施したところ 、2028年までに78%以上の組織がAIを導入する見込みであることが明らかとなりました。なかでも生成AIは急速に普及が進んでおり、2024年は 生成AIを活用したサービスがローンチする など実用化が進み、そして今年2025年は、生成AIを活用して ビジネス価値を創出するフェーズへと移行 が進んでいるとAWSでは考えています。 企業が生成AIに期待する効果や創出するビジネス価値は多岐にわたりますが、中堅・中小企業の多くのお客様においては以下の４つが代表的なものであると考えます。 生産性 ：大幅な生産性の向上 洞察 ：あらゆる社内情報から洞察を抽出しより迅速で的確な意思決定を支援 新体験 ：顧客および従業員との新しい革新的なコミュニケーションを確立 創造性 ：会話、物語、画像、映像、音楽などの新しいコンテンツやアイデアを創出 AWSの中堅・中小企業のお客様も、AWSの生成AIサービス Amazon Bedrock などを活用して、こうした新たなビジネス価値創出に向けた取り組みを進められてます。下記に活用事例の一部をご紹介いたします。 株式会社ジュビロ アカデミーのコーチングに生成 AI を活用、トレーニング指導案を作成 サッカー J リーグの「ジュビロ磐田」を運営する静岡県の企業、ジュビロは、クラブ運営やデータベース構築でのデジタル活用を積極的に推進してきました。2024年6月からは、アカデミーにおけるコーチング知識や経験の継承という課題解決のため、Amazon Bedrock を活用した生成 AI 導入の実証実験を開始。コーチが練習テーマなどを入力すると、過去の指導案データを学習した生成 AI が最適な練習メニューを提案し、コーチをアシストするツールを構築。将来的には選手個々のデータを活用したパーソナライズされた練習メニューの考案や、部活動支援など地域課題解決につながる展開も模索しています。 タキヒヨー株式会社 アパレルの社内業務に生成AIを活用 ～月450時間の効率化とデザイン創造性の進化を実現～ アパレル事業を中核とする繊維専門商社のタキヒヨーは、コロナ禍で顕在化した業務の属人化課題に対し、Amazon BedrockとGenerative AI Use Cases JPを活用した生成AI導入を実施。使いやすさとセキュリティを重視したシステム構築により、4部門で月450時間の工数削減を達成し、デザイン部門では1点あたり2時間の効率化を実現。さらにアパレルデザインの検討業務などクリエイティブな領域にも生成AIを展開し、デザイナーの創造性向上にも貢献しています。 アライズイノベーション株式会社 生成AIでローコード開発を効率化、次世代OCRの開発に成功 ～顧客の金融機関の帳票処理工数を80%削減見込み～ AIとローコード開発に強みを持つアライズイノベーションは、AI-OCRサービス「AIRead」の進化を目指し、トップダウンでClaude 3.5 Sonnetの評価から開発着手までわずか2週間でプロジェクトを始動。Amazon SageMakerとAmazon Bedrockを組み込んだ「生成AI-OCR」の開発により、OCRの精度と汎用性を飛躍的に向上。導入事例では、金融機関の年間数百万枚に及ぶ決算書のデータ化作業で、業務工数80％削減を実現見込みです。 株式会社やさしい手 非エンジニアが実現！ 3000 人規模の介護×生成 AI 革命 日本全国で在宅介護サービスを提供するやさしい手では、長年の課題であった現場スタッフの介護記録業務の負荷の軽減策として Amazon Bedrock を導入。IT 知識ゼロの 6 名のチームが、2 週間で生成 AI アプリを開発し、3 ヶ月で 3000 人の介護現場に展開。 その結果、記録業務時間が 83 %削減、計画書作成時間も 75 %削減。更に、介護スタッフが利用者と直接関わる時間が 25 %増加し、要介護者の小さな変化も見逃さない、一人ひとりに合わせた質の高いケアが可能になりました。これにより、高齢者が住み慣れた自宅や地域で安心して暮らし続ける「Aging in Place」の実現に貢献しています。 岩崎電気株式会社 生成 AI が実現する防災・減災 DX ～カメラ映像を用いた道路状況の無人監視～ 道路照明に強みを持つ創業80年の照明器具メーカーである岩崎電気では、昨今異常気象や震災による自然災害が頻発しており、防災・減災への危機意識が高まっていることを受け、同社では、自社の道路用照明とカメラを組み合わせたシステムに Amazon Bedrock を適用した道路状況の自動監視ソリューションを開発しました。従来はセンサーで冠水検知をする必要がありましたが、カメラ映像を生成 AI で解析することで、大幅なコスト削減と運用負荷の低減を実現しました。 さらにAWSジャパンでは、日本における生成AI技術の実用化を支援するため、2024年7月から「 生成AI実用化推進プログラム」 の提供を開始し、200社を超える企業・団体の生成AI実用化支援を行っていますが、その半数近くが中堅・中小企業のお客様です。今後も継続してAWSパートナー様と連携してAWSは本プログラムを通して、お客様の生成AIによる価値創造を技術面、資金面、またナレッジを提供しご支援しています。 出所：AWSジャパン ２．レガシーシステムからの脱却ーマイグレーション＆モダナイゼーション ～今こそクラウドへ　マイグレーション＆モダナイゼーション 日本では生成AIなどの最先端のデジタル技術を活用したくても、既存のレガシーシステムが足枷となり、連携や組み込みがスムーズに進められないといったレガシーシステムを取り巻く問題も発生しています。AWSの中堅・中小企業のお客様からも、基幹システムのクラウド移行を進めたけれど、仕様書が残っていない、システムがブラックボックス化してしまっている、といったお声をお聞きしています。クラウドは、必要なリソースを必要な分だけ柔軟かつ容易に調達が可能、調達まで数か月を要する物理サーバーと異なり、数クリックでサーバーを立ち上げられるなどすぐに始められ、また、高いセキュリティで安心安全にデータにアクセスすることができます。こうしたクラウドの優位性から、生成AIを「とりあえず使ってみる」ためにも、生成AIを最大化するためにも、クラウドは最適といえ、社内にAIエンジニアがいないという企業においても生成AIを身近なものにしています。生成AI隆盛の今だからこそ、クラウドへの移行、モダナイゼーションに取り組みを加速させる必要があると考えます。 今年5月にAWSは、レガシーからAWSへの移行とモダナイゼーションを支援する AWS Transform の提供を開始しました。初のエージェント型AIサービスであるAWS Transformは、AIが複雑な依存関係を理解し、暗黙知化したビジネスロジックを可視化、従来は年単位だったプロジェクトを月単位まで短縮することを可能にしました。 また、クラウド移行においても、お客様がその状況に応じて最適な移行を実現できるようにAWSパートナーと連携してご支援しています。クラウド移行に関して豊富な知識と高い経験値を有し、 「AWS移行とマイグレーションコンピテンシーパートナー」 として認定されたパートナー各社が、複雑な移行プロジェクトの実現に活躍しています。 出所：AWSジャパン ３．デジタル人材育成 総務省が2023年に公開した「国内外における最新の情報通信技術の研究開発及びデジタル活用の動向に関する調査研究」によると、日本は米国や中国、ドイツなどの諸外国と比べてシステム開発における内製化割合が低いことが明らかとなっています。デジタル人材が不足し、デジタルを十分に活用できていない中堅・中小企業のお客様がITの内製化を推進できるようにAWSは、デジタル人材の育成支援にも注力しています。その一環として、初学者から経験豊富な技術者まで、AWSのクラウド・AI関する知識やスキルを習得できるデジタルトレーニング AWS Skill Builder を提供しています。 今年7月にAWSは、生成 AI を搭載した仮想顧客とのチャットを通じて実践的な AWS スキルを身につけられる新しい学習プラットフォーム AWS SimuLearn の提供を開始しました。AWS SimuLearn では、 日本語の生成 AI に関するラボとクラウドの基礎 (Cloud Practitioner) に関するラボが無料で提供 されており、クラウドや生成AIを一から学び、使い始めたいという方にも最適です。 ４．地域創生 超高齢化・人口減少・労働力不足など日本の様々な社会課題を解決するために、デジタル技術を活用した課題解決が求められています。日本全国の中堅・中小企業のお客様におけるクラウドの民主化、生成 AI の利活用促進は、こうした社会課題の解決を後押しし、日本政府が目指す地域創生を加速させると考えます。 日本全国のAWSのお客様がクラウドの民主化を実現するために、AWSパートナーのネットワークとの連携は必要不可欠です。多くのパートナーの中でも特に、中堅・中小企業のお客様のニーズ、課題に対するソリューションとサービスを定められた水準以上のレベルで提供する能力と実績を持つとして、AWSが認定した 中堅・中小企業（SMB）向けコンピテンシーパートナー のクラスメソッド、サーバーワークス、GMOとの連携も強化して、全国のお客様の課題発見から寄り添い、その解決をご支援していきます。 また、こうした日本社会の課題を解決し、地域創生を加速するためには全国のデジタル人材の育成も急務です。AWSは地域で活躍できるデジタル、AI人材を育成に向けて今年6月25日、独立行政法人国立高等専門学校機構 旭川工業高等専門学校（旭川高専）および富山高等専門学校（富山高専）2校 と 包括連携協定 を締結しました。 さらに全国のデジタル人材育成支援を強化するためAWSジャパンは、 デジタル社会実現ツアー2025 を、2025年8月18日～28日、全国7地域（新潟県、愛知県、大阪府、東京都、宮城県、福岡県、広島県）で開催を予定しています。今年で4回目（4年目）となる本ツアーでは、地域の学生や若手社会人を対象に地域課題をAIで解決を目指す「 地域創生・社会課題解決 AI プログラミングコンテスト 2025 」 を実施します。地域が抱える多様な社会課題に対し、クラウドや AI などのデジタル技術を活用した解決策を地域社会と共に考え、実装していくこうした取り組みを通じて、持続可能な地域創生を実現するとともに、全国の中堅・中小企業のお客様の成長、新たな価値創出を後押しします。 最後に。「日本のために、社会のために」 AWS広域事業統括本部は、日本経済の根幹であり日本を支える日本全国の中堅・中小企業のお客様の成長とイノベーションの実現を支援するビジネスパートナーを目指し、本ブログでご紹介した施策を含めた取り組みを強化していきます。 「日本のために、社会のために」、今後も 継続してAWS は、クラウド・生成 AI による経営課題の解決をAWS パートナーと一緒にご支援していきます アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 広域事業統括本部 統括本部長　原田 洋次

アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの石倉です。2025 年 6 月 25 、26 日に AWS Summit Japan が開催され、2 日間で 160 以上のセッションと 270 以上のブース展示が行われました。その中には、高い信頼性要件に対し工夫を凝らしながら耐障害性の高いワークロードを構築したお客様事例セッションもありました。また、AWS セッションや AWS Village のブース展示においても、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2025 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 事例セッションより ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略～勘定系移行までの道のり～ ソニー銀行 様 ソニー銀行様では、ビジネスアジリティの飛躍的な向上を目指し、長期的な視点でクラウドシフト戦略を推進されており、2025 年 5 月 新勘定系システムをクラウドネイティブなアーキテクチャにて AWS 稼働をスタートしました。稼働にあたり、大阪リージョンを活用したマルチリージョン構成にすることにより、基幹システムで求められる高い可用性を実現した事をご説明いただきました。移行時のサポートしてAWS エンタープライズサポート、AWS Countdown Premium ティアを活用頂き万全の体制にて移行を完遂した事もご説明頂きました。 国内金融業界初： AWS 上での勘定系システム移行の成功と次世代バンキングの展望 SBI Security Solutions様 SBI Security Solutions 様は AWS 上で稼働する銀行勘定系システム「次世代バンキングシステム」のサービスを開始し、2024 年に福島銀行で本番稼働を開始し、2025 年には島根銀行を 2 行目として稼働を予定しています。マルチ AZ・マルチリージョンで構成されており、AZ 障害は 1 分で自動回復、リージョン障害は 1 時間で切り替えを可能にしています。レジリエンシーを高めるためには CI/CD パイプラインの実装やリージョン切り替えのワークフロー整備といった「定型運用作業の自動化」と、オブザーバビリティを活用した「人の判断の迅速化」が重要と述べています。またこれには AWS からサポートを迅速化させるサービスである AWS Incident Detection and Response (IDR) の採用も大きな要因となっています。今後は AI Ops などを活用し、非定型作業の自動化も推進していくそうです。 AWS セッションより 公共機関におけるクラウドレジリエンス～障害からより早く回復するシステムの作り方～ AWS シニアパートナーソリューションアーキテクト 讃岐 和広より、レジリエンスライフサイクルフレームワークを活用したシステムの回復力強化について解説するセッションをお届けしました。デジタル社会の実現に向け変化を続ける環境において、従来の「障害を防ぐ」アプローチには限界があり、「障害が起きてもすぐ回復する」レジリエンスなアプローチへの意識変革が重要であることを強調しました。レジリエンスライフサイクルフレームワークの 5 つのステージ（目標設定、設計と実装、評価とテスト、運用、対応と学習）について、まず目標設定では SLO や RTO / RPO の目標値を定めることが重要であり、例えば地方公共団体情報システム非機能要件の標準【第1.1版】では RTO 12 時間以内、RPO 1 営業日前、サービス稼働率 99.5 % といった具体的な目標値が定められていることを紹介しました。また、ミッションクリティカルな重要業務では「静的安定性」の確保が重要であり、障害時でもシステムが変更を加えることなく通常通り動作し続けるよう、あらかじめ十分なキャパシティを確保しておくことを解説しました。 サービス停止を防ぐ AWS 活用術: コンテナワークロードにおける高可用性設計の実践 AWS シニアソリューションアーキテクト 堀内 保大より、コンテナワークロードにおける高可用性設計を解説するセッションをお届けしました。「Everything fails, all the time」という Werner Vogels の言葉の通り、障害は必ず発生することを前提として、いかに高速に復旧させるかが重要なポイントです。セッションでは、高可用性設計の 2 つの柱として「耐障害性」と「障害分離」を詳しく解説しました。耐障害性では、マルチ AZ 冗長化による配置戦略や、ヘルスチェック・サーキットブレーカー・リトライといった通信の信頼性確保について説明。障害分離では、トラフィックを AZ 内に閉じる AZ 独立性の設計と、Amazon Application Recovery Controller を活用した AZ 退避の仕組みを紹介しました。また、完全な停止ではなく散発的・部分的な劣化が発生するグレー障害についても触れ、外形監視による SLO 監視と静的安定性を考慮した AZ 退避の重要性を説明しています。Amazon EKS や Amazon ECS での実装例も交えながら、具体的な障害シナリオを通じてアーキテクチャがどのように機能するのかを確認できる、コンテナ環境における実践的な高可用性設計パターンを学べる内容となっています。 AWS におけるグレー障害の検出と対策 AWS ソリューションアーキテクト 安藤 麻衣より、見落としがちなグレー障害の検出と対策について解説するセッションをお届けしました。グレー障害は完全なシステム停止ではないものの、一部のユーザーにのみサービス品質の低下をもたらす検出困難な障害で、システム全体では正常に見えるが顧客側では問題が発生している状態を指します。従来のヘルスチェックでは検知できない小さなエラーに対し、Amazon CloudWatch の Contributor Insights を活用することで、特定のユーザーやインスタンスで発生するレイテンシー問題などを特定する方法を紹介しました。さらに複合アラームを使って AZ レベルでの障害を精密に検知する具体例を紹介しています。対応策では Amazon Application Recovery Controller のゾーンシフト機能を使った Availability Zone の切り離しを中心に解説。問題のあるAZを一時的に切り離すことでシステム全体の健全性を保つ手法です。この実現にはAZ独立性（AZI）の考慮が重要で、異なる AZ 間の不要な通信を防ぎ AZ 内でリソース利用を完結させる設計についても言及しています。最後に AWS Fault Injection Service を使った事前の障害訓練や、組織全体でレジリエンス文化を醸成することの重要性を強調しました。 設計から運用まで~ AWS サポートを徹底活用して重要システムを安定稼働させよう AWS シニアクラウドサポートエンジニア 古野俊広より、重要システムの安定運用とレジリエンス向上を支援する AWS サポートサービスについて解説するセッションをお届けしました。システム障害による損失の大きさと、耐障害性の高いアーキテクチャ構築やマイグレーション時の課題を背景に、AWS が提供する包括的なサポートサービスを紹介しました。AWS Countdown Premium（AWS CDP）では、設計段階からローンチ後まで専門チームが継続的にサポートを提供します。アーキテクチャレビュー、設定項目の確認、負荷試験時のメトリクス分析など、サポートエンジニアが実際のリソース設定を直接チェックし、移行フェーズでの迅速な情報共有とエスカレーション支援も行います。AWS Incident Detection and Response（AWS IDR）では、24 時間 365 日体制でシステム監視を行い、障害発生時には 5 分以内に専門エンジニアが対応を開始します。IDR は SBI セキュリティ・ソリューションズ様にご利用いただき、日本語サポートにより迅速な対処を実現できています。AWS Support Automation Workflows（AWS SAW）は、よくある技術的問題に対する自動化されたトラブルシューティングを提供し、障害復旧時間の短縮を実現します。 アーキテクチャ道場 2025 – 実践編！ AWS ソリューションアーキテクトがモダナイゼーションとレジリエンスの 2 つのお題に対して、実際のお客様事例をもとにアーキテクチャを紹介します。その中で SBI Security Solutions 様における銀行の勘定系システム全体のレジリエンスを考えるお題があり、勘定系システムに求められる高い信頼性の基準を満たしつつ、業界特有の通信方式（セッション維持や固定 IP 接続など）という制約にどう対応するかが解説されています。実装方針としては、ノードや AZ 障害にはマルチ AZ のアクティブ/アクティブ構成で、リージョン障害にはアクティブ/パッシブの構成を採用されています。また、中継センターが外部との接続方式を緩衝するよう設置することで、弾力性のあるクラウドの特性を活かしてシステム全体のレジリエンスを高められていました。切り替え時にはヒューマンインザループを採用しつつ、判断を行うフローを自動化したり、判断を待たずにできる準備を並行で走らせるなどの工夫があり、業界問わず参考になる例と思います。 AWS ブース展示より ブース：レジリエンスブース＆大阪リージョンブース レジリエンス・大阪リージョンブース資料は こちら からダウンロード頂けます。 レジリエンスブース レジリエンス関連プラクティス ( コントロールプレーン / データプレーンの特性、静的安定性等) 、関連の AWS サービス、AZ 障害に備えるための手法、ディザスタリカバリ (DR) に対応する為の戦略をご案内しました。AZ 障害に対応するための手法として Amazon Aplication Recovery Controller のデモを実施しました。ディザスタリカバリ (DR) 戦略については、RPO / RTO に応じた戦略とそれに紐づく具体的なアーキテクチャ説明を中心にご案内いたしました。 大阪リージョン・たこ焼きブース 大阪といえば、たこ焼き。たこ焼きがいつでも注文できるデモアプリを展示いたしました。デモアプリは、東京 ＆ 大阪マルチリージョンによるアクティブアクティブ構成で、災害耐性の向上、RTO / RPO の短縮、そして低レイテンシーを実現しています。AWS Fault Injection Service による障害注入実験、Amazon CloudWatch Application Signals、Amazon Managed Grafana によるマルチリージョンオブザーバビリティにより、リージョン障害がおきてもアプリの正常稼働を確認できるデモを実施しました。 大阪リージョン・データセンターブース 大阪リージョンの有用性をテーマに、データセンターの災害対策についてご紹介しました。大阪リージョンデータセンターの災害対策として、津波による浸水被害を受けない設計、「免震構造」により、震度 ６ 弱の揺れでは影響を受けない設計であることをご案内しました。免震構造の模型展示も行いました。 金融ブース：進化する金融 × レジリエンス（ゼロダウンタイムを実現するフェイルオーバー/金融システムを守るサイバーレジリエンス） 金融ブースの概要資料は こちら からダウンロード頂けます。 こちらのブースでは、金融システムのミッションクリティカル要件とサイバーレジリエンス強化について、マルチリージョン構成による可用性確保や回復力評価など、具体的な実装方法をデモで紹介していました。勘定系システムを例に、Aurora DSQL をマルチリージョンで構成し、障害発生時においてもサービスのゼロダウンタイムを実現する構成や、マイクロサービスを採用した顧客接点ようモバイルアプリを例にした障害状況に応じた挙動の振る舞いを意識したアーキテクチャパターンをご紹介しました。サイバーレジリエンス強化については、クラウドとオンプレ環境両方におけるバックアップデータ保護やフォレンジック環境の構築、および復旧フローについて具体的な実装例とともにご紹介しました。主に、AWS Backup や Amazon S3 を用いたVault Lock の機能でバックアップデータを保護しつつ、Logically air-gapped vault でリージョンや AWS アカウントを跨いだデータ隔離を行うことで攻撃者からのバックアップデータ侵害を防ぐアーキテクチャとしています。 Chaos Kitty で楽しくインシデント対応の基本を学ぼう！ Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層の Web アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応の体験が行うことができます。今までの Chaos Kitty は IoT 機器での操作を前提としており、実際に皆様の環境でお試しいただくにはハードルが高いところがありました。今回はアーキテクチャを一部改修し、AWS CDK を活用した IaC 化を行うことで IoT 機器なしでも簡単にデプロイ可能となりました。さらに Amazon CloudWatch Application Signals を使った標準的なダッシュボードを使い、サービスとして重要な指標を取得して可視化できるようにしています。また、生成 AI を利用した障害分析効率化を図る AIOps を体感いただくために、AWS Japan の Solutions Architect が開発した障害分析ソリューション Failure Analysis Assistant (FA2) との連携も可能になっています。 まとめ 障害へのアプローチとして、障害は起こる事を前提し、早く復旧するためのアプローチ（レジリエンス、回復力）を検討頂く事が重要です。今回の Summit では、このプラクティスを踏襲、実践するためのヒントが多く確認できる内容となっておりました。特に勘定系といったミッションクリティカルなシステムの AWS 稼働事例、復旧を短縮するための AWS サービス、サポートサービスの活用が確認できる内容になっておりました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド移行を検討頂いている皆様に少しでも参考になれば幸いです。 著者 石倉 徹 パートナー技術統括本部 シニアパートナーソリューションアーキテクト 安藤 麻衣 ストラテジックインダストリー技術本部通信第三ソリューション部 ソリューションアーキテクト 河角 修 フィナンシャルサービスインダストリー技術本部 銀行ソリューション部 ソリューションアーキテクト

はじめに 企業は、開発者の生産性向上、アプリケーションの高速開発、レガシーコードの保守負担軽減を支援する方法を模索しています。Amazon Q Developer は、企業がカスタマイズされた SAP 環境に関連する技術的負債を解消し、新機能をより迅速に提供できるように支援する生成 AI サービスです。このブログでは、Amazon Q Developer が SAP 開発者の生産性向上とイノベーションの加速にどのように役立つかについて説明します。 SAP は、世界中の数千の企業のビジネスを支えるミッションクリティカルな基幹業務システムです。長年にわたり、多くの企業は自社固有の要件を満たすために SAP をカスタマイズしてきました。これらのカスタマイゼーションを実現するために、SAP の ABAP プログラミング言語を利用して、必要なビジネス機能のプログラムを追加開発してきました。 ABAP プログラムは企業が SAP をビジネスに適応させるために作成されましたが、これにより SAP 環境の運用やアップグレードの難易度が高くなります。また、数十年前に書かれた複雑な ABAP コードについて、ドキュメントが不足していたり、元の開発者が退職していたりするという事はよくあることです。現在、これらの企業がクラウドへの移行、S/4HANA へのアップグレード、SAP 推奨するクリーンコア戦略（コア SAP アプリケーションで変更をせず要件を満たすために SAP の機能拡張する）の採用を検討する中で、レガシーコードは多くの課題を抱えています。 Amazon Q Developer による SAP モダナイゼーションの簡素化 Amazon Q Developer は、企業がレガシーコードの課題を克服し、より高速で低コストな SAP アップグレードを可能にします。これにより、規制遵守、セキュリティパッチ適用、新しいソフトウェア機能の採用が簡素化されます。Amazon Q Developer は、レガシー ABAP コードの機能仕様と技術仕様の両方のドキュメントが生成でき、貴重な時間を節約できます。 Amazon Q Developer は、従来の SAP ABAP、SAP ABAP RESTful Application Programming Model (RAP)、SAP Cloud Application Programming Model (CAP) を含む、SAP プログラミングフレームワーク全体で使用可能です。Amazon Q Developer は VS Code、Eclipse、その他複数の IDE 拡張で利用できます。Amazon Q developer の Eclipse バージョンは、近い将来、すべての ABAP オブジェクトタイプに対して完全に機能するようになる予定です。 他のプログラミング言語 (Java、Python) で Amazon Q Developer を使用しているお客様から、開発者の生産性が最大 40％ 向上し、さまざまな開発タスクが最大80％加速されたとの報告がありました。ABAP 開発に関して、既に SAP のお客様 (およびパートナー様) から同様のベネフィットを得られているという声を聞き始めています。 Zappos.com のエンタープライズシステム担当シニアディレクターである Saul Dave 氏は次のように述べています。 Amazon Q Developer will be a game-changer for our ABAP development and application support teams. この後、Amazon Q Developer が SAP 開発者の生産性をどのように向上させるかを示す4つのユースケースについて詳しく説明します。 ABAP コードの生成 BTP および Fiori アプリケーションの生成 テストケースの生成 レガシー ABAP コードのドキュメント生成 ユースケース #1：ABAP コードの生成 Amazon Q Developer は、自然言語プロンプトを解釈してコードを作成できます。この例では、注文番号と顧客番号でフィルタリングする機能を含む、オープン中の販売注文を表示する ABAP コードが生成されます。開発者は、Amazon Q Developer に次のプロンプトを入力してコードを作成しました。 “Generate an ABAP report named zhprp_sales_order_overview, showing list of open sales orders, filter either by order number or customer number (sold-to-party). Include: Sales order number, Sold-to-party, Order Creation date, Line Item number, Material Number, Ordered quantity, Confirmed Quantity. Order the records by sales order number. Display the output in ALV format.” 以下の短いビデオは、プロンプトの入力と生成されたコードの出力を示しています。Amazon Q Developer チャットウィンドウは画面の右側にあります。生成されたコードが SAP 内で正常に実行されることも確認できました。 ユースケース #2：Fiori および BTP のコード生成 Amazon Q Developer を使用して完全な Fiori アプリケーションを開発することを説明します。この例では、単一のプロンプトを使用して、CDS ビュー、OData インターフェース、UI を含むフロントエンドとバックエンドコンポーネントを作成するプロセスのステップを進めます。使用されるプロンプトは次のとおりです。 “Provide me with all the things I need to do to create a fiori application for the sales order(create, update, delete) and then you can handhold me while I am creating each step. In addition to that I want to have a class to insert dummy data and test classes for my cds view for TDD. Amazon Q Developer は階層化されたアプローチに従い、必要なテーブル構造が作成されるデータベース層から始まります。その後、 CDS 層に移り、基盤となるデータベーステーブルを抽象化しながらデータのビジネスに使うためのビューを提供するルート CDS ビューが定義されます。ビジネス層では、Amazon Q Developer はビヘイビア実装とテストクラスを含む CDS ビューのビヘイビア定義の生成を支援します。サービス層では、OData V2 公開のためのサービス定義とバインディングの作成が含まれ、Fiori アプリケーションとバックエンドとのコミュニケーションが可能になります。UI 層では、Amazon Q Developer はメタデータ拡張を使用した UI アノテーションを支援します。その後、開発の次のロードマップが提案され、manifest.json、サービスバインディング、アクティベーション、パブリッシングの作成が含まれます。最終ステップでは、カスタムコントローラーアクションと HTML UI5 コンポーネントが作成され、完全な Fiori アプリケーションを生成します。 ユースケース #3：単体テストケースの生成 Amazon Q Developer は、ドキュメント不足や元の開発者が居なくなった場合に、既存のコードのテストクラスを作成することを支援します。ユーザーは単純にコードを Q のインラインチャットに貼り付けるだけで、包括的なテストシナリオが自動的に分析・生成されます。生成されたコードの構文エラーは、Q のインラインチャット機能を通じてワンクリック実装で迅速に修正できます。生成されたテストクラスは SAP システムですぐに利用でき、必要に応じて微調整できます。 “Generate unit test class for public methods ”Provide the your class logic/details here” この機能により、開発者は複数の反復後でもビジネスロジックを簡単にテストでき、手動テストにかかる工数を節約できます。 ユースケース #4：レガシーABAPコードのドキュメント生成 次の例では、Amazon Q Developer が ABAP コードを分析し、チャットウィンドウのカスタムテンプレートに基づいてドキュメントを自動生成します。このユースケースは既存のコードと新しく作成されたコードの両方に適切できます。生成後に、ドキュメントは PDF やWord ドキュメントに簡単に変換できます。Amazon Q Developer は、重要な情報を理解し、一貫したフォーマット標準を維持しながらドキュメント作成プロセスを行います。この例では、次のプロンプトを使用しました。 “Generate a technical documentation of the above ABAP code. Make sure to provide highly detailed documentation, clearly explaining the action performed each of the components using following pointers as template: 1. Class/Program name 2. Class/Program Overview 3. Technical Specifications 3.1 Data Structure 3.2 Selection Screen (If provided) 4. Main Components 4.1 Subroutines/Methods 5. Test Implementation (If provided) 5.1 Test Methods 5.2 Test Setup 6. Technical Dependencies 7. Error Handling 8. Performance Considerations このユースケースは、企業はカスタムオブジェクトから影響を受けるビジネスプロセスを簡単に理解し、文書化できます。これにより移行とカレッジトランスファーのプロセスに役立ちます。 上記のユースケースからわかるように、Amazon Q Developer は SAP 開発者の手作業を削減する強力な機能を提供し、顧客がビジネスプロセスをより迅速にモダナイズできるように支援します。私たちは、お客様がこれらの機能を活用し続けることを期待しております。 料金体系 Amazon Q Developer 無料ティアから始めることができます。これは月 50 回のチャットインタラクション、月 5 回のソフトウェア開発支援、月最大 1,000 行のコード変換を提供します。Pro プランは無料プランのすべての機能に加えて、ユーザーとポリシーを管理するエンタープライズアクセス制御機能、提案を改善するために Amazon Q Developer で独自のコードをベースにしたカスタマイズ機能、高度な機能のために高い使用リミットを提供します。 詳細な価格プランはこちらをクリック してご確認ください。 今すぐレガシー SAP コードをモダナイズしましょう Amazon Q Developer のセットアップに関するステップバイステップの手順については、この ワークショップ をご参考ください。今後、これらやその他の SAP での活用シナリオのデモや詳細な解説をするビデオをYoutubeに公開する予定なので、ご確認ください。Amazon Q Developer の詳細については、 ドキュメント でご確認ください。レガシー SAP コードのモダナイゼーションに関する相談は、私たちのチームにお問い合わせください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

本記事は米国時間 7 月 14 日に公開された「 Introducing Kiro – A new agentic IDE that works alongside you from prototype to production 」の日本語抄訳版です。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 こんな経験はありませんか。何度もプロンプトを入力すると、動作するアプリケーションができあがる。楽しくて魔法のように感じます。しかし、プロダクション環境に移行するには、それだけでは不十分です。アプリケーションを構築する際、AI モデルはどのような前提を置いたのでしょうか？あなたはずっとエージェントをガイドしてきましたが、それらの決定は文書化されていません。要件は曖昧で、アプリケーションがそれらを満たしているかどうかわかりません。システムがどのように設計され、その設計があなたの環境とパフォーマンスにどう影響するかをすぐに理解できません。時には一歩下がって決定事項を整理することで、より良くて保守しやすいアプリケーションにたどり着くことがあります。それが Kiro が仕様駆動開発で支援することです。 コンセプトからプロダクションまで、AI エージェントとの作業を簡素化した開発者体験を通じて開発を支援する AI IDE（統合開発環境）、Kiro の発表を嬉しく思います。Kiro は Vibe Coding “も” 得意ですが、それをはるかに超えています。Kiro の強みは、スペック (spec) やフック (hook) などの機能を使って、これらのプロトタイプをプロダクションシステムに移行することです。 Kiro スペック (spec) は、機能を深く考える必要がある時、事前計画が必要なリファクタリング作業、システムの動作を理解したい時など、プロダクションに移行するために必要なほとんどの場面で有用な成果物です。開発を始める時、要件は通常不明確なので、開発者は計画と明確化のために仕様を使用します。仕様は同じ方法で AI エージェントをより良い実装に導くことができます。 Kiroフック (hook) は、あなたが見落としたことをキャッチしたり、作業中にバックグラウンドで定型業務を完了する経験豊富な開発者のように機能します。これらのイベント駆動による自動化は、ファイルの保存、作成、削除時、または手動トリガーでエージェントにバックグラウンドタスクを実行させます。 スペックとフックを使った開発 Kiro は仕様ワークフローを開発とより統合することで加速します。この例では、手作り品販売の e コマースアプリケーションに、ユーザーが各商品にフィードバックを残すためのレビューシステムを追加したいと思います。spec を使った開発の 3 ステップのプロセスを見てみましょう。 私たちが取り組んでいる e コマースアプリ 1. 単一プロンプトから要件へ Kiro は単一プロンプトから要件を展開します。「製品のレビューシステムを追加」と入力すると、レビューの表示、作成、フィルタリング、評価というユーザーストーリーが生成されます。各ユーザーストーリーには、開発者が基本的なユーザーストーリーから構築する際に通常処理するエッジケースをカバーする EARS（Easy Approach to Requirements Syntax）記法の受け入れ基準が含まれます。これによりプロンプトの前提が明示的になり、Kiro が求めているものを構築していることがわかります。 Kiro の要件仕様 2. 要件に基づく技術設計 Kiro はコードベースと承認された仕様要件を分析して設計文書を生成します。データフロー図、TypeScript インターフェース、データベーススキーマ、API エンドポイントを作成します。例えば、レビューシステムの Review インターフェースなどです。これにより、通常開発を遅らせる要件の明確化に関する長いやり取りが不要になります。 Kiro のインターフェース、マーメイド図、データフロー図を含む設計仕様 3. タスクの実装 Kiro はタスクとサブタスクを生成し、依存関係に基づいて正しく順序付けし、各タスクを要件にリンクします。各タスクには、単体テスト、統合テスト、ローディング状態、モバイル対応、アクセシビリティ要件などの実装詳細が含まれます。これにより、完了したと思った後に不足部分を発見するのではなく、段階的に作業をチェックできます。 Kiro はタスクとサブタスクを自動生成し、それらを適切な順序で並べ、各タスクを要件に紐づけることで、抜け漏れがないようにすることで、全プロセスを簡素化します。Kiro は各タスクに対する単体テストの作成、ローディング状態の追加、商品とレビュー間の相互作用のための統合テスト、そしてレスポンシブデザインとアクセシビリティについても考慮しています。 タスクインターフェースでは、実行状況を示す進行インジケーターとともにタスクを一つずつトリガーできます。完了後は、完了状況をインラインで確認し、コード差分とエージェント実行履歴を表示して作業を監査できます。 Kiro スペックはあなたの進化するコードベースと同期し続けます。開発者はコードを作成し、Kiro に仕様の更新を依頼するか、手動で仕様を更新してタスクを更新することができます。これにより、開発者が実装中に元の成果物の更新を止めてしまうという一般的な問題を解決し、将来のメンテナンスを複雑にする文書の不一致を防ぎます。 4. フックでリリース前に問題を発見 コードをコミットする前に、ほとんどの開発者は頭の中でチェックリストを実行します。何かを壊していないか？テストは更新されているか？ドキュメントは最新か？これは健全ですが、実装には多くの手作業が必要になることがあります。 Kiro のエージェントフックは、あなたが見落としたことをキャッチするベテラン開発者のように機能します。フックはファイルの保存や作成時に実行されるイベント駆動自動化で、協力者にタスクを委任するようなものです。一度フックを設定すれば、Kiro が残りを処理します。いくつかの例をご紹介します。 React コンポーネントを保存すると、フックがテストファイルを更新します。 API エンドポイントを変更すると、フックが README ファイルを更新します。 コミットの準備ができると、セキュリティフックが資格情報の漏洩をスキャンします。 フックはチーム全体で一貫性を確保します。すべての人が同じ品質チェック、コード標準、セキュリティ検証の修正の恩恵を受けます。私たちのレビュー機能では、新しい React コンポーネントが単一責任の原則に従うことを確認したいと考えています。これにより、開発者が多くのことを行うコンポーネントを作成しないようにします。Kiro は私のプロンプトを受け取り、最適化されたシステムプロンプトを生成し、監視するリポジトリフォルダを選択します。このフックが Git にコミットされると、コーディング標準がチーム全体に適用されます。誰かが新しいコンポーネントを追加するたびに、エージェントは自動的にそれをガイドラインに照らして検証します。 ファイル保存時に実行されるフックを作成する その他の充実した機能 Kiro スペックと Kiro フック以外にも、Kiro には AI コードエディターに期待されるすべての機能が含まれています。専門ツールを接続するための Model Context Protocol (MCP) サポート、プロジェクト全体で AI の動作を導くステアリングルール、ファイル、URL、ドキュメントのコンテキストプロバイダーを持つアドホックコーディングタスクのためのエージェントチャットなどです。Kiro は Code OSS をベースに構築されているため、VS Code の設定と Open VSX 互換プラグインを維持しながら IDE を使用できます。完全な AI コーディング体験に加えて、プロダクションに必要な基盤も提供します。 今後について 私たちのビジョンは、ソフトウェア製品の構築を困難にする根本的な課題を解決することです。チーム間の設計整合性の確保、競合する要件の解決、技術的負債の排除、コードレビューの厳格化、シニアエンジニアが退職した際のチームの知識の保持まで。人間と機械がソフトウェアを構築するために協調する方法は、まだ混乱しており断片的ですが、私たちはそれを変えるために取り組んでいます。仕様はその方向への大きな一歩です。 仕様駆動開発を体験する準備はできていますか？Kiro はプレビュー期間中は無料で、一部制限があります。実際のアプリケーションを構築するためにお試しいただき、 Discord サーバー でご意見をお聞かせください。 開始するには、 Kiro をダウンロード して Google や GitHub を含む 4 つのログイン方法のいずれかでサインインしてください。Mac、Windows、Linux と、最も人気のあるプログラミング言語をサポートしています。 実践的なチュートリアル では、仕様からデプロイまでの完全な機能の構築を体験いただくことができます。 ぜひ繋がりましょう。 X 、 LinkedIn 、 Instagram で @kirodotdev、 Bluesky で @kiro.dev をタグ付けし、ハッシュタグ #builtwithkiro を使用して作成したものを共有してください。

本ブログは 2025 年 6 月 19 日に公開された Blog ” How to prioritize security risks using AWS Security Hub exposure findings ” を翻訳したものです。 re:Inforce 2025 で、AWS は強化された AWS Security Hub を発表しました。これにより、組織がクラウド環境を保護するために、重大なセキュリティ問題を大規模に優先順位付けして対応する方法を変革できます。本ブログ記事では、Security Hub の 露出の検出結果 機能を使用して、これらの問題に優先順位を付ける方法を説明します。強化された Security Hub は、高度な分析を使用して、クラウド環境全体のセキュリティシグナルを自動的に関連付け、補強し、優先順位付けを行います。Security Hub は、 Amazon GuardDuty 、 Amazon Inspector 、 Amazon Macie 、および以前は AWS Security Hub として知られていた AWS Security Hub Cloud Security Posture Management (CSPM) とシームレスに統合されています。この統合を通じて、Security Hub は総合的な脅威検出と脆弱性評価を提供します。このインテリジェントな統合により、組織は認証情報侵害の可能性から意図しないリソースの露出まで重大なセキュリティ問題を迅速に特定し、セキュリティチームは最も重要な事項に集中できるようになります。 Security Hub の概要 Security Hub は、統合されたクラウドセキュリティソリューションを通じて、クラウドのセキュリティ体制を強化するための 3 つの重要なセキュリティ機能を提供します。 一元管理と継続的なモニタリングを通じて、組織全体の可視性を提供します。 Amazon Inspector や AWS Security Hub CSPM などのサービスから送られるセキュリティシグナルに情報を付加することで、お客様の環境に特有のアクティブなリスクを表面化させます。それにより、自信を持って優先順位付けを行い、対応を効率化できるようになります。 Amazon Inspector、AWS Security Hub CSPM、Amazon Macie、およびその他の AWS サービスからの検出結果を関連付けます。それにより、潜在的な攻撃経路の特定、悪用可能な脆弱性や不適切な設定の発見、および実行可能な修復手順の提供を支援する、統合リスク分析を提供します。 お客様の最大の関心事は、「どこから優先的に対応すべきか」を判断する方法です。セキュリティの検出結果が個別に表示されると、複数のアカウントやリージョンにまたがる大量の検出結果を管理しづらくなり、真の優先順位や影響を判断することが難しくなります。Security Hub では、コンテキストに基づく分析を提供することでこの問題を解決します。脆弱性、脅威、不適切な設定を関連付けることで悪用可能な経路を明らかにし、最も重大なリスクを表面化させます。これにより、どの問題から優先的に対処すべきかについて、十分な情報に基づいた判断を下すことができます。 露出の検出結果を参照することで、重大なセキュリティ問題の優先順位付けと対応を、大規模に行うことが可能になります。露出は、Security Hub CSPM、脆弱性をスキャンする Amazon Inspector、機密データの検出と保護を行う Amazon Macie からの検出結果と特性の分析に基づいています。これらは潜在的なセキュリティ問題として定義され、さまざまな露出の特性によって生成されます。 自動的な関連付けと補強されたシグナルが無い場合、セキュリティチームは問題の優先順位付けを効率的に行うことが難しくなります。例えば、Amazon Inspector が検出した脆弱性は、Security Hub CSPM が特定した不適切な設定と組み合わさることで、極めて重大になる可能性があります。しかし、何千ものシグナルの関係を手動で分析することは時間がかかり、重大なセキュリティコンテキストを見逃しやすくなります。これに対応するためにカスタムソリューションを構築するチームもありますが、このアプローチでは分析担当者の時間と保守作業が大幅に必要となり、重大なセキュリティの関連性が見落とされる可能性があります。 Security Hub は、統合されたクラウドセキュリティセンターにおいて、これらの AWS サービス間をネイティブに統合することで、ログの収集と集約のオーバーヘッド無しに、この複雑さを軽減します。これによりセキュリティチームは、個々のセキュリティシグナルを手動で組み合わせることに貴重な時間を費やすことなく、重大な露出がビジネスに影響を与える前に、それらを特定し対応できるようになります。自動化された関連付けと強化されたコンテキストにより、どこに労力を集中させるべきかについて、より迅速で十分な情報に基づいた意思決定を行うことができます。これにより、最終的にクラウド環境をより効果的に保護することができます。 露出の検出結果は、セキュリティ体制に対する総合的な視点を提供することで、環境内のセキュリティリスクを特定します。これらの検出結果により、潜在的なリスクを理解し対処することができます。この統合的なアプローチを通じて、最も重大な露出の検出結果に最初に焦点を当てることで、修復作業の優先順位付けを効率的に行うことができます。 露出の検出結果は、 Open Cybersecurity Schema Framework (OCSF) スキーマでフォーマットされています。これは、セキュリティツール間でシームレスにデータを共有できるオープンソースの標準です。Security Hub が OCSF を採用していることによるメリットはいくつかあります。Linux Foundation の一部であるオープンで標準化されたスキーマとして、OCSF は AWS 環境内外の複数のセキュリティツールやサービス間の相互運用性を可能にします。一貫したフィールドの命名とカテゴリ分けにより、強化されたデータの正規化を提供することで、サードパーティのセキュリティツールとの統合がより容易になります。 Security Hub の検出結果を受信できる OCSF スキーマをサポートしている、またはサポートする予定のパートナーには、次の企業が含まれています: Arctic Wolf、CrowdStrike、Comcast の DataBee、Datadog、DTEX Systems、Dynatrace、Fortinet、IBM、Netskope、 Orca Security 、Palo Alto Networks、Rapid7、Securonix、 SentinelOne 、Sophos、Splunk、Cisco Company、 Sumo Logic 、 Tines 、Trellix、 Wiz 、Zscaler。さらに、 Accenture 、Caylent、 Deloitte 、IBM、 Optiv などのサービスパートナーが、Security Hub と OCSF スキーマの導入を支援できます。 セキュリティリスクの優先順位付け Security Hub に移動すると、図 1 に示す露出の概要ウィジェットを含む、概要ダッシュボードが表示されます。このウィジェットには、露出の重大度と数が表示されます。Security Hub は各露出の検出結果に、重要 (Critical)、高 (High)、中 (Medium)、または低 (Low) のデフォルトの重大度を割り当てます。重大度が情報 (Informational) の検出結果は表示されません。 Security Hub は、AWS サービス全体にわたる複数のセキュリティ特性を分析および関連付けることで、露出の検出結果の重大度を計算します。Security Hub はこれらの要素を個別に評価するのではなく、コンテキストに基づくアプローチを使用し、各要素がどのように相関しているかに基づいて重大度を割り当てています。例えば、脆弱性が検知されたリソースがあった場合に、インターネットから悪用可能であったり機密データへのアクセス権を持っていたりすると、より高い重大度となる可能性があります。 Security Hub は、露出の検出結果のデフォルト重大度を決定するために、いくつかの要素を使用します。 発見のしやすさ – ポートスキャンやインターネット検索など、リスクのあるリソースを発見するための自動ツールの利用可能性。 悪用のしやすさ – 脅威アクターがリスクを悪用できる容易さ。例えば、オープンなネットワークパスや誤って設定されたメタデータがある場合、脅威アクターはより迅速にリスクを悪用できます。 悪用の可能性 – Security Hub は、脆弱性が悪用される確率を推定するデータ駆動型スコアリングシステム Exploit Prediction Scoring System (EPSS) などの外部シグナルと、内部の脅威インテリジェンスの両方を使用して、リスクが悪用される確率を判断します。この包括的なアプローチは、 Amazon Elastic Compute Cloud (EC2) インスタンスと AWS Lambda 関数の露出の検出結果に適用されます。 認知度 – リスクが単なる理論上のものではなく、どの程度公になっているか、あるいは、自動化されたエクスプロイト (攻撃手法) が存在しているか。この要素は EC2 インスタンスと Lambda 関数の露出の検出結果に適用されます。 影響 – エクスプロイトが実行された場合の潜在的な被害。例えば、露出によって、データ漏洩による機密性の喪失、データ破損による完全性の喪失、可用性の喪失、または説明責任の喪失につながる可能性があります。 このウィジェットのリスク一覧は、重大な検出結果の数が最も多い上位 8 つのリスクに絞って表示されます。2 つ以上のリスクで重大な検出結果の数が同じ場合、それらの検出結果は自動的に、より最近の重大な検出結果の後ろにグループ化されてリストに表記されます。 図 1: 露出の概要ウィジェット このウィジェットから露出のダッシュボードに移動すると、潜在的なセキュリティ問題の継続的な分析のために、事前にフィルタリングされた露出のビューを確認できます。各重大度に関連付けられた数字を選択して重大度でフィルタリングしたり、リストから選択して特定の露出の検出結果を表示したり、[ すべての露出検出結果を表示 ] を選択して図 2 に示す新しい露出のダッシュボードを表示したりすることができます。 図 2: 露出のダッシュボード 露出のコンソールでは、検出結果をタイトル別に、重大度の高い順に表示しています。これはフィルター条件によって整理され、検出結果のタイトルでグループ化されています。図 2 に示すように、左側に表示される [ クイックフィルター ] では、重大度、全体の中で検出結果が多いトップ 10 の属性、トップ 10 のアカウント、トップ 10 のリソースタイプに基づいて、露出の検出結果を迅速にフィルタリングする方法を提供します。フィルターの使用に加えて、[ グループ化条件 ] のドロップダウンを使用することで、AWS アカウント ID、リソースタイプ、製品名など特定の属性で露出の検出結果をグループ化することもできます。 露出の検出結果をレビューするには、図 3 に示すように検出結果を展開し、ソフトウェアの脆弱性、不適切な設定、到達可能性などのリソース、ステータス、属性、および特性の相関関係を表示します。これらは特性タイプとも呼ばれます。特定の露出の検出結果では、特性は 1 つ以上のシグナルに関連付けられ、シグナルは 1 つ以上の指標を含むことができます。 図 3: 露出の検出結果 図 3 に示すように、[ Potential Credential Stealing: Internet reachable EC2 instance with administrative instance profile has network-exploitable software vulnerabilities with a high likelihood of exploitation ] という検出結果は、そのインスタンスに不適切な設定、脆弱性、および到達可能性 (リソースへのオープンなネットワーク経路があることの示唆) が関連することを示しています。リスクに関連する行の任意の場所を選択すると、図 4 に示す概要パネルが表示され、このシグナルについてより詳しい情報を参照することができます。 図 4: 露出の検出結果の概要 この例では、us-east-1 リージョンにあるインターネットからアクセス可能な EC2 インスタンスのソフトウェア脆弱性に関する重大度が [重要] である検出結果を示しています。この可視化が強力なのは、[ 潜在的な攻撃パス ] の図を参照することで、潜在的な脅威アクターがこれらの脆弱性をどのように悪用してリソースにアクセスする可能性があるかをマッピングして、重要なポイントを把握するのに役立つからです。この検出結果には、リソース識別子、作成時間、到達可能性、脆弱性、および不適切な設定などの重要なメタデータも含まれています。 この検出結果を使用することで、複雑なセキュリティの関連性をすばやく理解し、リスクの状況を評価し、修復の優先順位を決定できます。それにより、クラウド内のワークロードをより適切に保護し、より情報に基づいたセキュリティの意思決定を行うことができるようになります。セキュリティの対応に優先順位を付けるために、検出結果の重大度レベルを調整したり、ステータスを更新したり、OCSF 形式で検出結果をエクスポートしたりすることもできます。 露出の検出結果が表示されている理由を確認するために、図 5 に示すように [ 特性 ] タブを選択します。これにより、 不適切な設定 や 脆弱性 などの特性が一覧表示されます。[ 特性 ] タブで [ シグナル別 ] を選択すると、露出の検出結果に関連する全シグナルが一覧表示されます。これらのシグナルは、Security Hub CSPM や Amazon Inspector などのさまざまなサービスから作成された根本的な検出結果であり、それらが関連付けられて露出の検出結果に関連するリスクが判断されます。 図 5: 露出の検出結果の特性タブ [ リソース ] タブを選択すると、図 6 に示すように、露出の検出結果に関連するリソースが表示されます。 図 6: 露出の検出結果のリソースタブ 表示されるリソースは 1 つだけとは限らず、EC2 インスタンス、 Amazon Simple Storage Service (Amazon S3) バケット、 AWS Identity and Access Management (IAM) ロールなど複数リソースの組み合わせで表示される場合もあります。このリソースのリストは、検出結果に起因するリスクを軽減するために、お客様の環境で何を修復する必要があるかを判断するのに役立ちます。 最後に、[ チケット作成 ] のオプションを使用することで、Security Hub は Atlassian の Jira Service Management や ServiceNow などの人気のあるサービス管理システムとネイティブに統合し、インシデント管理プロセスを効率化できます。この統合により、手動でのチケット作成の必要性が最小限に抑えられ、セキュリティ問題の発見から修復までの時間を短縮することができます。組織は Security Hub 自動化ルール を使用して、Security Hub コンソールから直接セキュリティ検出結果のチケットを自動作成して追跡でき、重大なセキュリティの露出が未対応のまま放置されないようにするのに役立ちます。これらの広く使用されているサービス管理システムとの統合により、一貫したワークフローの維持、修復作業の追跡がしやすくなり、セキュリティチームと運用チームのコラボレーションもより行いやすくなります。このように、検出から解決までの効率的な道筋を提供することで、セキュリティ運用の効率化を図ることができます。 まとめ Security Hub の強化された露出の検出機能は、組織がクラウド環境を安全に保つ方法を大きく進歩させることができます。複数の AWS サービスを通してセキュリティシグナルを自動的に関連付けて分析することで、Security Hub はお客様が最も重大なセキュリティ問題が何であるかを、自信を持って大規模に優先順位付けして対応するのに役立ちます。潜在的な攻撃パスを直感的に可視化し、インテリジェントな重大度ランキングと総合的な特性分析を提供することで、リスクの優先順位付けについてセキュリティチームがデータに基づく意思決定を行うことを可能にします。 Security Hub の露出の検出結果は、組織がセキュリティ体制を発生ベース型から事前予防型へ、以下の方法で移行するのに役立ちます。 パブリックにアクセス可能となっているリソースを自動的に発見して評価する セキュリティの機能と設定について明確な可視性を提供する 複数のセキュリティシグナルを関連付けて、重大なリスクを特定する 実行可能な修復手順を提示する 効率的な分析のための直感的なフィルタリングとグループ化オプションを提供する クラウド環境が複雑化し続ける中、露出の検出機能は、潜在的なセキュリティの問題を前もって対応するために必要な自動化、インテリジェンス、コンテキストを提供します。これにより、セキュリティチームは重大なリスクへの対応に貴重な時間を集中して使えるようになり、最終的に組織がクラウド環境全体でより強固なセキュリティ体制を維持するのに役立ちます。 小規模な開発環境または大規模なエンタープライズ環境のどちらを管理している場合でも、Security Hub の露出の検出結果は、AWS ワークロードを効果的に保護し、進化し続ける周辺環境の中で強固なセキュリティ体制を維持するために必要な洞察を提供します。 本ブログ記事に関するフィードバックがございましたら、 翻訳元ブログ の Comments 欄にコメントを投稿してください。本ブログ記事に関する質問がある場合は、 AWS Security, Identity, and Compliance re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 Shahna Campbell Shahna は AWS のソリューションアーキテクトで、セキュリティにフォーカスしたスペシャリストチームで働いています。以前は、臨床のヘルスケア分野でアプリケーションスペシャリストとして働いていました。Shahna はサイバーセキュリティと分析の分野に情熱を持っています。彼女は自由時間に、ハイキング、旅行、そして家族と過ごすことを楽しんでいます。 Marshall Jones Marshall は AWS のワールドワイドセキュリティスペシャリストソリューションアーキテクトです。彼のバックグラウンドには AWS コンサルティングとセキュリティアーキテクトがあり、エッジセキュリティ、脅威検知、コンプライアンスなどさまざまなセキュリティ領域に焦点を当ててきました。現在は、AWS のエンタープライズのお客様が AWS セキュリティサービスを採用および運用可能にし、セキュリティの効果を高めてリスクを軽減できるよう支援することに注力しています。 Kimberly Dickson Kimberly はシンガポールを拠点とする AWS のセキュリティスペシャリストソリューションアーキテクトです。彼女は、お客様が自信を持って安全にクラウドでの運用を行えることを支援する技術的なセキュリティソリューションについて、お客様と協力して働くことに情熱を持っています。 本ブログは Solutions Architect の 泉 航 が翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。6月25日、26日に開催された AWS Summit 2025 に参加された方も多いのではないでしょうか？私も2日間ブースに立たせていただき、たくさんの学びと刺激を得ることができました。この場を借りて、お忙しい中ご参加頂いた皆様と運営に関わられた皆様に感謝申し上げます。 さて、最近生成AI関連の自己学習リソースが本当に充実してきました。特に注目なのが、先日リリースされた AWS Builder Center ！ これまでの community.aws が進化する形でローンチされた、新しい学習ポータルです。技術スキルの向上をサポートしてくれるプラットフォームとして生まれ変わり、AIやML、コンテナ、サーバーレスなど、興味のある技術分野に応じた学習パスの提供や hands-on まで無料で利用できます。この後ご紹介する AWS SimuLearn と合わせて、AWS の学習環境が進化していますので是非チェックしてみてください。 では今週も生成 AI with AWS 界隈のニュースを見ていきましょう！ さまざまなニュース ブログ記事「通信事業者が提供するSmart-Xのための協調AIエージェントによる分散推論」 このブログでは、デバイスエッジからAWSクラウドまでの多層アーキテクチャにおいて、AIの推論処理を効率的に分散させる新しいアプローチについて解説しています。具体例として交差点安全システムを取り上げ、カメラやセンサーからのリアルタイムデータを用いた事故予防や対応の仕組みを説明しています。ファーエッジ（デバイス）でリアルタイムの推論処理、ニアエッジ（通信事業者のMECサイト）で複数デバイスからのデータ集約と高度な推論、そしてAWS上で全体的なオーケストレーションと分析を行います。このアプローチにより、低遅延での即時対応と、AWS上での高度な分析の両立が可能になります。リアルタイム性が求められるエッジでの処理と、高度な分析が必要なクラウドでの処理を最適に組み合わせることで、より効率的で信頼性の高いSmart-Xソリューションを構築できる点がポイントです。 ブログ記事「スタートアップ 3 社に学ぶ生成 AI 実装のリアル。AWS 活用の最前線【AWS Summit Japan・事例セッション】」 AWS Summit Japan 2025 で紹介された、生成AIを活用する3つのスタートアップ企業の事例を紹介しています。LayerX社は、Amazon Bedrock を活用して経理業務の効率化を実現し、独自のAI-OCRシステムと大規模言語モデルを組み合わせることで、高精度な帳票処理を可能にしました。カラクリ社は、AWS Trainium を活用して独自のLLMを開発し、カスタマーサポート業務に特化した高性能なAIエージェントを低コストで実現しています。ファインディ社は、Amazon Security Lake を導入してセキュリティログを一元管理し、Amazon Bedrock と連携させることで、セキュリティ監視業務の効率化に成功しました。それぞれ生成AIを活用する事で企業固有の課題を解決し、業務効率を大きく改善した事例になります。 ブログ記事「AWS SimuLearn: Generative AI – 「生成AI」を無料で学習しましょう！」 AWS SimuLearn は、生成AIを活用した新しい学習プラットフォームです。現在、生成AIとクラウドの基礎に関する無料の日本語対応コースを提供しています。現在、生成 AI 関連の 8 コースとクラウドの基礎 12 コースを無料で利用することができます。実際のAWSアカウントを使用した実践的なハンズオン学習が、料金を気にすることなく実施できる環境が整備されていることがポイントです。 サービスアップデート Amazon CloudWatch と Application Signals の AI 支援トラブルシューティング用 MCP サーバー AIによる自動化されたトラブルシューティングと監視を強化する2つの新しいModel Context Protocol (MCP) サーバーを発表しました。これにより、AIエージェントが、より高度な分析と問題解決をサポートできるようになります。CloudWatch MCPサーバーはアラームベースのインシデント対応やメトリクス分析を提供し、Application Signals MCPサーバーはSLOを通じたサービスヘルスモニタリングと自動化された根本原因分析を実現します。ポイントは、自然言語でのクエリを通じてテレメトリーデータからビジネスインサイトを生成できること、そしてAIアシスタントが組み込みのアプリケーションパフォーマンスモニタリングの知識を活用して実用的な解決策を提案できることです。これらのツールにより、開発者は複数のAWSコンソールやAPIを手動で操作する必要がなくなり、より効率的なトラブルシューティングが可能になります。 Amazon Neptune AnalyticsがGenAIアプリケーション向けにMem0との統合を開始 Amazon Neptune Analytics がオープンソースのGenAI向けメモリシステムであるMem0との統合を発表しました。この統合により、AIエージェントがグラフデータベースを長期記憶機能として活用できるようになり、よりパーソナライズされたAI体験の提供が可能になります。Neptune をメモリストアとして使用することで、LLMは各インタラクションから学習し、時間とともにより効果的な応答が可能になります。グラフ、ベクター、キーワードの複数のモダリティにわたるハイブリッド検索もサポートされており、マルチホップグラフ推論による応答品質の向上も実現します。 Amazon Bedrockが開発を効率化するAPIキーを導入 Amazon Bedrock に新しくAPIキー認証機能が追加され、生成AIアプリケーションの開発がより簡単になりました。従来はIAMのプリンシパルとポリシーの手動設定が必要でしたが、Amazon Bedrock コンソールやaws SDKから直接認証情報を生成できるようになります。開発者は短期（最大12時間）または長期のAPIキーを選択でき、長期キーは有効期限の設定やIAMのコンソールでの管理が可能です。 Amazon SageMaker AIがAWSアジアパシフィック（台北）リージョンで利用可能に 機械学習の開発をサポートするAmazon SageMaker AI が、2025年6月に新しくオープンしたアジアパシフィック（台北）リージョンでの提供を開始しました。Amazon SageMaker AI は、開発者やデータサイエンティストが機械学習モデルを効率的に構築、トレーニング、デプロイできる完全マネージド型プラットフォームで、機械学習プロセスの各ステップにおける煩雑な作業を軽減し、高品質なモデル開発を容易にします。 Amazon Q in QuickSightが7つの新しいリージョンで利用可能になりました Amazon Q in QuickSight のサービス提供地域が大幅に拡大され、東京を含むアジア太平洋、ヨーロッパ、米国の7つの新しいリージョンで利用可能になりました。このサービスは、自然言語を使ってデータから洞察を引き出し、ビジネス分析を加速させる機能を提供します。ユーザーはAmazon Q in QuickSight を使用することで、データの説明やレコメンデーションを含むドキュメントやエグゼクティブサマリーを生成できます。 Amazon Q Developer のチャット機能が AWS Management Console を介してサービスのデータを照会可能に Amazon Q Developer の機能が拡張され、AWS Management Console、Slack、Microsoft Teams、AWS Console Mobile Applicationから直接AWSサービスのデータを照会・分析できるようになりました。例えば、S3バケットに保存されたログや、DynamoDBのレコード、CloudWatchログなどを自然言語で対話しながら分析できます。複数のインターフェースを行き来したり、異なるソースから情報を手動で収集したりする必要がなくなるため、クラウド環境の管理やトラブルシューティングにかかる時間と労力を大幅に削減できます。この機能は追加設定なしですぐに利用可能です。 Amazon SageMaker HyperPodが新しいオブザーバビリティー機能を発表 Amazon SageMaker HyperPod に新しいオブザーバビリティー機能が追加され、生成AIモデルの開発プロセスを大幅に効率化できるようになりました。Amazon Managed Grafana と Amazon Managed Prometheus を活用した統合ダッシュボードにより、生成AIタスクのパフォーマンスメトリクス、リソース使用率、クラスターの健全性を一元的に監視できます。これにより、パフォーマンスボトルネックの特定やトラブルシューティングの時間が大幅に短縮されます。 フルマネージド型MLflow 3.0がAmazon SageMaker AIで利用可能に Amazon SageMaker が提供するフルマネージド型MLflow 3.0は、生成AIの開発プロセスを大幅に効率化する新機能です。実験の追跡から本番環境までのエンドツーエンドのオブザーバビリティーを提供し、開発者は単一のツールで実験の追跡やモデル・AIアプリケーションのパフォーマンス監視が可能になりました。特に生成AIアプリケーションの各ステップにおける入力、出力、メタデータを記録するトレース機能は予期せぬ動作や不具合の原因特定を迅速化できます。また、各モデルとアプリケーションバージョンの記録を維持することで、AIの応答をソースコンポーネントまで追跡できるため、トラブルシューティングの時間を大幅に削減することができます。 Amazon SageMaker HyperPodがAIワークフロー用のCLIとSDKを一般提供開始 Amazon SageMaker HyperPod のCLIとSDKが一般提供開始されました。CLIはHyperPodクラスターの管理と迅速な実験のための一貫した操作性を提供し、SDKは分散トレーニングと推論機能へのプログラムによるアクセスを可能にします。データサイエンティストやMLエンジニアは、簡単なコマンドでトレーニングジョブの起動、推論エンドポイントのデプロイ、クラスターのパフォーマンス監視が可能になり、システムログや可観測性ダッシュボードへのアクセスによってデバッグや開発の効率化が図れます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 アップデートの前に、先日開催された re:Inforce のre:Capイベントを含め今月いくつかイベントが予定されているので紹介させてください。よかったらご参加ください。 — 商用データベースをAWSで活用する 2025 年 7 月 17 日 (木) 10:00 – 12:00 JST 開催場所：オンライン 申し込みは こちら AWS re:Inforce 2025 re:Cap 〜クラウドセキュリティを簡素化してイノベーションを加速〜 2025 年 7 月 24 日 (木) 10:00 – 12:00 JST 開催場所：オンライン 申し込みは こちら 金融業界向け：AWS の生成 AI 基盤で実現するデータ駆動型金融革新 2025 年 7 月 24 日 (木) 14:00 – 16:00 JST 開催場所：オンライン 申し込みは こちら — それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月7日週の主要なアップデート 7/7(月) この日のアップデートはありませんでした。 7/8(火) Oracle Database@AWS is now generally available Oracle Database@AWS が一般提供開始されました。これは AWS と Oracle が共同で提供するサービスで、AWS データセンター内で Oracle Exadata Database Service と Oracle Autonomous Database on Dedicated Exadata Infrastructureを利用できるものです。Oracle RAC等の利用ができる他、Amazon Redshift との Zero-ETL 、S3やCloudWatch他のAWSサービスと統合されます。まずは、バージニア北部 およびオレゴンの2つのリージョンでの提供ですが、今後東京、大阪を含む20のリージョンに拡大予定です。詳細については Oracle Database@AWS  と ドキュメント をご確認ください。 Amazon VPC Lattice announces support for Oracle Database@AWS Amazon VPC Lattice が Oracle Database@AWS (ODB) をサポートしました。VPC Lattice のサポートにより、複雑なネットワーキングの設定を必要とすることなく、ODBから数千の VPC やオンプレミス環境を横断して AWS サービス、HTTP API、TCP アプリケーションに簡単に接続できるようになる他、Amazon S3 と Amazon Redshift にプライベートかつ安全にアクセスすることが可能です。これによりデータベースの OCI マネージドバックアップや、独自の バックアップをAmazon S3に取得するのを簡単に設定可能です。詳細については、 リリースブログ 、Amazon  VPC Lattice 、および  Oracle Database@AWS  のドキュメントをご確認ください。 AWS Network Firewall: Native AWS Transit Gateway support in all regions AWS Network Firewall が全リージョンで AWS Transit Gateway との直接統合をサポートしました。これまでは専用の VPC サブネットやルートテーブルの管理が必要でしたが、今回のアップデートで直接アタッチが可能になり設定が大幅に簡素化されます。これによりAWS Site-to-Site VPN や AWS Direct Connect 経由で接続された VPC やオンプレミスネットワークを含む、AWS ネットワーク全体のトラフィックを保護できます。この機能は、AWS Network Firewall と AWS Transit Gateway の両方がサポートされている全ての  AWS リージョン で利用可能です。詳細は ドキュメント をご確認ください。 AWS Site-to-Site VPN now supports IPv6 addresses on outer tunnel IPs AWS Site-to-Site VPN で、外部トンネル IP に IPv6 アドレスを利用可能になりました。これまでIPv6のサポートは内部トンネルのみで、外部トンネルには IPv4 アドレスが必須でした。今回のアップデートで内部・外部の両方のトンネルで IPv6 アドレスを設定できるようになったことで、IPv6 専用ネットワークへの移行や規制要件への対応が簡単になります。また、外部トンネル IP での IPv6 利用には追加料金がかからないため、パブリック IPv4 のコストも削減できます。この機能はミラノリージョンを除く他のすべての商用リージョンと GovCloud リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Q in QuickSight is now available in 7 additional regions Amazon Q in QuickSightが東京リージョンを含む新たに７つのリージョンで利用可能になりました。利用開始されました。Amazon Q in QuickSightは自然言語でデータに質問するだけで洞察を得ることができる機能で、既存のダッシュボードでカバーされていない情報を得るのに、従来は複雑な操作が必要だったデータ分析が、専門スキル不要で簡単に行えるようになります。また、Amazon Q in QuickSight は顧客データでトレーニングしないため安心してご利用いただけます。30日間の無料枠もあるので、ぜひお試しください。 7/9(水) Amazon Q chat in the AWS Management Console can now query AWS service data Amazon Q Developer が AWS Management Console、Slack、Microsoft Teams チャット、AWS Console Mobile Application から直接、AWS サービスに保存されたデータをクエリおよび分析できるようになりました。これまで複数の画面を行き来していた作業が、自然言語での会話だけで完結します。例えば S3 バケット内のファイル分析、DynamoDB テーブルのレコード確認、CloudWatch ログの調査などが可能です。追加設定不要で全リージョンで利用でき、管理者は IAM 権限でアクセス制御できます。詳細は ドキュメント をご確認ください。 Amazon Connect now supports parallel AWS Lambda execution in flows Amazon Connectがフロー内でのAWS Lambda 関数の並列実行をサポートしました。Amazon Connect では、Lambda を使用して3rd Partyや自社のシステムと連携ができましたが、従来は Lambda 関数を順次実行する必要がありました。今回のアップデートで複数の Lambda を同時実行できるようになり、例えば購入履歴の確認とプロモーション情報の取得を並行して行うなどが可能になり顧客の待ち時間を短縮できます。機能は、Amazon Connect が利用可能な すべての AWS リージョン で利用可能です。詳細は ドキュメント をご確認ください。 Amazon P6e-GB200 UltraServers now available for the highest GPU performance in EC2 Amazon EC2 で最高性能の GPU インスタンス P6e-GB200 UltraServers が提供開始されました。NVIDIA の最新 GB200 GPU を最大 72 個搭載し、360 petaflopsの FP8 コンピュート、13.4 TB の総高帯域幅メモリ、および最大 28.8 Tbps の Elastic Fabric Adapterを利用可能で、従来では困難だった大規模 AI モデルの訓練や推論を効率的に実行できます。このインスタンスは現時点ではバージニア北部リージョンの拡張である Dallas Local Zoneで  Amazon EC2 Capacity Blocks for ML  を通じて利用可能です。詳細は ドキュメント をご確認ください。 7/10(木) Amazon SageMaker HyperPod introduces CLI and SDK for AI Workflows Amazon SageMaker HyperPodのCLIとSDKの一般提供が開始されました。SageMaker HyperPod CLI は、HyperPod クラスターの管理と迅速な実験のためのシンプルで一貫したコマンドライン体験を提供します。そして、SDK は HyperPod の分散トレーニングと推論機能へのプログラムからの直感的なアクセスを提供し、開発者がワークロード設定をきめ細かく制御できるようにします。これまで大規模 AI モデルの構築や訓練は複雑でしたが、これらの機能によりより簡単にトレーニングジョブの実行、推論エンドポイントのデプロイ、クラスターパフォーマンスの監視などが可能になりました。SageMaker HyperPodがサポートされているすべてのAWS商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon SageMaker Studio now supports remote connections from Visual Studio Code Amazon SageMaker StudioでVisual Studio Codeからのリモート接続がサポートされました。これまでAIの開発環境を構築するには数時間かかるケースもありましたが、今回のアップデートによりわずか数分でVS CodeからSageMakerの計算リソースにアクセスできるようになります。これにより普段使い慣れた VS Code の拡張機能やカスタム設定をそのまま活用しながら、AI モデルの開発やデータ分析が可能です。この機能は現時点ではオハイオリージョンで利用可能です。詳細は AWS ML ブログ もしくは ドキュメント をご確認ください。 Amazon SageMaker HyperPod accelerates open-weights model deployment Amazon SageMaker HyperPodが、Amazon SageMaker JumpStart からのオープンウェイト基盤モデルとAmazon S3およびAmazon FSxから独自のファインチューニングモデルの直接デプロイをサポートしました。従来は別々のリソースでモデルの訓練とデプロイを行う必要がありましたが、今回のアップデートにより同一の HyperPod クラスター上でモデルの訓練からファインチューニング、デプロイまでを一貫して実行可能になりました。この機能は東京を含む12のリージョンで利用可能です。詳細は ブログ および ドキュメント をご確認ください。 7/11(金) 大きなアップデートはありませんでした。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

2025 年 6 月 25 日・26 日に開催された AWS Summit Japan において、初日に「AWS Jam – チームで課題解決型ハンズオンに挑戦！ (生成 AI 編)」を実施しました。本イベントには、クラウドスキルの向上を目指す 88 名の参加者が、4 名ずつ 22 チームに分かれて参加しました。 今回の AWS Jam イベントは、生成 AI がテーマでした。参加者は Amazon Bedrock や Amazon SageMaker AI などのサービスを活用し、生成 AI モデルの選択や適切なプロンプト設計、推論パラメータの調整など、実践的なスキルを競い合いました。会場は終始活気に満ち、「あ、そういう解決方法があったのか！」「この機能、こんな使い方ができるんですね！」といった声が会場のあちこちから聞こえ、互いのスキルや知見を共有しながら課題を乗り越える姿が印象的でした。 参加者からは「実践的な課題に取り組むことで、座学だけでは得られない気づきがあった」「チームメンバーそれぞれの得意分野を活かして協力できた」といった前向きな感想が多く寄せられ、学びと成長の場として大きな成功を収めることができました。 このブログでは、熱気あふれる当日の様子をより詳しくお伝えするとともに、AWS Jam がどのようにクラウド学習やチームでのスキル共有に役立つのか、また、AWS Jam を実施したい方向けに、AWS Skill Builder やクラスルームトレーニングなどの選択肢についてもご紹介します。 AWS Jam とは AWS Jam は、AWS のユースケースに沿って用意された様々なテーマの課題を解決しながら「AWS を楽しく学ぶ」実践型のイベントです。参加者は AWS やシステム開発の知識や経験を活用し、必要に応じてその場で情報を調べながら、与えられた複数の課題を AWS マネジメントコンソールなどを利用してクリアしていきます。AWS Jam では、課題ごとに獲得得点やヒントが設定されており、時間内にクリアした課題と使用したヒントを総合してチームの得点を競い合います。 AWS Jam には「Play」「Learn」「Validate」の 3 つのコンセプトがあります。 Play (遊ぶ): 得点を競うゲーミング形式のイベントを通じて、楽しみながら課題解決に挑戦します。チーム内でのコミュニケーションの促進にもつながります。 Learn (学ぶ): シナリオに沿った課題を解決することで、AWS サービスの知識やスキルを身につけていきます。普段扱っていない AWS のサービスや機能を新たに学んだり調べたりする機会にもなります。 Validate (検証する): 課題解決を通して、参加者自身の AWS サービスに対するスキルや理解度を確認できます。 また、AWS Jam には生成 AI に関連する課題も多く用意されており、今回の Jam イベントでは、そんな生成 AI に関連する課題を 14 個選択しました。 AWS Jam 実施前のハイライト 今回の AWS Jam では 4 人でチームを組みます。登録時点ではチームは決まっておらず、会場に入場する際にくじ引きでチームを決定しました。ランダムにチームを決定することで、個人で参加する人のハードルを下げ、平等性を保つことを目的としました。 くじ引きを担当するトレノケート 山下さん Jam 実施前の緊張感漂う会場 優勝チームにはトロフィー、2,3 位にはメダルが贈呈される AWS Jam に参加するには、 AWS Skill Builder のアカウントが必要です。開場からイベント開始までの時間を利用して、スタッフがサポートしつつアカウントの準備を行なっていただきました。また、準備が完了したテーブルでは、チームメンバーと自己紹介や雑談をして交流を深めていました。 準備が整ったらオリエンテーション開始です。オリエンテーションでは、AWS Jam のプラットフォーム上でイベントとチームに参加していただき、AWS Jam の紹介とチャレンジへの取り組み方の説明を行いました。 ファシリテーターの AWS テクニカルインストラクター 青木克臣 AWS Jam では、チームでの取り組み方にプラットフォーム上の制約は無く、複数人で相談しながら 1 つずつチャレンジを進めるモブ型や、チーム内で 2 人 1 組になってチャレンジを進めるペア型、手分けして個人でチャレンジを進めるソロ型があります。 本イベントでは、以下の理由からペア型またはモブ型での参加形式を採用しました。 個人ではなく、チームとして AWS Jam イベントを楽しんでいただきたいと考えたため AWS Jam が個人の学習だけでなく、参加者同士のスキル共有の場としても価値があることを体験していただきたいため また、チャレンジに取り組む際には、AWS マネジメントコンソールやノートブックの操作を担当する「操作係」と、指示を出す「指示係」という役割分担をお願いしました。 AWS Jam 開始前にいくつかコツを伝えました。 例えば、ペアワークをうまく進めるコツとして、指示係が指示をする際には、具体的かつ意図まで伝えるようにしましょう (例：「プロンプトを修正しよう」ではなく「生成されたテキストが指定した形式に沿っていないので、プロンプトに具体的な出力形式の指示を追加して、JSON フォーマットで出力されるように修正しよう」や「ここの～」や「そこの～」といった曖昧な表現ではなく、「左上の～と書かれた四角いボタン」「右から3つ目に～」「xxというファイルの10行目のコードの～」など) というような点を伝えました。 また、チームで何かを達成したり、ポイントを獲得したりしたときには、チーム全員で拍手をすることでチームの連帯感を高め、チームでイベントを楽しんでいただけるようにしました。 AWS Jam 実施中の様子 「3、2、1…」カウントダウンの後、AWS Jam がついにスタートしました！ チームで AWS Jam に取り組む時間は 150 分です。AWS Jam が始まると、参加者たちは早速チーム内でペアを決めたり、最初に挑戦するチャレンジを相談したりと、活気に満ちた雰囲気が広がりました。 ペアワークやモブワークでは、画面を操作する「操作係」と、指示やサポートを行う「指示係」に分かれて協力しながらチャレンジに取り組む姿が見られました。 本イベントでは、各チームにモニターとホワイトボードを用意し、モニターには AWS マネジメントコンソールが映し出され、画面を見ながら意見を交わしていました。また、行き詰まった際にはホワイトボードを活用して考えを整理したり、図を描いて問題解決の糸口を探ったりする場面も見受けられました。 初対面のメンバー同士でも、課題を前に自然とコミュニケーションが生まれ、「こちらのサービスを使ってみては？」「このコマンドを試してみよう」と活発な意見交換が行われていました。時には笑い声も聞こえる和やかな雰囲気の中、チーム一丸となって課題解決に取り組む姿が印象的でした。 AWS Jam 実施中の様子 1/4 AWS Jam 実施中の様子 2/4 AWS Jam 実施中の様子 3/4 AWS Jam 実施中の様子 4/4 イベント中に、チャレンジを解決したチームに一言インタビューを実施したところ、「Bedrock に知らない機能があって、学びになった！楽しいです！」「めっちゃ楽しいです。引き続き頑張ります！」など感想をいただきました。 結果発表 激戦の結果、優勝は「Bed6」チーム、2 位が「Typhoon Monkeys」チーム、3 位が「kome」チームとなりました。各チームとも素晴らしいパフォーマンスを見せ、最後まで緊張感が漂う白熱した戦いを繰り広げました。おめでとうございます。 優勝: Bed6 のみなさま 2 位: Typhoon Monkeys のみなさま 3 位: kome のみなさま 上位 3 チームのメンバー AWS Jam のコンソールでは、リーダーボードやスコアリングトレンドがリアルタイムで表示されるため、特に後半では他チームとの得点差に一喜一憂する様子が見られました。「あと 20 点差だ！」「次のチャレンジをクリアすれば逆転できる！」と、競争意識が高まることでチーム内の結束も一層強まっていきました。残り時間が少なくなるにつれて会場の熱気も高まり、最後の最後まで諦めずに挑戦し続けるチームの姿が印象的でした。 実施後のアンケートでは、「Bedrock や SageMaker など、普段使わない分野のサービスを使った実利用例について分かりやすく学べてとても良かった」「JAM楽しかった！」「とても学びが多く楽しかったです」といったコメントを多くいただきました。 組織で AWS のスキルアップを考えている場合には、ぜひ AWS Jam を活用してみてください。組織で AWS Jam を活用する方法は次にご紹介します。 AWS Skill Builder チームサブスクリプションで AWS Jam イベントを実施可能 AWS Skill Builder は 600 を超えるデジタルコースや AWS 認定公式練習問題などが学べるオンライン学習プラットフォームです。また、 チームサブスクリプション を利用すれば、今回の AWS Summit で実施したような AWS Jam イベントをお客様が実施できるようになります。他にもたくさんのチャレンジから好みのチャレンジを選定し、組織内で回数制限なく自由にイベントを開催できます。 AWS Skill Builder サブスクリプションのご案内 のブログに詳細が記載されていますので、併せてご確認ください。 AWS Summit Japan 2025 の AWS Jam イベントは、生成 AI がテーマでした。AWS Jam には生成 AI に関連するチャレンジが多く存在しており、新規開発も進んでいます。(2025/07/04 時点) AWS Summit Japan 2025 で使われたチャレンジの一覧はこちらです。すでに組織で AWS Skill Builder チームサブスクリプションを契約されている場合は、 「AWS Summit Japan 2025」 のチャレンジセット を使用して、ぜひご自身の組織で開催してみてください。 レベル タイトル AWS サービス Easy Unlocking Insights: Understanding the Voice of the Customer Transcribe, Bedrock, Lambda Easy Your Query Whisperer SageMaker AI, Bedrock Easy The Lord Of The RAGs Bedrock, SageMaker AI, Translate Medium Intelligent Recipe Recommendation SageMaker AI, Bedrock Medium GenAI Security: Time for Serious Dialogue Bedrock Medium Silent Minds in the Cloud: No Trespassing Allowed Bedrock, VPC, Lambda Medium Responsible Banking Assistant SageMaker AI, Bedrock Medium Explain Model Decisions SageMaker AI Medium AI-Assisted Application Factory on Amazon Bedrock SageMaker AI, Bedrock, S3, CloudFront Medium Bits, Bytes, and Beyond: Fine-Tuning Expedition SageMaker AI, Lambda Medium Your Data Discovery Guardian Angel Bedrock, SageMaker AI, Redshift Medium Imagine the Impossible SageMaker AI Medium Run your own virtual comics studio powered by multi agents SageMaker AI, Bedrock Hard Keep your Taxbot in check Bedrock, Lambda AWS クラスルームトレーニングで AWS Jam を提供中 AWS クラスルームトレーニングに AWS Jam を追加したコースも提供しています (2025/07/09 時点では個社向けの開催のみです)。こちらを選択していただく利点として、クラスルームトレーニングを受けた後に AWS Jam を受講できるため、 知識をインプットするだけでなく AWS Jam で実践することで、より理解を深めたりスキルとしての検証をしたりできる点があります。さらに、トレーニング企画時に AWS の担当者と相談しながら AWS Jam の実施方法を決めていけるので、以下のような要望も可能です。 Play / Learn / Validate のどのコンセプトを重視するか 知識やスキルの近いメンバーでチームを組むか、均等になるようにチームを組むか モブ型、ペア型、ソロ型など、どんな形式で進めるか また、AWS Summit と同様に AWS の認定インストラクターが実施準備や当日の進行をするため、AWS Jam の用意や進行をするのに不安があるお客様にもおすすめです。 AWS Jam を追加したクラスルームトレーニングはオンラインでもオンサイトでもどちらでも提供可能です。オンラインの利点を活かして、普段は交流の少ないグループ内企業や国際拠点の従業員との交流の場としたり、オンサイトで部署やチーム内のスキル共有の場としてご利用いただいています。どちらもトレーニングでの知識のインプットだけでなく、AWS Jam で実践することで、知識を深めスキルとして検証できたとお客様から満足いただけております。 組織での AWS Jam 活用に興味がある場合は、 AWS トレーニングと認定へのお問い合わせ からご連絡ください。(画面右上で「日本語」を選択し、日本語での問い合わせが可能です) 最後に AWS Jam は、楽しみながら実践的に AWS を学ぶことができるイベントです。今回の AWS Summit Japan でも、熱戦が繰り広げられるとともに、チーム内でのスキル共有や新たな発見に満ちた有意義な時間としていただけました。これからクラウドスキルの向上を目指す方、ただ知識をインプットするだけでなく実践力を鍛えたい方、組織や個人のスキルを検証したい方にとって AWS Jam は最適です。 AWS Jam に挑戦したいと思った方は、AWS Skill Builder や AWS クラスルームトレーニング、AWS のイベント時に開催される機会を利用して AWS Jam に参加してみてください。 おまけ：本イベントでは、AWS トレーニングパートナー所属の AWS 認定インストラクターも運営メンバーとして加わっていました。当日運営をサポートいただいた AWS 認定インストラクターの方々、ありがとうございました。 (敬称略) 株式会社アシスト 木本 佳希 株式会社アシスト 嶋津 絵里子 NECビジネスインテリジェンス 吉田 薫 株式会社NTTデータ先端技術 田中 勇希 クラスメソッド株式会社 平野 文雄 株式会社システムシェアード 天野 盛介 トレノケート株式会社 金井 仁 トレノケート株式会社 久保玉井 純 トレノケート株式会社 髙山 裕司 トレノケート株式会社 山下 光洋 株式会社日立アカデミー 松川 信一郎 株式会社日立システムズ 藤巻 雄裕 株式会社f4samurai 酒井 幹士 ブログの著者 青木 克臣 (Katsuomi Aoki) トレーニングサービス本部 テクニカルインストラクター

2025 年 6 月 25 日、26 日に幕張メッセにて開催された AWS Summit Japan 2025 にご参加いただいた皆様、ありがとうございました。イベントはお楽しみいただけましたでしょうか。 本記事では、Day 2 に開催された、生成 AI をテーマとした AWS GameDay ~ Generative AI Unicorn Party ~ の開催概要と結果をご報告いたします。 図1 : GameDay の イメージスライド AWS GameDay とは？ AWS GameDay は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。3～4 名でチームを結成し、待ち受けるさまざまなトラブルやクエストをクリアしながら最終ミッションの達成を目指します。各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。ゲーミフィケーションされた安全な環境で、楽しみながらさまざまなことを学ぶことができる機会を得られるワークショップです。 開催概要 今回の GameDay は総勢 22 チーム 88 名の方にご参加頂きました。当日のチームは、4 名で構成されるランダムなメンバーで編成されました。GameDay で高スコアを生み出す秘訣としてチームプレイ・連携が重要であることがアナウンスされ、ゲームの開始時間までにチームビルディングとして自己紹介、得意分野や経験領域の共有、名刺交換などが行われていました。 図2 : オープニングの様子 シナリオ概要 今回のゲームシナリオとして採用された “Generative AI Unicorn Party” では、架空のテクノロジースタートアップであるユニコーンレンタル社の新入社員説明会のシーンから始まりました。 図3 : オープニング説明の様子 オープニングにてCEOは、”ユニコーンレンタルの事業にAIを活用したサービスを提供することで、新しい体験をお客様に提供できるのではないかと考え、Generative AI Unicorn Party という、全く新しい生成 AI を活用したサービスを発表しました。しかしユニコーンレンタル社には十分な AI の知見者が足りておらず、このサービスは発展途上です。そこで AI や機械学習、データサイエンスに詳しい技術者である参加者の皆様に、今回のこの新しいサービスの発展と問題の解決にいただきたい。”と語りました。今回は参加者の皆様に、AWS の 生成 AI サービスを用いてミッションに取り組んで頂きました。ミッションの中では、 PartyRock を用いて生成 AI アプリケーションを作成したり、 Amazon Q Developer を活用したデバッグ、Amazon Bedrock の Guardrails や Agents を用いた高度な生成 AI アプリケーションの構築を体験いただきました。 ゲーム中の様子 皆様、GameDay ワークショップの内容に集中しつつも、楽しんで取り組んでいる様子でした。 図4 : GameDay 開催中の様子 今回の GameDay では、 Amazon Q Developer の力を借りながら問題に取り組むことができることもあって、多くのチームが問題を解けており、点数についてもかなり接戦であったように感じました。 図5 : 最終スコアボード 結果 結果は以下の通りでした。 第 1 位 Team ECS（小林 直樹 氏, 芦田 遼太 氏,(匿名希望) 氏, 陶 金 氏) / スコア : 234,099 図6 : 第1位 Team ECS のメンバー 第 2 位 ずんだもん（松岡 文雄 氏, 島川 寿希也 氏, 小野 綾介 氏, 平井 友樹 氏) / スコア : 214,254 図7 : 第2位 ずんだもん のメンバー 第 3 位 Bedrock Brothers（福元 駿汰 氏, 中野 勇一 氏, 大脇 遼 氏, 大橋 直弥 氏) / スコア : 206,996 図8 : 第3位 Bedrock Brothers のメンバー 上位入賞おめでとうございます。上位 3 チームの皆様には、メダルとぬいぐるみが進呈されました。 図9 : メダルとぬいぐるみ 優勝チームからは「 我々のチームには５人目のメンバーがいました。それは Amazon Q Developer です。 」と、本来4人チームのところに、 Amazon Q Developer を5人目のメンバーとして加えていただけたという、ありがたいコメントもあり、会場は大きく盛り上がりました。 その他の参加者の方々からも、以下のようなコメントをいただきました： 「Amazon Bedrock をフルに活用したアプリケーションの実装を体感できた」 「生成 AI 周りのキャッチアップする良い機会になった」 「周りの方と協力して進めることができて、楽しかった」 「普段触らないサービスに触れることができとても勉強になりました」 「Amazon Q Developer に ECS の作成をお願いしたら全部やってくれた」 皆様が Amazon Q Developer を早くも使いこなされていたこともあり、「 Amazon Q Developer が課題解決に大きく役立った」というコメントが多く見受けられ、生成 AI を活用した開発の現在地を知る機会になったようでした。 また、当日ランダムで編成されたチームメンバーとのコミュニケーションが刺激になったというコメントが多く寄せられました。このような交流ができることも GameDay の醍醐味だと思います。 図10 : GameDay 終了後の集合写真 最後に ご参加いただいた皆様、ありがとうございました。 生成 AI 領域の進歩は目まぐるしく、すでに従来の開発のあり方を大きく変えつつあるなかで、GameDay の中で 楽しみながら Amazon Q Developer を利用していただいたことで、その可能性を感じていただけたのではないかと思います。 今回惜しくも入賞を逃したチームの皆様、もしくは参加してみたい！と思ったエンジニアの皆様、今後もさまざまなイベントで GameDay の開催を予定していますので、機会を見かけましたら奮ってご挑戦ください。 それでは、また来年の AWS Summit Japan でお会いできることを楽しみにしています！ 著者について 大磯 直人（Naoto Oiso） Solutions Architect

7 月 9 日、 Amazon Elastic Compute Cloud (Amazon EC2) P6e-GB200 UltraServers の一般提供をお知らせします。この製品は NVIDIA GB200 NVL72 によって強化されており、AI トレーニングと推論向けに最高の GPU パフォーマンスを提供します。 Amazon EC2 UltraServers は、複数の EC2 インスタンス間で高帯域幅かつ低レイテンシーの専用アクセラレータインターコネクトを使用して、これらのインスタンスを接続します。 NVIDIA Grace Blackwell Superchip は、NVIDIA NVLink-C2C インターコネクトを使用して、2 つの高性能 NVIDIA Blackwell テンソルコア GPU と Arm アーキテクチャベースの NVIDIA Grace CPU を接続します。各 Grace Blackwell Superchip は、10 ペタフロップスの FP8 コンピューティング (スパース性なし) と最大 372 GB の HBM3e メモリを搭載しています。Superchip アーキテクチャでは、GPU と CPU が 1 つのコンピューティングモジュール内に配置されるため、現世代の EC2 P5en インスタンス と比較して、GPU と CPU 間の帯域幅が大幅に増加します。 EC2 P6e-GB200 UltraServers を使用すると、1 つの NVLink ドメイン内で最大 72 個の NVIDIA Blackwell GPU にアクセスして、360 ペタフロップスの FP8 コンピューティング (スパース性なし) と合計 13.4 TB の高帯域幅メモリ (HBM3e) を使用できます。 AWS Nitro System を搭載した P6e-GB200 UltraServers は、EC2 UltraClusters にデプロイされ、数万台の GPU まで安全かつ確実にスケーリングできます。 EC2 P6e-GB200 UltraServers は、合計で最大 28.8 Tbps の Elastic Fabric Adapter (EFAv4) ネットワーキングを実現します。また、EFA は NVIDIA GPUDirect RDMA と組み合わされているため、オペレーティングシステムのバイパスを使用してサーバー間の GPU から GPU への通信を低レイテンシーで実現できます。 EC2 P6e-GB200 UltraServers の仕様 EC2 P6e-GB200 UltraServers は、NVLink で 36 個から 72 個の GPU のサイズでご利用いただけます。EC2 P6e-GB200 UltraServers の仕様は次のとおりです。 UltraServer タイプ GPU GPU メモリ (GB) vCPU インスタンスメモリ (GiB) インスタンスストレージ (TB) EFA ネットワークの総帯域幅 (Gbps) EBS 帯域幅 (Gbps) u-p6e-gb200x36 36 6660 1296 8640 202.5 14400 540 u-p6e-gb200x72 72 13320 2592 17280 405 28800 1080 P6e-GB200 UltraServers は、エキスパートモデルと推論モデルの混合を含む、1 兆パラメータスケールでのフロンティアモデルのトレーニングや推論など、コンピューティングとメモリを非常に多く消費する AI ワークロードに最適です。 質問応答、コード生成、動画と画像の生成、音声認識などを含む、エージェンティック AI および 生成 AI アプリケーションを構築できます。 動作中の P6e-GB200 UltraServers ダラスローカルゾーンの EC2 P6e-GB200 UltraServers は、 ML 用 EC2 キャパシティブロック を通じてご利用いただけます。ダラスローカルゾーン ( us-east-1-dfw-2a ) は、米国東部 (バージニア北部) リージョンの延長です。 EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で、 [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 u-p6e-gb200x36 または u-p6e-gb200x72 UltraServers 用の EC2 キャパシティブロックが必要な期間を指定します。 キャパシティブロックのスケジュールが正常に設定されると、事前に請求が行われ、購入後も料金は変わりません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 機械学習用のキャパシティブロック 」を参照してください。 購入したキャパシティブロック内では、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用してインスタンスを実行できます。ソフトウェア側では、 AWS Deep Learning AMI を使用して開始できます。これらのイメージは、お客様がおそらく既にご存知であり、使用しているフレームワークとツール (PyTorch、JAX など) で事前設定されています。 また、EC2 P6e-GB200 UltraServers をさまざまな AWS マネージドサービスとシームレスに統合することも可能です。例: Amazon SageMaker Hyperpod は、P6e-GB200 UltraServers のプロビジョニングと管理を自動的に処理する、耐障害性の高いマネージド型のインフラストラクチャを提供し、障害が発生したインスタンスを同一 NVLink ドメイン内の事前設定済みの予備キャパシティに置き換えて、パフォーマンスを維持します。 Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、1 つのマネージドノードグループをノードとして複数の P6e-GB200 UltraServer 間で使用し、Kubernetes クラスター内のプロビジョニングとライフサイクル管理を自動化することができます。P6e-GB200 UltraServers では EKS トポロジ対応ルーティングを使用できるため、分散ワークロードの緊密に結合されたコンポーネントを、単一の UltraServer の NVLink 接続インスタンス内に最適に配置することが可能です。 Amazon FSx for Lustre ファイルシステムは、大規模な HPC および AI ワークロードに必要となる数百 GB/秒のスループットと、数百万回の 1 秒あたりの入出力オペレーション (IOPS) で、P6e-GB200 UltraServers のデータアクセスを提供します。大規模なデータセットにすばやくアクセスするには、最大 405 TB のローカル NVMe SSD ストレージを使用するか、 Amazon Simple Storage Service (Amazon S3) で費用対効果の高い事実上無制限のストレージを使用することができます。 今すぐご利用いただけます Amazon EC2 P6e-GB200 UltraServers は現在、 ML 用 EC2 キャパシティブロック を通じてダラスローカルゾーン ( us-east-1-dfw-2a ) でご利用いただけます。詳細については、 Amazon EC2 の料金ページ を参照してください。 Amazon EC2 コンソール で Amazon EC2 P6e-GB200 UltraServers をぜひお試しください。詳細については、 Amazon EC2 P6e インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

AWS では、ビルダーの皆様を心から大切に思っています。弊社は、技術コミュニティの活性化を支援する新しい方法を常に模索し、AWS Developer Center や community.aws など、人々がつながり、知識や経験を共有できる場を創出しています。 7 月 9 日、ビルダーの皆様がすべてのビルダーリソースにアクセスし、AWS コミュニティと交流して、AWS 製品チームにフィードバックや製品の提案を提供するための新しいプラットフォームである AWS Builder Center を発表しました。また、この新しいエクスペリエンスは、従来の AWS Developer Center と community.aws を統合します。 エキサイティングな機能が幅広く用意されています。さっそくいくつか見てみましょう。 皆様の声が重要です: ウィッシュリストのご紹介 個人的に最もエキサイティングな新機能の 1 つは、 ウィッシュリスト です。AWS サービスで実現してほしい新機能や改善点について、皆様のご要望をお寄せいただけるようになりました。他のビルダーは、これらの要望を見つけて投票するだけでなく、独自の要望を作成することもできます。 コミュニティとして製品ロードマップに共同で影響をもたらし、弊社が AWS サービスの未来を形作るのをサポートしていただけます。AWS サービスの運用中に、アイデア、提案、機能の提案、課題を共有できます。また、AWS コミュニティは、アイデアに賛成票を投じたり、極めて要望の多い改善点をハイライト表示できます。当社の社内チームがこれらの要望に目を通し、極めて多く寄せられた要望をサービスチームに伝達して、皆様の声を製品開発プロセスの不可欠な要素として活用します。 AWS コミュニティで人々とつながる [つながる] ページでは、 AWS ヒーロー や AWS コミュニティビルダー と直接つながる機会が数多くあります。世界中で、皆様が所在する都市の近くにある AWS User Groups や AWS Cloud Clubs を探して参加できます。 さらに、このページをブックマークして、今後のコミュニティイベントを見つけるための一元的なハブとして使用できます。これにより、皆様が所在している地域で学習やネットワーキングの機会を見つけたり、同じ関心を持ち、志を同じくするビルダーと出会ったりすることが簡単になります。 人々をフォローすることについて言えば、AWS Builder Center は AWS テクニカルコミュニティの中心ハブとして機能し、他のビルダーと非常に簡単につながったり、交流したりできるようにします。他のビルダーとつながるためのさまざまな方法が備わっています。例えば、 [フォローする人] セクションでは、AWS ヒーロー、コミュニティビルダー、関心のある領域で知識と専門知識を共有しているアクティブなコミュニティメンバーをご紹介しています。 AWS ハンズオンリソースを探す [構築] ページでは、 AWS チュートリアル や AWS ワークショップ など、あらゆるスキルレベル向けに設計されたインタラクティブな学習リソースを含め、ハンズオン体験を通じて AWS に慣れ親しむための方法を見つけることができます。生成 AI およびエージェンティック AI サービスのプレイグラウンドを探索し、 AWS 無料利用枠 を見つけて、各サービスについて指定された制限まで AWS サービスを無料でお試しいただけます。 [ツールボックス] ページを選択すると、AWS 向けの最新のツール、プログラミング言語リソース、オープンソースプロジェクトを見つけることができます。[ツールボックス] には、プロジェクトのスキャフォールディングと実行に必要なものがすべて揃っています。 弊社は、ビルダーのビルドエクスペリエンスを改善するため、特定のトピックで共同作業するための専用グループやフォーラムの作成、ハンズオンラボ用のワークショップの開催、ビルダーが AWS サービスを自由に実験できるさまざまなサービスプレイグラウンドなど、Builder Center の組み込みオファリングを拡張する予定です。 ビルダージャーニーのサポート 新しい [学習] セクションは、スキル開発への入口として機能し、AWS の専門知識を広げるために必要なあらゆるものをご用意しています。ここでは、学習およびトレーニングリソース、ワークショップ、ゲーム化された体験など、AWS での構築ジャーニーを教育的かつ魅力的なものにするためのさまざまなリソースを探索できます。 [トピック] ページを選択すると、さらに多くのコンテンツを探索して見つけることができます。トピックとタグでコンテンツを探索できます。注目のトピックやトレンドのトピックのセクションがあり、コミュニティで今注目を集めている情報に常に触れているようにするのに役立ちます。 皆様の言語に対応した組み込みローカリゼーション AWS Builder Center は、包括的なローカリゼーションサポートで、言語の壁を打破します。Builder Center で公開されるすべてのコンテンツは、自動的に 16 の言語で利用可能になります。また、投稿、コメント、ご要望などのユーザー生成コンテンツは、 [翻訳] を使用してオンデマンドで機械翻訳できます。そのため、世界中のビルダーとコラボレーションし、言語の壁を越えて知識や経験を共有できます。 デフォルトでは、すべてのコンテンツはブラウザで設定されている言語に基づいて表示されます。しかし、設定ページにアクセスして AWS Builder Center がデフォルトで使用する言語を選択することにより、この設定を変更できます。 今すぐサインアップしてプロフィールを作成しましょう AWS Builder Center は、AWS ジャーニーを紹介するための、よりパーソナライズされた包括的な手段を提供します。自分独自のプロフィールには、カスタム URL と共有可能な QR コードがあります。これにより、簡単に他のビルダーとつながり、AWS コミュニティであなたの存在を共有できます。 投稿、ご要望、意義深いやり取りはすべて一元化されたビュー内で整理され、簡単に確認できます。 [プロフィールを管理] ページで、プロフィールをカスタマイズし、特定の関心や専門領域を追加することで、同じ情熱を持つビルダーとつながるのに役立ちます。プロフィールの管理はシームレスです。AWS ビルダー ID を使用してすべての AWS サービス間で同期するため、AWS オファリングを利用する際に、ID の一貫性が確保されます。 builder.aws.com にアクセスし、AWS ビルダー ID でサインアップして、自分独自のエイリアスを取得することで、コンテンツ作成、ウィッシュリスト、コミュニティエンゲージメントツールなど、すべての機能にアクセスできます。 AWS Builder Center は、他の AWS ビルダーとつながり、学び、構築するのに役立つよう設計されています。ぜひ一緒にジャーニーを楽しみましょう! – Channy &  Matheus Guimaraes | @codingmatheus 原文は こちら です。

7 月 8 日、AWS 内で Oracle Real Application Clusters (RAC) を含む Oracle Exadata ワークロード向けの新しいオファリングである Oracle Database@AWS の一般提供の開始を発表しました。 お客様は過去 14 年間にわたって、 Amazon Elastic Compute Cloud (Amazon EC2) を使用してクラウド内で Oracle データベースワークロードをセルフマネージドで管理するか、フルマネージドの Amazon Relational Database Service (Amazon RDS) for Oracle を使用するかを選択できました。今後は、Oracle RAC または Oracle Exadata を必要とするワークロード向けに、より迅速かつシンプルなクラウド移行を実現するための追加のオプションをご利用いただけます。また、お客様は、AWS Marketplace を通じて単一の請求書を受け取ります。これは、AWS とのコミットメントや Oracle ライセンス特典 (Bring Your Own License (BYOL) や Oracle Support Rewards などの割引プログラムを含む) にカウントされます。 Oracle Database@AWS を利用すると、変更を最小限に抑えながら、AWS 内で、Oracle Exadata ワークロードを Oracle Exadata Database Service on Dedicated Infrastructure または Oracle Autonomous Database on Dedicated Exadata Infrastructure に移行できます。お客様は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS API などの使い慣れた AWS ツールとインターフェイスを通じて、Oracle Database@AWS デプロイを購入、プロビジョニング、管理できます。AWS API は、リソースをプロビジョニングおよび管理するために必要な、対応する Oracle Cloud Infrastructure (OCI) API を呼び出します。 2024 年 12 月の プレビュー 以降、一般提供が開始される際に、本番ワークロードを実行するのに役立つよう、弊社は機能を改善したり、追加したりしてきました: リージョンレベルの拡大 –  7 月 8 日より、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンで Oracle Database@AWS をご利用いただけるようになりました。また、世界中の 20 の AWS リージョンに拡大する計画も発表しました。このより幅広い可用性は、さまざまな地理的エリアのお客様の多様なニーズをサポートするため、より多くの企業がこのオプションから恩恵を享受できます。AWS リージョンのワークロード要件に合わせて、さまざまな Exadata システムサイズからお選びいただけます。 ゼロ ETL と S3 バックアップ – 分析のために Amazon Redshift との ゼロ ETL 統合 から恩恵を享受できるようになりました。これは、抽出、変換、ロードオペレーションのためのデータパイプラインを構築および管理する必要性をなくします。ゼロ ETL により、ネットワーク間のデータ転送コストを発生させることなく、AWS 上のデータを統合できます。最大でイレブンナインのデータ耐久性を備えた Amazon Simple Storage Service (Amazon S3) バックアップを提供しています。 Autonomous VM クラスター – Exadata Dedicated Infrastructure 上で、Exadata VM クラスターに加えて Autonomous VM クラスターをプロビジョニングできるようになりました。コミットされたハードウェアおよびソフトウェアリソースを使用するフルマネージドデータベース環境である Oracle Autonomous Database on Dedicated Exadata Infrastructure を実行できます。 また、Oracle Database@AWS は、 Amazon Virtual Private Cloud (Amazon VPC) Lattice (S3 や Redshift などの AWS サービスへのネットワークパスを直接設定するため)、 AWS Identity and Access Management (IAM) (認証と認可のため)、 Amazon EventBridge (データベースライフサイクルイベントをモニタリングするため)、 AWS CloudFormation (インフラストラクチャオートメーションのため)、 Amazon CloudWatch (メトリクスを収集およびモニタリングするため)、 AWS CloudTrail (API オペレーションをログ記録するため) などの他の AWS サービスと統合します。 Oracle Database@AWS の開始方法 Oracle Database@AWS は、AWS データセンター内で、Oracle Exadata Database Service on Dedicated Infrastructure と Oracle Autonomous Database on Dedicated Exadata Infrastructure という 2 つの主要サービスをサポートしています。 これらのサービスは、物理的には AWS リージョンのアベイラビリティーゾーン内に存在し、論理的には OCI リージョンに存在するため、高速かつ低レイテンシーの接続を通じて AWS サービスとのシームレスな統合を実現できます。 Oracle Exadata VM クラスターをアベイラビリティーゾーン内でホストする、プライベートで分離されたネットワークである ODB ネットワークを作成します。その後、VPC で実行されている EC2 アプリケーションサーバーにアクセスできる ODB ピアリングを使用します。詳細については、AWS ドキュメントの「 How Oracle Database@AWS works 」にアクセスしてください。 AWS Marketplace でプライベートオファーをリクエストする Oracle Database@AWS のジャーニーを開始するには、 AWS コンソール にアクセスするか、または AWS Marketplace のプライベートオファー をリクエストしてください。AWS と Oracle の営業チームがお客様のリクエストを受け取り、お客様のワークロードに最適なオプションを見つけるためにお客様にご連絡し、アカウントをアクティブ化します。 Oracle Database@AWS をアクティブ化してアクセスできるようになったら、 [ダッシュボード] を使用して、ODB ネットワーク、Exadata インフラストラクチャ、Exadata VM クラスターまたは Autonomous VM クラスター、および ODB ピアリング接続を作成できます。 詳細については、AWS ドキュメントの「 Onboarding to Oracle Database@AWS 」と「 AWS Marketplace buyer private offers 」にアクセスしてください。 ODB ネットワークを作成する ODB ネットワークは、AWS 上で OCI インフラストラクチャをホストする分離されたプライベートネットワークです。ODB ネットワークは、OCI の子サイト内に存在するネットワークに直接マッピングするため、AWS と OCI の間の通信手段として機能します。 [ダッシュボード] で、 [ODB ネットワークを作成] を選択し、ネットワーク名を入力し、アベイラビリティーゾーンを選択して、アプリケーションによって確立されるクライアント接続と、自動バックアップの実行に使用されるバックアップ接続の CIDR 範囲を指定します。また、ドメイン ( oraclevcn.com に固定されています) のプレフィックスとして使用する名前を入力することもできます。例えば、 myhost と入力した場合、完全修飾ドメイン名は myhost.oraclevcn.com となります。 オプションで、ODB ネットワークアクセスを設定して、Amazon S3 への自動バックアップとゼロ ETL を実行し、Amazon Redshift を利用して Oracle データに対するほぼリアルタイムの分析と ML を実現できます。 ODB ネットワークを作成したら、EC2 アプリケーションサーバーの VPC ルートテーブルを、ODB ネットワークのクライアント接続 CIDR で更新します。詳細については、AWS ドキュメントの「 ODB network 」、「 ODB peering 」、「 Configuring VPC route tables for ODB peering 」にアクセスしてください。 Exadata インフラストラクチャを作成する Oracle Exadata インフラストラクチャは、Oracle Exadata データベースを実行するデータベースサーバー、ストレージサーバー、およびネットワーキングの基盤となるアーキテクチャです。 [Exadata インフラストラクチャを作成] を選択し、名前を入力して、デフォルトのアベイラビリティーゾーンを使用します。次のステップでは、Exadata システムモデルとして [Exadata.X11M] を選択できます。また、データベースサーバーは、デフォルトで 2 台、最大で 32 台設定でき、ストレージサーバーは、デフォルトで 3 台、最大で 64 台設定できます (サーバーあたりのストレージ容量は 80 TB)。 最後に、スケジュール設定、パッチ適用モード、OCI メンテナンス通知の連絡先など、システムメンテナンスの詳細設定を構成できます。AWS コンソールからインフラストラクチャを作成した後、そのインフラストラクチャを変更することはできません。ただし、OCI コンソールに移動して変更することは可能です。 Exadata インフラストラクチャを削除するには、AWS ドキュメントの「 Deleting an Oracle Exadata infrastructure in Oracle Database@AWS 」にアクセスしてください。 Exadata VM クラスターまたは Autonomous VM クラスターを作成する Exadata インフラストラクチャ上に VM クラスターを作成し、同じ ODB ネットワーク内に異なる Oracle Exadata インフラストラクチャを持つ複数の VM クラスターをデプロイできます。 VM クラスターには次の 2 つのタイプがあります: Exadata VM クラスターは、Oracle Enterprise Edition のすべての機能を含む完全な Oracle データベースがインストールされた仮想マシンのセットです。 Autonomous VM クラスターは、人間による介入を必要とせずに、AI/ML を利用して主要な管理タスクを自動化するフルマネージドデータベースのセットです。 [Exadata VM クラスターを作成] を選択し、VM クラスター名とタイムゾーンを入力して、ライセンスオプションとして Bring Your Own License (BYOL) またはライセンス込みを選択します。次のステップでは、Exadata インフラストラクチャ、グリッドインフラストラクチャのバージョン、および Exadata イメージのバージョンを選択できます。データベースサーバーについては、各 VM の CPU コア数、メモリ、ローカルストレージを選択するか、またはデフォルトをそのまま使用できます。 次のステップでは、ODB ネットワークを選択し、VM クラスターのプレフィックスを入力することで、接続設定を構成できます。単一クライアントアクセス名 (SCAN) リスナーに対する TCP アクセス用のポート番号を入力できます。デフォルトのポートは 1521 ですが、1024～8999 の範囲でカスタム SCAN ポートを入力することもできます。SSH キーペアについては、VM クラスターに対する SSH アクセスのために使用する 1 つ以上のキーペアのパブリックキーの部分を入力します。 その後、診断とタグを選択し、設定を確認して、VM クラスターを作成します。作成プロセスには、VM クラスターのサイズに応じて最大 6 時間かかる場合があります。 Oracle データベースを作成および管理する VM クラスターの準備ができたら、OCI コンソールで Oracle Exadata データベースを作成および管理できます。Exadata VM クラスターの詳細ページで、 [OCI で管理] を選択します。OCI コンソールにリダイレクトされます。 OCI コンソールで Oracle Database を作成する際、Oracle Database 19c または 23ai を選択できます。プロビジョンドデータベースのために自動バックアップを有効にする際に、OCI リージョンの S3 バケットまたは OCI Object Storage を使用できます。詳細については、OCI ドキュメントの「 Provision Oracle Exadata Database Service in Oracle Database@AWS 」にアクセスしてください。 知っておくべきこと Oracle Database@AWS についていくつか知っておくべきことを次に示します: モニタリング – VM クラスター、コンテナデータベース、プラガブルデータベースの AWS/ODB 名前空間にある Amazon CloudWatch メトリクスを使用して、Oracle Database@AWS をモニタリングできます。AWS CloudTrail は、Oracle Database@AWS のすべての AWS API コールをイベントとしてキャプチャします。CloudTrail ログを使用すると、Oracle Database@AWS に対して実行されたリクエスト、リクエストの実行元の IP アドレス、リクエストの実行日時、および他の詳細を確認できます。詳細については、「 Monitoring Oracle Database@AWS 」にアクセスしてください。 セキュリティ – IAM を使用して許可を割り当てて、Oracle Database@AWS リソースを管理することが許可されるユーザーを決定できるほか、SSL/TLS 暗号化接続を使用してデータのセキュリティを確保できます。また、シームレスなイベントドリブンのデータベースオペレーションのために、 Amazon EventBridge を利用することもできます。これらはすべて連携して、効率的なクラウド運用を実現しながら、セキュリティ標準を維持します。詳細については、「 Security in Oracle Database@AWS 」にアクセスしてください。 コンプライアンス – Oracle Database@AWS を利用する際のコンプライアンスに関する責任は、データの機密性、お客様の企業のコンプライアンスに関する目標、ならびに適用される法令および規制によって決まります。当社は、Oracle Database@AWS で次のコンプライアンスを提供しています: SOC 1、SOC 2、SOC 3、HIPAA、C5、CSA STAR Attest、CSA STAR Cert、HDS (フランス)、ISO シリーズ (ISO/IEC 9001、20000-1、27001、27017、27018、27701、22301)、PCI DSS、HITRUST。詳細については、「 Compliance validation for Oracle Database@AWS 」にアクセスしてください。 サポート – AWS または Oracle の営業担当チームは、お客様の現在のデータベースインフラストラクチャの評価、Oracle Database@AWS がお客様の組織の要件をどのように最良に満たすことができるのかを明らかにすること、カスタマイズされた移行戦略とタイムラインの策定をサポートできます。また、AWS クラウドで実行される Oracle ベースのワークロードの設計、デプロイ、管理に特化した AWS Oracle コンピテンシーパートナー からのサポートを受けることもできます。 一般提供の開始と近日中に予定されている提供の開始 Oracle Database@AWS は、AWS Marketplace を通じて、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけるようになりました。Oracle Database@AWS の料金および AWS Marketplace のプライベートオファーは、Oracle によって設定されます。このオファリングについての料金に関する詳細は、 Oracle の料金ページ でご覧いただけます。 Oracle Database@AWS は、南北アメリカ、欧州、アジアパシフィックの 20 超の AWS リージョンに拡大される予定です。これには、次が含まれます: 米国東部 (オハイオ)、米国西部 (北カリフォルニア)、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、南米 (サンパウロ)。 Oracle Database@AWS は、 AWS コンソール を使用して開始できます。詳細については、「 Oracle Database@AWS ユーザーガイド 」および OCI ドキュメント にアクセスしてください。また、通常の AWS サポートの連絡先または OCI サポート を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

毎週月曜日に、先週注目されたベストリリースとブログについてお伝えします。 この AWS Weekly Roundup を続ける前に、6 月、私は家族と一緒にカリフォルニア州サンフランシスコに引っ越し、Developer Advocate/SDE, GenAI としての新しい役割を始めたことをお伝えしたいと思います。 私はこれにワクワクしています。エキサイティングな新しい課題に取り組みながら、ベイエリアの新しいコミュニティとつながる機会があるからです。あなたが生成 AI とエージェンティックアプリケーションの構築に焦点を当てたコミュニティに参加している方か、それをご存知の方であれば、ぜひつながりたいと思います。 つながりましょう ! 6 月 30 日週のリリース 6 月 30 日週のリリースは次のとおりです: AWS Graviton4 を搭載した新しい Amazon EC2 C8gn インスタンスが最大 600 Gbps のネットワーク帯域幅を提供 – AWS Graviton4 プロセッサと第 6 世代 AWS Nitro Card を搭載した Amazon Elastic Compute Cloud (Amazon EC2) の C8gn インスタンスが一般公開されました。これらのネットワーク最適化インスタンスは、最大 600 Gbps のネットワーク帯域幅を提供します。これは、EC2 のネットワーク最適化インスタンスの中で最も高い帯域幅を表し、最大 192 個の vCPU と 384 GiB のメモリを備えています。C7gn インスタンスよりも 30% 高いコンピューティングパフォーマンスを提供し、仮想アプライアンス、データ分析、クラスターコンピューティングジョブなどのネットワーク集約型ワークロードに最適です。 Amazon DynamoDB グローバルテーブルで、マルチリージョン強整合性を利用して、最も耐障害性の高いアプリケーションを構築 – Amazon DynamoDB グローバルテーブルは、ゼロの目標復旧時点 (RPO) を必要とするアプリケーションのマルチリージョン強整合性 (MRSC) をサポートするようになりました。この機能により、システム停止中もアプリケーションはどのリージョンからでも最新データを読み取ることができ、支払い処理や金融サービスにおける重要なニーズに対応できます。MRSC では 3 つの AWS リージョンを 3 つのフルレプリカまたは 2 つのレプリカとウィットネスとして設定する必要があり、それによりミッションクリティカルなワークロードに最高レベルのアプリケーションの耐障害性を提供します。 Amazon Nova Canvas の更新: 仮想試着とスタイルのオプションが利用可能になりました – Amazon Nova Canvas では、2 つの画像を組み合わせて衣服が人にどのように見えるかを視覚化する仮想試着機能に加えて、芸術的な一貫性が向上した画像を生成するための 8 つの新しいトレーニング済みスタイルオプション (3D アニメーション、デザインスケッチ、ベクトルイラスト、グラフィックノベルなど) が導入されました。3 つの AWS リージョンで利用可能なこれらの機能は、現実的な製品の視覚化を求める小売業者やコンテンツ作成者向けに、AI を活用した画像生成機能を強化します。 Amazon Q in Connect では、プロアクティブな レコメンデーション のために 7 つの言語がサポートされるようになりました – Amazon Q in Connect は、生成 AI を搭載したカスタマーサービス用のアシスタントで、英語、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語の 7 つの言語でプロアクティブなレコメンデーションを提供するようになりました。AI を搭載したカスタマーサービスアシスタントは、音声やチャットでのやり取り中に顧客の意図を検出し、エージェントが問題を迅速かつ正確に解決できるようにします。 Amazon Aurora MySQL と Amazon RDS for MySQL を Amazon SageMaker と統合できるようになりました – この統合により、分析用のデータをほぼリアルタイムで利用できるようになります。MySQL データを Apache Iceberg 互換のレイクハウスに自動的に抽出します。その後、さまざまな分析エンジンや機械学習ツールを使用して、このデータにシームレスにアクセスできます。 Amazon Aurora DSQL が追加の AWS リージョンで利用できるようになりました – Amazon Aurora DSQL はアジアパシフィック (ソウル) にも拡大し、アジアパシフィックリージョンと欧州リージョン全体でマルチリージョンクラスターをサポートするようになりました。このサーバーレスの分散型 SQL データベースは、無制限のスケーラビリティ、最高の可用性を実現し、AWS 無料利用枠でインフラストラクチャを管理する必要がありません。 その他の AWS ブログ記事 Amazon SageMaker JumpStart と Amazon OpenSearch Service を使用して本番環境で RAG を最適化 – Amazon SageMaker JumpStart と Amazon OpenSearch Service を使用して本番環境で検索拡張生成 (RAG) を最適化する方法を学びましょう。この包括的なガイドでは、LangChain による RAG ワークフローの実装を示し、OpenSearch 最適化戦略について説明し、セットアップ手順を提供し、これらの AWS のサービスを組み合わせてスケーラブルで費用対効果の高い生成 AI アプリケーションを実現するメリットについて説明します。 EKS 上の Bedrock、MCP サーバーを使用するエージェンティック GenAI アプリケーション – この投稿では、Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされた Amazon Bedrock、Strands Agent、およびモデルコンテキストプロトコル (MCP) サーバーを使用してスケーラブルな AI チャットアプリケーションを構築する方法を示します。このアーキテクチャでは、エージェントワークフローとコンテナ化されたマイクロサービスを組み合わせて、複数の基盤モデルとのインテリジェントな自動スケーリング会話を実現します。 AWS Lake Formation で AWS Glue 5.0 を使用してデータレイクテーブルにテーブルレベルのアクセスコントロールを適用 – AWS Glue 5.0 では、AWS Lake Formation による Apache Spark のフルテーブルアクセス (FTA) コントロールが導入され、きめ細かなアクセスオーバーヘッドなしでテーブルレベルのセキュリティを実現できます。この機能は、レイクフォーメーションテーブル用のネイティブ Spark SQL/DataFrames をサポートします。これにより、Iceberg および Hive テーブルでの読み取り/書き込み操作が可能になり、パフォーマンスが向上し、コストが削減されます。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルは、 All Builders Welcome Grant プログラム に申し込むことができます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。現在、申し込みを受け付けており、2025 年 7 月 15 日に締め切ります。 AWS NY Summit – コンピューティング、ストレージ、生成 AI における最新かつ最新鋭の AWS テクノロジーに焦点を当てた Swami の基調講演からインサイトを得ることができます。ニュースブログチームもエキサイティングなニュースをいくつか用意しています。直接参加できない場合でも、 グローバルライブストリームに登録 して参加することが可能です。また、最寄りの都市で 7 月と 8 月に開催される予定の Summit の日付も確認しておきましょう。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 AWS Gen AI Lofts に参加する – サンフランシスコ、ベルリン、ドバイ、ダブリン、バンガロール、マンチェスター、パリ、テルアビブ、およびその他の場所で AWS Gen AI Lofts を体験してください。実践的なワークショップ、専門家によるガイダンス、投資家向けネットワーキング、コラボレーションスペースなどがあり、生成 AI スタートアップのジャーニーを加速させるように設計されています。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 7 月 7 日週のニュースは以上です。7 月 14 日週の月曜日に再びアクセスして、新たな Weekly Roundup をぜひお読みください! –  Eli 原文は こちら です。

本稿は、2025 年 7 月 2 日に公開された “ Boost application performance: Amazon CloudFront enables HTTPS record ” を翻訳したものです。 Amazon CloudFront は、グローバルネットワーク全体で Amazon Route 53 の HTTPS DNS エイリアスレコードをサポートすることを発表しました。この機能でクライアントは、その後の接続ステップではなく、最初の DNS 解決フェーズで最適な HTTP プロトコルを見つけることができます。これにより、ユーザーはパフォーマンスとセキュリティを向上させると同時に、運用コストを削減できます。 この記事では、実装の詳細、パフォーマンスの向上、およびこの機能の設定方法について説明します。 DNS HTTPS レコード HTTPS レコードは、 RFC 9460 で定義されているサービスバインディング (SVCB) DNS レコードの特殊な形式です。これらのレコードタイプは、安全なインターネット接続の柔軟性を高め、信頼性と速度を向上させます。HTTPS レコードは、接続の確立に必要なラウンドトリップ回数を減らし、将来のプロトコルアップグレードをサポートすることでこれを実現しています。 HTTPS DNS レコードは、特定のドメインで利用できるサービスについて、他のレコードタイプ (A や AAAA など) よりも詳細な情報を提供します。このレコードタイプには、サポートされているプロトコルやポートなどの重要な情報が表示され、クライアントが接続できる代替サーバーを指定することもできます。 クライアントが DNS ルックアップを実行して HTTPS レコードが利用可能になると、使用可能なプロトコルに関する情報が即時に届きます。これにより、TLS ネゴシエーションとプロトコル検出を別々に行う必要がなくなります。ブラウザとモバイルアプリケーションは、最もパフォーマンスの高いプロトコルを使用して最初の接続で直接安全な接続を確立できるため、レイテンシーとダウングレード攻撃に対する脆弱性が軽減されます。 HTTPS DNS レコードフォーマット： <domain> <TTL> IN HTTPS <priority> <target> <parameters> 例： mysite.com. 300 IN HTTPS 1 . alpn=h2,h3 コンポーネント： domain：ウェブサイトの FQDN (末尾がドットで終わる) TTL：キャッシュ時間 (秒単位) (300-86400) priority：エイリアスは 0、サービスエンドポイントは 0 より大きい target：同じドメインの場合は「.」、別のドメインを指定 parameters：アプリケーション層プロトコルネゴシエーション、プロトコルネゴシエーション値の場合は alpn=h2、h3 などのキーと値のペア TTL が小さいほど動的更新が多いケースに向き、TTL が高いほどキャッシュパフォーマンスが向上します。 ブラウザサポート 主要なブラウザはすでに HTTPS レコードタイプをサポートしています。ウェブトラフィックの大半を占めるChrome、Safari、Firefox は、これらのクエリをデフォルトですでに行っています。 ブラウザが DNS クエリリクエストを行うと、通常は、従来の A/AAAA レコードリクエストと新しい HTTPS レコードリクエストの両方を同時に送信します。ブラウザは HTTPS レコード応答のプロトコル情報と IP アドレスを使用して最適な接続を確立します。この方法では、HTTPS レコードが利用可能な場合にパフォーマンスを最適化すると同時に、まだサポートしていない DNS サーバーとの互換性を維持できます。 クライアントがこの機能をサポートしていない場合は、「従来の DNS 解決と接続アップグレードフロー」セクションで説明されている従来の DNS 解決プロセスに従います。これにより、リスクのない最適化が可能になり、古いクライアントとの互換性を損なうことなくパフォーマンスを向上させることができます。 従来の DNS 解決と接続アップグレードフロー 次のシーケンス図は、HTTP/1.1 または HTTP/2 への初回接続後に、クライアントが Alt-Svc ヘッダーを介してHTTP/3 サポートを検出する従来の方法を示しています。HTTP/3 へのアップグレードには複数の接続確立が必要でした。 図 1: HTTPS レコードを使用しない DNS 解決と HTTP/3 アップグレードプロセス 次のステップでは、その順序を説明します。 ステップ 1-2: DNS クエリ (1) クライアントが DNS に www.example.com A/AAAA を問い合わせる (2) DNS は CloudFront エッジサーバーの IP のみを返す 結果：クライアントには IP アドレスはあるがプロトコル情報はありません。 ステップ 3-7: 最初の HTTP/2 接続 (3) CloudFront へ TCP ハンドシェイク (3 ウェイ) (4) TCP が確立される (5) TCP 経由の TLS ハンドシェイク (6) TCP 経由で TLS を確立される (7) HTTP/2 リクエスト レスポンス：HTTP/2 レスポンス Alt-Svc: h3=”:443″ 結果：クライアントは最初のリクエスト後に HTTP/3 サポートについて知ります。 HTTP/3 over QUIC を使用すると、最新の ウェブアプリケーションのパフォーマンスが向上しますが、接続のアップグレードプロセスには追加のラウンドトリップが必要になり、遅延が発生します。次のセクションでは、CloudFront ディストリビューションで HTTPS DNS レコードを使用してこれを改善する方法を紹介します。 CloudFront HTTPS DNS レコードと HTTP/3：安全な名前解決と接続確立フロー 次のシーケンス図は、HTTPS レコードタイプによる DNS 解決と、それに続くクライアントと ウェブサーバー間の接続確立を示しています。 図 2： HTTP/3 接続のための HTTPS レコードタイプを使用した DNS 解決 次のステップでは、その順序を説明します。 ステップ 1-2：DNS クエリ (1) クライアントが DNS に www.example.com HTTPS と A/AAAA を問い合わせる (2) DNS は CloudFront エッジサーバーの IP と alpn=h2,h3 を含む HTTPS レコードを返す 結果:クライアントは DNS を通じて HTTP/3 サポートを知ります。 ステップ 3-6：ダイレクト接続 (3) クライアントが CloudFront へ QUIC ハンドシェイク (1-RTT) を開始する (4) QUIC 接続が確立される (5) クライアントが HTTP/3 リクエストを送信する (6) CloudFront が HTTP/3 で応答する この図は、HTTPS DNS レコードタイプが HTTP/3 や QUIC などの最新のウェブプロトコルに関する初期ヒントをどのように提供するかを示しています。この仕組みにより、クライアントは接続開始前にサーバーがサポートするプロトコルを把握でき、より安全で効率的な接続確立プロセスが可能になります。 CloudFront HTTPS DNS レコードの作成方法 まず CloudFront ディストリビューションで HTTP/2 または HTTP/3 もしくはその両方を有効にする必要があります。既存のディストリビューションでは、 設定 に移動して 編集 を選択します。そこから次の図に示すように、ディストリビューションの HTTP/2 または HTTP/3 を有効にします。 図 3: 必要な CloudFront 設定 CloudFront ディストリビューションで HTTP/2 または HTTP/3 もしくはその両方が有効になっている場合、Route 53 を通じてカスタムドメインの HTTPS レコードを有効にできます。ドメインのホストゾーンを編集し、次の図に示すようにレコードの作成を選択します。レコード名には、CloudFront ディストリビューションのドメインに一致するサブドメインを入力します。次に、HTTPS タイプのエイリアスレコードを作成します。トラフィックのルーティング先で、CloudFront ディストリビューションへのエイリアスを選択し、該当する CloudFront ディストリビューションを選びます。保存すると、CloudFront はドメインの HTTPS レコードの送信を開始します。 図 4：HTTPS タイプの Route 53 エイリアスレコード CloudFront コスト最適化：Route 53 エイリアス HTTPS レコードの使用 CloudFront のコスト最適化を行う際、ほとんどの戦略はキャッシュヒット率の最大化、オリジンのオフロード、データ転送量の削減、HTTPS/TLS ハンドシェイクのオーバーヘッド最小化に焦点を当てています。しかし、Route 53 のエイリアスレコードを使用することで実現できる、強力でありながら見過ごされがちなコスト削減手法があります。 従来、Route 53 の DNS クエリはクエリごとに課金されます。しかし、エイリアスレコード（IPv4 専用の CloudFront ディストリビューションに対するエイリアス A レコード、またはデュアルスタック IPv4/IPv6 ディストリビューションに対するエイリアス A および AAAA レコード）を使用すると、Route 53 はこれらの DNS クエリ料金を免除します。これにより、トラフィックの多いドメインの運用コストを直接削減できます。CloudFront へのエイリアス HTTPS レコードのサポートにより、これらの節約効果はさらに拡大されます。 これで、ユーザーは CloudFront ディストリビューションを直接指す Route 53 エイリアス HTTPS レコードを設定できるようになり、Route 53 はこれらの DNS クエリを無料で処理します。これにより、最も一般的な 3 種類の DNS レコードタイプ (A、AAAA、HTTPS) のコストが削減されます。さらに、これはグローバルトラフィックを抱える大企業だけでなく、規模拡大を目指すスタートアップ企業にとっても特に影響力があります。最も一般的な DNS レコードクエリの利用が増えても課金されないため、安心感が得ることができます。 まとめ：ウェブパフォーマンス向上への一歩 Amazon CloudFront と Amazon Route 53 による HTTPS DNS レコードのサポートは、Web パフォーマンス最適化において意義ある進歩を表しています。不必要な接続セットアップのラウンドトリップを排除することで、CloudFront はエンドユーザーにコンテンツをより迅速かつ効率的に配信することができます。CloudFront での HTTPS レコードのサポートは、現在すべてのエッジロケーションで利用可能です。 AWS マネジメントコンソール を通じて、これらの新機能の使用を開始できます。CloudFront や Route 53 からの HTTPS レコード使用に関して追加料金はかかりません。 翻訳は Solutions Architect の長谷川 純也が担当しました。