TECH PLAY

AWS

AWS の技術ブログ

å…š3216ä»¶

本蚘事は「 Build with Kiro: Introducing the community hub and Kiro Labs 」を翻蚳したものです。 Kiro コミュニティは、日々新たなものを生み出し続けおいたす。境界を抌し広げるハッカ゜ンプロゞェクトから、カスタムフック、創造的な゚ヌゞェントワヌクフロヌ、そしお SNS や Discord で共有される MCP むンテグレヌションたで、皆さんは私たちの想像を超える堎所ぞ Kiro を連れお行っおくれたした。Amazon 瀟内でも同じ珟象が起きおいたす。倚様なバックグラりンドを持぀ビルダヌたちが、私たちの予想を超える圢で Kiro を最倧限に掻甚するワヌクフロヌ、むンタヌフェむス、ツヌルをカスタマむズしおいたす。そしお今、私たちはこれらすべおにふさわしい拠点を甚意したした。 本日、 Kiro コミュニティハブ を公開したす。これは Kiro.dev 䞊の新しい拠点で、コミュニティが䜕を䜜っおいるかを発芋し、より良く・より速く開発するためのリ゜ヌスを芋぀け、Kiro を䜿う他の開発者ず぀ながり、Kiro をフィヌチャヌしたむベントで実践的に孊ぶこずができる堎所です。コミュニティによっお䜜られたプロゞェクトや Kiro powers ず䞊んで、Kiro Labs も公開したす。Kiro Labs は新たに立ち䞊げる GitHub Organization で、Amazon 瀟員が Kiro を䜿い、Kiro のために䜜成したオヌプン゜ヌスプロゞェクト専甚の堎所です。Kiro での開発䜓隓を拡匵・匷化するこずを目的ずしおいたす。プロゞェクトは GitHub の kirodotdev-labs で公開されおおり、fork しお拡匵し、自分のものにしおいただけたす。 Kiro Labs でより良く開発する 私たちは、最も速いむノベヌションはオヌプンな堎所で生たれるず信じおいたす。この 1 幎、Amazon 瀟内のビルダヌたちが、驚くほどの詊行錯誀ずパヌ゜ナラむズを通じお、個人レベルおよびチヌムレベルでのベストプラクティスを定矩しおいくのを芋おきたした。Kiro Labs は、この成果を共有する仕組みです。これによっお皆さんがむンスピレヌションを埗お、孊び、さらに発展させられるようになりたす。 Kiro Labs のプロゞェクトは実隓的か぀コミュニティ䞻導であり、公匏の kirodotdev GitHub Organization ずは別物であり、Kiro の公匏サポヌト察象機胜ではありたせん。これらは無保蚌で as-is ずしお共有されおおり、Kiro で䜕を䜜れるかのむンスピレヌションを䞎え、開発を加速させるこずを目的ずしおいたす。゚ヌゞェントやフックなどを含むカスタムワヌクフロヌ、Kiro CLI 䞊のパヌ゜ナラむズされたナヌザヌむンタヌフェむス、Kiro の利甚を最適化する生産性ツヌルなど、幅広いプロゞェクトがありたす。プロゞェクトは as-is のオヌプン゜ヌスラむセンスで公開されおいたすが、公開前に Amazon のオヌプン゜ヌス基準に埓ったコヌドレビュヌおよびセキュリティレビュヌを経おおり、それぞれに明確なステヌタスが付いおいたす: Active (積極的にメンテナンスされ、コントリビュヌションを受け付けおいる)、Maintenance (バグ修正のみ)、Archived (読み取り専甚、メンテナンス終了)。 Kiro Labs の dotkiro は、チヌムの Kiro ステアリングファむルやスキルを単䞀の Git リポゞトリから同期させる軜量な CLI です。初期化、曎新、远加、削陀を 1 ぀のコマンドで実行できたす。すべおの開発者が同じ芏玄を共有し、芏玄の曎新は単なるプルリク゚ストで完結したす。 Kiro Labs はコミュニティが参加するための堎所です。これらのプロゞェクトを詊し、Issue を起祚し、プルリク゚ストを送信し、フィヌドバックを共有しおいただくこずを歓迎したす。プロゞェクトがアむデアの皮になったり、あなたのナヌスケヌスに合わなかったりした堎合は、ぜひ教えおください。皆さんの意芋が、これらのツヌルがどのように進化しおいくかを圢䜜る䞊で重芁です。 GitHub の kirodotdev-labs でプロゞェクトを探玢しお感想を教えおください。たたは、SNS で @kirodotdev をメンションし、#KiroLabs タグを付けお、あなたのアダプテヌションを共有しおください。 コミュニティプロゞェクトからむンスピレヌションを埗る Kiro Labs は Amazon 瀟員がどのように実隓しおいるかを玹介する堎所ですが、 コミュニティショヌケヌス は Kiro コミュニティが䜕を䜜っおいるかを発芋できる堎所です。私たちは、Kiro での開発を目に芋える、共有された䜓隓にしたいず考えおいたす。他の人が䜜っおいるものを芋られるようになれば、より速く開発し、実蚌されたパタヌンに基づいお反埩改善でき、お互いを刺激し合っおさらに前進できたす。コミュニティショヌケヌスでは、プロゞェクトの皮類を暪断しお簡単に探玢・発芋できたす。そしお、Kiro で䜜ったものをコミュニティに共有したい堎合は、コミュニティショヌケヌスから盎接 応募 できたす。最高のアむデアは私たちからではなく、皆さんから生たれたす。 ここでは、Kiro での開発を支揎するコミュニティ執筆のガむド、チュヌトリアル、その他のリ゜ヌスも取り䞊げおいきたす。Kiro の機胜は今埌も拡匵されおいきたすが、その成長の過皋でコミュニティからのコントリビュヌションを継続的に玹介しおいきたいず考えおいたす。これらのリ゜ヌスは、他のリ゜ヌスでは十分にカバヌできない郚分で開発者を支揎するこずを目的ずした、実䞖界のナヌスケヌスやプロゞェクトを衚珟しおいたす。 オンラむンおよびオフラむンで぀ながる 優れたツヌルは、ビルダヌ同士が぀ながり察話しおいるずきに、より速く䜜られたす。コミュニティハブでは、Kiro Discord コミュニティで進行䞭の䌚話を玹介しおいたす。ここでは他の開発者や Kiro チヌムメンバヌからサポヌトを受けたり、隔週開催の Kiro 公匏オフィスアワヌに参加したり、アむデアを共有したり、協力者を芋぀けたりできたす。 コミュニティハブのロヌンチに合わせお、Kiro 関連の今埌のむベントを芋぀けるための初の統合リ゜ヌスも公開したす。Kiro チヌム䞻催のものだけでなく、コミュニティ䞻催のものも含たれたす。ハッカ゜ン、ワヌクショップ、ミヌトアップ、ラむブ配信、カンファレンスを䞀箇所で芋぀けられたす。バヌチャルでも察面でも、リアルタむムで䞀緒に開発するこずで、実践的に孊び、他の人ず盎接぀ながる機䌚が埗られたす。そしおコミュニティを最倧限にサポヌトするため、独自の Kiro むベントをカレンダヌ掲茉甚に申請するフォヌム、およびクレゞット、スタッフィング、マヌケティングなど倚様な遞択肢で Kiro チヌムからのサポヌトをリク゚ストするオプションも甚意したした。皆さんがどのようなむベントを䌁画し、私たちがどのようにお手䌝いできるか、楜しみにしおいたす。 Kiro コミュニティに参加する コミュニティハブず Kiro Labs は、同じストヌリヌの䞀環ずしお公開されたす。Kiro は、それを䜿う人々によっお圢䜜られるように蚭蚈されおいたす。私たちはただ始たったばかりで、皆さんが䜕を䜜るのかを楜しみにしおいたす。Labs プロゞェクトを fork しおみる、Issue を起祚する、プルリク゚ストを送信する、フィヌドバックを共有するなど、ぜひ詊しおみおください。自身のプロゞェクトをコミュニティショヌケヌスに応募したり、Discord チャンネルに参加したり、むベントに参加したりもできたす。皆さんのご意芋は、Kiro ずこのコミュニティがどのように進化しおいくかを圢䜜る助けずなりたす。私たちは、その進化を掚進するためのコントロヌルずツヌルを、より倚く皆さんの手に届けたいず考えおいたす。 コミュニティハブ にアクセスする Kiro Labs を探玢する Discord に参加する X 、 LinkedIn 、 Instagram で @kirodotdev を、 Bluesky で @kiro.dev をメンションし、#BuildWithKiro タグを付けおあなたの䜜品を共有しおください
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 2026 幎の AWS Summit Japan がいよいよ近づいおきたしたね今幎は Agent AI の進化が目芚たしく、今週のアップデヌトを芋おも Amazon Bedrock AgentCore や Amazon Quick など、AI ゚ヌゞェント関連の発衚が盛りだくさんです。Summit ではこれらの最新技術を䜓感できるデモ展瀺やセッションが倚数予定されおいるず思うず、今からわくわくが止たりたせん。みなさんも䌚堎でぜひ最新の Agent AI を䜓隓しおみおください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎4月27日週の䞻芁なアップデヌト 4/27(月) Amazon EC2 M8in および M8ib むンスタンスを発衚 EC2 でカスタム第6䞖代 Intel Xeon Scalable プロセッサ (Granite Rapids) を搭茉した M8in (ネットワヌク最適化) および M8ib (EBS 最適化) むンスタンスの䞀般提䟛を開始したした。M8in.96xlarge は 600 Gbps のネットワヌク垯域幅を提䟛し、これは enhanced networking に察応した EC2 むンスタンスの䞭で最も高い倀です。M8ib.96xlarge は 最倧 300 Gbps の EBS 垯域幅を提䟛し、非アクセラレヌテッドコンピュヌトむンスタンスの䞭で最高の EBS 性胜を実珟したす。前䞖代 M6in/M6ib ず比范しお最倧 43% の性胜向䞊を実珟しおいたす。 AWS Billing Conductor が Billing Transfer ナヌザヌ向けに Passthrough Pricing Plan を提䟛開始 AWS Billing Conductor は AWS の料金請求をカスタマむズしお、独自の料金䜓系を䜜りたい方向けのサヌビスです。Billing Transfer ã¯ã€AWS Organizations の管理アカりントが倖郚アカりントに請求管理を委譲できる機胜ずなるのですが、この機胜で Passthrough Pricing Plan を提䟛開始したした。Passthrough Pricing Plan を遞択するず、ビリンググルヌプ内のすべおのアカりントが、AWS の請求額をそのたた反映したデヌタを確認できたす。独自の割匕を保護したり、請求デヌタをカスタマむズする必芁がない Direct Customers や Channel Partners は、無料でこのプランを利甚できたす。この機胜は US East (N. Virginia) リヌゞョンで利甚可胜です。 Amazon Redshift Serverless の AI-driven scaling がすべおの新しいワヌクグルヌプでデフォルトに Amazon Redshift Serverless は、すべおの新しいワヌクグルヌプで AI-driven scaling and optimization をデフォルトで有効にしたした。この機胜は機械孊習を䜿甚しおコンピュヌトニヌズを予枬し、ク゚リがキュヌに入る前に自動的にリ゜ヌスを調敎したす。たた、Base RPU の範囲を埓来の 32-512 RPU から 8-512 RPU に拡倧し、AI-driven scaling の利甚開始コストを削枛したした。price-performance slider により、コスト、パフォヌマンス、たたはその䞡方のバランスを遞択でき、手動チュヌニングなしで優れた䟡栌察性胜を実珟したす。 4/28(火) Amazon Quick がチャット内でのドキュメントずビゞュアル䜜成をサポヌト Amazon Quick は、チャット内で Word、Excel、PowerPoint、PDF などのドキュメントず、むンフォグラフィックやチャヌトなどのビゞュアルを自然蚀語で䜜成できる機胜を远加したした。ナヌザヌはツヌルを切り替えるこずなく、䌚話の䞭でドキュメントを䜜成、線集、ダりンロヌドできたす。ドキュメント䜜成機胜は Amazon Quick が利甚可胜な党リヌゞョンで提䟛され、ビゞュアル䜜成機胜は US East (N. Virginia) ず US West (Oregon) でプレビュヌずしお提䟛されたす。たた、Amazon Quick には Free プランが远加され、AWS アカりントやクレゞットカヌドなしで quick.aws.com から無料で利甚を開始できたす。 Amazon Quick で自然蚀語を䜿甚したカスタムアプリケヌション構築機胜 (プレビュヌ) Amazon Quick で、自然蚀語でカスタムりェブアプリケヌションを数分で䜜成できる新機胜 Apps in Amazon Quick をプレビュヌ版ずしお提䟛を開始したした。埓来は開発者リ゜ヌスや技術スキルが必芁だった瀟内ツヌルやりェブアプリケヌションの構築を、コヌディング䞍芁で実珟しやすくなりたす。個人的に良いなず思っおいるのは、Amazon Quick の仕組みの䞭でアプリケヌションを操䜜できるようになるので、Amazon Quick にログむン出来る方にのみ限定した公開が出来るずいう点です。組織内で奜きにアプリケヌションの実装を蚱すず、セキュリティのガバナンスが利かせられにくくなり、思わぬ倖郚公開になっおしたうこずがありたす。Apps in Amazon Quick でアプリケヌションを䜜成するず、Amazon Quick にログむンできる方のみアクセスを提䟛できる仕組みが実珟できるのが、玠敵なポむントですね。 Amazon Quick が macOS ず Windows 向けデスクトップアプリケヌション (プレビュヌ版) ずしお利甚可胜に Amazon Quick のネむティブデスクトップアプリケヌション (macOS/Windows 察応) がプレビュヌ版ずしお提䟛開始されたした。Web ブラりザ版の機胜に加え、ロヌカルファむルぞの盎接アクセス、OS レベルの通知、バックグラりンド゚ヌゞェント、ブラりザ自動化、知識グラフなど、デスクトップ統合機胜を提䟛したす。開発者向けには Model Context Protocol (MCP) によるロヌカルツヌル連携をサポヌトし、コヌディング゚ヌゞェントずの統合が可胜です。珟圚は US East (N. Virginia) リヌゞョンの Free/Plus プラン、Professional/Enterprise プランの党サブスクラむバヌが利甚できたす。なお、Amazon Quck on desktop を利甚した際に、デヌタが AI モデルのトレヌニングに利甚されない点が Document に蚘茉 されおいたす。 Amazon Bedrock で OpenAI モデル、Codex、Managed Agents を提䟛開始 (Limited Preview) AWS ず OpenAI がパヌトナヌシップを拡倧し、Amazon Bedrock 䞊で 3 ぀の新機胜を Limited Preview ずしお提䟛開始したした。1 : OpenAI の最新モデルが Bedrock 経由でアクセス可胜になりたす。2 : OpenAI のコヌディング゚ヌゞェント Codex が AWS 環境内で利甚可胜になり、CLI、デスクトップアプリ、VS Code 拡匵機胜から AWS 認蚌情報で実行できたす。3 : OpenAI を掻甚した Amazon Bedrock Managed Agents により、本番環境察応の AI ゚ヌゞェントを迅速にデプロむできたす。すべおの利甚は既存の AWS クラりドコミットメントに適甚可胜で、IAM、AWS PrivateLink、暗号化、CloudTrail ログなどの゚ンタヌプラむズ管理機胜を継承したす。 Amazon Connect Talent による AI を掻甚した採甚゜リュヌション (Preview 提䟛開始) Amazon Connect Talent は、AI ゚ヌゞェントを掻甚した採甚゜リュヌションで、Preview ずしお提䟛が開始されたした。Amazon の数十幎にわたる採甚をしおきた経隓に基づき、構造化された音声面接、科孊的裏付けのある評䟡、䞀貫性のあるスコアリングを AI ゚ヌゞェントが実行したす。候補者は 24 時間 365 日、あらゆるデバむスから面接を受けるこずができ、採甚担圓者は AI チヌムメむトが生成したスコア、トランスクリプト、詳现な候補者評䟡をレビュヌしお、より迅速か぀客芳的な採甚刀断を行うこずができたす。US East (N. Virginia) および US West (Oregon) リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore Runtime が Node.js のダむレクトコヌドデプロむに察応 Amazon Bedrock AgentCore Runtime が Node.js をマネヌゞド蚀語ランタむムずしおサポヌト開始したした。埓来の Python に加えお、Node.js が远加サポヌトされた圢です。TypeScript プロゞェクト (JavaScript ぞコンパむル埌) や Strands Agents SDK などの゚ヌゞェントフレヌムワヌクで構築した゚ヌゞェントもデプロむ可胜です。Node.js を利甚した Agent でセッション分離、SigV4 ず OAuth 2.0 による認蚌、双方向ストリヌミング、マネヌゞドセッションストレヌゞ、Amazon CloudWatch による observability などの AgentCore の各機胜を利甚できたす。 4/29(æ°Ž) Amazon QuickSight で Filter Controls のカスタム゜ヌトをサポヌト Amazon Quick の QuickSight (BI 機胜) にある Filter Controls で、Quick カスタム゜ヌト機胜が远加されたした。Filter Controls は、ダッシュボヌドに衚瀺するデヌタのフィルタヌが行えたす。埓来はドロップダりンなどに衚瀺される衚瀺順がアルファベット順でしたが、独自の䞊び順に倉曎できるようになりたした。䟋えば、「Critical, High, Medium, Low」ずいう業務䞊の優先順䜍に合わせた䞊び順を指定できるようになりたした。QuickSight がサポヌトされる党リヌゞョンで利甚可胜です。 Amazon CloudFront がキャッシュタグによる無効化をサポヌト Amazon CloudFront は、キャッシュタグによるオブゞェクト無効化機胜を远加したした。この機胜により、URL パスが異なっおいたずしおも、キャッシュコンテンツを 1 回のリク゚ストで無効化できたす。埓来は個別の URL を远跡するか、広範なワむルドカヌドパタヌンで無関係なコンテンツたで無効化する必芁がありたしたが、タグベヌスの無効化によりキャッシュ無効化の範囲を限定しやすくなりたす。タグを付䞎するためには、CloudFront のオリゞン偎で、タグを付䞎したす。䟋えば、response.headers[‘x-amz-meta-cache-tag’] = ‘user001’ こういった圢で事前にタグを付䞎するこずで、特定のタグに玐づくキャッシュデヌタを無効化できたす。 Amazon RDS for MySQL が Preview Environment で MySQL Innovation Release 9.6 を発衚 Amazon RDS for MySQL は、RDS Database Preview Environment で MySQL コミュニティ Innovation Release 9.6 のサポヌトを開始したした。MySQL 9.6 は 2026幎1月20日にリリヌスされた最新の Innovation Release で、Foreign Key 制玄凊理の SQL レむダヌ移行、Audit Log Component の远加、JSON Duality Views DML Tagging などの新機胜がありたす。Preview Environment は最新機胜の評䟡専甚環境であり、DB むンスタンスは䜜成埌 60日間で自動削陀されるので、本番環境ではなく怜蚌ずしおご利甚ください。 4/30(朚) Amazon Quick が Microsoft Excel、PowerPoint 拡匵機胜を远加、Word 拡匵機胜を曎新 (Preview) Amazon Quick は Microsoft 365 環境向けの拡匵機胜を匷化し、Excel ず PowerPoint の新芏拡匵機胜、および Word 拡匵機胜のアップデヌトをプレビュヌ提䟛開始したした。これにより、AI を掻甚しお、ドキュメントの修正䜜業、財務モデルの構築、プレれンテヌション資料の䜜成などの耇雑なタスクを Microsoft 365 アプリケヌション内で盎接実行できたす。珟圚 7 リヌゞョンで利甚可胜で、無料アカりントでの利甚が可胜です。 AWS Lambda が Ruby 4.0 をサポヌト AWS Lambda が Ruby 4.0 のサポヌトを開始したした。Ruby 4.0 は最新の長期サポヌト (LTS) リリヌスで、2029幎3月たでセキュリティアップデヌトずバグ修正が提䟛されたす。マネヌゞドランタむムずコンテナベヌスむメヌゞの䞡方に察応し、AWS が自動的にアップデヌトを適甚したす。たた、Ruby 4.0 ランタむムでは Lambda Advanced logging controls に察応し、JSON 構造化ログ、ログレベルの蚭定、CloudWatch ログ グルヌプのカスタマむズが可胜になりたした。党リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore の最適化機胜をプレビュヌ版ずしお提䟛開始 Amazon Bedrock AgentCore に、AI ゚ヌゞェントのパフォヌマンスを継続的に改善する 3 ぀の最適化機胜 (Recommendations、Batch evaluations、A/B tests) が远加されたした。これにより、本番環境で皌働する AI ゚ヌゞェントの「芳枬 → 評䟡 → 改善」を実行しやすくなりたす。Recommendations は CloudWatch Logs のトレヌスデヌタを分析し、AI が自動的に最適化された system prompt や tool descriptions を提案したす。Batch evaluations で事前定矩したテストケヌスによる怜蚌を実行し、A/B tests で本番トラフィックに察する統蚈的怜蚌を行いたす。 Amazon Bedrock AgentCore Identity で On-Behalf-Of (OBO) トヌクン亀換をサポヌト Amazon Bedrock AgentCore Identity が OAuth 2.0 の On-Behalf-Of (OBO) トヌクン亀換機胜の䞀般提䟛を開始したした。この機胜により、゚ヌゞェントは認蚌枈みナヌザヌの代わりに保護されたリ゜ヌスにアクセスする際、ナヌザヌに耇数回の同意フロヌを求めるこずなくアクセスできたす。䟋えば、カスタマヌサポヌト担圓者が AgentCore 䞊の AI Agent を通じお、耇数の顧客管理システムから情報を取埗したいずしたす。各システムに個別にログむンするのは倧倉なので、OBO トヌクン亀換を組み蟌むこずで、担圓者は䞀床の認蚌だけで耇数システムに透過的にアクセスできるようになりたす。 Amazon ECS Managed Instances で NVIDIA GPU メトリクスをサポヌト Amazon ECS Managed Instances で NVIDIA GPU メトリクスが利甚可胜になりたした。CloudWatch Container Insights の enhanced observability を通じお、GPU の総数、CPU 利甚率、GPU のメモリ䜿甚率、ハヌドりェアヘルス、枩床などのメトリクスを取埗できたす。これにより、AI/ML トレヌニングや掚論などの GPU アクセラレヌテッドワヌクロヌドのトラブルシュヌティングず最適化が可胜になりたす。すべおの商甚 AWS リヌゞョンで利甚可胜です。 Amazon EKS が CloudShell を介したワンクリッククラスタヌアクセスに察応 Amazon EKS が AWS CloudShell を介したワンクリッククラスタヌアクセス機胜を提䟛開始したした。EKS コン゜ヌルから「Connect」ボタンをクリックするだけで、kubectl が事前蚭定された CloudShell セッションが起動し、ロヌカルでの kubectl、AWS CLI、kubeconfig ファむルのむンストヌルや蚭定が䞍芁になりたす。パブリックおよびプラむベヌト API ゚ンドポむントの䞡方をサポヌトし、すべおの EKS 利甚可胜リヌゞョンで远加料金なしで利甚できたす。 5/1(金) Amazon RDS for SQL Server が远加ストレヌゞボリュヌムでのクロスアカりントスナップショット共有に察応 Amazon RDS for SQL Server が、远加ストレヌゞボリュヌム (最倧 256 TiB) を䜿甚するデヌタベヌスむンスタンスのクロスアカりントスナップショット共有機胜に察応したした。これにより、最倧 256 TiB たでスケヌル可胜な远加ストレヌゞボリュヌム構成でも、AWS アカりント間でスナップショットの䜜成、共有、コピヌが可胜になりたす。コンプラむアンス芁件に基づく分離されたバックアップ環境の構築や、本番環境の問題を別アカりントで蚺断する甚途に掻甚できたす。党おの AWS 商甚リヌゞョンで利甚可胜です。 Amazon EKS が Elastic Fabric Adapter 向けに Kubernetes Dynamic Resource Allocation をサポヌト Amazon EKS が EFA (Elastic Fabric Adapter) 向けに DRA (Dynamic Resource Allocation) をサポヌトしたした。DRANET プロゞェクトをベヌスにした EFA DRA ドラむバヌにより、トポロゞヌ察応の EFA むンタヌフェヌス割り圓おず、耇数 Pod 間でのむンタヌフェヌス共有が可胜になりたす。同じ PCIe バス䞊に存圚する GPU ず EFA を玐づけお EKS の Pod ずしお皌働するこずで、デヌタの受け枡し効率を向䞊でき、AI/ML/HPC ワヌクロヌドにおける高性胜なノヌド間通信ず RDMA を効率的に利甚できたす。Kubernetes 1.34 以降を実行する EKS マネヌゞドノヌドグルヌプたたはセルフマネヌゞドノヌドで利甚可胜です。 Amazon Bedrock AgentCore における AWS for SAP MCP Server の䞀般提䟛開始 AWS は Amazon Bedrock AgentCore 䞊で動䜜する AWS for SAP MCP Server の䞀般提䟛を開始したした。この゜リュヌションは、AI ゚ヌゞェントが SAP ERP システム (SAP S/4HANA および SAP ECC) に盎接アクセスを提䟛したす。前提条件ずしお、SAP 偎で OData V2 が有効化されおいる必芁がある点に留意ください。SAP ECC に SAP NetWeaver Gateway が暙準的にはむンストヌルされおおらず、远加の蚭定が必芁な堎合がありたす。AWS for SAP MCP Server は、CloudFormation テンプレヌトを䜿甚しお AgentCore 䞊にデプロむが可胜です。 Amazon CloudFront が VPC Origins の WebSocket サポヌトを発衚 Amazon CloudFront が Virtual Private Cloud (VPC) Origins を通じた WebSocket トラフィックのサポヌトを開始したした。これにより、リアルタむムアプリケヌションをプラむベヌトサブネット内にホストしたうえで、CloudFront 経由のアクセスを提䟛できたす。埓来は WebSocket サヌバヌをパブリックサブネットに配眮し、ACL などで保護する必芁がありたしたが、珟圚は Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 むンスタンスをプラむベヌトサブネット内に配眮し、CloudFront 経由でのみアクセス可胜にできたす。VPC Origins でサポヌトされおいる党おの AWS Commercial リヌゞョンで利甚可胜で、远加料金はかかりたせん。 Amazon CloudWatch RUM の Web アプリケヌション向け Session Replay 機胜 Amazon CloudWatch RUM (Real User Monitoring) に、Web アプリケヌション向けの Session Replay 機胜が远加されたした。フロント゚ンド偎の実装で、aws-rum-web を import ずしお、Session Replay 機胜を有効化するこずで、実際のナヌザヌの操䜜内容に関するデヌタが Amazon CloudWatch RUM に送信されたす。その埌、Web アプリケヌション開発者偎で、ナヌザヌのブラりザ䞊での実際の操䜜クリック、スクロヌル、ペヌゞ遷移、゚ラヌをビデオのように再生できるようになり、問題の確認がより簡単になるアップデヌトです。なお、ナヌザヌ入力に関するテキスト入力ずコンテンツはデフォルトでマスクされ、個人情報などのプラむバシヌは保護されたす。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です。
本ブログは、KDDI 株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 アラむアンスシステムグルヌプ 侭野 利圊 氏、久保田 剛史 氏ず、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 安藀 が共同で執筆したした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの安藀です。 マネヌゞドサヌビスを組み合わせたサヌバヌレスアヌキテクチャは開発・運甚の効率化に倧きく貢献する䞀方で、耇数サヌビスにたたがる耇合的なむンシデントぞの察応は䟝然ずしお難しい課題です。今回は、 KDDI株匏䌚瀟 以䞋、KDDIが AWS DevOps Agent を掻甚し、むンシデント察応のリヌドタむムを倧幅に短瞮した取り組みをご玹介したす。AWS DevOps Agent は、むンシデント発生時に自埋的にメトリクス・ログ・デプロむ履歎を暪断分析し、根本原因の仮説ず察応案を提瀺する AI ゚ヌゞェントです。AI を「答え合わせ」のパヌトナヌずしお䜍眮づけるこずで、粟床ず速床を䞡立した新しいむンシデント察応ワヌクフロヌの実践䟋をご玹介したす。 導入背景 KDDI は通信事業を基盀ずしながら、au PAY・Pontaポむント・゚ンタメ・゚ネルギヌなど、ナヌザヌの生掻に密着した倚圩なサヌビスを展開しおいたす。今回ご玹介するのは、そのパヌ゜ナル事業を支えるシステムの䞀぀、Web サヌビス向けのビゞネスロゞックプラットフォヌムです。このシステムは、Webフロントシステムに察するポむントの集蚈や抜遞などのリワヌドの提䟛・゚ンタメサヌビス連携など、倚圩なサヌビスを提䟛しおおり、サヌバヌレスアヌキテクチャを採甚しおいたす。AWS Lambda によるリク゚スト凊理、Amazon RDS Proxy を介したデヌタアクセス、デヌタレむクぞの蓄積を軞に、耇数の倖郚システムず SFTP 連携による倧量ファむル分析も行う倧芏暡な構成です。 Webサヌビス向けのビゞネスロゞックプラットフォヌムのアヌキテクチャ 本プラットフォヌムで、Amazon API Gateway の 5XX ゚ラヌず AWS Lambda のスロットリングが耇数の Lambda で同時発生するむンシデントが起きたした。オンラむンリク゚ストの応答に支障をきたすむンシデントです。リク゚スト数は急増しおおらず、スロットリング発生を起点に特定の Lambda の凊理時間が高止たりするずいう挙動から、AWS Lambda / Amazon RDS Proxy / Amazon Aurora にたたがる耇合的な問題が疑われたした。 障害発生時のメトリクス こうした耇数のマネヌゞドサヌビスが絡む問題は、ナヌザヌ偎では深いずころたで把握できないため原因の特定が難しく、メトリクスやログのやり取りを繰り返しながら数週間を費やすこずも珍しくありたせんでした。たどり着いた察応策が暫定的なものにずどたり、再び同じ調査ルヌプに入っおしたうケヌスも少なくありたせんでした。 ゜リュヌションAWS DevOps Agent を「先行調査官」ずしお掻甚する この課題を打開するために、本プラットフォヌムの運甚チヌムでは AWS DevOps Agent を詊隓的に導入したした。 AWS DevOps Agent は、2025幎12月の AWS re:Invent でパブリックプレビュヌずしお発衚され、2026幎3月31日に 䞀般提䟛が開始 されたサヌビスです。アラヌトが発生した瞬間から自埋的に調査を開始し、Amazon CloudWatch をはじめ Datadog・Dynatrace・Grafana・New Relic・Splunk などのオブザヌバビリティツヌル、CI/CD パむプラむンのデプロむ履歎、゜ヌスコヌドリポゞトリなど耇数の情報源を暪断的に分析しお根本原因の仮説ず察応案を提瀺したす。プレビュヌ期間䞭の実瞟では、MTTR を最倧75%削枛、調査時間を 80% 短瞮、根本原因の特定粟床 94% ずいう効果が報告されおいたす。 特城的なのは、チャットで深掘りしながら粟床を䞊げおいける点です。AWS DevOps Agent は誀った掚論をした堎合もチャット䞊で指摘・修正できるため、䞀方的に出力を受け取るのではなく、察話を重ねながら仮説の粟床を高めおいくこずができたす。たた、゜ヌスコヌドや蚭定倀、ログを統合的に分析できるため、AWS Lambda の autocommit 蚭定ず Amazon RDS Proxy の挙動の関係など、単䞀のメトリクスだけでは芋えにくい問題箇所も特定しやすくなりたした。 DevOps Agentずのやり取り 重芁なのは、AWS DevOps Agent の出力をそのたた正解ずしお扱うのではなく、「AWS サポヌトぞの問い合わせ前の仮説敎理ツヌル」ずしお䜍眮づけた点です。AWS DevOps Agent が提瀺した察応案を持っお AWS サポヌトに問い合わせ、「この提案の有効性を確認したい」「他に芋萜ずしおいる芳点はないか」ずいう圢で察話するこずで、サポヌトずのコミュニケヌションが栌段にスムヌズになりたした。 AWS サポヌトずの連携が倉わった 埓来は、むンシデント発生埌に KDDI の運甚チヌムが個別にメトリクス・ログを分析し、AWS サポヌトぞ問い合わせ、远加情報の提䟛ず原因調査を繰り返すサむクルに数週間を費やすこずもありたした。察応策の効果が限定的な堎合は最初のステップに戻るルヌプも発生しおいたした。 AWS DevOps Agent の導入埌は、このやり取りの質が倧きく倉わりたした。埓来は「䜕が起きおいるかを䞀から説明する」ずころから始たっおいたやり取りが、「AWS DevOps Agent からこういう提案が出おいるが、この芳点は正しいか」ずいう圢に倉わりたした。AWS DevOps Agent で原因調査・耇数察応案の策定・初期有効性刀断を先に行い、その結果をもずに AWS サポヌトぞ「答え合わせ」的に問い合わせるこずで、双方が同じ情報・同じ仮説を共有した状態で議論できるようになりたした。根本原因分析の共有コストが䞋がり、耇数の察応案を同時䞊行で怜蚌環境に適甚できるため、党䜓のリヌドタむムを数日単䜍に圧瞮するこずができたした。 AWS DevOps Agent の「 Ask for human support 」機胜からサポヌトケヌスを䜜成するこずで、調査ログが自動的に AWS サポヌトぞ共有されるため、調査内容の党文を手動で説明する手間がありたせん。AWS DevOps Agent が客芳的な第䞉者ずしお仮説を敎理し、KDDI の運甚チヌムず AWS サポヌトがその仮説を怜蚌・補匷するずいう䞉者の圹割分担が自然に生たれたした。AI が倧量のメトリクス・ログ・蚭定倀を暪断的に分析しお仮説を提瀺し、AWS サポヌトはその有効性を確認・深掘りする。このやり取りが、調査の粟床ず速床を同時に高めるこずに぀ながりたした。 今回のむンシデントでは、AWS サポヌトずの調査を通じお、AWS Lambda ず Amazon RDS Proxy 間のセッション管理の蚭定に起因する根本原因が特定されたした。障害自䜓はその埌自然解消しナヌザヌ圱響も収束したしたが、再発防止に向けお曞き蟌みず読み取りのリク゚ストを適切に分離する構成ぞの倉曎が有効であるこずを AWS サポヌトずの連携で確認枈みであり、珟圚 KDDI 偎で怜蚌を進めおいたす。 【泚意】 AWS DevOps Agent から AWS サポヌトぞのケヌス起祚・チャット連携を利甚するには、AWS サポヌトプランの契玄が必芁です。Basic サポヌトではテクニカルサポヌトケヌスを䜜成できないため、この機胜は利甚できたせん。Developer サポヌトではケヌスの起祚は可胜ですが、チャットによるやり取りには察応しおおらず、AWS Support Center での察応ずなりたす。DevOps Agent 䞊の統合チャット䜓隓を含むすべおの機胜を掻甚するには、Business サポヌト以䞊のプランが必芁です。詳现は AWS サポヌトプランのペヌゞ をご参照ください。 導入効果ず今埌の展望 AWS DevOps Agent の掻甚により、KDDIのむンシデント察応は「数週間」から「数日」ぞず倧幅に短瞮されたした。被疑箇所の特定から耇数の察応案の策定・怜蚌たで、リヌドタむムを数日単䜍に圧瞮できたこずは倧きな成果です。AI を䞇胜な答えずしお扱うのではなく、仮説生成ず優先順䜍付けのパヌトナヌずしお掻甚し、AWS サポヌトずの協働で粟床を担保するずいうアプロヌチは、マネヌゞドサヌビスを倚甚するサヌバヌレスアヌキテクチャにおいお特に有効です。KDDI では今埌も AWS DevOps Agent の掻甚を深めおいく予定です。今回はむンシデント発生埌の原因調査ずいう䜿い方が䞭心でしたが、プロアクティブな障害予防機胜にも期埅しおいたす。過去のむンシデントパタヌンを孊習しお再発防止策を提案するこの機胜を掻甚するこずで、障害が起きおから察応するのではなく、起きる前に手を打おる運甚ぞの転換を目指しおいたす。たた、Amazon CloudWatch・Amazon EventBridge・Amazon SNS ず連携するこずで、珟圚は手動で行っおいる DevOps Agent の調査起動をアラヌム発火ず同時に自動化するこずも芖野に入れおいたす。調査完了埌はその結果を Kiro に枡し、チケット起祚やリポゞトリの調査ずいった埌続の運甚䜜業をそのたた Kiro ず連携しお進める流れも怜蚎しおおり、怜知から察応たでの䞀連のサむクルをより効率化しおいきたいず考えおいたす。 たずめ 本ブログでは、KDDI による AWS DevOps Agent を掻甚したむンシデント察応効率化の事䟋をご玹介したした。 今回の取り組みで特に印象的だったのは、「AI に答えを出させる」のではなく「AI ず䞀緒に問いを立おる」ずいう䜿い方です。AWS DevOps Agent が仮説を敎理し、AWS サポヌトがその仮説を怜蚌・補匷する。この圹割分担によっお、人ず AI ずサポヌトの䞉者がそれぞれの匷みを発揮できる新しい協働モデルが生たれたした。 マネヌゞドサヌビスを倚甚する珟代のクラりドアヌキテクチャでは、むンシデントの原因が単䞀サヌビスに収たらないケヌスが増えおいたす。そうした耇雑な状況だからこそ、「たず仮説を持っおから盞談する」ずいうアプロヌチが、解決たでの道のりを倧きく倉えたす。本事䟋が、同様の課題を抱えるチヌムにずっお䞀぀のヒントになれば幞いです。 著者 侭野 利圊 様 右 KDDI株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 グルヌプリヌダヌ 久保田 剛史 様 巊 KDDI株匏䌚瀟 パヌ゜ナル事業統括本郚 システム開発本郚 ラむフデザむンプラットフォヌム郚 安藀 麻衣 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ ゜リュヌションアヌキテクト  
本日、AWS は AWS SDK for SAP ABAP Knowledge MCP Server の䞀般提䟛開始を発衚したした。このリリヌス以前は、IDE ず AWS ドキュメントの間でコンテキストスむッチを行い、汎甚的な䜿甚方法や䟋を基に自分で ABAP コヌドを䜜成する必芁がありたした。この MCPModel Context Protocolサヌバヌにより、゚ヌゞェント型 IDE が公匏の AWS SDK for SAP ABAP リファレンスず同じ信頌性の高いドキュメントを䜿甚しお、その䜜業を代行したす。2023幎に ABAP SDK をリリヌスした際、 Amazon Bedrock 、 Amazon Simple Storage Service 、 Amazon Textract などの AWS サヌビスを玔粋な ABAP で呌び出す方法を瀺す 80,000 ペヌゞ以䞊の ドキュメント を同時にリリヌスしたした。ABAP SDK が増え続ける AWS サヌビスのリストに察応し続ける䞭で、そのドキュメントは 130,000 ペヌゞ以䞊に拡倧しおいたす。同時に、 Amazon Q Developer for Eclipse や Kiro のような゚ヌゞェント型 IDE の台頭を目にしおおり、お客様からはこのドキュメントにアクセスしお IDE の機胜を匷化する AI 搭茉ツヌルが求められおいたす。AWS SDK for SAP ABAP Knowledge MCP Server は、LLM倧芏暡蚀語モデルのコンテキストりィンドりを効率的か぀節玄的に䜿甚する方法でこれを実珟したす。 MCP サヌバヌの䜿甚方法 ゚ヌゞェント型 IDE に MCP サヌバヌを蚭定するず、AWS SDK for SAP ABAP の広範なドキュメントラむブラリを怜玢する必芁がなくなりたす。IDE ず䌚話するだけで、シナリオに特化したガむダンスを埗るこずができたす lv_bytes の PDF デヌタを lv_bucket ずいう S3 バケットに保存する ABAP 構文は䜕ですか レスポンスには正しい構文が含たれたす lo_s3->putobject( iv_bucket = lv_bucket iv_key = 'my-document.pdf' iv_body = lv_bytes iv_contenttype = 'application/pdf' ). 次のステップ 開始するには、 Getting Started ペヌゞ にアクセスしお、任意の MCP クラむアントを AWS SDK for SAP ABAP Knowledge MCP Server ゚ンドポむントに接続するための蚭定䟋をご確認ください。この MCP サヌバヌは、認蚌䞍芁でワヌクステヌションに远加゜フトりェアをむンストヌルする必芁のない HTTPS ゚ンドポむントずしお提䟛されたす。ツヌルはドキュメントの読み取り専甚ク゚リです。必芁な蚭定は、゚ヌゞェント型 IDE に URL を提䟛するこずだけです。 IDE を蚭定した埌、゚ヌゞェント型 IDE ず䌚話しおサンドボックス S/4HANA システムで ABAP コヌドプログラムを開発しおみたしょう。以䞋のプロンプトを詊しお開始しおください SAPGUI からアップロヌドされた耇数ペヌゞの PDF ファむルを受け取り、フィヌルドを抜出しお画面に曞き出す ABAP レポヌトを䜜成しおください。適切な AWS サヌビスを䜿甚しおください 2぀のビゞネスパヌトナヌ間の最短運転距離を蚈算する ABAP レポヌトを、AWS サヌビスを䜿甚しお䜜成しおください サヌビスオヌダヌのテキストを読み取り、機密性の高い PII が含たれおいるかどうかを刀定する ABAP レポヌトを、AWS サヌビスを䜿甚しお䜜成しおください たずめ AWS SDK for SAP ABAP Knowledge Server により、゚ヌゞェント型 IDE が SDK ドキュメントを代わりに読み取るため、AWS SDK for SAP ABAP の党機胜を掻甚した ABAP コヌドを容易に開発できたす。MCP サヌバヌの ABAP SDK ドキュメントのナレッゞベヌスは毎日曎新され、SDK のリリヌスサむクルに合わせお゚ヌゞェント型 IDE を最新の状態に保ちたす。MCP サヌバヌは無料で䞀般公開されおおり、AWS アカりントは䞍芁で、グロヌバルに利甚可胜です。 SAP on AWS ディスカッションに参加する AWS re:Post の SAP on AWS トピックでコミュニティに参加したしょう。お客様のアカりントチヌムや AWS Support チャネルに加えお、SAP on AWS ゜リュヌションアヌキテクチャチヌムが SAP on AWS トピックを定期的にモニタリングし、ディスカッションや質問に察応しおいたす。サポヌトに関連しない質問がある堎合は、 re:Post でディスカッションに参加し、コミュニティのナレッゞベヌスに貢献するこずをご怜蚎ください。 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
抂芁 珟圚、AWS䞊の本番SAP HANAデヌタベヌスのヘルスチェックを行うには、6぀以䞊のAWSサヌビスにたたがる10以䞊のAPI呌び出しが必芁です。 AWS Systems Manager for SAP SSM for SAPや AWS Console for SAP Applications でアプリケヌションのステヌタスを確認し、 Amazon CloudWatch CloudWatchでCPU、メモリ、ディスクのメトリクスを確認し、 AWS Backup でHANAバックアップのステヌタスを怜蚌し、SSM for SAPを䜿甚しおアプリケヌションの構成チェックを実行し、SAPホスト䞊のファむルシステム䜿甚状況を怜査し、これらすべおのデヌタを手動で盞関分析する必芁がありたす。各サヌビスには独自のAWSマネゞメントコン゜ヌル、API、CLI、出力圢匏がありたす。 手動䜜業に加えお、AWS䞊のSAPワヌクロヌドの管理には、各サヌビスのAPI、必芁なパラメヌタ、レスポンス構造に関する深い知識が求められたす。このようなクロスサヌビスワヌクフロヌを自分で構築するずいうこずは、カスタムスクリプトの䜜成ず保守、耇数サヌビスにたたがる゚ラヌケヌスの凊理、APIの倉曎ぞの远埓を意味したす。そのような専門知識は少数のチヌムメンバヌに集䞭しおいるこずが倚く、圌らが䞍圚の堎合にボトルネックが生じたす。 AWS For SAP Management MCP Server は、この耇雑さを単䞀の自然蚀語による䌚話に簡玠化したす。耇数のAWSマネゞメントコン゜ヌルを操䜜したり、異なるAPIやCLIの入出力構造を蚘憶したりする代わりに、AIアシスタント Kiro —AI搭茉のIDE、 Kiro-CLI —AI支揎開発の力をタヌミナルに提䟛するツヌル、たたはMCPサヌバヌ統合をサポヌトするその他のツヌルにSAPランドスケヌプの管理に関する質問をするだけで、構造化されたSAP察応の回答を埗るこずができたす。 この蚘事では、このMCPサヌバヌのセットアップ方法を孊び、AIドリブンのむンサむトの取埗、SAP管理の自動化の実行、既存のワヌクフロヌやAWS環境ずの統合に぀いお説明したす。 MCPサヌバヌずは䜕か、なぜSAP運甚に必芁なのか Model Context ProtocolMCP は、AIアシスタントが構造化された方法で倖郚ツヌルを呌び出すこずを可胜にするオヌプンスタンダヌドです。MCPサヌバヌは、AIアシスタントが䜿甚できる専門ツヌルキットです。この堎合、SAPを理解するツヌルキットです。 AWS䞊のSAPアプリケヌションは、財務、サプラむチェヌン、人事などのコアビゞネスプロセスを実行しおいたす。珟圚、これらはSSM for SAPおよびAWS Console for SAP Applicationsを通じお提䟛される専甚の゚クスペリ゚ンスで管理されおいたす。しかし、MCPサヌバヌがなければ、AIアシスタントは自身が知っおいる情報のみで䜜業するこずになり、AI機胜ずSAP固有の運甚の間にギャップが生じたす。 AWS For SAP Management MCP Serverは、この機胜をAIアシスタントにもたらしたす。サヌバヌが持぀知識—SAPコンポヌネントの䟝存関係、怜蚌枈みパタヌン、クロスサヌビスロゞック—を1぀のむンタヌフェヌスに統合し、察話できるようにしたす。このMCPをAIアシスタントに蚭定するこずで、適切なSAPコンテキストず20以䞊のSAP察応ツヌルぞのアクセスが埗られたす。これらのツヌルは、ラむブSAP環境で管理ク゚リを実行し、AWSサヌビス間でデヌタを盞関分析し、SAP的に意味のある結果を返し、お客様の承認を埗おアクションを実行できたす。 仕組み AWS For SAP Management MCP Serverは、デスクトップたたは既存のむンフラストラクチャ䞊でロヌカルに実行され、MCP暙準stdioトランスポヌトを介しおAIアシスタントに接続したす。既存のAWS認蚌情報 ~/.aws/config を䜿甚しおAPI呌び出しを行い、远加のむンフラストラクチャは䞍芁です。このMCPサヌバヌはSSM For SAPを基盀ずしお構築されおおり、登録されたアプリケヌションを基瀎ずしお䜿甚したす。SAPアプリケヌションは、AWS Console for SAP Applications、SSM for SAPの API / CLI 、たたは AWS API MCP Server を䜿甚しお該圓する入力を提䟛するこずで登録できたす。 機胜ず安党制埡 AWSLabs を通じお公開されおいるこのMCPサヌバヌは、さたざたなトラブルシュヌティング、モニタリング、自動化のナヌスケヌスに䜿甚できたす。SAPアプリケヌションのトポロゞヌ—システムを構成するコンポヌネント、それらの盞互関係、それらをサポヌトするAWSリ゜ヌス—を理解しおいたす。MCPサヌバヌは4぀の領域にわたる20以䞊の構造化ツヌルを公開しおいたす モニタリングずレポヌト読み取り専甚 登録されたすべおのアプリケヌション、コンポヌネントトポロゞヌ、メタデヌタを含む完党なSAPランドスケヌプの衚瀺 SSM for SAPからのSAPアプリケヌションステヌタス、Amazon CloudWatchからのメトリクス、AWS Backupからのバックアップステヌタス、ファむルシステム䜿甚状況、構成コンプラむアンスを単䞀のレスポンスに盞関させたヘルスサマリヌの取埗 コンプラむアンスやチヌムレビュヌ甚のダりンロヌド可胜なMarkdownヘルスレポヌトの生成 構成コンプラむアンス読み取り専甚 AWS Well-Architected Framework のSAP LensAWS䞊でSAPワヌクロヌドを実行するためのベストプラクティスを含むに察する構成チェックの実行 実際の倀ず期埅倀を瀺す個別のルヌル評䟡の詳现確認ず、修埩ガむダンスの提䟛 アプリケヌションラむフサむクル管理確認が必芁 自然蚀語によるSAPアプリケヌションの起動ず停止 サヌバヌはコンポヌネントの䟝存関係を理解しおいたす。HANAデヌタベヌスを停止する際、䟝存するNetWeaverアプリケヌションを怜出し、基盀ずなるEC2むンフラストラクチャずずもに正しい順序でカスケヌド停止するこずを提案し、実行前に明瀺的な確認を求めたす SSM for SAPぞの新しいSAPアプリケヌションの登録 スケゞュヌル運甚確認が必芁、リ゜ヌスを䜜成 Amazon EventBridge Scheduler EventBridge Schedulerを通じた定期スケゞュヌルの䜜成。䟋「開発甚SAPシステムを平日のみ実行するようスケゞュヌルする」 サヌバヌはEventBridge Schedulerの蚭定、IAMを通じたロヌル䜜成、ペむロヌド構築を凊理したす コスト最適化に有甚。䟋非本番システムを営業時間䞭のみ実行するようスケゞュヌル 安党性に぀いお 読み取り専甚の操䜜モニタリング、レポヌト、コンプラむアンスチェックは確認なしで実行されたす。アプリケヌションの停止やスケゞュヌルの䜜成など、状態を倉曎する操䜜は、サヌバヌが実行する前に明瀺的な確認を必芁ずしたす。AIアシスタントが蚈画されたアクションを提瀺し、承認を求めたす。 AIプロンプトの䟋 以䞋は、このMCPサヌバヌを䜿甚しお自然蚀語で実行できる䞀般的なタスクです 「すべおのSAPアプリケヌションを䞀芧衚瀺しお」 「本番HANAデヌタベヌスの珟圚のヘルスステヌタスは」 「HANA SAPアプリケヌションの構成チェック結果を衚瀺しお」 「SAPシステムHDBの構成チェックを毎週金曜日の午埌6時PDTに実行しお」 「HANAデヌタベヌスずその䟝存アプリケヌションを停止しお」 「アカりント内のSAPアプリケヌションのランドスケヌプを衚瀺しお」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA の状態はどうですかどのような問題が発生しおいたすか」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA を毎週金曜日の午埌6時PDTに停止し、毎週月曜日の午前6時PDTに再起動しお」 「SAPアプリケヌション LaunchWizardHanaSingleLargeR7i_HANA のヘルスサマリヌレポヌトを生成しおファむルに保存しお」 はじめに AWS For SAP Management MCP Serverの利甚開始は、わずか数分で完了したす。 前提条件 SSM for SAP、Amazon CloudWatch、Amazon EC2、Amazon EventBridge Scheduler、AWS Backup、SSM、IAMの暩限を持぀ ~/.aws/config で蚭定された AWS認蚌情報 SSM for SAPに登録された SAPアプリケヌション がMCPサヌバヌの基盀ずしお䜿甚されたす。 Kiro、Kiro-CLIなどの MCP互換AIアシスタント uvx がむンストヌルされた Python 3.10以䞊 。 pip install uvx たたはお䜿いのOSに察応するコマンドでuvxをむンストヌルし、 uvx –version を実行しおPATHに含たれおいるこずを確認しおください むンストヌル 開始する前に、䞊蚘の前提条件を完了しおいるこずを確認しおください。 AIアシスタントのMCP蚭定ファむルを 芋぀けたす ファむルの堎所に぀いおは Kiroドキュメント たたはお䜿いのアシスタントのドキュメントを確認しおください。 蚭定ファむルを 開き 、 mcpServers セクションに以䞋のブロックを远加したす { "mcpServers":{ "awslabs.aws-for-sap-management-mcp-server":{ "autoApprove":[ ], "disabled":false, "command":"uvx", "args":[ "awslabs.aws-for-sap-management-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>", "FASTMCP_LOG_LEVEL":"ERROR" }, "transportType":"stdio" } } } 泚意蚭定ファむルが存圚しない堎合は、䞊蚘の完党な構造で䜜成しおください。ファむルは存圚するが mcpServers セクションがない堎合は、セクションを远加しおください。 <YOUR_AWS_PROFILE> をお䜿いのAWSプロファむル名に 眮き換えたす 。 蚭定ファむルを 保存したす 。 uvx がPATHにない堎合は、フルパスを指定する必芁がある堎合がありたす。 新しい蚭定を読み蟌むためにAIアシスタントを 再起動したす 。 䞡方のMCPサヌバヌを䜵甚する AWS For SAP Management MCP Serverは、AWS API MCP Serverず補完的なツヌルずしお䜵甚するよう蚭蚈されおいたす。SAP固有のワヌクフロヌをドメむン知識で凊理し、SAPトポロゞヌ、コンポヌネントの䟝存関係、運甚のベストプラクティスを理解したす。AWS API MCP Serverは、SAP固有のツヌルでカバヌされない操䜜に察しお、AWSサヌビスAPIぞの汎甚アクセスを提䟛したす。 これらを組み合わせるこずで、AIアシスタントにSAP察応のむンテリゞェンスず幅広いAWSサヌビスカバレッゞの䞡方を提䟛できたす。䞡方を蚭定するこずを掚奚したす { "mcpServers":{ "awslabs.aws-for-sap-management-mcp-server":{ "autoApprove":[], "disabled":false, "command":"uvx", "args":[ "awslabs.aws-for-sap-management-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>", "FASTMCP_LOG_LEVEL":"ERROR" }, "transportType":"stdio" }, "awslabs.aws-api-mcp-server":{ "command":"uvx", "args":[ "awslabs.aws-api-mcp-server@latest" ], "env":{ "AWS_PROFILE":"<YOUR_AWS_PROFILE>" }, "transportType":"stdio" } } } 動䜜確認 AIアシスタントを 開きたす 。 AWS For SAP Management MCPが正垞に接続され、そのツヌルがアシスタントの利甚可胜なツヌルに衚瀺されるこずを 確認したす 。 簡単なプロンプトを䜿甚しお テストしたす 「 すべおのSAPアプリケヌションを䞀芧衚瀺しお 」ず入力し、レスポンスが期埅するSAPランドスケヌプず䞀臎するこずを確認したす。 ゚ラヌが衚瀺された堎合は、以䞋のトラブルシュヌティングセクションを確認しおください。 トラブルシュヌティング MCPサヌバヌがAIアシスタントに衚瀺されない 蚭定ファむルが有効なJSONであるこずを確認しおください 蚭定倉曎を保存した埌、AIアシスタントを再起動しおください uvx がむンストヌルされ、PATHに远加されおいるこずを確認しおくださいたたは蚭定でフルパスを䜿甚しおください。 認蚌゚ラヌ AWS_PROFILE が ~/.aws/config で正しく蚭定されおいるこずを確認しおください プロファむルに必芁なIAM暩限があるこずを確認しおください SAPアプリケヌションが怜出されない SAPアプリケヌションがSSM for SAPに登録されおいるこずを確認しおください プロファむルのAWSリヌゞョンが、SAPアプリケヌションが登録されおいるリヌゞョンず䞀臎しおいるこずを確認しおください 利甚可胜なリヌゞョンず料金 AWS For SAP Management MCP Serverは、 GitHubのAWS Labs MCPリポゞトリ でオヌプン゜ヌスプロゞェクトずしお本日より利甚可胜です。PyPI、Amazon Elastic Container RegistryAmazon ECR、Docker Hub、MCP Toolkitを通じお配垃されおいたす。 MCPサヌバヌ自䜓は無料です。お䜿いのマシン䞊でロヌカルに実行されたす。基盀ずなるAPI呌び出しSSM for SAP、Amazon CloudWatch、Amazon EventBridge Scheduler、AWS Backup、Amazon EC2に察する暙準的なAWSサヌビス利甚料金が適甚されたす。これは、AWSマネゞメントコン゜ヌルやAWS CLIを盎接䜿甚する堎合ず同じ料金です。 このサヌバヌは、 AWS Systems Manager for SAPがサポヌトされおいる AWSリヌゞョンで動䜜したす。 たずめ AWS For SAP Management MCP Serverは、AWS䞊のSAPワヌクロヌド管理の運甚䞊の耇雑さを軜枛したす。以前は耇数のコン゜ヌルを操䜜し、サヌビス間でデヌタを盞関分析する必芁があったタスク—ヘルスチェック、コンプラむアンス怜蚌、ラむフサむクル管理、スケゞュヌリング—が、単䞀の自然蚀語むンタラクションになりたす。 これは、AWS Console for SAP Applicationsビゞュアル管理およびSSM for SAP APIプログラムによるアクセスを補完する第3のオプションずしお機胜したす䌚話型のSAP察応運甚管理です。 AWS Labs MCPリポゞトリ にアクセスし、AIアシスタントでサヌバヌを蚭定しお始めたしょう。AWS Systems Manager for SAPの詳现なガむダンスに぀いおは、 SSM for SAPドキュメント および APIリファレンス をご芧ください。AWS䞊でのSAPワヌクロヌドの実行に぀いお詳しくは、 AWS for SAP をご芧ください。 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
SAP システムを運甚しおいる堎合、アップグレヌドの障壁ずなるカスタムコヌドの特定ず修正ずいう課題に盎面しおいるこずでしょう。 SAP Clean Core のアセスメント ず修正䜜業には数週間の手䜜業が必芁ずなり、モダナむれヌションのタむムラむンを加速するこずが困難になりたす。 Kiro ゚ヌゞェント は、SAP Clean Core 戊略ぞのアプロヌチを倉革したす。Clean Core ゞャヌニヌは通垞、カスタムコヌドのアセスメント、違反の修正、そしお今埌の Clean Core 方匏での運甚ずいう3぀のフェヌズで展開されたすが、Kiro ゚ヌゞェントはそのすべおを加速できたす。 GitHub でリリヌスされた これらのオヌプン゜ヌス゚ヌゞェントは、ABAP コヌド違反の分類を自動化し、詳现な修正ガむダンスを提䟛したす。数千の ABAP オブゞェクトを手動でレビュヌする代わりに、数週間かかっおいた包括的なアセスメントを数時間で完了できるようになりたす。 この蚘事では、Kiro ゚ヌゞェントを䜿甚しお SAP Clean Core アセスメントを自動化する方法、倧芏暡実装のコスト考慮事項、そしお最初の自動アセスメントを開始するためのステップバむステップの手順をご玹介したす。 SAP Clean Core を理解する SAP コアをクリヌンに保぀ ずは、暙準゜フトりェアぞの盎接的な倉曎を最小限に抑え、リリヌス枈み API を䜿甚しお拡匵ずしお新しい機胜を構築するこずを意味したす。これにより、S/4HANA システムはアップグレヌドに察応し、クラりド察応ずなり、SAP のむノベヌションが提䟛されるたびにそれを採甚できるようになりたす。 SAP の内郚オブゞェクトに䟝存するカスタムコヌドは、アップグレヌドリスクを生み出したす。Clean Core ガバナンスは、ABAP Cloud 開発モデルを通じおそのリスクを定量化し削枛するこずで、SAP の進化に合わせおシステムを保守可胜な状態に保ちたす。2025幎8月、SAP は以䞋の図に瀺す 新しい成熟床モデル をリリヌスしたした。これは、カスタム開発をクリヌンか吊かの二項分類ではなく、レベル A  D に分類するものです。すでにゞャヌニヌを開始しおいる堎合でも、これから始める堎合でも、䞻に泚力すべき点は以䞋の通りです 未䜿甚のカスタムコヌドの排陀 カスタムコヌドレベルの分類 レベル D からの脱华 SAP Clean Core カスタムコヌドのレベル分類 未䜿甚のカスタムコヌドの排陀 SAP のお客様ず協業する䞭で、䞀般的な組織ではカスタムコヌドの 50%  60% が䜿甚されおいないこずが芳察されおいたす。぀たり、ビゞネス䞊の利益なしにカスタムコヌドベヌスの半分以䞊を保守しおいる可胜性が高いのです。これを排陀するこずは Clean Core の優先事項リストの䞊䜍に䜍眮づけるべきであり、将来のプロゞェクトの簡玠化を可胜にしたす。 カスタムコヌドレベルの分類 SAP は分類ガむドラむンだけでなく、 ABAP Test CockpitATCチェックカテゎリ も提䟛しおいたす。ATC チェックを䜿甚しお珟圚の状況を把握したしょう。レベル別の Clean Core 分垃は、進捗を远跡するための有甚な指暙です。 Clean Core 察応に向けた取り組み レベル A は長期的なクラりド察応の北極星を衚したすが、ほずんどの組織にずっおレベル D コヌドの排陀が最も高い投資察効果をもたらしたす。レベル D コヌド倉曎、暗黙的/明瀺的゚ンハンスメント、SAP テヌブルぞの盎接曞き蟌み、未リリヌス API の䜿甚を含むは、アップグレヌドをブロックし、重倧なトランスポヌト゚ラヌを匕き起こしたす。レベル D からレベル C たたは B ぞの移行は、アップグレヌドの障壁を即座に取り陀き、完党な ABAP コヌドリファクタリングを必芁ずせずに技術的負債を削枛したす。この実甚的なアプロヌチにより、S/4HANA システムを最新の状態に保぀こずを積極的に劚げおいるコヌドの修正を優先できたす。 Kiro ゚ヌゞェントによる解決 Kiro ゚ヌゞェントを䜿甚しお SAP Clean Core アセスメントを自動化できるようになりたした。 GitHub でリリヌスされた オヌプン゜ヌスツヌルであるこれらの゚ヌゞェントは、コヌド違反の特定ず修正を効率化したす。゚ヌゞェントは ABAP コヌドベヌスを分析し、S/4HANA アップグレヌドをブロックする可胜性のあるレベル D コヌドに関する詳现なレポヌトを提䟛したす。リポゞトリには、詳现なセットアップ手順、ワヌクフロヌの抂芁、セキュリティに関する考慮事項、およびすぐに開始するための䟋が含たれおいたす。 以䞋のビデオ では、Clean Core フレヌムワヌクの抂芁を説明しおいたす。Kiro ゚ヌゞェントは既存の ABAP Test CockpitATCワヌクフロヌず統合し、Amazon Bedrock を通じお利甚可胜な基盀 AI モデルを䜿甚しお、修正タスクの分類ず優先順䜍付けを行いたす。゚ヌゞェントは ABAP Accelerator MCP Server の䞊に構築されおおり、初期コヌドスキャンから最終アセスメントレポヌトたでの完党なワヌクフロヌを提䟛したす。 コストに関する考慮事項 Kiro ゚ヌゞェントは Amazon Bedrock でホストされおいる AI モデルを䜿甚しおカスタムコヌドを分析し、コストはアセスメントするオブゞェクト数に応じおスケヌルしたす。Anthropic Claude Opus 4.5 でのテストに基づくず、1,000 の ABAP オブゞェクトのアセスメントには玄 700750 クレゞットが必芁で、4時間以内に完了したす。 Kiro Pro プラン月額 $20、1,000 クレゞット含むでは、このアセスメントは月間割り圓お内に完党に収たり、オブゞェクトあたり玄 $0.02 です。 異なるタスクに異なるモデルを蚭定するこずでコストを最適化できたす。品質が最も重芁なドキュメント䜜成や耇雑な分析には Anthropic Claude Opus を䜿甚し、定型的な ATC 分類チェックには Anthropic Claude SonnetAnthropic Claude Opus ず比范しお 40% 安䟡たたは Anthropic Claude HaikuAnthropic Claude Opus ず比范しお 80% 安䟡を䜿甚したす。このハむブリッドアプロヌチにより、高品質な結果を維持しながらアセスメントコストを 4050% 削枛できたす。 数千のオブゞェクトを持぀倧芏暡なコヌドベヌスの堎合、Kiro Power プラン月額 $200、10,000 クレゞットが最もコスト効率の高いオプションです。詳现に぀いおは、 Kiro の料金ペヌゞ をご芧ください。 始めたしょう この蚘事では、Kiro ゚ヌゞェントが未䜿甚のカスタムコヌドの排陀、コヌド成熟床レベルの分類、修正䜜業の優先順䜍付けにより、SAP Clean Core アセスメントをどのように自動化するかを孊びたした。 SAP Clean Core アセスメントを自動化する準備はできたしたか以䞋の手順に埓っお Kiro ゚ヌゞェントの䜿甚を開始しおください ツヌルぞのアクセス  Kiro ゚ヌゞェント GitHub リポゞトリ にアクセスしお最新リリヌスをダりンロヌドし、ドキュメントを確認しおください 環境のセットアップ 開発環境で ABAP Accelerator MCP Server を蚭定し、SAP システムぞの接続を確認しおください 最初のアセスメントの実行 ワヌクフロヌず出力圢匏に慣れるために、ABAP オブゞェクトの小さなサブセットから始めおください 実装のスケヌル プロセスに慣れたら、完党なコヌドベヌスのアセスメントに拡倧し、結果をアップグレヌド蚈画に統合しおください SAP Clean Core のベストプラクティスに関する远加のガむダンスに぀いおは、 ABAP Extensibility Guide – Clean Core および GitHub で利甚可胜な ATC Cloud Readiness Check Variants を確認しおください。 オヌプン゜ヌスを䞀緒に構築したしょう Clean Core ツヌルを䜿甚しおゞャヌニヌを加速するだけでなく、Kiro カスタム゚ヌゞェントで新しい機胜を拡匵・構築するこずをお勧めしたす。 皆様の経隓に぀いおお聞かせください。コメントセクションでフィヌドバックを共有するか、LinkedIn でお問い合わせください Ravi Kashyap 、 Stephan Kremer 、 Adam Hill 本ブログはAmazon Bedrockによる翻蚳を行い、パヌトナヌSA束本がレビュヌしたした。原文は こちら です。
私は 4 月 27 日週、英囜のペヌクで䌑暇を過ごしたした。ペヌクは、囜内で最も幜霊に取り぀かれた街ずしお知られおいたす。千幎近くにわたっおそこに立ち続けおきた修道院跡を散策し、䞭䞖の城壁沿いを散策し、倜はゎヌストツアヌに参加しお、䜕䞖玀にもわたっお語り継がれおきた物語に耳を傟けたした。これほど倚くの歎史を芋守っおきた堎所に立぀ず、䞍思議ず心が萜ち着きたす。今はデスクに戻っおきたしたが、その察比は吊応なく感じられたす。修道院の石は千幎もの間、ほずんど倉わるこずなくそこに立っおいるのに、たった 1 週間の䌑暇の間に、技術革新のスピヌドはたた䞀段進展しおいたした。 ノヌスペヌクシャヌにあるりィットビヌ修道院跡。千幎の歎史を芋守っおきた石がある䞀方で、この 1 週間だけで新たな倉化の波が抌し寄せたした。 それでは、2026 幎 5 月 4 日週の AWS ニュヌスを芋おいきたしょう。 䞻なトピック 4 月 28 日、AWS の CEO であるマット ガヌマン、SVP Amazon Applied AI Solutions である Colleen Aubrey 氏、AWS の CMO である Julia White、そしお OpenAI のリヌダヌたちが登壇し、お客様が゚ヌゞェントを利甚しおビゞネスのあり方をどのように倉えおいるのかに぀いお語りたした。このむベントでは、Amazon Quick、Amazon Connect、OpenAI ずのパヌトナヌシップの匷化に関する数々の発衚が行われたした。このむベントでの䞻な発衚のたずめをご玹介したす。 Amazon Quick が、デスクトップアプリケヌション、新しい料金プラン、ビゞュアルアセット生成で拡匵 – Amazon Quick は、お客様のアプリケヌションず連携し、お客様にずっお重芁なこずを孊習しお、お客様のためにアクションを実行する、業務甚 AI アシスタントです。今週、Quick は新しいデスクトップアプリケヌション (プレビュヌ) を発衚したした。このアプリケヌションを利甚するこずで、ブラりザを開かなくおも、ロヌカルファむル、カレンダヌ、コミュニケヌションに接続できたす。個人のメヌルアドレス、たたは既存の Google、Apple、Github、Amazon 認蚌情報を䜿甚しお数分でサむンアップできたす。AWS アカりントは䞍芁です。Quick は、チャットむンタヌフェむスから盎接、掗緎されたドキュメント、プレれンテヌション、むンフォグラフィック、画像を生成できるようになりたした。たた、ネむティブ統合機胜も拡匵され、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams が含たれるようになりたした。新しい「Quick でカスタムアプリケヌションを構築」機胜 (プレビュヌ) では、自然蚀語を䜿甚しおビゞネス党䜓ず連携するむンテリゞェントなアプリケヌション、ダッシュボヌド、りェブペヌゞを䜜成できたす。 Amazon Connect が 4 ぀の゚ヌゞェンティック AI ゜リュヌションに拡匵 – Amazon Connect は、単䞀の補品から、お客様既存のワヌクフロヌ内で動䜜するように蚭蚈された、䞀連の 4 ぀の゚ヌゞェンティック AI ゜リュヌションに拡匵されたす。Amazon Connect Decisions は、サプラむチェヌンプランニングおよびむンテリゞェンス゜リュヌションであり、30 幎にわたる Amazon の運甚科孊ず 25 を超える専門的なサプラむチェヌンツヌルを組み合わせるこずで、チヌムの業務を危機管理からプロアクティブな蚈画に移行させたす。Amazon Connect Talent (プレビュヌ) は、゚ヌゞェンティック AI 採甚゜リュヌションであり、倧芏暡な採甚を管理する人材獲埗リヌダヌ向けに、AI 䞻導の面接、科孊的根拠に基づいた評䟡、䞀貫性のある評䟡を提䟛したす。Amazon Connect Customer (旧称: Amazon Connect) は、音声、チャット、デゞタルチャネル党䜓でパヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスを提䟛したす。新しい蚭定機胜により、組織は、察話型 AI を数か月間ではなく数週間でセットアップできたす。Amazon Connect Health は、゚ヌゞェントによる患者確認、予玄管理、患者むンサむト、アンビ゚ントドキュメンテヌション、医療コヌディングを提䟛するこずで、患者がより迅速に医療ケアを利甚し、臚床医がその提䟛により倚くの時間を割けるようになりたす。 AWS ず OpenAI が Amazon Bedrock におけるパヌトナヌシップを拡倧 – AWS ず OpenAI は、最新の OpenAI モデルを Amazon Bedrock に導入し、Codex on Amazon Bedrock をリリヌスするほか、OpenAI を利甚する Amazon Bedrock Managed Agents を提䟛したす。すべお限定プレビュヌです。Amazon Bedrock 䞊の OpenAI モデル (限定プレビュヌ) は、GPT-5.5 や GPT-5.4 を含む最新の OpenAI モデルを、お客様が既にご利甚の Bedrock API に統合し、統合されたセキュリティ、ガバナンス、コストコントロヌルを提䟛したす。远加のむンフラストラクチャを蚭定する必芁も、新しいセキュリティモデルを孊ぶ必芁もありたせん。Codex on Amazon Bedrock (限定プレビュヌ) を䜿甚するず、既存の AWS 環境内で OpenAI コヌディング゚ヌゞェントにアクセスしお、AWS 認蚌情報を䜿甚しお認蚌し、Bedrock を通じお掚論凊理を実行するほか、Codex の䜿甚量を AWS クラりドのコミットメントに算入できたす。Codex on Bedrock は Bedrock API を通じお利甚でき、たずは Codex CLI、Codex デスクトップアプリケヌション、Visual Studio Code 拡匵機胜で利甚可胜です。OpenAI を利甚する Amazon Bedrock Managed Agents (限定プレビュヌ) は、OpenAI のフロンティアモデルず AWS むンフラストラクチャを組み合わせお、OpenAI を利甚する本番察応の゚ヌゞェントをクラりド内に構築したす。OpenAI ハヌネスを利甚しお構築するこずで、より迅速な実行、より鋭い掚論、長時間実行タスクの確実な制埡を実珟したす。 詳现に぀いおは、「 Top announcements of the What’s Next with AWS, 2026 」にアクセスしおください。 2026 幎 4 月 27 日週のリリヌス 4 月 27 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす: Amazon EC2 M8in および M8ib むンスタンスの䞀般提䟛を開始 – カスタムの第 6 䞖代むンテル Xeon Scalable プロセッサず第 6 䞖代 AWS Nitro Card を搭茉したこれらのむンスタンスは、M6in および M6ib ず比范しお、最倧 43% 高いパフォヌマンスを提䟛したす。M8in は 600 Gbps のネットワヌク垯域幅を提䟛し、M8ib は最倧 300 Gbps の EBS 垯域幅を提䟛したす。米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (スペむン) で利甚可胜です。 Amazon EC2 R8in および R8ib むンスタンスの䞀般提䟛を開始 – 同じ第 6 䞖代むンテル Xeon Scalable プロセッサず Nitro Card をベヌスに構築されたメモリ最適化むンスタンス。600 Gbps のネットワヌクず 300 Gbps の EBS 垯域幅プロファむルを備えおいたす。倧芏暡な商甚デヌタベヌス、デヌタレむク、SAP HANA などのむンメモリデヌタベヌスに適しおいたす。米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、欧州 (スペむン) で利甚可胜です。 Amazon EC2 C8ine および M8ine むンスタンスの䞀般提䟛を開始 – ネットワヌク最適化むンスタンス。C6in および M6in ず比范しお、最倧 2.5 倍の vCPU あたりのパケットパフォヌマンスず、最倧 2 倍のむンタヌネットゲヌトりェむ経由のトラフィックのネットワヌクスルヌプットを提䟛したす。仮想ファむアりォヌル、ロヌドバランサヌ、5G UPF ワヌクロヌドなどのセキュリティおよびネットワヌク仮想アプラむアンス向けに蚭蚈されおいたす。C8ine は米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (東京) で、M8ine は米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) で利甚可胜です。 Amazon Bedrock AgentCore が最適化機胜を远加 (プレビュヌ) – AgentCore は、本番での゚ヌゞェントの「芳察、評䟡、改善」のサむクルを完了するために、レコメンデヌション、バッチ評䟡、A/B テストを提䟛するようになりたした。レコメンデヌションは、本番のトレヌスず評䟡の出力を分析し、最適化されたシステムプロンプトずツヌルの説明を提案したす。これらは、事前定矩枈みのテストケヌスに察するバッチ評䟡、たたは実際のトラフィックに察する A/B テストで怜蚌できたす。すべおのレコメンデヌションは、リリヌス前に承認が必芁です。 AWS Lambda が Ruby 4.0 のサポヌトを远加 – 最新の LTS リリヌスである Ruby 4.0 が、Lambda マネヌゞドランタむムおよびコンテナベヌスむメヌゞずしお利甚可胜になりたした。JSON 構造化ログ、蚭定可胜なログ蚘録レベル、タヌゲット CloudWatch ロググルヌプ蚭定など、Lambda の高床なログ蚘録コントロヌルのサポヌトを含んでいたす。䞭囜リヌゞョンおよび AWS GovCloud (米囜) を含む、すべおの AWS リヌゞョンで利甚可胜です。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 その他の AWS ニュヌス 興味深いず思われる远加の蚘事やリ゜ヌスをいく぀かご玹介したす: Amazon Q Developer サポヌト終了のお知らせ – Amazon Q Developer IDE プラグむンず有料サブスクリプションのサポヌトは、2027 幎 4 月 30 日に終了したす。お客様は Kiro に移行する期間ずしお 12 か月の猶予がありたす。新芏サむンアップは 2026 幎 5 月 15 日からブロックされたすが、既存のサブスクリプションでは匕き続きナヌザヌを远加できたす。2026 幎 5 月 29 日より、Q Developer Pro では Opus 4.6 が利甚できなくなりたす。Opus 4.5 および他の既存モデルは匕き続き利甚可胜ですが、Opus 4.7 を含む最新のコヌディングモデルは Kiro でのみ利甚可胜です。AWS マネゞメントコン゜ヌルの Amazon Q Developer および AWS 公匏゚クスペリ゚ンス (ドキュメント、モバむルアプリ、Slack、Microsoft Teams) に圱響はありたせん。 AWS 10,000 AIdeas Competition: 受賞者の発衚 – AWS は、ビルダヌが Kiro ず AWS 無料利甚枠のみを䜿甚しお構築された AI アプリケヌションを応募するグロヌバルコンテストである 10,000 AIdeas Competition の受賞者 20 名を発衚したした。115 か囜から応募があり、4 回の審査ず 2 回のコミュニティ投祚を経お遞考されたした。受賞者は、Global Champions、Regional Champions、Innovation Awards、Creative Track の各カテゎリに分かれおおり、各カテゎリで賞金ず AWS クレゞットが授䞎されたす。 AWS Student Builder Groups  â€“ AWS Cloud Clubs は AWS Student Builder Groups に進化したした。コミュニティは珟圚、63 か囜、600 以䞊の倧孊やカレッゞに広がっおいたす。既存の Cloud Club メンバヌシップ、バッゞ、進捗状況は匕き継がれ、Cloud Club Captain は Group Leader になりたす。メンバヌシップは 18 歳以䞊の孊習者であれば誰でも参加できたす。AWS Builder Center で最寄りのグルヌプを探すか、たたはキャンパスで新しいグルヌプを立ち䞊げるための申請をするこずができたす。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう: AWS Summits – AWS Summits は、クラりドず AI をカバヌする無料の実地むベントです。5 月の開催予定: シンガポヌル (5 月 6 日)、 テルアビブ (5 月 6 日)、 ワルシャワ (5 月 6 日)、 ストックホルム (5 月 7 日)、 シドニヌ (5 月 13 日14 日)、 ハンブルク (5 月 20 日)、 ゜りル (5 月 20 日)、 アムステルダム (5 月 27 日)、 ミラノ (5 月 28 日)、 ムンバむ (5 月 28 日)。 AWS Community Days – コミュニティリヌダヌが䌁画および提䟛するコミュニティ䞻導のカンファレンス。今埌のむベントには、 むスタンブヌル (トルコ) (5 月 9 日) ず パナマシティ (パナマ) (5 月 23 日) が含たれおいたす。 AWS Builder Center にアクセスしお、他のビルダヌず亀流したり、゜リュヌションを提䟛したり、構築を継続するのに圹立぀リ゜ヌスを芋぀けたりしたしょう。たた、今埌開催される AWS 䞻導の実地およびオンラむンむベント や、 デベロッパヌ向けセッション もご芧いただけたす。 – Esra この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスや発衚を簡単にたずめお毎週ご玹介したす! 原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 今週は、日本時間 4 月 29 日に開催された  What’s Next with AWS  ã§ç™ºè¡šã•れた倧型のアップデヌトが倚数ありたした。AWS CEO の Matt Garman ず OpenAI のリヌダヌたちが登壇し、AI ゚ヌゞェントが䌁業の業務のあり方をどう倉えおいくかを議論するむベントで、Amazon Quick、Amazon Connect、そしお Amazon Bedrock に関する倚数のアップデヌトが発衚されたした。蚘事埌半のサヌビスアップデヌトずあわせおご芧ください。 生成 AI を掻甚したビゞネス倉革に取り組むお客様を支揎する 生成 AI 実甚化掚進プログラム は匕き続き参加䌁業を募集しおいたす。ご興味のある方はぜひご芧ください。 それでは、4 月 27 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 奈良垂ず日立システムズ様、個人番号利甚事務系の閉域環境で GenU を掻甚し特定保健指導の業務効率化を実珟 奈良垂ず株匏䌚瀟日立システムズ様は、マむナンバヌ系ネットワヌク䞊での生成 AI 掻甚に取り組みたした。個人番号利甚事務系は機埮情報を扱うためむンタヌネットから厳栌に分離されおおり、埓来は倖郚の生成 AI サヌビスを利甚するこずが困難でした。この課題に察し、ガバメントクラりド䞊に  Generative AI Use Cases (GenU)  の閉域モヌドを構築し、Amazon Bedrock を VPC Endpoint 経由で利甚する構成を採甚したした。特定保健指導における面談蚘録䜜成にリアルタむム文字起こしず専甚プロンプトによる 7 項目自動敎圢を適甚した結果、報告曞 1 件の䜜成時間が 1〜2 時間から 30〜60 分に短瞮され、珟堎担圓者党員が業務負担軜枛を実感し、今埌の継続利甚を垌望したした。日立システムズ様が担圓する党囜の自治䜓ぞの暪展開や、母子保健・児童盞談・障害犏祉ずいった同皮業務ぞの応甚が蚈画されおいたす。 ブログ蚘事「 2026 幎「What’s Next with AWS」からの泚目の発衚 」を公開 2026 幎 4 月 29 日に開催された What’s Next with AWS むベントでの䞻芁発衚のたずめ蚘事です。Amazon Quick の新しいデスクトップアプリ・Free/Plus プラン・ビゞュアル生成・倖郚統合拡倧、Amazon Connect の Decisions・Talent・Customer・Health の 4 ゜リュヌション展開、そしお Amazon Bedrock 䞊での OpenAI モデル・Codex・マネヌゞド゚ヌゞェントの提䟛開始限定プレビュヌなど、倧型アップデヌトが俯瞰できたす。本蚘事の埌半のサヌビスアップデヌトずあわせおご芧ください。 ブログ蚘事「 【開催報告】AWS Retail & CPG EXPO 2026 — AI ゚ヌゞェントが倉える流通小売・消費財業界の珟堎を䜓感 」を公開 2026 幎 4 月 20 日に AWS 東京オフィスで開催された、流通小売・消費財業界向け完党招埅制むベントの開催報告ブログです。NRF 2026 で発衚された 7 ぀の AI ゚ヌゞェントデモを日本向けにロヌカラむズしお展瀺するずずもに、株匏䌚瀟コヌセヌ様、株匏䌚瀟 asken 様、株匏䌚瀟ゎヌルドりむン様、株匏䌚瀟カむンズ様の生成 AI 掻甚事䟋セッションが実斜されたした。各瀟ずも「珟堎定着」「Vibe Coding」「経営ず珟堎のギャップ」「生成 AI による画像生成の実店舗掻甚」ず切り口が異なり、業界の AI ゚ヌゞェント実装の珟圚地を知るこずができる内容です。 ブログ蚘事「 補造業 × 生成 AI 、8 瀟の「ここだけの話」が぀ながり課題解決を加速する — AWS 生成 AI ラりンドテヌブル in 倧阪 開催報告 」を公開 2026 幎 3 月 31 日に AWS 倧阪オフィスで開催された、補造業 8 瀟シャヌプ、ダマハ、村田補䜜所、日立産業制埡゜リュヌションズ、コベルコシステム、東掋玡、倧日本印刷、ダむキン工業のクロヌズド・ラりンドテヌブルの開催報告です。瀟内ツヌルの珟堎定着、少人数での AI 掚進䜓制、補造業特有の非構造化デヌタの扱いずいった共通課題に察し、各瀟の実践知が亀換された様子が玹介されおいたす。AWS セッションでは Amazon Bedrock AgentCore ã‚’掻甚した AgentOps の 4 ステップ評䟡フレヌムワヌクも玹介されおいたす。 ブログ蚘事「 Amazon Q Developer のサポヌト終了に関するお知らせ 」を公開 Amazon Q Developer の IDE プラグむンず有償サブスクリプションのサポヌトが 2027 幎 4 月 30 日に終了するこずが発衚されたした。埌継ずなる Kiro ã¯ä»•様駆動開発spec-driven developmentのためにれロから構築された゚ヌゞェント型開発環境で、Specs、Hooks、Steering files、Custom subagents、Powers ずいった機胜を備えおいたす。2026 幎 5 月 15 日以降は新芏サむンアップの受付が停止されたすが、既存ナヌザヌは 2027 幎 4 月 30 日たで利甚可胜です。なお、AWS マネゞメントコン゜ヌルや AWS Console Mobile App、Slack/Microsoft Teams のチャットアプリで提䟛されおいる Amazon Q Developer は今回の察象倖で、匕き続きご利甚いただけたす。 ブログ蚘事「 Amazon Quick を瀟内のナレッゞに接続しよう – Microsoft SharePoint Online ç·š 」を公開 Amazon Quick の AI ゚ヌゞェントを瀟内の SharePoint Online に接続する方法を、ナレッゞベヌス連携AI が怜玢・回答ずアクション連携自然蚀語でリスト・ファむル・Excel を盎接操䜜の 2 ぀のアプロヌチでステップバむステップに解説しおいたす。Entra ID でのアプリ登録方法から ACL を匕き継ぐ Admin-managed setup、コネクタ䜜成の詳现たで扱われおおり、これから SharePoint ず Quick を連携させたい方の導入ガむドずしお最適です。 ブログ蚘事「 Amazon Quick を䜿甚した゚ンタヌプラむズ向けパッチ適甚・むンベントリダッシュボヌドの構築 」を公開 AWS Systems Manager のむンベントリ情報ずパッチ適甚状況を、Amazon Quick の自然蚀語プロンプトで可芖化する゜リュヌションを解説しおいたす。CloudFormation テンプレヌトをデプロむし、「Create a pie chart for count of resourceid by provider」のようなプロンプトでダッシュボヌドを玠早く構築できたす。倚段階の手動操䜜を数回のプロンプトに眮き換える、生成 BI のわかりやすいナヌスケヌスです。 ブログ蚘事「 「NVIDIA Robotics Solutions 勉匷䌚」を開催したした 」を公開 2026 幎 4 月 14 日に開催された、フィゞカル AI 開発支揎プログラム採択䌁業向けの勉匷䌚の開催報告です。NVIDIA の Isaac Sim / Isaac Lab / Cosmos / GR00T ずいったロボティクス向け技術スタックの玹介に加え、Physical AI 開発の各フェヌズデヌタ生成、モデル孊習、モデル配信に最適な Amazon EC2 むンスタンスG6e/G7e、P5、P5en/P6-B200 などの遞び方、AWS CDK でデプロむできる開発環境サンプル Remote AWS Develop Station (RADS) が玹介されおいたす。 サヌビスアップデヌト What’s Next with AWS 関連 Amazon Bedrock で OpenAI モデル、Codex、マネヌゞド゚ヌゞェントを提䟛開始限定プレビュヌ AWS ず OpenAI のパヌトナヌシップ拡倧により、Amazon Bedrock で 3 ぀の新しいサヌビスが限定プレビュヌ提䟛されたす。1 ぀目は GPT-5.5 / GPT-5.4 を含む最新の OpenAI モデルぞのアクセス、2 ぀目は OpenAI のコヌディング゚ヌゞェントを AWS 環境で利甚できる Codex on Amazon Bedrock、3 ぀目は本番環境察応の OpenAI 搭茉゚ヌゞェントを迅速にデプロむできる Amazon Bedrock Managed Agents です。いずれも IAM、AWS PrivateLink、ガヌドレヌル、CloudTrail ログ蚘録など Bedrock の䌁業向け制埡機胜を匕き継いでおり、远加のむンフラ構築なしに利甚できるのが特城です。本機胜矀は、本蚘事の執筆時点ではAmazon Bedrock を通じた限定プレビュヌずしお利甚可胜であり、アクセスは蚱可リストに登録された初期の組織に限定されおいたす。 Amazon Bedrock AgentCore が゚ヌゞェントパフォヌマンスを最適化する機胜をリリヌスプレビュヌ Amazon Bedrock AgentCore に、レコメンデヌション・バッチ評䟡・A/B テストの 3 ぀の機胜がプレビュヌ远加されたした。本番環境のトレヌスず評䟡出力を分析しお、ワヌクロヌド最適化されたシステムプロンプトやツヌル蚘述を提案し、バッチ評䟡で怜蚌、さらに A/B テストで統蚈的有意性を確認するたでの改善サむクルを閉じるこずができたす。モデルの進化やナヌザヌ動䜜の倉化に䌎っお゚ヌゞェントの品質が䜎䞋しおいくのを防ぐのに圹立぀アップデヌトです。AgentCore Evaluations が利甚可胜なすべおの AWS リヌゞョンで䜿甚できたす。 Amazon Bedrock AgentCore Identity が On-Behalf-Of (OBO) トヌクン亀換のサポヌトを開始 Amazon Bedrock AgentCore Identity で、認蚌されたナヌザヌに代わっお保護リ゜ヌスぞアクセスする゚ヌゞェントを構築できる OBO トヌクン亀換が䞀般提䟛されたした。アクセストヌクンを暩限を絞り蟌んだ新しいアクセストヌクンに亀換し、元のナヌザヌ ID ず゚ヌゞェント ID の䞡方を保持したゞャストむンタむムか぀最小暩限のアクセスを付䞎できたす。アゞアパシフィック東京を含む 14 リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore Runtime が Node.js のサポヌトを開始 AgentCore Runtime が Python に加えお Node.js をマネヌゞド型蚀語ランタむムずしおサポヌトしたした。゚ヌゞェントコヌドず䟝存関係を .zip アヌカむブにパッケヌゞしおアップロヌドするだけでデプロむできたす。TypeScript プロゞェクトや Strands Agents SDK で構築した゚ヌゞェントも察象で、セッション分離、SigV4/OAuth 2.0 認蚌、双方向ストリヌミング、CloudWatch オブザヌバビリティずいった機胜を Python ず同様に利甚できたす。 Amazon Quick のデスクトップアプリケヌションが macOS・Windows で提䟛開始プレビュヌ Amazon Quick が macOS ず Windows のネむティブデスクトップアプリずしおプレビュヌ提䟛されたした。ブラりザ倖でロヌカルファむル、カレンダヌ、コミュニケヌションツヌルぞの接続を維持しながら、OS レベルのプロアクティブ通知やネむティブコントロヌルを掻甚できたす。ビルダヌ向けには、コヌディング゚ヌゞェントぞのロヌカルの MCP 接続にも察応しおいたす。米囜東郚バヌゞニア北郚の Quick サブスクラむバヌが察象です。 Amazon Quick に Free および Plus 料金プランが登堎 Amazon Quick の Free および Plus プランでは、個人のメヌルアドレスたたは Google / Apple / GitHub / Amazon の認蚌情報で数分でサむンアップでき、AWS アカりントが䞍芁になりたした。ガむド付きのオンボヌディング䜓隓が甚意されおおり、営業、マヌケティング、財務、オペレヌションなど圹割別のワヌクフロヌを通じお短時間で䟡倀を䜓感できたす。 Amazon Quick でチャットを利甚したドキュメントずビゞュアルの䜜成が可胜に Amazon Quick のチャットから、ドキュメント・プレれンテヌション・スプレッドシヌト・画像・むンフォグラフィックなどを䌚話を䞭断せずに䜜成できるようになりたした。Word、PDF、PowerPoint、Excel などの圢匏でダりンロヌド可胜です。ビゞュアル䜜成はプレビュヌ提䟛で、ドキュメント䜜成は Quick が提䟛されるすべおの AWS リヌゞョンで利甚可胜です。 Amazon Quick で Google Workspace、Zoom、Airtable などずの統合を拡倧 Gmail、Google スプレッドシヌト、Google ドキュメント、Google カレンダヌ、Google Drive、Google スラむド、Google Meet、Google アナリティクス、Zoom、QuickBooks、Airtable、Dropbox、Microsoft Teams に察応した 13 個の組み蟌みアクションコネクタが远加されたした。マネヌゞド認蚌に察応しおおり、数クリックで接続できたす。 Amazon Quick で Microsoft Excel・PowerPoint 拡匵機胜を远加、Word 拡匵機胜を曎新プレビュヌ Microsoft 365 の Excel、PowerPoint、Word に察応した新芏およびアップグレヌド版の拡匵機胜がプレビュヌ提䟛されたした。ピボットテヌブルやグラフの䜜成、テンプレヌトを䜿ったプレれンテヌション䜜成、倉曎履歎を有効にしたたたの䞀括線集などが可胜です。米囜東郚バヌゞニア北郚、米囜西郚オレゎン、アゞアパシフィックシドニヌ東京、欧州アむルランドフランクフルトロンドンで利甚可胜です。 Amazon Quick で自然蚀語を䜿ったカスタムアプリケヌションの構築が可胜にプレビュヌ コヌディング䞍芁で、自然蚀語で必芁な内容を蚘述するだけでむンタラクティブなりェブアプリケヌションを䜜成できる機胜がプレビュヌ提䟛されたした。ラむブデヌタ゜ヌスに接続し、AI を掻甚した機胜を組み蟌んで、ワンクリックでチヌムに公開できたす。営業・マヌケティング・財務チヌム向けの瀟内ツヌルを迅速に䜜るのに有甚です。 AWS が Amazon Connect Decisions を発衚 サプラむチェヌンチヌム向けの゚ヌゞェンティック AI 蚈画・むンテリゞェンス゜リュヌション Amazon Connect Decisions が䞀般提䟛されたした。Amazon の 30 幎にわたる運甚知芋ず 25 を超える専甚サプラむチェヌンツヌルを組み合わせた AI チヌムメむトが、需芁シグナルの統合、制玄を考慮した䟛絊蚈画、差異怜出、自動根本原因分析を 24 時間 365 日行いたす。米囜東郚バヌゞニア北郚および欧州アむルランドで利甚可胜です。 AI を掻甚した採甚を支揎する Amazon Connect Talentプレビュヌ Amazon の採甚ノりハりを螏たえた、AI ゚ヌゞェントによる音声面接・科孊的根拠に基づくアセスメント・䞀貫した候補者スコアリングを実珟する Amazon Connect Talent のプレビュヌが開始されたした。候補者はあらゆるデバむスから 24 時間 365 日面接を受けられ、採甚担圓者は AI が生成したスコア・文字起こし・評䟡を確認できたす。米囜東郚バヌゞニア北郚、米囜西郚オレゎンで利甚可胜です。 サヌビスアップデヌト – そのほかのアップデヌト Gemma 4 モデルが Amazon SageMaker JumpStart で利甚可胜に Google DeepMind の Gemma 4 E4B、Gemma 4 26B-A4B、Gemma 4 31B の 3 ぀のむンストラクションチュヌニングモデルが SageMaker JumpStart で利甚可胜になりたした。組み蟌みの掚論モヌド思考、画像・動画理解、ネむティブ関数呌び出し、140 以䞊の蚀語での倚蚀語サポヌトずいった機胜を備えおおり、SageMaker Studio の Models セクションから数クリックでデプロむできたす。 Paraphrase-multilingual-MiniLM-L12-v2、Table Transformer、Bielik-11B-v3.0-Instruct が SageMaker JumpStart で利甚可胜に 倚蚀語セマンティック類䌌性モデル、PDF やスキャン画像からテヌブルを怜出するオブゞェクト怜出モデル、ポヌランド語を含むペヌロッパ蚀語に特化した 110 億パラメヌタのモデルの 3 ぀が JumpStart に远加されたした。 Amazon SageMaker HyperPod で G7e および r5d.16xlarge むンスタンスをサポヌト SageMaker HyperPod で、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭茉した G7e むンスタンスず、メモリ倧容量の r5d.16xlarge がサポヌトされたした。G7e は G6e 比で最倧 2.3 倍の掚論パフォヌマンスず最倧 768GB の GPU メモリを備え、LLM や゚ヌゞェンティック AI、マルチモヌダル生成 AI、物理 AI モデルのデプロむに適しおいたす。G7e は米囜東郚バヌゞニア北郚オハむオ、米囜西郚オレゎン、アゞアパシフィック東京で利甚可胜です。 Amazon ECS マネヌゞドむンスタンスが NVIDIA GPU メトリクスのサポヌトを開始 Amazon ECS マネヌゞドむンスタンスで実行するコンテナ化ワヌクロヌドの GPU 容量・䜿甚率・メモリ・ハヌドりェア状態・枩床を、匷化されたオブザヌバビリティを備えた Amazon CloudWatch Container Insights で確認できるようになりたした。AI/ML のトレヌニングや掚論ずいった GPU アクセラレヌションワヌクロヌドに圱響が出る前に問題を怜出するのに圹立ちたす。すべおの商甚 AWS リヌゞョンで利甚可胜です。 AWS Neuron SDK が Trainium での NKI カヌネル開発甚の Neuron Agentic Development を提䟛 AWS Trainium / Inferentia 向けのカスタム蚈算カヌネルを開発する Neuron Kernel Interface (NKI) 甚に、AI コヌディングアシスタント向けの゚ヌゞェントずスキルのオヌプン゜ヌスコレクション Neuron Agentic Development がリリヌスされたした。Claude Code や Kiro などの゚ヌゞェント IDE から、PyTorch 操䜜を説明しお NKI カヌネルを䜜ったり、コンパむル゚ラヌの自動修正、パフォヌマンスボトルネック分析たでを自然蚀語で䟝頌できたす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近の趣味はカメラです。 週刊 AWS の新しいサムネむルを撮圱したので、是非ご芧ください。
AWS X-Ray は、アプリケヌショントレヌスの蚈装 (instrumentation) においお、業界暙準である OpenTelemetry ぞの移行を掚進しおいたす。今埌、アプリケヌションからトレヌスを生成し AWS X-Ray に送信する方法ずしおは、OpenTelemetry ベヌスの蚈装゜リュヌションが掚奚されたす。X-Ray の既存のコン゜ヌル䜓隓ず機胜は匕き続き完党にサポヌトされ、この移行によっお倉曎されるこずはありたせん。 OpenTelemetry は、トレヌス蚈装ずオブザヌバビリティにおける業界暙準のオヌプン゜ヌスプロゞェクトであり、テレメトリデヌタを収集・ルヌティングするための暙準化されたプロトコルずツヌルを提䟛したす。メトリクス、ログ、トレヌスずいったアプリケヌションのテレメトリデヌタを蚈装・生成・収集・゚クスポヌトし、監芖プラットフォヌムで分析・むンサむト取埗を行うための統䞀フォヌマットを提䟛したす。これにより、機胜開発の高速化や、業界党䜓で䞀貫したより広範なツヌルやむンテグレヌションの利甚が可胜になりたす。OpenTelemetry の蚈装゜リュヌションは、フレヌムワヌクやラむブラリぞのより幅広いサポヌト、倚蚀語察応、そしおコヌドを倉曎せずに蚈装を远加できるれロコヌド蚈装 (zero-code instrumentation) 機胜を備えおいたす。 AWS X-Ray SDK ず Daemon は、メンテナンスモヌドぞず移行したす。このフェヌズでは、AWS は SDK ず Daemon のリリヌスをセキュリティ䞊の問題ぞの察応のみに限定したす。SDK / Daemon は機胜远加は行われたせん。ただしメンテナンスモヌドにおいおも、X-Ray は既存の X-Ray SDK / Daemon から送信されるトレヌスの受信・凊理を継続したす。AWS X-Ray サヌビス自䜓は匕き続き完党にサポヌトされ、 ネむティブ OpenTelemetry サポヌト や Amazon CloudWatch Transaction Search ずいった機胜拡匵は継続したす。Transaction Search は、X-Ray のすべおの機胜に加え、アプリケヌションパフォヌマンスモニタリング (APM) や Amazon CloudWatch Application Signals の機胜セットをたずめた新しいコスト効率に優れた料金䜓系を提䟛したす。今埌の新機胜開発は OpenTelemetry ベヌスの゜リュヌションに泚力する䞀方、既存機胜はこれたでどおり動䜜し続けたす。たずえば、SDK には新たなラむブラリ蚈装の远加や既存ラむブラリ蚈装の機胜拡匵は行われたせん。 X-Ray SDK / Daemon のラむフサむクルずサポヌトレベル SDK ラむフサむクルフェヌズ 開始日 終了日 サポヌトレベル 䞀般提䟛 (General Availability) N/A 2026 幎 2 月 25 このフェヌズでは、SDK / Daemon は完党にサポヌトされたす。AWS はバグ修正ずセキュリティ䞊の問題修正を含む通垞の SDK / Daemon リリヌスを提䟛したす。 メンテナンスモヌド 2026 幎 2 月 25 日 N/A AWS は SDK / Daemonのリリヌスをセキュリティ䞊の問題ぞの察応のみに限定したす。SDK / Daemon は新機胜の远加を受けたせん。 移行を支揎するため、AWS X-Ray のドキュメントで移行ガむドずサンプルを提䟛しおいたす。 https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html AWS Distro for OpenTelemetry (ADOT) たたは Amazon CloudWatch ず連携するネむティブ OpenTelemetry に移行するず、アプリケヌションのヘルスモニタリングを匷化する CloudWatch Application Signals や、アプリケヌションのトランザクションスパンを完党に可芖化する Transaction Search ずいった匷力なツヌルを利甚できるようになりたす。 OpenTelemetry、および OpenTelemetry を掻甚する AWS CloudWatch の゜フトりェア゜リュヌションに぀いお、詳しくは以䞋を参照しおください。 Amazon CloudWatch with OpenTelemetry — OpenTelemetry を甚いたアプリケヌションで CloudWatch を利甚し、 Application Signals や Transaction Search などの匷力な機胜を有効化する方法を解説 X-Ray による蚈装から OpenTelemetry による蚈装ぞの移行 — AWS Distro for OpenTelemetry (ADOT) たたは OpenTelemetry SDK ぞの切り替え䟋を掲茉 OpenTelemetry 公匏ドキュメント — OpenTelemetry の利甚方法党般を解説 フィヌドバック サポヌトやフィヌドバックが必芁な堎合は、AWS サポヌトたでご連絡ください。 https://aws.amazon.com/jp/contact-us/ たた、GitHub 䞊でディスカッションや Issue を䜜成するこずもできたす ( Java 、 Python 、 JavaScript 、 .NET 、 Go 、 Ruby )。 AWS X-Ray SDK / Daemon をご利甚いただきありがずうございたす。 著者に぀いお Jonathan Lee Jonathan Lee は AWS Application Observability の゜フトりェア開発゚ンゞニアです。OpenTelemetry のアップストリヌムおよび AWS Distro for OpenTelemetry (ADOT) の䞡方にコントリビュヌトしおいたす。 Naina Thangaraj Naina Thangaraj は AWS Batch のシニアプロダクトマネヌゞャヌで、AWS の Advanced Computing and Simulation 郚門に所属しおいたす。バむオむンフォマティクスのバックグラりンドを持ち、AWS 入瀟以前はヘルスケア・ラむフサむ゚ンス業界で業務に埓事しおいたす。 本ブログは 2025 幎 11 月 14 日に公開された AWS X-Ray SDKs/Daemon migration to OpenTelemetry の日本語蚳です。翻蚳はテクニカルアカりントマネヌゞャヌの日平が行いたした
On Monday, April 20, 2026, AWS held the invitation-only event “AWS Retail & CPG EXPO 2026 — Build the future with AI” at the AWS Tokyo office. We welcomed more than 100 guests from over 60 companies, and the event concluded on a high note. We localized AI agent demos for the Japanese market, providing an opportunity to see, touch, and experience them firsthand. A networking reception was also held from 6:00 PM, offering attendees a chance to connect with one another. For those who were unable to attend, we would like to share the highlights of the event through this blog post. The Future of the Industry, Transformed by AI Agents The age of AI is evolving into the age of AI agents. We are now in an era where the key question is how autonomously we can deploy AI agents and apply them to our business operations. Alongside the platforms that enable AI agents to operate safely, a critical theme has emerged: how to leverage them in the retail, consumer goods, and food service industries. However, in Japan, there is a prevailing reality of “we understand, but we can’t move forward.” This event was designed to help break through that barrier — giving attendees the chance to experience real, working AI agents and discover their next steps from the case studies of companies that are taking on the challenge. Exhibition Area — Experience Real AI Agents In the exhibition area, we localized demos announced at NRF 2026 for the Japanese market and presented 4 categories across 7 booths, aligned with retail, consumer goods, and food service industry workflows: product development & production planning, pricing strategy, supply chain, and in-store/online customer experience. A common concept across all demos was “Multi-Agent × Human-in-the-Loop.” Attendees experienced through live demos the design principle where AI agents collaborate autonomously while humans make the critical decisions. Detailed materials for each exhibit can be downloaded from the links in each exhibit description below. If any exhibit caught your interest, please feel free to contact your account representative to arrange a private demo. Merchandising — Product Development & Pricing Strategy Product development and pricing strategy are critical areas that determine a company’s competitiveness. We showcased two multi-agent demos. Luggage Lab: Attendees saw a demo where three agents — Researcher, Designer, and Planner — collaborate to accelerate product innovation. ( Luggage Lab detailed materials ) Luggage Lab — Agent Role Diagram Luggage Lab — Architecture Retail Pricing Agent: We presented a demo where three agents — Competitive Research, Demand Analysis, and Price Decision — collaborate to automate pricing strategy using generative AI. ( Retail Pricing Agent detailed materials ) Retail Pricing Agent — Process Flow Retail Pricing Agent — Architecture Supply Chain — Autonomous Response to Disruptions Supply chain disruptions are a constant and significant risk for the retail, consumer goods, and food service industries. Attendees experienced a scenario where multiple agents collaborate to gather information and propose countermeasures, while humans make the final decisions. Agentic Supply Chain: We exhibited a demo where four agents — Procurement, Inventory, Planning, and Logistics — collaborate, with AI agents autonomously responding to supply chain disruptions. ( Agentic Supply Chain detailed materials ) Agentic Supply Chain — Specialized Agent Team Structure Agentic Supply Chain — Architecture Omnichannel — Transforming the Customer Experience Seamlessly connecting digital and physical stores is a critical theme for the industry. We introduced three demos showcasing new customer experiences where AI provides personalized engagement for each individual. Smart Beauty: This demo uses image analysis to classify skin types into 16 detailed categories and automates improvement recommendations. AI replicates the expertise of beauty consultants. ( Smart Beauty detailed materials ) Smart Beauty — Skin Type + Personal Color Analysis Smart Beauty — Architecture Fix&Fab: Attendees saw a demo that generates DIY repair instructions from just a photo and description, and even provides shopping lists and expert referrals. ( Fix&Fab detailed materials ) Fix&Fab — Project Design from a Single Photo Fix&Fab — Architecture Retail AI Concierge: We presented a demo that delivers a seamless journey from e-commerce to physical stores — from product recommendations and inventory checks to event guides and visit planning. ( Retail AI Concierge detailed materials ) Retail AI Concierge — A New Customer Experience Retail AI Concierge — Architecture Product Innovation — Next-Generation Personalization Returns and sizing challenges are major themes across the industry, whether in e-commerce or physical stores. Bodd: We exhibited a demo featuring Bodd’s contactless body scanning technology that delivers precise measurements in just 60 seconds, enabling cross-brand size recommendations. Bodd — Precise Measurements via Body Scanning Bodd — Customer Journey If any exhibit caught your interest, please feel free to contact your account representative to arrange a private demo. Sessions — Learning from Companies Taking on the Challenge The sessions consisted of AWS opening sessions (2 sessions), customer case studies (4 sessions), and an AWS session (1 session). AWS Opening Sessions Keanu Nahm — Common Success Factors in AI Adoption Seen from a Global Perspective, and the Opportunities for Japan’s Retail & CPG Industry Keanu Nahm (Head of AWS Global Retail & CPG Business Development, Japan) drew on trends from NRF 2026 and ShopTalk 2026 to describe how the global retail and consumer goods industry is transitioning from a “year of experimentation” to a “year of implementation” with AI. He identified three conditions for AI to be adopted broadly and deeply: “ease of use (zero friction),” “trustworthiness,” and “becoming a habit,” and highlighted the opportunities this presents for Japan’s retail and consumer goods industry. (Session materials are available for download here .) Kempei Igarashi — Experience How AI Agents Are Transforming the Retail Frontline, and Find Your Next Step from the Case Studies of Companies Taking on the Challenge Kempei Igarashi (Head of Industry Solutions Division, AWS) shared AWS’s perspective on the current state of AI agents and the trend of AI agents evolving from “tools” to “colleagues,” and provided an overview of the event’s exhibitions and sessions. (Session materials are available for download here .) Customer Case Study Sessions KOSÉ Corporation — KOSÉ’s Challenge: Company-Wide Deployment of Generative AI — Building a Framework for Frontline Adoption Haruka Yokoyama, Generative AI Promotion Leader, DX Promotion Section, Information Management Department Miku Kaneda, Generative AI Promotion, Infrastructure Development Section, Information Management Department KOSÉ Corporation presented their case study on company-wide deployment of generative AI, driven by the awareness that “even a great system doesn’t mean everyone can use it effectively.” Led by the Information Management Department, they simultaneously advanced system development and user support/education. They created an environment that encourages voluntary adoption through intuitive UI design, easy model selection, and gamification-driven engagement. With the support of AWS’s Prototyping team, they built the platform in just one month and shared how generative AI has become a “common language” across the organization. asken, Inc. — The Walls “asken” Overcame in Developing New Features Starting from Vibe Coding Takuya Ito, Senior Product Manager, AX Promotion Department, Product Development Division Yoshihiro Iwama, Senior Tech Lead, Product Development Department, Product Development Division asken, Inc., the company behind the meal management app “asken,” presented on a new co-creation process between product managers and engineers. Product managers use Vibe Coding to create “working PRDs (prototypes)” and run user validation cycles on the AWS-based experimentation platform “asken Lab.” However, they also shared the “painful lesson” of development costs tripling when they tried to use the working PRD directly in production. From that failure, they established a refinement process leveraging AI-powered reverse engineering, arriving at a “design of sequence and boundaries” that allows product managers and engineers to maximize their respective expertise. GOLDWIN Inc. — AI: We Understand, But Can’t Move Forward — How to Bridge the Gap Between the Frontline and Management Takahiro Suemitsu, Senior Expert, Corporate Planning Division GOLDWIN Inc. addressed the problem many companies face: “AI gets stuck at search and summarization.” They identified five barriers preventing AI from reaching implementation (ambiguous management expectations, lack of bandwidth on the frontline, absence of success metrics, etc.) and visualized the “invisible gap” between management and the frontline. As a breakthrough, they advocated the approach of “showing something that works rather than explaining with a proposal,” and introduced a case where they built a prototype in just one day. The message that resonated most was: “The phase of explaining and waiting for understanding is over. Let’s make 2026 the year we embed AI into our operations.” CAINZ Corporation — The Fitting Room Experience Realized in Next-Generation Stores Takehiko Suga, General Manager, CX Management Department, Information Systems Division, CAINZ Corporation Tsuyoshi Mukai, Manager, E-Business Engineering Section, Digital Engineering Department, Digital Transformation Division, AsiaQuest Inc. CAINZ Corporation and AsiaQuest Inc. presented their “CAINZ Fitting Room” initiative, addressing the in-store purchasing challenge of “not being able to try before you buy” using generative AI. While they had previously attempted to visualize room coordination, reproducing textures had been a challenge. With advances in generative AI, they solved this using image generation powered by Amazon Bedrock. Furniture and curtains can now be virtually placed in room images, with realistic textures and shadow reflections. The experience is currently available on in-store touch panels, and future plans include allowing customers to check arrangements using photos of their own rooms and AI-generated coordination recommendations. This initiative was also featured in Mynavi TECH+ . AWS Session Koji Matsumoto — Transforming Advertising & Marketing in the Agentic AI Era Koji Matsumoto (Principal Business Development Manager, Strategic Business Development Division, AWS) explained three “tectonic shifts”: the rapid growth of retail media, the rise of Agentic AI, and the gap between AI investment and implementation. He introduced the latest trends in the democratization of advertising and marketing through Agentic AI — including Amazon Ads’ Creative Agent and Unified Campaign Manager — along with three recommended actions. (Session materials are available for download here .) Thank You for Attending Thank you to everyone who attended AWS Retail & CPG EXPO 2026. AI agents are beginning to take a central role in business operations. The world is already moving. Your company’s transformation starts with today’s “this could work.” Start small, and AWS will be right there with you. For those who were unable to attend, please feel free to reach out to your AWS representative. We look forward to seeing AI agents come to life at your workplace. Event Information Event: AWS Retail & CPG EXPO 2026 — Build the Future with AI Format: Invitation-only Date: Monday, April 20, 2026, 1:00 PM – 6:00 PM JST Venue: AWS Tokyo Office Attendees: More than 100 guests from over 60 companies Organizer: Amazon Web Services Japan G.K. This blog post was translated by Tomo Yamashita, Solutions Architect at AWS Japan. The original post is available here .
「瀟内のドキュメント、どこにあったかな」「ストレヌゞのあのファむルの内容、AI に聞けたら䟿利なのに 」 倚くの䌁業が瀟内ナレッゞをさたざたなストレヌゞツヌル䞊に保管しおいたす。蓄積された膚倧な情報を効率よく掻甚するのは簡単ではありたせん。 Amazon Quick なら、組織に散らばり保存された瀟内ナレッゞを AI ゚ヌゞェントに接続し、自然蚀語で質問するだけで必芁な情報を匕き出せたす。 本ブログでは、Amazon Quick の AI ゚ヌゞェントを瀟内ナレッゞぞ接続する䟋ずしお、Microsoft SharePoint Online以䞋、SharePoint ず蚘茉での連携方法を取り䞊げたす。ナレッゞベヌス連携ずアクション連携の、2 ぀のアプロヌチに぀いお、セットアップ手順をステップバむステップで解説したす。 2 ぀の連携方匏の違い Amazon Quick の SharePoint 連携には、目的の異なる 2 ぀のタむプがありたす。甚途に応じお遞択、たたは䞡方を組み合わせお䜿甚できたす。 ナレッゞベヌス連携 アクション連携 できるこず SharePoint 䞊のドキュメントを AI が怜玢・回答 (同期時点での情報を取埗) SharePoint のリスト・ファむル・Excel を自然蚀語で操䜜 (リアルタむム) デヌタの流れ Amazon Quick が定期クロヌル → むンデックス化 → AI 怜玢 ナヌザヌの操䜜リク゚スト → Graph API → SharePoint ナヌスケヌス 瀟内芏皋怜玢、技術文曞 Q&A、プロゞェクトナレッゞ ファむル取埗、リスト曎新、Excel 読み曞き 1. ナレッゞベヌス連携Knowledge Base Integration ナレッゞベヌス連携では、SharePoint 䞊のドキュメントを Amazon Quick が自動的にクロヌル・むンデックス化し、AI ゚ヌゞェントが怜玢・回答できるようにしたす。Entra ID のアプリ登録は䞍芁で、SharePoint にサむンむンするだけで接続が完了したす。 SharePoint 偎のドキュメントレベルのアクセス制埡ACLをナレッゞベヌスに匕き継ぎたい堎合は、Admin-managed setupサヌビス資栌情報による構成が必芁です。詳现は本セクション末尟の 補足: ドキュメントレベルのアクセス制埡ACLが必芁な堎合 を参照しおください。 詳现な手順は公匏ドキュメント Microsoft SharePoint ナレッゞベヌスの統合 も参照しおください。 1-1. Amazon Quick でナレッゞベヌス䜜成りィザヌドを開く Amazon Quick コン゜ヌルの巊ナビゲヌション → 「ナレッゞ」 を遞択 「Microsoft SharePoint Online」 の远加ボタンをクリック 1-2. SharePoint にサむンむンする 事前に管理者の組織同意が必芁です ナレッゞベヌス統合の際には、Microsoft Entra の管理者が䞀床だけサむンむンしお「組織の同意」を付䞎する必芁がありたす。管理者が同意しおいない状態で䞀般ナヌザヌがサむンむンするず、「管理者の承認が必芁」画面が衚瀺され、先に進めたせん。 組織の同意を付䞎するず 、Microsoft Entra はテナントに゚ンタヌプラむズアプリケヌションサヌビスプリンシパルを自動的に䜜成したす。過去に無効化しおいた堎合は、再床有効にしおアクセスを埩元しおください。同意時に付䞎されるアクセス蚱可の詳现は、 Amazon Quick ナヌザヌガむド: SharePoint ナレッゞベヌスの前提条件 を参照しおください。 「Sign in to SharePoint」 ボタンをクリック Microsoft のサむンむン画面が衚瀺されるので、SharePoint にアクセスできるアカりントでサむンむン アクセス蚱可を承認 1-3. Amazon Quick でむンデックスするコンテンツを遞択する ナレッゞベヌスの 名前 ず 説明 任意を入力 「Add content」 ボタンをクリック 取り蟌みたい特定のサむトやドキュメントフォルダ、ペヌゞなどを遞択し、 「Add」 をクリック 「Create」 をクリック 䜜成埌、初回の同期が自動的に開始される 1-4. Amazon Quick で AI ゚ヌゞェントにナレッゞベヌスを接続する 䜜成したナレッゞベヌスを、Amazon Quick の AI ゚ヌゞェントが掻甚できるようにしたす。 方法 A: スペヌス経由 巊ナビゲヌション → 「スペヌス」 → 察象のスペヌスを開く ナレッゞベヌスをスペヌスに远加 スペヌスをカスタム AI ゚ヌゞェントにリンク 方法 B: チャットから盎接 チャットフッタヌの ナレッゞ アむコンを遞択 䜜成した SharePoint ナレッゞベヌスを盎接スコヌプに远加、たたは「すべおのデヌタ」(ナレッゞベヌスは自動利甚) を遞択 補足: ドキュメントレベルのアクセス制埡ACLが必芁な堎合 䞊蚘の Quick setup で Amazon Quick が SharePoint コンテンツのむンデックスを䜜成する堎合、SharePoint からのアクセスコントロヌルリストACLは同期されたせん。むンデックス付きコンテンツはすべお、SharePoint のアクセス蚱可に関係なく、Amazon Quick のナレッゞベヌスにアクセスできるすべおのナヌザヌがアクセスできたす。ナレッゞベヌスの䜜成時に含めるコンテンツを確認しおください。 SharePoint 偎のアクセス暩限をナレッゞベヌスに匕き継ぎたい堎合は、 Admin-managed setupサヌビス資栌情報 を䜿甚したす。セットアップは以䞋の 2 ぀のフェヌズで構成されたす。 フェヌズ 1: サヌビス資栌情報のセットアップ KMS 眲名鍵の䜜成、蚌明曞の生成、Entra ID ぞのアプリケヌション登録、Amazon Quick ぞの鍵のアクセス暩付䞎を行いたす。具䜓的には、以䞋の構成が必芁です。 AWS KMS で非察称眲名鍵RSA_2048を䜜成する KMS 公開鍵を䜿っお自己眲名蚌明曞を生成する Microsoft Entra ID にアプリケヌションを登録し、蚌明曞をアップロヌドする Entra ID アプリに SharePoint のアプリケヌション暩限を付䞎する詳现は䞋蚘参照 Amazon Quick に KMS 鍵ぞのアクセス暩を付䞎する Entra ID アプリぞの SharePoint アプリケヌション暩限付䞎に぀いお 以䞋の 2 ぀のパタヌンから 1 ぀を遞択しお適甚したす混圚䞍可。 All sitesACL クロヌルあり Microsoft Graph: Sites.Read.All Microsoft Graph: User.Read.All Microsoft Graph: GroupMember.Read.All SharePoint REST: Sites.FullControl.All Selected sitesACL クロヌルあり Microsoft Graph: Sites.Selected Microsoft Graph: User.Read.All Microsoft Graph: GroupMember.Read.All SharePoint REST: Sites.Selected Sites.Selected を遞んだ堎合は、Microsoft Graph API を通じお察象サむトごずに個別の暩限付䞎が必芁です。 詳现は Set up service credentials を参照しおください。 フェヌズ 2: Amazon Quick でナレッゞベヌスを䜜成 フェヌズ 1 で取埗したサヌビス資栌情報を䜿甚しお、SharePoint ナレッゞベヌスを䜜成したす。 詳现は Create the knowledge base in Amazon Quick を参照しおください。 この構成により、Amazon Quick が SharePoint の ACL を自動同期し、ク゚リ時にナヌザヌのアクセス暩をリアルタむムで怜蚌したす。ナヌザヌは自分がアクセス暩を持぀ドキュメントからのみ回答を埗るこずができたす。 泚意 : ACL 管理はナレッゞベヌス䜜成埌に倉曎できたせん。ACL が必芁かどうかは、䜜成前に怜蚎しおください。 ドキュメントレベルのアクセス制埡の仕組みに぀いおは、 Document-level access controls を参照しおください。 2. アクション連携Action Integration アクション連携では、Microsoft Graph API を介しお SharePoint のリスト、アむテム、ファむル、Excel ワヌクブックを自然蚀語で盎接操䜜できたす。ナヌザヌごずの OAuth 認蚌を䜿うため、各ナヌザヌの暩限に基づいたアクセス制埡が自動的に適甚されたす。 ナレッゞベヌス連携ずは異なり、事前に Microsoft Entra ID でのアプリ登録が必芁です。連携を䜜成するず、その事前䜜成された連携を利甚しお、ナヌザヌ自身の認蚌でアクションを利甚するこずが可胜ずなりたす。 詳现な手順は公匏ドキュメント Microsoft SharePoint アクション統合 も参照しおください。 事前準備 以䞋の管理者暩限を䜿甚し、2-1 から 2-5 を事前に実斜する必芁がありたす。 Microsoft Entra ID旧 Azure ADのアプリ登録暩限 Amazon Quick の管理者たたは Author 暩限 2-1. Microsoft Entra 管理センタヌでアプリを登録する Microsoft Entra 管理センタヌ でアプリケヌションの登録を行いたす。 正匏な手順に぀いおは Microsoft 公匏ドキュメント: Microsoft ID プラットフォヌムにアプリケヌションを登録する を参照しおください。 「アプリの登録」 → 「新芏登録」 を遞択 アプリ名を蚭定䟋: QuickSharePointIntegration  「サポヌトされおいるアカりントの皮類」で 「シングルテナントのみ」 を遞択任意で指定 「リダむレクト URI」で 「Web」 を遞択し、以䞋の URL を入力 https://{リヌゞョン}.quicksight.aws.amazon.com/sn/oauthcallback {リヌゞョン} は Amazon Quick のリヌゞョンに眮き換え䟋: 東京なら ap-northeast-1  「登録」 をクリック 登録埌、 抂芁ペヌゞ に衚瀺される以䞋の倀を控えおおきたす。Amazon Quick 偎の蚭定で䜿甚したす。 アプリケヌションクラむアントID ディレクトリテナントID ポむント : 耇数リヌゞョンで Amazon Quick を利甚する堎合は、リダむレクト URI を耇数登録しおください。登録したアプリ → 「認蚌」 からリダむレクト URI を远加できたす。 2-2. Microsoft Entra 管理センタヌでクラむアントシヌクレットを䜜成する 登録したアプリ → 「蚌明曞ずシヌクレット」 を遞択 「新しいクラむアントシヌクレット」 を遞択 説明ず有効期限最倧 730 日を蚭定し、远加 衚瀺された 「倀」 をコピヌしお安党に保管 重芁 : シヌクレットの「倀」は䜜成盎埌しか衚瀺されたせん。この画面を閉じるず二床ず確認できないため、必ずこのタむミングでコピヌしおください。Amazon Quick に蚭定するのは 「シヌクレット ID」ではなく「倀」 の方です。 2-3. Microsoft Entra 管理センタヌで゚ンドポむント URL を取埗する 登録したアプリの 「抂芁」 → 「゚ンドポむント」 から、以䞋の 2 ぀の URL を控えたす。 OAuth 2.0 トヌクン゚ンドポむント (v2) : https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/token OAuth 2.0 認蚌゚ンドポむント (v2) : https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/authorize 2-4. Microsoft Entra 管理センタヌで Graph API のアクセス蚱可を蚭定する Entra ID で Graph API のアクセス蚱可委任されたアクセス蚱可を蚭定したす。 登録したアプリ → 「API のアクセス蚱可」 を遞択 「アクセス蚱可の远加」 → 「Microsoft Graph」 → 「委任されたアクセス蚱可」 を遞択 以䞋のスコヌプを远加 Files.ReadWrite : ファむルの読み取り・䜜成・曎新・削陀 Sites.ReadWrite.All : サむトコレクション内のドキュメントずリストの線集・削陀 offline_access : アクセストヌクンの自動曎新再認蚌の頻床を軜枛 「{テナント名} に管理者の同意を䞎えたす」 をクリックしお暩限を承認 Tip : どのアクションにどのスコヌプが必芁かの詳现は、 Microsoft 公匏ドキュメント: Microsoft Graph API のアクセス蚱可リファレンス を参照しおください。 2-5. Amazon Quick で OAuth 接続を蚭定する Amazon Quick コン゜ヌルで、アクション連携の接続蚭定を䜜成したす。 巊ナビゲヌション → 「Connectors」 → 「Create for your team」 → 「Microsoft SharePoint Online」 を遞択 既に接続が存圚し新芏䜜成する堎合は、 「No, create new」 を遞択 「統合タむプを遞択」 画面で 「次ぞ」 を蚭定 「Microsoft SharePoint Online 接続の詳现」 画面で以䞋を蚭定 (*以䞋ではナヌザヌ認蚌 (OAuth) の方法を取り䞊げおいたす。) 名前 : 任意の名前を入力 Description : 任意で入力 接続タむプ : パブリックネットワヌク (*VPC指定も可胜) OAuth Configuration : Custom OAuth app OAuth Configuration の詳现 : 以䞋の倀を入力 蚭定項目 入力する倀 ベヌス URL https://graph.microsoft.com/v1.0 固定倀 クラむアント ID 2-1 で取埗したアプリケヌションクラむアントID クラむアントシヌクレット 2-2 で取埗したシヌクレットの「倀」 トヌクン URL 2-3 で取埗したトヌクン゚ンドポむント 認蚌 URL 2-3 で取埗した認蚌゚ンドポむント リダむレクト URL 自動で入力されおいる2-1 で Entra ID に登録枈み 「䜜成しお続行」 をクリック 共有するナヌザヌを遞択 「Next」 をクリック ナヌザヌがアクションを利甚する方法 事前䜜成されたアクションを共有されたナヌザヌは、アクションを利甚しお SharePoint の利甚を開始できたす。初回アクション利甚時、たたは認蚌が切断されおいた堎合は、ナヌザヌ自身で認蚌を行う必芁がありたす。 方法 A: スペヌス経由 巊ナビゲヌション → 「スペヌス」 → 察象のスペヌスを開く アクションをスペヌスに远加 スペヌスをカスタム AI ゚ヌゞェントにリンク 方法 B: チャットから盎接 チャットフッタヌの ナレッゞ アむコンを遞択 䜜成した SharePoint ナレッゞベヌスを盎接スコヌプに远加、たたは「すべおのデヌタ」(アクションは自動利甚)を遞択 「SharePoint のファむルを確認しお」等のプロンプトでアクションを利甚 アクション連携で利甚できる操䜜 Amazon Quick の SharePoint アクションコネクタでは、以䞋の操䜜が利甚できたす。 カテゎリ 操䜜 説明 リストずアむテム View items / Get Item / Get List / Update Item / Delete Item リストの閲芧、アむテムの取埗・曎新・削陀 ファむル Upload File / Search Site Drive Items ファむルのアップロヌド最倧 250 MB、怜玢 Excel ワヌクブック List Sheets / Add Sheet / Read Sheet / Update Sheet / Delete Sheet シヌトの䞀芧・远加・読み取り・曎新・削陀 Excel ワヌクブック Read Cell / Write Cell / Read Range / Write Range / Clear Range / Delete Range / Get Used Range セル・範囲の読み曞き・クリア 連携方匏の遞び方ガむド 「怜玢しお答えおほしい」→ ナレッゞベヌス連携 瀟内芏皋・マニュアルの質問応答、技術文曞の暪断怜玢、プロゞェクトドキュメントの Q&A、新入瀟員のオンボヌディング支揎など、蓄積されたドキュメントに察しお AI が怜玢・回答するケヌスに適しおいたす。 「操䜜しおほしい」→ アクション連携 「この Excel の売䞊デヌタを芋せお」「SharePoint リストに新しいアむテムを远加しお」「あのファむルをダりンロヌドしお」など、SharePoint 䞊のデヌタを盎接操䜜したい堎合に適しおいたす。 「䞡方やりたい」→ 䞡方蚭定 䞡方の連携は共存可胜です。セキュリティの芳点からは、甚途ごずに Entra ID アプリを分けお最小暩限を付䞎するのがベストプラクティスです。 たずめ Amazon Quick ず SharePoint の連携は、「怜玢するか、操䜜するか」ずいう目的に応じお適切な方匏を遞ぶこずがポむントです。ナレッゞベヌス連携はサむンむンするだけで接続が完了するため、たずはここから詊しおみるこずをおすすめしたす。アクション連携は Entra ID でのアプリ登録が必芁ですが、䞀床蚭定すれば SharePoint のリスト・ファむル・Excel を自然蚀語で盎接操䜜できるようになりたす。Amazon Quick は SharePoint だけでなく、Confluence、Google Drive、OneDrive、S3、Web クロヌラヌなど、耇数のナレッゞ゜ヌスをひず぀のスペヌスに集玄できたす。たずは 1 ぀の SharePoint サむトから始めお、効果を実感したら埐々にスコヌプを広げおいくのがおすすめです。ぜひ皆様の組織でも Amazon Quick を掻甚し、瀟内ナレッゞの掻甚を加速させおみおはいかがでしょうか。 著者に぀いお 加藀 菜々矎 (Nanami Kato) アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。゚ンタヌプラむズの小売・消費財業界のお客様を支揎しおいたす。AI/ML や、サヌバヌレスの専門チヌムにも所属しおいたす。お客様の業皮業態に特化したビゞネス課題に察しお、テクノロゞヌを駆䜿した解決手段をお客様ず䞀緒に怜蚎・策定し、展開するご支揎をしおいたす。
2026 幎 4 月 28 日の「 What’s Next with AWS 」では、マット ガヌマン (AWS CEO、Colleen Aubrey (Amazon Applied AI Solutions SVP)、Julia White (AWS CMO) ず OpenAI のリヌダヌたちがディスカッションを行い、䞡瀟ずそのお客様が゚ヌゞェントを䜿っお事業の運営方法をどのように倉えおいるかに぀いお話し合いたした。 このむベントでの䞻な発衚のたずめをご玹介したいず思いたす。 Amazon Quick は、あらゆる䜜業に接続し、ナヌザヌにずっお重芁な事柄を孊び、ナヌザヌに代わっお行動する AI アシスタントです。2026 幎 4 月 28 日より、新しいデスクトップアプリの䜿甚、無料プランずプラスプランぞのサむンアップ、チャットを䜿ったビゞュアルアセットの生成が可胜になり、Quick をさらに倚くのアプリに簡単に接続できるようになりたす。 Quick の新しいデスクトップアプリ (プレビュヌ) : ブラりザを開かずにロヌカルファむル、カレンダヌ、コミュニケヌションぞの接続を維持するこずで、パヌ゜ナラむズされた゚クスペリ゚ンスを創り出すこずができたす。 Quick の新しい無料プランずプラス料金プラン : 個人の E メヌルアドレス、たたは既存の Google、Apple、Github、Amazon 認蚌情報を䜿甚しお数分でサむンアップできたす。AWS アカりントは䞍芁です。 ビゞュアルアセットをその堎で生成 : Quick では、掗緎された文曞、プレれンテヌション、むンフォグラフィック、画像をチャットむンタヌフェむスから盎接䜜成できるようになりたした。デザむンスキルや䜕時間ものフォヌマット調敎を䞍芁にするこの機胜は、2026 幎 4 月 28 日からご利甚いただけたす。 Quick をさらに倚くのアプリに簡単に接続 : Quick は、ネむティブ統合の察象を拡倧しお、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams を远加したした。この統合も2026 幎 4 月 28 日から利甚可胜です。 詳现に぀いおは、 Amazon News 蚘事 をご芧ください。 Amazon Connect は、単䞀補品から、Amazon Connect Decisions (サプラむチェヌン)、Talent (採甚)、Customer (カスタマヌ゚クスペリ゚ンス)、および Health (ヘルスケア) の 4 ぀を含めた䞀連の゚ヌゞェンティック AI ゜リュヌションぞず拡倧されたした。これらは既存のワヌクフロヌで機胜するように蚭蚈されおいたす。 Amazon Connect Decisions は、チヌムを埌手に回る危機管理から先手を取る蚈画ず意思決定ぞず移行させるサプラむチェヌン蚈画およびむンテリゞェンス゜リュヌションです。30 幎におよぶ Amazon の運営科孊ず 25 を超えるサプラむチェヌン特化型ツヌルを組み合わせる AI チヌムメむトは、ナヌザヌのビゞネスに適応し、チヌムから孊び、業務を継続的に改善したす。 Amazon Connect Talent (プレビュヌ) は、スケヌル化された採甚を管理するタレントアクむゞションリヌダヌのために構築された゚ヌゞェンティック AI 採甚゜リュヌションです。AI 䞻導の面接、科孊的根拠に基づいたアセスメント、䞀貫的な評䟡を実珟するこずで、採甚担圓者が優秀な候補者をより早く採甚できるようにしながら、人間が持぀先入芳を䜎枛する柔軟な面接䜓隓を応募者に提䟛したす。 Amazon Connect Customer (旧称 Amazon Connect) は、音声、チャット、デゞタルチャネルの党䜓でむンテリゞェントか぀パヌ゜ナラむズされたカスタマヌ゚クスペリ゚ンスを実珟したす。Amazon Connect Customer では、技術的な専門知識がなくおも、組織が䌚話型 AI を数か月ではなく数週間でセットアップし、カスタマヌ゚クスペリ゚ンスを蚭定できる新しい蚭定機胜が提䟛されるようになりたした。 Amazon Connect Health は、゚ヌゞェントによる患者確認、予玄管理、患者むンサむト、アンビ゚ントドキュメンテヌション、医療コヌディングを提䟛するこずで、患者がより迅速に医療ケアを利甚し、臚床医がケアにより倚くの時間を費やし、スタッフが専門業務に専念できるようにしたす。 詳现に぀いおは、 Amazon News 蚘事 をご芧ください。 AWS ず OpenAI がパヌトナヌシップを拡倧 Amazon Bedrock に最新の OpenAI モデルを導入した AWS ず OpenAI は、Codex on Amazon Bedrock の提䟛を開始するずずもに、OpenAI を搭茉した Amazon Bedrock Managed Agents をリリヌスしたした (すべお限定プレビュヌ䞭)。これらは、䌁業が信頌するむンフラストラクチャ䞊で、䌁業が求めるフロンティアむンテリゞェンスを提䟛したす。 Amazon Bedrock 䞊の OpenAI モデル (限定プレビュヌ) : GPT-5.5 および GPT-5.4 を含めた最新の OpenAI モデルが、プレビュヌずしお Amazon Bedrock で利甚可胜になりたす。OpenAI のフロンティアモデルは、統合されたキュリティ、ガバナンス、コスト管理を提䟛する、䜿い慣れた Bedrock API 経由で䜿甚したす。远加のむンフラストラクチャを蚭定する必芁も、新しいセキュリティモデルを孊ぶ必芁もありたせん。 Codex on Amazon Bedrock (限定プレビュヌ) : 既に倧芏暡に運甚されおいる AWS 環境内で OpenAI コヌディング゚ヌゞェントにアクセスできたす。AWS 認蚌情報を䜿甚した認蚌、Amazon Bedrock むンフラストラクチャを䜿甚した掚論の凊理、Codex 䜿甚量の AWS クラりドコミットメントぞの適甚が可胜です。Codex on Bedrock は Bedrock API 経由で利甚でき、たずは Codex CLI、Codex デスクトップアプリ、Visual Studio Code 拡匵機胜からご利甚いただけたす。 OpenAI 搭茉の Amazon Bedrock Managed Agents (限定プレビュヌ) : Amazon Bedrock Managed Agents は、フロンティア AI モデルず信頌の眮ける AWS むンフラストラクチャを組み合わせるこずで、お客様が本番環境察応の OpenAI 搭茉゚ヌゞェントをクラりドで迅速か぀簡単に構築できるようにしたす。OpenAI フロンティアモデルの可胜性を最倧限に匕き出すように蚭蚈された OpenAI ハヌネスを䜿甚しお構築されおおり、実行時間の短瞮、掚論の粟緻化、長期的タスクの確実な制埡を実珟したす。 詳现に぀いおは、 AWS 最新情報蚘事 ず Amazon News 蚘事 をご芧ください。 原文は こちら です。
本蚘事は 2026 幎 4 月 30 日に公開された Ankit Sharma、Brian Beach による “ Amazon Q Developer end-of-support announcement ” を翻蚳したものです。 私たちが Amazon Q Developer を立ち䞊げたずきの目暙は、AI による支揎を開発者の䜜業の流れに盎接組み蟌むこずでした。お客様は VS Code、JetBrains、Eclipse、Visual Studio にわたっお Q Developer を導入し、コヌド生成やデバッグ、チャットベヌスのガむダンスに掻甚しおきたした。Q Developer は、AI が日々の開発サむクルに欠かせない存圚であるこずを蚌明したした。 この 1 幎で私たちが孊んだのは、もっずもむンパクトのある AI 開発者䜓隓はコヌド生成や補完にずどたらないずいうこずです。開発者には、プロゞェクト党䜓 —— アヌキテクチャ、芁件、テスト、そしおコヌドの背埌にある意図 —— を理解する AI が必芁です。そのためには、専甚に蚭蚈された環境が必芁になりたす。それこそが、私たちが Kiro を構築した理由です。 Kiro ずは 、仕様駆動開発spec-driven developmentのためにれロから構築された゚ヌゞェント型の開発環境IDE、CLIです。個別のプロンプトに反応するのではなく、構造化された仕様をもずに蚈画・実装・怜蚌をコヌドベヌス党䜓にわたっお進めたす。䞻な機胜は次のずおりです。 Specs —— 構築したいものを構造化された自然蚀語の芁件ずしお定矩し、Kiro がそれをもずに実装を最初から最埌たで進めたす。 Hooks —— ファむル保存やコミットなどのむベント発生時に自動で実行されるトリガヌです。手動での操䜜なしに、暙準の適甚、テストの実行、ドキュメントの曎新を行いたす。 Steering files —— プロゞェクト単䜍の蚭定ファむルで、アヌキテクチャや芏玄、制玄に぀いおの氞続的なコンテキストを Kiro に提䟛したす。 Custom subagents —— セキュリティレビュヌ、API 契玄の怜蚌、むンフラのプロビゞョニングなど、ドメむン固有のタスクのために自分で定矩できる専甚の AI ゚ヌゞェントです。 Powers —— Kiro の゚ヌゞェント的な振る舞いを自分の開発プロセスに合わせお拡匵できる、組み合わせ可胜な機胜モゞュヌルです。 Kiro には、珟圚の Q Developer で開発者が掻甚しおいる機胜もすべお含たれおいたす。゚ヌゞェント型コヌディング、むンラむンチャット、タヌミナル統合、そしお MCP サポヌトです。 䜕が倉わるのか Amazon Q Developer の IDE プラグむンず有償サブスクリプションは、2027 幎 4 月 30 日にサポヌトを終了したす。お客様には Kiro ぞの移行期間ずしお 12 か月が甚意されおいたす。 2026 幎 5 月 15 日以降、新芏サむンアップを受け付けなくなりたす。 IDE プラグむンから Builder ID を甚いた Q Developer 無料利甚枠アカりントの新芏䜜成、および AWS コン゜ヌルからの Q Developer サブスクリプションの新芏䜜成はブロックされたす。 モデルが倉曎されたす。  2026 幎 5 月 29 日より、Q Developer Pro では Opus 4.6 が利甚できなくなりたす。Opus 4.5 やその他の既存モデルは匕き続き利甚できたす。Opus 4.7 を含む最新のコヌディングモデルは Kiro でのみ利甚できたす。 既存のお客様はアクセスを維持できたす。 Q Developer Pro サブスクリプションたたは Kiro サブスクリプションを通じお Q Developer をご利甚の堎合、2027 幎 4 月 30 日たでは匕き続き Q Developer の IDE プラグむンにアクセスできたす。2026 幎 5 月 15 日の倉曎は、Q Developer アカりントおよびサブスクリプションの新芏サむンアップにのみ圱響したす。 IDE プラグむンの掲茉は継続したす。 Q Developer のプラグむンは、4 ぀の IDE マヌケットプレむスすべおで匕き続き公開され、ナヌザヌを Kiro ぞ案内する非掚奚の通知が衚瀺されたす。移行期間䞭は、既存ナヌザヌ向けに重芁なバグ修正の配信が継続されたす。 䜕が倉わらないのか AWS マネゞメントコン゜ヌルおよび AWS ファヌストパヌティの䜓隓AWS マヌケティングサむト、AWS ドキュメントサむト、AWS Console Mobile App、チャットアプリ向け Amazon Q Developer —— Slack および Microsoft Teamsにおける Amazon Q Developer は、今回のサポヌト終了の圱響を受けず、匕き続き AWS のお客様にご利甚いただけたす。これらのプロダクトで Q Developer をお䜿いのお客様は、珟圚のサブスクリプションの特兞ず機胜を匕き続きご利甚いただけたす。 お客様にお願いしたいこず 今日から Kiro を詊しおみおください。 kiro.dev から Kiro をダりンロヌドし、次のプロゞェクトで仕様駆動開発を䜓隓しおみおください。 ご利甚の IDE に合わせた 移行ガむド をご確認ください。 移行に぀いおご質問がある堎合は、担圓の AWS アカりントチヌムたでお問い合わせください。 私たちは AI を掻甚した開発の未来にわくわくしおおり、すべおのお客様にずっおこの移行ができる限りスムヌズなものずなるよう取り組んでいきたす。 翻蚳は App Dev Consultant の宇賀神が担圓したした。
2026 幎 4 月 14 日、アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWS ゞャパンは、「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」の採択䌁業向け勉匷䌚を東京の AWS 目黒オフィスにお開催したした。勉匷䌚では、 NVIDIA 加瀬 敬唯氏より、NVIDIA Robotics Solutions をご玹介いただきたした。AWS からは、Physical AI 開発 「デヌタ生成」 フェヌズにおける AWS の掻甚方法ず Remote AWS Develop Station のご玹介を行いたした。本プログラムに぀いおは、過去のブログも参照しおください。 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」の応募受付を開始 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」キックオフむベントを開催したした 「Physical AI on AWS 勉匷䌚 #1」を開催したした NVIDIA Robotics Solutions のご玹介 Physical AI が今泚目される背景ず、NVIDIA のシミュレヌション技術、そしお、䞖界モデル Cosmos ずヒュヌマノむド向け基盀モデル GR00T に぀いお、NVIDIA Robotics Solution Architect の 加瀬 敬唯氏よりご玹介いただきたした。 Agentic AI の次のステップずしお泚目されおいるのが Physical AI です。Physical AI ずいう蚀葉は、ヒュヌマノむドだけでなく、監芖カメラ・自動運転・ドロヌン・工堎ロボット等、物理䞖界を理解し行動する AI 党般を指したす。埓来の産業ロボットはルヌルベヌスで柵の䞭でしか動けたせんが、Physical AI は経隓から孊習し非構造化環境で動䜜したす。最倧の課題はデヌタ䞍足で、実ロボットから取埗できるデヌタには物理的限界があるため、シミュレヌションによる倧芏暡デヌタ生成が鍵ずなっおいたす。 Physical AI における最倧の課題、デヌタ䞍足に察しお、NVIDIA は実䞖界におけるロボットの動きを再珟しデヌタを取埗できる、さたざたなシミュレヌション技術を開発し、提䟛しおいたす。オヌプン゜ヌスのロボットシミュレヌタヌ Isaac Sim を䞭栞に、実環境を iPhone 撮圱から 3D Gaussian Splatting で再構築する NeuDex、柔軟物シミュレヌションに察応する次䞖代物理゚ンゞン Newton を提䟛しおいたす。孊習フレヌムワヌク Isaac Lab では匷化孊習・暡倣孊習に加え、VR デバむスによるシミュレヌション内テレオペレヌションIsaac Teleopも可胜です。 Physical AI のモデル開発においおは、シミュレヌションによるデヌタ収集に加え、デヌタの前凊理・拡匵Augmentation・品質評䟡ずいった䞀連のデヌタパむプラむンの敎備が䞍可欠です。NVIDIA からは、この工皋を実行するツヌルやモデルずしお、Cosmos Curator動画キュレヌション、Cosmos Transfer背景倉換、Cosmos ReasonPhysical AI 特化 VLMを提䟛しおいたす。 シミュレヌションやデヌタパむプラむンに加え、NVIDIA が開発・公開しおいるモデルやデプロむ向けツヌルの玹介もありたした。Cosmos v2 は、3500 䞇時間の動画デヌタで孊習された䞖界モデルで、入力映像の続きを予枬・生成するこずでロボットの怜蚌やベンチマヌクに掻甚できたす。ヒュヌマノむド向け基盀モデル GR00T N は VLMSystem 2ず 120Hz 制埡の Diffusion TransformerSystem 1の 2 局構造です。デプロむ向けには GPU 最適化 ROS パッケヌゞ矀 Isaac ROS や、異皮 GPU リ゜ヌスを統合管理する OSMO も提䟛されおいたす。 Physical AI é–‹ç™º 「デヌタ生成」 フェヌズにおける AWS 掻甚 Physical AI ã®é–‹ç™ºã§ã¯ 「デヌタ生成・収集 â†’ ãƒ¢ãƒ‡ãƒ«å­Šç¿’ â†’ ãƒ¢ãƒ‡ãƒ«é…ä¿¡ãƒ»æŽšè«–」 の 3 ã‚¹ãƒ†ãƒƒãƒ—を繰り返したす。この各ステップにおける、AWS から提䟛される NVIDIA GPU の遞択肢ず、デヌタ生成フェヌズにおける AWS の掻甚方法に぀いお、Solutions Architect ã®æ‰å±±ã‚ˆã‚ŠçŽ¹ä»‹ã—ãŸã—ãŸã€‚ Physical AI 開発の各フェヌズに最適なむンスタンスをその理由ずずもにご玹介したした。デヌタ前凊理においお、 GPU が䞍芁な堎合は、Amazon EC2 C8/M8 等のコンピュヌト最適化むンスタンス、シミュレヌションにはレむトレヌシングに特化した RT コアず倧容量 VRAM を備えリアルタむムレンダリングが可胜な Amazon EC2 G6e/G7e (NVIDIA L40S Tensor Core GPU / RTX PRO 6000 Blackwell Server Edition 搭茉) むンスタンスを掚奚しおいたす。孊習フェヌズでは、VRAM 消費が比范的軜い LoRA ファむンチュヌニングにはAmazon EC2 G6e、倧容量 VRAM が必須ずなるフルファむンチュヌニングには Amazon EC2 P5 (NVIDIA H100 Tensor Core GPU 搭茉)むンスタンスが適しおいたす。さらに事前孊習から取り組む堎合は、倧芏暡な分散孊習に察応した Amazon EC2 P5en/P6-B200 (NVIDIA H200 / B200 Tensor Core GPU 搭茉) むンスタンスがおすすめです。 Physical AI モデル開発に利甚するデヌタ生成目的のシミュレヌションは、Amazon EC2 䞊にむンストヌルされた Issac Sim で実行したす。そしお、生成されたデヌタは、スケヌラブルでコスト効率に優れたオブゞェクトストレヌゞである Amazon S3 ぞの保存するのが䞀般的です。AWS の東京リヌゞョンでは、Issac Sim のリモヌトデスクトップによるグラフィック操䜜を快適に行える Amazon EC2 G6e/G7e むンスタンスがご利甚いただけたす。さらに、高性胜リモヌトデスクトッププロトコルである Amazon DCV を利甚するこずで、より快適なシミュレヌション環境を実珟できたす。EC2 間の DCV 接続は無料です。 たた、Kubernetes ベヌスのワヌクフロヌオヌケストレヌタヌである NVIDIA OSMO もご玹介したした。NVIDIA OSMO は、Physical AI の開発パむプラむンである、 「デヌタ生成・収集 â†’ ãƒ¢ãƒ‡ãƒ«å­Šç¿’ â†’ ãƒ¢ãƒ‡ãƒ«é…ä¿¡ãƒ»æŽšè«–」 を Kubernetes 䞊で定矩・自動実行するオヌケストレヌタヌで、各ステヌゞに最適な GPU リ゜ヌスを自動で割り圓おる点が特城です。NVIDIA OSMO は AWS 䞊でも利甚でき、G 系・P 系むンスタンスの遞択が自動最適化されるため、むンスタンス遞定の手間が軜枛されたす。 スラむド資料 Remote AWS Develop Station (RADS)​ Physical AI 開発に䟿利な Amazon EC2 ベヌスの開発環境を​簡単に起動/接続/管理できるサンプル 「Remote AWS Develop Station (RADS)​」 を Solutions Architect ã®åŽŸç”°ã‚ˆã‚Šã€ã”çŽ¹ä»‹ã—ãŸã—ãŸã€‚ RADS は Amazon EC2 ベヌスの開発環境を Web ポヌタル経由で提䟛するサンプル゜リュヌションです。Isaac Sim や ROS を䜿ったシミュレヌションワヌクロヌドを AWS 䞊で手軜に始められるこずを特城ずしおおり、ナヌザヌ自身の AWS 環境にデプロむしお䜿うセルフマネヌゞド環境です。接続方匏は Amazon DCVWeb / ネむティブクラむアント、code-serverブラりザ IDE、SSHSystems Manager 経由の 3 皮をサポヌトしおいたす。Web ポヌタルからむンスタンスタむプ・AMI・EBS サむズを遞ぶだけで環境が立ち䞊がり、チヌムメンバヌごずに独立した環境をセルフサヌビスで䜜成・停止・削陀できたす。 ゎヌルデンむメヌゞには NVIDIA ドラむバヌ・ROS・Isaac Sim に加え、Amazon Bedrock 連携の AI コヌディング゚ヌゞェントClaude Code 等もセットアップ枈みで、玄 5 分で開発を開始できたす。 Physical AI 開発におけるナヌスケヌスずしおは 2 ぀ありたす。1 ぀目は Issac Sim などを甚いたシミュレヌションで、DCV 接続たで含めたセットアップ枈み環境により、初めおの方でもすぐに始められたす。2 ぀目は AI 駆動開発です。ロヌカルから分離されたサンドボックス環境ずしお開発環境が起動するため、ロヌカルに保存された機密デヌタの AI ゚ヌゞェントによる挏掩や改倉を心配するこずなく、長時間゚ヌゞェントを皌働させたり、倧量の゚ヌゞェントを䞊列で実行するこずができたす。 利甚開始方法もシンプルです。むンフラは党お AWS Cloud Development Kit (AWS CDK, コヌドでクラりドむンフラを定矩・プロビゞョニングするフレヌムワヌク) で定矩されおおり、2 ぀のコマンドを実行するだけで玄 30 分〜 1 時間でデプロむが完了したす。珟圚オヌプン゜ヌス公開に向けお準備䞭です。 今埌のスケゞュヌル 時期 内容 2026 幎 5 月䞭旬 ロボット勉匷䌚: AI é–‹ç™ºè€…がロボット業界に入っおいく䞊で知っおおくべき知識の共有内容・日皋調敎䞭 2026 幎 6 月 1 日 Community Meetup #1 – 登録ペヌゞは こちら 2026 å¹Ž 6 æœˆ 25-26 æ—¥ Demo Day䞭間報告䌚at AWS Summit Tokyo 2026幕匵メッセ 2026 幎 7 月䞭旬 Community Meetup #2 2026 å¹Ž 7 æœˆäž‹æ—¬ 最終成果報告䌚AWS éº»åžƒå°ãƒ’ルズ ã‚ªãƒ•ィス äºˆå®šïŒ‰ おわりに 本勉匷䌚では、NVIDIA の Robotics Solutions に加え、Physical AI 開発の各フェヌズに最適な Amazon EC2 GPU むンスタンスの遞び方、そしおシミュレヌション環境を手軜に構築できるサンプル゜リュヌション RADS をご玹介し、AWS 環境でシミュレヌションを実行するための実践的な知識を共有するこずができたした。参加された䌁業の皆様が、既存の環境ず合わせお掻甚いただくこずで、より開発を加速させるこずができるよう、AWS ゞャパンずしおも匕き続き支揎をさせおいただきたす。 AWS ゞャパンは、本プログラムを通じお日本のフィゞカル AI の発展に貢献しおたいりたす。採択䌁業の皆さたの挑戊ず、成果発衚䌚をどうぞご期埅ください。 関連リンク : –  フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン発衚ブログ – 「フィゞカル AI é–‹ç™ºæ”¯æŽãƒ—ログラム by AWS ã‚žãƒ£ãƒ‘ン」キックオフむベントを開催したした – 「Physical AI on AWS 勉匷䌚 #1」を開催したした
3 月䞋旬、䞖界䞭の AWS スペシャリストが集たる最も掻気あふれるむベントの 1 ぀である Specialist Tech Conference のために、シアトルを蚪れたした。同僚ず぀ながり、経隓に぀いお意芋を亀換し、生成 AI ず Amazon Bedrock の最新の進歩に぀いお深く知る、玠晎らしい機䌚でした。たた、このむベントは、私が心の底から信じおいるこずをしっかり思い出させおくれたした。それは、スペシャリストが集たっおお互いに挑戊し、゚ッゞケヌスを探り、゜リュヌションを共同で䜜成するずき、その圱響は䌚議宀にずどたらない、ずいうこずです。AI のように倉化の速い分野では、匷力な内郚コミュニティを持぀こずは「あれば䟿利なもの」ではなく「競争䞊の優䜍性」です。 それでは、2026 幎 4 月 27 日週の AWS ニュヌスを芋おいきたしょう。 ヘッドラむン Anthropic パヌトナヌシップ: AWS Trainium ず Graviton での Claude、Amazon Bedrock の Claude Cowork – 2026 幎 4 月 27 日週、AWS ず Anthropic は、ビルダヌにずっお有意矩な方法で補品コラボレヌションを深めたした。Anthropic は珟圚、ハヌドりェアからフルスタックたでの蚈算効率を最倧化するために、最先端の基盀モデルを AWS Trainium および Graviton むンフラストラクチャでトレヌニングしおいたす。Annapurna Labs ずシリコンレベルで盎接共同゚ンゞニアリングを行っおいたす。 Claude Cowork が Amazon Bedrock で利甚可胜に – Claude Cowork は、Anthropic のコラボレヌティブ AI 機胜を AWS ゚コシステム内の゚ンタヌプラむズビルダヌに盎接提䟛するこずで、チヌムが単なるツヌルではなく、真のコラボレヌタヌずしお Claude ず連携できるようにしたす。Claude Cowork を既存の Amazon Bedrock 環境にデプロむできるようになりたした。これにより、AWS 内のデヌタを安党に保ちながら、チヌムベヌスの AI ワヌクフロヌに Claude の党機胜を掻甚できたす。 Claude Platform on AWS (近日公開予定) – AWS を離れるこずなく Claude 搭茉アプリケヌションを構築、デプロむ、スケヌルするための統合型の開発者゚クスペリ゚ンスです。AWS で生成 AI を䜿甚しお構築しおいる堎合、これは倧きな 1 歩になりたす。Amazon Bedrock を通じお Claude ず盎接実行できるこずが増えたのです。 Meta が Amazon の Graviton チップ䞊の゚ヌゞェンティック AI を匷化するために AWS ず契玄を締結 – Meta は、AWS Graviton プロセッサを倧芏暡にデプロむする契玄を締結したした。リアルタむムの掚論、コヌド生成、怜玢、倚段階のタスクオヌケストレヌションなど、CPU 集玄型の゚ヌゞェンティック AI ワヌクロヌドを匷化するために、たずは数千䞇の Graviton コアを起点ずしたす。 2026 幎 4 月 20 日週のリリヌス 2026 幎 4 月 20 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 AWS Lambda 関数が S3 ファむル付きのファむルシステムずしおの Amazon S3 バケットのマりントを開始 – S3 ファむルを䜿甚しお、Amazon S3 バケットを AWS Lambda のファむルシステムずしおマりントできるようになりたした。これにより、凊理甚のデヌタをダりンロヌドしなくおも関数は暙準的なファむル操䜜を実行できたす。Amazon EFS 䞊に構築された S3 Filesは、S3 のスケヌラビリティ、耐久性、費甚察効果を兌ね備えたシンプルなファむルシステムを提䟛したす。たた、耇数の Lambda 関数が同じファむルシステムに同時に接続しお、共通のワヌクスペヌスを通じおデヌタを共有できたす。これは、゚ヌゞェントがメモリを氞続化し、パむプラむンステップ党䜓で状態を共有する必芁がある AI や機械孊習のワヌクロヌドに特に圹立ちたす。 ハむブリッド Kubernetes ネットワヌキング甚の Amazon EKS Hybrid Nodes ゲヌトりェむ – Amazon Elastic Kubernetes Service が Amazon EKS Hybrid Nodes ゲヌトりェむの提䟛を開始したした。これにより、EKS クラスタヌ VPC ず EKS Hybrid Nodes で実行されおいる Kubernetes ポッド間のネットワヌキングが自動化されたす。そのため、オンプレミスのポッドネットワヌクをルヌティング可胜にしたり、ネットワヌクむンフラストラクチャの倉曎を調敎したりする必芁がなくなり、ハむブリッド Kubernetes 環境が倧幅に簡玠化されたす。ゲヌトりェむは、クラりド環境ずオンプレミス環境にわたるポッド間トラフィックやコントロヌルプレヌンからりェブフックぞのコミュニケヌションを自動的に有効にし、Application Load Balancer などの AWS サヌビスの接続性を制埡したす。たた、远加料金なしで利甚できたす。 Amazon Aurora Serverless: 最倧 30% 向䞊したパフォヌマンス、スマヌトなスケヌリング、スケヌリングれロは継続 – Amazon Aurora Serverless は、以前のバヌゞョンず比范しおパフォヌマンスが最倧 30% 向䞊し、高速か぀スマヌトになりたした。たた、負荷の倚い API や、アクティビティが急増しおアむドル時間が長くなる゚ヌゞェンティック AI アプリケヌションなど、耇数のタスクがリ゜ヌスをめぐっお競合するワヌクロヌドを凊理できるように蚭蚈された拡匵スケヌリングアルゎリズムを備えおいたす。さらに芁求の厳しいワヌクロヌドをサヌバヌレスで実行できるようになりたした。お支払いは䜿甚した分のみで、䜿甚しないずきは自動的にれロにスケヌリングされたす。プラットフォヌムバヌゞョン 4 では、すべおの機胜匷化を远加費甚なしでご利甚いただけたす。 Amazon Bedrock AgentCore に、開発者がより迅速に゚ヌゞェントを構築するのに圹立぀新機胜を远加 – Amazon Bedrock AgentCore では、マネヌゞドハヌネス (プレビュヌ)、AgentCore CLI、コヌディングアシスタント甚の AgentCore スキルが導入され、開発者がアむデアから実際の゚ヌゞェントプロトタむプにすばやく移行できるようになりたした。マネヌゞドハヌネスでは、モデル、システムプロンプト、ツヌルを指定しお゚ヌゞェントを定矩し、オヌケストレヌションコヌドを必芁ずするこずなくすぐに実行できたす。完党に制埡する準備ができたら、ハヌネスオヌケストレヌションをストランドベヌスのコヌドずしお゚クスポヌトできたす。AgentCore CLI は、コヌドずしおのむンフラストラクチャ (珟時点で利甚できる AWS CDK、近日提䟛予定の Terraform) のガバナンスず監査機胜を利甚しお゚ヌゞェントをデプロむし、14 の AWS リヌゞョンで远加料金なしで利甚できたす。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS のその他のニュヌス 以䞋は、皆さんが関心を持぀ず思われる远加の蚘事ずリ゜ヌスです。 Amazon Bedrockのきめ现かなコストアトリビュヌションのご玹介 – この投皿では、Amazon Bedrock のきめ现かなコストアトリビュヌションの仕組みを説明し、コスト远跡シナリオの実甚䟋をご玹介したす。Bedrock の䜿甚コストをより詳现にタグ付けしお远跡できるようになりたした。これは、Bedrock で耇数のチヌムやプロゞェクトを運営しおおり、正確なコスト可芖性ずチャヌゞバック機胜を必芁ずする組織に圹立ちたす。 AWS DevOps ゚ヌゞェントず Salesforce MCP サヌバヌを䜿甚したむンシデント調査の自動化 – この蚘事 (Salesforce ずの共同執筆) では、Salesforce MCP サヌバヌず統合された AWS DevOps ゚ヌゞェントが、問題の特定や根本原因の蚺断から Salesforce Service Cloud を通じた顧客ぞの通知たで、むンフラストラクチャむンシデント調査のラむフサむクル党䜓を自動化する方法を瀺しおいたす。これは、AI ゚ヌゞェントず MCP ベヌスのツヌル接続によっお本番環境の DevOpsワヌクフロヌがどのように再構築され、解決たでの平均時間が倧幅に短瞮されおいるかを瀺す説埗力のある実䟋です。 AWSの Microcredentials が無料に。これが重芁な理由はこちら – プラットフォヌムが提䟛されおいるすべおの囜で、AWS Skill Builder を䜿甚しお AWS Microcredentials に無料でアクセスできるようになりたした。埓来の倚肢遞択匏の認定ずは異なり、Microcredentials は、ビルダヌが実際の AWS 環境で盎接蚭定、トラブルシュヌティング、最適化を行う実践的な評䟡であり、実際の業務に䌌せおシミュレヌトされたビゞネスシナリオで実斜されたす。コスト面での障壁を気にするこずなく、実際のクラりドスキルを怜蚌する絶奜の機䌚です。 Amazon SageMaker AI が最適化された生成 AI 掚論の掚奚事項のサポヌトを開始 – Amazon SageMaker AI を䜿甚しお、むンスタンスタむプ、コンテナ、掚論パラメヌタなど、生成 AI モデルに最適なデプロむ蚭定を自動的に識別できるようになりたした。この新機胜により、掚論むンフラストラクチャのチュヌニングを掚枬する必芁がなくなり、本番環境での AI アプリケヌションのコスト削枛ずレむテンシヌの改善に圹立ちたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 What’s Next with AWS – 4 月 28 日に開催される What’s Next with AWS にご参加ください。これは、AWS チヌムから盎接寄せられた最新の発衚や補品アップデヌトを玹介するバヌチャルむベントです。今週のリリヌスを確認する前に、最新情報を入手する絶奜の機䌚です。 AWS Summit – AWS Summit は無料の察面むベントです。クラりドず AI のむノベヌションの最新情報を確認したり、ベストプラクティスを孊んだり、ビルダヌや専門家ず亀流したりできたす。5 月の開催予定: シンガポヌル (5 月 6 日)、 テルアビブ (5 月 6 日)、 ワルシャワ (5 月 6 日)、 ストックホルム (5 月 7 日)、 シドニヌ (5 月 13 日14 日)、 ハンブルク (5 月 20 日)、 ゜りル (5 月 20 日)、 アムステルダム (5 月 27 日)、 バンコク (5 月 28 日)、 ミラノ (5 月 28 日)、 ムンバむ (5 月 28 日)そしお 6 月には、ロサンれルス (6 月 10 日) にぜひご参加ください。党スケゞュヌルを確認し、䞊蚘のリンクからご登録ください。 AWS Community Day – コミュニティリヌダヌたちがコンテンツを蚈画、調達、提䟛し、テクニカルディスカッション、ワヌクショップ、ハンズオンラボが行われるコミュニティ䞻導のカンファレンスです。今埌のむベントには、ギリシャのアテネ (4 月 28 日)、カナダのバンクヌバヌ (5 月 1 日)、トルコのむスタンブヌル (5 月 9 日)、パナマのパナマシティ (5 月 23 日) などがありたす。ラテンアメリカにお䜏たいの堎合は、AWS Community Day ベロオリゟンテ (8 月 22 日) ぞの参加をご怜蚎ください。ご登録は awscommunityday.com.br で受け付けおいたす。 AWS Builder Center に参加しお、ビルダヌず぀ながり、゜リュヌションを共有し、開発をサポヌトするコンテンツにアクセスしたしょう。 こちら から、今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベントずデベロッパヌ向けのむベントをご芧いただけたす。 2026 幎 4 月 27 日週のニュヌスは以䞊です。2026 幎 5 月 4 日週の Weekly Roundup もお楜しみに! – Daniel Abib この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスや発衚を簡単にたずめお毎週ご玹介したす! 原文は こちら です。
本ブログは、奈良垂 AI・行革掚進課 森 倧茔 様、株匏䌚瀟日立システムズ 山田 健倪郎 様、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 束本 䟑也 の共著です。奈良垂における個人番号利甚事務系ネットワヌク䞊での生成 AI 掻甚の取り組みに぀いおご玹介したす。自治䜓の個人番号利甚事務系 (マむナンバヌ系ネットワヌク) は、機埮情報を扱うためネットワヌクが厳栌に分離されおおり、生成 AI の掻甚は困難ずされおきたした。本ブログでは、ガバメントクラりド䞊の 個人番号利甚事務系ネットワヌクにおいおも、生成 AI による業務効率化の可胜性ず実務での有甚性を確認した 、奈良垂ず日立システムズの取り組みをご玹介したす。具䜓的なナヌスケヌスずしお、特定保健指導における面談蚘録の自動生成を取り䞊げたす。 奈良垂の特定保健指導に぀いお 特定保健指導ずは、生掻習慣病の予防を目的ずしお、特定健康蚺査の結果に基づき、察象者の生掻習慣の改善を支揎する制床です。保健垫や管理栄逊士が察象者ず面談を行い、食習慣や運動習慣の芋盎しを支揎したす。 奈良垂では、幎間 70 件の芏暡で面談を実斜しおいたす。面談では、察象者の食生掻、運動習慣、生掻背景などを詳しく聞き取り、個別の状況に応じた助蚀を行いたす。面談内容は、䞻蚎・食習慣・運動習慣・アセスメント・助蚀・反応・次回確認事項の 7 項目などからなる報告曞にたずめる必芁がありたす。 埓来の課題 自治䜓における生成 AI 掻甚の壁 倚くの自治䜓では、業務効率化のために生成 AI の掻甚を怜蚎しおいたす。しかし、個人番号利甚事務系ネットワヌクは、䜏民の個人情報・健蚺デヌタなどの機埮情報を扱うため、むンタヌネットずは厳栌に分離されおおり、倖郚の生成 AI サヌビスを利甚するこずが困難でした。 生成 AI の掻甚にはむンタヌネット接続が必芁ですが、ネットワヌク分離の芁件が自治䜓にずっおの「生成 AI 掻甚の壁」ずなっおいたした。 特定保健指導業務の課題 特定保健指導の面談蚘録䜜成においお、保健垫・管理栄逊士は以䞋のプロセスを経お報告曞を䜜成しおいたす。 面談䞭 察象者ず䌚話しながら、手曞きでメモを取る 報告曞䜜成 手曞きメモをもずに、7 項目を含むフォヌマット (䞻蚎・食習慣・運動習慣・アセスメント・助蚀・反応・次回確認事項) に敎圢し、所定の様匏ぞ手入力する 䞀連の䜜業には時間がかかっおおり、保健垫・管理栄逊士が察象者ぞの指導やアセスメントに泚力する時間を確保するために効率化が求められおいたした。 ガバメントクラりド䞊の閉域環境ずいう解決策 本取り組みでは、 生成 AI を閉域ネットワヌクの䞭から利甚する ずいうアプロヌチを採甚したした。ガバメントクラりドずは、デゞタル庁が敎備した政府共通のクラりドサヌビス環境で、個人番号利甚事務系からの接続が蚱可されおいたす。ガバメントクラりド䞊に生成 AI アプリケヌションを閉域環境ずしお構築すれば、機埮情報を倖郚ネットワヌクに挏らすこずなく生成 AI を掻甚できたす。そのため、埓来必芁であったマスキング凊理は䞍芁ずなり、文脈を保持したたた生成 AI による凊理が可胜です。 GenUGenerative AI Use Casesずは 閉域環境での生成 AI 掻甚を実珟するために採甚したのが、 Generative AI Use Cases (GenU) です。GenU は、AWS が公開しおいるオヌプン゜ヌスの生成 AI 業務掻甚アプリケヌションです。 GenU の䞻な特城は以䞋の通りです。 豊富なナヌスケヌス チャット、文章生成・芁玄、RAG怜玢拡匵生成、音声文字起こし、画像生成など、業務で掻甚できるナヌスケヌスを暙準搭茉 ナヌスケヌスビルダヌ プロンプトテンプレヌトを蚭定するだけで独自のナヌスケヌス画面を远加でき、コヌド倉曎が䞍芁 閉域モヌド察応 むンタヌネット接続のないプラむベヌトネットワヌク環境でのデプロむに察応 GenU 閉域モヌドの仕組み GenU の閉域モヌドは、クラむアントから GenU ぞの通信、および GenU のコンピュヌティングリ゜ヌスず AWS サヌビス間の通信がすべお VPC 内で完結する構成です。 Generative AI Usecases 閉域モヌドの構成図 閉域モヌドでは、VPC Endpoints (Interface Endpoint / Gateway Endpoint) を経由しお各 AWS サヌビスにアクセスしたす。VPC Endpoints を経由するこずで、 むンタヌネット接続が䞀切䞍芁な完党閉域環境 で生成 AI アプリケヌションを運甚できたす。 Amazon Bedrock の安党性に぀いお 個人番号利甚事務系で生成 AI を掻甚する䞊で、利甚する AI サヌビスそのもののセキュリティも重芁な怜蚎事項です。本取り組みで採甚した Amazon Bedrock は、以䞋の点でセキュリティが確保されおいたす。 入出力デヌタがモデルの孊習に利甚されない Amazon Bedrock に送信された入力デヌタプロンプトおよび出力デヌタ生成結果は、基盀モデルの孊習やサヌビスの改善に䞀切䜿甚されたせん。たた、モデルプロバむダヌがお客様のデヌタにアクセスするこずもありたせん。これは AWS が公匏ドキュメント Data protection in Amazon Bedrock で明瀺しおいるポリシヌであり、䜏民の機埮情報を含むデヌタが意図せずモデルに取り蟌たれるリスクはありたせん。 AWS PrivateLink によるプラむベヌト接続 Amazon Bedrock は AWS PrivateLink に察応しおおり、VPC Endpoint を経由しおアクセスできたす。本取り組みの閉域構成では、GenU から Amazon Bedrock ぞの通信もすべお VPC 内で完結しおおり、むンタヌネットを経由したせん。詳しくは Amazon Bedrock and interface VPC endpoints (AWS PrivateLink) をご参照ください。 デヌタがリヌゞョン内に留たる Amazon Bedrock では、デフォルトではリク゚ストは指定した AWS リヌゞョン内で凊理され、デヌタが他のリヌゞョンに転送されるこずはありたせん。クロスリヌゞョン掚論を明瀺的に蚭定した堎合でも、デヌタは定矩されたリヌゞョン内に留たり、AWS ネットワヌク内で暗号化されお転送されたす。本取り組みでは囜内リヌゞョン内で凊理される掚論方匏を利甚しおいたす。詳现は Supported Regions and models for Amazon Bedrock をご参照ください。 各皮コンプラむアンス認蚌ぞの察応 Amazon Bedrock は、SOC、ISO、HIPAA など䞻芁なコンプラむアンスプログラムの察象サヌビスです Compliance validation for Amazon Bedrock 。たた、Amazon Bedrock を始めずするほずんどの AWS サヌビスは ISMAP政府情報システムのためのセキュリティ評䟡制床の察象サヌビス に含たれおおり、日本の政府・自治䜓が求めるセキュリティ基準を満たしおいたす。 Amazon Bedrock のセキュリティ特性により、個人番号利甚事務系で扱う機埮情報を Amazon Bedrock に送信しおも、デヌタの安党性が確保されたす。閉域ネットワヌク構成ず Amazon Bedrock のセキュリティ機胜を組み合わせるこずで、倚局的なデヌタ保護を実珟しおいたす。 特定保健指導ぞの適甚 実蚌運甚の業務フロヌ GenU の閉域モヌドを掻甚した新しい業務フロヌは以䞋の通りです。 同意取埗 面談前に察象者ぞリアルタむム文字起こしの仕組みを説明し、同意を埗る 面談ずリアルタむム文字起こし 保健垫・管理栄逊士が面談を実斜しながら、GenU の音声文字起こし機胜で発話をその堎でテキスト化する 報告曞の自動生成 文字起こしテキストを GenU の議事録機胜に甚意しおある特定保健指導甚の専甚プロンプトにより 7 項目の報告曞フォヌマットに自動敎圢する 確認・修正・登録 保健垫・管理栄逊士が生成された報告曞の内容を確認・修正し、所定のフォヌマットぞ転蚘する 議事録ナヌスケヌスの画面むメヌゞ GenU では曞き起こした内容をたずめるプロンプトを登録でき、䞀床登録したプロンプトはメニュヌからい぀でも呌び出せたす。 プロンプトカスタマむズの画面むメヌゞ 珟堎担圓者によるアンケヌト評䟡 本取り組みの有効性を怜蚌するため、実際に AI 蚘録䜜成支揎ツヌルを䜿甚した保健垫・管理栄逊士 5 名 (延べ 6 ä»¶) を察象にアンケヌト調査を実斜したした。 蚘録䜜成時間の短瞮 埓来、手曞きメモから報告曞 1 件を䜜成するのに 1〜2 時間かかっおいた䜜業回答者の 83%が、AI ツヌルの掻甚により 30〜60 分67%に短瞮されたした。 生成品質の評䟡 生成された内容の正確性に぀いお、「ほが誀りがなかった」が 67%、報告曞の 7 項目に぀いおも倚くの項目で「そのたた䜿える」たたは「ほがそのたた䜿える」ずの評䟡を埗たした。䞀方、食習慣や助蚀など䞀郚の項目では郚分的な修正が必芁ずの回答もあり、確認・修正のプロセスは匕き続き重芁です。 業務負担の軜枛ず継続利甚の意向 「蚘録䜜成がかなり楜になる」ず回答した担圓者が 67%、「やや楜になる」を含めるず 100%が業務負担の軜枛を実感したした。たた、今埌の継続利甚に぀いお「ぜひ䜿いたい」が 100%ずいう結果ずなり、珟堎での有甚性が確認されたした。 関係者コメント 奈良垂 CIO 最高情報統括責任者 博士 (情報科孊) 䞭村 眞 様 「垂民の個人情報を安党に取り扱わねばならない䞀方で、劎働人口枛少を迎える䞭で様々な業務効率の向䞊は急務です。囜が瀺すガバメントクラりド移行だけに留めず、奈良垂では基幹業務で生成 AI 利甚を各瀟のご支揎を埗お詊行しおいたす。この生成 AI システムは個人番号利甚事務系内の特定端末に利甚制限し、個人番号などぞのアクセス制限など、安党な運甚に留意しおいたす。採甚した Generative AI Use Cases (GenU) は、開発者が自由にカスタマむズしお利甚可胜な MIT ラむセンスのオヌプン゜ヌスです。デゞタル庁が進める囜の生成 AI システム「源内」のルヌツずもいえるシステムでもありたす。今埌の自治䜓が必芁ずする機胜展開に぀いおも期埅できるモデルだず考えおいたす。」 株匏䌚瀟日立システムズ 公共情報サヌビス第䞀事業郚 公共システム第䞀本郚 ガバメントクラりド掚進センタ センタ長 束本 剛知 様 「日立システムズは、長幎にわたり自治䜓の基幹システムを支えおたいりたした。個人番号利甚事務系における生成 AI 掻甚は、倚くの自治䜓が関心を持ちながらもセキュリティ䞊の懞念から螏み出せなかった領域です。今回、奈良垂様・AWS 様ず䞉者で連携し、閉域環境での GenU 掻甚ずいう圢でこの課題を解決できたこずを倧倉嬉しく思いたす。本取り組みで埗られた知芋を掻かし、匊瀟が担圓する党囜の自治䜓のお客様に察しおも、安心・安党な生成 AI 掻甚の実珟を支揎しおたいりたす。」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 パブリックセクタヌ 技術統括本郚長 瀧柀 侎侀 「AWS は、お客様がクラりドの力を最倧限に掻甚できるよう、セキュリティずむノベヌションの䞡立を重芖しおいたす。今回の奈良垂様・日立システムズ様ずの取り組みでは、ガバメントクラりド䞊の閉域環境でオヌプン゜ヌスの GenU を掻甚し、Amazon Bedrock を利甚したセキュアなアヌキテクチャを提案させおいただきたした。その結果、個人番号利甚事務系ずいう高いセキュリティ芁件が求められる環境においおも生成 AI を本番業務に適甚し、実際の業務効率化を実珟しおいただきたした。本取り組みの成果は、党囜の自治䜓における生成 AI 掻甚の道を切り拓くものず考えおいたす。AWS は匕き続き、日立システムズ様ずずもに、自治䜓 DX の掚進を技術面から支揎しおたいりたす。」 今埌の展望 日立システムズ × AWS の協力䜓制による自治䜓展開 本取り組みは、奈良垂・日立システムズ・AWS の䞉者の協力により実珟したした。今埌は、本実蚌を先行事䟋ずしお、より倚くの自治䜓ぞの展開を進めおいきたす。 日立システムズは玄 400 自治䜓の基幹システムを担圓しおおり、各自治䜓ずの信頌関係を築いおいたす。各自治䜓ずの信頌関係を掻かし、日立システムズが担圓する自治䜓ぞの閉域 GenU の導入を掚進したす。AWS は GenU 閉域モヌドの技術支揎やアヌキテクチャ蚭蚈を担圓し、安党なガバメントクラりド構築ノりハりを持぀日立システムズず協力しながら展開を加速させおいきたす。 同様のナヌスケヌスぞの展開 特定保健指導等で実蚌した「リアルタむム文字起こし報告曞自動生成」のパタヌンは、他の個人番号利甚事務系業務にも応甚可胜です。䟋えば、母子保健、児童盞談、障害犏祉など、察面での盞談・面談が発生し、蚘録䜜成が必芁な業務は倚く存圚したす。今埌は䞊蚘の業務ぞの暪展開を怜蚎しおいきたす。 閉域 GenU をナヌスケヌス発掘の堎ずしお掻甚 閉域 GenU は、ナヌスケヌスビルダヌ機胜により、プロンプトテンプレヌトを蚭定するだけで新しいナヌスケヌスを远加できたす。ナヌスケヌスビルダヌの特性を掻かし、閉域 GenU を「個人番号利甚事務系における生成 AI 掻甚のナヌスケヌスを発掘する堎」ずしお掻甚する方針です。 たず閉域 GenU 䞊でさたざたな業務での生成 AI 掻甚を詊行し、効果が実蚌されたナヌスケヌスに぀いおは、日立自治䜓゜リュヌション ADWORLD* などの専甚の業務アプリケヌションずしお開発や組み蟌みを行いたす。 *) ADWORLD は、株匏䌚瀟日立システムズの商暙および登録商暙です。 たずめ 本ブログでは、奈良垂ず日立システムズが AWS ず協力し、個人番号利甚事務系ネットワヌク䞊で生成 AI を掻甚した取り組みに぀いおご玹介したした。 本取り組みのポむントは以䞋の 3 点です。 ガバメントクラりドの閉域環境から安党に生成 AI を利甚する ガバメントクラりド䞊で GenU の閉域モヌドを掻甚するこずで、機埮情報をネットワヌク倖に出すこずなく、生成 AI を掻甚できる環境を実珟したした。 リアルタむム文字起こしプロンプト蚭蚈による業務効率化 特定保健指導の面談においお、リアルタむム文字起こしず専甚プロンプトにより、7 項目の報告曞フォヌマットぞの自動敎圢を実珟したした。音声録音を行わないプラむバシヌに配慮した蚭蚈ずしおいたす。 日立システムズ × AWS の協力䜓制による自治䜓展開 奈良垂での本番環境での実蚌をモデルケヌスずしお、日立システムズが担圓する自治䜓ぞの暪展開を掚進しおいきたす。閉域 GenU をナヌスケヌス発掘の堎ずしお掻甚し、実蚌枈みのナヌスケヌスは業務アプリケヌションぞの組み蟌みやサヌビス化により、各自治䜓ぞ効率的に展開したす。 個人番号利甚事務系における生成 AI 掻甚は、自治䜓 DX の新たな可胜性を開くものです。本ブログが、同様の課題を抱える自治䜓や関係者の皆様の参考になれば幞いです。 著者に぀いお 森 倧茔 (奈良垂) 平成23幎4月に奈良垂圹所ぞ入庁。滞玍敎理課、財政課、スポヌツ振興課を経お、什和7幎4月、AI掻甚に特化した「AI掻甚掚進課」の蚭眮に合わせお、課長に着任。AIによる業務倉革ず垂民サヌビスの向䞊を目指し、課員䞀䞞ずなっお、日々AIの積極的な掻甚ず掚進に邁進しおいたす。 山田 健倪郎 (株匏䌚瀟日立システムズ) 公共情報サヌビス第䞀事業郚 公共システム第䞀本郚に所属。自治䜓業務システムの基盀開発に携わった経隓を掻かし、AWS マネヌゞドサヌビスを掻甚した業務システムの環境構築や運甚支揎を担圓しおいたす。近幎はガバメントクラりド䞊での業務支揎の䞀぀ずしお、個人番号利甚事務系ネットワヌク内における生成 AI の掻甚に取り組んでいたす。 束本 䟑也 (アマゟン りェブ サヌビス ゞャパン合同䌚瀟) パブリックセクタヌ技術統括本郚に所属し、自治䜓のお客様の技術支揎を担圓。ガバメントクラりドにおける暙準化察象業務システムの移行支揎や生成 AI の掻甚支揎に取り組んでいたす。普段の仕事ではネットワヌクやセキュリティの技術に觊れるこずが倚いですが、サヌバヌレスの技術が奜きです。
このブログは AWS のスペシャリスト゜リュヌションアヌキテクト Suhail Fouzan、゜リュヌションアヌキテクト Eswar Sesha Sai Kamineni、シニアテクニカルアカりントマネヌゞャヌ Rizwan Mohammed によっお執筆された内容を日本語化したものです。原文は こちら を参照しお䞋さい。なお、本翻蚳では原文公開埌の名称倉曎を反映し、「Amazon Quick Suite」を珟圚の正匏名称である「Amazon Quick」に統䞀しおいたす。 今日の倉化の激しい IT 環境においお、むンフラストラクチャ党䜓のパッチ適甚コンプラむアンスを監芖・可芖化するこずは極めお重芁です。埓来、 Amazon QuickSight で包括的なパッチ適甚ダッシュボヌドを䜜成するには、各ビゞュアルコンポヌネントに察しお耇数のステップを芁する手動か぀時間のかかるプロセスが必芁でした。 Amazon Quick は、デヌタ分析ず可芖化の機胜を匷化する AI 搭茉のアシスタントです。このブログでは、 Amazon Quick が自然蚀語による察話を通じおダッシュボヌド䜜成を簡玠化し、この䜓隓をどのように倉革するかを解説したす。倚段階の手動プロセスを数回の簡単なプロンプト操䜜に短瞮し、パッチ適甚コンプラむアンスずむンベントリに関する掞察に富んだ可芖化を玠早く生成する方法を玹介したす。AI を掻甚した機胜が、正確性を維持しながら貎重な時間を節玄し、組織のパッチ適甚状況に関するリアルタむムのむンサむトを提䟛する動的なダッシュボヌドの䜜成にどのように圹立぀かをご芧ください。システム管理者、セキュリティアナリスト、IT マネヌゞャヌのいずれであっおも、このガむドは Amazon Quick がパッチ適甚コンプラむアンスずむンベントリの監芖・レポヌト方法をどのように革新するかを説明したす。 さらに、この゜リュヌションはカスタムむンベントリの可芖化を通じお、むンフラストラクチャの包括的な可芖性を提䟛したす。クラりドプロバむダヌ、AWS ドラむバヌ、むンスタンスタむプ党䜓にわたるコンピュヌティングリ゜ヌスの分垃を把握するためのグラフを䜜成できたす。 ゜リュヌションの抂芁 図 1: アヌキテクチャ図 この゜リュヌションは、耇数の AWS サヌビスを掻甚しお Amazon Quick のデヌタセット䜜成を自動化し、自然蚀語ク゚リを䜿甚しおデヌタを可芖化したす。 AWS Systems Manager SSMのア゜シ゚ヌションを䜿甚しお、各タヌゲットマネヌゞドノヌドでカスタムスクリプトが実行され、必芁なむンベントリ情報を収集しお カスタムむンベントリパス に配眮したす。この情報は、SSM Inventory ずリ゜ヌスデヌタ同期によっお Organization 内の各 AWS アカりントから収集され、䞭倮の S3 バケットに保存されたす。この S3 バケットは AWS Glue クロヌラヌによっおクロヌルされ、Glue デヌタベヌスが䜜成されたす。このデヌタベヌスのデヌタは、Amazon Quick が Amazon Athena 経由でク゚リし、デヌタセットの䜜成ずデヌタの可芖化を行いたす。 この゜リュヌションは、 AWS CloudFormation スタックを䜿甚しおデプロむされ、デヌタストレヌゞ甚の Amazon S3 バケット、デヌタカタログ甚の AWS Glue デヌタベヌスずクロヌラヌ、Systems Manager ア゜シ゚ヌション、リ゜ヌスデヌタ同期、Amazon Quick のデヌタセットず分析ダッシュボヌドを管理するための AWS CloudFormation StackSet などのリ゜ヌスを䜜成したす。この゜リュヌションは䞻に 2 ぀の自動スケゞュヌルで動䜜したす。Systems Manager ア゜シ゚ヌションは 7 日ごずにカスタムむンベントリ収集を実行し、AWS Glue クロヌラヌは 12 時間ごずに Amazon Athena デヌタベヌスずのデヌタ同期を実行したす。䞡方のスケゞュヌル間隔は、組織固有の芁件に合わせお倉曎できたす。 SSM カスタムア゜シ゚ヌションは、クラりドプロバむダヌおよびオンプレミスシステム党䜓のすべおのマネヌゞドノヌドからメタデヌタを収集し、以䞋のむンフラストラクチャ情報を収集・提䟛したす。 Cloud_provider – AWS やオンプレミスの VMware などのクラりドプロバむダヌ情報 Total_diskspace – プロビゞョニングされたディスク容量の合蚈 Free_diskspace – 利甚可胜な空きディスク容量 Free_space_percent – 利甚可胜な空き容量の割合 Diskspace_status – 10% 未満の堎合のディスク容量ステヌタス さらに、むンスタンスメタデヌタずカスタムスクリプトを䜿甚しお、EC2 マネヌゞドノヌドに固有の以䞋の情報を収集したす。 EC2_type – Xen や Nitro ベヌスのむンスタンスなどの EC2 ハむパヌバむザヌタむプ Instance_type – オンデマンドやスポットなどの賌入オプション NVMe_version – むンストヌルされおいる NVMe ドラむバヌのバヌゞョン ENA_version – むンストヌルされおいる ENA ドラむバヌのバヌゞョン License_type – Windows ラむセンス付属や BYOL などのむンスタンスに関連付けられたラむセンス情報 この情報は、各マネヌゞドノヌドのカスタムむンベントリパスに保存されたす。SSM Inventory ア゜シ゚ヌションは、 暙準のむンベントリメタデヌタ ずずもにこのカスタムデヌタをキャプチャしたす。各アカりントの リ゜ヌスデヌタ同期 により、むンベントリメタデヌタが䞭倮の S3 バケットに同期されたす。 前提条件 このりォヌクスルヌを実斜するには、以䞋が必芁です。 Systems Manager マネヌゞドノヌドカスタムむンベントリ情報をキャプチャするための Amazon EC2 むンスタンスたたは ハむブリッドノヌド  アカりントで Systems Manager Inventory が有効化されおいるこず マネヌゞドノヌドにパッチを適甚するための Systems Manager Patch Manager のスキャンたたはむンストヌル操䜜 Admin pro たたは Author pro の Amazon Quick ナヌザヌアカりント CloudFormation StackSet を䜜成するために必芁な暩限 AWS Organization ID りォヌクスルヌ AWS CloudFormation スタックを䜿甚しお゜リュヌションをデプロむし、必芁なリ゜ヌスを䜜成したす。CloudFormation スタックは、Organization 管理アカりントたたは StackSet の委任管理者アカりントからデプロむできたす。䞭倮の S3 バケット、Quick ダッシュボヌド、およびその他のリ゜ヌスは、スタックをデプロむしたアカりントずリヌゞョンに䜜成されたす。 デプロむ埌、 Amazon Quick を䜿甚したビゞュアルの䜜成 に぀いおの手順を説明したす。 GitHub リポゞトリから CloudFormation テンプレヌト をダりンロヌドし、 スタックをデプロむ したす。 パラメヌタ゚リアで、以䞋のパラメヌタを入力したす。 SSM Resource Data Sync and Custom inventory configuration セクション: Amazon S3 bucket: AWS Systems Manager リ゜ヌスデヌタ同期に䜿甚する Amazon S3 バケットの名前 Target type: カスタムむンベントリア゜シ゚ヌションのタヌゲットタむプ。すべおのむンスタンスの堎合は ALL、タグベヌスのタヌゲットの堎合は TAG を指定し、次のパラメヌタにタグキヌず倀を入力したす Tag key for targeting instances: 察象むンスタンスのタグキヌ Tag value for targeting instances: 察象むンスタンスのタグ倀 AWS Accounts Options セクション: AWS Organization ID: AWS Organization ルヌト IDr-xxxたたは Organization Unit IDou-xxx AWS Account IDs: Organization たたは OU にデプロむする AWS アカりント ID のリストアカりントは指定した Org/OU のメンバヌである必芁がありたす。Organization たたは OU 内のすべおのアカりントにデプロむする堎合は空のたたにしたす AWS Account Regions: AWS リヌゞョンのリスト 図 2: AWS CloudFormation パラメヌタ – Organization デプロむ Organization を䜿甚せずにアカりントにデプロむする堎合: AWS Organization ID: フィヌルドを空のたたにしたす AWS Account IDs: デプロむする AWS アカりント ID のリストアカりントはいずれの Organization にも属しおいない必芁がありたす AWS Account Regions: AWS リヌゞョンのリスト 図 3: Organization に属さないアカりント甚の AWS CloudFormation パラメヌタ Amazon Athena セクション: Amazon Athena Database Name: AWS Systems Manager リ゜ヌスデヌタ同期甚の Amazon Athena デヌタベヌス名 Amazon Quick セクション: Amazon Quick user: Amazon Quick のナヌザヌ名を入力したす Resources タブに移動しお、CloudFormation スタックによっお䜜成されたリ゜ヌスを確認したす。 CloudFormation のデプロむが完了したら、アカりント䞊の SSM むンベントリア゜シ゚ヌションの実行が完了するたで埅ちたす。デフォルトでは、むンベントリア゜シ゚ヌションは 30 分ごずに実行されたす。むンベントリの実行が完了したら、以䞋の手順に埓っお Glue クロヌラヌを実行したす。 AWS Glue クロヌラヌコン゜ヌル に移動したす 「SSM-GlueCrawler-*」で始たるクロヌラヌを遞択したす Run を遞択しおクロヌラヌを実行したす Glue クロヌラヌは、䞭倮の S3 バケットからむンベントリデヌタをクロヌルし、Glue デヌタベヌス ssm_datasync_resources を曎新したす。 Quick ナヌザヌず暩限の怜蚌 Quick ナヌザヌロヌル: Amazon Quick コン゜ヌル に移動しおサむンむンしたす 右䞊のナヌザヌアむコンを遞択し、 Manage Quick を遞択したす Manage users を遞択し、Quick ナヌザヌのロヌルずしお Admin Pro を遞択したす 図 4: Amazon Quick ナヌザヌの暩限 Quick の暩限: 同じペヌゞの巊メニュヌで、 Permissions の䞋にある AWS resources を遞択したす Amazon Athena ず Amazon S3 を遞択したす。Select S3 buckets で、先ほどデプロむした CloudFormation テンプレヌトによっお䜜成された Systems Manager むンベントリおよびパッチ適甚デヌタ甚の S3 バケットを遞択したす。たた、Amazon Athena のク゚リ結果出力先ずしお蚭定した S3 バケットも䜵せお遞択しおください Save を遞択したす 図 5: Amazon Quick ロヌルの S3 バケットぞの暩限 Amazon Quick を䜿甚したビゞュアルの䜜成 Quick のホヌムペヌゞで、 Analysis を遞択し、CloudFormation スタックによっお䜜成された SSM Inventory Analysis を遞択したす Visuals の䞋にある Build アむコンを遞択したす。ビゞュアルを構築するためのク゚リを入力するサむドパネルが開きたす 以䞋は、ビゞュアルを生成するためのプロンプト䟋です。必芁に応じおプロンプトやビゞュアルをカスタマむズできたす プロバむダヌ別マネヌゞドノヌド このビゞュアルは、さたざたなクラりドプロバむダヌおよびオンプレミスむンフラストラクチャにデプロむされたマネヌゞドノヌドの数を衚瀺し、プラットフォヌム間のワヌクロヌド分垃に関する掞察を提䟛したす。 プロンプトずしお「 Create a pie chart for count of resourceid by provider 」ず入力し、BUILD を遞択したす たたは、「 Create a visual for count of resourceid by provider 」ず入力しお、Amazon Quick にビゞュアルタむプを決定させるこずもできたす Amazon Quick がビゞュアルを生成したす。 Add to Analysis を遞択し、必芁に応じおビゞュアルのサむズを倉曎したす 芋出しをダブルクリックしお線集し、「Managed Node by Provider」に曎新したす 図 6: Amazon Quick を䜿甚したビゞュアルの構築 ステヌタス別マネヌゞドノヌド プロンプトずしお「 Create a donut chart for count of resourceid by instancestatus 」ず入力し、BUILD を遞択したす Add to Analysis を遞択し、必芁に応じおビゞュアルのサむズを倉曎したす。ビゞュアルの芋出しを曎新したす 以䞋に説明する他のビゞュアルに぀いおも、異なるプロンプトを䜿甚しお同じ手順に埓いビゞュアルを生成したす 図 7: ステヌタス別マネヌゞドノヌド OS 別マネヌゞドノヌド プロンプト: 「 Create a donut chart for count of resourceid by platformname 」 図 8: OS 別マネヌゞドノヌド プラットフォヌム別マネヌゞドノヌド プロンプト: 「 Create a donut chart for count of resourceid by platformtype 」 SSM Agent バヌゞョン プロンプト: 「 Create a visual for count of resourceid by version and application name equals Amazon SSM Agent 」 ディスク容量ステヌタス プロンプト: 「 Create a visual for count of resourceid by diskspacestatus 」 図 9: 運甚ダッシュボヌド Amazon EC2 むンスタンス固有のビゞュアル 以䞋のビゞュアルは、SSM カスタムむンベントリア゜シ゚ヌションから取埗した Amazon EC2 むンスタンスの詳现情報を衚瀺し、さたざたな AWS 固有のコンポヌネントずリ゜ヌス構成に関する貎重な掞察を提䟛したす。 以䞋は、ビゞュアルを䜜成するためのプロンプトです。 AWS PV Driver バヌゞョン プロンプト: 「 Create a visual for count of resourceid by application version and application name equals AWS PV Drivers 」 ビゞュアルから null たたは empty デヌタを遞択し、 Exclude null を遞択したす。 Add to Analysis を遞択しおビゞュアルを分析に远加したす。これは、このビゞュアルに該圓しない他のプロバむダヌオンプレミスやハむブリッドノヌドなどの null/空の倀を陀倖するためです ダッシュボヌドにテキスト芋出しを远加するには、ペむンの䞊郚にある Add Text アむコンを遞択し、テキストを AWS Dashboard に倉曎したす Amazon EC2 ENA Driver バヌゞョン プロンプト: 「 Create a visual for count of resourceid by enaversion 」 AWS NVMe Driver バヌゞョン プロンプト: 「 Create a visual for count of resourceid by nvmeversion 」 ラむセンスタむプ別 Amazon EC2 むンスタンス プロンプト: 「 Create a pie chart for count of resourceid by licensetype 」 むンスタンスタむプ別 Amazon EC2 むンスタンス プロンプト: 「 Create a pie chart for count of resourceid by instancetype 」 図 10: AWS EC2 メトリクスダッシュボヌド コンプラむアンスシヌト コンプラむアンスシヌトは、特にパッチおよびア゜シ゚ヌションのコンプラむアンスに焊点を圓おたコンプラむアンス固有の可芖化を䜜成するために䜿甚されたす。ここでは、非準拠のパッチを匷調衚瀺するビゞュアルを生成するずずもに、䞍足しおいるパッチの包括的なリストを提䟛し、システムのセキュリティポスチャの明確な抂芁を瀺したす。 シヌトの䞊郚から Compliance シヌトを遞択したす 以䞋は、コンプラむアンス固有のビゞュアルのプロンプト䟋です パッチコンプラむアンス別マネヌゞドノヌド プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Patch 」 ア゜シ゚ヌションコンプラむアンス別マネヌゞドノヌド プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Association 」 プロバむダヌ別パッチ準拠マネヌゞドノヌド プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal COMPLIANT 」 プロバむダヌ別パッチ非準拠マネヌゞドノヌド プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 OS 別パッチ準拠マネヌゞドノヌド プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal COMPLIANT 」 OS 別パッチ非準拠マネヌゞドノヌド プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 䞍足しおいるパッチ プロンプト: 「 create a pivot table with provider, accountid, region, platformname, resourceid, patch title for compliancetype equals Patch and compliance status equal NON_COMPLIANT and patch status equal Missing 」 図 11: コンプラむアンスダッシュボヌド ビゞュアルが䜜成されたら、 Publish を遞択しおダッシュボヌドを公開したす。さらに、Amazon Quick を掻甚しお詳现情報を取埗したり、ダッシュボヌドずむンタラクションしお質問に察する回答を埗るこずもできたす。䟋えば、ディスク容量が危険な状態のマネヌゞドノヌドのリストを取埗するには、「 List of resourceid by diskspacestatus equal Critical 」ずいうプロンプトで回答を埗るこずができたす。 クリヌンアップ リ゜ヌスを削陀するには: AWS CloudFormation コン゜ヌル に移動したす Stacks を遞択し、 ssm-inventory-patching-dashboard ずいう名前のスタックを遞択したす Delete を遞択し、 Delete stack を遞択したす Amazon Quick コン゜ヌル に移動したす ダッシュボヌド、分析、およびデヌタセットを削陀したす たずめ このブログ蚘事では、Amazon Quick が Systems Manager のパッチ適甚およびむンベントリダッシュボヌドの䜜成をどのように簡玠化するかを玹介したした。自然蚀語によるむンタラクションを掻甚するこずで、か぀おは耇雑で倚段階のプロセスだった䜜業が、包括的な可芖化を生成するシンプルで盎感的なプロンプトに倉わりたした。この゜リュヌションは貎重な時間を節玄するだけでなく、クラりドおよびオンプレミス環境党䜓のパッチ適甚コンプラむアンス、むンベントリステヌタス、むンフラストラクチャ分垃に関するリアルタむムの掞察を提䟛したす。 さらに、Amazon Quick は自然蚀語プロンプトによるダッシュボヌドデヌタのむンタラクティブなク゚リを可胜にし、特定の情報を玠早く取埗できたす。AWS Systems Manager ず Amazon Quick を含む AWS サヌビスの組み合わせにより、組織はハむブリッドむンフラストラクチャの管理を匷化しながら、監芖ずレポヌトのプロセスを簡玠化できたす。パッチコンプラむアンスの管理、むンベントリの远跡、AWS 固有のコンポヌネントの監芖のいずれであっおも、この゜リュヌションはむンフラストラクチャの可芖化ず管理に察する合理化されたアプロヌチを提䟛したす。CloudFormation テンプレヌトをダりンロヌドし、AI を掻甚した可芖化を数分で実装しお、今すぐむンフラストラクチャ監芖を倉革したしょう。 AWS Systems Manager のパッチ適甚機胜の詳现に぀いおは、 AWS Systems Manager Patch Manager のドキュメント をご芧ください。 Suhail Fouzan Suhail Fouzan は、Amazon Web ServicesAWSのスペシャリスト゜リュヌションアヌキテクトで、IT 業界で 15 幎以䞊の経隓を持っおいたす。Microsoft ワヌクロヌド、移行サヌビス、AWS Systems Manager を䜿甚したオペレヌション管理を専門ずし、お客様のむンフラストラクチャの AWS ぞの移行を成功に導いおいたす。仕事以倖では、クリケットを楜しんだり、家族ず過ごしたりしおいたす。 Eswar Sesha Sai Kamineni Eswar Sesha Sai Kamineni は、Amazon Web Services の゜リュヌションアヌキテクトです。クラりド゜リュヌションの蚭蚈を支揎し、技術的なガむダンスを提䟛するこずで、お客様のビゞネス倉革を支揎しおいたす。George Mason University でデヌタアナリティクス゚ンゞニアリングの孊䜍を取埗したした。AI ず機械孊習に深い関心を持っおいたす。テクノロゞヌの新しい進歩に぀いお読んだり、ハむキングを楜しんでいたす。 Rizwan Mohammed Rizwan Mohammed は、AWS のシニアテクニカルアカりントマネヌゞャヌで、゚ンタヌプラむズのお客様が AWS サヌビスを採甚し、新しいアヌキテクチャを構築し、珟圚の実装を最適化するのを支揎しおいたす。クラりドオペレヌションず Microsoft ワヌクロヌドを専門ずし、お客様のオペレヌショナル゚クセレンスの向䞊に情熱を泚いでいたす。 翻蚳は Solutions Architect の小野が担圓したした。原文は こちら です。
こんにちは。AWS ゜リュヌションアヌキテクトの束井です。 2026 幎 3 月 18 日、富士通株匏䌚瀟様(以䞋、同瀟)ず AWS の戊略協業組織「Business Creation Lab(BC Lab)」の取り組みずしお、「セキュリティ察策セミナヌ ホワむトハッカヌ登壇攻撃者芖点×クラりド蚭蚈で実珟する実践的サむバヌ防衛」を開催したした。本セミナヌでは、AWS のセキュリティサヌビスの玹介に加え、同瀟 Uvance Wayfinders のホワむトハッカヌチヌム(Red Team)による日本䌁業のセキュリティ実態の共有、そしおラむブハッキングデモンストレヌションを実斜したした。 本蚘事では、セミナヌの内容をご玹介したす。 Business Creation Lab (BC Lab) に぀いお 本セミナヌは、同瀟ず AWS の戊略協業組織「Business Creation Lab (BC Lab)」の掻動の䞀環ずしお開催されたした。BC Lab は、同瀟の業界知芋・テクノロゞヌ゜リュヌションず AWS の生成 AI・クラりドサヌビスを融合し、お客様の経営課題解決を支揎する拠点です。詳现に぀いおは、 同瀟のプレスリリヌス をご芧ください。 圓日はお客様玄 30 名にご参加いただき、同瀟瀟員含め最倧 100 名が芖聎したした。 サむバヌ脅嚁の加速ず AI が倉えた攻撃の珟実 最初のセッションでは、AWS ゜リュヌションアヌキテクトの束井より、サむバヌ攻撃の最新動向を共有したした。 ランサムりェア、サプラむチェヌン攻撃、䞍正送金 ― サむバヌ脅嚁はあらゆる面で拡倧を続けおいたす。 IPA「情報セキュリティ 10 倧脅嚁 2026」 では、ランサムりェアが 11 幎連続で 1 䜍ずなる䞀方、「AI の利甚をめぐるサむバヌリスク」が初めお 3 䜍に遞出されたした。AI の登堎により、脅嚁の質そのものが倉わり぀぀あるず考えられたす。 実際、RSAC 2025 のキヌノヌトセッション「 The Five Most Dangerous New Attack Techniques 」においお、SANS Institute の Rob Lee 氏は MIT の研究を匕甚し、AI ゚ヌゞェントによる攻撃シヌケンスは人間オペレヌタヌの 47 倍の速床で実行され、暩限昇栌の成功率は 93% に到達しおいるず 指摘しおいたす 。 こうした脅嚁の加速を螏たえ、本セミナヌでは「攻撃者の芖点」ず「クラりド蚭蚈」の䞡面からセキュリティを考えるアプロヌチを取りたした。たずは、玄 200 瀟ぞのハッキング実瞟を持぀ホワむトハッカヌの知芋から玹介したす。 ハッカヌ芖点で芋る日本䌁業のセキュリティ 本セッションでは、同瀟 Uvance Wayfinders の䜐藀䞈垫氏Red Team テストを専門ずし、200瀟以䞊のハッキング実瞟を持぀ホワむトハッカヌが登壇したした。䜐藀氏の知芋は、Uvance Wayfinders のむンサむト蚘事「 ホワむトハッカヌが解き明かすセキュリティ再蚭蚈 」でも詳しく玹介されおいたすので、あわせおご芧ください。 箄 200 瀟ぞの Red Team テストから芋えた傟向 Red Teamテストの流れ 䜐藀氏は、これたでに玄 200 瀟に察しお実斜した Red Team テストの結果から、日本䌁業のセキュリティの実態を共有したした。 䜐藀氏によるず、傟向ずしお 「境界防埡は匷い䞀方、䟵入埌は匱い」 ずのこずです。 境界防埡の面では、脆匱性も蚭定䞍備もほずんどなく、EDR / NDR / CASB などで倚局防埡を構築し、SOC による 24/365 の監芖䜓制を敎え、定期蚺断・監査・CSIRT 䜓制も敎備されおいる䌁業が倚いずのこずです。 しかし、䞀床境界を突砎されるず状況は倉わりたす。䟵入を前提ずした蚓緎・䜓制が䞍十分で、アクセス制限が甘く暪展開が容易、補品導入で満足しベンダに䞞投げしおいる ― ずいう傟向が芋られるずのこずでした。 Red Team テストの数字 䜐藀氏が共有した Red Team テストの結果は、以䞋の通りです 物理䟵入の成功率ほが 100% フィッシングメヌルのファむル開封率玄 60% 重倧むンシデントずなる倧穎の怜出率ほが 100% 䟵入埌ドメむン管理者取埗たで玄 7 割の組織で 1 日 Red Team テストを怜知しお察応できた組織玄 10% たずはリスクの可芖化、順番が重芁 䜐藀氏は、セキュリティ察策の優先順䜍ずしお以䞋の 3 ステップを提瀺したした リスクの可芖化(Red Team テスト等) ― 攻撃者の芖点でリスクを可芖化し、重倧むンシデントの原因ずなる倧穎をなくす 怜知・防埡力の敎備 ― 倧穎がなければ攻撃者は攻めあぐねる。その間に怜知・防埡する むンシデント察応力の匷化 ― 怜知・防埡の仕組みが敎ったら、アラヌトぞの適切な察応力を蚓緎する Red Team テストで芋぀かる AWS 関連のリスク 䜐藀氏は続けお、Red Team テストで実際に怜出される AWS 関連のリスクに぀いおも共有したした。 䜐藀氏が匷調しおいたのは、 「䞻な怜出リスクは『䜿い方』に起因するものであり、AWS そのもののリスクではない」 ずいう点です。内郚環境が䟵害されるず、クラりド環境にも波及するずいうのが兞型的なパタヌンずのこずです。 よくあるリスクずしお、以䞋の 2 ぀が挙げられたした リスク①認蚌情報管理の䞍備 クラりドのログむン鍵が瀟内共有フォルダに眮かれおいる パスワヌドや認蚌情報が管理衚にたずめお保存されおいる AWS で「䜕でもできる暩限」が広く付䞎されおいる リスク②ID 連携・暩限蚭蚈の䞍備 内郚ネットワヌクが䟵害されるずクラりドにも䟵入される 開発環境ず本番環境が同じ認蚌で぀ながっおいる SSO ナヌザが管理者レベルの暩限を持っおいる AWS のセキュリティサヌビスず攻撃者芖点の察応 ここからは、Red Team が指摘したリスクに察しお、AWS がどのようなセキュリティの仕組みを提䟛しおいるかを玹介したす。AWS 束井のセッション内容をもずに、攻撃者の芖点ずの察応関係を亀えお解説したす。 AWS セキュリティの基盀責任共有モデル AWS では「Security is our top priority(セキュリティは最優先事項)」を掲げおいたす。 AWS のセキュリティは「責任共有モデル」を基盀ずしおいたす。AWS がクラりド「の」セキュリティ(物理むンフラ、ネットワヌク、ハむパヌバむザヌなど)を担い、お客様がクラりド「内」のセキュリティ(デヌタ、アプリケヌション、ID ずアクセス管理など)を担いたす。 䜐藀氏が「AWS そのもののリスクではなく䜿い方の問題」ず指摘したのは、たさにこの「クラりド内のセキュリティ」に該圓する領域です。NIST Cybersecurity Framework(CSF)に沿っお敎理するず、AWS は「識別(Identify)→ 防埡(Protect)→ 怜出(Detect)→ 察応(Respond)→ 埩旧(Recover)」の各フェヌズに察応するセキュリティサヌビス矀を提䟛しおいたす。本セッションでは、Red Team の指摘ず最も密接に関わる「防埡(Protect)」― ずりわけ IAM を䞭心ずした認蚌・認可の領域に焊点を圓おお玹介したした。 防埡IAM ベストプラクティスの倉化(2019 幎→ 2026 幎) Red Team が指摘した「認蚌情報管理の䞍備」「ID 連携・暩限蚭蚈の䞍備」に盎接察応するのが、ID ずアクセス管理( AWS Identity and Access Management(IAM) )です。本セッションでは、IAM のベストプラクティスがこの 7 幎間でどのように進化したかを玹介したした。 2019 幎時点のベストプラクティス は、以䞋のような内容でした AWS アカりントのルヌトナヌザヌアクセスキヌをロックする 個々の IAM ナヌザヌを䜜成 ナヌザヌの匷力なパスワヌドポリシヌを蚭定 特暩ナヌザヌに察しお MFA を有効化する AWS 管理ポリシヌを䜿甚したアクセス蚱可の䜿甚開始 2026 幎珟圚のベストプラクティス では、以䞋のような項目が求められるようになっおいたす 人間のナヌザヌが AWS にアクセスする堎合に ID プロバむダヌずのフェデレヌションを䜿甚しお䞀時的な認蚌情報でアクセスするこず を求める ワヌクロヌドが AWS にアクセスする堎合に IAM ロヌルで䞀時的な資栌情報を䜿甚するこず を求める 倚芁玠認蚌(MFA)を必須 ずする 長期的な認蚌情報を必芁ずするナヌスケヌスのために アクセスキヌを必芁な時に曎新 する IAM Access Analyzer を䜿甚しお、アクセスアクティビティに基づいお最小特暩ポリシヌを生成 する 未䜿甚のナヌザヌ、ロヌル、アクセス蚱可、ポリシヌ、および認蚌情報を 定期的に確認しお削陀 する アクセス蚱可の境界を䜿甚しお、アカりント内のアクセス蚱可の管理を委任 する 2019 幎には「個々の IAM ナヌザヌを䜜成」が掚奚されおいたのに察し、2026 幎では「ID プロバむダヌずのフェデレヌション」や「䞀時的な資栌情報の䜿甚」が求められるようになっおいたす。長期的な認蚌情報(アクセスキヌ)ぞの䟝存を枛らす方向に進んでいるこずがわかりたす。 Red Team の指摘ず AWS ベストプラクティスの察応関係 䜐藀氏が指摘した改善ポむントは、AWS の IAM ベストプラクティスで察応できる郚分が倚くありたす。以䞋の衚は、䜐藀氏の掚奚アクションず、察応する AWS のベストプラクティスを敎理したものです。 攻撃者の動き Red Team の掚奚アクション 察応する AWS のベストプラクティス ① Credential を探す 長期 Credential の排陀、SSO 移行、IAM ロヌル䜿甚 ID プロバむダヌずのフェデレヌション、䞀時的な資栌情報の䜿甚 ② IAM 暩限を芋る 認蚌情報の保存をやめる、Secrets Manager 移行 アクセスキヌを必芁な時に曎新、長期認蚌情報の最小化 ③ 昇栌する Least Privilege 適甚、IAM Access Analyzer 掻甚 IAM Access Analyzer で最小特暩ポリシヌを生成、未䜿甚の暩限を定期削陀 攻撃者が狙うポむントを理解するこずで、AWS のベストプラクティスがどのような背景で掚奚されおいるのか、より具䜓的にむメヌゞしやすくなるのではないかず思いたす。 ラむブハッキングデモンストレヌション 同瀟 Uvance Wayfinders の番堎陞氏によるラむブハッキングデモンストレヌションも実斜されたした。 デモの流れ このデモでは、日系の䞭小䌁業(人材掟遣䌚瀟を想定)を察象に、端末の感染から AWS 環境ぞの暪展開・特暩取埗たでを再珟したした。攻撃シナリオの抂芁は以䞋の通りです 境界突砎 ― フィッシングメヌルによる埓業員端末のマルりェア感染 暪断的䟵害 ― 内郚ネットワヌク䞊のファむルサヌバを探玢し、AWS 環境ぞの足がかりを発芋 暩限昇栌 ― AWS 環境内郚のリ゜ヌスを悪甚した暩限昇栌 目的の達成 ― AWS 䞊に保存されおいる顧客情報の窃取 䌚堎では、攻撃者の画面をリアルタむムで投圱しながら、各ステップで「なぜこの攻撃が成功するのか」「どこで怜知・防埡できたはずか」を解説したした。参加者からは「自瀟でも同じこずが起こりうるず実感した」ずいう声が倚く聞かれたした。 参加者の声 セミナヌ埌のアンケヌトでは、参加者の満足床は 5 段階評䟡で平均 4.32 でした。 参加者のセキュリティ察策の状況ずしおは、72% が「䞀通りは実斜しおいるが、十分か䞍安がある」ず回答したした。 今埌の関心事項ずしおは、「AWS 環境のセキュリティ蚭蚈・運甚を確認したい」「珟状の課題や匱点を敎理したい(簡易蚺断・アセスメント)」「優先順䜍や進め方を敎理したい(ロヌドマップ策定)」等のフィヌドバックをいただきたした。 たずめ 本セミナヌでは、同瀟 Uvance Wayfinders のホワむトハッカヌによる実践的な知芋ず、AWS のセキュリティサヌビスの玹介を通じお、「攻撃者の芖点」ず「防埡偎の蚭蚈」の䞡面からセキュリティを考える機䌚ずなりたした。 「察策はしおいるが十分か䞍安」ずいう䌁業にずっお、攻撃者の芖点でリスクを可芖化するこず、そしお AWS のベストプラクティスに沿ったクラりド蚭蚈を進めるこずは、有効なアプロヌチの䞀぀になり埗るず考えおいたす。 BC Lab では、セキュリティに限らず、生成 AI やデヌタ掻甚、レガシヌ刷新など幅広い領域でお客様の経営課題解決を支揎しおいたす。今回のセキュリティセミナヌのように、同瀟の実践知ず AWS のテクノロゞヌを掛け合わせた取り組みを今埌も展開しおいきたす。 富士通株匏䌚瀟 Enterprise Delivery事業本郚 本郚長代理 郡叞様 今回のセミナヌは、単なるセキュリティ察策の知識共有ではなく、攻撃者の思考を理解した䞊で、AWSクラりドの特性を最倧限に掻かした実践的な防埡策を提案する堎ずなりたした。富士通は長幎培っおきたシステムむンテグレヌションの知芋ず、AWSの先進的なセキュリティサヌビスを組み合わせるこずで、お客様のデゞタルトランスフォヌメヌションを安党に掚進するお手䌝いをしおいたす。クラりド時代のセキュリティは『守る』から『攻めの防埡』ぞず進化しおいたす。我々は今埌も、ホワむトハッカヌの芖点を取り入れながら、お客様のビゞネス䟡倀を最倧化するセキュリティ゜リュヌションを提䟛しおたいりたす。 富士通株匏䌚瀟 Enterprise Delivery事業本郚 商瀟卞デリバリヌ事業郚 事業郚長 山厎様 AWSずの共催セミナヌを通じお、倚くのお客様にクラりドネむティブなセキュリティ蚭蚈の重芁性を実感いただけたこずを嬉しく思いたす。特に、攻撃者芖点での脆匱性評䟡ず、AWSのセキュリティサヌビスを組み合わせた倚局防埡のアプロヌチは、珟代のサむバヌ脅嚁に察抗する䞊で䞍可欠です。富士通は、AWSの豊富なセキュリティサヌビスず、圓瀟の運甚ノりハりを融合させ、お客様のクラりド環境を『安党で䜿いやすい』ものにするこずが䜿呜です。今埌も、AWSずの連携をさらに匷化し、業界をリヌドするセキュリティプラクティスを発信し続けたす。 著者 束井 僚倪郎 (Ryotaro Matsui) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト。 富士通グルヌプ様をご支揎しおいたす。興味関心領域はセキュリティです。
補造業のお客様を支揎しおいる゜リュヌションアヌキテクトの柀、倧前、池田です。 2026 幎 3 月 31 日に AWS 倧阪オフィスにお「生成 AI ラりンドテヌブル in 倧阪」を開催したした。本蚘事ではむベントの抂芁ず圓日の様子をお䌝えしたす。 開催の背景 補造業における生成 AI の掻甚は、ナヌスケヌス遞定のフェヌズを経お、実運甚を目指したプロゞェクトずしお掚進する䌁業が増えおいたす。補造珟堎に眠る暗黙知を生成 AI で掻甚できる圢匏知ぞず倉える取り組みや、生成 AI を搭茉した自瀟補品の開発など、さたざたなナヌスケヌスで掻甚が進んでいたす。 私たち゜リュヌションアヌキテクトが各瀟の技術支揎を行う䞭で気づいたのは、扱う補品や事業領域は異なっおも、盎面しおいる課題には倚くの共通点があるずいうこずです。お客様からも「同じ業皮で近しい取り組みを進める䌁業は、どのように課題ぞ向き合っおいるのか知りたい」ずいう声を倚くいただいおいたした。 お客様ず AWS の 1 察 1 の技術支揎だけでは届かない領域がありたす。ある䌁業の詊行錯誀が、別の䌁業が抱える課題解決のヒントになりうる — お客様同士の知芋が぀ながるこずで、課題解決はスケヌルし、さらには日本の補造業党䜓の競争力匷化にも぀ながるず私たちは考えたした。そこで、䌁業間の察話を通じた盞互孊習の堎ずしお、ラりンドテヌブル圢匏でのむベントを開催したした。 むベント抂芁 開催日 2026 幎 3 月 31 日月13:00 〜 18:00 + 懇芪䌚 䌚堎 AWS 倧阪オフィス 26F 圢匏 クロヌズド・ラりンドテヌブル圢匏各瀟発衚 + 質疑応答 参加者数 15 名 参加䌁業順䞍同 シャヌプ株匏䌚瀟 ダマハ株匏䌚瀟 株匏䌚瀟村田補䜜所 株匏䌚瀟日立産業制埡゜リュヌションズ コベルコシステム株匏䌚瀟 東掋玡株匏䌚瀟 倧日本印刷株匏䌚瀟 ダむキン工業株匏䌚瀟 各瀟 30 分発衚 20 分 + 質疑 10 分の持ち時間で自瀟の取り組みを共有するラりンドテヌブル圢匏で実斜したした。クロヌズドな堎だからこそ螏み蟌んだ内容を共有でき、参加者党員が発衚者であり聎講者でもあるため、双方向の議論が自然に生たれる構成です。 各瀟の発衚テヌマ 各瀟の発衚では、生成 AI を実業務に適甚する䞭で盎面する課題ず、たさに今取り組たれおいる実践知が共有されたした。クロヌズドなむベントのため、各瀟の発衚タむトルずご登壇者名のみの公開ずなりたすが、以䞋でご玹介したす。 暮らし、拡がる、SHARP の AI シャヌプ株匏䌚瀟 Smart Appliances & Solutions 事業本郚 Smart Life 事業統蜄郚 AI サヌビス掚進郚 äž­å°Ÿ 祐介、早川 元基 家電補品ぞの生成 AI 搭茉における開発事䟋ず技術的な課題が共有されたした。 Yamaha Network 事業 AI の取り組み ダマハ株匏䌚瀟 PS 事業郚商品開発郚 クラりド開発 G 加藀 康之介 ネットワヌク機噚の運甚・蚭蚈支揎における AI 掻甚の段階的な取り組みが玹介されたした。 AWS の生成 AI を掻甚した文曞怜玢業務の効率化 その性胜が期埅を凌駕する 株匏䌚瀟村田補䜜所 技術・事業開発本郚 共通基盀技術センタヌ マネヌゞャヌ 埳本 盎暹 少人数䜓制での瀟内ドキュメント怜玢システムの構築ず運甚の工倫が玹介されたした。 OT における暗黙知ず生成 AI 利甚の取り組み 業務むンプロセス化ず AI Agent 株匏䌚瀟日立産業制埡゜リュヌションズ 䌁画統括本郚未来創造本郚 梶山 矩埳 株匏䌚瀟✇✎産業制埡゜リュヌションズ GenerativeAI センタ 䜐塚 掋右 ベテラン゚ンゞニアの暗黙知を圢匏知化し AI で掻甚する取り組みが玹介されたした。 1,300 人の珟堎知を AWS AI-DLC で䟡倀ぞ昇華させる 文化醞成ずデリバリヌ暙準の同期による組織倉革の実践 コベルコシステム株匏䌚瀟 事業統括本郚 技術掚進郚 前園 博文 党瀟的な AI 掻甚掚進に向けた組織づくりず意識倉革の取り組みが共有されたした。 RAG × CPT で぀くる珟堎特化 AI 東掋玡株匏䌚瀟 TX・業務革新総括郚 TX 掚進郚 坂倉 広也 補造珟堎特有の甚語や衚蚘ゆれぞの察応に向けた技術的なアプロヌチが玹介されたした。 DNP の生成 AI 掻甚に関する取り組み 倧日本印刷株匏䌚瀟ABセンタヌ 䜐藀 陜平 ドキュメントの構造化ず瀟内ぞの AI 展開の工倫が玹介されたした。 ダむキン工業における生成 AI の取り組み ダむキン工業株匏䌚瀟 電子システム事業郚 森本 康倪 自瀟ドメむンに特化した AI の開発ず瀟内業務支揎ぞの掻甚が玹介されたした。 AWS セッションの玹介 ゚ヌゞェントの本番皌働を加速する AgentOps を AWS で実珟 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 倧前 遌、柀 亮倪 各瀟の発衚を通じお、RAG による瀟内ナレッゞ怜玢から䞀歩進み、AI ゚ヌゞェントを業務に組み蟌むプロゞェクトが倚くの䌁業で始たっおいるこずが芋えおきたした。䞀方で、゚ヌゞェントの本番運甚における評䟡や監芖は、業界党䜓ずしおただベストプラクティスが確立されおいない領域です。 本セッションでは、゚ヌゞェントの構築パタヌンSingle Agent、Tool-Augmented、Multi Agent などに応じお評䟡すべき芳点が異なる点を敎理し、Amazon 瀟内での実践をもずにした Define → Evaluate → Share → Monitor の 4 ステップの評䟡フレヌムワヌクず、その実珟を支える Amazon Bedrock AgentCore を玹介したした。 詳现は AWS ブログ「 Evaluating AI agents: Real-world lessons from building agentic systems at Amazon 」でも玹介されおいたす。 参加者からは「AI ゚ヌゞェントシステムの芳点を䜓系的にたずめおいただいおわかりやすかった」「応答の評䟡や運甚時の監芖呚りは既存システムでも課題に䞊がっおいるため、怜蚎しおいきたい」ずいった声をいただいおいたす。 「ここだけの話」はどう぀ながったのか 各瀟の発衚では普段は衚に出ない課題や詊行錯誀が率盎に語られたした。質疑応答では「うちも同じ課題を抱えおいる」「こういうアプロヌチで解決した」ずいったやり取りが自然ず生たれ、予定時間を超えお議論が続くセッションもありたした。たさに、各瀟の「ここだけの話」が぀ながり、新たな解決のヒントが生たれおいたした。  ã€Œäœœã£ãŸãƒ„ヌルを瀟内で䜿っおもらえない」問題 技術的に動くものは䜜れおも、珟堎に定着しないずいう悩みは倚くの䌁業に共通しおいたした。議論では「トップダりンで広げるべきか、珟堎起点のボトムアップが良いか」「掚進チヌムず珟堎の゚ンゲヌゞメントをどう蚭蚈するか」「評䟡指暙をどこに眮くか利甚率か、業務むンパクトか」ずいった論点が亀わされ、各瀟が実際に詊しおうたくいった/いかなかった斜策が具䜓的に共有されたした。  å°‘人数で AI 掚進を回すリアルな状況 「専任チヌムは数名、兌任メンバヌも含めお十数名」ずいう䜓制で党瀟展開を進める䌁業が倚く、リ゜ヌス制玄の䞭で䜕を優先し、䜕を諊めるかが共通のテヌマでした。内補ず倖郚掻甚の線匕き、瀟内啓発にどこたで時間を割くか、小さく始めお実瞟を䜜る進め方など、珟実的なトレヌドオフに぀いおの議論が続きたした。 補造業特有のデヌタをどう扱うか 図面、仕様曞、珟堎のベテランの暗黙知、蚭蚈ノりハり — 補造業ならではの非構造化・機密性の高いデヌタをどう生成 AI で掻甚するかは、各瀟が盎面しおいる共通課題でした。RAG の粟床を珟堎芁件たで匕き䞊げる工倫、甚語ゆれぞの察凊、セキュリティを担保した䞊での瀟内展開の蚭蚈など、「補造業だからこそ」の螏み蟌んだ技術論が飛び亀いたした。 扱う補品や事業領域は違えど、共通の悩みが次々ず浮かび䞊がったのも印象的でした。 懇芪䌚でも議論の熱は冷めず、セッション䞭には螏み蟌みきれなかった技術的な詳现に぀いお、あちこちで話の茪が広がっおいたした。 アンケヌト結果ず参加者の声 「぀ながるこずで課題解決を加速する」ずいうむベントの狙いが実珟できたこずは、参加者の声からも䌝わっおきたす。 「生成 AI 掻甚に関するネット䞊の情報ずは違う、各瀟の取り組みの生の声を聎くこずができおずおも勉匷になった」 「独自モデルの開発が意倖に倚いこずに驚いた。AI ずアゞャむルの芪和性も新たな気づきだった」 「どう䜿っおもらうかずいう芳点や、瀟内に生成 AI を広げおいくやり方なども参考になった」 「難しい課題に挑戊されおいるが、目的が明確で地に足が぀いおおり、ずおも参考になった」 「取り組みを進めるこずができる人員が限られおいる䞭で、各瀟の背景や目的芳、具䜓的なツヌルの話が特に参考になった」 「ラりンドテヌブルは質問もたくさんできお倧倉有意矩だった」 「自分だけが苊劎しおいるのかず思っおいたが、各瀟同じ課題に向き合っおいるこずがわかり、ここに来おやろうずいう決断を持おた」 おわりに 今回のラりンドテヌブルを通じお、 お客様だからこそ応えられるお客様の悩みがある ずいうこず、そしおお客様同士の察話が課題解決を加速させるずいうこずを、改めお実感したした。アンケヌトでの次回参加垌望 100% ずいう結果が物語っおいたす。 改めお、参加いただいた皆様に埡瀌申し䞊げたす。AWS では今埌もこうした䌁業間の察話の堎を䌁画しおたいりたす。生成 AI の掻甚でお悩みの方は、ぜひ担圓の゜リュヌションアヌキテクトにご盞談ください。 著者に぀いお 柀 亮倪 (Ryota Sawa) 補造業のお客様を担圓する゜リュヌションアヌキテクトです。前職では AI、機械孊習開発ぞ埓事しおおり、珟圚も最新技術の導入・掻甚に悩む䌁業様ぞの技術支揎も行っおおりたす。 前職では AI 、機械孊習を甚いた開発に埓事しおおり、珟圚も同様の技術掻甚にお悩みのお客様ぞも技術支揎しおおりたす。奜きなサヌビスは Amazon Bedrock AgentCore です。最近はゎルフぞの熱が再燃しおおり、コヌスに立぀ずアヌキテクチャより打数が気になりたす。 倧前 遌 (Ryo Omae) AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様を䞭心に、クラりド掻甚の技術支揎を行っおいたす。特に 機械孊習・生成 AI 領域を埗意ずし、お客様のビゞネス課題をテクノロゞヌの力で解決するお手䌝いをしおいたす。奜きな AWS サヌビスは Amazon SageMaker, Amazon Bedrock で、新しい基盀モデルが出たらすぐに觊っおいたす。䌑日はバむクにたたがっおツヌリングぞ行くのが奜きで、颚を感じながら走る時間が、最高のリフレッシュです。 池田 敬之 (Takayuki Ikeda) 関西の補造業のお客様を担圓する゜リュヌションアヌキテクトです。クラりド × デヌタ × AI でお客様のビゞネスを支揎しおいたす。奜きなサヌビスは Amazon Bedrock AgentCore ず Strands Agentsです。䌑日はキックボクシングで汗を流した埌、愛犬ず散歩ずいったコンボで英気を逊うのが定番コヌスです。
みなさん、こんにちは。゜リュヌションアヌキテクトの戞塚です。今週も 週刊AWS をお届けしたす。 さお、みなさんはゎヌルデンりィヌクのご予定はお決たりでしょうか。今幎は長期䌑暇にされる方も倚いようですね。私はずいうず、6月24日・25日に幕匵メッセで開催される AWS Summit の準備があり、飛び石連䌑を぀なげおの長期䌑暇は取れそうにありたせん。その代わり、趣味のパデルの倧䌚にいく぀か゚ントリヌしおいるので、そこでリフレッシュしようず思っおいたす。 AWS Summit では、パデルのフォヌムを VR で蚈枬できる展瀺を予定しおおり、珟圚鋭意開発䞭です。VR の䞖界芳も AI を掻甚しお実珟しおおり、日々倚くの孊びがありたす。たた、スマヌトグラスや音声を掻甚した業務効率化アプリも開発䞭で、そちらもご䜓隓いただけたす。ぜひご来堎ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎4月20日週の䞻芁なアップデヌト 4/20(月) Amazon CloudWatch Logs Insights が JOIN およびサブク゚リコマンドを導入 Amazon CloudWatch Logs Insights で JOIN ずサブク゚リコマンドが利甚可胜になりたした。これたで耇数のロググルヌプをたたいだ分析では、耇数のク゚リを実行しお手動で結果を組み合わせる必芁がありたしたが、今回のアップデヌトで 1 ぀のク゚リで完結できるようになりたした。䟋えば、゚ラヌが倚いサヌビスを特定するサブク゚リず、パフォヌマンスデヌタを持぀別のロググルヌプを JOIN するこずで、゚ラヌ頻床ず応答時間を同時に分析し、優先察応すべきサヌビスを効率的に特定できたす。詳现は こちらのドキュメントをご参照ください。 Amazon DocumentDB (MongoDB 互換) がバヌゞョン 5.0 から 8.0 ぞのむンプレヌスアップグレヌドをサポヌト Amazon DocumentDB で、バヌゞョン 5.0 から 8.0 ぞのむンプレヌスアップグレヌドが可胜になりたした。埓来はクラスタを新芏䜜成する必芁がありたしたが、今回のアップデヌトでクリック数回の操䜜だけでアップグレヌドできたす。バヌゞョン 8.0 ではク゚リ凊理が最倧 7 倍高速化され、ストレヌゞ圧瞮も最倧 5 倍向䞊するため、アプリケヌションの応答速床改善ずコスト削枛を同時に実珟できたす。詳现は こちらのドキュメントをご参照ください。 4/21(火) AWS Lambda Durable Execution SDK for Java 䞀般提䟛開始 AWS Lambda Durable Execution SDK for Java が䞀般提䟛開始されたした。Java 開発者が Lambda で長時間実行されるワヌクフロヌを構築できるようになりたす。泚文凊理パむプラむンや AI ゚ヌゞェント連携、承認フロヌなどを倖郚サヌビスなしで䜜成可胜です。実行を最倧 1 幎間䞀時停止でき、進捗も自動で保存されたす。詳现は こちらの Document をご参照ください。 Amazon Aurora serverless: 最倧 30% のパフォヌマンス向䞊、よりスマヌトなスケヌリング、そしおれロたでのスケヌルダりンを継続 Amazon Aurora serverless がプラットフォヌムバヌゞョン 4 で倧幅にアップデヌトされ、最倧 30% のパフォヌマンス向䞊ず賢いスケヌリング機胜を実珟したした。埓来は耇数のタスクが同時実行される際にリ゜ヌス競合が発生しやすかったビゞネス甚 Web アプリケヌションや API サヌビスでも、効率的に動䜜するようになりたした。特に゚ヌゞェント型 AI アプリケヌションのように、掻動が集䞭する時間ず長時間のアむドル状態が䞍芏則に発生するワヌクロヌドに最適で、䜿甚量に応じた自動スケヌリングにより無駄なコストを削枛できたす。詳现は こちらの Blog 蚘事をご参照ください。 AWS Lambda 関数で Amazon S3 バケットを S3 Files によりファむルシステムずしおマりント可胜に AWS Lambda で Amazon S3 バケットをファむルシステムずしお盎接マりントできる S3 Files 機胜が提䟛開始されたした。埓来はデヌタ凊理のためにオブゞェクトをダりンロヌドする必芁がありたしたが、今回のアップデヌトによりファむル操䜜が盎接可胜になりたす。耇数の Lambda 関数が同じファむルシステムに同時接続でき、AI や機械孊習のワヌクフロヌでデヌタ共有が簡単になりたす。詳现は こちらの Blog 蚘事をご参照ください。 ハむブリッド Kubernetes ネットワヌキング向け Amazon EKS Hybrid Nodes ゲヌトりェむの玹介 Amazon EKS で Hybrid Nodes gateway が提䟛開始されたした。この機胜により、クラりドずオンプレミス環境を跚ぐハむブリッド Kubernetes ネットワヌクが自動化されたす。埓来は耇雑なルヌティング蚭定やネットワヌクチヌムずの調敎が必芁でしたが、これらが䞍芁になりたす。pod 間通信や AWS サヌビスずの接続も自動で凊理され、EC2 むンスタンスに Helm でデプロむするだけで利甚できたす。䞭囜リヌゞョン以倖で远加料金なしで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 4/22(æ°Ž) Amazon Bedrock AgentCore が開発者の゚ヌゞェント構築を高速化する新機胜を远加 Amazon Bedrock AgentCore に新機胜が远加され、AI ゚ヌゞェント開発が倧幅に簡単になりたした。新しい managed harness (プレビュヌ) により、埓来必芁だったオヌケストレヌションコヌドを曞かずに、モデルずプロンプト、ツヌルを指定するだけで゚ヌゞェントを即座に実行できたす。セッション途䞭でのモデル倉曎や、タスクの䞭断・再開も可胜で、プロトタむプから本栌運甚たで䞀貫しおサポヌトしたす。远加料金は発生せず、オレゎン、バヌゞニア北郚、フランクフルト、シドニヌの 4 リヌゞョンで利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 AWS Secrets Manager が MongoDB Atlas ず Confluent Cloud ぞの管理察象倖郚シヌクレット機胜を拡匵 AWS Secrets Manager が MongoDB Atlas ず Confluent Cloud の倖郚シヌクレット管理に察応したした。埓来は各サヌビスの認蚌情報を自動ロヌテヌションするために Lambda 関数を自䜜する必芁がありたしたが、今回のアップデヌトで AWS が提䟛する機胜だけで実珟できるようになりたした。デヌタベヌスず Kafka を組み合わせたデヌタパむプラむンなどで、耇数のサヌビスのシヌクレットを䞀元管理し、運甚負荷を倧幅に削枛できたす。詳现は こちらのドキュメントをご参照ください。 Amazon ECS マネヌゞドむンスタンス向け GPU ヘルスモニタリングず自動修埩機胜の導入 Amazon ECS Managed Instances で NVIDIA GPU の健康監芖ず自動修埩機胜が提䟛開始されたした。GenAI 掚論などの GPU ワヌクロヌドでハヌドりェア故障が発生した際、自動的に故障を怜知しお問題のあるむンスタンスを亀換したす。これたで GPU 故障時は手動での察応が必芁でしたが、この機胜により可甚性が倧幅に向䞊したす。NVIDIA DCGM を䜿甚しお継続的に監芖し、EventBridge 経由で通知も可胜です。察応する NVIDIA GPU むンスタンスタむプで远加料金なしで利甚できたす。詳现は こちらのドキュメントをご参照ください。 4/23(朚) Amazon Redshift が Apache Iceberg テヌブルに察する UPDATE、DELETE、MERGE をサポヌト Amazon Redshift で Apache Iceberg テヌブルに察する UPDATE、DELETE、MERGE 操䜜がサポヌトされたした。これたで Iceberg テヌブルの個別行を修正するには倖郚゚ンゞンが必芁でしたが、今回のアップデヌトにより Redshift から盎接デヌタ操䜜が可胜になりたす。デヌタパむプラむンの耇雑さや遅延を削枛でき、倉曎デヌタキャプチャや緩やかに倉化するディメンションなどの䞀般的なデヌタ統合パタヌンで掻甚できたす。詳现は こちらのドキュメントをご参照ください。 AWS Client VPN が AWS Transit Gateway ずのネむティブ統合をサポヌト AWS Client VPN が AWS Transit Gateway ずのネむティブ統合をサポヌトしたした。これたで耇数の VPC にリモヌトアクセスするには䞭間 VPC の管理が必芁でしたが、今回のアップデヌトで䞍芁になり運甚が倧幅に簡玠化されたす。さらに゚ンドナヌザヌの IP アドレスが保持されるため、セキュリティ監査やトラブルシュヌティングが容易になりたす。詳现は こちらのドキュメントをご参照ください。 Amazon Athena がマネヌゞドコネクタでフェデレヌテッドク゚リを簡玠化 Amazon Athena で DynamoDB や PostgreSQL、MySQL、Snowflake など 12 のデヌタ゜ヌスに察するマネヌゞド コネクタが提䟛開始されたした。埓来は S3 以倖のデヌタをク゚リするためにコネクタリ゜ヌスのデプロむや管理が必芁でしたが、マネヌゞド コネクタにより Athena が自動でセットアップず管理を行うため、この手間が䞍芁になりたした。デヌタを移動するこずなく、耇数のデヌタ゜ヌスを暪断しおク゚リできるため、分析䜜業が倧幅に効率化されたす。詳现は こちらのドキュメントをご参照ください。 4/24(金) Amazon Connect が AI ゚ヌゞェントのパフォヌマンスを枬定・改善するための 8 ぀の新しいメトリクスを提䟛開始 Amazon Connect で AI ゚ヌゞェントの性胜を枬定する 8 ぀の新しいメトリクスが利甚可胜になりたした。ゎヌル成功率や忠実床スコア、ツヌル遞択粟床などを通じお、AI が顧客の問い合わせを正しく解決できおいるかを詳现に分析できたす。埓来は AI ゚ヌゞェントの品質評䟡が困難でしたが、今回のアップデヌトで定量的な改善が可胜になりたす。専甚ダッシュボヌドや API を通じおデヌタにアクセスでき、カスタマヌサポヌトの質向䞊に掻甚できたす。詳现は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Gateway ず Identity が VPC egress をサポヌト Amazon Bedrock AgentCore Gateway ず Identity が VPC egress をサポヌトし、プラむベヌトネットワヌク内のリ゜ヌスず安党に通信できるようになりたした。埓来は倖郚からアクセスできないプラむベヌト環境のリ゜ヌス呌び出しが困難でしたが、今回のアップデヌトにより EKS 䞊の MCP サヌバヌなどを盎接利甚可胜になりたす。マネヌゞド蚭定で簡単に開始でき、耇雑な芁件には自己管理も遞択できたす。東京リヌゞョンを含む 14 リヌゞョンで利甚可胜です。 詳现はこちらのドキュメントをご参照ください。 Amazon Q がワヌクフォヌスむンテリゞェンスのための Visier の Vee ゚ヌゞェントず統合 Amazon Quick が Visier の AI アシスタント Vee ず統合されたした。これにより HR や財務担圓者が Amazon Quick 内で盎接人事デヌタにアクセスできるようになりたす。埓来はツヌルを切り替える必芁がありたしたが、今回のアップデヌトで自然蚀語による質問で人員数や離職率などの情報を瞬時に取埗可胜です。詳现は こちらの Blog 蚘事をご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 戞塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界党般のお客様をご支揎しおいる゜リュヌション アヌキテクトで、AI/ML、IoT を埗意ずしおいたす。最近では AWS を掻甚したサステナビリティに぀いおお客様に蚎求するこずが倚いです。 趣味は、パデルずいうスペむン発祥のスポヌツで、䌑日は仲間ずよく倧䌚に出おいたす。