TECH PLAY

AWS

AWS の技術ブログ

å…š3418ä»¶

みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。盎前のご案内になりたすが、3 月 25 日氎に「 AWS での Claude Code の買い方・䜿い方 」ずいう Claude Code を AWS 䞊で掻甚する手段や買い方をご玹介するむベントが開催されたす。たた翌日の 3 月 26 日朚には「 Amazon Quick で倉わる業務の珟堎 — 掻甚䌁業・AWS瀟員による事䟋玹介 」が開催されたす。ご興味がある方はぜひご参加ください 「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き募集䞭ですのでよろしくお願いしたす。 それでは 3月 9 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI事䟋ブログ「 寄皿 䞉菱電機が挑む補造業の商談倉革 – AWS で実珟した商談支揎サヌビス「Memory Tech」 」 䞉菱電機 名叀屋補䜜所が、補造業の商談珟堎で発生する口頭コミュニケヌションの認識霟霬ずいう課題を解決するために、AI を掻甚した商談支揎サヌビス「Memory Tech」を AWS 䞊で開発した事䟋が玹介されおいたす。Memory Tech は Web ブラりザやスマヌトフォンで商談の音声を録音するだけで、Amazon Bedrock の生成 AI が 2 分以内に構造化された議事録を自動生成するサヌビスで、AWS Amplify Gen 2 を䞭栞ずしたサヌバヌレスアヌキテクチャにより、少人数のチヌムでも迅速な開発ず 1,000 名超のナヌザヌに察応する安定運甚を実珟しおいたす。生成 AI を掻甚するナヌザヌにずっおは、Amazon Bedrock 䞊で Anthropic Claude ず Amazon Nova を甚途に応じお䜿い分けるこずでコスト最適化ず応答速床を䞡立しおおり、珟堎の業務習慣を倉えずに AI の力で業務改善を図る実践的な掻甚事䟋ずしお参考になりたす。 AWS生成AI事䟋ブログ「 【寄皿】「12時間で PoC が完成」― サミット株匏䌚瀟の情報システム郚門が AI コヌディングアシスタント Kiro で実珟した、圧倒的スピヌドの内補開発 」 スヌパヌマヌケットチェヌンのサミット株匏䌚瀟が、AI コヌディングアシスタント「Kiro」を掻甚しお情報システム郚門による内補開発を加速させた事䟋が玹介されおいたす。埓来であれば倖郚委蚗で 3 か月・数癟䞇円芏暡のコストがかかる店舗デヌタ分析ダッシュボヌドの PoC を、Kiro の Spec-driven Development 機胜を掻甚しお䞀人の担圓者がわずか 12 時間で完成させるなど、開発スピヌドの倧幅な向䞊を実珟したした。生成 AI を掻甚した開発に取り組むナヌザヌにずっおは、セッション情報の管理やステアリングの蚭定ずいった Kiro を効果的に䜿いこなすための実践的なノりハりに加え、レガシヌシステムのリバヌス゚ンゞニアリングやパヌトナヌずの協業モデルの倉革など、AI コヌディングアシスタントの掻甚範囲を広げるヒントが埗られる内容です。 ブログ蚘事「 「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」キックオフむベントを開催したした 」 AWS ゞャパンが、フィゞカル AI の開発を支揎する玄 6 ヶ月間のプログラムのキックオフむベントを開催し、採択䌁業によるピッチや Amazon Robotics の事䟋玹介が行われた様子を報告しおいたす。このプログラムでは、゜リュヌションアヌキテクトによる技術支揎、AWS クレゞットの提䟛に加え、プロトタむピングを専門ずする Prototyping & Cloud EngineeringPACEチヌムが開発する Physical AI Scaffolding KitPASKによるトレヌニング環境のサンプル提䟛など、デヌタ収集からモデル孊習・実機デプロむたでの䞀連のパむプラむン構築を包括的にサポヌトしたす。生成 AI を掻甚するナヌザヌにずっおは、Vision-Language-ActionVLAモデルなどのロボット基盀モデル開発を Amazon SageMaker HyperPod 䞊で実行する具䜓的なアプロヌチや、日本のものづくりの匷みず生成 AI を融合させるフィゞカル AI ゚コシステムの最新動向を知るこずができる内容です。 ブログ蚘事「 月刊 AWS 補造 2026幎3月号 」 今月の月刊 AWS 補造では「Agentic AI × 補造業」を特集しおおり、BMW Group が Amazon Bedrock AgentCore ず Strands Agents を掻甚しおペタバむト芏暡のデヌタからむンサむトを抜出する品質管理の事䟋や、Amazon Bedrock AgentCore による調達ワヌクフロヌの自動化、メック株匏䌚瀟が Amazon Bedrock AgentCore Runtime ず Amazon S3 Vectors で研究業務を効率化した事䟋など、補造業の各領域で Agentic AI を実践的に掻甚するコンテンツが充実しおいたす。さらに、Toyota Motor Europe が Amazon Bedrock でレガシヌメむンフレヌムのドキュメント自動生成に取り組んだ事䟋や、䞉菱電機が Kiro ず GitLab で開発ワヌクフロヌを暙準化した事䟋など、生成 AI を掻甚した補造業の業務改善事䟋も倚数玹介されおいたす。補造業に関わる方にずっお、生成 AI の具䜓的な掻甚パタヌンをたずめお把握できる内容ですので、ぜひご芧ください。 ブログ蚘事「 ゚ンタヌプラむズガバナンスMCP サヌバヌずモデルの制埡 」 AI コヌディングアシスタント「Kiro」に、゚ンタヌプラむズ向けの 2 ぀の新しいガバナンス機胜がリリヌスされたした。1 ぀目は MCP サヌバヌレゞストリで、管理者が承認枈みの MCP サヌバヌを JSON 圢匏の蚱可リストずしお定矩し、開発者が接続できるサヌバヌを䞀元管理できるようになりたす。2 ぀目はモデルガバナンス機胜で、組織内の開発者が利甚できる AI モデルを管理者が制埡でき、特にデヌタレゞデンシヌ芁件がある堎合にグロヌバルクロスリヌゞョン掚論を䜿甚する実隓的モデルを無効化するずいった察応が可胜になりたす。生成 AI を掻甚した開発を組織的に掚進するナヌザヌにずっおは、セキュリティ・コンプラむアンス芁件を満たしながら AI コヌディングツヌルの導入を拡倧するための具䜓的なアプロヌチずしお参考になる内容です。 サヌビスアップデヌト Kiro IDE 0.11 のリリヌス Kiro IDE 0.11 がリリヌスされたした。゚ンタヌプラむズチヌム向けに MCP サヌバヌアクセスずモデル利甚のガバナンス機胜が远加され、管理者が承認枈みの MCP サヌバヌや利甚可胜な AI モデルを䞀元管理できるようになりたした。たた、チャットにドキュメント添付機胜が远加され、PDF、CSV、DOC、XLSX、HTML、Markdown など倚様なフォヌマットのファむルをチャット入力にドラッグペヌストしお、1 メッセヌゞあたり最倧 5 ファむルたでテキストや画像ず組み合わせお AI に読み蟌たせるこずができたす。生成 AI を掻甚した開発に取り組むナヌザヌにずっおは、ドキュメントを盎接チャットに枡しお内容を掚論させられるようになったこずで、仕様曞やデヌタファむルを参照しながらのコヌディング䜜業がより効率的になるアップデヌトです。 AI アシスタントによる構成管理を実珟する新しい LZA MCP サヌバヌ Landing Zone Accelerator on AWSLZAの構成管理を AI アシスタントずの自然蚀語の察話で行える MCP サヌバヌがオヌプン゜ヌスずしお公開されたした。この LZA MCP サヌバヌは 20 皮類の専甚ツヌルを備えおおり、耇数の LZA バヌゞョンにたたがるドキュメント怜玢、構成管理、パむプラむン監芖、デプロむ倱敗時の原因分析ずいった、これたで手䜜業で時間のかかっおいた䜜業を効率化できたす。Kiro、Amazon Q Developer、Claude Code などの IDE ず互換性のあるコンテナ化された MCP ゚ンドポむントずしお動䜜するため、生成 AI を掻甚した開発環境を構築しおいるナヌザヌにずっおは、マルチアカりント環境のガバナンス蚭定を自然蚀語で察話しながら管理できる実甚的なツヌルずしお掻甚が期埅できたす。 Amazon Bedrock AgentCore Memory が長期メモリのストリヌミング通知をサポヌト Amazon Bedrock AgentCore Memory に、長期メモリのストリヌミング通知機胜が远加されたした。長期メモリぱヌゞェントずのやり取りからむンサむトを抜出し、次回以降のむンタラクションでパヌ゜ナラむズされた䜓隓を提䟛する機胜ですが、これたでメモリの倉曎を怜知するにはポヌリング凊理を自前で実装する必芁がありたした。今回のアップデヌトにより、メモリレコヌドの䜜成・倉曎時に Amazon Kinesis ぞプッシュ通知がストリヌミングされるようになり、埌続のワヌクフロヌ起動やアプリケヌション状態の曎新、メモリ倉曎の監査を自動化できるようになりたす。生成 AI ゚ヌゞェントを開発するナヌザヌにずっおは、ポヌリングロゞックの実装が䞍芁になるこずでアヌキテクチャが簡玠化され、よりリアルタむム性の高いパヌ゜ナラむズ䜓隓の構築が可胜になるアップデヌトです。本機胜は東京リヌゞョンを含む 15 の AWS リヌゞョンで利甚可胜です。 Amazon Bedrock が初回トヌクンレむテンシヌずクォヌタ消費のオブザヌバビリティをサポヌト Amazon Bedrock に 2 ぀の新しい Amazon CloudWatch メトリクスが远加されたした。TimeToFirstToken はストリヌミング API でリク゚スト送信から最初のトヌクン受信たでのレむテンシヌを枬定するメトリクスで、クラむアント偎の実装なしにレむテンシヌ劣化の監芖や SLA ベヌスラむンの蚭定が可胜になりたす。EstimatedTPMQuotaUsage はキャッシュ曞き蟌みトヌクンや出力バヌンダりン乗数を含む Tokens Per MinuteTPMのクォヌタ消費量を远跡するメトリクスで、クォヌタ䞊限に達する前にアラヌムを蚭定しおレヌト制限を事前に回避できたす。生成 AI アプリケヌションを運甚するナヌザヌにずっおは、远加費甚や API 倉曎なしに Amazon CloudWatch で掚論パフォヌマンスずクォヌタ䜿甚状況を可芖化できるようになり、本番環境の安定運甚に圹立぀アップデヌトです。 Amazon Connect が AI を掻甚したマネヌゞャヌアシスタント機胜を発衚プレビュヌ Amazon Connect に、コンタクトセンタヌのマネヌゞャヌが自然蚀語で業務に関する質問をするず即座に回答を埗られる、AI を掻甚したアシスタント機胜がプレビュヌずしお発衚されたした。゚ヌゞェントのスケゞュヌリング、セルフサヌビス䜓隓、パフォヌマンス評䟡を含む 150 以䞊の Amazon Connect メトリクスに察しお自然蚀語でク゚リでき、これたで手䜜業で数時間かかっおいたデヌタ収集を数秒で完了できるようになりたす。さらに、サヌビスレベル目暙の達成が危ぶたれるキュヌの特定や具䜓的な改善アクションの提案など、根本原因の蚺断も行えるため、生成 AI を掻甚しおカスタマヌサヌビスの品質向䞊に取り組むナヌザヌにずっお、運甚の意思決定を加速させる実甚的なアップデヌトです。 Amazon Quick Suite がチャットパヌ゜ナラむれヌションのためのナヌザヌ蚭定機胜をリリヌス Amazon Quick Suite に、チャット䜓隓をナヌザヌごずにカスタマむズできるナヌザヌ蚭定User Preferences機胜が远加されたした。チャットパネルのレむアりト蚭定、デフォルトのチャット゚ヌゞェントやナレッゞスコヌプの事前遞択に加え、自分の呌び名や業務の泚力領域を登録するこずで、AI がその情報をもずにレスポンスをパヌ゜ナラむズしおくれるようになりたす。これたでセッションをたたいでチャット蚭定や゚ヌゞェント遞択、個人のコンテキストを保持する手段がなかったため、生成 AI を業務で日垞的に掻甚するナヌザヌにずっおは、毎回の蚭定の手間が省かれ、最初のやり取りからパヌ゜ナラむズされた䜓隓が埗られるようになる䟿利なアップデヌトです。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎 (Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近倩ぷらを(食べるのではなく)揚げるほうにハマっおたす。
みなさん、こんにちは。Amazon Connect ゜リュヌションアヌキテクトの坂田です。 2026幎2月に発衚された Amazon Connect のアップデヌトをたずめおお届けしたす。今月は、゚ヌゞェントの通話品質を向䞊させる音声匷化機胜や、タスクの AI 抂芁・掚奚アクション、ダッシュボヌドのきめ现かいアクセス制埡、Amazon Connect Cases の耇数の機胜拡匵、スケゞュヌリングやアりトバりンドキャンペヌンの運甚改善など、合蚈 13件のアップデヌトが発衚されたした。加えお、AWS Contact Center Blog では AI ゚ヌゞェントの掻甚やコンタクトセンタヌ移行のベストプラクティスなど 4件のブログ蚘事が公開されおいたす。以䞋、カテゎリごずにご玹介したす。 目次 泚目のアップデヌトに぀いお 2026幎2月のアップデヌト䞀芧 ゚ヌゞェント䜓隓の向䞊 AI・分析機胜の匷化 Amazon Connect Cases の機胜匷化 スケゞュヌリングずアりトバりンドキャンペヌン AWS Contact Center Blog のご玹介 たずめ 1. 泚目のアップデヌトに぀いお 今月の泚目アップデヌトは以䞋の 3぀です! 泚目 1: Amazon Connect が隒音環境向けのオヌディオ拡匵機胜を導入 ひず぀めは、2月4日に発衚された Audio Enhancement 機胜 です。これは、゚ヌゞェント偎の音声をリアルタむムで凊理し、゚ンドカスタマヌが聞く音声品質を向䞊させるものです。コンタクトセンタヌではしばしば、他の゚ヌゞェントの䌚話やネットワヌク機噚から発せられる隒音など、呚囲の雑音が気になるこずがありたす。今回のアップデヌトは、こうした環境で業務を行う゚ヌゞェントにずっお特に有甚な機胜です。 この機胜には 2぀のモヌド が甚意されおいたす。 ノむズ抑制Noise Suppressionモヌド : バックグラりンドノむズを䜎枛したす。有線・無線ヘッドセット、ヘッドセットなしのいずれの構成でも利甚可胜です。 音声分離Voice Isolationモヌド : ノむズ䜎枛に加え、コンタクトセンタヌ内で耇数の人が話しおいる環境でも゚ヌゞェントの音声を分離したす。有線ヘッドセット䜿甚時のみ掚奚されたす。 有効化方法 : 管理者がナヌザヌ管理画面から察象゚ヌゞェントの Phone type を Soft phone に蚭定し、Audio Enhancement のモヌドを遞択したす。蚭定倉曎は次の通話から適甚されたす。セキュリティプロファむルの「コンタクトコントロヌルパネル (CCP)」暩限の「オヌディオデバむスの蚭定」を有効にするず、゚ヌゞェント自身が CCP 䞊でモヌドを切り替えるこずも可胜です。 API サポヌト : CreateUser / UpdateUserConfig API の VoiceEnhancementConfigs パラメヌタ、Amazon Connect Streams API の agent.setVoiceEnhancementMode() 、ConnectSDK の Voice API に察応しおいたす。 前提条件 : ゜フトフォンナヌザヌのみ察象。最䜎 4コア CPU仮想マシンは 4 vCPUが必芁。VDI 環境ではロヌカルブラりザアクセス方匏のみサポヌトAmazon Connect audio optimization 方匏は非察応。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおの AWS 商甚リヌゞョン 関連リ゜ヌス : Amazon Connect で゚ヌゞェントのオヌディオ匷化を有効にする 泚目 2: タスクの AI 抂芁ず掚奚アクション 抂芁 : Amazon Connect にタスクの AI 抂芁ず掚奚アクション機胜が远加されたした。゚ヌゞェントがタスクを受け取った際に、AI が過去のアクティビティを芁玄し、次に取るべきアクションを提案したす。䟋えば、オンラむンフォヌムから送信された返金リク゚ストのタスクを受け取った堎合、泚文詳现の確認、返品資栌のチェック、支払い方法の確認ずいった過去のアクティビティが芁玄され、返金を完了するための掚奚ステップが提瀺されたす。この機胜を有効にするには、タスクが゚ヌゞェントに割り圓おられる前のフロヌに コネクトアシスタント フロヌブロックを远加したす。ナレッゞベヌスを远加するこずで、掚奚内容をさらにガむドするこずも可胜です。 利甚可胜リヌゞョン : Amazon Connect のリアルタむム゚ヌゞェントアシスタンスが利甚可胜なすべおの AWS リヌゞョン 関連リ゜ヌス Amazon Connect のフロヌブロック: Connect Assistant 泚目 3: Agent Workspace での通知機胜 抂芁 : Amazon Connect Agent Workspace に通知機胜が远加されたした。ワヌクスペヌスのヘッダヌに通知が衚瀺され、どのペヌゞからでも確認できるため、゚ヌゞェントやビゞネスナヌザヌは珟圚の䜜業を䞭断するこずなく、緊急のアップデヌトやポリシヌ倉曎、アクションアむテムなどの重芁な情報を受け取るこずができたす。新しい通知 API を䜿甚するこずで、組織内の特定のオヌディ゚ンスに察しおプログラムからタヌゲットメッセヌゞを送信するこずが可胜です。パブリック API および AWS CloudFormation にも察応しおいたす。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン 関連リ゜ヌス : ワヌクスペヌスヘッダヌの通知機胜 通知の蚭定方法 通知の䜜成・送信はすべお API 経由で行いたす。Amazon Connect の Notifications API ずしお以䞋の8぀のアクションが提䟛されおいたす。 CreateNotification : 新しい通知を䜜成し、指定した受信者に配信したす UpdateNotificationContent : 既存の通知内容を曎新したす DeleteNotification : 通知を削陀したす DescribeNotification / ListNotifications / SearchNotifications : 通知の詳现取埗・䞀芧・怜玢を行いたす ListUserNotifications : 特定ナヌザヌの通知䞀芧を取埗したす UpdateUserNotificationStatus : ナヌザヌの通知ステヌタス既読/未読を曎新したす 通知を䜜成する際の䞻なパラメヌタは以䞋の通りです。 Content : ロケヌルコヌド ja_JP 、 en_US など 11蚀語をキヌずしたマップ圢匏で、各蚀語の通知テキストを指定したす1蚀語あたり最倧 500文字。リンクの埋め蟌みにも察応しおいたす。 Recipients : 受信者のナヌザヌ ARN を配列で指定したす最倧 200件。むンスタンス ARN を指定するず、むンスタンス内の党ナヌザヌに送信できたす。 Priority : HIGH たたは LOW を指定したす。高優先床の通知は䜎優先床より䞊に衚瀺されたす。 ExpiresAt : 通知の有効期限をタむムスタンプで指定したす。未指定の堎合、デフォルトで䜜成から1週間埌に自動的に非衚瀺になりたす。 Tags : タグベヌスアクセス制埡TBACに䜿甚するタグを付䞎できたす。 アクセス制埡 通知の受信には远加の暩限は䞍芁ですが、通知の䜜成・線集・削陀・送信枈み通知の閲芧には API 暩限が必芁です。タグベヌスアクセス制埡TBACにより、管理者は自身に割り圓おられたタグず䞀臎する通知のみを管理でき、䞀臎するタグを持぀ナヌザヌにのみ送信できたす。階局ベヌスアクセス制埡HBACでは、管理者は自身の階局レベル以䞋のナヌザヌにのみ通知を送信できたす。 2. 2026幎2月のアップデヌト䞀芧 2.1. ゚ヌゞェント䜓隓の向䞊 ゚ヌゞェントパフォヌマンス評䟡の異議申し立おワヌクフロヌ 2026幎2月3日 抂芁 : ゚ヌゞェントがパフォヌマンス評䟡に察しお異議を申し立おるための統合ワヌクフロヌが远加されたした。゚ヌゞェントは評䟡に同意できない堎合、Connect UI 䞊から理由を添えお異議を申し立おるこずができたす。指定されたマネヌゞャヌには自動メヌル通知が送信され、異議の確認ず解決を行いたす。マネヌゞャヌは異議が申し立おられた評䟡の䞀芧やステヌタスを远跡でき、タむムリヌな解決が可胜です。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおのリヌゞョン 関連リ゜ヌス : 評䟡の異議申し立お Audio Enhancement音声匷化による゚ヌゞェント通話品質の向䞊 2026幎2月4日 泚目 1 を確認しおください! チャット・タスク・Eメヌル・コヌルバックの自動応答Auto-Accept蚭定 2026幎2月5日 抂芁 : チャット、タスク、Eメヌル、コヌルバックの各チャネルに察しお、゚ヌゞェントの自動応答Auto-Acceptを蚭定できるようになりたした。自動応答を有効にするず、着信コンタクトが゚ヌゞェントの手動承認を埅たずに自動的に接続されるため、顧客ぞの迅速な察応が可胜になりたす。これたでこの蚭定はむンバりンド音声通話に察しおのみ利甚可胜でしたが、今回のアップデヌトでチャネルごずに個別に蚭定できるようになりたした。䟋えば、タスクには自動応答を有効にし぀぀、音声通話では無効のたたにするずいった運甚が可胜です。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン 関連リ゜ヌス : 自動応答の有効化 チャネル別の埌凊理ACWタむムアりト蚭定 2026幎2月11日 抂芁 : チャット、タスク、Eメヌル、コヌルバックの各チャネルに察しお、゚ヌゞェントの埌凊理After Contact Workタむムアりトを蚭定できるようになりたした。ACW タむムアりトにより、゚ヌゞェントが埌凊理に費やせる時間を制限し、タむムアりト埌は自動的に察応可胜状態に戻りたす。これは、゚ヌゞェントごず、チャネルごずに異なるタむムアりトを蚭定でき、䟋えばEメヌルには短い ACW タむムアりトを蚭定し぀぀、音声通話には次の顧客察応に備えるためのクヌルダりン時間ずしお長めのタむムアりトを維持するずいった運甚が可胜です。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン 関連リ゜ヌス : ゚ヌゞェントの蚭定 Agent Workspace 内の通知機胜の远加 2026幎2月13日 泚目 3 を確認しおください! 2.2. AI・分析機胜の匷化 音声むンタラクションのテスト・シミュレヌション API 2026幎2月 抂芁 : コンタクトセンタヌの䜓隓をシミュレヌションするテストを構成・実行するための API が远加されたした。発信者の電話番号やカスタマヌプロファむル、通話理由「泚文状況を確認したい」など、期埅される応答「リク゚ストが凊理されたした」など、営業時間倖やキュヌ満杯ずいったビゞネス条件をプログラムで蚭定できたす。CI/CD パむプラむンぞの統合、耇数テストの同時実行、デプロむサむクルの䞀郚ずしおの自動回垰テストが可胜になり、ワヌクフロヌの倉曎を迅速に怜蚌しお本番環境ぞ自信を持っおデプロむできたす。 利甚可胜リヌゞョン : アゞアパシフィックムンバむ、゜りル、シンガポヌル、シドニヌ、東京、アフリカケヌプタりン、欧州フランクフルト、ロンドン、米囜東郚バヌゞニア北郚、米囜西郚オレゎン、カナダ䞭郚 関連リ゜ヌス : Amazon Connect API リファレンス タスクの AI 抂芁ず掚奚アクション 2026幎2月13日 泚目 2 を確認しおください! ダッシュボヌドのきめ现かいアクセス制埡 2026幎2月12日 抂芁 : Amazon Connect ダッシュボヌドにきめ现かいアクセス制埡機胜が远加されたした。リ゜ヌスタグを適甚するこずで、特定の゚ヌゞェント、キュヌ、ルヌティングプロファむルなどのリ゜ヌスに察するメトリクスの衚瀺暩限を制埡できたす。タグを䜿甚しおメトリクスをフィルタリングし、同じタグを共有する゚ヌゞェントやキュヌの集蚈メトリクスを衚瀺するこずも可胜です。䟋えば、゚ヌゞェントに「Department:Customer Service」タグを付䞎するこずで、カスタマヌサヌビスチヌムのマネヌゞャヌのみがダッシュボヌドメトリクスを閲芧できるよう制限できたす。 利甚可胜リヌゞョン : Amazon Connect が提䟛されおいるすべおの AWS 商甚リヌゞョンおよび AWS GovCloud (US-West) 関連リ゜ヌス : ダッシュボヌドのタグベヌスアクセス制埡 2.3. Amazon Connect Cases の機胜匷化 䟝存フィヌルドオプションをマッピングするための CSV アップロヌドをサポヌト 2026幎2月6日 抂芁 : Amazon Connect Cases のケヌスフィヌルドに蚭定する䟝存フィヌルドドロップダりンメニュヌを CSV ファむルのアップロヌドで䞀括蚭定できるようになりたした。䟝存フィヌルドオプションは、カスケヌドドロップダりンメニュヌを䜜成したす。1 ぀のフィヌルド (タヌゲットフィヌルド) で䜿甚可胜な遞択肢は、別のフィヌルド (゜ヌスフィヌルド) で遞択された倀によっお異なりたす。CSV ファむルは「Parent Field Name」「Child Field Name」「Parent Value」「Child Value」の4列フォヌマットで、各行が1぀の芪子関係を衚したす。1぀の CSV ファむルに耇数のフィヌルドペアを含めるこずも可胜です。地理的な階局構造囜 → 郜道府県 → 垂区町村や補品カテゎリの分類カテゎリ → サブカテゎリなど、耇雑な階局デヌタの蚭定䜜業を倧幅に効率化できたす。なお、゜ヌスフィヌルドずタヌゲットフィヌルドはいずれも単䞀遞択型である必芁がありたす。 利甚可胜リヌゞョン : 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、カナダ (䞭郚)、欧州 (フランクフルト、ロンドン)、アゞアパシフィック (゜りル、シンガポヌル、シドニヌ、東京)、アフリカ (ケヌプタりン) 関連リ゜ヌス : 䟝存フィヌルドオプション 䟝存フィヌルドオプションの CSV アップロヌド ケヌステンプレヌトでの耇数行テキストフィヌルドのサポヌト 2026幎2月17日 抂芁 : ケヌステンプレヌトで耇数行テキストフィヌルドがサポヌトされるようになりたした。この新しいフィヌルドタむプは、耇数の段萜に察応しお瞊方向に拡匵されるため、゚ヌゞェントは根本原因分析、取匕の詳现、調査結果などの詳现な自由蚘述ノヌトや構造化デヌタをケヌス内に盎接蚘録できたす。これたでの単䞀行テキストフィヌルドでは蚘録しきれなかった詳现情報を、ケヌスに盎接玐づけお管理できるようになり、ケヌス管理の質が向䞊したす。 利甚可胜リヌゞョン : 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、カナダ (䞭郚)、欧州 (フランクフルト、ロンドン)、アゞアパシフィック (゜りル、シンガポヌル、シドニヌ、東京)、アフリカ (ケヌプタりン) 関連リ゜ヌス : Amazon Connect Cases でケヌスフィヌルドを䜜成する AWS Service Quotas ずの統合 2026幎2月18日 抂芁 : Amazon Connect Cases が AWS Service Quotas に察応したした。管理者は Service Quotas コン゜ヌルから、適甚されおいるクォヌタの確認、䜿甚率のモニタリング、およびクォヌタの匕き䞊げリク゚ストを䞀元的に行えるようになりたした。察象ずなるクォヌタの匕き䞊げリク゚ストは手動介入なしで自動承認されるため、予期しないサヌビス制玄に遭遇するこずなくケヌスワヌクロヌドをスケヌルできたす。 利甚可胜リヌゞョン : 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、カナダ (䞭郚)、欧州 (フランクフルト、ロンドン)、アゞアパシフィック (゜りル、シンガポヌル、シドニヌ、東京)、アフリカ (ケヌプタりン) 関連リ゜ヌス : Amazon Connect Cases のサヌビスクォヌタ 2.4. スケゞュヌリングずアりトバりンドキャンペヌン ドラフトスケゞュヌルでの゚ヌゞェント䌑暇リク゚スト衚瀺 2026幎2月17日 抂芁 : 承認枈みの゚ヌゞェント䌑暇リク゚ストがドラフトスケゞュヌル内に衚瀺されるようになりたした。スケゞュヌル管理者は、特定の日に゚ヌゞェントがスケゞュヌルされなかった理由を容易に確認でき、スケゞュヌルを公開する前にカバレッゞのギャップを特定しお調敎するこずが可胜になりたす。これにより、スケゞュヌル䜜成時の可芖性が向䞊し、人員配眮の最適化に圹立ちたす。 利甚可胜リヌゞョン : Amazon Connect の゚ヌゞェントスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン 関連リ゜ヌス : 䌑暇管理 アりトバりンドキャンペヌンのダむダルモヌド動的切り替え 2026幎2月26日 抂芁 : アりトバりンドキャンペヌンにおけるダむダルモヌドの動的切り替え機胜が発衚されたした。コンタクトセンタヌの管理者は、アクティブなキャンペヌン実行䞭にプレビュヌモヌドず非プレビュヌモヌドプログレッシブダむダルなどを切り替えるこずができたす。埓来はキャンペヌン開始埌にダむダルモヌドを倉曎するにはキャンペヌンの停止ず再起動が必芁でしたが、今回のアップデヌトによりキャンペヌンを䞭断するこずなくリアルタむムで切り替えが可胜になりたした。䟋えば、高優先床のコンタクトに察応する際にプログレッシブダむダルからプレビュヌモヌドに切り替え、远加のコンテキストを確認した埌、通垞のトラフィックパタヌンに戻った際に元のモヌドに埩垰させるずいった運甚が可胜です。 利甚可胜リヌゞョン : 米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、カナダ (䞭郚)、欧州 (フランクフルト、ロンドン)、アゞアパシフィック (゜りル、シンガポヌル、シドニヌ、東京)、アフリカ (ケヌプタりン) 関連リ゜ヌス : アりトバりンドキャンペヌンの蚭定 3. AWS Contact Center Blog のご玹介 2026幎2月には、AWS Contact Center Blog においお Amazon Connect に関連する 4件のブログ蚘事が公開されたした。機胜アップデヌトの発衚ずは別に、AI ゚ヌゞェントの掻甚方法やコンタクトセンタヌ移行のベストプラクティスなど、実践的な知芋が共有されおいたす。 AI ゚ヌゞェントによるハむパヌパヌ゜ナラむれヌション 2026幎2月2日 Amazon Connect Customer Profiles ず Amazon Personalize を組み合わせ、顧客察応䞭にリアルタむムでパヌ゜ナラむズされた商品レコメンデヌションを提䟛する方法を解説しおいたす。「おすすめ商品」「類䌌アむテム」「よく䞀緒に賌入される商品」「人気商品」「トレンド商品」の5぀のレコメンデヌションナヌスケヌスが玹介されおおり、AI ゚ヌゞェントのガヌドレヌルやプロンプトのカスタマむズによるブランド䞀貫性の確保方法も説明されおいたす。さらに、アりトバりンドキャンペヌンを掻甚したプロアクティブな Web 通知の配信に぀いおも觊れられおいたす。 CX 業界予枬 2026 2026幎2月3日 2026幎のカスタマヌ゚クスペリ゚ンスCX業界の展望をたずめた゜ヌトリヌダヌシップ蚘事です。AVOA、Cavell、IDC、Constellation Research などのアナリストの芋解を集玄し、「オヌケストレヌション断片的な AI 導入から統合的なマルチ゚ヌゞェント䜓隓ぞ」「トラストAI ガバナンスフレヌムワヌクの構築」「スケヌルAI 成果の枬定可胜なビゞネスアりトカムぞの転換」の3぀のテヌマで敎理されおいたす。 Amazon Connect ぞの移行ベストプラクティス 2026幎2月26日 既存のコンタクトセンタヌから Amazon Connect ぞの移行における「人」の偎面に焊点を圓おた包括的なガむドです。オペレヌションチヌム゚ヌゞェント、スヌパヌバむザヌ、QA アナリスト、ワヌクフォヌスマネヌゞャヌ、むンフラストラクチャチヌムテレフォニヌ゚ンゞニア、ACD 管理者、ネットワヌクスペシャリスト、アプリケヌションチヌムCX 開発者、゚ヌゞェントデスクトップ開発者、ルヌティング開発者の3カテゎリに分けお、レガシヌロヌルから Amazon Connect ロヌルぞのトレヌニングパスが詳现に解説されおいたす。 Kiro を掻甚した AI ゚ヌゞェント開発の高速化 2026幎2月27日 AI コヌディングアシスタント Kiro を䜿甚しお、15 のバック゚ンド API を統合した Amazon Connect AI ゚ヌゞェントをわずか3日間で構築した事䟋を玹介しおいたす。通垞 2〜3週間かかる POC 開発を倧幅に短瞮し、Kiro によるアヌキテクチャ蚭蚈、Lambda 関数のコヌド生成、CloudWatch ログ分析によるデバッグ、MCP ツヌルスキヌマの䜜成ずいった開発プロセスが解説されおいたす。Amazon Bedrock Agents、AWS Lambda、Amazon DynamoDB、Amazon Bedrock AgentCore Gateway を掻甚した統合パタヌンが瀺されおいたす。 4. たずめ 2026幎2月は、゚ヌゞェント䜓隓の向䞊Audio Enhancement、チャネル別蚭定、Agent Workspace 内の通知機胜、AI・分析機胜の匷化タスクの AI 抂芁・掚奚アクション、ダッシュボヌドのきめ现かいアクセス制埡、Amazon Connect Cases の機胜匷化CSV 䞀括蚭定、耇数行テキスト、Service Quotas 統合、そしおスケゞュヌリングずアりトバりンドキャンペヌンの運甚改善ず、幅広い領域にわたる13件の機胜アップデヌトが発衚されたした。 特に、Audio Enhancement による゚ヌゞェントの通話品質向䞊、タスクの AI 抂芁・掚奚アクションによる゚ヌゞェント生産性の向䞊、そしおアりトバりンドキャンペヌンのダむダルモヌド動的切り替えは、日々のコンタクトセンタヌ運甚に盎接的なメリットをもたらす泚目のアップデヌトです。 たた、AWS Contact Center Blog では、AI ゚ヌゞェントによるハむパヌパヌ゜ナラむれヌション、CX 業界の 2026幎予枬、Amazon Connect ぞの移行ベストプラクティス、Kiro を掻甚した AI ゚ヌゞェント開発の高速化の 4件のブログ蚘事が公開されたした。機胜アップデヌトず合わせお、これらのブログ蚘事もぜひご確認ください。 今埌も最新の Amazon Connect のアップデヌト情報は AWS の What’s New ペヌゞ や Amazon Connect のリリヌスノヌト 、そしお AWS Contact Center Blog で確認できたす。匕き続き最新情報をチェックしおみおください。 シニア スペシャリスト ゜リュヌションアヌキテクト/Amazon Connect, 坂田 陜䞀郎
2026 幎 3 月 12 日、 Amazon Simple Storage Service (Amazon S3) の新機胜を発衚したした。この機胜を䜿甚するず、独自のアカりントのリヌゞョン名前空間に汎甚バケットを䜜成でき、デヌタストレヌゞの芏暡や甚途の拡倧に䌎うバケットの䜜成および管理を簡玠化できたす。耇数の AWS リヌゞョンにたたがる汎甚のバケット名を䜜成するず、垌望するバケット名をい぀でも䜿甚できるこずが保蚌されたす。 この機胜を䜿甚するず、リク゚ストしたバケット名にアカりント固有のサフィックスを远加するこずで、自分のアカりントのリヌゞョナル名前空間に予枬どおりの名前を付けお汎甚バケットを䜜成できたす。たずえば、アカりントのリヌゞョナル名前空間にバケット mybucket-123456789012-us-east-1-an を䜜成できたす。 mybucket は指定したバケット名のプレフィックスです。次に、リク゚ストされたバケット名にアカりントのリヌゞョナルサフィックス -123456789012-us-east-1-an を远加したす。別のアカりントが私のアカりントのサフィックスを䜿甚しおバケットを䜜成しようずするず、そのアカりントのリク゚ストは自動的に拒吊されたす。 セキュリティチヌムは、 AWS Identity and Access Management (AWS IAM) ポリシヌず AWS Organizations サヌビスコントロヌルポリシヌを䜿甚しお、埓業員が新しい s3: x-amz-bucket-namespace 条件キヌを䜿甚しおアカりントのリヌゞョナル名前空間にのみバケットを䜜成するように匷制できたす。これにより、チヌムが組織党䜓でアカりントのリヌゞョナル名前空間を採甚しやすくなりたす。 アカりントのリヌゞョナル名前空間を実際に䜿っお S3 バケットを䜜成する 開始するには、 Amazon S3 コン゜ヌル で [バケットを䜜成] を遞択したす。アカりントのリヌゞョナル名前空間にバケットを䜜成するには、 [アカりントのリヌゞョナル名前空間] を遞択したす。このオプションを遞択するず、アカりントずリヌゞョンに固有の任意の名前でバケットを䜜成できたす。 この蚭定は、グロヌバル名前空間の汎甚バケットず同じ機胜をすべおサポヌトしたす。唯䞀の違いは、アカりントのサフィックスが付いたバケット名を䜿甚できるのはそのアカりントのみであるずいう点です。バケット名のプレフィックスずアカりントのリヌゞョナルサフィックスを合わせた長さは、363 文字以内にする必芁がありたす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお、 x-amz-bucket-namespace: account-regional リク゚ストヘッダヌを指定し、互換性のあるバケット名を指定するこずで、アカりントのリヌゞョナル名前空間のバケットを䜜成できたす。 $ aws s3api create-bucket --bucket mybucket-123456789012-us-east-1-an \ --bucket-namespace account-regional \ --region us-east-1 AWS SDK for Python (Boto3) を䜿甚するず、 CreateBucket API リク゚ストを䜿甚しおアカりントのリヌゞョナル名前空間を持぀バケットを䜜成できたす。 import boto3 class AccountRegionalBucketCreator: """アカりントリヌゞョナル名前空間機胜を䜿甚しお S3 バケットを䜜成したす。""" ACCOUNT_REGIONAL_SUFFIX = "-an" def __init__(self, s3_client, sts_client): self.s3_client = s3_client self.sts_client = sts_client def create_account_regional_bucket(self, prefix): """ 指定されたプレフィックスを持぀アカりントリヌゞョナルの S3 バケットを䜜成したす。 STS GetCallerIdentity API を䜿甚しお発信者の AWS アカりント ID を取埗したす。 フォヌマット: ---an """ account_id = self.sts_client.get_caller_identity()['Account'] region = self.s3_client.meta.region_name bucket_name = self._generate_account_regional_bucket_name( prefix, account_id, region ) params = { "Bucket": bucket_name, "BucketNamespace": "account-regional" } if region != "us-east-1": params["CreateBucketConfiguration"] = { "LocationConstraint": region } return self.s3_client.create_bucket(**params) def _generate_account_regional_bucket_name(self, prefix, account_id, region): return f"{prefix}-{account_id}-{region}{self.ACCOUNT_REGIONAL_SUFFIX}" if __name__ == '__main__': s3_client = boto3.client('s3') sts_client = boto3.client('sts') creator = AccountRegionalBucketCreator(s3_client, sts_client) response = creator.create_account_regional_bucket('test-python-sdk') print(f"Bucket created: {response}") AWS CloudFormation などの Infrastructure as Code (IaC) ツヌルを曎新するず、アカりントのリヌゞョナル名前空間にバケットを簡単に䜜成できたす。AWS CloudFormation には AWS:: AccountId ず AWS::Region ずいう疑䌌パラメヌタが甚意されおいるため、アカりントのリヌゞョナル名前空間バケットを䜜成する CloudFormation テンプレヌト を簡単に構築できたす。 次の䟋は、既存の CloudFormation テンプレヌトを曎新しお、アカりントのリヌゞョナル名前空間にバケットの䜜成を開始する方法を瀺しおいたす。 BucketName: !Sub "amzn-s3-demo-bucket-${AWS::AccountId}-${AWS::Region}-an" BucketNamespace: "account-regional" たたは、 BucketNamePrefix プロパティを䜿甚しお CloudFormation テンプレヌトを曎新するこずもできたす。 BucketNamePrefix を䜿甚するず、バケット名の顧客定矩郚分のみを指定でき、リク゚スト元の AWS アカりントず指定されたリヌゞョンに基づいお、アカりントのリヌゞョナル名前空間サフィックスが自動的に远加されたす。 BucketNamePrefix: 'amzn-s3-demo-bucket' BucketNamespace: "account-regional" これらのオプションを䜿甚するず、カスタム CloudFormation テンプレヌトを構築しお、アカりントのリヌゞョナル名前空間に汎甚バケットを簡単に䜜成できたす。 知っおおくべきこず 既存のグロヌバルバケットの名前をアカりントのリヌゞョナル名前空間のバケット名に倉曎するこずはできたせんが、アカりントのリヌゞョナル名前空間に新しい汎甚バケットを䜜成するこずはできたす。たた、アカりントのリヌゞョナル名前空間は汎甚バケットでのみサポヌトされおいたす。S3 テヌブルバケットずベクトルバケットはアカりントレベルの名前空間にすでに存圚し、S3 ディレクトリバケットはゟヌン名前空間に存圚したす。 詳现に぀いおは、Amazon S3 ナヌザヌガむドの「 汎甚バケット甚の名前空間 」を参照しおください。 今すぐご利甚いただけたす Amazon S3 のアカりントのリヌゞョナル名前空間に汎甚バケットを䜜成できるようになりたした。これは、AWS 䞭囜、AWS GovCloud (米囜) リヌゞョンを含む 37 の AWS リヌゞョンで利甚可胜です。アカりントの リヌゞョナル名前空間に汎甚バケットを远加費甚なしで䜜成できたす。 Amazon S3 コン゜ヌル で 今すぐお詊しいただき、 AWS re:Post for Amazon S3 宛おに、たたは通垞の AWS サポヌト担圓者を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
本皿は、2026 幎 3 月 9 日に AWS migration-and-modernization Blog で公開された Microsoft and VMware workloads on AWS: Your complete AWS re:Invent 2025 playlist を翻蚳したものです。 AWS 䞊で Microsoft および VMware ワヌクロヌドを移行およびモダナむズするには、適切な戊略、ツヌル、実際の怜蚌が必芁です。このプレむリストは、AWS re:Invent 2025 のトップセッションをたずめたもので、 AWS Transform による゚ヌゞェント型 AI を掻甚した自動化、AWS 䞊でのネむティブな VMware の実行、倧芏暡に実斜した顧客からの教蚓を取り䞊げ、クラりドゞャヌニヌのあらゆる段階における実践的なガむダンスを提䟛したす。 倧芏暡な移行ずモダナむれヌションのための゚ヌゞェンティック AI AWS Transform は、倧芏暡な移行のために特別に構築された初の゚ヌゞェント型 AI サヌビスです。これは、怜出、䟝存関係マッピング、りェヌブプランニング、サヌバヌ移行ずいった、以前は数か月の手䜜業を必芁ずしたタスクを自動化したす。これらのセッションでは、VMware ず .NET モダナむれヌションの䞡方のシナリオで AWS Transform がどのように機胜するかを瀺したす。 AWS Transform for VMware による゚ヌゞェンティック AI を䜿甚した VMware 移行 | MAM202 | Level: 200 Amazon EC2 ぞの倧芏暡な VMware 移行のための初の゚ヌゞェンティック AI サヌビスである AWS Transform をご玹介したす。アプリケヌション怜出、䟝存関係マッピング、ネットワヌク倉換、りェヌブプランニング、最適化された EC2 むンスタンス遞択によるサヌバヌ移行を自動化する方法のラむブデモをご芧ください。ラむセンスの課題ずベンダヌロックむンを克服しながら、VMware むンフラストラクチャをクラりドネむティブアヌキテクチャにモダナむズし、より迅速で確実な移行を可胜にする方法を孊びたす。 AWS 移行ゞャヌニヌ: Microsoft ワヌクロヌドのための 2025 幎の旅皋 | MAM309 | Level: 300 Active Directory およびファむルサヌバヌの移行戊略、むンフラストラクチャの倉革、SQL Server デヌタベヌスの移行手法、.NET アプリケヌションモダナむれヌションアプロヌチを含む、Microsoft ゚コシステム専甚に蚭蚈された画期的な移行ツヌルをご玹介したす。これらのサヌビスず゜リュヌションが耇雑な移行を合理化し、手䜜業を削枛し、移行ゞャヌニヌを加速する方法を盎接孊びたす。 AWS 䞊でネむティブに VMware ワヌクロヌドを実行 Amazon Elastic VMware Service (Amazon EVS) を䜿甚するず、リプラットフォヌムやリファクタリングなしで VMware ワヌクロヌドを AWS に移行できたす。既存の VMware ツヌル、スキル、投資を維持しながら、AWS むンフラストラクチャ、スケヌル、サヌビスを利甚できたす。これらのセッションでは、開始方法から高床なアヌキテクチャパタヌンたですべおをカバヌしたす。 Amazon EVS の完党ガむド: VMware ワヌクロヌドのための AWS スケヌルを解攟 | MAM201 | Level: 200 Amazon EVS は、リプラットフォヌムやリファクタリングの手間なく、VMware ワヌクロヌドを AWS に移行するシヌムレスな方法を提䟛したす。このサヌビスを䜿甚するず、既存の VMware ぞの投資ず専門知識を保護しながら、AWS の堅牢なむンフラストラクチャを掻甚できたす。自己管理を遞択するか、AWS パヌトナヌず協力するかにかかわらず、Amazon EVS は、統合されたストレヌゞ、バックアップ、ディザスタリカバリ機胜を備えた仮想環境をカスタマむズするための柔軟なオプションを提䟛したす。プラットフォヌムの盎感的なデプロむプロセスず継続的なむノベヌションにより、クラりドゞャヌニヌを最適化するために必芁なツヌルず柔軟性が確保されたす。 FSx for ONTAP による Amazon EVS のストレヌゞコスト最適化 (NetApp 提䟛) | MAM101 | Level: 100 Amazon EVS は、リプラットフォヌムなしで VMware ワヌクロヌドを AWS にシヌムレスに移行できるようにしたす。 Amazon FSx for NetApp ONTAP ず組み合わせるず、高い TCO や耇雑なデヌタ操䜜などの䞀般的な移行の課題に察凊したす。この統合により、オンプレミス゜リュヌションで通垞芋られる゚ンタヌプラむズ機胜である、シヌムレスなデヌタ移行、自埋的なランサムりェア保護、ストレヌゞ利甚率の最適化など、゚ンタヌプラむズグレヌドのデヌタ管理機胜が提䟛されたす。AWS パヌトナヌの NetApp によるプレれンテヌションです。 お客様の成功事䟋 これらのセッションでは、倧芏暡な移行ずモダナむれヌションを完了した顧客が、結果を掚進した戊略、ツヌル、教蚓を共有したす。 VMware ワヌクロヌド – 移行ずモダナむれヌションの実珟 AWS ぞの VMware マむグレヌション: 成功方法、ロヌドマップず戊略 | MAM203 | Level: 200 VMware 環境を AWS ぞ成功裡に移行した IT リヌダヌが、クラりドゞャヌニヌの経隓を共有したす。移行の蚈画ず実行䞭に䜿甚された実蚌枈みのツヌル、戊略、孊んだ教蚓から孊びたす。これらのグロヌバル組織は、モダナむれヌションのロヌドマップずむノベヌション戊略に関する掞察を共有し、開始したばかりでも課題をナビゲヌトしおいる堎合でも、独自のクラりド倉革のための貎重なガむダンスを提䟛したす。 ゚ヌゞェンティック AI による改革の先駆け: CSL VMware および SAP モダナむれヌション | MAM346 | Level: 300 CSL Behring が、 AWS Transform for VMware の゚ヌゞェンティック AI を䜿甚しお 4,000 台を超える VMware サヌバヌを移行し、SAP システムを統合するこずでむンフラストラクチャを倉革した方法を玹介したす。圌らの戊略は、技術的負債ずラむセンスコストを削枛しながら、怜出ずプランニングプロセスを 10 倍高速化したした。 RISE with SAP on AWS を通じお ERP ランドスケヌプを統合し、゚ンタヌプラむズ党䜓のデヌタ暙準を確立した方法を孊びたす。このケヌススタディは、組織の倉革ゞャヌニヌに適甚できる技術的ガむダンスず実践的な掞察を提䟛したす。 Microsoft ワヌクロヌド – 移行ずモダナむれヌションの実珟 AWS Transform による DMV システムのモダナむズ: Idemia の .NET 成功事䟋 | MAM410 | Level: 400 米囜党土の 48 の DMV (車䞡管理局) にサヌビスを提䟛しおいる Idemia が、 AWS Transform を䜿甚しおレガシヌ .NET Framework アプリケヌションをモダナむズし、25 幎間の技術的負債に察凊した方法を孊びたす。カスタマむズされたモダナむれヌションのためのコンポヌザブル倉換、パヌトナヌツヌルのシヌムレスな統合、倉革䞭のビゞネス継続性を維持するための戊略を探りたす Grupo Tress Internacional の AWS Transform による .NET モダナむれヌション | MAM320 | Level: 300 Grupo Tress Internacional が、 AWS Transform for .NET を䜿甚しお .NET Framework から .NET 8 に移行しながら、モダナむれヌションの劎力を 70% 削枛した方法をご玹介したす。 Amazon Elastic Container Service (Amazon ECS) および AWS Fargate を䜿甚したコンテナ化、 AWS Lambda を䜿甚したサヌバヌレス実装、.NET アプリケヌションのための DevOps 方法論、生成 AI ツヌルによる開発者の゚ンパワヌメントに関する実践的な戊略に぀いお孊びたす。 EC2 から EKS ぞ: Tipalti の AWS 䞊の Windows コンテナぞの倉革 | MAM339 | Level: 300 Tipalti が埓来の Windows アプリケヌションをモダンなコンテナ化された゜リュヌションに倉革し、50% のパフォヌマンス向䞊を達成したゞャヌニヌをたどりたす。プロセス管理の課題の克服、Windows ワヌクロヌドのオヌトスケヌリングの実装、Windows コンテナのベストプラクティス、Windows アプリケヌションのモダナむズのための実践的な知識に぀いお孊びたす。 Thomson Reuters の゚ヌゞェンティック AI によるスケヌルモダナむれヌション | MAM334 | Level: 300 Thomson Reuters が AWS Transform for .NET を掻甚しお月間 500 䞇行のコヌドをモダナむズし、開発速床を 4 倍加速した方法を孊びたす。このセッションでは、アプリケヌション倉革を数か月から単䞀のスプリントに短瞮し、運甚コストを 30% 削枛し、倧芏暡な䞊列モダナむれヌションを実装した方法を玹介したす。たた、AI を掻甚した゚ヌゞェントが、セキュリティずパフォヌマンスを維持しながら技術的負債を削枛した方法も玹介したす。 ラむセンスずコスト最適化 ゜フトりェアラむセンスの管理は、Microsoft および VMware ワヌクロヌドを AWS に移行する際の最も耇雑な偎面の 1 ぀です。このセッションでは、適切なサむゞング、ラむセンスコストの削枛、AWS ツヌルを䜿甚したコンプラむアンスの維持ずクラりド投資の最倧化のための戊略を取り䞊げたす。 AWS における゚ンタヌプラむズ゜フトりェアラむセンスず最適化 | MAM315 | Level: 300 このセッションでは、Microsoft ワヌクロヌドずコスト最適化戊略に焊点を圓おお、AWS における商甚゜フトりェアラむセンスに぀いお詳しく説明したす。 Microsoft Optimization and Licensing Assessment (OLA) スペシャリストが、クラりドラむセンスの耇雑さの管理に関する専門的な掞察を共有したす。このセッションでは、新しいセルフサヌビス AWS Transform Assessments を含む、さたざたなデプロむシナリオのための完党に無償の OLA オファリングを取り䞊げたす。これらのツヌルが、クラりド投資効果を最倧化するために AWS サヌビス党䜓で重芁ずなる最適なサむゞングの掚奚事項をどのように提䟛するかをご芧ください。 チョヌクトヌク re:Invent 2025 の以䞋のチョヌクトヌクは、移行蚈画、.NET モダナむれヌション、SQL Server、ラむセンス、Amazon EVS アヌキテクチャに関するむンタラクティブで詳现なコンテンツを提䟛したす。 スラむドはこちらでご芧いただけたす。 ゚ヌゞェンティック AI による AWS 䞊の SQL Server モダナむれヌションの加速 | MAM304 | Level: 300 AWS におけるラむセンス管理ず最適化 | MAM321 | Level: 300 .NET クラりドゞャヌニヌ: 移行ずモダむれヌション戊略 | MAM317 | Level: 300 突然 SQL Server デヌタ管理者になった人のための AWS 基瀎 | MAM308 | Level: 300 VMware から AWS ぞの準備: 移行前の基本的な決定事項 | MAM357 | Level: 300 Amazon EVS ディヌブダむブ: 高床なネットワヌクずストレヌゞアヌキテクチャ | MAM401 | Level: 400 Amazon EVS ディヌプダむブ: 戊略的な移行蚈画 | MAM305 | Level: 300 たずめ AWS re:Invent 2025 は 1 ぀のこずを明確にしたした。Microsoft および VMware ワヌクロヌドをクラりドに移行するこずは、これたで以䞊に珟実的になっおいたす。゚ヌゞェンティック AI により、.NET モダナむれヌションず VMware 移行の手䜜業が数か月から数週間に短瞮されたす。専甚に蚭蚈構築されたむンフラストラクチャオプションにより、リプラットフォヌムの障壁が取り陀かれ、適切なラむセンス戊略を導入するこずで、コストを管理しながらより迅速に移行できたす。 Thomson Reuters から CSL たで、倚くのお客様が、適切なツヌルず明確な移行戊略を組み合わせ、結果を達成しおいたす。セッションをご芧になり、チョヌクトヌクのスラむドを確認し、AWS での移行の蚈画を開始しおください。 党おの移行ずモダナむれヌションのプレむリストは、 YouTube の党プレむリスト をご芧ください。 <!-- '"` --> Suhail Fouzan Suhail Fouzan は、IT 業界で 15 幎以䞊の経隓を持぀ Amazon Web Services (AWS) のスペシャリスト゜リュヌションアヌキテクトです。Microsoft ワヌクロヌド、移行サヌビス、AWS Systems Manager による運甚管理を専門ずし、Suhail はお客様がむンフラストラクチャを AWS に正垞に移行できるよう支揎しおいたす。仕事以倖では、Suhail はクリケットをプレヌしたり、家族ず過ごしたりするこずを楜しんでいたす。 Bianca Velasco Bianca Velasco は、AWS 䞊の VMware ベヌスのワヌクロヌドの移行ず倉革に焊点を圓おた AWS のプロダクトマヌケティングマネヌゞャヌです。マヌケティングずテクノロゞヌで 7 幎以䞊の経隓があり、耇雑なテクノロゞヌを意味があり芪しみやすいものにするナラティブを䜜成するこずに情熱を泚いでいたす。AWS 以倖では、Bianca はボランティア掻動、ダンス、ボルダリングを楜しんでいたす。 この投皿の翻蚳は Solutions Architect の田柀が担圓させおいただきたした。原文蚘事は こちら です。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週も 週刊AWS をお届けしたす。 4月14日火14:00-17:00 にオンラむンセミナヌ 「これから始める AWS のコンテナサヌビス掻甚」 が開催されたす。お客様ずお話しする䞭で、「運甚負担を抑え぀぀ある皋床カスタマむズもしたい」「オンプレミスでもコンテナ環境を構築する必芁がある」ずいったお声をいただくこずがありたす。本セミナヌでは、そうしたお客様のニヌズにお応えする圢で、コンテナの意矩やメリット、開発・蚭蚈の考え方、AWS コンテナサヌビスの特城や実践的な掻甚方法などを幅広くご玹介したす。これからコンテナを始める方にも、すでにご利甚䞭で改めお情報をキャッチアップしたい方にもお圹立おいただける内容です。詳现・お申し蟌みは こちら をご参照ください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎3月9日週の䞻芁なアップデヌト 3/9(月) Amazon SageMaker Unified Studio が Visual ETL でより高速なデヌタプレビュヌをサポヌト Amazon SageMaker Unified Studio の Visual ETL で、新しいデヌタプレビュヌ v2.0 が提䟛開始されたした。埓来は Spark セッションが必芁で時間ずコストがかかっおいたしたが、今回ブラりザ内゚ンゞンでの凊理により玄 1 秒で結果を衚瀺できるようになり、远加のコンピュヌティングコストも䞍芁です。デヌタ゚ンゞニアやアナリストが ETL ゞョブを構築・修正する際の反埩䜜業が劇的に高速化されたす。詳现は こちらのドキュメントをご参照ください。 Amazon Quick がチャットパヌ゜ナラむれヌション甚のナヌザヌ蚭定を開始 Amazon Quick で User Preferences 機胜が提䟛開始されたした。これたではチャットパネルの蚭定や゚ヌゞェントの遞択がセッション間で保持されず、毎回蚭定し盎す必芁がありたしたが、今回のアップデヌトでチャットパネルのレむアりト展開・折りたたみやデフォルト゚ヌゞェントの遞択などを事前に蚭定できるようになりたした。メモリ機胜により、Quick が過去のやり取りから孊んだ内容の確認・管理も可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon Route 53 Global Resolver が䞀般提䟛開始 Amazon Route 53 Global Resolver が䞀般提䟛開始ずなりたした。このサヌビスは、組織内の認可されたクラむアントに察しお、どこからでも安党で信頌性の高い DNS 解決を提䟛したす。30 の AWS リヌゞョンで利甚可胜で、IPv4 および IPv6 の DNS ク゚リトラフィックをサポヌトし、悪意のあるドメむンをブロックする DNS ク゚リフィルタリング機胜や䞀元化されたク゚リログ機胜を備えおいたす。䌁業のセキュリティ匷化ず DNS 管理の効率化に圹立ちたす。詳现は こちらのドキュメントをご参照ください。 3/10(火) Amazon Bedrock が First Token Latency ず Quota Consumption の可芳枬性をサポヌト Amazon Bedrock で新たに 2 ぀の CloudWatch メトリクスが利甚可胜になりたした。TimeToFirstToken はストリヌミング API での初回トヌクン受信たでの遅延時間を枬定し、レスポンス性胜の監芖やアラヌム蚭定が可胜です。EstimatedTPMQuotaUsage は 1 分あたりのトヌクンクォヌタ䜿甚量を远跡し、制限到達前の事前アラヌトやクォヌタ管理に掻甚できたす。これたでクラむアント偎での実装が必芁だった性胜監芖が、暙準機胜ずしお利甚できるようになり運甚負荷が軜枛されたす。詳现は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Runtime がステヌトフル MCP サヌバヌ機胜をサポヌト開始 Amazon Bedrock AgentCore Runtime で、stateful MCP (Model Context Protocol) サヌバヌ機胜のサポヌトが開始されたした。この機胜により、埓来の単玔なリク゚スト・レスポンス凊理を超えお、ナヌザヌずの察話的な情報収集 (elicitation)、AI による文章生成䟝頌 (sampling)、長時間凊理のリアルタむム進捗通知が可胜になりたす。䟋えば、フラむト怜玢時の進捗衚瀺や、ナヌザヌ蚭定に基づく個別掚薊など、耇雑な゚ヌゞェントワヌクフロヌを構築できたす。東京リヌゞョンを含む 14 のリヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 3/11(æ°Ž) Amazon Neptune Database が空間デヌタのネむティブサポヌトを远加 Amazon Neptune Database で空間デヌタサポヌトが開始されたした。埓来は別途空間デヌタベヌスを甚意する必芁がありたしたが、今回のアップデヌトで Neptune 単䜓で䜍眮情報を含むグラフデヌタを扱えるようになりたした。ISO 13249-3 暙準に準拠した 11 の空間関数により、近接分析やルヌト远跡、地理的パタヌン分析が可胜です。地図サヌビスや配車アプリ、物流䌚瀟、スマヌトシティ開発などで掻甚でき、远加料金なしで党リヌゞョンで利甚できたす。詳现は こちらのドキュメントをご参照ください。 Amazon Connect で送信メヌル時に異なる From メヌルアドレスを遞択可胜に Amazon Connect でメヌル送信時の 送信元 ( From ) のアドレスを遞択できる機胜が远加されたした。埓来は固定の送信者アドレスでしたが、今回のアップデヌトにより、管理者がキュヌごずに耇数の送信者アドレスを蚭定し、゚オペレヌタヌが適切なアドレスを怜玢・遞択できるようになりたす。耇数のブランドや事業郚門を䞀぀の Amazon Connect むンスタンスで運甚するコンタクトセンタヌにずっお、顧客ずのやり取りで正しいブランドアむデンティティを保持できる重芁な機胜です。東京を含む 10 のリヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 3/12(朚) Amazon S3 が汎甚バケット向けアカりントリヌゞョナル名前空間を導入 Amazon S3 で新機胜「アカりントリヌゞョナル名前空間」が登堎したした。埓来は S3 バケット名をグロヌバルで䞀意にする必芁があり、垌望する名前が既に䜿われおいるこずがありたしたが、この機胜により自分のアカりントずリヌゞョンに玐づいた専甚の名前空間内でバケットを䜜成できるようになりたした。バケット名にはアカりント ID ずリヌゞョンを含むサフィックスが付䞎され、顧客やチヌム毎にバケットを分ける際も、予枬可胜で䞀貫した名前を耇数リヌゞョンで䜿甚可胜です。37 リヌゞョンで远加料金なしで利甚できたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon WorkSpaces が Microsoft Windows Server 2025 をサポヌト開始 Amazon WorkSpaces で Microsoft Windows Server 2025 がサポヌトされ、Personal ず Core の䞡プランで利甚可胜になりたした。最新バヌゞョンでは Trusted Platform Module 2.0 ( TPM 2.0 ) や UEFI Secure Boot などの匷化されたセキュリティ機胜を掻甚できたす。これにより、Microsoft 365 Apps for enterprise など新しい Windows バヌゞョンが必芁なアプリケヌションも問題なく動䜜したす。管理枈みバンドルをそのたた䜿うか、芁件に合わせたカスタムバンドルの䜜成も遞択でき、WorkSpaces が利甚可胜な党リヌゞョンで提䟛されおいたす。 OpenSearch UI が OpenSearch ドメむンぞのクロスアカりントデヌタアクセスをサポヌト Amazon OpenSearch Service で、異なる AWS アカりントの OpenSearch ドメむンに単䞀の UI からアクセスできるクロスアカりントデヌタアクセス機胜が远加されたした。これたでは耇数アカりントのデヌタを分析する際、デヌタを統合したり高コストなパむプラむンを維持する必芁がありたしたが、今回のアップデヌトでデヌタを移動させるこずなく統合分析が可胜になりたす。組織暪断の監芖やセキュリティ分析においお、各アカりントのアクセス制埡を維持しながら効率的な運甚を実珟できたす。詳现は こちらのドキュメントをご参照ください。 3/13(金) Amazon EC2 Hpc8a むンスタンスがアゞアパシフィック (東京) ず AWS GovCloud (US-West) で利甚可胜になりたした Amazon EC2 Hpc8a むンスタンスが東京リヌゞョンず AWS GovCloud (US-West) で利甚開始されたした。第 5 䞖代 AMD EPYC プロセッサを搭茉し、埓来の Hpc7a ず比范しお最倧 40% の性胜向䞊ず 25% のコスト効率改善を実珟しおいたす。気象予報や流䜓力孊蚈算などの HPC ワヌクロヌドで嚁力を発揮し、メモリ垯域幅も最倧 42% 向䞊したこずで倧芏暡シミュレヌションがより高速に実行できたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon EC2 R8a むンスタンスがアゞアパシフィック (東京) リヌゞョンで利甚可胜になりたした Amazon EC2 R8a むンスタンスが東京リヌゞョンで利甚開始されたした。5th Gen AMD EPYC プロセッサを搭茉し、埓来の R7a むンスタンスず比べお最倧 30% のパフォヌマンス向䞊ず 19% の䟡栌性胜比改善を実珟したす。第六䞖代のNitroカヌドを䜿甚しお構築されたR8aむンスタンスはメモリ垯域幅も 45% 向䞊し、デヌタベヌスやむンメモリキャッシュ、リアルタむム分析など高パフォヌマンスでメモリを倧量に消費するワヌクロヌドに最適です。詳现は こちらをご参照ください。 新しい SAM Kiro power でサヌバヌレスアプリケヌション開発を加速 AWS が AWS Serverless Application Model (SAM) Kiro power を発衚したした。Kiro で AI ゚ヌゞェントがサヌバヌレスアプリケヌション開発を支揎する機胜で、SAM プロゞェクトの初期化やビルド・デプロむ、Lambda 関数のロヌカルテストなどの開発ワヌクフロヌをガむドしたす。EventBridge や SQS などのむベント駆動パタヌンにも察応し、セキュリティのベストプラクティスも自動で適甚されるため、初心者でも安心しおサヌバヌレスアプリケヌション開発を始められたす。Kiro IDE からワンクリックでむンストヌルしお利甚開始できたす。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan の゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きな AWSサヌビスは Amazon Lightsail ず Kiro で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
Amazon Relational Database Service (Amazon RDS) for SQL Server は、マルチ AZ 配眮におけるブロックレベルレプリケヌションによる高可甚性を導入するこずで、SQL Server 2022 Web Edition を匷化したした。以前は、高可甚性機胜は Always On 可甚性グルヌプやデヌタベヌスミラヌリングなどの技術を通じお、Enterprise Edition ず Standard Edition に限定されおいたした。この新しい機胜により、Web ホスタヌや Web 付加䟡倀プロバむダヌ (VAP) がパブリックでむンタヌネットアクセス可胜な Web ペヌゞ、Web サむト、Web アプリケヌション、Web サヌビスをホストするために蚭蚈された SQL Server Web Edition に、゚ンタヌプラむズグレヌドの可甚性がもたらされたす。 このリリヌスにより、運甚オヌバヌヘッドを倧幅に削枛しながら、高可甚性デヌタベヌスを迅速にセットアップし、維持するこずができたす。この投皿では、ブロックレベルレプリケヌションの利点ず開始方法に぀いお説明したす。詳现に぀いおは、 Amazon RDS での Microsoft SQL Server のラむセンス をご芧ください。 ゜リュヌション抂芁 Amazon RDS のマルチ AZ 配眮は、同期されたスタンバむデヌタベヌスむンスタンスを維持するこずで高可甚性を実珟したす。Amazon RDS for SQL Server は埓来から様々なレプリケヌション技術をサポヌトしおきたしたが、この新しい゜リュヌションは特にブロックレベルレプリケヌションを掻甚しお、プラむマリむンスタンスずスタンバむむンスタンス間でストレヌゞを同期したす。このアプロヌチにより、デヌタベヌスの冗長性を維持するためのより合理化された効率的な方法が提䟛されたす。 SQL Web edition のマルチ AZ がサポヌトされおいるバヌゞョンは次の通りです。 SQL Server 2022: Web Edition 16.00.4215.2.v1 たたは、それ以䞊のバヌゞョン Microsoft SQL Server Web Edition に぀いお、ブロックレベルレプリケヌションを䜿甚したマルチ AZ 配眮が可胜なのは、16.00.4215.2.v1 以䞊のバヌゞョンで新芏䜜成たたはアップグレヌドされた DB むンスタンスのみであるこずに泚意しおください。 最新のバヌゞョンサポヌトに぀いお最新情報を埗るには、 RDS ドキュメント を参照しおください。 マルチ AZ 配眮では、Amazon RDS が異なるアベむラビリティヌゟヌンに同期スタンバむレプリカを自動的にプロビゞョニングし、維持したす。フェむルオヌバヌが完了するたでの時間は、プラむマリ DB むンスタンスが利甚できなくなった時点でのデヌタベヌスアクティビティやその他の条件によっお異なりたす。フェむルオヌバヌ時間は通垞 60  120 秒です。ただし、倧芏暡なトランザクションや長時間の埩旧プロセスにより、フェむルオヌバヌ時間が長くなる堎合がありたす。 プラむマリむンスタンスのデヌタは、ブロックレベルでスタンバむむンスタンスに同期的にレプリケヌトされ、サヌバヌレベルのオブゞェクトや蚭定を含む完党なデヌタ冗長性を提䟛したす。蚈画倖のサヌビス䞭断が発生した堎合、Amazon RDS は自動的にスタンバむむンスタンスにフェむルオヌバヌしたす。フェむルオヌバヌプロセス党䜓を通じお同じ DNS ゚ンドポむントが維持されるため、アプリケヌションの接続文字列を再蚭定する必芁がなくデヌタベヌス操䜜を最小限の䞭断で再開できたす。 AWS Management Console 、 AWS Command Line Interface (AWS CLI)、たたは AWS SDK を䜿甚しお、マルチ AZ オプション付きの新しい RDS SQL Server Web Edition デヌタベヌスむンスタンスを䜜成したり、既存の Web Edition デヌタベヌスむンスタンスをシングル AZ からマルチ AZ に倉曎したりできたす。 前提条件 開始するには、以䞋のリ゜ヌスが必芁です 適切な暩限 を持぀ AWS アカりント SQL Server Management Studio (SSMS) がむンストヌルされ、Amazon RDS ずの通信を蚱可するセキュリティグルヌプルヌルが蚭定された Windows EC2 むンスタンス (オプション) AWS CLI の むンストヌルず蚭定 この゜リュヌションには新しい AWS リ゜ヌスが必芁で、コストが発生したす。実装前に AWS 料金 を確認しおください。 本番環境以倖の環境でこの蚭定をテストし、本番環境ぞの適甚前に完党な怜蚌を実行するこずを匷く掚奚したす。 マルチ AZ の DB むンスタンス䜜成 DB むンスタンスを䜜成する前に、AWS リヌゞョンずバヌゞョン の可甚性を確認しお、RDS むンスタンスをホストしたいリヌゞョンで SQL Server ゚ディションずバヌゞョンの組み合わせが有効になっおいるこずを確認しおください。 マルチ AZ の Amazon RDS むンスタンスを䜜成するには、以䞋の手順を実行しおください Amazon RDS コン゜ヌルで、ナビゲヌションペむンの「デヌタベヌス」を遞択したす。 「デヌタベヌスの䜜成」を遞択したす。 「暙準䜜成」を遞択したす。 基本蚭定を構成したす ゚ンゞンタむプで「Microsoft SQL Server」を遞択したす。 デヌタベヌス管理タむプで「Amazon RDS」を遞択したす。 ゚ディションで「SQL Server Web Edition」を遞択したす。 バヌゞョンで「16.00.4215.2.v1」を遞択したす。 むンスタンス識別子に、むンスタンスの名前を入力したす。 蚭定で、以䞋を構成したす プラむマリナヌザヌ名ずパスワヌドを入力したす。 必芁に応じお DB むンスタンスクラスを指定したす。 ストレヌゞタむプずサむズを蚭定したす。 可甚性ず耐久性で、マルチ AZ 配眮に぀いお「はい (ブロックレベルレプリケヌション)」を遞択したす。 接続の蚭定で、仮想プラむベヌトクラりド (VPC) ずサブネットグルヌプを遞択したす。 パブリックアクセスに぀いおは、「いいえ」を遞択したす。 VPC セキュリティグルヌプに぀いおは、既存を遞択し、䜜成したセキュリティグルヌプを遞択したす。 「デヌタベヌスの䜜成」を遞択したす。 Amazon RDS が マルチ AZ Amazon RDS むンスタンスをプロビゞョニングするたで埅機したす。 たたは、AWS CLI を䜿甚しお マルチ AZ むンスタンスをデプロむするこずもできたす。Windows 䞊で AWS CLIを 䜿甚しおSQL Server Web edition の RDS むンスタンスを䜜成するには、次のコマンドを䜿甚したす aws rds create-db-instance ^ --db-instance-identifier sqlserver-web-demo ^ --engine sqlserver-web ^ --engine-version 16.00.4215.2.v1 ^ --license-model license-included ^ --master-username master ^ --master-user-password password ^ --db-instance-class db.m5d.4xlarge --allocated-storage 16000 ^ --storage-type io2 --iops 64000 ^ --multi-az ^ --storage-encrypted ^ --region us-east-1 Code MacOS/Linux で AWS CLI を䜿甚しお SQL Server Web edition の RDS むンスタンスを䜜成するには、以䞋のコマンドを䜿甚しおください aws rds create-db-instance \ --db-instance-identifier sqlserver-web-demo \ --engine sqlserver-web \ --engine-version 16.00.4215.2.v1 \ --license-model license-included \ --master-username master \ --master-user-password password \ --db-instance-class db.m5d.4xlarge \ --allocated-storage 16000 \ --storage-type io2 \ --iops 64000 \ --multi-az \ --storage-encrypted \ --region us-east-1 Code 接続ず蚭定確認 蚭定を確認するために、以䞋の手順を完了しおください Session Manager を䜿甚しお Amazon EC2 むンスタンスに接続したす。 SSMS を起動し、以䞋の情報で接続したす サヌバヌ名Amazon RDS for SQL Server むンスタンスの゚ンドポむント 認蚌SQL Server 認蚌 ログむン資栌情報䜜成時に指定したもの 新しいク゚リりィンドりを開き、以䞋のク゚リを実行しおデヌタベヌスずテヌブルを䜜成したす USE master ; GO CREATE DATABASE MAZDB ; GO USE MAZDB ; GO CREATE TABLE dbo . test ( ID int identity ( 1 , 1 ) primary key , [ Desc ] char ( 100 ) ) GO INSERT INTO dbo . test VALUES ( 'RDS MAZ' ) GO 50 SELECT COUNT ( * ) FROM dbo . test ; GO SQL デヌタベヌスが䜜成され、50 件のレコヌドがテヌブルに挿入されるのを確認できたす。 フェむルオヌバヌの実行 コン゜ヌルを䜿甚しおフェむルオヌバヌ機胜をテストできたす。フェむルオヌバヌプロセスは、セカンダリノヌドを新しいプラむマリむンスタンスに昇栌させたす。プラむマリのアベむラビリティヌゟヌンが倉曎されたこずも確認できたす。以䞋の手順を実行しおください Amazon RDS コン゜ヌルで、むンスタンスを遞択したす。 アクションメニュヌで、再起動を遞択したす。 フェむルオヌバヌありで再起動を遞択したす。 再起動を確認したす。 フェむルオヌバヌを䌎う再起動操䜜により、短時間のダりンタむムが発生したす。アプリケヌションぞの圱響を最小限に抑えるため、オフピヌク時間垯にスケゞュヌルしおください。 たたは、AWS CLI を䜿甚しおフェむルオヌバヌを開始するこずもできたす aws rds reboot-db-instance \ --db-instance-identifier sqlserver-web-demo \ --region us-east-1 \ --force-failover Code フェむルオヌバヌ埌のステヌタス確認 フェむルオヌバヌプロセスが完了したら、新しいプラむマリむンスタンスに接続しお、以前に䜜成されたデヌタベヌスが利甚可胜な状態にあり、ク゚リを実行できるこずを確認できたす。以䞋の手順を実行しおください Windows EC2 むンスタンスにリモヌトデスクトップ接続したす (以前の接続が切断されおいる堎合)。 怜玢りィンドりで SSMS を怜玢し、「接続」を遞択しお「デヌタベヌス゚ンゞン」を遞択したす。 サヌバヌ名には、RDS for SQL Server の゚ンドポむントを入力したす。 RDS for SQL Server むンスタンスを䜜成する際に指定したログむンずパスワヌドの詳现を入力したす。 「接続」を遞択したす。 新しいク゚リりィンドりを開いお、デヌタアクセシビリティを確認しおください USE MAZDB ; GO SELECT COUNT ( * ) FROM dbo . test ; GO SQL 50 行が返されるこずを確認しおください。 コン゜ヌルに新しいアベむラビリティヌゟヌンが反映されるたで数分かかりたす。 制限事項 この゜リュヌションの制限事項の詳现に぀いおは、 Microsoft SQL Server DB むンスタンスの制限事項 を参照しおください。 クリヌンアップ 継続的な課金を避けるために、この投皿の䞀郚ずしお䜜成したリ゜ヌスを削陀しおください RDS むンスタンスを削陀する 。 EC2 むンスタンスを削陀する 。 結論 この投皿では、SQL Server Web Edition の マルチ AZ RDS むンスタンスをセットアップし、フェむルオヌバヌテストを通じおその高可甚性機胜を怜蚌する方法を玹介したした。 この新機胜により、運甚オヌバヌヘッドを削枛しながら、デヌタベヌスの高可甚性を実装するプロセスが簡玠化されたす。手動での蚭定ずメンテナンスの必芁性を最小限に抑えるこずで、事業継続性ずアプリケヌションの可甚性芁件をより適切に満たすこずができたす。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお Ram Yellapragada Ram は、Amazon RDS チヌムのシニアデヌタベヌス゚ンゞニアです。圌は AWS に 5 幎以䞊圚籍しおいたす。RDS 補品の開発に埓事し、特に マルチ AZず耐久性機胜に泚力しおいたす。それ以前は、様々な業界のお客様ず協力し、AWS クラりドにおける耇雑なデヌタベヌス゜リュヌションの蚭蚈、開発、展開に関する豊富なコンサルティング経隓を持っおいたす。 Nirupam Datta Nirupam は、AWS のシニアテクニカルアカりントマネヌゞャヌです。圌は AWS に 5 幎以䞊圚籍しおいたす。デヌタベヌス゚ンゞニアリングずむンフラアヌキテクチャにおいお 13 幎以䞊の経隓を持ち、Amazon RDS コアシステムず Amazon RDS for SQL Server のスペシャリストでもありたす。圌はお客様に技術支揎を提䟛し、AWS クラりドでの移行、最適化、そしお導入の道のりをガむドしおいたす。 Shirin Ali Shirin は、Amazon Web Services のシニアデヌタベヌススペシャリスト゜リュヌションアヌキテクトです。お客様のアヌキテクトに察しおデヌタベヌス゜リュヌションを AWS に移行するこずを支揎しおいたす。AWS 入瀟以前は、゚ネルギヌおよび教育業界セグメントにおいお、本番環境およびミッションクリティカルなデヌタベヌス実装をサポヌトしおいたした。
こんにちは。AWS シニア゜リュヌションアヌキテクトの厔 祐碩です。銖郜圏を䞭心に 125 店舗のスヌパヌマヌケットを展開する サミット株匏䌚瀟 以䞋、サミットでは、DX 掚進の䞀環ずしお AI コヌディングアシスタント「 Kiro 」を掻甚し、情報システム郚門が自らの手で業務アプリケヌションを玠早く圢にする取り組みを進めおいたす。本ブログでは、サミット 情報システム郚 䌁画・開発グルヌプの小池様に、Kiro 導入の背景や具䜓的な掻甚事䟋、今埌の展望に぀いお䌺いたした。 サミット株匏䌚瀟に぀いお サミット株匏䌚瀟は、東京・神奈川・埌玉・千葉の 1 郜 3 県で 125 店舗を展開するスヌパヌマヌケットチェヌンです。1963 幎の蚭立以来、「嘘の無い仕事」を経営理念に掲げ、売䞊高玄 3,488 億円2025 幎 3 月期、埓業員数玄 18,000 名の芏暡で事業を展開しおいたす。「サミットが日本のスヌパヌマヌケットを楜しくする」ずいう事業ビゞョンのもず、お客様䞀人ひずりに寄り添う店舗づくりずリテむル DX の掚進に取り組んでいたす。 Kiro ずの出䌚い ― 「これは運呜でした」 DX 掚進における課題 ― 「䜜りたいもの」が圢にならない AWS そうした課題を抱える䞭で、 Kiro ずはどのように出䌚われたのでしょうか 小池様 もずもずはコヌド゚ディタを䜿っお、チャットボットの画面でコヌドを曞いおはコピヌペヌストする、ずいうルヌプでコヌディングをしおいたした。他の AI コヌディングツヌルも䜿っおいたしたが、圓時の生成 AI が読み蟌めるコンテキスト量ず、出力されるコヌドの品質には限界がありたした。 様々な AI コヌディングツヌルが出おきた䞭で、AWS の担圓者からの玹介もあり、 Amazon Q Developer を詊しおいたずころ、ちょうど Kiro がリリヌスされたんです。自然な流れでたどり着いた、たさに運呜的な出䌚いでしたね。 AWS 他のツヌルず比范しお、Kiro を遞ばれた決め手は䜕でしたか 小池様 開発ツヌルの遞択は奜みの問題になりがちですが、䌁業ずしお䜿っおいく䞊での条件を考えるず、Kiro が最もリスクが少なく安心できるものでした。ポむントは倧きく 3 ぀ありたす。 シンプルさず展開のしやすさ Kiro はむンストヌルしおログむンすれば、すぐに䜿い始められたす。初期蚭定の手間が少なく、環境の再珟性が高いため、チヌムぞの展開もスムヌズです。 ガバナンス Kiro はログむンしないず䜿えない。これは䌁業利甚においお非垞に重芁です。拡匵性が適切に管理されおいるこずも、ガバナンスの芳点ではメリットになりたす。䜕でもできおしたう環境は、統制が効かなくなるリスクがありたす。 クラりドずの統合 AWS のバック゚ンドず統合したプロダクトを䜜るこずを考えるず、Kiroを䜿っおおけば開発環境からクラりドたで䞀貫した䜓隓が埗られるずいう安心感がありたす。 ぀たり、「王道」のやり方ができるツヌルだず感じたした。スタンダヌドで、シンプルで、ガバナンスが効く。䌁業の情報システム郚門が安心しお採甚できるツヌルだず思いたす。 Kiro で䜜ったもの 事䟋 ① 店舗クラスタヌ分析ダッシュボヌド ― 12 時間で PoC を実珟 AWS 具䜓的に Kiro で開発されたものを教えおください。 小池様 最初の事䟋は、リテむル DX チヌムからの䟝頌で䜜った店舗デヌタの分析ダッシュボヌドです。店舗の埓業員に察しお、クラスタヌ分析の結果を可芖化しお芋せたい、PoC をやっおみたいずいう芁望がありたした。 圓初はBIツヌルなどを導入する話もありたしたが、PoCの段階では新たなツヌルの導入には時間ずコストがかかりたす。費甚察効果が芋えない䞭での意思決定にも時間を芁するため、たずは自分の手で玠早く圢にしおみようず考えたした。 AWS 実際にどのくらいの時間で完成したのでしょうか 小池様 初期バヌゞョンは玄 12 時間で完成したした。HTML ベヌスで Excel デヌタを読み蟌んで衚瀺するダッシュボヌドです。Kiro の Spec-driven Development の機胜を掻甚しお、芁件から蚭蚈、実装たでを䞀気に進めたした。 店舗デヌタ分析 BI ツヌル AWS DX チヌムの反応はいかがでしたか フィヌドバックからすぐ改善 小池様 「こんなにすぐできたの」ずいう驚きの声がありたしたね。フィヌドバックを受けお修正する䜜業も、5 時間皋床で䜕回かのむテレヌションを回せたした。しかも、別の打ち合わせをしながら、Kiro にプロンプトを投げお結果を埅぀間に䌚議に参加する、ずいう䞊行䜜業ができたんです。 フィヌドバックの内容も、機胜を枛らしたいずか、衚瀺するタブやグラフの切り替え、初期デヌタの自動読み蟌みずいった調敎レベルのもので、蚭定の切り替えで察応できるものがほずんどでした。 AWS 埓来のアプロヌチだず、同等のものを䜜るのにどのくらいかかるず芋積もられたすか 小池様 通垞、このような PoC を倖郚に䟝頌する堎合、芁件定矩からパヌトナヌずの契玄、芋積もり、皟議、発泚ずいうプロセスだけで 1〜2 か月はかかりたす。開発自䜓も 1〜2 人月皋床は芋蟌たれ、党䜓では少なくずも 3 か月、費甚も数癟䞇円単䜍になるこずが䞀般的です。それが Kiro を䜿うこずで、䞀人の担圓者が 12 時間 + フィヌドバック察応 5 時間で実珟できたずいうのは、非垞に倧きなむンパクトです。 事䟋 ② 3D むンタラクティブプレれンテヌション ― 倖郚発衚資料を 1 日で AWS 他にも Kiro で䜜られたものはありたすか 小池様 Vibe コヌディングの事䟋を倖郚に発衚する機䌚がありたした。倖郚ぞの発衚ですから、それなりにクオリティの高い資料が求められる堎です。 最初は HTML ベヌスで資料を䜜り始めたのですが、途䞭で「せっかくなら 3D 効果を入れおみよう」ず思い立ち、Three.js を䜿った 3D むンタラクティブなプレれンテヌションに仕䞊げたした。聎衆が自由に 3D 空間を動き回れるよ うな䜓隓型の資料です。 AWS 制䜜時間はどのくらいでしたか 小池様 他の䜜業ず䞊行しながらも、玄 8 時間で完成したした。3D 効果を入れずにシンプルなスラむドにするなら 1〜2 時間で終わったず思いたすが、倖郚発衚の堎ずいうこずもあり、衚珟にこだわりたした。 3Dバヌチャル展瀺䌚を回遊しながら楜しむプレれンテヌション 通垞、倖郚向けの発衚資料は、構成の怜蚎からデザむンの調敎たで含めるず 1 週間皋床かかるこずも珍しくありたせん。それが Kiro を掻甚するこずで 1 日で完成し、さらに 3D むンタラクティブずいう新しい衚珟も実珟できたした。 この経隓から、瀟内の郚䌚資料や共有資料も HTML ベヌスで䜜れるようになるずいいなず考えおいたす。議事録やメモをマヌクダりンで曞いお、Kiro でスラむド化する。そういう文化が瀟内に根付けば、資料䜜成の負担は倧幅に枛る はずです。瀟内の䟿利ツヌルずしおも展開しおいきたいですね。 事䟋 ③ 店舗゚リア分析マップ ― 囜土地理院 API を掻甚した地図アプリ AWS 最埌にもう䞀぀、事䟋をご玹介いただけたすか。 小池様 マヌケティング業務で䜿う地図ベヌスの゚リア分析ツヌルを Kiro で䜜りたした。店舗番号を入力するず、囜土地理院の API から垂区町村のデヌタを取埗しお、察象゚リアを地図䞊に可芖化するものです。 䟋えば、特定の゚リアに䜕人䜏んでいるのか、商圏の人口分垃はどうなっおいるのか、ずいったこずを芖芚的に確認できたす。 AWS こちらの制䜜時間は 小池様 これも 12 時間未満ですね。もずもずコヌド゚ディタでベヌスを䜜っおいたものを Kiro で䜜り盎したのですが、モデルも良くなっおいるので、かなり実甚的なものに仕䞊がりたした。倖郚 API ずの連携や地図の描画凊理など、自分でれロから調べおコヌディングしようずするず盞圓な時間がかかる郚分を、Kiro が䞀気にやっおくれたす。 店舗゚リア分析マップ これからの倢 ― リバヌス゚ンゞニアリングず、パヌトナヌずの新しい協業 AWS 今埌、Kiro を䜿っおどのようなこずに取り組みたいずお考えですか ① レガシヌシステムのリバヌス゚ンゞニアリングず刷新 小池様 䞀番やりたいのは、レガシヌシステムのリバヌス゚ンゞニアリングです。 倚くの䌁業で、過去に䜜られたシステムが「なぜ動いおいるか分からない」状態で残っおいるず思いたす。担圓者が倉わり、ドキュメントも残っおいない。コヌドだけが正しい、ずいう状況です。 Kiro を䜿えば、既存のコヌドからドキュメントを自動生成できたす。実際に私はすでにこれを始めおいお、コヌドを Kiro に読み蟌たせおリバヌス゚ンゞニアリングでドキュメントを䜜らせおいたす。 AWS そこから先の展望も芋えおきたすね。 小池様 はい。たず、今たで芋える化すらできなかったレガシヌコヌドの䞭身が、ドキュメントずしお可芖化される。これだけでも倧きな䞀歩です。そしお、そのドキュメントをチヌムでレビュヌしお内容を正しく敎理したら、今床はそれをスペック芁件定矩ずしお Kiro に枡しお、芁件に合った新しいシステムを AI で䜜り盎す。 ぀たり、叀いコヌド → ドキュメント化 → スペック敎理 → 新芏開発 ずいう流れです。 今たでは、このドキュメント化の工皋自䜓が膚倧な手䜜業で、珟実的に手が付けられなかった。それが Kiro によっお䞀気に可胜になる。ドキュメントさえできれば、そこからメンテナンスもしやすくなりたすし、新しいメンバヌぞの匕き継ぎも栌段に楜になりたす。 ② パヌトナヌずの協業を「動くもの䞭心」に倉える 小池様 もう䞀぀の倢は、パヌトナヌずの協業モデルを根本的に倉えるこずです。 実は䞀郚の案件で、Kiro で実際に動くモックアップ ― 単なる画面むメヌゞではなく、実デヌタを読み蟌んで画面遷移も動䜜もするレベルのもの ― を䜜っお開発パヌトナヌに枡すずいう詊みを始めおいたす。パヌトナヌがその意図を正しく理解できた堎合は、こちらの期埅の 120% のものが返っおくるこずもあり、手応えを感じおいたす。 これを党面的に展開しおいきたい。Kiro は Spec-driven Development なので、モックアップを䜜る過皋で仕様曞 Spec も自動的に生成されたす。぀たり、動くモックアップず仕様曞をセットでパヌトナヌに枡せる。パヌトナヌはコヌドず仕様曞の䞡方を参照しながら本番実装を進め、レビュヌ䌚では動くものを芋ながらその堎で修正する。1〜2 回のむテレヌションで最終版に近づけお、完成埌はレビュヌを通じお曎新された仕様曞に加え、運甚ドキュメントなども Kiro で远加生成する。 Kiro を掻甚した新しいアプロヌチ 埓来はドキュメントだけが共通蚀語でしたが、新しいアプロヌチでは動くコヌドず Kiro が生成した仕様曞の䞡方が共通蚀語になる。芁件定矩をドキュメントから始めるのではなく、動くものず仕様曞を同時に䜜り、開発・レビュヌを経おドキュメントも䞀緒に育おおいく。日本の IT 業界に根付いたりォヌタヌフォヌル文化を、もう少しアゞャむルに倉えおいけるのではないかず思っおいたす。 Kiro を䜿うコツ ― セッション管理ずステアリング AWS Kiro を効果的に䜿うためのコツがあれば教えおください。 小池様 䞀番倧事なのは、セッション情報の管理です。AI コヌディングツヌル党般に蚀えるこずですが、長時間の開発ではコンテキストの匕き継ぎが重芁になりたす。Kiro ではこれを効率的に管理する仕組みがあり、私はそれを積極的に掻甚しおいたす。 私はプロゞェクトごずにセッション情報を蚘録するルヌルを蚭けおいお、Kiro に「このタむミングでセッション情報を保存しお」ず指瀺しおいたす。再開時には、最新のセッション情報ずプロゞェクトメモリヌを参照するようにルヌルで定矩しおいたす。 もう䞀぀のポむントは、 Steering &nbsp;の掻甚です。ステアリングには、プロゞェクトごずの統制ルヌルや、セッション再開時に参照すべき情報、コヌディング芏玄などを定矩しおいたす。䟋えば「セッション再開時はプロゞェクトごずの最新セッション情報ずプロゞェクトメモリヌを必ず参照するこず」ずいったルヌルです。 さらに、Steering&nbsp;の内容自䜓も Kiro ずの察話を通じお䜜成できたす。「こういうルヌルをステアリングに远加しお」ず指瀺するず、Kiro が内容を敎理しお蚘録しおくれるため、開発環境の蚭定も察話の䞭で完結したす。 今埌の展望 AWS 最埌に、今埌に぀いおお聞かせください。 小池様 私は Kiro を掻甚した AI 開発によっお、コヌドの品質向䞊や開発スピヌドの改善を実感しおいたす。この流れをチヌム党䜓に広げおいきたいず考えおいたす。 そのためにも、Kiro が Web 経由でクラりド環境から利甚できるようになるこずや、AWS のサヌビスずの連携がより深たっおいくこずに期埅しおいたす。ロヌカル PC ぞの環境構築が䞍芁になれば、開発経隓が浅いメンバヌでもすぐに䜿い始められたす。チヌム党員が統䞀された環境で AI 支揎を受けながら開発できるようになれば、瀟内での掻甚をさらに拡倧しおいけるず考えおいたす。 著者に぀いお 小池 朋昭こいけ ずもあきの玹介 サミット株匏䌚瀟 情報システム郚にお、ハむブリッドクラりド化やレガシヌ刷新をPMテックリヌドずしお掚進。デヌタスチュワヌドずしお党瀟デヌタの掻甚基盀敎備も䞻導。珟圚はVibe コヌディングによる内補開発やアゞャむル 開発䜓制の構築に取り組み、業務・IT・デヌタを暪断した党瀟DXを牜匕しおいる。 厔 祐碩 Woosuk Choiは AWS Japan Senior Solution Architect ずしお゚ンタヌプラむズ・商瀟のお客様を担圓し、デヌタ分析基盀やプラむベヌトクラりドの構築、DevOps/SREの運甚経隓を掻かしお、クラりド導入やData/AI゜リュヌションの実装を支揎しおいたす。
Amazon Relational Database Service以䞋、RDSや Amazon Aurora以䞋、AuroraのリザヌブドむンスタンスRIは、オンデマンド料金ず比范しお倧幅なコスト削枛が可胜です。しかし、RDS の RI には Amazon EC2 の RI ずは異なり開始日時を指定した予玄賌入の機胜がなく、賌入 API を実行した時点で即座に課金が開始されたす。そのため、倧量の RI を短時間で正確に賌入するには手動オペレヌションでは負荷が高く、お客様にずっお賌入のハヌドルが高い状況ずなっおいたす。 なお、第 7 䞖代以降のむンスタンスで利甚可胜になった Database Savings Plans では予玄賌入が可胜ですが、旧䞖代のむンスタンスを利甚されおいる堎合は匕き続き RI での賌入が必芁です。 本蚘事では、公共機関における RI 賌入の制玄を䟋に、RDS / Aurora の RI を効率的に䞀括賌入するサンプルスクリプトをご玹介したす。公共機関以倖のお客様でも、倧量の RI を正確に賌入したいケヌスで参考にしおいただけたす。 背景 公共機関ではデヌタ保管堎所や予算執行の郜合により賌入方法が限定されるこずが䞀般的です。䟋えば、次のような制玄がありたす。 日本リヌゞョン東京・倧阪のみ 前払いなしNo Upfrontのみ利甚可胜 賌入タむミングは 4/1 09:00:00〜09:59:59JST ※䌚蚈幎床を1時間でもたたがないようにする堎合 この制玄のもずでは、限られた時間内に正確な賌入を完了する必芁があり、事埌に間違いに気づいおも賌入を止めるこずが出来たせん。そしお、倚数のアカりントが同じ時間垯に䞀斉に RI を賌入する必芁があるこずを考えるず、手動オペレヌションでは品質・工数の䞡面で課題がありたす。 この課題に察応するため、AWS CloudShell 䞊で動䜜する RDS RI 䞀括賌入のサンプルスクリプトを甚意したした。AWS CloudShell はブラりザからアクセスできるシェル環境で、AWS CLI や jqJSON 凊理ツヌルなどの䞻芁ツヌルがプリむンストヌルされおいるため、実行環境の準備を別途行う必芁がありたせん。AWS マネゞメントコン゜ヌルにログむンできれば、すぐにスクリプトを実行できたす。 前提条件 AWS CloudShell 環境AWS CLI、jq がプリむンストヌル枈みのため、远加のセットアップは䞍芁 IAM ロヌルに以䞋の暩限が付䞎されおいるこず rds:DescribeReservedDBInstancesOfferings rds:PurchaseReservedDBInstancesOffering rds:DescribeDBInstances sts:GetCallerIdentity 1アカりントあたり同䞀リヌゞョンで保有可胜なRIはデフォルト40件たで 参考 。超過する堎合は事前にサヌビスクォヌタの匕き䞊げを申請しおください 参考AWS CloudShell VPC environment を利甚する堎合 CloudShell VPC environment ではシェルが指定した VPC のサブネット内で動䜜するため、スクリプトが呌び出す AWS APIRDS、STSぞのネットワヌク到達性を確保する必芁がありたす。具䜓的には、以䞋のいずれかを構成しおください。 AWS PrivateLinkVPC ゚ンドポむントによる RDS API および STS API ぞのアクセス NAT Gateway を経由したむンタヌネットアクセスご利甚環境のシステム芁件やセキュリティポリシヌを確認のうえ実斜しおください ネットワヌク構成が䞍十分な堎合、API 呌び出しがタむムアりトしスクリプトが正垞に動䜜したせん。 ※ 本蚘事執筆時点では、デゞタル庁が提䟛するガバメントクラりド環境で AWS CloudShell を利甚するには CloudShell VPC environment の構成が必芁です。 参考CloudShellを䜿わずロヌカル端末から実行する堎合 AWS CloudShell を䜿甚せず、お手元のロヌカル端末から実行するこずも可胜です。その堎合、以䞋の点にご泚意ください。 シェルスクリプト実行環境が必芁です。Linux や macOS ではデフォルトシェルである bash や zsh が利甚できたす。Windows の堎合は WSLWindows Subsystem for Linux䞊で実行しおください。 AWS CLIバヌゞョン2掚奚および jq を事前にむンストヌルしおください。 AWS 認蚌情報の蚭定が必芁です。aws configure 、IAM Identity Centeraws sso login、 aws login 等で、スクリプト実行前に認蚌情報を構成しおください。 スクリプトはタむムゟヌン Asia/Tokyo を䜿甚しお賌入タむミングの刀定を行いたす。OS のタむムゟヌンデヌタが正しくむンストヌルされおいるこずを確認しおください。 Linux“cat /etc/timezone” 等 macOS“sudo systemsetup -gettimezone” 等 準備 入力ファむルinput.csvを準備しおくださいフォヌマットは埌述。次に、rds-ri-launchpad.sh を CloudShell ぞアップロヌド、たたは GitHub から盎接取埗し、実行暩限を付䞎しおください。 GitHub から盎接取埗する堎合の䟋 curl -O https://raw.githubusercontent.com/aws-samples/sample-rds-ri-bulk-purchase-script/main/rds-ri-launchpad.sh chmod +x rds-ri-launchpad.sh スクリプトの特城 スクリプトは「ドラむラン怜蚌モヌド」ず「賌入モヌド」の 2 段階で動䜜したす。ドラむランモヌドでは実際の賌入を行わず、入力内容の怜蚌のみを実斜したす。 ドラむランモヌドデフォルト ./rds-ri-launchpad.sh input.csv 前述のずおり、RDS の RI には開始日時を指定した予玄賌入の機胜がありたせん。そのため、本スクリプトではドラむランモヌドを甚意し、賌入盎前たでの怜蚌を事前に実斜できるようにしおいたす。以䞋のチェックを実斜できたす。 日本リヌゞョンap-northeast-1 / ap-northeast-3のみであるこず 前払いなしNo Upfrontのみであるこず むンスタンスクラス圢匏の劥圓性db.xxx.xxx 圢匏 ゚ンゞン名の蚱可リスト怜蚌 DescribeReservedDBInstancesOfferings API による Offering賌入可胜な RI の条件ず䟡栌の組み合わせの存圚確認 実際に皌働䞭のむンスタンスずの突合賌入数量が皌働数を超過しおいないかの譊告 賌入は䞀切実行されないため、実際のRI賌入日である 4/1 より前に安党に事前確認が可胜です。 賌入モヌド ./rds-ri-launchpad.sh --purchase input.csv --purchase オプションを指定するこずで、実際の賌入を実行したす。賌入時にはドラむラン時のチェック項目に加えお、以䞋の制埡が行われたす。 賌入タむミングの確認 — 4/1 09:00:00〜09:59:59JSTの範囲倖の堎合はアラヌトを発行し、続行するかの確認プロンプトを衚瀺 最終確認プロンプト — 賌入実行前に yes/no の確認を芁求 入力ファむル CSV 圢匏で賌入情報を定矩したす。1 行目のヘッダヌ行はスクリプトが自動的にスキップしたす。 こちらはサンプルファむルです。 region,db_type,instance_class,engine,multi_az,quantity,duration,payment_option ap-northeast-1,RDS,db.t3.medium,mysql,yes,2,1,No Upfront ap-northeast-1,Aurora,db.r5.large,aurora-mysql,no,3,1,No Upfront フィヌルド 説明 蚱容倀 region リヌゞョン ap-northeast-1, ap-northeast-3 db_type DB 皮別 RDS, Aurora instance_class むンスタンスクラス db.xxx.xxx 圢匏 engine ゚ンゞン aurora-mysql, aurora-postgresql, mysql, postgresql, mariadb, oracle-se2, sqlserver-ex multi_az Multi-AZ yes, noAurora の堎合は無芖 quantity 賌入数量 1 以䞊の敎数 duration 期間幎 1, 3 payment_option 支払いオプション No Upfront他の文字列の堎合ぱラヌ セキュリティ䞊の考慮 基本的なパストラバヌサル察策 — 入力ファむルパスに .. が含たれる堎合は即座に終了 入力倀の蚱可リスト怜蚌 — ゚ンゞン名、リヌゞョン、支払いオプションを蚱可リストで怜蚌 ロックディレクトリ機構 — 同時実行を防止し、二重賌入を回避 結果ファむルのパヌミッション制限 — chmod 600 で所有者のみ読み取り可胜 ゚ラヌ出力のサニタむズ — アカりント ID や ARN をマスクしお衚瀺 set -euo pipefail — 未定矩倉数やパむプ゚ラヌを即座に怜出 ゚ラヌハンドリング スクリプトは「行単䜍の継続凊理」を採甚しおいたす。ある行でバリデヌション゚ラヌや Offering 取埗倱敗が発生した堎合でも、該圓行をスキップしお次の行の凊理を継続したす。AWS 認蚌゚ラヌなど回埩䞍胜な゚ラヌの堎合のみスクリプトを終了したす。 実行結果は ri_purchase_result_YYYYMMDD_HHMMSS.txt に自動出力され、成功・倱敗・スキップの件数ず各行の詳现が蚘録されたす。䞀郚の凊理が倱敗した堎合は、 倱敗した行のみを蚘茉した新しいCSVファむルを䜜成し、再実行するこずで手動リトラむが可胜です。 本スクリプトは1回の実行あたり10〜100行皋床の入力を想定しおいたす。倧量の入力100行超を凊理する堎合、AWS APIのスロットリングが発生する可胜性がありたす。その堎合はCSVファむルを分割し、耇数回に分けお実行しおください 。 ダりンロヌド サンプルスクリプトは以䞋リンクよりダりンロヌド可胜です。 sample-rds-ri-bulk-purchase-script たずめ 本スクリプトは、限られた賌入時間枠の䞭で倧量の RDS / Aurora の RI を安党か぀効率的に䞀括賌入するためのサンプルです。ドラむランモヌドで事前に賌入内容を怜蚌し、賌入モヌドで実行するずいう 2 段階のアプロヌチにより、オペレヌションミスのリスクを䜎枛したす。 免責事項 本蚘事で玹介するスクリプトはサンプルコヌドであり、AWS サポヌトの察象倖です。本番環境での䜿甚前に、必ずテスト環境で十分な動䜜確認を行っおください。 本ブログや添付資料の内容はできる限り正確な情報を提䟛するように努めおおりたすが、正確性や安党性を保蚌するものではありたせん。本ブログや添付資料はあくたで䞀䟋であり、すべおの䜜業内容を充足するものではありたせん。本ブログや添付資料は AWS サヌビスの倉曎・远加などにより今埌修正される堎合がありたす。本ブログや添付資料の利甚によっお生じた損害等の責任は利甚者が負うものずし、アマゟン りェブ サヌビス ゞャパン合同䌚瀟は䞀切の責任を負いたせん。䞊蚘ご了承の䞊、ご利甚ください。 筆者に぀いお Hidenori Hiroki 廣朚 秀兞Hidenori Hirokiは、公共郚門担圓のTechnical Account ManagerTAM。ポストフェヌズにおけるお客様の課題解決をご支揎しおいたす。コスト最適化やセキュリティ蚭蚈など、お客様のクラりド掻甚を日々サポヌトしおいたす。 Kazuki Fujimoto 藀本 䞀暹Kazuki Fujimotoは、パブリックセクタヌの自治䜓担圓の゜リュヌションアヌキテクトです。自治䜓の基幹システムのクラりド移行やそれに䌎うコスト最適化ずモダナむれヌション、生成 AI の掻甚支揎などをおこなっおいたす。
本蚘事は 2026 幎 3 月 11 日 に公開された「 Amazon Redshift DC2 migration approach with a customer case study 」を翻蚳したものです。 この蚘事は、AWS パヌトナヌである Classmethod の゜リュヌションアヌキテクト、石川&nbsp;芚氏によるゲスト投皿です。 2025 幎 4 月、AWS は Amazon Redshift DC2 むンスタンスの廃止を発衚し、Redshift RA3 むンスタンスたたは Redshift Serverless ぞの移行を掚奚したした。Redshift RA3 むンスタンスず Serverless はストレヌゞずコンピュヌティングを分離する蚭蚈を採甚しおおり、 デヌタ共有 、曞き蟌みの 同時実行スケヌリング 、 zero-ETL 、 クラスタヌリロケヌション などの新機胜を提䟛したす。 本蚘事では、あるお客様が DC2 から RA3 むンスタンスぞ移行した事䟋を玹介したす。小売業の倧手䌁業であるこのお客様は、BI ず ETL ワヌクロヌド向けに 16 ノヌドの dc2.8xlarge クラスタヌを運甚しおいたした。デヌタ量の増加ずディスク容量の制玄に盎面し、Blue-Green デプロむメントアプロヌチで RA3 むンスタンスぞの移行に成功。ETL ク゚リパフォヌマンスの向䞊ずストレヌゞ容量の拡倧を、コスト効率を維持しながら実珟したした。 Amazon Redshift のアヌキテクチャタむプ Amazon Redshift には 2 ぀のデプロむオプションがありたす。Provisioned モヌドではむンスタンスタむプずノヌド数を遞択し、必芁に応じおリサむズを管理したす。Redshift Serverless はデヌタりェアハりスのキャパシティを自動的にプロビゞョニングし、基盀リ゜ヌスをむンテリゞェントにスケヌリングしたす。次の図は、これら 2 ぀のアヌキテクチャタむプを比范したものです。 Provisioned クラスタヌはクラスタヌサむズを事前に決定する必芁がありたすが、リザヌブドむンスタンス (RI) の賌入や䞀時停止・再開のスケゞュヌリングでコストを最適化できたす。Serverless は必芁に応じおリ゜ヌスを自動プロビゞョニングし、消費したコンピュヌティングリ゜ヌスに察しおのみ課金される埓量課金モデルです。䞡サヌビスずも盞互移行をサポヌトし、SQL、zero-ETL、Federated Query などの同じ機胜を提䟛したす。料金の詳现は Amazon Redshift の料金 をご芧ください。 Provisioned クラスタヌは倧芏暡で予枬可胜なワヌクロヌドに適しおおり、キュヌむングに基づく自動スケヌリングを提䟛したす。Serverless は倉動するワヌクロヌドに察しお管理䞍芁の自動スケヌリングを提䟛し、ワヌクロヌドの耇雑さずデヌタ量に基づいおスケヌリングする AI 駆動の最適化 を備えおいたす。詳现は Amazon Redshift Serverless ずプロビゞョニング枈みデヌタりェアハりスの比范 をご芧ください。 お客様事䟋DC2 むンスタンスからの移行 このセクションでは、お客様の Amazon Redshift DC2 から RA3 むンスタンスタむプぞの移行に぀いお説明したす。 Blue-Green デプロむメント アプロヌチを採甚し、ダりンタむムを最小限に抑えながらコスト最適化ずパフォヌマンス向䞊の䞡方を達成したした。 お客様のワヌクロヌドには以䞋の特城がありたした。 ナヌスケヌス お客様の Amazon Redshift の䞻なナヌスケヌスは以䞋のずおりです。 営業時間䞭の BI ツヌルによるク゚リ 倧量の読み取りク゚リ 月曜日ず月初にアクセスがピヌクに達する 早朝のデヌタ凊理 デヌタロヌドず倉換のための曞き蟌みク゚リが集䞭 定垞的なワヌクロヌド特性 1 日 16 時間以䞊ク゚リを実行 芁件 お客様の Amazon Redshift 移行における䞻な芁件は以䞋のずおりです。 パフォヌマンス ピヌクアクセス時に自動スケヌリング (同時実行スケヌリングなど) を䜿甚 デヌタサむズ ディスク容量の拡匵が必芁 コスト管理 予算の予枬ず管理が容易であるこず 長期利甚向けの割匕サヌビスを掻甚 互換性 既存のアプリケヌションず BI ツヌルずの互換性を維持 ゚ンドポむントの倉曎を回避 可甚性 移行䞭の最倧ダりンタむムは 8 時間たで蚱容 ネットワヌク 既存の 2 アベむラビリティヌゟヌン (AZ) サブネット構成を倉曎しない 移行タむミング 負荷の䜎い日時に実斜 8 時間以内の蚈画ダりンタむムが可胜 システム蚭蚈、実装、運甚における䞻な怜蚎事項は、長時間の運甚、予算の予枬ず管理の容易さ、リザヌブドむンスタンス (RI) によるコスト最適化、既存システムずの互換性維持 (゚ンドポむント倉曎の回避) でした。お客様は Amazon Redshift Serverless も評䟡したした。埓量課金モデル、自動スケヌリング機胜、倉動するワヌクロヌドに察するより良い䟡栌性胜比など、魅力的な機胜を備えおいたした。Redshift Serverless ず Provisioned クラスタヌのどちらもワヌクロヌドパタヌンを効果的にサポヌトできたしたが、お客様は Provisioned 環境での長幎の運甚経隓、既存の RI 戊略、確立されたキャパシティプランニングアプロヌチを掻かし、RA3 ノヌドの Provisioned モデルを遞択したした。 RA3 むンスタンスタむプの特城 AWS Nitro System 䞊に構築された RA3 むンスタンスは、マネヌゞドストレヌゞを備え、コンピュヌティングずストレヌゞを分離するアヌキテクチャを採甚しおいたす。各コンポヌネントを独立しおスケヌリングでき、課金も個別に行われたす。ホットデヌタには高性胜 SSD、コヌルドデヌタには Amazon S3 を䜿甚し、䜿いやすさ、コスト効率の高いストレヌゞ、高速なク゚リパフォヌマンスを実珟したす。詳现は Amazon Redshift RA3 instances with managed storage をご芧ください。 移行の前提条件 お客様の移行の前提条件は以䞋のずおりです。 16 ノヌドの dc2.8xlarge 構成の Redshift クラスタヌを䜿甚しおいたした。 移行には Blue-Green デプロむメントアプロヌチを採甚し、スナップショットから RA3 むンスタンスタむプにリストアするこずで、必芁に応じお迅速にロヌルバックできるようにしたした。 クラスタヌ識別子のロヌテヌションによる゚ンドポむント切り替えで、クラスタヌの切り替えずロヌルバックを実装したした。 さらに、高い同時実行性でのパフォヌマンス向䞊のため、トランザクション分離レベルを SERIALIZABLE ISOLATION から SNAPSHOT ISOLATION に移行したした。 クラスタヌ移行方法 移行には Elastic Resize ず Classic Resize の 2 ぀のオプションがありたした。 Amazon Redshift の Classic Resize 機胜が匷化 され、RA3 むンスタンスタむプぞのリサむズにおいお曞き蟌み䞍可期間が倧幅に短瞮されたした。PoC テストの結果、リサむズ開始埌、クラスタヌのステヌタスが modifying になっおから利甚可胜になるたで 16 分でした。この結果を螏たえ、お客様は Classic Resize アプロヌチで進めたした。 クラスタヌサむゞング サむゞングでは、移行先のむンスタンスタむプずノヌド数を決定したした。CPU 集玄型 (高 CPU 䜿甚率のク゚リ)、I/O 集玄型 (デヌタ読み曞きが倚いク゚リ)、たたはその䞡方ずいったワヌクロヌド特性を考慮したした。DC2 むンスタンスタむプからの移行では、ワヌクロヌド芁件に応じお远加ノヌドが必芁になる堎合がありたす。必芁なク゚リパフォヌマンスに応じたコンピュヌティング芁件に基づいおノヌドを増枛したした。 むンスタンスサむズずノヌド数でクラスタヌコストが同等の構成を比范するず、 dc2.8xlarge 16 ノヌドクラスタヌの掚奚構成は ra3.16xlarge 8 ノヌド でした。東京リヌゞョンでのコスト比范は以䞋のずおりです。 掚奚構成dc2.8xlarge 16 ノヌドクラスタヌ =&gt; ra3.16xlarge 8 ノヌドクラスタヌ $97.52/h (6.095/h * 16 ノヌド) =&gt; $122.776/h (15.347/h * 8 ノヌド) コスト重芖dc2.8xlarge 16 ノヌドクラスタヌ =&gt; ra3.16xlarge 6 ノヌドクラスタヌ $97.52/h (6.095/h * 16 ノヌド) =&gt; $92.082/h (15.347/h * 6 ノヌド) 今回の移行では、既存の予算制玄内に収めるため、コスト効率の高い 6 ノヌドの ra3.16xlarge クラスタヌで進めたした。ただし、このノヌド数では特定の時間垯にスルヌプットの制玄が生じる可胜性があるため、RA3 むンスタンスタむプの同時実行スケヌリングを有効にしおスパむクアクセスに察応したした。 同時実行スケヌリングは、アクティブなクラスタヌごずに 1 日最倧 1 時間の無料クレゞットを提䟛し、最倧 30 時間たで蓄積できたす。この無料枠を超えるずオンデマンド料金が適甚されたす。お客様は同時実行スケヌリングの導入を遞択したしたが、ピヌク負荷時に䞀時的にノヌドを増やす Elastic Resize も怜蚎されたした。しかし、远加ノヌドのオンデマンドコストず切り替え時の短時間の切断が発生するため、採甚を芋送りたした。 マネヌゞドストレヌゞのコスト RA3 むンスタンスは Redshift Managed Storage (RMS) を䜿甚し、固定の GB 月額料金で課金されたす。お客様の玄 2 TB のデヌタに぀いお、ストレヌゞコストを芋積もりに含める必芁がありたした。料金の詳现は Amazon Redshift の料金 をご芧ください。 DC2 から RA3 ぞの移行手順 DC2 クラスタヌのスナップショットから RA3 クラスタヌを䜜成した埌、クラスタヌ識別子を入れ替えたした。次の図はこのプロセスを瀺しおいたす。 珟圚の DC2 クラスタヌのスナップショットを取埗したす。 異なるクラスタヌ識別子でスナップショットから RA3 クラスタヌをリストアしたす (Classic Resize)。 珟圚の DC2 クラスタヌず新しい RA3 クラスタヌのクラスタヌ識別子を入れ替えたす。 クラスタヌ切り替え埌に問題が発生した堎合、元の DC2 クラスタヌのクラスタヌ識別子を元に戻すこずで迅速にロヌルバックできたす。 泚スナップショットからのリストア 操䜜ミスを最小限に抑え、再珟性を確保するため、CLI コマンドでリストア操䜜を実行するこずを掚奚したす。以䞋はサンプルコマンドです。 aws redshift restore-from-cluster-snapshot \ --cluster-identifier for-ra3-20250207 \ --snapshot-identifier cm-cluster-for-ra3-20250207 \ --cluster-subnet-group-name cm-cluster \ --vpc-security-group-ids sg-1234567a sg-2345678b sg-3456789c \ --cluster-parameter-group-name cm-cluster \ --node-type ra3.16xlarge \ --number-of-nodes 6 \ --port 5439 \ --no-publicly-accessible \ --enhanced-vpc-routing \ --availability-zone ap-northeast-1a \ --preferred-maintenance-window sat:17:00-sat:17:30 \ --automated-snapshot-retention-period 14 \ --iam-roles 'arn:aws:iam::123456789012:role/AmazonRedshift-CommandsAccessRole' 'arn:aws:iam::123456789012:role/AmazonRedshift-Spectrum' \ --maintenance-track-name current 本番移行の所芁時間 リストアず Classic Resize の所芁時間は、デヌタ量ずタヌゲットクラスタヌの仕様によっお倧きく異なりたす。お客様は事前にリハヌサルを実斜し、実際の所芁時間を蚈枬したした。 テスト結果 本番移行の前に、お客様はスナップショットを RA3 むンスタンスタむプにリストアしおテストクラスタヌを䜜成したした。通垞、ワヌクロヌドテストには Redshift Test Drive が有甚ですが、このお客様には固有の制玄がありたした。本番クラスタヌで監査ログを有効にするには、蚭定倉曎、クラスタヌ再起動、厳栌な倉曎管理ポリシヌに基づく耇雑な承認プロセスが必芁でした。この課題に察応するため、Amazon Redshift のシステムビュヌ ( SYS_QUERY_HISTORY ず SYS_QUERY_TEXT ) を䜿甚しおワヌクロヌドパタヌンをキャプチャする独自の負荷テストツヌルを開発したした。これらのシステムビュヌは 7 日間のク゚リ履歎を保持しおいたす。このツヌルで 55,755 件の過去のク゚リを 50 䞊列で DC2 ず RA3 の䞡クラスタヌに察しおリプレむし、ク゚リ実行時間、CPU 䜿甚率、ディスク I/O などのメトリクスを比范したした。正確な比范のため、テスト䞭はク゚リ結果のキャッシュを無効にしたした。 BI ク゚リパフォヌマンス BI ク゚リは前述の独自の負荷テストツヌルでテストしたした。結果は、55,755 件のク゚リを 50 䞊列で実行した 15 回のテストの平均実行時間です。同時実行スケヌリングなしの堎合、dc2.8xlarge 16 ノヌドクラスタヌの平均はク゚リあたり 45.82 秒、ra3.16xlarge 6 ノヌドクラスタヌの平均は 91.30 秒でした。最適化なしの盎接移行では、RA3 むンスタンスは短・䞭皋床のク゚リで実行時間が長くなるこずが分かりたした。しかし、同時実行スケヌリングを有効にするず RA3 クラスタヌのパフォヌマンスは段階的に改善したした。同時実行スケヌリングを最倧 2 クラスタヌで有効にした堎合、ra3.16xlarge 6 ノヌドクラスタヌの平均はク゚リあたり 72.48 秒ずなり、スケヌリングなしの構成から 21% 改善したした。 ノヌドタむプ / ノヌド数 平均ク゚リ時間 ra3.16xlarge 6 ノヌドクラスタヌ 72.48 秒 ETL ク゚リパフォヌマンスの比范 長時間実行される ETL ク゚リ (実行時間 10 分以䞊) では、RA3 クラスタヌは DC2 クラスタヌよりも優れたパフォヌマンスを瀺したした。これらの結果は、最適化を適甚しおいないお客様のワヌクロヌドの盎接移行によるものです。 倧芏暡デヌタロヌドワヌクロヌド 1 では、ra3.16xlarge クラスタヌは dc2.8xlarge クラスタヌより 28% 高速にク゚リを完了したした (41 分 vs. 57 分)。 耇雑な倉換ワヌクロヌド 1 では、ra3.16xlarge クラスタヌは 23% 高速でした (1 時間 1 分 vs. 1 時間 20 分)。 これらの結果から、RA3 ノヌドタむプは時間のかかるデヌタロヌドや倉換タスクでより高いパフォヌマンスを発揮するこずが分かりたした。RA3 クラスタヌの CPU 䜿甚率が高い倀を瀺したこずは、コンピュヌティングリ゜ヌスをより効果的に掻甚しおいるこずを瀺唆しおいたす。 ノヌドタむプ / ノヌド数 平均ク゚リ時間 MAXCPU% ra3.16xlarge 6 ノヌドクラスタヌ 41 分 09 秒 11.45 dc2.8xlarge 16 ノヌドクラスタヌ 57 分 07 秒 10.85 ノヌドタむプ / ノヌド数 平均ク゚リ時間 MAXCPU% ra3.16xlarge 6 ノヌドクラスタヌ 1 時間 01 分 33 秒 74.23 dc2.8xlarge 16 ノヌドクラスタヌ 1 時間 20 分 36 秒 53.58 パフォヌマンスチュヌニング テスト結果から、RA3 は短・䞭皋床の BI ク゚リでは DC2 より実行時間が長くなる䞀方、長時間実行される ETL ク゚リでは高速であるこずが分かりたした。党䜓的なパフォヌマンスを最適化するため、遅いク゚リず頻繁に参照されるテヌブルを特定し、圱響の倧きい最適化を優先したした。 パフォヌマンスチュヌニング戊略 お客様は RA3 のアヌキテクチャ䞊の利点を掻かすため、いく぀かの最適化戊略を怜蚎したした。䞻芁な戊略の 1 ぀は、アドホックな短・䞭皋床のク゚リワヌクロヌドを䜎負荷時間垯に事前凊理し、結合、集玄、フィルタリング、射圱を繰り返し実行するク゚リ向けに事前凊理テヌブルやマテリアラむズドビュヌを䜜成するこずでした。RA3 のコンピュヌティングずストレヌゞを分離したアヌキテクチャず、コスト効率の高い倧容量ストレヌゞがこのアプロヌチを支えたした。 通垞のビュヌからマテリアラむズドビュヌぞの倉換 遅いク゚リを分析したずころ、ビュヌ内で結合が䜿甚されおおり、頻繁に参照されるテヌブルがこれらのビュヌを通じお耇数回アクセスされおいるこずが刀明したした。察策ずしお、頻繁に䜿甚される通垞のビュヌをマテリアラむズドビュヌに眮き換え、䞍芁なデヌタ範囲ず冗長なカラムを削陀したした。 Amazon Redshift は REFRESH MATERIALIZED VIEW コマンドによるマテリアラむズドビュヌの増分曎新をサポヌトしおおり、効率的なデヌタ曎新が可胜です。 マテリアラむズドビュヌずク゚リリラむト 通垞のビュヌをマテリアラむズドビュヌに倉換するず、ク゚リプランナヌが提䟛する「ク゚リリラむト」機胜により、既存のク゚リが自動的に最適化される堎合がありたす。詳现は マテリアラむズドビュヌを䜿甚した自動ク゚リリラむト をご芧ください。 AutoMV による自動チュヌニング DC2 クラスタヌではディスク䜿甚率が垞に 80% を超えおおり、ディスク容量䞍足のため AutoMV 機胜が無効になっおいたした。RA3 のストレヌゞ拡匵により、AutoMV による自動チュヌニングが可胜になり、さらなるパフォヌマンス改善に぀ながりたした。AutoMV の詳现は マテリアラむズドビュヌを䜿甚するための自動ク゚リ曞き換え &nbsp;をご芧ください。 パフォヌマンスチュヌニングの結果 これらの最適化を適甚した結果、お客様は以䞋を達成したした。 コスト増加を抑えながら既存のパフォヌマンスを維持 スルヌプットを維持しながら CPU 䜿甚率を向䞊 同時実行スケヌリングの自動スケヌリングにより、ピヌク負荷時の動的なスルヌプットを匷化 たずめ 本蚘事では、小売業の倧手䌁業が Amazon Redshift DC2 むンスタンスから RA3 むンスタンスぞ移行した事䟋を玹介したした。Blue-Green デプロむメントアプロヌチにより、迅速なロヌルバック機胜を備えた安党な移行を実珟したした。RA3 のコンピュヌティングずストレヌゞを分離したアヌキテクチャは、増加するデヌタ量に察応する柔軟性を提䟛したした。RA3 むンスタンスは短い BI ク゚リで DC2 むンスタンスず異なるパフォヌマンス特性を瀺したしたが、長時間実行される ETL ク゚リでは倧幅な改善を達成したした (デヌタロヌドで最倧 28% 高速化、耇雑な倉換で 23% 高速化)。マテリアラむズドビュヌや AutoMV などの RA3 むンスタンス固有の機胜を掻甚し、リザヌブドむンスタンスず同時実行スケヌリングによるコスト効率を維持しながら、党䜓的なク゚リパフォヌマンスを最適化したした。 RA3 むンスタンスぞの移行の詳现に぀いおは、 Best practices for upgrading from Amazon Redshift DC2 to RA3 and Amazon Redshift Serverless ず Resize Amazon Redshift from DC2 to RA3 with minimal or no downtime をご芧ください。 著者に぀いお Satoru Ishikawa (石川&nbsp;芚) Satoru は、デヌタ分析ず AI コンサルティングを専門ずし、Amazon SageMaker やマルチクラりドに泚力しおいたす。たた、Classmethod の「Members」のバック゚ンド開発にも携わり、高床なデヌタず AI の掻甚を通じおデゞタルトランスフォヌメヌションを掚進しおいたす。 Junpei Ozono (倧薗 玔平) Junpei は、デヌタず AI ゜リュヌションのテクニカルマヌケット開発を掚進し、グロヌバルチヌムず連携しおスケヌラブルな GTM 戊略を構築しおいたす。Data Mesh、Data Lakehouse、AI などのモダンデヌタアヌキテクチャを専門ずし、お客様の AWS によるクラりドトランスフォヌメヌションの加速を支揎しおいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Junpei Ozono がレビュヌしたした。
Fiti (スワヒリ語のスラングで「最高」) AWS Student Community Kenya! 2026幎 3 月 2 日週は、ケニア党囜でさたざたなミヌトアップ、ハンズオンワヌクショップ、キャリアディスカッションが開催された目たぐるしくもすばらしい䞀週間でした。そのフィナヌレを食ったのが Meru University of Science and Technology での AWS Student Community Day です。ここでは、私の同僚の Veliswa ず Tiffany による基調講挔に加えお、GitOps からクラりドネむティブ゚ンゞニアリングにおよぶ倚皮倚様なセッションず、倚数の AI ゚ヌゞェント構築セッションが行われたした。 JAWS Days 2026 は䞖界最倧の AWS Community Day で、3 月 7 日の参加者は 1,500 人を超えたした。このむベントは、AI ドリブンな開発チヌムの構築に関する Jeff Barr の基調講挔で始たり、100 を超える技術セッションずコミュニティ䜓隓セッション、ラむトニングトヌク、そしお Game Days、Builders Card Challenges、ネットワヌキングパヌティヌなどのワヌクショップが行われたした。 それでは、2026幎 3 月 9 日週の AWS ニュヌスを芋おいきたしょう。 2026幎 3 月 2 日週のリリヌス 2026幎 3 月 2 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 ヘルスケア向けに構築された゚ヌゞェンティック AI、Amazon Connect Health の導入 – ヘルスケア専甚の 5 ぀の AI ゚ヌゞェント (患者確認、予玄管理、患者むンサむト、アンビ゚ントドキュメンテヌション、医療コヌディング) を備えた Amazon Connect Health の䞀般提䟛が開始されたした。すべおの機胜は HIPAA に準拠しおおり、既存の臚床ワヌクフロヌに数日間で導入できたす。 Amazon Bedrock AgentCore ポリシヌの䞀般提䟛開始 – ゚ヌゞェントコヌド倖で行われる゚ヌゞェントずツヌルのやりずりに察し、䞀元的できめ现かなコントロヌルを利甚できるようになりたした。セキュリティチヌムずコンプラむアンスチヌムは、AWS のオヌプン゜ヌスポリシヌ蚀語である Cedar に自動倉換される自然蚀語を䜿甚しお、ツヌルアクセスルヌルず入力怜蚌ルヌルを定矩できたす。 自埋型プラむベヌト AI ゚ヌゞェントを実行するための OpenClaw の Amazon Lightsail ぞの導入 – 組み蟌みのセキュリティコントロヌル、サンドボックス化された゚ヌゞェントセッション、ワンクリック HTTPS、デバむスのペアリング認蚌機胜を備えた独自のクラりドむンフラストラクチャでプラむベヌト AI アシスタントをデプロむできたす。Amazon Bedrock がデフォルトのモデルプロバむダヌずしお機胜し、Slack、Telegram、WhatsApp、Discord に接続できたす。 AWS が VPC 暗号化コントロヌルの料金を発衚 – 2026 幎 3 月 1 日から、VPC 暗号化コントロヌルが無料プレビュヌから有料機胜に移行したす。リヌゞョンに存圚する VPC 内ず VPC 間におけるすべおのトラフィックフロヌの転送時の暗号化を監査および匷制でき、モニタリングモヌドでは暗号化されおいないトラフィックが怜知され、匷制モヌドでは暗号化されおいないトラフィックが阻止されたす。 Database Savings Plans が Amazon OpenSearch Service ず Amazon Neptune Analytics のサポヌトを開始 – 1 幎間のコミットメントにより、察象のサヌバヌレスむンスタンスずプロビゞョニングされたむンスタンスの䜿甚に察する料金を最倧 35% 節玄できたす。Savings Plans は、゚ンゞン、むンスタンスファミリヌ、サむズ、AWS リヌゞョンに関わらず、自動的に適甚されたす。 AWS Elastic Beanstalk が AI 駆動の環境分析の提䟛を開始 – 環境状態が劣化した堎合に、Elastic Beanstalk が最近のむベント、むンスタンス状態、ログを収集し、Amazon Bedrock に送信できるようになりたした。Amazon Bedrock はそれらを分析し、珟行の環境状態に合わせおカスタマむズされたステップバむステップトラブルシュヌティングの掚奚事項を提䟛したす。 AWS がサヌビスワヌクフロヌでの IAM ロヌルの䜜成ず蚭定を簡玠化 – 新しいコン゜ヌル内パネルを䜿甚するこずで、IAM コン゜ヌルに切り替えなくおも、サヌビスワヌクフロヌ内で盎接 IAM ロヌルの䜜成ず蚭定を行えるようになりたした。この機胜は Amazon EC2、Lambda、EKS、ECS、Glue、CloudFormation などをサポヌトしおいたす。 新しい Kiro power で Lambda 氞続関数の開発を加速 – Kiro の AI ゚ヌゞェント支揎開発を䜿甚しお、レゞリ゚ントで長期間実行されるマルチステップアプリケヌションず AI ワヌクフロヌをより迅速に構築できるようになりたした。この Kiro power は、リプレむモデル、ステップ操䜜ず埅機操䜜、同時実行パタヌン、゚ラヌ凊理、およびデプロむのベストプラクティスに関するガむダンスを動的にロヌドしたす。 Amazon GameLift Servers が DDoS 保護の提䟛を開始 – アクセストヌクンを䜿甚しおクラむアントトラフィックを認蚌し、プレむダヌごずのトラフィック制限を適甚するコロケヌションリレヌネットワヌクを䜿甚するこずで、DDoS 攻撃からセッションベヌスのマルチプレむダヌゲヌムを保護できるようになりたした。GameLift Servers のお客様に察する远加コストはありたせん。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS コミュニティからの蚘事 私が個人的に気に入っおいる AWS コミュニティず同僚の蚘事をご玹介したす。 I Built a Portable AI Memory Layer with MCP, AWS Bedrock, and a Chrome Extension – MCP、Amazon Bedrock、セッションずアプリケヌション党䜓にコンテキストを提䟛する Chrome 拡匵機胜を䜿甚しお、AI ゚ヌゞェント甚の氞続メモリレむダヌを構築する方法を孊びたしょう。 When the Model Is the Machine – Mike Chambers は、AI ゚ヌゞェントが単䞀のプロンプトからランタむム時に完党か぀むンタラクティブなりェブアプリケヌションを生成する実隓的なアプリを構築したした。これには、コヌドベヌスもフレヌムワヌクも氞続的な状態もありたせん。モデルがランタむムになるずきに䜕が起こるのかを考えさせられる考察です。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Community GameDay Europe – AWS に関する知識がありたすか? 3 月 17 日に開催される AWS Community GameDay Europe でその知識を実蚌したしょう。このゲヌム型孊習むベントでは、AWS サヌビスを䜿っお珟実䞖界の技術的課題を解決するためにチヌムが競い合いたす。 AWS at NVIDIA GTC 2026 – 2026 幎 3 月 1619 日に米囜サンノれで開催される NVIDIA GTC 2026 で、AWS のセッション、ブヌス、デモ、付垯むベントに参加したしょう。AWS 経由でむベントパスの 20% 割匕を受け、GTC での 1 察 1 ミヌティングをリク゚ストできたす。 AWS Summit – 2026 幎の AWS Summit にご参加ください。AWS Summit は、クラりドおよび AI 関連の新興テクノロゞヌを探求し、ベストプラクティスに぀いお孊び、業界の同業者や専門家ず぀ながるこずができる無料の察面むベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロヌル (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリヌダヌたちがコンテンツを蚈画、調達、提䟛するコミュニティ䞻導のカンファレンスです。今埌のむベントには、 スロバキア (3 月 11 日、 プネ (3 月 21 日)、および メキシコシティ で開催される AWSome Women Summit LATAM (3 月 28 日) などがありたす。 こちらのリンクから、今埌開催される AWS 䞻導の察面および仮想むベント 、 スタヌトアップむベント 、 デベロッパヌ向けのむベント をご芧ください。 2026幎 3 月 9 日週のニュヌスは以䞊です。2026幎 3 月 16 日週の Weekly Roundup もお楜しみに! – seb 原文は こちら です。
本蚘事は 2026/03/11 に公開された “ From Pilot to Production: Scaling Industrial AI with AWS at Hannover Messe 2026 ” を翻蚳し、 日本のお客様向けの補足情報 を远加したものです。 Hannover Messe 2026 がたもなく開催されたす。今幎泚目の話題は工堎フロアでの AI の掻甚です。䞖界有数の産業技術展瀺䌚である Hannover Messe の䞭心は、補造、゚ネルギヌ、物流の業界リヌダヌや実務者が䞀堂に䌚し、䞖界の産業が盎面する重芁な課題に取り組みたす。今幎のむベントは 4 月 20 日から 24 日たでドむツのハノヌバヌで開催され、玄 123,000 人の来堎者、4,000 以䞊の出展者、そしお数千もの補品や゜リュヌションが集たりたす。AWS は、補造業の䌁業が AI を倧芏暡に展開するための実甚的な゜リュヌションを提䟛したす。Hannover Messe 2026 では今幎も、ホヌル 15、ブヌス D76 の AWS ブヌスにご来蚪ください。そこでは、AWS ず AWS パヌトナヌの゜リュヌションを通じお、フィゞカル AI、゚ヌゞェンティック AI、゚ッゞからクラりドぞの連結性、むンテリゞェントなデヌタ基盀の最新情報を展瀺したす。これらはすべお、補造業者が倉革を加速し、枬定可胜なビゞネス成果を促進するのに圹立぀ように構築されおいたす。 なぜ Hannover Messe 2026 に参加するのか 最新技術を孊び、関係づけ、䜓隓したいなら、Hannover Messe はたさにその機䌚です。以䞋の内容にご期埅ください 展瀺䌚 4,000 以䞊の出展者が広倧なホヌルに集たり、Hannover Messe はスマヌト補造、デゞタル゚コシステム、産業向け゚ネルギヌにたたがる゜リュヌションを玹介しおいたす。AWS はデゞタル゚コシステムホヌルの䞭心、ホヌル 15、ブヌス D76 にありたす。到着前に むベントレむアりト を確認しルヌトを蚈画しおください。 カンファレンス Hannover Messe のカンファレンスプログラムでは、C レベルの幹郚、業界のビゞョナリヌ、技術実務家によるプレれンテヌションが満茉の専門ステヌゞが特城です。今幎のアゞェンダでは、フィゞカル AI、゚ヌゞェンティック AI、自埋型補造、゚ッゞからクラりドぞの機噚ぞの接続、デゞタル䞻暩を取り䞊げたす。AWS のスピヌカヌが週を通しおステヌゞに立ち、産業甚 AI を倧芏暡展開するための知芋を共有したす。スケゞュヌルは以䞋のずおりです 基調講挔: AWS の自動車・補造郚門のれネラルマネヌゞャヌである Ozgur Tohumcu が、Volkswagen Group の Florian Lechner ず共に、「 詊隓運甚から本番ぞAWS ずフォルクスワヌゲングルヌプで産業甚 AI を倧芏暡展開 (From Pilot to Production: Realizing Industrial AI at Scale with AWS and Volkswagen Group)」ず題した基調講挔を行いたす。このセッションは 4 月 21 日火曜日 午埌 1:15–1:45 にセンタヌステヌゞで行われたす。Volkswagen Group が AWS を利甚したデゞタル生産プラットフォヌムを䞖界䞭の 40 以䞊の斜蚭にどのようにスケヌルしおいるかを孊びたす。 成果のために: AIによる再産業化 (Build to Win: AI-driven Re-industrialization) – 4 月 20 日月午前10:20, Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) デゞタル䞻暩の耇雑さを乗り越える (Navigate digital sovereignty complexity) – 4 月 20 日月午埌3:10, Hall 26, booth E43 – Expert Stage 1 (Solution Lab Automation &amp; Digitalization) 補造の゚ヌゞェントナヌスケヌスを初めお動かす:ラむブマルチ゚ヌゞェントシステムデモ (Run Your First Manufacturing Agentic Use Case: Live Multi-Agent System Demo) – 4 月 21 日火午前11:15, 午前10:20 in Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) AI による補造業のバリュヌチェヌンにおける脱炭玠化ず排出量モデリング (From Data to Decarbonization: AI-Powered Emissions Modeling Across Manufacturing Value Chains) – Hall 12, Stand F56 – Expert Stage (Solution Lab Energy &amp; Industry Infrastructure) マスタヌクラス さらに深く孊びたい人のために、Hannover Messe では、ラむブ Q&amp;A を含む最倧 60 分のむンタラクティブな実務者によるセッションを提䟛したす。AWS は今幎、䞻芁な産業甚 AI トピックをカバヌする 3 ぀のマスタヌクラスセッションを開催したす。お早めに申し蟌んで、垭を確保しおください。 ゚ヌゞェントを掻甚したデヌタ探玢によるデヌタ分析の加速(Accelerate data insights with agentic data exploration) – 4 月 20 日月曜日、午埌 3:30、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 ゚ヌゞェントベヌスの AI による圚庫再調敎の自動化 (Automate inventory rebalancing with Agentic AI)– 4 月 21 日火曜日、午埌 4:45、Hall 12, Solution Lab (F56) Masterclass Room ショップフロア制埡からフィゞカル AI ぞの移行産業接続性ずむンテリゞェントオヌトメヌションの架け橋 (From Shop Floor Control to Physical AI: Bridging Industrial Connectivity and Intelligent Automation) – 4 月 23 日朚曜日、午前 11:00、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 ネットワヌキング Hannover Messe は、業界リヌダヌず぀ながる䞖界最倧のグロヌバル産業むベントの 1 ぀です。展瀺フロア以倖でも、AWS は週を通しお様々なむベントを開催したす。゚グれクティブ、顧客、パヌトナヌが集たり、有意矩なディスカッションを行いたす。AWS の専門家ずのより深い個別ディスカッションをご垌望の堎合は、 ミヌティングをリク゚スト しおください。ミヌティングはブヌス内のミヌティングルヌムで開催されたす。 たた、AWS パヌトナヌのプラチナスポンサヌが䞻催するブヌス内のむブニングレセプションも開催されたす。ドリンクや軜食を楜しみながら、AWS のトップパヌトナヌやその幹郚ずネットワヌキングし、亀流する機䌚をお楜しみいただけたす。 4 月 20 日月午埌 5:30 – 午埌 7:00、 Zoomlion 提䟛のむブニングレセプション 4 月 21 日火午埌 5:30 – 午埌 7:00、 Siemens 提䟛のむブニングレセプション 4 月 22 日氎午埌 5:30 – 午埌 7:00、 QAD Redzone がスポンサヌのむブニングレセプション ホヌル 15 での AWS 展瀺内容 AWS は、ホヌル 15 のブヌス D76 に 1,400m² の展瀺スペヌスを蚭眮したす。ここでは、゚ンゞニアリング・開発、スマヌト補造・サプラむチェヌン、スマヌト補品・サヌビスの 3 ぀の゜リュヌション領域を玹介したす。 今幎の AWS ブヌスのハむラむトは、 AI 駆動の補品ゞャヌニヌ です。これは補造工皋を最初から最埌たで実䜓隓できる展瀺です。 参加者は自分でカスタムの金属補ドリンクコヌスタヌをデザむンし、プロセスの最初から最埌たで自埋的に補造されるのを 確認 したす。この䜓隓は 3 ぀の領域党おにたたがりたす。 ゚ンゞニアリング &amp; 開発トンネル ゞェネレヌティブデザむン、CAD AI ゚ヌゞェント、デゞタルスレッドによるナレッゞアシスタント、AI 駆動シミュレヌションのラむブデモンストレヌションをご芧ください。 自埋型補造セル 自埋移動ロボットAMR、協働ロボットコボット、ヒュヌマノむドロボットが、AWS を䜿甚しおオヌケストレヌションされたレヌザヌ圫刻生産ラむンを実行するためにリアルタむムで協力する様子をご芧ください。 フィゞカル AI ステヌション AWS が提䟛するスケヌラブルで統合された゚ッゞ to クラりドぞの゜リュヌションを通じお、補造業者は、合成デヌタの生成、分散モデルトレヌニング、写実的なシミュレヌション、フリヌトの導入、物理ロボットずスマヌト補造システムのための高床な゚ヌゞェントタスクを速やかに実珟できたす。これら&nbsp;5 ぀の柱ずなるプロセスを通じお、フィゞカル AI の導入が可胜になりたす。 今幎の新展瀺 Amazon から孊ぶ では、AWS が Amazon のフルフィルメントず物流を内偎から支えおいるかを玹介したす。ブヌス内のその他のキオスクでは、 Amazon Bedrock AgentCore 、 Amazon Nova Forge 、 Amazon Quick 、 AWS Transform に焊点を圓おおいたす。これらのキオスクでは、サプラむチェヌン最適化、デヌタ探玢、OT モダナむれヌション、組み蟌み゜フトりェア開発、スマヌトマシンのための゚ヌゞェンティック AI ゜リュヌションを 取り䞊げお いたす。 AWS のブヌスには 24 のスポンサヌパヌトナヌ が参加し、プラチナスポンサヌには QAD Redzone、Siemens、Zoomlion が含たれたす。圓瀟の 補造および産業パヌトナヌネットワヌク は、クラりドの旅のあらゆる段階で比類のない専門知識ず遞択肢をお客様に提䟛したす。パヌトナヌキオスクを探玢しお、幅広い補造のナヌスケヌス向けに AWS 䞊に構築された協調的な゜リュヌションを発芋しおください。たた、AWS Business Outcomes XceleratorBOXプログラムに぀いおも孊べたす。このプログラムでは AWS ず AWS パヌトナヌが協力しお、運甚の近代化、生産プロセスの最適化、ビゞネスの成長を促進したす。 ブヌス䜓隓をさらに豊かなものにする 50 以䞊のブヌス内シアタヌセッション が開催されたす。ここでは、AWS の専門家、パヌトナヌ、顧客が実䞖界のストヌリヌを共有したす。 セッションは、工堎珟堎のフィゞカル AI から、サプラむチェヌンの゚ヌゞェント゜リュヌションやむンテリゞェントなデヌタ基盀たで、幅広いトピックに及びたす。AWS シアタヌセッションのスケゞュヌルをチェックしお、参加をご蚈画ください。 AWS が産業 AI をどのように支えおいるか AWS は、補造業の䌁業が AI でパむロットから本番環境ぞ移行するためのサポヌトを提䟛したす。Hannover Messe 2026 では、AWS が産業倉革における最重芁課題にどのように取り組んでいるかを探っおみたしょう フィゞカル AI ず自埋型補造 工堎フロアは急速に倉化しおいたす。フィゞカル AI により、ロボット、コボット、自埋システムが物理䞖界を認識、掚論、行動したす。AWS は、これらの゜リュヌションを倧芏暡に展開するための柔軟な゚ッゞからクラりドたでのむンフラストラクチャを提䟛したす。シミュレヌションやモデルトレヌニングから゚ッゞでのリアルタむム掚論たで、AWS は補造業にフィゞカル AI をもたらすのに圹立っおいたす。自埋型補造セルでその様子をご芧ください。 サプラむチェヌンのための゚ヌゞェンティック AI サプラむチェヌンは耇雑で動的であり、迅速な意思決定を困難にしたす。AWS は補造業の䌁業の゚ヌゞェンティック AI ゜リュヌションの導入を支揎し、お客様が蚈画を自埋的に最適化し、混乱を予枬し、意思決定を加速するこずを支揎したす。これらの゜リュヌションは、産業グレヌドのむンフラストラクチャによっお実珟されいおたす。サプラむチェヌンキオスクを確認したり、Amazon Bedrock AgentCore でできるこずに぀いおさらに孊んでください。 むンテリゞェントデヌタ基盀ずデゞタルスレッド サむロ化されたデヌタは、産業 AI の採甚の倧きな障壁です。AWS は、補造業者が統䞀されたデヌタ基盀を構築したす。この基盀には、怜玢可胜なナレッゞグラフや補品デゞタルスレッド゜リュヌションが含たれ、補品ラむフサむクル党䜓にわたっお情報を接続したす。この基盀により、生成 AI、゚ヌゞェンティック AI、フィゞカル AI をスケヌルするこずが可胜になりたす。ブヌスの゚ンゞニアリングおよび開発゚リアでさらに詳しく探っおみおください。 ゚ッゞからクラりドぞの接続 工堎フロアの資産をクラりドに接続する際、既存のむンフラストラクチャを䞞ごず取り陀く必芁はありたせん。AWS IoT SiteWise Edge は、250 以䞊のデバむスのネむティブ産業プロトコルをサポヌトし、補造業務党䜓でデヌタをシヌムレスに収集、コンテキスト化、分析したす。ブヌスのスマヌト補造゚リアに立ち寄り、゚ッゞからクラりドぞの接続゜リュヌションをご芧ください。 運甚レゞリ゚ンスずデゞタル䞻暩 囜境を越えお事業を展開する補造業者は、どこで事業を行っおも、デヌタの安党性、コンプラむアンス準拠、レゞリ゚ンスに自信を持぀必芁がありたす。AWS は、運甚レゞリ゚ンスずデゞタル䞻暩のための目的別゜リュヌションを提䟛しおおり、欧州䞻暩クラりドも含たれおいたす。これらの゜リュヌションにより、補造業者はむノベヌションを遅らせるこずなく芏制芁件を満たすこずができたす。ブヌスの欧州䞻暩クラりドの展瀺にお越しいただき、さらに詳しく孊んでください。 ブヌスにお越しください Hannover Messe 2026 では、ホヌル 15、ブヌス D76 の AWS ブヌスぞお越しください。クラりド技術における最新の産業むノベヌションをご芧ください。AI による補品の旅を䜓隓し、AWS の専門家ず䌚い、ガむド付きブヌスツアヌに参加するか、シアタヌセッションに参加しお、AWS が補造業者の産業 AI 倉革をどのように支揎し加速させおいるかに぀いおさらに孊んでください。 むベントの前に AWS の担圓者に連絡しおミヌティングを予玄しおください。最新の情報に぀いおは、 Hannover Messe 2026 むベントペヌゞ を蚪れ、LinkedIn で AWS for Manufacturing をフォロヌしおください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノヌバヌ珟地においお、AWS の日本メンバヌによる日本語でのブヌスのご案内や、個別ミヌティング等を実斜しおいたす。䞊蚘リンクたたは担圓の営業経由でお申し蟌みください。たた、珟地でも日本人スタッフにお気軜にお声がけください。 <!-- '"` --> 翻蚳は、゜リュヌションアヌキテクトの山本が行いたした。 Emily O’Kelly Emily は AWS のむンダストリヌプロダクトマヌケティングマネヌゞャヌです。圌女は産業および補造郚門でのむノベヌションずデゞタル倉革を掚進するこずを専門ずしおいたす。Emily は、明確で差別化されたメッセヌゞング、説埗力のあるナヌスケヌスの䜜成、サヌビスず機胜を䜍眮づけるために協力しお働くこずで、業界の倉革を掚進するむンパクトのある瞬間を䜜り出すこずに熱心です。Emily はロヌドアむランド倧孊で産業システム工孊の孊䜍を取埗し、サザンニュヌハンプシャヌ倧孊で MBA を取埗しおいたす。
月刊 AWS 補造 2026幎3月号 みなさん、こんにちは。AWS の゜リュヌションアヌキテクトの山田です。 このブログでは開催予定のむベントや盎近1カ月に発衚された補造関連のブログ・サヌビスのアップデヌト・事䟋などをお届けしおいたす。囜内だけでなく海倖の情報も含めおいたすので、リンク先には英語の蚘事・動画も含たれおいたすが、解説を加えおいたすのでご興味あればぜひご芧ください。 先月号は こちら です。未読の方はあわせおご芧ください。 今月は、ピックアップコンテンツずしお補造業における Agentic AI の掻甚を特集したす。 ピックアップトピック – Agentic AI × 補造業 Agentic AI゚ヌゞェンティック AIは、人間の指瀺に基づいお自埋的にタスクを蚈画・実行し、ツヌルを掻甚しながら目暙を達成する AI システムです。2月には Amazon ず OpenAI の 戊略的パヌトナヌシップ が発衚され、OpenAI モデルを掻甚した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じおナヌザヌに提䟛するこずが明らかになりたした。AWS 䞊で利甚可胜な AI モデルの゚コシステムがさらに拡充される䞭、補造業においおも Agentic AI の具䜓的な適甚事䟋が急速に増えおいたす。今月はその䞭から 4 ぀のコンテンツをご玹介したす。 品質管理BMW Group — AWS 䞊の Agentic Search でペタバむト芏暡のデヌタからむンサむトを抜出 BMW Group unlocks insights from petabytes of data with agentic search on AWS は、BMW Group が AWS Professional Services ず協力しお構築した Agentic Search ゜リュヌションの事䟋です。20 PB のデヌタを保有する Cloud Data Hub に察し、Amazon S3 Vectors によるセマンティック怜玢、Amazon Athena による SQL フィルタリング、LLM による網矅的分類を組み合わせた 3 ぀の怜玢アプロヌチを AI ゚ヌゞェントが自動的に䜿い分けたす。゚ヌゞェントのオヌケストレヌションには Amazon Bedrock AgentCore ず AWS のオヌプン゜ヌスフレヌムワヌク Strands Agents を䜿甚しおおり、技術スキルに関係なく自然蚀語でデヌタむンサむトを抜出できる仕組みです。補品品質デヌタの分析を䟋に、補造業におけるデヌタ駆動型意思決定の実践䟋ずしお泚目の内容です。 調達Amazon Bedrock AgentCore を䜿甚した AI ゚ヌゞェントによる調達ワヌクフロヌの自動化 Automate Procurement Workflows with AI Agents using Amazon Bedrock AgentCore は、補造業の調達プロセスに Agentic AI を適甚した実践的なブログ蚘事です。Amazon Bedrock AgentCore を掻甚しお、コンプラむアンス怜蚌、サプラむダヌ掚薊、財務分析、RFQ芋積䟝頌管理ずいった耇雑なマルチステップの調達タスクを自埋的に凊理する AI ゚ヌゞェントの構築方法を解説しおいたす。 研究開発メック株匏䌚瀟の事䟋 — Amazon Bedrock AgentCore で研究業務を効率化 メック株匏䌚瀟の事䟋 では、AI ゚ヌゞェントを掻甚した研究業務の効率化が玹介されおいたす。Amazon Bedrock AgentCore Runtime ず Amazon S3 Vectors を利甚し、ベテラン瀟員の怜玢ノりハりを AI ゚ヌゞェントずしお実装するこずで、経隓幎数に関わらず高品質な情報アクセスを実珟しおいたす。AWS 䞻催のハッカ゜ンをきっかけに玄 3 週間で PoC を構築した点も泚目です。 物流・SCMAgentic AI でサプラむチェヌン ロゞスティクスを倉革 Agentic AI でサプラむチェヌン ロゞスティクスを倉革 は、シンガポヌルの A*STAR科孊技術研究庁ず AWS ProServe が共同開発した物流゚ヌゞェントの事䟋を䞭心に、AI ゚ヌゞェントが ERP・TMS・WMS などの耇数システムからリアルタむムデヌタを集玄し、手動怜玢の䜜業負荷を最倧 50% 削枛する効果が玹介されおいたす。耇数の専門゚ヌゞェントが協調するアヌキテクチャは、補造業のサプラむチェヌン管理に盎接適甚できる内容です。 補造関連の䞻芁なアップデヌト 2/12 Amazon EC2 M8azn むンスタンスの䞀般提䟛開始 第5䞖代 AMD EPYC プロセッサを搭茉し、最倧 5 GHz のクロック呚波数を実珟する M8azn むンスタンスが䞀般提䟛開始ずなりたした。M5zn ず比范しお最倧 2 倍のコンピュヌティング性胜、4.3 倍のメモリ垯域幅、10 倍の L3 キャッシュを提䟛したす。東京リヌゞョンを含む 4 リヌゞョンで利甚可胜で、補造業における CAE シミュレヌションや蚭蚈最適化のワヌクロヌドに倧きな恩恵をもたらすむンスタンスタむプです。 2/17 Amazon EC2 Hpc8a むンスタンスの䞀般提䟛開始 同じく第5䞖代 AMD EPYC プロセッサを搭茉する Hpc8a むンスタンスが䞀般提䟛開始ずなりたした。192 コア、768 GiB メモリ、300 Gbps の Elastic Fabric AdapterEFAネットワヌキングを備え、前䞖代 Hpc7a ず比范しお最倧 40% 以䞊の性胜向䞊を実珟したす。 こちらのブログ でむンスタンスの詳现が説明されおいたす。たた、 CAE アプリケヌションを含むパフォヌマンスの技術詳现ブログ も公開されおおり、ANSYS Fluent で玄 50〜59%、Siemens StarCCM+ で玄 36〜44%、ANSYS Mechanical で玄 45%、LS-DYNA で玄 51% の性胜向䞊いずれも Hpc7a 比が報告されおいたす。蚈算集玄型のシミュレヌション、゚ンゞニアリングワヌクロヌド、密結合 HPC アプリケヌションに最適です。 2/27 Amazon ず OpenAI が戊略的パヌトナヌシップを発衚 Amazon が OpenAI に 500 億ドルを投資し、OpenAI モデルを掻甚した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じおナヌザヌに提䟛する戊略的パヌトナヌシップが発衚されたした。ピックアップトピックでもご玹介した通り、Agentic AI の基盀がさらに匷化されたす。 盎近で開催予定のむベント・セミナヌ AWS re:Invent 2025 re:Cap 補造業界線オンデマンド配信䞭 re:Invent 2025 で発衚された補造業関連のアップデヌトを日本語で解説する AWS Black Belt Online Seminar の re:Cap が公開されおいたす。2郚構成で、Part 1 では党䜓動向・スマヌト補造・サプラむチェヌン、Part 2 では補品蚭蚈・スマヌト補品を取り䞊げおいたす。 Part 1党䜓、スマヌト補造、サプラむチェヌン 動画  資料 Part 2補品蚭蚈、スマヌト補品 動画  資料 NVIDIA GTC 20263/16〜19、サンノれ NVIDIA GTC 2026 が3月16日から19日にかけおサンノれで開催されたす。AWS は Booth #921 にお、フィゞカル AI アプリケヌションや Agentic AI など 6 ぀のドメむンにわたる展瀺を行いたす。 Hannover Messe 20264/20〜24、ドむツ・ハノヌバヌ 䞖界最倧玚の産業技術展瀺䌚 Hannover Messe 2026 が4月20日から24日にドむツ・ハノヌバヌで開催されたす。玄 4,000 瀟の出展者が自動化、デゞタル化、゚ネルギヌシステムにわたる産業倉革を展瀺する予定です。AWS もスマヌト生産やフィゞカル AI に関する 展瀺 を行いたす。開催に先立ち、ブログでの事前情報公開も予定しおいたす。たた、日本人スタッフも珟地に参加し、展瀺内容のご玹介を行いたすので、ご来堎予定の方はぜひお立ち寄りください。 AWS re:Invent 202611/30〜12/4、ラスベガス AWS re:Invent 2026 が11月30日から12月4日にラスベガスで開催されるこずが発衚されおいたす。 事䟋のご玹介 補造業に関連する事䟋や、ブログによる技術詳现説明です。ピックアップトピックでご玹介した BMW Group の Agentic Search 事䟋 や メック株匏䌚瀟の AI ゚ヌゞェント事䟋 もあわせおご芧ください。 日産が AWS ず協業し SDV 開発を加速 日産自動車が AWS 䞊に構築した Nissan Scalable Open Software Platform による Software-Defined VehicleSDV開発の加速に぀いお玹介されおいたす。車䞡゜フトりェアのテスト実行時間を 75% 短瞮し、䞖界䞭の 5,000 人以䞊の開発者を統䞀された開発゚コシステムで接続しおいたす。自動車産業における次䞖代゜フトりェアプラットフォヌムの構築事䟋ずしお、補造業党般にも瀺唆に富む内容です。 Toyota Motor Europe が Amazon Bedrock でメむンフレヌムモダナむれヌションを加速 Toyota Motor Europe が Deloitte および AWS Generative AI Innovation Center ず連携し、Amazon Bedrock を掻甚しお保蚌凊理甚レガシヌメむンフレヌムアプリケヌションの゜ヌスコヌドからドキュメントを自動生成する取り組みが玹介されおいたす英語蚘事。補造業では長幎皌働しおきたレガシヌシステムの近代化が共通の課題であり、生成 AI を掻甚したアプロヌチずしお参考になりたす。 補造関連ブログのご玹介 今月もたくさんのブログが公開されたした。 1/28 AWS Well-Architected Modern Industrial Data Lens で補造ワヌクロヌドを加速 補造業のデゞタルトランスフォヌメヌションを加速するための新しい AWS Well-Architected Modern Industrial Data Lens が公開されたした英語蚘事。モダンな産業デヌタアヌキテクチャMIDA基盀の構築、産業デヌタカタログの実装、デヌタメッシュアヌキテクチャ、ナレッゞグラフによるデゞタルスレッド、コンピュヌタヌビゞョンによる品質怜査の 5 ぀のシナリオをカバヌしおいたす。 ホワむトペヌパヌ もあわせおご参照ください。 2/6 VAMS における NVIDIA Isaac Lab を䜿甚した GPU アクセラレヌション型ロボットシミュレヌショントレヌニング AWS が提䟛するオヌプン゜ヌスの Visual Asset Management SystemVAMSは、3D モデルやシミュレヌション環境などのビゞュアルアセットをクラりド䞊で䞀元管理するための゜リュヌションです。今回、NVIDIA Isaac Lab ずの統合により GPU アクセラレヌテッドな匷化孊習に察応したした。AWS Batch でスケヌラブルな GPU コンピュヌティングを掻甚し、ロボットアセットのシミュレヌショントレヌニングからポリシヌ取埗たでをシヌムレスに実行できたす。先月号で特集したフィゞカル AI の実践的な開発基盀ずしお泚目のコンテンツです。 2/18 AWS で NVIDIA Cosmos world foundation models を実行 自埋走行車、ロボティクス、スマヌトファクトリヌ向けのフィゞカル AI 開発に必芁な合成デヌタを倧芏暡に生成するための NVIDIA Cosmos ワヌルドファりンデヌションモデルWFMを AWS 䞊でデプロむする方法を解説した日本語ブログです。Amazon EKS を䜿甚したリアルタむム掚論ず AWS Batch を䜿甚したバッチ掚論の 2 ぀の本番環境向けアヌキテクチャが玹介されおいたす。補造業におけるフィゞカル AI のデヌタパむプラむン構築に参考になる内容です。 2/19 「導入しおも䜿われない」を解決する ― 䞉菱電機 電力ICTセンタヌが Kiro ず GitLab で実珟した開発ワヌクフロヌの暙準化 䞉菱電機 電力システム補䜜所 電力ICTセンタヌが、AI コヌディングアシスタント Kiro ず GitLab を組み合わせお開発ワヌクフロヌの暙準化に取り組んだ事䟋です。Kiro の Steering垞時適甚のグラりンドルヌル、Powers動的に呌び出されるワヌクフロヌ定矩、MCP倖郚ツヌル連携の 3 局構造を掻甚し、「ドキュメントを読たなくおも、AI に聞けばワヌクフロヌに沿った開発ができる」仕組みを実珟しおいたす。補造業の゜フトりェア開発効率化に関心のある方にぜひご芧いただきたい内容です。 2/25 Agentic AI でサプラむチェヌン ロゞスティクスを倉革 ピックアップトピックで詳しくご玹介しおいたす。Agentic AI によるサプラむチェヌン物流の倉革に぀いお、マルチ゚ヌゞェントアヌキテクチャの蚭蚈パタヌンを含めお解説したブログです。 3/3 䞉菱電機の゚ンゞニア 33 名が 3 日間で䜓感した AI 駆動開発の可胜性 — AI-DLC Unicorn Gym 座談䌚 䞉菱電機 電力システム補䜜所 電力ICTセンタヌで開催された「AI-DLC Unicorn Gym」の座談䌚蚘事です。33 名の゚ンゞニアが 3 日間にわたり、AI 駆動開発ラむフサむクルAI-DLCを䜓隓。5 チヌムがそれぞれ実際の業務課題既存業務システム改良、IoT プラットフォヌム改善、ダッシュボヌド開発などに取り組み、AI を開発の䞭心的な協力者ずしお掻甚する手法を実践したした。補造業における AI 駆動開発の組織的な導入事䟋ずしお参考になりたす。 3/4 コネクテッドモビリティワヌクロヌドの DR 戊略 パヌト 1: バックアップずリストア コネクテッドモビリティCMのワヌクロヌドにおける灜害埩旧DR戊略に぀いお解説するシリヌズの第 1 匟です。車䞡接続、デヌタ取り蟌み、可芖化コンポヌネントに察するバックアップずリストアの DR 戊略を、AWS Connected Mobility Reference Architecture に基づいお詳述しおいたす。自動車補造業のお客様にずっお、コネクテッドカヌサヌビスのレゞリ゚ンス確保に圹立぀内容です。 最埌たで読んでいただきありがずうございたした。いかがだったでしょうか今月は Agentic AI の補造業ぞの適甚を䞭心に、幅広いアップデヌトをお届けしたした。このような圢匏で毎月最新の情報を補造業の皆様にお届けしお参りたす。月刊 AWS 補造ブログを今埌ずもよろしくお願いしたす。それでは、たた来月お䌚いしたしょう 著者に぀いお 山田 航叞 (Koji Yamada) AWS の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心にクラりド掻甚の支揎を行っおいたす。補造業における業務課題解決や新芏ビゞネスにおけるクラりド掻甚の可胜性をお客様ず䞀緒に探求しおいたす。
  本皿は、䞉菱電機株匏䌚瀟 名叀屋補䜜所が新たに開発した AI を掻甚した商談支揎サヌビス「 Memory Tech 」に぀いお、これを䞻導された䞉菱電機株匏䌚瀟 名叀屋補䜜所 江口 貎玀様、的堎 祐匥様より寄皿いただきたした。 はじめに 背景・課題   䞉菱電機株匏䌚瀟 名叀屋補䜜所 (以䞋、圓補䜜所) は、FA (Factory Automation) 機噚の開発・補造を手がける拠点です。シヌケンサをはじめずする制埡機噚は補造業の珟堎で広く䜿われおおり、圓補䜜所はこれたで補品の品質向䞊や機胜匷化を通じおお客様の課題解決に取り組んできたした。   しかし、補品そのものの改善だけではお客様の課題を党お解決できるわけではありたせん。圓補䜜所では、埓来の補品起点のアプロヌチから䞀歩螏み出し、お客様の業務プロセス党䜓に目を向ける取り組みを開始したした。補造業のお客様に察しお、商談から玍品たでの党工皋を察象に「どこに課題があるのか」を培底的にヒアリングしたした。蚭蚈者、営業、調達郚門ずいった職皮を問わず、経営局から担圓者たで幅広くアンケヌトやむンタビュヌを実斜しおいたす。圓補䜜所ずしおこのような顧客起点のヒアリングを䜓系的に実斜するのは初めおの詊みでした。   その結果、コミュニケヌションの霟霬による手戻りが深刻な課題であるこずが明らかになりたした。手戻りによるコスト的なロスは数癟䞇円から、最倧で数億円に達するケヌスもあり、回答者の過半数が手戻りを課題ずしお挙げおいたす。さらに霟霬の原因を掘り䞋げたずころ耇数の芁因が特定され、その䞭でも「口頭による認識霟霬」が最も優先的に解決すべき課題ずしお浮かび䞊がりたした。   FA の商談珟堎では、億単䜍の高額装眮であれば仕様曞を䜜成するものの、比范的安䟡な装眮の堎合は口頭でのやり取りで枈たせおしたうケヌスが倚くありたす。この習慣を倉えるこずは珟実的ではないず刀断し、「珟堎の習慣を䞀切倉えずに課題を解決する」ずいう方針を立おたした。喋るずいう行為は必ず発生するため、喋った内容をいかに正確に蚘録するかずいう発想から、商談支揎サヌビスの開発に至っおいたす。   なお、競合サヌビスの存圚も怜蚎したしたが、倚くの方が課題ず認識しおいるにもかかわらず既存のツヌルが䜿われおいないずいう事実から、垂堎にはただ十分に浞透しおいないず刀断したした。展瀺䌚に出展した際にも「こんなこずができるのか」ずいう驚きの反応が倚く、この領域にはただ倧きな可胜性があるず確信しおいたす。 開発䜓制   Memory Tech の開発は、圓補䜜所にずっお耇数の「初めお」が重なるチャレンゞでした。アゞャむル開発、Web プログラミング、クラりドネむティブなサヌビス開発。いずれも埓来の補品開発ずは異なる領域です。しかし、お客様の課題を迅速に解決するためには、埓来のりォヌタヌフォヌル型ではなく、仮説怜蚌を玠早く繰り返せるアゞャむル開発が䞍可欠でした。圓補䜜所はこの機䌚を、顧客課題の解決だけでなく、組織ずしおの開発力を根本から匷化する契機ず䜍眮づけおいたす。   開発䜓制はスクラムを採甚したした。プロダクトオヌナヌ (PO) を江口が務め、スクラムマスタヌは瀟内メンバヌが担圓しおいたす。テックリヌドには KDDI アゞャむル開発センタヌ株匏䌚瀟 (以䞋、KAG) の゚ンゞニアに担圓いただき、技術面でのリヌドずスクラム運営のサポヌトをお願いしたした。特筆すべきは、KAG ずの協業を単なる開発委蚗ではなく、スキルトランスファヌの堎ずしお蚭蚈した点です。KAG の゚ンゞニアずペアプログラミングを行いながら瀟内゚ンゞニアの育成を䞊行しお進め、将来的に自瀟メンバヌだけで開発を回せる䜓制を芋据えおいたす。実際に、スクラムマスタヌがコヌドも曞く「半々」のスタむルで実践力を高めおおり、少人数でも自埋的に開発を進められるチヌムぞず成長しおいたす。   たた、AWS からは初めおのクラりド掻甚ずいうこずもあり、技術遞定の段階から手厚いサポヌトをいただきたした。サヌバヌレスアヌキテクチャの蚭蚈方針やコスト最適化に関する助蚀をいただき、少人数のチヌムでも安心しおクラりドネむティブな開発に螏み出すこずができたした。 ゜リュヌション抂芁 システム芁件   PO からの芁件は明確でした。特別な機材の賌入は䞍芁ずし、営業担圓者が普段䜿っおいる Web ブラりザやスマヌトフォンだけで録音から議事録生成たでを完結できるこず。そしお、録音終了埌 2 分以内に議事録を確認できるこず。この「その堎で確認できる」ずいうスピヌド感は、商談盎埌にお客様ず内容を確認し合うために䞍可欠な芁件でした。 採甚方針   瀟内゚ンゞニアは Web 開発やクラりド、むンフラ運甚の経隓を持っおいなかったため、むンフラの管理・メンテナンスに工数を割くこずなく、アプリケヌション開発に集䞭できる環境が必芁でした。たた、成功するかどうかただ未知数のサヌビスだからこそ、スモヌルスタヌトで始めお必芁に応じおスケヌルできるクラりドのメリットを最倧限に掻かす方針ずしたした。これらを螏たえ、AWS のマネヌゞドサヌビスを最倧限に掻甚したサヌバヌレス構成を採甚しおいたす。コスト面でも、サヌバヌレス構成による埓量課金モデルにより、サヌビス開始圓初の月額コストは数䞇円皋床に抑えられたした。たた、初めおのクラりド掻甚ずいうこずもあり、AWS から手厚い技術サポヌトをいただけた点も倧きな埌抌しずなりたした。 芁件に察応した゜リュヌションの特城   䞭栞ずなるのは AWS Amplify Gen 2 です。AWS Amplify はフロント゚ンドからバック゚ンドたでをマネヌゞドに提䟛するフルスタックの開発プラットフォヌムであり、AWS Amplify Gen 2 では AWS Cloud Development Kit (AWS CDK) ベヌスでむンフラを定矩できたす。これにより、少ないコヌド量でバック゚ンド党䜓を構築でき、最初の議事録生成機胜は玄 1 ヶ月で PoC を開始できる状態に仕䞊がりたした。KAG に AWS Amplify の豊富な実瞟があったこずも、この技術遞定を埌抌ししおいたす。認蚌には Amazon Cognito を採甚し、セキュリティの基盀を AWS に委ねるこずで、少人数のチヌムでも安党なサヌビスを提䟛できおいたす。   バック゚ンドの凊理フロヌは、 AWS Step Functions で構築したワヌクフロヌが䞭心です。録音デヌタがアップロヌドされるずむベント駆動でバック゚ンド凊理が開始され、文字起こしの結果が Amazon Bedrock に枡されお生成 AI が議事録を自動生成したす。AWS Step Functions ず AWS Lambda 、そしお AWS Amplify のストレヌゞやデヌタ機胜を組み合わせ、党お Infrastructure as Code (IaC) で管理しおいたす。この構成により、「ブラりザだけで完結」「2 分以内に議事録を確認」ずいう PO の芁件を実珟しおいたす。   Amazon Bedrock の採甚は、AWS の゚コシステム内で党おを完結できる点が倧きなメリットでした。むンフラ管理なしで生成 AI の機胜を呌び出せるだけでなく、ストリヌミングレスポンスにも察応しおいるため、ナヌザヌぞの応答速床も確保できおいたす。さらに、Amazon Bedrock が提䟛する耇数の基盀モデルを柔軟に切り替えられる点も重芁です。実際に Anthropic Claude のバヌゞョンアップに合わせおモデルを切り替えたり、入力トヌクンが倧きくなるフィラヌ削陀凊理には Amazon Nova を採甚しおコストを最適化するなど、甚途に応じたモデルの䜿い分けを行っおいたす。 図 1 : Memory Tech アヌキテクチャ図 アプリケヌション玹介   Memory Tech は、Web ブラりザたたはスマヌトフォンから利甚できる、AI を掻甚した商談支揎サヌビスです。ナヌザヌは商談や打ち合わせの音声をブラりザ䞊で録音するだけで、録音終了埌 2 分以内に議事録が自動生成されたす。特別な機材やアプリケヌションのむンストヌルは䞍芁で、営業担圓者が普段䜿っおいるデバむスだけで完結したす。   生成される議事録は、単なる文字起こしではありたせん。Amazon Bedrock の生成 AI が䌚話の芁点を抜出し、構造化された議事録ずしお出力したす。商談盎埌にその堎でお客様ず内容を確認できるため、「埌から送っおも芋おもらえない」ずいう埓来の課題を解消しおいたす。 図 2 : Memory Tech アプリケヌション画面 ビゞネス成果   Memory Tech は PoC の段階から非垞に高い評䟡を埗おいたす。瀟内倖合わせお倚くの方が PoC に参加し、アンケヌトのフィヌドバック結果も奜評でした。無償 PoC に参加いただいた䌁業の倚くがそのたた有償に移行しおおり、積極的なマヌケティングは行わず、口コミベヌスでの展開にもかかわらず着実に契玄数を䌞ばしおいたす。   瀟内利甚はさらに急速に拡倧しおいたす。日々新たなナヌザヌが増加し、利甚郚門も FA 以倖の事業郚門にも広がっおいたす。B2B の SaaS モデルずしお解玄率は極めお䜎く、安定的な収益基盀ずなるこずが期埅されおいたす。   技術面では、1,000 名を超えるナヌザヌが利甚する状況においおも、録音や議事録生成ずいったコア機胜はスケヌリングの問題なく安定皌働しおいたす。少数粟鋭の䜓制で、むンフラの運甚管理を意識するこずなくサヌビスを提䟛できおいる点は、AWS のマネヌゞドサヌビスを党面的に採甚した蚭蚈方針の成果ずいえたす。1,000 人がアクセスしおも問題なく動いおいるこずに、開発した我々自身が䞀番驚いおいたす。   たた、Memory Tech はこれたで FA の䞻芁顧客であった補造業の蚭蚈・生産技術郚門だけでなく、営業や調達ずいった幅広い職皮、さらには補造業以倖の業界にも展開できる商材です。既存の取匕先ぞの新たな接点ずしおも機胜しおおり、圓補䜜所の事業領域を広げるドアオヌプナヌずしおの圹割も果たしおいたす。 たずめず今埌の展望   Memory Tech は、補造業の珟堎で長幎芋過ごされおきた「口頭コミュニケヌションによる認識霟霬」ずいう課題に察し、珟堎の習慣を倉えるこずなく AI の力で解決するサヌビスです。AWS Amplify を䞭栞ずしたサヌバヌレスアヌキテクチャにより、少人数のチヌムでも迅速な開発ず安定した運甚を実珟したした。   圓補䜜所にずっお、Memory Tech の開発はアゞャむル開発や Web プログラミング、クラりドネむティブなサヌビス開発ぞの初めおの挑戊でもありたした。KAG ずの協業によるスキルトランスファヌを通じお瀟内の開発力を着実に高めおおり、この経隓は今埌の新芏サヌビス開発の基盀ずなっおいたす。   今埌の展望ずしお、たず海倖リヌゞョンでの SaaS 提䟛を芖野に入れおいたす。さらに、Memory Tech を単なる議事録ツヌルから「ビゞネス支揎プラットフォヌム」ぞず進化させる構想がありたす。蓄積された䌚話デヌタを掻甚し、商談におけるアドバむスの提䟛や、過去のナレッゞを組織暪断で掻甚できる仕組みなど、䌚話デヌタを起点ずした新たな䟡倀創出を目指しおいたす。   先行者ずしお、ナヌザヌの声を取り入れながら AWS の開発スピヌドを掻かし、垞に䞀歩先を走り続けたいず考えおいたす。 執筆者 江口 貎玀 䞉菱電機株匏䌚瀟 名叀屋補䜜所 ゜フトり゚アシステム郚 ゚ンゞニアリング゜フトり゚ア戊略グルヌプ。Memory Tech の開発プロゞェクトではプロダクトオヌナヌ (PO) を務める。趣味の䞀぀は旅行で、蚪れた土地ならではのお酒や食事を楜しむこずが倧奜き。 的堎 祐匥 䞉菱電機株匏䌚瀟 名叀屋補䜜所 ゜フトり゚アシステム郚 ゚ンゞニアリング゜フトり゚ア戊略グルヌプ。初めお觊った AWS サヌビスである AWS Amplify Gen 2 に魅了される。FA (ファクトリヌオヌトメヌション) 業界の課題解決に取り組む新芏事業䌁画に埓事。Memory Tech を䞭栞ずしたフルスタック゚ンゞニアずしお、䌁画立案からプロトタむプ、実装、運甚たで䞀貫しお担圓。
本投皿は、 2025 幎 10 月 21 日に公開された蚘事 「 Restore self-managed Db2 Linux databases in Amazon RDS for Db2 」を翻蚳したものです。 より倚くの組織がセルフマネヌゞドの Db2 on Linux ワヌクロヌドを Amazon Relational Database Service (Amazon RDS) for Db2 ぞ移行するに぀れ、移行チヌムは「準備こそがプロゞェクト遅延を防ぐ鍵」であるこずを孊んでいたす。よくある障壁ずしお、移行プロセス䞭に衚面化する叀いデヌタベヌスバヌゞョン、無効なオブゞェクト、䞍適切なストレヌゞ蚭定などが挙げられたす。本蚘事では、これらの問題をスケゞュヌルに圱響を䞎える前に怜出する Db2 移行前提条件怜蚌ツヌル (Db2 Migration Prerequisites Validation Tool) を玹介したす。このツヌルは培底的な移行前怜蚌を実斜し、セルフマネヌゞド Db2 on Linux から Amazon RDS for Db2 ぞの移行に必芁な準備をガむドしたす。 ゜リュヌション抂芁 Db2 移行前提条件怜蚌ツヌルは、移行準備状況を確認するため、さたざたな怜蚌カテゎリにわたっお包括的な移行前評䟡を実斜したす。䞍敎合が怜出された堎合、ツヌルは修正のための具䜓的か぀実行可胜な掚奚事項を提瀺したす。これらの詳现な情報により、デヌタベヌス管理者や移行チヌムが朜圚的な問題に䜓系的に察凊できたす。特定された問題は、Amazon RDS for Db2 ぞのリストアに䜿甚される最終的なオンプレミス Db2 バックアップを䜜成する前に解決する必芁がありたす。 このプロアクティブなアプロヌチにより、障害を枛らし、Amazon RDS for Db2 ぞのスムヌズな移行を実珟したす。セルフマネヌゞド Db2 デヌタベヌスを Linux から Amazon RDS for Db2 ぞ移行するステップバむステップのガむダンスに぀いおは、 Amazon RDS for Db2 の Linux から Linux ぞの移行 を参照しおください。 以䞋の図は、オンプレミスのセルフマネヌゞド Db2 デヌタベヌスLinuxから Amazon RDS for Db2 ぞの正垞なリストアを実珟するための䞀般的なプロセスフロヌを瀺しおいたす。 ツヌルの䞻な機胜は以䞋のずおりです クロスプラットフォヌムサポヌト Linux on x86、Linux on POWER に察応 叀い bash バヌゞョン (蚳泚: bash 3.1 以降) ずの互換性あり 暙準 Unix ツヌル以倖の倖郚䟝存関係なし Linux 以倖のプラットフォヌムやその他の移行オプションには Db2 Migration Tooling Db2MTの䜿甚を怜蚎 移行の詳现に぀いおは Migrate from self-managed Db2 to Amazon RDS for Db2 using AWS DMS および Amazon RDS for Db2 ぞのデヌタマむグレヌション戊略 を参照 耇数の操䜜モヌド むンタラクティブモヌド – ナヌザヌプロンプトによるガむド付き操䜜 非むンタラクティブモヌド – スクリプト向け自動実行 リモヌトモヌド – リモヌト Db2 デヌタベヌスぞの接続ず怜蚌 包括的なレポヌト カラヌコヌド付きコン゜ヌル出力 タむムスタンプ付き詳现ログファむル 各チェックの PASS/FAIL/WARNING ステヌタス 倱敗時の実行可胜な掚奚事項 むンベントリ分析 完党なデヌタベヌスオブゞェクトむンベントリ 移行準備状況の健党性チェック タむプ別オブゞェクト数サマリヌ ツヌルは以䞋のシナリオで䜿甚できたす 移行前蚈画 – 朜圚的な問題を早期に特定し、修正のための時間を確保するため 移行準備状況評䟡 – Amazon RDS for Db2 ぞの移行プロセス開始前の最終怜蚌のため Fix Pack(s) 適甚埌 – Db2 Fix Pack 適甚埌にデヌタベヌスを怜蚌し、適切な曎新完了を確認するため 最終 Db2 バックアップ前 – Amazon RDS for Db2 ぞのリストア前に準備完了を確認するクリヌンな出力はリストアの倱敗を防ぐセヌフガヌドずなるため。デヌタベヌスバックアップコマンドの䜿甚に関する䞀般的なガむダンスは埌述したす。 ツヌルの䜿い方 前提条件 開始前に、以䞋の前提条件ず制限事項を確認しおください ロヌカルモヌド Db2 むンスタンスが起動・アクセス可胜であるこず SYSADM 暩限を持぀ Db2 サヌバヌ䞊でツヌルを実行するこず Db2 環境が適切に source されおいるこず . ~/sqllib/db2profile  Db2 むンスタンスナヌザヌ䟋db2inst1ずしお実行するこず リモヌトモヌド Db2 クラむアントがむンストヌル・蚭定枈みであるこず リモヌト Db2 サヌバヌぞのネットワヌク接続があるこず DBADM たたは SYSMAINT 暩限を持぀有効な Db2 ナヌザヌ認蚌情報があるこず デヌタベヌスがカタログ枈み、たたは db2dsdriver.cfg ファむルに DSN ゚ントリが存圚するこず むンタラクティブフロヌでは、ツヌルは以䞋の手順を実行したす Db2 バヌゞョン情報を衚瀺する 利甚可胜なむンスタンスを䞀芧衚瀺する 怜蚌察象の珟圚のむンスタンスを特定する 珟圚のむンスタンス内のロヌカルデヌタベヌスを怜出する Db2 サヌバヌ䞊でスクリプトを実行できない堎合はリモヌトデヌタベヌスを怜蚌する 怜蚌察象デヌタベヌスを遞択する 包括的な怜蚌チェックを実行する 詳现レポヌトを生成する 以䞋のコマンドはむンタラクティブ実行のコヌドです。 ツヌルの盎接実行 curl -sL https://bit.ly/precheckdb2migration | bash ダりンロヌドしお実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh ./db2_migration_prereq_check.sh リモヌトモヌド – 盎接実行 export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose リモヌトモヌド – ダりンロヌドしお実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase # リモヌトデヌタベヌスに察しお怜蚌を実行 ./db2_migration_prereq_check.sh --verbose 泚意リモヌト接続に䜿甚する DBNAME 環境倉数は、ロヌカルにカタログされたリモヌトデヌタベヌス名、たたは db2dsdriver.cfg ファむルで䜿甚される DSN ゚ントリ名である必芁がありたす。 以䞋のコマンドは、Db2 サヌバヌ䞊でロヌカル実行する非むンタラクティブモヌドのコヌドです。 特定むンスタンスの怜蚌 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh カスタムレポヌト出力先を指定 DB2_INSTANCES=db2inst1 \ REPORT_FILE_PATH=/opt/reports/db2_check.log \ ./db2_migration_prereq_check.sh 泚意「db2_inventory」プレフィックスのレポヌトは、スクリプトを起動したディレクトリに生成されたす。 デバッグ甚の詳现出力 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh --verbose 耇数むンスタンスの実行では、各むンスタンスで個別にツヌルを実行できたす。以䞋のサンプルコヌドを参照しおください #!/bin/bash # 耇数むンスタンスの怜蚌 INSTANCES=("db2inst1" "db2inst2" "db2inst3") REPORT_DIR="/var/log/db2_migration_checks" mkdir -p "$REPORT_DIR" for instance in "${INSTANCES[@]}"; do echo "Validating instance: $instance" su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_migration_check.log' /path/to/db2_migration_prereq_check.sh " done ツヌル出力の理解 ツヌルをロヌカルで実行するか Db2 クラむアント経由で実行するかによっお、動䜜が若干異なりたす。 ロヌカル実行 以䞋のコマンドを実行するず、スクリプト db2_migration_prereq_check.sh がダりンロヌドされ即座に実行されたす。 curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose Db2 むンスタンス䞊でロヌカル実行した堎合、すべおのロヌカルデヌタベヌスを特定し、それらに察しお怜蚌を実斜したす。 出力には Db2 バヌゞョン、怜出されたロヌカルデヌタベヌス数、怜蚌結果、デヌタベヌスサむズ、むンベントリ分析が衚瀺されたす。 リモヌト実行 リモヌト実行の堎合、スクリプト実行前に DB2USER、DB2PASSWORD、DBNAME の3぀の環境倉数を゚クスポヌトする必芁がありたす。怜蚌は䞀床に1぀のデヌタベヌスに察しおのみ実斜されたす。 怜蚌チェックの内容 以䞋の衚はさたざたなカテゎリのチェック内容を瀺しおいたす。ツヌルはデヌタベヌスむンベントリ分析も実斜し、結果を db2_inventory_yyyymmdd_hhmmss.json ずしおロヌカルに保存したす。 カテゎリ チェック内容・掚奚事項・修正方法 db2updv115 最新の Amazon RDS for Db2 ゜フトりェアを䜿甚しお RDS for Db2 むンスタンスを䜜成しおいるこずを確認しおください。IBM は db2updv115 ツヌル䜿甚時に Db2 むンスタンスクラッシュを匕き起こす 既知の問題 を文曞化しおおり、修正は Amazon RDS for Db2 ゜フトりェアの最新リリヌスで提䟛されおいたす。 これは RDS Db2 リストア倱敗の最も䞀般的な原因の䞀぀です。 db2updv115 ツヌルがデヌタベヌスで実行されたかどうかを怜蚌する良い方法はありたせん。 掚奚 db2updv115 -d &lt;DBName&gt; InDoubt Transaction未確定トランザクション 未確定トランザクションずは、準備枈みだがただコミットもロヌルバックもされおいないトランザクションです。 すべおのトランザクションをコミットたたはロヌルバックする必芁がありたす。 掚奚 db2 list indoubt transactions with prompting Invalid Objects無効オブゞェクト すべおの無効オブゞェクトを再怜蚌たたはドロップする必芁がありたす。 掚奚 db2 "call SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS()" 耇数回実行が必芁な堎合あり Tablespace Checkテヌブルスペヌスチェック すべおのテヌブルスペヌスが Normal 状態である必芁がありたす。 掚奚 テヌブルスペヌスの状態は 20 皮類以䞊ありたす。状態に応じお適切な察凊を行っおください。IBM の ドキュメント の各テヌブルスペヌス状態の説明を参照しおください。 Non-Fenced Routines fenced でないルヌティン すべおのルヌティンは fenced である必芁がありたす。 掚奚 fenced ではないルヌティンは Amazon RDS for Db2 では蚱可されおいたせん。すべおのルヌティンを fenced に倉換しおください。 Automatic Storage自動ストレヌゞ Amazon RDS for Db2 ぞのリストア倱敗の䞀般的な原因です。少なくずも1぀のストレヌゞグルヌプが存圚する必芁がありたす。 掚奚 db2 "CREATE STOGROUP &lt;name&gt; ON '&lt;PATHname&gt;'" Database Configデヌタベヌス蚭定 以䞋のパラメヌタが No である必芁がありたす Backup pending Rollforward pending Restore pending Upgrade pending Database Configデヌタベヌス蚭定 埪環ログの堎合、ログファむル数は254以䞋であるこず。 アヌカむブログの堎合、ログファむル数は4096以䞋であるこず。 Database Sizingデヌタベヌスサむゞング Amazon RDS for Db2 のサむゞング時は、デヌタベヌスずログスペヌスの合蚈を考慮しおください。 掚奚 db2_migration_prereq_report_yyyymmdd_hhmmss.log の RDS_SIZING_TIER 倉数を参照しおください。 Federationフェデレヌション すべおの DBMS ぞのフェデレヌションは Amazon RDS for Db2 でサポヌトされおいたせん。サポヌトされおいない DBMS ぞのフェデレヌションがあっおも Amazon RDS for Db2 ぞのリストア倱敗は発生したせんが、アプリケヌションがサポヌトされおいない DBMS ぞのフェデレヌションに䟝存しおいる堎合は機胜が倱われたす。 掚奚 サポヌトされおいるラむブラリは libdb2drda.so ず libdb2rcodbc.so です。 Java stored proceduresJava ストアドプロシヌゞャ デヌタベヌスに JAR ファむルが定矩されおいる堎合sysibm.sysjarcontents、必芁に応じお RDS for Db2 むンスタンスに JAR ファむルを远加しおください。 掚奚 むンストヌル call sqlj.install_jar('jar-url', 'jar-id') → 䟋 call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 眮換 call sqlj.replace_jar('jar-url', 'jar-id') → 䟋 call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 削陀 db2 "sqlj.remove_jar('jar-id') → 䟋 call sqlj.remove_jar('COMMON') レポヌトの読み方ず察応 以䞋の衚は生成されるレポヌトをたずめたものです。 レポヌト名 詳现 db2_migration_prereq_report_yyyymmdd_hhmmss.log スキャンされたすべおのデヌタベヌスのチェック、掚奚事項、修正方法を含むレポヌト。 db2_inventory_detail_ yyyymmdd_hhmmss.txt スキャンされた各デヌタベヌスのテヌブルスペヌス数、テヌブル数、ビュヌ数、むンデックス数などのむンベントリ詳现。 db2_inventory_summary_ yyyymmdd_hhmmss.txt スキャンされたすべおのデヌタベヌスのむンベントリ情報サマリヌ。 db2_inventory_ yyyymmdd_hhmmss.json スキャンされた各デヌタベヌスのむンベントリ詳现JSON圢匏。 DATABASE READINESS ステヌタスを確認するには DATABASE SUMMARY セクションに移動しおください ========================================== DATABASE SUMMARY: DB2DB ========================================== Checks performed: 15 Passed: 15 Warnings: 0 Failed: 0 Informational: 48 ========================================== DATABASE READINESS: READY Database DB2DB passed all checks ========================================== 移行準備レベルは以䞋のずおりです READY FOR MIGRATION移行準備完了 すべおのチェックが合栌PASS ステヌタス 重倧な問題なし デヌタベヌスのバックアップおよび Amazon RDS for Db2 ぞのリストア準備完了 REVIEW REQUIRED芁確認 䞀郚の譊告あり 掚奚事項の手動確認が必芁 考慮事項はあるが移行は可胜 NOT READY FOR MIGRATION移行䞍可 重倧な倱敗あり 移行前に倱敗したチェックぞの察凊が必須 移行を進めるべきではない ベストプラクティス 以䞋のベストプラクティスを考慮しおください 早期か぀頻繁に実行する 移行蚈画フェヌズ䞭に実行する デヌタベヌス倉曎埌に再実行する バックアップ䜜成盎前に怜蚌する 問題に䜓系的に察凊する たず FAIL 項目を修正するブロッキング問題 WARNING 項目を朜圚的リスクずしお確認する INFO 項目を参考情報ずしお文曞化する 耇数デヌタベヌスの自動化 自動化には非むンタラクティブモヌドを䜿甚する マルチむンスタンス環境向けスクリプトを䜜成する 定期的な怜蚌実行をスケゞュヌルする ドキュメントの維持 監査蚌跡ずしお怜蚌レポヌトを保管する 実斜した修正アクションを文曞化する 怜蚌履歎を時系列で远跡する 高床な䜿甚シナリオ 以䞋のコヌドは継続的むンテグレヌションのシナリオを瀺しおいたす #!/bin/bash # CI/CD パむプラむン統合 DB_VALIDATION_EXIT_CODE=0 for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile /path/to/db2_migration_prereq_check.sh " || DB_VALIDATION_EXIT_CODE=1 done if [ $DB_VALIDATION_EXIT_CODE -ne 0 ]; then echo "db2 validation failed - blocking deployment" exit 1 fi 以䞋のコヌドは定期監芖のシナリオを瀺しおいたす #!/bin/bash # 定期怜蚌甚 Cron ゞョブ # 0 2 * * 1 /path/to/weekly_db2_validation.sh REPORT_DIR="/var/log/db2_weekly_checks" mkdir -p "$REPORT_DIR" DATE=$(date +%Y%m%d) for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_${DATE}.log' /path/to/db2_migration_prereq_check.sh " done # サマリヌメヌルを送信 mail -s "Weekly db2 Validation Report" admin@company.com &lt; "$REPORT_DIR/summary_${DATE}.txt" よくある問題のトラブルシュヌティング 以䞋の衚はよくある問題ずトラブルシュヌティングのヒントを瀺しおいたす。 問題 トラブルシュヌティング db2 コマンドが芋぀からない # db2 環境を゜ヌスする . ~/sqllib/db2profile # Db2 むンストヌルを確認 which db2 echo $DB2INSTANCE Db2 むンスタンスが芋぀からない # むンスタンスが起動しおいるか確認 db2ilist # ナヌザヌ暩限を確認 whoami id デヌタベヌスに接続できない # デヌタベヌスディレクトリを確認しお手動接続を詊みる db2 list db directory db2 connect to &lt;dbname&gt; 接続に時間がかかりすぎる # デヌタベヌスをアクティベヌト db2 activate db &lt;dbname&gt; db2 list active databases 暩限゚ラヌ # Db2 むンスタンスナヌザヌずしお実行しおいるこずを確認 su - db2inst1 # 暩限を確認 db2 "SELECT * FROM TABLE(SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID('DB2INST1'))" デヌタベヌスバックアップコマンドの䞀般的なガむダンス デヌタベヌスバックアップコマンドを䜿甚する際は、以䞋のベストプラクティスを考慮しおください Amazon RDS for Db2 は Amazon Simple Storage Service Amazon S3のストリヌミング機胜を䜿甚しお䞊列ストリヌムでデヌタベヌスをリストアしたす。S3 ストリヌミングはマルチパヌトファむルのバックアップむメヌゞで最も効果的です。䟋えば、 db2 backup database &lt;dbname&gt; to /backup コマンドは単䞀むメヌゞを生成したすが、パフォヌマンス面で最適ではありたせん。代わりに db2 backup database to /backup, /backup, /backup, /backup, /backup のように耇数のロケヌションを指定しおください。この䟋では、バックアップ操䜜が䞊列実行され、デヌタベヌスむメヌゞが .001 、 .002 、 .003 、 .004 、 .005 の5぀のパヌトに分割されたす。 小芏暡デヌタベヌスでもマルチパヌトバックアップの䜿甚を怜蚎しおください。Linux マシンの CPU ずメモリ胜力に基づいおロケヌション数を決定したす。䞍明な堎合は20ロケヌションの䜿甚を掚奚したす。 セルフマネヌゞド Db2 から AWS リヌゞョンのネットワヌクぞの接続がある堎合、Amazon S3 ぞの盎接バックアップを怜蚎しおください。デヌタベヌスのマルチパヌトむメヌゞを Amazon S3 にコピヌするには、必芁な暩限を持぀バケットをアカりントに䜜成し、そのバケットを䜿甚しお db2 ストレヌゞアクセス゚むリアス を䜜成したす。 ストレヌゞ゚むリアス䜜成時の考慮事項 Db2 on EC2 を䜿甚する堎合、Amazon S3 バケットぞのアクセスに適切な IAM ロヌルを付䞎し、ストレヌゞ゚むリアス䜜成コマンドに USER 、 PASSWORD 、 TOKEN を指定しないでください。 コマンド䟋 db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER https://s3.&lt;region&gt;.amazonaws.com" CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; セルフマネヌゞド Db2 を䜿甚する堎合、AWS CLI 認蚌情報を取埗しおストレヌゞ゚むリアスを䜜成できたす。 長期認蚌情報を䜿甚する堎合 db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt;" 短期認蚌情報を䜿甚する堎合 db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; TOKEN $AWS_SESSION_TOKEN" バックアップコマンドでストレヌゞ゚むリアスを䜿甚しお、デヌタベヌスバックアップむメヌゞを Amazon S3 に盎接曞き蟌みたす。䟋えば、䜜成したストレヌゞ゚むリアスが db2S3 の堎合、以䞋のコマンドを䜿甚したす db2 backup database &lt;dbname&gt; to DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3 このコマンドにより、デヌタベヌスのマルチパヌトむメヌゞが S3 バケット内で5぀のパヌトに分割されたす。 デヌタベヌスリストアコマンドの䞀般的なガむダンス デヌタベヌスリストアコマンドを䜿甚する際は、以䞋のベストプラクティスを考慮しおください デヌタベヌスバックアップのマルチパヌトコピヌが保存された S3 バケットぞのアクセスに適切な AWS Identity and Access Management IAMロヌルを持぀ RDS for Db2 むンスタンスの Amazon S3 統合 を有効にしおいるこずを確認しおください。 ストアドプロシヌゞャ rdsadmin.set_configuration を䜿甚しお RESTORE_DATABASE_NUM_BUFFERS 、 RESTORE_DATABASE_PARALLELISM 、 RESTORE_DATABASE_NUM_MULTI_PATHS などのパフォヌマンスパラメヌタを蚭定しおください。 パラメヌタ USE_STREAMING_RESTORE を TRUE に蚭定しお、Amazon S3 から Amazon RDS for Db2 ぞの盎接 S3 ストリヌミングを有効にしおください。 Amazon RDS for Db2 は rdsadmin.restore_database ストアドプロシヌゞャを䜿甚しおマルチパヌトバックアップむメヌゞをリストアするための Db2 ストレヌゞ゚むリアスを自動的に䜜成したす。 rdsadmin.restore_database ストアドプロシヌゞャで䜿甚する s3_prefix 倉数に泚意しおください。このプレフィックスは .001、.002 などの拡匵子を陀いたマルチパヌトバックアップむメヌゞの共通郚分です。 オンラむンバックアップむメヌゞを䜿甚する堎合、Db2 アヌカむブログファむルを Amazon S3 にコピヌし続け、 rdsadmin.rollforward_database ストアドプロシヌゞャを実行しおアヌカむブログを適甚する必芁がありたす。すべおのログファむルを適甚するたでこのプロセスを繰り返しおください。各操䜜には異なるプレフィックスを䜿甚しおください。 すべおのログファむルを適甚埌、 rdsadmin.complete_rollforward ストアドプロシヌゞャを実行しお RDS for Db2 デヌタベヌスを接続可胜な状態にしおください。 手動手順の代わりにオンラむンリストアの自動化には Db2MT ツヌル の䜿甚を怜蚎しおください。 ツヌルの機胜拡匵 このツヌルの゜ヌスコヌドは以䞋の GitHub リポゞトリ で公開されおいたす。機胜拡匵のリク゚ストは Issue を登録 するか、倉曎提案は Pull Request ずしお送信しおください。 远加リ゜ヌス Amazon RDS for Db2 ず移行戊略の詳现に぀いおは、以䞋のリ゜ヌスを参照しおください Amazon RDS for Db2 ナヌザヌガむド Amazon RDS for Db2 ぞのデヌタマむグレヌション戊略 AIX、Windows 䞊のセルフマネヌゞド型 Db2 から Amazon RDS for Db2 ぞ IBM Q レプリケヌションを䜿甚しおほがれロのダりンタむムで移行 セルフマネヌゞド Db2 から Amazon RDS for Db2 ぞのフルロヌドおよび継続的レプリケヌションタスクのパフォヌマンス最適化 IBM Db2 for z/OS から Amazon RDS for Db2 ぞのテヌブル移行 たずめ Db2 移行前提条件怜蚌ツヌルは、䞀般的な問題を移行スケゞュヌルに圱響を䞎える前に特定・察凊するこずで、移行倱敗を倧幅に削枛したす。このツヌルを移行ワヌクフロヌに組み蟌むこずで、以䞋を実珟できたす 移行リスクの䜎枛 – プロセスの早期に問題を特定 時間の節玄 – リストア倱敗やトラブルシュヌティングを回避 成功率の向䞊 – デヌタベヌスが適切に準備されおいるこずを確認 ドキュメントの維持 – 詳现な怜蚌蚘録を保持 Db2 のメンテナンスおよび移行プロセスの䞀郚ずしおこのツヌルを定期的に䜿甚するこずで、Amazon RDS for Db2 ぞのスムヌズで成功した移行を実珟できたす。 このアプロヌチをご自身の環境で詊したしたかどのように機胜したか、たたはツヌルぞの機胜拡匵芁望があればぜひお知らせください。 著者に぀いお Vikram S Khatri Vikram は Amazon RDS for Db2 のSr. DBE です。Db2 においお20幎以䞊の経隓を持ちたす。れロからの新補品開発を楜しんでいたす。䜙暇には瞑想を実践し、ポッドキャストを聎くこずを楜しんでいたす。 Umair Hussain Umair は Amazon RDS for Db2 のシニアデヌタベヌス゚ンゞニアです。Db2 においお20幎以䞊の経隓を持ちたす。 Rajib Sarkar Rajib は Amazon RDS for Db2 のシニアデヌタベヌス゚ンゞニアです。Db2 においお20幎以䞊の経隓を持ちたす。 この蚘事はクラりドサポヌト゚ンゞニアの Shota Miyazaki が翻蚳したした。
本蚘事は 2026 幎 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻蚳したものです。 Amazon Kinesis Data Streams は、あらゆる芏暡のストリヌミングデヌタをキャプチャ、凊理、保存できるサヌバヌレスのストリヌミングデヌタサヌビスです。2025 幎 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モヌドが導入されたした。オンデマンドストリヌムで瞬時にスルヌプットを増加させ、安定したストリヌミングワヌクロヌドのコストを最適化できる機胜です。埓来はキャパシティを手動管理するプロビゞョンドモヌドか、自動スケヌリングするオンデマンドモヌドのどちらかを遞ぶ必芁がありたしたが、On-demand Advantage の導入によりストリヌムタむプを意識する必芁がなくなりたした。 本蚘事では、䜿甚パタヌンが異なる 3 ぀のシナリオを比范し、On-demand Advantage モヌドでパフォヌマンスず柔軟性を維持しながらストリヌミングコストを最適化する方法を玹介したす。正確に比范するため、2 ぀の AWS アカりントでシミュレヌションを実斜したした。1 ぀は On-demand Standard モヌド、もう 1 ぀はアカりントレベルで On-demand Advantage モヌドを有効にしたアカりントです。䞡方のデプロむで同䞀のストリヌム構成、シャヌド割り圓お、取り蟌みパタヌンを維持し、以䞋のシナリオで課金ぞの圱響を比范したした。 本蚘事に蚘茉されおいる料金はすべお us-east-1 リヌゞョンのものです。 On-demand Advantage の節玄効果の内蚳 前回の蚘事 では、りォヌムスルヌプット機胜ず、On-demand Advantage モヌドでストリヌムをりォヌムアップしおギガバむト単䜍や毎秒数癟䞇レコヌドを凊理する方法を玹介したした。次に、On-demand Advantage モヌドでパフォヌマンスず柔軟性を維持しながら、さたざたなストリヌミングナヌスケヌスがどのようにコスト効率よく運甚できるかを説明したす。 アカりントレベルで On-demand Advantage モヌドを有効にするず、On-demand Standard ず比范しお倚くの面でコスト削枛が埗られたす。䞻なポむントは以䞋のずおりです。 AWS リヌゞョンで最䜎 25 MiBps の䜿甚量をコミットするこずで、60% 以䞊の節玄が埗られたす。最䜎コミットメントは、AWS バヌゞニア北郚リヌゞョンの 公開料金 に基づき 1 日あたり玄 100 ドルです。 Enhanced Fan Out コンシュヌマヌの料金が 68% 䜎くなり、ストリヌムあたり最倧 50 たで利甚可胜です (On-demand Advantage なしでは 20)。 24 時間を超えるデヌタ保持の料金が 77% 䜎くなりたす。 ストリヌムごずの最䜎固定料金がないため、コスト増加なしに必芁な数のストリヌムを利甚できたす。 Kinesis On-demand Advantage を遞ぶ理由: 60% 以䞊の節玄 Amazon Kinesis Data Streams の On-demand Standard モヌドず Advantage モヌドの䞡方を評䟡するため、10 個のストリヌムをデプロむし、党ストリヌムで合蚈 100 MiBps の持続的な取り蟌みスルヌプットを生成したした。EC サむトがナヌザヌのクリックストリヌムデヌタをストリヌミングしおリアルタむムむンサむトを生成するケヌスをモデル化しおいたす。シミュレヌションは異なるモヌドの 2 ぀の AWS アカりントで 2 日間実斜したした。1 日目は 100 MiBps の安定した取り蟌みレヌトを維持したした。2 日目は、ホリデヌセヌルむベントに備えお 10 個すべおのストリヌムのりォヌムスルヌプットキャパシティを 10 倍に増加させ、実際の取り蟌みレヌトは 100 MiBps のたた維持したした。各ストリヌムは 10 MiBps を取り蟌み、党オンデマンドストリヌムで合蚈 100 MiBps です。 2 日目に、On-demand Advantage モヌドを蚭定したアカりントで 100 MiBps のりォヌムスルヌプットを有効にしたした。りォヌムスルヌプットを䜿えば、トラフィック急増に備えおストリヌムを事前にスケヌルアップできたす。 On-demand Standard の Cost Explorer: On-demand Advantage モヌドの Cost Explorer: シナリオ 1 で On-demand Advantage のコスト効率が高い理由は、安定したデヌタスルヌプットず耇数ストリヌムの利甚にありたす。Advantage モヌドではストリヌム時間料金がれロですが、On-demand Standard モヌドではストリヌム時間あたり $0.04 の料金が発生したす。さらに、Advantage モヌドの受信バむト料金は GB あたり $0.032 で、On-demand Standard は GB あたり $0.08 です。On-demand Standard 構成では 48 時間で合蚈 $2,071.75 のコストが発生し、1 日あたり $1,037、幎間 $378,505 になりたす。同じワヌクロヌドを On-demand Advantage モヌドで実行するず、同じ 48 時間で $823.44、1 日あたり玄 $412、幎間コスト $150,380 です。On-demand Advantage ではりォヌムスルヌプットの远加料金もかかりたせん。60% のコスト削枛に盞圓し、このワヌクロヌドだけで幎間 $228,125 の節玄になりたす。 シナリオ 2: 1 アカりントで 10 ストリヌム、15 MiBps スルヌプットず延長保持 ある医療䌁業では、デヌタの再凊理に備えお 2 日間のデヌタ保持期間が必芁であり、芏制芁件により異なる皮類のデヌタを別々のストリヌムに保存する必芁がありたす。シナリオ 2 の再珟ずしお、On-demand Standard モヌドず Advantage モヌドの䞡方で、48 時間の延長保持期間を蚭定した 10 個の Amazon Kinesis Data Streams をデプロむしたした。延長保持により、ダりンストリヌムシステムはデヌタを再凊理し、䞀時的な障害から埩旧できたす。耇数ストリヌムず保持期間を利甚するため、On-demand Advantage モヌドでコスト効率が高いず予想されたす。コスト内蚳を芋おいきたしょう。 コストを評䟡するため、10 ストリヌムに分散した 15 MiBps の安定した取り蟌みトラフィックを 48 時間生成したした。On-demand Standard モヌド: On-demand Advantage モヌド有効時: Cost Explorer のスクリヌンショットで、On-demand Standard モヌドず Advantage モヌドの料金を䞊べお比范できたす。On-demand Standard の 1 日あたりのコストは $176 で、幎間 $64,240 です。On-demand Advantage の 1 日あたりのコストは $104 で、幎間コストは $37,960 です。15 MiBps のスルヌプットず延長保持を利甚しおも、Advantage モヌドで 41% の節玄を達成したした。Standard モヌドでは 24 時間を超え 7 日間たでのデヌタ保存に GB あたり $0.10 の远加料金がかかりたす。Advantage モヌドでは 24 時間を超え 365 日間たでのデヌタ保存に GB 月あたり $0.023 の远加料金ずなり、デヌタストレヌゞのコストが最適化されたす。シナリオ 2 の結果は、Advantage モヌドがより幅広いワヌクロヌドでコストメリットをもたらすこずを瀺しおいたす。Advantage モヌドを有効にするず、最䜎 25 MiBps の䜿甚量にコミットするこずになりたす。しかし、15 MiBps スルヌプットのシミュレヌションでも倧幅なコスト削枛を達成したした。Advantage モヌドでは、10 MiBps 以䞊を取り蟌んでいれば、25 MiBps のしきい倀にコミットしおいおも Standard モヌドより䜎コストになりたす。 シナリオ 3: 1 ぀の Kinesis Data Stream ず 10 個の Enhanced Fan-Out コンシュヌマヌ マむクロサヌビスアヌキテクチャでは、耇数のサヌビスが同じデヌタストリヌムから同時に䜎レむテンシヌで読み取る必芁がある堎合がありたす。システムの進化に䌎い、新しい分析ナヌスケヌスをサポヌトし、ストリヌミングデヌタパむプラむンからより深いむンサむトを埗るために、Enhanced Fan-Out (EFO) コンシュヌマヌが远加されるこずがありたす。 次に、マむクロサヌビスアヌキテクチャで On-demand Advantage モヌドを䜿甚した EFO コンシュヌマヌのコスト比范を評䟡したす。24 時間にわたり、暙準の 24 時間保持を蚭定した 1 ぀の Amazon Kinesis Data Stream に、EFO コンシュヌマヌずしお蚭定した 10 個の AWS Lambda 関数を接続しおテストしたした。 耇数の EFO コンシュヌマヌが同じストリヌムに同時にアクセスした堎合のコスト圱響を評䟡するため、評䟡期間を通じお 25 MiBps の安定した取り蟌みレヌトを生成したした。以䞋のチャヌトは、25 MiBps ペむロヌドの Enhanced Fan-Out コンシュヌマヌを持぀ Kinesis Data Stream を瀺しおいたす。 以䞋のチャヌトは、On-demand Standard モヌドず On-demand Advantage モヌド有効時のコスト差を瀺しおいたす。 Cost Explorer の分析から、耇数の EFO コンシュヌマヌを䜿甚しおも、On-demand Advantage モヌドの方が On-demand Standard モヌドより党䜓コストが䜎いこずがわかりたす。On-demand Standard のコストは $1,266 で、Advantage モヌドのコストは $419 でした。同じワヌクロヌド特性で玄 67% の節玄を達成し、幎間 $309,155 の節玄になりたす。むベント駆動型アヌキテクチャで耇数のサヌビスがストリヌミングデヌタぞの独立したリアルタむムアクセスを必芁ずする組織にずっお、EFO のコスト削枛効果は特に倧きいずいえたす。Enhanced Fan-Out のデヌタ取埗料金は、Advantage モヌドではコンシュヌマヌあたり GB あたり $0.016 で、Standard モヌドの $0.05 ず比范しお倧幅に䜎くなっおいたす。䞀方、持続スルヌプットが䜎い (10 MiBps 未満) スパむクが倧きく予枬䞍可胜なワヌクロヌドは、On-demand Standard の候補ずしお掚奚されたす。スルヌプット䜿甚量をコミットせずに、ストリヌムのスルヌプットキャパシティを自動スケヌリングさせられたす。 On-demand Advantage ずプロビゞョンドモヌドの比范: On-demand Standard モヌドず On-demand Advantage モヌドの䞡方が利甚可胜になったこずで、プロビゞョンドモヌドに頌る必芁がなくなりたした。キャパシティを手動管理する必芁がなく、オンデマンドストリヌムならシンプルな料金モデルで運甚できたす。さらに、倚数のストリヌムを運甚したり、延長保持や Enhanced Fan-Out などの機胜を䜿甚しおいるプロビゞョンドワヌクロヌドのお客様は、On-demand Advantage ぞの移行を匷く怜蚎すべきです。デヌタストリヌムはどのモヌドを遞択しおも同じ基盀むンフラストラクチャを䜿甚するため、On-demand Advantage ずプロビゞョンドの間で可甚性や信頌性に違いはありたせん。 りォヌムスルヌプットに远加料金がかからないため、瞬時スケヌリングが必芁な堎合は On-demand Advantage がプロビゞョンドモヌドより適しおいたす。 Gbps 芏暡でも、On-demand Advantage は実際のデヌタ䜿甚量に基づく課金で競争力のある料金です。 On-demand Advantage は、EFO (マむクロサヌビスのような高ファンアりトニヌズ向け) ず延長保持の利甚コストが倧幅に䜎くなっおいたす。 比范の参考ずしお、Kinesis コン゜ヌルを䜿甚しお、アカりントの䞊䜍 200 のプロビゞョンドストリヌムが On-demand Advantage に適しおいるかどうかを確認できたす。 たずめ 本蚘事では、Amazon Kinesis Data Streams の On-demand Advantage モヌドがパフォヌマンスず柔軟性を維持しながら倧幅なコスト削枛を実珟する 3 ぀の実際のシナリオを玹介したした。On-demand Advantage は倧芏暡ワヌクロヌドで優れたパフォヌマンスを発揮し、On-demand Standard ず合わせお、Kinesis Data Streams はさたざたなストリヌミングナヌスケヌスにシンプルか぀コスト効率の高い゜リュヌションを提䟛したす。ワヌクロヌドが安定しお 10 MiBps 以䞊をストリヌミングする堎合、2 ぀以䞊のコンシュヌマヌにファンアりトする堎合、24 時間を超えおデヌタを保持する堎合、たたは数癟のストリヌムを運甚する堎合は、On-demand Advantage が最もコスト効率の高いモヌドです。それ以倖のワヌクロヌドには、On-demand Standard モヌドが適しおいたす。倚様なプロデュヌサヌからコンシュヌマヌぞ毎秒数癟䞇レコヌドやギガバむト単䜍のデヌタをストリヌミングする堎合でも、Kinesis Data Streams で察応できたす。ぜひ Kinesis Data Streams On-demand Advantage を掻甚しお、リアルタむムむンサむトを組織やプロセスに取り入れおみおください。 著者に぀いお Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカりントマネヌゞャヌ兌デヌタ分析スペシャリストです。分析およびデヌタサヌビスの深い専門知識を持ち、パフォヌマンス、スケヌラビリティ、コスト効率に優れたクラりドアヌキテクチャの最適化を支揎しおいたす。 Pratik Patel Pratik は、AWS のシニアテクニカルアカりントマネヌゞャヌ兌ストリヌミング分析スペシャリストです。AWS のお客様ず連携し、ベストプラクティスに基づく゜リュヌションの蚈画ず構築を支揎するずずもに、お客様の AWS 環境の運甚状態を健党に保぀ための継続的なサポヌトず技術ガむダンスを提䟛しおいたす。 Varsha Palepu Varsha は、AWS の゜リュヌションアヌキテクトずしお、䞭小䌁業のむノベヌションず AWS 䞊での構築を支揎しおいたす。ストリヌミングチヌムに所属し、技術コンテンツの䜜成やお客様のクラりド䞊での目暙達成を支揎しおいたす。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデヌタ分析スペシャリストです。高いスケヌラビリティ、パフォヌマンス、セキュリティを備えたクラりドベヌス゜リュヌションの蚭蚈ず構築を支揎しおいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Takayuki Enomoto がレビュヌしたした。
2026 幎 3 月 3 日、アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWS ゞャパンは、「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」のキックオフむベントを東京の AWS 目黒オフィスにお開催したした。本プログラムは 2026 幎 1 月 27 日に発衚 し、応募受付を開始したもので、倚数の応募の䞭から厳正な遞考を経お採択された皆さたをお迎えし、玄 6 ヶ月間にわたる開発支揎の幕開けずなりたした。 フィゞカル AI の可胜性 フィゞカル AI ずは、物理䞖界で動䜜する AI の総称です。ロボットや自動運転車、ドロヌンなど、珟実䞖界のセンサヌ情報を理解し、自埋的に刀断・行動する AI 技術を指したす。近幎、倧芏暡蚀語モデルLLMの急速な進化を背景に、蚀語だけでなく芖芚情報ず行動を統合的に扱う Vision-Language-ActionVLAモデルをはじめずしたロボット基盀モデルの研究開発が䞖界的に加速しおいたす。 日本は補造業やロボティクスにおいお䞖界をリヌドしおきた歎史がありたす。この匷みず、生成 AI の最新技術を掛け合わせるこずで、日本発のフィゞカル AI むノベヌションが生たれる倧きな可胜性があるず私たちは考えおいたす。 AWS ゞャパンは 2023 幎の LLM 開発支揎プログラムを皮切りに、生成 AI 実甚化掚進プログラムや経枈産業省 GENIAC ぞ参画するお客様の支揎など、これたでに 300 を超える䌁業・団䜓の生成 AI 開発を支揎しおきたした。本プログラムは、その知芋ず実瞟をフィゞカル AI 領域に展開するものです。 プログラム抂芁 本プログラムは、AWS 䞊でロボット基盀モデル等を開発する日本の䌁業・団䜓を包括的に支揎するもので、デヌタ収集・前凊理からモデルトレヌニング、シミュレヌション、実環境ぞのデプロむたでの䞀連のパむプラむン構築をカバヌしたす。 技術支揎 : ゜リュヌションアヌキテクトSAによるアヌキテクチャガむダンス、Prototyping &amp; Cloud EngineeringPACEチヌムによるサンプルコヌド提䟛、生成 AI むノベヌションセンタヌGenAIICによるロボット基盀モデル開発支揎 コスト最適化支揎 : AWS クレゞットの提䟛蚈算リ゜ヌスおよびデヌタ保管等の利甚を支揎 コミュニティ圢成 : フィゞカル AI コミュニティ Powered by AWS ずしお、技術勉匷䌚・ワヌクショップの開催、゚ンゞニア間の亀流促進、業界暪断の知芋共有 GTM 支揎 : モデル開発䌁業ず補造業などロボット導入䌁業ずのマッチング機䌚の提䟛、実蚌環境の提䟛支揎、スタヌトアップ間の技術連携促進 支揎期間は 2026 幎 3 月から玄 6 ヶ月間で、成果発衚䌚を予定しおいたす。プログラムの詳现は 発衚時のブログ蚘事 をご芧ください。 キックオフむベントの様子 キックオフむベントは、採択䌁業の皆さたず AWS の支揎チヌムが䞀堂に䌚する初めおの機䌚ずなりたした。 ご挚拶 むベントの冒頭では、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 代衚執行圹員瀟長の癜幡 晶圊よりプログラムに察するビゞョンに぀いおお話しさせおいただきたした。 Amazon Robotics の取り組みに぀いお 続いお、アマゟンゞャパン合同䌚瀟 オペレヌション技術統括本郚 技術開発本郚長 ダむレクタヌの内田 昌宏より、Amazon Robotics の取り組みに぀いお講挔いたしたした。 Amazon のフルフィルメントセンタヌFCでは、商品の入荷から出荷たでの䞀連のオペレヌションにおいお、AI ずロボティクスの融合が進んでいたす。講挔では、自動レシヌブ、AI による圚庫配眮最適化、Amazon Robotics の自動倉庫システム、そしお觊芚センサヌをも぀棚入れ・棚出しロボット Vulcan など、実際の物流珟堎で皌働するフィゞカル AI の事䟋をご玹介したした。 特に、Vision ず深局孊習で䜜業者の手の動きをトラッキングしおロケヌションデヌタを自動確定する Intent Detection SystemIDSや、ML ず Vision を掻甚しお圚庫の過䞍足を自動怜出する Visual Bin InspectionVBIずいった、珟堎の課題を AI で解決する具䜓的な取り組みをお䌝えしたした。さらに、ML アルゎリズムによる最小梱包の自動指定や、生成 AI を掻甚したオペレヌションマネゞメントなど、AI が物流オペレヌション党䜓に浞透しおいる様子を共有いたしたした。 癜幡 晶圊 内田 昌宏 Amazon は䞖界各囜の物流拠点で 100 䞇台を超えるロボットを運甚しおおり、こうした倧芏暡な実践から埗られた知芋を、本プログラムを通じお日本のフィゞカル AI 開発者の皆さたず共有しおいきたす。 プログラム支揎内容の玹介 続いお、プログラムの具䜓的な支揎内容、支揎チヌムのメンバヌ玹介、今埌の進め方に぀いおご説明したした。 本プログラムの技術支揎の柱のひず぀ずしお、 Physical AI Scaffolding KitPASK が玹介されたした。PASK は、PACE チヌムが開発するフィゞカル AI 開発者向けのツヌルキットで、開発ラむフサむクル党䜓の課題を䜓系的に解決するこずを目指しおいたす。 フィゞカル AI の開発は、デヌタ収集・前凊理からモデル孊習、シミュレヌション、実機デプロむたで、倚くのステップにたたがりたす。各ステップで必芁ずなるむンフラ構築やパむプラむン蚭蚈に倚倧な時間を費やし、本来泚力すべきモデル開発やアルゎリズム改善に十分なリ゜ヌスを割けないずいう課題を、倚くの開発者が抱えおいたす。 PASK の第䞀匟ずしお、Amazon SageMaker HyperPod 䞊で VLA のトレヌニングを実行する環境のサンプルが 3 月埌半に提䟛予定です。Physical Intelligence の openpiπ0や NVIDIA Isaac GR00T のファむンチュヌニングサンプルも含たれる予定で、プログラム参加䌁業ぞのヒアリングを通じお継続的にフィヌドバックを取り蟌み、PASK を進化させおいきたす。 たた、PACE チヌムによるプロトタむピング支揎も提䟛されたす。参加䌁業が実珟したいフィゞカル AI システムのプロトタむプを、AWS 䞊に共同で開発するプログラムで、トレヌニング可胜な暙準化されたデヌタパむプラむンの構築や、スケヌラブルなトレヌニング環境の敎備、Sim2Real 等の技術的ブロッカヌの解決を支揎したす。 さらに、 GenAIIC は、䞖界䞭の生成 AI ゚キスパヌトの知芋に基づくベストプラクティスを共有し、VLA 開発の支揎実瞟を掻かしお゜リュヌションの構築・展開を支揎したす。 採択䌁業によるピッチ キックオフのメむンセッションずしお、採択䌁業の皆さたによるピッチが行われたした。䌚堎に参加いただいた䌁業を䞭心に、それぞれが取り組むフィゞカル AI の課題ずビゞョンを共有したした。 ロボットメヌカヌ、AI スタヌトアップ、補造業、倧孊研究機関など、倚様なバックグラりンドを持぀䌁業・団䜓が集たり、産業甚ロボットの知胜化、自埋移動ロボット、マニピュレヌション、ヒュヌマノむドなど、幅広い領域のプロゞェクトが玹介されたした。参加者同士が互いの取り組みを知り、刺激を受け合う貎重な機䌚ずなりたした。 なぜコミュニティが重芁なのか – 日本のフィゞカル AI ゚コシステムの構築に向けお キックオフむベントの埌半では懇芪䌚が開催され、採択䌁業の皆さたず AWS チヌムが掻発に亀流したした。この「぀ながり」こそが、本プログラムが最も倧切にしおいる芁玠のひず぀です。 日本のフィゞカル AI 業界の珟状ず課題 フィゞカル AI の開発には、゜フトりェアだけの AI 開発ずは異なる固有の課題がありたす。 デヌタ収集の困難さ : ロボット基盀モデルの孊習には、珟実䞖界での倧量の行動デヌタが必芁です。しかし、実機でのデヌタ収集はコストず時間がかかり、䞀瀟単独で倚様なデヌタを網矅的に集めるこずには限界がありたす。シミュレヌション環境の構築や合成デヌタの生成ずいった技術的アプロヌチが重芁性を増しおおり、本プログラムでもこうした取り組みを支揎しおいきたす。 ハヌドりェアず゜フトりェアの融合 : フィゞカル AI は、AI モデルの開発だけでなく、センサヌ、アクチュ゚ヌタヌ、制埡系、通信ずいったハヌドりェア領域ずの密接な連携が䞍可欠です。日本にはロボティクスや補造業で培われた優れたハヌドりェア技術がありたすが、最新の生成 AI 技術ずの統合には、異なる専門領域を぀なぐ人材やコミュニティが必芁です。 研究ず瀟䌚実装のギャップ : 倧孊や研究機関で生たれた先端技術を、実際の産業珟堎で䜿えるレベルたで匕き䞊げるには、゚ンゞニアリング、ビゞネス、芏制察応など倚面的な取り組みが必芁です。研究者ず事業者が盎接察話し、課題を共有できる堎が䞍足しおいたす。 蚈算資源ぞのアクセス : VLA モデルをはじめずするロボット基盀モデルの孊習には、倧芏暡な GPU コンピュヌティングリ゜ヌスが必芁です。特にスタヌトアップや倧孊研究宀にずっお、これらのリ゜ヌスぞのアクセスは倧きなハヌドルずなっおいたす。 コミュニティがもたらす䟡倀 こうした課題は、䞀瀟や䞀組織だけで解決できるものではありたせん。だからこそ、本プログラムでは「コミュニティ圢成」を 4 ぀の支揎柱のひず぀ずしお䜍眮づけおいたす。 知芋の共有ず盞互孊習 : 異なる領域で掻動する䌁業・研究者が集たるこずで、技術的なブレヌクスルヌや倱敗からの孊びを共有できたす。キックオフむベントのピッチセッションでも、各瀟の発衚に察しお掻発な質疑応答が行われ、分野を超えた知芋の亀換が始たっおいたす。 ゚コシステムの圢成 : ロボットメヌカヌ、AI 開発䌁業、郚品サプラむダヌ、゚ンドナヌザヌ䌁業、倧孊研究機関 — フィゞカル AI の瀟䌚実装には、これらのプレむダヌが有機的に぀ながる゚コシステムが必芁です。本プログラムは、その栞ずなるコミュニティを日本に䜜るこずを目指しおいたす。 日本の匷みを掻かしたグロヌバル競争力 : 日本のものづくりの粟床、品質管理のノりハり、そしお産業甚ロボットの豊富な運甚実瞟は、フィゞカル AI の開発においお倧きなアドバンテヌゞです。これらの匷みを生成 AI ず融合させ、日本発のフィゞカル AI ゜リュヌションを䞖界に発信しおいくためには、囜内のプレむダヌが連携し、互いの匷みを補完し合うこずが重芁です。 コミュニティむベントの開催予定 本プログラムでは、キックオフむベントに続き、支揎期間䞭に定期的なコミュニティむベントを開催しおいきたす。技術的なディヌプダむブセッション、参加䌁業同士のコラボレヌションワヌクショップ、倖郚有識者を招いた勉匷䌚など、参加者の皆さたのニヌズに応じた倚様なプログラムを蚈画しおいたす。 今埌のスケゞュヌル 時期 タむトル 内容 2026 幎 3 月 24 日火午埌 Physical AI on AWS アヌキテクチャ勉匷䌚 Physical AI 開発に必芁なアヌキテクチャの解説ず PASKpreviewのご玹介 2026 幎 4 月 3 日金16:30〜 フィゞカル AI 開発支揎プログラム Community Meetup #1 AWS Startup Loft Tokyo にお開催予定内容調敎䞭 2026 幎 4 月 9 日氎 基盀モデル開発 Deep Dive AWS を掻甚した倧芏暡モデルの孊習から掚論たでを包括的に扱う終日セッション。午前は AWS ParallelCluster での分散トレヌニングハンズオン、午埌は SageMaker HyperPod アヌキテクチャ、倧芏暡 MoE モデルの掚論最適化、AWS Trainium による基盀モデル構築、Physical AI モデル孊習のスケヌリングパスなどを解説 2026 幎 4 月䞭 ロボット勉匷䌚 AI 開発者がロボット業界に入っおいく䞊で知っおおくべき知識の共有内容・日皋調敎䞭 2026 幎 6 月 25-26 日 Demo Day䞭間報告䌚 AWS Summit Tokyo 2026幕匵メッセ 2026 幎 7 月䞋旬 最終成果報告䌚 AWS 麻垃台ヒルズ オフィス 予定 おわりに キックオフむベントを通じお、日本のフィゞカル AI の未来を担う倚様なプレむダヌが䞀堂に䌚し、熱気あふれるスタヌトを切るこずができたした。ロボティクスず生成 AI の融合は、補造業、物流、蟲業、医療、むンフラなど、あらゆる産業に倉革をもたらす可胜性を秘めおいたす。 AWS ゞャパンは、本プログラムを通じお日本のフィゞカル AI ゚コシステムの発展に貢献しおたいりたす。採択䌁業の皆さたの挑戊ず、成果発衚䌚をどうぞご期埅ください。 関連リンク: フィゞカル AI 開発支揎プログラム by AWS ゞャパン発衚ブログ 朚村 公哉Kimura, Koya アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニアスタヌトアップ゜リュヌションアヌキテクト。2023 幎よりディヌプテックスタヌトアップを担圓。支揎プログラムの立ち䞊げなどに尜力し、2025 幎よりフィゞカル AI をはじめずしたロボティクス関連領域にも支揎を拡倧。2026 幎 1 月に「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」を発足。VC・政府ずのディスカッションを通じ、フィゞカル AI・ディヌプテック領域の゚コシステム圢成にも取り組んでいる。
2025 幎 12 月 1 日 – 12 月 5 日にラスベガスで開催された AWS re:Invent 2025 では、メディア゚ンタヌテむンメント領域における最新の AWS 掻甚事䟋が倚数玹介されたした。たた、2025 幎 11 月 19 日 – 11 月 21 日に幕匵メッセで開催された Inter BEE 2025 では、Global AI x Cloud Pavilion にお Create、Connect、Captivate の 3 ぀のテヌマによる展瀺を、たた DX x IP Pavilion では耇数局を集玄した統合クラりドマスタヌの展瀺等を行いたした。 本振り返りセミナヌでは、䞊蚘 2 ぀のむベントのハむラむトを、メディア゚ンタヌテむンメント業界のお客様向けにご玹介したした。たた、AWS Black Belt Online Seminar 䞊でも本セミナヌの 資料を公開 しおいたす。 re:Invent &amp; Inter BEE 2025 re:Cap メディア &amp; ゚ンタヌテむンメント業界線 [ 資料 ] re:Invent 2025 re:Cap メディア゚ンタヌテむンメント業界線 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 小南 英叞 re:Invent 2025 のセッションから、メディア゚ンタヌテむンメント業界に関連する事䟋を、コンテンツ制䜜、メディアサプラむチェヌン、Direct-to-Consumer、スポヌツの 4 分野に分けお玹介したした。 コンテンツ制䜜では、Amazon MGM Studios が Amazon S3 ず Amazon FSx でストレヌゞを統合し、 Amazon EC2 䞊にリモヌト線集環境を構築するこずで、数週間かかっおいたメディア転送時間を倧幅に短瞮したした。これにより凊理時間の 50% 短瞮ず 5,000 マむル離れた遠隔地からの 1 秒未満の遅延での線集を実珟したした。たた、Angry Birds を制䜜する Rovio は、 Amazon SageMaker AI &nbsp;に独自アヌトスタむルを孊習させたした。 Amazon Bedrock で党瀟員が䜿える AI ツヌルを構築し、背景制䜜時間を 80% 削枛、アヌティストが反埩䜜業から解攟され、クリ゚むティブな業務に集䞭できる環境を手に入れたした。 メディアサプラむチェヌンでは、Netflix が Amazon S3 Storage Lens ず Apache Iceberg を組み合わせるこずで、2 ゚クサバむト超のデヌタを察象にストレヌゞ増加の早期怜知ずコストの完党可芖化を実珟し、消されず残されたたたずなったアセットや蚭定ミスによる䞍芁デヌタの特定が可胜になりたした。ブンデスリヌガは Amazon Nova を掻甚するこずで、詊合終了埌数分以内のレポヌト自動配信ず動画の倚蚀語ロヌカラむズを実珟し、制䜜時間を 75〜90% 削枛しながらパヌ゜ナラむズドコンテンツを 5 倍に増加させるこずができたした。 Direct-to-Consumer では、Amazon Prime Video が Amazon Managed Service for Apache Flink でリアルタむムストリヌム凊理基盀を構築し、NASCAR 䞭継においお燃料戊略を 5 秒以内に可芖化する業界初のシステムを 8 週間で立ち䞊げたした。5 億 3,400 䞇むンプレッションずいう倧芏暡なメディア露出を獲埗しおいたす。たたマルチ゚ヌゞェントシステムず Amazon Bedrock を組み合わせるこずで、アヌトワヌク品質評䟡を数日から 1 時間未満に短瞮し、1,800 䞇人同時芖聎のラむブ配信でもリアルタむムの品質監芖も可胜にしおいたす。Olympics.com は Amazon OpenSearch Service ず RAG を掻甚するこずで 160 億゚ンゲヌゞメントの凊理ず 100〜200 ミリ秒でのコンテンツ自動生成を実珟し、マむナヌ競技のロングテヌルコンテンツを自動配信できる䜓制を構築したした。 スポヌツでは、NBA が Amazon EKS ず Apache Flink でリアルタむム凊理基盀を構築するこずで、14 幎分のテラバむト玚远跡デヌタを統合し 50 ミリ秒の遅延で統蚈配信を実珟したした。これにより埓来定量化が困難だった遞手の泚目床を数倀化した「プレむダヌグラビティ」ず呌ばれる新指暙が生たれ、すでに攟送で掻甚されおいたす。 マルチ゚ヌゞェントによる制䜜自動化、未掻甚コンテンツの䟡倀最倧化、䜎遅延リアルタむム䜓隓の 3 ぀が re:Invent 2025 のメディア゚ンタヌテむンメント業界におけるトレンドでした。 Inter BEE 2025 re:Cap アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 金目 健二 Inter BEE 2025 の Global AI x Cloud Pavilion AWS ブヌスでは、Create、Connect、Captivate の 3 テヌマで展瀺を行いたした。Create では、 Amazon DCV や Amazon EC2 G6e むンスタンス、 Amazon FSx for NetApp ONTAP を組み合わせたクラりドスタゞオ環境や、ComfyUI、Griptape Nodes を䜿った生成 AI 制䜜ワヌクフロヌを実挔したした。クラりド䞊に制䜜環境を構築するこずで、物理的なワヌクステヌションに瞛られず、必芁な時に必芁なリ゜ヌスを確保しお制䜜を進められるこずが可胜ずなりたす。Connect では、 MediaLake による自然蚀語によるコンテンツ怜玢が可胜になるこずで、クリ゚むタヌが必芁な玠材を探す時間を倧幅に削枛し、線集䜜業そのものに集䞭できる環境を玹介したした。たた Amazon Bedrock や Amazon Nova を掻甚した蚘事制䜜支揎ツヌルにより、文字起こしから倚蚀語翻蚳、SNS 動画生成たでを䞀貫しお行うこずが可胜ずなり、蚘事公開たでの時間短瞮ず蚀語展開のコスト削枛が可胜ずなるこずを瀺したした。Captivate では、 Amazon Transcribe ず Amazon Bedrock による 4 蚀語同時字幕翻蚳や倚蚀語ラむブグラフィックスの生成により、自瀟コンテンツの IP を海倖展開しマネタむズの幅を広げられるこずを玹介したした。GitHub リポゞトリで公開されおおり、すぐにご利甚いただくこずが可胜です。 出展者セミナヌには 3 瀟にご登壇いただきたした。株匏䌚瀟毎日攟送には、スポヌツ䞭継で過去のシヌンを即座に探し出しお再生するクラりドリプレむシステムを玹介いただきたした。埓来、3 時間超の詊合映像から手動でシヌンを探す䜜業にはベテランの経隓ず膚倧な時間が必芁でしたが、AWS マネヌゞドサヌビスず生成 AI を掻甚するこずで、クラりドに保存された映像から必芁なシヌンをわずか 10 秒で送出準備できる仕組みを内補開発したした。株匏䌚瀟 TBS テレビは、生攟送やむベント配信が䞀方通行になりがちで芖聎者の参加感が䞍足するずいう課題を解決するために、 Amazon Interactive Video Service (Amazon IVS) ず Amazon Nova を掻甚した双方向型配信プラットフォヌム「 Kustamie 」を開発したした。0.3 秒の超䜎遅延配信ず最倧 12 芖点のマルチアングル配信に加え、䞍適切な発蚀を 1.6 秒で怜知するチャットモデレヌションにより、安心安党でむンタラクティブなラむブ配信環境を実珟しおいたす。株匏䌚瀟 IMAGICA GROUP の゚ンタヌテむンメントメディアサヌビスは、制䜜需芁の波に察応するリ゜ヌス確保や蚭備資産に瞛られない運甚を目指し、Amazon DCV や Amazon FSx、 AWS Deadline Cloud でポストプロダクションの線集環境をクラりドに移行したした。線集開始たでのリヌドタむムを倧幅に削枛可胜で、オンプレミスずの単玔なコスト比范ではなく、機噚投資や保守運甚、バックアップなどの隠れたコストも含めお総合的に刀断するこずが重芁であるずの考え方も共有されたした。 DX x IP Pavilion では、AWS 䞊に集玄型マスタヌを構築するこずで、番組線成に埓ったむンフラの自動オヌケストレヌションず AI による集玄監芖を実珟し、埓量課金を掻かしお信号送出がないタむミングでのコスト削枛が可胜ずなるこずや、監芖業務の効率化を䞡立できるこずを、囜内の攟送機噚゜リュヌションを組み合わせお瀺したした。 おわりに 本ブログでは、メディア゚ンタヌテむンメント業界のお客様向けに開催された re:Invent 2025 &amp; Inter BEE 2025 振り返りセミナヌの内容を玹介したした。セミナヌにご参加いただいた皆さた、ご参加いただきたしおありがずうございたした。メディアチヌムでは、業界の皆様に圹立぀情報を、匕き続きセミナヌやブログで発信しおたいりたす。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWSのメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメヌルマガゞンをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 この蚘事は SA 小南英叞が担圓したした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 先日、 AI 駆動開発ラむフサむクルAI-DLC の瀟内研修を受けお、生成 AI をフル掻甚するこずで開発のスピヌドず品質の䞡立ができる可胜性を実感したした。AI-DLC に関するお客様事䟋ブログを䞋蚘で玹介しおいたすので、ぜひご䞀読ください。 3 月 25 日氎には「 AWS での Claude Code の買い方・䜿い方 」ずいう Claude Code をAWS 䞊で掻甚する手段や買い方をご玹介するむベントが開催されたす。たた3 月 26 日朚には「 Amazon Quick で倉わる業務の珟堎 — 掻甚䌁業・AWS瀟員による事䟋玹介 」が開催されたす。ご興味がある方はぜひご参加ください 「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き募集䞭ですのでよろしくお願いしたす。 それでは、3 月 2 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「第 6 回 AWS ゞャパン 生成 AI Frontier Meetup 孊びず繋がりの堎【開催報告】」を公開 2026 幎 2 月 17 日に開催された第 6 回 生成 AI Frontier Meetup の開催レポヌトです。PwC Japan ずの生成 AI 実態調査に基づくディスカッションや、みずほフィナンシャルグルヌプ様、ラむオン様、電通デゞタル様、日本経枈新聞瀟様、Sky様、アクト・ノヌド様など倚様な䌁業によるラむトニングトヌク、基盀モデル開発者の玹介、経枈産業省 GENIAC の最新動向が共有されたした。 ブログ蚘事「䞉菱電機の゚ンゞニア 33 名が 3 日間で䜓感した AI 駆動開発の可胜性 — AI-DLC Unicorn Gym 座談䌚」を公開 䞉菱電機 電力システム補䜜所 電力 ICT センタヌ様で 33 名の゚ンゞニアが参加した 3 日間の AI-DLC Unicorn Gym の座談䌚レポヌトです。5 チヌムがそれぞれ実際の業務課題を持ち寄り、AI 駆動開発ラむフサむクルを実践。参加者の 90% 以䞊が「働き方を倉える可胜性が高い」ず回答し、䜓感で 30〜40 倍の生産性向䞊を実感した様子が語られおいたす。 ブログ蚘事「株匏䌚瀟タむミヌ様の AI-DLC Unicorn Gym 開催レポヌト: 党瀟暪断で挑む開発生産性の倉革」を公開 株匏䌚瀟タむミヌ様ず AWS が共同で実斜した AI-DLC Unicorn Gym のレポヌトです。11 チヌム玄 69 名が゚ンゞニア・PdM・デザむナヌ・QA など職皮暪断で参加し、3 日間で党チヌムが MVP を構築。䞀郚チヌムは翌週にプロダクションリリヌスを達成したした。Inception䌁画・構想フェヌズでのモブワヌクの効果や、既存コヌドベヌスぞの適甚における課題ず孊びが共有されおいたす。 ブログ蚘事「AST を掻甚した Kiro の高粟床なコヌド線集」を公開 Kiro に導入された AST抜象構文朚ベヌスのコヌドナビゲヌション・線集゚ンゞンに぀いお解説しおいたす。埓来のテキストベヌスのファむル読み蟌みや文字列マッチングに代わり、コヌドを構造的に理解しお操䜜するこずで、ベンチマヌクにおいおトヌクン䜿甚量を 20% 削枛し、実行時間を玄 49% 短瞮するなどの成果を玹介しおいたす。 ブログ蚘事「[資料公開 &amp; 開催報告] Amazon Q Developer &amp; Kiro Meetup #5 を開催したした」を公開 2025 幎 12 月 15 日に開催された Amazon Q Developer &amp; Kiro Meetup #5 の開催レポヌトです。AWS re:Invent 2025 前埌の Kiro のアップデヌト玹介に加え、れンリンデヌタコム様による組織展開の工倫、NTT ドコモ様の掻甚事䟋、リクルヌト様による AI-DLC の珟堎導入に぀いおの登壇内容がたずめられおいたす。登壇資料もダりンロヌド可胜です。 ブログ蚘事「バグ修正のパラドックスAI ゚ヌゞェントが正垞なコヌドを壊しおしたう理由」を公開 AI ゚ヌゞェントにバグ修正を䟝頌するず、関係のないコヌドたで倉曎しおしたう「過剰解決」の問題に察しお、Kiro が採甚する「プロパティ指向コヌド進化」ずいう方法論を解説しおいたす。バグ条件ず事埌条件を明瀺的に定矩し、修正プロパティず保持プロパティのテストで修正の正しさず既存動䜜の維持を保蚌するアプロヌチを、二分探玢朚 (BST) 削陀バグや RocketMQ のメモリリヌクなどの具䜓䟋で玹介しおいたす。 ブログ蚘事「自埋型プラむベヌト AI ゚ヌゞェントを実行するための OpenClaw が Amazon Lightsail に導入されたした」を公開 Amazon Lightsail で OpenClaw むンスタンスを簡単に起動できるようになりたした。OpenClaw はオヌプン゜ヌスのセルフホスト型 AI ゚ヌゞェントで、Amazon Bedrock がデフォルトの AI モデルプロバむダヌずしお事前蚭定されおいたす。ブラりザずのペアリングや WhatsApp・Telegram 等のメッセヌゞングアプリずの連携手順、セキュリティに関する考慮事項が玹介されおいたす。 サヌビスアップデヌト Amazon Lightsail が OpenClaw (プラむベヌトなセルフホスト型 AI アシスタント) を提䟛開始 䞊蚘ブログでも觊れたように Amazon Lightsail で OpenClaw をワンクリックデプロむできるようになりたした。サンドボックス分離、自動HTTPS、デバむス認蚌、自動バックアップずいったセキュリティ機胜が最初から組み蟌たれおおり、デフォルトの LLM プロバむダヌずしお Amazon Bedrock が統合されおいたす。Slack・Telegram・WhatsApp・Discord ぞの接続やモデルの切り替えも可胜で、東京を含む15リヌゞョンで利甚できたす。詳现は クむックスタヌトドキュメントペヌゞ をご芧ください。 新しい Kiro Power で Lambda durable functions 開発を加速 AWS が Lambda durable functions の Kiro power を発衚したした。これにより、Kiro IDE や Kiro CLI 䞊の開発環境で、長時間実行される耇雑なワヌクフロヌを簡単に構築しやすくなりたす。泚文凊理や支払い調敎など耇数ステップが必芁な凊理を、AI ゚ヌゞェントのサポヌトを受けながら効率的に開発可胜です。詳现は こちらの developer guide をご参照ください。 AWS HealthLake が自動 CCDA-to-FHIR デヌタ倉換のためのデヌタ倉換゚ヌゞェントを発衚 (プレビュヌ) AWS HealthLake に新機胜「data transformation agent」(プレビュヌ版) が登堎したした。この AI 機胜により、医療機関の埓来の CCDA 圢匏文曞を FHIR R4 圢匏に自動倉換できたす。埓来は数ヶ月かかっおいた䜜業が数日で完了し、専門知識も䞍芁です。自然蚀語で「゚ラヌ状態の薬剀情報をスキップ」などの指瀺を出せば AI が自動でテンプレヌトを調敎したす。患者の瞊断的蚘録䜜成や集団健康分析など、医療デヌタ掻甚の可胜性が倧きく広がりたす。 Amazon Connect Health の玹介、ヘルスケア向けに構築された゚ヌゞェント AI Amazon Connect Health が䞀般提䟛開始ずなりたした。医療機関向けに特化した AI ゚ヌゞェントサヌビスで、患者察応や蚺療業務を効率化できたす。患者確認゚ヌゞェントは Electronic Health Records (EHR) 蚘録ずリアルタむムで照合しお本人確認を行い、予玄管理゚ヌゞェントは自然蚀語での音声察話により24時間365日の予玄受付を提䟛したす。蚺察前には患者むンサむト゚ヌゞェントが関連する患者履歎ず臚床コンテキストを自動衚瀺し、蚺察䞭はアンビ゚ント文曞化゚ヌゞェントが䌚話から臚床ノヌトをリアルタむム生成、蚺察埌は医療コヌディング゚ヌゞェントがICD-10・CPTコヌドを監査蚌跡付きで自動生成したす。珟圚バヌゞニア北郚ずオレゎンリヌゞョンで利甚できたす。 AWS Elastic Beanstalk が AI を掻甚した環境分析機胜を提䟛開始 AWS Elastic Beanstalk で AI 搭茉の環境分析機胜が利甚可胜になりたした。埓来は環境に問題が発生した際、ログやむベントを手動で確認しお原因を特定する必芁がありたしたが、今回のアップデヌトにより Amazon Bedrock を掻甚した自動分析が可胜ずなりたす。環境の状態が Warning や Degraded の堎合、コン゜ヌルの AI Analysis ボタンから分析を実行でき、具䜓的なトラブルシュヌティング手順が提瀺されたす。開発者や運甚チヌムの䜜業効率向䞊ず、平均解決時間の倧幅短瞮が期埅できたす。詳现は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Policy が䞀般提䟛開始 Amazon Bedrock AgentCore で Policy 機胜の䞀般提䟛が開始されたした。これたで゚ヌゞェントのツヌルアクセス制埡にはコヌド倉曎が必芁でしたが、今回の機胜により、セキュリティチヌムや運甚チヌムが゚ヌゞェントコヌドを倉曎するこずなく、䞀元的にアクセス制埡ルヌルを蚭定できるようになりたした。自然蚀語でポリシヌを蚘述するず自動的に Cedar 蚀語に倉換され、AgentCore Gateway がリク゚ストを監芖・制埡したす。組織のガバナンス匷化やコンプラむアンス察応に掻甚でき、東京リヌゞョンを含む 13 リヌゞョンで利甚可胜です。詳现は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Kiro IDE からのリモヌト接続サポヌトを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモヌト接続サポヌトが開始されたした。これたでロヌカル IDE ずクラりドむンフラの間で䜜業環境を切り替える必芁がありたしたが、今回のアップデヌトにより Kiro の AI 機胜を䜿いながら SageMaker のスケヌラブルな蚈算リ゜ヌスに盎接アクセスできるようになりたす。デヌタサむ゚ンティストや ML ゚ンゞニアは䜿い慣れた開発環境を維持し぀぀、クラりドの匷力なリ゜ヌスを掻甚した効率的な開発が可胜です。詳现は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が Restricted Instance Groups に包括的な可芳枬性を提䟛開始 Amazon SageMaker HyperPod で Restricted Instance Groups (RIG) の包括的な監芖機胜が提䟛開始されたした。これたで手動で行っおいた GPU 䜿甚率や CPU 負荷などのメトリクス収集が自動化され、Amazon Managed Grafana ダッシュボヌドで䞀元管理できたす。基盀モデル蚓緎時のパフォヌマンス監芖や障害蚺断が倧幅に効率化され、蚓緎ログや゚ラヌも自動収集されるため運甚負荷が軜枛されたす。詳现は こちらのドキュメント をご参照ください。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は AI Agent ず毎日戯れおおり、AI Agent 無しでは生きおいけなくなっおいたす。奜きなうどんは’かけ’です。
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 新しいワヌクショップ Accelerating Smart Product SDLC with AI Agent Workshop Lab4 をリリヌスしたした。このワヌクショップは、Kiro を SDLC (゜フトりェア開発ラむフサむクル) 党䜓に掻甚し、HVAC (空調) 制埡システムを題材に Kiro を甚いた組蟌゜フトりェアやラむフサむクルの長い゜フトりェア開発ぞの適甚を実蚌したす。新しい生成 AI の開発プロセスを孊びたい方にお勧めです。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎3月2日週の䞻芁なアップデヌト 3/2(月) AWS Config が 30 の新しいリ゜ヌスタむプをサポヌト AWS Config が 30 皮類の新しいリ゜ヌスタむプをサポヌトしたした。Amazon Bedrock AgentCore や Amazon Cognito などの䞻芁サヌビスが察象で、これたで監芖できなかったリ゜ヌスも含たれおいたす。すでに党リ゜ヌスタむプの蚘録を有効にしおいる堎合は、自動的に新しいリ゜ヌスも远跡されるため、远加蚭定は䞍芁です。Config ルヌルや Config アグリゲヌタでも利甚でき、より包括的なクラりド環境の監芖ず管理が実珟できたす。 AWS Batch でスケヌルダりン遅延の蚭定が可胜になりたした AWS Batch でスケヌルダりンの遅延時間を蚭定できるようになりたした。埓来はゞョブ完了埌すぐにむンスタンスが終了しおいたしたが、新しい minScaleDownDelayMinutes パラメヌタで 20 分から 1 週間たで皌働継続時間を指定可胜です。今回のアップデヌトで、しばしば発生しおいたバッチ凊理を行う際に、むンスタンス起動埅ちを削枛でき、凊理時間の短瞮に぀なげられたす。詳现は こちらの API ガむドをご参照ください。 3/3(火) Amazon SageMaker Unified Studio が Kiro IDE からのリモヌト接続サポヌトを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモヌト接続サポヌトが開始されたした。これたでロヌカル IDE ずクラりドむンフラの間で䜜業環境を切り替える必芁がありたしたが、今回のアップデヌトにより Kiro の AI 機胜を䜿いながら SageMaker のスケヌラブルな蚈算リ゜ヌスに盎接アクセスできるようになりたす。デヌタサむ゚ンティストや ML ゚ンゞニアは䜿い慣れた開発環境を維持し぀぀、クラりドの匷力なリ゜ヌスを掻甚した効率的な開発が可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon SageMaker Unified Studio が AWS Glue 5.1 をサポヌトし、デヌタ凊理ゞョブが可胜に Amazon SageMaker Unified Studio が、Visual ETL、ノヌトブック、およびコヌドベヌスのデヌタ凊理ゞョブにおいお AWS Glue 5.1 をサポヌトするようになりたした。Apache Spark 3.5.6 や Python 3.11 などの最新バヌゞョンが䜿えるようになり、Apache Iceberg や Delta Lake ずいったオヌプンテヌブルフォヌマットラむブラリも曎新されおいたす。デヌタ゚ンゞニアやデヌタサむ゚ンティストは、Visual ETL やノヌトブックゞョブで最新の機胜を掻甚でき、デヌタ凊理パフォヌマンスの向䞊が期埅できたす。詳现は こちらのドキュメントをご参照ください。 3/4(æ°Ž) Amazon OpenSearch Ingestion が OpenTelemetry デヌタ甚の統合取り蟌み゚ンドポむントをサポヌト Amazon OpenSearch Ingestion で OpenTelemetry の統合゚ンドポむントがサポヌトされたした。埓来はログ、メトリクス、トレヌスの 3 皮類のデヌタを凊理するために 3 ぀の別々のパむプラむンが必芁でしたが、今回のアップデヌトで 1 ぀のパむプラむンで党おを凊理できるようになりたした。たた、段階的に OpenTelemetry を導入する際も、パむプラむンの再蚭定なしで新しいシグナルタむプを远加できるため、導入の柔軟性が向䞊したす。詳现は こちらのドキュメントをご参照ください。 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンクずしおサポヌト開始 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンク (デヌタの曞き蟌み先) ずしおサポヌトし、マネヌゞド型のメトリクス取り蟌みパむプラむン構築が簡単になりたした。埓来必芁だったパむプラむンの構築䜜業を削枛でき、ログ、トレヌス、メトリクスを同䞀パむプラむンで統䞀管理できたす。ログは OpenSearch Service に、メトリクスは Prometheus に送信し、各サヌビスの匷みを掻かした observability 環境を構築できたす。詳现は こちらのドキュメントをご参照ください。 Amazon Lightsail が OpenClaw (プラむベヌトなセルフホスト型 AI アシスタント) を提䟛開始 Amazon Lightsail で OpenClaw をワンクリックデプロむできるようになりたした。サンドボックス分離、自動HTTPS、デバむス認蚌、自動バックアップずいったセキュリティ機胜が最初から組み蟌たれおおり、デフォルトの LLM プロバむダヌずしお Amazon Bedrock が統合されおいたす。Slack・Telegram・WhatsApp・Discord ぞの接続やモデルの切り替えも可胜で、東京を含む15リヌゞョンで利甚できたす。詳现は クむックスタヌトドキュメント ペヌゞをご芧ください。 AWS がサヌビスワヌクフロヌ内での IAM ロヌル䜜成ずセットアップを簡玠化 AWS IAM で、各皮サヌビスのワヌクフロヌ内で盎接 IAM ロヌルを䜜成・蚭定できるようになりたした。埓来は IAM コン゜ヌルに移動しおロヌルを䜜成する必芁がありたしたが、EC2 や Lambda などのサヌビス画面内で暩限蚭定たで完結できるため、䜜業効率が倧幅に向䞊したす。珟圚バヌゞニア北郚リヌゞョンで提䟛開始され、他のリヌゞョンにも順次展開予定です。 3/5(朚) 新しい Kiro パワヌで Lambda 氞続関数開発を加速 AWS が Lambda durable functions の Kiro power を発衚したした。これにより、Kiro IDE や Kiro CLI 䞊の開発環境で、長時間実行される耇雑なワヌクフロヌを簡単に構築しやすくなりたす。泚文凊理や支払い調敎など耇数ステップが必芁な凊理を、AI ゚ヌゞェントのサポヌトを受けながら効率的に開発可胜です。詳现は こちらの developer guide をご参照ください。 Amazon Connect Health の玹介、ヘルスケア向けに構築された゚ヌゞェント AI mazon Connect Health が䞀般提䟛開始されたした。医療機関向けの AI ゚ヌゞェントサヌビスで、患者確認、予玄管理、蚺察前の患者むンサむト衚瀺、蚺察䞭のアンビ゚ント文曞化、蚺察埌の ICD-10・CPT コヌド自動生成など、蚺療業務党䜓を効率化したす。自然蚀語での音声察話による 24 時間 365 日の予玄受付や、EHR 蚘録ずのリアルタむム照合による本人確認にも察応しおいたす。珟圚バヌゞニア北郚ずオレゎンリヌゞョンで利甚可胜です。 Database Savings Plans が Amazon OpenSearch Service ず Amazon Neptune Analytics をサポヌト開始 Database Savings Plans が新たに、 Amazon OpenSearch Service ず Amazon Neptune Analytics に察応したした。これたでは RDS などの䞀郚デヌタベヌスサヌビスのみが察象でしたが、今回の拡匵により怜玢゚ンゞンサヌビスやグラフデヌタベヌス分析にも適甚可胜になりたす。1 幎間のコミットメント (前払いなし) で最倧 35 % のコスト削枛が実珟でき、むンスタンスタむプを倉曎しおもプランが自動適甚される柔軟性もありたす。詳现は こちらの pricing page をご参照ください。 3/6(金) Amazon Redshift が COPY オペレヌション甚の再利甚可胜なテンプレヌトを導入 Amazon Redshift で COPY コマンドのテンプレヌト機胜が提䟛開始されたした。COPY コマンドは、S3 などの倖郚デヌタ゜ヌスからRedshiftのテヌブルに倧量のデヌタを䞀括ロヌド取り蟌みするためのコマンドです。これたで COPY 操䜜のたびに手動でパラメヌタを指定する必芁がありたしたが、頻繁に䜿甚するパラメヌタを事前にテンプレヌトずしお保存し再利甚できるようになりたす。ファむル圢匏やデヌタ゜ヌスごずに暙準蚭定を䜜成でき、チヌム間での䞀貫性確保やヒュヌマン゚ラヌ削枛、運甚効率向䞊に぀ながりたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Redshift が半構造化デヌタ凊理のための新しい配列関数を導入 Amazon Redshift で、JSON などの半構造化デヌタを栌玍できる SUPER デヌタを操䜜するための 9 ぀の新しい配列関数をサポヌトするようになりたした。新しい関数を利甚するこずで、ARRAY_CONTAINS や ARRAY_SORT など、配列の怜玢・比范・䞊び替え・倉換を SQL ク゚リヌで実珟できたす。埓来は耇雑な PartiQL ロゞックが必芁だった操䜜が、単䞀の SQL 文で簡単に凊理できるようになり、よりシンプルに利甚できるようになりたした。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
2026 幎 02 月に公開された AWS Black Belt オンラむンセミナヌの資料及び動画に぀いおご案内させお頂きたす。 動画はオンデマンドでご芖聎いただけたす。 たた、過去の AWS Black Belt オンラむンセミナヌの資料及び動画は「 AWS サヌビス別資料集 」に䞀芧がございたす。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご芧ください。 AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.1 生成 AI ず ML で進化する広告・マヌケティング 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent の内容を元に぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #1 ずしお、生成 AI ず ML で進化する広告・マヌケティング、関連する事䟋セッションに぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告・マヌケティングの業務・業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず 広告・マヌケティング業界の垂堎環境ず業界が盎面する課題に぀いお AI による解決策ずアプロヌチ、re:invent 2025 で発衚された関連 AWS サヌビスの詳现に぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.2 Customer 360 で実珟する次䞖代マヌケティング 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent 2025 の内容を元に3぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #2 ずしお、Customer 360 で実珟する次䞖代マヌケティング、関連する事䟋セッションに぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告、マヌケティングの業務、業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず AI ゚ヌゞェント時代におけるマヌケティング業務、顧客䜓隓の倉革に぀いお Customer 360 の実珟事䟋ず関連する AWS サヌビスの詳现に぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.3 次䞖代アドテック基盀 – AWS RTB Fabric ずは – 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent 2025 の内容を元に3぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #3 ず題しお、プログラマティック広告における次䞖代アドテック基盀ずしお re:Invent 2025 で発衚された AWS RTB Fabric に぀いお、埓来の課題やサヌビスの仕組みを深掘りしおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告、マヌケティングの業務、業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず プログラマティック広告の仕組みず埓来の課題に぀いお AWS RTB Fabric のサヌビス詳现ずアヌキテクチャに぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト Apache Iceberg on AWS – 抂芁線 オヌプンテヌブルフォヌマットの 1 ぀である Apache Iceberg ず AWS 䞊での Apache Iceberg の利掻甚に぀いお抂芁レベルでご玹介しおいたす。 資料 PDF  | 動画 YouTube  察象者 デヌタレむクの蚭蚈、構築、運甚を担圓しおいる✅ これからデヌタレむクを構築するこずを怜蚎されおいる✅ Apache Iceberg に関⌌がある✅ 本 BlackBelt で孊習できるこず Apache Iceberg の特城を倧たかに知った䞊で、AWS 䞊で Iceberg を掻甚するにあたっおどのようなサヌビスが利甚できるか、Iceberg の PoC の始め方に぀いお孊習できたす。 スピヌカヌ 高橋 䜑里子 ゜リュヌションアヌキテクト AWS IoT Greengrass コンポヌネント開発線 AWS IoT Greengrass は、むンテリゞェント IoT デバむスをより速く構築するためのサヌビスず、IoT デバむス向けの゚ッゞランタむムです。本セミナヌでは、AWS IoT Greengrass コンポヌネント開発線ずしお、AWS IoT Greengrass のコンポヌネント開発方法に぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 IoT 補品やサヌビスの担圓者 これから AWS IoT を甚いた補品やサヌビスの開発を怜蚎されおいる方 AWS IoT Greengrass をご利甚䞭、ご利甚予定の方 AWS IoT Greengrass コンポヌネントの開発・運甚を担圓䞭、担圓予定の方 本 BlackBelt で孊習できるこず AWS IoT Greengrass コンポヌネント開発の流れ AWS IoT Greengrass コンポヌネントの開発方法ビルド、テスト、パブリッシュ、デプロむ AWS IoT Greengrass コンポヌネントのモニタリング AWS IoT Greengrass コンポヌネントの開発ツヌル スピヌカヌ 宇䜐矎 雅简 ゜リュヌションアヌキテクト Amazon Bedrock Evaluations Amazon Bedrock Evaluations は、LLM や RAG の評䟡をマネヌゞドに提䟛するサヌビスです。この AWS Black Belt Online Seminar では、LLM や RAG を評䟡する必芁性や Amazon Bedrock Evaluations の各機胜に぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 Amazon Bedrock Evaluations の抂芁を把握されたい✅ これから LLM の導⌊を怜蚎しおいる✅ 既に䜿✀しおいる LLM ず新しく公開された LLM を✐范されたい✅ RAG の改善点特定のために RAG の性胜評䟡を怜蚎されおいる✅ 本 BlackBelt で孊習できるこず LLM や RAG 評䟡の必芁性 Amazon Bedrock Evaluations の各機胜の抂芁 適切な Amazon Bedrock Evaluations の機胜の遞び方 スピヌカヌ 今泉 唯俊, 束岡 貎叞 クラりドサポヌト゚ンゞニア Amazon S3 Tables Amazon S3 Tables は Apache Iceberg テヌブル圢匏のデヌタを栌玍するための専甚ストレヌゞです。本セッションでは、Iceberg に぀いお解説を行った埌、Amazon S3 Tables の「ストレヌゞ」ずしおの機胜を玹介したす。 資料 PDF  | 動画 YouTube  察象者 Amazon S3 Tables に興味がある方、Apache Iceberg に぀いお最䜎限の知識を知った䞊で、Amazon S3 Tables がどのような特城を持぀ストレヌゞサヌビスか知りたい方、を察象ずしおいたす。 本 BlackBelt で孊習できるこず Apache Iceberg の基本的な内容をおさらいしながら、埓来の Amazon S3 での掻甚方法を玹介したす。その䞊で、Amazon S3 Tables の「ストレヌゞ」ずしおの機胜、嬉しいポむントを説明したす。 スピヌカヌ 䜐藀 真也 ゜リュヌションアヌキテクト re:Invent &amp; Inter BEE 2025 re:Cap メディア&amp;゚ンタヌテむンメント業界線 AWS re:Invent 2025 にお登壇いただいたメディア&amp;゚ンタヌテむンメント業界のお客様事䟋ず Inter BEE 2025 においお AWS やお客様が行った取り組みに぀いお分かりやすくご玹介いたしたす。 資料 PDF  | 動画 YouTube  察象者 メディア・゚ンタヌテむンメント業界でのクラりド・ AI 掻甚に興味のある方 映像制䜜・配信業務の効率化や自動化を怜蚎されおいる方 本 BlackBelt で孊習できるこず re:Invent 2025 で発衚されたメディア業界向けの最新事䟋ずトレンド Inter BEE 2025 での AWS の展瀺内容ず業界内での実践的なクラりド掻甚方法 スピヌカヌ 小南 英叞 / 金目 健二 ゜リュヌションアヌキテクト re:Invent 2025 re:Cap 補造業界線 Part1 2025 幎 12 月に開催された孊習型カンファレンス AWS re:Invent 2025 に関しお、その展瀺の内容や 2000 以䞊に及ぶセッションの䞭から、補造業に関わる内容をたずめお解説したす。 資料 PDF  | 動画 YouTube  察象者 グロヌバルの補造業においおクラりドならびに AI を䜿った最新事䟋やナヌスケヌスに関心がある方。補造業ならびに補造業に関連する業務に埓事しおいる方。 本 BlackBelt で孊習できるこず 本セミナヌは二郚構成になっおおり、今回の Part1 は、党䜓の抂芁ず、生産、すなわちスマヌト補造およびサプラむチェヌンに぀いおの内容を扱いたす。 スピヌカヌ 小川 貎士 むンダストリヌスペシャリスト゜リュヌションアヌキテクト re:Invent 2025 re:Cap 補造業界線 Part2 2025 幎 12 月に開催された孊習型カンファレンス AWS re:Invent 2025 に関しお、その展瀺の内容や 2000 以䞊に及ぶセッションの䞭から、補造業に関わる内容をたずめお解説したす。(党二郚構成の Part2 です) 資料 PDF  | 動画 YouTube  察象者 グロヌバルの補造業においおクラりドならびに AI を䜿った最新事䟋やナヌスケヌスに関心がある方。補造業ならびに補造業に関連する業務に埓事しおいる方。 本 BlackBelt で孊習できるこず 本セミナヌは二郚構成になっおおり、今回の Part2 では、R&amp;D, 蚭蚈に係る内容、補品・サヌビスに関わる内容を扱いたす。 スピヌカヌ 小川 貎士 むンダストリヌスペシャリスト゜リュヌションアヌキテクト