みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 先週は年に一度のAWS Summitが開催され、私はいくつかのブースで展示の担当をしていました。会場では、興味津々で「これを家に帰ってすぐ作ってみたい！」と言いながら、一生懸命メモを取っているお客様もいて、デモを開発して本当によかったと感じました。展示ブースではAIやIoTを組み合わせたものが多く、実際に動く様子を見てもらえると、楽しさやワクワク感がさらに増すなと思いました。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月23日週の主要なアップデート 6/23(月) Amazon WorkSpaces Core マネージドインスタンスによる VDI 移行の簡素化を発表 Amazon WorkSpaces Core Managed Instances を発表しました。これは仮想デスクトップ環境 (VDI) の移行をより簡単にするための新機能です。この機能は EC2 Managed Instances をベースにしており、お客様の AWS アカウント内でリソースをプロビジョニングできます。また、永続的および非永続的なワークロードに対するインフラストラクチャのライフサイクル管理も自動的に行います。また、既存の割引、Savings Plan、およびオンデマンドキャパシティ予約（ODCR）のようなその他の機能を、WorkSpacesのシンプルな運用で利用できるようになっています。 Amazon VPC のデフォルトルートテーブル容量が増加 Amazon VPC のルートテーブルのデフォルト容量が拡大されたことをお知らせします。これまでルートテーブルに設定できるルート数は 1 テーブルあたり 50 個が上限でしたが、今回のアップデートで 500 個まで拡張されました。従来は 50 個以上のルートを設定したい場合、制限緩和のリクエストを AWS に申請する必要がありましたが、この手続きが不要になります。 Amazon Time Sync Service がナノ秒のハードウェアパケットタイムスタンプに対応 Amazon Time Sync Service に、ナノ秒単位のハードウェアパケットタイムスタンプ機能が追加されました。この機能は、対応する Amazon EC2 インスタンスで利用可能です。この新機能により、Amazonのネットワークインフラストラクチャと AWS Nitro System を活用して、入力されるすべてのネットワークパケットに 64 bit のナノ秒精度のタイムスタンプを付与することができます。この機能により、EC2 インスタンスに届くパケットの順序や公平性の判定、片方向のネットワーク遅延の測定が可能になり、オンプレミスのソリューションと比較してより高い精度と正確性で分散システムのトランザクション速度を向上させることができます。 6/24(火) カスタマーカーボンフットプリントツールに地域ベースの排出量データが追加 AWSのカーボンフットプリントを計測するツール「Customer Carbon Footprint Tool (CCFT)」が機能強化されました。これまでは市場ベース方式 (MBM) による排出量計算のみでしたが、今回のアップデートで地域ベース方式 (LBM) による計算も追加されました。さらに、CloudFront の使用による推定排出量が、既存の EC2 や S3 と同様にサービスごとの内訳で確認できるようになりました。LBM と MBM の違いについては、 GHG プロトコルのスコープ 2 ガイダンス を参照ください。 Amazon Bedrock Guardrails がコンテンツフィルターと拒否トピックの階層化を発表 Amazon Bedrock Guardrails の新機能として、コンテンツフィルターと制限トピックに関する新しい階層が発表されました。Amazon Bedrock Guardrails は、有害なコンテンツやプロンプト攻撃を検出・ブロックし、特定のトピックを制限したり、個人を特定できる情報 (PII) を入力プロンプトやモデルの応答から編集したりするための設定可能な保護機能を提供します。また、モデルの誤った出力 (ハルシネーション) を検出・ブロックし、自動推論チェックを使用してモデルの応答における事実の主張を特定、修正、説明する機能も備えています。この Guardrails は、Amazon Bedrock でホストされているファンデーションモデル、自己ホスト型モデル、Bedrock 以外のサードパーティモデルなど、あらゆるモデルに ApplyGuardrail API を使用して適用できます。これにより、一貫したユーザー体験を提供し、安全性とプライバシー制御の標準化を支援します。また、新しく追加された Standard tier では、誤字脱字などの変更を含むコンテキストをより深く理解し、最大 60 の言語に対応したコンテンツの検出とフィルタリングが可能になります。 re:Post と re:Post Private に インテリジェント検索機能を発表 AWS re:Post と AWS re:Post Private に、新しい「インテリジェント検索」機能が追加されました。この機能により、AWS に関する情報をより効率的に、直感的に検索できるようになります。従来は AWS の公式ドキュメントやコミュニティの投稿など、複数のソースを個別に検索する必要がありましたが、インテリジェント検索では、これらの情報源から統合的に回答を得ることができます。例えば、IAM のパーミッション関連のエラーについて調べたい場合、自然な言葉で質問するだけで、AWS の様々なリソースから総合的な回答が得られます。セットアップは re:Post Private Administration Guide を参照ください。 6/25(水) AWS Glue で、フルテーブルアクセス権限を持つ AWS Lake Formation テーブルに対する Apache Spark の機能が強化 AWS Glue で Lake Formation のテーブルに対する Apache Spark の機能が強化されました。AWS Glue 5.0 の Apache Spark ジョブにおいて、ジョブロールが完全なテーブルアクセス権を持っている場合、AWS Lake Formation で登録されたテーブルに対する読み書き操作が可能になりました。これにより、同一の Apache Spark アプリケーション内で、Apache Hive やIcebergテーブルに対して CREATE、ALTER、DELETE、UPDATE、MERGE INTO などのデータ操作言語 (DML) 操作が実行できるようになりました。詳しくは、AWS Glue の ドキュメント をご覧ください。 Amazon Bedrock Flows が永続的な長時間実行とインラインコードサポートのプレビューを発表 Amazon Bedrock Flows は、基盤モデル (FM)、Amazon Bedrock Prompts、Amazon Bedrock Agents、Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails、その他の AWS サービスを連携させて、生成系 AI のワークフローを構築・拡張できるサービスです。今回のアップデートでは、長時間実行可能な永続的な実行機能とインラインコードのサポートがプレビューとして発表されました。これにより、ワークフロー開発と管理が大幅に効率化され、生成系 AI アプリケーションの構築に集中できるようになります。Amazon Bedrock Flows で長時間実行とインラインコード実行のプレビューが開始されました。従来は各ステップで 2 分のタイムアウト制限がありましたが、今回のアップデートで 15 分まで延長され、複雑な生成 AI ワークフローを実行しやすくできるようになりました。また、簡単なデータ処理のために Lambda 関数を作成する必要がなくなり、Python スクリプトを直接実行できるインラインコードノードが追加されました。 Amazon SageMaker で Git から S3 への自動同期がサポートされました Amazon SageMaker Unified Studio において、プロジェクトの Git リポジトリから Amazon S3 バケットへ自動的にファイルを同期する新機能をリリースしました。Amazon SageMaker Unified Studio は、AWS のアナリティクスや AI/ML サービスの機能やツールを統合した、データと AI 開発のための統合環境です。この環境では、単一のインターフェースからワークフローの構築、デプロイ、実行、監視が可能です。この新機能の最も重要なポイントは、開発環境で行ったコード変更を本番環境に自動的に反映できることです。これにより、手動での作業が不要となり、開発者のワークフローが効率化されます。詳細は ドキュメント を参照ください。 6/26(木) Amazon Braket が IQM Garnet で動的な回路機能を追加 Amazon Braket で、IQM 社の Garnet という量子プロセッシングユニット(QPU)上での動的回路機能の実験的サポートが開始されました。この機能強化により、量子研究者や開発者は回路の途中で測定を行い、その結果に基づいて後続の操作を制御できるようになりました。動的回路は量子エラーの軽減や修正に不可欠な要素であり、量子ビットの再利用による効率化や、条件付きロジックを必要とするアルゴリズムの実験を可能にします。この新機能により、ユーザーは 1 回の回路実行中に量子ビットをリセットして再利用したり、測定結果に基づいて条件付きの操作を適用したりすることができます。 Amazon CloudWatch で AWS Glue Data Catalog の使用状況メトリクスが利用可能に AWS Glue Data Catalogの利用状況メトリクスが Amazon CloudWatch で利用可能になりました。これは、データレイクハウス環境での API 利用状況を詳しく把握したいというお客様のニーズに応える重要なアップデートです。AWS Glue Data Catalog は、データレイクハウスのメタデータを管理するサービスですが、今回のアップデートにより、その API の使用状況を CloudWatch で監視できるようになりました。この機能は、Data Catalog が利用可能なすべての AWS リージョンで利用可能です。詳細は ブログ を参照ください。 AWS IoT Device Management の マネージド統合機能が 一般提供開始 AWS IoT Device Management で「マネージド統合」が一般提供開始されました。この機能は、異なるメーカーや接続プロトコルを使用する IoT デバイスの管理を簡素化することを目的としています。開発者は、直接接続、ハブベース、サードパーティのクラウドベースなど、接続タイプに関係なく、単一の統合インターフェースを通じて多様な IoT デバイスの導入と管理が可能になりました。マネージド統合では、Cloud-to-Cloud (C2C) コネクタとデバイスデータモデルテンプレートを使用できます。プレビュー段階では、パートナーやベンダーから提供される事前構築された C2C コネクタのカタログと、80 個以上のデバイスデータモデルテンプレートにアクセスできましたが、今回の一般提供では、開発者が独自のコネクタを作成・公開し、テンプレートをカスタマイズして新しいデータモデルを作成できるようになりました。 6/27(金) Amazon Route 53 が Resolver エンドポイントのキャパシティ使用率メトリックを提供開始 Route 53 Resolverエンドポイントのクエリ処理能力 (キャパシティ) を監視するための新しい Amazon CloudWatch メトリクス (ResolverEndpointCapacityStatus) が利用可能になりました。この機能により、VPC 内の Resolver エンドポイントに関連付けられた Elastic Network Interface (ENI) のキャパシティ状態を簡単に確認できるようになります。これまでは、DNSクエリの数を 5 分間隔で監視し、手動で制限に達する時期を予測する必要がありましたが、新機能では各エンドポイントのキャパシティ状態を直接確認できます。 AWS Firewall Manager が AWS WAF L7 DDOS マネージドルールをサポート AWS Firewall Manager において、AWS WAF の L7 DDoS 対策のマネージドルールがサポートされるようになりました。これは、アプリケーション層 (L7) での DDoS 保護を強化する機能です。AWS WAF のマネージドルールグループが、Amazon CloudFront や Application Load Balancer (ALB) などの AWS サービス上で動作するアプリケーションに対する DDoS 攻撃を自動的に検知し、軽減します。 Amazon Q の Java 開発者向けアップグレード変換 CLI が一般提供開始 Amazon Q Developer の Java アップグレード変換用 CLI (コマンドラインインターフェース) が一般提供開始されたことをお知らせします。この機能により、コマンドラインから Amazon Q Developer の変換機能を呼び出し、大規模な Java のアップグレードを実行できるようになりました。この新機能では、Java アプリケーションを Java 8、11、17、21 のソースバージョンから、Java 17 または 21 のターゲットバージョンへアップグレードすることが可能です。これは従来の IDE に加えて、新たに CLI でも利用できるようになりました。 AWS Summit でご覧いただいたものをこれから手元で試してみるのも面白いかもしれませんね。Summit 開催後には、ふりかえりブログが出てくると思いますので、そちらもお楽しみに。それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2025年5月12日〜16日、経済産業省が推進するプログラム『 Generative AI Accelerator Challenge(GENIAC) 』の採択者と共に、米国ベイエリアおよびシアトルの米大手モデルプロバイダーを訪問し、技術交流セッションを実施しました。GENIAC は、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が推進する取り組みで、日本国内の生成 AI 基盤モデル開発力を底上げし、企業等の創意工夫を促すことを目的とするものです。AWSは計算資源の提供や技術支援、コミュニティ形成支援を行っております。今回の訪米は、グローバルモデルプロバイダーとの意見交換及び最新トレンドの把握を目的として、GENIACコミュニティに参画する6社（ 株式会社リコー 、 カラクリ株式会社 、 ウーブン・バイ・トヨタ株式会社 、 松尾研究所 、 株式会社ユビタス 、 フューチャー株式会社 ）から経営層・技術責任者計7名をお招きしました。 左から松尾研究所 村上取締役、上林様、フューチャー株式会社 森下 Senior Architect、ウーブン・バイ・トヨタ株式会社 小堀 Director、株式会社リコー 中田乙一 様、カラクリ株式会社 中山CPO、株式会社ユビタス 中坪 Senior Director プログラム概要 1. Japan Innovation Campusでのビジネスセッション（5/12 11 am – 1 pm） 経済産業省が主催するシリコンバレーのイノベーション拠点である Japan Innovation Campus にて、日本からの参加者6社は日本人起業家3名（ Glasp Nakayashiki CEO, I’mbesideyou Kamiya CEO, and Ando COO）とのパネルディスカッションを実施しました。日本と米国の市場の違いや米国でのビジネスの魅力やチャレンジついてのインプットを得ました。また現地VCとAWSによるMeet Upイベントでは株式会社ユビタスが参加し、現地VCであるElevation CapitalのKrishna Mehra (AI Partner)および現地スタートアップ企業であるAdoptAのDeepak Anchala (CEO)と意見交換をしました。日本への投資意欲の実態を体感するとともに、AI Drivenな事業創造の重要性を認識しました。 2．Anthtropicとの対話セッション（5/12 3pm – 5 pm） Anthropic は、サンフランシスコに拠点を置くAIスタートアップで、安全性と信頼性を重視した大規模言語モデル（LLM）の開発を行っています。創業者はOpenAIの元メンバーであり、同社の「Claude」は、高度な対話能力と直感的な操作性で注目を集めています。Anthropicからは、Jason Kim氏、Ethan氏、Sam氏が参加し、知見共有セッションを実施しました。Claude Codeの活用方法や顧客実装に関する知見が共有され、双方にとって示唆を得られる生産的な技術交流となりました。 3．Metaとの対話セッション（5/13 9 am – 12 pm） Meta は、生成AI分野でも積極的に開発を進めており、独自の大規模言語モデル「Llama（ラマ）」シリーズを提供しています。Metaからは、Eissa　Jamil氏（パートナーエンジニアリングマネージャー）、Christine Hayden氏（カスタマーサクセスリード）、Hamid Shojanazeri氏（Llama/PyTorchのパートナーエンジニアリングマネージャー）、Joe Spisak氏（ジェネレーティブAIディレクター）が参加し、GENIAC参加者と3時間に及ぶ討議を行いました。 4．NVIDIAとの対話セッション（5/13 2 pm – 6 pm） NVIDIA は、GPU（グラフィックス処理ユニット）で世界的に知られる半導体企業であり、生成AIの基盤を支える中心的な存在です。NVIDIAからは、Yogesh Agrawal氏（データセンタービジネス担当VP）、Jacon Kern氏（AWS Cosellリード）、Mukundhan Srinivasan氏（NeMo GTM）、Jeff Lattomus氏（DGXC セールスリーダー）が参加し、GENIAC参加者との対話を行いました。NVIDIAのプロダクトチームとサービスソリューションアーキテクトより、NeMo、NIMs、Dynamoに関する最新の技術情報とトレンドについて詳細な説明が行われました。NVIDIA DGX Cloudの紹介では、NVIDIAとAWS合同のQ&Aセッションが実施されました。 5．Annapurna Labとの対話セッション（5/14 10 am – 12 pm） Annapurna Labsは、Amazonが買収した半導体開発企業で、AWSの独自チップの設計を担っています。代表的な製品には、推論用チップ「 Inferentia 」や学習用チップ「 Trainium 」があり、これらはコスト効率よく大規模なAIワークロードを処理するために最適化されています。AWSからは、AnnapurnaのHead of BD/GTMであるKamran Khanが参加し、GENIAC参加者との対話を行いました。Karakuriの中山CPOから現状の活用方法についてシェアされるとともに、Trainiumの今後の展望について共有されました。 6．Cohereとの対話セッション（5/14 2 pm – 4 pm） Cohere は、カナダ・トロント発のAIスタートアップで、エンタープライズ向けに特化した大規模言語モデル（LLM）の開発を行っています。CohereからはSaurabh氏（CTO）とGokce氏（MLリサーチャー）が参加しました。 7．AWS Bedrockの市場動向（5/15 3 pm – 5 pm） AWSからは Amazon Bedrock のGTMチームのEugene Kawamoto（Director）が参加しました。Eugene Kawamotoは、Amazon BedrockおよびAI ServicesのGTMの立場から見たAWSの現状と米国における生成AIのニーズとトレンドについて共有しました。生成AIのトレンドとしてAgentic AIの普及とそのエコシステムについての重要性についての言及がありました。日本の参加者を交えた生成AIのモデル開発とGTMのアイデアについての意見交換がされました。 8．Amazon SageMaker HyperPod、Amazon AGIチームによるEBCセッション（5/16 9 am – 11 am） AWSからは、 Amazon SageMaker HyperPod サービスチームのRajneesh SinghとAmazon AGI AIインフラストラクチャの製品責任者であるSejun Raが登壇し、Amazon NovaとAmazon SageMaker HyperPodを使用したモデル開発に関する説明を行いました。 参加者の声  株式会社カラクリ 中山CPO： 世界トップ企業の専門家たちや現地で挑戦する日本人起業家たちと会話し、そこで得た知見をもとに先を見据えた意思決定ができました。セッティングしていただいたAWSの皆様ありがとうございました。 ウーブン・バイ・トヨタ株式会社 小堀 Director： 今回の視察ではAnthropic、Meta、Cohereなど生成AI開発の最前線を視察し大いに刺激を受けた。一方で、日本のAI事業社にとって資金調達やユースケース拡大の課題も認識でき大きな学びがありました。 松尾研究室 村上取締役： Big Techの強さはもちろん感じましたが、日本のモデル開発事業者やAIエンジニアが十分戦えるレベルにいることを再確認することもできました。勝ち筋を見極め協調と差別化のバランスを取ることが重要です。今回得た知見を活用し、今後も松尾研として日本全体を支援していきます。 株式会社ユビタス 中坪 Senior Director： 今回の視察ではAnthropic、Meta、Cohereなど生成AI開発の最前線を視察し大いに刺激を受けた。一方で、日本のAI事業社にとって資金調達やユースケース拡大の課題も認識でき大きな学びがありました。 フューチャー株式会社 森下 Senior Architect： この度は貴重な視察の機会を設けていただきありがとうございました。今後自社のビジネスをどのように展開していくかという点で多くの示唆をいただき、また今後国内企業が成功を収めるためには様々な国内外の企業と協力体制を築いていくことが重要になると感じました。 株式会社リコー 中田乙一様： AWSチームの皆様の献身的なサポートのおかげで、貴重なネットワーキングの機会を得ることができました。米国やカナダの主要企業との対話を通じて、当社が取り組むべき注力分野やアプローチについて新たな視点を得ることができ、大変有意義でした。さらに、参加組織間の強いつながりも生まれ、特に意味のある経験となりました。 AWSは今後もGENIACコミュニティの活動を継続的に支援していきます。また、AWSは生成AIの社会実装を加速するために「 生成AI実用化推進プログラム 」も展開しています。これは、製造業、金融、医療、教育など幅広い業界のニーズに応じて、生成AIのビジネス現場での具体的な活用を支援する取り組みです。コミュニティイベントも開催されますので、ぜひ奮ってご参加ください。 このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャーである田村 圭が執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 先週開催された AWS Summit Japan 2025 、みなさまお楽しみいただけましたか？　残念ながら参加できなかった、という方も 7/11 までの期間限定でコンテンツを配信中となっておりますので、ぜひ上記サイトよりご登録の上ご覧ください！ 今週は AWS Summit Week でしたが、Amazon Bedrock Guardrailsの日本語対応や AWS ジャパン 生成AI実用化推進プログラムの新プラン（GENIAC-PRIZE 応募者支援プラン及び Agentic AI 実用化推進プラン）が発表されています。Summit コンテンツも視聴しながら、ぜひ本ブログもキャッチアップにお役立てください！   それでは、6月23日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Amazon Bedrock Guardrails が日本語に対応しました 」を公開 Amazon Bedrock Guardrails が待望の日本語コンテンツフィルタリングに対応し、日本語特有の表現や文脈を理解した高精度な有害コンテンツ検出が可能になりました。従来は英語のみの対応だったため、日本語での生成AI アプリケーション開発では十分な安全対策が困難でしたが、今回のアップデートにより個人情報や機密情報の漏洩防止、不適切なトピックの拒否設定などが日本語環境でも実現できます。 ブログ記事「 生成AI実用化推進プログラムに2つの新プランを追加 」を公開 AWS ジャパンが「生成AI実用化支援プログラム」において、日本の生成AI実用化を加速するための2つの新プランを追加しました。新プランでは、経済産業省とNEDOが主催する「GENIAC-PRIZE」への応募者の計算リソースの調達から実装・事業化までを一貫してサポートする「GENIAC-PRIZE応募者支援プラン」と、自律的なAI（Agentic AI）の実用化を総合的に支援するために設計思想策定から運用体制確立までをサポートする「Agentic AI実用化推進プラン」の二つを新たに提供しています。従来のプランも含めて、みなさまのご興味に応じてぜひ応募をご検討ください。 ブログ記事「 AWS Summit Japan 2025で体験！生成 AI でロボットが人間の指示を理解する未来 」を公開 AWS Summit Japan 2025で発表された IoT、ロボット、LLM の融合技術は、物理世界とデジタル世界の境界を取り払う革新的なアプローチとして大きな注目を集めています。この技術により、工場の製造ロボットが自然言語で作業指示を理解し、IoT センサーからのリアルタイムデータを基に自律的に判断・行動することが可能になり、従来の定型的な作業から創造的な問題解決まで幅広く対応できるようになります。 サービスアップデート Amazon Q Developer の Java アップグレード変換機能が CLI で一般提供開始 Amazon Q Developer Java アップグレード変換 CLI の一般提供が開始されました。この CLI を使えば、コマンドラインから Java アプリケーションのソースコードを最新バージョンにアップグレードできます。主な機能は、Java 8/11/17/21 から 17/21 へのアップグレード、選択的なライブラリアップグレード、Oracle から PostgreSQL への SQL 変換です。米国東部 (バージニア北部) と欧州 (フランクフルト) の AWS リージョンで Linux と Mac OS から利用可能です。 Amazon CloudWatch Investigations でトラブルシューティングを加速（一般提供開始） Amazon CloudWatch Investigations が一般提供開始されました。AIエージェントが環境内の異常を探し、根本原因を特定し、修復ステップを提案することで、平均解決時間を短縮します。調査は80以上のAWSコンソールから開始でき、チームで協力して結果を追加・確認できます。関連するドキュメントや修正案も表示され、Slackなどのコミュニケーションツールとも統合できます。この機能は追加費用なしで、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (スペイン)、欧州 (ストックホルム) で利用できます。 Amazon Bedrock Guardrails にコンテンツフィルターと拒否トピックのための新しい機能 Tier を追加 Amazon Bedrock Guardrailsは、コンテンツフィルターと拒否トピックの新しい Tier を発表し、柔軟性と使いやすさが向上しました。新しい「スタンダード」Tier により、望ましくないコンテンツをより的確に検出・フィルタリングでき、最大60の言語がサポートされます。 Amazon Bedrock Flows で永続的な長時間実行とインラインコードサポートをプレビュー提供開始 Amazon Bedrock Flows に永続的な長時間実行機能とインラインコードサポートが追加されました（プレビュー）。これにより、ワークフローの実行時間が15分に延長され、カスタムモニタリングコードが不要になり、簡単なデータ処理のためのLambda関数設定のオーバーヘッドがなくなります。これらの機能強化で、ワークフロー開発と管理が合理化され、生成的AIアプリケーション構築に集中できるようになります。 Amazon SageMaker HyperPod で NVIDIA B200 GPU を搭載した P6 インスタンスが利用可能に Amazon SageMaker HyperPod で最新の NVIDIA B200 GPU を搭載した P6 インスタンスが利用可能になりました。P6-B200インスタンスは、8基のBlackwell GPUと1440 GBの高帯域幅GPUメモリを搭載し、従来のP5enインスタンスと比べて最大2倍のパフォーマンスを発揮します。これらのインスタンスは、米国西部(オレゴン)リージョンのSageMaker HyperPodフレキシブルトレーニングプランで利用可能です。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 三厨 航(Wataru Mikuriya) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近読んだ本は「春にして君を離れ」です。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2025 年 5 月 30 日に、「 [教育業界向け] 手を動かしながら学ぶデータ分析ワークショップ」を AWS Startup Loft Tokyo にて開催しました。 近年、個別最適な学びと協働的な学びの実現に向けて教育業界におけるデータ分析の重要性が増しています。 本イベントでは、初等中等教育、EdTech のシステム構築に関わるベンダー、パートナー企業の方々をお招きし、教育業界におけるデータ利活用や AWS における実現方法に関して振り返りつつ、Amazon QuickSight を活用した教育データ分析ダッシュボードの構築などをハンズオンを体験していただきました。当日お集まりいただいた総勢 40 名以上の皆様には、改めて御礼申し上げます。本ブログではその開催報告をお届けします。 オープニング AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 本部長 松井佑馬 イベント冒頭では、AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 本部長 松井佑馬がオープニングの挨拶を行いました。 冒頭では、国の教育 DX ロードマップ案を引用し、「学ぶ人のためにあらゆるリソースを」という理念のもと、教育のデジタル化とデータ活用の全体像を紹介しました。校務負担の軽減や多様な学習環境整備を推進するための教育データの標準化・分析の必要性を強調しました。 また、AWS のツールやサービスを活用し、教育の質を向上させるためには、Amazon 社内で活用されている「Working Backwards」というアプローチを参考に、理想的な教育環境を実現するために必要なステップを逆算し、そこから必要なデータや分析方法を見出していくことの重要性についても言及しました。 座学パート１「教育業界におけるデータ利活用」 AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 ソリューションアーキテクト 田村健祐 開催挨拶の後は、「教育業界におけるデータ利活用」をテーマにSA 田村により座学パートを行いました。 まず冒頭では、教育 DX の重要なミッションである「誰もが、いつでもどこからでも、誰とでも、自分らしく学べる社会」の実現に向けたこれまでの取り組みについて述べました。GIGA スクール構想に始まり、教育データ利活用ロードマップが策定され、これに基づいた施策が実施されてきました。さらに現在は改訂版である教育 DX ロードマップの策定が始まっています。 続いて、「教育 DX ロードマップ」に基づいて、教育現場が抱える課題についての説明を行いました。子供たちにとっては「自分らしい学び」や「自律的な学習」の実現が課題となっており、教職員の方々は厳しい勤務実態の中で業務効率化が求められています。 これらの課題に対して、教育データの活用は一つの柱となります。特に教育データ利活用では 3 つの重要な取り組みが必要と考えられます： １：教育サービスの相互接続 校務支援システムやデジタル教科書など、様々な教育システムの連携を目指す ２：教育データの標準化 主体情報、内容情報、活動情報といった教育データの xAPI 活用などの標準化を進め、効率的なデータ活用を目指す ３：データ分析・活用の推進 学校・学級・個人レベルでのダッシュボード導入により、データの可視化と活用の促進を目指す データの活用により、子どもたちにとっては個別最適な学習支援の実現が期待できます。教職員にとっては子どもたちや学校の状況を即座に把握し、データに基づいた支援ができるため、業務効率や質の面での向上が見込めます。 教育現場のデジタル化は着実に前進していますが、上で述べたような教育現場が抱える課題を踏まえると、データ分析・活用のさらなる推進が求められます。 座学パート２「教育データ活用のためのAWSアーキテクチャ」 AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 ソリューションアーキテクト 大南賢亮 続いて SA 大南より、教育データ活用のための AWS アーキテクチャについて、実践的な解説を行いました。 教育現場でのデータ活用には、データをさまざまな場所からコピーしており「正」のデータが不明確になりやすいことや、分析手法の変更に対応できるデータの持ち方がされていないことなどの課題が挙げられます。これらの課題に対して、多様なデータを一元的に保存する「データレイク」というアプローチが有効です。 しかし、実際にデータレイクを構築するには 、 データの蓄積・分析・可視化といった機能を用意する手間や、高い可用性・拡張性・性能・セキュリティを担保するための管理負担の大きさなど、技術的な課題も多くあります。 そこで AWS のマネージドサービスを活用することで、効率的なデータレイク構築が可能となります。具体的には： Amazon S3 をコアのストレージとして活用 AWS Glue でデータカタログ化と ETL 処理を実現 Amazon Athena でデータに対するクエリを簡単に実行 Amazon QuickSight でのデータ可視化 といった組み合わせで、包括的なデータ分析環境を構築できます。 実際の活用案として、xAPI 形式のスタディログ分析や教育ダッシュボードの構築を紹介しました。これらにより、学習理解度の分布や推移、生活記録との相関など、多角的な教育データの分析が可能となります。 また、データレイクのセキュリティとして、文部科学省「教育データ利活用に係る留意事項」に沿った個人情報・プライバシー保護に対応するため、Amazon S3 Object Lock （WORM : Write Once Read Many の実現）や、Amazon GuardDuty S3 Protection（データ管理の脅威検知）などの機能を活用できる点も紹介しました。 ハンズオンパート１「データのプロファイリング（AWS Glue, AWS Glue DataBrew）」 AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 ソリューションアーキテクト 秋山怜穏 ワークショップの後半ではハンズオンパートとして実際に AWS の Workshop 環境に触りながら、参加者の皆さまと AWS におけるデータ分析環境の構築方法について学びました。ハンズオンでは、 こちら のコンテンツを用い、大学の学生情報システムおよび学習管理システム上のデータを題材に AWS におけるデータのプロファイリングと可視化の流れを体験いただきました。 まず、ハンズオンパート１では AWS Glue DataBrew を用いてデータのプロファイリングを行う手順（ Lab 4: データプロファイリングを通じた学生データレイクの理解 ）を体験いただきました。 参加者の皆さんには、AWS Glue Data Catalog に格納された学生テーブルから DataBrew データセットを作成していただき、本格的なデータプロファイリングジョブの設定を体験していただきました。 PII（個人識別情報）検出機能や重複データの特定、データ間の相関関係分析など、実際のデータ分析プロジェクトで必要となる高度な機能を一通り試していただきました。セキュリティ面でも、KMS 暗号化や IAM ロールの適切な設定を通じて、データガバナンスの重要性を実践的に理解しました。 プロファイルジョブの実行後は、データ品質サマリーや値分布の可視化結果を確認し、データの特性を深く理解しました。生成AIを活用しながら分析結果から得られるインサイトを得る段階まで体験いただきました。 ハンズオンパート２ 「データの可視化（Amazon QuickSight、Q in QuickSight）」 AWS ジャパン 合同会社 パブリックセクター技術統括本部 教育・研究技術本部 ソリューションアーキテクト 山本ひかる 続くハンズオンパート２では、ハンズオンパート１で準備したデータを可視化する手順（ Lab 6：学生データレイクの探索、学生データレイクの可視化 ）を参加者の皆さまと行いました。 Amazon QuickSight の基本機能や、 Amazon Q in QuickSight による生成 AI とのコラボレーションをご体験いただきました。 まずは、Amazon QuickSight アカウントの設定を行い、ユーザーの登録を行いました。 その後、ハンズオンパート１で準備したデータへのアクセス権を付与し、Amazon QuickSight の「データセット」へデータの取り組みを行います。データの取り込み後、「分析」の画面へ移り、ダッシュボードのためのビジュアルの構築を行いました。 ビジュアルの構築では、学生の人口統計の可視化をテーマに行いました。例えば、学生の男女比を示す円グラフ、学部・専攻別の first-generation student（家庭で最初に学位以上の課程に進学した学生）の割合を示すヒートマップ、学生の出身州を示す地図上での可視化、などを行いました。 Amazon QuickSight の基本操作を一通り体験いただいた後は、 Amazon Q in QuickSight によるビジュアルの構築に皆さまにご体験いただきました。 Amazon Q in QuickSight を使用してビジュアルを構築・編集する Amazon Q in QuickSight を使用して計算フィールドを作成し、ビジュアルで使用する ダッシュボードに関する自然言語での Q&A 体験 このように、ハンズオンパート２では、Amazon QuickSight の基本的な操作（アカウントの設定、サンプルデータセット・分析・ダッシュボードの作成など）に加え、Amazon Q in QuickSight による生成 AI とのコラボレーションによる BI 業務の効率化・ユーザーエクスペリエンスの向上をご体験いただきました。 最後に 本ワークショップを通じて、AWS のデータ分析サービスの基礎から実践的な活用方法までご紹介させていただきました。データの蓄積から可視化まで、AWS S3、Glue、Glue DataBrew、Athena、Amazon QuickSight といった各サービスを組み合わせることで、効率的なデータ分析基盤を構築できることをご確認いただけたかと思います。 多くの企業様が「データは持っているものの、どう活用すればよいかわからない」「BI ツールの導入に時間がかかりそう」といった課題を抱えていらっしゃいます。本ワークショップをきっかけに、AWS のデータ分析サービスを活用いただくことで、皆様のデータ活用の第一歩を踏み出していただければ幸いです。 まとめ ワークショップ後の懇親会（任意参加）では、参加者の皆さまの間で活発な意見交換が行われ、教育分野でのデータ活用についての具体的なディスカッションが展開されました。この機会を通じて、参加者同士の貴重なネットワーキングの場となったことを大変嬉しく思います。 AWS は今後も、教育機関のデータ活用を支援するため、様々なテクニカルセッションやコミュニティ活動を継続して実施して参ります。 ご関心を持たれた方は、お気軽に お問い合わせ ください。教育のイノベーションに取り組まれる皆さまのご参加をお待ちしております。 次回の教育業界向けイベントにも、ぜひご期待ください！ このブログは、 アマゾン ウェブサービス ジャパン 合同会社 パブリックセクター 技術統括本部 教育・研究技術本部 ソリューションアーキテクト 秋山怜穏、山本ひかるが執筆しました。

革新的な AI を活用したソリューションとお客様での実績により、AWS はメインフレームモダナイゼーションにおける地位を強化しています 「AWS は AWS Blu Age とパートナーツールを含む最も幅広いポートフォリオを提供しています。パフォーマンス、セキュリティ、コンプライアンスのためのモダナイゼーションとクラウド最適化の全体にわたって、熟練したコンサルタントと幅広いエコシステムによってお客様をサポートします。」— ISG 社の著名なアナリストであり、本ブログで取り上げたレポートの著者、Pedro L. Bicudo Maschio ISG は、米国に於けるメインフレームアプリケーションモダナイゼーションソフトウェアを四象限に位置付けた ISG Provider Lens の 2025 年版レポートで、アマゾンウェブサービス (AWS) をリーダーに選出しました。 ISG のレポートでは、以前から AWS がメインフレームモダナイゼーションに於けるリーダーとして位置付けられており、その連続記録を更に伸ばすものになります。これは、お客様のモダナイゼーションプロジェクトを成功に導いた当社の実証済みの能力と、AWS Transform の追加によるポートフォリオの幅広さの両方を象徴しています。 今日、Transamerica、Allianz、Marriott Hotels など、世界中の大企業のお客様が、メインフレームベースの最も重要なワークロードのモダナイゼーションに AWS を信頼して採用しています。 2025 年の ISG Provider Lens 調査では、21 社のソフトウェアベンダーを、競争力とポートフォリオの魅力という 2 つの重要な側面から評価しました。レガシーメインフレームアプリケーションのトランスフォーメーションを加速させたいというお客様の需要は、日に日に増しています。この包括的な分析では、各プロバイダーがメインフレームエコシステム内の複雑さと技術的多様性に対処しながら、お客様からの要求に応える能力を調査しました。AWS は、その包括的なソリューションポートフォリオ、継続的なイノベーション、およびお客様で実証済みの実績で際立っていました。 AWS Transform for Mainframe のトランスフォーメーション機能 AWS Transform for Mainframe は、メインフレーム向けの初のエージェント AI エクスペリエンスであり、お客様がメインフレームモダナイゼーションジャーニーを加速できるよう支援します。コードベースの分析、ドキュメントの生成、モノリシック構造の分解、レガシーコードの変換、モダナイゼーションの全行程の管理といった複雑なタスクを自動化する専門のエージェントが AWS で利用できます。また、AWS Transform for Mainframe は、必要な場合にのみ人間の入力を使用します。 AWS Transform は、エンドツーエンドのモダナイゼーションタスクに伴う複雑さを解消するエージェントフレームワークを通じて、お客様やパートナーがメインフレームモダナイゼーションのプロジェクトを加速できるよう支援します。Amazon は、これまでに数万社のお客様をクラウドに移行してきました。AWS Transform は、Amazon の19年にわたるクラウド移行の経験を基に学習した AI を活用して、重要なタスクを自動化します。メインフレームプログラムの詳細なドキュメントの作成や、モノリシックアプリケーションの論理的なビジネスグループや機能への分解といった、時間が掛かる操作を迅速に実行できます。 re: Invent 2024 で発表された AWS Transform for Mainframe には、メインフレームのお客様に代わってイノベーションと構築を続ける AWS の取り組みが反映されています。メインフレームモダナイゼーションは、これまで複数年にわたるプロジェクトでした。AWS Transform を使って、これらのプロジェクトが複数年にわたる取り組みから複数四半期にわたる取り組みへと移行し、メインフレームのお客様がレガシープラットフォームからの撤退と AWS 活用によるイノベーションに自信を付けた様子を目にしています。 AWS Mainframe Modernization の実力 AWS は、Transamerica のようなお客様がメインフレームシステムを AWS に移行してバッチパフォーマンスを 30% 向上させ、Visma のようなお客様が年間 55% のコスト削減を達成できるよう支援してきました。AWS は、メインフレームアプリケーションの分析、移行、トランスフォーメーションを容易にする革新的なツールとサービスをお客様に提供することで、こうした成功事例を可能にしています。AWS では、お客様がリファクタリングパターンもしくはリプラットフォームパターンを選ぶことができます。メインフレームアプリケーションを AWS のリレーショナルデータベースを使用するアプリケーションに変換する際に、Java または COBOL いずれにするかお客様が選択できるようにしています。お客様はアプリケーションとデータに関する詳細な情報を得ることができ、移行後は 200 を超える AWS クラウドサービスにアクセスできます。 AWS は、お客様がメインフレームモダナイゼーション目標を達成できるよう支援する専用アクセラレータを提供しています。たとえば、データレプリケーション機能により、従来のメインフレームデータを AWS とほぼリアルタイムで同期できるため、組織は新しい機能を開発したり、モダンなレポートシステムを実装したり、AI/ML 機能を活用したりできます。また、ファイル転送機能によってクラウドへのファイルの移動が効率化され、データモダナイゼーションの可能性が広がります。最後に、アセンブラの変換機能により、移行プロジェクト中にメインフレームのアセンブラコードを COBOL または Java に容易に変換できるため、モダナイゼーションの複雑さが軽減されます。 ISG による四象限分析を確認してみましょう ISG による四象限分析の無料レポート を読んで、ISG が AWS をメインフレームモダナイゼーションのリーダーと評価した理由をご覧ください。 最新の ISG Provider Lens レポートには、メインフレームモダナイゼーションソリューションを取り巻く業界の変化が示されています。組織がデジタルトランスフォーメーションへの取り組みを加速するにつれて、信頼性が高くスケーラブルなメインフレームモダナイゼーションサービスに対する需要は高まり続けています。次の分析図は、ISG レポートからの抜粋です。 図 1. ISG Provider Lens は、AWS を 2025 年の米国市場向けのメインフレームアプリケーションモダナイゼーションソフトウェアソリューションのリーダーとして位置付けています。この四象限分析では、競争力とポートフォリオの魅力に基づいてベンダーを評価します。 著者 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、メインフレームとレガシーのモダナイゼーションを専門としています。Tim は世界中のお客様やパートナーと協力して、メインフレームアプリケーションを変革するための革新的な戦略を開発しています。ティムはメインフレーム・モダナイゼーション業界に 7 年以上携わり、Astadia（Amdocs により買収）と IBM に勤務してきました。AWS では、お客様やパートナーがより早く結果を出せるよう支援する、拡張性の高いモダナイゼーション戦略の構築に注力しています。 Phil de Valence Phil de Valence は、AWS Mainframe Modernization サービスのプロダクトマネジメントをリードしています。Phil は 22 年以上にわたってメインフレームに関わり、主に世界中の企業顧客向けのモダナイゼーションの取り組みをリードしてきました。メインフレームに関する 9 冊の著書 (IBM Redbooks) を共同執筆し、AWS のモダナイゼーションに関する 50 以上の記事やビデオを出版し、AWS re: Invent、Micro Focus Universe、SHARE、IBM Impact などのカンファレンスで発表してきました。現在の役職では、ビジネス価値を最大限に引き出すために、メインフレームアプリケーションのモダナイゼーションを加速させるイノベーションの構築に注力しています。メインフレームとレガシーシステムに対する AWS の価値提示を最大限に活用する方法について、お客様やパートナーに助言しています。 Rao Panchomarthi グローバルのメインフレームモダナイゼーション組織のリーダー。Rao は、IBM メインフレーム、分散システム、クラウドテクノロジーにまたがる 20 年以上の経験を持つ経験豊富な IT プロフェッショナルです。Rao は大規模なビジネストランスフォーメーションをリードし、メインフレームアプリケーションのクラウドテクノロジーへの移行や、モダナイズするための戦略を策定しています。AWS に入社する前は、JPMorgan Chase のクレジットカード事業でアーキテクチャ責任者を務め、複数のトランスフォーメーションプロジェクトをリードしていました。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

sort コンパクションと z-order コンパクションを使用して、 Amazon S3 Tables と 汎用 S3 バケット での Apache Iceberg クエリパフォーマンスを向上させることが可能になりました。 通常、Iceberg は AWS Glue データカタログ や S3 Tables で Amazon Simple Storage Service (Amazon S3) 内の大規模な分析データセットを管理するために使用します。Iceberg テーブルは、同時ストリーミングやバッチインジェスト、スキーマ進化、タイムトラベルなどのユースケースをサポートします。高インジェストまたは頻繁に更新されるデータセットを扱うときは、データレイクに多数の小さなファイルが蓄積される場合があり、クエリのコストやパフォーマンスに影響を及ぼします。皆さんからは、Iceberg のデータレイアウトの最適化は操作が複雑で、多くの場合にカスタムパイプラインの開発と維持が必要になるというご意見をいただいています。マネージドコンパクションでのデフォルトの binpack 戦略はパフォーマンスを大幅に向上させますが、S3 と S3 Tables の両方に sort および z-order のコンパクションオプションを導入すると、1 つ、または複数のディメンション全体をフィルタリングするクエリのパフォーマンスがさらに大きく向上します。 2 つの新しいコンパクション戦略: Sort と z-order データをより効率的に整理するため、Amazon S3 では、デフォルトの binpack コンパクションに加えて、 sort と z-order の 2 つの新しいコンパクション戦略がサポートされるようになりました。これらの高度な戦略は、 AWS Glue データカタログ による最適化を通じて、フルマネージド型の S3 Tables と、汎用 S3 バケット内の Iceberg テーブルの両方で利用できます。 Sort コンパクションは、ユーザー定義の列順序に基づいてファイルを整理します。テーブルにソート順序が定義されている場合、S3 Tables コンパクションはコンパクションプロセス時にそのソート順序を使用して、類似する値をクラスター化するようになります。これは、スキャンされるファイルの数を減らすことでクエリの実行効率性を向上させます。例えば、 state や zip_code による sort コンパクションでテーブルが整理されている場合、これらの列をフィルタリングするクエリでスキャンされるファイル数が減るため、レイテンシーとクエリエンジンコストが低減します。 Z-order コンパクションは、複数のディメンション全体で効率的なファイルプルーニングを有効にすることで、ファイルをさらに整理します。この戦略は、複数の列からの値の二進数表現をソート可能な単一のスカラーにインターリーブするため、空間クエリや多次元クエリには特に有用です。例えば、ワークロードに pickup_location 、 dropoff_location 、および fare_amount で同時にフィルタリングするクエリが含まれる場合に z-order コンパクションを使用すると、スキャンされるファイルの総数を従来のソートベースのレイアウトよりも少なくすることができます。 S3 Tables は、Iceberg テーブルのメタデータを使用して現行のソート順序を判断します。テーブルにソート順序が定義されている場合は、継続的なメンテナンス時に sort コンパクションが自動的に適用されるため、アクティブ化するための追加設定は必要ありません。 z-order を使用するには、S3 Tables API を使用してテーブルのメンテナンス設定を更新し、戦略を z-order に設定する必要があります。汎用 S3 バケット内の Iceberg テーブルの場合は、コンパクション設定を更新することで、最適化の最中に sort または z-order コンパクションを使用するように AWS Glue データカタログを設定できます。 sort または z-order の対象となるのは、これらを有効化した後で書き込まれた新しいデータのみです。コンパクション実施済みの既存ファイルは、テーブルのメンテナンス設定でターゲットファイルのサイズを大きくするか、標準の Iceberg ツールを使用してデータを書き換えることでファイルを明示的に書き換える場合を除き、そのまま変更されません。この動作は、いつ、どのくらいのデータを整理し直すかをユーザーが制御して、コストとパフォーマンスのバランスを取ることができるように設計されたものです。 実際の動作を見てみましょう ここでは、Apache Spark と AWS コマンドラインインターフェイス (AWS CLI) を使用するシンプルな例を説明していきます。インストール済みの Spark クラスターと S3 テーブルバケットを用意しました。 testnamespace 内には testtable という名前のテーブルがあります。テーブルにデータを追加できるように、コンパクションを一時的に無効にしました。 データを追加したら、テーブルのファイル構造を確認します。 spark.sql(""" SELECT substring_index(file_path, '/', -1) as file_name, record_count, file_size_in_bytes, CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name, CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name FROM ice_catalog.testnamespace.testtable.files ORDER BY file_name """).show(20, false) +--------------------------------------------------------------+------------+------------------+----------------+----------------+ |file_name |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name| +--------------------------------------------------------------+------------+------------------+----------------+----------------+ |00000-0-66a9c843-5a5c-407f-8da4-4da91c7f6ae2-0-00001.parquet |1 |837 |Quinn |Quinn | |00000-1-b7fa2021-7f75-4aaf-9a24-9bdbb5dc08c9-0-00001.parquet |1 |824 |Tom |Tom | |00000-10-00a96923-a8f4-41ba-a683-576490518561-0-00001.parquet |1 |838 |Ilene |Ilene | |00000-104-2db9509d-245c-44d6-9055-8e97d4e44b01-0-00001.parquet|1000000 |4031668 |Anjali |Tom | |00000-11-27f76097-28b2-42bc-b746-4359df83d8a1-0-00001.parquet |1 |838 |Henry |Henry | |00000-114-6ff661ca-ba93-4238-8eab-7c5259c9ca08-0-00001.parquet|1000000 |4031788 |Anjali |Tom | |00000-12-fd6798c0-9b5b-424f-af70-11775bf2a452-0-00001.parquet |1 |852 |Georgie |Georgie | |00000-124-76090ac6-ae6b-4f4e-9284-b8a09f849360-0-00001.parquet|1000000 |4031740 |Anjali |Tom | |00000-13-cb0dd5d0-4e28-47f5-9cc3-b8d2a71f5292-0-00001.parquet |1 |845 |Olivia |Olivia | |00000-134-bf6ea649-7a0b-4833-8448-60faa5ebfdcd-0-00001.parquet|1000000 |4031718 |Anjali |Tom | |00000-14-c7a02039-fc93-42e3-87b4-2dd5676d5b09-0-00001.parquet |1 |838 |Sarah |Sarah | |00000-144-9b6d00c0-d4cf-4835-8286-ebfe2401e47a-0-00001.parquet|1000000 |4031663 |Anjali |Tom | |00000-15-8138298d-923b-44f7-9bd6-90d9c0e9e4ed-0-00001.parquet |1 |831 |Brad |Brad | |00000-155-9dea2d4f-fc98-418d-a504-6226eb0a5135-0-00001.parquet|1000000 |4031676 |Anjali |Tom | |00000-16-ed37cf2d-4306-4036-98de-727c1fe4e0f9-0-00001.parquet |1 |830 |Brad |Brad | |00000-166-b67929dc-f9c1-4579-b955-0d6ef6c604b2-0-00001.parquet|1000000 |4031729 |Anjali |Tom | |00000-17-1011820e-ee25-4f7a-bd73-2843fb1c3150-0-00001.parquet |1 |830 |Noah |Noah | |00000-177-14a9db71-56bb-4325-93b6-737136f5118d-0-00001.parquet|1000000 |4031778 |Anjali |Tom | |00000-18-89cbb849-876a-441a-9ab0-8535b05cd222-0-00001.parquet |1 |838 |David |David | |00000-188-6dc3dcca-ddc0-405e-aa0f-7de8637f993b-0-00001.parquet|1000000 |4031727 |Anjali |Tom | +--------------------------------------------------------------+------------+------------------+----------------+----------------+ only showing top 20 rows テーブルが複数の小さなファイルで構成されており、新しいファイルの上限値と下限値が重複していることがわかります。データは明らかにソートされていません。 テーブルのソート順序を設定します。 spark.sql("ALTER TABLE ice_catalog.testnamespace.testtable WRITE ORDERED BY name ASC") テーブルコンパクションを有効にします (デフォルトで有効になっていますが、このデモの最初に無効化しました)。 aws s3tables put-table-maintenance-configuration --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable --type icebergCompaction --value "status=enabled,settings={icebergCompaction={strategy=sort}}" 有効にしたら、次のコンパクションジョブがトリガーされるのを待ちます。十分な数の小さなファイルが存在する場合、ジョブは一日中実行されます。コンパクションステータスは、次のコマンドを使用して確認できます。 aws s3tables get-table-maintenance-job-status --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable コンパクションが完了したら、テーブルを構成するファイルをもう一度調べます。データが 2 つのファイルにコンパクションされており、上限値と下限値がこれら 2 つのファイル全体でデータがソートされたことを示しています。 spark.sql(""" SELECT substring_index(file_path, '/', -1) as file_name, record_count, file_size_in_bytes, CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name, CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name FROM ice_catalog.testnamespace.testtable.files ORDER BY file_name """).show(20, false) +------------------------------------------------------------+------------+------------------+----------------+----------------+ |file_name |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name| +------------------------------------------------------------+------------+------------------+----------------+----------------+ |00000-4-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|13195713 |50034921 |Anjali |Kelly | |00001-5-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|10804307 |40964156 |Liza |Tom | +------------------------------------------------------------+------------+------------------+----------------+----------------+ ファイルの数が少なく、ファイルのサイズが大きくなっていて、指定したソート列全体でクラスタリングが改善されています。 z-order の使用にも同じ手順を実行しますが、その場合はメンテナンス設定で strategy=z-order を設定します。 利用可能なリージョン Sort コンパクションと z-order コンパクションは、 Amazon S3 Tables がサポートされるすべての AWS リージョン で利用でき、AWS Glue データカタログによる最適化が利用可能な汎用 S3 バケットにも利用できます。S3 Tables に関しては、既存の使用量とメンテナンス料金以外の追加料金はかかりません。データカタログによる最適化に関しては、コンパクション時にコンピューティング料金が適用されます。 これらの変更により、 sort 列または z-order 列でフィルタリングするクエリは、より高速なクエリ時間とエンジンコストの削減からメリットを得られます。私の経験では、 binpack から sort または z-order に切り替えるときに、データレイアウトとクエリパターンに応じて、3 倍以上のパフォーマンス向上を確認できました。実際のデータでパフォーマンスがどれだけ向上したかをぜひ教えてください。 詳細については、 Amazon S3 Tables の製品ページにアクセスするか、「 S3 Tables のメンテナンス 」ドキュメントをご覧ください。S3 Tables API または AWS Glue による最適化 を使用して、今すぐ独自のテーブルで新しい戦略のテストを開始することも可能です。 – seb 原文は こちら です。

6 月 16 日週のメインイベントは、セキュリティに焦点を当てた AWS re:Inforce カンファレンス でした。 ブログチームは、今では風物詩となった re: Cap 記事を書いて、発表を要約し、トップブログ記事へのリンクを掲載しました 。 それをさらに要約すると、 強化された IAM Access Analyzer 機能 、 ルートユーザーに対する MFA の義務付け 、 AWS Network Firewall への脅威インテリジェンス統合 といった新しいセキュリティイノベーションがいくつか発表されました。その他の注目すべき更新には、 AWS Certificate Manager からエクスポート可能なパブリック SSL/TLS 証明書 、 簡素化された AWS WAF コンソールエクスペリエンス 、 プロアクティブなネットワークセキュリティのための新しい AWS Shield 特徴量 (プレビュー中) などがあります。さらに、 AWS Security Hub がリスクの優先順位付けで強化され (プレビュー中)、 Amazon GuardDuty が Amazon EKS クラスターをサポートするようになりました 。 なかでも、私のお気に入りの発表は Amazon Verified Permissions チームからの発表です。このチームは、 Express.js 用のオープンソースパッケージをリリースして、 開発者がウェブアプリケーション API に外部のきめ細かな認可を実装できるようにしました 。これによって認可の統合が簡素化されるため、コードの複雑性が軽減し、アプリケーションのセキュリティが向上します。 Amazon Verified Permissions チームは、 Verified Permissions ポリシーストアを作成し、Cedar および Verified Permissions 認可ミドルウェアをアプリに追加してから、Cedar スキーマを作成してデプロイし、Cedar ポリシーを作成してデプロイする方法 の概要をまとめたブログも公開しました。Cedar スキーマは OpenAPI 仕様から生成され、 AWS コマンドラインインターフェイス (CLI) で使用できるようにフォーマットされています。 では、6 月 16 日週に行われたその他の新しい発表を見てみましょう。 6 月 16 日週のリリース re:Inforce 以外にも、私が注目したリリースをいくつかご紹介します。 AWS Lambda が Avro 形式と Protobuf 形式の Kafka イベントのネイティブサポートを発表 – AWS Lambda が、Apache Kafka の event-source-mapping (ESM) で、 Avro 形式と Protobuf 形式の Kafka イベントをネイティブにサポートするようになりました。この統合により、オープンソースの Kafka コンシューマーインターフェイスを使用して、スキーマの検証、イベントのフィルタリング、イベントの処理を実行できるようになります。また、 Powertools for AWS Lambda を使用して、カスタム逆シリアル化コードを記述せずに Kafka イベントを処理することもできるため、AWS Lambda での Kafka アプリケーションの構築が容易になります。 Kafka のお客様は、効率的なデータストレージ、迅速なシリアル化と逆シリアル化、スキーマ進化のサポート、異なるプログラミング言語間の相互運用性のために Avro 形式と Protobuf 形式を使用しており、データが処理パイプラインに入る前に、スキーマレジストリを利用してスキーマの管理、進化、検証を行っています。これまで、これらのデータ形式を使用するときは、イベントを検証、逆シリアル化、フィルタリングするためのカスタムコードを Lambda 関数内に作成する必要がありました。今回のローンチにより、Lambda は Avro と Protobuf に加えて、GSR、CCSR、SCSR との統合もネイティブにサポートするようになりました。こうしたサポートにより、カスタムコードを記述しなくても、これらのデータ形式を使用して Kafka イベントを処理できるようになります。さらに、不要な関数呼び出しを防ぐためのイベントフィルタリングを使用して、コストを最適化することも可能です。 Amazon S3 Express One Zone が単一の API コールによるオブジェクトのアトミックな名前変更をサポート – RenameObject API は、複数のステップが伴う名前変更操作を単一の API コールに変換することで、S3 ディレクトリバケットでのデータ管理を簡素化します。つまり、既存オブジェクトの名前をソースとして指定し、新しい名前を同じ S3 ディレクトリバケット内の宛先として指定することで、S3 Express One Zone 内のオブジェクトの名前を変更できるようになります。データの移動が不要なこの機能は、ログファイル管理、メディア処理、データ分析といったアプリケーションを加速しながら、コストを削減します。例えば、1 テラバイトのログファイルの名前変更なら数時間ではなく数ミリ秒で完了できるようになるため、アプリケーションの大幅な高速化とコスト削減につながります。 Valkey が Go、OpenTelemetry、パイプラインバッチ処理をサポートする GLIDE 2.0 を発表 – AWS は、Google および Valkey コミュニティと共同で、General Language Independent Driver for the Enterprise (GLIDE) 2.0 の一般提供開始を発表しました。これは、AWS の公式オープンソース Valkey クライアントライブラリの最新リリースです。Redis の代わりに使用でき、許容度が最も高いオープンソースである Valkey は、 Linux Foundation が管理しており、これからもオープンソースとして提供され続けます。すべての Valkey コマンドをサポートする Valkey GLIDE は、信頼性に優れた高性能多言語クライアントです。 GLIDE 2.0 には、開発者サポートを拡大し、オブザーバビリティを向上させ、高スループットワークロードのパフォーマンスを最適化する新しい機能が導入されています。Valkey GLIDE 2.0 は、Java、Python、Node.js の多言語サポートを Go (Google 提供) にも拡張して、4 つの言語全体で一貫性のある完全互換の API エクスペリエンスを提供します。今後さらに多くの言語がサポートされる予定です。今回のリリースにより、Valkey GLIDE は OpenTelemetry をサポートするようになりました。OpenTelemetry はオープンソースのベンダーニュートラルなフレームワークで、開発者がテレメトリデータやクライアント側の重要なパフォーマンスインサイトを生成、収集、エクスポートすることを可能にします。さらに、GLIDE 2.0 ではバッチ処理機能も導入されました。この機能は、複数のコマンドをグループ化して単一の操作として実行できるようにすることで、高頻度ユースケースのネットワークオーバーヘッドとレイテンシーを軽減します。 Valkey GLIDE の詳細については、最新の AWS Developers Podcast エピソード「 Inside Valkey GLIDE: building a next-gen Valkey client library with Rust 」をお聞きください。 AWS からのお知らせの詳細なリストについては、「AWS の最新情報」ページを随時ご確認ください。 その他の読み物 私のベルギー同胞である Alexis が、 ストリーミング可能な HTTP トランスポートを使用して MCP ツールサーバーを開発し、Lambda と API Gateway にデプロイする方法 を説明する 2 部構成シリーズの最初の記事を書きました。これは、AWS で MCP サーバーを実装する人にとって必読の記事です。私は、Alexis がリモート MCP サーバーの認証と認可について説明する第 2 部をとても楽しみにしています。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。 日本 ( 6 月 25～26 日)、 インド (オンライン: 6 月 26 日)、 ニューヨーク (7 月 16 日) など、最寄りのイベントにご登録ください。 7 月と 8 月に開催される 台北 (7 月 29 日)、ジャカルタ (8 月 7 日)、メキシコ (8 月 8 日)、サンパウロ (8 月 13 日)、ヨハネスブルグ (8 月 20 日)の Summit もスケジュールに入れておきましょう。9 月と 10 月にはさらなる Summit が予定されています。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 今週のニュースは以上です。6 月 30 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

1．イントロダクション H.U.グループは、「ヘルスケアにおける新しい価値の創造を通じて、人々の健康と医療の未来に貢献すること」をMissionに掲げる企業グループです。当グループでは、検査・関連サービス事業、臨床検査薬事業、ヘルスケア関連サービス事業の3つを主軸とし、医療に関する様々な製品やサービスを提供しています。 そして我々が所属するH.U.グループ中央研究所では、サイエンスを起点として新たなシーズの探索や新規事業の創出を目指し活動しています。その中でもバイオインフォマティクス課では、オミックス解析に関する研究開発や、解析環境の開発と実装などに取り組んでいます。 今回、オミックス解析の中でも、ゲノム解析の情報処理工程をリアルタイムかつ自動で実行する解析環境の開発と技術検証を実施しましたので、本ブログでその取り組みをご紹介いたします。 2．背景 ヒトや細菌、ウイルスなどのゲノムデータからは非常に多くの情報を得ることができ、疾患の診断や治療、感染症の追跡や制御、新薬開発などに役立つことから、医療におけるゲノム解析の需要は年々高まってきています。 ゲノムデータを解析する遺伝子検査にはいくつかの方法があります。その中でも、次世代シークエンサー (NGS) と呼ばれるDNAやRNAの塩基配列を高速かつ大規模に決定する技術を用いた解析では、出力されるデータ量が膨大で複雑な計算を行うため、計算リソースの確保が必須です。 弊社では、研究開発や事業部門においてヒトゲノムシークエンスや腸内細菌叢解析などほぼ全ての解析をオンプレミスサーバーで実施していますが、ストレージや計算リソースを需要に合わせて柔軟に調整することが難しく、計算リソースの過不足が生じてしまう課題がありました。 また、ゲノムデータの解析は複数の工程を経て行われ、コマンドラインを用いた操作も必要です。社内研修による検査員の技術取得も進めていますが、検査需要の急増に対応した人員の育成・拡充には時間を要します。そのため、解析の実行自体も大きなハードルとなっていました。 これらの課題を解決するために、柔軟に解析環境をスケールでき、ゲノムデータ解析の一連の工程を自動化した解析環境の開発に取り組みました。開発にあたり、多様なサービスやオミックスデータ解析で豊富な実績を有するAWSを利用しました。 3．技術検証の詳細 3-1．構築環境の概要 我々は、AWSマネージドサービスを利用し、以下の機能をもつ解析環境を実現しました。 シークエンスデータのクラウドへの転送から解析までの全工程を自動化 サンプル数やプロセスに応じた柔軟な解析リソースの立ち上げ 解析状況の確認のための情報の集約 解析状況をユーザーへ通知 今回の検証で使用したシークエンサーの特徴として、経時的にシークエンスの生データが出力され、実験者がシークエンスを停止させるまでデータが出力されます。この経時的に出力されるデータを都度自動的に解析することで、人の手を介さずにほぼリアルタイムでの解析を実現しました。また、取得されたデータ量についてユーザーにメール通知を送る機能を実装しました。これまで実験者がシークエンスの状況や取得データ量を目視で確認していましたが、自動で取得データ量を確認することで、実験者の作業削減にも繋がりました。さらに、実験者は必要データ量の取得が完了したことを通知で容易に把握でき、より適切なタイミングでシークエンスを停止することも可能になりました。 解析を全て自動化すると、現在の解析状況の把握が難しくなるため、プロセス毎に作成されるファイルの出力状況を集約し、進捗を確認するためのデータベースを作成しました。このデータベースは進捗状況の把握だけでなく、解析に要した時間の集計などにも活用が可能です。 これらの機能を実現する解析環境の構築は、全て研究開発員による内製開発で行いました。 3-2．ソリューション概要 上記の機能を実現するにあたり、各工程で以下のAWSサービスを利用しました。 【構成図】 Amazon Simple Storage Service (Amazon S3) へのデータ転送： AWS DataSync を利用し、シークエンスの生データをオンプレミスからS3へ転送します。DataSyncのタスク作成や実行はオンプレミスで作成したスクリプトで自動化しました。 各種処理の自動実行： AWS上で行う各種処理は AWS Lambda で実行を管理しました。 キーとなるファイルがS3に作成されたことを Amazon EventBridge で検出し、 AWS Step Functions を介して各処理のLambda関数が実行されます。 Lambda関数は機能ごとに分割して実装することで、開発やトラブルシューティング時の切り分けを容易にしました。また、それら複数の関数を効率的に連携・管理するために、Step Functionsを活用しています。 解析の実施： AWS Lambdaで AWS Batch ジョブがキックされると、解析パイプラインが実行されます。 解析パイプラインはNextflowとDockerを使用して作成しております。Dockerイメージは Amazon Elastic Container Registry (Amazon ECR) に格納し、解析時にはイメージからコンテナを作成して解析が行われます。これにより、サンプル数や解析プロセスに応じた柔軟な計算リソースの立ち上げを実現しています。 データの集約： Amazon DynamoDB を利用し、解析バッチ単位のテーブルの作成と各種結果ファイルのパスやタイムスタンプなどを集約します。 通知機能： 解析状況の通知には、 Amazon Simple Notification Service (Amazon SNS) を使用しました。 ４．構築振り返り 今回の解析環境は、全て内製で構築しました。しかし、当初はAWSについての知識や利用経験が浅く、機能や役割を理解することはスムーズにできても、運用上どのような設定にするのが最適かを考えながらの構築には非常に多くの時間を要しました。自分たちで手を動かしてみないと見えてこない部分も多いため、チーム内で構築範囲を分担し、各担当範囲のサービスを実際に動かしてみることから始めました。トライ&エラーを繰り返し、各々の課題や疑問を共有・議論していくことで、チーム全体の理解を深めていきました。情報収集の際は、AWSに関する様々なドキュメントや先行事例がウェブに公開されているため、非常に参考になりました。さらに、生成AIの活用も非常に有効で、調査や検証の効率を高めることができました。また、サポートも充実しており、特に構成の検討ではAWSチームからの技術的な支援に大変助けられました。 構築を進めていくと、初めに想定していた構成では対応しづらい部分もあり、その都度「AWSのマネージドサービスで何ができるのか」と「自分たちが実現したい機能」をすり合わせ、試行錯誤しながら解決していきました。 今回の内製開発を通して、技術的な知識だけでなく、解析の流れや必要な性能、運用上の制約などを高い解像度で把握し、適切なサービスを選択して活用することが非常に重要であると改めて実感しました。 ５．成果 今回、全てのシークエンスデータの解析工程を自動化し、リアルタイムでの解析にも対応できる柔軟性の高い解析環境の開発と技術検証を行い、実現性や効果について様々な知見を得ることができました。自動化を実現することで、解析の作業負担削減やヒューマンエラーの防止だけでなく、実験者が他のタスクにリソースを割くことができるようになり、全体の作業効率の向上も期待されます。さらに、リアルタイム解析と全体の効率化により、TAT（Turn Around Time: 検体受領から報告完了までの時間）の更なる短縮が可能となり、迅速な結果報告が求められる検査にも貢献できると考えます。実際に、クラウドベースのリアルタイム解析環境構築によってデータ解析を高速化し、臨床現場での迅速な意思決定を支援した論文も報告されています[1]。 もちろんこれらの技術は、今回検証したようなリアルタイムで経時的に出力されるデータだけでなく、他のシークエンスデータの解析などにも活用できます。 また、全て内製開発を行うことで、メンバーのスキル向上にも繋がりました。「作りたいものを思い描いた通りに実現する」ことは中々に難しく、外注する際にはベンダーとの認識の共有でギャップが生じることがあります。今回、内製開発をしたことで実験者の意見も含めた現状の課題や理想像の認識共有がスムーズに進み、各メンバーが必要な技術を習得することで、現場のニーズを反映した機能を実現することができました。 5．まとめ AWSの各種サービスを活用し、ゲノム解析の情報処理工程を自動で実行・スケールする解析環境の開発と検証の取り組みについてご紹介しました。今回は技術検証が目的でしたが、今後はこの技術と得られた知見を活用し、検査需要の変動に柔軟に対応でき、ユーザービリティの高い解析環境の開発と実装を目指していきたいと考えています。 また、現在は環境の複製や別プロジェクトでの活用を見据え、Infrastructure as Code (IaC) についての取り組みも進めています。IaCによってインフラ構築も自動化し、迅速な横展開や効率的なバージョン管理も可能になることで、更なる付加価値向上が見込まれます。 以上のように、我々は日々進歩する技術を取り入れながら自社でその技術を醸成し、より価値の高いサービスを提供することで医療とヘルスケアの発展に貢献して参ります。 参考文献： [1] Gorzynski, John E., et al. “Ultrarapid Nanopore Genome Sequencing in a Critical Care Setting.” New England Journal of Medicine, vol. 386, no. 7, 2022, pp. 700–702. https://doi.org/10.1056/NEJMc2112090 著者： 久我有祐美 H.U.グループ中央研究所 試験開発部 バイオインフォマティクス課 オミックス解析のための解析環境整備や解析パイプラインの開発、ゲノム解析などを担当しています。 木下大輔 H.U.グループ中央研究所 試験開発部 バイオインフォマティクス課 オミックス解析のための環境整備やシステム開発、サーバー管理などを担当しています。 関家友子 H.U.グループ中央研究所 試験開発部 バイオインフォマティクス課 データ解析全般を担当するとともにデータ解析のための環境整備も担当しています。 湯原悟志 H.U.グループ中央研究所 試験開発部 担当部長 バイオインフォマティクス関連領域における研究開発戦略立案など担当しています。

日本時間 2025/6/25 に、Amazon Bedrock Guardrails が日本語に対応しました。この日付はくしくもAWS Summit Japan 2025 の開幕初日になり日本にとってはうれしいニュースとなりました。本記事では、日本語対応の詳細について速報をお届けします。 (AWS Summit で話す著者の様子。この後 Amazon Bedrock Guardrails を紹介しました) Amazon Bedrock Guardrails のアップデート概要 今回のアップデートで、コンテンツフィルターと拒否トピックについて Standard Tier を選択することで日本語を含む 60 以上の言語をカバーできるようになり、誤字脱字などにも頑健な検出ができるようになりました。コンテンツフィルターには、モデルのシステムプロンプトを抜き出すようなPrompt Attack の検知も含みます。これまでのモデルは Classic Tier という扱いになります。 詳細 : Amazon Bedrock Guardrails announces tiers for content filters and denied topics 対応言語 : Languages supported by Amazon Bedrock Guardrails なお、ワードフィルタとグラウンディングチェックは Standard Tier でもまだ日本語に対応はしていません。 注意点として、Standard Tier を使用する場合クロスリージョン推論が現在必須となります。クロスリージョン先は Guardrails のリージョンにより決まっているようで、例えば東京で Guardrails を使う場合は APAC Guardrail v1:0 のプロファイルを使うことになり文字通り APAC 圏内で推論が分散されます。国内に閉じる要件がある場合この点に留意する必要があります。 詳細 : Supported Regions for cross-Region guardrail inference Amazon Bedrock Guardrails の価格 最新の価格は Pricing のページ を確認いただくとして、本記事執筆時点ではコンテンツフィルタの価格が $0.15 / 1,000 text units となります。”text unit” はモデルの価格に使用されるトークンではなく文字数の単位で、1 text unit は最大 1,000 文字を含むチャンクになります。この「文字」は Unicode 文字で、2 byte の日本語であっても文字は 1 文字になります。1 text unit = 最大 1,000 文字ですから、コンテンツフィルタの価格は $0.15 / 1,000,000 文字となります。 ※記事執筆時点で、Classic と Standard で料金が変わらないことを開発チームに確認しています。 Amazon Bedrock Guardrails の利用方法 では、実際に利用方法を見ていきましょう。 AWS Console で Amazon Bedrock のメニューにアクセスします。 Amazon Bedrock のメニューの中から Guardrails を選択します。 Guardrails を作成します。この時、クロスリージョン推論にチェックを入れてください。 コンテンツフィルターなどを作成する際、忘れずに “Standard” を選択します。 では、実際に試して見ましょう。Guardrails の右側のペインからすぐに試すことが出来ます。今回は極道のゲームの主人公的なセリフを入れてみました。 しっかりとコンテンツが “Violence” として分類され応答がブロックされていることを確認できました。検出した場合の挙動はブロックか記録のみに留める方法があります。 ちなみに Classic だと素通りしてしまいますが、モデルの方が回答を拒否する安全策がとられている場合そちらで回答が返却されます。 おわりに 本記事では、日本語対応した Amazon Bedrock Guardrails の概要と価格、使い方をお伝えしました。生成 AI の返答に誤りや有害な内容が含まれていたためにサービス停止につながった事例が 2024 年時点でも複数観測されています 。サービス停止は開発の停滞だけでなく会社の評判にも悪影響を与えるインシデントです。Guardrails の適用によりリスクを抑え持続的な生成 AI 活用につなげて頂ければ幸いです。

2025 年 6 月 25 日、「AWS ジャパン 生成AI実用化支援プログラム」において、日本の生成AI実用化を加速する2つの新プランの提供開始を発表いたしました。 プログラムの進化と実績 AWSでは、2023年の「 AWS LLM 開発支援プログラム 」から、2024年7月の「 AWS ジャパン生成 AI 実用化推進プログラム 」の開始を経て、一貫して日本における生成AI技術の実用化を支援してまいりました。生成AI活用の戦略策定段階からご支援する「戦略プランニングコース」、生成AI基盤モデルの開発・カスタマイズを支援する「モデルカスタマイズコース」、汎用モデルを活用したシステム開発を支援する「モデル活用コース」の3つのコースを通じて、200社を超える企業・団体の皆様の生成AI実用化を支援しています。 生成AI技術は現在、データ処理の自動化から、自律的な判断・行動の実現へと発展しています。この発展をさらに支援するため、この度、生成AIの具体的な産業応用と技術開発を促進する、「AWS ジャパン 生成AI実用化支援プログラム」の2つの支援プランを開始いたします。 新たに発表する2つの支援プラン 『 GENIAC-PRIZE 応募者支援プラン』 『 GENIAC-PRIZE 応募者支援プラン』は、経済産業省と国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO）が主催する生成AIの社会実装と開発力強化を目指す懸賞金型プロジェクト「GENIAC-PRIZE」への応募者を支援するプランです。 本プランでは、GENIAC-PRIZE応募者の皆様に対して、計算リソースの調達から実装・事業化までのプロセスを一貫してサポートいたします。 GENIAC-PRIZE 詳細に関しては、GENIAC-PRIZE特設サイトをご確認ください。（ https://geniac-prize.nedo.go.jp/ ） 『Agentic AI 実用化推進プラン』 『Agentic AI 実用化推進プラン』は、企業・団体や開発者の皆様のAgentic AI実用化への取り組みを総合的に支援するプランです。 Agentic AI開発において、スケーラビリティの確保やマルチエージェントシステムの構築といったアーキテクチャ設計が重要であり、また意思決定アルゴリズムの実装や倫理的配慮、セキュリティとプライバシーの確保など、自律性とセキュリティに関する要素を考慮する必要があります。さらに、大規模データ処理の効率化やリアルタイム応答性の実現、既存システムとの統合など、実装と運用面での多くの検討を行う必要があります。 本プランでは、Agentic AI開発に必要となる設計思想策定（ゴールの明確化やタスク分解）から継続改善可能な運用体制確立までを、AWSとAWSパートナーが連携しサポートいたします。 プランへのお申し込み方法 両プランへの申し込みは、「AWS ジャパン 生成AI実用化支援プログラム」の各コースへご登録の上、AWS担当者へそれぞれのプランへ参加希望である旨お伝えください。 『GENIAC-PRIZE 応募者支援プラン』 「モデルカスタマイズコース」にご登録の上、AWS担当者へ参加希望をお申し出ください。 募集期間は、2025 年 6 月 25 日から 2025 年 12 月 31 日 『Agentic AI 実用化推進プラン』 「モデル活用コース」にご登録の上、AWS担当者へ参加希望をお申し出ください。 募集期間は、2025 年 6 月 25 日から通年での募集 「 AWS ジャパン生成 AI 実用化推進プログラム 」は、日本国内に法人又は拠点を持ち、AWS で生成 AI を活用しビジネス課題の解決に取り組む国内の企業・団体お客様を対象としたプログラムとなります。応募に際しては、フリーアドレスでの応募はご遠慮いただいておりますのでご注意ください。 おわりに 生成AI技術は現在、データ処理の自動化から、自律的な判断・行動の実現へと発展しています。 AWSは、これら新プランを通じて、お客様の具体的な課題解決とビジネス価値の創出をサポートしてまいります。 ぜひ皆様のプログラム参加をお待ちしております。

1. はじめに 本稿では、株式会社 NTT ドコモにおいて、モバイルネットワークにおける障害検知の迅速化に向けた可視化システムを導入された事例をご紹介します。 第一弾 では、取り組みの背景とアーキテクチャ概要についてご紹介しました。第二弾では、技術観点において AWS Lambda や Amazon Managed Grafana がどのように使われ、構築されたか、その技術的な Tips と一緒にご紹介します。 2. 可視化システムのアーキテクチャおよび実装方法 図 1.  アーキテクチャ概要 データが Amazon S3 にアップロードされたことをトリガーとして AWS Lambda が起動します。 AWS Lambda によりファイルの解凍、データの抽出、集計など必要な ETL 処理が行われ、Amazon Timestream に可視化に必要なデータを格納します。 Amazon Managed Grafana のダッシュボード から Amazon Timestream に対してクエリが発行され、取得したデータのメトリクスの可視化がされます。 Amazon Managed Grafana のダッシュボードは、1 分ごとに自動更新されほぼリアルタイムでトラフィックの変動が確認できます。 AWS Lambda の実装 AWS Lambda では、大きくわけて2つの処理を行います。 1つ目は、Amazon S3 にアップロードされたトラフィックデータの ETL 処理です。アップロードされた CSV ファイルは、装置ごとに数千行のトラフィックデータを保持しています。そこから、時刻と装置の ID と可視化に必要なトラフィックデータを抽出します。 2つ目は、Amazon Timestream への書き込み処理です。 共通の属性を持つレコードのバッチ書き込み によりパフォーマンスとコスト最適化を行っています。 Amazon Timestream の書き込みコストは、書き込まれたデータ量に対して課金され、そのデータサイズは最も近い KiB に丸められるため、書き込み回数や書き込みデータ量を小さくすることでコスト最適化が可能です。AWS Lambda から Amazon Timestream への書き込み処理では、1 レコードずつ書き込むのではなく 100 レコード以内の単位でのバッチ書き込むことで書き込みパフォーマンスの最適化を行っています。さらに、属性が共通のものがある場合、共通値は書き込みごとに common_attributes （共通属性）として指定することで書き込みコストを削減しています。 Amazon Managed Grafana の実装 図2. Amazon Managed Grafana による可視化画面 オペレータ向けの可視化システムとして、Amazon Managed Grafana のダッシュボード上に複数のパネルを表示しています。 それぞれのパネルは地域ごとに、Amazon Timestream のメジャー値である ①「Attach試行数」の合計値 と ②「Attach成功数」の合計値と ③  ②を①で割った Attach 成功率 として、時系列グラフで表示しています。Attach とは、モバイルネットワークのある装置における接続セッションの確立のことであり、その成功率がパフォーマンス監視として重要な指標になります。それらメジャー値は 1 分周期で生成されているため、1 分周期でダッシュボードの自動更新を Amazon Managed Grafana のダッシュボードの機能により実現しています。これによって、1 分周期で各パネルで定義されたクエリが Amazon Timestream 向けに発行されます。オペレータがよりリアルタイムに監視を行うために、10 秒以内ですべてのパネルのデータポイントの表示がされる必要がありパフォーマンスを向上させることが重要なポイントでした。 他のパネルのクエリ結果の流用によりパフォーマンスの向上とコスト効率化を実現しています。 ダッシュボード内にある他の 1 つのパネルのクエリ結果を使用することができます。 パネル間でクエリ結果を共有する ことで、データソースに対して実行されるクエリの数とクエリデータ量を削減することができ、ダッシュボードのパフォーマンスの向上とコストの最適化を実現しています。 クエリの WHERE 句に時刻範囲を指定することで必要な時間のみを表示することでパフォーマンスの向上とコスト効率化を実現しています。 ダッシュボード上でユーザーの指定する時間範囲によって、取得するデータの期間を変更できるようにし、指定した期間のみのデータを取得するようにしています。以下はクエリ文のサンプルです。 SELECT time , measure_name ,SUM("Attach試行数") AS " Attach試行数" ,SUM("Attach成功数") AS " Attach成功数" ,ROUND((CAST(SUM("Attach成功数") AS double ))/ SUM("Attach試行数"),3) as " Attach成功率" FROM $__database.$__table WHERE time between from_milliseconds($__from) AND from_milliseconds($__to) GROUP BY time,measure_name ORDER BY time,measure_name 3. 終わりに 本稿では、NTTドコモにおけるモバイルネットワークの障害検知の迅速化のために導入された可視化システムにおいて、主に AWS Lambda と Amazon Managed Grafana の実装例をご紹介しました。これにより可視化システムの高パフォーマンスを実現し、より迅速にサービス障害に気付くことが可能となりました。今後もより大規模なデータの可視化のためにパフォーマンス観点およびコスト観点での効率化を引き続き行っていく予定です。   著者 株式会社NTTドコモ ネットワーク本部　サービスマネジメント部　オペレーションシステムDX担当　 今井　識 株式会社NTTドコモにて、モバイルネットワークの遠隔監視・措置業務向け可視化システムの企画・開発・運用を一貫して行うチームのマネジメントと技術課題解決のリードを担当しています。 アマゾン ウェブ サービス ジャパン合同会社 宮崎 友貴 ソリューションアーキテクトとして通信業界のお客様の AWS 活用 を支援しています。   アマゾン ウェブ サービス ジャパン合同会社 高野 翔史 こソリューションアーキテクトとして製造業界のお客様の AWS 活用 を支援しています。

1. はじめに 昨今のモバイルネットワーク は、人同士のコミュニケーションツールから、いまでは決済、物流など様々なサービス・生活を支える重要な社会基盤へと進化しており、これまで以上に安定したサービスの提供が求められています。一方で、モバイルネットワークの拡張と複雑化が進み、通信事業者にとってより早く異常を検知し、被疑箇所を特定し、迅速に復旧を行うことは大きな課題となっています。 これまで、NTT ドコモは、装置からの警報を契機とした設備監視を行い、異常時にサービス影響のある障害であるかを切り分けていました。トラフィックの変動から異常を検知するための可視化システムを構築することで、オペレーターが早期にサービス障害に気付き迅速に周知広報や措置回復させることでより安定したモバイルサービスを提供することを可能としました。 参考：2023 年 5 月 「 電気通信サービスにおける 障害発生時の周知・広報に関する ガイドライン 」が策定され、 障害発生時刻から原則 30 分以内の初報の公表が必要とされました。 2. 可視化システムの要件 ドコモでは障害を早期に検知する方法として、現在のトラフィックの状態と平時のトラフィックの状態それぞれの推移を時系列で可視化することを目指しました。トラフィックの状態を表すメトリクスとしては、モバイルネットワーク装置から監視装置を経由して収集している PM: Performance Management データ (トラフィックデータ）を使います。 新規の可視化システムを開発するにあたり、以下の要件がありました。 トラフィックデータの前処理要件： 収集したトラフィックデータを解凍し、データを整形し、装置情報のマッピングを行うETL機能 ダッシュボードの表示要件： 最短 1 分間隔での自動更新機能 リアルタイム性能要件：   データ受信から表示までの全処理を数分以内に完了 ダッシュボード上のクエリ応答（ダッシュボード画面の表示時間）は 10 秒以内 コスト最適化要件： 大容量データに対応した効率的なシステム設計の実現 システム運用における維持費用の最小化 上記のうち、特に最も重要な要件は、リアルタイム性要件です。より迅速に障害を検知するためには、トラフィックデータを受信してから可視化しオペレーターが異常を検知するまでの時間をできる限り短縮する必要があります。また、そのような状況下でダッシュボードの表示時間ができる限り短い時間であることも利用者であるオペレータにとって非常に重要な要件になります。一方で、トラフィックデータは、最短 1 分周期で装置群単位で大量のメトリクスを扱っており、多くの同時読み書きトランザクションが発生することが想定されます。したがって、大量の同時読み書きトランザクションが常時発生するシステムにおいてリアルタイム性を実現することが重要なポイントになります。 3.  ソリューション 上記要件を満たすソリューションとして新規に構築したシステムのアーキテクチャ図は以下になります。 図1.  アーキテクチャ概要 データが Amazon S3 にアップロードされたことをトリガーとして AWS Lambda が起動します。 AWS Lambda によりファイルの解凍、データの抽出、集計など必要な ETL 処理が行われ、Amazon Timestream に可視化に必要なデータを格納します。 Amazon Managed Grafana のダッシュボード から Amazon Timestream に対して最短 1 分間隔のクエリが発行され、取得したデータのメトリクスの可視化がされます。 Amazon Managed Grafana のダッシュボードは、最短 1 分ごとに自動更新されほぼリアルタイムでトラフィックの変動が確認できます。 本アーキテクチャのポイントとしては、以下 4 つあります。 サーバーレスアーキテクチャの採用 ドコモのオペレーション現場では、サービス影響可視化システムはオペレーションに使用するツールの 1 つであり、モバイルネットワークに対する保守運用が集中すべき業務であり、ネットワークビジネスの運用コスト削減のためにもシステム基盤の運用はなるべく軽減する必要があります。そこで、AWS のサーバーレスアーキテクチャを採用することでインフラ部分の運用が不要になり運用コストをできる限り抑えています。 Amazon Timestream と Amazon Managed Grafana による統合サービスの活用 Amazon Timestream は、1 分あたり数十 GB を超える時系列データを取り込み、TB 規模の時系列データに対して SQL クエリを数秒で実行できる時系列データベースサービスです。ドコモでは、リアルタイム性の要件が強く、また、今後拡大するデータ量を考慮して Amazon Timestream を採択しました。 Amazon Managed Grafana は、 オープンソースの Grafana をベースにしたフルマネージドサービスで運用データを簡単に可視化します。ダッシュボードの自動更新機能がある点と Amazon Timestream とシームレスに連携でき、親和性に優れている点からリアルタイム性監視用途に向いているため採択しました。 採用にあたっては、机上検討だけではなく、PoC の実施により実際のデータに近いサンプルデータを使って機能評価および性能評価を行い、要件を満たせることを確認しました。   複雑な集計処理はクエリ側ではなく AWS Lambda 側で実装 トラフィックの変動から異常を検知するために過去のトラフィックデータと現在のトラフィックデータの比較を行い、その乖離が大きい場合に検知を行う目的があったため、その乖離率の算出を行う必要がありました。Amazon Managed Grafana から Amazon Timestream に対しての SELECT 文で集計を行う方法と、AWS Lambda 側で集計を行ってから Amazon Timestream に投入する方法があります。前週比較のみのような簡易な集計の場合は前者を、数週間分の比較や複雑な統計関数を使用する場合には後者、と使い分けることでリアルタイム性を保つような工夫を行っています。結果として、10 秒以内でのクエリ結果の可視化（ダッシュボード画面の表示）を行うことを実現できました。 コスト効率が良いデータの扱い トラフィックデータは TB を超えるほどのデータ量があります。オペレータが扱いたいデータを予め定義し可視化に必要な分だけ AWS Lambda で抽出を行うことで Amazon Timestream や Amazon Managed Grafana で扱うデータ量を最小限に絞りコスト最適化を図っています。 オペレータ向けに提供された可視化画面は以下になります。モバイルネットワークを構成するコンポーネントの 1 つであるコアネットワークのコントロールプレーンを制御する装置である MME のトラフィックデータを時系列で地域別に表示しています。以下の例では、Attach の試行数/成功数/成功率について平時の値と重ねて表示しており、オペレータが異常に気付けるようになっています。 図2. Amazon Managed Grafana による可視化画面 4.  まとめ 結果として、NTT ドコモにおけるモバイルネットワークのオペレーション現場に、既存の監視では迅速に気づくことが難しいサービス障害を迅速に検知できる仕組みを導入しました。また、トラフィックデータの状態を可視化したことで、故障発生時の障害箇所の切り分けにも使用でき、より迅速な復旧措置にもつながっています。 本稿では、取り組みの背景とアーキテクチャ概要についてご紹介しました。 第二弾 では、より技術的な実装方法をご紹介します。 著者 株式会社 NTTドコモ ネットワーク本部　サービスマネジメント部　オペレーションシステム DX 担当　 今井　識 株式会社 NTTドコモにて、モバイルネットワークの遠隔監視・措置業務向け可視化システムの企画・開発・運用を一貫して行うチームのマネジメントと技術課題解決のリードを担当しています。 アマゾン ウェブ サービス ジャパン合同会社 宮崎 友貴 ソリューションアーキテクトとして通信業界のお客様の AWS 活用 を支援しています。 アマゾン ウェブ サービス ジャパン合同会社 高野 翔史 ソリューションアーキテクトとして製造業界のお客様の AWS 活用 を支援しています。

みなさんこんにちは！Solutions Architect の富永崇之です。普段は金融領域のお客さんをご支援する傍ら、大小様々な会場で映像演出をする活動をプライベートで行っており、 AWS Summit Japan 2025 においては昨年に引き続き基調講演前のウェルカムパフォーマンスの映像演出を担当しています。 ウェルカムパフォーマンスでは DJ / プロデューサーの FPM 田中知之さんが流す音楽に合わせて即興で映像を構成していきますので、もし AWS Summit Japan 2025 にご来場の際は、ぜひ朝からお越しいただいて楽しんでいただければと思います。さらに基調講演後、Room A ~ E にて開催の各セッションの合間に流れる映像も昨年に引き続いて担当していますので、こちらも楽しんでいただければと思います。 (写真は AWS Summit Japan 2024 のものになります) さて、今年の AWS Summit Japan 2025 では、ウェルカムパフォーマンスのほかに AWS Summit Japan の受付に設置される Welcome ボードに映すサイネージ映像と、ホール内の休憩ラウンジに設置されるフォトスポットに映すサイネージ映像の制作も担当しています。 この 2 つのサイネージ映像は Amazon Nova Reel を活用して作成しています。本稿では AWS Summit Japan 2025 のサイネージ映像を Amazon Bedrock と Amazon Nova Reel を使って作成した事例についてご紹介します。 Amazon Nova Reel を使用した映像の生成 サイネージ映像は背景映像やロゴ、テキストといった要素から構成されています。この内、背景映像を Amazon Nova Reel を使用して作成しています。 Amazon Nova Reel 1.1 では最長 120 秒で 720p 24fps の映像を、512 文字以内のプロンプトテキストから生成することができます。料金は従量課金制で、生成する映像の長さに応じて課金されます。Amazon Bedrock のプレイグラウンドに画像/映像生成を簡単に試行できる UI がありますので、こちらを使用していきます。今回サイネージ用に何種類かの映像を作成したのですが、その中の 1 つで光の粒で構成された CG の映像には以下のプロンプトを使用しました。 An abstract CG image of cyber space composed of particles. The particles move in wave. it gives a creative, fun, exciting impression. Zoom in. Amazon Nova Reel 1.1 にはマルチショット動画という機能があります。マルチショット動画では単一のプロンプトテキストから 6 秒の映像を複数生成し、生成した映像をつなぎ合わせて最長 120 秒の映像を作成することができます。もっと細かく制御したい場合は、6 秒の動画ごとにテキストプロンプトを切り替える制御も可能になっています。例えば、最初の 60 秒はカメラワークを Zoom In させて、後半の 60 秒はカメラを俯瞰視点にするといった制御も可能です。 つなぎ合わされた出力映像は Amazon Simple Storage Service (Amazon S3) に出力されますが、つなぎ合わせる前の 6 秒ごとのシーン映像も Amazon S3 に出力されています。今回はフォトブース用にゆっくり背景映像を切り替える映像にしていきたかったため、全映像を一度ダウンロードし、映像がゆっくり切り替わるように映像の編集を行っています。さらに、アップスケール処理(ディテールを保ちながら 720p から 4K に拡大する処理)やカラーグレーディング処理(狙った色合いになるよう調整する処理)を施し、ロゴモーションやテキストメッセージを追加して構成したのが会場で流れている映像になります。 生成 AI から新たなインスピレーションを得る Amazon Bedrock と Amazon Nova Reel の興味深い点は、映像の生成にかかる時間が非常に短いところで、120 秒の映像がわずか 3 – 5 分で生成できます。そのため、生成の試行錯誤が非常に容易です。 今回、作成した映像の 1 つは「AWS Summit Japan 2025」 をテーマにしています。しかし、 AWS Summit Japan 2025 の映像といっても想像するものは人それぞれです。カンファレンスホールの写実的な映像を想像する人もいれば、クラウドを意識した近未来的な CG の映像を想像した方もいらっしゃるかと思います。 今回は敢えて最初からイメージを固めず、A video on the theme of AWS Summit Japan. Creative and free expression. ( AWS Summit Japan というテーマの映像を独創的で自由な表現で) というプロンプトから始めました。シード値を変えながらいくつかの映像を生成し、そこから発想を広げていくアプローチを取っています。すると、本当に様々な生成 AI が考える AWS Summit Japan の映像が出力されます。生成 AI の出力の中には、従来では思いつかないような独創的なイメージや、面白いイメージも出てきまして、そこから様々なインスピレーションを得ることができます。その中からフォトブースに合いそうなイメージをピックアップし、狙ったイメージに近づけるようプロンプトに条件を追加していきました。 最終的には以下のプロンプトで生成した映像を採用しています。プロンプトには 4K という文言がありますが、こちらはディティールの細かい映像を導くためのプロンプトで、出力解像度は前述の通り 720p になります。このプロンプトにより東京の都市景観とクラウドコンピューティングが融合した、リアルな映像が生成されます。その他、Amazon Nova Reel のプロンプトエンジニアリングのベストプラクティスを知りたい方はドキュメント ( https://docs.aws.amazon.com/ja_jp/nova/latest/userguide/prompting-video-generation.html ) を参照してください。 Video on the theme of “AWS Summit Japan”. The image is a fusion of the cityscape of Tokyo and cloud computing. 4K, photorealistic. 欲しい画像や映像の具体的なイメージを最初から言語化することは難しく、そもそもどのような映像が適しているか分からない状況も多いと思います。そんな状況であっても、まず生成 AI にいくつか生成させてみて、そこから具体的なイメージに近づけていくというアプローチがとれるのは、生成 AI ならではだと思います。 まとめ 本稿では AWS Summit Japan 2025 の Welcome ボードおよびフォトブースで使用するサイネージ映像の作成に Amazon Nova Reel を組み入れた事例をご紹介しました。 最初から思い通りのイメージを狙ったプロンプトを作成するアプローチも可能ですが、インスピレーションを得るために生成 AI に自由に発想させるというアプローチもとることができ、映像の表現の幅を広げるためのツールとしてとても有用だと思いますので、みなさんもぜひ Amazon Nova Reel を触ってみてください。プロンプト作成のコツとしては、具体的な視覚的要素 (色、動き、雰囲気) を含めることで、より意図に近い映像が生成されやすくなります。Amazon Nova Reel を試してみたい方は、Amazon Bedrock コンソールのプレイグラウンドから簡単に始められます。まずは短いプロンプトから試してみて、生成 AI が描く世界を体験してみてください。 Amazon Bedrock と Amazon Nova Reel がどんな映像を生成したかは、ぜひ会場で確かめてみてください。それでは AWS Summit Japan 2025 でお会いしましょう！ 著者について 富永 崇之 (Takayuki Tominaga) AWS Japan のソリューションアーキテクトとして、金融業界のお客様を中心に日々クラウド活用の技術支援を行なっています。 ソリューションアーキテクトとしての業務の傍ら、都内のクラブやライブハウスで VJ としても活動しています。

この記事は 2025 年 2 月 13 日に公開された Using Open Job Description to Customize Submitter Workflows  を翻訳したものです。 レンダーファームへのジョブの定義と送信プロセスを効率化したいアーティストやテクニカルディレクター (TD) の方はいらっしゃいますか？このブログでは、Open Job Description (OpenJD) を使用して AWS Deadline Cloud の統合サブミッターをカスタマイズする方法について説明し、最後にゼロから作成したカスタムサブミッターのコードサンプルを紹介します。 OpenJD は、ユーザーがレンダーファームに送信するジョブを定義できるオープンな仕様です。ジョブの送信はコンテンツ作成ワークフローの終盤で行われ、OpenJD は TD やテクニカルアーティストがワークフローの中断を最小限に抑えるために、サブミッターワークフローをカスタマイズする機会を提供します。サブミッターのカスタマイズにより、 AWS Deadline Cloud にジョブを送信するユーザーの時間と労力を節約できます。 図 A は、Deadline Cloud に統合された Maya 2024 サブミッターを示しています。これは Maya ジョブを送信するための基本的な機能ユーザーに提供します。 図 A: Maya 2024 サブミッターに統合された Deadline Cloud カスタマイズのユースケース FuzzyPixel のカスタム Maya サブミッターは、FuzzyPixel チームによって開発されました。私たちは、AWS の機能がリリースされる前に、設計、プロトタイプ作成、テストを行うために、実際のプロダクションに取り組んでいる AWS チームです。このブログでは、最新のプロダクションで開発したカスタマイズについて説明します。 ユースケースは以下の通りです: プロジェクトパスと出力パスの更新 ：プロジェクトパスと出力パスが開いているシーンに基づいて自動的に設定されることで、ユーザーの時間を節約し、認知的負荷を軽減します。 画像解像度 ：ジョブの最終レンダリング解像度が 8K の場合があります。テストレンダリング用に解像度を下げることができれば、時間を節約しレンダリングコストを削減できます。 GUI の再構成 ：統合されたサブミッターは、4 つの異なるタブを使用して GUI コントロールを整理します。頻繁に使用するコントロールを RenderSettings タブの下に配置することで、ジョブ送信ワークフローを効率化できます。 フリートのカスタム属性 ：ユーザーがジョブをスポットインスタンスとオンデマンドインスタンスのどちらで実行するかを選択できるようになると、長時間のレンダリングでもジョブの中断を回避できます。 レンダーレイヤーコントロール ：サブミッターでレンダーレイヤーを明示的に制御できるようにすることで、レンダーレイヤーの可視性とフレーム範囲をより詳細に制御できます。 これら全てのユースケース要件を、OpenJD、AWS Deadline Cloud API、Maya API、PySide2、Python スクリプトを使用して実現しました。最初のユースケースを見ていく前に、OpenJD について詳しく見ていきましょう。 前提条件 続行する前に、以下の前提条件をすべて満たす必要があります。 Windows ワークステーション Maya 2024 と AWS Deadline Cloud Submitter のインストール Maya 2024 には独自の料金体系があり、これはAWS とは関連していないことに注意してください。 ファーム、フリート、キュー、および Deadline Cloud Monitor 、そしてファーム用に作成されたプロファイル Python-3.10.8 のインストール (Maya 2024 の Python バージョンと一致させるため、このバージョンの使用を推奨します) https://www.python.org/downloads/ このバージョンの Python に deadline と GUI の依存関係を pip でインストール 例：”C:\Program Files\Python-3.10.8\PCBuild\amd64\python.exe”  -m pip install deadline[gui] FuzzyPixel カスタム Maya サブミッター のダウンロード 注意: このブログで提供されているすべての例は、Windows ワークステーションでのみ実行できます。 ジョブバンドルで OpenJD を見る Deadline Cloud 統合サブミッターの画像 (図 A) では、右下に Export bundle ボタンがあります。ジョブバンドルとは、Deadline Cloud レンダーファームで実行されるジョブの完全な説明です。このセクションでは、前述のユースケースがどのように実現されたかを理解するための第一歩として、Maya シーンからエクスポートされたジョブバンドルを見ていきます。 ジョブバンドルのエクスポート Maya を開き、レンダーファームに送信するシーンを読み込みます。 シーンの読み込み後、サブミッターを起動します。サブミッターが正しくインストールされている場合、図 B に示すように AWS Deadline タブ (画面の右端) が表示されます。サブミッターが表示されない場合は、 Windows 、 Settings/Preferences 、そして Plug-in Manager の順に選択してください。表示されるポップアップウィンドウで Deadline と入力し、 Loaded と Auto load を選択してからウィンドウを閉じます。 図 B: Maya 2024 の AWS Deadline Cloud ツールシェルフ AWS Deadline シェルフに Deadline Cloud アイコンが表示されたら、それをクリックすると Maya 統合 サブミッターが起動します。 こちらの手順 に従ってファームにログインしてください。 図 C: Maya 2024 統合サブミッターの初期起動 サブミッターを起動したら、 Export bundle ボタンをクリックします。エクスポート後、ファイルブラウザと確認モーダルがポップアップ表示されます。ファイルブラウザには、ジョブバンドルを含む 3 つのファイルが格納されたフォルダが表示されます。 図 D: Export bundle をクリックした後の Maya 2024 統合サブミッター ジョブバンドルの説明 Maya からエクスポートされた各ジョブバンドルフォルダには、アセット参照用、パラメータ値用、エクスポートされたジョブを記述するテンプレートの 3 つのファイルが含まれています。 asset_references.yaml ファイルには、アセットパス、出力フォルダ、ジョブの参照パスが含まれています。 Service-Managed Fleet (SMF) を使用している場合、これはアセットをレンダーファームにアップロードするための手段となります。 Customer-Managed Fleet (CMF) を ストレージプロファイル と共に使用している場合、asset_references.yaml で指定されるリストは空でも構いません。 parameter_values.yaml ファイルには、ジョブテンプレートで参照する予定の値が全て含まれているので便利です。画像解像度のユースケースでは、パラメータ値の例として ImageWidth と ImageHeight があります。 template.yaml ファイルには、ジョブの説明が含まれています。asset_references.yaml と parameter_values.yaml ファイルを参照して、ジョブを完全に表現することができます。3 つのファイルすべてを使用すると便利ですが、template.yaml ファイルだけでジョブを完全に記述することも可能です。 最初のユースケースである、プロジェクトパスと出力パスの更新を実現するために、ジョブバンドルを使用して構築していきます。 ユースケース #1 – プロジェクトパスと出力パスの更新 FuzzyPixel チームは、現在開いている Maya シーンから導出した Python コードを使用して、プロジェクトパスと出力パスを設定したいと考えていました。 以下のようなアプローチを取りました： Maya クエリの実行 Maya ファイルの現在のパスを取得する方法は複数ありますが、ここでは次のように実行しました: project_path = cmds.workspace(q=True, active=True) 出力パスについては、図 G に示すように、プロジェクトパスとフォルダを連結しました: output_path = f'{project_path}/images' 次に、クエリの結果を使用して、サブミッターのプロジェクトフィールドと出力フィールドに値を設定します。 プロジェクトパスと出力パスの値が得られたら、前のセクションで説明した parameter_values.yaml ファイルにデータを挿入できます。 先ほどエクスポートした parameter_values.yaml ファイルを開き、プロジェクトパスと出力パスを参照している行を見つけます。これらの行がハイライトされたエクスポートされたバンドルは図 E で確認できます。エクスポートしたバンドルの .yaml ファイルの該当する行は次のとおりです: - name: ProjectPath value: W:/Prod2/prod/sequences/sq0300/sh0050/light - name: OutputFilePath value: W:/Prod2/prod/sequences/sq0300/sh0050/light/maya/images 図 E: エクスポートされた parameter_values.yaml ファイル Python の pyyaml パッケージを使用して、parameter_values.yaml ファイルをプログラムで更新できます。今回は手動でファイルを変更します。例えば、13 行目の project_path と、15 行目の output_path に変更します (図 E を参照)。 変更されたバンドルからジョブを送信  このセクションでは、エクスポートしたジョブバンドルに加えた変更を表示する GUI を起動します。 1. 上記の前提条件を満たしたワークステーションのコマンドシェルから、次のコマンドを入力します: deadline bundle gui-submit C:\path_to_your_exported_and_modified_bundle サブミッターの起動: 図 F: deadline バンドル gui-submit の画面 Job-specific settings タブをクリックして、変更したプロジェクトパスと出力パスを確認します。 図 G: Deadline バンドル gui-submit の Job-specific settings ユースケース #2 – 画像解像度 バンドルデータを変更して画像解像度のユースケースを実現するパターンに従うことで、時間を節約し、レンダリングコストを削減できます。すべての GUI control の Description が利用可能です。 ユースケース #3、#4、#5 – カスタムサブミッターのスクラッチ開発 タブの再編成、フリートのカスタム属性、レンダーレイヤーの制御のユースケースは、前のセクションのカスタマイズパターンから、以下の 4 つの領域で外れていました。 タブの再編成 : Deadline Cloud Maya 統合サブミッターでは、.yaml の編集によるタブの追加や削除はできません。 QTree Widget : レンダーレイヤーの表示に QTree Widget コントロールを使用したいと考えましたが、このコントロールはジョブテンプレート UI コントロールとして利用できません。 カスタムハンドラー : 統合サブミッターは、 Submit ボタンをクリックした後の template.yaml の更新をまだサポートしていません。Maya のクエリ、またはカスタムサブミッター GUI の変更、そしてユーザーが Submit ボタンをクリックした 後に  template.yaml を更新するには、カスタムハンドラーが必要です。 フリート属性の表示 : ユーザーがジョブを実行するインスタンスタイプを制御できるようにするため、ファームで ‘スポット’ と ‘オンデマンド’ のフリート属性を定義し、これらの属性をサブミッターで表示しました。 タブの再編成、QTree Widget の実装、カスタムハンドラーについては、公開されている QT のコントロールとドキュメント を活用しました。フリートの属性を表示するために AWS Deadline Cloud API を使用しました。 FuzzyPixel Maya カスタムサブミッターは、図 H に示すように、Render Settings タブの下によく使用される機能を統合することで、ユーザーのワークフローを効率化します。図 I に示すように、Render Layers タブはサブミッター内でレンダーレイヤーの可視性とフレーム範囲を直接制御できるようにすることで、サブミッターの機能を拡張します。これまでのすべてのユースケースは、スクラッチ開発された Python コードを通じて実装されており、 OpenJD スキーマ全体 を探索するための実践的な経験とコンテキストを提供します。 図 H: FuzzyPixel Maya サブミッターの Render Settings タブ 図 I: FuzzyPixel Maya サブミッターの Render Layers タブ まとめ このブログでは、Maya サブミッターのワークフローをカスタマイズするために、Python コードを手動で編集し、ジョブバンドルを変更しました。これらのカスタマイズにより、クリエイティブワークフローの中断を最小限に抑え、時間を節約し、最終的にコストを削減するというるユースケースを実現するのに役立ちました。 AWS がどのようにお客様のビジネスを加速させることができるのか、  AWS の担当者 にお問い合わせください。 参考資料 Open Job Description ドキュメント ジョブの構築方法 ジョブの実行方法 サンプル Gregory Dismond Gregory Dismond は、AWS のクリエイティブツール部門でデザインテクノロジストを務めており、35 年以上にわたる経験を持っています。その経験には、DreamWorks や EA でのパイプライン開発、telltale games でのナラティブ R&D、Wavefront Technologies でのプロダクト開発、NSF ERC での計算幾何学が含まれます。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本記事は、 Using Open Job Description to Customize Submitter Workflows を翻訳したものです。翻訳は Solutions Architect の濵野が担当しました。

はじめに こんにちは！ソリューションアーキテクトの西亀真之です。今回は、 AWS Summit Japan 2025 の1日目 (2025年6月25日) に展示予定の「生成 AI でロボットが人間の指示を理解！」というデモについて、その魅力と背景にある技術をご紹介します。このデモでは、Amazon Bedrock の生成 AI 技術を活用して、Mini Pupper という小型四足歩行ロボットを自然言語で直感的に操作する体験ができます。 図1: デモで利用する小型四足歩行ロボットのMini Pupper 「ダンスして」「前に歩いて、その後に右に曲がって」といった日常的な言葉で指示するだけで、ロボットが理解して動く様子は、まるで未来から来たかのような体験です。しかも、事前にプログラムしていない指示でも、生成 AI がうまく解釈してロボットの動きに変換してくれる柔軟性も魅力の一つです。どのような指示でも何かしようと頑張る姿は、思わず愛着が湧いてくるほど可愛らしいものです。 デモで体験できること このデモでは、以下のような体験ができます： 自然言語でのロボット操作 : 専門的な知識がなくても、日常会話のような言葉でロボットを操作できます 生成 AI による指示の解釈 : 曖昧な指示や複雑な指示も、生成AIが適切に解釈してロボットの動きに変換します 例えば、「嬉しそうに踊って」と指示すると、Mini Pupper は頭を上下に振りながら前後に動いたり、「悲しそうに歩いて」と言えば、頭を下げながらゆっくりと歩いたりします。事前にプログラムされていない行動でも、生成 AI が「嬉しい」「悲しい」といった感情表現を解釈し、適切なロボットの動きに変換してくれるのです。 背景にある技術 図2: デモのアーキテクチャ概要 このデモの裏側では、以下の AWS サービスと技術が連携して動作しています： 1.  Amazon Bedrock による自然言語処理 デモの中核となるのは、 Amazon Bedrock の大規模言語モデル（LLM）です。今回のデモでは、軽量なモデルである Claude 3.5 Haiku を利用しています。ユーザーからの自然言語の指示を受け取り、ロボットが理解できるコマンドの組み合わせに変換します。例えば「前に歩いて、その後に右に曲がって」という指示は、以下のようなコマンドに変換されます： ['move_forward:0.5:2.0', 'stop:0:0.5', 'turn_right:-1.0:1.0', 'stop:0:0.5'] 2.  Amazon Bedrock Agents によるアクション実行 Amazon Bedrock Agents は、生成 AI が作成したコマンドを受け取り、 AWS Lambda を通じて AWS IoT Core 経由でロボットにコマンドを送信します。 3.  AWS IoT Core による安全な通信 AWS IoT Core は、クラウドとロボット間の安全で信頼性の高い通信を実現します。MQTT プロトコルを使用することで、低レイテンシーでリアルタイムな制御が可能になっています。ロボットがコマンドを受信すると、そのコマンドに基づいて対応するアクションを実行します。ロボットの制御では ROS2 というロボット開発で広く使われるソフトウェアを利用しています。 図3: ユーザーの指示からロボットの制御までの流れ デモの見どころ このデモの見どころはユーザからの指示を事前に細かく設定せずとも、生成 AI が柔軟に指示を解釈し、動作を生成してくれるところになります。あらかじめ定義された基本的な動作（前進、後退、回転など）を組み合わせることで、事前に明示的にプログラムしていない複雑な行動も実現できます。生成 AI が人間の意図を理解し、適切な動作の組み合わせを考え出すことで、ロボットの可能性が大きく広がります。 例えば、「犬のように振る舞って」という指示に対して、生成 AI は「吠える」「尻尾を振る（体を揺らす）」「四つん這いで歩く」といった基本動作を組み合わせて、犬らしい振る舞いを作り出します。ブースにお越しいただいた際にはロボットに対して無茶振りをしてみてください。 AWS Summit Japan 2025 でぜひ体験を！ このデモは、 AWS Summit Japan 2025 の1日目の6月25日に ブース B-131-A  で体験いただけます。実際に自分の言葉で Mini Pupper を操作する体験は、文章や画像だけでは伝わらない感動があります。 ぜひ会場にお越しいただき、生成 AI とロボティクスの融合がもたらす新しい可能性を体感してください。皆さまのご来場をお待ちしております。 まとめ：生成 AI とロボティクスの未来 Amazon Bedrock のような生成 AI 技術とロボティクスの融合は、まだ始まったばかりです。今回のデモで示したような自然言語インターフェースは、ロボットとのコミュニケーション方法を変える可能性を秘めています。将来的には、家庭用ロボット、産業用ロボット、介護ロボットなど、様々な分野で自然言語による直感的な操作が当たり前になるかもしれません。 AWS Summit Japan 2025 のデモブースで、その未来の一端を体験してみませんか？皆さまのご来場を心よりお待ちしております。 イベント情報 イベント名 : AWS Summit Japan 2025 日程 : 2025年6月25日 (Day 1) 場所 : AWS Expo の AWS Builders’ Fair の中にあります。詳細は こちら 。 デモブース名 : 生成 AI でロボットが人間の指示を理解！ ブース番号 : B-131-A このブログ記事が、AWS Summit Japan 2025 のロボティクスデモに興味を持っていただくきっかけになれば嬉しいです。 著者紹介 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな領域は IoT とロボットです。趣味はボルダリングでオフィスにあるボルダリングウォールにトライしています。 Muhammad Fikko Fadjrimiratno（ふぃっこ） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。

AWS re:Inforce 2025 (6 月 16 日～18 日、フィラデルフィア) において、AWS の Vice President 兼 Chief Information Security Officer である Amy Herzog が基調講演を行い、新たなセキュリティイノベーションについて発表しました。イベント全体を通して、AWS は、セキュリティの大規模な簡素化と、組織がクラウドでより回復力の高いアプリケーションを構築できるようにすることに重点を置いた追加のセキュリティ機能を発表しました。今年のカンファレンスで発表された主要なセキュリティ機能のリリースとアップデートの包括的な概要を以下に示します。 新しい IAM Access Analyzer 機能を使用して、重要な AWS リソースへの内部アクセスを検証 AWS Identity and Access Management Access Analyzer の新機能は、セキュリティチームが、自動推論を使用して複数のポリシーを評価し、統合ダッシュボードを通じて検出結果を表示することで、AWS 組織内のどのプリンシパルが、S3 バケット、DynamoDB テーブル、RDS スナップショットなどの重要なリソースにアクセスできるのかを検証するのに役立ちます。 AWS IAM がすべてのアカウントタイプでルートユーザーに MFA を強制するようになりました 新しい多要素認証の強制により、パスワード関連の攻撃の 99% 超を防ぐことができます。FIDO 認定セキュリティキーなど、サポートされているさまざまな IAM MFA の方法を用いて、AWS アカウントに対するアクセスを強化できます。AWS はユーザーフレンドリーな MFA 実装のために FIDO2 パスキーをサポートしているため、ユーザーはルートユーザーと IAM ユーザーごとに最大 8 台の MFA デバイスを登録できます。 AWS Network Firewall で Amazon 脅威インテリジェンスを使用してセキュリティ体制を強化 この新しい Network Firewall マネージドルールグループは、AWS におけるワークロードに関連するアクティブな脅威に対する保護を提供します。この機能は、Amazon 脅威インテリジェンスシステムである MadPot を利用して、マルウェアホスティング URL、ボットネットのコマンド & コントロールサーバー、暗号通貨マイニングプールなどの攻撃インフラストラクチャを継続的に追跡し、アクティブな脅威についての侵害指標 (IOC) を特定します。 AWS Certificate Manager がどこでも使用できるエクスポート可能なパブリック SSL/TLS 証明書を導入 AWS Certificate Manager を利用して、安全な TLS トラフィック終端処理を必要とする AWS、ハイブリッド、またはマルチクラウドワークロードのために、エクスポート可能なパブリック証明書を発行できるようになりました。 AWS WAF の簡素化されたコンソールエクスペリエンス 新しい AWS WAF コンソールエクスペリエンスでは、事前設定済みの保護パックを通じて、セキュリティ設定のステップが最大 80% 少なくなります。セキュリティチームは、統合セキュリティメトリクスと、直感的なインターフェイスを通じたカスタマイズ可能なコントロールにより、特定のアプリケーションタイプのための包括的な保護を迅速に実装できます。 Amazon CloudFront が新しいユーザーフレンドリーなインターフェイスでウェブアプリケーションの配信とセキュリティを簡素化 Amazon CloudFront の簡素化されたコンソールエクスペリエンスをぜひお試しください。AWS WAF の強化されたルールパックと統合インターフェイスを通じて、TLS 証明書のプロビジョニング、DNS 設定、セキュリティ設定を自動化することで、わずか数クリックでウェブアプリケーションの高速化とセキュリティ保護を実現できます。 新しい AWS Shield 機能が、ネットワークセキュリティの問題が悪用される前に検出 (プレビュー) Shield のネットワークセキュリティ体制管理は、AWS アカウント全体でネットワークリソースを自動的に検出および分析し、AWS のベストプラクティスに基づいてセキュリティリスクの優先順位付けを行い、SQL インジェクションや DDoS 攻撃などの脅威からアプリケーションを保護するための是正に関する実用的なレコメンデーションを提供します。 新しい AWS Security Hub を利用してセキュリティを統合し、リスクの優先順位付けと対応を大規模に実現 (プレビュー) AWS Security Hub は、セキュリティシグナルを実用的なインサイトに変換できるように強化されています。これは、セキュリティチームが重要度の高い問題を大規模に優先順位付けして対応するのに役立ちます。この統合ソリューションは、クラウド環境全体の包括的な可視性を提供するとともに、複数のセキュリティツールの管理に伴う複雑さを軽減します。 Amazon GuardDuty が Extended Threat Detection の対象範囲を Amazon EKS クラスターに拡張 Amazon GuardDuty Extended Threat Detection が Amazon EKS クラスターをサポートするようになりました。これは、Kubernetes 監査ログ、実行時の動作、AWS API アクティビティにおけるセキュリティシグナルを相関させることで、高度な多段階攻撃を検出するのに役立ちます。この機能強化により、この機能がなければ見逃される可能性のある重大度の高い攻撃シーケンスが自動的に特定され、脅威への迅速な対応が可能になります。 AWS MSSP コンピテンシーの新しいカテゴリ AWS MSSP コンピテンシー (旧称: AWS レベル 1 MSSP コンピテンシー) に、インフラストラクチャセキュリティ、ワークロードセキュリティ、アプリケーションセキュリティ、データ保護、ID およびアクセス管理、インシデント対応、サイバーリカバリをカバーする新しいカテゴリが追加されました。パートナーは、専用のセキュリティオペレーションセンターを通じて 24 時間年中無休のモニタリングとインシデント対応を提供します。 Amazon Verified Permissions を利用して Express アプリケーション API を数分で保護 Amazon Verified Permissions は、デベロッパーが Amazon Verified Permissions を利用して Express ウェブアプリケーション API の認可を数分で実装できるようにするオープンソースパッケージである verified-permissions-express-toolkit のリリースを発表しました。 コンピューティングを超えて: Amazon Inspector のコードセキュリティで脆弱性検出をシフトレフト Amazon Inspector のコードセキュリティ機能の一般提供が開始されました。これは、アプリケーションのソースコード、依存関係、Infrastructure as Code (IaC) 全体でセキュリティ上の脆弱性と設定ミスを迅速に特定し、優先順位を付けることで、本番導入前にアプリケーションのセキュリティを実現するのに役立ちます。 AWS Backup が論理エアギャップボールトのためにマルチパーティー承認機能を追加 AWS Backup の論理エアギャップボールトのためのマルチパーティー承認機能により、AWS アカウントが侵害された場合でも、リカバリアカウントとのボールト共有を有効にできる、信頼された個人で構成される指定承認チームからの認可を活用することで、バックアップデータをリカバリできます。 原文は こちら です。

6 月 17 日、AWS re:Invent 2024 での発表「 Amazon GuardDuty Extended Threat Detection: クラウドセキュリティの強化のための AI/ML 攻撃シーケンスの特定 」でご紹介した機能を基に、対象範囲を Amazon Elastic Kubernetes Service (Amazon EKS) に拡張した Amazon GuardDuty Extended Threat Detection を発表しました。 Kubernetes ワークロードを管理するセキュリティチームは、コンテナ化されたアプリケーションを標的とする高度な多段階攻撃の検出に苦労することがよくあります。これらの攻撃には、コンテナの悪用、権限昇格、Amazon EKS クラスター内での不正な移動が含まれる場合があります。従来のモニタリングアプローチでは、個々の疑わしいイベントは検出できたとしても、さまざまなデータソースや期間にまたがる、より広範な攻撃パターンを見逃してしまうことがよくあります。 GuardDuty Extended Threat Detection では、Amazon EKS 監査ログ、EKS クラスターに関連付けられたプロセスの実行時の動作、EKS クラスターでのマルウェア実行、AWS API アクティビティにおけるセキュリティシグナルを自動的に相関させ、この機能を使用しなければ見過ごされる可能性のある高度な攻撃パターンを特定する、重大度の高い検出結果タイプが新たに導入されています。例えば、GuardDuty は、脅威アクターがコンテナアプリケーションを悪用し、特権サービスアカウントトークンを取得して、これらの昇格された権限を使用して機密性の高い Kubernetes シークレットまたは AWS リソースにアクセスする攻撃シーケンスを検出できるようになりました。 この新しい機能は、GuardDuty 相関アルゴリズムを使用して、潜在的な侵害を示唆するアクションシーケンスを監視および特定します。 保護プラン や他のシグナルソース全体で検出結果を評価して、一般的な攻撃パターンや新たな攻撃パターンを特定します。検出された攻撃シーケンスごとに、GuardDuty は、影響を受ける可能性のあるリソース、イベントのタイムライン、関与するアクター、シーケンスの検出に使用されたインジケーターなど、包括的な詳細を提供します。また、検出結果は、検知されたアクティビティを、MITRE ATT&CK® の戦術と手法、および AWS ベストプラクティスに基づく是正に関するレコメンデーションにマッピングします。これは、セキュリティチームが脅威の性質を理解するのに役立ちます。 EKS のために Extended Threat Detection を有効にするには、 EKS Protection または Runtime Monitoring のうち、少なくとも 1 つの機能を有効にする必要があります。検出カバレッジを最大化するために、両方を有効にして検出機能を強化することをお勧めします。EKS Protection は監査ログを通じてコントロールプレーンのアクティビティをモニタリングし、Runtime Monitoring はコンテナ内の動作を監視します。これらを組み合わせることで、EKS クラスターの完全なビューが作成され、GuardDuty は複雑な攻撃パターンを検出できるようになります。 仕組み EKS クラスターのために新しい Amazon GuardDuty Extended Threat Detection を利用するには、 GuardDuty コンソール に移動して、アカウントで EKS Protection を有効にします。右上のリージョンセレクターから、EKS Protection を有効にするリージョンを選択します。ナビゲーションペインで、 [EKS Protection] を選択します。 [EKS Protection] ページで、現在のステータスを確認し、 [有効にする] を選択します。 [確認] を選択して選択内容を保存します。 有効になると、GuardDuty は追加の設定を必要とせずに、EKS クラスターからの EKS 監査ログのモニタリングを直ちに開始します。GuardDuty は、独立したストリームを通じて、EKS コントロールプレーンから直接、これらの監査ログを使用します。これは、既存のログ記録設定には影響しません。 マルチアカウント環境の場合 、委任された GuardDuty 管理者アカウントのみが、メンバーアカウントのために EKS Protection を有効または無効にしたり、組織に参加する新しいアカウントのために自動有効化設定を構成したりできます。 Runtime Monitoring を有効にするには、ナビゲーションペインで [Runtime Monitoring] を選択します。 [設定] タブで [有効にする] を選択して、アカウントのために Runtime Monitoring を有効にします。 これで、 [概要] ダッシュボードから、Kubernetes クラスターの侵害に特に関連する攻撃シーケンスと重要度の高い検出結果を表示できます。GuardDuty が、認証情報の侵害イベントや EKS クラスター内の疑わしいアクティビティなど、Kubernetes 環境における複雑な攻撃パターンを特定していることを確認できます。重大度、リソースへの影響、攻撃タイプ別に検出結果が視覚的に表されるため、Amazon EKS のセキュリティ体制を全体的に把握できます。これにより、コンテナ化されたワークロードに対する極めて重要な脅威を優先できます。 [検出結果の 詳細] ページでは、EKS クラスターを標的とする複雑な攻撃シーケンスが可視化されるため、潜在的な侵害の全容を把握するのに役立ちます。GuardDuty は、シグナルをタイムラインに相関させ、検知された動作を、MITRE ATT&CK® の戦術や手法 (アカウント操作、リソースハイジャック、権限昇格など) にマッピングします。このきめ細かなインサイトにより、攻撃者が Amazon EKS 環境をどのように侵害しているのかが正確に明らかになります。EKS ワークロードやサービスアカウントなどの影響を受けるリソースを特定します。インジケーター、アクター、エンドポイントの詳細な内訳により、攻撃パターンを理解し、影響を判断して、是正作業の優先順位を決定するための実用的なコンテキストが提供されます。これらのセキュリティインサイトを統合ビューにまとめることで、Amazon EKS セキュリティインシデントの重大度を迅速に評価し、調査時間を短縮して、コンテナ化されたアプリケーションを保護するための的を絞った対策を実施できます。 [検出結果の詳細] ページの [リソース] セクションには、攻撃シーケンス中に影響を受けた特定のアセットに関するコンテキストが表示されます。この統合リソースリストにより、最初のアクセスから標的の Kubernetes コンポーネントに至るまで、侵害の正確な範囲を可視化できます。GuardDuty には、リソースタイプ、識別子、作成日、名前空間の情報などの詳細な属性が含まれているため、コンテナ化されたインフラストラクチャのどのコンポーネントで即時の対応が必要かを迅速に評価できます。この集中的なアプローチにより、インシデント対応中の推測作業が排除されるため、影響を受ける極めて重要なリソースの是正作業を優先し、Amazon EKS を標的とした攻撃の潜在的な影響範囲を最小限に抑えることができます。 今すぐご利用いただけます 対象範囲を Amazon EKS クラスターに拡大した Amazon GuardDuty Extended Threat Detection は、Kubernetes 環境全体にわたる包括的なセキュリティモニタリングを提供します。この機能を使用すると、さまざまなデータソース間でイベントを相関させ、従来のモニタリングでは見逃される可能性のある攻撃シーケンスを特定することで、高度な多段階攻撃を検出できます。 この拡張カバレッジの使用を開始するには、GuardDuty の設定で EKS Protection を有効にし、検出機能を強化するために Runtime Monitoring を追加することを検討してください。 この新機能の詳細については、 Amazon GuardDuty のドキュメントをご覧ください。 – Esra 原文は こちら です。

本稿は、2025 年 6 月 17 日に AWS Storage Blog で公開された “ Protect on-premises VMware infrastructure with NetApp BlueXP Disaster Recovery, Amazon Elastic VMware Service, and Amazon FSx for NetApp ONTAP ” を翻訳したものです。 VMware ワークロードには、ビジネス上の意思決定や運用の原動力となる重要なデータが含まれています。ランサムウェアの脅威、壊滅的なハードウェア障害、自然災害などの潜在的な災害が、多大なコストを伴うダウンタイムやデータ損失につながる可能性があるため、データの可用性と耐障害性の維持は最優先事項です。こうした課題に対処するには、あらゆる企業にとって効果的なディザスタリカバリ (DR) 戦略を策定するための戦略的計画と信頼できるソリューションが必要不可欠です。 NetApp BlueXP Disaster Recovery は、Amazon Elastic VMware Service ( Amazon EVS ) と Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を使用してクラウドと統合することで、オンプレミスの VMware ワークロードをシームレスに保護する方法を提供します。 この統合ソリューションにより、組織には次のようなメリットがあります。 短縮された目標復旧時間 (RTO) と目標復旧時点 (RPO) の達成 Amazon Web Services (AWS) の従量課金制モデルを活用した費用対効果の高い DR ソリューション 既存の VMware ツールやプロセスとのシームレスな統合 本番環境の VM の中断を伴わないフェイルオーバーのテスト 本稿では、これらのテクノロジーがどのように連携して、事業継続性の重要なニーズに対応する包括的な DR ソリューションを提供するのかを探ります。 1. Amazon EVS をフェイルオーバーサイトとして設定する方法、2. Amazon EVS の vCenter を新しいサイトに追加する方法、3. レプリケーションプランの作成、4. テストフェイルオーバーの実行の 4 つのステップで構成と実装について説明します。 ソリューション概要 NetApp BlueXP Disaster Recovery NetApp BlueXP Disaster Recovery は、VMware 環境に堅牢なデータ保護とリカバリを提供するように設計された DRaaS (Disaster Recovery as a Service) ソリューションです。 BlueXP クラウドベースの管理フレームワークの不可欠な部分として、このサービスは既存の BlueXP マネージド NetApp ONTAP ストレージインフラストラクチャと自動的に統合されます。Amazon EVS と FSx for ONTAP を活用することで、企業は重要な仮想マシン (VM) をデータ損失から保護し、ダウンタイム時に迅速に復旧できます。ソリューションアーキテクチャを 図 1 に示します。 図 1: BlueXP Disaster Recovery の概要 BlueXP Disaster Recovery の主な価値は次のとおりです。 シームレスな統合 : オンプレミスの VMware 環境と AWS のサービスを簡単に統合できます。 VM の自動フェイルオーバー : 最小限のダウンタイムで AWS のワークロードを迅速に復旧できます。 管理の簡素化 : オンプレミス環境と Amazon EVS 環境の両方を単一のインターフェイスから管理できます。 コスト最適化 : 使用した AWS リソースに対してのみお支払いいただきます。 スケーラビリティ : 変化するビジネスニーズに合わせて DR 環境を迅速に拡張できます。 Amazon Elastic VMware Service (Amazon EVS) Amazon EVS は、プラットフォームの変更や再構築を必要とせずに、使い慣れた VMware Cloud Foundation (VCF) ソフトウェアとツールに AWS のスケール、回復力、パフォーマンスを連携させることができます。 Amazon EVS の主な価値は次のとおりです。 スピードとシンプルさ : 移行の煩わしさを解消し、運用の一貫性を維持します。 IP アドレスの変更、スタッフの再トレーニング、運用手順書の書き換えをすることなく、オンプレミスネットワークを拡張し、ワークロードを移行できます。 制御とカスタマイズ : クラウド内の VMware アーキテクチャを完全に制御して、アドオンやサードパーティソリューションなど、アプリケーション固有の要求を満たす仮想化スタックを設計および最適化できます。ワークロードだけでなく、仮想化環境もリフト＆シフトできます。 使い慣れたツールを活用して、ストレージ、バックアップ、ディザスタリカバリのニーズに対応できます。 管理方法の選択 : セルフマネージドで運用するか、AWS パートナーの専門知識を活用して AWS 上の VCF 環境を構築、管理、運用し、人材、時間、コストにわたるビジネス目標を達成することを選択できます。 AWS サービスへのアクセス : ワークロードをクラウドに確実に移行し、信頼性、耐障害性、セキュリティ、スケーラビリティの向上によるメリットを享受できます。Amazon EVS は、200 を超えるサービスを通じて VMware 環境の拡張と拡大を簡素化します。 FSx for ONTAP によるサポート : 外部データストアと VM 接続ストレージの両方で、FSx for ONTAP は柔軟性を高め、コストを削減し、データ保護、高可用性を実現するコンピューティングから切り離された伸縮自在なストレージなど、さまざまなエンタープライズグレードのメリットをもたらします。 Amazon FSx for NetApp ONTAP Amazon FSx for ONTAP は、NetApp の ONTAP ストレージソフトウェアの機能をネイティブサービスとして AWS にもたらすフルマネージドストレージサービスです。 Amazon EVS での使用が検証されており、高度なデータ管理機能を備えた VMware 環境のストレージ基盤を提供します。これには ONTAP API、スナップショットベースのデータ保護、SnapMirror レプリケーションが含まれます。 FSx for ONTAP の主な価値は次のとおりです。 ハイパフォーマンス : 低レイテンシで高いパフォーマンスを実現し、要求の厳しいアプリケーションやワークロードに適しています。 コスト最適化 : 重複排除や圧縮などのストレージ効率化機能を提供して、ストレージコストを削減します。 データ保護 : ONTAP スナップショットと SnapMirror レプリケーションをサポートします。 スケーラビリティ : パフォーマンスを犠牲にすることなく、増大するデータニーズに合わせて迅速に拡張できます。 使い慣れた ONTAP エクスペリエンス : オンプレミスの NetApp ONTAP と同等のユーザーエクスペリエンスを提供します。 構成と実装 Amazon EVS と FSx for ONTAP を使用した BlueXP Disaster Recovery のセットアップは簡単です。以下に 4 つの概要を示します。 ステップ 1: Amazon EVS をフェイルオーバーサイトとして設定する BlueXP Disaster Recovery を使用して Amazon EVS の vCenter でサイトをセットアップする場合は、 Location ドロップダウンメニューから AWS-EVS を選択します。 (図 2) 図 2: BlueXP Disaster Recovery での Amazon EVS サイトの作成 ステップ 2: Amazon EVS の vCenter を新しいサイトに追加する サイトが作成されたら、既存の FSx for ONTAP ベースの Amazon EVS の vCenter を追加できます。vCenter の管理 IP アドレスまたは完全修飾ドメイン名 (FQDN)、正しい TCP ポート、および DRaaS で vCenter を管理するために必要な権限を含むログイン認証情報を入力します (図 3) 。 この情報は、不正アクセスを防ぐために、お客様の Amazon Virtual Private Cloud ( Amazon VPC ) 内の BlueXP コネクタに保存されます。 図 3: Amazon EVS の vCenter クラスターをサイトに追加する ステップ 3: レプリケーションプランを作成する BlueXP Disaster Recovery コンソールの Replication plans セクションに移動し、 レプリケーションプラン を追加します。新しく作成したサイトを “Failover site” として使用します。 (図 4) 図 4: Amazon EVS を Failover site として使用するレプリケーションプラン ステップ 4: テストフェイルオーバーを実行する データレプリケーションが完了したら、VMware DR プランを簡単に有効化できます。 レプリケーションプラン を選択し、 ドロップダウンメニュー から Failover をクリックします。 確認ポップアップに Failover と入力し、 Failover ボタン をクリックして確定します。 (図 5) 図 5: Amazon EVS と FSx for ONTAP を使用したフェイルオーバーの実行 フェイルオーバープロセスが期待通りに動作することを確認するために、定期的にテストを行うことが重要です。BlueXP Disaster Recovery のユニークな機能の 1 つは、稼働中の本番 VM とその保護を中断することなく、テストフェイルオーバーを実行できることです。 テストフェイルオーバーを実行するには、 ドロップダウンメニュー から “Fail over” の代わりに Test failover メニューオプションを選択します。 このプロセスは、実際のフェイルオーバーとは 3 つの点で異なります。 オンプレミスで実行されている本番環境の VM は停止しません。 レプリケーションプランで保護されているデータストアのレプリケーションは停止されません。 FSx for ONTAP クラスタで保護されている各データストアのクローンを作成し、その情報を使用して Amazon EVS の vCenter に VM を登録して起動します。 利用を開始する NetApp の既存のお客様は、追加費用なしで Lab On Demand にアクセスできるため、既存のインフラストラクチャにサービスをインストールすることなく、BlueXP Disaster Recovery の機能を試すことができます。FSx for ONTAP を初めて使用する場合は、 AWS Marketplace で NetApp BlueXP のリストにアクセスしてサブスクライブしてください。いくつかの手順を実行して導入すると、BlueXP コンソールから BlueXP Disaster Recovery の 30 日間の容量無制限トライアルにアクセスできるようになります。追加コストは発生しません。トライアルが終了したら、レプリケーションプランとサイトを削除するだけで、すべての変更を元に戻すことができます。 結論 データの可用性が収益に直接影響する今日のビジネス環境において、堅牢なディザスタリカバリソリューションを持つことは単なる IT イニシアチブではなく、ビジネス要件です。 BlueXP Disaster Recovery を Amazon EVS および Amazon FSx for NetApp ONTAP と組み合わせると、オンプレミスの VMware ワークロード向けの強力で柔軟なデータ保護およびディザスタリカバリソリューションが実現します。この統合ソリューションでは、シームレスな AWS 統合、スケーラブルなディザスタリカバリ、AWS での従量課金制モデルによるコスト効率の向上、使い慣れた VMware ツールとインターフェイスによる管理の効率化が実現します。このソリューションを導入することで、企業は不測の災害に直面しても、重要なアプリケーションが引き続き利用可能で保護されていることを確認できます。 このブログでは、これらのテクノロジーがどのように連携して、事業継続性の重要なニーズに対応する包括的な DR ソリューションを実現するかを説明しました。1. Amazon EVS をフェイルオーバーサイトとして設定する方法、2. Amazon EVS の vCenter を新しいサイトに追加する方法、3. レプリケーションプランの作成、4. テストフェイルオーバーの実行の 4 つのステップで構成と実装について説明しました。 より多くの AWS パートナー ソリューションについて調べるか、 AWS の担当者 にお問い合わせいただき、お客様のビジネスの加速をどのように支援できるかをご相談ください。 さらに詳しく Amazon Elastic VMware Service (Amazon EVS) のパブリックプレビュー開始のお知らせ Amazon Elastic VMware Service が Amazon FSx for NetApp ONTAP と統合 Amazon FSx for NetApp ONTAP の開始方法 AWS における VMware ワークロードの次なる展開は？ BlueXP Disaster Recovery と Amazon EVS — ビデオ NetApp BlueXP Disaster Recovery の概要 NetApp BlueXP Disaster Recovery 導入ガイド   Eric Yuen Eric Yuen は AWS のシニアパートナーソリューションアーキテクトです。 ソリューションを構築する AWS ストレージパートナーと緊密に連携し、お客様が AWS でストレージ環境を設計できるよう支援しています。 Eric は、さまざまなストレージおよびデータ保護テクノロジーに関わってきた 20 年の業界経験があります。 Tony Ansley Tony Ansley は NetApp のシニアテクニカルマーケティングエンジニアで、NetApp ONTAP ストレージソリューションのデータ保護機能とサービスを担当しています。 Tony は、エンタープライズクライアントとデータセンターのテクノロジーに関する 35 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当し、監修はネットアップ合同会社の藤原様に協力頂きました。原文は こちら です。

AWS Security Hub は、Amazon Web Services (AWS) アカウント全体のセキュリティアラートとコンプライアンスステータスを表示し、集計するための中心的な場所となっています。6 月 17 日、相関関係、コンテキスト化、可視化機能が追加された新しい AWS Security Hub のプレビューリリースを発表します。これにより、重大なセキュリティ問題の優先順位付け、大規模な対応によるリスクの軽減、チームの生産性の向上、クラウド環境の保護強化ができるようになります。 新しい AWS Security Hub を簡単に紹介します。 この新しい機能強化により、AWS Security Hub は Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub クラウドセキュリティ体制管理 (CSPM) 、 Amazon Macie 、その他の AWS セキュリティ機能を統合し、統合クラウドセキュリティソリューションでの一元管理を通じてクラウド環境全体を可視化できるようにします。 新しい AWS Security Hub の使用を開始する AWS Security Hub の使用を開始する方法を順を追って説明します。 AWS Security Hub を初めてご利用になる場合は、AWS Security Hub コンソールに移動して AWS のセキュリティ機能と諸機能を有効にし、組織全体のリスク評価を開始する必要があります。 ドキュメントのページ をご覧ください。 AWS Security Hub を有効にすると、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM など、有効にしたサポートセキュリティ機能のデータが自動的に使用されます。AWS Security Hub コンソールに移動してこれらの検出結果を確認し、これらの機能にわたる検出結果の相関関係から得られるインサイトを活用できます。 セキュリティリスクが発見されると、再設計された Security Hub 概要ダッシュボードに表示されます。新しい Security Hub 概要ダッシュボードでは、AWS のセキュリティ体制を包括的かつ統一的に把握できます。ダッシュボードでは、セキュリティの検出結果が明確なカテゴリに整理されるため、リスクの特定と優先順位付けが容易になります。 新しい エクスポージャーサマリー ウィジェットは、Amazon Inspector、AWS Security Hub CSPM、Amazon Macie からのリソース関係とシグナルを分析することで、エクスポージャー (セキュリティの脆弱性) を特定して優先順位を付けるのに役立ちます。これらのリスク検出結果は自動的に生成され、新しいソリューションの重要な部分となり、重要なエクスポージャーがどこにあるかが明らかになります。エクスポージャーについての詳細は、 ドキュメントのページをご覧ください 。 AWS Security Hub には、潜在的なカバレッジギャップを特定するのに役立つ セキュリティカバレッジ ウィジェットが提供されるようになりました。このウィジェットを使用すると、Security Hub のセキュリティ機能でカバーされていない箇所を特定できます。この可視性により、セキュリティカバレッジを向上させるために必要な機能、アカウント、機能を特定できます。 ナビゲーションメニューでわかるように、AWS Security Hub はセキュリティ管理を効率化するために 5 つの主要領域に分かれています。 エクスポージャー : Security Hub によって発生した、AWS リソースやシステムを不正アクセスや侵害にさらす可能性のある、セキュリティ上の脆弱性や設定ミスなど、すべてのエクスポージャー検出結果が可視化され、環境外からアクセスできる可能性のあるリソースを特定しやすくなります 脅威 : Amazon GuardDuty によって生成されたすべての脅威検出結果を統合し、潜在的な悪質なアクティビティや侵入の試みを表示します 脆弱性 : Amazon Inspector によって検出されたすべての脆弱性が表示され、ソフトウェアの欠陥と設定の問題が強調表示されます 体制管理 : AWS Security Hub クラウドセキュリティ体制管理 (CSPM) から得られたすべての体制管理検出結果を表示し、セキュリティのベストプラクティスに準拠できるようにします 機密データ : Amazon Macie が特定したすべての機密データ検出結果を表示し、機密情報の追跡と保護に役立ちます エクスポージャー ページに移動すると、タイトル別にグループ化された検出結果が表示され、重大度レベルが明確に示されるため、最初に重大な問題に集中できます。 特定のエクスポージャーを調べるには、任意の検出結果を選択すると、影響を受けたリソースが確認できます。パネルには、関係するリソース、アカウント、リージョン、および問題が検出された日時に関する重要な情報が表示されます。 このパネルには、複雑なセキュリティ関係を理解するのに特に役立つ攻撃パスも可視化されて表示されます。ネットワークエクスポージャーパスについては、仮想プライベートクラウド (VPC)、サブネット、セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、ロードバランサーなど、パスに含まれるすべてのコンポーネントを確認できるため、セキュリティコントロールを実装する場所を正確に特定するのに役立ちます。また、この可視化では Identity and Access Management (IAM) の関係も強調表示され、アクセス許可の設定によって権限昇格やデータアクセスがどのように可能になるかがわかります。複数の特性を持つリソースには明確なマークが付けられているため、どのコンポーネントが最もリスクが高いかをすばやく特定できます。 脅威ダッシュボード には、Amazon GuardDuty によって検出された潜在的な悪意のあるアクティビティに関する実用的なインサイトが表示され、検出結果が重大度別に整理されるため、異常な API コール、疑わしいネットワークトラフィック、潜在的な認証情報の侵害などの重大な問題をすばやく特定できます。ダッシュボードには、 GuardDuty 拡張脅威検出 の検出結果が表示され、すべての「重大」な重大度の脅威は、早急な対応を必要とするこれらの拡張脅威検出を表します。 同様に、Amazon Inspector の 脆弱性ダッシュボード では、ソフトウェアの脆弱性とネットワーク露出リスクを包括的に把握できます。ダッシュボードには、悪用が判明している脆弱性、緊急の更新が必要なパッケージ、脆弱性の数が最も多いリソースが表示されます。 もう 1 つの貴重な新機能は、AWS Security Hub の対象となる組織内にデプロイされたすべてのリソースのインベントリを提供する リソースビュー です。このビューを使用すると、どのリソースに不利な検出結果があるかをすばやく特定し、リソースタイプまたは検出結果の重大度でフィルタリングできます。任意のリソースを選択すると、他のコンソールに切り替えなくても詳細な設定情報が得られるため、調査ワークフローが効率化されます。 新しいセキュリティハブには、クラウド環境を包括的に監視し、サードパーティのセキュリティソリューションに接続するのに役立つ統合機能も用意されています。これにより、組織固有のニーズに合わせた統合セキュリティソリューションを柔軟に作成できます。 例えば、統合機能を使用すると、セキュリティ検出結果を表示するときに、「 チケットの作成 」オプションを選択して、希望するチケット統合を選択できます。 その他の情報 いくつかの留意点を次に示します: 利用可能なリージョン – このプレビュー期間中、新しい AWS Security Hub は、次の AWS リージョンでご利用いただけます。米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港、ジャカルタ、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、中東 (バーレーン)、南米 (サンパウロ) 。 価格 — 新しい AWS Security Hub は、プレビュー期間中は追加料金なしでご利用いただけます。ただし、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM などの統合機能のコストは引き続き発生します。 既存の AWS セキュリティ機能との統合 — Security Hub は Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、および Amazon Macie と統合されているため、運用上のオーバーヘッドを増やすことなく包括的なセキュリティ体制を実現できます。 データ相互運用性の強化 — 新しい Security Hub は オープンサイバーセキュリティスキーマフレームワーク (OCSF) を使用しており、標準化されたデータ形式でセキュリティ機能全体でシームレスなデータ交換を可能にします。 強化された AWS Security Hub の詳細とプレビューへの参加については、 AWS Security Hub 製品ページをご覧ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

マルチチャネル文字起こしストリーミングは、 Amazon Transcribe の機能の一つで、多くの場合ウェブブラウザで利用できます。このストリームソースの作成にはいくつかの制約がありますが、 JavaScript Web Audio API を使用すると、動画、音声ファイル、マイクなどのハードウェアなど、さまざまなオーディオソースを接続して組み合わせ、文字起こしを作成できます。 この記事では、2 つのマイクをオーディオソースとして使用し、それらを 1 つのデュアルチャネルオーディオに結合し、必要なエンコードを実行して Amazon Transcribe にストリーミングする方法を説明します。ブラウザに 2 つのマイクを接続する際に必要とする Vue.js アプリケーションのソースコードも提供されています。ただし、このアプローチの汎用性はこのユースケースにとどまらず、さまざまなデバイスやオーディオソースに対応するように調整できます。 このアプローチでは、1 回の Amazon Transcribe セッションで 2 つのソースの文字起こしを取得できるため、ソースごとに個別のセッションを使用する場合と比較して、コスト削減などのメリットが得られます。 2つのマイクを使用する際の課題 今回のユースケースでは、2 つのマイクでシングルチャネルのストリームを使用し、 Amazon Transcribe のスピーカーラベル識別機能 を有効にしてスピーカーを識別すれば十分かもしれませんが、いくつか考慮すべき点があります。 スピーカーラベルはセッション開始時にランダムに割り当てられるため、ストリーム開始後にアプリケーションで結果をマッピングする必要があります。 似たような声色を持つスピーカーが誤ってラベル付けされる可能性があり、人間でさえ区別が困難です。 2 人のスピーカーが 1 つのオーディオソースで同時に話すと、音声が重なり合う可能性があります。 マイクで 2 つのオーディオソースを使用し、各トランスクリプトが固定の入力ソースから取得することで、これらの懸念に対処できます。スピーカーにデバイスを割り当てることで、アプリケーションはどのトランスクリプトを使用するかを事前に認識できます。ただし、近くにある 2 つのマイクが複数の音声を拾っている場合、音声が重なり合う可能性があります。これは、指向性マイク、音量管理、Amazon Transcribe の単語レベルの 信頼度スコア を使用することで軽減できます。 ソリューションの概要 次の図はソリューションのワークフローを示しています。 2つのマイクのアプリケーション図 Web Audio API では、2つのオーディオ入力を使用します。この API を使うと、マイク A とマイク B の2つの入力を1つのオーディオデータソースに統合できます。左チャンネルがマイク A、右チャンネルがマイク B を表します。 次に、このオーディオソースを PCM (パルス符号変調) オーディオに変換します。PCM はオーディオ処理で一般的なフォーマットであり、Amazon Transcribe がオーディオ入力に必要とするフォーマットの1つです。最後に、PCM オーディオを Amazon Transcribe にストリーミングして文字起こしを行います。 前提条件 以下の環境を事前に用意することが必要です。 GitHub リポジトリ からのソースコード。 Bun または  Node.js が JavaScript ランタイムとしてインストールされていること。 Web Audio API と互換性のあるウェブブラウザ。このソリューションは、Google Chrome バージョン 135.0.7049.85 で動作することがテストされています。 2 つのマイクがコンピュータに接続され、ブラウザからこれらのマイクに アクセスできること 。 Amazon Transcribe の権限を持つ AWS アカウント。例として、Amazon Transcribe には次の AWS Identity and Access Management ポリシーを使用できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DemoWebAudioAmazonTranscribe", "Effect": "Allow", "Action": "transcribe:StartStreamTranscriptionWebSocket", "Resource": "*" } ] } アプリケーションを起動する アプリケーションを起動するには、以下の手順を実行してください。 コードをダウンロードしたルートディレクトリに移動します。 env.sample ファイルから AWS アクセスキーを設定するための .env ファイルを作成します。 パッケージをインストールし、 bun install を実行します（Node.js を使用している場合は node install を実行します）。 Web サーバーを起動し、 bun dev を実行します（Node.js を使用している場合は node dev を実行します）。 ブラウザで http://localhost:5173/ を開きます。. 2つのマイクを接続して http://localhost:5173 で実行されているアプリケーション コードの説明 このセクションでは、実装のための重要なコード部分を解説します。 最初のステップは、ブラウザ API navigator.mediaDevices.enumerateDevices() を使用して、接続されているマイクの一覧を取得することです。 const devices = await navigator.mediaDevices.enumerateDevices(); return devices.filter((d) => d.kind === 'audioinput'); 次に、接続されているマイクごとにMediaStreamオブジェクトを取得する必要があります。これは、ユーザーのメディアデバイス（カメラやマイクなど）へのアクセスを可能にする navigator.mediaDevices.getUserMedia() APIを使用して実行できます。その後、これらのデバイスからの音声または動画データを表すMediaStreamオブジェクトを取得できます。 const streams = [] const stream = await navigator.mediaDevices.getUserMedia({ audio: { deviceId: device.deviceId, echoCancellation: true, noiseSuppression: true, autoGainControl: true, }, }) if (stream) streams.push(stream) 複数のマイクからの音声を結合するには、音声処理用の AudioContextインターフェース を作成する必要があります。この AudioContext 内で、 ChannelMergerNode を使用して、異なるマイクからの音声ストリームを結合できます。 connect(destination, src_idx, ch_idx) メソッドの引数は次のとおりです。 destination – 出力先。この例では mergerNode です。 src_idx – ソースチャンネルのインデックス。この例では両方とも0です（各マイクがシングルチャンネルの音声ストリームであるため）。 ch_idx – 出力先のチャンネルインデックス。この例ではそれぞれ0と1で、ステレオ出力を作成します。 // audioContextのインスタンス const audioContext = new AudioContext({ sampleRate: SAMPLE_RATE, }) // マイクのストリームデータを処理するために使用 const audioWorkletNode = new AudioWorkletNode(audioContext, 'recording-processor', {...}) // microphone A const audioSourceA = audioContext.createMediaStreamSource(mediaStreams[0]); // microphone B const audioSourceB = audioContext.createMediaStreamSource(mediaStreams[1]); // 2つの入力用のオーディオノード const mergerNode = audioContext.createChannelMerger(2); // オーディオ ソースを mergerNode の宛先に接続。 audioSourceA.connect(mergerNode, 0, 0); audioSourceB.connect(mergerNode, 0, 1); // mergerNodeをAudioWorkletNodeに接続 merger.connect(audioWorkletNode); そのマイクデータは AudioWorklet tで処理され、指定された録音フレーム数ごとにデータメッセージが送信されます。これらのメッセージには、Amazon Transcribeに送信するPCM形式でエンコードされた音声データが含まれます。 p-event ライブラリを使用すると、Workletからのイベントを非同期的に反復処理できます。このWorkletの詳細については、この記事の次のセクションで説明します。 import { pEventIterator } from 'p-event' ... // ワークレットを登録する try { await audioContext.audioWorklet.addModule('./worklets/recording-processor.js') } catch (e) { console.error('Failed to load audio worklet') } // 非同期イテレータ const audioDataIterator = pEventIterator<'message', MessageEvent<AudioWorkletMessageDataType>>( audioWorkletNode.port, 'message', ) ... // AsyncIterableIterator: ワークレットが `SHARE_RECORDING_BUFFER` メッセージを含むイベントを発行するたびに、このイテレータは必要な AudioEvent オブジェクトを返す。 const getAudioStream = async function* ( audioDataIterator: AsyncIterableIterator<MessageEvent<AudioWorkletMessageDataType>>, ) { for await (const chunk of audioDataIterator) { if (chunk.data.message === 'SHARE_RECORDING_BUFFER') { const { audioData } = chunk.data yield { AudioEvent: { AudioChunk: audioData, }, } } } } Amazon Transcribeへのデータのストリーミングを開始するには、作成したイテレータを使用し、 NumberOfChannels: 2 と EnableChannelIdentification: true を有効にしてデュアルチャネルの文字起こしを有効にします。詳細については、 AWS SDK StartStreamTranscriptionCommand のドキュメントをご覧ください。 import { LanguageCode, MediaEncoding, StartStreamTranscriptionCommand, } from '@aws-sdk/client-transcribe-streaming' const command = new StartStreamTranscriptionCommand({ LanguageCode: LanguageCode.EN_US, MediaEncoding: MediaEncoding.PCM, MediaSampleRateHertz: SAMPLE_RATE, NumberOfChannels: 2, EnableChannelIdentification: true, ShowSpeakerLabel: true, AudioStream: getAudioStream(audioIterator), }) リクエストを送信すると、オーディオストリームデータと Amazon Transcribe の結果を交換するための WebSocket 接続が作成されます。 const data = await client.send(command) for await (const event of data.TranscriptResultStream) { for (const result of event.TranscriptEvent.Transcript.Results || []) { callback({ ...result }) } } result オブジェクトには、 ch_0 や ch_1 など、マイクのソースを識別するために使用できる ChannelId プロパティが含まれます。 詳細: オーディオワークレット オーディオワークレットは別スレッドで実行することで、非常に低レイテンシなオーディオ処理を実現します。実装とデモのソースコードは、 public/worklets/recording-processor.js ファイルにあります。 今回のケースでは、このワークレットを使用して主に2つのタスクを実行します。 mergerNode のオーディオを反復処理します。このノードは両方のオーディオチャンネルを含み、ワークレットへの入力となります。 mergerNode ノードのデータバイトを PCM 符号付き 16 ビット リトルエンディアン オーディオ形式にエンコードします。この処理は、反復処理ごとに、またはアプリケーションにメッセージペイロードを送信する必要があるときに行います。 これを実装するための一般的なコード構造は次のとおりです。 class RecordingProcessor extends AudioWorkletProcessor { constructor(options) { super() } process(inputs, outputs) {...} } registerProcessor('recording-processor', RecordingProcessor) このWorkletインスタンスには、 processorOptions 属性を使用してカスタムオプションを渡すことができます。デモでは、新しいメッセージペイロードを送信するタイミングを決定するためのビットレートガイドとして、 maxFrameCount: (SAMPLE_RATE * 4) / 10 を設定しています。メッセージの例は以下のとおりです。 this.port.postMessage({ message: 'SHARE_RECORDING_BUFFER', buffer: this._recordingBuffer, recordingLength: this.recordedFrames, audioData: new Uint8Array(pcmEncodeArray(this._recordingBuffer)), // PCM encoded audio format }) 2チャンネルのPCMエンコード 最も重要なセクションの一つは、2チャンネルのPCMエンコード方法です。 Amazon Transcribe APIリファレンス のAWSドキュメントによると、AudioChunkは Duration (s) * Sample Rate (Hz) * Number of Channels * 2 で定義されます。2チャンネルの場合、16000Hzで1秒は、1 * 16000 * 2 * 2 = 64000 bytesです。エンコード関数は以下のようになります。 // 入力は配列であり、各要素は AudioWorkletProcessor からの -1.0 ～ 1.0 の Float32 値を持つチャネルであることに注意してください。 const pcmEncodeArray = (input: Float32Array[]) => { const numChannels = input.length const numSamples = input[0].length const bufferLength = numChannels * numSamples * 2 // 2 bytes per sample per channel const buffer = new ArrayBuffer(bufferLength) const view = new DataView(buffer) let index = 0 for (let i = 0; i < numSamples; i++) { // 各チャンネルごとにエンコード for (let channel = 0; channel < numChannels; channel++) { const s = Math.max(-1, Math.min(1, input[channel][i])) // 32 ビット浮動小数点数を 16bit PCM オーディオ波形サンプルに変換します。 // 最大値: 32767 (0x7FFF)、最小値: -32768 (-0x8000) view.setInt16(index, s < 0 ? s * 0x8000 : s * 0x7fff, true) index += 2 } } return buffer } オーディオデータブロックの処理方法の詳細については、 AudioWorkletProcessor: process() ソッドを参照してください。PCM形式のエンコードの詳細については、 Multimedia Programming Interface and Data Specifications 1.0 を参照してください。 結論 この記事では、ブラウザの Web Audio API と Amazon Transcribe ストリーミングを使用して、リアルタイムのデュアルチャネル文字起こしを実現するウェブアプリケーションの実装の詳細について説明しました。 AudioContext 、 ChannelMergerNode 、 AudioWorklet を組み合わせることで、2 つのマイクからの音声データをシームレスに処理およびエンコードし、Amazon Transcribe に送信して文字起こしを行うことができました。特に AudioWorklet を使用することで、低レイテンシーの音声処理を実現し、スムーズで応答性の高いユーザーエクスペリエンスを提供できました。 このデモを基に、会議の録音から音声制御インターフェースまで、幅広いユースケースに対応する、より高度なリアルタイム文字起こしアプリケーションを作成できます。 ぜひこのソリューションをお試しいただき、コメント欄にフィードバックをお寄せください。 原文は こちら です。 About the Author Jorge Lanzarotti  is a Sr. Prototyping SA at Amazon Web Services (AWS) based on Tokyo, Japan. He helps customers in the public sector by creating innovative solutions to challenging problems.