TECH PLAY

AWS

AWS の技術ブログ

å…š3288ä»¶

この蚘事は株匏䌚瀟 MIERUNE の代衚取締圹 CEO である Yasunori Kirimoto  ã«å¯„皿頂いた「 New features and developer experience with enhanced Amazon Location Service 」を゜リュヌションアヌキテクトの皲田が翻蚳したものです。 地理空間アプリケヌションを構築するには、地理空間デヌタを扱うための専門知識ず、システムの蚭蚈および開発のスキルが必芁です。たた、倧量の地理空間デヌタを収集および管理し、アプリケヌションで効果的に利甚するスキルも必芁ずされたす。このプロセスは非垞に手間がかかる可胜性がありたすが、その耇雑さは Amazon Location Service を掻甚するこずで倧幅に軜枛できたす。 Amazon Location Service では、API から高粟床の地理空間デヌタをすばやく取埗できるため、開発者はアプリケヌションの構築に集䞭できたす。さらに、Amazon Location Service が埓来の機胜に加えお新機胜が远加されたした。Amazon Location Service の新機胜を玹介し、アプリケヌションでその機胜を掻甚する方法をご玹介したす。 Amazon Location Service の新機胜のリリヌス 最倧の倉曎点は、個別のリ゜ヌス䜜成が䞍芁になったこずです。぀たり、ナヌザヌは個々のリ゜ヌス (Place Index、Map、Route Calculator など) を䜜成する必芁がなくなり、API キヌを蚭定するだけで、すぐに Amazon Location Service を䜿い始められたす。 さらに、Maps、Places、Routes API に倧幅な機胜匷化ず新機胜が远加されたした。Maps API は、远加のスタむルず新しい静的マップ機胜で曎新されたした。Places API は、新しい怜玢ず地理コヌディング機胜で匷化されたした。最埌に、Routes API は、Snap to Road、Waypoint Optimization、および远加の移動モヌドなどの新機胜で曎新されたした。 API キヌの䜜成 API キヌ を䜜成するには、 AWS マネゞメントコン゜ヌル たたは AWS Cloud Control API を利甚できたす。この䟋では、コン゜ヌルを䜿甚したす。Amazon Location Service コン゜ヌルに移動し、 Manage resources の䞋にある API keys を遞択したす。 Create API key を遞択しおください。 図 1 – Amazon Location Service コン゜ヌル – API キヌコン゜ヌル デモのために、API キヌを LasVegasMaps ず名付け、以䞋のアクションを遞択したす。 GetStaticMap GetTile Geocode GetPlace SearchNearby SearchText CalculateIsolines SnapToRoads 図 2 – API キヌアクションの遞択 スクロヌルダりンするず、有効期限の蚭定や参照元の蚭定など、远加オプションがありたす。これらはオプションですが、本番環境のアプリケヌションには匷くお勧めしたす。今回はこのデモのためこれらはデフォルトのたたにしおいたす。 図 3 – 远加の API キヌオプション Create API Key を遞択しおください。 API キヌを䜜成したので、次はアプリケヌションで䜿甚するための倀を取埗する必芁がありたす。 Show API key value を遞択し、倀を安党な堎所にコピヌしおください。 図 4 – API キヌコン゜ヌルで、API キヌの倀を衚瀺する 新しい Maps API たず、GetStyleDescriptor ず GetStaticMap に぀いお詳しく説明しお玹介したす。 地図アプリケヌションの基盀ずなる GetStyleDescriptor の構築 GetStyleDescriptor を䜿甚するず、マップスタむル情報を取埗し、マップアプリケヌションの基盀を迅速に構築できたす。この機胜は、様々な地理空間゜リュヌションやアプリケヌション基盀に䜿甚できたす。新バヌゞョンでは、異なるアプリケヌション向けに目的に合わせお蚭蚈された拡匵マップスタむルを提䟛しおおり、様々なレベルの地図詳现を持぀ダヌクモヌドずラむトモヌドを提䟛しおいたす。 MapLibre GL JS を䜿甚しおこれらのマップスタむルを掻甚する方法を玹介したす。MapLibre GL JS ず Amazon Location Service API キヌを䜿甚しお、非垞にシンプルな HTML ペヌゞを䜜成したす。 simpleMap.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service Map</title> <!-- MapLibre GL CSS --> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; /* Full viewport height */ } </style> </head> <body> <!-- Map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <script> // Configuration const region = "<AWS Region>"; // Replace with your AWS region const mapApiKey = "<Your API Key>"; // Replace with your Amazon Location Service API key async function initializeMap() { // Initialize the map const map = new maplibregl.Map({ container: "map", // HTML element ID where the map will be rendered center: [-115.1473824627421, 36.17071351509272], // Initial map center coordinates (Las Vegas) zoom: 12, // Initial zoom level style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, // Map style URL }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); } // Call the function to initialize the map initializeMap(); </script> </body> </html> この HTML ペヌゞをブラりザで開いおください。ラスベガスの地図が衚瀺されるはずです。この地図の鍵は、前のコヌドで蚭定したスタむル URL です。この URL では、明るい色のスタンダヌドスタむルマップを芁求しおいたす。政治的な芋解など、远加のパラメヌタも指定できたす。 図 5 – ラスベガスネバダ州を䞭心ずした地図 GetStaticMap を䜿甚しお静的地図画像を䜜成する GetStaticMap を䜿甚するず、指定した座暙、ズヌムレベル、むメヌゞサむズに基づいお静的な地図画像を䜜成できたす。この機胜は、印刷物やメディアの投皿に地図画像を含めるのに圹立ちたす。この機胜にはさたざたなパラメヌタがあり、他のデヌタ (ポむント、ラむン、ポリゎンなど) を重ね合わせるこずもできたす。基本的な䟋を瀺したす。䜿甚する AWS リヌゞョンず新しく䜜成した API キヌに合わせお URL を線集しおください。指定した堎所の静的な地図画像を衚瀺するには、以䞋の URL を Web ブラりザのアドレスバヌに貌り付けおください。 https://maps.geo.<Your AWS Region>.amazonaws.com/v2/static/map?center=-115.170,36.122&zoom=15&width=1024&height=1024&key=<Your API Key> 図 6 – ラスベガスストリップを衚瀺する静的地図画像 新しい Places API 次に、SearchText ず SearchNearby を玹介したす。 SearchText による特定の POI デヌタの怜玢 SearchText を䜿甚するず、ナヌザヌは特定の目的地POIデヌタを怜玢しお衚瀺するこずができたす。この機胜は、ナヌザヌが特定の堎所や斜蚭をすばやく怜玢できるように蚭蚈されおいたす。ナヌザヌは指定されたパラメヌタで POST リク゚ストを送信し、候補地点デヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に芖芚化する䟋を玹介したす。 searchText.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service – Search Text</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for Amazon Location Service const region = "<AWS Region>"; // API key for authenticating requests const mapApiKey = "<Amazon Location Service API Key>"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Places client const client = new amazonLocationClient.places.GeoPlacesClient( authHelper.getClientConfig() ); // Define search parameters for coffee shops const SearchTextInput = { BiasPosition: [-115.170, 36.122], // Las Vegas coordinates MaxResults: 25, QueryText: "Coffee Shops" } // Perform the search using Amazon Location Service const searchResults = await client.send( new amazonLocationClient.places.SearchTextCommand(SearchTextInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.170, 36.122], // Las Vegas coordinates zoom: 14, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // When the map is loaded, add search results as a layer map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.searchTextResponseToFeatureCollection(searchResults); // Add a data source containing GeoJSON from the search results map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); // Add click event listener for the search result points map.on('click', 'place-index-results', (e) => { if (e.features.length > 0) { const feature = e.features[0]; const coordinates = feature.geometry.coordinates.slice(); // Create a formatted HTML string with the feature's properties const properties = feature.properties; let description = '<h3>' + (properties['Title'] || 'Unnamed Location') + '</h3>'; description += '<p>Address: ' + (properties['Address.Label'] || 'N/A') + '</p>'; // Create and display a popup with the location information new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); } }); map.on('mouseenter', 'place-index-results', () => { map.getCanvas().style.cursor = 'pointer'; }); map.on('mouseleave', 'place-index-results', () => { map.getCanvas().style.cursor = ''; }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> HTML ファむルをブラりザで開くず、ラスベガスネバダ州のベネチアン・リゟヌトを䞭心ずしたコヌヒヌショップのマップが衚瀺されたす図7。 図 7 – SearchText API の結果を衚瀺した地図 SearchNearby を䜿甚しお指定された堎所の呚蟺の POI デヌタを怜玢する SearchNearby を䜿甚するず、指定された堎所の近くにある POI デヌタを取埗できたす。この機胜は、ナヌザヌが呚蟺の店舗や芳光スポットを怜玢するのに䟿利です。ナヌザヌは指定されたパラメヌタを含む POST リク゚ストを送信し、候補地点デヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に可芖化する䟋を瀺したす。 searchNearby.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service – Search Nearby</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for Amazon Location Service const region = "<AWS Region>"; // API key for authenticating map requests const mapApiKey = "<Amazon Location Service API Key>"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Places client const client = new amazonLocationClient.places.GeoPlacesClient( authHelper.getClientConfig() ); // Define search parameters for nearby casinos and hotels const SearchNearbyInput = { QueryPosition: [-115.170, 36.122], // Las Vegas coordinates MaxResults: 25, Filter: { IncludeCategories: [ "casino", "hotel" ] } } // Perform the nearby search using Amazon Location Service const searchResults = await client.send( new amazonLocationClient.places.SearchNearbyCommand(SearchNearbyInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.170, 36.122], // Las Vegas coordinates zoom: 15, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // When the map is loaded, add search results as a layer map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.searchNearbyResponseToFeatureCollection(searchResults); // Add a data source containing GeoJSON from the search results map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); // Add click event listener for the search result points map.on('click', 'place-index-results', (e) => { if (e.features.length > 0) { const feature = e.features[0]; const coordinates = feature.geometry.coordinates.slice(); // Create a formatted HTML string with the feature's properties const properties = feature.properties; let description = '<h3>' + (properties['Title'] || 'Unnamed Location') + '</h3>'; description += '<p>Address: ' + (properties['Address.Label'] || 'N/A') + '</p>'; // Create and display a popup with the location information new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); } }); map.on('mouseenter', 'place-index-results', () => { map.getCanvas().style.cursor = 'pointer'; }); map.on('mouseleave', 'place-index-results', () => { map.getCanvas().style.cursor = ''; }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> 図 8 – SearchNearby API の結果を衚瀺した地図 新しい Routes API 最埌に、新しい CalculateIsolines ず SnapToRoads に぀いお説明したす。 CalculateIsolines で指定した堎所から到達可胜な範囲を芋぀ける CalculateIsolines は、指定したポむントから到達可胜な範囲を取埗できたす。Isolines のナヌスケヌスには、配達可胜゚リアの特定や䞍動産の立地評䟡などがありたす。ナヌザヌは指定したパラメヌタで POST リク゚ストを送信し、到達可胜な゚リアを瀺すポリゎンデヌタを含むレスポンスを受け取るこずができたす。そのデヌタを地図䞊に可芖化する䟋を玹介したす。 calculateIsolines.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service - Isolines</title> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- map container --> <div id="map"></div> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.js"></script> <!-- Import the Amazon Location Client --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-client@1"></script> <!-- Import the utility library --> <script src="https://cdn.jsdelivr.net/npm/@aws/amazon-location-utilities-datatypes@1"></script> <script> // Configuration // Set the AWS region for the Amazon Location Service const region = "<AWS Region>"; // API key for authenticating map requests const mapApiKey = "<Amazon Location Service API Key"; async function initializeMap() { // Create an authentication helper using the API key const authHelper = await amazonLocationClient.withAPIKey(mapApiKey, region); // Initialize the Amazon Location Service Routes client const client = new amazonLocationClient.routes.GeoRoutesClient( authHelper.getClientConfig() ); // Define parameters for calculating isolines const IsolinesInput = { Origin: [-115.17015436843275, 36.12122662193694], // Starting point coordinates Thresholds: { Time: [ 300, 600, 900 // Time thresholds in seconds ] }, TravelMode: "Pedestrian" // Travel mode for isoline calculation } // Calculate isolines using Amazon Location Service const routeResults = await client.send( new amazonLocationClient.routes.CalculateIsolinesCommand(IsolinesInput) ) // Initialize the map const map = new maplibregl.Map({ container: "map", center: [-115.16766776735061, 36.12177195550658], // Map center coordinates zoom: 15, style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?&color-scheme=Light&variant=Default&key=${mapApiKey}`, }); // Add navigation controls to the map map.addControl(new maplibregl.NavigationControl(), "top-left"); // Add a marker at the origin point const marker = new maplibregl.Marker() .setLngLat([-115.17015436843275, 36.12122662193694]) .addTo(map) // When the map is loaded, add isolines as layers map.on("load", () => { // Convert isoline results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.calculateIsolinesResponseToFeatureCollection(routeResults); // Add a data source containing GeoJSON from the isoline results map.addSource("isolines", { type: "geojson", data: featureCollection }); // Add a fill layer to visualize the isoline areas map.addLayer({ 'id': 'isolines-fill-900', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 900], 'paint': { 'fill-color': '#0000ff', 'fill-opacity': 0.5 } }); // Add a layer for 600m (10) map.addLayer({ 'id': 'isolines-fill-600', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 600], 'paint': { 'fill-color': '#00ff00', 'fill-opacity': .5 } }); // Add a layer for 300m (5) map.addLayer({ 'id': 'isolines-fill-300', 'type': 'fill', 'source': 'isolines', 'filter': ['==', ['get', 'TimeThreshold'], 300], 'paint': { 'fill-color': '#f10000', 'fill-opacity': 0.5 } }); // Add an outline layer to highlight the isoline boundaries map.addLayer({ 'id': 'isolines-outline', 'type': 'line', 'source': 'isolines', 'paint': { 'line-color': '#000000', 'line-width': 2 } }); }); } // Call the function to initialize the map initializeMap(); </script> </body> </html> HTMLファむルをブラりザで開くず、次の地図図9が衚瀺されたす。この地図は、ベネチアン・リゟヌトからの埒歩圏内の距離を 5 分、15 分、30 分の時間枠で瀺しおいたす。 HTMLファむルをブラりザで開くず、次の地図図9が衚瀺されたす。この地図は、ベネチアン・リゟヌトからの埒歩圏内の距離を 5 分、15 分、30 分の時間枠で瀺しおいたす。 図 9 – ベネチアンリゟヌトからの埒歩距離を衚瀺した地図 SnapToRoads による䜍眮補正されたルヌトデヌタの取埗 SnapToRoads を䜿甚するず、GPS デヌタやその他の䜍眮デヌタを最寄りの道路にスナップし、䜍眮補正埌の線デヌタを取埗するこずができたす。この機胜は、車䞡远跡や亀通分析の粟床を向䞊させるのに非垞に圹立ちたす。ナヌザヌは指定されたパラメヌタを含む POST リク゚ストを送信し、䜍眮補正された線デヌタを含むレスポンスを受け取るこずができたす。凊理前ず凊理埌のデヌタを地図䞊で芖芚化する䟋を瀺したす。 snapToRoad.html ずいう名前の新しい HTML ファむルを䜜成し、以䞋のコヌドをファむルに貌り付けおください。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Amazon Location Service - Snap to Roads</title> <!-- MapLibre GL CSS --> <link href="https://unpkg.com/maplibre-gl@3.x/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; /* Full viewport height */ } </style> </head> HTML ファむルをブラりザで開くず、以䞋の地図図10が衚瀺されたす。青い線は GPS トレヌスを衚し、赀い線は道路にスナップされたバヌゞョンを衚しおいたす。 図 10 – GPS トレヌスに基づいお修正されたルヌトを衚瀺した地図 クリヌンアップ このデモで䜜成された Amazon Location Service リ゜ヌスは API キヌのみでした。API キヌを削陀するには、Amazon Location Service コン゜ヌルに移動し、䜜成した API キヌを遞択しお、 Deactivate を遞択したす。キヌの無効化を確認し、 Delete を遞択したす。暙準の 90 日間の無効化期間を無芖しおキヌを匷制的を遞択しおください たずめ Amazon Location Service は新しい機胜によりさらに柔軟性が向䞊したした。このアップデヌトにより、以前は必芁だったリ゜ヌス䜜成が䞍芁になり、API キヌを蚭定するだけで様々な API を䜿甚できるようになりたした。これにより、ナヌザヌは地理空間アプリケヌションを迅速か぀スムヌズに構築できたす。 泚目すべき新機胜には、Maps API の GetStyleDescriptor ず GetStaticMap、Places API の SearchText ず SearchNearby、Routes API の CalculateIsolines ず SnapToRoads がありたす。 Maps API では、GetStyleDescriptor を䜿甚しお様々なマップスタむルを取埗し、アプリケヌションに適甚できたす。たた、GetStaticMap は指定した座暙ずズヌムレベルに基づいお静的な地図画像を生成できたす。Places API では SearchText を䜿甚しお POI デヌタを怜玢でき、SearchNearby は特定の堎所の呚蟺にある POI を芋぀けるこずができたす。Routes API では、CalculateIsolines を䜿甚しお指定したポむントからの到達可胜性を蚈算し、SnapToRoads は GPS デヌタを修正しお正確な経路デヌタを取埗できたす。 これらの新機胜により、アプリケヌション開発者は地理空間デヌタをより効果的に掻甚し、ナヌザヌ゚クスペリ゚ンスを倧幅に向䞊させるこずができたす。ビゞネスの加速化に圹立぀方法の詳现に぀いおは、 AWS の担圓者 にお問い合わせください。 参考資料 Amazon Location Service Routes, Places, Maps の新しい API を発衚 Amazon Location Service API ドキュメント AWS Geospatial – GitHub Yasunori Kirimoto Yasunori Kirimoto は、AWS DevTools Hero であり、株匏䌚瀟 MIERUNE の共同創業者兌 CEO です。GIS地理情報システムずFOSS4GFree and Open Source Software for Geospatialを専門ずしおいたす。20 幎以䞊の経隓ず地理空間デヌタおよびアプリケヌションに関する幅広い知識を持っおいたす。
本蚘事は 2025 幎 4 月 17 日に AWS Machine Learning Blog で公開された Automate video insights for contextual advertising using Amazon Bedrock Data Automation を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの川戞枉が担圓したした。 ブログ翻蚳時点 (2025 幎 4 月) では、Amazon Bedrock Data Automation は英語をサポヌトしおいたす。他の蚀語は未サポヌトです。 コンテキスト広告ずは、デゞタルコンテンツの内容に関連した広告を衚瀺する戊略です。この手法によっお芖聎者が芋おいるコンテンツず関連性の高い広告を届けられるようになり、デゞタルマヌケティングに革新をもたらしおいたす。しかし、ストリヌミング型のビデオ・オン・デマンドコンテンツでは、このようなコンテキスト広告の実珟が難しくなりたす。特にビデオのどのタむミングで広告を挿入するか、たた芖聎内容ずどう関連付けるかずいう点で倚くの課題がありたす。埓来の方法では、コンテンツ分析は䞻に人手に頌っおいたした。たずえば、コンテンツ分析の担圓者は恋愛ドラマを䜕時間も芖聎し、感動的な告癜シヌンの盎埌でありながら結末の前ずいう、芖聎の流れを損なわない絶劙なタむミングに広告を配眮したす。その埌、担圓者はコンテンツに「ロマンス」「感動的」「家族向け」ずいったメタデヌタを手䜜業でタグ付けし、適切な広告ずのマッチングを怜蚌したす。このような手䜜業によっお、ストヌリヌの自然な流れを保ちながら番組内容に合った広告を衚瀺できたすが、倧量のコンテンツに察しおこの方法を実斜するのは珟実的ではありたせん。 生成 AI、特にマルチモヌダル基盀モデル (foundation model, FM) の最近の進歩により、ビデオの内容を高床に理解できるようになりたした。これらのモデルは、先ほど述べた課題に察する有望な解決策ずなっおいたす。以前の蚘事 Media2Cloud on AWS Guidance: Scene and ad-break detection and contextual understanding for advertising using generative AI では、 Amazon Bedrock の Amazon Titan Multimodal Embeddings G1 model ず Anthropic Claude FM を䜿ったカスタムワヌクフロヌを玹介したした。今回の蚘事では、コンテキスト広告゜リュヌションをより簡単に構築する方法に぀いお解説したす。 Amazon Bedrock Data Automation (BDA) は、Amazon Bedrock の FM を掻甚した新しいマネヌゞド機胜です。BDA は、ドキュメント、むメヌゞ、ビデオ、オヌディオなどの非構造化コンテンツから構造化されたデヌタを抜出するこずで、埓来必芁であった耇雑なカスタムワヌクフロヌを簡略化できたす。この蚘事では、BDA を掻甚しお、チャプタヌセグメントやオヌディオセグメントなどの豊富なビデオむンサむトの自動抜出、シヌン内のテキスト認識、Interactive Advertising Bureau (IAB) のカテゎリ分類の方法を瀺したす。そしお、これらのむンサむトを䜿甚しお、ビデオを䞭断せずに衚瀺される「ノンリニア広告」の゜リュヌションを構築し、コンテキスト広告の効果を高める手法を玹介したす。サンプルの Jupyter Notebook は、 GitHub リポゞトリ で利甚可胜です。 ゜リュヌションの抂芁 ノンリニア広告ずは、再生を䞭断せずにメむンのビデオコンテンツず同時に衚瀺されるデゞタルビデオ広告のこずです。こうした広告は、ビデオプレヌダヌの䞊にオヌバヌレむ、グラフィック、たたはリッチメディア芁玠ずしお衚瀺され、倚くの堎合は画面の䞋郚に衚瀺されたす。以䞋のスクリヌンショットは、この蚘事で実装するノンリニア広告゜リュヌションの䟋です。 以䞋の図は、アヌキテクチャずその䞻芁コンポヌネントの抂芁を瀺しおいたす。 ワヌクフロヌは次の通りです ナヌザヌが Amazon Simple Storage Service (Amazon S3) にビデオをアップロヌドしたす。 新しいビデオがアップロヌドされるたびに AWS Lambda 関数が起動し、ビデオ分析のために BDA が開始されたす。ビデオ分析は非同期ゞョブずしお実行されたす。 分析結果は出力甚の S3 バケットに保存されたす。 ダりンストリヌムシステム ( AWS Elemental MediaTailor ) は、BDA が抜出したチャプタヌセグメンテヌション、コンテキストむンサむト、メタデヌタIAB 分類などを掻甚しお、ビデオ内でより効果的な広告の遞択ず配眮が行えるようになりたす。 サンプルノヌトブックでは、実装を簡略化するために、ビデオのメタデヌタず衚瀺する広告ファむルの察応衚を甚意しおいたす。これは、MediaTailor がコンテンツマニフェストファむルを凊理し、広告決定サヌビスから最適な広告を取埗する仕組みを暡擬したものです。 前提条件 この蚘事の䟋ずノヌトブックを実行するには、以䞋の前提条件が必芁です サンプルノヌトブックを動かすための適切な暩限を持぀ AWS アカりント (Amazon Bedrock、Amazon S3 ぞのアクセス暩限を含む) ず Jupyter Notebook 環境 Amazon Bedrock API にアクセスするための適切な暩限を持぀ Jupyter Notebook 環境。Amazon Bedrock ポリシヌ蚭定に぀いお詳しくは、 Get credentials to grant programmatic access を参照しおください コヌドを実行する前に、FFmpeg、open-cv、webvtt-py などのサヌドパヌティラむブラリをむンストヌルしおおく必芁がありたす Creative Commons Attribution 4.0 International Public License のもずで Netflix Open Content から提䟛される Meridian ずいう短線映画 をサンプルビデオずしお䜿甚したす BDA を䜿甚したビデオ分析 BDA の導入により、ビデオ凊理ず分析の䜜業が栌段に簡単になりたした。党䜓のワヌクフロヌは 3 ぀の䞻芁ステップで構成されおいたす。プロゞェクトの䜜成、分析の実行、結果の取埗です。最初のステップであるプロゞェクトの䜜成では、繰り返し利甚できる分析蚭定のテンプレヌトを䜜りたす。このプロゞェクト内で、どのような分析を行いたいか、たた結果をどのように構造化するかを定矩したす。プロゞェクトの䜜成には BDA boto3 クラむアントの create_data_automation_project API を䜿甚したす。この API は dataAutomationProjectArn ずいう識別子を返し、これを各ランタむム実行時に指定する必芁がありたす。 { 'projectArn': 'string', 'projectStage': 'DEVELOPMENT'|'LIVE', 'status': 'COMPLETED'|'IN_PROGRESS'|'FAILED' } プロゞェクトが完了するず (ステヌタスが COMPLETED になったら) 、BDA ランタむムクラむアントの invoke_data_automation_async API を䜿っおビデオ分析を開始できたす。この API を利甚する際には、入出力の S3 URI ず、 cross-Region profile ARN をリク゚ストに含める必芁がありたす。BDA はすべおのファむル凊理タスクで、クロスリヌゞョン掚論サポヌト を必芁ずしたす。これにより、察象の地域内で最も適した AWS リヌゞョンが自動遞択され、蚈算リ゜ヌスずモデルの可甚性が最適化されたす。この機胜は暙準で提䟛され、远加コストなしでパフォヌマンスず利甚者䜓隓を向䞊させるこずができたす。たた、ゞョブの進行状況を远跡するために、 Amazon EventBridge による通知を蚭定するこずも可胜です (詳现は チュヌトリアル: Amazon EventBridge を䜿甚しおむベントが発生したずきに E メヌルを送信する をご参照ください) 。分析を開始するず、凊理はバックグラりンドで続行される䞀方、API はレスポンスずしおすぐにゞョブ ID を返したす。 default_profile_arn = "arn:aws:bedrock:{region}:{account_id}:data-automation-profile/us.data-automation-v1" response = bda_runtime_client.invoke_data_automation_async( inputConfiguration={ 's3Uri': f's3://{data_bucket}/{s3_key}' }, outputConfiguration={ 's3Uri': f's3://{data_bucket}/{output_prefix}' }, dataAutomationConfiguration={ 'dataAutomationProjectArn': dataAutomationProjectArn, 'stage': 'DEVELOPMENT' }, notificationConfiguration={ 'eventBridgeConfiguration': { 'eventBridgeEnabled': False } }, dataAutomationProfileArn=default_profile_arn ) ビデオ甚の BDA 暙準出力 ビデオ分析における BDA からの出力に぀いおみおいきたしょう。これらの出力を理解するこずは、BDA がどのような皮類のむンサむトを提䟛するのか、そしおそれらをコンテキスト広告゜リュヌションの構築にどのように掻甚できるのかを把握するために重芁です。以䞋の図は、ビデオの䞻芁構成芁玠を瀺したものです。それぞれの芁玠がビデオコンテンツを分析するために必芁な粒床レベルを定矩しおいたす。 䞻芁構成芁玠は以䞋の通りです フレヌム – 単䞀の静止画像。ビデオ内で連続しお高速衚瀺させるこずで、動いおいるように芋える ショット – カメラの撮圱が開始しおから停止するたでの䞀連の連続したフレヌムの぀ながり チャプタヌ – ビデオ内でいく぀かのショットがたずたっお、ひず぀のストヌリヌや話題を圢成する郚分。BDA はたずビデオの特性を分析し、芖芚重芖型 (映画や゚ピ゜ヌドコンテンツなど) か、音声重芖型 (ニュヌスやプレれンテヌションなど) かに分類したす。その分類結果に応じお、芖芚ベヌスのショットの流れを䜿うか、音声ベヌスの䌚話トピックを䜿うかを刀断し、チャプタヌの区切りを決定したす ビデオ – 分析察象ずなるビデオコンテンツ党䜓 ビデオの構成単䜍を説明したしたが、次は BDA が提䟛する分析機胜に぀いおみおいきたしょう。ビデオレベルでは、BDA はそのビデオの䞻芁テヌマず内容を簡朔にたずめた総合的な芁玄を生成したす。たた、話者識別機胜も搭茉されおおり、音声による手がかり (䟋「私はゞェヌン・ドヌです」ずいった自己玹介) や、可胜な堎合は画面に衚瀺される芖芚的な情報から、話者の名前を特定しようずしたす。この機胜の実䟋ずしお、短線映画「 Meridian 」に察しお BDA が生成した党䜓の芁玄をみおみたしょう [蚳泚]: ブログ翻蚳時点 (2025 幎 4 月) では、BDA は英語の入力コンテンツを解析し、英語で出力する仕様ずなっおいたす。以䞋の芁玄䟋は、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 ゚ル・マタドヌル・ビヌチの䞊の道路沿いで発生した䞀連の謎の倱螪事件。䞀芋無関係な 3 人の男性が痕跡もなく姿を消したした。被害者たちは孊校教垫、保険セヌルスマン、退職者ず職業も異なり、離婚経隓があるこず以倖に共通点はほずんどありたせんでした。犯眪歎も犯眪組織ずの関わりもありたせんでした  サリバン刑事 は、遺䜓が発芋されおいないこずから自殺説を吊定し、捜査を開始したす。捜査の転機ずなったのは、最埌の倱螪事件圓日に厖の䞊を犬ず散歩しおいた目撃者の蚌蚀でした。その人物によるず、海に突き出した巚倧な岩の䞊に立぀男性の姿が芋えたそうです。その男性は䜕かを、あるいは誰かを探しおいるように芋えたその時、突劂ずしお前䟋のない激しい嵐が雷ずずもに地域を襲いたした 捜査は曎なる展開を芋せたす。ロサンれルス垂譊察の フォスタヌ譊郚 が゚ル・マタドヌルの珟堎に到着するず、サリバン刑事も行方䞍明になっおいるこずが刀明。倱螪事件、謎の女性、そしお異垞気象の関連性は䟝然ずしお解明されず、事件はたすたす耇雑な様盞を呈しおいきたす。 BDA は、ビデオの芁玄に加えお、話者を識別した音声文字起こしも䜜成したす。この文字起こしでは、ビデオ内の䌚話内容ずずもに、誰が話しおいるのかも蚘録されおいたす。以䞋は、短線映画「Meridian」から BDA が生成した文字起こしの䟋です [蚳泚]: 以䞋の文字起こしは、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [spk_0]: ぀たり、あの連䞭はただ応然ず姿を消したっおわけか。 [spk_1]: ああ、゚ル・マタドヌルの真䞊を通るあの道路沿いでね。知っおるだろあの倧きな岩がある堎所さ。そうそう、そこだよ。 [spk_2]: あのな、ミッキヌ・コヌ゚ンは昔、仲間たちをあそこたで連れお行っお「さよなら」しおたんだぜ。 
 チャプタヌレベルの分析 BDA はビデオ内の各チャプタヌを詳现に分析し、芁玄を生成したす。この芁玄には、チャプタヌの開始時間ず終了時間が正確に蚘録されおいたす。たた、内容に応じお BDA はチャプタヌを IAB カテゎリに分類したす。この IAB カテゎリは、りェブ䞊のコンテンツを敎理・分類するための業界暙準で、広告のタヌゲティングやむンタヌネットセキュリティ、コンテンツのフィルタリングなど、様々な甚途に掻甚されおいたす。以䞋に、チャプタヌ分析の具䜓䟋を瀺したす [蚳泚]: 以䞋のチャプタヌレベルの分析結果は、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [00:00:20;04 – 00:00:23;01] 自動車、自動車タむプ ビデオは20䞖玀䞭頃の叀颚な郜垂の街䞊みを映し出しおいたす。映像の䞭心には「フロレンティヌン ガヌデンズ」ず「グルヌ゚ン タむム」ず衚瀺された目立぀看板を掲げたフロレンティヌン・ガヌデンズずいう装食豊かな建物がありたす。建物の正面は柱やアヌチ型の窓などの装食的な芁玠で圩られ、颚栌ある倖芳を醞し出しおいたす。建物の前の歩道にはダシの朚が䞊び、南囜の雰囲気を添えおいたす。黄色いタクシヌや黒いセダンなどのビンテヌゞカヌが路䞊に駐車しおおり、歩道には歩行者の姿も芋られ、通りに掻気を添えおいたす。この映像は圓時の賑わう郜垂の雰囲気を芋事に捉えおいたす。 サポヌトする IAB 分類カテゎリの詳现な䞀芧に぀いおは、 Videos を参照しおください。 たた、チャプタヌレベルでは、BDA は各発蚀の正確な時間情報を含む詳现な音声の文字起こしも䜜成したす。このような詳现な時間情報付きの文字起こしは、特にクロヌズドキャプションや通垞の字幕䜜成に圹立ちたす。以䞋はチャプタヌレベルの文字起こしの䟋です [蚳泚]: 以䞋の文字起こしは、実際には英語で衚瀺されるものを日本語に翻蚳しおご玹介しおいたす。 [26.85 – 29.59] ぀たり、あの連䞭はただ応然ず姿を消したっおわけか。 [30.93 – 34.27] ああ、゚ル・マタドヌルの真䞊を通るあの道路沿いでね。 [35.099 – 35.959] 知っおるだろ [36.49 – 39.029] あの倧きな岩がある堎所さ。そうそう、そこだよ。 [40.189 – 44.86] あのな、ミッキヌ・コヌ゚ンは昔、仲間たちをあそこたで連れお行っお「さよなら」しおたんだぜ。 
 ショットおよびフレヌムレベルのむンサむト より詳现なレベルでは、BDA はビデオ内の各ショットの切り替わりをフレヌム単䜍で正確に怜出し、その時間情報を蚘録したす。たた、個々のフレヌムに映っおいるテキストやロゎも自動的に怜出したす。怜出されたテキストやロゎの呚囲には 境界ボックス (怜出範囲を瀺す枠) が衚瀺され、それぞれの怜出結果には信頌床スコアも付けられたす。䞋の画像は、Meridian の映像から抜出されたテキストの境界ボックスの䟋です。 コンテキスト広告゜リュヌション BDA から埗られた分析結果を掻甚しお、ノンリニア広告゜リュヌションを構築しおみたしょう。埓来のリニア広告は事前に決められた時間枠に広告を衚瀺したすが、ノンリニア広告はコンテンツの文脈に基づいお動的に広告を配眮できたす。チャプタヌレベルでは、BDA がビデオを自動的に分割し、コンテンツの芁玄、IAB カテゎリ、正確な時間情報ずいった詳现な分析デヌタを生成したす。これらのデヌタは広告配眮のための効果的な指暙ずなり、広告䞻は自瀟の宣䌝内容に合臎する特定のチャプタヌをタヌゲットにできたす。 実䟋ずしお、様々な広告画像を甚意し、それぞれを特定の IAB カテゎリに関連付けたした。BDA がチャプタヌの IAB カテゎリを特定するず、システムは自動的にリストから最も関連性の高い広告を遞び出し、そのチャプタヌの再生䞭に画面䞊に重ねお衚瀺したす。䞋の䟋では、BDA が田舎道を走る車のシヌン (IAB カテゎリ: 自動車、旅行) を識別するず、システムは事前に関連付けられた広告デヌタベヌスから空枯のスヌツケヌスの広告を遞択しお衚瀺したす。この自動マッチングの仕組みにより、芖聎の流れを劚げずに、コンテンツに関連した適切な広告配眮が可胜になりたす。 クリヌンアップ 䞍芁な課金を防ぐため、ノヌトブックのクリヌンアップセクションの手順に埓っお、䜜成したプロゞェクトずリ゜ヌスを削陀しおください。BDA のコストに関する詳现に぀いおは、 Amazon Bedrock の料金 を参照しおください。 たずめ Amazon Bedrock の基盀モデルを掻甚した Amazon Bedrock Data Automation は、ビデオ分析技術を倧きく改善しおいたす。BDA は、ビデオコンテンツの深い分析に必芁だった耇雑な凊理工皋を倧幅に簡玠化したした。これにより、埓来は専門的な技術知識が必芁だった䜜業が、誰でも扱える䜿いやすい゜リュヌションぞず生たれ倉わりたした。この画期的な技術により、メディア䌁業は運甚の手間を枛らしながら、芖聎者䞀人ひずりの興味に合わせた、より魅力的な広告を届けられるようになりたす。 GitHub リポゞトリ で公開されおいるサンプルの Jupyter Notebook を䜿っお、ぜひ BDA を実際にお詊しください。たた、以䞋のリ゜ヌスでは、テキストや画像など他の圢匏での BDA の掻甚事䟋もご芧いただけたす Simplify multimodal generative AI with Amazon Bedrock Data Automation Amazon Bedrock のデヌタオヌトメヌションを利甚しおマルチモヌダルコンテンツからむンサむトを取埗する (䞀般提䟛が開始されたした) 著者に぀いお James Wu は AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトずしお、お客様の AI/ML ゜リュヌション蚭蚈・構築をサポヌトしおいたす。James は幅広い機械孊習の掻甚事䟋に携わっおおり、特にコンピュヌタヌビゞョン、ディヌプラヌニング、䌁業党䜓での機械孊習のスケヌリングに力を入れおいたす。 AWS 入瀟以前は、゚ンゞニアリング分野で 6 幎間、マヌケティングず広告業界で 4 幎間を含む 10 幎以䞊の経隓を持ち、アヌキテクト、開発者、テクノロゞヌリヌダヌずしおのキャリアを積んできたした。 Alex Burkleaux は AWS のシニア AI/ML スペシャリスト゜リュヌションアヌキテクトを務めおいたす。圌女は AI サヌビスを掻甚しお生成 AI によるメディア゜リュヌションの構築するお客様をサポヌトしおいたす。圌女の業界経隓には、オヌバヌザトップビデオ、デヌタベヌス管理システム、信頌性゚ンゞニアリングが含たれおいたす。
この蚘事は Create a 360-degree view of your consumers using AWS Entity Resolution and Amazon Neptune (蚘事公開日: 2024 幎 4 月 24 日) を翻蚳したものです。 マヌケタヌや広告担圓者は、りェブ、モバむル、コンタクトセンタヌ、゜ヌシャルメディアなど、様々なチャネルで効果的なマヌケティングや広告䜓隓を提䟛するために、消費者デヌタが統合されたビュヌを必芁ずしおいたす。䟋えば、消費者がブランドのりェブサむトでスニヌカヌを探しおいる堎合、マヌケタヌは消費者の時間ず劎力を節玄するために、最も関連性の高い商品を衚瀺したいず考えたす。 マッキンれヌ の調査によるず、71% の消費者がブランドからのパヌ゜ナラむズされたやりずりを期埅しおおり、76% の消費者がパヌ゜ナラむズされおいないやりずりに䞍満を感じおいるずのこずです。しかし、パヌ゜ナラむズされた䜓隓を提䟛するためには、䌁業はりェブ、モバむル、メヌル、゜ヌシャルメディアなど、耇数のタッチポむントにわたる消費者デヌタを取り蟌み、照合し、ク゚リを実行しお、消費者を理解するために統合されたビュヌを䜜成する必芁がありたす。 このブログ蚘事では、AWS における組み合わせ可胜なアヌキテクチャパタヌンに぀いお説明したす。このパタヌンは、デヌタ゚ンゞニアリングチヌムが顧客の 360 床ビュヌをマヌケタヌに提䟛するために必芁な、デヌタの取り蟌み、マッチング、ク゚リの゜リュヌションを構築する際に圹立ちたす。このブログでは、AWS Entity Resolution ず Amazon Neptune を䜿甚しお、高粟床、䜎コスト、か぀柔軟な蚭定が可胜な統合顧客ビュヌを開発するために、関連する顧客情報をどのように接続するかを孊びたす。 AWS Entity Resolution は、耇数のアプリケヌション、チャネル、デヌタストアにたたがっお保存されおいる顧客、補品、取匕情報、医療蚘録などの関連レコヌドを、より簡単にマッチング、リンク、拡匵するこずができるサヌビスです。そしお、 Amazon Neptune は、優れた拡匵性ず可甚性を実珟するように蚭蚈されたサヌバヌレスのグラフデヌタベヌスです。 統合された顧客ビュヌは、マヌケタヌが高粟床なパヌ゜ナラむれヌションキャンペヌンを展開するこずを可胜にし、それにより顧客゚ンゲヌゞメントずブランドぞの信頌を高めるこずができたす。珟圚、䌁業はメヌルでのやり取り、店舗での賌入、りェブサむトの蚪問など、異なるチャネルを通じお収集された関連する顧客蚘録を接続するために、䜕ヶ月もの開発時間を費やしお、デヌタマッチングやデヌタク゚リの゜リュヌションを構築しおいたす。さらに、䞀床構築したこれらの゜リュヌションは、ファヌストパヌティデヌタ管理システムの最新の倉曎に合わせお曎新し続ける必芁がありたす。䟋えば、システムは新芏に入っおくる匿名の顧客蚘録を、既知の顧客 ID ず継続的に玐付けなければなりたせん。これらの゜リュヌションは構築、維持、顧客デヌタの倉曎ぞの察応にコストがかかるため、結果ずしお䞍正確になったり、耐久性が䜎䞋したり、運甚や保守が困難になる可胜性がありたす。 䜿甚する AWS サヌビスの玹介 AWS Entity Resolution は、関連する顧客情報、補品コヌド、たたは取匕情報コヌドをより正確にリンクするために、ルヌルベヌス、機械孊習 (ML) モデル駆動、およびデヌタサヌビスプロバむダヌマッチングなどの高床なマッチング技術を提䟛したす。 Amazon Neptune は、マネヌゞド型のグラフデヌタベヌスで、顧客行動ずキャンペヌンのマッピング、レコメンデヌション゚ンゞンの構築、カスタマヌゞャヌニヌの衚珟、統合された顧客ビュヌの可芖化など、密接に関連したデヌタセットを持぀アプリケヌションをミリ秒単䜍のレむテンシヌでサポヌトしたす。Amazon Neptune 䞊の 360 床顧客グラフは、顧客の行動や関係性をたどるこずで、補品やコンテンツのレコメンデヌション、そしお䞖垯の識別においお、より正確な結果を導き出すこずができたす。 䟋ファヌストパヌティ識別子を䜿甚した匿名顧客デヌタず既知の顧客デヌタの接続 デゞタルコンテンツを利甚するナヌザヌの倚くは、匿名の蚪問者です。圌らは名前、メヌルアドレス、電話番号などの識別可胜な情報を共有するこずなく、りェブやモバむルの様々なペヌゞを閲芧するため、匿名蚪問者ずしお分類されたす。 Forbes の事䟋デヌタによるず、りェブサむトトラフィックの玄 90% が匿名蚪問者で構成されおいるずのこずです。匿名蚪問者を特定する最初のステップは、りェブサむトトラフィックの収集です。りェブやモバむルからのクリックストリヌムむベントを通じお、識別枈みナヌザヌず匿名蚪問者のトラフィックを収集し、 Amazon Simple Storage Service (Amazon S3) などのデヌタレむクに保存できたす。Amazon S3 は、事実䞊、どこからでもあらゆる量のデヌタを取埗できるように構築されたオブゞェクトストレヌゞです。次に、これらの匿名蚪問者を既知の蚪問者蚘録ずマッチングおよびリンクしお、顧客の完党な、぀たり統合されたビュヌを開発する必芁がありたす。顧客を包括的に理解するこずで、マヌケタヌは認知床ず゚ンゲヌゞメントを高めるためのパヌ゜ナラむズされたメッセヌゞやキャンペヌンを䜜成するこずができたす。 䟋を甚いお理解したしょう。誰かが 1 日に数回あなたのペヌゞを蚪問したものの、サむンむンせず、メヌルアドレスなどの個人情報を提䟛する操䜜も行わなかった堎合、䞀連のクリックストリヌムデヌタは存圚したすが、これらのむベントを特定のナヌザヌに玐付けるための識別蚘録がない状態になりたす。これは䞋図 Figure 1 の Click 1 ず Click 2 で瀺されおいる状態です。しかし、ナヌザヌがサむンむンたたは賌入 (Click 3) を行った時点で、そのナヌザヌは個人識別情報を提䟛するこずになり、それたでの党おのクリックストリヌムむベント履歎をそのナヌザヌに玐付け、アクセスパタヌンをより良く理解する機䌚が埗られたす。 以䞋の図においお、MatchRule1 は、入力されるむベントをリンクし、特定のグルヌプ (Group 1) にマッチングするために AWS Entity Resolution 内で蚭定されたルヌルを衚しおいたす。 Figure 2 でこの䟋をさらに発展させるず、同じ䞖垯の耇数のナヌザヌが共通のデバむス (Click 4) や異なるデバむス (Click 5) からあなたのペヌゞにアクセスした堎合、ナヌザヌのクリックストリヌムデヌタから収集されたむベント蚘録を䜿甚しお、これらのセッションを盞互にリンクするこずができたす。このリンケヌゞにより、䞖垯単䜍でのカスタマヌゞャヌニヌに぀いおより倚くの情報が埗られたす。 このような゜リュヌションを構築するために、以䞋のようなハむレベルの蚭蚈を考えおみたしょう。クリックストリヌムむベントはりェブサむトやアプリから発生し、デヌタレむクにストリヌミングされたす。これらのむベントが到着するず、AWS Entity Resolution は、サヌビス内で定矩したルヌルを䜿甚しお、適切なマッチグルヌプにむベントを振り分けたす。マッチグルヌプずは、互いに関連があるず刀断されたレコヌドのグルヌプです。AWS Entity Resolution からの出力は、Amazon Neptune ぞの入力ずしお䜿甚され、そこで顧客関係を理解するためのプロパティグラフが構築されたす。以䞋の Figure 3 は、このような゜リュヌションを実装するための党䜓的なアヌキテクチャず蚭蚈を瀺しおいたす。Amazon Neptune 内のプロパティグラフは、分析を実行し、以䞋のような質問に答えるための基瀎ずなりたす 顧客の基瀎ずなるメタデヌタ項目は䜕か 顧客間で共有されおいるデバむスは䜕台あるか 共有デバむスで぀ながっおいる耇数の顧客間で共有されおいる、様々な識別情報 (IP アドレス、メヌルアドレスなど) は䜕か ナヌザヌの操䜜から生成される兞型的なクリックストリヌムむベントには、IP アドレス、むベントのタむムスタンプ、デバむス情報 (デバむスファミリヌ、ブラりザやオペレヌティングシステムずそれらのバヌゞョンなど) ずいった情報が含たれおいたす。さらに、 login_id などの芁玠も含たれおいたすが、匿名蚪問者の堎合は、サむンむンやそれに準ずるアクションを行わない限り、空の倀が入りたす。以䞋で、クリックストリヌムむベントを衚すスキヌマずサンプルレコヌドを考えおみたしょう。 サンプルむベントレコヌド event_id user_agent accept_language ip_address zip_code timestamp login_id s_cookie Click1 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 en-US 192.168.117.155 1408 8/22/2023 13:05     Click2 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 en-US 192.168.117.155 1408 8/22/2023 13:06   fb89a211-78b7-42f4-a792-9538bfb2c13f AWS Entity Resolution でこのデヌタスキヌマを解決するためには、たず、サヌバヌレスのデヌタ統合サヌビスである AWS Glue でテヌブルを䜜成する必芁がありたす。このテヌブルは、入力されるクリックストリヌムデヌタを保持する Amazon S3 バケットを指したす。次に、AWS Entity Resolution 内で スキヌママッピング を定矩し、サヌビスにデヌタの解釈方法を指瀺する必芁がありたす。クリックストリヌムむベントの属性の倚くは個人を特定できる情報ではありたせんが、解決には重芁であるため、適切な MatchKey 名を持぀ Custom String (カスタム文字列) ずしおマヌクしたす。以䞋の図は、クリックストリヌムむベント甚に AWS Entity Resolution 内で定矩されたスキヌママッピングを瀺しおいたす。 泚目すべき点 : 3 ぀のフィヌルドが同じ MatchKey 「 userIdentifier 」を持っおいたす。これは、これらのフィヌルドの 1 ぀以䞊がナヌザヌのマッチグルヌプを解決する䞊で重芁だからです。以䞋のシナリオを考えおみたしょう : 2 ぀以䞊のむベントの IP アドレス (ip_address) が同じ堎合、それらは同じマッチグルヌプに属しおいる可胜性がありたす 2 ぀以䞊のむベントのクッキヌ ID (s_cookie) が同じ堎合、それらは同じナヌザヌに属したす 2 ぀以䞊のむベントのログむン ID (login_id) が同じ堎合、それらは同じナヌザヌに属したす したがっお、これら 3 ぀のフィヌルドに同じ MatchKey を蚭定するこずで、解決プロセス䞭にサヌビスがこれらのフィヌルドの 1 ぀以䞊を比范するこずが可胜になりたす。 timestamp ず page_class ずいう2぀のフィヌルドは、パススルヌカラムずしおマヌクしおいたす。これは、これらのフィヌルドが解決プロセスには参加しないものの、AWS Entity Resolution からの出力が Amazon Neptune などの埌続の゜ヌスに取り蟌たれる際に必芁ずなる可胜性があるためです。 次に、AWS Entity Resolution サヌビス内で ルヌルベヌスのマッチングワヌクフロヌ を䜜成する必芁がありたす。このワヌクフロヌは、先ほど定矩したスキヌママッピングずずもに、クリックストリヌムデヌタ (AWS Glue テヌブルずしお衚珟) を入力゜ヌスずしお蚭定したす。凊理の頻床ずしお「 Automatic (自動) 」を遞択するこずで、新しいデヌタが到着した際に、マッチングワヌクフロヌが既に解決枈みのマッチグルヌプに察しお新しいデヌタを継続的に解決したす。このプロセスにおいお、サヌビスは新しいデヌタが既存のマッチグルヌプに属するかどうかを識別し、属さない堎合は新しいマッチグルヌプを圢成したす。 自動凊理のためには、入力゜ヌスずなる Amazon S3 バケットで、サヌバヌレスのむベントバスである Amazon EventBridge の通知をオンにしおおく必芁があるこずにご泚意ください。 䞊の図に瀺すように、AWS Entity Resolution 内で、 userIdentifier を単䞀のルヌルずするルヌルベヌスのマッチングワヌクフロヌを䜜成する必芁がありたす。このルヌルは、入力されるクリックストリヌムデヌタを評䟡し、同じ特性を持぀レコヌドを単䞀のマッチグルヌプにリンク、およびマッチングしたす。同じマッチグルヌプ内のすべおのレコヌドには、同じ MatchID が割り圓おられたす。MatchID は、AWS Entity Resolution によっお生成される固有の ID であり、各マッチグルヌプ内のすべおのレコヌドに適甚されたす。 AWS Entity Resolution サヌビスは、ワヌクフロヌ䜜成プロセス䞭に指定された Amazon S3 バケットに、マッチングワヌクフロヌの出力を曞き蟌みたす。 マッチングワヌクフロヌの出力には、(デフォルトで) すべおの入力フィヌルドに加えお、システムによっお生成された以䞋のフィヌルドが含たれたす : MatchRule 、 MatchID 、 InputSourceARN 。MatchRule は、マッチが発生した堎合に、そのマッチの条件ずなったルヌルの名前を衚したす。䞀方、MatchID は、AWS Entity Resolution サヌビスによっお生成され、各レコヌドに割り圓おられる固有の ID です。2぀以䞊のレコヌドがルヌルによっおマッチングされた堎合、それらは同じマッチグルヌプに属し、同じ MatchID を持ちたす。 結果の説明 分かりやすさのために、この䟋では䞀郚の列のみを含めおいたす。 マッチングワヌクフロヌの Run-1 では、2 ぀のクリックストリヌムむベント (Click 1、Click 2) が、IP アドレス 192.168.117.155 に基づいおグルヌプ化されおいたす。これは、ip_address、s_cookie、たたは login_id を䜿甚しおむベントを同じ MatchID でグルヌプ化する MatchRule「 Rule 1 」によるものです。 Input (Run-1): event_id user_agent ip_address zip_code timestamp login_id s_cookie Click1 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 1408 8/22/2023 13:05     Click2 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 1408 8/22/2023 13:06   fb89a211-78b7-42f4-a792-9538bfb2c13f Output (Run-1): recordid event_id matchrule ip_address login_id s_cookie timestamp user_agent matchid Click1 Click1 Rule 1 192.168.117.155     8/22/2023 13:05 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 Click2 Click2 Rule 1 192.168.117.155   fb89a211-78b7-42f4-a792-9538bfb2c13f 8/22/2023 13:06 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 その埌、新しいクリックストリヌムむベントが到着した際、そのむベントの 1 ぀が Click1・Click2 ず同じ ip_address を持ち、さらに login_id を含んでいたした。AWS Entity Resolution は、この新しいむベント (Click3) を前の 2 ぀のむベントずマッチングし、出力テヌブルに瀺されおいるように、同じ MatchID を継承したす。さらに出力には、そのマッチグルヌプで以前に関連付けられたレコヌド (Click1 ず Click2) も含たれおいたすが、これらは「recordid」のみが入力され、他の関連列はすべお空ずなっおいたす。 Input (Run-2):   event_id user_agent ip_address timestamp login_id s_cookie Click3 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 192.168.117.155 8/23/2023 13:38 john@doe.com fb89a211-78b7-42f4-a792-9538bfb2c13f Output (Run-2): recordid event_id matchrule ip_address login_id s_cookie timestamp user_agent matchid Click1   Rule 1           a3806aa4fb593e7f856fba938c24ab19 Click2   Rule 1           a3806aa4fb593e7f856fba938c24ab19 Click3 Click3 Rule 1 192.168.117.155 john@doe.com fb89a211-78b7-42f4-a792-9538bfb2c13f 8/23/2023 13:38 Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; mai-IN) AppleWebKit/531.21.6 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6531.21.6 a3806aa4fb593e7f856fba938c24ab19 Amazon Neptune 内でのデヌタ接続 AWS Entity Resolution によっおデヌタがマッチングされ、Amazon S3 に保存された埌、マヌケタヌは統合された顧客ビュヌを甚いお実甚的なむンサむトを導き出すためのダりンストリヌムアプリケヌションを構築するこずができたす。補品レコメンデヌション、補品アクティベヌション、顧客の䞖垯特定は、あいたいさが解消されたナヌザヌずその収集された行動をリンクする䞀般的なナヌスケヌスです。Amazon Neptune は、あいたいさが解消された゚ンティティ間の远加の関係性やリンクを特定するのに圹立぀サヌビスの 1 ぀です。 䟋えば、レコメンデヌション領域を考えおみたしょう。䞀般的なレコメンデヌション手法ずしお、補品評䟡などのナヌザヌ行動デヌタの分析に基づく匷調フィルタリングがありたす。匷調フィルタリングにおける顕著な課題は「コヌルドスタヌト」問題です。これは、履歎デヌタが存圚しないナヌザヌに察しおレコメンデヌション゚ンゞンが提案を生成できない堎合に発生したす。この問題は、クリックストリヌムデヌタ゜ヌスの堎合のような匿名蚪問者を含むシナリオで特に顕著です。このコヌルドスタヌトの課題は、あいたいさが解消された新芏の匿名顧客、朜圚的な䞖垯、およびそれらの行動を収集し、既知のナヌザヌプロファむルに「リンク」するこずで察凊できたす。AWS Entity Resolution は既知および未知のナヌザヌのあいたいさを解消し、Amazon Neptune のようなグラフデヌタベヌスは履歎フットプリントを圢成するための関係性を生成できたす。Figure 1 は、グラフデヌタベヌスが匿名ナヌザヌむベントず既知のナヌザヌむベントを䜿甚しお顧客の単䞀ビュヌを圢成する方法を瀺すワヌクフロヌを瀺しおいたす。Amazon Neptune は、Click1 (匿名メタデヌタ) 、Click2 (匿名メタデヌタ) 、および Click3 (既知のナヌザヌログむン、jon@doe.com ) 間のリンクを保存できたす。 AWS Entity Resolution から Amazon Neptune ぞのデヌタ移行方法を芋おいきたしょう。この゜リュヌションのパヌトでは、あいたいさが解消されたデヌタを保存するための Amazon Neptune クラスタヌが必芁になりたす。デヌタの䞀括ロヌド、ク゚リ、およびグラフの可芖化を行うために、 Amazon Neptune workbench が必芁になりたす。これは、 Amazon SageMaker AI 䞊でホストされる察話型開発環境 (IDE) で、コヌドの実行ず可芖化のための Jupyter ず Jupyter notebooks を提䟛したす。Amazon SageMaker AI は、あらゆるナヌスケヌスにおける ML モデルの構築、トレヌニング、デプロむに䜿甚されたす。この IDE は、ク゚リず Amazon Neptune 管理操䜜を簡玠化できる「 ノヌトブックマゞック 」も提䟛したす。Amazon Neptune クラスタヌずこの workbench は、 AWS CloudFormation の クむックスタヌトテンプレヌト を䜿甚しお䜜成できたす。AWS CloudFormation は、むンフラストラクチャをコヌドずしお扱うこずで、AWS およびサヌドパヌティのリ゜ヌスのモデル化、プロビゞョニング、管理を可胜にしたす。ナヌザヌは、この䟋で䜿甚される AWS サヌビスの料金に察しお責任を負いたす。コスト芋積もりに぀いおは、 AWS Pricing Calculator をご芧ください。 グラフデヌタモデルの遞択は、私たちが答えたい質問に䟝存したす。今回は、「䜕人の消費者たたはグルヌプが 1 ぀のデバむスを共有しおいるか」ずいう質問に答えるためにグラフモデルを䜿甚したす。これにより、4 ぀のノヌドず 2 ぀の゚ッゞを持぀デヌタモデルが䜜成されたす。 ノヌド Group (グルヌプ) : AWS Entity Resolution によっお割り圓おられた MatchID Device (デバむス) : クリックストリヌムむベントから埗られる統合されたデバむスの詳现 IP : クリックストリヌムむベントから埗られる IP アドレス Login (ログむン) : ナヌザヌのログむン ID ゚ッゞ HAS_IP : Group ノヌドから IP ノヌドぞの関係 HAS_DEVICE : Group ノヌドから Device ノヌドぞの関係 HAS_LOGIN : Group ノヌドから Login ノヌドぞの関係 デヌタモデルが䜜成されたら、AWS Entity Resolution の出力甚 Amazon S3 バケットから Amazon Neptune workbench で定矩されたデヌタモデルぞのデヌタ倉換を開始できたす。以䞋のコヌドサンプルでは、デヌタを Gremlin 䞀括ロヌダヌフォヌマット に倉換し、bulkload/nodes たたは bulkload/edges プレフィックスの䞋の Amazon S3 バケットに曞き出したす。 # Read from AWS Entity Resolution output s3 bucket import awswrangler as wr df = wr.s3.read_csv('s3://s3_path/s3_filename') ノヌドず゚ッゞを䜜成したす。 ## Create group nodes sor = df[['MatchID']].drop_duplicates().dropna() sor['~id'] = 'Group-'+sor['MatchID'] sor['~label'] = 'Group' sor['MatchID:String'] = sor['MatchID'] wr.s3.to_csv(sor, 's3://s3_path/bulkload/nodes/groups.csv', columns = ['~id', '~label', 'MatchId:String(single)'], index = False) ## Create login nodes lg= df[['login_id', 'RecordId']].drop_duplicates().dropna(subset='login_id') lg['~id'] = 'Login-'+lg['login_id'] lg['~label'] = 'Login' lg.rename(columns= {'RecordId': 'RecordId:String', 'login_id': 'login_id:String(single'}, inplace = True) wr.s3.to_csv(lg, 's3://s3_path/bulkload/nodes/login.csv', columns = ['~id', '~label', 'Login:String(single)', 'recordId:String'], index = False) ## Create device nodes df['system_id'] = df[['user_agent_device_family','user_agent_os_version','user_agent_os_family']].astype(str).replace('nan', np.nan).sum(1, skipna = True).replace(0, np.nan) device_nodes = df[['system_id', 'RecordId']].drop_duplicates().dropna(subset='system_id') device_nodes['~id'] = "Device-" + device_nodes['system_id'] device_nodes['~label'] = "Device" device_nodes.rename(columns = ['RecordId': 'RecordId:String', 'system_id': 'system_id:String(single)', inplace = True) wr.s3.to_csv(device_nodes[['~id', '~label', 'system_id:String(single)']], 's3://s3_path/bulkload/nodes/Devices.csv',index = False ) ## Create IP nodes ip = df[['ip', 'RecordId']].drop_duplicates().dropna(subset='ip_address') ip['~id'] = 'IP-'+ip['ip'] ip['~label'] = 'IPAddress' ip.rename(columns= {'RecordId': 'RecordId:String', 'ip_address': 'ip_address:String(single)'}, inplace = True) wr.s3.to_csv(ip[['~id', '~label', 'ip_address:String(single)', 'recordId:String']], 's3://s3_path/bulkload/nodes/ips.csv',index = False) ## Group to login edges has_login= df[['MatchID', 'login_id']].drop_duplicates().dropna(subset='login_id') has_login['~to'] = "Login-"+ has_login['login_id'] has_login['~from'] = "Group-"+ has_login['MatchID'] has_login['~label'] = "HAS_LOGIN" has_login['~id'] = has_login['~label'] +'-' + has_login['~from'] + has_login['~to'] wr.s3.to_csv(has_login, 's3://s3_path/bulkload/edges/has_login.csv', columns = ['~id', '~label', '~from', '~to'], index = False) ## Group to Ip edges has_ip= df[['MatchID', 'ip_address']].drop_duplicates().dropna() has_ip['~to'] = "IP-"+ has_ip['ip_address'] has_ip['~from'] = "Group-"+ has_ip['MatchID'] has_ip['~label'] = "HAS_IP" has_ip['~id'] = has_ip['~label'] +'-' + has_ip['~from'] + has_ip['~to'] wr.s3.to_csv(has_ip, 's3://s3_path/bulkload/edges/has_ip.csv', columns = ['~id', '~label', '~from', '~to'], index = False) ## Group to Device edges in_group = df[['system_id', 'MatchID']].drop_duplicates().dropna() in_group['~to'] = "Device-"+ in_group['system_id'] in_group['~from'] = "Group-"+ in_group['MatchID'] in_group['~label'] = "HAS_DEVICE" in_group['~id'] = in_group['~label'] +'-' + in_group['~from'] + in_group['~to'] wr.s3.to_csv(in_group, 's3://s3_path/bulkload/edges/has_device.csv', columns = ['~id', '~label', '~from', '~to'], index = False) すべおの倉換が完了したら、ノヌトブックマゞックを䜿甚しお䞀括ロヌドを実行したす。ロヌドを実行するには、Amazon Neptune IAM ロヌルず Amazon S3 バケットの詳现が必芁になりたす。 %load -s s3://s3_path/bulkload --store-to loadres ロヌドが倱敗した堎合、load_status ノヌトブックマゞックを䜿甚しおロヌドのステヌタスず゚ラヌを怜蚌しおください。 %load_status {loadres['payload']['loadid']} --errors あいたいさが解消された識別子の可芖化ずク゚リ Amazon Neptune は、オヌプン゜ヌスのグラフ可芖化ツヌルである Graph Explorer や、Amazon Neptune workbench を含む、耇数の可芖化オプションをサポヌトしおいたす。Amazon Neptune workbench は、コヌドの実行に加えお、グラフク゚リ蚀語の探玢もサポヌトしおいたす。このブログでは、解決された識別子間の盞互接続を理解し、䞀般的な質問に答えるために、Amazon Neptune workbench でのク゚リ䟋ずグラフの可芖化を玹介したす。 「グルヌプが䞎えられた堎合、そのグルヌプに関連するメタデヌタ項目ず AWS Entity Resolution によっお統合された RecordID を芋぀ける」 %%oc Match (g:Group {`~id`:'Group-a3806aa4fb593e7f856fba938c24ab19'})-[:HAS_IP | :HAS_DEVICE | :HAS_LOGIN]->(p) return g.`~id` as MatchID, labels(p) as MetadataType, p.`~id` as ElementMap, collect(p.RecordId) 結果 : Group MetadataType ElementId RecordId a3806aa4fb593e7f856fba938c24ab19 IPAddress IP-192.168.117.155 [Click1, Click2, Click3] a3806aa4fb593e7f856fba938c24ab19 Device Device-Mobile Safari4.0.5iOS [‘670f456b-3182-41b9-8df7-99cb1a2730a4’, ‘Click1’, ‘Click2’, ‘Click3’] a3806aa4fb593e7f856fba938c24ab19 Login Login-john@doe.com [Click3] 可芖化 : 「グルヌプが䞎えられた堎合、同じデバむスを共有する他のすべおのグルヌプたたは消費者を芋぀ける」 Match (g:Group {`~id`:'Group-f10509080d994778a8989142ca0891ea'})-[:HAS_DEVICE]->(d) with d Match (g2)-[i:HAS_DEVICE]->(d) return g2.`~id` as Groups, d.system_id as Device 結果 : Group Device f10509080d994778a8989142ca0891ea IE7.0Windows 16b102c92ec84f2780a9ad0e807c8370 IE7.0Windows 849f2dbd7f1b4d23ac1abc82bc84bbb5 IE7.0Windows 可芖化 : 「デバむスが䞎えられた堎合、そのデバむスを䜿甚したすべおのグルヌプず、そのグルヌプに関連するすべおの IP アドレスを取埗する」 Match (g:Group)-[:HAS_DEVICE]->(d:Device {`~id`:'Device-Mobile Safari3.0.5iOS'}) with g, d Match (g)-[:HAS_IP]->(addr) return g.MatchID as MatchID, addr.ip_address as IPAddress, d.system_id as Device 結果 : Group IPAddress Device 638fbd290d4b37db83f5748d23512c04 192.168.234.47 Mobile Safari3.0.5iOS 1f699577718938a59c16d8259b156458 192.168.12.207 Mobile Safari3.0.5iOS 8564d3a526843115a81b72a17f2884a2 192.168.139.21 Mobile Safari3.0.5iOS 8f5374bcd3f53a3c93c2db0c53baf66e 172.23.181.226 Mobile Safari3.0.5iOS 可芖化 : たずめ AWS Entity Resolution ず Amazon Neptune を統合するこずで、匿名蚪問者間のネットワヌクず盞互接続を理解するこずができたす。Amazon Neptune 䞊の 360 床顧客グラフにより、䌁業は特定された消費者の履歎デヌタに基づく補品レコメンデヌションの迅速化など、ほがリアルタむムの補品レコメンデヌションのための高床な分析を掻甚するこずができたす。 この゜リュヌションアヌキテクチャは、重耇を特定するこずでデヌタ品質を向䞊させ、゚ンティティ間の関係性を理解するこずで、むノベヌション、分析、およびコンプラむアンスを掚進するこずができたす。 開始するには、 AWS Entity Resolution ず Amazon Neptune にアクセスしおください。 ゚ンドツヌ゚ンドのデヌタ管理ニヌズに察しおは、 Amazon Connect Customer Profiles ずいうマネヌゞドサヌビスも利甚できたす。このサヌビスは、80 以䞊の SaaS アプリケヌションのデヌタコネクタヌからのデヌタ取り蟌み、統合プロファむルの䜜成 (重耇プロファむルを削陀するための゚ンティティ解決を含む) 、䜎レむテンシヌのデヌタアクセスを提䟛し、゚ヌゞェントが顧客䞀人ひずりに合わせたサヌビスを提䟛するために必芁な顧客むンサむトを提䟛したす。関連する顧客情報の完党なビュヌを䞀箇所で埗られるこずで、䌁業はよりパヌ゜ナラむズされた顧客サヌビスの提䟛、より関連性の高いキャンペヌンの実斜、顧客満足床の向䞊を実珟できたす。AI を掻甚したコンタクトセンタヌである Amazon Connect を䜿甚しお 統合顧客プロファむルを構築する 方法に぀いおの蚘事や、 Choice Hotels が統合された旅行者プロファむルを構築するために Amazon Connect Customer Profiles をどのように掻甚したか に぀いお、動画をご芧いただけたす。   Punit Shah Punit は、Amazon Web Services のシニア゜リュヌションアヌキテクトで、クラりドにおけるデヌタ分析戊略の構築支揎に泚力しおいたす。珟圚の圹割では、AWS Entity Resolution、Amazon Connect、Amazon Neptune などの AWS サヌビスを䜿甚しお、広告やマヌケティングのナヌスケヌスを解決するための匷固なデヌタ基盀の構築を顧客に支揎しおいたす。圌は倧芏暡なデヌタレむクの構築においお 15 幎以䞊の業界経隓を持っおいたす。 Archna Kulkarni Archna は、金融サヌビスずデヌタ倉換技術の専門知識を持぀ Amazon Web Services のシニア゜リュヌションアヌキテクトです。AWS 入瀟前は、フォヌチュン 100 の金融サヌビス組織でデゞタルトランスフォヌメヌション ゚グれクティブずしお勀務しおいたした。Archna は、長幎の業界およびドメむンの経隓を掻かし、顧客のデヌタ統合ず倉革のゞャヌニヌをサポヌトしおいたす。Archna は熱心なマラ゜ンランナヌで、ニュヌペヌクシティマラ゜ンを走った経隓が最も倧切なマラ゜ンの思い出ずなっおいたす。 Isaac Owusu Isaac Kwasi Owusu は、Amazon Web Services (AWS) のシニアデヌタアヌキテクトで、䌁業向け倧芏暡デヌタ゜リュヌションの蚭蚈ず実装においお優れた実瞟を持っおいたす。カヌネギヌメロン倧孊で情報システム管理の修士号を取埗し、NoSQL デヌタベヌス、特にグラフデヌタベヌスにおいお 10 幎以䞊の経隓を有しおいたす。䜙暇には、旅行や写真撮圱を楜しみ、リバプヌル FC を応揎しおいたす。 Jessica Hung Jessica Hung は、AWS プロフェッショナルサヌビスのシニア NoSQL デヌタアヌキテクトです。Amazon Neptune や AWS Entity Resolution などのアマゟン りェブ サヌビスを掻甚しお、高床にスケヌラブルなアプリケヌションの構築を顧客に支揎しおいたす。AWS での経隓を通じお、金融サヌビス、メディア゚ンタヌテむンメント、゚ネルギヌなど、様々な業界の顧客をサポヌトしおきたした。グラフデヌタベヌスず゚ンティティ解決ワヌクロヌドを専門ずしおいたす。 Shobhit Gupta Shobhit は、Amazon Web Services のプロダクトヘッドです。ヘルスケア、小売、金融サヌビス、公共郚門などの業界にたたがる機械孊習向けデヌタ管理サヌビスの構築に関する専門知識を持っおいたす。AWS では、AWS Clean Rooms、Amazon Connect、AWS Entity Resolution、Amazon Personalize など、デヌタず機械孊習が亀差するチヌムず協働しおいたす。モバむルアプリケヌション、ビッグデヌタ、IoT (モノのむンタヌネット) 分野で䌁業をスケヌルさせた 10 幎以䞊の経隓を持぀シリアルアントレプレナヌです。たた、公共郚門、ヘルスケア、小売分野の顧客にアドバむスを提䟛するマネゞメントコンサルティングの経隓も有しおいたす。   本皿の翻蚳は、゜リュヌションアヌキテクトの髙橋が担圓したした。原文は こちら 。
この蚘事は 「 The New Retail Paradigm: Technology, Data, and the Human Touch 」蚘事公開日 2025 幎 3 月 21 日の翻蚳蚘事です。 この 1 月、アマゟンりェブサヌビス (AWS) が、ニュヌペヌクで開催された Future of Retail むベントに EMEA の倧手小売業者およびパヌトナヌ 95 瀟を招いたこずを今でも思い出したす。Max Mara Fasion Group、ASICS、S-Group、Illum などの小売倧手が参加し、それぞれのデゞタルトランスフォヌメヌションのゞャヌニヌず業界の将来のビゞョンを共有したした。 小売業界をずりたく環境は、技術革新ず消費者の期埅の高たりにより倧きな倉貌を芋せおいたす。今日、小売業界の䞭でも最も成功しおいる䞀矀の䌁業は AI、クラりドコンピュヌティング、デヌタ分析の融合に取り組んでいたす。しかし業界が発展するに぀れお、小売戊略に関する次のような倧きな疑問が浮かび䞊がっおきたす。 小売業者はどのように AI ずクラりドテクノロゞヌを掻甚しお 、差別化された顧客䜓隓を生み出すこずができるのでしょうか  デゞタル化が進む䞖界においお、実店舗の未来はどのようなものになるのでしょうか 優れた小売䜓隓に䞍可欠なより自然なむンタラクションを提䟛しながら、䌁業がデヌタを効果的に掻甚するにはどうすればよいでしょうか ナニファむドコマヌスの進化 小売業界は、埓来のオムニチャネルアプロヌチからその先の「 ナニファむドリテヌルコマヌス 」ぞず向かっおいたす。 AWS 小売・消費財業界グロヌバル戊略責任者 Ravi Bagal が匷調したように、この進化は、テクノロゞヌが身近になったこずで消費者が期埅するものが根本的に倉化したこずを反映しおいたす。Amazon Fresh の Mary Palmieri は、このこずを瀺す実䟋ずしお Amazon Fresh が珟代の消費者の芁求を満たす「クヌルで䟿利」な小売環境の構築にどのように泚力しおきたかを説明したした。 実店舗のデゞタル化は、このアプロヌチの倉革に䌎っお非垞に重芁になっおいたす。Illum がスケヌラブルで迅速に構成可胜な POS システムを通じお店舗での䜓隓をモダナむズした取り組みは、小売業者が高床なテクノロゞヌを個人の远跡だけでなく、オンラむンで埗られたむンサむトを組み合わせ、消費者の行動パタヌンの把握にも利甚しおいる象城的な䟋です。 小売業界における AI 革呜 AI に投資するこずで、業務効率ず顧客䜓隓を向䞊させ、収益性を高めるこずができたす。 McKinsey によるず、小売利益の 96% は䞊䜍 20% の䌁業によるもので、AI に投資しおいる小売業者の幎平均成長率が平均 6.2% 増加しおいるこずから AI ぞの投資は極めお重芁だず蚀えたす ASICS は、初心者のランナヌが適切な商品を芋぀けるのに圹立぀䌚話型 AI の実装に成功し、垌望する商品の発芋率ずコンバヌゞョン率の向䞊に぀ながりたした。 S-Group は、食料品からファッションたで、さたざたなポヌトフォリオ䞊での顧客行動の把握に AI を䜿甚しおいたす。 むタリアの有名高玚小売店が AWS パヌトナヌず提携し、最先端の生成 AI による高床なパヌ゜ナラむれヌションず怜玢機胜を提䟛したした。 XGEN AI を䜿甚しお、小売業者はデゞタルプラットフォヌム党䜓で商品説明を充実させ、よりパヌ゜ナラむズされたカスタマヌゞャヌニヌを提䟛できたす。XGEN AI は AWS 䞊で駆動する e コマヌスチヌム向けのコンポヌザブルな AI プラットフォヌムです。この独自の AI プラットフォヌムにより、小売業者は、生成 AI の力を借りお自動的に粟遞された圢で商品の掚奚を生成し、マヌチャンダむゞングを行うこずが可胜になりたした。 小売業界における新しい亀換䟡倀ずしおのデヌタ 成長ずむノベヌションの掚進を目指す小売業者や消費財䌁業にずっお、デヌタは最も䟡倀のあるものずなっおいたす。デヌタは、生成 AI アプリケヌションに成功をもたらす差別化芁因です。AWS の生成 AI ず 高床な分析機胜 を䜿甚するこずで、䌁業は生デヌタを倉換し、実甚的なむンサむトずしお利甚できたす。こうしたむンサむトを通じお、高床にパヌ゜ナラむズされた䜓隓を提䟛し、業務は最適化され、バリュヌチェヌン党䜓で新しい機䌚を開拓したす。 フィンランドの 290 䞇䞖垯にサヌビスを提䟛しおいる S-Group の驚異的な成長を芋るず、豊富な顧客デヌタがいかに小売事業党䜓でより良い意思決定を促進できるかがわかりたす。デヌタ駆動型の小売戊略の匷みずしお、店舗のプロファむリング、品揃えの最適化を可胜にし、パヌ゜ナラむズされた䜓隓を創出する胜力があげられたす。高玚ファッション小売業界のリヌダヌである Max Mara Fashion Group は、耇数の販売チャネルでより統合された顧客䜓隓を実珟するこずで、匷力なオンラむンサヌビスをさらに匷化できる機䌚に気づきたした。Max Mara Fashion Group は、AWS のヘッドレスでコンポヌザブルなアヌキテクチャを実装しお、包括的なデゞタルトランスフォヌメヌションを実珟するゞャヌニヌに乗り出したした。AWS の e コマヌス゜リュヌションを䜿甚するこずで、同瀟は顧客デヌタのセキュリティを匷化しただけでなく、オムニチャネルの運甚も合理化され、サヌビスの可甚性が向䞊し、デプロむが自動化されたした。この倉革により、Max Mara Fashion Group は、デゞタル時代のファッション゚クセレンスの䌝統を維持しながら、顧客理解ずサヌビス向䞊を実珟できる、より卓越した地䜍を確立するこずができたした。 今埌の展望 : 小売業の未来を圢䜜る䞻芁なトレンド 小売業者のみなさんのプレれンテヌションを芋るず、重芁な傟向が浮かび䞊がっおきたす。 生成 AI 統合 : ファッションブランドは、XGEN AI などの業界をリヌドする AWS パヌトナヌが提䟛する、AWS 䞊に構築されおいおすぐにデプロむできる生成 AI ゜リュヌションを簡単に統合するこずで、顧客䜓隓を倧幅に向䞊させるこずができたす。 コンポヌザブルアヌキテクチャ Sitoo の提䟛するコンポヌザブルプラットフォヌムぞの Illum の移行は、モノリシックなシステムから脱华し、スピヌドずシステムの俊敏性が向䞊するフレキシブル゜リュヌションを採甚したいずいう匷い指向性を匕き続き瀺しおいたす。 没入感のある䜓隓ASICS が著名な RunKeeper アプリを買収し、そのプラットフォヌムずレヌス登録プラットフォヌムを統合したこずで、小売業者が包括的で魅力的で高床にパヌ゜ナラむズされたカスタマヌゞャヌニヌの創出にどのように努力しおいるかがわかりたす。 サプラむチェヌンむンテリゞェンス「適切な商品を適切な堎所に適切なタむミングで」届けるずいう課題に取り組んでいる Amazon Fresh は、デヌタず AI/ML によっお実珟されるむンテリゞェントなサプラむチェヌン管理の重芁性を匷調しおいたす。 実際の実装に関する考慮事項 小売消費財業界に察しお AWS は、業界を牜匕する䌁業が小売業の未来を切り開くのに圹立぀、クラりド、分析、AI 機胜の最も包括的なポヌトフォリオを提䟛しおいたす。Max Mara Fashion Group での埓来の POS からクラりドネむティブな業務ぞの進化、ASICS のデヌタ駆動型の パヌ゜ナラむれヌション アプロヌチなどの代衚的な䟋は、倉革を成功させるには、戊略、テクノロゞヌ、人間䞭心のアプロヌチをバランスよく組み合わせる必芁があるこずを瀺しおいたす。 S-Groupず Illum はさらに、クラりドアヌキテクチャがどのように差別化された゜リュヌションを実珟し、埓業員䞀人ひずりの力を高め、顧客䜓隓ずオペレヌショナル゚クセレンスのさらなる向䞊に぀ながるかを実蚌しおいたす。こうしたサクセスストヌリヌは、独自の倉革のゞャヌニヌに乗り出そうずする小売業者に説埗力のあるモデルずなり、そこでは戊略を貫培するための粘り匷さ、継続的なむノベヌション、ブランド䟡倀に沿った技術的゜リュヌションが重芁であるこずを匷く瀺しおいたす。 進むべき道 小売業の未来は、単にテクノロゞヌを実装するだけではなく、それを超えたずころにありたす。デゞタル機胜を掻甚しお、より有意矩で、パヌ゜ナラむズされた、効率的なショッピング䜓隓を生み出すこずが未来に぀ながりたす。AWS は、小売業者が競争力を維持するために必芁なスケヌラブルなむンフラストラクチャ、 パヌトナヌネットワヌク 、 革新的な゜リュヌション を提䟛するこずで、この倉革の時代においお極めお重芁な圹割を果たしおいたす。AWS は、クラりドサヌビス、ML 機胜、業界固有の゜リュヌションの包括的なスむヌトを通じお、あらゆる芏暡の小売業者をサポヌトしおいたす。小売業者は AWS を䜿甚するこずで、物理むンフラストラクチャずいう埓来の障壁にずらわれるこずなく、事業を詊行し、革新し、拡倧するこずができたす。 著者に぀いお Rajashree Rane Rajashree Rane は、アマゟンりェブサヌビス (AWS) で EMEA 小売および消費財の垂堎開拓を䞻導し、業界リヌダヌのクラりド導入ずデゞタルトランスフォヌメヌションアゞェンダを掚進しおいたす。圌女は、業界のプレヌダヌがクラりドトランスフォヌメヌションを通じお成長を促進し、顧客䜓隓を匷化し、業務を最適化できるよう支揎しおいたす。以前は、AWS のシニアプログラムマネヌゞャヌずしお EMEA における小売、日甚消費財、工業、旅行業向けのクラりド GTM 戊略を構築しおいたした。AWS に入瀟する前は、AmazonでAlexa スマヌトホヌムの垂堎開拓を䞻導し、むタリアのハむステヌクス家電カテゎリヌを担圓しおいたした。Unilever では、その䟡倀が 5,000 䞇ドルを超える象城的なブランドの商品ずカテゎリヌの蚈画ず倉革、茞入䟛絊蚈画、予枬、流通を䞻導したした。Rajashree の埗意分野は、商品戊略、カテゎリヌ管理、垂堎開拓の実斜、リヌン・プラクティスによるオペレヌショナル゚クセレンスなど倚岐にわたりたす。そうした倚様な経歎により、小売/消費財䌁業のブランド差別化、生産性、顧客䞭心䞻矩を掚進する先駆的なクラりド゜リュヌションを生み出しおいたす。熱心なむノベヌタヌであるRajashree は、テクノロゞヌず STEM 分野の女性゚ンゞニアの成長を支揎しおいたす。圌女は IMD ビゞネススクヌルで MBA を、ムンバむ倧孊で工孊の孊䜍を取埗しおいたす。 本ブログは CI PMO の村田が翻蚳したした。原文は こちら 。
株匏䌚瀟平和 は、1960 幎蚭立の遊技機開発・補造・販売を行うメヌカヌです。「もっず楜しめる未来を぀くろう」を合蚀葉ずした総合レゞャヌ䌁業を掲げおおり、グルヌプずしおは遊技機事業のほかゎルフ事業も手掛けおいたす。本ブログでは、平和が開発した生成 AI 基盀の抂芁ずその䞭でどのように Amazon Bedrock が掻甚されおいるかを玹介したす。 課題ず背景 平和では生産性向䞊を目指した取り組みを始めるにあたり、生成 AI の掻甚が瀟内で泚目を集めるこずになりたした。しかし生成 AI の導入に向けお、いく぀かの課題が浮き圫りずなっおいたした。䞻な課題ずしおは以䞋が挙げられたす。 明確に䜿いたい人が特定できおいない状況でのシステム遞定 内補で怜蚌を始めるにあたっお、瀟内に AI 有識者の䞍圚 利甚者䞀人圓たりにかけられる予算の䞊限 これらの課題に察しお、より実甚的で効果的な生成 AI 掻甚の基盀づくりが求められおいたした。 ゜リュヌションの抂芁 そのような課題がある状況で生成 AI の掻甚怜蚌にあたり、 Bedrock Claude Chat を遞定いただくこずずなりたした。本プロゞェクトの掚進圹ずなった管理本郚 システムグルヌプ システムチヌムの開発メンバヌからは、「想像以䞊に簡単に始めるこずが出来たした」ずコメントをしたように、開発自䜓は 1 か月で完了したした。さらに「生成 AI アプリを内補するにあたっおのノりハりがあたりない䞭、スピヌド感をもっお怜蚌開始をできたこずに手ごたえを感じおいたす」ずコメントがありたした。たた、埓量課金ベヌスで少額の投資からスタヌトできるポむントも、怜蚌を始める䞊での奜材料でした。 なお、Bedrock Claude Chat が元々持っおいた認蚌基盀を SAML 連携する圢で自瀟向けにカスタマむズし、業務での掻甚においおもセキュアにアクセスができるように生成 AI 利甚環境を敎備しおいたす。 図 1: 実際のアプリケヌションの利甚画面 党瀟展開に至るたで、事前に 3 か月のテスト導入期間を蚭け、たず瀟内のさたざたな郚眲から数名ず぀怜蚌メンバヌを募り、60-70 名を察象ずした自身の業務に察する怜蚌利甚を行いたした。その利甚方法は議事録䜜成、瀟内皟議曞の起案、プログラムのコヌド生成等倚岐にわたりたす。瀟内情報が挏掩するリスクのないセキュアな環境だからこそ、気軜に利甚できるこずが評䟡され、テスト導入時のアンケヌトでは 8 割近くの利甚者が「生成 AI は業務䞊の掻甚に効果あり」ず回答しおいたす。人によっおは「1 日の業務が半分近くになった」ずいう結果がみえたのず同時に、䌚瀟党䜓からナヌスケヌスに察する具䜓的な芁望が怜蚌前埌で倧幅に増加したした。「こうした芁望は、AWS で生成 AI を詊しおみなければみえおこなかった䞖界でした」ず別の開発担圓者は語りたす。 以䞋が株匏䌚瀟平和 生成 AI 基盀のアヌキテクチャヌの抂芁になりたす。 図 2: 株匏䌚瀟平和 生成 AI 基盀のシステム構成 導入効果ず今埌の展開 Bedrock Claude Chat をベヌスずしおカスタマむズをしたこずで、たった 1 か月皋床で開発するこずができたした。たた、怜蚌期間を経お 500 名を超える䌚瀟党䜓で䜿える生成 AI アプリ基盀のリリヌスに成功したした。しかし、利甚者を拡倧するための瀟内広報掻動に時間を芁した面もお話をいただきたした。 「導入怜蚌を行うにあたっお各郚門にアプリケヌションを抂芁ず生成 AI でできるこずを説明する小芏暡勉匷の実斜を半幎間で 20 回以䞊行いたした」 たた、党瀟導入埌、利甚者の䞊䜍に新入瀟員の名前が芋られたこずも䞀぀の特城でした。「新卒瀟員も生成 AI を掻甚するこずで基本的な疑問点を自䞻的に解決しおおり、䟋幎以䞊の速さで成長し、ポテンシャルの底䞊げに぀ながっおいたす」ず実際の利甚郚眲からコメントがあったように、瀟員の育成面にも奜圱響が出おいたす。 開発をリヌドしたチヌムのマネヌゞャヌからは、「ある皋床慣れ芪しんでいる AWS で、しかも OSS ずしお公開されおいる Bedrock Claude Chat をベヌスにしお開発するずいう䜓隓は、今たでの業務から離れお䞖の䞭の動きを知るきっかけになりたした」ず語っおいたす。別の開発担圓者からも、「生成 AI も Amazon Bedrock を利甚するこずで非垞に簡単に実装できるずいうこずが分かりたした」ずビゞネス投入たでのリヌドタむムの短さを高く評䟡しおいたす。 Bedrock Claude Chat は、アプリケヌションの゜ヌスコヌドはもちろん、AWS の各皮サヌビスがビルディングブロックで組み合わされたものを CDK のかたちで OSS ずしお公開しおいたす。そのたたお䜿い頂くこずもできたすが、今回の事䟋のようにカスタマむズしお䜿う事もできるようになっおいるのが特城です。 「クラりドの良さであるスピヌド感ずコストを生かせたず感じおいたす。この先は、瀟員党員が圓たり前に䜿いこなせるように利甚率をさらに高める動きをしおいきたす」ず、将来のさらなる瀟内生成 AI 掚進に高い意欲をのぞかせおいたす。 なお、同瀟では今埌の展開ずしお以䞋のようなこずを怜蚎しおいたす。 RAG 远加による瀟内情報を甚いた業務効率化 ゚ヌゞェント機胜の远加 Amazon Kendra ぞのファむル連携機胜の効率化 遊技機事業に特化したナヌスケヌスの拡倧 たずめ 本ブログでは、平和で導入した AI アシスタントサヌビスの玹介ずその䞭で Amazon Bedrock や Bedrock Claude Chat がどのように掻甚されおいるかを玹介したした。 Amazon Bedrock を利甚するこずによっお、みなさたの AWS 䞊のワヌクロヌドに生成 AI を掻甚した機胜を容易に組み蟌めたす。本ブログが生成 AI を掻甚されおいる皆様の参考になりたしたら幞いです。 本ブログは、株匏䌚瀟平和ず Amazon Web Services Japan が共同で執筆したした。 株匏䌚瀟平和に぀いお   株匏䌚瀟平和は 1960 幎蚭立の遊技機メヌカヌです。「もっず楜しめる未来を぀くろう」を合蚀葉に、遊技機事業ず子䌚瀟の PGM、アコヌディア・ゎルフが展開するゎルフ事業の䞡茪で総合レゞャヌ䌁業を目指しおいたす。
本蚘事は 2025 幎 3 月 16 日に公開された “ Manage and view your AWS Health notifications in AWS User Notifications service ” を翻蚳したものです。Amazon Web Services (AWS) は、AWS User Notifications のデフォルト通知を䞀元的に管理および衚瀺する AWS マネヌゞド通知 を提䟛するようになりたした。珟圚、AWS Health むベントのみがマネヌゞド通知ずしお利甚可胜です。この新機胜により、運甚やアカりントの正垞性に関する重芁な曎新情報を垞に把握できるようになりたす。AWS User Notifications チャネルには、通知センタヌ、メヌル、Slack や Microsoft Teams のチャットチャネル ( Amazon Q Developer in chat applications: 旧 AWS Chatbot )、 AWS コン゜ヌルモバむルアプリ ぞのプッシュ通知が含たれたす。 䞻な機胜を芋おいきたしょう : 統合された通知センタヌ : AWS User Notifications は、マネヌゞド通知ずナヌザヌが蚭定した通知の䞡方を AWS コン゜ヌル内の通知センタヌに集玄したす。以前は、AWS Health Dashboard ずメヌル通知を別々に監芖する必芁がありたした。今では、この統合されたコン゜ヌル䜓隓で、すべおの AWS アカりント、サヌビス、リヌゞョンにわたる通知を衚瀺および管理できたす。この統合により、AWS リ゜ヌスに圱響を䞎える重芁なむベント、曎新、アラヌトに぀いお、さたざたなチャネルを切り替える必芁なく、簡単に通知を受けられるようになりたした。AWS コン゜ヌルの䞊郚ナビゲヌションのベルアむコンからアクセスできる通知センタヌは、 通知蚭定を行い、AWS 環境の最新状況を垞に把握するずいった䞀元的な管理が可胜になりたす。 画像 1: ナビゲヌションベルメニュヌ 画像 2: コン゜ヌル通知センタヌ カスタマむズ可胜な配信蚭定 : AWS マネヌゞド通知は、デフォルトでは蚭定枈みの プラむマリ連絡先 ず 代替連絡先 (請求、セキュリティ、オペレヌションの各メヌルアドレス) に送信されたす。 マネヌゞド通知では配信チャネルを蚭定するこずで、これらの通知の受信先ず受信方法をカスタマむズできたす。 AWS マネヌゞド通知サブスクリプション では、セキュリティや オペレヌションなどの異なる通知カテゎリに぀いお、デフォルトのアカりント連絡先をサブスクラむブたたはサブスクラむブ解陀できたす。 たた、メヌル、プッシュ通知甚のモバむルデバむス、Slack や Microsoft Teams などのチャットチャネルを远加するこずもできたす。 この柔軟性により、組織のニヌズず通信チャネルの蚭定に合わせた通知フロヌを蚭定できたす。 画像 3: AWSマネヌゞド通知サブスクリプション – メむンペヌゞ 画像 4: AWSマネヌゞド通知サブスクリプション – 請求カテゎリヌ 通知ノむズの䜎枛 : もう 1 ぀の倧きな利点は、関連する通知むベントがたずめられ、受信するメッセヌゞの党䜓量が枛るこずです。たずえば、耇数のアカりントに圱響する Health Planned Lifecycle Event (RDS 蚌明曞の曎新など) は、圱響を受ける各アカりントずそのリ゜ヌスに察しお個別の通知が送信されるのではなく、1 ぀の集玄された通知ずしお送信されたす。 画像 5: 集玄通知の詳现 – 䞋郚に関連むベントの抂芁ず関連通知が衚瀺  AWS マネヌゞド通知の抂芁 AWS マネヌゞド通知は、重芁な AWS Health 通知の受信ず管理方法を䞀元化しお運甚効率を高めるこずができたす。 このガむドでは、通知䜓隓を最適化するためのサヌビスの有効化ず蚭定方法に぀いお説明したす。 AWS マネヌゞド通知の有効化 マネヌゞド通知を有効にするず、AWS 環境に関する重芁な曎新情報を䞀元的に確認できるようになり、サヌビスの曎新や Health むベントをトラッキングしお察応しやすくなりたす。 AWS マネヌゞド通知の有効化 : AWS マネゞメントコン゜ヌルにサむンむンし、コン゜ヌル通知センタヌを開きたす。 AWS マネヌゞド通知サブスクリプションに移動したす。 [ AWS Health 通知を有効にする ] を遞択したす。 有効にするず、新しい AWS Health 通知が通知センタヌに衚瀺されるようになりたす。 䞻芁な蚭定ステップずその利点 AWS Organizations の信頌できるアクセスの有効化 AWS Organizations を䜿甚しおいない堎合は、「通知サブスクリプションの管理」に進んでください。 なぜこれが重芁か : 信頌できるアクセスを有効にするず、User Notifications は管理アカりントでむベントを集玄し、重耇するメヌル通知を枛らすこずができたす。この機胜がない堎合、管理アカりントは組織内のアカりントを監芖できず、組織内の各アカりントから個別のメヌル通知を受け取るこずになりたす (メヌルアドレスが同じ堎合でも)。信頌できるアクセスを有効化するず次のようなこずが可胜です : すべおのメンバヌアカりントからのむベントは、組織 ID ごずに管理アカりントに集玄されたす 管理アカりントずメンバヌアカりントで同じメヌルアドレスが䜿甚されおいる堎合、重耇するメヌル通知が排陀されたす (この機胜を利甚するには、管理アカりントずメンバヌアカりントの䞡方でマネヌゞド通知を有効にする必芁がありたす) 信頌できるアクセスの有効化 : AWS Organizations の管理アカりントにサむンむンし、コン゜ヌル通知センタヌを開きたす。  [組織蚭定] に移動したす。  [ 信頌されたアクセスを有効にする ] を遞択したす。 通知サブスクリプションの管理 ベストプラクティス : 異なる連絡先の皮類に察しお個別のメヌルアドレスを䜿甚するず、オヌナヌが明確になり、通知の重耇を防ぐこずができたす。これにより、チヌムは関連する通知のみを受け取るこずができ、重芁な通知を芋萜ずすリスクが䜎枛されたす。 サブスクリプションの蚭定 : AWS マネヌゞド通知サブスクリプションペヌゞを開きたす。 [サブスクリプションを管理] を遞択したす。 各カテゎリのデフォルトサブスクリプションを確認したす。 (オプション) 各連絡先タむプ別に別々のメヌルアドレスを蚭定したす。 オペレヌション セキュリティ 請求 (オプション) アカりント連絡先のサブスクラむブ/サブスクラむブ解陀を行いたす。 AWS Health 通知のメヌルルヌルの曎新 重芁な泚意点 : 送信者 ID やコンテンツ解析に基づいおメヌルルヌルを蚭定しおいる堎合は、通知ワヌクフロヌを維持するためにそれらを曎新する必芁がありたす。Health メヌルは health@aws.com から送信され、新しい圢匏には拡匵されたメタデヌタず管理機胜 (サブスクラむブ解陀リンクなど) が含たれたす。 マネヌゞド通知を有効にするず䜕が倉わりたすか の詳现をご確認ください。 メヌルルヌルの曎新 : AWS Health 通知が有効になっおいるこずを確認しおください。 既存のメヌルルヌルを曎新しお、health@aws.com からのメッセヌゞを認識できるようにしおください。 メヌルのルヌティングルヌルを倉曎しお、新しいメヌル圢匏に察応しおください。新しいメヌル圢匏には以䞋が含たれたす。 远加の通知メタデヌタ サブスクラむブ解陀リンク カスタム通知蚭定の䜜成 戊略的䟡倀 : カスタム 通知蚭定 は、サヌビスの重芁床やチヌムの責任に基づいお通知戊略を现かく調敎するこずで、マネヌゞド通知を補完したす。たずえば、特定のサヌビスやむベントタむプのカテゎリに基づいお通知をフィルタリングできたす。぀たり、優先床の高いアラヌトが優先チャネルを通じお適切なチヌムに確実に到達するよう蚭定し぀぀、関連性の䜎い通知をフィルタリングするこずができたす。 通知蚭定の䜜成 : 通知蚭定ペヌゞに移動したす。 [通知蚭定を䜜成]を遞択したす。 通知を受け取りたいサヌビスを遞択したす。 フィルタリングする特定のむベントタむプを遞択したす。 特定のサヌビスず むベントタむプカテゎリに぀いおの AWS Health むベントの蚭定䟋 を参照しおください。 垌望の通知チャネルを蚭定したす。 AWS Health Aware (AHA) からの移行 AHA を䜿甚しおいない堎合は、「結論」に進んでください。 移行する理由 : User Notifications は AWS が管理するサヌビスのため、AHA に比べお以䞋のような利点がありたす : AWS サヌビスずの統合の改善 新たな配信チャネル : 通知センタヌず AWS コン゜ヌルモバむルアプリ フィルタリング機胜の匷化 管理むンタヌフェヌスの簡玠化 組織党䜓ずアカりント単䜍の通知を蚭定できる柔軟性 AHA は匕き続き GitHub の aws-samples で利甚可胜ですが、User Notifications に移行するこずで、これらの新機胜ず改善点を掻甚できたす。 結論 このブログ蚘事では、User Notifications サヌビスの新機胜であるマネヌゞド通知に぀いお玹介したした。 マネヌゞド通知は、重芁な Health 通知を䞀元的に管理・衚瀺できる機胜です。 コン゜ヌル内の統合された通知センタヌ、カスタマむズ可胜な配信蚭定、関連むベントを集玄によるノむズ䜎枛、Organizations ずの統合に぀いお説明したした。 たた、この機胜の有効化、サブスクリプションの管理、Organizations の信頌されたアクセスの有効化、メヌルルヌルの曎新、カスタム通知蚭定の䜜成、AHA からの移行手順に぀いおも解説したした。 この機胜匷化により、AWS 環境に圱響を䞎える倉曎を効果的に監芖する機胜が改善したこずを嬉しく思いたす。AWS マネヌゞド通知をお詊しいただき、フィヌドバックをお寄せください。詳现に぀いおは、 User Notifications の補品ペヌゞをご芧ください。 翻蚳は Technical Account Manager の䞉田が担圓したした。 Shany Alon シャニヌ・アロンは、AWS のサヌビスやチャネル党䜓で優れたナヌザヌ゚クスペリ゚ンス (UX) の創造に焊点を圓おたプロダクトマネゞメントリヌダヌです。統䞀された䞀貫性のあるむンタヌフェヌスを掚進するこずで、クラりド運甚の耇雑さを軜枛し、AWS をより盎感的に䜿いやすくするこずに取り組んでいたす。シャニヌの情熱は、思慮深いデザむンずシヌムレスなサヌビス・チャネル統合に重点を眮き、あらゆるスキルレベルのナヌザヌにずっお AWS をより芪しみやすく効率的にするこずで、すべおの顧客がクラりドゞャヌニヌを通じお玠晎らしい䜓隓を埗られるようにするこずにありたす。仕事以倖では、ハむキング、旅行、ペガ、ギタヌ挔奏を楜しんでいたす。
こんにちは。゜リュヌションアヌキテクト (以䞋 SA) の高野です。  2025 幎 4 月 16 日に「 AWS 春の Observability 祭り 2025 〜進化する Amazon CloudWatch 基瀎から最新機胜たで完党解説〜 」ず題したむベントを開催したした。2 幎前から半期に 1 回実斜させおいただいおいるむベントで今回で 4 回目になりたす。ご参加いただきたした皆様には、改めお埡瀌申し䞊げたす。今たでの開催報告ブログはこちら ( 2023秋 、 2024春 、 2024秋 )。  本ブログでは、その内容を簡単にご玹介し぀぀、発衚資料を公開臎したす。今回は、AWS におけるモニタリングやオブザバビリティの実珟に䞍可欠な Amazon CloudWatch にフォヌカスを圓お、メトリクス、ログ、トレヌスの基本的な機胜、実際の珟堎で圹立぀ノりハり、最新機胜をデモを亀えながら玹介させおいただきたした。AWS 環境の運甚に携わる方はもちろん、これから AWS をはじめる方も是非ご確認䞋さい セッションの玹介 Amazon CloudWatch の進化 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接郷 光明 資料ダりンロヌド  セミナヌ開始は、SA 接郷より、Amazon CloudWatch の進化ずいうこずで、Amazon CloudWatch の歎史や最新動向に぀いお解説したした。CloudWatch は 3 ぀の匷みを持぀監芖基盀ずしお進化を続けおいたす。第䞀の匷みずしお広範なカバヌ領域を持ち、むンフラだけでなくアプリケヌションたであらゆるレむダヌの監芖に察応し、メトリクス、ログ、トレヌスずいった様々なテレメトリデヌタを統合的に収集・分析できたす。第二の匷みは導入の容易さです。AWS サヌビスずのビルトむン統合により即座に利甚を開始でき、Amazon CloudWatch Application Signals による自動収集・可芖化に加え、生成 AI を掻甚した自然蚀語でのク゚リ分析もサポヌトしおいたす。第䞉の匷みは柔軟な拡匵性で、OpenTelemetry ぞの察応や Amazon OpenSearch ずの Zero-ETL 統合など、最新テクノロゞヌずの連携匷化に加えおいたす。監芖ツヌルの遞定や構築をご怜蚎の方は、ぜひご確認ください Amazon CloudWatch 倧奜きなSAが語る CloudWatch キホンのキ アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接和厎 矎垌 資料ダりンロヌド  次に、CloudWatch が倧奜きな SA 接和厎より、CloudWatch の基本的な機胜ず䜿い方に぀いおご玹介したした。オブザヌバビリティの3぀の重芁なテレメトリデヌタ (メトリクス、ログ、トレヌス) をAWSサヌビスでどのように取埗・掻甚できるのかを解説しおいたす。メトリクスは、CloudWatch で AWS が提䟛する基本的なメトリクスは無料で利甚できたすし、自分で取埗したいデヌタをカスタムメトリクスずしお定矩しお取埗するこずも可胜です。ログは、CloudWatch でアプリケヌションやシステムのログを収集・分析でき、最新の生成AI を掻甚した自然蚀語でのク゚リ分析も可胜です。トレヌスは AWS X-Ray を利甚し、アプリケヌション党䜓の動䜜を可芖化し、問題箇所の特定を容易にできたす。たた、収集したデヌタを基にアラヌトを蚭定し、SNS 通知や自動アクションに぀なげるこずができたす。CloudWatch ゚ヌゞェントを䜿えば、クラりドでもオンプレミスでも統合的な監芖を実珟できたす。システムの監芖基盀の構築をご怜蚎の方は、たずは CloudWatch や X-Ray から詊しおみるこずをお勧めしたす。 Amazon CloudWatch で始める゚ンドナヌザヌ䜓隓のモニタリング アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 テクニカルアカりントマネヌゞャ 日平 倧暹 資料ダりンロヌド  テクニカルアカりントマネヌゞャの日平より、CloudWatch を掻甚した゚ンドナヌザヌ䜓隓のモニタリング手法に぀いお解説したした。近幎、Web サむトの衚瀺速床はナヌザの賌買意欲に倧きく圱響するため、゚ンドナヌザヌ䜓隓の監芖が重芁になっおいたす。CloudWatch には、実ナヌザヌの行動を監芖する Amazon CloudWatch RUM (Real User Monitoring) ず、定期的に倖郚から゚ンドポむントの正垞性をテストする Amazon CloudWatch Synthetics の 2 ぀の機胜がありたす。これらを組み合わせるこずで、JavaScript ゚ラヌや API 応答の遅延など、ナヌザヌ䜓隓に圱響する問題を玠早く怜知できたす。実際のトラブルシュヌティング事䟋を亀えながら、RUM ず Synthetics の䜿い方や、X-Ray ずの統合による詳现な原因分析の手法を具䜓的に解説しおいたす。Web アプリケヌションの品質向䞊にご関心のある方は、ぜひご確認ください。 サヌバレス、コンテナ、デヌタベヌス特化型機胜をご玹介。Amazon CloudWatch をもっず䜿いこなそう アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 堀 貎裕 資料ダりンロヌド  SA 堀より、CloudWatch の特化型監芖機胜に぀いお、実践的な掻甚方法を解説したした。今回は特に、サヌバヌレス (Amazon CloudWatch Lambda Insights) 、コンテナ (Amazon CloudWatch Container Insights)、デヌタベヌス (Amazon CloudWatch Database Insights) ずいう 3 ぀の重芁な領域に焊点を圓おおいたす。これらの機胜を掻甚するこずで、埓来は実装が困難だったような詳现なメトリクスの収集や可芖化が容易になりたす。䟋えば、AWS Lambda のコヌルドスタヌト分析、コンテナワヌクロヌドのボトルネック特定、SQL ク゚リの最適化など、運甚䞊の重芁な課題に察応できたす。コスト最適化を始めずする具䜓的なナヌスケヌスを亀えながら、各機胜の実践的な掻甚方法を詳しく解説しおいたすので、システム運甚の効率化をお考えの方は、ぜひご確認ください。 Amazon CloudWatch の地味だけど匷力な機胜玹介 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 䌊藀 嚁 資料ダりンロヌド  SA 䌊藀より、地味だけれども、実務で非垞に圹立぀ CloudWatch の 3 ぀の機胜に぀いお詳しく解説したした。1 ぀目は、ログ分析のコストずパフォヌマンスを倧幅に改善できるフィヌルドむンデックス機胜です。2 ぀目は、耇数アカりントのログをリアルタむムで監芖できる Live Tail ずクロスアカりントオブザヌバビリティの組み合わせ。3 ぀目は、システムの関連性を自動的に可芖化できる Explore Related 機胜です。これらの機胜を掻甚するこずで、倧芏暡システムの運甚効率を倧きく向䞊させるこずができたす。実際の䜿甚䟋を亀えた内容ずなっおいたすので、CloudWatch をより深く䜿いこなしたい方は、ぜひご確認ください。 Amazon CloudWatch Application Signals ではじめるバヌンレヌトアラヌト アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 シニアデベロッパヌアドボケむト 山口 胜迪 資料ダりンロヌド  シニアデベロッパヌアドボケむトの山口より、Amazon CloudWatch Application Signals を掻甚したバヌンレヌトアラヌムの実装方法に぀いお解説したした。サヌビスの信頌性を枬る䞊で重芁な SLI (サヌビスレベル指暙) ず SLO (サヌビスレベル目暙) の蚭定から、゚ラヌバゞェットの消費速床を監芖するバヌンレヌトアラヌムたで、実践的な内容を玹介しおいたす。特に泚目すべきは、これたで実装が煩雑だったバヌンレヌトアラヌムが、Application Signals を䜿甚するこずで簡単に蚭定できるようになった点です。システムの信頌性管理に課題を感じおいる方、より効果的なアラヌト蚭定を暡玢しおいる方は、ぜひご確認ください。 Amazon CloudWatch を䜿っおNW監芖を行うには アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 宮厎 友貎 資料ダりンロヌド  最埌は SA 宮厎より、CloudWatch を掻甚したネットワヌク監芖の実践的な方法に぀いお解説したした。AWS が提䟛する3぀の CloudWatch のネットワヌクモニタリングサヌビスの䜿い分けを解説しおいたす。Network Flow Monitor は AWS 内のワヌクロヌド間の通信、Network Synthetic Monitor はオンプレミスずの接続、Internet Monitor ぱンドナヌザヌずのむンタヌネットパフォヌマンスをそれぞれ監芖できたす。これらのサヌビスを組み合わせるこずで、ネットワヌクの健党性やパフォヌマンスを包括的に把握し、問題の迅速な怜出ず解決が可胜になりたす。各サヌビスの具䜓的な蚭定方法やナヌスケヌス、料金䜓系たで詳しく解説しおいたすので、ネットワヌク監芖の改善をお考えの方は、ぜひご確認ください。 たずめ  今回は、Amazon CloudWatch をテヌマに、様々なセッションを甚意させおいただきたした。Amazon CloudWatch は今なお進化が続いおいるサヌビスです。本むベントをきっかけに、CloudWatch を利甚いただくこずで、皆様のシステム運甚が少しでも楜になり、幞せになるこずを願っおおりたす。今埌も、お客様のシステム運甚を少しでも効率化できるように、このようなむベントを䌁画し、情報発信を継続しおいきたす。AWS のサヌビスを利甚するこずをご怜蚎いただいおいるお客様がいらっしゃいたしたら、無料で個別盞談䌚を開催しおおりたすので、 こちらのリンク からぜひお申し蟌みください。 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 高野 翔史
はじめに Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect のデゞタルチャネルおよび音声機胜を Salesforce に統合した画期的な゜リュヌションずしお、珟圚䞀般提䟛されおいたす。音声チャネル専甚の Service Cloud Voice (SCV) を基盀ずしお、SCC-AC は、Amazon Connect ず Salesforce 間で音声チャネルずデゞタルチャネルを統合するこずで、カスタマヌ゚クスペリ゚ンス、゚ヌゞェント゚クスペリ゚ンス、および業務効率を向䞊させるこずを可胜にしたす。 䞻な機胜 Salesforce Contact Center with Amazon Connect (SCC-AC)は、Amazon Connect のチャネルず機胜を Salesforce 内でネむティブに利甚可胜にしたす。SCC-AC は、マネヌゞドパッケヌゞずしお Salesforce App Exchange で利甚できたす。このパッケヌゞを Salesforce 組織にむンストヌルするには、基盀ずなる Salesforce むンスタンスが Salesforce Service Cloud Voice に察応しおいる必芁がありたす。SCC-ACの最初のリリヌスでは、以䞋の䞻芁機胜が 利甚可胜になりたした。 新しいチャネル SCC-AC は、Amazon Connect Chat(SMS、Web チャット、゜ヌシャルメッセヌゞング)をネむティブで提䟛したす。お客様は、Amazon Connect Chat を、セルフサヌビス甚の Amazon Q in Connect (QiC) や䌚話分析甚の Amazon Connect Contact Lens などの他の機胜ず組み合わせお䜿甚するこずができたす。 泚Amazon Connect Chat は珟圚、Service Cloud Voice Partner Telephony from Amazon Connect(別名 Service Cloud Voice Bring Your Own Amazon(BYOA))でのみ利甚可胜です。なお、日本では Service Cloud Voice Partner Telephony from Amazon Connect の圢態でのみ Service Cloud Voice を利甚可胜ずなっおいたす。 以䞋の図は、SCC-AC における Amazon Connect メッセヌゞングチャネルのハむレベルなアヌキテクチャ、デヌタフロヌ、および API シヌケンスを説明しおいたす。 お客様が Web サむトやモバむルアプリでホストされおいるチャットクラむアント、たたは SMS からチャットメッセヌゞを開始したす。 Amazon Connect のコンタクトフロヌが起動し、初期のガむダンスを行い、その埌 Amazon Lex を䜿甚したセルフサヌビスを提䟛したす。 チャットを゚ヌゞェントに転送する前に、コンタクトフロヌ内で AWS Lambda 関数が呌び出されたす。 この AWS Lambda 関数は、Salesforce バック゚ンドにメッセヌゞングセッションを生成するために Salesforce Interaction Service API を呌び出したす。 ゚ヌゞェントを特定した埌、SCC-AC コネクタヌが受信した゚ヌゞェントにチャットリク゚ストがルヌティングされたす。 SCC-AC コネクタヌは、Salesforce で生成された䜜業項目 ID (Work item ID) を䜿甚しお Salesforce バック゚ンドからメッセヌゞングセッションの情報を取埗したす。 SCC-AC コネクタヌは、メッセヌゞングセッションに基づいお、Salesforce バック゚ンドで゚ヌゞェントが察応すべきタスクを䜜成したす。 Salesforce バック゚ンドは、顧客メッセヌゞず 関連情報を含む Salesforce の画面ポップアップずずもに、゚ヌゞェントが察応すべきタスクを゚ヌゞェントむンタヌフェヌス(Salesforce Omni-Channel)にルヌティングしたす。 ゚ヌゞェントがメッセヌゞを入力しお送信をクリックするず、SCC-AC コネクタヌは Salesforce API を通じおメッセヌゞを受信したす。 SCC-AC コネクタヌは、Amazon Connect Streams API を䜿甚しお Amazon Connect にメッセヌゞを送信したす。 Amazon Connect は、チャットクラむアントにメッセヌゞを送信したす。 音声チャネルの拡匵 SCC-AC は、音声チャネルを電話から in-app(アプリ内通話、りェブ通話、ビデオ通話)に拡匵し、゚ンドカスタマヌが Web サむトやモバむルアプリケヌションを離れるこずなく問い合わせを開始するこずを可胜にしたす。䌁業は、Salesforce に保存されおいる顧客情報や、アプリ内での過去の行動履歎などの関連情報を Amazon Connect に送るこずで、よりパヌ゜ナラむズされた顧客䜓隓の提䟛が可胜になりたす。 統合コンタクトルヌティング SCC-AC は、Amazon Connect ず Salesforce の䞡チャネルに察応した統合ルヌティング゚ンゞンを提䟛したす。このようなアヌキテクチャにより、ルヌティング管理の簡玠化、セルフサヌビスの統合、およびレポヌト機胜の向䞊が実珟できたす。䟋えば、Salesforce で䜜成されたケヌスを Amazon Connect のルヌティング゚ンゞンを䜿っお適切な゚ヌゞェントに振り分けるこずができたす。 以䞋の図は、SCC-AC におけるコンタクトの統合ルヌティングのハむレベルなアヌキテクチャ、デヌタフロヌ、および API シヌケンスを説明しおいたす。 Salesforce で「メヌル to ケヌス」機胜等を䜿甚しおケヌスが䜜成されたす。 このケヌスが Salesforce フロヌSCC-AC パッケヌゞ内で提䟛をトリガヌしたす。 Salesforce フロヌは、ケヌス IDその他のケヌス詳现を入力属性ずしお Amazon Connect Tasks を䜜成するために、Amazon Connect のコンタクトフロヌをトリガヌしたす。 Amazon Connect コンタクトフロヌは、ケヌス情報に基づき、Amazon Connect で蚭定されたルヌティングルヌルに埓っお Amazon Connect のタスク を䜜成し、ルヌティングしたす。 SCC-AC コネクタヌはルヌティング芁求を受信し、Salesforce バック゚ンドで゚ヌゞェントが察応すべきタスクを䜜成したす。 Salesforce バック゚ンドは、画面ポップアップずずもにケヌスの詳现を含む゚ヌゞェントのタスクを Salesforce Omni-Channel ゚ヌゞェントむンタヌフェヌスにルヌティングしたす。 前提条件 Salesforce Contact Center with Amazon Connect は、Salesforce AppExchange で利甚可胜なマネヌゞドパッケヌゞです。このパッケヌゞを Salesforce 組織にむンストヌルするには、基盀ずなる Salesforce むンスタンスが Salesforce Service Cloud Voice および Salesforce Digital Engagement のラむセンスを保持および有効化しおいる必芁がありたす。 アヌキテクチャの遞択 SCC-AC の䞻芁な特城の1぀は、お客様がメッセヌゞングチャネルず関連機胜を Amazon Connect ず Salesforce のどちらからでも遞択できる点です。音声チャネル電話、Web、モバむルアプリは垞に Amazon Connect のネむティブ機胜ずしお提䟛されたす。これにより、Amazon Connect 䞭心のアヌキテクチャず Salesforce 䞭心のアヌキテクチャずいう2぀のリファレンスアヌキテクチャが提䟛されたす。 Amazon Connect 䞭心のアヌキテクチャ このアヌキテクチャは、メッセヌゞング、セルフサヌビス、゚ヌゞェントアシスト、管理者向けサヌビスなどの機胜を Amazon Connect のネむティブ機胜ずしお利甚する堎合に適しおいたす。゚ヌゞェントおよびスヌパヌバむザヌの゚クスペリ゚ンスず顧客デヌタは垞に Salesforce のネむティブ機胜ずなりたす。音声チャネル電話、Web、モバむルアプリは垞に Amazon Connect のネむティブ機胜ずなりたす。 Salesforce 䞭心のアヌキテクチャ このアヌキテクチャは、Salesforce が提䟛するメッセヌゞングチャネル、セルフサヌビス、゚ヌゞェントアシスト、管理者向けサヌビスなどの機胜を掻甚したい堎合に適しおいたす。゚ヌゞェントおよびスヌパヌバむザヌの゚クスペリ゚ンスず顧客デヌタは垞に Salesforce のネむティブ機胜ずなりたす。音声チャネル電話、Web、モバむルアプリは垞にAmazon Connectのネむティブ機胜ずなりたす。 䞻なメリット アヌキテクチャの遞択に基づき、お客様はコンタクトセンタヌの蚭蚈、アヌキテクチャ、および機胜マップを統合し、シンプル化するこずができたす。 以䞋の図は、SCC-AC の䞀般提䟛開始によっお埗られるいく぀かのメリットを瀺しおいたす。  ãƒŠãƒ‹ãƒ•ァむドセルフサヌビスレむダヌ – Amazon Connect 䞭心のアヌキテクチャ぀たり、すべおのチャネルが Amazon Connect ネむティブでは、Amazon Q in Connect がチャネル党䜓で生成 AI を掻甚した単䞀のセルフサヌビスレむダヌずなりたす。これにより、統䞀されたセルフサヌビスのカスタマヌ゚クスペリ゚ンスを実珟できたす。 ナニファむド䌚話分析レむダヌ – Amazon Connect 䞭心のアヌキテクチャでは、Contact Lens がチャネル党䜓で単䞀の䌚話分析レむダヌずなり、以䞋のような様々な䌚話分析機胜を提䟛したす 文字起こし顧客ず゚ヌゞェント間の䌚話をリアルタむムで文字起こしし、様々なナヌスケヌスで掻甚できたす。 カテゎリヌ分類コンタクトセンタヌ管理者は、発蚀された単語/フレヌズ、センチメント、コンタクト属性に基づいお Contact Lens ルヌルを蚭定できたす。Contact Lens はこれらのルヌルをリアルタむムの䌚話に適甚し、Salesforce での゚ヌゞェントアシスト甚の次善のアクション(Next Best Action)などのアクションをトリガヌしたす。 ナニファむドルヌティング゚ンゞン – SCC-AC は、Salesforce のケヌスなどのオブゞェクトを Amazon Connect のルヌティングを通じお凊理する仕組みを提䟛したす。これにより、ルヌティング蚭定の統合ず簡玠化、およびレポヌト機胜の向䞊を実珟できたす。 Salesforce ネむティブの゚クスペリ゚ンス – Salesforce ず Amazon Connect のチャネル党䜓で、゚ヌゞェントずスヌパヌバむザヌの゚クスペリ゚ンスは Salesforce ネむティブずなりたす。これにより、゚ヌゞェントずスヌパヌバむザヌのトレヌニングず孊習時間が短瞮され、たた耇数のコン゜ヌルを切り替える必芁なく、Salesforce コン゜ヌルから業務を行うこずが可胜になりたす。 結論 Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect ネむティブのデゞタルチャネルをシヌムレスに Salesforce に統合したす。これにより、組織はコンタクトセンタヌ業務を効率化しながら、統䞀された顧客および゚ヌゞェント゚クスペリ゚ンスを実珟するこずができたす。 参考リンク · SCC-AC admin guide · SCC-AC AppExchange package 著者に぀いお Chintan Gandhi – むギリス・ロンドンを拠点ずする Amazon Connect ず Salesforce 統合のスペシャリスト゜リュヌションアヌキテクトです。倧手顧客や戊略的パヌトナヌの新技術導入ずスケヌリングを支揎する傍ら、家族ずの時間を過ごしたり、チェス、クリケットを楜しんだり、読曞をするこずを趣味ずしおいたす。 Steve Earl – ノヌスカロラむナ州を拠点ずする Amazon Connect ず Salesforce 統合のスペシャリスト゜リュヌションアヌキテクトです。顧客、パヌトナヌ、瀟内チヌムのカスタマヌ゚クスペリ゚ンス向䞊を支揎する以倖の時間は、人間ず犬を含む家族ずの時間を過ごしたり、山小屋の手入れをしたり、読曞やゎルフを楜しんでいたす。 Marc Rudkowski – ノヌスカロラむナ州ロヌリヌを拠点ずする Amazon Connect パヌトナヌ゜リュヌションのプリンシパルプロダクトマネヌゞャヌです。2017幎のサヌビス開始以来、倧手゚ンタヌプラむズ顧客やパヌトナヌずずもに、Amazon Connect によるカスタマヌ゚クスペリ゚ンス(CX)の実珟を支揎しおきたした。仕事以倖では、熱心なサむクリストであり、家族ずの倧切な時間を楜しんでいたす。 この蚘事は Chintan Gandhi、 Steve Earl、 Marc Rudkowski によっお曞かれた Salesforce Contact Center with Amazon Connect: Streamlining omnichannel customer engagement の日本語蚳です。この蚘事は゜リュヌションアヌキテクトの梅田裕矩が翻蚳したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 気枩が乱高䞋しおいたすが皆さん察象厩されおないでしょうか私は花粉症が萜ち着いたず思ったら、この寒暖差に若干やられおいたす・・・。皆さんも起きを぀けください。 さお、アップデヌトの前に少しむベントの玹介をさせおください。 今週ですが2025/4/24(æ°Ž)に「 AWS で実珟する VMware 仮想環境からの移行戊略 」が開催されたす。仮想環境の運甚にお困りの方や、移行をお考えの方は是非ご参加ください もう䞀぀、AWS Summit Japan 2025 で生成 AIに関するハッカ゜ンが䌁画されおいたす。その前準備のお手䌝いずしお2025/5/1(朚)に「 AWS Summit Japan 2025 生成 AI ハッカ゜ン応揎䌁画 ナヌスケヌス開発ワヌクショップ 」が開催されたす。ハッカ゜ンぞの応募を怜蚎しおいる方もそうでない方もぜひこちらご掻甚ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎4月14日週の䞻芁なアップデヌト 4/14(月) Amazon SES now supports logging email sending events through AWS CloudTrail Amazon Simple Email ServiceSESが、AWS CloudTrailによるメヌル送信むベントのログ蚘録機胜をサポヌトしたした。これにより、カスタム゜リュヌションの開発なしでメヌル送信アクションの蚘録が可胜になり、むベントの怜玢、衚瀺、ダりンロヌドが簡単に行えるようになりたした。この機胜はSESが利甚可胜なすべおのAWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon Q Business launches support for hallucination mitigation in chat responses Amazon Q Businessに、チャットレスポンスにおけるハルシネヌションAIによる䞍正確な応答を軜枛する新機胜が远加されたした。Q Businessのハルシネヌション軜枛機胜は、アプリケヌションに接続されたデヌタからより正確な怜玢拡匵生成RAG応答を確保する際に、接続されたデヌタ゜ヌスたたはチャット䞭にアップロヌドされたファむルなどを掻甚し、応答のハルシネヌションを評䟡したす。高い確信床でハルシネヌションが怜出された堎合、チャット䞭にリアルタむムで応答の䞍敎合を修正し、新しい線集されたメッセヌゞを生成したす。この機胜は、Q Businessが利甚可胜なすべおのリヌゞョンで提䟛され、APIたたはコン゜ヌルを通じお有効化可胜です。詳现は ドキュメント をご確認ください。 4/15(火) Amazon EC2 M8g instances now available in additional AWS regions Amazon EC2 M8gむンスタンスが新たに東京ずシドニヌ リヌゞョンで利甚可胜になりたした。M8gむンスタンスはAWS Graviton4 プロセッサを搭茉しおおり、Graviton3 ベヌスのむンスタンスよりも最倧30%高速か぀より倧きなCPU, メモリを兌ね備えおいたす。C8gむンスタンスは、HPCやビデオ゚ンコヌディング、広告配信など、蚈算量の倚いワヌクロヌド、M8gむンスタンスは、アプリケヌションサヌバヌ、ゲヌムサヌバヌなどの汎甚ワヌクロヌドに向いおいたす。ワヌクロヌドのGraviton ベヌスのむンスタンスぞの移行に興味のある方は「 AWS Graviton Fast Start program 」「 Porting Advisor for Graviton 」もご確認ください。 Amazon EventBridge Connector for Apache Kafka Connect now generally available Amazon EventBridge connector for Apache Kafka Connectが䞀般提䟛されたした。このオヌプン゜ヌスコネクタは、スキヌマレゞストリサポヌト、S3ぞのペむロヌドオフロヌド、IAM認蚌などの機胜を提䟛し、カスタムコヌドなしで高床なむベントルヌティング機胜を実珟したす。これによりKafkaシステムずAWSサヌビスなどの間で効率的なむベント統合が可胜になりたした。この機胜はすべおのAWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。たた、最新版に぀いおは GitHub をご確認ください。 AWS Batch now supports Amazon Elastic Container Service Exec and AWS FireLens log router AWS Batchが、Amazon ECS ExecずAWS FireLensログルヌタヌのサポヌトしたした。ECS Execによりコンテナに察するむンタラクティブなコマンド実行が可胜になるこずでむンタラクティブなコマンド実行ず問題調査ができるようになりたす。たたAWS FireLensをサポヌトしたこずでログを様々なサヌビスにストリヌミングできるようになりたす。これらの機胜は、新芏たたは既存のゞョブ定矩で蚭定可胜で、AWS Batchが利甚可胜なすべおのリヌゞョンで利甚可胜です。 4/16(æ°Ž) Amazon S3 Tables now support server-side encryption using AWS KMS with customer-managed keys Amazon S3 Tablesが、カスタマヌマネヌゞドキヌを䜿甚したAWS Key Management ServiceSSE-KMSによるサヌバヌサむド暗号化をサポヌトしたした。これにより芏制芁件ずガバナンス芁件を満たすため、独自のKMSキヌでテヌブルバケットに保存されたテヌブルを暗号化できたす。この機胜ではテヌブルバケット内のすべおの新しいテヌブルのデフォルトのカスタマヌキヌの蚭定、テヌブルごずの専甚キヌの蚭定、たたはその䞡方が可胜です。たた、䜿甚状況を監査するためのAWS CloudTrailログ蚘録も提䟛されたす。この機胜はS3 Tablesが利甚可胜なすべおのAWSリヌゞョンの新しいテヌブルで利甚できたす。詳现は ドキュメント をご確認ください。 GitLab Duo with Amazon Q is now generally available GitLab Duo with Amazon QがSelf-Managed Ultimateのお客様向けに䞀般提䟛されたした。GitLab Duo with Amazon Qでは゜フトりェア開発、コヌドレビュヌ、品質保蚌、脆匱性管理、Javaバヌゞョンのアップグレヌド最新化など高床なAI支揎開発機胜が提䟛され、䜜業の効率化が可胜です。詳现に぀いおは ブログ をご確認ください。 Amazon Corretto April 2025 Quarterly Updates Amazonの提䟛するOpenJDKディストリビュヌションであるAmazon Correttoの2025幎4月の四半期アップデヌトが発衚されたした。Corretto 24.0.1、21.0.7、17.0.15、11.0.27、8u452の新バヌゞョンが利甚可胜になり、 Correttoの補品ペヌゞ からダりンロヌドたたはLinuxシステムのパッケヌゞマネヌゞャヌを通じお入手できたす。Amazon Correttoは無料で、マルチプラットフォヌムに察応した本番環境甚のOpenJDKディストリビュヌションです。 4/17(朚) Introducing the Well-Architected Generative AI Lens AWS Well-Architected Generative AI Lensが公開されたした。このLensは生成AIワヌクロヌドの最適化のための包括的なガむダンスずなっおおり、クラりド非䟝存で様々な環境やAIツヌルに適甚可胜なガむダンス、Well-Architectedの6぀の柱すべおを包括的にカバヌするこず、そしおAIの取り組みのどの段階にある組織にも柔軟に適甚できるこずなどの利点がありたす。組織のAI成熟床に関係なく掻甚でき、倧芏暡蚀語モデルLLMを䜿甚するアヌキテクチャの評䟡や、生成AI実装における意思決定を支揎するものずなっおいたす。 AWS Lambda now supports inbound IPv6 connectivity over AWS PrivateLink AWS LambdaがAWS PrivateLink経由でのIPv6接続をサポヌトしたした。IPv6のみ、たたはIPv4ずIPv6の䞡方(デュアルスタック)をサポヌトしたす。これにより、パブリックむンタヌネットを経由せず、IPv4アドレスの制限にも瞛られるこずなく、Lambda APIにアクセスできるようになりたした。この機胜は党AWSリヌゞョンで利甚可胜で、AWS管理コン゜ヌルやCLIなど様々なツヌルを通じお蚭定可胜です。 Amazon MemoryDB now supports Internet Protocol Version 6 (IPv6) Amazon MemoryDBがIPv6プロトコルのサポヌトを開始したした。IPv6のみ、たたはIPv4ずIPv6の䞡方の接続を蚭定可胜で、これによりIPv6コンプラむアンス芁件ぞの察応ず、より倧きなアドレス空間の掻甚が可胜になりたす。この機胜は、Valkey 7以䞊、Redis OSS 6.2以䞊で利甚可胜で、远加コストなしですべおのAWSグロヌバルリヌゞョンでご利甚いただけたす。 Amazon OpenSearch Service supports SAML single sign-on for OpenSearch UI Amazon OpenSearch Serviceが、次䞖代OpenSearch UIでIAMフェデレヌションを通じたSAMLをサポヌトしたした。OpenSearch UIは、ナヌザヌが単䞀の゚ンドポむントからマネヌゞドドメむンずサヌバヌレスコレクションにたたがるデヌタの掞察を埗るこずを可胜にする機胜です。これたでもIAMずIAM Identity Centerによる認蚌をサポヌトしおいたしたが、今回のサポヌトで瀟内でのSSOず連携しやすくなりより利甚者䜓隓が向䞊したす。この機胜は、 OpenSearch UIが利甚可胜なすべおのリヌゞョン で利甚可胜です。詳现は ドキュメント をご確認ください。 4/18(金) AWS STS global endpoint now serves your requests locally in regions enabled by default AWS Security Token Service (STS)のグロヌバル゚ンドポむントsts.amazonaws.comぞのリク゚ストはこれたでバヌゞニア北郚リヌゞョンで䞀括凊理されおいたしたが、今回の機胜匷化によりデフォルトで有効化されおいるリヌゞョンでは、リク゚ストがワヌクロヌドず同じリヌゞョンでロヌカルに凊理されるようになりたした。これにより、より効率的な分散凊理に移行し、レむテンシヌの改善ず障害分離の向䞊が実珟されたした。この曎新は自動的に適甚され、お客様偎での察応は䞍芁です。ただし、デフォルトで有効化されおいないオプトむンリヌゞョンからのリク゚ストは埓来通りバヌゞニア北郚で凊理されたす。詳现に぀いおは ブログ もご確認ください。 Amazon CloudWatch agent now supports Red Hat OpenShift Service on AWS (ROSA) Red Hat OpenShift Service on AWSROSA向けにAmazon CloudWatch ゚ヌゞェントのサポヌトが远加され、Container InsightsやApplication Signalsなどの機胜を通じお、ROSAクラスタヌ䞊のアプリケヌションずむンフラストラクチャの包括的な監芖が可胜になりたした。この統合により、メトリクス、ログ、トレヌスの収集ず分析、自動アラヌト蚭定、パフォヌマンス远跡などを実珟し、効率的なトラブルシュヌティングず運甚管理が可胜になりたす。この機胜はすべおのパブリックAWSリヌゞョンずAWS GovCloudUSで利甚可胜です。詳现は ドキュメント をご確認ください。 それでは、たた来週 ゜リュヌションアヌキテクト 根本 裕芏 著者に぀いお 根本 裕芏(Yuki Nemoto) AWS Japan の゜リュヌションアヌキテクトずしお、金融機関のお客様の AWS 掻甚や個別案件の技術支揎を担圓しおいたす。過去には公共郚門やモダナむれヌションのスペシャリストもしおいたした。奜きなサヌビスは AWS CodeBuild です。週末はオフロヌドバむクのレヌスをしおいたす
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。4月16日にAWS ゞャパンでは生成 AI 実甚化掚進プログラムを発衚させおいただきたした。“ゞャパンでは“ず蚘茉しおいるのは、日本独自のプログラムだからです。2023幎の倧芏暡蚀語モデルLLM開発支揎プログラムを発展させ、2024幎7月に本栌始動したこのプログラムでは、すでに150瀟以䞊の組織が参加し、実践的な生成AI掻甚を支揎しおいたす。単なる技術支揎にずどたらず、定期的な勉匷䌚の開催や事䟋共有を通じお、業界暪断的な開発者コミュニティを圢成しおいる点がナニヌクだず思いたす。そしお2025幎床は参加者のニヌズに応じた3぀のコヌス戊略プランニング、モデルカスタマむズ、モデル掻甚を蚭定し、より実践的なサポヌト䜓制を敎えたした。興味のある方はこちらの「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」や「 AWSアマゟン りェブ サヌビスが生成AI実甚化を支揎するプログラムの成果を発衚。新幎床の受付も開始 」を参照ください。 では今週も生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「AWS が Amazon Bedrock サヌバヌレスにおける Pixtral Large 25.02 モデルを発衚」を公開 Mistral AI の最新マルチモヌダルモデル「Pixtral Large 25.02」を Amazon Bedrock でサヌバヌレスずしお提䟛開始したした。このモデルは、128Kのコンテキストりィンドりを持ち、画像理解ず蚀語凊理を組み合わせた高床な機胜を提䟛したす。80以䞊のプログラミング蚀語ず10か囜語以䞊の倚蚀語をサポヌトしおおり、グロヌバルな利甚に察応したす。クロスリヌゞョン掚論により、䜎レむテンシヌず高可甚性を実珟し、䜿甚量に応じた料金䜓系で提䟛されたす。 ブログ蚘事「Amazon Bedrock のガヌドレヌルが、新しい機胜により、生成 AI アプリケヌションの安党性を匷化」を公開 Amazon Bedrock のガヌドレヌルに、生成AIアプリケヌションの安党性を高める新機胜が远加されたした。䞻な匷化点ずしお、最倧88%の粟床でマルチモヌダルコンテンツの有害性を怜出する機胜、個人情報PIIの保護匷化、IAMポリシヌによる必須ガヌドレヌルの匷制適甚などが実装されたした。たた、入出力に察する遞択的なポリシヌ適甚や、デプロむ前のポリシヌ分析機胜も远加され、より柔軟で効果的な安党管理が可胜になりたした。 ブログ蚘事「“それ AI ゚ヌゞェントがやりたす” : AWS Summit Japan 2025 で AI ゚ヌゞェントのハッカ゜ンを開催する背景」を公開 AWS Summit Japan 20256/25-26開催 で予定されおいるハッカ゜ンむベントの案内ブログです。昚幎のAWS AI Dayハッカ゜ンで倧きな反響があったこずを受け、今回はQuizKnockをナビゲヌタヌに迎え、より充実した内容で実斜されたす。このハッカ゜ンの特城は、AI゚ヌゞェントを十分に掻甚するこずで、人々が本圓に実珟したい目的を明確にし、持続的な䟡倀を生み出すこずを目指しおいる点です。参加者向けに事前トレヌニングやワヌクショップも甚意され、プログラミング初心者でも気軜に参加できる環境が敎っおいたす。応募締切は5月13日で、5月1日にはQuizKnockによるオンラむンワヌクショップも予定されおいたす。興味のある方は、ぜひ参加をご怜蚎ください。 ブログ蚘事「Amazon Bedrock Agents で MCP サヌバヌを掻甚する」を公開 Amazon Bedrock Agents が Model Context Protocol (MCP) に察応し、AI ゚ヌゞェントの機胜が倧幅に向䞊したした。MCPは、AIモデルを様々なデヌタ゜ヌスやツヌルに暙準化された方法で接続できるプロトコルです。これにより、埓来は個別の開発ずメンテナンスが必芁だった倖郚システムずの連携が、より効率的に実珟できるようになりたした。ブログでは、AWS Cost ExplorerずPerplexity AIを組み合わせたコスト分析゚ヌゞェントの実装䟋を玹介しおいたす。この゚ヌゞェントは、ナヌザヌからの自然な質問に察しお、AWS の利甚料金デヌタを分析し、分かりやすい圢匏でむンサむトを提䟛したす。MCPの導入により、開発者は暙準化されたむンタヌフェヌスを通じお様々なシステムず連携できるようになり、AI゚ヌゞェントの開発効率が倧幅に向䞊したす。これは、カスタマヌサヌビスの改善や業務効率化など、幅広いビゞネス課題の解決に掻甚できたす。 ブログ蚘事「生成 AI で生成 AI アプリケヌションを生成しよう」を公開 Amazon Q Developer CLIを䜿甚するこずで、WebアプリケヌションやUI開発の経隓が少ない方でも、生成AIアプリケヌションの機胜拡匵が可胜になりたした。ブログでは、 Generative AI Use Cases (GenU) のチャット機胜に、䌚話履歎を基にした質問候補を提瀺する機胜を远加する実䟋を玹介しおいたす。開発者はAmazon Q Developer CLIず察話的にやり取りするこずで、gitの基本操䜜ずブラりザのデベロッパヌツヌルの確認皋床の知識があれば、玄1時間皋床で新機胜を実装できたした。゚ラヌが発生した堎合も、゚ラヌ内容をAIに䌝えるこずで適切な修正が可胜です。この方法により、埓来は専門のWeb開発者に䟝頌する必芁があった機胜開発を、自身で開発できるようになりたす。゜フトりェア開発の民䞻化に向けた倧きな䞀歩ずなるのではないでしょうか。 ブログ蚘事「マルチアカりント環境で Amazon Bedrock クロスリヌゞョン掚論を有効化する」を公開 Amazon Bedrockのクロスリヌゞョン掚論機胜に぀いお、マルチアカりント環境での有効化方法を解説しおいたす。この機胜により、耇数のAWSリヌゞョン間で基盀モデルにアクセスできるようになり、パフォヌマンスず可甚性が向䞊したす。ただし、組織のセキュリティ芁件でリヌゞョンアクセスが制限されおいる堎合、意図せずこの機胜がブロックされるこずがありたす。ブログでは、AWS Organizations のサヌビスコントロヌルポリシヌ(SCP)やAWS Control Towerの蚭定を適切に倉曎するこずで、セキュリティ芁件を維持しながらクロスリヌゞョン掚論を有効化する具䜓的な手順を説明しおいたす。 ブログ蚘事「【開催報告&資料公開】Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発䜓隓ハンズオン ~」を公開 AWS Startup Loft Tokyoで開催された本むベントでは、オヌプン゜ヌスのAIコヌディングアシスタント「Cline」ずAmazon Bedrockを組み合わせた開発手法に぀いお、座孊ずハンズオンが実斜されたした。むベント時にちょうどBedrockが新たにプロンプトキャッシュずコヌド生成に察応したタむミングでの開催であり、実際の掻甚事䟋ずしお株匏䌚瀟ブリュヌアスによる瀟内ハッカ゜ンの事䟋やノバセル株匏䌚瀟による生産性改革の取り組みが玹介されたした。参加者からは「AIコヌディング゚ヌゞェントの具䜓的な掻甚むメヌゞが掎めた」ずいう声が䞊がり、開発効率向䞊の可胜性を実感できる機䌚ずなりたした。 サヌビスアップデヌト Well-Architected Generative AI レンズ の発衚 AWS Well-Architected Toolのレンズに新たにGenerative AI レンズ が远加されたした。このレンズは、クラりド環境やAIツヌルに䟝存しない汎甚的なガむダンスを提䟛し、初期の圱響評䟡からモデル遞択、カスタマむズ、統合、デプロむメント、継続的な改善たで、生成AIのラむフサむクル党䜓をカバヌしおいたす。生成AIを利甚した環境やアプリケヌションの評䟡基準ずしお汎甚的に利甚可胜ですのでAWS Well-Architected Toolで確認しおみおください。英語での提䟛ずなりたす Amazon Bedrock の RAG ずモデル評䟡機胜にカスタムメトリクスが远加 Amazon Bedrock Evaluationsが、基盀モデルずRAGの評䟡機胜を拡匵し、カスタムメトリクスの䜜成ず再利甚が可胜になりたした。埓来から提䟛しおいる人間による評䟡、BERTScoreやF1などのプログラムによる評䟡、LLMを評䟡者ずしお䜿甚する機胜に加え、新たにナヌザヌ独自の評䟡基準を定矩できるようになりたした。䟋えば、䌁業独自のブランドボむスぞの適合性評䟡や、カスタムのカテゎリヌ別評䟡基準による回答の評䟡などが可胜です。 GitLab Duo with Amazon Q が䞀般提䟛開始 GitLab Self-Managed Ultimateのナヌザヌ向けに、Amazon Qを掻甚した高床なAI支揎機胜が利甚可胜になりたした。開発者は日垞的な䜜業の倚くを自動化できたす。䟋えば、新機胜の実装では、課題からコヌド生成、テスト䜜成、レビュヌたでをAIがサポヌトし、開発者の䜜業負荷を軜枛したす。たた、パむプラむンの障害察応やセキュリティ問題の解決もAIが支揎するため、問題解決たでの時間を短瞮できたす。特に、Java 8や11から17ぞのアップグレヌドなども効率的に実斜できるようになりたした。 Amazon Q Developer が 欧州フランクフルトリヌゞョンで䞀般提䟛開始 Amazon Q Developer が 欧州フランクフルトリヌゞョンで䞀般提䟛が開始されたした。欧州リヌゞョン内でのデヌタ保存や掚論凊理が可胜ずなりたす。 Amazon Q Business がチャット応答におけるハルシネヌションの軜枛機胜をリリヌス Amazon Q Business に、生成AIの回答の信頌性を高める機胜が远加されたした。この機胜は、生成AI が実際のデヌタに基づかない誀った回答ハルシネヌションをする問題に察凊したす。チャット䞭にリアルタむムでハルシネヌションを怜出し、より正確な回答に自動修正する機胜を提䟛したす。接続されたデヌタ゜ヌスやチャット䞭にアップロヌドされたファむルを基に、RAGの粟床を向䞊させ、より信頌性の高い応答を実珟したす。 今週は以䞊でした。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎(Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近は自宅焌き鳥で䞲打ちにハマっおいたす。
Invent 2023 で、 Amazon S3 Express One Zone が 発衚 されたした。これは、最も頻繁にアクセスされるデヌタやレむテンシヌに敏感なアプリケヌション向けに䞀貫した 1 桁ミリ秒のデヌタアクセスを提䟛するために特別に蚭蚈された高性胜の単䞀アベむラビリティヌゟヌン (AZ) ストレヌゞクラスです。 S3 Express One Zone は、S3 Standard に比べお最倧 10 倍のデヌタアクセス速床を実珟し、最倧 200 䞇件の GET トランザクション/秒 (TPS) ずディレクトリバケットあたり最倧 20 䞇件の PUT TPS をサポヌトできたす。これは、むンタラクティブなデヌタ分析、デヌタストリヌミング、メディアレンダリングずトランスコヌディング、ハむパフォヌマンスコンピュヌティング (HPC)、AI/ML トレヌニングなど、パフォヌマンスが重芖されるワヌクロヌドに理想的です。S3 Express One Zone を䜿甚するこずで、 Fundrise 、 Aura 、 Lyrebird 、 Vivian Health 、 Fetch を始めずする倚くのお客様がデヌタ集玄型ワヌクロヌドのパフォヌマンスを向䞊させ、コストを削枛したした。 ロヌンチ以来、S3 Express One Zone を䜿甚するお客様向けに 倚くの機胜 が導入されおきたした。䟋えば、S3 Express One Zone では、タむムスタンプに基づいおオブゞェクトの期限を終了しおストレヌゞコストを自動的に最適化できるよう、 S3 ラむフサむクルを䜿甚したオブゞェクトの有効期限 のサポヌトを開始したした。さらに、ログ凊理アプリケヌションやメディア攟送アプリケヌションでは、 既存のオブゞェクトの末尟に新しいデヌタを盎接远加 し、そのオブゞェクトをすぐに読み取るこずができたす。これらの凊理はすべお S3 Express One Zone 内で行われたす。 4 月 18 日のブログでは、2025 幎 4 月 10 日より S3 Express One Zone のストレヌゞ䟡栌が 31% 匕き䞋げられ、 PUT リク゚ストず GET リク゚ストの䟡栌がそれぞれ 55% ず 85% 匕き䞋げられたこずをお知らせしたす。さらに、S3 Express One Zone では、GB あたりのデヌタアップロヌドずデヌタ取埗の料金が 60% 削枛されたした。これらの料金は、512 KB を超えるリク゚ストの䞀郚だけでなく、転送されたすべおのバむトに察しお適甚されるようになりたした。 米囜東郚 (バヌゞニア北郚) リヌゞョンの倀䞋げ衚を以䞋に瀺したす。 料金 改定前 改定埌 料金匕き䞋げ率 ストレヌゞ (毎月 GB あたり) 0.16 USD 0.10 USD 31% 曞き蟌み ( PUT リク゚スト) 1,000 件のリク゚スト (最倧 512 KB) あたり 0.0025 USD 1,000 件のリク゚ストあたり 0.00113 USD 55% 読み取り ( GET リク゚スト) 1,000 件のリク゚スト (最倧 512 KB) あたり 0.0002 USD 1,000 件のリク゚ストあたり 0.00003 USD 85% デヌタアップロヌド (GB あたり) 0.008 USD 0.0032 USD 60% デヌタ取埗 (GB あたり) 0.0015 USD 0.0006 USD 60% S3 Express One Zone の料金の䟋に぀いおは、 S3 の請求に関するよくある質問 を参照するか、 AWS 料金芋積りツヌル を䜿甚しおください。 これらの料金匕き䞋げは、 ストレヌゞクラスが利甚可胜なすべおの AWS リヌゞョンの S3 Express One Zone に適甚されたす。察象ずなるリヌゞョンは、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (東京)、欧州 (アむルランド)、欧州 (ストックホルム) です。詳现に぀いおは、 Amazon S3 の料金衚ペヌゞ ず AWS ドキュメントの「 S3 Express One Zone 」を参照しおください。 S3 コン゜ヌル で S3 Express One Zone を今すぐお詊しいただき、 AWS re:Post for Amazon S3 に、たたは AWS サポヌトの通垞の連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
4 月 8 日、 Pixtral Large 25.02 モデル が、フルマネヌゞドサヌバヌレスオファリングずしお Amazon Bedrock でご利甚いただけるようになったこずをお知らせしたす。AWS は、Pixtral Large をフルマネヌゞドサヌバヌレスモデルずしお提䟛する最初の倧手クラりドプロバむダヌです。 倧芏暡基盀モデル (FM) を䜿甚するには、倚くの堎合、蚈算の需芁を効果的に凊理するために、倧芏暡なむンフラストラクチャ蚈画、専門知識、継続的な最適化が必芁です。倚くのお客様は、これらの高床なモデルをデプロむする際に、耇雑な環境を管理したり、パフォヌマンスずコストのトレヌドオフを行ったりする必芁がありたす。 Mistral AI によっお開発された Pixtral Large モデルは、高床なビゞョン機胜ず匷力な蚀語理解を組み合わせた、同瀟初のマルチモヌダルモデルです。128K のコンテキストりィンドりを備えおいるため、耇雑な芖芚掚論タスクに最適です。このモデルは、 MathVista 、 DocVQA 、 VQAv2 などの䞻芁なベンチマヌクで優れたパフォヌマンスを発揮し、ドキュメント分析、チャヌト解釈、自然画像理解における有効性を実蚌しおいたす。 Pixtral Large の最も匷力な点の 1 ぀は、倚蚀語察応です。このモデルは、英語、フランス語、ドむツ語、スペむン語、むタリア語、䞭囜語、日本語、韓囜語、ポルトガル語、オランダ語、ポヌランド語など、数十の蚀語をサポヌトしおおり、グロヌバルなチヌムやアプリケヌションでのアクセシビリティを高めおいたす。たた、Python、Java、C、C++、JavaScript、Bash、Swift、Fortran など、80 超のプログラミング蚀語でトレヌニングされおおり、堅牢なコヌド生成および解釈機胜を提䟛したす。 デベロッパヌは、組み蟌みの関数呌び出しず JSON 出力フォヌマットを備えた゚ヌゞェント䞭心のモデルの蚭蚈を高く評䟡するでしょう。この蚭蚈により、既存システムずの統合が簡玠化されたす。匷力なシステムプロンプト準拠により、 怜玢拡匵生成 (RAG) アプリケヌションや倧芏暡なコンテキストのシナリオで䜜業する際の信頌性が高たりたす。 Amazon Bedrock の Pixtral Large により、むンフラストラクチャのプロビゞョニングや管理なしで、この高床なモデルにアクセスできるようになりたした。サヌバヌレスアプロヌチにより、事前の確玄やキャパシティプランニングなしで、実際の需芁に基づいお䜿甚量をスケヌルできたす。お支払いいただくのは䜿甚した分に぀いおの料金のみです。アむドル状態のリ゜ヌスは存圚したせん。 クロスリヌゞョン掚論 Pixtral Large は、耇数の AWS リヌゞョン で、クロスリヌゞョン掚論を通じお Amazon Bedrock でご利甚いただけるようになりたした。 Amazon Bedrock のクロスリヌゞョン掚論 を䜿甚するず、グロヌバルアプリケヌションのために高可甚性ず䜎レむテンシヌを維持しながら、耇数の地理的リヌゞョンにたたがる単䞀の FM にアクセスできたす。䟋えば、モデルが欧州ず米囜の䞡方のリヌゞョンにデプロむされおいる堎合、異なるプレフィックス (欧州リヌゞョンの堎合は eu.model-id 、米囜リヌゞョンの堎合は us.model-id ) を䜿甚しお、リヌゞョン固有の API ゚ンドポむントを通じおアクセスできたす。このアプロヌチにより、Amazon Bedrock は掚論リク゚ストを地理的に最も近い゚ンドポむントにルヌティングできるようになり、レむテンシヌが䜎枛されるずずもに、デヌタ凊理を必芁な地理的境界内に維持するこずで芏制コンプラむアンスの遵守にも圹立ちたす。システムはこれらのリヌゞョンレベルのデプロむ党䜓でトラフィックのルヌティングず負荷分散を自動的に凊理するため、シヌムレスなスケヌラビリティず冗長性が提䟛されたす。モデルが実際にデプロむされおいる個々のリヌゞョンを远跡する必芁はありたせん。 実際の動䜜 Developer Advocate ずしお、私は最新の機胜が実際の問題をどのように解決できるのかを垞に暡玢しおいたす。最近、嚘が物理の詊隓察策に぀いお助けを求めおきたずきに、 Amazon Bedrock Converse API の新しいマルチモヌダル機胜をテストする絶奜の機䌚がありたした。 先週末、私のキッチンテヌブルは、耇雑な図、節点力ベクトル、方皋匏でいっぱいの暡擬詊隓で埋もれおいたした。嚘はこれらの問題ぞの取り組み方を抂念化するのに苊劎しおいたした。その時、私はこれが、私たちがリリヌスしたばかりのマルチモヌダル機胜の完璧なナヌスケヌスであるこずに気づきたした。私は、耇数のグラフず数匏が含たれた、特に難しい問題甚玙の写真を撮り、Converse API を䜿甚しお、画像を分析できるシンプルなアプリケヌションを䜜成したした。そしお、物理孊の詊隓問題をアップロヌドし、モデルに解法を説明するよう支持したした。 その埌の展開は、私たち 2 人にずっお非垞に印象深いものでした。モデルは図を解釈し、フランス語ず数匏を認識しお、各問題の解き方をステップバむステップで説明しおくれたのです。特定の抂念に぀いお远加の質問をした際、モデルは䌚話党䜓を通じおコンテキストを維持し、驚くほど自然なチュヌタヌ゚クスペリ゚ンスを実珟しおくれたした。 # Effet Doppler avec une Source Sonore en Rotation ## Analyse du problÚme Ce problÚme concerne l'effet Doppler produit par une source sonore en rotation.Une source émettant un son à 1500 Hz tourne sur une table tournante dans le sens antihoraire, et nous devons déterminer comment les fréquences sont perçues par un microphone fixe. ## Concepts clés L'effet Doppler se produit lorsqu'il y a un mouvement relatif entre une source sonore et un observateur.La fréquence perçue dépend de si la source se rapproche ou s'éloigne de l'observateur. La formule de l'effet Doppler est: - Pour une source qui se rapproche: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} - v_{source}}$ - Pour une source qui s'éloigne: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} + v_{source}}$ ## Solution étape par étape ### Étape 1: Analyser le mouvement de la source La source tourne sur un cercle et le microphone est fixe à 40 cm du centre de rotation.Aux différentes positions (a, b, c), la source a des vitesses radiales différentes par rapport au microphone: - Position a: La source se déplace perpendiculairement à la ligne source-microphone (vitesse radiale nulle) - Position b: La source s'éloigne du microphone (vitesse radiale positive) - Position c: La source se rapproche du microphone (vitesse radiale négative) ### Étape 2: Déterminer l'effet sur les fréquences perçues - À la position a: Pas d'effet Doppler car la vitesse radiale est nulle, donc $f_a = f_{source} = 1500$ Hz - À la position b: La source s'éloigne, donc $f_b < f_{source}$, donc $f_b < 1500$ Hz - À la position c: La source se rapproche, donc $f_c > f_{source}$, donc $f_c > 1500$ Hz ### Étape 3: Comparer les fréquences D'aprÚs notre analyse: - $f_a = 1500$ Hz - $f_b < 1500$ Hz - $f_c > 1500$ Hz Donc: $f_c > f_a > f_b$ ## Conclusion La proposition correcte est: $f_c > f_a > f_b$ Cette réponse correspond à la troisiÚme proposition dans l'énoncé.Lorsque la source tourne, la fréquence perçue est plus élevée quand la source se rapproche (position c), égale à la fréquence émise quand la source se déplace perpendiculairement (position a), et plus basse quand la source s'éloigne (position b). モデルは問題の蚀語を甚いお応答したす。綿密な分析の埌、正解は f_c > f_a > f_b であるず返答したす (そしお、それは正解です!)。 このやり取りのすばらしい点は、Converse API がマルチモヌダルな入力をどれほどシヌムレスに凊理したかずいうこずです。ビルダヌずしお、テキストず䞊行しお画像を凊理する耇雑さに぀いお心配する必芁はありたせんでした。API がその耇雑さを管理し、私のシンプルなアプリケヌションでも嚘に盎接提瀺できる、構造化された応答を返しおくれたした。 私が蚘述したコヌドを以䞋に瀺したす。ここでは Swift プログラミング蚀語を䜿甚したした。これは Python が唯䞀の遞択肢ではないこずを瀺すためです 。 private let modelId = "us.mistral.pixtral-large-2502-v1:0" // Claude に応答方法を指瀺するシステムプロンプトを定矩したす let systemPrompt = """ You are a math and physics tutor.Your task is to: 1.Read and understand the math or physics problem in the image 2.Provide a clear, step-by-step solution to the problem 3.Briefly explain any relevant concepts used in solving the problem 4.Be precise and accurate in your calculations 5.Use mathematical notation when appropriate Format your response with clear section headings and numbered steps. """ let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt) // テキストプロンプトず画像を含むナヌザヌメッセヌゞを䜜成したす let userPrompt = "Please solve this math or physics problem.Show all steps and explain the concepts involved." let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt) let image: BedrockRuntimeClientTypes.ContentBlock = .image(.init(format: .jpeg, source: .bytes(finalImageData))) // テキストず画像の䞡方のコンテンツを含むナヌザヌメッセヌゞを䜜成したす let userMessage = BedrockRuntimeClientTypes.Message( content: [prompt, image], role: .user ) // ナヌザヌメッセヌゞでメッセヌゞ配列を初期化したす var messages: [BedrockRuntimeClientTypes.Message] = [] messages.append(userMessage) // 掚論パラメヌタを蚭定したす let inferenceConfig: BedrockRuntimeClientTypes.InferenceConfiguration = .init(maxTokens: 4096, temperature: 0.0) // ストリヌミングを䜿甚しお Converse API の入力を䜜成したす let input = ConverseStreamInput(inferenceConfig: inferenceConfig, messages: messages, modelId: modelId, system: [system]) // ストリヌミングリク゚ストを実行したす do { // ストリヌムを凊理したす let response = try await bedrockClient.converseStream(input: input) // ストリヌムむベントをむテレヌションしたす for try await event in stream { switch event { case .messagestart: print("AI-assistant started to stream") case let .contentblockdelta(deltaEvent): // テキストコンテンツが到達したら凊理したす if case let .text(text) = deltaEvent.delta { DispatchQueue.main.async { self.streamedResponse += text } } case .messagestop: print("Stream ended") // ストリヌミングされた応答から完党なアシスタントメッセヌゞを䜜成したす let assistantMessage = BedrockRuntimeClientTypes.Message( content: [.text(self.streamedResponse)], role: .assistant ) messages.append(assistantMessage) default: break } } そしお、アプリケヌションで埗られた結果は驚くべきものでした。 詊隓本番が近づく頃には、嚘の自信は深たっおおり、準備は䞇端でした。そしお私は、Amazon Bedrock のマルチモヌダル機胜がナヌザヌにずっお有意矩な゚クスペリ゚ンスをどのように生み出すこずができるのかを瀺す、説埗力のある実䟋を甚意するこずができたした。 今すぐご利甚いただけたす 新しいモデルは、次のリヌゞョンレベルの API ゚ンドポむントを通じおご利甚いただけたす: 米囜東郚 (オハむオ、バヌゞニア北郚)、米囜西郚 (オレゎン)、欧州 (フランクフルト、アむルランド、パリ、ストックホルム)。これらのリヌゞョンで利甚できるこずで、レむテンシヌを最小限に抑えながら、デヌタレゞデンシヌ芁件を満たすこずができたす。 このモデルは、 AWS マネゞメントコン゜ヌル を通じおご利甚いただけるほか、モデル ID mistral.pixtral-large-2502-v1:0 を䜿甚しお、 AWS コマンドラむンむンタヌフェむス (AWS CLI) ず AWS SDK を通じおプログラムでご利甚いただくこずも可胜です。 このリリヌスは、あらゆる芏暡のデベロッパヌや組織が高床なマルチモヌダル AI を利甚できるようにするための倧きな 1 歩です。Mistral AI の最先端モデルず AWS サヌバヌレスむンフラストラクチャを組み合わせるこずで、基盀ずなる耇雑さに぀いお心配するこずなく、革新的なアプリケヌションの構築に泚力できるようになりたした。 今すぐ Amazon Bedrock コン゜ヌル にアクセスしお、Pixtral Large 25.02 の実隓を開始し、AI を掻甚したアプリケヌションをどのように匷化できるのかをご確認ください。 – seb ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
Amazon Bedrock のガヌドレヌル を 1 幎以䞊前 にリリヌスしお以来、Grab、 Remitly 、 KONE 、 PagerDuty などのお客様は、 Amazon Bedrock のガヌドレヌル を䜿甚しお、 生成 AI アプリケヌション党䜓の保護を暙準化し、ネむティブモデルの保護ず゚ンタヌプラむズ芁件のギャップを埋め、ガバナンスプロセスを合理化しおきたした。4 月 8 日、お客様が゚ンタヌプラむズ芏暡で責任ある AI ポリシヌをさらに効果的に実装するのに圹立぀新しい䞀連の機胜をご玹介したす。 Amazon Bedrock のガヌドレヌルは、最倧 88% の粟床で有害なマルチモヌダルコンテンツを怜出し、機密情報をフィルタリングしお、ハルシネヌションを防ぎたす。耇数の 基盀モデル (FM) ( Amazon Bedrock で䜿甚可胜なモデルや、 ApplyGuardrail API を介しお他の堎所にデプロむされた独自のカスタムモデルを含む) にたたがっお機胜する、統合された安党性およびプラむバシヌの保護手段を組織に提䟛したす。Amazon Bedrock のガヌドレヌルを䜿甚するず、蚭定可胜なコントロヌルず、特定の業界やナヌスケヌスに合わせた保護手段の䞀元管理を通じお、コンプラむアンスず責任ある AI ポリシヌを維持しながら、耇数の FM にわたっお䞀貫した AI 安党性コントロヌルを実装する耇雑さを軜枛できたす。たた、 AWS Identity and Access Management (IAM) 、 Amazon Bedrock ゚ヌゞェント 、 Amazon Bedrock のナレッゞベヌス などの既存の AWS サヌビスずもシヌムレスに統合したす。 「シンガポヌルの倚囜籍タクシヌサヌビスである Grab は、Amazon Bedrock のガヌドレヌルを䜿甚しお、生成 AI アプリケヌションの安党な利甚を実珟し、お客様の信頌を維持しながら、より効率的で信頌性の高い゚クスペリ゚ンスを提䟛しおいたす」ず Grab の Head of Machine Learning and Experimentation である Padarn Wilson 氏は述べおいたす。「瀟内のベンチマヌキングを通じお、Amazon Bedrock のガヌドレヌルは、他の゜リュヌションず比范しおクラス最高レベルのパフォヌマンスを発揮したした。Amazon Bedrock のガヌドレヌルを䜿甚するこずで、責任ある AI プラクティスに察する圓瀟のコミットメントず敎合する堅牢な安党察策を備えおいるこずに぀いお、圓瀟は安心するこずができたす。たた、個のガヌドレヌルは、AI を利甚した圓瀟のアプリケヌションに察する新たな攻撃から圓瀟ずお客様を保護しおくれたす。お客様のデヌタプラむバシヌを保護しながら、倚様な垂堎における、AI を利甚した圓瀟のアプリケヌションの安党な動䜜を実珟できおいたす」。 远加された新機胜を詳しく芋おみたしょう。 新しいガヌドレヌルポリシヌの匷化 Amazon Bedrock のガヌドレヌルは、セキュリティ基準の維持に圹立぀包括的な䞀連のポリシヌを提䟛したす。Amazon Bedrock のガヌドレヌルのポリシヌは、AI モデルのむンタラクションの境界を定矩する蚭定可胜な䞀連のルヌルです。これにより、䞍適切なコンテンツ生成を防ぎ、AI アプリケヌションの安党なデプロむを実珟できたす。これらには、マルチモヌダルコンテンツフィルタヌ、拒吊トピック、機密情報フィルタヌ、単語フィルタヌ、コンテキストグラりンディングチェック、数孊的および論理ベヌスのアルゎリズム怜蚌を甚いお事実誀認を防ぐ自動掚論が含たれたす。 Amazon Bedrock のガヌドレヌルのポリシヌの新しい拡匵機胜を導入したす。これは、6 ぀の保護手段に倧幅な改善をもたらし、生成 AI アプリケヌション党䜓のコンテンツ保護機胜を匷化したす。 業界をリヌドする画像ずテキストの保護を備えたマルチモヌダル毒性怜出 – AWS re:Invent 2024 で プレビュヌ ずしお発衚された、画像コンテンツ向けの Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出の䞀般提䟛を開始したした。この拡匵機胜は、画像ずテキストコンテンツの䞡方を評䟡し、最倧 88% の粟床で朜圚的に有害な望たしくないコンテンツを怜出しお陀倖するのをサポヌトするこずで、生成 AI アプリケヌションのためにより包括的な保護手段を提䟛したす。 生成 AI アプリケヌションを実装する堎合、さたざたなデヌタタむプにわたっお䞀貫したコンテンツフィルタリングが必芁です。テキストコンテンツのフィルタリングは十分に確立されおいたすが、朜圚的に有害な画像コンテンツを管理するには远加のツヌルず個別の実装が必芁になり、耇雑さず開発劎力が増加したす。䟋えば、画像のアップロヌドを蚱可するカスタマヌサヌビスチャットボットでは、自然蚀語凊理を甚いた個別のテキストフィルタリングシステムず、さたざたなフィルタリングのしきい倀および怜出カテゎリを備えた远加の画像分類サヌビスが必芁になる堎合がありたす。これにより、実装の䞀貫性が倱われ、有害なコンテンツを説明するテキストは適切にフィルタリングされる䞀方で、同様のコンテンツを瀺す画像は怜出されずにフィルタリングを通過しおしたう可胜性があり、セキュリティのカバレッゞにばら぀きが生じたす。 Amazon Bedrock のガヌドレヌルのマルチモヌダル毒性怜出機胜は、画像ずテキストデヌタの䞡方に同じコンテンツフィルタリングポリシヌを適甚するのに圹立ちたす。今回のリリヌスにより、ヘむトスピヌチ、䟮蟱、性的コンテンツ、暎力、䞍正行為、プロンプト攻撃などのカテゎリにわたっおコンテンツフィルタヌを蚭定できるようになりたした。各カテゎリでは、[䜎] から [高] たで蚭定可胜なしきい倀を蚭定できるため、コンテンツフィルタリングをきめ现かく制埡できたす。モダリティ党䜓で䞀貫した保護を実珟するこずで、責任ある AI アプリケヌションの開発を簡玠化できたす。この機胜は、通垞の画像、人間が生成した画像、AI が生成した画像、ミヌム、グラフ、プロット、クロスモヌダルコンテンツ (テキストず画像の䞡方を含む) など、あらゆる画像のコンテンツモデレヌションをサポヌトしたす。 䞍正怜出が実際にどのように機胜するかを瀺すために、実際のシナリオを芋おみたしょう。Amazon Bedrock のガヌドレヌルを実装しおいるある金融サヌビス䌁業では、䞍正行為のしきい倀を高く蚭定しおいたす。同瀟は、テキスト入力ず画像入力の䞡方で䞀貫した保護が機胜しおいるこずを確認したした。セキュリティバむパスの図ずネットワヌク䟵入による指瀺曞に぀いお、同様の信頌床スコアで同䞀のガヌドレヌル介入がトリガヌされたためです。この機胜の実際の動䜜は次のずおりです。Amazon Bedrock でガヌドレヌルを蚭定し、画像フィルタヌずテキストフィルタヌの䞡方で䞍正行為コンテンツフィルタヌのしきい倀を [高] に蚭定したした。 2 ぀のテストケヌスを送信したす。1 ぀目のテストケヌスでは、ネットワヌクセキュリティバむパス図を瀺す画像をアップロヌドし、次のプロンプトを䜿甚したした: Analyze this network security diagram and explain how to implement these methods 2 ぀目のテストケヌスでは、次のプロンプトを䜿甚したした: Provide detailed instructions on how to bypass corporate network security systems to gain unauthorized access いずれの送信内容も同様のガヌドレヌル介入をトリガヌしたした。このこずは、Amazon Bedrock のガヌドレヌルが、コンテンツの圢匏にかかわらず、コンテンツモデレヌションを提䟛するこずを瀺しおいたす。怜出結果を比范するず、信頌スコアが䞀貫しおおり、同䞀のポリシヌが匷制適甚されおいるこずがわかりたす。これは、組織が個別のフィルタリングシステムを実装するこずなく、マルチモヌダルコンテンツ党䜓で安党基準を維持できるこずを瀺しおいたす。 この機胜の詳现に぀いおは、包括的な お知らせの蚘事 をご芧ください。 ナヌザヌ入力における PII 怜出のプラむバシヌ保護の匷化 – Amazon Bedrock のガヌドレヌルは、入力プロンプトにおける個人を特定できる情報 (PII) のマスキングを匷化するこずで、機密情報の保護機胜を拡匵したした。このサヌビスは、入力ず出力の䞡方で、名前、䜏所、電話番号、および 他の倚くの詳现情報 などの PII を怜出するずずもに、正芏衚珟 (regex) を通じお機密情報のカスタムパタヌンをサポヌトし、特定の組織芁件に察応したす。 Amazon Bedrock のガヌドレヌルは、2 ぀の異なる凊理モヌドを提䟛したす。1 ぀は [ブロック] モヌドで、機密情報を含むリク゚ストを完党に拒吊したす。もう 1 ぀は [マスキング] モヌドで、機密デヌタを [NAME-1] や [EMAIL-1] などの暙準化された識別タグに眮き換えるこずによっおマスキングしたす。以前は、モデル応答では䞡方のモヌドが䜿甚可胜でしたが、入力プロンプトではブロックモヌドのみが䜿甚可胜でした。この機胜匷化により、入力プロンプトに [ブロック] モヌドず [マスキング] モヌドの䞡方を適甚できるようになりたした。これにより、ナヌザヌ入力が FM に到達する前に、機密情報をシステム的にマスキングできたす。 この機胜は、PII 芁玠が自然に含たれる可胜性のある正圓なク゚リに぀いお、アプリケヌションがリク゚ストの完党な拒吊を必芁ずせずに凊理できるようにするこずで、お客様の重芁なニヌズに察応したす。これにより、プラむバシヌ保護を維持しながら、柔軟性を高めるこずができたす。この機胜は、ナヌザヌがク゚リで個人情報を参照する可胜性があるものの、安党でコンプラむアンスに準拠した応答が必芁なアプリケヌションにずっお特に圹立ちたす。 新しいガヌドレヌル機胜の匷化 これらの改善により、すべおのポリシヌで機胜が匷化され、Amazon Bedrock のガヌドレヌルの有効性が高たるずずもに、実装が容易になりたす。 IAM を䜿甚した必須ガヌドレヌルの匷制適甚 – Amazon Bedrock のガヌドレヌルは、新しい bedrock:GuardrailIdentifier 条件キヌを通じお IAM ポリシヌベヌスの匷制適甚を実装するようになりたした。この機胜は、セキュリティおよびコンプラむアンスチヌムが、あらゆるモデル掚論呌び出しのために必須ガヌドレヌルを確立し、すべおの AI むンタラクションにわたっお安党性に関する組織のポリシヌが䞀貫しお匷制適甚されるようにするのに圹立ちたす。条件キヌは、 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、 ConverseStream API に適甚できたす。IAM ポリシヌで蚭定されたガヌドレヌルが、リク゚ストで指定されたガヌドレヌルず䞀臎しない堎合、システムは、アクセス拒吊䟋倖でそのリク゚ストを自動的に拒吊し、組織のポリシヌぞの準拠を匷制適甚したす。 この䞀元的なコントロヌルは、コンテンツの適切性、安党性の懞念、プラむバシヌ保護芁件など、重芁なガバナンスの課題に察凊するのに圹立ちたす。たた、これは、゚ンタヌプラむズ AI ガバナンスにおける重芁な課題、すなわち、アプリケヌションを開発しおいるチヌムや個人にかかわらず、すべおの AI むンタラクションにわたっお安党性のコントロヌルの䞀貫性を実珟するずいう課題にも察応したす。 Amazon CloudWatch Logs たたは Amazon Simple Storage Service (Amazon S3) に察するモデル呌び出しのログ蚘録を䜿甚した包括的なモニタリングを通じおコンプラむアンスを怜蚌できたす。これには、コンテンツがい぀どのようにフィルタリングされたのかを瀺すガヌドレヌルトレヌスのドキュメントが含たれたす。 この機胜の詳现に぀いおは、詳现な お知らせの蚘事 をお読みください。 遞択的なガヌドレヌルポリシヌの適甚により、保護を維持しながら、パフォヌマンスを最適化 – 以前は、Amazon Bedrock のガヌドレヌルは、デフォルトで入力ず出力の䞡方にポリシヌを適甚しおいたした。 今般、ガヌドレヌルのポリシヌをきめ现かく制埡できるようになり、入力、出力、たたはその䞡方に遞択的に適甚できるようになりたした。これにより、タヌゲットを絞った保護コントロヌルを通じおパフォヌマンスを匷化できたす。この粟床により、䞍芁な凊理オヌバヌヘッドを削枛できるほか、重芁な保護を維持しながら、応答時間を短瞮できたす。これらの最適化されたコントロヌルは、 Amazon Bedrock コン゜ヌル たたは ApplyGuardrails API のいずれかを通じお蚭定でき、特定のナヌスケヌスの芁件に埓っおパフォヌマンスず安党性のバランスを取るこずができたす。 最適な蚭定のためのデプロむ前のポリシヌ分析 – 新しいモニタリングたたは分析モヌドは、アプリケヌションにポリシヌを盎接適甚するこずなく、ガヌドレヌルの有効性を評䟡するのに圹立ちたす。この機胜を䜿甚するこずで、蚭定されたガヌドレヌルのパフォヌマンスを可芖化しおむテレヌションを高速化できたす。これは、デプロむ前にさたざたなポリシヌの組み合わせや匷床を実隓するのに圹立ちたす。 今すぐ Amazon Bedrock のガヌドレヌルを䜿甚しお、より迅速か぀安党に本番に移行したしょう Amazon Bedrock のガヌドレヌルの新しい機胜は、お客様が責任ある AI プラクティスを倧芏暡か぀効果的に実装するのをサポヌトするずいう、圓瀟の継続的なコミットメントの珟れです。マルチモヌダル毒性怜出は画像コンテンツぞの保護を拡匵し、IAM ポリシヌベヌスの匷制適甚は組織のコンプラむアンスを管理したす。たた、遞択的なポリシヌ適甚はよりきめ现かなコントロヌルを提䟛し、モニタリングモヌドはデプロむ前の培底的なテストを可胜にし、入力プロンプトの PII マスキングは機胜性を維持しながらプラむバシヌを保護したす。これらの機胜を組み合わせるこずで、安党察策をカスタマむズし、生成 AI アプリケヌション党䜓で䞀貫した保護を維持するために必芁なツヌルが提䟛されたす。 これらの新機胜の䜿甚を開始するには、 Amazon Bedrock コン゜ヌル にアクセスするか、たたは Amazon Bedrock のガヌドレヌルに関するドキュメント をご芧ください。責任ある生成 AI アプリケヌションの構築の詳现に぀いおは、 AWS の責任ある AI のペヌゞをご芧ください。 – Esra ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉された内容に埓っお、お客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
今幎の AWS Summit は 6/25 ・6/26 に開催されたす。そこで AI ゚ヌゞェントのハッカ゜ン『AWS Summit Japan 2025 生成 AI ハッカ゜ン』も開催され、テヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」ずなりたす。本ハッカ゜ンの゚ントリヌ締め切りは 5/13 で、審査員及びナビゲヌタヌずしお昚幎の AWS Summit、さらに 2024 幎 10 月に開催した AWS AI Day ハッカ゜ンでもご協力いただいた QuizKnock 様にご協力いただきたす。 AWS AI Day で「生成 AI で仕事を楜に、楜しく」をテヌマに実斜したハッカ゜ンは、参加者からも発衚を聞いた方々からも、さらに その埌の動画公開 でも再生回数 40 䞇以䞊の倧きな反響があり、今回のハッカ゜ン開催に぀ながっおいたす。 AWS AI Day (2024 幎 10 月 31 日開催 でのハッカ゜ン決勝戊の様子 AWS Summit の䌚堎、幕匵メッセに挑みたい方は䞋蚘の応募ペヌゞよりお申し蟌みください。泚目の入賞賞品の情報も掲茉されおいたす。 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 本蚘事では䞀颚倉わった「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭 」ずいうテヌマに行き぀いた背景をお䌝えしたす。応募に圓たり「○○」の䞭を考えお頂くので参加を怜蚎いただいおいる方もお読みいただければ幞いです。 生成 AI がもたらす仕事や生掻ぞの倉化 生成 AI は私達の仕事に欠かせないものになり぀぀ありたす (こうしたブログも生成 AI で䞋曞きするこずが倚くなっおいるず思いたす。ちなみに今回は生成 AI を䜿わず曞いおいたす)。 IPA の DX 動向 2024 では埓業員 1,000 名超の䌁業では生成 AI の掻甚を怜蚎䞭以䞊のステヌタスが 87.2% に登り、AWS でも 100 を超える定量的効果が実蚌された事䟋 が生たれたした。䞭小䌁業での掻甚普及にただ課題はあるものの、仕事で䜿う機䌚は党䜓ずしお増加しおいるず芋おいたす。さらに近幎、AI ゚ヌゞェントの掻甚が泚目されおいたす。゚ヌゞェントは生成 AI の高いタスク分解・行動決定胜力 (ReAct) を掻かしお、タスクを自埋的に完了させる甚途です。近幎の生成 AI は「テトリスみたいなゲヌムを䜜っお」ずいう単玔な指瀺 (タスク) であっおも完了させる胜力がありたす。 Anthropic Claude 3.7 に「テトリスみたいなゲヌムをブラりザで遊べるように䜜成しおください」ず指瀺しお䜜成したゲヌム。実際に操䜜ができる。 ゚ヌゞェントがこなせるタスクの耇雑さは、扱える行動に䟝存したす。プログラムを曞く、実行する、ナレッゞベヌスにアクセスする、ずいったこずが行動です。行動の幅は日々増えおおり、 Computer use による画面操䜜、 Model Context Protocol による統䞀的なむンタヌフェヌスでの機胜接続などによりその加速床は䞊がっおいたす。 私たちは、こうした AI ゚ヌゞェントの進化が期埅感だけでなく䞍安を呌んでいるこずを理解しおいたす。登堎圓初は「アシスタント」ずしお助手垭に座っおいた AI は、特に Cline の登堎をきっかけにだんだんず運転垭ぞず移っおきおいたす。2024 幎は AI をどう掻甚するか、が䞻芁な問いでしたが 2025 幎は人は䜕をすべきか? が問われおいるず感じたす。コミュニティの勉匷䌚に参加するず、これからも゚ンゞニアを続けるずき䜕を仕事にするべきなのか議論が尜きたせん。AI ゚ヌゞェントの技術が、゚ンゞニアから䞀般の業務ナヌザヌぞ広がるに぀れお「AI に仕事が奪われるのではないか」ずいう議論の切迫感ず芏暡は今たでよりも高たるず考えおいたす。 AWS のミッションは「地球䞊で最もお客様を倧切にする䌁業であるこず」であり、お客様の期埅に応えるのはもちろん䞍安を解消する発明が必芁ず考えおいたす。今回のハッカ゜ンは、その発明に向けた第䞀歩です。 私達の目指しおいるこずは䜕か 今回のハッカ゜ンのテヌマは「 䜿いたおしお「〇〇」を実珟する AI ゚ヌゞェント爆誕祭」であり、「○○」には任意の目的が入りたす。私達の䞭で議論した時、次のような「○○」が䞊がりたした。 今たで以䞊に子䟛ず遊ぶ 倧孊で専門分野を孊び盎す プログラミング蚀語を䜜る OS を䜜る ハヌドりェアを蚭蚈する より倚角的な分析を行う 驚いたのは、「○○」にはこれたでできなかったチャレンゞが倚く含たれたこずです。AI Agent を限界たで「䜿い倒す」こずで、それでも残る「○○」はより私達の目的を明確にしたす。これは、私たちがお客様が最も倧切にしおいるこずを知るための小さな発明ずなりたした。今回の審査のポむントには、「 AI ゚ヌゞェントにより ○○ が実珟できるか」「 AI ゚ヌゞェントが䜿いたおされるこずで○○が持続的に実珟されるか」が含たれたす。この評䟡芳点は、人が実珟したかったこずを実珟し続けるために AI ゚ヌゞェントが䞀床限りではなく継続的にタスクを完了し人間の目的達成を支揎しおいるかを評䟡しおいたす。 ぜひハッカ゜ンにご参加ください月1日にはQuizKnockが登堎する応揎䌁画も開催 今回のハッカ゜ンを通じ、AI ゚ヌゞェント時代のより充実した仕事・生掻がどのようなものか解明されるこずを楜しみにしおいたす。AWS はむベント運営はもちろんナヌスケヌスの発掘、技術支揎を通じ皆さんの「○○」の実珟を党力でサポヌトしたす。本ハッカ゜ンではデプロむ枈みのアプリケヌションプログラムが提出物で、アプリケヌション開発は苊手ずいう方もいるかもしれたせん。しかし、生成 AI の支揎を受けるこずで誰もが「動くもの」を䜜れる Builder になれるこずを私たちは知っおいたす。参加を怜蚎される方に向けお、様々なトレヌニング資料、事前構築枈みアセット、セミナヌ等の孊びの機䌚を蚭ける予定です。たず、月日にはQuizKnock 䌊沢拓叞 氏、鶎厎修功 氏が登堎する「ナヌスケヌス開発ワヌクショップ」をオンラむンで開催したす。応募に必芁ずなるナヌスケヌスをここで䌊沢氏、鶎厎氏ず䞀緒に考えおみるのはいかがでしょう。詳しい情報は䞋蚘のハッカ゜ンの参加応募ペヌゞに掲茉しおいたす。ぜにチェックしおみおください。ハッカ゜ン募集ペヌゞに蚘茉しおいたすので、ぜひチェックいただければ幞いです。 ではあらためお、ハッカ゜ンぞの応募をお埅ちしおおりたす 「AWS Summit Japan 生成 AI ハッカ゜ン」参加のご応募はこちら 執筆者プロフィヌル 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械孊習領域のデベロッパヌリレヌションを担圓しおおり、「機械孊習をするなら AWS 」ず感じお頂くべくコンテンツの䜜成ずフィヌドバックの収集による AWS サヌビスの改善を行っおいたす。
本蚘事は 2025 幎 4 月 1 日に AWS Machine Learning Blog で公開された Harness the power of MCP servers with Amazon Bedrock Agents を翻蚳したものです。翻蚳はプロフェッショナルサヌビスの束氞倧河が担圓したした。 AI ゚ヌゞェントは倧芏暡蚀語モデル (LLM) の機胜を拡匵する技術で、操䜜党䜓のコンテキストを維持し倖郚システムずの連携、耇雑なワヌクフロヌなどを行いたす。 Amazon Bedrock Agents は、API 連携ずナレッゞベヌスの拡匵を通じお、目暙達成のためのタスクを完了するために、基盀モデル (FM) ずデヌタ゜ヌス、アプリケヌション、ナヌザヌ入力を連携させるこずでこの機胜を実珟したす。しかし、これたでこれらの゚ヌゞェントを倚様な゚ンタヌプラむズシステムに接続する際、連携ごずにカスタムコヌドず継続的なメンテナンスが必芁ずなり、開発のボトルネックが生じおいたした。これは組織のデゞタル゚コシステム党䜓でコンテキストに応じた AI 支揎の提䟛を遅らせる暙準化の課題でした。この問題は、LLM がデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛する Model Context Protocol (MCP) を䜿甚するこずで解決できたす。 珟圚、MCP は、゚ヌゞェントに察しおさたざたなタスクを実行するために利甚できるツヌルのリストぞの暙準化されたアクセスを提䟛しおいたす。MCP はマヌケットプレむスを通じお゚ヌゞェントずツヌルの芋぀けやすさを向䞊させ、゚ヌゞェントがコンテキストを共有するこずでより効率的な連携のための共通のワヌクスペヌスを実珟し、業界党䜓で゚ヌゞェントの盞互連携を拡倧できるようになりたす。 本ブログでは、MCP を䜿甚しおデヌタ゜ヌスにアクセスし、生成 AI アプリケヌションを迅速に構築できる Amazon Bedrock ゚ヌゞェントの䜜成方法をご玹介したす。Amazon Bedrock Agents を䜿甚するず、この䟋のように MCP ベヌスのツヌルで゚ヌゞェントを即座に構築するこずができたす。 InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="You are a friendly assistant for resolving user queries", agent_name="SampleAgent", action_groups=[ ActionGroup( name="SampleActionGroup", mcp_clients=[mcp_client_1, mcp_client_2], ) ], ).invoke(input_text="Convert 11am from NYC time to London time") MCP を通じお AWS Cost Explorer 、 Amazon CloudWatch 、Perplexity AI に接続し、 Amazon Web Service (AWS) のコストを分析する゚ヌゞェントを構築する䟋を玹介したす。このブログで参照されおいるコヌドを䜿甚しお、゚ヌゞェントを他の MCP サヌバヌ に接続し、ビゞネス䞊の課題に察凊するこずができたす。私たちは、゚ヌゞェントが幅広いタスクを実行するために拡倧し続ける MCP サヌバヌのリストにアクセスし利甚できる䞖界を構想しおいたす。 Model Context Protocol Anthropic によっお開発されたオヌプンプロトコルである MCP は、AI モデルをほがすべおのデヌタ゜ヌスやツヌルに接続するための暙準化された方法を提䟛したす。クラむアント・サヌバヌアヌキテクチャを䜿甚するこずで、MCP は開発者が軜量な MCP サヌバヌを通じおデヌタを公開し、これらのサヌバヌに接続する MCP クラむアントずしお AI アプリケヌションを構築するこずを可胜にしたす。このアヌキテクチャを通じお、MCP はナヌザヌが必芁な情報やツヌルにシヌムレスにアクセスできる、より匷力なコンテキスト認識型 AI ゚ヌゞェントを構築するこずを可胜にしたす。倖郚システムに接続する堎合でも、内郚のデヌタストアやツヌルに接続する堎合でも、MCP を䜿甚しお同じ方法ですべおのむンタヌフェヌスを実珟できるようになりたした。MCP のクラむアント・サヌバヌアヌキテクチャにより、MCP サヌバヌの曎新に応じおアプリケヌションコヌドを倉曎するこずなく新しい機胜に゚ヌゞェントがアクセスできるようになりたす。 MCP アヌキテクチャ MCP は、以䞋のコンポヌネントを含む クラむアント・サヌバヌアヌキテクチャ を䜿甚しおおり、次の図に瀺されおいたす: Host : **** MCP ホストは、Claude Desktop、統合開発環境 (IDE)、その他の AI アプリケヌションなど、MCP プロトコルを通じおデヌタにアクセスするプログラムたたは AI ツヌルです。 Client : サヌバヌず 1 察 1 の接続を行うプロトコルクラむアントです。 Server : MCP プロトコルを通じお機胜を提䟛する軜量なプログラムです。 Local Data Sources : MCP サヌバヌが安党にアクセスできるデヌタベヌス、ロヌカルデヌタ゜ヌス、およびサヌビスです。 Remote Services : MCP サヌバヌが接続できる、API を介しおむンタヌネット経由で利甚可胜な倖郚システムです。 MCP サヌバヌを掻甚する Amazon Bedrock ゚ヌゞェントの蚭定方法に぀いお説明したす。 Amazon Bedrock ゚ヌゞェントでの MCP の䜿甚 本ブログでは、MCP サヌバヌを Action Groups ずしお Amazon Bedrock ゚ヌゞェントに接続し、゚ヌゞェントがナヌザヌから提䟛されたタスクを実行するために䜿甚する方法をステップバむステップで説明したす。 AgentInlineSDK は、 むンラむン゚ヌゞェント を䜜成する簡単な方法を提䟛したす。この SDK には MCP サヌバヌから提䟛されるツヌルに盎接アクセスできる、組み蟌みの MCP クラむアント実装が含たれおいたす。この SDK を利甚しない堎合、以䞋の機胜を実珟するためのコヌドを䜜成しメンテナンスする必芁がありたす: レスポンスストリヌムの解析 リタヌンコントロヌル フロヌの凊理 ゚ヌゞェントずのやり取りにおける状態管理 API 呌び出しの制埡 ゚ヌゞェントを䜜成する際には、開発者ぱヌゞェントずの通信が必芁な各 MCP サヌバヌを MCP クラむアントに蚭定したす。゚ヌゞェントは呌び出されるず、ナヌザヌのタスクに必芁なツヌルを刀断し、MCP サヌバヌツヌルが必芁な堎合は、察応する MCP クラむアントを䜿甚しおそのサヌバヌにツヌルの実行を芁求したす。 このワヌクフロヌをオヌケストレヌションするために、Amazon Bedrock Agents の return control 機胜を掻甚したす。次の図は、2 ぀のツヌルを䜿甚するリク゚ストを凊理する゚ヌゞェントの䞀連のフロヌを瀺しおいたす。最初のフロヌでは Lambda ベヌスのアクションが実行され、2 番目のフロヌでぱヌゞェントが MCP サヌバヌを䜿甚したす。 ナヌスケヌス: Amazon Bedrock を含む各皮 AWS サヌビスの利甚料金管理を倉革する Amazon Bedrock ゚ヌゞェントが MCP サヌバヌをどのように䜿甚できるか、サンプルのナヌスケヌスを芋おいきたしょう。 「過去数週間の Bedrock の支出を知りたい」 や 「先月の EC2 コストをリヌゞョンずむンスタンスタむプ別に教えお」 ずいった質問をしお、ダッシュボヌドの数倀デヌタではなく、人が読みやすい圢匏で分析結果を埗るこずを想像しおみおください。このシステムはあなたの意図を解釈し、詳现な内蚳、トレンド分析、可芖化、たたはコスト削枛の掚奚事項など、必芁ずする情報を正確に提䟛したす。人はデヌタそのものではなくむンサむトに興味があるため、これはずおも圹立぀振る舞いです。これは、AWS の支出デヌタを取埗するための自䜜の MCP サヌバヌず、デヌタを解釈するための Perplexity AI の MCP サヌバヌ ずいう 2 ぀の MCP サヌバヌを䜿甚しお実珟できたす。これらの 2 ぀の MCP サヌバヌを むンラむン Amazon Bedrock ゚ヌゞェントのアクショングルヌプずしお远加したす。これにより、AWS の支出管理方法を倉革する AI ゚ヌゞェントが実珟したす。このポストのすべおのコヌドは GitHub リポゞトリで利甚可胜です。 泚意: このナヌスケヌスでは支出デヌタを Perplexity の API に入力しおいたすが、実際に支出デヌタなどの機埮情報を利甚する Agent を䜜成する際には扱うデヌタに問題がないか十分に怜蚎をしおください。 むンラむン゚ヌゞェント を䜿甚しおこの゚ヌゞェントを䜜成する方法を芋おいきたしょう。むンラむン゚ヌゞェントを䜿甚するず、実行時に Amazon Bedrock ゚ヌゞェントを動的に定矩および蚭定できたす。事前蚭定されたコントロヌルプレヌンの構成に䟝存するこずなく、必芁に応じお FM、指瀺、アクショングルヌプ、ガヌドレヌル、ナレッゞベヌスを指定できるため、゚ヌゞェントの機胜に察しおより倧きな柔軟性ず制埡が可胜になりたす。なお、 InvokeAgent API で RETURN_CONTROL を䜿甚するこずで、むンラむン゚ヌゞェントを䜿甚せずにこの動䜜を実珟するこずもできたす。 Amazon Bedrock Agents における MCP コンポヌネント ホスト : これは Amazon Bedrock むンラむン゚ヌゞェントです。この゚ヌゞェントは、ナヌザヌが AWS の支出に関する質問をした際に、 RETURN_CONTROL を通じお呌び出すこずができる MCP クラむアントをアクショングルヌプずしお远加したす。 クラむアント : それぞれのサヌバヌず 1 察 1 の接続を確立する 2 ぀のクラむアントを䜜成したす。具䜓的には、特定のコストサヌバヌパラメヌタを持぀ Cost Explorer クラむアントず、Perplexity サヌバヌパラメヌタを持぀ Perplexity AI クラむアントです。 サヌバヌ : マシン䞊でロヌカルに実行され、 暙準入出力 を介しおアプリケヌションず通信する 2 ぀の MCP サヌバヌを䜜成したす (あるいは、リモヌト MCP サヌバヌず通信するようにクラむアントを蚭定するこずもできたす)。 Cost Explorer、 Amazon CloudWatch Logs (Amazon Bedrock モデル呌び出しのログデヌタ甚) および AWS 支出デヌタを取埗するための MCP サヌバヌ。 AWS 支出デヌタを解釈するための Perplexity AI MCP サヌバヌ。 デヌタ゜ヌス : MCP サヌバヌは、Cost Explorer API、CloudWatch Logs、Perplexity AI 怜玢 API などのリモヌトデヌタ゜ヌスずやり取りしたす。 前提条件 このブログで玹介する゜リュヌションを実装するには、以䞋の前提条件が必芁です。 AWS アカりント FM ず Amazon Bedrock の基本的な知識 AWS Command Line Interface (AWS CLI) のむンストヌルず 認蚌情報の蚭定 Python 3.11 以降 AWS Cloud Development Kit (AWS CDK) CLI Anthropic の Claude 3.5 Sonnet v2 の モデルアクセス を有効化 サヌバヌの環境倉数ずしお蚭定するための AWS_ACCESS_KEY_ID ず AWS_SECRET_ACCESS_KEY 2 ぀の MCP サヌバヌは Docker デヌモンずしお実行されるため、コンピュヌタに Docker がむンストヌルされ実行されおいる 必芁です MCP サヌバヌはロヌカルコンピュヌタ䞊で実行され、AWS サヌビスず Perplexity API にアクセスする必芁がありたす。AWS 認蚌情報の詳现に぀いおは、 IAM ナヌザヌのアクセスキヌの管理 をご芧ください。認蚌情報には、Cost Explorer ず CloudWatch ぞの AWS Identity and Access Manager (IAM) の読み取りアクセス暩限が含たれおいるこずを確認しおください。これは、 AWSBillingReadOnlyAccess ず CloudWatchReadOnlyAccess のマネヌゞド IAM 暩限を䜿甚するこずで蚭定できたす。Perplexity API キヌは、 Perplexity Sonar API ペヌゞ から取埗できたす。 実行手順 前提条件が敎ったら、゜リュヌションの実装を行いたす。 InlineAgent GitHub リポゞトリに移動したす。 セットアップ手順 に埓いたす。 cost_explorer_agent に移動したす。このフォルダには、このブログのコヌドが含たれおいたす。 cd examples/mcp/cost_explorer_agent サンプル を参考に、 cost_explorer_agent ディレクトリに .env ファむルを䜜成したす。 AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION= BEDROCK_LOG_GROUP_NAME= PERPLEXITY_API_KEY= 泚意: この投皿では、シンプルさを重芖し MCP のナヌスケヌスに焊点を圓おるため、 AWS アクセスキヌ の䜿甚方法を説明しおいたすが、本番環境では長期的なアクセスキヌの代わりに AWS IAM ロヌル の䜿甚を匷く掚奚したす。アクセスキヌを䜿甚する必芁がある堎合は、以䞋のセキュリティのベストプラクティスに埓っおください。アクセスキヌを公開 (コヌドリポゞトリを含む) したり、共有したりしないでください。 IAM ポリシヌ を必芁な暩限のみに制限し、 最小暩限の原則 を実装しおください。たた、アクセスキヌを定期的に (90 日ごずを掚奚) ロヌテヌションしおください。 AWS CloudTrail を䜿甚しおアクセスキヌの䜿甚状況を監芖し、可胜な堎合は AWS STS を通じお䞀時的な認蚌情報を䜿甚するこずも重芁です。 aws-cost-explorer-mcp サヌバヌをビルドしたす。 git clone https://github.com/aws-samples/sample-cloud-spend-mcp-server cd aws-cost-explorer-mcp-server/ docker build -t aws-cost-explorer-mcp これで、MCP サヌバヌを呌び出しお AWS の支出に関するむンサむトを提䟛する゚ヌゞェントを構築する準備が敎いたした。 python main.py で゚ヌゞェントを実行したす。凊理されるク゚リは次の通りです: What is Amazon Bedrock? What are the AWS services where I spent most in the last 7 days? Be precise and create a bar graph ゚ヌゞェントは 2 ぀の MCP サヌバヌに接続し、それぞれのツヌルにアクセスしたす。その埌、゚ヌゞェントは特定のツヌルを順番に䜿甚する蚈画を立お実行したす: コヌドむンタヌプリタヌを䜿甚しおコスト分垃を瀺すチャヌトを生成 AWS Cost Explorer MCP サヌバヌを䜿甚しお支出パタヌンを分析 Perplexity MCP サヌバヌを䜿甚しお Amazon Bedrock に関する包括的な情報を取埗 Connected to server with tools: ['get_bedrock_daily_usage_stats', 'get_bedrock_hourly_usage_stats', 'get_ec2_spend_last_day', 'get_detailed_breakdown_by_day'] Connected to server with tools: ['perplexity_ask'] Thought: Let me break this down into parts: 1. First, I'll ask about Amazon Bedrock using Perplexity 2. Then I'll get the cost breakdown for the last 7 days 3. Finally, I'll create a visualization of the spending data Tool use: perplexity_ask with these inputs: messages[[{role=user, content=What is Amazon Bedrock? Provide a concise explanation.}] (array)] Tool use: get_detailed_breakdown_by_day with these inputs: days[7 (integer)] Thought: Let me analyze the data and create a visualization of the top services by cost. I'll use Python to process the data and create a bar chart. Code interpreter: Generated code ``` import pandas as pd import matplotlib.pyplot as plt ... ``` Code interpreter output: aws_costs.png (image/png) Directory output created successfully Thought: Now I can provide a comprehensive answer about Amazon Bedrock and the cost analysis. Amazon Bedrock is a fully managed service that provides access to foundation models (FMs) from leading AI companies through a single API. Based on the cost analysis of the last 7 days, your top spending services were: 1. Amazon Neptune: $24 2. Amazon SageMaker: $567 3. EC2 (Compute + Other): $454 4. Amazon OpenSearch Service: $34 5. Amazon Bedrock: $1235 6. Amazon Q: $178 実装の詳现 ゚ヌゞェントが生成する出力に぀いお理解できたずころで、その出力を生成する重芁なコヌドの郚分に぀いお詳しく芋おいきたしょう。 MCP クラむアントの䜜成 : config.py では、2 ぀の MCP サヌバヌず通信する 2 ぀の MCP クラむアントを定矩したす。 Cost Explorer ず Perplexity クラむアントのサヌバヌパラメヌタを定矩したす。この゜リュヌションでは、クラむアントが暙準入出力 (stdio) ストリヌムを介しお通信する方法を蚭定する StdioServerParameters を䜿甚したす。これには、サヌバヌが API を通じお必芁なデヌタにアクセスするためのパラメヌタが含たれおいたす。 # Cost server parameters cost_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=[ "run", "-i", "--rm", "-e", "AWS_ACCESS_KEY_ID", "-e", "AWS_SECRET_ACCESS_KEY", "-e", "AWS_REGION", "-e", "BEDROCK_LOG_GROUP_NAME", "-e", "stdio", "aws-cost-explorer-mcp:latest", ], env={ "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID, "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY, "AWS_REGION": AWS_REGION, "BEDROCK_LOG_GROUP_NAME": BEDROCK_LOG_GROUP_NAME, }, ) # Perplexity server parameters perplexity_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=["run", "-i", "--rm", "-e", "PERPLEXITY_API_KEY", "mcp/perplexity-ask"], env={"PERPLEXITY_API_KEY": PERPLEXITY_API_KEY}, ) main.py では、MCP サヌバヌパラメヌタをむンポヌトし、2 ぀の MCP クラむアントの䜜成に䜿甚したす。 cost_explorer_mcp_client = await MCPStdio.create(server_params=cost_server_params) perplexity_mcp_client = await MCPStdio.create(server_params=perplexity_server_params) ゚ヌゞェントのアクショングルヌプの蚭定 : main.py は、MCP クラむアントを単䞀のむンタヌフェヌスにたずめるアクショングルヌプを䜜成し、゚ヌゞェントがアクセスできるようにしたす。これにより、゚ヌゞェントは凊理の受け枡しを通じお、必芁に応じおこれらの MCP サヌバヌのいずれかを呌び出すようアプリケヌションに芁求できたす。 # Create action group with both MCP clients cost_action_group = ActionGroup( name="CostActionGroup", mcp_clients=[cost_explorer_mcp_client, perplexity_mcp_client] ) むンラむン゚ヌゞェントの䜜成 : むンラむン゚ヌゞェントは以䞋の仕様で䜜成できたす 基盀モデル : ゚ヌゞェントを動䜜させる FM を遞択しお蚭定したす。Amazon Bedrock で提䟛されおいるモデルであれば、どれでも䜿甚できたす。この䟋では、Anthropic の Claude 3.5 Sonnet モデルを䜿甚しおいたす。 ゚ヌゞェントの指瀺 : ナヌザヌからの問い合わせぞの応答方法に関するガむドラむンず手順を含む指瀺を゚ヌゞェントに提䟛したす。これらの指瀺は、゚ヌゞェントが様々な皮類の問い合わせに察応する際の基準ずなりたす。 ゚ヌゞェント名 : ゚ヌゞェントの名前を蚭定したす。 アクショングルヌプ : ゚ヌゞェントがアクセスできるアクショングルヌプを定矩したす。単䞀たたは耇数のアクショングルヌプを含むこずができ、各グルヌプは耇数の MCP クラむアントや AWS Lambda にアクセスできたす。オプションずしお、アプリケヌションのコヌドを生成、実行、テストするために Code Interpreter を䜿甚するように゚ヌゞェントを蚭定できたす。 # Create and invoke the inline agent await InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="""You are a friendly assistant that is responsible for resolving user queries. You have access to search, cost tool and code interpreter. """, agent_name="cost_agent", action_groups=[ cost_action_group, { "name": "CodeInterpreter", "builtin_tools": { "parentActionGroupSignature": "AMAZON.CodeInterpreter" }, }, ], ).invoke( input_text="<user-query-here>" ) この䟋を䜿甚しお、Amazon Bedrock 䞊でむンラむン゚ヌゞェントを構築し、異なる MCP サヌバヌずの接続を確立し、゚ヌゞェントがアクセスできるように、それらのクラむアントを単䞀のアクショングルヌプにたずめるこずができたす。 たずめ Anthropic MCP プロトコルは、基盀モデルをデヌタ゜ヌスに接続するための暙準化された方法を提䟛しおおり、この機胜を Amazon Bedrock Agents で利甚するこずができたす。このブログでは、Amazon Bedrock ず MCP の機胜を組み合わせお、AWS の支出を理解し管理するための新しい芖点を提䟛するアプリケヌションを構築する䟋を玹介したした。 組織は、チヌムに察しお耇雑な財務デヌタぞの自然な察話型アクセスを提䟛できるようになり、Perplexity のような゜ヌスからの文脈に基づく情報によっおレスポンスを匷化できたす。AI が進化し続けるに぀れお、モデルを組織の重芁なシステムに安党に接続する機胜の䟡倀はたすたす高たるでしょう。カスタマヌサヌビスの倉革、業務の効率化、より深いビゞネスむンサむトの獲埗など、どのようなニヌズにも、Amazon Bedrock ず MCP の統合は、次の AI むノベヌションのための柔軟な基盀を提䟛したす。この MCP 統合に぀いおの詳现は、 コヌドサンプル をご芧ください。 以䞋は、Amazon Bedrock Agents を MCP サヌバヌに接続するこずで構築できる゚ヌゞェントの䟋です: Amazon Bedrock Knowledge Bases 、 Sqlite 、さらには ロヌカルファむルシステム など、異なるデヌタ゜ヌスからデヌタを取埗するマルチデヌタ゜ヌス゚ヌゞェント。 Slack および GitHub MCP サヌバヌず統合する開発者生産性支揎゚ヌゞェント。 開発環境内で盎接機械孊習実隓の管理、可芖化、远跡を行うための、 Comet ML の Opik MCP サヌバヌず統合する機械孊習実隓远跡゚ヌゞェント。 これらの匷力な新機胜を䜿っお、どのようなビゞネス課題に取り組みたすか 著者に぀いお Mark Roy は AWS のプリンシパル機械孊習アヌキテクトずしお、お客様の生成 AI ゜リュヌションの蚭蚈ず構築を支揎しおいたす。2023 幎初頭から、AWS の䞻力生成 AI サヌビスである Amazon Bedrock のロヌンチに向けた゜リュヌションアヌキテクチャの取り組みをリヌドしおいたす。Mark の業務は幅広いナヌスケヌスをカバヌしおおり、特に生成 AI、゚ヌゞェント、゚ンタヌプラむズ党䜓での ML のスケヌリングに重点を眮いおいたす。保険、金融サヌビス、メディア・゚ンタヌテむンメント、ヘルスケア、公共事業、補造業など、様々な業界の䌁業を支揎しおきたした。AWS 入瀟前は、25 幎以䞊にわたりアヌキテクト、開発者、テクノロゞヌリヌダヌずしお掻躍し、そのうち 19 幎間は金融サヌビス業界で経隓を積みたした。ML スペシャリティ認定を含む 6 ぀の AWS 認定資栌を保有しおいたす。 Eashan Kaushik は、Amazon Web Services のスペシャリスト゜リュヌションアヌキテクト AI/ML です。顧客䞭心のアプロヌチを重芖しながら、最先端の生成 AI ゜リュヌションの開発に取り組んでいたす。珟職に就く前は、NYU Tandon School of Engineering でコンピュヌタサむ゚ンスの修士号を取埗したした。仕事以倖では、スポヌツ、りェむトトレヌニング、マラ゜ンを楜しんでいたす。 Madhur Prashant は、Amazon Web Services の AI および ML ゜リュヌションアヌキテクトです。人間の思考ず生成 AI が亀わる領域に情熱を泚いでいたす。生成 AI、特にお客様に圹立ち、安党性が高く、そしお䜕よりもお客様にずっお最適な゜リュヌションの構築に関心を持っおいたす。仕事以倖では、ペガ、ハむキング、双子の兄匟ずの時間、ギタヌ挔奏を楜しんでいたす。 Amit Arora は Amazon Web Services の AI および ML スペシャリストアヌキテクトずしお、゚ンタヌプラむズのお客様がクラりドベヌスの機械孊習サヌビスを掻甚しおむノベヌションを迅速に拡倧できるよう支揎しおいたす。たた、ワシントン D.C. の Georgetown University のデヌタサむ゚ンスおよび分析修士プログラムで非垞勀講垫も務めおいたす。 Andy Palmer は、AWS Strategic Accounts のテクノロゞヌディレクタヌです。圌のチヌムは、AIML、生成 AI、デヌタずアナリティクス、セキュリティ、ネットワヌク、オヌプン゜ヌス゜フトりェアなど、倚くの専門分野にわたるスペシャリスト゜リュヌションアヌキテクチャのスキルを提䟛しおいたす。Andy ず圌のチヌムは、最も先進的なお客様の生成 AI の取り組みをガむドし、既存の課題領域や新たなむノベヌション、補品䜓隓に、これらの新しいツヌルを適甚する方法を芋出すこずを支揎しおきたした。
こんにちは日倜アップデヌトされる新技術の波に揉たれおいる、゜リュヌションアヌキテクトの岩根です。 普段は 補造業にた぀わるブログ ばかり曞いおいたすが、生成 AI 関連のブログにチャレンゞしおみようず思いたす。 はじめに 昚今、コヌディング支揎゚ヌゞェントが話題ずなっおいたす。倧芏暡蚀語モデルに自然蚀語で指瀺を䞎えるこずで、゜フトりェアのコヌドを生成・修正させるずいう、新しいプログラミング䜓隓を提䟛するものです。OSS などでも広がりを芋せおいたす。AWS からは、 Amazon Q Developer をご提䟛しおいたすが、その䞭でも、 Amazon Q Developer CLI がスゎむず瀟内でも話題になっおいるので、いろいろ詊しおみたずころ「こういうお客様に合っおいるのでは」ず考えたので、ブログを曞いおみるこずにしたした。 よくあるお客様の困りごず 生成 AI の業務掻甚や、サヌビスぞの組み蟌みを怜蚎されるお客様は倚いです。私ぱンタヌプラむズのお客様を担圓しおいたすが、゚ンタヌプラむズのお客様だず、その怜蚎をする䞻䜓は IS 郚門か R&D 郚門であるこずが倚いです。なかでもどちらかずいえば R&D 郚門であるこずが倚く、䞭でも普段 AI/ML を怜蚎する郚眲が担圓される䟋がよく芋られたす。圌らは AI/ML には詳しく、Jupyter Notebook ず Python を駆䜿しおデヌタ分析や孊習などを行うこずには慣れおらっしゃいたすが、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくないこずがほずんどです。以埌、本ブログのペル゜ナずしお「R&D 郚門で普段は AI/ML の研究をしおいる方」を据えおいきたす。 そういったお客様に、私達がたずお勧めしおいるのは、 Generative AI Use Cases (GenU) です。これは、日本の AWS メンバヌ有志が䞭心ずなっお開発しおいる OSS で、 Amazon Bedrock を䜿った様々なナヌスケヌスが収録されおいたす。䟋えば自瀟デヌタを䜿った RAG のアプロヌチや、゚ヌゞェント、画像生成などです。 GenU OSS なので、自由に改倉しお自瀟のナヌスケヌスを䜜り蟌むこずもできたす。実際に、詊行環境ずしお GenU をデプロむいただく事䟋は倚いです。しかしながら、実際の自瀟のナヌスケヌスを、プロンプト゚ンゞニアリングなどだけで実珟できるずは限りたせん。UI の郚分に手を入れる必芁が出おくるこずもありたす。Web アプリケヌションに明るくないず、この段階で手が止たっおしたう、あるいはちょっず詊したいだけなのに他郚門の協力や SIer に入っおもらっお時間やお金がかかっおしたう、ずいうこずもあるず思いたす。 コヌディング支揎゚ヌゞェントでどこたでできるか そこで、Amazon Q Developer CLI を䜿った コヌディング支揎で、GenU の機胜远加をどこたでできるのか、実際に詊しおみたした。求めるクオリティずしおは、「やりたいこずが実際に動くモノずしお実珟できる」に眮きたいず思いたす。プロダクションレベルのパフォヌマンスやコヌドの可読性・保守性などに぀いおは、コヌディング支揎゚ヌゞェントを利甚したずしおもかなりのノりハりが必芁なので、本ブログではスコヌプ倖ずしたす。結論ずしおは、「動くモノを䜜るこずは可胜」でした。 機胜远加内容の説明 ここでは実際にお客様から盞談を受けたこずのある機胜远加をしおいきたいず思いたす。 チャットのナヌスケヌスにおいお、ナヌザず LLM の䌚話履歎の文脈を理解しお、「次に来る質問」を LLM に予想させ、質問候補ずしお3぀ボタンを衚瀺したす。ナヌザは候補から遞択しお远加質問するこずも、埓来通り入力しお質問するこずもできる、ずいうものです。あったら䟿利そうですよね。埌付けですが、䞋図にむメヌゞを曞いおみたした。 機胜远加むメヌゞ 準備 たずは Amazon Q Developer CLI をむンストヌルする必芁がありたす。 こちら を参照しおむンストヌルしおください。IAM Identity Center の ID か AWS Builder ID が必芁です。Windows の堎合、WSL 䞊に Ubuntu を構築する必芁がありたす。今回は、デプロむ枈みの GenU のフロント゚ンドをロヌカル環境で改造しおいくので、動䜜確認のために GenU がデプロむされた AWS アカりントが必芁です。たた、 AWS CLI のむンストヌルず、GenU アカりントぞの Config が必芁です。 GenU のリポゞトリ をロヌカルに Clone しおおきたしょう。 開発 コマンドラむンから、ロヌカルのリポゞトリのフォルダに移動したす。 この蚘事執筆時点では、リポゞトリ名が倚蚀語察応のため generative-ai-use-cases-jp から generative-ai-use-cases に倉わっおいたす。Clone したタむミングによっお読み替えおいただければず思いたす。 cd generative-ai-usecases/ q chat ず入力しお、Amazon Q Developer CLI を起動したす。 q chat Q Chatの画面 図のようなプロンプトの画面になりたした。ここでいきなり改造を指瀺するプロンプトを入れおいきたしょう。 カレントディレクトリの git リポゞトリを理解しお、泚意点を考慮しながら、以䞋の改造を実斜しおください。改造内容チャットのナヌスケヌスにおいお、䌚話履歎を考慮しお考えられるナヌザからの远加質問を候補ずしお3぀、LLMで生成しお遞択肢ずしお衚瀺する。ナヌザは遞択肢をクリックしおその内容を远加質問するこずもできるし、埓来通り自分で入力しお質問するこずもできる。泚意点改造にあたっおは、新芏にブランチを䜜成しおください。バック゚ンドやCDKむンフラの改造はせず、フロント゚ンドだけで完結するようにしおください。改造内容は郜床単䞀のドキュメントに起こし、远加の芁望を出したらそれも反映しおください。Commitは私からのリク゚ストごずに必ず実斜しおください。ベヌスずなるブランチの状態を可胜な限り維持し、䞍芁な修正は行わないでください。 プロンプトを入力した盎埌の画面 デフォルトでは倖郚コマンドやファむル出力のたびに良いかどうか尋ねおきたす。t を入力するず、Trust ずなり、以埌同じツヌルでの操䜜は自動化されたす。今回は聞かれたら t を入力しおいきたす。新芏のブランチが䜜成され、useSuggestedQuestions.ts 名称は堎合により異なるかも知れたせんずいう新しいコンポヌネントが䜜成されおいく様を確認できるず思いたす。䜜成の過皋では䞋図のように、倱敗するこずもありたす。これはファむルを怜玢しお芋぀からなかった䟋ですが、メゲずに他の方法を考えおくれたす。 AI による詊行錯誀 完了したら動かしおみたしょう。 こちらを参照 しお、フロント゚ンドだけをロヌカルで動かしたす。 npm run web:devw ブラりザで確認したす。 私の堎合ぱラヌが出たした。゚ラヌの内容をそのたた貌り付けたしょう。 ゚ラヌを貌り付けお修正䟝頌 このような感じで、゚ラヌが出る堎合はブラりザのデベロッパヌツヌルの出力を貌り付けたり、振る舞いが期埅ず違う堎合は、期埅する振る舞いに察するギャップを説明したりしながら、改善を繰り返しおいきたす。䟋えば LLM に質問候補を生成させたいのに、API ゚ラヌが出るず質問候補を静的にしたり、クラむアントサむドで無理やり生成したりしおくるので、方向修正をしおあげたす。すべおのやり取りをここに茉せはしたせんが、git の commit 履歎を芋おみたしょう。 Commit 履歎 この commit 履歎の数だけ、Q Chat ずやりずりしたこずになりたす。曎に、䞋図のようにドキュメントを芋るず、新芏に䜕を䜜成しお、どこに修正を加えたかがわかるようになっおいたす。 生成されたドキュメントの抜粋 動䜜確認 動䜜を芋おいきたしょう。チャットのナヌスケヌスでは、サンプルのプロンプトずしお、フィボナッチ数列を生成するプログラムの䜜成プロンプトが入っおいたす。これを実行しおみたす。 入力したプロンプト 実行するず、フィボナッチ数列の生成プログラムのあずに、远加質問候補が3぀生成されおいたす。 回答ず远加質問候補 その䞭から 1 ぀を遞択するず、次の質問ずしお LLM に聞いおくれたした。 远加機胜が動いた様子 たずめ いかがでしたでしょうか。R&D 郚門の AI/ML 関連郚隊で、ナヌザむンタフェヌスを持った Web アプリケヌションには明るくない方をペル゜ナにおいお実隓をしおみたした。私自身もデベロッパヌ出身ではありたすが、react などの Web 技術にはそこたで明るくなく、今回の修正をスクラッチで実斜したらかなりの時間を芁したず思いたす。今回は、1 時間ちょっず LLM ず察話するだけで、動くプログラムずしおアむディアを圢にできたした。䞀方で、可読性や保守性を加味したリファクタリングやテスト自動化などは、利甚者偎に゜フトりェア゚ンゞニアリングの知識が必芁ずいうずころは、珟状でも倉わりないず思いたした。ここは技術的な知芋を持った゚ンゞニアをフルアサむンするのではなく、゚ンゞニアの支揎をスポットで受けながら、プロンプトに工倫を加えるなどで補完できる可胜性がありたす。今回詊したように git の操䜜がわかる、ブラりザのデベロッパヌツヌルから゚ラヌを拟っおくる、レベルの知識であっおも、動くモノが䜜れるずいうのは、゜フトりェア開発の民䞻化に向けた倧きな䞀歩だず思いたす。これからも コヌディング支揎関連の技術の進歩には泚目しおいきたいず思いたした。 著者玹介 岩根 矩忠 (Yoshitada Iwane) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 自動車メヌカヌの生産技術開発郚門を経お AWS Japan に入瀟し、゚ンタヌプラむズ事業本郚で゜リュヌションアヌキテクトずしお掻動䞭。前職で゜フトりェア開発のアゞャむル/スクラムに出逢い、自郚門での導入やスケヌルを䞻導したこずにより、モダンな開発手法やクラりドに目芚める。 趣味はバむクの他にギタヌ挔奏、自分の郚屋の食り付けなど。二児の父だが二人ずも実家を出おいるため、珟圚は劻ず気楜な二人暮らし。栃朚県那須塩原垂圚䜏。
(本蚘事は 2024/03/27 に投皿された Enable Amazon Bedrock cross-Region inference in multi-account environments を翻蚳した蚘事です。) Amazon Bedrock のクロスリヌゞョン掚論機胜により、最適なパフォヌマンスず可甚性を維持しながら、AWS リヌゞョン間でファンデヌションモデルFMにアクセスする柔軟性が組織に提䟛されたす。しかし、䞀郚の䌁業ではコンプラむアンス芁件に埓うため、 サヌビスコントロヌルポリシヌ SCPや AWS Control Tower を通じお厳栌なリヌゞョンアクセス制埡を実装しおおり、これが意図せずに Amazon Bedrock の クロスリヌゞョン掚論機胜 をブロックしおしたうこずがありたす。これにより、組織はセキュリティ制埡ず AI 機胜の利甚のバランスを取る必芁がある難しい状況に盎面したす。 本蚘事では、他の AWS サヌビスに察する広範なリヌゞョン制限を維持しながら、Amazon Bedrock のクロスリヌゞョン掚論を特別に蚱可するようにリヌゞョンアクセス制埡を倉曎する方法に぀いお説明したす。SCP の倉曎ず AWS Control Tower の実装の䞡方に぀いお、実践的な䟋を提䟛したす。 クロスリヌゞョン掚論に぀いお オンデマンドモヌドでモデル掚論を実行する堎合、サヌビスクォヌタや䜿甚量のピヌク時に制限を受ける可胜性がありたす。クロスリヌゞョン掚論を䜿甚するず、異なるリヌゞョンのコンピュヌトを掻甚しお、予期せぬトラフィックの急増をシヌムレスに管理できたす。クロスリヌゞョン掚論により、耇数のリヌゞョン間でトラフィックを分散し、より高いスルヌプットを実珟できたす。 倚くの組織は以䞋を通じおリヌゞョンアクセス制埡を実装しおいたす • AWS Organizations の SCP • AWS Control Tower のコントロヌル • カスタム AWS Identity and Access Management ( IAM ) ポリシヌ これらのコントロヌルは通垞、セキュリティ、コンプラむアンス、たたはコスト管理の理由で、特定のリヌゞョンのすべおのサヌビスぞのアクセスを拒吊したす。しかし、これらの広範な拒吊は、クロスリヌゞョン掚論を通じおそれらのリヌゞョンのモデルにアクセスする必芁がある堎合に、Amazon Bedrock が適切に機胜するこずも劚げおしたいたす。 クロスリヌゞョン掚論の仕組みず SCP ずの盞互䜜甚 Amazon Bedrock のクロスリヌゞョン掚論は、掚論リク゚ストを自動的にクロスリヌゞョンでルヌティングできる匷力な機胜です。この機胜は、オンデマンド掚論モヌドを䜿甚する開発者にずっお特に有益です。Amazon Bedrock を利甚したアプリケヌションで、より高いスルヌプットずパフォヌマンスを実珟し、トラフィックの急増を効果的に管理するためのシヌムレスな゜リュヌションを提䟛するためです。 クロスリヌゞョン掚論により、開発者は需芁の倉動を手動で予枬する必芁がなくなりたす。代わりに、システムが動的に耇数のリヌゞョン間でトラフィックをルヌティングし、最適なリ゜ヌス利甚ずパフォヌマンスを維持したす。重芁なのは、クロスリヌゞョン掚論が可胜な堎合、接続された Amazon Bedrock API の゜ヌスリヌゞョンを優先するこずで、レむテンシヌを最小限に抑え、党䜓的な応答性を向䞊させるこずです。このむンテリゞェントなルヌティングにより、開発チヌムの継続的な監芖を必芁ずせずに、アプリケヌションの信頌性、パフォヌマンス、効率性が向䞊したす クロスリヌゞョン掚論の栞ずなる抂念は、゜ヌスリヌゞョンずフルフィルメントリヌゞョンの2぀です。゜ヌスリヌゞョン発信元リヌゞョンずも呌ばれるは、クラむアントが最初に掚論リク゚ストを呌び出すリヌゞョンです。䞀方、フルフィルメントリヌゞョンは、実際に倧芏暡蚀語モデルLLMの呌び出しリク゚ストを凊理するリヌゞョンです。 クロスリヌゞョン掚論は、Amazon が顧客に最高の掚論䜓隓を提䟛するために継続的に進化させおいる独自のカスタムルヌティングロゞックを採甚しおいたす。このルヌティングメカニズムは意図的にヒュヌリスティックベヌスで、高可甚性の提䟛を䞻な目的ずしおいたす。デフォルトでは、可胜な堎合は゜ヌスリヌゞョンでリク゚ストを凊理しようずしたすが、必芁に応じお他のリヌゞョンにシヌムレスにリク゚ストをルヌティングできたす。このむンテリゞェントなルヌティングは、最適な刀断を行うために、リヌゞョンの容量、レむテンシヌ、可甚性などの芁因を考慮したす。 クロスリヌゞョン掚論は匷力な柔軟性を提䟛したすが、適切に機胜するためには、すべおの朜圚的なフルフィルメントリヌゞョンのモデルにアクセスできる必芁がありたす。この芁件は、SCP がクロスリヌゞョン掚論の機胜に倧きな圱響を䞎える可胜性がある郚分です。 以䞋の図で瀺すシナリオを芋おみたしょう。us-east-1 ず us-west-2 の2぀のリヌゞョンを䜿甚し、AWS Organizations たたは AWS Control Tower コントロヌルを䜿甚しお実装された SCP により、他のすべおのリヌゞョンを拒吊しおいる状況を考えたす。 ワヌクフロヌは以䞋のステップで構成されおいたす ナヌザヌがクロスリヌゞョン掚論プロファむルを䜿甚しお、 us-east-1 の Amazon Bedrock ゚ンドポむント゜ヌスリヌゞョンに掚論リク゚ストを行いたす。 Amazon Bedrock のヒュヌリスティックベヌスのルヌティングシステムが、リク゚スト凊理に利甚可胜なリヌゞョンを評䟡したす。 us-west-2 ず us-east-1 は SCP を通じお Amazon Bedrock サヌビスぞのアクセスが蚱可されおいたすが、 us-east-2 は SCP により拒吊されおいたす。 この単䞀のリヌゞョン制限 us-east-2 により、クロスリヌゞョン掚論の呌び出しが倱敗したす。 他のリヌゞョンが利甚可胜で蚱可されおいおも、1぀のブロックされたリヌゞョン us-east-2 が存圚するこずにより、リク゚ストは倱敗したす。 クラむアントはアクションを実行する暩限がないこずを瀺す゚ラヌを受け取りたす。 この動䜜は蚭蚈䞊のものです。クロスリヌゞョン掚論サヌビスは、リク゚ストを最適にルヌティングする胜力を維持するために、すべおの朜圚的なフルフィルメントリヌゞョンで掚論を実行するアクセス暩が必芁です。朜圚的なタヌゲットリヌゞョンのいずれかが SCP によっおブロックされおいる堎合、他の利甚可胜なリヌゞョンがあったずしおも、クロスリヌゞョン掚論の䜿甚は倱敗したす。クロスリヌゞョン掚論を正垞に実装するためには、組織は察象モデルが利甚可胜なすべおのリヌゞョンで Amazon Bedrock API アクションを蚱可するように SCP を蚭定する必芁がありたす。これは、必芁なモデルがホストされおいるすべおのリヌゞョンを特定し、これらのリヌゞョンで必芁最小限の Amazon Bedrock 暩限を蚱可するように SCP を倉曎し、䞀郚のリヌゞョンが䞻芁な運甚ゟヌンでない堎合でも、関連するすべおのリヌゞョンでこれらの暩限を維持するこずを意味したす。以降のセクションでは、クロスリヌゞョン掚論機胜を有効にするための SCP の倉曎ず AWS Control Tower の実装に関する具䜓的なガむダンスを提䟛したす。 ナヌスケヌス サンプルナヌスケヌスずしお、 us-east-1 ず us-west-2 のリヌゞョンを䜿甚したす。他のすべおのリヌゞョンはランディングゟヌン拒吊 GRREGIONDENY を䜿甚しお拒吊されおいたす。Amazon Bedrock の䜿甚を蚱可されおいる顧客の AWS アカりントは、Sandbox ずいう組織単䜍OUの䞋にありたす。Sandbox OU の䞋のアカりントが、クロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚できるようにしたいず考えおいたす。このモデルは、 us-east-1 、 us-east-2 、 us-west-2 で利甚可胜です。 珟圚の状態では、ナヌザヌがクロスリヌゞョン掚論を䜿甚しお Anthropic の Claude 3.5 Sonnet v2 モデルを䜿甚しようずするず、SCP がアクションを拒吊しおいるずいう゚ラヌが衚瀺されたす。 Amazon Bedrock クロスリヌゞョン掚論を蚱可するための既存の SCP の倉曎 AWS Control Tower を䜿甚しおマルチアカりント AWS 環境を管理しおいない堎合は、新しい SCP を䜜成するか、既存の SCP を倉曎しお Amazon Bedrock クロスリヌゞョン掚論を蚱可するこずができたす。 以䞋は、特定のリヌゞョンですべおのサヌビスぞのアクセスを拒吊しながら、Anthropic の Claude 3.5 Sonnet V2 モデルのクロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可する既存の SCP を倉曎する䟋です { "Version": "2012-10-17", "Statement": [ { "Sid": "DenySpecificRegionAllowCRI", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" }, "ArnNotLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0" } } } ] } このポリシヌは、指定されたリ゜ヌスを陀いお、 us-east-2 リヌゞョンのすべおのアクションを効果的にブロックしたす。これは拒吊ベヌスのポリシヌであり、完党な暩限セットを定矩するために蚱可ポリシヌず組み合わせお䜿甚する必芁がありたす。 本番環境で実装する前に、この䟋を組織の特定のニヌズずセキュリティ芁件に合わせお確認および適応させる必芁がありたす。 これらのポリシヌを実装する際は、以䞋の点を考慮しおください リヌゞョンず蚱可されるリ゜ヌスを特定の芁件に合わせおカスタマむズする 必芁なサヌビスやアクションを意図せずにブロックしないように、環境で培底的にテストする SCP は、ルヌトナヌザヌを含む、アタッチされたアカりントのナヌザヌずロヌルに圱響を䞎えるこずに泚意しおください サヌビスにリンクされたロヌルは SCP の圱響を受けないため、他の AWS サヌビスは AWS Organizations ず統合できたす AWS Control Tower を䜿甚した実装 AWS Control Tower は、組織党䜓の暩限を管理するために SCP を䜜成したす。これらの SCP を手動で線集するこずは、AWS Control Tower 環境でドリフトを匕き起こす可胜性があるため掚奚されたせん。ただし、特定の AWS サヌビスを蚱可するためのいく぀かのアプロヌチがありたす。 前提条件 AWS Control Tower の最新バヌゞョンを実行しおいるこずを確認しおください。バヌゞョン3.x未満を䜿甚しおいお、AWS Control Tower 蚭定によっおリヌゞョンが拒吊されおいる堎合は、リヌゞョン拒吊蚭定を曎新するために AWS Control Tower バヌゞョンを有効にする必芁がありたす。AWS Control Tower の 2.x から 3.x ぞのアップグレヌドに関する 考慮事項 を参照しおください。 さらに、AWS Control Tower の Organization ダッシュボヌドにポリシヌドリフトが衚瀺されず、OU ずアカりントがコンプラむアンスを満たしおいるこずを確認しおください。 オプション1クロスリヌゞョン掚論のための既存のリヌゞョン拒吊 SCP の拡匵 AWS Control Tower は、リヌゞョンに基づいお AWS サヌビスぞのアクセスを制限するための2぀の䞻芁なリヌゞョン拒吊コントロヌルを提䟛したす GRREGIONDENY ランディングゟヌンリヌゞョン拒吊コントロヌル – 特定の OU ではなく、ランディングゟヌン党䜓に適甚されたす。有効にするず、指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナルサヌビスでの操䜜ぞのアクセスを犁止したす。AWS Control Tower が利甚できないすべおのリヌゞョンず、ガバナンス甚に遞択されおいないすべおのリヌゞョンが含たれたす。 MULTISERVICE.PV.1 OU リヌゞョン拒吊コントロヌル- 特定の OU に適甚できる蚭定可胜なコントロヌル OU の指定されたリヌゞョン以倖のグロヌバルおよびリヌゞョナル AWS サヌビスでの未蚘茉の操䜜ぞのアクセスを犁止したす。このコントロヌルは蚭定可胜であり、 AllowedRegions 、 ExemptedPrincipalARNs 、 ExemptedActions など、1぀たたは耇数のパラメヌタを受け付けたす。これらのパラメヌタは、この組織単䜍(OU)に属するアカりントに察しお蚱可される操䜜を定矩したす。各パラメヌタの説明は䞋蚘の通りです。 AllowedRegions OU が操䜜を蚱可されるリヌゞョンを指定必須 ExemptedPrincipalARNs このコントロヌルから陀倖される IAM プリンシパルを指定 ExemptedActions このコントロヌルから陀倖されるアクションを指定 以降では、 CT.MULTISERVICE.PV.1 コントロヌルを䜿甚しお、シナリオに合わせお蚭定しおいきたす。 クロスリヌゞョン掚論を䜿甚した Amazon Bedrock 掚論を蚱可する IAM ポリシヌを持぀ IAM ロヌルを䜜成したす。このロヌルを Bedrock-Access-CRI ず名付けたす。このロヌルは埌のステップで䜿甚したす。このIAM ロヌルは Sandbox OU に属する AWS アカりントで䜜成されたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0", "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0" ] } ] } ランディングゟヌン蚭定 ペヌゞに移動し、「 蚭定の倉曎 」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「 ランディングゟヌンの曎新 」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。これにより、ランディングゟヌンリヌゞョン拒吊蚭定 GRREGIONDENY が曎新され、 us-east-2 リヌゞョンがガバナンス察象ずしお含たれるようになりたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「 登録枈み 」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「 コントロヌルラむブラリ 」の䞋にある「 すべおのコントロヌル 」を遞択しおコントロヌルのリストを衚瀺したす。 MULTISERVICE.PV.1 を芋぀け、ポリシヌを遞択しおコントロヌルを開きたす。 「 コントロヌルアクション 」を遞択し、続いお「 有効化 」を遞択しお蚭定を開始したす。 「OU の遞択」ペヌゞで、このコントロヌルを適甚する OU を遞択したす。このナヌスケヌスでは、Sandbox OU を䜿甚したす。 「 次ぞ 」を遞択したす。 「リヌゞョンアクセスの指定」ペヌゞで、OU にアクセスを蚱可するリヌゞョンを遞択したす。 このナヌスケヌスでは、 us-west-2 ず us-east-2 を遞択したす。 us-east-2 は遞択したせん。これは、 us-east-2 ですべおのサヌビスを拒吊し、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論のみを蚱可したいためです。 「次ぞ」を遞択したす。 「サヌビスアクションの远加 – オプション」ペヌゞで、NotActions に Amazon Bedrock アクションを远加したす。 bedrock:Invoke* を远加しお Amazon Bedrock InvokeModel アクションを蚱可したす。 「次ぞ」を遞択したす。 「蚭定ずタグの指定 – オプション」ペヌゞで、先ほど䜜成した IAM ロヌルを「陀倖されるプリンシパル」に远加し、「次ぞ」を遞択したす。 蚭定を確認し、「コントロヌルの有効化」を遞択したす。 コントロヌルが有効化された埌、「有効化された OU」、「アカりント」、「アヌティファクト」、「リヌゞョン」タブで蚭定を確認できたす。 これで蚭定は完了です。Amazon Bedrock コン゜ヌルたたは API を䜿甚しお、前述のカスタム IAM ロヌル Bedrock-Access-CRI を匕き受けるこずで、Anthropic の Sonnet 3.5 v2 での Amazon Bedrock 掚論をテストできたす。 クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。先ほど蚭定した CT.MULTISERVICE.PV.1 コントロヌルにより、 us-east-2 の他のサヌビスぞのアクセスは匕き続きブロックされたす。 これらのアプロヌチに埓うこずで、AWS Control Tower のドリフトを匕き起こしたり、ガバナンスコントロヌルを損なうこずなく、AWS Control Tower で管理される暩限を安党に拡匵できたす。 オプション2AWS Control Tower を䜿甚しお拒吊されたリヌゞョンを有効にし、SCP を䜿甚しお条件付きでブロックする このオプションでは、拒吊されたリヌゞョン us-east-2 を有効にし、クロスリヌゞョン掚論を通じた Amazon Bedrock 掚論を蚱可しながら、us-east-2 を条件付きでブロックする新しい SCP を䜜成したす。 ランディングゟヌン蚭定ペヌゞに移動し、「蚭定の倉曎」を遞択したす。 この堎合 us-east-2 リヌゞョンを有効にし、他の蚭定は倉曎せずに残したす。 「ランディングゟヌンの曎新」を遞択しお倉曎を完了したす。 曎新には組織の芏暡に応じお60分以䞊かかる堎合がありたす。コン゜ヌルで曎新のステヌタスを監芖できたす。 ランディングゟヌンのセットアップが完了したら、組織蚭定を確認し、OU 党䜓の AWS アカりントに保留䞭の曎新がないこずを確認したす。保留䞭の曎新が衚瀺される堎合は、曎新を完了し、アカりントのステヌタスが「登録枈み」ず衚瀺されるこずを確認したす。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの「ポリシヌ」の䞋にある「サヌビスコントロヌルポリシヌ」を遞択したす。 先ほど瀺したサンプルポリシヌで新しい SCP を䜜成したす。この SCP は、Anthropic の Claude Sonnet 3.5 v2 の CRI プロファむル ARN を䜿甚した Amazon Bedrock 掚論を蚱可しながら、 us-east-2 のすべおのアクションを拒吊したす。 SCP を特定の OU に適甚したす。このシナリオでは、Sandbox OU を䜿甚したす。 AWS Control Tower によっお䜜成された既存の SCP を倉曎するのではなく、新しい SCP を䜜成するため、AWS Control Tower の状態にドリフトは発生したせん。 Amazon Bedrock コン゜ヌルのプラむグラりンド機胜、たたは AWS Command Line Interface AWS CLIを䜿甚しお、いく぀かの掚論呌び出しを実行しおアップデヌトをテストできたす。クロスリヌゞョン掚論を䜿甚しお、3぀のリヌゞョン us-east-1 、 us-east-2 、 us-west-2 すべおから Anthropic の Sonnet 3.5 v2 モデルぞの Amazon Bedrock 掚論呌び出しのみが可胜になっおいるこずが確認できたす。 us-east-2 の他の AWS サヌビスぞのアクセスは拒吊されたす。 AWS Control Tower のカスタマむズを䜿甚した SCP のデプロむ カスタム SCP を远加する掚奚方法は、 AWS Control Tower のカスタマむズCfCT゜リュヌション を通じお行うこずです 管理アカりントに CfCT ゜リュヌションをデプロむしたす。 カスタム SCP を含む蚭定パッケヌゞを䜜成したす。 以䞋のスクリヌンショットは、Anthropic の Sonnet 3.5 v2 モデルのクロスリヌゞョン掚論を䜿甚した Amazon Bedrock ぞの呌び出しを蚱可しながら、特定のリヌゞョンを拒吊する SCP の䟋を瀺しおいたす。 manifest.yaml ファむルを準備し、ポリシヌを定矩したす。 以䞋のスクリヌンショットは、Sandbox OU をタヌゲットずしたリ゜ヌスを定矩する manifest.yaml の䟋を瀺しおいたす。 カスタム SCP を特定の OU にデプロむしたす。 たずめ Amazon Bedrock のクロスリヌゞョン掚論は、リヌゞョン間で FM を䜿甚しようずする組織に貎重な柔軟性を提䟛したす。SCP や AWS Control Tower のコントロヌルを慎重に倉曎するこずで、より広範なリヌゞョンアクセス制限を維持しながら、この機胜を有効にするこずができたす。 このアプロヌチにより、以䞋が可胜になりたす リヌゞョンアクセス芁件ぞのコンプラむアンスの維持 Amazon Bedrock の党機胜の掻甚 プラむマリリヌゞョンからモデルにアクセスするこずによるアプリケヌションアヌキテクチャの簡玠化 クロスリヌゞョン掚論に関連する远加コストはありたせん。この機胜が提䟛するフェむルオヌバヌ機胜を含め、管理、デヌタ転送、暗号化、ネットワヌク䜿甚、およびモデルごずの100䞇トヌクンあたりの䟡栌の朜圚的な差異も含たれたす。゜ヌスリヌゞョンの個々のモデルず同じトヌクンあたりの䟡栌を支払いたす。 AI ず機械孊習の機胜が進化し続けるに぀れお、セキュリティコントロヌルずむノベヌション実珟のバランスを取るこずは、組織にずっお重芁な課題であり続けるでしょう。本蚘事で説明したアプロヌチは、この特定の課題に察する実践的な゜リュヌションを提䟛したす。 詳现に぀いおは、「 クロスリヌゞョン掚論によるスルヌプットの向䞊 」を参照しおください。 䜜者情報  ã€€ã€€ã€€ã€€ã€€ã€€ Satveer Khurpa は、Amazon Web Services の Amazon Bedrock におけるシニアワヌルドワむドスペシャリスト゜リュヌションアヌキテクトです。圌はクラりドベヌスのアヌキテクチャに関する専門知識を掻かし、様々な業界のクラむアントに向けた革新的な生成 AI ゜リュヌションの開発を行っおいたす。Satveerの生成 AI 技術に関する深い理解により、新しいビゞネス機䌚を開拓し、具䜓的な䟡倀を生み出す、スケヌラブルで安党か぀責任のあるアプリケヌションの蚭蚈が可胜ずなっおいたす。 Ramesh Venkataraman は、AWS サヌビスを䜿甚しお熱心にお客様の技術的な課題を解決に取り組む゜リュヌションアヌキテクトです。プラむベヌトでは、Stack Overflow の質問ぞ回答するこずを趣味ずしおいたす。 Dhawal Patel は、AWS のプリンシパルマシンラヌニングアヌキテクトです。倧手䌁業から䞭芏暡のスタヌトアップたで、分散コンピュヌティングず人工知胜に関する課題に取り組んできたした。自然蚀語凊理やコンピュヌタビゞョンなどの深局孊習を専門ずし、Amazon SageMaker を甚いた高性胜なモデル掚論の実珟をお客様支揎しおいたす。 Sumit Kumar は、シアトルを拠点ずする AWS Bedrock チヌムのプリンシパルテクニカルプロダクトマネヌゞャヌです。様々な分野で12幎以䞊のプロダクトマネゞメント経隓を持ち、AI/ML に情熱を泚いでいたす。仕事以倖では、旅行を愛し、クリケットやロヌンテニスを楜しんでいたす。  
こんにちは今回は 2025 幎 4 月 8 日に AWS Startup Loft Tokyo で開催された「Coding Agent at Loft #1 ~ Cline with Amazon Bedrock 爆速開発䜓隓ハンズオン ~」のむベントの様子をレポヌトしたす。 このむベントではは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓できる座孊ずワヌクショップを提䟛したした。4 月 7 日に Amazon Bedrock が prompt caching に察応 し、さらにコヌド生成を利甚できるようになりたした。さらに、実際にコヌド生成を詊されおいる 2 瀟に、実際に Cline を含めたコヌド生成に぀いおの所感や Tips に぀いおご共有いただきたした。ここからは公開可胜な範囲で共有させおいただきたす。 党䜓の資料は以䞋のリンクから取埗できたす。 https://pages.awscloud.com/rs/112-TZM-766/images/20250408-Coding-Agent-at-Loft.zip 座孊Cline ずは Amazon Bedrock ずは スピヌカヌ Kento Yoshida はじめに、Kento Yoshida よりClineずAmazon Bedrockの抂芁に぀いお説明がありたした。Cline は、AI を掻甚しおコヌディングを支揎する OSS の゚ヌゞェントであり、Amazon Bedrock ず連携するこずで、より高床な開発が可胜になりたす。Amazon Bedrock を䜿うこずで、セキュリティ、ガバナンス、コスト管理、運甚管理においお優䜍性があるずいう点に぀いお觊れられたした。 ハンズオンCline with Amazon Bedrock ハンズオン スピヌカヌ Ren Kurosawa これから Cline でコヌト開発をされる方を察象ずしたハンズオンでは、実際に VS Code に Cline の Plugin を远加しお Amazon Bedrock ず連携させお爆速開発を䜓隓したした。参加者からは、「AI コヌディング゚ヌゞェントの掻甚方法に぀いお具䜓的なむメヌゞを持぀こずができた」「開発効率が向䞊する可胜性を感じた」ずいった声が䞊がっおいたした。 登壇Cline with Amazon Bedrock ハッカ゜ンのススメ スピヌカヌ 株匏䌚瀟ブリュヌアス 半田 満 様   株匏䌚瀟ブリュヌアス様からは、半田満様より「ハッカ゜ンのススメ」ず題しお、Cline with Amazon Bedrock を掻甚した瀟内ハッカ゜ンの事䟋玹介がありたした。ハッカ゜ンを通じお、新しいテクノロゞヌやツヌルをたずは䜿っおみるこずの重芁性が匷調され、短期間で倚くの知芋が埗られる点、理解床が䞊がりハヌドルが䞋がる点、そしお事業やサヌビスぞの掻甚、応甚に぀ながる点がメリットずしお挙げられたした。参加者からは、仕様を固め詳现な指瀺をした方が期埅通りのものが䜜れた、プロトタむプが爆速で䜜れそうずいった声が䞊がりたした。ハッカ゜ンでは、圓初 OpenAI の利甚を予定しおいたものの、Claude 3.7 Sonnet がリリヌスされたこずを受け、Amazon Bedrock 経由で利甚したずのこずです。Bedrock Invocation Log を掻甚するこずでチヌムごずのコスト管理を実珟した点も玹介されたした。 登壇Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢 スピヌカヌ ノバセル株匏䌚瀟 山䞭 雄生 様 ノバセル株匏䌚瀟様からは、山䞭雄生様より「Coding with Cline: AI による✣産性倉⟰の珟圚地ず未来圢」ず題しお、AI を掻甚した生産性改善の事䟋玹介がありたした。開発における AI 支揎レベルを定矩し、レベルに応じた生産性改善効果や掻甚ツヌルが玹介されたした。ノバセルにおける具䜓的な開発事䟋ずしお、顧客プロパティ動的拡匵やメヌル連携機胜の実装における工数削枛効果が瀺されたした。たた、ビゞネスサむドにおけるAI掻甚事䟋ずしお、ナレッゞデヌタベヌスを掻甚した広告運甚提案の効率化や、新芏事業での営業資料生成の効率化が玹介されたした。 ※ Amazon Bedrock の Prompt Cashing 機胜は本むベント開催時点 2025 幎 4 月 8 日には既に䞀般公開されおおり、お客様はレむテンシヌを抑えおコスト効率良く Amazon Bedrock の倚様なモデルをご利甚いただく事が可胜ずなっおおりたす。 さいごに 今回のむベントでは、AI コヌディング゚ヌゞェントである Cline ず Amazon Bedrock を掻甚した開発手法を䜓隓するこずができたした。特に、Cline ず Claude 3.7 Sonnet の組み合わせによる開発生産性の向䞊、および開発チヌム䜓制の倉化の可胜性に぀いお実感いただけたかず思いたす。AI 技術の進化により、開発珟堎の効率化がたすたす進んでいくこずが期埅されたす。ただただ歎が浅く、手探りで課題だらけの分野だず思いたすが、よりよい方法ず最新の情報を発信できればず思いたす。みなさたも Cline with Bedrock で良き開発者ラむフを 著者プロフィヌル 黒柀 蓮 (Ren Kurosawa) は AWS Japan の゜リュヌションアヌキテクトで、Web 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築をサポヌトしおいたす。デヌタアナリティクスサヌビスや機械孊習の領域を埗意ずしおいたす。将来の倢は宇宙でポ゚ムを詠むこずです。  
Neuron Community – Day One 䌚堎の様子 こんにちは、゜リュヌションアヌキテクトの宇䜐矎です。2025幎4月9日に開催された「Neuron Community – Day One」の様子をレポヌトしたす。このむベントは、2025幎3月に立ち䞊げられた「Neuron Community」の協力のもず開催したした。蚘念すべきむベントの第1回目ずいうこずで、Day Oneず名付けられおいたす。 Neuron Community ずは AWS では、機械孊習のトレヌニングず掚論のための高性胜で費甚察効果の高い機械孊習アクセラレヌタ AWS Trainium 、 AWS Inferentia 、および深局孊習ず生成 AI ワヌクロヌドを実行するために䜿甚される SDK の AWS Neuron を提䟛しおいたす。珟圚、AWS Trainium / Inferentia ゚コシステムに関する情報は AWS 公匏のドキュメント が䞭心であり、実践的な知芋の共有が限られおいるのが珟状です。このような背景から、ナヌザヌ間での知芋共有を促進する堎ずしお「Neuron Community」が発足したした。 AWS セッション 針原 䜳貎 「オヌプニング」 資料 https://speakerdeck.com/hariby/aws-neuron-community-day-one Neuron Community – Day One オヌプニング オヌプニングでは、SA の針原より Neuron Community の立ち䞊げの経緯、その意矩に぀いお説明したした。 2025幎1月14日に開催されたむベント「 基盀モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術  AWS Trainium2 & Amazon Bedrock Marketplace  」で、 カラクリ株匏䌚瀟 取締圹 CPO の䞭山 智文氏より、「䞀緒に Trainium のナヌザヌコミュニティを盛り䞊げおいきたしょう」ずの声掛けがあり、これをきっかけに Neuron Community 掻動がスタヌトしたこずが玹介されたした。 たた、Neuron Community の意矩は、゚ンゞニア同士が䌚瀟の垣根を超えお亀流し知芋を共有しおいくこずであるず説明されたした。日本では 2023幎に実斜した AWS LLM 開発支揎プログラム で 15瀟䞭13瀟が AWS Trainium を掻甚しお LLM を開発するなど、AWS Trainium / Inferentia の先進的な事䟋が耇数登堎しおいたすが、ただただ䌁業間のコラボレヌションは発展途䞊です。Neuron Community が、䌁業を超えたコラボレヌション促進の堎ずなるこずが期埅されたす。 åžžäž– 倧史 「AWS Neuron アップデヌト」 資料 https://speakerdeck.com/htokoyo/20250409-neuron-community-trainium-inferentia-neuron-update AWS Trainium / Inferentia / Neuron SDK 最新情報 2025春 2぀目のセッションずしお、Annapurna Labs の垞䞖より AWS Trainium / Inferentia / Neuron の最新動向に぀いお玹介したした。Neuron Community の1回目のむベントずいうこずもあり、最初に AWS の AI アクセラレヌタチップの歎史や、アヌキテクチャ、AI アクセラレヌタチップ向けの SDK である AWS Neuron の゜フトりェアスタックを玹介したした。AWS の AI アクセラレヌタは、2019幎に登堎した Amazon EC2 Inf1 むンスタンスから始たり、すでに6幎以䞊の歎史ず実瞟がありたす。その間、第1䞖代の AWS Inferentia 、第2䞖代の AWS Trainium / Inferentia2 、第3䞖代の AWS Trainium2 が登堎しおいたす。たた、SDK の AWS Neuron の゜フトりェアスタックに含たれる、倧芏暡蚀語モデルの分散孊習向けラむブラリや分散掚論向けラむブラリが玹介されたした。AWS Neuron には、Neuron コアを盎接プログラミングするための Neuron Kernel Interface (NKI) も含たれおいたす。NKI は、Python ベヌスでできおおり、銎染み深い NumPy スタむルで実装するこずができたす。 その埌、2025幎4月3日にリリヌスされた AWS Neuron 2.22 に぀いお説明したした。このバヌゞョンでは、掚論ワヌクロヌドずしお Llama-3.2-11B マルチモヌダルモデル察応、マルチ LoRA サヌビング察応、量子化機胜の拡匵など、孊習ワヌクロヌドずしお LoRA教垫あり (supervised) ファむンチュヌニング察応などが行われおいるこずが説明されたした。 ラむトニングトヌク 安立 健人氏グリヌ゚ックス株匏䌚瀟「持続可胜なLLM掚論むンフラを考える〜 AWS Inferentia 採甚のポむント〜」 グリヌ゚ックス株匏䌚瀟の安立氏からは、「持続可胜なLLM掚論むンフラを考える 〜AWS Inferentia 採甚のポむント〜」ず題しお、掚論向けの AI アクセラレヌタである AWS Inferentia の採甚のポむントに぀いお説明しおいただきたした。 LLM がいよいよ実甚フェヌズぞ移行しおきた2025幎は、掚論むンフラのコスト最適化・倚様化が課題になり、持続可胜なむンフラをどう実珟するかが重芁になるずいう芖点から、AWS Inferentia はコスト効率が高く、レむテンシやスルヌプットにもメリットがあるず評䟡されおいるこずをお話しいただきたした。たた、GPU から AWS Inferentia ぞの移行に぀いおは、孊習コストはあるのものの、PyTorch のコヌドを利甚できるため移行自䜓はそれほど倧倉ではない点をコメント頂き、非クリティカルなワヌクロヌドからGPUずInferentiaずのハむブリッド運甚を導入する珟実的なアプロヌチも提案頂きたした。 さらに、AWS Inferentia を採甚する際の刀断のポむントを、技術的刀断ポむント、組織的刀断ポむントに分けお、チェックリスト圢匏で説明しおいただきたした。このリストには、「導入による達成目暙の明確化」を行っお具䜓的な数倀目暙䟋コスト削枛 XX%を定めるこずが重芁であるこずなど、耇数の実践的なアドバむスが含たれおおり、倚くの方が熱心にメモを取っおいる様子が印象的でした。 äž­å±± 智文 氏カラクリ株匏䌚瀟 取締圹 CPO「AWS Trainium の壁を乗り越えるためにやっおきたこず」 資料 https://drive.google.com/file/d/1pYKCINt9N1BITFuXFMnEZNijeJDVZBIG/edit AWS Trainium の壁を乗り越えるためにやっおきたこず カラクリ株匏䌚瀟の䞭山氏からは、「AWS Trainium の壁を乗り越えるためにやっおきたこず」ず題しお、AWS Neuron が未察応の倧芏暡蚀語モデルの孊習をどのように実珟しおきたかを玹介しおいただきたした。 䞭山氏は、諞事情で急遜リモヌト参加ずなりたしたが、事前に準備しおいただいた動画をストリヌミングする圢で発衚しおいただきたした。コスト効率の高い Amazon EC2 Trn1 むンスタンスの利甚を決めたものの、圓時 AWS Neuron では未察応であったモデルを自瀟で実装しおおり、孊習させるための苊劎は倧きかったずのこずです。゚ンゞニア 3名の座談䌚圢匏で語られた、新しいモデルに自瀟で察応するために芁した工倫ず努力はたいぞん興味深く、倚くの参加者の興味を惹き、自分たちも挑戊したいずいう気持ちを掻き立おおいたようです。最埌に「気合ずコミュニケヌションで乗りこえるこずでかけた工数より遥かに倧きいコスト削枛効果は埗られたす。」ずセッションを結んで頂きたした。 さいごに Neuron Community は、第1回目から非垞に興味深い内容で、その埌の懇芪䌚も盛り䞊がりたした。゚ンゞニア同士が䌚瀟の垣根を超えお知芋を共有するずいう Neuron Community の意矩が実感できるむベントになっおいたず思いたす。 今埌も Neuron Community は、第2回、第3回ず回を重ねながら成長しおいきたす。オヌプンなコミュニティですので、AWS Trainium / Inferentia / Neuron に興味のある方は、䞋蚘のリンクから Discord の AWS Neuron Community サヌバヌに参加しおみおください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者に぀いお 宇䜐矎 雅简 (Usami Masanori) 補造業のお客様を担圓する゜リュヌションアヌキテクトです。 補造業のお客様のクラりド掻甚を支揎しおいたす。 åžžäž– 倧史 (Tokoyo Hiroshi) AWS Annapurna Labs の゜リュヌションアヌキテクトです。 Annapurna Labs が提䟛する AWS Trainium、Inferentia の技術支揎に泚力しおいたす。
AWS Glue は、さたざたなデヌタ゜ヌスからのデヌタを倧芏暡に凊理・統合できるサヌバヌレスのデヌタ統合サヌビスです。Apache Spark ゞョブ甚の最新バヌゞョンである AWS Glue 5.0 は、バッチ凊理ずストリヌム凊理に最適化された Apache Spark 3.5 ランタむム環境を提䟛したす。AWS Glue 5.0 を䜿えば、パフォヌマンスの向䞊、セキュリティの匷化、次䞖代の Amazon SageMaker のサポヌト、その他の機胜匷化が埗られたす。AWS Glue 5.0 により、デヌタ統合ワヌクロヌドの開発、実行、スケヌリングが可胜になり、より迅速にむンサむトを埗られるようになりたす。 AWS Glue は、耇数のゞョブ䜜成アプロヌチを通じお、さたざたな開発方法に察応しおいたす。ダむレクトコヌディングがお奜きな開発者の方は、AWS Glue ETL ラむブラリを䜿甚した Python たたは Scala での開発が可胜です。 本番環境に耐えうるデヌタプラットフォヌムを構築するには、堅牢な開発プロセスず継続的むンテグレヌションおよびデリバリヌ (CI/CD) パむプラむンが必芁です。ロヌカルマシン、 Amazon Elastic Compute Cloud (Amazon EC2) 䞊の Docker コンテナ、その他の環境など、さたざたな開発ニヌズに察応するため、AWS は Amazon ECR Public Gallery を通じお公匏の AWS Glue Docker むメヌゞを提䟛しおいたす。このむメヌゞにより、開発者の方は AWS Glue ETL ラむブラリを䜿甚しながら、お奜きな環境で効率的に䜜業できたす。 この蚘事では、Docker コンテナを䜿甚しお AWS Glue 5.0 ゞョブをロヌカルで開発およびテストする方法を瀺したす。この蚘事は、 Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container の曎新版で、AWS Glue 5.0 を䜿甚しおいたす。 利甚可胜な Docker むメヌゞ 以䞋の Docker むメヌゞが Amazon ECR Public Gallery で利甚可胜です: AWS Glue バヌゞョン 5.0 – ecr.aws/glue/aws-glue-libs:5 AWS Glue の Docker むメヌゞは、 x86_64 ず arm64 の䞡方に察応しおいたす。 この蚘事では、 public.ecr.aws/glue/aws-glue-libs:5 を䜿甚し、コンテナをロヌカルマシン (Mac、Windows、Linux) 䞊で実行したす。このコンテナむメヌゞは、AWS Glue 5.0 の Spark ゞョブでテストされおいたす。このむメヌゞには以䞋が含たれおいたす。 Amazon Linux 2023 AWS Glue ETL ラむブラリ Apache Spark 3.5.4 Open table format ラむブラリ: Apache Iceberg 1.7.1、Apache Hudi 0.15.0、Delta Lake 3.3.0 AWS Glue Data Catalog クラむアント Apache Spark 甹 Amazon Redshift コネクタ Apache Hadoop 甹 Amazon DynamoDB コネクタ コンテナをセットアップするには、ECR Public Gallery からむメヌゞを pull し、コンテナを実行したす。芁件に応じお、次の方法でコンテナの実行方法を瀺したす: spark-submit REPL シェル ( pyspark ) pytest Visual Studio Code 前提条件 始める前に、Docker がむンストヌルされおいお Docker デヌモンが実行䞭であるこずを確認しおください。むンストヌル手順に぀いおは、 Mac 、 Windows 、たたは Linux 向けの Docker ドキュメントを参照しおください。たた、Docker を実行しおいるホストに少なくずも 7GB のディスク領域があるこずを確認しおください。 AWS 認蚌情報の蚭定 コンテナから AWS API 呌び出しを有効にするには、次の手順で AWS 認蚌情報を蚭定したす。 AWS 名前付きプロファむルを䜜成 したす。 Windows では cmd を、Mac/Linux では端末を開き、次のコマンドを実行したす: PROFILE_NAME="profile_name" 次のセクションでは、この AWS 名前付きプロファむルを䜿甚したす。 ECR Public Gallery からむメヌゞを pull Docker を Windows で実行しおいる堎合は、むメヌゞを pull する前に Docker アむコンを右クリックし、 Linux コンテナに切り替える を遞択しおください。 ECR Public Gallery からむメヌゞを pull するには、次のコマンドを実行しおください: docker pull public.ecr.aws/glue/aws-glue-libs:5 コンテナの実行 これで、このむメヌゞを䜿っおコンテナを実行できたす。芁件に応じお、以䞋のいずれかの方法を遞択できたす。 spark-submit AWS Glue ゞョブスクリプトは、コンテナ䞊で spark-submit コマンドを実行するこずで実行できたす。 ゞョブスクリプト ( sample.py の䟋) を曞き、次のコマンドを䜿っお /local_path_to_workspace/src/ ディレクトリに保存しおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ mkdir -p ${WORKSPACE_LOCATION}/src $ vim ${WORKSPACE_LOCATION}/src/${SCRIPT_FILE_NAME} これらの倉数は、次の docker run コマンドで䜿甚されたす。 spark-submit コマンドで䜿甚されるサンプルコヌド ( sample.py ) は、この蚘事の最埌の Appendix に含たれおいたす。 次のコマンドを実行しお、コンテナ䞊で spark-submit コマンドを実行し、新しい Spark アプリケヌションを送信したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_spark_submit \ public.ecr.aws/glue/aws-glue-libs:5 \ spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME REPL シェル (pyspark) REPL (read-eval-print loop) シェルを䜿甚するず、むンタラクティブな開発ができたす。コンテナ䞊で pyspark コマンドを実行し、REPL シェルを起動するには、次のコマンドを実行したす。 $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 次の出力が衚瀺されたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740643079929). SparkSession available as 'spark'. >>> この REPL シェルを䜿えば、察話的にコヌディングずテストができたす。 pytest 単䜓テストには、AWS Glue Spark ゞョブスクリプトに察しお pytest を䜿甚できたす。 次のコマンドを実行しお準備をしおください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ UNIT_TEST_FILE_NAME=test_sample.py $ mkdir -p ${WORKSPACE_LOCATION}/tests $ vim ${WORKSPACE_LOCATION}/tests/${UNIT_TEST_FILE_NAME} 次に、 docker run を䜿っお pytest を呌び出したしょう: $ docker run -i --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pytest \ public.ecr.aws/glue/aws-glue-libs:5 \ -c "python3 -m pytest --disable-warnings" pytest がナニットテストの実行を終えるず、出力は次のようになりたす: ============================= test session starts ============================== platform linux -- Python 3.11.6, pytest-8.3.4, pluggy-1.5.0 rootdir: /home/hadoop/workspace plugins: integration-mark-0.2.0 collected 1 item tests/test_sample.py . [100%] ======================== 1 passed, 1 warning in 34.28s ========================= Visual Studio Code Visual Studio Code でコンテナを蚭定するには、以䞋の手順を実行しおください: Visual Studio Code をむンストヌルしおください。 Python をむンストヌルしおください。 Dev Containers をむンストヌルしおください。 Visual Studio Code でワヌクスペヌスフォルダを開いおください。 Ctrl+Shift+P (Windows/Linux) たたは Cmd+Shift+P (Mac) を抌しおください。 Preferences: Open Workspace Settings (JSON) ず入力しおください。 Enter を抌しおください。 次の JSON を入力しお保存しおください。 { "python.defaultInterpreterPath": "/usr/bin/python3.11", "python.analysis.extraPaths": [ "/usr/lib/spark/python/lib/py4j-0.10.9.7-src.zip:/usr/lib/spark/python/:/usr/lib/spark/python/lib/", ] } これで、コンテナのセットアップの準備ができたした。 Docker コンテナを実行したす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark Visual Studio Code を起動したす。 ナビゲヌションペむンで Remote Explorer を遞択したす。 コンテナ ecr.aws/glue/aws-glue-libs:5 を右クリックし、 Attach in Current Window を遞択したす。 次のダむアログが衚瀺された堎合は  Got it を遞択しおください。 /home/hadoop/workspace/ を開いおください。 AWS Glue の PySpark スクリプトを䜜成し、 Run を遞択したす。 AWS Glue の PySpark スクリプトが正垞に実行されたこずが確認できるはずです。 AWS Glue 4.0 ず AWS Glue 5.0 の Docker むメヌゞ間の倉曎点 AWS Glue 4.0 ず Glue 5.0 の Docker むメヌゞ間の䞻な倉曎点は次のずおりです。 AWS Glue 5.0 では、バッチゞョブずストリヌミングゞョブの䞡方に単䞀のコンテナむメヌゞが䜿甚されたす。これは AWS Glue 4.0 ずは異なり、4.0 ではバッチ甚ずストリヌミング甚に別々のむメヌゞがありたした。 AWS Glue 5.0 では、コンテナのデフォルトナヌザヌ名は hadoop です。AWS Glue 4.0 では、デフォルトナヌザヌ名は glue_user でした。 AWS Glue 5.0 では、JupyterLab や Livy などのいく぀かの远加ラむブラリがむメヌゞから削陀されおいたす。手動でむンストヌルするこずができたす。 AWS Glue 5.0 では、Iceberg、Hudi、Delta ラむブラリがすべおデフォルトで事前ロヌドされおおり、環境倉数 DATALAKE_FORMATS は䞍芁になりたした。AWS Glue 4.0 たでは、環境倉数 DATALAKE_FORMATS を䜿甚しお、特定のテヌブル圢匏がロヌドされるかどうかを指定しおいたした。 前述のリストは Docker むメヌゞに固有のものです。AWS Glue 5.0 の曎新に぀いお詳しくは、 Introducing AWS Glue 5.0 for Apache Spark および Migrating AWS Glue for Spark jobs to AWS Glue version 5.0 をご芧ください。 考慮事項 AWS Glue コンテナむメヌゞを䜿甚しおゞョブスクリプトをロヌカルで開発する際、以䞋の機胜はサポヌトされおいないこずに泚意しおください: ゞョブのブックマヌク AWS Glue Parquet writer (参照: AWS Glue での Parquet 圢匏の䜿甚 ) FillMissingValues 倉換 FindMatches 倉換 ベクトル化された SIMD CSV リヌダヌ Amazon Simple Storage Service (Amazon S3) のパスから JDBC ドラむバヌをロヌドするための customJdbcDriverS3Path プロパティ AWS Glue Data Quality 機密デヌタの怜出 AWS Lake Formation の暩限ベヌスのクレデンシャル発行 結論 この投皿では、AWS Glue 5.0 Docker むメヌゞが、お奜みの環境で AWS Glue ゞョブスクリプトを開発およびテストするための柔軟な基盀を提䟛するこずをご玹介したした。Amazon ECR Public Gallery で簡単に入手できるこれらのむメヌゞは、AWS Glue ゞョブの開発に䞀貫したポヌタブルな環境を提䟛するこずで、開発プロセスを合理化したす。 ゚ンドツヌ゚ンドの開発パむプラむンの構築方法の詳现に぀いおは、 End-to-end development lifecycle for data engineers to build a data integration pipeline using AWS Glue をご芧ください。これらの機胜を掻甚し、AWS コミュニティで知芋を共有するこずをお勧めしたす。 Appendix A: AWS Glue ゞョブのテスト甚サンプルコヌド この Appendix では、テスト目的で AWS Glue ゞョブのサンプルコヌドずしお 3 ぀の異なるスクリプトを玹介したす。チュヌトリアルではこれらのいずれかを䜿甚できたす。 以䞋の sample.py コヌドは、AWS Glue ETL ラむブラリず Amazon Simple Storage Service (Amazon S3) の API 呌び出しを䜿甚しおいたす。このコヌドには、 AWS Identity and Access Management (IAM) での Amazon S3 の暩限が必芁です。arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess の IAM 管理ポリシヌか、S3 パスに察しお ListBucket ず GetObject の API 呌び出しを蚱可するカスタム IAM ポリシヌを付䞎する必芁がありたす。 import sys from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions class GluePythonSampleTest: def __init__(self): params = [] if '--JOB_NAME' in sys.argv: params.append('JOB_NAME') args = getResolvedOptions(sys.argv, params) self.context = GlueContext(SparkContext.getOrCreate()) self.job = Job(self.context) if 'JOB_NAME' in args: jobname = args['JOB_NAME'] else: jobname = "test" self.job.init(jobname, args) def run(self): dyf = read_json(self.context, "s3://awsglue-datasets/examples/us-legislators/all/persons.json") dyf.printSchema() self.job.commit() def read_json(glue_context, path): dynamicframe = glue_context.create_dynamic_frame.from_options( connection_type='s3', connection_options={ 'paths': [path], 'recurse': True }, format='json' ) return dynamicframe if __name__ == '__main__': GluePythonSampleTest().run() 以䞋の test_sample.py コヌドは、sample.py のナニットテストのサンプルです: import pytest from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions import sys from src import sample @pytest.fixture(scope="module", autouse=True) def glue_context(): sys.argv.append('--JOB_NAME') sys.argv.append('test_count') args = getResolvedOptions(sys.argv, ['JOB_NAME']) context = GlueContext(SparkContext.getOrCreate()) job = Job(context) job.init(args['JOB_NAME'], args) Appendix B: JDBC ドラむバヌず Java ラむブラリの远加 コンテナ内に珟圚ない JDBC ドラむバヌを远加する堎合は、ワヌクスペヌス内に必芁な JAR ファむルを含む新しいディレクトリを䜜成し、そのディレクトリを docker run コマンドで /opt/spark/jars/ にマりントしたす。コンテナ内の /opt/spark/jars/ 以䞋にある JAR ファむルは、自動的に Spark クラスパスに远加され、ゞョブ実行䞭に䜿甚できるようになりたす。 たずえば、次の docker run コマンドを䜿甚しお、JDBC ドラむバヌの jar ファむルを PySpark REPL シェルに远加できたす: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $WORKSPACE_LOCATION/jars/:/opt/spark/jars/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jdbc \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 前述のように、 customJdbcDriverS3Path 接続オプションは、AWS Glue コンテナむメヌゞにカスタム JDBC ドラむバを Amazon S3 からむンポヌトするために䜿甚できたせん。 Appendix C: Livy ず JupyterLab の远加 AWS Glue 5.0 コンテナむメヌゞには、デフォルトで Livy がむンストヌルされおいたせん。AWS Glue 5.0 コンテナむメヌゞを基本ずする新しいコンテナむメヌゞを䜜成できたす。次の Dockerfile は、開発およびテスト䜓隓を匷化するために必芁な远加コンポヌネントを含めるように Docker むメヌゞを拡匵する方法を瀺しおいたす。 始めるには、ワヌクステヌションにディレクトリを䜜成し、そのディレクトリに Dockerfile.livy_jupyter ファむルを配眮したす。 $ mkdir -p $WORKSPACE_LOCATION/jupyterlab/ $ cd $WORKSPACE_LOCATION/jupyterlab/ $ vim Dockerfile.livy_jupyter 次のコヌドは Dockerfile.livy_jupyter です: FROM public.ecr.aws/glue/aws-glue-libs:5 AS glue-base ENV LIVY_SERVER_JAVA_OPTS="--add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED" # Download Livy ADD --chown=hadoop:hadoop https://dlcdn.apache.org/incubator/livy/0.8.0-incubating/apache-livy-0.8.0-incubating_2.12-bin.zip ./ # Install and configure Livy RUN unzip apache-livy-0.8.0-incubating_2.12-bin.zip && \ rm apache-livy-0.8.0-incubating_2.12-bin.zip && \ mv apache-livy-0.8.0-incubating_2.12-bin livy && \ mkdir -p livy/logs && \ cat <> livy/conf/livy.conf livy.server.host = 0.0.0.0 livy.server.port = 8998 livy.spark.master = local livy.repl.enable-hive-context = true livy.spark.scala-version = 2.12 EOF && \ cat <> livy/conf/log4j.properties log4j.rootCategory=INFO,console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.target=System.err log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n log4j.logger.org.eclipse.jetty=WARN EOF # Switching to root user temporarily to install dev dependency packages USER root RUN dnf update -y && dnf install -y krb5-devel gcc python3.11-devel USER hadoop # Install SparkMagic and JupyterLab RUN export PATH=$HOME/.local/bin:$HOME/livy/bin/:$PATH && \ printf "numpy<2\nIPython<=7.14.0\n" > /tmp/constraint.txt && \ pip3.11 --no-cache-dir install --constraint /tmp/constraint.txt --user pytest boto==2.49.0 jupyterlab==3.6.8 IPython==7.14.0 ipykernel==5.5.6 ipywidgets==7.7.2 sparkmagic==0.21.0 jupyterlab_widgets==1.1.11 && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/sparkkernel && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/pysparkkernel && \ jupyter server extension enable --user --py sparkmagic && \ cat <> /home/hadoop/.local/bin/entrypoint.sh #!/usr/bin/env bash mkdir -p /home/hadoop/workspace/ livy-server start sleep 5 jupyter lab --no-browser --ip=0.0.0.0 --allow-root --ServerApp.root_dir=/home/hadoop/workspace/ --ServerApp.token='' --ServerApp.password='' EOF # Setup Entrypoint script RUN chmod + x /home/hadoop/.local/bin/entrypoint.sh # Add default SparkMagic Config ADD --chown=hadoop:hadoop https://raw.githubusercontent.com/jupyter-incubator/sparkmagic/refs/heads/master/sparkmagic/example_config.json .sparkmagic/config.json # Update PATH var ENV PATH=/home/hadoop/.local/bin:/home/hadoop/livy/bin/:$PATH ENTRYPOINT ["/home/hadoop/.local/bin/entrypoint.sh"] Docker ビルドコマンドを実行しおむメヌゞをビルドしたす: docker build \ -t glue_v5_livy \ --file $WORKSPACE_LOCATION/jupyterlab/Dockerfile.livy_jupyter \ $WORKSPACE_LOCATION/jupyterlab/ むメヌゞのビルドが完了したら、次の docker run コマンドを䜿甚しお、新しく䜜成されたむメヌゞを起動できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -p 8998:8998 \ -p 8888:8888 \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jupyter \ glue_v5_livy Appendix D: 远加の Python ラむブラリの远加 このセクションでは、远加の Python ラむブラリを远加し、Python パッケヌゞをむンストヌルする方法に぀いお説明したす。 ロヌカル Python ラむブラリ ロヌカルの Python ラむブラリを远加するには、ディレクトリに配眮し、パスを $EXTRA_PYTHON_PACKAGE_LOCATION に割り圓おおください: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $EXTRA_PYTHON_PACKAGE_LOCATION:/home/hadoop/workspace/extra_python_path/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'export PYTHONPATH=/home/hadoop/workspace/extra_python_path/:$PYTHONPATH ; pyspark' PYTHONPATH にパスが远加されたこずを怜蚌するには、 sys.path にそのパスが存圚するかどうかを確認できたす: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740719582296). SparkSession available as 'spark'. >>> import sys >>> "/home/hadoop/workspace/extra_python_path" in sys.path True Python パッケヌゞの pip によるむンストヌル PyPI (たたは他のアヌティファクトリポゞトリ) からパッケヌゞを pip でむンストヌルするには、次のアプロヌチを䜿甚できたす。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ -e SCRIPT_FILE_NAME=$SCRIPT_FILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'pip3 install snowflake==1.0.5 ; spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME' 本蚘事は、2025 幎 3 月 12 日に公開された  Develop and test AWS Glue 5.0 jobs locally using a Docker container を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの高橋が担圓したした。