AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 9月に入り秋を少し感じられるようになっおきたした。 9月の builders.flash 蚘事が出おいたすので生成AI関連のものをピックアップしおみたす。 カメラ画像を Amazon Bedrock で解析 ! ~ SORACOM Flux における安党な AI 呌び出しず効果的なプロンプトの探求株匏䌚瀟゜ラコム様 少数粟鋭・高創造性ぞの転換Amazon Q Developer CLI を掻甚したオフショア開発の効率化株匏䌚瀟 プロト゜リュヌション様 ゚ンゞニアの挑戊を加速させる ! ~ 生成 AI ハンズオンワヌクショップ ~株匏䌚瀟豊田自動織機IT゜リュヌションズ様 Strands SDK を䜿っお、AWS Lambda Tool MCP Server を詊しおみた !AWS MCP (Model Context Protocol) で MCP (Minecraft Play) しお芪の嚁厳を取り戻す倏 ~ Strands Agents を添えお ~AWS どの蚘事も実践的か぀生成AI掻甚の芳点が異なっおいお参考になりたすね。 盎近控えおいるむベントずしおは、2025 幎 9 月 24 日 (æ°Ž) に Amazon Nova による業務革新事䟋の玹介を䞭心ずしたむベント「AWS Amazon Nova Ignite」が開催予定です。 こちらから申し蟌み可胜 ですので是非ご参加ください。 先日 2぀の新しいプランを远加した「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も非垞に倚くの申し蟌みをいただいおいたす。匕き続き募集䞭ですのでよろしくお願いしたす。 それでは、9 月 1 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「9 月 15 日たで無料で Kiro を䜿甚」を公開 開発者向け゚ヌゞェント型 IDE「Kiro」にお、 8 月 22 日の䟡栌曎新 に続き、9 月 15 日たで無料䜿甚を延長するこずが発衚されたした。本ブログでは、返金凊理の詳现、䜿甚制限のリセット、超過料金の無料提䟛1,000 回の vibe リク゚ストず 200 回の spec リク゚スト、今埌の䟡栌倉曎予定などに぀いおQA圢匏で説明しおいたす。 ブログ蚘事「SAP ず AWS が AI 共同むノベヌションプログラムを発衚 : 垂堎の倉動性ずサプラむチェヌンの耇雑性に察応するための生成 AI ゜リュヌションを創出ぞ」を公開 2025 幎の SAP Sapphire にお、AWS ず SAP は AI 共同むノベヌションプログラムを発衚したした。本ブログでは、パヌトナヌが ERP ワヌクロヌドに特化した生成 AI アプリケヌションず゚ヌゞェントを構築できるよう支揎するプログラムの抂芁、Amazon Bedrock ず SAP Business Technology Platform の統合、Accenture や Deloitte などのパヌトナヌ䌁業ずの協力事䟋を玹介しおいたす。 ブログ蚘事「生成 AI ず IoT でスマヌト産業機械の䟡倀を最倧化」を公開 本ブログでは、生成 AI ず IoT を組み合わせおスマヌト産業機械の䟡倀を最倧化するナヌスケヌスや実珟方法に぀いお解説しおいたす。1/問題の蚺断・解決支揎、2/フィヌルドサヌビスオペレヌションの匷化、3/装眮フリヌト分析、4/AI蚺断レポヌトの4぀のナヌスケヌスを取り䞊げ、Amazon Bedrock ず AWS IoT サヌビスを掻甚した具䜓的なアヌキテクチャず実装方法を玹介しおいたす。 ブログ蚘事「第 4 回 AWS ゞャパン 生成 AI Frontier Meetup 孊びず繋がりの堎【開催報告】」を公開 2025 幎 8 月 26 日に第 4 回 AWS ゞャパン生成AI Frontier Meetup を開催したした。本ブログでは、生成AI実甚化掚進プログラムの成果、Amazon Nova の新機胜、Kiro や Amazon Bedrock AgentCore などの最新サヌビス、参加䌁業によるラむトニングトヌク、GENIAC 採択者による基盀モデル開発事䟋など、むベントで玹介された幅広い内容をたずめおいたす。 ブログ蚘事「CloudWatch ゚ヌゞェントを甚いたAI ゚ヌゞェントの監芖方法」を公開 AI ゚ヌゞェントアプリケヌションが想定通りの顧客䜓隓を生み出しおいるかを担保するためには包括的なオブザヌバビリティが必芁です。本ブログでは、AI ゚ヌゞェントアプリケヌションを Amazon CloudWatch で監芖する方法に぀いお玹介しおいたす。Strands Agents SDK を䜿甚したサンプルアプリケヌションを䟋に、CloudWatch ゚ヌゞェントの蚭定方法、トレヌス・メトリクス・ログの収集、X-Ray による可芖化、実際のデプロむ手順ずテレメトリデヌタ分析の具䜓的な実装方法を玹介しおいたす。 サヌビスアップデヌト AWS Transform アセスメントに分離ストレヌゞが含たれるように AWS Transform のアセスメント評䟡機胜が拡匵され、オンプレミスのストレヌゞむンフラ分析が可胜になりたした。これたで Compute やネットワヌクの評䟡が䞭心でしたが、今回 SAN や NAS などのストレヌゞも分析察象ずなりたした。Amazon S3 や Amazon EBS ぞの移行掚奚が自動生成され、より具䜓的な移行蚈画が立おられるようになりたす。 AWS Transform for VMware が柔軟なネットワヌク管理ずより広い AWS リヌゞョンカバレッゞをサポヌト AWS Transform for VMware が VPC CIDR 範囲の倉曎をサポヌト開始したした。これによりオンプレミスず AWS 環境で IP 競合なく䞊行皌働ができるようになりたした。たた、新たにオハむオ、ストックホルム、アむルランドリヌゞョンでの利甚もサポヌトされたした。 Amazon BedrockでAnthropic Claudeモデルの簡玠化されたキャッシュ管理機胜を開始 Amazon Bedrock の Anthropic Claude モデル (Claude 3.5 Haiku、Claude 3.7、Claude 4) で、䜿いやすさが向䞊されたプロンプトキャッシング機胜が利甚できるようになりたした。これたではプロンプトのどの郚分をキャッシュから再利甚するか開発者自身で管理する必芁がありたしたが、今回の機胜により、リク゚スト末尟にキャッシュブレヌクポむントを蚭定するのみで利甚可胜になりたした。この機胜は各モデルが提䟛されおいる党おのリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon Bedrock がアゞアパシフィック (ゞャカルタ) リヌゞョンで利甚可胜に Amazon Bedrock がゞャカルタリヌゞョンで利甚可胜になりたした。ゞャカルタリヌゞョンにデヌタを珟地に保持しながら生成 AI アプリケヌションを構築できるようになりたす。詳现は こちらのドキュメント をご参照ください。 Amazon BedrockがAnthropic Claude Sonnet 4のグロヌバルクロスリヌゞョン掚論をサポヌト開始 Amazon Bedrock で Anthropic Claude Sonnet 4 のグロヌバルクロスリヌゞョン掚論がサポヌトされたした。これたではUS、EU、APAC などの特定の地域に玐づいたクロスリヌゞョン掚論を遞択できたした。今回のサポヌトにより、トラフィックが集䞭した際に特定地域に䟝存しない分散凊理が可胜ずなり、モデルスルヌプットをより向䞊させるこずができたす。詳现に぀いおは クロスリヌゞョン掚論によるスルヌプット向䞊 、および 掚論プロファむルでサポヌトされおいるリヌゞョンずモデルのドキュメント もご確認ください。 AWS が Amazon Bedrock の API キヌを管理するための 3 ぀の新しい条件キヌのサポヌトを远加 Amazon Bedrock の API キヌ管理がより柔軟になりたした。3぀の新しい条件キヌが远加され、管理者は API キヌの生成、有効期限、蚱可されるAPIキヌのタむプをより现かく制埡できたす。䟋えば、Amazon Bedrock 専甚の長期 API キヌ䜜成は蚱可し぀぀、CodeCommit等の他サヌビス甚の生成は犁止するずいった蚭定が可胜です。詳现は こちらのドキュメント をご参照ください。 Amazon Neptune が生成AIアプリケヌションの長期蚘憶を支揎するZepずの統合を発衚 Amazon Neptune ず Zep の統合が発衚されたした。Zep は LLM アプリケヌション向けのオヌプン゜ヌスメモリサヌバヌで、ナヌザヌずのやり取りの履歎の氞続化、取埗、および拡匵が可胜です。これにより、Neptune Database たたは Neptune Analytics をグラフストアずしお利甚し぀぀、Amazon OpenSearch を Zep のメモリシステムのテキスト怜玢ストアずしお䜿甚するこずで、よりパヌ゜ナラむズされたLLMアプリケヌションが構築しやすくなりたした。詳现に぀いおはこちらの サンプルノヌトブック をご確認ください。 Amazon EKS の Split Cost Allocation Data が NVIDIA および AMD GPU、Trainium、Inferentia 搭茉 EC2 むンスタンスをサポヌト Amazon EKS の Split Cost Allocation Data が GPU や Trainium、Inferentia を䜿った加速コンピュヌティングワヌクロヌドに察応したした。これたで CPU ずメモリのコストしか远跡できたせんでしたが、今回のアップデヌトで NVIDIA や AMD の GPU、AWS の AI チップのコストも詳现に把握できるようになりたす。AI/ML ワヌクロヌドを耇数のチヌムで運甚しおいる䌁業では、各チヌムのリ゜ヌス䜿甚量に応じた正確なコスト配分が可胜になりたす。詳现は こちらのブログ蚘事 をご参照ください。 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は AI Agent ず毎日戯れおおり、AI Agent 無しでは生きおいけなくなっおいたす。奜きなうどんは’かけ’です。
本投皿は、 Channy Yunによる蚘事 「Introducing Oracle Database@AWS for simplified Oracle Exadata migrations to the AWS Cloud」 を翻蚳したものです。 2025幎7月8日、AWS 内の Oracle Real Application Clusters (RAC) を含む Oracle Exadata ワヌクロヌド向けの新補品である Oracle Database @AWS の䞀般提䟛に぀いお発衚したした。 過去14幎間、お客様は、 Amazon Elastic Compute CloudAmazon EC2 を䜿甚しおクラりドでOracle Databaseのワヌクロヌドを自己管理するか、フルマネヌゞド型の Amazon Relational Database ServiceAmazon RDSfor Oracle を䜿甚するかを遞択しおいたした。この床、クラりドぞの迅速か぀簡単な移行のためにOracle RACたたはOracle Exadataを必芁ずするワヌクロヌド甚のオプションが远加されたした。費甚に぀いおは、AWSぞのコミットメントや、Bring Your Own LicenseBYOL・Oracle Support Rewardsなどの割匕プログラムを含むオラクルのラむセンス特兞にカりントされる請求曞が、AWS Marketplaceを通じお発行されたす。 Oracle Database @AWS を䜿甚するず、最小限の倉曎で、Oracle ExadataワヌクロヌドをAWS内の専甚むンフラストラクチャ䞊のOracle Exadata Database Serviceたたは専甚Exadataむンフラストラクチャ䞊のOracle Autonomous Databaseに移行できたす。Oracle Database @AWS デプロむメントは、 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、たたは AWS で実行されるアプリケヌション甚の AWS API などの䜿い慣れた AWS ツヌルずむンタヌフェむスを介しお賌入、プロビゞョニング、管理できたす。AWS APIは、リ゜ヌスのプロビゞョニングず管理に必芁なOracle Cloud Infrastracture(OCI) APIを呌び出したす。 2024幎12月の プレビュヌ 以来、䞀般提䟛時にむけお本番環境のワヌクロヌドを実行するのに圹立぀機胜を改善たたは远加しおきたした。 リヌゞョンの拡倧 – 2025幎7月時点で、Oracle Database @AWS を米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) リヌゞョンで䜿甚できるようになりたした。たた、䞖界20のAWSリヌゞョンに拡倧する蚈画も発衚しおいたす。このように幅広く利甚できるため、さたざたな地域のお客様の倚様なニヌズに察応できるため、より倚くの䌁業がこのオプションの恩恵を受けるこずができたす。AWSリヌゞョンのワヌクロヌド芁件に合わせお、さたざたなExadataシステムサむズを遞択できたす。 Zero-ETL ず S3バックアップぞの察応 – Amazon Redshift ずの Zero-ETL統合 による分析が可胜になり、抜出、倉換、ロヌド操䜜のためのデヌタパむプラむンを構築および管理する必芁がなくなりたした。Zero-ETL統合を䜿えば、ネットワヌク間のデヌタ転送コストをかけずに、AWSでデヌタを統合できたす。99.9999999% (むレブンナむン) のデヌタ耐久性を備えた  Amazon Simple Storage Service (Amazon S3)  ã®ãƒãƒƒã‚¯ã‚¢ãƒƒãƒ—を提䟛しおいたす。 Autonomous VMクラスタ – Exadata専甚むンフラストラクチャ䞊のExadata VMクラスタに加えお、Autonomous VMクラスタをプロビゞョニングできるようになりたした。Oracle Autonomous Databaseは、専甚のハヌドりェアず゜フトりェアのリ゜ヌスを䜿甚する完党に管理されたデヌタベヌス環境である専甚のExadataむンフラストラクチャで実行できたす。 Oracle Database @AWS は、S3 や Redshift などの AWS サヌビスぞのネットワヌクパスを盎接蚭定するための Amazon Virtual Private Cloud (Amazon VPC) Lattice、認蚌ず承認のための AWS Identity and Access Management (IAM) 、デヌタベヌスラむフサむクルむベントのモニタリングのための Amazon EventBridge 、むンフラストラクチャの自動化のための AWS CloudFormation 、メトリクスの収集ずモニタリングのための Amazon CloudWatch 、API 操䜜のロギングのための AWS CloudTrail など、他の AWS サヌビスず統合されおいたす。 Oracle Database@AWS 入門 Oracle Database @AWS は 2 ぀の䞻芁なサヌビスをサポヌトしおいたす。1 ぀は AWS デヌタセンタヌ内の専甚むンフラストラクチャ䞊の Oracle Exadata Database Serviceず、専甚の Exadata むンフラストラクチャ䞊の Oracle Autonomous Database です。 これらのサヌビスは、物理的にはAWSリヌゞョンのアベむラビリティヌゟヌン内に存圚し、論理的にはOCIリヌゞョンに存圚するため、高速で䜎遅延の接続を通じおAWSサヌビスずシヌムレスに統合できたす。 アベむラビリティヌゟヌン内でOracle Exadata VMクラスタヌをホストするプラむベヌトで独立したネットワヌクであるODBネットワヌクを䜜成したす。次に、VPCで実行されおいるEC2アプリケヌションサヌバヌにアクセスできるODBピアリングを䜿甚したす。詳现に぀いおは、AWS ドキュメントの 「How Oracle Database@AWS works」 を参照しおください。 AWS Marketplaceでプラむベヌトオファヌをリク゚スト Oracle Database @AWS を開始するには、 AWS Console にアクセスするか、 AWS Marketplaceのプラむベヌトオファヌ をリク゚ストしおください。AWSずOracleの営業チヌムがリク゚ストを受け取り、お客様のワヌクロヌドに最適なオプションを芋぀けお連絡し、アカりントを有効にしたす。 Oracle Database @AWS をアクティブ化しおアクセスできるようになるず、 ダッシュボヌド を䜿甚しおODBネットワヌク、Exadataむンフラストラクチャ、Exadata VMクラスタたたはAutonomous VMクラスタ、およびODBピアリング接続を䜜成できたす。 詳现に぀いおは、AWS ドキュメントの「 Onboarding to Oracle Database@AWS 」ず ã€Œ AWS Marketplace buyer private offers 」をご芧ください。 ODBネットワヌクの䜜成 ODBネットワヌクは、AWS䞊でOCIむンフラストラクチャをホストするプラむベヌトな分離ネットワヌクです。ODBネットワヌクは、OCIの子サむト内に存圚するネットワヌクに盎接マッピングされ、AWSずOCI間の通信手段ずしお機胜したす。 ダッシュボヌド で、「 Create ODB network 」を遞択し、ネットワヌク名を入力し、アベむラビリティヌゟヌンを遞択し、アプリケヌションによっお確立されるクラむアント甚接続ず自動バックアップに䜿甚するバックアップ甚接続のCIDR範囲を指定したす。 oraclevcn.com ず固定しお、ドメむンのプレフィックスずしお䜿甚する名前を入力するこずもできたす。たずえば、 myhost ず入力した堎合、完党修食ドメむン名は myhost.oraclevcn.com です。 オプションで、ODBネットワヌクアクセスを蚭定しお、Amazon S3ぞの自動バックアップやZero-ETLのむンフラストラクチャに関する蚭定を行い、Amazon Redshiftを䜿甚しおほがリアルタむムの分析ずOracleデヌタの機械孊習を行う準備を行えたす。 ODBネットワヌクを䜜成したら、EC2アプリケヌションサヌバヌのVPCルヌトテヌブルをODBネットワヌクのクラむアント接続CIDRで曎新したす。詳现に぀いおは、AWSドキュメントの「 ODB network 」、「 ODB peering 」、「 Configuring VPC route tables for ODB peering 」を参照しおください。 Exadataむンフラストラクチャの䜜成 Oracle Exadataむンフラストラクチャは、Oracle Exadata Databaseを実行するデヌタベヌスサヌバヌ、ストレヌゞサヌバヌ、ネットワヌクの基盀ずなるアヌキテクチャです。 Exadataむンフラストラクチャの䜜成を遞択し、名前を入力しお、デフォルトのアベむラビリティヌゟヌンを䜿甚しおください。次のステップでは、 Exadata.X11M をExadataシステムモデルずしお遞択できたす。たた、デヌタベヌスサヌバヌ最小台〜最倧台ずストレヌゞサヌバヌ最小台〜最倧台、サヌバヌあたり80TBのストレヌゞ容量をそれぞれ蚭定するこずが可胜です。 最埌に、スケゞュヌル、パッチモヌド、OCIメンテナンス通知連絡先など、システムメンテナンスの蚭定を構成できたす。AWSコン゜ヌルからむンフラストラクチャを䜜成した埌で倉曎するこずはできたせん。しかし、OCIコン゜ヌルに移動しお倉曎するこずはできたす。 Exadataむンフラストラクチャを削陀するには、AWSドキュメントの「 Deleting an Oracle Exadata infrastructure in Oracle Database@AWS 」を参照しおください。 Exadata VMクラスタヌたたはAutonomous VMクラスタヌを䜜成 Exadataむンフラストラクチャヌ䞊にVMクラスタヌを䜜成し、同じODBネットワヌクに異なるOracle Exadataむンフラストラクチャヌを持぀耇数のVMクラスタヌをデプロむできたす。 VMクラスタヌには2皮類ありたす Exadata VMクラスタヌは、Oracle Enterprise Editionのすべおの機胜を含む完党なOracle Databaseがむンストヌルされた仮想マシンのセットです。 Autonomous VMクラスタヌは、完党に管理されたデヌタベヌスのセットで、人間の介入なしにAI/MLを䜿甚しお䞻芁な管理タスクを自動化したす。 Exadata VMクラスタヌの䜜成 を遞択し、VMクラスタヌ名ずタむムゟヌンを入力し、Bring Your Own LicenseBYOLたたはラむセンスオプションに含たれるラむセンスを遞択したす。次のステップでは、Exadataむンフラストラクチャ、grid infrastructureのバヌゞョン、Exadata imageのバヌゞョンを遞択できたす。デヌタベヌスサヌバヌの堎合は、各VMのCPUコア数、メモリ、ロヌカルストレヌゞを遞択するか、デフォルト倀を遞択するこずができたす。 次のステップでは、ODBネットワヌクを遞択し、VMクラスタヌのプレフィックスを入力するこずで、接続蚭定を構成できたす。single client access name(SCAN)リスナヌぞのTCPアクセスのポヌト番号を入力できたす。デフォルトのポヌトは1521です。たたは、1024〜8999の範囲でカスタムSCANポヌトを入力できたす。SSHキヌペアの堎合は、VMクラスタヌぞのSSHアクセスに䜿甚される1぀以䞊のキヌペアの公開鍵郚分を入力しおください。 次に、蚺断ずタグを遞択し、蚭定を確認しお、VMクラスタヌを䜜成できたす。VMクラスタヌのサむズにもよりたすが、䜜成プロセスには最倧6時間かかるこずがありたす。 Oracle Databaseを䜜成しお管理 VMクラスタヌの準備が敎ったら、OCIコン゜ヌルでOracle Exadataデヌタベヌスを䜜成しお管理できたす。Exadata VMクラスタヌの詳现ペヌゞで「 Manage in OCI 」を遞択しおください。OCIコン゜ヌルにリダむレクトされたす。 OCIコン゜ヌルでOracle Databaseを䜜成するずきは、Oracle Database 19cたたは23aiを遞択できたす。プロビゞョニングされたデヌタベヌスの自動バックアップを有効にする堎合は、S3バケットたたはOCIリヌゞョンのOCIオブゞェクトストレヌゞを䜿甚できたす。詳现に぀いおは、OCI ドキュメントの 「 Provision Oracle Exadata Database Service in Oracle Database@AWS 」を参照しおください。 泚意事項 Oracle Database @AWS に぀いお知っおおくべきこずがいく぀かありたす。 モニタリング — VM クラスタヌ、コンテナデヌタベヌス、およびプラガブルデヌタベヌスの AWS/ODB 名前空間にある Amazon CloudWatch メトリクスを䜿甚しお Oracle Database @AWS をモニタリングできたす。AWS CloudTrailは、Oracle Database @AWS に察するすべおの AWS API 呌び出しをむベントずしおキャプチャしたす。CloudTrailのログを䜿甚するず、Oracle Database @AWS に察しお行われたリク゚スト、リク゚ストが行われたIPアドレス、リク゚ストが行われた日時、および远加の詳现を確認できたす。詳现に぀いおは、「 Monitoring Oracle Database@AWS 」をご芧ください。 セキュリティ — IAM を䜿甚しお、Oracle Database @AWS リ゜ヌスず、デヌタを保護するための SSL/TLS 暗号化接続を誰に管理できるかを決定する暩限を割り圓おるこずができたす。 Amazon EventBridge を䜿甚しお、むベント䞻導型のデヌタベヌスをシヌムレスに運甚するこずもできたす。すべおが連携しおセキュリティ基準を維持するず同時に、効率的なクラりド運甚が可胜になりたす。詳现に぀いおは、「 Security in Oracle Database@AWS 」をご芧ください。 コンプラむアンス — Oracle Database @AWS を䜿甚する堎合のコンプラむアンス責任は、デヌタの機密性、䌚瀟のコンプラむアンス目暙、および適甚される法埋ず芏制によっお決たりたす。お客様は、オラクルのクラりド・コンプラむアンスに関する情報を オラクルのりェブサむト で芋぀けるこずができたす。Oracle Database @AWS は、SOC 1、SOC 2、SOC 3、HIPAA、C5、CSA STAR Attest、CSA STAR Cert、HDS (フランス)、ISO シリヌズ (ISO/IEC 9001、20000-1、27001、27017、27018、27701、22301)、PCI DSS、HITRUSTなど、AWSコンプラむアンスプログラムの察象範囲内のAWSサヌビスず統合されおいたす。 サポヌト — AWSたたはOracleの営業アカりントチヌムが、珟圚のデヌタベヌスむンフラストラクチャの評䟡、Oracle Database@AWS が組織の芁件に最も合臎するための方法の決定、およびカスタマむズされた移行戊略ずタむムラむンの策定を支揎したす。たた、AWSクラりドで実行されるOracleベヌスのワヌクロヌドの蚭蚈、デプロむ、管理を専門ずする AWS Oracleコンピテンシヌパヌトナヌ から支揎を受けるこずもできたす。 珟圚利甚可胜な機胜、近日公開予定の機胜 Oracle Database @AWS は、AWS マヌケットプレむスを通じお米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) リヌゞョンで利甚できるようになりたした。Oracle Database @AWS の䟡栌蚭定ず AWS マヌケットプレむスのプラむベヌトオファヌはOracleによっお蚭定されたす。䟡栌に関する具䜓的な詳现は、 Oracleのサヌビスの䟡栌蚭定ペヌ ゞで確認できたす。 Oracle Database @AWS は、以䞋を含む南北アメリカ、ペヌロッパ、アゞア倪平掋地域のさらに20のAWSリヌゞョンに拡倧する予定です: 米囜東郚オハむオ、米囜西郚北カリフォルニア、アゞア倪平掋メルボルン、アゞアパシフィックムンバむ、アゞアパシフィック倧阪、アゞアパシフィック゜りル、アゞアパシフィックシンガポヌル、アゞアパシフィックシドニヌ、アゞアパシフィック東京、カナダ䞭倮、ペヌロッパフランクフルト、ペヌロッパロンドン、ペヌロッパミラノ、ペヌロッパパリ、ペヌロッパスペむン、ペヌロッパストックホルム、ペヌロッパチュヌリッヒ、南米サンパりロ AWS コン゜ヌル を䜿っお Oracle Database @AWS を䜿い始めるこずができたす。詳现に぀いおは、「 Oracle Database@AWS User Guide 」ず OCI のドキュメント にアクセスし、通垞の AWS サポヌトの連絡先たたは OCI サポヌト にフィヌドバックを送っおください。 本投皿ぞのご意芋はコメント欄にお願いしたす。 翻蚳は゜リュヌションアヌキテクトの 矢朚 芚 が担圓したした。原文は こちら です。
2025 幎 8 月 28 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer Meetup #2 – Amazon Q Developer を業務で掻甚した成果共有ず最新情報 Update – 」のむベントの様子をレポヌトしたす。 このむベントは、AWS が提䟛する生成 AI アシスタント、 Amazon Q Developer をテヌマに実斜したした。たず゜リュヌションアヌキテクトの小西から、Amazon Q Developer ず、 AI IDE である “Kiro” の最新情報アップデヌト情報をご玹介させおいただきたした。続いお、Amazon Q Developer をご利甚いただいおいる株匏䌚瀟 LIFULL 様、株匏䌚瀟マむナビ様から、どのように業務やプロゞェクトに掻かしおいるのか、リアルな䜿い方や工倫、実際に感じた効果に぀いお発衚しおいただきたした。 珟地参加・オンラむン参加合わせお 200 名以䞊の方にご登録いただきたした。参加者からは「各瀟さんの取り組み状況が聞けおずおも参考になりたした」ずの感想をいただきたした。これから Amazon Q Developer を導入しおみたい方、すでに利甚しおいるがさらに掻甚したい方、他瀟の利甚状況に興味がある方、それぞれの皆様にご参考いただける情報をご玹介させおいただきたした。 むベント抂芁 開催日時: 2025幎8月28日 䌚堎: AWS Startup Loft Tokyo (目黒)、オンラむン配信 スピヌカヌ 株匏䌚瀟 LIFULL 様 「Amazon Q Developer 掻甚による業務効率化ず倚職皮展開」 株匏䌚瀟 マむナビ様 「Amazon Q Developer 導入実践蚘 – リスク察策から組織浞透たで」 Konishi Kyosuke, Solutions Architect, Amazon Web Services Japan G.K. 「Amazon Q Developer & Kiro アップデヌト情報」 Amazon Q Developer & Kiro の最新アップデヌト情報 スピヌカヌ: Konishi Kyosuke, Solutions Architect, Amazon Web Services Japan G.K. 資料ダりンロヌドはこちら: Amazon Q Developer & Kiro アップデヌト情報 はじめに、゜リュヌションアヌキテクトの小西より、Amazon Q Developer ず Kiro の最新アップデヌト情報をご玹介したした。Amazon Q Developer は開発者のための生成 AI アシスタントで、統合開発環境 (IDE)・コマンドラむン (CLI)・AWS マネゞメントコン゜ヌル ず、さたざたなシチュ゚ヌションで利甚者をご支揎したす。Kiro は仕様駆動開発 (Spec driven development) をコンセプトずした AI IDE で、AI ゚ヌゞェントを最倧限掻甚した開発䜓隓をご提䟛したす。 小西からは Amazon Q Developer の倚蚀語察応 (日本語含) の拡匵や、CLI でのカスタム゚ヌゞェント、マネゞメントコン゜ヌルでの Agentic 察応などの新機胜をご玹介したした。たた、Kiro の䟡栌䜓系の最新情報に぀いおもご説明したした。 お客様事䟋: 株匏䌚瀟 LIFULL 様「Amazon Q Developer 掻甚による業務効率化ず倚職皮展開」 LIFULL 様のご登壇資料は Amazon Q Developer掻甚による 業務効率化ず倚職皮展開 にお公開されおいたす。 株匏䌚瀟 LIFULL 様からは、「Amazon Q Developer 掻甚による業務効率化ず倚職皮展開」ず題しお、Amazon Q Developer の掻甚状況に぀いお事䟋玹介をしおいただきたした。 HTML の生成によるスラむド䜜成の自動化 (この発衚資料も) や、サヌビス䌁画におけるプロトタむプ䜜成に効果枬定レポヌト自動化、アむデア出しなど、゚ンゞニアの利甚に限らない、幅広いナヌスケヌスをご玹介いただきたした。瀟内での利甚者増加トレンドや瀟内 MCP の利甚状況、利甚状況ランキング、カスタム゚ヌゞェントの蚭定など瀟内での普及掻動に぀いおもご説明いただきたした。 お客様事䟋: 株匏䌚瀟マむナビ様 「Amazon Q Developer 導入実践蚘 – リスク察策から組織浞透たで」 ご登壇資料ダりンロヌドはこちら: Amazon Q Developer 導⌊実践蚘 – リスク察策から組織浞透たで 株匏䌚瀟 マむナビ様からは、「Amazon Q Developer 導入実践蚘 – リスク察策から組織浞透たで」ず題しお、Amazon Q Developer の掻甚状況に぀いお事䟋玹介をしおいただきたした。 Amazon Q Developer を導入する際のリスク芳点での怜蚎内容や性胜・費甚、アクセス暩限や暗号化・承認フロヌずいったルヌル䜜りのプロセスに぀いおご説明いただきたした。たた、利甚を匷制しない圢での導入促進掻動に぀いおもご玹介いただきたした。さらに、/context など Amazon Q Developer の䟿利機胜の玹介や、CI/CD パむプラむンの゚ラヌ分析、勉匷䌚での掻甚など運甚・利甚䞡方の芳点からの掻甚事䟋をご共有いただきたした。 ネットワヌキング 珟地参加の方のみ、ケヌタリングをご甚意し、ネットワヌキングのための懇芪䌚を実斜したした。 登壇者の方ぞの質問や、参加者同士の意芋亀換、AWS メンバヌぞの盞談が掻発におこなわれおいたした。 おわりに 今回のむベントでは AWS が提䟛する生成 AI アシスタントの Amazon Q Developer をいかに導入・掻甚されおいるかをお客様の事䟋を䞭心にご玹介させおいただきたした。株匏䌚瀟 LIFULL 様、株匏䌚瀟マむナビ様にご登壇いただき、コヌディングだけではなく、䌁画・デザむン・むンフラストラクチャの運甚など、さたざたな掻甚方法をご玹介いただきたした。Amazon Q Developer、そしお Kiro は今埌も分野の発展に䌎っおサヌビスアップデヌトを続けおたいりたす。 次回の開催予定 次回の Amazon Q Developer Meetup #3 は AI 駆動開発ラむフサむクル (AI-DLC) をテヌマに開催予定です。詳现は埌日公開させおいただきたすので、 むベント䞀芧ペヌゞ の曎新をお埅ちください。 yamazaki hiroki profile-20250806 山厎 宏玀 (Hiroki Yamazaki) 山厎宏玀 は Amazon Web Services Japan G.K. の゜リュヌションアヌキテクトずしお、ISV/SaaS 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築、生成 AI の掻甚をご支揎しおいたす。Amazon Q Developer や AWS Cloud Development Kit (AWS CDK) を奜みたす。(より良いご支揎のために) AI ゚ヌゞェントに代わりに働いおもらおうず画策しおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 残暑が厳しいですが、みなさんいかがお過ごしでしょうか早く涌しくなるず良いですね・・・ アップデヌトの前に䞀぀宣䌝をさせおください。 今月、9月25日にデヌタベヌスパフォヌマンスの最適化をテヌマに、MariaDBずAWSの専門家によるむベントを予定しおいたすMariaDBを利甚する方に限らず、RDSのパフォヌマンス最適化をお考えのデヌタベヌス管理者やアプリケヌション開発者の方がいらっしゃいたしたらぜひご掻甚ください 2025 MariaDB Database Performance Meetup@Japan 2025幎9月25日朚13:0017:00開堎 12:30 䌚堎AWS Startup Loft 東京 / 目黒セントラルスク゚ア 17F それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎9月1日週の䞻芁なアップデヌト 9/1(月) 米囜の祝日のためアップデヌトはありたせんでした。 9/2(火) Simplified Cache Management for Anthropic’s Claude models in Amazon Bedrock Amazon Bedrock の Anthropic Claude モデル (Claude 3.5 Haiku、Claude 3.7、Claude 4) で䜿いやすさが向䞊し、簡玠化されたプロンプトキャッシング機胜が利甚できるようになりたした。これたでは開発者が明瀺的にプロンプトの䞀郚を指定し、管理する必芁がありたした。今回の機胜により、リク゚スト末尟にキャッシュブレヌクポむントを蚭定するだけで、システムは以前にキャッシュされた最も長いプレフィックスから自動的に読み取るため、手動で指定する必芁がなくなりたす。この簡玠化されたキャッシュ管理機胜はキャッシュ読み取りトヌクンが 1 分あたりのトヌクン (TPM) クォヌタにカりントされないため、マルチタヌン䌚話や怜玢アシスタントの構築がより効率的になりたす。この機胜は各モデルが提䟛されおいるリヌゞョン党おで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon Neptune Now Integrated with Zep to Power Long-Term Memory for GenAI Applications Amazon Neptune ず Zep の統合が発衚されたした。Zep は LLM アプリケヌション向けのオヌプン゜ヌスメモリサヌバヌで、ナヌザヌむンタラクション履歎の氞続化、取埗、および拡匵が可胜です。これにより、Neptune Database たたは Neptune Analytics を基盀ずなるグラフストアずしお、Amazon OpenSearch を Zep のメモリシステムのテキスト怜玢ストアずしお䜿甚できるようになり、長期蚘憶、コンテキスト、掚論を備えた LLM ゚ヌゞェントの構築がより簡単になりたす。詳现に぀いおはこちらの サンプルノヌトブック をご確認ください。 Announcing a new open source project for scenario-focused AWS CLI scripts 新しいオヌプン゜ヌスプロゞェクト「AWS Developer Tutorials」が GitHub で公開されたした。これは 60 以䞊の AWS サヌビスに察応したシェルスクリプト集で、゚ラヌハンドリングやリ゜ヌスのクリヌンアップたで含んだシナリオ重芖の実甚的なCLIコヌドを提䟛するものです。埓来 AWS CLI でスクリプトを曞く際に発生しがちな゚ラヌ凊理やリ゜ヌス管理の課題を解決し、Amazon Q Developer CLI などの生成 AI ツヌルず組み合わせるこずで、反埩的なテストず改善プロセスを通じお動䜜するスクリプトを生成できたす。わずか 15 分皋床で動䜜するスクリプトを䜜成できるようになりたす。詳现は GitHubのリポゞトリ ず Builder Centerの投皿 をご確認ください。 Amazon CloudWatch Synthetics adds multi-browser support for application testing Amazon CloudWatch Synthetics が既存の Chrome に加えお、Firefox ブラりザをサポヌトしたした。Amazon CloudWatch Synthetics ã¯ã‚Šã‚§ãƒ–アプリケヌションのテストず監芖を可胜にするサヌビスで、Playwright や Puppeteer ベヌスのカナリアスクリプトを実行できたす。今回のFirefox ブラりザサポヌトによりブラりザ固有の問題特定も察応し、パフォヌマンスメトリクス、成功率、ビゞュアル監芖結果を自動的に収集できたす。この機胜はすべおの商甚AWSリヌゞョンで利甚可胜です。詳现に぀いおはこちらの ドキュメント をご確認ください。 9/3(æ°Ž) Amazon Bedrock now supports Global Cross-Region inference for Anthropic Claude Sonnet 4 Amazon Bedrock で Anthropic Claude Sonnet 4 のグロヌバルクロスリヌゞョン掚論がサポヌトされたした。これたでもUS、EU、APAC などの特定の地域に玐づいたクロスリヌゞョン掚論を遞択できたした。今回の機胜によりトラフィックが集䞭した際に、これたでより柔軟に分散凊理が可胜になり、モデルスルヌプットをさらに向䞊させるこずができたす。詳现に぀いおは クロスリヌゞョン掚論によるスルヌプット向䞊 、および 掚論プロファむルでサポヌトされおいるリヌゞョンずモデル のドキュメントもご確認ください。 Amazon RDS for Oracle introduces bare metal instances with 25% lower pricing compared to equivalent virtualized instances Amazon RDS for Oracle ず Amazon RDS Custom for Oracle がベアメタルむンスタンスをサポヌトしたした。ベアメタルむンスタンスは同等の仮想むンスタンスず比范しお25%䜎䟡栌で、 M7i、R7i、X2iedn、X2idn、X2iezn、M6i、M6id、M6in、R6i、R6id、R6inがサポヌトされたす。䟋えば、db.r7i.16xlarge むンスタンスず db.r7i.8xlarge むンスタンスで実行されおいるデヌタベヌスを、単䞀の db.r7i.metal-24xl むンスタンス䞊の個別のプラガブルデヌタベヌスに統合するなどマルチテナントにしお収容率を高めるこずができたす。たた、ベアメタルむンスタンスは基盀サヌバヌの CPU コア数ず゜ケット数を完党に可芖化するため、商甚デヌタベヌスラむセンスずサポヌトコストを削枛できる可胜性がありたす。ラむセンス削枛の可胜性に関しおは、 Oracle Cloud Policy  ãš  Oracle Core Factor Table  ã‚’参照し、ラむセンスパヌトナヌに盞談しお刀断ください。利甚可胜なむンスタンス構成、䟡栌蚭定、リヌゞョンの可甚性に぀いおは、 Amazon RDS for Oracle の料金 ず  Amazon RDS Custom for Oracle の料金 を参照しおください。 Amazon CloudWatch now supports querying metrics data up to two weeks old Amazon CloudWatch の Metrics Insights が、2 週間前たでのメトリクスデヌタのク゚リをサポヌトしたした。これたでは 3 時間前たでのデヌタのみ察応しおいたしたが、今回の機胜拡匵により長期間のトレンド分析や障害の圱響調査が可胜になりたす。この機胜は党おの商甚AWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 9/4(朚) Amazon Connect adds detailed disconnect reasons for improved call troubleshooting Amazon Connect で、アりトバりンド通話の詳现な切断理由が確認できるようになりたした。埓来は通話が倱敗した際の原因調査においお倚くのケヌスでサポヌトチケットの䜜成が必芁でした。今回のアップデヌトにより暙準的なテレコム゚ラヌコヌドに基づいた詳现な理由が衚瀺されるため、コヌルセンタヌの運甚担圓者は迅速にトラブルシュヌティングを行えたす。この機胜はAmazon Connectが利甚可胜なすべおのリヌゞョンで利甚可胜です。詳现はこちらの ドキュメント ず ベストプラクティスガむド をご確認ください。 ECS Exec is now available in the AWS Management Console Amazon ECS のECS Exec がAWS マネゞメントコン゜ヌルからの実行をサポヌトしたした。これたでECS Exec は AWS API、CLI、たたは SDK を通じおのみアクセス可胜で、コン゜ヌルでトラブルシュヌティングを行う際にはそれらにむンタヌフェヌスを切り替える必芁がありたした。今回マネゞメントコン゜ヌルからの実行をサポヌトしたこずでむンタヌフェヌスを切り替えるこずなく、実行䞭のコンテナに察しお安党でむンタラクティブなシェルアクセスを盎接開くこずが可胜になりたした。この機胜はすべおの商甚AWSリヌゞョンで利甚可胜です。詳现に぀いおは ドキュメント をご確認ください。 Amazon EC2 announces AMI Usage to better monitor the use of AMIs Amazon EC2 で AMI (Amazon Machine Image) 䜿甚状況確認機胜が提䟛されたした。これたで AMI の䜿甚状況の確認をするには独自スクリプトが必芁でした。今回のアップデヌトにより、むンスタンス、起動テンプレヌト、Image Builder レシピ、SSM パラメヌタなど、耇数のリ゜ヌス党䜓でアカりント内の任意の AMI の䜿甚状況を確認できる他、䜿甚しおいるアカりントを䞀芧衚瀺するレポヌトを生成できたす。この機胜により管理・運甚䜜業を効率的に実斜できたす。この機胜はすべおのリヌゞョンで利甚可胜です。詳现はこちらの ドキュメント をご確認ください。 9/5(金) Announcing general availability of Organizational Notification Configurations for AWS User Notifications AWSのナヌザヌ通知をOrganizations党䜓で蚭定および衚瀺できるようになりたした。これたで通知蚭定は各 AWS アカりント個別にしおいたしたが、今回のアップデヌトにより管理アカりントもしくは委任管理者DAから䞀元管理できるようになりたす。たた、EventBridgeのむベントによる通知もサポヌトされたす。この機胜はすべおの リヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Enhancing threat detection with Amazon GuardDuty new custom entity lists Amazon GuardDuty が゚ンティティリストを䜿甚した脅嚁怜出のカスタマむズをサポヌトしたした。これたでの脅嚁怜出は IP アドレスリストを元に実斜するこずができたした。今回のアップデヌトによりサポヌトされた゚ンティティリストにはドメむン、 IP アドレスたたはその䞡方を含めるこずができ、より包括的な脅嚁怜出が可胜になりたす。たた、゚ンティティリストは信頌できる゜ヌスからのアラヌト抑制にも利甚可胜です。この機胜はGuardDutyが提䟛されるすべおのリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon CloudFront launches TLS security policy with post-quantum support Amazon CloudFront は、既存のすべおの Transport Layer Security (TLS) セキュリティポリシヌにおいお、ハむブリッド耐量子鍵確立のサポヌトを発衚したした。珟圚は埩号できない情報も量子コンピュヌティングの発達によっお将来的に埩号される脅嚁に察抗する耐量子暗号 (PQC)をクラむアントから゚ッゞぞの接続においお適甚し、デヌタを保護するこずが可胜です。PQC は既存ポリシヌで自動有効化され、远加蚭定や料金は䞍芁です。加えお、TLS オプションを匷化する新しい TLS 1.3 専甚ポリシヌ(TLS1.3_2025)も提䟛されたした。これにより最新のセキュリティ暙準を芁求する組織でもより高いセキュリティず性胜を実珟できたす。これらの詳现は ドキュメント をご確認ください。 それでは、たた来週 ゜リュヌションアヌキテクト 根本 裕芏 著者に぀いお 根本 裕芏(Yuki Nemoto) AWS Japan の゜リュヌションアヌキテクトずしお、金融機関のお客様の AWS 掻甚や個別案件の技術支揎を担圓しおいたす。過去には公共郚門やモダナむれヌションのスペシャリストもしおいたした。奜きなサヌビスは AWS CodeBuild です。週末はオフロヌドバむクのレヌスをしおいたす
こんにちは、Amazon Connect ゜リュヌションアヌキテクトの枅氎です。8月も終わりたしたが、ただただ厳しい気候が続きたすね。皆様くれぐれもご自愛ください。さお、2025幎7月のアップデヌトたずめ はご芧いただけたしたか今月も新しいバッゞやアップデヌト情報を䞭心に以䞋の内容をお届けしたす。皆さんのお圹に立぀内容があれば幞いです 泚目のアップデヌトに぀いお 2025幎8月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 1. 泚目のアップデヌトに぀いお Amazon Connect AI Fundamentals – Knowledge Badge Readiness Path (Amazon Connect の新しい孊習プランが公開) このプランでは、Amazon Connect における AI 機胜の実践的掻甚ずコンタクトセンタヌでの機械孊習に぀いお孊習したす。AI を掻甚したむンシデント凊理の最適化、効率的なモニタリング、リ゜ヌス管理を䞭心に、Contact Lens による察話分析や Amazon Q によるむンテリゞェントアシスタンスの掻甚方法を解説したす。リアルタむム分析ず感情分析を通じお゚ヌゞェントのパフォヌマンス向䞊を図り、パヌ゜ナラむズされた顧客䜓隓の実珟に向けた実装戊略を孊びたす。たた、プラむバシヌ保護を含む倫理的 AI の実践に぀いおも取り䞊げたす。本プランは、AI・機械孊習のコンタクトセンタヌ掻甚に関心がある方、および Amazon Connect の運甚・分析・管理に携わる方を察象ずしおいたす。 孊習リ゜ヌスの構成 Amazon Connect AI and ML Fundamentals Amazon Connect AI Supervisor Capabilities Amazon Connect AI Workforce Optimization Amazon Connect AI Agent Capabilities Amazon Connect AI Self-Service Capabilities Amazon Connect AI Customer Engagement Amazon Connect AI Fundamentals Assessment このカリキュラムを修了し、ナレッゞチェックを 80% 以䞊のスコアで合栌するず Credly から Amazon Connect AI Fundamentals バッゞを獲埗できたす。これはクラりドスキルや経隓を䌝えるために圹立おるこずができたす。このトレヌニングは無償で利甚可胜で、珟圚は英語で提䟛しおいたす。孊習には AWS Skill Builder のアカりントが必芁です。 Amazon Connect がりェブサむトやアプリケヌションぞのタスクずメヌルの組み蟌みをすぐに利甚可胜に Amazon Connect コミュニケヌションりィゞェットの新しいお問い合わせフォヌムオプションを䜿甚しお、タスクず E メヌルベヌスのカスタマヌ゚クスペリ゚ンスをりェブサむトやアプリケヌションで簡単に提䟛できるようになりたした。䟋えば、コミュニケヌションりィゞェットをりェブサむトに远加しお、顧客が営業時間倖にコヌルバックリク゚ストを送信したり、りェブフォヌムから E メヌルを送信したりできるようにするこずができたす。スヌパヌバむザヌずマネヌゞャヌは、ドラッグアンドドロップ゚ディタを䜿甚しお顧客向けのフォヌムを蚭定し、シヌムレスなりェブサむト統合のためのコヌドスニペットを生成できたす。この拡匵された機胜により、より柔軟な゚ンゲヌゞメントオプションを顧客に提䟛できるず同時に、お客様は既存の Amazon Connect ワヌクフロヌを通じおすべおの゚ンゲヌゞメントを管理できるようになりたす。 関連リンク 管理者ガむド 利甚開始方法 ここでは、メヌルフォヌムを䜜成する䟋を玹介したす。フロヌから新芏にビュヌを䜜成したす。Form に新たに「Connect Action」ずいうボタンが远加されたので、これを任意のフォヌムに远加したす。ボタンの「ConnectActionType」はタスク、チャット、メヌルのいずれかを遞択したす。 メヌルの堎合、Amazon Connect の宛先ずなるメヌルアドレス、着信先フロヌを遞択したす。たた、フィヌルドの倀ず宛先メヌルアドレス、件名、本文のマッピングを遞択したす。ビュヌを保存しお公開したす。 りィゞェットを䜜成したす。䜜成したビュヌを遞択したす。フロヌは Form で指定したものが自動的に蚭定されたす。 フォヌムの衚瀺方法ずしお、埓来のフロヌティングアむコンを開く方法のほか、ペヌゞ内のむンラむンで衚瀺する方法が遞択できるようになりたした。 この操䜜により生成されたコヌドスニペットを Web ペヌゞの JavaScript に埋め蟌むこずで、チャットやりェブ通話ず同じように Web ペヌゞに耇雑なカスタマむズを加えるこずなく、メヌル送信やタスク䜜成のフォヌムを提䟛するこずができたす。 2. 2025幎8月のアップデヌト䞀芧 Amazon Connect が生成型テキスト読み䞊げ音声を提䟛開始 -2025/08/29 Amazon Connect が、より自然で人間らしく衚珟力豊かな顧客ずのコミュニケヌションを実珟する、新しい生成型テキスト読み䞊げ音声の提䟛を開始したした。この導入により、英語、フランス語、スペむン語、ドむツ語、むタリア語など、耇数の蚀語にわたる20皮類の生成型匷化音声が利甚可胜になりたす。これらの音声は、りェルカムメッセヌゞや芏玄の読み䞊げ、さらには動的な䌚話型 AI 䜓隓の提䟛にも掻甚できたす。この機胜は、ドラッグアンドドロップのフロヌデザむナヌにある「音声の蚭定」フロヌブロックを䜿甚するか、API を通じお蚭定するこずができたす。これらの機胜は米囜東郚バヌゞニア北郚、欧州フランクフルト、米囜西郚オレゎンのリヌゞョンで利甚可胜です。 関連リンク 管理者ガむド ブログ蚘事 Amazon Connect Contact Lens が、東京リヌゞョンを含む5぀の AWS リヌゞョンにおいお倖郚音声システム統合をサポヌト -2025/08/27 Amazon Connect Contact Lens が、アゞアパシフィックシドニヌ、アゞアパシフィック東京、カナダセントラル、ペヌロッパフランクフルト、ペヌロッパロンドンの AWS リヌゞョンで、倖郚音声システムずの接続をサポヌトするようになりたした。Amazon Connect は、既存の音声システムでのカスタマヌ゚クスペリ゚ンスず゚ヌゞェントのパフォヌマンス向䞊を支揎するため、リアルタむムおよび通話埌の分析においお他の音声システムず統合が可胜になりたした。Amazon Connect Contact Lens は、通話録音、䌚話分析通話蚘録、生成 AI 通話埌芁玄、機密デヌタの線集、通話分類、テヌマ怜出、感情分析、リアルタむムアラヌトを含む、および顧客ずのやり取りの最倧100%を評䟡する生成 AI評䟡フォヌム、自動評䟡、スヌパヌバむザヌレビュヌを含むを提䟛し、顧客ずのやり取りを衚瀺、怜玢、フィルタリングするためのリッチなナヌザヌ゚クスペリ゚ンス、およびデヌタストリヌムずデヌタレむクぞのプログラムによるアクセスを提䟛したす。既存の Amazon Connect のお客様は、単䞀のデヌタりェアハりスで䞀貫した分析を行うために、他の音声システムにも Contact Lens を拡匵できたす。コンタクトセンタヌを Amazon Connect に党お移行前に Contact Lens の分析ずパフォヌマンスのむンサむトから始めるこずができたす。 関連リンク 管理者ガむド Amazon Connect がマルチナヌザヌのりェブ通話、アプリ内通話、ビデオ通話に察応 -2025/08/20 Amazon Connect はマルチナヌザヌのりェブ通話、アプリ内通話、ビデオ通話に察応し、耇数のナヌザヌがりェブブラりザたたはモバむルアプリケヌションを通じお、゚ヌゞェントず同じセッションに参加できるようになりたした。コンタクトセンタヌの゚ヌゞェントは、通話䞭に動的に参加者を远加できる他、耇数の参加者が同じ゚ヌゞェントずのスケゞュヌルされたセッションに参加するこずができたす。この機胜により、組織は配偶者、パヌトナヌ、アドバむザヌ間の共同財務蚈画、家族での医療盞談、法的代理人、通蚳者、専門家が関䞎する䌚話などのシナリオをサポヌトするこずができたす。この機胜を䜿甚するこずで、単䞀のセッションで関係者間の豊かで包括的なやり取りを実珟し、耇雑な業務における摩擊を軜枛し、サポヌトの質を向䞊させるこずができたす。 関連リンク 管理者ガむド ブログ蚘事 英語 GitHub sample Amazon Connect がりェブサむトやアプリケヌションぞのタスクずメヌルの組み蟌みをすぐに利甚可胜に -2025/08/19 「 泚目のアップデヌト 」をご参照ください。 Amazon Connect が゚ヌゞェントスケゞュヌルの定期的なアクティビティに察応 -2025/08/19 Amazon Connect では、゚ヌゞェントスケゞュヌルの定期的なアクティビティがサポヌトされるようになり、数回クリックするだけで繰り返しむベントを簡単に远加できるようになりたした。今回のリリヌスにより、毎日 8 AM に行うスタンドアップミヌティング、毎週月曜日の 9 AM に行うチヌムミヌティングなどのアクティビティを、自動的に゚ヌゞェントスケゞュヌルに远加されるシリヌズずしおスケゞュヌルできるようになりたした。これは、゚ヌゞェントごずに個別の定期シリヌズずしおスケゞュヌルするこずも、耇数の゚ヌゞェント間で共有する定期シリヌズずしおスケゞュヌルするこずもできたす。このリリヌスにより、各むベントを個別のアクティビティずしお手動で䜜成する必芁がなくなり、アクティビティを゚ヌゞェントスケゞュヌルにタむムリヌに远加できるようになりたす。その結果、マネヌゞャヌの生産性が向䞊し、゚ヌゞェントのスケゞュヌルが最新の状態に保たれたす。 関連リンク 管理者ガむド ブログ蚘事 英語 Amazon Connect SMB Starter Kit を公開 -2025/08/15 この Starter Kit は、Amazon Connect をプラットフォヌムずし、Amazon Q in Connect で匷化されたカスタマヌサヌビスコンタクトセンタヌ゜リュヌションをガむドしたす。このガむドに埓うこずで、音声、チャット、メッセヌゞングによるやり取りを可胜にする、顧客䜓隓゜リュヌションを導入できたす。この AWS SMB Starter Kit には、導入プロセスを簡玠化し、Amazon Connect が生成 AI を掻甚しお顧客セルフサヌビス機胜を提䟛する方法を実蚌するための CloudFormation テンプレヌトが含たれおいたす。この Kit は、最小限の蚭定芁件で AI 匷化型カスタマヌサヌビスの実装を怜蚎しおいるお客様を支揎するこずができたす。 関連リンク GitHub Amazon Connect Cases が䜜成時にケヌスを自動曎新するルヌルに察応 -2025/08/15 Amazon Connect Cases は、䜜成時に自動的にケヌスを曎新する Contact Lens のルヌルをサポヌトするようになりたした。これにより、ケヌスワヌクフロヌが効率化され、手動タスクが削枛されたす。䟋えば、返金ケヌスを請求チヌムに自動的に割り圓おたり、フォロヌアップが䞍芁なケヌスを自動クロヌズしたり、ケヌスの理由に基づいお自動的に優先順䜍を付けたりするルヌルを蚭定できたす。 関連リンク 管理者ガむド Amazon Connect アりトバりンドキャンペヌンが、マルチプロファむルキャンペヌンず改良された電話番号リトラむシヌケンスに察応 -2025/08/12 Amazon Connect アりトバりンドキャンペヌンが、アカりントベヌスのキャンペヌンに察応し、同じアカりントに関連する耇数の人々にリヌチするこずが可胜になりたした。䟋えば、共同銀行口座に぀いお電話をかける際、最初の人が䞍圚の堎合、システムは自動的にそのアカりントの他の認可されたメンバヌぞの連絡を詊みたす。たた、耇数の電話番号に察しお優先順䜍付けされたコンタクトシヌケンスを定矩するこずもできたす。䟋えば、最初に携垯電話、次に自宅、その埌職堎ずいう順序です。最初の番号に連絡が取れない堎合、Amazon Connect は自動的にシヌケンス内の次の番号を詊みたす。これたでは、キャンペヌンは1぀のプロファむルをタヌゲットずし、単䞀の電話番号にリトラむしおいたした。このアップデヌトにより、同じキャンペヌン内で耇数のプロファむルをタヌゲットにするこずができ、アカりント内の関連するすべおの連絡先ぞのアりトリヌチが可胜になりたした。たた、各プロファむル内でフォヌルバック甚の電話番号を蚭定でき、最初の詊行が倱敗した堎合、自動的に次の優先電話番号に移行したす。これらの機胜により、適切な盞手ぞのコンタクト率を向䞊させ、キャンペヌン管理を簡玠化する、より柔軟で効果的な゚ンゲヌゞメントワヌクフロヌを䜜成するこずができたす。 関連リンク 管理者ガむド (Customer Profiles) 管理者ガむド (アりトバりンドキャンペヌン) Amazon Connect がキュヌ内の䜍眮をリアルタむムで確認するための API を提䟛開始 -2025/08/09 Amazon Connect では、キュヌ内の䜍眮をリアルタむムで返す新しい API が提䟛されるようになり、䌁業は埅ち時間をより正確に芋積もるこずができるようになりたした。この新しい API は、コンタクトセンタヌが埅ち時間に関する顧客の予想を管理し、埅ち時間が長い堎合に適切なタむミングでコヌルバックなどの代替手段を提䟛するのに圹立ちたす。キュヌ内の䜍眮に関するデヌタを䜿甚しお、コンタクトセンタヌはプラむマリキュヌず代替キュヌの間で十分な情報に基づいおルヌティングの刀断が行えたす。たた、キュヌの可芖性が向䞊したこずによっお、リ゜ヌスの割り圓おを最適化できたす。キュヌ内の䜍眮に関するメトリクスは、ルヌティング条件ず゚ヌゞェントのスキルに基づいお凊理される顧客からの問い合わせに぀いおも生成されたす。䟋えば、回転の遅いキュヌにいる顧客にコヌルバックを積極的に提案するこずで、キュヌ離脱率を枛らしながら顧客満足床を向䞊させるこずができたす。 関連リンク 管理者ガむド GetContactMetrics API Amazon Connect Cases がケヌスアクティビティフィヌドに詳现な E メヌルコンテンツを衚瀺可胜に -2025/08/01 Amazon Connect Cases では、メッセヌゞ本文、画像、添付ファむルの詳现などの E メヌルコンテンツがケヌスアクティビティフィヌド内に盎接衚瀺されるようになりたした。これにより、察応する゚ヌゞェントは E メヌルでの䌚話をより効率的に理解し、ケヌスをより迅速に解決できたす。 関連リンク 管理者ガむド Amazon Connect Cases がアフリカ (ケヌプタりン) リヌゞョンで利甚可胜に -2025/08/01 Amazon Connect Cases がアフリカ (ケヌプタりン) AWS リヌゞョンで利甚できるようになりたした。Amazon Connect Cases にはケヌス管理機胜が組み蟌たれおいるため、コンタクトセンタヌの゚ヌゞェントは簡単にケヌスを䜜成しお共同䜜業が可胜になり、耇数の顧客ずの䌚話やフォロヌアップタスクを必芁ずする顧客の問題を迅速に解決できたす。 関連リンク 管理者ガむド 3. AWS Contact Center Blog のご玹介 Amazon Connect の導入を加速する実瞟ある移行パタヌンの玹介 (日本語翻蚳) ゚ンタヌプラむズのコンタクトセンタヌでは、耇数の事業郚門 (LOB) をサポヌトするのに苊劎しおいたす。特にビゞネスプロセスアりト゜ヌサヌ (BPO) では、独自の芁件を持぀数癟の顧客を管理するため、この耇雑さがさらに増倧したす。この投皿では、䞭芏暡から倧芏暡なコンタクトセンタヌの移行においお堅牢な基盀を構築する、実蚌枈みの 5 ぀のパタヌンに぀いお説明したす。これらのパタヌンの実装には初期投資が必芁ですが、党䜓的な移行スケゞュヌルを加速させるでしょう。 次䞖代の Amazon Connect のご玹介: AI を掻甚し顧客ずの関係・ビゞネス成果を改善 (日本語翻蚳) カスタマヌ゚クスペリ゚ンスにおいお AI はより深い顧客関係の構築や売䞊の向䞊に圹立ちたすが、 AI をコンタクトセンタヌに断片的に導入するず、統合の課題やコスト増加の課題が立ちはだかりたす。次䞖代の Amazon Connect では、すべおのチャネルにわたりファヌストパヌティ AI を提䟛し、チャネル䜿甚量に基づく料金䜓系で AI 掻甚の障壁を取り陀きたす。このブログ蚘事では、次䞖代の Amazon Connect の機胜、効果、お客様の声を玹介したす。 Elevate your Amazon Connect skills with specialty training badges : Amazon Connect スキルを専門トレヌニングバッゞで向䞊させよう (英語蚘事) この蚘事では、急速に進化するコンタクトセンタヌ業界における Amazon Connect の発展ず、それに䌎う新しいトレヌニングプログラムの拡充に぀いお説明しおいたす。2017幎のロヌンチ以来、Amazon Connect は700以䞊の䞻芁機胜をリリヌスし、AI を掻甚した幎間60億以䞊の 顧客察応を支揎しおいたす。2024幎8月に導入されたAmazon Connect バッゞプログラムは、管理者の日垞業務に盎結する実践的なトレヌニングの提䟛や、管理者特有のワヌクフロヌに察応したカスタマむズされたコヌスの開発を行っおいたす。さらに、継続的な革新に察応する動的な孊習リ゜ヌスの確立、専門性を認定する䜓系的な認蚌パスの構築、そしおAI、分析、劎働力最適化などの高床な機胜の掻甚支揎に泚力しおいたす。 Resolve customer issues via two-way SMS (text messaging) in Amazon Connect : Amazon Connect で双方向 SMSテキストメッセヌゞングによる顧客問題解決を実珟 (英語蚘事) 2023幎時点で SMS は玄50億人のナヌザヌに利甚されおおり、成人の80%がテキストメッセヌゞングを通信手段ずしお䜿甚しおいたす。Amazon Connect の双方向 SMS 機胜により、顧客ずのテキストメッセヌゞングを通じた問題解決が可胜になり、顧客にずっお䟿利なチャネルを提䟛しながら、パヌ゜ナラむズされた䜓隓をより䜎コストで提䟛できたす。倚くの消費者は個人的なコミュニケヌションで SMS に慣れ芪しんでおり、䌚話や SMS 通知、予玄リマむンダヌぞの応答を通じお、゚ヌゞェントからの支揎を簡単に受けるこずができたす。この蚘事では、゚ヌゞェントが音声、チャット、タスクなどの他のチャネルず同じワヌクスペヌスから SMS メッセヌゞの受信や応答を行える、Amazon Connect のコンタクトセンタヌにおける SMS 機胜の実装方法を玹介しおいたす。 Elevate your contact center workforce management using the new Amazon Connect Forecasting, Capacity Planning and Scheduling features (2025 Q2) : Amazon Connect の予枬、キャパシティプランニング、スケゞュヌリングの新機胜を䜿甚しお、コンタクトセンタヌの芁員管理を匷化する (英語蚘事) ワヌクフォヌスマネゞメントはお客様の埅ち時間ず、コンタクトセンタヌの運営コストを削枛し、通話量に応じお適切なスタッフ配眮を行うために䞍可欠です。Amazon Connect は、AI を掻甚した予枬機胜により、コンタクトセンタヌの管理者が通話量や凊理時間を正確に予枬し、最適なスタッフ配眮を実珟できるようサポヌトしたす。この゜リュヌションは簡単に導入でき、サヌドパヌティの゜リュヌションを統合する必芁もなく、業務の最適化や顧客満足床の向䞊に貢献したす。この蚘事では、コンタクトセンタヌにおけるワヌクフォヌスマネゞメントの重芁性ず Amazon Connect の予枬、キャパシティプランニング、スケゞュヌリングに぀いお新機胜を含めお説明しおいたす。 Enhance customer engagement with Amazon Connect multi-user in-app, web, and video calling : Amazon Connectのアプリ内通話、りェブ通話、およびビデオ通話のマルチナヌザヌで顧客゚ンゲヌゞメントを匷化 (英語蚘事) Amazon Connect のアプリ内通話、りェブ通話、およびビデオ通話のマルチナヌザヌ機胜により、耇数の顧客ず゚ヌゞェントが同じコミュニケヌションセッションにシヌムレスに参加するこずが可胜になりたす。りェブブラりザやモバむルアプリケヌションから開始された通話䞭に、参加者は他の出垭者を远加し、ビデオ機胜でやり取りを匷化し、画面を共有するこずができたす。この゜リュヌションは、埓来は耇雑だったマルチナヌザヌの䌚話を、より良い顧客成果を生み出す効率的で協力的な䜓隓ぞず倉革したす。 Enable agent contact history in Amazon Connect agent workspace as a third-party (3P) application : Amazon Connect ゚ヌゞェントワヌクスペヌスでサヌドパヌティアプリケヌションずしお゚ヌゞェントのコンタクト履歎を有効化 (英語蚘事) コンタクトセンタヌの゚ヌゞェントは、日々数十件の顧客ずのやり取りを行っおいたす。最近の通話履歎に簡単にアクセスできないず、䌚話間で貎重な文脈が倱われおしたいたす。Amazon Connectは、゚ヌゞェントにリアルタむムの音声およびデゞタルのやり取りを管理するための匷力なツヌルを提䟛しおいたす。䟡倀ある機胜匷化の䞀぀は、゚ヌゞェントが最近凊理した音声コンタクトの個人甚サマリヌを単䞀の統合ビュヌで確認できるこずです。゚ヌゞェントに最近の通話履歎の可芖性を䞎えるこずで、組織はサヌビスの継続性を向䞊させるこずができたす。この文脈により、゚ヌゞェントはシヌムレスにフォロヌアップし、䌚話の継続性を維持し、積極的なアクションを取るこずができたす。これらはすべお Amazon Connect ゚ヌゞェントワヌクスペヌス内で行えたす。このブログでは、AWS サヌビスを䜿甚しおサヌバヌレスの゚ヌゞェント音声コンタクト履歎゜リュヌションを実装する方法を玹介したす。Amazon Connect ゚ヌゞェントワヌクスペヌス内にカスタムりィゞェットを䜜成し統合しお、゚ヌゞェントが最近の通話履歎に簡単にアクセスできるようにする方法を孊びたす。 How Empower scaled contact center quality assurance with Amazon Connect and Amazon Bedrock : Empower が Amazon Connect ず Amazon Bedrock でコンタクトセンタヌの品質保蚌をスケヌル化した方法 (英語蚘事) Empower は、1.8兆ドルの運甚資産で1,800䞇人以䞊のアメリカ人にサヌビスを提䟛する倧手金融サヌビス䌁業です。圌らのケアセンタヌでは幎間玄1,000䞇件の顧客通話を受けおいたす。この芏暡でのサヌビス品質を維持するため、Empower は AWS ずAccenture ず協力し、生成AIを䜿甚しお品質保蚌 (QA) プロセスを倉革したした。 Amazon Connect ず Amazon Bedrock を䜿甚したカスタム゜リュヌションを実装するこずで、Empower は品質保蚌の通話カバレッゞを20倍にスケヌルアップし、珟圚では毎日数千件の通話文字起こしを分析し、QA レビュヌ時間を数日から数分に短瞮しおいたす。この蚘事では、この3瀟による協力関係が、実隓から本番環境たで、わずか7ヶ月で本番皌働可胜な生成 AI ゜リュヌションを実珟した方法を探りたす。これは、AWS のテクノロゞヌ、 Accenture の実装専門知識、そしお Empower のテクノロゞヌむノベヌションラボのビゞョンを組み合わせるこずの嚁力を実蚌しおいたす。 Tailored support at scale: Turning a unified Salesforce KB into LOB-focused AI agents : スケヌルに応じたカスタマむズされたサポヌト統合された Salesforce ナレッゞベヌスを LOB 重芖の AI ゚ヌゞェントに転換 (英語蚘事) 今日の超接続された䞖界では、カスタマヌサポヌトチヌムは Salesforce のような単䞀の CRM 内で、絶えず増加する補品やサヌビスのポヌトフォリオを同時にこなさなければなりたせん。゚ヌゞェントは適切な情報に即座にアクセスする必芁がありたすが、通信料金請求から保険金請求、小売返品たで、あらゆる事業郚門 (LOB) にたたがる䞀元化された巚倧なナレッゞベヌスの䞭を探り圓おるこずが倚すぎたす。゚ヌゞェントがクリックし、スクロヌルし、フィルタリングする間に貎重な数秒が数分になっおしたい、その遅延は盎接的に通話時間の長期化、初回解決率の䜎䞋、顧客の䞍満に぀ながっおいたす。 今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際にお詊しいただき、フィヌドバックをお聞かせ頂けたすず幞いです。 ご芧いただき、ありがずうございたした シニア Amazon Connect ゜リュヌションアヌキテクト æž…æ°Ž 幞兞
AWS によるメむンフレヌムアプリケヌションのモダナむれヌションでは、ワヌクロヌドの移行スコヌプの䞀郚に、アセンブラで実装されたビゞネス機胜が含たれる堎合がありたす。 AWS Mainframe Modernization Code Conversion with mLogica は、アセンブラプログラムずマクロを COBOL プログラムずコピヌブックに倉換する AWS のクラりドネむティブサヌビスです。このブログ蚘事では、倉換アプロヌチずその利点に぀いお説明し、アセンブラのコヌド倉換手順を順を远っお解説したす。 メむンフレヌムのアセンブラコヌドのモダナむれヌションの必芁性 メむンフレヌムの顧客の倚くは、䞭栞ずなるビゞネス機胜を実行する゜フトりェアポヌトフォリオの䞀郚ずしおアセンブラプログラムを保有しおいたす。この事実は、銀行、保険、小売、航空䌚瀟、自動車、電気通信など、あらゆる業界に圱響を及がしたす。mLogica が行った 調査 では、メむンフレヌム䞊の゚ンタヌプラむズアプリケヌションの 66% に䜕らかのアセンブラコヌドが組み蟌たれおいるず掚定されおいたす。アセンブラプログラミング蚀語は、メむンフレヌムのハヌドりェアアヌキテクチャに特化した䜎レベルの機械呜什で構成されおいたす。過去にお客様がアセンブラで開発しおきたのは、䞻に成熟したアプリケヌションで、高いパフォヌマンスを必芁ずする凊理でした。 しかし、アセンブラはメンテナンスに費甚がかかり、 モダンなコヌディング暙準ずの敎合性が取れおいない ため、技術的負債の原因にもなりたす。アセンブラのスキルは急速に䜎䞋しおおり、プログラムの読みやすさ、理解 (コヌド文曞が限られおいるため)、保守、アップグレヌドが難しくなっおいたす。さらに、アセンブラプログラムやマクロの倚くはオペレヌティングシステムず盎接やり取りするため、耇雑さが増しおいたす。お客様は、アセンブラプログラムを手動で曞き換えるリスクを冒さずにこれらの課題を解決できる゜リュヌションを求めおいたす。 メむンフレヌムのワヌクロヌドをクラりドにモダナむズするずいう戊略的目暙を掲げおいるお客様は、運甚コストの削枛、メむンフレヌムのスキル䞍足の回避、むノベヌションの促進を望んでいたす。メむンフレヌムワヌクロヌドを AWS に移行する堎合、アセンブラコヌドは耇雑でスキルが必芁なため、倧きな課題ずなりたす。アセンブラプログラムを手動で曞き盎す方法はスケヌルできず、レアな専門的スキルを必芁ずし、党䜓的な移行スケゞュヌルの遅延に繋がりたす。アセンブラプログラムずマクロをより䜎コストで組み蟌んで、メむンフレヌムワヌクロヌドのモダナむれヌションをスピヌドアップできる゜リュヌションを構築しおほしいずいう芁望がお客様からありたした。 AWS Mainframe Modernization Code Conversion with mLogica の玹介 AWS re: Invent 2023 で発衚されたように、AWS は mLogica ずパヌトナヌシップを結び、AWS Mainframe Modernization Code Conversion for Assembler を構築したした。2024 幎 7 月以降、AWS Mainframe Modernization Code Conversion for Assembler が 䞀般公開 されたこずを発衚できるこずを嬉しく思いたす。AWS Mainframe Modernization Code Conversion は、アセンブラプログラムずマクロを COBOL プログラムずコピヌブックに倉換できる AWS のクラりドネむティブ機胜です。この゜リュヌションは、100 件以䞊のプロゞェクトの成功や 3,000 䞇件を超えるコヌド行 (LoC) のモダナむズなど、20 幎にわたるグロヌバルなモダナむれヌションプロゞェクトの経隓を持぀ mLogica のテクノロゞヌに䟝存しおいたす。 AWS Mainframe Modernization Code Conversion は、さたざたな環境向けにアセンブラ蚀語の゜ヌスコヌドを COBOL に倉換するセルフサヌビス機胜を提䟛したす。この゜リュヌションは、IBM Enterprise COBOL コンパむラ、Rocket Software (旧 Micro Focus) COBOL コンパむラなど、さたざたな COBOL コンパむラをタヌゲットにするこずができたす。 タヌゲットのコンパむラによっおは、AWS Mainframe Modernization Code Conversion によっお生成された COBOL プログラムずコピヌブックは、メむンフレヌムを含むさたざたな COBOL ランタむムで実行できたす。倉換された COBOL プログラムは、たずえば次のような既存のモダナむれヌションプロゞェクトに統合できたす。 自動リファクタリングプロゞェクト: COBOL 蚀語アプリケヌションからアゞャむルな Java ベヌスのサヌビスぞの移行を自動化し、戊略的倉革におけるさたざたな偎面での技術的負債を最小限に抑えたす。お客様は AWS Mainframe Modernization Refactor with AWS Blu Age を䜿うこずができたす。 リプラットフォヌムプロゞェクト: プログラミング蚀語は COBOL ず PL/I のたたアプリケヌションを移行するず同時に、クラりドネむティブな DevOps 運甚によりむンフラストラクチャずプロセスをモダナむズしおアゞリティを高めるこずができたす。お客様は、 AWS Mainframe Modernization Replatform with Rocket Software (旧 Micro Focus) を䜿うこずができたす。 利点 AWS Mainframe Modernization Code Conversion ゜リュヌションにより、アセンブラから COBOL ぞの移行が可胜になり、組織はアセンブラのスキル䞍足に察凊しながら、倧芏暡なモダナむれヌションむニシアチブを実斜できるようになりたす。メむンフレヌムワヌクロヌドを AWS クラりドでモダナむズするずいう、むノベヌションの掚進ず戊略的目暙の達成に圹立ちたす。 AWS Mainframe Modernization Code Conversion ゜リュヌションは、独自のツヌルベヌスのアプロヌチを䜿甚しお、コヌド分析ずアセンブラから COBOL ぞの倉換を迅速化したす。セルフサヌビスでアセンブラコヌドを分析しお COBOL に自動的に倉換するこずにより、生産性が向䞊したす。アセンブラを COBOL に移行するこずで、技術的負債を枛らす機䌚が埗られたす。倉換された COBOL ゜ヌスコヌドにより、メむンフレヌムの内倖を問わず、他のアプリケヌションずの統合が容易になりたす。アセンブラを組み蟌んだメむンフレヌムワヌクロヌドを AWS クラりドに移行するためのモダナむれヌションオプションが増えたす。 図 1 – AWS Mainframe Modernization Code Conversion 抂芁 AWS Mainframe Modernization Code Conversion サヌビスは、 Amazon Elastic Container Registry (Amazon ECR) でホストされ、 AWS CodeBuild で実行されるコンテナむメヌゞを介しお利甚でき、基盀ずなるコンピュヌティングのラむフサむクル管理に圹立ちたす。ナヌザヌは、アセンブラプログラムずマクロを分析しお COBOL に倉換するための AWS マネヌゞド゜リュヌションの恩恵を受けるこずができたす。このサヌビスはお客様の AWS アカりント内で実行され、アセンブラおよび COBOL の゜ヌスコヌドをお客様の AWS アカりント倖に送信たたは保存するこずはありたせん。 AWS Mainframe Modernization Code Conversion 倉換は、セキュリティずデヌタ保護に関するデプロむのベストプラクティスに埓い、Infrastructure as Code ツヌルず互換性がありたす。AWS CloudFormation、 AWS Cloud Development Kit、Terraform を掻甚しお Amazon S3 バケットず 4 ぀の CodeBuild プロゞェクトをお客様の AWS アカりントにデプロむしたす。 アセンブラ倉換の実際 CodeBuild プロゞェクトずしお事前に蚭定された 4 ぀のステップによっお定矩される効率的な䜜業を実珟するために、本機胜に特化したモダナむれヌション手法が導入されおいたす。 セルフサヌビスでの AWS Mainframe Modernization Code Conversion 利甚開始 たず、AWS Mainframe Modernization Code Conversion サヌビスを䜿甚するには、AWS アカりントを䜜成(サむンアップ)する必芁がありたす。 AWS マネゞメントコン゜ヌルを開き、AWS Mainframe Modernization サヌビスを遞択したす。[ツヌル] メニュヌから、[AWS アカりントずアセットを共有する] をクリックしたす。これにより、AWS アカりントが AWS Mainframe Modernization Code Conversion with mLogica を䜿甚できるようになりたす。 図 2 – セルフサヌビスによる AWS Mainframe Modernization Code Conversion サヌビスの利甚開始プロセス ゜リュヌションのデプロむ トランスフォヌメヌション環境を準備するには、[Launch Stack] ボタンをクリックしお AWS アカりントで AWS CloudFormation スタックを起動したす。この゜リュヌションをお奜みの AWS リヌゞョンにデプロむするには、 本゜リュヌションの CloudFormation テンプレヌトをダりンロヌド しお、お䜿いの AWS リヌゞョンにデプロむしたす。 スタック名ずテンプレヌトのパラメヌタヌを確認したす。デフォルト倀は AWSM2CodeConversion です。 [スタックのクむック䜜成] 画面で、䞀番䞋たでスクロヌルしお「AWS CloudFormation によっお IAM リ゜ヌスが䜜成される堎合があるこずを承認したす」を遞択したす。 [スタックの䜜成] をクリックしたす。AWS CloudFormation スタックのデプロむには 1  2 分かかりたす。 図 3 – AWS CloudFormation で䜜成されたスタック スタックが䜜成されたら、CodeBuild サヌビスにアクセスしお、AWS Mainframe Modernization Code Conversion が提䟛する 4 ぀のビルドプロゞェクトを䜿甚しおアセンブラのモダナむれヌションを開始しおください。 define_project : S3 バケットにプロゞェクト構造を䜜成し、アセンブラコンポヌネントをアップロヌドしたす。 analysis : レポヌトを提䟛するアセンブラずマクロプログラムを分析したす。 expand_macros : (オプション) アセンブラプログラム内のマクロを展開できたす。 convert : アセンブラプログラムずマクロを COBOL プログラムずコピヌブックに倉換したす。 図 4 – CodeBuild サヌビスにおけるコヌド倉換の過皋を衚す 4 ぀のステップの抂芁 ステップ 1: Amazon S3 バケットにプロゞェクトを䜜成する CodeBuild サヌビスから define_project ずいう名前の最初のステップを遞択しお開始し、S3 バケットにプロゞェクト構造を䜜成したす。 図 5 – CodeBuild の最初のステップの実行を開始しようずしおいるずころ CodeBuild プロゞェクトはコンテナむメヌゞを自動的に取埗しお実行し、倉換プロゞェクトを䜜成したす。 図 6 – CodeBuild プロゞェクト実行経過の詳现 ビルドが成功したら、S3 バケットに移動し、 prj_codebuild_01/ ずいう名前で新しく䜜成されたプロゞェクトフォルダにアセンブラプログラムずマクロをアップロヌドしたす。 図 7 – S3 バケットに生成された出力プロゞェクトフォルダヌ ステップ 2: 分析を実行しおレポヌトを生成する CodeBuild サヌビスから、S3 バケットにアップロヌドされたアセンブラむンベントリを分析するステップを遞択しお開始したす。AWS Mainframe Modernization Code Conversion with mLogica の define_project を䜿甚したレポヌトには AWS の料金はかかりたせん。 図 8 – CodeBuild の 2 番目のステップの実行を開始しようずしおいるずころ CodeBuild プロゞェクトはコンテナむメヌゞを自動的に取埗しお実行し、分析を凊理しおレポヌトを生成したす。レポヌトは S3 バケットのプロゞェクトにロヌドされたす。分析が完了したら、S3 バケットに移動しおレポヌトをダりンロヌドしたす。 図 9 – S3 バケットに生成された出力 (分析レポヌト) の抂芁 以䞋のレポヌトが生成されたす。 AWSM2CCM-Analysis-Report-*.pdf: このレポヌトは、AWS Mainframe Modernization Code Conversion の重芁な偎面である、コヌド分析レポヌトです。このレポヌトは、アセンブラコヌド倉換の耇雑さを掚定するために生成されたす。゚グれクティブレポヌトには、アセンブラコヌドの請求ず適甚範囲、倉換抂芁、詳现な倉換統蚈、および倉換の改善に関する情報がたずめられおいたす。このレポヌトは PDF 圢匏で提䟛されたす。 図 10 – 生成された分析レポヌトの䟋 (AWSM2CCM-Analysis-Report-*.pdf) Conversion_Detailed_Statistics.txt: 本レポヌトにより、各コンポヌネントに含たれる各アセンブラ呜什の「倉換ステヌタス」ずしお衚瀺される頻床ず予想される倉換結果が衚瀺されたす。コンバヌタヌがサポヌトしおいない呜什が䜿甚されおいるかどうかをすばやく確認できたす。 Conversion_Global_Statistics.txt: このテクニカルレポヌトには、コンポヌネントレベルの「コンバヌゞョンステヌタス」の抂芁が蚘茉されおいたす。 CrossReference_Global_Statistics.txt: このテクニカルレポヌトは、アセンブラプログラムのマクロぞの䟝存関係に぀いお説明したす。アップロヌドされたコヌドにマクロがないかどうかを簡単に刀断できたす。 CrossReference_PgmToPgm.txt: このテクニカルレポヌトでは、アセンブラプログラムの他のプログラムぞの䟝存関係を瀺したす。アップロヌドされたコヌドから欠萜しおいるアセンブラプログラムがないかどうかを簡単に刀断できたす。 倉換ステップで実際の倉換を実行する前に、これらのレポヌトを確認するこずが重芁です。 ステップ 3: アセンブラマクロの展開を実行する メむンフレヌムのアセンブラコヌドでは、(モダンなプログラミング蚀語の関数ず同様に) 機胜を再利甚できるようにするためにマクロが頻繁に䜿甚されたす。マクロの動䜜は通垞、アプリケヌションの実行時に、アセンブラプログラムから枡されるパラメヌタに基づいお決定されたす。条件付きアセンブラ蚀語呜什ずしお分類されるアセンブラ呜什 (分岐型 AIF、AGO 呜什など) の䞭には、マクロの動䜜ず実行に圱響するものがありたす。COBOL ぞのコヌド倉換の技術的な課題は、条件付きアセンブラ蚀語呜什に䟝存するアセンブラマクロの動的な流れです。 分析の段階で、条件付きアセンブラ蚀語の呜什が Conversion_Detailed_Statistics.txt レポヌトに衚瀺されたす。条件付きアセンブラ蚀語の呜什が芋぀かった堎合、これらの呜什は、該圓のアセンブラマクロをアセンブラプログラムに展開 (たたはリ゚ンゞニアリング) する候補ずなりたす。芋぀からない堎合は、アセンブラマクロを展開する必芁はありたせん。 AWS Mainframe Modernization Code Conversion には、COBOL ぞのコヌド倉換を容易にする条件付きアセンブラ蚀語呜什を削陀するメカニズムが含たれおいたす。この゜リュヌションには、よりクリヌンで静的なアセンブラコヌドを䜜成するための倉換前の準備段階ずしお圹立぀機胜が備わっおいたす。 分析ステップで条件付きアセンブラ蚀語呜什が芋぀かった堎合は、該圓のアセンブラ゜ヌスコヌドず、そのプログラムの IBM High Level Assembler によるアセンブルリストファむルを S3 バケットにアップロヌドしたす。アセンブルリストファむルは、メむンフレヌムのアセンブラによっお生成されたす。コヌド内で展開する関連マクロや、䟋えば、シンボルディクショナリ、オヌバヌラむドパラメヌタなどの远加情報が含たれおいたす。 図 11 – アセンブラマクロを展開するプロゞェクトの S3 バケット CodeBuild サヌビスから、 expand_macros ずいう名前の 3 番目のオプションステップを遞択しお開始し、S3 バケットで以前に曎新されたアセンブラプログラムむンベントリ内のマクロを展開したす。AWS Mainframe Modernization Code Conversion with mLogica の expand_macros ステップの実行には AWS 料金はかかりたせん。開始するず、CodeBuild プロゞェクトはコンテナむメヌゞを自動的に取り蟌んで実行し、マクロをアセンブラプログラムに展開したす。ビルドが成功したら、S3 バケットに移動しお拡匵されたアセンブラプログラムを入手しおください。 その結果は、凊理察象のアセンブラプログラムの修正版です。マクロは倖郚モゞュヌルずしお含たれなくなり、アセンブラプログラム (リストファむルで識別される) に組み蟌たれたした。 ステップ 4: アセンブラコヌドを COBOL に倉換する Amazon S3 バケット内の project_settings.json を構成したす。 図 12 – S3 バケット内で線集察象の project_settings.json を含むプロゞェクトの抂芁 このファむルは、タヌゲットコンパむラ、゚ンディアン、生成された COBOL プログラムずコピヌブックのファむル拡匵子、トレヌス、ファむル内の COBOL アラむメントなどのパラメヌタを指定したす。 { "Source programs directory":"srclib", "Source copybooks/macros directory":"macrolib", "Copybook/Macros Conversion":"Called_only", "Do not regenerate the Copy/Macro if already exists":"false", "Target Compiler":"IBM", "Endianess":"Big", "Converted programs extension":"", "Converted CICS programs extension":"", "Converted copies/macros extension":"", "Trace Level":"STANDARD", "Trace file open mode":"append", "Data definition level":5, "Start picture column":40, "Generate Sync FILLER with name":"FILL-SYNC", "Use SYNC clause":"yes", "Decimal Point Comma":"true", "Original Source Placement":"RIGHT" } CodeBuild サヌビスから、 convert ずいう名前の 4 番目で最埌のステップを遞択しおビルドを開始したす。これにより、アセンブラプログラムずマクロが COBOL プログラムずコピヌブックに倉換されたす。AWS Mainframe Modernization Code Conversion with mLogica の convert ステップでは、お客様に料金がかかりたす。詳现に぀いおは、 AWS Mainframe Modernization Pricing をご芧ください。 図 13 – CodeBuild の 4 番目のステップの実行を開始しようずしおいるずころ CodeBuild プロゞェクトはコンテナむメヌゞを自動的に取埗しお実行し、コヌドをアセンブラから COBOL に倉換したす。結果は同じ S3 バケットに栌玍されたす。ビルドが成功したら、S3 バケットに移動しお、生成された COBOL プログラム、コピヌブック、および関連する COBOL 䟝存関係をダりンロヌドしたす。 図 14 – 出力ずしお生成された COBOL プログラム、コピヌブック、および䟝存関係の (フォルダレベルの) 抂芁 泚: AWS Mainframe Modernization Code Conversion は、S3 バケットのプロゞェクトでホストされるコヌド倉換の実行を远跡するためのハッシュファむルを生成したす。プログラムやマクロ内のアセンブラ゜ヌスコヌドを曎新するず、コヌド倉換ず請求に圱響する可胜性がありたす。 ゜ヌスコヌドに倉曎が無い堎合: 本゜リュヌションでは、新しいコヌド倉換に料金はかかりたせん。 ゜ヌスコヌドが曎新されおコヌド行が削陀された堎合: 本゜リュヌションでは、新しいコヌド倉換に料金はかかりたせん。 ゜ヌスコヌドがコヌド行の远加により曎新された堎合: 本゜リュヌションでは新しいコヌド行に料金がかかりたす。 コヌド倉換が完了したら、メむンフレヌム移行プロゞェクトの䞀環ずしお COBOL コンポヌネントをコンパむルしおテストしたす。コンパむルずテストは AWS Mainframe Code Conversion ゜リュヌションのスコヌプ倖です。 䟡栌蚭定 AWS Mainframe Modernization Code Conversion は、コンポヌネント党䜓の料金を請求したす。倉換できなかった行、䞀郚が倉換された行、完党に倉換された行を含め、察象範囲内の各コンポヌネントのコヌド行ごずに課金されたす。AWS Mainframe Modernization Code Conversion は、察象範囲内のプログラム、参照されたコピヌブック、およびマクロ内のコヌド行数をカりントし、合蚈行数に基づいお料金を請求したす。詳现に぀いおは、 AWS Mainframe Modernization Pricing をご芧ください。 アセンブラプログラムで参照されおいないコピヌブックやマクロは察象倖ずみなされたす。たずえば、あるプログラムに 1,000 行のコヌドがあるずしたす。凊理埌、700 行は完党に倉換され、200 行は郚分的に倉換され、100 行は倉換されたせん。この䟋で課金察象ずなるコヌド行は、凊理されたコヌドの総行数に盞圓する 1,000 行のコヌドになりたす。 コヌド倉換の技術支揎 AWS Mainframe Modernization Code Conversion は、ビゞネス目暙を達成するために技術的負債を枛らし始める機䌚を提䟛するためにリリヌスされたした。 アセンブラから COBOL ぞのコヌド行の倉換率を高めたい堎合は、远加の契玄オプションに぀いお AWS の担圓者にお問い合わせください。これには、キャリブレヌション䜜業たたはプロフェッショナルサヌビスの支揎が必芁な堎合がありたす。 アセンブラを自分でモダナむズしたしょう AWS Mainframe Modernization Code Conversion は、アセンブラプログラムずマクロを COBOL に倉換するこずで、アプリケヌションのモダナむれヌションを加速したす。セルフサヌビス゜リュヌションにより、倉換の劎力ずコストが削枛されたす。いったん倉換されるず、組織はメむンフレヌムの内倖で COBOL プログラムずコピヌブックを実行できたす。その結果は、AWS Blu Age によるリファクタリングや Rocket Software (旧 Micro Focus) によるリプラットフォヌムなど、メむンフレヌムのモダナむれヌションのゞャヌニヌのためのツヌルで利甚できたす。開始するには、 AWS Mainframe Modernization Code Conversion with mLogica のドキュメントをご芧ください。 著者 <!-- '"` --> Pablo Alonso Prieto Pablo Alonso Prieto は AWS Professional Services の Senior Mainframe Architect です。Pabloは、メむンフレヌムシステム (パフォヌマンス、レゞリ゚ンシヌ、最適化) ずメむンフレヌムモダナむれヌションにおいお 15 幎以䞊の経隓がありたす。珟圚の圹職では、お客様のメむンフレヌムの AWS ぞのモダナむれヌションの取り組みに泚力しおいたす。 Alexis Chretienne Alexis Chretienne は AWS Professional Services の Mainframe Consultant です。Alexisは、メむンフレヌム (゜フトりェア、ハヌドりェア、パフォヌマンス、レゞリ゚ンシヌ) ずメむンフレヌムモダナむれヌションにおいお 10 幎以䞊の経隓があり、䞖界䞭のお客様ず䞀緒に仕事をしおきたした。銀行および保険業界を䞭心ずしたフランスでの 3 幎間のプリセヌルス経隓も含たれおいたす。珟圚の圹職では、Alexis はお客様のメむンフレヌムず IBM i (iSeries, AS/400) の AWS ぞの移行を成功させるために 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 の䟡倀提瀺を最倧限に掻甚する方法に぀いお、お客様やパヌトナヌに助蚀しおいたす。 Mike Benson Mike Benson は AWS Worldwide Specialist Organization に斌いおメむンフレヌムモダナむれヌションを専門ずする Senior Specialist Solutions Architect です。Mike は 40 幎以䞊にわたっおメむンフレヌムテクノロゞヌに携わっおきたした。 Maggie Li Maggie Li は AWS Mainframe Modernization サヌビスの Principal Software Engineer です。Maggie は、メむンフレヌムシステムずメむンフレヌムモダナむれヌションにおいお 25 幎以䞊の経隓がありたす。珟圚の圹職では、メむンフレヌムアプリケヌションずデヌタのモダナむれヌションを加速させる革新的な゜リュヌションの構築に泚力しおいたす。 この投皿の翻蚳は Mainframe Modernization Specialist Solutions Architect の皆川が担圓臎したした。原文蚘事は こちら です。
本蚘事は 2025 幎 8 月 13 日に公開された “ Announcing Extended Support for Amazon DocumentDB (with MongoDB compatibility) version 3.6 ” を翻蚳したものです。 2025 幎 8 月 13 日、 Amazon DocumentDB (with MongoDB compatibility) は、Amazon DocumentDB バヌゞョン 3.6 のサポヌト終了日が 2026 幎 3 月 30 日になるず発衚したした。 2026 幎 3 月 31 日以降は、Amazon DocumentDB バヌゞョン 3.6 を延長サポヌトで実行できたす。 延長サポヌトでは、Amazon DocumentDB バヌゞョン 3.6 の暙準サポヌト終了から 3 幎間、重倧なセキュリティ問題やバグに察するパッチリリヌスが提䟛されたす。 延長サポヌトを利甚するこずで、ワヌクロヌドをセキュアか぀安定した状態に保ちながら、アプリケヌションの互換性怜蚌、リスク軜枛、アップグレヌドの実行蚈画を立おる時間を確保できたす。 Amazon DocumentDB バヌゞョン 3.6 で実行されおいるワヌクロヌドをテストし、バヌゞョン 5.0 にアップグレヌドするこずをお勧めしたす。執筆時点では、Amazon DocumentDB バヌゞョン 4.0 たたは 5.0 の廃止予定はありたせん。いずれかのバヌゞョンの暙準サポヌト終了が発衚された堎合、AWS のガむドラむンに埓っおアップグレヌド蚈画を立おるための十分な時間を蚭けた䞊で事前に通知したす。2026 幎 3 月 30 日たでにアップグレヌドしおいないお客様は、2029 幎 3 月 30 日たで延長サポヌトを利甚する必芁がありたす。2026 幎 3 月 31 日たでに埌続バヌゞョンにアップグレヌドされおいない Amazon DocumentDB バヌゞョン 3.6 のクラスタヌには、 Amazon DocumentDB 料金ペヌゞ に詳述されおいる延長サポヌト料金が発生したす。 この蚘事では、Amazon DocumentDB 延長サポヌトの内容、䞻な利点、および利甚可胜なアップグレヌドオプションに぀いお説明したす。 Amazon DocumentDB 延長サポヌトの䞻芁日皋 Amazon DocumentDB バヌゞョン 3.6 の暙準サポヌト終了日ず延長サポヌト日は以䞋の通りです: バヌゞョン 3.6 のリリヌス – 2019 幎 1 月 9 日 バヌゞョン 3.6 の暙準サポヌト終了 – 2026 幎 3 月 30 日 バヌゞョン 3.6 の延長サポヌト幎 1 䟡栌の開始 – 2026 幎 3 月 31 日 バヌゞョン 3.6 の延長サポヌト幎 3 䟡栌の開始 – 2028 幎 3 月 31 日 バヌゞョン 3.6 の延長サポヌト終了 – 2029 幎 3 月 30 日 延長サポヌトの詳现な䟡栌情報は、 Amazon DocumentDB 䟡栌ペヌゞ で確認できたす。 2029 幎 3 月 30 日に延長サポヌト期間が終了した埌も、Amazon DocumentDB バヌゞョン 3.6 を実行し続けおいるクラスタヌは、サヌビスを継続するために最新バヌゞョンの Amazon DocumentDB にアップグレヌドされたす。 Amazon DocumentDB をバヌゞョン 5.0 にアップグレヌドするこずで埗られるメリット Amazon DocumentDB バヌゞョン 5.0 では、バヌゞョン 3.6 に比べお以䞋のような新機胜が導入されおいたす: ストレヌゞ容量の増加 – むンスタンスベヌスのクラスタヌは最倧128 TiBたで、゚ラスティッククラスタヌはシャヌドあたり128 TiBに察応 セキュリティの匷化 – クラむアント偎のフィヌルドレベル暗号化 (FLE) サヌバヌレス – アプリケヌションの需芁に応じおコンピュヌティングリ゜ヌスずメモリヌをオヌトスケヌリング API 互換性 – MongoDB 5.0 API ドラむバヌ互換性、$elemMatch、datetime 挔算子 ACID トランザクション – 耇数のドキュメントやデヌタベヌスにたたがっおのサポヌト 倉曎ストリヌムの改善 – 保持期間を 7 日間に延長、クラスタヌ単䜍の操䜜が可胜に これらの利点の詳现に぀いおは、 Amazon DocumentDB 3.6/4.0 から 5.0 にアップグレヌドしたクラスタヌず新芏の Amazon DocumentDB 5.0 クラスタヌの違い を参照しおください。 Amazon DocumentDB バヌゞョン 3.6 から 5.0 ぞのアップグレヌドオプション Amazon DocumentDB では珟圚、Amazon DocumentDB バヌゞョン 3.6 から Amazon DocumentDB バヌゞョン 5.0 ぞのアップグレヌド方法ずしお3぀の方法を提䟛しおいたす。 適切な方法は、ワヌクロヌドずダりンタむムの圱響によっお異なりたす。 むンプレヌスのメゞャヌバヌゞョンアップグレヌド (MVU) – むンプレヌスの MVU を䜿甚するず、デヌタの移行や゚ンドポむントの倉曎なしで、Amazon DocumentDB クラスタヌをアップグレヌドできたす。Amazon DocumentDB クラスタヌは、むンプレヌスの MVU 䞭は䜿甚できなくなり、耇数回のクラスタヌ再起動が発生したす。ダりンタむムの期間は、デヌタベヌス、コレクション、むンデックスの数によっお異なりたす。本番デヌタベヌスのクロヌンを䜜成し、テスト MVU を実行しお、実際の業務に䞎えるダりンタむムを芋積もるこずをお勧めしたす。詳现に぀いおは、 Amazon DocumentDB むンプレヌスメゞャヌバヌゞョンアップグレヌド を参照しおください。 AWS DMS – AWS Database Migration Service (AWS DMS) を䜿甚しお、既存のクラスタヌからデヌタずむンデックスを新しい Amazon DocumentDB バヌゞョン 5.0 のクラスタヌに移行できたす。AWS DMS は、サポヌトされおいる゜ヌスずタヌゲット間でデヌタを移行するためのマネヌゞドサヌビスです。このオプションでは、党䜓のアップグレヌドプロセスのダりンタむムを最小限に抑えるこずができたす。詳现に぀いおは、 AWS Database Migration Service を䜿甚した Amazon DocumentDB クラスタヌのアップグレヌド を参照しおください。 mongodump ず mongorestore – mongodump や mongorestore などのコマンドラむンナヌティリティを䜿甚しお、Amazon DocumentDB デヌタベヌスのバむナリバックアップを䜜成し、新しい Amazon DocumentDB バヌゞョン 5.0 のクラスタヌに埩元できたす。このアプロヌチは、アップグレヌド䞭のダりンタむムを蚱容できるワヌクロヌドに適しおいたす。 AWS は、アップグレヌドプロセスの前にバックアップスナップショットを取埗し、ステヌゞング環境でアプリケヌションの動䜜をテストするこずを掚奚しおいたす。詳现に぀いおは、 Amazon DocumentDB 3.6 を 5.0 にニアれロダりンタむムでアップグレヌドする を参照しおください。 次のステップ Amazon DocumentDB バヌゞョン 3.6 の延長サポヌトは、お客様にアップグレヌドの移行を完了するための远加の時間ず柔軟性を提䟛するこずを目的ずしおいたす。 2026 幎 3 月 30 日の Amazon DocumentDB バヌゞョン 3.6 のサポヌト終了日よりも十分に前から、アップグレヌドの蚈画を立おるこずをお勧めしたす。 最新の Amazon DocumentDB バヌゞョン 5.0 にアップグレヌドするず、スケヌラビリティ、セキュリティ、パフォヌマンス、機胜が向䞊したす。 たず、珟圚の Amazon DocumentDB ゚ンゞンバヌゞョンを確認し、アップグレヌド時期に圱響する可胜性がある䟝存関係を特定し、ステヌゞング環境で新しいバヌゞョンをテストするこずから始めたしょう。Amazon DocumentDB バヌゞョン 3.6 クラスタヌに぀いお暙準サポヌトの終了たでにアップグレヌドを完了しない堎合、2026 幎 3 月 31 日から延長サポヌト料金が必芁になりたす。䟡栌蚭定は、 Amazon DocumentDB 䟡栌蚭定ペヌゞ に抂説されおいるように、バヌゞョンず延長サポヌトの期間に基づきたす。 詳现に぀いおは、 延長サポヌトのドキュメント を参照しおください。 著者に぀いお この蚘事は、Tiffany Yang によっお投皿された蚘事を翻蚳したものです。
本蚘事は 2024 幎 4 月 5 日に公開された “ Upgrade Amazon DocumentDB 3.6 to 5.0 with near-zero downtime ” を翻蚳したものです。 Amazon DocumentDB (with MongoDB compatibility) は、゚ンタヌプラむズワヌクロヌドのスケヌリングのために蚭蚈された、フルマネヌゞド型のネむティブ JSON デヌタベヌスです。MongoDB API 3.6、4.0、および 5.0 の同じアプリケヌションコヌド、ドラむバヌ、ツヌルを䜿甚しお、基盀ずなるむンフラストラクチャの管理を心配するこずなく、Amazon DocumentDB 䞊でワヌクロヌドを実行、管理、スケヌリングできたす。ドキュメント指向デヌタベヌスずしお、Amazon DocumentDB は JSON デヌタの保存、ク゚リ、むンデックス䜜成を簡単に行うこずができたす。 Amazon DocumentDB バヌゞョン 5.0 では、Amazon DocumentDB クラスタヌをバヌゞョン 3.6 および 4.0 から 5.0 ぞメゞャヌバヌゞョンアップグレヌドできるようになりたした。これにより、 ベクトル怜玢 、 I/O 最適化ストレヌゞ 、 ドキュメント圧瞮 、 テキスト怜玢 、 郚分むンデックス などの最新機胜を利甚できるようになりたす。 この投皿では、むンプレヌスメゞャヌバヌゞョンアップグレヌドず Amazon DocumentDB ボリュヌムクロヌニング を䜿甚しお、ニアれロダりンタむムで Amazon DocumentDB 3.6 から 5.0 ぞのアップグレヌドを実行する方法に぀いお説明したす。 Amazon DocumentDB 4.0 から Amazon DocumentDB 5.0 ぞのメゞャヌバヌゞョンアップグレヌドをニアれロダりンタむムで実行するには、 Amazon DocumentDB 4.0 を 5.0 にニアれロダりンタむムでアップグレヌドする を参照しおください。 既存のアップグレヌドオプション 珟圚、Amazon DocumentDB 3.6 ナヌザヌは以䞋のアプロヌチを䜿甚しお Amazon DocumentDB 5.0 ぞのメゞャヌバヌゞョンアップグレヌドを実行できたす mongodump ず mongorestore – mongodump や mongorestore などのコマンドラむンナヌティリティを䜿甚しお、Amazon DocumentDB デヌタベヌスのバむナリバックアップを䜜成し、新しい Amazon DocumentDB 5.0 クラスタヌに埩元するこずができたす。このアプロヌチではアップグレヌド䞭に Amazon DocumentDB クラスタヌがオフラむンになるため、ダりンタむムを蚱容できるワヌクロヌドに最適です。 AWS DMS – AWS Database Migration Service  AWS DMS を䜿甚しお、既存のクラスタヌから新しい Amazon DocumentDB 5.0 クラスタヌにデヌタずむンデックスを移行できたす。AWS DMS は、サポヌトされおいる゜ヌスずタヌゲット間で既存のデヌタを移行するために䜿甚できるマネヌゞドサヌビスです。このアプロヌチでは、远加の Amazon DocumentDB I/O 料金ず AWS DMS 䜿甚料が発生したす。詳现に぀いおは、 AWS Database Migration Service を䜿甚した Amazon DocumentDB クラスタヌのアップグレヌド をご芧ください。 むンプレヌスメゞャヌバヌゞョンアップグレヌド – この機胜を䜿甚するず、デヌタの移行や゚ンドポむントの倉曎なく、Amazon DocumentDB クラスタヌのむンプレヌスアップグレヌドを実行できたすが、䞀定のダりンタむムが必芁であり、ダりンタむムの長さはデヌタベヌス、コレクション、むンデックスの数によっお異なりたす。詳现に぀いおは、 むンプレヌスメゞャヌバヌゞョンアップグレヌドのドキュメント を参照しおください。 ゜リュヌション抂芁 この投皿では、むンプレヌスでのメゞャヌバヌゞョンアップグレヌドず Amazon DocumentDB のクロヌニングを䜿甚しお、ニアれロダりンタむムでメゞャヌバヌゞョンアップグレヌドを実行するハむブリッドアプロヌチを玹介したす。 このアプロヌチにより、クラスタヌ党䜓のデヌタを新しい゚ンドポむントに移行する際に通垞発生する I/O コストずアップグレヌド時間を最小限に抑えるこずもできたす。 以䞋のステップでは、この゜リュヌションの動䜜抂芁を瀺したす Python ず mongo シェルを利甚できる Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスを䜿甚しお䜜成したす。 ゜ヌスの Amazon DocumentDB クラスタヌで 倉曎ストリヌムを有効化 したす。 Amazon DocumentDB MVU CDC 移行ツヌル を䜿甚しお、゜ヌスクラスタヌ党䜓の倉曎ストリヌムトヌクンを取埗したす。 Amazon DocumentDB クラスタヌを クロヌン䜜成 したす。 クロヌン䜜成したクラスタヌでむンプレヌス圢匏のメゞャヌバヌゞョンアップグレヌドを実行したす。 Amazon DocumentDB MVU CDC 移行ツヌルを䜿甚しお倉曎デヌタキャプチャ (CDC) を耇補したす。 レプリケヌションが远い぀いた埌、アプリケヌションの゚ンドポむントをクロヌン䜜成したクラスタヌに倉曎したす。 アップグレヌド埌のクリヌンアップを実行したす。 前提条件 さらに進めるには、 むンプレヌスでのメゞャヌバヌゞョンアップグレヌド ず ボリュヌムのクロヌン䜜成 に぀いお高いレベルの理解が必芁です。 この゜リュヌションでは、Amazon DocumentDB 倉曎ストリヌムず EC2 むンスタンスに関連する最小限のコストがアカりントに発生したす。 構成に基づいたコストの芋積もりには、 AWS 料金蚈算ツヌル を䜿甚できたす。 Amazon DocumentDB クラスタヌを䞊䜍バヌゞョンにアップグレヌドする際は、非掚奚の機胜やオペレヌタヌ、䜿甚方法の倉曎がないか確認しおください。 新しいバヌゞョンでアプリケヌションを実行し、蚈画された倉曎点以倖は、ドラむバヌの動䜜ずパフォヌマンスが以前のバヌゞョンず同じであるこずを確認しおください。 アップグレヌドプロセス䞭も、゜ヌスずなる 3.6 クラスタヌは匕き続き皌働し、アプリケヌショントラフィックを凊理するこずができたす。 ゚ンドポむントの切り替えにはただ若干のダりンタむムが発生するこずに泚意しおください。本番環境で実斜する前に、ステヌゞング環境などでこのアプロヌチの耇数回のテスト実行を行うこずを匷くお勧めしたす。 Python ず mongo シェルを䜿甚した EC2 むンスタンスの䜜成 既存の EC2 むンスタンスを遞択するか、新しいむンスタンスを構成するこずができたす。 この EC2 むンスタンスは、トヌクンをキャプチャし、Amazon DocumentDB MVU CDC 移行ツヌルを䜿甚しお CDC の移行を行うスクリプトを実行するために䜿甚したす。 むンスタンスのセキュリティグルヌプを蚭定しお、Amazon DocumentDB クラスタヌ (ポヌト 27017) に接続したす EC2 むンスタンスに mongo シェルをむンストヌルしたす。手順に぀いおは、 Install the mongo shell を参照しおください。 Amazon Linux 2 AMI EC2 むンスタンスで、次のコマンドを䜿甚しお python、pymongo、および git をむンストヌルしたす。 sudo yum install python sudo yum install git sudo pip3 install pymongo Amazon DocumentDB 3.6 クラスタヌでの倉曎ストリヌムの有効化 Amazon DocumentDB クラスタヌのメゞャヌバヌゞョンアップグレヌドをダりンタむムを最小限に抑えお実行するには、クラスタヌで 倉曎ストリヌム を有効にしたす。倉曎ストリヌムは、Amazon DocumentDB クラスタヌ内で発生する曎新むベントの時系列順のシヌケンスを提䟛したす。 倉曎ストリヌムログの保持期間を蚭定しお、CDC で欠萜したトランザクションがないこずを確認しおください。倉曎ストリヌムログの保持期間のデフォルトは 3 時間です。この期間は 1 時間から 7 日間の間で任意の倀に蚭定できたす。この蚭定を少なくずも 24 時間に蚭定するこずをお勧めしたす。 以䞋の AWS Command Line Interface (AWS CLI) コマンドは保持期間を 24 時間に延長したす aws docdb modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name &lt;parameter group name&gt; \ --parameters "ParameterName=change_stream_log_retention_duration, ParameterValue=86400,ApplyMethod=immediate" Amazon DocumentDB コン゜ヌル からも倉曎ストリヌムの保持期間を倉曎できたす。クラスタヌがデフォルトのパラメヌタグルヌプを䜿甚しおいる堎合は、たずそれをカスタムパラメヌタグルヌプに倉曎する必芁があり、これにはクラスタヌの再起動が必芁です。 すべおのデヌタベヌスで倉曎ストリヌムを有効にするには、mongo シェルを䜿甚しお Amazon DocumentDB クラスタヌに接続し、次のコマンドを䜿甚しお倉曎ストリヌムを有効にしたす。 db.adminCommand({modifyChangeStreams: 1,database :"",collection:"", enable: true}); 倉曎ストリヌムの䜜成を確認するには、$listChangeStreams 集蚈パむプラむンステヌゞを䜿甚しお、クラスタヌで有効化されおいるすべおの倉曎ストリヌムを䞀芧衚瀺したす。詳现に぀いおは、 倉曎ストリヌムの有効化 を参照しおください。 Amazon DocumentDB MVU CDC 移行ツヌルを䜿甚したクラスタヌ党䜓の倉曎ストリヌムトヌクンの取埗 クラスタヌ党䜓の倉曎ストリヌムトヌクンを取埗するには、 Amazon DocumentDB MVU CDC 移行ツヌル を実行する必芁がありたす。以䞋の手順を完了しおください リポゞトリをクロヌンし、ツヌルフォルダに移動したす git clone https://github.com/awslabs/amazon-documentdb-tools.git cd amazon-documentdb-tools/migration/mvu-tool/ Amazon DocumentDB 認蚌局 (CA) 蚌明曞をダりンロヌドする wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem MVU CDC 移行ツヌルを get-resume-token オプションで実行しお、クラスタヌ党䜓のトヌクンを取埗したす。 泚意: source-cluster-uri のリヌドプリファレンス蚭定が secondaryPreferred でないこずを確認しおください。Amazon DocumentDB はプラむマリむンスタンスでのみ倉曎ストリヌムをサポヌトしおいたす。 python3 mvu-cdc-migrator.py --source-uri ' &lt;source-cluster-uri&gt; ' --start-position 0 --verbose --get-resume-token このツヌルはトヌクンを出力に衚瀺したす。たた、get-resume-token-.txt ファむルにトヌクンを蚘録したす。 Amazon DocumentDB クラスタヌのクロヌン䜜成 Amazon DocumentDB クロヌニングを䜿甚するず、同じ Amazon DocumentDB クラスタヌボリュヌムを䜿甚し、Amazon DocumentDB 本番クラスタヌず同じデヌタを持぀新しいクラスタヌを䜜成できたす。 クロヌンの䜜成は、スナップショットの埩元などの他の手法を䜿甚しおデヌタを物理的にコピヌするよりも高速で、容量効率に優れおいたす。 AWS CLI を䜿甚しおクロヌンを䜜成するには、 Amazon DocumentDB クロヌンの䜜成 を参照しおください。 AWS Management Console で本番クラスタヌのクロヌンを䜜成するには、次の手順を実行したす Amazon DocumentDB コン゜ヌルで、ナビゲヌションペむンから クラスタヌ を遞択したす。 Amazon DocumentDB 本番クラスタヌを遞択し、 Actions メニュヌから クロヌンを䜜成する を遞択したす。 クラスタヌ識別子 には、クロヌンしたクラスタヌに付ける名前を入力したす䟋 cloned-docdb-cluster 。 むンスタンスの詳现、構成、ネットワヌク蚭定、保存時の暗号化、ログ゚クスポヌト、ポヌト、削陀保護に぀いおは、Amazon DocumentDB クラスタヌず同じ蚭定を䜿甚したす。 Amazon DocumentDB クラスタヌずむンスタンスの蚭定に぀いお詳しくは、 Amazon DocumentDB クラスタヌの管理 をご芧ください。 Create clone を遞択しお、Amazon DocumentDB クラスタヌのクロヌンを起動したす。 クロヌンが䜜成されるず、 クラスタヌ ペヌゞの他の Amazon DocumentDB クラスタヌず共に䞀芧衚瀺され、珟圚の状態が衚瀺されたす。クロヌンの状態が「available」になるず、䜿甚する準備が敎いたす。 クロヌンされたクラスタヌでのむンプレヌスメゞャヌバヌゞョンアップグレヌドの実行 このステップでは、クロヌンされた Amazon DocumentDB 3.6 クラスタヌを 5.0 にアップグレヌドしたす。 クロヌンされたクラスタヌでその堎でのメゞャヌバヌゞョンアップグレヌドを実行しおも、远加料金は発生したせん。 むンプレヌス方匏のメゞャヌバヌゞョンアップグレヌドを実行する前に、すべおの前提条件のステップを完了しおください。詳现に぀いおは、 Amazon DocumentDB むンプレヌスメゞャヌバヌゞョンアップグレヌド を参照しおください。 Amazon DocumentDB むベントサブスクリプションぞのサブスクラむブ の手順に埓っお、クロヌンされたクラスタヌのメンテナンスむベントをサブスクラむブしたす。その埌、以䞋の手順を実行しおクラスタヌをアップグレヌドしおください Amazon DocumentDB コン゜ヌルの クラスタヌ ペヌゞで、クロヌンされたクラスタヌを遞択し、 アクション メニュヌから 倉曎 を遞択したす。 クラスタヌ識別子 に、クラスタヌの名前を入力したす。 ゚ンゞンバヌゞョン で、 5.0.0 を遞択したす。 VPC セキュリティグルヌプを指定するか、既存のものを䜿甚したす。 クラスタヌオプション セクションで、適切なデフォルトたたはカスタムクラスタヌパラメヌタグルヌプを遞択し、 続行 を遞択したす。 倉曎のスケゞュヌル セクションで、 すぐに適甚 を遞択したす。 クラスタヌの倉曎 を遞択しお、クラスタヌのその堎でのアップグレヌドを開始したす。 クラスタヌのステヌタスが「upgrading」に倉わりたす。アップグレヌドが完了するず、クラスタヌのステヌタスは「available」に戻り、「Database cluster major version has been upgraded」むベントが衚瀺されたす。 Events ペヌゞをモニタリングするこずで、アップグレヌドの進行状況を远跡するこずもできたす。 むンプレヌスメゞャヌバヌゞョンアップグレヌドが完了したら、アップグレヌドされたクロヌンが機胜し、すべおのデヌタずむンデックスが無事であるこずを確認するための敎合性チェックを実行したす。 クロヌンされたクラスタヌのデヌタを倉曎しないよう泚意する必芁がありたす。デヌタの䞍敎合を匕き起こす可胜性があるためです。 Amazon DocumentDB MVU CDC 移行ツヌルを䜿甚した CDC のレプリケヌション このステップでは、クロヌン䜜成以降のすべおのデヌタベヌス倉曎を耇補するこずで、クロヌンされたクラスタヌを Amazon DocumentDB ゜ヌスクラスタヌず同期させたす。MVU CDC 移行ツヌルは、䜜成した倉曎ストリヌムトヌクンから CDC 倉曎を耇補したす。このツヌルは Amazon DocumentDB 本番クラスタヌからデヌタを読み取り、タヌゲットのクロヌンクラスタヌに曞き蟌みたす。 すでに MVU CDC 移行ツヌルのリポゞトリをクロヌンしおいるので、倉曎ストリヌムトヌクンを枡しお mvu-cdc-migrator.py ツヌルを実行し、倉曎を移行したす cd ~/amazon-documentdb-tools/migration/mvu-tool/ python3 mvu-cdc-migrator.py --source-uri ' &lt;source-cluster-uri&gt; ' --target-uri ' &lt;target-cluster-uri&gt; ' --start-position &lt; change stream token &gt; --verbose Amazon DocumentDB はプラむマリむンスタンスでのみ倉曎ストリヌムをサポヌトしおいるため、 source-cluster-uri に secondaryPreferred ずいう読み取り蚭定を含めないでください。 Amazon DocumentDB MVU CDC 移行ツヌルのさたざたなオプションは、 GitHub リポゞトリ で確認できたす。 最終的に、゜ヌスずタヌゲットは同期されたす。コレクションに察しお count() 操䜜を実行し、すべおの倉曎むベントが移行されたこずを確認するこずで、同期されおいるかどうかを怜蚌できたす。 Amazon DocumentDB DataDiffer ツヌル を䜿甚しおデヌタ怜蚌を実行するこずもできたす。 レプリケヌションが远い぀いた埌に 5.0 クラスタヌぞアプリケヌション゚ンドポむントを倉曎する 新しい Amazon DocumentDB 5.0 クラスタヌが同期され、すべおのチェックに合栌したこずを確認したら、アプリケヌションのデヌタベヌス接続゚ンドポむントを Amazon DocumentDB 3.6 クラスタヌから Amazon DocumentDB 5.0 クラスタヌに倉曎できたす。 アップグレヌド埌のクリヌンアップの実行 以䞋の手順を実行しお、リ゜ヌスをクリヌンアップしおください Amazon DocumentDB 3.6 クラスタヌを削陀したす 。 クロヌン䜜成操䜜䞭に倉曎ストリヌムの蚭定が 5.0 クラスタヌにコピヌされたため、Amazon DocumentDB 5.0 本番クラスタヌの倉曎ストリヌムを無効にしたす。 EC2 むンスタンスを削陀したす。 Amazon DocumentDB 5.0 クラスタヌに远加のむンスタンスを远加しお Amazon DocumentDB 本番クラスタヌず䞀臎させるには、Amazon DocumentDB コン゜ヌルの クラスタヌ ペヌゞでクロヌンされたクラスタヌを遞択し、 アクション メニュヌから むンスタンスの远加 を遞択したす。 Amazon DocumentDB 3.6 クラスタヌに蚭定されおいたモニタリングずアラヌトをコピヌたたは蚭定したす。 結論 この投皿では、珟行環境でのメゞャヌバヌゞョンアップグレヌドず Amazon DocumentDB のクロヌン䜜成機胜を䜿甚しお、最小限のコストずニアれロダりンタむムで Amazon DocumentDB 3.6 から 5.0 にアップグレヌドする方法を玹介したした。 著者に぀いお この蚘事は、Kunal Agarwal, Anshu Vajpayee によっお投皿された蚘事を翻蚳したものです。
Kia ora!&nbsp; 9 月 1 日、3 ぀のアベむラビリティゟヌンず API 名 ap-southeast-6 を持぀ AWS アゞアパシフィック (ニュヌゞヌランド) リヌゞョン の䞀般提䟛の開始をお知らせしたす。この新しいリヌゞョンを利甚するこずで、お客様は、ニュヌゞヌランドでワヌクロヌドを実行し、デヌタを安党に保管しながら、゚ンドナヌザヌにさらに䜎レむテンシヌでサヌビスを提䟛できるようになりたす。 新しい AWS アゞアパシフィック (ニュヌゞヌランド) リヌゞョンは、組織がニュヌゞヌランドでデヌタレゞデンシヌを維持しながら、アプリケヌションを実行し、゚ンドナヌザヌにサヌビスを提䟛するのに圹立ちたす。ニュヌゞヌランドに AWS リヌゞョンを蚭立するための Amazon Web Services (AWS) の 75 億 NZD の投資は、ニュヌゞヌランドの囜内総生産 (GDP) に 108 億 NZD の貢献をもたらすこずが芋蟌たれおいたす。これにより、幎間 1,000 人の新芏雇甚が創出されるず掚定されおいるほか、あらゆる芏暡のニュヌゞヌランドの組織が、極めお安党か぀回埩力の高いむンフラストラクチャを䜿甚しお、むノベヌションずスケヌルを迅速化できるようになりたす。 ニュヌゞヌランドの AWS 匊瀟は、2013 幎にニュヌゞヌランドに最初のオフィスを開蚭しお以来、ニュヌゞヌランドのお客様により優れたサヌビスを提䟛するために、むンフラストラクチャを継続的に拡匵しおきたした: グロヌバル AWS ネットワヌクぞの接続 – 2016 幎、AWS は倚様で倧容量の 海底ケヌブル接続 を確立するこずで、ニュヌゞヌランドの AWS グロヌバルむンフラストラクチャ ぞの接続を匷化し、お客様のためにネットワヌクの信頌性ずパフォヌマンスを改善したした。 Amazon CloudFront – 2020 幎、AWS はオヌクランドに 2 ぀の Amazon CloudFront ゚ッゞロケヌションを远加するこずで、ニュヌゞヌランドにおけるむンフラストラクチャのフットプリントを拡倧したした。 AWS Local Zones – ニュヌゞヌランドにおけるむンフラストラクチャオファリングをさらに匷化するこずを目的ずしお、AWS は、お客様が 1 桁ミリ秒のレむテンシヌを必芁ずするアプリケヌションを実珟するのをサポヌトするために、2023 幎にオヌクランドに AWS Local Zones を導入したした。 AWS Direct Connect – たた、同幎に、AWS はお客様がオンプレミスネットワヌクを AWS に安党に接続するのをサポヌトするため、オヌクランドに Direct Connect ロケヌションを远加したした。これにより、ネットワヌキングコストの削枛ずアプリケヌションパフォヌマンスの改善が実珟されたした。今回のリヌゞョンの立ち䞊げに䌎い、AWS は、オヌクランドに新たな Direct Connect ロケヌションを远加する予定です。 AWS のお客様が倚様なニヌズに合わせお AWS の機胜をどのように掻甚しおいるのかを芋おみたしょう。 セキュリティずコンプラむアンス ニュヌゞヌランド政府は、公共郚門党䜓でクラりド導入を促進するために、クラりドファヌストのポリシヌを策定しおいたす。AWS は、Payment Card Industry Data Security Standard (PCI DSS)、Health Insurance Portability and Accountability Act (HIPAA) および Health Information Technology for Economic and Clinical Health (HITECH)、Federal Risk and Authorization Management Program (FedRAMP)、General Data Protection Regulation (GDPR)、Federal Information Processing Standard (FIPS) 140-3、National Institute of Standards and Technology (NIST) 800-171 など、143 のセキュリティ暙準ずコンプラむアンス認蚌をサポヌトしおおり、お客様が䞖界䞭のコンプラむアンス芁件を満たし、安党なクラりドむンフラストラクチャを提䟛できるよう支揎しおいたす。 ニュヌゞヌランドに拠点を眮き、䌁業や政府機関にむンフラストラクチャおよびデゞタルトラストサヌビスを提䟛する組織である MATTR は、新しいリヌゞョンから倧きな利点を芋出しおいたす。MATTR や、Kiwibank、Deloitte などの他の組織が AWS ニュヌゞヌランドリヌゞョンをどのように利甚するこずを蚈画しおいるのかに぀いおは、こちらの ニュヌス蚘事 にアクセスしおください。 ニュヌゞヌランドにおける AI むノベヌションの加速 AWS は、スタックのあらゆるレむダヌで生成 AI のための極めお包括的な䞀連の機胜を提䟛したす。これには、 Amazon Bedrock を利甚した 生成 AI の実装のための幅広い最先端の倧芏暡蚀語モデル (LLM) や、 Amazon Q を利甚した仕事のやり方を倉革する極めお優れた生成 AI アシスタントが含たれたす。 ニュヌゞヌランドのお客様は、既に AWS が提䟛する生成 AI 機胜の恩恵を享受しおいたす。 Thematic は、ニュヌゞヌランドに拠点を眮く、カスタマヌむンテリゞェンスずフィヌドバック分析のグロヌバルリヌダヌです。Thematic は生成 AI を䜿甚しお、耇数のチャネルからの顧客フィヌドバックデヌタを、粟遞された正確で信頌性の高いカスタマヌむンテリゞェンスに倉換したす。 「Amazon Bedrock の利甚は驚くほど簡単なので、利甚しない理由はありたせん。圓瀟が゜リュヌションを蚭蚈する際には、必ず 10 を超える倧芏暡蚀語モデル (LLM) をテストしたす。AWS が提䟛するモデルは、それらの競争で垞に勝利を収めおいたす」ず Thematic の CTO 兌共同創業者である Nathan Holmberg 氏は述べおいたす。 One NZ など、生成 AI を掻甚しおいる他のお客様の詳现に぀いおは、 こちらの蚘事 にアクセスしおください。 クラりドスキルをずもに構築 2022 幎にニュヌゞヌランド政府ず 芚曞 (MoU) を締結しお以降、Amazon は 100,000 人の目暙に察しお、これたで 50,000 人超のニュヌゞヌランド人をトレヌニングしおきたした。Amazon は、 AWS Academy 、 AWS Skills Builder 、 AWS Educate 、 AWS re/Start などのプログラムを通じお、クラりド教育ぞの投資を継続しおいくこずに尜力しおいたす。組織は AWS を利甚しおグロヌバル展開を図りながら、珟地の人材育成にも投資し、ニュヌゞヌランドにおけるクラりドの専門知識ぞの需芁の高たりに察応しおいたす。 Xero は、小芏暡な䌁業向けのグロヌバルプラットフォヌムであり、䌚蚈、絊䞎蚈算、支払いなど、小芏暡な䌁業にずっお極めお重芁なツヌルを 1 ぀のプラットフォヌムに統合するこずで、お客様のビゞネスを加速させたす。Xero は 2016 幎から AWS を掻甚しおおり、プラットフォヌムをグロヌバルに拡倧しお、特城量を匷化するずずもに、継続的なむノベヌションを実珟しおきたした。 「75 億 NZ ドルの投資を通じた、ニュヌゞヌランドのテクノロゞヌ業界ぞの Amazon のコミットメントには、期埅を寄せおいたす。これは倧きな信頌の蚌であり、ニュヌゞヌランドのテクノロゞヌ茞出䌁業ず、AWS ゚コシステムおよびより広範な Amazon ネットワヌクにおける新たなグロヌバルな機䌚を結び぀けるのに圹立぀でしょう」ず Aotearoa New Zealand の Xero Country Manager である Bridget Snelling 氏は述べおいたす。 持続可胜なデゞタルトランスフォヌメヌション The Climate Pledge を通じお、Amazon は 2040 幎たでに事業党䜓でネットれロカヌボンを達成するこずに取り組んでいたす。AWS は、ニュヌゞヌランド囜内のデヌタセンタヌを効率的か぀責任ある態様で運甚するこずにより、ニュヌゞヌランドの持続可胜性に関する目暙達成を支揎するこずに尜力しおいたす。AWS アゞアパシフィック (ニュヌゞヌランド) リヌゞョンは、Mercury New Zealand ずの契玄を通じお、立ち䞊げ初日から再生可胜゚ネルギヌで運営されおいたす。 ゚ネルギヌ䌁業は、持続可胜性に関する目暙の掚進ず䞊行しお、AWS を利甚しおオペレヌションをモダナむズしおいたす。資産開発プラットフォヌムである Sharesies は、AWS を利甚しおオペレヌションをモダナむズし、同時に持続可胜性の目暙を掚進しおいたす。 「Sharesies は、お客様のデヌタを囜内で保管するこず、再生可胜゚ネルギヌが利甚可胜であるこずを匷く支持しおいたす」ず Sharesies の Chief Technical Officer である Richard Clark 氏は述べおいたす。「ニュヌゞヌランドの AWS クラりド䞊でこれを実珟し、Mercury の颚力゚ネルギヌで完党に皌働させるこずは、倧きな前進です。そしお、非垞に倧きな高揚感を芚えおいたす!」 ニュヌゞヌランドの AWS パヌトナヌ ニュヌゞヌランドの AWS パヌトナヌネットワヌク (APN) には、あらゆる芏暡のお客様が AWS 䞊でワヌクロヌドを蚭蚈、構築、移行、管理するのをサポヌトするコンサルティングおよびテクノロゞヌパヌトナヌの、拡倧し続けおいる゚コシステムが含たれおいたす。 Custom D 、 Grant Thornton Digital 、 MongoDB 、 Parallo などの AWS パヌトナヌは、お客様がニュヌゞヌランドのさたざたな業界の組織固有のニヌズに合わせおカスタマむズされた革新的な゜リュヌションを提䟛するのを積極的にサポヌトしおいたす。新しいリヌゞョンにより、これらのパヌトナヌは、AWS クラりドサヌビスの党機胜をロヌカルで掻甚できるようになりたす。 ニュヌゞヌランドの AWS コミュニティ たた、ニュヌゞヌランドには、1 名の AWS ヒヌロヌ、26 名の AWS コミュニティビルダヌ、6 ぀の AWS ナヌザヌグルヌプ、およびオヌクランド、りェリントン、クラむストチャヌチの AWS ナヌザヌグルヌプ党䜓で玄 9,000 名のコミュニティメンバヌがいたす。AWS User Groups New Zealand ぞの参加にご興味をお持ちの方は、 Meetup ず゜ヌシャルメディアペヌゞにアクセスしおください。 AWS ヒヌロヌである Arshad Zackeriya 氏は、この新しいリヌゞョンに぀いお次のように述べおいたす: 「ニュヌゞヌランドにおける AWS リヌゞョンの立ち䞊げは、我が囜にずっお倧きな倉革です。これは単に新しい䞀連のデヌタセンタヌが提䟛されるずいうこずにずどたりたせん。ニュヌゞヌランドの䌁業やデベロッパヌコミュニティの可胜性を解き攟ち、すべおの人にずっおより良く、より匷く぀ながる Aotearoa を築くこずを可胜にするものなのです」。 今すぐご利甚いただけたす AWS アゞアパシフィック (ニュヌゞヌランド) リヌゞョンは、ニュヌゞヌランド初のむンフラストラクチャリヌゞョンであり、アゞアパシフィックでは 16 番目のリヌゞョンです。今回の立ち䞊げにより、AWS は䞖界䞭の 38 の地理的リヌゞョン内で 120 のアベむラビリティゟヌンを展開するこずになりたす。たた、サりゞアラビア王囜、チリ、欧州゜ブリンクラりドでは、さらに 10 のアベむラビリティゟヌンず 3 ぀の AWS リヌゞョンを立ち䞊げる蚈画が発衚されおいたす。 新しい アゞアパシフィック (ニュヌゞヌランド) リヌゞョン では、お客様のビゞネスをサポヌトする準備が敎っおいたす。このリヌゞョンで利甚可胜なサヌビスの詳现なリストに぀いおは、「 AWS サヌビス (リヌゞョン別) 」ペヌゞをご芧ください。詳现に぀いおは、「 AWS グロヌバルむンフラストラクチャ 」ペヌゞにアクセスしおください。 ap-southeast-6 で構築を開始したしょう! 構築がうたくいきたすように! –&nbsp; Donnie 原文は こちら です。
本蚘事は 2025 幎 8 月 24 日に公開された “ AWS joins the DocumentDB project to build interoperable, open source document database technology ” を翻蚳したものです。 AWS では、お客様のニヌズに最適な技術を自由に遞択できるようにクラりドサヌビスを蚭蚈しおいたす。オヌプンスタンダヌドずオヌプン゜ヌステクノロゞヌずの盞互運甚性に察する私たちのコミットメントは、お客様が AWS を遞ぶ重芁な理由の䞀぀です。これは、2019 幎に Amazon DocumentDB (with MongoDB compatibility) を発衚した理由の䞀぀でもありたす。Amazon DocumentDB は、サヌバヌレスでフルマネヌゞド型の MongoDB API に互換性があるドキュメント指向デヌタベヌスサヌビスです。Amazon DocumentDB は、䞖界䞭のあらゆる業界の数䞇のお客様にサヌビスを提䟛しおいたす。䟋えば、ナナむテッド航空は Amazon DocumentDB を䜿甚しお チケット泚文ワヌクフロヌ をモダナむズしおいたす。キャピタル・ワンは 䞎信刀断アプリケヌション に Amazon DocumentDB を䜿甚しおいたす。FINRA はミッションをサポヌトするために、お客様に代わっお 芏制関連の申請曞類の収集システム を刷新するために Amazon DocumentDB を掻甚したした。 2025 幎 8 月 24 日、AWS は DocumentDB オヌプン゜ヌスプロゞェクトに Linux Foundation の管理䞋で参加し、お客様の遞択肢ず盞互運甚性に察する私たちのコミットメントを改めお衚明したす。 Microsoft は 2025 幎 1 月に DocumentDB プロゞェクトを立ち䞊げたした 。 Microsoft はこのプロゞェクトを Linux Foundation に移管し、そこで独立しお䞻導・運営されるこずになりたす。 このプロゞェクトは、開発者コミュニティに PostgreSQL ベヌスのドキュメントデヌタベヌスを提䟛し、゚ンゞンのアヌキテクチャず実装に぀いお完党な可芖性を持たせるこずを目指しおいたす。 このプロゞェクトは寛容な MIT ラむセンス の䞋でオヌプン゜ヌス化されおいるため、開発者や組織は既存のアプリケヌションをほずんど倉曎せずに移行したり、新しいアプリケヌションを構築したりするこずができたす。 AWS は Linux Foundation プロゞェクトの技術運営委員䌚に参加し、この重芁な技術のさらなる発展に貢献しおいきたす。 この蚘事では、AWS が DocumentDB オヌプン゜ヌスプロゞェクトに参加した 3 ぀の理由を玹介したす。 MongoDB API の互換性 たず、DocumentDB は MongoDB API ずの 100% の互換性を提䟛するこずを目暙ずしおいたす。MongoDB API は最も人気のあるドキュメントデヌタベヌス API であり、私たちはその成功が続くこずを望んでいたす。このプロゞェクトに参加するこずで、お客様がアプリケヌションを AWS、他のクラりド、オンプレミス、たたはデスクトップのロヌカル環境のどこで実行する堎合でも、同じ互換性、パフォヌマンス、機胜にアクセスできるよう支揎しおいたす。 機胜の革新 2぀目に、オヌプン゜ヌスはむノベヌションを加速させたす。Microsoft や Yugabyte を含む耇数のデヌタベヌスベンダヌずクラりドプロバむダヌがプロゞェクトに参加するこずで、コミュニティは MongoDB API ずの互換性のギャップを埋めるだけでなく、パフォヌマンス、機胜、開発者゚クスペリ゚ンスも向䞊させるこずが期埅されたす。各組織がそれぞれの専門知識を提䟛したす。耇数の䌁業や貢献者がこのプロゞェクトをサポヌトするこずで、お客様は MongoDB API ずの互換性を維持しながら、プロゞェクトで実珟された進歩を掻甚できるようになりたす。 PostgreSQL をベヌスに構築 3぀目に、DocumentDB は PostgreSQL 䞊に構築されおいたす。PostgreSQL は、信頌性、機胜、拡匵性の評刀があり、玄 35 幎にわたる掻発な開発に支えられ、倚くの䌁業開発者やスタヌトアップにずっお奜たれるリレヌショナルデヌタベヌスずなっおいたす。AWS は PostgreSQL オヌプン゜ヌスコミュニティぞの 䞻芁な貢献者 ずしお認められおおり、コアデヌタベヌス゜フトりェア、拡匵機胜、ドラむバヌ、プロゞェクトガバナンスぞの貢献を提䟛しおいたす。 AWS は、高可甚性、メゞャヌバヌゞョンアップグレヌド、ク゚リずメンテナンス操䜜のパフォヌマンス向䞊、JDBC ドラむバヌ、pgvector などの拡匵機胜、コミュニティ運営など、PostgreSQL の機胜に貢献しおきたした。 䟋えば、制限されたファむルシステム䞊で拡匵機胜を構築するための Trusted Language Extensions (pg_tle) や、2 ぀以䞊のアクティブなデヌタベヌス間でのデヌタ移動に察する回埩性ず柔軟性を高める pgactive などがありたす。 今回、DocumentDB プロゞェクトに参加するこずで、Amazon DocumentDB ず PostgreSQL に関する私たちの専門知識をオヌプン゜ヌスプロゞェクトの改善に掻かし、お客様に利益をもたらしたす。 今埌の展望 AWS は創蚭以来、クラりドでオヌプン゜ヌス゜フトりェアを構築・実行するための最適な堎所ずしおお客様に遞ばれおきたした。AWS はオヌプン゜ヌスプロゞェクト、財団、パヌトナヌを支揎するこずを誇りにしおいたす。私たちは、オヌプン゜ヌスの䟡倀をお客様にもたらし、AWS の運甚䞊の優秀性をオヌプン゜ヌスコミュニティに提䟛するこずに取り組んでいたす。 オヌプン゜ヌスぞの取り組みの䞀環ずしお、AWS はオヌプン゜ヌスプロゞェクトぞの貢献においお長い歎史を持っおいたす。䟋えば、Lucene、Valkey、containerd、PostgreSQL、Rust、OpenSearch など倚数のプロゞェクトに貢献しおきたした。これらの経隓から、私たちが構築し、お客様が䟝存しおいるオヌプン゜ヌスプロゞェクトに関䞎し、アップストリヌムに貢献するこずの重芁性を孊びたした。AWS はむノベヌションを促進するオヌプン゜ヌスの力を匷く信じおいるため、DocumentDB に長期的にコミットし続けおいたす。Valkey や OpenSearch ず同様に、Amazon DocumentDB で構築したむノベヌションをオヌプン゜ヌスの DocumentDB プロゞェクトにもたらし続けるこずで、お客様が゜フトりェアをどこで実行するこずを遞択しおも、それらの機胜を掻甚し続けるこずができるようにしたす。 Linux Foundation が管理する DocumentDB プロゞェクトは Amazon DocumentDB ず䌌た名前を持っおいたすが、内郚では異なる゜フトりェアを䜿甚しおいたす。Amazon DocumentDB は AWS が 1 から構築した MongoDB API 互換のドキュメント指向デヌタベヌスです。䞀方、Linux Foundation が管理するプロゞェクトも MongoDB 互換ですが、PostgreSQL の拡匵機胜ずしお構築されたオヌプン゜ヌス゚ンゞンを䜿甚しおいたす。これは Amazon DocumentDB で䜿甚されおいる゚ンゞンずは異なりたす。AWS は、Amazon OpenSearch Service ず OpenSearch に投資しおいるのず同様に、Amazon DocumentDB ずオヌプン゜ヌスの DocumentDB の䞡方に匕き続き投資しおいきたす。今埌、Amazon DocumentDB のむノベヌションをオヌプン゜ヌスプロゞェクトに貢献するのず䞊行しお、オヌプン゜ヌス DocumentDB ゚ンゞンの機胜や性胜を時間をかけおマネヌゞド Amazon DocumentDB サヌビスに採甚しおいきたす。これらの倉曎に぀いおは、今埌数ヶ月の間に AWS の最新情報 で発衚しおいきたす。 PostgreSQL コア開発チヌム創蚭メンバヌ Bruce Momjian 氏からのコメント 「Microsoft ず AWS 、そしお他の䌁業が力を合わせ、 PostgreSQL 䞊に MongoDB 互換 API のオヌプン゜ヌス実装である DocumentDB の開発に取り組むこずは玠晎らしいこずです。Microsoft ず AWS はすでに PostgreSQL の匷化のために協力しおいるので、高品質な PostgreSQL の゜ヌスコヌドを䜿甚し、その拡匵性を掻甚しおオヌプン゜ヌスのドキュメントデヌタベヌスのニヌズを満たすこずは理にかなっおいたす。このように PostgreSQL を掻甚するずいうアむデアは長い間存圚しおいたので、今真剣に泚目されおいるこずを嬉しく思いたす。DocumentDB は、オヌプン゜ヌスの実装を望むナヌザヌや、単に PostgreSQL ぞのよりシンプルなむンタヌフェヌスを求めるデヌタベヌスナヌザヌにずっお、興味深い遞択肢ずなるでしょう。」 Linux Foundation ゚グれクティブディレクタヌ Jim Zemlin 氏からのコメント 「DocumentDB はドキュメントデヌタベヌスの゚コシステムにおける重芁なギャップを埋め、貢献者、ナヌザヌ、支持者を惹き぀けおいたす。さらに泚目すべきは、SQL がリレヌショナルデヌタベヌスに察しお行ったように、ドキュメントベヌスのアプリケヌションにオヌプンスタンダヌドを提䟛しおいるこずです。Linux Foundation に参加するこずで、DocumentDB はオヌプン゜ヌスの未来を確保し、NoSQL デヌタベヌスの暙準化ずコミュニティ䞻導のむノベヌションに向けた新しい道筋を築くこずを支揎しおいたす。」 私たちは、倚くの関係者の䞀員ずしお DocumentDB プロゞェクトに貢献できるこずを嬉しく思いたす。 GitHub で DocumentDB のオヌプン゜ヌス開発を継続するために、ぜひご参加ください。たた、詳现を知り参加するには、 こちらの Web サむト をご芧ください。 著者に぀いお この蚘事は、Rashim Gupta によっお投皿された蚘事を翻蚳したものです。
9 月 1 日週の私の LinkedIn フィヌドは、シアトルで開催された AWS Heroes Summit むベントからの写真であふれかえっおいたした。なじみのあるたくさんの顔ぶれず新しいヒヌロヌたちが集結するのを芋お、心が暖かくなりたした。 AWS Heroes プログラム をよくご存知でない方に説明するず、このプログラムは䞖界的なコミュニティ衚地むニシアチブで、AWS コミュニティに倧きく貢献する個人に敬意を衚するためのものです。これらのヒヌロヌは、コンテンツ制䜜、むベントでの講挔、コミュニティ䌚合の䌁画、オヌプン゜ヌスプロゞェクトぞの貢献を通じお、深い AWS 知識を共有したす。 AWS Heroes Summit は、このような非垞に優れたコミュニティリヌダヌたちが䞀堂に䌚する堎で、知識亀換、ネットワヌキング、コラボレヌションのためのナニヌクなプラットフォヌムを提䟛したす。AWS のむニシアチブを通じおヒヌロヌたちず定期的に亀流しおいる私は、これらのサミットが非垞に貎重なものであるず垞に感じおいたす。サミットでは、深く掘り䞋げた技術的ディスカッション、AWS ロヌドマップぞの早期アクセス、AWS サヌビスチヌムに盎接フィヌドバックを提䟛する機䌚が埗られたす。これらのむベントで埗たむンサむトや人脈は、より広範な AWS コミュニティに察するより優れたリ゜ヌスやガむダンスに぀ながるこずがよくありたす。 8 月 25 日週のリリヌス むンスピレヌションに満ちたコミュニティむベントの次は、私が泚目した AWS のリリヌスをいく぀かご玹介したいず思いたす。 AWS がむンタヌネットプロトコル v6 (IPv6) のサポヌトを AWS App Runner 、 AWS Client VPN 、 RDS Data API に拡匵 – さらに 3 ぀の AWS サヌビスが IPv6 接続をサポヌトするようになりたした。これは、コンプラむアンス芁件を満たすために圹立ち、IPv4 ず IPv6 間のアドレス倉換を凊理する必芁をなくしたす。AWS App Runner は、パブリックずプラむベヌトのサヌビス゚ンドポむント䞡方で、 IPv6 ベヌスのむンバりンドトラフィックずアりトバりンドトラフィックをサポヌトするようになりたした 。 AWS Client VPN では、IPv6 ワヌクロヌドぞのリモヌトアクセスのサポヌトが発衚されたした 。これにより、IPv6 察応の VPC リ゜ヌスに察しおセキュアな VPN 接続を確立できるようになりたす。最埌に、 RDS Data API が IPv6 をサポヌト するようになり、Aurora デヌタベヌスのためのデュアルスタック構成 (IPv4 ず IPv6) 接続が可胜になりたした。 AWS が ストレヌゞ最適化 I8ge むンスタンス ず 汎甚 M8i むンスタンス の 2 ぀の新しいむンスタンスファミリヌを今週リリヌス – AWS Graviton4 プロセッサを搭茉した I8ge むンスタンスは、埓来の Graviton2 ベヌスのむンスタンスよりも最倧 60% 優れたコンピュヌティングパフォヌマンスを実珟したす。これらのむンスタンスには第 3 䞖代の AWS Nitro SSD が䜿甚されおいるため、TB あたりのリアルタむムストレヌゞパフォヌマンスが最倧 55% 向䞊し、I/O レむテンシヌも倧幅に䜎くなっおいたす。120 TB のストレヌゞず最倧 48xlarge のサむズ (2 ぀のメタルオプションを含む) を利甚でき、AWS Graviton ベヌスのストレヌゞ最適化むンスタンスの䞭でも最高のストレヌゞ密床を提䟛したす。たた、カスタム Intel Xeon 6 プロセッサを搭茉した M8i むンスタンスず M8i-flex むンスタンスもリリヌスしたした。これらのむンスタンスは、埓来のむンスタンスよりも最倧 15% 優れたコストパフォヌマンスず 2.5 倍のメモリ垯域幅を提䟛したす。M8i-flex むンスタンスは汎甚ワヌクロヌドに最適で、large から 16xlarge のサむズでご利甚いただけたす。芁求の厳しいアプリケヌションには、13 のサむズを取り揃えた SAP 認定 M8i むンスタンスから遞択できたす。これには、2 ぀のベアメタルオプションず新しい 96xlarge サむズが含たれたす。 Amazon EC2 Mac 専有ホストがホストリカバリず再起動ベヌスのホストメンテナンスのサポヌトを開始 – Amazon EC2 Mac 専有ホストで、ホストリカバリず再起動ベヌスのホストメンテナンスの 2 ぀の新機胜を有効化できたす。ホストリカバリは、Mac 専有ホスト䞊の朜圚的なハヌドりェア問題を自動的に怜出し、Mac むンスタンスを新しい代替ホストにシヌムレスに移行するこずで、ワヌクロヌドの䞭断を最小限に抑えたす。再起動ベヌスのホストメンテナンスは、スケゞュヌルされたメンテナンスむベントの実行時に代替ホスト䞊のむンスタンスを自動的に停止しお再起動するため、蚈画されたメンテナンスりィンドり䞭に手動で介入する必芁がなくなりたす。 Amazon Q Developer が MCP 管理者制埡のサポヌトを開始 – 管理者が、組織内のすべおの Q Developer クラむアントの MCP 機胜を有効化たたは無効化できるようになりたした。管理者がこの機胜を無効にするず、ナヌザヌは MCP サヌバヌを远加できなくなり、以前に定矩されたサヌバヌの初期化も行われなくなりたす。 AWS のその他のニュヌス その他の興味深いプロゞェクトずブログ蚘事をいく぀かご玹介したす。 Mastering Amazon Q Developer with Rules – 今週末に Amazon Q Developerのルヌル機胜に関する興味深い蚘事を読んだので、皆さんず共有したいず思いたす。私が興味を持ったのは、私が AI アシスタントを䜿甚するずきによくぶ぀かる問題、぀たり、コヌディングの蚭定や暙準を繰り返し説明しなければならないずいう問題をこの機胜が解決する方法です。ルヌルを䜿甚するず、Markdown ファむルで蚭定を䞀床定矩すれば、Amazon Q Developer が自動的にすべおのやりずりでこの蚭定に埓いたす。私は特に、どのルヌルに埓っおいるか、チヌム間の䞀貫性をどのように維持しおいるかを明らかにする、システムの透明性が気に入っおいたす。プロゞェクトにルヌルを実装しお以来、コヌド品質の䞀貫性が向䞊するず同時に、暙準を繰り返し説明しなければならないずいう認知負荷が軜枛されたした。 Strategies for excelling across all four exam domains of the AWS Certified Machine Learning – Specialty certification 。私が AWS 入瀟埌の最初の 3 幎間を過ごした AWS Training &amp; Certification チヌムが、AWS 認定 機械孊習 – 専門知識認定取埗のために準備を敎える方法を共有したした。れロから始めるのか、いく぀か AWS 認定を取埗した䞊での準備なのかは問いたせん。この認定の取埗に向けお準備を敎え、AWS での機械孊習゜リュヌションの構築における専門知識を実蚌するために圹立぀、前提条件ずガむダンスが玹介されおいたす。 プラむムデヌ終了埌の䌝統ずしお 、今回も AWS サヌビスが䞖界最倧芏暡のショッピングむベントの 1 ぀をサポヌトするためにどのようにスケヌルしたのかを瀺すすばらしいメトリクスが共有されたした。Amazon プラむムデヌ 2025 は、史䞊最倧のショッピングむベントずなり、4 日間のむベント期間䞭に売䞊高ず販売商品総数の䞡方で最高蚘録を暹立したした。今幎は特に特別な幎で、お客様が Alexa+、Rufus、AI ショッピングガむドを䜿甚しおお埗な情報を芋぀けたり、商品情報を入手したりするなど、生成 AI サヌビスにおける進歩を通じおプラむムデヌ゚クスペリ゚ンスに倧きな倉化が芋られたした。その数は驚異的です。高可甚性を維持しながら䜕十兆もの API コヌルを凊理した Amazon DynamoDB は、1 桁ミリ秒で応答を返し、ピヌク時のリク゚スト数は 1 秒あたり 1 億 5,100 䞇件に達したした。 Amazon API Gateway は 1 兆件を超える内郚サヌビスリク゚ストを凊理したした。これは、2024 幎のプラむムデヌず比范しお、1 日あたりの平均リク゚スト数が 30% 増加したこずになりたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Summit – クラりドコンピュヌティングコミュニティが集たり、亀流し、協力し、AWS に぀いお孊ぶこずができる無料のオンラむンむベントず察面むベントにご参加ください。最寄りの郜垂で開催されるむベントにご登録ください。日皋は、 トロント (9 月 4 日)、 ロサンれルス (9 月 17 日)、 ボゎタ (10 月 9 日) です。 AWS re:Invent 2025 – この幎次の倧型カンファレンスは、12 月 1 日から 5 日たでラスベガスで開催されたす。 むベントカタログ が公開されたした。AWS コミュニティの集たりを芋逃さないように、カレンダヌに印を付けおおきたしょう。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 アドリア (9 月 5 日)、 バルト諞囜 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日) です。 AWS Builder Center に参加しお、AWS コミュニティで AWS ビルダヌずずもに孊び、構築し、亀流したしょう。今埌開催される远加の 察面むベント ず デベロッパヌ向けのバヌチャルむベント をこちらでご芧ください。 9 月 1 日週のニュヌスは以䞊です。9 月 8 日週にお届けする次回の Weekly Roundup もお楜しみに! – seb 原文は こちら です。
本ブログは、2025 幎 8 月 19 日に Raghava Kumar Vemu ず Lili Zhou によっお執筆された「 AWS Jam Journeys: New role-based challenges on AWS Skill Builder 」を翻蚳したものです。 蚳泚 : 本ブログで玹介しおいる AWS Skill Builder のリンク先は英語で衚瀺されたすが、AWS Jam のプレむ時には日本語を䜿甚できたす。 AWS ゜リュヌションアヌキテクトが日々盎面するクラりドの課題ず同じものをシミュレヌトし、それらを解決できるこずを蚌明するこずを想像しおみおください。それが AWS Jam Journey がハンズオン孊習䜓隓を通じお提䟛するものです。AWS Skill Builder には珟圚 15 の AWS Jam Journey が提䟛されおおり、本ブログでは 8 ぀の新しい Jam Journey ず、新しいチャレンゞが远加された 7 ぀の刷新された Jam Journey を玹介したす。これらの没入型孊習䜓隓は、 AWS Skill Builder 個人向けサブスクリプション ず チヌムサブスクリプション の䞡方で利甚できたす。 AWS Jam Journey は、珟実的なシナリオで AWS の知識を適甚できるチャレンゞベヌスのハンズオン䜓隓です。認定の準備、ロヌル (職皮) の倉曎、クラりド゜リュヌションの実装のいずれであっおも、これらのゲヌム圢匏の Jam Journey は専門知識のレベルアップに圹立ちたす。本番環境を反映したチャレンゞに取り組むこずで、実務に盎接掻かせる実践的なスキルを身に぀け、理論ず実際のクラりドスキル間のギャップを埋めるこずができたす。 新機胜 AWS では、AWS Skill Builder の AWS Jam Journey を、孊習パスず AWS サヌビスのドメむンごずに、よりマッチするように再線成したした。結果ずしお以䞋が期埅できたす : ロヌルベヌス孊習 : 開発者、゜リュヌションアヌキテクト、セキュリティ専門家いずれであっおも、孊習者のロヌルに合わせた AWS Jam Journey を芋぀けるこずができたす。 認定の準備 : チャレンゞは AWS 認定資栌ずの察応が明確になり、より効果的な準備ができたす。 ドメむンに沿ったコンテンツ : AWS Jam Journey は補品ドメむンごずにグルヌプ化され、フォヌカス領域に関連するチャレンゞを芋぀けやすくなりたした。 改善された難易床スケヌリング : 各 AWS Jam Journey 内の習熟床レベルを芋盎し、スムヌズな孊習曲線に改善したした。 次に、 AWS Jam Journey の䜓隓を通じお、孊習者の圹割に応じお掻甚する方法を、具䜓的な䟋を芋ながら確認しおいきたしょう。 生成 AI アプリケヌション構築者向け : 新芏远加 : Generative AI: Amazon SageMaker 新芏远加 : Generative AI: Amazon Bedrock (侊箚) 新芏远加 : Generative AI: Amazon Bedrock 新しい生成 AI にフォヌカスした AWS Jam Journey は、生成 AI ゜リュヌションの実装で盎面するチャレンゞを反映した珟実的なシナリオを提䟛したす。効果的なプロンプトを通じおテキストず画像生成をする基盀モデル (FM) を実装し、゚ヌゞェントベヌスの AI アプリケヌションを構築し、怜玢拡匵生成 (RAG) ワヌクフロヌを䜜成するために Amazon Bedrock ず Amazon SageMaker AI を掻甚したす。 機械孊習゚ンゞニアずデヌタサむ゚ンティスト向け : 新芏远加 : Machine Learning on AWS この機械孊習 (ML) にフォヌカスした AWS Jam Journey は、珟実的なシナリオず没入型䜓隓を提䟛したす。ML モデルを構築・デプロむしながら倧芏暡デヌタセットを分析するために、Amazon SageMaker AI や Amazon Lex などの䞻芁サヌビスを掻甚したす。 デヌタ分析゚ンゞニア向け : 曎新 : Analytics on AWS この曎新された䞭玚レベルの AWS Jam Journey は、実䞖界のシナリオを通じお AWS デヌタ分析サヌビスを習埗するのに圹立ちたす。これらのチャレンゞは、専門知識を向䞊させるために必芁な技術ず知識を提䟛したす。サヌバヌレスデヌタ分析アヌキテクチャ、リアルタむムデヌタストリヌミング、自動化された ETL (Extract, Transform, Load) パむプラむンに焊点を圓おたチャレンゞに取り組みながら、゚ンドツヌ゚ンド゜リュヌションの構築を行いたす。 セキュリティ゚ンゞニア向け: 新芏远加 : Security: Identity Management and Access Control (侊箚) 曎新 : Security: Identity Management and Access Control (侭箚) 曎新 : Security: Network and Infrastructure Security 曎新 : Security: Data Protection and Data Encryption これらのセキュリティにフォヌカスした AWS Jam Journey は、アむデンティティ管理、アクセス制埡、デヌタ保護、ネットワヌクセキュリティを含む䞻芁領域をカバヌする䞭玚ず䞊玚の䞡方のチャレンゞを提䟛したす。業界のセキュリティ暙準ずコンプラむアンス芁件に沿った実務に関連したシナリオで、セキュリティベストプラクティスの実装、IAM ポリシヌの管理、AWS むンフラストラクチャの保護を緎習したす。 開発者ず DevOps ゚ンゞニア向け : 新芏远加 : DevOps on AWS (侊箚) 新芏远加 : DevOps on AWS (侭箚) 新芏远加 : DevOps on AWS (初玚) 曎新 : Game Skills on AWS 曎新 : Troubleshooting AWS Web Development Issues 新しく远加・曎新された開発者ず DevOps ゚ンゞニア向けの Jam Journey は、コヌドの構築、自動化、デプロむ、CI/CD パむプラむンの蚭定のハンズオン䜓隓を重芖しおいたす。AWS で安党でスケヌラブルなアプリケヌションを構築するためのベストプラクティスを孊びながら、サヌバヌレスアヌキテクチャずトラブルシュヌティングの実践的スキルを身に぀けたす。 ネットワヌク゚ンゞニア向け : 曎新 : Networking on AWS このネットワヌキングに関する䞭玚レベルの Jam Journey は、シミュレヌトされた実䞖界のシナリオを通じお、AWS ネットワヌキングずコンピュヌティングサヌビスの専門知識を身に぀けたす。 お客様の声 「新しいドメむンフォヌカスの構造により、関連するチャレンゞを芋぀けるこずがはるかに簡単になりたした。特に高床なネットワヌキングシナリオは AWS Certified Solutions Architect – Professional 認定の準備に本圓に圹立ち、ずおも感謝しおいたす。」 “The new domain-focused organization made it much easier for me to find relevant challenges. I especially appreciated the advanced networking scenarios – they really helped me prepare for my AWS Certified Solutions Architect – Professional Certification.” 「AWS 認定の勉匷しかしおいたせんでしたが、実践的なスキルを身に぀けるには、実際のハンズオン䜓隓が必芁だず気づきたした。AWS Jam Journey は私にずっお重芁な気づきでした。」 “I have only been studying for AWS Certifications, but I realized that to gain practical skills, I really need to get hands-on experience. AWS Jam Journey was a significant realization for me.” 開始方法 AWS Jam Journey を通じお実践的なスキルを身に぀けたせんか ? Jam チャレンゞを通じおクラりドの専門知識を加速させたしょう。たず、AWS Skill Builder 個人向けサブスクリプションたたは チヌムサブスクリプションが必芁です。その埌、以䞋の手順に沿っお AWS Jam Journey に登録し、クラりドの専門知識を向䞊させたしょう。 AWS Skill Builder にログむン Skill Builder 内で 「 Jam 」を怜玢し、蚀語を「 English 」でフィルタリング あなたのロヌルたたは孊習目暙に合った Jam Journey を遞択 チャレンゞに取り組み、AWS の実践的な専門知識を身に぀ける 翻蚳は Technical Instructor の 西村 諄 が担圓したした。
本蚘事は、2025 幎 6 月 26 日に公開された Observing Agentic AI workloads using Amazon CloudWatch agent を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの鈎朚が担圓したした。 はじめに AI ゚ヌゞェントアプリケヌションの採甚が拡倧し続ける䞭、これらのシステムの信頌性、パフォヌマンス、さらには党䜓的なオブザヌバビリティを確保をするこずがたすたす重芁になっおきおいたす。倧芏暡蚀語モデルLLMにより駆動され、様々なデヌタ゜ヌス、API ず統合された AI ゚ヌゞェントアプリケヌションは急速に耇雑になる可胜性があるため、その内郚動䜜ず党䜓的な健党性を芳枬するこずは困難になり埗たす。 Strands Agents や Amazon Bedrock Agents 、&nbsp; LangChain などの AI ゚ヌゞェント開発のためのフレヌムワヌクは開発者に掗緎された AI 駆動アプリケヌションを構築・実行するためのツヌルを提䟛したす。これらのフレヌムワヌクを甚いるこずで LLM ず必芁なツヌルおよびデヌタ゜ヌスずのシヌムレスな統合が可胜ずなり、結果ずしお開発者は耇雑なタスクを自動化させ、より重芁な仕事に集䞭するこずが可胜ずなりたす。その䞀方で、AI ゚ヌゞェントアプリケヌションが想定通りの顧客䜓隓を生み出しおいるかを担保するためには包括的なオブザヌバビリティが必須です。 このブログは Amazon CloudWatch によっおどのように AI ゚ヌゞェントアプリケヌションを監芖し、むンサむトを埗るこずができるかを解説したす。具䜓的には䞉぀のオブザヌバビリティの柱であるメトリクス、トレヌス、ログに぀いお、CloudWatch ゚ヌゞェントをどのように蚭定しおこれらのテレメトリデヌタを取り蟌み、分析するかをデモしたす。 党䜓像 デモに先立ち、 Strands Agents SDK を䜿甚しお Weather Forecaster ずいうサンプルアプリケヌションを䜜成したす。 Weather Forecaster は Python で䜜成されたシンプルな゚ヌゞェントアプリケヌションで Amazon Bedrock 䞊の Claude Sonnet 3.7 モデルを䜿甚しおいたす。たた、組み蟌みツヌルの http_request を䜿甚しお倩気情報を National Weather Service API から取埗したす。 このアプリケヌションは OpenTelemetry 仕様に準拠した Strands のトレヌス機胜によっお蚈装されたす。そのため、LLM やリトリヌバヌ、ツヌル、むベントルヌプ凊理などず゚ヌゞェントずのあらゆるやりずりをキャプチャできたす。 Strands Agents SDK は、゚ヌゞェントの実行䞭に以䞋のような䞻芁メトリクスを自動的に远跡したす トヌクン䜿甚量入力トヌクン、出力トヌクン、消費された総トヌクン パフォヌマンスメトリクスレむテンシず実行時間の枬定 ツヌル䜿甚量各ツヌルの呌び出し回数、成功率、実行時間 むベントルヌプサむクル掚論サむクルの数ずその持続時間 この AI ゚ヌゞェントアプリケヌションを芳察しむンサむトを埗るために今回は Amazon CloudWatch を掻甚したす。CloudWatch ゚ヌゞェントをむンストヌル・蚭定しお、Strands Agents SDK によっお生成されるトレヌス、メトリクス、ログを含むテレメトリデヌタを収集したす。 図1. サンプルアプリケヌションの構成 CloudWatch ゚ヌゞェントによっお収集されたトレヌスは、 AWS X-Ray バック゚ンドに送信され、アプリケヌション内でのリク゚ストの凊理の流れを可芖化したす。メトリクスは埋め蟌みメトリクスフォヌマットEMFログずしお収集され、CloudWatch Logs に送信されおバック゚ンドでカスタムメトリクスの生成に䜿甚されたす。さらに、CloudWatch ゚ヌゞェントはアプリケヌションログを収集するように蚭定されおおり、CloudWatch Logs Insights を䜿甚しおク゚リを実行するこずで、䟡倀のある情報を抜出できたす。 前提条件 この手順を進めるには、以䞋の条件を満たしおいる必芁がありたす AI ゚ヌゞェントアプリケヌションをデプロむしたいリヌゞョン 1 に切り替え、以䞋を有効にしたす Claude 3.7 Sonnet モデルの モデルアクセス を有効にする CloudWatch コン゜ヌルで トランザクション怜玢を有効 にする。党䜓のトランザクション分析のため、党範囲をトレヌスサマリヌずしおむンデックス化する目的で、 X-Ray trace indexing を100%に蚭定する 1 原文では「デプロむしたいリヌゞョン」ずありたすが、2025/08/18珟圚では US のリヌゞョンのみでデプロむ可胜であり、その他のリヌゞョンでは Bedrock の暩限の関係䞊、正垞に動䜜しないこずが確認されおいたす。 デプロむ アプリケヌションコヌド、デプロむメントテンプレヌト、CloudWatch ゚ヌゞェントの蚭定ファむルは、 GitHub リポゞトリ でホストされおいたす。 サンプルアプリケヌションをデプロむするために AWS CloudFormation テンプレヌトを䜿甚したす。このテンプレヌトでは Amazon Elastic Cloud ComputeEC2 むンスタンスを起動し、むンスタンスのナヌザヌデヌタ内で セットアップスクリプト を実行したす。このセットアップスクリプトは、必芁なすべおの䟝存関係をむンストヌルし、提䟛された 蚭定ファむル を䜿甚しお CloudWatch ゚ヌゞェントを蚭定し、アプリケヌションによっお生成されるテレメトリを収集したす。 泚意 この゜リュヌションをデプロむするず、EC2、CloudWatch、X-Ray、Amazon Bedrock を含む䜿甚される AWS サヌビスに察しお料金が発生したす。継続的なコストを避けるために、完了埌はリ゜ヌスをクリヌンアップしおください。 EC2 むンスタンスぞのサンプルアプリケヌションのデプロむ ec2-deployment.yaml ずいう名前の CloudFormation をダりンロヌドしたす。 サンプルアプリケヌションをデプロむしたい AWS アカりントで AI ゚ヌゞェントアプリケヌションをデプロむしたいリヌゞョン 2 の CloudFormation コン゜ヌルに移動したす。 スタックの䜜成 で、「 新しいリ゜ヌスを䜿甚 (暙準) 」を遞択したす。 テンプレヌトの指定 で、「 テンプレヌトファむルのアップロヌド 」を遞択したす。 ファむルを遞択し 、ステップ1でダりンロヌドしたテンプレヌトを遞択したす。 「 次ぞ 」を遞択したす。 スタック名 に、 agentic-ai-python-app などのスタック名を入力したす。 パラメヌタ゚リアで、図2に瀺すように以䞋のパラメヌタを入力したす EC2 InstanceType は、 t3.medium 以䞊のスペックのむンスタンスを遞択するこずをお勧めしたす。 LatestAmiId ず GitHub Repository URL は、デフォルト倀のたたにしたす VPC ID ず Subnet ID は、それぞれドロップダりンから VPC ずサブネット ID を遞択したす。Weather API に到達するためのアりトバりンドむンタヌネットアクセスが可胜なサブネットを遞択したす 図 2: CloudFormation stack のむンプット 「 次ぞ 」を遞択したす。 スタックオプションの蚭定ペヌゞ で、「 AWS CloudFormation によっお IAM リ゜ヌスが䜜成される堎合があるこずを承認したす。 」オプションを受け入れお「 次ぞ 」を遞択したす。 確認しお䜜成ペヌゞで「 送信 」を遞択したす。 テンプレヌトがデプロむされた埌、 出力 を遞択し、 InstanceId をメモしたす。 2 原文では「デプロむしたいリヌゞョン」ずありたすが、2025/08/18珟圚では US のリヌゞョンのみでデプロむ可胜であり、その他のリヌゞョンでは Bedrock の暩限の関係䞊、正垞に動䜜しないこずが確認されおいたす。 サンプルアプリケヌションずのやりずり EC2 コン゜ヌル に移動し、図3に瀺すように、 AWS Systems Manager の機胜である Session Managerを䜿甚しお、前のセクションでメモしたむンスタンスに接続したす。 図 3: EC2 むンスタンスにセッションマネヌゞャヌを甚いお接続 以䞋のコマンドを実行しお Python アプリケヌションを実行したす sudo -i bash -c "cd /home/ec2-user/agentic-ai-app &amp;&amp; python app.py" 図4に瀺すように、゚ヌゞェントず察話し、倩気情報を取埗するための質問をするこずができたす。 図 4: Weather Forecaster ゚ヌゞェントずの䌚話 Strands ゚ヌゞェントは、 http_request ツヌルを䜿甚しお Weather API を呌び出し、私たちのプロンプトに察する最終的な応答を生成するルヌプで、Claude Sonnet 3.7 ず盞互䜜甚したした。 次のセクションでは、AWS CloudWatch コン゜ヌルでアプリケヌションによっお生成されたテレメトリデヌタを分析する方法を探りたす。 CloudWatch コン゜ヌル䞊でのテレメトリデヌタ分析 トレヌス分析 AWS マネゞメントコン゜ヌルの CloudWatch コン゜ヌル に移動したす。 Application SignalsAPM セクションに移動し、 トレヌスマップ を遞択したす。Strands Agent が トレヌスマップ 内に衚瀺されたす。 図5に瀺すように、 トレヌスマップ の Strands Agent をクリックしお、サンプルアプリケヌションによっお生成されたトレヌスを衚瀺したす。 図 5: トレヌスマップ 図6のトレヌスは、応答時間、所芁時間、各トレヌスのステヌタスを含む、リク゚ストに関する詳现情報を提䟛したす。 図 6: CloudWatch 䞊でのトレヌス 特定のトレヌスをより深く掘り䞋げるには、図7に瀺すように、トレヌスをクリックしおリク゚ストの完党なタむムラむンを衚瀺したす。 図 7: スパンのタむムラむンず盞関づけられたログ トレヌスタむムラむンは、サむクル、呌び出されたモデル、実行されたツヌルを含む、゚ヌゞェントの実行に関するすべおの詳现を明らかにしたす。さらに、実行トレヌスでキャプチャされたデヌタずアプリケヌションログを盞関させるこずができたす。 トレヌス内の特定のステップやスパンのメタデヌタを衚瀺するには、図8に瀺すように、スパンをクリックしおプロンプト、完了、結果に関する完党な詳现を衚瀺したす。 図 8: スパンのメタデヌタ トランザクション怜玢 Application Signals コン゜ヌルのトランザクション怜玢機胜を䜿甚しおスパンを分析するには、以䞋の手順に埓いたす。 Application Signals コン゜ヌル内のトランザクション怜玢セクションに移動したす。 図9に瀺すように、その ID を持぀ナヌザヌによっお行われたすべおのリク゚ストを衚瀺するために、フィルタ attributes.user.id = demo@example.com を远加したす。 図 9: トランザクション怜玢䞊でのスパンのフィルタヌ 各 traceId をクリックしお、プロンプト、完了、スパンでキャプチャされたその他のメタデヌタなど、その特定のリク゚ストの詳现をより深く分析できたす。これにより、サンプルアプリケヌションず察話する個々のナヌザヌのアクティビティを簡単に远跡・調査できたす。 ビゞュアル゚ディタに加えお、 Log Insight QL を䜿甚しお aws/spans ログルヌプに察しお高床なク゚リを実行し、詳现情報を抜出するこずもできたす。䟋えば、図10に瀺すように、総トヌクン䜿甚量が 10,000 tokens を超えるすべおのプロンプトを取埗するク゚リを実行できたす。 fields @timestamp, attributes.gen_ai.prompt, attributes.gen_ai.usage.total_tokens, attributes.user.id | filter attributes.gen_ai.usage.total_tokens &gt; 10000 | sort attributes.gen_ai.usage.total_tokens desc | limit 10 図 10: CloudWatch Logs Insights 䞊でのク゚リの実行 アプリケヌションログずメトリクス アプリケヌションログにアクセスするには、CloudWatch Log グルヌプ の strands-agent-logs ロググルヌプに移動したす。 図11に瀺すように、サンプルアプリケヌションによっお生成されたログを衚瀺するために、最新のログストリヌムを遞択したす。 図 11: CloudWatch Logs 䞊でのアプリケヌションのログ レむテンシ、入力・出力トヌクン、ToolCallCount、ErrorCount、SuccessRate、TotalCycles などのアプリケヌション固有のメトリクスは、別のロググルヌプ strands-agent-metrics で EMF ログずしおCloudWatch に送信されたす。 CloudWatch コン゜ヌルで、 メトリクス セクションに移動するず、図12に瀺すように、 strands-agent-metrics ロググルヌプからのカスタムメトリクスで生成された新しい名前空間 StrandsAgentMetrics が確認できたす。 図 12: CloudWatch メトリクスコン゜ヌル䞊でのアプリケヌションメトリクス StrandsAgentMetrics カスタムメトリクスを䜿甚しお、CloudWatch コン゜ヌルでカスタムダッシュボヌドずアラヌムを䜜成し、AI ゚ヌゞェントアプリケヌションの健党性ずパフォヌマンスを監芖するこずもできたす。 クリヌンアップ CloudFormation スタックの削陀 AWS CloudFormation コン゜ヌル を開き、ナビゲヌションペむンで スタック を遞択したす。 先ほど䜜成した CloudFormation スタックを遞択し、 削陀 を遞択し、「スタックを削陀したすか」ずいうポップアップに察しお、再床 削陀 を遞択したす。 Transaction Searchの無効化 CloudWatch コン゜ヌル の 蚭定 に移動したす。 X-ray トレヌス タブを抌し、 トランザクション怜玢 の ビュヌ蚭定 を遞択したす。 次に 線集 をクリックしたす。 transaction search 機胜を無効にするために チェックボックス を倖したす。 Save をクリックしたす。 結論 このブログ投皿では、Amazon CloudWatch を掻甚しお AI ゚ヌゞェントアプリケヌションを芳察し、掞察を埗る方法を探りたした。OpenTelemetry 暙準仕様に基づいお構築された Strands Agents SDK を䜿甚しお、メトリクス、トレヌス、ログからなる䟡倀のあるテレメトリデヌタを生成するために、アプリケヌションを蚈装する方法を実挔したした。 CloudWatch ゚ヌゞェントを蚭定しおこのようにテレメトリデヌタを収集するこずで、CloudWatch コン゜ヌル内で AI ゚ヌゞェントアプリケヌションのパフォヌマンス、䜿甚量、実行詳现を取り蟌み、分析する方法を瀺したした。これにより、アプリケヌションの健党性ず信頌性を監芖し、発生する問題をトラブルシュヌティングし、AI 駆動ワヌクフロヌのパフォヌマンスを最適化できたす。 重芁なポむントは、䜿甚する特定の゚ヌゞェンティック AI フレヌムワヌクは異なる堎合がありたすが、オブザヌバビリティの原則は同じであるずいうこずです。アプリケヌションが OpenTelemetry などのオヌプンな暙準仕様でテレメトリデヌタを生成する限り、CloudWatch を掻甚しお可芖性を埗るこずができたす。アプリケヌションが EC2、Lambda、ECS、EKS、たたはその他の環境で実行されおいるかどうかに関係なく、゚ヌゞェンティック AI ワヌクロヌドから関連するオブザヌバビリティデヌタを収集するように CloudWatch ゚ヌゞェントを蚭定するだけです。
アマゟン りェブ サヌビス ゞャパン以䞋、AWS ゞャパンが 2024 幎 7 月に発衚した「 生成 AI 実甚化掚進プログラム 」は、生成 AI の掻甚を支揎する取り組みです。基盀モデルの開発者向けず、既存モデルを掻甚する利甚者向けの 2 ぀の枠組みを提䟛し、䌁業の目的や怜蚎段階に応じた最適な支揎を行っおきたした。たた、2025幎4月から生成AI掻甚の戊略策定段階からご支揎する「戊略プランニングコヌス」も提䟛を開始しおおりたす。 その「生成 AI 実甚化掚進プログラム」の参加者や、経枈産業省が䞻催する Generative AI Accelerator Challenge 以䞋、GENIACの関係者、生成 AI に関心を持぀䌁業が䞀堂に䌚する「生成 AI Frontier Meetup」が、2025 幎 8 月 26 日に開催されたした。2024 幎 11 月 15 日の 第 1 回 、2025 幎 2 月 7 日の 第 2 回 、2025 幎 4 月 16 日の 第 3 回 に続き、今回が第 4 回ずなりたす。本蚘事では、むベントの暡様をレポヌトしたす。 本むベントの叞䌚進行は、AWS ゞャパン事業開発統括本郚 生成 AI 掚進マネヌゞャヌである梶原 貎志が務め、党䜓を通じお登壇者の玹介やセッションの案内を行いたした。 開䌚のご挚拶 むベント冒頭では、AWS ゞャパン 事業開発統括本郚 グロヌス事業開発本郚長の塚本 陜子がご挚拶をしたした。AWS ゞャパンは日本のお客様の発展に向け、クラりドサヌビスの提䟛に加えお、急速に掻甚が進む生成AIに぀いおも日本独自のプログラム、グロヌバルでのプログラムの掻甚、政府のプロゞェクトを通じお支揎をしおたいりたした。 2023 幎は「 AWS LLM 開発支揎プログラム 」で 17 瀟を支揎し、2024 幎はモデル開発者に加えお利甚者も察象にした「生成 AI 実甚化掚進プログラム」ぞず拡充。2025 幎には生成 AI の戊略策定支揎を匷化し、环蚈で 200 瀟超を支揎したした。加えお、グロヌバル斜策の「 AWS Generative AI Accelerator 」では 2024 幎にスタヌトアップ 3 瀟が採択され、経枈産業省・NEDO 䞻導の GENIAC でも第 2・第 3 期ずもに 13 瀟を支揎しおいたす。 お客様のニヌズの倉化ずしお、2024 幎は瀟内業務の効率化が䞭心だった䞀方で、2025 幎にかけお既存事業・サヌビスぞの実装盞談が増加し、AI ゚ヌゞェントやドメむン特化型モデルぞの需芁が高たっおいたす。これを受けお、2025 幎 4 月に「戊略プランニングコヌス」を新蚭、6 月には「モデルカスタマむズコヌス」ず「モデル掻甚コヌス」を拡充し、 GENIAC-PRIZE やAgentic AI実甚化を支揎するプランを新蚭したこずを玹介したした。 たた、これたでの「生成 AI Frontier Meetup」の取り組みに぀いおも玹介。ニヌズやテクノロゞヌなど、倉化・進化しおいくものに察しお、本プログラムでは倉わらず、人やコミュニティに察しお、支揎をしおいくこずを述べ、最埌に本むベントから新たな䟡倀が創出されるこずの期埅を述べ、参加者の方々ぞの感謝を䌝えたした。 AWS スピヌカヌによるセッション 続いお、AWS ゞャパン サヌビステクノロゞヌ事業統括本郚 AI ゜リュヌション郚郚長の金杉 有芋子が、AI ゚ヌゞェントがもたらす゜フトりェア開発・運甚・利甚䜓隓の倉化ず、AWS の最新アップデヌトを玹介したした。 冒頭では、Gartner 瀟が発衚した「2028 幎たでに゚ンタヌプラむズアプリの 33 が Agentic AI を取り蟌み、日々の意思決定の 15 が AI に眮き換わる」ずいう予想を玹介。それを螏たえ、AWS ずしお「䞖界で最も有甚な AI ゚ヌゞェントを構築するための堎所を提䟛する」ず述べたした。 AWS のアップデヌトずしお、基盀モデル Amazon Nova に新たなカスタマむズ機胜が加わりたした。継続事前孊習、ファむンチュヌニング、アラむンメント、蒞留ずいった倚様な手法に察応し、䞀郚のカスタマむズ枈みモデルは Amazon Bedrock 䞊でホスト可胜になりたした。加えお、ブラりザ操䜜に特化したモデル + SDK である Amazon Nova Act がリリヌスされたした。Amazon Bedrock では、 Luma AI ず DeepSeek がモデルのラむンナップに加わったほか、盎近では TwelveLabs の Marengo動画をベクトル化する埋め蟌みモデルず Pegasus動画からテキストを生成し、ハむラむト䜜成やタグ付け、分析に掻甚可胜を远加したした。さらに、 OpenAI の gpt-oss 120Billion ず 20Billion の 2 モデルを公開し、掚論やテキスト生成の遞択肢を広げおいたす。 ゚ヌゞェント開発のフレヌムワヌクずしお、オヌプン゜ヌスの Strands Agents SDK を提䟛しおいたす。これは、プロバむダヌに䟝存しないモデル駆動型の蚭蚈ずなっおおり、ネむティブツヌルや MCP サヌバヌ、AWS の各皮サヌビスずの統合を暙準搭茉しおいたす。゚ヌゞェントを本番皌働させる際に生じる問題の解決策ずしお、 Amazon Bedrock AgentCore のプレビュヌを発衚したした。フレヌムワヌクやモデルを問わず、胜力の高い゚ヌゞェントを安党か぀スケヌラブルにデプロむ・運甚するための実行基盀を提䟛したす。 加えお、数週間前に゚ヌゞェント型 IDE である Kiro のプレビュヌをロヌンチしたした。察話しながら実装を進めるバむブコヌディングのモヌドず、仕様を軞に構築するスペックのモヌドを備えおいたす。たた、既存のコヌディングアシスタント Amazon Q Developer も任意の IDE に統合でき、開発から運甚たでのワヌクフロヌ刷新を埌抌ししたす。 さらに、゚ヌゞェントずツヌルが連携する将来を芋据え、 AWS Marketplace に「AI ゚ヌゞェントずツヌル」の新セクションを新蚭したした。自然蚀語でク゚リできる怜玢欄を備え、必芁なツヌルぞのアクセス性を高めおいたす。最埌に、今埌も各サヌビスの改善を続けおいく方針を瀺し、セッションを締めくくりたした。 プログラム参加者によるラむトニングトヌク ここからは、生成 AI 実甚化掚進プログラムに参加する各瀟の代衚者が登壇し、AWS のサヌビス利甚を軞にした取り組みを玹介したした。AWS ゞャパン サヌビス &amp; テクノロゞヌ事業統括本郚 技術本郚長の小林 正人写真右ず、AWS ゞャパン シニア&nbsp;生成 AI&nbsp;スタヌトアップ ゜リュヌションアヌキテクトの針原 䜳貎写真巊がモデレヌタヌを務め、登壇者に質問を投げかけ぀぀進行したした。 モデル開発者の事䟋 東京科孊倧孊 情報理工孊院 修士課皋 2 幎の藀井 䞀喜 氏は、SwallowProject をテヌマに講挔したした。 SwallowProject は東京科孊倧孊ず産業技術総合研究所の共同研究で、英日䞡察応のオヌプン LLM を継続的に開発し぀぀、商甚利甚可胜な圢で Hugging Face に公開しおいたす。合成デヌタ生成の実行基盀には Amazon SageMaker HyperPod ず Amazon EC2 P5 むンスタンスを掻甚しおいたす。 䞉菱電機株匏䌚瀟 情報技術総合研究所 AI 研究開発センタヌの斉藀 蟰圊 氏は、同瀟の AI ブランド「 Maisart 」の研究戊略ずしお、゚ヌゞェント AI の頭脳ずなるドメむン特化型蚀語モデルを玹介したした。汎甚モデルに補造業に特化した孊習を斜し、その䞊で芁玄や QA などのタスク特化孊習を実斜。正解に加えお「望たしくない回答」も合成しお孊習させるこずで、出力の遞別粟床を高めおいたす。 モデル利甚者の事䟋 株匏䌚瀟Zaif システム開発郚 ゚ンゞニアリングマネヌゞャヌの倧宅 悠介 氏は、暗号資産取匕所における生成 AI 掻甚の取り組みに぀いお玹介したした。AI 利甚に䌎うリスクを枛らすため、通信時にプロキシサヌバヌを経由するこずで、API キヌなど正芏衚珟で怜出可胜な情報をブロックしおいたす。さらに、非定型でルヌルを定矩しづらい個人情報などの怜出のため、 Amazon Bedrock Guardrails を掻甚しおいたす。 ナヌザックシステム株匏䌚瀟 AI ゚ヌゞェント事業郚 事業郚長の䞊野真裕氏は、受泚業務の自動化を目的ずした新サヌビス「 Knowfa 受泚 AI ゚ヌゞェント 」に぀いお玹介したした。同瀟は長幎 RPA による定型業務の効率化を提䟛しおきたしたが、非定型領域ぞの察応には生成 AI の掻甚が䞍可欠ず刀断。開発にあたっおは、AWS を掻甚しお PoC を耇数回実斜したした。進化の早い生成 AI の特性を螏たえ、将来的なモデル匷化を芋越した「付け替え可胜」な蚭蚈思想でアヌキテクチャを構築したした。 GENIAC採択者による開発モデルのご玹介 AWSゞャパンはGENIAC第2期においお、蚈13瀟のお客様をご支揎したした。そのうち3瀟より自瀟で開発した基盀モデルに぀いおお話いただきたした。 Turing株匏䌚瀟 CTO の山口 祐 氏は、完党自動運転を実珟するための生成 AI 掻甚に぀いお玹介したした。人間の運転を代替するには、耇雑な亀通状況を理解するマルチモヌダル AI が䞍可欠であるずし、蚀語ず芖芚を組み合わせたモデル「 Heron 」の開発を進めおいたす。この基盀技術を応甚した自動運転モデル「DriveHeron」を甚いお、シミュレヌタヌ䞊で䞀時停止やネゎシ゚ヌションを䌎う運転を実珟しおいたす。 囜立研究開発法人 海掋研究開発機構 䞊垭研究員の束岡 倧祐 氏は、気候倉動察策を支揎する生成 AI モデルを解説したした。同機構はこれたで深海探査や気候シミュレヌション研究を䞭心に取り組んできたしたが、GENIAC 第2期 を契機に、倧芏暡蚀語モデルを甚いた地域気候サヌビスの実珟に着手。自治䜓の防灜蚈画策定や䌁業の TCFD[1] レポヌト䜜成を支揎する仕組みを開発したした。 䌁業代衚者による最埌のセッションは、株匏䌚瀟ヒュヌマノヌム研究所 代衚取締圹瀟長の瀬々 最 氏。同瀟は脈拍や血圧ずいったバむタルデヌタや遺䌝子発珟量のような情報を掻甚し、がん研究や創薬支揎に応甚できるモデルの開発を進めおいたす。GENIAC のプロゞェクトでは、䞖界䞭から収集した 9 億现胞分のデヌタを基盀に、3 億现胞分の高品質デヌタで孊習を実斜。遺䌝子倉異による圱響をシミュレヌション可胜ずするモデルを構築したした。 登壇者の皆様 クロヌゞング AWS ゞャパンの梶原がクロヌゞングを行いたした。次回の「生成 AI Frontier Meetup」は 2025 幎 11 月 17 日に開催が決定しおいたす。たた䜵せお、近日開催予定の生成 AI 関連のむベントもご案内したした。 AWS Amazon Nova Ignite 日本初開催の ISV/SaaS ビゞネスに携わるお客様のためのむベント。AI ゚ヌゞェントにおける抂念実蚌PoCから本番運甚に至るたでの重芁なギャップを乗り越えるために必芁な芁玠などをご玹介。 むベント抂芁 日時: 2025幎9月24日 (æ°Ž) 13:30~18:40受付開始 12:45 開催方匏: 察面のみ 䌚堎: 九段テラスカンファレンスホヌル2F 鳳凰九段䞋駅より埒歩1分 登壇者様: 株匏䌚瀟四囜銀行様、株匏䌚瀟NTTデヌタ様、 株匏䌚瀟キヌ・プランニング様 登録はこちら AWS Japan AI Agent Day 2025 – AWS で実珟する独⟃ LLM 構築 – AI ゚ヌゞェントの実装ず掻✀に焊点を圓おた、技術者向けカンファレンス。 コヌディング゚ヌゞェント、゚ヌゞェント時代のセキュリティ、゚ヌゞェンティックツヌルずしおの RAGRetrieval-Augmented Generationなど、AI ゚ヌゞェント構築に必芁な芁玠を包括的にご玹介。 むベント抂芁 ✇時: 2025 幎 10 ✉ 1 ✇✊13:00〜18:00 開催✅匏: オンラむン 登録✅法等、詳现に぀いおは近✇公開予定 OpenAI gpt-oss ファむンチュヌニング⌊⟚ – AWS で実珟する独⟃ LLM 構築 – Amazon SageMaker AI を掻✀しお最新のオヌプンりェむトモデルOpenAI gpt-ossをファむンチュヌニングする実践的な⌿法を䜓隓するハンズオン。 ⟔語・✂化の保護やセキュリティの芳点から重芁性が⟌たるオヌプンりェむトモデルの⟃瀟掻✀に぀いお、LoRA などの PEFT 技術を✀いた効率的なカスタマむズ✅法をご玹介。 むベント抂芁 ✇時: 2025 幎 10 ✉ 2 ✇✊14:00〜18:00開堎 13:30 開催✅匏: ハむブリッド 䌚堎: ✬⿊セントラルスク゚ア 17F ご登録はこちら 参加者亀流䌚の様子 亀流䌚では、各セッションで共有された事䟋を起点に、登壇者ず参加者が自由に意芋を亀わす様子が目立ちたした。生成 AI 導入における工倫や課題、今埌の方向性をめぐっお熱心な議論が続き、䌚堎党䜓に掻気があふれおいたした。業皮や圹割を超えたネットワヌキングも進み、実務で埗た知芋を共有しながら、新たな連携や共創の芜が育たれる堎ずなりたした。 䌚堎内には、技術的な盞談に応じる「Ask an Expert」コヌナヌも蚭けられ、ご参加のお客様の質問に回答いたしたした。 おわりに 本むベントは、生成AIの瀟䌚実装に向けた最新の取り組みや、具䜓的な業務掻甚の事䟋が数倚く玹介され、珟堎で圹立぀孊びを埗られる有意矩な時間ずなりたした。AWS ゞャパンは、今埌も業界暪断での亀流や技術支揎を通じお、䌁業の生成 AI 掻甚を埌抌しし、持続的な実甚化に貢献しおいきたす。 [1] TCFD: Task Force on Climate-related Financial Disclosure (気候関連財務情報開瀺タスクフォヌス)
今日の競争の激しい産業環境においお、建蚭機械、鉱山機械、工堎蚭備などの産業機械メヌカヌは、補品の可胜性を最倧限に匕き出す革新的な方法を暡玢しおいたす。IoT を掻甚しおこれらの機械をクラりドに接続するこずで、装眮メヌカヌは実際の䜿甚環境での装眮の性胜を可芖化し、皌働パタヌンを理解し、繰り返し発生する故障モヌドを特定し、装眮の改善ず新たなサヌビス提䟛に぀ながる最適化の機䌚を発芋できたす。機械からクラりドぞの包括的な接続゜リュヌションの構築は耇雑で時間のかかる䜜業ずなる可胜性がありたす。ブログ「 AWS を䜿甚したスマヌト産業機械の構築: 総合的ガむド 」では、倧芏暡なむンフラ投資なしで安党でスケヌラブルな産業゜リュヌションを実珟する AWS IoT サヌビスに぀いお説明したした。このブログでは、スマヌト産業機械向けの IoT ず生成 AI を組み合わせた倉革の可胜性に぀いお探りたす。特に、装眮メヌカヌが Amazon Bedrock のような AWS 生成 AI サヌビスず、 AWS IoT Core や AWS IoT SiteWise のような AWS IoT サヌビスを組み合わせお、産業オペレヌションを革新し、新たな掞察を生み出し、具䜓的なビゞネス成果を実珟する方法に焊点を圓おたす。 [蚳泚: このブログにおいお、スマヌト産業機械(Smart Machines , Smart Industrial Machines) はスマヌト補品 (Smart Products: この堎合、消費者向け補品も含む)の䞀分野で䞻に産業珟堎で皌働しITシステムず接続しお高床な機胜を有する装眮、重機、建機などのスマヌト補品を衚しおいたす] スマヌト産業機械向けの生成 AI 生成 AI は、運甚デヌタず補品デヌタからアクションに぀ながる分析結果を導き出すこずで、産業甚途における倧きなむノベヌションをもたらすこずができたす。これにより、機械オペレヌタヌやサヌビス゚ンゞニアは、迅速に、䞀貫性のある方法で問題を解決するこずができたす。 Capgemini の調査 によるず、補造業の倧倚数が生成 AI に単に興味を持っおいるだけでなく、55% が積極的にその可胜性を探求しおおり、45% が珟圚パむロットプロゞェクトに取り組んでいたす。AWS ず AWS パヌトナヌは、䌁業が生成 AI ベヌスのアプリケヌションを効果的に構築し倧芏暡展開するこずを容易にしたす。装眮メヌカヌ向けの生成 AI ず IoT を組み合わせたスマヌト産業機械の 4 ぀のナヌスケヌスに぀いお説明したす。 問題の蚺断・解決の支揎 フィヌルドサヌビスオペレヌションの匷化 装眮メヌカヌ向け機械矀分析 AI が出力した蚺断レポヌト 1. 問題の蚺断・解決の支揎 IoT ず生成 AI の組み合わせは、保守管理に革新をもたらすこずができたす。䟋えば、装眮の IoT センサヌからのデヌタが、枩床、圧力、振動などのしきい倀を超えたこずにより異垞譊報をトリガヌするシナリオを考えおみたしょう。IoT センサヌからの異垞怜知アラヌトに、生成 AI が機噚の取扱説明曞、暙準䜜業手順曞 (SOP) 、過去のメンテナンス蚘録、蓄積された珟堎䜜業者の経隓知識、必芁郚品の履歎などの関連情報を付加するこずで、メンテナンス業務を倧幅に改善するこずができたす。保守チヌムは、譊報に加えお、問題に関する完党な状況、詳现な修理手順のガむダンス、具䜓的な亀換郚品の掚奚事項、修理に必芁な工具のリストなどを受け取るこずができたす。これにより、装眮メヌカヌのサヌビス技術者ず゚ンドナヌザヌの保守スタッフの双方にずっお䞍具合察応が簡玠化され、修理時間が短瞮され、珟地での熟緎したサヌビス゚ンゞニアの必芁性が䜎枛されたす。このナヌスケヌスのサンプル実装に぀いおは、「 AWS における問題の蚺断・解決支揎のガむダンス 」を参照しおください。この組み合わせは、障害怜出を超えた包括的な保守ガむダンスを提䟛し、 音声察応の AI アシスタント を通じお提䟛するこずも可胜で、技術者は修理䜜業䞭に手を自由にしながら、音声で蚺断情報を芁求するこずができたす。䟋えば、技術者がポンプモデルの圧力倉動の原因に぀いお尋ねるず、䜜業の流れを䞭断するこずなく即座に音声ガむダンスを受け取るこずができたす。 2. フィヌルドサヌビスオペレヌションの匷化 珟地での問題の蚺断・解決支揎を基瀎ずしお、装眮メヌカヌは遠隔蚺断ずむンテリゞェントな蚪問前準備により、フィヌルドサヌビスオペレヌションを倉革するこずができたす。フィヌルドサヌビスチヌムは AI が出力した蚺断レポヌトを受け取り、センサヌ枬定倀や゚ラヌコヌドなどの機械デヌタを遠隔で分析し、珟地蚪問が必芁な堎合は各修理に必芁なものを迅速に準備するこずができたす。この準備には、亀換郚品の予想、必芁か぀適切な工具、特定の問題に察する技術者の専門知識の適合が含たれたす。その結果、耇数回の珟地蚪問が枛少し、保守コストが削枛され、初回修理成功率ず修理時間が倧幅に改善されたす。より良い障害分析ず準備により、より良いリ゜ヌス配分、より速い修理時間、より効率的な技術者の配眮、そしお改善された顧客䜓隓が可胜になりたす。 KONE゚レベヌタヌず゚スカレヌタヌのグロヌバルリヌダヌが AWS ず共同で、接続された゚レベヌタヌの保守履歎、IoT デヌタ、関連文曞を分析しお技術者が゚レベヌタヌをより速く修理できるよう支揎する AI 搭茉の技術者アシスタントを開発した様子を このビデオ でご芧ください。 3. 装眮メヌカヌ向け装眮フリヌト分析 埓来の機械矀分析では、数千台の導入枈みの装眮からの掞察を抜出するために、デヌタサむ゚ンティストず耇雑なデヌタ゚ンゞニアリングが必芁でした。生成 AI は、倧芏暡なデヌタセットに察する自然蚀語でのク゚リを可胜にし、テレメトリヌデヌタずサヌビスレポヌトやオペレヌタヌのフィヌドバックなどの非構造化゜ヌスを組み合わせお、自動的に文章化された分析結果を生成するこずでこれを倉革したす。性胜パタヌンを理解するためにダッシュボヌドを手動で構築する代わりに、装眮メヌカヌは「高枩環境での掘削機の䞀般的な故障モヌドは䜕か」ずいった質問をしお、傟向を特定し、環境芁因を盞関させ、蚭蚈の改善を掚奚する包括的な分析を受け取るこずができたす。これにより、技術チヌム以倖でも機械矀の掞察にアクセスできるようになり、営業チヌムや補品チヌムが異なるナヌスケヌスや環境での装眮の性胜を迅速に理解できるようになりたす。これらの掞察により、新しい「サヌビス化」ビゞネスモデルも可胜になりたす。システムは資産タむプ、顧客セグメント、地理的䜍眮ごずに詳现な性胜に関する文章を自動的に生成し、これたでは倧量の手䜜業による分析が必芁だったパタヌンを明らかにしたす。 4. AI が出力した蚺断レポヌト 装眮メヌカヌは生成 AI を掻甚しお、テレメトリヌデヌタ、保守履歎、環境条件、むンシデントログなど、耇数のデヌタ゜ヌスを統合した包括的な運甚レポヌトを䜜成するこずができたす。これらのレポヌトは自瀟チヌムの戊略的掞察を創出し、たた手䜜業によるレポヌト䜜成ずデヌタ収集の時間を節玄するこずもできたす。これらのレポヌトは、リアクティブな蚺断ずは異なり、より広範な性胜パタヌンを分析しお補品開発に情報を提䟛し、蚭蚈の改善を特定し、サヌビスず顧客サポヌト戊略を最適化したす。 これらのレポヌトは、補造業者向けの戊略的むンテリゞェンスず、顧客向けの自動化された倚次元レポヌトの䞡方のレベルで䟡倀を創出する二重レポヌトアプロヌチを取るこずができたす。装眮メヌカヌはこれらの蚺断機胜を顧客向けのプレミアムサヌビスずしお提䟛し、装眮の信頌性向䞊、より良い顧客サヌビス、顧客オペレヌション管理のための掞察を通じお、より匷固な顧客関係を構築しながら、継続的な収益を生み出すこずができたす。 HP が AWS ずずもに、IoT、機械孊習、生成 AI を掻甚しお未来のむンテリゞェント印刷工堎を創造しおいる様子を このビデオ でご芧ください。 IoT デヌタず生成 AI の橋枡し 「 AWS でのスマヌト産業機械導入のガむダンス 」は、スマヌト産業機械ぞの取り組みの出発点ずなりたす。このガむダンスは、スマヌト産業機械を効果的に倧芏暡に接続・管理するために必芁な基本的な構成芁玠を確立し、同時にさたざたなアプリケヌションのために品質デヌタを準備、文脈化、維持する産業デヌタ基盀を䜜成したす。この基盀があれば、装眮メヌカヌは AWS の生成 AI を䜿甚しお新しい機胜を開発するこずができたす。 図 1 のアヌキテクチャ図は、生成 AI レむダヌが远加されたこの基本的なスマヌト産業機械アヌキテクチャを瀺しおいたす。 図 1: AWS IoT ず生成 AI を䜿甚した AWS でのスマヌト産業機械導入のアヌキテクチャ 産業甚 IoT デヌタは、AWS IoT SiteWise Edge を䜿甚しお AWS IoT SiteWise に盎接取り蟌むか、AWS IoT Core のルヌルを介しお取り蟌たれたす。システム内で、このデヌタは静的プロパティシリアル番号、機械タむプなどず動的プロパティセンサヌ枬定倀、GPS 䜍眮などを組み合わせたデゞタルアセットモデルに敎理されたす。モヌタヌ、アクチュ゚ヌタヌ、ポンプなどの個々のアセットは、より倧きな機械や装眮を衚珟するために芪子関係で接続されたす。構造化された IoT デヌタの基盀は、生成 AI 機胜ず組み合わされるこずでさらに匷力になり、生の運甚デヌタを実甚的な掞察ずむンテリゞェントな自動応答に倉換しお、支揎付き保守ず機械矀管理分析を実珟したす。このパタヌンは、亀換郚品ず保守蚘録情報を取埗するための保守プラットフォヌムなどのサヌドパヌティの産業システムにも拡匵するこずができたす。 Amazon Bedrock: IoT ず生成 AI の統合のための柔軟な゜リュヌション スマヌト産業機械゜リュヌションに取り組む装眮メヌカヌは、Amazon Bedrock で生成 AI の取り組みを開始するこずができたす。Amazon Bedrock は、䞻芁な基盀モデル (FM) ぞの容易なアクセスを提䟛する完党マネヌゞド型サヌビスです。 Amazon Bedrock Knowledge Bases を䜿甚するず、これらのモデルず組織のデヌタを簡単に接続しお、特定の情報゜ヌスに基づいた正確で関連性の高い文脈に応じた応答を提䟛するこずができたす。Amazon Bedrock Knowledge Bases は、Amazon S3、倖郚システム、Salesforce、Confluence、SharePoint などの顧客゜リュヌション、およびカスタム゚ンドポむントの既存デヌタず接続し、迅速な導入を可胜にしたす。Amazon Bedrock Knowledge Base のセットアップは、 ここ で定矩されおいる手順を䜿甚しお迅速か぀簡単に行うこずができたす。 モデルずデヌタを Amazon Bedrock Agents ず組み合わせるこずで、デヌタの保存堎所に関係なく、IoT デヌタや独自の情報から迅速に掞察を埗るこずができたす。自然蚀語でのやり取りを通じお、1 台の機械を監芖したり、シヌムレスに機械矀党䜓の管理に拡匵したり、運甚サマリヌを生成したりするこずができたす。Amazon Bedrock Agents は倖郚システムに察するタスクを調敎・実行するこずができ、IoT デヌタず保守システムをク゚リしお新しいむンシデントチケットや譊報を䜜成するこずができたす。これにより、自埋型゚ヌゞェントを䜿甚しおあらゆるワヌクフロヌに察応するこずができたす。 䟋えば、Amazon Bedrock agents は、IoT デヌタずナレッゞベヌスの掞察を加えお、 Amazon Connect で自動的にサポヌトチケットを䜜成するこずができたす。装眮の問題が発生した堎合、システムは状況に応じた情報ずずもにオペレヌタヌに即座に通知し、より迅速な解決ずプロアクティブな顧客サヌビスを可胜にしたす。このコンタクトセンタヌパタヌンの詳现に぀いおは、「 AWS での自動入力のコンタクトセンタヌぞの接続ガむダンス 」を参照しおください。 Amazon Bedrock は、より耇雑なワヌクフロヌのための゚ヌゞェントシステムの構築を加速する マルチ゚ヌゞェントコラボレヌション もサポヌトしおいたす。この機胜のハンズオンデモンストレヌションに぀いおは、 Amazon Bedrock マルチ゚ヌゞェントコラボレヌション をご芧ください。 スマヌト産業機械向けの゚ッゞむンテリゞェンス 接続性が限られおいるか䞍安定な環境で皌働する産業機噚にずっお、生成 AI 機胜を゚ッゞに盎接導入するこずは魅力的な遞択肢です。接続性ずコンピュヌティング胜力に応じお、定型的な小芏暡タスクぱッゞモデルで実行し、より耇雑なク゚リは接続が利甚可胜な堎合にクラりドの倧芏暡蚀語モデル (LLM) にオフロヌドするハむブリッドアプロヌチを採甚するこずもできたす。小芏暡蚀語モデル (SLM) をスマヌト産業機械に盎接組み蟌むこずも可胜で、オフラむン状態でも継続的な AI 支揎が可胜になりたす。 AWS での゚ッゞむンテリゞェンス ず ゚ッゞでの生成 AI ず IoT のベストプラクティス に぀いお詳しくは、これらのブログをご芧ください。 AWS IoT SiteWise Assistant: 産業甚 IoT ず生成 AI 統合のためのネむティブ゜リュヌション Amazon Bedrock があらゆる IoT デヌタ゜ヌスに察しお柔軟な基盀を提䟛する䞀方で、AWS は産業甚デヌタの収集、保存、分析のニヌズに AWS IoT SiteWise を利甚する産業機噚メヌカヌ向けに目的に特化した゜リュヌションも提䟛しおいたす。 AWS IoT SiteWise Assistant は、機械の性胜、傟向、運甚指暙に関する掞察を埗るために耇雑な技術的ク゚リステヌトメントを曞く必芁なく、自然蚀語で機械デヌタをク゚リできるようにするこずで AWS IoT SiteWise の機胜を匷化したす。より詳现な抂芁に぀いおは、「 AWS IoT SiteWise Assistant による産業意思決定の倉革 」をご芧ください。 補品開発ラむフサむクルに生成 AI を掻甚し垂堎投入を加速する [この章は日本のお客様向けに原著者蚱諟のもず AWS Japan SA 吉川が远加したした] 補造業におけるスマヌト補品開発で比重をたしおいる゜フツェア開発にでは、生成 AI ツヌルを掻甚するこずで倧幅な効率化が可胜です。AWS Japan ブログ「 生成 AI (Amazon Bedrock ず Amazon Q Developer) を掻甚した補造業スマヌト補品開発の新しいかたち – Part2 補品開発ラむフサむクルの加速 」では、生成 AI が゜フトりェア補品開発ラむフサむクル (SDLC) の各フェヌズでどのように掻甚できるかを詳しく解説しおいたす。垂堎調査やプロトタむピング、芁件定矩、コヌディング、テスト、デバッグ、倚蚀語察応など、開発プロセス党䜓で生成 AI を掻甚した具䜓的な掻甚事䟋が玹介されおいたす。さらにタスクの自動化や人間ず AI の協調開発の仕組みに぀いお詳しく説明されおおり、開発者ずしお参考になる知芋が埗られたす。生成 AI ツヌルの掻甚によるスマヌト補品開発の効率化ず生産性向䞊のヒントが埗られるはずです。 AWS パヌトナヌによるスマヌト産業機械向けの生成 AI AWS パヌトナヌは、戊略的コンサルティングやアむデア創出から、「 AWS でのスマヌト産業機械導入のガむダンス 」を掻甚したスケヌラブルで安党な゜リュヌションの提䟛たで、スマヌト産業機械゜リュヌションを構築する AWS の顧客をサポヌトする重芁な圹割を果たしおいたす。このセクションでは、これらのシステムむンテグレヌタ (SI) AWS パヌトナヌが、IoT ず生成 AI の組み合わせにより、顧客を支揎し、より広範なスマヌト産業機械産業を発展させおいる方法に぀いお説明したす。 日本のお客様向け情報 富士゜フト は AWS プレミアパヌトナヌずしお IoT やスマヌト産業機械の開発に豊富な実瞟を持っおいたす。装眮の組み蟌み開発からアプリケヌション開発たで䞀貫したサヌビスを行っおおり、センサヌデヌタ収集、機械孊習による予防保守、遠隔操䜜など、 IoT を掻甚した機胜の実珟が可胜です。 AWS サヌビスの導入から運甚・技術サポヌトたでのワンストップ支揎 も行っおいたす。ものづくりの珟堎ニヌズに合わせた゜リュヌションず、豊富な開発実瞟のある技術者が、 IoT 化を支揎したす。 クラスメ゜ッド は、AWS プレミアパヌトナヌずしお豊富な IoT ゜リュヌション構築実瞟を持っおいたす。5,000 件を超えるプロゞェクト実瞟ず 3,500 以䞊の AWS 認定を有し、 スマヌト産業機械からのデヌタ収集、分析基盀の構築、モバむルアプリ開発など、 IoT ゜リュヌション の䞀貫した提䟛が可胜です。特に AWS の IoT サヌビスを掻甚した IoT システムの蚭蚈、構築、運甚支揎に匷みを持っおいたす。 グロヌバルパヌトナヌ AWS のパヌトナヌは䞖界䞭でお客様を支揎しおいたす。北米や欧州のスマヌト産業機械システムを構築するずきには、以䞋のグロヌバルパヌトナヌに関する情報が圹に立ちたす。 Deloitte は生成 AI を掻甚しお、スマヌト産業機械向けの支揎付き保守ず自埋的な意思決定を実珟し、アフタヌマヌケットサポヌトず Equipment-as-a-Service (EaaS) ぞの移行の䞡方を最適化しおいたす。 SoftServe の統合 IIoT プラットフォヌム ず 生成 AI ゜リュヌション は、産業甚 IoT (IIoT)、生成 AI、デゞタルツむン、NVIDIA の機胜を組み合わせおスマヌト産業機械を倉革したす。圌らの Schunk 実装により、遠隔およびフィヌルドサポヌト゚ンゞニアが顧客の装眮を効率的にトラブルシュヌティングできるようになりたす。 Twisthink は珟圚、生成 AI ず IoT の AWS サヌビスを掻甚しお、より少ない開発努力ず投資で、予枬保守ず機械矀管理分析のためのス マヌト産業機械ナヌスケヌス をサポヌトしおいたす。 Green Custard は AWS 䞊で IoT ず生成 AI を組み合わせ、支揎付き保守、リアルタむムの性胜最適化、匷化された顧客サポヌトを通じおスマヌト産業機械の提䟛を革新しおいたす。圌らの Britvic’s Aqua Libra Flavour Tap の実装は、IoT デヌタずサポヌト文曞のむンテリゞェントな分析を通じお匷化された顧客サヌビスを実蚌しおいたす。 結論 IoT ず生成 AI の組み合わせは、保守運甚の匷化、機械矀管理プロセスの拡匵、顧客向けの新しいアプリケヌションを通じた新たな収益源の創出により、スマヌト産業機械メヌカヌにずっお倉革的です。AWS ず AWS パヌトナヌは、補造業者が珟圚の IoT ゜リュヌションを拡匵するか、競争力を維持し収益成長を促進する䜍眮付けの新しいスマヌト産業機械を構築するのを支揎するサヌビスず゜リュヌションを提䟛したす。 IoT ず生成 AI で補品を倉革する準備はできたしたか AWS たたは AWS パヌトナヌにご連絡いただき、今日からスマヌト産業機械の取り組みを開始しおください。AWS での生成 AI の詳现に぀いおは、以䞋のリ゜ヌスをご芧ください 産業向け生成 AI 生成 AI むノベヌションセンタヌ Amazon Bedrock Agents を䜿甚した堅牢な生成 AI アプリケヌションを構築するためのベストプラクティス AWS Internet of Things このブログぞの远加の貢献者に特別な感謝を捧げたす。このブログの背埌には、産業甚 IoT の背景を持぀以䞋の方々を含む、産業、IoT、生成 AI にわたる AWS スペシャリストの玠晎らしいコラボレヌションがありたす Yuri Chamarelli 、シニア生成 AI/ML スペシャリスト゜リュヌションアヌキテクト産業甚 IoT のバックグラりンド Channa Samynathan 、AWS Edge AI &amp; Advanced Computing シニアワヌルドワむドスペシャリスト゜リュヌションアヌキテクト Vijay Karthick Baskar 、補造業向けシニアパヌトナヌ゜リュヌションアヌキテクト Dimitrios Spiliopoulos Dimitrios Spiliopoulos は、AWS のワヌルドワむド・プリンシパル IIoT GTM スペシャリストです。圌は LinkedIn のトップボむスであり、産業甚 IoT ずスマヌト補造に関する定期的な執筆者およびスピヌカヌずしお、グロヌバルな産業顧客やパヌトナヌず協力しおいたす。AWS では IoT ず補造に関連するさたざたな圹割で 3 幎半の経隓を持ちたす。 IoT 分野ず補造業界での功瞟により、Manufacturer.com による補造業界トップ 100 アドボケむト賞や Onalytica による Who is Who in IoT など、数々の賞を受賞しおいたす。たた、2018 幎から IE ビゞネススクヌルで IoT の非垞勀教授を務めおいたす。 ゚ッゞコンピュヌティング、IoT、デゞタルツむン、AI、サステナビリティ、むンダストリヌ 4.0 に関する知芋を共有するこずを埗意ずしおいたす。LinkedIn での フォロヌやコネクトをお埅ちしおいたす: https://www.linkedin.com/in/spiliopoulosdimitrios/ Gabriel Verreault Gabriel は AWS のシニア・パヌトナヌ・゜リュヌション・アヌキテクトずしお、補造業分野、特に産業蚭備の保党ず産業甚 AI に泚力しおいたす。産業甚デヌタプラットフォヌムのバックグラりンドを掻かし、スマヌト補造、スマヌト産業機械、AI/ML に関する゜リュヌションの定矩、構築、啓発掻動においお AWS パヌトナヌず協力しおいたす。 Gary Emmerton Gary は英囜を拠点ずする AWS のシニア・゜リュヌション・アヌキテクトです。クラりド゜リュヌションを䞭心に䌁業のお客様を担圓しおおり、特に IoT テクノロゞヌを専門ずしおいたす。電子工孊のバックグラりンドを持ち、IT 業界で 30 幎以䞊にわたりさたざたな圹割を経隓しおきたした。消費財から金融サヌビス、゚ネルギヌ・公共事業たで、幅広い業界のお客様を支揎しおきた豊富な経隓を有しおいたす。 このブログはAWS Blog Maximizing the value of Smart Machines with generative AI and IoT を元にAWS Japan Solutions Architect 吉川晃平 (Kohei Yoshikawa) が翻蚳し日本の読者向け情報を远蚘したした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 2025幎も8月に入り、生成AIの分野では匕き続き掻発な開発ず新機胜のリリヌスが続いおいたす。特に、Amazon Bedrock における先端的なモデル遞択肢の拡充Claude Opus4.1 及び gpt-ossや昚今関心が高たっおいる AI 駆動開発ラむフサむクルに぀いおのブログがずおも興味深かったのでぜひご䞀読ください。 先日 2぀の新しいプランを远加した「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も非垞に倚くの申し蟌みをいただいおいたす。匕き続き募集䞭ですのでよろしくお願いしたす。 それでは、8 月 11 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「 AI 駆動開発ラむフサむクル:゜フトりェア゚ンゞニアリングの再構築 」を公開 AI技術を掻甚した新しい゜フトりェア開発ラむフサむクルに぀いお、埓来の開発プロセスずの比范、AI統合による各フェヌズの倉革、具䜓的なメリットを包括的に解説しおいたす。特に、芁件定矩から蚭蚈、実装、テスト、デプロむメント、運甚に至る各段階をコンテキスト情報を介しおシヌムレスに継続させる、アむデアから実際にお客様が利甚するたでの゜フトりェア開発党般を再考するための新しい考え方に぀いお詳しく説明しおいたす。 ブログ蚘事「 Amazon Q Developer CLI カスタム゚ヌゞェントで開発の混乱を乗り越えよう 」を公開 Amazon Q Developer CLIのカスタム゚ヌゞェント機胜を掻甚しお、耇雑な開発環境での混乱を解決する方法に぀いお詳しく解説しおいたす。特に、マルチプロゞェクト環境での䟝存関係管理、コヌド品質の䞀貫性確保、チヌム間のワヌクフロヌ統䞀ずいった課題を題材に、耇数のカスタム゚ヌゞェントを䜿い分けるこずによっおツヌルや暩限蚭定ずいった゚ヌゞェント管理䞊のオヌバヌヘッドを削枛する方法を提瀺しおいたす。 ブログ蚘事「 Kiro の䟡栌蚭定を理解するSpec、Vibe、䜿甚量のトラッキング 」を公開 Kiroの包括的な理解を深めるため、お客様から特に倚数のお問い合わせをいただいた䟡栌䜓系の詳现、技術仕様、ナヌザヌ゚クスペリ゚ンス、そしお利甚状況の効果的な远跡方法に぀いお詳しく解説しおいたす。特に、コスト最適化のための料金プランの遞択方法、パフォヌマンス芁件に応じた蚭定調敎、実際の䜿甚感やナヌザビリティの評䟡ポむントに焊点を圓おおいたす。 ブログ蚘事「 OpenAI オヌプンりェむトモデルが AWS で利甚可胜に 」を公開 OpenAIのオヌプンりェむトモデルgpt-oss-120b、gpt-oss-20bがAWS䞊で利甚可胜になったこずに぀いお、モデルの特城、性胜ベンチマヌク、具䜓的な掻甚シナリオを詳しく玹介しおいたす。特に、コヌディング支揎、科孊的分析、数孊的掚論における優れた性胜、128Kコンテキストりィンドりの掻甚方法、調敎可胜な掚論レベルの蚭定に぀いお実䟋を亀えお説明しおいたす。䌁業が独自のAI゜リュヌションを構築する際に、高性胜なオヌプン゜ヌスモデルを掻甚しおコストを抑制しながらカスタマむズ性ず制埡性を確保できる、 AWS における新たな基盀モデルの遞択肢に関する情報を提䟛しおいたす。 ブログ蚘事「 自動掚論チェックを䜿甚しお、AI のハルシネヌションを最小限に抑え、最倧 99% の怜蚌粟床を実珟: 今すぐご利甚いただけたす 」を公開 Amazon Bedrock Guardrailsの自動掚論チェック機胜の䞀般提䟛に぀いお詳しく解説しおいたす。基盀モデルによっお生成されたコンテンツのハルシネヌションを、ドメむン知識ず照らし合わせお効果的に怜出・防止し、高い怜蚌粟床を実珟する仕組みず掻甚方法を玹介しおいたす。 ブログ蚘事「 Amazon S3 Vectors の玹介: 倧芏暡なネむティブベクトルサポヌトを備えた初のクラりドストレヌゞプレビュヌ 」を公開 Amazon S3 Vectorsのプレビュヌ提䟛に぀いお、ベクトルデヌタの効率的な保存・怜玢メカニズム、埓来の゜リュヌションずの性胜比范、実装の簡玠化に぀いお詳しく解説しおいたす。特に、RAGアプリケヌションでの掻甚方法、倧芏暡ベクトル怜玢の最適化技術、既存のS3゚コシステムずのシヌムレスな統合に぀いお具䜓的な事䟋を亀えお説明しおいたす。ベクトル怜玢を必芁ずするAIアプリケヌションの開発者にずっお、むンフラストラクチャの耇雑性を倧幅に軜枛し、開発速床を向䞊させる゜リュヌションずしお玹介されおいたす。 ブログ蚘事「 Amazon DocumentDB サヌバヌレスが利甚可胜になりたした 」を公開 Amazon DocumentDB サヌバヌレスの䞀般提䟛開始に぀いお、サヌバヌレスアヌキテクチャの利点、埓来のプロビゞョニング型ずの違い、コスト最適化の仕組みに぀いお詳しく玹介しおいたす。特に、倉動するワヌクロヌドぞの自動スケヌリング、䜿甚量ベヌスの課金モデル、生成AIアプリケヌションでのドキュメントストレヌゞずしおの掻甚方法に぀いお具䜓的に説明しおいたす。RAGシステムやコンテンツ管理システムなど、ドキュメント指向のAIアプリケヌションを構築する開発者にずっお、運甚負荷を軜枛しながらコスト効率を向䞊させるデヌタベヌス゜リュヌションずなりたす。 ブログ蚘事「 AWS Summit Japan 2025: &nbsp;生成 AI を甚いた教育業界向け゜リュヌションデモのご玹介 」を公開 AWS Summit Japan 2025における生成AI教育に関する取り組みに぀いお玹介しおいたす。生成AI技術の普及ず教育を通じお、より倚くの人々がAI技術を掻甚できるようになるこずを目指した内容ずなっおいたす。 サヌビスアップデヌト Amazon DynamoDB が Console-to-Code 機胜をサポヌト DynamoDBでAmazon Q Developerを掻甚したConsole-to-Code機胜がサポヌトされたした。コン゜ヌル操䜜を蚘録し、生成AIでInfrastructure as Codeを自動生成できたす。この機胜は、Amazon Q Developerが利甚可胜な党おの商甚リヌゞョンで提䟛されおいたす。 Anthropic の Claude Opus 4.1 が Amazon Bedrock で利甚可胜に AnthropicのClaude Opus 4.1がAmazon Bedrockで利甚可胜になりたした。コヌディングず゚ヌゞェント機胜においお業界最高レベルの性胜を提䟛し、耇雑な開発タスクの自動化を実珟したす。珟圚、米囜西郚オレゎン、米囜東郚バヌゞニア北郚、米囜東郚オハむオリヌゞョンで利甚可胜です。 Amazon Bedrock ず Amazon SageMaker JumpStart で OpenAI のオヌプンりェむトモデルが利甚可胜に OpenAIのオヌプンりェむトモデルgpt-oss-120b、gpt-oss-20bがAmazon BedrockずSageMaker JumpStartで利甚可胜になりたした。コヌディング、科孊的分析、数孊的掚論に優れた性胜を発揮したす。Amazon Bedrockでは米囜西郚オレゎンリヌゞョンで、SageMaker JumpStartでは米囜東郚オハむオ、バヌゞニア北郚およびアゞア倪平掋ムンバむ、東京リヌゞョンで利甚可胜です。 Amazon Bedrockがアゞア倪平掋メルボルンリヌゞョンで利甚可胜に Amazon Bedrockがアゞア倪平掋メルボルンリヌゞョンで利甚可胜になりたした。オヌストラリアのお客様がより䜎いレむテンシヌで基盀モデルを利甚できるようになり、生成AIアプリケヌションの構築が効率化されたす。 Amazon Bedrock Guardrailsで自動掚論チェック機胜が䞀般提䟛開始 Amazon Bedrock Guardrailsで自動掚論チェック機胜が䞀般提䟛開始されたした。圢匏怜蚌技術により最倧99%の粟床でAIハルシネヌションを怜出し、芏制業界での生成AI掻甚を支揎したす。この機胜は、米囜東郚バヌゞニア北郚、米囜東郚オハむオ、米囜西郚オレゎン、欧州フランクフルト、欧州アむルランド、欧州パリリヌゞョンで利甚可胜です。 Amazon SageMaker HyperPodで継続的プロビゞョニング機胜がサポヌト SageMaker HyperPodで継続的プロビゞョニング機胜がサポヌトされたした。利甚可胜なむンスタンスでトレヌニングを即座に開始しながら、バックグラりンドで残りの容量を自動プロビゞョニングできたす。この機胜は、Amazon SageMaker HyperPodが利甚可胜な党おのAWSリヌゞョンで提䟛されおいたす。 Amazon OpenSearch Serverlessで自動セマンティック匷化機胜が導入 OpenSearch Serverlessで自動セマンティック匷化機胜が導入されたした。耇雑な蚭定なしでセマンティック怜玢を実装でき、英語専甚ず15蚀語察応の倚蚀語バリアントが提䟛されおいたす。この機胜は、珟圚米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、アゞア倪平掋ムンバむ、シンガポヌル、シドニヌ、東京、欧州フランクフルト、アむルランド、スペむン、ストックホルムリヌゞョンで利甚可胜です。 Amazon OpenSearch ServerlessでHybrid Search、AIコネクタ、自動化機胜がサポヌト OpenSearch ServerlessでHybrid Search、AIコネクタ、自動化機胜がサポヌトされたした。RAGやセマンティック怜玢のナヌスケヌスが促進され、Amazon SageMaker、Bedrockずの統合が簡玠化されたす。これらの機胜は、米囜東郚バヌゞニア北郚、オハむオ、米囜西郚オレゎン、アゞア倪平掋ムンバむ、シンガポヌル、シドニヌ、東京、欧州フランクフルト、アむルランド、スペむン、ストックホルムリヌゞョンで利甚可胜です。 Amazon OpenSearch UIでSAML属性による Fine Grained Access Control&nbsp;がサポヌト OpenSearch UIでSAML属性による Fine Grained Access Control&nbsp;がサポヌトされたした。IdPのナヌザヌ属性に基づく動的で詳现なデヌタアクセス制埡により、マルチテナント環境での運甚が匷化されたす。この機胜は、OpenSearch UIが利甚可胜な党おのリヌゞョンで提䟛されおいたす。 著者に぀いお 䞉厚 航&nbsp; (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近読んだ本は「PACHINCO」です。
ニフティ株匏䌚瀟は、長幎にわたりむンタヌネットサヌビスプロバむダヌずしお安定したサヌビスを提䟛しおきたした。珟圚は総合的なデゞタルサヌビス䌁業ぞず発展し、ポむントサヌビス事業も展開しおいたす。同瀟の「ニフティポむントクラブ」は日垞生掻のあらゆる堎面で利甚できる䟿利なサヌビスずしお倚くのナヌザヌに芪したれおおり、顧客ロむダリティの向䞊に倧きく貢献しおいたす。 このポむントサヌビスは、2025幎4月にAurora PostgreSQLぞの移行を完了したした。 本ブログでは、ニフティが提䟛するポむントサヌビスのデヌタベヌスをOracle Database Enterprise EditionからAurora PostgreSQLぞ移行した際の゚ピ゜ヌドに぀いおご玹介したす。 移行察象の既存システムずその課題 移行察象ずなったのは、䌚員のポむント残高管理、ポむントの付䞎・利甚履歎の管理、キャンペヌン管理などを担う、ポむントサヌビスの基幹システムです。本システムは、「ニフティポむントクラブ」およびその仕組みを利甚する耇数のサヌビスにずっお䞭栞を担うシステムであり、ニフティずしお圱響範囲が倧きくなるため停止が蚱されないシステムでした。䞀方で、急激なアクセス増加ぞの察応やセキュリティ芁件ぞの適応ずいった面では、珟行システムには柔軟性や可甚性に限界が芋え始めおおり、将来的な運甚継続に課題を抱えおいたした。そうした状況の䞭、利甚䞭の基盀サヌビスの提䟛終了がアナりンスされたこずを受け、より信頌性が高く、保守性に優れた新たなデヌタベヌス基盀ぞの移行が求められる状況ずなっおいたした。 Aurora PostgreSQLに移行するこずを決定した理由 ニフティ株匏䌚瀟では、Amazon Web ServiceのAmazon Aurora PostgreSQLを移行先ずしお遞定したした。移行先の刀断にあたっおは、耇数の芳点を総合的に評䟡したした。 AWS採甚の理由①むンフラ環境のAWSぞの統䞀による運甚効率向䞊ずAWSの豊富な実瞟 デヌタベヌスに先立ち、アプリケヌションの䞀郚はすでにAWS䞊に移行枈みであるこずや連携システムもAWS䞊に構築されおいたこずから、むンフラ環境を統䞀するこずで運甚効率が向䞊するずいう点がありたした。たた、豊富な技術ドキュメントやAWS Blogの事䟋情報、AWSのサポヌト䜓制も瀟内の意思決定を支える安心材料ずなりたした。 AWS採甚の理由②AWS Database Migration Service&nbsp;やパヌトナヌの掻甚 AWSには認定パヌトナヌが倚数存圚し、移行に際しおパヌトナヌを芋぀けやすかったこずに加え、デヌタの移行および移行埌のデヌタ怜蚌にAWS Database Migration ServiceDMSを掻甚できるずいう利点もあり、これらが異皮デヌタベヌスぞのマむグレヌションを埌抌しする芁因ずなりたした。 異皮デヌタベヌス移行の理由①PostgreSQLの運甚経隓ず実瞟の蓄積 瀟内ではすでにPostgreSQLを甚いた採甚実瞟があり、その特性や運甚ノりハりも蓄積されおいたこずから、新たな孊習コストや移行埌のトラブルに察する䞍安が少なく、採甚を埌抌しする芁因ずなりたした。 異皮デヌタベヌス移行の理由②゚ンゞン倉曎に察するコスト 埓来のシステムはPL/SQLぞの䟝存床が䜎く、たた、日々の運甚においお自動化されたテスト環境が敎っおいたこずから、Oracle DatabaseからPostgreSQLぞの゚ンゞン倉曎に䌎う移行コストは比范的抑えられるず芋蟌たれたした。 Aurora採甚の理由Aurora サヌビスによる運甚保守性の向䞊 Aurora PostgreSQLを掻甚した過去の移行経隓を通じお、マネヌゞドな機胜が運甚負荷の軜枛に倧きく寄䞎するこずを実感しおいたした。今回のプロゞェクトでも、バックアップや監芖、セキュリティずいった日垞運甚に関わる機胜をAuroraに任せられるこずで、保守性の高い運甚䜓制を実珟できるず刀断し、Auroraの採甚を決定したした。 移行プロゞェクトの課題ず察策 デヌタベヌス移行プロゞェクトは、技術的な課題だけでなく、蚈画策定や意思決定においおも倚くの困難を䌎いたす。ニフティ株匏䌚瀟では、移行にあたっおアプリケヌション移行ずデヌタ移行の双方でさたざたな課題に盎面し、それぞれに応じた察応を行いたした。 アプリケヌション移行における課題Pro*Cを䜿ったレガシヌコヌドの扱い プロゞェクトの初期段階で、移行察象ずなる機胜を詳现に掗い出した結果、すべおの機胜をそのたた移行するず、コストが膚倧になるこずが刀明したした。特に、Pro*Cを䜿甚しお実装されたコヌドが倚数存圚しおおり、Oracle Database固有の機胜や構文に䟝存しおいる箇所もありたした。そのため、以䞋の察応を実斜する方向で、蚈画の芋盎しを行いたした。 Webアプリケヌション偎のロゞックに組み蟌み、アプリケヌションコヌドに眮き換える察応 䞀郚機胜に぀いおは倖郚パヌトナヌぞ開発を委蚗 利甚頻床の䜎い機胜を廃止する決断 必須機胜ず廃止可胜な機胜の遞別、および瀟内で機胜廃止の議論を行い、移行察象数を䞋げる察応 デヌタ移行における課題①文字コヌドの問題 デヌタ移行においお特に困難だった課題の䞀぀が、文字コヌドの問題です。具䜓的には、EUCやSJISなど耇数の文字コヌドが混圚しおおり、これは連携先䌁業から取り蟌むデヌタに察するバリデヌションが䞍十分であるこずなど、耇数の芁因によっお発生しおいたした。さらに、Oracle DatabaseのEUCずPostgreSQLのEUCでは機皮䟝存文字の解釈に違いがあり、PostgreSQLでは䞀郚の文字に察応できないずいう問題も存圚したした。 これらの課題に察しおは、DMSで移行可胜なデヌタに぀いおは自動移行を実斜し、゚ラヌずなったデヌタに぀いおは個別に察応したした。たた、文字コヌドの問題が予想されるカラムに぀いおは、CSVに出力しお個別に移行凊理を行うこずで、文字化けやデヌタ欠損のリスクを最小限に抑えたした。さらに、PostgreSQLで察応できない文字に぀いおは、該圓件数を確認したずころ少数であるこずが刀明したため、「」に眮換する方針で瀟内の合意を埗お察応を進めたした。 デヌタ移行における課題②倧量デヌタの取捚遞択 長幎運甚されおきたシステムであったため、䞀郚のテヌブルには4億レコヌド20幎以䞊にわたっお蓄積されたデヌタずいう膚倧なデヌタが存圚しおいたした。すべおのデヌタを移行する堎合、移行前の評䟡䜜業や移行にかかる時間の点で課題があったこずから、デヌタの必芁性を改めお芋盎す決断をしたした。他サヌビスにおけるデヌタ利甚状況を、関係郚門に確認のうえ粟査した結果、叀いデヌタ特にポむント履歎デヌタは移行の必芁がないず刀断できたした。これにより、業務䞊必芁な盎近数幎分のデヌタ数千䞇レコヌドのみを移行する方針を瀟内で決定するこずができたした。この調査ず刀断により、移行察象ずなるデヌタ量を倧幅に削枛するこずができたした。 蚈画倉曎を経お完了した移行の道のり 圓初、移行プロゞェクトは2025幎3月末の完了を予定しおいたしたが、実際には4月末に完了したした。たた、人的リ゜ヌスに぀いおも、圓初蚈画しおいた50人月から玄65人月ぞず増加する結果ずなりたした。こうした芏暡の倉化は、移行過皋で刀明した耇雑な技術的課題に察応するために必芁だったものです。䞀方で、DMSを甚いお移行を行えたこずや、AWS䞊で本番盞圓の怜蚌環境を容易に構築できたこずは、品質確保や開発スピヌドの向䞊に倧きく寄䞎したず振り返っおいたす。党䜓的な移行戊略に぀いおは、AWSのメンバヌに技術的な盞談を行うこずができたした。特に重芁だったのはデヌタ移行方匏の遞定です。圓初は差分移行を蚈画しおいたしたが、AWSメンバヌずの協議を通じお、この方匏に䌎うリスクを確認するこずができたした。リスクを螏たえ移行方匏を倉曎したこずで、朜圚的な倧芏暡障害を未然に防ぐこずができたず考えおいたす。これらの結果、移行プロゞェクトは安党か぀確実に完了するこずができたした。 Amazon Aurora PostgreSQL ぞの移行の効果 Aurora PostgreSQLぞの移行により、耇数の効果が埗られたした。最も倧きな効果は運甚負荷の削枛です。既存プラットフォヌムのシステム保守によるメンテナンス察応コストが50%削枛されたした。埓来は基盀のセキュリティ察応によるメンテナンスが半期に数回発生し、その郜床6時間皋床のサヌビス停止が必芁でしたが、Aurora移行埌はそのような長時間の停止がなくなりたした。 開発面では、PostgreSQLの䜿いやすさが゚ンゞニアの生産性向䞊に貢献しおいたす。叀いOracle Databaseのバヌゞョンを利甚しおいたこずもあり、ク゚リ構文が耇雑化しやすい点が解消されたした。たたマネヌゞドサヌビスになったこずで、Amazon CloudWatchやAmazon RDS Performance Insightsずいった監芖機胜やスロヌク゚リの抜出機胜、自動バックアップ機胜を利甚できるようになり、埓来はシェルスクリプトで自前で構築・管理しおいた䜜業が䞍芁になりたした。Auroraの豊富な機胜により、システムの安定性ず拡匵性を向䞊させるこずが出来たした。 たずめ ニフティ株匏䌚瀟では、今回の AWS 移行により運甚時の負荷やシステムの安定性を改善するこずができたした。今回の AWS 移行に぀いお、ニフティ株匏䌚瀟 サヌビスシステムグルヌプの関 氏、现野 氏は以䞋のように振り返っおいたす。 「䜿い慣れおいる Aurora PostgreSQL に移行したこずで、運甚が倧幅に改善されたした。セキュリティ面の向䞊なども実珟でき、Aurora 移行によるメリットを感じおいたす」 ニフティ株匏䌚瀟 サヌビスシステムグルヌプ 束尟 亜玀氏 (写真䞭倮)、现野 俊平氏 (写真巊)、関 歩歊氏 (写真右)
この蚘事は、AWS の SAP グロヌバル責任者の Sara Alligood ず、SAP の AI プロダクトアンドパヌトナヌマネゞメント郚門長の Kai M ÃŒ hlbauer 氏ずの共著です 2025 幎の SAP Sapphire にお、Amazon Web Services, Inc. ず SAP は、パヌトナヌがお客様のリアルタむムなビゞネス課題を迅速に解決するための生成系 AI アプリケヌションず゚ヌゞェントを構築できるよう支揎する、新しい AI 共同むノベヌションプログラムの開始を発衚したした。 倚くの組織は、生成 AI がビゞネスを倉革する可胜性を認識しおいたすが、どこから始めればよいかわかりたせん。 高床な生成 AI 技術ず基幹システムからの ERP デヌタを組み合わせるこずで、䌁業は倧きな䟡倀を匕き出すこずができたす。 䟋えば、配送ルヌトの最適化、サプラむチェヌン運甚ぞの朜圚的な圱響の予枬、正確な財務芋通しの䜜成などが可胜です。 AI 共同むノベヌションプログラム は、パヌトナヌが ERP ワヌクロヌドに合わせた生成系 AI アプリケヌションを定矩、構築、デプロむできるよう支揎するずいう、䞡瀟の共通ビゞョンを衚しおいたす。 このプログラムでは、SAP の゚ンタヌプラむズテクノロゞヌず AWS の生成 AI サヌビスを組み合わせ、AI のスペシャリスト、プロフェッショナルサヌビスのコンサルタント、゜リュヌションアヌキテクトなど、䞡瀟のスペシャリストによる支揎を提䟛し、お客様の導入に向けた取り組みをサポヌトしたす。 このプログラムには、業界特有のアプリケヌションの開発、テスト、デプロむをサポヌトするための専任の技術リ゜ヌス、クラりドクレゞットなどが含たれたす。 「AWS ず SAP の長幎にわたるパヌトナヌシップは、お客様のクラりドゞャヌニヌを加速し、ビゞネスデヌタからより倚くの䟡倀を匕き出すこずを支揎しおきたした」ず、AWS のスペシャリストおよびパヌトナヌ担圓バむスプレゞデントの Ruba Borno は述べおいたす。 「私たちの AI 共同むノベヌションプログラムは、組織が Amazon Bedrock を䜿甚しお生成 AI アプリケヌションを構築し、最も重芁な SAP デヌタを分析しお掻甚できるようにする、セキュリティず柔軟性を備えた重芁な次のステップです。 これにより、お客様は数十幎分のビゞネス情報を実践的な知芋に倉換しながら、より俊敏でデヌタ駆動型の組織ぞの転換を加速するこずができたす。」 「AWS ずの AI 共同むノベヌションプログラムを通じお、䌁業は最も耇雑な運甚䞊の課題を高い粟床ずスピヌドで解決できるようになりたす」ず SAP の最高技術責任者兌最高 AI 責任者の Philipp Herzig 氏は述べおいたす。 「完党に統合されたプラットフォヌムであるSAP BTP の機胜ず、圓瀟の深いビゞネスプロセスの専門知識を、AWS の包括的な生成 AI 機胜ず組み合わせるこずで、パヌトナヌは目的に特化した AI ゚ヌゞェントを䜜成できるようになりたした。これにより、リアルタむムでの財務䞊の異垞の特定から、混乱時のサプラむチェヌンの自動最適化たで、最も喫緊の課題を解決できたす。」 このプログラムにより、パヌトナヌは SAP Business Technology Platform 䞊の SAP AI Foundation で、Amazon Nova や Anthropic Claude などの倧芏暡蚀語モデルを含む Amazon Bedrock の最新の生成 AI ツヌルずサヌビスを䜿甚しお、生成 AI アプリケヌションを迅速に構築し、芏暡を拡倧するこずができたす。 この発衚は、AWS ず SAP が、Hyundai Motor Group、Moderna、Zurich Insurance Group などのお客様を支揎するために行っおいる取り組みを拡倧するものです。これにより、SAP ワヌクロヌドを AWS に移行・モダナむズし、クラりドの可甚性、柔軟性、スケヌラビリティを実珟できたす。AWS 䞊で SAP ワヌクロヌドを実行するこずで、お客様はデヌタを生成系 AI ゜リュヌションず組み合わせるこずができたす。Accenture や Deloitte などのパヌトナヌは、このプログラムを通じお AWS ず SAP ず協力し、耇雑な課題を解決するための生成系 AI ゜リュヌションの開発ずデプロむを加速させおいたす。 「AWS ず SAP の AI 共同むノベヌションプログラムは、AWS のクラりドむンフラストラクチャず SAP の゚ンタヌプラむズ゜フトりェアの経隓を組み合わせおいたす。Accenture の AI 倉革の専門知識ず業界知識を加えるこずで、䌁業に察しお生成 AI サヌビスを最も重芁なビゞネスワヌクロヌドに統合する方法を具䜓的に瀺すこずができたす」ず、Accenture の Senior Managing Director で SAP Business Group Lead の Caspar Borggreve 氏は述べおいたす。 「䟋えば、AWS ず SAP ず共同で、ある公共事業のお客様ず協力しお、自然灜害に察する資産回埩力の機胜を構築しおいたす。これにより、環境の課題を予枬しお察応し、資産密集地域を保護し、お客様ぞのサヌビス継続性を維持するこずができたす。」 「この AI 共同むノベヌションプログラムは、AWS ず SAP の最先端の生成 AI 機胜ず、Deloitte の深い業界経隓ず技術力を組み合わせ、お客様に倉革的な゜リュヌションを提䟛したす」ず、Deloitte Consulting LLP の AWS グロヌバルチヌフコマヌシャルオフィサヌである Nishita Henry 氏は述べおいたす。 「このプログラムを通じお、Amazon Bedrock を掻甚した財務゜リュヌションを構築し、ヘルスケアおよびラむフサむ゚ンス䌁業が、䞍安定な垂堎環境䞋でも、補品ミックスの最適化、予枬粟床の向䞊、競争力のある䟡栌蚭定の維持を実珟できるよう支揎したす。」 AWS SAP AI 共同むノベヌションプログラム の詳现に぀いおは、 aws.amazon.com/sap/ai をご芧ください。 本ブログはパヌトナヌ゜リュヌションアヌキテクトの束本が翻蚳したした。原文は こちら です。
むベント抂芁 本むベントでは、AWS が提䟛する環境䞊で兞型的なセキュリティむンシデントぞの察応を、チヌム察抗のゲヌム圢匏で䜓隓するこずができたす。たた、昚今様々なお客様におご利甚が怜蚎されおいる生成 AI を甚いたセキュリティに぀いお、AWS および AWS パヌトナヌ様がどのようにむンフラストラクチャ・アプリケヌション・デヌタ・AI のセキュリティを高床化できるのかをご玹介いたしたす。 AWS GameDay に぀いお AWS GameDay は、ある課題に察しお AWS サヌビスで解決するための察応力や実装スキルを詊すこずができる実践圢匏のワヌクショップです。34 名でチヌムを結成し、埅ち受けるさたざたなトラブルやク゚ストをクリアしながら最終ミッションの達成を目指したす。各ク゚ストをクリアするごずにポむントが付䞎され、最も倚くのポむントを獲埗したチヌムが勝者ずなりたす。安党な環境で、楜しみながらさたざたなこずを孊ぶこずができる機䌚を埗られるワヌクショップです。 開催日時 2025幎10月14日火13:00 – 18:00 (12:30 é–‹å Ž)、18:00-19:00 にお参加任意の懇芪䌚を実斜いたしたす。 開催堎所 東京郜品川区䞊倧厎 3-1-1 目黒セントラルスク゚ア 参加察象者 クラりドアヌキテクトや゚ンゞニアから、ディレクタヌ、CTOたで、あらゆるレベルの技術リヌダヌやビルダヌを察象ずしおいたす。 特に以䞋のような方々に最適なむベントずなっおおりたす ・党瀟の AWS アカりントのセキュリティ向䞊斜策に぀いお怜蚎されおいる方 ・CCoE など、党瀟でのアカりント管理やセキュアな利甚を掚進されおいる方 ・AWS 䞊に具䜓的なビゞネスワヌクロヌドをもち、そのセキュリティ向䞊に関心のある方 ・生成 AI を利甚したアプリケヌションにおけるセキュリティ向䞊に関心のある方 ・生成 AI を甚いたセキュリティ向䞊゜リュヌションに興味のある方 定員・参加費 120名 (1チヌム 3名 x 40 チヌム) 事前登録制ずなっおおりたす。 お申し蟌みは、AWSの担圓営業を通しおのお申し蟌みを受け付けずなりたす。 参加費無料 18:00-19:00 におネットワヌキングむベントを予定しおおりたす。クラりドにおけるセキュリティや生成 AI の掻甚のための参加者同士の亀流の堎ずしおもご掻甚ください。 皆様のご参加を心よりお埅ちしおおりたす。
8 月 28 日、カスタム Intel Xeon 6 プロセッサを搭茉し、3.9 GHz の持続オヌルコアタヌボ呚波数を備えた、AWS でのみ利甚可胜な Amazon Elastic Compute Cloud (Amazon EC2) の汎甚 M8i および M8i-Flex むンスタンス の䞀般提䟛の開始をお知らせしたす。これらのむンスタンスは、クラりドにおける同等の Intel プロセッサの䞭でも最高のパフォヌマンスず最速のメモリ垯域幅を提䟛したす。たた、前䞖代の M7i および M7i-Flex むンスタンス ず比范しお、最倧 15 % 優れた䟡栌パフォヌマンス、最倧 20 % 高いパフォヌマンス、2.5 倍のメモリ垯域幅を実珟したす。 M8i および M8i-flex むンスタンスは、汎甚りェブアプリケヌションサヌバヌ、仮想デスクトップ、バッチ凊理、マむクロサヌビス、デヌタベヌス、゚ンタヌプラむズアプリケヌションなどの汎甚ワヌクロヌドの実行に最適です。これらのむンスタンスのパフォヌマンスに関しお、M7i および M7i-Flex むンスタンスず比范するず、NGINX りェブアプリケヌションの堎合は最倧 60 、PostgreSQL デヌタベヌスワヌクロヌドの堎合は最倧 30 、AI 深局孊習のレコメンデヌションモデルの堎合は最倧 40  高速です。 R8i および R8i-Flex むンスタンス ず同様、これらのむンスタンスは新しい第 6 䞖代 AWS Nitro Card を䜿甚しおおり、前䞖代のむンスタンスず比范しおネットワヌクず Amazon Elastic Block Storage (Amazon EBS) の垯域幅が最倧 2 倍増加しおいたす。そのため、りェブ、アプリケヌション、ゲヌムサヌバヌなどの小芏暡なパケットを凊理するワヌクロヌドのネットワヌクスルヌプットが倧幅に向䞊したす。たた、ネットワヌクず Amazon EBS 垯域幅の間で 25 % の割り圓お調敎を行う垯域幅蚭定にも察応しおおり、デヌタベヌスのパフォヌマンス、ク゚リ凊理、ログ蚘録速床が向䞊したす。 M8i むンスタンス M8i むンスタンスは、基盀ずなる物理ハヌドりェアぞの専甚アクセスを提䟛するベアメタルむンスタンスを含め、最倧 384 個の vCPU ず 1.5 TB のメモリを提䟛したす。これらの SAP 認定むンスタンスは、最倧のむンスタンスサむズや継続的に高い CPU を必芁ずする倧芏暡なアプリケヌションサヌバヌやデヌタベヌス、ゲヌムサヌバヌ、CPU ベヌスの掚論、動画のストリヌミングを実行するのに圹立ちたす。 M8i むンスタンスの仕様は次のずおりです。 むンスタンスサむズ vCPU メモリ (GiB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) m8i.large 2 8 最倧 12.5 最倧 10 m8i.xlarge 4 16 最倧 12.5 最倧 10 m8i.2xlarge 8 32 最倧 15 最倧 10 m8i.4xlarge 16 64 最倧 15 最倧 10 m8i.8xlarge 32 128 15 10 m8i.12xlarge 48 192 22.5 15 m8i.16xlarge 64 256 30 20 m8i.24xlarge 96 384 40 30 m8i.32xlarge 128 512 50 40 m8i.48xlarge 192 768 75 60 m8i.96xlarge 384 1536 100 80 m8i.metal-48xl 192 768 75 60 m8i.metal-96xl 384 1536 100 80 M8i-Flex むンスタンス M8i-Flex むンスタンスは、M8i むンスタンスの䜎コスト版であり、5 % 䜎い料金で 5 % 優れた料金パフォヌマンスを実珟しおいたす。最新䞖代のパフォヌマンスから恩恵を享受できるにかかわらず、すべおのコンピュヌティングリ゜ヌスを完党に掻甚しおいないワヌクロヌド向けに蚭蚈されおいたす。これらのむンスタンスは、95 % の確率で最倧 CPU パフォヌマンスを発揮できたす。 M8i-Flex むンスタンスの仕様は次のずおりです。 むンスタンスサむズ vCPU メモリ (GiB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) m8i-flex.large 2 8 最倧 12.5 最倧 10 m8i-flex.xlarge 4 16 最倧 12.5 最倧 10 m8i-flex.2xlarge 8 32 最倧 15 最倧 10 m8i-flex.4xlarge 16 64 最倧 15 最倧 10 m8i-flex.8xlarge 32 128 最倧 15 最倧 10 m8i-flex.12xlarge 48 192 最倧 22.5 最倧 15 m8i-flex.16xlarge 64 256 最倧 30 最倧 20 珟圚、旧䞖代の汎甚むンスタンスを䜿甚しおいる堎合は、アプリケヌションやワヌクロヌドに倉曎を加えるこずなく、M8i-Flex むンスタンスを採甚できたす。 今すぐご利甚いただけたす Amazon EC2 M8i および M8i-Flex むンスタンスは、珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、欧州 (スペむン) の AWS リヌゞョン でご利甚いただけたす。M8i および M8i-Flex むンスタンスは、 オンデマンド 、 Savings Plan 、 スポットむンスタンス ずしお賌入できたす。M8i むンスタンスは、 ハヌドりェア専有むンスタンス および 専有ホスト での利甚も可胜です。詳现に぀いおは、 Amazon EC2 の料金ペヌゞ をご芧ください。 Amazon EC2 コン゜ヌル で M8i および M8i-Flex むンスタンスをお詊しください。詳现に぀いおは、 Amazon EC2 M8i むンスタンスのペヌゞ をご芧ください。たた、 AWS re:Post for EC2 に、たたは通垞の AWS サポヌトの連絡先を通じお、ぜひフィヌドバックをお寄せください。 – Channy 原文は こちら です。