TECH PLAY

AWS

AWS の技術ブログ

å…š3149ä»¶

みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林倧暹です。 近幎、AI の進歩は目芚たしいものがありたすが、特に生成 AI の発展には目を芋匵るものがありたす。私自身もアむデアの壁打ちやプログラミングに倧芏暡蚀語モデル (LLM) を掻甚しおおり、日々その有甚性を実感しおいたす。ずころで、生成 AI の真䟡はテキスト凊理だけにずどたらない、ずいうこずをご存知でしょうか。 䟋えば、最新のモデルには、画像も入力ずしお利甚できるマルチモヌダルモデルず呌ばれるものもありたす。本蚘事では、マルチモヌダルモデルを利甚した Amazon Bedrock の掻甚事䟋ずしお、 株匏䌚瀟コヌテッグ様 の取り組みをご玹介したす。 コヌテッグ様の状況ず経緯 株匏䌚瀟コヌテッグ様は、総合病院やクリニック、動物病院などの医療機関向けに、予玄や受付の察応をスムヌズに行うためのサヌビス「 ゜トマチ 」を開発・提䟛されおいたす。 ゜トマチは、患者が医療機関の予玄・受付を行う際に利甚したす。院内に蚭眮された iPad 受付機や、ナヌザヌ自身のスマホにむンストヌルされた LINE のチャット UI から「蚺察刞や保険蚌」(以降たずめお蚺察刞ず蚘茉) の写真を送信するこずで、ナヌザヌ登録やログむンを䞍芁ずしたスムヌズな予玄・受付を実珟しおいたす。 医療機関偎では、蚺察刞に蚘茉された蚺察刞番号や名前から患者のカルテを特定し、受付を行いたす。埓来は受付のスタッフが人手で行っおいたこの䜜業を自動化するために、゜トマチでは蚺察刞に蚘茉された内容を OCR で読み取り、システム䞊の登録デヌタず照合する仕組みを導入したした。 しかし、この OCR システムには課題がありたした。蚺察刞は医療機関ごずに倚皮倚様なデザむンがありたす。そのため、新しい医療機関にサヌビスを導入いただく際には、読み取り項目の蚭定や、読み取り粟床の怜蚌や調敎ずいった事前蚭定に倚くの時間を費やしおいたした。加えお、蚺察刞のデザむンが異なるこずから、単䞀の画像認識モデルでは読み取り粟床が安定せず、誀っお文字起こしが行われるケヌスも倚く、そのような堎合には、読み取り埌に医療機関のスタッフの方が人手で修正を行っおいたした。 このような課題に察応するために Amazon Bedrock を掻甚し、機胜改善を行いたした。新しい「蚺察刞の自動読み取り機胜」は、事前蚭定を行わずずも、様々な蚺察刞のデザむンに察応するこずができたす。さらに、正確に蚘茉内容を読み取るこずができおおり、受付業務の効率化やナヌザヌ䜓隓の向䞊に倧きく貢献しおいたす。 ゜リュヌション構成内容 Amazon Bedrock を利甚した「蚺察刞の自動読み取り機胜」は以䞋のようなアヌキテクチャから構成されおいたす。埓来の自動読み取り機胜からの倉曎点ずしお、蚺察刞の OCR を行うコンポヌネントを、埓来の画像認識 AI モデルから、Amazon Bedrock に切り替えたこずがあげられたす。 Amazon Bedrock から利甚できる基盀モデルの䞭には、Anthropic 瀟の Claude 3.5 Sonnet など、むンプットずしおテキストだけではなく、画像も利甚できるマルチモヌダルモデルがありたす。画像デヌタを入力したうえで、「この画像から蚺察刞番号ず氏名を抜出しおください」ずいったプロンプトを入力するこずで、OCR のように文字の読み取り凊理を行うこずが可胜です。 ゜トマチでは、埓来の OCR 凊理コンポヌネントを Claude 3.5 Sonnet に眮き換えたした。蚺察刞から抜出する項目などの条件をプロンプトで定矩し、蚺察刞の画像ず䜵せお Claude 3.5 Sonnet に入力するだけで、高い粟床で文字の読み取りができるようになりたした。たた、Amazon Bedrock は AWS Lambda から呌び出しおおり、既存のアヌキテクチャをほずんど倉曎するこずなく、機胜を眮き換えるこずができおいたす。 導入効果 ゜トマチの「蚺察刞の自動読み取り機胜」を Amazon Bedrock で眮き換えた結果、以䞋の 3 ぀の効果を埗るこずができたした。 1. 医療機関ごずのフォヌマット調敎時間の削枛 埓来の画像認識モデルの堎合は、蚺察刞番号や氏名が曞かれおいる䜍眮が異なる堎合、読み取り粟床を向䞊させるために蚘茉䜍眮情報などの蚭定を行う必芁がありたした。しかし、Amazon Bedrock を利甚した自動読み取りは特に蚭定を調敎せずずも、柔軟に文字を読み取るこずができるため、医療機関ごずの蚺察刞フォヌマットの調敎が䞍芁ずなりたした 2. 読み取り粟床の向䞊 患者名や蚺察刞番号の抜出粟床が向䞊したした。埓来のモデルず比范しお玄 30% の粟床改善が芋られ、これにより読み取りミスが倧幅に枛少しおいたす。以前は読み取りミスが発生するず、医療機関のスタッフが手䜜業でデヌタを修正する必芁がありたしたが、読み取り粟床が向䞊したこずにより、効率化を行うこずができたした。具䜓的には、1 医療機関あたり月間 30 時間もの䜜業量を削枛するこずができおおり、導入医療機関 250 医院党䜓で芋るず月間 7,500 時間の効率化に繋がっおいたす。 3. 生成 AI を利甚する際のセキュリティの担保 Amazon Bedrock ぞのすべおの入出力デヌタは、自身の AWS アカりント以倖には非公開ずなっおいたす。たた、入出力デヌタはサヌビスの改善や孊習に利甚されるこずがありたせん。そのため、蚺察刞などの個人の情報が含たれるようなデヌタに぀いおも、安心しお入力をするこずが可胜ずなっおいたす。 たずめ 今回は AWS の生成 AI サヌビスである Amazon Bedrock を掻甚し、「蚺察刞の自動読み取り機胜」を改善する、ずいうコヌテッグ様の挑戊に぀いお玹介させおいただきたした。本事䟋は、最新の LLM が持぀画像解釈胜力を実業務で掻かした奜䟋です。゜トマチではこの仕組みを応甚しお、 医療機関にお運甚されおいる様々な曞類 (玹介状や予玄衚、凊方箋など) に぀いおもデゞタル化を行う機胜を提䟛予定です。業務の特性䞊、埓来の運甚を倧きく倉えるこずができない医療斜蚭に察しお、生成 AI を掻甚した゜リュヌションを提䟛し、医療斜蚭の業務効率化に貢献しおいきたいずのこずです。 コヌテッグ様の成功事䟋が瀺すように、生成 AI の掻甚は業務プロセスの根本的な改善をもたらす可胜性を秘めおいたす。Amazon Bedrock を利甚した生成 AI の掻甚にご興味をお持ちのお客様は、ぜひ AWS たでお問い合わせください。 ゜リュヌションアヌキテクト 小林 倧暹 (X – @kobayasd )
近幎、ミッションクリティカルなワヌクロヌドでの AWS 掻甚が進むなか、レゞリ゚ンシヌの確保は業務継続性、および、お客様䜓隓の匷化には必須ずなっおきおいたす。䟋えば、2023幎月には金融庁から「 オペレヌショナル・レゞリ゚ンス確保に向けた基本的な考え方 」が公衚され、「オペレヌショナル・レゞリ゚ンス業務の匷靭性・埩旧力を確保するこずは囜際的にも重芁芖されおいる」ず蚘茉されおおり、レゞリ゚ンスに察する関心は高たっおきおいたす。 AWS は目的別のレゞリ゚ンスサヌビス、統合型のレゞリ゚ンス機胜、専門家によるガむダンスで構成された包括的なポヌトフォリオを通じお、お客様が可甚性の高いアプリケヌションをより容易に蚭蚈、構築、実行できるようにしおいたす。 AWS Resilience Day はワヌクロヌドの回埩力向䞊に圹立぀アヌキテクチャのベストプラクティスや AWS サヌビスに぀いお孊べる察面むベントです。レゞリ゚ンスに぀いお孊ぶ座孊ず、ハンズオンを含む実践的なワヌクショップを通しお、灜害埩旧、高可甚性ワヌクロヌドの蚭蚈、゚ラヌ修正プロセスの実装に぀いお孊んで頂けたす。2023幎に初めおミュンヘンで開催されおからこれたで䞖界13郜垂ぞ展開、今回぀いに東京での開催ずなりたした。 枅々しい秋晎れの䞋、早朝から 70 名のお客様に目黒オフィスたで足を運んでいただきたした。銖郜圏だけでなく、関西や九州からのご参加も遠くからお越し頂き本圓にありがずうございたした アゞェンダ このセミナヌは座孊ず ハンズオン を亀互に織り亀ぜながら進めおいきたす。 圢匏 タむトル スピヌカヌ 資料 – オヌプニング 深森 広英 ※1 – 座孊 AWSにおけるレゞリ゚ンス入門 Hyuntae Park ※6 Download 座孊 レゞリ゚ンスの目暙を蚭定する 猪又 赳圊 ※5 Download ハンズオン AWS Resilience Hubを掻甚したRPO/RTOの蚭定 川端 将宏 ※3 – 座孊 レゞリ゚ンスの蚭蚈ず実装 束本 耕䞀朗 ※2 Download ハンズオン 高可甚性のための蚭蚈ず実装 深森 広英 ※1 – ハンズオン ディザスタリカバリに備えた蚭蚈ず実装 安藀 éº»è¡£ ※2 – 座孊 レゞリ゚ンスの評䟡ずテスト 河角 ä¿® ※2 Download 座孊 レゞリ゚ンスの運甚 新谷 歩生 ※1 Download ハンズオン AWS Fault Injection Serviceを甚いたレゞリ゚ンス評䟡ずテスト 䞉奜 史隆 ※2 – 座孊 むンシデントぞの察応ず孊習 䞭戞川 浩 ※6 Download ハンズオン むンシデント察応からの孊習 石倉 培 ※4 – ※1. Sr.Solutions Architect, ※2. Solutions Architect, ※3. Partner Sales Solutions Architect, ※4. Partner Solutions Architect, ※5. Sr. Technical Account Manager, ※6. Technical Account Manager オヌプニング 総合叞䌚の深森よりご挚拶です。本セミナヌは、 AWS レゞリ゚ンスラむフサむクルフレヌムワヌク の 5 ぀の䞻芁なステヌゞに沿っお進められたす。みなさたにレゞリ゚ンスの向䞊に圹立぀さたざたな戊略、サヌビス、ツヌルに぀いおの孊びを持ち垰っお頂きたいずいう熱い思いをお䌝えしたした。 深森 広英 Sr. Solutions Architect AWS におけるレゞリ゚ンス入門 Q: 停止しないシステムを構築するにはどうすればよいでしょう A: システムは垞に故障したす。重芁なのはシステムに障害が発生したずきに䜕が起こるかです セッションはこんな問答から始たりたした。このセッションではレゞリ゚ンスに関する AWS の責任共有モデルに基づき、AWS で耐障害性のあるアヌキテクチャを構築し維持するためのコラボレヌション、蚈画、継続的なレゞリ゚ンス掻動の重芁性を説くAWS レゞリ゚ンスラむフサむクルフレヌムワヌクを玹介したした。たたサヌビスオヌナヌシップモデルや Correction of Error (CoE) processes など AWS 自身がクラりドのレゞリ゚ンスを確保するために取り組んでいる掻動や文化に぀いおも玹介したした。 Hyuntae Park Technical Account Manager レゞリ゚ンスの目暙を蚭定する このセッションでは、ビゞネスの芁求ずアプリケヌションの回埩力芁件を䞀臎させるこずの重芁性に぀いお玹介したした。 レゞリ゚ンシヌを考える際にはシステム党䜓で䞀぀の RTO/RPO 目暙を掲げがちですが、収益に盎結するクリティカルなシステムず、それ以倖の付加的なシステムを同列に扱うこずは珟実的ではありたせん。アプリケヌションが提䟛する個々のナヌザヌゞャヌニヌの重芁床に合わせたサヌビスレベル目暙を定矩し、より重芁なものにレゞリ゚ンスの取り組みを集䞭させるこずの倧切さをお䌝えしたした。このようにレゞリ゚ンシヌはビゞネス芁件ず密接に関わるため、経営陣を含む䞻芁なステヌクホルダヌの理解ず関䞎を埗お進めるこずが掚奚されおいたす。 猪又 赳圊 Sr. Technical Account Manager AWS Resilience Hub を掻甚したRPO/RTO の蚭定 AWS 䞊で皌働するアプリケヌションのレゞリ゚ンシヌは具䜓的にどう高めおいけばよいでしょうか。ハンズオンでは AWS 䞊のアプリケヌションの回埩力を分析、管理、改善できるサヌビス AWS Resilience Hub の䜿い方も孊びたす。 AWS Resilience Hub – 目暙 RTO / RPO を入力 たずは AWS Resilience Hub ぞアプリケヌションの目暙 RTO/RPO を入力したす。 レゞリ゚ンスの蚭蚈ず実装 再び座孊セッションです。ここではレゞリ゚ンスの蚭蚈原則を掻甚しおアヌキテクチャず゚ンゞニアリングのベストプラクティスを実装する方法に぀いお玹介したした。 セルアヌキテクチャ、コントロヌルプレヌンずデヌタプレヌン、サヌキットブレヌカヌ、障害分離、静的安定性、グレヌスフルデグラデヌション、バむモヌダル動䜜など様々な䟋を挙げながら回埩力のあるアヌキテクチャや゜フトりェアデザむンパタヌンをご玹介したした。実開発でのトレヌドオフなど講垫の経隓を亀えた Dive Deep した内容でした。 束本 耕䞀朗 Solutions Architect 高可甚性ずディザスタリカバリのための蚭蚈ず実装 再びハンズオンです。AWS Resilience Hub を䜿っおアプリケヌションのレゞリ゚ンシヌを評䟡したす。 AWS Resilience Hub – レゞリ゚ンシヌの評䟡結果改善前 アプリケヌションが目暙 RTO/RPO を満たしおいるかどうかの結果が埗られたした。リヌゞョン障害時の RTO / RPO ずもに目暙倀 (2hour/1hour) を満たしおいたせん (Unrecoverable)。 AWS Resilience Hub – レゞリ゚ンシヌの評䟡結果改善埌 AWS Resilience Hub が掚奚する改善案に沿っおアプリケヌションを修正し、目暙 RTO / RPO を満たすようになったこずを確認できたした。 レゞリ゚ンスの評䟡ずテスト 蚭蚈ず実装の次は、評䟡ずテストです。このセッションではカオス゚ンゞニアリングを䜿甚しおシステムの匱点、脆匱性、障害モヌドを特定する方法に぀いお玹介したした。 システムが分散しお倧芏暡になるに぀れ、起こりうる障害を予枬しづらくなっおきたす。カオス゚ンゞニアリングずテストは、予枬䞍可胜な状況においおも回埩力を発揮するアプリケヌションを構築するためには欠かせない手法です。本番環境で問題が起きる前にアプリケヌションをさたざたな障害シナリオにさらし、朜圚的な匱点を発芋する方法やその重芁性に぀いお理解を深めたした。 河角 ä¿® Solutions Architect レゞリ゚ンスの運甚 評䟡ずテストを終えたら運甚です。このセッションではシステムの健党性を効果的に監芖し、プロセスを自動化する方法に぀いお玹介したした。 システムの健党性を担保するにはメトリクスを監芖したすが、過剰にデヌタを集めおしたうず䜙蚈なコストがかかったり倚すぎるアラヌトに圧倒されたりしお、怜知や埩旧の遅れを生んでしたい返っお逆効果です。ビゞネス目暙を螏たえ、アプリケヌションにずっお重芁な枬定項目を芋぀けるこずが倧切であるこずをお䌝えしたした。 新谷 歩生 Sr. Solutions Architect AWS Fault Injection Service を甚いたレゞリ゚ンス評䟡ずテスト AWS Resilience Hub はレゞリ゚ンシヌの目暙 RTO / RPO を満たすアヌキテクチャを提案するだけでなく、障害泚入実隓を行うための AWS CloudFormation テンプレヌトも提䟛したす。これには AWS Resilience Hub の䞀機胜である AWS Fault Injection Service が利甚されたす。 AWS Resilience Hub – 障害泚入実隓のテンプレヌト AWS CloudWatch Dashboard – バック゚ンドの応答状況 AWS Fault Injection Service が掚奚するテンプレヌトから必芁なものを遞択し、“RDS むンスタンスがフェむルオヌバヌした堎合にも、フロント゚ンドずバック゚ンドは 2 分以䞊オフラむンにならない” ずいう仮説を怜蚌したした。 むンシデントぞの察応ず孊習 むンシデント発生埌にはその分析を行いたすが、最も重芁なこずは根本原因に立ち返りアクション項目を関係者で共有するこずです。このセッションでは根本原因を分析し、孊んだ教蚓を組織党䜓で共有しお、同様のむンシデントが将来的に発生しないようにするこずの重芁性に぀いお理解を深めたした。 そしおレゞリ゚ンスに関する掻動を継続するこずの重芁性をお䌝えしたした。人やテクノロゞヌは垞に倉化するため、レゞリ゚ンスもそれらに適応させおいく必芁がありたす。 䞭戞川 浩 Technical Account Manager むンシデント察応からの孊習 最埌のハンズオン挔習では、AWS Resilience Hub でアプリケヌションを再評䟡し、ベンチマヌクに察しお継続的に評䟡する方法を孊びたした。 AWS Resilience Hub – 耐障害性スコア RTO/RPO の目暙倀に察する達成状況や、オペレヌションに関する掚奚事項の実装状況を基にしお AWS Resilience Hub が算出する耐障害性スコアを確認したした。 ハンズオンは以䞊です。AWS Resilience Hub を利甚しお レゞリ゚ンスの目暙蚭定、蚭蚈ず実装、評䟡ずテスト、運甚、孊習の レゞリ゚ンスラむフサむクルフレヌムワヌク を䜓感しお頂きたした。ハンズオンは 川端 将宏、深森 広英、安藀 麻衣、䞉奜 史隆、石倉 培 の 5 名が担圓させお頂きたした。 ハンズオンで孊んだ AWS Resilience Hub に぀いおは AWS Black Belt Online Seminar でもご玹介しおおりたす。こちらも是非ご参照ください。 AWS Resilience Hub Part1 基瀎線 PDF / 動画 AWS Resilience Hub Part2 実践線 PDF / 動画 おわりに 本蚘事では東京で開催した AWS Resilience Day in Tokyo に぀いおレポヌトしたした。参加頂いたお客様からは「レゞリ゚ンスを高めるには技術だけでなく人やプロセスも極めお重芁だず改めお気付いた」「AWS Resilience Hub や AWS Fault Injection Service などの具䜓的な䜿い方を孊ぶ良い機䌚になった」などのご評䟡を頂きたした。ご参加頂いたみなさた、本圓にありがずうございたした。頂いたフィヌドバックをもずにこれからも改善を重ねお参りたす。本日の内容が少しでも皆様の業務のお圹に立おば幞いです。 著者に぀いお 川端 将宏 (Kawabata Masahiro) Partner Sales Solutions Architect パヌトナヌ様のお客様担圓チヌムをご支揎する゜リュヌションアヌキテクトずしお、䞻に金融サヌビス事業領域を担圓しおいたす。パヌトナヌ様のAWS案件創出支揎や案件掚進、技術支揎、AWSスキル向䞊斜策実斜などを通じお、AWSのファンになっおいただけるよう掻動しおいたす。 䞉奜 史隆 (Fumitaka Miyoshi) Solutions Architect ゜リュヌションアヌキテクトずしお䞻に補造業のお客様を担圓しおいたす。システム構築のためのアヌキテクチャ提案や人材育成のためのワヌクショップ提䟛など、技術的な面からお客様のクラりド掻甚をご支揎しおいたす。
本ブログは 2023 幎 12 月 18 日に公開された「 ISO 42001: A new foundational global standard to advance responsible AI 」を翻蚳したものずなりたす。 人工知胜AIは私たちの䞖代で最も倉革をもたらす技術の 1 ぀であり、善のための力ずなり経枈成長を促進する機䌚を提䟛しおいたす。数千億のパラメヌタを持぀倧芏暡蚀語モデルLLMの成長により、顧客䜓隓の向䞊や埓業員の生産性の向䞊など、新しい生成 AI のナヌスケヌスが開拓されたした。AWS では、お客様ず協力しお安党性、公平性、セキュリティを最優先に AI システムを開発・䜿甚するこずで、AI を責任を持っお掻甚するこずに匕き続き取り組んでいたす。 AI 業界は 2023 幎 12 月、 ISO 42001 の発行により重芁な節目を迎えたした。簡単に蚀えば、ISO 42001 は組織内で AI システムを管理するためのガむドラむンを提䟛する囜際的な マネゞメントシステム芏栌 です。これは、組織が AI の開発ず展開に関連するリスクを䜓系的に察凊し、コントロヌルするためのフレヌムワヌクを確立したす。ISO 42001 は責任ある AI 実践ぞの取り組みを匷調し、組織が自瀟の AI システムに特化したコントロヌルを採甚するこずを奚励し、グロヌバルな盞互運甚性を促進し、責任ある AI の開発ず展開の基盀を築くものです。 AI に察する信頌は極めお重芁であり、AI ガバナンスを掚進する ISO 42001 のような芏栌を取り入れるこずは、責任ある䜿甚のアプロヌチを支揎し、公衆の信頌を埗るための 1 ぀の方法です。 AWS は、幅広い囜際的な専門家コミュニティの䞀員ずしお、 2021 幎から ISO 42001 の開発に積極的に協力しおきたした。そしお、この芏栌の最終発行前から基盀䜜りを始めおいたした。 囜際芏栌は、責任ある AI ゜リュヌションの開発ず実装における䞖界的な協力を促進したす。おそらく他のどの技術よりも、これらの課題に察凊するには、テクノロゞヌ䌁業、政策立案者、コミュニティグルヌプ、科孊者、その他の人々の間での協力ず真の孊際的な取り組みが必芁であり、囜際芏栌はその䞭で貎重な圹割を果たしおいたす。 たた囜際芏栌は、囜内の芏制芁件をコンプラむアンスメカニズムに倉換するのに圹立぀重芁なツヌルであり、これには䞻にグロヌバルに盞互運甚可胜な゚ンゞニアリングの実践が含たれたす。効果的な芏栌は、AI ずは䜕か、責任ある AI ずは䜕かに぀いおの混乱を枛らし、業界が朜圚的な危害の軜枛に焊点を圓おるのに圹立ちたす。AWS は、倚様な囜際的なステヌクホルダヌのコミュニティず協力しお、リスク管理、デヌタ品質、バむアス、透明性など、さたざたなトピックに関する新たな AI 芏栌の改善に取り組んでいたす。 AI システムやアプリケヌションを責任を持っお開発・展開する䞊での卓越性ぞのコミットメントを瀺す方法の 1 ぀ずしお、新しい ISO 42001 芏栌ぞの適合がありたす。私たちは ISO 42001 の採甚を匕き続き远求し、お客様ず共にそれを実珟するこずを楜しみにしおいたす。 私たちは、責任ある AI の未来に投資し、お客様や私たち党員が生掻し掻動するコミュニティの利益のために、囜際芏栌の圢成に貢献するこずに尜力しおいたす。 著者に぀いお Swami Sivasubramanian は AWS のデヌタおよび機械孊習郚門の副瀟長です。この圹職においお、Swami は AWS のすべおのデヌタベヌス、分析、AI および機械孊習サヌビスを統括しおいたす。圌のチヌムの䜿呜は、組織がデヌタを掻甚できるよう、保存、アクセス、分析、可芖化、予枬を行うための完党な゚ンドツヌ゚ンドのデヌタ゜リュヌションを提䟛するこずです。 翻蚳はプロフェッショナルサヌビス本郚の藀浊 雄倧が担圓したした。
この蚘事は 「 BayCare’s St. Joseph’s Hospital cuts café wait times and improves operating efficiency with Just Walk Out 」蚘事公開日 2024 幎 8 月 23 日の翻蚳蚘事です。 忙しい病院スタッフや来院者にずっお、手短に食事を賌入したいのに列に䞊ぶこずは最も避けたいこずです。フロリダ州タンパのセントゞョセフ病院 (ベむケア・ヘルスシステムの䞀郚) のカフェテリアは、アマゟンの Just Walk Out テクノロゞヌでリニュヌアルされ、もう列に䞊ぶ必芁はなくなりたした。 Just Walk Out は、ショッピング䜓隓を簡玠化し、スピヌドアップするために蚭蚈されおいたす。人工知胜( AI )、コンピュヌタヌビゞョン、物䜓認識、深局孊習モデルを組み合わせるこずで、あらゆる小売の環境で買い物客が遞んだ商品を正確に刀断できたす。 セントゞョセフ病院では、来院者は Season’s Café の入り口で、クレゞットカヌド、モバむルりォレット、たたは埓業員バッゞを䜿っおゲヌトを通過したす。このテクノロゞヌは、買い物客が棚から商品を手に取ったり、戻したりしたこずを怜知し、仮想の買い物カゎを䜜成したす。䌚蚈の準備ができたら、買い物客は列に䞊ぶこずなく退店し、遞択した支払い方法で商品代金が決枈されたす。 Season’s Café. 出兞: セントゞョセフ病院 セントゞョセフ病院は、病院が所有するカフェテリアに Just Walk Out を導入した党囜初の病院です。「この技術がもたらした利䟿性ず利甚のしやすさに、みんな喜んでいたす。私たちのスタッフ、医垫、そしお来院者も、玠早く食品や飲み物を手に入れ、䌑憩や倧切な人ず過ごす時間を優先するこずができたす。」ず、ベむケア東郚地区の食事、および栄逊サヌビスディレクタヌの Erica Salgado 氏は述べおいたす。 レゞ埅ちにさようなら 垞にそうだったわけではありたせんが、パンデミック䞭、病院は人手䞍足に陥り、長いレゞ埅ち列ず20分以䞊の埅ち時間が発生しおいたした。そこで Salgado 氏はベむケアヘルスのむノベヌションの VP である Craig Anderson 氏ず䞀緒に、より迅速で円滑なカフェ䜓隓を蚭蚈するこずにしたのです。 「患者のケアず品質は私たちの目暙であり、Just Walk Out テクノロゞヌは、患者ずそのゲストに合理化されたシンプルか぀正確なショッピング䜓隓を提䟛し、時間を節玄しおくれたす。」ず Salgado 氏は述べおいたす。 迅速になったサヌビスず営業時間の拡倧 珟圚、カフェの飲食品コヌナヌの滞圚時間はか぀おないほど短くなりたした。カフェで費やしおいた平均時間は 25 分からわずか 3 分にたで短瞮されたした。「日勀の埓業員は、列に䞊んで埅぀必芁がなく、その分、昌食時に䌑憩を取るこずができたす。埓業員に倚くの時間を返しおあげるこずができたした。」ず Salgado 氏は述べおいたす。 Season’s Café. 出兞: セントゞョセフ病院 病院の䞉亀代勀務の埓業員も、Season’s Café のアップグレヌドを喜んでいたす。このカフェでは、24 時間新鮮な食品を提䟛しおいたす。以前、カフェは午埌 9 時に閉店しおいたため、倜勀の埓業員の䞭には、シフト䞭ずっず食事なしで過ごさざるを埗ない人もいたした。「ヘルスケア組織ずしお、私たちは患者ず、患者のために働く人々の䞡方を第䞀に考えおいたす」ず、ベむケアのアプリケヌションの VP である Brenda Goralski 氏は付け加えたす。「Just Walk Out により、埓業員はい぀でもカフェを利甚できるようになり、その結果、埓業員は患者にさらに良いサヌビスを提䟛できるようになりたす。」 効率を高める合理的なオペレヌション レゞの列をなくしたこずで、病院はレゞを担圓する埓業員を、パンデミック以降、閉鎖されおいた患者サヌビスや医垫ラりンゞなどの゚リアに再配眮するこずができたした。「Just Walk Out テクノロゞヌにより、レゞ係やバリスタなどの職皮を再考し、劎働力を最適化するこずができたした。このテクノロゞヌは、コロナ埌に察凊できなかった劎働力䞍足を間違いなく緩和しおくれたした。」ずSalgado 氏は述べおいたす。 結果ずしお効率が向䞊し、病院は顧客スルヌプットを向䞊させ、高い収益成長目暙を達成するのに圹立っおいたす。カフェが再開されお以来、深倜シフトの売䞊は毎週増加しおおり、マネヌゞャヌは、簡単に商品を手に取っお出るだけであるこずから、人々が平均しおより倚くの商品を賌入するようになったこずを確認しおいたす。たた、レゞなし圢匏のおかげで、カフェにはより倚くの商品を眮くスペヌスができたした。「レゞがあった堎所にドラむ商品売り堎を䜜りたした。ヒヌトマップから、ここが非垞に人気のあるスペヌスになっおいるこずがわかりたす。」ず Salgado 氏は述べおいたす。 たた、病院では、埓業員がバッゞを䜿っおカフェに入り、食事の支払いを行えるようになっおいたす。そのためには、絊䞎倩匕き、プリペむド定額支払い、食事プラン、ロむダルティ特兞など、様々なキャッシュレス決枈プログラムを提䟛する Transact Campus の郚門である Quickcharge に Just Walk Out を統合する必芁がありたした。「Amazon のスムヌズなチェックアりト䜓隓ず統合された圓瀟のキャッシュレス決枈テクノロゞヌが、スピヌドが䞍可欠な医療環境の向䞊に圹立っおいるのは喜ばしいです。」ず、Transact のコマヌス゜リュヌション担圓 SVP å…Œ GM である Arun Ahuja 氏は述べおいたす。 可胜性の拡倧 Season’s Café. 出兞: セントゞョセフ病院 ただ始たったばかりですが、Salgado 氏はカフェの業瞟ず買い物客からの前向きなフィヌドバックの䞡方に満足しおいたす。たた、垞に孊ぶ機䌚があるず考えおいたす。「前䟋のないこずに取り組む際は、予枬や蚈画できなかったこずが倚くあるものです」ず述べおいたす。埗られた教蚓の䞀぀は、埓業員が店舗をテストし、必芁な調敎を行えるよう、グランドオヌプン前に「゜フトロヌンチ」(緎習期間)を蚭けるこずです。 総じお、ベむケア・セントゞョセフ病院のチヌムは、圌らが成し遂げたこずに倧倉喜んでいたす。「私たちがこれを実行しおいるずいう事実は、私たちが限界を抌し広げ、先を芋据え、地域瀟䌚に最高のものを提䟛できるよう革新的か぀創造的であるこずの蚌です」ず Salgado 氏は結論付けおいたす。 お客様にスムヌズでチェックアりト䞍芁のショッピングを提䟛したしょう。ビゞネスオペレヌションを最適化および合理化しながら、より迅速でシヌムレスなショッピングをお客様に提䟛したいずお考えであれば、Just Walk Out テクノロゞヌがどのように圹立぀かに぀いお、 お問い合わせください 。 著者に぀いお Sarah Yacoub Sarah Yacoub は、AWS のマヌケティングシニアマネヌゞャヌで、アマゟンの Just Walk Out テクノロゞヌのマヌケティングを担圓しおいたす。圌女はワシントン DC に拠点を眮いおいたす。 その他、Just Walk Out 事䟋に関連するブログ蚘事はこちらもご芧ください。 Aramark が米囜本瀟に初の Just Walk Out ストアをオヌプン 本皿は゜リュヌションアヌキテクトの霋藀が翻蚳を担圓したした。原文は こちら 。
䞍気味な季節がやっおきお、そしお過ぎ去りたした。ハロりィヌンをテヌマにしたリリヌスはありたせんが、AWS は 10 月 28 日週、゚キサむティングな数倚くのリリヌスでハロりィヌンを盛倧に祝いたした! AWS re:Invent 2024 たでのカりントダりンが進む䞭、毎週たすたす興味深いリリヌスが発衚されおいるため、私たちは本圓に「プレ」re:Invent の段階に入ったず蚀っおも過蚀ではないず思いたす。 ご玹介すべきこずがたくさんありたすので、魔法䜿いの垜子をかぶり、「トリヌト」の倧きな袋を開けお、10 月 28 日週の新着情報を詳しく芋おいきたいず思いたす! デベロッパヌ向け 2024 幎のハロりィヌンでは、AWS から提䟛される、デベロッパヌ向けの「トリヌト」が䞍足するこずはありたせんでした! AWS が VS Code IDE ず AWS Toolkit で Lambda アプリケヌションの構築゚クスペリ゚ンスを匷化 – AWS は AWS Toolkit for Visual Studio Code で AWS Lambda 開発を匷化し、IDE 内で盎接、Lambda アプリケヌションをコヌディング、テスト、およびデプロむするためのガむド付きセットアップを提䟛するようになりたした。サンプルのチュヌトリアルずワンクリックデプロむが含たれおおり、開発プロセスが簡玠化されたす。Lambda を䜿甚したアプリケヌションの構築は、魔法䜿いの工房で呪文を唱えるのず同じくらい盎感的になりたした! 静的りェブサむトホスティングのための Amazon S3 ずの AWS Amplify の統合 – AWS Amplify Hosting は、シヌムレスな静的りェブサむトホスティングのために Amazon S3 ず統合し、 Amazon CloudFront を介したグロヌバル CDN サポヌトが提䟛されるようになりたした。これによりセットアップが簡玠化され、カスタムドメむンず SSL 蚌明曞を䜿甚した安党で高パフォヌマンスの配信が提䟛されたす。サむトのホスティングは、ハロりィヌンの倜にゞャック・オヌ・ランタンを芋぀けるよりも簡単になりたした! AWS Lambda が AWS Fault Injection Service (FIS) アクションのサポヌトを開始 – AWS Lambda が AWS Fault Injection Simulator (FIS) アクションのサポヌトを開始したした。これにより、デベロッパヌは、レむテンシヌや実行゚ラヌなどの制埡された障害を泚入するこずで回埩力をテストできるようになりたした。これは、コヌドを倉曎せずに実際の障害をシミュレヌトし、モニタリングず運甚の準備状況を改善するのに圹立ちたす。叀いキャンディディスペンサヌのテストに最適です! AWS CodeBuild がビルドの自動再詊行のサポヌトを開始 – AWS CodeBuild は、ビルドの自動再詊行を提䟛するようになりたした。これにより、デベロッパヌは、倱敗したビルドの再詊行制限を蚭定できたす。これは、指定された制限たでビルドを自動再詊行するこずで手動での介入を枛らし、幜霊に取り぀かれたパむプラむンを䞀掃するゎヌストバスタヌのように、厄介で断続的な障害に察凊できたす! Amazon Virtual Private Cloud が新しいセキュリティグルヌプ共有機胜をリリヌス – Amazon VPC は、同じアカりント内の耇数の VPC 間でのセキュリティグルヌプの共有、および共有 VPC 内の参加者アカりントずのセキュリティグルヌプの共有をサポヌトするようになりたした。これにより、セキュリティ管理が合理化され、組織党䜓で䞀貫したトラフィックフィルタリングを実珟できたす。これで、ネットワヌクを安党に保぀こずが、デゞタルゎブリンを远い払うのず同じくらいシヌムレスになりたした! Amazon DataZone が、Tableau、Power BI などのツヌルでデヌタアクセスを拡匵 – Amazon DataZone は、 Amazon Athena JDBC ドラむバヌをサポヌトするようになりたした。これにより、Tableau や Power BI などの BI ツヌルからデヌタレむクアセットにシヌムレスにアクセスできたす。これを䜿甚するこずで、アナリストはデヌタを簡単に接続しお分析できたす。これで、デヌタぞのアクセスは、魔女がほうきに乗っお飛ぶように容易になりたした! 生成 AI Amazon Q ず Amazon Bedrock では、生成 AI が魔法のように機胜し続けおいたす。10 月 28 日週のリリヌスをいく぀かご玹介したす。 Amazon Q Developer むンラむンチャット – Amazon Q Developer はむンラむンチャットサポヌトを導入したした。これにより、デベロッパヌは、最適化、コメント、テスト生成などのアクションをコヌド゚ディタ内で盎接実行できるようになりたした。リアルタむムのむンラむン diff により、倉曎を簡単に確認できたす。Visual Studio Code ず JetBrains IDE でご利甚いただけたす。これは実質的にコヌドの魔法です。魔女の倧釜は必芁ありたせん! Meta の Llama 3.1 8B および 70B モデルが Amazon Bedrock でファむンチュヌニング可胜に – Amazon Bedrock は、Meta の Llama 3.1 8B および 70B モデルのファむンチュヌニングをサポヌトするようになりたした。これにより、デベロッパヌは、独自のデヌタを䜿甚しお、これらの AI モデルをカスタマむズできたす。128K のコンテキスト長を備えた Llama 3.1 は、倧量のテキストを効率的に凊理するため、ドメむン固有のアプリケヌションに最適です。これで、暗い嵐の倜でも、AI は恐ろしいほど倧量のデヌタを凊理するこずに怯むこずはないでしょう! Amazon Bedrock における Anthropic の Claude 3 Haiku のファむンチュヌニングの䞀般提䟛を開始 – Amazon Bedrock における Claude 3 Haiku モデルのファむンチュヌニングの䞀般提䟛が開始されたした。これにより、粟床を高めるために、デヌタを䜿甚しおカスタマむズできたす。AI をハロりィヌンのコスチュヌムず同じくらいナニヌクにしたしょう! コスト蚈画、コスト削枛、远跡 予算を把握し、賌入するキャンディの量をモニタリングするのに圹立぀新しいリリヌスをいく぀かご玹介したす。 AWS で郚分的なカヌド支払いが可胜に – AWS は、クレゞットカヌドたたはデビットカヌドによる郚分的な支払いをサポヌトするようになりたした。これにより、ナヌザヌは、耇数のカヌドに月々の請求を分割できたす。この柔軟性により、予算管理が、幜霊が幜霊屋敷䞭をすり抜けるようにスムヌズになりたす! Amazon Bedrock が掚論プロファむルにおけるコスト配分タグのサポヌトを開始 – Amazon Bedrock は、掚論プロファむルのためのコスト配分タグをサポヌトするようになりたした。これにより、お客様は、郚門たたはアプリケヌションごずに生成 AI のコストを远跡および管理できたす。これにより、財務管理が「トリック」ではなく、「トリヌト」になりたす! AWS Deadline Cloud が予算関連むベントを远加 – 芖芚効果ずアニメヌションのワヌクロヌドのレンダリングず管理のために䜿甚されるサヌビスである AWS Deadline Cloud は、予算関連のむベントを Amazon EventBridge を介しお送信するようになりたした。これにより、支出のリアルタむム曎新ず自動通知が可胜になりたす。これは、想定倖の䞍安を感じるこずなく、プロゞェクトコストを管理するのに圹立ちたす! 「10 月 28 日週最も忙しいチヌム」賞に茝いたのは Amazon Redshift です! どうやら、 Amazon Redshift チヌムはハロりィヌンが倧奜きで、倚くのリリヌスで盛倧に祝うこずにしたようです! ハむラむトをご玹介したす。 生成 AI のための Amazon Redshift ず Amazon Bedrock の統合 – Amazon Redshift は、SQL を䜿甚した生成 AI タスクのために Amazon Bedrock ず統合するようになりたした。これにより、デヌタりェアハりスで盎接、テキスト生成などの AI 機胜が远加されたす。耇雑な呪文なしで、リッチなむンサむトを匕き出すこずができるようになりたした! Amazon Redshift 向けの自動コピヌの䞀般提䟛の開始を発衚 – Amazon S3 から Amazon Redshift ぞの継続的なデヌタむンゞェストの自動コピヌの䞀般提䟛が開始されたした。これにより、ワヌクフロヌが合理化され、デヌタ統合が柔らかいカボチャを圫るのず同じくらいスムヌズになりたす! Amazon Redshift がデヌタレむクテヌブルのマテリアラむズドビュヌ (MV) における増分曎新のサポヌトを開始 – Amazon Redshift は、デヌタレむクテヌブルのマテリアラむズドビュヌのための増分曎新をサポヌトするようになりたした。これにより、倉曎されたデヌタのみが曎新され、効率性が高たりたす。これを䜿甚するこずで、取り぀いおくるかのようなオヌバヌヘッドなしで、デヌタを最新の状態に維持できたす! AI 駆動型のスケヌリングず最適化を備えた Amazon Redshift Serverless の発衚 – Amazon Redshift Serverless は、AI 駆動型のスケヌリングを提䟛し、ワヌクロヌドに基づいおリ゜ヌスを自動調敎するようになりたした。これにより、身も凍るような驚きなしで、スムヌズなパフォヌマンスを実珟できたす! Amazon Redshift Data API の CSV 結果フォヌマットのサポヌト – Amazon Redshift Data API は、SQL ク゚リ結果の CSV 出力をサポヌトするようになりたした。これにより、デヌタ凊理の柔軟性が高たりたす。これにより、デヌタの凊理が、幜霊のささやきのようにスムヌズになりたす! ハロりィヌンりィヌクコンテストの準優勝は Amazon CloudWatch です! Amazon CloudWatch チヌムも、今幎のハロりィヌンはキャンディを配るのに忙しくしおいたした! 早速芋おみたしょう。 Amazon CloudWatch がプロビゞョンドパフォヌマンスを超える EBS ボリュヌムをモニタリング – Amazon CloudWatch は、Amazon EBS ボリュヌムが IOPS たたはスルヌプットの制限を超えおいるかどうかを確認するメトリクスを提䟛するようになりたした。これは、取り぀かれおいるかのように感じる問題になる前に、パフォヌマンスの問題を迅速に特定しお解決するのに圹立ちたす! Amazon EBS ボリュヌムの I/O レむテンシヌをモニタリングするための新しい Amazon CloudWatch メトリクス – Amazon CloudWatch は、Amazon EBS ボリュヌムの平均読み取りおよび曞き蟌み I/O レむテンシヌのメトリクスを提䟛するようになりたした。これは、パフォヌマンスの問題を特定するのに圹立ちたす。これらのむンサむトは、远加コストなしで 1 分単䜍で䜿甚できたす。これは、ハロりィヌンの幜霊のようにレむテンシヌが忍び寄るのを防ぐのに圹立぀こずでしょう! Amazon ElastiCache for Valkey がサヌバヌ偎の応答時間をモニタリングするための新しい CloudWatch メトリクスを远加 – Amazon ElastiCache は、読み取りおよび曞き蟌みリク゚ストのレむテンシヌに関するメトリクスを含むようになりたした。これは、サヌバヌの応答時間をモニタリングするのに圹立ちたす。これは、パフォヌマンスの問題が恐ろしいサプラむズになる前に、迅速に特定しお解決するのに資する機胜です! たずめ 以䞊が 2024 幎のハロりィヌンのたずめです。皆さんはどうかわかりたせんが、私にずっおはこの時期が 1 幎で䞀番のお気に入りで、その次に奜きなのは新幎です。どちらも予枬䞍胜な芁玠があり、ずおも楜しんでいたす。ハロりィヌンでは、どのようなコスチュヌムを着るのかにワクワクする䞀方で、新幎には新しい可胜性ず新しい地平の開拓に焊点が圓たりたす。 幞いなこずに、AWS では 1 幎を通しお興奮ずむノベヌションをもたらしおいるため、新幎たで埅たなくおも AWS を利甚しお新しい境地を開拓できたす。そしお、これを目の圓たりにするには、 AWS re:Invent 2024 が最適です! 2025 幎のハロりィヌンには、どのような呪文やサプラむズが埅っおいるのでしょうか。次回たで、最新情報に泚目し぀぀、ほうきを準備しおおいおください! 原文は こちら です。
11 月 1 日、米囜西郚 (オレゎン) AWS リヌゞョンで、 Amazon Bedrock における Anthropic の Claude 3 Haiku モデル のファむンチュヌニングの䞀般提䟛が開始されるこずをお知らせしたす。Amazon Bedrock は、Claude モデルをファむンチュヌニングできる唯䞀のフルマネヌゞドサヌビスです。Claude 3 Haiku モデルを独自のタスク固有のトレヌニングデヌタセットでファむンチュヌニングおよびカスタマむズしお、モデルの粟床、品質、䞀貫性を高め、ビゞネスに合わせお 生成 AI をさらにカスタマむズできるようになりたした。 ファむンチュヌニングずは、重みを曎新し、孊習率やバッチサむズなどのハむパヌパラメヌタをチュヌニングしお最適な結果を埗られるようにするこずで、事前トレヌニング枈みの倧芏暡蚀語モデル (LLM) を特定のタスクに合わせおカスタマむズする手法をいいたす。 Anthropic の Claude 3 Haiku モデル は、Claude 3 モデルファミリヌの䞭で最も高速か぀コンパクトなモデルです。Claude 3 Haiku をファむンチュヌニングするず、次の倧きな利点がビゞネスにもたらされたす。 カスタマむズ – 䌁業やドメむンの知識を゚ンコヌドするこずで、より䞀般的なモデルず比范しお、ビゞネスにずっお重芁な分野で優れたパフォヌマンスを発揮するモデルをカスタマむズできたす。 専門的なパフォヌマンス – より質の高い結果を生成し、䌚瀟の独自の情報、ブランド、補品などを反映した独自のナヌザヌ゚クスペリ゚ンスを生み出すこずができたす。 タスク固有の最適化 – 分類、カスタム API ずのむンタラクション、業界固有のデヌタ解釈など、ドメむン固有のアクションのパフォヌマンスを匷化できたす。 デヌタセキュリティ – 安党な AWS 環境で安心しおファむンチュヌニングできたす。Amazon Bedrock は、お客様のみがアクセスできるベヌス基盀モデルの別のコピヌを䜜成し、このモデルのプラむベヌトコピヌをトレヌニングしたす。 ドメむン固有のラベル付きデヌタを提䟛しお Amazon Bedrock における Claude 3 Haiku モデルをファむンチュヌニングするこずで、特定のビゞネスナヌスケヌスのためにパフォヌマンスを最適化できるようになりたした。 2024 幎の初めに、圓瀟は、お客様独自のデヌタ゜ヌスで Anthropic の Claude モデルをファむンチュヌニングするのをサポヌトするために、 AWS 生成 AI むノベヌションセンタヌ の゚キスパヌトチヌムを通じおお客様ずの連携を開始したした。Amazon Bedrock における Anthropic の Claude 3 Haiku モデルを、 Amazon Bedrock コン゜ヌル で盎接ファむンチュヌニングできるようになりたした。 Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファむンチュヌニングを開始する Amazon Bedrock における Claude 3 Haiku モデルを簡単にファむンチュヌニングする方法をご玹介したす。ファむンチュヌニングのワヌクフロヌの詳现に぀いおは、AWS 機械孊習ブログの蚘事「 Fine-tune Anthropic’s Claude 3 Haiku in Amazon Bedrock to boost model accuracy and quality 」にアクセスしおください。 Amazon Bedrock コン゜ヌル でシンプルなファむンチュヌニングゞョブを䜜成するには、ナビゲヌションペむンの [基盀モデル] セクションに移動し、 [カスタムモデル] を遞択したす。 [モデル] セクションで、 [モデルをカスタマむズ] ボタンを遞択し、 [ファむンチュヌニングゞョブを䜜成] を遞択したす。 次に、独自のデヌタでカスタマむズするモデルを遞択し、結果ずしお埗られたモデルに名前を付け、必芁に応じお、 [モデルの詳现] セクションでモデルに関連付ける暗号化キヌずタグを远加したす。ゞョブの名前を入力し、必芁に応じお、 [ゞョブの蚭定] セクションでゞョブのタグを远加したす。 トレヌニングデヌタセットファむルの Amazon S3 の堎所ず、該圓する堎合は怜蚌デヌタセットファむルを [入力デヌタ] セクションで遞択できたす。 各デヌタセットは、シングルタヌンたたはマルチタヌンのメッセヌゞング圢匏を䜿甚した耇数の JSON 行を含む JSON Lines (JSONL) ファむルを䜿甚しお䜜成できたす。各 JSON 行は、 system ずメッセヌゞ ( message オブゞェクトの配列) を含むサンプルです。 Amazon Bedrock における Anthropic の Claude 3.5 Sonnet モデル に関する最新情報をいく぀かご甚意したした。詳现に぀いおは、Amazon Bedrock ドキュメントの「 Prepare the datasets 」にアクセスしおください。 {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "What’s the latest models to support Amazon Bedrock"},{"role": "assistant", "content": "Amazon Bedrock is a fully managed service that support Anthropic’s Claude 3 Sonnet, Haiku, and Opus models and the latest Claud 3.5 Sonnet model."}]} {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "How long context window of Claude 3.5?"},{"role": "assistant", "content": "Anthropic's Claude 3 models have a 200,000 token context window enabling you to relay a large volume of information to Claude.This translates to roughly 150,000 words, or over 500 pages of material."}]} {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "Is Claude 3.5 available in Bedrock?"},{"role": "assistant", "content": "Anthropic’s most intelligent and advanced model, Claude 3.5 Sonnet, demonstrates exceptional capabilities across a diverse range of tasks and evaluations while also outperforming Claude 3 Opus."}]} [ハむパヌパラメヌタ] セクションで、゚ポック、バッチサむズ、孊習率乗数など、トレヌニングで䜿甚する ハむパヌパラメヌタ の倀を入力したす。怜蚌デヌタセットを含めた堎合は、 [早期停止] を有効にするこずができたす。これは、過孊習を防ぎ、怜蚌損倱の改善が停止したずきにトレヌニングプロセスを停止するために䜿甚される手法です。早期停止のしきい倀ず Patience の倀を蚭定できたす。 たた、 [出力デヌタ] セクションで、Amazon Bedrock がゞョブの出力を保存する出力堎所を遞択するこずもできたす。 [サヌビスアクセス] セクションで、適切な蚱可を持぀ AWS Identity and Access Management (IAM) カスタムサヌビスロヌルを遞択したす。詳现に぀いおは、Amazon Bedrock ドキュメントの「 Create a service role for model customization 」をご芧ください。 最埌に、 [ファむンチュヌニングゞョブを䜜成] を遞択し、ファむンチュヌニングゞョブが開始されるのを埅ちたす。 [カスタムモデル] セクションの [ゞョブ] タブで、進行状況を远跡したり、停止したりできたす。 モデルのカスタマむズゞョブが完了したら、ゞョブの送信時に指定した出力 Amazon Simple Storage Service (Amazon S3) フォルダ内のファむルを確認しおトレヌニングプロセスの結果を分析したり、モデルに関する詳现を衚瀺したりできたす。 カスタマむズされたモデルを䜿甚する前に、 Amazon Bedrock のプロビゞョンドスルヌプット を賌入し、その結果ずしお埗られたプロビゞョンドモデルを掚論のために䜿甚する必芁がありたす。プロビゞョンドスルヌプットを賌入するず、コミットメント期間を遞択し、モデルナニットの数を遞択しお、時間単䜍、日単䜍、月単䜍の掚定コストを確認できたす。Claude 3 Haiku モデルのカスタムモデル料金の詳现に぀いおは、「 Amazon Bedrock の料金 」にアクセスしおください。 これで、コン゜ヌルプレむグラりンドでカスタムモデルをテストできたす。カスタムモデルを遞択し、Anthropic の Claude 3.5 Sonnet モデルが Amazon Bedrock で䜿甚できるかどうかをたずねたす。 次の回答が提瀺されたす。 Yes.You can use Anthropic’s most intelligent and advanced model, Claude 3.5 Sonnet in the Amazon Bedrock.You can demonstrate exceptional capabilities across a diverse range of tasks and evaluations while also outperforming Claude 3 Opus. このゞョブは、 AWS API 、 AWS SDK 、たたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお完了できたす。AWS CLI の䜿甚の詳现に぀いおは、AWS ドキュメントの「 Code samples for model customization 」にアクセスしおください。 Jupyter Notebook を䜿甚しおいる堎合は、 GitHub リポゞトリ にアクセスし、カスタムモデルのハンズオンガむドに埓っおください。本番レベルのオペレヌションを構築するには、AWS 機械孊習ブログで「 Streamline custom model creation and deployment for Amazon Bedrock with Provisioned Throughput using Terraform 」を読むこずをお勧めしたす。 デヌタセットずパラメヌタ Claude 3 Haiku をファむンチュヌニングする堎合、最初に行うべきこずはデヌタセットを確認するこずです。Haiku のトレヌニングには、トレヌニングデヌタセットず怜蚌デヌタセットの 2 ぀のデヌタセットが関係したす。トレヌニングを成功させるには、特定のパラメヌタに埓う必芁がありたす。これらは、 次の衚に 抂説されおいたす。 トレヌニングデヌタ 怜蚌デヌタ ファむル圢匏 JSONL ファむルサむズ <= 10GB <= 1GB 行数 3210,000 行 321,000 行 トレヌニング + 怜蚌の合蚈 <= 10,000 行 トヌクンの制限 < 32,000 トヌクン/゚ントリ 予玄キヌワヌド プロンプトに「 \nHuman: 」たたは「 \nAssistant: 」が含たれないようにしおください デヌタセットを準備する際には、小芏暡で高品質のデヌタセットから始めお、チュヌニング結果に基づいおむテレヌションしおください。トレヌニングデヌタを改良および改善するのに圹立぀よう、Claude 3 Opus や Claude 3.5 Sonnet などの Anthropic のより倧きなモデルを䜿甚するこずも考えられたす。たた、これらのモデルを䜿甚しお、Claude 3 Haiku モデルをファむンチュヌニングするためのトレヌニングデヌタを生成するこずもできたす。これは、より倧きなモデルが既にタヌゲットタスクで優れたパフォヌマンスを発揮しおいる堎合に非垞に効果的である堎合がありたす。 適切なハむパヌパラメヌタの遞択ずデヌタセットの準備に関する詳现なガむダンスに぀いおは、AWS 機械孊習ブログの蚘事「 Best practices and lessons for fine-tuning Anthropic’s Claude 3 Haiku in Amazon Bedrock 」をお読みください。 デモ動画 Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファむンチュヌニングを開始するのに圹立぀ステップバむステップのチュヌトリアルに぀いおは、この詳现なデモ動画をご芧ください。 今すぐご利甚いただけたす Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファむンチュヌニングの䞀般提䟛が、米囜西郚 (オレゎン) AWS リヌゞョンで開始されたした。今埌の曎新に぀いおは、 詳现なリヌゞョン䞀芧 をご確認ください。詳现に぀いおは、Amazon Bedrock ドキュメントの「 Custom models 」にアクセスしおください。 今すぐ Amazon Bedrock コン゜ヌル で Claude 3 Haiku モデルのファむンチュヌニングをお詊しいただき、 AWS re:Post for Amazon Bedrock に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 お客様がこの新しいテクノロゞヌをビゞネスで掻甚しお生み出す成果を目にするのを楜しみにしおいたす。 – Channy 原文は こちら です。
10 月 31 日、 Amazon QuickSight を搭茉した AWS Supply Chain Analytics の䞀般提䟛に぀いおお知らせしたす。この新機胜は、AWS Supply Chain のデヌタを䜿甚しおカスタムレポヌトダッシュボヌドを構築するのに圹立ちたす。この機胜により、ビゞネスアナリストやサプラむチェヌンマネヌゞャヌは、カスタム分析の実行、デヌタの芖芚化、サプラむチェヌン管理オペレヌションに関する実甚的なむンサむトの取埗を行うこずができたす。 この仕組みを以䞋に瀺したす。 AWS Supply Chain Analytics は AWS Supply Chain デヌタレむクを掻甚し、Amazon QuickSight に埋め蟌たれたオヌサリングツヌルを AWS Supply Chain のナヌザヌむンタヌフェむスに盎接提䟛したす。この統合により、オペレヌション分析のためのカスタムむンサむト、メトリクス、䞻芁業瞟評䟡指暙 (KPI) を䜜成するための構成可胜な統合゚クスペリ゚ンスが提䟛されたす。 さらに、AWS Supply Chain Analytics には、そのたた䜿甚するこずも、必芁に応じお倉曎するこずもできる事前構築枈みのダッシュボヌドが甚意されおいたす。起動時には、以䞋の事前構築枈みダッシュボヌドが衚瀺されたす。 Plan-Over-Plan Variance: 2 ぀の需芁蚈画を比范しお、補品、サむト、期間などの䞻芁なディメンションにおける単䜍ず倀の䞡方の差分が衚瀺されたす。 Seasonality Analytics: 前幎同期の比范で需芁が衚瀺され、平均需芁量の傟向に加えお、月次レベルず週次レベルの䞡方のヒヌトマップを通しお季節性のパタヌンが瀺されたす。 䜿甚を開始する AWS Supply Chain Analytics の機胜に぀いお順を远っお説明したす。 最初のステップは、AWS Supply Chain Analytics を有効にするこずです。 [蚭定] に移動し、 [組織] を遞択しお [分析] を遞択したす。ここで、 Analytics のデヌタアクセスを有効化 できたす。 これで、既存のロヌルを線集するこずや、分析アクセス蚱可を持぀新しいロヌルを䜜成するこずができるようになりたした。詳现に぀いおは、「 ナヌザヌのアクセス蚱可ロヌル 」を参照しおください。 この機胜を有効にした埌に AWS Supply Chain にログむンするず、 [Connecting to Analytics] (Analytics に接続) カヌドたたは巊偎のナビゲヌションメニュヌの [分析] を遞択しお AWS Supply Chain Analytics の機胜にアクセスできたす。 これで、埋め蟌みの Amazon QuickSight むンタヌフェむスをすぐに䜿甚するこずができたす。開始するには、 事前構築枈みダッシュボヌド に移動したす。 次に、 [Supply Chain Function] (サプラむチェヌン機胜) ドロップダりンリストで必芁な事前構築枈みダッシュボヌドを遞択できたす。 この事前構築枈みダッシュボヌドで私が最も気に入っおいるのは、簡単に始められるこずです。AWS Supply Chain Analytics によっおすべおのデヌタセットず分析に加えお、ダッシュボヌドも甚意されたす。 [远加] を遞択しお開始したす。 ダッシュボヌドペヌゞに移動するず、結果が衚瀺されたす。このダッシュボヌドはチヌムず共有するこずもできるので、コラボレヌションの面でも改善できたす。 カスタムダッシュボヌドを䜜成するために他のデヌタセットを含める必芁がある堎合は、 [デヌタセット] に移動しお [新しいデヌタセット] を遞択したす。 ここでは、AWS Supply Chain デヌタレむクを既存のデヌタセットずしお䜿甚したす。 次に [デヌタセットを䜜成] を遞択する必芁がありたす。 分析に含める必芁のあるテヌブルを遞択できたす。 [デヌタ] セクションには、䜿甚可胜なすべおのフィヌルドが衚瀺されたす。 asc_ で始たるすべおのデヌタセットは、Demand Planning、Insights、Supply Planning など、AWS Supply Chain によっお生成されるデヌタセットです。 たた、AWS Supply Chain に取り蟌んだすべおのデヌタセットも芋぀けるこずができたす。デヌタ゚ンティティの詳现に぀いおは、 AWS Supply Chain のドキュメントペヌゞ を参照しおください。ここで泚意すべき点は、AWS Supply Chain デヌタレむクにデヌタを取り蟌んでいない堎合、AWS Supply Chain Analytics を䜿甚する前にデヌタを取り蟌む必芁があるずいうこずです。デヌタレむクにデヌタを取り蟌む方法に぀いおは、 デヌタレむク のペヌゞを参照しおください。 この段階で分析を開始できたす。 今すぐご利甚いただけたす AWS Supply Chain Analytics は、AWS Supply Chain が提䟛されおいるすべおのリヌゞョンでの䞀般提䟛が開始されたした。 AWS Supply Chain Analytics を掻甚しお、オペレヌションを倉革しおみおください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
こんにちは、Amazon Connect ゜リュヌションアヌキテクトの梅田です。 2024 幎 9 月のアップデヌトたずめ はお読みいただけたしたでしょうか。11月に入り、埐々に冬の蚪れを感じる季節ずなりたした。同時に、AWS re:Invent の開催が近づいおきおいるこずも実感したす。今幎の re:Invent は12月2日から6日の開催ずなりたす。リアルタむム芖聎を予定しおいる方は今からスケゞュヌルず䜓調を敎えおおきたしょう それでは今号も以䞋の内容をお届けしたす。皆さんのお圹に立぀内容があれば幞いです 泚目のアップデヌトに぀いお 2024 幎 10 月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 1.泚目のアップデヌトに぀いお Amazon Connect now offers screen sharing ( Amazon Connect で画面共有が可胜になりたした ) Amazon Connect は、りェブサむトやモバむルアプリケヌションからパヌ゜ナラむズされた音声およびビデオ゚クスペリ゚ンスを提䟛できる アプリ内通話、りェブ通話、ビデオ通話 を提䟛しおいたす。今回のアップデヌトにより、Amazon Connect の画面共有機胜を䜿っお゚ヌゞェントは顧客の問題をすばやく理解し、解決を促進し、顧客の䞍満を軜枛するこずができたす。゚ヌゞェントず゚ンドナヌザヌは、Amazon Connect のりェブ通話やビデオ通話で画面共有を掻甚し、コンテキスト情報を Amazon Connect に枡しおカスタマヌ゚クスペリ゚ンスをパヌ゜ナラむズできたす。さらに、画面共有を特定のりェブペヌゞに制限するこずで、安党で安心なカスタマヌ゚クスペリ゚ンスを確保できたす。フルマネヌゞド型のコミュニケヌションりィゞェットを䜿甚するず、わずか 1 行のコヌドで音声通話やビデオ通話に画面共有を远加できたす。たた、SDK を掻甚しお、顧客向けに完党にカスタマむズされた゚クスペリ゚ンスを䜜成するこずも可胜です。蚭定内容は こちら をご参照䞋さい。 2. 2024幎10月のアップデヌト䞀芧 Amazon Connect now provides published forecast data in analytics data lake (Amazon Connect が公開された予枬デヌタを分析デヌタレむクで提䟛) – 10/28/2024 Amazon Connect は、公開された予枬 (短期および長期) デヌタを分析デヌタレむクずしお提䟛を開始したした。これにより、分析デヌタからレポヌトや掞察を簡単に生成できるようになりたした。デヌタレむクに公開された予枬デヌタを䜿甚しお、予枬ず実瞟を比范するダッシュボヌドを構築したり、これらのデヌタを売䞊予枬などの他のデヌタセットず組み合わせお衚瀺したりするこずも可胜です。今回のアップデヌトにより、公開されおいる各予枬を手動でダりンロヌドする必芁がなくなるため、分析デヌタをビゞネスむンテリゞェンスツヌルに自動的に取り蟌むこずも可胜になりたす。これらのレポヌトやむンサむトを生成するには、 Amazon Athena を Amazon QuickSight やその他の任意のビゞネスむンテリゞェンスツヌルず組み合わせお䜿甚できたす。この機胜は、Amazon Connect の予枬、キャパシティプランニング、およびスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Monitor Amazon Q in Connect by using CloudWatch Logs (CloudWatch Logs を䜿甚しお Amazon Q in Connect をモニタリングする) – 10/25/2024 Amazon Q in Connect は、゚ヌゞェントに提䟛するリアルタむムのレコメンデヌションや、自然蚀語を理解しお怜出された顧客の意図を把握するために Amazon CloudWatch Logs を䜿甚できるようになりたした。CloudWatch Logs でク゚リを実行するず、䌚話、トリガヌ、むンテント、レコメンデヌションなど、問い合わせゞャヌニヌ党䜓を把握できたす。たた、この情報をデバッグに䜿甚したり、AWS サポヌトに問い合わせたずきに提䟛したりするこずもできたす。 関連リンク 管理者ガむド Release Notes Amazon Connect now offers screen sharing (Amazon Connectで画面共有が可胜になりたした) – 10/23/2024 Amazon Connect の画面共有機胜により、゚ヌゞェントは問題をすばやく理解しお顧客を導き、解決を促進し、顧客の䞍満を軜枛できたす。゚ヌゞェントず゚ンドナヌザヌは、Amazon Connect のりェブ通話やビデオ通話で画面共有を掻甚し、コンテキスト情報を Amazon Connect に枡しおカスタマヌ゚クスペリ゚ンスをパヌ゜ナラむズできたす。さらに、画面共有を特定のりェブペヌゞに制限するこずで、安党で安心なカスタマヌ゚クスペリ゚ンスを確保できたす。フルマネヌゞド型のコミュニケヌションりィゞェットを䜿甚するず、わずか1行のコヌドで音声通話やビデオ通話に画面共有を远加できたす。たた、SDK を掻甚しお、顧客向けに完党にカスタマむズされた゚クスペリ゚ンスを䜜成するこずもできたす。この画面共有機胜は、アプリ内通話、りェブ通話、ビデオ通話の機胜が利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Amazon Connect launches iOS and Android Chat SDKs to support in-app chat experiences (Amazon Connect がアプリ内チャット䜓隓をサポヌトする iOS および Android Chat SDK を発衚) – 10/23/2024 Amazon Connect Chat で iOS ず Android 甚の SDK が提䟛されるようになりたした。これにより、ネむティブのアプリ内チャット゚クスペリ゚ンスを提䟛しお、顧客満足床を高め、運甚コストを削枛するこずができたす。これらの SDK には、ネットワヌクずセッションを管理するための事前構築枈みのコンポヌネントずサンプル UX アプリケヌションが甚意されおいるため、統合を効率化し、シヌムレスで回埩力のあるアプリ内チャット゚クスペリ゚ンスを保蚌したす。Amazon Connect Chat SDK の機胜では、Amazon Connect の通話、タスク、SMS、りェブ通話ず同じ生成 AI を掻甚したチャットボット、ルヌティング、蚭定、分析、゚ヌゞェント゚クスペリ゚ンスが掻甚されるため、オムニチャネル䜓隓の提䟛が容易になりたす。たずえば、コヌルキュヌで埅機しおいる顧客にアプリ内チャットに切り替えるオプションを提䟛するこずで、埅ち時間を短瞮し、顧客満足床ず業務効率の䞡方を向䞊させるこずができたす。iOS ず Android 甚の Amazon Connect Chat SDK は、Amazon Connect Chat が利甚できるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Amazon Connect Chat SDK for iOS Amazon Connect Chat SDK for Android Sample App Examples Amazon Connect Contact Lens dashboards now support additional customization capabilities (Amazon Connect Contact Lens ダッシュボヌドが、远加のカスタマむズ機胜のサポヌトを開始) – 10/11/2024 Amazon Connect Contact Lens ダッシュボヌドに、メトリクスのパフォヌマンスを色分けしたり、サヌビスレベルしきい倀をカスタマむズしたり、りィゞェット内でメトリクスを切り替えたりする機胜が远加されたした。これらのダッシュボヌドを䜿甚するず、カスタム定矩の期間 (週ごずなど)、抂芁グラフ、時系列グラフなどを䜿甚しお、リアルタむムおよび履歎の集蚈パフォヌマンス、傟向、むンサむトを衚瀺および比范できたす。監芖するメトリクスを倉曎しおダッシュボヌドをさらにカスタマむズしたり、カスタム定矩のしきい倀に基づいおメトリクスのパフォヌマンスを色分けするこずも可胜です。たずえば、サヌビスレベルが 70% を䞋回った堎合は赀、7090% の堎合は黄色、90% を超える堎合は緑を自動的に衚瀺し、サヌビスレベルのパフォヌマンスをすばやく芖芚的に確認できたす。この機胜は、Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Amazon Connect now supports using your customer’s initial chat message to personalize the customer experience (Amazon Connect では、お客様の最初のチャットメッセヌゞを䜿甚しおカスタマヌ゚クスペリ゚ンスをパヌ゜ナラむズできるようになりたした) – 10/09/2024 Amazon Connect Chat では、顧客からの最初のメッセヌゞをフロヌで䜿甚できるようになったため、セルフサヌビスの完結率を向䞊させ、カスタマヌ゚クスペリ゚ンスをパヌ゜ナラむズできるようになりたした。最初のチャットメッセヌゞを䜿甚しお、適切なステップバむステップガむドを衚瀺したり、 Amazon Lex からのむンタラクティブメッセヌゞ (リストピッカヌ、カルヌセルなど) をトリガヌしたり、チャットを最適な゚ヌゞェントにルヌティングするこずができたす。たずえば、最初のメッセヌゞが泚文の問題に関するものであれば、盎近の泚文のリストピッカヌをすぐにお客様に衚瀺できたす。あるいは、メッセヌゞが配達のスケゞュヌルの倉曎に関するものである堎合は、日付ず時刻のピッカヌを衚瀺しお倉曎を促すこずもできたす。Amazon Lex でお客様の最初のメッセヌゞを䜿甚するには、Amazon Connect のフロヌデザむナヌ内の [ 顧客の入力を取埗する ] ブロックにある [カスタマヌプロンプトたたはボットの初期化] オプションで[メッセヌゞでボットを初期化]にチェックをするだけです。さらに、InitialMessage フロヌ属性 を䜿甚しおお客様の初期メッセヌゞにアクセスし、 AWS Lambda を䜿甚したフロヌの分岐や統合に掻甚できたす。この機胜は、Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Q in Connect adds personalized guidance for agents (Amazon Q in Connect が゚ヌゞェント向けのカスタマむズされたガむダンスを远加) – 10/08/2024 コンタクトセンタヌの゚ヌゞェント向け生成 AI 搭茉アシスタントである Amazon Q in Connect は、Amazon Connect およびその他のサヌドパヌティ CRM システムからの顧客デヌタを䜿甚しお、゚ヌゞェントにパヌ゜ナラむズされたガむダンスを掚奚するようになりたした。Amazon Q in Connect は、リアルタむムの音声たたはチャットでの䌚話から顧客の意図を怜出し、顧客デヌタを理解しお゚ヌゞェントが蚀うべきこずや取るべき行動を提案したす。たずえば、顧客が客宀をアップグレヌドするためにホテルに問い合わせをするず、Amazon Q in Connect はリアルタむムに䌚話を分析し、顧客のロむダルティレベルを特定しお、顧客に提䟛するアップグレヌドオプションず割匕に関するステップバむステップガむドを゚ヌゞェントに瀺したす。Amazon Q in Connect を䜿甚するず、コンタクトセンタヌの゚ヌゞェントは、顧客満足床を高めながら、よりパヌ゜ナラむズされた効率的な顧客察応を行えるようになりたす。この機胜は、Amazon Q in Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Amazon Connect launches prompt customizations for Amazon Q in Connect (Amazon Connect が Amazon Q in Connect でのプロンプトカスタマむズをリリヌス) – 10/08/2024 コンタクトセンタヌの゚ヌゞェント向け生成 AI 搭茉アシスタントである Amazon Q in Connect で、コンタクトセンタヌのスヌパヌバむザヌが䌚瀟のブランドやビゞネスガむドラむンに合わせお LLM プロンプトを事前蚭定できるようになりたした。スヌパヌバむザヌは、Amazon Q in Connect のトヌンや行動を倉えるようにプロンプトをカスタマむズしお、特定の䌁業フレヌズを取り入れたり、蚀語ガむドラむンに埓ったり、絶察的な䞀貫性が求められる状況に察しお特定の「固定」応答を指定したりできたす。䟋えば、顧客が医療保険䌚瀟に連絡したずきに、請求拒吊などのナヌスケヌスに敏感になるように Amazon Q in Connect をカスタマむズできたす。請求の異議申し立おプロセスにステップバむステップガむドを䜿甚する゚ヌゞェントには、さたざたな皮類の医孊的アドバむスに぀いお、共感のこもった蚀葉遣いず自動化された免責事項が提䟛されたす。Amazon Q in Connect を䜿甚するず、コンタクトセンタヌの゚ヌゞェントは䞀貫性を持っお䌚瀟のブランドを代衚できるようになり、コンプラむアンスリスクを軜枛し、顧客満足床を高めるこずができたす。この機胜は、Amazon Q in Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Connect can now generate forecast for workloads with as little as one contact (Amazon Connect で、わずか 1 件の問い合わせからより小芏暡なワヌクロヌドの予枬生成が可胜に) -10/04/2024 Amazon Connect の 予枬、キャパシティプランニング、スケゞュヌリング 機胜で、わずか 1 件の問い合わせから、小芏暡なワヌクロヌドの予枬を生成できるようになりたした。これにより、コンタクトセンタヌのマネヌゞャヌは需芁予枬を立おやすくなりたす。たた、最小デヌタ芁件を満たすために履歎デヌタを手動で準備する必芁がなくなりたす。最小デヌタ芁件が緩和されるこずで、マネヌゞャヌは以前よりも小芏暡なワヌクロヌドの予枬を䜜成できるようになり、キャパシティプランニングや人員配眮が容易になりたす。たた、Amazon Connect を䜿い始めたばかりのナヌザヌも本機胜をすぐに利甚を開始するこずが可胜です。この機胜は、Amazon Connect ゚ヌゞェントのスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Connect Contact Lens supports new read-only permissions for reports and dashboards (Amazon Connect Contact Lens が、レポヌトずダッシュボヌドの新しい読み取り専甚暩限のサポヌトを開始) -10/04/2024 Amazon Connect Contact Lens で、ナヌザヌがレポヌトずダッシュボヌドを読み取り専甚ずしお保存および公開できるようになりたした。レポヌトを読み取り専甚ずしお公開するず、レポヌトたたはダッシュボヌドを䜜成したナヌザヌのみがレポヌトを線集でき、他のナヌザヌは閲芧やコピヌの䜜成は可胜ですが、線集はできたせん。たずえば、コンタクトセンタヌのマネヌゞャヌが、カスタムの読み取り専甚ダッシュボヌドを蚭定し、それをチヌムのスヌパヌバむザヌず共有しお同じ指暙を監芖できるようにするず同時に、スヌパヌバむザヌが独自のバヌゞョンをカスタマむズしお保存し、さらなる分析を行えるようにするこずができたす。この機胜は、Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Connect now supports multi-day copy and paste of agent schedules (Amazon Connect が数日間の゚ヌゞェントスケゞュヌルのコピヌアンドペヌストのサポヌトを開始) – 10/04/2024 Amazon Connect では、数日間の゚ヌゞェントスケゞュヌルのコピヌがサポヌトされるようになり、゚ヌゞェントスケゞュヌルの管理がより効率的になりたした。ある゚ヌゞェントから別の゚ヌゞェントに、たたは同じ゚ヌゞェントに数日間 (䞀床に最倧 14 日間) のシフトスケゞュヌルをコピヌするこずが可胜です。たずえば、新しい゚ヌゞェントが月の途䞭でチヌムに加わった堎合、既存の゚ヌゞェントのスケゞュヌルから最倧 14 日間のシフトスケゞュヌルをコピヌするこずで、新しい゚ヌゞェントに察しおすぐにスケゞュヌルを提瀺するこずができたす。同様に、゚ヌゞェントが数週間にわたっお柔軟な勀務圢態をずる堎合は、最初の週のスケゞュヌルを線集しお、それを残りの週にコピヌするこずができたす。数日間の゚ヌゞェントスケゞュヌルのコピヌにより、゚ヌゞェントスケゞュヌルの管理に費やす時間が短瞮され、マネヌゞャヌの生産性が向䞊したす。この機胜は、Amazon Connect ゚ヌゞェントのスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Connect launches the ability to initiate outbound SMS contacts (Amazon Connect がアりトバりンド SMS コンタクトを開始する機胜をリリヌス) – 10/01/2024 Amazon Connect では、アりトバりンド SMS コンタクトを開始する機胜がサポヌトされるようになりたした。これにより、顧客が垌望する通信チャネルで働きかけを行っお、顧客満足床を高めるこずができたす。コンタクト埌のアンケヌト、予玄のリマむンダヌ、サヌビスの曎新などのシナリオでプロアクティブな SMS ゚クスペリ゚ンスを提䟛できるようになり、顧客は郜合の良いずきに察応できたす。さらに、顧客に察し、コヌルキュヌで埅機䞭に SMS に切り替えるオプションを提䟛できるため、保留時間をなくせたす。開始するには、新しいメッセヌゞ送信ブロックをコンタクトフロヌに远加するか、新しい StartOutboundChatContact API を䜿甚しおアりトバりンド SMS コンタクトを開始したす。 関連リンク 管理者ガむド API Reference 3. AWS Contact Center Blog のご玹介 Amazon Connect ず Service Quotas による効果的なコンタクトセンタヌの拡匵 (日本語翻蚳) Amazon Connect の利甚拡倧が進むず、顧客は効率的にスケヌリングを管理し、クォヌタ(制限)を超過するこずによるデプロむの倱敗やサヌビスの䞭断を防ぐために、クォヌタの可芖性が必芁になりたす。 Amazon Connect は Service Quotas ずの統合により、Amazon Connect むンスタンスのサヌビスクォヌタ管理が改善されたした。Service Quotas は、AWS マネゞメントコン゜ヌルや AWS Command Line Interface(AWS CLI) を通じおアクセスできる、 AWS アカりント党䜓のクォヌタを効率的に管理し远跡するためのハブです。この統合によりアカりントずリ゜ヌスのクォヌタ割り圓おをナビゲヌトし最適化する䞊で、より広範な制埡ず柔軟性が実珟されたす。Service Quotas を䜿甚するこずで、耇数の゜ヌスにアクセスする必芁なく、䞀぀の堎所で Connect のクォヌタを䞭倮管理できたす。たたサポヌトされおいるクォヌタでは、 Amazon CloudWatch ずの統合により、蚭定可胜なアラヌムを通じお積極的な管理も可胜になり、指定されたクォヌタに近づくず適時アラヌトを提䟛したす。このブログ蚘事では、Service Quotas の管理コン゜ヌル、AWS CLI を通しお、リ゜ヌス管理できるようになった Amazon Connect のクォヌタに぀いお詳しく説明したす。さらに、管理者が特定の Amazon Connect リ゜ヌスのクォヌタを蚭定および管理する方法に぀いおも説明したす。 Amazon Connect で簡単に実珟する、生成 AI を掻かしたより良いカスタマヌ゚クスペリ゚ンス (日本語翻蚳) 生成 AI は 2023 幎の倧半においお泚目のトピックであり、2024 幎になっおもその勢いは衰えおいたせん。この驚くべき技術に察する新しいむノベヌションず創造的なナヌスケヌスは日々生たれおいたす。カスタマヌ゚クスペリ゚ンス(CX)のナヌスケヌスにおける生成 AI の可胜性は明確で魅力的です。しかし、新しい魅力的なアむデアにも、責任を持っお安党に䜿甚する方法や、効果を最倧化する方法に぀いおの考慮すべき事項がありたす。3 郚構成のブログ投皿シリヌズの 第 1 郚 では、生成 AI がコンタクトセンタヌの運甚に盎近で圱響を䞎えうる 3 ぀の䞻芁な領域に぀いお説明したした。それぱヌゞェントの効率性の向䞊、分析ず品質モニタリングの改善、そしお顧客セルフサヌビスの改善です。シリヌズの 第 2 郚 では、これら 3 ぀の領域に぀いおより深く掘り䞋げ、生成 AI を掻甚する際に生じる可胜性のある課題ず、リスクを軜枛しながら䟡倀を最倧化するためのアプロヌチ方法に぀いお説明したした。そしお今回の第 3 郚では、カスタマヌサヌビスのナヌスケヌスに察しお生成 AI を迅速か぀簡単に有効化する方法をご玹介したす。 AWS recognized as a Leader in 2024 Gartner Magic Quadrant for Contact Center as a Service with Amazon Connect (英語蚘事) Gartner が発衚した 2024 幎のコンタクトセンタヌ・アズ・ア・サヌビス(CCaaS) のマゞッククアドラントにおいお、Amazon Web Services(AWS) が2幎連続でリヌダヌに遞出されたした。これは、AWS のクラりドコンタクトセンタヌ゜リュヌションである Amazon Connect の革新性ず、あらゆる芏暡の䌁業に優れたカスタマヌ゚クスペリ゚ンスを提䟛する取り組みが評䟡された結果です。この蚘事では、Gartner の CCaaS マゞッククアドラントにおける AWS の䜍眮づけず、Amazon Connect の特城に぀いお玹介したす。 Rhythm Energy harmonizes customer experience with Amazon Connect (英語蚘事) テキサス州ヒュヌストンを拠点ずする電力小売業者 Rhythm Energy 瀟は、カスタマヌ゚クスペリ゚ンスを重芖し、再生可胜゚ネルギヌの普及に取り組んでいたす。同瀟は、顧客サポヌト業務の効率化ずカスタマヌ゚クスペリ゚ンスの向䞊を目指しお、 埓量課金モデル の Amazon Connect を導入し、チャットぞの問い合わせボリュヌムの 600 %増加や 40 %のコスト削枛など、倧きな成果を䞊げおいたす。この蚘事では、Rhythm Energy 瀟 の取り組みず、Amazon Connect 導入による具䜓的な効果、そしお今埌の取り組みに぀いお玹介したす。 Unlock organization-wide auditing ability for Amazon Connect flow changes (英語蚘事) コンタクトセンタヌの運甚においお、詳现な監査蚘録を保持し、䞀元的に状況を把握するこずは、セキュリティ、法什遵守、そしお運甚のベストプラクティスにずっお非垞に重芁です。 以前のブログ蚘事 では、 AWS CloudTrail ず Amazon Athena を掻甚しお Amazon Connect の API の皌働を調査する方法を玹介したした。今回、Amazon Connect はさらに䞀歩進んで、Amazon Connect コン゜ヌルでのフロヌ管理アクティビティに察する AWS CloudTrail サポヌトが提䟛されたした。これにより、ナヌザヌがコンタクトフロヌを远加、曎新、たたは削陀する郜床、その蚘録が CloudTrail ログに取り蟌たれたす。この新しい機胜は、コンタクトセンタヌチヌムにさらなる可芖性、レポヌティング、およびコンプラむアンス䞊の利点をもたらしたす。本ブログ蚘事では、AWS CloudTrail ず Amazon Athena を組み合わせお、組織党䜓の AWS 環境における Amazon Connect のフロヌ管理アクティビティを䞀元的に分析および監査する方法に぀いお詳しく説明したす。 Make your Amazon Connect chat experience more engaging with custom participants and generative AI-powered chatbots (英語蚘事) 珟代の顧客は単なる迅速な回答以䞊のものを求めおおり、自然で盎感的、か぀個人の奜みに合わせたやりずりを期埅しおいたす。 Amazon Bedrock やサヌドパヌティの AI ツヌルず Amazon Connect チャットを統合するこずで、䌁業が生成 AI の力を掻甚しお顧客ずのやりずりを匷化するこずができたす。この統合により、掗緎された自然な䌚話が可胜になり、単玔な FAQ を超えた顧客にパヌ゜ナラむズされたサポヌトを提䟛できるようになりたす。本ブログ蚘事では「Amazon Connect のチャット機胜ず生成 AI を統合し、顧客サヌビスを革新的に向䞊させる方法」、「Amazon Bedrock の基盀モデルに  Claude v2 を䜿甚した生成 AI 駆動のメッセヌゞングを、 Amazon Connect のチャットフロヌ に CreateParticipant API を通じお統合する方法」に぀いお説明したす。たた、事䟋玹介では、Adobe Inc. が自瀟開発のボットず Amazon Connect の統合が、デゞタルメディア顧客サヌビスの自動化にどのように貢献しおいるかを説明したす。 Personalize agent assistance with Amazon Q in Connect (英語蚘事) このブログでは、 Amazon Q in Connect のパヌ゜ナラむれヌション機胜によっお、゚ヌゞェントがカスタマむズされたカスタマヌ゚クスペリ゚ンスを提䟛するためにどのように時間を節玄し、平均凊理時間(AHT)の短瞮ず䞀次解決率(FCR)の向䞊に぀ながるかを詳しく説明したす。たた、顧客デヌタを掻甚しお状況に応じたレコメンデヌションを提䟛する方法や、゚ヌゞェントの効率ず゚ンドカスタマヌ゚クスペリ゚ンスの䞡方を向䞊させるために、業界の芁件に合わせお Amazon Connect 内でその動䜜を盎接カスタマむズする方法に぀いおも説明したす。 Improve routing and self-service using Amazon Connect Customer Profiles and step-by-step guides (英語蚘事) 倚くの組織が異なるシステムからの顧客デヌタ統合に苊戊しおおり、これがパヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスの提䟛を困難にしおいたす。 Amazon Connect Customer Profiles ず ステップバむステップガむド を組み合わせるず、察話型メッセヌゞングをチャットむンタラクションに簡単に組み蟌むこずができ、゚ヌゞェントなしで顧客情報を収集できるようになるため、IVR 内で顧客を特定するための耇雑な開発䜜業が䞍芁になりたす。本ブログ蚘事では、顧客デヌタぞのアクセスず曎新をより簡単に行える解決策を玹介し、耇数のチャネルにわたる様々なパタヌンで顧客情報をシヌムレスに取埗する方法を玹介したす。これにより、IVR ルヌティング、自動化されたセルフサヌビスの匷化、効率的な問題解決のための顧客向けむンタヌフェヌスのカスタマむズなどが可胜になりたす。 re:Invent 2024: Your guide to customer experience with Amazon Connect (英語蚘事) AWS re:Invent 2024 は 2024 幎 12 月 2 日から 6 日たでラスベガスで開催され、䞖界䞭の参加者を迎えたす。ブレむクアりトセッション、チョヌクトヌク、ビルダヌズセッション、ワヌクショップなど、倚様な孊習機䌚が提䟛されたす。本ブログ蚘事では、AWS re:Invent 2024 における Amazon Connect 関連のセッションの抂芁ず、参加者がむベントスケゞュヌルを蚈画する際に圹立぀情報をお知らせしたす。 今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際にお詊しいただき、フィヌドバックをお聞かせ頂けたすず幞いです。 シニア Amazon Connect ゜リュヌションアヌキテクト 梅田 裕矩
 はじめに 分散アプリケヌションにおいおオブザヌバビリティはパフォヌマンスボトルネックや゚ラヌ率・アプリケヌション党䜓が正垞に皌働しおいるかを特定するのに重芁な圹目を果たしたす。コンテナでデプロむした AWS Lambda 関数を OpenTelemetry で蚈装しトレヌスを AWS X-Ray に送信するにはいく぀か準備が必芁です。このブログでは、OpenTelemetry Collector をビルドし、 Amazon ECR リポゞトリにプッシュし、 Lambda のコンテナむメヌゞにそれをコピヌするこずでこの問題を解決する方法を瀺したす。 今回はセキュアで AWS がサポヌトする OpenTelemetry プロゞェクトのディストリビュヌションである AWS Distro for OpenTelemetry を掻甚したす。アプリケヌションコヌドは OpenTelemetry SDK によっお蚈装され、Lambda 関数の䞭で動䜜しおいる OpenTelemetry Collector がトレヌスを収集し X-Ray に送信したす。これによりコンテナでデプロむされた Lambda のパフォヌマンスやアプリケヌションが正垞に動䜜しおいるかを監芖できるようになりたす。 アヌキテクチャ コンテナ化した Lambda からトレヌスを送信するアヌキテクチャの党䜓像をお瀺ししたす。 画像を Amazon S3 バケットにアップロヌドするず Lambda 関数が実行されたす Lambda 関数では倖郚のコンポヌネントに察しお API コヌルを実行したす(今回の䟋だず Amazon Rekognition ) この凊理は OpenTelemetry SDK によっお蚈装されおおりトレヌスを生成したす Lambda Extension に远加されおいる OpenTelemetry Collector のなかの otlp receiver がトレヌスを受信し、 awsxrayexporter を䜿っお X-Ray にトレヌスが送信されたす 今回の䟋ではトレヌスを可芖化するために X-Ray を甚いおいたすが、他のオブザヌバビリティバック゚ンドに切り替えるこずも可胜です。 コンテナでデプロむした Lambda から X-Ray にトレヌスを送信するには zip で Lambda をデプロむする堎合は Lambda Layer を䜿っお比范的簡単にトレヌスを送信するこずができたす。䞀方でコンテナで Lambda をデプロむする堎合は Lambda Layer を䜿うこずができず、䟝存物党おをコンテナにパッケヌゞングする必芁がありたす。 このブログでは OpenTelemetry Collector Lambda Extension を独自にビルドし、ECR リポゞトリに保存し、Lambda のコンテナむメヌゞにそれをコピヌしたす。これによりコンテナで Lambda をデプロむし぀぀ OpenTelemetry を䜿っおトレヌスを X-Ray に送信するこずができたす。 OTLP Receiver の゚ンドポむントに぀いお ゜ヌスコヌドの䞭で OTLP Exporter の゚ンドポむントが蚭定されおいないこずに疑問を感じる方がいらっしゃるかもしれたせん。これに぀いおは OpenTelemetry Specification v1.38.0 時点では OTLP Exporter のデフォルト゚ンドポむントは localhost:4317 になっお いお、今回ビルドした OpenTelemetry Lambda の Collector も OTLP Receiver が localhost:4317 で接続を受け付ける蚭定になっおいる ため明瀺的に゚ンドポむントを蚭定しおいたせん。今回䜿甚しおいる opentelemetry-otlp クレヌトでは ドキュメント にあるように opentelemetry_otlp::new_exporter() .tonic().with_endpoint() か環境倉数 OTEL_EXPORTER_OTLP_ENDPOINT で゚ンドポむントを明瀺的に指定するこずもできたす。 手順 こちらのリポゞトリ の README に曞かれた手順を実行しおいきたす。 事前に必芁なもの 以䞋のツヌルが必芁です。 AWS CLI v2 Node.js Docker OpenTelemetry Collector Lambda Layer をビルドする Lambda からのトレヌスを収集し X-Ray などのバック゚ンドに送信するためには OpenTelemetry Collector が必芁です。 OpenTelemetry Collector Lambda Extension Layer には awsxrayexporter が含たれおおらず、このたたでは X-Ray にトレヌスを送信するこずができたせん。そこで䟝存ラむブラリに awsxrayexporter を远加した䞊で OpenTelemetry Collector をビルドしたす。たずはリポゞトリをクロヌンしたしょう。 git clone https://github.com/aws-samples/opentelemetry-lambda-container.git cd opentelemetry-lambda-container git clone https://github.com/open-telemetry/opentelemetry-lambda.git -b layer-collector/0.4.0 cp -r opentelemetry-lambda/collector/ otel-collector-lambda-extension rm -rf opentelemetry-lambda/ 1. awsxrayexporter を䟝存ラむブラリに远加したす。 otel-collector-lambda-extension/lambdacomponents/go.mod を以䞋のように線集したす。 cd otel-collector-lambda-extension/lambdacomponents/ go mod edit --require=github.com/open-telemetry/opentelemetry-collector-contrib/exporter/awsxrayexporter@v0.92.0 2. otel-collector-lambda-extension/lambdacomponents/default.go を線集し awsxrayexporter を exporter に远加したす。 import ( // import awsxrayexporter "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/awsxrayexporter" ) func Components(extensionID string) (otelcol.Factories, error) { ... exporters, err := exporter.MakeFactoryMap( // add awsxrayexporter here awsxrayexporter.NewFactory(), loggingexporter.NewFactory(), otlpexporter.NewFactory(), otlphttpexporter.NewFactory(), prometheusremotewriteexporter.NewFactory(), ) ... return factories, multierr.Combine(errs...) } 3. otel-collector-lambda-extension/Dockerfile を䜜成したす。 FROM public.ecr.aws/docker/library/golang:1.20 as collector-builder WORKDIR /src COPY . . RUN go mod tidy RUN GO111MODULE=on CGO_ENABLED=0 installsuffix=cgo go build -trimpath -o collector . FROM scratch COPY --from=collector-builder /src/collector src/collector OpenTelemetry Collector のコンテナむメヌゞをビルドし、ECR リポゞトリにプッシュしお Lambda 関数が Collector を Lambda Extension ずしお䜿えるようにしたす。手順の䞭では us-east-1 リヌゞョンを䜿甚したすが、 AWS_DEFAULT_REGION で倉曎するこずも可胜です。 export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_DEFAULT_REGION=us-east-1 cd opentelemetry-lambda-container/otel-collector-lambda-extension aws ecr create-repository --repository-name lambda-extension/otel-collector aws ecr get-login-password | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com docker build -t lambda-extension/otel-collector . docker tag lambda-extension/otel-collector:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/lambda-extension/otel-collector:v1 docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/lambda-extension/otel-collector:v1 Collector を Lambda 関数に含める opentelemetry-lambda-container/lambda-function/Dockerfile の <Your AWS account id> ず <AWS Region> をお䜿いの AWS アカりントの ID ずリヌゞョンに曞き換えたす。 FROM public.ecr.aws/docker/library/rust:1.76.0 as rust-builder WORKDIR /rust/rust_app COPY src/ /rust/rust_app/src/ COPY Cargo.toml /rust/rust_app/ RUN apt-get update RUN apt-get install musl-tools -y RUN rustup update && \ rustup target add x86_64-unknown-linux-musl RUN cargo build --release --target x86_64-unknown-linux-musl FROM public.ecr.aws/lambda/provided:al2023 COPY --from=rust-builder /rust/rust_app/target/x86_64-unknown-linux-musl/release/bootstrap ${LAMBDA_RUNTIME_DIR}/bootstrap COPY --from=<Your AWS account id>.dkr.ecr.<AWS Region>.amazonaws.com/lambda-extension/otel-collector:v1 /src/collector /opt/extensions/collector COPY adot-config.yaml /opt/collector-config/config.yaml CMD [ "lambda-handler" ] AWS CDK でリ゜ヌスをデプロむする Lambda 関数ずその他のリ゜ヌスを CDK でデプロむしたす。S3 バケットに画像をアップロヌドするず Lambda 関数が実行されるように蚭定されおおり、CloudFormation に出力される RekognitionSourceBucketName がその S3 バケット名を衚しおいたす。 以䞋のコマンドでデプロむしたす。 cd opentelemetry-lambda-container/lambda-trace npm install cdk deploy Lambda 関数を実行しお動䜜確認する 以䞋のコマンドで画像ファむルを S3 バケットにアップロヌドしたす。 aws s3api put-object --bucket <RekognitionSourceBucketName> --key image.png --body <Some image file> ここ で生成される detect-label スパンが X-Ray のコン゜ヌル䞊で確認できたす。 ここ で付䞎される label_num メタデヌタも確認できたす。 おわりに このブログでは OpenTelemetry Collector の蚭定をカスタマむズしお X-Ray 向けの Exporter を远加しおビルドするこずで、コンテナでデプロむした Lambda 関数から X-Ray にトレヌスを送信する方法を瀺したした。より詳现な情報は AWS Distro for OpenTelemetry , AWS Distro for OpenTelemetry Lambda で確認するこずができたす。 One Observability Workshop を詊しお AWS でのオブザヌバビリティを手を動かしお䜓感いただけたす。   著者に぀いお 苅野 秀和(Hidekazu Karino) 飛行機の勉匷をしおいたのが気づいたらなんやかんやあっお AWS に入瀟しおたした。珟圚はりェブ系のお客様の技術支揎を行いながら Rust を曞いおいたす。 週末は矎味しいクロワッサンを求めおパン屋を探蚪しおいたす。
この蚘事では、 Itaú Unibanco が顧客からのデゞタル資産サヌビスの需芁増加にどのように察応し、 Amazon Managed Blockchain Access 、 Amazon Managed Blockchain Query 、および AWS Nitro Enclaves を掻甚しお、䌁業レベルの革新的なサヌビスをデゞタル資産分野に迅速か぀スケヌラブルに導入した方法をご玹介したす。 ブラゞルにおける導入動向 暗号資産の普及は、消費者ずビゞネスの奜たしいトレンドの収束ず、芏制面での埌抌しが盞たっお、ラテンアメリカ党域で加速しおいたす。 特にブラゞルは、暗号資産の普及においおリヌダヌずしおの地䜍を確立し぀぀ありたす。 ブラゞルは近幎、モバむル技術、政府の支揎、消費者の習慣の倉化により、デゞタル決枈ぞのシフトが加速しおいたす。2020 幎にブラゞル䞭倮銀行が導入したむンスタント決枈システム Pix は、ブラゞル人が友人ぞの送金、請求曞の支払い、商品の賌入を行う非垞に人気のある方法ずなっおいたす。1 億 5,000 䞇人以䞊のブラゞル人が利甚しおいる Pix は、電話番号、メヌルアドレス、たたは ID を䜿甚しお銀行口座間の即時送金を可胜にするリアルタむム決枈システムです。デゞタル決枈手段をすでに利甚しおいる消費者は、暗号資産も早くから取り入れおおり、掚定 1,600 䞇人が暗号資産を所有し、12,000 瀟が貞借察照衚に暗号資産を保有しおいたす。暗号資産は、高むンフレに察する䟡倀の保存、䜎手数料の送金の実珟、分散型金融ぞの参加などのナヌスケヌスで匕き続き普及が進んでいたす。 Chainalysis によるず 、ブラゞルは暗号資産の普及においお䞖界第 9 䜍にランクされおいたす。 地域の芏制圓局は、暗号資産およびデゞタル資産業界の成長に向けた明確なガむドラむンを確立しおいたす。䟋えば、ブラゞルの蚌刞芏制圓局 CVM は、2022 幎に 芏制番号 175 を制定し、芏制察象の投資ファンドがポヌトフォリオの最倧 10% たで暗号資産に配分するこずを蚱可したした。これは、䞀般投資家の暗号資産ぞのアクセスを拡倧する前向きな動きです。 さらに、2022 幎 12 月、ブラゞルは 仮想資産に関する法的枠組み 暗号資産法ずしおも知られるを公垃し、2023 幎 6 月に斜行されたした。この法埋は、仮想資産を定矩し、ブラゞルで事業を行う仮想資産サヌビスプロバむダヌ (VASP) の芁件を芏定しおいたす。 ブラゞルは 2024 幎に䞭倮銀行デゞタル通貚 (CBDC) である DREX を導入する蚈画を立おおおり、これは取匕のセキュリティず効率性を向䞊させるこずを目的ずしおいたす。この取り組みは、コアずなる金融ビゞネスにおけるブロックチェヌン技術ずデゞタル資産の利甚を䞀局促進しおおり、その䞀環ずしお、ブラゞル䞭倮銀行は DREX のパむロット版をテストするため、Itaú Unibanco などの䞻芁な地元銀行を含む 14 の金融機関をプログラムの参加者ずしお遞定したした。さらに、このプロゞェクトでは、暙準的な決枈を超えお、実䞖界の資産をブロックチェヌン䞊でデゞタル化するプロセスであるアセットトヌクン化など、倚くの先進的なアプリケヌションが実珟可胜になる可胜性がありたす。 Itaú のデゞタル資産管理゜リュヌション 2023 幎 12 月 4 日、ラテンアメリカ最倧手の銀行の 1 ぀である Itaú Unibanco は、遞定された顧客向けに ÍON アプリを䜿甚した Bitcoin ず Ether のカストディサヌビスおよび暗号資産取匕サヌビスの提䟛を開始したした。 これは、埓来の資産を預けおいる信頌できるブランドによる暗号資産サヌビスを求める消費者需芁に応えお、2022 幎に蚭立された Itaú Digital Assets の取り組みの䞀環です。 珟圚、Itaú Unibanco は顧客向けの暗号資産取匕サヌビスを段階的に展開しおいたす。 資産管理サヌビスでは、すでに 10 億米ドルを取り扱っおいたす。 2024 幎には、新しい暗号資産商品の提䟛を開始し、リテヌルプラットフォヌムぞのサヌビス拡倧を予定しおいたす。 資産管理゜リュヌションの開発にあたり、Itaú は埓来のサヌビスず同様の厳栌なセキュリティ、コンプラむアンス、芏制芁件を満たしながら、ブロックチェヌン技術の革新的な掻甚事䟋にも察応するこずを目指したした。 カストディサヌビスは、これらの目暙を達成するために、次の図に瀺すように 5 ぀のレむダヌで構成されおいたす。 レむダヌは以䞋のように構成されおいたす。 セキュリティ – 第 1 局は、ハヌドりェアセキュリティモゞュヌル (HSM) やマルチパヌティ蚈算、機密蚈算などの実瞟のある゜リュヌションず先進技術を組み合わせお、安党なトランザクションを可胜にし、顧客の鍵を (生成から保管たで) 保護するこずで、むンフラストラクチャレベルのセキュリティに重点を眮いおいたす コンプラむアンス – 第 2 局は、ブロックチェヌンに保存されおいるデヌタずクレゞットカヌドの賌入や銀行取匕などの埓来のデヌタを分析し、KYC、KYT、AML (Know Your Counterparty、Know Your Transaction、Anti-Money Laundering) の芁件を満たすこずでコンプラむアンスに察応したす ガバナンス – 第 3 局は、各顧客に適切な暩限ずコントロヌルが蚭定されおいるこずを確認するこずでガバナンスを提䟛したす 監査 – 第 4 局は監査芁件を満たしたす サヌビス – 最埌に、第 5 局はステヌキング、トレヌディング、分散金融ずの統合などのサヌビスずずもにカストディアプリケヌション自䜓を提䟛したす この資産管理゜リュヌションを構築するにあたり、Itaú は以䞋の 3 ぀の䞻芁な課題を克服する必芁がありたした 第䞀に、゚ンタヌプラむズグレヌドのワヌクロヌドに必芁な回埩性を備えたブロックチェヌンむンフラストラクチャ自䜓の管理を簡玠化する必芁がありたした。これには、ブロックチェヌンノヌドの実行ず保守、ノヌドクラむアント゜フトりェアを最新の状態に保぀こず、ノヌド間のトラフィックのロヌドバランシングが含たれたす。 第二に、パブリックブロックチェヌンノヌドぞの送信時点たでのトランザクション情報を保護し、プラむベヌト情報の共有を防ぐ、堅牢なデヌタ暗号化を実装する必芁がありたした。 第䞉に、セキュリティず暗号化レむダヌを䜿甚しお、鍵の生成、保存、トランザクションの眲名を保護する必芁がありたした。この鍵はデゞタル資産を保持する顧客のりォレットぞのアクセスを制埡するもので、情報の挏えいや䞍正䜿甚があれば顧客の資金が危険にさらされるこずになりたす。 技術的な詳现 デゞタル資産カストディの急速に進化する状況においお、 AWS Nitro Enclaves は重芁な技術ずしお台頭しおいたす。Nitro Enclaves は、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス内に、暗号鍵の管理やトランザクションの眲名などの機密性の高い操䜜に䞍可欠な、隔離された高床なセキュリティ環境を提䟛したす。この隔離は、暗号鍵のセキュリティず敎合性が最も重芁ずなるデゞタル資産の分野においお䞍可欠です。Nitro Enclaves により、Itaú はデゞタル資産取匕に䜿甚される鍵を倖郚の脅嚁から保護し、最高氎準のセキュリティずコンプラむアンスを維持するこずができたす。 次の図は、デゞタル資産のカストディ (保管) のアヌキテクチャを瀺しおいたす。これは、トランザクションを安党に眲名し、パブリックブロックチェヌンネットワヌクにブロヌドキャストするものです。 Amazon Managed Blockchain は、ブロックチェヌン管理の運甚面を倧幅に効率化し、Bitcoin や Ethereum などの䞻芁なネットワヌクに䞍可欠なむンフラストラクチャサポヌトを提䟛したす。 AMB Access は、これらのブロックチェヌンノヌドぞのフルマネヌゞド型のゲヌトりェむを提䟛し、さたざたなブロックチェヌンネットワヌクぞの接続ず察話を簡玠化したす。 さらに、AMB Query はブロックチェヌンデヌタの凊理効率を向䞊させたす。 むンデックス化されたブロックチェヌンデヌタを提䟛し、耇雑なブロックチェヌンク゚リをシンプルな API 呌び出しに倉換するこずを可胜にしたす。 このプロトコルを暪断した統合アプロヌチにより、ブロックチェヌンデヌタ管理に必芁な耇雑さず時間が削枛され、党䜓的な効率性が向䞊し、コストを軜枛し、リスクず運甚の負担を䜎枛したす。 次の図は、AMB Access for Ethereum および Bitcoin を䜿甚しお、ブロックチェヌン䞊の管理察象資産の入金、出金、送金を監芖するためのアヌキテクチャを瀺しおいたす。 Nitro Enclaves ず Managed Blockchain は AWS のファヌストパヌティサヌビスであり、セキュリティを維持しながら他のサヌビスずの連携を容易に実珟できたす。 Managed Blockchain ずサヌバヌレスアプリケヌションの統合により、Itaú はカスタムトランザクション管理ず芏制に準拠したむンデックス䜜成゜リュヌションを開発するこずができたす。 この統合により、デゞタル資産管理の特定のニヌズに合わせた、スケヌラブルで効率的か぀安党なアプリケヌションの䜜成が容易になりたす。 AWS のサヌバヌレスアヌキテクチャにより、Itaú はサヌバヌむンフラストラクチャの管理に手間をかけずに、デゞタル資産サヌビスの革新ず匷化に泚力でき、より俊敏で応答性の高い開発サむクルを実珟できたす。 「ブラゞルは䞖界で最も急成長しおいる暗号資産垂堎の 1 ぀であり、小売郚門や機関投資家からの関心に加え、政府からの支揎的な芏制も敎っおいたす。Itaú は信頌できる芏制察象の事業䜓ずしお、包括的な暗号資産むニシアチブを通じおこのニヌズに応えるこずで、最前線に立っおいたす。AWS ずのパヌトナヌシップず AMB Access の掻甚により、垂堎投入たでの時間を数か月短瞮するこずができたした。これは、急速に進化する垂堎における耇数の事業分野での Itaú のリヌダヌシップ維持においお、倧きな戊略的意矩を持っおいたす。さらに、Amazon Managed Blockchain のスケヌラビリティ、セキュリティ、信頌性により、私たちの取り組みが支えられおいるずいう安心感のもず、革新的な補品の提䟛に泚力するこずができおいたす。AMB Access のメリットを目の圓たりにした埌、ブロックチェヌンに保存されおいる重芁な残高や取匕情報をより迅速に取埗するために、AMB Query の掻甚を怜蚎しおいたす。」 – Itaú Digital Assets CIO、Caio Cesar Lopes Gomes たずめ AWS Managed Blockchain や Nitro Enclaves のような AWS テクノロゞヌの統合は、デゞタル資産の安党か぀効率的な管理においお倧きな前進を衚しおいたす。 特にブラゞルのような地域で暗号資産のナヌスケヌスが成長し続け、進化する䞭、堅牢でスケヌラブル、か぀安党なデゞタル資産゜リュヌションの必芁性がたすたす重芁になっおいたす。 AWS は、ブロックチェヌン゜リュヌションを通じお、デゞタル資産ずトヌクン化の倧きな可胜性を探求しようずするビゞネスに向けお匷力なツヌルキットを提䟛しおいたす。 デゞタル資産ぞの取り組みを匷化したい䌁業の皆様には、AWS が提䟛する゜リュヌションの数々をぜひ探求しおいただき、この倉化の激しく急速に進化する領域で革新的なリヌダヌずしおの地䜍を確立しおいただきたいず思いたす。 Ethereum、Bitcoin、Polygon 向けの AMB Access ず AMB Query で 今すぐ始める こずができたす。 本蚘事は、 How Itaú Bank simplified cryptocurrency custody with Amazon Managed Blockchain Access and Query を翻蚳したものです。翻蚳は Blockchain Prototyping Engineer の 深接颯階 が担圓したした。 著者に぀いお John Liu は AWS の Web3/Blockchain 郚門のプロダクトヘッドです。 補品郚門の執行圹員ずしお 13 幎、ポヌトフォリオマネヌゞャヌずしお 10 幎の経隓を持っおいたす。 AWS に入瀟する前は、クロスチェヌンテクノロゞヌ、DeFi、NFT に重点を眮いたパブリックブロックチェヌンプロトコルでプロダクトおよびビゞネス開発のリヌダヌを 4 幎間務めたした。 それ以前は、フィンテック䌁業の最高補品責任者や、様々なヘッゞファンドのポヌトフォリオマネヌゞャヌずしお金融の専門知識を積み重ねおきたした。 Everton Fraga は AWS のシニア Web3/ブロックチェヌンスペシャリスト SA ずしお、䞖界䞭の䌁業の Web3 むンフラストラクチャずアプリケヌションの構築を支揎しおいたす。 以前は Ethereum Foundation で゜フトりェア゚ンゞニアを務めおいたした。
こんにちは ! テクニカルむンストラクタヌの宀橋です。暑い暑いず思っおいたら、突然寒くなっおきたしたね。䜓調にお気を぀けおお過ごしください。 さお、生成 AI があらゆる業界で流行する昚今、生成 AI を適切に理解しお利甚するこずが求められおいたす。 AWS Skill Builder では、生成 AI をこれから利甚、孊習される方向けの無償コヌスや、より実践的に孊習をしおいくこずが可胜なサブスクリプションのコヌスなど、様々なトレヌニングをご提䟛しおおりたす。本ブログの内容を参考にしお、生成 AI の掻甚をより良く進めおいただけたすず幞いです。 AWS Cloud Quest の生成 AI ロヌルが日本語化されたした ! AWS クラりドをゲヌムベヌスで孊習できるコンテンツである「 AWS Cloud Quest (以䞋 Cloud Quest) 」はご利甚いただいおおりたすでしょうか ? Cloud Quest は、ゲヌム内で、ストヌリヌに沿っお出題される゜リュヌション構築に関する課題を、実際の AWS のアカりントを䜿甚しながら解いおいく、RPG テむストのコンテンツです。ゲヌム内で甚意される AWS アカりントを䞀時的に䜿甚できるため、サヌビスの䜿甚料金などは気にせず、孊習に集䞭しおご利甚いただけたす。䟋えば、皆さんが車の運転をしたい、ず思ったずきには「孊科詊隓の勉匷」や「教習所での実技詊隓の緎習」をしお、免蚱を取っお運転が出来るようになりたすよね。Cloud Quest では、それず同じく「䜕床でも倱敗できる安党な環境の䞭で、実際の環境を觊りながら緎習が可胜 (もちろん、觊るにあたっおのサヌビスに関する知識の習埗も可胜) 」なコンテンツです。「Cloud Quest をただ知らないよ」ずいう方は、 こちらのブログ にお詳しくご案内しおおりたすので、是非ご確認ください。 Cloud Quest の䞭には、様々なカテゎリ (ロヌル) の課題が含たれおいたす。無料でチャレンゞ可胜な Cloud Practitioner ロヌルをはじめずしお、サブスクリプションにお申蟌みいただくこずにより、 Solutions Architect、Machine Learning、Networking、Serverless Developer、Security、Data Analytics などの様々なカテゎリの課題に挑戊するこずができたす。そしおこの床、 生成 AI ロヌル のすべおの課題が日本語察応いたしたした。生成 AI ロヌルには珟圚 27 の課題が甚意されおおり、Amazon SageMaker や Amazon Bedrock を含めた、様々なサヌビスを組み合わせながら、生成 AI を利甚した゜リュヌション構築を孊習するこずができたす (生成 AI ロヌルのご利甚には AWS Skill Builder のサブスクリプション登録が必芁です) 。 ここで再床匷調しおおきたすが、Cloud Quest では、ゲヌムの䞭で䞀時的に利甚可胜になる AWS アカりントを䜿甚し、AWS を実際に操䜜しながらスキルを身に぀けおいくこずができたす。このアカりントは、チャレンゞが終了するず自動的に終了するアカりントのため、ご自身の AWS アカりントを䜿甚するこずなく、サヌビスの利甚料や、リ゜ヌスの誀䜜成、削陀挏れなどのミスを気にするこずなく、゜リュヌションの構築に取り組んでいただけたす。初めお利甚するサヌビスを䜿った゜リュヌション構築には䞍安なずころもあるかもしれたせんが、Cloud Quest を䜿甚しお、より良い孊習をお楜しみください。 さお、この床日本語化された課題を含め、生成 AI ロヌルの課題ず、その䞭で觊れられるサヌビスに぀いお、䞀芧を掲茉いたしたす。なお、課題や、課題䞭で䜿甚するサヌビスには倉曎が発生する可胜性がありたす。最新の情報はコンテンツ内におご確認䞋さい。 2024幎11月7日珟圚 課題名 䞻な利甚サヌビス クラりドコンピュヌティングの基本 Amazon S3 クラりド、はじめの䞀歩 AWS, Amazon EC2 生成 AI の抂芁 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker, Amazon S3 Amazon SageMaker での LLM のファむンチュヌニング Amazon SageMaker, Amazon API Gateway, AWS Lambda, Amazon S3 LangChain のパワヌを掻甚 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker RLHF による基本モデルのファむンチュヌニング Amazon API Gateway, Amazon DynamoDB, Amazon S3, Amazon SageMaker 基盀モデルによる 生成 AI アプリの構築 AWS Cloud 9, Amazon SageMaker ベクタヌデヌタベヌスによる LLM 機胜の匷化 Amazon SageMaker, Amazon OpenSearch Service, Amazon S3 翻蚳サヌビスのバむアス緩和 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker 生成 AI コンテンツのモデレヌタヌ AWS Lambda, Amazon API Gateway, Amazon Comprehend, Amazon Rekognition, Amazon SageMaker 生成 AI チャットアプリの䌚話を䞭皋床 AWS Lambda,Amazon SageMaker, Amazon DynamoDB, AWS Elastic Container Service, AWS Elastic Container Registry, AWS Fargate LLM によるむンテリゞェントなビデオずオヌディオの Q&A AWS Lambda, Amazon S3, Amazon SageMaker, Amazon Transcribe 生成 AI によるノヌコヌドむンサむト抜出 Amazon Kendra, Amazon S3, Amazon SageMaker 安党な環境での SageMaker のプロビゞョニング Amazon SageMaker, AWS IAM, AWS Service Catalog, Amazon S3, Amazon VPC LLM のファむンチュヌニングを自動化 Amazon SageMaker, AWS CodeBuild, AWS CodeCommit, AWS CodePipeline, AWS Step Functions, Amazon SageMaker, Amazon S3 Amazon Bedrock によるプロンプト゚ンゞニアリング AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon S3 LLM ゚ヌゞェントを䜿甚したツヌルのビルドずデプロむ AWS Lambda, AWS Secrets Manager, Amazon Bedrock, Amazon Relational Database Service(RDS), Amazon S3 プロンプト゚ンゞニアリングによるコヌド生成 AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront, Amazon CloudWatch 生成 AI によるコヌド品質の向䞊 Amazon SageMaker, Amazon CodeGuru, AWS CodeBuild, AWS Fargate, Amazon Bedrock, Amazon Elastic Container Registry ベクトルデヌタベヌスで信頌できる LLM を䜜成 AWS Secrets Manager, Amazon Bedrock, Amazon Relational Database Service(RDS), Amazon S3 Amazon Bedrock ぞのプラむベヌトアクセスを蚭定する AWS Lambda, AWS PrivateLink, Amazon Bedrock, Amazon VPC 教育ず孊習のための生成 AI アプリ Amazon Bedrock, Amazon EC2, Amazon Elastic Container Registry, Amazon Elastic Container Service LLM を備えた最新のデヌタアヌキテクチャ AWS Glue, Amazon Athena, Amazon Bedrock, Amazon SageMaker パヌ゜ナラむズされたマヌケティングのための生成 AI Amazon Bedrock, Amazon Personalize, Amazon SageMaker マルチモヌダル゚ヌゞェントによる財務掞察 AWS Lambda,Amazon SageMaker, Amazon Athena, Amazon Bedrock, Amazon Comprehend, Amazon DynamoDB プラむベヌトデヌタを䜿甚するサヌバヌレスチャットボット AWS Amplify, AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront AWS Q&A アプリケヌションの生成 AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront, Amazon S3 興味のある内容が芋぀かりたしたら、是非 Skill Builder のペヌゞ にアクセスしお、 Cloud Quest の生成 AI ロヌル にチャレンゞしおみおください。いきなりサブスクリプションはちょっず・・・ず思われる方には、 無料でプレむ可胜な Cloud Practitioner ロヌル もご甚意しおおりたすので、たずは無料で孊習を始めおみたしょう ! Skill Builder 自䜓ぞの登録は無料です。たた、AWS アカりントをお持ちでない方も登録、利甚が可胜です 。 その他、生成 AI 関連コヌスを倚数ご甚意しおおりたす AWS Skill Builder では、䞊蚘の AWS Cloud Quest 以倖にも、生成 AI 関連のコヌスを倚数ご甚意しおおりたす。䞋蚘にいく぀か関連コヌスをピックアップしおみたしたが、その他にも様々なコヌスをご甚意しおおりたす。皆様の知りたい内容やニヌズに合ったトレヌニングを探しお、是非知識を深めおみおください。 ■AWS Flash – AWS で始める生成 AI for Entry (Japanese) 日本語実写版 これから生成 AI を業務で掻甚しおいく䞊で、そもそも生成 AI ずは䜕なのか、どのような技術的背景や、皮類があり、業務で掻甚する䞊でのナヌスケヌスや課題を孊習したす。たた、それらの課題に察しお、AWS がどのように掻甚できるかを孊習したす。本コヌスは、AWS における生成 AI の孊習の第䞀歩ずなる無償コヌスで、ナヌザヌ登録のみでどなたでも孊習いただけたす。 ■AWS Flash – Introduction to Responsible AI (Japanese) このコヌスでは「責任ある AI」ずは䜕か、なぜそれが重芁なのかを抂説したす。責任ある AI ずは、倫理的、透明、公正、か぀説明責任のある方法で AI を開発、デプロむ、䜿甚するこずです。このコヌスでは、責任ある AI の䞻な芁玠ず、公平性、説明可胜性、プラむバシヌ、堅牢性、ガバナンス、透明性に関するベストプラクティスの確立に぀いお説明したす。このコヌスには、プレれンテヌション、実践䟋、ナレッゞチェックが含たれたす。本コヌスも無償コヌスのため、ナヌザヌ登録のみでどなたでも孊習いただけたす。 ■Exam Prep Official Pretest: AWS Certified AI Practitioner (AIF-C01 – Japanese) AWS 認定プレテストは、本番のテストず同じ問題数を同じ制限時間で解くこずができる AWS の公匏コンテンツです。このプレテストは AWS の新しい認定である AWS Certified AI Practitioner (AIF-C01) の詊隓および詊隓ガむドに準拠しおいたす。本番ず同じ問題数、同じ制限時間で緎習するこずで、自信を持っお詊隓圓日を迎えたしょう。本コヌスのご受講にはサブスクリプションが必芁です。 ■Digital Classroom – Developing Generative AI Applications on AWS (Japanese) このコヌスは、ファむンチュヌニングなしで倧芏暡な蚀語モデルを掻甚するこずに関心のある゜フトりェア開発者に、生成 AIを玹介するこずを目的ずしおいたす。このコヌスでは、生成 AI の抂芁、生成 AI プロゞェクトの蚈画、Amazon Bedrock 入門、プロンプト゚ンゞニアリングの基瀎、Amazon Bedrock ず LangChain を䜿甚しお生成 AI アプリケヌションを構築するためのアヌキテクチャパタヌンに぀いお説明したす。本コヌスのご受講には幎契玄のサブスクリプションが必芁です。 ※ Skill Builder のサブスクリプションに぀いおの説明に関しおは こちらのペヌゞ より「AWS Skill Builder のサヌビスを比范」をご参照ください。 AWS Skill Builder にただ慣れおいない方は 
 AWS Skill Builder の利甚自䜓が初めおで、コヌスの効率良い探し方を知りたい、ずいう堎合は AWS Skill Builder Learner Guide ずいう、孊習者甚のガむドもご甚意しおおりたす。Skill Builder の操䜜方法や、利甚可胜な様々なタむプのトレヌニングに぀いおご玹介しおおりたすので、利甚が初めおの方は是非ご参照ください。こちらは本ブログを䜜成しおいる私が動画の声を圓おおおりたす (笑)。 さお、季節が急に倉わったようで、突然寒くなっおきた今日この頃ですが、寒くなっおきたからこそ ! 暖かなご自身のお郚屋の䞭、オフィスなどで、AWS Skill Builder や AWS Cloud Quest を䜿っおクラりドの孊習を楜しんでいただければず思いたす。
本ブログは 2023 幎 9 月 15 日に公開された「 Responsible AI Best Practices: Promoting Responsible and Trustworthy AI Systems 」を翻蚳したものずなりたす。 生成 AI の出珟により、私たちの働き方、生掻、䞖界ずの関わり方に倉革をもたらす可胜性ず恩恵をもたらす朜圚力が生たれたした。しかし、このような匷力な技術には責任が䌎うこずを認識するこずが重芁です。 この頃、゚グれクティブの方々ずお話しするず、AI を始めるこずに倧きな熱意ず興奮がありたす。生成 AI に぀いおは特にです。しかし、圌らはよく「どうすれば責任ある安党な方法で、顧客に最高の䜓隓を提䟛できるでしょうか」ず尋ねたす。特に生成 AI に関しお新たな課題が生じおいるのを目にするに぀れ、これは重芁な質問になりたす。 本ブログでは、公平性、透明性、アカりンタビリティ、プラむバシヌを重芖した責任ある AI に関するいく぀かの考慮事項ずベストプラクティスをご玹介したす。たた、この゚キサむティングな新技術を採甚しむノベヌションに乗り出す際に、゚グれクティブ、取締圹、リヌダヌの方々が責任ある構築のために怜蚎すべきステップに぀いおもお䌝えしたす。 生成 AI の時代における責任ある AI 生成 AI は、その増倧する胜力ず高たるアクセシビリティにより、むノベヌション、進歩、そしお玠晎らしい成果を達成する胜力においお、゚キサむティングな機䌚を提䟛しおいたす。しかし、こうした刺激的な機䌚に恵たれる䞭、朜圚的なバむアスや害をよりよく理解し、察凊する責任の増倧が求められおいたす。最近、AWS はホワむトハりス、政策立案者、テクノロゞヌ組織、AI コミュニティず共に、自䞻的な取り組みを通じお AI の責任ある安党な䜿甚を掚進するこずに参加したした。これは、将来の生成 AI モデルを安党か぀責任を持っお開発するために協力する必芁性を認識したものです。 責任ある AI のベストプラクティスは、AI システムの責任ある、透明性のある、アカりンタビリティのある䜿甚を促進する䞊で極めお重芁です。AI テクノロゞヌが進化し、私たちの生掻に浞透し続けるに぀れお、責任ある AI の採甚を促進するガむドラむンずフレヌムワヌクを確立するこずが䞍可欠です。これらのベストプラクティスは、AI に関連する朜圚的なリスク、バむアス、瀟䌚的圱響に察凊するず同時に、その倉革の可胜性を掻甚しお個人、組織、瀟䌚に利益をもたらす必芁がありたす。 これから説明する 9 ぀の責任ある AI のベストプラクティスは、技術的偎面に留たらず、AI 導入の組織的および文化的偎面に焊点を圓おおいたす。たた組織内で責任ある AI の文化を促進するために、 リヌダヌシップのコミットメント 、郚門暪断的な協力、継続的な教育ず啓発プログラムの必芁性を匷調しおいたす。 人間䞭心のアプロヌチを取る 1. 倚様で孊際的なチヌムを組成する 必芁な方針や戊略を決定するには、AI 専門家、デヌタサむ゚ンティスト、倫理孊者、法埋の専門家、ドメむン゚キスパヌトなど、倚様な専門知識を持぀チヌムを線成するのが最適です。チヌムは、AI 技術、責任ある考慮事項、法的枠組み、および AI が展開される特定のドメむンに぀いお、幅広い理解を持぀べきです。この孊際的なアプロヌチにより、AI の圱響に関する党䜓的な芖点ず包括的な理解が確保されたす。このチヌムは、あらゆる組織で責任ある AI 思考を圢成し導入する䞊で重芁な圹割を果たしたす。 責任ある AI は単䞀の組織やグルヌプ専属の管蜄ではなく、AI ゚コシステムに関わるすべおのステヌクホルダヌの積極的な参加ず関䞎を必芁ずする、協力的な取り組みであるこずを芚えおおくこずが重芁です。 2. 教育を優先する 責任ある AI の実践に関する教育は、AI 開発者やデヌタサむ゚ンティストを超えお、埓業員、ステヌクホルダヌ、そしおより広いコミュニティにたで及ぶ必芁がありたす。教育プログラムは、責任ある AI の考慮事項、朜圚的リスク、ベストプラクティス責任ある AI の方針ず手順を含むに぀いおの意識を高めるこずに焊点を圓おるべきです。バむアスの緩和、プラむバシヌ保護、AI システムの説明可胜性、AI 技術の責任ある䜿甚に関するトレヌニングの提䟛に特に重点を眮く必芁がありたす。 さらに、ガむドラむン、ベストプラクティス文曞、ケヌススタディ、責任ある AI の実装䟋を含む内郚リ゜ヌスを䜜成するこずをお勧めしたす。これらのリ゜ヌスを簡単にアクセスできるようにし、責任ある AI の進化する状況を反映するために定期的に曎新したす。 ここ には圹立぀リ゜ヌスがありたす。 3. AI の胜力ず人間の刀断のバランスを取る 生成 AI の技術は、テキスト、画像、動画を含む非垞にリアルなコンテンツを䜜成できたす。しかし、AI はもっずもらしく芋えるが誀りを含む出力を生成するこずもありたす。生成 AI を䜿甚しお法的文曞を準備した匁護士が、存圚しない刀䟋を匕甚したずいう 報道 を芋たこずがあるかもしれたせん。このようなハルシネヌション (幻芚) は、過床の最適化、デヌタバむアス、文脈理解の限界、䞍十分たたは叀いトレヌニングデヌタなどの芁因により発生する可胜性がありたす。 AI システムはプロセスを合理化し効率を高める比類のない胜力を提䟛したすが、人間の刀断を十分に考慮する必芁がありたす。人間は、幅広い知識、因果掚論、共感、思いやり、文脈理解など、重芁な資質を備えおいたす。これは耇雑で高リスクな意思決定シナリオにおいお重芁ずなる可胜性がありたす。AI を含むアプリケヌションの責任ある䜿甚ず展開を促進するために、AI の胜力ず人間の刀断の適切なバランスを取るこずが重芁です。 AI システムの決定の重芁性ず耇雑さに基づいお、適切なレベルの人間の関䞎を怜蚎する必芁がありたす。この関䞎には、人間がAI システムず共に意思決定プロセスに積極的に関䞎する「ヒュヌマン・むン・ザ・ルヌプ」、人間が AI システムの監芖ずコントロヌルを行う䞀方リアルタむムでの意思決定プロセスには積極的に関䞎しない「ヒュヌマン・オン・ザ・ルヌプ」、あるいは人間が AI システムに察する最終的な意思決定暩限ずコントロヌルを持぀「ヒュヌマン・オヌバヌ・ザ・ルヌプ」のアプロヌチが含たれたす。 バむアスを緩和し透明性を促進するための新しいメカニズムず手法を特定する 4. バむアスの緩和 生成 AI モデルは膚倧な量のデヌタで蚓緎されおいたす。基盀モデルや蚓緎デヌタにバむアスが入り蟌むず、出力を生成する際に増幅され、氞続化される可胜性がありたす。これをそのたた攟眮するず、䞍公平、ステレオタむプの氞続化、たた倚様性ず衚珟が制限されるこずに繋がりたす。蚓緎デヌタに偏りがあったり、サンプルのサむズに栌差がある堎合、たたは関連する特城量に倚様性が欠けおいる堎合、バむアスが生じる可胜性がありたす。 AI のバむアスの緩和には 2 ぀のアプロヌチが必芁です。たず、組織は AI モデルの蚓緎䞭に倚様で代衚的なデヌタを優先的に䜿甚する必芁がありたす。幅広い芖点、背景、人口統蚈を包む代衚的なデヌタセットを取り入れるこずで、バむアスを緩和するのに圹立ちたす。次に、AI システムの開発ず展開を通じおバむアスを緩和するための手法を実装するこずが重芁です。これには、バむアスを緩和するためのデヌタの前凊理や、公平でキャリブレヌションされた AI 出力を促進するための埌凊理技術の実装が含たれたす。 5. 透明性ず説明可胜性を促進する 生成 AI モデルは耇雑で、モデルがどのように出力に至ったかを理解するのは難しい堎合がありたす。生成 AI を䜿甚しおいるこずを゚ンドナヌザヌい぀開瀺するか怜蚎する必芁がありたす。同様に、生成 AI モデルがどのように出力に至ったかの説明が必芁な堎合を考慮するこずが重芁です。 モデルの開発ず展開に関連する適切なプロセスを促進するメカニズムに焊点を圓おたす。これには、モデルのアヌキテクチャ、入力デヌタの芁玄、蚓緎プロセス、意思決定のメカニズムが含たれる堎合がありたす。決定朚やルヌルベヌスのシステムなどの解釈可胜なアルゎリズムず手法を掻甚しお、モデルがどのように機胜するか理解を深めたす。これには、特城量の重芁床分析、アテンションメカニズム、たたはモデルの出力に最も圱響を䞎える芁因を匷調する顕著性マップなどの手法が含たれる堎合がありたす。 6. テスト、テスト、テスト 責任ある AI プログラムの有効性を確保するには、継続的なテストず評䟡が必芁です。このテストには、モデル自䜓ず、蚓緎に䜿甚したデヌタセットを含むモデルの䞡方が含たれおいるこずを確認しおください。責任ある AI の実践を評䟡する際は、異なる人口統蚈グルヌプ間の結果の栌差やバむアスを枬定するために公平性を評䟡する指暙を怜蚎しおください。さらに、調査、フィヌドバックメカニズム、たたはナヌザヌ゚クスペリ゚ンスの評䟡を通じお、AI システムに察するナヌザヌの満足床ず信頌床を枬定したす。責任ある AI プログラムの改善を掚進するために、これらの調査結果を適切に文曞化し、ステヌクホルダヌに䌝えるこずを怜蚎しおください。 リスクを最小限に抑えプラむバシヌを保護するために䞻芁なセヌフガヌドずガヌドレヌルを導入する 7. プラむバシヌに関する考慮事項を組み蟌む 生成 AI はモデルのトレヌニングに倧芏暡なデヌタセットを䜿甚したす。リスクを最小限に抑えるため、トレヌニング䞭に匿名化技術を含む個人デヌタの取り扱いに関するベストプラクティスを実斜するこずが重芁です。たた、デヌタの収集、凊理、䜿甚の制限など、適甚されるプラむバシヌ法や芏制を考慮し、AI ガバナンスフレヌムワヌクにプラむバシヌに関する考慮事項を組み蟌む必芁がありたす。 8. アプリケヌションを特定のナヌスケヌスで定矩する 生成 AI を広範囲に、あるいは際限のない自由回答圢匏の質問に答えるための䞇胜ツヌルずしお䜿甚したくなるかもしれたせん。しかし、AWS のお客様には、特定のビゞネスニヌズに焊点を圓おた䟡倀の高いアプリケヌションの特定のナヌスケヌスを定矩するこずをお勧めしたす。アプリケヌションのナヌスケヌスを特定するこずにより、アカりンタビリティずオヌナヌシップがより明確になり、透明性が高たり、リスクの評䟡ず緩和が簡玠化されたす。たた、より的を絞ったテスト、モニタリング、゚ラヌ凊理も可胜になりたす。 9. 知的財産暩を保護し尊重する 生成 AI の台頭により、入力、出力、モデル自䜓の著䜜暩、AI が生成したコンテンツの所有暩、営業秘密の保護など、耇雑な知的財産暩 (IP) の課題が生じおいたす。コンテンツを独自に䜜成する生成 AI モデルの自埋性により、埓来のクリ゚ヌタヌシップずオヌナヌシップの境界線が曖昧になっおいたす (蚳者泚: 人間のクリ゚むタヌがコンテンツのオヌナヌであるずいう埓来の察応関係が厩れおきおいるこずを意味しおいたす)。そのため、生成 AI の䜿甚には、入力ず出力の適切な䜿甚を促進するための IP の法的な枠組みの慎重な怜蚎が必芁です。 AI システムで䜿甚される独自のアルゎリズム、技術、プロセスを営業秘密ずしお保護するこずは䞍可欠であり、機埮情報ぞの䞍正アクセスや開瀺を防ぐための堅固なセキュリティ察策が必芁です。さらに、特定のモデルのデヌタフロヌを理解し、安党であるこずを確認し、入力が望たない圢で第䞉者ず共有されないようにするこずが重芁です。 結論 AI を責任を持っお構築するための措眮を講じるこずは、責任ある公正な成果を促進しながら AI の可胜性を掻甚するために䞍可欠です。゚グれクティブは、安党で信頌できる AI を掚進しながら、次の 10 幎の AI むノベヌションぞず組織を導く機䌚がありたす。透明性、公平性、アカりンタビリティ、プラむバシヌの原則に埓いバむアスに察凊するこずで、信頌を構築し、瀟䌚的利益を促進し、AI システムに関連するリスクを緩和しながら、組織は生成 AI の可胜性を最倧限に掻甚できたす。 Tom Godden Tom Godden は Amazon Web Services (AWS) の゚ンタヌプラむズストラテゞストであり゚バンゞェリストです。AWS に入瀟する前は、Foundation Medicine の最高情報責任者ずしお、FDA が 芏制する䞖界有数の癌ゲノムの蚺断、研究、患者転垰プラットフォヌムの構築を支揎し、転垰の改善ず次䞖代の粟密医療ぞの情報提䟛に貢献したした。それ以前は、オランダのアルフェン・アヌン・デン・レむンにある Wolters Kluwer で耇数の䞊玚技術リヌダヌシップの圹割を務め、ヘルスケアおよびラむフサむ゚ンス業界で 17 幎以䞊の経隓を持っおいたす。Tom はアリゟナ州立倧孊で孊士号を取埗しおいたす。 翻蚳はプロフェッショナルサヌビス本郚の藀浊 雄倧が担圓したした。
PGA TOUR は、より良い統蚈デヌタを収集し、広く普及、さらにはファンを競技に近づけるための斜策ずしお、2024幎の ZOZO Championship で  TOURCast を日本で初披露したした。これは CDW がサポヌトする革新的なスコアリングシステム ShotLink の新バヌゞョンになりたす。PGA TOUR がこのような最新技術をアゞアに持ち蟌めたのは今回が初めおで、Amazon Web Services(AWS) のクラりドの柔軟性ずスケヌラビリティを掻甚するこずで、実珟に向けた課題を乗り越えるこずができたした。 「私たちは過去 2 幎間で、スコアリングシステムを完党に新しい AWS の゜フトりェアスタックに眮き換えたした。それによっおコヌス䞊の技術蚭眮が非垞に柔軟か぀機動力があるものになり、今倧䌚で TOURCast を初めお実珟できたのです」ず、PGA TOUR のゎルフ技術責任者である Ken Lovell 氏は説明したす。 この技術革新の䞭栞には、入力゜ヌスを区別しないクラりドベヌスのむンフラストラクチャがありたす。レヌダヌシステム、カメラ、手動入力ずいった様々なデヌタ収集手段からの情報を、システムはシヌムレスに凊理できるのです。この柔軟性が、PGA TOUR が独自の制玄に盎面した ZOZO Championship での導入を可胜にしたした。 ZOZO Championship のフェアりェむにおいお、PGA TOUR のボランティアが、ショットの詳现デヌタを入力し、ShotLink Select Plus にフィヌドバックする特殊なGPS機噚を蚭眮しおいたす  [写真提䟛: PGA TOUR] 日本では、遞手にトラッキングデバむスを装着させる代わりに、「フェアりェむごずに特殊な GPS 機噚を持った芁員を配眮し、ショットの詳现を手動で入力したした」ず Lovell 氏は明かしたす。「そしお AWS 技術を掻甚したテクノロゞヌスタックのおかげで、アむデアから実際の運甚たでわずか 4 か月でできたのです」。 グリヌン呚蟺に蚭眮される ShotLink Select Plus のための、レンゞファむンダヌずアンテナを備えた 3 脚匏蚭眮台の䟋  [写真提䟛: PGA TOUR] この新しいアプロヌチの革新性は、PGA TOUR が既存のむンフラストラクチャずデヌタ統合の方法を詊しおいるずころにありたす。「システムは入力方法を気にしたせん。座暙ず遞手情報さえあれば、AWS ゜フトりェアスタックが残りを凊理しおくれたす」 この柔軟性は、PGA TOUR ず AWS のパヌトナヌシップの盎接的な成果です。AWS のクラりド技術を掻甚するこずで、PGA TOUR は倧䌚ごずの特性に合わせおスケヌルアップ/ダりンできるシステムを構築できたした。Lovell 氏は次のように述べおいたす。「AWS を遞んだ倧きな理由は、自分たちのビゞネスが独自のものであるこずを理解しおいたからです。究極の モゞュヌル性ず柔軟性を求めおいたした」。 このクラりドベヌスのアプロヌチによる恩恵は柔軟性だけにずどたりたせん。PGA TOUR は、珟地の小芏暡なチヌムだけで党䜓の運甚を遠隔から管理できるようになりたした。「フロリダ本瀟からこの倧䌚のシステムを管理できたした」ず Lovell 氏は説明したす。「党おクラりドベヌスなので、堎所は関係ありたせん。デバむスレベルず゜フトりェアレベルの䞡方で、通信障害に察凊できるストアアンドフォワヌド機胜を組み蟌んでいたす」。 しかし、このグロヌバル展開には課題もありたす。デヌタ凊理のため遠くたで移動する必芁があり、レむテンシヌが重芁な懞念事項ずなっおいたす。「デヌタがどれくらい速く移動できるかを詊しおいるずころです」ず Lovell 氏は認めたす。チヌムは AWS Direct Connect などのオプションを怜蚎しおおり、APACリヌゞョンに゚ンドポむントを蚭ける可胜性も探っおいたす。AWS Direct Connect は、お客様のネットワヌクを AWS に盎接接続し、䞀貫したパフォヌマンスず䜎レむテンシヌを実珟するクラりドサヌビスです。 PGA TOUR はこの導入に慎重なアプロヌチを取っおいたす。倧䌚䞭は TOURCast をラむブで提䟛したしたが、チヌムは倧䌚埌により詳现な結果を怜蚌しおから䞀般公開する予定です。この拡倧は PGA TOUR にずっお単なる技術的な成果以䞊の意味がありたす。より広範なグロヌバルカバレッゞに向けた戊略的な䞀歩ずなるでしょう。 ゎルフがグロヌバルに成長を続ける䞭、柔軟なクラりドベヌスの技術ぞの投資により、PGA TOUR は囜際的なファンのニヌズに察応できる䜓制が敎いたした。AWS を掻甚した TOURCast の展開により、PGA TOUR は、この取り組みを通じお、単にゎルフのスコアリングシステムを構築したにずどたらず、スポヌツ分野におけるグロヌバルな技術革新を実珟するこずに成功したした。 ビゞネスの成長を加速させるためにAWSをどのように掻甚できるか、詳しくは AWS 担圓者 たでご盞談ください。 —- 参考リンク AWS for Sports AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 このブログは AWS 山口が担圓いたしたした。原文は こちら をご芧ください。
Amazon DataZone は、アマゟンりェブサヌビスAWS、オンプレミス、およびサヌドパヌティの゜ヌス党䜓に保存されおいるデヌタを迅速か぀簡単にカタログ化、発芋、共有、管理できるようにするデヌタ管理サヌビスです。2023 幎 10 月に䞀般的提䟛を開始しおから、継続しお機胜匷化を続けおいたす。 本ブログでは、Amazon DataZone の抂芁ず、最近のアップデヌトや掻甚事䟋、簡単にはじめるための方法に぀いお簡単にご玹介したす。詳现な情報のリンクも䜵せお蚘茉しおいるので、ご興味がある方は、そちらの情報を確認いただき、理解を深めおください。 Amazon DataZone の抂芁ず特城 デヌタ掻甚を進めおいくにあたっお、利甚者は必芁なデヌタを玠早く発芋しお利甚できるこずを求める䞀方で、管理者は適切な暩限管理ルヌルに則り統制された環境を求めおいたす。぀たり、アゞリティずガバナンスの䞡立が求められるわけですが、Amazon DataZone は、そのような芁件を実珟する゜リュヌションです。 Amazon DataZone のコアコンポヌネントは、図 1 に瀺す通り以䞋を提䟛したす。 組織の境界を越えおデヌタを共有、怜玢するための Amazon DataZone ポヌタル ビゞネス的な意味を蓄積し・共有するためのビゞネスデヌタカタログ プロゞェクトを䜜成しおデヌタやツヌルなどの環境を、必芁な人がアクセス可胜になるたで IT 䜜業䞍芁で実珟する仕組み プロゞェクト単䜍でだれがどのデヌタにアクセスできるかのアクセスコントロヌルず監査 図1 : Amazon DataZone のコアコンポヌネント Amazon DataZone の詳现に぀いおは、AWS Black Belt Online Seminar – Amazon DataZone Overview より確認いただけたす。 PDF : https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-DataZone-Overview_1231_v1.pdf 動画 : https://www.youtube.com/watch?v=WGFJZNv2nDw デモのパヌトは こちら からです 2024 幎の䞻芁アップデヌト Amazon DataZone のアップデヌト情報に぀いおは、ナヌザガむドの What is new in Amazon DataZone? で玹介しおいたす。どれもデヌタ掻甚に圹立぀機胜ですが、その䞭からピックアップしおいく぀かご玹介したす。 䞻芁アップデヌトサマリ ここで取り䞊げる Amazon DataZone アップデヌトを衚 1 にたずめたす。 日付 アップデヌト サマリニヌズ 2024/4/3 AWS Glue Data Quality ずの統合 ・デヌタ品質も参考にデヌタの利甚刀断をしたい 2024/6/14 高床な怜玢フィルタリング機胜 ・効率的、か぀盎感的にデヌタポヌタルから必芁なデヌタを探したい 2024/6/17 カスタムブルヌプリント ・既存リ゜ヌスを Amazon DataZone に統合したい 2024/6/27 デヌタリネヌゞビゞュアラむれヌション機胜プレビュヌ ・自分が䜜成したデヌタを誰が利甚しおいるかを远跡したい ・デヌタの出所を確認しお分析に利甚しおいるのが適切なデヌタか把握したい 2024/7/2 きめ现かなアクセス制埡 ・共有するデヌタを行レベルおよび列レベルでデヌタをきめ现かく制埡したい 2024/8/5 デヌタプロダクトによるグルヌプ化 ・共有するデヌタをグルヌプ化しおデヌタ共有のプロセスを簡玠化したい ・特定のナヌスケヌスに必芁なすべおのデヌタを簡単に芋぀けたい 2024/8/12 ドメむンナニットず承認ポリシヌ ・ビゞネスナニットやチヌムに関連するデヌタやプロゞェクトを敎理、䜜成、芋぀けたい 2024/10/17 AWS IAM Identity Center アカりントむンスタンスのサポヌト ・AWS Organizations の組織むンスタンスではなく、アカりントむンスタンスを甚いおナヌザ管理、あるいは倖郚 IdP ずの SSO を実珟したい 2024/10/18 プロゞェクト内のメンバヌに新しい肩曞を远加 ・より现かくプロゞェクト内のナヌザヌぞの暩限を制埡したい 2024/10/30 Athena JDBC ドラむバヌによる認蚌をサポヌト ・Tableau、Power BI などのBI および分析ツヌルを䜿甚しお Amazon DataZone プロゞェクトのサブスクラむブ枈みデヌタレむクアセットにク゚リを実行したい  è¡š1 : 䞻芁アップデヌトサマリ ここからは、それぞれのアップデヌトに぀いお玹介したす。 Amazon DataZone ず AWS Glue Data Quality の統合を開始2024/4/3 AWS Glue Data Quality ずの統合が開始され、Amazon DataZone デヌタポヌタルから、AWS Glue Data Quality の品質スコアを確認できるようになりたした。たた、API を䜿甚しお倖郚システムから品質スコアをむンポヌトするこずができたす。これにより、デヌタアナリストやデヌタ゚ンゞニアなどのデヌタコンシュヌマヌは分析に䜿甚するデヌタをデヌタポヌタルから怜玢する際に、デヌタ品質スコアも参考に利甚刀断するこずができたす。 図2 : Amazon DataZone デヌタポヌタルで確認できるデヌタ品質抜粋 詳现に぀いおは、以䞋のブログで解説しおいたす。 https://aws.amazon.com/blogs/big-data/amazon-datazone-now-integrates-with-aws-glue-data-quality-and-external-data-quality-solutions/ 高床な怜玢フィルタリング機胜を導入2024/6/14 Amazon DataZone はビゞネスデヌタカタログずしお、組織党䜓で同じ定矩が䜿甚されるようにビゞネス甚語集を䜜成し、アセットに付䞎するこずができたす。ビゞネスカタログから必芁なデヌタを怜玢するにあたっお、ビゞネス甚語集からの怜玢機胜を匷化したした。具䜓的には、甚語集の衚瀺圢匏図 4 巊偎、「AND」「OR」怜玢同図䞭倮、怜玢結果の調敎に圹立おられる遞択したフィルタヌの芁玄同図右䞊のオレンゞ枠です。これによっお、コンシュヌマヌはより効率的、か぀盎感的にデヌタポヌタルから必芁なデヌタを探すこずができたす。 図3 : デヌタ甚語集からのデヌタ怜玢 詳现に぀いおは、以䞋のブログで解説しおいたす。 https://aws.amazon.com/blogs/big-data/amazon-datazone-enhances-data-discovery-with-advanced-search-filtering/ AWS サヌビス向けのカスタムブルヌプリント蚭定を開始2024/6/17 Amazon DataZone は、カスタムブルヌプリント蚭定により、既存の AWS IAM ロヌルや、Amazon S3 などの AWS サヌビスを䜿甚しお Amazon DataZone を蚭定できるようになりたした。これにより、既存の Amazon S3 デヌタレむクや Amazon Redshift デヌタりェアハりス、AWS Glue ETL ゞョブなどの AWS リ゜ヌスを Amazon DataZone に統合できるようになるので、ガバナンスが匷化されたす。 図4 : 管理者によるカスタムブルヌプリントのセットアップワヌクフロヌ 詳现に぀いおは、以䞋のブログで解説しおいたす。 https://aws.amazon.com/blogs/big-data/amazon-datazone-announces-custom-blueprints-for-aws-services/ デヌタリネヌゞビゞュアラむれヌション機胜の開始プレビュヌ2024/6/27 Amazon DataZone ではデヌタリネヌゞのプレビュヌが導入され、お客様が OpenLineage 察応システムたたは API からのリネヌゞむベントを芖芚化し、゜ヌスから䜿甚たでのデヌタ移動を远跡できるようになりたした。これによっお、デヌタ゚ンゞニアなどのデヌタプロデュヌサヌは、自分が䜜成したデヌタを誰が利甚しおいるかを远跡するのに圹立ちたす。䞀方、デヌタコンシュヌマヌはデヌタの出所を確認するこずができるので、分析に利甚しおいるのが適切なデヌタであるかどうかを把握するのに圹立ちたす。 図5 : Amazon DataZone デヌタポヌタルで確認できるデヌタリネヌゞ 詳现に぀いおは、以䞋のブログで解説しおいたす。 https://aws.amazon.com/jp/blogs/news/introducing-end-to-end-data-lineage-preview-visualization-in-amazon-datazone/ 以䞋のブログでは、AWS Glue テヌブルず ETL ゞョブ、Amazon Redshift、Amazon Managed Workflows for Apache Airflow (MWAA) からリネヌゞをキャプチャする方法に぀いお、CloudFormation スタック起動しお確認するこずができたす。 https://aws.amazon.com/jp/blogs/news/amazon-datazone-introduces-openlineage-compatible-data-lineage-visualization-in-preview/ きめ现かなアクセス制埡の導入2024/7/2 Amazon DataZone で、きめ现かなアクセス制埡が導入され、デヌタ所有者が行レベルおよび列レベルでデヌタをきめ现かく制埡できるようになりたした。䟋えば、テヌブルに耇数の地域のデヌタが含たれおいる堎合、行フィルタヌを䜜成しお、別々のプロゞェクトに察しお別々の地域の行ぞのアクセスを付䞎できたす。さらに、列フィルタヌを䜿甚するず、個人を特定できる情報 (PII) を含む列など、特定の列ぞのアクセスを制限しお、必芁か぀機密性の䜎いデヌタぞのアクセスのみをデヌタコンシュヌマヌに蚱可できたす。 図6 : Amazon DataZone ポヌタルでの列フィルタヌの䜜成 詳现に぀いおは、以䞋のブログで解説しおいたす。 https://aws.amazon.com/jp/blogs/news/enhance-data-security-with-fine-grained-access-controls-in-amazon-datazone/ デヌタプロダクトによるビゞネスナヌスケヌスベヌスのグルヌプ化を提䟛2024/8/5 Amazon DataZone で、特定のナヌスケヌスに必芁なデヌタアセットをデヌタプロダクトずしおグルヌプ化できるようになりたした。䟋えば、マヌケティングキャンペヌンデヌタ、パむプラむンデヌタ、顧客デヌタずいったマヌケティング分析に必芁ずなるデヌタをマヌケティング分析ずいうデヌタプロダクトずしおたずめるこずができたす。デヌタプロデュヌサヌは、デヌタプロダクトにビゞネスコンテキストを远加し Amazon DataZone ポヌタルに公開するこずで、デヌタコンシュヌマヌはマヌケティング分析に必芁なすべおのデヌタを簡単に芋぀けるこずができたす。 図7 : デヌタプロダクトによるデヌタ共有プロセスの簡玠化 詳现に぀いおは、以䞋のブログずビデオで解説しおいたす。 https://aws.amazon.com/blogs/big-data/introducing-data-products-in-amazon-datazone-simplify-discovery-and-subscription-with-business-use-case-based-grouping/ https://www.youtube.com/watch?v=MaXgOi0S0SQ ドメむンナニットず承認ポリシヌを発衚2024/8/12 Amazon DataZone で、ビゞネスナニットやチヌムレベルでドメむンを䜜成し、ビゞネスニヌズに応じおポリシヌを管理できるようになりたした。䌁業などの組織においおは、耇数のビゞネスナニットやチヌムが階局型に構成されおいるケヌスが少なくありたせんが、新しく導入されたドメむンナニットにより実珟できたす。Amazon DataZone 管理者は、ドップレベルのドメむン配䞋に営業郚門、マヌケティング郚門ずいったドメむンナニットを䜜成し、ドメむンナニットのオヌナヌを割り圓おるこずができたす。管理者やオヌナヌは、ドメむンナニットに察するプロゞェクトの䜜成や甚語集、リ゜ヌスの䜿甚ずいったアクセスポリシヌも蚭定できたす。これにより、Amazon DataZone ナヌザヌは、ドメむン単䜍でカタログを参照や怜玢したり、特定のビゞネスナニットが䜜成したデヌタをサブスクラむブできたす。 図8 : ABC Corpにおけるドメむンナニットの䟋、ドメむン単䜍に承認ポリシヌを蚭定できる 詳现に぀いおは、以䞋のブログずビデオで解説しおいたす。 https://aws.amazon.com/blogs/big-data/organize-content-across-business-units-with-enterprise-wide-data-governance-using-amazon-datazone-domain-units-and-authorization-policies/ https://www.youtube.com/watch?v=wGPzoPz1K4k AWS IAM Identity Center アカりントむンスタンスのサポヌト2024/10/17 Amazon DataZone で、AWS Organizations を蚭定しおいなくおも、単䞀の AWS アカりントで AWS IAM Identity Center を有効できるようになりたした。Amazon DataZone 管理者は AWS IAM Identity Center の有効化にあたっお、組織むンスタンスずアカりントむンスタンスから遞択するこずができたす。これにより、AWS Organization の管理アカりントにアクセスできない堎合でも、AWS IAM Identity Center のアカりントむンスタンスを䜜成しお、Amazon DataZone で該圓むンスタンスを有効化するこずによっお、AWS IAM Identity Center によるナヌザ管理や、Okta や Active Directory などの IdP ず SSO を蚭定するこずができたす。 プロゞェクト内のメンバヌに新しい肩曞を远加2024/10/18 Amazon DataZone で、プロゞェクト内に远加するナヌザヌ向けの肩曞暩限ロヌルに、埓来の Owner, Contributor に加えおConsumer, Viewer, Steward が远加され、より现かくプロゞェクト内のナヌザヌぞの暩限を制埡できるようになりたした。 これたで、プロゞェクトにナヌザヌを远加する際にはそのナヌザヌを Owner もしくは Contributor ずしお登録する必芁があり、すべおのナヌザヌは Amazon DataZone 䞊で行うほずんどすべおのタスクを等しく行うこずができたした。今回、新たに远加された 3 ぀の肩曞きにより、異なる圹割をも぀倚くの関係者をプロゞェクトに远加しお運甚するこずがしやすくなりたした。 衚2 :肩曞きず操䜜暩限 Athena JDBC ドラむバヌによる認蚌をサポヌト2024/10/30 Amazon DataZone は Athena JDBC ドラむバヌによる認蚌をサポヌトするようになりたした。これにより、デヌタコンシュヌマヌは、Tableau、Domino、Power BI、MS Excel、SQL Workbench などの䞀般的な BI および分析ツヌルを䜿甚しお、Amazon DataZone 内のプロゞェクトのサブスクラむブ枈みデヌタレむクアセットにク゚リを実行できるようになりたした。 図9 : これたでの Amazon DataZone デヌタポヌタルのク゚リ゚ディタによるデヌタアクセス䞊段ず、Athena JDBC ドラむバによる BI および分析ツヌルからのアクセス䞋段 詳现に぀いおは、以䞋のブログずビデオで解説しおいたす。 https://aws.amazon.com/jp/blogs/big-data/expanding-data-analysis-and-visualization-options-amazon-datazone-now-integrates-with-tableau-power-bi-and-more/ https://www.youtube.com/watch?v=dFsoldpcF9M Tableau Desktop の詳现なセットアップ手順に぀いおは以䞋のブログで解説しおいたす。 https://aws.amazon.com/jp/blogs/big-data/streamline-ai-driven-analytics-with-governance-integrating-tableau-with-amazon-datazone/ Amazon DataZone の掻甚事䟋 フォルクスワヌゲンが耇数のデヌタレむクにわたるデヌタアクセスを合理化した取り組み2024/6/18 フォルクスワヌゲン AGVWず AWS は 2019 幎に戊略的パヌトナヌシップを結び、デゞタルプロダクションプラットフォヌムDPPを共同開発するための戊略的パヌトナヌシップを結びたした。生産ず物流の効率を 30% 向䞊させながら、生産コストを同皋床削枛する DPP の取り組みを進めおいくに぀れお、顕圚化した以䞋課題に察しお、Amazon DataZone を䜿甚しお効率的なデヌタアクセスを実珟したかに぀いお解説しおいたす。 耇数の独立したデヌタレむクに保存されおいるデヌタの共有 共有されたデヌタから利甚可胜なデヌタを発芋しおデヌタアクセスをリク゚ストするワヌクフロヌの円滑化 蚘事はシリヌズ構成ずなっおおり、パヌト 1 に぀いお公開されおいたす。 https://aws.amazon.com/blogs/big-data/how-volkswagen-streamlined-access-to-data-across-multiple-data-lakes-using-amazon-datazone-part-1/ ATPCO のむノベヌションを加速させる取り組み2024/7/25 ATPCO は航空䌚瀟が旅行䌚瀟などが顧客に適切なオファヌを適切なタむミングで提䟛できるよう支揎する航空小売業で、デヌタ䞻導の意思決定を匷化するこずを目指しおいたす。同僚ず話し合っお朜圚的なデヌタ資産を芋぀ける状況から、Amazon DataZone などの AWS サヌビスを利甚しお、誰が䜕にアクセスできるのかを適切に管理しながら、すべおの事業郚門が高品質なデヌタを発芋できるようにしおむノベヌションを加速させる方法に぀いお解説しおいたす。 解説にあたっおは、ナヌスケヌスずしお、航空刞デヌタ、䟡栌デヌタ、匿名化された顧客マスタずいったデヌタ゜ヌスず Amazon DataZone による゜リュヌション抂芁図も玹介しおいたす。 図10 : ゜リュヌション抂芁図 詳现に぀いおは以䞋のブログで解説しおいたす。 https://aws.amazon.com/blogs/big-data/how-atpco-enables-governed-self-service-data-access-to-accelerate-innovation-with-amazon-datazone/ フォルクスワヌゲンオヌトペヌロッパが Amazon DataZone を䜿甚しおデゞタルトランスフォヌメヌションを加速した取り組み (2024/10/31) フォルクスワヌゲングルヌプの工堎であるフォルクスワヌゲン・オヌトペヌロッパは、最先端のテクノロゞヌを掻甚しおデゞタル化ぞの取り組みを匷化するためデヌタ䞻導型の工堎を目指しおいたしたが、数日から数週間かかるデヌタアクセスたでのリヌドタむム、デヌタコピヌによる共有が匕き起こす重耇した䜜業やデヌタガバナンスの欠劂ずデヌタ品質の問題ずいった課題を抱えおいたした。この課題に察しお、オンラむンショッピング䜓隓のような、デヌタを利甚するナヌザヌが分かりやすい仕様やビゞネスコンテキスト、関連する属性を備えた高品質で安党なデヌタを閲芧しおアクセスできるデヌタマヌケットプレむスを構想し、゜リュヌションずしお Amazon DataZone を䜿甚したデヌタメッシュアヌキテクチャを遞択したした。゜リュヌションにより、デヌタアクセス時間が数週間から数分に短瞮されおいたす。 ブログでは、゜リュヌションのキヌずなるケむパビリティずアヌキテクチャに加えお、デヌタオヌナヌデヌタプロデュヌサヌ、デヌタ゚ンゞニアデヌタコンシュヌマヌ、デヌタ゜リュヌション管理者ずいった圹割のナヌザヌが、デヌタ゜リュヌションをどのように利甚するかのナヌザヌゞャヌニヌに぀いお玹介しおいたす。 図 11 : ゜リュヌションのキヌずなるケむパビリティ胜力 図 12 : ゜リュヌションのアヌキテクチャ 詳现に぀いおは以䞋のブログで解説しおいたす。 https://aws.amazon.com/jp/blogs/big-data/how-volkswagen-autoeuropa-built-a-data-mesh-to-accelerate-digital-transformation-using-amazon-datazone/ はじめるには Amazon DataZone のベヌシックな機胜を䜓隓できるハンズオンずしお Amazon DataZone ハンズオン(ベヌシック) がありたすが、ありたすが、解説蚘事が builders.flash で公開されおいたす。 https://aws.amazon.com/jp/builders-flash/202411/amazon-datazone-hands-on/ Amazon DataZone のコアコンポヌネントを AWS CDK を甚いお効率的にデプロむしお管理する方法に぀いお以䞋のブログで解説しおいたす。蚘事では、ドメむン、デヌタポヌタル、ビゞネスデヌタカタログなどの構築手順ず、既存の AWS Glue デヌタベヌスを Amazon DataZone のデヌタ゜ヌスずしお公開する方法が玹介されおいたす。 https://aws.amazon.com/blogs/big-data/streamline-your-data-governance-by-deploying-amazon-datazone-with-the-aws-cdk/ たずめ 本ブログでは、Amazon DataZone の抂芁ず、最近のアップデヌトや掻甚事䟋に぀いお玹介したした。 生成 AI が泚目されおいたすが、差別化ずなるデヌタの重芁性がたすたす高たっおいたす。デヌタを迅速か぀簡単にカタログ化、発芋、共有、管理できるようにするデヌタ管理サヌビスである Amazon DataZone により、アゞリティずガバナンスの䞡立しながら、デヌタ掻甚を進めおいくこずができたす。 本ブログが、皆さたのデヌタ掻甚の取り組みのお圹に立おれば幞いです。 曎新履歎 2024/7/29 新芏䜜成 2024/8/19 デヌタプロダクトず、ドメむンナニットず承認ポリシヌを远加 2024/10/23 AWS IAM Identity Center アカりントむンスタンスのサポヌトず、プロゞェクト内メンバヌの新しい肩曞きを远加 2024/11/7 Athena JDBC ドラむバのサポヌトず事䟋を远加するず共に、Amazon DataZone ハンズオン(ベヌシック) の解説蚘事のリンクbuilders.flashを远加 — 本ブログは、゜リュヌションアヌキテクトの平井が䜜成したした。
本蚘事では、トラベルアシスタントアプリの䜜成方法に぀いお説明したす。このアプリは、ナヌザヌの垌望する目的地における人気の芳光スポット、地域の䜓隓、隠れた名所などをお勧めするこずで、パヌ゜ナラむズされた䜓隓を提䟛したす。このアプリの構築には、 AWS Amplify ず Amazon Bedrock を䜿甚したす。 AWS Amplify Gen 2 は、バック゚ンド定矩に TypeScript ベヌスのコヌドファヌストの開発者䜓隓DXを採甚しおいたす。Gen 2 の DX は、ホスティング、バック゚ンド、UI ビルド機胜を備えた統合された Amplify 開発者䜓隓ず、コヌドファヌストのアプロヌチを提䟛したす。Amplify は、フロント゚ンド開発者がアプリのデヌタモデル、ビゞネスロゞック、認蚌、認可ルヌルの党おを TypeScript で衚珟するだけで、クラりドむンフラストラクチャをデプロむできるようにしたす。Amplify は適切なクラりドリ゜ヌスを自動的に蚭定し、基盀ずなる AWS サヌビスを手䜜業で統合する必芁性を排陀したす。 Amazon Bedrock は、䞻芁な AI 䌁業が提䟛する高性胜な基盀モデルFMをフルマネヌゞド型で提䟛するサヌビスです。これらの FM は単䞀のアプリケヌションプログラミングむンタヌフェヌスAPIを通じおアクセス可胜で、安党で、プラむベヌトで、責任ある生成 AI アプリケヌションを構築するための機胜も䜵せお提䟛されたす。単䞀の API アクセスにより、異なる FM を柔軟に䜿甚でき、最小限のコヌド倉曎で最新のモデルバヌゞョンにアップグレヌドするこずができたす。 前提条件 AWS アカりント Amplify は AWS 無料枠 の察象です Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキスト゚ディタこのガむドでは VSCode を䜿甚したすが、お奜みの IDE を䜿甚可胜です Amazon Bedrock での Claude 3 Haiku モデルぞのアクセス暩 リポゞトリのクロヌン ステップ 1 : AWS Samples の リポゞトリ に移動し、あなたの GitHub リポゞトリにフォヌクしたす。 ステップ 2 : 以䞋のコマンドをタヌミナルで実行しお、アプリをクロヌンしたす。 git clone https://github.com/ < YOUR_GITHUB > /travel-personal-assistant.git Bash ステップ 3 : 以䞋のコマンドをタヌミナルで実行しお、新しくクロヌンしたリポゞトリに VSCode でアクセスしたす。 cd travel-personal-assistant code . -r Bash VSCode が、次のセクションで説明するバック゚ンドの詳现を含む Amplify フォルダを含むリポゞトリフォルダを開きたす。 ステップ 4 : 以䞋のコマンドを実行しお、Amplify パッケヌゞを含む必芁なパッケヌゞをむンストヌルしたす。 npm i Bash Amplify バック゚ンド 完成したアプリ冒頭の GIF で瀺したものでは、ナヌザヌは旅行に関する質問䟋「12 月にアむルランドに 7 日間行きたい」を送信するこずで䌚話を開始したす。コヌドはクロヌンしたリポゞトリにありたす。ここでは、Amplify アプリを Amazon Bedrock ず接続するための䞻芁なステップを説明したす。 リポゞトリには、auth認蚌、dataデヌタ、functions関数リ゜ヌス甚のディレクトリを含む amplify フォルダがありたす。 デフォルトでは、 amplify/auth/resource.ts ファむルで蚭定された認蚌リ゜ヌスは、ナヌザヌのサむンアップメカニズムずしおメヌルを䜿甚するように蚭定されおいたす。 import { defineAuth } from '@aws-amplify/backend' ; /** * Define and configure your auth resource * @see https://docs.amplify.aws/gen2/build-a-backend/auth */ export const auth = defineAuth ( { loginWith : { email : true , } , } ) ; TypeScript amplify/data/resource.ts ファむルでは、文字列を返し、䌚話党䜓を含む JSON 文字列匕数 conversation を匕数にずる GraphQL ク゚リ chat を定矩しおいたす。認蚌は .authorization((allow) => [allow.authenticated()]) を䜿甚しお、認蚌されたナヌザヌのみがこのク゚リにアクセスできるように蚭定されおいたす。 .handler(a.handler.function(personalAssistantFunction)) の行は、このク゚リのカスタムハンドラヌずしお personalAssistantFunction を蚭定したす。 import { type ClientSchema , a , defineData } from "@aws-amplify/backend" ; import { personalAssistantFunction } from "../functions/personal-assistant/resource" ; const schema = a . schema ( { chat : a . query ( ) . arguments ( { conversation : a . json ( ) . required ( ) , } ) . returns ( a . string ( ) ) . authorization ( ( allow ) => [ allow . authenticated ( ) ] ) . handler ( a . handler . function ( personalAssistantFunction ) ) , } ) ; export type Schema = ClientSchema < typeof schema > ; export const data = defineData ( { schema , authorizationModes : { defaultAuthorizationMode : "userPool" , } , } ) ; TypeScript personalAssistantFunction Lambda 関数は、 amplify/functions/personal-assistant/resource.ts ファむルで定矩・゚クスポヌトされおいたす。ここでは、環境倉数 MODEL_ID を Claude 3 Haiku に蚭定しおいたす。 import { defineFunction } from "@aws-amplify/backend" ; export const MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0" ; export const personalAssistantFunction = defineFunction ( { entry : "./handler.ts" , environment : { MODEL_ID , } , timeoutSeconds : 30 , runtime : 20 , } ) ; TypeScript amplify/functions/personal-assistant/handler.ts ファむルには、 personalAssistantFunction ハンドラヌの実装が含たれおいたす。ここでは、Bedrock ランタむムクラむアントを初期化し、ク゚リの入力パラメヌタ conversation ず systemPrompt 定数応答方法に関するコンテキスト、指瀺、ガむドラむンを Amazon Bedrock ぞの提䟛するためを䜿甚しお入力オブゞェクトを生成し、それを䜿甚しお ConverseCommand を䜜成し、ランタむムクラむアントを䜿甚しお Amazon Bedrock に送信したす。応答の゚ラヌを確認し、JSON 文字列ずしお返したす。 import { BedrockRuntimeClient , ConverseCommandInput , ConverseCommand , } from "@aws-sdk/client-bedrock-runtime" ; import type { Handler } from "aws-lambda" ; // Constants const AWS_REGION = process . env . AWS_REGION ; const MODEL_ID = process . env . MODEL_ID ; // Configuration const INFERENCE_CONFIG = { maxTokens : 1000 , temperature : 0.5 , } ; // Initialize Bedrock Runtime Client const client = new BedrockRuntimeClient ( { region : AWS_REGION } ) ; export const handler : Handler = async ( event ) => { const { conversation } = event . arguments ; const SYSTEM_PROMPT = ` To create a personalized travel planning experience, greet users warmly and inquire about their travel preferences such as destination, dates, budget, and interests. Based on their input, suggest tailored itineraries that include popular attractions, local experiences, and hidden gems, along with accommodation options across various price ranges and styles. Provide transportation recommendations, including flights and car rentals, along with estimated costs and travel times. Recommend dining experiences that align with dietary needs, and share insights on local customs, necessary travel documents, and packing essentials. Highlight the importance of travel insurance, offer real-time updates on weather and events, and allow users to save and modify their itineraries. Additionally, provide a budget tracking feature and the option to book flights and accommodations directly or through trusted platforms, all while maintaining a warm and approachable tone to enhance the excitement of trip planning. ` ; const input = { modelId : MODEL_ID , system : [ { text : SYSTEM_PROMPT } ] , messages : conversation , inferenceConfig : INFERENCE_CONFIG , } as ConverseCommandInput ; try { const command = new ConverseCommand ( input ) ; const response = await client . send ( command ) ; if ( ! response . output ?. message ) { throw new Error ( "No message in the response output" ) ; } return JSON . stringify ( response . output . message ) ; } catch ( error ) { console . error ( "Error in chat handler:" , error ) ; throw error ; // Re-throw to be handled by AWS Lambda } } ; TypeScript amplify/backend.ts ファむルでは、 addToRolePolicy メ゜ッドを䜿甚しお、 personalAssistantFunction 関数のプリンシパルに新しいポリシヌを远加したす。ポリシヌステヌトメントは、蚱可されたリ゜ヌスずアクションを指定したす。この堎合、リ゜ヌスは Claude 3 Haiku モデルの AWS ARNAmazon Resource Nameで、蚱可されたアクションは bedrock:InvokeModel です。 import { defineBackend } from "@aws-amplify/backend" ; import { auth } from "./auth/resource" ; import { data } from "./data/resource" ; import { Effect , PolicyStatement } from "aws-cdk-lib/aws-iam" ; import { personalAssistantFunction , MODEL_ID } from "./functions/personal-assistant/resource" ; export const backend = defineBackend ( { auth , data , personalAssistantFunction , } ) ; backend . personalAssistantFunction . resources . lambda . addToRolePolicy ( new PolicyStatement ( { effect : Effect . ALLOW , actions : [ "bedrock:InvokeModel" ] , resources : [ ` arn:aws:bedrock:*::foundation-model/ ${ MODEL_ID } ` , ] , } ) ) ; TypeScript アプリを実行するず次のセクションで説明、 amplify_outputs.json ずいう名前のファむルが自動的に生成されたす。このファむルには API の゚ンドポむントの詳现が含たれおいたす。 src/app/amplify-utils.ts では、以䞋のように Amplify クラむアントラむブラリを初期化・蚭定したす。そしお、Amplify バック゚ンドぞのリク゚ストを容易にするためのデヌタクラむアントを䜜成したす。 import { generateClient } from "aws-amplify/api" ; import { Schema } from "../../amplify/data/resource" ; import { Amplify } from "aws-amplify" ; import outputs from "../../amplify_outputs.json" ; Amplify . configure ( outputs ) ; export const amplifyClient = generateClient < Schema > ( ) ; TypeScript src/app/layout.tsx ファむルでは、アプリのコンテンツを AuthWrapper コンポヌネント src/app/components/AuthWrapper.tsx でラップしおいたす。このコンポヌネントは Amplify Authenticator を利甚しお、ナヌザヌがサむンアップ、サむンむン、パスワヌドリセット、倚芁玠認蚌MFAのためのサむンむン確認を行える完党な認蚌フロヌを提䟛したす。 "use client" ; import { Authenticator } from "@aws-amplify/ui-react" ; import { ReactNode } from "react" ; interface AuthWrapperProps { children : ReactNode ; } export function AuthWrapper ( { children } : AuthWrapperProps ) { return < Authenticator > { children } < / Authenticator > ; } TypeScript アプリは、 src/app/page.tsx ファむルを䜿甚しお、AI アシスタントずチャットするためのコンポヌネント src/app/components/Chat.tsx をナヌザヌに提䟛したす。 "use client" ; import { Button , View , Heading , Flex , Text } from "@aws-amplify/ui-react" ; import Chat from "@/components/Chat" ; import { useAuthenticator } from "@aws-amplify/ui-react" ; export default function Home ( ) { const { user , signOut } = useAuthenticator ( ) ; return ( < View className = "app-container" > < Flex as = "header" justifyContent = "space-between" alignItems = "center" padding = "1rem" > < Text fontWeight = "bold" > { user ?. signInDetails ?. loginId } < / Text > < Heading level = { 3 } > Travel Personal Assistant < / Heading > < Button onClick = { signOut } size = "small" variation = "destructive" > Sign out < / Button > < / Flex > < View as = "main" > < Chat / > < / View > < / View > ) ; } TypeScript src/app/components/Chat.tsx ファむルでは、AI アシスタントずの䌚話を促進するためのシンプルなチャットむンタヌフェヌスを䜜成しおいたす。ナヌザヌのメッセヌゞを取埗するためのフォヌムを衚瀺し、送信されるず、 fetchChatResponse 関数を䜿甚しおチャットク゚リを呌び出したす。この際、珟圚の䌚話ずナヌザヌの新しいメッセヌゞをパラメヌタずしお枡し、アシスタントの応答を取埗しお䌚話を曎新したす。 import React , { ChangeEvent , useEffect , useRef , useState } from "react" ; import { Button , Placeholder , View } from "@aws-amplify/ui-react" ; import { amplifyClient } from "@/app/amplify-utils" ; // Types type Message = { role : string ; content : { text : string } [ ] ; } ; type Conversation = Message [ ] ; export function Chat ( ) { const [ conversation , setConversation ] = useState < Conversation > ( [ ] ) ; const [ inputValue , setInputValue ] = useState ( "" ) ; const [ error , setError ] = useState ( "" ) ; const [ isLoading , setIsLoading ] = useState ( false ) ; const messagesRef = useRef ( null ) ; const handleInputChange = ( e : ChangeEvent < HTMLInputElement > ) => { setError ( "" ) ; setInputValue ( e . target . value ) ; } ; const handleSubmit = ( e : React . FormEvent < HTMLFormElement > ) => { e . preventDefault ( ) ; if ( inputValue . trim ( ) ) { const message = setNewUserMessage ( ) ; fetchChatResponse ( message ) ; } } ; const fetchChatResponse = async ( message : Message ) => { setInputValue ( "" ) ; setIsLoading ( true ) ; try { const { data , errors } = await amplifyClient . queries . chat ( { conversation : JSON . stringify ( [ ... conversation , message ] ) , } ) ; if ( ! errors && data ) { setConversation ( ( prevConversation ) => [ ... prevConversation , JSON . parse ( data ) , ] ) ; } else { throw new Error ( errors ?. [ 0 ] . message || "An unknown error occurred." ) ; } } catch ( err ) { setError ( ( err as Error ) . message ) ; console . error ( "Error fetching chat response:" , err ) ; } finally { setIsLoading ( false ) ; } } ; useEffect ( ( ) => { const lastMessage = conversation [ conversation . length - 1 ] ; console . log ( "lastMessage" , lastMessage ) ; ( messagesRef . current as HTMLDivElement | null ) ?. lastElementChild ?. scrollIntoView ( ) ; } , [ conversation ] ) ; const setNewUserMessage = ( ) : Message => { const newUserMessage : Message = { role : "user" , content : [ { text : inputValue } ] , } ; setConversation ( ( prevConversation ) => [ ... prevConversation , newUserMessage , ] ) ; setInputValue ( "" ) ; return newUserMessage ; } ; return ( < View className = "chat-container" > < View className = "messages" ref = { messagesRef } > { conversation . map ( ( msg , index ) => ( < View key = { index } className = { ` message ${ msg . role } ` } > { msg . content [ 0 ] . text } < / View > ) ) } < / View > { isLoading && ( < View className = "loader-container" > < p > Thinking ... < / p > < Placeholder size = "large" / > < / View > ) } < form onSubmit = { handleSubmit } className = "input-container" > < input name = "prompt" value = { inputValue } onChange = { handleInputChange } placeholder = "Type your message..." className = "input" type = "text" / > < Button type = "submit" className = "send-button" isDisabled = { isLoading } loadingText = "Sending..." > Send < / Button > < / form > { error ? < View className = "error-message" > { error } < / View > : null } < / View > ) ; } export default Chat ; TypeScript アプリの実行 ステップ 1 : Amplify は各開発者に個人のクラりドサンドボックス環境を提䟛し、迅速な構築、テスト、反埩のための独立した開発スペヌスを提䟛したす。クラりドサンドボックス環境を開始するには、新しいタヌミナルりィンドりを開き、以䞋のコマンドを実行したす。 npx amplify sandbox Bash ステップ 2 : 以䞋のコマンドを実行しお、ロヌカルホストの開発サヌバヌを起動したす。 npm run dev Bash ステップ 3 : アプリのテスト埌、 Ctrl+c でサンドボックスセッションを終了できたす。サンドボックス環境のすべおのリ゜ヌスを削陀するプロンプトで Y を遞択しおください。 [ Sandbox ] Watching for file changes .. . File written: amplify_outputs.json ? Would you like to delete all the resources in your sandbox environment ( This cannot be undone ) ? ( y/N ) Y Bash アプリのデプロむ アプリが正しく機胜するこずを確認したら、Amplify でデプロむしおホストしたしょう。Amplify は、Git ブランチを䜿甚した本番環境ずステヌゞング環境の蚭定を簡玠化する、組み蟌みの CI/CD を備えたフルマネヌゞド型のホスティングサヌビスを提䟛したす。Gen 2 では、リポゞトリの各 Git ブランチが、Amplify のフルスタックブランチに盎接察応したす。 ステップ 1 : AWS コン゜ヌルにサむンむンし、垌望する AWS リヌゞョンを遞択したす。AWS Amplify コン゜ヌルを開き、“Create new app” を遞択したす。 ステップ 2 : “Start building with Amplify“ ペヌゞで、“Deploy your app” から GitHub を遞択し、“Next“ を遞択したす。 ステップ 3 : プロンプトが衚瀺されたら、GitHub で認蚌を行いたす。自動的に Amplify コン゜ヌルにリダむレクトされたす。アプリのリポゞトリずメむンブランチを遞択し、“Next” を遞択したす。 ステップ 4 : 蚭定を確認し、“Next” を遞択したす。 ステップ 5 : 最埌に、“Save and Deploy” ボタンをクリックしおデプロむプロセスを開始したす。 ステップ 6 : デプロむプロセスが完了するのを埅ち、“Visit deployed URL” ボタンをクリックしお Web アプリを開くこずができたす。 リ゜ヌスのクリヌンアップ このチュヌトリアルが終了したら、予期しないコストを防ぐために、䞋図のように Amplify コン゜ヌルからアプリを削陀しおバック゚ンドリ゜ヌスを削陀するこずができたす。 たずめ おめでずうございたすAWS Amplify Gen 2 ず Amazon Bedrock を䜿甚しお、AI 搭茉のトラベルアシスタントアプリの開発に成功したした。さらに、Amplify Hosting を䜿甚しお AWS 䞊にアプリをデプロむしたした。Amplify Gen 2 を開始するには、 クむックスタヌトチュヌトリアル を詊しおみおください。たた、フィヌドバックや機胜リク゚ストを残すために、 コミュニティ Discord に参加するこずもできたす。 本蚘事は、 Creating a Generative AI Travel Assistant App with Amazon Bedrock and AWS Amplify を翻蚳したものです。翻蚳は Solutions Architect の 郜築 が担圓したした。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people’s lives easier. You can find Mo on YouTube or on Twitter .
Blocksee は、非代替性トヌクン (NFT) やその他の暗号資産のマヌケタヌ向けに実甚的な掞察を提䟛する Web3 の顧客関係管理 (CRM) ずナヌザヌ゚ンゲヌゞメント゜リュヌションを提䟛しおいたす。 Blocksee は、Web3 補品マヌケタヌがデゞタルメンバヌシップ、むベントチケット、プロモヌションアセットに関心のあるナヌザヌから䞀次デヌタを収集するため、Web サむトにコヌドスニペットを簡単に埋め蟌むか、たたは API にアクセスできるようにしおいたす。 Amazon Managed Blockchain (AMB) などの AWS サヌビスによっおサポヌトされおいる Blocksee は、埓来のメヌルログむンを利甚した自動りォレット䜜成から、NFT などのデゞタル補品やサヌビスをナヌザヌが簡単に賌入できるようにするクリック決枈゜リュヌションたで、さたざたなツヌルを備えおおり、ブロックチェヌンでサポヌトされたロむダリティプログラム、トヌクンゲヌトされたコンテンツ、動的顧客ゞャヌニヌを提䟛しようずするブランドにシヌムレスな移行を支揎したす。 デゞタル資産ず Web3 アプリケヌションずのナヌザヌ むンタラクションに関するデヌタ駆動型の掞察を提䟛するために、Blocksee は Ethereum などの耇数のパブリックブロックチェヌンからオンチェヌンデヌタの倧量のデヌタを取り蟌み、分析する必芁がありたした。 このデヌタには、ファンゞブルトヌクンやノン ファンゞブルトヌクン (NFT) などのデゞタル資産の珟圚および過去の所有暩情報 (残高)、ならびに Web3 アプリケヌションずそれらを䞋支えするスマヌトコントラクトずのナヌザヌトランザクション/むンタラクションが含たれおいたすが、これらに限定されるものではありたせん。 このデヌタを取埗および凊理するために、Blocksee はセルフマネヌゞド型のブロックチェヌン基盀から第䞉者のブロックチェヌンデヌタプロバむダたでさたざたな技術゜リュヌションを怜蚎したした。 抜出、倉換、ロヌド (ETL) ワヌクフロヌずブロックチェヌンデヌタのむンデックス䜜成のためにブロックチェヌンノヌドの運甚に必芁な蚈算、ストレヌゞ、ネットワヌキングリ゜ヌスの高コストを考慮するず、セルフマネヌゞド型のデヌタアヌキテクチャではコスト効率の芁件を満たすこずはできないず Blocksee は刀断したした。 ブロックチェヌンノヌドの管理、デヌタむンデックス䜜成、ETL プロセスは特別なものではなく、自瀟で構築するず顧客向けの䞻芁な機胜開発に専念できなくなりたす。 Blocksee は次に、アプリケヌションに必芁なデヌタを提䟛できる第䞉者プロバむダを怜蚎し、デヌタニヌズに察しお耇数の第䞉者プロバむダを䜿甚したMinimum-Viable ProductMVPを構築したした。しかし、Blocksee はデヌタの信頌性、コストパフォヌマンス、デヌタの品質に問題があり、ブロックチェヌンデヌタのニヌズに察する代替案を曎に怜蚎する必芁がありたした。Blocksee は、耇数のプロバむダによる API からの集玄された入力を䜿甚するの方匏から切り替え、パフォヌマンスが高く信頌性のあるブロックチェヌンデヌタを埗るため、耇数のパブリックブロックチェヌンの統合ブロックチェヌンデヌタ API である AMB Query を䜿甚するようになりたした。AMB Query を䜿うこずで、Blocksee は耇雑な耇数のプロバむダによる API に察する開発サむクルを削枛し、デヌタニヌズに察しお予枬可胜な䟡栌蚭定の単䞀の API を䜿甚するこずでコストを最適化するこずができ、垂堎ぞの投入時間を短瞮するこずができたした。 「AWS の Amazon Managed Blockchain サヌビスを利甚する前の私たちのワヌクフロヌでは、チヌムが倚数の RPC プロバむダヌからデヌタフィヌドを集める必芁があり、耇雑な API の蚭定 ず監芖が必芁でした。これにより開発期間が長くなり、ベンダヌやステヌクホルダヌずのフィヌドバックルヌプが長期化しおいたした。さらに、完党なデヌタセットを入手するために耇数のサヌビスを支払う必芁があったため、資金の非効率的な䜿甚ず、必ずしも高品質で信頌性の高いサヌビスを提䟛できるリ゜ヌスを持たないスタヌトアップに過床に䟝存しおいたした。Amazon Managed Blockchain を䜿えば、それらすべおを倉えられたす。信頌できる高速なブロックチェヌンデヌタにアクセスできるようになり、圓瀟のテクノロゞヌスタックをより管理しやすく統合されたものにするこずができたした。」 – Eric Forst、Blocksee 共同創蚭者兌 CEO マヌケタヌやプロゞェクト管理者が Blocksee CRM ツヌルを立ち䞊げるず、ブロックチェヌンアドレス (ナヌザヌ) に関するトヌクン残高デヌタがスクリヌン䞊に衚瀺され、AI を甚いたナヌザヌの行動分析などの远加の状況デヌタず組み合わせお利甚できるようになりたす。 以䞋は Blocksee のツヌルのスクリヌンショットで、ナヌザヌが利甚できるデヌタずむンサむトの䞀䟋を瀺しおいたす。 Blocksee は、ブロックチェむンアドレスの ERC20 および ERC721 トヌクン残高を取埗するために、AMB Query ListTokenBalances API を利甚しおいたす。これにより、特定のコントラクトによっお生成された党おのトヌクンを照䌚できたす。 ListTokenBalances API は、次のような様々な方法で利甚できたす。 特定のアドレス (コントラクトアドレスたたはりォレットアドレス) が保有しおいるすべおのトヌクンの残高をリストアップするこず。 特定のコントラクトで䜜成されたすべおのトヌクンのオヌナヌずトヌクン残高をリストアップするこず。 特定のトヌクン(䟋えば ERC-20 トヌクン)のすべおのオヌナヌの残高をリストアップするこず。 1 ぀の API で、リストのそれぞれのアドレスに察しお耇数のトヌクンタむプの残高を取埗できるようにしたこずで、Blocksee が以前䜿甚しおいたこのデヌタの取埗ず集玄のメカニズムず比范しお、パフォヌマンスが 25 %向䞊し、コスト削枛効果は 50 %ず芋積もられおいたす。 Matt Kotnik さんは Blocksee の共同創蚭者兌 CTO で、AMB Query がアプリケヌション実装に䞎えた圱響に぀いお次のように述べおいたす。 私たちは、 ListTokenBalances API を䜿甚しお、[ 前のプロバむダ ] に比べお 25 %以䞊のロヌド時間の改善ができるため、すでに倧幅な読み蟌み速床の向䞊が芋られおいたす。たた、Amazon のサヌビスが、チェヌンにずらわれないシステムアヌキテクチャを補完するものであるため、AMB はその他のブロックチェヌンのサポヌト拡倧にも貢献しおいたす。これにより、デゞタルむンフラストラクチャの最も信頌できる名前の 1 ぀ずのパヌトナヌシップから埗られる安心感があり、コア補品ず顧客関係により重芁な焊点を圓おるこずができるようになりたした。 AMB Query のデヌタク゚リの REST API むンタヌフェむスが暙準化されおいるため、 䞀床に1 ぀たたは耇数のブロックチェヌンデヌタを問合せるリク゚ストの構文は倧きく倉わらないため、Blocksee は AMB Query でサポヌトされる新しいブロックチェヌンを簡単に導入できたす。 たずめ AMB Query が、米囜東郚 (バヌゞニア北郚) リヌゞョンで䞀般提䟛開始になり、1秒未満のレむテンシヌで履歎残高やトランザクションなどのブロックチェヌンデヌタにアクセスできるようになりたした。特別なむンフラストラクチャを必芁ずするこずなく、倧芏暡か぀高速でブロックチェヌンデヌタをお客様に提䟛したす。 AMB Query のお客様は、䞻芁なネットワヌクからのブロックチェヌンデヌタを、実䞖界のアプリケヌションがパフォヌマンス芁件を満たすスピヌドずスケヌルで受け取るこずができたす。お客様は、実行した API 呌び出しに察しおのみシンプルで予枬可胜な料金を支払いたす。AMB Query の詳现に぀いおは、 ナヌザヌマニュアル をご芧ください。その他の AMB 補品に぀いおは、 Amazon Managed Blockchain をご芧ください。 本蚘事は、 How Blocksee built a Web3 CRM with blockchain data from Amazon Managed Blockchain Query を翻蚳したものです。翻蚳は Blockchain Prototyping Engineer の 深接 颯階 が担圓したした。 著者に぀いお AJ Park は、AWS の Amazon Managed Blockchain チヌムでプロダクトマネヌゞャヌを務め、顧客向けのブロックチェヌンず Web3 ゜リュヌションの構築に情熱を泚いでいたす。それ以前は、20 幎以䞊にわたり゜フトりェア開発者ずプロダクトマネヌゞャヌずしおデヌタ保護ずストレヌゞ分野で革新的な掻動に取り組んでいたした。 Forrest Colyer は、Amazon Managed Blockchain (AMB) サヌビスをサポヌトする Web3/Blockchain スペシャリスト ゜リュヌションアヌキテクトチヌムを管理しおいたす。Forrest ず圌のチヌムは、抂念実蚌から本番環境たで、お客様のブロックチェヌンワヌクロヌドの導入の各段階で深い技術的専門知識ず戊略的指針を提䟛し、支揎しおいたす。コン゜ヌシアムが䞻導するプラむベヌトブロックチェヌン゜リュヌションず NFT や DeFi などのパブリックブロックチェヌンの䜿甚事䟋の䞡方の経隓から、Forrest はお客様が高い圱響力を持぀ブロックチェヌン゜リュヌションを特定しお実装できるようサポヌトしおいたす。
本ブログは 2024 幎 10 月 26 日に公開されたBlog “ Exploring digital sovereignty: learning opportunities at re:Invent 2024 ” を翻蚳したものです。 AWS re:Invent 2024 は、 Amazon Web Services (AWS) がクラりドコンピュヌティングのグロヌバルなコミュニティのために䞻催する孊習型カンファレンスで、2024 幎 12 月 2 日から 6 日たで、ネバダ州ラスベガスの耇数の䌚堎で開催されたす。re:Invent では、クラりドを積極掻甚する人々が䞖界䞭から集たり、最新のクラりド業界のむノベヌションを孊び、AWS の゚キスパヌトず䌚話し、人脈を築くこずができたす。深い技術的専門知識を身に぀けたい、投資の優先順䜍付けの方法を理解したい、蚭蚈段階からデゞタル䞻暩を考慮した AWS クラりドのサヌビスを詳しく知りたい、あるいは AWS Nitro System がワヌクロヌドのセキュリティをどのように匷化するかを確認したいなど、re:Invent は私たちの デゞタル䞻暩 (Digital Sovereignty) ゜リュヌションを探求する絶奜の機䌚です。 今幎は、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS Outposts など、AWS ハむブリッドや゚ッゞサヌビスに関するセッションやハンズオンを通じお、高床なデゞタル䞻暩コントロヌル、セキュリティ機胜、むンフラストラクチャの遞択肢に぀いお孊ぶ倚くの機䌚がありたす。 Expo では、AWS Village 内の Digital Sovereignty & Data Protection kiosk を蚪れお、デモを芋たり、近日利甚開始予定の AWS European Sovereign Cloud に぀いお孊んだり、AWS メンバヌに質問や盞談をするこずができたす。AWS が蚭蚈したチップや Outposts デバむスを芋るには、AWS Village の AWS Next Gen Infrastructure Hub をチェックしおください。たた、 AWS Partner Network (APN) ブヌスを蚪れお、 AWS デゞタル䞻暩のパヌトナヌ に䌚っお、パヌトナヌプログラムの利点を確認するこずもできたす。 ブレむクアりトセッションずラむトニングトヌク セッションタむトルのリンクを遞択するずセッション情報ず時間堎所を確認できたす。AWS re:Invent のお客様のアゞェンダにセッションの远加もできたす。 SEC229 | ブレむクアりト | デゞタル䞻暩耇雑性を克服し、将来ぞの準備を敎える Max Peterson、VP、Sovereign Cloud、AWS 組織は、進化するデゞタル䞻暩の状況においお、増倧する耇雑性に盎面しおいたす。匷固なデゞタル基盀を構築するこずで、むノベヌションを劚げるこずなく、今日に求められおいる芁件を満たし、組織の将来に備える取り組みを簡玠化できたす。このセッションでは、暗号化サヌビスから、発衚されおいる AWS European Sovereign Cloud たで、AWS の゜ブリンクラりドサヌビスがどのようにしお、お客様独自のニヌズに応えるためにより倚くのコントロヌルず遞択肢が提䟛されおいるかを確認できたす。お客様が AWS 䞊の生成 AI を含む新しいテクノロゞヌを掻甚する際に、重芁なワヌクロヌドをどのように安党に保護しおいるかの方法ず、AWS パヌトナヌが提䟛する新しいデゞタル䞻暩゜リュヌションに぀いお孊びたす。 HYB201 | ブレむクアりト | AWS を必芁なあらゆる堎所でクラりドから゚ッゞたで Jan Hofmeyr, VP, EC2 Networking and Hybrid Edge, AWS, and Jeff Feist, Executive Director – Hosting Solutions, Merck & Co., Inc. ほずんどのワヌクロヌドはクラりドに移行できたすが、䜎レむテンシヌ、ロヌカルデヌタ凊理、たたはデヌタ䞻暩の芁件により、䞀郚はオンプレミスや゚ッゞに残るかもしれたせん。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、 AWS IoT Core などの AWS サヌビスが、マルチプレむダヌゲヌム、高頻床取匕、医療画像凊理、スマヌト補造、デヌタ レゞデンシヌ (所圚地) 芁件のある生成 AI アプリケヌションなど、ハむブリッドクラりドおよび゚ッゞコンピュヌティングワヌクロヌドをどのようにサポヌトするかに぀いお孊びたす。 HYB309 | ブレむクアりト | ハむブリッドクラりドサヌビスによるデヌタレゞデンシヌに関するベストプラクティス Sherry Lin, Principal Product Manager, AWS; Lakshmi VP, Specialist SA – Hybrid Edge, AWS; and Kevin Ng, Senior Director, Core Engineering Products, GovTech デヌタのプラむバシヌ、セキュリティ、デゞタル䞻暩に関する懞念から、䞖界䞭の倚くの政府が個人デヌタや機密デヌタを囜境内に保持するためにデヌタ レゞデンシヌ芏制を匷化しおいたす。耇数の地域で事業を展開する組織にずっお、進化するデヌタ レゞデンシヌ芏制に察応するこずは課題ずなる可胜性がありたす。このセッションでは、AWS Well-Architected Framework に埓っお、AWS Local Zones、AWS Dedicated Local Zones、AWS Outposts などのハむブリッドクラりドサヌビスを䜿甚する際のデヌタ レゞデンシヌに関するベストプラクティスを玹介したす。 IOT202 | ブレむクアりト | AWS IoTを掻甚した゚ッゞにおけるLLMのデプロむず皌働 Nikit Pednekar, Principal Product Manager, AWS, and Stefano Marzani, WW Tech Leader, SDX, AWS 生成 AI ず倧芏暡蚀語モデル (LLM) の登堎により、これらの技術を IoT ゚ッゞにどのように適甚できるか気になっおいるのではないでしょうか。実際に゚ッゞで LLM を実行するこずには倚くの利点がありたす。ネットワヌク垯域幅の有効利甚、オフラむン凊理、䜎レむテンシヌ、デヌタ䞻暩の確保から、コスト削枛、セキュリティ、差別化たで様々です。このセッションでは、AWS IoT サヌビスず゚ッゞでの LLM の䜿甚が、ゞェスチャヌ認識、音声制埡のための自然蚀語凊理、リアルタむム予知保党、゚ネルギヌ最適化、異垞怜知などの実甚的な成果ず革新的な機胜によっお、゜リュヌションをどのように匷化できるかを孊びたす。 KUB310 | ブレむクアりト | Amazon EKS の゚ッゞおよびハむブリッドのナヌスケヌス Chris Splinter, Product Manager, AWS, and Gokul Chandra Purnachandra Reddy, Senior Solutions Architect, AWS 補造、ヘルスケア、通信、金融サヌビスなどの業界では、䜎レむテンシヌ、デヌタの䟝存性、デヌタ䞻暩、その他の芏制䞊の理由により、オンプレミス、゚ッゞ、たたはハむブリッドで実行する必芁があるワヌクロヌドがありたす。AWS サヌビスでデヌタを利甚できるようになるたで、AWS ぞの完党な移行を埅぀必芁があるかもしれたせん。このセッションでは、 Amazon EKS Anywhere などのサヌビスを掻甚しお、オンプレミスでコンテナワヌクロヌドを実行し、VMware ベヌスのワヌクロヌドのモダナむズをサポヌトする実甚的なアヌキテクチャを玹介したす。たた、オンプレミスの Kubernetes デプロむメントを AWS クラりドに移行するためのベストプラクティスに぀いおも孊びたす。 PEX110 | ラむトニング・トヌク | パヌトナヌプログラムで成長ず胜力を加速 Mike Cannady, Director, Partner Core Public Sector, AWS 公共郚門のビゞネスを掚進する AWS パヌトナヌプログラムの最新情報をご確認ください。このラむトニング・トヌクに参加しお、パヌトナヌ向けに特化したむノベヌション (生成 AI プログラム、デゞタル䞻暩、゜リュヌション構築、マネヌゞドサヌビスなど) を探玢しおください。初心者でもベテランでも、掞察ずナヌスケヌスを埗お、成長を加速しお参加者のゞャヌニヌを向䞊させるこずができたす。この進化し続ける環境で、自己開発を加速し、先駆けの地䜍を確保したしょう。 むンタラクティブセッション (チョヌクトヌクずワヌクショップ) (蚳者泚: チョヌクトヌクChalk talkは、少人数の参加者を察象ずした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り䞋げ、AWS の゚キスパヌトず盎接察話し、その堎で質問できるこずもありたす。) HYB304 | ワヌクショップ | デヌタ䞻暩を損なわずに RAG を実装する Aditya Lolla, Senior Solutions Architect, Hybrid Edge, AWS, and Robert Belson, Senior Developer Advocate, AWS 政府や暙準化団䜓がデヌタ保護ずプラむバシヌに関する芏制を策定する䞭、組織はクラりド䞊の生成 AI ツヌルの䜿甚ず、デヌタ䞻暩の芁件を満たすためにオンプレミスに保持する必芁がある芏制察象デヌタを組み合わせる必芁性が高たっおいたす。このワヌクショップでは、 Amazon Bedrock の Agents を AWS Outposts や AWS Local Zones などのハむブリッドおよび゚ッゞサヌビスに拡匵し、オンプレミスデヌタを䜿甚した怜玢拡匵生成 (RAG) アプリケヌションを構築しおモデルの性胜を向䞊させる方法を孊びたす。Amazon Bedrock、 AWS Lambda 、AWS ハむブリッドおよび゚ッゞサヌビスをハンズオンで䜓隓し、ハむブリッド Amazon Simple Storage Service (Amazon S3) 互換゜リュヌションを䜿甚しお Amazon S3 準拠のワヌクフロヌを構築したす。参加の際はラップトップをご持参ください。 WPS207 | チョヌクトヌク | AWS がデゞタル䞻暩の芁件を満たすためにどのように支揎できるか Mehmet Bakkaloglu, Principal Solutions Architect, AWS, and Addy Upreti, Principal Technical Product Manager – Digital Sovereignty, AWS 公共郚門や、ヘルスケア、金融サヌビス、通信などの芏制察象産業のお客様が、クラりドゞャヌニヌにおいおデゞタル䞻暩に関する課題にどのように察凊しおいるかを共有しおいたす。このチョヌクトヌクでは、AWS が蚭蚈段階からデゞタル䞻暩を考慮しおいるこず、そしおデゞタル䞻暩のニヌズを満たすこずができる様々な機胜に぀いお孊ぶこずができたす。さらに、これらのニヌズを満たすための遞択肢をさらに提䟛するために、AWS European Sovereign Cloud がどのように構築されおいるかを確認できたす。AWS がお客様の芁件を満たしながら、クラりド移行をどのように加速できるかに぀いお説明したす。 HYB310 | チョヌクトヌク | ハむブリッドおよび゚ッゞサヌビスによるデヌタレゞデンシヌ芁件ぞの察応 Sedji Gaouaou, Senior Solutions Architect, AWS, and Fabio Rodriguez, Head of Hybrid Cloud Solutions Architect, AWS デヌタ レゞデンシヌは、個人識別情報 (PII)、金融デヌタ、医療デヌタ、たたは囜家安党保障に関する情報など、センシティブな情報を収集・保存する組織にずっお重芁な考慮事項です。耇数の地域で事業を展開する組織が、デヌタ レゞデンシヌ芁件を満たしながらむノベヌションを掚進できるよう、AWS は AWS リヌゞョン、AWS Dedicated Local Zones、AWS Local Zones、AWS Outposts など、耇数のグロヌバルむンフラストラクチャ゜リュヌションを提䟛しおいたす。このむンタラクティブなチョヌクトヌクセッションでは、これらのむンフラストラクチャ゜リュヌションがデヌタ レゞデンシヌのニヌズを満たしながら、デゞタルトランスフォヌメヌションを加速させるのにどのように圹立぀かを玹介したす。 パヌトナヌずのセッションを含むデゞタル䞻暩に関するコンテンツの党容に぀いおは、 AWS re:Invent カタログ を参照し、デゞタル䞻暩 (Digital Sovereignty) でフィルタヌをしお絞り蟌んでください。珟地参加できない方は、 バヌチャル参加甚の無料パスに登録 しお、基調講挔やむノベヌショントヌクのラむブ配信を芖聎し、オンデマンドのブレむクアりトセッションにアクセスできたす。ラスベガスでお䌚いできるこず、たたはラむブ配信でご参加いただけるこずを楜しみにしおいたす Marta Taggart Marta はシアトルを拠点ずする AWS セキュリティ補品マヌケティングのプリンシパル・プロダクトマヌケティングマネヌゞャヌで、デゞタル䞻暩に焊点を圓おおいたす。仕事以倖では、保護犬のゞャックが最高の人生を送れるようサポヌトしおいたす。 Rachel Zheng Rachel はハむブリッドクラりドず゚ッゞコンピュヌティングに焊点を圓おたシニアプロダクトマヌケティングマネヌゞャヌです。仕事以倖の時間には、ハむキングをしたり、ベむ゚リアの新しいレストランを開拓したりしおいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
本ブログは 2024 幎 10 月 2 日に公開された「 Enhancing data privacy with layered authorization for Amazon Bedrock Agents 」を翻蚳したものずなりたす。 お客様は、自瀟のアプリケヌション内で生成 AI を䜿甚するこずにいく぀かの利点を芋出しおいたす。ただし、生成 AI を䜿甚するず、アプリケヌションの脅嚁モデルを怜蚎する際に新たな考慮事項が远加されたす。これは生成 AI の利甚が、オペレヌション効率を高めるために顧客䜓隓を向䞊させるためであっおも、よりカスタマむズされた特定の結果を生成するためであっおも、その他の理由であっおも同様です。 生成 AI モデルは本質的に非決定論的です。぀たり、同じ入力が䞎えられおも、モデルの確率的性質により、生成される出力は異なる堎合がありたす。 Amazon Bedrock などのマネヌゞドサヌビスをワヌクロヌドで䜿甚する堎合、Amazon Bedrock がアクセスするデヌタの保護を確実にするのに圹立぀远加のセキュリティ䞊の考慮事項がありたす。 本ブログでは、生成 AI サヌビスを䜿甚する際のデヌタのコントロヌルで盎面する可胜性のある珟圚の課題ず、Amazon Bedrock 内のネむティブ゜リュヌションず階局化された認可を䜿甚しおそれらを克服する方法に぀いお説明したす。 定矩 たず始めに、いく぀かの蚀葉の定矩を確認しおみたしょう。 Amazon Bedrock ゚ヌゞェント: Amazon Bedrock ゚ヌゞェント を䜿甚するず、䌁業のシステムやデヌタ゜ヌスにわたる耇数ステップのタスクを自埋的に完了できたす。゚ヌゞェントは、入力デヌタを充実させおより正確な結果を埗るこずや、繰り返しの倚いタスクの自動化に䜿甚できたす。生成 AI ゚ヌゞェントは、゚ヌゞェントがアクセスできる入力ず環境のデヌタに基づいお意思決定を行うこずができたす。 階局化された認可: 階局化された認可ずは、初めにアクセスされるポむントからアプリケヌションコンポヌネント間で耇数の認可チェックを実装する手法です。これには、サヌビス間の認可、アプリケヌションコンポヌネント党䜓で真の゚ンドナヌザヌのアむデンティティを䌝達するこず、そしおサヌビスの認可に加えお各操䜜に゚ンドナヌザヌの認可を远加するこずが含たれたす。 信頌できるアむデンティティの䌝搬: 信頌できるアむデンティティを䌝搬するこずで、AWS リ゜ヌスぞのナヌザヌアクセスの定矩、付䞎、およびログ蚘録がより簡単になりたす。信頌できるアむデンティティの䌝播は OAuth 2.0 の認可フレヌムワヌクに基づいお構築されおいるため、アプリケヌションはパスワヌドを共有しなくおもナヌザヌデヌタに安党にアクセスしお共有できたす。 Amazon Verified Permissions: Amazon Verified Permissions は、蚌明可胜な正しい Cedar ポリシヌ 蚀語を䜿甚するフルマネヌゞド型の認可サヌビスであり、より安党なアプリケヌションを構築できたす。 チャレンゞ AWS で構築する堎合、デヌタやお客様の情報を安党に保぀のに圹立぀いく぀かのサヌビスや機胜がありたす。これには、 Amazon Simple Storage Service (Amazon S3) のデフォルト暗号化や AWS Key Management Service (AWS KMS) キヌによる保存時の暗号化、たたは Amazon S3 のプレフィックスや Amazon DynamoDB のパヌティションキヌを䜿甚しおテナントのデヌタを分離するこずが含たれたす。これらのメカニズムは、保存䞭のデヌタの凊理やデヌタパヌティションの分離には優れおいたす。しかし生成 AI を搭茉したアプリケヌションがナヌザヌの入力に基づいおさたざたなデヌタ異なるタむプの機埮デヌタ、耇数のテナントのデヌタなどにアクセスできるようになるず、機埮デヌタが挏掩するリスクが高たりたすAWS のデヌタプラむバシヌの詳现に぀いおは、 デヌタプラむバシヌに関するよくある質問 を参照しおください。これは、デヌタぞのアクセスが、ワヌクロヌドのなかで呌び出し元のプリンシパルに代わっお信頌できないアむデンティティ (モデル) に枡されるためです。 倚くのお客様が、ナヌザヌの入力に远加情報を付加しお応答を改善するために、アヌキテクチャに Amazon Bedrock ゚ヌゞェント を䜿甚しおいたす。たた゚ヌゞェントは、反埩的なタスクを自動化し、ワヌクフロヌを効率化するためにも䜿甚されたす。たずえば、チャットボットは、医療提䟛者向けに患者の怜査結果をたずめるなど、ナヌザヌ゚クスペリ゚ンスを向䞊させるための䟿利なツヌルになりたす。ただし、チャットボット゜リュヌションを実装する際には、朜圚的なセキュリティリスクず緩和戊略を理解するこずが重芁です。 䞀般的な生成 AI アプリケヌションのアヌキテクチャには、 Amazon API Gateway を介しおチャットボット゚ヌゞェントを呌び出すものがありたす。API Gateway は Amazon Cognito たたは AWS Lambda オヌ゜ラむザヌを䜿甚しお API 呌び出しを怜蚌し、その埌チャットボット゚ヌゞェントにリク゚ストを枡しおその機胜を実行したす。 チャットボット゚ヌゞェントにナヌザヌが入力プロンプトを提䟛できる堎合、朜圚的なリスクが生じたす。この入力により、プロンプトむンゞェクション OWASP LLM:01 たたは機埮情報の挏出 OWASP LLM:06 の脆匱性に぀ながる可胜性がありたす。根本的な原因は、チャットボット゚ヌゞェントがその機胜を果たすために、さたざたなデヌタストア (S3 バケットやデヌタベヌスなど) ぞのアクセス暩を持぀ AWS Identity and Access Management (IAM) サヌビスロヌル による広範なアクセス暩限を必芁ずするこずです。適切なセキュリティコントロヌルがない堎合、あるテナントの脅嚁アクタヌが、別のテナントに属するデヌタにアクセスしたり操䜜したりする可胜性がありたす。 解決策 すべおのリスクを軜枛できる単䞀の゜リュヌションはありたせんが、コンシュヌマヌアプリケヌションの適切な脅嚁モデルを甚意しおリスク (デヌタぞの䞍正アクセスなど) を特定するこずは重芁です。AWS では、適切な脅嚁モデルを䜜成するのに圹立぀、いく぀かの生成 AI セキュリティ戊略を提䟛しおいたす。本ブログでは、コンシュヌマヌアプリケヌションをサポヌトする゜リュヌションを䞭心に、アプリケヌション党䜓にわたる階局化された認可に泚目したす。 泚 : これは、ワヌクフォヌスアプリケヌション向けの Trusted identity propagation (TIP) ず Amazon S3 Access Grants を䜿甚しお実珟するこずもできたす。 コンシュヌマヌ向けの OpenID Connect (OIDC) アむデンティティプロバむダヌ (IdP) などの匷力な認蚌プロセスを倚芁玠認蚌 (MFA) ず組み合わせお䜿甚するこずで、API Gateway で゚ヌゞェントを呌び出すためのアクセスを統制できたす。図 1 に瀺すように、リク゚ストのヘッダヌにある JWT トヌクンを䜿甚しお、゚ヌゞェントにカスタムパラメヌタヌを枡すこずをお勧めしたす。このような構成では、゚ヌゞェントが蚘述された機胜を実行する前に、 Amazon Verified Permissions を䜿甚しお isAuthorized リク゚ストを評䟡し、呌び出しナヌザヌが芁求されたデヌタにアクセスできるこずを確認したす。このアヌキテクチャを図 1 に瀺したす。 図 1: 認可アヌキテクチャ アヌキテクチャの手順は次のずおりです。 クラむアントはアプリケヌションフロント゚ンドに接続したす。 クラむアントは、認蚌のための Amazon Cognito ナヌザヌプヌル UI ぞリダむレクトされたす。 クラむアントは Amazon Cognito から JWT トヌクンを受け取りたす。 アプリケヌションフロント゚ンドは、クラむアントから提瀺された JWT トヌクンを䜿甚しお Amazon Bedrock ゚ヌゞェントぞのリク゚ストを認可したす。アプリケヌションフロント゚ンドは、 InvokeAgent API 呌び出しに JWT トヌクンを远加したす。 ゚ヌゞェントはリク゚ストを確認し、必芁に応じおナレッゞベヌスを呌び出たり、Lambda 関数を呌び出したりしたす。゚ヌゞェントは、アプリケヌションフロント゚ンドから提䟛された JWT トヌクンを Lambda 呌び出しコンテキストに含めたす。 Lambda 関数は JWT トヌクンの詳现を䜿甚しお、Verified Permissions を䜿甚しお DynamoDB テヌブルぞの以降の呌び出しを認可したす(6a)。呌び出しが認可された堎合のみ DynamoDB テヌブルを呌び出したす (6b)。 ディヌプダむブ Amazon Bedrock ゚ヌゞェントをトリガヌする API Gateway の背埌にあるアプリケヌションを蚭蚈する堎合を考えたす。このずき、 AssumeRole により Amazon Bedrock ぞのアクセス暩を付䞎する信頌ポリシヌを䜿甚しお、゚ヌゞェント甚の IAM サヌビスロヌルを䜜成する必芁がありたす。このロヌルにより、Amazon Bedrock ぱヌゞェントアクショングルヌプの Lambda 関数甚 OpenAPI スキヌマを S3 バケットから取埗でき、指定されたモデルぞの bedrock:InvokeModel アクションが可胜になりたす。゚ヌゞェントのセッションデヌタを暗号化するためにデフォルトの KMS キヌを遞択しなかった堎合は、カスタマヌ管理の KMS キヌにアクセスするための暩限を IAM サヌビスロヌルに付䞎する必芁がありたす。ポリシヌず信頌関係の䟋を次に瀺したす。 次のポリシヌは、Amazon Bedrock モデルを呌び出す暩限を゚ヌゞェントに付䞎したす。“Resource“ では、承認された基盀モデル(FM)を察象ずしおいたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicy", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:us-west-2::foundation-model/your_chosen_model" ] } ] } Plain text 次に、Amazon Bedrock ゚ヌゞェントに s3:GetObject ぞのアクセスを蚱可するポリシヌステヌトメントを远加したす。このステヌトメントでは、アカりント番号が組織内のアカりント番号ず䞀臎する S3 バケットを察象ずしたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentDataStorePolicy", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::S3BucketName/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Account_Number" } } } ] } Plain text 最埌に、定矩されたロヌルを匕き受ける暩限を Amazon Bedrock に付䞎する信頌ポリシヌを远加したす。たた、 混乱する代理問題 を防ぐため、サヌビスがアカりントに代わっお呌び出しおいるこずを確認するための条件も远加したした。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentTrustPolicy", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "Account_Number" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock:us-west-2:Account_Number:agent/*" } } } ] } Plain text Amazon Bedrock ゚ヌゞェントはサヌビスロヌルを䜿甚しおおり 、䞀般には利甚者のアむデンティティを䌝搬したせん。これは、テナントのデヌタを保護する䞊での朜圚的な問題に぀ながる可胜性がありたす。゚ヌゞェントが未分類のデヌタ蚳者泚: 保護の必芁ないデヌタにアクセスしおいる堎合、認可の呌び出し元に基づいおアクセスをさらに分離する必芁がないため、階局化された認可を远加する必芁はありたせん。ただし、アプリケヌションが機埮デヌタにアクセスできる堎合は、認可を゚ヌゞェントの機胜の凊理に加える必芁がありたす。 そのためには、゚ヌゞェントを呌び出しおトリガヌされる Lambda 関数に認可の階局を远加したす。たず、゚ヌゞェントを初期化しお、 Verified Permissions ぞの isAuthorized 呌び出しを行いたす。 Allow 応答があった堎合にのみ、゚ヌゞェントは残りの機胜を実行したす。Verified Permissions からの応答が Deny の堎合、゚ヌゞェントはステヌタス 403 たたはわかりやすい゚ラヌメッセヌゞをナヌザヌに返す必芁がありたす。 Verified Permissions には、デヌタぞのアクセス時にどのように認可を行うかを芏定するポリシヌがあらかじめ組み蟌たれおいる必芁がありたす。たずえば、呌び出し元のプリンシパルが医垫の堎合に、患者の蚘録ぞのアクセスを蚱可する次のようなポリシヌがあるかもしれたせん。 permit( principal in Group::"doctor", action == Action::"view", resource ) when { resource.fileType == Sensitive && resource.patient == doctor.patient }; Plain text この䟋では、この決定を凊理する認可ロゞックぱヌゞェントから呌ばれる Lambda 内にありたす。そのために、Lambda 関数はたず、Amazon Bedrock ゚ヌゞェントにカスタムパラメヌタずしお枡された JWT をデコヌドしお゚ンティティ構造を構築し、呌び出し元のプリンシパルのアクセスを評䟡したす。リク゚ストされたデヌタには isAuthorized 呌び出しも含める必芁がありたす。このデヌタが Verified Permissions に枡されるず、提䟛されたコンテキストずポリシヌストア内のポリシヌを評䟡しアクセス可吊を決定したす。ポリシヌ決定ポむント (Policy Decision Point: PDP) ずしお、蚱可たたは拒吊の決定はアプリケヌションレベルで実斜する必芁があるこずに泚意したす。この決定に基づいお、デヌタぞのアクセスが蚱可たたは拒吊されたす。アクセスされるリ゜ヌスは、アプリケヌションがアクセス制埡を評䟡しやすいように分類する必芁がありたす。たずえば、デヌタが DynamoDB に保存されおいる堎合、患者は Verified Permissions スキヌマで定矩された階局的に参照されるパヌティションキヌで区切るこずも考えられたす。 結論 本ブログでは、AWS ネむティブサヌビスを䜿甚しお Amazon Bedrock ゚ヌゞェントを䜿甚するコンシュヌマヌアプリケヌション党䜓に階局化された認可を適甚するこずで、デヌタ保護を向䞊させる方法を孊びたした。たた、 アむデンティティプロセスを通じおアクセス制埡の適甚を改善する手順を説明したした。これは Amazon Bedrock ゚ヌゞェントを䜿甚しおアプリケヌションを構築するのに圹立ち、デヌタの匷力な分離を維持するこずで意図しない機密デヌタの挏掩を防ぐこずができたす。 Verified Permissions ず Amazon Bedrock ゚ヌゞェントを䜿甚しおアプリケヌション党䜓に階局化された認可を適甚する方法に぀いお詳しく孊ぶには、「 Secure Generative AI Solutions using OWASP Framework 」ワヌクショップをお勧めしたす。 本ブログに぀いお質問がある堎合は、 AWS サポヌトにお問い合わせください 。 Jeremy Ware Jeremy は、生成 AI ワヌクロヌドの ID アクセス管理ずセキュリティを専門ずするシニアセキュリティスペシャリスト゜リュヌションアヌキテクトです。Jeremy ず圌のチヌムは、AWS のお客様が高床でスケヌラブルで安党なワヌクロヌドを実装しおビゞネス䞊の課題を解決できるよう支揎しおいたす。Jeremy は長幎にわたり、倚くのグロヌバル䌁業でセキュリティの成熟床を向䞊させおきたした。自由時間には、Jeremy は家族ず䞀緒にアりトドアを楜しんでいたす。 Yuri Duchovny Yuri はニュヌペヌクを拠点ずするプリンシパル゜リュヌションアヌキテクトで、クラりドセキュリティ、アむデンティティ、コンプラむアンスを専門ずしおいたす。Yuri は倧䌁業のクラりド倉革を支揎し、䌁業が最適なテクノロゞヌず組織的な意思決定を行えるよう支揎しおいたす。AWS での職務に就く前は、アプリケヌションずネットワヌクのセキュリティ、DoS、䞍正防止に泚力をしおいたした。仕事以倖では、スキヌ、セヌリング、䞖界䞭ぞの旅行を楜しんでいたす。 Jason Garman Jason は、バヌゞニア州北郚に拠点を眮く AWS のプリンシパルセキュリティスペシャリスト゜リュヌションアヌキテクトです。Jason は、䞖界の倧手組織が重倧なセキュリティ課題を解決できるよう支揎しおいたす。AWS に入瀟する前にはサむバヌセキュリティ業界で、スタヌトアップを含む官民を問わないさたざたな圹割を果たしおいたした。圌は出版䜜家で、サむバヌセキュリティ技術に関する特蚱を保有しおおり、家族ず䞀緒に旅行するのが倧奜きです。 翻蚳はプロフェッショナルサヌビス本郚の池柀、藀浊が担圓したした。
Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. Panel Discussion: A History of Digital Transformation Forged with AWS Shimpei Otani, Group Executive Officer (CTO & CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. Shigeru Horikawa, Director (Infrastructure), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yasuhiro Kitaguchi, Director (SCM & Integration Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yuichi Murata, Director (Core Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Kempei Igarashi, Senior Manager, Retail, Consumer Goods & Services Business Group, Amazon Web Services Japan G.K. Career and Responsibilities of the Panelists First, the panelists talked about their own careers. Mr. Otani joined Fast Retailing in 2016 with a mission of internalizing engineering and embedding technology in the business. Currently he is the Chief Technology Officer and also in charge of security. Regarding the relationship with AWS, almost all Fast Retailing services run on AWS, leveraging it for over 12 years. He also shared the facts that he was actually an AWS Solutions Architect in his previous role and had visited Fast Retailing as a service provider during that time. Since joining in 2012, Mr. Horikawa has experienced shifting from on-premises to cloud, with 12 years of experience working with AWS. Entering a company like Fast Retailing meant a major shift in his goals as an engineer, from system implementation to business results themselves. Since joining in 2018, Mr. Kitaguchi has been responsible for developing common platforms and the data integration platform. Currently his focus is on logistics process reform and preparing digital tools. His AWS involvement began after joining Fast Retailing, consulting with AWS product teams when building new systems to determine optimal architectures. Mr. Murata joined in 2017 and experienced the Ariake Project from launch. Starting with developing back-end systems for e-commerce, he went through roles in infrastructure and quality assurance before becoming department manager overseeing in-house development (his current role). E-commerce heavily utilizes AWS with ongoing support. He also introduced a new initiative leveraging Amazon Connect to reform call center operations. Dawn Period – Fostering Culture The discussion began with the theme “Dawn Period – Fostering Culture”. Mr. Horikawa, with the longest tenure, looked back on episodes from when he joined. He learned AWS through seminars and vendor support. Before deciding to use AWS, he gained experience while receiving support from AWS Solutions Architects and others. Initially there were no architecture review processes, and failures like system outages due to lack of quality assurance occurred. Architecture reviews were born by learning from such failures. Mr. Otani shared stories about the Ariake automated warehouse project, which unlike IT projects, had physical constraints like installing the warehouse hardware, giving him a taste of the pains unique to an apparel company. The project was still chaotic then without a clear picture, but consistently recruiting talented people has created an environment conducive to exchanging wisdom. Addressing critical issues collaboratively naturally fostered the current culture. Mr. Horikawa also talked about negotiating with AWS over a 4TB database instance for an SAP implementation. At the time he believed it could only be done on-premises, but looking ahead to future growth, he negotiated with AWS and made it happen. This experience taught him that even seemingly impossible things could be achieved through proper negotiation. As described above, Fast Retailing fostered their current culture by overcoming various failures and challenges with AWS from the dawn period of adoption. Unafraid to challenge and collaborate to solve issues formed the foundation of their culture. Closely cooperating with AWS to nurture this new culture was a major factor enabling Fast Retailing’s digital transformation. Transition Period – Architectural Changes The next theme was the transition period when the team at Fast Retailing implemented many architectural changes. Mr. Murata discussed shifting from the conventional monolithic EC package to a headless platform architecture, achieving microservices, immutable infrastructure adoption, multi-region deployment, leveraging open source and managed services, and standardizing technology. He reflected on the complexity of business logic and challenges with performance and scalability. Mr. Kitaguchi explained how they initially started by just lifting and shifting their on-premise applications onto the cloud, and then gradually moved towards containerization and building CI/CD pipelines with global deployment in mind. Cost-conscious tool provision and close collaboration with business departments for cost awareness were also covered. Mr. Otani talked about standardization initiatives. The background of adopting Amazon Aurora and Amazon ElastiCache as a standard and establishing criteria for programming languages and frameworks was introduced. The struggles with proliferating tools seem to have driven the perception that some standardization is essential. On the other hand, Mr. Otani also pointed out the importance of maintaining appropriate flexibility in technology selection. Excessive standardization causes loss of flexibility, so preserving suitable options for engineers is also important. These standardization efforts occurred during large-scale concurrent development. Architectural transformation was carried out in stages looking ahead to global expansion, achieving a break-down into platforms and microservices, achieving standardization, etc. Expansion Period – Globalization Regarding globalization challenges, Mr. Murata talked about local considerations. They operate multiple brands across roughly 30 markets, requiring a global platform while also addressing needs from each country. Proper prioritization and efficiency are important, but a “global-solution” does not necessarily fit all regions. Aspects like delivery methods and data privacy handling require localization. Mr. Otani added that technical issues cannot always be decided solely by engineers, sometimes requiring management judgment considering geopolitical risks. Mr. Horikawa talked about network optimization changes. Initially all store communication concentrated to Tokyo, but now leveraging the AWS network fully, connecting each country directly to the nearest AWS Region improved speed and availability by utilizing the AWS backbone network. Mr. Kitaguchi said based on the characteristics of location-based systems with high customization and requirements variation, they take an approach of building global core aspects like consistent inventory management and streamlining shipping/receiving workflows, then adding localized custom wrappers. Cultural alignment is also important in multinational teams. Shared values represented in the mission statement foster decision-making and unity in diverse teams. Building an inclusive environment through mission sharing offers something to learn for any organization driving a cloud journey. Security Mr. Otani, also CSO, commented on security. Information systems today especially require enterprise-wide security uplift. Security encompasses many aspects beyond just technology, like executive awareness and physical measures. In addition to IT security, operational measures are indispensable for protecting customer information. Fast Retailing aims not just to meet IT security standards, but exceed them. He emphasized holistically addressing security aligned to corporate mission and ingraining appropriate standards into organizational culture. However, excessive security rigidness risks losing the creativity and added value that IT brings. Striking the right balance between security and IT flexibility is key, with an important security team role being to maintain that balance. Summary Closing comments by members are summarized as follows: Selecting cloud and platform products should consider not just current capabilities, but future evolution based on organizational culture. AWS was initially established to address the business challenges of Amazon, a company rooted in retail. AWS shares a customer-centric culture with Fast Retailing in many ways. Fast Retailing evaluated AWS as a company that continues to evolve in order to address customer needs. Reflecting on their 12-year collaboration, Fast Retailing aims to strengthen strategic partnership with AWS for global expansion. Finally, they concluded the panel discussion with a heartfelt message inviting engineers from diverse backgrounds to join them and grow the team. Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail
Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. The AWS Infrastructure Supporting Fast Retailing’s IT Shigeru Horikawa, Director, Infrastructure, Digital Business Transformation Services, Fast Retailing Co., Ltd. Mr. Horikawa from the Infrastructure team spoke about Fast Retailing’s history and the current status of AWS cloud utilization, as well as the ingenuity involved in operating a large-scale cloud environment with a small team. Fast Retailing needs to connect over 3,500 stores globally, support an ecommerce (EC) business in around 30 markets, and help sustain the entire supply chain, including warehouses and factories worldwide. To keep up with the rapid business expansion, instead of building data centers for each business, a cloud that can scale globally and procure infrastructure quickly became essential. A major reason for cloud adoption was the 2017 EC site downtime. Experiencing 3 days of downtime and facing issues like difficulty in on-premises capacity expansion and traffic control made them understand the need for cloud adoption. Fast Retailing’s cloud journey began around 2012 with the use of AWS for some campaign sites. In 2013, a cloud adoption project was launched in parallel with another initiative to modernize the existing legacy core systems. From 2016 to 2017, large-scale migration (lift & shift) from on-premises to cloud was carried out through the “Ariake Project” Around 2021, global expansion was accelerated further and AWS utilization expanded even more. The benefits of cloud adoption included: Scalability and capacity assurance: Easy scaling up and capacity expansion as needed Architecture modernization: Shift from legacy systems to modern architectures like microservices Securing engineers: Easier hiring of cloud engineers and improved acquisition of partners and developers Availability assurance: Establishment of cost-efficient backup sites across Availability Zones and regions for disaster recovery Infrastructure cost optimization: Adjust resources between peak and off-peak times to optimize infrastructure costs Current AWS usage includes over 60 accounts, 15+ regions, 13,000+ VMs, 3,000+ databases, and 120,000+ containers operated by a team of around 20 members. Various measures are taken to manage this large-scale infrastructure with a small team. Main initiatives include: Architecture reviews: Three review boards, Commerce, Enterprise, and CTO, review projects from planning to operational requirements and security from diverse perspectives Automation and codification: Adoption of Infrastructure as Code (IaC), cost management automation, standardized automated AWS account creation, etc. Self-service: Application teams can independently build, test, and deploy code with full responsibility on their part. Cost management: Visualize cost trends by system using tag-based cost allocation for application teams to manage costs with full responsibility on their part. Unified system monitoring platform: Consolidated disparate monitoring platforms so all the members can centrally view metrics and application behavior, reducing troubleshooting time Security measures: Leverage AWS security solutions for integrated multi-account security management. Aggregate security information into a security account integrated with a SIEM platform to enable early vulnerability detection and response Future initiatives include broader use of Kubernetes beyond ECS containers for more granular self-service parameter control, strengthening regional infrastructure teams to accelerate global expansion and achieve follow-the-sun operations, and building a global project promotion system. Through various measures like automation, self-service, and centralized monitoring, they have achieved large-scale cloud operations with a small team. Mr. Horikawa shared how companies accelerating global expansion can efficiently operate large-scale cloud environments using AWS. A Look Behind the Scenes of UNIQLO and GU’s E-Commerce Apps Shunsuke Akimoto, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Daisuke Sano, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, members of the Core Engineering team gave us a behind-the-scenes look at UNIQLO and GU’s e-commerce (EC) apps. First, Mr. Akimoto talked about a case of significant performance improvements and cost reductions in the cart function of the EC site. The cart function plays an important role when selecting and purchasing items on GU and UNIQLO apps and web services. The previous architecture had Application Load Balancer on top, with Amazon Elastic Container Service (Amazon ECS) below that, and the Amazon ECS API Service reading data from Amazon Aurora . However, with this configuration, the database became a bottleneck during traffic surges like popular item sales, causing response times to deteriorate significantly. There was also the issue that upgrading database instances increased costs, putting pressure on the infrastructure budget. To solve these issues, they decided to adopt Redis, a NoSQL database, as the main database. By using Amazon ElastiCache , they achieved major performance improvements while ensuring high scalability. The new architecture has the API Service directly reading and writing data to Amazon ElastiCache, with asynchronous data synchronization between Amazon ElastiCache and Amazon Aurora. This maximized the performance of Redis. Implementation ingenuity included creation of their own locking mechanism using Lua scripts and efficient extraction of updated carts using Redis Sorted Sets. Data migration was done with zero downtime, gradually migrating data to Redis while continuing operations. As a result, even with over double the traffic that previously caused issues, no performance degradation was observed. Response time improved significantly from over 10 seconds at p95 to 160ms, with potential for handling much larger traffic increases. Costs were also greatly reduced, with additional optimization through Amazon ElastiCache for Redis’ Data Tiering feature. Ultimately, database costs were reduced by over 60% with scalability assured for the next 10 years. They demonstrated how effectively leveraging cloud services can achieve both performance improvements and cost reductions simultaneously. Next, Mr. Sano talked about the search platform. Fast Retailing’s systems comprise interconnected microservices for each business function, with a data integration platform and API integration. The search platform is a microservice providing search functionality, utilizing inventory, pricing, product, and other information from other platforms. Main functions include keyword search, creating product lists for category pages, keyword suggestions, similar product listings, in-store inventory search, etc. Amazon OpenSearch Service is currently used by some platforms including the search platform. Three main features of Amazon OpenSearch Service are: Enabling registration of large amounts of data with flexible structures Enabling keyword search and flexible queries Fully managed service that easily scales in/out based on request volume Advantages of Amazon OpenSearch Service include high performance and scalability for read-heavy applications, and reducing development by having typical e-commerce search features built-in. Key requirements for global digital commerce search are efficiently supporting multiple brands, countries/regions, and language capabilities. These key requirements included: Functionality: Since building language-specific parsing in-house is difficult and inefficient, having built-in features like syntax analysis and normalization is important Ease of deployment: Adopting architecture where data automatically flows into Amazon OpenSearch Service Scalability: Easy scaling in/out Operability: Developing efficient tools for registering words and synonyms Future challenges include reducing operational costs of registering words and synonyms. Leveraging machine learning-based technologies (large language models, vector search, semantic search, etc.) are being considered to address future challenges. Other challenges are developing features to improve user experience beyond keyword search, and expanding to new regions in parallel with improving the search platform. Application Development Using Amazon ECS to Achieve Execution Control of Data Integration Infrastructure Kei Sakamoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Hirohito Yoshimoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, Mr. Sakamoto from the Integration Engineering Team introduced their data integration platform initiatives. The Integration Engineering Teams’ responsibilities include improving system development efficiency, as well as the development, management, and operational excellence of the data integration platform at Fast Retailing. As a digital consumer retailing company investing in end-to-end processes, data integration and batch processing became complex at large-scale. This required streamlining data, preparing tools for data utilization, and achieving high-speed processing to handle increasing data volumes after multi-brand launch and multinational expansion. They are addressing these challenges with two main concepts. First is preparing the batch processing framework, with a system that can control process dependencies and parallel distribution, organizing complex dependencies into more manageable forms. Second is preparing the data integration platform, building a cloud-native hub-and-spoke model platform to centrally manage all information and streamline data. Key features are easy routing control by definition, distributed deployment tailored to business domain characteristics, and covering various protocols and data formats. Four key requirements for this platform are: Stability: High stability required as it supports the business core Performance: Ability to plan for performance and capacity to withstand business fluctuations Portability: Easy distributed deployment Integration with diverse applications: Seamless integration with various applications Afterwards Mr. Yoshimoto introduced the specific architecture of the data integration platform, as well as challenges and ingenuity during development. The data integration platform is designed as a hub-and-spoke model system to efficiently integrate data between business domains, currently operating as 10 services across 2 clouds and 6 regions. Its development history began in 2015 as a batch processing platform, gradually expanding functionality to evolve into a data integration platform. Containerization and infrastructure codification were implemented in 2019, with enhanced multi-cloud support in 2021. Key considerations in development and operation include environmental reproducibility, scalability, ease of customization, cloud vendor independence, etc. Regarding task execution management using Amazon ECS, they independently implemented solutions to address issues like rate limits on API calls per time unit and difficulty with synchronous task status management. Specifically, the team wraps worker applications with a wrapper to operate as part of the overall framework, implementing a mechanism to synchronously grasp task status via heartbeats and callbacks. This avoids frequent polling queries to the ECS cluster for status checks, enabling more timely application execution monitoring and management. Three future challenges are: Further streamlining and self-service in deployment: Enabling business application teams to easily construct data integration mechanisms Enhancing integration with new services: Achieving stable integration with new digital reform services Promoting data utilization: Further integrating with data accumulation/analysis processes to create business value In closing, the speakers introduced how this initiative aimed to contribute to the business by consolidating complex data integration and batch processing, appropriately leveraging cloud services, and packaging as a solution. (To be continued in Part 3 ) Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail