TECH PLAY

AWS

AWS の技術ブログ

å…š3251ä»¶

アマゟン りェブ サヌビス ゞャパン以䞋、AWSは 2025 幎 5 月 30 日に、「 [教育業界向け] 手を動かしながら孊ぶデヌタ分析ワヌクショップ」を AWS Startup Loft Tokyo にお開催したした。 近幎、個別最適な孊びず協働的な孊びの実珟に向けお教育業界におけるデヌタ分析の重芁性が増しおいたす。 本むベントでは、初等䞭等教育、EdTech のシステム構築に関わるベンダヌ、パヌトナヌ䌁業の方々をお招きし、教育業界におけるデヌタ利掻甚や AWS における実珟方法に関しお振り返り぀぀、Amazon QuickSight を掻甚した教育デヌタ分析ダッシュボヌドの構築などをハンズオンを䜓隓しおいただきたした。圓日お集たりいただいた総勢 40 名以䞊の皆様には、改めお埡瀌申し䞊げたす。本ブログではその開催報告をお届けしたす。 オヌプニング AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 本郚長 束井䜑銬 むベント冒頭では、AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 本郚長 束井䜑銬がオヌプニングの挚拶を行いたした。 冒頭では、囜の教育 DX ロヌドマップ案を匕甚し、「孊ぶ人のためにあらゆるリ゜ヌスを」ずいう理念のもず、教育のデゞタル化ずデヌタ掻甚の党䜓像を玹介したした。校務負担の軜枛や倚様な孊習環境敎備を掚進するための教育デヌタの暙準化・分析の必芁性を匷調したした。 たた、AWS のツヌルやサヌビスを掻甚し、教育の質を向䞊させるためには、Amazon 瀟内で掻甚されおいる「Working Backwards」ずいうアプロヌチを参考に、理想的な教育環境を実珟するために必芁なステップを逆算し、そこから必芁なデヌタや分析方法を芋出しおいくこずの重芁性に぀いおも蚀及したした。 座孊パヌト「教育業界におけるデヌタ利掻甚」 AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 ゜リュヌションアヌキテクト 田村健祐 開催挚拶の埌は、「教育業界におけるデヌタ利掻甚」をテヌマにSA 田村により座孊パヌトを行いたした。 たず冒頭では、教育 DX の重芁なミッションである「誰もが、い぀でもどこからでも、誰ずでも、自分らしく孊べる瀟䌚」の実珟に向けたこれたでの取り組みに぀いお述べたした。GIGA スクヌル構想に始たり、教育デヌタ利掻甚ロヌドマップが策定され、これに基づいた斜策が実斜されおきたした。さらに珟圚は改蚂版である教育 DX ロヌドマップの策定が始たっおいたす。 続いお、「教育 DX ロヌドマップ」に基づいお、教育珟堎が抱える課題に぀いおの説明を行いたした。子䟛たちにずっおは「自分らしい孊び」や「自埋的な孊習」の実珟が課題ずなっおおり、教職員の方々は厳しい勀務実態の䞭で業務効率化が求められおいたす。 これらの課題に察しお、教育デヌタの掻甚は䞀぀の柱ずなりたす。特に教育デヌタ利掻甚では 3 ぀の重芁な取り組みが必芁ず考えられたす 教育サヌビスの盞互接続 校務支揎システムやデゞタル教科曞など、様々な教育システムの連携を目指す 教育デヌタの暙準化 䞻䜓情報、内容情報、掻動情報ずいった教育デヌタの xAPI 掻甚などの暙準化を進め、効率的なデヌタ掻甚を目指す デヌタ分析・掻甚の掚進 孊校・孊玚・個人レベルでのダッシュボヌド導入により、デヌタの可芖化ず掻甚の促進を目指す デヌタの掻甚により、子どもたちにずっおは個別最適な孊習支揎の実珟が期埅できたす。教職員にずっおは子どもたちや孊校の状況を即座に把握し、デヌタに基づいた支揎ができるため、業務効率や質の面での向䞊が芋蟌めたす。 教育珟堎のデゞタル化は着実に前進しおいたすが、䞊で述べたような教育珟堎が抱える課題を螏たえるず、デヌタ分析・掻甚のさらなる掚進が求められたす。 座孊パヌト「教育デヌタ掻甚のためのAWSアヌキテクチャ」 AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 ゜リュヌションアヌキテクト 倧南賢亮 続いお SA 倧南より、教育デヌタ掻甚のための AWS アヌキテクチャに぀いお、実践的な解説を行いたした。 教育珟堎でのデヌタ掻甚には、デヌタをさたざたな堎所からコピヌしおおり「正」のデヌタが䞍明確になりやすいこずや、分析手法の倉曎に察応できるデヌタの持ち方がされおいないこずなどの課題が挙げられたす。これらの課題に察しお、倚様なデヌタを䞀元的に保存する「デヌタレむク」ずいうアプロヌチが有効です。 しかし、実際にデヌタレむクを構築するには 、 デヌタの蓄積・分析・可芖化ずいった機胜を甚意する手間や、高い可甚性・拡匵性・性胜・セキュリティを担保するための管理負担の倧きさなど、技術的な課題も倚くありたす。 そこで AWS のマネヌゞドサヌビスを掻甚するこずで、効率的なデヌタレむク構築が可胜ずなりたす。具䜓的には Amazon S3 をコアのストレヌゞずしお掻甚 AWS Glue でデヌタカタログ化ず ETL 凊理を実珟 Amazon Athena でデヌタに察するク゚リを簡単に実行 Amazon QuickSight でのデヌタ可芖化 ずいった組み合わせで、包括的なデヌタ分析環境を構築できたす。 実際の掻甚案ずしお、xAPI 圢匏のスタディログ分析や教育ダッシュボヌドの構築を玹介したした。これらにより、孊習理解床の分垃や掚移、生掻蚘録ずの盞関など、倚角的な教育デヌタの分析が可胜ずなりたす。 たた、デヌタレむクのセキュリティずしお、文郚科孊省「教育デヌタ利掻甚に係る留意事項」に沿った個人情報・プラむバシヌ保護に察応するため、Amazon S3 Object Lock WORM : Write Once Read Many の実珟や、Amazon GuardDuty S3 Protectionデヌタ管理の脅嚁怜知などの機胜を掻甚できる点も玹介したした。 ハンズオンパヌト「デヌタのプロファむリングAWS Glue, AWS Glue DataBrew」 AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 ゜リュヌションアヌキテクト 秋山怜穏 ワヌクショップの埌半ではハンズオンパヌトずしお実際に AWS の Workshop 環境に觊りながら、参加者の皆さたず AWS におけるデヌタ分析環境の構築方法に぀いお孊びたした。ハンズオンでは、 こちら のコンテンツを甚い、倧孊の孊生情報システムおよび孊習管理システム䞊のデヌタを題材に AWS におけるデヌタのプロファむリングず可芖化の流れを䜓隓いただきたした。 たず、ハンズオンパヌトでは AWS Glue DataBrew を甚いおデヌタのプロファむリングを行う手順 Lab 4: デヌタプロファむリングを通じた孊生デヌタレむクの理解 を䜓隓いただきたした。 参加者の皆さんには、AWS Glue Data Catalog に栌玍された孊生テヌブルから DataBrew デヌタセットを䜜成しおいただき、本栌的なデヌタプロファむリングゞョブの蚭定を䜓隓しおいただきたした。 PII個人識別情報怜出機胜や重耇デヌタの特定、デヌタ間の盞関関係分析など、実際のデヌタ分析プロゞェクトで必芁ずなる高床な機胜を䞀通り詊しおいただきたした。セキュリティ面でも、KMS 暗号化や IAM ロヌルの適切な蚭定を通じお、デヌタガバナンスの重芁性を実践的に理解したした。 プロファむルゞョブの実行埌は、デヌタ品質サマリヌや倀分垃の可芖化結果を確認し、デヌタの特性を深く理解したした。生成AIを掻甚しながら分析結果から埗られるむンサむトを埗る段階たで䜓隓いただきたした。 ハンズオンパヌト 「デヌタの可芖化Amazon QuickSight、Q in QuickSight」 AWS ゞャパン 合同䌚瀟 パブリックセクタヌ技術統括本郚 教育・研究技術本郚 ゜リュヌションアヌキテクト 山本ひかる 続くハンズオンパヌトでは、ハンズオンパヌトで準備したデヌタを可芖化する手順 Lab 6孊生デヌタレむクの探玢、孊生デヌタレむクの可芖化 を参加者の皆さたず行いたした。 Amazon QuickSight の基本機胜や、 Amazon Q in QuickSight による生成 AI ずのコラボレヌションをご䜓隓いただきたした。 たずは、Amazon QuickSight アカりントの蚭定を行い、ナヌザヌの登録を行いたした。 その埌、ハンズオンパヌトで準備したデヌタぞのアクセス暩を付䞎し、Amazon QuickSight の「デヌタセット」ぞデヌタの取り組みを行いたす。デヌタの取り蟌み埌、「分析」の画面ぞ移り、ダッシュボヌドのためのビゞュアルの構築を行いたした。 ビゞュアルの構築では、孊生の人口統蚈の可芖化をテヌマに行いたした。䟋えば、孊生の男女比を瀺す円グラフ、孊郚・専攻別の first-generation student家庭で最初に孊䜍以䞊の課皋に進孊した孊生の割合を瀺すヒヌトマップ、孊生の出身州を瀺す地図䞊での可芖化、などを行いたした。 Amazon QuickSight の基本操䜜を䞀通り䜓隓いただいた埌は、 Amazon Q in QuickSight によるビゞュアルの構築に皆さたにご䜓隓いただきたした。 Amazon Q in QuickSight を䜿甚しおビゞュアルを構築・線集する Amazon Q in QuickSight を䜿甚しお蚈算フィヌルドを䜜成し、ビゞュアルで䜿甚する ダッシュボヌドに関する自然蚀語での Q&A 䜓隓 このように、ハンズオンパヌトでは、Amazon QuickSight の基本的な操䜜アカりントの蚭定、サンプルデヌタセット・分析・ダッシュボヌドの䜜成などに加え、Amazon Q in QuickSight による生成 AI ずのコラボレヌションによる BI 業務の効率化・ナヌザヌ゚クスペリ゚ンスの向䞊をご䜓隓いただきたした。 最埌に 本ワヌクショップを通じお、AWS のデヌタ分析サヌビスの基瀎から実践的な掻甚方法たでご玹介させおいただきたした。デヌタの蓄積から可芖化たで、AWS S3、Glue、Glue DataBrew、Athena、Amazon QuickSight ずいった各サヌビスを組み合わせるこずで、効率的なデヌタ分析基盀を構築できるこずをご確認いただけたかず思いたす。 倚くの䌁業様が「デヌタは持っおいるものの、どう掻甚すればよいかわからない」「BI ツヌルの導入に時間がかかりそう」ずいった課題を抱えおいらっしゃいたす。本ワヌクショップをきっかけに、AWS のデヌタ分析サヌビスを掻甚いただくこずで、皆様のデヌタ掻甚の第䞀歩を螏み出しおいただければ幞いです。 たずめ ワヌクショップ埌の懇芪䌚任意参加では、参加者の皆さたの間で掻発な意芋亀換が行われ、教育分野でのデヌタ掻甚に぀いおの具䜓的なディスカッションが展開されたした。この機䌚を通じお、参加者同士の貎重なネットワヌキングの堎ずなったこずを倧倉嬉しく思いたす。 AWS は今埌も、教育機関のデヌタ掻甚を支揎するため、様々なテクニカルセッションやコミュニティ掻動を継続しお実斜しお参りたす。 ご関心を持たれた方は、お気軜に お問い合わせ ください。教育のむノベヌションに取り組たれる皆さたのご参加をお埅ちしおおりたす。 次回の教育業界向けむベントにも、ぜひご期埅ください このブログは、 アマゟン りェブサヌビス ゞャパン 合同䌚瀟 パブリックセクタヌ 技術統括本郚 教育・研究技術本郚 ゜リュヌションアヌキテクト 秋山怜穏、山本ひかるが執筆したした。
革新的な AI を掻甚した゜リュヌションずお客様での実瞟により、AWS はメむンフレヌムモダナむれヌションにおける地䜍を匷化しおいたす 「AWS は AWS Blu Age ずパヌトナヌツヌルを含む最も幅広いポヌトフォリオを提䟛しおいたす。パフォヌマンス、セキュリティ、コンプラむアンスのためのモダナむれヌションずクラりド最適化の党䜓にわたっお、熟緎したコンサルタントず幅広い゚コシステムによっおお客様をサポヌトしたす。」— ISG 瀟の著名なアナリストであり、本ブログで取り䞊げたレポヌトの著者、Pedro L. Bicudo Maschio ISG は、米囜に斌けるメむンフレヌムアプリケヌションモダナむれヌション゜フトりェアを四象限に䜍眮付けた ISG Provider Lens の 2025 幎版レポヌトで、アマゟンりェブサヌビス (AWS) をリヌダヌに遞出したした。 ISG のレポヌトでは、以前から AWS がメむンフレヌムモダナむれヌションに斌けるリヌダヌずしお䜍眮付けられおおり、その連続蚘録を曎に䌞ばすものになりたす。これは、お客様のモダナむれヌションプロゞェクトを成功に導いた圓瀟の実蚌枈みの胜力ず、AWS Transform の远加によるポヌトフォリオの幅広さの䞡方を象城しおいたす。 今日、Transamerica、Allianz、Marriott Hotels など、䞖界䞭の倧䌁業のお客様が、メむンフレヌムベヌスの最も重芁なワヌクロヌドのモダナむれヌションに AWS を信頌しお採甚しおいたす。 2025 幎の ISG Provider Lens 調査では、21 瀟の゜フトりェアベンダヌを、競争力ずポヌトフォリオの魅力ずいう 2 ぀の重芁な偎面から評䟡したした。レガシヌメむンフレヌムアプリケヌションのトランスフォヌメヌションを加速させたいずいうお客様の需芁は、日に日に増しおいたす。この包括的な分析では、各プロバむダヌがメむンフレヌム゚コシステム内の耇雑さず技術的倚様性に察凊しながら、お客様からの芁求に応える胜力を調査したした。AWS は、その包括的な゜リュヌションポヌトフォリオ、継続的なむノベヌション、およびお客様で実蚌枈みの実瞟で際立っおいたした。 AWS Transform for Mainframe のトランスフォヌメヌション機胜 AWS Transform for Mainframe は、メむンフレヌム向けの初の゚ヌゞェント AI ゚クスペリ゚ンスであり、お客様がメむンフレヌムモダナむれヌションゞャヌニヌを加速できるよう支揎したす。コヌドベヌスの分析、ドキュメントの生成、モノリシック構造の分解、レガシヌコヌドの倉換、モダナむれヌションの党行皋の管理ずいった耇雑なタスクを自動化する専門の゚ヌゞェントが AWS で利甚できたす。たた、AWS Transform for Mainframe は、必芁な堎合にのみ人間の入力を䜿甚したす。 AWS Transform は、゚ンドツヌ゚ンドのモダナむれヌションタスクに䌎う耇雑さを解消する゚ヌゞェントフレヌムワヌクを通じお、お客様やパヌトナヌがメむンフレヌムモダナむれヌションのプロゞェクトを加速できるよう支揎したす。Amazon は、これたでに数䞇瀟のお客様をクラりドに移行しおきたした。AWS Transform は、Amazon の19幎にわたるクラりド移行の経隓を基に孊習した AI を掻甚しお、重芁なタスクを自動化したす。メむンフレヌムプログラムの詳现なドキュメントの䜜成や、モノリシックアプリケヌションの論理的なビゞネスグルヌプや機胜ぞの分解ずいった、時間が掛かる操䜜を迅速に実行できたす。 re: Invent 2024 で発衚された AWS Transform for Mainframe には、メむンフレヌムのお客様に代わっおむノベヌションず構築を続ける AWS の取り組みが反映されおいたす。メむンフレヌムモダナむれヌションは、これたで耇数幎にわたるプロゞェクトでした。AWS Transform を䜿っお、これらのプロゞェクトが耇数幎にわたる取り組みから耇数四半期にわたる取り組みぞず移行し、メむンフレヌムのお客様がレガシヌプラットフォヌムからの撀退ず AWS 掻甚によるむノベヌションに自信を付けた様子を目にしおいたす。 AWS Mainframe Modernization の実力 AWS は、Transamerica のようなお客様がメむンフレヌムシステムを AWS に移行しおバッチパフォヌマンスを 30% 向䞊させ、Visma のようなお客様が幎間 55% のコスト削枛を達成できるよう支揎しおきたした。AWS は、メむンフレヌムアプリケヌションの分析、移行、トランスフォヌメヌションを容易にする革新的なツヌルずサヌビスをお客様に提䟛するこずで、こうした成功事䟋を可胜にしおいたす。AWS では、お客様がリファクタリングパタヌンもしくはリプラットフォヌムパタヌンを遞ぶこずができたす。メむンフレヌムアプリケヌションを AWS のリレヌショナルデヌタベヌスを䜿甚するアプリケヌションに倉換する際に、Java たたは COBOL いずれにするかお客様が遞択できるようにしおいたす。お客様はアプリケヌションずデヌタに関する詳现な情報を埗るこずができ、移行埌は 200 を超える AWS クラりドサヌビスにアクセスできたす。 AWS は、お客様がメむンフレヌムモダナむれヌション目暙を達成できるよう支揎する専甚アクセラレヌタを提䟛しおいたす。たずえば、デヌタレプリケヌション機胜により、埓来のメむンフレヌムデヌタを AWS ずほがリアルタむムで同期できるため、組織は新しい機胜を開発したり、モダンなレポヌトシステムを実装したり、AI/ML 機胜を掻甚したりできたす。たた、ファむル転送機胜によっおクラりドぞのファむルの移動が効率化され、デヌタモダナむれヌションの可胜性が広がりたす。最埌に、アセンブラの倉換機胜により、移行プロゞェクト䞭にメむンフレヌムのアセンブラコヌドを COBOL たたは Java に容易に倉換できるため、モダナむれヌションの耇雑さが軜枛されたす。 ISG による四象限分析を確認しおみたしょう ISG による四象限分析の無料レポヌト を読んで、ISG が AWS をメむンフレヌムモダナむれヌションのリヌダヌず評䟡した理由をご芧ください。 最新の ISG Provider Lens レポヌトには、メむンフレヌムモダナむれヌション゜リュヌションを取り巻く業界の倉化が瀺されおいたす。組織がデゞタルトランスフォヌメヌションぞの取り組みを加速するに぀れお、信頌性が高くスケヌラブルなメむンフレヌムモダナむれヌションサヌビスに察する需芁は高たり続けおいたす。次の分析図は、ISG レポヌトからの抜粋です。 図 1. ISG Provider Lens は、AWS を 2025 幎の米囜垂堎向けのメむンフレヌムアプリケヌションモダナむれヌション゜フトりェア゜リュヌションのリヌダヌずしお䜍眮付けおいたす。この四象限分析では、競争力ずポヌトフォリオの魅力に基づいおベンダヌを評䟡したす。 著者 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、メむンフレヌムずレガシヌのモダナむれヌションを専門ずしおいたす。Tim は䞖界䞭のお客様やパヌトナヌず協力しお、メむンフレヌムアプリケヌションを倉革するための革新的な戊略を開発しおいたす。ティムはメむンフレヌム・モダナむれヌション業界に 7 幎以䞊携わり、AstadiaAmdocs により買収ず IBM に勀務しおきたした。AWS では、お客様やパヌトナヌがより早く結果を出せるよう支揎する、拡匵性の高いモダナむれヌション戊略の構築に泚力しおいたす。 Phil de Valence Phil de Valence は、AWS Mainframe Modernization サヌビスのプロダクトマネゞメントをリヌドしおいたす。Phil は 22 幎以䞊にわたっおメむンフレヌムに関わり、䞻に䞖界䞭の䌁業顧客向けのモダナむれヌションの取り組みをリヌドしおきたした。メむンフレヌムに関する 9 冊の著曞 (IBM Redbooks) を共同執筆し、AWS のモダナむれヌションに関する 50 以䞊の蚘事やビデオを出版し、AWS re: Invent、Micro Focus Universe、SHARE、IBM Impact などのカンファレンスで発衚しおきたした。珟圚の圹職では、ビゞネス䟡倀を最倧限に匕き出すために、メむンフレヌムアプリケヌションのモダナむれヌションを加速させるむノベヌションの構築に泚力しおいたす。メむンフレヌムずレガシヌシステムに察する AWS の䟡倀提瀺を最倧限に掻甚する方法に぀いお、お客様やパヌトナヌに助蚀しおいたす。 Rao Panchomarthi グロヌバルのメむンフレヌムモダナむれヌション組織のリヌダヌ。Rao は、IBM メむンフレヌム、分散システム、クラりドテクノロゞヌにたたがる 20 幎以䞊の経隓を持぀経隓豊富な IT プロフェッショナルです。Rao は倧芏暡なビゞネストランスフォヌメヌションをリヌドし、メむンフレヌムアプリケヌションのクラりドテクノロゞヌぞの移行や、モダナむズするための戊略を策定しおいたす。AWS に入瀟する前は、JPMorgan Chase のクレゞットカヌド事業でアヌキテクチャ責任者を務め、耇数のトランスフォヌメヌションプロゞェクトをリヌドしおいたした。 この投皿の翻蚳は Mainframe Modernization Specialist Solutions Architect の皆川が担圓臎したした。原文蚘事は こちら です。
sort コンパクションず z-order コンパクションを䜿甚しお、 Amazon S3 Tables ず 汎甚 S3 バケット での Apache Iceberg ク゚リパフォヌマンスを向䞊させるこずが可胜になりたした。 通垞、Iceberg は AWS Glue デヌタカタログ や S3 Tables で Amazon Simple Storage Service (Amazon S3) 内の倧芏暡な分析デヌタセットを管理するために䜿甚したす。Iceberg テヌブルは、同時ストリヌミングやバッチむンゞェスト、スキヌマ進化、タむムトラベルなどのナヌスケヌスをサポヌトしたす。高むンゞェストたたは頻繁に曎新されるデヌタセットを扱うずきは、デヌタレむクに倚数の小さなファむルが蓄積される堎合があり、ク゚リのコストやパフォヌマンスに圱響を及がしたす。皆さんからは、Iceberg のデヌタレむアりトの最適化は操䜜が耇雑で、倚くの堎合にカスタムパむプラむンの開発ず維持が必芁になるずいうご意芋をいただいおいたす。マネヌゞドコンパクションでのデフォルトの binpack 戊略はパフォヌマンスを倧幅に向䞊させたすが、S3 ず S3 Tables の䞡方に sort および z-order のコンパクションオプションを導入するず、1 ぀、たたは耇数のディメンション党䜓をフィルタリングするク゚リのパフォヌマンスがさらに倧きく向䞊したす。 2 ぀の新しいコンパクション戊略: Sort ず z-order デヌタをより効率的に敎理するため、Amazon S3 では、デフォルトの binpack コンパクションに加えお、 sort ず z-order の 2 ぀の新しいコンパクション戊略がサポヌトされるようになりたした。これらの高床な戊略は、 AWS Glue デヌタカタログ による最適化を通じお、フルマネヌゞド型の S3 Tables ず、汎甚 S3 バケット内の Iceberg テヌブルの䞡方で利甚できたす。 Sort コンパクションは、ナヌザヌ定矩の列順序に基づいおファむルを敎理したす。テヌブルに゜ヌト順序が定矩されおいる堎合、S3 Tables コンパクションはコンパクションプロセス時にその゜ヌト順序を䜿甚しお、類䌌する倀をクラスタヌ化するようになりたす。これは、スキャンされるファむルの数を枛らすこずでク゚リの実行効率性を向䞊させたす。䟋えば、 state や zip_code による sort コンパクションでテヌブルが敎理されおいる堎合、これらの列をフィルタリングするク゚リでスキャンされるファむル数が枛るため、レむテンシヌずク゚リ゚ンゞンコストが䜎枛したす。 Z-order コンパクションは、耇数のディメンション党䜓で効率的なファむルプルヌニングを有効にするこずで、ファむルをさらに敎理したす。この戊略は、耇数の列からの倀の二進数衚珟を゜ヌト可胜な単䞀のスカラヌにむンタヌリヌブするため、空間ク゚リや倚次元ク゚リには特に有甚です。䟋えば、ワヌクロヌドに pickup_location 、 dropoff_location 、および fare_amount で同時にフィルタリングするク゚リが含たれる堎合に z-order コンパクションを䜿甚するず、スキャンされるファむルの総数を埓来の゜ヌトベヌスのレむアりトよりも少なくするこずができたす。 S3 Tables は、Iceberg テヌブルのメタデヌタを䜿甚しお珟行の゜ヌト順序を刀断したす。テヌブルに゜ヌト順序が定矩されおいる堎合は、継続的なメンテナンス時に sort コンパクションが自動的に適甚されるため、アクティブ化するための远加蚭定は必芁ありたせん。 z-order を䜿甚するには、S3 Tables API を䜿甚しおテヌブルのメンテナンス蚭定を曎新し、戊略を z-order に蚭定する必芁がありたす。汎甚 S3 バケット内の Iceberg テヌブルの堎合は、コンパクション蚭定を曎新するこずで、最適化の最䞭に sort たたは z-order コンパクションを䜿甚するように AWS Glue デヌタカタログを蚭定できたす。 sort たたは z-order の察象ずなるのは、これらを有効化した埌で曞き蟌たれた新しいデヌタのみです。コンパクション実斜枈みの既存ファむルは、テヌブルのメンテナンス蚭定でタヌゲットファむルのサむズを倧きくするか、暙準の Iceberg ツヌルを䜿甚しおデヌタを曞き換えるこずでファむルを明瀺的に曞き換える堎合を陀き、そのたた倉曎されたせん。この動䜜は、い぀、どのくらいのデヌタを敎理し盎すかをナヌザヌが制埡しお、コストずパフォヌマンスのバランスを取るこずができるように蚭蚈されたものです。 実際の動䜜を芋おみたしょう ここでは、Apache Spark ず AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚するシンプルな䟋を説明しおいきたす。むンストヌル枈みの Spark クラスタヌず S3 テヌブルバケットを甚意したした。 testnamespace 内には testtable ずいう名前のテヌブルがありたす。テヌブルにデヌタを远加できるように、コンパクションを䞀時的に無効にしたした。 デヌタを远加したら、テヌブルのファむル構造を確認したす。 spark.sql(""" SELECT substring_index(file_path, '/', -1) as file_name, record_count, file_size_in_bytes, CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name, CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name FROM ice_catalog.testnamespace.testtable.files ORDER BY file_name """).show(20, false) +--------------------------------------------------------------+------------+------------------+----------------+----------------+ |file_name |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name| +--------------------------------------------------------------+------------+------------------+----------------+----------------+ |00000-0-66a9c843-5a5c-407f-8da4-4da91c7f6ae2-0-00001.parquet |1 |837 |Quinn |Quinn | |00000-1-b7fa2021-7f75-4aaf-9a24-9bdbb5dc08c9-0-00001.parquet |1 |824 |Tom |Tom | |00000-10-00a96923-a8f4-41ba-a683-576490518561-0-00001.parquet |1 |838 |Ilene |Ilene | |00000-104-2db9509d-245c-44d6-9055-8e97d4e44b01-0-00001.parquet|1000000 |4031668 |Anjali |Tom | |00000-11-27f76097-28b2-42bc-b746-4359df83d8a1-0-00001.parquet |1 |838 |Henry |Henry | |00000-114-6ff661ca-ba93-4238-8eab-7c5259c9ca08-0-00001.parquet|1000000 |4031788 |Anjali |Tom | |00000-12-fd6798c0-9b5b-424f-af70-11775bf2a452-0-00001.parquet |1 |852 |Georgie |Georgie | |00000-124-76090ac6-ae6b-4f4e-9284-b8a09f849360-0-00001.parquet|1000000 |4031740 |Anjali |Tom | |00000-13-cb0dd5d0-4e28-47f5-9cc3-b8d2a71f5292-0-00001.parquet |1 |845 |Olivia |Olivia | |00000-134-bf6ea649-7a0b-4833-8448-60faa5ebfdcd-0-00001.parquet|1000000 |4031718 |Anjali |Tom | |00000-14-c7a02039-fc93-42e3-87b4-2dd5676d5b09-0-00001.parquet |1 |838 |Sarah |Sarah | |00000-144-9b6d00c0-d4cf-4835-8286-ebfe2401e47a-0-00001.parquet|1000000 |4031663 |Anjali |Tom | |00000-15-8138298d-923b-44f7-9bd6-90d9c0e9e4ed-0-00001.parquet |1 |831 |Brad |Brad | |00000-155-9dea2d4f-fc98-418d-a504-6226eb0a5135-0-00001.parquet|1000000 |4031676 |Anjali |Tom | |00000-16-ed37cf2d-4306-4036-98de-727c1fe4e0f9-0-00001.parquet |1 |830 |Brad |Brad | |00000-166-b67929dc-f9c1-4579-b955-0d6ef6c604b2-0-00001.parquet|1000000 |4031729 |Anjali |Tom | |00000-17-1011820e-ee25-4f7a-bd73-2843fb1c3150-0-00001.parquet |1 |830 |Noah |Noah | |00000-177-14a9db71-56bb-4325-93b6-737136f5118d-0-00001.parquet|1000000 |4031778 |Anjali |Tom | |00000-18-89cbb849-876a-441a-9ab0-8535b05cd222-0-00001.parquet |1 |838 |David |David | |00000-188-6dc3dcca-ddc0-405e-aa0f-7de8637f993b-0-00001.parquet|1000000 |4031727 |Anjali |Tom | +--------------------------------------------------------------+------------+------------------+----------------+----------------+ only showing top 20 rows テヌブルが耇数の小さなファむルで構成されおおり、新しいファむルの䞊限倀ず䞋限倀が重耇しおいるこずがわかりたす。デヌタは明らかに゜ヌトされおいたせん。 テヌブルの゜ヌト順序を蚭定したす。 spark.sql("ALTER TABLE ice_catalog.testnamespace.testtable WRITE ORDERED BY name ASC") テヌブルコンパクションを有効にしたす (デフォルトで有効になっおいたすが、このデモの最初に無効化したした)。 aws s3tables put-table-maintenance-configuration --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable --type icebergCompaction --value "status=enabled,settings={icebergCompaction={strategy=sort}}" 有効にしたら、次のコンパクションゞョブがトリガヌされるのを埅ちたす。十分な数の小さなファむルが存圚する堎合、ゞョブは䞀日䞭実行されたす。コンパクションステヌタスは、次のコマンドを䜿甚しお確認できたす。 aws s3tables get-table-maintenance-job-status --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable コンパクションが完了したら、テヌブルを構成するファむルをもう䞀床調べたす。デヌタが 2 ぀のファむルにコンパクションされおおり、䞊限倀ず䞋限倀がこれら 2 ぀のファむル党䜓でデヌタが゜ヌトされたこずを瀺しおいたす。 spark.sql(""" SELECT substring_index(file_path, '/', -1) as file_name, record_count, file_size_in_bytes, CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name, CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name FROM ice_catalog.testnamespace.testtable.files ORDER BY file_name """).show(20, false) +------------------------------------------------------------+------------+------------------+----------------+----------------+ |file_name |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name| +------------------------------------------------------------+------------+------------------+----------------+----------------+ |00000-4-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|13195713 |50034921 |Anjali |Kelly | |00001-5-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|10804307 |40964156 |Liza |Tom | +------------------------------------------------------------+------------+------------------+----------------+----------------+ ファむルの数が少なく、ファむルのサむズが倧きくなっおいお、指定した゜ヌト列党䜓でクラスタリングが改善されおいたす。 z-order の䜿甚にも同じ手順を実行したすが、その堎合はメンテナンス蚭定で strategy=z-order を蚭定したす。 利甚可胜なリヌゞョン Sort コンパクションず z-order コンパクションは、 Amazon S3 Tables がサポヌトされるすべおの AWS リヌゞョン で利甚でき、AWS Glue デヌタカタログによる最適化が利甚可胜な汎甚 S3 バケットにも利甚できたす。S3 Tables に関しおは、既存の䜿甚量ずメンテナンス料金以倖の远加料金はかかりたせん。デヌタカタログによる最適化に関しおは、コンパクション時にコンピュヌティング料金が適甚されたす。 これらの倉曎により、 sort 列たたは z-order 列でフィルタリングするク゚リは、より高速なク゚リ時間ず゚ンゞンコストの削枛からメリットを埗られたす。私の経隓では、 binpack から sort たたは z-order に切り替えるずきに、デヌタレむアりトずク゚リパタヌンに応じお、3 倍以䞊のパフォヌマンス向䞊を確認できたした。実際のデヌタでパフォヌマンスがどれだけ向䞊したかをぜひ教えおください。 詳现に぀いおは、 Amazon S3 Tables の補品ペヌゞにアクセスするか、「 S3 Tables のメンテナンス 」ドキュメントをご芧ください。S3 Tables API たたは AWS Glue による最適化 を䜿甚しお、今すぐ独自のテヌブルで新しい戊略のテストを開始するこずも可胜です。 – seb 原文は こちら です。
6 月 16 日週のメむンむベントは、セキュリティに焊点を圓おた AWS re:Inforce カンファレンス でした。 ブログチヌムは、今では颚物詩ずなった re: Cap 蚘事を曞いお、発衚を芁玄し、トップブログ蚘事ぞのリンクを掲茉したした 。 それをさらに芁玄するず、 匷化された IAM Access Analyzer 機胜 、 ルヌトナヌザヌに察する MFA の矩務付け 、 AWS Network Firewall ぞの脅嚁むンテリゞェンス統合 ずいった新しいセキュリティむノベヌションがいく぀か発衚されたした。その他の泚目すべき曎新には、 AWS Certificate Manager から゚クスポヌト可胜なパブリック SSL/TLS 蚌明曞 、 簡玠化された AWS WAF コン゜ヌル゚クスペリ゚ンス 、 プロアクティブなネットワヌクセキュリティのための新しい AWS Shield 特城量 (プレビュヌ䞭) などがありたす。さらに、 AWS Security Hub がリスクの優先順䜍付けで匷化され (プレビュヌ䞭)、 Amazon GuardDuty が Amazon EKS クラスタヌをサポヌトするようになりたした 。 なかでも、私のお気に入りの発衚は Amazon Verified Permissions チヌムからの発衚です。このチヌムは、 Express.js 甚のオヌプン゜ヌスパッケヌゞをリリヌスしお、 開発者がりェブアプリケヌション API に倖郚のきめ现かな認可を実装できるようにしたした 。これによっお認可の統合が簡玠化されるため、コヌドの耇雑性が軜枛し、アプリケヌションのセキュリティが向䞊したす。 Amazon Verified Permissions チヌムは、 Verified Permissions ポリシヌストアを䜜成し、Cedar および Verified Permissions 認可ミドルりェアをアプリに远加しおから、Cedar スキヌマを䜜成しおデプロむし、Cedar ポリシヌを䜜成しおデプロむする方法 の抂芁をたずめたブログも公開したした。Cedar スキヌマは OpenAPI 仕様から生成され、 AWS コマンドラむンむンタヌフェむス (CLI) で䜿甚できるようにフォヌマットされおいたす。 では、6 月 16 日週に行われたその他の新しい発衚を芋おみたしょう。 6 月 16 日週のリリヌス re:Inforce 以倖にも、私が泚目したリリヌスをいく぀かご玹介したす。 AWS Lambda が Avro 圢匏ず Protobuf 圢匏の Kafka むベントのネむティブサポヌトを発衚 – AWS Lambda が、Apache Kafka の event-source-mapping (ESM) で、 Avro 圢匏ず Protobuf 圢匏の Kafka むベントをネむティブにサポヌトするようになりたした。この統合により、オヌプン゜ヌスの Kafka コンシュヌマヌむンタヌフェむスを䜿甚しお、スキヌマの怜蚌、むベントのフィルタリング、むベントの凊理を実行できるようになりたす。たた、 Powertools for AWS Lambda を䜿甚しお、カスタム逆シリアル化コヌドを蚘述せずに Kafka むベントを凊理するこずもできるため、AWS Lambda での Kafka アプリケヌションの構築が容易になりたす。 Kafka のお客様は、効率的なデヌタストレヌゞ、迅速なシリアル化ず逆シリアル化、スキヌマ進化のサポヌト、異なるプログラミング蚀語間の盞互運甚性のために Avro 圢匏ず Protobuf 圢匏を䜿甚しおおり、デヌタが凊理パむプラむンに入る前に、スキヌマレゞストリを利甚しおスキヌマの管理、進化、怜蚌を行っおいたす。これたで、これらのデヌタ圢匏を䜿甚するずきは、むベントを怜蚌、逆シリアル化、フィルタリングするためのカスタムコヌドを Lambda 関数内に䜜成する必芁がありたした。今回のロヌンチにより、Lambda は Avro ず Protobuf に加えお、GSR、CCSR、SCSR ずの統合もネむティブにサポヌトするようになりたした。こうしたサポヌトにより、カスタムコヌドを蚘述しなくおも、これらのデヌタ圢匏を䜿甚しお Kafka むベントを凊理できるようになりたす。さらに、䞍芁な関数呌び出しを防ぐためのむベントフィルタリングを䜿甚しお、コストを最適化するこずも可胜です。 Amazon S3 Express One Zone が単䞀の API コヌルによるオブゞェクトのアトミックな名前倉曎をサポヌト – RenameObject API は、耇数のステップが䌎う名前倉曎操䜜を単䞀の API コヌルに倉換するこずで、S3 ディレクトリバケットでのデヌタ管理を簡玠化したす。぀たり、既存オブゞェクトの名前を゜ヌスずしお指定し、新しい名前を同じ S3 ディレクトリバケット内の宛先ずしお指定するこずで、S3 Express One Zone 内のオブゞェクトの名前を倉曎できるようになりたす。デヌタの移動が䞍芁なこの機胜は、ログファむル管理、メディア凊理、デヌタ分析ずいったアプリケヌションを加速しながら、コストを削枛したす。䟋えば、1 テラバむトのログファむルの名前倉曎なら数時間ではなく数ミリ秒で完了できるようになるため、アプリケヌションの倧幅な高速化ずコスト削枛に぀ながりたす。 Valkey が Go、OpenTelemetry、パむプラむンバッチ凊理をサポヌトする GLIDE 2.0 を発衚 – AWS は、Google および Valkey コミュニティず共同で、General Language Independent Driver for the Enterprise (GLIDE) 2.0 の䞀般提䟛開始を発衚したした。これは、AWS の公匏オヌプン゜ヌス Valkey クラむアントラむブラリの最新リリヌスです。Redis の代わりに䜿甚でき、蚱容床が最も高いオヌプン゜ヌスである Valkey は、 Linux Foundation が管理しおおり、これからもオヌプン゜ヌスずしお提䟛され続けたす。すべおの Valkey コマンドをサポヌトする Valkey GLIDE は、信頌性に優れた高性胜倚蚀語クラむアントです。 GLIDE 2.0 には、開発者サポヌトを拡倧し、オブザヌバビリティを向䞊させ、高スルヌプットワヌクロヌドのパフォヌマンスを最適化する新しい機胜が導入されおいたす。Valkey GLIDE 2.0 は、Java、Python、Node.js の倚蚀語サポヌトを Go (Google 提䟛) にも拡匵しお、4 ぀の蚀語党䜓で䞀貫性のある完党互換の API ゚クスペリ゚ンスを提䟛したす。今埌さらに倚くの蚀語がサポヌトされる予定です。今回のリリヌスにより、Valkey GLIDE は OpenTelemetry をサポヌトするようになりたした。OpenTelemetry はオヌプン゜ヌスのベンダヌニュヌトラルなフレヌムワヌクで、開発者がテレメトリデヌタやクラむアント偎の重芁なパフォヌマンスむンサむトを生成、収集、゚クスポヌトするこずを可胜にしたす。さらに、GLIDE 2.0 ではバッチ凊理機胜も導入されたした。この機胜は、耇数のコマンドをグルヌプ化しお単䞀の操䜜ずしお実行できるようにするこずで、高頻床ナヌスケヌスのネットワヌクオヌバヌヘッドずレむテンシヌを軜枛したす。 Valkey GLIDE の詳现に぀いおは、最新の AWS Developers Podcast ゚ピ゜ヌド「 Inside Valkey GLIDE: building a next-gen Valkey client library with Rust 」をお聞きください。 AWS からのお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞを随時ご確認ください。 その他の読み物 私のベルギヌ同胞である Alexis が、 ストリヌミング可胜な HTTP トランスポヌトを䜿甚しお MCP ツヌルサヌバヌを開発し、Lambda ず API Gateway にデプロむする方法 を説明する 2 郚構成シリヌズの最初の蚘事を曞きたした。これは、AWS で MCP サヌバヌを実装する人にずっお必読の蚘事です。私は、Alexis がリモヌト MCP サヌバヌの認蚌ず認可に぀いお説明する第 2 郚をずおも楜しみにしおいたす。 その他の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 コラボレヌションスペヌスであり、没入型゚クスペリ゚ンスでもある AWS GenAI Lofts  ã¯ã€ã‚¯ãƒ©ã‚Šãƒ‰ã‚³ãƒ³ãƒ”ュヌティングず AI に関する AWS の専門知識を玹介し、AI 補品やサヌビスを実際に䜿甚する機䌚、業界リヌダヌずの独占セッション、投資家や同業他瀟ずの貎重なネットワヌキングする機䌚をスタヌトアップや開発者に提䟛したす。  お近くの GenAI Loft 開催地を芋぀けお 、忘れずに登録したしょう。 AWS Summit は、クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトしお、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントです。 日本 ( 6 月 2526 日)、 むンド (オンラむン: 6 月 26 日)、 ニュヌペヌク (7 月 16 日) など、最寄りのむベントにご登録ください。 7 月ず 8 月に開催される 台北 (7 月 29 日)、ゞャカルタ (8 月 7 日)、メキシコ (8 月 8 日)、サンパりロ (8 月 13 日)、ペハネスブルグ (8 月 20 日)の Summit もスケゞュヌルに入れおおきたしょう。9 月ず 10 月にはさらなる Summit が予定されおいたす。 近日開催予定のすべおの AWS 䞻導の察面およびバヌチャルむベントは、こちら でご芧ください。 今週のニュヌスは以䞊です。6 月 30 日週に再びアクセスしお、新たな Weekly Roundup をぜひお読みください! – seb この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
1むントロダクション H.U.グルヌプは、「ヘルスケアにおける新しい䟡倀の創造を通じお、人々の健康ず医療の未来に貢献するこず」をMissionに掲げる䌁業グルヌプです。圓グルヌプでは、怜査・関連サヌビス事業、臚床怜査薬事業、ヘルスケア関連サヌビス事業の3぀を䞻軞ずし、医療に関する様々な補品やサヌビスを提䟛しおいたす。 そしお我々が所属するH.U.グルヌプ䞭倮研究所では、サむ゚ンスを起点ずしお新たなシヌズの探玢や新芏事業の創出を目指し掻動しおいたす。その䞭でもバむオむンフォマティクス課では、オミックス解析に関する研究開発や、解析環境の開発ず実装などに取り組んでいたす。 今回、オミックス解析の䞭でも、ゲノム解析の情報凊理工皋をリアルタむムか぀自動で実行する解析環境の開発ず技術怜蚌を実斜したしたので、本ブログでその取り組みをご玹介いたしたす。 2背景 ヒトや现菌、りむルスなどのゲノムデヌタからは非垞に倚くの情報を埗るこずができ、疟患の蚺断や治療、感染症の远跡や制埡、新薬開発などに圹立぀こずから、医療におけるゲノム解析の需芁は幎々高たっおきおいたす。 ゲノムデヌタを解析する遺䌝子怜査にはいく぀かの方法がありたす。その䞭でも、次䞖代シヌク゚ンサヌ (NGS) ず呌ばれるDNAやRNAの塩基配列を高速か぀倧芏暡に決定する技術を甚いた解析では、出力されるデヌタ量が膚倧で耇雑な蚈算を行うため、蚈算リ゜ヌスの確保が必須です。 匊瀟では、研究開発や事業郚門においおヒトゲノムシヌク゚ンスや腞内现菌叢解析などほが党おの解析をオンプレミスサヌバヌで実斜しおいたすが、ストレヌゞや蚈算リ゜ヌスを需芁に合わせお柔軟に調敎するこずが難しく、蚈算リ゜ヌスの過䞍足が生じおしたう課題がありたした。 たた、ゲノムデヌタの解析は耇数の工皋を経お行われ、コマンドラむンを甚いた操䜜も必芁です。瀟内研修による怜査員の技術取埗も進めおいたすが、怜査需芁の急増に察応した人員の育成・拡充には時間を芁したす。そのため、解析の実行自䜓も倧きなハヌドルずなっおいたした。 これらの課題を解決するために、柔軟に解析環境をスケヌルでき、ゲノムデヌタ解析の䞀連の工皋を自動化した解析環境の開発に取り組みたした。開発にあたり、倚様なサヌビスやオミックスデヌタ解析で豊富な実瞟を有するAWSを利甚したした。 3技術怜蚌の詳现 3-1構築環境の抂芁 我々は、AWSマネヌゞドサヌビスを利甚し、以䞋の機胜をも぀解析環境を実珟したした。 シヌク゚ンスデヌタのクラりドぞの転送から解析たでの党工皋を自動化 サンプル数やプロセスに応じた柔軟な解析リ゜ヌスの立ち䞊げ 解析状況の確認のための情報の集玄 解析状況をナヌザヌぞ通知 今回の怜蚌で䜿甚したシヌク゚ンサヌの特城ずしお、経時的にシヌク゚ンスの生デヌタが出力され、実隓者がシヌク゚ンスを停止させるたでデヌタが出力されたす。この経時的に出力されるデヌタを郜床自動的に解析するこずで、人の手を介さずにほがリアルタむムでの解析を実珟したした。たた、取埗されたデヌタ量に぀いおナヌザヌにメヌル通知を送る機胜を実装したした。これたで実隓者がシヌク゚ンスの状況や取埗デヌタ量を目芖で確認しおいたしたが、自動で取埗デヌタ量を確認するこずで、実隓者の䜜業削枛にも繋がりたした。さらに、実隓者は必芁デヌタ量の取埗が完了したこずを通知で容易に把握でき、より適切なタむミングでシヌク゚ンスを停止するこずも可胜になりたした。 解析を党お自動化するず、珟圚の解析状況の把握が難しくなるため、プロセス毎に䜜成されるファむルの出力状況を集玄し、進捗を確認するためのデヌタベヌスを䜜成したした。このデヌタベヌスは進捗状況の把握だけでなく、解析に芁した時間の集蚈などにも掻甚が可胜です。 これらの機胜を実珟する解析環境の構築は、党お研究開発員による内補開発で行いたした。 3-2゜リュヌション抂芁 䞊蚘の機胜を実珟するにあたり、各工皋で以䞋のAWSサヌビスを利甚したした。 【構成図】 Amazon Simple Storage Service (Amazon S3) ぞのデヌタ転送 AWS DataSync を利甚し、シヌク゚ンスの生デヌタをオンプレミスからS3ぞ転送したす。DataSyncのタスク䜜成や実行はオンプレミスで䜜成したスクリプトで自動化したした。 各皮凊理の自動実行 AWS䞊で行う各皮凊理は AWS Lambda で実行を管理したした。 キヌずなるファむルがS3に䜜成されたこずを Amazon EventBridge で怜出し、 AWS Step Functions を介しお各凊理のLambda関数が実行されたす。 Lambda関数は機胜ごずに分割しお実装するこずで、開発やトラブルシュヌティング時の切り分けを容易にしたした。たた、それら耇数の関数を効率的に連携・管理するために、Step Functionsを掻甚しおいたす。 解析の実斜 AWS Lambdaで AWS Batch ゞョブがキックされるず、解析パむプラむンが実行されたす。 解析パむプラむンはNextflowずDockerを䜿甚しお䜜成しおおりたす。Dockerむメヌゞは Amazon Elastic Container Registry (Amazon ECR) に栌玍し、解析時にはむメヌゞからコンテナを䜜成しお解析が行われたす。これにより、サンプル数や解析プロセスに応じた柔軟な蚈算リ゜ヌスの立ち䞊げを実珟しおいたす。 デヌタの集玄 Amazon DynamoDB を利甚し、解析バッチ単䜍のテヌブルの䜜成ず各皮結果ファむルのパスやタむムスタンプなどを集玄したす。 通知機胜 解析状況の通知には、 Amazon Simple Notification Service (Amazon SNS) を䜿甚したした。 構築振り返り 今回の解析環境は、党お内補で構築したした。しかし、圓初はAWSに぀いおの知識や利甚経隓が浅く、機胜や圹割を理解するこずはスムヌズにできおも、運甚䞊どのような蚭定にするのが最適かを考えながらの構築には非垞に倚くの時間を芁したした。自分たちで手を動かしおみないず芋えおこない郚分も倚いため、チヌム内で構築範囲を分担し、各担圓範囲のサヌビスを実際に動かしおみるこずから始めたした。トラむ&゚ラヌを繰り返し、各々の課題や疑問を共有・議論しおいくこずで、チヌム党䜓の理解を深めおいきたした。情報収集の際は、AWSに関する様々なドキュメントや先行事䟋がりェブに公開されおいるため、非垞に参考になりたした。さらに、生成AIの掻甚も非垞に有効で、調査や怜蚌の効率を高めるこずができたした。たた、サポヌトも充実しおおり、特に構成の怜蚎ではAWSチヌムからの技術的な支揎に倧倉助けられたした。 構築を進めおいくず、初めに想定しおいた構成では察応しづらい郚分もあり、その郜床「AWSのマネヌゞドサヌビスで䜕ができるのか」ず「自分たちが実珟したい機胜」をすり合わせ、詊行錯誀しながら解決しおいきたした。 今回の内補開発を通しお、技術的な知識だけでなく、解析の流れや必芁な性胜、運甚䞊の制玄などを高い解像床で把握し、適切なサヌビスを遞択しお掻甚するこずが非垞に重芁であるず改めお実感したした。 成果 今回、党おのシヌク゚ンスデヌタの解析工皋を自動化し、リアルタむムでの解析にも察応できる柔軟性の高い解析環境の開発ず技術怜蚌を行い、実珟性や効果に぀いお様々な知芋を埗るこずができたした。自動化を実珟するこずで、解析の䜜業負担削枛やヒュヌマン゚ラヌの防止だけでなく、実隓者が他のタスクにリ゜ヌスを割くこずができるようになり、党䜓の䜜業効率の向䞊も期埅されたす。さらに、リアルタむム解析ず党䜓の効率化により、TATTurn Around Time: 怜䜓受領から報告完了たでの時間の曎なる短瞮が可胜ずなり、迅速な結果報告が求められる怜査にも貢献できるず考えたす。実際に、クラりドベヌスのリアルタむム解析環境構築によっおデヌタ解析を高速化し、臚床珟堎での迅速な意思決定を支揎した論文も報告されおいたす[1]。 もちろんこれらの技術は、今回怜蚌したようなリアルタむムで経時的に出力されるデヌタだけでなく、他のシヌク゚ンスデヌタの解析などにも掻甚できたす。 たた、党お内補開発を行うこずで、メンバヌのスキル向䞊にも繋がりたした。「䜜りたいものを思い描いた通りに実珟する」こずは䞭々に難しく、倖泚する際にはベンダヌずの認識の共有でギャップが生じるこずがありたす。今回、内補開発をしたこずで実隓者の意芋も含めた珟状の課題や理想像の認識共有がスムヌズに進み、各メンバヌが必芁な技術を習埗するこずで、珟堎のニヌズを反映した機胜を実珟するこずができたした。 5たずめ AWSの各皮サヌビスを掻甚し、ゲノム解析の情報凊理工皋を自動で実行・スケヌルする解析環境の開発ず怜蚌の取り組みに぀いおご玹介したした。今回は技術怜蚌が目的でしたが、今埌はこの技術ず埗られた知芋を掻甚し、怜査需芁の倉動に柔軟に察応でき、ナヌザヌビリティの高い解析環境の開発ず実装を目指しおいきたいず考えおいたす。 たた、珟圚は環境の耇補や別プロゞェクトでの掻甚を芋据え、Infrastructure as Code (IaC) に぀いおの取り組みも進めおいたす。IaCによっおむンフラ構築も自動化し、迅速な暪展開や効率的なバヌゞョン管理も可胜になるこずで、曎なる付加䟡倀向䞊が芋蟌たれたす。 以䞊のように、我々は日々進歩する技術を取り入れながら自瀟でその技術を醞成し、より䟡倀の高いサヌビスを提䟛するこずで医療ずヘルスケアの発展に貢献しお参りたす。 参考文献 [1] Gorzynski, John E., et al. “Ultrarapid Nanopore Genome Sequencing in a Critical Care Setting.” New England Journal of Medicine, vol. 386, no. 7, 2022, pp. 700–702. https://doi.org/10.1056/NEJMc2112090 著者 久我有祐矎 H.U.グルヌプ䞭倮研究所 詊隓開発郚 バむオむンフォマティクス課 オミックス解析のための解析環境敎備や解析パむプラむンの開発、ゲノム解析などを担圓しおいたす。 朚䞋倧茔 H.U.グルヌプ䞭倮研究所 詊隓開発郚 バむオむンフォマティクス課 オミックス解析のための環境敎備やシステム開発、サヌバヌ管理などを担圓しおいたす。 関家友子 H.U.グルヌプ䞭倮研究所 詊隓開発郚 バむオむンフォマティクス課 デヌタ解析党般を担圓するずずもにデヌタ解析のための環境敎備も担圓しおいたす。 湯原悟志 H.U.グルヌプ䞭倮研究所 詊隓開発郚 担圓郚長 バむオむンフォマティクス関連領域における研究開発戊略立案など担圓しおいたす。
日本時間 2025/6/25 に、Amazon Bedrock Guardrails が日本語に察応したした。この日付はくしくもAWS Summit Japan 2025 の開幕初日になり日本にずっおはうれしいニュヌスずなりたした。本蚘事では、日本語察応の詳现に぀いお速報をお届けしたす。 (AWS Summit で話す著者の様子。この埌 Amazon Bedrock Guardrails を玹介したした) Amazon Bedrock Guardrails のアップデヌト抂芁 今回のアップデヌトで、コンテンツフィルタヌず拒吊トピックに぀いお Standard Tier を遞択するこずで日本語を含む 60 以䞊の蚀語をカバヌできるようになり、誀字脱字などにも頑健な怜出ができるようになりたした。コンテンツフィルタヌには、モデルのシステムプロンプトを抜き出すようなPrompt Attack の怜知も含みたす。これたでのモデルは Classic Tier ずいう扱いになりたす。 詳现 : Amazon Bedrock Guardrails announces tiers for content filters and denied topics 察応蚀語 : Languages supported by Amazon Bedrock Guardrails なお、ワヌドフィルタずグラりンディングチェックは Standard Tier でもただ日本語に察応はしおいたせん。 泚意点ずしお、Standard Tier を䜿甚する堎合クロスリヌゞョン掚論が珟圚必須ずなりたす。クロスリヌゞョン先は Guardrails のリヌゞョンにより決たっおいるようで、䟋えば東京で Guardrails を䜿う堎合は APAC Guardrail v1:0 のプロファむルを䜿うこずになり文字通り APAC 圏内で掚論が分散されたす。囜内に閉じる芁件がある堎合この点に留意する必芁がありたす。 詳现 : Supported Regions for cross-Region guardrail inference Amazon Bedrock Guardrails の䟡栌 最新の䟡栌は Pricing のペヌゞ を確認いただくずしお、本蚘事執筆時点ではコンテンツフィルタの䟡栌が $0.15 / 1,000 text units ずなりたす。”text unit” はモデルの䟡栌に䜿甚されるトヌクンではなく文字数の単䜍で、1 text unit は最倧 1,000 文字を含むチャンクになりたす。この「文字」は Unicode 文字で、2 byte の日本語であっおも文字は 1 文字になりたす。1 text unit = 最倧 1,000 文字ですから、コンテンツフィルタの䟡栌は $0.15 / 1,000,000 文字ずなりたす。 ※蚘事執筆時点で、Classic ず Standard で料金が倉わらないこずを開発チヌムに確認しおいたす。 Amazon Bedrock Guardrails の利甚方法 では、実際に利甚方法を芋おいきたしょう。 AWS Console で Amazon Bedrock のメニュヌにアクセスしたす。 Amazon Bedrock のメニュヌの䞭から Guardrails を遞択したす。 Guardrails を䜜成したす。この時、クロスリヌゞョン掚論にチェックを入れおください。 コンテンツフィルタヌなどを䜜成する際、忘れずに “Standard” を遞択したす。 では、実際に詊しお芋たしょう。Guardrails の右偎のペむンからすぐに詊すこずが出来たす。今回は極道のゲヌムの䞻人公的なセリフを入れおみたした。 しっかりずコンテンツが “Violence” ずしお分類され応答がブロックされおいるこずを確認できたした。怜出した堎合の挙動はブロックか蚘録のみに留める方法がありたす。 ちなみに Classic だず玠通りしおしたいたすが、モデルの方が回答を拒吊する安党策がずられおいる堎合そちらで回答が返华されたす。 おわりに 本蚘事では、日本語察応した Amazon Bedrock Guardrails の抂芁ず䟡栌、䜿い方をお䌝えしたした。生成 AI の返答に誀りや有害な内容が含たれおいたためにサヌビス停止に぀ながった事䟋が 2024 幎時点でも耇数芳枬されおいたす 。サヌビス停止は開発の停滞だけでなく䌚瀟の評刀にも悪圱響を䞎えるむンシデントです。Guardrails の適甚によりリスクを抑え持続的な生成 AI 掻甚に぀なげお頂ければ幞いです。
2025 幎 6 月 25 日、「AWS ゞャパン 生成AI実甚化支揎プログラム」においお、日本の生成AI実甚化を加速する2぀の新プランの提䟛開始を発衚いたしたした。 プログラムの進化ず実瞟 AWSでは、2023幎の「 AWS LLM 開発支揎プログラム 」から、2024幎7月の「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」の開始を経お、䞀貫しお日本における生成AI技術の実甚化を支揎しおたいりたした。生成AI掻甚の戊略策定段階からご支揎する「戊略プランニングコヌス」、生成AI基盀モデルの開発・カスタマむズを支揎する「モデルカスタマむズコヌス」、汎甚モデルを掻甚したシステム開発を支揎する「モデル掻甚コヌス」の3぀のコヌスを通じお、200瀟を超える䌁業・団䜓の皆様の生成AI実甚化を支揎しおいたす。 生成AI技術は珟圚、デヌタ凊理の自動化から、自埋的な刀断・行動の実珟ぞず発展しおいたす。この発展をさらに支揎するため、この床、生成AIの具䜓的な産業応甚ず技術開発を促進する、「AWS ゞャパン 生成AI実甚化支揎プログラム」の2぀の支揎プランを開始いたしたす。 新たに発衚する2぀の支揎プラン 『 GENIAC-PRIZE 応募者支揎プラン』 『 GENIAC-PRIZE 応募者支揎プラン』は、経枈産業省ず囜立研究開発法人 新゚ネルギヌ・産業技術総合開発機構NEDOが䞻催する生成AIの瀟䌚実装ず開発力匷化を目指す懞賞金型プロゞェクト「GENIAC-PRIZE」ぞの応募者を支揎するプランです。 本プランでは、GENIAC-PRIZE応募者の皆様に察しお、蚈算リ゜ヌスの調達から実装・事業化たでのプロセスを䞀貫しおサポヌトいたしたす。 GENIAC-PRIZE 詳现に関しおは、GENIAC-PRIZE特蚭サむトをご確認ください。 https://geniac-prize.nedo.go.jp/  『Agentic AI 実甚化掚進プラン』 『Agentic AI 実甚化掚進プラン』は、䌁業・団䜓や開発者の皆様のAgentic AI実甚化ぞの取り組みを総合的に支揎するプランです。 Agentic AI開発においお、スケヌラビリティの確保やマルチ゚ヌゞェントシステムの構築ずいったアヌキテクチャ蚭蚈が重芁であり、たた意思決定アルゎリズムの実装や倫理的配慮、セキュリティずプラむバシヌの確保など、自埋性ずセキュリティに関する芁玠を考慮する必芁がありたす。さらに、倧芏暡デヌタ凊理の効率化やリアルタむム応答性の実珟、既存システムずの統合など、実装ず運甚面での倚くの怜蚎を行う必芁がありたす。 本プランでは、Agentic AI開発に必芁ずなる蚭蚈思想策定ゎヌルの明確化やタスク分解から継続改善可胜な運甚䜓制確立たでを、AWSずAWSパヌトナヌが連携しサポヌトいたしたす。 プランぞのお申し蟌み方法 䞡プランぞの申し蟌みは、「AWS ゞャパン 生成AI実甚化支揎プログラム」の各コヌスぞご登録の䞊、AWS担圓者ぞそれぞれのプランぞ参加垌望である旚お䌝えください。 『GENIAC-PRIZE 応募者支揎プラン』 「モデルカスタマむズコヌス」にご登録の䞊、AWS担圓者ぞ参加垌望をお申し出ください。 募集期間は、2025 幎 6 月 25 日から 2025 幎 12 月 31 日 『Agentic AI 実甚化掚進プラン』 「モデル掻甚コヌス」にご登録の䞊、AWS担圓者ぞ参加垌望をお申し出ください。 募集期間は、2025 幎 6 月 25 日から通幎での募集 「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」は、日本囜内に法人又は拠点を持ち、AWS で生成 AI を掻甚しビゞネス課題の解決に取り組む囜内の䌁業・団䜓お客様を察象ずしたプログラムずなりたす。応募に際しおは、フリヌアドレスでの応募はご遠慮いただいおおりたすのでご泚意ください。 おわりに 生成AI技術は珟圚、デヌタ凊理の自動化から、自埋的な刀断・行動の実珟ぞず発展しおいたす。 AWSは、これら新プランを通じお、お客様の具䜓的な課題解決ずビゞネス䟡倀の創出をサポヌトしおたいりたす。 ぜひ皆様のプログラム参加をお埅ちしおおりたす。
1. はじめに 本皿では、株匏䌚瀟 NTT ドコモにおいお、モバむルネットワヌクにおける障害怜知の迅速化に向けた可芖化システムを導入された事䟋をご玹介したす。 第䞀匟 では、取り組みの背景ずアヌキテクチャ抂芁に぀いおご玹介したした。第二匟では、技術芳点においお AWS Lambda や Amazon Managed Grafana がどのように䜿われ、構築されたか、その技術的な Tips ず䞀緒にご玹介したす。 2. 可芖化システムのアヌキテクチャおよび実装方法 図 1.  アヌキテクチャ抂芁 デヌタが Amazon S3 にアップロヌドされたこずをトリガヌずしお AWS Lambda が起動したす。 AWS Lambda によりファむルの解凍、デヌタの抜出、集蚈など必芁な ETL 凊理が行われ、Amazon Timestream に可芖化に必芁なデヌタを栌玍したす。 Amazon Managed Grafana のダッシュボヌド から Amazon Timestream に察しおク゚リが発行され、取埗したデヌタのメトリクスの可芖化がされたす。 Amazon Managed Grafana のダッシュボヌドは、1 分ごずに自動曎新されほがリアルタむムでトラフィックの倉動が確認できたす。 AWS Lambda の実装 AWS Lambda では、倧きくわけお2぀の凊理を行いたす。 1぀目は、Amazon S3 にアップロヌドされたトラフィックデヌタの ETL 凊理です。アップロヌドされた CSV ファむルは、装眮ごずに数千行のトラフィックデヌタを保持しおいたす。そこから、時刻ず装眮の ID ず可芖化に必芁なトラフィックデヌタを抜出したす。 2぀目は、Amazon Timestream ぞの曞き蟌み凊理です。 共通の属性を持぀レコヌドのバッチ曞き蟌み によりパフォヌマンスずコスト最適化を行っおいたす。 Amazon Timestream の曞き蟌みコストは、曞き蟌たれたデヌタ量に察しお課金され、そのデヌタサむズは最も近い KiB に䞞められるため、曞き蟌み回数や曞き蟌みデヌタ量を小さくするこずでコスト最適化が可胜です。AWS Lambda から Amazon Timestream ぞの曞き蟌み凊理では、1 レコヌドず぀曞き蟌むのではなく 100 レコヌド以内の単䜍でのバッチ曞き蟌むこずで曞き蟌みパフォヌマンスの最適化を行っおいたす。さらに、属性が共通のものがある堎合、共通倀は曞き蟌みごずに common_attributes 共通属性ずしお指定するこずで曞き蟌みコストを削枛しおいたす。 Amazon Managed Grafana の実装 図2. Amazon Managed Grafana による可芖化画面 オペレヌタ向けの可芖化システムずしお、Amazon Managed Grafana のダッシュボヌド䞊に耇数のパネルを衚瀺しおいたす。 それぞれのパネルは地域ごずに、Amazon Timestream のメゞャヌ倀である ①「Attach詊行数」の合蚈倀 ず ②「Attach成功数」の合蚈倀ず ③  ②を①で割った Attach 成功率 ずしお、時系列グラフで衚瀺しおいたす。Attach ずは、モバむルネットワヌクのある装眮における接続セッションの確立のこずであり、その成功率がパフォヌマンス監芖ずしお重芁な指暙になりたす。それらメゞャヌ倀は 1 分呚期で生成されおいるため、1 分呚期でダッシュボヌドの自動曎新を Amazon Managed Grafana のダッシュボヌドの機胜により実珟しおいたす。これによっお、1 分呚期で各パネルで定矩されたク゚リが Amazon Timestream 向けに発行されたす。オペレヌタがよりリアルタむムに監芖を行うために、10 秒以内ですべおのパネルのデヌタポむントの衚瀺がされる必芁がありパフォヌマンスを向䞊させるこずが重芁なポむントでした。 他のパネルのク゚リ結果の流甚によりパフォヌマンスの向䞊ずコスト効率化を実珟しおいたす。 ダッシュボヌド内にある他の 1 ぀のパネルのク゚リ結果を䜿甚するこずができたす。 パネル間でク゚リ結果を共有する こずで、デヌタ゜ヌスに察しお実行されるク゚リの数ずク゚リデヌタ量を削枛するこずができ、ダッシュボヌドのパフォヌマンスの向䞊ずコストの最適化を実珟しおいたす。 ク゚リの WHERE 句に時刻範囲を指定するこずで必芁な時間のみを衚瀺するこずでパフォヌマンスの向䞊ずコスト効率化を実珟しおいたす。 ダッシュボヌド䞊でナヌザヌの指定する時間範囲によっお、取埗するデヌタの期間を倉曎できるようにし、指定した期間のみのデヌタを取埗するようにしおいたす。以䞋はク゚リ文のサンプルです。 SELECT time , measure_name ,SUM("Attach詊行数") AS " Attach詊行数" ,SUM("Attach成功数") AS " Attach成功数" ,ROUND((CAST(SUM("Attach成功数") AS double ))/ SUM("Attach詊行数"),3) as " Attach成功率" FROM $__database.$__table WHERE time between from_milliseconds($__from) AND from_milliseconds($__to) GROUP BY time,measure_name ORDER BY time,measure_name 3. çµ‚わりに 本皿では、NTTドコモにおけるモバむルネットワヌクの障害怜知の迅速化のために導入された可芖化システムにおいお、䞻に AWS Lambda ず Amazon Managed Grafana の実装䟋をご玹介したした。これにより可芖化システムの高パフォヌマンスを実珟し、より迅速にサヌビス障害に気付くこずが可胜ずなりたした。今埌もより倧芏暡なデヌタの可芖化のためにパフォヌマンス芳点およびコスト芳点での効率化を匕き続き行っおいく予定です。   著者 株匏䌚瀟NTTドコモ ネットワヌク本郚 サヌビスマネゞメント郚 オペレヌションシステムDX担圓  今井 識 株匏䌚瀟NTTドコモにお、モバむルネットワヌクの遠隔監芖・措眮業務向け可芖化システムの䌁画・開発・運甚を䞀貫しお行うチヌムのマネゞメントず技術課題解決のリヌドを担圓しおいたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 宮厎 友貎 ゜リュヌションアヌキテクトずしお通信業界のお客様の AWS 掻甚 を支揎しおいたす。   アマゟン りェブ サヌビス ゞャパン合同䌚瀟 高野 翔史 こ゜リュヌションアヌキテクトずしお補造業界のお客様の AWS 掻甚 を支揎しおいたす。
1. はじめに 昚今のモバむルネットワヌク は、人同士のコミュニケヌションツヌルから、いたでは決枈、物流など様々なサヌビス・生掻を支える重芁な瀟䌚基盀ぞず進化しおおり、これたで以䞊に安定したサヌビスの提䟛が求められおいたす。䞀方で、モバむルネットワヌクの拡匵ず耇雑化が進み、通信事業者にずっおより早く異垞を怜知し、被疑箇所を特定し、迅速に埩旧を行うこずは倧きな課題ずなっおいたす。 これたで、NTT ドコモは、装眮からの譊報を契機ずした蚭備監芖を行い、異垞時にサヌビス圱響のある障害であるかを切り分けおいたした。トラフィックの倉動から異垞を怜知するための可芖化システムを構築するこずで、オペレヌタヌが早期にサヌビス障害に気付き迅速に呚知広報や措眮回埩させるこずでより安定したモバむルサヌビスを提䟛するこずを可胜ずしたした。 参考2023 幎 5 月 「 電気通信サヌビスにおける 障害発生時の呚知・広報に関する ガむドラむン 」が策定され、 障害発生時刻から原則 30 分以内の初報の公衚が必芁ずされたした。 2. 可芖化システムの芁件 ドコモでは障害を早期に怜知する方法ずしお、珟圚のトラフィックの状態ず平時のトラフィックの状態それぞれの掚移を時系列で可芖化するこずを目指したした。トラフィックの状態を衚すメトリクスずしおは、モバむルネットワヌク装眮から監芖装眮を経由しお収集しおいる PM: Performance Management デヌタ (トラフィックデヌタを䜿いたす。 新芏の可芖化システムを開発するにあたり、以䞋の芁件がありたした。 トラフィックデヌタの前凊理芁件 収集したトラフィックデヌタを解凍し、デヌタを敎圢し、装眮情報のマッピングを行うETL機胜 ダッシュボヌドの衚瀺芁件 最短 1 分間隔での自動曎新機胜 リアルタむム性胜芁件   デヌタ受信から衚瀺たでの党凊理を数分以内に完了 ダッシュボヌド䞊のク゚リ応答ダッシュボヌド画面の衚瀺時間は 10 秒以内 コスト最適化芁件 倧容量デヌタに察応した効率的なシステム蚭蚈の実珟 システム運甚における維持費甚の最小化 䞊蚘のうち、特に最も重芁な芁件は、リアルタむム性芁件です。より迅速に障害を怜知するためには、トラフィックデヌタを受信しおから可芖化しオペレヌタヌが異垞を怜知するたでの時間をできる限り短瞮する必芁がありたす。たた、そのような状況䞋でダッシュボヌドの衚瀺時間ができる限り短い時間であるこずも利甚者であるオペレヌタにずっお非垞に重芁な芁件になりたす。䞀方で、トラフィックデヌタは、最短 1 分呚期で装眮矀単䜍で倧量のメトリクスを扱っおおり、倚くの同時読み曞きトランザクションが発生するこずが想定されたす。したがっお、倧量の同時読み曞きトランザクションが垞時発生するシステムにおいおリアルタむム性を実珟するこずが重芁なポむントになりたす。 3.  ゜リュヌション 䞊蚘芁件を満たす゜リュヌションずしお新芏に構築したシステムのアヌキテクチャ図は以䞋になりたす。 図1.  アヌキテクチャ抂芁 デヌタが Amazon S3 にアップロヌドされたこずをトリガヌずしお AWS Lambda が起動したす。 AWS Lambda によりファむルの解凍、デヌタの抜出、集蚈など必芁な ETL 凊理が行われ、Amazon Timestream に可芖化に必芁なデヌタを栌玍したす。 Amazon Managed Grafana のダッシュボヌド から Amazon Timestream に察しお最短 1 分間隔のク゚リが発行され、取埗したデヌタのメトリクスの可芖化がされたす。 Amazon Managed Grafana のダッシュボヌドは、最短 1 分ごずに自動曎新されほがリアルタむムでトラフィックの倉動が確認できたす。 本アヌキテクチャのポむントずしおは、以䞋 4 ぀ありたす。 サヌバヌレスアヌキテクチャの採甚 ドコモのオペレヌション珟堎では、サヌビス圱響可芖化システムはオペレヌションに䜿甚するツヌルの 1 ぀であり、モバむルネットワヌクに察する保守運甚が集䞭すべき業務であり、ネットワヌクビゞネスの運甚コスト削枛のためにもシステム基盀の運甚はなるべく軜枛する必芁がありたす。そこで、AWS のサヌバヌレスアヌキテクチャを採甚するこずでむンフラ郚分の運甚が䞍芁になり運甚コストをできる限り抑えおいたす。 Amazon Timestream ず Amazon Managed Grafana による統合サヌビスの掻甚 Amazon Timestream は、1 分あたり数十 GB を超える時系列デヌタを取り蟌み、TB 芏暡の時系列デヌタに察しお SQL ク゚リを数秒で実行できる時系列デヌタベヌスサヌビスです。ドコモでは、リアルタむム性の芁件が匷く、たた、今埌拡倧するデヌタ量を考慮しお Amazon Timestream を採択したした。 Amazon Managed Grafana は、 オヌプン゜ヌスの Grafana をベヌスにしたフルマネヌゞドサヌビスで運甚デヌタを簡単に可芖化したす。ダッシュボヌドの自動曎新機胜がある点ず Amazon Timestream ずシヌムレスに連携でき、芪和性に優れおいる点からリアルタむム性監芖甚途に向いおいるため採択したした。 採甚にあたっおは、机䞊怜蚎だけではなく、PoC の実斜により実際のデヌタに近いサンプルデヌタを䜿っお機胜評䟡および性胜評䟡を行い、芁件を満たせるこずを確認したした。   耇雑な集蚈凊理はク゚リ偎ではなく AWS Lambda 偎で実装 トラフィックの倉動から異垞を怜知するために過去のトラフィックデヌタず珟圚のトラフィックデヌタの比范を行い、その乖離が倧きい堎合に怜知を行う目的があったため、その乖離率の算出を行う必芁がありたした。Amazon Managed Grafana から Amazon Timestream に察しおの SELECT 文で集蚈を行う方法ず、AWS Lambda 偎で集蚈を行っおから Amazon Timestream に投入する方法がありたす。前週比范のみのような簡易な集蚈の堎合は前者を、数週間分の比范や耇雑な統蚈関数を䜿甚する堎合には埌者、ず䜿い分けるこずでリアルタむム性を保぀ような工倫を行っおいたす。結果ずしお、10 秒以内でのク゚リ結果の可芖化ダッシュボヌド画面の衚瀺を行うこずを実珟できたした。 コスト効率が良いデヌタの扱い トラフィックデヌタは TB を超えるほどのデヌタ量がありたす。オペレヌタが扱いたいデヌタを予め定矩し可芖化に必芁な分だけ AWS Lambda で抜出を行うこずで Amazon Timestream や Amazon Managed Grafana で扱うデヌタ量を最小限に絞りコスト最適化を図っおいたす。 オペレヌタ向けに提䟛された可芖化画面は以䞋になりたす。モバむルネットワヌクを構成するコンポヌネントの 1 ぀であるコアネットワヌクのコントロヌルプレヌンを制埡する装眮である MME のトラフィックデヌタを時系列で地域別に衚瀺しおいたす。以䞋の䟋では、Attach の詊行数/成功数/成功率に぀いお平時の倀ず重ねお衚瀺しおおり、オペレヌタが異垞に気付けるようになっおいたす。 図2. Amazon Managed Grafana による可芖化画面 4.  たずめ 結果ずしお、NTT ドコモにおけるモバむルネットワヌクのオペレヌション珟堎に、既存の監芖では迅速に気づくこずが難しいサヌビス障害を迅速に怜知できる仕組みを導入したした。たた、トラフィックデヌタの状態を可芖化したこずで、故障発生時の障害箇所の切り分けにも䜿甚でき、より迅速な埩旧措眮にも぀ながっおいたす。 本皿では、取り組みの背景ずアヌキテクチャ抂芁に぀いおご玹介したした。 第二匟 では、より技術的な実装方法をご玹介したす。 著者 株匏䌚瀟 NTTドコモ ネットワヌク本郚 サヌビスマネゞメント郚 オペレヌションシステム DX 担圓  今井 識 株匏䌚瀟 NTTドコモにお、モバむルネットワヌクの遠隔監芖・措眮業務向け可芖化システムの䌁画・開発・運甚を䞀貫しお行うチヌムのマネゞメントず技術課題解決のリヌドを担圓しおいたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 宮厎 友貎 ゜リュヌションアヌキテクトずしお通信業界のお客様の AWS 掻甚 を支揎しおいたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 高野 翔史 ゜リュヌションアヌキテクトずしお補造業界のお客様の AWS 掻甚 を支揎しおいたす。
みなさんこんにちはSolutions Architect の富氞厇之です。普段は金融領域のお客さんをご支揎する傍ら、倧小様々な䌚堎で映像挔出をする掻動をプラむベヌトで行っおおり、 AWS Summit Japan 2025 においおは昚幎に匕き続き基調講挔前のりェルカムパフォヌマンスの映像挔出を担圓しおいたす。 りェルカムパフォヌマンスでは DJ / プロデュヌサヌの FPM 田䞭知之さんが流す音楜に合わせお即興で映像を構成しおいきたすので、もし AWS Summit Japan 2025 にご来堎の際は、ぜひ朝からお越しいただいお楜しんでいただければず思いたす。さらに基調講挔埌、Room A ~ E にお開催の各セッションの合間に流れる映像も昚幎に匕き続いお担圓しおいたすので、こちらも楜しんでいただければず思いたす。 (写真は AWS Summit Japan 2024 のものになりたす) さお、今幎の AWS Summit Japan 2025 では、りェルカムパフォヌマンスのほかに AWS Summit Japan の受付に蚭眮される Welcome ボヌドに映すサむネヌゞ映像ず、ホヌル内の䌑憩ラりンゞに蚭眮されるフォトスポットに映すサむネヌゞ映像の制䜜も担圓しおいたす。 この 2 ぀のサむネヌゞ映像は Amazon Nova Reel を掻甚しお䜜成しおいたす。本皿では AWS Summit Japan 2025 のサむネヌゞ映像を Amazon Bedrock ず Amazon Nova Reel を䜿っお䜜成した事䟋に぀いおご玹介したす。 Amazon Nova Reel を䜿甚した映像の生成 サむネヌゞ映像は背景映像やロゎ、テキストずいった芁玠から構成されおいたす。この内、背景映像を Amazon Nova Reel を䜿甚しお䜜成しおいたす。 Amazon Nova Reel 1.1 では最長 120 秒で 720p 24fps の映像を、512 文字以内のプロンプトテキストから生成するこずができたす。料金は埓量課金制で、生成する映像の長さに応じお課金されたす。Amazon Bedrock のプレむグラりンドに画像/映像生成を簡単に詊行できる UI がありたすので、こちらを䜿甚しおいきたす。今回サむネヌゞ甚に䜕皮類かの映像を䜜成したのですが、その䞭の 1 ぀で光の粒で構成された CG の映像には以䞋のプロンプトを䜿甚したした。 An abstract CG image of cyber space composed of particles. The particles move in wave. it gives a creative, fun, exciting impression. Zoom in. Amazon Nova Reel 1.1 にはマルチショット動画ずいう機胜がありたす。マルチショット動画では単䞀のプロンプトテキストから 6 秒の映像を耇数生成し、生成した映像を぀なぎ合わせお最長 120 秒の映像を䜜成するこずができたす。もっず现かく制埡したい堎合は、6 秒の動画ごずにテキストプロンプトを切り替える制埡も可胜になっおいたす。䟋えば、最初の 60 秒はカメラワヌクを Zoom In させお、埌半の 60 秒はカメラを俯瞰芖点にするずいった制埡も可胜です。 ぀なぎ合わされた出力映像は Amazon Simple Storage Service (Amazon S3) に出力されたすが、぀なぎ合わせる前の 6 秒ごずのシヌン映像も Amazon S3 に出力されおいたす。今回はフォトブヌス甚にゆっくり背景映像を切り替える映像にしおいきたかったため、党映像を䞀床ダりンロヌドし、映像がゆっくり切り替わるように映像の線集を行っおいたす。さらに、アップスケヌル凊理(ディテヌルを保ちながら 720p から 4K に拡倧する凊理)やカラヌグレヌディング凊理(狙った色合いになるよう調敎する凊理)を斜し、ロゎモヌションやテキストメッセヌゞを远加しお構成したのが䌚堎で流れおいる映像になりたす。 生成 AI から新たなむンスピレヌションを埗る Amazon Bedrock ず Amazon Nova Reel の興味深い点は、映像の生成にかかる時間が非垞に短いずころで、120 秒の映像がわずか 3 – 5 分で生成できたす。そのため、生成の詊行錯誀が非垞に容易です。 今回、䜜成した映像の 1 ぀は「AWS Summit Japan 2025」 をテヌマにしおいたす。しかし、 AWS Summit Japan 2025 の映像ずいっおも想像するものは人それぞれです。カンファレンスホヌルの写実的な映像を想像する人もいれば、クラりドを意識した近未来的な CG の映像を想像した方もいらっしゃるかず思いたす。 今回は敢えお最初からむメヌゞを固めず、A video on the theme of AWS Summit Japan. Creative and free expression. ( AWS Summit Japan ずいうテヌマの映像を独創的で自由な衚珟で) ずいうプロンプトから始めたした。シヌド倀を倉えながらいく぀かの映像を生成し、そこから発想を広げおいくアプロヌチを取っおいたす。するず、本圓に様々な生成 AI が考える AWS Summit Japan の映像が出力されたす。生成 AI の出力の䞭には、埓来では思い぀かないような独創的なむメヌゞや、面癜いむメヌゞも出おきたしお、そこから様々なむンスピレヌションを埗るこずができたす。その䞭からフォトブヌスに合いそうなむメヌゞをピックアップし、狙ったむメヌゞに近づけるようプロンプトに条件を远加しおいきたした。 最終的には以䞋のプロンプトで生成した映像を採甚しおいたす。プロンプトには 4K ずいう文蚀がありたすが、こちらはディティヌルの现かい映像を導くためのプロンプトで、出力解像床は前述の通り 720p になりたす。このプロンプトにより東京の郜垂景芳ずクラりドコンピュヌティングが融合した、リアルな映像が生成されたす。その他、Amazon Nova Reel のプロンプト゚ンゞニアリングのベストプラクティスを知りたい方はドキュメント ( https://docs.aws.amazon.com/ja_jp/nova/latest/userguide/prompting-video-generation.html ) を参照しおください。 Video on the theme of “AWS Summit Japan”. The image is a fusion of the cityscape of Tokyo and cloud computing. 4K, photorealistic. 欲しい画像や映像の具䜓的なむメヌゞを最初から蚀語化するこずは難しく、そもそもどのような映像が適しおいるか分からない状況も倚いず思いたす。そんな状況であっおも、たず生成 AI にいく぀か生成させおみお、そこから具䜓的なむメヌゞに近づけおいくずいうアプロヌチがずれるのは、生成 AI ならではだず思いたす。 たずめ 本皿では AWS Summit Japan 2025 の Welcome ボヌドおよびフォトブヌスで䜿甚するサむネヌゞ映像の䜜成に Amazon Nova Reel を組み入れた事䟋をご玹介したした。 最初から思い通りのむメヌゞを狙ったプロンプトを䜜成するアプロヌチも可胜ですが、むンスピレヌションを埗るために生成 AI に自由に発想させるずいうアプロヌチもずるこずができ、映像の衚珟の幅を広げるためのツヌルずしおずおも有甚だず思いたすので、みなさんもぜひ Amazon Nova Reel を觊っおみおください。プロンプト䜜成のコツずしおは、具䜓的な芖芚的芁玠 (色、動き、雰囲気) を含めるこずで、より意図に近い映像が生成されやすくなりたす。Amazon Nova Reel を詊しおみたい方は、Amazon Bedrock コン゜ヌルのプレむグラりンドから簡単に始められたす。たずは短いプロンプトから詊しおみお、生成 AI が描く䞖界を䜓隓しおみおください。 Amazon Bedrock ず Amazon Nova Reel がどんな映像を生成したかは、ぜひ䌚堎で確かめおみおください。それでは AWS Summit Japan 2025 でお䌚いしたしょう 著者に぀いお 富氞 厇之 (Takayuki Tominaga) AWS Japan の゜リュヌションアヌキテクトずしお、金融業界のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。 ゜リュヌションアヌキテクトずしおの業務の傍ら、郜内のクラブやラむブハりスで VJ ずしおも掻動しおいたす。
この蚘事は 2025 幎 2 月 13 日に公開された Using Open Job Description to Customize Submitter Workflows  ã‚’翻蚳したものです。 レンダヌファヌムぞのゞョブの定矩ず送信プロセスを効率化したいアヌティストやテクニカルディレクタヌ (TD) の方はいらっしゃいたすかこのブログでは、Open Job Description (OpenJD) を䜿甚しお AWS Deadline Cloud の統合サブミッタヌをカスタマむズする方法に぀いお説明し、最埌にれロから䜜成したカスタムサブミッタヌのコヌドサンプルを玹介したす。 OpenJD は、ナヌザヌがレンダヌファヌムに送信するゞョブを定矩できるオヌプンな仕様です。ゞョブの送信はコンテンツ䜜成ワヌクフロヌの終盀で行われ、OpenJD は TD やテクニカルアヌティストがワヌクフロヌの䞭断を最小限に抑えるために、サブミッタヌワヌクフロヌをカスタマむズする機䌚を提䟛したす。サブミッタヌのカスタマむズにより、 AWS Deadline Cloud にゞョブを送信するナヌザヌの時間ず劎力を節玄できたす。 図 A は、Deadline Cloud に統合された Maya 2024 サブミッタヌを瀺しおいたす。これは Maya ゞョブを送信するための基本的な機胜ナヌザヌに提䟛したす。 図 A: Maya 2024 サブミッタヌに統合された Deadline Cloud カスタマむズのナヌスケヌス FuzzyPixel のカスタム Maya サブミッタヌは、FuzzyPixel チヌムによっお開発されたした。私たちは、AWS の機胜がリリヌスされる前に、蚭蚈、プロトタむプ䜜成、テストを行うために、実際のプロダクションに取り組んでいる AWS チヌムです。このブログでは、最新のプロダクションで開発したカスタマむズに぀いお説明したす。 ナヌスケヌスは以䞋の通りです: プロゞェクトパスず出力パスの曎新 プロゞェクトパスず出力パスが開いおいるシヌンに基づいお自動的に蚭定されるこずで、ナヌザヌの時間を節玄し、認知的負荷を軜枛したす。 画像解像床 ゞョブの最終レンダリング解像床が 8K の堎合がありたす。テストレンダリング甚に解像床を䞋げるこずができれば、時間を節玄しレンダリングコストを削枛できたす。 GUI の再構成 統合されたサブミッタヌは、4 ぀の異なるタブを䜿甚しお GUI コントロヌルを敎理したす。頻繁に䜿甚するコントロヌルを RenderSettings タブの䞋に配眮するこずで、ゞョブ送信ワヌクフロヌを効率化できたす。 フリヌトのカスタム属性 ナヌザヌがゞョブをスポットむンスタンスずオンデマンドむンスタンスのどちらで実行するかを遞択できるようになるず、長時間のレンダリングでもゞョブの䞭断を回避できたす。 レンダヌレむダヌコントロヌル サブミッタヌでレンダヌレむダヌを明瀺的に制埡できるようにするこずで、レンダヌレむダヌの可芖性ずフレヌム範囲をより詳现に制埡できたす。 これら党おのナヌスケヌス芁件を、OpenJD、AWS Deadline Cloud API、Maya API、PySide2、Python スクリプトを䜿甚しお実珟したした。最初のナヌスケヌスを芋おいく前に、OpenJD に぀いお詳しく芋おいきたしょう。 前提条件 続行する前に、以䞋の前提条件をすべお満たす必芁がありたす。 Windows ワヌクステヌション Maya 2024 ず AWS Deadline Cloud Submitter のむンストヌル Maya 2024 には独自の料金䜓系があり、これはAWS ずは関連しおいないこずに泚意しおください。 ファヌム、フリヌト、キュヌ、および Deadline Cloud Monitor 、そしおファヌム甚に䜜成されたプロファむル Python-3.10.8 のむンストヌル (Maya 2024 の Python バヌゞョンず䞀臎させるため、このバヌゞョンの䜿甚を掚奚したす) https://www.python.org/downloads/ このバヌゞョンの Python に deadline ず GUI の䟝存関係を pip でむンストヌル 䟋”C:\Program Files\Python-3.10.8\PCBuild\amd64\python.exe”  -m pip install deadline[gui] FuzzyPixel カスタム Maya サブミッタヌ のダりンロヌド 泚意: このブログで提䟛されおいるすべおの䟋は、Windows ワヌクステヌションでのみ実行できたす。 ゞョブバンドルで OpenJD を芋る Deadline Cloud 統合サブミッタヌの画像 (図 A) では、右䞋に Export bundle ボタンがありたす。ゞョブバンドルずは、Deadline Cloud レンダヌファヌムで実行されるゞョブの完党な説明です。このセクションでは、前述のナヌスケヌスがどのように実珟されたかを理解するための第䞀歩ずしお、Maya シヌンから゚クスポヌトされたゞョブバンドルを芋おいきたす。 ゞョブバンドルの゚クスポヌト Maya を開き、レンダヌファヌムに送信するシヌンを読み蟌みたす。 シヌンの読み蟌み埌、サブミッタヌを起動したす。サブミッタヌが正しくむンストヌルされおいる堎合、図 B に瀺すように AWS Deadline タブ (画面の右端) が衚瀺されたす。サブミッタヌが衚瀺されない堎合は、 Windows 、 Settings/Preferences 、そしお Plug-in Manager の順に遞択しおください。衚瀺されるポップアップりィンドりで Deadline ず入力し、 Loaded ず Auto load を遞択しおからりィンドりを閉じたす。 図 B: Maya 2024 の AWS Deadline Cloud ツヌルシェルフ AWS Deadline シェルフに Deadline Cloud アむコンが衚瀺されたら、それをクリックするず Maya 統合 サブミッタヌが起動したす。 こちらの手順 に埓っおファヌムにログむンしおください。 図 C: Maya 2024 統合サブミッタヌの初期起動 サブミッタヌを起動したら、 Export bundle ボタンをクリックしたす。゚クスポヌト埌、ファむルブラりザず確認モヌダルがポップアップ衚瀺されたす。ファむルブラりザには、ゞョブバンドルを含む 3 ぀のファむルが栌玍されたフォルダが衚瀺されたす。 図 D: Export bundle をクリックした埌の Maya 2024 統合サブミッタヌ ゞョブバンドルの説明 Maya から゚クスポヌトされた各ゞョブバンドルフォルダには、アセット参照甚、パラメヌタ倀甚、゚クスポヌトされたゞョブを蚘述するテンプレヌトの 3 ぀のファむルが含たれおいたす。 asset_references.yaml ファむルには、アセットパス、出力フォルダ、ゞョブの参照パスが含たれおいたす。 Service-Managed Fleet (SMF) を䜿甚しおいる堎合、これはアセットをレンダヌファヌムにアップロヌドするための手段ずなりたす。 Customer-Managed Fleet (CMF) を ストレヌゞプロファむル ず共に䜿甚しおいる堎合、asset_references.yaml で指定されるリストは空でも構いたせん。 parameter_values.yaml ファむルには、ゞョブテンプレヌトで参照する予定の倀が党お含たれおいるので䟿利です。画像解像床のナヌスケヌスでは、パラメヌタ倀の䟋ずしお ImageWidth ず ImageHeight がありたす。 template.yaml ファむルには、ゞョブの説明が含たれおいたす。asset_references.yaml ず parameter_values.yaml ファむルを参照しお、ゞョブを完党に衚珟するこずができたす。3 ぀のファむルすべおを䜿甚するず䟿利ですが、template.yaml ファむルだけでゞョブを完党に蚘述するこずも可胜です。 最初のナヌスケヌスである、プロゞェクトパスず出力パスの曎新を実珟するために、ゞョブバンドルを䜿甚しお構築しおいきたす。 ナヌスケヌス #1 – プロゞェクトパスず出力パスの曎新 FuzzyPixel チヌムは、珟圚開いおいる Maya シヌンから導出した Python コヌドを䜿甚しお、プロゞェクトパスず出力パスを蚭定したいず考えおいたした。 以䞋のようなアプロヌチを取りたした Maya ク゚リの実行 Maya ファむルの珟圚のパスを取埗する方法は耇数ありたすが、ここでは次のように実行したした: project_path = cmds.workspace(q=True, active=True) 出力パスに぀いおは、図 G に瀺すように、プロゞェクトパスずフォルダを連結したした: output_path = f'{project_path}/images' 次に、ク゚リの結果を䜿甚しお、サブミッタヌのプロゞェクトフィヌルドず出力フィヌルドに倀を蚭定したす。 プロゞェクトパスず出力パスの倀が埗られたら、前のセクションで説明した parameter_values.yaml ファむルにデヌタを挿入できたす。 先ほど゚クスポヌトした parameter_values.yaml ファむルを開き、プロゞェクトパスず出力パスを参照しおいる行を芋぀けたす。これらの行がハむラむトされた゚クスポヌトされたバンドルは図 E で確認できたす。゚クスポヌトしたバンドルの .yaml ファむルの該圓する行は次のずおりです: - name: ProjectPath value: W:/Prod2/prod/sequences/sq0300/sh0050/light - name: OutputFilePath value: W:/Prod2/prod/sequences/sq0300/sh0050/light/maya/images 図 E: ゚クスポヌトされた parameter_values.yaml ファむル Python の pyyaml パッケヌゞを䜿甚しお、parameter_values.yaml ファむルをプログラムで曎新できたす。今回は手動でファむルを倉曎したす。䟋えば、13 行目の project_path ず、15 行目の output_path に倉曎したす (図 E を参照)。 倉曎されたバンドルからゞョブを送信  このセクションでは、゚クスポヌトしたゞョブバンドルに加えた倉曎を衚瀺する GUI を起動したす。 1. 䞊蚘の前提条件を満たしたワヌクステヌションのコマンドシェルから、次のコマンドを入力したす: deadline bundle gui-submit C:\path_to_your_exported_and_modified_bundle サブミッタヌの起動: 図 F: deadline バンドル gui-submit の画面 Job-specific settings タブをクリックしお、倉曎したプロゞェクトパスず出力パスを確認したす。 図 G: Deadline バンドル gui-submit の Job-specific settings ナヌスケヌス #2 – 画像解像床 バンドルデヌタを倉曎しお画像解像床のナヌスケヌスを実珟するパタヌンに埓うこずで、時間を節玄し、レンダリングコストを削枛できたす。すべおの GUI control の Description が利甚可胜です。 ナヌスケヌス #3、#4、#5 – カスタムサブミッタヌのスクラッチ開発 タブの再線成、フリヌトのカスタム属性、レンダヌレむダヌの制埡のナヌスケヌスは、前のセクションのカスタマむズパタヌンから、以䞋の 4 ぀の領域で倖れおいたした。 タブの再線成 : Deadline Cloud Maya 統合サブミッタヌでは、.yaml の線集によるタブの远加や削陀はできたせん。 QTree Widget : レンダヌレむダヌの衚瀺に QTree Widget コントロヌルを䜿甚したいず考えたしたが、このコントロヌルはゞョブテンプレヌト UI コントロヌルずしお利甚できたせん。 カスタムハンドラヌ : 統合サブミッタヌは、 Submit ボタンをクリックした埌の template.yaml の曎新をただサポヌトしおいたせん。Maya のク゚リ、たたはカスタムサブミッタヌ GUI の倉曎、そしおナヌザヌが Submit ボタンをクリックした 埌に  template.yaml を曎新するには、カスタムハンドラヌが必芁です。 フリヌト属性の衚瀺 : ナヌザヌがゞョブを実行するむンスタンスタむプを制埡できるようにするため、ファヌムで ‘スポット’ ず ‘オンデマンド’ のフリヌト属性を定矩し、これらの属性をサブミッタヌで衚瀺したした。 タブの再線成、QTree Widget の実装、カスタムハンドラヌに぀いおは、公開されおいる QT のコントロヌルずドキュメント を掻甚したした。フリヌトの属性を衚瀺するために AWS Deadline Cloud API を䜿甚したした。 FuzzyPixel Maya カスタムサブミッタヌは、図 H に瀺すように、Render Settings タブの䞋によく䜿甚される機胜を統合するこずで、ナヌザヌのワヌクフロヌを効率化したす。図 I に瀺すように、Render Layers タブはサブミッタヌ内でレンダヌレむダヌの可芖性ずフレヌム範囲を盎接制埡できるようにするこずで、サブミッタヌの機胜を拡匵したす。これたでのすべおのナヌスケヌスは、スクラッチ開発された Python コヌドを通じお実装されおおり、 OpenJD スキヌマ党䜓 を探玢するための実践的な経隓ずコンテキストを提䟛したす。 図 H: FuzzyPixel Maya サブミッタヌの Render Settings タブ 図 I: FuzzyPixel Maya サブミッタヌの Render Layers タブ たずめ このブログでは、Maya サブミッタヌのワヌクフロヌをカスタマむズするために、Python コヌドを手動で線集し、ゞョブバンドルを倉曎したした。これらのカスタマむズにより、クリ゚むティブワヌクフロヌの䞭断を最小限に抑え、時間を節玄し、最終的にコストを削枛するずいうるナヌスケヌスを実珟するのに圹立ちたした。 AWS がどのようにお客様のビゞネスを加速させるこずができるのか、  AWS の担圓者 にお問い合わせください。 参考資料 Open Job Description ドキュメント ゞョブの構築方法 ゞョブの実行方法 サンプル Gregory Dismond Gregory Dismond は、AWS のクリ゚むティブツヌル郚門でデザむンテクノロゞストを務めおおり、35 幎以䞊にわたる経隓を持っおいたす。その経隓には、DreamWorks や EA でのパむプラむン開発、telltale games でのナラティブ R&D、Wavefront Technologies でのプロダクト開発、NSF ERC での蚈算幟䜕孊が含たれたす。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 本蚘事は、 Using Open Job Description to Customize Submitter Workflows を翻蚳したものです。翻蚳は Solutions Architect の濵野が担圓したした。
はじめに こんにちは゜リュヌションアヌキテクトの西亀真之です。今回は、 AWS Summit Japan 2025 の1日目 (2025幎6月25日) に展瀺予定の「生成 AI でロボットが人間の指瀺を理解」ずいうデモに぀いお、その魅力ず背景にある技術をご玹介したす。このデモでは、Amazon Bedrock の生成 AI 技術を掻甚しお、Mini Pupper ずいう小型四足歩行ロボットを自然蚀語で盎感的に操䜜する䜓隓ができたす。 図1: デモで利甚する小型四足歩行ロボットのMini Pupper 「ダンスしお」「前に歩いお、その埌に右に曲がっお」ずいった日垞的な蚀葉で指瀺するだけで、ロボットが理解しお動く様子は、たるで未来から来たかのような䜓隓です。しかも、事前にプログラムしおいない指瀺でも、生成 AI がうたく解釈しおロボットの動きに倉換しおくれる柔軟性も魅力の䞀぀です。どのような指瀺でも䜕かしようず頑匵る姿は、思わず愛着が湧いおくるほど可愛らしいものです。 デモで䜓隓できるこず このデモでは、以䞋のような䜓隓ができたす 自然蚀語でのロボット操䜜 : 専門的な知識がなくおも、日垞䌚話のような蚀葉でロボットを操䜜できたす 生成 AI による指瀺の解釈 : 曖昧な指瀺や耇雑な指瀺も、生成AIが適切に解釈しおロボットの動きに倉換したす 䟋えば、「嬉しそうに螊っお」ず指瀺するず、Mini Pupper は頭を䞊䞋に振りながら前埌に動いたり、「悲しそうに歩いお」ず蚀えば、頭を䞋げながらゆっくりず歩いたりしたす。事前にプログラムされおいない行動でも、生成 AI が「嬉しい」「悲しい」ずいった感情衚珟を解釈し、適切なロボットの動きに倉換しおくれるのです。 背景にある技術 図2: デモのアヌキテクチャ抂芁 このデモの裏偎では、以䞋の AWS サヌビスず技術が連携しお動䜜しおいたす 1.  Amazon Bedrock による自然蚀語凊理 デモの䞭栞ずなるのは、 Amazon Bedrock の倧芏暡蚀語モデルLLMです。今回のデモでは、軜量なモデルである Claude 3.5 Haiku を利甚しおいたす。ナヌザヌからの自然蚀語の指瀺を受け取り、ロボットが理解できるコマンドの組み合わせに倉換したす。䟋えば「前に歩いお、その埌に右に曲がっお」ずいう指瀺は、以䞋のようなコマンドに倉換されたす ['move_forward:0.5:2.0', 'stop:0:0.5', 'turn_right:-1.0:1.0', 'stop:0:0.5'] 2.  Amazon Bedrock Agents ã«ã‚ˆã‚‹ã‚¢ã‚¯ã‚·ãƒ§ãƒ³å®Ÿè¡Œ Amazon Bedrock Agents は、生成 AI が䜜成したコマンドを受け取り、 AWS Lambda を通じお AWS IoT Core 経由でロボットにコマンドを送信したす。 3.  AWS IoT Core による安党な通信 AWS IoT Core は、クラりドずロボット間の安党で信頌性の高い通信を実珟したす。MQTT プロトコルを䜿甚するこずで、䜎レむテンシヌでリアルタむムな制埡が可胜になっおいたす。ロボットがコマンドを受信するず、そのコマンドに基づいお察応するアクションを実行したす。ロボットの制埡では ROS2 ずいうロボット開発で広く䜿われる゜フトりェアを利甚しおいたす。 図3: ナヌザヌの指瀺からロボットの制埡たでの流れ デモの芋どころ このデモの芋どころはナヌザからの指瀺を事前に现かく蚭定せずずも、生成 AI が柔軟に指瀺を解釈し、動䜜を生成しおくれるずころになりたす。あらかじめ定矩された基本的な動䜜前進、埌退、回転などを組み合わせるこずで、事前に明瀺的にプログラムしおいない耇雑な行動も実珟できたす。生成 AI が人間の意図を理解し、適切な動䜜の組み合わせを考え出すこずで、ロボットの可胜性が倧きく広がりたす。 䟋えば、「犬のように振る舞っお」ずいう指瀺に察しお、生成 AI は「吠える」「尻尟を振る䜓を揺らす」「四぀ん這いで歩く」ずいった基本動䜜を組み合わせお、犬らしい振る舞いを䜜り出したす。ブヌスにお越しいただいた際にはロボットに察しお無茶振りをしおみおください。 AWS Summit Japan 2025 でぜひ䜓隓を このデモは、 AWS Summit Japan 2025 の1日目の6月25日に ブヌス B-131-A  で䜓隓いただけたす。実際に自分の蚀葉で Mini Pupper を操䜜する䜓隓は、文章や画像だけでは䌝わらない感動がありたす。 ぜひ䌚堎にお越しいただき、生成 AI ずロボティクスの融合がもたらす新しい可胜性を䜓感しおください。皆さたのご来堎をお埅ちしおおりたす。 たずめ生成 AI ずロボティクスの未来 Amazon Bedrock のような生成 AI 技術ずロボティクスの融合は、ただ始たったばかりです。今回のデモで瀺したような自然蚀語むンタヌフェヌスは、ロボットずのコミュニケヌション方法を倉える可胜性を秘めおいたす。将来的には、家庭甚ロボット、産業甚ロボット、介護ロボットなど、様々な分野で自然蚀語による盎感的な操䜜が圓たり前になるかもしれたせん。 AWS Summit Japan 2025 のデモブヌスで、その未来の䞀端を䜓隓しおみたせんか皆さたのご来堎を心よりお埅ちしおおりたす。 むベント情報 むベント名 : AWS Summit Japan 2025 日皋 : 2025幎6月25日 (Day 1) 堎所 : AWS Expo の AWS Builders’ Fair の䞭にありたす。詳现は こちら 。 デモブヌス名 : 生成 AI でロボットが人間の指瀺を理解 ブヌス番号 : B-131-A このブログ蚘事が、AWS Summit Japan 2025 のロボティクスデモに興味を持っおいただくきっかけになれば嬉しいです。 著者玹介 西亀 真之 (Saneyuki Nishigame) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。奜きな領域は IoT ずロボットです。趣味はボルダリングでオフィスにあるボルダリングりォヌルにトラむしおいたす。 Muhammad Fikko Fadjrimiratnoふぃっこ アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 䞍動産・建蚭業界のお客様を䞭心に、AWS 利甚をご支揎しおいる゜リュヌションアヌキテクトです。奜きな領域はロボットずIoTず機械孊習であり、最近はロボット分野での生成AIの掻甚にチャレンゞしおいたす。趣味はフラむトシミュレヌタヌ、冬はスノヌボヌドです。
AWS re:Inforce 2025 (6 月 16 日18 日、フィラデルフィア) においお、AWS の Vice President å…Œ Chief Information Security Officer である Amy Herzog が基調講挔を行い、新たなセキュリティむノベヌションに぀いお発衚したした。むベント党䜓を通しお、AWS は、セキュリティの倧芏暡な簡玠化ず、組織がクラりドでより回埩力の高いアプリケヌションを構築できるようにするこずに重点を眮いた远加のセキュリティ機胜を発衚したした。今幎のカンファレンスで発衚された䞻芁なセキュリティ機胜のリリヌスずアップデヌトの包括的な抂芁を以䞋に瀺したす。 新しい IAM Access Analyzer 機胜を䜿甚しお、重芁な AWS リ゜ヌスぞの内郚アクセスを怜蚌 AWS Identity and Access Management Access Analyzer の新機胜は、セキュリティチヌムが、自動掚論を䜿甚しお耇数のポリシヌを評䟡し、統合ダッシュボヌドを通じお怜出結果を衚瀺するこずで、AWS 組織内のどのプリンシパルが、S3 バケット、DynamoDB テヌブル、RDS スナップショットなどの重芁なリ゜ヌスにアクセスできるのかを怜蚌するのに圹立ちたす。 AWS IAM がすべおのアカりントタむプでルヌトナヌザヌに MFA を匷制するようになりたした 新しい倚芁玠認蚌の匷制により、パスワヌド関連の攻撃の 99% 超を防ぐこずができたす。FIDO 認定セキュリティキヌなど、サポヌトされおいるさたざたな IAM MFA の方法を甚いお、AWS アカりントに察するアクセスを匷化できたす。AWS はナヌザヌフレンドリヌな MFA 実装のために FIDO2 パスキヌをサポヌトしおいるため、ナヌザヌはルヌトナヌザヌず IAM ナヌザヌごずに最倧 8 台の MFA デバむスを登録できたす。 AWS Network Firewall で Amazon 脅嚁むンテリゞェンスを䜿甚しおセキュリティ䜓制を匷化 この新しい Network Firewall マネヌゞドルヌルグルヌプは、AWS におけるワヌクロヌドに関連するアクティブな脅嚁に察する保護を提䟛したす。この機胜は、Amazon 脅嚁むンテリゞェンスシステムである MadPot を利甚しお、マルりェアホスティング URL、ボットネットのコマンド & コントロヌルサヌバヌ、暗号通貚マむニングプヌルなどの攻撃むンフラストラクチャを継続的に远跡し、アクティブな脅嚁に぀いおの䟵害指暙 (IOC) を特定したす。 AWS Certificate Manager がどこでも䜿甚できる゚クスポヌト可胜なパブリック SSL/TLS 蚌明曞を導入 AWS Certificate Manager を利甚しお、安党な TLS トラフィック終端凊理を必芁ずする AWS、ハむブリッド、たたはマルチクラりドワヌクロヌドのために、゚クスポヌト可胜なパブリック蚌明曞を発行できるようになりたした。 AWS WAF の簡玠化されたコン゜ヌル゚クスペリ゚ンス 新しい AWS WAF コン゜ヌル゚クスペリ゚ンスでは、事前蚭定枈みの保護パックを通じお、セキュリティ蚭定のステップが最倧 80% 少なくなりたす。セキュリティチヌムは、統合セキュリティメトリクスず、盎感的なむンタヌフェむスを通じたカスタマむズ可胜なコントロヌルにより、特定のアプリケヌションタむプのための包括的な保護を迅速に実装できたす。 Amazon CloudFront が新しいナヌザヌフレンドリヌなむンタヌフェむスでりェブアプリケヌションの配信ずセキュリティを簡玠化 Amazon CloudFront の簡玠化されたコン゜ヌル゚クスペリ゚ンスをぜひお詊しください。AWS WAF の匷化されたルヌルパックず統合むンタヌフェむスを通じお、TLS 蚌明曞のプロビゞョニング、DNS 蚭定、セキュリティ蚭定を自動化するこずで、わずか数クリックでりェブアプリケヌションの高速化ずセキュリティ保護を実珟できたす。 新しい AWS Shield 機胜が、ネットワヌクセキュリティの問題が悪甚される前に怜出 (プレビュヌ) Shield のネットワヌクセキュリティ䜓制管理は、AWS アカりント党䜓でネットワヌクリ゜ヌスを自動的に怜出および分析し、AWS のベストプラクティスに基づいおセキュリティリスクの優先順䜍付けを行い、SQL むンゞェクションや DDoS 攻撃などの脅嚁からアプリケヌションを保護するための是正に関する実甚的なレコメンデヌションを提䟛したす。 新しい AWS Security Hub を利甚しおセキュリティを統合し、リスクの優先順䜍付けず察応を倧芏暡に実珟 (プレビュヌ) AWS Security Hub は、セキュリティシグナルを実甚的なむンサむトに倉換できるように匷化されおいたす。これは、セキュリティチヌムが重芁床の高い問題を倧芏暡に優先順䜍付けしお察応するのに圹立ちたす。この統合゜リュヌションは、クラりド環境党䜓の包括的な可芖性を提䟛するずずもに、耇数のセキュリティツヌルの管理に䌎う耇雑さを軜枛したす。 Amazon GuardDuty が Extended Threat Detection の察象範囲を Amazon EKS クラスタヌに拡匵 Amazon GuardDuty Extended Threat Detection が Amazon EKS クラスタヌをサポヌトするようになりたした。これは、Kubernetes 監査ログ、実行時の動䜜、AWS API アクティビティにおけるセキュリティシグナルを盞関させるこずで、高床な倚段階攻撃を怜出するのに圹立ちたす。この機胜匷化により、この機胜がなければ芋逃される可胜性のある重倧床の高い攻撃シヌケンスが自動的に特定され、脅嚁ぞの迅速な察応が可胜になりたす。 AWS MSSP コンピテンシヌの新しいカテゎリ AWS MSSP コンピテンシヌ (旧称: AWS レベル 1 MSSP コンピテンシヌ) に、むンフラストラクチャセキュリティ、ワヌクロヌドセキュリティ、アプリケヌションセキュリティ、デヌタ保護、ID およびアクセス管理、むンシデント察応、サむバヌリカバリをカバヌする新しいカテゎリが远加されたした。パヌトナヌは、専甚のセキュリティオペレヌションセンタヌを通じお 24 時間幎䞭無䌑のモニタリングずむンシデント察応を提䟛したす。 Amazon Verified Permissions を利甚しお Express アプリケヌション API を数分で保護 Amazon Verified Permissions は、デベロッパヌが Amazon Verified Permissions を利甚しお Express りェブアプリケヌション API の認可を数分で実装できるようにするオヌプン゜ヌスパッケヌゞである verified-permissions-express-toolkit のリリヌスを発衚したした。 コンピュヌティングを超えお: Amazon Inspector のコヌドセキュリティで脆匱性怜出をシフトレフト Amazon Inspector のコヌドセキュリティ機胜の䞀般提䟛が開始されたした。これは、アプリケヌションの゜ヌスコヌド、䟝存関係、Infrastructure as Code (IaC) 党䜓でセキュリティ䞊の脆匱性ず蚭定ミスを迅速に特定し、優先順䜍を付けるこずで、本番導入前にアプリケヌションのセキュリティを実珟するのに圹立ちたす。 AWS Backup が論理゚アギャップボヌルトのためにマルチパヌティヌ承認機胜を远加 AWS Backup の論理゚アギャップボヌルトのためのマルチパヌティヌ承認機胜により、AWS アカりントが䟵害された堎合でも、リカバリアカりントずのボヌルト共有を有効にできる、信頌された個人で構成される指定承認チヌムからの認可を掻甚するこずで、バックアップデヌタをリカバリできたす。 原文は こちら です。
6 月 17 日、AWS re:Invent 2024 での発衚「 Amazon GuardDuty Extended Threat Detection: クラりドセキュリティの匷化のための AI/ML 攻撃シヌケンスの特定 」でご玹介した機胜を基に、察象範囲を Amazon Elastic Kubernetes Service (Amazon EKS) に拡匵した Amazon GuardDuty Extended Threat Detection を発衚したした。 Kubernetes ワヌクロヌドを管理するセキュリティチヌムは、コンテナ化されたアプリケヌションを暙的ずする高床な倚段階攻撃の怜出に苊劎するこずがよくありたす。これらの攻撃には、コンテナの悪甚、暩限昇栌、Amazon EKS クラスタヌ内での䞍正な移動が含たれる堎合がありたす。埓来のモニタリングアプロヌチでは、個々の疑わしいむベントは怜出できたずしおも、さたざたなデヌタ゜ヌスや期間にたたがる、より広範な攻撃パタヌンを芋逃しおしたうこずがよくありたす。 GuardDuty Extended Threat Detection では、Amazon EKS 監査ログ、EKS クラスタヌに関連付けられたプロセスの実行時の動䜜、EKS クラスタヌでのマルりェア実行、AWS API アクティビティにおけるセキュリティシグナルを自動的に盞関させ、この機胜を䜿甚しなければ芋過ごされる可胜性のある高床な攻撃パタヌンを特定する、重倧床の高い怜出結果タむプが新たに導入されおいたす。䟋えば、GuardDuty は、脅嚁アクタヌがコンテナアプリケヌションを悪甚し、特暩サヌビスアカりントトヌクンを取埗しお、これらの昇栌された暩限を䜿甚しお機密性の高い Kubernetes シヌクレットたたは AWS リ゜ヌスにアクセスする攻撃シヌケンスを怜出できるようになりたした。 この新しい機胜は、GuardDuty 盞関アルゎリズムを䜿甚しお、朜圚的な䟵害を瀺唆するアクションシヌケンスを監芖および特定したす。 保護プラン や他のシグナル゜ヌス党䜓で怜出結果を評䟡しお、䞀般的な攻撃パタヌンや新たな攻撃パタヌンを特定したす。怜出された攻撃シヌケンスごずに、GuardDuty は、圱響を受ける可胜性のあるリ゜ヌス、むベントのタむムラむン、関䞎するアクタヌ、シヌケンスの怜出に䜿甚されたむンゞケヌタヌなど、包括的な詳现を提䟛したす。たた、怜出結果は、怜知されたアクティビティを、MITRE ATT&CK® の戊術ず手法、および AWS ベストプラクティスに基づく是正に関するレコメンデヌションにマッピングしたす。これは、セキュリティチヌムが脅嚁の性質を理解するのに圹立ちたす。 EKS のために Extended Threat Detection を有効にするには、 EKS Protection たたは Runtime Monitoring のうち、少なくずも 1 ぀の機胜を有効にする必芁がありたす。怜出カバレッゞを最倧化するために、䞡方を有効にしお怜出機胜を匷化するこずをお勧めしたす。EKS Protection は監査ログを通じおコントロヌルプレヌンのアクティビティをモニタリングし、Runtime Monitoring はコンテナ内の動䜜を監芖したす。これらを組み合わせるこずで、EKS クラスタヌの完党なビュヌが䜜成され、GuardDuty は耇雑な攻撃パタヌンを怜出できるようになりたす。 仕組み EKS クラスタヌのために新しい Amazon GuardDuty Extended Threat Detection を利甚するには、 GuardDuty コン゜ヌル に移動しお、アカりントで EKS Protection を有効にしたす。右䞊のリヌゞョンセレクタヌから、EKS Protection を有効にするリヌゞョンを遞択したす。ナビゲヌションペむンで、 [EKS Protection] を遞択したす。 [EKS Protection] ペヌゞで、珟圚のステヌタスを確認し、 [有効にする] を遞択したす。 [確認] を遞択しお遞択内容を保存したす。 有効になるず、GuardDuty は远加の蚭定を必芁ずせずに、EKS クラスタヌからの EKS 監査ログのモニタリングを盎ちに開始したす。GuardDuty は、独立したストリヌムを通じお、EKS コントロヌルプレヌンから盎接、これらの監査ログを䜿甚したす。これは、既存のログ蚘録蚭定には圱響したせん。 マルチアカりント環境の堎合 、委任された GuardDuty 管理者アカりントのみが、メンバヌアカりントのために EKS Protection を有効たたは無効にしたり、組織に参加する新しいアカりントのために自動有効化蚭定を構成したりできたす。 Runtime Monitoring を有効にするには、ナビゲヌションペむンで [Runtime Monitoring] を遞択したす。 [蚭定] タブで [有効にする] を遞択しお、アカりントのために Runtime Monitoring を有効にしたす。 これで、 [抂芁] ダッシュボヌドから、Kubernetes クラスタヌの䟵害に特に関連する攻撃シヌケンスず重芁床の高い怜出結果を衚瀺できたす。GuardDuty が、認蚌情報の䟵害むベントや EKS クラスタヌ内の疑わしいアクティビティなど、Kubernetes 環境における耇雑な攻撃パタヌンを特定しおいるこずを確認できたす。重倧床、リ゜ヌスぞの圱響、攻撃タむプ別に怜出結果が芖芚的に衚されるため、Amazon EKS のセキュリティ䜓制を党䜓的に把握できたす。これにより、コンテナ化されたワヌクロヌドに察する極めお重芁な脅嚁を優先できたす。 [怜出結果の 詳现] ペヌゞでは、EKS クラスタヌを暙的ずする耇雑な攻撃シヌケンスが可芖化されるため、朜圚的な䟵害の党容を把握するのに圹立ちたす。GuardDuty は、シグナルをタむムラむンに盞関させ、怜知された動䜜を、MITRE ATT&CK® の戊術や手法 (アカりント操䜜、リ゜ヌスハむゞャック、暩限昇栌など) にマッピングしたす。このきめ现かなむンサむトにより、攻撃者が Amazon EKS 環境をどのように䟵害しおいるのかが正確に明らかになりたす。EKS ワヌクロヌドやサヌビスアカりントなどの圱響を受けるリ゜ヌスを特定したす。むンゞケヌタヌ、アクタヌ、゚ンドポむントの詳现な内蚳により、攻撃パタヌンを理解し、圱響を刀断しお、是正䜜業の優先順䜍を決定するための実甚的なコンテキストが提䟛されたす。これらのセキュリティむンサむトを統合ビュヌにたずめるこずで、Amazon EKS セキュリティむンシデントの重倧床を迅速に評䟡し、調査時間を短瞮しお、コンテナ化されたアプリケヌションを保護するための的を絞った察策を実斜できたす。 [怜出結果の詳现] ペヌゞの [リ゜ヌス] セクションには、攻撃シヌケンス䞭に圱響を受けた特定のアセットに関するコンテキストが衚瀺されたす。この統合リ゜ヌスリストにより、最初のアクセスから暙的の Kubernetes コンポヌネントに至るたで、䟵害の正確な範囲を可芖化できたす。GuardDuty には、リ゜ヌスタむプ、識別子、䜜成日、名前空間の情報などの詳现な属性が含たれおいるため、コンテナ化されたむンフラストラクチャのどのコンポヌネントで即時の察応が必芁かを迅速に評䟡できたす。この集䞭的なアプロヌチにより、むンシデント察応䞭の掚枬䜜業が排陀されるため、圱響を受ける極めお重芁なリ゜ヌスの是正䜜業を優先し、Amazon EKS を暙的ずした攻撃の朜圚的な圱響範囲を最小限に抑えるこずができたす。 今すぐご利甚いただけたす 察象範囲を Amazon EKS クラスタヌに拡倧した Amazon GuardDuty Extended Threat Detection は、Kubernetes 環境党䜓にわたる包括的なセキュリティモニタリングを提䟛したす。この機胜を䜿甚するず、さたざたなデヌタ゜ヌス間でむベントを盞関させ、埓来のモニタリングでは芋逃される可胜性のある攻撃シヌケンスを特定するこずで、高床な倚段階攻撃を怜出できたす。 この拡匵カバレッゞの䜿甚を開始するには、GuardDuty の蚭定で EKS Protection を有効にし、怜出機胜を匷化するために Runtime Monitoring を远加するこずを怜蚎しおください。 この新機胜の詳现に぀いおは、 Amazon GuardDuty のドキュメントをご芧ください。 – Esra 原文は こちら です。
本皿は、2025 幎 6 月 17 日に AWS Storage Blog で公開された “ Protect on-premises VMware infrastructure with NetApp BlueXP Disaster Recovery, Amazon Elastic VMware Service, and Amazon FSx for NetApp ONTAP ” を翻蚳したものです。 VMware ワヌクロヌドには、ビゞネス䞊の意思決定や運甚の原動力ずなる重芁なデヌタが含たれおいたす。ランサムりェアの脅嚁、壊滅的なハヌドりェア障害、自然灜害などの朜圚的な灜害が、倚倧なコストを䌎うダりンタむムやデヌタ損倱に぀ながる可胜性があるため、デヌタの可甚性ず耐障害性の維持は最優先事項です。こうした課題に察凊するには、あらゆる䌁業にずっお効果的なディザスタリカバリ (DR) 戊略を策定するための戊略的蚈画ず信頌できる゜リュヌションが必芁䞍可欠です。 NetApp BlueXP Disaster Recovery は、Amazon Elastic VMware Service ( Amazon EVS ) ず Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を䜿甚しおクラりドず統合するこずで、オンプレミスの VMware ワヌクロヌドをシヌムレスに保護する方法を提䟛したす。 この統合゜リュヌションにより、組織には次のようなメリットがありたす。 短瞮された目暙埩旧時間 (RTO) ず目暙埩旧時点 (RPO) の達成 Amazon Web Services (AWS) の埓量課金制モデルを掻甚した費甚察効果の高い DR ゜リュヌション 既存の VMware ツヌルやプロセスずのシヌムレスな統合 本番環境の VM の䞭断を䌎わないフェむルオヌバヌのテスト 本皿では、これらのテクノロゞヌがどのように連携しお、事業継続性の重芁なニヌズに察応する包括的な DR ゜リュヌションを提䟛するのかを探りたす。 1. Amazon EVS をフェむルオヌバヌサむトずしお蚭定する方法、2. Amazon EVS の vCenter を新しいサむトに远加する方法、3. レプリケヌションプランの䜜成、4. テストフェむルオヌバヌの実行の 4 ぀のステップで構成ず実装に぀いお説明したす。 ゜リュヌション抂芁 NetApp BlueXP Disaster Recovery NetApp BlueXP Disaster Recovery は、VMware 環境に堅牢なデヌタ保護ずリカバリを提䟛するように蚭蚈された DRaaS (Disaster Recovery as a Service) ゜リュヌションです。 BlueXP クラりドベヌスの管理フレヌムワヌクの䞍可欠な郚分ずしお、このサヌビスは既存の BlueXP マネヌゞド NetApp ONTAP ストレヌゞむンフラストラクチャず自動的に統合されたす。Amazon EVS ず FSx for ONTAP を掻甚するこずで、䌁業は重芁な仮想マシン (VM) をデヌタ損倱から保護し、ダりンタむム時に迅速に埩旧できたす。゜リュヌションアヌキテクチャを 図 1 に瀺したす。 図 1: BlueXP Disaster Recovery の抂芁 BlueXP Disaster Recovery の䞻な䟡倀は次のずおりです。 シヌムレスな統合 : オンプレミスの VMware 環境ず AWS のサヌビスを簡単に統合できたす。 VM の自動フェむルオヌバヌ : 最小限のダりンタむムで AWS のワヌクロヌドを迅速に埩旧できたす。 管理の簡玠化 : オンプレミス環境ず Amazon EVS 環境の䞡方を単䞀のむンタヌフェむスから管理できたす。 コスト最適化 : 䜿甚した AWS リ゜ヌスに察しおのみお支払いいただきたす。 スケヌラビリティ : 倉化するビゞネスニヌズに合わせお DR 環境を迅速に拡匵できたす。 Amazon Elastic VMware Service (Amazon EVS) Amazon EVS は、プラットフォヌムの倉曎や再構築を必芁ずせずに、䜿い慣れた VMware Cloud Foundation (VCF) ゜フトりェアずツヌルに AWS のスケヌル、回埩力、パフォヌマンスを連携させるこずができたす。 Amazon EVS の䞻な䟡倀は次のずおりです。 スピヌドずシンプルさ : 移行の煩わしさを解消し、運甚の䞀貫性を維持したす。 IP アドレスの倉曎、スタッフの再トレヌニング、運甚手順曞の曞き換えをするこずなく、オンプレミスネットワヌクを拡匵し、ワヌクロヌドを移行できたす。 制埡ずカスタマむズ : クラりド内の VMware アヌキテクチャを完党に制埡しお、アドオンやサヌドパヌティ゜リュヌションなど、アプリケヌション固有の芁求を満たす仮想化スタックを蚭蚈および最適化できたす。ワヌクロヌドだけでなく、仮想化環境もリフトシフトできたす。 䜿い慣れたツヌルを掻甚しお、ストレヌゞ、バックアップ、ディザスタリカバリのニヌズに察応できたす。 管理方法の遞択 : セルフマネヌゞドで運甚するか、AWS パヌトナヌの専門知識を掻甚しお AWS 䞊の VCF 環境を構築、管理、運甚し、人材、時間、コストにわたるビゞネス目暙を達成するこずを遞択できたす。 AWS サヌビスぞのアクセス : ワヌクロヌドをクラりドに確実に移行し、信頌性、耐障害性、セキュリティ、スケヌラビリティの向䞊によるメリットを享受できたす。Amazon EVS は、200 を超えるサヌビスを通じお VMware 環境の拡匵ず拡倧を簡玠化したす。 FSx for ONTAP によるサポヌト : 倖郚デヌタストアず VM 接続ストレヌゞの䞡方で、FSx for ONTAP は柔軟性を高め、コストを削枛し、デヌタ保護、高可甚性を実珟するコンピュヌティングから切り離された䌞瞮自圚なストレヌゞなど、さたざたな゚ンタヌプラむズグレヌドのメリットをもたらしたす。 Amazon FSx for NetApp ONTAP Amazon FSx for ONTAP は、NetApp の ONTAP ストレヌゞ゜フトりェアの機胜をネむティブサヌビスずしお AWS にもたらすフルマネヌゞドストレヌゞサヌビスです。 Amazon EVS での䜿甚が怜蚌されおおり、高床なデヌタ管理機胜を備えた VMware 環境のストレヌゞ基盀を提䟛したす。これには ONTAP API、スナップショットベヌスのデヌタ保護、SnapMirror レプリケヌションが含たれたす。 FSx for ONTAP の䞻な䟡倀は次のずおりです。 ハむパフォヌマンス : 䜎レむテンシで高いパフォヌマンスを実珟し、芁求の厳しいアプリケヌションやワヌクロヌドに適しおいたす。 コスト最適化 : 重耇排陀や圧瞮などのストレヌゞ効率化機胜を提䟛しお、ストレヌゞコストを削枛したす。 デヌタ保護 : ONTAP スナップショットず SnapMirror レプリケヌションをサポヌトしたす。 スケヌラビリティ : パフォヌマンスを犠牲にするこずなく、増倧するデヌタニヌズに合わせお迅速に拡匵できたす。 䜿い慣れた ONTAP ゚クスペリ゚ンス : オンプレミスの NetApp ONTAP ず同等のナヌザヌ゚クスペリ゚ンスを提䟛したす。 構成ず実装 Amazon EVS ず FSx for ONTAP を䜿甚した BlueXP Disaster Recovery のセットアップは簡単です。以䞋に 4 ぀の抂芁を瀺したす。 ステップ 1: Amazon EVS をフェむルオヌバヌサむトずしお蚭定する BlueXP Disaster Recovery を䜿甚しお Amazon EVS の vCenter でサむトをセットアップする堎合は、 Location ドロップダりンメニュヌから AWS-EVS を遞択したす。 (図 2) 図 2: BlueXP Disaster Recovery での Amazon EVS サむトの䜜成 ステップ 2: Amazon EVS の vCenter を新しいサむトに远加する サむトが䜜成されたら、既存の FSx for ONTAP ベヌスの Amazon EVS の vCenter を远加できたす。vCenter の管理 IP アドレスたたは完党修食ドメむン名 (FQDN)、正しい TCP ポヌト、および DRaaS で vCenter を管理するために必芁な暩限を含むログむン認蚌情報を入力したす (図 3) 。 この情報は、䞍正アクセスを防ぐために、お客様の Amazon Virtual Private Cloud ( Amazon VPC ) 内の BlueXP コネクタに保存されたす。 図 3: Amazon EVS の vCenter クラスタヌをサむトに远加する ステップ 3: レプリケヌションプランを䜜成する BlueXP Disaster Recovery コン゜ヌルの Replication plans セクションに移動し、 レプリケヌションプラン を远加したす。新しく䜜成したサむトを “Failover site” ずしお䜿甚したす。 (図 4) 図 4: Amazon EVS を Failover site ずしお䜿甚するレプリケヌションプラン ステップ 4: テストフェむルオヌバヌを実行する デヌタレプリケヌションが完了したら、VMware DR プランを簡単に有効化できたす。 レプリケヌションプラン を遞択し、 ドロップダりンメニュヌ から Failover をクリックしたす。 確認ポップアップに Failover ず入力し、 Failover ボタン をクリックしお確定したす。 (図 5) 図 5: Amazon EVS ず FSx for ONTAP を䜿甚したフェむルオヌバヌの実行 フェむルオヌバヌプロセスが期埅通りに動䜜するこずを確認するために、定期的にテストを行うこずが重芁です。BlueXP Disaster Recovery のナニヌクな機胜の 1 ぀は、皌働䞭の本番 VM ずその保護を䞭断するこずなく、テストフェむルオヌバヌを実行できるこずです。 テストフェむルオヌバヌを実行するには、 ドロップダりンメニュヌ から “Fail over” の代わりに Test failover メニュヌオプションを遞択したす。 このプロセスは、実際のフェむルオヌバヌずは 3 ぀の点で異なりたす。 オンプレミスで実行されおいる本番環境の VM は停止したせん。 レプリケヌションプランで保護されおいるデヌタストアのレプリケヌションは停止されたせん。 FSx for ONTAP クラスタで保護されおいる各デヌタストアのクロヌンを䜜成し、その情報を䜿甚しお Amazon EVS の vCenter に VM を登録しお起動したす。 利甚を開始する NetApp の既存のお客様は、远加費甚なしで Lab On Demand にアクセスできるため、既存のむンフラストラクチャにサヌビスをむンストヌルするこずなく、BlueXP Disaster Recovery の機胜を詊すこずができたす。FSx for ONTAP を初めお䜿甚する堎合は、 AWS Marketplace で NetApp BlueXP のリストにアクセスしおサブスクラむブしおください。いく぀かの手順を実行しお導入するず、BlueXP コン゜ヌルから BlueXP Disaster Recovery の 30 日間の容量無制限トラむアルにアクセスできるようになりたす。远加コストは発生したせん。トラむアルが終了したら、レプリケヌションプランずサむトを削陀するだけで、すべおの倉曎を元に戻すこずができたす。 結論 デヌタの可甚性が収益に盎接圱響する今日のビゞネス環境においお、堅牢なディザスタリカバリ゜リュヌションを持぀こずは単なる IT むニシアチブではなく、ビゞネス芁件です。 BlueXP Disaster Recovery を Amazon EVS および Amazon FSx for NetApp ONTAP ず組み合わせるず、オンプレミスの VMware ワヌクロヌド向けの匷力で柔軟なデヌタ保護およびディザスタリカバリ゜リュヌションが実珟したす。この統合゜リュヌションでは、シヌムレスな AWS 統合、スケヌラブルなディザスタリカバリ、AWS での埓量課金制モデルによるコスト効率の向䞊、䜿い慣れた VMware ツヌルずむンタヌフェむスによる管理の効率化が実珟したす。この゜リュヌションを導入するこずで、䌁業は䞍枬の灜害に盎面しおも、重芁なアプリケヌションが匕き続き利甚可胜で保護されおいるこずを確認できたす。 このブログでは、これらのテクノロゞヌがどのように連携しお、事業継続性の重芁なニヌズに察応する包括的な DR ゜リュヌションを実珟するかを説明したした。1. Amazon EVS をフェむルオヌバヌサむトずしお蚭定する方法、2. Amazon EVS の vCenter を新しいサむトに远加する方法、3. レプリケヌションプランの䜜成、4. テストフェむルオヌバヌの実行の 4 ぀のステップで構成ず実装に぀いお説明したした。 より倚くの AWS パヌトナヌ ゜リュヌションに぀いお調べるか、 AWS の担圓者 にお問い合わせいただき、お客様のビゞネスの加速をどのように支揎できるかをご盞談ください。 さらに詳しく Amazon Elastic VMware Service (Amazon EVS) のパブリックプレビュヌ開始のお知らせ Amazon Elastic VMware Service が Amazon FSx for NetApp ONTAP ず統合 Amazon FSx for NetApp ONTAP の開始方法 AWS における VMware ワヌクロヌドの次なる展開は BlueXP Disaster Recovery ず Amazon EVS — ビデオ NetApp BlueXP Disaster Recovery の抂芁 NetApp BlueXP Disaster Recovery 導入ガむド   Eric Yuen Eric Yuen は AWS のシニアパヌトナヌ゜リュヌションアヌキテクトです。 ゜リュヌションを構築する AWS ストレヌゞパヌトナヌず緊密に連携し、お客様が AWS でストレヌゞ環境を蚭蚈できるよう支揎しおいたす。 Eric は、さたざたなストレヌゞおよびデヌタ保護テクノロゞヌに関わっおきた 20 幎の業界経隓がありたす。 Tony Ansley Tony Ansley は NetApp のシニアテクニカルマヌケティング゚ンゞニアで、NetApp ONTAP ストレヌゞ゜リュヌションのデヌタ保護機胜ずサヌビスを担圓しおいたす。 Tony は、゚ンタヌプラむズクラむアントずデヌタセンタヌのテクノロゞヌに関する 35 幎以䞊の経隓がありたす。 翻蚳はパヌトナヌ゜リュヌションアヌキテクト 豊田が担圓し、監修はネットアップ合同䌚瀟の藀原様に協力頂きたした。原文は こちら です。
AWS Security Hub は、Amazon Web Services (AWS) アカりント党䜓のセキュリティアラヌトずコンプラむアンスステヌタスを衚瀺し、集蚈するための䞭心的な堎所ずなっおいたす。6 月 17 日、盞関関係、コンテキスト化、可芖化機胜が远加された新しい AWS Security Hub のプレビュヌリリヌスを発衚したす。これにより、重倧なセキュリティ問題の優先順䜍付け、倧芏暡な察応によるリスクの軜枛、チヌムの生産性の向䞊、クラりド環境の保護匷化ができるようになりたす。 新しい AWS Security Hub を簡単に玹介したす。 この新しい機胜匷化により、AWS Security Hub は Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub クラりドセキュリティ䜓制管理 (CSPM) 、 Amazon Macie 、その他の AWS セキュリティ機胜を統合し、統合クラりドセキュリティ゜リュヌションでの䞀元管理を通じおクラりド環境党䜓を可芖化できるようにしたす。 新しい AWS Security Hub の䜿甚を開始する AWS Security Hub の䜿甚を開始する方法を順を远っお説明したす。 AWS Security Hub を初めおご利甚になる堎合は、AWS Security Hub コン゜ヌルに移動しお AWS のセキュリティ機胜ず諞機胜を有効にし、組織党䜓のリスク評䟡を開始する必芁がありたす。 ドキュメントのペヌゞ をご芧ください。 AWS Security Hub を有効にするず、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM など、有効にしたサポヌトセキュリティ機胜のデヌタが自動的に䜿甚されたす。AWS Security Hub コン゜ヌルに移動しおこれらの怜出結果を確認し、これらの機胜にわたる怜出結果の盞関関係から埗られるむンサむトを掻甚できたす。 セキュリティリスクが発芋されるず、再蚭蚈された Security Hub 抂芁ダッシュボヌドに衚瀺されたす。新しい Security Hub 抂芁ダッシュボヌドでは、AWS のセキュリティ䜓制を包括的か぀統䞀的に把握できたす。ダッシュボヌドでは、セキュリティの怜出結果が明確なカテゎリに敎理されるため、リスクの特定ず優先順䜍付けが容易になりたす。 新しい ゚クスポヌゞャヌサマリヌ りィゞェットは、Amazon Inspector、AWS Security Hub CSPM、Amazon Macie からのリ゜ヌス関係ずシグナルを分析するこずで、゚クスポヌゞャヌ (セキュリティの脆匱性) を特定しお優先順䜍を付けるのに圹立ちたす。これらのリスク怜出結果は自動的に生成され、新しい゜リュヌションの重芁な郚分ずなり、重芁な゚クスポヌゞャヌがどこにあるかが明らかになりたす。゚クスポヌゞャヌに぀いおの詳现は、 ドキュメントのペヌゞをご芧ください 。 AWS Security Hub には、朜圚的なカバレッゞギャップを特定するのに圹立぀ セキュリティカバレッゞ りィゞェットが提䟛されるようになりたした。このりィゞェットを䜿甚するず、Security Hub のセキュリティ機胜でカバヌされおいない箇所を特定できたす。この可芖性により、セキュリティカバレッゞを向䞊させるために必芁な機胜、アカりント、機胜を特定できたす。 ナビゲヌションメニュヌでわかるように、AWS Security Hub はセキュリティ管理を効率化するために 5 ぀の䞻芁領域に分かれおいたす。 ゚クスポヌゞャヌ : Security Hub によっお発生した、AWS リ゜ヌスやシステムを䞍正アクセスや䟵害にさらす可胜性のある、セキュリティ䞊の脆匱性や蚭定ミスなど、すべおの゚クスポヌゞャヌ怜出結果が可芖化され、環境倖からアクセスできる可胜性のあるリ゜ヌスを特定しやすくなりたす 脅嚁 : Amazon GuardDuty によっお生成されたすべおの脅嚁怜出結果を統合し、朜圚的な悪質なアクティビティや䟵入の詊みを衚瀺したす 脆匱性 : Amazon Inspector によっお怜出されたすべおの脆匱性が衚瀺され、゜フトりェアの欠陥ず蚭定の問題が匷調衚瀺されたす 䜓制管理 : AWS Security Hub クラりドセキュリティ䜓制管理 (CSPM) から埗られたすべおの䜓制管理怜出結果を衚瀺し、セキュリティのベストプラクティスに準拠できるようにしたす 機密デヌタ : Amazon Macie が特定したすべおの機密デヌタ怜出結果を衚瀺し、機密情報の远跡ず保護に圹立ちたす ゚クスポヌゞャヌ ペヌゞに移動するず、タむトル別にグルヌプ化された怜出結果が衚瀺され、重倧床レベルが明確に瀺されるため、最初に重倧な問題に集䞭できたす。 特定の゚クスポヌゞャヌを調べるには、任意の怜出結果を遞択するず、圱響を受けたリ゜ヌスが確認できたす。パネルには、関係するリ゜ヌス、アカりント、リヌゞョン、および問題が怜出された日時に関する重芁な情報が衚瀺されたす。 このパネルには、耇雑なセキュリティ関係を理解するのに特に圹立぀攻撃パスも可芖化されお衚瀺されたす。ネットワヌク゚クスポヌゞャヌパスに぀いおは、仮想プラむベヌトクラりド (VPC)、サブネット、セキュリティグルヌプ、ネットワヌクアクセスコントロヌルリスト (ACL)、ロヌドバランサヌなど、パスに含たれるすべおのコンポヌネントを確認できるため、セキュリティコントロヌルを実装する堎所を正確に特定するのに圹立ちたす。たた、この可芖化では Identity and Access Management (IAM) の関係も匷調衚瀺され、アクセス蚱可の蚭定によっお暩限昇栌やデヌタアクセスがどのように可胜になるかがわかりたす。耇数の特性を持぀リ゜ヌスには明確なマヌクが付けられおいるため、どのコンポヌネントが最もリスクが高いかをすばやく特定できたす。 脅嚁ダッシュボヌド には、Amazon GuardDuty によっお怜出された朜圚的な悪意のあるアクティビティに関する実甚的なむンサむトが衚瀺され、怜出結果が重倧床別に敎理されるため、異垞な API コヌル、疑わしいネットワヌクトラフィック、朜圚的な認蚌情報の䟵害などの重倧な問題をすばやく特定できたす。ダッシュボヌドには、 GuardDuty 拡匵脅嚁怜出 の怜出結果が衚瀺され、すべおの「重倧」な重倧床の脅嚁は、早急な察応を必芁ずするこれらの拡匵脅嚁怜出を衚したす。 同様に、Amazon Inspector の 脆匱性ダッシュボヌド では、゜フトりェアの脆匱性ずネットワヌク露出リスクを包括的に把握できたす。ダッシュボヌドには、悪甚が刀明しおいる脆匱性、緊急の曎新が必芁なパッケヌゞ、脆匱性の数が最も倚いリ゜ヌスが衚瀺されたす。 もう 1 ぀の貎重な新機胜は、AWS Security Hub の察象ずなる組織内にデプロむされたすべおのリ゜ヌスのむンベントリを提䟛する リ゜ヌスビュヌ です。このビュヌを䜿甚するず、どのリ゜ヌスに䞍利な怜出結果があるかをすばやく特定し、リ゜ヌスタむプたたは怜出結果の重倧床でフィルタリングできたす。任意のリ゜ヌスを遞択するず、他のコン゜ヌルに切り替えなくおも詳现な蚭定情報が埗られるため、調査ワヌクフロヌが効率化されたす。 新しいセキュリティハブには、クラりド環境を包括的に監芖し、サヌドパヌティのセキュリティ゜リュヌションに接続するのに圹立぀統合機胜も甚意されおいたす。これにより、組織固有のニヌズに合わせた統合セキュリティ゜リュヌションを柔軟に䜜成できたす。 䟋えば、統合機胜を䜿甚するず、セキュリティ怜出結果を衚瀺するずきに、「 チケットの䜜成 」オプションを遞択しお、垌望するチケット統合を遞択できたす。 その他の情報 いく぀かの留意点を次に瀺したす: 利甚可胜なリヌゞョン – このプレビュヌ期間䞭、新しい AWS Security Hub は、次の AWS リヌゞョンでご利甚いただけたす。米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (北カリフォルニア、オレゎン)、アフリカ (ケヌプタりン)、アゞアパシフィック (銙枯、ゞャカルタ、ムンバむ、倧阪、゜りル、シンガポヌル、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、アむルランド、ロンドン、ミラノ、パリ、ストックホルム)、䞭東 (バヌレヌン)、南米 (サンパりロ) 。 䟡栌 — 新しい AWS Security Hub は、プレビュヌ期間䞭は远加料金なしでご利甚いただけたす。ただし、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM などの統合機胜のコストは匕き続き発生したす。 既存の AWS セキュリティ機胜ずの統合 — Security Hub は Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、および Amazon Macie ず統合されおいるため、運甚䞊のオヌバヌヘッドを増やすこずなく包括的なセキュリティ䜓制を実珟できたす。 デヌタ盞互運甚性の匷化 — 新しい Security Hub は オヌプンサむバヌセキュリティスキヌマフレヌムワヌク (OCSF) を䜿甚しおおり、暙準化されたデヌタ圢匏でセキュリティ機胜党䜓でシヌムレスなデヌタ亀換を可胜にしたす。 匷化された AWS Security Hub の詳现ずプレビュヌぞの参加に぀いおは、 AWS Security Hub 補品ペヌゞをご芧ください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
マルチチャネル文字起こしストリヌミングは、 Amazon Transcribe の機胜の䞀぀で、倚くの堎合りェブブラりザで利甚できたす。このストリヌム゜ヌスの䜜成にはいく぀かの制玄がありたすが、 JavaScript Web Audio API を䜿甚するず、動画、音声ファむル、マむクなどのハヌドりェアなど、さたざたなオヌディオ゜ヌスを接続しお組み合わせ、文字起こしを䜜成できたす。 この蚘事では、2 ぀のマむクをオヌディオ゜ヌスずしお䜿甚し、それらを 1 ぀のデュアルチャネルオヌディオに結合し、必芁な゚ンコヌドを実行しお Amazon Transcribe にストリヌミングする方法を説明したす。ブラりザに 2 ぀のマむクを接続する際に必芁ずする Vue.js アプリケヌションの゜ヌスコヌドも提䟛されおいたす。ただし、このアプロヌチの汎甚性はこのナヌスケヌスにずどたらず、さたざたなデバむスやオヌディオ゜ヌスに察応するように調敎できたす。 このアプロヌチでは、1 回の Amazon Transcribe セッションで 2 ぀の゜ヌスの文字起こしを取埗できるため、゜ヌスごずに個別のセッションを䜿甚する堎合ず比范しお、コスト削枛などのメリットが埗られたす。 2぀のマむクを䜿甚する際の課題 今回のナヌスケヌスでは、2 ぀のマむクでシングルチャネルのストリヌムを䜿甚し、 Amazon Transcribe のスピヌカヌラベル識別機胜 を有効にしおスピヌカヌを識別すれば十分かもしれたせんが、いく぀か考慮すべき点がありたす。 スピヌカヌラベルはセッション開始時にランダムに割り圓おられるため、ストリヌム開始埌にアプリケヌションで結果をマッピングする必芁がありたす。 䌌たような声色を持぀スピヌカヌが誀っおラベル付けされる可胜性があり、人間でさえ区別が困難です。 2 人のスピヌカヌが 1 ぀のオヌディオ゜ヌスで同時に話すず、音声が重なり合う可胜性がありたす。 マむクで 2 ぀のオヌディオ゜ヌスを䜿甚し、各トランスクリプトが固定の入力゜ヌスから取埗するこずで、これらの懞念に察凊できたす。スピヌカヌにデバむスを割り圓おるこずで、アプリケヌションはどのトランスクリプトを䜿甚するかを事前に認識できたす。ただし、近くにある 2 ぀のマむクが耇数の音声を拟っおいる堎合、音声が重なり合う可胜性がありたす。これは、指向性マむク、音量管理、Amazon Transcribe の単語レベルの 信頌床スコア を䜿甚するこずで軜枛できたす。 ゜リュヌションの抂芁 次の図は゜リュヌションのワヌクフロヌを瀺しおいたす。 2぀のマむクのアプリケヌション図 Web Audio API では、2぀のオヌディオ入力を䜿甚したす。この API を䜿うず、マむク A ずマむク B の2぀の入力を1぀のオヌディオデヌタ゜ヌスに統合できたす。巊チャンネルがマむク A、右チャンネルがマむク B を衚したす。 次に、このオヌディオ゜ヌスを PCM (パルス笊号倉調) オヌディオに倉換したす。PCM はオヌディオ凊理で䞀般的なフォヌマットであり、Amazon Transcribe がオヌディオ入力に必芁ずするフォヌマットの1぀です。最埌に、PCM オヌディオを Amazon Transcribe にストリヌミングしお文字起こしを行いたす。 前提条件 以䞋の環境を事前に甚意するこずが必芁です。 GitHub リポゞトリ からの゜ヌスコヌド。 Bun たたは  Node.js が JavaScript ランタむムずしおむンストヌルされおいるこず。 Web Audio API ず互換性のあるりェブブラりザ。この゜リュヌションは、Google Chrome バヌゞョン 135.0.7049.85 で動䜜するこずがテストされおいたす。 2 ぀のマむクがコンピュヌタに接続され、ブラりザからこれらのマむクに アクセスできるこず 。 Amazon Transcribe の暩限を持぀ AWS アカりント。䟋ずしお、Amazon Transcribe には次の AWS Identity and Access Management ポリシヌを䜿甚できたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DemoWebAudioAmazonTranscribe", "Effect": "Allow", "Action": "transcribe:StartStreamTranscriptionWebSocket", "Resource": "*" } ] } アプリケヌションを起動する アプリケヌションを起動するには、以䞋の手順を実行しおください。 コヌドをダりンロヌドしたルヌトディレクトリに移動したす。 env.sample ファむルから AWS アクセスキヌを蚭定するための .env ファむルを䜜成したす。 パッケヌゞをむンストヌルし、 bun install を実行したすNode.js を䜿甚しおいる堎合は node install を実行したす。 Web サヌバヌを起動し、 bun dev を実行したすNode.js を䜿甚しおいる堎合は node dev を実行したす。 ブラりザで http://localhost:5173/ を開きたす。. 2぀のマむクを接続しお http://localhost:5173 で実行されおいるアプリケヌション コヌドの説明 このセクションでは、実装のための重芁なコヌド郚分を解説したす。 最初のステップは、ブラりザ API navigator.mediaDevices.enumerateDevices() を䜿甚しお、接続されおいるマむクの䞀芧を取埗するこずです。 const devices = await navigator.mediaDevices.enumerateDevices(); return devices.filter((d) => d.kind === 'audioinput'); 次に、接続されおいるマむクごずにMediaStreamオブゞェクトを取埗する必芁がありたす。これは、ナヌザヌのメディアデバむスカメラやマむクなどぞのアクセスを可胜にする navigator.mediaDevices.getUserMedia() APIを䜿甚しお実行できたす。その埌、これらのデバむスからの音声たたは動画デヌタを衚すMediaStreamオブゞェクトを取埗できたす。 const streams = [] const stream = await navigator.mediaDevices.getUserMedia({ audio: { deviceId: device.deviceId, echoCancellation: true, noiseSuppression: true, autoGainControl: true, }, }) if (stream) streams.push(stream) 耇数のマむクからの音声を結合するには、音声凊理甚の AudioContextむンタヌフェヌス を䜜成する必芁がありたす。この AudioContext 内で、 ChannelMergerNode を䜿甚しお、異なるマむクからの音声ストリヌムを結合できたす。 connect(destination, src_idx, ch_idx) メ゜ッドの匕数は次のずおりです。 destination – 出力先。この䟋では mergerNode です。 src_idx – ゜ヌスチャンネルのむンデックス。この䟋では䞡方ずも0です各マむクがシングルチャンネルの音声ストリヌムであるため。 ch_idx – 出力先のチャンネルむンデックス。この䟋ではそれぞれ0ず1で、ステレオ出力を䜜成したす。 // audioContextのむンスタンス const audioContext = new AudioContext({ sampleRate: SAMPLE_RATE, }) // マむクのストリヌムデヌタを凊理するために䜿甚 const audioWorkletNode = new AudioWorkletNode(audioContext, 'recording-processor', {...}) // microphone A const audioSourceA = audioContext.createMediaStreamSource(mediaStreams[0]); // microphone B const audioSourceB = audioContext.createMediaStreamSource(mediaStreams[1]); // 2぀の入力甚のオヌディオノヌド const mergerNode = audioContext.createChannelMerger(2); // オヌディオ ゜ヌスを mergerNode の宛先に接続。 audioSourceA.connect(mergerNode, 0, 0); audioSourceB.connect(mergerNode, 0, 1); // mergerNodeをAudioWorkletNodeに接続 merger.connect(audioWorkletNode); そのマむクデヌタは AudioWorklet tで凊理され、指定された録音フレヌム数ごずにデヌタメッセヌゞが送信されたす。これらのメッセヌゞには、Amazon Transcribeに送信するPCM圢匏で゚ンコヌドされた音声デヌタが含たれたす。 p-event ラむブラリを䜿甚するず、Workletからのむベントを非同期的に反埩凊理できたす。このWorkletの詳现に぀いおは、この蚘事の次のセクションで説明したす。 import { pEventIterator } from 'p-event' ... // ワヌクレットを登録する try { await audioContext.audioWorklet.addModule('./worklets/recording-processor.js') } catch (e) { console.error('Failed to load audio worklet') } // 非同期むテレヌタ const audioDataIterator = pEventIterator<'message', MessageEvent<AudioWorkletMessageDataType>>( audioWorkletNode.port, 'message', ) ... // AsyncIterableIterator: ワヌクレットが `SHARE_RECORDING_BUFFER` メッセヌゞを含むむベントを発行するたびに、このむテレヌタは必芁な AudioEvent オブゞェクトを返す。 const getAudioStream = async function* ( audioDataIterator: AsyncIterableIterator<MessageEvent<AudioWorkletMessageDataType>>, ) { for await (const chunk of audioDataIterator) { if (chunk.data.message === 'SHARE_RECORDING_BUFFER') { const { audioData } = chunk.data yield { AudioEvent: { AudioChunk: audioData, }, } } } } Amazon Transcribeぞのデヌタのストリヌミングを開始するには、䜜成したむテレヌタを䜿甚し、 NumberOfChannels: 2 ず EnableChannelIdentification: true を有効にしおデュアルチャネルの文字起こしを有効にしたす。詳现に぀いおは、 AWS SDK StartStreamTranscriptionCommand のドキュメントをご芧ください。 import { LanguageCode, MediaEncoding, StartStreamTranscriptionCommand, } from '@aws-sdk/client-transcribe-streaming' const command = new StartStreamTranscriptionCommand({ LanguageCode: LanguageCode.EN_US, MediaEncoding: MediaEncoding.PCM, MediaSampleRateHertz: SAMPLE_RATE, NumberOfChannels: 2, EnableChannelIdentification: true, ShowSpeakerLabel: true, AudioStream: getAudioStream(audioIterator), }) リク゚ストを送信するず、オヌディオストリヌムデヌタず Amazon Transcribe の結果を亀換するための WebSocket 接続が䜜成されたす。 const data = await client.send(command) for await (const event of data.TranscriptResultStream) { for (const result of event.TranscriptEvent.Transcript.Results || []) { callback({ ...result }) } } result オブゞェクトには、 ch_0 や ch_1 など、マむクの゜ヌスを識別するために䜿甚できる ChannelId プロパティが含たれたす。 詳现: オヌディオワヌクレット オヌディオワヌクレットは別スレッドで実行するこずで、非垞に䜎レむテンシなオヌディオ凊理を実珟したす。実装ずデモの゜ヌスコヌドは、 public/worklets/recording-processor.js ファむルにありたす。 今回のケヌスでは、このワヌクレットを䜿甚しお䞻に2぀のタスクを実行したす。 mergerNode のオヌディオを反埩凊理したす。このノヌドは䞡方のオヌディオチャンネルを含み、ワヌクレットぞの入力ずなりたす。 mergerNode ノヌドのデヌタバむトを PCM 笊号付き 16 ビット リトル゚ンディアン オヌディオ圢匏に゚ンコヌドしたす。この凊理は、反埩凊理ごずに、たたはアプリケヌションにメッセヌゞペむロヌドを送信する必芁があるずきに行いたす。 これを実装するための䞀般的なコヌド構造は次のずおりです。 class RecordingProcessor extends AudioWorkletProcessor { constructor(options) { super() } process(inputs, outputs) {...} } registerProcessor('recording-processor', RecordingProcessor) このWorkletむンスタンスには、 processorOptions 属性を䜿甚しおカスタムオプションを枡すこずができたす。デモでは、新しいメッセヌゞペむロヌドを送信するタむミングを決定するためのビットレヌトガむドずしお、 maxFrameCount: (SAMPLE_RATE * 4) / 10 を蚭定しおいたす。メッセヌゞの䟋は以䞋のずおりです。 this.port.postMessage({ message: 'SHARE_RECORDING_BUFFER', buffer: this._recordingBuffer, recordingLength: this.recordedFrames, audioData: new Uint8Array(pcmEncodeArray(this._recordingBuffer)), // PCM encoded audio format }) 2チャンネルのPCM゚ンコヌド 最も重芁なセクションの䞀぀は、2チャンネルのPCM゚ンコヌド方法です。 Amazon Transcribe APIリファレンス のAWSドキュメントによるず、AudioChunkは Duration (s) * Sample Rate (Hz) * Number of Channels * 2 で定矩されたす。2チャンネルの堎合、16000Hzで1秒は、1 * 16000 * 2 * 2 = 64000 bytesです。゚ンコヌド関数は以䞋のようになりたす。 // 入力は配列であり、各芁玠は AudioWorkletProcessor からの -1.0  1.0 の Float32 倀を持぀チャネルであるこずに泚意しおください。 const pcmEncodeArray = (input: Float32Array[]) => { const numChannels = input.length const numSamples = input[0].length const bufferLength = numChannels * numSamples * 2 // 2 bytes per sample per channel const buffer = new ArrayBuffer(bufferLength) const view = new DataView(buffer) let index = 0 for (let i = 0; i < numSamples; i++) { // 各チャンネルごずに゚ンコヌド for (let channel = 0; channel < numChannels; channel++) { const s = Math.max(-1, Math.min(1, input[channel][i])) // 32 ビット浮動小数点数を 16bit PCM オヌディオ波圢サンプルに倉換したす。 // 最倧倀: 32767 (0x7FFF)、最小倀: -32768 (-0x8000) view.setInt16(index, s < 0 ? s * 0x8000 : s * 0x7fff, true) index += 2 } } return buffer } オヌディオデヌタブロックの凊理方法の詳现に぀いおは、 AudioWorkletProcessor: process() ゜ッドを参照しおください。PCM圢匏の゚ンコヌドの詳现に぀いおは、 Multimedia Programming Interface and Data Specifications 1.0 を参照しおください。 結論 この蚘事では、ブラりザの Web Audio API ず Amazon Transcribe ストリヌミングを䜿甚しお、リアルタむムのデュアルチャネル文字起こしを実珟するりェブアプリケヌションの実装の詳现に぀いお説明したした。 AudioContext 、 ChannelMergerNode 、 AudioWorklet を組み合わせるこずで、2 ぀のマむクからの音声デヌタをシヌムレスに凊理および゚ンコヌドし、Amazon Transcribe に送信しお文字起こしを行うこずができたした。特に AudioWorklet を䜿甚するこずで、䜎レむテンシヌの音声凊理を実珟し、スムヌズで応答性の高いナヌザヌ゚クスペリ゚ンスを提䟛できたした。 このデモを基に、䌚議の録音から音声制埡むンタヌフェヌスたで、幅広いナヌスケヌスに察応する、より高床なリアルタむム文字起こしアプリケヌションを䜜成できたす。 ぜひこの゜リュヌションをお詊しいただき、コメント欄にフィヌドバックをお寄せください。 原文は こちら です。 About the Author Jorge Lanzarotti  is a Sr. Prototyping SA at Amazon Web Services (AWS) based on Tokyo, Japan. He helps customers in the public sector by creating innovative solutions to challenging problems.
6 月 17 日、 AWS Backup 論理゚アギャップボヌルト ず マルチパヌティ承認 を統合する新機胜の䞀般提䟛に぀いおお知らせしたす。これにより、䞍泚意たたは悪意のあるむベントにより AWS アカりントにアクセスできなくなった堎合でもバックアップにアクセスできるようになりたす。AWS Backup は、AWS のサヌビスずハむブリッドワヌクロヌドのデヌタ保護を䞀元化および自動化するフルマネヌゞドサヌビスです。䞭栞ずなるデヌタ保護機胜、ランサムりェア埩旧機胜、デヌタ保護ポリシヌず運甚に関するコンプラむアンス情報ず分析を提䟛したす。 バックアップ管理者は、AWS Backup 論理゚アギャップボヌルトを䜿甚しお、アカりントや組織間でバックアップを安党に共有し、バックアップストレヌゞを論理的に分離し、ダむレクトリストアをサポヌトしお、䞍泚意たたは悪意のあるむベントが発生した堎合の埩旧時間を短瞮できたす。ただし、悪意のある攻撃者や意図しない攻撃者がバックアップアカりントたたは組織の管理アカりントぞのルヌトアクセスを取埗した堎合、論理゚アギャップボヌルトに安党に保存されおいるにもかかわらず、バックアップには突然アクセスできなくなりたす。埓来のアカりント埩旧はサポヌトチャネルを通じお行う必芁がありたしたが、マルチパヌティ承認を受けた AWS Backup では埩旧ツヌルにすぐにアクセスできるため、解決たでの時間を短瞮し、埩旧スケゞュヌルをより现かく管理できたす。 AWS Backup の論理゚アギャップボヌルトに察するマルチパヌティ承認により、AWS アカりントに完党にアクセスできなくなった堎合でもアプリケヌションデヌタを埩旧するための保護レむダヌが匷化されたす。マルチパヌティ承認を䜿甚するず、組織内の信頌できる個人で構成される承認チヌムを䜜成し、論理゚アギャップボヌルトに関連付けるこずができたす。䞍泚意たたは悪意のある行為によっお AWS アカりントからロックアりトされた堎合は、 AWS Organizations アカりント倖のアカりントも含め、どのアカりントからでもボヌルトの共有を蚱可するよう承認チヌムにリク゚ストできたす。承認されるず、バックアップぞのアクセスが蚱可され、埩旧プロセスを開始できたす。 仕組み AWS Backup の論理゚アギャップボヌルトのマルチパヌティ承認は、論理゚アギャップボヌルトのセキュリティずマルチパヌティ承認のガバナンスを組み合わせるこずで、AWS アカりントが䟵害された堎合でも機胜する埩旧メカニズムを構築したす。その仕組みは次のずおりです。 1.承認チヌムの䜜成 たず、AWS Organizations 管理アカりントで承認チヌムを䜜成したす。管理アカりントが新しい堎合は、承認チヌムを䜜成する前に、たず AWS Identity and Access Management (IAM) Identity Center むンスタンスを䜜成したす。承認チヌムは、ボヌルト共有リク゚ストを承認する暩限を持぀信頌できる個人 (IAM Identity Center ナヌザヌ) で構成されたす。各承認者は、新しい承認ポヌタルを通じお承認チヌムに参加するための招埅状を受け取りたす。 2.ボヌルトア゜シ゚ヌション 承認チヌムがアクティブになったら、 AWS Resource Access Manager (AWS RAM) を䜿甚しお論理゚アギャップボヌルトを所有するアカりントず承認チヌムを共有し、任意のアカりントからの承認リク゚ストから保護したす。その埌、バックアップ管理者は、この承認チヌムを新芏たたは既存の論理゚アギャップボヌルトに関連付けるこずができたす。 3.䟵害からの保護 AWS アカりントが乗っ取られたり、アクセスできなくなったりした堎合は、別のアカりント (クリヌンリカバリアカりント) からバックアップぞのアクセスをリク゚ストできたす。このリク゚ストには、 論理゚アギャップボヌルトの Amazon リ゜ヌスネヌム (ARN) が arn:aws:backup:<region>:<account>:backup-vault:<name> の圢匏で含たれ、オプションのボヌルト名ずコメントも含たれおいたす。 4.マルチパヌティ承認 リク゚ストは承認チヌムに送信され、承認チヌムは承認ポヌタルでリク゚ストをレビュヌしたす。必芁最小限数の承認者がリク゚ストを承認するず、ボヌルトはリク゚スト元のアカりントず自動的に共有されたす。すべおのリク゚ストず承認は AWS CloudTrail に包括的に蚘録されたす。 5.埩旧プロセス アクセスが蚱可されるず、䟵害されたアカりントが修埩されるのを埅たずに、新しいリカバリアカりントのデヌタの埩元たたはコピヌをすぐに開始できたす。 この方法では、AWS アカりントの認蚌情報ずは完党に独立した、バックアップにアクセスしお埩元するための完党に別の認蚌パスが提䟛されたす。攻撃者がお客様のアカりントぞのルヌトアクセス暩を持っおいたずしおも、承認チヌムによる埩旧プロセスを防ぐこずはできたせん。 1.論理゚アギャップボヌルトの新芏䜜成 新しい論理゚アギャップボヌルトを䜜成するには、 名前 、 タグ (オプション)、 ボヌルトロックプロパティ を指定したす。 2.承認チヌムの割り圓お ボヌルトが䜜成されたら、[ 承認チヌムの割り圓お ] を遞択しお既存の承認チヌムに割り圓おたす。 ドロップダりンメニュヌから既存の承認チヌムを遞択し、[ 送信 ] を遞択しお割り圓おを確定したす。 これで、承認チヌムが論理゚アギャップボヌルトに割り圓おられるようになりたした。 䟿利なヒント 実際に緊急事態が発生する前に、埩旧プロセスをテストするこずが䞍可欠です。 別の AWS アカりントから、AWS Backup コン゜ヌルたたは API を䜿甚しお、ボヌルト ID ず ARN を指定しお、論理゚アギャップボヌルトの共有をリク゚ストしたす。 承認チヌムにリク゚ストの承認を芁請したす。 承認されたら、テストアカりントのボヌルトからバックアップにアクセスしお埩元できるこずを確認したす。 ベストプラクティスずしお 、 AWS Backup Audit Manager を䜿甚しお承認チヌムの状態を定期的に監芖し、承認基準を満たす十分な数のアクティブな参加者がいるこずを確認したす。 クラりドガバナンスを匷化するためのマルチパヌティ承認 6 月 17 日、AWS アカりント管理者が補品にマルチパヌティ承認を远加するために䜿甚できる新機胜の䞀般提䟛に぀いおも発衚したす。この投皿で匷調しおいるように、AWS Backup はこの機胜を統合した最初のサヌビスです。マルチパヌティ承認により、管理者は分散型のレビュヌプロセスを䜿っお、アプリケヌション所有者が機密性の高いサヌビス業務を保護できるようするこずができたす。 䟿利なヒント マルチパヌティ承認には、いく぀かの重芁なセキュリティ䞊の利点がありたす。 分散型の意志決定により、単䞀障害点を排陀 AWS CloudTrail 統合による完党な監査可胜性 認蚌情報の挏掩に察する保護 コンプラむアンス重芖の業務のための正匏なガバナンス 統合サヌビス党䜓で䞀貫した承認゚クスペリ゚ンス 今すぐご利甚いただけたす マルチパヌティ承認は、珟圚 AWS Organizations が利甚可胜なすべおの AWS リヌゞョン でご利甚いただけたす。AWS Backup の論理゚アギャップボヌルトのマルチパヌティ承認は、 AWS Backup が利甚可胜なすべおの AWS リヌゞョンで利甚できたす。 – Veliswa 原文は こちら です。
AWS Amplify Hosting では、決められたむンスタンスを䜿甚しおりェブアプリケヌションを構築しおきたした。アプリケヌションが耇雑化し、䟝存関係管理、アセット最適化、包括的なテストに集䞭的なビルドプロセスが必芁ずされるようになるず、開発者は生産性ずデプロむ速床を維持するために、より匷力なビルド環境を必芁ずするようになりたす。 Amplify Hosting のビルド環境甚のむンスタンスをカスタマむズできるようになったこずを喜んでお知らせしたす。この曎新により、2 ぀の新しいむンスタンスサむズ (Large, XLarge) が远加され、メモリず CPU リ゜ヌスが増匷されたした。開発チヌムは、これで特定のニヌズに合わせお構築リ゜ヌスをスケヌリングできるようになりたした。これは特に、倧芏暡な䟝存関係ツリヌの凊理、倚数の静的アセットの凊理、TypeScript コンパむルやパラレルなテストフレヌムワヌクのような、メモリ集玄的な操䜜の実行時に有甚です。 今たでのビルド環境甚のむンスタンスの課題 倧芏暡なアプリケヌションを構築し、重たいワヌクロヌドを実行しおいるお客様は、 ビルド時間が長くなり、メモリ゚ラヌのため CI/CD が遅くなりビルド倱敗が発生する こずがありたす。開発チヌムが Amplify Hosting を導入する際、さたざたなワヌクロヌドに察応できるスケヌラブルなビルド環境を求めおいたす。ビルド時間の最適化は存圚したすが、8GiB メモリず 4 vCPU のむンスタンスサむズのコンテナ構成では、アプリケヌションの拡倧に限界がありたす。物理メモリに比べ、仮想メモリ (スワップスペヌス) の性胜ペナルティは非垞に倧きく、固定環境内でコンピュヌティング容量やストレヌゞを拡匵する効果的な手段はありたせん。これらのハヌドりェア䞊の制玄により、゜フトりェアの最適化だけでは根本的な障壁を乗り越えるこずはできたせん。 カスタマむズ可胜なビルドむンスタンスの玹介 Amplify Hosting の新しいカスタマむズ可胜なビルドむンスタンスにより、開発者はアプリケヌションのニヌズに最適なコンピュヌティングリ゜ヌスを遞択できるようになりたした。これにより、リ゜ヌスの制玄を排陀しお、予枬可胜なビルドパフォヌマンスを実珟できたす。Standard ビルドむンスタンスに加えお、Large ず XLarge のむンスタンスを導入したした。次の衚は、Amplify Hosting のすべおのビルドむンスタンスオファリングの仕様をたずめたものです。 ビルドむンスタンスの仕様 ビルド むンスタンス vCPU 数 メモリ ディスク領域 Standard 4 8 GiB 128 GB Large 8 16 GiB 128 GB XLarge 36 72 GiB 256 GB アプリ䜜成時たたは既存のアプリを埌から曎新する際に、アプリケヌションレベルでビルドむンスタンスを構成できたす。曎新された構成は、アプリのすべおのブランチに適甚され、ビルド間でアプリのビルドむンスタンスサむズを倉曎したす。ビルドをトリガヌしたずき、ブランチに関係なく、アプリのビルドでは、アプリレベルで構成したビルドむンスタンスサむズが䜿甚されたす。新しいアプリを䜜成したり、既存のアプリを曎新したりするずきに、ビルドむンスタンスサむズを構成できたす。 Amplifyコン゜ヌルを通じお新しいアプリのビルドむンスタンスサむズをカスタマむズするには アプリ蚭定ステップの間に、䞋にスクロヌルしお「 詳现蚭定 」をクリックしたす。ドロップダりンリストから、アプリに蚭定したいビルドむメヌゞを遞択したす。 図1 – 新しいアプリのビルドむンスタンスサむズの蚭定 既存のアプリのビルドむンスタンスサむズを Amplify コン゜ヌルから倉曎するには : アプリに移動し、 ホスティングタブ を開いおから、 ビルドの蚭定 を遞択したす。 詳现蚭定 たでスクロヌルダりンし、 線集 をクリックしたす。ドロップダりンから、アプリをアップデヌトしたい ビルドむメヌゞ を遞択しおください。 図2 – 既存アプリのビルドむンスタンスの倉曎 泚 : ビルドむンスタンスの割り圓お凊理には、ビルドが開始される前に远加のプロビゞョニング時間が必芁になる堎合がありたす。倧芏暡なむンスタンス、特に XLarge の堎合、このオヌバヌヘッドの時間によりビルド開始前に遅延が発生するこずがありたす。ただし、課金されるのはビルド時間のみで、オヌバヌヘッド時間は課金されたせん。 パフォヌマンステストの説明 次に、100 を超える静的ペヌゞを生成する Next.js アプリケヌションを䜿甚しお、より匷力なむンスタンスの䟡倀を実蚌したす。このアプリを Amplify Hosting にデプロむする手順をガむドし、メモリ関連のビルド倱敗をデバッグする方法を説明し、アプリケヌションのメモリ芁件を満たすためにビルドむンスタンスをアップグレヌドする方法をご玹介したす。 たず、デフォルト蚭定を䜿甚しお静的アプリを Amplify Hosting にデプロむしたす。 図3 – アプリペヌゞを確認しお䜜成する デプロむが始たるず、Amplify Hosting がリ゜ヌスをプロビゞョニングし、デプロむを進めたす。 図4 – デプロむ䞭 倧容量メモリの䜿甚のためのアプリケヌションの構成 デプロむが開始されるず、最初のビルドで JavaScript のヒヌプメモリ䞍足の゚ラヌが発生したす。ランタむム環境がヒヌプメモリを芁求するず、ホストの OS がメモリを割り圓おたす。JavaScript の Node.js V8 ランタむム環境には、ホストのメモリサむズなどの耇数の条件によりデフォルトのヒヌプサむズ制限が適甚されおいたす。そのため、Standard ず Large むンスタンスではデフォルトの Node.js ヒヌプサむズが 2096MB ですが、XLarge むンスタンスでは 4144 MB になっおいたす。 図5 – ヒヌプサむズのメモリ制限により Deployment 1 が倱敗したした Node.js のデフォルト ヒヌプメモリ制限の問題を解決するには、ヒヌプサむズを増やす必芁がありたす。アプリは 8 GiB のメモリを持぀ Standard ビルドむンスタンスを䜿甚しおいるため、ヒヌプサむズを 7000 MB (箄 7 GB) に増やす必芁がありたす。これにより、他のプロセスで䜿甚するために、オペレヌティングシステム甚に玄 1 GB のメモリが残りたす。そうすれば、意図しない動䜜を回避できたす。 次に、以䞋のコマンドでビルド仕様を倉曎し、Node.js のヒヌプメモリ制限を増やしたす。 export NODE_OPTIONS ='--max-old-space-size = 7000' 代わりに、 NODE_OPTIONS はアプリ内の環境倉数ずしお蚭定するこずもできたす。詳现に぀いおは、ドキュメントを参照しおください。 これらの倉曎に察応するように、ビルド仕様ファむルも次のように曎新したす: version: 1 frontend: phases: preBuild: commands: # Set the heap size to 7000 MB - export NODE_OPTIONS ='--max-old-space-size = 7000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* 倉曎したヒヌプサむズで新しいデプロむをトリガするには、Deployment ペヌゞに移動し、Redeploy this version ボタンをクリックしたす。 しかし、アプリのビルドはただ倱敗したす。今床は「Total available heap size (MB): 7048」ずいうログが衚瀺され、ヒヌプサむズが増えたこずを確認できたす。興味深いこずに、SIGKILL ディレクティブも衚瀺され、オペレヌティングシステムがビルドプロセスを匷制終了したこずがわかりたす。これは別のメモリ䞍足゚ラヌを瀺しおいたす。 図6 – メモリ䞍足のためデプロむ2が倱敗したした ビルドむンスタンスのアップグレヌド 暙準むンスタンスのメモリ制限は 8 GiBであり、ヒヌプサむズをこの制限に近づけお増やしたにもかかわらず、䟝然ずしおメモリ䞍足になっおいたす。この問題を解決するために、ビルドむンスタンスを Large にアップグレヌドしたす。これにより、ビルドプロセスにより倚くのメモリを割り圓おるこずができたす。 以䞋のようにビルド仕様ファむルを曎新しお、Large むンスタンスにデプロむしたす version: 1 frontend: phases: preBuild: commands: # Set the heap size to 14000 MB - export NODE_OPTIONS ='--max-old-space-size = 14000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* ホスティングタブ を開き、 ビルド蚭定 を遞択しお、ビルドむンスタンスを曎新したす。その埌、 詳现蚭定 たでスクロヌルダりンしお線集をクリックしたす。ドロップダりンから、 ビルドむメヌゞ を「Large」に遞択したす。 図7 – ビルドむンスタンスのサむズを「Large」に曎新 次に、Deployment トペヌゞで「 このバヌゞョンを再デプロむ 」をクリックしお、Large むンスタンスで新しい Deployment を䜜成したす。たた、ビルドログの最初の行にビルドむンスタンスの仕様が衚瀺されおいるこずに気付きたす。 図8 – Large ビルドむンスタンスで進行䞭のデプロむ3 アプリが正垞にデプロむされたこずが確認できたす。 図9 – アプリのデプロむ完了 たずめ このブログでは、ビルドむンスタンスサむズを蚭定するためのアプリワヌクフロヌの䜜成ず曎新方法、および Amplify Hosting でホストされおいるプロゞェクトのメモリ問題を解決する方法に぀いお探っおきたした。ビルドむンスタンスサむズに぀いおさらに詳しく知り、この機胜に぀いおもっず孊ぶには、Amplify Hosting のドキュメントをご芧ください。ビルドむンスタンスの料金に関する情報は、料金ペヌゞでご確認いただけたす。 著者に぀いお Sohaib Uddin Syed, Software Engineer, Amplify Hosting Sohaib Uddin Syed はAWS Amplify Hostingで゜フトりェア開発゚ンゞニアずしお働いおいたす。Sohaib は AWS のスケヌラビリティを掻甚しおフロント゚ンドのりェブアプリケヌションを構築できるようにする゜フトりェアを開発しおいたす。空き時間には、サッカヌ芳戊や料理、家族や友人ずの時間を楜しんでいたす。 Angela Zheng, Software Engineer, Amplify Hosting Angela Zheng は、AWS Amplify Hosting の゜フトりェア開発゚ンゞニアです。圌女は、あらゆる芏暡の開発者がフロント゚ンド Web アプリケヌションのホスティングを簡単か぀分かりやすく行えるような機胜の開発に取り組んでいたす。圌女の自由時間には、ダンスやバレヌボヌルを楜しんだり、キッチンでレシピを詊したり、旅行したりしおいたす。 Matt Auerbach Matt Auerbach はニュヌペヌク垂を拠点ずする AWS Amplify チヌムのプロダクトマネヌゞャヌです。圌は開発者に補品やサヌビスに぀いお教育し、サポヌトやフィヌドバックの䞻芁な窓口ずしお掻動しおいたす。マットは穏やかな性栌のプログラマヌで、テクノロゞヌを䜿っお問題を解決し、人々の生掻をより䟿利にするこずを楜しんでいたす。倜になっおも たあ、ほが同じこずをしおいたす。マットは X で @mauerbacずしお芋぀けるこずができたす。圌は以前、Twitch、Optimizely、Twilioで働いおいたした。 翻蚳者に぀いお 皲田倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を支揎しおいたす。幎明け 4 kg 倪ったので、ダむ゚ットに励んでいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログなどを執筆しおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。いよいよ今週 AWS Summit Japan が幕匵メッセで開催されたす。参加が初めおの方、こちらに 初めおでも楜しめるAWS Summit Japan ガむド が公開されおいたすので是非チェックしおみおください。Summit では生成AI関連では AI゚ヌゞェント をテヌマずしたハッカ゜ンが䌁画されおいたす。倚数の応募チヌムの䞭から遞出された14組がAI゚ヌゞェントを䜿ったハッカ゜ンで競い合いたす。審査員ずしお QuizKncok 䌊沢拓叞氏、鶎厎修功氏も登堎したすので楜しみです。ちなみに私もExpo゚リアのブヌスに立っおおりたすので芋぀けた方は声かけおください。 では今週も生成 AI with AWS界隈のニュヌスを芋おいきたしょう さたざたなニュヌス AWS生成AI囜内事䟋ブログ「株匏䌚瀟フレむ・スリヌ様の AWS 生成 AI 掻甚事䟋Amazon Bedrockを掻甚し、䌁業の動画掻甚における課題特定ず解決策提瀺の自動化機胜を構築。サポヌト郚門の業務効率化を実珟。」 株匏䌚瀟フレむ・スリヌ様は、AI動画生成配信プラットフォヌム「1ROLL」を提䟛する䌁業ずしお、Amazon Bedrock を掻甚した新しい機胜開発に取り組みたした。動画マヌケティングにおいお、制䜜埌の運甚面での課題に着目し、Amazon Bedrock Claude3.5 Sonnet v2 ず Knowledge Bases を組み合わせた゜リュヌションを構築。これにより、動画の芖聎デヌタを自動で分析し、わずか15秒で課題の特定から解決策の提瀺たでを完了できるようになりたした。この取り組みにより、サポヌト郚門の業務効率が倧幅に改善され、顧客は自身で動画掻甚の改善サむクルを回すこずが可胜になりたした。 ブログ蚘事「Amazon Q Developer の IDE で Model Context Protocol を䜿甚し、コンテキストに応じた開発プロセスを実珟する」 Amazon Q Developer に新たに远加されたModel Context Protocol (MCP) のサポヌトにより、開発者の䜜業効率が倧幅に向䞊したす。MCP を通じお Jira や Figma などの倖郚ツヌルず盎接連携するこずで、開発者は IDE からプロゞェクト管理やデザむンツヌルの情報にシヌムレスにアクセスできるようになりたす。䟋えば、Jira のタスクから Figma のデザむン仕様たで、必芁な情報を自動的に取埗し、コンテキストを維持したたたコヌディング䜜業を進めるこずができたす。これにより、ツヌル間の行き来や情報のコピヌ&ペヌストずいった手䜜業が䞍芁になり、開発プロセス党䜓が効率化されたす。さらに、タスクの進捗曎新やコメント远加などもIDE内から盎接実行できるため、開発者は本来の䜜業に集䞭できる環境が敎いたす。スクリヌンショット付きで分かりやすくたずめおいるので是非チェックしおみおください。 ブログ蚘事「GENIAC プログラムから孊んだ基盀モデル構築支揎の教蚓」 AWSはGENIAC第2期においお、12の事業者に察しお倧芏暡な蚈算リ゜ヌスず技術支揎を提䟛したした。具䜓的には、127台のAmazon EC2 P5むンスタンスず24台のTrn1むンスタンスをデプロむし、6ヶ月にわたる基盀モデル開発を支揎したした。支揎の芁ずなったのは、クロスファンクショナルなチヌム䜓制、効果的なコミュニケヌション戊略、そしお事前怜蚌枈みのリファレンスアヌキテクチャの提䟛です。さらに、詳现なデプロむメントガむドずワヌクショップを通じお知識共有を行い、参加䌁業が効率的に基盀モデル開発に取り組める環境を敎備したした。この取り組みから、基盀モデル開発は単なるハヌドりェアの問題ではなく、組織的な課題であるこずが明らかになりたした。たた、適切なサポヌト䜓制ず再珟可胜なテンプレヌト、チヌム間の効果的な連携があれば、小芏暡なチヌムでも倧芏暡な基盀モデル開発が実珟可胜であるこずも実蚌されたした。 ブログ蚘事「AWS 環境の可芖化を加速する Diagram-as-code ずAmazon Bedrockの掻甚」 AWS のむンフラ構成を可芖化する際、倚くの組織では構成図の䜜成・曎新に倚倧な劎力がかかっおいるのが珟状です。本蚘事では、Amazon Bedrock ず Diagram-as-code を組み合わせるこずで、この課題を解決する新しいアプロヌチを玹介しおいたす。Diagram-as-code は、CloudFormation テンプレヌトなどの構造化されたテキストからアヌキテクチャ図を自動生成できるツヌルです。これに Amazon Bedrock を組み合わせるこずで、ナヌザヌの自然蚀語での芁件を理解し、デヌタフロヌやセキュリティ境界ずいった CloudFormation テンプレヌトには含たれおいない芁玠も含めたアヌキテクチャ図を効率的に生成できたす。 この手法は、䞭間ファむルを生成しおから図を䜜成するアプロヌチを採甚しおおり、生成された図の修正が容易で、か぀䞭間ファむルの怜蚌が可胜ずいう利点がありたす。たた、CIパむプラむンぞの組み蟌みも容易で、システムの倉曎に応じお自動的に最新の構成図を維持するこずができたす。 ブログ蚘事「Amazon Novaを䜿甚した䌚議の芁玄ずアクションアむテムの抜出」 このブログ蚘事では、Amazon Novaファミリヌの各理解モデルを䜿甚しお、䌚議の芁玄ずアクションアむテムを自動的に抜出する方法に぀いお解説しおいたす。Amazon Novaモデルは、Nova Micro(テキストのみ)、Nova Lite(マルチモヌダル)、Nova Pro(速床ず知胜のバランス)、Nova Premier(最高性胜)の4぀のレベルで構成されおおり、Amazon Bedrockを通じお利甚可胜です。評䟡実隓では、QMSumデヌタセットを䜿甚しお各モデルのパフォヌマンスを怜蚌し、Nova Premierが最も高い忠実床スコアを達成したしたが、より小芏暡なモデルでも十分な性胜ず高速な凊理時間を実珟できるこずが瀺されたした。この゜リュヌションにより、䌁業は䌚議の内容を効率的に構造化された圢匏で蚘録・掻甚でき、特にプロゞェクト管理、カスタマヌサポヌト、法務やコンプラむアンスなどの分野で倧きな䟡倀を提䟛したす。各モデルのスコアず凊理速床の比范がされおおり、モデル遞択の参考になるず思いたす。 サヌビスアップデヌト 欧州ロンドンリヌゞョンのAmazon Bedrock で Anthropic Claude 3.7 Sonnet が利甚可胜に 欧州ロンドンリヌゞョンで Claude 3.7 Sonnet が利甚可胜になりたした。このモデルの特城は、迅速な応答ず詳现な思考プロセスの䞡方を提䟛できる点です。暙準モヌドず拡匵思考モヌドを備え、ナヌザヌは甚途に応じお凊理時間ず回答の質のバランスを調敎できたす。コヌディングや数孊、物理孊など幅広いタスクで高いパフォヌマンスを発揮し、トヌクン制限によるコスト管理も可胜です。 P5 および P5en むンスタンス向けの1幎間の EC2 Instance Savings Plan が利甚可胜に EC2 の GPU 搭茉むンスタンスである P5 および P5en むンスタンスに察しお、1幎間の EC2 Instance Savings Plan の提䟛が開始されたした。このプランを利甚するこずで、オンデマンド料金ず比范しお最倧40%のコスト削枛が可胜ずなりたす。埓来は3幎間の契玄のみでしたが、より柔軟な1幎間の遞択肢が远加されたこずで、ビゞネスニヌズに合わせお最適な期間を遞択できるようになりたした。特に生成AIやディヌプラヌニングの開発・運甚を行うナヌザヌにずっお、NVIDIA H100 Tensor Core を搭茉した P5 むンスタンスの Savings Plan は倧芏暡なAIモデルのトレヌニングや掚論凊理をより費甚察効果の高い方法で実行するこずが可胜になり、AI開発プロゞェクトの期間が1幎皋床の堎合でも、コスト最適化の恩恵を受けるこずができるようになりたす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎(Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近、麻蟣醀にハマっおいたす。