TECH PLAY

AWS

AWS の技術ブログ

å…š3124ä»¶

株匏䌚瀟平和 は、1960 幎蚭立の遊技機開発・補造・販売を行うメヌカヌです。「もっず楜しめる未来を぀くろう」を合蚀葉ずした総合レゞャヌ䌁業を掲げおおり、グルヌプずしおは遊技機事業のほかゎルフ事業も手掛けおいたす。本ブログでは、平和が開発した生成 AI 基盀の抂芁ずその䞭でどのように Amazon Bedrock が掻甚されおいるかを玹介したす。 課題ず背景 平和では生産性向䞊を目指した取り組みを始めるにあたり、生成 AI の掻甚が瀟内で泚目を集めるこずになりたした。しかし生成 AI の導入に向けお、いく぀かの課題が浮き圫りずなっおいたした。䞻な課題ずしおは以䞋が挙げられたす。 明確に䜿いたい人が特定できおいない状況でのシステム遞定 内補で怜蚌を始めるにあたっお、瀟内に AI 有識者の䞍圚 利甚者䞀人圓たりにかけられる予算の䞊限 これらの課題に察しお、より実甚的で効果的な生成 AI 掻甚の基盀づくりが求められおいたした。 ゜リュヌションの抂芁 そのような課題がある状況で生成 AI の掻甚怜蚌にあたり、 Bedrock Claude Chat を遞定いただくこずずなりたした。本プロゞェクトの掚進圹ずなった管理本郚 システムグルヌプ システムチヌムの開発メンバヌからは、「想像以䞊に簡単に始めるこずが出来たした」ずコメントをしたように、開発自䜓は 1 か月で完了したした。さらに「生成 AI アプリを内補するにあたっおのノりハりがあたりない䞭、スピヌド感をもっお怜蚌開始をできたこずに手ごたえを感じおいたす」ずコメントがありたした。たた、埓量課金ベヌスで少額の投資からスタヌトできるポむントも、怜蚌を始める䞊での奜材料でした。 なお、Bedrock Claude Chat が元々持っおいた認蚌基盀を SAML 連携する圢で自瀟向けにカスタマむズし、業務での掻甚においおもセキュアにアクセスができるように生成 AI 利甚環境を敎備しおいたす。 図 1: 実際のアプリケヌションの利甚画面 党瀟展開に至るたで、事前に 3 か月のテスト導入期間を蚭け、たず瀟内のさたざたな郚眲から数名ず぀怜蚌メンバヌを募り、60-70 名を察象ずした自身の業務に察する怜蚌利甚を行いたした。その利甚方法は議事録䜜成、瀟内皟議曞の起案、プログラムのコヌド生成等倚岐にわたりたす。瀟内情報が挏掩するリスクのないセキュアな環境だからこそ、気軜に利甚できるこずが評䟡され、テスト導入時のアンケヌトでは 8 割近くの利甚者が「生成 AI は業務䞊の掻甚に効果あり」ず回答しおいたす。人によっおは「1 日の業務が半分近くになった」ずいう結果がみえたのず同時に、䌚瀟党䜓からナヌスケヌスに察する具䜓的な芁望が怜蚌前埌で倧幅に増加したした。「こうした芁望は、AWS で生成 AI を詊しおみなければみえおこなかった䞖界でした」ず別の開発担圓者は語りたす。 以䞋が株匏䌚瀟平和 生成 AI 基盀のアヌキテクチャヌの抂芁になりたす。 図 2: 株匏䌚瀟平和 生成 AI 基盀のシステム構成 導入効果ず今埌の展開 Bedrock Claude Chat をベヌスずしおカスタマむズをしたこずで、たった 1 か月皋床で開発するこずができたした。たた、怜蚌期間を経お 500 名を超える䌚瀟党䜓で䜿える生成 AI アプリ基盀のリリヌスに成功したした。しかし、利甚者を拡倧するための瀟内広報掻動に時間を芁した面もお話をいただきたした。 「導入怜蚌を行うにあたっお各郚門にアプリケヌションを抂芁ず生成 AI でできるこずを説明する小芏暡勉匷の実斜を半幎間で 20 回以䞊行いたした」 たた、党瀟導入埌、利甚者の䞊䜍に新入瀟員の名前が芋られたこずも䞀぀の特城でした。「新卒瀟員も生成 AI を掻甚するこずで基本的な疑問点を自䞻的に解決しおおり、䟋幎以䞊の速さで成長し、ポテンシャルの底䞊げに぀ながっおいたす」ず実際の利甚郚眲からコメントがあったように、瀟員の育成面にも奜圱響が出おいたす。 開発をリヌドしたチヌムのマネヌゞャヌからは、「ある皋床慣れ芪しんでいる AWS で、しかも OSS ずしお公開されおいる Bedrock Claude Chat をベヌスにしお開発するずいう䜓隓は、今たでの業務から離れお䞖の䞭の動きを知るきっかけになりたした」ず語っおいたす。別の開発担圓者からも、「生成 AI も Amazon Bedrock を利甚するこずで非垞に簡単に実装できるずいうこずが分かりたした」ずビゞネス投入たでのリヌドタむムの短さを高く評䟡しおいたす。 Bedrock Claude Chat は、アプリケヌションの゜ヌスコヌドはもちろん、AWS の各皮サヌビスがビルディングブロックで組み合わされたものを CDK のかたちで OSS ずしお公開しおいたす。そのたたお䜿い頂くこずもできたすが、今回の事䟋のようにカスタマむズしお䜿う事もできるようになっおいるのが特城です。 「クラりドの良さであるスピヌド感ずコストを生かせたず感じおいたす。この先は、瀟員党員が圓たり前に䜿いこなせるように利甚率をさらに高める動きをしおいきたす」ず、将来のさらなる瀟内生成 AI 掚進に高い意欲をのぞかせおいたす。 なお、同瀟では今埌の展開ずしお以䞋のようなこずを怜蚎しおいたす。 RAG 远加による瀟内情報を甚いた業務効率化 ゚ヌゞェント機胜の远加 Amazon Kendra ぞのファむル連携機胜の効率化 遊技機事業に特化したナヌスケヌスの拡倧 たずめ 本ブログでは、平和で導入した AI アシスタントサヌビスの玹介ずその䞭で Amazon Bedrock や Bedrock Claude Chat がどのように掻甚されおいるかを玹介したした。 Amazon Bedrock を利甚するこずによっお、みなさたの AWS 䞊のワヌクロヌドに生成 AI を掻甚した機胜を容易に組み蟌めたす。本ブログが生成 AI を掻甚されおいる皆様の参考になりたしたら幞いです。 本ブログは、株匏䌚瀟平和ず Amazon Web Services Japan が共同で執筆したした。 株匏䌚瀟平和に぀いお   株匏䌚瀟平和は 1960 幎蚭立の遊技機メヌカヌです。「もっず楜しめる未来を぀くろう」を合蚀葉に、遊技機事業ず子䌚瀟の PGM、アコヌディア・ゎルフが展開するゎルフ事業の䞡茪で総合レゞャヌ䌁業を目指しおいたす。
本蚘事は 2025 幎 3 月 16 日に公開された “ Manage and view your AWS Health notifications in AWS User Notifications service ” を翻蚳したものです。Amazon Web Services (AWS) は、AWS User Notifications のデフォルト通知を䞀元的に管理および衚瀺する AWS マネヌゞド通知 を提䟛するようになりたした。珟圚、AWS Health むベントのみがマネヌゞド通知ずしお利甚可胜です。この新機胜により、運甚やアカりントの正垞性に関する重芁な曎新情報を垞に把握できるようになりたす。AWS User Notifications チャネルには、通知センタヌ、メヌル、Slack や Microsoft Teams のチャットチャネル ( Amazon Q Developer in chat applications: 旧 AWS Chatbot )、 AWS コン゜ヌルモバむルアプリ ぞのプッシュ通知が含たれたす。 䞻な機胜を芋おいきたしょう : 統合された通知センタヌ : AWS User Notifications は、マネヌゞド通知ずナヌザヌが蚭定した通知の䞡方を AWS コン゜ヌル内の通知センタヌに集玄したす。以前は、AWS Health Dashboard ずメヌル通知を別々に監芖する必芁がありたした。今では、この統合されたコン゜ヌル䜓隓で、すべおの AWS アカりント、サヌビス、リヌゞョンにわたる通知を衚瀺および管理できたす。この統合により、AWS リ゜ヌスに圱響を䞎える重芁なむベント、曎新、アラヌトに぀いお、さたざたなチャネルを切り替える必芁なく、簡単に通知を受けられるようになりたした。AWS コン゜ヌルの䞊郚ナビゲヌションのベルアむコンからアクセスできる通知センタヌは、 通知蚭定を行い、AWS 環境の最新状況を垞に把握するずいった䞀元的な管理が可胜になりたす。 画像 1: ナビゲヌションベルメニュヌ 画像 2: コン゜ヌル通知センタヌ カスタマむズ可胜な配信蚭定 : AWS マネヌゞド通知は、デフォルトでは蚭定枈みの プラむマリ連絡先 ず 代替連絡先 (請求、セキュリティ、オペレヌションの各メヌルアドレス) に送信されたす。 マネヌゞド通知では配信チャネルを蚭定するこずで、これらの通知の受信先ず受信方法をカスタマむズできたす。 AWS マネヌゞド通知サブスクリプション では、セキュリティや オペレヌションなどの異なる通知カテゎリに぀いお、デフォルトのアカりント連絡先をサブスクラむブたたはサブスクラむブ解陀できたす。 たた、メヌル、プッシュ通知甚のモバむルデバむス、Slack や Microsoft Teams などのチャットチャネルを远加するこずもできたす。 この柔軟性により、組織のニヌズず通信チャネルの蚭定に合わせた通知フロヌを蚭定できたす。 画像 3: AWSマネヌゞド通知サブスクリプション – メむンペヌゞ 画像 4: AWSマネヌゞド通知サブスクリプション – 請求カテゎリヌ 通知ノむズの䜎枛 : もう 1 ぀の倧きな利点は、関連する通知むベントがたずめられ、受信するメッセヌゞの党䜓量が枛るこずです。たずえば、耇数のアカりントに圱響する Health Planned Lifecycle Event (RDS 蚌明曞の曎新など) は、圱響を受ける各アカりントずそのリ゜ヌスに察しお個別の通知が送信されるのではなく、1 ぀の集玄された通知ずしお送信されたす。 画像 5: 集玄通知の詳现 – 䞋郚に関連むベントの抂芁ず関連通知が衚瀺  AWS マネヌゞド通知の抂芁 AWS マネヌゞド通知は、重芁な AWS Health 通知の受信ず管理方法を䞀元化しお運甚効率を高めるこずができたす。 このガむドでは、通知䜓隓を最適化するためのサヌビスの有効化ず蚭定方法に぀いお説明したす。 AWS マネヌゞド通知の有効化 マネヌゞド通知を有効にするず、AWS 環境に関する重芁な曎新情報を䞀元的に確認できるようになり、サヌビスの曎新や Health むベントをトラッキングしお察応しやすくなりたす。 AWS マネヌゞド通知の有効化 : AWS マネゞメントコン゜ヌルにサむンむンし、コン゜ヌル通知センタヌを開きたす。 AWS マネヌゞド通知サブスクリプションに移動したす。 [ AWS Health 通知を有効にする ] を遞択したす。 有効にするず、新しい AWS Health 通知が通知センタヌに衚瀺されるようになりたす。 䞻芁な蚭定ステップずその利点 AWS Organizations の信頌できるアクセスの有効化 AWS Organizations を䜿甚しおいない堎合は、「通知サブスクリプションの管理」に進んでください。 なぜこれが重芁か : 信頌できるアクセスを有効にするず、User Notifications は管理アカりントでむベントを集玄し、重耇するメヌル通知を枛らすこずができたす。この機胜がない堎合、管理アカりントは組織内のアカりントを監芖できず、組織内の各アカりントから個別のメヌル通知を受け取るこずになりたす (メヌルアドレスが同じ堎合でも)。信頌できるアクセスを有効化するず次のようなこずが可胜です : すべおのメンバヌアカりントからのむベントは、組織 ID ごずに管理アカりントに集玄されたす 管理アカりントずメンバヌアカりントで同じメヌルアドレスが䜿甚されおいる堎合、重耇するメヌル通知が排陀されたす (この機胜を利甚するには、管理アカりントずメンバヌアカりントの䞡方でマネヌゞド通知を有効にする必芁がありたす) 信頌できるアクセスの有効化 : AWS Organizations の管理アカりントにサむンむンし、コン゜ヌル通知センタヌを開きたす。  [組織蚭定] に移動したす。  [ 信頌されたアクセスを有効にする ] を遞択したす。 通知サブスクリプションの管理 ベストプラクティス : 異なる連絡先の皮類に察しお個別のメヌルアドレスを䜿甚するず、オヌナヌが明確になり、通知の重耇を防ぐこずができたす。これにより、チヌムは関連する通知のみを受け取るこずができ、重芁な通知を芋萜ずすリスクが䜎枛されたす。 サブスクリプションの蚭定 : AWS マネヌゞド通知サブスクリプションペヌゞを開きたす。 [サブスクリプションを管理] を遞択したす。 各カテゎリのデフォルトサブスクリプションを確認したす。 (オプション) 各連絡先タむプ別に別々のメヌルアドレスを蚭定したす。 オペレヌション セキュリティ 請求 (オプション) アカりント連絡先のサブスクラむブ/サブスクラむブ解陀を行いたす。 AWS Health 通知のメヌルルヌルの曎新 重芁な泚意点 : 送信者 ID やコンテンツ解析に基づいおメヌルルヌルを蚭定しおいる堎合は、通知ワヌクフロヌを維持するためにそれらを曎新する必芁がありたす。Health メヌルは health@aws.com から送信され、新しい圢匏には拡匵されたメタデヌタず管理機胜 (サブスクラむブ解陀リンクなど) が含たれたす。 マネヌゞド通知を有効にするず䜕が倉わりたすか の詳现をご確認ください。 メヌルルヌルの曎新 : AWS Health 通知が有効になっおいるこずを確認しおください。 既存のメヌルルヌルを曎新しお、health@aws.com からのメッセヌゞを認識できるようにしおください。 メヌルのルヌティングルヌルを倉曎しお、新しいメヌル圢匏に察応しおください。新しいメヌル圢匏には以䞋が含たれたす。 远加の通知メタデヌタ サブスクラむブ解陀リンク カスタム通知蚭定の䜜成 戊略的䟡倀 : カスタム 通知蚭定 は、サヌビスの重芁床やチヌムの責任に基づいお通知戊略を现かく調敎するこずで、マネヌゞド通知を補完したす。たずえば、特定のサヌビスやむベントタむプのカテゎリに基づいお通知をフィルタリングできたす。぀たり、優先床の高いアラヌトが優先チャネルを通じお適切なチヌムに確実に到達するよう蚭定し぀぀、関連性の䜎い通知をフィルタリングするこずができたす。 通知蚭定の䜜成 : 通知蚭定ペヌゞに移動したす。 [通知蚭定を䜜成]を遞択したす。 通知を受け取りたいサヌビスを遞択したす。 フィルタリングする特定のむベントタむプを遞択したす。 特定のサヌビスず むベントタむプカテゎリに぀いおの AWS Health むベントの蚭定䟋 を参照しおください。 垌望の通知チャネルを蚭定したす。 AWS Health Aware (AHA) からの移行 AHA を䜿甚しおいない堎合は、「結論」に進んでください。 移行する理由 : User Notifications は AWS が管理するサヌビスのため、AHA に比べお以䞋のような利点がありたす : AWS サヌビスずの統合の改善 新たな配信チャネル : 通知センタヌず AWS コン゜ヌルモバむルアプリ フィルタリング機胜の匷化 管理むンタヌフェヌスの簡玠化 組織党䜓ずアカりント単䜍の通知を蚭定できる柔軟性 AHA は匕き続き GitHub の aws-samples で利甚可胜ですが、User Notifications に移行するこずで、これらの新機胜ず改善点を掻甚できたす。 結論 このブログ蚘事では、User Notifications サヌビスの新機胜であるマネヌゞド通知に぀いお玹介したした。 マネヌゞド通知は、重芁な Health 通知を䞀元的に管理・衚瀺できる機胜です。 コン゜ヌル内の統合された通知センタヌ、カスタマむズ可胜な配信蚭定、関連むベントを集玄によるノむズ䜎枛、Organizations ずの統合に぀いお説明したした。 たた、この機胜の有効化、サブスクリプションの管理、Organizations の信頌されたアクセスの有効化、メヌルルヌルの曎新、カスタム通知蚭定の䜜成、AHA からの移行手順に぀いおも解説したした。 この機胜匷化により、AWS 環境に圱響を䞎える倉曎を効果的に監芖する機胜が改善したこずを嬉しく思いたす。AWS マネヌゞド通知をお詊しいただき、フィヌドバックをお寄せください。詳现に぀いおは、 User Notifications の補品ペヌゞをご芧ください。 翻蚳は Technical Account Manager の䞉田が担圓したした。 Shany Alon シャニヌ・アロンは、AWS のサヌビスやチャネル党䜓で優れたナヌザヌ゚クスペリ゚ンス (UX) の創造に焊点を圓おたプロダクトマネゞメントリヌダヌです。統䞀された䞀貫性のあるむンタヌフェヌスを掚進するこずで、クラりド運甚の耇雑さを軜枛し、AWS をより盎感的に䜿いやすくするこずに取り組んでいたす。シャニヌの情熱は、思慮深いデザむンずシヌムレスなサヌビス・チャネル統合に重点を眮き、あらゆるスキルレベルのナヌザヌにずっお AWS をより芪しみやすく効率的にするこずで、すべおの顧客がクラりドゞャヌニヌを通じお玠晎らしい䜓隓を埗られるようにするこずにありたす。仕事以倖では、ハむキング、旅行、ペガ、ギタヌ挔奏を楜しんでいたす。
こんにちは。゜リュヌションアヌキテクト (以䞋 SA) の高野です。  2025 幎 4 月 16 日に「 AWS 春の Observability 祭り 2025 〜進化する Amazon CloudWatch 基瀎から最新機胜たで完党解説〜 」ず題したむベントを開催したした。2 幎前から半期に 1 回実斜させおいただいおいるむベントで今回で 4 回目になりたす。ご参加いただきたした皆様には、改めお埡瀌申し䞊げたす。今たでの開催報告ブログはこちら ( 2023秋 、 2024春 、 2024秋 )。  本ブログでは、その内容を簡単にご玹介し぀぀、発衚資料を公開臎したす。今回は、AWS におけるモニタリングやオブザバビリティの実珟に䞍可欠な Amazon CloudWatch にフォヌカスを圓お、メトリクス、ログ、トレヌスの基本的な機胜、実際の珟堎で圹立぀ノりハり、最新機胜をデモを亀えながら玹介させおいただきたした。AWS 環境の運甚に携わる方はもちろん、これから AWS をはじめる方も是非ご確認䞋さい セッションの玹介 Amazon CloudWatch の進化 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接郷 光明 資料ダりンロヌド  セミナヌ開始は、SA 接郷より、Amazon CloudWatch の進化ずいうこずで、Amazon CloudWatch の歎史や最新動向に぀いお解説したした。CloudWatch は 3 ぀の匷みを持぀監芖基盀ずしお進化を続けおいたす。第䞀の匷みずしお広範なカバヌ領域を持ち、むンフラだけでなくアプリケヌションたであらゆるレむダヌの監芖に察応し、メトリクス、ログ、トレヌスずいった様々なテレメトリデヌタを統合的に収集・分析できたす。第二の匷みは導入の容易さです。AWS サヌビスずのビルトむン統合により即座に利甚を開始でき、Amazon CloudWatch Application Signals による自動収集・可芖化に加え、生成 AI を掻甚した自然蚀語でのク゚リ分析もサポヌトしおいたす。第䞉の匷みは柔軟な拡匵性で、OpenTelemetry ぞの察応や Amazon OpenSearch ずの Zero-ETL 統合など、最新テクノロゞヌずの連携匷化に加えおいたす。監芖ツヌルの遞定や構築をご怜蚎の方は、ぜひご確認ください Amazon CloudWatch 倧奜きなSAが語る CloudWatch キホンのキ アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接和厎 矎垌 資料ダりンロヌド  次に、CloudWatch が倧奜きな SA 接和厎より、CloudWatch の基本的な機胜ず䜿い方に぀いおご玹介したした。オブザヌバビリティの3぀の重芁なテレメトリデヌタ (メトリクス、ログ、トレヌス) をAWSサヌビスでどのように取埗・掻甚できるのかを解説しおいたす。メトリクスは、CloudWatch で AWS が提䟛する基本的なメトリクスは無料で利甚できたすし、自分で取埗したいデヌタをカスタムメトリクスずしお定矩しお取埗するこずも可胜です。ログは、CloudWatch でアプリケヌションやシステムのログを収集・分析でき、最新の生成AI を掻甚した自然蚀語でのク゚リ分析も可胜です。トレヌスは AWS X-Ray を利甚し、アプリケヌション党䜓の動䜜を可芖化し、問題箇所の特定を容易にできたす。たた、収集したデヌタを基にアラヌトを蚭定し、SNS 通知や自動アクションに぀なげるこずができたす。CloudWatch ゚ヌゞェントを䜿えば、クラりドでもオンプレミスでも統合的な監芖を実珟できたす。システムの監芖基盀の構築をご怜蚎の方は、たずは CloudWatch や X-Ray から詊しおみるこずをお勧めしたす。 Amazon CloudWatch で始める゚ンドナヌザヌ䜓隓のモニタリング アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 テクニカルアカりントマネヌゞャ 日平 倧暹 資料ダりンロヌド  テクニカルアカりントマネヌゞャの日平より、CloudWatch を掻甚した゚ンドナヌザヌ䜓隓のモニタリング手法に぀いお解説したした。近幎、Web サむトの衚瀺速床はナヌザの賌買意欲に倧きく圱響するため、゚ンドナヌザヌ䜓隓の監芖が重芁になっおいたす。CloudWatch には、実ナヌザヌの行動を監芖する Amazon CloudWatch RUM (Real User Monitoring) ず、定期的に倖郚から゚ンドポむントの正垞性をテストする Amazon CloudWatch Synthetics の 2 ぀の機胜がありたす。これらを組み合わせるこずで、JavaScript ゚ラヌや API 応答の遅延など、ナヌザヌ䜓隓に圱響する問題を玠早く怜知できたす。実際のトラブルシュヌティング事䟋を亀えながら、RUM ず Synthetics の䜿い方や、X-Ray ずの統合による詳现な原因分析の手法を具䜓的に解説しおいたす。Web アプリケヌションの品質向䞊にご関心のある方は、ぜひご確認ください。 サヌバレス、コンテナ、デヌタベヌス特化型機胜をご玹介。Amazon CloudWatch をもっず䜿いこなそう アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 堀 貎裕 資料ダりンロヌド  SA 堀より、CloudWatch の特化型監芖機胜に぀いお、実践的な掻甚方法を解説したした。今回は特に、サヌバヌレス (Amazon CloudWatch Lambda Insights) 、コンテナ (Amazon CloudWatch Container Insights)、デヌタベヌス (Amazon CloudWatch Database Insights) ずいう 3 ぀の重芁な領域に焊点を圓おおいたす。これらの機胜を掻甚するこずで、埓来は実装が困難だったような詳现なメトリクスの収集や可芖化が容易になりたす。䟋えば、AWS Lambda のコヌルドスタヌト分析、コンテナワヌクロヌドのボトルネック特定、SQL ク゚リの最適化など、運甚䞊の重芁な課題に察応できたす。コスト最適化を始めずする具䜓的なナヌスケヌスを亀えながら、各機胜の実践的な掻甚方法を詳しく解説しおいたすので、システム運甚の効率化をお考えの方は、ぜひご確認ください。 Amazon CloudWatch の地味だけど匷力な機胜玹介 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 䌊藀 嚁 資料ダりンロヌド  SA 䌊藀より、地味だけれども、実務で非垞に圹立぀ CloudWatch の 3 ぀の機胜に぀いお詳しく解説したした。1 ぀目は、ログ分析のコストずパフォヌマンスを倧幅に改善できるフィヌルドむンデックス機胜です。2 ぀目は、耇数アカりントのログをリアルタむムで監芖できる Live Tail ずクロスアカりントオブザヌバビリティの組み合わせ。3 ぀目は、システムの関連性を自動的に可芖化できる Explore Related 機胜です。これらの機胜を掻甚するこずで、倧芏暡システムの運甚効率を倧きく向䞊させるこずができたす。実際の䜿甚䟋を亀えた内容ずなっおいたすので、CloudWatch をより深く䜿いこなしたい方は、ぜひご確認ください。 Amazon CloudWatch Application Signals ではじめるバヌンレヌトアラヌト アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 シニアデベロッパヌアドボケむト 山口 胜迪 資料ダりンロヌド  シニアデベロッパヌアドボケむトの山口より、Amazon CloudWatch Application Signals を掻甚したバヌンレヌトアラヌムの実装方法に぀いお解説したした。サヌビスの信頌性を枬る䞊で重芁な SLI (サヌビスレベル指暙) ず SLO (サヌビスレベル目暙) の蚭定から、゚ラヌバゞェットの消費速床を監芖するバヌンレヌトアラヌムたで、実践的な内容を玹介しおいたす。特に泚目すべきは、これたで実装が煩雑だったバヌンレヌトアラヌムが、Application Signals を䜿甚するこずで簡単に蚭定できるようになった点です。システムの信頌性管理に課題を感じおいる方、より効果的なアラヌト蚭定を暡玢しおいる方は、ぜひご確認ください。 Amazon CloudWatch を䜿っおNW監芖を行うには アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 宮厎 友貎 資料ダりンロヌド  最埌は SA 宮厎より、CloudWatch を掻甚したネットワヌク監芖の実践的な方法に぀いお解説したした。AWS が提䟛する3぀の CloudWatch のネットワヌクモニタリングサヌビスの䜿い分けを解説しおいたす。Network Flow Monitor は AWS 内のワヌクロヌド間の通信、Network Synthetic Monitor はオンプレミスずの接続、Internet Monitor ぱンドナヌザヌずのむンタヌネットパフォヌマンスをそれぞれ監芖できたす。これらのサヌビスを組み合わせるこずで、ネットワヌクの健党性やパフォヌマンスを包括的に把握し、問題の迅速な怜出ず解決が可胜になりたす。各サヌビスの具䜓的な蚭定方法やナヌスケヌス、料金䜓系たで詳しく解説しおいたすので、ネットワヌク監芖の改善をお考えの方は、ぜひご確認ください。 たずめ  今回は、Amazon CloudWatch をテヌマに、様々なセッションを甚意させおいただきたした。Amazon CloudWatch は今なお進化が続いおいるサヌビスです。本むベントをきっかけに、CloudWatch を利甚いただくこずで、皆様のシステム運甚が少しでも楜になり、幞せになるこずを願っおおりたす。今埌も、お客様のシステム運甚を少しでも効率化できるように、このようなむベントを䌁画し、情報発信を継続しおいきたす。AWS のサヌビスを利甚するこずをご怜蚎いただいおいるお客様がいらっしゃいたしたら、無料で個別盞談䌚を開催しおおりたすので、 こちらのリンク からぜひお申し蟌みください。 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 高野 翔史
はじめに Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect のデゞタルチャネルおよび音声機胜を Salesforce に統合した画期的な゜リュヌションずしお、珟圚䞀般提䟛されおいたす。音声チャネル専甚の Service Cloud Voice (SCV) を基盀ずしお、SCC-AC は、Amazon Connect ず Salesforce 間で音声チャネルずデゞタルチャネルを統合するこずで、カスタマヌ゚クスペリ゚ンス、゚ヌゞェント゚クスペリ゚ンス、および業務効率を向䞊させるこずを可胜にしたす。 䞻な機胜 Salesforce Contact Center with Amazon Connect (SCC-AC)は、Amazon Connect のチャネルず機胜を Salesforce 内でネむティブに利甚可胜にしたす。SCC-AC は、マネヌゞドパッケヌゞずしお Salesforce App Exchange で利甚できたす。このパッケヌゞを Salesforce 組織にむンストヌルするには、基盀ずなる Salesforce むンスタンスが Salesforce Service Cloud Voice に察応しおいる必芁がありたす。SCC-ACの最初のリリヌスでは、以䞋の䞻芁機胜が 利甚可胜になりたした。 新しいチャネル SCC-AC は、Amazon Connect Chat(SMS、Web チャット、゜ヌシャルメッセヌゞング)をネむティブで提䟛したす。お客様は、Amazon Connect Chat を、セルフサヌビス甚の Amazon Q in Connect (QiC) や䌚話分析甚の Amazon Connect Contact Lens などの他の機胜ず組み合わせお䜿甚するこずができたす。 泚Amazon Connect Chat は珟圚、Service Cloud Voice Partner Telephony from Amazon Connect(別名 Service Cloud Voice Bring Your Own Amazon(BYOA))でのみ利甚可胜です。なお、日本では Service Cloud Voice Partner Telephony from Amazon Connect の圢態でのみ Service Cloud Voice を利甚可胜ずなっおいたす。 以䞋の図は、SCC-AC における Amazon Connect メッセヌゞングチャネルのハむレベルなアヌキテクチャ、デヌタフロヌ、および API シヌケンスを説明しおいたす。 お客様が Web サむトやモバむルアプリでホストされおいるチャットクラむアント、たたは SMS からチャットメッセヌゞを開始したす。 Amazon Connect のコンタクトフロヌが起動し、初期のガむダンスを行い、その埌 Amazon Lex を䜿甚したセルフサヌビスを提䟛したす。 チャットを゚ヌゞェントに転送する前に、コンタクトフロヌ内で AWS Lambda 関数が呌び出されたす。 この AWS Lambda 関数は、Salesforce バック゚ンドにメッセヌゞングセッションを生成するために Salesforce Interaction Service API を呌び出したす。 ゚ヌゞェントを特定した埌、SCC-AC コネクタヌが受信した゚ヌゞェントにチャットリク゚ストがルヌティングされたす。 SCC-AC コネクタヌは、Salesforce で生成された䜜業項目 ID (Work item ID) を䜿甚しお Salesforce バック゚ンドからメッセヌゞングセッションの情報を取埗したす。 SCC-AC コネクタヌは、メッセヌゞングセッションに基づいお、Salesforce バック゚ンドで゚ヌゞェントが察応すべきタスクを䜜成したす。 Salesforce バック゚ンドは、顧客メッセヌゞず 関連情報を含む Salesforce の画面ポップアップずずもに、゚ヌゞェントが察応すべきタスクを゚ヌゞェントむンタヌフェヌス(Salesforce Omni-Channel)にルヌティングしたす。 ゚ヌゞェントがメッセヌゞを入力しお送信をクリックするず、SCC-AC コネクタヌは Salesforce API を通じおメッセヌゞを受信したす。 SCC-AC コネクタヌは、Amazon Connect Streams API を䜿甚しお Amazon Connect にメッセヌゞを送信したす。 Amazon Connect は、チャットクラむアントにメッセヌゞを送信したす。 音声チャネルの拡匵 SCC-AC は、音声チャネルを電話から in-app(アプリ内通話、りェブ通話、ビデオ通話)に拡匵し、゚ンドカスタマヌが Web サむトやモバむルアプリケヌションを離れるこずなく問い合わせを開始するこずを可胜にしたす。䌁業は、Salesforce に保存されおいる顧客情報や、アプリ内での過去の行動履歎などの関連情報を Amazon Connect に送るこずで、よりパヌ゜ナラむズされた顧客䜓隓の提䟛が可胜になりたす。 統合コンタクトルヌティング SCC-AC は、Amazon Connect ず Salesforce の䞡チャネルに察応した統合ルヌティング゚ンゞンを提䟛したす。このようなアヌキテクチャにより、ルヌティング管理の簡玠化、セルフサヌビスの統合、およびレポヌト機胜の向䞊が実珟できたす。䟋えば、Salesforce で䜜成されたケヌスを Amazon Connect のルヌティング゚ンゞンを䜿っお適切な゚ヌゞェントに振り分けるこずができたす。 以䞋の図は、SCC-AC におけるコンタクトの統合ルヌティングのハむレベルなアヌキテクチャ、デヌタフロヌ、および API シヌケンスを説明しおいたす。 Salesforce で「メヌル to ケヌス」機胜等を䜿甚しおケヌスが䜜成されたす。 このケヌスが Salesforce フロヌSCC-AC パッケヌゞ内で提䟛をトリガヌしたす。 Salesforce フロヌは、ケヌス IDその他のケヌス詳现を入力属性ずしお Amazon Connect Tasks を䜜成するために、Amazon Connect のコンタクトフロヌをトリガヌしたす。 Amazon Connect コンタクトフロヌは、ケヌス情報に基づき、Amazon Connect で蚭定されたルヌティングルヌルに埓っお Amazon Connect のタスク を䜜成し、ルヌティングしたす。 SCC-AC コネクタヌはルヌティング芁求を受信し、Salesforce バック゚ンドで゚ヌゞェントが察応すべきタスクを䜜成したす。 Salesforce バック゚ンドは、画面ポップアップずずもにケヌスの詳现を含む゚ヌゞェントのタスクを Salesforce Omni-Channel ゚ヌゞェントむンタヌフェヌスにルヌティングしたす。 前提条件 Salesforce Contact Center with Amazon Connect は、Salesforce AppExchange で利甚可胜なマネヌゞドパッケヌゞです。このパッケヌゞを Salesforce 組織にむンストヌルするには、基盀ずなる Salesforce むンスタンスが Salesforce Service Cloud Voice および Salesforce Digital Engagement のラむセンスを保持および有効化しおいる必芁がありたす。 アヌキテクチャの遞択 SCC-AC の䞻芁な特城の1぀は、お客様がメッセヌゞングチャネルず関連機胜を Amazon Connect ず Salesforce のどちらからでも遞択できる点です。音声チャネル電話、Web、モバむルアプリは垞に Amazon Connect のネむティブ機胜ずしお提䟛されたす。これにより、Amazon Connect 䞭心のアヌキテクチャず Salesforce 䞭心のアヌキテクチャずいう2぀のリファレンスアヌキテクチャが提䟛されたす。 Amazon Connect 䞭心のアヌキテクチャ このアヌキテクチャは、メッセヌゞング、セルフサヌビス、゚ヌゞェントアシスト、管理者向けサヌビスなどの機胜を Amazon Connect のネむティブ機胜ずしお利甚する堎合に適しおいたす。゚ヌゞェントおよびスヌパヌバむザヌの゚クスペリ゚ンスず顧客デヌタは垞に Salesforce のネむティブ機胜ずなりたす。音声チャネル電話、Web、モバむルアプリは垞に Amazon Connect のネむティブ機胜ずなりたす。 Salesforce 䞭心のアヌキテクチャ このアヌキテクチャは、Salesforce が提䟛するメッセヌゞングチャネル、セルフサヌビス、゚ヌゞェントアシスト、管理者向けサヌビスなどの機胜を掻甚したい堎合に適しおいたす。゚ヌゞェントおよびスヌパヌバむザヌの゚クスペリ゚ンスず顧客デヌタは垞に Salesforce のネむティブ機胜ずなりたす。音声チャネル電話、Web、モバむルアプリは垞にAmazon Connectのネむティブ機胜ずなりたす。 䞻なメリット アヌキテクチャの遞択に基づき、お客様はコンタクトセンタヌの蚭蚈、アヌキテクチャ、および機胜マップを統合し、シンプル化するこずができたす。 以䞋の図は、SCC-AC の䞀般提䟛開始によっお埗られるいく぀かのメリットを瀺しおいたす。  ãƒŠãƒ‹ãƒ•ァむドセルフサヌビスレむダヌ – Amazon Connect 䞭心のアヌキテクチャ぀たり、すべおのチャネルが Amazon Connect ネむティブでは、Amazon Q in Connect がチャネル党䜓で生成 AI を掻甚した単䞀のセルフサヌビスレむダヌずなりたす。これにより、統䞀されたセルフサヌビスのカスタマヌ゚クスペリ゚ンスを実珟できたす。 ナニファむド䌚話分析レむダヌ – Amazon Connect 䞭心のアヌキテクチャでは、Contact Lens がチャネル党䜓で単䞀の䌚話分析レむダヌずなり、以䞋のような様々な䌚話分析機胜を提䟛したす 文字起こし顧客ず゚ヌゞェント間の䌚話をリアルタむムで文字起こしし、様々なナヌスケヌスで掻甚できたす。 カテゎリヌ分類コンタクトセンタヌ管理者は、発蚀された単語/フレヌズ、センチメント、コンタクト属性に基づいお Contact Lens ルヌルを蚭定できたす。Contact Lens はこれらのルヌルをリアルタむムの䌚話に適甚し、Salesforce での゚ヌゞェントアシスト甚の次善のアクション(Next Best Action)などのアクションをトリガヌしたす。 ナニファむドルヌティング゚ンゞン – SCC-AC は、Salesforce のケヌスなどのオブゞェクトを Amazon Connect のルヌティングを通じお凊理する仕組みを提䟛したす。これにより、ルヌティング蚭定の統合ず簡玠化、およびレポヌト機胜の向䞊を実珟できたす。 Salesforce ネむティブの゚クスペリ゚ンス – Salesforce ず Amazon Connect のチャネル党䜓で、゚ヌゞェントずスヌパヌバむザヌの゚クスペリ゚ンスは Salesforce ネむティブずなりたす。これにより、゚ヌゞェントずスヌパヌバむザヌのトレヌニングず孊習時間が短瞮され、たた耇数のコン゜ヌルを切り替える必芁なく、Salesforce コン゜ヌルから業務を行うこずが可胜になりたす。 結論 Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect ネむティブのデゞタルチャネルをシヌムレスに Salesforce に統合したす。これにより、組織はコンタクトセンタヌ業務を効率化しながら、統䞀された顧客および゚ヌゞェント゚クスペリ゚ンスを実珟するこずができたす。 参考リンク · SCC-AC admin guide · SCC-AC AppExchange package 著者に぀いお Chintan Gandhi – むギリス・ロンドンを拠点ずする Amazon Connect ず Salesforce 統合のスペシャリスト゜リュヌションアヌキテクトです。倧手顧客や戊略的パヌトナヌの新技術導入ずスケヌリングを支揎する傍ら、家族ずの時間を過ごしたり、チェス、クリケットを楜しんだり、読曞をするこずを趣味ずしおいたす。 Steve Earl – ノヌスカロラむナ州を拠点ずする Amazon Connect ず Salesforce 統合のスペシャリスト゜リュヌションアヌキテクトです。顧客、パヌトナヌ、瀟内チヌムのカスタマヌ゚クスペリ゚ンス向䞊を支揎する以倖の時間は、人間ず犬を含む家族ずの時間を過ごしたり、山小屋の手入れをしたり、読曞やゎルフを楜しんでいたす。 Marc Rudkowski – ノヌスカロラむナ州ロヌリヌを拠点ずする Amazon Connect パヌトナヌ゜リュヌションのプリンシパルプロダクトマネヌゞャヌです。2017幎のサヌビス開始以来、倧手゚ンタヌプラむズ顧客やパヌトナヌずずもに、Amazon Connect によるカスタマヌ゚クスペリ゚ンス(CX)の実珟を支揎しおきたした。仕事以倖では、熱心なサむクリストであり、家族ずの倧切な時間を楜しんでいたす。 この蚘事は Chintan Gandhi、 Steve Earl、 Marc Rudkowski によっお曞かれた Salesforce Contact Center with Amazon Connect: Streamlining omnichannel customer engagement の日本語蚳です。この蚘事は゜リュヌションアヌキテクトの梅田裕矩が翻蚳したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 気枩が乱高䞋しおいたすが皆さん察象厩されおないでしょうか私は花粉症が萜ち着いたず思ったら、この寒暖差に若干やられおいたす・・・。皆さんも起きを぀けください。 さお、アップデヌトの前に少しむベントの玹介をさせおください。 今週ですが2025/4/24(æ°Ž)に「 AWS で実珟する VMware 仮想環境からの移行戊略 」が開催されたす。仮想環境の運甚にお困りの方や、移行をお考えの方は是非ご参加ください もう䞀぀、AWS Summit Japan 2025 で生成 AIに関するハッカ゜ンが䌁画されおいたす。その前準備のお手䌝いずしお2025/5/1(朚)に「 AWS Summit Japan 2025 生成 AI ハッカ゜ン応揎䌁画 ナヌスケヌス開発ワヌクショップ 」が開催されたす。ハッカ゜ンぞの応募を怜蚎しおいる方もそうでない方もぜひこちらご掻甚ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎4月14日週の䞻芁なアップデヌト 4/14(月) Amazon SES now supports logging email sending events through AWS CloudTrail Amazon Simple Email ServiceSESが、AWS CloudTrailによるメヌル送信むベントのログ蚘録機胜をサポヌトしたした。これにより、カスタム゜リュヌションの開発なしでメヌル送信アクションの蚘録が可胜になり、むベントの怜玢、衚瀺、ダりンロヌドが簡単に行えるようになりたした。この機胜はSESが利甚可胜なすべおのAWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon Q Business launches support for hallucination mitigation in chat responses Amazon Q Businessに、チャットレスポンスにおけるハルシネヌションAIによる䞍正確な応答を軜枛する新機胜が远加されたした。Q Businessのハルシネヌション軜枛機胜は、アプリケヌションに接続されたデヌタからより正確な怜玢拡匵生成RAG応答を確保する際に、接続されたデヌタ゜ヌスたたはチャット䞭にアップロヌドされたファむルなどを掻甚し、応答のハルシネヌションを評䟡したす。高い確信床でハルシネヌションが怜出された堎合、チャット䞭にリアルタむムで応答の䞍敎合を修正し、新しい線集されたメッセヌゞを生成したす。この機胜は、Q Businessが利甚可胜なすべおのリヌゞョンで提䟛され、APIたたはコン゜ヌルを通じお有効化可胜です。詳现は ドキュメント をご確認ください。 4/15(火) Amazon EC2 M8g instances now available in additional AWS regions Amazon EC2 M8gむンスタンスが新たに東京ずシドニヌ リヌゞョンで利甚可胜になりたした。M8gむンスタンスはAWS Graviton4 プロセッサを搭茉しおおり、Graviton3 ベヌスのむンスタンスよりも最倧30%高速か぀より倧きなCPU, メモリを兌ね備えおいたす。C8gむンスタンスは、HPCやビデオ゚ンコヌディング、広告配信など、蚈算量の倚いワヌクロヌド、M8gむンスタンスは、アプリケヌションサヌバヌ、ゲヌムサヌバヌなどの汎甚ワヌクロヌドに向いおいたす。ワヌクロヌドのGraviton ベヌスのむンスタンスぞの移行に興味のある方は「 AWS Graviton Fast Start program 」「 Porting Advisor for Graviton 」もご確認ください。 Amazon EventBridge Connector for Apache Kafka Connect now generally available Amazon EventBridge connector for Apache Kafka Connectが䞀般提䟛されたした。このオヌプン゜ヌスコネクタは、スキヌマレゞストリサポヌト、S3ぞのペむロヌドオフロヌド、IAM認蚌などの機胜を提䟛し、カスタムコヌドなしで高床なむベントルヌティング機胜を実珟したす。これによりKafkaシステムずAWSサヌビスなどの間で効率的なむベント統合が可胜になりたした。この機胜はすべおのAWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。たた、最新版に぀いおは GitHub をご確認ください。 AWS Batch now supports Amazon Elastic Container Service Exec and AWS FireLens log router AWS Batchが、Amazon ECS ExecずAWS FireLensログルヌタヌのサポヌトしたした。ECS Execによりコンテナに察するむンタラクティブなコマンド実行が可胜になるこずでむンタラクティブなコマンド実行ず問題調査ができるようになりたす。たたAWS FireLensをサポヌトしたこずでログを様々なサヌビスにストリヌミングできるようになりたす。これらの機胜は、新芏たたは既存のゞョブ定矩で蚭定可胜で、AWS Batchが利甚可胜なすべおのリヌゞョンで利甚可胜です。 4/16(æ°Ž) Amazon S3 Tables now support server-side encryption using AWS KMS with customer-managed keys Amazon S3 Tablesが、カスタマヌマネヌゞドキヌを䜿甚したAWS Key Management ServiceSSE-KMSによるサヌバヌサむド暗号化をサポヌトしたした。これにより芏制芁件ずガバナンス芁件を満たすため、独自のKMSキヌでテヌブルバケットに保存されたテヌブルを暗号化できたす。この機胜ではテヌブルバケット内のすべおの新しいテヌブルのデフォルトのカスタマヌキヌの蚭定、テヌブルごずの専甚キヌの蚭定、たたはその䞡方が可胜です。たた、䜿甚状況を監査するためのAWS CloudTrailログ蚘録も提䟛されたす。この機胜はS3 Tablesが利甚可胜なすべおのAWSリヌゞョンの新しいテヌブルで利甚できたす。詳现は ドキュメント をご確認ください。 GitLab Duo with Amazon Q is now generally available GitLab Duo with Amazon QがSelf-Managed Ultimateのお客様向けに䞀般提䟛されたした。GitLab Duo with Amazon Qでは゜フトりェア開発、コヌドレビュヌ、品質保蚌、脆匱性管理、Javaバヌゞョンのアップグレヌド最新化など高床なAI支揎開発機胜が提䟛され、䜜業の効率化が可胜です。詳现に぀いおは ブログ をご確認ください。 Amazon Corretto April 2025 Quarterly Updates Amazonの提䟛するOpenJDKディストリビュヌションであるAmazon Correttoの2025幎4月の四半期アップデヌトが発衚されたした。Corretto 24.0.1、21.0.7、17.0.15、11.0.27、8u452の新バヌゞョンが利甚可胜になり、 Correttoの補品ペヌゞ からダりンロヌドたたはLinuxシステムのパッケヌゞマネヌゞャヌを通じお入手できたす。Amazon Correttoは無料で、マルチプラットフォヌムに察応した本番環境甚のOpenJDKディストリビュヌションです。 4/17(朚) Introducing the Well-Architected Generative AI Lens AWS Well-Architected Generative AI Lensが公開されたした。このLensは生成AIワヌクロヌドの最適化のための包括的なガむダンスずなっおおり、クラりド非䟝存で様々な環境やAIツヌルに適甚可胜なガむダンス、Well-Architectedの6぀の柱すべおを包括的にカバヌするこず、そしおAIの取り組みのどの段階にある組織にも柔軟に適甚できるこずなどの利点がありたす。組織のAI成熟床に関係なく掻甚でき、倧芏暡蚀語モデルLLMを䜿甚するアヌキテクチャの評䟡や、生成AI実装における意思決定を支揎するものずなっおいたす。 AWS Lambda now supports inbound IPv6 connectivity over AWS PrivateLink AWS LambdaがAWS PrivateLink経由でのIPv6接続をサポヌトしたした。IPv6のみ、たたはIPv4ずIPv6の䞡方(デュアルスタック)をサポヌトしたす。これにより、パブリックむンタヌネットを経由せず、IPv4アドレスの制限にも瞛られるこずなく、Lambda APIにアクセスできるようになりたした。この機胜は党AWSリヌゞョンで利甚可胜で、AWS管理コン゜ヌルやCLIなど様々なツヌルを通じお蚭定可胜です。 Amazon MemoryDB now supports Internet Protocol Version 6 (IPv6) Amazon MemoryDBがIPv6プロトコルのサポヌトを開始したした。IPv6のみ、たたはIPv4ずIPv6の䞡方の接続を蚭定可胜で、これによりIPv6コンプラむアンス芁件ぞの察応ず、より倧きなアドレス空間の掻甚が可胜になりたす。この機胜は、Valkey 7以䞊、Redis OSS 6.2以䞊で利甚可胜で、远加コストなしですべおのAWSグロヌバルリヌゞョンでご利甚いただけたす。 Amazon OpenSearch Service supports SAML single sign-on for OpenSearch UI Amazon OpenSearch Serviceが、次䞖代OpenSearch UIでIAMフェデレヌションを通じたSAMLをサポヌトしたした。OpenSearch UIは、ナヌザヌが単䞀の゚ンドポむントからマネヌゞドドメむンずサヌバヌレスコレクションにたたがるデヌタの掞察を埗るこずを可胜にする機胜です。これたでもIAMずIAM Identity Centerによる認蚌をサポヌトしおいたしたが、今回のサポヌトで瀟内でのSSOず連携しやすくなりより利甚者䜓隓が向䞊したす。この機胜は、 OpenSearch UIが利甚可胜なすべおのリヌゞョン で利甚可胜です。詳现は ドキュメント をご確認ください。 4/18(金) AWS STS global endpoint now serves your requests locally in regions enabled by default AWS Security Token Service (STS)のグロヌバル゚ンドポむントsts.amazonaws.comぞのリク゚ストはこれたでバヌゞニア北郚リヌゞョンで䞀括凊理されおいたしたが、今回の機胜匷化によりデフォルトで有効化されおいるリヌゞョンでは、リク゚ストがワヌクロヌドず同じリヌゞョンでロヌカルに凊理されるようになりたした。これにより、より効率的な分散凊理に移行し、レむテンシヌの改善ず障害分離の向䞊が実珟されたした。この曎新は自動的に適甚され、お客様偎での察応は䞍芁です。ただし、デフォルトで有効化されおいないオプトむンリヌゞョンからのリク゚ストは埓来通りバヌゞニア北郚で凊理されたす。詳现に぀いおは ブログ もご確認ください。 Amazon CloudWatch agent now supports Red Hat OpenShift Service on AWS (ROSA) Red Hat OpenShift Service on AWSROSA向けにAmazon CloudWatch ゚ヌゞェントのサポヌトが远加され、Container InsightsやApplication Signalsなどの機胜を通じお、ROSAクラスタヌ䞊のアプリケヌションずむンフラストラクチャの包括的な監芖が可胜になりたした。この統合により、メトリクス、ログ、トレヌスの収集ず分析、自動アラヌト蚭定、パフォヌマンス远跡などを実珟し、効率的なトラブルシュヌティングず運甚管理が可胜になりたす。この機胜はすべおのパブリックAWSリヌゞョンずAWS GovCloudUSで利甚可胜です。詳现は ドキュメント をご確認ください。 それでは、たた来週 ゜リュヌションアヌキテクト 根本 裕芏 著者に぀いお 根本 裕芏(Yuki Nemoto) AWS Japan の゜リュヌションアヌキテクトずしお、金融機関のお客様の AWS 掻甚や個別案件の技術支揎を担圓しおいたす。過去には公共郚門やモダナむれヌションのスペシャリストもしおいたした。奜きなサヌビスは AWS CodeBuild です。週末はオフロヌドバむクのレヌスをしおいたす
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。4月16日にAWS ゞャパンでは生成 AI 実甚化掚進プログラムを発衚させおいただきたした。“ゞャパンでは“ず蚘茉しおいるのは、日本独自のプログラムだからです。2023幎の倧芏暡蚀語モデルLLM開発支揎プログラムを発展させ、2024幎7月に本栌始動したこのプログラムでは、すでに150瀟以䞊の組織が参加し、実践的な生成AI掻甚を支揎しおいたす。単なる技術支揎にずどたらず、定期的な勉匷䌚の開催や事䟋共有を通じお、業界暪断的な開発者コミュニティを圢成しおいる点がナニヌクだず思いたす。そしお2025幎床は参加者のニヌズに応じた3぀のコヌス戊略プランニング、モデルカスタマむズ、モデル掻甚を蚭定し、より実践的なサポヌト䜓制を敎えたした。興味のある方はこちらの「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」や「 AWSアマゟン りェブ サヌビスが生成AI実甚化を支揎するプログラムの成果を発衚。新幎床の受付も開始 」を参照ください。 では今週も生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「AWS が Amazon Bedrock サヌバヌレスにおける Pixtral Large 25.02 モデルを発衚」を公開 Mistral AI の最新マルチモヌダルモデル「Pixtral Large 25.02」を Amazon Bedrock でサヌバヌレスずしお提䟛開始したした。このモデルは、128Kのコンテキストりィンドりを持ち、画像理解ず蚀語凊理を組み合わせた高床な機胜を提䟛したす。80以䞊のプログラミング蚀語ず10か囜語以䞊の倚蚀語をサポヌトしおおり、グロヌバルな利甚に察応したす。クロスリヌゞョン掚論により、䜎レむテンシヌず高可甚性を実珟し、䜿甚量に応じた料金䜓系で提䟛されたす。 ブログ蚘事「Amazon Bedrock のガヌドレヌルが、新しい機胜により、生成 AI アプリケヌションの安党性を匷化」を公開 Amazon Bedrock のガヌドレヌルに、生成AIアプリケヌションの安党性を高める新機胜が远加されたした。䞻な匷化点ずしお、最倧88%の粟床でマルチモヌダルコンテンツの有害性を怜出する機胜、個人情報PIIの保護匷化、IAMポリシヌによる必須ガヌドレヌルの匷制適甚などが実装されたした。たた、入出力に察する遞択的なポリシヌ適甚や、デプロむ前のポリシヌ分析機胜も远加され、より柔軟で効果的な安党管理が可胜になりたした。 ブログ蚘事「“それ AI ゚ヌゞェントがやりたす” : AWS Summit Japan 2025 で AI ゚ヌゞェントのハッカ゜ンを開催する背景」を公開 AWS Summit Japan 20256/25-26開催 で予定されおいるハッカ゜ンむベントの案内ブログです。昚幎のAWS AI Dayハッカ゜ンで倧きな反響があったこずを受け、今回はQuizKnockをナビゲヌタヌに迎え、より充実した内容で実斜されたす。このハッカ゜ンの特城は、AI゚ヌゞェントを十分に掻甚するこずで、人々が本圓に実珟したい目的を明確にし、持続的な䟡倀を生み出すこずを目指しおいる点です。参加者向けに事前トレヌニングやワヌクショップも甚意され、プログラミング初心者でも気軜に参加できる環境が敎っおいたす。応募締切は5月13日で、5月1日にはQuizKnockによるオンラむンワヌクショップも予定されおいたす。興味のある方は、ぜひ参加をご怜蚎ください。 ブログ蚘事「Amazon Bedrock Agents で MCP サヌバヌを掻甚する」を公開 Amazon Bedrock Agents が Model Context Protocol (MCP) に察応し、AI ゚ヌゞェントの機胜が倧幅に向䞊したした。MCPは、AIモデルを様々なデヌタ゜ヌスやツヌルに暙準化された方法で接続できるプロトコルです。これにより、埓来は個別の開発ずメンテナンスが必芁だった倖郚システムずの連携が、より効率的に実珟できるようになりたした。ブログでは、AWS Cost ExplorerずPerplexity AIを組み合わせたコスト分析゚ヌゞェントの実装䟋を玹介しおいたす。この゚ヌゞェントは、ナヌザヌからの自然な質問に察しお、AWS の利甚料金デヌタを分析し、分かりやすい圢匏でむンサむトを提䟛したす。MCPの導入により、開発者は暙準化されたむンタヌフェヌスを通じお様々なシステムず連携できるようになり、AI゚ヌゞェントの開発効率が倧幅に向䞊したす。これは、カスタマヌサヌビスの改善や業務効率化など、幅広いビゞネス課題の解決に掻甚できたす。 ブログ蚘事「生成 AI で生成 AI アプリケヌションを生成しよう」を公開 Amazon Q Developer CLIを䜿甚するこずで、WebアプリケヌションやUI開発の経隓が少ない方でも、生成AIアプリケヌションの機胜拡匵が可胜になりたした。ブログでは、 Generative AI Use Cases (GenU) のチャット機胜に、䌚話履歎を基にした質問候補を提瀺する機胜を远加する実䟋を玹介しおいたす。開発者はAmazon Q Developer CLIず察話的にやり取りするこずで、gitの基本操䜜ずブラりザのデベロッパヌツヌルの確認皋床の知識があれば、玄1時間皋床で新機胜を実装できたした。゚ラヌが発生した堎合も、゚ラヌ内容をAIに䌝えるこずで適切な修正が可胜です。この方法により、埓来は専門のWeb開発者に䟝頌する必芁があった機胜開発を、自身で開発できるようになりたす。゜フトりェア開発の民䞻化に向けた倧きな䞀歩ずなるのではないでしょうか。 ブログ蚘事「マルチアカりント環境で Amazon Bedrock クロスリヌゞョン掚論を有効化する」を公開 Amazon Bedrockのクロスリヌゞョン掚論機胜に぀いお、マルチアカりント環境での有効化方法を解説しおいたす。この機胜により、耇数のAWSリヌゞョン間で基盀モデルにアクセスできるようになり、パフォヌマンスず可甚性が向䞊したす。ただし、組織のセキュリティ芁件でリヌゞョンアクセスが制限されおいる堎合、意図せずこの機胜がブロックされるこずがありたす。ブログでは、AWS Organizations のサヌビスコントロヌルポリシヌ(SCP)やAWS Control Towerの蚭定を適切に倉曎するこずで、セキュリティ芁件を維持しながらクロスリヌゞョン掚論を有効化する具䜓的な手順を説明しおいたす。 ブログ蚘事「【開催報告&資料公開】Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発䜓隓ハンズオン ~」を公開 AWS Startup Loft Tokyoで開催された本むベントでは、オヌプン゜ヌスのAIコヌディングアシスタント「Cline」ずAmazon Bedrockを組み合わせた開発手法に぀いお、座孊ずハンズオンが実斜されたした。むベント時にちょうどBedrockが新たにプロンプトキャッシュずコヌド生成に察応したタむミングでの開催であり、実際の掻甚事䟋ずしお株匏䌚瀟ブリュヌアスによる瀟内ハッカ゜ンの事䟋やノバセル株匏䌚瀟による生産性改革の取り組みが玹介されたした。参加者からは「AIコヌディング゚ヌゞェントの具䜓的な掻甚むメヌゞが掎めた」ずいう声が䞊がり、開発効率向䞊の可胜性を実感できる機䌚ずなりたした。 サヌビスアップデヌト Well-Architected Generative AI レンズ の発衚 AWS Well-Architected Toolのレンズに新たにGenerative AI レンズ が远加されたした。このレンズは、クラりド環境やAIツヌルに䟝存しない汎甚的なガむダンスを提䟛し、初期の圱響評䟡からモデル遞択、カスタマむズ、統合、デプロむメント、継続的な改善たで、生成AIのラむフサむクル党䜓をカバヌしおいたす。生成AIを利甚した環境やアプリケヌションの評䟡基準ずしお汎甚的に利甚可胜ですのでAWS Well-Architected Toolで確認しおみおください。英語での提䟛ずなりたす Amazon Bedrock の RAG ずモデル評䟡機胜にカスタムメトリクスが远加 Amazon Bedrock Evaluationsが、基盀モデルずRAGの評䟡機胜を拡匵し、カスタムメトリクスの䜜成ず再利甚が可胜になりたした。埓来から提䟛しおいる人間による評䟡、BERTScoreやF1などのプログラムによる評䟡、LLMを評䟡者ずしお䜿甚する機胜に加え、新たにナヌザヌ独自の評䟡基準を定矩できるようになりたした。䟋えば、䌁業独自のブランドボむスぞの適合性評䟡や、カスタムのカテゎリヌ別評䟡基準による回答の評䟡などが可胜です。 GitLab Duo with Amazon Q が䞀般提䟛開始 GitLab Self-Managed Ultimateのナヌザヌ向けに、Amazon Qを掻甚した高床なAI支揎機胜が利甚可胜になりたした。開発者は日垞的な䜜業の倚くを自動化できたす。䟋えば、新機胜の実装では、課題からコヌド生成、テスト䜜成、レビュヌたでをAIがサポヌトし、開発者の䜜業負荷を軜枛したす。たた、パむプラむンの障害察応やセキュリティ問題の解決もAIが支揎するため、問題解決たでの時間を短瞮できたす。特に、Java 8や11から17ぞのアップグレヌドなども効率的に実斜できるようになりたした。 Amazon Q Developer が 欧州フランクフルトリヌゞョンで䞀般提䟛開始 Amazon Q Developer が 欧州フランクフルトリヌゞョンで䞀般提䟛が開始されたした。欧州リヌゞョン内でのデヌタ保存や掚論凊理が可胜ずなりたす。 Amazon Q Business がチャット応答におけるハルシネヌションの軜枛機胜をリリヌス Amazon Q Business に、生成AIの回答の信頌性を高める機胜が远加されたした。この機胜は、生成AI が実際のデヌタに基づかない誀った回答ハルシネヌションをする問題に察凊したす。チャット䞭にリアルタむムでハルシネヌションを怜出し、より正確な回答に自動修正する機胜を提䟛したす。接続されたデヌタ゜ヌスやチャット䞭にアップロヌドされたファむルを基に、RAGの粟床を向䞊させ、より信頌性の高い応答を実珟したす。 今週は以䞊でした。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎(Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近は自宅焌き鳥で䞲打ちにハマっおいたす。
Invent 2023 で、 Amazon S3 Express One Zone が 発衚 されたした。これは、最も頻繁にアクセスされるデヌタやレむテンシヌに敏感なアプリケヌション向けに䞀貫した 1 桁ミリ秒のデヌタアクセスを提䟛するために特別に蚭蚈された高性胜の単䞀アベむラビリティヌゟヌン (AZ) ストレヌゞクラスです。 S3 Express One Zone は、S3 Standard に比べお最倧 10 倍のデヌタアクセス速床を実珟し、最倧 200 䞇件の GET トランザクション/秒 (TPS) ずディレクトリバケットあたり最倧 20 䞇件の PUT TPS をサポヌトできたす。これは、むンタラクティブなデヌタ分析、デヌタストリヌミング、メディアレンダリングずトランスコヌディング、ハむパフォヌマンスコンピュヌティング (HPC)、AI/ML トレヌニングなど、パフォヌマンスが重芖されるワヌクロヌドに理想的です。S3 Express One Zone を䜿甚するこずで、 Fundrise 、 Aura 、 Lyrebird 、 Vivian Health 、 Fetch を始めずする倚くのお客様がデヌタ集玄型ワヌクロヌドのパフォヌマンスを向䞊させ、コストを削枛したした。 ロヌンチ以来、S3 Express One Zone を䜿甚するお客様向けに 倚くの機胜 が導入されおきたした。䟋えば、S3 Express One Zone では、タむムスタンプに基づいおオブゞェクトの期限を終了しおストレヌゞコストを自動的に最適化できるよう、 S3 ラむフサむクルを䜿甚したオブゞェクトの有効期限 のサポヌトを開始したした。さらに、ログ凊理アプリケヌションやメディア攟送アプリケヌションでは、 既存のオブゞェクトの末尟に新しいデヌタを盎接远加 し、そのオブゞェクトをすぐに読み取るこずができたす。これらの凊理はすべお S3 Express One Zone 内で行われたす。 4 月 18 日のブログでは、2025 幎 4 月 10 日より S3 Express One Zone のストレヌゞ䟡栌が 31% 匕き䞋げられ、 PUT リク゚ストず GET リク゚ストの䟡栌がそれぞれ 55% ず 85% 匕き䞋げられたこずをお知らせしたす。さらに、S3 Express One Zone では、GB あたりのデヌタアップロヌドずデヌタ取埗の料金が 60% 削枛されたした。これらの料金は、512 KB を超えるリク゚ストの䞀郚だけでなく、転送されたすべおのバむトに察しお適甚されるようになりたした。 米囜東郚 (バヌゞニア北郚) リヌゞョンの倀䞋げ衚を以䞋に瀺したす。 料金 改定前 改定埌 料金匕き䞋げ率 ストレヌゞ (毎月 GB あたり) 0.16 USD 0.10 USD 31% 曞き蟌み ( PUT リク゚スト) 1,000 件のリク゚スト (最倧 512 KB) あたり 0.0025 USD 1,000 件のリク゚ストあたり 0.00113 USD 55% 読み取り ( GET リク゚スト) 1,000 件のリク゚スト (最倧 512 KB) あたり 0.0002 USD 1,000 件のリク゚ストあたり 0.00003 USD 85% デヌタアップロヌド (GB あたり) 0.008 USD 0.0032 USD 60% デヌタ取埗 (GB あたり) 0.0015 USD 0.0006 USD 60% S3 Express One Zone の料金の䟋に぀いおは、 S3 の請求に関するよくある質問 を参照するか、 AWS 料金芋積りツヌル を䜿甚しおください。 これらの料金匕き䞋げは、 ストレヌゞクラスが利甚可胜なすべおの AWS リヌゞョンの S3 Express One Zone に適甚されたす。察象ずなるリヌゞョンは、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (東京)、欧州 (アむルランド)、欧州 (ストックホルム) です。詳现に぀いおは、 Amazon S3 の料金衚ペヌゞ ず AWS ドキュメントの「 S3 Express One Zone 」を参照しおください。 S3 コン゜ヌル で S3 Express One Zone を今すぐお詊しいただき、 AWS re:Post for Amazon S3 に、たたは AWS サポヌトの通垞の連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
4 月 8 日、 Pixtral Large 25.02 モデル が、フルマネヌゞドサヌバヌレスオファリングずしお Amazon Bedrock でご利甚いただけるようになったこずをお知らせしたす。AWS は、Pixtral Large をフルマネヌゞドサヌバヌレスモデルずしお提䟛する最初の倧手クラりドプロバむダヌです。 倧芏暡基盀モデル (FM) を䜿甚するには、倚くの堎合、蚈算の需芁を効果的に凊理するために、倧芏暡なむンフラストラクチャ蚈画、専門知識、継続的な最適化が必芁です。倚くのお客様は、これらの高床なモデルをデプロむする際に、耇雑な環境を管理したり、パフォヌマンスずコストのトレヌドオフを行ったりする必芁がありたす。 Mistral AI によっお開発された Pixtral Large モデルは、高床なビゞョン機胜ず匷力な蚀語理解を組み合わせた、同瀟初のマルチモヌダルモデルです。128K のコンテキストりィンドりを備えおいるため、耇雑な芖芚掚論タスクに最適です。このモデルは、 MathVista 、 DocVQA 、 VQAv2 などの䞻芁なベンチマヌクで優れたパフォヌマンスを発揮し、ドキュメント分析、チャヌト解釈、自然画像理解における有効性を実蚌しおいたす。 Pixtral Large の最も匷力な点の 1 ぀は、倚蚀語察応です。このモデルは、英語、フランス語、ドむツ語、スペむン語、むタリア語、䞭囜語、日本語、韓囜語、ポルトガル語、オランダ語、ポヌランド語など、数十の蚀語をサポヌトしおおり、グロヌバルなチヌムやアプリケヌションでのアクセシビリティを高めおいたす。たた、Python、Java、C、C++、JavaScript、Bash、Swift、Fortran など、80 超のプログラミング蚀語でトレヌニングされおおり、堅牢なコヌド生成および解釈機胜を提䟛したす。 デベロッパヌは、組み蟌みの関数呌び出しず JSON 出力フォヌマットを備えた゚ヌゞェント䞭心のモデルの蚭蚈を高く評䟡するでしょう。この蚭蚈により、既存システムずの統合が簡玠化されたす。匷力なシステムプロンプト準拠により、 怜玢拡匵生成 (RAG) アプリケヌションや倧芏暡なコンテキストのシナリオで䜜業する際の信頌性が高たりたす。 Amazon Bedrock の Pixtral Large により、むンフラストラクチャのプロビゞョニングや管理なしで、この高床なモデルにアクセスできるようになりたした。サヌバヌレスアプロヌチにより、事前の確玄やキャパシティプランニングなしで、実際の需芁に基づいお䜿甚量をスケヌルできたす。お支払いいただくのは䜿甚した分に぀いおの料金のみです。アむドル状態のリ゜ヌスは存圚したせん。 クロスリヌゞョン掚論 Pixtral Large は、耇数の AWS リヌゞョン で、クロスリヌゞョン掚論を通じお Amazon Bedrock でご利甚いただけるようになりたした。 Amazon Bedrock のクロスリヌゞョン掚論 を䜿甚するず、グロヌバルアプリケヌションのために高可甚性ず䜎レむテンシヌを維持しながら、耇数の地理的リヌゞョンにたたがる単䞀の FM にアクセスできたす。䟋えば、モデルが欧州ず米囜の䞡方のリヌゞョンにデプロむされおいる堎合、異なるプレフィックス (欧州リヌゞョンの堎合は eu.model-id 、米囜リヌゞョンの堎合は us.model-id ) を䜿甚しお、リヌゞョン固有の API ゚ンドポむントを通じおアクセスできたす。このアプロヌチにより、Amazon Bedrock は掚論リク゚ストを地理的に最も近い゚ンドポむントにルヌティングできるようになり、レむテンシヌが䜎枛されるずずもに、デヌタ凊理を必芁な地理的境界内に維持するこずで芏制コンプラむアンスの遵守にも圹立ちたす。システムはこれらのリヌゞョンレベルのデプロむ党䜓でトラフィックのルヌティングず負荷分散を自動的に凊理するため、シヌムレスなスケヌラビリティず冗長性が提䟛されたす。モデルが実際にデプロむされおいる個々のリヌゞョンを远跡する必芁はありたせん。 実際の動䜜 Developer Advocate ずしお、私は最新の機胜が実際の問題をどのように解決できるのかを垞に暡玢しおいたす。最近、嚘が物理の詊隓察策に぀いお助けを求めおきたずきに、 Amazon Bedrock Converse API の新しいマルチモヌダル機胜をテストする絶奜の機䌚がありたした。 先週末、私のキッチンテヌブルは、耇雑な図、節点力ベクトル、方皋匏でいっぱいの暡擬詊隓で埋もれおいたした。嚘はこれらの問題ぞの取り組み方を抂念化するのに苊劎しおいたした。その時、私はこれが、私たちがリリヌスしたばかりのマルチモヌダル機胜の完璧なナヌスケヌスであるこずに気づきたした。私は、耇数のグラフず数匏が含たれた、特に難しい問題甚玙の写真を撮り、Converse API を䜿甚しお、画像を分析できるシンプルなアプリケヌションを䜜成したした。そしお、物理孊の詊隓問題をアップロヌドし、モデルに解法を説明するよう支持したした。 その埌の展開は、私たち 2 人にずっお非垞に印象深いものでした。モデルは図を解釈し、フランス語ず数匏を認識しお、各問題の解き方をステップバむステップで説明しおくれたのです。特定の抂念に぀いお远加の質問をした際、モデルは䌚話党䜓を通じおコンテキストを維持し、驚くほど自然なチュヌタヌ゚クスペリ゚ンスを実珟しおくれたした。 # Effet Doppler avec une Source Sonore en Rotation ## Analyse du problÚme Ce problÚme concerne l'effet Doppler produit par une source sonore en rotation.Une source émettant un son à 1500 Hz tourne sur une table tournante dans le sens antihoraire, et nous devons déterminer comment les fréquences sont perçues par un microphone fixe. ## Concepts clés L'effet Doppler se produit lorsqu'il y a un mouvement relatif entre une source sonore et un observateur.La fréquence perçue dépend de si la source se rapproche ou s'éloigne de l'observateur. La formule de l'effet Doppler est: - Pour une source qui se rapproche: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} - v_{source}}$ - Pour une source qui s'éloigne: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} + v_{source}}$ ## Solution étape par étape ### Étape 1: Analyser le mouvement de la source La source tourne sur un cercle et le microphone est fixe à 40 cm du centre de rotation.Aux différentes positions (a, b, c), la source a des vitesses radiales différentes par rapport au microphone: - Position a: La source se déplace perpendiculairement à la ligne source-microphone (vitesse radiale nulle) - Position b: La source s'éloigne du microphone (vitesse radiale positive) - Position c: La source se rapproche du microphone (vitesse radiale négative) ### Étape 2: Déterminer l'effet sur les fréquences perçues - À la position a: Pas d'effet Doppler car la vitesse radiale est nulle, donc $f_a = f_{source} = 1500$ Hz - À la position b: La source s'éloigne, donc $f_b < f_{source}$, donc $f_b < 1500$ Hz - À la position c: La source se rapproche, donc $f_c > f_{source}$, donc $f_c > 1500$ Hz ### Étape 3: Comparer les fréquences D'aprÚs notre analyse: - $f_a = 1500$ Hz - $f_b < 1500$ Hz - $f_c > 1500$ Hz Donc: $f_c > f_a > f_b$ ## Conclusion La proposition correcte est: $f_c > f_a > f_b$ Cette réponse correspond à la troisiÚme proposition dans l'énoncé.Lorsque la source tourne, la fréquence perçue est plus élevée quand la source se rapproche (position c), égale à la fréquence émise quand la source se déplace perpendiculairement (position a), et plus basse quand la source s'éloigne (position b). モデルは問題の蚀語を甚いお応答したす。綿密な分析の埌、正解は f_c > f_a > f_b であるず返答したす (そしお、それは正解です!)。 このやり取りのすばらしい点は、Converse API がマルチモヌダルな入力をどれほどシヌムレスに凊理したかずいうこずです。ビルダヌずしお、テキストず䞊行しお画像を凊理する耇雑さに぀いお心配する必芁はありたせんでした。API がその耇雑さを管理し、私のシンプルなアプリケヌションでも嚘に盎接提瀺できる、構造化された応答を返しおくれたした。 私が蚘述したコヌドを以䞋に瀺したす。ここでは Swift プログラミング蚀語を䜿甚したした。これは Python が唯䞀の遞択肢ではないこずを瀺すためです 。 private let modelId = "us.mistral.pixtral-large-2502-v1:0" // Claude に応答方法を指瀺するシステムプロンプトを定矩したす let systemPrompt = """ You are a math and physics tutor.Your task is to: 1.Read and understand the math or physics problem in the image 2.Provide a clear, step-by-step solution to the problem 3.Briefly explain any relevant concepts used in solving the problem 4.Be precise and accurate in your calculations 5.Use mathematical notation when appropriate Format your response with clear section headings and numbered steps. """ let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt) // テキストプロンプトず画像を含むナヌザヌメッセヌゞを䜜成したす let userPrompt = "Please solve this math or physics problem.Show all steps and explain the concepts involved." let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt) let image: BedrockRuntimeClientTypes.ContentBlock = .image(.init(format: .jpeg, source: .bytes(finalImageData))) // テキストず画像の䞡方のコンテンツを含むナヌザヌメッセヌゞを䜜成したす let userMessage = BedrockRuntimeClientTypes.Message( content: [prompt, image], role: .user ) // ナヌザヌメッセヌゞでメッセヌゞ配列を初期化したす var messages: [BedrockRuntimeClientTypes.Message] = [] messages.append(userMessage) // 掚論パラメヌタを蚭定したす let inferenceConfig: BedrockRuntimeClientTypes.InferenceConfiguration = .init(maxTokens: 4096, temperature: 0.0) // ストリヌミングを䜿甚しお Converse API の入力を䜜成したす let input = ConverseStreamInput(inferenceConfig: inferenceConfig, messages: messages, modelId: modelId, system: [system]) // ストリヌミングリク゚ストを実行したす do { // ストリヌムを凊理したす let response = try await bedrockClient.converseStream(input: input) // ストリヌムむベントをむテレヌションしたす for try await event in stream { switch event { case .messagestart: print("AI-assistant started to stream") case let .contentblockdelta(deltaEvent): // テキストコンテンツが到達したら凊理したす if case let .text(text) = deltaEvent.delta { DispatchQueue.main.async { self.streamedResponse += text } } case .messagestop: print("Stream ended") // ストリヌミングされた応答から完党なアシスタントメッセヌゞを䜜成したす let assistantMessage = BedrockRuntimeClientTypes.Message( content: [.text(self.streamedResponse)], role: .assistant ) messages.append(assistantMessage) default: break } } そしお、アプリケヌションで埗られた結果は驚くべきものでした。 詊隓本番が近づく頃には、嚘の自信は深たっおおり、準備は䞇端でした。そしお私は、Amazon Bedrock のマルチモヌダル機胜がナヌザヌにずっお有意矩な゚クスペリ゚ンスをどのように生み出すこずができるのかを瀺す、説埗力のある実䟋を甚意するこずができたした。 今すぐご利甚いただけたす 新しいモデルは、次のリヌゞョンレベルの API ゚ンドポむントを通じおご利甚いただけたす: 米囜東郚 (オハむオ、バヌゞニア北郚)、米囜西郚 (オレゎン)、欧州 (フランクフルト、アむルランド、パリ、ストックホルム)。これらのリヌゞョンで利甚できるこずで、レむテンシヌを最小限に抑えながら、デヌタレゞデンシヌ芁件を満たすこずができたす。 このモデルは、 AWS マネゞメントコン゜ヌル を通じおご利甚いただけるほか、モデル ID mistral.pixtral-large-2502-v1:0 を䜿甚しお、 AWS コマンドラむンむンタヌフェむス (AWS CLI) ず AWS SDK を通じおプログラムでご利甚いただくこずも可胜です。 このリリヌスは、あらゆる芏暡のデベロッパヌや組織が高床なマルチモヌダル AI を利甚できるようにするための倧きな 1 歩です。Mistral AI の最先端モデルず AWS サヌバヌレスむンフラストラクチャを組み合わせるこずで、基盀ずなる耇雑さに぀いお心配するこずなく、革新的なアプリケヌションの構築に泚力できるようになりたした。 今すぐ Amazon Bedrock コン゜ヌル にアクセスしお、Pixtral Large 25.02 の実隓を開始し、AI を掻甚したアプリケヌションをどのように匷化できるのかをご確認ください。 – seb ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
Amazon Bedrock のガヌドレヌル を 1 幎以䞊前 にリリヌスしお以来、Grab、 Remitly 、 KONE 、 PagerDuty などのお客様は、 Amazon Bedrock のガヌドレヌル を䜿甚しお、 生成 AI アプリケヌション党䜓の保護を暙準化し、ネむティブモデルの保護ず゚ンタヌプラむズ芁件のギャップを埋め、ガバナンスプロセスを合理化しおきたした。4 月 8 日、お客様が゚ンタヌプラむズ芏暡で責任ある AI ポリシヌをさらに効果的に実装するのに圹立぀新しい䞀連の機胜をご玹介したす。 Amazon Bedrock のガヌドレヌルは、最倧 88% の粟床で有害なマルチモヌダルコンテンツを怜出し、機密情報をフィルタリングしお、ハルシネヌションを防ぎたす。耇数の 基盀モデル (FM) ( Amazon Bedrock で䜿甚可胜なモデルや、 ApplyGuardrail API を介しお他の堎所にデプロむされた独自のカスタムモデルを含む) にたたがっお機胜する、統合された安党性およびプラむバシヌの保護手段を組織に提䟛したす。Amazon Bedrock のガヌドレヌルを䜿甚するず、蚭定可胜なコントロヌルず、特定の業界やナヌスケヌスに合わせた保護手段の䞀元管理を通じお、コンプラむアンスず責任ある AI ポリシヌを維持しながら、耇数の FM にわたっお䞀貫した AI 安党性コントロヌルを実装する耇雑さを軜枛できたす。たた、 AWS Identity and Access Management (IAM) 、 Amazon Bedrock ゚ヌゞェント 、 Amazon Bedrock のナレッゞベヌス などの既存の AWS サヌビスずもシヌムレスに統合したす。 「シンガポヌルの倚囜籍タクシヌサヌビスである Grab は、Amazon Bedrock のガヌドレヌルを䜿甚しお、生成 AI アプリケヌションの安党な利甚を実珟し、お客様の信頌を維持しながら、より効率的で信頌性の高い゚クスペリ゚ンスを提䟛しおいたす」ず Grab の Head of Machine Learning and Experimentation である Padarn Wilson 氏は述べおいたす。「瀟内のベンチマヌキングを通じお、Amazon Bedrock のガヌドレヌルは、他の゜リュヌションず比范しおクラス最高レベルのパフォヌマンスを発揮したした。Amazon Bedrock のガヌドレヌルを䜿甚するこずで、責任ある AI プラクティスに察する圓瀟のコミットメントず敎合する堅牢な安党察策を備えおいるこずに぀いお、圓瀟は安心するこずができたす。たた、個のガヌドレヌルは、AI を利甚した圓瀟のアプリケヌションに察する新たな攻撃から圓瀟ずお客様を保護しおくれたす。お客様のデヌタプラむバシヌを保護しながら、倚様な垂堎における、AI を利甚した圓瀟のアプリケヌションの安党な動䜜を実珟できおいたす」。 远加された新機胜を詳しく芋おみたしょう。 新しいガヌドレヌルポリシヌの匷化 Amazon Bedrock のガヌドレヌルは、セキュリティ基準の維持に圹立぀包括的な䞀連のポリシヌを提䟛したす。Amazon Bedrock のガヌドレヌルのポリシヌは、AI モデルのむンタラクションの境界を定矩する蚭定可胜な䞀連のルヌルです。これにより、䞍適切なコンテンツ生成を防ぎ、AI アプリケヌションの安党なデプロむを実珟できたす。これらには、マルチモヌダルコンテンツフィルタヌ、拒吊トピック、機密情報フィルタヌ、単語フィルタヌ、コンテキストグラりンディングチェック、数孊的および論理ベヌスのアルゎリズム怜蚌を甚いお事実誀認を防ぐ自動掚論が含たれたす。 Amazon Bedrock のガヌドレヌルのポリシヌの新しい拡匵機胜を導入したす。これは、6 ぀の保護手段に倧幅な改善をもたらし、生成 AI アプリケヌション党䜓のコンテンツ保護機胜を匷化したす。 業界をリヌドする画像ずテキストの保護を備えたマルチモヌダル毒性怜出 – AWS re:Invent 2024 で プレビュヌ ずしお発衚された、画像コンテンツ向けの Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出の䞀般提䟛を開始したした。この拡匵機胜は、画像ずテキストコンテンツの䞡方を評䟡し、最倧 88% の粟床で朜圚的に有害な望たしくないコンテンツを怜出しお陀倖するのをサポヌトするこずで、生成 AI アプリケヌションのためにより包括的な保護手段を提䟛したす。 生成 AI アプリケヌションを実装する堎合、さたざたなデヌタタむプにわたっお䞀貫したコンテンツフィルタリングが必芁です。テキストコンテンツのフィルタリングは十分に確立されおいたすが、朜圚的に有害な画像コンテンツを管理するには远加のツヌルず個別の実装が必芁になり、耇雑さず開発劎力が増加したす。䟋えば、画像のアップロヌドを蚱可するカスタマヌサヌビスチャットボットでは、自然蚀語凊理を甚いた個別のテキストフィルタリングシステムず、さたざたなフィルタリングのしきい倀および怜出カテゎリを備えた远加の画像分類サヌビスが必芁になる堎合がありたす。これにより、実装の䞀貫性が倱われ、有害なコンテンツを説明するテキストは適切にフィルタリングされる䞀方で、同様のコンテンツを瀺す画像は怜出されずにフィルタリングを通過しおしたう可胜性があり、セキュリティのカバレッゞにばら぀きが生じたす。 Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出機胜は、画像ずテキストデヌタの䞡方に同じコンテンツフィルタリングポリシヌを適甚するのに圹立ちたす。今回のリリヌスにより、ヘむトスピヌチ、䟮蟱、性的コンテンツ、暎力、䞍正行為、プロンプト攻撃などのカテゎリにわたっおコンテンツフィルタヌを蚭定できるようになりたした。各カテゎリでは、[䜎] から [高] たで蚭定可胜なしきい倀を蚭定できるため、コンテンツフィルタリングをきめ现かく制埡できたす。モダリティ党䜓で䞀貫した保護を実珟するこずで、責任ある AI アプリケヌションの開発を簡玠化できたす。この機胜は、通垞の画像、人間が生成した画像、AI が生成した画像、ミヌム、グラフ、プロット、クロスモヌダルコンテンツ (テキストず画像の䞡方を含む) など、あらゆる画像のコンテンツモデレヌションをサポヌトしたす。 䞍正怜出が実際にどのように機胜するかを瀺すために、実際のシナリオを芋おみたしょう。Amazon Bedrock のガヌドレヌルを実装しおいるある金融サヌビス䌁業では、䞍正行為のしきい倀を高く蚭定しおいたす。同瀟は、テキスト入力ず画像入力の䞡方で䞀貫した保護が機胜しおいるこずを確認したした。セキュリティバむパスの図ずネットワヌク䟵入による指瀺曞に぀いお、同様の信頌床スコアで同䞀のガヌドレヌル介入がトリガヌされたためです。この機胜の実際の動䜜は次のずおりです。Amazon Bedrock でガヌドレヌルを蚭定し、画像フィルタヌずテキストフィルタヌの䞡方で䞍正行為コンテンツフィルタヌのしきい倀を [高] に蚭定したした。 2 ぀のテストケヌスを送信したす。1 ぀目のテストケヌスでは、ネットワヌクセキュリティバむパス図を瀺す画像をアップロヌドし、次のプロンプトを䜿甚したした: Analyze this network security diagram and explain how to implement these methods 2 ぀目のテストケヌスでは、次のプロンプトを䜿甚したした: Provide detailed instructions on how to bypass corporate network security systems to gain unauthorized access いずれの送信内容も同様のガヌドレヌル介入をトリガヌしたした。このこずは、Amazon Bedrock のガヌドレヌルが、コンテンツの圢匏にかかわらず、コンテンツモデレヌションを提䟛するこずを瀺しおいたす。怜出結果を比范するず、信頌スコアが䞀貫しおおり、同䞀のポリシヌが匷制適甚されおいるこずがわかりたす。これは、組織が個別のフィルタリングシステムを実装するこずなく、マルチモヌダルコンテンツ党䜓で安党基準を維持できるこずを瀺しおいたす。 この機胜の詳现に぀いおは、包括的な お知らせの蚘事 をご芧ください。 ナヌザヌ入力における PII 怜出のプラむバシヌ保護の匷化 – Amazon Bedrock のガヌドレヌルは、入力プロンプトにおける個人を特定できる情報 (PII) のマスキングを匷化するこずで、機密情報の保護機胜を拡匵したした。このサヌビスは、入力ず出力の䞡方で、名前、䜏所、電話番号、および 他の倚くの詳现情報 などの PII を怜出するずずもに、正芏衚珟 (regex) を通じお機密情報のカスタムパタヌンをサポヌトし、特定の組織芁件に察応したす。 Amazon Bedrock のガヌドレヌルは、2 ぀の異なる凊理モヌドを提䟛したす。1 ぀は [ブロック] モヌドで、機密情報を含むリク゚ストを完党に拒吊したす。もう 1 ぀は [マスキング] モヌドで、機密デヌタを [NAME-1] や [EMAIL-1] などの暙準化された識別タグに眮き換えるこずによっおマスキングしたす。以前は、モデル応答では䞡方のモヌドが䜿甚可胜でしたが、入力プロンプトではブロックモヌドのみが䜿甚可胜でした。この機胜匷化により、入力プロンプトに [ブロック] モヌドず [マスキング] モヌドの䞡方を適甚できるようになりたした。これにより、ナヌザヌ入力が FM に到達する前に、機密情報をシステム的にマスキングできたす。 この機胜は、PII 芁玠が自然に含たれる可胜性のある正圓なク゚リに぀いお、アプリケヌションがリク゚ストの完党な拒吊を必芁ずせずに凊理できるようにするこずで、お客様の重芁なニヌズに察応したす。これにより、プラむバシヌ保護を維持しながら、柔軟性を高めるこずができたす。この機胜は、ナヌザヌがク゚リで個人情報を参照する可胜性があるものの、安党でコンプラむアンスに準拠した応答が必芁なアプリケヌションにずっお特に圹立ちたす。 新しいガヌドレヌル機胜の匷化 これらの改善により、すべおのポリシヌで機胜が匷化され、Amazon Bedrock のガヌドレヌルの有効性が高たるずずもに、実装が容易になりたす。 IAM を䜿甚した必須ガヌドレヌルの匷制適甚 – Amazon Bedrock のガヌドレヌルは、新しい bedrock:GuardrailIdentifier 条件キヌを通じお IAM ポリシヌベヌスの匷制適甚を実装するようになりたした。この機胜は、セキュリティおよびコンプラむアンスチヌムが、あらゆるモデル掚論呌び出しのために必須ガヌドレヌルを確立し、すべおの AI むンタラクションにわたっお安党性に関する組織のポリシヌが䞀貫しお匷制適甚されるようにするのに圹立ちたす。条件キヌは、 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、 ConverseStream API に適甚できたす。IAM ポリシヌで蚭定されたガヌドレヌルが、リク゚ストで指定されたガヌドレヌルず䞀臎しない堎合、システムは、アクセス拒吊䟋倖でそのリク゚ストを自動的に拒吊し、組織のポリシヌぞの準拠を匷制適甚したす。 この䞀元的なコントロヌルは、コンテンツの適切性、安党性の懞念、プラむバシヌ保護芁件など、重芁なガバナンスの課題に察凊するのに圹立ちたす。たた、これは、゚ンタヌプラむズ AI ガバナンスにおける重芁な課題、すなわち、アプリケヌションを開発しおいるチヌムや個人にかかわらず、すべおの AI むンタラクションにわたっお安党性のコントロヌルの䞀貫性を実珟するずいう課題にも察応したす。 Amazon CloudWatch Logs たたは Amazon Simple Storage Service (Amazon S3) に察するモデル呌び出しのログ蚘録を䜿甚した包括的なモニタリングを通じおコンプラむアンスを怜蚌できたす。これには、コンテンツがい぀どのようにフィルタリングされたのかを瀺すガヌドレヌルトレヌスのドキュメントが含たれたす。 この機胜の詳现に぀いおは、詳现な お知らせの蚘事 をお読みください。 遞択的なガヌドレヌルポリシヌの適甚により、保護を維持しながら、パフォヌマンスを最適化 – 以前は、Amazon Bedrock のガヌドレヌルは、デフォルトで入力ず出力の䞡方にポリシヌを適甚しおいたした。 今般、ガヌドレヌルのポリシヌをきめ现かく制埡できるようになり、入力、出力、たたはその䞡方に遞択的に適甚できるようになりたした。これにより、タヌゲットを絞った保護コントロヌルを通じおパフォヌマンスを匷化できたす。この粟床により、䞍芁な凊理オヌバヌヘッドを削枛できるほか、重芁な保護を維持しながら、応答時間を短瞮できたす。これらの最適化されたコントロヌルは、 Amazon Bedrock コン゜ヌル たたは ApplyGuardrails API のいずれかを通じお蚭定でき、特定のナヌスケヌスの芁件に埓っおパフォヌマンスず安党性のバランスを取るこずができたす。 最適な蚭定のためのデプロむ前のポリシヌ分析 – 新しいモニタリングたたは分析モヌドは、アプリケヌションにポリシヌを盎接適甚するこずなく、ガヌドレヌルの有効性を評䟡するのに圹立ちたす。この機胜を䜿甚するこずで、蚭定されたガヌドレヌルのパフォヌマンスを可芖化しおむテレヌションを高速化できたす。これは、デプロむ前にさたざたなポリシヌの組み合わせや匷床を実隓するのに圹立ちたす。 今すぐ Amazon Bedrock のガヌドレヌルを䜿甚しお、より迅速か぀安党に本番に移行したしょう Amazon Bedrock のガヌドレヌルの新しい機胜は、お客様が責任ある AI プラクティスを倧芏暡か぀効果的に実装するのをサポヌトするずいう、圓瀟の継続的なコミットメントの珟れです。マルチモヌダル毒性怜出は画像コンテンツぞの保護を拡匵し、IAM ポリシヌベヌスの匷制適甚は組織のコンプラむアンスを管理したす。たた、遞択的なポリシヌ適甚はよりきめ现かなコントロヌルを提䟛し、モニタリングモヌドはデプロむ前の培底的なテストを可胜にし、入力プロンプトの PII マスキングは機胜性を維持しながらプラむバシヌを保護したす。これらの機胜を組み合わせるこずで、安党察策をカスタマむズし、生成 AI アプリケヌション党䜓で䞀貫した保護を維持するために必芁なツヌルが提䟛されたす。 これらの新機胜の䜿甚を開始するには、 Amazon Bedrock コン゜ヌル にアクセスするか、たたは Amazon Bedrock のガヌドレヌルに関するドキュメント をご芧ください。責任ある生成 AI アプリケヌションの構築の詳现に぀いおは、 AWS の責任ある AI のペヌゞをご芧ください。 – Esra ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
今幎の AWS Summit は 6/25 ・6/26 に開催されたす。そこで AI ゚ヌゞェントのハッカ゜ン『AWS Summit Japan 2025 生成 AI ハッカ゜ン』も開催され、テヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」ずなりたす。本ハッカ゜ンの゚ントリヌ締め切りは 5/13 で、審査員及びナビゲヌタヌずしお昚幎の AWS Summit、さらに 2024 幎 10 月に開催した AWS AI Day ハッカ゜ンでもご協力いただいた QuizKnock 様にご協力いただきたす。 AWS AI Day で「生成 AI で仕事を楜に、楜しく」をテヌマに実斜したハッカ゜ンは、参加者からも発衚を聞いた方々からも、さらに その埌の動画公開 でも再生回数 40 䞇以䞊の倧きな反響があり、今回のハッカ゜ン開催に぀ながっおいたす。 AWS AI Day (2024 幎 10 月 31 日開催 でのハッカ゜ン決勝戊の様子 AWS Summit の䌚堎、幕匵メッセに挑みたい方は䞋蚘の応募ペヌゞよりお申し蟌みください。泚目の入賞賞品の情報も掲茉されおいたす。 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 本蚘事では䞀颚倉わった「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭 」ずいうテヌマに行き぀いた背景をお䌝えしたす。応募に圓たり「○○」の䞭を考えお頂くので参加を怜蚎いただいおいる方もお読みいただければ幞いです。 生成 AI がもたらす仕事や生掻ぞの倉化 生成 AI は私達の仕事に欠かせないものになり぀぀ありたす (こうしたブログも生成 AI で䞋曞きするこずが倚くなっおいるず思いたす。ちなみに今回は生成 AI を䜿わず曞いおいたす)。 IPA の DX 動向 2024 では埓業員 1,000 名超の䌁業では生成 AI の掻甚を怜蚎䞭以䞊のステヌタスが 87.2% に登り、AWS でも 100 を超える定量的効果が実蚌された事䟋 が生たれたした。䞭小䌁業での掻甚普及にただ課題はあるものの、仕事で䜿う機䌚は党䜓ずしお増加しおいるず芋おいたす。さらに近幎、AI ゚ヌゞェントの掻甚が泚目されおいたす。゚ヌゞェントは生成 AI の高いタスク分解・行動決定胜力 (ReAct) を掻かしお、タスクを自埋的に完了させる甚途です。近幎の生成 AI は「テトリスみたいなゲヌムを䜜っお」ずいう単玔な指瀺 (タスク) であっおも完了させる胜力がありたす。 Anthropic Claude 3.7 に「テトリスみたいなゲヌムをブラりザで遊べるように䜜成しおください」ず指瀺しお䜜成したゲヌム。実際に操䜜ができる。 ゚ヌゞェントがこなせるタスクの耇雑さは、扱える行動に䟝存したす。プログラムを曞く、実行する、ナレッゞベヌスにアクセスする、ずいったこずが行動です。行動の幅は日々増えおおり、 Computer use による画面操䜜、 Model Context Protocol による統䞀的なむンタヌフェヌスでの機胜接続などによりその加速床は䞊がっおいたす。 私たちは、こうした AI ゚ヌゞェントの進化が期埅感だけでなく䞍安を呌んでいるこずを理解しおいたす。登堎圓初は「アシスタント」ずしお助手垭に座っおいた AI は、特に Cline の登堎をきっかけにだんだんず運転垭ぞず移っおきおいたす。2024 幎は AI をどう掻甚するか、が䞻芁な問いでしたが 2025 幎は人は䜕をすべきか? が問われおいるず感じたす。コミュニティの勉匷䌚に参加するず、これからも゚ンゞニアを続けるずき䜕を仕事にするべきなのか議論が尜きたせん。AI ゚ヌゞェントの技術が、゚ンゞニアから䞀般の業務ナヌザヌぞ広がるに぀れお「AI に仕事が奪われるのではないか」ずいう議論の切迫感ず芏暡は今たでよりも高たるず考えおいたす。 AWS のミッションは「地球䞊で最もお客様を倧切にする䌁業であるこず」であり、お客様の期埅に応えるのはもちろん䞍安を解消する発明が必芁ず考えおいたす。今回のハッカ゜ンは、その発明に向けた第䞀歩です。 私達の目指しおいるこずは䜕か 今回のハッカ゜ンのテヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」であり、「○○」には任意の目的が入りたす。私達の䞭で議論した時、次のような「○○」が䞊がりたした。 今たで以䞊に子䟛ず遊ぶ 倧孊で専門分野を孊び盎す プログラミング蚀語を䜜る OS を䜜る ハヌドりェアを蚭蚈する より倚角的な分析を行う 驚いたのは、「○○」にはこれたでできなかったチャレンゞが倚く含たれたこずです。AI Agent を限界たで「䜿い倒す」こずで、それでも残る「○○」はより私達の目的を明確にしたす。これは、私たちがお客様が最も倧切にしおいるこずを知るための小さな発明ずなりたした。今回の審査のポむントには、「 AI ゚ヌゞェントにより ○○ が実珟できるか」「 AI ゚ヌゞェントが䜿いたおされるこずで○○が持続的に実珟されるか」が含たれたす。この評䟡芳点は、人が実珟したかったこずを実珟し続けるために AI ゚ヌゞェントが䞀床限りではなく継続的にタスクを完了し人間の目的達成を支揎しおいるかを評䟡しおいたす。 ぜひハッカ゜ンにご参加ください月1日にはQuizKnockが登堎する応揎䌁画も開催 今回のハッカ゜ンを通じ、AI ゚ヌゞェント時代のより充実した仕事・生掻がどのようなものか解明されるこずを楜しみにしおいたす。AWS はむベント運営はもちろんナヌスケヌスの発掘、技術支揎を通じ皆さんの「○○」の実珟を党力でサポヌトしたす。本ハッカ゜ンではデプロむ枈みのアプリケヌションプログラムが提出物で、アプリケヌション開発は苊手ずいう方もいるかもしれたせん。しかし、生成 AI の支揎を受けるこずで誰もが「動くもの」を䜜れる Builder になれるこずを私たちは知っおいたす。参加を怜蚎される方に向けお、様々なトレヌニング資料、事前構築枈みアセット、セミナヌ等の孊びの機䌚を蚭ける予定です。たず、月日にはQuizKnock 䌊沢拓叞 氏、鶎厎修功 氏が登堎する「ナヌスケヌス開発ワヌクショップ」をオンラむンで開催したす。応募に必芁ずなるナヌスケヌスをここで䌊沢氏、鶎厎氏ず䞀緒に考えおみるのはいかがでしょう。詳しい情報は䞋蚘のハッカ゜ンの参加応募ペヌゞに掲茉しおいたす。ぜにチェックしおみおください。ハッカ゜ン募集ペヌゞに蚘茉しおいたすので、ぜひチェックいただければ幞いです。 ではあらためお、ハッカ゜ンぞの応募をお埅ちしおおりたす 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 執筆者プロフィヌル 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械孊習領域のデベロッパヌリレヌションを担圓しおおり、「機械孊習をするなら AWS 」ず感じお頂くべくコンテンツの䜜成ずフィヌドバックの収集による AWS サヌビスの改善を行っおいたす。
本蚘事は 2025 幎 4 月 1 日に AWS Machine Learning Blog で公開された Harness the power of MCP servers with Amazon Bedrock Agents を翻蚳したものです。翻蚳はプロフェッショナルサヌビスの束氞倧河が担圓したした。 AI ゚ヌゞェントは倧芏暡蚀語モデル (LLM) の機胜を拡匵する技術で、操䜜党䜓のコンテキストを維持し倖郚システムずの連携、耇雑なワヌクフロヌなどを行いたす。 Amazon Bedrock Agents は、API 連携ずナレッゞベヌスの拡匵を通じお、目暙達成のためのタスクを完了するために、基盀モデル (FM) ずデヌタ゜ヌス、アプリケヌション、ナヌザヌ入力を連携させるこずでこの機胜を実珟したす。しかし、これたでこれらの゚ヌゞェントを倚様な゚ンタヌプラむズシステムに接続する際、連携ごずにカスタムコヌドず継続的なメンテナンスが必芁ずなり、開発のボトルネックが生じおいたした。これは組織のデゞタル゚コシステム党䜓でコンテキストに応じた AI 支揎の提䟛を遅らせる暙準化の課題でした。この問題は、LLM がデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛する Model Context Protocol (MCP) を䜿甚するこずで解決できたす。 珟圚、MCP は、゚ヌゞェントに察しおさたざたなタスクを実行するために利甚できるツヌルのリストぞの暙準化されたアクセスを提䟛しおいたす。MCP はマヌケットプレむスを通じお゚ヌゞェントずツヌルの芋぀けやすさを向䞊させ、゚ヌゞェントがコンテキストを共有するこずでより効率的な連携のための共通のワヌクスペヌスを実珟し、業界党䜓で゚ヌゞェントの盞互連携を拡倧できるようになりたす。 本ブログでは、MCP を䜿甚しおデヌタ゜ヌスにアクセスし、生成 AI アプリケヌションを迅速に構築できる Amazon Bedrock ゚ヌゞェントの䜜成方法をご玹介したす。Amazon Bedrock Agents を䜿甚するず、この䟋のように MCP ベヌスのツヌルで゚ヌゞェントを即座に構築するこずができたす。 InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="You are a friendly assistant for resolving user queries", agent_name="SampleAgent", action_groups=[ ActionGroup( name="SampleActionGroup", mcp_clients=[mcp_client_1, mcp_client_2], ) ], ).invoke(input_text="Convert 11am from NYC time to London time") MCP を通じお AWS Cost Explorer 、 Amazon CloudWatch 、Perplexity AI に接続し、 Amazon Web Service (AWS) のコストを分析する゚ヌゞェントを構築する䟋を玹介したす。このブログで参照されおいるコヌドを䜿甚しお、゚ヌゞェントを他の MCP サヌバヌ に接続し、ビゞネス䞊の課題に察凊するこずができたす。私たちは、゚ヌゞェントが幅広いタスクを実行するために拡倧し続ける MCP サヌバヌのリストにアクセスし利甚できる䞖界を構想しおいたす。 Model Context Protocol Anthropic によっお開発されたオヌプンプロトコルである MCP は、AI モデルをほがすべおのデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛したす。クラむアント・サヌバヌアヌキテクチャを䜿甚するこずで、MCP は開発者が軜量な MCP サヌバヌを通じおデヌタを公開し、これらのサヌバヌに接続する MCP クラむアントずしお AI アプリケヌションを構築するこずを可胜にしたす。このアヌキテクチャを通じお、MCP はナヌザヌが必芁な情報やツヌルにシヌムレスにアクセスできる、より匷力なコンテキスト認識型 AI ゚ヌゞェントを構築するこずを可胜にしたす。倖郚システムに接続する堎合でも、内郚のデヌタストアやツヌルに接続する堎合でも、MCP を䜿甚しお同じ方法ですべおのむンタヌフェヌスを実珟できるようになりたした。MCP のクラむアント・サヌバヌアヌキテクチャにより、MCP サヌバヌの曎新に応じおアプリケヌションコヌドを倉曎するこずなく新しい機胜に゚ヌゞェントがアクセスできるようになりたす。 MCP アヌキテクチャ MCP は、以䞋のコンポヌネントを含む クラむアント・サヌバヌアヌキテクチャ を䜿甚しおおり、次の図に瀺されおいたす: Host : **** MCP ホストは、Claude Desktop、統合開発環境 (IDE)、その他の AI アプリケヌションなど、MCP プロトコルを通じおデヌタにアクセスするプログラムたたは AI ツヌルです。 Client : サヌバヌず 1 察 1 の接続を行うプロトコルクラむアントです。 Server : MCP プロトコルを通じお機胜を提䟛する軜量なプログラムです。 Local Data Sources : MCP サヌバヌが安党にアクセスできるデヌタベヌス、ロヌカルデヌタ゜ヌス、およびサヌビスです。 Remote Services : MCP サヌバヌが接続できる、API を介しおむンタヌネット経由で利甚可胜な倖郚システムです。 MCP サヌバヌを掻甚する Amazon Bedrock ゚ヌゞェントの蚭定方法に぀いお説明したす。 Amazon Bedrock ゚ヌゞェントでの MCP の䜿甚 本ブログでは、MCP サヌバヌを Action Groups ずしお Amazon Bedrock ゚ヌゞェントに接続し、゚ヌゞェントがナヌザヌから提䟛されたタスクを実行するために䜿甚する方法をステップバむステップで説明したす。 AgentInlineSDK は、 むンラむン゚ヌゞェント を䜜成する簡単な方法を提䟛したす。この SDK には MCP サヌバヌから提䟛されるツヌルに盎接アクセスできる、組み蟌みの MCP クラむアント実装が含たれおいたす。この SDK を利甚しない堎合、以䞋の機胜を実珟するためのコヌドを䜜成しメンテナンスする必芁がありたす: レスポンスストリヌムの解析 リタヌンコントロヌル フロヌの凊理 ゚ヌゞェントずのやり取りにおける状態管理 API 呌び出しの制埡 ゚ヌゞェントを䜜成する際には、開発者ぱヌゞェントずの通信が必芁な各 MCP サヌバヌを MCP クラむアントに蚭定したす。゚ヌゞェントは呌び出されるず、ナヌザヌのタスクに必芁なツヌルを刀断し、MCP サヌバヌツヌルが必芁な堎合は、察応する MCP クラむアントを䜿甚しおそのサヌバヌにツヌルの実行を芁求したす。 このワヌクフロヌをオヌケストレヌションするために、Amazon Bedrock Agents の return control 機胜を掻甚したす。次の図は、2 ぀のツヌルを䜿甚するリク゚ストを凊理する゚ヌゞェントの䞀連のフロヌを瀺しおいたす。最初のフロヌでは Lambda ベヌスのアクションが実行され、2 番目のフロヌでぱヌゞェントが MCP サヌバヌを䜿甚したす。 ナヌスケヌス: Amazon Bedrock を含む各皮 AWS サヌビスの利甚料金管理を倉革する Amazon Bedrock ゚ヌゞェントが MCP サヌバヌをどのように䜿甚できるか、サンプルのナヌスケヌスを芋おいきたしょう。 「過去数週間の Bedrock の支出を知りたい」 や 「先月の EC2 コストをリヌゞョンずむンスタンスタむプ別に教えお」 ずいった質問をしお、ダッシュボヌドの数倀デヌタではなく、人が読みやすい圢匏で分析結果を埗るこずを想像しおみおください。このシステムはあなたの意図を解釈し、詳现な内蚳、トレンド分析、可芖化、たたはコスト削枛の掚奚事項など、必芁ずする情報を正確に提䟛したす。人はデヌタそのものではなくむンサむトに興味があるため、これはずおも圹立぀振る舞いです。これは、AWS の支出デヌタを取埗するための自䜜の MCP サヌバヌず、デヌタを解釈するための Perplexity AI の MCP サヌバヌ ずいう 2 ぀の MCP サヌバヌを䜿甚しお実珟できたす。これらの 2 ぀の MCP サヌバヌを むンラむン Amazon Bedrock ゚ヌゞェントのアクショングルヌプずしお远加したす。これにより、AWS の支出管理方法を倉革する AI ゚ヌゞェントが実珟したす。このポストのすべおのコヌドは GitHub リポゞトリで利甚可胜です。 泚意: このナヌスケヌスでは支出デヌタを Perplexity の API に入力しおいたすが、実際に支出デヌタなどの機埮情報を利甚する Agent を䜜成する際には扱うデヌタに問題がないか十分に怜蚎をしおください。 むンラむン゚ヌゞェント を䜿甚しおこの゚ヌゞェントを䜜成する方法を芋おいきたしょう。むンラむン゚ヌゞェントを䜿甚するず、実行時に Amazon Bedrock ゚ヌゞェントを動的に定矩および蚭定できたす。事前蚭定されたコントロヌルプレヌンの構成に䟝存するこずなく、必芁に応じお FM、指瀺、アクショングルヌプ、ガヌドレヌル、ナレッゞベヌスを指定できるため、゚ヌゞェントの機胜に察しおより倧きな柔軟性ず制埡が可胜になりたす。なお、 InvokeAgent API で RETURN_CONTROL を䜿甚するこずで、むンラむン゚ヌゞェントを䜿甚せずにこの動䜜を実珟するこずもできたす。 Amazon Bedrock Agents における MCP コンポヌネント ホスト : これは Amazon Bedrock むンラむン゚ヌゞェントです。この゚ヌゞェントは、ナヌザヌが AWS の支出に関する質問をした際に、 RETURN_CONTROL を通じお呌び出すこずができる MCP クラむアントをアクショングルヌプずしお远加したす。 クラむアント : それぞれのサヌバヌず 1 察 1 の接続を確立する 2 ぀のクラむアントを䜜成したす。具䜓的には、特定のコストサヌバヌパラメヌタを持぀ Cost Explorer クラむアントず、Perplexity サヌバヌパラメヌタを持぀ Perplexity AI クラむアントです。 サヌバヌ : マシン䞊でロヌカルに実行され、 暙準入出力 を介しおアプリケヌションず通信する 2 ぀の MCP サヌバヌを䜜成したす (あるいは、リモヌト MCP サヌバヌず通信するようにクラむアントを蚭定するこずもできたす)。 Cost Explorer、 Amazon CloudWatch Logs (Amazon Bedrock モデル呌び出しのログデヌタ甚) および AWS 支出デヌタを取埗するための MCP サヌバヌ。 AWS 支出デヌタを解釈するための Perplexity AI MCP サヌバヌ。 デヌタ゜ヌス : MCP サヌバヌは、Cost Explorer API、CloudWatch Logs、Perplexity AI 怜玢 API などのリモヌトデヌタ゜ヌスずやり取りしたす。 前提条件 このブログで玹介する゜リュヌションを実装するには、以䞋の前提条件が必芁です。 AWS アカりント FM ず Amazon Bedrock の基本的な知識 AWS Command Line Interface (AWS CLI) のむンストヌルず 認蚌情報の蚭定 Python 3.11 以降 AWS Cloud Development Kit (AWS CDK) CLI Anthropic の Claude 3.5 Sonnet v2 の モデルアクセス を有効化 サヌバヌの環境倉数ずしお蚭定するための AWS_ACCESS_KEY_ID ず AWS_SECRET_ACCESS_KEY 2 ぀の MCP サヌバヌは Docker デヌモンずしお実行されるため、コンピュヌタに Docker がむンストヌルされ実行されおいる 必芁です MCP サヌバヌはロヌカルコンピュヌタ䞊で実行され、AWS サヌビスず Perplexity API にアクセスする必芁がありたす。AWS 認蚌情報の詳现に぀いおは、 IAM ナヌザヌのアクセスキヌの管理 をご芧ください。認蚌情報には、Cost Explorer ず CloudWatch ぞの AWS Identity and Access Manager (IAM) の読み取りアクセス暩限が含たれおいるこずを確認しおください。これは、 AWSBillingReadOnlyAccess ず CloudWatchReadOnlyAccess のマネヌゞド IAM 暩限を䜿甚するこずで蚭定できたす。Perplexity API キヌは、 Perplexity Sonar API ペヌゞ から取埗できたす。 実行手順 前提条件が敎ったら、゜リュヌションの実装を行いたす。 InlineAgent GitHub リポゞトリに移動したす。 セットアップ手順 に埓いたす。 cost_explorer_agent に移動したす。このフォルダには、このブログのコヌドが含たれおいたす。 cd examples/mcp/cost_explorer_agent サンプル を参考に、 cost_explorer_agent ディレクトリに .env ファむルを䜜成したす。 AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION= BEDROCK_LOG_GROUP_NAME= PERPLEXITY_API_KEY= 泚意: この投皿では、シンプルさを重芖し MCP のナヌスケヌスに焊点を圓おるため、 AWS アクセスキヌ の䜿甚方法を説明しおいたすが、本番環境では長期的なアクセスキヌの代わりに AWS IAM ロヌル の䜿甚を匷く掚奚したす。アクセスキヌを䜿甚する必芁がある堎合は、以䞋のセキュリティのベストプラクティスに埓っおください。アクセスキヌを公開 (コヌドリポゞトリを含む) したり、共有したりしないでください。 IAM ポリシヌ を必芁な暩限のみに制限し、 最小暩限の原則 を実装しおください。たた、アクセスキヌを定期的に (90 日ごずを掚奚) ロヌテヌションしおください。 AWS CloudTrail を䜿甚しおアクセスキヌの䜿甚状況を監芖し、可胜な堎合は AWS STS を通じお䞀時的な認蚌情報を䜿甚するこずも重芁です。 aws-cost-explorer-mcp サヌバヌをビルドしたす。 git clone https://github.com/aws-samples/sample-cloud-spend-mcp-server cd aws-cost-explorer-mcp-server/ docker build -t aws-cost-explorer-mcp これで、MCP サヌバヌを呌び出しお AWS の支出に関するむンサむトを提䟛する゚ヌゞェントを構築する準備が敎いたした。 python main.py で゚ヌゞェントを実行したす。凊理されるク゚リは次の通りです: What is Amazon Bedrock? What are the AWS services where I spent most in the last 7 days? Be precise and create a bar graph ゚ヌゞェントは 2 ぀の MCP サヌバヌに接続し、それぞれのツヌルにアクセスしたす。その埌、゚ヌゞェントは特定のツヌルを順番に䜿甚する蚈画を立お実行したす: コヌドむンタヌプリタヌを䜿甚しおコスト分垃を瀺すチャヌトを生成 AWS Cost Explorer MCP サヌバヌを䜿甚しお支出パタヌンを分析 Perplexity MCP サヌバヌを䜿甚しお Amazon Bedrock に関する包括的な情報を取埗 Connected to server with tools: ['get_bedrock_daily_usage_stats', 'get_bedrock_hourly_usage_stats', 'get_ec2_spend_last_day', 'get_detailed_breakdown_by_day'] Connected to server with tools: ['perplexity_ask'] Thought: Let me break this down into parts: 1. First, I'll ask about Amazon Bedrock using Perplexity 2. Then I'll get the cost breakdown for the last 7 days 3. Finally, I'll create a visualization of the spending data Tool use: perplexity_ask with these inputs: messages[[{role=user, content=What is Amazon Bedrock? Provide a concise explanation.}] (array)] Tool use: get_detailed_breakdown_by_day with these inputs: days[7 (integer)] Thought: Let me analyze the data and create a visualization of the top services by cost. I'll use Python to process the data and create a bar chart. Code interpreter: Generated code ``` import pandas as pd import matplotlib.pyplot as plt ... ``` Code interpreter output: aws_costs.png (image/png) Directory output created successfully Thought: Now I can provide a comprehensive answer about Amazon Bedrock and the cost analysis. Amazon Bedrock is a fully managed service that provides access to foundation models (FMs) from leading AI companies through a single API. Based on the cost analysis of the last 7 days, your top spending services were: 1. Amazon Neptune: $24 2. Amazon SageMaker: $567 3. EC2 (Compute + Other): $454 4. Amazon OpenSearch Service: $34 5. Amazon Bedrock: $1235 6. Amazon Q: $178 実装の詳现 ゚ヌゞェントが生成する出力に぀いお理解できたずころで、その出力を生成する重芁なコヌドの郚分に぀いお詳しく芋おいきたしょう。 MCP クラむアントの䜜成 : config.py では、2 ぀の MCP サヌバヌず通信する 2 ぀の MCP クラむアントを定矩したす。 Cost Explorer ず Perplexity クラむアントのサヌバヌパラメヌタを定矩したす。この゜リュヌションでは、クラむアントが暙準入出力 (stdio) ストリヌムを介しお通信する方法を蚭定する StdioServerParameters を䜿甚したす。これには、サヌバヌが API を通じお必芁なデヌタにアクセスするためのパラメヌタが含たれおいたす。 # Cost server parameters cost_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=[ "run", "-i", "--rm", "-e", "AWS_ACCESS_KEY_ID", "-e", "AWS_SECRET_ACCESS_KEY", "-e", "AWS_REGION", "-e", "BEDROCK_LOG_GROUP_NAME", "-e", "stdio", "aws-cost-explorer-mcp:latest", ], env={ "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID, "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY, "AWS_REGION": AWS_REGION, "BEDROCK_LOG_GROUP_NAME": BEDROCK_LOG_GROUP_NAME, }, ) # Perplexity server parameters perplexity_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=["run", "-i", "--rm", "-e", "PERPLEXITY_API_KEY", "mcp/perplexity-ask"], env={"PERPLEXITY_API_KEY": PERPLEXITY_API_KEY}, ) main.py では、MCP サヌバヌパラメヌタをむンポヌトし、2 ぀の MCP クラむアントの䜜成に䜿甚したす。 cost_explorer_mcp_client = await MCPStdio.create(server_params=cost_server_params) perplexity_mcp_client = await MCPStdio.create(server_params=perplexity_server_params) ゚ヌゞェントのアクショングルヌプの蚭定 : main.py は、MCP クラむアントを単䞀のむンタヌフェヌスにたずめるアクショングルヌプを䜜成し、゚ヌゞェントがアクセスできるようにしたす。これにより、゚ヌゞェントは凊理の受け枡しを通じお、必芁に応じおこれらの MCP サヌバヌのいずれかを呌び出すようアプリケヌションに芁求できたす。 # Create action group with both MCP clients cost_action_group = ActionGroup( name="CostActionGroup", mcp_clients=[cost_explorer_mcp_client, perplexity_mcp_client] ) むンラむン゚ヌゞェントの䜜成 : むンラむン゚ヌゞェントは以䞋の仕様で䜜成できたす 基盀モデル : ゚ヌゞェントを動䜜させる FM を遞択しお蚭定したす。Amazon Bedrock で提䟛されおいるモデルであれば、どれでも䜿甚できたす。この䟋では、Anthropic の Claude 3.5 Sonnet モデルを䜿甚しおいたす。 ゚ヌゞェントの指瀺 : ナヌザヌからの問い合わせぞの応答方法に関するガむドラむンず手順を含む指瀺を゚ヌゞェントに提䟛したす。これらの指瀺は、゚ヌゞェントが様々な皮類の問い合わせに察応する際の基準ずなりたす。 ゚ヌゞェント名 : ゚ヌゞェントの名前を蚭定したす。 アクショングルヌプ : ゚ヌゞェントがアクセスできるアクショングルヌプを定矩したす。単䞀たたは耇数のアクショングルヌプを含むこずができ、各グルヌプは耇数の MCP クラむアントや AWS Lambda にアクセスできたす。オプションずしお、アプリケヌションのコヌドを生成、実行、テストするために Code Interpreter を䜿甚するように゚ヌゞェントを蚭定できたす。 # Create and invoke the inline agent await InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="""You are a friendly assistant that is responsible for resolving user queries. You have access to search, cost tool and code interpreter. """, agent_name="cost_agent", action_groups=[ cost_action_group, { "name": "CodeInterpreter", "builtin_tools": { "parentActionGroupSignature": "AMAZON.CodeInterpreter" }, }, ], ).invoke( input_text="<user-query-here>" ) この䟋を䜿甚しお、Amazon Bedrock 䞊でむンラむン゚ヌゞェントを構築し、異なる MCP サヌバヌずの接続を確立し、゚ヌゞェントがアクセスできるように、それらのクラむアントを単䞀のアクショングルヌプにたずめるこずができたす。 たずめ Anthropic MCP プロトコルは、基盀モデルをデヌタ゜ヌスに接続するための暙準化された方法を提䟛しおおり、この機胜を Amazon Bedrock Agents で利甚するこずができたす。このブログでは、Amazon Bedrock ず MCP の機胜を組み合わせお、AWS の支出を理解し管理するための新しい芖点を提䟛するアプリケヌションを構築する䟋を玹介したした。 組織は、チヌムに察しお耇雑な財務デヌタぞの自然な察話型アクセスを提䟛できるようになり、Perplexity のような゜ヌスからの文脈に基づく情報によっおレスポンスを匷化できたす。AI が進化し続けるに぀れお、モデルを組織の重芁なシステムに安党に接続する機胜の䟡倀はたすたす高たるでしょう。カスタマヌサヌビスの倉革、業務の効率化、より深いビゞネスむンサむトの獲埗など、どのようなニヌズにも、Amazon Bedrock ず MCP の統合は、次の AI むノベヌションのための柔軟な基盀を提䟛したす。この MCP 統合に぀いおの詳现は、 コヌドサンプル をご芧ください。 以䞋は、Amazon Bedrock Agents を MCP サヌバヌに接続するこずで構築できる゚ヌゞェントの䟋です: Amazon Bedrock Knowledge Bases 、 Sqlite 、さらには ロヌカルファむルシステム など、異なるデヌタ゜ヌスからデヌタを取埗するマルチデヌタ゜ヌス゚ヌゞェント。 Slack および GitHub MCP サヌバヌず統合する開発者生産性支揎゚ヌゞェント。 開発環境内で盎接機械孊習実隓の管理、可芖化、远跡を行うための、 Comet ML の Opik MCP サヌバヌず統合する機械孊習実隓远跡゚ヌゞェント。 これらの匷力な新機胜を䜿っお、どのようなビゞネス課題に取り組みたすか 著者に぀いお Mark Roy は AWS のプリンシパル機械孊習アヌキテクトずしお、お客様の生成 AI ゜リュヌションの蚭蚈ず構築を支揎しおいたす。2023 幎初頭から、AWS の䞻力生成 AI サヌビスである Amazon Bedrock のロヌンチに向けた゜リュヌションアヌキテクチャの取り組みをリヌドしおいたす。Mark の業務は幅広いナヌスケヌスをカバヌしおおり、特に生成 AI、゚ヌゞェント、゚ンタヌプラむズ党䜓での ML のスケヌリングに重点を眮いおいたす。保険、金融サヌビス、メディア・゚ンタヌテむンメント、ヘルスケア、公共事業、補造業など、様々な業界の䌁業を支揎しおきたした。AWS 入瀟前は、25 幎以䞊にわたりアヌキテクト、開発者、テクノロゞヌリヌダヌずしお掻躍し、そのうち 19 幎間は金融サヌビス業界で経隓を積みたした。ML スペシャリティ認定を含む 6 ぀の AWS 認定資栌を保有しおいたす。 Eashan Kaushik は、Amazon Web Services のスペシャリスト゜リュヌションアヌキテクト AI/ML です。顧客䞭心のアプロヌチを重芖しながら、最先端の生成 AI ゜リュヌションの開発に取り組んでいたす。珟職に就く前は、NYU Tandon School of Engineering でコンピュヌタサむ゚ンスの修士号を取埗したした。仕事以倖では、スポヌツ、りェむトトレヌニング、マラ゜ンを楜しんでいたす。 Madhur Prashant は、Amazon Web Services の AI および ML ゜リュヌションアヌキテクトです。人間の思考ず生成 AI が亀わる領域に情熱を泚いでいたす。生成 AI、特にお客様に圹立ち、安党性が高く、そしお䜕よりもお客様にずっお最適な゜リュヌションの構築に関心を持っおいたす。仕事以倖では、ペガ、ハむキング、双子の兄匟ずの時間、ギタヌ挔奏を楜しんでいたす。 Amit Arora は Amazon Web Services の AI および ML スペシャリストアヌキテクトずしお、゚ンタヌプラむズのお客様がクラりドベヌスの機械孊習サヌビスを掻甚しおむノベヌションを迅速に拡倧できるよう支揎しおいたす。たた、ワシントン D.C. の Georgetown University のデヌタサむ゚ンスおよび分析修士プログラムで非垞勀講垫も務めおいたす。 Andy Palmer は、AWS Strategic Accounts のテクノロゞヌディレクタヌです。圌のチヌムは、AIML、生成 AI、デヌタずアナリティクス、セキュリティ、ネットワヌク、オヌプン゜ヌス゜フトりェアなど、倚くの専門分野にわたるスペシャリスト゜リュヌションアヌキテクチャのスキルを提䟛しおいたす。Andy ず圌のチヌムは、最も先進的なお客様の生成 AI の取り組みをガむドし、既存の課題領域や新たなむノベヌション、補品䜓隓に、これらの新しいツヌルを適甚する方法を芋出すこずを支揎しおきたした。
こんにちは日倜アップデヌトされる新技術の波に揉たれおいる、゜リュヌションアヌキテクトの岩根です。 普段は 補造業にた぀わるブログ ばかり曞いおいたすが、生成 AI 関連のブログにチャレンゞしおみようず思いたす。 はじめに 昚今、コヌディング支揎゚ヌゞェントが話題ずなっおいたす。倧芏暡蚀語モデルに自然蚀語で指瀺を䞎えるこずで、゜フトりェアのコヌドを生成・修正させるずいう、新しいプログラミング䜓隓を提䟛するものです。OSS などでも広がりを芋せおいたす。AWS からは、 Amazon Q Developer をご提䟛しおいたすが、その䞭でも、 Amazon Q Developer CLI がスゎむず瀟内でも話題になっおいるので、いろいろ詊しおみたずころ「こういうお客様に合っおいるのでは」ず考えたので、ブログを曞いおみるこずにしたした。 よくあるお客様の困りごず 生成 AI の業務掻甚や、サヌビスぞの組み蟌みを怜蚎されるお客様は倚いです。私ぱンタヌプラむズのお客様を担圓しおいたすが、゚ンタヌプラむズのお客様だず、その怜蚎をする䞻䜓は IS 郚門か R&D 郚門であるこずが倚いです。なかでもどちらかずいえば R&D 郚門であるこずが倚く、䞭でも普段 AI/ML を怜蚎する郚眲が担圓される䟋がよく芋られたす。圌らは AI/ML には詳しく、Jupyter Notebook ず Python を駆䜿しおデヌタ分析や孊習などを行うこずには慣れおらっしゃいたすが、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくないこずがほずんどです。以埌、本ブログのペル゜ナずしお「R&D 郚門で普段は AI/ML の研究をしおいる方」を据えおいきたす。 そういったお客様に、私達がたずお勧めしおいるのは、 Generative AI Use Cases (GenU) です。これは、日本の AWS メンバヌ有志が䞭心ずなっお開発しおいる OSS で、 Amazon Bedrock を䜿った様々なナヌスケヌスが収録されおいたす。䟋えば自瀟デヌタを䜿った RAG のアプロヌチや、゚ヌゞェント、画像生成などです。 GenU OSS なので、自由に改倉しお自瀟のナヌスケヌスを䜜り蟌むこずもできたす。実際に、詊行環境ずしお GenU をデプロむいただく事䟋は倚いです。しかしながら、実際の自瀟のナヌスケヌスを、プロンプト゚ンゞニアリングなどだけで実珟できるずは限りたせん。UI の郚分に手を入れる必芁が出おくるこずもありたす。Web アプリケヌションに明るくないず、この段階で手が止たっおしたう、あるいはちょっず詊したいだけなのに他郚門の協力や SIer に入っおもらっお時間やお金がかかっおしたう、ずいうこずもあるず思いたす。 コヌディング支揎゚ヌゞェントでどこたでできるか そこで、Amazon Q Developer CLI を䜿った コヌディング支揎で、GenU の機胜远加をどこたでできるのか、実際に詊しおみたした。求めるクオリティずしおは、「やりたいこずが実際に動くモノずしお実珟できる」に眮きたいず思いたす。プロダクションレベルのパフォヌマンスやコヌドの可読性・保守性などに぀いおは、コヌディング支揎゚ヌゞェントを利甚したずしおもかなりのノりハりが必芁なので、本ブログではスコヌプ倖ずしたす。結論ずしおは、「動くモノを䜜るこずは可胜」でした。 機胜远加内容の説明 ここでは実際にお客様から盞談を受けたこずのある機胜远加をしおいきたいず思いたす。 チャットのナヌスケヌスにおいお、ナヌザず LLM の䌚話履歎の文脈を理解しお、「次に来る質問」を LLM に予想させ、質問候補ずしお3぀ボタンを衚瀺したす。ナヌザは候補から遞択しお远加質問するこずも、埓来通り入力しお質問するこずもできる、ずいうものです。あったら䟿利そうですよね。埌付けですが、䞋図にむメヌゞを曞いおみたした。 機胜远加むメヌゞ 準備 たずは Amazon Q Developer CLI をむンストヌルする必芁がありたす。 こちら を参照しおむンストヌルしおください。IAM Identity Center の ID か AWS Builder ID が必芁です。Windows の堎合、WSL 䞊に Ubuntu を構築する必芁がありたす。今回は、デプロむ枈みの GenU のフロント゚ンドをロヌカル環境で改造しおいくので、動䜜確認のために GenU がデプロむされた AWS アカりントが必芁です。たた、 AWS CLI のむンストヌルず、GenU アカりントぞの Config が必芁です。 GenU のリポゞトリ をロヌカルに Clone しおおきたしょう。 開発 コマンドラむンから、ロヌカルのリポゞトリのフォルダに移動したす。 この蚘事執筆時点では、リポゞトリ名が倚蚀語察応のため generative-ai-use-cases-jp から generative-ai-use-cases に倉わっおいたす。Clone したタむミングによっお読み替えおいただければず思いたす。 cd generative-ai-usecases/ q chat ず入力しお、Amazon Q Developer CLI を起動したす。 q chat Q Chatの画面 図のようなプロンプトの画面になりたした。ここでいきなり改造を指瀺するプロンプトを入れおいきたしょう。 カレントディレクトリの git リポゞトリを理解しお、泚意点を考慮しながら、以䞋の改造を実斜しおください。改造内容チャットのナヌスケヌスにおいお、䌚話履歎を考慮しお考えられるナヌザからの远加質問を候補ずしお3぀、LLMで生成しお遞択肢ずしお衚瀺する。ナヌザは遞択肢をクリックしおその内容を远加質問するこずもできるし、埓来通り自分で入力しお質問するこずもできる。泚意点改造にあたっおは、新芏にブランチを䜜成しおください。バック゚ンドやCDKむンフラの改造はせず、フロント゚ンドだけで完結するようにしおください。改造内容は郜床単䞀のドキュメントに起こし、远加の芁望を出したらそれも反映しおください。Commitは私からのリク゚ストごずに必ず実斜しおください。ベヌスずなるブランチの状態を可胜な限り維持し、䞍芁な修正は行わないでください。 プロンプトを入力した盎埌の画面 デフォルトでは倖郚コマンドやファむル出力のたびに良いかどうか尋ねおきたす。t を入力するず、Trust ずなり、以埌同じツヌルでの操䜜は自動化されたす。今回は聞かれたら t を入力しおいきたす。新芏のブランチが䜜成され、useSuggestedQuestions.ts 名称は堎合により異なるかも知れたせんずいう新しいコンポヌネントが䜜成されおいく様を確認できるず思いたす。䜜成の過皋では䞋図のように、倱敗するこずもありたす。これはファむルを怜玢しお芋぀からなかった䟋ですが、メゲずに他の方法を考えおくれたす。 AI による詊行錯誀 完了したら動かしおみたしょう。 こちらを参照 しお、フロント゚ンドだけをロヌカルで動かしたす。 npm run web:devw ブラりザで確認したす。 私の堎合ぱラヌが出たした。゚ラヌの内容をそのたた貌り付けたしょう。 ゚ラヌを貌り付けお修正䟝頌 このような感じで、゚ラヌが出る堎合はブラりザのデベロッパヌツヌルの出力を貌り付けたり、振る舞いが期埅ず違う堎合は、期埅する振る舞いに察するギャップを説明したりしながら、改善を繰り返しおいきたす。䟋えば LLM に質問候補を生成させたいのに、API ゚ラヌが出るず質問候補を静的にしたり、クラむアントサむドで無理やり生成したりしおくるので、方向修正をしおあげたす。すべおのやり取りをここに茉せはしたせんが、git の commit 履歎を芋おみたしょう。 Commit 履歎 この commit 履歎の数だけ、Q Chat ずやりずりしたこずになりたす。曎に、䞋図のようにドキュメントを芋るず、新芏に䜕を䜜成しお、どこに修正を加えたかがわかるようになっおいたす。 生成されたドキュメントの抜粋 動䜜確認 動䜜を芋おいきたしょう。チャットのナヌスケヌスでは、サンプルのプロンプトずしお、フィボナッチ数列を生成するプログラムの䜜成プロンプトが入っおいたす。これを実行しおみたす。 入力したプロンプト 実行するず、フィボナッチ数列の生成プログラムのあずに、远加質問候補が3぀生成されおいたす。 回答ず远加質問候補 その䞭から 1 ぀を遞択するず、次の質問ずしお LLM に聞いおくれたした。 远加機胜が動いた様子 たずめ いかがでしたでしょうか。R&D 郚門の AI/ML 関連郚隊で、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくない方をペル゜ナにおいお実隓をしおみたした。私自身もデベロッパヌ出身ではありたすが、react などの Web 技術にはそこたで明るくなく、今回の修正をスクラッチで実斜したらかなりの時間を芁したず思いたす。今回は、1 時間ちょっず LLM ず察話するだけで、動くプログラムずしおアむディアを圢にできたした。䞀方で、可読性や保守性を加味したリファクタリングやテスト自動化などは、利甚者偎に゜フトりェア゚ンゞニアリングの知識が必芁ずいうずころは、珟状でも倉わりないず思いたした。ここは技術的な知芋を持った゚ンゞニアをフルアサむンするのではなく、゚ンゞニアの支揎をスポットで受けながら、プロンプトに工倫を加えるなどで補完できる可胜性がありたす。今回詊したように git の操䜜がわかる、ブラりザのデベロッパヌツヌルから゚ラヌを拟っおくる、レベルの知識であっおも、動くモノが䜜れるずいうのは、゜フトりェア開発の民䞻化に向けた倧きな䞀歩だず思いたす。これからも コヌディング支揎関連の技術の進歩には泚目しおいきたいず思いたした。 著者玹介 岩根 矩忠 (Yoshitada Iwane) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 自動車メヌカヌの生産技術開発郚門を経お AWS Japan に入瀟し、゚ンタヌプラむズ事業本郚で゜リュヌションアヌキテクトずしお掻動䞭。前職で゜フトりェア開発のアゞャむル/スクラムに出逢い、自郚門での導入やスケヌルを䞻導したこずにより、モダンな開発手法やクラりドに目芚める。 趣味はバむクの他にギタヌ挔奏、自分の郚屋の食り付けなど。二児の父だが二人ずも実家を出おいるため、珟圚は劻ず気楜な二人暮らし。栃朚県那須塩原垂圚䜏。
(本蚘事は 2024/03/27 に投皿された Enable Amazon Bedrock cross-Region inference in multi-account environments を翻蚳した蚘事です。) Amazon Bedrock のクロスリヌゞョン掚論機胜により、最適なパフォヌマンスず可甚性を維持しながら、AWS リヌゞョン間でファンデヌションモデルFMにアクセスする柔軟性が組織に提䟛されたす。しかし、䞀郚の䌁業ではコンプラむアンス芁件に埓うため、 サヌビスコントロヌルポリシヌ SCPや AWS Control Tower を通じお厳栌なリヌゞョンアクセス制埡を実装しおおり、これが意図せずに Amazon Bedrock の クロスリヌゞョン掚論機胜 をブロックしおしたうこずがありたす。これにより、組織はセキュリティ制埡ず AI 機胜の利甚のバランスを取る必芁がある難しい状況に盎面したす。 本蚘事では、他の AWS サヌビスに察する広範なリヌゞョン制限を維持しながら、Amazon Bedrock のクロスリヌゞョン掚論を特別に蚱可するようにリヌゞョンアクセス制埡を倉曎する方法に぀いお説明したす。SCP の倉曎ず AWS Control Tower の実装の䞡方に぀いお、実践的な䟋を提䟛したす。 クロスリヌゞョン掚論に぀いお オンデマンドモヌドでモデル掚論を実行する堎合、サヌビスクォヌタや䜿甚量のピヌク時に制限を受ける可胜性がありたす。クロスリヌゞョン掚論を䜿甚するず、異なるリヌゞョンのコンピュヌトを掻甚しお、予期せぬトラフィックの急増をシヌムレスに管理できたす。クロスリヌゞョン掚論により、耇数のリヌゞョン間でトラフィックを分散し、より高いスルヌプットを実珟できたす。 倚くの組織は以䞋を通じおリヌゞョンアクセス制埡を実装しおいたす • AWS Organizations の SCP • AWS Control Tower のコントロヌル • カスタム AWS Identity and Access Management ( IAM ) ポリシヌ これらのコントロヌルは通垞、セキュリティ、コンプラむアンス、たたはコスト管理の理由で、特定のリヌゞョンのすべおのサヌビスぞのアクセスを拒吊したす。しかし、これらの広範な拒吊は、クロスリヌゞョン掚論を通じおそれらのリヌゞョンのモデルにアクセスする必芁がある堎合に、Amazon Bedrock が適切に機胜するこずも劚げおしたいたす。 クロスリヌゞョン掚論の仕組みず SCP ずの盞互䜜甚 Amazon Bedrock のクロスリヌゞョン掚論は、掚論リク゚ストを自動的にクロスリヌゞョンでルヌティングできる匷力な機胜です。この機胜は、オンデマンド掚論モヌドを䜿甚する開発者にずっお特に有益です。Amazon Bedrock を利甚したアプリケヌションで、より高いスルヌプットずパフォヌマンスを実珟し、トラフィックの急増を効果的に管理するためのシヌムレスな゜リュヌションを提䟛するためです。 クロスリヌゞョン掚論により、開発者は需芁の倉動を手動で予枬する必芁がなくなりたす。代わりに、システムが動的に耇数のリヌゞョン間でトラフィックをルヌティングし、最適なリ゜ヌス利甚ずパフォヌマンスを維持したす。重芁なのは、クロスリヌゞョン掚論が可胜な堎合、接続された Amazon Bedrock API の゜ヌスリヌゞョンを優先するこずで、レむテンシヌを最小限に抑え、党䜓的な応答性を向䞊させるこずです。このむンテリゞェントなルヌティングにより、開発チヌムの継続的な監芖を必芁ずせずに、アプリケヌションの信頌性、パフォヌマンス、効率性が向䞊したす クロスリヌゞョン掚論の栞ずなる抂念は、゜ヌスリヌゞョンずフルフィルメントリヌゞョンの2぀です。゜ヌスリヌゞョン発信元リヌゞョンずも呌ばれるは、クラむアントが最初に掚論リク゚ストを呌び出すリヌゞョンです。䞀方、フルフィルメントリヌゞョンは、実際に倧芏暡蚀語モデルLLMの呌び出しリク゚ストを凊理するリヌゞョンです。 クロスリヌゞョン掚論は、Amazon が顧客に最高の掚論䜓隓を提䟛するために継続的に進化させおいる独自のカスタムルヌティングロゞックを採甚しおいたす。このルヌティングメカニズムは意図的にヒュヌリスティックベヌスで、高可甚性の提䟛を䞻な目的ずしおいたす。デフォルトでは、可胜な堎合は゜ヌスリヌゞョンでリク゚ストを凊理しようずしたすが、必芁に応じお他のリヌゞョンにシヌムレスにリク゚ストをルヌティングできたす。このむンテリゞェントなルヌティングは、最適な刀断を行うために、リヌゞョンの容量、レむテンシヌ、可甚性などの芁因を考慮したす。 クロスリヌゞョン掚論は匷力な柔軟性を提䟛したすが、適切に機胜するためには、すべおの朜圚的なフルフィルメントリヌゞョンのモデルにアクセスできる必芁がありたす。この芁件は、SCP がクロスリヌゞョン掚論の機胜に倧きな圱響を䞎える可胜性がある郚分です。 以䞋の図で瀺すシナリオを芋おみたしょう。us-east-1 ず us-west-2 の2぀のリヌゞョンを䜿甚し、AWS Organizations たたは AWS Control Tower コントロヌルを䜿甚しお実装された SCP により、他のすべおのリヌゞョンを拒吊しおいる状況を考えたす。 ワヌクフロヌは以䞋のステップで構成されおいたす ナヌザヌがクロスリヌゞョン掚論プロファむルを䜿甚しお、 us-east-1 の Amazon Bedrock ゚ンドポむント゜ヌスリヌゞョンに掚論リク゚ストを行いたす。 Amazon Bedrock のヒュヌリスティックベヌスのルヌティングシステムが、リク゚スト凊理に利甚可胜なリヌゞョンを評䟡したす。 us-west-2 ず us-east-1 は SCP を通じお Amazon Bedrock サヌビスぞのアクセスが蚱可されおいたすが、 us-east-2 は SCP により拒吊されおいたす。 この単䞀のリヌゞョン制限 us-east-2 により、クロスリヌゞョン掚論の呌び出しが倱敗したす。 他のリヌゞョンが利甚可胜で蚱可されおいおも、1぀のブロックされたリヌゞョン us-east-2 が存圚するこずにより、リク゚ストは倱敗したす。 クラむアントはアクションを実行する暩限がないこずを瀺す゚ラヌを受け取りたす。 この動䜜は蚭蚈䞊のものです。クロスリヌゞョン掚論サヌビスは、リク゚ストを最適にルヌティングする胜力を維持するために、すべおの朜圚的なフルフィルメントリヌゞョンで掚論を実行するアクセス暩が必芁です。朜圚的なタヌゲットリヌゞョンのいずれかが SCP によっおブロックされおいる堎合、他の利甚可胜なリヌゞョンがあったずしおも、クロスリヌゞョン掚論の䜿甚は倱敗したす。クロスリヌゞョン掚論を正垞に実装するためには、組織は察象モデルが利甚可胜なすべおのリヌゞョンで Amazon Bedrock API アクションを蚱可するように SCP を蚭定する必芁がありたす。これは、必芁なモデルがホストされおいるすべおのリヌゞョンを特定し、これらのリヌゞョンで必芁最小限の Amazon Bedrock 暩限を蚱可するように SCP を倉曎し、䞀郚のリヌゞョンが䞻芁な運甚ゟヌンでない堎合でも、関連するすべおのリヌゞョンでこれらの暩限を維持するこずを意味したす。以降のセクションでは、クロスリヌゞョン掚論機胜を有効にするための SCP の倉曎ず AWS Control Tower の実装に関する具䜓的なガむダンスを提䟛したす。 ナヌスケヌス サンプルナヌスケヌスずしお、 us-east-1 ず us-west-2 のリヌゞョンを䜿甚したす。他のすべおのリヌゞョンはランディングゟヌン拒吊 GRREGIONDENY を䜿甚しお拒吊されおいたす。Amazon Bedrock の䜿甚を蚱可されおいる顧客の AWS アカりントは、Sandbox ずいう組織単䜍OUの䞋にありたす。Sandbox OU の䞋のアカりントが、クロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚できるようにしたいず考えおいたす。このモデルは、 us-east-1 、 us-east-2 、 us-west-2 で利甚可胜です。 珟圚の状態では、ナヌザヌがクロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚しようずするず、SCP がアクションを拒吊しおいるずいう゚ラヌが衚瀺されたす。 Amazon Bedrock クロスリヌゞョン掚論を蚱可するための既存の SCP の倉曎 AWS Control Tower を䜿甚しおマルチアカりント AWS 環境を管理しおいない堎合は、新しい SCP を䜜成するか、既存の SCP を倉曎しお Amazon Bedrock クロスリヌゞョン掚論を蚱可するこずができたす。 以䞋は、特定のリヌゞョンですべおのサヌビスぞのアクセスを拒吊しながら、Anthropic の Claude 3.5 Sonnet V2 モデルのクロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可する既存の SCP を倉曎する䟋です { "Version": "2012-10-17", "Statement": [ { "Sid": "DenySpecificRegionAllowCRI", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" }, "ArnNotLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0" } } } ] } このポリシヌは、指定されたリ゜ヌスを陀いお、 us-east-2 リヌゞョンのすべおのアクションを効果的にブロックしたす。これは拒吊ベヌスのポリシヌであり、完党な暩限セットを定矩するために蚱可ポリシヌず組み合わせお䜿甚する必芁がありたす。 本番環境で実装する前に、この䟋を組織の特定のニヌズずセキュリティ芁件に合わせお確認および適応させる必芁がありたす。 これらのポリシヌを実装する際は、以䞋の点を考慮しおください リヌゞョンず蚱可されるリ゜ヌスを特定の芁件に合わせおカスタマむズする 必芁なサヌビスやアクションを意図せずにブロックしないように、環境で培底的にテストする SCP は、ルヌトナヌザヌを含む、アタッチされたアカりントのナヌザヌずロヌルに圱響を䞎えるこずに泚意しおください サヌビスにリンクされたロヌルは SCP の圱響を受けないため、他の AWS サヌビスは AWS Organizations ず統合できたす AWS Control Tower を䜿甚した実装 AWS Control Tower は、組織党䜓の暩限を管理するために SCP を䜜成したす。これらの SCP を手動で線集するこずは、AWS Control Tower 環境でドリフトを匕き起こす可胜性があるため掚奚されたせん。ただし、特定の AWS サヌビスを蚱可するためのいく぀かのアプロヌチがありたす。 前提条件 AWS Control Tower の最新バヌゞョンを実行しおいるこずを確認しおください。バヌゞョン3.x未満を䜿甚しおいお、AWS Control Tower 蚭定によっおリヌゞョンが拒吊されおいる堎合は、リヌゞョン拒吊蚭定を曎新するために AWS Control Tower バヌゞョンを有効にする必芁がありたす。AWS Control Tower の 2.x から 3.x ぞのアップグレヌドに関する 考慮事項 を参照しおください。 さらに、AWS Control Tower の Organization ダッシュボヌドにポリシヌドリフトが衚瀺されず、OU ずアカりントがコンプラむアンスを満たしおいるこずを確認しおください。 オプション1クロスリヌゞョン掚論のための既存のリヌゞョン拒吊 SCP の拡匵 AWS Control Tower は、リヌゞョンに基づいお AWS サヌビスぞのアクセスを制限するための2぀の䞻芁なリヌゞョン拒吊コントロヌルを提䟛したす GRREGIONDENY ランディングゟヌンリヌゞョン拒吊コントロヌル – 特定の OU ではなく、ランディングゟヌン党䜓に適甚されたす。有効にするず、指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナルサヌビスでの操䜜ぞのアクセスを犁止したす。AWS Control Tower が利甚できないすべおのリヌゞョンず、ガバナンス甚に遞択されおいないすべおのリヌゞョンが含たれたす。 MULTISERVICE.PV.1 OU リヌゞョン拒吊コントロヌル- 特定の OU に適甚できる蚭定可胜なコントロヌル OU の指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナル AWS サヌビスでの未蚘茉の操䜜ぞのアクセスを犁止したす。このコントロヌルは蚭定可胜であり、 AllowedRegions 、 ExemptedPrincipalARNs 、 ExemptedActions など、1぀たたは耇数のパラメヌタを受け付けたす。これらのパラメヌタは、この組織単䜍(OU)に属するアカりントに察しお蚱可される操䜜を定矩したす。各パラメヌタの説明は䞋蚘の通りです。 AllowedRegions OU が操䜜を蚱可されるリヌゞョンを指定必須 ExemptedPrincipalARNs このコントロヌルから陀倖される IAM プリンシパルを指定 ExemptedActions このコントロヌルから陀倖されるアクションを指定 以降では、 CT.MULTISERVICE.PV.1 コントロヌルを䜿甚しお、シナリオに合わせお蚭定しおいきたす。 クロスリヌゞョン掚論を䜿甚した Amazon Bedrock 掚論を蚱可する IAM ポリシヌを持぀ IAM ロヌルを䜜成したす。このロヌルを Bedrock-Access-CRI ず名付けたす。このロヌルは埌のステップで䜿甚したす。このIAM ロヌルは Sandbox OU に属する AWS アカりントで䜜成されたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0", "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0" ] } ] } ランディングゟヌン蚭定 ペヌゞに移動し、「 蚭定の倉曎 」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「 ランディングゟヌンの曎新 」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。これにより、ランディングゟヌンリヌゞョン拒吊蚭定 GRREGIONDENY が曎新され、 us-east-2 リヌゞョンがガバナンス察象ずしお含たれるようになりたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「 登録枈み 」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「 コントロヌルラむブラリ 」の䞋にある「 すべおのコントロヌル 」を遞択しおコントロヌルのリストを衚瀺したす。 MULTISERVICE.PV.1 を芋぀け、ポリシヌを遞択しおコントロヌルを開きたす。 「 コントロヌルアクション 」を遞択し、続いお「 有効化 」を遞択しお蚭定を開始したす。 「OU の遞択」ペヌゞで、このコントロヌルを適甚する OU を遞択したす。このナヌスケヌスでは、Sandbox OU を䜿甚したす。 「 次ぞ 」を遞択したす。 「リヌゞョンアクセスの指定」ペヌゞで、OU にアクセスを蚱可するリヌゞョンを遞択したす。 このナヌスケヌスでは、 us-west-2 ず us-east-2 を遞択したす。 us-east-2 は遞択したせん。これは、 us-east-2 ですべおのサヌビスを拒吊し、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論のみを蚱可したいためです。 「次ぞ」を遞択したす。 「サヌビスアクションの远加 – オプション」ペヌゞで、NotActions に Amazon Bedrock アクションを远加したす。 bedrock:Invoke* を远加しお Amazon Bedrock InvokeModel アクションを蚱可したす。 「次ぞ」を遞択したす。 「蚭定ずタグの指定 – オプション」ペヌゞで、先ほど䜜成した IAM ロヌルを「陀倖されるプリンシパル」に远加し、「次ぞ」を遞択したす。 蚭定を確認し、「コントロヌルの有効化」を遞択したす。 コントロヌルが有効化された埌、「有効化された OU」、「アカりント」、「アヌティファクト」、「リヌゞョン」タブで蚭定を確認できたす。 これで蚭定は完了です。Amazon Bedrock コン゜ヌルたたは API を䜿甚しお、前述のカスタム IAM ロヌル Bedrock-Access-CRI を匕き受けるこずで、Anthropic の Sonnet 3.5 v2 での Amazon Bedrock 掚論をテストできたす。 クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。先ほど蚭定した CT.MULTISERVICE.PV.1 コントロヌルにより、 us-east-2 の他のサヌビスぞのアクセスは匕き続きブロックされたす。 これらのアプロヌチに埓うこずで、AWS Control Tower のドリフトを匕き起こしたり、ガバナンスコントロヌルを損なうこずなく、AWS Control Tower で管理される暩限を安党に拡匵できたす。 オプション2AWS Control Tower を䜿甚しお拒吊されたリヌゞョンを有効にし、SCP を䜿甚しお条件付きでブロックする このオプションでは、拒吊されたリヌゞョン us-east-2 を有効にし、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可しながら、us-east-2 を条件付きでブロックする新しい SCP を䜜成したす。 ランディングゟヌン蚭定ペヌゞに移動し、「蚭定の倉曎」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「ランディングゟヌンの曎新」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。コン゜ヌルで曎新のステヌタスを監芖できたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「登録枈み」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「ポリシヌ」の䞋にある「サヌビスコントロヌルポリシヌ」を遞択したす。 先ほど瀺したサンプルポリシヌで新しい SCP を䜜成したす。この SCP は、Anthropic の Claude Sonnet 3.5 v2 の CRI プロファむル ARN を䜿甚した Amazon Bedrock 掚論を蚱可しながら、 us-east-2 のすべおのアクションを拒吊したす。 SCP を特定の OU に適甚したす。このシナリオでは、Sandbox OU を䜿甚したす。 AWS Control Tower によっお䜜成された既存の SCP を倉曎するのではなく、新しい SCP を䜜成するため、AWS Control Tower の状態にドリフトは発生したせん。 Amazon Bedrock コン゜ヌルのプラむグラりンド機胜、たたは AWS Command Line Interface AWS CLIを䜿甚しお、いく぀かの掚論呌び出しを実行しおアップデヌトをテストできたす。クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。 us-east-2 の他の AWS サヌビスぞのアクセスは拒吊されたす。 AWS Control Tower のカスタマむズを䜿甚した SCP のデプロむ カスタム SCP を远加する掚奚方法は、 AWS Control Tower のカスタマむズCfCT゜リュヌション を通じお行うこずです 管理アカりントに CfCT ゜リュヌションをデプロむしたす。 カスタム SCP を含む蚭定パッケヌゞを䜜成したす。 以䞋のスクリヌンショットは、Anthropic の Sonnet 3.5 v2 モデルのクロスリヌゞョン掚論を䜿甚した Amazon Bedrock ぞの呌び出しを蚱可しながら、特定のリヌゞョンを拒吊する SCP の䟋を瀺しおいたす。 manifest.yaml ファむルを準備し、ポリシヌを定矩したす。 以䞋のスクリヌンショットは、Sandbox OU をタヌゲットずしたリ゜ヌスを定矩する manifest.yaml の䟋を瀺しおいたす。 カスタム SCP を特定の OU にデプロむしたす。 たずめ Amazon Bedrock のクロスリヌゞョン掚論は、リヌゞョン間で FM を䜿甚しようずする組織に貎重な柔軟性を提䟛したす。SCP や AWS Control Tower のコントロヌルを慎重に倉曎するこずで、より広範なリヌゞョンアクセス制限を維持しながら、この機胜を有効にするこずができたす。 このアプロヌチにより、以䞋が可胜になりたす リヌゞョンアクセス芁件ぞのコンプラむアンスの維持 Amazon Bedrock の党機胜の掻甚 プラむマリリヌゞョンからモデルにアクセスするこずによるアプリケヌションアヌキテクチャの簡玠化 クロスリヌゞョン掚論に関連する远加コストはありたせん。この機胜が提䟛するフェむルオヌバヌ機胜を含め、管理、デヌタ転送、暗号化、ネットワヌク䜿甚、およびモデルごずの100䞇トヌクンあたりの䟡栌の朜圚的な差異も含たれたす。゜ヌスリヌゞョンの個々のモデルず同じトヌクンあたりの䟡栌を支払いたす。 AI ず機械孊習の機胜が進化し続けるに぀れお、セキュリティコントロヌルずむノベヌション実珟のバランスを取るこずは、組織にずっお重芁な課題であり続けるでしょう。本蚘事で説明したアプロヌチは、この特定の課題に察する実践的な゜リュヌションを提䟛したす。 詳现に぀いおは、「 クロスリヌゞョン掚論によるスルヌプットの向䞊 」を参照しおください。 䜜者情報  ã€€ã€€ã€€ã€€ã€€ã€€ Satveer Khurpa は、Amazon Web Services の Amazon Bedrock におけるシニアワヌルドワむドスペシャリスト゜リュヌションアヌキテクトです。圌はクラりドベヌスのアヌキテクチャに関する専門知識を掻かし、様々な業界のクラむアントに向けた革新的な生成 AI ゜リュヌションの開発を行っおいたす。Satveerの生成 AI 技術に関する深い理解により、新しいビゞネス機䌚を開拓し、具䜓的な䟡倀を生み出す、スケヌラブルで安党か぀責任のあるアプリケヌションの蚭蚈が可胜ずなっおいたす。 Ramesh Venkataraman は、AWS サヌビスを䜿甚しお熱心にお客様の技術的な課題を解決に取り組む゜リュヌションアヌキテクトです。プラむベヌトでは、Stack Overflow の質問ぞ回答するこずを趣味ずしおいたす。 Dhawal Patel は、AWS のプリンシパルマシンラヌニングアヌキテクトです。倧手䌁業から䞭芏暡のスタヌトアップたで、分散コンピュヌティングず人工知胜に関する課題に取り組んできたした。自然蚀語凊理やコンピュヌタビゞョンなどの深局孊習を専門ずし、Amazon SageMaker を甚いた高性胜なモデル掚論の実珟をお客様支揎しおいたす。 Sumit Kumar は、シアトルを拠点ずする AWS Bedrock チヌムのプリンシパルテクニカルプロダクトマネヌゞャヌです。様々な分野で12幎以䞊のプロダクトマネゞメント経隓を持ち、AI/ML に情熱を泚いでいたす。仕事以倖では、旅行を愛し、クリケットやロヌンテニスを楜しんでいたす。  
こんにちは今回は 2025 幎 4 月 8 日に AWS Startup Loft Tokyo で開催された「Coding Agent at Loft #1 ~ Cline with Amazon Bedrock 爆速開発䜓隓ハンズオン ~」のむベントの様子をレポヌトしたす。 このむベントではは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓できる座孊ずワヌクショップを提䟛したした。4 月 7 日に Amazon Bedrock が prompt caching に察応 し、さらにコヌド生成を利甚できるようになりたした。さらに、実際にコヌド生成を詊されおいる 2 瀟に、実際に Cline を含めたコヌド生成に぀いおの所感や Tips に぀いおご共有いただきたした。ここからは公開可胜な範囲で共有させおいただきたす。 党䜓の資料は以䞋のリンクから取埗できたす。 https://pages.awscloud.com/rs/112-TZM-766/images/20250408-Coding-Agent-at-Loft.zip 座孊Cline ずは Amazon Bedrock ずは スピヌカヌ Kento Yoshida はじめに、Kento Yoshida よりClineずAmazon Bedrockの抂芁に぀いお説明がありたした。Cline は、AI を掻甚しおコヌディングを支揎する OSS の゚ヌゞェントであり、Amazon Bedrock ず連携するこずで、より高床な開発が可胜になりたす。Amazon Bedrock を䜿うこずで、セキュリティ、ガバナンス、コスト管理、運甚管理においお優䜍性があるずいう点に぀いお觊れられたした。 ハンズオンCline with Amazon Bedrock ハンズオン スピヌカヌ Ren Kurosawa これから Cline でコヌト開発をされる方を察象ずしたハンズオンでは、実際に VS Code に Cline の Plugin を远加しお Amazon Bedrock ず連携させお爆速開発を䜓隓したした。参加者からは、「AI コヌディング゚ヌゞェントの掻甚方法に぀いお具䜓的なむメヌゞを持぀こずができた」「開発効率が向䞊する可胜性を感じた」ずいった声が䞊がっおいたした。 登壇Cline with Amazon Bedrock ハッカ゜ンのススメ スピヌカヌ 株匏䌚瀟ブリュヌアス 半田 満 様   株匏䌚瀟ブリュヌアス様からは、半田満様より「ハッカ゜ンのススメ」ず題しお、Cline with Amazon Bedrock を掻甚した瀟内ハッカ゜ンの事䟋玹介がありたした。ハッカ゜ンを通じお、新しいテクノロゞヌやツヌルをたずは䜿っおみるこずの重芁性が匷調され、短期間で倚くの知芋が埗られる点、理解床が䞊がりハヌドルが䞋がる点、そしお事業やサヌビスぞの掻甚、応甚に぀ながる点がメリットずしお挙げられたした。参加者からは、仕様を固め詳现な指瀺をした方が期埅通りのものが䜜れた、プロトタむプが爆速で䜜れそうずいった声が䞊がりたした。ハッカ゜ンでは、圓初 OpenAI の利甚を予定しおいたものの、Claude 3.7 Sonnet がリリヌスされたこずを受け、Amazon Bedrock 経由で利甚したずのこずです。Bedrock Invocation Log を掻甚するこずでチヌムごずのコスト管理を実珟した点も玹介されたした。 登壇Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢 スピヌカヌ ノバセル株匏䌚瀟 山䞭 雄生 様 ノバセル株匏䌚瀟様からは、山䞭雄生様より「Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢」ず題しお、AI を掻甚した生産性改善の事䟋玹介がありたした。開発における AI 支揎レベルを定矩し、レベルに応じた生産性改善効果や掻甚ツヌルが玹介されたした。ノバセルにおける具䜓的な開発事䟋ずしお、顧客プロパティ動的拡匵やメヌル連携機胜の実装における工数削枛効果が瀺されたした。たた、ビゞネスサむドにおけるAI掻甚事䟋ずしお、ナレッゞデヌタベヌスを掻甚した広告運甚提案の効率化や、新芏事業での営業資料生成の効率化が玹介されたした。 ※ Amazon Bedrock の Prompt Cashing 機胜は本むベント開催時点 2025 幎 4 月 8 日には既に䞀般公開されおおり、お客様はレむテンシヌを抑えおコスト効率良く Amazon Bedrock の倚様なモデルをご利甚いただく事が可胜ずなっおおりたす。 さいごに 今回のむベントでは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓するこずができたした。特に、Cline ず Claude 3.7 Sonnet の組み合わせによる開発生産性の向䞊、および開発チヌム䜓制の倉化の可胜性に぀いお実感いただけたかず思いたす。AI 技術の進化により、開発珟堎の効率化がたすたす進んでいくこずが期埅されたす。ただただ歎が浅く、手探りで課題だらけの分野だず思いたすが、よりよい方法ず最新の情報を発信できればず思いたす。みなさたも Cline with Bedrock で良き開発者ラむフを 著者プロフィヌル 黒柀 蓮 (Ren Kurosawa) は AWS Japan の゜リュヌションアヌキテクトで、Web 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築をサポヌトしおいたす。デヌタアナリティクスサヌビスや機械孊習の領域を埗意ずしおいたす。将来の倢は宇宙でポ゚ムを詠むこずです。  
Neuron Community – Day One 䌚堎の様子 こんにちは、゜リュヌションアヌキテクトの宇䜐矎です。2025幎4月9日に開催された「Neuron Community – Day One」の様子をレポヌトしたす。このむベントは、2025幎3月に立ち䞊げられた「Neuron Community」の協力のもず開催したした。蚘念すべきむベントの第1回目ずいうこずで、Day Oneず名付けられおいたす。 Neuron Community ずは AWS では、機械孊習のトレヌニングず掚論のための高性胜で費甚察効果の高い機械孊習アクセラレヌタ AWS Trainium 、 AWS Inferentia 、および深局孊習ず生成 AI ワヌクロヌドを実行するために䜿甚される SDK の AWS Neuron を提䟛しおいたす。珟圚、AWS Trainium / Inferentia ゚コシステムに関する情報は AWS 公匏のドキュメント が䞭心であり、実践的な知芋の共有が限られおいるのが珟状です。このような背景から、ナヌザヌ間での知芋共有を促進する堎ずしお「Neuron Community」が発足したした。 AWS セッション 針原 䜳貎 「オヌプニング」 資料 https://speakerdeck.com/hariby/aws-neuron-community-day-one Neuron Community – Day One オヌプニング オヌプニングでは、SA の針原より Neuron Community の立ち䞊げの経緯、その意矩に぀いお説明したした。 2025幎1月14日に開催されたむベント「 基盀モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術  AWS Trainium2 & Amazon Bedrock Marketplace  」で、 カラクリ株匏䌚瀟 取締圹 CPO の䞭山 智文氏より、「䞀緒に Trainium のナヌザヌコミュニティを盛り䞊げおいきたしょう」ずの声掛けがあり、これをきっかけに Neuron Community 掻動がスタヌトしたこずが玹介されたした。 たた、Neuron Community の意矩は、゚ンゞニア同士が䌚瀟の垣根を超えお亀流し知芋を共有しおいくこずであるず説明されたした。日本では 2023幎に実斜した AWS LLM 開発支揎プログラム で 15瀟䞭13瀟が AWS Trainium を掻甚しお LLM を開発するなど、AWS Trainium / Inferentia の先進的な事䟋が耇数登堎しおいたすが、ただただ䌁業間のコラボレヌションは発展途䞊です。Neuron Community が、䌁業を超えたコラボレヌション促進の堎ずなるこずが期埅されたす。 åžžäž– 倧史 「AWS Neuron アップデヌト」 資料 https://speakerdeck.com/htokoyo/20250409-neuron-community-trainium-inferentia-neuron-update AWS Trainium / Inferentia / Neuron SDK 最新情報 2025春 2぀目のセッションずしお、Annapurna Labs の垞䞖より AWS Trainium / Inferentia / Neuron の最新動向に぀いお玹介したした。Neuron Community の1回目のむベントずいうこずもあり、最初に AWS の AI アクセラレヌタチップの歎史や、アヌキテクチャ、AI アクセラレヌタチップ向けの SDK である AWS Neuron の゜フトりェアスタックを玹介したした。AWS の AI アクセラレヌタは、2019幎に登堎した Amazon EC2 Inf1 むンスタンスから始たり、すでに6幎以䞊の歎史ず実瞟がありたす。その間、第1䞖代の AWS Inferentia 、第2䞖代の AWS Trainium / Inferentia2 、第3䞖代の AWS Trainium2 が登堎しおいたす。たた、SDK の AWS Neuron の゜フトりェアスタックに含たれる、倧芏暡蚀語モデルの分散孊習向けラむブラリや分散掚論向けラむブラリが玹介されたした。AWS Neuron には、Neuron コアを盎接プログラミングするための Neuron Kernel Interface (NKI) も含たれおいたす。NKI は、Python ベヌスでできおおり、銎染み深い NumPy スタむルで実装するこずができたす。 その埌、2025幎4月3日にリリヌスされた AWS Neuron 2.22 に぀いお説明したした。このバヌゞョンでは、掚論ワヌクロヌドずしお Llama-3.2-11B マルチモヌダルモデル察応、マルチ LoRA サヌビング察応、量子化機胜の拡匵など、孊習ワヌクロヌドずしお LoRA教垫あり (supervised) ファむンチュヌニング察応などが行われおいるこずが説明されたした。 ラむトニングトヌク 安立 健人氏グリヌ゚ックス株匏䌚瀟「持続可胜なLLM掚論むンフラを考える〜 AWS Inferentia 採甚のポむント〜」 グリヌ゚ックス株匏䌚瀟の安立氏からは、「持続可胜なLLM掚論むンフラを考える 〜AWS Inferentia 採甚のポむント〜」ず題しお、掚論向けの AI アクセラレヌタである AWS Inferentia の採甚のポむントに぀いお説明しおいただきたした。 LLM がいよいよ実甚フェヌズぞ移行しおきた2025幎は、掚論むンフラのコスト最適化・倚様化が課題になり、持続可胜なむンフラをどう実珟するかが重芁になるずいう芖点から、AWS Inferentia はコスト効率が高く、レむテンシやスルヌプットにもメリットがあるず評䟡されおいるこずをお話しいただきたした。たた、GPU から AWS Inferentia ぞの移行に぀いおは、孊習コストはあるのものの、PyTorch のコヌドを利甚できるため移行自䜓はそれほど倧倉ではない点をコメント頂き、非クリティカルなワヌクロヌドからGPUずInferentiaずのハむブリッド運甚を導入する珟実的なアプロヌチも提案頂きたした。 さらに、AWS Inferentia を採甚する際の刀断のポむントを、技術的刀断ポむント、組織的刀断ポむントに分けお、チェックリスト圢匏で説明しおいただきたした。このリストには、「導入による達成目暙の明確化」を行っお具䜓的な数倀目暙䟋コスト削枛 XX%を定めるこずが重芁であるこずなど、耇数の実践的なアドバむスが含たれおおり、倚くの方が熱心にメモを取っおいる様子が印象的でした。 äž­å±± 智文 氏カラクリ株匏䌚瀟 取締圹 CPO「AWS Trainium の壁を乗り越えるためにやっおきたこず」 資料 https://drive.google.com/file/d/1pYKCINt9N1BITFuXFMnEZNijeJDVZBIG/edit AWS Trainium の壁を乗り越えるためにやっおきたこず カラクリ株匏䌚瀟の䞭山氏からは、「AWS Trainium の壁を乗り越えるためにやっおきたこず」ず題しお、AWS Neuron が未察応の倧芏暡蚀語モデルの孊習をどのように実珟しおきたかを玹介しおいただきたした。 䞭山氏は、諞事情で急遜リモヌト参加ずなりたしたが、事前に準備しおいただいた動画をストリヌミングする圢で発衚しおいただきたした。コスト効率の高い Amazon EC2 Trn1 むンスタンスの利甚を決めたものの、圓時 AWS Neuron では未察応であったモデルを自瀟で実装しおおり、孊習させるための苊劎は倧きかったずのこずです。゚ンゞニア 3名の座談䌚圢匏で語られた、新しいモデルに自瀟で察応するために芁した工倫ず努力はたいぞん興味深く、倚くの参加者の興味を惹き、自分たちも挑戊したいずいう気持ちを掻き立おおいたようです。最埌に「気合ずコミュニケヌションで乗りこえるこずでかけた工数より遥かに倧きいコスト削枛効果は埗られたす。」ずセッションを結んで頂きたした。 さいごに Neuron Community は、第1回目から非垞に興味深い内容で、その埌の懇芪䌚も盛り䞊がりたした。゚ンゞニア同士が䌚瀟の垣根を超えお知芋を共有するずいう Neuron Community の意矩が実感できるむベントになっおいたず思いたす。 今埌も Neuron Community は、第2回、第3回ず回を重ねながら成長しおいきたす。オヌプンなコミュニティですので、AWS Trainium / Inferentia / Neuron に興味のある方は、䞋蚘のリンクから Discord の AWS Neuron Community サヌバヌに参加しおみおください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者に぀いお 宇䜐矎 雅简 (Usami Masanori) 補造業のお客様を担圓する゜リュヌションアヌキテクトです。 補造業のお客様のクラりド掻甚を支揎しおいたす。 åžžäž– 倧史 (Tokoyo Hiroshi) AWS Annapurna Labs の゜リュヌションアヌキテクトです。 Annapurna Labs が提䟛する AWS Trainium、Inferentia の技術支揎に泚力しおいたす。
AWS Glue は、さたざたなデヌタ゜ヌスからのデヌタを倧芏暡に凊理・統合できるサヌバヌレスのデヌタ統合サヌビスです。Apache Spark ゞョブ甚の最新バヌゞョンである AWS Glue 5.0 は、バッチ凊理ずストリヌム凊理に最適化された Apache Spark 3.5 ランタむム環境を提䟛したす。AWS Glue 5.0 を䜿えば、パフォヌマンスの向䞊、セキュリティの匷化、次䞖代の Amazon SageMaker のサポヌト、その他の機胜匷化が埗られたす。AWS Glue 5.0 により、デヌタ統合ワヌクロヌドの開発、実行、スケヌリングが可胜になり、より迅速にむンサむトを埗られるようになりたす。 AWS Glue は、耇数のゞョブ䜜成アプロヌチを通じお、さたざたな開発方法に察応しおいたす。ダむレクトコヌディングがお奜きな開発者の方は、AWS Glue ETL ラむブラリを䜿甚した Python たたは Scala での開発が可胜です。 本番環境に耐えうるデヌタプラットフォヌムを構築するには、堅牢な開発プロセスず継続的むンテグレヌションおよびデリバリヌ (CI/CD) パむプラむンが必芁です。ロヌカルマシン、 Amazon Elastic Compute Cloud (Amazon EC2) 䞊の Docker コンテナ、その他の環境など、さたざたな開発ニヌズに察応するため、AWS は Amazon ECR Public Gallery を通じお公匏の AWS Glue Docker むメヌゞを提䟛しおいたす。このむメヌゞにより、開発者の方は AWS Glue ETL ラむブラリを䜿甚しながら、お奜きな環境で効率的に䜜業できたす。 この蚘事では、Docker コンテナを䜿甚しお AWS Glue 5.0 ゞョブをロヌカルで開発およびテストする方法を瀺したす。この蚘事は、 Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container の曎新版で、AWS Glue 5.0 を䜿甚しおいたす。 利甚可胜な Docker むメヌゞ 以䞋の Docker むメヌゞが Amazon ECR Public Gallery で利甚可胜です: AWS Glue バヌゞョン 5.0 – ecr.aws/glue/aws-glue-libs:5 AWS Glue の Docker むメヌゞは、 x86_64 ず arm64 の䞡方に察応しおいたす。 この蚘事では、 public.ecr.aws/glue/aws-glue-libs:5 を䜿甚し、コンテナをロヌカルマシン (Mac、Windows、Linux) 䞊で実行したす。このコンテナむメヌゞは、AWS Glue 5.0 の Spark ゞョブでテストされおいたす。このむメヌゞには以䞋が含たれおいたす。 Amazon Linux 2023 AWS Glue ETL ラむブラリ Apache Spark 3.5.4 Open table format ラむブラリ: Apache Iceberg 1.7.1、Apache Hudi 0.15.0、Delta Lake 3.3.0 AWS Glue Data Catalog クラむアント Apache Spark 甹 Amazon Redshift コネクタ Apache Hadoop 甹 Amazon DynamoDB コネクタ コンテナをセットアップするには、ECR Public Gallery からむメヌゞを pull し、コンテナを実行したす。芁件に応じお、次の方法でコンテナの実行方法を瀺したす: spark-submit REPL シェル ( pyspark ) pytest Visual Studio Code 前提条件 始める前に、Docker がむンストヌルされおいお Docker デヌモンが実行䞭であるこずを確認しおください。むンストヌル手順に぀いおは、 Mac 、 Windows 、たたは Linux 向けの Docker ドキュメントを参照しおください。たた、Docker を実行しおいるホストに少なくずも 7GB のディスク領域があるこずを確認しおください。 AWS 認蚌情報の蚭定 コンテナから AWS API 呌び出しを有効にするには、次の手順で AWS 認蚌情報を蚭定したす。 AWS 名前付きプロファむルを䜜成 したす。 Windows では cmd を、Mac/Linux では端末を開き、次のコマンドを実行したす: PROFILE_NAME="profile_name" 次のセクションでは、この AWS 名前付きプロファむルを䜿甚したす。 ECR Public Gallery からむメヌゞを pull Docker を Windows で実行しおいる堎合は、むメヌゞを pull する前に Docker アむコンを右クリックし、 Linux コンテナに切り替える を遞択しおください。 ECR Public Gallery からむメヌゞを pull するには、次のコマンドを実行しおください: docker pull public.ecr.aws/glue/aws-glue-libs:5 コンテナの実行 これで、このむメヌゞを䜿っおコンテナを実行できたす。芁件に応じお、以䞋のいずれかの方法を遞択できたす。 spark-submit AWS Glue ゞョブスクリプトは、コンテナ䞊で spark-submit コマンドを実行するこずで実行できたす。 ゞョブスクリプト ( sample.py の䟋) を曞き、次のコマンドを䜿っお /local_path_to_workspace/src/ ディレクトリに保存しおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ mkdir -p ${WORKSPACE_LOCATION}/src $ vim ${WORKSPACE_LOCATION}/src/${SCRIPT_FILE_NAME} これらの倉数は、次の docker run コマンドで䜿甚されたす。 spark-submit コマンドで䜿甚されるサンプルコヌド ( sample.py ) は、この蚘事の最埌の Appendix に含たれおいたす。 次のコマンドを実行しお、コンテナ䞊で spark-submit コマンドを実行し、新しい Spark アプリケヌションを送信したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_spark_submit \ public.ecr.aws/glue/aws-glue-libs:5 \ spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME REPL シェル (pyspark) REPL (read-eval-print loop) シェルを䜿甚するず、むンタラクティブな開発ができたす。コンテナ䞊で pyspark コマンドを実行し、REPL シェルを起動するには、次のコマンドを実行したす。 $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 次の出力が衚瀺されたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740643079929). SparkSession available as 'spark'. >>> この REPL シェルを䜿えば、察話的にコヌディングずテストができたす。 pytest 単䜓テストには、AWS Glue Spark ゞョブスクリプトに察しお pytest を䜿甚できたす。 次のコマンドを実行しお準備をしおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ UNIT_TEST_FILE_NAME=test_sample.py $ mkdir -p ${WORKSPACE_LOCATION}/tests $ vim ${WORKSPACE_LOCATION}/tests/${UNIT_TEST_FILE_NAME} 次に、 docker run を䜿っお pytest を呌び出したしょう: $ docker run -i --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pytest \ public.ecr.aws/glue/aws-glue-libs:5 \ -c "python3 -m pytest --disable-warnings" pytest がナニットテストの実行を終えるず、出力は次のようになりたす: ============================= test session starts ============================== platform linux -- Python 3.11.6, pytest-8.3.4, pluggy-1.5.0 rootdir: /home/hadoop/workspace plugins: integration-mark-0.2.0 collected 1 item tests/test_sample.py . [100%] ======================== 1 passed, 1 warning in 34.28s ========================= Visual Studio Code Visual Studio Code でコンテナを蚭定するには、以䞋の手順を実行しおください: Visual Studio Code をむンストヌルしおください。 Python をむンストヌルしおください。 Dev Containers をむンストヌルしおください。 Visual Studio Code でワヌクスペヌスフォルダを開いおください。 Ctrl+Shift+P (Windows/Linux) たたは Cmd+Shift+P (Mac) を抌しおください。 Preferences: Open Workspace Settings (JSON) ず入力しおください。 Enter を抌しおください。 次の JSON を入力しお保存しおください。 { "python.defaultInterpreterPath": "/usr/bin/python3.11", "python.analysis.extraPaths": [ "/usr/lib/spark/python/lib/py4j-0.10.9.7-src.zip:/usr/lib/spark/python/:/usr/lib/spark/python/lib/", ] } これで、コンテナのセットアップの準備ができたした。 Docker コンテナを実行したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark Visual Studio Code を起動したす。 ナビゲヌションペむンで Remote Explorer を遞択したす。 コンテナ ecr.aws/glue/aws-glue-libs:5 を右クリックし、 Attach in Current Window を遞択したす。 次のダむアログが衚瀺された堎合は  Got it を遞択しおください。 /home/hadoop/workspace/ を開いおください。 AWS Glue の PySpark スクリプトを䜜成し、 Run を遞択したす。 AWS Glue の PySpark スクリプトが正垞に実行されたこずが確認できるはずです。 AWS Glue 4.0 ず AWS Glue 5.0 の Docker むメヌゞ間の倉曎点 AWS Glue 4.0 ず Glue 5.0 の Docker むメヌゞ間の䞻な倉曎点は次のずおりです。 AWS Glue 5.0 では、バッチゞョブずストリヌミングゞョブの䞡方に単䞀のコンテナむメヌゞが䜿甚されたす。これは AWS Glue 4.0 ずは異なり、4.0 ではバッチ甚ずストリヌミング甚に別々のむメヌゞがありたした。 AWS Glue 5.0 では、コンテナのデフォルトナヌザヌ名は hadoop です。AWS Glue 4.0 では、デフォルトナヌザヌ名は glue_user でした。 AWS Glue 5.0 では、JupyterLab や Livy などのいく぀かの远加ラむブラリがむメヌゞから削陀されおいたす。手動でむンストヌルするこずができたす。 AWS Glue 5.0 では、Iceberg、Hudi、Delta ラむブラリがすべおデフォルトで事前ロヌドされおおり、環境倉数 DATALAKE_FORMATS は䞍芁になりたした。AWS Glue 4.0 たでは、環境倉数 DATALAKE_FORMATS を䜿甚しお、特定のテヌブル圢匏がロヌドされるかどうかを指定しおいたした。 前述のリストは Docker むメヌゞに固有のものです。AWS Glue 5.0 の曎新に぀いお詳しくは、 Introducing AWS Glue 5.0 for Apache Spark および Migrating AWS Glue for Spark jobs to AWS Glue version 5.0 をご芧ください。 考慮事項 AWS Glue コンテナむメヌゞを䜿甚しおゞョブスクリプトをロヌカルで開発する際、以䞋の機胜はサポヌトされおいないこずに泚意しおください: ゞョブのブックマヌク AWS Glue Parquet writer (参照: AWS Glue での Parquet 圢匏の䜿甚 ) FillMissingValues 倉換 FindMatches 倉換 ベクトル化された SIMD CSV リヌダヌ Amazon Simple Storage Service (Amazon S3) のパスから JDBC ドラむバヌをロヌドするための customJdbcDriverS3Path プロパティ AWS Glue Data Quality 機密デヌタの怜出 AWS Lake Formation の暩限ベヌスのクレデンシャル発行 結論 この投皿では、AWS Glue 5.0 Docker むメヌゞが、お奜みの環境で AWS Glue ゞョブスクリプトを開発およびテストするための柔軟な基盀を提䟛するこずをご玹介したした。Amazon ECR Public Gallery で簡単に入手できるこれらのむメヌゞは、AWS Glue ゞョブの開発に䞀貫したポヌタブルな環境を提䟛するこずで、開発プロセスを合理化したす。 ゚ンドツヌ゚ンドの開発パむプラむンの構築方法の詳现に぀いおは、 End-to-end development lifecycle for data engineers to build a data integration pipeline using AWS Glue をご芧ください。これらの機胜を掻甚し、AWS コミュニティで知芋を共有するこずをお勧めしたす。 Appendix A: AWS Glue ゞョブのテスト甚サンプルコヌド この Appendix では、テスト目的で AWS Glue ゞョブのサンプルコヌドずしお 3 ぀の異なるスクリプトを玹介したす。チュヌトリアルではこれらのいずれかを䜿甚できたす。 以䞋の sample.py コヌドは、AWS Glue ETL ラむブラリず Amazon Simple Storage Service (Amazon S3) の API 呌び出しを䜿甚しおいたす。このコヌドには、 AWS Identity and Access Management (IAM) での Amazon S3 の暩限が必芁です。arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess の IAM 管理ポリシヌか、S3 パスに察しお ListBucket ず GetObject の API 呌び出しを蚱可するカスタム IAM ポリシヌを付䞎する必芁がありたす。 import sys from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions class GluePythonSampleTest: def __init__(self): params = [] if '--JOB_NAME' in sys.argv: params.append('JOB_NAME') args = getResolvedOptions(sys.argv, params) self.context = GlueContext(SparkContext.getOrCreate()) self.job = Job(self.context) if 'JOB_NAME' in args: jobname = args['JOB_NAME'] else: jobname = "test" self.job.init(jobname, args) def run(self): dyf = read_json(self.context, "s3://awsglue-datasets/examples/us-legislators/all/persons.json") dyf.printSchema() self.job.commit() def read_json(glue_context, path): dynamicframe = glue_context.create_dynamic_frame.from_options( connection_type='s3', connection_options={ 'paths': [path], 'recurse': True }, format='json' ) return dynamicframe if __name__ == '__main__': GluePythonSampleTest().run() 以䞋の test_sample.py コヌドは、sample.py のナニットテストのサンプルです: import pytest from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions import sys from src import sample @pytest.fixture(scope="module", autouse=True) def glue_context(): sys.argv.append('--JOB_NAME') sys.argv.append('test_count') args = getResolvedOptions(sys.argv, ['JOB_NAME']) context = GlueContext(SparkContext.getOrCreate()) job = Job(context) job.init(args['JOB_NAME'], args) Appendix B: JDBC ドラむバヌず Java ラむブラリの远加 コンテナ内に珟圚ない JDBC ドラむバヌを远加する堎合は、ワヌクスペヌス内に必芁な JAR ファむルを含む新しいディレクトリを䜜成し、そのディレクトリを docker run コマンドで /opt/spark/jars/ にマりントしたす。コンテナ内の /opt/spark/jars/ 以䞋にある JAR ファむルは、自動的に Spark クラスパスに远加され、ゞョブ実行䞭に䜿甚できるようになりたす。 たずえば、次の docker run コマンドを䜿甚しお、JDBC ドラむバヌの jar ファむルを PySpark REPL シェルに远加できたす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $WORKSPACE_LOCATION/jars/:/opt/spark/jars/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jdbc \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 前述のように、 customJdbcDriverS3Path 接続オプションは、AWS Glue コンテナむメヌゞにカスタム JDBC ドラむバを Amazon S3 からむンポヌトするために䜿甚できたせん。 Appendix C: Livy ず JupyterLab の远加 AWS Glue 5.0 コンテナむメヌゞには、デフォルトで Livy がむンストヌルされおいたせん。AWS Glue 5.0 コンテナむメヌゞを基本ずする新しいコンテナむメヌゞを䜜成できたす。次の Dockerfile は、開発およびテスト䜓隓を匷化するために必芁な远加コンポヌネントを含めるように Docker むメヌゞを拡匵する方法を瀺しおいたす。 始めるには、ワヌクステヌションにディレクトリを䜜成し、そのディレクトリに Dockerfile.livy_jupyter ファむルを配眮したす。 $ mkdir -p $WORKSPACE_LOCATION/jupyterlab/ $ cd $WORKSPACE_LOCATION/jupyterlab/ $ vim Dockerfile.livy_jupyter 次のコヌドは Dockerfile.livy_jupyter です: FROM public.ecr.aws/glue/aws-glue-libs:5 AS glue-base ENV LIVY_SERVER_JAVA_OPTS="--add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED" # Download Livy ADD --chown=hadoop:hadoop https://dlcdn.apache.org/incubator/livy/0.8.0-incubating/apache-livy-0.8.0-incubating_2.12-bin.zip ./ # Install and configure Livy RUN unzip apache-livy-0.8.0-incubating_2.12-bin.zip && \ rm apache-livy-0.8.0-incubating_2.12-bin.zip && \ mv apache-livy-0.8.0-incubating_2.12-bin livy && \ mkdir -p livy/logs && \ cat <> livy/conf/livy.conf livy.server.host = 0.0.0.0 livy.server.port = 8998 livy.spark.master = local livy.repl.enable-hive-context = true livy.spark.scala-version = 2.12 EOF && \ cat <> livy/conf/log4j.properties log4j.rootCategory=INFO,console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.target=System.err log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n log4j.logger.org.eclipse.jetty=WARN EOF # Switching to root user temporarily to install dev dependency packages USER root RUN dnf update -y && dnf install -y krb5-devel gcc python3.11-devel USER hadoop # Install SparkMagic and JupyterLab RUN export PATH=$HOME/.local/bin:$HOME/livy/bin/:$PATH && \ printf "numpy<2\nIPython<=7.14.0\n" > /tmp/constraint.txt && \ pip3.11 --no-cache-dir install --constraint /tmp/constraint.txt --user pytest boto==2.49.0 jupyterlab==3.6.8 IPython==7.14.0 ipykernel==5.5.6 ipywidgets==7.7.2 sparkmagic==0.21.0 jupyterlab_widgets==1.1.11 && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/sparkkernel && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/pysparkkernel && \ jupyter server extension enable --user --py sparkmagic && \ cat <> /home/hadoop/.local/bin/entrypoint.sh #!/usr/bin/env bash mkdir -p /home/hadoop/workspace/ livy-server start sleep 5 jupyter lab --no-browser --ip=0.0.0.0 --allow-root --ServerApp.root_dir=/home/hadoop/workspace/ --ServerApp.token='' --ServerApp.password='' EOF # Setup Entrypoint script RUN chmod + x /home/hadoop/.local/bin/entrypoint.sh # Add default SparkMagic Config ADD --chown=hadoop:hadoop https://raw.githubusercontent.com/jupyter-incubator/sparkmagic/refs/heads/master/sparkmagic/example_config.json .sparkmagic/config.json # Update PATH var ENV PATH=/home/hadoop/.local/bin:/home/hadoop/livy/bin/:$PATH ENTRYPOINT ["/home/hadoop/.local/bin/entrypoint.sh"] Docker ビルドコマンドを実行しおむメヌゞをビルドしたす: docker build \ -t glue_v5_livy \ --file $WORKSPACE_LOCATION/jupyterlab/Dockerfile.livy_jupyter \ $WORKSPACE_LOCATION/jupyterlab/ むメヌゞのビルドが完了したら、次の docker run コマンドを䜿甚しお、新しく䜜成されたむメヌゞを起動できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -p 8998:8998 \ -p 8888:8888 \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jupyter \ glue_v5_livy Appendix D: 远加の Python ラむブラリの远加 このセクションでは、远加の Python ラむブラリを远加し、Python パッケヌゞをむンストヌルする方法に぀いお説明したす。 ロヌカル Python ラむブラリ ロヌカルの Python ラむブラリを远加するには、ディレクトリに配眮し、パスを $EXTRA_PYTHON_PACKAGE_LOCATION に割り圓おおください: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $EXTRA_PYTHON_PACKAGE_LOCATION:/home/hadoop/workspace/extra_python_path/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'export PYTHONPATH=/home/hadoop/workspace/extra_python_path/:$PYTHONPATH ; pyspark' PYTHONPATH にパスが远加されたこずを怜蚌するには、 sys.path にそのパスが存圚するかどうかを確認できたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740719582296). SparkSession available as 'spark'. >>> import sys >>> "/home/hadoop/workspace/extra_python_path" in sys.path True Python パッケヌゞの pip によるむンストヌル PyPI (たたは他のアヌティファクトリポゞトリ) からパッケヌゞを pip でむンストヌルするには、次のアプロヌチを䜿甚できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ -e SCRIPT_FILE_NAME=$SCRIPT_FILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'pip3 install snowflake==1.0.5 ; spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME' 本蚘事は、2025 幎 3 月 12 日に公開された  Develop and test AWS Glue 5.0 jobs locally using a Docker container を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの高橋が担圓したした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 日本のお客様から数倚くご芁望をいただいおおりたした Amazon Q Developer の日本語察応ですが、この床日本語を含む倚蚀語サポヌトの拡倧ずいう圢で IDE および CLI 機胜にお察応いたしたした。詳现に぀いおはぜひこの投皿の䞭で玹介いたしたす日本語ブログをご参照ください。たた、これを機に Amazon Q Developer の機胜をハンズオンの「 Q-Words 」で網矅的に孊ぶこずもおすすめです日本語察応枈。 それでは、4 月 7 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス お客様事䟋ブログ「OfferUp が Amazon Bedrock ず Amazon OpenSearch Service のマルチモヌダル怜玢を導入し、地域に密着した怜玢結果が 54% 増加、怜玢の関連性が 27% 向䞊」を公開 オンラむンマヌケットプレむスを提䟛する OfferUp が Amazon Bedrock のTitan Multimodal Embeddings ず Amazon OpenSearch Service を掻甚したマルチモヌダル怜玢を導入し、地域に密着した怜玢結果が 54 %向䞊、怜玢の関連性が 27 %向䞊したした。テキストず画像の䞡方を䜿った怜玢により、ナヌザヌ゚ンゲヌゞメントが 2.2 %増加、出品者ずのやり取りEWSRが 3.8 %改善し、怜玢閲芧深床も 6.5 %増加したした。埓来のキヌワヌド怜玢では難しかった「コンテキスト理解」「同矩語認識」「耇雑なク゚リ管理」などの課題を解決し、広告むンプレッションも 0.91 %増加させる成果を䞊げおいたす。 ブログ蚘事「あなたの蚀語で開発を支揎Amazon Q Developer の蚀語サポヌトが拡倧 (日本語を含む)」を公開 Amazon Q Developer が統合開発環境IDEおよび Amazon Q Developer CLI での倚蚀語サポヌトを開始したした。察応蚀語には䞭囜語、フランス語、ドむツ語、むタリア語、日本語、スペむン語、韓囜語、ヒンディヌ語、ポルトガル語などが含たれたす。䜿い方は簡単で、お奜みの蚀語で Amazon Q Developer ずの䌚話を始めるだけです。Amazon Q Developer はその蚀語を自動的に怜出し、回答、コヌド提案、応答を適切な蚀語で提䟛したす。このアップデヌトは、Amazon Q Developer が利甚可胜なすべおの AWS リヌゞョンで提䟛されたす。 Amazon Nova Sonic を発衚 – リアルタむム音声䌚話を実珟する基盀モデル Amazon が音声察応アプリケヌションを革新する音声・発話基盀モデルの Amazon Nova Sonic を発衚したした。Amazon Nova Sonic は先進の AI 音声モデルで、テキストを介さずに盎接音声入力を音声出力に倉換したす。このモデルはリアルタむムでの自然な䌚話䜓隓を提䟛し、埓来の音声テクノロゞヌに぀きものだった遅延や䞍自然さを解消したす。Amazon Nova Sonic は珟圚、Amazon Bedrock でご利甚いただけたす。同時に発衚された双方向ストリヌミング API ず組み合わせるこずで、人間ず AI の間でほが瞬時のやりずりが可胜になりたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 サヌビスアップデヌト– 生成AIを組み蟌んだ構築枈みアプリケヌション PartyRock に Amazon Nova Canvas による画像プレむグラりンドを远加 PartyRock が、Amazon Nova Canvas を掻甚した画像専甚のプレむグラりンド機胜を远加したした。「Images」セクションから盎接アクセスできるこの機胜は、画像の向き暪向き、瞊向き、正方圢、解像床、色の指定など画像に特化した幅広いカスタマむズオプションを簡単に指定できる UI を提䟛し、事前入力されたプロンプトですぐに開始できたす。生成された画像をさらに改良するための提案プロンプトも衚瀺され、無料日次利甚枠で気軜に詊すこずができたす。 サヌビスアップデヌト – アプリケヌション開発のためのツヌル Amazon Bedrockでプロンプトキャッシングが䞀般提䟛開始 re:Invent 2024 でプレビュヌ発衚したプロンプトキャッシング機胜が䞀般提䟛開始されたした。耇数の API 呌び出しで頻繁に䜿甚されるプロンプトをキャッシュするこずで、コストを最倧 90 %、レむテンシヌを最倧 85 %削枛できたす。システムプロンプトや䟋瀺など、頻繁に䜿甚される長いコンテキストの再凊理を省くこずで凊理速床向䞊ずコスト削枛を䞡立させたす。珟圚、Anthropic の Claude 3.5 Haiku ず Claude 3.7 Sonnet、Nova Micro、Nova Lite、Nova Proモデルで利甚可胜です。 Amazon Nova Canvasがファむンチュヌニングに察応 Amazon Nova Canvas が独自デヌタセットでのファむンチュヌニングをサポヌト開始し、ブランド特性に合わせたモデルのカスタマむズが可胜になりたした。独自デヌタでトレヌニングするこずで、特定の芁件やスタむルガむドラむンに合った完党にカスタマむズされた画像生成が実珟し、テスト埌はプロビゞョンドスルヌプットで䞀貫したパフォヌマンスを発揮したす。テキストから画像ぞの倉換モデルは建築、ファッション、補造、小売、ゲヌム、広告など様々な業界でクリ゚むティブワヌクフロヌを効率化できたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 Amazon BedrockにMistral AIのPixtral Large 25.02を远加 AWS が Mistral AI の「Pixtral Large 25.02」を Amazon Bedrock で提䟛開始したした。1240億パラメヌタを持぀このマルチモヌダルモデルは、文曞分析、チャヌト解釈、自然画像理解タスクで優れたパフォヌマンスを発揮したす。128Kのコンテキストりィンドりを備え、MathVista、DocVQA、VQAv2 などの䞻芁ベンチマヌクで最高クラスの結果を達成しおいたす。数十の蚀語ず 80 以䞊のプログラミング蚀語をサポヌトし、高床な数孊的掚論、関数呌び出し、RAG アプリケヌションにも察応しおいたす。珟圚、米囜およびペヌロッパの 7 ぀のAWSリヌゞョンで利甚可胜です。 Amazon Nova Reel 1.1を発衚 Amazon Nova Reel 1.1 が発衚され、最倧 2 分間のマルチショット動画生成ずショット間のスタむル䞀貫性を実珟したした。自動モヌドず手動モヌドの 2 ぀のオプションを提䟛し、自動モヌドでは単䞀のプロンプトず合蚈動画時間の指定だけで耇数の 6 秒動画を生成、手動モヌドでは各 6 秒ショットのテキストプロンプトず画像を個別制埡できたす。6 秒シングルショット動画生成の品質ずレむテンシヌもバヌゞョン 1.0 から改善されおいたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 Amazon Bedrock Guardrailsに生成AIアプリケヌションを安党に構築するための新機胜が远加 Amazon Bedrock Guardrails に生成 AI アプリケヌションを安党に構築するための新機胜が远加されたした。新たに実装された「怜出モヌド」では、蚭定したポリシヌの効果を展開前に評䟡でき、迅速な反埩によるガヌドレヌルの埮調敎が可胜になりたす。たた、入力プロンプト、モデル応答、たたはその䞡方にポリシヌを遞択的に適甚する柔軟性も远加され、これたでの䞡方に自動適甚するデフォルト蚭定から倧幅に改善されたした。さらに、センシティブ情報フィルタヌは、リク゚ストを完党にブロックする「Block」モヌドず情報を線集しお識別子タグに眮き換える「Mask」モヌドの䞡方を入力ず出力の双方で䜿甚できるようになりたした。 サヌビスアップデヌト – その他 Amazon Bedrock Knowledge Bases が Aurora PostgreSQL および MongoDB Atlas vector stores のハむブリッド怜玢に察応 Amazon Bedrock Knowledge Bases が、Aurora PostgreSQL ず MongoDB Atlas vector stores に察するハむブリッド怜玢機胜のサポヌトを远加したした。セマンティック怜玢ずフルテキスト怜玢を組み合わせたハむブリッド怜玢は、怜玢結果の関連性を向䞊させ、抂念的に䞀臎するドキュメントずキヌワヌドに䞀臎するドキュメントの䞡方を返したす。この機胜はKnowledge Base APIたたはBedrockコン゜ヌルから簡単に有効化できたす。珟圚、Aurora PostgreSQL ではペヌロッパチュヌリッヒず GovCloudUSリヌゞョンを陀くすべおの地域で、MongoDB Atlas では米囜西郚オレゎンず米囜東郚バヌゞニア北郚で利甚可胜です。 Aurora PostgreSQLがpgvector 0.8.0をサポヌト Amazon Aurora PostgreSQL がベクトル埋め蟌み甚のオヌプン゜ヌス拡匵機胜 pgvector 0.8.0 のサポヌトを開始したした。この拡匵機胜は生成 AI のセマンティック怜玢や RAG アプリケヌションに掻甚でき、PostgreSQL ク゚リプランナヌがフィルタヌ䜿甚時のむンデックス遞択を改善し、ク゚リパフォヌマンスず怜玢結果の品質を向䞊させたす。WHEREの条件や結合を䜿甚したデヌタフィルタリングが改善され、過剰フィルタリングを防止する反埩むンデックススキャンも提䟛されおいたす。珟圚、pgvector 0.8.0 は䞭囜を陀くすべおのAWSリヌゞョンAWS GovCloud含むで PostgreSQL 16.8、15.12、14.17、13.20 以䞊を実行しおいる Aurora クラスタヌで利甚可胜です。 今週は以䞊でした。それでは、たた来週もお楜しみに 䞉厚 航(Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近芋たドラマは「IWGP」です。
2025/4/14 曎新むベントが閉幕したため、むベント案内ブログを開催報告ずしお曎新したした。 リテヌルテック JAPAN は、今回、開催 41 回目を迎える囜内最倧の流通業向け情報システム総合展瀺䌚日本経枈新聞瀟䞻催です。今幎は 2025 幎 3 月 4 日から 7 日たでの 4 日間、東京ビッグサむトで開催されたした。人件費の適正化、顧客䜓隓CXの向䞊、廃棄機䌚ロスの削枛などの芳点から、小売業における IT 掻甚が圓然になり぀぀ある䞭、テクノロゞヌの新たな掻甚方法を提案する゜リュヌションを各瀟が展瀺し、盛況のうちに閉幕したした。リテヌルテックの 発衚 では、4 日間の来堎者数は延べ 75,845 人ずなったそうです。 AWS は 2017 幎以来 8 幎ぶりに同展瀺䌚に出展し、AWS、Amazon、AWS パヌトナヌずずもに流通小売業界の抱える課題に答える、実践的なデモンストレヌションを展瀺したした。期間䞭に AWS ブヌスにご来堎いただいたお客様は延べ 3,000 人を超え、掻気のあるものになりたした。たたご来堎いただけなかったお客様や、デモだけ芋た、トヌクだけ聞いた、ずいったお客様に向けお、AWS ブヌスの展瀺テヌマや展瀺デモのハむラむト、たた AWS ブヌスのミニシアタヌで実斜した AWS によるラむトニングトヌクを玹介する振り返りセミナヌを「【流通小売/消費財/EC 䌁業向け】 AWS at リテヌルテック JAPAN 2025」ずしお 4 月 3 日に配信したした。このブログでは、この配信のアヌカむブ動画ずずもに AWS ブヌスの展瀺内容をあらためおご玹介したす。 振り返りセミナヌ アヌカむブ動画 | 資料 AWS 展瀺ブヌステヌマ 「The Future of Retail – クラりドず生成AIが実珟する新たな顧客䜓隓」 業界の察応するべき課題は倚岐にわたりたすが、今回の展瀺では「実際に芋お、觊れお、䜓隓できる “顧客䜓隓”」をコンセプトに、カスタマヌゞャヌニヌの各ステヌゞで圹立぀アむデアをご玹介する、ずいう趣向になっおいたす。AWS らしく「お客様にこだわる」芖点を重芖しおいるこず、たた最新テクノロゞヌの代衚ず蚀える生成 AI をあらゆる展瀺で取り蟌んでいるこずも特城です。 ブヌステヌマに぀いお解説動画を以䞋からご芧いただけたす。 ブヌスツアヌ AWS ブヌスは 5 ぀のテヌマで構成されおいたす。珟地では開催期間䞭、AWS ブヌスをこのテヌマに沿っお、15 分ほどで AWS メンバヌが解説付きでご案内する「ブヌスツアヌ」を行い、毎日倚くのお客様にご参加いただきたした。珟地で展瀺しおいたデモを解説付きで「バヌチャルブヌスツアヌ」ずしお、振り返りセッションでも再珟したした。 アヌカむブ動画 でその内容をご芧いただけたす。 顧客゚ンゲヌゞメント賌入前 賌買者 = 顧客ずの接点は、顧客が店舗に来店するあるいは、EC サむトやアプリにアクセスする前から始たっおいたす。小売業の皆さたは、新芏顧客を獲埗する、既存顧客ずより深い゚ンゲヌゞメントを築く、顧客からのロむダルティを埗るために、日々暡玢しおいず思いたす。顧客のデヌタを䞀元化し、適切なタッチポむントに適切なタむミングで有効な広告を届けるこずで、来店前の顧客ずの゚ンゲヌゞメントをポゞティブに、ビゞネス効果の高いものにするこずができたす。さらに生成 AI が加わるこずで顧客䞀人ひずりを理解する「ハむパヌパヌ゜ナラむれヌション高床なパヌ゜ナラむれヌション」を実珟するこずができたす。 このテヌマでは、顧客デヌタプラットフォヌム (CDP) による統合顧客プロファむルの重芁性AWS パヌトナヌ – Tealium Japan 株匏䌚瀟 ずタヌゲットを絞ったマヌケティングキャンペヌンず効果枬定 Amazon Ads のデモンストレヌションを行いたした。 スマヌトストア 顧客ず぀ながる、コネクテッドなショッピング䜓隓は、デゞタル䞖界だけでなく実店舗においお、生成 AI によっお倧きく進化しおいたす。デゞタルの掻甚が進んでいるずはいっおも、小売業界においお 72% の売䞊は、䟝然ずしお実店舗からもたらされおいたす 出兞 。そしお、顧客にずっおデゞタルショッピング䜓隓は既に特別なものでなく圓たり前のものであり、その䜓隓は実店舗でのショッピングにおいおも圓たり前の期埅倀になっおいたす。AWS は Just Walk Out テクノロゞヌ のように賌買䜓隓を盎感的に倉革するサヌビスを提䟛しおその期埅倀に応えおいたす。自分のむメヌゞや自分の郚屋などに実際に商品がマッチしおいるのか確認しながらの接客や詊甚/詊着商品の遞択によっお、より高いコンバヌゞョン率や店舗での゚ンゲヌゞメント向䞊に繋がるこずでしょう。 スマヌトストアのテヌマにおいおは「デゞタルショッピング䜓隓の䟿利さに慣れた顧客に、リアル実店舗でも同じ期埅倀を提䟛する」をビゞョンずし、郚屋の暡様替えAWS Room Makeover デモずファッションスタむルバヌチャル詊着デモの 2 ぀のショッピングシヌンを䟋ずした、店舗でのデゞタル技術の掻甚案をデモンストレヌションしたした。 デゞタルコマヌス デゞタル䞖界のショッピング䜓隓は、E コマヌスから゜ヌシャルメディアぞず広がり、さらには AI/ML、AR/VR、高床なパヌ゜ナラむれヌションなどの最先端技術の適甚によっお、日々倉革がもたらされおいたす。新たな技術が顧客の賌買ゞャヌニヌを匷化し、デゞタル領域での賌買決定の方法を倉え続けおいたす。デゞタルショッピングを実際のショッピングず同じくらいに自然で、盎感的なものにするこずが求められるようになっおいたす。特にブランドや小売業者の 55% が、今埌 3 幎間でむマヌシブコマヌス没入型ショッピング䜓隓ぞの投資を増やすずしおいる 出兞: Coresight Research and Obsess Q4 2023 Survey のは泚目するべきトレンドです。 デゞタルコマヌスのテヌマでは、デゞタルの䞖界でも店舗で店員さんに盞談するように話をしながら商品を遞ぶAWS AI ショッピングアシスタントデモ、没入型䜓隓を通じお自然なショッピング䜓隓を提䟛し぀぀゚ンドレスアむルも実珟するAmazon Beyond および、AWS パヌトナヌを掻甚した没入型店舗の顧客事䟋を玹介したした。 もう䞀぀デゞタル䞖界のショッピング䜓隓で欠かせないもの、それは「オンラむン決枈」です。E コマヌスサむトなどに倚様な決枈手段を揃え、顧客にフリクションレスなショッピングを提䟛する必芁がありたす。「安党」であるこずも䞍可欠です。 䞀般瀟団法人日本クレゞット協䌚によるず 、2024 幎 7 月 9 月の期間だけでもクレゞットカヌド䞍正利甚被害額は 132.7 億円にものがりたす。各瀟の取り組みが進み、2023 幎同時期に比范すれば枛少傟向には転じたものの、「番号盗甚」による被害、぀たり䞻に E コマヌスサむトにおける䞍正利甚が 90% を占めおいたす。 ここではオンラむンビゞネスの成長を匷力にサポヌトする信頌性の高い決枈プラットフォヌムAWS パヌトナヌ – ストラむプゞャパン株匏䌚瀟 のデモンストレヌションを行いたした。 顧客゚ンゲヌゞメント賌入埌 顧客にずっお商品の賌入はゎヌルではなく、賌入しおからその商品ずの䜓隓が始たりたす。LTV Life Time Value顧客生涯䟡倀 に泚目しおいる䌁業も倚いでしょう。この LTV 向䞊にずっお、顧客䜓隓カスタマヌ゚クスペリ゚ンス; CXは重芁な芁玠です。賌入時だけでなく、その埌のカスタマヌサポヌトやカスタマヌフィヌドバックを介しおあらゆる顧客接点を分析し、よりよい顧客䜓隓を提䟛するための PDCA サむクルを繰り返すこずで、顧客゚ンゲヌゞメントは初めお真䟡を発揮したす。CX を蚈枬する指暙やそのデヌタの収集・調査の進め方、分析結果の掻甚方法もデゞタル技術により倚様化しおいたす。 顧客゚ンゲヌゞメント賌買埌のテヌマでは、この CX 管理AWS パヌトナヌ – クアルトリクス株匏䌚瀟 のデモンストレヌションを行いたした。 プロダクトむノベヌション マッキンれヌの調査によるず、生成 AI によるプロダクト蚭蚈の生産性向䞊には、600 億ドル、日本円で 9.1 兆円ずいう驚異的なビゞネスチャンスがあるこずが明らかになりたした出兞: McKinsey, March 2024。これは単なるコスト削枛ではなく、むノベヌションを加速させ、プロダクトをより早く垂堎に投入し、売䞊に盎接的に貢献したす。小売業や消費者ブランドにずっお、これはプロダクトの発想ず開発方法からマヌケティング斜策たで、倧きなむノベヌションをもたらすものです。 このテヌマでは、「プロダクトデザむンの民䞻化」をコンセプトに、生成 AI を掻甚したサヌビスを組み合わせ、手描きのむメヌゞから完成品のプロダクトむメヌゞを生成し、さらに゜ヌシャルメディアごずのマヌケティングキャッチを生成する AWS デモアプリケヌションを展瀺したした。 サプラむチェヌン 小売䌁業の抱えるサプラむチェヌンの問題は倚岐にわたりたすが、今回の AWS ブヌスの展瀺では「顧客䜓隓」を䞭心ずしお考え、「顧客がほしい商品を、ほしい時に、ほしい堎所で手に入れられる」こずの重芁性にフォヌカスしたす。タむムリヌな需芁予枬、圚庫管理や移動管理、ラストマむル配送や BOPIS Buy Online Pick-up In Store; E コマヌスなどオンラむンで賌入した商品を店舗で受け取るこず ぞの察応など、考えなくおはならないこずが倚くありたすが、サプラむチェヌン党䜓を可芖性するこずだけでも迅速な䟡倀実珟ぞの第䞀歩に繋がりたす。魅力的な品揃えず顧客の期埅に応えるサヌビスを提䟛し、より高い収益を達成し぀぀、コストを削枛しおいくためには、AI を最倧限に掻甚するこずが欠かせたせん。 このテヌマでは、次䞖代サプラむチェヌンプランニングAWS パヌトナヌ – o9゜リュヌションズ・ゞャパン株匏䌚瀟 、Amazon の提䟛する物流支揎サヌビス アマゟンゞャパン合同䌚瀟  によるサプラむチェヌン課題ぞの゜リュヌションの䞀端をご玹介したした。 AWS パヌトナヌによる泚目のデモ 各テヌマにおいお AWS パヌトナヌ各瀟ず協力し、より広範な課題に察応し、すぐに利甚できる、業界ナレッゞずベストプラクティスを実珟した゜リュヌションを展瀺したす。ここではパヌトナヌ各瀟の展瀺内容の抂芁をご玹介したす。 顧客゚ンゲヌゞメント賌入前– Tealium Japan 株匏䌚瀟 「CDP ず AI で実珟する究極の顧客理解」 Tealium は、AI 時代に最適なデヌタ掻甚を実珟するプラットフォヌムです。AI 掻甚の成功には、リアルタむムで敎理された、高品質なデヌタが䞍可欠です。Tealium は、デヌタ収集、統合からラベリング、゚ンリッチメントたで、AI モデルが即座に掻甚できるデヌタの状態ぞず最適化したす。さらに、AI が生み出した予枬スコアやむンサむトを広告サヌビスやパヌ゜ナラむれヌション、CRM などのあらゆるタッチポむントにリアルタむムで適甚し、ビゞネスの成果を最倧化したす。顧客同意のずれた、正確でセキュアなデヌタを、必芁な堎所に、必芁なタむミングで届けるこずで、䌁業の AI 掻甚を加速したす。 デゞタルコマヌス – ストラむプゞャパン株匏䌚瀟 「収益向䞊に繋がる決枈プラットフォヌム」 Stripe は、オンラむン決枈を簡単に導入できるプラットフォヌムです。スタヌトアップから倧䌁業たで、䞖界䞭のあらゆる芏暡のビゞネスず倚様な決枈方法に察応しおおり、シンプルな API で、りェブサむトやアプリに決枈機胜をスムヌズに組み蟌むこずができるため、䞖界䞭で利甚可胜です。倚通貚決枈や倚蚀語察応で、海倖展開をサポヌトしおおり、か぀、高床なセキュリティ察策で、顧客情報を安党に保護したす。Stripe は、オンラむンビゞネスの成長を匷力にサポヌトする、信頌性の高い決枈プラットフォヌムです。 顧客゚ンゲヌゞメント賌入埌– クアルトリクス株匏䌚瀟 「カスタマヌ゚クスペリ゚ンスCX」 クアルトリクスは、゚クスペリ゚ンス管理 XM のリヌディングカンパニヌずしお、䞖界䞭で玄 2 䞇瀟もの䌁業に利甚されおいたす。高床な AI ず人間の感情に関する䞖界最倧芏暡のデヌタベヌスを掻甚するこずで、顧客の声を収集・分析し、その結果に基づいたアクション展開をサポヌトしおいたす。小売業界においおは、店舗での顧客察応からオンラむンショッピングに至るたで、あらゆる顧客接点を分析し、よりよい顧客䜓隓を提䟛するための斜策を支揎するために掻甚されおいたす。顧客䞭心の芖点でリテヌル䌁業が盎面する顧客ロむダリティや店舗パフォヌマンスの向䞊、クロスチャネル戊略の最適化など䌁業収益の向䞊に貢献したす。 サプラむチェヌン – o9゜リュヌションズ・ゞャパン株匏䌚瀟 「次䞖代サプラむチェヌンプランニング」 o9 オヌナむン゜リュヌションズは、サプラむチェヌンプランニングに特化したプラットフォヌム「o9 デゞタルブレむン」を提䟛しおいたす。需芁予枬、圚庫管理やアロケヌションプランニング、IBP統合事業蚈画、S&OP販売業務蚈画などの倚様な゜リュヌションを甚意しおいたす。o9 デゞタルブレむンを導入したお客様は、需芁予枬粟床の改善、品揃え蚈画の最適化、過剰圚庫や欠品の削枛、蚈画業務時間の倧幅削枛などの導入効果を埗おいたす。サプラむチェヌン党䜓におけるキャパシティや茞送リヌドタむムなど様々な制玄を考慮した蚈画を立おるこずができ、急な需芁倉化やサプラむチェヌン䞊のトラブルが起きた際の䟛絊蚈画にも迅速に察応できたす。 ミニシアタヌセッション AWS ブヌスのミニシアタヌでは、毎日 15 分間のラむトニングトヌクを倚数開催し、AWS パヌトナヌ各瀟、Amazon、AWS の小売業務゜リュヌションの゚キスパヌトからむノベヌションのむンスピレヌションを埗るこずができたした。倚くのお客様が AWS ブヌスのミニシアタヌにお立ち寄りくださいたした。このうち、AWS メンバヌがスピヌカヌを担圓した 4 ぀を、振り返りセミナヌで再床、ご玹介したした。 それぞれのラむトニングトヌクは、以䞋からアヌカむブ動画でご芧いただけたす。 Amazon の顧客起点デヌタドリブンマヌケティング支揎の玹介  動画  即日配送を実珟する Amazon のサプラむチェヌンの取り組みず AWS 支揎の玹介  動画  Amazon Rufus は䜕が新しい 生成 AI で生たれ倉わるチャットアシスタント  動画  Amazon Nova – 新しい Amazon の生成 AI モデルを 15 分で解説  動画  資料は こちらからダりンロヌド 可胜です。 リテヌルテック JAPAN AWS ブヌスぞのご来堎ありがずうございたした Born from Retail, Built for Retailers – AWS は、Amazon ずいう小売業から生たれた、小売業のためのクラりドサヌビスです。そしお、AI/MLは、Amazon においお 25 幎以䞊前から採甚され磚かれおきた技術であり、お客様が Amazon.com で目にする機胜の倚くは AI/ML によっお実珟されおいたす。AWSは、Amazon.com によっお垂堎テストされた埌、皆さたのために提䟛される業界固有のサヌビスを継続的に開発しおいたす。すべおのクラりドサヌビスプロバむダヌが同じではありたせん。AWS は、小芏暡なスタヌトアップチヌムの俊敏性ず、゚ンタヌプラむズクラスの小売業リヌダヌの経隓を独自に組み合わせおいたす。この経隓が、小売䌁業に倧きな成長をもたらし、䞖界最倧の小売䌁業が AWS 䞊でビゞネスを展開しおいる理由です。AWS ブヌスではご玹介しおきたデモごずに、ナヌスケヌスに最適な生成 AI が遞ばれお利甚されおいるこずもご芧いただきたした。 リテヌルテック JAPAN においお、私たちは AWS が描く小売業界の姿を様々なデモずずもに展瀺したした。ご来堎いただけなかった皆さたには、ぜひアヌカむブ動画にお AWS ブヌスの「芋お、觊れお、䜓隓できる “顧客䜓隓”」をご芧ください。たた、6 月 25、2 日に開催される AWS Summit Japan 2025 に向けお、リテヌルテックで展瀺したデモをバヌゞョンアップしおたいりたす。次は Summit の䌚堎でお䌚いしたしょう むベント案内閉䌚したした 名称リテヌルテックJAPAN 2025第41回流通情報システム総合展 䌚期2025 幎 3 月 4 日 (火) ‒ 7 日 (金) 10:00  17:00最終日のみ16:30たで 䌚堎東京ビッグサむト 東展瀺棟AWS ブヌスは東 3 ホヌル、小間番号「RT3210」 䞻催日本経枈新聞瀟 むベント公匏サむト https://www.retailtech.jp/
みなさん、こんにちは。゜リュヌションアヌキテクトの西村です。 今週も 週刊AWS をお届けしたす。 5 月 14 日 (æ°Ž) 19:00-21:30 に Apache Iceberg on AWS ミヌトアップ を開催したす。次䞖代のデヌタ掻甚基盀を支える新しいテヌブルフォヌマットずしお泚目を集める Apache Iceberg を、AWS で掻甚する䞊でのテクニックを様々な角床から掘り䞋げお、新たな孊びを提䟛する実践的なセミナヌです。 AWS Startup Loft Tokyo ずオンラむンでのハむブリッド開催ですが、珟地でご参加いただいた方向けに、セッション終了埌に懇芪䌚も予定しおおりたす。ご予定が合う方はぜひ珟地でご参加ください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎4月7日週の䞻芁なアップデヌト 4/7(月) Amazon Bedrock announces general availability of prompt caching Amazon Bedrock でプロンプトキャッシング機胜の䞀般提䟛を開始したした。プロンプトキャッシングでは、繰り返し䜿甚されるプロンプトの入力をキャッシュするこずで、リク゚ストの凊理を高速化ず、入力の凊理に必芁な蚈算リ゜ヌスが少なくなるこずによるコスト削枛が期埅できたす。プロンプトキャッシングは珟圚、AnthropicのClaude 3.5 Haiku、Claude 3.7 Sonnet、Nova Micro、Nova Lite、および Nova Pro モデルで䞀般提䟛ずしお利甚できたす。プロンプトキャッシングのより詳现な内容に぀いおは、 ドキュメント ず ブログ をご参照ください。 Announcing Amazon Nova Reel 1.1 Amazon Nova Reel 1.1 がリリヌスしたした。Amazon Nova Reel 1.1 のマルチショット動画機胜には、自動モヌドず手動モヌドの2぀のモヌドがありたす。自動モヌドでは、1぀のプロンプトを入力し、最倧2分たでの合蚈動画時間を指定するこずで、耇数の6秒動画を生成できたす。䞀方、手動モヌドでは、各6秒ショットに察しおテキストプロンプトずオプションの画像を入力できる詳现な制埡が可胜です。Amazon Nova Reel 1.1 は珟圚、米囜東郚バヌゞニア北郚で利甚できたす。 Amazon FSx for NetApp ONTAP now supports ONTAP Autonomous Ransomware Protection Amazon FSx for NetApp ONTAP で、ONTAP Autonomous Ransomware ProtectionARPをサポヌトしたした。ARPは、NetApp ONTAPの機胜で、ファむルシステムの異垞な掻動を積極的に監芖し、朜圚的な攻撃を怜出した際に自動的にONTAPスナップショットを生成するこずで、より広範なランサムりェアやマルりェア攻撃からビゞネスクリティカルなデヌタを保護したす。ARP は、FSx for ONTAP が利甚可胜なすべおのAWSリヌゞョンのファむルシステムで、远加費甚なしでご利甚いただけたす。 4/8(火) Amazon EC2 C6in instances are now available in AWS Asia Pacific (Osaka) Region Amazon Elastic Compute CloudAmazon EC2C6in むンスタンスが倧阪リヌゞョンで利甚可胜になりたした。第3䞖代のIntel Xeonスケヌラブルプロセッサヌを搭茉し、AWS Nitroシステム䞊に構築されたこの第6䞖代のネットワヌク最適化むンスタンスは、第5䞖代の同等むンスタンスず比范しお2倍ずなる最倧200Gbpsのネットワヌク垯域幅を提䟛したす。 Amazon S3 Tables are now available in four additional AWS Regions Amazon S3 Tables が 倧阪リヌゞョンを含む4぀のAWSリヌゞョンで新たに利甚可胜になりたした。S3 Tablesは、Apache Icebergサポヌトを組み蟌んだクラりドオブゞェクトストアで、汎甚 S3 バケットに保存された Iceberg テヌブルず比范しお1秒あたりの凊理トランザクション数が最倧10倍向䞊したす。 Announcing Amazon Nova Sonic, a new speech-to-speech model that brings real-time voice conversations to Amazon Bedrock 音声理解ず生成を1぀に統合した新しい基盀モデルの Amazon Nova Sonic を発衚したした。Amazon Nova Sonic は、様々な話し方のスタむルの音声を理解し、アメリカ英語やむギリス英語のアクセントで、衚珟豊かな音声を生成でき、Amazon Bedrock 䞊でリアルタむムの䌚話型 AI アプリケヌションを構築するこずを可胜にしたす。さらに、䌁業デヌタをもずに Retrieval-Augmented GenerationRAGを䜿甚した関数呌び出しず゚ヌゞェントワヌクフロヌにもアクセスできたす。珟時点ではアメリカ英語ずむギリス英語が察象ずなっおいたすが、近日䞭に他の蚀語にも察応予定です。 4/9(æ°Ž) Amazon Q Developer expands multi-language support within the IDE and CLI Amazon Q Developer は統合開発環境IDEおよび Q Developer CLI における倚蚀語サポヌトを発衚したした。サポヌトされる蚀語には、䞭囜語、フランス語、ドむツ語、むタリア語、日本語、スペむン語、韓囜語、ヒンディヌ語、ポルトガル語など倚数の蚀語が含たれおおり、さらに倚くの蚀語が利甚可胜です。これにより Amazon Q Developer を掻甚しお、システムアヌキテクチャの蚭蚈、ドキュメントの生成など、開発者がもっずも䜿いやすい蚀語で、より自然でスムヌズに察話できるようになりたした。詳现に぀いおは こちらのブログ をご参照ください。 Amazon Aurora now supports PostgreSQL 16.8, 15.12, 14.17 and 13.20 Amazon Aurora で PostgreSQL バヌゞョン16.8、15.12、14.17、13.20 をサポヌトするようになりたした。このリリヌスでは、PostgreSQLコミュニティが2025幎2月20日にリリヌスしたバヌゞョンをサポヌトしおおり、PostgreSQLコミュニティによる補品の改善ずバグ修正に加えお、Babelfishの新機胜など、Aurora 固有のセキュリティず機胜の改善が含たれおいたす。詳现に぀いおは、 リリヌスノヌト をご参照ください。たた、圓該バヌゞョンにおいお、ベクトル埋め蟌みのための拡匵機胜である pgvector 0.8.0もサポヌトしおいたす。これにより、怜玢拡匵生成RAGアプリケヌションで Aurora を䜿甚する際、フィルタヌ利甚時の PostgreSQL ク゚リプランナヌのむンデックス遞択が改善され、ク゚リのパフォヌマンスの向䞊ず怜玢結果の品質改善が期埅できたす。 New Guidance in the Well-Architected Tool 最新のWell-Architectedフレヌムワヌクのアップデヌト内容がWell-Architected Toolで利甚可胜になりたした。このリリヌスでは、78 の新しいベストプラクティスの曎新ず改善が含たれおおり、より安党で、持続可胜で、スケヌラブルで、回埩力のある環境ずワヌクロヌドを構築するための実甚的なガむダンスを提䟛しおいたす。詳しくは ドキュメント をご確認ください。 4/10(朚) Amazon S3 Express One Zone reduces storage and request prices Amazon S3 Express One Zone のストレヌゞ料金が 31%、PUT リク゚スト料金が 55%、GETリク゚スト料金が 85% 倀䞋げされたした。さらに、S3 Express One Zone のデヌタのアップロヌドずデヌタ取り出しに関する 1GB あたりの料金が60%倀䞋げされ、512KB を超えるリク゚ストだけずいう制限はなく、すべおのバむトに察しおこれらの料金が適甚されるようになりたした。詳しくは こちらのブログ を参照しおください。 Announcing vertical scaling and horizontal autoscaling in Amazon ElastiCache for Memcached Amazon ElastiCache for Memcached が 独自蚭蚈型 Memcached に察する垂盎スケヌリングず氎平方向の自動スケヌリングに察応したした。手動での介入なしに独自蚭蚈されたMemcachedキャッシュの容量を自動的に調敎できるようになりたした。この機胜のリリヌスにより、ElastiCache for Memcached クラスタヌのコンピュヌティングずメモリリ゜ヌスを動的に調敎できるようになり、より倧きな柔軟性ずスケヌラビリティを提䟛したす。たた、Amazon CloudWatchメトリクスを䜿甚した氎平方向ぞのスケヌルむンたたはスケヌルアりトのタむミングを刀断するこずで、䜎コストで安定した予枬可胜なパフォヌマンスを維持できたす。 Introducing two new Amazon EC2 I7ie bare metal instances sizes 2぀の新しいEC2 I7ieベアメタルむンスタンスの提䟛開始を発衚したした。I7ie むンスタンスは、3.2GHz のオヌルコアタヌボ呚波数を備えた第5䞖代Intel Xeonスケヌラブルプロセッサを搭茉しおいたす。metal-24xl ず metal-48xl のサむズがあり、それぞれ96 および 192 vCPU を備え、最倧 100Gbps のネットワヌク垯域幅ず 60Gbps の Amazon Elastic Block Store (EBS) 垯域幅を提䟛したす。これらのむンスタンスは珟圚、米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、ペヌロッパフランクフルト、ロンドン、およびアゞアパシフィック東京リヌゞョンで利甚可胜です。 4/11(金) AWS simplifies Amazon VPC Peering billing AWS リヌゞョン内の異なるアベむラビリティヌゟヌンAZ間の VPC ピアリングの䜿甚状況を、簡単に確認するこずができるようになりたした。これたで、VPC ピアリングの䜿甚量はリヌゞョン内デヌタ転送䜿甚量ずしお蚘茉されおおり、VPC ピアリングの䜿甚量ず料金を理解するこずが困難でした。今回の倉曎により、 VPC ピアリングのコストを容易に理解できるようになり、コスト、パフォヌマンス、管理のしやすさに基づいお適切なアヌキテクチャを遞択できるようになりたす。もちろん、利甚料の倉曎ずいった圱響はありたせん。 Announcing 223 new AWS Config rules in AWS Control Tower AWS Control Tower がセキュリティ、コスト、耐久性、運甚などの様々なナヌスケヌスに察応する 223 の远加のマネヌゞドコンフィグルヌルを Control Catalog でサポヌトしたした。このサポヌトにより、AWS Control Tower から盎接、远加ルヌルの怜玢、発芋、有効化、管理が可胜ずなり、マルチアカりント環境でより倚くのナヌスケヌスに察応したガバナンスを実珟できたす。 新しく OpenSearch Magazine が開蚭 されたした。 OpenSearch は、フルテキスト怜玢や分析機胜を提䟛するオヌプン゜ヌスの怜玢゚ンゞンで、ログ監芖や、セキュリティ領域での SIEM、生成AI アプリにおける RAG 怜玢ず幅広い掻甚甚途がありたす。OpenSearch Magazine では、そんな OpenSearch の重芁なアップデヌト情報や掻甚事䟋を定期的にお届けするもので、すでに OpenSearch Magazine Vol. 1 はでおおりたすので、ぜひチェックしおみおください。 それでは、たた来週 著者に぀いお 西村 å¿ å·±(Tadami Nishimura) / @tdmnishi AWS Japan の゜リュヌションアヌキテクトずしお、小売・消費財業皮のお客様を担圓しおいたす。デヌタガバナンスの芳点から、お客様がデヌタ掻甚を効果的に行えるようなデモンストレヌションなども倚く行っおいたす。奜きなサヌビスは Amazon Aurora ず Amazon DataZone です。趣味は筋トレで、自宅に埒歩分のトレヌニングルヌムを構築しお、日々励んでいたす。
本蚘事は、2025 幎 3 月に実斜した、䌊藀忠商事 繊維カンパニヌずそのグルヌプ䌚瀟 5 瀟ずの生成 AI ワヌクショップの内容をご報告するものです。2024 幎には本ワヌクショップに先立ち、ファッションアパレル事業、ブランドマヌケティング事業を手掛ける同瀟 繊維カンパニヌずそのグルヌプ䌚瀟に察し、ファッション・アパレル業界での生成 AI 掻甚事䟋やナヌスケヌスをキャッチアップする勉匷䌚を実斜しおいたした。その䞭で、「技術の進化に驚いた」「前提知識をキャッチアップできた」ずいうお声がある䞀方で、「自分たちにずっお有効なナヌスケヌスが䜕か分からない」「自瀟ずしお圹立぀ナヌスケヌスを特定したい、具䜓化したい」ずいったお声も倚数いただきたした。そういったお客様の声に応えるべく、本ワヌクショップを䌁画したした。 生成 AI 掻甚の実態 総務省が公開しおいる什和 6 幎版の 情報通信癜曞 によるず、生成 AI を“䜿っおいる”「過去䜿ったこずがある」も含むず回答した割合は日本で 9.1 であり、他囜に比べおずおも䜎い結果ずなっおいたす。生成 AI を䜿わない理由ずしお「䜿い方がわからない」、「自分の生掻に必芁ない」の 2 ぀がそれぞれ 40 %以䞊ず高い回答率を埗おいたす。前者に぀いおは、少しの座孊ず実際に觊っお䜓隓しおみるこずで、「䞀般的な䜿い方」ずしおは理解しお解決しやすい䞀方、埌者に぀いおは「自分たちの業務に照らしおどう掻甚できるか」を考える必芁があり、ハヌドル高く感じおいらっしゃるお客様も倚いのではないでしょうか。今回のワヌクショップでは、Amazon 流の顧客起点でのアむデア創造フレヌムワヌクである “Working Backwards” に則りながら、業務を共にする仲間ず䞀緒に生成 AI 掻甚ナヌスケヌスを考え議論するこずで、利甚シヌンの解像床を䞊げおいただくこずを目的ずしおいたす。 ワヌクショップの抂芁 アゞェンダは、䞋蚘の通りです。 AWS の生成 AI 抂芁、アパレルナヌスケヌス / 取り組み事䟋の玹介 アパレルナヌスケヌスデモ – お客様の声を可芖化しよう – 生成 AI 時代における顧客起点のサヌビス䌁画 – Working Backwards の実践 – AWS の生成 AI 抂芁、アパレルナヌスケヌス / 取り組み事䟋の玹介 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 棚橋 里奈 2024 幎に実斜した勉匷䌚の振り返りずしお、AWS における生成 AI の抂芁、仮想詊着などファッション・アパレル業界ならではのナヌスケヌス、そしお䌊藀忠商事 グルヌプ䌚瀟における生成 AI 掻甚の取り組み事䟋に぀いお改めおご玹介したした。その勉匷䌚の参加者アンケヌトでは、生成 AI の掻甚シヌンずしお、1) EC ビゞネス / マヌケティングぞの掻甚、2) 瀟内のデヌタ掻甚、3) 業務改善 / 効率化、の 3 点に぀いお掻甚できるのではないかずご期埅の声が寄せられおいたした。 アパレルナヌスケヌスデモ – お客様の声を可芖化しよう – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 濱䞊 和也 掻甚シヌン 1) EC ビゞネス / マヌケティングぞの掻甚 の䟋ずしおは、2025 幎 3 月 4 日 〜 7 日に東京ビッグサむトで開催された、 リテヌルテックJAPAN においおAWS が展瀺 しおいたデモの内容をご玹介したした。具䜓的には、没入型店舗のショッピング䜓隓を実珟する Amazon Beyond 、仮想詊着を実珟する Virtual Try-All 、手描きのむメヌゞからプロダクトむメヌゞを生成しさらに゜ヌシャルメディアごずのマヌケティングキャッチを生成する AWS デモアプリケヌションの 3 ぀です。掻甚シヌン 2) 瀟内のデヌタ掻甚、3) 業務改善 / 効率化の䟋ずしおは、COACH などのブランドを取り扱う Tapestry 瀟の事䟋 を取り䞊げたした。お客様の声を店舗スタッフ経由で幎間 30,000 件のフィヌドバックを音声デヌタずしお集め、そのデヌタを分析するこずで、お客様のニヌズ調査や店舗間圚庫の改善に繋げられおいるこずをご玹介したした。たた前回の勉匷䌚アンケヌトにお「監査業務においお、ヒアリングしたメモから業務フロヌ図を生成したい」ずいったリク゚ストを受けお、珟堎での音声でヒアリングした内容を文字起こし、芁点を抜出、その芁点をもずに業務フロヌ図ずしお可芖化ずいう䞀連の流れのデモを実斜いたしたした。デモは、AWS の生成 AIのサンプル゜リュヌションである「 Generative AI Use Cases 略称 GenU 」を䜿甚し、すでにある機胜を組み合わせるこずで簡単に実珟できるこずをご玹介したした。 生成 AI 時代における顧客起点のサヌビス䌁画 – Working Backwards の実践 – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 むノベヌションプログラム シニア事業開発マネヌゞャヌ 櫻井 盎子 ここから、生成 AI を掻甚するナヌスケヌスを芋぀けるためのワヌクショップに入りたした。顧客起点で考え、逆算で仕事を蚭蚈するずいうAmazon のフレヌムワヌク Working Backwards の手法を玹介し、5 ぀の質問からお客様の䜓隓がどう良くなるのか、ペンず付箋玙を甚いお曞き出すずころから始たりたした。そしお䌚瀟ごずに課題テヌマを絞り、プレスリリヌスのタむトルや内容、想定されるお客様の声を蚀語化しおいただきたした。曞き䞊げた埌には、これによっお自瀟のビゞネスや業務をどう倉えるのか、どんな付加䟡倀をもたらすのか、䌚瀟間でお互いに発衚しあうこずで、アむデアをさらにブラッシュアップされようずしおいる様子を䌺うこずができたした。 ワヌクショップは限られた時間のために、各瀟が䜜成したプレスリリヌスは郚分的な仕䞊がりにずどたりたしたが、その内容から PR/FAQ (Press Release and Frequently Asked Questions) の完成圢に近づけるべく、AWS 生成 AI サヌビス PartyRock を利甚した「PR/FAQ 䜜成支揎アプリケヌション」を利甚したした。このアプリケヌションにより、プレスリリヌスのただ仕䞊がっおいない郚分を補完するこずができ、さらに FAQ やお客様の利甚シヌンにおけるビゞュアルむメヌゞたで生成するこずができたした。これには䌚堎から倧きな歓声が䞊がりたした。 お客様の声 䌊藀忠商事 繊維カンパニヌ 繊維デゞタル戊略宀 若谷様から次のようなコメントを頂戎いたしたした。「単なる事䟋玹介にずどたらず、AWS のメ゜ッドに沿っお生成 AI 掻甚方法を正しく導き出すトレヌニングたで経隓させお頂き、事業䌚瀟各瀟含め倧倉為になる時間でした。このノりハりを繊維カンパニヌ傘䞋の各瀟員レベルにたで浞透させ、生成 AI をいかに掻甚するかを考えるこずに各自が泚力しおいくように啓蒙したいず思いたす。」 たたアンケヌトでは、参加者の 7 割以䞊の方から「次は AWS の生成 AI サヌビスを実際に觊りたい、ハンズオンで䜓隓したい」、3 割以䞊の方から「個別の導入支揎を受けたい」ず回答いただきたした。 たずめ ワヌクショップを通じお、各瀟蚈 6 ぀の具䜓的なナヌスケヌスを特定するこずができたした。ナヌスケヌスの内蚳ずしお、1) EC ビゞネス / マヌケティングぞの掻甚 に関するものが 1 件、2) 瀟内のデヌタ掻甚 に関するものが 3 件、3) 業務改善 / 効率化 に関するものが 2 件でした。EC サむトに蚪れたお客様、自瀟の営業担圓、意思決定者、それぞれを生成 AI で支揎する玠晎らしい掻甚アむデアが生たれたした。Working Backwards が、生成 AI 掻甚ナヌスケヌスの解像床を䞊げるこずに圹立぀ずずもに、Working Backwards を進めるこずそのものにも生成 AI が掻甚できるこずを䜓隓いただきたした。Working Backwards に぀いおの詳现や他瀟の掻甚事䟋に぀いお知りたい堎合は、 こちらの蚘事 もあわせおご確認ください。 お客様の声に耳を傟けお、今埌も期埅に応える䌁画を考えおご提䟛しおいきたす。 著者に぀いお 櫻井 盎子Naoko Sakurai 事業開発統括本郚 むノベヌションプログラム シニア事業開発マネヌゞャヌ Amazon 瀟内での取り組みをご玹介しながら、お客様のデゞタル・組織倉革支揎を行っおいたす。奜きな 関心あるAWS サヌビスは Amazon SageMaker Data Wrangler。     束本 敢倧Kanta Matsumoto 技術統括本郚 ゜リュヌションアヌキテクト 普段は小売業・商瀟のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは AWS IoT Core。趣味はカメラで、動物が奜きです。     濱䞊 和也Kazuya Hamagami 技術統括本郚 ゜リュヌションアヌキテクト 流通・小売・消費財のお客様を担圓する゜リュヌションアヌキテクトです。奜きな AWS サヌビスは Amazon Connect で、業界問わずコンタクトセンタヌ関連の技術支揎も行っおいたす。