2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催いたしました。本イベントには 22 社 50 名の方々にご参加いただき、生成 AI を活用したデータ分析の新しい可能性について、実践的な学びの場を提供することができました。 イベントの背景と目的 近年、企業の意思決定においてデータ活用は不可欠となっています。しかし、多くの企業が膨大なデータから迅速に意思決定につながるインサイトを得ることに苦心し、データ分析の専門知識を持つ人材の不足に直面しています。さらに、システム部門はダッシュボード作成に十分な工数を割くことができず、ビジネス部門は分析スキルの不足や情報の複雑さにより、効果的にデータ活用ができないという現状があります。これらの課題に対し、生成 AI 技術を活用した BI ツールが新たなソリューションとして注目を集めています。本ワークショップでは、AWS の最新サービスである Amazon Q in QuickSight を通じて、生成AI x BI のデータ分析アプローチを体験していただく機会を設けました。 セッション内容 生成 AI x BI の概要説明とデモ ワークショップの最初のセッションでは、データ分析における生成 AI の可能性と Amazon Q in QuickSight の機能について解説を行いました。自然言語でのダッシュボード作成、データの解釈に関する Q&A 機能、そしてデータストーリーの自動生成という 3 つの機能について、消費財業界向けのサンプルデータを用いたデモを実施しました。システム部門ユーザーとビジネス部門ユーザーそれぞれの視点から、具体的な活用シーンを紹介し、生成 AI と BI の融合がもたらす具体的なビジネス価値について説明しました。 ハンズオン 続くセッションでは、参加者の皆様に実際の Amazon Q in QuickSight を使用したダッシュボードの作成とデータ分析を体験していただきました。消費財業界の受注・出荷データを用いて、テーブル形式のビジュアルや時系列の積み上げ棒グラフなど、様々な形式のデータ可視化を自然言語での指示で作成しました。参加者は「受注金額が一番多い日」や「発注者ごとの出荷金額」といった具体的な問いかけを行い、Amazon Q in QuickSight が即座に適切なビジュアルと回答を提供する、これまでにない分析体験を得ることができました。 ユースケースディスカッション ディスカッションパートでは、参加者は実際の業務課題に基づいたデータ分析ダッシュボードの設計に取り組みました。このセッションでは、現場の具体的な課題からスタートし、生成 AI を活用した解決策の提案まで、段階的なアプローチで議論を深めていきました。 まず個人ワークでは、現場で直面している課題を具体的なストーリーとして言語化することに注力しました。参加者は「○○部署の A さんが××を見れなくて『XYZ できない』と困っている」という形式で課題を特定し、その可視化に必要な条件を 5W1H の形式で整理しました。 続くダッシュボード設計のフェーズでは、各参加者が具体的なラフスケッチを作成しました。ダッシュボードを端的に表現するタイトルの設定、ビジュアルの効果的な配置、フィルター機能の活用方法、KPI の視覚化方法など、実用的な観点から設計を進めました。特に今回は、生成 AI の活用を前提として、自然言語での問いかけとそれに対する期待する描画内容を具体的に検討し、Amazon Q in QuickSight の特徴を活かしたアイディアを考えていただきました。 グループディスカッションでは、各参加者が自身のダッシュボード案を説明し、活発な質疑応答が行われました。議論は特定した現場の課題、提案するダッシュボードの概要、生成 AI の活用方法、実装における工夫点など、多岐にわたりました。各グループで選出された代表者による全体発表では、実務に即した具体的な提案が共有され、参加者全員で知見を深めることができました。 懇親会 セッション終了後の懇親会では、参加者同士の交流を深めながら、各グループから提案されたダッシュボードのアイデアについて投票を行いました。参加者からの投票ではアルフレッサ伊賀様が、AWS メンバーからの投票ではアクタス則武様のアイデアが選出されました。両者とも、実務における課題を踏まえた実践的な提案として高く評価されました。 お客様の声 ワークショップ全体を通じて、他のお客様との交流による新しい知見の獲得や、BI と生成 AI の具体的な活用シーンの理解、実践的なハンズオン体験について、多くの好評の声をいただきました。特に、今後の活用領域として売上・業績予測や複数データの横断分析、自然言語による簡易作成機能への期待が寄せられ、具体的な業務適用への検討意欲も高まりました。 おわりに 本ワークショップは、生成 AI を活用したデータ分析の可能性と実用性について、参加者の皆様に具体的なイメージを持っていただく貴重な機会となりました。今後も、お客様のビジネス課題解決に貢献できるよう、より実践的で価値のある機会を提供してまいります。ご参加いただいた皆様に心より御礼申し上げます。

本記事は 2025 年 6 月 5 日に公開された “ Access Claude Sonnet 4 in Amazon Q Developer CLI ” を翻訳したものです。 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。この最新モデルは、SWE-bench でのエージェント型コーディングにおいて最先端の 72.7% のスコアを記録しており、コーディングにおいて優れた性能を発揮しています（詳細については Claude 4 の発表 をご覧ください）。強化されたコーディングと推論機能により、複雑なコードの分析、日常的な開発タスクの最適化、バグ修正の実装、bash コマンドの実行、新機能の開発を、高速なフィードバックループとより正確な応答で支援します。 Claude Sonnet 4を活用するために、Amazon Q Developerでは特定のClaude Sonnetモデルを簡単に選択できるようになっており、CLIでより柔軟な操作が可能になっています。 Claude Sonnet 4: バランスの取れたインテリジェンスを持つ高性能モデル Claude Sonnet 3.7: 拡張された思考能力を持つ高性能モデル Claude Sonnet 3.5: 高性能インテリジェントモデル Claude モデルの機能と比較の詳細については、 Anthropic モデル概要 を参照してください。 このブログ記事では、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法を説明し、簡単なデモを紹介します。 Claude Sonnet 4 の選択方法 Amazon Q Developer CLI の最新バージョン（ v1.11.0 以降）に更新してください。インストール手順については、 Amazon Q for command line のインストール を参照してください。Claude Sonnet 4 には以下のオプションでアクセスできます： アクティブなチャット中に /model コマンドを使用して claude-4-sonnet を選択 q chat --model claude-4-sonnet で新しいチャットを開始 q settings chat.defaultModel claude-4-sonnet でデフォルトモデルとして設定 --model パラメータと設定でサポートされているモデル名は以下の通りです： claude-3.5-sonnet claude-3.7-sonnet (デフォルト) claude-4-sonnet モデル選択の優先順位 Q Developer CLI は以下の順序でモデルを選択します： 現在のセッションでのモデル選択（ /model または --model による） 設定でのユーザー構成設定 システムデフォルト（ Claude 3.7 Sonnet ） 主要な動作 Q Developer CLI エージェントは、特定のモデルが選択されていない場合、Claude 3.7 Sonnet をデフォルトとします。アクティブなチャットセッション中は、 /model コマンドを使用してモデル間をシームレスに切り替えできます。チャットの継続性はセッション間で維持され、会話が再開されたときにシステムは以前に選択されたモデルを保持します。Claude Sonnet 4 を好む場合、ユーザー設定でデフォルトモデルとして設定すると、すべての新しいチャットセッションに自動的に適用されますが、必要に応じて特定のモデル選択で設定を上書きできます。 図 1: セッションで読み込まれたモデルを表示する Q Developer CLI Claude Sonnet 4 と Q Developer CLI の実際の動作 Q Developer CLI で Claude Sonnet 4 に切り替えた後、その機能を実際のコーディング例で探ってみましょう。こちらがデモンストレーションで使用するプロンプトです。 以下の機能を持つ Python コマンドライン to-do リストアプリを作成してください： - 説明と優先度（low/medium/high）付きのタスクを追加 - インデックスでタスクを完了としてマーク - 優先度、次に挿入順でタスクをソート表示 - 完了ステータスを表示（[x] 完了、[ ] 保留中） - 空のタスクと無効なインデックスのエラーハンドリング - タスクはメモリ内のみに保存 このアプリケーションを実装するコードを提供してください。 図 2: Claude Sonnet 4 の動作を示す Q Developer CLI インターフェイス 上記のデモンストレーションでは、Claude Sonnet 4 を使用した Q Developer CLI が、プロンプトで提供された要件を超えて、引用された説明を含む高度なコマンド解析、包括的なエラーハンドリング、型ヒントで強化されたクリーンなオブジェクト指向設計を実装しました。インターフェイスには、明確なエラーメッセージと列挙型（enum）を使った、シンプルで見やすい優先度の管理、タスクを明確に表現するフォーマットされた出力などを備えた、有用なガイダンスシステムが特徴です。 さらに、Claude Sonnet 4 を使用した Q Developer CLI は、実用的なエラーハンドリングの例と明確な使用方法を含む to-do アプリケーションの README ドキュメントも生成し、プロンプトの要件を構造化された使いやすいアプリケーションに変換しました。 まとめ Claude Sonnet 4 が利用可能になったことは、Amazon Q Developer の機能における重要な進歩を意味します。複雑なコードリファクタリングから効率的なドキュメント作成まで、Claude Sonnet 4 は複雑なタスクも日常的な開発作業も効率的に実行する手助けをします。 複雑なタスクに Claude Sonnet 4 を選択するか、特定のニーズに他のモデルを使用するかにかかわらず、Amazon Q Developer はあなたの好みに適応し、作業の進め方の効率性を維持しながら AI アシスタンスを最適化します。 Amazon Q Developer の最新バージョン（ v1.11.0 ）が CLI に登場し、強化されたモデル機能と選択オプションであなたの開発をサポートします。インストール手順については、 Amazon Q for Command line のインストール を参照してください。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Kirankumar Chandrashekar は、Amazon Q Developer に焦点を当てた AWS の生成 AI スペシャリストソリューションアーキテクトです。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code の深い専門知識を持ち、Amazon Q Developer を使用して顧客の開発プロセスの向上を支援しています。Kirankumar は複雑な顧客の課題を解決することに情熱を持ち、音楽、料理、旅行を楽しんでいます。

Amazon Nova は、Amazon Bedrock で利用できる、最先端のインテリジェンスと業界をリードするコストパフォーマンスを実現する新世代の基盤モデルで、4 つの理解モデル、2 つのクリエイティブコンテンツ生成モデル、1 つの Speech-to-Speech モデルが含まれます。Amazon Nova 理解モデルは、テキスト、画像、動画入力を受け入れてテキスト出力を生成するモデルで、機能、品質、スピード、コストについて幅広い選択肢を提供します。 この記事では 、Amazon Nova 理解モデルのプロンプトエンジニアリングの ベストプラクティス に従って、パフォーマンスを最適化する方法を紹介します。 Amazon Nova 理解モデルの特徴 Amazon Nova モデルには様々なニーズに合うように設計された 4 つの理解モデルが含まれています。 Amazon Nova Micro – 非常に低コストで最小レイテンシーのレスポンスを提供するテキストのみのモデルです。 Amazon Nova Lite – 非常に低コストのマルチモーダルモデルで、画像、動画、テキストの入力を高速で処理できます。 Amazon Nova Pro – 幅広いタスクの精度、速度、コストを最適に組み合わせた、高性能のマルチモーダルモデルです。 Amazon Nova Premier – 複雑なタスクに最適なマルチモーダルモデルであり、コスト効率の高いアプリケーション向けのカスタムモデルを蒸留するための教師にもなります。 各モデルの料金の詳細については、 Amazon Bedrock の料金ページ をご覧ください。 Amazon Nova 理解モデルのプロンプトエンジニアリング モデルを効果的に導いて品質の精度を向上させるため、明確な指示で構造化されたプロンプトを反復的に改善することが重要です。ユースケースに最適なプロンプトを開発できるように、次の要素を検討することをお勧めします。 プロンプトのユースケースの定義する タスク – モデルが具体的に何をするか ロール – モデルが想定すべきロール 応答スタイル – 出力の構造やトーン 指示 – モデルが順守すべきガイドライン 思考連鎖を利用するか モデルの応答を制限する明確で強い指示を与える Step-by-Step で考えることで構造的思考を促す フォーマットと構造 ##Task##、##Context##、##Example## のように、区切り文字を使用してプロンプトのセクションを分ける JSON、YAML、Markdown などの出力形式を指定する DO、DO NOT、MUST など、強い指示や制限を使用する 事前入力(prefill)して、前書きを省略したり指定した形式で出力することを誘導する Amazon Nova 理解モデルのプロンプト例 議事録を要約する以下の例を考えてみましょう。ベストプラクティスに従って Amazon Nova Pro のプロンプトは以下のシステムプロンプトから始まります。ここでは temperature を 0.2、 topP を 0.9 にしています。 あなたは会議議事録の分析と要約に長けた経験豊富なエグゼクティブアシスタントです。あなたの主な責任は、複雑な議論を明確で実行可能な要約にまとめることです。 以下の指示に従ってください。 ##INSTRUCTIONS## 1. ##NOTES## にある会議議事録を読んで理解してください 2. すべての出力を ##OUTPUTS## というセクションにマークダウン形式で入れてください。 3. 会議議事録を 5 文以内に要約してください。これを「全体概要」というセクションに入れてください。 4. 特定の人向けのアクションアイテムと、完了する必要があるものを数値で挙げてください。このリストを「アクションアイテム」というセクションに入れてください。 5. 該当する場合は、次回の会議でさらに詳しく議論する必要があるトピックをリストアップしてください。これを「次回の会議のトピック」というセクションに入れてください。 ユーザプロンプトには、以下の SF 風の架空の議事録を用意しました。最後に ##OUTPUTS## という文字列を事前入力して、前書きの省略とマークダウン形式での出力を誘導しています。 ##NOTES## ミーティング開催日:2050 年 3 月 5 日 ミーティング時間:午後 2 時 場所:銀河間本部会議室 3B 出席者: - キャプテン・スターダスト - ドクター・クェーサー - レディ・ネビュラ - サー・スーパーノヴァ - ミス・コメット 午後 2 時 5 分にキャプテン・スターダストが招集したミーティング 1. 最新のチームメンバー、コメットさんの紹介 2. プラネット・ゾグへの最近のミッションについての議論 - キャプテン・スターダスト：「全体的には成功だったが、ゾギアンとのコミュニケーションは難しかった。私たちは語学力を向上させる必要があります。」 - クエーサー博士：「同感です。すぐにゾギアン-英語辞書の作成に取り掛かります。」 - レディ・ネビュラ：「ゾギアンの料理は文字通りこの世のものとは思えませんでした！船でゾギアンのフードナイトをすることを検討すべきだ。」 3. セクター7における宇宙海賊問題への取り組み - サー・スーパーノバ：「この海賊に対処するには、もっと良い戦略が必要だ。彼らは今月、すでに 3 隻の貨物船を略奪しました。」 - キャプテン・スターダスト：「その地域でのパトロールを増やすことについて、スタービーム提督と話そう。 - クエーサー博士:「船が海賊に発見されないようにするのに役立つ新しいクローキング技術の開発に取り組んできました。プロトタイプを完成させるにはあと数週間かかります。」 4. 毎年恒例の銀河間ベイクオフのレビュー - レディ・ネビュラ：「私たちのチームがコンペティションで2位になったことを報告できてうれしいです！私たちのマーシャン・マッド・パイは大ヒットでした！ - コメットさん：「来年は1位を目指しましょう。ジュピターゼリーの秘密のレシピがあって、それが勝つかもしれないと思う。 5. 次回のチャリティ募金活動の計画 - キャプテン・スターダスト：「インターギャラクティック・チャリティ・バザーのブースには、クリエイティブなアイディアが必要です。」 - サー・スーパーノバ：「『ダンク・ザ・エイリアン』のゲームはいかがですか？エイリアンの格好をしたボランティアに水風船を投げてもらうこともできます。」 - クエーサー博士：「勝者には賞品がもらえる『あの星の名前』トリビアゲームを作れるよ。」 - レディ・ネビュラ：「皆さん、素晴らしいアイディアですね。物資を集めてゲームの準備を始めましょう。」 6. 今後のチームビルディング・リトリート - コメットさん：「ムーン・リゾート・アンド・スパでのチームビルディング・リトリートを提案したいです。最近のミッションを終えて、絆を深め、リラックスする絶好の機会です。」 - キャプテン・スターダスト:「素晴らしいアイディアですね。予算を確認して、実現できるか見てみます。」 7. 次回の会議の議題項目 - ゾギアン英語辞典の最新情報 (クエーサー博士) - クローキング技術の進捗報告 (クエーサー博士) - セクター 7 (キャプテン・スターダスト) でのパトロール強化の結果 - 銀河間チャリティーバザーの最終準備 (全て) 会議は午後 3 時 15 分に延期されました。次回の会議は、2050 年 3 月 19 日午後2時に会議室3Bで開催される予定です。 銀河間本部。 ##OUTPUTS## 以下は Amazon Nova Pro の出力になります。マークダウン形式で出力され、各アクションアイテムの明確な担当者も特定しています。 ### 全体概要 会議では、新しいチームメンバーの紹介、プラネット・ゾグへのミッションの議論、宇宙海賊問題への取り組み、銀河間ベイクオフのレビュー、チャリティ募金活動の計画、チームビルディング・リトリート、そして次回の会議の議題項目について話し合われました。 ### アクションアイテム 1. クエーサー博士：ゾギアン-英語辞書の作成を開始する。 2. キャプテン・スターダスト：スタービーム提督とセクター7でのパトロール増加について話し合う。 3. クエーサー博士：新しいクローキング技術のプロトタイプを完成させる。 4. 全員：銀河間チャリティーバザーのブースのための物資を集める。 5. キャプテン・スターダスト：ムーン・リゾート・アンド・スパでのチームビルディング・リトリートの実現可能性と予算を確認する。 ### 次回の会議のトピック 1. ゾギアン英語辞典の最新情報 (クエーサー博士) 2. クローキング技術の進捗報告 (クエーサー博士) 3. セクター 7 でのパトロール強化の結果 (キャプテン・スターダスト) 4. 銀河間チャリティーバザーの最終準備 (全て) Function calling 生成 AI エージェントの台頭により Tool use(function calling) は 大規模言語モデル （LLM）にとって最も重要な機能のひとつとなりました。ジョブに適したツールを低レイテンシーで正しく選択するモデルの能力が、エージェントを使ったシステムの成功と失敗の分かれ目になる場合があります。 Amazon Nova 理解モデルの Tool use は構造化された API の呼び出しをサポートしており、ツール設定スキーマによるツールの選択をサポートしています。また、これらのツールをいつ発動させるか、させないかを決定するメカニズムも提供しています。 以下の例では、 ツール設定スキーマを渡してツールを呼び出しています。Amazon Nova 理解モデルではツールを呼び出す際に Greedy Decoding を使用するように、 temperature 、 topP 、 topK を 1 に設定することが推奨されています。 Converse API を使用する場合は、 temperature 、 topP は、 inferenceConfig 属性で指定し、 topK は additionalModelRequestFields 属性で指定します。これによりモデルはツールの選択において最高の精度を持つようになります。Greedy Decoding パラメータやその他のツールの使用例については、 Tool use (function calling) with Amazon Nova で詳しく説明されています。 tool_config = { "tools": [{ "toolSpec": { "name": "get_recipe", "description": "構造化されたレシピ生成システム", "inputSchema": { "json": { "type": "object", "properties": { "recipe": { "type": "object", "properties": { "name": {"type": "string"}, "ingredients": { "type": "array", "items": { "type": "object", "properties": { "item": {"type": "string"}, "amount": {"type": "number"}, "unit": {"type": "string"} } } }, "instructions": { "type": "array", "items": {"type": "string"} } }, "required": ["name", "ingredients", "instructions"] } } } } } }] } input_text = "チョコレートラバケーキのレシピを教えてください" messages = [{ "role": "user", "content": [{"text": input_text}] }] # 推論パラメーターを指定 inf_params = {"topP": 1, "temperature": 1} # additionalModelRequestFields でモデル固有の推論パラメータ (topK=1) を指定 response = client.converse( modelId="us.amazon.nova-lite-v1:0", messages=messages, toolConfig=tool_config, inferenceConfig=inf_params, additionalModelRequestFields={"inferenceConfig": {"topK": 1}} ) まとめ Amazon Nova 理解モデルは、Amazon Bedrock で利用可能な高性能かつコスト効率に優れた次世代基盤モデルです。4 つの理解モデルは、機能、品質、スピード、コストに応じて選択できます。Amazon Nova 理解モデルのパフォーマンスを最適化するには、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことが推奨されます。また、これらの手法を活用することでより安価なモデルでも十分なパフォーマンスを発揮しコスト最適化に寄与する可能性があります。

はじめに アマゾン ウェブ サービス (以下、AWS) は、2025年6月30日に Amazon Connect の機能として Amazon Connect Global Resiliency（以下、ACGR）を 日本で一般提供開始 しました。これにより、AWS アジアパシフィック（東京）リージョンで Amazon Connect インスタンスをご利用されているお客様が、AWS アジアパシフィック（大阪）リージョンのインスタンスに設定を同期し、フェイルオーバーできるようになりました。日本国内にある2つの AWS リージョン間で Amazon Connect Global Resiliency を利用することによって、地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることができます。また、データを日本国内に保持しながら、コンタクトセンターの可用性を高めることができます。 本ブログでは Amazon Connect が備えている信頼性について改めて解説した上で、ACGR の機能概要と利用にあたりお客様にご理解いただきたい事項、日本で利用可能なACGR の機能についてご紹介します。ACGR の詳細な解説については、 管理者ガイド をご参照ください。 Amazon Connect の信頼性 Amazon Connect は、AWS グローバルインフラストラクチャ上にデプロイされるオムニチャネルのクラウドコンタクトセンターです。AWS グローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心に構築されています。AWS リージョンは、低レイテンシー、高スループット、高い冗長性を備えたネットワークによって接続された、物理的に独立した複数のアベイラビリティーゾーンを提供します。アベイラビリティーゾーンは、単一または複数のデータセンターインフラストラクチャよりも可用性が高く、耐障害性に優れ、スケーラブルです。 Amazon Connect は、サービスを提供している各 AWS リージョンにおいて、3つ以上のアベイラビリティーゾーン (AZ) に冗長な専用ネットワーク経路を持つ、複数の通信事業者と接続しています。特定のコンポーネント、データセンター、または AZ 全体に障害が発生した場合、影響を受ける箇所は自動的にシステムから除外されます。これにより、お客様に一貫した品質の体験を提供することが可能です。 Amazon Connect に接続する各通信事業者は、アクティブ/アクティブ構成で複数の AZ に接続されています。これにより、ネットワーク経路や AZ 全体の障害がお客様の体験に影響を与えることはありません。また、異なる通信事業者の複数電話番号を利用するデザインにすることで、万一通信事業者に障害が発生した場合でもお客様は別の電話番号を利用してコンタクトセンターに問い合わせることが可能になり、影響を最小限に抑えることができます。詳細については Amazon Connect の耐障害性 をご覧下さい。 図１．単一リージョンのテレフォニーとソフトフォンのアーキテクチャ（出典： Amazon Connect 管理者ガイド ） マルチリージョンの Amazon Connect デプロイメントを検討されるお客様はまず、シングルリージョン/マルチ AZ デプロイメントではお客様のニーズを満たせない理由を明確にし、理解することが重要です。次に、お客様の災害復旧やビジネス継続性に関する要件が、運用やコンプライアンス、その他の規則や規制に関連し、マルチリージョンを必須要件としているかなどを 、AWS のソリューションアーキテクトと議論してください。また、お客様の本番環境で ACGR をご利用いただくには、 AWS Well-Architected Framework の Amazon Connect Custom Lens を確認することが前提条件となります。Well-Architected Framework のレビューを実施することで、ACGR の必要性を確認することができます。 ACGR の機能概要 ACGR は、Amazon Connect に地理的なテレフォニー（電話通信）の冗長性を提供し、予期しないリージョンの機能停止や中断が発生した場合に、インバウンドトラフィックとエージェントを別のリージョンの Amazon Connect インスタンスに分散する柔軟なソリューションを提供します。お客様は複数の AWS リージョンに Amazon Connect をデプロイし、どのリージョンで着信コールを受信し、エージェントが対応するかを API によって制御できます。 コンタクトセンターのお客様は、フェールオーバー後も同一の電話番号を使用して問い合わせが可能です。 コンタクトセンターのエージェントは、フェールオーバー後もログインし直すことなく業務継続が可能です。 ソースインスタンスとレプリカインスタンスは、自動的に双方向で設定を同期します。 これらの機能を理解するために、以下ではいくつかの概念と関連用語を解説します。 トラフィック分散グループ (TDG) トラフィック分散グループ (TDG) は、異なる AWS リージョンにある Amazon Connect インスタンスをリンクするリソースです。ACGR の使用を開始すると、デフォルトの TDG が1つ作成されますが、事業部別窓口などのユースケースに基づいて TDG を追加することもできます。TDG では、トラフィックやエージェントログインの分散を割合 (%) で指定します。コンタクトセンターの管理者はTDG ごとの割合を操作することで、お客様の問い合わせトラフィックをルーティングするリージョンと、エージェントがログインするリージョンを変化させることができます。 図２．トラフィック分散グループ（出典： Amazon Connect Global Resiliency Workshop ） グローバルサインイン ACGR により、コンタクトセンターのエージェントは業務開始時に1度サインインするだけで、どのリージョンを利用しているかを意識することなく、現在アクティブなリージョンを利用してお客様の問い合わせに対応できます。管理者が API を使用して TDG のエージェントログイン先を変更した場合、エージェントが再ログインすることなくアクティブなリージョンに切り替わります。これは、エージェントが ACGR に対応するオプションを有効化したカスタム CCP を利用している場合、またはエージェントワークスペースを使用している場合に有効です。 図３．グローバルサインイン（出典： Amazon Connect Global Resiliency Workshop ） グローバル設定管理 (GSM) ACGR の利用を開始する際は、API を使用してソースインスタンスのレプリカを作成します。これにより、グローバル設定管理サービスは初期レプリケーションプロセスとして、AWS リージョン間で Amazon Connect 設定を複製します。この最初のステップが正常に完了すると、複製されたリソースに対して行われた変更は、ソースまたはレプリカインスタンスのいずれであっても、リージョン間で継続的に双方向で同期されます。同期対象のリソースは こちら を参照してください。レポート、ルール、ビューなどのデータや設定は対象外です。また Amazon Connect が連携している Amazon Lex や AWS Lambda、Amazon S3 上のデータも同期の対象外です。対象外の設定やデータのうち運用に必要となるものは、お客様の責任において設定やデータの複製を実施いただく必要があります。 図４．グローバル設定管理（出典： Amazon Connect Global Resiliency Workshop ） ACGR の監視と運用 ACGR の運用は、お客様と AWS の共同責任です。AWS は2つの AWS リージョンでフェイルオーバーするためのインフラストラクチャを提供する責任があります。お客様は、インスタンス設定を最新の状態に保ち、お客様ごとのビジネス要件に基づいてトラフィックとエージェントの分散を管理する責任があります。また、インスタンスを監視しシステム状態とパフォーマンスにおける異常や、通常と異なる動作を発見する仕組みを準備することが求められます。さらにお客様は、独自の事業継続プロセス (BCP) および標準運用手順 (SOP) において、フェールオーバーの承認プロセスや判断基準を定義しておく必要があります。 ACGR の運用にあたっては、Amazon Connect インスタンスのモニタリングと、ACGR のモニタリングも必要となります。インスタンスのモニタリングでは、アクティブな通話数やコンタクトフローのエラーなどにより、Amazon Connect の健全性を確認します。ACGR のモニタリングは、設定のミラーリングプロセスを確認することで、ACGR 自体の健全性を確認します。これらの監視にあたっては、 Amazon CloudWatch や AWS CloudTrail を活用することができます。 日本における ACGR 利用上の注意事項 AWS アジアパシフィック (大阪) リージョンの Amazon Connect は、AWS アジアパシフィック (東京) リージョンのビジネス継続性を確保するために、音声、チャット、タスクのチャネルを利用することが可能です。2025年6月30日時点では、アジアパシフィック (大阪) リージョンにおいて以下の機能はサポートされていません。 Amazon Lex Amazon Connect Contact Lens Amazon Q in Connect Amazon Connect Customer Profiles Amazon Connect Cases アプリ内通話、ウェブ通話、ビデオ通話機能、および画面共有機能 予測、キャパシティプランニング、スケジューリング Amazon Connect アウトバウンドキャンペーン このため TDG による分散は、通常時が東京100％ / 大阪0%、フェールオーバー時は東京0% / 大阪100% という設定で運用されることになると想定しています。これ以外の設定で東京と大阪を同時に利用する場合、お客様およびエージェントごとの体験に差異が生じる恐れがあります。また、フェールオーバー時に継続利用可能な電話番号は、2025年6月30日時点で TFN (料金無料通話番号)をサポートします。 まとめ ACGR の一般提供開始により、地理的に離れた場所での災害対策を必要とするお客様や、国内でデータを保存する要件のあるお客様のニーズにお応えすることが可能になります。ACGR の利用を開始するには、AWS のアカウントチーム、テクニカルアカウントマネージャー、または Amazon Connect ソリューションアーキテクトにお問い合わせください。詳細なセットアップの方法や、切り替えテストの手順、ベストプラクティスについては、 Amazon Connect Global Resiliency Workshop を参照してください。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊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 アカウントが侵害された場合でも、リカバリアカウントとのボールト共有を有効にできる、信頼された個人で構成される指定承認チームからの認可を活用することで、バックアップデータをリカバリできます。 原文は こちら です。