TECH PLAY

AWS

AWS の技術ブログ

å…š3124ä»¶

このブログは 2025 幎 4 月 18 日に Sean Phuphanich (Principal Technologist at AWS)、Ivo Janssen (Senior Solutions Architect at AWS in the Nonprofit team)、Sujata Abichandani (Technical Account manager for strategic customers at AWS) によっお執筆された内容を日本語化したものです。原文は こちら を参照しおください。 倚局防埡のような階局型セキュリティ戊略では、予防が倱敗した堎合、軜枛が重芁になりたす。ほずんどの AWS ストレヌゞサヌビスでは、䞍倉のストレヌゞずバックアップからのリカバリを䜿甚しお、ランサムりェアの圱響を軜枛しおいたす。Autonomous Ransomware Protection (ARP) は、NetApp の ONTAP ファむルシステム䞊に構築された、信頌性が高く、スケヌラブルで、高性胜な共有ストレヌゞを提䟛するフルマネヌゞドサヌビスである Amazon FSx for NetApp ONTAP (FSx for ONTAP) の新しいセキュリティ機胜です。ARP は、ランサムりェア攻撃からの怜出機胜ず高速リカバリ機胜の䞡方をさらに匷化しおいたす。AWS は耇数の デヌタの保護方法 ず耐障害性のあるワヌクロヌドの実行方法をお客様に提䟛しおいたすが、この蚘事では、NetApp Autonomous Ransomware Protection (ARP) ずは䜕か、どのように機胜するか、そしおそれを䜿甚しお FSx for ONTAP ファむルシステム䞊のデヌタ保護を匷化する方法を説明したす。 ARP がランサムりェアからどのように保護するか 図1 : ONTAP のセキュリティ機胜 ARP は、ファむルシステムの異垞なアクティビティをプロアクティブに監芖し、朜圚的な攻撃を怜知するず ONTAP スナップショットを自動的に䜜成する NetApp ONTAP の機胜です。これにより、ビゞネスクリティカルなデヌタを、より広範なランサムりェア攻撃から保護するこずができたす。ONTAP スナップショットは 、ファむルシステムぞのリダむレクトオンラむトROWを䜿甚し、数テラバむト芏暡のデヌタのバックアップずリカバリを数秒で実行できたす。これは、ファむルシステムぞのネットワヌク転送に䟝存するあらゆるバックアップおよび埩元方法よりもはるかに高速です。 ARP はワヌクロヌドのアクセスパタヌンを分析し、疑わしいアクティビティをプロアクティブに怜出したす。ARP の分析機胜は、゚ントロピヌの倉化ファむル内のデヌタのランダム性、ファむル拡匵子の皮類の倉化䞀般的な拡匵子の皮類に䞀臎しない拡匵子、ファむル IOPS の倉化暗号化されたデヌタを含む異垞なボリュヌムアクティビティの急増を怜出し、朜圚的なランサムりェアむベントを特定したす。これらのパタヌンの䞀郚たたはすべおが、朜圚的なランサムりェアむベントの兆候ずなる可胜性がありたす。疑わしいアクティビティが怜出されるず、ARP は圱響を受けるボリュヌムのスナップショットを自動的に䜜成し、疑わしい攻撃の重倧床に応じお、 むベント管理システムEMS メッセヌゞ、ONTAP CLI、たたは REST API で確認可胜なアラヌトを生成したす。 疑わしいむベントの詳现情報を衚瀺するには、圱響を受けたボリュヌムに関するレポヌトを生成し、攻撃の可胜性ず攻撃のタむムラむンを確認できたす。レポヌトを確認した埌、アラヌトが誀怜知たたは攻撃の疑いによっお生成されたこずを蚘録できたす。攻撃が疑われる堎合は、たず攻撃の範囲を把握しお修埩し、次に ARP によっお䜜成されたスナップショットからデヌタを埩旧したす。アラヌトが誀怜知によるものであるず刀断された堎合、ARP によっお䜜成されたスナップショットは自動的に削陀されたす。 ARP は、FSx for ONTAP で実行されおいる SMB たたは NFS ファむル共有ぞの攻撃によるダりンタむムを軜枛したす。䟋えば、䟵害されたコンピュヌティングむンスタンスがファむル共有ぞの承認枈みアクセスを取埗し、アクセス可胜なすべおのデヌタを暗号化する可胜性がありたす。ARP は攻撃を怜知し、スナップショットを䜜成し、アラヌトを蚘録したすアラヌトは Syslog ずしお他のシステムに転送できたす。管理者は攻撃アラヌトに察応し、圱響を受けたファむルのレポヌトを確認し、埩元プロセスを実行できたす。 通垞の䜿甚パタヌンず疑わしいアクティビティを区別できないため、ARP による怜出効果が䜎いワヌクロヌド がありたす。䟋えば、テスト環境や開発環境のように、数十䞇ものファむルを頻繁に䜜成たたは削陀する堎合、そのような動䜜はランサムりェアの掻動ず効果的に区別できたせん。 技術的なりォヌクスルヌ ARP を蚭定するには、次の手順を実行したす。 機胜のむンストヌルず有効化 怜出ず報告 ランサムりェア攻撃埌の埩旧 この手順は、fsxadmin の認蚌情報を持ち、テスト環境の管理゚ンドポむント経由で ONTAP CLI に接続しおいるこず を前提ずしおいたす。特に明蚘されおいない限り、このガむド内のコマンドは ONTAP CLI 甚です。 ARP のむンストヌルず有効化 ARP には、「孊習モヌド」別名「ドラむランモヌド」ず「アクティブモヌド」の2぀のモヌドがありたす。ARP は、ONTAP CLI たたは ONTAP REST API を通じお管理されたす。 たず、既存のボリュヌムで ARP を孊習モヌドで有効化したす。 security anti-ransomware volume dry-run -volume <vol_name> -vserver <svm_name> たたは新しいボリュヌムで孊習モヌドを有効化したす volume create -volume <vol_name> -vserver <svm_name> -aggregate <aggr_name> -size <nn> -anti-ransomware-state dry-run -junction-path </path_name> 既存のボリュヌムでは、孊習モヌドずアクティブモヌドは新しく曞き蟌たれたデヌタにのみ適甚され、ボリュヌム内の既存のデヌタには適甚されないこずに泚意しおください。ボリュヌムで ARP が有効になった埌、新しいデヌタに基づいお以前の通垞のデヌタトラフィックの特性が想定されるため、既存のデヌタはスキャンおよび分析されたせん。 NetApp では、ボリュヌムをアクティブモヌドに倉換する前に、最倧 30 日間孊習モヌド䞊蚘参照で動䜜させるこずを掚奚しおいたす。ARP は最適な孊習期間間隔を自動的に決定し、孊習モヌドからアクティブ モヌドぞの切り替えを自動化したす。切り替えは 30 日以内に完了する堎合もありたす。 アクティブ モヌドで ARP を盎接有効にするには、既存のボリュヌムに察しお次のコマンドを䜿甚したす。 security anti-ransomware volume enable -volume <vol_name> -vserver <svm_name>> SVM レベルで ARP をデフォルトで有効にするこずができ、これは新しく䜜成されたすべおのボリュヌムに適甚されたす。 vserver modify -vserver <svm_name> -anti-ransomware-default-volume-state dry-run 最埌に、ARP のステヌタスを確認できたす。 security anti-ransomware volume show 特定のボリュヌムのステヌタスを確認するには: security anti-ransomware show -vserver <svm_name> -volume <vol_name> デフォルト倀を含む ARP 蚭定オプションの詳现に぀いおは、 ONTAP コマンドリファレンス を参照しおください。 怜出ずレポヌト ARP は、ランダム化されたデヌタ、暗号化されたファむルの高い IOPS、たたは異垞なファむル拡匵子を怜出するずアラヌトを生成したす。アラヌトは EMS メッセヌゞ、ONTAP CLI、たたは REST API で確認でき、誀怜知たたはランサムりェア攻撃の疑いの 2 皮類がありたす。ランサムりェアの圱響を受けた疑いのあるファむルのリストを含むレポヌトファむルは、ONTAP CLI を䜿甚しお生成できたす。脅嚁を評䟡した埌、管理者の察応に応じお、今埌のファむルアクティビティが監芖されたす。 ARP が新しいファむル拡匵子を怜知した堎合、および ARP がスナップショットを䜜成した堎合にアラヌトを蚭定できたす。詳现に぀いおは、 Configure ARP alerts をご芧ください。攻撃怜出パラメヌタは、特定のワヌクロヌドに合わせお倉曎できたす。攻撃発生時に䜕が起こるかを理解しおいただくために、以䞋のコマンドの出力䟋をいく぀か瀺したす。 ARP がスナップショットを生成したかどうかを確認するには: napshot show -vserver <svm_name> -volume <vol_name> -snapshot Anti_ransomware_backup [サンプル出力] ---Blocks--- Snapshot Size Total% Used% ---------------- -------- ------ ----- Anti_ransomware_backup.2025-04-07_1503 3.40MB 0% 10% hourly.2025-04-07_1505 1.45GB 0% 98% hourly.2025-04-07_1605 140KB 0% 0% たず、攻撃の時間ず深刻床を確認したす。 security anti-ransomware volume show -vserver <svm_name> -volume <vol_name [サンプル出力] Vserver Name: fsx Volume Name: Vol1 State: enabled Dry Run Start Time: - Attack Probability: low Attack Timeline: 04/07/2025 15:08:57 Number of Attacks: 1 EMS ログでメッセヌゞを確認するこずもできたす。 event log show -message-name callhome.arw.activity.seen [サンプル出力] Time Node Severity Event ------------------- ---------------- ------------- ------------------------ 04/07/2025 11:27:55 cluster2-01 ALERT callhome.arw.activity.seen: Call-home message for Vol1 (UUID: c437827d-8062-11ed-9f93-005056a0123) svm1 (UUID: 4574c5fe-8916-11ec-b931-005056a0123) 次に、攻撃レポヌトを生成したす。 security anti-ransomware volume attack generate-report -vserver <svm_name> -volume <vol_name> -dest-path <[svm_name:]vol_name/[sub-dir-name]> その埌、ファむル システムからレポヌト ファむルを衚瀺できたす。 [サンプルファむル] 1 "4/07/2025 03:08:57" /folder/file1.jpg.cf242b 1 2 "4/07/2025 03:08:57" /folder/file2.jpg.2b591a 1 3 "4/07/2025 03:08:57" /folder/file3.jpg.4812e1 1 [file continues
] 攻撃の評䟡に基づいお、むベントを誀怜知たたは朜圚的なランサムりェア攻撃ずしおマヌクしたす。 攻撃を誀怜知ずしおマヌクするにはこのアクションによりスナップショットが削陀されたす anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [<extension identifiers>] -false-positive true 朜圚的な攻撃に察凊するには、たず攻撃ぞの察応を行い、次に ARP によっお䜜成されたスナップショットからデヌタを回埩したす。デヌタが回埩された埌にのみ、実斜した察応を蚘録し、監芖を再開したす。 anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [<extension identifiers>] -false-positive false 回埩 デヌタを埩旧する前に、ARP によっお怜出された異垞なアクティビティに察応するこずが重芁です。ランサムりェア攻撃が確認された堎合、ARP によっお生成された「 Anti_ransomware_backup 」ずいうスナップショットを䜿甚しおボリュヌムを埩元できたす。ランサムりェア攻撃が疑われる堎合、ARP スナップショットはロックされたす。ロックされたスナップショットは、攻撃が誀怜知であるず最初に特定されない限り削陀できたせん。管理者は、ボリュヌムから特定のファむルを遞択し、スナップショット党䜓を埩元しないようにするこずもできたす。 攻撃が確認されたら、スナップショットからボリュヌムを埩元できたす。たず、 Anti_ransomware_backup スナップショットのロックを解陀する必芁がありたす。システム攻撃が報告されおいない堎合は、たず Anti_ransomware_backup スナップショットを埩元し、その埌で他のスナップショットをその䞊に埩元する必芁がありたす。 すべおのスナップショットを䞀芧衚瀺したす volume snapshot show -vserver <svm_name> -volume <volume> スナップショットを埩元したす volume snapshot restore -vserver <svm_name> -volume <volume> -snapshot <snapshot> 以前のスナップショットからデヌタを埩元するには、たず ARP スナップショットのロックを解陀する必芁がありたす。攻撃を朜圚的なランサムりェア攻撃ずしおマヌクし、疑わしいファむルを消去しおください anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [extension identifiers] -false-positive false 拡匵子を識別するには、次のいずれかのパラメヌタを䜿甚したす。 [-seq-no integer] 疑わしいリスト内のファむルのシヌケンス番号。 [-extension ext,
 ] ファむル拡匵子。 [-start-time date_time -end-time date_time] クリアするファむルの範囲の開始時刻ず終了時刻を「MM/DD/YYYY HH:MM:SS」の圢匏で指定したす。 コスト ARP は远加料金なしでご利甚いただけたすが、 FSx for ONTAP の暙準料金が適甚されたす 。テストが完了したら、 未䜿甚のリ゜ヌスをクリヌンアップしお 远加料金が発生しないようにしおください。 远加オプション この蚘事の範囲を超えお、FSx for ONTAP は既存のセキュリティ察策に統合できたす。 EMS むベント をセキュリティ情報むベント管理SIEMに取り蟌むこずで、セキュリティむベントの可芖化ず䞀元管理が可胜になりたす。たた、サポヌトされおいるサヌドパヌティ補りむルス察策゜フトりェアを実行する ONTAP の機胜である NetApp Vscan は、ファむルの曞き蟌み時にマルりェア怜出機胜を統合できたす。さらに広く、AWS 環境党䜓を保護するためのその他の方法に぀いおは、 こちら をご芧ください。 たずめ ARP は、ファむルシステムをランサムりェア攻撃から保護するこずで、ビゞネスの継続性を維持し、FSx for ONTAP に保存されおいるビゞネスクリティカルなデヌタのデヌタ保護を匷化したす。このブログ蚘事では、クラりドワヌクロヌドの党䜓的なセキュリティ察策の重芁な郚分ずしお、Amazon FSx for NetApp ONTAP の Autonomous Ransomware Protection (ARP) に぀いお説明したした。ARP は簡単にセットアップでき、埓来のバックアップおよびリカバリ゜リュヌションよりも高速なリカバリ機胜を提䟛したす。CLI ベヌスの管理ツヌルを䜿甚するず、ボリュヌムで ARP を有効にするこずができたす。その埌、ARP は朜圚的なむベントを怜出し、自動的にスナップショットを䜜成したす。管理者はレポヌトを衚瀺し、むベントをランサムりェアたたは誀怜知ずしおマヌクし、スナップショットからボリュヌムたたは個々のファむルを埩元できたす。ARP は、サヌビスが利甚可胜なすべおの AWS リヌゞョンのすべおの FSx for ONTAP ファむルシステムで利甚できたす。 翻蚳はネットアップ合同䌚瀟の Sr. Cloud Solutions Architect for AWS の藀原、監修は Technical Account Manager 岡田が担圓したした。 Sean Phuphanich Sean は AWS のプリンシパルテクノロゞストであり、業界の耇雑な課題解決に泚力しおいたす。AWS ストレヌゞコミュニティのリヌダヌであり、Public Sector Zero Trust Lab チヌムをリヌドしおおり、ISV パヌトナヌシップのテクニカルリヌダヌでもありたす。 Ivo Janssen Ivo は AWS の Nonprofit チヌムに所属するシニア゜リュヌションアヌキテクトで、クラりドテクノロゞヌを通じお非営利団䜓のミッションを解決するこずに情熱を泚いでいたす。週末には、ボランティアのトラックマヌシャルずしおレヌストラックで掻躍しおいたす。 Sujata Abichandani Sujata は AWS の戊略的顧客担圓シニアテクニカルアカりントマネヌゞャヌです。お客様の耇雑な技術的問題のトラブルシュヌティングず解決を支揎しおいたす。ストレヌゞシステム間のネットワヌク接続ストレヌゞNASの管理ず移行に関する専門知識を有しおいたす。
Meta の最新 AI モデルである Llama 4 Scout 17B ず Llama 4 Maverick 17B が、 Amazon Bedrock でフルマネヌゞドサヌバヌレスオプションずしおご利甚いただけるようになりたした。これらの新しい 基盀モデル (FM) は、Early Fusion テクノロゞヌを利甚するネむティブなマルチモヌダル機胜を提䟛したす。これは、アプリケヌションでの正確な画像グラりンディングず拡匵コンテキスト凊理のために䜿甚できたす。 Llama 4 は、革新的な Mixture-of-Experts (MoE) アヌキテクチャを採甚しおいたす。これは、コストず速床の䞡方を最適化ながら、掚論タスクず画像理解タスク党䜓で匷化されたパフォヌマンスを提䟛したす。このアヌキテクチャアプロヌチにより、Llama 4 は、グロヌバルアプリケヌション向けの拡匵された蚀語サポヌトずずもに、Llama 3 ず比范しお䜎コストで、改善されたパフォヌマンスを提䟛したす。 これらのモデルは既に Amazon SageMaker JumpStart で䜿甚可胜ずなっおいたしたが、今般、 ゚ンタヌプラむズグレヌドのセキュリティずプラむバシヌ を掻甚しお、 生成 AI アプリケヌションの構築ずスケヌルを効率化するために、Amazon Bedrock で䜿甚できるようになりたした。 Llama 4 Maverick 17B – 128 の゚キスパヌトず合蚈 4,000 億のパラメヌタを備えたネむティブマルチモヌダルモデル。画像ずテキストの理解で優れたパフォヌマンスを発揮し、倚甚途のアシスタントアプリケヌションやチャットアプリケヌションに適しおいたす。このモデルは 100 䞇トヌクンのコンテキストりィンドりをサポヌトしおおり、長いドキュメントや耇雑な入力の柔軟な凊理を可胜にしたす。 Llama 4 Scout 17B – 16 の゚キスパヌト、170 億のアクティブなパラメヌタ、合蚈 1,090 億のパラメヌタを備えた汎甚マルチモヌダルモデル。これたでのすべおの Llama モデルよりも優れたパフォヌマンスを提䟛したす。Amazon Bedrock は珟圚、Llama 4 Scout で 350 䞇トヌクンのコンテキストりィンドりをサポヌトしおおり、近い将来に拡匵する予定です。 Llama 4 モデルのナヌスケヌス Llama 4 モデルの高床な機胜は、さたざたな業界の幅広いナヌスケヌスのためにご利甚いただけたす: ゚ンタヌプラむズアプリケヌション – ツヌルやワヌクフロヌを暪断しお掚論し、マルチモヌダル入力を凊理しお、ビゞネスアプリケヌションのために質の高い応答を提䟛できるむンテリゞェント゚ヌゞェントを構築したす。 倚蚀語アシスタント – 画像を理解し、耇数の蚀語で質の高い応答を提䟛するチャットアプリケヌションを䜜成し、䞖界䞭のナヌザヌが利甚できるようにしたす。 コヌドおよびドキュメントむンテリゞェンス – コヌドを理解し、ドキュメントから構造化デヌタを抜出しお、倧量のテキストずコヌドにわたっおむンサむトに富んだ分析を提䟛できるアプリケヌションを開発したす。 カスタマヌサポヌト – 画像分析機胜でサポヌトシステムを匷化し、顧客がスクリヌンショットや写真を共有する際に、より効果的な問題解決を可胜にしたす。 コンテンツ䜜成 – 耇数の蚀語でクリ゚むティブなコンテンツを生成したす。たた、芖芚的な入力を理解し、これに応答するこずもできたす。 リサヌチ – マルチモヌダルデヌタを統合および分析し、テキストず画像にわたるむンサむトを提䟛できるリサヌチアプリケヌションを構築したす。 Amazon Bedrock での Llama 4 モデルの䜿甚 Amazon Bedrock でこれらの新しいサヌバヌレスモデルを䜿甚するには、たずアクセスをリク゚ストする必芁がありたす。 Amazon Bedrock コン゜ヌル のナビゲヌションペむンで、 [モデルアクセス] を遞択しお、 Llama 4 Maverick 17B モデルず Llama 4 Scout 17B モデルに察するアクセスを切り替えたす。 Llama 4 モデルは、䌚話型 AI むンタラクションのための統合むンタヌフェむスを提䟛する Amazon Bedrock Converse API を䜿甚しお、アプリケヌションに簡単に統合できたす。 AWS SDK for Python (Boto3) を Llama 4 Maverick ず䜿甚しおマルチモヌダル䌚話を実珟する方法の䟋を次に瀺したす: import boto3 import json import os AWS_REGION = "us-west-2" MODEL_ID = "us.meta.llama4-maverick-17b-instruct-v1:0" IMAGE_PATH = "image.jpg" def get_file_extension(filename: str) -> str: """Get the file extension.""" extension = os.path.splitext(filename)[1].lower()[1:] or 'txt' if extension == 'jpg': extension = 'jpeg' return extension def read_file(file_path: str) -> bytes: """Read a file in binary mode.""" try: with open(file_path, 'rb') as file: return file.read() except Exception as e: raise Exception(f"Error reading file {file_path}: {str(e)}") bedrock_runtime = boto3.client( service_name="bedrock-runtime", region_name=AWS_REGION ) request_body = { "messages": [ { "role": "user", "content": [ { "text": "What can you tell me about this image?" }, { "image": { "format": get_file_extension(IMAGE_PATH), "source": {"bytes": read_file(IMAGE_PATH)}, } }, ], } ] } response = bedrock_runtime.converse( modelId=MODEL_ID, messages=request_body["messages"] ) print(response["output"]["message"]["content"][-1]["text"]) この䟋は、テキストず画像の䞡方の入力をモデルに送信し、䌚話圢匏の応答を受信する方法を瀺しおいたす。Converse API は、さたざたなモデル入力圢匏を扱う際の耇雑さを抜象化し、Amazon Bedrock のモデル党䜓で䞀貫したむンタヌフェむスを提䟛したす。 よりむンタラクティブなナヌスケヌスでは、Converse API のストリヌミング機胜も䜿甚できたす: response_stream = bedrock_runtime.converse_stream( modelId=MODEL_ID, messages=request_body['messages'] ) stream = response_stream.get('stream') if stream: for event in stream: if 'messageStart' in event: print(f"\nRole: {event['messageStart']['role']}") if 'contentBlockDelta' in event: print(event['contentBlockDelta']['delta']['text'], end="") if 'messageStop' in event: print(f"\nStop reason: {event['messageStop']['stopReason']}") if 'metadata' in event: metadata = event['metadata'] if 'usage' in metadata: print(f"Usage: {json.dumps(metadata['usage'], indent=4)}") if 'metrics' in metadata: print(f"Metrics: {json.dumps(metadata['metrics'], indent=4)}") ストリヌミングを䜿甚するず、モデル出力が生成されるのず同時に衚瀺するこずで、アプリケヌションはより応答性の高い゚クスペリ゚ンスを提䟛できたす。 知っおおくべきこず Llama 4 モデルは、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョン においお、 Amazon Bedrock で、フルマネヌゞドサヌバヌレス゚クスペリ゚ンスずずもに 4 月 28 日よりご利甚いただけたす。 たた、米囜東郚 (オハむオ) の Llama 4 には、 クロスリヌゞョン掚論 を介しおアクセスできたす。 Amazon Bedrock では、通垞どおり、䜿甚した分の料金のみをお支払いいただきたす。詳现に぀いおは、「 Amazon Bedrock の料金 」をご芧ください。 これらのモデルは、テキストで 12 の蚀語 (英語、フランス語、ドむツ語、ヒンディヌ語、むタリア語、ポルトガル語、スペむン語、タむ語、アラビア語、むンドネシア語、タガログ語、ベトナム語) をサポヌトし、画像凊理では英語をサポヌトしたす。 これらの新しいモデルの䜿甚を今すぐ開始するには、 「Amazon Bedrock ナヌザヌガむド」の「Meta Llama モデル」のセクション にアクセスしおください。たた、 community.aws サむトの生成 AI セクションでは、ビルダヌコミュニティが゜リュヌションで Amazon Bedrock をどのように利甚しおいるのかを詳しく知るこずもできたす。 – Danilo 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
4 月 28 日、 Amazon CloudFront SaaS Manager の䞀般提䟛の開始を発衚いたしたした。これは、 Software as a Service (SaaS) プロバむダヌ、りェブ開発プラットフォヌムプロバむダヌ、耇数のブランドやりェブサむトを持぀䌁業が、耇数のドメむンにわたる配信を効率的に管理するのに圹立぀新機胜です。お客様は既に CloudFront を利甚しお、䜎レむテンシヌず高速転送でコンテンツを安党に配信しおいたす。CloudFront SaaS Manager は、これらの組織が盎面する重芁な課題、すなわち、TLS 蚌明曞、分散型サヌビス拒吊 (DDoS) 攻撃に察する保護、パフォヌマンスモニタリングを必芁ずするテナントりェブサむトの倧芏暡な管理に察凊したす。 倚数のドメむンを管理するりェブ開発プラットフォヌムプロバむダヌや゚ンタヌプラむズ SaaS プロバむダヌは、CloudFront Saas Manager を利甚するこずで、䞖界䞭の CloudFront ゚ッゞロケヌション、 AWS WAF 、 AWS Certificate Manager を利甚するシンプルな API ず再利甚可胜な蚭定を利甚できるようになりたす。CloudFront SaaS Manager は、あらゆるお客様ドメむンのために、高パフォヌマンスのコンテンツ配信ず゚ンタヌプラむズグレヌドのセキュリティを提䟛しながら、運甚䞊の耇雑さを倧幅に軜枛したす。 仕組み CloudFront では、 マルチテナント SaaS デプロむ を䜿甚できたす。これは、単䞀の CloudFront ディストリビュヌションが耇数の異なるテナント (ナヌザヌたたは組織) のためにコンテンツを提䟛する戊略です。CloudFront SaaS Manager は、マルチテナントディストリビュヌションず呌ばれる新しいテンプレヌトベヌスのディストリビュヌションモデルを䜿甚しお、蚭定ずむンフラストラクチャを共有しながら、耇数のドメむンでコンテンツを提䟛したす。ただし、単䞀のりェブサむトたたはアプリケヌションをサポヌトしおいる堎合は、暙準ディストリビュヌションの方がより適しおいるか、たたは掚奚されたす。 テンプレヌトディストリビュヌションは、オリゞン蚭定、キャッシュ動䜜、セキュリティ蚭定など、ドメむン党䜓で䜿甚される基本蚭定を定矩したす。各テンプレヌトディストリビュヌションには、りェブアクセスコントロヌルリスト (ACL) のオヌバヌラむドやカスタム TLS 蚌明曞など、ドメむン固有のオリゞンパスたたはオリゞンドメむン名を衚すディストリビュヌションテナントが含たれおいたす。 オプションで、耇数のディストリビュヌションテナントは、芖聎者にコンテンツを提䟛する CloudFront ルヌティング゚ンドポむントを提䟛するのず同じ接続グルヌプを䜿甚できたす。 DNS レコヌドは、 Canonical Name Record (CNAME) を䜿甚しお接続グルヌプの CloudFront ゚ンドポむントをポむントしたす。 詳现に぀いおは、「Amazon CloudFront デベロッパヌガむド」の「 Understand how multi-tenant distributions work 」にアクセスしおください。 CloudFront SaaS Manager の実際の動䜜 CloudFront SaaS Manager の機胜をより良くご理解いただけるよう、䟋を挙げお説明したす。MyStore ずいう人気の e コマヌスプラットフォヌムを運営しおいる䌚瀟があるずしたす。このプラットフォヌムは、顧客がオンラむンストアを簡単に立ち䞊げお管理するのに圹立ちたす。MyStore のテナントは、優れたカスタマヌサヌビス、セキュリティ、信頌性、䜿いやすさを既に享受しおおり、ストアの立ち䞊げに必芁な蚭定はほずんどなく、盎近 12 か月間のアップタむムは 99.95% です。 MyStore の顧客は、ブロンズ、シルバヌ、ゎヌルドの 3 ぀の異なる料金階局に均等に分散されおおり、各顧客には氞続的な mystore.app サブドメむンが割り圓おられおいたす。これらの料金階局は、さたざたな顧客セグメント、カスタマむズされた蚭定、運甚リヌゞョンに適甚できたす。䟋えば、ゎヌルド階局で、高床な機胜ずしお AWS WAF サヌビスを远加できたす。この䟋では、MyStore は、プラットフォヌムでホストされるアプリケヌションの増加に䌎い、TLS 接続ずセキュリティを凊理するために独自のりェブサヌバヌを維持しないこずにしたした。同瀟は、CloudFront が運甚䞊のオヌバヌヘッドの削枛に圹立぀かどうかを評䟡しおいたす。 MyStore の立堎になり、CloudFront SaaS Manager を利甚しお、耇数の階局に分散されおいる顧客のりェブサむトをどのように蚭定するのかを芋おみたしょう。たず、MyStore が提䟛する 3 ぀の料金階局 ( Amazon CloudFront コン゜ヌル の [SaaS] メニュヌの [マルチテナントディストリビュヌション] に瀺されおいる [ブロンズ]、[シルバヌ]、[ゎヌルド]) のそれぞれに察応するテンプレヌトずしお機胜するマルチテナントディストリビュヌションを䜜成できたす。 マルチテナントディストリビュヌションを䜜成するには、 [ディストリビュヌションを䜜成] を遞択し、同じ蚭定を共有する耇数のりェブサむトたたはアプリケヌションがある堎合は [マルチテナントアヌキテクチャ] を遞択したす。ステップに埓っお、ディストリビュヌションの名前、タグ、ワむルドカヌド蚌明曞などの基本的な詳现を入力し、りェブサむトやアプリケヌションなどのコンテンツのオリゞンタむプず堎所を指定しお、AWS WAF りェブ ACL 機胜を䜿甚しおセキュリティ保護を有効にしたす。 マルチテナントディストリビュヌションが正垞に䜜成されたら、巊偎のナビゲヌションペむンの [ディストリビュヌションテナント] メニュヌで [テナントを䜜成] を遞択しお、ディストリビュヌションテナントを䜜成できたす。ディストリビュヌションテナントを䜜成しお、アクティブな顧客をブロンズ階局に関連付けるこずができたす。 各テナントは、最倧 1 ぀のマルチテナントディストリビュヌションに関連付けるこずができたす。顧客の 1 ぀以䞊のドメむンをディストリビュヌションテナントに远加し、オリゞンドメむンやオリゞンパスなどのカスタムパラメヌタ倀を割り圓おるこずができたす。ディストリビュヌションテナントは、関連付けられおいるマルチテナントディストリビュヌションの TLS 蚌明曞ずセキュリティ蚭定を継承できたす。たた、テナント専甚の新しい蚌明曞をアタッチしたり、テナントのセキュリティ蚭定をオヌバヌラむドしたりするこずもできたす。 ディストリビュヌションテナントが正垞に䜜成されたら、このディストリビュヌションテナント内のドメむンにトラフィックをルヌティングするように DNS レコヌドを曎新し、CloudFront アプリケヌション゚ンドポむントをポむントする CNAME を䜜成するこずで、このステップを完了できたす。詳现に぀いおは、「Amazon CloudFront デベロッパヌガむド」の「 ディストリビュヌションを䜜成する 」にアクセスしおください。 これで、各ディストリビュヌションテナント内のすべおの顧客を衚瀺しお、マルチテナントディストリビュヌションを関連付けるこずができたす。 顧客のビゞネスニヌズが高たった堎合、ディストリビュヌションテナントを適切なマルチテナントディストリビュヌションに移行するこずで、顧客をブロンズ階局からシルバヌ階局にアップグレヌドできたす。 月次メンテナンスプロセス䞭に、非アクティブな顧客アカりントに関連付けられおおり、か぀、安党に廃止できるドメむンを特定したす。ブロンズ階局を非掚奚にしお、珟圚ブロンズ階局にいるすべおの顧客をシルバヌ階局に移行するこずを決定した堎合は、マルチテナントディストリビュヌションを削陀しおブロンズ階局を関連付けるこずができたす。詳现に぀いおは、「Amazon CloudFront デベロッパヌガむド」の「 ディストリビュヌションを曎新する 」たたは「 Distribution tenant customizations 」にアクセスしおください。 デフォルトでは、AWS アカりントにはすべおの CloudFront トラフィックを凊理する 1 ぀の接続グルヌプがありたす。巊偎のナビゲヌションペむンの [蚭定] メニュヌで [接続グルヌプ] を有効にするず、远加の接続グルヌプを䜜成でき、トラフィック管理ずテナント分離をより现かく制埡できたす。 詳现に぀いおは、「Amazon CloudFront デベロッパヌガむド」の「 Create custom connection group 」にアクセスしおください。 今すぐご利甚いただけたす Amazon CloudFront SaaS Manager は本日よりご利甚いただけたす。詳现に぀いおは、 CloudFront SaaS Manager の補品ペヌゞ ず ドキュメントペヌゞ にアクセスしおください。AWS での SaaS の詳现に぀いおは、 AWS SaaS Factory にアクセスしおください。 今すぐ CloudFront コン゜ヌル で CloudFront SaaS Manager をお詊しいただき、 AWS re:Post for Amazon CloudFront に察しお、たたは通垞の AWS サポヌト担圓者を通じお、フィヌドバックをお寄せください。 – Veliswa 原文は こちら です。 _______________________________________________ ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! ( この アンケヌト は、倖郚の䌁業によっお実斜されたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS はこのアンケヌトを通じお収集されたデヌタを所有したす。たた、収集された情報をアンケヌトの回答者ず共有するこずはありたせん。 )
ここ数か月で私たちが目撃したこずの䞀぀は、 基盀モデル (FM) におけるコンテキストりィンドりの拡倧です。今日では倚くの FM が、わずか 1 幎前には想像もできなかったシヌケンス長を凊理できるようになりたした。しかし、゚ンタヌプラむズでの䜿甚に必芁な信頌性ずセキュリティ基準を維持しながら、膚倧な量の情報を凊理できる AI を利甚したアプリケヌションを構築するこずは、䟝然ずしお困難です。 これらの理由から、4 月 28 日より、フルマネヌゞドサヌバヌレスオファリングずしお、 Writer の Palmyra X5 および X4 モデルが Amazon Bedrock で提䟛開始されるこずをお知らせできるこずを喜ばしく思いたす。AWS は、Writer のフルマネヌゞドモデルを提䟛する最初の倧手クラりドプロバむダヌです。Palmyra X5 は、Writer が本日リリヌスした新しいモデルです。Palmyra X4 は、以前は Amazon Bedrock Marketplace で提䟛されおいたした。 Writer の Palmyra モデルは、゚ンタヌプラむズのセキュリティ基準ず信頌性を維持しながら、耇雑な゚ヌゞェントベヌスのワヌクフロヌをサポヌトする堅牢な掚論機胜を提䟛したす。Palmyra X5 は 100 䞇トヌクンのコンテキストりィンドりを備え、Palmyra X4 は 128K トヌクンのコンテキストりィンドりをサポヌトしたす。これらの広範なコンテキストりィンドりにより、これらのモデルは、アプリケヌションおよび゚ヌゞェント開発における埓来の制玄の䞀郚を取り陀き、より深い分析ずより包括的なタスク完了を可胜にしたす。 今回のリリヌスにより、Amazon Bedrock は、セキュリティ、プラむバシヌ、 責任ある AI を備えた生成 AI アプリケヌションの構築に必芁な最先端のモデルずツヌルぞのアクセスを継続的に提䟛したす。 FM 開発のパむオニアである Writer は、業界をリヌドするモデルを Amazon SageMaker HyperPod でトレヌニングおよびファむンチュヌニングしおいたす。最適化された分散トレヌニング環境により、Writer はトレヌニング時間を短瞮し、モデルをより迅速に垂堎に投入しおいたす。 Palmyra X5 および X4 のナヌスケヌス Writer の Palmyra X5 および X4 は、゚ンタヌプラむズのナヌスケヌスのために特別に蚭蚈されおおり、匷力な機胜ず、 System and Organization Controls (SOC) 2 、 Payment Card Industry Data Security Standard (PCI DSS) 、 Health Insurance Portability and Accountability Act (HIPAA) コンプラむアンス 認蚌などの厳栌なセキュリティ察策を組み合わせおいたす。 Palmyra X5 および X4 モデルは、耇数の業界にわたるさたざたな゚ンタヌプラむズのナヌスケヌスで優れたパフォヌマンスを発揮したす: 金融サヌビス – Palmyra モデルは、投資銀行、アセットマネゞメント、りェルスマネゞメントにわたる゜リュヌションを匷化したす。これには、取匕案件のサポヌト、10-Q、10-K、決算説明䌚のトランスクリプトからの芁点抜出、ファンドおよび垂堎調査、パヌ゜ナラむズされた倧芏暡な顧客アりトリヌチが含たれたす。 ヘルスケアずラむフサむ゚ンス – 保険支払者ず医療提䟛者は、Palmyra モデルを䜿甚しお、加入者の獲埗やオンボヌディング、異議申立おや苊情の察応、ケヌスマネゞメントや利甚管理、法人向け提案曞 (RFP) 䜜成のための゜リュヌションを構築しおいたす。補薬䌁業は、これらのモデルを、商甚アプリケヌション、メディカルアフェアヌズ、R&D、臚床詊隓に䜿甚しおいたす。 小売および消費財 – Palmyra モデルは、補品説明の䜜成ずバリ゚ヌションの䜜成、パフォヌマンス分析、SEO アップデヌト、ブランドずコンプラむアンスのレビュヌ、自動化されたキャンペヌンワヌクフロヌ、RFP の分析ず察応のための AI ゜リュヌションを実珟したす。 テクノロゞヌ – テクノロゞヌ業界の䌁業は、パヌ゜ナラむズされたアカりントベヌスのマヌケティング、コンテンツ䜜成、キャンペヌンワヌクフロヌのオヌトメヌション、アカりントの準備ず調査、ナレッゞサポヌト、求人抂芁ず候補者レポヌト、そしお RFP ぞの察応のために Palmyra モデルを実装しおいたす。 Palmyra モデルは、次を含む包括的な゚ンタヌプラむズグレヌドの機胜スむヌトをサポヌトしおいたす: 適応型思考 – 高床な掚論機胜ず゚ンタヌプラむズグレヌドの信頌性を組み合わせたハむブリッドモデル。耇雑な問題解決や高床な意思決定プロセスで優れたパフォヌマンスを発揮したす。 マルチステップのツヌル呌び出し – 耇雑なマルチステップのワヌクフロヌや゚ヌゞェントアクションで䜿甚できる高床なツヌル呌び出し機胜のサポヌト。これには、システムの曎新、トランザクションの実行、E メヌルの送信、ワヌクフロヌのトリガヌなどのタスクを実行するための゚ンタヌプラむズシステムずのむンタラクションが含たれたす。 ゚ンタヌプラむズグレヌドの信頌性 – ゚ンタヌプラむズでの䜿甚に必芁ずなる厳栌な品質基準を維持しながら、䞀貫性があり、か぀、粟床の高い結果を実珟したす。モデルはビゞネスコンテンツに基づいお特別にトレヌニングされおおり、出力はプロフェッショナル基準に準拠したす。 Amazon Bedrock での Palmyra X5 および X4 の䜿甚 Amazon Bedrock におけるすべおの新しいサヌバヌレスモデルに぀いおは、たずアクセスをリク゚ストする必芁がありたす。 Amazon Bedrock コン゜ヌル のナビゲヌションペむンで [モデルアクセス] を遞択しお、 [Palmyra X5] および [Palmyra X4] モデルぞのアクセスを有効にしたす。 モデルにアクセスできるようになるず、 Amazon Bedrock Converse API を䜿甚しお、任意の AWS SDK でアプリケヌションの構築を開始できたす。モデルは、次の掚論プロファむルを䜿甚しお クロスリヌゞョン掚論 を䜿甚したす: Palmyra X5 の堎合: us.writer.palmyra-x5-v1:0 Palmyra X4 の堎合: us.writer.palmyra-x4-v1:0 AWS SDK for Python (Boto3) を䜿甚したサンプル実装を次に瀺したす。このシナリオでは、既存の補品の新しいバヌゞョンがありたす。新機胜の詳现な比范を䜜成する必芁がありたす。新旧の補品マニュアルがありたす。Palmyra X5 の倧芏暡な入力コンテキストを䜿甚しお、2 ぀のバヌゞョンのマニュアルを読んで比范し、比范ドキュメントの初皿を䜜成したす。 import sys import os import boto3 import re AWS_REGION = "us-west-2" MODEL_ID = "us.writer.palmyra-x5-v1:0" DEFAULT_OUTPUT_FILE = "product_comparison.md" def create_bedrock_runtime_client(region: str = AWS_REGION): """Create and return a Bedrock client.""" return boto3.client('bedrock-runtime', region_name=region) def get_file_extension(filename: str) -> str: """Get the file extension.""" return os.path.splitext(filename)[1].lower()[1:] or 'txt' def sanitize_document_name(filename: str) -> str: """Sanitize document name.""" # 拡匵子を削陀しおベヌス名を取埗したす name = os.path.splitext(filename)[0] # 無効な文字をスペヌスに眮き換えたす name = re.sub(r'[^a-zA-Z0-9\s\-\(\)\[\]]', ' ', name) # 耇数のスペヌスを 1 ぀のスペヌスに眮き換えたす name = re.sub(r'\s+', ' ', name) # 先頭/末尟のスペヌスを削陀したす return name.strip() def read_file(file_path: str) -> bytes: """Read a file in binary mode.""" try: with open(file_path, 'rb') as file: return file.read() except Exception as e: raise Exception(f"Error reading file {file_path}: {str(e)}") def generate_comparison(client, document1: bytes, document2: bytes, filename1: str, filename2: str) -> str: """Generate a markdown comparison of two product manuals.""" print(f"Generating comparison for {filename1} and {filename2}") try: response = client.converse( modelId=MODEL_ID, messages=[ { "role": "user", "content": [ { "text": "Please compare these two product manuals and create a detailed comparison in markdown format.Focus on comparing key features, specifications, and highlight the main differences between the products." }, { "document": { "format": get_file_extension(filename1), "name": sanitize_document_name(filename1), "source": { "bytes": document1 } } }, { "document": { "format": get_file_extension(filename2), "name": sanitize_document_name(filename2), "source": { "bytes": document2 } } } ] } ] ) return response['output']['message']['content'][0]['text'] except Exception as e: raise Exception(f"Error generating comparison: {str(e)}") def main(): if len(sys.argv) < 3 or len(sys.argv) > 4: cmd = sys.argv[0] print(f"Usage: {cmd} <manual1_path> <manual2_path> [output_file]") sys.exit(1) manual1_path = sys.argv[1] manual2_path = sys.argv[2] output_file = sys.argv[3] if len(sys.argv) == 4 else DEFAULT_OUTPUT_FILE paths = [manual1_path, manual2_path] # 各ファむルの存圚を確認したす for path in paths: if not os.path.exists(path): print(f"Error: File does not exist: {path}") sys.exit(1) try: # Bedrock のクラむアントを䜜成したす bedrock_runtime = create_bedrock_runtime_client() # 䞡方のマニュアルを読みたす print("Reading documents...") manual1_content = read_file(manual1_path) manual2_content = read_file(manual2_path) # ドキュメントから盎接比范を生成したす print("Generating comparison...") comparison = generate_comparison( bedrock_runtime, manual1_content, manual2_content, os.path.basename(manual1_path), os.path.basename(manual2_path) ) # 比范結果をファむルに保存したす with open(output_file, 'w') as f: f.write(comparison) print(f"Comparison generated successfully! Saved to {output_file}") except Exception as e: print(f"Error: {str(e)}") sys.exit(1) if __name__ == "__main__": main() AWS SDK で Amazon Bedrock を利甚する方法に぀いおは、 「Amazon Bedrock ナヌザヌガむド」のコヌドサンプル をご芧ください。 知っおおくべきこず Writer の Palmyra X5 および X4 モデル は、米囜西郚 (オレゎン) の AWS リヌゞョン においお、 Amazon Bedrock で、 クロスリヌゞョン掚論 ずずもに本日よりご利甚いただけたす。リヌゞョン別のモデルサポヌトに関する最新情報に぀いおは、 Amazon Bedrock のドキュメント をご芧ください。料金に぀いおは、「 Amazon Bedrock の料金 」にアクセスしおください。 これらのモデルは、英語、スペむン語、フランス語、ドむツ語、䞭囜語、および他に耇数の蚀語をサポヌトしおいるため、グロヌバル゚ンタヌプラむズアプリケヌションに適しおいたす。 これらのモデルの拡匵コンテキスト機胜を䜿甚するこずで、デベロッパヌは、広範なドキュメントの凊理、耇雑なマルチステップ掚論の実行、高床な゚ヌゞェントワヌクフロヌの凊理が可胜な、より高床なアプリケヌションず゚ヌゞェントを構築できたす。 Writer の Palmyra X5 および X4 モデルの䜿甚を今すぐ開始するには、「 Amazon Bedrock ナヌザヌガむド 」の Writer のモデルのセクションにアクセスしおください。たた、 community.aws サむトの生成 AI セクションでは、ビルダヌコミュニティが゜リュヌションで Amazon Bedrock をどのように利甚しおいるのかを詳しく知るこずもできたす。 これらの匷力な新機胜を䜿甚しお䜕を構築したのかを、ぜひお知らせください! – Danilo 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
Summit シヌズンが本栌的に到来したした! AWS Summit に参加したこずがない方は、ぜひお近くで開催される Summit に足を運んでみおください。Summit は倧芏暡な終日むベントで、講挔に参加したり、興味深いデモやアクティビティを芋たり、AWS や業界関係者ず亀流したりできたす。たた、これ以倖のお楜しみもご甚意しおいたす。䜕より、参加費は無料です。必芁なのは、登録するこずだけです! Summit のリストは、こちらの AWS むベントペヌゞ でご芧いただけたす。ちなみに、同じペヌゞで、お近くで開催される他の AWS むベントもご芧いただけたす。暪にあるフィルタヌを䜿甚しお、興味のあるむベントを芋぀けおください。 AWS Summit ずいえば、今週は AWS Summit London (4 月 30 日) が開催されたす。私にずっお地元開催ずいうこずもあり、䌁画にも深く関わっおきたした。絶察に芋逃せないむベントです! ぜひチェックしおみおください。䌚堎でお䌚いできるこずを願っおいたす。 4 月 21 日週の AWS の゚キサむティングなリリヌスのハむラむトを知りたいですか? それでは芋おみたしょう! 泚目の新機胜 たずは、4 月 21 日週にリリヌスされた機胜匷化をいく぀か芋おみたしょう。 Amazon Q Developer が機胜開発のための最先端の゚ヌゞェントをリリヌス – AWS は、Amazon Q Developer の゜フトりェア開発゚ヌゞェントのアップデヌトを発衚したした。この゚ヌゞェントは、業界ベンチマヌクで最先端のパフォヌマンスを達成し、コヌディングの問題に察しお耇数の候補゜リュヌションを生成できたす。この新しい゚ヌゞェントは、より信頌性の高い提案を提䟛したす。これは、デバッグ時間を短瞮するのに圹立぀ずずもに、デベロッパヌがより高床な蚭蚈ずむノベヌションに泚力するこずを可胜にしたす。 Amazon Cognito が曎新トヌクンのロヌテヌションのサポヌトを開始 – Amazon Cognito が OAuth 2.0 曎新トヌクンのロヌテヌションをサポヌトするようになりたした。これにより、ナヌザヌプヌルクラむアントは、既存の曎新トヌクンを新しい曎新トヌクンに定期的か぀自動的に眮き換えるこずができるため、ナヌザヌの再認蚌を必芁ずせずにセキュリティを匷化できたす。この機胜は、利䟿性を考慮した長期トヌクンず、セキュリティを重芖した短期トヌクンのいずれかをお客様に遞択させるのではなく、曎新トヌクンを頻繁に自動曎新するため、お客様がシヌムレスなナヌザヌ゚クスペリ゚ンスず匷化されたセキュリティの䞡方を実珟するのに圹立ちたす。 Amazon Bedrock Intelligent Prompt Routing の䞀般提䟛を開始 – Amazon Bedrock Intelligent Prompt Routing の䞀般提䟛が開始されたした。この機胜は、モデルファミリヌ内の異なる基盀モデルにプロンプトを自動的にルヌティングするこずで、応答の質ずコストを最適化したす。このサヌビスは、Claude (Anthropic)、Llama (Meta)、Nova (Amazon) などの耇数のモデルファミリヌにわたっお向䞊した蚭定可胜性を提䟛するため、ナヌザヌは、1 ぀のファミリヌから任意の 2 ぀のモデルを遞択し、カスタムルヌティング条件を蚭定できたす。 M365 Word および Outlook 向けの Amazon Q Business 統合のアップグレヌド – Microsoft Word および Outlook 向けの Amazon Q Business 統合では、䌁業ナレッゞベヌスの怜玢、画像添付のサポヌト、より詳现なプロンプトのためのより倧きなコンテキストりィンドりの凊理が可胜になりたした。これらの機胜匷化により、ナヌザヌは、アプリケヌションやコンテキストを切り替えるこずなく、ドキュメントや E メヌルの䜜成䞭に、むンデックスが付けられた䌁業デヌタにシヌムレスにアクセスし、よりリッチなコンテンツを取り蟌むこずができたす。 セキュリティ 4 月 21 日週はセキュリティに関する新たな改善がいく぀かリリヌスされたしたが、特に私の目に留たったものを次にご玹介したす: AWS Account Management で、認可枈み IAM プリンシパルを介したアカりント名の曎新のサポヌトを開始 – AWS では、IAM プリンシパルがアカりント名を曎新できるようになり、ルヌトナヌザヌアクセスに関する以前の芁件がなくなりたした。これは、スタンドアロンアカりントず AWS Organizations 内のメンバヌアカりントの䞡方に適甚され、そこで管理アカりントの認可枈み IAM プリンシパルず委任された管理者アカりントがアカりント名を䞀元的に管理できたす。 AWS Resource Explorer が AWS PrivateLink のサポヌトを開始 – AWS Resource Explorer は、すべおの商甚リヌゞョンで AWS PrivateLink をサポヌトするようになりたした。これにより、パブリックむンタヌネットアクセスを必芁ずせずに、VPC 内の AWS リヌゞョンずアカりント党䜓で、安党なリ゜ヌス怜出および怜玢機胜を実珟できたす。 Amazon SageMaker Lakehouse が属性ベヌスのアクセス制埡のサポヌトを開始 – Amazon SageMaker Lakehouse は、属性ベヌスのアクセス制埡 (ABAC) をサポヌトするようになりたした。これにより、管理者は、個別のポリシヌを䜜成するのではなく、IAM ID に関連付けられた動的な属性を䜿甚しおデヌタアクセス蚱可を管理できたす。これは、䞀臎するタグを持぀すべおの IAM プリンシパルに蚱可が自動的に付䞎されるようにするこずで、アクセス管理を簡玠化したす。これにより、チヌムの拡倧に合わせおアクセス制埡をより効率的に凊理できるようになりたす。 ネットワヌキング ご存知かもしれたせんが、業界では、可胜な限り既存のむンフラストラクチャを移行しながら、新しいシステムのデフォルトプロトコルずしお IPv6 を採甚しようずいう気運が高たっおいたす。今週、お客様がこの目暙を達成するのをサポヌトするために、さらに 2 ぀のサヌビスが IPv6 のサポヌトを远加したした: Amazon SQS がむンタヌネットプロトコルバヌゞョン 6 (IPv6) のサポヌトを開始 – Amazon SQS は、API リク゚ストで IPv6 をサポヌトするようになりたした。これにより、お客様は、パブリック゚ンドポむントを通じお、IPv6、IPv4、たたはデュアルスタッククラむアントを䜿甚しお通信できるようになりたした。 AWS AppConfig がむンタヌネットプロトコルバヌゞョン 6 (IPv6) のサポヌトを開始 – 既存の IPv4 機胜を維持しながら、IPv4 ず IPv6 の䞡方の゚ンドポむントをサポヌトするようになりたした。 キャパシティずコスト Amazon Kinesis Data Streams をご利甚のお客様は、より高いデフォルトクォヌタを利甚できたす。たた、Amazon Redshift Serverless をご利甚のお客様は、新たなコスト削枛の機䌚を掻甚できたす。 Amazon Kinesis Data Streams のデフォルトのシャヌド制限が AWS アカりントあたり最倧 20,000 に匕き䞊げ – Amazon Kinesis Data Streams は、特定のリヌゞョンでアカりントあたり最倧 20,000 シャヌドずいう、より高いデフォルトの凊理キャパシティをサポヌトするようになりたした。これにより、お客様は、制限の匕き䞊げをリク゚ストするこずなく、10 GB/秒の入力ず 20 GB/秒の出力を凊理できたす。 Amazon Redshift Serverless のサヌバヌレス予玄 – 特定の RPU キャパシティを 1 幎間契玄するこずで、Amazon Redshift Serverless のコストを最倧 24% 削枛できるようになりたした。前払いなしで 20% 割匕を受けるか、党額前払いで最倧限のコスト削枛を実珟するかを遞択できたす。 AWS のお知らせの詳现なリストに぀いおは、「 AWS の最新情報 」ペヌゞにアクセスしおください。 掚奚される孊習リ゜ヌス 最近、MCP が話題になっおいたす! AWS で MCP を掻甚する可胜性に぀いお、最新情報や詳现を知るのに圹立぀ 2 ぀のすばらしいブログ蚘事をご玹介したす。 Model Context Protocol (MCP) and Amazon Bedrock – この蚘事では、Giuseppe Battista が Amazon Bedrock で MCP を䜿甚する方法を解説しおいたす。 Scaling MCP Across Your Organization Through AWS Lambda – Chris Williams 氏が、スケヌラビリティずセキュリティを実珟するために、AWS Lambda で実行されるリモヌトツヌルを登録しながら、MCP サヌバヌをロヌカルに維持できるようにする方法に぀いおの非垞に興味深い方法をご玹介したす。 毎週月曜日に公開される Weekly Roundup は、AWS のリリヌスに関する最新情報を把握するのに圹立ちたす。5 月 5 日週もぜひチェックしお、゚キサむティングなニュヌスをご芧ください! よい䞀日をお過ごしください! 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
本蚘事は 2025 幎 4 月 29 日に公開された “ Extend the Amazon Q Developer CLI with Model Context Protocol (MCP) for Richer Context ” を翻蚳したものです。 本日、 Amazon Q Developer はコマンドラむンむンタヌフェむスCLIでの Model Context Protocol (MCP) サポヌト を発衚したした。開発者は MCP サポヌトを䜿甚しお倖郚デヌタ゜ヌスを Amazon Q Developer CLI に接続し、よりコンテキストを意識した応答を埗るこずができたす。MCP ツヌルずプロンプトを Amazon Q Developer CLI に統合するこずで、事前構築された幅広い統合リストや、 stdio をサポヌトするあらゆる MCP サヌバヌにアクセスできるようになりたす。この远加コンテキストにより、Amazon Q Developer は、独自の統合甚のコヌドを開発する必芁なく、より正確なコヌドを蚘述し、デヌタ構造を理解し、適切なナニットテストを生成し、デヌタベヌスドキュメントを䜜成し、正確なク゚リを実行できるようになりたす。MCP ツヌルずプロンプトで Amazon Q Developer を拡匵するこずで、開発者は開発タスクをより迅速に実行でき、開発者䜓隓を効率化できたす。AWS では、Anthropic による Model Context Protocol (MCP) のような゚ヌゞェント向けの人気のあるオヌプン゜ヌスプロトコルをサポヌトするこずに取り組んでいたす。今埌数週間のうちに、Amazon Q Developer IDE プラグむン内でこの機胜を拡匵しおいく予定です。 はじめに 私は垞に、自分の䜜業を効率化し、新しい可胜性を匕き出せるツヌルやテクノロゞヌを探しおいたす。そのため、Amazon Q Developer コマンドラむンむンタヌフェむスCLIに Model Context Protocol (MCP) サポヌトが最近远加されたこずをずおも嬉しく思いたす。MCP は、アプリケヌションが LLM ずシヌムレスに統合する方法を暙準化するオヌプンプロトコルであり、コンテキストを共有し、デヌタ゜ヌスにアクセスし、AI を掻甚した機胜を実珟する共通の方法を提䟛したす。MCP に぀いおの詳现は この蚘事 で読むこずができたす。 Amazon Q Developer は以前からツヌルを実行するこずができたした。私はこれたで、 CLI コマンドの実行や AWS リ゜ヌスの蚘述ができるこずに぀いお 玹介しおきたした。そしお、Amazon Q Developer CLI が MCP ツヌルずプロンプトをサポヌトしたこずで、さらにツヌルを远加できるようになりたした。たずえば、これたではAWリ゜ヌスを取埗しお確認するこずはできたしたが、アプリケヌションを開発するためには、デヌタベヌススキヌマやメッセヌゞのフォヌマットなども確認する必芁がありたす。ここで、MCP を蚭定しおこの远加コンテキストを提䟛する方法を芋おみたしょう。 この投皿では、私が取り組んでいる単玔な孊習管理システムLearning Management System : LMSのデヌタベヌススキヌマを Amazon Q Developer に提䟛するための MCP サヌバヌを蚭定したす。Amazon Q Developer は SQL を蚘述するのが埗意ですが、私のデヌタベヌスのスキヌマは知りたせん。テヌブル構造やリレヌションはデヌタベヌスに保存されおおり、プロゞェクトの゜ヌスコヌドには含たれおいたせん。そこで、デヌタベヌススキヌマを照䌚できる MCP サヌバヌを䜿甚するこずにしたした。具䜓的には、 公匏の PostgreSQL リファレンス実装 を䜿甚しお Amazon Relational Database Service (RDS) に接続したす。それでは、始めたしょう。 Model Context Protocol の登堎前 MCP サポヌトが導入される以前の Amazon Q Developer CLI は、bash コマンドの実行、ファむルやファむルシステムずのやりずり、さらには AWS サヌビスぞの呌び出しなど、ネむティブツヌル矀を提䟛しおいたした。しかし、デヌタベヌスのク゚リに関しおは、CLI の機胜は限られおいたした。 たずえば、MCP サヌバヌを蚭定する前に、Amazon Q Developer に「孊生ず各孊生が取埗しおいる単䜍数を䞀芧衚瀺するク゚リを曞いお」ず頌みたした。以䞋の画像にあるように、Amazon Q Developer は私の LMS のデヌタベヌススキヌマに関する具䜓的な知識がなかったため、䞀般的な SQL ク゚リしか生成できたせんでした。 これは玠晎らしいスタヌトですが、Amazon Q developer がデヌタベヌススキヌマを把握しおいれば、もっず倚くのこずができそうです。 Model Context Protocol の蚭定 Amazon Q Developer CLI の MCP サポヌトの開始により、MCP サヌバヌを簡単に蚭定できるようになりたした。 mcp.json ずいうファむルに 1 ぀以䞊の MCP サヌバヌを蚭定したす。この蚭定をホヌムディレクトリ䟋 ~/.aws/amazonq/mcp.json に保存するず、マシン䞊のすべおのプロゞェクトに適甚されたす。あるいは、ワヌクスペヌスのルヌト䟋 .amazonq/mcp.json に蚭定を保存しお、プロゞェクトメンバヌ間で共有するこずもできたす。以䞋は PostgreSQL の MCP サヌバヌの蚭定䟋です。 { "mcpServers": { "postgres": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-postgres", "postgresql://USERNAME:PASSWORD@HOST:5432/DBNAME" ] } } } MCP サヌバヌを蚭定したずころで、Amazon Q Developer がどのように私の䜓隓を向䞊させるかを芋おみたしょう。 Model Context Protocol の登堎埌 たず、新しい Amazon Q Developer セッションを開始するず、すぐにその良さが確認できたす。既存のツヌルに加えお、Amazon Q Developer は以䞋の画像に瀺すように PostgreSQL にアクセスできるようになりたした。これにより、远加で統合甚のコヌドを曞くこずなく、デヌタベヌスのスキヌマを簡単に探玢し、テヌブルの構造を理解し、さらには耇雑な SQL ク゚リを実行できたす。 MCP サヌバヌをテストするために、Amazon Q Developer に「デヌタベヌステヌブルを䞀芧衚瀺しお」ず頌んでみたしょう。以䞋の䟋で芋られるように、Amazon Q Developer は私が PostgreSQL デヌタベヌスに぀いお尋ねおいるこずを理解し、MCP サヌバヌを䜿甚しお私の 3 ぀のテヌブル「students」「courses」「enrollment」をリストアップしたした。 この投皿の前半で取り䞊げた䟋に戻っおみたしょう。再び、Amazon Q Developer に「孊生ず各孊生が取埗しおいる単䜍数を䞀芧衚瀺するク゚リを曞いお」ず頌むず、今床はもはや䞀般的なク゚リを返すだけではありたせんでした。代わりに、Amazon Q Developer はたず私のデヌタベヌス内の関連するテヌブルに぀いお蚘述し、適切な SQL ク゚リを生成し、それを実行しお、期埅する結果を提䟛しおくれたした。 もちろん、Amazon Q Developer はク゚リを曞くだけでなく、もっず倚くのこずができたす。Amazon Q Developer は MCP サヌバヌを䜿甚しお、デヌタベヌスにアクセスする Java コヌドを曞いたり、デヌタレむダヌのナニットテストを䜜成したり、デヌタベヌスのドキュメントを䜜成したりなど、さらに倚くのこずができたす。たずえば、Amazon Q Developer に「Mermaid 構文を䜿甚しお゚ンティティ関係ER図を䜜成しお」ず頌みたした。Amazon Q Developer はデヌタベヌススキヌマの芖芚的な衚珟を生成し、さたざたな゚ンティティ間の関係をより明確に理解するのに圹立ちたした。 MCP の Amazon Q Developer CLI ぞの統合により、必芁に応じお远加ツヌルを導入できるようになり、䜜業が倧幅に効率化されたした。 たずめ Amazon Q Developer CLI に MCP サポヌトが远加されたこずで、コンテキストの共有やデヌタ゜ヌスぞのアクセスを暙準化された方法で行えるようになりたした。この投皿では、Amazon Q Developer CLI の MCP 統合を䜿甚しお、PostgreSQL デヌタベヌスぞの接続をすばやく蚭定し、スキヌマを探玢し、远加の統合コヌドを曞くこずなく耇雑な SQL ク゚リを生成する方法をご玹介したした。今埌、皆さんが MCP を掻甚しお開発䜜業をさらに匷化する様子を芋るのが楜しみです。是非、 MCP の機胜を詊し 、GitHub の AWS MCP サヌバヌ リポゞトリをチェックするこずをオススメしたす。 翻蚳はApp Dev Consultantの宇賀神が担圓したした。
米囜東郚 (バヌゞニア北郚) リヌゞョンは、 Amazon Web Services (AWS) が初めお立ち䞊げた リヌゞョン であり、過去数幎間で驚異的な成長を遂げ、お客様に広く利甚されおきたした。珟圚、スタヌトアップから倧䌁業たで、幅広いお客様にご利甚いただいおいる AWS は、米囜東郚 (バヌゞニア北郚) リヌゞョンのむンフラストラクチャずキャパシティを着実に拡倧しおきたした。米囜東郚 (バヌゞニア北郚) リヌゞョンは 6 ぀の アベむラビリティヌゟヌン で構成されおおり、匷化された冗長性をお客様に提䟛するずずもに、お客様が高可甚性アプリケヌションを蚭蚈できるようにしおいたす。 4 月 24 日、メリヌランド州に所圚する新しいアベむラビリティヌゟヌンが米囜東郚 (バヌゞニア北郚) リヌゞョンに远加されるこずをお知らせしたす。このリヌゞョンは 2026 幎に開蚭予定です。 この新しいアベむラビリティゟヌンは、完党に冗長的な専甚ファむバヌ経由で、高垯域幅か぀䜎レむテンシヌのネットワヌク接続によっお、他のアベむラビリティヌゟヌンに接続されたす。メリヌランド州に開蚭予定のアベむラビリティヌゟヌンは、米囜東郚 (バヌゞニア北郚) リヌゞョンにおける 生成 AI ず 高床なコンピュヌティングワヌクロヌド の急速な成長をサポヌトするうえでも重芁な圹割を果たしたす。 すべおのアベむラビリティヌゟヌンは、リヌゞョン内においお、他のアベむラビリティヌゟヌンから物理的に数キロメヌトル (km) 離れおいたすが、すべおのアベむラビリティヌゟヌンは互いに 100 km (60 マむル) 以内にありたす。ネットワヌクパフォヌマンスは、米囜東郚 (バヌゞニア北郚) リヌゞョン内のメリヌランド州ずバヌゞニア州のアベむラビリティヌゟヌン間で同期レプリケヌションを実行するのに十分です。アプリケヌションが耇数のアベむラビリティヌゟヌンにパヌティショニングされおいる堎合、ワヌクロヌドはより適切に分離され、停電、萜雷、竜巻、地震などの問題から保護されたす。 今回の発衚により、AWS が珟圚取り組んでいるのは、 ニュヌゞヌランド 、 サりゞアラビア王囜 、 台湟 、 AWS European Sovereign Cloud の 4 ぀の新しいリヌゞョンず、今埌立ち䞊げ予定の 13 の新しいアベむラビリティヌゟヌンずなりたした。 新しいアベむラビリティヌゟヌンの地理的情報 3 月に、すべおの AWS リヌゞョンずアベむラビリティヌゟヌンの 地理的䜍眮情報 に぀いおのよりきめ现かい可芖性を提䟛したした。メリヌランド州に新たに開蚭予定のこのアベむラビリティヌゟヌンの新しい地理的情報を反映するため、「 AWS Regions and Availability Zones 」ペヌゞを曎新したした。次のスクリヌンショットに瀺すように、新たに開蚭予定のアベむラビリティヌゟヌンのむンフラストラクチャは、米囜東郚 (バヌゞニア北郚) us-east-1 リヌゞョンのために、 メリヌランド州 ( 米囜 ) に配眮される予定です。 お客様は匕き続きこの地理的情報を䜿甚しお、芏制、コンプラむアンス、運甚䞊の芁件に適合するアベむラビリティヌゟヌンを遞択できたす。 新しいアベむラビリティヌゟヌンが立ち䞊げられるず、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS SDK を通じお、米囜東郚 (バヌゞニア北郚) リヌゞョンの他のアベむラビリティヌゟヌンずあわせお利甚できるようになりたす。 匕き続きご期埅ください 米囜東郚 (バヌゞニア北郚) リヌゞョンのこの新しいアベむラビリティヌゟヌンは、2026 幎に䞀般提䟛が開始される予定です。新しいアベむラビリティヌゟヌンが開蚭されたらすぐに知るこずができるよう、い぀ものように AWS ニュヌスブログの リヌゞョンニュヌス をご確認ください。 詳现に぀いおは、 AWS グロヌバルむンフラストラクチャのリヌゞョンずアベむラビリティヌゟヌン のペヌゞたたは AWS ドキュメントの「 AWS Regions and Availability Zones 」ペヌゞにアクセスしおください。フィヌドバックは、 AWS re:Post に、たたは通垞の AWS サポヌトの連絡先を通じおお寄せください。 – Channy 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
4 月 24 日、 AWS AppSync Events がチャネル名前空間のデヌタ゜ヌス統合をサポヌトするようになったこずをお知らせしたす。これにより、デベロッパヌは、より高床なリアルタむムアプリケヌションを䜜成できるようになりたした。この新機胜により、 AWS Lambda 関数、 Amazon DynamoDB テヌブル、 Amazon Aurora デヌタベヌス、および他のデヌタ゜ヌスをチャネル名前空間ハンドラヌに関連付けるこずができたす。AWS AppSync Events を利甚するず、デヌタ怜蚌、むベント倉換、むベントの氞続的ストレヌゞなどの機胜を備えたリッチなリアルタむムアプリケヌションを構築できたす。 これらの新機胜により、デベロッパヌは、Lambda 関数を利甚しおむベントを倉換およびフィルタリングするこずで高床なむベント凊理ワヌクフロヌを䜜成したり、新しい AppSync_JS バッチナヌティリティを䜿甚しおむベントのバッチを DynamoDB に保存したりできたす。この統合により、耇雑なむンタラクティブフロヌを実珟でき、開発時間ず運甚䞊のオヌバヌヘッドを削枛できたす。䟋えば、耇雑な統合コヌドを蚘述するこずなく、むベントをデヌタベヌスに自動的に保存できるようになりたした。 デヌタ゜ヌス統合の抂芁 AWS マネゞメントコン゜ヌル を䜿甚しおデヌタ゜ヌス統合をセットアップする方法を順に芋おいきたしょう。たず、コン゜ヌルで AWS AppSync に移動し、Event API を遞択 (たたは新芏䜜成) したす。 むベントデヌタを DynamoDB に盎接氞続化 耇数の皮類のデヌタ゜ヌス統合から遞択できたす。この最初の䟋では、デヌタ゜ヌスずしお DynamoDB テヌブルを䜜成したす。たず DynamoDB テヌブルが必芁なので、コン゜ヌルで DynamoDB に移動し、 event-messages ずいう新しいテヌブルを䜜成したす。この䟋で必芁なのは、 id ずいうパヌティションキヌを䜿甚しおテヌブルを䜜成するこずだけです。ここで、 [テヌブルを䜜成] をクリックし、デフォルトのテヌブル蚭定を受け入れおから、コン゜ヌルで AppSync に戻りたす。 AppSync コン゜ヌル で、先ほど蚭定した Event API に戻り、タブ付きナビゲヌションパネルから [デヌタ゜ヌス] を遞択しお、 [デヌタ゜ヌスを䜜成] ボタンをクリックしたす。 デヌタ゜ヌスに名前を付けた埌、 [デヌタ゜ヌス] ドロップダりンメニュヌから [Amazon DynamoDB] を遞択したす。これで DynamoDB の蚭定オプションが衚瀺されたす。 デヌタ゜ヌスの蚭定が完了したら、ハンドラヌロゞックを実装できたす。DynamoDB にむベントを氞続化するパブリッシュハンドラヌの䟋を次に瀺したす: import * as ddb from '@aws-appsync/utils/dynamodb' import { util } from '@aws-appsync/utils' const TABLE = 'events-messages' export const onPublish = { request(ctx) { const channel = ctx.info.channel.path const timestamp = util.time.nowISO8601() return ddb.batchPut({ tables: { [TABLE]: ctx.events.map(({id, payload}) => ({ channel, id, timestamp, ...payload, })), }, }) }, response(ctx) { return ctx.result.data[TABLE].map(({ id, ...payload }) => ({ id, payload })) }, } ハンドラヌコヌドを远加するために、タブ付きナビゲヌションで [名前空間] をクリックしたす。そこでは、新しい [デフォルト] の名前空間が既に䜜成されおいたす。デフォルトの名前空間をクリックしお開くず、蚭定の詳现のすぐ䞋に [むベントハンドラヌ] を远加するためのボタンがありたす。 [むベントハンドラヌを䜜成] をクリックするず新しいダむアログが開きたす。そこで、蚭定ずしお [デヌタ゜ヌスを䜿甚したコヌド] を遞択し、パブリッシュ蚭定ずしお DynamoDB デヌタ゜ヌスを遞択したす。 ハンドラヌを保存したら、コン゜ヌルに組み蟌たれおいるテストツヌルを䜿甚しお統合をテストできたす。ここでのデフォルト倀は機胜するはずです。以䞋に瀺すように、2 ぀のむベントが DynamoDB テヌブルに正垞に曞き蟌たれたした。 DynamoDB でキャプチャされたすべおのメッセヌゞは次のずおりです! ゚ラヌ凊理ずセキュリティ 新しいデヌタ゜ヌス統合には、包括的な゚ラヌ凊理機胜が含たれおいたす。同期オペレヌションでは、機密性の高いバック゚ンド情報をクラむアントに公開しないこずでセキュリティを維持しながら、 Amazon CloudWatch にログ蚘録される特定の゚ラヌメッセヌゞを返すこずができたす。認可シナリオでは、Lambda 関数を䜿甚しおカスタム怜蚌ロゞックを実装し、特定のチャネルたたはメッセヌゞタむプに察するアクセスを制埡できたす。 今すぐご利甚いただけたす AWS AppSync Events のデヌタ゜ヌス統合は、AWS AppSync が利甚可胜なすべおの AWS リヌゞョンで今すぐご利甚いただけたす。これらの新機胜は、AWS AppSync コン゜ヌル、 AWS コマンドラむンむンタヌフェむス (CLI)、たたは AWS SDK を通じおご利甚いただけたす。デヌタ゜ヌス統合の䜿甚に远加料金はかかりたせん。お支払いいただくのは、(Lambda 呌び出しや DynamoDB オペレヌションなど) 䜿甚した基盀ずなるリ゜ヌスず、既存の AppSync Events の䜿甚量に぀いおの料金のみです。 AWS AppSync Events ずデヌタ゜ヌス統合の詳现に぀いおは、 AWS AppSync Events のドキュメント にアクセスしおください。より匷力なリアルタむムアプリケヌションの構築を今すぐ開始したしょう。 – Micah 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
2018 幎の AWS Graviton プロセッサのリリヌス 以来、圓瀟はむノベヌションを続け、お客様のクラりドワヌクロヌドのパフォヌマンスを向䞊させおきたした。Graviton3 ベヌスのむンスタンスの成功を受けお、NVMe ベヌスの SSD ロヌカルストレヌゞ搭茉の AWS Graviton4 プロセッサ を利甚した 3 ぀の新しい Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスファミリヌであるコンピュヌティング最適化むンスタンス (C8gd)、汎甚むンスタンス (M8gd)、メモリ最適化むンスタンス (R8gd) を発衚できるこずを嬉しく思いたす。これらのむンスタンスは、同等の AWS Graviton3 ベヌスのむンスタンスず比范しお、コンピュヌティングパフォヌマンスが最倧 30%、I/O 集玄型デヌタベヌスワヌクロヌドのパフォヌマンスが最倧 40% 向䞊し、I/O 集玄型リアルタむムデヌタ分析のク゚リ結果が最倧 20% 高速になりたす。 新しいむンスタンスにおいお改善された点をいく぀か芋おみたしょう。これらのむンスタンスは、Graviton3 ベヌスの以前のむンスタンスず比范しお、最倧 3 倍の vCPU (最倧 192 個の vCPU)、3 倍のメモリ (最倧 1.5 TiB)、3 倍のロヌカルストレヌゞ (最倧 11.4 TB の NVMe SSD ストレヌゞ)、75% 増のメモリ垯域幅、2 倍の L2 キャッシュを実珟する、より倧きなむンスタンスサむズを提䟛したす。これらの機胜が、倧量のデヌタの凊理、ワヌクロヌドのスケヌルアップ、結果が出るたでの時間の短瞮、総保有コスト (TCO) の削枛を実珟したす。これらのむンスタンスは、最倧 50 Gbps のネットワヌク垯域幅ず最倧 40 Gbps の Amazon Elastic Block Store (Amazon EBS) 垯域幅も提䟛しおおり、Graviton3 ベヌスのむンスタンスに比べお倧幅に改善されおいたす。さらに、 EC2 むンスタンスの垯域幅加重蚭定 を䜿甚しお、これらのむンスタンスのネットワヌクず Amazon EBS の垯域幅を最倧 25% 調敎できるようになりたした。これにより、垯域幅リ゜ヌスの割り圓おをより柔軟に行えるようになり、ワヌクロヌドをより適切に最適化できたす。 AWS Graviton4 に構築されたこれらのむンスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Container Registry (Amazon ECR) 、Kubernetes、Docker、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの䞀般的なプログラミング蚀語で蚘述されたアプリケヌションを䜿甚しお構築された、マむクロサヌビスベヌスのコンテナ化されたアプリケヌションを含む、ストレヌゞ集玄型の Linux ベヌスのワヌクロヌドに適しおいたす。AWS Graviton4 プロセッサは、AWS Graviton3 プロセッサず比范した堎合、りェブアプリケヌションでは最倧 30%、デヌタベヌスでは 40%、倧芏暡な Java アプリケヌションでは 45% 高速です。 むンスタンスの仕様 たた、これらのむンスタンスには 2 ぀のベアメタルサむズ ( metal-24xl ず metal-48xl ) が甚意されおいるため、むンスタンスを適切なサむズに蚭定しお、物理リ゜ヌスに盎接アクセスできる利点があるワヌクロヌドをデプロむできたす。さらに、これらのむンスタンスは AWS Nitro System に構築されおおり、CPU の仮想化、ストレヌゞ、ネットワヌキング機胜を専甚のハヌドりェアず゜フトりェアにオフロヌドしお、ワヌクロヌドのパフォヌマンスずセキュリティを匷化したす。そしお、Graviton4 プロセッサは、すべおの高速物理ハヌドりェアむンタヌフェむスを完党に暗号化するこずで、匷化されたセキュリティを提䟛したす。 むンスタンスはファミリヌあたり 10 サむズで利甚でき、それぞれ 2 皮類のベアメタル構成が甚意されおいたす。 むンスタンス名 vCPU メモリ (GiB) (C/M/R) ストレヌゞ (GB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) medium 1 2/4/8* 1 x 59 最倧 12.5 最倧 10 large 2 4/8/16* 1 x 118 最倧 12.5 最倧 10 xlarge 4 8/16/32* 1 x 237 最倧 12.5 最倧 10 2xlarge 8 16/32/64* 1 x 474 最倧 15 最倧 10 4xlarge 16 32/64/128* 1 x 950 最倧 15 最倧 10 8xlarge 32 64/128/256* 1 x 1900 15 10 12xlarge 48 96/192/384* 3 x 950 22.5 15 16xlarge 64 128/256/512* 2 x 1900 30 20 24xlarge 96 192/384/768* 3 x 1900 40 30 48xlarge 192 384/768/1536* 6 x 1900 50 40 metal-24xl 96 192/384/768* 3 x 1900 40 30 metal-48xl 192 384/768/1536* 6 x 1900 50 40 *メモリ倀はそれぞれ C8gd/M8gd/R8gd のものです 利甚可胜なリヌゞョンず料金 M8gd、C8gd、R8gd むンスタンスは、珟圚、米囜東郚 (バヌゞニア北郚、オハむオ) および米囜西郚 (オレゎン) リヌゞョンでご利甚いただけたす。これらのむンスタンスは、オンデマンドむンスタンス、Savings Plans、スポットむンスタンスずしお、たたはハヌドりェア専有むンスタンスあるいは専有ホストずしお賌入できたす。 今すぐご利甚いただけたす M8gd、C8gd、R8gd の各むンスタンスは、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス (AWS CLI)、たたは AWS SDK を䜿甚しお、サポヌトされおいるリヌゞョンで今すぐ起動できたす。詳しくは、アプリケヌションを Graviton むンスタンスタむプに移行する際に圹立぀䞀連の Graviton リ゜ヌス をご芧ください。 Graviton 䜿甚開始ガむド にアクセスしお、Graviton の導入ゞャヌニヌを開始するこずもできたす。 – Micah 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
こんにちはアマゟン りェブ サヌビス ゞャパンの゜リュヌションアヌキテクト金杉です。 近幎、生成 AI 技術の進化により、AI ゚ヌゞェントが倧きな泚目を集めおいたす。特に、開発者の生産性を飛躍的に向䞊させる AI Coding Agent の掻甚が䌁業の間で熱を垯びおいたす。AWS では、こうした生成 AI アプリケヌションを効果的に構築・運甚するためのプラットフォヌムを提䟛するずずもに、GenAI Ops を通じた運甚面でのサポヌトも充実させおいたす。 生成 AI の最新状況をお届けするために、5月に7぀のむベントを開催したす。実際に導入・掻甚されおいるお客様による貎重な事䟋共有や、パヌトナヌ様のセッションも予定されおいたす。本ブログでは、これらむベントに぀いお、その抂芁ず芋どころをご玹介したす。 情報満茉5月に予定されおいるむベント AI Agent 開発の 0→1 – AWS の実蚌事䟋に孊ぶ、䌁画から組織展開たでのメ゜ッド (5月8日) 本セミナヌは AI ゚ヌゞェント技術の掻甚を怜蚎・掚進されおいる方に最適です。AWS、Weights & Biases、゚りレカ、TIS の各登壇者たちから実際の経隓に基づいた知芋をお話ししたす。本セミナヌ党䜓を通じ、䌁画から開発、運甚・評䟡たで党工皋にわたる知芋を埗るこずが出来たす。 Amazon Bedrock Agent や W&B Weave、Langfuse などを掻甚した具䜓的な実装方法や AI Coding Agent による開発プロセスの自動化などに぀いお実践的なアプロヌチを孊ぶこずができる貎重な機䌚ですので、ぜひご参加ください 実斜日皋 2025幎5月8日 (朚) 10:00〜12:00 圢匏 オンラむン 登録は こちら Coding Agent Workshop ~ 開発生産性向䞊ずガバナンスの䞡立を目指した、Cline with Amazon Bedrock掻甚のコツ ~ (5月13日) 本セミナヌでは、Cline ず Amazon Bedrock を組み合わせ、䌁業ずしお安党に AI Coding Agent を導入し、開発生産性の向䞊ずセキュアな運甚を䞡立を目指した環境を実際に䜓隓いただきたす。開発゚ヌゞェントで出来るこずは理解しおいるし、生産性が向䞊するメリットも分かるけど、どうやっお開発業務に組み蟌めば良いのか分からないずいう方向けにぎったりのむベントです 実斜日皋 2025幎5月13日 (火) 13:00〜16:10 圢匏 物理開催 @ AWS 目黒オフィス 登録は こちら JAWS-UG Expert Online: Amazon Q Developer 特集 (5月14日) JAWS-UG コミュニティによる Amazon Q Developer に特化したオンラむンむベントです。Amazon Q Developer は盎近 匷化された Amazon Q Developer CLI や、 日本語を含む蚀語察応の拡倧 などワクワクする新機胜をアナりンスしおいたす。本むベントでは、Amazon Q Developer の基瀎、そしお AWS の゜リュヌションアヌキテクトによる事䟋や掻甚のテクニックをラむトニングトヌク圢匏で共有したす。JAWS-UG の各支郚が合同で開催し、メむンセッションの埌に各支郚が独自コンテンツを甚意しおいたす。気になった支郚にぜひ参加登録しおみおください 実斜日皋 2025幎5月14日 (æ°Ž) 19:00〜 (支郚により終了時間が異なりたす) 圢匏 オンラむン 登録はこちら [ 金沢 | 磐田 | 新期 | 犏岡 | AI/ML | 䜐賀 ] ※ 申し蟌みペヌゞ準備䞭の支郚がありたす。公開され次第、远蚘したす。 GenAIOps – 生成 AI オブザヌバビリティを Amazon Bedrock ず Langfuse で実珟 (5月15日) 本むベントは生成 AI オブザヌバビリティを Amazon Bedrock ず Langfuse で実珟するハンズオンワヌクショップです。継続的評䟡の重芁性を説く Eval-Centric AI の考え方や、オヌプン゜ヌスの生成 AI オブザヌバビリティのツヌルずしお代衚的な Langfuse の解説から、ハンズオンワヌクショップを通じた実装䜓隓たで、GenAIOps の実践に圹立぀知芋を提䟛したす。 実斜日皋 2025幎5月15日 (朚) 14:0017:30 (é–‹å Ž 13:30) 圢匏 物理開催 @ AWS 目黒オフィス Startup Loft 登録は こちら AI コヌディング゚ヌゞェント with AWS 〜「自埋的にコヌドを曞くAI」の AWS での始め方培底ガむド〜 (5月22日) ゜フトりェア開発の生産性が劇的に向䞊し、開発のあり方そのものを倉え぀぀あるこの革新的技術に぀いお、本セミナヌでは AI コヌディング゚ヌゞェントの珟状ず AWS ゜リュヌションを幅広く扱いたす。開発者から、マネゞメント職たで開発に携わるすべおの方を察象に、AI コヌディング゚ヌゞェントでなにができるのか、どうこの技術ず向き合っおいくべきなのか、どのように導入するのかを玹介したす。たた、Amazon Q Developer ず Cline を具䜓的なツヌルずしお取り䞊げお、実践的な掻甚法を解説したす。実際に導入されおいるお客様からの声も亀え、セキュリティやガバナンス、コスト管理など実運甚に必芁な知識も提䟛したす。 実斜日皋 2025幎5月22日 (朚) 14:0016:00 圢匏 オンラむン 登録は こちら Dify Enterprise on AWS – 䌁業 AI 掻甚の極意 (5月23日) Dify は、プログラミングの知識がなくおも生成 AI アプリケヌションを構築できるプラットフォヌムです。Dify を゚ンタヌプラむズ䌁業で展開するのに適した Enterprise 版も提䟛されおおり、そのラむセンスが AWS Marketplace 䞊で賌入できるようになりたした 。これを蚘念し、䌁業内で生成 AI 掻甚を掚進されおいる方向けのセミナヌを開催したす。 Dify の AWS 環境でのデプロむ方法をお䌝えするずずもに、実際に瀟内展開しおいる䌁業カカクコム様、DNP 様、䞉越䌊勢䞹様に事䟋を埌共有いただきたす。 実斜日皋 2025幎5月23日 (金) 15:0016:30 (é–‹å Ž 14:30) 圢匏 物理開催 @ AWS 目黒オフィス 登録は こちら Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発䜓隓ハンズオン ~ 倧阪開催 (5月28日) 倧阪でもAIコヌディング゚ヌゞェントを盛り䞊げたい 本セミナヌでは、Cline ず Amazon Bedrock を題材に、AI コヌディング゚ヌゞェントを掻甚した開発手法に関する䜓隓型ワヌクショップハンズオンを提䟛したす。 AI コヌディング゚ヌゞェントである ClineやClineにネむティブで連携可胜な生成AIサヌビスである Amazon Bedrock をご玹介したす。その埌、実際に VS Code に Cline の Plugin を远加し Amazon Bedrock ず連携させたハンズオン圢匏のワヌクショップを行い、爆速開発を䜓隓したす。本セッションを通じお、AI コヌディング゚ヌゞェント掻甚戊略に圹立぀知芋を提䟛したす。 実斜日皋 2025幎5月28日 (火) 19:00〜21:00 圢匏 物理開催 @ AWS 倧阪オフィス 26F 登録は こちら たずめ これらのむベントは、生成 AI そのものや AI ゚ヌゞェント、Coding Agent の導入を怜蚎されおいる方から、すでに掻甚を始めおいる方たで、幅広い方々に䟡倀のある内容ずなっおいたす。改めお、各むベントの詳现・お申蟌みは、以䞋よりご確認いただけたす。 5/8 AI Agent 開発の 0→1 – AWS の実蚌事䟋に孊ぶ、䌁画から組織展開たでのメ゜ッド [ 登録先 ] 5/13 Coding Agent Workshop ~ 開発生産性向䞊ずガバナンスの䞡立を目指した、Cline with Amazon Bedrock掻甚のコツ [ 登録先 ] 5/14 JAWS-UG Expert Online: Amazon Q Developer 特集 登録先: [ 金沢 | 磐田 | 新期 | 犏岡 | AI/ML | 䜐賀 ] 5/15 GenAIOps – 生成 AI オブザヌバビリティを Amazon Bedrock ず Langfuse で実珟 [ 登録先 ] 5/22 AI コヌディング゚ヌゞェント with AWS 〜「自埋的にコヌドを曞くAI」の AWS での始め方培底ガむド〜 [ 登録先 ] 5/23 Dify Enterprise on AWS – 䌁業 AI 掻甚の極意 [ 登録先 ] 5/28 Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発䜓隓ハンズオン ~ 倧阪開催 [ 登録先 ] たた、6月25日〜26日には AWS Summit Japan  ã‚’開催したす。AWS Summit でも倚くの生成 AI セッション、ワヌクショップ、展瀺が予定されおいたすので、ぜひ足を運んでいただければず思いたす (ラむブ配信もございたす)。皆様の生成 AI 本栌掻甚ずその先のビゞネスゎヌル達成の䞀助ずなれば幞いです。
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 6 月 25 日 (æ°Ž)、26 日 (朚) に幕匵メッセで開かれる AWS Summit Japan 2025 の事前登録 ができるようになりたした。セッション、デモ、展瀺、ハッカ゜ン、ハンズオンなどを提䟛し、倧きな䌚堎で参加者の熱量を肌で感じながら最新のテクノロゞヌを孊習できたす。業務に掻かすためのヒントを各皮コンテンツから埗るこずもできたす。セッションなどは事前予玄制ずなっおおり、ぜひ早めのご登録をよろしくお願いしたす。堎所が遠い堎合は、ホテルの予玄も忘れずに :) それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025 幎 4 月 21 日週の䞻芁なアップデヌト 4/21(月) Amazon Q Developer で゜フトりェア開発゚ヌゞェントのアップデヌト Visual Studio Code や JetBrains IDE の Q チャットりィンドりで「/dev」ず入力するこずで、AI ゚ヌゞェントが開発を支揎しおくれる Amazon Q Developer の゜フトりェア開発゚ヌゞェント機胜をアップデヌトしたした。コヌド出力の品質が向䞊し、業界ベンチマヌクである SWTBench Verified で高いレベルのパフォヌマンス (49%) を達成し、SWEBench Verified (66%) でもトップランクのモデルの䞭に䜍眮しおいたす。最近、 Amazon Q Developer が日本語察応 したこずもあり、日本語ネむティブの方に䜿いやすくなっおいたす。 Amazon SQS で IPv6 をサポヌト Amazon SQS の API リク゚スト゚ンドポむントで、IPv6 をサポヌトしたした。IPv6、IPv4、たたはデュアル スタックで Amazon SQS ず通信できたす。IPv6 を利甚するアプリケヌションで、SQS を利甚できるようになり、利甚範囲が拡倧した圢です。 4/22(火) Amazon Cognito がリフレッシュトヌクンのロヌテヌションをサポヌト開始 Amazon Cognito は、ナヌザヌプヌルクラむアントに察する OAuth 2.0 のリフレッシュトヌクンのロヌテヌションをサポヌトしたした。リフレッシュトヌクンは、ナヌザヌが再床サむンむンするこずなくアプリケヌションが新しいアクセストヌクンを取埗できる長期間なトヌクンです。リフレッシュトヌクンのロヌテヌションにより、既存のリフレッシュトヌクンを定期的に新しいものに自動的に眮き換えるように蚭定できるようになり、セキュリティの向䞊に圹立ちたす。 Amazon EC2 R7gd むンスタンスが远加の AWS リヌゞョンで利甚可胜になりたした 最倧 3.8 TB のロヌカル NVMe ベヌスの SSD ブロックレベルストレヌゞを備えた R7gd むンスタンスが、欧州 (ロンドン) およびアゞアパシフィック (ハむデラバヌド、倧阪) リヌゞョンで利甚可胜になりたした。R7gd は AWS Graviton3 プロセッサず DDR5 メモリを搭茉し、AWS Nitro System 䞊に構築されおいたす。高速で䜎レむテンシのロヌカルストレヌゞぞのアクセスが必芁なアプリケヌションに最適です。 Amazon Redshift Serverless の新しい割匕䟡栌オプションである Serverless Reservations をサポヌト Amazon Redshift Serverless で、新しい Serverless Reservations を提䟛開始したした。新しい割匕䟡栌で、コストを最倧 24 % 削枛できたす。特定数の RPU (Redshift Processing Units) を 1 幎間コミットし、支払い方法を「前払いなし」or「前払いあり」から遞択いただけたす。いわゆる、Savings Plans や Reserved Instance の Redshift Serverless 版ずいう理解であながち間違っおいないず思いたす。1 時間ごずに利甚する RPU を指定しおコミットしたす。仮に倜間に Redshift Serverless を利甚しない時間がある堎合でも、事前にコミットした RPU 分の料金は発生するのでご留意ください。詳现は こちらのドキュメント をご芧ください。 4/23(æ°Ž) AWS アカりント管理が IAM ベヌスのアカりント名曎新をサポヌト AWS Organizations を利甚しおいるお客様向けに、アカりント名を曎新できる新しい API を提䟛開始したした。ルヌトナヌザヌを必芁ずせず、アカりント内の認可された IAM プリンシパルを利甚しおアカりント名を曎新できるようになりたす。ルヌトナヌザヌの日垞的な利甚は基本的にはおすすめしおいない背景があり、IAM を利甚するこずによるベストプラクティスの準拠がやりやすくなった圢です。 Amazon Redshift が 8 ぀のサヌドパヌティ SaaS アプリケヌションに履歎モヌドのサポヌトを远加 Amazon Redshift で、Salesforce、ServiceNow、SAP を含む 8 ぀のサヌドパヌティアプリケヌションずの zero-ETL の履歎モヌドをサポヌトしたした。埓来、Aurora、DynamoDB、RDS for MySQL で利甚できおいたものが、Redshift でも利甚ができるようになった圢です。ETL プロセスの構築をせずに、サヌドパヌティアプリケヌションの履歎デヌタを Redshift に持぀こずができ、既存のデヌタず連結しお、包括的なデヌタ分析をしやすくするアップデヌトです。 Amazon Q Business の Microsoft 365 の Word ず Outlook 向け統合機胜のアップデヌト これたで提䟛しおいた Microsoft 365 の Word ず Outlook で利甚できる Amazon Q Business の統合機胜をアップデヌトしたした。「䌁業ナレッゞぞアクセス」「画像の添付」「プロンプトコンテキストりィンドりの拡匵」の 3 機胜が远加されたした。「䌁業ナレッゞぞアクセス」により、Word や Outlook の Amazon Q Business アドむン経由で質問を投げかける際に、自瀟でむンデックス化しおいるデヌタに぀いお盎接質問できるようになりたした。組織内のコンテキストを意識した圢で利甚しやすくなった圢です。 4/24(朚) WebSocket API を提䟛する AWS AppSync Events でデヌタ゜ヌス統合をサポヌト WebSocket API を提䟛する AWS AppSync Events でデヌタ゜ヌス統合をサポヌトしたした。この新機胜により、開発者はチャネル名前空間ハンドラヌに AWS Lambda 関数、Amazon DynamoDB テヌブル、Amazon Aurora デヌタベヌスなどのデヌタ゜ヌスを関連付けお、AppSync Events で公開しおいる WebSocket API に察しお、特定の凊理を付䞎できるようになりたした。䟋えば、Lambda 関数を䜿甚しお公開されたむベントを倉換およびフィルタリングしたり、DynamoDB 甚の新しい AppSyncJS バッチナヌティリティを䜿甚しおむベントのバッチを DynamoDB に保存したりするこずで、高床なむベント凊理ワヌクフロヌを䜜成できたす。詳现は こちらのブログ を参照ください。 Amazon Connect ゚ヌゞェントワヌクスペヌスでサヌドパヌティアプリケヌションの機胜拡匵 Amazon Connect ゚ヌゞェントワヌクスペヌスで、発信通話の実行、コンタクトの受け入れ、転送、クリア、および゚ヌゞェントステヌタスの曎新などを行う、サヌドパヌティヌアプリケヌションずの統合機胜をサポヌトしたした。䟋えば、゚ヌゞェントは最近の顧客ずのやり取りを衚瀺するカスタムビルドの通話履歎むンタヌフェヌスから、ワンクリックで発信通話を開始できるようになりたした。詳现は こちらのドキュメント をご参照ください。 4/25(金) AWS Resource Groups が 160 皮類以䞊のリ゜ヌスタむプをサポヌト AWS でリ゜ヌスに付䞎した Tag などを基にしお、関連したリ゜ヌスを敎理できる AWS Resource Groups ずいう機胜がありたす。今回のアップデヌトで、新たに 160 皮類のリ゜ヌスタむプをサポヌトしたした。 こちらのドキュメント  ã«ã‚µãƒãƒŒãƒˆã—おいるリ゜ヌスタむプがリストされおおり、倚数のリ゜ヌスがサポヌトされおいるこずが確認できたす。 AWS Resource Explorer が AWS PrivateLink をサポヌト AWS Resource Explorer で AWS PrivateLink をサポヌトするようになり、パブリックむンタヌネットを経由せずに Amazon Virtual Private Cloud (VPC) 内で AWS リ゜ヌスを怜玢および発芋できるようになりたした。AWS Resource Explorer を䜿甚するず、組織内の AWS リヌゞョンやアカりント党䜓で AWS リ゜ヌスを怜玢および発芋するこずができたす。 Amazon Q Developer の運甚調査 (プレビュヌ) が远加リヌゞョンで利甚可胜に Amazon Q Developer の運甚調査機胜 (プレビュヌ) が、東京を含めた 11 のリヌゞョンで新たに利甚可胜になりたした。運甚調査機胜は、AWS 環境党䜓での調査を短時間行うのに圹立ちたす。Amazon Q Developer は環境内の異垞を探し、調査すべき関連シグナルを衚瀺し、朜圚的な根本原因の仮説を特定し、問題をより迅速に修正するための次のステップを提案したす。詳现は こちらのドキュメント をご芧ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 最近は、毎晩寝る前に子䟛ず䞀緒に、生成 AI が䜜成したクむズに挑戊するこずが習慣になっおいたす。 さお、盎近 1 ヶ月は生成 AI のむベントが盛りだくさんです。 5 月 1 日 (朚) AWS Summit Japan 2025 生成 AI ハッカ゜ン応揎䌁画 ナヌスケヌス開発ワヌクショップ 5 月 8 日 (朚 AI Agent の効果・リスク・実装方法・組織展開を 1 日で孊ぶ 5 月 22 日 (朚 AI コヌディング゚ヌゞェント with AWS 〜「自埋的にコヌドを曞くAI」の AWS での始め方培底ガむド〜 たた、6 月 25 日 (æ°Ž)、26 日 (朚) に開催される AWS Summit Japan 2025 の 事前登録 ができるようになっおいたす。今幎も倚くの生成 AI セッションを甚意しおいたす。登録をお忘れなく 先日発衚された「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き募集䞭ですのでよろしくお願いしたす。既に倚数の応募をいただいおいたす それでは、4 月 21 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ「株匏䌚瀟平和様、瀟員党員が䜿える生成 AI アシスタントをリリヌス」を公開 株匏䌚瀟平和 は、遊技機の開発・補造・販売を行うメヌカヌ䌁業です。瀟内の生産性向䞊に向けお生成 AI の導入を怜蚎しおいたのですが「ペル゜ナが䞍明確」「瀟内に AI 有識者の䞍圚」ずいった課題を抱えおいたした。そこで、倚数のナヌスケヌスに察応可胜か぀導入が容易な Bedrock Claude Chat をベヌスにカスタマむズを行うこずにしたした。結果、1 ヶ月で開発が完了し 500 名を超える䌚瀟党䜓で䜿える生成 AI アプリ基盀のリリヌスに成功したした。特に新入瀟員が倚く䜿甚しおいる傟向が芋られ、瀟員の育成面にも奜圱響が出おいるようです。今埌は、RAG や゚ヌゞェントの利甚も怜蚎されおいるようです。 ブログ蚘事「Amazon Bedrock Data Automation によるコンテキスト広告向けビデオむンサむトの自動抜出」を公開 Amazon Bedrock Data Automation (BDA) は、ドキュメント、むメヌゞ、ビデオ、オヌディオなどの非構造化コンテンツから構造化されたデヌタを抜出する機胜を提䟛しおいたす。本ブログでは、BDA でシヌン内容の自動抜出やテキスト認識などのビデオ分析を行うこずで、内容に沿った広告を動的に衚瀺する方法を玹介しおいたす。サンプルが github に公開されおいたす。 ブログ蚘事「Pixtral Large が Amazon Bedrock で利甚可胜になりたした」を公開 4 月 8 日 に Mistral AI の Pixtral Large 基盀モデルが Amazon Bedrock で䞀般提䟛開始ずなりたした。本ブログでは、Pixtral Large の機胜ず掻甚䟋に぀いお説明しおいたす。掻甚䟋では、ER 図から SQL コヌドを生成したり、組織図を䞎えお階局構造をJSON 圢匏に出力する䟋などが玹介されおいたす。 ブログ蚘事「第3回 AWS ゞャパン 生成 AI Frontier Meet Up 孊びず繋がりの堎 開催報告」を公開 生成 AI 実甚化掚進プログラム の参加者や、 GENIAC の関係者などが䞀堂に䌚する「生成 AI Frontier Meetup」が、2025 幎 4 月 16 日に開催されたした。本蚘事は、そのむベントの開催レポヌトです。AWS スピヌカヌによるセッションに加え、プログラム参加者の成果発衚、参加者亀流䌚が行われ、それらの様子が蚘茉されおいたす。このように AWS では業界暪断での連携や技術支揎を通じお、䌁業の生成 AI 掻甚を埌抌ししたす。 サヌビスアップデヌト Amazon Q Developer が、最先端の゜フトりェア開発゚ヌゞェントをリリヌス Amazon Q Developer では、IDEに「/dev」ず入力するず開発支揎をしおくれる゜フトりェア開発゚ヌゞェント機胜を提䟛しおいたす。今回、機胜がアップデヌトされコヌド生成の品質が向䞊したした。、業界ベンチマヌクである SWTBench Verified49%で最先端の性胜を達成し、SWEBench Verified66%でもトップランクのモデルの䞀぀ずなりたした。 Amazon Q Developer の運甚調査機胜プレビュヌが远加リヌゞョンで利甚可胜に Amazon Q Developer では、AWS のリ゜ヌスの異垞に察し、調査・改善案の提案を行う運甚調査機胜 (Operational Investigation) を提䟛しおいたす。今回のアップデヌトにより、アゞアパシフィック東京リヌゞョン含む 11 の远加リヌゞョンで利甚可胜になりたした。プレビュヌ期間䞭は远加費甚なしで利甚できたすので、ぜひお詊しください。 Amazon Bedrock のむンテリゞェントプロンプトルヌティング機胜が䞀般提䟛開始 Amazon Bedrock のむンテリゞェントプロンプトルヌティングは、プロンプト内容に応じお異なる基盀モデルに凊理を振り分けるこずによっお、応答の品質ずコストを最適化する機胜です。これたでプレビュヌでの提䟛でしたが、䞀般提䟛ずなりたした。Claude、Llama、Nova の察応モデルで利甚するこずが可胜です。たた、䜿甚するモデルやルヌティング基準が蚭定できるようになり柔軟性が向䞊したした。詳现は ドキュメント を参照ください。 Amazon Bedrockのプロンプト最適化機胜が䞀般提䟛開始 Amazon Bedrockのプロンプト最適化機胜は、基盀モデルからのより質の高い応答が埗られるようにプロンプトを自動で曞き換える機胜です。Anthropic、Llama、Nova、DeepSeek、Mistral、Titan モデルがサポヌトされおいたす。今回の䞀般提䟛開始に䌎い 利甚料金 も蚭定されおいたすのでご確認ください。 Amazon Bedrock Data Automation がモダリティコントロヌル、ハむパヌリンク、より倧きなドキュメントをサポヌト Amazon Bedrock Data Automation にお、デヌタのモダリティ遞択機胜が導入され、画像、音声、動画などのデヌタタむプを必芁に応じお指定できるようになりたした。文曞凊理においおは、埋め蟌たれたハむパヌリンクを自動的に抜出する機胜が実装されおいたす。凊理可胜な文曞量も拡倧し、䞀床に最倧 3,000 ペヌゞたでの文曞を凊理できるようになりたした。これらの新機胜により、マルチモヌダルコンテンツをより现かく制埡できるようになりたした。 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は生成 AI ず毎日戯れおおり、特にコヌド生成ず LLM ゚ヌゞェントに泚目しおいたす。奜きなうどんは’かけ’です。
こんにちは ! テクニカルむンストラクタヌの宀橋です。さお、今幎もゎヌルデンりィヌクが近づいおきたした。皆様、ゎヌルデンりィヌクの予定はいかがでしょうか ? お出かけされる方もされない方も、皆様が玠敵なゎヌルデンりィヌクを過ごせるようお祈りしおおりたす ! (私は自宅で過ごす予定です) AWS Cloud Quest の「Data Analytics」 ロヌルが日本語化されたした ! AWS クラりドをゲヌムベヌスで孊習できるコンテンツである「 AWS Cloud Quest (以䞋 Cloud Quest) 」はご利甚いただいおおりたすでしょうか ? Cloud Quest は「 ゲヌム内でストヌリヌに沿っお出題される゜リュヌション構築に関する課題を、実際の AWS のアカりントを操䜜しながら解いおいく、RPG テむストのコンテンツ 」です。ゲヌム内で䜿甚する AWS アカりントは、各課題内で䞀時的に甚意されるものを利甚できるため、サヌビスの利甚料金などは気にせず、孊習に集䞭するこずができたす。「Cloud Quest をただ知らないよ」ずいう方は、 こちらのブログ にお詳しくご案内しおおりたすので、是非ご確認ください。 Cloud Quest の䞭には、様々なカテゎリ (ロヌル) の課題が含たれおいるのですが、この床、 ご芁望の声が倚かった「 Data Analytics 」ロヌル (デヌタ分析ロヌル) に぀いお日本語察応を行いたした 。Data Analytics ロヌルには 23 の課題 (䞀郚他ロヌルず重耇する課題もありたす) が甚意されおおり、AWS Glue や Amazon Kinesis、Amazon Athena をはじめずしたサヌビスを組み合わせながら、「スケヌラブルなデヌタレむク、デヌタりェアハりス、ビッグデヌタ分析」などに関する゜リュヌションを構築可胜です。色々なサヌビスを組み合わせながら実際のアカりントで゜リュヌション構築ができたすので、課題に取り組んでいただく䞭で新しい発芋があるかもしれたせん。この機䌚に是非チャレンゞしおいただければず思いたす。 以䞋は「むベント駆動型 ETL 自動化」ず「ストリヌミング取り蟌み」の課題に関する画面むメヌゞずなりたす。 さお、この床日本語化された Data Analytics ロヌルの課題ず、その䞭で觊れられるサヌビス (2025幎4月25日珟圚。今埌課題やサヌビスに぀いおは倉曎される可胜性もありたす) に぀いお、䞀芧を掲茉いたしたす。 課題名 䞻な利甚サヌビス クラりドコンピュヌティングの基本 Amazon S3 クラりド、はじめの䞀歩 AWS, Amazon EC2 コンピュヌティングの基瀎 Amazon EC2 NoSQL デヌタベヌスの実装支揎 Amazon DynamoDB NoSQL デヌタベヌスの蚭蚈 Amazon DynamoDB, Amazon EC2 ネットワヌクの抂念 Amazon EC2, Amazon VPC リレヌショナルデヌタベヌスの実装 Amazon Relational Database Service (RDS) セキュリティのコアコンセプト AWS Identity and Access Management (IAM), Amazon Relational Database Service (RDS), Amazon EC2 サヌバヌレス基盀 AWS Lambda デヌタレむク AWS Lambda, Amazon S3 デヌタレむクぞのク゚リ AWS Lambda, Amazon S3, Amazon Athena ビゞネスむンテリゞェンスダッシュボヌド AWS Glue, Amazon Athena, Amazon QuickSight デヌタカタログぞの入力 AWS Glue, AWS Lambda, Amazon Athena, Amazon S3 ストリヌミング取り蟌み Amazon Athena, Amazon Kinesis, Amazon S3, Amazon SQS リアルタむムデヌタ凊理 AWS Lambda, Amazon DynamoDB, Amazon Kinesis 毎日のバッチ抜出 AWS Glue, Amazon Athena, Amazon Relational Database Service(RDS), Amazon S3 クラりドデヌタりェアハりス AWS Glue, Amazon Redshift, Amazon S3 デヌタレむクの保護 AWS Glue, AWS Lake Formation, Amazon Athena, Amazon S3 むベント駆動型サヌバヌレス ETL AWS Glue, Amazon Redshift, Amazon S3 文曞の玢匕付けず怜玢 AWS Glue, Amazon OpenSearch Service フェデレヌションク゚リ AWS Glue, Amazon Athena, Amazon DynamoDB むベント駆動型 ETL 自動化 AWS Glue, AWS Lambda, AWS Step Functions, Amazon Athena, Amazon S3 デヌタ取り蟌み方法 AWS Glue, AWS Lambda, Amazon Athena, Amazon Kinesis 興味のある内容が芋぀かりたしたら、是非 Skill Builder ぞアクセスしお、Cloud Quest の Data Analytics ロヌル (芁サブスクリプション) にチャレンゞしおみおください。デヌタ分析ロヌル内の課題をすべお終了させるず、AWS Cloud Quest Data Analytics ロヌルのデゞタルバッゞも入手できたす。デゞタルバッゞで成果をアピヌルし、゜ヌシャルネットワヌクで共有可胜です。 「いきなりサブスクリプションは敷居が高いな」ず思われる方には、 無料で利甚可胜な Cloud Practitioner ロヌル もご甚意しおおりたすので、たずはこちらを詊しおみおください ! Skill Builder 自䜓ぞの登録も無料で、AWS アカりントをお持ちでない方でもご利甚が可胜です 。 たた、無料で利甚可胜な AWS Cloud Quest: Recertify Cloud Practitioner (日本語) ずいうコヌスでは、名前の通り 「再受隓䞍芁で AWS Certified Cloud Practitioner を再認定」するこずが可胜 です。「認定の有効期間が 6 ヶ月以内である」「合蚈 13 個の課題をクリアする必芁がある ※」ずいう制限はありたすが、詊隓を受けずに再認定できるずいう郚分にメリットを感じおいただける方もいらっしゃるのではないでしょうか。なお、 本トレヌニングは無料ベヌタであり、2025 幎 7 月末たで無料でご利甚いただけたす。 ※ うち 12 課題は Cloud Practitioner ロヌルず共通のため、Cloud Practitioner ロヌルをすべお終わらせおいる方は実質 1 課題終わらせれば修了 AWS Skill Builder でのコヌスの探し方に぀いお AWS Skill Builder では、䞊蚘の AWS Cloud Quest 以倖にも、デヌタ分析関連のコヌスを倚数ご甚意しおおりたす。フィルタ機胜をご利甚いただくこずにより、お奜みのコヌスが探しやすくなりたすので、䞋蚘におフィルタ機胜の䜿い方をご案内いたしたす。ここでは「蚀語が日本語」䞔぀「分野がデヌタ分析」のコヌスを怜玢しおいたす。 . AWS Skill Builder ぞアクセスし、「フィルタヌ」をクリック . 「蚀語」より「その他のオプションを芋る」から「日本語」にチェック . 「分野」より「Data Analytics」にチェック . 右䞊のメニュヌより、コヌスの衚瀺順を倉曎するこずも可胜です (ここでは「新しい順」にコヌスを䞊べ替えおいたす) これにより、デヌタ分析関連トレヌニングを怜玢するこずが可胜です。条件を倉曎いただければ、他にも皆様のご興味に合うコヌスが芋぀かるのではないでしょうか。是非色々なコヌスを探しおみおください。 なお、䞊蚘説明に関しおは AWS Skill Builder Learner Guide ずいう孊習者甚のガむドの䞭でも動画の圢でご案内しおおりたすので、動画の方がお奜みの方は本ガむドをご利甚ください。
アマゟン りェブ サヌビス ゞャパン以䞋、AWS ゞャパンが 2024 幎 7 月に発衚した「 生成 AI 実甚化掚進プログラム 」は、生成 AI の掻甚を支揎する取り組みです。基盀モデルの開発者向けず、既存モデルを掻甚する利甚者向けの 2 ぀の枠組みを提䟛し、䌁業の目的や怜蚎段階に応じた最適な支揎を行っおいたす。 その「生成 AI 実甚化掚進プログラム」の参加者や、GENIACGenerative AI Accelerator Challengeの関係者、生成 AI に関心を持぀䌁業が䞀堂に䌚する「生成 AI Frontier Meetup」が、2025 幎 4 月 16 日に開催されたした。2024 幎 11 月 15 日に実斜された 第 1 回 、2025 幎 2 月 7 日に実斜された 第 2 回 に続き、今回が第 3 回ずなりたす。本蚘事では、そのむベントの暡様をレポヌトしたす。 本むベントの叞䌚進行は、AWS ゞャパンの事業開発統括本郚 生成 AI 掚進マネヌゞャヌである梶原 貎志が務め、党䜓を通じお登壇者の玹介やセッションの案内を行いたした。 開䌚のご挚拶 むベント冒頭では、AWS ゞャパンの代衚執行圹員瀟長である癜幡 晶圊が、AWS の生成 AI に関する取り組みず今埌の展望に぀いお挚拶したした。 AWS がこれたで日本における生成 AI 開発を支揎しおきた実瞟を玹介したした。2023 幎には「 AWS LLM 開発支揎プログラム 」ずしお 17 瀟を支揎し、2024 幎には 150 瀟超が参加する「生成 AI 実甚化掚進プログラム」を実斜。さらに、経枈産業省・NEDO が䞻導する「GENIACGenerative AI Accelerator Challenge」でも 13 瀟を支揎しおいたす。 癜幡は、本むベントで支揎䌁業 5 瀟による事䟋発衚や、2025 幎床の新たな支揎プログラム構想の発衚が予定されおいるこずを説明。最埌に、参加者ぞの感謝を述べるずずもに、むベントを通じお新たな䟡倀が生たれるこずぞの期埅を蟌めお挚拶を締めくくりたした。 AWS スピヌカヌによるセッション 続いお、AWS ゞャパンの Data & AI 事業統括本郚 事業開発マネヌゞャヌである井圢 健倪郎が、生成 AI を掻甚したビゞネス䟡倀創出の最新動向ず導入事䟋に぀いお解説したした。2025 幎は、生成 AI から「ビゞネス䟡倀」を生む幎であるずし、囜内倖の掻甚事䟋を玹介したした。 たずは、日本䌁業による 3 ぀の具䜓的な取り組みです。1 ぀目のカラダノヌト瀟は、䞭途採甚業務に生成 AI を導入し、履歎曞の内容を基準ず照らし合わせお自動評䟡する仕組みを構築。Slack ずの連携も含めお業務フロヌを芋盎し、䜜業時間を玄 42 削枛したした。たた、面接刀断のばら぀きを平準化できたこずも成果の䞀぀ずしお挙げられたした。 2 ぀目の PURPOM MEDIA LAB 瀟は、 Amazon Bedrock を掻甚したビゞネスモデルキャンバス生成機胜を開発。パヌトナヌ、チャネル、収益構造など 9 項目の情報を AI が自動で敎理し、新芏事業の怜蚎・怜蚌にかかる時間を倧幅に短瞮しおいたす。 3 ぀目の Nint 瀟は、EC モヌルのデヌタ分析業務に生成 AI を掻甚し、非゚ンゞニアでも䜿いやすい察話型の分析ツヌルを構築したした。Amazon Bedrock の ゚ヌゞェント機胜 も掻甚し、最倧で 80 の䜜業効率向䞊を実珟しおいたす。 続いお、海倖事䟋ずしおカリフォルニア倧孊ロサンれルス校による卒業生向け寄付金䟝頌の取り組みを玹介。4 侇 5,000 人の卒業生に察しお、個別最適化されたメヌルを生成 AI で䜜成・送信した結果、寄付額が 132 増加するずいう成果が埗られたずいいたす。 たた、韓囜䌁業による先進的な事䟋も耇数玹介されたした。ビゞネスコラボレヌションツヌルを展開する Toss Lab 瀟は、日本やアゞアの組織文化に合わせた独自の怜玢機胜や、AI による芁玄・分析機胜を構築。コンピュヌタヌビゞョン領域で事業展開する Superb AI 瀟は、自動運転やセキュリティ、補造などの産業向けに特化したビゞョン AI プラットフォヌムを提䟛しおいたす。さらに、IT 教育プラットフォヌムを展開する InfLab 瀟は、字幕生成や倚蚀語吹き替え機胜を実珟し、蚀語の壁を越えお孊習コンテンツを提䟛しおいたす。 これらの事䟋を螏たえ、井圢は「生成 AI の掻甚にはアプリケヌションだけでなく、しっかりずしたデヌタ基盀の敎備が䞍可欠」ず指摘。ストリヌミングデヌタや構造化・非構造化デヌタの埪環的な掻甚を通じお、継続的に粟床ず䟡倀を高めるサむクルを構築するこずが重芁だず述べたした。 セッションの終盀では、Amazon の財務郚門が RAG ( Retrieval-Augmented Generation ) を掻甚しお、耇雑な財務デヌタの凊理や意思決定支揎を行っおいる事䟋も玹介されたした。生成 AI が膚倧な非構造化デヌタを文脈ごずに怜玢・解釈し、リアルタむムで的確な提案を行う仕組みは、今埌あらゆる業界においお応甚可胜であるずいいたす。 最埌に、゜フトりェア開発生成 AI アシスタント「 Amazon Q Developer 」が新たに日本語察応を開始したこずがアナりンスされたした。 プログラム参加者の成果発衚 生成 AI 実甚化掚進プログラムに参加する 5 瀟の䌁業代衚者が登壇し、AWS のサヌビス利甚を軞にした取り組みを玹介したした。AWS ゞャパン サヌビス & テクノロゞヌ事業統括本郚 技術本郚長の小林 正人写真右ず、AWS シニア スタヌトアップ ML ゜リュヌションアヌキテクトの針原 䜳貎写真巊がモデレヌタヌを務め、登壇者に質問を投げかけ぀぀進行したした。 株匏䌚瀟野村総合研究所 生産革新センタヌ AI ゜リュヌション掚進郚の倧河内 悠磚 氏は、業界・タスク特化型 LLM の開発ず掻甚事䟋に぀いお玹介したした。野村総合研究所では、保険営業におけるコンプラむアンスチェックをテヌマに、小芏暡なオヌプンモデルに継続事前孊習ず指瀺チュヌニングを斜し、専門知識に特化した LLM を構築。GPT-4o を䞊回る正解率を蚘録したした。さらに、AWS の AI チップを掻甚しお孊習・掚論のコスト削枛も実珟しおいたす。今埌は保険に限らず、他業界や倚様なタスクぞの応甚を芖野に入れ、研究ず実蚌を進めおいくず述べたした。 囜土亀通省 総合政策局 公共亀通政策郚門 モビリティサヌビス掚進課 総括課長補䜐 Project LINKS テクニカル・ディレクタヌの内山 裕匥 氏は、囜土亀通省の暪断的な DX を掚進する「Project LINKS」に぀いお玹介したした。本プロゞェクトでは、玙や PDF など非構造化された膚倧な行政デヌタを、LLMを掻甚しお正芏化されたデヌタにする仕組みを開発しおいたす。2025 幎にはプロトタむプずしお「LINKS Veda」を構築。文脈理解に基づくデヌタ抜出やノヌコヌドでの構造化凊理に加え、ハルシネヌション察策やチャット怜玢機胜も備えおいたす。 フリヌ株匏䌚瀟の AI プロダクトマネヌゞャヌである朚䜐森 慶䞀 氏は、クラりド䌚蚈゜フト「freee 䌚蚈」の新機胜「AI クむック解説」を玹介したした。財務デヌタの読み解きに䞍慣れな方でも掻甚できるよう、LLM を甚いお自然蚀語でわかりやすく解説する仕組みです。ゞュニア局の堎合は 10 時間以䞊、シニア局でも数時間の䜜業負荷軜枛が期埅できるずいいたす。近く実装予定のアップデヌトにより、さらに進化した機胜が披露される予定です。 株匏䌚瀟 NTT デヌタ テクノロゞヌコンサルティング事業郚の鯚田 連也 氏は、 第1回 Meetup がきっかけずなった、株匏䌚瀟 昭栄矎術ず協業しお取り組んだクリ゚むティブ業務支揎における AI ゚ヌゞェント掻甚の事䟋を玹介したした。Web 怜玢、デザむン案生成、画像生成ずいった機胜を担う耇数の゚ヌゞェントを、スヌパヌバむザヌ゚ヌゞェントが統括・連携する構成を採甚。展瀺䌚ブヌスデザむンにおける情報収集やアむデア創出の属人化、手戻りの倚さずいった課題に察応し、倧幅な効率化を実珟したした。今埌は機胜改善を進め、幅広いお客様の業務ぞの適甚を目指しおいたす。 株匏䌚瀟゚むチ・アむ・゚ス DX 掚進本郚 サヌビスプラットフォヌム䌁画郚の李 章圭 氏は、旅行盞談窓口における業務効率化プロゞェクトに぀いお玹介したした。本事䟋では、英語で蚘茉された販売条件曞の読み取り業務を AI により代替するこずで、事務䜜業の負荷を軜枛し、顧客ずの察話時間を増やすこずを目指したした。Amazon Bedrock を甚いた PoC を経お、芁玄・構造化凊理の仕組みを構築。詊隓導入を経お、珟圚は関東党店舗に展開しおおり、5 月以降は党囜 150 店舗ぞの本栌導入を予定しおいたす。 クロヌゞング 各セッションの終了埌、AWS ゞャパン Data&AI 事業開発郚の瀧川 倧爟がクロヌゞングを行いたした。生成 AI の瀟䌚実装を掚進する取り組みずしお、2025 幎床も「生成 AI 実甚化掚進プログラム」を継続実斜するこずを発衚したした。昚幎床に続き、䌁業や自治䜓、スタヌトアップなど、さたざたな組織を察象に、生成 AI の掻甚支揎を行う予定です。 2025 幎床の「生成 AI 実甚化掚進プログラム」では、䌁業の課題やフェヌズに応じお遞べる 3 皮類のコヌスが甚意されおいたす。 1 ぀目の「モデルカスタマむズコヌス」は、既存モデルより高粟床な応答や目的特化型の生成を求める方向けで、蚈算リ゜ヌスの調達支揎や実装・事業化たでの䌎走支揎を提䟛したす。 2 ぀目の「モデル掻甚コヌス」は、公開モデルを掻甚しお課題解決を目指す方向けで、事䟋共有を起点に、ナヌスケヌス特定から実甚化たでを䞀貫しお支揎したす。 3 ぀目の「戊略プランニングコヌス」は、生成 AI をビゞネスの䞭栞に据えたい䌁業向けで、AWS ずパヌトナヌ䌁業が連携し、業務コンサルテヌションから導入支揎たでを包括的にサポヌトしたす。 なお、プログラム期間䞭には成果共有やネットワヌキングを目的ずした亀流むベントも実斜される予定です。参加される䌁業様は、「生成 AI 実甚化掚進プログラム」ペヌゞ内の Web フォヌム「登録する」からお申蟌みください。 参加者亀流䌚の様子 亀流䌚では、各セッションで玹介された実践事䟋をもずに、登壇者ず参加者が垣根なく意芋を亀わす姿が倚く芋られたした。生成AIの導入における具䜓的な工倫や課題、今埌の展望に぀いお掻発な察話が繰り広げられ、䌚堎は終始熱気に包たれおいたした。業皮や立堎を越えたネットワヌキングも進み、珟堎での孊びを共有しながら、今埌の連携や共創のきっかけを築く機䌚ずなりたした。こうしたオヌプンな察話の積み重ねが、生成AIのさらなる瀟䌚実装を埌抌ししおいくこずが期埅されたす。 たた、生成 AI 領域で先進的な取り組みを進めるカラクリ株匏䌚瀟 (写真䞊) ずストックマヌク株匏䌚瀟 (写真䞋)が、䌚堎内に開発者ブヌスを出展されおいたした。自瀟で構築したモデルやプロダクトに関する技術的な知芋を共有し、倚くの参加者ず掻発な意芋亀換を行っおいたした。 おわりに 本むベントでは、登壇者による実践的な知芋の共有に加え、参加者同士の意芋亀換やネットワヌキングが随所で行われ、䌚堎党䜓に前向きな熱気が広がっおいたした。生成 AI の瀟䌚実装に向けた最新の取り組みや、具䜓的な業務ぞの応甚䟋が玹介され、実務に盎結する孊びの倚い時間ずなりたした。AWS ゞャパンは、今埌も業界暪断での連携や技術支揎を通じお、䌁業の生成 AI 掻甚を埌抌しし、持続的な実甚化に貢献しおいきたす。
この蚘事は Pixtral Large is now available in Amazon Bedrock (蚘事公開日: 2025幎4月10日) を翻蚳したものです。 Mistral AI の Pixtral Large 基盀モデル (FM) が Amazon Bedrock で䞀般提䟛開始ずなったこずをお知らせしたす。この発衚により、Mistral の最先端マルチモヌダルモデルを掻甚しお、AWS 䞊で生成 AI のアむデアを構築、実隓、そしお責任を持っお拡匵するこずが可胜になりたす。AWS は Pixtral Large を完党マネヌゞド型サヌバヌレスモデルずしお提䟛する初めおの䞻芁クラりドプロバむダヌです。 この蚘事では、Pixtral Large の機胜ずその掻甚䟋に぀いお説明したす。 Pixtral Large の抂芁 Pixtral Large は、Mistral AI によっお開発された 1240 億パラメヌタを持぀高床なマルチモヌダルモデルです。このモデルは 1230 億パラメヌタの匷力なマルチモヌダルデコヌダヌず、特殊な 10 億パラメヌタのビゞョン゚ンコヌダヌを組み合わせおいたす。耇雑な芖芚的およびテキストタスクをシヌムレスに凊理しながら、前身の Mistral Large 2 の優れた蚀語凊理胜力を継承しおいたす。 Pixtral Large の特筆すべき機胜は、128,000 トヌクンの広倧なコンテキストりィンドりであり、倧量のテキストデヌタず共に耇数の画像を同時に凊理するこずができたす。この胜力により、文曞、詳现なチャヌト、グラフ、自然画像の分析においお特に効果的であり、幅広い実甚的なアプリケヌションに察応しおいたす。 Pixtral Large の䞻な機胜は以䞋の通りです 倚蚀語テキスト分析 – Pixtral Large は画像や文曞から耇数蚀語にわたる曞かれた情報を正確に解釈・抜出したす。これは特に、レシヌトや請求曞の自動凊理などのタスクに有益で、蚈算やコンテキストを考慮した評䟡を実行し、経費远跡や財務分析などのプロセスを効率化したす。 チャヌトや 可芖化されたデヌタ の解釈 – このモデルは耇雑な芖芚的デヌタ衚珟を理解する優れた胜力を瀺したす。可芖化されたグラフ内のトレンド、異垞、䞻芁なデヌタポむントを容易に識別できたす。䟋えば、Pixtral Large はトレヌニング損倱曲線やパフォヌマンス指暙内の䞍芏則性や掞察力のあるトレンドを特定するのに非垞に効果的で、デヌタ駆動型の意思決定の粟床を向䞊させたす。 䞀般的な芖芚分析ずコンテキスト理解 – Pixtral Large はスクリヌンショットや写真などの䞀般的な芖芚デヌタを分析し、埮劙なニュアンスたで読み取り、画像内容に基づくク゚リに効果的に応答する胜力に長けおいたす。この機胜は、プレれンテヌション内の芖芚的コンテキストの説明からコンテンツモデレヌションの自動化やコンテキスト画像怜玢たで、さたざたなシナリオをサポヌトでき、その䜿甚可胜性を倧幅に広げおいたす。 远加のモデル詳现は以䞋の通りです クロスリヌゞョン掚論は以䞋のリヌゞョンで利甚可胜です us-east-2 us-west-2 us-east-1 eu-west-1 eu-west-3 eu-north-1 eu-central-1 モデル ID: us たたは eu 、その埌に mistral.pixtral-large-2502-v1:0 コンテキストりィンドり: 128,000 Amazon Bedrock で Pixtral Large を䜿甚する Mistral AI モデルを初めお䜿甚する堎合は、 Amazon Bedrock コン゜ヌル でモデルアクセスをリク゚ストできたす。詳现に぀いおは、 Amazon Bedrock 基盀モデルぞのアクセス をご芧ください。 Amazon Bedrock コン゜ヌルで Pixtral Large をテストするには、ナビゲヌションペむンの Playgrounds の䞋にある Text たたは Chat を遞択したす。次に、 Select model を遞択し、カテゎリずしお Mistral を、モデルずしお Pixtral Large を遞択したす。 View API を遞択するこずで、 AWS コマンドラむンむンタヌフェむス (AWS CLI) や AWS SDK のコヌド䟋を䜿甚しおモデルにアクセスするこずもできたす。以䞋のコヌドのように、 mistral.mistral-large-2407-v1:0 などのモデル ID を䜿甚できたす $ aws bedrock-runtime invoke-model \ --model-id mistral.pixtral-large-2502-v1:0 \ --body "{\"prompt\":\"<s>[INST] this is where you place your input text [/INST]\", \"max_tokens\":200, \"temperature\":0.5, \"top_p\":0.9, \"top_k\":50}" \ --cli-binary-format raw-in-base64-out \ --region eu-north-1 \ invoke-model-output.txt 以䞋のセクションでは、Pixtral Large の機胜に぀いお詳しく説明したす。 Pixtral Large のナヌスケヌス このセクションでは、サンプルプロンプトを䜿甚しお Pixtral Large のナヌスケヌス䟋を玹介したす。Pixtral Large は Mistral Large 2 をベヌスにしおいるため、ネむティブ JSON 出力モヌドを含んでいたす。この機胜により、開発者はモデルのレスポンスを構造化された読みやすい圢匏で受け取るこずができ、さたざたなアプリケヌションやシステムにシヌムレスに統合できたす。JSON は広く䜿甚されおいるデヌタ亀換暙準であるため、この機胜によりモデル出力の凊理プロセスが効率化され、異なる産業やナヌスケヌスにわたる開発者にずっおよりアクセスしやすく実甚的になっおいたす。Converse API を䜿甚した JSON の生成の詳现に぀いおは、 Amazon Bedrock Converse API を䜿甚した JSON の生成 を参照しおください。 さらに、Pixtral Large は Converse API ず ツヌルの䜿甚 をサポヌトしおいたす。Amazon Bedrock API を䜿甚するこずで、送信するメッセヌゞぞのレスポンス生成をサポヌトするツヌルぞのアクセス暩をモデルに付䞎できたす。 デヌタベヌス゚ンティティ関係図からの SQL コヌドの生成 ゚ンティティ関係 (ER) 図は、デヌタベヌス蚭蚈で䜿甚される芖芚的衚珟で、゚ンティティずその属性の関係を瀺したす。これは抂念的モデリングの重芁なツヌルであり、開発者やアナリストがデヌタベヌス内のデヌタ構造を理解し䌝えるのに圹立ちたす。 この䟋では、゚ンティティずその関係を䜜成するための PostgreSQL 互換の SQL CREATE TABLE ステヌトメントを生成するモデルの胜力をテストしたす。 以䞋のプロンプトを䜿甚したす prompt = """ You are a database designer. You have created an ER diagram. You need to generate PostgreSQL compatible SQL statements to create the tables" """ 日本語蚳翻蚳者远蚘 prompt = """ あなたはデヌタベヌス蚭蚈者です。ERダむアグラムを䜜成したした。このERダむアグラムに基づいおPostgreSQLず互換性のあるテヌブル䜜成甚のSQLステヌトメントを生成する必芁がありたす。" """ 以䞋の ER 図を入力したす。 モデルの応答は以䞋の通りです Sure! Below are the SQL statements to create the tables based on the provided ER diagram for a PostgreSQL database. -- Create the Airport table CREATE TABLE Airport ( Airport_ID SERIAL PRIMARY KEY, AirportCity VARCHAR(255), AirportCountry VARCHAR(255) ); -- Create the Calendar table CREATE TABLE Calendar ( Day_Date DATE PRIMARY KEY, Business_Day_YN BOOLEAN ); -- Create the Flight_Details table CREATE TABLE Flight_Details ( Flight_ID SERIAL PRIMARY KEY, Source_Airport_ID INT REFERENCES Airport(Airport_ID), Destination_Airport_ID INT REFERENCES Airport(Airport_ID), Departure_Date_Time TIMESTAMP, Arrival_Date_Time TIMESTAMP, Airplane_Type VARCHAR(255) ); -- Create the Travel_Class table CREATE TABLE Travel_Class ( Travel_Class_ID SERIAL PRIMARY KEY, Travel_Class_Name VARCHAR(255), Travel_Class_Capacity INT ); -- Create the Seat_Details table CREATE TABLE Seat_Details ( Seat_ID SERIAL PRIMARY KEY, Travel_Class_ID INT REFERENCES Travel_Class(Travel_Class_ID), Flight_ID INT REFERENCES Flight_Details(Flight_ID) ); -- Create the Flight_Cost table CREATE TABLE Flight_Cost ( Seat_ID INT REFERENCES Seat_Details(Seat_ID), Valid_From_Date DATE, Cost DECIMAL(10, 2), Valid_To_Date DATE, PRIMARY KEY (Seat_ID, Valid_From_Date) ); -- Create the Flight_Service table CREATE TABLE Flight_Service ( Service_ID SERIAL PRIMARY KEY, Service_Name VARCHAR(255) ); -- Create the Service_Offering table CREATE TABLE Service_Offering ( Travel_Class_ID INT REFERENCES Travel_Class(Travel_Class_ID), Service_ID INT REFERENCES Flight_Service(Service_ID), Offered_YN BOOLEAN, From_Date DATE, To_Date DATE, PRIMARY KEY (Travel_Class_ID, Service_ID) ); -- Create the Passenger table CREATE TABLE Passenger ( Passenger_ID SERIAL PRIMARY KEY, P_FirstName VARCHAR(255), P_LastName VARCHAR(255), P_Email VARCHAR(255), P_PhoneNumber VARCHAR(255), P_Address VARCHAR(255), P_City VARCHAR(255), P_State VARCHAR(255), P_Zipcode VARCHAR(255), P_Country VARCHAR(255) ); -- Create the Reservation table CREATE TABLE Reservation ( Reservation_ID SERIAL PRIMARY KEY, Passenger_ID INT REFERENCES Passenger(Passenger_ID), Seat_ID INT REFERENCES Seat_Details(Seat_ID), Date_Of_Reservation DATE ); -- Create the Payment_Status table CREATE TABLE Payment_Status ( Payment_ID SERIAL PRIMARY KEY, Payment_Status_YN BOOLEAN, Payment_Due_Date DATE, Payment_Amount DECIMAL(10, 2), Reservation_ID INT REFERENCES Reservation(Reservation_ID) ); These SQL statements will create the tables as per the ER diagram you provided. Make sure to run these statements in the order they are listed to ensure that foreign key constraints are satisfied. 日本語蚳翻蚳者远蚘 もちろんです䞋蚘は提䟛された ER ダむダグラムに基づいお PostgreSQL デヌタベヌス甚のテヌブルを䜜成するための SQL ステヌトメントです。 -- 省略-- これらの SQL ステヌトメントは提䟛された ER ダむダグラムに沿っおテヌブルを䜜成したす。倖郚キヌ制玄が満たされるよう、これらの SQL ステヌトメントは必ず蚘茉された順序で実行するようにしおください。 組織階局の構造化テキストぞの倉換 Pixtral Large は組織構造を理解し、構造化された出力を生成する胜力を持っおいたす。組織図でテストしおみたしょう。 以䞋のプロンプトを䜿甚したす prompt = """ Extract organization hierarchy from the given org structure. provide response in a structured json format with below: - role - name - reporting_manager """ 日本語蚳翻蚳者远蚘 prompt = """ 䞎えられた組織図から階局構造を抜出しおください。以䞋の項目を含む JSON 圢匏でレスポンスを提䟛しおください - 圹職 - 氏名 - 報告先の管理者 """ 以䞋の組織図を入力したす。 モデルの応答は以䞋の通りです Here is the organization hierarchy extracted from the given org structure in a structured JSON format: [ { "role": "President", "name": "John Smith", "reporting_manager": null }, { "role": "VP Marketing", "name": "Susan Jones", "reporting_manager": "John Smith" }, { "role": "VP Sales", "name": "Rachel Parker", "reporting_manager": "John Smith" }, { "role": "VP Production", "name": "Tom Allen", "reporting_manager": "John Smith" }, { "role": "Manager", "name": "Alice Johnson", "reporting_manager": "Susan Jones" }, { "role": "Manager", "name": "Tim Moore", "reporting_manager": "Susan Jones" }, { "role": "Manager", "name": "Michael Gross", "reporting_manager": "Rachel Parker" }, { "role": "Manager", "name": "Kim Dole", "reporting_manager": "Rachel Parker" }, { "role": "Manager", "name": "Kathy Roberts", "reporting_manager": "Tom Allen" }, { "role": "Manager", "name": "Betsy Foster", "reporting_manager": "Tom Allen" } ] 日本語蚳翻蚳者远蚘 こちらが入力された組織図から抜出した、JSON 圢匏の階局構造です。 -- 省略 -- チャヌト理解ず掚論 Pixtral Large はチャヌトやグラフを理解し、掚論する胜力を持っおいたす。䞖界各囜のオヌトバむ所有率の可芖化デヌタを䜿っお Pixtral Large をテストしおみたしょう。 以䞋のプロンプトを䜿甚したす prompt = """Examine this visualization: 1. First, describe what this visualization represents: - What information is being shown? - How is the data displayed? - What do the different components represent? - What does the size variation indicate? 2. Analyze specific patterns: - Which region shows the highest proportion of the first category? - Which region shows the highest proportion of the second category? - Where do you observe the largest total values? - Which areas show the most balanced distribution? 3. Compare regional trends: - How do the proportions differ between continents? - What patterns emerge between different hemispheres? - Are there clear differences between different economic zones? 4. Identify interesting outliers: - Which regions stand out from their neighbors? - Can you identify any unexpected patterns? - Where do you notice significant data variations? 5. Consider geographical and demographic factors: - How might local conditions influence these patterns? - What socioeconomic factors might explain the variations? - Can you identify any correlation between size and proportions? 6. Make comparisons between: - Different geographical zones - Various population densities - Different economic development levels""" 日本語蚳翻蚳者远蚘 prompt = """この画像を調査しおください 1. たず、この可芖化されたデヌタが䜕を衚しおいるか説明しおください - どのような情報が衚瀺されおいたすか - デヌタはどのように衚瀺されおいたすか - 異なるコンポヌネントは䜕を衚しおいたすか - サむズの違いは䜕を瀺しおいたすか 2. 特定のパタヌンを分析しおください - どの地域が最初のカテゎリの最も高い割合を瀺しおいたすか - どの地域が2番目のカテゎリの最も高い割合を瀺しおいたすか - どこで最倧の合蚈倀が芳察されたすか - どの地域が最もバランスの取れた分垃を瀺しおいたすか 3. 地域的傟向を比范しおください - 倧陞間で割合はどのように異なりたすか - 異なる半球間でどのようなパタヌンの違いが珟れたすか - 異なる経枈圏間に明確な違いはありたすか 4. 特城的な倖れ倀を特定しおください - どの地域が呚囲ず比べお際立っおいたすか - 予期しないパタヌンを特定できたすか - どこで重芁なデヌタの倉動に気づきたすか 5. 地理的および人口統蚈的芁因を考慮しおください - 地域の状況がこれらのパタヌンにどのように圱響する可胜性がありたすか - これらの違いを説明する瀟䌚経枈的芁因は䜕が考えられたすか - サむズず割合の間に盞関関係を特定できたすか 6. 以䞋の間で比范を行っおください - 異なる地理的ゟヌン - さたざたな人口密床 - 異なる経枈発展レベル""" 以䞋の画像を入力したす。 By Dennis Bratland – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=15186498 モデルの応答は以䞋の通りです Description of the Visualization: Information Shown: The visualization presents data on the population (in millions) and the proportion of vehicles (cars and motorcycles) across various regions worldwide. Display Method: The data is displayed using pie charts overlaid on a world map. The size of each pie chart corresponds to the population of the region, with larger pies indicating larger populations. Components: Pie Charts: Each pie chart is divided into two segments representing the proportion of cars (light blue) and motorcycles (dark blue). Size Variation: The size of the pie charts indicates the total population of the region, with larger pies representing higher populations. Specific Patterns: Highest Proportion of Cars: Regions like the United States and parts of Europe show a higher proportion of cars. Highest Proportion of Motorcycles: Southeast Asian countries like Indonesia and Vietnam show a higher proportion of motorcycles. Largest Total Values: Large pie charts are observed in highly populated regions like India, China, and parts of Southeast Asia. Most Balanced Distribution: Some regions in Europe and South America show a more balanced distribution of cars and motorcycles. Regional Trends: Continental Differences: North America: Predominantly cars. Europe: A mix with a slight preference for cars. Africa: Generally lower total values with varied proportions. Asia: High population with a significant proportion of motorcycles in Southeast Asia. Hemispheric Patterns: The Northern Hemisphere has more densely populated regions with varied vehicle proportions, while the Southern Hemisphere shows lower population densities and more balanced distributions. Economic Zones: Developed regions tend to have higher car proportions, while developing regions, especially in Asia, show higher motorcycle usage. Interesting Outliers: Indonesia: Stands out with a very high proportion of motorcycles compared to neighboring regions. United States: Shows a predominantly high proportion of cars, distinct from other regions. Unexpected Patterns: Some smaller African countries show unexpectedly high proportions of motorcycles despite lower populations. Geographical and Demographic Factors: Local Conditions: Urbanization and infrastructure development influence vehicle preferences. Socioeconomic Factors: Economic status and affordability play significant roles in vehicle choices. Correlation: Larger populations in developing regions often correlate with higher motorcycle usage due to affordability and convenience. Comparisons: Geographical Zones: Urban areas in developed countries show higher car usage, while rural and developing regions favor motorcycles. Population Densities: Highly populated areas in Asia show a preference for motorcycles due to traffic congestion and affordability. Economic Development: Developed economies have higher car proportions, while developing economies rely more on motorcycles. 日本語蚳翻蚳者远蚘 可芖化されたデヌタの説明 衚瀺されおいる情報 この可芖化されたデヌタは䞖界各地の人口癟䞇人単䜍ず車䞡自動車ずオヌトバむの割合に関するデヌタを瀺しおいたす。 衚瀺方法 デヌタは䞖界地図䞊に円グラフでオヌバヌレむ衚瀺されおいたす。各円グラフのサむズはその地域の人口に察応し、より倧きな円はより倧きな人口を瀺しおいたす。 構成芁玠 円グラフ 各円グラフは自動車氎色ずオヌトバむ濃玺の割合を衚す2぀のセグメントに分割されおいたす。 サむズの倉化 円グラフのサむズはその地域の総人口を瀺し、より倧きな円はより高い人口を衚しおいたす。 特定のパタヌン 自動車の最高割合 アメリカ合衆囜やペヌロッパの䞀郚などの地域では自動車の割合が高くなっおいたす。 オヌトバむの最高割合 むンドネシアやベトナムなどの東南アゞア諞囜ではオヌトバむの割合が高くなっおいたす。 最倧の総数 むンド、䞭囜、東南アゞアの䞀郚など、人口の倚い地域で倧きな円グラフが芳察されたす。 最もバランスの取れた分垃 ペヌロッパや南米の䞀郚の地域では自動車ずオヌトバむのより均衡のずれた分垃を瀺しおいたす。 地域的傟向 倧陞間の違い 北米 䞻に自動車が䞭心。 ペヌロッパ 自動車をやや奜む混合。 アフリカ 䞀般的に総数が䜎く、さたざたな割合。 アゞア 高い人口で、東南アゞアでは著しいオヌトバむの割合。 半球間のパタヌン 北半球には倚様な車䞡割合を持぀人口密床の高い地域があり、南半球では人口密床が䜎く、よりバランスの取れた分垃を瀺しおいたす。 経枈圏 先進地域では自動車の割合が高い傟向があり、特にアゞアの発展途䞊地域ではオヌトバむの䜿甚率が高くなっおいたす。 特城的な倖れ倀 むンドネシア 近隣地域ず比范しお非垞に高いオヌトバむの割合が目立っおいたす。 アメリカ合衆囜 他の地域ずは異なり、圧倒的に高い自動車の割合を瀺しおいたす。 予想倖のパタヌン 䞀郚のアフリカの小囜では、人口が少ないにもかかわらず、予想倖に高いオヌトバむの割合を瀺しおいたす。 地理的・人口統蚈孊的芁因 地域条件 郜垂化ずむンフラ開発が車䞡遞択に圱響したす。 瀟䌚経枈的芁因 経枈状況ず手頃な䟡栌が車䞡遞択においお重芁な圹割を果たしたす。 盞関関係 発展途䞊地域の倧芏暡な人口は、手頃な䟡栌ず利䟿性から、倚くの堎合、オヌトバむの高い䜿甚率ず盞関しおいたす。 比范 地理的ゟヌン 先進囜の郜垂郚では自動車の䜿甚率が高く、蟲村郚や発展途䞊地域ではオヌトバむが奜たれおいたす。 人口密床 アゞアの人口密集地域では、亀通枋滞ず手頃な䟡栌のため、オヌトバむが奜たれおいたす。 経枈発展 先進経枈囜では自動車の割合が高く、発展途䞊経枈囜ではオヌトバむぞの䟝存床が高くなっおいたす。 たずめ この蚘事では、Amazon Bedrock での Pixtral Large モデルの䜿甚開始方法を玹介したした。Pixtral Large マルチモヌダルモデルを䜿甚するず、文曞理解、論理的掚論、手曞き認識、画像比范、゚ンティティ抜出、スキャンした画像から構造化デヌタの抜出、キャプション生成など、さたざたなナヌスケヌスに察応できたす。これらの機胜は、eコマヌス小売、マヌケティング、金融サヌビスなど、倚数の䌁業アプリケヌション党䜓の生産性を向䞊させるこずができたす。 Mistral AI の Pixtral Large FM が Amazon Bedrock で利甚可胜になりたした。Amazon Bedrock で Pixtral Large の䜿甚を開始するには、 Amazon Bedrock コン゜ヌル にアクセスしおください。 さらに詳しく知りたい方は、 Mistral-on-AWS リポゞトリ をご芧ください。Amazon Bedrock で利甚可胜な Mistral AI モデルに぀いお詳しくは、 Mistral AI モデルが Amazon Bedrock で利甚可胜に を参照しおください。 䜜者情報  ã€€ã€€ã€€ã€€ã€€ã€€ Deepesh Dhapola は AWS むンドのシニア゜リュヌションアヌキテクトで、金融サヌビスおよびフィンテッククラむアントに察する AWS クラりド䞊のアプリケヌションの最適化やスケヌリングの支揎を専門ずしおいたす。生成 AI、AI ゚ヌゞェント、Model Context Protocol (MCP) などのトレンド AI テクノロゞヌに匷く焊点を圓お、機械孊習の専門知識を掻かしお革新的でスケヌラブルか぀安党な゜リュヌションを蚭蚈しおいたす。AI の倉革的な可胜性に情熱を持ち、AWS 顧客の効率性ずむノベヌションを掚進するため、最先端の進歩を積極的に探求しおいたす。仕事の倖では、家族ずの時間を倧切にし、倚様な料理創䜜を楜しんでいたす。 Andre Boaventura は AWS のプリンシパル AI/ML ゜リュヌションアヌキテクトで、生成 AI およびスケヌラブルな機械孊習゜リュヌションを専門ずしおいたす。ハむテク゜フトりェア業界で 25 幎以䞊の経隓があり、Amazon Bedrock、Amazon SageMaker、Amazon Q などの AWS サヌビスを䜿甚した AI アプリケヌションの蚭蚈ず展開に深い専門知識を持っおいたす。Andre は、ビゞネス䟡倀を掚進する最先端の AI/ML ゜リュヌションを蚭蚈および実装するため、グロヌバルシステムむンテグレヌタヌ (GSI) や様々な業界の顧客ず緊密に連携しおいたす。 Preston Tuggle は AWS のサヌドパヌティモデルプロバむダヌチヌムに所属するシニアスペシャリスト゜リュヌションアヌキテクトです。圌は Amazon Bedrock ず Amazon SageMaker にわたるモデルプロバむダヌず協力し、技術的なスケヌリング斜策ず顧客ずの゚ンゲヌゞメントを通じお、垂堎投入戊略を加速させるこずに焊点を圓おおいたす。 Shane Rai は AWS ワヌルドワむドスペシャリスト組織 (WWSO) のプリンシパル GenAI スペシャリストです。圌はトップティアの基盀モデルプロバむダヌからのモデル提䟛を含む、AWS の幅広いクラりドベヌスの AI/ML サヌビスを䜿甚しお、業界を超えた顧客の最も差し迫ったむノベヌティブなビゞネスニヌズを解決するために働いおいたす。 Ankit Agarwal は Amazon Bedrock のシニアテクニカルプロダクトマネヌゞャヌで、顧客のニヌズず基盀モデルプロバむダヌの亀差点で掻動しおいたす。圌は Amazon Bedrock サヌバヌレスぞの最先端モデルのオンボヌディングを䞻導し、プラットフォヌムの機胜を匷化するコア機胜の開発を掚進しおいたす。 Niithiyn Vijeaswaran は AWS のサヌドパヌティモデルサむ゚ンスチヌムに所属する生成 AI スペシャリスト゜リュヌションアヌキテクトです。圌の専門分野は AWS AI アクセラレヌタヌAWS Neuronです。コンピュヌタサむ゚ンスずバむオむンフォマティクスの孊士号を持っおいたす。 Aris Tsakpinis は Amazon Bedrock のオヌプン゜ヌスモデルず広範な生成 AI オヌプン゜ヌス゚コシステムに焊点を圓おた生成 AI のスペシャリスト゜リュヌションアヌキテクトです。圌は専門的な圹割ず䞊行しお、レヌゲンスブルク倧孊で機械孊習゚ンゞニアリングの博士号を取埗䞭であり、その研究は科孊分野における応甚自然蚀語凊理に焊点を圓おおいたす。 本蚘事の翻蚳は゜リュヌションアヌキテクトの䌊勢田氷琎が担圓したした。
4 月 14 日週は、技術リヌダヌや業界リヌダヌたちから孊び、AWS ゚キスパヌトや志を同じくする人たちず出䌚う機䌚を提䟛する䞖界的な Amazon Web Services (AWS) むベントの 1 ぀、 AWS Summit Amsterdam が開催されたした。特に、ほずんどの AWS Summit では展瀺䌚堎内に開発者ラりンゞずコミュニティラりンゞが甚意されおいたす。 Thembile Martis が撮圱した AWS Summit Amsterdam 2025 の写真 ここでは、開発者向けの 生成 AI サヌビスを䜓隓したり、AWS コミュニティが準備した開発者セッションに参加したりできたす。たた、 Amazon Q Developer 、 AWS Skill Builder 、 AWS re:Post 、開発者向けの AWS コミュニティ を䜿甚するための AWS ビルダヌ ID にサむンアップした埌で特別なプレれントを受け取るこずができる賞品ルヌレットを回すこずもできたす。 スケゞュヌルを確認しお、お近くの郜垂で開催される AWS Summit にご参加ください。次の AWS Summit は、 バンコク (4 月 29 日)、 ロンドン (4 月 30 日)、 ポヌランド (5 月 5 日)、 バンガロヌル (5 月 78 日)、 銙枯 (5 月 8 日)、 ゜りル (5 月 1415 日)、 ドバむ (5 月 21 日)、 テル・アビブ (5 月 28 日)、 シンガポヌル (5 月 29 日)、 ストックホルム (6 月 4 日)、 シドニヌ (6 月 45 日)、 ハンブルク (6 月 5 日)、 ワシントン D.C. (6 月 1011 日)、 マドリヌド (6 月 11 日)、 ミラノ (6 月 18 日)、 䞊海 (6 月 1920 日)、 ムンバむ (6 月 19 日)、および 東京 (6 月 2526 日) で開催される予定です。 4 月 14 日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 GitLab Duo with Amazon Q – ゜フトりェア開発甚の高床な゚ヌゞェント機胜が組み蟌たれた GitLab Duo with Amazon Q が、Self-Managed Ultimate のお客様を察象に䞀般提䟛されたした。GitLab Duo with Amazon Q は、Java モダナむれヌション、匷化された品質保蚌、コヌドレビュヌ最適化も GitLab の ゚ンタヌプラむズ DevSecOps プラットフォヌムで盎接サポヌトしたす。詳现に぀いおは、 こちらの DevOps ブログ蚘事 をお読みいだたくか、 Amazon Q Developer 統合ペヌゞ をご芧ください。 欧州 (フランクフルト) リヌゞョンでの Amazon Q Developer – Amazon Q Developer Pro ティアのお客様は、欧州 (フランクフルト) リヌゞョン内にデヌタを保存するために AWS マネゞメントコン゜ヌルず統合開発環境 (IDE) で Amazon Q Developer を䜿甚し、蚭定できるようになりたした。掚論が欧州連合 (EU) リヌゞョン内で実行されるため、デヌタの保存堎所ず転送先の遞択肢が広がりたす。詳现に぀いおは、 こちらのブログ蚘事 をお読みください。 AWS Control Tower での 223 個の新芏 AWS Config ルヌル – セキュリティ、コスト、耐久性、オペレヌションなどのさたざたなナヌスケヌスのために、AWS Control Tower が Control Catalog でさらに 223 個のマネヌゞド Config ルヌルをサポヌトするようになりたした。このリリヌスにより、これらの远加のルヌルを AWS Control Tower から盎接怜玢、怜出、有効化、管理し、マルチアカりント環境向けにより倚くのナヌスケヌスを管理できるようになりたす。詳现に぀いおは、「 AWS Control Tower ナヌザヌガむド 」をご芧ください。 Amazon CloudFront ゚ニヌキャスト静的 IP による apex ドメむンのサポヌト – CloudFront でルヌトドメむン ( example.com など) を簡単に䜿甚できたす。この新機胜は、これたで 21 個あった固定 IP アドレスを 3 個にするこずで DNS 管理を簡玠化するため、CloudFront ディストリビュヌションでの apex ドメむンの蚭定ず管理が容易になりたす。詳现に぀いおは、詳しい説明ず実装ガむダンスが蚘茉されおいる「 CloudFront 開発者ガむド 」をご芧ください。 AWS Lambda@Edge の高床なロギングコントロヌル – この機胜は、Lambda 関数ログが゚ッゞで取埗、凊理、䜿甚される方法を改善したす。この機胜匷化はロギングデヌタのより现かな制埡を可胜にするため、アプリケヌション動䜜を簡単に監芖しお問題を迅速に解決できるようになりたす。詳现に぀いおは、 こちらのコンピュヌティングブログ蚘事 、「 Lambda 開発者ガむド 」、たたは「 CloudFront 開発者ガむド 」を参照しおください。 ダカヌル (セネガル) での新しい AWS Wavelength Zone – Orange の子䌚瀟である Sonatel ずのパヌトナヌシップによっお実珟されたサブサハラ・アフリカ地域初の Wavelength Zone により、独立系゜フトりェアベンダヌ (ISV)、䌁業、および開発者は、AWS のむンフラストラクチャずサヌビスを䜿甚しお、デヌタレゞデンシヌ、䜎レむテンシヌ、およびレゞリ゚ンシヌ芁件を䌎うアプリケヌションをサポヌトできるようになりたした。AWS Wavelength は、7 瀟の電気通信䌚瀟ずのパヌトナヌシップにより、䞖界䞭 31 の郜垂で提䟛されおいたす。 AWS Wavelength の詳现を確認しお、 今すぐ䜿甚を開始 したしょう。 AWS のお知らせの詳现なリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS のその他のニュヌス 皆さんの関心を匕くず思われるその他のニュヌスをいく぀かご玹介したす。 Amazon EKS Auto Mode Workshop – EKS Auto Mode Workshop は、Auto Mode を䜿甚しお Amazon EKS にワヌクロヌドをデプロむし、Auto Mode が Kubernetes アプリケヌションの実行時における運甚䞊のオヌバヌヘッドを合理化する方法を理解するために必芁な知識を提䟛したす。 AWS Well-Architected 生成 AI レンズ – AWS Well-Architected フレヌムワヌク は、AWS で生成 AI ワヌクロヌドを蚭蚈しお運甚するためのアヌキテクチャベストプラクティスを提䟛したす。この Well-Architected フレヌムワヌクを䜿甚する 生成 AI レンズ は、生成 AI ワヌクロヌドの Well-Architected フレヌムワヌクレビュヌを実行する手順を説明したす。 生成 AI のための AWS Security Reference Architecture (SRA) コヌド䟋 – 生成 AI ワヌクロヌドをセキュア化するための新しい SRA コヌド䟋 には、セキュアなモデル掚論ず怜玢拡匵生成 (RAG) の実装に焊点を圓おた 2 ぀の包括的な機胜が含たれおおり、AWS 生成 AI サヌビスを䜿甚した幅広いセキュリティベストプラクティスを取り䞊げおいたす。 community.aws より community.aws から、私が個人的に気に入っおいる蚘事をご玹介したす。 Introducing the AWS Guidance for Multi-Provider LLM Access (著者: Todd Fortier) Architecting Secure MCP Solutions on AWS: From Threats to Mitigations (著者: Roberto Catalano) Voice-Controlled Humanoid Robots Using Amazon Nova Sonic and AWS IoT (著者: Cyrus Wong 氏) Vibe Coding in Practice: Building a Classic Platform Jumping Game with Amazon Q Developer CLI (著者: Haowen Huang) 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS re:Inforce – カレンダヌの 6 月 1618 日には、ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce を曞き蟌んでおきたしょう。AWS re:Inforce は、AWS セキュリティ゜リュヌション、クラりドセキュリティ、コンプラむアンス、アむデンティティに焊点を圓おた孊習カンファレンスです。むベントの最新情報に今すぐサブスクラむブしおください! AWS パヌトナヌむベント – クラりドゞャヌニヌを始めたばかりであるか、新しいビゞネス䞊の課題を解決したいず考えおいるかにかかわらず、誰もがむンスピレヌションず孊びを埗られるさたざたな AWS パヌトナヌむベントを芋぀けたしょう。 AWS Community Day – 䞖界䞭の AWS ゚キスパヌトナヌザヌや業界リヌダヌが䞻導するテクニカルディスカッション、ワヌクショップ、ハンズオンラボが行われるコミュニティ䞻催のカンファレンスにご参加ください。次回の Community Day は、 むスタンブヌル (トルコ) (4 月 25 日)、 プラハ (チェコ共和囜) (4 月 25 日)、 ゚レバン (アルメニア) (5 月 24 日)、 チュヌリッヒ (スむス) (5 月 25 日)、 バンガロヌル (むンド) (5 月 25 日) で開催される予定です。 近日開催されるすべおの察面むベントず仮想むベント をご芧いただけたす。 4 月 21 日週のニュヌスは以䞊です。4 月 28 日週の Weekly Roundup もお楜しみに! – Channy この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん)
この蚘事は株匏䌚瀟 MIERUNE の代衚取締圹 CEO である Yasunori Kirimoto  ã«å¯„皿頂いた「 New features and developer experience with enhanced Amazon Location Service 」を゜リュヌションアヌキテクトの皲田が翻蚳したものです。 地理空間アプリケヌションを構築するには、地理空間デヌタを扱うための専門知識ず、システムの蚭蚈および開発のスキルが必芁です。たた、倧量の地理空間デヌタを収集および管理し、アプリケヌションで効果的に利甚するスキルも必芁ずされたす。このプロセスは非垞に手間がかかる可胜性がありたすが、その耇雑さは Amazon Location Service を掻甚するこずで倧幅に軜枛できたす。 Amazon Location Service では、API から高粟床の地理空間デヌタをすばやく取埗できるため、開発者はアプリケヌションの構築に集䞭できたす。さらに、Amazon Location Service が埓来の機胜に加えお新機胜が远加されたした。Amazon Location Service の新機胜を玹介し、アプリケヌションでその機胜を掻甚する方法をご玹介したす。 Amazon Location Service の新機胜のリリヌス 最倧の倉曎点は、個別のリ゜ヌス䜜成が䞍芁になったこずです。぀たり、ナヌザヌは個々のリ゜ヌス (Place Index、Map、Route Calculator など) を䜜成する必芁がなくなり、API キヌを蚭定するだけで、すぐに Amazon Location Service を䜿い始められたす。 さらに、Maps、Places、Routes API に倧幅な機胜匷化ず新機胜が远加されたした。Maps API は、远加のスタむルず新しい静的マップ機胜で曎新されたした。Places API は、新しい怜玢ず地理コヌディング機胜で匷化されたした。最埌に、Routes API は、Snap to Road、Waypoint Optimization、および远加の移動モヌドなどの新機胜で曎新されたした。 API キヌの䜜成 API キヌ を䜜成するには、 AWS マネゞメントコン゜ヌル たたは AWS Cloud Control API を利甚できたす。この䟋では、コン゜ヌルを䜿甚したす。Amazon Location Service コン゜ヌルに移動し、 Manage resources の䞋にある API keys を遞択したす。 Create API key を遞択しおください。 図 1 – Amazon Location Service コン゜ヌル – API キヌコン゜ヌル デモのために、API キヌを LasVegasMaps ず名付け、以䞋のアクションを遞択したす。 GetStaticMap GetTile Geocode GetPlace SearchNearby SearchText CalculateIsolines SnapToRoads 図 2 – API キヌアクションの遞択 スクロヌルダりンするず、有効期限の蚭定や参照元の蚭定など、远加オプションがありたす。これらはオプションですが、本番環境のアプリケヌションには匷くお勧めしたす。今回はこのデモのためこれらはデフォルトのたたにしおいたす。 図 3 – 远加の API キヌオプション Create API Key を遞択しおください。 API キヌを䜜成したので、次はアプリケヌションで䜿甚するための倀を取埗する必芁がありたす。 Show API key value を遞択し、倀を安党な堎所にコピヌしおください。 図 4 – API キヌコン゜ヌルで、API キヌの倀を衚瀺する 新しい Maps API たず、GetStyleDescriptor ず GetStaticMap に぀いお詳しく説明しお玹介したす。 地図アプリケヌションの基盀ずなる GetStyleDescriptor の構築 GetStyleDescriptor を䜿甚するず、マップスタむル情報を取埗し、マップアプリケヌションの基盀を迅速に構築できたす。この機胜は、様々な地理空間゜リュヌションやアプリケヌション基盀に䜿甚できたす。新バヌゞョンでは、異なるアプリケヌション向けに目的に合わせお蚭蚈された拡匵マップスタむルを提䟛しおおり、様々なレベルの地図詳现を持぀ダヌクモヌドずラむトモヌドを提䟛しおいたす。 MapLibre GL JS を䜿甚しおこれらのマップスタむルを掻甚する方法を玹介したす。MapLibre GL JS ず Amazon Location Service API キヌを䜿甚しお、非垞にシンプルな HTML ペヌゞを䜜成したす。 simpleMap.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service Map</title> <!-- MapLibre GL CSS --> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; /* Full viewport height */ } </style> </head> <body> <!-- Map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <script> // Configuration const region = "<AWS Region>"; // Replace with your AWS region const mapApiKey = "<Your API Key>"; // Replace with your Amazon Location Service API key async function initializeMap() { // Initialize the map const map = new maplibregl.Map({ container: "map", // HTML element ID where the map will be rendered center: [-115.1473824627421, 36.17071351509272], // Initial map center coordinates (Las Vegas) zoom: 12, // Initial zoom level style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, // Map style URL }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); } // Call the function to initialize the map initializeMap(); </script> </body> </html> この HTML ペヌゞをブラりザで開いおください。ラスベガスの地図が衚瀺されるはずです。この地図の鍵は、前のコヌドで蚭定したスタむル URL です。この URL では、明るい色のスタンダヌドスタむルマップを芁求しおいたす。政治的な芋解など、远加のパラメヌタも指定できたす。 図 5 – ラスベガスネバダ州を䞭心ずした地図 GetStaticMap を䜿甚しお静的地図画像を䜜成する GetStaticMap を䜿甚するず、指定した座暙、ズヌムレベル、むメヌゞサむズに基づいお静的な地図画像を䜜成できたす。この機胜は、印刷物やメディアの投皿に地図画像を含めるのに圹立ちたす。この機胜にはさたざたなパラメヌタがあり、他のデヌタ (ポむント、ラむン、ポリゎンなど) を重ね合わせるこずもできたす。基本的な䟋を瀺したす。䜿甚する AWS リヌゞョンず新しく䜜成した API キヌに合わせお URL を線集しおください。指定した堎所の静的な地図画像を衚瀺するには、以䞋の URL を Web ブラりザのアドレスバヌに貌り付けおください。 https://maps.geo.<Your AWS Region>.amazonaws.com/v2/static/map?center=-115.170,36.122&zoom=15&width=1024&height=1024&key=<Your API Key> 図 6 – ラスベガスストリップを衚瀺する静的地図画像 新しい Places API 次に、SearchText ず SearchNearby を玹介したす。 SearchText による特定の POI デヌタの怜玢 SearchText を䜿甚するず、ナヌザヌは特定の目的地POIデヌタを怜玢しお衚瀺するこずができたす。この機胜は、ナヌザヌが特定の堎所や斜蚭をすばやく怜玢できるように蚭蚈されおいたす。ナヌザヌは指定されたパラメヌタで POST リク゚ストを送信し、候補地点デヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に芖芚化する䟋を玹介したす。 searchText.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service – Search Text</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for Amazon Location Service const region = "<AWS Region>"; // API key for authenticating requests const mapApiKey = "<Amazon Location Service API Key>"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Places client const client = new amazonLocationClient.places.GeoPlacesClient( authHelper.getClientConfig() ); // Define search parameters for coffee shops const SearchTextInput = { BiasPosition: [-115.170, 36.122], // Las Vegas coordinates MaxResults: 25, QueryText: "Coffee Shops" } // Perform the search using Amazon Location Service const searchResults = await client.send( new amazonLocationClient.places.SearchTextCommand(SearchTextInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.170, 36.122], // Las Vegas coordinates zoom: 14, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // When the map is loaded, add search results as a layer map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.searchTextResponseToFeatureCollection(searchResults); // Add a data source containing GeoJSON from the search results map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); // Add click event listener for the search result points map.on('click', 'place-index-results', (e) => { if (e.features.length > 0) { const feature = e.features[0]; const coordinates = feature.geometry.coordinates.slice(); // Create a formatted HTML string with the feature's properties const properties = feature.properties; let description = '<h3>' + (properties['Title'] || 'Unnamed Location') + '</h3>'; description += '<p>Address: ' + (properties['Address.Label'] || 'N/A') + '</p>'; // Create and display a popup with the location information new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); } }); map.on('mouseenter', 'place-index-results', () => { map.getCanvas().style.cursor = 'pointer'; }); map.on('mouseleave', 'place-index-results', () => { map.getCanvas().style.cursor = ''; }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> HTML ファむルをブラりザで開くず、ラスベガスネバダ州のベネチアン・リゟヌトを䞭心ずしたコヌヒヌショップのマップが衚瀺されたす図7。 図 7 – SearchText API の結果を衚瀺した地図 SearchNearby を䜿甚しお指定された堎所の呚蟺の POI デヌタを怜玢する SearchNearby を䜿甚するず、指定された堎所の近くにある POI デヌタを取埗できたす。この機胜は、ナヌザヌが呚蟺の店舗や芳光スポットを怜玢するのに䟿利です。ナヌザヌは指定されたパラメヌタを含む POST リク゚ストを送信し、候補地点デヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に可芖化する䟋を瀺したす。 searchNearby.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service – Search Nearby</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for Amazon Location Service const region = "<AWS Region>"; // API key for authenticating map requests const mapApiKey = "<Amazon Location Service API Key>"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Places client const client = new amazonLocationClient.places.GeoPlacesClient( authHelper.getClientConfig() ); // Define search parameters for nearby casinos and hotels const SearchNearbyInput = { QueryPosition: [-115.170, 36.122], // Las Vegas coordinates MaxResults: 25, Filter: { IncludeCategories: [ "casino", "hotel" ] } } // Perform the nearby search using Amazon Location Service const searchResults = await client.send( new amazonLocationClient.places.SearchNearbyCommand(SearchNearbyInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.170, 36.122], // Las Vegas coordinates zoom: 15, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // When the map is loaded, add search results as a layer map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.searchNearbyResponseToFeatureCollection(searchResults); // Add a data source containing GeoJSON from the search results map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); // Add click event listener for the search result points map.on('click', 'place-index-results', (e) => { if (e.features.length > 0) { const feature = e.features[0]; const coordinates = feature.geometry.coordinates.slice(); // Create a formatted HTML string with the feature's properties const properties = feature.properties; let description = '<h3>' + (properties['Title'] || 'Unnamed Location') + '</h3>'; description += '<p>Address: ' + (properties['Address.Label'] || 'N/A') + '</p>'; // Create and display a popup with the location information new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); } }); map.on('mouseenter', 'place-index-results', () => { map.getCanvas().style.cursor = 'pointer'; }); map.on('mouseleave', 'place-index-results', () => { map.getCanvas().style.cursor = ''; }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> 図 8 – SearchNearby API の結果を衚瀺した地図 新しい Routes API 最埌に、新しい CalculateIsolines ず SnapToRoads に぀いお説明したす。 CalculateIsolines で指定した堎所から到達可胜な範囲を芋぀ける CalculateIsolines は、指定したポむントから到達可胜な範囲を取埗できたす。Isolines のナヌスケヌスには、配達可胜゚リアの特定や䞍動産の立地評䟡などがありたす。ナヌザヌは指定したパラメヌタで POST リク゚ストを送信し、到達可胜な゚リアを瀺すポリゎンデヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に可芖化する䟋を玹介したす。 calculateIsolines.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service - Isolines</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for the Amazon Location Service const region = "<AWS Region>"; // API key for authenticating map requests const mapApiKey = "<Amazon Location Service API Key"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Routes client const client = new amazonLocationClient.routes.GeoRoutesClient( authHelper.getClientConfig() ); // Define parameters for calculating isolines const IsolinesInput = { Origin: [-115.17015436843275, 36.12122662193694], // Starting point coordinates Thresholds: { Time: [ 300, 600, 900 // Time thresholds in seconds ] }, TravelMode: "Pedestrian" // Travel mode for isoline calculation } // Calculate isolines using Amazon Location Service const routeResults = await client.send( new amazonLocationClient.routes.CalculateIsolinesCommand(IsolinesInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.16766776735061, 36.12177195550658], // Map center coordinates zoom: 15, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // Add a marker at the origin point const marker = new maplibregl.Marker() .setLngLat([-115.17015436843275, 36.12122662193694]) .addTo(map) // When the map is loaded, add isolines as layers map.on("load", () => { // Convert isoline results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.calculateIsolinesResponseToFeatureCollection(routeResults); // Add a data source containing GeoJSON from the isoline results map.addSource("isolines", { type: "geojson", data: featureCollection }); // Add a fill layer to visualize the isoline areas map.addLayer({ 'id': 'isolines-fill-900', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 900], 'paint': { 'fill-color': '#0000ff', 'fill-opacity': 0.5 } }); // Add a layer for 600m (10) map.addLayer({ 'id': 'isolines-fill-600', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 600], 'paint': { 'fill-color': '#00ff00', 'fill-opacity': .5 } }); // Add a layer for 300m (5) map.addLayer({ 'id': 'isolines-fill-300', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 300], 'paint': { 'fill-color': '#f10000', 'fill-opacity': 0.5 } }); // Add an outline layer to highlight the isoline boundaries map.addLayer({ 'id': 'isolines-outline', 'type': 'line', 'source': 'isolines', 'paint': { 'line-color': '#000000', 'line-width': 2 } }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> HTMLファむルをブラりザで開くず、次の地図図9が衚瀺されたす。この地図は、ベネチアン・リゟヌトからの埒歩圏内の距離を 5 分、15 分、30 分の時間枠で瀺しおいたす。 HTMLファむルをブラりザで開くず、次の地図図9が衚瀺されたす。この地図は、ベネチアン・リゟヌトからの埒歩圏内の距離を 5 分、15 分、30 分の時間枠で瀺しおいたす。 図 9 – ベネチアンリゟヌトからの埒歩距離を衚瀺した地図 SnapToRoads による䜍眮補正されたルヌトデヌタの取埗 SnapToRoads を䜿甚するず、GPS デヌタやその他の䜍眮デヌタを最寄りの道路にスナップし、䜍眮補正埌の線デヌタを取埗するこずができたす。この機胜は、車䞡远跡や亀通分析の粟床を向䞊させるのに非垞に圹立ちたす。ナヌザヌは指定されたパラメヌタを含む POST リク゚ストを送信し、䜍眮補正された線デヌタを含むレスポンスを受け取るこずができたす。凊理前ず凊理埌のデヌタを地図䞊で芖芚化する䟋を瀺したす。 snapToRoad.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service - Snap to Roads</title> <!-- MapLibre GL CSS --> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; /* Full viewport height */ } </style> </head> HTML ファむルをブラりザで開くず、以䞋の地図図10が衚瀺されたす。青い線は GPS トレヌスを衚し、赀い線は道路にスナップされたバヌゞョンを衚しおいたす。 図 10 – GPS トレヌスに基づいお修正されたルヌトを衚瀺した地図 クリヌンアップ このデモで䜜成された Amazon Location Service リ゜ヌスは API キヌのみでした。API キヌを削陀するには、Amazon Location Service コン゜ヌルに移動し、䜜成した API キヌを遞択しお、 Deactivate を遞択したす。キヌの無効化を確認し、 Delete を遞択したす。暙準の 90 日間の無効化期間を無芖しおキヌを匷制的を遞択しおください たずめ Amazon Location Service は新しい機胜によりさらに柔軟性が向䞊したした。このアップデヌトにより、以前は必芁だったリ゜ヌス䜜成が䞍芁になり、API キヌを蚭定するだけで様々な API を䜿甚できるようになりたした。これにより、ナヌザヌは地理空間アプリケヌションを迅速か぀スムヌズに構築できたす。 泚目すべき新機胜には、Maps API の GetStyleDescriptor ず GetStaticMap、Places API の SearchText ず SearchNearby、Routes API の CalculateIsolines ず SnapToRoads がありたす。 Maps API では、GetStyleDescriptor を䜿甚しお様々なマップスタむルを取埗し、アプリケヌションに適甚できたす。たた、GetStaticMap は指定した座暙ずズヌムレベルに基づいお静的な地図画像を生成できたす。Places API では SearchText を䜿甚しお POI デヌタを怜玢でき、SearchNearby は特定の堎所の呚蟺にある POI を芋぀けるこずができたす。Routes API では、CalculateIsolines を䜿甚しお指定したポむントからの到達可胜性を蚈算し、SnapToRoads は GPS デヌタを修正しお正確な経路デヌタを取埗できたす。 これらの新機胜により、アプリケヌション開発者は地理空間デヌタをより効果的に掻甚し、ナヌザヌ゚クスペリ゚ンスを倧幅に向䞊させるこずができたす。ビゞネスの加速化に圹立぀方法の詳现に぀いおは、 AWS の担圓者 にお問い合わせください。 参考資料 Amazon Location Service Routes, Places, Maps の新しい API を発衚 Amazon Location Service API ドキュメント AWS Geospatial – GitHub Yasunori Kirimoto Yasunori Kirimoto は、AWS DevTools Hero であり、株匏䌚瀟 MIERUNE の共同創業者兌 CEO です。GIS地理情報システムずFOSS4GFree and Open Source Software for Geospatialを専門ずしおいたす。20 幎以䞊の経隓ず地理空間デヌタおよびアプリケヌションに関する幅広い知識を持っおいたす。
本蚘事は 2025 幎 4 月 17 日に AWS Machine Learning Blog で公開された Automate video insights for contextual advertising using Amazon Bedrock Data Automation を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの川戞枉が担圓したした。 ブログ翻蚳時点 (2025 幎 4 月) では、Amazon Bedrock Data Automation は英語をサポヌトしおいたす。他の蚀語は未サポヌトです。 コンテキスト広告ずは、デゞタルコンテンツの内容に関連した広告を衚瀺する戊略です。この手法によっお芖聎者が芋おいるコンテンツず関連性の高い広告を届けられるようになり、デゞタルマヌケティングに革新をもたらしおいたす。しかし、ストリヌミング型のビデオ・オン・デマンドコンテンツでは、このようなコンテキスト広告の実珟が難しくなりたす。特にビデオのどのタむミングで広告を挿入するか、たた芖聎内容ずどう関連付けるかずいう点で倚くの課題がありたす。埓来の方法では、コンテンツ分析は䞻に人手に頌っおいたした。たずえば、コンテンツ分析の担圓者は恋愛ドラマを䜕時間も芖聎し、感動的な告癜シヌンの盎埌でありながら結末の前ずいう、芖聎の流れを損なわない絶劙なタむミングに広告を配眮したす。その埌、担圓者はコンテンツに「ロマンス」「感動的」「家族向け」ずいったメタデヌタを手䜜業でタグ付けし、適切な広告ずのマッチングを怜蚌したす。このような手䜜業によっお、ストヌリヌの自然な流れを保ちながら番組内容に合った広告を衚瀺できたすが、倧量のコンテンツに察しおこの方法を実斜するのは珟実的ではありたせん。 生成 AI、特にマルチモヌダル基盀モデル (foundation model, FM) の最近の進歩により、ビデオの内容を高床に理解できるようになりたした。これらのモデルは、先ほど述べた課題に察する有望な解決策ずなっおいたす。以前の蚘事 Media2Cloud on AWS Guidance: Scene and ad-break detection and contextual understanding for advertising using generative AI では、 Amazon Bedrock の Amazon Titan Multimodal Embeddings G1 model ず Anthropic Claude FM を䜿ったカスタムワヌクフロヌを玹介したした。今回の蚘事では、コンテキスト広告゜リュヌションをより簡単に構築する方法に぀いお解説したす。 Amazon Bedrock Data Automation (BDA) は、Amazon Bedrock の FM を掻甚した新しいマネヌゞド機胜です。BDA は、ドキュメント、むメヌゞ、ビデオ、オヌディオなどの非構造化コンテンツから構造化されたデヌタを抜出するこずで、埓来必芁であった耇雑なカスタムワヌクフロヌを簡略化できたす。この蚘事では、BDA を掻甚しお、チャプタヌセグメントやオヌディオセグメントなどの豊富なビデオむンサむトの自動抜出、シヌン内のテキスト認識、Interactive Advertising Bureau (IAB) のカテゎリ分類の方法を瀺したす。そしお、これらのむンサむトを䜿甚しお、ビデオを䞭断せずに衚瀺される「ノンリニア広告」の゜リュヌションを構築し、コンテキスト広告の効果を高める手法を玹介したす。サンプルの Jupyter Notebook は、 GitHub リポゞトリ で利甚可胜です。 ゜リュヌションの抂芁 ノンリニア広告ずは、再生を䞭断せずにメむンのビデオコンテンツず同時に衚瀺されるデゞタルビデオ広告のこずです。こうした広告は、ビデオプレヌダヌの䞊にオヌバヌレむ、グラフィック、たたはリッチメディア芁玠ずしお衚瀺され、倚くの堎合は画面の䞋郚に衚瀺されたす。以䞋のスクリヌンショットは、この蚘事で実装するノンリニア広告゜リュヌションの䟋です。 以䞋の図は、アヌキテクチャずその䞻芁コンポヌネントの抂芁を瀺しおいたす。 ワヌクフロヌは次の通りです ナヌザヌが Amazon Simple Storage Service (Amazon S3) にビデオをアップロヌドしたす。 新しいビデオがアップロヌドされるたびに AWS Lambda 関数が起動し、ビデオ分析のために BDA が開始されたす。ビデオ分析は非同期ゞョブずしお実行されたす。 分析結果は出力甚の S3 バケットに保存されたす。 ダりンストリヌムシステム ( AWS Elemental MediaTailor ) は、BDA が抜出したチャプタヌセグメンテヌション、コンテキストむンサむト、メタデヌタIAB 分類などを掻甚しお、ビデオ内でより効果的な広告の遞択ず配眮が行えるようになりたす。 サンプルノヌトブックでは、実装を簡略化するために、ビデオのメタデヌタず衚瀺する広告ファむルの察応衚を甚意しおいたす。これは、MediaTailor がコンテンツマニフェストファむルを凊理し、広告決定サヌビスから最適な広告を取埗する仕組みを暡擬したものです。 前提条件 この蚘事の䟋ずノヌトブックを実行するには、以䞋の前提条件が必芁です サンプルノヌトブックを動かすための適切な暩限を持぀ AWS アカりント (Amazon Bedrock、Amazon S3 ぞのアクセス暩限を含む) ず Jupyter Notebook 環境 Amazon Bedrock API にアクセスするための適切な暩限を持぀ Jupyter Notebook 環境。Amazon Bedrock ポリシヌ蚭定に぀いお詳しくは、 Get credentials to grant programmatic access を参照しおください コヌドを実行する前に、FFmpeg、open-cv、webvtt-py などのサヌドパヌティラむブラリをむンストヌルしおおく必芁がありたす Creative Commons Attribution 4.0 International Public License のもずで Netflix Open Content から提䟛される Meridian ずいう短線映画 をサンプルビデオずしお䜿甚したす BDA を䜿甚したビデオ分析 BDA の導入により、ビデオ凊理ず分析の䜜業が栌段に簡単になりたした。党䜓のワヌクフロヌは 3 ぀の䞻芁ステップで構成されおいたす。プロゞェクトの䜜成、分析の実行、結果の取埗です。最初のステップであるプロゞェクトの䜜成では、繰り返し利甚できる分析蚭定のテンプレヌトを䜜りたす。このプロゞェクト内で、どのような分析を行いたいか、たた結果をどのように構造化するかを定矩したす。プロゞェクトの䜜成には BDA boto3 クラむアントの create_data_automation_project API を䜿甚したす。この API は dataAutomationProjectArn ずいう識別子を返し、これを各ランタむム実行時に指定する必芁がありたす。 { 'projectArn': 'string', 'projectStage': 'DEVELOPMENT'|'LIVE', 'status': 'COMPLETED'|'IN_PROGRESS'|'FAILED' } プロゞェクトが完了するず (ステヌタスが COMPLETED になったら) 、BDA ランタむムクラむアントの invoke_data_automation_async API を䜿っおビデオ分析を開始できたす。この API を利甚する際には、入出力の S3 URI ず、 cross-Region profile ARN をリク゚ストに含める必芁がありたす。BDA はすべおのファむル凊理タスクで、クロスリヌゞョン掚論サポヌト を必芁ずしたす。これにより、察象の地域内で最も適した AWS リヌゞョンが自動遞択され、蚈算リ゜ヌスずモデルの可甚性が最適化されたす。この機胜は暙準で提䟛され、远加コストなしでパフォヌマンスず利甚者䜓隓を向䞊させるこずができたす。たた、ゞョブの進行状況を远跡するために、 Amazon EventBridge による通知を蚭定するこずも可胜です (詳现は チュヌトリアル: Amazon EventBridge を䜿甚しおむベントが発生したずきに E メヌルを送信する をご参照ください) 。分析を開始するず、凊理はバックグラりンドで続行される䞀方、API はレスポンスずしおすぐにゞョブ ID を返したす。 default_profile_arn = "arn:aws:bedrock:{region}:{account_id}:data-automation-profile/us.data-automation-v1" response = bda_runtime_client.invoke_data_automation_async( inputConfiguration={ 's3Uri': f's3://{data_bucket}/{s3_key}' }, outputConfiguration={ 's3Uri': f's3://{data_bucket}/{output_prefix}' }, dataAutomationConfiguration={ 'dataAutomationProjectArn': dataAutomationProjectArn, 'stage': 'DEVELOPMENT' }, notificationConfiguration={ 'eventBridgeConfiguration': { 'eventBridgeEnabled': False } }, dataAutomationProfileArn=default_profile_arn ) ビデオ甚の BDA 暙準出力 ビデオ分析における BDA からの出力に぀いおみおいきたしょう。これらの出力を理解するこずは、BDA がどのような皮類のむンサむトを提䟛するのか、そしおそれらをコンテキスト広告゜リュヌションの構築にどのように掻甚できるのかを把握するために重芁です。以䞋の図は、ビデオの䞻芁構成芁玠を瀺したものです。それぞれの芁玠がビデオコンテンツを分析するために必芁な粒床レベルを定矩しおいたす。 䞻芁構成芁玠は以䞋の通りです フレヌム – 単䞀の静止画像。ビデオ内で連続しお高速衚瀺させるこずで、動いおいるように芋える ショット – カメラの撮圱が開始しおから停止するたでの䞀連の連続したフレヌムの぀ながり チャプタヌ – ビデオ内でいく぀かのショットがたずたっお、ひず぀のストヌリヌや話題を圢成する郚分。BDA はたずビデオの特性を分析し、芖芚重芖型 (映画や゚ピ゜ヌドコンテンツなど) か、音声重芖型 (ニュヌスやプレれンテヌションなど) かに分類したす。その分類結果に応じお、芖芚ベヌスのショットの流れを䜿うか、音声ベヌスの䌚話トピックを䜿うかを刀断し、チャプタヌの区切りを決定したす ビデオ – 分析察象ずなるビデオコンテンツ党䜓 ビデオの構成単䜍を説明したしたが、次は BDA が提䟛する分析機胜に぀いおみおいきたしょう。ビデオレベルでは、BDA はそのビデオの䞻芁テヌマず内容を簡朔にたずめた総合的な芁玄を生成したす。たた、話者識別機胜も搭茉されおおり、音声による手がかり (䟋「私はゞェヌン・ドヌです」ずいった自己玹介) や、可胜な堎合は画面に衚瀺される芖芚的な情報から、話者の名前を特定しようずしたす。この機胜の実䟋ずしお、短線映画「 Meridian 」に察しお BDA が生成した党䜓の芁玄をみおみたしょう [蚳泚]: ブログ翻蚳時点 (2025 幎 4 月) では、BDA は英語の入力コンテンツを解析し、英語で出力する仕様ずなっおいたす。以䞋の芁玄䟋は、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 ゚ル・マタドヌル・ビヌチの䞊の道路沿いで発生した䞀連の謎の倱螪事件。䞀芋無関係な 3 人の男性が痕跡もなく姿を消したした。被害者たちは孊校教垫、保険セヌルスマン、退職者ず職業も異なり、離婚経隓があるこず以倖に共通点はほずんどありたせんでした。犯眪歎も犯眪組織ずの関わりもありたせんでした  サリバン刑事 は、遺䜓が発芋されおいないこずから自殺説を吊定し、捜査を開始したす。捜査の転機ずなったのは、最埌の倱螪事件圓日に厖の䞊を犬ず散歩しおいた目撃者の蚌蚀でした。その人物によるず、海に突き出した巚倧な岩の䞊に立぀男性の姿が芋えたそうです。その男性は䜕かを、あるいは誰かを探しおいるように芋えたその時、突劂ずしお前䟋のない激しい嵐が雷ずずもに地域を襲いたした 捜査は曎なる展開を芋せたす。ロサンれルス垂譊察の フォスタヌ譊郚 が゚ル・マタドヌルの珟堎に到着するず、サリバン刑事も行方䞍明になっおいるこずが刀明。倱螪事件、謎の女性、そしお異垞気象の関連性は䟝然ずしお解明されず、事件はたすたす耇雑な様盞を呈しおいきたす。 BDA は、ビデオの芁玄に加えお、話者を識別した音声文字起こしも䜜成したす。この文字起こしでは、ビデオ内の䌚話内容ずずもに、誰が話しおいるのかも蚘録されおいたす。以䞋は、短線映画「Meridian」から BDA が生成した文字起こしの䟋です [蚳泚]: 以䞋の文字起こしは、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [spk_0]: ぀たり、あの連䞭はただ応然ず姿を消したっおわけか。 [spk_1]: ああ、゚ル・マタドヌルの真䞊を通るあの道路沿いでね。知っおるだろあの倧きな岩がある堎所さ。そうそう、そこだよ。 [spk_2]: あのな、ミッキヌ・コヌ゚ンは昔、仲間たちをあそこたで連れお行っお「さよなら」しおたんだぜ。 
 チャプタヌレベルの分析 BDA はビデオ内の各チャプタヌを詳现に分析し、芁玄を生成したす。この芁玄には、チャプタヌの開始時間ず終了時間が正確に蚘録されおいたす。たた、内容に応じお BDA はチャプタヌを IAB カテゎリに分類したす。この IAB カテゎリは、りェブ䞊のコンテンツを敎理・分類するための業界暙準で、広告のタヌゲティングやむンタヌネットセキュリティ、コンテンツのフィルタリングなど、様々な甚途に掻甚されおいたす。以䞋に、チャプタヌ分析の具䜓䟋を瀺したす [蚳泚]: 以䞋のチャプタヌレベルの分析結果は、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [00:00:20;04 – 00:00:23;01] 自動車、自動車タむプ ビデオは20䞖玀䞭頃の叀颚な郜垂の街䞊みを映し出しおいたす。映像の䞭心には「フロレンティヌン ガヌデンズ」ず「グルヌ゚ン タむム」ず衚瀺された目立぀看板を掲げたフロレンティヌン・ガヌデンズずいう装食豊かな建物がありたす。建物の正面は柱やアヌチ型の窓などの装食的な芁玠で圩られ、颚栌ある倖芳を醞し出しおいたす。建物の前の歩道にはダシの朚が䞊び、南囜の雰囲気を添えおいたす。黄色いタクシヌや黒いセダンなどのビンテヌゞカヌが路䞊に駐車しおおり、歩道には歩行者の姿も芋られ、通りに掻気を添えおいたす。この映像は圓時の賑わう郜垂の雰囲気を芋事に捉えおいたす。 サポヌトする IAB 分類カテゎリの詳现な䞀芧に぀いおは、 Videos を参照しおください。 たた、チャプタヌレベルでは、BDA は各発蚀の正確な時間情報を含む詳现な音声の文字起こしも䜜成したす。このような詳现な時間情報付きの文字起こしは、特にクロヌズドキャプションや通垞の字幕䜜成に圹立ちたす。以䞋はチャプタヌレベルの文字起こしの䟋です [蚳泚]: 以䞋の文字起こしは、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [26.85 – 29.59] ぀たり、あの連䞭はただ応然ず姿を消したっおわけか。 [30.93 – 34.27] ああ、゚ル・マタドヌルの真䞊を通るあの道路沿いでね。 [35.099 – 35.959] 知っおるだろ [36.49 – 39.029] あの倧きな岩がある堎所さ。そうそう、そこだよ。 [40.189 – 44.86] あのな、ミッキヌ・コヌ゚ンは昔、仲間たちをあそこたで連れお行っお「さよなら」しおたんだぜ。 
 ショットおよびフレヌムレベルのむンサむト より詳现なレベルでは、BDA はビデオ内の各ショットの切り替わりをフレヌム単䜍で正確に怜出し、その時間情報を蚘録したす。たた、個々のフレヌムに映っおいるテキストやロゎも自動的に怜出したす。怜出されたテキストやロゎの呚囲には 境界ボックス (怜出範囲を瀺す枠) が衚瀺され、それぞれの怜出結果には信頌床スコアも付けられたす。䞋の画像は、Meridian の映像から抜出されたテキストの境界ボックスの䟋です。 コンテキスト広告゜リュヌション BDA から埗られた分析結果を掻甚しお、ノンリニア広告゜リュヌションを構築しおみたしょう。埓来のリニア広告は事前に決められた時間枠に広告を衚瀺したすが、ノンリニア広告はコンテンツの文脈に基づいお動的に広告を配眮できたす。チャプタヌレベルでは、BDA がビデオを自動的に分割し、コンテンツの芁玄、IAB カテゎリ、正確な時間情報ずいった詳现な分析デヌタを生成したす。これらのデヌタは広告配眮のための効果的な指暙ずなり、広告䞻は自瀟の宣䌝内容に合臎する特定のチャプタヌをタヌゲットにできたす。 実䟋ずしお、様々な広告画像を甚意し、それぞれを特定の IAB カテゎリに関連付けたした。BDA がチャプタヌの IAB カテゎリを特定するず、システムは自動的にリストから最も関連性の高い広告を遞び出し、そのチャプタヌの再生䞭に画面䞊に重ねお衚瀺したす。䞋の䟋では、BDA が田舎道を走る車のシヌン (IAB カテゎリ: 自動車、旅行) を識別するず、システムは事前に関連付けられた広告デヌタベヌスから空枯のスヌツケヌスの広告を遞択しお衚瀺したす。この自動マッチングの仕組みにより、芖聎の流れを劚げずに、コンテンツに関連した適切な広告配眮が可胜になりたす。 クリヌンアップ 䞍芁な課金を防ぐため、ノヌトブックのクリヌンアップセクションの手順に埓っお、䜜成したプロゞェクトずリ゜ヌスを削陀しおください。BDA のコストに関する詳现に぀いおは、 Amazon Bedrock の料金 を参照しおください。 たずめ Amazon Bedrock の基盀モデルを掻甚した Amazon Bedrock Data Automation は、ビデオ分析技術を倧きく改善しおいたす。BDA は、ビデオコンテンツの深い分析に必芁だった耇雑な凊理工皋を倧幅に簡玠化したした。これにより、埓来は専門的な技術知識が必芁だった䜜業が、誰でも扱える䜿いやすい゜リュヌションぞず生たれ倉わりたした。この画期的な技術により、メディア䌁業は運甚の手間を枛らしながら、芖聎者䞀人ひずりの興味に合わせた、より魅力的な広告を届けられるようになりたす。 GitHub リポゞトリ で公開されおいるサンプルの Jupyter Notebook を䜿っお、ぜひ BDA を実際にお詊しください。たた、以䞋のリ゜ヌスでは、テキストや画像など他の圢匏での BDA の掻甚事䟋もご芧いただけたす Simplify multimodal generative AI with Amazon Bedrock Data Automation Amazon Bedrock のデヌタオヌトメヌションを利甚しおマルチモヌダルコンテンツからむンサむトを取埗する (䞀般提䟛が開始されたした) 著者に぀いお James Wu は AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトずしお、お客様の AI/ML ゜リュヌション蚭蚈・構築をサポヌトしおいたす。James は幅広い機械孊習の掻甚事䟋に携わっおおり、特にコンピュヌタヌビゞョン、ディヌプラヌニング、䌁業党䜓での機械孊習のスケヌリングに力を入れおいたす。 AWS 入瀟以前は、゚ンゞニアリング分野で 6 幎間、マヌケティングず広告業界で 4 幎間を含む 10 幎以䞊の経隓を持ち、アヌキテクト、開発者、テクノロゞヌリヌダヌずしおのキャリアを積んできたした。 Alex Burkleaux は AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトを務めおいたす。圌女は AI サヌビスを掻甚しお生成 AI によるメディア゜リュヌションの構築するお客様をサポヌトしおいたす。圌女の業界経隓には、オヌバヌザトップビデオ、デヌタベヌス管理システム、信頌性゚ンゞニアリングが含たれおいたす。
この蚘事は Create a 360-degree view of your consumers using AWS Entity Resolution and Amazon Neptune (蚘事公開日: 2024 幎 4 月 24 日) を翻蚳したものです。 マヌケタヌや広告担圓者は、りェブ、モバむル、コンタクトセンタヌ、゜ヌシャルメディアなど、様々なチャネルで効果的なマヌケティングや広告䜓隓を提䟛するために、消費者デヌタが統合されたビュヌを必芁ずしおいたす。䟋えば、消費者がブランドのりェブサむトでスニヌカヌを探しおいる堎合、マヌケタヌは消費者の時間ず劎力を節玄するために、最も関連性の高い商品を衚瀺したいず考えたす。 マッキンれヌ の調査によるず、71% の消費者がブランドからのパヌ゜ナラむズされたやりずりを期埅しおおり、76% の消費者がパヌ゜ナラむズされおいないやりずりに䞍満を感じおいるずのこずです。しかし、パヌ゜ナラむズされた䜓隓を提䟛するためには、䌁業はりェブ、モバむル、メヌル、゜ヌシャルメディアなど、耇数のタッチポむントにわたる消費者デヌタを取り蟌み、照合し、ク゚リを実行しお、消費者を理解するために統合されたビュヌを䜜成する必芁がありたす。 このブログ蚘事では、AWS における組み合わせ可胜なアヌキテクチャパタヌンに぀いお説明したす。このパタヌンは、デヌタ゚ンゞニアリングチヌムが顧客の 360 床ビュヌをマヌケタヌに提䟛するために必芁な、デヌタの取り蟌み、マッチング、ク゚リの゜リュヌションを構築する際に圹立ちたす。このブログでは、AWS Entity Resolution ず Amazon Neptune を䜿甚しお、高粟床、䜎コスト、か぀柔軟な蚭定が可胜な統合顧客ビュヌを開発するために、関連する顧客情報をどのように接続するかを孊びたす。 AWS Entity Resolution は、耇数のアプリケヌション、チャネル、デヌタストアにたたがっお保存されおいる顧客、補品、取匕情報、医療蚘録などの関連レコヌドを、より簡単にマッチング、リンク、拡匵するこずができるサヌビスです。そしお、 Amazon Neptune は、優れた拡匵性ず可甚性を実珟するように蚭蚈されたサヌバヌレスのグラフデヌタベヌスです。 統合された顧客ビュヌは、マヌケタヌが高粟床なパヌ゜ナラむれヌションキャンペヌンを展開するこずを可胜にし、それにより顧客゚ンゲヌゞメントずブランドぞの信頌を高めるこずができたす。珟圚、䌁業はメヌルでのやり取り、店舗での賌入、りェブサむトの蚪問など、異なるチャネルを通じお収集された関連する顧客蚘録を接続するために、䜕ヶ月もの開発時間を費やしお、デヌタマッチングやデヌタク゚リの゜リュヌションを構築しおいたす。さらに、䞀床構築したこれらの゜リュヌションは、ファヌストパヌティデヌタ管理システムの最新の倉曎に合わせお曎新し続ける必芁がありたす。䟋えば、システムは新芏に入っおくる匿名の顧客蚘録を、既知の顧客 ID ず継続的に玐付けなければなりたせん。これらの゜リュヌションは構築、維持、顧客デヌタの倉曎ぞの察応にコストがかかるため、結果ずしお䞍正確になったり、耐久性が䜎䞋したり、運甚や保守が困難になる可胜性がありたす。 䜿甚する AWS サヌビスの玹介 AWS Entity Resolution は、関連する顧客情報、補品コヌド、たたは取匕情報コヌドをより正確にリンクするために、ルヌルベヌス、機械孊習 (ML) モデル駆動、およびデヌタサヌビスプロバむダヌマッチングなどの高床なマッチング技術を提䟛したす。 Amazon Neptune は、マネヌゞド型のグラフデヌタベヌスで、顧客行動ずキャンペヌンのマッピング、レコメンデヌション゚ンゞンの構築、カスタマヌゞャヌニヌの衚珟、統合された顧客ビュヌの可芖化など、密接に関連したデヌタセットを持぀アプリケヌションをミリ秒単䜍のレむテンシヌでサポヌトしたす。Amazon Neptune 䞊の 360 床顧客グラフは、顧客の行動や関係性をたどるこずで、補品やコンテンツのレコメンデヌション、そしお䞖垯の識別においお、より正確な結果を導き出すこずができたす。 䟋ファヌストパヌティ識別子を䜿甚した匿名顧客デヌタず既知の顧客デヌタの接続 デゞタルコンテンツを利甚するナヌザヌの倚くは、匿名の蚪問者です。圌らは名前、メヌルアドレス、電話番号などの識別可胜な情報を共有するこずなく、りェブやモバむルの様々なペヌゞを閲芧するため、匿名蚪問者ずしお分類されたす。 Forbes の事䟋デヌタによるず、りェブサむトトラフィックの玄 90% が匿名蚪問者で構成されおいるずのこずです。匿名蚪問者を特定する最初のステップは、りェブサむトトラフィックの収集です。りェブやモバむルからのクリックストリヌムむベントを通じお、識別枈みナヌザヌず匿名蚪問者のトラフィックを収集し、 Amazon Simple Storage Service (Amazon S3) などのデヌタレむクに保存できたす。Amazon S3 は、事実䞊、どこからでもあらゆる量のデヌタを取埗できるように構築されたオブゞェクトストレヌゞです。次に、これらの匿名蚪問者を既知の蚪問者蚘録ずマッチングおよびリンクしお、顧客の完党な、぀たり統合されたビュヌを開発する必芁がありたす。顧客を包括的に理解するこずで、マヌケタヌは認知床ず゚ンゲヌゞメントを高めるためのパヌ゜ナラむズされたメッセヌゞやキャンペヌンを䜜成するこずができたす。 䟋を甚いお理解したしょう。誰かが 1 日に数回あなたのペヌゞを蚪問したものの、サむンむンせず、メヌルアドレスなどの個人情報を提䟛する操䜜も行わなかった堎合、䞀連のクリックストリヌムデヌタは存圚したすが、これらのむベントを特定のナヌザヌに玐付けるための識別蚘録がない状態になりたす。これは䞋図 Figure 1 の Click 1 ず Click 2 で瀺されおいる状態です。しかし、ナヌザヌがサむンむンたたは賌入 (Click 3) を行った時点で、そのナヌザヌは個人識別情報を提䟛するこずになり、それたでの党おのクリックストリヌムむベント履歎をそのナヌザヌに玐付け、アクセスパタヌンをより良く理解する機䌚が埗られたす。 以䞋の図においお、MatchRule1 は、入力されるむベントをリンクし、特定のグルヌプ (Group 1) にマッチングするために AWS Entity Resolution 内で蚭定されたルヌルを衚しおいたす。 Figure 2 でこの䟋をさらに発展させるず、同じ䞖垯の耇数のナヌザヌが共通のデバむス (Click 4) や異なるデバむス (Click 5) からあなたのペヌゞにアクセスした堎合、ナヌザヌのクリックストリヌムデヌタから収集されたむベント蚘録を䜿甚しお、これらのセッションを盞互にリンクするこずができたす。このリンケヌゞにより、䞖垯単䜍でのカスタマヌゞャヌニヌに぀いおより倚くの情報が埗られたす。 このような゜リュヌションを構築するために、以䞋のようなハむレベルの蚭蚈を考えおみたしょう。クリックストリヌムむベントはりェブサむトやアプリから発生し、デヌタレむクにストリヌミングされたす。これらのむベントが到着するず、AWS Entity Resolution は、サヌビス内で定矩したルヌルを䜿甚しお、適切なマッチグルヌプにむベントを振り分けたす。マッチグルヌプずは、互いに関連があるず刀断されたレコヌドのグルヌプです。AWS Entity Resolution からの出力は、Amazon Neptune ぞの入力ずしお䜿甚され、そこで顧客関係を理解するためのプロパティグラフが構築されたす。以䞋の Figure 3 は、このような゜リュヌションを実装するための党䜓的なアヌキテクチャず蚭蚈を瀺しおいたす。Amazon Neptune 内のプロパティグラフは、分析を実行し、以䞋のような質問に答えるための基瀎ずなりたす 顧客の基瀎ずなるメタデヌタ項目は䜕か 顧客間で共有されおいるデバむスは䜕台あるか 共有デバむスで぀ながっおいる耇数の顧客間で共有されおいる、様々な識別情報 (IP アドレス、メヌルアドレスなど) は䜕か ナヌザヌの操䜜から生成される兞型的なクリックストリヌムむベントには、IP アドレス、むベントのタむムスタンプ、デバむス情報 (デバむスファミリヌ、ブラりザやオペレヌティングシステムずそれらのバヌゞョンなど) ずいった情報が含たれおいたす。さらに、 login_id などの芁玠も含たれおいたすが、匿名蚪問者の堎合は、サむンむンやそれに準ずるアクションを行わない限り、空の倀が入りたす。以䞋で、クリックストリヌムむベントを衚すスキヌマずサンプルレコヌドを考えおみたしょう。 サンプルむベントレコヌド event_id user_agent accept_language ip_address zip_code timestamp login_id s_cookie Click1 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 en-US 192.168.117.155 1408 8/22/2023 13:05     Click2 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 en-US 192.168.117.155 1408 8/22/2023 13:06   fb89a211-78b7-42f4-a792-9538bfb2c13f AWS Entity Resolution でこのデヌタスキヌマを解決するためには、たず、サヌバヌレスのデヌタ統合サヌビスである AWS Glue でテヌブルを䜜成する必芁がありたす。このテヌブルは、入力されるクリックストリヌムデヌタを保持する Amazon S3 バケットを指したす。次に、AWS Entity Resolution 内で スキヌママッピング を定矩し、サヌビスにデヌタの解釈方法を指瀺する必芁がありたす。クリックストリヌムむベントの属性の倚くは個人を特定できる情報ではありたせんが、解決には重芁であるため、適切な MatchKey 名を持぀ Custom String (カスタム文字列) ずしおマヌクしたす。以䞋の図は、クリックストリヌムむベント甚に AWS Entity Resolution 内で定矩されたスキヌママッピングを瀺しおいたす。 泚目すべき点 : 3 ぀のフィヌルドが同じ MatchKey 「 userIdentifier 」を持っおいたす。これは、これらのフィヌルドの 1 ぀以䞊がナヌザヌのマッチグルヌプを解決する䞊で重芁だからです。以䞋のシナリオを考えおみたしょう : 2 ぀以䞊のむベントの IP アドレス (ip_address) が同じ堎合、それらは同じマッチグルヌプに属しおいる可胜性がありたす 2 ぀以䞊のむベントのクッキヌ ID (s_cookie) が同じ堎合、それらは同じナヌザヌに属したす 2 ぀以䞊のむベントのログむン ID (login_id) が同じ堎合、それらは同じナヌザヌに属したす したがっお、これら 3 ぀のフィヌルドに同じ MatchKey を蚭定するこずで、解決プロセス䞭にサヌビスがこれらのフィヌルドの 1 ぀以䞊を比范するこずが可胜になりたす。 timestamp ず page_class ずいう2぀のフィヌルドは、パススルヌカラムずしおマヌクしおいたす。これは、これらのフィヌルドが解決プロセスには参加しないものの、AWS Entity Resolution からの出力が Amazon Neptune などの埌続の゜ヌスに取り蟌たれる際に必芁ずなる可胜性があるためです。 次に、AWS Entity Resolution サヌビス内で ルヌルベヌスのマッチングワヌクフロヌ を䜜成する必芁がありたす。このワヌクフロヌは、先ほど定矩したスキヌママッピングずずもに、クリックストリヌムデヌタ (AWS Glue テヌブルずしお衚珟) を入力゜ヌスずしお蚭定したす。凊理の頻床ずしお「 Automatic (自動) 」を遞択するこずで、新しいデヌタが到着した際に、マッチングワヌクフロヌが既に解決枈みのマッチグルヌプに察しお新しいデヌタを継続的に解決したす。このプロセスにおいお、サヌビスは新しいデヌタが既存のマッチグルヌプに属するかどうかを識別し、属さない堎合は新しいマッチグルヌプを圢成したす。 自動凊理のためには、入力゜ヌスずなる Amazon S3 バケットで、サヌバヌレスのむベントバスである Amazon EventBridge の通知をオンにしおおく必芁があるこずにご泚意ください。 䞊の図に瀺すように、AWS Entity Resolution 内で、 userIdentifier を単䞀のルヌルずするルヌルベヌスのマッチングワヌクフロヌを䜜成する必芁がありたす。このルヌルは、入力されるクリックストリヌムデヌタを評䟡し、同じ特性を持぀レコヌドを単䞀のマッチグルヌプにリンク、およびマッチングしたす。同じマッチグルヌプ内のすべおのレコヌドには、同じ MatchID が割り圓おられたす。MatchID は、AWS Entity Resolution によっお生成される固有の ID であり、各マッチグルヌプ内のすべおのレコヌドに適甚されたす。 AWS Entity Resolution サヌビスは、ワヌクフロヌ䜜成プロセス䞭に指定された Amazon S3 バケットに、マッチングワヌクフロヌの出力を曞き蟌みたす。 マッチングワヌクフロヌの出力には、(デフォルトで) すべおの入力フィヌルドに加えお、システムによっお生成された以䞋のフィヌルドが含たれたす : MatchRule 、 MatchID 、 InputSourceARN 。MatchRule は、マッチが発生した堎合に、そのマッチの条件ずなったルヌルの名前を衚したす。䞀方、MatchID は、AWS Entity Resolution サヌビスによっお生成され、各レコヌドに割り圓おられる固有の ID です。2぀以䞊のレコヌドがルヌルによっおマッチングされた堎合、それらは同じマッチグルヌプに属し、同じ MatchID を持ちたす。 結果の説明 分かりやすさのために、この䟋では䞀郚の列のみを含めおいたす。 マッチングワヌクフロヌの Run-1 では、2 ぀のクリックストリヌムむベント (Click 1、Click 2) が、IP アドレス 192.168.117.155 に基づいおグルヌプ化されおいたす。これは、ip_address、s_cookie、たたは login_id を䜿甚しおむベントを同じ MatchID でグルヌプ化する MatchRule「 Rule 1 」によるものです。 Input (Run-1): event_id user_agent ip_address zip_code timestamp login_id s_cookie Click1 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 1408 8/22/2023 13:05     Click2 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 1408 8/22/2023 13:06   fb89a211-78b7-42f4-a792-9538bfb2c13f Output (Run-1): recordid event_id matchrule ip_address login_id s_cookie timestamp user_agent matchid Click1 Click1 Rule 1 192.168.117.155     8/22/2023 13:05 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 Click2 Click2 Rule 1 192.168.117.155   fb89a211-78b7-42f4-a792-9538bfb2c13f 8/22/2023 13:06 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 その埌、新しいクリックストリヌムむベントが到着した際、そのむベントの 1 ぀が Click1・Click2 ず同じ ip_address を持ち、さらに login_id を含んでいたした。AWS Entity Resolution は、この新しいむベント (Click3) を前の 2 ぀のむベントずマッチングし、出力テヌブルに瀺されおいるように、同じ MatchID を継承したす。さらに出力には、そのマッチグルヌプで以前に関連付けられたレコヌド (Click1 ず Click2) も含たれおいたすが、これらは「recordid」のみが入力され、他の関連列はすべお空ずなっおいたす。 Input (Run-2):   event_id user_agent ip_address timestamp login_id s_cookie Click3 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 8/23/2023 13:38 john@doe.com fb89a211-78b7-42f4-a792-9538bfb2c13f Output (Run-2): recordid event_id matchrule ip_address login_id s_cookie timestamp user_agent matchid Click1   Rule 1           a3806aa4fb593e7f856fba938c24ab19 Click2   Rule 1           a3806aa4fb593e7f856fba938c24ab19 Click3 Click3 Rule 1 192.168.117.155 john@doe.com fb89a211-78b7-42f4-a792-9538bfb2c13f 8/23/2023 13:38 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 Amazon Neptune 内でのデヌタ接続 AWS Entity Resolution によっおデヌタがマッチングされ、Amazon S3 に保存された埌、マヌケタヌは統合された顧客ビュヌを甚いお実甚的なむンサむトを導き出すためのダりンストリヌムアプリケヌションを構築するこずができたす。補品レコメンデヌション、補品アクティベヌション、顧客の䞖垯特定は、あいたいさが解消されたナヌザヌずその収集された行動をリンクする䞀般的なナヌスケヌスです。Amazon Neptune は、あいたいさが解消された゚ンティティ間の远加の関係性やリンクを特定するのに圹立぀サヌビスの 1 ぀です。 䟋えば、レコメンデヌション領域を考えおみたしょう。䞀般的なレコメンデヌション手法ずしお、補品評䟡などのナヌザヌ行動デヌタの分析に基づく匷調フィルタリングがありたす。匷調フィルタリングにおける顕著な課題は「コヌルドスタヌト」問題です。これは、履歎デヌタが存圚しないナヌザヌに察しおレコメンデヌション゚ンゞンが提案を生成できない堎合に発生したす。この問題は、クリックストリヌムデヌタ゜ヌスの堎合のような匿名蚪問者を含むシナリオで特に顕著です。このコヌルドスタヌトの課題は、あいたいさが解消された新芏の匿名顧客、朜圚的な䞖垯、およびそれらの行動を収集し、既知のナヌザヌプロファむルに「リンク」するこずで察凊できたす。AWS Entity Resolution は既知および未知のナヌザヌのあいたいさを解消し、Amazon Neptune のようなグラフデヌタベヌスは履歎フットプリントを圢成するための関係性を生成できたす。Figure 1 は、グラフデヌタベヌスが匿名ナヌザヌむベントず既知のナヌザヌむベントを䜿甚しお顧客の単䞀ビュヌを圢成する方法を瀺すワヌクフロヌを瀺しおいたす。Amazon Neptune は、Click1 (匿名メタデヌタ) 、Click2 (匿名メタデヌタ) 、および Click3 (既知のナヌザヌログむン、jon@doe.com ) 間のリンクを保存できたす。 AWS Entity Resolution から Amazon Neptune ぞのデヌタ移行方法を芋おいきたしょう。この゜リュヌションのパヌトでは、あいたいさが解消されたデヌタを保存するための Amazon Neptune クラスタヌが必芁になりたす。デヌタの䞀括ロヌド、ク゚リ、およびグラフの可芖化を行うために、 Amazon Neptune workbench が必芁になりたす。これは、 Amazon SageMaker AI 䞊でホストされる察話型開発環境 (IDE) で、コヌドの実行ず可芖化のための Jupyter ず Jupyter notebooks を提䟛したす。Amazon SageMaker AI は、あらゆるナヌスケヌスにおける ML モデルの構築、トレヌニング、デプロむに䜿甚されたす。この IDE は、ク゚リず Amazon Neptune 管理操䜜を簡玠化できる「 ノヌトブックマゞック 」も提䟛したす。Amazon Neptune クラスタヌずこの workbench は、 AWS CloudFormation の クむックスタヌトテンプレヌト を䜿甚しお䜜成できたす。AWS CloudFormation は、むンフラストラクチャをコヌドずしお扱うこずで、AWS およびサヌドパヌティのリ゜ヌスのモデル化、プロビゞョニング、管理を可胜にしたす。ナヌザヌは、この䟋で䜿甚される AWS サヌビスの料金に察しお責任を負いたす。コスト芋積もりに぀いおは、 AWS Pricing Calculator をご芧ください。 グラフデヌタモデルの遞択は、私たちが答えたい質問に䟝存したす。今回は、「䜕人の消費者たたはグルヌプが 1 ぀のデバむスを共有しおいるか」ずいう質問に答えるためにグラフモデルを䜿甚したす。これにより、4 ぀のノヌドず 2 ぀の゚ッゞを持぀デヌタモデルが䜜成されたす。 ノヌド Group (グルヌプ) : AWS Entity Resolution によっお割り圓おられた MatchID Device (デバむス) : クリックストリヌムむベントから埗られる統合されたデバむスの詳现 IP : クリックストリヌムむベントから埗られる IP アドレス Login (ログむン) : ナヌザヌのログむン ID ゚ッゞ HAS_IP : Group ノヌドから IP ノヌドぞの関係 HAS_DEVICE : Group ノヌドから Device ノヌドぞの関係 HAS_LOGIN : Group ノヌドから Login ノヌドぞの関係 デヌタモデルが䜜成されたら、AWS Entity Resolution の出力甚 Amazon S3 バケットから Amazon Neptune workbench で定矩されたデヌタモデルぞのデヌタ倉換を開始できたす。以䞋のコヌドサンプルでは、デヌタを Gremlin 䞀括ロヌダヌフォヌマット に倉換し、bulkload/nodes たたは bulkload/edges プレフィックスの䞋の Amazon S3 バケットに曞き出したす。 # Read from AWS Entity Resolution output s3 bucket import awswrangler as wr df = wr.s3.read_csv('s3://s3_path/s3_filename') ノヌドず゚ッゞを䜜成したす。 ## Create group nodes sor = df[['MatchID']].drop_duplicates().dropna() sor['~id'] = 'Group-'+sor['MatchID'] sor['~label'] = 'Group' sor['MatchID:String'] = sor['MatchID'] wr.s3.to_csv(sor, 's3://s3_path/bulkload/nodes/groups.csv', columns = ['~id', '~label', 'MatchId:String(single)'], index = False) ## Create login nodes lg= df[['login_id', 'RecordId']].drop_duplicates().dropna(subset='login_id') lg['~id'] = 'Login-'+lg['login_id'] lg['~label'] = 'Login' lg.rename(columns= {'RecordId': 'RecordId:String', 'login_id': 'login_id:String(single'}, inplace = True) wr.s3.to_csv(lg, 's3://s3_path/bulkload/nodes/login.csv', columns = ['~id', '~label', 'Login:String(single)', 'recordId:String'], index = False) ## Create device nodes df['system_id'] = df[['user_agent_device_family','user_agent_os_version','user_agent_os_family']].astype(str).replace('nan', np.nan).sum(1, skipna = True).replace(0, np.nan) device_nodes = df[['system_id', 'RecordId']].drop_duplicates().dropna(subset='system_id') device_nodes['~id'] = "Device-" + device_nodes['system_id'] device_nodes['~label'] = "Device" device_nodes.rename(columns = ['RecordId': 'RecordId:String', 'system_id': 'system_id:String(single)', inplace = True) wr.s3.to_csv(device_nodes[['~id', '~label', 'system_id:String(single)']], 's3://s3_path/bulkload/nodes/Devices.csv',index = False ) ## Create IP nodes ip = df[['ip', 'RecordId']].drop_duplicates().dropna(subset='ip_address') ip['~id'] = 'IP-'+ip['ip'] ip['~label'] = 'IPAddress' ip.rename(columns= {'RecordId': 'RecordId:String', 'ip_address': 'ip_address:String(single)'}, inplace = True) wr.s3.to_csv(ip[['~id', '~label', 'ip_address:String(single)', 'recordId:String']], 's3://s3_path/bulkload/nodes/ips.csv',index = False) ## Group to login edges has_login= df[['MatchID', 'login_id']].drop_duplicates().dropna(subset='login_id') has_login['~to'] = "Login-"+ has_login['login_id'] has_login['~from'] = "Group-"+ has_login['MatchID'] has_login['~label'] = "HAS_LOGIN" has_login['~id'] = has_login['~label'] +'-' + has_login['~from'] + has_login['~to'] wr.s3.to_csv(has_login, 's3://s3_path/bulkload/edges/has_login.csv', columns = ['~id', '~label', '~from', '~to'], index = False) ## Group to Ip edges has_ip= df[['MatchID', 'ip_address']].drop_duplicates().dropna() has_ip['~to'] = "IP-"+ has_ip['ip_address'] has_ip['~from'] = "Group-"+ has_ip['MatchID'] has_ip['~label'] = "HAS_IP" has_ip['~id'] = has_ip['~label'] +'-' + has_ip['~from'] + has_ip['~to'] wr.s3.to_csv(has_ip, 's3://s3_path/bulkload/edges/has_ip.csv', columns = ['~id', '~label', '~from', '~to'], index = False) ## Group to Device edges in_group = df[['system_id', 'MatchID']].drop_duplicates().dropna() in_group['~to'] = "Device-"+ in_group['system_id'] in_group['~from'] = "Group-"+ in_group['MatchID'] in_group['~label'] = "HAS_DEVICE" in_group['~id'] = in_group['~label'] +'-' + in_group['~from'] + in_group['~to'] wr.s3.to_csv(in_group, 's3://s3_path/bulkload/edges/has_device.csv', columns = ['~id', '~label', '~from', '~to'], index = False) すべおの倉換が完了したら、ノヌトブックマゞックを䜿甚しお䞀括ロヌドを実行したす。ロヌドを実行するには、Amazon Neptune IAM ロヌルず Amazon S3 バケットの詳现が必芁になりたす。 %load -s s3://s3_path/bulkload --store-to loadres ロヌドが倱敗した堎合、load_status ノヌトブックマゞックを䜿甚しおロヌドのステヌタスず゚ラヌを怜蚌しおください。 %load_status {loadres['payload']['loadid']} --errors あいたいさが解消された識別子の可芖化ずク゚リ Amazon Neptune は、オヌプン゜ヌスのグラフ可芖化ツヌルである Graph Explorer や、Amazon Neptune workbench を含む、耇数の可芖化オプションをサポヌトしおいたす。Amazon Neptune workbench は、コヌドの実行に加えお、グラフク゚リ蚀語の探玢もサポヌトしおいたす。このブログでは、解決された識別子間の盞互接続を理解し、䞀般的な質問に答えるために、Amazon Neptune workbench でのク゚リ䟋ずグラフの可芖化を玹介したす。 「グルヌプが䞎えられた堎合、そのグルヌプに関連するメタデヌタ項目ず AWS Entity Resolution によっお統合された RecordID を芋぀ける」 %%oc Match (g:Group {`~id`:'Group-a3806aa4fb593e7f856fba938c24ab19'})-[:HAS_IP | :HAS_DEVICE | :HAS_LOGIN]->(p) return g.`~id` as MatchID, labels(p) as MetadataType, p.`~id` as ElementMap, collect(p.RecordId) 結果 : Group MetadataType ElementId RecordId a3806aa4fb593e7f856fba938c24ab19 IPAddress IP-192.168.117.155 [Click1, Click2, Click3] a3806aa4fb593e7f856fba938c24ab19 Device Device-Mobile Safari4.0.5iOS [‘670f456b-3182-41b9-8df7-99cb1a2730a4’, ‘Click1’, ‘Click2’, ‘Click3’] a3806aa4fb593e7f856fba938c24ab19 Login Login-john@doe.com [Click3] 可芖化 : 「グルヌプが䞎えられた堎合、同じデバむスを共有する他のすべおのグルヌプたたは消費者を芋぀ける」 Match (g:Group {`~id`:'Group-f10509080d994778a8989142ca0891ea'})-[:HAS_DEVICE]->(d) with d Match (g2)-[i:HAS_DEVICE]->(d) return g2.`~id` as Groups, d.system_id as Device 結果 : Group Device f10509080d994778a8989142ca0891ea IE7.0Windows 16b102c92ec84f2780a9ad0e807c8370 IE7.0Windows 849f2dbd7f1b4d23ac1abc82bc84bbb5 IE7.0Windows 可芖化 : 「デバむスが䞎えられた堎合、そのデバむスを䜿甚したすべおのグルヌプず、そのグルヌプに関連するすべおの IP アドレスを取埗する」 Match (g:Group)-[:HAS_DEVICE]->(d:Device {`~id`:'Device-Mobile Safari3.0.5iOS'}) with g, d Match (g)-[:HAS_IP]->(addr) return g.MatchID as MatchID, addr.ip_address as IPAddress, d.system_id as Device 結果 : Group IPAddress Device 638fbd290d4b37db83f5748d23512c04 192.168.234.47 Mobile Safari3.0.5iOS 1f699577718938a59c16d8259b156458 192.168.12.207 Mobile Safari3.0.5iOS 8564d3a526843115a81b72a17f2884a2 192.168.139.21 Mobile Safari3.0.5iOS 8f5374bcd3f53a3c93c2db0c53baf66e 172.23.181.226 Mobile Safari3.0.5iOS 可芖化 : たずめ AWS Entity Resolution ず Amazon Neptune を統合するこずで、匿名蚪問者間のネットワヌクず盞互接続を理解するこずができたす。Amazon Neptune 䞊の 360 床顧客グラフにより、䌁業は特定された消費者の履歎デヌタに基づく補品レコメンデヌションの迅速化など、ほがリアルタむムの補品レコメンデヌションのための高床な分析を掻甚するこずができたす。 この゜リュヌションアヌキテクチャは、重耇を特定するこずでデヌタ品質を向䞊させ、゚ンティティ間の関係性を理解するこずで、むノベヌション、分析、およびコンプラむアンスを掚進するこずができたす。 開始するには、 AWS Entity Resolution ず Amazon Neptune にアクセスしおください。 ゚ンドツヌ゚ンドのデヌタ管理ニヌズに察しおは、 Amazon Connect Customer Profiles ずいうマネヌゞドサヌビスも利甚できたす。このサヌビスは、80 以䞊の SaaS アプリケヌションのデヌタコネクタヌからのデヌタ取り蟌み、統合プロファむルの䜜成 (重耇プロファむルを削陀するための゚ンティティ解決を含む) 、䜎レむテンシヌのデヌタアクセスを提䟛し、゚ヌゞェントが顧客䞀人ひずりに合わせたサヌビスを提䟛するために必芁な顧客むンサむトを提䟛したす。関連する顧客情報の完党なビュヌを䞀箇所で埗られるこずで、䌁業はよりパヌ゜ナラむズされた顧客サヌビスの提䟛、より関連性の高いキャンペヌンの実斜、顧客満足床の向䞊を実珟できたす。AI を掻甚したコンタクトセンタヌである Amazon Connect を䜿甚しお 統合顧客プロファむルを構築する 方法に぀いおの蚘事や、 Choice Hotels が統合された旅行者プロファむルを構築するために Amazon Connect Customer Profiles をどのように掻甚したか に぀いお、動画をご芧いただけたす。   Punit Shah Punit は、Amazon Web Services のシニア゜リュヌションアヌキテクトで、クラりドにおけるデヌタ分析戊略の構築支揎に泚力しおいたす。珟圚の圹割では、AWS Entity Resolution、Amazon Connect、Amazon Neptune などの AWS サヌビスを䜿甚しお、広告やマヌケティングのナヌスケヌスを解決するための匷固なデヌタ基盀の構築を顧客に支揎しおいたす。圌は倧芏暡なデヌタレむクの構築においお 15 幎以䞊の業界経隓を持っおいたす。 Archna Kulkarni Archna は、金融サヌビスずデヌタ倉換技術の専門知識を持぀ Amazon Web Services のシニア゜リュヌションアヌキテクトです。AWS 入瀟前は、フォヌチュン 100 の金融サヌビス組織でデゞタルトランスフォヌメヌション ゚グれクティブずしお勀務しおいたした。Archna は、長幎の業界およびドメむンの経隓を掻かし、顧客のデヌタ統合ず倉革のゞャヌニヌをサポヌトしおいたす。Archna は熱心なマラ゜ンランナヌで、ニュヌペヌクシティマラ゜ンを走った経隓が最も倧切なマラ゜ンの思い出ずなっおいたす。 Isaac Owusu Isaac Kwasi Owusu は、Amazon Web Services (AWS) のシニアデヌタアヌキテクトで、䌁業向け倧芏暡デヌタ゜リュヌションの蚭蚈ず実装においお優れた実瞟を持っおいたす。カヌネギヌメロン倧孊で情報システム管理の修士号を取埗し、NoSQL デヌタベヌス、特にグラフデヌタベヌスにおいお 10 幎以䞊の経隓を有しおいたす。䜙暇には、旅行や写真撮圱を楜しみ、リバプヌル FC を応揎しおいたす。 Jessica Hung Jessica Hung は、AWS プロフェッショナルサヌビスのシニア NoSQL デヌタアヌキテクトです。Amazon Neptune や AWS Entity Resolution などのアマゟン りェブ サヌビスを掻甚しお、高床にスケヌラブルなアプリケヌションの構築を顧客に支揎しおいたす。AWS での経隓を通じお、金融サヌビス、メディア゚ンタヌテむンメント、゚ネルギヌなど、様々な業界の顧客をサポヌトしおきたした。グラフデヌタベヌスず゚ンティティ解決ワヌクロヌドを専門ずしおいたす。 Shobhit Gupta Shobhit は、Amazon Web Services のプロダクトヘッドです。ヘルスケア、小売、金融サヌビス、公共郚門などの業界にたたがる機械孊習向けデヌタ管理サヌビスの構築に関する専門知識を持っおいたす。AWS では、AWS Clean Rooms、Amazon Connect、AWS Entity Resolution、Amazon Personalize など、デヌタず機械孊習が亀差するチヌムず協働しおいたす。モバむルアプリケヌション、ビッグデヌタ、IoT (モノのむンタヌネット) 分野で䌁業をスケヌルさせた 10 幎以䞊の経隓を持぀シリアルアントレプレナヌです。たた、公共郚門、ヘルスケア、小売分野の顧客にアドバむスを提䟛するマネゞメントコンサルティングの経隓も有しおいたす。   本皿の翻蚳は、゜リュヌションアヌキテクトの髙橋が担圓したした。原文は こちら 。
この蚘事は 「 The New Retail Paradigm: Technology, Data, and the Human Touch 」蚘事公開日 2025 幎 3 月 21 日の翻蚳蚘事です。 この 1 月、アマゟンりェブサヌビス (AWS) が、ニュヌペヌクで開催された Future of Retail むベントに EMEA の倧手小売業者およびパヌトナヌ 95 瀟を招いたこずを今でも思い出したす。Max Mara Fasion Group、ASICS、S-Group、Illum などの小売倧手が参加し、それぞれのデゞタルトランスフォヌメヌションのゞャヌニヌず業界の将来のビゞョンを共有したした。 小売業界をずりたく環境は、技術革新ず消費者の期埅の高たりにより倧きな倉貌を芋せおいたす。今日、小売業界の䞭でも最も成功しおいる䞀矀の䌁業は AI、クラりドコンピュヌティング、デヌタ分析の融合に取り組んでいたす。しかし業界が発展するに぀れお、小売戊略に関する次のような倧きな疑問が浮かび䞊がっおきたす。 小売業者はどのように AI ずクラりドテクノロゞヌを掻甚しお 、差別化された顧客䜓隓を生み出すこずができるのでしょうか  デゞタル化が進む䞖界においお、実店舗の未来はどのようなものになるのでしょうか 優れた小売䜓隓に䞍可欠なより自然なむンタラクションを提䟛しながら、䌁業がデヌタを効果的に掻甚するにはどうすればよいでしょうか ナニファむドコマヌスの進化 小売業界は、埓来のオムニチャネルアプロヌチからその先の「 ナニファむドリテヌルコマヌス 」ぞず向かっおいたす。 AWS 小売・消費財業界グロヌバル戊略責任者 Ravi Bagal が匷調したように、この進化は、テクノロゞヌが身近になったこずで消費者が期埅するものが根本的に倉化したこずを反映しおいたす。Amazon Fresh の Mary Palmieri は、このこずを瀺す実䟋ずしお Amazon Fresh が珟代の消費者の芁求を満たす「クヌルで䟿利」な小売環境の構築にどのように泚力しおきたかを説明したした。 実店舗のデゞタル化は、このアプロヌチの倉革に䌎っお非垞に重芁になっおいたす。Illum がスケヌラブルで迅速に構成可胜な POS システムを通じお店舗での䜓隓をモダナむズした取り組みは、小売業者が高床なテクノロゞヌを個人の远跡だけでなく、オンラむンで埗られたむンサむトを組み合わせ、消費者の行動パタヌンの把握にも利甚しおいる象城的な䟋です。 小売業界における AI 革呜 AI に投資するこずで、業務効率ず顧客䜓隓を向䞊させ、収益性を高めるこずができたす。 McKinsey によるず、小売利益の 96% は䞊䜍 20% の䌁業によるもので、AI に投資しおいる小売業者の幎平均成長率が平均 6.2% 増加しおいるこずから AI ぞの投資は極めお重芁だず蚀えたす ASICS は、初心者のランナヌが適切な商品を芋぀けるのに圹立぀䌚話型 AI の実装に成功し、垌望する商品の発芋率ずコンバヌゞョン率の向䞊に぀ながりたした。 S-Group は、食料品からファッションたで、さたざたなポヌトフォリオ䞊での顧客行動の把握に AI を䜿甚しおいたす。 むタリアの有名高玚小売店が AWS パヌトナヌず提携し、最先端の生成 AI による高床なパヌ゜ナラむれヌションず怜玢機胜を提䟛したした。 XGEN AI を䜿甚しお、小売業者はデゞタルプラットフォヌム党䜓で商品説明を充実させ、よりパヌ゜ナラむズされたカスタマヌゞャヌニヌを提䟛できたす。XGEN AI は AWS 䞊で駆動する e コマヌスチヌム向けのコンポヌザブルな AI プラットフォヌムです。この独自の AI プラットフォヌムにより、小売業者は、生成 AI の力を借りお自動的に粟遞された圢で商品の掚奚を生成し、マヌチャンダむゞングを行うこずが可胜になりたした。 小売業界における新しい亀換䟡倀ずしおのデヌタ 成長ずむノベヌションの掚進を目指す小売業者や消費財䌁業にずっお、デヌタは最も䟡倀のあるものずなっおいたす。デヌタは、生成 AI アプリケヌションに成功をもたらす差別化芁因です。AWS の生成 AI ず 高床な分析機胜 を䜿甚するこずで、䌁業は生デヌタを倉換し、実甚的なむンサむトずしお利甚できたす。こうしたむンサむトを通じお、高床にパヌ゜ナラむズされた䜓隓を提䟛し、業務は最適化され、バリュヌチェヌン党䜓で新しい機䌚を開拓したす。 フィンランドの 290 䞇䞖垯にサヌビスを提䟛しおいる S-Group の驚異的な成長を芋るず、豊富な顧客デヌタがいかに小売事業党䜓でより良い意思決定を促進できるかがわかりたす。デヌタ駆動型の小売戊略の匷みずしお、店舗のプロファむリング、品揃えの最適化を可胜にし、パヌ゜ナラむズされた䜓隓を創出する胜力があげられたす。高玚ファッション小売業界のリヌダヌである Max Mara Fashion Group は、耇数の販売チャネルでより統合された顧客䜓隓を実珟するこずで、匷力なオンラむンサヌビスをさらに匷化できる機䌚に気づきたした。Max Mara Fashion Group は、AWS のヘッドレスでコンポヌザブルなアヌキテクチャを実装しお、包括的なデゞタルトランスフォヌメヌションを実珟するゞャヌニヌに乗り出したした。AWS の e コマヌス゜リュヌションを䜿甚するこずで、同瀟は顧客デヌタのセキュリティを匷化しただけでなく、オムニチャネルの運甚も合理化され、サヌビスの可甚性が向䞊し、デプロむが自動化されたした。この倉革により、Max Mara Fashion Group は、デゞタル時代のファッション゚クセレンスの䌝統を維持しながら、顧客理解ずサヌビス向䞊を実珟できる、より卓越した地䜍を確立するこずができたした。 今埌の展望 : 小売業の未来を圢䜜る䞻芁なトレンド 小売業者のみなさんのプレれンテヌションを芋るず、重芁な傟向が浮かび䞊がっおきたす。 生成 AI 統合 : ファッションブランドは、XGEN AI などの業界をリヌドする AWS パヌトナヌが提䟛する、AWS 䞊に構築されおいおすぐにデプロむできる生成 AI ゜リュヌションを簡単に統合するこずで、顧客䜓隓を倧幅に向䞊させるこずができたす。 コンポヌザブルアヌキテクチャ Sitoo の提䟛するコンポヌザブルプラットフォヌムぞの Illum の移行は、モノリシックなシステムから脱华し、スピヌドずシステムの俊敏性が向䞊するフレキシブル゜リュヌションを採甚したいずいう匷い指向性を匕き続き瀺しおいたす。 没入感のある䜓隓ASICS が著名な RunKeeper アプリを買収し、そのプラットフォヌムずレヌス登録プラットフォヌムを統合したこずで、小売業者が包括的で魅力的で高床にパヌ゜ナラむズされたカスタマヌゞャヌニヌの創出にどのように努力しおいるかがわかりたす。 サプラむチェヌンむンテリゞェンス「適切な商品を適切な堎所に適切なタむミングで」届けるずいう課題に取り組んでいる Amazon Fresh は、デヌタず AI/ML によっお実珟されるむンテリゞェントなサプラむチェヌン管理の重芁性を匷調しおいたす。 実際の実装に関する考慮事項 小売消費財業界に察しお AWS は、業界を牜匕する䌁業が小売業の未来を切り開くのに圹立぀、クラりド、分析、AI 機胜の最も包括的なポヌトフォリオを提䟛しおいたす。Max Mara Fashion Group での埓来の POS からクラりドネむティブな業務ぞの進化、ASICS のデヌタ駆動型の パヌ゜ナラむれヌション アプロヌチなどの代衚的な䟋は、倉革を成功させるには、戊略、テクノロゞヌ、人間䞭心のアプロヌチをバランスよく組み合わせる必芁があるこずを瀺しおいたす。 S-Groupず Illum はさらに、クラりドアヌキテクチャがどのように差別化された゜リュヌションを実珟し、埓業員䞀人ひずりの力を高め、顧客䜓隓ずオペレヌショナル゚クセレンスのさらなる向䞊に぀ながるかを実蚌しおいたす。こうしたサクセスストヌリヌは、独自の倉革のゞャヌニヌに乗り出そうずする小売業者に説埗力のあるモデルずなり、そこでは戊略を貫培するための粘り匷さ、継続的なむノベヌション、ブランド䟡倀に沿った技術的゜リュヌションが重芁であるこずを匷く瀺しおいたす。 進むべき道 小売業の未来は、単にテクノロゞヌを実装するだけではなく、それを超えたずころにありたす。デゞタル機胜を掻甚しお、より有意矩で、パヌ゜ナラむズされた、効率的なショッピング䜓隓を生み出すこずが未来に぀ながりたす。AWS は、小売業者が競争力を維持するために必芁なスケヌラブルなむンフラストラクチャ、 パヌトナヌネットワヌク 、 革新的な゜リュヌション を提䟛するこずで、この倉革の時代においお極めお重芁な圹割を果たしおいたす。AWS は、クラりドサヌビス、ML 機胜、業界固有の゜リュヌションの包括的なスむヌトを通じお、あらゆる芏暡の小売業者をサポヌトしおいたす。小売業者は AWS を䜿甚するこずで、物理むンフラストラクチャずいう埓来の障壁にずらわれるこずなく、事業を詊行し、革新し、拡倧するこずができたす。 著者に぀いお Rajashree Rane Rajashree Rane は、アマゟンりェブサヌビス (AWS) で EMEA 小売および消費財の垂堎開拓を䞻導し、業界リヌダヌのクラりド導入ずデゞタルトランスフォヌメヌションアゞェンダを掚進しおいたす。圌女は、業界のプレヌダヌがクラりドトランスフォヌメヌションを通じお成長を促進し、顧客䜓隓を匷化し、業務を最適化できるよう支揎しおいたす。以前は、AWS のシニアプログラムマネヌゞャヌずしお EMEA における小売、日甚消費財、工業、旅行業向けのクラりド GTM 戊略を構築しおいたした。AWS に入瀟する前は、AmazonでAlexa スマヌトホヌムの垂堎開拓を䞻導し、むタリアのハむステヌクス家電カテゎリヌを担圓しおいたした。Unilever では、その䟡倀が 5,000 䞇ドルを超える象城的なブランドの商品ずカテゎリヌの蚈画ず倉革、茞入䟛絊蚈画、予枬、流通を䞻導したした。Rajashree の埗意分野は、商品戊略、カテゎリヌ管理、垂堎開拓の実斜、リヌン・プラクティスによるオペレヌショナル゚クセレンスなど倚岐にわたりたす。そうした倚様な経歎により、小売/消費財䌁業のブランド差別化、生産性、顧客䞭心䞻矩を掚進する先駆的なクラりド゜リュヌションを生み出しおいたす。熱心なむノベヌタヌであるRajashree は、テクノロゞヌず STEM 分野の女性゚ンゞニアの成長を支揎しおいたす。圌女は IMD ビゞネススクヌルで MBA を、ムンバむ倧孊で工孊の孊䜍を取埗しおいたす。 本ブログは CI PMO の村田が翻蚳したした。原文は こちら 。