金融業界の若手エンジニアの皆さん、こんにちは！ 「AWS JumpStart に参加したいけれど、ついていけるか不安…」 「同じ業界の仲間と一緒に学習したい」 「金融特有の規制要件も含めて理解したい」 そんなお悩みを解決するのが AWS JumpStart Zero For FSI です。 AWS JumpStart Zero For FSI は、金融業界の若手エンジニアの皆様を対象とした、AWS JumpStart 本編への準備イベントです。同じ業界の仲間と一緒に学習することで、より効率的で楽しい準備ができることを目指しています。AWS JumpStartって何？という方は こちらの記事 をご覧ください。 AWS JumpStart Zero For FSI とは イベント概要 AWS JumpStart Zero For FSI は、8月27日、28日 に開催される AWS JumpStart に参加予定の金融業界の若手エンジニアを対象としています。本イベントに参加することで、AWS JumpStart の予習や共に学習する仲間作りができます。 開催詳細： 開催日時： 8月22日（金）14:00-20:00 構成： 14:00-18:00（座学/グループワーク）、18:00-20:00（懇親会） 場所： 〒141-0021 東京都品川区上大崎3丁目1-1 目黒セントラルスクエア 17F AWS Startup Loft Tokyo 対象： 金融業界の若手エンジニア（1-5年目）で AWS JumpStart を受講予定の方 主な目的 AWS JumpStart を全力で楽しめる基礎知識の獲得 AWS JumpStart 本編で必要となる基礎知識を、同じ業界の仲間と一緒に楽しく学習します。 金融業界特有の課題と解決方法の理解 実際の金融機関におけるクラウド活用事例を通じて、業界特有の課題や解決方法を学びます。 同じ業界のエンジニアとの仲間作り 金融業界の若手エンジニア同士のネットワーキングを通じて、継続的な学びとキャリア成長のチャンスを得ます。 プログラム内容 ① クラウド基礎概念の理解 クラウドコンピューティングの基本概念について、オンプレミスとの違いやビジネスメリットを中心に解説します。特に金融業界でのクラウド活用トレンドを理解することができます。 セッション内では簡単なグループワークを実施し、自己紹介とともにクラウドへの期待や不安を共有することで、他の参加者と人脈を広げながら、クラウドについての理解を深める機会を得られます。 ②アーキテクチャホワイトボーディング AWS JumpStart 本編で実際に行うホワイトボーディングを体験していただきます。グループワークを通じて、アーキテクチャ設計の基本的な考え方を学び、本編への準備を行います。同じ業界の仲間と一緒に取り組むことで、より理解が深まることを期待しています。 ③ 金融業界でのクラウド活用実践 実際の金融機関におけるクラウド移行事例を紹介し、規制・コンプライアンス要件への具体的な対応方法を解説します。単なる事例紹介にとどまらず、参加者同士のディスカッションを通じて各社の課題や取り組みを共有し、実践的な知見の交換ができます。また、金融xクラウドで実際に働くAWS社員の声もお聞きいただき、金融業界でのキャリア形成のヒントを得て頂けます。 ④ 懇親会・ネットワーキング 他の参加者や AWS 若手メンバーと交流できる機会を通じて、クラウド業界での人脈を広げることができます。質問しやすい関係性が生まれ、今後の JumpStart 本編でより実践的な知識を深めることができます。さらに、この繋がりを活かして長期的なコミュニティ活動に参加することで、継続的な学びとキャリア成長のチャンスを得ることができます。 申し込み方法 こちらのページからお申し込みください。 お申し込みはお早めに！ まとめ 金融業界におけるクラウドネイティブ人材の育成は、デジタル変革を推進する上で重要な要素となっています。AWS JumpStart Zero For FSI では、同じ業界の仲間と一緒に学習することで、充実した準備ができる環境を提供します。 運営メンバー一同、金融業界の皆様により良い学習体験をお届けするべく準備を進めておりますので、ぜひとも参加をご検討ください。 よくある質問 Q: AWS の知識が全くないのですが、参加できますか？ A: はい、初心者の方を対象としたイベントです。安心してご参加ください。 Q: 他社の方との交流に不安があります A: 同じ業界の若手エンジニア同士、お互いに学び合う雰囲気を大切にしています！グループワークではアイスブレイクなども行いますので、ぜひ安心してご参加ください！ Q: AWS JumpStart とは別のイベントですか？ A: はい。AWS JumpStart とは別のイベントです。AWS JumpStartにご参加いただくための予習イベントとしてご用意しています。 Q: AWS JumpStart Zero For FSI に参加しなくても AWS JumpStart に参加できますか？ A: もちろん可能です。難易度や業界が異なる場合、AWS JumpStart のみにお申し込みください。 Q: 上の質問とは逆に、AWS JumpStart に参加しなくても、AWS JumpStart Zero For FSI に参加できますか？ A: はい。内容はAWS JumpStart にご参加を前提にしていますが、単体でのご参加も可能です。 Q: AWS JumpStart 自体への申し込みはどうすればいいですか？ A: こちらの記事 からご参加ください。 Q: AWS JumpStart をすでに申し込んでいます。どうすればいいでしょうか？ A: AWS JumpStart Zero For FSI は AWS JumpStart を補完する予習イベントです。ぜひこちらのイベントもご参加ください。 Q: 入社6年目でも参加できますか？ A: 本イベントは入社1～5年目の方を主な対象としておりますが、AWS初学者で、フレッシュな気持ちを持つ方であれば参加可能です。 Q: オンラインで参加は可能ですか？ A: 本イベントは現地開催のみです（※Jump Start本編はオンラインです。） Q: 参加費はいくらですか？ A: 参加費はかかりません。 関連リンク AWS JumpStart 2025 本編の詳細 運営チーム / ブログ著者 菅原 太樹 (Taiki Sugawara) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2024年に新卒で入社した 2 年目 SA。主に保険業界のお客様を担当しています。 好きなサービスは AWS Step Functions。自分の役職名を Step Functions Evangelist にしようとしたら却下されました。 X: @taikis_tech LinkedIn: https://www.linkedin.com/in/taikis/ 広恵 幸輝 (Kohki Hiroe) アマゾンウェブサービスジャパン合同会社 金融事業統括本部 アカウントエグゼクティブ グローバル金融機関・保険グループを担当するアカウントエグゼクティブ。 クラウドを通じたビジネス革新から、Amazon.comとの戦略的協業まで、お客様のデジタルジャーニーを包括的にサポート。 LinkedIn: https://www.linkedin.com/in/kohkih/ 佐藤 真也 (Shinya Sato) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト AWS の Storage サービス全般が好きで、AWS Black Belt Online Seminar の動画をよく更新しています。普段は保険業界のお客様を担当しています。 原 崚真 (Ryoma Hara) アマゾンウェブサービスジャパン合同会社　金融事業統括本部　地域金融西日本営業部　アカウントマネージャー アカウントマネージャーとして地域金融機関様と一部のSIer様を担当しています。 お客様のクラウドジャーニーをご支援するべく、日々活動しています。 LinkedIn はこちら 宮本 雅勝 (Masakatsu Miyamoto) アマゾンウェブサービスジャパン合同会社 カスタマーソリューションマネージメント本部 カスタマーソリューションマネージャー 金融機関のお客様のクラウドジャーニーを伴走的にご支援しております。 技術のみでなく非技術領域も含めて多岐に渡ってサポートします。 LinkedIn: https://www.linkedin.com/in/masakatsumiya/

「AWS の学習を継続したいけど、なかなかモチベーションが続かない…」「同じ AWS 初学者同士交流を深めたい」「技術的な知見を共有できる場所が欲しい」こんな悩みを持たれたことはありませんか？ 2021 年の開始以来、4,000人以上の仲間を送り出してきた AWS JumpStart に、待望の “Next Stage” が誕生しました。その名も「AWS JumpStart Next」です！ AWS JumpStart Next は学びと交流をテーマにした AWS JumpStart 参加者限定のプログラムです。2025 年 6 月 3 日、記念すべき第 1 回イベントを開催しました。会場には 2021 年から 2025 年まで、総勢 60 名以上の AWS JumpStart 卒業生が集まり、まるで同窓会のような賑やかな雰囲気の中、AI コーディングエージェントの最新トレンドから、先輩たちのリアルな現場経験まで、技術と人とが織りなす特別な空間が生まれました。 このブログでは、イベントの見どころや参加者の生の声をお届けしながら、AWS JumpStart Next が目指す繋がりの場をご紹介していきます。 AWS JumpStart Next は今後も定期的な開催を予定しており、今年は秋ごろに AWS JumpStart Next #2 を計画中です。メール等で配信される開催情報をぜひチェックしてみてください！まだ AWS JumpStart に参加したことがないという方は 8/27(水)-28(木)、10/23(木)-24(金) にも開催予定なのでこちらの ブログ からぜひご登録ください。 1. AWS JumpStart Next とは？ AWS JumpStart Next は、AWS JumpStart 卒業生限定の特別なプログラムです。 AWS JumpStart での学びを終えた後、「もっと深く学びたい」「仲間とのつながりを維持したい」「経験を共有したい」という皆さんの声から生まれました。 このプログラムの特徴は、大きく3つです。 1: 継続的な学びのきっかけ 最新技術のキャッチアップや実践的なグループワークなど、楽しみながら学び続けられる環境をご提供します。 2: 同期との絆を深める場 AWS JumpStart で築いた仲間との絆をさらに深めるとともに、参加年の枠を超えた新しい繋がりの場をご提供します。卒業生同士のつながりを促す Fun 要素を取り入れたコンテンツや、軽食を交えながらの懇親会を実施します。 3: 登壇機会の提供 技術的な知見や現場での AWS 活用経験を共有する場として、誰でも登壇にチャレンジできる機会をご用意しています。実際、今回ご登壇いただいた 3 名の卒業生の皆さんにとって外部に登壇するのは初めての挑戦でした。 2. AWS JumpStart Next #1 2025 年 6 月 3 日、AWS JumpStart Next の記念すべき第 1 回イベント「AWS JumpStart Next #1」を開催しました。本ブログではコンテンツの概要や参加者の声など、イベントのリアルな様子をお届けいたします。 【イベント詳細】 日時：2025 年 6 月 3 日（火）19:00～21:30 会場： AWS Startup Loft Tokyo （東京都品川区） 参加費：無料 対象：過去 AWS JumpStart にご参加いただいた皆様 3. AWS JumpStart Next #1 ハイライト AWS JumpStart Next の初回イベントは、クイズ大会から始まり懇親会まで、参加者同士の交流と技術的な学びが織り交ぜられた充実したプログラムとなりました。各セッションが高い評価を得ており、特にクイズ大会と卒業生 LT は参加者から高い支持が得られました。 オープニング イベントは、AWS JumpStart と今回の AWS JumpStart Next の位置づけについての説明からスタート。参加者同士がこれからのセッションを通じてより深く AWS の知識を得るとともに、同じ AWS 学習者としてのコミュニティを形成することをお伝えしました。 クイズ大会 最初のアイスブレイクとして実施された AWS に関するクイズ大会では、AWS の豆知識や AWS JumpStart の復習など幅広いクイズに参加者が挑戦しました。基礎知識から応用まで様々な問題が出題され、会場は大いに盛り上がりました。初対面の参加者同士も自然と会話が生まれ、その後のセッションでもリラックスした雰囲気が続きました。 AWS 社員による AI コーディングエージェントの最新トレンド紹介 AWS 社員から、Amazon Q Developer を中心とした AI コーディングエージェントの最新動向について紹介しました。実際のデモを通して機能のイメージを掴むことができ、コーディングだけでなく運用タスクでの活用例も紹介されました。さらに MCP の紹介など、AI を活用したより効率的な開発・運用方法について具体的な事例を交えた説明に、参加者は熱心に耳を傾けていました。 卒業生 LT（ライトニングトーク） イベントのハイライトとなったのが、過去の AWS JumpStart 卒業生による LT（ライトニングトーク）セッションです。3 名の卒業生が、JumpStart 後の AWS 活用事例や学びの継続方法、キャリアへの影響などについて発表を行いました。「卒業生の LT が本格的で刺激になった」というコメントが多く寄せられており、JumpStart で学んだことがその後のキャリアでどのように活かされているかを知る貴重な機会となりました。 登壇者と発表内容： 株式会社ネットケアサービス 飯村 淳平 様 タイトル：JumpStart での学びとこれから 株式会社インティメート・マージャー 木村 直人 様 タイトル：自社のアーキテクチャを１から考えてみたら自分の成長を実感できた エキサイト株式会社 山縣 寿樹 様 タイトル：エキサイトブログにおけるAzure→AWSへの移行とIaCの取り組み 各セッションについてグループワーク 後半は参加者同士で AI コーディングエージェントについて議論するグループワークを実施。AI ツールをどのように活用すれば業務が効率化できるか、実際の使用シーンや課題について意見を交換しました。普段は一人で悩みがちな技術的な課題も、様々なバックグラウンドを持つ参加者との対話を通じて新しい視点が得られる貴重な機会となりました。 懇親会と記念撮影 イベントの締めくくりには、参加者全員での記念撮影と軽食を囲んでの懇親会が行われました。特に AWS JumpStart ロゴ入りのスパムおにぎりが大好評で、参加者の間で話題となりました。 懇親会は大いに盛り上がり、参加者全員が積極的にコミュニケーションを取っており、オフラインならではの結束感が生まれたように感じました。「普段接点がない AWS 社員と直接話せる貴重な機会だった」との声もあり、AWS 社員や卒業生との交流を深め、人脈を広げる場となりました。 4. 参加者の声 イベント全体の満足度は非常に高く、参加者の大多数が次回の参加に意欲を見せてくださいました。アンケートからいただいた参加者からのフィードバックをいくつか紹介します： 「最高のイベントでした！」 「卒業生の LT が本格的で刺激になった」 「卒業生 LT が聞けた点はよかったです！」 また SNS では多くの方との交流ができて嬉しかったという声も挙がっていました。 アンケートでは、次回希望するコンテンツとしてハンズオンやディスカッション形式の勉強会が人気でした。これらの声を参考に、次回のイベント内容をさらに充実させていきます！ 5. 今後の展望 次回 AWS JumpStart Next #2 開催予告 AWS JumpStart Next は今回のイベントを皮切りに、継続的に開催していく予定です。今回よりもさらに熱量の高いイベントにすべく、次回も対面での開催を予定しています！ イベント後には多くの参加者から「次は自分も登壇したい」という熱意あふれる声をいただきました。この声に応え、AWS JumpStart Next #2 では、より多くの方々に登壇の機会をご提供できるよう検討を進めております。 具体的な開催日程や内容については AWS JumpStart 参加者向けにメール等でお知らせいたします。 JAWS-UG とのコラボレーション JAWS-UG（AWS User Group – Japan）とは日本全国にある AWS ユーザーによるコミュニティです。JAWS-UG では現場で AWS を活用されているかたが多く、様々な勉強会や交流イベントなどを開催しています。AWS JumpStart Next では今後 JAWS-UG とのコラボレーション企画も検討中です。 こちら から各地域やテーマごとの支部を探すことができますので、ぜひ JAWS-UG にも参加してみてください！ 6. まとめ AWS JumpStart 卒業生が集まるオンサイトイベント AWS JumpStart Next #1 は、参加者同士の技術交流と人的ネットワークの形成という目的を十分に達成し、多くの参加者から高い評価をいただきました。特に AWS JumpStart 卒業生による LT セッションは、AWS 学習の継続的な価値と可能性を示すものとして、参加者に大きな刺激を与えました。 技術と人のつながりが生まれる場所としての AWS JumpStart Next は、これからも AWS を学ぶコミュニティの発展に寄与していきたいと考えています。 このイベント開催にあたり、貴重な体験談をご共有いただいた卒業生発表者の皆様、そして何より積極的に参加いただいたすべての参加者の皆様のおかげで、素晴らしいイベントとなりました。 次回の AWS JumpStart Next #2 でお会いできることを楽しみにしています！ このブログの著者 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ソリューションアーキテクト 菊地 晏南 三浦 信二

6月 24 日と 25 日の 2 日間にわたり、幕張メッセにおいて 14 回目となる AWS Summit Japan が開催され、会場では約 3 万人の方々にご参加いただきました。本イベントでは 90 のセッションと 174 のブース展示が行われ、AWS の最新情報が共有されました。 物流業担当チームでは「倉庫 x OCR x 生成 AI エージェント」と題したデモ展示を行いました。この展示は物流業のみならず、製造業や小売業など倉庫業務に関心をもつ多くの方々にご来場いただき、生成AIによる OCR 読み取りの高精度さや生成AI エージェントを活用した業務高度化について大きな反響をいただきました。本ブログでは、展示内容とそれに使用されたサービスやアーキテクチャについて解説いたします。 背景：物流業界の課題 物流業界では、倉庫における手書き帳票処理が大きな課題となっています。作業スタッフの負担増大により、配送遅延や間違いが多発しており、業務効率化が急務となっています。このような状況を踏まえ、「生成AI を基幹システムとどう連携させるか」「生成AI をどのように業務改善に活用するか」という課題に対する一つの解決策として、今回のデモを企画しました。 デモの全体像 今回のデモでは、倉庫内の手書き帳票業務を対象に、生成AIを活用した OCR 機能とシステム連携による業務効率化ソリューションを紹介しました。以下がその主な特徴です。 1. 生成AIによる高精度な帳票読み取り（OCR） さまざまな帳票レイアウトや手書き文字も高精度で認識 事前に帳票テンプレートを登録・学習させる必要がなく、初見の帳票でも構造を理解して情報を抽出 Anthropic Claude 3.7 Sonnet を活用した高度なテキスト認識能力 2. 生成AIエージェントによる自律的なシステム連携 帳票から読み取った情報をもとに、必要な処理を自律的に判断 抽出情報に基づき、適切なシステムと連携する処理を実行 Anthropic Claude 3.5 Haiku を活用したインテリジェントなワークフロー制御 アーキテクチャ構成 デモのアーキテクチャは以下のような構成になっています。 データ取得 ：ハンディターミナル/タブレットで撮影した帳票イメージをAmazon S3 に保存 OCR 処理 ：AWS Lambdaが起動し、Amazon Bedrock 上の Anthropic Claude 3.7 Sonnet を呼び出して帳票をデジタル化し、抽出されたデータを Amazon DynamoDB に保存 システム連携 ：Amazon Bedrock上の生成AIエージェント（Anthropic Claude 3.5 Haiku）が Amazon DynamoDB の情報を読み取り、連携先の基幹システムを適切に呼び出し 情報可視化 ：基幹システムの情報を BI として Amazon QuickSight で可視化 このシステムにより、手書き帳票のデジタル化から基幹システムとの連携までをシームレスに実現しています。また、Amazon API Gateway、Amazon Cognito、Amazon QuickSightなども活用し、セキュアで使いやすいインターフェースを提供しています。 デモのシナリオを順を追って説明します。 ①データ取得 倉庫内の作業員がハンディターミナルやタブレットを使用してデモアプリケーションから手書き帳票を撮影します。 撮影された画像データは、Amazon API Gatewayを経由してAmazon S3バケットに保存されます。作業員は特別な訓練なしに、簡単な操作で帳票をデジタル化するプロセスを開始できます。これにより、従来は手作業で行っていた帳票の仕分けや管理作業が大幅に効率化されます。 ②OCR処理 生成AI以前の従来の OCR でも画像からデジタルなテキストデータを抽出することは可能でしたが、そのテキストに意味的な解釈を加えるためにはアプリケーション側の工夫が必要でした。例えば、今回の例のように帳票を扱うようなOCRシステムを構築する場合、帳票のテンプレートごとにどこにどのようなデータがあるかという意味的な解釈をシステムに組み込む必要があるため、帳票数が増えるとシステム管理にかかる工数が増大する問題がありました。 生成AIを活用することでこの問題を大幅に軽減できます。Amazon Bedrock にはテキストに加えて画像や音声をインプット情報として処理できるマルチモーダルな生成AIモデルがあります。こうしたモデルに対して、以下のようなプロンプトを画像とともに与えることで、高度なOCR処理を実現できます。 あなたは倉庫管理システムのOCR専門アシスタントです。この画像を分析し、発注指示書かどうかを判定し、情報を抽出して下さい。 ## 判定基準 発注指示書の特徴： - 依頼者情報（名前、住所、電話番号） - 出荷先情報（名前、住所） - 商品リスト（品番、品名、数量） - 「発注」「出荷指示」「納品」等のキーワード ## 出力形式 ### 発注指示書の場合 以下のJSON形式で出力（説明文は不要）： json { "sender_name": "依頼者名", "sender_address": "依頼者住所", "sender_phone": "依頼者電話番号", "recipient_name": "出荷先名", "recipient_address": "出荷先住所", "notes": "備考・特記事項", "shipment_items": [ { "product_code": "品番", "product_name": "品名", "item_count": 数量（数値`）` } ] } ### 発注指示書でない場合 json { "document_type": "other", "content": "読み取った内容をマークダウン形式で記載" } ## 注意事項 - 情報が不明・読み取れない場合は空文字列（""）またはnullを使用 - 数量は必ず数値型で出力 - 日付は可能な限りYYYY-MM-DD形式に変換 - 曖昧な文字は文脈から推測して補完 - JSONの構文エラーがないよう注意 画像を分析して適切な形式で出力してください。 今回のデモ展示では Amazon S3 に帳票画像が保存されると、AWS Lambda がトリガーされ上記のようなプロンプトを使った OCR 処理が開始されます。今回はモデルとして Anthropic Claude 3.7 Sonnet を使用しています。参考までにサンプルのインプットと出力結果を以下に示します。 { "sender_name": "クイックファッション", "sender_address": "141-0021 東京都品川区上大崎4丁目 5-10", "sender_phone": "012-3456-7890", "recipient_name": "クイックファッション墨田倉庫", "recipient_address": "130-0025 東京都墨田区千歳1丁目 5-17", "notes": "第一希望: 5月27日 16時～18時\n第二希望: 5月28日 18時～20時", "shipment_items": [ { "product_code": "A-10606", "product_name": "コンフォートスニーカー", "item_count": 35 }, { "product_code": "G-05011", "product_name": "クロップドワイドパンツ", "item_count": 20 }, { "product_code": "F-20221", "product_name": "くつろぎスウェット", "item_count": 45 } ] } { "sender_name": "セカンドモータース", "sender_address": "〒272-0127 千葉県市川市塩浜2丁目 13-1", "sender_phone": "012-3456-7890", "recipient_name": "セカンドモーターズ 新砂倉庫", "recipient_address": "〒136-0075 東京都江東区新砂3丁目 2-9", "notes": "", "shipment_items": [ { "product_code": "B-101", "product_name": "エクストリームグリップ", "item_count": 63 }, { "product_code": "F-001", "product_name": "冬タイヤセット1", "item_count": 25 }, { "product_code": "F-001", "product_name": "冬タイヤセット1", "item_count": 20 }, { "product_code": "C-0101", "product_name": "Navi Pro", "item_count": 22 } ] } 上記のサンプル画像を比較していただくと、テンプレートが全く異なることがわかります。この異なるテンプレートに対して、単一のプロンプトで想定通りのテキストを抽出できています。最初から倉庫管理システムに登録するために必要なデータ形式として出力されている点も運用上効率的です。 ブース対応の中でコストと認識精度に関する質問を多く頂きました。コストに関しては上記サンプルを OCR した際のInputトークンが 1,900、Output トークンが 400 でした。2025 年 7 月現在の米国リージョンの Anthropic Claude 3.5 Sonnet の単価 で計算すると0.0117 USDとなり、為替にもよりますが1回のOCRあたり1～2円程度のコストになります。 精度に関しては、上記サンプルで確認できる通り撮影状況が良ければ手書き文字であっても高精度で認識が可能です。一方で撮影状況や手書き文字自体によって思うような精度が出ないケースもあり、100 %に近い精度が求められるケースではそのまま導入することは難しい場合もあります。そのような場合には、前処理で OCR 処理がしやすいように画像を加工したり、OCR 処理後のデータを人目で確認させるような Human in the loop の設計とすることで、全体としての認識精度向上に取り組むことができます。今回のデモでは取得したデータをそのまま Amazon DynamoDB に保存しています。 ③システム連携 Amazon DynamoDB に保存された構造化データは、Amazon Bedrock 上の生成AI エージェントによって処理されます。この生成AIエージェントは、抽出された情報を分析し、どのような処理が必要かを自律的に判断します。最終回答が得られるまでReasoning (考察) + Acting (実行)と繰り返す手法を React と呼びます。この React の具体例として、商品の出荷指示であれば在庫管理システムへの連携、返品処理であれば返品管理システムへの連携など、適切な基幹システムを自動的に選択して必要な API を呼び出すといったことができます。 また、Amazon Bedrock のエージェント機能には Multi-agent collaboration があり、エージェントは他のコラボレーターエージェントにタスクを委任できます。具体的には、Supervisor エージェントがまずタスクを処理し、その後各社専用エージェントにタスクを委任することで、異なる基幹システムに対して適切なデータ形式で情報を連携させることが可能です。今回のデモでは OCR 処理した商品情報を Amazon Aurora に登録する AWS Lambda 処理を呼び出しています。 このインテリジェントなシステム連携により、従来は人間が判断して手作業で行っていた複数システム間の連携作業が自動化され、処理時間の短縮とヒューマンエラーの削減を実現します。 ④情報可視化 倉庫側の在庫や出荷状況を確認する仕組みとして Amazon QuickSight を利用しています。Amazon QuickSight は様々な業界やユースケースで利用可能なビジネスインテリジェンスツールです。デモでは商品毎の在庫数等をダッシュボードで表現しました。Amazon QuickSight はマルチデバイスに対応しているため、常設のモニタに KPI を投影したり、倉庫内を頻繁に移動する社員がモバイルデバイスで状況を確認したりと、幅広い活用が可能です。このようにダッシュボードを利用し、在庫切れリスクの早期発見、適正在庫数の維持、需要予測と備蓄計画の立案に活用いただけます。 また、Amazon QuickSight の大きな魅力はデータソースの選択肢が豊富なことです。AWS サービスである Amazon S3 や Amazon Redshift はもちろん、リレーショナルデータベースの Oracle や PostgreSQL、SaaS のデータプラットフォームである Snowflake など、様々なデータソースをサポートしています。今回は WMS の リレーショナルデータベースである Amazon Aurora をデータソースとして参照し、データベース内の入庫情報と出庫情報を基に、リアルタイムで在庫状況をダッシュボード上に表示しています。 期待される効果 このソリューションを導入することで、以下のような効果が期待できます。 業務効率の大幅な向上 ：手書き帳票の処理時間短縮と人的ミスの削減 システム連携の自動化 ：生成AIエージェントによる適切なシステム連携の自動判断 柔軟な対応力 ：様々な帳票フォーマットに対応可能な OCR 能力 導入の容易さ ：テンプレート登録不要で、すぐに活用可能 補足：Amazon Q Developer デモアプリケーションは、すべて Amazon Q Developer を活用して開発されました。従来のアプリケーション開発では、設計から実装まで多くの手作業によるコーディングが必要でしたが、今回のデモアプリケーションでは開発プロセスそのものも生成AIを活用して効率化しています。 Amazon Q Developer は、コード生成、コード変換、バグ修正、コードレビューなどの機能を提供する開発者向けの生成AIアシスタントです。今回のデモアプリケーション開発では、以下のような形で活用しました。 アーキテクチャ設計支援 : システム要件から最適なAWSサービス構成を提案 コード自動生成 : AWS Lambda 関数、API Gateway 設定、DynamoDB 操作など、必要なコンポーネントのコードを自然言語による指示から生成 プロンプトエンジニアリング : OCR 処理やエージェント連携のための最適なプロンプトを設計・改善 デバッグ支援 : 開発中に発生した問題の迅速な特定と修正案の提示・改修 これにより、従来であれば数週間かかるような開発工程が数日で完了し、開発者はビジネスロジックの設計や全体アーキテクチャの最適化に集中することができました。また、生成AI を活用したアプリケーション開発の経験が少ないチームメンバーでも、Amazon Q Developer のガイダンスに従うことで、高品質なコードを短時間で実装することができました。 このように、今回のデモは「生成AI による業務効率化」を示すだけでなく、「生成AI による開発効率化」も同時に実証する取り組みとなりました。物流業同様にソフトウェア開発も人手不足が深刻化しており、開発コストも高騰しています。このような状況で継続的な物流DXを推進するためにAmazon Q Developerを有効に活用することで、開発者の生産性向上と、より複雑な業務課題に対応するソリューションの迅速な開発が可能になります。 まとめ AWS Summit Japan 2025 で展示した「倉庫 x OCR x 生成 AI エージェント」は、物流業界が抱える手書き帳票処理の課題に対して、生成AIを活用した革新的な解決策を提案しています。生成AI を OCR として活用するだけでなく、システム連携のインテリジェンスとしても活用することで、業務プロセス全体の効率化を実現します。 物流業界は2024 年問題をはじめとする様々な課題に直面していますが、今回のデモで示したように、生成AI の活用によって、デジタルに詳しくない作業員でも簡単に業務を遂行できるようになり、生産性の向上が期待できます。物流が抱える課題の解決に向けて、生成AI の活用を検討してみてはいかがでしょうか。 このブログは、ソリューションアーキテクト 横山、宇加治、山本、駒野 が担当しました。

このブログは 2025 年 6 月 26 日 に Dave Jaskie、 Gekai Zou、 Aamir Khan、 Anshu Prabhat によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 お客様から Amazon WorkSpaces Personal に接続するために AWS PrivateLink を活用する方法についてよくお問い合わせをいただきます。 PrivateLink は、インターネットゲートウェイ、 NAT デバイス、 VPN 設定などの従来のネットワークコンポーネントを必要とせずに、安全でプライベートな接続を確立するシームレスな方法を提供します。このアプローチは、ネットワークアーキテクチャを簡素化するだけでなく、攻撃対象領域を大幅に削減し、すべてのデータトラフィックを AWS ネットワーク内で安全に保つことでセキュリティを強化します。このブログでは、 PrivateLink を WorkSpaces と統合するプロセスを段階的にガイドし、お客様の環境でこれらの利点を活用できるよう支援します。 前提条件と制限事項 WorkSpaces の PrivateLink は現在、ストリーミングトラフィックでサポートされています。 WorkSpaces の 前提条件と制限事項 の詳細については、 管理者ガイド を確認してください。 PrivateLink を設定するには、まずセキュリティグループを設定し、 VPC エンドポイントを作成し、最後に VPC エンドポイントを使用するように WorkSpace ディレクトリを設定する必要があります。 ステップ 1: セキュリティグループの作成 このステップでは、 WorkSpaces クライアントが作成する VPC エンドポイントと通信できるセキュリティグループを作成します。 Amazon EC2 コンソール のナビゲーションペインで、 ネットワーク & セキュリティ 、次に セキュリティグループ に移動します。 セキュリティグループの作成 を選択します。 基本的な詳細 で、以下を入力します： セキュリティグループ名 – セキュリティグループを識別する一意の名前を入力します。 説明 – セキュリティグループの目的を説明するテキストを入力します。 VPC – VPC エンドポイントがある VPC を選択します。 インバウンドルール に移動し、 ルールの追加 を選択して TCP トラフィック用のインバウンドルールを作成します。 以下を入力します： タイプ – カスタム TCP を選択します。 ポート範囲 – 次のポート番号を入力します： 443 、 4195 ソースタイプ – カスタムを選択します。 ソース – ユーザーが VPC エンドポイントに接続するプライベート IP CIDR 範囲または他のセキュリティグループ ID を入力します。 IPv4 アドレスソースからのインバウンドトラフィックのみを許可するようにしてください。 各 CIDR 範囲またはセキュリティグループに対してステップ 4 と 5 を繰り返します。 インバウンドルール に移動し、 ルールの追加 を選択して UDP トラフィック用のインバウンドルールを作成します。 以下を入力します： タイプ – カスタム UDP を選択します。 ポート範囲 – 次のポート番号を入力します： 443 、 4195 ソースタイプ – カスタムを選択します。 ソース – ステップ 5 で入力したのと同じプライベート IP CIDR 範囲またはセキュリティグループ ID を入力します。 各 CIDR 範囲またはセキュリティグループに対してステップ 7 と 8 を繰り返します。 セキュリティグループの作成 を選択します。 ステップ 2: VPC エンドポイントの作成 Amazon VPC では、 VPC エンドポイントを使用して VPC をサポートされている AWS サービスに接続できます。この例では、 WorkSpaces ユーザーが WorkSpaces からストリーミングできるように Amazon VPC を設定します。 Amazon VPC コンソール を開きます。 ナビゲーションペインで、 エンドポイント 、次に エンドポイントの作成 に移動します。 エンドポイントの作成 を選択します。 以下を確認します： サービスカテゴリ – AWS サービスが選択されていることを確認します。 サービス名 – com.amazonaws. Region .prod.highlander を選択します。 VPC – インターフェースエンドポイントを作成する VPC を選択します。VPC エンドポイントにアクセス可能なネットワーク環境であれば、 WorkSpaces リソースがある VPC とは異なる VPC を選択できます。 プライベート DNS 名を有効にする – チェックボックスが選択されています。ユーザーがネットワークプロキシを使用してストリーミングインスタンスにアクセスする場合は、プライベートエンドポイントに関連付けられたドメインと DNS 名でプロキシキャッシュを無効にします。 VPC エンドポイント DNS 名はプロキシを通過できるようにする必要があります。 DNS レコード IP タイプ – IPv4 を選択します。デュアルスタックと IPv6 DNS レコード IP タイプは現在サポートされていません。デュアルスタックまたは IPv6 が選択されている場合、 VPC エンドポイントを使用して WorkSpaces からストリーミングできません。 サブネット – VPC エンドポイントを作成するサブネット（アベイラビリティーゾーン）を選択します。少なくとも 2 つのサブネットを選択することをお勧めします。 IP アドレスタイプ – IPv4 を選択します。 セキュリティグループパネル – 先ほど作成したセキュリティグループを選択します。 （オプション） タグ パネルで、 1 つ以上のタグを作成できます。 エンドポイントの作成 を選択します。 エンドポイントが使用可能になると、ステータス列の値が利用可能に変わります。 ステップ 3: VPC エンドポイントを使用するように WorkSpaces ディレクトリを設定する ストリーミング用に作成した VPC エンドポイントを使用するように WorkSpaces ディレクトリを設定する必要があります。 VPC エンドポイントと同じ AWS リージョンで WorkSpaces コンソール を開きます。 ナビゲーションペイン で、 ディレクトリ を選択し、 使用する ディレクトリ を選択します。 VPC エンドポイントセクション に移動し、 編集 を選択します。 VPC エンドポイントの編集ダイアログボックス で、 ストリーミングエンドポイント の下で、作成した VPC エンドポイントを選択します。 オプションで 、 PCoIP WorkSpaces を使用するユーザーがインターネットからストリーミングできるようにすることを有効にする ことができます。 有効にすると、ユーザーはパブリックインターネット経由で PCoIP WorkSpaces からストリーミングできるようになります。そうでなければ、 PCoIP WorkSpaces はストリーミングに VPC エンドポイントの使用をサポートしていないため、ディレクトリ内の PCoIP WorkSpaces にアクセスできなくなります。 保存 を選択します。 新しいストリーミングセッションのトラフィックは、この VPC エンドポイント経由でルーティングされます。ただし、現在のストリーミングセッションのトラフィックは、以前に指定されたエンドポイント経由でルーティングされ続けます。 まとめ この投稿では、 Amazon WorkSpaces Personal を PrivateLink で設定する方法について説明しました。 PrivateLink の詳細については、製品ページをご確認ください。ご質問がございましたら、 AWS サポートチームまでお問い合わせください。 End User Compute の新機能の最新情報については、 AWS の新機能をチェックし、 YouTube プレイリストもぜひご覧ください。

本記事は、2025 年 4 月 24 日に公開された “ How to use data from the AWS Open Data program in Amazon Bedrock ” を翻訳したものです。翻訳はソリューションアーキテクトの秋山が担当しました。 AWS オープンデータスポンサーシッププログラム は、価値の高いデータセットをクラウド上でホストすることでデータ取得の障壁を排除し、研究者やアナリストがデータ管理ではなく、発見とイノベーションに集中できるようにします。データが Amazon Web Services (AWS) で共有されると、誰でも Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Athena 、 AWS Lambda 、 Amazon EMR などの幅広いコンピューティングおよびデータ分析プロダクトを使用して、データを分析し、その上にサービスを構築することができます。AWS は Registry of Open Data on AWS を通じて、AWS 上で公開されているデータセットのカタログを提供しています。このレジストリには、政府データ、科学研究、ライフサイエンス、気候、衛星画像、地理空間、ゲノムデータなど、650 以上のデータセットが一般に公開されています。 米国海洋大気庁 (NOAA) をはじめとする多くの政府機関が、AWS オープンデータスポンサーシッププログラムに参加しています。NOAA は NOAA オープンデータ配信 (NODD) プログラム を通じてデータを一般に公開しています。 AWS 上のすべての NODD データセットを閲覧 することができます。このチュートリアルでは、NODD プログラムの NOAA データを使用して、お客様が Amazon Bedrock で AWS オープンデータを通じて利用可能なデータをどのように活用できるかをご紹介します。 この投稿では、 Amazon Bedrock Knowledge Bases を使用して、AWS のオープンデータレジストリにある NOAA データセットを活用する方法について説明します。Amazon Bedrock Knowledge Bases を使用することで、プライベートおよびパブリックのデータソースからコンテキスト情報を 基盤モデル (FM) とエージェントに提供し、より関連性が高く、正確で、カスタマイズされた応答を実現できます。特に NOAA のグローバル歴史気候ネットワーク (GHCN) を使用することで、SQL コマンドや一般的なデータ検索ツールに慣れていないユーザーでも、降水量や積雪深などの情報にアクセスできるようになります。チャットベースのアシスタントを通じて、技術的な知識を持たない意思決定者でも、高度な技術データに理解しやすい形式でアクセスできるようになりました。 ソリューションの概要 この投稿は 2 つのパートに分かれています。パート 1 では、少数のファイルのみを使用するため、大きなコストをかけることなく機能を試すことができます。パート 2 では、データセット全体を使用して機能の全体像を把握できますが、コストも高くなります。追加コストの発生を防ぐため、作業が完了後はナレッジベースとベクトルストアを削除することをお勧めします。 NOAA Global Historical Climatology Network (GHCN) データセットをナレッジベースとして使用します。このデータセットには、米国全土の観測所からの気温と積雪深の測定値が含まれています。このデータセットは、AWS のオープンデータレジストリにある公開 Amazon Simple Storage Service (Amazon S3) バケット内の CSV ファイルとテキストファイルのセットとして提供されています。 前提条件 このソリューションを実行するには、以下の前提条件が必要です： 関連するサービスへのアクセス権限を持つ AWS アカウントへのアクセス AWS Management Console の基本的な知識 パート 1: ソリューションの概要 AWS のオープンデータレジストリから始めましょう: Registry of Open Data on AWS のウェブサイトで、以下のスクリーンショットに示すように、 Search datasets バーに GHCN と入力します。 図 1. Registry of Open Data on AWS の検索データセットボックスに GHCN を入力した状態 NOAA Global Historical Climatology Network Daily (GHCN-D) データセットを選択してレジストリページを開きます。 Browse Bucket リンクを右クリックして新しいウィンドウで開きます。このリンクをクリックすると、NOAA GHCN パブリックバケット内の現在のすべてのファイルとフォルダのリストが表示されます。 図 2. noaa-ghcn-pds バケットの AWS S3 Explorer ビュー csv/ フォルダを開き、次に by_year/ フォルダを開きます。GHCN のデータが 1750 年まで遡って用意されていることを確認できます。まず、利用可能なデータを確認するために、最も古いファイルのいくつかを見てみましょう。 1763.csv と 1764.csv ファイルを選択してダウンロードします。 ページの下部までスクロールし、 Next を選択します。データの最後のページに到達するまで Next を選択し続けます。この記事の執筆時点では、ページ 6 に 2012 年から 2025 年までのデータがあります。 2023.csv と 2024.csv もダウンロードします。 1763.csv と 1764.csv ファイルから始めて、それぞれのファイルをアプリケーションで開いてデータを確認します。 ファイルとデータ形式 データセットをナレッジベースとして検討する際には、ファイルのフォーマットとそのデータの内容が重要です。ナレッジベースに対して質問を投げかけ、適切な回答を得るためには、ファイルの内容とその参照方法を理解する必要があります。 例えば、1763.csv の GHCN データには、ID、DATE、ELEMENT、DATA_VALUE という列があります。この最初の 4 つの列が、この投稿の残りの部分の焦点となります。NOAA は open-data-docs リポジトリで各列のドキュメントを提供しています。NOAA のドキュメントによると、最初の列は観測所 ID (ID) です。DATE 列の日付は YYYYMMDD 形式で、例えば 17630127 は 1763 年 1 月 27 日を意味します。ELEMENT 列には、最高気温 (TMAX)、最低気温 (TMIN)、積雪深 (SNWD)、降水量 (PRCP) が含まれています。DATA_VALUE は ELEMENT の実際の値です。 ファイルをローカルで表示すると、観測所 (ID) ITE00100554 の 17630131 (1763 年 1 月 31 日) の最高気温が 9 であったことが、次のスクリーンショットのように確認できます。 図 3. ID ITE00100554の1763年1月31日の最高気温が9である1763.csvのスクリーンショット プライベート S3 バケットの作成 1763.csv と 1764.csv を使用してナレッジベースを作成するには、以下の手順に従ってください： Amazon S3 コンソール で、 バケットを作成 を選択し、バケット名を YOURNAME -ghcn-1763-1764 とします。 YOURNAME の部分は、バケット名を一意にするためにあなたの姓名などに置き換えてください。ページ内の他の設定はすべてデフォルトのままにして、ページ下部の バケットを作成 を選択します。 バケットが作成されたら、それを選択してバケットの内容を表示します（空の状態です）。 1763.csv と 1764.csv ファイルをバケットにドラッグ＆ドロップし、 アップロード を選択します。以下のスクリーンショットのように、両方のファイルがバケットにコピーされるまで待ちます。 または、アップロードボタンを使用します。1763.csv と 1764.csv ファイルをドラッグ＆ドロップするか、 ファイルを追加 を選択して追加できます。 アップロード を選択し、以下のスクリーンショットのように両方のファイルがバケットにコピーされるまで待ちます。 図 4. 1764.csv と 1763.csv を Files and folders にアップロードしたスクリーンショット 1760 年代のナレッジベース プライベートバケット内のデータを使用して、最初のナレッジベースを作成します。Amazon Bedrock の FM を使用するには、まずアクセス権限のリクエストが必要です。アクセス権限のリクエストとナレッジベースの作成には、以下の手順に従ってください： Amazon Bedrock コンソール の左側のナビゲーションペインで、 Configure and learn  の下にある モデルアクセス を選択します。 モデルアクセス ページで、 モデルアクセスを変更 を選択します。 Titan Text G1 – Premier 、 Titan Embeddings G1 – Text 、 Titan Text Embeddings V2、 Nova Pro、Nova Lite  の横にあるチェックボックスを選択し、 次へ を選択した後、 送信 を選択してこれらのモデルへのアクセスをリクエストします。 Build  の下で、 ナレッジベース  を選択します。 作成 を選択し、 ベクトルストアを含むナレッジベース を選択します。このウォークスルーでは、 Amazon OpenSearch Serverless を使用するベクトルストアを使用しますが、Amazon Bedrock ユーザーガイドの Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases で他のオプションも確認できます。 ナレッジベースに YOURNAME -GHCN-1763-1764 という名前を付けます。 YOURNAME をあなたの名前に置き換えてください。ページの残りの部分はデフォルトのままにして、 次へ を選択します。 データソース  で、以下を変更します： データソースの場所 は、 この AWS アカウント  のままにします。 S3 URI で、 S3 を参照  を選択し、先ほど作成した YOURNAME -ghcn-1763-1764 バケットを選択します。 ページの残りの部分はデフォルトのままにして、 次へ  をクリックします。 ここで使用する Embeddings モデルを選択する必要があるので、 モデルを選択  をクリックし、 Titan Text Embeddings V2 を選択して、 適用 をクリックします。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 選択内容を確認し、準備ができたら ナレッジベースを作成 を選択します。 Amazon OpenSearch Serverless でベクトルデータベースを準備するには数分かかります。このチュートリアルで使用する少量のデータであっても、Amazon OpenSearch Serverless コレクションにはコストが発生することに注意してください。コストを監視するために、 Cost Explorer の予算やアラーム を設定することをお勧めします。 ベクトルデータベースが作成されると、「Amazon OpenSearch Serverless ベクトルデータベースの準備が完了しました」という通知を受け取り、ナレッジベースが作成されます。この時点では空のベクトルストアができているので、データを投入する必要があります。そのためには、データを同期する必要があります： 以下のスクリーンショットに示すように、 データソース で作成したデータソースを選択します。 図 5. 選択したデータソースと同期する準備ができた GHCN-1763-1764 ナレッジベース ベクトルストアにデータの追加を開始するには、 同期 を選択します。プライベートバケットには 2 つのファイルしかないため、数分で完了するはずです。 2 つのファイルの内容をいくつか把握しているため、ローカルでファイルを開いて、答えがわかっている質問をすることができます。これにより、ナレッジベースがファイル内のデータを使用していること、およびそのデータを正しく使用していることを確認できます。ナレッジベースをテストするには、以下の手順に従ってください： テストに使用するモデルを選択するには、 ナレッジベースをテスト の下で モデルを選択 を選択します。 Nova Lite を選択し、 適用 を選択します。同様の回答を返す他のモデルも利用可能です。 ナレッジベースに質問するには、 プロンプトを記述 ボックスに以下をペーストし、 Run を選択します。 What was the TMAX on 17630131? 先ほど示したように、ファイルから答えは 9 であることがわかっています。ナレッジベースは以下の回答を提供します： The TMAX on 17630131 was 9 degrees ナレッジベースがどのように回答を導き出したかを確認するには、 詳細 > を選択します。メタデータには、Amazon Bedrock が回答を形成するために情報を見つけたファイル (source-uri) が表示されます。 ソースチャンク  には使用された実際のデータチャンクが表示され、以下のようになります： , ITE00100554,17630124,TMIN,10,,,E, ITE00100554,17630125,TMAX,24,,,E, ITE00100554,17630125,TMIN,-2,,,E, ITE00100554,17630126,TMAX,6,,,E, ITE00100554,17630126,TMIN,-22,,,E, ITE00100554,17630127,TMAX,1,,,E, ITE00100554,17630127,TMIN,-27,,,E, ITE00100554,17630128,TMAX,-5,,,E, ITE00100554,17630128,TMIN,-33,,,E ITE00100554,17630129,TMAX,-1,,,E, ITE00100554,17630129,TMIN,-29,,,E, ITE00100554,17630130,TMAX,4,,,E, ITE00100554,17630130,TMIN,-16,,,E, ITE00100554,17630131,TMAX,9,,,E, ITE00100554,17630131,TMIN,-21,,,E, ITE00100554,17630201,TMAX,19,,,E, ITE00100554,17630201,TMIN,-11,,,E, ITE00100554,17630202,TMAX,28,,,E, ITE00100554,17630202,TMIN,-2,,,E, 上記でハイライトされているように、以下のチャンクが私たちの回答です。 ITE00100554, 17630131, TMAX,9,,,E, ナレッジベースが情報をどのように解析し、回答を導き出すかを理解するために、いくつかの質問を試してみてください。 クリーンアップ 今後の料金の発生を防ぐため、作業が完了したらナレッジベースを削除する必要があります。ナレッジベースを削除するには： Amazon Bedrock コンソールの Build  で、 ナレッジベース を選択し、 YOURNAME -GHCN-1763-1764 ナレッジベースを選択します。 ナレッジベース作成時の詳細設定でベクトルストアを保持することを選択した場合、ナレッジベースを削除する前に Amazon OpenSearch のインデックス名を確認する必要があります。 ベクトルデータベース までスクロールし、 コレクション ARN をメモしてください： arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID で、 UUID は ea50z3iuyaavwy8bymq4 のようなコレクションの一意の識別子になります 新しいタブまたはブラウザウィンドウで OpenSearch Service コンソールを開き、 Serverless の下にある Collections を選択し、このチュートリアルで作成したコレクションを選択して開きます。 コレクション ARN が、ベクトルデータベース用に受け取った Amazon Resource Name (ARN) と一致することを確認します。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID ベクトルデータベースを削除するには、 コレクションを削除  を選択し、ダイアログボックスに 確認 と入力します。 Amazon Bedrock タブに戻り、ナレッジベースの削除の最後のステップを完了します。 削除  を選択し、ウィンドウに 削除 と入力します。 図 6. GHCN-1763-1764 のナレッジベースを削除 パート 2: ソリューションの詳細 このセクションでは、パート 1 で学んだ内容を活用して、Registry of Open Data のデータセットを使用したナレッジベースを直接利用することができます。ファイルをコピーする代わりに、Amazon Bedrock にパブリックバケットを直接指定します。以下の手順に従ってください： Registry of Open Data on AWS で、 Search datasets バーに GHCN と入力します。 レジストリページを開くために NOAA Global Historical Climatology Network Daily (GHCN-D) データセット を選択します。 このページにある Amazon Simple Notification Service (Amazon SNS) トピックに注目してください： arn:aws:sns:us-east-1:123901341784:NewGHCNObject アカウント ID の部分 ( 123901341784 ) を選択し、後でアカウント ID が必要になるため、このウィンドウを別のタブで開いたままにしておきます。 Browse Bucket リンクを右クリックして新しいウィンドウで開きます。このリンクをクリックすると、NOAA GHCN パブリックバケット内の現在のすべてのファイルとフォルダの一覧が表示されます。 このウォークスルーでは、データセット全体のサブセットのみを使用するために、ナレッジベースを特定のフォルダに制限する必要があります。これにより、このデモで発生するコストを抑えることができます。このデータセットをテストや開発以外の目的で使用する場合は、バケット全体を使用することをお勧めします。 NOAA は GHCN データのパフォーマンス改善に取り組んでおり、プレフィックス (またはフォルダ) が変更される可能性があることにご注意ください。 パート 1 と同様に、 csv/ フォルダ、次に by_year/ フォルダを開きます。ただし、今回は by_year フォルダ全体を使用します。バケット名とフォルダパスは次のようになります： s3://noaa-ghcn-pds/csv/by_year/ ウィンドウの右下にある番号付きのリンクを使用して、バケット内の最後のエントリに移動します。この記事の執筆時点では、 6 を選択すると、2012-2025.csv の年のファイルが表示されます。 2024.csv と 2023.csv を選択してダウンロードし、後で使用するために保存します。これらのファイルを使用して、最初にナレッジベースへのクエリを実行します。 GHCN 年次ナレッジベース パブリック AWS Open Data バケットのデータを使用して、新しいナレッジベースを作成します。パブリック AWS Open Data バケットから新しいデータでナレッジベースを更新したい場合は、 同期  コマンドを使用して更新できます。 Amazon Bedrock コンソールで、 作成 を選択し、 ベクトルストアを含むナレッジベース を選択します。 ナレッジベースに YOURNAME -GHCN-by-year という名前を付けます。 YOURNAME はあなたの名前に置き換えてください。ページの残りの部分はデフォルトのままにして、 次へ を選択します。 Data source で、以下の変更を行います： Data source location を Other AWS account に変更します。 Account ID に 123901341784 を入力します。 S3 URI に s3://noaa-ghcn-pds/csv/by_year/ を入力します。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 埋め込みモデルを選択するには、 モデルを選択 を選択し、 Titan Text Embeddings V2 を選択して、 適用 を選択します。 ページの残りの部分はデフォルトのままにして、 次へ を選択します。 選択内容を確認し、準備ができたら ナレッジベースを作成 を選択します。 Amazon OpenSearch Serverless でベクトルデータベースを準備するには数分かかります。Amazon OpenSearch Serverless コレクションには料金が発生します。この例では、パブリックの GHCN バケットにある数百のファイルを使用しています。コストを監視するために、 Cost Explorer の予算やアラーム を設定することをお勧めします。 ベクトルデータベースが作成されると、「Amazon OpenSearch Serverless ベクトルデータベースの準備が完了しました」という通知が表示され、ナレッジベースが作成されます。この時点では空のベクトルストアができているので、データを投入する必要があります。そのためには、データを同期する必要があります： 以下のスクリーンショットに示すように、 Data source で作成したデータソースを選択します。 図 8. 選択したデータソースと同期準備が完了した GHCN-by-year ナレッジベース ベクトルストアへのデータ追加を開始するには、 同期 を選択します。すべてのファイルをベクトルストアにパースするには数時間かかる場合があります。同期の完了を待つ間に、ナレッジベースの同期が完了した後にどのような質問ができるかを確認するため、いくつかのファイルをダウンロードすることができます。 同期が完了したら、以下の手順でナレッジベースをテストしてください： Amazon Bedrock コンソールで、 Build  の下にある ナレッジベース を選択し、 YOURNAME -GHCN-by-year ナレッジベースを選択します。 ナレッジベースをテスト で、テストに使用するモデルを選択するために モデルを選択 を選択します。 Nova Lite を選択し、 適用 を選択します。 これで質問の準備が整いました。以下にいくつかの例を示します： 質問： What was ASN00007139 TMAX in 17500301? 回答: The TMAX value for ASN00007139 on 17500301 is 424 ボットからの応答の横にある Show details > リンクに注目してください。このリンクを選択すると、応答の生成に使用されたファイルのチャンクを確認できます。 以下のような一般的な質問もできます： 質問: What types of data are in this knowledge base? 回答: Based on the retrieved results, the knowledge base contains data related to precipitation (PRCP), maximum temperature (TMAX), and minimum temperature (TMIN) データの内容と、ナレッジベースでの使用方法がわかったので、データセット全体に対して以下のような質問ができます: 質問: What was highest SNWD recorded for US1AKFN0032? 回答: The highest SNWD recorded for US1AKFN0032 is 559.0 この値は、アラスカ州フェアバンクスの積雪深を示しています。 NOAA GHCN ドキュメント を使用して最寄りの観測所を見つけ、どのような値が得られるか確認してみましょう！必要に応じて、コストを節約するために作業が完了したらナレッジベースを削除することもできます。 クリーンアップ 今後の料金の発生を防ぐため、作業が完了したらナレッジベースを削除する必要があります。ナレッジベースを削除するには： Amazon Bedrock コンソールで、 Build  の下にある ナレッジベース を選択し、 YOURNAME - GHCN-by-year ナレッジベースを選択します。 ナレッジベース作成時の詳細設定でベクトルストアを保持することを選択した場合、ナレッジベースを削除する前に Amazon OpenSearch Serverless のインデックス名を確認する必要があります。 ベクトルデータベース までスクロールし、 コレクション ARN をメモしてください。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID で、 UUID は ea50z3iuyaavwy8bymq4 のようなコレクションの一意の識別子になります 新しいタブまたはブラウザウィンドウで Amazon OpenSearch Service コンソールを開き、 Serverless の下にある Collections を選択し、このチュートリアルの一部として作成したコレクションを開きます。 ベクトルデータベースで確認した コレクション ARN と、 コレクション ARN が一致することを確認します。 arn:aws:aoss:REGION:AWSACCOUNTID:collection/ UUID ベクトルデータベースを削除するには コレクションを削除  を選択し、ダイアログボックスに 確認 と入力します。 Amazon Bedrock タブに戻り、ナレッジベースの削除の最後のステップを完了します。 削除  を選択し、ウィンドウに 削除 と入力します。 まとめ NOAA のデータ配信プログラムは、5 つの重要な目的のために環境データを共有しています。第一に、気象予報、緊急対応、海事・航空分野における輸送の安全性に関する重要な情報を提供します。第二に、科学者が気候研究、環境分析、トレンドモデリングを実施できるようにします。第三に、農業の収穫計画の支援、漁船団の航路最適化、観光事業の気象条件への適応など、産業全体の経済的意思決定をサポートします。第四に、公共データへのアクセスに関する連邦政府の要件を満たし、機関間の連携を強化します。第五に、気象モニタリングと環境研究の共有を通じて国際的なパートナーシップを支援します。このプログラムは、公的資金で収集された環境データは科学の発展と社会の利益のために自由に利用できなければならないという基本原則に基づいて運営されています。 AWS のオープンデータレジストリには、基盤モデルに追加のコンテキストを提供するために使用できる、650 以上のパブリックデータセットが含まれています。Amazon Bedrock は、AWS のオープンデータレジストリにあるパブリックデータセットの使用をサポートするようになったため、データセットのコピーを維持する必要がなくなりました。次のプロジェクトで使用できるデータセットがあるかどうか、レジストリをご確認ください。 リソース Amazon Bedrock ユーザーガイドの データをナレッジベースに変換する Amazon Bedrock ユーザーガイドの Amazon Bedrock でサポートされているデータ型 AWS のオープンデータについて詳しく学ぶ AWS のオープンデータレジストリでデータを探す Amazon Sustainability Data Initiative について詳しく学ぶ Chris Stoner Chris は AWS オープンデータチームのオープン環境・地理空間データ責任者です。以前は、 AWS Ground Station の主任プロダクトマネージャーとして、宇宙関連顧客向けの「サービスとしてのアンテナ」の開発を担当していました。また、アラスカ衛星施設 (ASF) 分散型アクティブアーカイブセンター (DAAC) で NASA の契約社員として働き、クラウド上での Sentinel-1 および NISAR ミッションのアーキテクチャを開発していました。Chris はマサチューセッツ大学アマースト校で MBA を、マサチューセッツ大学ローウェル校で IT 学士号を取得しています。技術系学術論文の著者であり、複数の特許を保有しています。

ここ、英国にも夏がやってきました! でも私は夏がちょっと苦手です。多くの人とは違い、外出時に「輝かしい太陽」を浴びることにそれほど熱心ではありません。とはいえ、夏は換気の良い快適な部屋でくつろぐための最高の口実になりますし、コーディングや最新の 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