AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

3642

本記事は 2025/10/10 に公開された “ Transform Supply Chain Logistics with Agentic AI ” を翻訳したものです。 AI はあらゆるサプライチェーンプロセスを変革する可能性があります。予測分析、モノのインターネット(IoT)、機械学習(ML)などの既存技術は、サプライチェーンの効率性と可視性を向上させましたが、組織は依然として重大な課題に直面しています。今日のサプライチェーン実務者は、地政学的緊張から自然災害に至るまでの複雑なシナリオに対応しながら、複数のシステムに散在するデータを管理しなければなりません。これらの課題は、大きなビジネスインパクトを生み出します。例えば、複雑な組立品で 1 つの締結部品(ボルト・ナット等)が欠けているだけで、納品が数週間遅れ、重大な財務損失と顧客体験の低下を招きます。他のすべてのプロセスが完璧に機能していてもです。エージェンティック AI(サプライチェーンエージェント)は、これらの根強い課題を解決できるでしょうか?このブログでは、Amazon Web Services(AWS)プロフェッショナルサービス(ProServe)が、組織が本番運用可能なレベルのエージェンティック AI ソリューションを実装し、サプライチェーン業務変革をどのように支援しているかを説明します。 サプライチェーンにおけるビジネス価値の機会 生成 AI は、サプライチェーンに大きな影響を与えると考えられています。マッキンゼーによると、サプライチェーンの総コストは運用コストの 3〜4%分、全産業合計で 2,900 億ドルから 5,500 億ドル削減可能とされています。この可能性により、EY(アーンスト・アンド・ヤング) はサプライチェーン組織の 40% が生成 AI 技術に投資していると指摘しています。これは、企業が生成 AI の価値を認識しており、アーリーアダプターがこの技術をサプライチェーンプロセスの中核に採用し始めていることを示しています。 生成 AI は、以下のようなビジネス成果を生み出す可能性があります: 関連する洞察や文書を速く見つけ、サプライチェーン専門家の時間を定型業務から解放し、労働生産性を向上させます。 原材料の状態の可視化と基礎データへの信頼性により過剰在庫を削減し、緊急配送や航空輸送の回数を減らします。 処理の自動化と自動生成される推奨事項により意思決定プロセスを最適化し、専門知識の活用、管理業務、ステークホルダーとの調整を効率化します。 エージェンティック AI システムが協力して複雑なタスクを解決 エージェンティック AI システムとは、独立して動作し、相互作用し、動的な環境で自律的な決定を下すデジタルシステムを指します。これらのシステムは、複数のエージェントを調整し、他の AI システムと通信してタスクを効率的に遂行し、複雑な問題解決と自動化を可能にします。生成 AI はエージェンティック AI システムとエージェントの基盤を提供し、AWS では顧客は Amazon Bedrock AgentCore を利用します。論理ベースの推論と文脈理解を通じて、エージェントはアクションを計画し、他のエージェントと協力し、タスクを効率的に実行し、人間の論理と推論を模倣します。サプライチェーン実務者がしばしば複数のシステムや部門横断的なチームやパートナーを扱うため、AI エージェントを使用することで、組織はより効率的になり、価値を生み出すことができます。 モデルベース、目標ベース、学習ベース、自律型、LLM、エージェンティックエージェントなど、異なるタスクを完了するためのエージェントタイプが増えています。これらのエージェントは、異なる機能を持ち、協力して目的の結果を達成します。例えば、顧客が納品を迅速化することを要求したとします。1 つのエージェントが納品のステータスを確認し、別のエージェントが在庫を確認します。さらに、別のエージェントが迅速化テーブルとコストを確認し、最後のエージェントはすべての情報に基づいて次の推奨アクションをまとめます。これらのエージェンティック機能は、複数のデータソースを組み合わせて、内外の顧客体験を向上させます。さらに、情報をまとめて推奨を行うだけでなく、組織が許可すれば、エージェントがシステム上のデータを更新することができます。 物流における AI エージェント 物流はリアルタイムでのステータス更新の必要性、絶えず変化するビジネス環境、そして異なる形式の複数のシステムとデータソースが存在するため、課題に溢れています。多くの企業は、アラートとプロアクティブなモニタリングでこれらの課題を解決していますが、これらのアラートには文脈情報が不足し、潜在的な解決策を提供せず、問題を 1 か所で解決する事ができません。 ガイドラインとして、AI エージェント(メイン)は物流エージェント、在庫エージェント、補充エージェント、調達エージェントなどの焦点を絞ったペルソナを持つことが推奨されます。これらのエージェントは共通の目標に向かって協力します。AI エージェントチームが協力して作業する様子を図 1 に示します。焦点を絞ったペルソナは、エンドユーザーがエージェント(メイン)の担当タスクを理解しやすくします。また、ユーザーデータアクセスを制限し、エージェントが処理する必要があるデータの量を減らします。特に物流では、倉庫、品質、文書生成、補充、関税/規制コンプライアンス、調達/契約、内部・外部の顧客体験など、様々なタイプのエージェントのユースケースがあります。焦点を絞ったペルソナを定義した後、次のステップは、エージェントが解決するべき問題とデータへのアクセス方法を定義することです。以下では、物流エージェントに焦点を当てます。 図 1: 協力して作業する AI エージェントチーム AWS ProServe が A*STAR 向けに物流エージェントを作成 2024 年 9 月、AWS はシンガポール貿易産業省(MTI)と科学技術研究庁(A*STAR)が設立した 製造セクター AI センター・オブ・エクセレンス (AIMfg)の立ち上げに参加しました。これはシンガポールの国家 AI 戦略 2.0 の一環です。このコラボレーションの最初の取り組みは「物流の未来」の探求に焦点を当てており、AWS ProServe は Amazon Bedrock を活用した物流エージェントを開発しました。 先進再製造技術センター (ARTC)は A*STAR 内の研究機関です。このセンターは航空宇宙、陸上輸送、消費財、バイオメディカル製造、エネルギーの 5 つの主要分野にわたる 96 のコンソーシアムメンバーで構成されています。この組織は、次の 4 つの戦略的テーマで研究開発を推進しています: 次世代製造プロセス 自律型製造 ネットゼロ製造(脱炭素製造) 強靭なバリューチェーン Industry 5.0 の人間中心的、持続可能、強靭な生産を重視する A*STAR ARTC は、プラントチームにエージェンティック AI を提供しています。これにより、仮想 AI エージェントが以下のような機会を創出します: 計画、実行、サプライヤー協業にわたる 組織の知識を集約 し、それを組織の業務 DNA に組み込む 目標駆動型の意思決定を行い、フィードバックループを通じて自己改善し、文脈の認識を維持することで、 自律的に運用する 。 AWS ProServe と共同で、A*STAR ARTC は物流の専門家とデータ分析者向けにカスタマイズされた AI エージェントを開発しました。このインテリジェントシステムにより、サプライチェーンの実務者は以下の項目を実現することができます: リアルタイムデータを集約・統合 します。ERP(基幹業務システム)、TMS(輸送管理システム)、WMS(倉庫管理システム)、顧客向けポータルからデータを収集します。 内部および外部の問い合わせに対して即時かつ正確な回答 を提供します。これにより、手動での検索と照合の作業負荷を最大 50% 削減します。 緊急配送コストを総物流費用の 3〜5%削減 し、逸失収益を軽減します。また、納品から配送までのサイクルを短縮します。 手戻り作業を最小化することで計画担当者の 生産性を向上させ 、例外管理、ネットワーク最適化、戦略的サプライヤー連携に集中できるようにします。 迅速で透明性の高い更新情報と予測到着時刻(ETA)のインサイトを通じて、 顧客満足度を向上 させます。 一時的な効率向上を超えて、この AI 駆動型アプローチは堅牢なデータ戦略を支え、キャパシティプランニングからアフターサービスまでのオペレーションバリューチェーン全体にわたり、物流をスマートで情報に基づく意思決定を促進する触媒として位置づけられます。 物流エージェントの構築アプローチと結果 AWS ProServe チームと A*STAR は協力して、エージェントが解決すべき複数の問題やタスクを定義しました。例えば、出荷最新の情報や影響を受ける発注書のアラートなどです。サプライチェーンの専門家は、自然言語と会話型 AI を使用してデータと対話します。これにより、問い合わせに対して変更、キャンセル、推奨を行うことができます。チームが様々な問題やタスクを定義した後、Amazon Bedrock やその他の AWS サービスを利用して物流エージェントを構築しました。 ビデオ 1:AI エージェント – 問題の定義から実行まで ビデオ 1 に示されているように、物流エージェントの導入により、チームは複数のソース(天気、出荷状況など)からより速く最新の情報を取得し、実行可能な対策についての洞察を得て、問い合わせに対する標準的な回答を受け取ることができます。例えば、ユーザーが発注書の更新を要求し、自然言語で質問を入力します。AI エージェントは質問を理解し、適切なデータソースを識別します。これには、構造化または非構造化データの分析が含まれます。これには、ERP システムや Excel スプレッドシートなどの内部データソース、または港湾のウェブサイトや航空貨物運送業者へのアプリケーション・プログラミング・インターフェース(API)接続などの外部ソースが含まれます。次に、AI エージェントは関連データにアクセスし、自然言語処理を使用して質問に答え、正確な回答を提供します。データ接続とエージェントのセットアップがどのように設定されているかの可視化については、図 2 を参照してください。 図 2:内外のデータへのアクセスを持つエージェントセットアップの例 要約すると、ロジスティクスアナリストは手動で情報を検索し、洞察を導き出したりする必要がなくなり、より戦略的なタスクに集中できるようになりました。これは一つの例ですが、サプライチェーン全体で適用可能な例は多くあり、生成 AI とサプライチェーンエージェントが組織の運営方法を変革しています。AI エージェントは洞察を即座に導き出し、エンドカスタマーの問い合わせに数秒で回答し、セルフサービスの問い合わせを可能にし、カスタマーエクスペリエンスの向上に役立ちます。 まとめ エージェンティック AI 機能は、物流の実務者が日々の業務を遂行し、エンドカスタマーエクスペリエンスを向上させる方法を変革しています。物流 AI エージェントにより、サプライチェーンチームは自然言語で対話し、組織のコンテキストを理解し、適切なデータソースを自動的に識別し、AI 推論を利用して結論を導き出したり、次の最善のアクションを推奨したりすることができます。ビジネス価値を基礎とする取り組みにより、サプライチェーンのあらゆる機能において、生産性の向上、収益の増加、速度の向上、コストの削減、無駄の排除につながる機会があります。エンドカスタマーの要求がさらに厳しくなる中で、この分野のリーダーは、価値を早期に得て、競争優位性に変えることができるでしょう。 この技術を導入する企業は、ビジネス価値をより早く実現し、すぐに競争優位性を獲得できます。AWS のお客様は、Amazon Bedrock サービス群やその他の利用可能なサービスで、今日から構築を始めることができます。変革の旅を加速させたいお客様は、 AWS プロフェッショナルサービス のアカウントエグゼクティブまたは AWS アカウントマネージャーにお問い合わせください。 物流エージェントの初期構築に貢献した Sam Gordon、さらなる開発と継続的なサポートを提供した Annie Naveh、追加のサポートとガイダンスを提供した Emily O’Kelly に特別な感謝を申し上げます。 翻訳は、ソリューションアーキテクトの山本が担当しました。 <!-- '"` --> Joe Pazak Joe Pazak は、アジア太平洋・日本(APJ)のエンドツーエンドのサプライチェーンとデジタルトランスフォーメーションを支援する責任者です。Joe は、需要計画、供給計画、生成 AI、高度な分析、物流、調達をカバーする複数の業界との大規模な変革プロジェクトから、深いサプライチェーンの専門知識をもたらします。彼は顧客を支援することを熱望しており、次世代のサプライチェーンツールとテクノロジーに移行するにつれて、大きなアイデアを考えるよう促します。Joe はシドニーを拠点としています。 Dr. Manuel Baeuml Dr. Manuel Baeuml は、ASEAN の AWS 製造・小売プラクティスをリードしています。Manuel は、スマート製造、顧客体験、サプライチェーンに注目し、製造および小売企業が重要なデジタル機能の定義・構想・実装を支援しています。過去 15 年間、Manuel はアジア太平洋とヨーロッパの業界リーダーと働いてきました。Manuel はシンガポールを拠点としています。
2026 年 2 月 16 日週、私のチームは米国サンノゼで開催された Developer Week で大勢の開発者と会ってきました。ここでは、私の同僚である Vinicius Senger が Renascent Software (リネイセントソフトウェア) に関する素晴らしい基調講演を行いました。Renascent Software とは、アプリケーションを構築して進化させる新たな手法であり、Kiro を使用することで人間と AI が 共同開発者として連携します。他の同僚は、本番環境対応の AI エージェントの構築とデプロイについて話しました。講演後も参加者全員がその場に残り、エージェントメモリ、マルチエージェントパターン、メタツール、フックに関する質疑応答を行いました。実際にエージェントを構築している開発者がこれほど多かったのは、大変興味深いと思いました。 私たちは、今後も開発者向けのサードパーティーカンファレンスで開発者の皆さんと会い、フィードバックをお聞きしたいと思っています。最も長い歴史を持ち、最大の規模を誇る Java エコシステムカンファレンス、 dev/nexus (3 月 4~6 日に米国アトランタで開催) にも参加する予定です。このカンファレンスでは、同僚の James Ward が Spring と MCP を使用した AI エージェントの構築について講演し、 Vinicius Senger と Jonathan Vogel は AI を用いて Java コードをアップグレードするための 10 のツールとヒントについて講演します。これ以外にも、皆さんが AWS とつながることができる場をご紹介していくつもりです。 2026 年 2 月 16 日週のリリース 以下は、2026 年 2 月 16 日週行われたその他の発表の一部です。 Amazon Bedrock の Claude Sonnet 4.6 モデル – Claude Sonnet 4.6 を使用できるようになりました。このモデルは、コーディング、エージェント、専門性を要する作業でフロンティアパフォーマンスを大規模に実現します。Claude Sonnet 4.6 は Opus 4.6 に迫るインテリジェンスを低コストで提供します。タスクをより迅速かつ高品質に完了することが可能になるため、大量のコーディングや知識作業のユースケースに最適です。 第 5 世代 AMD EPYC プロセッサ搭載の Amazon EC2 Hpc8a インスタンス – 最大 40% 優れたパフォーマンス、より広範なメモリ帯域幅、300 Gbps の Elastic Fabric Adapter ネットワークを提供する新しい Hpc8a の使用が可能になりました。コンピューティング集約型のシミュレーション、エンジニアリングワークロード、密結合 HPC アプリケーションを高速化できます。 カスタム Amazon Nova モデル向けの Amazon SageMaker Inference – Amazon SageMaker Inference を使用して、カスタム Nova モデルのデプロイ向けのインスタンスタイプ、自動スケーリングポリシー、同時実行設定をニーズに最も適した方法で構成できるようになりました。 仮想 Amazon EC2 インスタンスでのネストされた仮想化 – 仮想 EC2 インスタンスで KVM または Hyper-V を実行することにより、ネストされた仮想マシンを作成できます。この機能は、モバイルアプリケーション用のエミュレーターの実行、自動車用車載ハードウェアのシミュレーション、Windows ワークステーションでの Windows Subsystem for Linux の実行などのユースケースに利用できます。 Amazon Aurora でのサーバー側暗号化のデフォルト実行 – Amazon Aurora は、AWS 所有のキーを使ってサーバー側の暗号化をすべての新規データベースクラスターにデフォルトで自動適用することで、セキュリティ体制をさらに強化します。フルマネージド型のこの暗号化は、ユーザーに対して透過的なものであり、コストやパフォーマンスへの影響はありません。 AWS GovCloud (米国) リージョンでの Kiro – 政府ミッションに対応する開発チームのために Kiro を使用できるようになりました。規制対象環境で作業する開発者は、必要とされる厳格なセキュリティ管理機能を備えた Kiro のエージェンティック AI ツールを活用できるようになります。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 Introducing Agent Plugins for AWS – オープンソースの Agent Plugins for AWS が、AWS にアプリケーションのデプロイするためのスキルを備えたコーディングエージェントを提供する方法をご覧いただけます。 deploy-on-aws プラグインを使用することで、アーキテクチャ上の推奨事項、コスト見積もり、Infrastructure-as-Code をコーディングエージェントから直接生成できます。 A chat with Byron Cook on automated reasoning and trust in AI systems – AI システムがコードの生成や重要な意思決定を行うときに正しく行動していることを、自動推論を使用して確認する方法について学ぶことができます。AWS における正確性の証明に 10 年を費やしてきた Byron Cook のチームは、これらのテクニックをエージェンティックシステムに適用しています。 Best practices for deploying AWS DevOps Agent in production – 調査機能と運用効率のバランスを維持する DevOps Agent Space を設定するためのベストプラクティスを読むことができます。 Swami Sivasubramanian によると、インシデントを解決し、それらをプロアクティブに防止するフロンティアエージェントである AWS DevOps エージェントは、何千件ものエスカレーションを処理しており、Amazon 内での根本原因特定率は 86% を超えると推定されています。 AWS コミュニティからの記事 私が個人的に気に入っている AWS コミュニティの記事をご紹介します。 Everything You Need to Know About AWS for Your First Developer Job – 開発者として働く最初の 1 週間は、これまで従ってきたチュートリアルのようにはいきません。Ifeanyi Otuonye による、新しい仕事を始める人のための現実的な AWS ガイドを読みましょう。 Let an AI Agent Do Your Job Searching – 就職活動のためのキャリアページのチェックを手動で行っていませんか? AWS ヒーローである Danielle H. は、その作業をユーザーに代わって行う AI エージェントを構築しました。 Building the AWS Serverless Power for Kiro – AWS サーバーレスヒーローに認定されたことのある Gunnar Grosch は、開発ライフサイクル全体で利用できる 25 の MCP ツール、10 のステアリングガイド、構造化された意思決定ガイダンスを統合する Kiro Power を構築しました。 AWS Builder Center に参加して、コミュニティとつながり、知識を共有し、開発をサポートするコンテンツにアクセスしましょう。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 Amazon Nova AI Hackathon – 世界中の開発者とともに、フロンティア基盤モデルを使用して革新的な生成 AI ソリューションを構築しましょう。2026 年 2 月 2 日から 3 月 16 日までの 6 週間にわたるこのチャレンジでは、エージェンティック AI、マルチモーダル理解、UI オートメーション、音声エクスペリエンスなどの 5 つのカテゴリーの賞金 40,000 USD を目指して競い合います。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。今後のイベントには、 アーメダバード (2 月 28 日)、 JAWS Days in Tokyo (3 月 7 日)、 チェンナイ (3 月 7 日)、 スロバキア (3 月 11 日)、 プネ (3 月 21 日) が含まれます。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 2 月 23 日週のニュースは以上です。2026 年 3 月 2 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。
※&nbsp;この投稿はお客様に寄稿いただいた記事です。 開発チームに生成AIアシスタントを導入しても、「どう使えばいいかわからない」という理由で利用が広がらない——これは多くの組織が直面する課題です。 本稿では株式会社 NTTドコモ(以下、ドコモ)の主要な Web サービス提供基盤である『 POPLAR 』において、 Amazon Q Developer を個人利用から組織全体の標準ツールへと展開した実践的なアプローチをご紹介します。 一定規模の開発組織における先行事例の創出、ノウハウの体系化、標準化、そして継続的な改善まで、段階的な取り組みの全体像をお伝えします。 1. 先行利用事例の創出 POPLARでは、Amazon Q Developer の導入後も「どの場面で使うと効果があるかわからない。」という声から利用が伸び悩んでいました。この課題を解消するため、実案件を題材にした先行利用事例の創出に取り組みました。 ■ POPLARで先行事例が特に効いた理由 一定規模な開発組織であるため、“再現可能な成功例”が必要だった Software/Middleware のバージョンアップ案件は影響調査・差分分析の負荷が高く、AI効果が可視化されやすい工程構造だった 成果を共有する文化があり、成功事例が口コミのようにプロジェクト内に広がった こうした背景から、Software/Middleware のバージョンアップ案件を題材に、影響調査・設計・コーディングでAmazon Q Developerを活用しました。その結果、最大で約50%の効率化が確認されています。 図1のとおり、影響調査とコーディングで特に大きな改善が見られました。 (図1:先行開発案件の概要と効率化結果) また、図2のとおり、Amazon Q Developerに対してバージョンアップ作業の前提条件を追加して改修指示をすることで、精度向上が図れました。 (図2:プロンプト活用例) この様な成功事例を明確に示すことで、開発者の信頼向上およびプロジェクト全体での利用拡大が進むきっかけとなりました。 2.プロジェクト全体へのノウハウ共有と利用促進 先行事例で得た知見をプロジェクト全体へ展開するため、Amazon Q Developer を活用する際に必要な情報を体系化し、Amazon Q Developer という新しいツールを使うことに対する心理的障壁を下げる取り組みを進めました。 具体的には以下を整備しています。 (1) Amazon Q Developer 利用ガイドライン 機能概要、開発フェーズ別の活用パターン、利用時の制約事項、アカウント申請フローなど、AmazonQ Developer を利用するための各種ノウハウを整理し、開発チーム全体へ公開。 (2) 環境設定マニュアル(VS Code/サーバ) VS Code のセットアップ、IAM Identity Center 設定、既存リポジトリの取得方法など、利用開始に必要な手順をマニュアル化。 (3) コンテキスト活用ガイド プロジェクト固有のルールや制約事項をコンテキストとして整理し、VS Code に配布。プロジェクト特有の情報を踏まえた高精度な回答を得られる環境を整備。 (4) ユースケース別プロンプト集 実際の利用者からフィードバックを収集し、用途別のプロンプト集として体系化し公開。 説明会やデモの実施により、初めてのメンバーでも迷わず利用開始できる状態を構築しています。 3. Amazon Q Developer のさらなる利用促進に向けた取り組み 一定の利用拡大が進んだ後も、さらなる活用促進のために次の取り組みを実施しております。 (1)開発利用の標準化(生成AI開発ガイドライン) Amazon Q Developer の利用方法を工程別に整理し、生成AI開発ガイドラインとして文書化しました。 ガイドライン適用案件では最大約30%の効率化を達成しています。 また、図3のとおり、工数削減と品質安定を再現可能とする取り組みも進めています。 (図3:標準化効果) (2)MCP Server 連携環境の整備 図4のとおり、複数のMCP Serverと連携できるVS Code環境を整備し、共通設定ファイルや連携アプリを配布しました (図4:MCP Server連携構成) なお、POPLARプロジェクトでは以下のMCP Serverを活用しています。 Core MCP Server AWS Documentation MCP Server AWS CDK MCP Server AWS Knowledge MCP Server POPLAR Atlassian MCP (3)利用状況の可視化と個別フォロー 利用ログを用いて利用状況をダッシュボードにて可視化し、プロジェクトに所属する全メンバーの日次でのユーザ単位の「使用状況(チャット・コード生成行数・サジェスチョン数)」を確認出来る様にしました。また、その情報を活用し、利用が進まないメンバーには個別フォローを実施しています。 4. まとめ 本記事では、POPLAR における Amazon Q Developer の活用をプロジェクト全体へ拡げるための取り組みをご紹介しました。 先行事例の創出から始め、以下の通り段階的に取り組むことで生産性向上と利用拡大を実現しました。 STEP1 小さな成功で信頼を獲得(価値証明) STEP2 ノウハウを体系化して展開(情報共有) STEP3 組織の仕組みとして定着(標準化) 今回の取り組みが Amazon Q Developer を活用した開発の参考になれば幸いです。 今後も Kiro を活用した仕様駆動型開発などと組み合わせ、AWS が提供する生成AIアシスタントを最大限活用しながら、POPLAR のさらなる進化に取り組んでいきます。 第1回:NTT ドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用はこちら 著者について 株式会社 NTTドコモ 情報システム部 デジタルデザイン担当 担当部長 深谷 治男 ( Haruo Fukaya ) 担当課長 小柴 辰久 ( Tatsuhisa Koshiba ) 主査 川口 晃平 ( Kouhei Kawaguchi )
みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、 AWS Builder Center はご存じですか?ハンズオンワークショップで生成 AI やサーバーレスアーキテクチャを実践したり、コード例やチュートリアルで具体的な実装方法を学んだり、AWS Heroes や Community Buildersと繋がって知見を共有したり。さらに、AWS 製品チームへのフィードバックや機能提案もできます。技術記事、ユーザーグループ、実践的なラボまで、ビルダーに必要なリソースが一箇所に集約されている、それが AWS Builder Center です!今週の週刊 AWS で気になったトピックがあれば、Builder Center でさらなる知識の深掘りもいかがですか? それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月16日週の主要なアップデート 2/16(月) Amazon EC2 がネスト仮想化をサポート Amazon EC2 でネスト仮想化がサポートされ、EC2 インスタンス内に更に仮想環境を作成できるようになりました。従来はベアメタルインスタンスでしかネスト仮想マシンを作成できませんでしたが、通常の EC2 インスタンス上でも KVM や Hyper-V を実行可能になります。モバイルアプリのエミュレーター実行や自動車の車載システムシミュレーション、Windows 環境での Linux 実行など、より柔軟な仮想環境構築が可能です。 AWS Backup が AWS 上の SAP HANA に対する PrivateLink サポートを発表 AWS Backup が SAP HANA システム向けに AWS PrivateLink をサポート開始しました。これまで SAP HANA のアプリケーション通信は PrivateLink を使ってプライベートネットワーク経由にできましたが、バックアップ通信はパブリックエンドポイントを経由する必要がありました。今回のアップデートで、バックアップトラフィックもプライベートネットワーク経由でルーティングできるようになり、インターネットを経由しない完全にプライベートな通信が実現します。金融、医療、政府機関など規制の厳しい業界では HIPAA や PCI DSS などのコンプライアンス要件でプライベート通信が求められることが多く、このアップデートによりエンドツーエンドでプライベートなデータ保護戦略を実装できます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB 5.0 での長期サポート (LTS) の発表 Amazon DocumentDB 5.0 で長期サポート (LTS) の提供が開始されました。LTS 版ではデータベースのアップグレード頻度とメンテナンス負荷を大幅に軽減できます。新機能の追加は行わず、重要な安定性とセキュリティパッチのみを適用するため、本番環境での安定運用を重視する企業にとって理想的な選択肢です。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora が保存時のサーバーサイド暗号化をサポート Amazon Aurora で新しく作成するデータベースクラスターに対して、デフォルトで暗号化が自動適用されるようになりました。これまで手動で設定が必要だった暗号化が、今後は新規作成時に自動で有効になります。AWS が管理する暗号化キーを使用するため、コストやパフォーマンスへの影響はありません。セキュリティ設定の手間を省きつつ、データ保護を強化できるのがメリットです。詳細は こちらのドキュメントをご参照ください。 AWS Glue 5.1 が 18 の追加リージョンで利用可能に AWS Glue 5.1 が新たに大阪リージョンを含む 18 のリージョンで利用可能になりました。AWS Glue はサーバーレスなデータ統合サービスで、複数のデータソースからデータを発見・準備・移動・統合できます。AWS Glue 5.1 では Apache Spark 3.5.6 や Python 3.11 への対応により性能とセキュリティが向上し、これまで読み取り専用だった Lake Formation のアクセス制御が書き込み操作にも対応しています。 2/17(火) Claude Sonnet 4.6 が Amazon Bedrock で利用可能に Amazon Bedrock で Claude Sonnet 4.6 が利用可能になりました。このモデルは従来の Claude Sonnet 4.5 から大幅にアップグレードされ、コーディングやエージェント機能、ビジネス業務において優秀な性能を発揮します。企業では表計算作成、コンプライアンス確認、データ要約などの専門的な業務に活用でき、高品質な結果を効率的に得られます。詳細は こちらのリリース記事をご参照ください。 Amazon Connect でエージェントの休暇申請がドラフトスケジュールに含まれるようになりました Amazon Connect でエージェントの休暇申請がドラフトスケジュールに含まれるようになりました。これまでは、特定の日にエージェントがスケジュールされていない理由を確認するのに、別の休暇スケジュールを確認して再調整する必要がありました。このアップデートにより、例えば来月のスケジュール作成時に、普段月〜金で働くエージェントが最初の週にいない理由が休暇取得だとすぐに判明します。スケジュール管理者は公開前にカバレッジ不足を素早く特定し調整できるため、より効率的な運用が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.12 (MySQL 8.0.44 互換) が一般提供開始 Amazon Aurora MySQL の最新バージョン 3.12 が提供開始されました。MySQL 8.0.44 に対応し、セキュリティ強化やバグ修正に加え、可用性が向上しています。既存のデータベースから手動アップグレードまたは自動更新設定が可能で、ダウンタイムを最小限に抑えながら最新機能を利用できます。高いパフォーマンスと安定性を求めるアプリケーションに最適で、全ての Aurora MySQL 対応リージョンで利用可能です。 2/18(水) Amazon OpenSearch Service が Graviton4 (c8g、m8g、r8g) インスタンスのサポートを拡張 Amazon OpenSearch Service で最新の Graviton4 ベース EC2 インスタンス (c8g, m8g, r8g, r8gd) のサポートが拡張されました。Graviton4 は従来の Graviton3 と比べて最大 30% のパフォーマンス向上を実現し、コンピュート集約型、汎用、メモリ集約型ワークロードで最高の価格性能比を提供します。大阪リージョンなど 12 の新しいリージョンでも利用可能となり、より幅広い地域でコスト効率の高い検索・分析処理が可能になります。詳細は こちらの Blog 記事をご参照ください。 Amazon Aurora DSQL が Kiro powers と AI エージェントスキルと統合 Amazon Aurora DSQL が Kiro powers と AI エージェントスキルと統合し、AI エージェントの支援でデータベースアプリケーション開発が大幅に効率化されました。これまで手動で行っていたスキーマ設計や性能最適化を AI がサポートし、開発者は事前知識がなくても安心して Aurora DSQL を活用できます。Kiro IDE でワンクリックインストールでき、Claude や Cursor など主要な AI コーディングエージェントで利用可能です。 AWS Certificate Manager が新しいガイドラインに準拠するため、デフォルトの証明書有効期間を短縮 AWS Certificate Manager (ACM) でパブリック証明書の有効期限が 395 日から 198 日に短縮されました。これは 2026 年のセキュリティ標準強化に先立つ対応で、証明書の更新頻度が上がることでセキュリティが向上します。既存証明書はそのまま利用でき、自動更新も継続されるため追加作業は不要です。さらに、エクスポート可能証明書の価格が約半額に下がり (15 ドル→7 ドル)、コスト削減にもつながります。詳細は こちらのドキュメントをご参照ください。 2/19(木) Amazon EC2 M8i-flex インスタンスが東京リージョンで利用可能に Amazon EC2 M8i-flex インスタンスが東京、ソウル、シンガポール、マレーシア、フランクフルト、カナダ中央リージョンで利用開始されました。Intel Xeon 6 プロセッサを搭載し、従来の M7i-flex と比較して 15% のコストパフォーマンス向上と 2.5 倍のメモリ帯域幅を実現します。PostgreSQL で 30%、NGINX で 60%、AI 深層学習で 40% の性能向上が期待でき、Web アプリケーションやマイクロサービスに最適です。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 G7e インスタンスが東京リージョンで利用可能に Amazon EC2 G7e インスタンスが東京リージョンで利用開始となりました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、従来の G6e と比較して最大 2.3 倍の推論性能を実現します。大規模言語モデル (LLM) や生成 AI モデルの展開に最適で、最大 8 GPU と GPU あたり 96 GB のメモリを提供します。グラフィックス処理と AI 処理の両方が必要な空間コンピューティングワークロードで最高のパフォーマンスを発揮し、マルチモーダル AI アプリケーションの構築がより効率的になります。 2/20(金) Amazon RDS for Oracle が 2026 年 1 月リリース更新と Spatial パッチバンドルをサポート Amazon RDS for Oracle が 2026 年 1 月のリリースアップデート (RU) に対応しました。Oracle Database 19c と 21c 向けのセキュリティ修正が含まれており、データベースの安全性が向上します。また 19c 向けには Spatial Patch Bundle も提供され、地理空間データを扱う Oracle Spatial 機能のパフォーマンスと信頼性が改善されます。メンテナンス時間中の自動アップグレードも設定でき、運用負荷の軽減が可能です。詳細は こちらのドキュメントをご参照ください。 2 月もあと1週間です!このままだんだん暖かくなるといいですね! それでは、また来週! 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩0分のトレーニングルームを構築して、日々励んでいます。
本記事は 2026 年 2 月 23 日 に公開された「 Implement a data mesh pattern in Amazon SageMaker Catalog without changing applications 」を翻訳したものです。 Amazon SageMaker Unified Studio でプロジェクトを作成する際、プロジェクトプロファイルを選択してプロビジョニングするリソースとツールを定義します。Amazon SageMaker Catalog はこれらを使ってデータメッシュパターンを実装します。ただし、プロジェクトと共にプロビジョニングされるリソースを利用したくない場合もあります。たとえば、既存のアプリケーションやデータプロダクトに変更を加えたくない場合などです。 本記事では、現在のデータリポジトリとコンシューマーアプリケーションを変更せずに Amazon SageMaker Catalog でデータメッシュパターンを実装する方法を説明します。 ソリューション概要 本記事では、Amazon SageMaker Catalog 導入前に存在するデータプロデューサーとデータコンシューマーに基づくシナリオをシミュレートします。サンプルデータセットを既存データとしてみなし、AWS Lambda 関数は既存アプリケーションを代替します。実際のデータとワークロードでも同様の構成を利用することが可能です。 次の図は、ソリューションアーキテクチャの主要な構成を示しています。プロデューサーアカウントの Amazon Simple Storage Service (Amazon S3) バケットと AWS Glue Data Catalog で既存のデータリポジトリを表しています。コンシューマーアカウントの Lambda 関数で既存のコンシューマーアプリケーションです。 アーキテクチャで表現されている主要な構成要素は次のとおりです。 Amazon SageMaker ドメインの一部として、プロデューサープロジェクト (プロデューサーアカウント) とコンシューマープロジェクト (コンシューマーアカウント) を作成します。他のリソースとともに、関連付けられたアカウントの各プロジェクトにプロジェクト AWS Identity and Access Management (IAM) ロールが作成されます。 プロデューサーアカウントで、AWS Lake Formation でプロデューサープロジェクトの IAM ロールに既存のデータアセットへのアクセス許可を付与します。 プロデューサープロジェクトから Amazon SageMaker Catalog にデータアセットを公開します。 コンシューマープロジェクトからデータアセットをサブスクライブします。 コンシューマーアカウントで、サブスクライブしたデータアセットにアクセスするために、Lambda 関数がコンシューマープロジェクトの IAM ロールを引き受けるよう設定します。 本アーキテクチャは、次の Amazon Web Services (AWS) のサービスと機能に基づいています。 Amazon SageMaker Catalog でデータと AI を安全に検出、ガバナンス、コラボレーションできます。 Amazon SageMaker Unified Studio はデータを検出して構築するための単一のデータと AI 開発環境です。Amazon SageMaker Unified Studio プロジェクトはデータと AI タスクを実行するための共同作業の境界です。 Amazon SageMaker のレイクハウスアーキテクチャは Apache Iceberg と完全に互換性があります。Amazon S3 データレイク、Amazon Redshift データウェアハウス、サードパーティおよびフェデレーテッドデータソース全体でデータを統合します。 AWS Lake Formation で分析と機械学習のためにデータを一元的にガバナンス、保護、共有できます。 AWS Glue Data Catalog は、データアセットの永続的なメタデータストアです。テーブル定義、ジョブ定義、スキーマ、その他の制御情報が含まれており、AWS Glue 環境の管理に役立ちます。 Amazon S3 は業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。 リソースのセットアップ このセクションでは、ソリューションに必要なリソースと設定を準備します。 3 つの AWS アカウント このソリューションを実行するには 3 つの AWS アカウントが必要で、AWS Organizations の同じ組織に属している必要があります。 プロデューサーアカウント – 公開するデータアセットをホストします コンシューマーアカウント – プロデューサーアカウントから公開されたデータを消費するアプリケーションをホストします ガバナンスアカウント – Amazon SageMaker Unified Studio ドメインを設定する場所です 各アカウントには、2 つの異なるアベイラビリティーゾーンに少なくとも 2 つのプライベートサブネットを持つ Amazon Virtual Private Cloud (Amazon VPC) が必要です。手順については、「 VPC とその他の VPC リソースを作成する 」を参照してください。このソリューションを適用する予定のリージョンで両方の VPC を作成してください。 この例では、独立したガバナンスアカウントを利用していますが、Amazon SageMaker はプロデューサーアカウントまたはコンシューマーアカウントで設定および管理できるため、厳密には必須ではありません。3 つのアカウントを用意できないケースでも、本記事を使用して、現在のデータリポジトリとコンシューマーアプリケーションを変更せずに Amazon SageMaker Catalog でデータメッシュパターンを実装するために必要な主要な設定を理解できます。 プロデューサーアカウントでデータリポジトリを作成する まず、次の手順に従ってサンプルデータセットを作成します。 テキストエディタを開きます。 新しいファイルに次のテキストを貼り付けます。 name,stars oak,3 maple,2 birch,3 willow,4 pine,5 mango,1 neem,2 banyan,5 eucalyptus,3 teak,2 ファイルを trees.csv として保存します。これがサンプルデータファイルです。 サンプルデータセットを作成したら、プロデューサーアカウントに S3 バケットと AWS Glue データベースを作成します。これがデータリポジトリです。 プロデューサーアカウントで S3 バケットを作成し、 trees.csv ファイルをアップロードします。 プロデューサーアカウントで S3 コンソールにアクセスします。 S3 バケットを作成します。手順については、「 汎用バケットの作成 」を参照してください。 作成した trees.csv サンプルデータファイルを S3 バケットにアップロードします。手順については、「 オブジェクトのアップロード 」を参照してください。 プロデューサーアカウントで AWS Glue データベースとテーブルを作成します。 プロデューサーアカウントで Glue コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 Add database を選択します。 Name に collections と入力します。 Description に This database contains collections of statistics for natural resources と入力します。 Create database を選択します。 ナビゲーションペインの Data Catalog で、 Tables を選択します。 Add table を選択します。 テーブル作成のガイド付き手順で、 Step 1: Set table properties に次の入力を行います。 Name に trees と入力します。 Database で collections を選択します。 Description に This table captures ratings data related to the characteristics of various tree species と入力します。 Table format で Standard AWS Glue table (default) を選択します。 Select the type of source で S3 を選択します。 Data location is specified in で my account を選択します。 Include path に s3://&lt;bucket-name&gt;/&lt;prefix&gt;/ と入力します。 &lt;bucket-name&gt; は前の手順で作成した S3 バケットの名前、 &lt;prefix&gt; はアップロードした trees.csv ファイルのオプションのプレフィックスです。 Data format で CSV を選択します。 Delimeter で Comma (,) を選択します。 Next を選択します。 Step 2: Choose or define schema で次のように入力します。 Schema で Define or upload a schema を選択します。 Edit schema as JSON を選択し、ポップアップに次のスキーマを入力します。 [ { "Name": "name", "Type": "string", "Parameters": {} }, { "Name": "stars", "Type": "string", "Parameters": {} } ] Save を選択します。 Next を選択します。 Create を選択します。 コンシューマーアカウントで Lambda 関数を作成する コンシューマーアカウントで Lambda 関数を作成します。データコンシューマーアプリケーションをシミュレートします。まず、コンシューマーアカウントで Lambda 関数に割り当てる IAM ポリシーと IAM ロールを作成します。 コンシューマーアカウントで IAM コンソールにアクセスします。 次のポリシーを使用して IAM ポリシーを作成し、 smus_consumer_athena_execution という名前を付けます。プレースホルダー &lt;AWS_Region&gt; と &lt;AWS_account_ID_number&gt; をリージョンとコンシューマーアカウント ID 番号に置き換えてください。 &lt;workgroup_id&gt; プレースホルダーは後で置き換えます。IAM ポリシー作成の手順については、「 IAM ポリシーの作成 (コンソール) 」を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AthenaExecution", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:GetQueryResults" ], "Effect": "Allow", "Resource": "arn:aws:athena:&lt;AWS_Region&gt;:&lt;AWS_account_ID_number&gt;:workgroup/&lt;workgroup_id&gt;" } ] } AWS Lambda サービス用の IAM ロールを作成し、 smus_consumer_lambda という名前を付けます。AWS マネージドアクセス許可 AWSLambdaBasicExecutionRole と、作成したばかりの smus_consumer_athena_execution という名前のアクセス許可を割り当てます。手順については、「 AWS サービスにアクセス許可を委任するロールの作成 」を参照してください。 Lambda 関数の IAM ロールが配置されたら、コンシューマーアカウントで Lambda 関数を作成できます。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 Create function を選択し、次の情報を入力します。 Function name に consumer_function と入力します。 Runtime で Python 3.14 を選択します。 Change default execution role セクションを展開します。 Execution role で Use an existing role を選択します。 Existing role で smus_consumer_lambda を選択します。 Create function を選択します。 Code タブの Code source で、既存のコードを次のコードに置き換えます。 import boto3 import time sts_client = boto3.client('sts') role_arn = "&lt;role_arn&gt;" session_name = "AthenaQuerySession" catalog = "AwsDataCatalog" database = "&lt;database_name&gt;" workgroup = "&lt;workgroup_id&gt;" query = "select * from "+catalog+"."+database+".trees" def lambda_handler(event, context): # Assume SageMaker Unified Studio project role assumed_role_object = sts_client.assume_role( RoleArn=role_arn, RoleSessionName=session_name ) # Get temporary credentials credentials = assumed_role_object['Credentials'] # Create Athena client using temporary credentials athena = boto3.client( 'athena', aws_access_key_id=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_session_token=credentials['SessionToken'], region_name='eu-west-1' ) # Execute Athena Query response = athena.start_query_execution( QueryString=query, QueryExecutionContext={ 'Database': database, 'Catalog': catalog }, WorkGroup=workgroup ) query_execution_id = response['QueryExecutionId'] # Polling with exponential backoff wait_time = 0.25 # Start with 0.25 seconds max_wait = 8 # Maximum wait time of 8 seconds while True: result = athena.get_query_execution(QueryExecutionId=query_execution_id) state = result['QueryExecution']['Status']['State'] if state in ['FAILED', 'CANCELLED']: raise Exception(f"Query {state}") elif state == 'SUCCEEDED': break elif state in ['QUEUED', 'RUNNING']: time.sleep(wait_time) wait_time = min(wait_time * 2, max_wait) # Double wait time, cap at max_wait # Retrieve results results = athena.get_query_results(QueryExecutionId=query_execution_id) return results Deploy を選択します。 Lambda 関数に提供されたコードには、後で必要な情報を入手した後に置き換えるプレースホルダーがいくつか含まれています。プレースホルダーをまだ置き換えていないので、この時点では Lambda 関数をテストしないでください。 管理者アクセス権を持つユーザーを作成する Amazon SageMaker Unified Studio は、AWS IAM Identity Center ベースのドメインと IAM ベースのドメインという 2 つの異なるドメインタイプをサポートしています。本記事の執筆時点では、IAM Identity Center ベースのドメインのみが複数アカウントの関連付けをサポートしているため、本記事では IAM Identity Center を必要とするこのタイプのドメインを使用します。 ガバナンスアカウントで、IAM Identity Center を有効にし、Amazon SageMaker Unified Studio ドメインを作成および管理する管理ユーザーを作成します。管理者アクセス権を持つユーザーを作成します。 ガバナンスアカウントで IAM Identity Center を有効にします。手順については、「 IAM Identity Center の有効化 」を参照してください。 ガバナンスアカウントの IAM Identity Center で、ユーザーに管理者アクセス権を付与します。IAM Identity Center ディレクトリを ID ソースとして使用するチュートリアルについては、「 デフォルトの IAM Identity Center ディレクトリでユーザーアクセスを設定する 」を参照してください。 管理者アクセス権を持つユーザーとしてサインインします。 IAM Identity Center ユーザーでサインインするには、IAM Identity Center ユーザーを作成したときにメールアドレスに送信されたサインイン URL を使用します。IAM Identity Center ユーザーを使用したサインインのヘルプについては、「 AWS アクセスポータルにサインインする 」を参照してください。 SageMaker Unified Studio ドメインを作成する ガバナンスアカウントで Amazon SageMaker Unified Studio ドメインを作成するには、「 Amazon SageMaker Unified Studio ドメインの作成 – クイックセットアップ 」を参照してください。 ドメインが作成されたら、Amazon SageMaker Unified Studio ポータル (Web アプリケーション) に移動できます。ポータルでは分析と AI のためにデータと設定されたツールを使用できます。後で使用するため、Amazon SageMaker Unified Studio ポータルの URL を保存してください。 ソリューションの手順 前提条件が整ったので、次の 10 個の手順でソリューションを実装できます。 プロデューサーアカウントとコンシューマーアカウントを Amazon SageMaker Unified Studio ドメインに関連付ける まず、プロデューサーアカウントとコンシューマーアカウントを新しく作成した Amazon SageMaker Unified Studio ドメインに関連付けます。プロデューサーアカウントとコンシューマーアカウントをドメインに関連付ける際は、 AWS RAM share managed permission セクションで IAM users and roles can access APIs and IAM users can log in to Amazon SageMaker Unified Studio を選択してください。ステップバイステップの手順については、「 Amazon SageMaker Unified Studio の関連アカウント 」を参照してください。AWS アカウントが同じ組織に属している場合、関連付けリクエストは自動的に承認されます。ただし、AWS アカウントが同じ組織に属していない場合は、ガバナンスアカウントで他の AWS アカウントとの関連付けをリクエストし、プロデューサーアカウントとコンシューマーアカウントの両方で関連付けリクエストを承認します。 2 つのプロジェクトプロファイルを作成する 次に、プロデューサープロジェクト用とコンシューマープロジェクト用の 2 つのプロジェクトプロファイルを作成します。 Amazon SageMaker Unified Studio では、プロジェクトプロファイルは Amazon SageMaker ドメイン内のプロジェクトの上位テンプレートを定義します。プロジェクトプロファイルは、プロジェクトリソースの作成に使用される再利用可能な AWS CloudFormation テンプレートを提供するブループリントのコレクションです。 プロジェクトプロファイルは特定の AWS アカウントに関連付けられます。つまり、プロジェクトが作成されると、プロジェクトプロファイルにリストされているブループリントが関連付けられた AWS アカウントにデプロイされます。プロジェクトプロファイルを使用するには、プロジェクトプロファイルに関連付けられた AWS アカウントでブループリントを有効にする必要があります。 プロデューサープロジェクトプロファイルを作成する プロデューサーアカウントに関連付けられたプロデューサープロジェクトプロファイルを作成します。このプロジェクトプロファイルでプロデューサープロジェクトを作成します。このプロファイルには、IAM ユーザーロールやセキュリティグループなどのプロジェクトリソースを作成する Tooling ブループリントがデフォルトで含まれています。 プロジェクトプロファイルを作成する前に、次の手順を使用してプロデューサーアカウントで Tooling ブループリントを有効にします。 プロデューサーアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Associated domains を選択します。 セットアップ中に作成したドメインを選択します。 Blueprints タブで、 Tooling blueprint セクションの Enable を選択します。次の画像を参照してください。 Virtual private cloud (VPC) でアカウントの VPC を選択します。 Subnets で、異なるアベイラビリティーゾーンの少なくとも 2 つのサブネットを選択します。 Enable blueprint を選択します。 ガバナンスアカウントでプロジェクトプロファイルの作成に進みます。 ガバナンスアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Domains を選択します。 前提条件の一部として作成したドメインを選択します。 Project profiles タブで Create を選択し、次の情報を入力します。 Project profile name に producer-project-profile と入力します。 Project profile creation options で Custom create を選択します。 Blueprints でブループリントを選択しないでください。 Tooling ブループリントはすべてのプロジェクトプロファイルにデフォルトで含まれているためです。 Account で Provide an account ID を選択します。 Account ID にプロデューサーアカウント ID を入力します。 Region で Provide region name を選択し、作業しているリージョンを選択します。 Authorization で Allow all users and groups を選択します。 Project profile readiness で Enable project profile on creation を選択します。 Create project profile を選択します。 コンシューマープロジェクトプロファイルを作成する コンシューマープロジェクトプロファイルも作成し、コンシューマーアカウントに関連付けます。このプロファイルでコンシューマープロジェクトを作成します。コンシューマープロジェクトプロファイルには、データ管理用の AWS Glue データベースとクエリ用の Amazon Athena ワークグループを備えたレイクハウス環境を作成するために必要な LakeHouseDatabase ブループリントが含まれています。 Tooling ブループリントはプロジェクトプロファイルにデフォルトで含まれています。 プロジェクトプロファイルを作成する前に、コンシューマーアカウントで Tooling と LakeHouseDatabase ブループリントを有効にします。 コンシューマーアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Associated domains を選択します。 前提条件の一部として作成したドメインを選択します。 Blueprints タブで、 Tooling blueprint セクションの Enable を選択します。 Virtual private cloud (VPC) でアカウントの VPC を選択します。 Subnets で、異なるアベイラビリティーゾーンの少なくとも 2 つのサブネットを選択します。 Enable blueprint を選択します。 ナビゲーションペインで Associated domains を選択します。 前提条件の一部として作成したドメインを選択します。 Blueprints タブで LakeHouseDatabase ブループリントを選択します。 Enable を選択します。 Enable blueprint を選択します。 コンシューマーアカウントでブループリントが有効になったら、プロジェクトプロファイルの作成に進むことができます。 ガバナンスアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Domains を選択します。 前提条件の一部として作成したドメインを選択します。 Project profiles タブで Create を選択し、次の情報を入力します。 Project profile name に consumer-project-profile と入力します。 Project profile creation options で Custom create を選択します。 Blueprints で LakeHouseDatabase を選択します。 Account で Provide an account ID を選択します。 Account ID にコンシューマーアカウント ID を入力します。 Region で Provide region name を選択し、作業しているリージョンを選択します。 Authorization で Allow all users and groups を選択します。 Project profile readiness で Enable project profile on creation を選択します。 Create project profile を選択します。 SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する Amazon SageMaker Unified Studio では、プロジェクトはドメイン内の境界であり、他のユーザーと協力してビジネスユースケースに取り組むことができます。プロジェクトでは、データとリソースを作成して共有できます。Amazon SageMaker Unified Studio でプロデューサープロジェクトとコンシューマープロジェクトを作成するには、次の手順を使用します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択します。 Create project を選択し、次の情報を入力します。 Project name に Producer と入力します。 Project profile で producer-project-profile を選択します。 Continue を選択します。 Continue を選択します。 Create project を選択します。 Producer プロジェクトを作成したら、 Project overview に表示される Project role ARN をテキストファイルにメモします。次の画像を参照してください。プロジェクトロール名は、プロジェクトロール Amazon Resource Name (ARN) の arn:aws:iam::&lt;account_ID&gt;:role/ に続く文字列です。プロジェクトロール名と ARN の両方を後で使用します。 前の手順を繰り返して Consumer プロジェクトを作成します。 Project name に Consumer と入力し、 Project profile で consumer-project-profile を選択してください。作成後、 Project role ARN をテキストファイルにメモします。プロジェクトロール名は、プロジェクトロール ARN の arn:aws:iam::&lt;account_ID&gt;:role/ に続く文字列です。プロジェクトロール名と ARN の両方を後で使用します。 プロデューサーアカウントから独自データを持ち込む Amazon SageMaker Unified Studio の Producer プロジェクトに独自のデータを持ち込み(取り込み)ます。AWS はこれを実現するためのいくつかのオプションを提供しています。最初のオプションは Amazon SageMaker レイクハウスでの自動オンボーディング(導入)で、データセットの Amazon SageMaker レイクハウスメタデータを Amazon SageMaker Catalog に取り込みます。このオプションでは、新しい Amazon SageMaker Unified Studio ドメインの作成の一部として、または既存のドメインに対して Amazon SageMaker レイクハウスデータをオンボードできます。 Amazon SageMaker レイクハウスデータの自動オンボーディングの詳細については、「 Amazon SageMaker Unified Studio でのデータのオンボーディング 」を参照してください。他のオプションとして、プロジェクトの Data ページと Compute ページを使用するか、GitHub で提供されているスクリプトを使用して、既存のリソースを Amazon SageMaker Unified Studio プロジェクトに持ち込むことができます。 Data ページと Compute ページの使用、またはスクリプトの使用の詳細については、「 既存のリソースを Amazon SageMaker Unified Studio に持ち込む 」を参照してください。本記事では、Amazon SageMaker レイクハウス機能を使用して trees AWS Glue テーブルを Producer プロジェクトにインポートします。 テーブルの Amazon S3 ロケーションを登録する trees テーブルへのきめ細かいアクセス制御に Lake Formation アクセス許可を使用するには、 trees テーブルの Amazon S3 ロケーションを Lake Formation に登録する必要があります。次のアクションを実行します。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Administration で、 Data lake locations を選択します。 Register location を選択し、次の情報を入力します。 S3 URI に s3://&lt;bucket-name&gt;/&lt;prefix&gt;/ と入力します。 &lt;bucket-name&gt; は前提条件で作成した S3 バケットの名前、 &lt;prefix&gt; は前提条件の一部としてアップロードした trees.csv ファイルのオプションのプレフィックスです。 IAM role で AWSServiceRoleForLakeFormationDataAccess を選択します。 Permission mode で Lake Formation を選択します。 Register location を選択します。 Producer プロジェクトロールにデータベースのアクセス許可を付与する Producer プロジェクトに関連付けられた IAM ロールにデータベースアクセスを付与します。このロールはプロジェクトロールと呼ばれ、プロジェクト作成時に IAM で作成されました。 Amazon SageMaker Unified Studio の Producer プロジェクトから AWS Glue Data Catalog の collections データベースにアクセスするには、次のアクションを実行します。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 collections データベースを選択します。 Actions メニューから Grant を選択し、次の情報を入力します。 IAM users and roles で、 Producer プロジェクトのロール名を選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Producer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Database permissions で Describe を選択します。 Grant を選択します。 Producer プロジェクトロールにテーブルのアクセス許可を付与する Producer プロジェクトに関連付けられた IAM ロールに trees テーブルアクセスを付与します。これらのアクセス許可を付与するには次の手順に従います。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Tables and MVs を選択します。 trees テーブルを選択します。 Actions メニューから Grant を選択し、次の情報を入力します。 IAM users and roles で、 Producer プロジェクトのロールを選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Producer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Table permissions で Select と Describe を選択します。 Grantable permissions で Select と Describe を選択します。 Grant を選択します。 IAMAllowedPrincipals の既存のアクセス許可を取り消す アクセスに Lake Formation アクセス許可を適用するには、データベースとテーブルの両方で IAMAllowedPrincipals グループのアクセス許可を取り消す必要があります。詳細については、「 Lake Formation コンソールを使用したアクセス許可の取り消し 」を参照してください。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Permission で、 Data permissions を選択します。 Principal が IAMAllowedPrincipals に設定され、 Resource が collections または trees に設定されているエントリを選択します。次の画像を参照してください。 Revoke を選択します。 revoke と入力します。 再度 Revoke を選択します。 Producer プロジェクトでデータが利用可能であることを確認する Producer プロジェクトで collections データベースと trees テーブルにアクセスできることを確認します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンメニューを選択し、 Producer プロジェクトを選択します。 ナビゲーションペインの Overview で、 Data を選択します。 Lakehouse を選択します。 AwsDataCatalog を選択します。 collections を選択します。 tables を選択します。 trees テーブルの横にある 3 点アクションメニューを選択し、 Preview data を選択します。次の画像を参照してください。 次の画像に示すように、 trees テーブルのデータが表示されます。 Amazon SageMaker Catalog アセットを作成する プロジェクトでアクセス可能であっても、Amazon SageMaker Catalog で trees テーブルを操作するには、データソースを登録して Amazon SageMaker Catalog アセットを作成する必要があります。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Producer プロジェクトを選択します。 プロジェクトページのナビゲーションペインの Project catalog で、 Data sources を選択します。 Create Data Source を選択し、次のように選択します。 Name に collections と入力します。 Data source type で AWS Glue (Lakehouse) を選択します。 Database name で collections を選択します。 Next を選択します。 Next を選択します。 Next を選択します。 Create を選択します。 データソースが作成されたら、 collections データソースページで Run を選択します。これによりメタデータがインポートされ、Amazon SageMaker Catalog アセットが作成されます。 collections データソースの Data source runs タブで、実行が Completed とマークされ、 trees アセットが Successfully created と表示されます。次の画像を参照してください。 Amazon SageMaker Catalog でデータアセットを公開する データアセットを手動で公開することは、他のユーザーがカタログを通じてデータアセットにアクセスできるようにするために実行する必要がある 1 回限りの操作です。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Producer プロジェクトを選択します。 プロジェクトページの Project catalog で、 Assets を選択します。 Inventory タブで利用可能な trees データアセットを選択します。次の画像を参照してください。 (オプション) データソースの作成時に自動メタデータ生成が有効になっている場合、アセットのメタデータ (アセットのビジネス名など) を確認して承認または拒否できます。 Automated Metadata Generation バナーで Accept All または Reject All を選択できます。 Publish Asset を選択します。次の画像を参照してください。 Publish Asset を選択します。 Amazon SageMaker Catalog でデータアセットをサブスクライブする Consumer プロジェクトでデータアセットを消費するには、サブスクリプションリクエストを作成してデータアセットをサブスクライブします。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 Discover メニューで Catalog を選択します。 検索ボックスに trees と入力し、検索から返されたデータアセットを選択します。ステップ 7「Amazon SageMaker Catalog でデータアセットを公開する」で Automated Metadata Generation バナーの Accept All を選択した場合、データアセットには自動メタデータ推奨機能によって生成された別のビジネス名が付けられます。データアセットのテクニカルネームは trees です。次の画像を参照してください。 Subscribe を選択します。 Comment に、 This data asset is needed for model training purposes などの正当な理由を入力します。 再度 Subscribe を選択します。 デフォルトでは、アセットサブスクリプションリクエストにはデータ所有者による手動承認が必要です。ただし、 Consumer プロジェクトのリクエスターが Producer プロジェクトのメンバーでもある場合、サブスクリプションリクエストは自動的に承認されます。サブスクリプションリクエストの承認の詳細については、「 Amazon SageMaker Unified Studio でサブスクリプションリクエストを承認または拒否する 」を参照してください。 サブスクライブしたデータアクセスにアクセスするように Lambda IAM ロールを設定する Lambda 関数がサブスクライブしたデータアセットにアクセスできるようにするには、Lambda 関数が Consumer プロジェクトロールを引き受けることを許可する必要があります。 Consumer プロジェクトの IAM ロール信頼関係を編集します。 コンシューマーアカウントで IAM コンソールに移動します。 ナビゲーションペインの Access management で、 Roles を選択します。 Consumer プロジェクトの IAM ロールを選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Consumer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Trust relationships タブで、 Edit trust policy を選択します。 バックアップのため、既存の信頼ポリシーのコピーをテキストファイルに作成します。 Edit trust policy ウィンドウで、信頼ポリシーの他の既存のステートメントを削除または上書きしないようにしつつ、次のステートメントを既存の信頼ポリシーに追加します。プレースホルダー &lt;account_id&gt; をコンシューマー AWS アカウント ID に置き換えてください。 { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::&lt;account_id&gt;:role/smus_consumer_lambda" }, "Action": [ "sts:AssumeRole" ] } Update policy を選択します。 サブスクライブしたデータアセットへの Lambda 関数のアクセスをテストする Lambda 関数をテストする前に、関数コードと IAM ポリシーのプレースホルダーを置き換える必要があります。置き換える必要があるプレースホルダーは 3 つあります: &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; です。 &lt;role_arn&gt; については、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Consumer プロジェクトのロール ARN という実際の値がすでにあります。次のセクションでは、他のプレースホルダーの値を取得する手順を説明します。 AWS Glue Data Catalog データベース名を取得する Consumer プロジェクトと共に作成された AWS Glue Data Catalog データベースの名前を取得します。次に、この値を使用して consumer_function Lambda 関数コードの &lt;database_name&gt; プレースホルダーを置き換えます。AWS Glue Data Catalog データベース名を取得するには、次の手順に従います。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 プロジェクトページの Overview で、 Data を選択します。 Lakehouse を選択します。 AwsDataCatalog を選択します。 データベースの名前をコピーします。次の画像のように、 glue_db で始まる英数字の文字列である必要があります。 Athena ワークグループ ID を取得する Consumer プロジェクトと共に作成された Athena ワークグループの ID を取得します。次に、この値を使用して consumer_function Lambda 関数コードと smus_consumer_athena_execution IAM ポリシーの &lt;workgroup_id&gt; プレースホルダーを置き換えます。Athena ワークグループ ID を取得するには、次の手順を使用します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 プロジェクトページの Overview で、 Compute を選択します。 SQL analytics タブで project.athena を選択します。次の画像を参照してください。 Workgroup ARN をコピーしてテキストファイルに保存します。Athena ワークグループ ID は、Workgroup ARN の arn:aws:athena:&lt;region&gt;:&lt;account_ID&gt;:workgroup/ に続く文字列です。 smus_consumer_athena_execution IAM ポリシーのプレースホルダーを置き換える smus_consumer_athena_execution IAM ポリシーの &lt;workgroup_id&gt; プレースホルダーを置き換えるには、次の手順を使用します。 コンシューマーアカウントで IAM コンソールにアクセスします。 ナビゲーションペインで Policies を選択します。 検索フィールドに smus_consumer_athena_execution と入力します。 smus_consumer_athena_execution ポリシーを選択します。 Edit を選択します。 &lt;workgroup_id&gt; を前にメモした値に置き換えます。 Next を選択します。 Save changes を選択します。 Lambda 関数コードのプレースホルダーを置き換えてテストする consumer_function Lambda 関数コードの &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; プレースホルダーを置き換え、 trees テーブルのデータにアクセスする関数の機能をテストします。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function を選択します。 Code タブで、 &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; プレースホルダーを前にメモした各値に置き換えます。 Deploy を選択します。 Test タブで、 Event name に mytest と入力します。 Test を選択します。 実行が完了した後に表示される Executing function というタイトルの緑色のバナーで Details を選択します。 実行ログに trees テーブルの内容が報告されます。次の画像を参照してください。 Lambda 関数の実行がタイムアウトで失敗する場合は、次のように関数のタイムアウト設定を変更します。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function を選択します。 Configuration タブで Edit を選択します。 Timeout に 15 秒以上の値を入力します。 Save を選択します。 タイムアウトを増やした後、関数を再度テストします。 クリーンアップ 作成したリソースが不要になった場合は、追加料金が発生しないように削除してください。まず、ガバナンスアカウントで Amazon SageMaker Unified Studio ドメインを削除します。詳細については、「ドメインの削除」を参照してください。 プロデューサーアカウントから AWS Glue collections データベースを削除するには、次の手順に従います。 プロデューサーアカウントで Glue コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 collections データベースを選択します。 Delete を選択します。 Delete を選択します。 プロデューサーアカウントから S3 バケットを削除するには、バケットを空にしてからバケットを削除できます。バケットを空にする方法については、「 汎用バケットを空にする 」を参照してください。バケットの削除については、「 汎用バケットの削除 」を参照してください。 コンシューマーアカウントから Lambda 関数を削除するには、次の手順に従います。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function Lambda 関数を選択します。 Actions メニューを選択し、 Delete function を選択します。 confirm と入力します。 Delete を選択します。 クリーンアップの最後に、コンシューマーアカウントで smus_consumer_lambda という名前の IAM ロールを削除し、次に smus_consumer_athena_execution という名前の IAM ポリシーを削除します。IAM ロールの削除については、「 ロールまたはインスタンスプロファイルの削除 」を参照してください。IAM ポリシーの削除については、「 IAM ポリシーの削除 」を参照してください。 まとめ 本記事では、既存のアプリケーションとデータリポジトリを再設計せずに、データガバナンスのために Amazon SageMaker Catalog を採用する方法について説明しました。Amazon SageMaker Unified Studio で既存のデータをオンボードし、カタログで公開し、Amazon SageMaker Unified Studio プロジェクトのコンテキスト外にデプロイされたリソースからデータをサブスクライブして利用する方法を説明しました。このソリューションは、Amazon SageMaker Catalog でデータメッシュパターンの実装を加速し、組織内でデータを安全に公開、検索、アクセスするのに役立ちます。 詳細については、「 Amazon SageMaker とは 」を参照し、 Amazon SageMaker ワークショップ を実行して、データ、分析、AI の統合エクスペリエンスを試してください。 著者について Paolo Romagnoli Paolo は、AWS のエネルギーおよび公益事業向け Senior Solutions Architect です。エンタープライズソリューションの設計と構築に 20 年以上の経験があり、グローバルなエネルギー企業と協力して、ビジネスと技術のニーズに対応するソリューションを設計しています。テクノロジーに情熱を持ち、ランニングを楽しんでいます。 Joel Farvault Joel は、AWS の Principal Specialist SA Analytics で、エンタープライズアーキテクチャ、データガバナンス、分析に 25 年の経験があります。その経験を活用して、データ戦略と技術基盤についてお客様にアドバイスしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。
2026 年 2 月 16 日、 Amazon Elastic Compute Cloud (Amazon EC2) Hpc8a インスタンスの一般提供についてお知らせしたいと思います。このインスタンスは、最新の第 5 世代 AMD EPYC プロセッサを搭載した新しいハイパフォーマンスコンピューティング (HPC) 最適化インスタンスタイプであり、周波数は最大 4.5 GHz です。Hpc8a インスタンスは、数値流体力学、より高速な設計イテレーションのためのシミュレーション、限られた作業時間内での高解像度気象モデリング、迅速な TTR (Time-to-Results) を必要とする複雑な衝突シミュレーションなど、コンピューティング集約型の密結合 HPC ワークロードに最適です。 新しい HPC8a インスタンスは、前世代の Hpc7a インスタンス よりも最大 40% 優れたパフォーマンス、42% 広いメモリ帯域幅、最大 25% 優れた料金パフォーマンスを実現します。お客様は、コンピューティング集約型のシミュレーションワークロードでの効率的なスケーリングとジョブ完了時間の短縮に役立つ、高いコア密度、メモリ帯域幅、低レイテンシーネットワーキングからメリットを得られます。 Hpc8a インスタンス Hpc8a インスタンスでは、192 個のコア、768 GiB のメモリ、300 Gbps の Elastic Fabric Adapter (EFA) ネットワーキングを利用して、高レベルのノード間通信を大規模に行う必要があるアプリケーションを実行できます。 インスタンス名 物理コア数 メモリ (Gib) EFA ネットワーク帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) アタッチされたストレージ Hpc8a.96xlarge 192 768 最大 300 75 EBS のみ Hpc8a インスタンスは 96xlarge サイズのみで提供されており、コアとメモリの比率は 1:4 です。インスタンス起動時に必要なコアの数をカスタマイズすることで、HPC ワークロード要件に基づいて適切なサイズを設定できます。これらのインスタンスは第 6 世代の AWS Nitro Card も使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。 Hpc8a インスタンスは、 AWS ParallelCluster および AWS Parallel Computing Service (AWS PCS) で使用してワークロードの送信とクラスターの作成を簡素化、または Amazon FSx for Lustre で使用してストレージにミリ秒未満のレイテンシーと 1 秒あたり最大数百ギガバイトのスループットを実現できます。HPC ワークロードで最高のパフォーマンスを達成するため、このインスタンスでは同時マルチスレッド (SMT) が無効化されています。 今すぐご利用いただけます Amazon EC2 Hpc8a インスタンスは、米国東部 (オハイオ) と欧州 (ストックホルム) AWS リージョン で今すぐご利用いただけます。リージョンごとの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 このインスタンスは、 オンデマンドインスタンス および Savings Plan として購入できます。&nbsp;詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で Hpc8a インスタンスをお試しください。詳細については、 Amazon EC2 Hpc8a インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。
AWS New Summit 2025 で Amazon SageMaker AI の Amazon Nova カスタマイズ をリリースして以来、お客様からは Amazon SageMaker Inference でオープンウェイトモデルをカスタマイズする場合と同じ機能を Amazon Nova でも使用したいと伺っていました。また、本番環境のワークロードに必要なインスタンスタイプ、自動スケーリングポリシー、コンテキストの長さ、同時実行設定について、カスタムモデル推論の制御と柔軟性を高めたいという声もお聞きしました。 2026 年 2 月 16 日、Amazon SageMaker Inference でのカスタム Nova モデルサポートの一般提供を発表いたしました。これは、フルランクのカスタマイズされた Nova モデルをデプロイおよびスケールするための、本番環境グレードかつ設定可能で、コスト効率の高いマネージド推論サービスです。 Amazon SageMaker Training Jobs または Amazon HyperPod を使用して Nova Micro、Nova Lite、Nova 2 Lite の各モデルを推論機能付きでトレーニングし、Amazon SageMaker AI のマネージド推論インフラストラクチャを利用してシームレスにデプロイする、エンドツーエンドのカスタマイズジャーニーをご体験いただけるようになりました。 カスタム Nova モデル用の Amazon SageMaker Inference では、 P5 インスタンス の代わりに Amazon Elastic Compute Cloud (Amazon EC2) の G5 および G6 インスタンスを使用した GPU 使用率の最適化、5 分間の使用パターンに基づく自動スケーリング、設定可能な推論パラメータを通じて推論コストを削減できます。この機能により、継続的な事前トレーニング、教師ありのファインチューニング、またはユースケースに合わせた強化ファインチューニングを使用して、カスタマイズされた Nova モデル向けにデプロイできます。また、コンテキストの長さ、同時実行数、バッチサイズに関する詳細設定を設定して、特定のワークロードのレイテンシーとコスト精度のトレードオフを最適化することもできます。 カスタマイズした Nova モデルを SageMaker AI リアルタイムエンドポイントにデプロイする方法、推論パラメータを設定する方法、テスト用にモデルを呼び出す方法を見てみましょう。 SageMaker 推論にカスタム Nova モデルをデプロイする AWS re:Invent 2025 では、Nova モデルを含む一般的な AI モデル向けに Amazon SageMaker AI の新しいサーバーレスカスタマイズ を導入しました。数回クリックするだけで、モデルとカスタマイズ手法をシームレスに選択し、モデル評価とデプロイを行うことができます。トレーニング済みのカスタム Nova モデルアーティファクトが既にある場合は、 SageMaker Studio または SageMaker AI SDK を通じて SageMaker Inference でモデルをデプロイできます。 SageMaker Studio の [モデル] メニューで、お使いのモデル内のモデルで、トレーニング済みの Nova モデルを選択します。 [デプロイ] ボタン、 [SageMaker AI] 、 [新規エンドポイントを作成] を選択して、モデルをデプロイできます。 エンドポイント名、インスタンスタイプ、およびインスタンス数、最大インスタンス数、アクセス許可とネットワークなどの詳細オプション、 [デプロイ] ボタンを選択します。GA の起動時には、Nova Micro モデルの場合は g5.12xlarge 、 g5.24xlarge 、 g5.48xlarge 、 g6.12xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge インスタンスタイプ、Nova Lite モデルの場合は g5.24xlarge 、 g5.48xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge 、Nova 2 Lite モデルの場合は p5.48xlarge を使用できます。 エンドポイントを作成する際には、インフラストラクチャのプロビジョニング、モデルアーティファクトのダウンロード、推論コンテナの初期化に時間がかかります。 モデルのデプロイが完了し、エンドポイントのステータスで [InService] と表示されたら、新しいエンドポイントを使用してリアルタイムの推論を実行できます。モデルをテストするには、 [プレイグラウンド] タブを選択し、 チャット モードでプロンプトを入力します。 SageMaker AI SDK を使用して 2 つのリソースを作成することもできます。1 つは Nova モデルアーティファクトを参照する SageMaker AI モデルオブジェクトで、もう 1 つはモデルのデプロイ方法を定義するエンドポイント設定です。 次のコードは、Nova モデルアーティファクトを参照する SageMaker AI モデルを作成します。 # Create a SageMaker AI model model_response = sagemaker.create_model( ModelName= 'Nova-micro-ml-g5-12xlarge', PrimaryContainer={ 'Image': '123456789012.dkr.ecr.us-east-1.amazonaws.com/nova-inference-repo:v1.0.0', 'ModelDataSource': { 'S3DataSource': { 'S3Uri': 's3://your-bucket-name/path/to/model/artifacts/', 'S3DataType': 'S3Prefix', 'CompressionType': 'None' } }, # Model Parameters 'Environment': { 'CONTEXT_LENGTH': 8000, 'CONCURRENCY': 16, 'DEFAULT_TEMPERATURE': 0.0, 'DEFAULT_TOP_P': 1.0 } }, ExecutionRoleArn=SAGEMAKER_EXECUTION_ROLE_ARN, EnableNetworkIsolation=True ) print("Model created successfully!") 次に、デプロイインフラストラクチャを定義するエンドポイント設定を作成し、SageMaker AI リアルタイムエンドポイントを作成して Nova モデルをデプロイします。このエンドポイントはモデルをホストし、推論リクエストを行うための安全な HTTPS エンドポイントを提供します。 # Create Endpoint Configuration production_variant = { 'VariantName': 'primary', 'ModelName': 'Nova-micro-ml-g5-12xlarge', 'InitialInstanceCount': 1, 'InstanceType': 'ml.g5.12xlarge', } config_response = sagemaker.create_endpoint_config( EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config', ProductionVariants= production_variant ) print("Endpoint configuration created successfully!") # Deploy your Noval model endpoint_response = sagemaker.create_endpoint( EndpointName= 'Nova-micro-ml-g5-12xlarge-endpoint', EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config' ) print("Endpoint creation initiated successfully!") エンドポイントが作成されたら、推論リクエストを送信してカスタム Nova モデルから予測を生成できます。Amazon SageMaker AI は、ストリーミング/非ストリーミングモードのリアルタイム用の同期エンドポイントと、バッチ処理用の非同期エンドポイントをサポートします。 例えば、次のコードはテキスト生成用のストリーミング補完形式を作成します。 # Streaming chat request with comprehensive parameters streaming_request = { "messages": [ {"role": "user", "content": "Compare our Q4 2025 actual spend against budget across all departments and highlight variances exceeding 10%"} ], "max_tokens": 512, "stream": True, "temperature": 0.7, "top_p": 0.95, "top_k": 40, "logprobs": True, "top_logprobs": 2, "reasoning_effort": "low", # Options: "low", "high" "stream_options": {"include_usage": True} } invoke_nova_endpoint(streaming_request) def invoke_nova_endpoint(request_body): """ Invoke Nova endpoint with automatic streaming detection. Args: request_body (dict): Request payload containing prompt and parameters Returns: dict: Response from the model (for non-streaming requests) None: For streaming requests (prints output directly) """ body = json.dumps(request_body) is_streaming = request_body.get("stream", False) try: print(f"Invoking endpoint ({'streaming' if is_streaming else 'non-streaming'})...") if is_streaming: response = runtime_client.invoke_endpoint_with_response_stream( EndpointName=ENDPOINT_NAME, ContentType='application/json', Body=body ) event_stream = response['Body'] for event in event_stream: if 'PayloadPart' in event: chunk = event['PayloadPart'] if 'Bytes' in chunk: data = chunk['Bytes'].decode() print("Chunk:", data) else: # Non-streaming inference response = runtime_client.invoke_endpoint( EndpointName=ENDPOINT_NAME, ContentType='application/json', Accept='application/json', Body=body ) response_body = response['Body'].read().decode('utf-8') result = json.loads(response_body) print("✅ Response received successfully") return result except ClientError as e: error_code = e.response['Error']['Code'] error_message = e.response['Error']['Message'] print(f"❌ AWS Error: {error_code} - {error_message}") except Exception as e: print(f"❌ Unexpected error: {str(e)}") 完全なコード例を使用するには、「 Amazon SageMaker AI での Amazon Nova モデルのカスタマイズ 」をご参照ください。モデルのデプロイと管理に関するベストプラクティスの詳細については、「 SageMaker AI のベストプラクティス 」をご覧ください。 今すぐご利用いただけます カスタム Nova モデル用の Amazon SageMaker Inference は、2026 年 2 月 16 日、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 この機能は、自動スケーリングを使用して EC2 G5、G6、P5 インスタンスで実行される、推論機能を備えた Nova Micro、Nova Lite、Nova 2 Lite モデルをサポートします。使用したコンピューティングインスタンス分のみに対してお支払いいただきます。時間単位の請求で、最小契約はありません。詳細については、 Amazon SageMaker AI の料金ページ をご覧ください。 Amazon SageMaker AI コンソール をぜひお試しいただき、 AWS re:Post for SageMaker 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。
みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週号も盛りだくさんです。開催直前になりますが、2 月 27 日 (金)に「 企業でつかうためのCoding Agent「Kiro」 オンライン勉強会 」が開催されます。まだ申し込み受付中ですのでAI エージェントを活用した開発プロセスの効率化に関心がある方はぜひ参加ください!また 3 月 26 日(木)には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください! それでは 2 月 16 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI事例ブログ「BMW Group が AWS 上のエージェンティック検索でペタバイト規模のデータからインサイトを引き出す」を公開 BMW Group が AWS Professional Services と協力し、Amazon S3 Vectors、Amazon Bedrock、Amazon Bedrock AgentCore を活用したエージェンティック検索ソリューションを構築した事例が紹介されています。20 PB のデータを保有する同社のデータレイクハウスに対し、ハイブリッド検索・網羅的検索・SQL クエリの 3 つのアプローチを AI エージェントが自動的に切り替えることで、技術的な専門知識がなくても自然言語で大規模データからインサイトを引き出せるようになりました。生成 AI を活用してデータ分析の民主化を実現するアーキテクチャの実例として、エージェンティック AI の実装パターンやサーバーレスアーキテクチャによるコスト効率の高い運用方法を学ぶことができます。 AWS生成AI国内事例ブログ「『導入しても使われない』を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化」を公開 三菱電機 電力ICTセンターが、開発者向けエージェント型 IDE「Kiro」の Steering・Powers・MCP の 3 層構造と GitLab を組み合わせ、「AI に聞けばワークフローに沿った開発ができる」というプラットフォームを構築した事例が紹介されています。Issue 作成からブランチ作成、実装、MR 作成、レビューまでの開発フロー全体を Powers に定義し、さらに Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。生成 AI を活用した開発効率化に取り組むユーザーにとって、ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける仕組みづくりや、AI エージェントの振る舞いを組織のルールに沿って制御する具体的な方法を学ぶことができます。 AWS生成AI国内事例ブログ「メック株式会社の事例:Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化」を公開 メック株式会社が Amazon Bedrock AgentCore と Amazon S3 Vectors を活用し、研究業務における情報検索と情報更新を AI エージェントで自動化したソリューションを約 3 週間で構築した事例が紹介されています。情報検索エージェントはユーザーの質問をそのまま検索するのではなく専門知識をもとに最適なクエリを自動生成し、情報更新エージェントは新規情報にコンテキストやメタデータを自動付与することで、経験年数に関わらず高品質な情報アクセスと知的資産の体系的な蓄積を実現しています。生成 AI を活用したエージェント開発に取り組むユーザーにとって、Bedrock AgentCore Runtime のサーバーレスなランタイム環境と Strands Agents を組み合わせた PoC のスモールスタート事例として参考になります。 AWS生成AI国内事例ブログ「小売業界の未来を切り拓く:東芝テックが AWS の AI エージェントを活用した店舗運営支援ソリューションを開発」を公開 東芝テックが Amazon Bedrock と Amazon Bedrock AgentCore、Strands Agents SDK を活用し、POS データや在庫情報、IoT センサーデータを AI エージェントが継続的にモニターして売り場責任者に具体的な推奨アクションを通知する店舗運営支援ソリューションを開発した事例が紹介されています。ベテラン担当者の業務知識を管理画面から自然言語でインプットするだけでノーコードで AI エージェントを開発でき、24 時間 365 日バックグラウンドで稼働することで、経験年数に関わらずデータドリブンな意思決定が可能になります。生成 AI を活用した小売業向けソリューションに取り組むユーザーにとって、AgentCore Runtime によるサーバーレスなエージェント運用や AgentCore Memory による対話の記憶を活かしたパーソナライズなど、実践的なアーキテクチャの参考になります。 ブログ記事「AWS で NVIDIA Cosmos world foundation models を実行」を公開 自律走行車やロボティクス、スマートファクトリーなどのフィジカル AI 開発では、高品質なトレーニングデータの不足が大きな課題となっています。本ブログでは、NVIDIA Cosmos ワールドファウンデーションモデル (WFM) を AWS 上にデプロイし、物理的に妥当性のある合成データを大規模に生成する方法として、Amazon Elastic Kubernetes Service (Amazon EKS) を使ったリアルタイム推論と AWS Batch を使ったバッチ推論の 2 つの本番環境向けアーキテクチャを紹介しています。生成 AI を活用したフィジカル AI の開発に取り組むユーザーにとって、実世界のデータ収集に頼らず合成データで開発サイクルを加速できる具体的な実装パターンを学ぶことができます。 ブログ記事「リファクタリングを正しく行う:プログラム解析により AI エージェントの安全性と信頼性を高める方法」を公開 AI コーディングアシスタントにシンボルの名前変更やファイル移動といったリファクタリングを依頼すると、インポートの破損や参照の欠落が発生しがちですが、本ブログでは開発者向けエージェント型 IDE「Kiro」が IDE の言語サーバーを活用した「セマンティックリネームツール」と「スマートリロケートツール」でこの課題をどう解決するかを解説しています。LLM によるテキストベースの検索置換に頼るのではなく、コードの構造を理解するプログラム解析を組み合わせることで、ワークスペース全体にわたる変更を安全かつ正確に反映でき、リファクタリング後のデバッグ作業を大幅に削減できます。生成 AI を活用した開発に取り組むユーザーにとって、AI エージェントの出力をより信頼できるものにするための「構築による正確性」というアプローチの具体的な実装例として参考になります。 ブログ記事「バグ修正と既存アプリの上に構築するための新しい Spec タイプ」を公開 開発者向けエージェント型 IDE「Kiro」の仕様駆動開発ワークフロー Specs に、「デザインファースト」と「バグ修正」の 2 つの新しい Spec タイプが追加されました。デザインファースト Spec は技術的アプローチがすでに決まっている既存アプリへの機能追加に、バグ修正 Spec は「現在の振る舞い」「期待される振る舞い」「変更されない振る舞い」の 3 セクション構造で外科的な修正を行う場合に適しており、いずれもプロパティベーステストによる検証まで一貫して行えます。生成 AI を活用した開発に取り組むユーザーにとって、新規開発だけでなく既存コードベースの保守・改善においても、AI エージェントと効果的に協働するための実践的なアプローチを学ぶことができます。 ブログ記事「Claude Sonnet 4.6 が Kiro で利用可能になりました」を公開 開発者向けエージェント型 IDE「Kiro」の IDE および CLI で、Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.6 は Sonnet 4.5 からの完全なアップグレードで、Opus 4.6 に匹敵する知能を持ちながらトークン効率が高く、複数ステップのツール呼び出しや長いセッションでのコンテキスト維持など、エージェント作業に特化して構築されています。生成 AI を活用した開発に取り組むユーザーにとって、機能構築やリファクタリング、デバッグなどの反復的な開発ワークフローにおいて、より高速で高品質なタスク完了が期待できるモデルです。 ブログ記事「Kiro のエンタープライズ ID 連携と使用状況メトリクス」を公開 開発者向けエージェント型 IDE「Kiro」が、外部 ID プロバイダー(Okta と Microsoft Entra ID)との連携とユーザーレベルのアクティビティメトリクスをサポートしました。管理者は既存の SSO ポリシーや MFA 適用をそのまま Kiro に適用でき、IDE・CLI・Web アプリ全体でのチーム利用状況をクライアントタイプごとに可視化できるようになります。組織で生成 AI を活用した開発ツールの導入を検討しているユーザーにとって、既存の ID 基盤やコンプライアンス要件を維持しながらチーム全体への展開と利用状況の把握を実現できるエンタープライズ向け機能として注目です。 ブログ記事「エージェンティック・クラウドモダナイゼーション: AWS MCP と Kiro によるモダナイゼーションの加速」を公開 開発者向けエージェント型 IDE「Kiro」と公式の AWS MCP サーバーを統合することで、レガシーシステムのクラウドモダナイゼーションにおける分析・計画・実装の 3 フェーズを自動化し、従来数週間かかっていた評価やアーキテクチャ設計を数日に短縮するアプローチが紹介されています。Kiro が既存コードベースを分析してアーキテクチャ図やドキュメントを自動生成し、AWS Well-Architected Framework に沿ったターゲットアーキテクチャの設計、リアルタイムのコスト見積もり、AWS CloudFormation や AWS CDK 等の Infrastructure as Code の生成まで一貫して行えます。生成 AI を活用したモダナイゼーションに取り組むユーザーにとって、AWS ドキュメント・料金・CDK などの各種 MCP サーバーを組み合わせた具体的なセットアップ方法と実装パターンを学ぶことができます。 ブログ記事「AI で強化された脅威アクターによる FortiGate デバイスへの大規模な不正アクセス」を公開 Amazon Threat Intelligence が、商用生成 AI サービスを活用した脅威アクターが 55 か国以上・600 台超の FortiGate デバイスを侵害したキャンペーンを観測・分析した調査結果が共有されています。技術力の低い脅威アクターでも、AI を活用して攻撃計画の策定やツール開発、認証情報の抽出を大規模に行えるようになった一方、侵害の主因はインターネットに公開された管理インターフェイスと脆弱な認証情報という基本的なセキュリティの欠陥であり、堅実なセキュリティの基本が依然として有効な防御策であることが示されています。AWS を利用するユーザーに対しては、Amazon GuardDuty や Amazon Inspector、AWS Security Hub を活用した脅威検出やセキュリティポスチャの継続的な可視化など、具体的な推奨事項が紹介されています。 サービスアップデート Amazon Bedrock の強化学習ファインチューニングが OpenAI 互換 API でオープンウェイトモデルをサポート Amazon Bedrock の強化学習ファインチューニング(RFT)が、qwen.qwen3-32b や openai.gpt-oss-20b などのオープンウェイトモデルに対応し、OpenAI 互換のファインチューニング API が利用可能になりました。大規模なラベル付きデータセットや深い機械学習の専門知識がなくても、少量のプロンプトセットとルールベースの評価関数や AI ベースのジャッジを使ってモデルをカスタマイズでき、ファインチューニング完了後は追加のデプロイ手順なしに Responses API や Chat Completions API でそのまま推論に利用できます。生成 AI を活用するユーザーにとって、小型で高速かつコスト効率の高いモデルを自社の業務要件に合わせて最適化し、フルマネージドかつセキュアな環境で運用できる選択肢が広がるアップデートです。 Claude Sonnet 4.6 が Amazon Bedrock で利用可能に Amazon Bedrock で Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.5 からの直接アップグレードとして、Opus 4.6 に匹敵する知能を低コストで提供し、コーディング、エージェンティックワークフロー、ブラウザベースの自動化(コンピュータ使用)において高いパフォーマンスを発揮します。生成 AI を活用するユーザーにとって、マルチモデルパイプラインでのリードエージェント・サブエージェント両方の役割を担えるほか、スプレッドシート作成やコンプライアンスレビューなどのエンタープライズ用途にも活用でき、Sonnet 4.5 からの移行も軽微なプロンプト調整のみで対応できます。 Kiro が AWS GovCloud (US) リージョンで利用可能に 開発者向けエージェント型 IDE「Kiro」が、AWS GovCloud (US-East) および AWS GovCloud (US-West) リージョンで利用可能になりました。高いコンプライアンス要件を持つワークロードに対して、スペック駆動開発やドキュメント・ユニットテストの自動生成、ネイティブ MCP サポートによるデータベースや API との連携など、エージェンティック AI 開発の機能が提供されます。AWS IAM Identity Center によるエンタープライズ認証に対応しており、政府機関や規制産業で生成 AI を活用した開発に取り組むユーザーにとって、ミッションクリティカルな開発ワークフローに Kiro を導入できるようになるアップデートです。 今週は以上です。それでは、また来週お会いしましょう! 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。
本記事は 2026 年 2 月 17 日 に公開された「 Use default encryption at rest for new Amazon Aurora clusters 」を翻訳したものです。 データセキュリティはあらゆる規模の組織にとって最優先事項であり、保存データの暗号化は組織のセキュリティ戦略の重要な要素です。保存データの暗号化はストレージレベルでデータを不正アクセスから保護し、誰かが物理的にストレージメディアにアクセスしたとしても、適切な暗号化キーがなければ機密情報を読み取れないようにします。これにより、メディアの盗難や物理ストレージデバイスの不適切な廃棄によるリスクも軽減できます。 GDPR, HIPAA, PCI DSS, SOC 2 などの規制フレームワークでは、機密データの暗号化が求められています。デフォルトの暗号化によりコンプライアンスが簡素化され、コンプライアンス違反によるペナルティのリスクも低減します。 Amazon Aurora の保管時の暗号化により、すべての新しい Aurora クラスターは追加の操作なしにこれらの規制要件を満たせます。 本記事では、Amazon Aurora が、AWS 所有キーを使用してすべての新規データベースクラスターに対しデフォルトで保管時の暗号化を提供するようになったことを学びます。StorageEncryptionType フィールドによる暗号化ステータスの確認方法、新規および既存クラスターへの影響、暗号化されていないデータベースの移行オプションについても解説します。 Amazon Aurora における保管時暗号化 以前は、保管時の暗号化は Aurora クラスター作成時に明示的に選択できるオプション機能でした。create API ではデフォルトで暗号化が無効になっており、 --storage-encrypted パラメータを指定せずに、または --no-storage-encrypted パラメータを指定してクラスターを作成すると、データベースは暗号化されていない状態でした。 今後、すべての新しい Aurora クラスターは AWS 所有キーを使用してデフォルトで暗号化が有効になり、すべての新しいデータベースの顧客データは物理メディア上で常に暗号化されます。暗号化はアプリケーションに対して透過的で、パフォーマンスへの影響はありません。AWS 所有キーによる暗号化 (またはデフォルトの保管時の暗号化) には追加料金は発生しません。 Amazon Aurora での暗号化タイプ キーのタイプは以下のとおりです。 AWS 所有キー (SSE-RDS) – AWS が完全に管理する暗号化キーで、ユーザーは表示や管理ができません。Aurora でのデフォルト暗号化に自動的に使用されます。 AWS マネージドキー (AMK) – AWS が作成・管理するキーで、アカウントで表示できますがカスタマイズはできません。月額料金はかかりませんが、AWS KMS API の料金が適用されます。 カスタマーマネージドキー (CMK) – アカウント内に保存され、ユーザーが作成、所有、管理するキーです。 AWS KMS キーを完全に制御できます (AWS KMS の料金が適用されます)。 StorageEncryptionType 出力フィールド データが保管時に暗号化されているかどうかをより明確に把握できるようにするために、Amazon Aurora はすべての describe API で StorageEncryptionType という追加の出力フィールドを公開するようになりました。このフィールドで設定される値は以下です。 sse-rds (サーバーサイド暗号化): インスタンスやクラスターが AWS 所有キーで暗号化されていることを示します。 sse-kms (AWS マネージドキーまたはカスタマーマネージドキー): インスタンスやクラスターが AWS マネージドキーまたはカスタマーマネージドキーで暗号化されていることを示します。 none : インスタンスやクラスターがデフォルトでは暗号化が無効だった時期に作成され、暗号化されていないことを示します。 AWS 所有キーで新しいクラスターを作成すると、 StorageEncrypted フィールドは false と表示され、 StorageEncryptionType フィールドは sse-rds と表示されます。これは、データベースの暗号化を明示的に選択しなかったものの、AWS 所有キーでデータは保管時に暗号化されていることを示します。 この変更は Aurora クラスターにどのような影響を与えるか この変更による影響は以下です。 新しいクラスター : 設定不要で、AWS 所有キー (sse-rds) により自動的に暗号化されます。 既存のクラスター : 現在の暗号化状態が維持されます。既存のデータベースは自動的に変更されません。 既存の暗号化されていないクラスターの自動バックアップ、スナップショット、クローンは暗号化されないままです。 暗号化されていないクラスターをスナップショットから復元すると、AWS 所有キーで暗号化されます。AWS 所有キーを使用することで、AWS サービスはデータを透過的に暗号化し、キーの共有を気にすることなくクロスアカウントやクロスリージョンでのクラスター共有を容易に実現します。 コンプライアンスやキー管理の目的で KMS ベースの暗号化が必要な場合は、Aurora クラスター作成時にカスタマーマネージドキー (CMK) または AWS マネージドキーを明示的に指定できます。一般的に、リソースを保護する暗号化キーの監査や制御が必要でない限り、AWS 所有キーが適切な選択肢です。 ユースケースと例 Aurora クラスターの保管時暗号化の例とユースケースを紹介します。 ユースケース 1: 新しい Aurora クラスターの作成 シナリオ : --storage-encrypted パラメータを指定せずに、または明示的に --no-storage-encrypted を使用して、新しい Aurora PostgreSQL クラスターを作成します。 結果 : AWS 所有キーを用いたサーバーサイド暗号化 (SSE) がデフォルトで有効な状態でクラスターが作成されます。 --storage-encrypted パラメータを指定しない CLI の例 : aws rds create-db-cluster \ --db-cluster-identifier apgtest1 \ --engine aurora-postgresql \ --master-username postgres \ --master-user-password xxxxxxx 出力 : { "DBCluster": { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } 明示的に --no-storage-encrypted パラメータを指定した CLI の例 : aws rds create-db-cluster \ --db-cluster-identifier apgtest1 \ --engine aurora-postgresql \ --master-username postgres \ --master-user-password xxxxxxx \ --no-storage-encrypted 出力 : { "DBCluster": { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } ユースケース 2: スナップショットからの復元 シナリオ : KMS キーを指定せずに、暗号化されていないクラスターのスナップショットを復元して Aurora クラスターを作成します。 結果 : 復元されたクラスターは、AWS 所有キーを使用したサーバーサイド暗号化 (SSE) が有効な状態で作成されます。 CLI の例 : aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier restored-cluster \ --snapshot-identifier unencrypted-cluster-snapshot \ --engine aurora-postgresql 出力 : { "DBCluster": { "DBClusterIdentifier": "restored-cluster", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } ユースケース 3: クラスターの確認 シナリオ : ユースケース 1 またはユースケース 2 で作成した Aurora クラスターの暗号化ステータスとタイプを確認します。 結果 : 出力に暗号化ステータスが反映されます。ユースケース 1 およびユースケース 2 ではクラスター作成時に --storage-encrypted オプションを指定しなかったため、StorageEncrypted は false と表示されます。 StorageEncryptionType は sse-rds と表示され、データが AWS 所有キーで暗号化されていることが確認できます。 CLI の例 : aws rds describe-db-clusters --db-cluster-identifier apgtest1 出力 : { "DBClusters": [ { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } ] } ユースケース 4: スナップショットの作成 シナリオ A : SSE で暗号化された Aurora クラスターからスナップショットを作成します。 結果 : ソースクラスターと同じ暗号化状態 (SSE) でスナップショットが作成されます。 CLI の例 : aws rds create-db-cluster-snapshot \ --db-snapshot-identifier apgtest1-snapshot \ --db-instance-identifier apgtest1 SSE 暗号化スナップショットの出力 : { "DBClusterSnapshot": { "DBClusterSnapshotIdentifier": "apgtest1-snapshot", "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } シナリオ B : 暗号化されていない Aurora クラスターからスナップショットを作成します。 暗号化されていないスナップショットの出力 (既存のインスタンス): { "DBClusterSnapshot": { "DBClusterSnapshotIdentifier": "old-cluster-snapshot", "DBClusterIdentifier": "old-unencrypted-cluster", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "none" } } AWS コンソールの変更 AWS マネジメントコンソールにも新しいデフォルト暗号化の動作が反映され、より詳細な Aurora クラスターの暗号化ステータスが表示されます。 SSE 暗号化を使用しているインスタンスの場合、コンソールの 暗号化 セクションに AWS 所有 KMS キー と表示されます。これにより、どのタイプの暗号化が使われているかが明確になります。KMS ベースの暗号化を使用しているインスタンスの場合は、 AWS マネージド KMS キー または カスタマーマネージド KMS キー と表示されます。以下のスクリーンショットは、デフォルトキー (AWS 所有キー) で暗号化されたクラスターの設定を示しています。 暗号化オプションを指定したインスタンスの作成 新しいインスタンスやクラスターを作成する際、Aurora コンソールに 3 つの暗号化キーオプションのドロップダウンメニューが表示されるようになりました。 AWS 所有 キー (SSE-RDS) AWS マネージドキー (SSE-KMS) カスタマーマネージドキー (SSE-KMS) 同様に、コンソールでスナップショットを復元する際にも同じ 3 つのオプションが表示され、ユースケースに適した暗号化タイプを選択できます。 暗号化されていない既存のクラスターをどのように SSE または KMS 暗号化に移行するか 暗号化されていない既存データベース (StorageEncryptionType が none) がある場合、SSE または KMS ベースの暗号化を使用するように移行できます。 オプション 1: SSE (AWS 所有キー) を使用してクラスターを暗号化する 暗号化されていないデータベースの スナップショット を作成します 暗号化されていないスナップショットから 復元 して新しいクラスターを作成します アプリケーションの接続先を新しいクラスターのエンドポイントに更新します クラスターがデフォルト (AWS 所有) キーで暗号化されていることを確認します 元の暗号化されていないクラスターを削除します # Create cluster snapshot aws rds create-db-cluster-snapshot \ --db-cluster-identifier original-cluster \ --db-cluster-snapshot-identifier original-cluster-snapshot # Restore from unencrypted snapshot aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier new-encrypted-cluster \ --snapshot-identifier original-cluster-snapshot # Verify your cluster is encrypted with default (AWS owned) keys aws rds describe-db-clusters \ --db-cluster-identifier new-encrypted-cluster \ --query "DBClusters[0].{StorageEncrypted:StorageEncrypted,KmsKeyId:KmsKeyId, StorageEncryptionType:StorageEncryptionType}" \ --output table オプション 2: KMS ベースの暗号化 (CMK または AWS マネージドキー) に移行する オプション 1 と同じ手順で、スナップショット復元時に --kms-key-id を指定します。 # Restore with KMS encryption aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier new-encrypted-cluster \ --snapshot-identifier original-cluster-snapshot \ --kms-key-id arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id まとめ 本記事では、すべての新規 Aurora クラスターで保管時の暗号化がデフォルトで有効になり、追加コストや設定作業無しでセキュリティ強化と簡素化されたコンプライアンスを実現できることを紹介しました。既存データベースの暗号化ステータスを確認し、暗号化されていないデータベースを移行してこの強化されたセキュリティ機能を活用することを推奨します。 著者について Pratibha Shivnani Pratibha は、Amazon Web Services (AWS) の Amazon Aurora チームで Senior Product Manager (テクニカル – 外部サービス) を務めています。彼女は顧客のデータベース体験の簡素化と、強力なデータソリューションを誰もが使いやすくスケーラブルにすることに情熱を注いでいます。 Sukhpreet Kaur Bedi Sukhpreet は、AWS の Senior PostgreSQL Specialist Solutions Architect として、Amazon RDS for PostgreSQL と Aurora PostgreSQL エンジンを担当しています。彼女は、高可用性でスケーラブル、セキュアなデータベースアーキテクチャの構築を支援しています。 翻訳は Technical Account Manager の石渡が担当しました。
新しいスキル測定 “Microcredentials” とは AWS 認定を取得したが、もっと自分のスキルをアピールしたい!全冠の次の目標が欲しい!そんな方に朗報です。 Microcredentials は実践的なスキルを証明する新しい手法として、2025 年 11 月より AWS Skill Builder のサブスクリプションコンテンツとして利用が可能になりました。 Microcredentials は用意されたパフォーマンスベースの Exam Labs* で実践的な課題を解決することで、特定分野におけるスキルの深さを証明します。現在 “Agentic AI” と “Serverless” の 2 つの領域が Microcredentials としてリリース済みです。受験に際して必要な AWS 認定などの前提条件はありません。 実際に直面するであろう現実的な課題のトラブルシューティングを行い、効果的な解決策を実装します。基準を満たして合格すれば AWS 認定と同様に Credly のデジタルバッジが付与されます。今後も技術的なニーズに合わせて Microcredentials を追加していく予定です。ぜひ AWS 認定と合わせて取得ください。 <Microcredentials 操作画面のイメージ> *Exam Labs とは Exam Labsは、AWS が管理する Labs インフラストラクチャ上に構築されています。事前に構成された AWS 環境で、リスクなく様々な AWS サービスやソリューションを試すことができます。利用者は自身の AWS Account を利用せずとも、Exam Labs で提供される AWS 環境を利用することができます。Exam Labs には試験や評価に特化した機能(自動採点、評価基準の設定など)があります。 – AWS 認定との違い – Microcredentials の概要(Agentic AI/Serverless) 受験には AWS Skill Builder のサブスクリプション登録が必要です(参考: サブスクリプションについて ) Microcredentials の受験にあたり、サブスクリプション登録以外の費用は必要ありません 事前の予約は不要 制限時間は 90 分(中断不可) Exam Labs で複数の課題を解決 合格すれば AWS 認定と同様にデジタルバッジが付与されます 不合格の場合、次回は25日経過後から受験が可能 – Microcredentials 受験の流れ ① AWS Skill Builder の トップページ から、マイクロクレデンシャルを選択 – ② 受験したいマイクロクレデンシャルを選択して受験 ※ 一番左の「AWS マイクロクレデンシャル – お試し版」は操作説明のための体験版です。 – デジタルバッジ AWS 認定と同様に Credly で取得可能 – 関連性の高い AWS 認定 Agentic AI AWS Certified Generative AI Developer – Professional – Serverless AWS Certified Developer – Associate まとめ Microcredentials は AWS 認定だけでは証明することが難しい、特定分野におけるスキルの深度を証明できます。ぜひ AWS 認定と合わせて取得いただき、AWS 認定 × Microcredentials の新しいスキル証明を体感ください。 – 著者 トレーニングサービス本部 T&amp;C Certification BDM 両角貴寿(Moro)
本ブログは 2026 年 2 月 20 日に公開された AWS Blog “ AI-augmented threat actor accesses FortiGate devices at scale ” を翻訳したものです。 商用 AI サービスの普及により、技術力の低い脅威アクターでも大規模なサイバー攻撃を実行できるようになっています。Amazon Threat Intelligence はこの傾向を注視しており、最近の調査がその変化を裏付けています。Amazon Threat Intelligence は、ロシア語を話す金銭的動機を持つ脅威アクターが複数の商用生成 AI サービスを活用し、2026 年 1 月 11 日から 2 月 18 日にかけて 55 か国以上、600 台を超える FortiGate デバイスを侵害した事例を観測しました。FortiGate の脆弱性が悪用された形跡はありません。このキャンペーンが成功した要因は、外部に公開された管理ポートと、単一要素認証における脆弱な認証情報の悪用です。これらは基本的なセキュリティの欠陥であり、AI の支援によって技術力の低い脅威アクターでも大規模に悪用できるようになりました。このアクティビティの特徴は、限られた技術力にもかかわらず、脅威アクターが複数の商用生成 AI サービスを使い、作戦のあらゆるフェーズで既知の攻撃手法を実装・拡大した点にあります。なお、このキャンペーンに AWS インフラストラクチャが悪用された事実は確認されていません。Amazon Threat Intelligence は、セキュリティコミュニティ全体の防御に役立てるため、これらの調査結果を共有します。 この調査から、商用 AI サービスがサイバー攻撃の技術的な参入障壁を引き下げている実態が明らかになりました。このキャンペーンの脅威アクターと、国家の支援を受けた APT (Advanced Persistent Threat) グループとの関連は確認されていません。金銭的動機を持つ個人または小規模グループと考えられ、AI を活用することで、従来であればはるかに大規模で高度な技術力を持つチームを必要としたであろう作戦規模を実現しています。しかし、公開状態にあった攻撃データの分析に基づくと、この脅威アクターは複数の組織の Active Directory 環境を侵害し、認証情報データベース全体を抽出し、バックアップインフラストラクチャを標的にすることに成功しています。これはランサムウェア攻撃の前段階の活動と考えられます。注目すべき点として、この脅威アクターは強化された環境やより高度な防御対策に遭遇した場合、固執せずにより防御の弱いターゲットへ移行しています。このことから、この脅威アクターの強みは高度な技術スキルではなく、AI によって強化された効率性と規模にあることがわかります。 2026 年もこの傾向は続くと予想されます。技術力の高低を問わず、AI を活用した脅威アクティビティは増加し続けることを組織は想定しておく必要があります。最も効果的な対策は依然として堅実なセキュリティの基本であり、具体的には、境界デバイスのパッチ管理、認証情報の管理徹底、ネットワークセグメンテーション、そして侵害後の痕跡に対する堅牢な検出が挙げられます。 キャンペーンの概要 定常的な脅威インテリジェンス活動を通じて、Amazon Threat Intelligence はこのキャンペーンに関連する悪意のあるツールをホストしているインフラストラクチャを特定しました。脅威アクターは、AI が生成した攻撃計画、被害組織の構成情報、カスタムツールのソースコードといった作戦用ファイルも、同じ外部からアクセス可能なインフラストラクチャ上に配置していました。この運用上のセキュリティの不備により、脅威アクターの手法や作戦全体を通じた AI の活用方法を包括的に把握することができました。これは言わば AI を活用したサイバー攻撃の量産装置であり、技術力の低い実行者でも大規模に活動できる仕組みとなっています。 脅威アクターは世界各地に分散する FortiGate アプライアンスを侵害し、デバイスの完全な構成情報を抽出して、認証情報、ネットワークトポロジ情報、デバイス設定情報を入手しました。その後、窃取した認証情報を使って被害組織の内部ネットワークに侵入し、Active Directory の侵害、認証情報の収集、バックアップインフラストラクチャへのアクセス試行など、侵害後のアクティビティを実行しました。これらはランサムウェア攻撃の前段階の活動と一致しています。 初期アクセス: 認証情報の大量悪用 脅威アクターの初期アクセス手段は、インターネットに公開された FortiGate 管理インターフェイスに対する、認証情報を悪用した不正アクセスでした。脅威アクターが使用したツールの分析から、ポート 443、8443、10443、4443 上の管理インターフェイスに対する体系的なスキャンと、よく使い回される認証情報による認証試行が確認されました。 FortiGate の設定ファイルには以下のような情報が含まれるため、攻撃者にとって価値の高いターゲットです。 復元可能なパスワードを含む SSL-VPN ユーザー認証情報 管理者認証情報 完全なネットワークトポロジとルーティング情報 内部アーキテクチャを明らかにするファイアウォールポリシー IPsec VPN ピアの設定情報 脅威アクターは AI の支援を受けて Python スクリプトを開発し、窃取した設定情報の解析、復号、整理を行いました。 地理的分布 このキャンペーンの標的選定は、特定のセクターを狙ったものではなく、脆弱なアプライアンスに対する自動化された大量スキャンに基づく無差別的なものと分析しています。ただし、同一組織に属する複数の FortiGate デバイスがアクセスされるなど、組織単位での侵害を示唆するパターンも確認されています。Amazon Threat Intelligence は、連続する IP アドレスブロックや共通の非標準管理ポートの使用状況から、マネージドサービスプロバイダーのデプロイ環境や大規模な組織ネットワークと推定されるクラスターを観測しました。侵害されたデバイスは、南アジア、ラテンアメリカ、カリブ海地域、西アフリカ、北ヨーロッパ、東南アジアをはじめとする複数の地域に集中して分布していました。 カスタムツール: AI が生成した偵察フレームワーク 被害組織のネットワークへの VPN 接続を確立した後、脅威アクターは Go と Python の両方で記述された複数バージョンのカスタム偵察ツールをデプロイしています。ソースコードの分析から、AI を活用した開発の明確な痕跡が確認されました。具体的には、関数名をそのまま繰り返すだけの冗長なコメント、機能よりもフォーマットを重視した単純なアーキテクチャ、適切なデシリアライゼーションではなく文字列マッチングに頼った単純な JSON パース、空のドキュメントスタブを伴う言語組み込み関数の互換性ラッパーなどが挙げられます。これらのツールは脅威アクターが想定した特定の攻撃シナリオでは機能するものの、例外的な条件への耐性がなく、想定外の状況では正しく動作しません。これは、大幅な改良を加えずにそのまま使用された AI 生成コードに典型的な特徴です。 このツールは、VPN 接続後の偵察ワークフローを以下のように自動化します。 VPN ルーティングテーブルからのターゲットネットワークの取り込み ネットワークのサイズ別分類 オープンソースのポートスキャナー gogo を使用したサービスディスカバリの実行 SMB ホストとドメインコントローラーの自動識別 オープンソースの脆弱性スキャナー Nuclei を使用した、検出された HTTP サービスに対する脆弱性スキャンの統合と、優先順位付けされたターゲットリストの生成 侵害後の手法 被害組織のネットワーク内部に侵入した後、脅威アクターは広く知られたオープンソースの攻撃ツールを用いて、以下のような標準的な攻撃手法を実行しています。 ドメインの侵害: 脅威アクターの作戦文書では、オープンソースの侵害後ツールキットである Meterpreter と mimikatz モジュールを使用し、ドメインコントローラーに対して DCSync 攻撃を実行する計画が詳述されています。この手法により、脅威アクターは Active Directory から NTLM パスワードハッシュを抽出しました。確認された侵害事例では、脅威アクターはドメインの認証情報データベース全体を取得しています。少なくとも 1 件のケースでは、Domain Administrator アカウントに平文のパスワードが使用されており、そのパスワードはパスワードの使い回しにより FortiGate の設定情報から抽出されたか、あるいはそもそも脆弱なものでした。 ラテラルムーブメント: ドメインの侵害後、脅威アクターは追加のインフラストラクチャに対して Pass-the-Hash/Pass-the-Ticket 攻撃、標準的なポイズニングツールを使用した NTLM relay 攻撃、Windows ホスト上でのリモートコマンド実行などの手法でアクセスの拡大を試みています。 バックアップインフラストラクチャの標的化: 脅威アクターは特に Veeam Backup &amp; Replication サーバーを標的とし、PowerShell スクリプト、コンパイル済みの復号ツール、既知の Veeam の脆弱性を利用したエクスプロイトなど、認証情報を抽出するための複数のツールをデプロイしました。バックアップサーバーは、バックアップ操作に必要な高い権限を持つ認証情報を保存していることが多く、また、バックアップインフラストラクチャを侵害することでランサムウェアのデプロイ前にリカバリ機能を無力化できるため、攻撃者にとって高価値なターゲットです。 限定的なエクスプロイトの成功: 脅威アクターの作戦メモには、さまざまなターゲットに対する複数の CVE (CVE-2019-7192、CVE-2023-27532、CVE-2024-40711 など) への言及があります。しかし、この分析で得られた重要な知見は、脅威アクターが単純な自動化された攻撃パスを超える高度なエクスプロイトを試みた場合、おおむね失敗していたという点です。脅威アクター自身の作戦記録にも繰り返しの失敗が記録されています。標的のサービスにはすでにパッチが適用されていたり、必要なポートが閉鎖されていたり、脆弱性が対象の OS バージョンに該当しなかったりといったケースです。ある確認済みの被害組織に対する最終的な作戦評価では、主要なインフラストラクチャターゲットは「十分に保護されて」おり、「悪用可能な脆弱性ベクトルがない」と結論付けています。 AI による攻撃能力の増幅 Amazon Threat Intelligence の分析から、脅威アクターが作戦の全フェーズにわたり、少なくとも 2 つの商用 LLM (大規模言語モデル) プロバイダーを使い分けていたことが判明しました。 AI が生成した攻撃計画: 脅威アクターは AI を活用し、段階的なエクスプロイト手順、想定成功率、所要時間の見積もり、優先度付きタスクツリーを含む包括的な攻撃計画を生成していました。これらの計画には攻撃的 AI エージェントに関する学術研究への参照が含まれており、脅威アクターが AI を活用したペネトレーションテストの最新動向を追跡していることがうかがえます。AI は技術的に正確なコマンドシーケンスを生成できますが、脅威アクターは実環境の条件が計画と異なる場合への対応に苦慮しています。具体的には、カスタムエクスプロイトのコンパイル、失敗したエクスプロイトのデバッグ、標準的な手法が通用しなかった場合の柔軟な方向転換ができていません。 マルチモデルの作戦ワークフロー: Amazon Threat Intelligence は、脅威アクターが複数の AI サービスを相互補完的に使い分けていることを確認しました。一方は主にツール開発、攻撃計画の策定、作戦支援に使用されています。もう一方は、侵害済みネットワーク内でのピボットに追加の支援が必要な場合の補助的な攻撃プランナーとして使用されています。確認された事例の 1 つでは、脅威アクターが侵害中の被害組織の完全な内部トポロジ (IP アドレス、ホスト名、確認済みの認証情報、検出されたサービス) を LLM に送信し、既存のツールではアクセスできなかった追加システムの侵害手順を段階的に生成するよう要求していました。 大規模な AI 生成ツール: 偵察フレームワーク以外にも、脅威アクターのインフラストラクチャには、設定情報パーサー、認証情報抽出ツール、VPN 接続の自動化、大量スキャンのオーケストレーション、結果集約ダッシュボードなど、AI 生成の特徴を示すスクリプトが複数のプログラミング言語で多数格納されていました。これほどの量と多様性のカスタムツールは、通常であれば十分なリソースを擁する開発チームの存在を示唆します。しかし実際には、単独の脅威アクターまたはごく少数のグループが、AI の支援を受けてこのツールキット全体を作成していました。 脅威アクターの評価 包括的な分析に基づき、Amazon Threat Intelligence はこの脅威アクターについて以下のように評価しています。 動機: 広範かつ無差別な標的選定と技術力の低さから、金銭的動機と推定 言語: ロシア語の作戦文書が多数確認されていることから、ロシア語話者 技術レベル: 基本的な技術力は低~中程度だが、AI により大幅に強化されている。標準的な攻撃ツールの実行やルーチンタスクの自動化は可能だが、エクスプロイトのコンパイル、カスタム開発、実際のオペレーション中の応用的な問題解決には苦慮している AI 依存度: 全作戦フェーズにわたり広範に依存。ツール開発、攻撃計画、コマンド生成、作戦レポートに複数の商用 LLM プロバイダーを使用 作戦規模: 広範。数十か国にわたる侵害済みデバイスがあり、長期間の持続的な作戦活動の証拠あり 侵害後の深度: 浅い。強化された環境や非標準的なターゲットに対して繰り返し失敗しており、自動化されたアプローチが通用しないと固執せずに次のターゲットへ移行するパターン 運用上のセキュリティ: 不十分。詳細な作戦計画、認証情報、被害組織のデータがツールとともに暗号化されていない状態で保存されている Amazon の対応 Amazon Threat Intelligence は、脅威アクターに対する積極的な調査と阻止活動を通じて、お客様とインターネットエコシステム全体の保護に継続的に取り組んでいます。 このキャンペーンの発見後、Amazon Threat Intelligence は以下の対応を実施しました。 侵害の痕跡 (IOC) を含む実用的なインテリジェンスを関連パートナーと共有 業界パートナーと連携し、キャンペーンに対する可視性を高めるとともに協調的な防御活動を支援 これらの取り組みにより、Amazon は脅威アクターの作戦効果の低減に貢献するとともに、複数の国の組織がキャンペーンの被害を軽減するための対策を講じることを可能にしました。 組織の防御 このキャンペーンが成功した要因は、外部に公開された管理インターフェイス、脆弱な認証情報、単一要素認証の組み合わせです。これらはいずれも基本的なセキュリティの欠陥であり、AI の支援があれば技術力の低い脅威アクターでも大規模に悪用できるものです。堅実なセキュリティの基本は、AI を活用した脅威に対しても依然として有効な防御策です。以下の対策を確認し、実施することを推奨します。 1. FortiGate アプライアンスの監査 FortiGate アプライアンスを運用している組織は、直ちに以下の対策を講じてください。 管理インターフェイスがインターネットに公開されていないことを確認する。リモート管理が必要な場合は、既知の IP 範囲にアクセスを制限し、踏み台ホストまたは帯域外管理ネットワークを使用する 管理者アカウントや VPN ユーザーアカウントを含め、FortiGate アプライアンスのデフォルトおよびよく使われる認証情報をすべて変更する すべての SSL-VPN ユーザー認証情報をローテーションする (特に管理インターフェイスがインターネットからアクセス可能であった、またはアクセス可能だった可能性があるアプライアンス) すべての管理アクセスおよび VPN アクセスに多要素認証を実装する FortiGate の設定を点検し、未承認の管理者アカウントやポリシー変更がないか確認する VPN 接続ログを監査し、予期しない地理的場所からの接続がないか確認する 2. 認証情報の管理徹底 FortiGate の構成情報から認証情報が抽出されていることを踏まえ、以下の対策を実施してください。 FortiGate VPN の認証情報と Active Directory ドメインアカウント間でのパスワードの使い回しがないか監査する すべての VPN アクセスに多要素認証を実装する すべてのアカウント (特に Domain Administrator アカウント) で、一意で複雑なパスワードの使用を徹底する サービスアカウントの認証情報を確認してローテーションする (特にバックアップインフラストラクチャで使用されるもの) 3. 侵害後の検出 被害を受けた可能性のある組織は、以下の痕跡がないか確認してください。 予期しない DCSync 操作 (レプリケーション関連の GUID を伴う Event ID 4662) 正規の Windows サービスを模倣した名前の新しいスケジュールタスク VPN アドレスプールからの異常なリモート管理接続 ネットワークトラフィックにおける LLMNR/NBT-NS ポイズニングの痕跡 バックアップ認証情報ストアへの不正アクセス 正規のサービスアカウントに見せかけた名前の新しいアカウント 4. バックアップインフラストラクチャの強化 脅威アクターがバックアップインフラストラクチャを重点的に標的としていることから、以下の対策が重要です。 バックアップサーバーを一般的なネットワークアクセスから隔離する 認証情報抽出に悪用される既知の脆弱性に対して、バックアップソフトウェアにパッチを適用する バックアップサーバーでの未承認の PowerShell モジュールのロードを監視する 管理者アクセスがあっても変更できないイミュータブルなバックアップコピーを実装する AWS 固有の推奨事項 AWS を使用している組織は、以下の対策を実施してください。 Amazon GuardDuty を有効にして脅威検出を行う (異常な API コールや認証情報の使用パターンの監視を含む) Amazon Inspector を使用して、ソフトウェアの脆弱性と意図しないネットワークの露出を自動スキャンする AWS Security Hub を使用して、セキュリティポスチャの継続的な可視性を確保する AWS Systems Manager Patch Manager を使用して、ネットワークアプライアンスを実行する EC2 インスタンス全体のパッチコンプライアンスを維持する ネットワークデバイスの侵害が疑われる場合は、認証情報のリプレイの痕跡がないか IAM アクセスパターンを確認する 侵害の痕跡 (IOC) このキャンペーンは Impacket、gogo、Nuclei をはじめとする正規のオープンソースツールに依存しているため、従来の IOC ベースの検出だけでは十分な効果が得られません。これらのツールはペネトレーションテスターやセキュリティ専門家にも広く使用されているため、ツールが存在するだけでは侵害の痕跡とは判断できません。組織では、シグネチャベースのアプローチよりも振る舞いベースの検出 (異常な VPN 認証パターン、予期しない Active Directory レプリケーション、VPN アドレスプールからのラテラルムーブメント) を優先し、検出結果の前後の文脈を踏まえて調査することが重要です。 IOC 値 IOC タイプ 初回確認日 最終確認日 説明 212[.]11.64.250 IPv4 2026/1/11 2026/2/18 脅威アクターがスキャンおよびエクスプロイト作戦に使用したインフラストラクチャ 185[.]196.11.225 IPv4 2026/1/11 2026/2/18 脅威アクターが攻撃作戦に使用したインフラストラクチャ この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO であり、Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティを最も自然な選択肢とすることで Amazon のビジネスを支えることを使命としています。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO をはじめ、さまざまな役職を歴任した後、2023 年 9 月に現職に就任しました。 Amazon 入社前は、FBI (連邦捜査局) サイバー部門でコンピュータおよびネットワーク侵入の技術分析を統括していました。また、空軍特別調査局 (AFOSI) の特別捜査官も務め、現在のセキュリティ業界の基盤を築いたとされる複数のコンピュータ侵入調査を主導しました。 コンピュータサイエンスと刑事司法の学位を持ち、SRO GT America GT2 の現役レーシングカードライバーでもあります。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
本記事は 2025 年 10 月 5 日 に公開された「 Integral Ad Science scales over 100 M documents with Amazon OpenSearch Service 」を翻訳したものです。 ソーシャルメディアプラットフォーム全体でコンテンツ量が急増し、リアルタイムの機械学習 (ML) モデルトレーニングが求められる中、 Integral Ad Science (IAS) にはソリューションが必要でした。コンテンツ分類器の継続的な開発を支え、手動アノテーションによる遅延を解消し、ピーク時の処理スループットを最大化できるソリューションです。 IAS はデジタルメディアの計測と最適化におけるグローバルリーダーであり、デジタルメディア品質の信頼性と透明性の基準を確立しています。データドリブンなテクノロジーでリアルタイムのインサイトと包括的なデータを提供し、広告が安全で適切な環境で実際のオーディエンスに届くようにしています。 本記事では、IAS が Amazon OpenSearch Service を活用し、スケーラブルな SaaS 型 ML プラットフォームを構築した事例を紹介します。プラットフォームは日次 1 億件以上のドキュメントを処理し、プロジェクト開始時と比較して複雑な検索オペレーションで 40〜55% のパフォーマンス向上を達成しました。 課題 従来、データサイエンスチームは手動および半自動のアノテーションワークフローに数日から数週間を費やしていました。目標は、パフォーマンスとコンプライアンスの要件を満たしつつ、データサイエンティストやエンジニアが組織全体でセルフサービスで利用できる統合 ML プラットフォームの構築でした。 主な要件は以下のとおりです。 高次元ベクトル埋め込みの類似検索処理 リアルタイムのインデキシングとクエリ 数百の ML 分類器の自動再トレーニング ベクトルデータベースの評価 Apache Spark と Databricks プラットフォーム上に構築したカスタムベンチマークフレームワークで、ベクトルデータベースソリューションを広範に評価しました。 チームは以下のパフォーマンス指標で複数のソリューションを評価しました。 毎秒の類似検索クエリ数 一括書き込みスループット 一括読み取りスループット Spark とのネイティブ統合 結果として、優れたパフォーマンス、コスト効率、Amazon Web Services (AWS) との統合、活発なコミュニティサポートを理由に OpenSearch Service が選定されました。 カスタムベクトルインデキシングを備えた従来型データベース、専用ベクトルデータベースサービス、オープンソースソリューションなど、他のアプローチも検討しました。それぞれ強みはあったものの、コスト効率とスループットの要件を満たしつつ、チームが求める ML 体験を提供するソリューションは OpenSearch 以外にありませんでした。 ソリューション概要 広範な評価の結果、IAS は Amazon OpenSearch Service と Amazon Managed Streaming for Apache Kafka ( Amazon MSK ) を戦略的基盤として採用しました。アーキテクチャはホットストレージとコールドストレージの両階層にわたり、リアルタイム処理と履歴分析の両方に対応します。ベクトルとメタデータは Amazon MSK を通じてストリーミングされ、信頼性の高いスケーラブルな取り込みを実現します。Spark ベースのコンシューマーがマイクロバッチを処理し、リアルタイムベクトル検索用の Amazon OpenSearch Service (ホットレイヤー) と長期分析用の Databricks 上の Delta テーブル (コールドレイヤー) に送信します。 以下がソリューションの全体像です。 図 1: ソリューションアーキテクチャ OpenSearch Service のベクトル検索機能と豊富なフィルタリング API により、データサイエンティスト、ナレッジワーカー、開発者がノートブック、カスタムアプリケーション、ワークベンチやポータルなどの GUI から利用できるようになりました。 ソリューションの最適化 OpenSearch Service クラスター構成は、目標パフォーマンスの達成に向けて複数の最適化フェーズを経ました。AWS チームの支援により、初期のパフォーマンスボトルネックと構成上の課題を克服しています。チームは AWS Graviton3 プロセッサ の r6g から r7g インスタンスへ移行し、OpenSearch Service のバージョンを 2.13 から 2.19 にアップグレードし、 Concurrent Segment Search 機能を有効化しました。 OpenSearch Service のインデックスマッピングは、高次元ベクトル埋め込みと効率的な k 近傍法 (k-NN) 検索 に対応するよう最適化しました。具体的には、 Hierarchical Navigable Small Worlds (HNSW) アルゴリズム と内積類似度を使用した 1,024 次元のベクトルフィールドを構成し、フィルタリング用のメタデータフィールドマッピングも設定しました。ベクトルフィールドでは構築と検索のパフォーマンスに最適化したパラメータ設定も行っています。IAS は OpenSearch Service の Scalar Quantization 機能でコスト削減も実現しました。 パフォーマンス最適化には、効率的な k-NN フィルタリング、シャード数とサイズの調整によるシャード最適化、 Java Virtual Machine (JVM) ヒープ設定の調整と Concurrent Segment Search の有効化によるメモリ管理が含まれます。通常の検索では 40〜55% のパフォーマンス改善を達成しました。複雑なフィルタ付きオペレーションでは最大 80% の改善が見られ、最も大きな改善では 20 分以上かかっていた複雑なフィルタ検索が 1 分未満に短縮されました。 今後、IAS は OpenSearch Service 3.0 への移行を検討しています。集約パフォーマンスの最大 20% 向上、高カーディナリティ集約のレイテンシー大幅削減、GPU アクセラレーション対応の可能性を含むベクトルデータベース機能の強化が期待されます。 インデキシングの最適化 データ取り込みパイプラインは、Amazon MSK をストリーミング基盤として活用し、高可用性のために 10 パーティション、レプリケーションファクター 3 で構成しています。パイプラインは複数のステージでデータを処理し、信頼性の高い高スループットなドキュメント処理を実現します。継続的に実行される Spark ジョブが Kafka トピックを消費し、スループットとレイテンシーを最適化します。マイクロバッチは OpenSearch Service と Delta テーブルの両方に同時書き込みされ、ストレージレイヤー間の整合性を維持します。 アーキテクチャ変更により、IAS はクラスターに過負荷をかけることなく大量のドキュメントストリームを OpenSearch Service に安全にインデキシングでき、インデキシングプロセスのスロットリング制御が向上しました。 OpenSearch Hadoop コネクタ の統合により、knn-vector フィールドの Spark 連携が可能になり、処理量が大幅に向上しました。ホットレイヤーとコールドレイヤーへの書き込みの並列化により、ベクトルドキュメントのインデキシングパフォーマンスは日次 6,000 万件から 1 億件以上に向上しました。 IAS は knn-vector フィールドの Spark 連携をサポートするプルリクエストを OpenSearch Hadoop コネクタに提出しました。このコントリビューションは OpenSearch のオープンソースコミュニティとの協業を示す好例であり、IAS 固有の技術要件を満たすソリューションの実現にもつながりました。OpenSearch Hadoop コネクタとの統合は、システムの安定性を維持しつつ目標処理量を達成するうえで不可欠でした。 メリット これらの工夫によって、IAS のデータサイエンティスト、エンジニア、ナレッジワーカーにスケーラブルな SaaS 型 ML 機能を提供するソリューションを実現しました。社内ユーザーは好みのツールで分類器のトレーニングとデプロイを行いながら、大規模環境で高いパフォーマンスを維持できます。Amazon OpenSearch Service をベクトル検索に活用するアプローチにより、インフラストラクチャの複雑さと手動プロセスが削減されます。 その他のメリットは以下のとおりです。 新しいデータの到着に基づく分類器の継続的な再トレーニング アノテーションサイクルを数日〜数週間からわずか数時間に短縮 スパイクのあるトラフィックパターンでも日次 1 億件以上のドキュメントを効率的に処理 異なるチームやビジネスユニット間のマルチテナンシー対応 高いインデックスチャーンでのデータ保持コンプライアンスの維持 データサイエンスチームが新しい ML モデルや実験をデプロイするまでの時間を短縮 アーキテクチャの柔軟性も重要なポイントです。IAS のベクトルデータベーススタックは柔軟な構成により、新しいユースケースに素早く対応できます。 AWS Cloud Development Kit (AWS CDK) を使い、チームごとの一貫したコスト配分を維持しつつ、ソリューションをチーム間で複製できます。 まとめ IAS は取り組みの当初、厳しいパフォーマンスとコスト要件を満たしつつベクトルデータベース機能を実現するスケーラブルなソリューションを求めていました。Amazon OpenSearch Service は、データサイエンスチームへの約束を果たすために必要な機能を提供しました。ベクトル検索の最適化と Amazon Managed Streaming for Apache Kafka の統合を含むアーキテクチャ改善により、コスト効率を維持しつつ大幅なパフォーマンス向上を達成しています。 IAS は複数のビジネスユニットへのプラットフォーム展開を続けており、SaaS 型 ML ソリューションのスケールに合わせてより多くの分類器をサポートする計画です。パイプラインにはさらに多くのユースケースが追加される見込みです。 ビジネスの加速を支援する方法については、 AWS の担当者 にお問い合わせください。 関連情報 Amazon OpenSearch Service vector database capabilities revisited Amazon OpenSearch Service Resources Amazon OpenSearch Service Documentation 著者について Brian Maguire Brian Maguire は、Amazon Web Services の Principal Solutions Architect です。クラウド上でお客様のアイデア実現を支援しています。テクノロジスト、ライター、教師、そして学ぶことを愛する学生でもあります。書籍「Scalable Data Streaming with Amazon Kinesis」の共著者です。 Daniel Cintron Daniel Cintron は、IT 分野で 16 年以上の経験を持つ Sr. Technical Account Manager です。アドテック業界のお客様が AWS で目標を達成できるよう支援しています。仕事以外では、家族との時間や新しいテクノロジーの探求を楽しんでいます。 Dmitry Goldenberg Dmitry Goldenberg は、Integral Ad Science の Staff Engineer です。ベクトルデータベースの統合や大規模分類器トレーニングフレームワークの構築プロジェクトをリードしています。ソフトウェア開発とデータエンジニアリングで 30 年の経験を持ち、AI/ML、NLP、情報検索技術を専門としています。IAS では Databricks、Amazon MSK/Kafka、Spark、AWS OpenSearch Service を活用し、高度なメディア計測ソリューションを提供しています。 Rudra Ghosh Rudra Ghosh は、ダブリンを拠点とする Integral Ad Science の Machine Learning Operations Engineer です。AWS のクラウドネイティブコンポーネントを活用したスケーラブルな ML プラットフォームの構築を専門としています。データエンジニアリングと MLOps の両分野に精通し、本番対応の ML システムを実現しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。
本稿は、2026年1月5日に公開された AWS Blog “ Agentic Cloud Modernization: Accelerating Modernization with AWS MCPs and Kiro ” を翻訳したものです。 今日の急速に進化するテクノロジー環境において、組織はレガシーシステムのモダナイゼーションを進めながら、運用上の優秀性を維持し、コストを管理するという大きなプレッシャーに直面しています。従来のクラウドモダナイゼーションのアプローチでは、多くの場合、数週間にわたる手作業での調査、広範なドキュメント作成作業、そして多大な開発リソースが必要となり、市場投入までの時間を遅らせ、プロジェクトコストを増加させるボトルネックが生じていました。しかし、AWS の Kiro や Cline のような AI を活用した開発アシスタントが、公式の Anthropic Model Context Protocol (MCP) servers for AWS と統合されて登場したことで、これまで手動で時間のかかっていたプロセスを、自動化され、一貫性があり、スケーラブルな手法に変革するパラダイムシフトが起きています。このエージェンティック・アーキテクチャアプローチは、測定可能なビジネス成果を提供しながら、プロジェクトリスクを大幅に削減し、実装期間を数週間から数日に短縮します。 AI アシスタントの選択 組織は、AI を活用した開発パートナーとして Kiro または Cline のいずれかを活用できます。 Kiro は、AWS のネイティブな AI 搭載開発環境および IDE で、クラウドモダナイゼーションプロジェクトに対してインテリジェントな支援を提供します。AWS サービス、ドキュメント、リアルタイム AI アシスタンスへの統合アクセスを備えた包括的な開発体験を提供します。Kiro は、コンテキストに応じたコード分析、インフラストラクチャコードの生成、プロジェクトの可視化、コラボレーティブな開発ワークフローに優れています。開発環境に直接組み込まれた、AWS サービスとの深い統合、MCP サーバー管理、AI 搭載開発支援を備えた完全な IDE 体験を求めるチームに最適です。 Cline オプション: Kiro を使用していない組織の場合、AWS MCP との統合を完全にサポートする Cline を使用できます。Cline は VS Code 拡張機能として動作し、IDE 内で統合された開発体験を提供します。Cline は、VS Code の使用が必要なチームに最適です。 両方のアシスタントは、公式の AWS MCP servers と統合されており、すべての推奨事項と生成されたコードが現在の AWS ベストプラクティスに従い、特定のワークロード要件に最も適切なサービスを活用することを保証します。 従来のモダナイゼーションアプローチの課題 エンタープライズのモダナイゼーション施策は、通常、多大な時間とリソースを消費する典型的なパターンに従って進められます。評価フェーズでは、アーキテクトが既存システムを手動でカタログ化し、相互依存関係を文書化し、技術的負債を評価するため、数週間にわたることがよくあります。計画フェーズでは、ターゲットアーキテクチャの設計、コストの見積もり、モダナイゼーション戦略の策定のために、複数のチーム間で広範なコラボレーションが必要になります。実装フェーズでは、インフラストラクチャコードの作成、クラウドネイティブパターンへのアプリケーションの変更、運用手順の確立のために、多大な開発作業が必要になります。 こうした従来のアプローチは徹底的ではありますが、市場投入までの時間を遅らせ、プロジェクトコストを増加させるボトルネックを生み出します。手動プロセスは、ドキュメントの品質とアーキテクチャの決定に一貫性のなさをもたらします。最新のクラウドプラットフォームの複雑さから、チームがモダナイゼーション施策全体にわたってベストプラクティスを一貫して適用することは容易ではありません。組織は、手作業による評価と実装ワークフローに伴う避けられない遅延により、組織はプロジェクトの推進力を維持することが困難になることが少なくありません。 エージェンティック・アーキテクチャアプローチの紹介 エージェンティック・アーキテクチャという概念は、AI を活用してモダナイゼーションのライフサイクル全体を自動化・加速するものです。Kiro を公式の AWS MCP サーバーと統合することで、組織は既存システムと AWS のベストプラクティスの両方を理解するインテリジェントな開発環境を構築できます。この統合により、モダナイゼーションプロジェクトの評価、計画、実装フェーズにわたるエンドツーエンドの自動化フレームワークが実現します。 図 1 は、従来のモダナイゼーションの 3 つのフェーズ (評価、計画、実装) が、Kiro と AWS MCP の統合によってどのように変革されるかを示しています。このエージェントワークフローは、レガシーシステムの分析からターゲットアーキテクチャの設計、本番環境で使用可能なコード生成まで、一連のプロセスが自動化され、手作業の負担とプロジェクト期間を大幅に削減します。 Kiro は、既存のコードベースを分析し、アーキテクチャパターンを理解し、 AWS Well-Architected Framework の原則に沿った本番環境対応のソリューションを生成できる、インテリジェントな開発パートナーとして機能します。公式の AWS MCP サーバーとの統合により、すべての推奨事項と生成されたコードが現在の AWS ベストプラクティスに従い、特定のワークロード要件に最も適切なサービスを活用することが保証されます。 エージェントアプローチの3つの中核フェーズ 分析フェーズ – Kiro が既存システムを自動的に検証するフェーズです。コードベースを分析して現在のアーキテクチャパターンの包括的なドキュメントを生成し、システムの依存関係とデータフローを示す視覚的な図を作成し、技術的負債とモダナイゼーションの機会を特定し、アプリケーションとサービス全体のクラウド対応状況を評価します。 計画フェーズ – Kiro がターゲット AWS アーキテクチャをインテリジェントに設計します。具体的には、特定の要件に最適化されたソリューションを設計し、リアルタイムの AWS 価格を使用して詳細なコスト見積もりを生成し、段階的な実装戦略を含むモダナイゼーションロードマップを作成し、ワークロードの特性に基づいて適切な AWS サービスを推奨します。 実装フェーズ – 本番環境対応のアセットを自動生成します。Kiro は CloudFormation、CDK、または Terraform を使用した Infrastructure as Code を提供し、クラウドネイティブパターンに対応したアプリケーションコードの変更を作成し、モダナイズされたアーキテクチャを反映した最新のドキュメントを生成し、デプロイ自動化スクリプトと CI/CD パイプラインを生成します。 各フェーズは、特定の AWS MCP サーバーと Kiro の機能を活用して、従来は手作業で数週間かかっていたプロセスを、数日で本番環境対応の結果を提供する自動化された一貫性のあるワークフローに変革します。 図 1 – エージェントアーキテクチャワークフロー: AIを活用したクラウドモダナイゼーションプロセス 現状分析 エージェンティック・アーキテクチャモダナイゼーションの最初のフェーズは、既存システムの自動分析に焦点を当てます。Kiro はコードベースを調査し、アーキテクチャパターン、依存関係、潜在的なモダナイゼーションの機会を特定します。この分析により、通常であればシニアアーキテクトや開発者が数週間かけて手作業で行う必要がある詳細なドキュメントが生成されます。この自動分析アプローチにより、評価時間が数週間から数日に短縮され、すべてのシステムコンポーネントに対して一貫した評価基準が確保されます。 AIアシスタントは、システムの依存関係とデータフローを示す視覚的な図を作成することで、ステークホルダーが現在のアーキテクチャの複雑さを明確に理解できるようにします。技術的負債の評価を通じて、モダナイゼーションの取り組みが最も大きな効果を発揮する具体的な領域を特定します。クラウド対応性の評価では、各アプリケーションコンポーネントを調査して最適なモダナイゼーション戦略を決定し、プロジェクトのタイムラインに影響を与える前に潜在的な課題を特定します。生成されたドキュメントは、計画フェーズの確固たる基盤となり、モダナイゼーションプロセス全体を通じて貴重な参考資料として活用できます。 図 2 – Kiroで生成された現状アーキテクチャの分析とドキュメント 図 3 – Kiroで生成された現状アーキテクチャ図 計画 現状分析が完了すると、Kiro は組織固有の要件に最適化されたターゲット AWS アーキテクチャの設計に移行します。この AI アシスタントは、AWS サービスとアーキテクチャパターンの知識を活用して、パフォーマンス、コスト、運用の複雑さのバランスを取ったソリューションを推奨します。AWS MCP サーバーとの統合により、推奨事項は常に最新のサービス機能と料金モデルを反映します。 コスト見積もりは、さまざまなアーキテクチャオプションのリアルタイム分析を提供する自動化されたプロセスになります。Kiro は、現在のインフラストラクチャ費用と予測される AWS コストを比較するコストモデルを生成でき、モダナイゼーションの優先順位と予算配分について情報に基づいた意思決定を可能にします。モダナイゼーションロードマップは、ビジネスの中断を最小限に抑えながら、モダナイゼーションプロセス全体を通じて段階的な価値を提供する段階的な実装戦略の概要を示します。 計画フェーズには、ワークロードの特性に基づいた適切な AWS サービスの自動選択も含まれます。プロンプトを通じて非機能要件に関する情報を提供することで、エージェントは技術目標とビジネス目標の両方に沿ったアーキテクチャを設計できます。 図 4 – Kiro で生成されたターゲットアーキテクチャドキュメント 図 5 – Kiro で生成されたターゲットアーキテクチャ図 図 6 – Kiro で生成されたターゲットアーキテクチャのコストモデル 実装 実装フェーズでは、エージェンティック・アーキテクチャアプローチの真の力が発揮されます。Kiro は、組織の好みや既存のツール標準に基づいて、 AWS CloudFormation 、 AWS Cloud Development Kit (CDK)、または Terraform を使用して Infrastructure as Code を生成します。これらの生成されたテンプレートには、セキュリティ、モニタリング、運用上の優秀性に関する AWS のベストプラクティスが組み込まれており、評価フェーズと計画フェーズで特定された具体的な要件が反映されています。 コンテナ化、マイクロサービス分割、サーバーレス採用などの一般的なモダナイゼーション要件に対応するため、クラウドネイティブパターン向けのアプリケーションコード変更が自動生成されます。AI アシスタントは、レガシーコードパターンと最新のクラウドネイティブアプローチの両方を理解しており、ビジネスロジックを維持しながらクラウド最適化されたアーキテクチャを採用する変換コードを生成できます。 図 7 – Kiro で生成されたターゲットアーキテクチャのコードと CDK 公式 AWS MCP サーバーの活用 公式の AWS MCP サーバー との統合により、Kiro は AWS の機能と最新のベストプラクティスへの包括的なアクセスが可能になります。AWS MCP サーバーは、最新のドキュメントへのアクセスと AWS サービスに関する深い文脈的知識を持つため、基盤モデル以上のメリットを提供します。この統合により、より正確で有用な応答が可能になり、生成されるすべてのコードと推奨事項が現在の AWS サービスの機能と制限を反映します。 まず始めるべき MCP これらの MCP は、現在の状態のアーキテクチャ (図を含む) を文書化し、図、コスト、コード、デプロイメントを含むターゲットアーキテクチャを設計するのに役立ちます。 分析フェーズ core-mcp-server – ロールベースの環境変数に基づく動的プロキシサーバー戦略により、AWS MCP サーバーを使用するための出発点を提供します。 code-doc-gen-mcp-server – リポジトリ構造を分析し、コードプロジェクトの詳細なドキュメントを生成します。 aws-diagram-mcp-server – Python diagrams パッケージ DSL を使用して図を作成します。このサーバーを使用すると、Python コードを使用して AWS 図、シーケンス図、フロー図、クラス図を生成できます。 計画フェーズ aws-documentation-mcp-server – AWS ドキュメントへのアクセス、コンテンツの検索、推奨事項の取得を行うツールを提供します。 aws-knowledge-mcp-server – 最新のドキュメント、コードサンプル、その他の公式 AWS コンテンツを提供します。 aws-pricing-mcp-server – リアルタイムの AWS 料金情報へのアクセスとコスト分析機能を提供します。 生成フェーズ cdk-mcp-server – Cloud Development Kit (CDK) のベストプラクティス、Infrastructure as Code パターン、CDK Nag によるセキュリティコンプライアンス terraform-mcp-server – AWS 上の Terraform のベストプラクティス、Infrastructure as Code パターン、Checkov によるセキュリティコンプライアンス Infrastructure as Code の生成は、CDK、Terraform、CloudFormation ワークフロー専用の MCP サーバーから恩恵を受けます。これらの特化したサーバーは、セキュリティスキャンとコンプライアンスチェックを提供し、生成されたインフラストラクチャコードがエンタープライズセキュリティ基準を満たすことを保証します。この統合により、AWS サービスの制限やリージョンの可用性に対するインフラストラクチャ設計のリアルタイム検証も可能になります。 コンテナとサーバーレスのモダナイゼーションシナリオでは、EKS、ECS、AWS Serverless Application Model ワークフロー用の専用 MCP サーバーを活用します。これらの統合により、コンテナ化戦略とサーバーレス採用パターンに対する広範なサポートが提供され、生成されたソリューションが各デプロイモデルの AWS ベストプラクティスに従うことが保証されます。 AWS MCP を使用した AI アシスタントのセットアップ AWS MCP を使用した Kiro の設定 Kiro 内で MCP を設定する詳細については、 Introducing remote MCP servers をお読みください。 Kiro は、IDE 内に組み込まれた MCP 設定システムを通じて AWS MCP と統合されます。Kiro を AWS MCP サーバーで設定するには、次の手順を実行します。 AWS 認証情報の設定 : IDE の設定または環境変数を通じて、開発環境で AWS 認証情報が適切に設定されていることを確認してください。 MCP サーバーの追加 : Kiro IDE では、複数の方法で MCP サーバーを設定できます: ワークスペース設定 : ワークスペース内の .kiro/settings/mcp.json を作成または編集します ユーザー設定 : ~/.kiro/settings/mcp.json のグローバル設定を使用します IDE インターフェース : Kiro IDE 設定の MCP 設定パネルを使用します 図 8 – Kiro における MCP 設定パネルと JSON ワークスペース設定の例: { "mcpServers": { "aws-core": { "command": "uvx", "args": ["awslabs.core-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR" }, "disabled": false }, "aws-docs": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_DOCUMENTATION_PARTITION": "aws" }, "autoApprove": ["search_documentation"], "disabled": false }, "awslabs.aws-pricing-mcp-server": { "command": "uvx", "args": ["awslabs.aws-pricing-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "default", "AWS_REGION": "us-east-1" } } } } ** aws-pricing-mcp-server については、AWS_PROFILE 変数を定義する必要があることにご注意ください ** MCP ツールへのアクセス : Kiro IDE 内で、以下のことができます。 統合された MCP パネルで利用可能な MCP サーバーを表示 AI チャットインターフェースを通じて MCP ツールを直接使用 MCP サーバーのステータスを確認し、必要に応じてサーバーに再接続 特定のツールを自動承認してワークフローを効率化 統合の検証 : チャットインターフェースで Kiro に質問します。 Kiro IDE は、AWS に焦点を当てたモダナイゼーションにおいて、いくつかの利点を提供します。 コンテキストに応じた AI アシスタンスを備えた統合開発環境 ビジュアルな MCP サーバー管理と監視 コード編集と AWS サービスとのやり取りのシームレスな統合 リアルタイム検証を備えた Infrastructure as Code の組み込みサポート 開発、ドキュメント、デプロイを組み合わせた包括的な IDE ワークフロー AWS MCP を使用した Cline の設定 VS Code の Cline に MCP サーバーを追加するには、cline_mcp_settings.json ファイルを使用します。cline_mcp_settings.json ファイルは以下の場所にあります: macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/ Windows: %APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/ 上記と同じワークスペース設定 json が Cline でも動作します。 エージェンティック・アーキテクチャモダナイゼーションのメリット エージェンティック・アーキテクチャアプローチの採用は、モダナイゼーションプロジェクトの複数の側面において具体的な改善をもたらします。これらの手法を実装する組織は、クラウド変革施策全体を通じて、効率性の向上、リスクの低減、成果の改善を経験します。以下のセクションでは、AWS MCP サーバーと統合された AI を活用した開発アシスタントを利用する際に、組織が期待できる具体的なメリットと測定可能な影響について詳しく説明します。 測定可能なビジネス価値 エージェンティック・アーキテクチャアプローチを実装している組織は、モダナイゼーションプロジェクトの成果が改善されたと報告しています。アセスメントのタイムラインは数週間から数日に短縮され、より迅速な意思決定とプロジェクトの開始が可能になります。生成されたドキュメントの品質と一貫性は、人間による監視を最小限に抑えながら、手作業によるアプローチを上回ります。 コスト最適化は、実装後の検討事項ではなく、設計プロセスの不可欠な部分となります。アーキテクチャ設計中のリアルタイムコストモデリングにより、チームは実装を開始する前にパフォーマンスとコストの間で情報に基づいたトレードオフを行うことができます。自動化されたライトサイジング推奨事項は、組織がソリューションの過剰構築を回避し、インフラストラクチャの過剰プロビジョニングを防ぐのに役立ちます。 AWS のベストプラクティスの一貫した適用と自動化されたセキュリティコンプライアンスチェックにより、リスク軽減が向上します。プロセス全体を通じて生成される詳細なドキュメントは、監査要件をサポートし、継続的なメンテナンスと最適化の取り組みのための貴重な参考資料を提供します。 品質保証と標準化 エージェンティック・アーキテクチャアプローチは、AWS Well-Architected Framework に対する自動検証を通じて、強化された品質保証を提供します。生成されたすべてのアーキテクチャは、フレームワークの 6 つの柱すべてにわたって体系的な評価を受け、モダナイズされたソリューションが運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化に関するエンタープライズ標準を満たすことを保証します。 コード品質分析には、インフラストラクチャとアプリケーションコンポーネントの両方に包括的なカバレッジを提供する自動テスト生成が含まれます。この自動テストアプローチにより、モダナイズされたソリューションが信頼性を維持しながら、クラウドネイティブ運用に不可欠な継続的デリバリープラクティスをサポートすることが保証されます。 すべてのソリューションが同じ AI アシスタントと AWS MCP サーバー統合を活用することで、モダナイゼーションプロジェクト全体での標準化が自動的に実現されます。この一貫性により、運用の複雑さが軽減され、チームは異なるプロジェクト間で多様なアーキテクチャアプローチを管理するのではなく、標準化されたパターンに関する専門知識を開発できるようになります。 実装戦略とタイムライン エージェンティック・アーキテクチャアプローチの導入を成功させるには、自動化のメリットと組織の変更管理ニーズのバランスを取る、慎重な実装計画が必要です。初期セットアップでは通常、適切な AWS MCP サーバーで Kiro を構成し、必要な AWS 認証情報とアクセス許可を確立するのに数時間かかります。 パイロット評価フェーズは、AI が生成した推奨事項を組織の要件や好みに照らして検証する貴重な学習機会を提供します。これらのパイロットプロジェクトは通常 2 ~ 3 週間にわたり、組織が直面するモダナイゼーションの課題の全範囲を示す代表的なアプリケーションに焦点を当てます。 モダナイゼーション設計フェーズでは、パイロット評価から得られた教訓を活用して、包括的なターゲットアーキテクチャと実装ロードマップを作成します。これらのフェーズには通常 4 ~ 5 週間を要し、生成された推奨事項がビジネス目標と技術的制約に沿っていることを確認するためのステークホルダーレビュープロセスが含まれます。 実装フェーズは、アプリケーションの複雑さと組織の準備状況によって異なりますが、従来の手作業によるアプローチと比較して大幅に加速されます。Kiro が生成する本番環境対応のアセットにより、チームはインフラストラクチャコードとデプロイ自動化をゼロから作成するのではなく、検証とカスタマイズに集中できます。 今後の検討事項と継続的な進化 エージェンティック・アーキテクチャアプローチは、AI の機能が進化し、 AWS サービスが拡大するにつれて継続的に改善される進化する手法です。このアプローチを採用する組織は、長期的なモダナイゼーションの成功を支える標準化されたプロセスを確立しながら、AI を活用した開発支援の継続的な改善から恩恵を受けることができます。 MCP サーバーが新しいサービス提供やベストプラクティスを反映したアップデートを受け取ることで、新しい AWS サービスや機能との統合が自動的に行われます。この継続的な進化により、モダナイゼーションの取り組みは、確立された組織のパターンと好みとの一貫性を維持しながら、AWS のイノベーションに対応し続けます。 エージェンティック・アーキテクチャのモダナイゼーションを通じて確立された詳細なドキュメントと標準化されたアプローチは、将来の最適化と拡張の取り組みに向けた強固な基盤を提供します。組織はこれらの資産を活用して、エンタープライズの成功に不可欠な品質と一貫性を維持しながら、継続的なクラウド導入の取り組みをサポートできます。 まとめ AI を活用した開発アシスタントと公式 AWS ツールの統合は、組織がクラウドモダナイゼーションの課題にアプローチする方法における根本的な変革を表しています。評価、計画、実装の各フェーズを自動化することで、エージェンティック・アーキテクチャアプローチは、プロジェクトのタイムラインとリソース要件を削減しながら、価値ある成果を提供します。 これらの手法を採用する組織は、エンタープライズの成功に不可欠な品質と一貫性を維持しながら、クラウド導入の取り組みを加速できます。インテリジェントな自動化と AWS のベストプラクティスを組み合わせることで、レガシーシステムをビジネスの成長とイノベーションをサポートする最新のクラウドネイティブアーキテクチャに変革するための強力なフレームワークが生まれます。 アーキテクチャモダナイゼーションの未来は、人工知能と実績のあるクラウドプラットフォームおよびプラクティスの思慮深い統合にあります。今日これらの機能に投資する組織は、AI 機能が進化し成熟し続けるにつれて、時間とともに複利的に増大する競争優位性を確立するでしょう。 次のステップ 今日からエージェントアーキテクチャの取り組みを始めましょう。お好みの AI アシスタントに AWS MCP サーバーを設定してください。Kiro または Cline をダウンロードし、AWS 認証情報を設定し、IDE で MCP サーバーを設定して、代表的なレガシーアプリケーションで最初のモダナイゼーション評価を開始してください。初期セットアップにかかる時間はわずか数時間で、得られるインサイトはモダナイゼーションプロジェクトへのアプローチを大きく変えるでしょう。 Jeff Escott Jeff Escott は、AWS のプリンシパルアーキテクトで、30 年以上のテクノロジー経験を持っています。彼は、お客様がモダナイゼーション戦略を定義し、クラウドファーストのアプローチを採用することを支援し、人材、プロセス、テクノロジーにわたってお客様の変革を支援することに注力しています。さらに、Jeff は長年にわたり、アーキテクチャの実践を進歩させ、将来のアーキテクトを育成することを提唱してきました。Jeff は、ウースター工科大学で保険数理学の学士号を取得しており、米国コネチカット州を拠点としています。 翻訳はソリューションアーキテクトの平良允俊が担当しました。
本記事は 2026 年 2 月 13 日に公開された Ranjith Ramakrishnan による “ Enterprise identity and usage metrics ” を翻訳したものです。 Kiro が 11 月 17 日に一般提供されて以来、Rackspace、Smugmug、Netsmart などの多くの企業が、エンジニアリングチーム全体でスペック駆動開発アプローチを採用し、AI 開発においてより構造化されたアプローチをもたらし、場合によっては最大 90% の効率向上を実現しています。 本日、外部 ID プロバイダーのサポートとユーザーレベルのアクティビティメトリクスにより、組織が Kiro をさらに簡単に使用できるようになりました。企業には、ID 管理の仕組みやコンプライアンス要件があり、またチームは「何がどのように使われているのか」を可視化して把握する必要があります。この分野は急速に変化しているため、企業は新しいユーザーを迅速にオンボーディングし、AI がエンジニアをどこでどのように支援しているかについての洞察を得たいと考えています。このデータがあれば、ツールとプロセスへの投資を迅速に拡大し、一貫して高い品質基準を保ちながら、はるかに速くリリースできます。 外部 ID プロバイダー: Okta と Microsoft Entra ID 組織が Okta または Microsoft Entra ID を通じて ID を管理している場合、Kiro はそのインフラストラクチャに直接接続できるようになりました。これは、 IDE 、 CLI 、Web アプリなど、Kiro ポートフォリオ全体で機能します。開発者は既に持っている認証情報で認証するため、新しいログインを設定する必要はありません。 管理者が既存の ID プロバイダーをオンボーディングすると、SSO ポリシー、条件付きアクセスルール、MFA 適用が設定どおりに Kiro で使用されます。Okta と Microsoft Entra から始めたのは、多くのお客様からのリクエストに基づいています。追加の OIDC プロバイダーのサポートに取り組んでいます。まだサポートされていないプロバイダーを使用している場合は、 お知らせください 。優先順位の決定に役立てさせていただきます。 これは、Kiro を人気のあるエンタープライズツールやシステム(ID プロバイダー、チケットシステムやバージョン管理システム、デプロイツールなど)に接続する最初のステップです。 ユーザーレベルのアクティビティメトリクス 組織の管理者は、チーム全体の利用状況を日次で集計したデータを提供するユーザーアクティビティレポートを有効にできるようになりました。レポートは、クライアントタイプ(IDE、CLI、IDE プラグイン)ごとにアクティビティを分類するため、開発者が実際に使用しているツールを可視化できます。これらの基本的なメトリクスは始まりに過ぎません。 生産性の測定と使用パターンの確立は繰り返し出てくるテーマであり、今日、私たちはより豊富な分析(トレンドビュー、チームレベルの集計、エクスポート可能なダッシュボード)だけでなく、エージェント型開発を効果的に活用することが、どのように生産性向上につながるのか、その洞察を得られるようにしていきます。企業が重視するソフトウェアデリバリー指標において、どのチームが最も顕著な向上を実現しているのか? そしてその成果を牽引する利用パターンとは何か? 2026年の展開にご期待ください。 エンタープライズ向けの次のステップ これら 2 つの機能は、企業が既に依存しているシステム内で Kiro を機能させるための、より広範な取り組みの一部です。既存のツールやサービスとのさらなる統合、および開発速度を安全に向上させるために必要なガードレールを提供する追加のガバナンス制御と機能に積極的に取り組んでいます。 組織での Kiro 導入を検討中の方、または既に利用中で特定のエンタープライズ機能の優先的な実装を希望される方は、 お知らせいただくか 、 GitHub で Issues を開いてください。 翻訳は Solutions Architect の吉村が担当いたしました。
はじめに 東芝テック株式会社は、流通・小売業界やさまざまなワークプレイスに向けたソリューションを開発、提供しています。POS システムにおいては国内外でトップシェアを誇るリーディングカンパニーであり、グローバルリテールプラットフォーム「ELERA」による小売業務全体のデジタル化を支援しています。ELERA は、「タッチポイント」「ソリューション」「データサービス」の 3 軸でビジネスを展開し、高い拡張性とリアルタイムな情報活用によって現場の課題解決を支援することで、店舗運営の効率化や意思決定の高度化につなげます。パートナーとの連携を通じてデータ活用を軸に、店舗運営と顧客体験に革新をもたらす『リテール共創基盤』として、次世代の消費体験を形にしていきます。 この度、東芝テック株式会社は AWS の技術支援のもと、AI エージェント を活用した店舗運営支援ソリューションを開発し、2026 年 3 月3日~6日まで、東京ビッグサイト(国際展示場)で開催される「リテールテックJAPAN 2026」にてデモンストレーションを行います。本ブログでは、この新しいソリューションを解説致します。 小売業界が直面する課題 現代の小売業界では、デジタル化の波とともに、店舗運営の複雑さが増しています。売り場責任者は日々、膨大な売上データ、在庫情報、顧客動向を把握しながら、収益性を最大化するための意思決定に迫られています。しかし、多くの店舗では、ベテラン担当者の経験と勘に頼った運営が続いており、データ活用の恩恵を十分に受けられていないのが現状です。 特に深刻な課題となっているのが、データ分析に熟練の知見が必要とされることです。多くのスーパーマーケットの店舗では、数十種類にも及ぶ帳票に加え、日次・月次の売上集計、商品別売上分析、時間帯別売上分析など重要な情報が蓄積されますが、これらを読み解いて適切な判断を下すには複数年にわたる現場経験が必要とされています。新人スタッフや若手の売り場責任者にとって、予算達成率の数字から、具体的にどのような対策を講じるべきかを判断することは容易ではありません。 さらに、小売業界全体に共通する課題として、多くの店舗システムではデータの更新頻度に制約があり、リアルタイムな状況変化への対応が困難な状況です。例えば、午前中に特定の商品の売れ行きに変化が生じても、その情報を即座に把握して適切なタイミングで値引きや陳列変更といった対策を打つことは困難です。さらに人手が限られる中で、他の商品情報も踏まえ、どの商品から優先的に対応すべきかを判断するのは困難です。 また、部門横断的な分析も大きな課題です。例えば青果部門の責任者が、関連商品である鍋スープの売上動向を把握して連動した販促を行いたくても、部門ごとに分かれた組織構造や、各部門に蓄積された専門知識の分断により、総合的な判断を行うことは困難です。異なるシステムに散在するデータの統合に加え、部門間でのナレッジ共有や協調的な意思決定プロセスの確立が技術的・組織的な課題となっています。 店舗運営支援ソリューションの価値 本ソリューションは、これらの課題を解決し、小売業界に革新的な価値をもたらします。AI エージェントが小売業者の POS データや別システムのデータベースに格納された在庫情報、カメラや温湿度計などの IoT センサーによって生成されるデータなどを継続的にモニターし、あらかじめ設定したシグナル(売れ足が平常時より鈍い等)を検知すると、取るべき施策(値引きの必要性やタイミングの判断等)を自動的に分析し、売り場責任者のスマートフォンに具体的な推奨アクションを即座に通知します。これにより、従来は気づかれなかった売上機会を把握し、タイムリーな対応が可能になります。 ポイントは、ベテラン担当者の豊富な経験と知見、店長の施策の方向性を、管理画面から自然言語でインプットするだけで、現場でノーコードで AI エージェントを開発できることです。これらのエージェントは、従来の AI チャットボットとは異なり、24時間365日バックグラウンドで働き続けることできるため、PC やスマートフォンで担当者が質問文を入力せずとも、重要なビジネスシグナルを見落とすことがありません。結果として、データに基づく具体的で実行可能な施策を、適切なタイミングで実行することで、省人化に寄与しながら売上向上や廃棄削減を目指すことができます。 アーキテクチャ POS data analysis agents は、バックグラウンドで定期的に実行され、あらかじめ設定されたベテラン担当者の業務知識から生成されたプロンプトに基づいて POS データを分析し、施策を提案します。また、提案した施策に対して、店舗担当者の追加の質問を受け付け、データに基づいてパーソナライズされた対話を行います。 活用されている AWS サービスと、AI エージェントの構造 本ソリューションは、AWS の生成 AI サービスと、サーバーレスアーキテクチャを組み合わせた構成により実現されています。AI エージェントとは、事前に設定された目標を達成する自律型 AI システムです。従来のソフトウェアと異なり、事前定義済みのワークフローを必要とせず、AI エージェント自身がタスクを立案し、自動で実行することができます。AI エージェントの最もシンプルな定義は、 1) モデル 、 2) ツール 、 3) プロンプト 、の 3 つの要素の組み合わせです。 本ソリューションでは、下記の AWS サービスを活用しています。 Amazon Bedrock は、AI エージェントの「モデル」に利用しています。Claude 4.5 Sonnet の高度な自然言語処理能力により、ベテラン担当者から自然言語で与えられた業務知識を理解し、エージェントへ与える「プロンプト」に変換します。また、Amazon Bedrock は リアルタイムデータとデータベーススキーマを入力に SQL を生成する役割も持ちます。これにより、刻々と変化する状況に対応した施策を提案します。 Amazon Bedrock AgentCore は、効果的なエージェントを大規模かつ安全に構築、デプロイ、運用するためのエージェントプラットフォームです。AgentCore サービスの一つである AgentCore Runtime は、AI エージェントやツールをデプロイして実行するための、安全でサーバーレスの専用ホスティング環境を提供します。本ソリューションでは、AWS が開発したオープンソースの SDK である Strands Agents SDK を利用して開発した AI エージェントを AgentCore Runtime にデプロイしています。AI エージェントには、データベースに対して SQL を実行したり、 Amazon DynamoDB に対して推奨アクションを登録するなどの「ツール」が与えられていて、必要なタイミングで実行することができます。また、 AgentCore Memory は、AIエージェントが過去の対話を記憶できるようにするサービスです。本ソリューションでは、PC やスマートフォンを通じて AI エージェントが担当者と会話をする際に、過去の会話に基づいたパーソナライズされた応答を実現しています。 Amazon DynamoDB は、一桁ミリ秒のパフォーマンスを実現する、サーバーレス NoSQL フルマネージドデータベースです。本ソリューションでは、ベテラン担当者の豊富な経験と知見に基づいて生成されたプロンプトや、AI エージェントによって生成された推奨アクションが保存されています。 Amazon EventBridge は、イベントを使用してアプリケーションコンポーネント同士を接続するサーバーレスサービスです。これにより、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。本ソリューションでは、定期的に AI エージェントを起動させるために使用されます。 AWS の技術支援を活用した開発プロセス 本ソリューションは、東芝テックが AWS の技術支援のもと開発しました。開発プロセスでは、まず AWS のサンプルソリューション を活用したワークショップを実施し、東芝テックから提供された POS データを用いて AI エージェントの可能性を検証しました。このワークショップを通じて、小売業界特有の課題と AI 活用の方向性を明確化することができました。 続いて、AWS のプロトタイピングプログラムを活用し、具体的なソリューションの実装支援を行いました。東芝テックの豊富な業界知見と、AWS のクラウド・ AI 技術を組み合わせることで、従来解決が困難だった課題へのソリューションが実現しました。 本プロジェクトをリードした、東芝テック株式会社 執行役員 リテール・ソリューション事業本部 副事業本部長、同プロダクト・プランニング&クリエーションセンター長の石川 尚氏は、AWS との連携についてこのようにコメントしています。 東芝テックは、AIやクラウド技術の活用を通じて、小売業界のDXを強力に推進しています。今回、AWSの技術支援のもと、現場の課題解決に直結するAIエージェントを開発できたことは、当社のビジョン実現に向けた大きな一歩です。 小売現場の人手不足や業務の複雑化といった社会的課題に対し、データドリブンな意思決定支援を提供することで、より効率的で持続可能な店舗運営を実現します。 今後も AWS との協力を通じて、業界の未来を切り拓く革新的なソリューションを提供し続けてまいります。 東芝テック株式会社 執行役員 リテール・ソリューション事業本部 副事業本部長 同プロダクト・プランニング&クリエーションセンター長 石川 尚 氏 リテールテックJAPAN 2026での展示について 展示概要 会期 : 2026年3月3日(火)〜6日(金) 会場 : 東京ビッグサイト 東芝テックブース : 東展示棟 4ホール RT4201 東芝テックの告知ページ : https://www.toshibatec.co.jp/event/exhibition/rtj2026.html 小売業界の未来への展望 本ソリューションは、小売業界におけるAI活用の新たな可能性を示すものです。データドリブンな意思決定支援により、以下のような未来の実現を目指しています: 人手不足の解決 : 経験に依存しない店舗運営の実現 収益性の向上 : データに基づく最適な価格設定と在庫管理 顧客満足度の向上 : 適切な商品配置と在庫確保による購買体験の改善 環境負荷の低減 :廃棄ロス削減により、製造・輸送・廃棄における資源消費や GHG 排出量を軽減 東芝テックと AWS は、今後も小売業界の DX を支援し、より効率的で持続可能な店舗運営の実現に向けて取り組んでまいります。リテールテック JAPAN 2026の東芝テックブースにて、ぜひこの革新的なソリューションのデモをご体験ください。小売業界の未来を一緒に創造していきましょう。 お問い合わせ 東芝テック株式会社: 公式ウェブサイト Amazon Web Services: AWS公式サイト 本記事は東芝テック株式会社とアマゾン ウェブ サービス ジャパン合同会社の共同執筆によるものです。 著者 小川 翔 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売業界のお客様を中心にクラウド活用の技術支援を行なっています。好きな AWS サービスは Amazon Bedrock と、Amazon Personalize です。 谷 梨奈子 アマゾンウェブサービスジャパン合同会社 アカウントマネージャー 製造業のお客様を中心にクラウド活用に対する営業支援を行っております。MigrationからAI活用まで幅広い分野を提案させていただきます。
本記事は 2026 年 2 月 17 日に公開された Nima Kaviani による “ Claude Sonnet 4.6 is now available in Kiro ” を翻訳したものです。 本日より、 Kiro IDE と CLI で Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.6 は Sonnet 4.5 からの完全なアップグレードであり、ソフトウェア開発において Opus 4.6 に匹敵する知能を持ちながら、よりトークン効率が高く、ワークフロー全体でより高速で高品質なタスク完了を実現します。 一日中使いたくなるコーディングモデル Sonnet 4.6 は、複雑なコードベースを手取り足取り誘導する必要がないほど賢いモデルです。機能構築、リファクタリング、デバッグなどの反復的なワークフローを処理し、進行中にモデルをガイドしても品質を損ないません。Sonnet 4.6 は、インタラクティブな開発作業において優れた体験を提供します。 複数のタスクを含む spec を進めている際、Sonnet 4.6 は長いセッション全体でコンテキストと精度を維持します。マルチモデルパイプラインにおいて、リードエージェントとサブエージェントの両方の役割を果たし、適応的な思考とコンテキスト圧縮により、作業の進め方を正確に制御できます。 エージェント作業のために構築 Sonnet 4.6 は、現代の AI 開発が要求する複数ステップのオーケストレーションのために特別に構築されています。ツール呼び出しを処理し、長いセッション全体で状態を維持し、複雑な推論チェーンを管理します。これらすべてを、大量使用を実用的にする価格帯で実現します。 Kiro powers や カスタムサブエージェント を使用しているチームにとって、Sonnet 4.6 は自然に組み込まれます。パイプラインの異なる部分に異なるモデルを必要とせず、オーケストレーターとワーカーの両方の役割を果たすことができます。 利用可能性 Sonnet 4.6 は、Google、GitHub、AWS BuilderID、AWS IAM Identity Center でログインするすべての Kiro Pro、Pro+、Power のお客様にご利用いただけます。Sonnet 4.6 は AWS US-East-1(バージニア北部)および AWS Europe(フランクフルト)リージョンで利用可能で、Sonnet 4.5 と同様に 1.3 倍のクレジット乗数を備えており、開発作業においてコスト効率が良くなっています。 Kiro をダウンロード するか、アプリまたは CLI を再起動して新しいモデルを使用してください。 翻訳は Solutions Architect の吉村が担当いたしました。
本ブログは、メック株式会社 様と Amazon Web Services Japan が共同で執筆いたしました。 みなさま、こんにちは。AWSアカウントマネージャーの尾田です。 生成 AI が注目されてから数年が経ち、多くの活用事例が生まれています。特に最近では「エージェント」というキーワードも⾮常に注⽬されており、今まで以上に、複雑な業務に AI を活⽤できるようになってきています。 本ブログでは、AI エージェントを活⽤して研究業務の効率化や品質の底上げに取り組まれたメック株式会社様の事例についてご紹介いたします。同社は、AWS 主催のハッカソンイベントへの参加をきっかけに、わずか約3 週間という短期間でソリューションを構築しており、どの程度の効果が出るか検証を進めていく PoC フェーズにおいて、スモールスタートで素早く取り組まれた事例となっております。また、アーキテクチャの中には、Amazon Bedrock AgentCore や、Amazon S3 Vectors を利⽤しており、技術的にも先進的な取り組みとなっております。 お客様の取り組みの背景と目指す姿 企業の研究開発部門において、蓄積された専門知識や技術情報を組織全体の資産として最大限に活用し、全メンバーが高いレベルで業務を遂行できる環境を構築することは、競争力強化の鍵となります。同社では、生成 AI とエージェント技術の進化を好機と捉え、研究業務における次世代の働き方の実現に向けて、先進的な取り組みに挑戦しました。 組織全体の研究力の底上げと標準化 同社が目指したのは、ベテラン社員が持つ高度な検索スキルや情報収集のノウハウを AI エージェントとして実装し、組織全体で共有できる仕組みの構築です。経験年数に関わらず、すべての研究開発メンバーが高品質な情報へアクセスし、迅速な判断を行える環境の実現を目指しました。 複雑な専⾨領域における情報アクセスの革新 研究業務では、専門用語と関連技術が複雑に絡み合っており、適切なアプローチで情報にアクセスすることが重要です。同社は、AI エージェントが自律的に最適な検索クエリを生成し、ユーザーの真の目的に沿った情報を提供する仕組みの構築に取り組みました。これにより、複雑な専門領域においても直感的に情報へアクセスできる環境の実現を目指しています。 知的資産の戦略的活用基盤の構築 日々蓄積される研究データや新規情報、更新される技術情報を、単なるデータとして保管するのではなく、戦略的な知的資産として最大限活用できる基盤の構築を目指しました。AI エージェントによって、情報に適切なコンテキストやメタデータを自動付与し、組織の知見を継続的に進化させる仕組みの実現に取り組まれました。 ソリューション・構成内容 ソリューションイメージ図 同社の目指す姿を実現するため、単純な RAG アーキテクチャや情報更新の⾃動化ではなく、検索と情報更新の 2 つの領域で AI エージェントを活用したソリューションを構築しました。 情報検索エージェント ユーザーからの質問を受け取り、最適な情報を提供します。特徴的なのは、ユーザーの質問⽂をそのまま検索クエリとして使⽤するのではなく、専⾨技術のバックグラウンド知識をもとに、ユーザーの真の⽬的に沿った情報を取得できるよう、裏側で最適なクエリを⾃動⽣成します。また、得られた結果がユーザーの⽬的に沿わない場合は、必要に応じて複数回の検索を⾏います。これにより、すべてのメンバーがベテラン社員と同等レベルの情報アクセスが可能になります。 情報更新エージェント 新規情報の追加時に、単に⽂書をそのまま登録するのではなく、コンテキスト情報を付与します。具体的には、「どのような案件の、どのような相談をもとに必要となった情報なのか」という追加に至る背景情報などを付与します。また、情報の中⾝を確認した上で、メタデータを⾃動⽣成し、検索性を高めた形で情報更新を⾏います。これにより、組織の知的資産が体系的に蓄積され、継続的に価値を生み出す仕組みとなります。 アーキテクチャ図 特に注⽬すべき点は、AI エージェントが動く基盤として、Bedrock AgentCore Runtime を利⽤されている点です。Bedrock AgentCore Runtime は、AI エージェントとツールのデプロイおよびスケーリング専⽤に構築された、セキュアでサーバーレスなランタイム環境です。Bedrock AgentCore Runtimeを利⽤することで、AI エージェントが動くインフラストラクチャの構築・管理をサービス側にまかせることができる点や、将来的な本番運⽤を⾒越し、セキュリティや認証・認可、運⽤性の観点から、採⽤をいただいております。同社はStrands Agents で作成した AI エージェント及び RAG を利⽤するためのツールを Runtime 上にデプロイされています。また、RAG アーキテクチャは、利⽤形態を加味して、S3 Vectors を利⽤してコストを最適化されております。 本ソリューションでは、RAG が AI エージェントが利⽤できるツールの⼀つとなっており、単純な検索システムではなく、ユーザーの意図を理解し、最適な情報取得に向けて⾃律的に動作する仕組みとなっております。開発中に Bedrock AgentCore が一般提供を開始するというタイミングで、Bedrock AgentCore をご利⽤いただいておりましたが、 Amazon Bedrock AgentCore starter toolkitをはじめとしたリソースを活⽤することで⾮常に⾼速に AI エージェントのデプロイができたというお⾔葉もいただいております。 導⼊効果 本ソリューションにより、以下の効果が期待されます。 情報検索時間の短縮:すべてのメンバーが迅速かつ的確に必要な情報へアクセスでき、組織全体の生産性向上が見込まれます 研究業務レベルの底上げ:検索エージェントが適切なクエリを自動生成することで、経験年数に関わらず高品質な情報収集が可能になります 知的資産の継続的な進化:情報更新エージェントにより、調査結果や研究知見、最新情報が体系的に整備・自動更新され、戦略的に活用できる基盤が構築されます まとめ 本ブログでは、メック株式会社様の先進的な取り組みをご紹介しました。AI エージェントを活⽤することで、複雑な業務の効率化だけでなく、組織全体の能力向上につながることがイメージいただけたのではないでしょうか。ユーザーの⽬的を理解して、⽬的達成に向けて⾃律的に動く点が、エージェントの⼀番のポイントになってくるかと思います。 同社は、AI エージェントの活⽤を更にブラッシュアップしていき、より多くの業務での活⽤を進めることで、研究開発における競争力をさらに強化していくとのことです。 本事例が、生成 AI やエージェント技術を活用した業務効率化をご検討中のお客様の参考になれば幸いです。Amazon Bedrock AgentCore を活用したソリューション構築にご興味をお持ちの方は、お気軽にお問い合わせください。 メック株式会社(左から): 古川 智大 様 岸本 宗真 様 足立 優司 様 Amazon Web Services Japan 合同会社: ソリューションアーキテクト 上野 涼平(左端) アカウントマネージャー尾田 美菜(右端)
本記事は「 New spec types: fix bugs and build on top of existing apps 」を翻訳したものです。 モノリスからマイクロサービスへの移行を進めているとします。アーキテクチャはすでに明確で、イベント駆動、非同期メッセージング、特定のレイテンシ要件があります。必要なのは実装の手助けだけです。あるいは、バグを修正しているとします。何が壊れていて、何をそのままにすべきかはわかっています。外科的な修正が必要です。アプリの他の部分を変更したり、トークンを無駄に消費して堂々巡りすることなく、エージェントと協力してこれらの目標を達成する最善の方法は何でしょうか? Specs と仕様駆動開発ワークフローをリリースした際、私たちは従来の PM/エンジニアリングのフローに基づいて構築しました。まず要件、次に設計、そしてタスクという流れです。これは多くのプロジェクトでうまく機能し、何十万人もの開発者が新しいものを構築する際にこのアプローチをデフォルトとして採用してきました。 しかし、Kiro ユーザーと話す中で、明確なパターンが見えてきました。すべての人が要件から始めるわけではないということです。特に既存のブラウンフィールドアプリで作業する場合、技術アーキテクチャがすでに決まっている状態で取り組む開発者もいます。バグ修正をしていて、何を変更し何を変更すべきでないかを慎重に定義する必要がある開発者もいます。Specs の構造は手放したくないが、現在のフローではこれらのタイプのタスクに対して十分な柔軟性がありませんでした。 開発者がすでに取り組んでいるプロジェクトへのアプローチを変えるよう求めたくはなかったので、本日、デザインファーストワークフローとバグ修正 の 2 つの新しい Spec をリリースします。 硬直的なワークフローが失敗する理由 Specs を最初に設計した際、私たちは Laurence Tratt が提唱する ソフトウェア開発における「循環的仕様問題」と「観察者効果」に動機づけられていました。Tratt は根本的な緊張関係を指摘しています。 構築したいソフトウェアを正確に知る唯一の方法は完全に仕様化することだが、完全な仕様はソフトウェア自体を作成するのと少なくとも同じだけの作業量が必要である ということです。これは、ソフトウェアを真に仕様化するためにはソフトウェアを構築しなければならないという鶏卵問題になってしまいます。特に大規模プロジェクトでは、これは希望的観測にすぎません。Tratt が観察するように、ソフトウェアは空想と現実の間の「リミナルな状態」にあり、実際に何かを構築するまで定量化が難しいソフトな制約に満ちています。ソフトウェアを作成する行為自体が仕様化の行為なのです。これは計画なしで作業するということではなく、素早く進捗できるだけの十分な構造を持つ中間地点に到達するということです。 要件ファーストとデザインファーストは同じコインの表と裏であり、この循環的仕様問題の異なる側面に対処しています。 要件ファースト は、必要な振る舞いや成果は理解しているが、技術的な道筋が不明確な場合に機能します。「これは何をすべきか?」を「どのように動作すべきか?」の前に探求します。選択肢が開かれている新規プロジェクトに最適なオプションです。 デザインファースト は、経験、アーキテクチャ上の制約、またはプロトタイピングから技術的なビジョンをすでに持っていて、そのシステムが実際に何を達成するかを逆算して形式化する必要がある場合に機能します。ソリューションをホワイトボードに描いてから「この製品が何をするか」をまとめるようなものです。既存のアプリの上に新しい機能を構築する場合にも適用できます。現在のアーキテクチャと技術スタック内で作業する必要があるからです。 どちらのアプローチもイテレーションとフィードバックを重視しています。どちらもソフトウェアを事前に完璧に仕様化できるとは主張しません。代わりに、あなたの思考の現在地に合わせて、異なる出発点から循環的仕様問題に取り組む手助けをします。 デザインファースト Spec : 技術的アプローチから始める 次のプロンプトを考えてみましょう。 Wiki とデータレイク用の MCP サーバーを作成したい。タスクを分解して見積もりを出してほしい。FastAPI と mcp-python を使用。UI は不要。 この開発者はすでにスタック(FastAPI と mcp-python)、ハイレベルアーキテクチャ(MCP サーバー)、制約(UI 機能なし)を把握しています。「何を構築すべきか?」ではなく、「すでに設計したこのものを構築する手助けをしてほしい」と求めています。この場合、設計ドキュメントから始める方が理にかなっています。なぜなら、開発者がすでに問題について考えている方法と一致するからです。 そこで、新しい Feature Spec を作成する際、Kiro は選択を求めるようになりました。 要件ファースト または技術 デザインファースト です。技術デザインファーストを選択した場合、詳細レベルを選びます。システム図やコンポーネントのハイレベル設計か、アルゴリズムや関数シグネチャのローレベル設計かです。Kiro はまず設計ドキュメントを生成します。それをイテレーションし、さまざまな技術的アプローチを探求します。満足したら、Kiro は設計から要件を導出し、実現可能性を確保します。残りの Spec ワークフローは同じです。タスク、実装、実装が望んだものと一致するかを確認するプロパティベーステスト。 技術デザインファーストは、事前に定義されたアーキテクチャがある場合、何かが実現可能かどうかを確認するためにプロトタイピングしている場合、または設計の選択肢を制約する厳格な非機能要件がある場合に特にうまく機能します。技術的アプローチが出発点であり、目的地ではない場合に最適です。 バグ修正 Spec : 精密にバグを修正する バグを修正する際には、異なる制約と目標があります。新しいものを構築するのではなく、既存のものを修正します。影響範囲も異なります。変更しすぎると、正常に動作していたものを壊すリスクがあります。問題を修正する最小限の変更が求められます。 では、エージェントと協力してそれを行う最善の方法は何でしょうか? Specs を使ってバグ修正に成功した開発者には 2 つの共通点がありました。第一に、エラーメッセージだけでなく、エラーを引き起こした詳細なシナリオを定義していました。第二に、変更すべきでないものを明示的に述べていました。これは経験豊富な開発者がバグ修正について考える方法です。壊れているものを修正し、それ以外には触れません。 バグ修正 Spec を作成すると、Kiro は同様のアプローチに従い、3 つのセクションを持つ構造化されたドキュメントを生成します。 現在の振る舞い(Current Behavior) は、現在何が起きているかを記述します。「WHEN ユーザーが特殊文字を含むフォームを送信した場合、 THEN システムはバリデーションエラーでクラッシュする(THEN)」。このステップでより包括的に記述することで、Kiro はバグが発生する条件をより正確に診断できます。 期待される振る舞い(Expected Behavior) は、代わりに何が起こるべきかを記述します。「WHEN ユーザーが特殊文字を含むフォームを送信した場合、THEN the system SHALL 入力をサニタイズしてフォームを正常に処理する」。これにより、Kiro は解決された状態がどのようなものかを把握し、実際にバグが修正されたかを後で確認できます。 変更されない振る舞い(Unchanged Behavior) は、そのままでなければならないものを記述します。「WHEN ユーザーが有効なフォームを送信した場合、THEN the system SHALL CONTINUE TO 従来通りに処理を継続する」。変更すべきでないものを暗黙的にするのではなく、バグ修正 Spec はそれを明示的に述べます。これにより、Kiro はリグレッションが導入されていないことを確認し、検証するプロパティテストに反映できます。 この構造により、何が変わり何が変わらないかを明示的に考えることが強制され、基盤となるモデルがあなたの意図をより正確に理解する助けになります。Kiro はこれらのセクションを自動的に構築するため、この .md を自分で書く時間を費やす必要はありません。これらの条件をレビューして改善し、その後 Kiro は Feature Spec と同様に design.md と tasks.md の作成に進みますが、外科的な修正に特化した内容になります。 これがうまく機能する理由は、Kiro 独自のテスト方法にあります。Kiro は 3 つのカテゴリすべてに対してプロパティベーステスト(PBT)を生成します。現在の実装にバグがあることを検証するテスト、修正がバグを解決したことを検証するテスト、そして変更されない振る舞いが以前とまったく同じように動作し続けることを検証するテストです。これらの PBT がなければ、エージェントが包括的な条件セットに対して実際にバグを修正したかどうか、そして変更が本当に外科的であったかどうかを確認することは困難です。 バグ修正 Spec は、構造化された問題解決が有効な複雑なバグ、リグレッションリスクが高い状況、または修正のドキュメントが必要な場合に威力を発揮します。 あなたに適応するツール Specs は、多くの開発者が堅牢なソフトウェアを出荷するための AI 開発へのアプローチを変えました。しかし、既存のアプリ、特に大規模なコードベースで作業する場合、異なるアプローチを好むかもしれません。要件から始める場合もあります。構築したいものが正確にわかっているからです。技術的アプローチがすでに決まっていて、交渉の余地がない場合もあります。バグを修正していて、すべてのユーザーに影響するリグレッションを避けるために外科的な精度が必要な場合もあります。今では Specs は 3 つのユースケースすべてをサポートしています。 ドキュメント で Feature Spec と バグ修正 Spec の詳細をご覧ください。Kiro IDE を ダウンロード または再起動して、Specs の新しいアプローチをお試しください。
本ブログは、三菱電機株式会社 電力システム製作所 電力ICTセンター 小森様と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト稲田、GitLab 合同会社 ソリューションアーキテクトの小松原様の共著です。三菱電機 電力ICTセンターにおける Kiro と GitLab を組み合わせたソフトウェア開発効率化の取り組みについてご紹介します。 電力ICTセンターについて 三菱電機 電力システム製作所 電力ICTセンターは、再生可能エネルギーの拡大や電力自由化に対応する電力×ICTの専門組織です。電力取引・需給管理から、分散型電源/VPP、蓄電池制御、スマートメーター、託送・精算、環境価値管理、アセットマネジメントまで、電力事業全体をカバーする主力ソリューション「 BLEnDer(ブレンダー) 」を開発しています。BLEnDer を軸に電力の”見える化→判断→計画→制御”を一気通貫で実現する電力デジタルソリューションを提供し、電力会社様、送配電事業者様、小売電気事業者様、発電事業者様など、幅広い事業者様を支えています。 これまでの取り組みと課題 電力ICTセンターでは、ソフトウェア開発の効率化に向けてさまざまな取り組みを行ってきました。 GitLab をベースにした CI/CD 環境の構築 Amazon Bedrock を活用した RAG システムの開発(開発工数見積もりの支援) Amazon Bedrock を活用した設計書レビューの効率化 CI/CD ツールを活用したビルド・テスト・デプロイ作業の効率化 ワークフロー自動化ツールを活用した申請フローの自動化 これらのシステムやツールはそれぞれ開発効率化に寄与していますが、 導入・展開時に共通の課題 がありました。 開発したシステムやツールは、基本的に納入先の開発チームに運用・保守を担っていただきます。そのため、利用方法を示したドキュメントや設計ドキュメントの作成、利用フローの整備が不可欠です。時には勉強会を開催し、必要なスキルを習得していただく必要もありました。しかし、毎回フルセットで伴走支援を行うことは現実的ではなく、ドキュメントや勉強会だけで実践していただくには限界があると感じていました。 「ドキュメントを読まなくても、AI に聞けばワークフローに沿った開発ができる」 ― そんな仕組みを実現するために、Kiro と GitLab を組み合わせた新しいアプローチに取り組んでいます。 Kiro の Steering・Powers・MCP とは 本題に入る前に、今回の取り組みで活用している Kiro の主要機能について説明します。 Steering:プロジェクト横断のグラウンドルール Steering は、Kiro の振る舞いに対して 常に適用されるグラウンドルール を定義する仕組みです。プロジェクトのルートディレクトリに .kiro/steering/ ディレクトリを作成し、マークダウンファイルでルールを記述します。 .kiro/ └── steering/ ├── coding-standards.md # コーディング規約 ├── language.md # 言語設定(日本語で回答する等) └── security.md # セキュリティポリシー Steering に記述したルールは、 どの Power が発動しているかに関わらず常に Kiro のコンテキストに読み込まれます 。そのため、「日本語で回答すること」「機密情報をコードに含めないこと」といった、プロジェクト全体で一貫して守るべきルールの定義に適しています。 電力ICTセンターでは、プロジェクト固有ではない共通のグラウンドルール(言語設定、コーディング規約の基本方針など)を Steering で管理しています。 Powers:動的に呼び出されるワークフロー定義 Powers は、Steering とは異なり、 ユーザーの発話内容に応じて動的に呼び出される ルール定義の仕組みです。Power は POWER.md というメタデータファイルと、 steering/ ディレクトリ配下のステアリングファイル群で構成されます。 .kiro/powers/ └── my-power/ ├── POWER.md # Power のメタデータ(name, description, keywords) ├── mcp.json # この Power 専用の MCP サーバー設定(任意) └── steering/ ├── guide-a.md # ステアリングファイル A └── guide-b.md # ステアリングファイル B POWER.md の frontmatter には keywords を定義でき、ユーザーの発話にこれらのキーワードが含まれると、その Power が動的に発動します。 --- name: "standard-dev-flow" displayName: "Standard Dev Flow" description: "GitLab を使用した開発ワークフローを標準化する Power" keywords: ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"] --- Steering との使い分けのポイント は、コンテキストウィンドウの効率です。Steering は常に読み込まれるため、大量のルールを定義するとコンテキストを圧迫します。一方、Powers は必要なときだけ動的に読み込まれるため、ワークフロー固有の詳細なルール(数千行に及ぶガイドラインなど)を定義しても、関係ないタスクの際にはコンテキストを消費しません。 電力ICTセンターでは IDE での利用が多く、IDE 上で Power が動的に呼び出されていることを視覚的に確認できる点に安心感を感じています。「いま Kiro がどのルールに従って動いているか」が見えることで、AI の振る舞いを制御できている実感が得られます。 Kiro から Power を呼び出すイメージ MCP(Model Context Protocol):外部ツールとの連携 MCP は、Kiro が外部のツールやサービスと連携するためのプロトコルです。MCP サーバーを定義することで、Kiro が GitLab API の操作や独自のスクリプト実行など、IDE の外にある機能を呼び出せるようになります。 Power ごとに mcp.json を配置できるため、 特定のワークフローでのみ必要な MCP サーバーを、その Power に紐づけて管理 できます。例えば、Standard Dev Flow Power には GitLab 操作用の MCP サーバーを、Playwright Power にはテスト実行用の MCP サーバーを、といった使い分けが可能です。 3 つの機能の関係性 まとめると、以下のような役割分担になります。 機能 適用タイミング 用途 Steering 常時 プロジェクト横断のグラウンドルール Powers キーワードに応じて動的 ワークフロー固有の詳細ルール・手順 MCP Power に紐づけて動的 外部ツール・API との連携 この3層構造により、「常に守るべきルール」「タスクに応じて必要なルール」「外部ツールとの連携」を整理して管理でき、コンテキストウィンドウを効率的に活用しながら AI エージェントの振る舞いを制御できます。 現在の取り組み:Kiro × GitLab による開発プラットフォーム 全体像 現在、CI/CD を中心としたソフトウェア開発サイクル全体の効率化に取り組んでいます。 開発ワークフローの整理(ブランチ戦略・リリース戦略を含む CI/CD 環境の整備) アプリケーションのデプロイ方法の検討、テスト自動化環境の整備 GitLab CI/CD カタログを活用したパイプラインの標準化 ガイドラインの整備 これらの取り組みにおいて、Kiro と GitLab をどのように活用しているかをご紹介します。 Kiro の活用:Powers による開発ワークフローの標準化 Kiro では 2 つの Power (Standard Dev Flow Power, Playwright Power) を利用しています。それぞれについて解説します。 その 1: Standard Dev Flow Power 開発ワークフロー全体を標準化する Power を作成しました。以下のワークフローを Kiro に定義しています。 1. Issue 作成 → 2. ブランチ作成 → 3. 実装 → 4. コミット → 5. MR 作成 → 6. レビュー → 7. マージ この Power には、各フェーズに対応するステアリングファイルが含まれています。 standard-dev-flow/ ├── POWER.md # Power 定義(ワークフロー全体像) ├── mcp.json # MCP サーバー設定 └── steering/ ├── issue-management.md # Issue 作成ガイド ├── branch-commit-mr.md # ブランチ・コミット・MR作成ガイド ├── implementation.md # 実装作業ガイド ├── gitlab-duo-review.md # GitLab Duo レビューワークフロー ├── pipeline-troubleshooting.md # パイプライン失敗解析ガイド └── gitlab-official-mcp-tools.md # GitLab 公式 MCP ツールリファレンス POWER.md にはワークフローの全体像と各ステアリングファイルの参照タイミングを記述しています。例えば、「新しい Issue を作成する際は issue-management.md を参照」「パイプラインが失敗した際は pipeline-troubleshooting.md を参照」といった形で、Kiro がどのフェーズでどのルールを適用すべきかを明示しています。 各ステアリングファイルには、そのフェーズで Kiro が従うべき具体的なルールが記述されています。例えば branch-commit-mr.md には以下のようなルールが含まれます。 ブランチ命名規則: feature/{issue-number}-{brief-description} 形式 Conventional Commits 1.0.0 準拠のコミットメッセージ(type/scope/description/body の構造化、日本語での記述) MR 作成時の squash merge による 1 コミットへの集約 MR テンプレート(変更内容/テスト/レビュー観点/補足)に基づいた記述 開発者は Kiro に「Issue #123 の実装を開始してください」と伝えるだけで、Power に定義されたワークフローに沿って作業が進みます。Kiro は自動的に以下を実行します。 ブランチの確認・切り替え Issue の内容確認と tmp/{タスク名}-issue-details.md の作成 実行計画の作成( tmp/{タスク名}-plan.md ) 実装作業の実施 作業サマリーの作成( tmp/{タスク名}-summary.md ) このように、 作業の追跡ファイルを自動生成する仕組み も Power に組み込んでいます。Issue の詳細理解、チェックリスト形式の実行計画、作業完了後のサマリーを tmp/ ディレクトリに残すことで、作業の透明性を確保しています。 Standard Dev Flow Power には、GitLab 公式 MCP サーバーと独自の MCP サーバーの両方を mcp.json で定義しています。 GitLab 公式 MCP サーバーが提供する主なツール: create_issue / get_issue :Issue の作成・取得 create_merge_request / get_merge_request :MR の作成・取得 search / semantic_code_search :検索機能 独自 MCP サーバー(GitLab MCP Enhancer)で補完しているツール: get_mr_discussions / reply_to_discussion / resolve_all_discussions :MR ディスカッション操作 list_merge_requests / update_merge_request :MR の一覧・編集 list_issues / update_issue / add_issue_note :Issue の一覧・編集 get_latest_pipeline / get_pipeline_jobs / get_job_log :パイプライン解析 この 2 つの MCP サーバーを組み合わせることで、Issue 作成から MR レビュー対応、パイプライン失敗の解析まで、 GitLab の操作をほぼ Kiro 上で完結 できるようになりました。 その 2: Playwright Power 次のステップとして、Playwright を活用した E2E テスト生成のための Power も作成しています。 playwright/ ├── POWER.md # Power定義 └── steering/ ├── playwright-rule.md # コーディング規約・POM変換手順 ├── playwright-cli.md # playwright-cli の使い方 └── test-best-practices.md # テスト実装のベストプラクティス この Power のポイントは、 playwright-cli の出力から Page Object Model(POM)への変換手順 をステアリングファイルに詳細に定義している点です。playwright-cli はコーディングエージェント向けに設計された CLI ベースのブラウザ自動化ツールで、操作ごとに Playwright コードを出力します。 playwright-rule.md には、この出力コードから POM クラスへ変換する 3 ステップの手順が定義されています。 ロケーター抽出 :出力コードから要素を特定 readonly 定義 :コンストラクタでロケーターを宣言 アクションメソッド :操作をメソッドに抽象化 さらに、ロケーター戦略の優先順位も明確に定義しています。 getByRole() – ボタン、リンク等のセマンティック要素 getByLabel() – フォーム要素 getByPlaceholder() – プレースホルダーテキスト getByText() – 表示テキスト getByTestId() – テスト専用属性 CSS/XPath – 最後の手段 test-best-practices.md には、AAA パターン(Arrange/Act/Assert)によるテスト構造化、アサーション強化( toBeVisible() だけでなく toHaveText() で内容確認)、テスト安定化テクニック(スピナー待機、古い DOM の回避)など、実践的なベストプラクティスが記述されています。 これらのルールを Power に落とし込むことで、 誰が Kiro にテスト生成を依頼しても、組織のベストプラクティスに沿った一貫性のあるテストコードが生成されます 。 GitLab の活用 GitLab Pages によるガイドライン公開 プラットフォームを他 BU に展開するにあたり、ガイドラインの整備は不可欠です。GitLab Pages を活用し、マークダウンで記述したガイドを静的 Web サイトに変換して公開しています。ガイドには、GitLab CI/CD カタログを活用した標準パイプラインの説明や、GitLab Duo や Kiro の基本的な使い方や Tips を掲載しています。関連するソースコードはすべて GitLab で管理しており、ソースコードの修正があれば生成 AI を活用して即時にガイドに反映・公開できるため、管理の手間を感じません。 ここで重要なのは、 Powers には基本的にガイドに書いてあることをそのまま落とし込んでいる という点です。これにより、ガイドの内容と AI の振る舞いが常に一致し、「ガイドを読む」か「AI に聞く」かのどちらでも同じ情報にたどり着ける状態を実現しています。 GitLab Pages の利用イメージ CI/CD カタログによるパイプラインの標準化 GitLab CI/CD カタログを作成し、アーティファクトやキャッシュの設定を含むパイプラインテンプレートを配布しています。ユーザー側は環境固有のパラメータ値のみを入力すれば、即座に使用可能な状態です。 GitLab Duo による MR レビュー:AI 同士の協働 Kiro でコーディングを行い、MR を作成した後、GitLab Duo にレビューを依頼するワークフローを構築しています。 生成 AI は自分で生成したコードに対して正しいという認知バイアスがかかる可能性があるため、 コード生成(Kiro)とレビュー(GitLab Duo)を異なる AI に担当させる ことで、より客観的なレビューを実現しています。 GitLab Duo へのレビュー観点は、社内の有識者を交えて mr-review-instructions.yaml に定義しており、レビューコメントに必ず prefix(接頭辞)を付けるルールを設けています。この prefix により、レビュー指摘の重要度が一目で判断できるようになります。 instructions: - name: Common Review Policy fileFilters: - "**/*" instructions: | - **言語**: すべての応答は必ず日本語で行ってください - レビューする際には、以下のprefix(接頭辞)を必ず付けてください - [must] → 必須修正、修正しないのであれば修正しない理由を開発者に求める - [want] → できれば対応してほしい、改善として望ましい提案 - [imo] → 個人的意見、好みベースの提案 - [ask] → 質問、意図・背景の確認 - [nits] → 細かい指摘(nitpicks)、超軽微なスタイル修正など - [info] → 参考情報、共有・補足・関連情報 一方、Kiro 側の Power( gitlab-duo-review.md )には、GitLab Duo のレビュー結果をどう受け取り、どう対応するかのルールを定義しており、GitLab Duo が付与する prefix に対して、Kiro がどのように判断・行動すべきかを明示しています。 ・・・ ### 2. GitLab Duoにレビュー依頼 **重要**: GitLab Duoのレビューは**新規ディスカッション**で`@GitLabDuo`をメンションすることで発動する。MR作成時のdescriptionに記載しても発動しない。 **レビュー依頼のポイント**: - 新規ディスカッションを作成する(これが必須) - `@GitLabDuo`はスペースなしで記載 - 依頼メッセージには以下を含めると効果的: &nbsp; - 実装内容の概要 &nbsp; - 特に確認してほしい点 &nbsp; - 変更理由や背景 &nbsp; - 参考資料: 関連ドキュメント ### 3. レビュー結果確認 **レビューコメントのprefix(重要度の判断基準)**: GitLab Duoのレビューには以下のprefixが付与される。これを基に対応の優先度を判断する。 | Prefix | 意味 | 対応方針 | |--------|------|----------| | `[must]` | 必須修正 | 修正必須。対応しない場合は理由を説明 | | `[want]` | できれば対応 | 改善として望ましい。可能な限り対応 | | `[imo]` | 個人的意見 | 好みベースの提案。採用は任意 | | `[ask]` | 質問 | 意図・背景の確認。回答が必要 | | `[nits]` | 細かい指摘 | 超軽微なスタイル修正。余裕があれば対応 | | `[info]` | 参考情報 | 共有・補足・関連情報。対応不要 | **[ask]への対応**: `[ask]`が付いた質問には、該当ディスカッションに`@GitLabDuo`メンション付きで返信して不明点を解消する。 ・・・ [ask] が付いた質問には、該当ディスカッションに @GitLabDuo メンション付きで返信して不明点を解消するルールも定義しています。 また、GitLab Duo へのレビュー依頼方法についても Power に明記しています。GitLab Duo のレビューは MR の description に記の最後に /assign_reviewer @GitLabDuo を記載することで発動します。こうした「知らないとハマるポイント」も Power に落とし込むことで、開発者が試行錯誤する手間を省いています。 以上を踏まえた、Kiro と GitLab Duo の協働ワークフローは以下の通りです。 Kiro で機能を実装し、MR を作成 GitLab Duo に MR レビューを依頼(MCP 経由) レビュー指摘を Kiro が取得し、対応可否を判断 対応が必要な指摘に対してコード修正を実施 修正をコミット・プッシュし、再度 GitLab Duo にレビューを依頼 承認後、全ディスカッションを一括解決 この AI 同士の協働によるレビューサイクル により、ある程度のクオリティが担保された状態で人間のレビュアーが入ることで、レビュー負担の軽減が期待できます。 この構成のメリット 1. 導入ハードルの大幅な低下 Power を活用して開発フローを定義しているため、開発者は Kiro に質問しながら作業を進めるだけで、ワークフローに沿った開発を行うことができます。分からないことは Kiro に質問して解決できるため、Kiro の基本的な使い方を覚えるだけで開発を始められます。BU への展開時に「AI がサポートしてくれるし、ガイドを特に読む必要はないよ」と伝えるだけでハードルがぐっと下がります。 2. 開発の証跡とコラボレーション Issue や MR で開発の証跡を残すことで、他の開発者とのコラボレーションが容易になります。Issue を追うことで、別の開発者が作業を引き継ぐことも容易になると考えています。 3. レビュー負担の軽減 コード開発の速度が上がる一方で、レビュー者への負担が増大するリスクがあります。GitLab Duo での観点に基づいたレビューと CI/CD パイプラインの実行結果を Kiro にフィードバックさせて改善することで、人間のレビュアーが入る前にある程度のクオリティを担保できます。人間のレビュー疲れやレビュー工数の削減にも寄与することを期待しています。 工夫した点と苦労した点 1 : Power の発動率を上げる工夫 Power に keywords を設定して呼び出しの工夫をしましたが、期待通りに発動しないケースがありました。例えば、Standard Dev Flow Power には ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"] といったキーワードを設定していますが、ユーザーの発話がこれらのキーワードに完全に一致しない場合、Power が発動しないことがありました。 調査の結果、 Power を積極的に活用するよう促す Steering ファイルを作成する ことで、利用率が向上しました。Steering は常にコンテキストに読み込まれるため、「利用可能な Power がある場合は積極的に活用すること」というルールを Steering に記述することで、Power の発動率を改善できます。AI エージェントツールを組織で活用する際には、こうしたチューニングが重要になります。 2: GitLab 公式 MCP サーバーの補完 GitLabの良さはそのカスタマイズ性の高さにあります。 公式 MCP サーバーを補完する独自の MCP サーバー(GitLab MCP Enhancer)を自作 しました。 gitlab-official-mcp-tools.md というステアリングファイルに 公式 MCP サーバー (Beta 版)の全 14 ツールのパラメータ定義と使用例を記述し、Kiro が正しくツールを使えるようにガイドしています。これによりMR ディスカッションの取得・返信・解決、Issue の一覧・編集、パイプラインのジョブログ取得など、 GitLab の操作が大幅に向上し、ほぼ Kiro 上で操作を完結できるようになりました。 今後の展望 直近では、現在作成中の Playwright Power を完成させ、E2E テスト生成の効率化を推進していきます。また、Playwright Power と並行して、SonarQube の MCP サーバーを活用し、静的解析結果を Kiro にフィードバックする仕組みの構築も検討し始めました。これにより、コードレビュー時だけでなく、実装段階からコード品質を高めるための仕組み作りにも取り組んでいます。このように、組織で活用が見込まれる OSS の活用を推進する Power を順次作成し、AI を活用してソフトウェア開発が楽になる土壌を広げていく方針です。また、GitLab Duo のレビュー観点も継続的に育てていき、適用範囲を広げることでレビュー負担のさらなる軽減を目指します。 1 : 効果の定量化と継続的な改善 AI 活用による開発効率化の効果を可視化するため、定量的な評価指標の測定に取り組んでいきます。Issue からマージまでのリードタイムやレビューイテレーション回数といった開発速度の指標、GitLab Duo のレビュー指摘の精度、Kiro の Playwright Power で生成されるコードの品質などを、実際に各ビジネスユニット (以降、BU)で使用していただきながら評価していきます。これらのフィードバックを基に、Power のルール定義の改善や MCP サーバーの機能拡張など、継続的な改善サイクルを回していきます。 2 : Power とパイプラインのエコシステム構築 Power や CI/CD パイプラインを組織全体で活用していくため、バージョン管理と配布の仕組みを構築していきます。GitLab で Power/MCP や CI/CD パイプラインテンプレートを一元管理し、GitLab Pages で導入方法・アップグレード方法を公開します。バージョン更新時には更新ダッシュボードでユーザーに通知し、各 BU からの要望は Issue やチケットで収集して継続的に改善します。また、既存の管理システムとの連携も視野に入れ、障害報告から修正、リリースまでの開発サイクル全体の効率化を図ります。 3 : 組織全体への展開とコミュニティ形成 中長期的には、電力ICTセンター内の各 BU への展開を加速させていきます。積極的な情報発信を通じて周囲を巻き込みながら、地道に活用の輪を広げていきます。Power やルール整備の取り組みは電力ICTセンターに閉じた話ではないため、ゆくゆくは三菱電機全社的な取り組みとして認知され、活用方法について議論できるコミュニティが形成されることを目指しています。まずは足元の電力ICTセンターのソフトウェア開発効率化につながる活動をどんどん進めていきたいと考えています。 まとめ 三菱電機 電力ICTセンターでは、Kiro の Steering・Powers・MCP と GitLab の各機能を組み合わせることで、 「AI に聞けばワークフローに沿った開発ができる」 プラットフォームの構築を進めています。 この取り組みの本質は、単なるツール導入ではありません。 Steering でプロジェクト横断のグラウンドルールを定義し Powers でワークフロー固有の詳細なルール・手順を動的に呼び出し MCP で GitLab をはじめとする外部ツールとシームレスに連携する この 3 層構造により、ガイドラインの内容を Powers に落とし込み、GitLab Pages で公開するガイドと AI の振る舞いを一致させることで、 ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける 仕組みを作っています。さらに、Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。 ソフトウェア開発の効率化は、ツールの導入だけでは完結しません。開発ワークフローの標準化、ガイドラインの整備、そしてそれらを AI エージェントに落とし込むことで、初めて組織全体の開発効率が向上します。本ブログが、同様の課題を抱える皆様の参考になれば幸いです。 著者 小森 裕之 電力システム製作所 電力デジタルエナジーシステム開発部 システム基盤課所属。 コーヒーと Kiro が大好きです! 電力ICTセンター内の全ビジネスユニットの開発・運用に貢献するため、ITIL4 に準拠した専用プラットフォームの開発に携わっており、主に CI/CD 環境の検討・構築・導入や AI エージェントツールを活用した開発の仕組みづくりを担当しています。 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。2022 年から三菱電機グループを支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。 小松原 つかさ GitLab 合同会社 シニアパートナーソリューションアーキテクト 長きに渡るソフトウェア開発経験を持ち、データベース、セキュリティ、ビッグデータの領域での深い専門知識を持ちます。2022 年にGitLab に参加し、AI 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。
このブログは、シスメックス株式会社 次世代医療事業開発室と、ディピューラメディカルソリューションズ株式会社、アマゾン ウェブ サービス ジャパン合同会社 シニア ソリューション アーキテクト 中島丈博による共著です。 シスメックス株式会社の視線計測アプリ「Gazefinder」のご紹介 背景 シスメックス株式会社は、「より良いヘルスケアジャーニーを、ともに。」をビジョンに掲げ、臨床検査機器・診断薬やソフトウェアを世界中に提供しています。2025 年 10 月、私たちは新たな領域への挑戦として、お子さまの視線をオンラインで計測し、個性や社会性の発達を可視化するサービス 「 Gazefinder 」 をトライアルリリースしました。子育てにおいてお子さまの興味の対象を知ることは重要ですが、日常の中で正確に把握するのは簡単ではありません。そこで注目されているのが、視線を通じてお子さまの興味や発達を理解する技術です。 サービス概要 「Gazefinder」は、一般的なノートパソコンに搭載されたカメラを使って、お子さまの視線を計測します。視線の計測結果から専門的な知見をもとに、お子さまの個性や社会性の発達を客観的に把握し、保護者やご家族が安心して子育てできるようにサポートします。 Gazefinder 子どもの視線をオンラインで計測。個性や社会性がわかります | シスメックス株式会社 特徴 ・視線計測の専用装置不要:ノートパソコンに搭載されたカメラで視線計測が可能で、計測後約 10 分で結果を確認できる ・専門的な知見に基づいたコメント:視線の計測結果は専門的な知見により解析が行われ、後日、視線から分かることがコメントとしてお手元に届く ・専門のオペレータによる解説:オンラインで個別のフィードバックを受けられる(有料) ・子育てに役立つ動画:専門のオペレータによる解説をご利用いただいた方に、興味・関心に応じた動画が配信される AWS アーキテクチャのご紹介 サーバーレスアーキテクチャによるアプリケーション 視線計測アプリ「Gazefinder」は サーバレスアーキテクチャ を採用しています。一般的にサーバーレスアーキテクチャとは、サーバーのプロビジョニングや管理をクラウドプロバイダーに任せて、ディベロッパーはサーバーレスのコード実行環境やマネージドサービスを利用してアプリケーションを構築する設計手法です。AWS ではサーバーを管理することなく、コードの実行、データの管理、アプリケーションの統合を行うためのサービスを提供しており、Gazefinder はそれらを活用して Web アプリケーションを構築しています。今回利用したいくつかのサービスの中からポイントとなる要素を抜粋し、以下にご紹介します。 AWS Amplify を活用した Web アプリケーション開発 AWS Amplify は AWS を使用したスケーラブルな Web およびモバイルアプリ開発のためのフレームワークです。AWS Amplify を利用することでバックエンド構築機能を使用してフルスタックのアプリを構築し、 Amplify Hosting を使用して Web アプリケーションをデプロイ可能です。Gazefinder では Amplify CLI を利用してコマンドラインから効率的に Web アプリケーションを構築し、ホスティング環境は Amplify Hosting を利用することで、Git リポジトリから取得したソースコードから CI/CD が有効なスケーラブルなホスティング環境にデプロイしています。 視線計測を実現した Amazon Rekognition EyeDirection Amazon Rekognition はクラウドベースの画像およびビデオ分析サービスであり、機械学習の専門知識がなくても、イメージファイルやビデオファイルの物体検出、テキスト検出、安全でないコンテンツの検出、画像/ビデオ分析、顔比較などの機能をアプリケーションに追加することが可能です。今回 Gazefinder に実装された視線計測には Amazon Rekognition の EyeDirection が利用されています。EyeDirection は画像内の顔検出機能である DetectFaces の属性の1つとして提供されるものであり、Amazon Rekognition API として提供されています。画像を分析すると EyeDirection はレスポンスとして、サービスが予測した視線方向に対する 0 から 100 の範囲の信頼度、-180 から 180 の範囲でピッチ軸での視線方向を表すピッチ、-180 から 180 の範囲でヨー軸での視線方向を表すヨーを返します。 ピッチとヨーの値は、ユーザーが見ている画面上の x-y 座標にマッピングする必要がありますが、ユーザーとカメラとの距離および相対位置によってピッチとヨーの値と、画面上の x-y 座標との関係が変化します。そのため、分析を実施する前に、ピッチとヨーの値のマッピングをキャリブレーションする必要があります。 キャリブレーションは映像の一部に組み込まれており、ユーザーは画面の上下左右に動くアニメーションを視線で追うことで自動的に行われます。さらに、Gazefinder では EyeDirection からのレスポンスのうち、視線方向の値の信頼度の情報も加味して解析することにより、正確な視線計測を実現しています。 Amazon Chime SDK を活用したオンライン相談 Amazon Chime SDK は、音声通話、ビデオ通話、画面共有機能をウェブまたはモバイルアプリケーションに追加できるようにする WebRTC ベースのリアルタイム通信プラットフォームです。Gazefinder では視線の計測結果について専門のオペレータとのオンライン相談が可能となっており、これに利用しているのが Amazon Chime SDK です。ビデオ通話は、WebRTC プロトコルを使用したオンラインミーティングが可能であり、クライアントアプリケーションが SDK を介して Amazon Chime のメディアサービスに接続し、音声・映像ストリームの送受信を行います。またAmazon Chime SDK は API を利用した実装が可能となっていることから、UI をサービスに合わせてカスタマイズすることが可能です。 おわりに 本ブログでご紹介したシスメックス株式会社とディピューラメディカルソリューションズ株式会社の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について シスメックス株式会社 辻本 研二 (Kenji Tsujimoto) 執行役員 次世代医療事業開発室長:再生細胞医療やデジタル医療、そして小型デバイスをキーワードにシスメックスならではの新事業を創出することを目指しています。 村上 耕平 (Kohei Murakami) 次世代医療事業開発室 部長:デジタルヘルスの分野で新たな事業の企画、立ち上げ、推進、マーケティングまで新規事業に係る一連のプロセスを実行しています。 ディピューラメディカルソリューションズ株式会社 田野島 英司 (Eiji Tanoshima) 開発企画・開発部長:AI・IoT・クラウド・データ解析を融合し、医療・介護の専門家と利用者を結ぶ次世代スマートヘルスケアサービスの創出に向けた研究開発をリードしています。 竹内 康浩 (Yasuhiro Takeuchi) 開発企画・開発部 メディカルアプリケーションエンジニア:ゲイズファインダーアプリの受託開発ならびに保守運用を担当しており、AI を活用した新機能の企画・開発を推進しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ハイテク &amp; ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。 Amazon Web Services UK Inc. Amir Omicevic Solutions Architect at AWS and works with customers across automotive, supply chain and professional services industry. He specialises in enterprise-scale strategizing, architecture and building transformative AI/ML solutions to deliver measurable business outcomes and unlock new business value for his customers. Beyond his professional role, he enjoys teaching his children how to play music instruments and the basics of computing and AI.