TECH PLAY

AWS

AWS の技術ブログ

å…š3418ä»¶

本蚘事は 2026 幎 5 月 7 日に公開された “ Announcing aggregations on Amazon ElastiCache ” を翻蚳したものです。 Amazon ElastiCache が集蚈ク゚リをサポヌトするようになり、単䞀のク゚リでキャッシュ内のデヌタを盎接フィルタリング、グルヌプ化、倉換、集蚈するこずがより簡単になりたした。集蚈ク゚リを䜿甚するこずで、テラバむト芏暡のデヌタに察しおマむクロ秒単䜍の䜎レむテンシヌで、最新の曞き蟌みが反映された結果を返す、リアルタむムなアプリケヌション䜓隓を構築できたす。デヌタがすでに存圚する堎所で、アプリケヌションが芁求する速床で分析を行うこずができ、別途分析レむダヌを甚意する必芁はありたせん。集蚈機胜を䜿甚するず、ElastiCache に保存枈みのデヌタに察しお、リアルタむムのリヌダヌボヌド、ファセット怜玢によるカタログブラりゞング、運甚レポヌト、探玢的な分析ク゚リなどを構築できたす。 ElastiCache 内のメモリ䞊で集玄凊理を盎接実行するこずで、アヌキテクチャの耇雑さを軜枛し、応答時間を改善できたす。集玄ク゚リはサヌバヌ偎で蚈算を実行するため、アプリケヌションはデヌタをその堎で分析し、最終的なサマリヌのみを返すこずができたす。䟋えば、1 ぀の集玄ク゚リで、補品カタログをフィルタリングしお特定のカテゎリのデヌタを取埗し、結果をブランドごずにグルヌプ化し、各ブランドの平均評䟡を蚈算し、パフォヌマンス䞊䜍 10 件のみを返すずいったこずが可胜です。これらのク゚リは、GROUPBY、REDUCE、APPLY、FILTER、SORTBY、LIMIT などのステヌゞをパむプラむンに連結するこずで構築でき、各ステヌゞの出力が次のステヌゞぞの入力になりたす。これらのステヌゞを任意の順序で組み合わせ、繰り返し䜿甚するこずで、1 ぀のコマンドで耇数ステップの分析ワヌクフロヌを構築できたす。集玄はプラむマリ䞊で Read-after-Write 敎合性 (曞き蟌み埌読み取り敎合性) を提䟛するため、結果には最新の曞き蟌みが反映され、クラむアントコヌドを倉曎するこずなくシャヌド間でスケヌルしたす。本投皿では、集玄によっお実珟できるナヌスケヌスを玹介し、ElastiCache for Valkey を䜿っおファセットブラりゞング゚ンゞンを構築しながら、その仕組みを解説したす。 これらの集玄機胜は、ElastiCache version 9.0 for Valkey で、党文怜玢、完党䞀臎怜玢、範囲怜玢、ベクトル怜玢機胜 ( Amazon ElastiCache での党文怜玢、完党䞀臎怜玢、範囲怜玢、ハむブリッド怜玢 を参照) ず䞊んで利甚可胜です。ElastiCache version 9.0 for Valkey ではたた、個々のフィヌルドに察するきめ现やかな TTL 制埡を可胜にするハッシュフィヌルドの有効期限機胜や、最倧 40% 向䞊したパむプラむンスルヌプットも導入されおいたす。リリヌスの詳现に぀いおは、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご芧ください。 集玄の䜿甚が適しおいる堎面 アプリケヌションは、リアルタむムでフィルタリング、グルヌプ化、集蚈する必芁があるデヌタを ElastiCache に保存するこずがよくありたす。䟋えば、E コマヌスプラットフォヌムでは、カタログ党䜓にわたっおカテゎリ別の平均評䟡や商品数を蚈算したす。ストリヌミングサヌビスでは、ゞャンル別の総芖聎数、平均芖聎時間、再生数䞊䜍の䜜品を算出し、トレンドフィヌドやレコメンデヌションランキングを構築したす。金融サヌビスでは、ナヌザヌや時間枠ごずに取匕をグルヌプ化しお合蚈を蚈算し、しきい倀違反を怜出し、コンプラむアンスレポヌトを生成したす。アプリケヌションは、ナヌザヌ向けの゚クスペリ゚ンス、ラむブ分析、運甚レポヌトを支えるためにこのデヌタをリアルタむムに分析する必芁があり、叀いデヌタや遅い結果はナヌザヌ゚クスペリ゚ンスを䜎䞋させたす。デバッグや単発の調査のためにアドホックなク゚リが必芁な開発者は、別の分析レむダヌを蚭定したり、デヌタをアプリケヌションレむダヌに゚クスポヌトしたりするこずなく、ラむブデヌタに察しお盎接集蚈を実行するこずもできたす。集蚈は、次の 3 ぀の䞀般的なナヌスケヌスをサポヌトしたす。 カタログフィルタリングのためのファセット怜玢: E コマヌスプラットフォヌムでは、買い物客がブラりゞングする際に、各フィルタの組み合わせに䞀臎する商品数を衚瀺したす。買い物客がカテゎリや䟡栌垯を遞択するず、UI は残りのすべおのフィルタ倀のカりントを即座に曎新したす。1 ぀の集蚈ク゚リで、䞀臎するカタログをブランド、色、たたは評䟡ごずにグルヌプ化し、グルヌプごずのカりントを返すため、アプリケヌションは事前蚈算や叀いカりントのキャッシュなしに正確なファセット数を衚瀺できたす。集蚈はむンメモリで盎接実行されるため、数癟䞇の商品にたたがる堎合でも、これらのカりントはマむクロ秒のレむテンシで返されたす。 リアルタむムのトレンドずランキング: ゲヌムプラットフォヌム、ストリヌミングサヌビス、マヌケットプレむスでは、ラむブの゚ンゲヌゞメント指暙に基づいおトレンドコンテンツや䞊䜍ランカヌを衚瀺したす。埓来、これにはスケゞュヌルに埓っおランキングを再蚈算するバックグラりンドゞョブが必芁で、デヌタの陳腐化を招いおいたした。あるいは、倧量の結果セットに察するアプリケヌション偎での゜ヌトが必芁で、レむテンシヌが増加しおいたした。単䞀の集蚈ク゚リで、コンテンツをカテゎリヌごずにグルヌプ化し、総芖聎回数、゚ンゲヌゞメントスコア、プレむダヌランクを蚈算しお、䞊䜍の結果を返すこずができたす。むンデックスは曞き蟌み時に同期的に曎新されるため、集蚈ク゚リはポヌリング、キャッシュ無効化、定期的な再蚈算を行うこずなく最新のデヌタを反映したす。 運甚レポヌトず分析: ElastiCache を高速アクセスのために利甚するアプリケヌションでは、同じデヌタに察する運甚分析やレポヌトが必芁になるこずがよくありたす。䟋えば、セッションストアではデバむスごずの平均セッション時間を蚈算し、E コマヌスプラットフォヌムではステヌタスやフルフィルメント段階ごずの泚文量を蚈算したす。Aggregations は、別途の分析甚クラスタヌをプロビゞョニングしたり ETL パむプラむンを維持したりするこずなく、スケゞュヌルに基づいお、たたはオンデマンドで、これらのク゚リをむンメモリデヌタに察しお盎接実行したす。 ElastiCache を䜿ったファセット怜玢ずリアルタむム分析の構築 これらの機胜を組み合わせお実挔するために、メディアストリヌミングプラットフォヌムである AnyOrganization 向けに、ファセットブラりゞングず分析゚ンゞンを構築したす。AnyOrganization はコンテンツカタログを ElastiCache にハッシュキヌずしお保存しおおり、各映画タむトルにはゞャンル、蚀語、スタゞオ、評䟡、リアルタむムの芖聎回数ずいったメタデヌタが含たれおいたす。以䞋のコヌドでは、このデヌタに察しお 3 ぀のク゚リパタヌンを構築したす。ファセットフィルタリング、ラむブトレンドアむテム、そしおスタゞオレベルの゚ンゲヌゞメントレポヌトです。 前提条件 この蚘事の䟋では、Python ず valkey-py クラむアントラむブラリを䜿甚したす。手順を実行するには、以䞋が必芁です (所芁時間の目安: 30 分): AWS アカりント および AWS Command Line Interface (AWS CLI) ElastiCache レプリケヌショングルヌプを䜜成する暩限を持぀ AWS IAM ロヌル Amazon ElastiCache クラスタヌず同じ VPC 内にある Amazon EC2 むンスタンス (たたは Amazon ElastiCache に接続可胜な 任意のアプリケヌション) Python 3.9 以降、および valkey-py バヌゞョン 6.1.1 以降 (pip install valkey) この投皿の完党なサンプルコヌドは、 Amazon ElastiCache samples GitHub リポゞトリで入手できたす。 git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/aggregations-blog ElastiCache for Valkey クラスタヌのセットアップ 集蚈機胜を利甚するための ElastiCache クラスタヌは、 AWS Management Console たたは AWS CLI で䜜成できたす。集蚈機胜は ElastiCache version 9.0 for Valkey 以降で利甚可胜です。以䞋の䟋では CLI を䜿甚しおいたす。 aws elasticache create-replication-group \ --replication-group-id AnyOrganization-cache \ --replication-group-description "AnyOrganization Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --num-node-groups 2 \ --replicas-per-node-group 1 \ --multi-az-enabled \ --automatic-failover-enabled # --transit-encryption-enabled が蚭定されおいる堎合、Python クラむアント接続に # ssl=True を远加したす: # client = valkey.ValkeyCluster(..., ssl=True) デヌタぞのむンデックス䜜成 ElastiCache に保存されおいるデヌタに察しお、 catalog_index ずいうむンデックスを䜜成したす。 Genre 、 language 、 studio は、ファセットフィルタリング甚の完党䞀臎タグずしおむンデックス化されたす。 Release_year 、 rating 、 views_24h は、範囲フィルタや゜ヌト甚の数倀フィヌルドずしおむンデックス化されたす。タむトルは、キヌワヌド、プレフィックス、あいたい䞀臎をサポヌトする党文怜玢可胜なフィヌルドずしおむンデックス化されたす。 以䞋のコヌドは、valkey-py の search モゞュヌルを䜿甚しお Valkey Search コマンドを構築し送信したす。各 Python メ゜ッド呌び出しは、ネットワヌク越しに送信される Valkey コマンドに盎接察応しおいたす。䟋えば、 client.ft("catalog_index").create_index(...) は FT.CREATE コマンドを送信し、 client.ft("catalog_index").aggregate(req) は FT.AGGREGATE コマンドを送信したす。各コヌドブロックの暪に、察応する Valkey コマンドを瀺しおいたす。 import valkey from valkey.commands.search.field import TextField, TagField, NumericField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's discovery endpoint VALKEY_CLUSTER_ENDPOINT = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.ValkeyCluster( host=VALKEY_CLUSTER_ENDPOINT, port=6379, decode_responses=True, ssl=True) client.ft("catalog_index").create_index(fields=[ TextField("title"), TagField("genre"), TagField("language"), TagField("studio"), NumericField("release_year"), NumericField("rating"), NumericField("views_24h")], definition=IndexDefinition(prefix=["title:"],index_type=IndexType.HASH)) 同等の Valkey コマンド: FT.CREATE catalog_index ON HASH PREFIX 1 title: SCHEMA title TEXT genre TAG language TAG studio TAG release_year NUMERIC rating NUMERIC views_24h NUMERIC ElastiCache for Valkey ストアにカタログデヌタを投入したす。本蚘事では、ElastiCache GitHub リポゞトリのサンプルデヌタを䜿甚したすが、他のデヌタ゜ヌスを䜿甚するこずもできたす。 import csv import urllib.request import io import time response = urllib.request.urlopen( "https://raw.githubusercontent.com/aws-samples/amazon-elasticache-samples/main/blogs/aggregations-blog/catalog_data.csv") reader = csv.DictReader(io.TextIOWrapper(response)) count = 0 for row in reader: key = row.pop("id") client.hset(key, mapping=row) count += 1 print(f"Loaded {count} records") むンデックスはデヌタをロヌドする前でも埌でも䜜成できたす。プレフィックスに䞀臎するキヌが既に存圚する堎合、Valkey Search はそれらを自動的にむンデックスにバックフィルしたす。 ファセットフィルタヌ 以䞋の集蚈は、ナヌザヌが遞択したフィルタヌを受け取り、䞀臎する結果をゞャンル、蚀語、評䟡、公開幎でグルヌプ化し、各グルヌプのタむトル数を返したす。これにより、UI は結果ず䞊べおファセットの件数を衚瀺できたす。 from valkey.commands.search.aggregation import AggregateRequest, Desc from valkey.commands.search import reducers def get_facet_counts(filters): # Build query string from user-selected filters clauses = [] if "genre" in filters: clauses.append(f"@genre:{{{filters['genre']}}}") if "language" in filters: clauses.append(f"@language:{{{filters['language']}}}") if "min_rating" in filters: clauses.append(f"@rating:[{filters['min_rating']} + inf]") query = " ".join(clauses) if clauses else "@rating:[-inf + inf]" # Run an aggregation for each facet dimension dimensions = ["genre", "language", "rating"] facets = {} for dim in dimensions: req = AggregateRequest(query) \ .load(f"@{dim}") \ .group_by(f"@{dim}", reducers.count().alias("count")) facets[dim] = client.ft("catalog_index").aggregate(req).rows return facets # Example: user filters for dramas in english, get counts for each dimension facets = get_facet_counts({"genre": "drama", "language": "english"}) # Example output: # {'genre': [{'genre': 'drama', 'count': '6'}], # 'language': [{'language': 'english', 'count': '6'}], # 'rating': [{'rating': '4', 'count': '4'}, # {'rating': '5', 'count': '2'}]} 同等の Valkey コマンド (1 ぀のファセットディメンション、英語のドラマでフィルタリングする堎合): FT.AGGREGATE catalog_index "@genre:{drama} @language:{english}" LOAD 1 @genre GROUPBY 1 @genre REDUCE COUNT 0 AS count リアルタむムで急䞊昇䞭のアむテム 以䞋のコヌドは、ゞャンルごずのトップトレンドタむトルを取埗したす。これは、ナヌザヌがコンテンツを芖聎するずリアルタむムで曎新される views_24h フィヌルドに察する集蚈によっお実珟されおいたす。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド (1 ぀のファセットディメンションで、英語のドラマをフィルタリングする堎合): FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 リアルタむムトレンドアむテム 以䞋のコヌドは、ゞャンルごずにトレンドの䞊䜍タむトルを取埗するもので、ナヌザヌがコンテンツを芖聎するずリアルタむムに曎新される views_24h フィヌルドに察する集蚈によっお実珟されおいたす。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 オンデマンド゚ンゲヌゞメントレポヌト AnyOrganization は、制䜜スタゞオ別のコンテンツパフォヌマンスを枬定するために、日次のレポヌトゞョブを実行しおいたす。次のコヌドは、同じむンデックスに察する集蚈を䜿甚しお、タむトル数、平均評䟡、総゚ンゲヌゞメントなどのスタゞオレベルのメトリクスを蚈算したす。 def get_studio_report(): # Studio performance: title count, average rating, total 24h views req = AggregateRequest("@rating:[-inf + inf]") \ .load("@studio", "@rating", "@views_24h") \ .group_by("@studio", reducers.count().alias("title_count"), reducers.avg("@rating").alias("avg_rating"), reducers.sum("@views_24h").alias("total_views")) \ .sort_by(Desc("@total_views")) return client.ft("catalog_index").aggregate(req).rows studio_report = get_studio_report() # Example output: # [{'studio': 'StreamFlix Originals', 'title_count': '18', # 'avg_rating': '4.3333333333', 'total_views': '46200'}, # {'studio': 'Summit Pictures', 'title_count': '13', # 'avg_rating': '3.8461538462', 'total_views': '30000'}, # {'studio': 'Crimson Studios', 'title_count': '11', # 'avg_rating': '4.4545454545', 'total_views': '23100'}, # {'studio': 'Emerald Films', 'title_count': '8', # 'avg_rating': '4', 'total_views': '13600'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 3 @studio @rating @views_24h GROUPBY 1 @studio REDUCE COUNT 0 AS title_count REDUCE AVG 1 @rating AS avg_rating REDUCE SUM 1 @views_24h AS total_views SORTBY 2 @total_views DESC ベストプラクティス 集蚈ク゚リのレむテンシヌずスルヌプットを改善するには、各パむプラむンステヌゞを通過するドキュメント数を枛らすために早い段階でフィルタリングしたす。マッチする範囲が広いク゚リは、パむプラむンに入るキヌの数が増え、初期スキャンず初期ステヌゞのコストが増加したす。䟋えば、䞊蚘のファセットフィルタリングの䟋では、ナヌザヌのアクティブなフィルタヌをク゚リ文字列で枡すこずで、マッチするドキュメントのみが GROUPBY ステヌゞに入りたす。たた、しきい倀を満たさないグルヌプを削陀するために GROUPBY ステヌゞの埌に FILTER を远加するこずもできたす。䟋えば、結果を返す前にタむトル数が 5 未満のゞャンルを陀倖する堎合などです。さらに、䞊䜍の結果のみが必芁な堎合は、 SORTBY に MAX を远加するこずで、トレンドアむテムの䟋で瀺すように、゚ンゞンはワヌキングセット党䜓を゜ヌトするのではなく、䞊䜍の結果のみを远跡したす。 LOAD を䜿うず、むンデックスに含たれおいないフィヌルドであっおも、基ずなるハッシュデヌタから盎接フィヌルドを取埗しお集玄パむプラむンに取り蟌むこずができたす。䟋えば、ハッシュに actors フィヌルドを保存しおいるがむンデックス化しおいない堎合、ク゚リ実行時に LOAD で読み蟌み、それを䜿っおグルヌプ化や゜ヌトを行うこずができたす。ただし、 LOAD は䞀臎するドキュメントごずに基ずなるキヌから生デヌタを取埗する必芁があるため、結果セットのサむズに応じおレむテンシヌが増加したす。このオヌバヌヘッドを避けるため、ロヌドするフィヌルドの数は最小限に抑えおください。 クリヌンアップ このりォヌクスルヌのために ElastiCache クラスタヌを䜜成し、䞍芁になった堎合は、今埌の課金を避けるために、次の AWS CLI コマンドを䜿甚しおクラスタヌを削陀しおください。 aws elasticache delete-replication-group --replication-group-id AnyOrganization-cache はじめに この蚘事では、ElastiCache のアグリゲヌションに぀いお、ファセットフィルタリング、ラむブトレンドのレコメンデヌション、オンデマンドの゚ンゲヌゞメントレポヌトを取り䞊げ、これらすべおを単䞀の Valkey Search むンデックス䞊に構築する方法を解説したした。アグリゲヌションは、すべおの商甚 AWS リヌゞョン、AWS GovCloud (US) リヌゞョン、および䞭囜リヌゞョンにおいお、ElastiCache for Valkey バヌゞョン 9.0 を実行するノヌドベヌスのクラスタヌで远加費甚なしでご利甚いただけたす。Valkey は、Redis に代わる最も寛容なラむセンスのオヌプン゜ヌスか぀ベンダヌ䞭立な遞択肢であり、ElastiCache で掚奚される゚ンゞンです。䜿い始めるには、AWS Management Console、AWS SDK、たたは AWS CLI を䜿甚しお、Valkey 9.0 以降の新しいクラスタヌを䜜成するか、 既存のクラスタヌをアップグレヌド しおください。詳现に぀いおは、 ElastiCache のドキュメント をご芧ください。質問やフィヌドバックがある堎合は、 AWS re:Post for ElastiCache をご芧ください。 著者に぀いお Chaitanya Nuthalapati Chaitanya は AWS むンメモリデヌタベヌスサヌビスのシニアテクニカルプロダクトマネヌゞャヌで、Amazon ElastiCache for Valkey に泚力しおいたす。以前は、生成 AI、機械孊習、グラフネットワヌクを掻甚した゜リュヌションを構築しおいたした。仕事以倖の時間では、Chaitanya は趣味を集めるのに忙しく、珟圚はテニス、スケヌトボヌド、パドルボヌドを楜しんでいたす。 Karthik Subbarao Karthik は Amazon ElastiCache のシニア゜フトりェア゚ンゞニアであり、オヌプン゜ヌスの Valkey プロゞェクトに積極的に貢献しおいたす。分散システム、デヌタベヌス、Rust、そしお党般的に゜フトりェア開発テクノロゞヌを通じたむノベヌションに情熱を泚いでいたす。 Allen Samuels Allen は AWS のプリンシパル゚ンゞニアです。分散型で高性胜なシステムに情熱を泚いでいたす。䞖界䞭を旅したりデュプリケヌトブリッゞをプレむしたりしおいない時は、カリフォルニア州サンノれで過ごしおいたす。 Siva Subramaniam Siva は AWS のシニア゜リュヌションアヌキテクトで、技術リヌダヌシップずデヌタベヌスアヌキテクチャにおいお 20 幎の経隓を持っおいたす。お客様が AWS の専甚デヌタベヌスを䜿甚しお移行ずむノベヌションを実珟できるよう支揎しおいたす。仕事以倖では、Siva はクリケット、蟲䜜業、そしお劻から料理を孊ぶこずを楜しんでいたす。 ご指導いただいた Ian Childress 氏、そしおプロゞェクト党䜓を通じお実装面で貢献いただいた Miles Song 氏に特に感謝いたしたす。 本蚘事は、 Announcing aggregations on Amazon ElastiCache を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
本蚘事は 2026 幎 5 月 7 日に公開された “ Full-text, exact-match, range, and hybrid search on Amazon ElastiCache ” を翻蚳したものです。 蚳者蚻 本蚘事の党文怜玢は、珟時点では蚀語オプションずしお english のみをサポヌトしおおり、日本語テキストはスペヌスや句読点で区切られた単䜍でむンデックスされたす。日本語を党文怜玢する堎合は、事前に圢態玠解析で語ごずにスペヌスで区切ったテキストをむンデックスし、怜玢ク゚リも同じ圢で枡すようにしおください。 Amazon ElastiCache は、別個の怜玢サヌビスを䜿甚するこずなく、キャッシュ内で盎接リアルタむムの党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、ハむブリッド怜玢をサポヌトするようになりたした。䜎レむテンシヌで動的デヌタに察するスケヌラブルな怜玢を必芁ずするワヌクロヌドに察しお、アプリケヌションはマむクロ秒単䜍のレむテンシヌず毎秒最倧数癟䞇回の怜玢操䜜のスルヌプットでテラバむト芏暡のデヌタを怜玢できたす。これらの新しい怜玢機胜により、開発者は ElastiCache に既に保存されおいるデヌタを、単玔なキヌバリュヌ怜玢を超えた属性で柔軟にク゚リできるようになりたす。 完党䞀臎怜玢は、商品名、カテゎリ、ナヌザヌ ID、泚文番号など、テキスト、タグ、数倀属性にわたる正確な倀の䞀臎によっおドキュメントを取埗したす。数倀範囲怜玢は、䟡栌のしきい倀、日付範囲、取匕金額などの属性によっおドキュメントをフィルタリングしたす。完党䞀臎に加えお、党文怜玢はテキスト属性に察しお、オヌトコンプリヌト (入力補完) 甚のプレフィックスマッチング、タむプミス蚱容のためのファゞヌマッチング、耇数語怜玢のための近接マッチングを実行したす。これらの怜玢タむプをベクトル類䌌床ず単䞀のハむブリッドク゚リで組み合わせるこずができ、正確な甚語ず意味的な意図の䞡方を捉えるこずで、いずれかの手法を単独で䜿甚するよりも関連性の高い結果を提䟛したす。ベクトルワヌクロヌドにおいお、ElastiCache for Valkey は AWS 䞊の䞻芁なベクトルデヌタベヌスの䞭で、95% 以䞊の再珟率で最䜎レむテンシか぀最高スルヌプットのベクトル怜玢、そしお最高の䟡栌性胜比を実珟したす。 これらの怜玢機胜は、ElastiCache version 9.0 for Valkey で利甚可胜であり、リアルタむム分析やレポヌティング向けのサヌバヌサむド集蚈機胜も䜵せお提䟛されおいたす ( Amazon ElastiCache での集蚈機胜のお知らせ を参照)。ElastiCache version 9.0 for Valkey では、個々のフィヌルドに察するきめ现かい TTL 制埡を可胜にするハッシュフィヌルドの有効期限機胜や、最倧 40% 向䞊したパむプラむン化スルヌプットも導入されおいたす。リリヌスの詳现に぀いおは、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご芧ください。 この蚘事では、新しい怜玢機胜を順を远っお玹介し、それらがどのように連携するかを瀺しながら、怜玢およびレコメンデヌション゚ンゞンをれロから構築しおいきたす。 耇数のアプリケヌションにわたる匷力なリアルタむム怜玢を実珟 お客様からは、アプリケヌションがスケヌルするに぀れお、怜玢ワヌクフロヌがビゞネスに求められるスルヌプットをサポヌトしながら、ナヌザヌが期埅する䜎レむテンシヌの䜓隓を維持する必芁があるずの声が寄せられおいたす。䟋えば、決枈プラットフォヌム、ストリヌミングプラットフォヌム、オンラむン小売業者などは、䜕癟䞇ものドキュメントを ElastiCache に保存し、マむクロ秒のレむテンシヌでメタデヌタ属性によっおデヌタを取埗する必芁がありたす。さらに、ワヌクロヌドが進化するに぀れお、すでに ElastiCache に保存されおいるデヌタに察しお新しいナヌスケヌスをサポヌトする豊富な怜玢ク゚リが必芁だずいうお客様の声もありたす。䟋えば、アプリケヌションはデバむスタむプ、セッション状態、ナヌザヌアクティビティなどのナヌザヌおよびセッションコンテキストを ElastiCache に保存し、䜎レむテンシヌの䜓隓を提䟛するこずがよくありたす。ワヌクロヌドが進化するに぀れお、お客様はその同じデヌタをレコメンデヌションシステムの基盀ずしお掻甚したいず考えおおり、そのためにはこれらの属性をたたいだ怜玢が必芁になりたす。 ElastiCache では、マむクロ秒単䜍の䜎レむテンシヌず毎秒数癟䞇ク゚リ (QPS) のスルヌプットでデヌタを怜玢・取埗するためのさたざたな方法が提䟛されるようになりたした。曞き蟌みが完了するずすぐにデヌタが怜玢可胜になるため、アプリケヌションは垞に最新の結果をク゚リできたす。これらの機胜は、カタログ怜玢、レコメンデヌション゚ンゞン、゚ヌゞェント型メモリ、リアルタむムのリヌダヌボヌド、セッション怜玢などのナヌスケヌスを支えたす。 カタログ怜玢: オンラむン小売業者やストリヌミングプラットフォヌムは、顧客が倧芏暡なカタログから商品を芋぀けられるような怜玢䜓隓を構築しおいたす。これらのプラットフォヌムでは、商品名や説明文に察するテキスト怜玢ず、ブランド、カテゎリ、䟡栌、評䟡によるフィルタを単䞀のク゚リで組み合わせるこずで、ファセットブラりゞング䜓隓を提䟛できたす。プレフィックスマッチングは、ナヌザヌが入力するに぀れお候補を読み蟌むタむプアヘッド怜玢を実珟し、マむクロ秒単䜍で結果を返すため、即座に反応するような䜓隓を提䟛したす。さらに、ファゞヌマッチングを掻甚したタむプミスに匷い怜玢を組み合わせるこずで、スペルミスを自動的に凊理し、怜玢䜓隓をより堅牢にできたす。ファゞヌマッチングは完党䞀臎怜玢よりも蚈算コストが高いため、ElastiCache のようなむンメモリ怜玢゚ンゞン䞊で実行するこずで、高速で応答性の高い䜓隓を維持できたす。 レコメンデヌション゚ンゞン: カタログが数癟䞇アむテムに拡倧するに぀れお、ナヌザヌはデゞタルプラットフォヌムに察しお、関連性の高いコンテンツや商品を玠早く衚瀺するパヌ゜ナラむズされた閲芧䜓隓を期埅しおいたす。最新のレコメンデヌションシステムは、ナヌザヌずアむテムをベクトル埋め蟌みずしお゚ンコヌドしたす。これらのシステムは、ベクトル怜玢ず名前、説明、カテゎリ、圚庫状況、䟡栌垯などのフィルタヌを組み合わせお、数癟䞇のアむテムからレコメンデヌション候補を取埗したす。ハむブリッド怜玢は、テキスト、タグ、数倀フィルタヌをベクトル類䌌床ず単䞀のク゚リで組み合わせるこずでこれをサポヌトし、取埗される候補は意味的に関連性があり、ビゞネス䞊の制玄も満たしたす。商品ペヌゞでは、同じカテゎリず䟡栌垯にフィルタリングしおから埋め蟌みの類䌌床でランク付けするこずで、「類䌌アむテム」を衚瀺できたす。これを拡匵しお、行動履歎 (閲芧したアむテムの埋め蟌みの平均プヌリング、アテンションベヌスのモデル、シヌケンシャルモデルなどの手法を䜿甚) からナヌザヌ埋め蟌みを構築し、それをベクトルク゚リずしお枡すこずで、孊習した嗜奜に基づいお結果をランク付けするパヌ゜ナラむズされたレコメンデヌションを実珟できたす。 ゚ヌゞェントメモリ: ゚ヌゞェントメモリは、゚ヌゞェントが過去のやり取りから孊習するこずで、䌚話履歎党䜓を再生するこずなく応答の関連性を向䞊させ、トヌクンコストを削枛したす。゚ヌゞェントメモリシステムは、スコヌプ属性 (ナヌザヌ、゚ヌゞェント、セッション) ず珟圚のやり取りに察する意味的関連性によっおメモリを保存・取埗したす。ハむブリッド怜玢を䜿甚するこずで、これらのシステムはスコヌプやテキストフィルタヌずベクトル類䌌性を 1 ぀のク゚リで組み合わせたす。゚ヌゞェントメモリはラむブの䌚話パス䞊にあるため、曞き蟌み埌すぐに読み取れる可芖性が求められ、新しく保存された事実が即座に取埗可胜である必芁があり、新しいメモリの取埗ず統合のために高い同時読み曞き性胜が求められたす。ElastiCache は曞き蟌み時にメモリを同期的にむンデックス化し、マルチスレッディングを掻甚し、AWS 䞊の䞻芁なベクトルデヌタベヌスの䞭で最高のスルヌプットをマむクロ秒レベルのレむテンシヌで提䟛したす。ElastiCache ず Mem0 を䜿甚したステップバむステップの実装に぀いおは、 Build persistent memory for agentic AI applications with Mem0 Open Source, ElastiCache for Valkey, and Amazon Neptune Analytics をご芧ください。 ElastiCache for Valkey は、セルフマネヌゞドのメモリレむダヌを構築したい堎合や、䜎レむテンシでカスタマむズ可胜なむンメモリストアが必芁な堎合に適しおいたす。フルマネヌゞドのアプロヌチをお奜みの堎合は、 Amazon Bedrock AgentCore Memory を䜿甚しおメモリを管理するこずもできたす。 金融アプリケヌションずリヌダヌボヌド: 取匕プラットフォヌムやゲヌムアプリケヌションでは、取匕金額、タむムスタンプ、リスクスコア、プレむダヌランキングずいった数倀属性を持぀ドキュメントを保存し、䜎レむテンシヌで取埗する必芁がありたす。ElastiCache の数倀範囲ク゚リは、これらの属性に察する高速な怜玢をサポヌトし、時間枠、金額のしきい倀、スコア垯によるフィルタリングを可胜にしたす。ゲヌムアプリケヌションでは、スコアの曎新を即座に反映するリアルタむムなリヌダヌボヌドを維持でき、「自分の地域のトップ 100 プレむダヌ」のような範囲ク゚リにも察応できたす。 ナヌザヌおよびセッション管理: 各業界のアプリケヌションは、セッション管理のためにセッション ID、デバむスタむプ、ナヌザヌハンドルずいった構造化属性をキャッシュに保存しおいたす。これらのアプリケヌションは、ナヌザヌがログむンするずセッションデヌタをキャッシュに曞き蟌み、セッションのラむフサむクルを通じお曎新するため、即時に怜玢可胜な高速曞き蟌みが求められたす。ElastiCache は曎新を同期的にむンデックス化するため、セッション属性に察する怜玢は遅延なく最新の状態を反映したす。完党䞀臎怜玢により、数癟䞇のドキュメントから正確な識別子に基づいおアクティブなセッションや暩限をサブミリ秒のレむテンシヌで特定できたす。 ElastiCache を䜿った怜玢・レコメンデヌション゚ンゞンの構築 これらの怜玢タむプを組み合わせお実挔するため、゚レクトロニクス、矎容、家庭甚品など䜕癟䞇もの補品を販売する e コマヌスプラットフォヌム AnyCompany 向けの怜玢およびレコメンデヌション゚ンゞンを構築したす。AnyCompany は、買い物客がキヌワヌドで補品を芋぀け、ブランドや䟡栌垯などのフィルタヌで絞り蟌み、類䌌性を通じお関連商品を発芋できる怜玢䜓隓を求めおいたす。AnyCompany は 100 䞇を超える商品カタログを ElastiCache にハッシュベヌスのドキュメントずしお保存しおいたす (この䟋では、実際のタむトル、説明、ブランドを含む Amazon ESCI デヌタセット から掟生したもの)。次のコヌドは、このデヌタに察しお 5 ぀のク゚リパタヌンを構築したす: 入力補完怜玢、党文䞀臎、タむポに匷いマッチング、フィルタヌ付きブラりゞング、そしお類䌌商品のレコメンデヌションです。 前提条件 この蚘事の䟋では、 valkey-py クラむアントラむブラリず Python を䜿甚しおいたす。手順を実行するには、以䞋が必芁です (所芁時間の目安: 30 分): AWS アカりント ず AWS Command Line Interface (AWS CLI) ElastiCache レプリケヌショングルヌプを䜜成する暩限を持぀ AWS IAM ロヌル Amazon ElastiCache クラスタヌず同じ VPC 内にある Amazon EC2 むンスタンス (たたは Amazon ElastiCache に接続可胜 な任意のアプリケヌション) Python 3.9 以降および valkey-py バヌゞョン 6.1.1 以降 (pip install valkey) この蚘事の完党なサンプルコヌドは、ElastiCache samples GitHub リポゞトリで入手できたす。 ElastiCache for Valkey クラスタヌのセットアップ ElastiCache の怜玢甚クラスタヌは、AWS Management Console たたは AWS CLI を䜿甚しお䜜成できたす。以䞋の䟋では CLI を䜿甚しおいたす。怜玢機胜は ElastiCache for Valkey バヌゞョン 9.0 以降で利甚可胜です。 aws elasticache create-replication-group \ --replication-group-id AnyCompany-cache \ --replication-group-description "AnyCompany Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --replicas-per-node-group 0 むンデックスの䜜成ずデヌタのロヌド 商品デヌタを怜玢可胜にするため、 products_vec_index ずいうむンデックスを䜜成したす。タむトルず説明は、キヌワヌド、前方䞀臎、あいたい怜玢をサポヌトする党文怜玢可胜な属性ずしおむンデックス化されたす。ブランドず色は、絞り蟌み怜玢のために完党䞀臎タグずしおむンデックス化されたす。䟡栌、評䟡、圚庫は、範囲ク゚リや゜ヌトのために゜ヌト可胜な数倀属性ずしおむンデックス化されたす。 embedding は、セマンティック類䌌怜玢やレコメンデヌションのためにベクトル属性ずしおむンデックス化されたす。 import gzip import json import struct import urllib.request import valkey from valkey.commands.search.field import TextField, TagField, NumericField, VectorField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's endpoint VALKEY_HOST = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.Valkey(host=VALKEY_HOST, port=6379, decode_responses=False, ssl=True, ssl_cert_reqs="required") # Create the search index with text, tag, numeric, and vector fields try: client.execute_command("FT.DROPINDEX", "products_vec_index") except: pass client.ft("products_vec_index").create_index( fields=[ TextField("title"), TextField("description"), TagField("brand", separator=","), TagField("color", separator=","), NumericField("price"), NumericField("rating"), NumericField("stock"), VectorField("embedding", "FLAT", { "TYPE": "FLOAT32", "DIM": 64, "DISTANCE_METRIC": "COSINE"})], definition=IndexDefinition(prefix=["pv:"], index_type=IndexType.HASH)) ElastiCache ストアに商品デヌタセットを投入したす。このデヌタセットは 130 䞇件の商品のサブセットで、タむトル、説明、ブランド、および Amazon ESCI Shopping Queries デヌタセットから導出された事前蚈算枈みの 64 次元゚ンベディングを含む 13.7 䞇件の商品で構成されおいたす。サンプルリポゞトリをクロヌンし、ロヌドスクリプトを実行しおください git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/elasticache-valkey/fts-benchmark # <入力が必芁>: VALKEY_HOST 倉数をクラスタヌの゚ンドポむントで曎新しお実行: python load_products_blog.py タむプアヘッド怜玢 (先行入力怜玢) むンデックスずデヌタが準備できたら、AnyCompany はむンデックスに察しお実行され、䞀臎するドキュメントを返す FT.SEARCH ク゚リを䜿っお怜玢゚ンゞンを構築できたす。ナヌザヌが怜玢バヌに入力するず、アプリケヌションはプレフィックスク゚リを送信し、リアルタむムで候補を衚瀺したす。 from valkey.commands.search.query import Query results = client.ft("products_vec_index").search( Query("wire*").return_fields("title").paging(0, 5)) # User has typed "wire" - prefix match shows suggestions # Output: # [{'title': 'xyz Kids Wireless Headphones'}, # ... # ... # {'title': 'Santas Wire Christmas Lighting Storage Bag'}] フレヌズマッチング ナヌザヌが Enter キヌを抌すず、アプリケヌションはタむトルず説明に察しお党文怜玢を実行したす。SLOP は、単語同士がどれだけ離れおいおも䞀臎ず芋なすかを制埡し、単語がより近接しおいる結果ほど䞊䜍にランク付けされたす。 # User submits "wireless headphones" # SLOP 2 allows up to 2 words between terms results = client.ft("products_vec_index").search( Query("wireless headphones") .slop(2) .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Studio3 Wireless Headphones - Gray (Renewed)', # 'brand': 'xyz', 'price': '1928.28'}, # ... # {'title': 'xyz TUNE 220TWS - True Wireless in-Ear Headphone - Blue', # 'brand': 'xyz', 'price': '1121.23'}] タむプミスを蚱容するマッチング ク゚リが結果を返さない堎合、アプリケヌションはタむプミスを修正するためにあいたい䞀臎 (fuzzy matching) で再詊行したす。あいたい䞀臎は線集距離を蚈算するためコストが高いので、デフォルトずしおではなくフォヌルバックずしお䜿うのが最適です。 # Retry with fuzzy matching for "wireles headphoens" results = client.ft("products_vec_index").search( Query("%wireles% %headphoens%") .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Comfort 35 Wireless Headphones, Noise Cancelling - Silver (Renewed)', # 'brand': 'xyz', 'price': '1811.75'}, # ... # ... # {'title': 'xyz SoundSport Wireless Headphones, Black + Charging Case', # 'brand': 'xyz', 'price': '568.47'}] フィルタリングによる閲芧 買い物客が商品を怜玢しおフィルタヌを適甚するず、アプリケヌションはテキスト怜玢ずタグおよび数倀フィルタヌを単䞀のク゚リで組み合わせたす。 # ナヌザヌが「headphones」を怜玢し、䟡栌 $50-$150、評䟡 4.0 以䞊でフィルタリング results = client.ft("products_vec_index").search( Query("@title:headphones @price:[50 150] @rating:[4.0 5.0]") .return_fields("title", "brand", "price", "rating") .paging(0, 5)) # 出力: # [{'title': 'xyz WH1000XM3 Bluetooth Wireless Noise Canceling Headphones', # 'brand': 'xyz', 'price': '102.29', 'rating': '4.8'}, # ... # ... # {'title': 'Bluetooth Earbuds xyz SoundLink .. in Ear Headphones', # 'brand': 'xyz', 'price': '125.45', 'rating': '4.5'}] 類䌌商品のレコメンデヌション 「類䌌商品」のレコメンデヌションを実珟するために、AnyCompany はテキストフィルタヌを䜿ったハむブリッド怜玢で結果を該圓する商品タむプに絞り蟌み、ベクトル怜玢で衚瀺䞭の商品ずの類䌌床に基づいおフィルタヌ枈みの結果をランク付けしおいたす。 # Get the embedding of the product the user is currently viewing # for example - "Kids Headphones with Microphone 2 Pack" product_embedding = client.hget("pv:B0825SSTMN", "embedding") # Hybrid: text pre-filter "headphones" + vector KNN for similarity ranking results = client.ft("products_vec_index").search( Query("@title:headphones =>[KNN 5 @embedding $vec AS score]") .return_fields("title", "brand", "price", "score") .dialect(2), query_params={"vec": product_embedding}) # Output: # {'title': 'xyz I35 Kid Headphones with Microphone Volume Limited ...', # 'brand': 'xyz', 'price': '155.06', 'score': '0.293'}, # ... # ... # {'title': 'Kids Headphones with Pouch, xyz Wired ...', # 'brand': 'xyz', 'price': '957.95', 'score': '0.351'}] このパタヌンを拡匵しお、埋め蟌みベヌスの怜玢を掻甚したパヌ゜ナラむれヌションを実珟できたす。閲芧したアむテム埋め蟌みの平均プヌリング、アテンションベヌスのモデル、シヌケンスモデルなどの手法を甚いお、買い物客のむンタラクション履歎からナヌザヌ埋め蟌みを構築したす。単䞀の商品埋め蟌みの代わりにナヌザヌ埋め蟌みをベクトルク゚リずしお枡すこずで、KNN スコアリングがフィルタリングされた集合の䞭から、買い物客の孊習枈みの嗜奜に基づいお結果をランキングしたす。 内郚の仕組みずパフォヌマンス レむテンシヌずスルヌプットを、テキストず数倀のク゚リタむプに぀いお、レプリカなしの単䞀の cache.r7g.2xlarge ノヌドを含む 1 シャヌド構成の ElastiCache for Valkey クラスタヌ䞊で蚈枬したした。デヌタセットには玄 1 GB のデヌタが含たれおおり、䞊蚘の䟋で説明したテキスト、タグ、数倀、ベクトル属性を持぀ 130 䞇件の補品ドキュメントで構成されおいたす。レむテンシヌずスルヌプットの蚈枬には valkey-benchmark を䜿甚したした。 ク゚リタむプ P50 (ms) 1 クラむアント P99 (ms) 1 クラむアント QPS 300 クラむアント テキスト怜玢 (完党䞀臎) 0.135 0.255 60,000 前方䞀臎 (タむプアヘッド怜玢) 0.135 0.279 57,692 数倀範囲 (圚庫/評䟡でのフィルタ) 0.175 0.199 24,087 ハむブリッドク゚リ – テキスト + 数倀範囲 (ファセットブラりゞング) 0.135 0.295 52,632 ベクトル怜玢のレむテンシヌずスルヌプットのベンチマヌクに぀いおは、 Announcing vector search for Amazon ElastiCache を参照しおください。䞊蚘の䟋では、単䞀の cache.r7g.2xlarge ノヌドでのパフォヌマンスをテストしおいたす。レプリカ (シャヌドあたり最倧 5 ぀) ずシャヌドを远加するこずで読み取りスルヌプットをスケヌルし、数癟䞇 QPS に到達できたす。各レプリカは独自のむンデックスを持ち、独立しお怜玢を凊理できたすが、レプリカからの読み取りは結果敎合性ずなりたす。デヌタ容量よりも䜎レむテンシヌを優先する堎合は、 single-slot indexes を䜿甚しお、むンデックス化されたすべおのデヌタを 1 ぀のシャヌドに保持し、ファンアりトのオヌバヌヘッドを完党に回避しおください。シャヌドを远加するこずで、クラむアントコヌドを倉曎せずにメモリ容量を増やすこずができたす。 ElastiCache はデヌタの倉曎をリアルタむムで自動的にむンデックス化し、゚ンゞンは各曞き蟌みを確認応答する前にむンデックス化したす。そのため、それ以降の怜玢では曎新埌のデヌタが返され、read-after-write 敎合性が提䟛されたす。この敎合性の動䜜は、マルチキヌトランザクションや Lua スクリプトでも同様に保たれたす。Valkey はマルチスレッドを掻甚しおむンデックス凊理を耇数のスレッドにたたがっお実行するため、ElastiCache は曞き蟌みスルヌプットの高いワヌクロヌドにおいおも怜玢ク゚リで高いパフォヌマンスを発揮できたす。 クリヌンアップ このりォヌクスルヌのために ElastiCache クラスタヌを䜜成し、䞍芁になった堎合は、今埌の料金が発生しないように、次の AWS CLI コマンドを䜿甚しおクラスタヌを削陀しおください。 aws elasticache delete-replication-group --replication-group-id AnyCompany-cache たずめ 本投皿では、ElastiCache における党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、およびハむブリッド怜玢に぀いお解説したした。これらの怜玢タむプのナヌスケヌスを取り䞊げ、怜玢およびレコメンデヌションシステムの構築方法をご玹介したした。党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、およびハむブリッド怜玢は、Valkey 9.0 を実行する ElastiCache のノヌドベヌスクラスタヌにおいお、すべおの AWS 商甚リヌゞョン、AWS GovCloud (US) リヌゞョン、および䞭囜リヌゞョンで远加費甚なしでご利甚いただけたす。Valkey は、最も制玄の少ないオヌプン゜ヌスか぀ベンダヌニュヌトラルな Redis に代わる遞択肢であり、ElastiCache における掚奚゚ンゞンです。始めるには、AWS Management Console、AWS SDK、たたは AWS CLI を䜿甚しお、新しい Valkey 9.0 以降のクラスタヌを䜜成するか、 既存のクラスタヌをアップグレヌド しおください。詳现に぀いおは、 ElastiCache のドキュメント をご芧ください。ご質問やフィヌドバックは、 AWS re:Post for ElastiCache たでお寄せください。 著者に぀いお Chaitanya Nuthalapati Chaitanya は AWS むンメモリデヌタベヌスサヌビスのシニアテクニカルプロダクトマネヌゞャヌで、Amazon ElastiCache for Valkey を担圓しおいたす。以前は、生成 AI、機械孊習、グラフネットワヌクを掻甚した゜リュヌションを構築しおいたした。仕事以倖の時間では、Chaitanya は趣味を集めるこずに忙しく、珟圚はテニス、スケヌトボヌド、パドルボヌドを楜しんでいたす。 Karthik Subbarao Karthik は Amazon ElastiCache のシニア゜フトりェア゚ンゞニアで、オヌプン゜ヌスの Valkey プロゞェクトに積極的に貢献しおいたす。分散システム、デヌタベヌス、Rust、そしお党般的に゜フトりェア開発・技術を通じたむノベヌションに情熱を持っおいたす。 Ian Childress Ian は AWS の゜フトりェア開発マネヌゞャヌで、党文怜玢むンフラストラクチャを含む Valkey モゞュヌルおよび統合機胜を構築するチヌムを率いおいたす。仕事以倖では、Ian はホッケヌをプレむし、Go 蚀語で高性胜システムを曞くこずに没頭する飜くなき探求者です。倏になるず、氷から湖ぞず舞台を移し、毎週末家族ずりェむクサヌフィンを楜しんでいたす。 Eran Balan Eran は AWS のスペシャリスト゜リュヌションアヌキテクトで、むンメモリデヌタベヌスおよび Amazon ElastiCache を専門ずしおいたす。EMEA 地域のお客様ず協力し、キャッシングアヌキテクチャの蚭蚈、パフォヌマンスの最適化、Redis OSS から Valkey ぞの移行など、さたざたな移行を支揎しおいたす。仕事以倖では、Eran はミュヌゞカルや挔劇の芳劇、ハむキング、オヌプンりォヌタヌスむミングを楜しんでいたす。 プロゞェクト党䜓を通じお、ビゞョン、指導、そしお実践的な貢献をいただいた Allen Samuels 氏に心より感謝申し䞊げたす。 本蚘事は、 Full-text, exact-match, range, and hybrid search on Amazon ElastiCache を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
本蚘事は 2026 幎 5 月 7 日に公開された “ Valkey turns two ” を翻蚳したものです。 2 幎前、 Valkey は、Redis に察する真にオヌプンでベンダヌニュヌトラルな代替手段の必芁性に応えるコミュニティ䞻導の取り組みずしお誕生したした。本蚘事では、この 2 幎間の歩みを振り返り、Valkey の急速な普及、コミュニティによっおもたらされたむノベヌション、そしおこれらの発展がモダンなキャッシングおよびリアルタむムデヌタ基盀の未来にずっお䜕を意味するのかをご玹介したす。わずか 2 幎ずいう短い期間で、Valkey はほがすべおの䞻芁なクラりドプロバむダヌやオヌプン゜ヌスディストリビュヌションにおけるデフォルトの高性胜キヌバリュヌデヌタストアずなり、キャッシング分野におけるコミュニティ䞻導のむノベヌションの䞭心的存圚ずなりたした。Valkey は Docker の环蚈プル数 1 億回を突砎し (前幎比 17 倍)、225 名を超えるコントリビュヌタヌを集め、1,500 件以䞊のプルリク゚ストが提出されおいたす。これは同時期の Redis の開発ペヌスのおよそ 2 倍に盞圓したす。 この勢いは、匷力なむノベヌションのフラむホむヌルを生み出しおいたす。クラりドプロバむダヌ、䌁業、開発者党䜓で採甚が拡倧するに぀れ、Valkey オヌプン゜ヌス゚コシステム党䜓からの貢献により、セキュリティ、信頌性、パフォヌマンス、コスト効率、および高床な機胜の改善が掚進されおきたした。これらの改善により、本番環境で 最倧 60% 優れた䟡栌性胜比 や、党文怜玢、集蚈、ベクトル類䌌性、Bloom フィルタヌなどの高床な機胜を利甚できるようになるずいった、目に芋える圢での向䞊が実珟しおいたす。こうした匷化により、䜕䞇もの Amazon ElastiCache のお客様が数十䞇のクラスタヌを Valkey に移行しおいたす。Intuit、Airbnb、Nextdoor、Tinder、Peloton、Amazon Ads、Amazon Music ずいった 組織 は珟圚、最もレむテンシヌに敏感でビゞネスクリティカルなシステムの䞀郚を Valkey に䟝存しおいたす。 このむノベヌションのフラむホむヌルは、Valkey のオヌプンガバナンスずコミュニティ䞻導の開発モデルによっお実珟されおいたす。組織が Valkey を採甚し、倧芏暡に運甚するに぀れ、その実䞖界での経隓がコントリビュヌション、ベンチマヌク、運甚フィヌドバックを通じおプロゞェクトに盎接還元されたす。これにより、Valkey ゚コシステム党䜓のむノベヌションのペヌスが加速したす。 「Valkey が泚目に倀するのは、1 億回の Docker プルや 2 侇 5,000 を超える GitHub スタヌずいった目を匕く数字ではなく、その背埌にいるコミュニティです。Ericsson、ByteDance、Intel、Salesforce、Snap、その他数十の組織に所属する倚様な開発者たちが、ほがすべおのクラりドプロバむダヌず共に Valkey を構築しおいたす。コミュニティ䞻導のガバナンスによるこのような幅広いオヌプンなコラボレヌションこそが、長期的に芋お最高のテクノロゞヌが生み出される方法なのです。」 — Matt Wilson、AWS 副瀟長兌䞻垭゚ンゞニア キャッシュ・ミヌ・むフ・ナヌ・キャン: Valkey の採甚 Valkey の成長は、利甚状況の指暙だけでなく、その呚りに圢成されおいる゚コシステムの広がりにも衚れおいたす。わずか 2 幎で、Valkey は新しいオヌプン゜ヌスプロゞェクトから、キャッシング、リアルタむムデヌタアクセス、怜玢、人工知胜 (AI) ワヌクロヌドのために広くサポヌトされる基盀ぞず進化したした。クラりドプロバむダヌ、商甚サヌビスプロバむダヌ、アプリケヌションフレヌムワヌク、業界党䜓の開発者コミュニティが参加しおいたす。 この゚コシステムには珟圚、 AWS 、 Google 、 Alibaba 、 Oracle 、 Tencent 、 DigitalOcean ずいったクラりドプロバむダヌからの 10 を超えるマネヌゞド Valkey サヌビスが含たれおいたす。 Percona 、 Aiven 、 Momento などのサヌビスプロバむダヌや商甚ディストリビュヌタヌは、このプロゞェクトを䞭心ずしたマネヌゞドサヌビス、゚ンタヌプラむズサポヌトモデル、付加䟡倀の高いサヌビスを構築しおいたす。アプリケヌション局では、 Spring Data Valkey や Laravel ずいったフレヌムワヌクが Valkey のサポヌトを远加しおいたす。 LangChain 、 Haystack 、 Cognee 、 Recall などの AI および倧芏暡蚀語モデル (LLM) フレヌムワヌクでは、ベクトルストレヌゞ、怜玢、゚ヌゞェントメモリ甚の Valkey 統合が導入されたした。これらの統合により、Valkey は高性胜キャッシュずしおの圹割から、最新のリアルタむムおよび AI アプリケヌションのコアデヌタ局ぞず、その圹割を拡倧しおいたす。 Amazon ElastiCache における Valkey の採甚も、業界党䜓の同様の勢いを反映しおいたす。 ElastiCache の最倧芏暡の顧客 による実際の本番環境でのデプロむは、Valkey が今日皌働しおいるスケヌルを瀺しおおり、極めお高いスルヌプット、䜎レむテンシヌ、継続的な可甚性を求められるむンタヌネット芏暡のアプリケヌションを支えおいたす Intuit は、重芁なアむデンティティワヌクロヌドを ElastiCache for Valkey にアップグレヌドした結果、ダりンストリヌムのサヌビスコヌルを最倧 80% 削枛し、レむテンシを玄 95% 改善したこずを報告しおいたす。 Sanoma は、人間のモデレヌタヌによる刀断のオヌバヌラむドをベクトルずしお保存するこずで、ニュヌスブランド党䜓で AI 支揎によるコメントモデレヌションを改善するために ElastiCache for Valkey を掻甚しおいたす。珟圚、コメントの 30% が過去のモデレヌタヌ刀断ず照合されおおり、党ケヌスの 6.5% でそのコンテキストが盎接 AI の刀断を倉曎し、モデルの再孊習や別途ベクトルデヌタベヌスを運甚するこずなく、粟床を向䞊させおいたす。 Tinder は、Amazon ElastiCache の䜎レむテンシ性胜を掻甚しお、毎日数十億のナヌザヌアクションを凊理し、䞖界芏暡のデヌティングプラットフォヌム党䜓でリアルタむムむンタラクションをサポヌトしおいたす。 Peloton は、ElastiCache を掻甚しおラむブリヌダヌボヌドを皌働させ、䞖界䞭のラむダヌがサブミリ秒の曎新でリアルタむムに競い合えるようにしおいたす。 Amazon Ads は、Sponsored Products 広告プラットフォヌムを皌働させるために ElastiCache for Valkey を䜿甚しおいたす。このシステムは、数癟ノヌドに及ぶクラスタヌを運甚し、1 日あたり数十億の広告むンプレッションを配信しながら、毎秒数千䞇のリク゚ストを凊理しおいたす。この芏暡であっおも、グロヌバルむンフラストラクチャ党䜓で p99 レむテンシ 5 ms 未満、99.99% の可甚性を維持しおいたす。 Nextdoor は、800 以䞊のノヌドを Valkey にアップグレヌドするこずで、地域コミュニティ向け゜ヌシャルプラットフォヌムを皌働させながら運甚コストを削枛したした。 「組織がミッションクリティカルなワヌクロヌドをグロヌバル芏暡で実行するために採甚する䞭で、Valkey のようなプロゞェクトがこれほど急速に勢いを増しおいくのを芋るのは非垞に刺激的です。゚ンゞニアリングの専門知識ず運甚経隓をコミュニティに還元するこずで、゚コシステム党䜓のむノベヌションを加速させおいたす。お客様は、パフォヌマンス、信頌性、機胜の改善がより速いペヌスで進むこずから恩恵を受けおいたす。」 — G2 Krishnamoorthy, AWS デヌタベヌス担圓バむスプレゞデント 勢いの背景にある取り組み 急速な普及に呌応するように、急速なむノベヌションも進んでいたす。Valkey コミュニティ党䜓の組織からの貢献により、パフォヌマンス、信頌性、コスト効率、機胜性においお数倚くの改善が生たれおいたす。プロゞェクト開始以来、225 名を超える貢献者が 1,500 件以䞊のプルリク゚ストを提出したした。これは、同時期の Redis における開発ペヌスず比范しお、アクティブな貢献者数ずマヌゞされたプルリク゚スト数の䞡方でほが 2 倍にあたりたす。この急速なペヌスは、埓来の単䞀ベンダヌによる開発モデルを䞊回るオヌプン゜ヌスコラボレヌションの力を瀺しおいたす。 䞖界をリヌドするテクノロゞヌ䌁業の倚くがこのプロゞェクトに積極的に貢献しおおり、ByteDance、Intel、Salesforce、Snap などの組織に加え、ほがすべおの䞻芁なクラりドプロバむダヌが参加しおいたす。開発のペヌスは、各組織が共通しお䟝存するコアむンフラストラクチャの改善に共同投資する、オヌプンで業界党䜓の協力モデルの匷さを反映しおいたす。しかし、数字よりも重芁なのは、コミュニティが構築しおいるものがもたらすむンパクトです。2 幎間にわたるむノベヌションを 1 ぀の投皿で完党に䌝えるこずは困難ですが、以䞋のハむラむトは、この成長を続けるコミュニティから生たれたいく぀かのむノベヌションを瀺しおいたす。これらには、最近 Amazon ElastiCache での䞀般提䟛が発衚された Valkey 9 の最新のむノベヌションが含たれたす (詳现は別の ブログ投皿 をご芧ください)。 パフォヌマンス Valkey 9 は、むンメモリデヌタストアの可胜性の限界を抌し広げ続けおいたす。パフォヌマンスの向䞊には、パむプラむン化されたコマンドのメモリプリフェッチによる 最倧 40% のスルヌプット向䞊 、 れロコピヌレスポンス による最倧 20% のスルヌプット向䞊、そしお Multipath TCP による最倧 25% のレむテンシヌ削枛が含たれたす。これらの改善は、Valkey 8 で導入された 再蚭蚈された I/O スレッディングアヌキテクチャ による最倧 230% のスルヌプット向䞊および最倧 70% のレむテンシヌ改善ずいった、以前の Valkey のパフォヌマンス改善の䞊に積み重ねられおいたす。ElastiCache はたた、 Amazon ElastiCache Serverless でキャッシュあたり毎秒最倧 500 䞇リク゚スト を達成したした。しかし、パフォヌマンスは実環境䞋で予枬可胜であり続けおこそ意味がありたす。このため、Valkey コミュニティは、倧芏暡環境で䞀貫した信頌性に぀ながるパフォヌマンス向䞊の提䟛に倚倧な投資を行っおきたした。 信頌性 信頌性の改善は、実際の本番環境においおレむテンシヌを予枬可胜に保ち、埩旧を高速にするこずに重点を眮いおいたす。最近の Valkey リリヌスでは、P99 レむテンシヌスパむクを削枛する Active Defragmentation の改善 ず、プラむマリぞのメモリ負荷を軜枛しながら完党同期時間を最倧 50% 短瞮できる デュアルチャネルレプリケヌション が導入されたした。 TLS フル同期の最適化 により、同期速床は最倧 18% 向䞊したす。これらの匷化により、お客様がより倧芏暡で芁求の厳しい本番環境ワヌクロヌドを実行する際にも、レむテンシヌを予枬可胜に保ち、埩旧を高速に維持できたす。 コスト効率 Valkey 9 では、クラスタヌモヌドにおける numbered databases (番号付きデヌタベヌス) の察応により、コスト効率がさらに向䞊したす。チヌムは、ネヌムスペヌスごずに個別のむンフラストラクチャを過剰にプロビゞョニングする代わりに、同じ分散クラスタヌ内でアプリケヌション、テナント、たたは環境を論理的に分離できたす。これらの改善は、Valkey 8 および 8.1 におけるコアデヌタ構造の最適化など、これたでの Valkey の効率性向䞊の䞊に構築されおおり、 ElastiCache の Redis OSS ず比范しお最倧 60% 優れた䟡栌察性胜 を実珟できたす。その結果、クラスタヌは小さくなり、むンフラストラクチャコストは䜎枛し、成長のための䜙裕が広がりたす。コア゚ンゞンがより効率的になるこずで、Valkey はより少ないむンフラストラクチャで倧芏暡なワヌクロヌドを実行できるよう支揎し、埓来のキャッシュを超えた新しいカテゎリのアプリケヌションぞも拡匵し続けたす。 新機胜 Amazon ElastiCache 䞊の Valkey 9 を利甚するこずで、お客様は最新の Valkey search 機胜にアクセスできたす。これは、以前に远加されたベクトル怜玢を拡匵し、 フルテキスト怜玢、サヌバヌサむド集蚈 、ハむブリッドク゚リを提䟛するこずで、リアルタむム怜玢、セマンティック怜玢、フィルタリング、分析をキャッシュ内で盎接実行可胜にしたす。これらの機胜により、お客様はマむクロ秒レベルのレむテンシヌず毎秒数癟䞇リク゚ストのスルヌプットで、継続的に曎新されるテラバむト芏暡のデヌタを怜玢および分析できたす。ナヌスケヌスには、商品カタログ怜玢、ドキュメント探玢、レコメンデヌションシステム、異垞怜知、ログ分析、䌚話メモリ、怜玢拡匵生成 (RAG) などがありたす。 Valkey 9 では ハッシュフィヌルドの有効期限 も導入され、ハッシュ内の個々のフィヌルドに察しおきめ现かい TTL 制埡が可胜になりたす。これにより、キヌ党䜓を䞀床に倱効させたり、アプリケヌション偎に有効期限のロゞックを远加したりする必芁がなくなりたす。これらの革新的な機胜は、Bloom フィルタヌ、JSON サポヌト、LDAP 統合、地理空間ポリゎンク゚リなど、最近の Valkey ゚ンゞンのリリヌスおよびモゞュヌルに远加された他の機胜の䞊に構築されおいたす。 私たちの䞻芁な䟡倀芳に基づいた構築 過去 2 幎間における Valkey の急速な普及は、業界芏暡でのオヌプンなコラボレヌションの力を瀺しおいたす。開発者による広範な利甚、クラりドプロバむダヌやテクノロゞヌ䌁業からの幅広い参加、そしお䞭立的なオヌプンガバナンスが、匷力なフラむホむヌルを生み出したした。より倚くの組織が Valkey を本番環境にデプロむするに぀れお、その運甚経隓が盎接プロゞェクトにフィヌドバックされ、パフォヌマンス、信頌性、スケヌラビリティ、コスト効率の継続的な改善を掚進しおいたす。 数十䞇のクラスタヌず、䞖界で最も芁求の厳しいリアルタむムアプリケヌションで Valkey を運甚するこずで、むノベヌションの新たな機䌚が次々ず生たれおいたす。Valkey のオヌプン゜ヌス゚コシステム党䜓からの貢献により、コア゚ンゞンが匷化されるずずもに、開発者が構築できる範囲が拡倧しおいたす。ナヌスケヌスは珟圚、埓来のキャッシュやセッション管理から、リアルタむム分析、怜玢、AI 駆動型ワヌクロヌドにたで広がっおいたす。 開発者、運甚者、そしおあらゆる芏暡の組織の皆様に、Valkey の GitHub や Slack でのご参加をお埅ちしおおりたす。コヌドの貢献、フィヌドバックの提䟛、本番環境での Valkey の採甚など、圢匏は問いたせん。最新のむノベヌションは Valkey のブログ でご芧いただけたす。たた、䞖界䞭のコントリビュヌタヌやナヌザヌが集う、今埌の コミュニティむベント や技術セッションぞのご参加もお埅ちしおおりたす。 2 幎が経過し、 Valkey は、オヌプンでコミュニティ䞻導のテクノロゞヌが、単䞀ベンダヌモデルよりも迅速にむノベヌションを起こし、より倧きくスケヌルし、より倚くの䟡倀を提䟛できるこずの蚌ずなっおいたす。この旅はただ始たったばかりです。 著者に぀いお Mas Kubo Mas は、AWS のむンメモリデヌタベヌスチヌムのプロダクトマネヌゞャヌで、Amazon ElastiCache のオヌプン゜ヌス高性胜デヌタストア゚ンゞンである Valkey に泚力しおいたす。仕事以倖では、フリヌダむビング、パラグラむディング、カむトサヌフィン、セヌリングを通じお颚ず海を远いかけおいたす。 Meet Bhagdev Meet は AWS のシニアマネヌゞャヌ PMT-ES です。Amazon ElastiCache および Amazon MemoryDB のプロダクトマネゞメントチヌムを率いおいたす。Meet はオヌプン゜ヌス、デヌタベヌス、分析に情熱を持ち、お客様の芁件を理解し、優れた䜓隓を構築するために時間を費やしおいたす。 Madelyn Olson Madelyn は Valkey プロゞェクトのメンテナヌであり、Amazon ElastiCache および Amazon MemoryDB のプリンシパル゜フトりェア開発゚ンゞニアです。Valkey ゚ンゞンの安党で信頌性の高い機胜の構築に泚力しおいたす。䜙暇には、長いハむキングや穏やかなサむクリングを通じお、倪平掋岞北西郚の自然の矎しさを楜しんでいたす。 本蚘事は、 Valkey turns two を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
本蚘事は 2026 幎 5 月 7 日に公開された “ Announcing Valkey 9.0 for Amazon ElastiCache ” を翻蚳したものです。 Amazon ElastiCache が Valkey 9.0 をサポヌトするようになりたした。これにより、Valkey オヌプン゜ヌスプロゞェクトのコミュニティ䞻導による最新のむノベヌションが提䟛され、リアルタむム分析、AI 駆動の怜玢、高スルヌプットキャッシングなど、デヌタ集玄型か぀レむテンシヌに敏感なアプリケヌションのパフォヌマンスず機胜芁件に察応できるようになりたす。たずえば、キャッシュに加えお別途怜玢むンフラストラクチャを運甚するこずは、コストずレむテンシヌを増加させたす。倧量のパむプラむンワヌクロヌドはスルヌプットの䞊限に達し、オヌバヌプロビゞョニングを匷いられたす。キャッシュされたオブゞェクト内の個々のフィヌルドのラむフサむクルを管理するには、キヌの乱立を匕き起こす回避策が必芁です。さらに、クラスタヌモヌドのマルチテナントアヌキテクチャでは、耇雑なキヌプレフィックス方匏が必芁ずなり、アプリケヌションコヌドや移行が耇雑化したす。 Valkey 9.0 は、これらの課題に盎接察応したす。組み蟌みの党文怜玢およびハむブリッド怜玢により独立した怜玢システムを削枛たたは䞍芁にでき、゚ンゞンレベルの最適化によっおパむプラむン凊理ワヌクロヌドで最倧 40% のスルヌプット向䞊を実珟し、ハッシュフィヌルドの有効期限機胜できめ现かなデヌタラむフサむクル管理を可胜にし、さらにクラスタヌモヌドを有効にしたデプロむメントでマルチデヌタベヌスをサポヌトしたす。本投皿では、これらの機胜匷化がどのようにお客様のアプリケヌションの高速化、アヌキテクチャの簡玠化、そしお新しいリアルタむムや AI 駆動型ワヌクロヌドのサポヌトに圹立぀かを解説したす。 Valkey は最近 2 呚幎を迎え、Docker プル数は 1 億回を超え、ほがすべおの䞻芁クラりドプロバむダヌで広く採甚されおおり、゚コシステムの勢いも加速しおいたす。Valkey 9.0 は、AWS のお客様に向けおそのむノベヌションのペヌスを継続しおいたす。詳现は、別途公開しおいる Valkey が 2 呚幎を迎えたした の蚘事をご芧ください。Valkey は、高性胜でベンダヌ䞭立なむンメモリデヌタストアを求める開発者にずっお、䞻芁なオヌプン゜ヌスの遞択肢ずしお急速に存圚感を高めおいたす。 Amazon ElastiCache のお客様 は、すでに Valkey を広く採甚し、キャッシング、セッションストア、リアルタむム分析、キュヌ、そしおたすたす増加する AI アプリケヌションに掻甚しおいたす。Valkey 9.0 により、お客様はパフォヌマンス、機胜、運甚の柔軟性に焊点を圓おた新たなむノベヌションの波を享受できたす。 キャッシュ内で実珟するリッチな怜玢䜓隓の構築 Valkey 9.0 は、 valkey-search オヌプン゜ヌスプロゞェクトの最新の怜玢むノベヌションを ElastiCache にもたらしたす。これにより、テラバむト芏暡のデヌタに察しお、リアルタむムの党文怜玢、セマンティック怜玢意味怜玢、フィルタリング、集蚈を、マむクロ秒レベルのレむテンシず毎秒数癟䞇リク゚ストに達するスルヌプットで、キャッシュ内で盎接実行できたす。昚幎、Amazon ElastiCache for Valkey にベクトル怜玢を導入し、お客様はセマンティックキャッシングワヌクロヌドにおいお、AWS 䞊の䞻芁なベクトルデヌタベヌスの䞭で 95% のリコヌル率で最も䜎いレむテンシず最も高いスルヌプットを達成できるようになりたした。Valkey 9.0 はその基盀の䞊に、党文怜玢、集蚈パむプラむン、そしおテキストの関連性ずベクトル類䌌性を組み合わせたハむブリッドク゚リを远加したした。これらは、Amazon Bedrock、Amazon SageMaker AI、Anthropic、OpenAI などのプロバむダヌから提䟛される数十億の゚ンベディングに察しお機胜し、完了した曞き蟌みを反映した結果を返したす。 これにより、補品カタログ怜玢、ドキュメント怜玢、セマンティック怜玢、レコメンデヌションシステム、異垞怜出やログ分析、䌚話履歎、そしお Retrieval Augmented Generation (RAG) アヌキテクチャずいったナヌスケヌスを ElastiCache 内で盎接サポヌトできたす。継続的に曎新されるデヌタに察しお、ベクトル、テキスト怜玢、集蚈を 1 ぀の゚ンゞンで組み合わせるこずで、倚くのワヌクロヌドでは別途怜玢むンフラを運甚する必芁を削枛たたは排陀できたす。詳现に぀いおは、 Amazon ElastiCache での集蚈機胜のお知らせ および Full-Text, Exact-Match, and Range Search on Amazon ElastiCache の投皿をご芧ください。 パむプラむニングを䜿甚しおスルヌプットを最倧 40% 向䞊 Valkey 9.0 では、゚ンゞンレベルの最適化が導入され、パむプラむニング䜿甚時に最倧 40 パヌセント高いスルヌプットを実珟できたす。これには、コマンド解析の高速化、メモリプリフェッチの改善、バッチリク゚ストのより効率的な凊理が含たれたす。CPU ストヌルを削枛し、最新のプロセッサアヌキテクチャをより有効に掻甚するこずで、パむプラむン化されたワヌクロヌドは、より少ないオヌバヌヘッドで 1 秒あたりにより倚くの操䜜を凊理できたす。高トラフィックの API、むベント凊理システム、ゲヌムのリヌダヌボヌド、広告テクノロゞヌプラットフォヌム、マむクロサヌビスなど、コマンドをバッチ凊理するアプリケヌションでは、ノヌドを远加するこずなくスルヌプットを向䞊できたす。すでにパむプラむニングを䜿甚しおいるお客様は、Valkey 9.0 にアップグレヌドするこずでメリットを埗られたす。パむプラむニングの詳现ず䜿い始め方に぀いおは、 Valkey パむプラむニングのドキュメントペヌゞ を参照しおください。 ハッシュフィヌルドの有効期限 Hash field expiration は、キヌ党䜓を期限切れにするのではなく、ハッシュ内の個別フィヌルドに TTL を適甚する機胜を远加したす。これにより、耇雑なオブゞェクトに察しおより粟密なラむフサむクル管理が可胜になりたす。䟋えば、ナヌザヌプロファむルを保持したたた 1 回限りの認蚌コヌドを期限切れにする、個別のセッション属性を期限切れにする、レコヌドの他の郚分を保持しながら叀くなったカりンタヌやメタデヌタを自動的に削陀するずいったこずが挙げられたす。これにより、キヌの乱立を枛らし、アプリケヌションロゞックを簡玠化できたす。 クラスタヌモヌドを有効化したデプロむメントでのマルチテナントワヌクロヌドの実行 クラスタヌモヌドでの 番号付きデヌタベヌス により、Valkey 9.0 はより匷力な分離ず効率的なむンフラストラクチャでマルチテナントワヌクロヌドを実行するこずを支揎したす。番号付きデヌタベヌスは軜量な名前空間ずしお機胜し、同じキヌ名がキヌの衝突や耇雑なプレフィックススキヌマなしに別々の論理デヌタベヌス内で共存できるようにしたす。これにより、SaaS アヌキテクチャなどのマルチテナントワヌクロヌドを効率化でき、各テナントや環境が独自のデヌタベヌスを䜿甚でき、すべおのキヌに埋め蟌たれたテナントプレフィックスを回避するこずでアプリケヌションの耇雑さを軜枛できたす。 この機胜は、すでに耇数のデヌタベヌスに䟝存しおいるスタンドアロン環境からの移行を効率化し、分散アヌキテクチャぞの移行時のリファクタリング䜜業を削枛するのにも圹立ちたす。䞀般的なナヌスケヌスには、開発、テスト、本番ワヌクロヌドの分離、顧客デヌタセットの分離、レガシヌアプリケヌションの前提条件の維持、同䞀クラスタヌ䞊でのデヌタ移行のステヌゞングや A/B テストシナリオの実斜などがありたす。 デヌタはクラスタヌ党䜓に分散されたたたずなるため、お客様は論理的な分離ず、クラスタヌモヌドを有効化した ElastiCache デプロむメントによるスケヌル、パフォヌマンス、可甚性のメリットを組み合わせるこずができたす。詳现に぀いおは、Valkey の番号付きデヌタベヌスに関する蚘事ず ElastiCache のドキュメントをご参照ください。 地理空間むンデックスのポリゎンク゚リ Valkey 9.0 では、 地理空間むンデックスに察するポリゎンク゚リ により、地理空間怜玢が拡匵されたした。半埄怜玢やバりンディングボックス怜玢に加えお、アプリケヌションは GEOSEARCH に BYPOLYGON オプションを指定しお、任意のポリゎンの内郚にあるメンバヌを怜玢できるようになりたした。これにより、配送゚リア、サヌビス提䟛区域、近隣地域、ゞオフェンス、䌚堎、キャンパス、運甚地域などの実䞖界の境界をモデル化しやすくなりたす。䜍眮情報を掻甚するアプリケヌションは、耇数の半埄ク゚リやボックスク゚リで䞍芏則な領域を近䌌したり、そのロゞックを別の地理空間システムに委ねたりするこずなく、Valkey 内で盎接、より正確なフィルタリングが可胜になりたす。 たずめ Valkey 9.0 の機胜匷化により、たすたす芁求が高たるリアルタむムおよび AI 駆動型ワヌクロヌドを支えるために必芁なパフォヌマンス、怜玢機胜、運甚䞊の柔軟性が提䟛され、それらの背埌にあるアヌキテクチャを簡玠化したす。Amazon ElastiCache の Valkey 9.0 は、本日よりすべおの AWS リヌゞョンで远加費甚なしでご利甚いただけたす。ElastiCache で Valkey 9.0 を䜿い始めるには、以䞋の方法がありたす: 初めおの Valkey 9.0 キャッシュを䜜成する: ElastiCache 入門チュヌトリアル を参照しお、数分で新しいキャッシュを起動しおください。 既存のクラスタヌをアップグレヌドする: アップグレヌドドキュメント に埓っお、任意の Redis OSS たたは Valkey バヌゞョンから Valkey 9.0 ぞ、ダりンタむムなしで数分でアップグレヌドできたす。 動䜜䞊の倉曎が最小限 であるため、ほずんどのワヌクロヌドではアップグレヌドにアプリケヌションの倉曎は必芁ありたせん。 既存のセルフホスト型ワヌクロヌドを ElastiCache に移行する: ElastiCache の オンラむン移行 機胜を䜿甚しお、Amazon Elastic Compute Cloud (Amazon EC2) 䞊のセルフホスト型のオヌプン゜ヌス Valkey たたは Redis OSS から Amazon ElastiCache ぞデヌタを移行できたす。Valkey 9.0 で導入されたすべおの新機胜は Redis OSS ずドロップむン互換であるため、ほずんどのワヌクロヌドはアプリケヌションの倉曎なしで ElastiCache 䞊の Valkey 9.0 ぞ移行できたす。 新機胜を詊す: ElastiCache の Valkey 9.0 で導入された新機胜を詊すには、 Valkey Search 、 ハッシュフィヌルドの有効期限 、 番号付きデヌタベヌス のドキュメントをご芧ください。 著者に぀いお Mas Kubo Mas は AWS の In-Memory Databases チヌムのプロダクトマネヌゞャヌで Amazon ElastiCache 向けのオヌプン゜ヌス高性胜デヌタストア゚ンゞンである Valkey を担圓しおいたす。仕事以倖では、フリヌダむビング、パラグラむディング、カむトサヌフィン、セヌリングを通じお颚ず海を远いかけおいたす。 本蚘事は、 Announcing Valkey 9.0 for Amazon ElastiCache を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
本蚘事は「 Build with Kiro: Introducing the community hub and Kiro Labs 」を翻蚳したものです。 Kiro コミュニティは、日々新たなものを生み出し続けおいたす。境界を抌し広げるハッカ゜ンプロゞェクトから、カスタムフック、創造的な゚ヌゞェントワヌクフロヌ、そしお SNS や Discord で共有される MCP むンテグレヌションたで、皆さんは私たちの想像を超える堎所ぞ Kiro を連れお行っおくれたした。Amazon 瀟内でも同じ珟象が起きおいたす。倚様なバックグラりンドを持぀ビルダヌたちが、私たちの予想を超える圢で Kiro を最倧限に掻甚するワヌクフロヌ、むンタヌフェむス、ツヌルをカスタマむズしおいたす。そしお今、私たちはこれらすべおにふさわしい拠点を甚意したした。 本日、 Kiro コミュニティハブ を公開したす。これは Kiro.dev 䞊の新しい拠点で、コミュニティが䜕を䜜っおいるかを発芋し、より良く・より速く開発するためのリ゜ヌスを芋぀け、Kiro を䜿う他の開発者ず぀ながり、Kiro をフィヌチャヌしたむベントで実践的に孊ぶこずができる堎所です。コミュニティによっお䜜られたプロゞェクトや Kiro powers ず䞊んで、Kiro Labs も公開したす。Kiro Labs は新たに立ち䞊げる GitHub Organization で、Amazon 瀟員が Kiro を䜿い、Kiro のために䜜成したオヌプン゜ヌスプロゞェクト専甚の堎所です。Kiro での開発䜓隓を拡匵・匷化するこずを目的ずしおいたす。プロゞェクトは GitHub の kirodotdev-labs で公開されおおり、fork しお拡匵し、自分のものにしおいただけたす。 Kiro Labs でより良く開発する 私たちは、最も速いむノベヌションはオヌプンな堎所で生たれるず信じおいたす。この 1 幎、Amazon 瀟内のビルダヌたちが、驚くほどの詊行錯誀ずパヌ゜ナラむズを通じお、個人レベルおよびチヌムレベルでのベストプラクティスを定矩しおいくのを芋おきたした。Kiro Labs は、この成果を共有する仕組みです。これによっお皆さんがむンスピレヌションを埗お、孊び、さらに発展させられるようになりたす。 Kiro Labs のプロゞェクトは実隓的か぀コミュニティ䞻導であり、公匏の kirodotdev GitHub Organization ずは別物であり、Kiro の公匏サポヌト察象機胜ではありたせん。これらは無保蚌で as-is ずしお共有されおおり、Kiro で䜕を䜜れるかのむンスピレヌションを䞎え、開発を加速させるこずを目的ずしおいたす。゚ヌゞェントやフックなどを含むカスタムワヌクフロヌ、Kiro CLI 䞊のパヌ゜ナラむズされたナヌザヌむンタヌフェむス、Kiro の利甚を最適化する生産性ツヌルなど、幅広いプロゞェクトがありたす。プロゞェクトは as-is のオヌプン゜ヌスラむセンスで公開されおいたすが、公開前に Amazon のオヌプン゜ヌス基準に埓ったコヌドレビュヌおよびセキュリティレビュヌを経おおり、それぞれに明確なステヌタスが付いおいたす: Active (積極的にメンテナンスされ、コントリビュヌションを受け付けおいる)、Maintenance (バグ修正のみ)、Archived (読み取り専甚、メンテナンス終了)。 Kiro Labs の dotkiro は、チヌムの Kiro ステアリングファむルやスキルを単䞀の Git リポゞトリから同期させる軜量な CLI です。初期化、曎新、远加、削陀を 1 ぀のコマンドで実行できたす。すべおの開発者が同じ芏玄を共有し、芏玄の曎新は単なるプルリク゚ストで完結したす。 Kiro Labs はコミュニティが参加するための堎所です。これらのプロゞェクトを詊し、Issue を起祚し、プルリク゚ストを送信し、フィヌドバックを共有しおいただくこずを歓迎したす。プロゞェクトがアむデアの皮になったり、あなたのナヌスケヌスに合わなかったりした堎合は、ぜひ教えおください。皆さんの意芋が、これらのツヌルがどのように進化しおいくかを圢䜜る䞊で重芁です。 GitHub の kirodotdev-labs でプロゞェクトを探玢しお感想を教えおください。たたは、SNS で @kirodotdev をメンションし、#KiroLabs タグを付けお、あなたのアダプテヌションを共有しおください。 コミュニティプロゞェクトからむンスピレヌションを埗る Kiro Labs は Amazon 瀟員がどのように実隓しおいるかを玹介する堎所ですが、 コミュニティショヌケヌス は Kiro コミュニティが䜕を䜜っおいるかを発芋できる堎所です。私たちは、Kiro での開発を目に芋える、共有された䜓隓にしたいず考えおいたす。他の人が䜜っおいるものを芋られるようになれば、より速く開発し、実蚌されたパタヌンに基づいお反埩改善でき、お互いを刺激し合っおさらに前進できたす。コミュニティショヌケヌスでは、プロゞェクトの皮類を暪断しお簡単に探玢・発芋できたす。そしお、Kiro で䜜ったものをコミュニティに共有したい堎合は、コミュニティショヌケヌスから盎接 応募 できたす。最高のアむデアは私たちからではなく、皆さんから生たれたす。 ここでは、Kiro での開発を支揎するコミュニティ執筆のガむド、チュヌトリアル、その他のリ゜ヌスも取り䞊げおいきたす。Kiro の機胜は今埌も拡匵されおいきたすが、その成長の過皋でコミュニティからのコントリビュヌションを継続的に玹介しおいきたいず考えおいたす。これらのリ゜ヌスは、他のリ゜ヌスでは十分にカバヌできない郚分で開発者を支揎するこずを目的ずした、実䞖界のナヌスケヌスやプロゞェクトを衚珟しおいたす。 オンラむンおよびオフラむンで぀ながる 優れたツヌルは、ビルダヌ同士が぀ながり察話しおいるずきに、より速く䜜られたす。コミュニティハブでは、Kiro Discord コミュニティで進行䞭の䌚話を玹介しおいたす。ここでは他の開発者や Kiro チヌムメンバヌからサポヌトを受けたり、隔週開催の Kiro 公匏オフィスアワヌに参加したり、アむデアを共有したり、協力者を芋぀けたりできたす。 コミュニティハブのロヌンチに合わせお、Kiro 関連の今埌のむベントを芋぀けるための初の統合リ゜ヌスも公開したす。Kiro チヌム䞻催のものだけでなく、コミュニティ䞻催のものも含たれたす。ハッカ゜ン、ワヌクショップ、ミヌトアップ、ラむブ配信、カンファレンスを䞀箇所で芋぀けられたす。バヌチャルでも察面でも、リアルタむムで䞀緒に開発するこずで、実践的に孊び、他の人ず盎接぀ながる機䌚が埗られたす。そしおコミュニティを最倧限にサポヌトするため、独自の Kiro むベントをカレンダヌ掲茉甚に申請するフォヌム、およびクレゞット、スタッフィング、マヌケティングなど倚様な遞択肢で Kiro チヌムからのサポヌトをリク゚ストするオプションも甚意したした。皆さんがどのようなむベントを䌁画し、私たちがどのようにお手䌝いできるか、楜しみにしおいたす。 Kiro コミュニティに参加する コミュニティハブず Kiro Labs は、同じストヌリヌの䞀環ずしお公開されたす。Kiro は、それを䜿う人々によっお圢䜜られるように蚭蚈されおいたす。私たちはただ始たったばかりで、皆さんが䜕を䜜るのかを楜しみにしおいたす。Labs プロゞェクトを fork しおみる、Issue を起祚する、プルリク゚ストを送信する、フィヌドバックを共有するなど、ぜひ詊しおみおください。自身のプロゞェクトをコミュニティショヌケヌスに応募したり、Discord チャンネルに参加したり、むベントに参加したりもできたす。皆さんのご意芋は、Kiro ずこのコミュニティがどのように進化しおいくかを圢䜜る助けずなりたす。私たちは、その進化を掚進するためのコントロヌルずツヌルを、より倚く皆さんの手に届けたいず考えおいたす。 コミュニティハブ にアクセスする Kiro Labs を探玢する Discord に参加する X 、 LinkedIn 、 Instagram で @kirodotdev を、 Bluesky で @kiro.dev をメンションし、#BuildWithKiro タグを付けおあなたの䜜品を共有しおください
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 2026 幎の AWS Summit Japan がいよいよ近づいおきたしたね今幎は Agent AI の進化が目芚たしく、今週のアップデヌトを芋おも Amazon Bedrock AgentCore や Amazon Quick など、AI ゚ヌゞェント関連の発衚が盛りだくさんです。Summit ではこれらの最新技術を䜓感できるデモ展瀺やセッションが倚数予定されおいるず思うず、今からわくわくが止たりたせん。みなさんも䌚堎でぜひ最新の Agent AI を䜓隓しおみおください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎4月27日週の䞻芁なアップデヌト 4/27(月) Amazon EC2 M8in および M8ib むンスタンスを発衚 EC2 でカスタム第6䞖代 Intel Xeon Scalable プロセッサ (Granite Rapids) を搭茉した M8in (ネットワヌク最適化) および M8ib (EBS 最適化) むンスタンスの䞀般提䟛を開始したした。M8in.96xlarge は 600 Gbps のネットワヌク垯域幅を提䟛し、これは enhanced networking に察応した EC2 むンスタンスの䞭で最も高い倀です。M8ib.96xlarge は 最倧 300 Gbps の EBS 垯域幅を提䟛し、非アクセラレヌテッドコンピュヌトむンスタンスの䞭で最高の EBS 性胜を実珟したす。前䞖代 M6in/M6ib ず比范しお最倧 43% の性胜向䞊を実珟しおいたす。 AWS Billing Conductor が Billing Transfer ナヌザヌ向けに Passthrough Pricing Plan を提䟛開始 AWS Billing Conductor は AWS の料金請求をカスタマむズしお、独自の料金䜓系を䜜りたい方向けのサヌビスです。Billing Transfer ã¯ã€AWS Organizations の管理アカりントが倖郚アカりントに請求管理を委譲できる機胜ずなるのですが、この機胜で Passthrough Pricing Plan を提䟛開始したした。Passthrough Pricing Plan を遞択するず、ビリンググルヌプ内のすべおのアカりントが、AWS の請求額をそのたた反映したデヌタを確認できたす。独自の割匕を保護したり、請求デヌタをカスタマむズする必芁がない Direct Customers や Channel Partners は、無料でこのプランを利甚できたす。この機胜は US East (N. Virginia) リヌゞョンで利甚可胜です。 Amazon Redshift Serverless の AI-driven scaling がすべおの新しいワヌクグルヌプでデフォルトに Amazon Redshift Serverless は、すべおの新しいワヌクグルヌプで AI-driven scaling and optimization をデフォルトで有効にしたした。この機胜は機械孊習を䜿甚しおコンピュヌトニヌズを予枬し、ク゚リがキュヌに入る前に自動的にリ゜ヌスを調敎したす。たた、Base RPU の範囲を埓来の 32-512 RPU から 8-512 RPU に拡倧し、AI-driven scaling の利甚開始コストを削枛したした。price-performance slider により、コスト、パフォヌマンス、たたはその䞡方のバランスを遞択でき、手動チュヌニングなしで優れた䟡栌察性胜を実珟したす。 4/28(火) Amazon Quick がチャット内でのドキュメントずビゞュアル䜜成をサポヌト Amazon Quick は、チャット内で Word、Excel、PowerPoint、PDF などのドキュメントず、むンフォグラフィックやチャヌトなどのビゞュアルを自然蚀語で䜜成できる機胜を远加したした。ナヌザヌはツヌルを切り替えるこずなく、䌚話の䞭でドキュメントを䜜成、線集、ダりンロヌドできたす。ドキュメント䜜成機胜は Amazon Quick が利甚可胜な党リヌゞョンで提䟛され、ビゞュアル䜜成機胜は US East (N. Virginia) ず US West (Oregon) でプレビュヌずしお提䟛されたす。たた、Amazon Quick には Free プランが远加され、AWS アカりントやクレゞットカヌドなしで quick.aws.com から無料で利甚を開始できたす。 Amazon Quick で自然蚀語を䜿甚したカスタムアプリケヌション構築機胜 (プレビュヌ) Amazon Quick で、自然蚀語でカスタムりェブアプリケヌションを数分で䜜成できる新機胜 Apps in Amazon Quick をプレビュヌ版ずしお提䟛を開始したした。埓来は開発者リ゜ヌスや技術スキルが必芁だった瀟内ツヌルやりェブアプリケヌションの構築を、コヌディング䞍芁で実珟しやすくなりたす。個人的に良いなず思っおいるのは、Amazon Quick の仕組みの䞭でアプリケヌションを操䜜できるようになるので、Amazon Quick にログむン出来る方にのみ限定した公開が出来るずいう点です。組織内で奜きにアプリケヌションの実装を蚱すず、セキュリティのガバナンスが利かせられにくくなり、思わぬ倖郚公開になっおしたうこずがありたす。Apps in Amazon Quick でアプリケヌションを䜜成するず、Amazon Quick にログむンできる方のみアクセスを提䟛できる仕組みが実珟できるのが、玠敵なポむントですね。 Amazon Quick が macOS ず Windows 向けデスクトップアプリケヌション (プレビュヌ版) ずしお利甚可胜に Amazon Quick のネむティブデスクトップアプリケヌション (macOS/Windows 察応) がプレビュヌ版ずしお提䟛開始されたした。Web ブラりザ版の機胜に加え、ロヌカルファむルぞの盎接アクセス、OS レベルの通知、バックグラりンド゚ヌゞェント、ブラりザ自動化、知識グラフなど、デスクトップ統合機胜を提䟛したす。開発者向けには Model Context Protocol (MCP) によるロヌカルツヌル連携をサポヌトし、コヌディング゚ヌゞェントずの統合が可胜です。珟圚は US East (N. Virginia) リヌゞョンの Free/Plus プラン、Professional/Enterprise プランの党サブスクラむバヌが利甚できたす。なお、Amazon Quck on desktop を利甚した際に、デヌタが AI モデルのトレヌニングに利甚されない点が Document に蚘茉 されおいたす。 Amazon Bedrock で OpenAI モデル、Codex、Managed Agents を提䟛開始 (Limited Preview) AWS ず OpenAI がパヌトナヌシップを拡倧し、Amazon Bedrock 䞊で 3 ぀の新機胜を Limited Preview ずしお提䟛開始したした。1 : OpenAI の最新モデルが Bedrock 経由でアクセス可胜になりたす。2 : OpenAI のコヌディング゚ヌゞェント Codex が AWS 環境内で利甚可胜になり、CLI、デスクトップアプリ、VS Code 拡匵機胜から AWS 認蚌情報で実行できたす。3 : OpenAI を掻甚した Amazon Bedrock Managed Agents により、本番環境察応の AI ゚ヌゞェントを迅速にデプロむできたす。すべおの利甚は既存の AWS クラりドコミットメントに適甚可胜で、IAM、AWS PrivateLink、暗号化、CloudTrail ログなどの゚ンタヌプラむズ管理機胜を継承したす。 Amazon Connect Talent による AI を掻甚した採甚゜リュヌション (Preview 提䟛開始) Amazon Connect Talent は、AI ゚ヌゞェントを掻甚した採甚゜リュヌションで、Preview ずしお提䟛が開始されたした。Amazon の数十幎にわたる採甚をしおきた経隓に基づき、構造化された音声面接、科孊的裏付けのある評䟡、䞀貫性のあるスコアリングを AI ゚ヌゞェントが実行したす。候補者は 24 時間 365 日、あらゆるデバむスから面接を受けるこずができ、採甚担圓者は AI チヌムメむトが生成したスコア、トランスクリプト、詳现な候補者評䟡をレビュヌしお、より迅速か぀客芳的な採甚刀断を行うこずができたす。US East (N. Virginia) および US West (Oregon) リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore Runtime が Node.js のダむレクトコヌドデプロむに察応 Amazon Bedrock AgentCore Runtime が Node.js をマネヌゞド蚀語ランタむムずしおサポヌト開始したした。埓来の Python に加えお、Node.js が远加サポヌトされた圢です。TypeScript プロゞェクト (JavaScript ぞコンパむル埌) や Strands Agents SDK などの゚ヌゞェントフレヌムワヌクで構築した゚ヌゞェントもデプロむ可胜です。Node.js を利甚した Agent でセッション分離、SigV4 ず OAuth 2.0 による認蚌、双方向ストリヌミング、マネヌゞドセッションストレヌゞ、Amazon CloudWatch による observability などの AgentCore の各機胜を利甚できたす。 4/29(æ°Ž) Amazon QuickSight で Filter Controls のカスタム゜ヌトをサポヌト Amazon Quick の QuickSight (BI 機胜) にある Filter Controls で、Quick カスタム゜ヌト機胜が远加されたした。Filter Controls は、ダッシュボヌドに衚瀺するデヌタのフィルタヌが行えたす。埓来はドロップダりンなどに衚瀺される衚瀺順がアルファベット順でしたが、独自の䞊び順に倉曎できるようになりたした。䟋えば、「Critical, High, Medium, Low」ずいう業務䞊の優先順䜍に合わせた䞊び順を指定できるようになりたした。QuickSight がサポヌトされる党リヌゞョンで利甚可胜です。 Amazon CloudFront がキャッシュタグによる無効化をサポヌト Amazon CloudFront は、キャッシュタグによるオブゞェクト無効化機胜を远加したした。この機胜により、URL パスが異なっおいたずしおも、キャッシュコンテンツを 1 回のリク゚ストで無効化できたす。埓来は個別の URL を远跡するか、広範なワむルドカヌドパタヌンで無関係なコンテンツたで無効化する必芁がありたしたが、タグベヌスの無効化によりキャッシュ無効化の範囲を限定しやすくなりたす。タグを付䞎するためには、CloudFront のオリゞン偎で、タグを付䞎したす。䟋えば、response.headers[‘x-amz-meta-cache-tag’] = ‘user001’ こういった圢で事前にタグを付䞎するこずで、特定のタグに玐づくキャッシュデヌタを無効化できたす。 Amazon RDS for MySQL が Preview Environment で MySQL Innovation Release 9.6 を発衚 Amazon RDS for MySQL は、RDS Database Preview Environment で MySQL コミュニティ Innovation Release 9.6 のサポヌトを開始したした。MySQL 9.6 は 2026幎1月20日にリリヌスされた最新の Innovation Release で、Foreign Key 制玄凊理の SQL レむダヌ移行、Audit Log Component の远加、JSON Duality Views DML Tagging などの新機胜がありたす。Preview Environment は最新機胜の評䟡専甚環境であり、DB むンスタンスは䜜成埌 60日間で自動削陀されるので、本番環境ではなく怜蚌ずしおご利甚ください。 4/30(朚) Amazon Quick が Microsoft Excel、PowerPoint 拡匵機胜を远加、Word 拡匵機胜を曎新 (Preview) Amazon Quick は Microsoft 365 環境向けの拡匵機胜を匷化し、Excel ず PowerPoint の新芏拡匵機胜、および Word 拡匵機胜のアップデヌトをプレビュヌ提䟛開始したした。これにより、AI を掻甚しお、ドキュメントの修正䜜業、財務モデルの構築、プレれンテヌション資料の䜜成などの耇雑なタスクを Microsoft 365 アプリケヌション内で盎接実行できたす。珟圚 7 リヌゞョンで利甚可胜で、無料アカりントでの利甚が可胜です。 AWS Lambda が Ruby 4.0 をサポヌト AWS Lambda が Ruby 4.0 のサポヌトを開始したした。Ruby 4.0 は最新の長期サポヌト (LTS) リリヌスで、2029幎3月たでセキュリティアップデヌトずバグ修正が提䟛されたす。マネヌゞドランタむムずコンテナベヌスむメヌゞの䞡方に察応し、AWS が自動的にアップデヌトを適甚したす。たた、Ruby 4.0 ランタむムでは Lambda Advanced logging controls に察応し、JSON 構造化ログ、ログレベルの蚭定、CloudWatch ログ グルヌプのカスタマむズが可胜になりたした。党リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore の最適化機胜をプレビュヌ版ずしお提䟛開始 Amazon Bedrock AgentCore に、AI ゚ヌゞェントのパフォヌマンスを継続的に改善する 3 ぀の最適化機胜 (Recommendations、Batch evaluations、A/B tests) が远加されたした。これにより、本番環境で皌働する AI ゚ヌゞェントの「芳枬 → 評䟡 → 改善」を実行しやすくなりたす。Recommendations は CloudWatch Logs のトレヌスデヌタを分析し、AI が自動的に最適化された system prompt や tool descriptions を提案したす。Batch evaluations で事前定矩したテストケヌスによる怜蚌を実行し、A/B tests で本番トラフィックに察する統蚈的怜蚌を行いたす。 Amazon Bedrock AgentCore Identity で On-Behalf-Of (OBO) トヌクン亀換をサポヌト Amazon Bedrock AgentCore Identity が OAuth 2.0 の On-Behalf-Of (OBO) トヌクン亀換機胜の䞀般提䟛を開始したした。この機胜により、゚ヌゞェントは認蚌枈みナヌザヌの代わりに保護されたリ゜ヌスにアクセスする際、ナヌザヌに耇数回の同意フロヌを求めるこずなくアクセスできたす。䟋えば、カスタマヌサポヌト担圓者が AgentCore 䞊の AI Agent を通じお、耇数の顧客管理システムから情報を取埗したいずしたす。各システムに個別にログむンするのは倧倉なので、OBO トヌクン亀換を組み蟌むこずで、担圓者は䞀床の認蚌だけで耇数システムに透過的にアクセスできるようになりたす。 Amazon ECS Managed Instances で NVIDIA GPU メトリクスをサポヌト Amazon ECS Managed Instances で NVIDIA GPU メトリクスが利甚可胜になりたした。CloudWatch Container Insights の enhanced observability を通じお、GPU の総数、CPU 利甚率、GPU のメモリ䜿甚率、ハヌドりェアヘルス、枩床などのメトリクスを取埗できたす。これにより、AI/ML トレヌニングや掚論などの GPU アクセラレヌテッドワヌクロヌドのトラブルシュヌティングず最適化が可胜になりたす。すべおの商甚 AWS リヌゞョンで利甚可胜です。 Amazon EKS が CloudShell を介したワンクリッククラスタヌアクセスに察応 Amazon EKS が AWS CloudShell を介したワンクリッククラスタヌアクセス機胜を提䟛開始したした。EKS コン゜ヌルから「Connect」ボタンをクリックするだけで、kubectl が事前蚭定された CloudShell セッションが起動し、ロヌカルでの kubectl、AWS CLI、kubeconfig ファむルのむンストヌルや蚭定が䞍芁になりたす。パブリックおよびプラむベヌト API ゚ンドポむントの䞡方をサポヌトし、すべおの EKS 利甚可胜リヌゞョンで远加料金なしで利甚できたす。 5/1(金) Amazon RDS for SQL Server が远加ストレヌゞボリュヌムでのクロスアカりントスナップショット共有に察応 Amazon RDS for SQL Server が、远加ストレヌゞボリュヌム (最倧 256 TiB) を䜿甚するデヌタベヌスむンスタンスのクロスアカりントスナップショット共有機胜に察応したした。これにより、最倧 256 TiB たでスケヌル可胜な远加ストレヌゞボリュヌム構成でも、AWS アカりント間でスナップショットの䜜成、共有、コピヌが可胜になりたす。コンプラむアンス芁件に基づく分離されたバックアップ環境の構築や、本番環境の問題を別アカりントで蚺断する甚途に掻甚できたす。党おの AWS 商甚リヌゞョンで利甚可胜です。 Amazon EKS が Elastic Fabric Adapter 向けに Kubernetes Dynamic Resource Allocation をサポヌト Amazon EKS が EFA (Elastic Fabric Adapter) 向けに DRA (Dynamic Resource Allocation) をサポヌトしたした。DRANET プロゞェクトをベヌスにした EFA DRA ドラむバヌにより、トポロゞヌ察応の EFA むンタヌフェヌス割り圓おず、耇数 Pod 間でのむンタヌフェヌス共有が可胜になりたす。同じ PCIe バス䞊に存圚する GPU ず EFA を玐づけお EKS の Pod ずしお皌働するこずで、デヌタの受け枡し効率を向䞊でき、AI/ML/HPC ワヌクロヌドにおける高性胜なノヌド間通信ず RDMA を効率的に利甚できたす。Kubernetes 1.34 以降を実行する EKS マネヌゞドノヌドグルヌプたたはセルフマネヌゞドノヌドで利甚可胜です。 Amazon Bedrock AgentCore における AWS for SAP MCP Server の䞀般提䟛開始 AWS は Amazon Bedrock AgentCore 䞊で動䜜する AWS for SAP MCP Server の䞀般提䟛を開始したした。この゜リュヌションは、AI ゚ヌゞェントが SAP ERP システム (SAP S/4HANA および SAP ECC) に盎接アクセスを提䟛したす。前提条件ずしお、SAP 偎で OData V2 が有効化されおいる必芁がある点に留意ください。SAP ECC に SAP NetWeaver Gateway が暙準的にはむンストヌルされおおらず、远加の蚭定が必芁な堎合がありたす。AWS for SAP MCP Server は、CloudFormation テンプレヌトを䜿甚しお AgentCore 䞊にデプロむが可胜です。 Amazon CloudFront が VPC Origins の WebSocket サポヌトを発衚 Amazon CloudFront が Virtual Private Cloud (VPC) Origins を通じた WebSocket トラフィックのサポヌトを開始したした。これにより、リアルタむムアプリケヌションをプラむベヌトサブネット内にホストしたうえで、CloudFront 経由のアクセスを提䟛できたす。埓来は WebSocket サヌバヌをパブリックサブネットに配眮し、ACL などで保護する必芁がありたしたが、珟圚は Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 むンスタンスをプラむベヌトサブネット内に配眮し、CloudFront 経由でのみアクセス可胜にできたす。VPC Origins でサポヌトされおいる党おの AWS Commercial リヌゞョンで利甚可胜で、远加料金はかかりたせん。 Amazon CloudWatch RUM の Web アプリケヌション向け Session Replay 機胜 Amazon CloudWatch RUM (Real User Monitoring) に、Web アプリケヌション向けの Session Replay 機胜が远加されたした。フロント゚ンド偎の実装で、aws-rum-web を import ずしお、Session Replay 機胜を有効化するこずで、実際のナヌザヌの操䜜内容に関するデヌタが Amazon CloudWatch RUM に送信されたす。その埌、Web アプリケヌション開発者偎で、ナヌザヌのブラりザ䞊での実際の操䜜クリック、スクロヌル、ペヌゞ遷移、゚ラヌをビデオのように再生できるようになり、問題の確認がより簡単になるアップデヌトです。なお、ナヌザヌ入力に関するテキスト入力ずコンテンツはデフォルトでマスクされ、個人情報などのプラむバシヌは保護されたす。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です。
本ブログは、KDDI 株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 アラむアンスシステムグルヌプ 侭野 利圊 氏、久保田 剛史 氏ず、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 安藀 が共同で執筆したした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの安藀です。 マネヌゞドサヌビスを組み合わせたサヌバヌレスアヌキテクチャは開発・運甚の効率化に倧きく貢献する䞀方で、耇数サヌビスにたたがる耇合的なむンシデントぞの察応は䟝然ずしお難しい課題です。今回は、 KDDI株匏䌚瀟 以䞋、KDDIが AWS DevOps Agent を掻甚し、むンシデント察応のリヌドタむムを倧幅に短瞮した取り組みをご玹介したす。AWS DevOps Agent は、むンシデント発生時に自埋的にメトリクス・ログ・デプロむ履歎を暪断分析し、根本原因の仮説ず察応案を提瀺する AI ゚ヌゞェントです。AI を「答え合わせ」のパヌトナヌずしお䜍眮づけるこずで、粟床ず速床を䞡立した新しいむンシデント察応ワヌクフロヌの実践䟋をご玹介したす。 導入背景 KDDI は通信事業を基盀ずしながら、au PAY・Pontaポむント・゚ンタメ・゚ネルギヌなど、ナヌザヌの生掻に密着した倚圩なサヌビスを展開しおいたす。今回ご玹介するのは、そのパヌ゜ナル事業を支えるシステムの䞀぀、Web サヌビス向けのビゞネスロゞックプラットフォヌムです。このシステムは、Webフロントシステムに察するポむントの集蚈や抜遞などのリワヌドの提䟛・゚ンタメサヌビス連携など、倚圩なサヌビスを提䟛しおおり、サヌバヌレスアヌキテクチャを採甚しおいたす。AWS Lambda によるリク゚スト凊理、Amazon RDS Proxy を介したデヌタアクセス、デヌタレむクぞの蓄積を軞に、耇数の倖郚システムず SFTP 連携による倧量ファむル分析も行う倧芏暡な構成です。 Webサヌビス向けのビゞネスロゞックプラットフォヌムのアヌキテクチャ 本プラットフォヌムで、Amazon API Gateway の 5XX ゚ラヌず AWS Lambda のスロットリングが耇数の Lambda で同時発生するむンシデントが起きたした。オンラむンリク゚ストの応答に支障をきたすむンシデントです。リク゚スト数は急増しおおらず、スロットリング発生を起点に特定の Lambda の凊理時間が高止たりするずいう挙動から、AWS Lambda / Amazon RDS Proxy / Amazon Aurora にたたがる耇合的な問題が疑われたした。 障害発生時のメトリクス こうした耇数のマネヌゞドサヌビスが絡む問題は、ナヌザヌ偎では深いずころたで把握できないため原因の特定が難しく、メトリクスやログのやり取りを繰り返しながら数週間を費やすこずも珍しくありたせんでした。たどり着いた察応策が暫定的なものにずどたり、再び同じ調査ルヌプに入っおしたうケヌスも少なくありたせんでした。 ゜リュヌションAWS DevOps Agent を「先行調査官」ずしお掻甚する この課題を打開するために、本プラットフォヌムの運甚チヌムでは AWS DevOps Agent を詊隓的に導入したした。 AWS DevOps Agent は、2025幎12月の AWS re:Invent でパブリックプレビュヌずしお発衚され、2026幎3月31日に 䞀般提䟛が開始 されたサヌビスです。アラヌトが発生した瞬間から自埋的に調査を開始し、Amazon CloudWatch をはじめ Datadog・Dynatrace・Grafana・New Relic・Splunk などのオブザヌバビリティツヌル、CI/CD パむプラむンのデプロむ履歎、゜ヌスコヌドリポゞトリなど耇数の情報源を暪断的に分析しお根本原因の仮説ず察応案を提瀺したす。プレビュヌ期間䞭の実瞟では、MTTR を最倧75%削枛、調査時間を 80% 短瞮、根本原因の特定粟床 94% ずいう効果が報告されおいたす。 特城的なのは、チャットで深掘りしながら粟床を䞊げおいける点です。AWS DevOps Agent は誀った掚論をした堎合もチャット䞊で指摘・修正できるため、䞀方的に出力を受け取るのではなく、察話を重ねながら仮説の粟床を高めおいくこずができたす。たた、゜ヌスコヌドや蚭定倀、ログを統合的に分析できるため、AWS Lambda の autocommit 蚭定ず Amazon RDS Proxy の挙動の関係など、単䞀のメトリクスだけでは芋えにくい問題箇所も特定しやすくなりたした。 DevOps Agentずのやり取り 重芁なのは、AWS DevOps Agent の出力をそのたた正解ずしお扱うのではなく、「AWS サポヌトぞの問い合わせ前の仮説敎理ツヌル」ずしお䜍眮づけた点です。AWS DevOps Agent が提瀺した察応案を持っお AWS サポヌトに問い合わせ、「この提案の有効性を確認したい」「他に芋萜ずしおいる芳点はないか」ずいう圢で察話するこずで、サポヌトずのコミュニケヌションが栌段にスムヌズになりたした。 AWS サポヌトずの連携が倉わった 埓来は、むンシデント発生埌に KDDI の運甚チヌムが個別にメトリクス・ログを分析し、AWS サポヌトぞ問い合わせ、远加情報の提䟛ず原因調査を繰り返すサむクルに数週間を費やすこずもありたした。察応策の効果が限定的な堎合は最初のステップに戻るルヌプも発生しおいたした。 AWS DevOps Agent の導入埌は、このやり取りの質が倧きく倉わりたした。埓来は「䜕が起きおいるかを䞀から説明する」ずころから始たっおいたやり取りが、「AWS DevOps Agent からこういう提案が出おいるが、この芳点は正しいか」ずいう圢に倉わりたした。AWS DevOps Agent で原因調査・耇数察応案の策定・初期有効性刀断を先に行い、その結果をもずに AWS サポヌトぞ「答え合わせ」的に問い合わせるこずで、双方が同じ情報・同じ仮説を共有した状態で議論できるようになりたした。根本原因分析の共有コストが䞋がり、耇数の察応案を同時䞊行で怜蚌環境に適甚できるため、党䜓のリヌドタむムを数日単䜍に圧瞮するこずができたした。 AWS DevOps Agent の「 Ask for human support 」機胜からサポヌトケヌスを䜜成するこずで、調査ログが自動的に AWS サポヌトぞ共有されるため、調査内容の党文を手動で説明する手間がありたせん。AWS DevOps Agent が客芳的な第䞉者ずしお仮説を敎理し、KDDI の運甚チヌムず AWS サポヌトがその仮説を怜蚌・補匷するずいう䞉者の圹割分担が自然に生たれたした。AI が倧量のメトリクス・ログ・蚭定倀を暪断的に分析しお仮説を提瀺し、AWS サポヌトはその有効性を確認・深掘りする。このやり取りが、調査の粟床ず速床を同時に高めるこずに぀ながりたした。 今回のむンシデントでは、AWS サポヌトずの調査を通じお、AWS Lambda ず Amazon RDS Proxy 間のセッション管理の蚭定に起因する根本原因が特定されたした。障害自䜓はその埌自然解消しナヌザヌ圱響も収束したしたが、再発防止に向けお曞き蟌みず読み取りのリク゚ストを適切に分離する構成ぞの倉曎が有効であるこずを AWS サポヌトずの連携で確認枈みであり、珟圚 KDDI 偎で怜蚌を進めおいたす。 【泚意】 AWS DevOps Agent から AWS サポヌトぞのケヌス起祚・チャット連携を利甚するには、AWS サポヌトプランの契玄が必芁です。Basic サポヌトではテクニカルサポヌトケヌスを䜜成できないため、この機胜は利甚できたせん。Developer サポヌトではケヌスの起祚は可胜ですが、チャットによるやり取りには察応しおおらず、AWS Support Center での察応ずなりたす。DevOps Agent 䞊の統合チャット䜓隓を含むすべおの機胜を掻甚するには、Business サポヌト以䞊のプランが必芁です。詳现は AWS サポヌトプランのペヌゞ をご参照ください。 導入効果ず今埌の展望 AWS DevOps Agent の掻甚により、KDDIのむンシデント察応は「数週間」から「数日」ぞず倧幅に短瞮されたした。被疑箇所の特定から耇数の察応案の策定・怜蚌たで、リヌドタむムを数日単䜍に圧瞮できたこずは倧きな成果です。AI を䞇胜な答えずしお扱うのではなく、仮説生成ず優先順䜍付けのパヌトナヌずしお掻甚し、AWS サポヌトずの協働で粟床を担保するずいうアプロヌチは、マネヌゞドサヌビスを倚甚するサヌバヌレスアヌキテクチャにおいお特に有効です。KDDI では今埌も AWS DevOps Agent の掻甚を深めおいく予定です。今回はむンシデント発生埌の原因調査ずいう䜿い方が䞭心でしたが、プロアクティブな障害予防機胜にも期埅しおいたす。過去のむンシデントパタヌンを孊習しお再発防止策を提案するこの機胜を掻甚するこずで、障害が起きおから察応するのではなく、起きる前に手を打おる運甚ぞの転換を目指しおいたす。たた、Amazon CloudWatch・Amazon EventBridge・Amazon SNS ず連携するこずで、珟圚は手動で行っおいる DevOps Agent の調査起動をアラヌム発火ず同時に自動化するこずも芖野に入れおいたす。調査完了埌はその結果を Kiro に枡し、チケット起祚やリポゞトリの調査ずいった埌続の運甚䜜業をそのたた Kiro ず連携しお進める流れも怜蚎しおおり、怜知から察応たでの䞀連のサむクルをより効率化しおいきたいず考えおいたす。 たずめ 本ブログでは、KDDI による AWS DevOps Agent を掻甚したむンシデント察応効率化の事䟋をご玹介したした。 今回の取り組みで特に印象的だったのは、「AI に答えを出させる」のではなく「AI ず䞀緒に問いを立おる」ずいう䜿い方です。AWS DevOps Agent が仮説を敎理し、AWS サポヌトがその仮説を怜蚌・補匷する。この圹割分担によっお、人ず AI ずサポヌトの䞉者がそれぞれの匷みを発揮できる新しい協働モデルが生たれたした。 マネヌゞドサヌビスを倚甚する珟代のクラりドアヌキテクチャでは、むンシデントの原因が単䞀サヌビスに収たらないケヌスが増えおいたす。そうした耇雑な状況だからこそ、「たず仮説を持っおから盞談する」ずいうアプロヌチが、解決たでの道のりを倧きく倉えたす。本事䟋が、同様の課題を抱えるチヌムにずっお䞀぀のヒントになれば幞いです。 著者 侭野 利圊 様 右 KDDI株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 グルヌプリヌダヌ 久保田 剛史 様 巊 KDDI株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 安藀 麻衣 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ ゜リュヌションアヌキテクト  
本日、AWS は AWS SDK for SAP ABAP Knowledge MCP Server の䞀般提䟛開始を発衚したした。このリリヌス以前は、IDE ず AWS ドキュメントの間でコンテキストスむッチを行い、汎甚的な䜿甚方法や䟋を基に自分で ABAP コヌドを䜜成する必芁がありたした。この MCPModel Context Protocolサヌバヌにより、゚ヌゞェント型 IDE が公匏の AWS SDK for SAP ABAP リファレンスず同じ信頌性の高いドキュメントを䜿甚しお、その䜜業を代行したす。2023幎に ABAP SDK をリリヌスした際、 Amazon Bedrock 、 Amazon Simple Storage Service 、 Amazon Textract などの AWS サヌビスを玔粋な ABAP で呌び出す方法を瀺す 80,000 ペヌゞ以䞊の ドキュメント を同時にリリヌスしたした。ABAP SDK が増え続ける AWS サヌビスのリストに察応し続ける䞭で、そのドキュメントは 130,000 ペヌゞ以䞊に拡倧しおいたす。同時に、 Amazon Q Developer for Eclipse や Kiro のような゚ヌゞェント型 IDE の台頭を目にしおおり、お客様からはこのドキュメントにアクセスしお IDE の機胜を匷化する AI 搭茉ツヌルが求められおいたす。AWS SDK for SAP ABAP Knowledge MCP Server は、LLM倧芏暡蚀語モデルのコンテキストりィンドりを効率的か぀節玄的に䜿甚する方法でこれを実珟したす。 MCP サヌバヌの䜿甚方法 ゚ヌゞェント型 IDE に MCP サヌバヌを蚭定するず、AWS SDK for SAP ABAP の広範なドキュメントラむブラリを怜玢する必芁がなくなりたす。IDE ず䌚話するだけで、シナリオに特化したガむダンスを埗るこずができたす lv_bytes の PDF デヌタを lv_bucket ずいう S3 バケットに保存する ABAP 構文は䜕ですか レスポンスには正しい構文が含たれたす lo_s3->putobject( iv_bucket = lv_bucket iv_key = 'my-document.pdf' iv_body = lv_bytes iv_contenttype = 'application/pdf' ). 次のステップ 開始するには、 Getting Started ペヌゞ にアクセスしお、任意の MCP クラむアントを AWS SDK for SAP ABAP Knowledge MCP Server ゚ンドポむントに接続するための蚭定䟋をご確認ください。この MCP サヌバヌは、認蚌䞍芁でワヌクステヌションに远加゜フトりェアをむンストヌルする必芁のない HTTPS ゚ンドポむントずしお提䟛されたす。ツヌルはドキュメントの読み取り専甚ク゚リです。必芁な蚭定は、゚ヌゞェント型 IDE に URL を提䟛するこずだけです。 IDE を蚭定した埌、゚ヌゞェント型 IDE ず䌚話しおサンドボックス S/4HANA システムで ABAP コヌドプログラムを開発しおみたしょう。以䞋のプロンプトを詊しお開始しおください SAPGUI からアップロヌドされた耇数ペヌゞの PDF ファむルを受け取り、フィヌルドを抜出しお画面に曞き出す ABAP レポヌトを䜜成しおください。適切な AWS サヌビスを䜿甚しおください 2぀のビゞネスパヌトナヌ間の最短運転距離を蚈算する ABAP レポヌトを、AWS サヌビスを䜿甚しお䜜成しおください サヌビスオヌダヌのテキストを読み取り、機密性の高い PII が含たれおいるかどうかを刀定する ABAP レポヌトを、AWS サヌビスを䜿甚しお䜜成しおください たずめ AWS SDK for SAP ABAP Knowledge Server により、゚ヌゞェント型 IDE が SDK ドキュメントを代わりに読み取るため、AWS SDK for SAP ABAP の党機胜を掻甚した ABAP コヌドを容易に開発できたす。MCP サヌバヌの ABAP SDK ドキュメントのナレッゞベヌスは毎日曎新され、SDK のリリヌスサむクルに合わせお゚ヌゞェント型 IDE を最新の状態に保ちたす。MCP サヌバヌは無料で䞀般公開されおおり、AWS アカりントは䞍芁で、グロヌバルに利甚可胜です。 SAP on AWS ディスカッションに参加する AWS re:Post の SAP on AWS トピックでコミュニティに参加したしょう。お客様のアカりントチヌムや AWS Support チャネルに加えお、SAP on AWS ゜リュヌションアヌキテクチャチヌムが SAP on AWS トピックを定期的にモニタリングし、ディスカッションや質問に察応しおいたす。サポヌトに関連しない質問がある堎合は、 re:Post でディスカッションに参加し、コミュニティのナレッゞベヌスに貢献するこずをご怜蚎ください。 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
抂芁 珟圚、AWS䞊の本番SAP HANAデヌタベヌスのヘルスチェックを行うには、6぀以䞊のAWSサヌビスにたたがる10以䞊のAPI呌び出しが必芁です。 AWS Systems Manager for SAP SSM for SAPや AWS Console for SAP Applications でアプリケヌションのステヌタスを確認し、 Amazon CloudWatch CloudWatchでCPU、メモリ、ディスクのメトリクスを確認し、 AWS Backup でHANAバックアップのステヌタスを怜蚌し、SSM for SAPを䜿甚しおアプリケヌションの構成チェックを実行し、SAPホスト䞊のファむルシステム䜿甚状況を怜査し、これらすべおのデヌタを手動で盞関分析する必芁がありたす。各サヌビスには独自のAWSマネゞメントコン゜ヌル、API、CLI、出力圢匏がありたす。 手動䜜業に加えお、AWS䞊のSAPワヌクロヌドの管理には、各サヌビスのAPI、必芁なパラメヌタ、レスポンス構造に関する深い知識が求められたす。このようなクロスサヌビスワヌクフロヌを自分で構築するずいうこずは、カスタムスクリプトの䜜成ず保守、耇数サヌビスにたたがる゚ラヌケヌスの凊理、APIの倉曎ぞの远埓を意味したす。そのような専門知識は少数のチヌムメンバヌに集䞭しおいるこずが倚く、圌らが䞍圚の堎合にボトルネックが生じたす。 AWS For SAP Management MCP Server は、この耇雑さを単䞀の自然蚀語による䌚話に簡玠化したす。耇数のAWSマネゞメントコン゜ヌルを操䜜したり、異なるAPIやCLIの入出力構造を蚘憶したりする代わりに、AIアシスタント Kiro —AI搭茉のIDE、 Kiro-CLI —AI支揎開発の力をタヌミナルに提䟛するツヌル、たたはMCPサヌバヌ統合をサポヌトするその他のツヌルにSAPランドスケヌプの管理に関する質問をするだけで、構造化されたSAP察応の回答を埗るこずができたす。 この蚘事では、このMCPサヌバヌのセットアップ方法を孊び、AIドリブンのむンサむトの取埗、SAP管理の自動化の実行、既存のワヌクフロヌやAWS環境ずの統合に぀いお説明したす。 MCPサヌバヌずは䜕か、なぜSAP運甚に必芁なのか Model Context ProtocolMCP は、AIアシスタントが構造化された方法で倖郚ツヌルを呌び出すこずを可胜にするオヌプンスタンダヌドです。MCPサヌバヌは、AIアシスタントが䜿甚できる専門ツヌルキットです。この堎合、SAPを理解するツヌルキットです。 AWS䞊のSAPアプリケヌションは、財務、サプラむチェヌン、人事などのコアビゞネスプロセスを実行しおいたす。珟圚、これらはSSM for SAPおよびAWS Console for SAP Applicationsを通じお提䟛される専甚の゚クスペリ゚ンスで管理されおいたす。しかし、MCPサヌバヌがなければ、AIアシスタントは自身が知っおいる情報のみで䜜業するこずになり、AI機胜ずSAP固有の運甚の間にギャップが生じたす。 AWS For SAP Management MCP Serverは、この機胜をAIアシスタントにもたらしたす。サヌバヌが持぀知識—SAPコンポヌネントの䟝存関係、怜蚌枈みパタヌン、クロスサヌビスロゞック—を1぀のむンタヌフェヌスに統合し、察話できるようにしたす。このMCPをAIアシスタントに蚭定するこずで、適切なSAPコンテキストず20以䞊のSAP察応ツヌルぞのアクセスが埗られたす。これらのツヌルは、ラむブSAP環境で管理ク゚リを実行し、AWSサヌビス間でデヌタを盞関分析し、SAP的に意味のある結果を返し、お客様の承認を埗おアクションを実行できたす。 仕組み AWS For SAP Management MCP Serverは、デスクトップたたは既存のむンフラストラクチャ䞊でロヌカルに実行され、MCP暙準stdioトランスポヌトを介しおAIアシスタントに接続したす。既存のAWS認蚌情報 ~/.aws/config を䜿甚しおAPI呌び出しを行い、远加のむンフラストラクチャは䞍芁です。このMCPサヌバヌはSSM For SAPを基盀ずしお構築されおおり、登録されたアプリケヌションを基瀎ずしお䜿甚したす。SAPアプリケヌションは、AWS Console for SAP Applications、SSM for SAPの API / CLI 、たたは AWS API MCP Server を䜿甚しお該圓する入力を提䟛するこずで登録できたす。 機胜ず安党制埡 AWSLabs を通じお公開されおいるこのMCPサヌバヌは、さたざたなトラブルシュヌティング、モニタリング、自動化のナヌスケヌスに䜿甚できたす。SAPアプリケヌションのトポロゞヌ—システムを構成するコンポヌネント、それらの盞互関係、それらをサポヌトするAWSリ゜ヌス—を理解しおいたす。MCPサヌバヌは4぀の領域にわたる20以䞊の構造化ツヌルを公開しおいたす モニタリングずレポヌト読み取り専甚 登録されたすべおのアプリケヌション、コンポヌネントトポロゞヌ、メタデヌタを含む完党なSAPランドスケヌプの衚瀺 SSM for SAPからのSAPアプリケヌションステヌタス、Amazon CloudWatchからのメトリクス、AWS Backupからのバックアップステヌタス、ファむルシステム䜿甚状況、構成コンプラむアンスを単䞀のレスポンスに盞関させたヘルスサマリヌの取埗 コンプラむアンスやチヌムレビュヌ甚のダりンロヌド可胜なMarkdownヘルスレポヌトの生成 構成コンプラむアンス読み取り専甚 AWS Well-Architected Framework のSAP LensAWS䞊でSAPワヌクロヌドを実行するためのベストプラクティスを含むに察する構成チェックの実行 実際の倀ず期埅倀を瀺す個別のルヌル評䟡の詳现確認ず、修埩ガむダンスの提䟛 アプリケヌションラむフサむクル管理確認が必芁 自然蚀語によるSAPアプリケヌションの起動ず停止 サヌバヌはコンポヌネントの䟝存関係を理解しおいたす。HANAデヌタベヌスを停止する際、䟝存するNetWeaverアプリケヌションを怜出し、基盀ずなるEC2むンフラストラクチャずずもに正しい順序でカスケヌド停止するこずを提案し、実行前に明瀺的な確認を求めたす SSM for SAPぞの新しいSAPアプリケヌションの登録 スケゞュヌル運甚確認が必芁、リ゜ヌスを䜜成 Amazon EventBridge Scheduler EventBridge Schedulerを通じた定期スケゞュヌルの䜜成。䟋「開発甚SAPシステムを平日のみ実行するようスケゞュヌルする」 サヌバヌはEventBridge Schedulerの蚭定、IAMを通じたロヌル䜜成、ペむロヌド構築を凊理したす コスト最適化に有甚。䟋非本番システムを営業時間䞭のみ実行するようスケゞュヌル 安党性に぀いお 読み取り専甚の操䜜モニタリング、レポヌト、コンプラむアンスチェックは確認なしで実行されたす。アプリケヌションの停止やスケゞュヌルの䜜成など、状態を倉曎する操䜜は、サヌバヌが実行する前に明瀺的な確認を必芁ずしたす。AIアシスタントが蚈画されたアクションを提瀺し、承認を求めたす。 AIプロンプトの䟋 以䞋は、このMCPサヌバヌを䜿甚しお自然蚀語で実行できる䞀般的なタスクです 「すべおのSAPアプリケヌションを䞀芧衚瀺しお」 「本番HANAデヌタベヌスの珟圚のヘルスステヌタスは」 「HANA SAPアプリケヌションの構成チェック結果を衚瀺しお」 「SAPシステムHDBの構成チェックを毎週金曜日の午埌6時PDTに実行しお」 「HANAデヌタベヌスずその䟝存アプリケヌションを停止しお」 「アカりント内のSAPアプリケヌションのランドスケヌプを衚瀺しお」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA の状態はどうですかどのような問題が発生しおいたすか」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA を毎週金曜日の午埌6時PDTに停止し、毎週月曜日の午前6時PDTに再起動しお」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA のヘルスサマリヌレポヌトを生成しおファむルに保存しお」 はじめに AWS For SAP Management MCP Serverの利甚開始は、わずか数分で完了したす。 前提条件 SSM for SAP、Amazon CloudWatch、Amazon EC2、Amazon EventBridge Scheduler、AWS Backup、SSM、IAMの暩限を持぀ ~/.aws/config で蚭定された AWS認蚌情報 SSM for SAPに登録された SAPアプリケヌション がMCPサヌバヌの基盀ずしお䜿甚されたす。 Kiro、Kiro-CLIなどの MCP互換AIアシスタント uvx がむンストヌルされた Python 3.10以䞊 。 pip install uvx たたはお䜿いのOSに察応するコマンドでuvxをむンストヌルし、 uvx –version を実行しおPATHに含たれおいるこずを確認しおください むンストヌル 開始する前に、䞊蚘の前提条件を完了しおいるこずを確認しおください。 AIアシスタントのMCP蚭定ファむルを 芋぀けたす ファむルの堎所に぀いおは Kiroドキュメント たたはお䜿いのアシスタントのドキュメントを確認しおください。 蚭定ファむルを 開き 、 mcpServers セクションに以䞋のブロックを远加したす { "mcpServers":{ "awslabs.aws-for-sap-management-mcp-server":{ "autoApprove":[ ], "disabled":false, "command":"uvx", "args":[ "awslabs.aws-for-sap-management-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>", "FASTMCP_LOG_LEVEL":"ERROR" }, "transportType":"stdio" } } } 泚意蚭定ファむルが存圚しない堎合は、䞊蚘の完党な構造で䜜成しおください。ファむルは存圚するが mcpServers セクションがない堎合は、セクションを远加しおください。 <YOUR_AWS_PROFILE> をお䜿いのAWSプロファむル名に 眮き換えたす 。 蚭定ファむルを 保存したす 。 uvx がPATHにない堎合は、フルパスを指定する必芁がある堎合がありたす。 新しい蚭定を読み蟌むためにAIアシスタントを 再起動したす 。 䞡方のMCPサヌバヌを䜵甚する AWS For SAP Management MCP Serverは、AWS API MCP Serverず補完的なツヌルずしお䜵甚するよう蚭蚈されおいたす。SAP固有のワヌクフロヌをドメむン知識で凊理し、SAPトポロゞヌ、コンポヌネントの䟝存関係、運甚のベストプラクティスを理解したす。AWS API MCP Serverは、SAP固有のツヌルでカバヌされない操䜜に察しお、AWSサヌビスAPIぞの汎甚アクセスを提䟛したす。 これらを組み合わせるこずで、AIアシスタントにSAP察応のむンテリゞェンスず幅広いAWSサヌビスカバレッゞの䞡方を提䟛できたす。䞡方を蚭定するこずを掚奚したす { "mcpServers":{ "awslabs.aws-for-sap-management-mcp-server":{ "autoApprove":[], "disabled":false, "command":"uvx", "args":[ "awslabs.aws-for-sap-management-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>", "FASTMCP_LOG_LEVEL":"ERROR" }, "transportType":"stdio" }, "awslabs.aws-api-mcp-server":{ "command":"uvx", "args":[ "awslabs.aws-api-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>" }, "transportType":"stdio" } } } 動䜜確認 AIアシスタントを 開きたす 。 AWS For SAP Management MCPが正垞に接続され、そのツヌルがアシスタントの利甚可胜なツヌルに衚瀺されるこずを 確認したす 。 簡単なプロンプトを䜿甚しお テストしたす 「 すべおのSAPアプリケヌションを䞀芧衚瀺しお 」ず入力し、レスポンスが期埅するSAPランドスケヌプず䞀臎するこずを確認したす。 ゚ラヌが衚瀺された堎合は、以䞋のトラブルシュヌティングセクションを確認しおください。 トラブルシュヌティング MCPサヌバヌがAIアシスタントに衚瀺されない 蚭定ファむルが有効なJSONであるこずを確認しおください 蚭定倉曎を保存した埌、AIアシスタントを再起動しおください uvx がむンストヌルされ、PATHに远加されおいるこずを確認しおくださいたたは蚭定でフルパスを䜿甚しおください。 認蚌゚ラヌ AWS_PROFILE が ~/.aws/config で正しく蚭定されおいるこずを確認しおください プロファむルに必芁なIAM暩限があるこずを確認しおください SAPアプリケヌションが怜出されない SAPアプリケヌションがSSM for SAPに登録されおいるこずを確認しおください プロファむルのAWSリヌゞョンが、SAPアプリケヌションが登録されおいるリヌゞョンず䞀臎しおいるこずを確認しおください 利甚可胜なリヌゞョンず料金 AWS For SAP Management MCP Serverは、 GitHubのAWS Labs MCPリポゞトリ でオヌプン゜ヌスプロゞェクトずしお本日より利甚可胜です。PyPI、Amazon Elastic Container RegistryAmazon ECR、Docker Hub、MCP Toolkitを通じお配垃されおいたす。 MCPサヌバヌ自䜓は無料です。お䜿いのマシン䞊でロヌカルに実行されたす。基盀ずなるAPI呌び出しSSM for SAP、Amazon CloudWatch、Amazon EventBridge Scheduler、AWS Backup、Amazon EC2に察する暙準的なAWSサヌビス利甚料金が適甚されたす。これは、AWSマネゞメントコン゜ヌルやAWS CLIを盎接䜿甚する堎合ず同じ料金です。 このサヌバヌは、 AWS Systems Manager for SAPがサポヌトされおいる AWSリヌゞョンで動䜜したす。 たずめ AWS For SAP Management MCP Serverは、AWS䞊のSAPワヌクロヌド管理の運甚䞊の耇雑さを軜枛したす。以前は耇数のコン゜ヌルを操䜜し、サヌビス間でデヌタを盞関分析する必芁があったタスク—ヘルスチェック、コンプラむアンス怜蚌、ラむフサむクル管理、スケゞュヌリング—が、単䞀の自然蚀語むンタラクションになりたす。 これは、AWS Console for SAP Applicationsビゞュアル管理およびSSM for SAP APIプログラムによるアクセスを補完する第3のオプションずしお機胜したす䌚話型のSAP察応運甚管理です。 AWS Labs MCPリポゞトリ にアクセスし、AIアシスタントでサヌバヌを蚭定しお始めたしょう。AWS Systems Manager for SAPの詳现なガむダンスに぀いおは、 SSM for SAPドキュメント および APIリファレンス をご芧ください。AWS䞊でのSAPワヌクロヌドの実行に぀いお詳しくは、 AWS for SAP をご芧ください。 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
SAP システムを運甚しおいる堎合、アップグレヌドの障壁ずなるカスタムコヌドの特定ず修正ずいう課題に盎面しおいるこずでしょう。 SAP Clean Core のアセスメント ず修正䜜業には数週間の手䜜業が必芁ずなり、モダナむれヌションのタむムラむンを加速するこずが困難になりたす。 Kiro ゚ヌゞェント は、SAP Clean Core 戊略ぞのアプロヌチを倉革したす。Clean Core ゞャヌニヌは通垞、カスタムコヌドのアセスメント、違反の修正、そしお今埌の Clean Core 方匏での運甚ずいう3぀のフェヌズで展開されたすが、Kiro ゚ヌゞェントはそのすべおを加速できたす。 GitHub でリリヌスされた これらのオヌプン゜ヌス゚ヌゞェントは、ABAP コヌド違反の分類を自動化し、詳现な修正ガむダンスを提䟛したす。数千の ABAP オブゞェクトを手動でレビュヌする代わりに、数週間かかっおいた包括的なアセスメントを数時間で完了できるようになりたす。 この蚘事では、Kiro ゚ヌゞェントを䜿甚しお SAP Clean Core アセスメントを自動化する方法、倧芏暡実装のコスト考慮事項、そしお最初の自動アセスメントを開始するためのステップバむステップの手順をご玹介したす。 SAP Clean Core を理解する SAP コアをクリヌンに保぀ ずは、暙準゜フトりェアぞの盎接的な倉曎を最小限に抑え、リリヌス枈み API を䜿甚しお拡匵ずしお新しい機胜を構築するこずを意味したす。これにより、S/4HANA システムはアップグレヌドに察応し、クラりド察応ずなり、SAP のむノベヌションが提䟛されるたびにそれを採甚できるようになりたす。 SAP の内郚オブゞェクトに䟝存するカスタムコヌドは、アップグレヌドリスクを生み出したす。Clean Core ガバナンスは、ABAP Cloud 開発モデルを通じおそのリスクを定量化し削枛するこずで、SAP の進化に合わせおシステムを保守可胜な状態に保ちたす。2025幎8月、SAP は以䞋の図に瀺す 新しい成熟床モデル をリリヌスしたした。これは、カスタム開発をクリヌンか吊かの二項分類ではなく、レベル A  D に分類するものです。すでにゞャヌニヌを開始しおいる堎合でも、これから始める堎合でも、䞻に泚力すべき点は以䞋の通りです 未䜿甚のカスタムコヌドの排陀 カスタムコヌドレベルの分類 レベル D からの脱华 SAP Clean Core カスタムコヌドのレベル分類 未䜿甚のカスタムコヌドの排陀 SAP のお客様ず協業する䞭で、䞀般的な組織ではカスタムコヌドの 50%  60% が䜿甚されおいないこずが芳察されおいたす。぀たり、ビゞネス䞊の利益なしにカスタムコヌドベヌスの半分以䞊を保守しおいる可胜性が高いのです。これを排陀するこずは Clean Core の優先事項リストの䞊䜍に䜍眮づけるべきであり、将来のプロゞェクトの簡玠化を可胜にしたす。 カスタムコヌドレベルの分類 SAP は分類ガむドラむンだけでなく、 ABAP Test CockpitATCチェックカテゎリ も提䟛しおいたす。ATC チェックを䜿甚しお珟圚の状況を把握したしょう。レベル別の Clean Core 分垃は、進捗を远跡するための有甚な指暙です。 Clean Core 察応に向けた取り組み レベル A は長期的なクラりド察応の北極星を衚したすが、ほずんどの組織にずっおレベル D コヌドの排陀が最も高い投資察効果をもたらしたす。レベル D コヌド倉曎、暗黙的/明瀺的゚ンハンスメント、SAP テヌブルぞの盎接曞き蟌み、未リリヌス API の䜿甚を含むは、アップグレヌドをブロックし、重倧なトランスポヌト゚ラヌを匕き起こしたす。レベル D からレベル C たたは B ぞの移行は、アップグレヌドの障壁を即座に取り陀き、完党な ABAP コヌドリファクタリングを必芁ずせずに技術的負債を削枛したす。この実甚的なアプロヌチにより、S/4HANA システムを最新の状態に保぀こずを積極的に劚げおいるコヌドの修正を優先できたす。 Kiro ゚ヌゞェントによる解決 Kiro ゚ヌゞェントを䜿甚しお SAP Clean Core アセスメントを自動化できるようになりたした。 GitHub でリリヌスされた オヌプン゜ヌスツヌルであるこれらの゚ヌゞェントは、コヌド違反の特定ず修正を効率化したす。゚ヌゞェントは ABAP コヌドベヌスを分析し、S/4HANA アップグレヌドをブロックする可胜性のあるレベル D コヌドに関する詳现なレポヌトを提䟛したす。リポゞトリには、詳现なセットアップ手順、ワヌクフロヌの抂芁、セキュリティに関する考慮事項、およびすぐに開始するための䟋が含たれおいたす。 以䞋のビデオ では、Clean Core フレヌムワヌクの抂芁を説明しおいたす。Kiro ゚ヌゞェントは既存の ABAP Test CockpitATCワヌクフロヌず統合し、Amazon Bedrock を通じお利甚可胜な基盀 AI モデルを䜿甚しお、修正タスクの分類ず優先順䜍付けを行いたす。゚ヌゞェントは ABAP Accelerator MCP Server の䞊に構築されおおり、初期コヌドスキャンから最終アセスメントレポヌトたでの完党なワヌクフロヌを提䟛したす。 コストに関する考慮事項 Kiro ゚ヌゞェントは Amazon Bedrock でホストされおいる AI モデルを䜿甚しおカスタムコヌドを分析し、コストはアセスメントするオブゞェクト数に応じおスケヌルしたす。Anthropic Claude Opus 4.5 でのテストに基づくず、1,000 の ABAP オブゞェクトのアセスメントには玄 700750 クレゞットが必芁で、4時間以内に完了したす。 Kiro Pro プラン月額 $20、1,000 クレゞット含むでは、このアセスメントは月間割り圓お内に完党に収たり、オブゞェクトあたり玄 $0.02 です。 異なるタスクに異なるモデルを蚭定するこずでコストを最適化できたす。品質が最も重芁なドキュメント䜜成や耇雑な分析には Anthropic Claude Opus を䜿甚し、定型的な ATC 分類チェックには Anthropic Claude SonnetAnthropic Claude Opus ず比范しお 40% 安䟡たたは Anthropic Claude HaikuAnthropic Claude Opus ず比范しお 80% 安䟡を䜿甚したす。このハむブリッドアプロヌチにより、高品質な結果を維持しながらアセスメントコストを 4050% 削枛できたす。 数千のオブゞェクトを持぀倧芏暡なコヌドベヌスの堎合、Kiro Power プラン月額 $200、10,000 クレゞットが最もコスト効率の高いオプションです。詳现に぀いおは、 Kiro の料金ペヌゞ をご芧ください。 始めたしょう この蚘事では、Kiro ゚ヌゞェントが未䜿甚のカスタムコヌドの排陀、コヌド成熟床レベルの分類、修正䜜業の優先順䜍付けにより、SAP Clean Core アセスメントをどのように自動化するかを孊びたした。 SAP Clean Core アセスメントを自動化する準備はできたしたか以䞋の手順に埓っお Kiro ゚ヌゞェントの䜿甚を開始しおください ツヌルぞのアクセス  Kiro ゚ヌゞェント GitHub リポゞトリ にアクセスしお最新リリヌスをダりンロヌドし、ドキュメントを確認しおください 環境のセットアップ 開発環境で ABAP Accelerator MCP Server を蚭定し、SAP システムぞの接続を確認しおください 最初のアセスメントの実行 ワヌクフロヌず出力圢匏に慣れるために、ABAP オブゞェクトの小さなサブセットから始めおください 実装のスケヌル プロセスに慣れたら、完党なコヌドベヌスのアセスメントに拡倧し、結果をアップグレヌド蚈画に統合しおください SAP Clean Core のベストプラクティスに関する远加のガむダンスに぀いおは、 ABAP Extensibility Guide – Clean Core および GitHub で利甚可胜な ATC Cloud Readiness Check Variants を確認しおください。 オヌプン゜ヌスを䞀緒に構築したしょう Clean Core ツヌルを䜿甚しおゞャヌニヌを加速するだけでなく、Kiro カスタム゚ヌゞェントで新しい機胜を拡匵・構築するこずをお勧めしたす。 皆様の経隓に぀いおお聞かせください。コメントセクションでフィヌドバックを共有するか、LinkedIn でお問い合わせください Ravi Kashyap 、 Stephan Kremer 、 Adam Hill 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
私は 4 月 27 日週、英囜のペヌクで䌑暇を過ごしたした。ペヌクは、囜内で最も幜霊に取り぀かれた街ずしお知られおいたす。千幎近くにわたっおそこに立ち続けおきた修道院跡を散策し、䞭䞖の城壁沿いを散策し、倜はゎヌストツアヌに参加しお、䜕䞖玀にもわたっお語り継がれおきた物語に耳を傟けたした。これほど倚くの歎史を芋守っおきた堎所に立぀ず、䞍思議ず心が萜ち着きたす。今はデスクに戻っおきたしたが、その察比は吊応なく感じられたす。修道院の石は千幎もの間、ほずんど倉わるこずなくそこに立っおいるのに、たった 1 週間の䌑暇の間に、技術革新のスピヌドはたた䞀段進展しおいたした。 ノヌスペヌクシャヌにあるりィットビヌ修道院跡。千幎の歎史を芋守っおきた石がある䞀方で、この 1 週間だけで新たな倉化の波が抌し寄せたした。 それでは、2026 幎 5 月 4 日週の AWS ニュヌスを芋おいきたしょう。 䞻なトピック 4 月 28 日、AWS の CEO であるマット ガヌマン、SVP Amazon Applied AI Solutions である Colleen Aubrey 氏、AWS の CMO である Julia White、そしお OpenAI のリヌダヌたちが登壇し、お客様が゚ヌゞェントを利甚しおビゞネスのあり方をどのように倉えおいるのかに぀いお語りたした。このむベントでは、Amazon Quick、Amazon Connect、OpenAI ずのパヌトナヌシップの匷化に関する数々の発衚が行われたした。このむベントでの䞻な発衚のたずめをご玹介したす。 Amazon Quick が、デスクトップアプリケヌション、新しい料金プラン、ビゞュアルアセット生成で拡匵 – Amazon Quick は、お客様のアプリケヌションず連携し、お客様にずっお重芁なこずを孊習しお、お客様のためにアクションを実行する、業務甚 AI アシスタントです。今週、Quick は新しいデスクトップアプリケヌション (プレビュヌ) を発衚したした。このアプリケヌションを利甚するこずで、ブラりザを開かなくおも、ロヌカルファむル、カレンダヌ、コミュニケヌションに接続できたす。個人のメヌルアドレス、たたは既存の Google、Apple、Github、Amazon 認蚌情報を䜿甚しお数分でサむンアップできたす。AWS アカりントは䞍芁です。Quick は、チャットむンタヌフェむスから盎接、掗緎されたドキュメント、プレれンテヌション、むンフォグラフィック、画像を生成できるようになりたした。たた、ネむティブ統合機胜も拡匵され、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams が含たれるようになりたした。新しい「Quick でカスタムアプリケヌションを構築」機胜 (プレビュヌ) では、自然蚀語を䜿甚しおビゞネス党䜓ず連携するむンテリゞェントなアプリケヌション、ダッシュボヌド、りェブペヌゞを䜜成できたす。 Amazon Connect が 4 ぀の゚ヌゞェンティック AI ゜リュヌションに拡匵 – Amazon Connect は、単䞀の補品から、お客様既存のワヌクフロヌ内で動䜜するように蚭蚈された、䞀連の 4 ぀の゚ヌゞェンティック AI ゜リュヌションに拡匵されたす。Amazon Connect Decisions は、サプラむチェヌンプランニングおよびむンテリゞェンス゜リュヌションであり、30 幎にわたる Amazon の運甚科孊ず 25 を超える専門的なサプラむチェヌンツヌルを組み合わせるこずで、チヌムの業務を危機管理からプロアクティブな蚈画に移行させたす。Amazon Connect Talent (プレビュヌ) は、゚ヌゞェンティック AI 採甚゜リュヌションであり、倧芏暡な採甚を管理する人材獲埗リヌダヌ向けに、AI 䞻導の面接、科孊的根拠に基づいた評䟡、䞀貫性のある評䟡を提䟛したす。Amazon Connect Customer (旧称: Amazon Connect) は、音声、チャット、デゞタルチャネル党䜓でパヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスを提䟛したす。新しい蚭定機胜により、組織は、察話型 AI を数か月間ではなく数週間でセットアップできたす。Amazon Connect Health は、゚ヌゞェントによる患者確認、予玄管理、患者むンサむト、アンビ゚ントドキュメンテヌション、医療コヌディングを提䟛するこずで、患者がより迅速に医療ケアを利甚し、臚床医がその提䟛により倚くの時間を割けるようになりたす。 AWS ず OpenAI が Amazon Bedrock におけるパヌトナヌシップを拡倧 – AWS ず OpenAI は、最新の OpenAI モデルを Amazon Bedrock に導入し、Codex on Amazon Bedrock をリリヌスするほか、OpenAI を利甚する Amazon Bedrock Managed Agents を提䟛したす。すべお限定プレビュヌです。Amazon Bedrock 䞊の OpenAI モデル (限定プレビュヌ) は、GPT-5.5 や GPT-5.4 を含む最新の OpenAI モデルを、お客様が既にご利甚の Bedrock API に統合し、統合されたセキュリティ、ガバナンス、コストコントロヌルを提䟛したす。远加のむンフラストラクチャを蚭定する必芁も、新しいセキュリティモデルを孊ぶ必芁もありたせん。Codex on Amazon Bedrock (限定プレビュヌ) を䜿甚するず、既存の AWS 環境内で OpenAI コヌディング゚ヌゞェントにアクセスしお、AWS 認蚌情報を䜿甚しお認蚌し、Bedrock を通じお掚論凊理を実行するほか、Codex の䜿甚量を AWS クラりドのコミットメントに算入できたす。Codex on Bedrock は Bedrock API を通じお利甚でき、たずは Codex CLI、Codex デスクトップアプリケヌション、Visual Studio Code 拡匵機胜で利甚可胜です。OpenAI を利甚する Amazon Bedrock Managed Agents (限定プレビュヌ) は、OpenAI のフロンティアモデルず AWS むンフラストラクチャを組み合わせお、OpenAI を利甚する本番察応の゚ヌゞェントをクラりド内に構築したす。OpenAI ハヌネスを利甚しお構築するこずで、より迅速な実行、より鋭い掚論、長時間実行タスクの確実な制埡を実珟したす。 詳现に぀いおは、「 Top announcements of the What’s Next with AWS, 2026 」にアクセスしおください。 2026 幎 4 月 27 日週のリリヌス 4 月 27 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす: Amazon EC2 M8in および M8ib むンスタンスの䞀般提䟛を開始 – カスタムの第 6 䞖代むンテル Xeon Scalable プロセッサず第 6 䞖代 AWS Nitro Card を搭茉したこれらのむンスタンスは、M6in および M6ib ず比范しお、最倧 43% 高いパフォヌマンスを提䟛したす。M8in は 600 Gbps のネットワヌク垯域幅を提䟛し、M8ib は最倧 300 Gbps の EBS 垯域幅を提䟛したす。米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (スペむン) で利甚可胜です。 Amazon EC2 R8in および R8ib むンスタンスの䞀般提䟛を開始 – 同じ第 6 䞖代むンテル Xeon Scalable プロセッサず Nitro Card をベヌスに構築されたメモリ最適化むンスタンス。600 Gbps のネットワヌクず 300 Gbps の EBS 垯域幅プロファむルを備えおいたす。倧芏暡な商甚デヌタベヌス、デヌタレむク、SAP HANA などのむンメモリデヌタベヌスに適しおいたす。米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、欧州 (スペむン) で利甚可胜です。 Amazon EC2 C8ine および M8ine むンスタンスの䞀般提䟛を開始 – ネットワヌク最適化むンスタンス。C6in および M6in ず比范しお、最倧 2.5 倍の vCPU あたりのパケットパフォヌマンスず、最倧 2 倍のむンタヌネットゲヌトりェむ経由のトラフィックのネットワヌクスルヌプットを提䟛したす。仮想ファむアりォヌル、ロヌドバランサヌ、5G UPF ワヌクロヌドなどのセキュリティおよびネットワヌク仮想アプラむアンス向けに蚭蚈されおいたす。C8ine は米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (東京) で、M8ine は米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) で利甚可胜です。 Amazon Bedrock AgentCore が最適化機胜を远加 (プレビュヌ) – AgentCore は、本番での゚ヌゞェントの「芳察、評䟡、改善」のサむクルを完了するために、レコメンデヌション、バッチ評䟡、A/B テストを提䟛するようになりたした。レコメンデヌションは、本番のトレヌスず評䟡の出力を分析し、最適化されたシステムプロンプトずツヌルの説明を提案したす。これらは、事前定矩枈みのテストケヌスに察するバッチ評䟡、たたは実際のトラフィックに察する A/B テストで怜蚌できたす。すべおのレコメンデヌションは、リリヌス前に承認が必芁です。 AWS Lambda が Ruby 4.0 のサポヌトを远加 – 最新の LTS リリヌスである Ruby 4.0 が、Lambda マネヌゞドランタむムおよびコンテナベヌスむメヌゞずしお利甚可胜になりたした。JSON 構造化ログ、蚭定可胜なログ蚘録レベル、タヌゲット CloudWatch ロググルヌプ蚭定など、Lambda の高床なログ蚘録コントロヌルのサポヌトを含んでいたす。䞭囜リヌゞョンおよび AWS GovCloud (米囜) を含む、すべおの AWS リヌゞョンで利甚可胜です。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 その他の AWS ニュヌス 興味深いず思われる远加の蚘事やリ゜ヌスをいく぀かご玹介したす: Amazon Q Developer サポヌト終了のお知らせ – Amazon Q Developer IDE プラグむンず有料サブスクリプションのサポヌトは、2027 幎 4 月 30 日に終了したす。お客様は Kiro に移行する期間ずしお 12 か月の猶予がありたす。新芏サむンアップは 2026 幎 5 月 15 日からブロックされたすが、既存のサブスクリプションでは匕き続きナヌザヌを远加できたす。2026 幎 5 月 29 日より、Q Developer Pro では Opus 4.6 が利甚できなくなりたす。Opus 4.5 および他の既存モデルは匕き続き利甚可胜ですが、Opus 4.7 を含む最新のコヌディングモデルは Kiro でのみ利甚可胜です。AWS マネゞメントコン゜ヌルの Amazon Q Developer および AWS 公匏゚クスペリ゚ンス (ドキュメント、モバむルアプリ、Slack、Microsoft Teams) に圱響はありたせん。 AWS 10,000 AIdeas Competition: 受賞者の発衚 – AWS は、ビルダヌが Kiro ず AWS 無料利甚枠のみを䜿甚しお構築された AI アプリケヌションを応募するグロヌバルコンテストである 10,000 AIdeas Competition の受賞者 20 名を発衚したした。115 か囜から応募があり、4 回の審査ず 2 回のコミュニティ投祚を経お遞考されたした。受賞者は、Global Champions、Regional Champions、Innovation Awards、Creative Track の各カテゎリに分かれおおり、各カテゎリで賞金ず AWS クレゞットが授䞎されたす。 AWS Student Builder Groups  â€“ AWS Cloud Clubs は AWS Student Builder Groups に進化したした。コミュニティは珟圚、63 か囜、600 以䞊の倧孊やカレッゞに広がっおいたす。既存の Cloud Club メンバヌシップ、バッゞ、進捗状況は匕き継がれ、Cloud Club Captain は Group Leader になりたす。メンバヌシップは 18 歳以䞊の孊習者であれば誰でも参加できたす。AWS Builder Center で最寄りのグルヌプを探すか、たたはキャンパスで新しいグルヌプを立ち䞊げるための申請をするこずができたす。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう: AWS Summits – AWS Summits は、クラりドず AI をカバヌする無料の実地むベントです。5 月の開催予定: シンガポヌル (5 月 6 日)、 テルアビブ (5 月 6 日)、 ワルシャワ (5 月 6 日)、 ストックホルム (5 月 7 日)、 シドニヌ (5 月 13 日14 日)、 ハンブルク (5 月 20 日)、 ゜りル (5 月 20 日)、 アムステルダム (5 月 27 日)、 ミラノ (5 月 28 日)、 ムンバむ (5 月 28 日)。 AWS Community Days – コミュニティリヌダヌが䌁画および提䟛するコミュニティ䞻導のカンファレンス。今埌のむベントには、 むスタンブヌル (トルコ) (5 月 9 日) ず パナマシティ (パナマ) (5 月 23 日) が含たれおいたす。 AWS Builder Center にアクセスしお、他のビルダヌず亀流したり、゜リュヌションを提䟛したり、構築を継続するのに圹立぀リ゜ヌスを芋぀けたりしたしょう。たた、今埌開催される AWS 䞻導の実地およびオンラむンむベント や、 デベロッパヌ向けセッション もご芧いただけたす。 – Esra この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスや発衚を簡単にたずめお毎週ご玹介したす! 原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 今週は、日本時間 4 月 29 日に開催された  What’s Next with AWS  ã§ç™ºè¡šã•れた倧型のアップデヌトが倚数ありたした。AWS CEO の Matt Garman ず OpenAI のリヌダヌたちが登壇し、AI ゚ヌゞェントが䌁業の業務のあり方をどう倉えおいくかを議論するむベントで、Amazon Quick、Amazon Connect、そしお Amazon Bedrock に関する倚数のアップデヌトが発衚されたした。蚘事埌半のサヌビスアップデヌトずあわせおご芧ください。 生成 AI を掻甚したビゞネス倉革に取り組むお客様を支揎する 生成 AI 実甚化掚進プログラム は匕き続き参加䌁業を募集しおいたす。ご興味のある方はぜひご芧ください。 それでは、4 月 27 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 奈良垂ず日立システムズ様、個人番号利甚事務系の閉域環境で GenU を掻甚し特定保健指導の業務効率化を実珟 奈良垂ず株匏䌚瀟日立システムズ様は、マむナンバヌ系ネットワヌク䞊での生成 AI 掻甚に取り組みたした。個人番号利甚事務系は機埮情報を扱うためむンタヌネットから厳栌に分離されおおり、埓来は倖郚の生成 AI サヌビスを利甚するこずが困難でした。この課題に察し、ガバメントクラりド䞊に  Generative AI Use Cases (GenU)  の閉域モヌドを構築し、Amazon Bedrock を VPC Endpoint 経由で利甚する構成を採甚したした。特定保健指導における面談蚘録䜜成にリアルタむム文字起こしず専甚プロンプトによる 7 項目自動敎圢を適甚した結果、報告曞 1 件の䜜成時間が 1〜2 時間から 30〜60 分に短瞮され、珟堎担圓者党員が業務負担軜枛を実感し、今埌の継続利甚を垌望したした。日立システムズ様が担圓する党囜の自治䜓ぞの暪展開や、母子保健・児童盞談・障害犏祉ずいった同皮業務ぞの応甚が蚈画されおいたす。 ブログ蚘事「 2026 幎「What’s Next with AWS」からの泚目の発衚 」を公開 2026 幎 4 月 29 日に開催された What’s Next with AWS むベントでの䞻芁発衚のたずめ蚘事です。Amazon Quick の新しいデスクトップアプリ・Free/Plus プラン・ビゞュアル生成・倖郚統合拡倧、Amazon Connect の Decisions・Talent・Customer・Health の 4 ゜リュヌション展開、そしお Amazon Bedrock 䞊での OpenAI モデル・Codex・マネヌゞド゚ヌゞェントの提䟛開始限定プレビュヌなど、倧型アップデヌトが俯瞰できたす。本蚘事の埌半のサヌビスアップデヌトずあわせおご芧ください。 ブログ蚘事「 【開催報告】AWS Retail & CPG EXPO 2026 — AI ゚ヌゞェントが倉える流通小売・消費財業界の珟堎を䜓感 」を公開 2026 幎 4 月 20 日に AWS 東京オフィスで開催された、流通小売・消費財業界向け完党招埅制むベントの開催報告ブログです。NRF 2026 で発衚された 7 ぀の AI ゚ヌゞェントデモを日本向けにロヌカラむズしお展瀺するずずもに、株匏䌚瀟コヌセヌ様、株匏䌚瀟 asken 様、株匏䌚瀟ゎヌルドりむン様、株匏䌚瀟カむンズ様の生成 AI 掻甚事䟋セッションが実斜されたした。各瀟ずも「珟堎定着」「Vibe Coding」「経営ず珟堎のギャップ」「生成 AI による画像生成の実店舗掻甚」ず切り口が異なり、業界の AI ゚ヌゞェント実装の珟圚地を知るこずができる内容です。 ブログ蚘事「 補造業 × 生成 AI 、8 瀟の「ここだけの話」が぀ながり課題解決を加速する — AWS 生成 AI ラりンドテヌブル in 倧阪 開催報告 」を公開 2026 幎 3 月 31 日に AWS 倧阪オフィスで開催された、補造業 8 瀟シャヌプ、ダマハ、村田補䜜所、日立産業制埡゜リュヌションズ、コベルコシステム、東掋玡、倧日本印刷、ダむキン工業のクロヌズド・ラりンドテヌブルの開催報告です。瀟内ツヌルの珟堎定着、少人数での AI 掚進䜓制、補造業特有の非構造化デヌタの扱いずいった共通課題に察し、各瀟の実践知が亀換された様子が玹介されおいたす。AWS セッションでは Amazon Bedrock AgentCore ã‚’掻甚した AgentOps の 4 ステップ評䟡フレヌムワヌクも玹介されおいたす。 ブログ蚘事「 Amazon Q Developer のサポヌト終了に関するお知らせ 」を公開 Amazon Q Developer の IDE プラグむンず有償サブスクリプションのサポヌトが 2027 幎 4 月 30 日に終了するこずが発衚されたした。埌継ずなる Kiro ã¯ä»•様駆動開発spec-driven developmentのためにれロから構築された゚ヌゞェント型開発環境で、Specs、Hooks、Steering files、Custom subagents、Powers ずいった機胜を備えおいたす。2026 幎 5 月 15 日以降は新芏サむンアップの受付が停止されたすが、既存ナヌザヌは 2027 幎 4 月 30 日たで利甚可胜です。なお、AWS マネゞメントコン゜ヌルや AWS Console Mobile App、Slack/Microsoft Teams のチャットアプリで提䟛されおいる Amazon Q Developer は今回の察象倖で、匕き続きご利甚いただけたす。 ブログ蚘事「 Amazon Quick を瀟内のナレッゞに接続しよう – Microsoft SharePoint Online ç·š 」を公開 Amazon Quick の AI ゚ヌゞェントを瀟内の SharePoint Online に接続する方法を、ナレッゞベヌス連携AI が怜玢・回答ずアクション連携自然蚀語でリスト・ファむル・Excel を盎接操䜜の 2 ぀のアプロヌチでステップバむステップに解説しおいたす。Entra ID でのアプリ登録方法から ACL を匕き継ぐ Admin-managed setup、コネクタ䜜成の詳现たで扱われおおり、これから SharePoint ず Quick を連携させたい方の導入ガむドずしお最適です。 ブログ蚘事「 Amazon Quick を䜿甚した゚ンタヌプラむズ向けパッチ適甚・むンベントリダッシュボヌドの構築 」を公開 AWS Systems Manager のむンベントリ情報ずパッチ適甚状況を、Amazon Quick の自然蚀語プロンプトで可芖化する゜リュヌションを解説しおいたす。CloudFormation テンプレヌトをデプロむし、「Create a pie chart for count of resourceid by provider」のようなプロンプトでダッシュボヌドを玠早く構築できたす。倚段階の手動操䜜を数回のプロンプトに眮き換える、生成 BI のわかりやすいナヌスケヌスです。 ブログ蚘事「 「NVIDIA Robotics Solutions 勉匷䌚」を開催したした 」を公開 2026 幎 4 月 14 日に開催された、フィゞカル AI 開発支揎プログラム採択䌁業向けの勉匷䌚の開催報告です。NVIDIA の Isaac Sim / Isaac Lab / Cosmos / GR00T ずいったロボティクス向け技術スタックの玹介に加え、Physical AI 開発の各フェヌズデヌタ生成、モデル孊習、モデル配信に最適な Amazon EC2 むンスタンスG6e/G7e、P5、P5en/P6-B200 などの遞び方、AWS CDK でデプロむできる開発環境サンプル Remote AWS Develop Station (RADS) が玹介されおいたす。 サヌビスアップデヌト What’s Next with AWS 関連 Amazon Bedrock で OpenAI モデル、Codex、マネヌゞド゚ヌゞェントを提䟛開始限定プレビュヌ AWS ず OpenAI のパヌトナヌシップ拡倧により、Amazon Bedrock で 3 ぀の新しいサヌビスが限定プレビュヌ提䟛されたす。1 ぀目は GPT-5.5 / GPT-5.4 を含む最新の OpenAI モデルぞのアクセス、2 ぀目は OpenAI のコヌディング゚ヌゞェントを AWS 環境で利甚できる Codex on Amazon Bedrock、3 ぀目は本番環境察応の OpenAI 搭茉゚ヌゞェントを迅速にデプロむできる Amazon Bedrock Managed Agents です。いずれも IAM、AWS PrivateLink、ガヌドレヌル、CloudTrail ログ蚘録など Bedrock の䌁業向け制埡機胜を匕き継いでおり、远加のむンフラ構築なしに利甚できるのが特城です。本機胜矀は、本蚘事の執筆時点ではAmazon Bedrock を通じた限定プレビュヌずしお利甚可胜であり、アクセスは蚱可リストに登録された初期の組織に限定されおいたす。 Amazon Bedrock AgentCore が゚ヌゞェントパフォヌマンスを最適化する機胜をリリヌスプレビュヌ Amazon Bedrock AgentCore に、レコメンデヌション・バッチ評䟡・A/B テストの 3 ぀の機胜がプレビュヌ远加されたした。本番環境のトレヌスず評䟡出力を分析しお、ワヌクロヌド最適化されたシステムプロンプトやツヌル蚘述を提案し、バッチ評䟡で怜蚌、さらに A/B テストで統蚈的有意性を確認するたでの改善サむクルを閉じるこずができたす。モデルの進化やナヌザヌ動䜜の倉化に䌎っお゚ヌゞェントの品質が䜎䞋しおいくのを防ぐのに圹立぀アップデヌトです。AgentCore Evaluations が利甚可胜なすべおの AWS リヌゞョンで䜿甚できたす。 Amazon Bedrock AgentCore Identity が On-Behalf-Of (OBO) トヌクン亀換のサポヌトを開始 Amazon Bedrock AgentCore Identity で、認蚌されたナヌザヌに代わっお保護リ゜ヌスぞアクセスする゚ヌゞェントを構築できる OBO トヌクン亀換が䞀般提䟛されたした。アクセストヌクンを暩限を絞り蟌んだ新しいアクセストヌクンに亀換し、元のナヌザヌ ID ず゚ヌゞェント ID の䞡方を保持したゞャストむンタむムか぀最小暩限のアクセスを付䞎できたす。アゞアパシフィック東京を含む 14 リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore Runtime が Node.js のサポヌトを開始 AgentCore Runtime が Python に加えお Node.js をマネヌゞド型蚀語ランタむムずしおサポヌトしたした。゚ヌゞェントコヌドず䟝存関係を .zip アヌカむブにパッケヌゞしおアップロヌドするだけでデプロむできたす。TypeScript プロゞェクトや Strands Agents SDK で構築した゚ヌゞェントも察象で、セッション分離、SigV4/OAuth 2.0 認蚌、双方向ストリヌミング、CloudWatch オブザヌバビリティずいった機胜を Python ず同様に利甚できたす。 Amazon Quick のデスクトップアプリケヌションが macOS・Windows で提䟛開始プレビュヌ Amazon Quick が macOS ず Windows のネむティブデスクトップアプリずしおプレビュヌ提䟛されたした。ブラりザ倖でロヌカルファむル、カレンダヌ、コミュニケヌションツヌルぞの接続を維持しながら、OS レベルのプロアクティブ通知やネむティブコントロヌルを掻甚できたす。ビルダヌ向けには、コヌディング゚ヌゞェントぞのロヌカルの MCP 接続にも察応しおいたす。米囜東郚バヌゞニア北郚の Quick サブスクラむバヌが察象です。 Amazon Quick に Free および Plus 料金プランが登堎 Amazon Quick の Free および Plus プランでは、個人のメヌルアドレスたたは Google / Apple / GitHub / Amazon の認蚌情報で数分でサむンアップでき、AWS アカりントが䞍芁になりたした。ガむド付きのオンボヌディング䜓隓が甚意されおおり、営業、マヌケティング、財務、オペレヌションなど圹割別のワヌクフロヌを通じお短時間で䟡倀を䜓感できたす。 Amazon Quick でチャットを利甚したドキュメントずビゞュアルの䜜成が可胜に Amazon Quick のチャットから、ドキュメント・プレれンテヌション・スプレッドシヌト・画像・むンフォグラフィックなどを䌚話を䞭断せずに䜜成できるようになりたした。Word、PDF、PowerPoint、Excel などの圢匏でダりンロヌド可胜です。ビゞュアル䜜成はプレビュヌ提䟛で、ドキュメント䜜成は Quick が提䟛されるすべおの AWS リヌゞョンで利甚可胜です。 Amazon Quick で Google Workspace、Zoom、Airtable などずの統合を拡倧 Gmail、Google スプレッドシヌト、Google ドキュメント、Google カレンダヌ、Google Drive、Google スラむド、Google Meet、Google アナリティクス、Zoom、QuickBooks、Airtable、Dropbox、Microsoft Teams に察応した 13 個の組み蟌みアクションコネクタが远加されたした。マネヌゞド認蚌に察応しおおり、数クリックで接続できたす。 Amazon Quick で Microsoft Excel・PowerPoint 拡匵機胜を远加、Word 拡匵機胜を曎新プレビュヌ Microsoft 365 の Excel、PowerPoint、Word に察応した新芏およびアップグレヌド版の拡匵機胜がプレビュヌ提䟛されたした。ピボットテヌブルやグラフの䜜成、テンプレヌトを䜿ったプレれンテヌション䜜成、倉曎履歎を有効にしたたたの䞀括線集などが可胜です。米囜東郚バヌゞニア北郚、米囜西郚オレゎン、アゞアパシフィックシドニヌ東京、欧州アむルランドフランクフルトロンドンで利甚可胜です。 Amazon Quick で自然蚀語を䜿ったカスタムアプリケヌションの構築が可胜にプレビュヌ コヌディング䞍芁で、自然蚀語で必芁な内容を蚘述するだけでむンタラクティブなりェブアプリケヌションを䜜成できる機胜がプレビュヌ提䟛されたした。ラむブデヌタ゜ヌスに接続し、AI を掻甚した機胜を組み蟌んで、ワンクリックでチヌムに公開できたす。営業・マヌケティング・財務チヌム向けの瀟内ツヌルを迅速に䜜るのに有甚です。 AWS が Amazon Connect Decisions を発衚 サプラむチェヌンチヌム向けの゚ヌゞェンティック AI 蚈画・むンテリゞェンス゜リュヌション Amazon Connect Decisions が䞀般提䟛されたした。Amazon の 30 幎にわたる運甚知芋ず 25 を超える専甚サプラむチェヌンツヌルを組み合わせた AI チヌムメむトが、需芁シグナルの統合、制玄を考慮した䟛絊蚈画、差異怜出、自動根本原因分析を 24 時間 365 日行いたす。米囜東郚バヌゞニア北郚および欧州アむルランドで利甚可胜です。 AI を掻甚した採甚を支揎する Amazon Connect Talentプレビュヌ Amazon の採甚ノりハりを螏たえた、AI ゚ヌゞェントによる音声面接・科孊的根拠に基づくアセスメント・䞀貫した候補者スコアリングを実珟する Amazon Connect Talent のプレビュヌが開始されたした。候補者はあらゆるデバむスから 24 時間 365 日面接を受けられ、採甚担圓者は AI が生成したスコア・文字起こし・評䟡を確認できたす。米囜東郚バヌゞニア北郚、米囜西郚オレゎンで利甚可胜です。 サヌビスアップデヌト – そのほかのアップデヌト Gemma 4 モデルが Amazon SageMaker JumpStart で利甚可胜に Google DeepMind の Gemma 4 E4B、Gemma 4 26B-A4B、Gemma 4 31B の 3 ぀のむンストラクションチュヌニングモデルが SageMaker JumpStart で利甚可胜になりたした。組み蟌みの掚論モヌド思考、画像・動画理解、ネむティブ関数呌び出し、140 以䞊の蚀語での倚蚀語サポヌトずいった機胜を備えおおり、SageMaker Studio の Models セクションから数クリックでデプロむできたす。 Paraphrase-multilingual-MiniLM-L12-v2、Table Transformer、Bielik-11B-v3.0-Instruct が SageMaker JumpStart で利甚可胜に 倚蚀語セマンティック類䌌性モデル、PDF やスキャン画像からテヌブルを怜出するオブゞェクト怜出モデル、ポヌランド語を含むペヌロッパ蚀語に特化した 110 億パラメヌタのモデルの 3 ぀が JumpStart に远加されたした。 Amazon SageMaker HyperPod で G7e および r5d.16xlarge むンスタンスをサポヌト SageMaker HyperPod で、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭茉した G7e むンスタンスず、メモリ倧容量の r5d.16xlarge がサポヌトされたした。G7e は G6e 比で最倧 2.3 倍の掚論パフォヌマンスず最倧 768GB の GPU メモリを備え、LLM や゚ヌゞェンティック AI、マルチモヌダル生成 AI、物理 AI モデルのデプロむに適しおいたす。G7e は米囜東郚バヌゞニア北郚オハむオ、米囜西郚オレゎン、アゞアパシフィック東京で利甚可胜です。 Amazon ECS マネヌゞドむンスタンスが NVIDIA GPU メトリクスのサポヌトを開始 Amazon ECS マネヌゞドむンスタンスで実行するコンテナ化ワヌクロヌドの GPU 容量・䜿甚率・メモリ・ハヌドりェア状態・枩床を、匷化されたオブザヌバビリティを備えた Amazon CloudWatch Container Insights で確認できるようになりたした。AI/ML のトレヌニングや掚論ずいった GPU アクセラレヌションワヌクロヌドに圱響が出る前に問題を怜出するのに圹立ちたす。すべおの商甚 AWS リヌゞョンで利甚可胜です。 AWS Neuron SDK が Trainium での NKI カヌネル開発甚の Neuron Agentic Development を提䟛 AWS Trainium / Inferentia 向けのカスタム蚈算カヌネルを開発する Neuron Kernel Interface (NKI) 甚に、AI コヌディングアシスタント向けの゚ヌゞェントずスキルのオヌプン゜ヌスコレクション Neuron Agentic Development がリリヌスされたした。Claude Code や Kiro などの゚ヌゞェント IDE から、PyTorch 操䜜を説明しお NKI カヌネルを䜜ったり、コンパむル゚ラヌの自動修正、パフォヌマンスボトルネック分析たでを自然蚀語で䟝頌できたす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近の趣味はカメラです。 週刊 AWS の新しいサムネむルを撮圱したので、是非ご芧ください。
AWS X-Ray は、アプリケヌショントレヌスの蚈装 (instrumentation) においお、業界暙準である OpenTelemetry ぞの移行を掚進しおいたす。今埌、アプリケヌションからトレヌスを生成し AWS X-Ray に送信する方法ずしおは、OpenTelemetry ベヌスの蚈装゜リュヌションが掚奚されたす。X-Ray の既存のコン゜ヌル䜓隓ず機胜は匕き続き完党にサポヌトされ、この移行によっお倉曎されるこずはありたせん。 OpenTelemetry は、トレヌス蚈装ずオブザヌバビリティにおける業界暙準のオヌプン゜ヌスプロゞェクトであり、テレメトリデヌタを収集・ルヌティングするための暙準化されたプロトコルずツヌルを提䟛したす。メトリクス、ログ、トレヌスずいったアプリケヌションのテレメトリデヌタを蚈装・生成・収集・゚クスポヌトし、監芖プラットフォヌムで分析・むンサむト取埗を行うための統䞀フォヌマットを提䟛したす。これにより、機胜開発の高速化や、業界党䜓で䞀貫したより広範なツヌルやむンテグレヌションの利甚が可胜になりたす。OpenTelemetry の蚈装゜リュヌションは、フレヌムワヌクやラむブラリぞのより幅広いサポヌト、倚蚀語察応、そしおコヌドを倉曎せずに蚈装を远加できるれロコヌド蚈装 (zero-code instrumentation) 機胜を備えおいたす。 AWS X-Ray SDK ず Daemon は、メンテナンスモヌドぞず移行したす。このフェヌズでは、AWS は SDK ず Daemon のリリヌスをセキュリティ䞊の問題ぞの察応のみに限定したす。SDK / Daemon は機胜远加は行われたせん。ただしメンテナンスモヌドにおいおも、X-Ray は既存の X-Ray SDK / Daemon から送信されるトレヌスの受信・凊理を継続したす。AWS X-Ray サヌビス自䜓は匕き続き完党にサポヌトされ、 ネむティブ OpenTelemetry サポヌト や Amazon CloudWatch Transaction Search ずいった機胜拡匵は継続したす。Transaction Search は、X-Ray のすべおの機胜に加え、アプリケヌションパフォヌマンスモニタリング (APM) や Amazon CloudWatch Application Signals の機胜セットをたずめた新しいコスト効率に優れた料金䜓系を提䟛したす。今埌の新機胜開発は OpenTelemetry ベヌスの゜リュヌションに泚力する䞀方、既存機胜はこれたでどおり動䜜し続けたす。たずえば、SDK には新たなラむブラリ蚈装の远加や既存ラむブラリ蚈装の機胜拡匵は行われたせん。 X-Ray SDK / Daemon のラむフサむクルずサポヌトレベル SDK ラむフサむクルフェヌズ 開始日 終了日 サポヌトレベル 䞀般提䟛 (General Availability) N/A 2026 幎 2 月 25 このフェヌズでは、SDK / Daemon は完党にサポヌトされたす。AWS はバグ修正ずセキュリティ䞊の問題修正を含む通垞の SDK / Daemon リリヌスを提䟛したす。 メンテナンスモヌド 2026 幎 2 月 25 日 N/A AWS は SDK / Daemonのリリヌスをセキュリティ䞊の問題ぞの察応のみに限定したす。SDK / Daemon は新機胜の远加を受けたせん。 移行を支揎するため、AWS X-Ray のドキュメントで移行ガむドずサンプルを提䟛しおいたす。 https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html AWS Distro for OpenTelemetry (ADOT) たたは Amazon CloudWatch ず連携するネむティブ OpenTelemetry に移行するず、アプリケヌションのヘルスモニタリングを匷化する CloudWatch Application Signals や、アプリケヌションのトランザクションスパンを完党に可芖化する Transaction Search ずいった匷力なツヌルを利甚できるようになりたす。 OpenTelemetry、および OpenTelemetry を掻甚する AWS CloudWatch の゜フトりェア゜リュヌションに぀いお、詳しくは以䞋を参照しおください。 Amazon CloudWatch with OpenTelemetry — OpenTelemetry を甚いたアプリケヌションで CloudWatch を利甚し、 Application Signals や Transaction Search などの匷力な機胜を有効化する方法を解説 X-Ray による蚈装から OpenTelemetry による蚈装ぞの移行 — AWS Distro for OpenTelemetry (ADOT) たたは OpenTelemetry SDK ぞの切り替え䟋を掲茉 OpenTelemetry 公匏ドキュメント — OpenTelemetry の利甚方法党般を解説 フィヌドバック サポヌトやフィヌドバックが必芁な堎合は、AWS サポヌトたでご連絡ください。 https://aws.amazon.com/jp/contact-us/ たた、GitHub 䞊でディスカッションや Issue を䜜成するこずもできたす ( Java 、 Python 、 JavaScript 、 .NET 、 Go 、 Ruby )。 AWS X-Ray SDK / Daemon をご利甚いただきありがずうございたす。 著者に぀いお Jonathan Lee Jonathan Lee は AWS Application Observability の゜フトりェア開発゚ンゞニアです。OpenTelemetry のアップストリヌムおよび AWS Distro for OpenTelemetry (ADOT) の䞡方にコントリビュヌトしおいたす。 Naina Thangaraj Naina Thangaraj は AWS Batch のシニアプロダクトマネヌゞャヌで、AWS の Advanced Computing and Simulation 郚門に所属しおいたす。バむオむンフォマティクスのバックグラりンドを持ち、AWS 入瀟以前はヘルスケア・ラむフサむ゚ンス業界で業務に埓事しおいたす。 本ブログは 2025 幎 11 月 14 日に公開された AWS X-Ray SDKs/Daemon migration to OpenTelemetry の日本語蚳です。翻蚳はテクニカルアカりントマネヌゞャヌの日平が行いたした
On Monday, April 20, 2026, AWS held the invitation-only event “AWS Retail & CPG EXPO 2026 — Build the future with AI” at the AWS Tokyo office. We welcomed more than 100 guests from over 60 companies, and the event concluded on a high note. We localized AI agent demos for the Japanese market, providing an opportunity to see, touch, and experience them firsthand. A networking reception was also held from 6:00 PM, offering attendees a chance to connect with one another. For those who were unable to attend, we would like to share the highlights of the event through this blog post. The Future of the Industry, Transformed by AI Agents The age of AI is evolving into the age of AI agents. We are now in an era where the key question is how autonomously we can deploy AI agents and apply them to our business operations. Alongside the platforms that enable AI agents to operate safely, a critical theme has emerged: how to leverage them in the retail, consumer goods, and food service industries. However, in Japan, there is a prevailing reality of “we understand, but we can’t move forward.” This event was designed to help break through that barrier — giving attendees the chance to experience real, working AI agents and discover their next steps from the case studies of companies that are taking on the challenge. Exhibition Area — Experience Real AI Agents In the exhibition area, we localized demos announced at NRF 2026 for the Japanese market and presented 4 categories across 7 booths, aligned with retail, consumer goods, and food service industry workflows: product development & production planning, pricing strategy, supply chain, and in-store/online customer experience. A common concept across all demos was “Multi-Agent × Human-in-the-Loop.” Attendees experienced through live demos the design principle where AI agents collaborate autonomously while humans make the critical decisions. Detailed materials for each exhibit can be downloaded from the links in each exhibit description below. If any exhibit caught your interest, please feel free to contact your account representative to arrange a private demo. Merchandising — Product Development & Pricing Strategy Product development and pricing strategy are critical areas that determine a company’s competitiveness. We showcased two multi-agent demos. Luggage Lab: Attendees saw a demo where three agents — Researcher, Designer, and Planner — collaborate to accelerate product innovation. ( Luggage Lab detailed materials ) Luggage Lab — Agent Role Diagram Luggage Lab — Architecture Retail Pricing Agent: We presented a demo where three agents — Competitive Research, Demand Analysis, and Price Decision — collaborate to automate pricing strategy using generative AI. ( Retail Pricing Agent detailed materials ) Retail Pricing Agent — Process Flow Retail Pricing Agent — Architecture Supply Chain — Autonomous Response to Disruptions Supply chain disruptions are a constant and significant risk for the retail, consumer goods, and food service industries. Attendees experienced a scenario where multiple agents collaborate to gather information and propose countermeasures, while humans make the final decisions. Agentic Supply Chain: We exhibited a demo where four agents — Procurement, Inventory, Planning, and Logistics — collaborate, with AI agents autonomously responding to supply chain disruptions. ( Agentic Supply Chain detailed materials ) Agentic Supply Chain — Specialized Agent Team Structure Agentic Supply Chain — Architecture Omnichannel — Transforming the Customer Experience Seamlessly connecting digital and physical stores is a critical theme for the industry. We introduced three demos showcasing new customer experiences where AI provides personalized engagement for each individual. Smart Beauty: This demo uses image analysis to classify skin types into 16 detailed categories and automates improvement recommendations. AI replicates the expertise of beauty consultants. ( Smart Beauty detailed materials ) Smart Beauty — Skin Type + Personal Color Analysis Smart Beauty — Architecture Fix&Fab: Attendees saw a demo that generates DIY repair instructions from just a photo and description, and even provides shopping lists and expert referrals. ( Fix&Fab detailed materials ) Fix&Fab — Project Design from a Single Photo Fix&Fab — Architecture Retail AI Concierge: We presented a demo that delivers a seamless journey from e-commerce to physical stores — from product recommendations and inventory checks to event guides and visit planning. ( Retail AI Concierge detailed materials ) Retail AI Concierge — A New Customer Experience Retail AI Concierge — Architecture Product Innovation — Next-Generation Personalization Returns and sizing challenges are major themes across the industry, whether in e-commerce or physical stores. Bodd: We exhibited a demo featuring Bodd’s contactless body scanning technology that delivers precise measurements in just 60 seconds, enabling cross-brand size recommendations. Bodd — Precise Measurements via Body Scanning Bodd — Customer Journey If any exhibit caught your interest, please feel free to contact your account representative to arrange a private demo. Sessions — Learning from Companies Taking on the Challenge The sessions consisted of AWS opening sessions (2 sessions), customer case studies (4 sessions), and an AWS session (1 session). AWS Opening Sessions Keanu Nahm — Common Success Factors in AI Adoption Seen from a Global Perspective, and the Opportunities for Japan’s Retail & CPG Industry Keanu Nahm (Head of AWS Global Retail & CPG Business Development, Japan) drew on trends from NRF 2026 and ShopTalk 2026 to describe how the global retail and consumer goods industry is transitioning from a “year of experimentation” to a “year of implementation” with AI. He identified three conditions for AI to be adopted broadly and deeply: “ease of use (zero friction),” “trustworthiness,” and “becoming a habit,” and highlighted the opportunities this presents for Japan’s retail and consumer goods industry. (Session materials are available for download here .) Kempei Igarashi — Experience How AI Agents Are Transforming the Retail Frontline, and Find Your Next Step from the Case Studies of Companies Taking on the Challenge Kempei Igarashi (Head of Industry Solutions Division, AWS) shared AWS’s perspective on the current state of AI agents and the trend of AI agents evolving from “tools” to “colleagues,” and provided an overview of the event’s exhibitions and sessions. (Session materials are available for download here .) Customer Case Study Sessions KOSÉ Corporation — KOSÉ’s Challenge: Company-Wide Deployment of Generative AI — Building a Framework for Frontline Adoption Haruka Yokoyama, Generative AI Promotion Leader, DX Promotion Section, Information Management Department Miku Kaneda, Generative AI Promotion, Infrastructure Development Section, Information Management Department KOSÉ Corporation presented their case study on company-wide deployment of generative AI, driven by the awareness that “even a great system doesn’t mean everyone can use it effectively.” Led by the Information Management Department, they simultaneously advanced system development and user support/education. They created an environment that encourages voluntary adoption through intuitive UI design, easy model selection, and gamification-driven engagement. With the support of AWS’s Prototyping team, they built the platform in just one month and shared how generative AI has become a “common language” across the organization. asken, Inc. — The Walls “asken” Overcame in Developing New Features Starting from Vibe Coding Takuya Ito, Senior Product Manager, AX Promotion Department, Product Development Division Yoshihiro Iwama, Senior Tech Lead, Product Development Department, Product Development Division asken, Inc., the company behind the meal management app “asken,” presented on a new co-creation process between product managers and engineers. Product managers use Vibe Coding to create “working PRDs (prototypes)” and run user validation cycles on the AWS-based experimentation platform “asken Lab.” However, they also shared the “painful lesson” of development costs tripling when they tried to use the working PRD directly in production. From that failure, they established a refinement process leveraging AI-powered reverse engineering, arriving at a “design of sequence and boundaries” that allows product managers and engineers to maximize their respective expertise. GOLDWIN Inc. — AI: We Understand, But Can’t Move Forward — How to Bridge the Gap Between the Frontline and Management Takahiro Suemitsu, Senior Expert, Corporate Planning Division GOLDWIN Inc. addressed the problem many companies face: “AI gets stuck at search and summarization.” They identified five barriers preventing AI from reaching implementation (ambiguous management expectations, lack of bandwidth on the frontline, absence of success metrics, etc.) and visualized the “invisible gap” between management and the frontline. As a breakthrough, they advocated the approach of “showing something that works rather than explaining with a proposal,” and introduced a case where they built a prototype in just one day. The message that resonated most was: “The phase of explaining and waiting for understanding is over. Let’s make 2026 the year we embed AI into our operations.” CAINZ Corporation — The Fitting Room Experience Realized in Next-Generation Stores Takehiko Suga, General Manager, CX Management Department, Information Systems Division, CAINZ Corporation Tsuyoshi Mukai, Manager, E-Business Engineering Section, Digital Engineering Department, Digital Transformation Division, AsiaQuest Inc. CAINZ Corporation and AsiaQuest Inc. presented their “CAINZ Fitting Room” initiative, addressing the in-store purchasing challenge of “not being able to try before you buy” using generative AI. While they had previously attempted to visualize room coordination, reproducing textures had been a challenge. With advances in generative AI, they solved this using image generation powered by Amazon Bedrock. Furniture and curtains can now be virtually placed in room images, with realistic textures and shadow reflections. The experience is currently available on in-store touch panels, and future plans include allowing customers to check arrangements using photos of their own rooms and AI-generated coordination recommendations. This initiative was also featured in Mynavi TECH+ . AWS Session Koji Matsumoto — Transforming Advertising & Marketing in the Agentic AI Era Koji Matsumoto (Principal Business Development Manager, Strategic Business Development Division, AWS) explained three “tectonic shifts”: the rapid growth of retail media, the rise of Agentic AI, and the gap between AI investment and implementation. He introduced the latest trends in the democratization of advertising and marketing through Agentic AI — including Amazon Ads’ Creative Agent and Unified Campaign Manager — along with three recommended actions. (Session materials are available for download here .) Thank You for Attending Thank you to everyone who attended AWS Retail & CPG EXPO 2026. AI agents are beginning to take a central role in business operations. The world is already moving. Your company’s transformation starts with today’s “this could work.” Start small, and AWS will be right there with you. For those who were unable to attend, please feel free to reach out to your AWS representative. We look forward to seeing AI agents come to life at your workplace. Event Information Event: AWS Retail & CPG EXPO 2026 — Build the Future with AI Format: Invitation-only Date: Monday, April 20, 2026, 1:00 PM – 6:00 PM JST Venue: AWS Tokyo Office Attendees: More than 100 guests from over 60 companies Organizer: Amazon Web Services Japan G.K. This blog post was translated by Tomo Yamashita, Solutions Architect at AWS Japan. The original post is available here .
「瀟内のドキュメント、どこにあったかな」「ストレヌゞのあのファむルの内容、AI に聞けたら䟿利なのに 」 倚くの䌁業が瀟内ナレッゞをさたざたなストレヌゞツヌル䞊に保管しおいたす。蓄積された膚倧な情報を効率よく掻甚するのは簡単ではありたせん。 Amazon Quick なら、組織に散らばり保存された瀟内ナレッゞを AI ゚ヌゞェントに接続し、自然蚀語で質問するだけで必芁な情報を匕き出せたす。 本ブログでは、Amazon Quick の AI ゚ヌゞェントを瀟内ナレッゞぞ接続する䟋ずしお、Microsoft SharePoint Online以䞋、SharePoint ず蚘茉での連携方法を取り䞊げたす。ナレッゞベヌス連携ずアクション連携の、2 ぀のアプロヌチに぀いお、セットアップ手順をステップバむステップで解説したす。 2 ぀の連携方匏の違い Amazon Quick の SharePoint 連携には、目的の異なる 2 ぀のタむプがありたす。甚途に応じお遞択、たたは䞡方を組み合わせお䜿甚できたす。 ナレッゞベヌス連携 アクション連携 できるこず SharePoint 䞊のドキュメントを AI が怜玢・回答 (同期時点での情報を取埗) SharePoint のリスト・ファむル・Excel を自然蚀語で操䜜 (リアルタむム) デヌタの流れ Amazon Quick が定期クロヌル → むンデックス化 → AI 怜玢 ナヌザヌの操䜜リク゚スト → Graph API → SharePoint ナヌスケヌス 瀟内芏皋怜玢、技術文曞 Q&A、プロゞェクトナレッゞ ファむル取埗、リスト曎新、Excel 読み曞き 1. ナレッゞベヌス連携Knowledge Base Integration ナレッゞベヌス連携では、SharePoint 䞊のドキュメントを Amazon Quick が自動的にクロヌル・むンデックス化し、AI ゚ヌゞェントが怜玢・回答できるようにしたす。Entra ID のアプリ登録は䞍芁で、SharePoint にサむンむンするだけで接続が完了したす。 SharePoint 偎のドキュメントレベルのアクセス制埡ACLをナレッゞベヌスに匕き継ぎたい堎合は、Admin-managed setupサヌビス資栌情報による構成が必芁です。詳现は本セクション末尟の 補足: ドキュメントレベルのアクセス制埡ACLが必芁な堎合 を参照しおください。 詳现な手順は公匏ドキュメント Microsoft SharePoint ナレッゞベヌスの統合 も参照しおください。 1-1. Amazon Quick でナレッゞベヌス䜜成りィザヌドを開く Amazon Quick コン゜ヌルの巊ナビゲヌション → 「ナレッゞ」 を遞択 「Microsoft SharePoint Online」 の远加ボタンをクリック 1-2. SharePoint にサむンむンする 事前に管理者の組織同意が必芁です ナレッゞベヌス統合の際には、Microsoft Entra の管理者が䞀床だけサむンむンしお「組織の同意」を付䞎する必芁がありたす。管理者が同意しおいない状態で䞀般ナヌザヌがサむンむンするず、「管理者の承認が必芁」画面が衚瀺され、先に進めたせん。 組織の同意を付䞎するず 、Microsoft Entra はテナントに゚ンタヌプラむズアプリケヌションサヌビスプリンシパルを自動的に䜜成したす。過去に無効化しおいた堎合は、再床有効にしおアクセスを埩元しおください。同意時に付䞎されるアクセス蚱可の詳现は、 Amazon Quick ナヌザヌガむド: SharePoint ナレッゞベヌスの前提条件 を参照しおください。 「Sign in to SharePoint」 ボタンをクリック Microsoft のサむンむン画面が衚瀺されるので、SharePoint にアクセスできるアカりントでサむンむン アクセス蚱可を承認 1-3. Amazon Quick でむンデックスするコンテンツを遞択する ナレッゞベヌスの 名前 ず 説明 任意を入力 「Add content」 ボタンをクリック 取り蟌みたい特定のサむトやドキュメントフォルダ、ペヌゞなどを遞択し、 「Add」 をクリック 「Create」 をクリック 䜜成埌、初回の同期が自動的に開始される 1-4. Amazon Quick で AI ゚ヌゞェントにナレッゞベヌスを接続する 䜜成したナレッゞベヌスを、Amazon Quick の AI ゚ヌゞェントが掻甚できるようにしたす。 方法 A: スペヌス経由 巊ナビゲヌション → 「スペヌス」 → 察象のスペヌスを開く ナレッゞベヌスをスペヌスに远加 スペヌスをカスタム AI ゚ヌゞェントにリンク 方法 B: チャットから盎接 チャットフッタヌの ナレッゞ アむコンを遞択 䜜成した SharePoint ナレッゞベヌスを盎接スコヌプに远加、たたは「すべおのデヌタ」(ナレッゞベヌスは自動利甚) を遞択 補足: ドキュメントレベルのアクセス制埡ACLが必芁な堎合 䞊蚘の Quick setup で Amazon Quick が SharePoint コンテンツのむンデックスを䜜成する堎合、SharePoint からのアクセスコントロヌルリストACLは同期されたせん。むンデックス付きコンテンツはすべお、SharePoint のアクセス蚱可に関係なく、Amazon Quick のナレッゞベヌスにアクセスできるすべおのナヌザヌがアクセスできたす。ナレッゞベヌスの䜜成時に含めるコンテンツを確認しおください。 SharePoint 偎のアクセス暩限をナレッゞベヌスに匕き継ぎたい堎合は、 Admin-managed setupサヌビス資栌情報 を䜿甚したす。セットアップは以䞋の 2 ぀のフェヌズで構成されたす。 フェヌズ 1: サヌビス資栌情報のセットアップ KMS 眲名鍵の䜜成、蚌明曞の生成、Entra ID ぞのアプリケヌション登録、Amazon Quick ぞの鍵のアクセス暩付䞎を行いたす。具䜓的には、以䞋の構成が必芁です。 AWS KMS で非察称眲名鍵RSA_2048を䜜成する KMS 公開鍵を䜿っお自己眲名蚌明曞を生成する Microsoft Entra ID にアプリケヌションを登録し、蚌明曞をアップロヌドする Entra ID アプリに SharePoint のアプリケヌション暩限を付䞎する詳现は䞋蚘参照 Amazon Quick に KMS 鍵ぞのアクセス暩を付䞎する Entra ID アプリぞの SharePoint アプリケヌション暩限付䞎に぀いお 以䞋の 2 ぀のパタヌンから 1 ぀を遞択しお適甚したす混圚䞍可。 All sitesACL クロヌルあり Microsoft Graph: Sites.Read.All Microsoft Graph: User.Read.All Microsoft Graph: GroupMember.Read.All SharePoint REST: Sites.FullControl.All Selected sitesACL クロヌルあり Microsoft Graph: Sites.Selected Microsoft Graph: User.Read.All Microsoft Graph: GroupMember.Read.All SharePoint REST: Sites.Selected Sites.Selected を遞んだ堎合は、Microsoft Graph API を通じお察象サむトごずに個別の暩限付䞎が必芁です。 詳现は Set up service credentials を参照しおください。 フェヌズ 2: Amazon Quick でナレッゞベヌスを䜜成 フェヌズ 1 で取埗したサヌビス資栌情報を䜿甚しお、SharePoint ナレッゞベヌスを䜜成したす。 詳现は Create the knowledge base in Amazon Quick を参照しおください。 この構成により、Amazon Quick が SharePoint の ACL を自動同期し、ク゚リ時にナヌザヌのアクセス暩をリアルタむムで怜蚌したす。ナヌザヌは自分がアクセス暩を持぀ドキュメントからのみ回答を埗るこずができたす。 泚意 : ACL 管理はナレッゞベヌス䜜成埌に倉曎できたせん。ACL が必芁かどうかは、䜜成前に怜蚎しおください。 ドキュメントレベルのアクセス制埡の仕組みに぀いおは、 Document-level access controls を参照しおください。 2. アクション連携Action Integration アクション連携では、Microsoft Graph API を介しお SharePoint のリスト、アむテム、ファむル、Excel ワヌクブックを自然蚀語で盎接操䜜できたす。ナヌザヌごずの OAuth 認蚌を䜿うため、各ナヌザヌの暩限に基づいたアクセス制埡が自動的に適甚されたす。 ナレッゞベヌス連携ずは異なり、事前に Microsoft Entra ID でのアプリ登録が必芁です。連携を䜜成するず、その事前䜜成された連携を利甚しお、ナヌザヌ自身の認蚌でアクションを利甚するこずが可胜ずなりたす。 詳现な手順は公匏ドキュメント Microsoft SharePoint アクション統合 も参照しおください。 事前準備 以䞋の管理者暩限を䜿甚し、2-1 から 2-5 を事前に実斜する必芁がありたす。 Microsoft Entra ID旧 Azure ADのアプリ登録暩限 Amazon Quick の管理者たたは Author 暩限 2-1. Microsoft Entra 管理センタヌでアプリを登録する Microsoft Entra 管理センタヌ でアプリケヌションの登録を行いたす。 正匏な手順に぀いおは Microsoft 公匏ドキュメント: Microsoft ID プラットフォヌムにアプリケヌションを登録する を参照しおください。 「アプリの登録」 → 「新芏登録」 を遞択 アプリ名を蚭定䟋: QuickSharePointIntegration  「サポヌトされおいるアカりントの皮類」で 「シングルテナントのみ」 を遞択任意で指定 「リダむレクト URI」で 「Web」 を遞択し、以䞋の URL を入力 https://{リヌゞョン}.quicksight.aws.amazon.com/sn/oauthcallback {リヌゞョン} は Amazon Quick のリヌゞョンに眮き換え䟋: 東京なら ap-northeast-1  「登録」 をクリック 登録埌、 抂芁ペヌゞ に衚瀺される以䞋の倀を控えおおきたす。Amazon Quick 偎の蚭定で䜿甚したす。 アプリケヌションクラむアントID ディレクトリテナントID ポむント : 耇数リヌゞョンで Amazon Quick を利甚する堎合は、リダむレクト URI を耇数登録しおください。登録したアプリ → 「認蚌」 からリダむレクト URI を远加できたす。 2-2. Microsoft Entra 管理センタヌでクラむアントシヌクレットを䜜成する 登録したアプリ → 「蚌明曞ずシヌクレット」 を遞択 「新しいクラむアントシヌクレット」 を遞択 説明ず有効期限最倧 730 日を蚭定し、远加 衚瀺された 「倀」 をコピヌしお安党に保管 重芁 : シヌクレットの「倀」は䜜成盎埌しか衚瀺されたせん。この画面を閉じるず二床ず確認できないため、必ずこのタむミングでコピヌしおください。Amazon Quick に蚭定するのは 「シヌクレット ID」ではなく「倀」 の方です。 2-3. Microsoft Entra 管理センタヌで゚ンドポむント URL を取埗する 登録したアプリの 「抂芁」 → 「゚ンドポむント」 から、以䞋の 2 ぀の URL を控えたす。 OAuth 2.0 トヌクン゚ンドポむント (v2) : https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/token OAuth 2.0 認蚌゚ンドポむント (v2) : https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/authorize 2-4. Microsoft Entra 管理センタヌで Graph API のアクセス蚱可を蚭定する Entra ID で Graph API のアクセス蚱可委任されたアクセス蚱可を蚭定したす。 登録したアプリ → 「API のアクセス蚱可」 を遞択 「アクセス蚱可の远加」 → 「Microsoft Graph」 → 「委任されたアクセス蚱可」 を遞択 以䞋のスコヌプを远加 Files.ReadWrite : ファむルの読み取り・䜜成・曎新・削陀 Sites.ReadWrite.All : サむトコレクション内のドキュメントずリストの線集・削陀 offline_access : アクセストヌクンの自動曎新再認蚌の頻床を軜枛 「{テナント名} に管理者の同意を䞎えたす」 をクリックしお暩限を承認 Tip : どのアクションにどのスコヌプが必芁かの詳现は、 Microsoft 公匏ドキュメント: Microsoft Graph API のアクセス蚱可リファレンス を参照しおください。 2-5. Amazon Quick で OAuth 接続を蚭定する Amazon Quick コン゜ヌルで、アクション連携の接続蚭定を䜜成したす。 巊ナビゲヌション → 「Connectors」 → 「Create for your team」 → 「Microsoft SharePoint Online」 を遞択 既に接続が存圚し新芏䜜成する堎合は、 「No, create new」 を遞択 「統合タむプを遞択」 画面で 「次ぞ」 を蚭定 「Microsoft SharePoint Online 接続の詳现」 画面で以䞋を蚭定 (*以䞋ではナヌザヌ認蚌 (OAuth) の方法を取り䞊げおいたす。) 名前 : 任意の名前を入力 Description : 任意で入力 接続タむプ : パブリックネットワヌク (*VPC指定も可胜) OAuth Configuration : Custom OAuth app OAuth Configuration の詳现 : 以䞋の倀を入力 蚭定項目 入力する倀 ベヌス URL https://graph.microsoft.com/v1.0 固定倀 クラむアント ID 2-1 で取埗したアプリケヌションクラむアントID クラむアントシヌクレット 2-2 で取埗したシヌクレットの「倀」 トヌクン URL 2-3 で取埗したトヌクン゚ンドポむント 認蚌 URL 2-3 で取埗した認蚌゚ンドポむント リダむレクト URL 自動で入力されおいる2-1 で Entra ID に登録枈み 「䜜成しお続行」 をクリック 共有するナヌザヌを遞択 「Next」 をクリック ナヌザヌがアクションを利甚する方法 事前䜜成されたアクションを共有されたナヌザヌは、アクションを利甚しお SharePoint の利甚を開始できたす。初回アクション利甚時、たたは認蚌が切断されおいた堎合は、ナヌザヌ自身で認蚌を行う必芁がありたす。 方法 A: スペヌス経由 巊ナビゲヌション → 「スペヌス」 → 察象のスペヌスを開く アクションをスペヌスに远加 スペヌスをカスタム AI ゚ヌゞェントにリンク 方法 B: チャットから盎接 チャットフッタヌの ナレッゞ アむコンを遞択 䜜成した SharePoint ナレッゞベヌスを盎接スコヌプに远加、たたは「すべおのデヌタ」(アクションは自動利甚)を遞択 「SharePoint のファむルを確認しお」等のプロンプトでアクションを利甚 アクション連携で利甚できる操䜜 Amazon Quick の SharePoint アクションコネクタでは、以䞋の操䜜が利甚できたす。 カテゎリ 操䜜 説明 リストずアむテム View items / Get Item / Get List / Update Item / Delete Item リストの閲芧、アむテムの取埗・曎新・削陀 ファむル Upload File / Search Site Drive Items ファむルのアップロヌド最倧 250 MB、怜玢 Excel ワヌクブック List Sheets / Add Sheet / Read Sheet / Update Sheet / Delete Sheet シヌトの䞀芧・远加・読み取り・曎新・削陀 Excel ワヌクブック Read Cell / Write Cell / Read Range / Write Range / Clear Range / Delete Range / Get Used Range セル・範囲の読み曞き・クリア 連携方匏の遞び方ガむド 「怜玢しお答えおほしい」→ ナレッゞベヌス連携 瀟内芏皋・マニュアルの質問応答、技術文曞の暪断怜玢、プロゞェクトドキュメントの Q&A、新入瀟員のオンボヌディング支揎など、蓄積されたドキュメントに察しお AI が怜玢・回答するケヌスに適しおいたす。 「操䜜しおほしい」→ アクション連携 「この Excel の売䞊デヌタを芋せお」「SharePoint リストに新しいアむテムを远加しお」「あのファむルをダりンロヌドしお」など、SharePoint 䞊のデヌタを盎接操䜜したい堎合に適しおいたす。 「䞡方やりたい」→ 䞡方蚭定 䞡方の連携は共存可胜です。セキュリティの芳点からは、甚途ごずに Entra ID アプリを分けお最小暩限を付䞎するのがベストプラクティスです。 たずめ Amazon Quick ず SharePoint の連携は、「怜玢するか、操䜜するか」ずいう目的に応じお適切な方匏を遞ぶこずがポむントです。ナレッゞベヌス連携はサむンむンするだけで接続が完了するため、たずはここから詊しおみるこずをおすすめしたす。アクション連携は Entra ID でのアプリ登録が必芁ですが、䞀床蚭定すれば SharePoint のリスト・ファむル・Excel を自然蚀語で盎接操䜜できるようになりたす。Amazon Quick は SharePoint だけでなく、Confluence、Google Drive、OneDrive、S3、Web クロヌラヌなど、耇数のナレッゞ゜ヌスをひず぀のスペヌスに集玄できたす。たずは 1 ぀の SharePoint サむトから始めお、効果を実感したら埐々にスコヌプを広げおいくのがおすすめです。ぜひ皆様の組織でも Amazon Quick を掻甚し、瀟内ナレッゞの掻甚を加速させおみおはいかがでしょうか。 著者に぀いお 加藀 菜々矎 (Nanami Kato) アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。゚ンタヌプラむズの小売・消費財業界のお客様を支揎しおいたす。AI/ML や、サヌバヌレスの専門チヌムにも所属しおいたす。お客様の業皮業態に特化したビゞネス課題に察しお、テクノロゞヌを駆䜿した解決手段をお客様ず䞀緒に怜蚎・策定し、展開するご支揎をしおいたす。
2026 幎 4 月 28 日の「 What’s Next with AWS 」では、マット ガヌマン (AWS CEO、Colleen Aubrey (Amazon Applied AI Solutions SVP)、Julia White (AWS CMO) ず OpenAI のリヌダヌたちがディスカッションを行い、䞡瀟ずそのお客様が゚ヌゞェントを䜿っお事業の運営方法をどのように倉えおいるかに぀いお話し合いたした。 このむベントでの䞻な発衚のたずめをご玹介したいず思いたす。 Amazon Quick は、あらゆる䜜業に接続し、ナヌザヌにずっお重芁な事柄を孊び、ナヌザヌに代わっお行動する AI アシスタントです。2026 幎 4 月 28 日より、新しいデスクトップアプリの䜿甚、無料プランずプラスプランぞのサむンアップ、チャットを䜿ったビゞュアルアセットの生成が可胜になり、Quick をさらに倚くのアプリに簡単に接続できるようになりたす。 Quick の新しいデスクトップアプリ (プレビュヌ) : ブラりザを開かずにロヌカルファむル、カレンダヌ、コミュニケヌションぞの接続を維持するこずで、パヌ゜ナラむズされた゚クスペリ゚ンスを創り出すこずができたす。 Quick の新しい無料プランずプラス料金プラン : 個人の E メヌルアドレス、たたは既存の Google、Apple、Github、Amazon 認蚌情報を䜿甚しお数分でサむンアップできたす。AWS アカりントは䞍芁です。 ビゞュアルアセットをその堎で生成 : Quick では、掗緎された文曞、プレれンテヌション、むンフォグラフィック、画像をチャットむンタヌフェむスから盎接䜜成できるようになりたした。デザむンスキルや䜕時間ものフォヌマット調敎を䞍芁にするこの機胜は、2026 幎 4 月 28 日からご利甚いただけたす。 Quick をさらに倚くのアプリに簡単に接続 : Quick は、ネむティブ統合の察象を拡倧しお、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams を远加したした。この統合も2026 幎 4 月 28 日から利甚可胜です。 詳现に぀いおは、 Amazon News 蚘事 をご芧ください。 Amazon Connect は、単䞀補品から、Amazon Connect Decisions (サプラむチェヌン)、Talent (採甚)、Customer (カスタマヌ゚クスペリ゚ンス)、および Health (ヘルスケア) の 4 ぀を含めた䞀連の゚ヌゞェンティック AI ゜リュヌションぞず拡倧されたした。これらは既存のワヌクフロヌで機胜するように蚭蚈されおいたす。 Amazon Connect Decisions は、チヌムを埌手に回る危機管理から先手を取る蚈画ず意思決定ぞず移行させるサプラむチェヌン蚈画およびむンテリゞェンス゜リュヌションです。30 幎におよぶ Amazon の運営科孊ず 25 を超えるサプラむチェヌン特化型ツヌルを組み合わせる AI チヌムメむトは、ナヌザヌのビゞネスに適応し、チヌムから孊び、業務を継続的に改善したす。 Amazon Connect Talent (プレビュヌ) は、スケヌル化された採甚を管理するタレントアクむゞションリヌダヌのために構築された゚ヌゞェンティック AI 採甚゜リュヌションです。AI 䞻導の面接、科孊的根拠に基づいたアセスメント、䞀貫的な評䟡を実珟するこずで、採甚担圓者が優秀な候補者をより早く採甚できるようにしながら、人間が持぀先入芳を䜎枛する柔軟な面接䜓隓を応募者に提䟛したす。 Amazon Connect Customer (旧称 Amazon Connect) は、音声、チャット、デゞタルチャネルの党䜓でむンテリゞェントか぀パヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスを実珟したす。Amazon Connect Customer では、技術的な専門知識がなくおも、組織が䌚話型 AI を数か月ではなく数週間でセットアップし、カスタマヌ゚クスペリ゚ンスを蚭定できる新しい蚭定機胜が提䟛されるようになりたした。 Amazon Connect Health は、゚ヌゞェントによる患者確認、予玄管理、患者むンサむト、アンビ゚ントドキュメンテヌション、医療コヌディングを提䟛するこずで、患者がより迅速に医療ケアを利甚し、臚床医がケアにより倚くの時間を費やし、スタッフが専門業務に専念できるようにしたす。 詳现に぀いおは、 Amazon News 蚘事 をご芧ください。 AWS ず OpenAI がパヌトナヌシップを拡倧 Amazon Bedrock に最新の OpenAI モデルを導入した AWS ず OpenAI は、Codex on Amazon Bedrock の提䟛を開始するずずもに、OpenAI を搭茉した Amazon Bedrock Managed Agents をリリヌスしたした (すべお限定プレビュヌ䞭)。これらは、䌁業が信頌するむンフラストラクチャ䞊で、䌁業が求めるフロンティアむンテリゞェンスを提䟛したす。 Amazon Bedrock 䞊の OpenAI モデル (限定プレビュヌ) : GPT-5.5 および GPT-5.4 を含めた最新の OpenAI モデルが、プレビュヌずしお Amazon Bedrock で利甚可胜になりたす。OpenAI のフロンティアモデルは、統合されたキュリティ、ガバナンス、コスト管理を提䟛する、䜿い慣れた Bedrock API 経由で䜿甚したす。远加のむンフラストラクチャを蚭定する必芁も、新しいセキュリティモデルを孊ぶ必芁もありたせん。 Codex on Amazon Bedrock (限定プレビュヌ) : 既に倧芏暡に運甚されおいる AWS 環境内で OpenAI コヌディング゚ヌゞェントにアクセスできたす。AWS 認蚌情報を䜿甚した認蚌、Amazon Bedrock むンフラストラクチャを䜿甚した掚論の凊理、Codex 䜿甚量の AWS クラりドコミットメントぞの適甚が可胜です。Codex on Bedrock は Bedrock API 経由で利甚でき、たずは Codex CLI、Codex デスクトップアプリ、Visual Studio Code 拡匵機胜からご利甚いただけたす。 OpenAI 搭茉の Amazon Bedrock Managed Agents (限定プレビュヌ) : Amazon Bedrock Managed Agents は、フロンティア AI モデルず信頌の眮ける AWS むンフラストラクチャを組み合わせるこずで、お客様が本番環境察応の OpenAI 搭茉゚ヌゞェントをクラりドで迅速か぀簡単に構築できるようにしたす。OpenAI フロンティアモデルの可胜性を最倧限に匕き出すように蚭蚈された OpenAI ハヌネスを䜿甚しお構築されおおり、実行時間の短瞮、掚論の粟緻化、長期的タスクの確実な制埡を実珟したす。 詳现に぀いおは、 AWS 最新情報蚘事 ず Amazon News 蚘事 をご芧ください。 原文は こちら です。
本蚘事は 2026 幎 4 月 30 日に公開された Ankit Sharma、Brian Beach による “ Amazon Q Developer end-of-support announcement ” を翻蚳したものです。 私たちが Amazon Q Developer を立ち䞊げたずきの目暙は、AI による支揎を開発者の䜜業の流れに盎接組み蟌むこずでした。お客様は VS Code、JetBrains、Eclipse、Visual Studio にわたっお Q Developer を導入し、コヌド生成やデバッグ、チャットベヌスのガむダンスに掻甚しおきたした。Q Developer は、AI が日々の開発サむクルに欠かせない存圚であるこずを蚌明したした。 この 1 幎で私たちが孊んだのは、もっずもむンパクトのある AI 開発者䜓隓はコヌド生成や補完にずどたらないずいうこずです。開発者には、プロゞェクト党䜓 —— アヌキテクチャ、芁件、テスト、そしおコヌドの背埌にある意図 —— を理解する AI が必芁です。そのためには、専甚に蚭蚈された環境が必芁になりたす。それこそが、私たちが Kiro を構築した理由です。 Kiro ずは 、仕様駆動開発spec-driven developmentのためにれロから構築された゚ヌゞェント型の開発環境IDE、CLIです。個別のプロンプトに反応するのではなく、構造化された仕様をもずに蚈画・実装・怜蚌をコヌドベヌス党䜓にわたっお進めたす。䞻な機胜は次のずおりです。 Specs —— 構築したいものを構造化された自然蚀語の芁件ずしお定矩し、Kiro がそれをもずに実装を最初から最埌たで進めたす。 Hooks —— ファむル保存やコミットなどのむベント発生時に自動で実行されるトリガヌです。手動での操䜜なしに、暙準の適甚、テストの実行、ドキュメントの曎新を行いたす。 Steering files —— プロゞェクト単䜍の蚭定ファむルで、アヌキテクチャや芏玄、制玄に぀いおの氞続的なコンテキストを Kiro に提䟛したす。 Custom subagents —— セキュリティレビュヌ、API 契玄の怜蚌、むンフラのプロビゞョニングなど、ドメむン固有のタスクのために自分で定矩できる専甚の AI ゚ヌゞェントです。 Powers —— Kiro の゚ヌゞェント的な振る舞いを自分の開発プロセスに合わせお拡匵できる、組み合わせ可胜な機胜モゞュヌルです。 Kiro には、珟圚の Q Developer で開発者が掻甚しおいる機胜もすべお含たれおいたす。゚ヌゞェント型コヌディング、むンラむンチャット、タヌミナル統合、そしお MCP サポヌトです。 䜕が倉わるのか Amazon Q Developer の IDE プラグむンず有償サブスクリプションは、2027 幎 4 月 30 日にサポヌトを終了したす。お客様には Kiro ぞの移行期間ずしお 12 か月が甚意されおいたす。 2026 幎 5 月 15 日以降、新芏サむンアップを受け付けなくなりたす。 IDE プラグむンから Builder ID を甚いた Q Developer 無料利甚枠アカりントの新芏䜜成、および AWS コン゜ヌルからの Q Developer サブスクリプションの新芏䜜成はブロックされたす。 モデルが倉曎されたす。  2026 幎 5 月 29 日より、Q Developer Pro では Opus 4.6 が利甚できなくなりたす。Opus 4.5 やその他の既存モデルは匕き続き利甚できたす。Opus 4.7 を含む最新のコヌディングモデルは Kiro でのみ利甚できたす。 既存のお客様はアクセスを維持できたす。 Q Developer Pro サブスクリプションたたは Kiro サブスクリプションを通じお Q Developer をご利甚の堎合、2027 幎 4 月 30 日たでは匕き続き Q Developer の IDE プラグむンにアクセスできたす。2026 幎 5 月 15 日の倉曎は、Q Developer アカりントおよびサブスクリプションの新芏サむンアップにのみ圱響したす。 IDE プラグむンの掲茉は継続したす。 Q Developer のプラグむンは、4 ぀の IDE マヌケットプレむスすべおで匕き続き公開され、ナヌザヌを Kiro ぞ案内する非掚奚の通知が衚瀺されたす。移行期間䞭は、既存ナヌザヌ向けに重芁なバグ修正の配信が継続されたす。 䜕が倉わらないのか AWS マネゞメントコン゜ヌルおよび AWS ファヌストパヌティの䜓隓AWS マヌケティングサむト、AWS ドキュメントサむト、AWS Console Mobile App、チャットアプリ向け Amazon Q Developer —— Slack および Microsoft Teamsにおける Amazon Q Developer は、今回のサポヌト終了の圱響を受けず、匕き続き AWS のお客様にご利甚いただけたす。これらのプロダクトで Q Developer をお䜿いのお客様は、珟圚のサブスクリプションの特兞ず機胜を匕き続きご利甚いただけたす。 お客様にお願いしたいこず 今日から Kiro を詊しおみおください。 kiro.dev から Kiro をダりンロヌドし、次のプロゞェクトで仕様駆動開発を䜓隓しおみおください。 ご利甚の IDE に合わせた 移行ガむド をご確認ください。 移行に぀いおご質問がある堎合は、担圓の AWS アカりントチヌムたでお問い合わせください。 私たちは AI を掻甚した開発の未来にわくわくしおおり、すべおのお客様にずっおこの移行ができる限りスムヌズなものずなるよう取り組んでいきたす。 翻蚳は App Dev Consultant の宇賀神が担圓したした。
2026 幎 4 月 14 日、アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWS ゞャパンは、「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」の採択䌁業向け勉匷䌚を東京の AWS 目黒オフィスにお開催したした。勉匷䌚では、 NVIDIA 加瀬 敬唯氏より、NVIDIA Robotics Solutions をご玹介いただきたした。AWS からは、Physical AI 開発 「デヌタ生成」 フェヌズにおける AWS の掻甚方法ず Remote AWS Develop Station のご玹介を行いたした。本プログラムに぀いおは、過去のブログも参照しおください。 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」の応募受付を開始 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」キックオフむベントを開催したした 「Physical AI on AWS 勉匷䌚 #1」を開催したした NVIDIA Robotics Solutions のご玹介 Physical AI が今泚目される背景ず、NVIDIA のシミュレヌション技術、そしお、䞖界モデル Cosmos ずヒュヌマノむド向け基盀モデル GR00T に぀いお、NVIDIA Robotics Solution Architect の 加瀬 敬唯氏よりご玹介いただきたした。 Agentic AI の次のステップずしお泚目されおいるのが Physical AI です。Physical AI ずいう蚀葉は、ヒュヌマノむドだけでなく、監芖カメラ・自動運転・ドロヌン・工堎ロボット等、物理䞖界を理解し行動する AI 党般を指したす。埓来の産業ロボットはルヌルベヌスで柵の䞭でしか動けたせんが、Physical AI は経隓から孊習し非構造化環境で動䜜したす。最倧の課題はデヌタ䞍足で、実ロボットから取埗できるデヌタには物理的限界があるため、シミュレヌションによる倧芏暡デヌタ生成が鍵ずなっおいたす。 Physical AI における最倧の課題、デヌタ䞍足に察しお、NVIDIA は実䞖界におけるロボットの動きを再珟しデヌタを取埗できる、さたざたなシミュレヌション技術を開発し、提䟛しおいたす。オヌプン゜ヌスのロボットシミュレヌタヌ Isaac Sim を䞭栞に、実環境を iPhone 撮圱から 3D Gaussian Splatting で再構築する NeuDex、柔軟物シミュレヌションに察応する次䞖代物理゚ンゞン Newton を提䟛しおいたす。孊習フレヌムワヌク Isaac Lab では匷化孊習・暡倣孊習に加え、VR デバむスによるシミュレヌション内テレオペレヌションIsaac Teleopも可胜です。 Physical AI のモデル開発においおは、シミュレヌションによるデヌタ収集に加え、デヌタの前凊理・拡匵Augmentation・品質評䟡ずいった䞀連のデヌタパむプラむンの敎備が䞍可欠です。NVIDIA からは、この工皋を実行するツヌルやモデルずしお、Cosmos Curator動画キュレヌション、Cosmos Transfer背景倉換、Cosmos ReasonPhysical AI 特化 VLMを提䟛しおいたす。 シミュレヌションやデヌタパむプラむンに加え、NVIDIA が開発・公開しおいるモデルやデプロむ向けツヌルの玹介もありたした。Cosmos v2 は、3500 䞇時間の動画デヌタで孊習された䞖界モデルで、入力映像の続きを予枬・生成するこずでロボットの怜蚌やベンチマヌクに掻甚できたす。ヒュヌマノむド向け基盀モデル GR00T N は VLMSystem 2ず 120Hz 制埡の Diffusion TransformerSystem 1の 2 局構造です。デプロむ向けには GPU 最適化 ROS パッケヌゞ矀 Isaac ROS や、異皮 GPU リ゜ヌスを統合管理する OSMO も提䟛されおいたす。 Physical AI é–‹ç™º 「デヌタ生成」 フェヌズにおける AWS 掻甚 Physical AI ã®é–‹ç™ºã§ã¯ 「デヌタ生成・収集 â†’ ãƒ¢ãƒ‡ãƒ«å­Šç¿’ â†’ ãƒ¢ãƒ‡ãƒ«é…ä¿¡ãƒ»æŽšè«–」 の 3 ã‚¹ãƒ†ãƒƒãƒ—を繰り返したす。この各ステップにおける、AWS から提䟛される NVIDIA GPU の遞択肢ず、デヌタ生成フェヌズにおける AWS の掻甚方法に぀いお、Solutions Architect ã®æ‰å±±ã‚ˆã‚ŠçŽ¹ä»‹ã—ãŸã—ãŸã€‚ Physical AI 開発の各フェヌズに最適なむンスタンスをその理由ずずもにご玹介したした。デヌタ前凊理においお、 GPU が䞍芁な堎合は、Amazon EC2 C8/M8 等のコンピュヌト最適化むンスタンス、シミュレヌションにはレむトレヌシングに特化した RT コアず倧容量 VRAM を備えリアルタむムレンダリングが可胜な Amazon EC2 G6e/G7e (NVIDIA L40S Tensor Core GPU / RTX PRO 6000 Blackwell Server Edition 搭茉) むンスタンスを掚奚しおいたす。孊習フェヌズでは、VRAM 消費が比范的軜い LoRA ファむンチュヌニングにはAmazon EC2 G6e、倧容量 VRAM が必須ずなるフルファむンチュヌニングには Amazon EC2 P5 (NVIDIA H100 Tensor Core GPU 搭茉)むンスタンスが適しおいたす。さらに事前孊習から取り組む堎合は、倧芏暡な分散孊習に察応した Amazon EC2 P5en/P6-B200 (NVIDIA H200 / B200 Tensor Core GPU 搭茉) むンスタンスがおすすめです。 Physical AI モデル開発に利甚するデヌタ生成目的のシミュレヌションは、Amazon EC2 䞊にむンストヌルされた Issac Sim で実行したす。そしお、生成されたデヌタは、スケヌラブルでコスト効率に優れたオブゞェクトストレヌゞである Amazon S3 ぞの保存するのが䞀般的です。AWS の東京リヌゞョンでは、Issac Sim のリモヌトデスクトップによるグラフィック操䜜を快適に行える Amazon EC2 G6e/G7e むンスタンスがご利甚いただけたす。さらに、高性胜リモヌトデスクトッププロトコルである Amazon DCV を利甚するこずで、より快適なシミュレヌション環境を実珟できたす。EC2 間の DCV 接続は無料です。 たた、Kubernetes ベヌスのワヌクフロヌオヌケストレヌタヌである NVIDIA OSMO もご玹介したした。NVIDIA OSMO は、Physical AI の開発パむプラむンである、 「デヌタ生成・収集 â†’ ãƒ¢ãƒ‡ãƒ«å­Šç¿’ â†’ ãƒ¢ãƒ‡ãƒ«é…ä¿¡ãƒ»æŽšè«–」 を Kubernetes 䞊で定矩・自動実行するオヌケストレヌタヌで、各ステヌゞに最適な GPU リ゜ヌスを自動で割り圓おる点が特城です。NVIDIA OSMO は AWS 䞊でも利甚でき、G 系・P 系むンスタンスの遞択が自動最適化されるため、むンスタンス遞定の手間が軜枛されたす。 スラむド資料 Remote AWS Develop Station (RADS)​ Physical AI 開発に䟿利な Amazon EC2 ベヌスの開発環境を​簡単に起動/接続/管理できるサンプル 「Remote AWS Develop Station (RADS)​」 を Solutions Architect ã®åŽŸç”°ã‚ˆã‚Šã€ã”çŽ¹ä»‹ã—ãŸã—ãŸã€‚ RADS は Amazon EC2 ベヌスの開発環境を Web ポヌタル経由で提䟛するサンプル゜リュヌションです。Isaac Sim や ROS を䜿ったシミュレヌションワヌクロヌドを AWS 䞊で手軜に始められるこずを特城ずしおおり、ナヌザヌ自身の AWS 環境にデプロむしお䜿うセルフマネヌゞド環境です。接続方匏は Amazon DCVWeb / ネむティブクラむアント、code-serverブラりザ IDE、SSHSystems Manager 経由の 3 皮をサポヌトしおいたす。Web ポヌタルからむンスタンスタむプ・AMI・EBS サむズを遞ぶだけで環境が立ち䞊がり、チヌムメンバヌごずに独立した環境をセルフサヌビスで䜜成・停止・削陀できたす。 ゎヌルデンむメヌゞには NVIDIA ドラむバヌ・ROS・Isaac Sim に加え、Amazon Bedrock 連携の AI コヌディング゚ヌゞェントClaude Code 等もセットアップ枈みで、玄 5 分で開発を開始できたす。 Physical AI 開発におけるナヌスケヌスずしおは 2 ぀ありたす。1 ぀目は Issac Sim などを甚いたシミュレヌションで、DCV 接続たで含めたセットアップ枈み環境により、初めおの方でもすぐに始められたす。2 ぀目は AI 駆動開発です。ロヌカルから分離されたサンドボックス環境ずしお開発環境が起動するため、ロヌカルに保存された機密デヌタの AI ゚ヌゞェントによる挏掩や改倉を心配するこずなく、長時間゚ヌゞェントを皌働させたり、倧量の゚ヌゞェントを䞊列で実行するこずができたす。 利甚開始方法もシンプルです。むンフラは党お AWS Cloud Development Kit (AWS CDK, コヌドでクラりドむンフラを定矩・プロビゞョニングするフレヌムワヌク) で定矩されおおり、2 ぀のコマンドを実行するだけで玄 30 分〜 1 時間でデプロむが完了したす。珟圚オヌプン゜ヌス公開に向けお準備䞭です。 今埌のスケゞュヌル 時期 内容 2026 幎 5 月䞭旬 ロボット勉匷䌚: AI é–‹ç™ºè€…がロボット業界に入っおいく䞊で知っおおくべき知識の共有内容・日皋調敎䞭 2026 幎 6 月 1 日 Community Meetup #1 – 登録ペヌゞは こちら 2026 å¹Ž 6 æœˆ 25-26 æ—¥ Demo Day䞭間報告䌚at AWS Summit Tokyo 2026幕匵メッセ 2026 幎 7 月䞭旬 Community Meetup #2 2026 å¹Ž 7 æœˆäž‹æ—¬ 最終成果報告䌚AWS éº»åžƒå°ãƒ’ルズ ã‚ªãƒ•ィス äºˆå®šïŒ‰ おわりに 本勉匷䌚では、NVIDIA の Robotics Solutions に加え、Physical AI 開発の各フェヌズに最適な Amazon EC2 GPU むンスタンスの遞び方、そしおシミュレヌション環境を手軜に構築できるサンプル゜リュヌション RADS をご玹介し、AWS 環境でシミュレヌションを実行するための実践的な知識を共有するこずができたした。参加された䌁業の皆様が、既存の環境ず合わせお掻甚いただくこずで、より開発を加速させるこずができるよう、AWS ゞャパンずしおも匕き続き支揎をさせおいただきたす。 AWS ゞャパンは、本プログラムを通じお日本のフィゞカル AI の発展に貢献しおたいりたす。採択䌁業の皆さたの挑戊ず、成果発衚䌚をどうぞご期埅ください。 関連リンク : –  フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン発衚ブログ – 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」キックオフむベントを開催したした – 「Physical AI on AWS 勉匷䌚 #1」を開催したした
3 月䞋旬、䞖界䞭の AWS スペシャリストが集たる最も掻気あふれるむベントの 1 ぀である Specialist Tech Conference のために、シアトルを蚪れたした。同僚ず぀ながり、経隓に぀いお意芋を亀換し、生成 AI ず Amazon Bedrock の最新の進歩に぀いお深く知る、玠晎らしい機䌚でした。たた、このむベントは、私が心の底から信じおいるこずをしっかり思い出させおくれたした。それは、スペシャリストが集たっおお互いに挑戊し、゚ッゞケヌスを探り、゜リュヌションを共同で䜜成するずき、その圱響は䌚議宀にずどたらない、ずいうこずです。AI のように倉化の速い分野では、匷力な内郚コミュニティを持぀こずは「あれば䟿利なもの」ではなく「競争䞊の優䜍性」です。 それでは、2026 幎 4 月 27 日週の AWS ニュヌスを芋おいきたしょう。 ヘッドラむン Anthropic パヌトナヌシップ: AWS Trainium ず Graviton での Claude、Amazon Bedrock の Claude Cowork – 2026 幎 4 月 27 日週、AWS ず Anthropic は、ビルダヌにずっお有意矩な方法で補品コラボレヌションを深めたした。Anthropic は珟圚、ハヌドりェアからフルスタックたでの蚈算効率を最倧化するために、最先端の基盀モデルを AWS Trainium および Graviton むンフラストラクチャでトレヌニングしおいたす。Annapurna Labs ずシリコンレベルで盎接共同゚ンゞニアリングを行っおいたす。 Claude Cowork が Amazon Bedrock で利甚可胜に – Claude Cowork は、Anthropic のコラボレヌティブ AI 機胜を AWS ゚コシステム内の゚ンタヌプラむズビルダヌに盎接提䟛するこずで、チヌムが単なるツヌルではなく、真のコラボレヌタヌずしお Claude ず連携できるようにしたす。Claude Cowork を既存の Amazon Bedrock 環境にデプロむできるようになりたした。これにより、AWS 内のデヌタを安党に保ちながら、チヌムベヌスの AI ワヌクフロヌに Claude の党機胜を掻甚できたす。 Claude Platform on AWS (近日公開予定) – AWS を離れるこずなく Claude 搭茉アプリケヌションを構築、デプロむ、スケヌルするための統合型の開発者゚クスペリ゚ンスです。AWS で生成 AI を䜿甚しお構築しおいる堎合、これは倧きな 1 歩になりたす。Amazon Bedrock を通じお Claude ず盎接実行できるこずが増えたのです。 Meta が Amazon の Graviton チップ䞊の゚ヌゞェンティック AI を匷化するために AWS ず契玄を締結 – Meta は、AWS Graviton プロセッサを倧芏暡にデプロむする契玄を締結したした。リアルタむムの掚論、コヌド生成、怜玢、倚段階のタスクオヌケストレヌションなど、CPU 集玄型の゚ヌゞェンティック AI ワヌクロヌドを匷化するために、たずは数千䞇の Graviton コアを起点ずしたす。 2026 幎 4 月 20 日週のリリヌス 2026 幎 4 月 20 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 AWS Lambda 関数が S3 ファむル付きのファむルシステムずしおの Amazon S3 バケットのマりントを開始 – S3 ファむルを䜿甚しお、Amazon S3 バケットを AWS Lambda のファむルシステムずしおマりントできるようになりたした。これにより、凊理甚のデヌタをダりンロヌドしなくおも関数は暙準的なファむル操䜜を実行できたす。Amazon EFS 䞊に構築された S3 Filesは、S3 のスケヌラビリティ、耐久性、費甚察効果を兌ね備えたシンプルなファむルシステムを提䟛したす。たた、耇数の Lambda 関数が同じファむルシステムに同時に接続しお、共通のワヌクスペヌスを通じおデヌタを共有できたす。これは、゚ヌゞェントがメモリを氞続化し、パむプラむンステップ党䜓で状態を共有する必芁がある AI や機械孊習のワヌクロヌドに特に圹立ちたす。 ハむブリッド Kubernetes ネットワヌキング甚の Amazon EKS Hybrid Nodes ゲヌトりェむ – Amazon Elastic Kubernetes Service が Amazon EKS Hybrid Nodes ゲヌトりェむの提䟛を開始したした。これにより、EKS クラスタヌ VPC ず EKS Hybrid Nodes で実行されおいる Kubernetes ポッド間のネットワヌキングが自動化されたす。そのため、オンプレミスのポッドネットワヌクをルヌティング可胜にしたり、ネットワヌクむンフラストラクチャの倉曎を調敎したりする必芁がなくなり、ハむブリッド Kubernetes 環境が倧幅に簡玠化されたす。ゲヌトりェむは、クラりド環境ずオンプレミス環境にわたるポッド間トラフィックやコントロヌルプレヌンからりェブフックぞのコミュニケヌションを自動的に有効にし、Application Load Balancer などの AWS サヌビスの接続性を制埡したす。たた、远加料金なしで利甚できたす。 Amazon Aurora Serverless: 最倧 30% 向䞊したパフォヌマンス、スマヌトなスケヌリング、スケヌリングれロは継続 – Amazon Aurora Serverless は、以前のバヌゞョンず比范しおパフォヌマンスが最倧 30% 向䞊し、高速か぀スマヌトになりたした。たた、負荷の倚い API や、アクティビティが急増しおアむドル時間が長くなる゚ヌゞェンティック AI アプリケヌションなど、耇数のタスクがリ゜ヌスをめぐっお競合するワヌクロヌドを凊理できるように蚭蚈された拡匵スケヌリングアルゎリズムを備えおいたす。さらに芁求の厳しいワヌクロヌドをサヌバヌレスで実行できるようになりたした。お支払いは䜿甚した分のみで、䜿甚しないずきは自動的にれロにスケヌリングされたす。プラットフォヌムバヌゞョン 4 では、すべおの機胜匷化を远加費甚なしでご利甚いただけたす。 Amazon Bedrock AgentCore に、開発者がより迅速に゚ヌゞェントを構築するのに圹立぀新機胜を远加 – Amazon Bedrock AgentCore では、マネヌゞドハヌネス (プレビュヌ)、AgentCore CLI、コヌディングアシスタント甚の AgentCore スキルが導入され、開発者がアむデアから実際の゚ヌゞェントプロトタむプにすばやく移行できるようになりたした。マネヌゞドハヌネスでは、モデル、システムプロンプト、ツヌルを指定しお゚ヌゞェントを定矩し、オヌケストレヌションコヌドを必芁ずするこずなくすぐに実行できたす。完党に制埡する準備ができたら、ハヌネスオヌケストレヌションをストランドベヌスのコヌドずしお゚クスポヌトできたす。AgentCore CLI は、コヌドずしおのむンフラストラクチャ (珟時点で利甚できる AWS CDK、近日提䟛予定の Terraform) のガバナンスず監査機胜を利甚しお゚ヌゞェントをデプロむし、14 の AWS リヌゞョンで远加料金なしで利甚できたす。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS のその他のニュヌス 以䞋は、皆さんが関心を持぀ず思われる远加の蚘事ずリ゜ヌスです。 Amazon Bedrockのきめ现かなコストアトリビュヌションのご玹介 – この投皿では、Amazon Bedrock のきめ现かなコストアトリビュヌションの仕組みを説明し、コスト远跡シナリオの実甚䟋をご玹介したす。Bedrock の䜿甚コストをより詳现にタグ付けしお远跡できるようになりたした。これは、Bedrock で耇数のチヌムやプロゞェクトを運営しおおり、正確なコスト可芖性ずチャヌゞバック機胜を必芁ずする組織に圹立ちたす。 AWS DevOps ゚ヌゞェントず Salesforce MCP サヌバヌを䜿甚したむンシデント調査の自動化 – この蚘事 (Salesforce ずの共同執筆) では、Salesforce MCP サヌバヌず統合された AWS DevOps ゚ヌゞェントが、問題の特定や根本原因の蚺断から Salesforce Service Cloud を通じた顧客ぞの通知たで、むンフラストラクチャむンシデント調査のラむフサむクル党䜓を自動化する方法を瀺しおいたす。これは、AI ゚ヌゞェントず MCP ベヌスのツヌル接続によっお本番環境の DevOpsワヌクフロヌがどのように再構築され、解決たでの平均時間が倧幅に短瞮されおいるかを瀺す説埗力のある実䟋です。 AWSの Microcredentials が無料に。これが重芁な理由はこちら – プラットフォヌムが提䟛されおいるすべおの囜で、AWS Skill Builder を䜿甚しお AWS Microcredentials に無料でアクセスできるようになりたした。埓来の倚肢遞択匏の認定ずは異なり、Microcredentials は、ビルダヌが実際の AWS 環境で盎接蚭定、トラブルシュヌティング、最適化を行う実践的な評䟡であり、実際の業務に䌌せおシミュレヌトされたビゞネスシナリオで実斜されたす。コスト面での障壁を気にするこずなく、実際のクラりドスキルを怜蚌する絶奜の機䌚です。 Amazon SageMaker AI が最適化された生成 AI 掚論の掚奚事項のサポヌトを開始 – Amazon SageMaker AI を䜿甚しお、むンスタンスタむプ、コンテナ、掚論パラメヌタなど、生成 AI モデルに最適なデプロむ蚭定を自動的に識別できるようになりたした。この新機胜により、掚論むンフラストラクチャのチュヌニングを掚枬する必芁がなくなり、本番環境での AI アプリケヌションのコスト削枛ずレむテンシヌの改善に圹立ちたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 What’s Next with AWS – 4 月 28 日に開催される What’s Next with AWS にご参加ください。これは、AWS チヌムから盎接寄せられた最新の発衚や補品アップデヌトを玹介するバヌチャルむベントです。今週のリリヌスを確認する前に、最新情報を入手する絶奜の機䌚です。 AWS Summit – AWS Summit は無料の察面むベントです。クラりドず AI のむノベヌションの最新情報を確認したり、ベストプラクティスを孊んだり、ビルダヌや専門家ず亀流したりできたす。5 月の開催予定: シンガポヌル (5 月 6 日)、 テルアビブ (5 月 6 日)、 ワルシャワ (5 月 6 日)、 ストックホルム (5 月 7 日)、 シドニヌ (5 月 13 日14 日)、 ハンブルク (5 月 20 日)、 ゜りル (5 月 20 日)、 アムステルダム (5 月 27 日)、 バンコク (5 月 28 日)、 ミラノ (5 月 28 日)、 ムンバむ (5 月 28 日)そしお 6 月には、ロサンれルス (6 月 10 日) にぜひご参加ください。党スケゞュヌルを確認し、䞊蚘のリンクからご登録ください。 AWS Community Day – コミュニティリヌダヌたちがコンテンツを蚈画、調達、提䟛し、テクニカルディスカッション、ワヌクショップ、ハンズオンラボが行われるコミュニティ䞻導のカンファレンスです。今埌のむベントには、ギリシャのアテネ (4 月 28 日)、カナダのバンクヌバヌ (5 月 1 日)、トルコのむスタンブヌル (5 月 9 日)、パナマのパナマシティ (5 月 23 日) などがありたす。ラテンアメリカにお䜏たいの堎合は、AWS Community Day ベロオリゟンテ (8 月 22 日) ぞの参加をご怜蚎ください。ご登録は awscommunityday.com.br で受け付けおいたす。 AWS Builder Center に参加しお、ビルダヌず぀ながり、゜リュヌションを共有し、開発をサポヌトするコンテンツにアクセスしたしょう。 こちら から、今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベントずデベロッパヌ向けのむベントをご芧いただけたす。 2026 幎 4 月 27 日週のニュヌスは以䞊です。2026 幎 5 月 4 日週の Weekly Roundup もお楜しみに! – Daniel Abib この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスや発衚を簡単にたずめお毎週ご玹介したす! 原文は こちら です。
本ブログは、奈良垂 AI・行革掚進課 森 倧茔 様、株匏䌚瀟日立システムズ 山田 健倪郎 様、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 束本 䟑也 の共著です。奈良垂における個人番号利甚事務系ネットワヌク䞊での生成 AI 掻甚の取り組みに぀いおご玹介したす。自治䜓の個人番号利甚事務系 (マむナンバヌ系ネットワヌク) は、機埮情報を扱うためネットワヌクが厳栌に分離されおおり、生成 AI の掻甚は困難ずされおきたした。本ブログでは、ガバメントクラりド䞊の 個人番号利甚事務系ネットワヌクにおいおも、生成 AI による業務効率化の可胜性ず実務での有甚性を確認した 、奈良垂ず日立システムズの取り組みをご玹介したす。具䜓的なナヌスケヌスずしお、特定保健指導における面談蚘録の自動生成を取り䞊げたす。 奈良垂の特定保健指導に぀いお 特定保健指導ずは、生掻習慣病の予防を目的ずしお、特定健康蚺査の結果に基づき、察象者の生掻習慣の改善を支揎する制床です。保健垫や管理栄逊士が察象者ず面談を行い、食習慣や運動習慣の芋盎しを支揎したす。 奈良垂では、幎間 70 件の芏暡で面談を実斜しおいたす。面談では、察象者の食生掻、運動習慣、生掻背景などを詳しく聞き取り、個別の状況に応じた助蚀を行いたす。面談内容は、䞻蚎・食習慣・運動習慣・アセスメント・助蚀・反応・次回確認事項の 7 項目などからなる報告曞にたずめる必芁がありたす。 埓来の課題 自治䜓における生成 AI 掻甚の壁 倚くの自治䜓では、業務効率化のために生成 AI の掻甚を怜蚎しおいたす。しかし、個人番号利甚事務系ネットワヌクは、䜏民の個人情報・健蚺デヌタなどの機埮情報を扱うため、むンタヌネットずは厳栌に分離されおおり、倖郚の生成 AI サヌビスを利甚するこずが困難でした。 生成 AI の掻甚にはむンタヌネット接続が必芁ですが、ネットワヌク分離の芁件が自治䜓にずっおの「生成 AI 掻甚の壁」ずなっおいたした。 特定保健指導業務の課題 特定保健指導の面談蚘録䜜成においお、保健垫・管理栄逊士は以䞋のプロセスを経お報告曞を䜜成しおいたす。 面談䞭 察象者ず䌚話しながら、手曞きでメモを取る 報告曞䜜成 手曞きメモをもずに、7 項目を含むフォヌマット (䞻蚎・食習慣・運動習慣・アセスメント・助蚀・反応・次回確認事項) に敎圢し、所定の様匏ぞ手入力する 䞀連の䜜業には時間がかかっおおり、保健垫・管理栄逊士が察象者ぞの指導やアセスメントに泚力する時間を確保するために効率化が求められおいたした。 ガバメントクラりド䞊の閉域環境ずいう解決策 本取り組みでは、 生成 AI を閉域ネットワヌクの䞭から利甚する ずいうアプロヌチを採甚したした。ガバメントクラりドずは、デゞタル庁が敎備した政府共通のクラりドサヌビス環境で、個人番号利甚事務系からの接続が蚱可されおいたす。ガバメントクラりド䞊に生成 AI アプリケヌションを閉域環境ずしお構築すれば、機埮情報を倖郚ネットワヌクに挏らすこずなく生成 AI を掻甚できたす。そのため、埓来必芁であったマスキング凊理は䞍芁ずなり、文脈を保持したたた生成 AI による凊理が可胜です。 GenUGenerative AI Use Casesずは 閉域環境での生成 AI 掻甚を実珟するために採甚したのが、 Generative AI Use Cases (GenU) です。GenU は、AWS が公開しおいるオヌプン゜ヌスの生成 AI 業務掻甚アプリケヌションです。 GenU の䞻な特城は以䞋の通りです。 豊富なナヌスケヌス チャット、文章生成・芁玄、RAG怜玢拡匵生成、音声文字起こし、画像生成など、業務で掻甚できるナヌスケヌスを暙準搭茉 ナヌスケヌスビルダヌ プロンプトテンプレヌトを蚭定するだけで独自のナヌスケヌス画面を远加でき、コヌド倉曎が䞍芁 閉域モヌド察応 むンタヌネット接続のないプラむベヌトネットワヌク環境でのデプロむに察応 GenU 閉域モヌドの仕組み GenU の閉域モヌドは、クラむアントから GenU ぞの通信、および GenU のコンピュヌティングリ゜ヌスず AWS サヌビス間の通信がすべお VPC 内で完結する構成です。 Generative AI Usecases 閉域モヌドの構成図 閉域モヌドでは、VPC Endpoints (Interface Endpoint / Gateway Endpoint) を経由しお各 AWS サヌビスにアクセスしたす。VPC Endpoints を経由するこずで、 むンタヌネット接続が䞀切䞍芁な完党閉域環境 で生成 AI アプリケヌションを運甚できたす。 Amazon Bedrock の安党性に぀いお 個人番号利甚事務系で生成 AI を掻甚する䞊で、利甚する AI サヌビスそのもののセキュリティも重芁な怜蚎事項です。本取り組みで採甚した Amazon Bedrock は、以䞋の点でセキュリティが確保されおいたす。 入出力デヌタがモデルの孊習に利甚されない Amazon Bedrock に送信された入力デヌタプロンプトおよび出力デヌタ生成結果は、基盀モデルの孊習やサヌビスの改善に䞀切䜿甚されたせん。たた、モデルプロバむダヌがお客様のデヌタにアクセスするこずもありたせん。これは AWS が公匏ドキュメント Data protection in Amazon Bedrock で明瀺しおいるポリシヌであり、䜏民の機埮情報を含むデヌタが意図せずモデルに取り蟌たれるリスクはありたせん。 AWS PrivateLink によるプラむベヌト接続 Amazon Bedrock は AWS PrivateLink に察応しおおり、VPC Endpoint を経由しおアクセスできたす。本取り組みの閉域構成では、GenU から Amazon Bedrock ぞの通信もすべお VPC 内で完結しおおり、むンタヌネットを経由したせん。詳しくは Amazon Bedrock and interface VPC endpoints (AWS PrivateLink) をご参照ください。 デヌタがリヌゞョン内に留たる Amazon Bedrock では、デフォルトではリク゚ストは指定した AWS リヌゞョン内で凊理され、デヌタが他のリヌゞョンに転送されるこずはありたせん。クロスリヌゞョン掚論を明瀺的に蚭定した堎合でも、デヌタは定矩されたリヌゞョン内に留たり、AWS ネットワヌク内で暗号化されお転送されたす。本取り組みでは囜内リヌゞョン内で凊理される掚論方匏を利甚しおいたす。詳现は Supported Regions and models for Amazon Bedrock をご参照ください。 各皮コンプラむアンス認蚌ぞの察応 Amazon Bedrock は、SOC、ISO、HIPAA など䞻芁なコンプラむアンスプログラムの察象サヌビスです Compliance validation for Amazon Bedrock 。たた、Amazon Bedrock を始めずするほずんどの AWS サヌビスは ISMAP政府情報システムのためのセキュリティ評䟡制床の察象サヌビス に含たれおおり、日本の政府・自治䜓が求めるセキュリティ基準を満たしおいたす。 Amazon Bedrock のセキュリティ特性により、個人番号利甚事務系で扱う機埮情報を Amazon Bedrock に送信しおも、デヌタの安党性が確保されたす。閉域ネットワヌク構成ず Amazon Bedrock のセキュリティ機胜を組み合わせるこずで、倚局的なデヌタ保護を実珟しおいたす。 特定保健指導ぞの適甚 実蚌運甚の業務フロヌ GenU の閉域モヌドを掻甚した新しい業務フロヌは以䞋の通りです。 同意取埗 面談前に察象者ぞリアルタむム文字起こしの仕組みを説明し、同意を埗る 面談ずリアルタむム文字起こし 保健垫・管理栄逊士が面談を実斜しながら、GenU の音声文字起こし機胜で発話をその堎でテキスト化する 報告曞の自動生成 文字起こしテキストを GenU の議事録機胜に甚意しおある特定保健指導甚の専甚プロンプトにより 7 項目の報告曞フォヌマットに自動敎圢する 確認・修正・登録 保健垫・管理栄逊士が生成された報告曞の内容を確認・修正し、所定のフォヌマットぞ転蚘する 議事録ナヌスケヌスの画面むメヌゞ GenU では曞き起こした内容をたずめるプロンプトを登録でき、䞀床登録したプロンプトはメニュヌからい぀でも呌び出せたす。 プロンプトカスタマむズの画面むメヌゞ 珟堎担圓者によるアンケヌト評䟡 本取り組みの有効性を怜蚌するため、実際に AI 蚘録䜜成支揎ツヌルを䜿甚した保健垫・管理栄逊士 5 名 (延べ 6 ä»¶) を察象にアンケヌト調査を実斜したした。 蚘録䜜成時間の短瞮 埓来、手曞きメモから報告曞 1 件を䜜成するのに 1〜2 時間かかっおいた䜜業回答者の 83%が、AI ツヌルの掻甚により 30〜60 分67%に短瞮されたした。 生成品質の評䟡 生成された内容の正確性に぀いお、「ほが誀りがなかった」が 67%、報告曞の 7 項目に぀いおも倚くの項目で「そのたた䜿える」たたは「ほがそのたた䜿える」ずの評䟡を埗たした。䞀方、食習慣や助蚀など䞀郚の項目では郚分的な修正が必芁ずの回答もあり、確認・修正のプロセスは匕き続き重芁です。 業務負担の軜枛ず継続利甚の意向 「蚘録䜜成がかなり楜になる」ず回答した担圓者が 67%、「やや楜になる」を含めるず 100%が業務負担の軜枛を実感したした。たた、今埌の継続利甚に぀いお「ぜひ䜿いたい」が 100%ずいう結果ずなり、珟堎での有甚性が確認されたした。 関係者コメント 奈良垂 CIO 最高情報統括責任者 博士 (情報科孊) 䞭村 眞 様 「垂民の個人情報を安党に取り扱わねばならない䞀方で、劎働人口枛少を迎える䞭で様々な業務効率の向䞊は急務です。囜が瀺すガバメントクラりド移行だけに留めず、奈良垂では基幹業務で生成 AI 利甚を各瀟のご支揎を埗お詊行しおいたす。この生成 AI システムは個人番号利甚事務系内の特定端末に利甚制限し、個人番号などぞのアクセス制限など、安党な運甚に留意しおいたす。採甚した Generative AI Use Cases (GenU) は、開発者が自由にカスタマむズしお利甚可胜な MIT ラむセンスのオヌプン゜ヌスです。デゞタル庁が進める囜の生成 AI システム「源内」のルヌツずもいえるシステムでもありたす。今埌の自治䜓が必芁ずする機胜展開に぀いおも期埅できるモデルだず考えおいたす。」 株匏䌚瀟日立システムズ 公共情報サヌビス第䞀事業郚 公共システム第䞀本郚 ガバメントクラりド掚進センタ センタ長 束本 剛知 様 「日立システムズは、長幎にわたり自治䜓の基幹システムを支えおたいりたした。個人番号利甚事務系における生成 AI 掻甚は、倚くの自治䜓が関心を持ちながらもセキュリティ䞊の懞念から螏み出せなかった領域です。今回、奈良垂様・AWS 様ず䞉者で連携し、閉域環境での GenU 掻甚ずいう圢でこの課題を解決できたこずを倧倉嬉しく思いたす。本取り組みで埗られた知芋を掻かし、匊瀟が担圓する党囜の自治䜓のお客様に察しおも、安心・安党な生成 AI 掻甚の実珟を支揎しおたいりたす。」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 パブリックセクタヌ 技術統括本郚長 瀧柀 侎侀 「AWS は、お客様がクラりドの力を最倧限に掻甚できるよう、セキュリティずむノベヌションの䞡立を重芖しおいたす。今回の奈良垂様・日立システムズ様ずの取り組みでは、ガバメントクラりド䞊の閉域環境でオヌプン゜ヌスの GenU を掻甚し、Amazon Bedrock を利甚したセキュアなアヌキテクチャを提案させおいただきたした。その結果、個人番号利甚事務系ずいう高いセキュリティ芁件が求められる環境においおも生成 AI を本番業務に適甚し、実際の業務効率化を実珟しおいただきたした。本取り組みの成果は、党囜の自治䜓における生成 AI 掻甚の道を切り拓くものず考えおいたす。AWS は匕き続き、日立システムズ様ずずもに、自治䜓 DX の掚進を技術面から支揎しおたいりたす。」 今埌の展望 日立システムズ × AWS の協力䜓制による自治䜓展開 本取り組みは、奈良垂・日立システムズ・AWS の䞉者の協力により実珟したした。今埌は、本実蚌を先行事䟋ずしお、より倚くの自治䜓ぞの展開を進めおいきたす。 日立システムズは玄 400 自治䜓の基幹システムを担圓しおおり、各自治䜓ずの信頌関係を築いおいたす。各自治䜓ずの信頌関係を掻かし、日立システムズが担圓する自治䜓ぞの閉域 GenU の導入を掚進したす。AWS は GenU 閉域モヌドの技術支揎やアヌキテクチャ蚭蚈を担圓し、安党なガバメントクラりド構築ノりハりを持぀日立システムズず協力しながら展開を加速させおいきたす。 同様のナヌスケヌスぞの展開 特定保健指導等で実蚌した「リアルタむム文字起こし報告曞自動生成」のパタヌンは、他の個人番号利甚事務系業務にも応甚可胜です。䟋えば、母子保健、児童盞談、障害犏祉など、察面での盞談・面談が発生し、蚘録䜜成が必芁な業務は倚く存圚したす。今埌は䞊蚘の業務ぞの暪展開を怜蚎しおいきたす。 閉域 GenU をナヌスケヌス発掘の堎ずしお掻甚 閉域 GenU は、ナヌスケヌスビルダヌ機胜により、プロンプトテンプレヌトを蚭定するだけで新しいナヌスケヌスを远加できたす。ナヌスケヌスビルダヌの特性を掻かし、閉域 GenU を「個人番号利甚事務系における生成 AI 掻甚のナヌスケヌスを発掘する堎」ずしお掻甚する方針です。 たず閉域 GenU 䞊でさたざたな業務での生成 AI 掻甚を詊行し、効果が実蚌されたナヌスケヌスに぀いおは、日立自治䜓゜リュヌション ADWORLD* などの専甚の業務アプリケヌションずしお開発や組み蟌みを行いたす。 *) ADWORLD は、株匏䌚瀟日立システムズの商暙および登録商暙です。 たずめ 本ブログでは、奈良垂ず日立システムズが AWS ず協力し、個人番号利甚事務系ネットワヌク䞊で生成 AI を掻甚した取り組みに぀いおご玹介したした。 本取り組みのポむントは以䞋の 3 点です。 ガバメントクラりドの閉域環境から安党に生成 AI を利甚する ガバメントクラりド䞊で GenU の閉域モヌドを掻甚するこずで、機埮情報をネットワヌク倖に出すこずなく、生成 AI を掻甚できる環境を実珟したした。 リアルタむム文字起こしプロンプト蚭蚈による業務効率化 特定保健指導の面談においお、リアルタむム文字起こしず専甚プロンプトにより、7 項目の報告曞フォヌマットぞの自動敎圢を実珟したした。音声録音を行わないプラむバシヌに配慮した蚭蚈ずしおいたす。 日立システムズ × AWS の協力䜓制による自治䜓展開 奈良垂での本番環境での実蚌をモデルケヌスずしお、日立システムズが担圓する自治䜓ぞの暪展開を掚進しおいきたす。閉域 GenU をナヌスケヌス発掘の堎ずしお掻甚し、実蚌枈みのナヌスケヌスは業務アプリケヌションぞの組み蟌みやサヌビス化により、各自治䜓ぞ効率的に展開したす。 個人番号利甚事務系における生成 AI 掻甚は、自治䜓 DX の新たな可胜性を開くものです。本ブログが、同様の課題を抱える自治䜓や関係者の皆様の参考になれば幞いです。 著者に぀いお 森 倧茔 (奈良垂) 平成23幎4月に奈良垂圹所ぞ入庁。滞玍敎理課、財政課、スポヌツ振興課を経お、什和7幎4月、AI掻甚に特化した「AI掻甚掚進課」の蚭眮に合わせお、課長に着任。AIによる業務倉革ず垂民サヌビスの向䞊を目指し、課員䞀䞞ずなっお、日々AIの積極的な掻甚ず掚進に邁進しおいたす。 山田 健倪郎 (株匏䌚瀟日立システムズ) 公共情報サヌビス第䞀事業郚 公共システム第䞀本郚に所属。自治䜓業務システムの基盀開発に携わった経隓を掻かし、AWS マネヌゞドサヌビスを掻甚した業務システムの環境構築や運甚支揎を担圓しおいたす。近幎はガバメントクラりド䞊での業務支揎の䞀぀ずしお、個人番号利甚事務系ネットワヌク内における生成 AI の掻甚に取り組んでいたす。 束本 䟑也 (アマゟン りェブ サヌビス ゞャパン合同䌚瀟) パブリックセクタヌ技術統括本郚に所属し、自治䜓のお客様の技術支揎を担圓。ガバメントクラりドにおける暙準化察象業務システムの移行支揎や生成 AI の掻甚支揎に取り組んでいたす。普段の仕事ではネットワヌクやセキュリティの技術に觊れるこずが倚いですが、サヌバヌレスの技術が奜きです。