2025 年も 2 月になり、落ち着きが戻ってきた今日この頃ですが、2024 年の re:Invent で行われた新しいエキサイティングなリリースや発表に追いつこうとしている人がまだ大勢います。2025 年の初めから世界中で何百もの re:Invent re:Cap イベントが開催されており、複数のオプションを提供し、関心のあるリリースを発見して詳細を掘り下げることができるようにする対面式の AWS 公式終日イベントに加えて、コミュニティイベントやバーチャルイベントも行われています。 1 月、私は幸運にも AWS EMEA re:Invent re:Cap の共同司会者を務めることができました。このイベントは、エキスパートとともにデモ、ホワイトボードセッション、ライブ Q&A をほぼ 4 時間に渡って行ったライブストリーム配信でした。見逃した場合でも大丈夫。 オンデマンドで視聴 できるようになりました! このイベントにはすばらしいチームが参加し、何千人もの人々がバーチャル体験を通して楽しく学びました。ぜひ視聴してみてください。どの re:Invent re:Cap イベントにも参加できていない同僚と共有することもお勧めします。 韓国チームも独自のバーチャル re:Invent re:Cap イベントの主催で大成功を収めました。これも オンデマンドで視聴 できます。韓国語を話すなら、このイベントをぜひご覧ください。 見るより読むほうが好きならば、すばらしいオプションがあります。 community.aws にアクセスすることで、あらゆる分野全体のリリースを取り上げたすべてのスライドが含まれる、完全な公式 re:Invent re:Cap デックをダウンロードできます。 また、このサイトではこれから開催される世界中の対面式 re:Invent re:Cap コミュニティイベント のすべてを確認でき、今からでもお近くの都市のコミュニティイベントに参加する機会を得られます。 とは言っても、皆さんご存知のとおり、新しいリリース、発表、更新は re: Invent で終わるわけではありません。さらに多くのリリース、発表、更新が毎週行われています。毎週月曜日に読み、前週の AWS ニュースハイライトを把握できる Weekly Roundup シリーズがあるのはこのためです。 では、2 月 3 日週私が注目したリリースをご紹介しましょう。 2 月 3 日週の AWS リリース AWS Step Functions を使用しているなら、これらのニュースに興味を持つかもしれません。 Distributed Map 向けの新しいデータソースと出力オプション – Distributed Map は、大規模な並列ドキュメント処理に最適です。これからは、JSON ファイルと CSV ファイルに対する既存のサポートに加えて、JSONL ファイル、およびセミコロンやタブで区切られたファイルも処理できるようになります。また、FLATTEN などの新しい出力変換を使用して、コードを追加することなく結果セットを統合することもできます。 ステートマシンとアクティビティの AWS アカウントあたりのデフォルトクォータが 100,000 に増加 – 登録済みのステートマシンとアクティビティの数に対するこれまでの AWS あたりのデフォルトクォータは 10,000 であったため、この増加によってその数が 10 倍になりました。 Amazon Q Developer にもいくつかの更新があります。 Amazon Q Developer Pro ティアサブスクリプションのための新しいシンプル化されたセットアップエクスペリエンス – スタンドアロンアカウント、または AWS Organizations メンバーアカウントの Amazon Q Developer サブスクリプションを、2 ステップセットアップを使用して Amazon Q コンソール から作成できるようになりました。 Amazon Q Developer がすべての AWS 商用リージョンでのコンソールエラーのトラブルシューティングに対応 – Amazon Q Developer は、コンソールでの Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda 、および AWS CloudFormation 使用時における一般的なエラーの診断に役立ちます。アイデンティティ許可の問題、誤った設定などを特定することが可能です。これまで、この機能はいくつかのリージョンに限定されていましたが、すべての AWS 商用リージョンで利用できるようになりました。 その他のさまざまな AWS サービスからのリリースで、今週私の目に留まったものもいくつかご紹介します。 AWS CloudFormation がスタックリファクタリングを導入 – CloudFormation スタックの分割、1 つのスタックから別のスタックへのリソースの移動、同じスタック内にあるリソースの論理名の変更を行えるようになりました。この機能は柔軟性を大幅に向上させ、組織やアーキテクチャ内の変更に対応し続けることを可能にします。これには、既存スタックのリソースライフサイクル管理の合理化、命名規則変更の常時把握、その他の状況などが含まれます。スタックは、 AWS コマンドラインインターフェイス (CLI) または AWS SDK を使用してリファクタリングできます。 AWS Config が 4 つの新しいリリースタイプのサポートを開始 – AWS Config は AWS 環境全体でのリソースの監視に最適で、企業ポリシー、セキュリティポリシー、およびコンプライアンス要件との整合性の確保に役立ちます。4 つの新しいリソースタイプが追加されたことで、 Amazon VPC のパブリックアクセスのブロック設定、これらの設定内で設けられた例外、および S3 Express One Zone バケットポリシーとディレクトリバケット設定を監視できるようになります。 VSS を使用した EC2 インスタンス上の Microsoft SQL Server の自動復旧 – Volume Shadow Copy Services (VSS) と呼ばれる新しい機能を使用して、Microsoft SQL Server データベースの実行中にそのデータベースを Amazon Elastic Block Store (EBS) スナップショットにバックアップできるようになりました。バックアップ後、 AWS Systems Manager Automation ランブックを使用して希望に応じた復旧時点を設定すると、ダウンタイムなしで VSS ベースの EBS スナップショットからデータベースを自動的に復元します。 その他の更新 AWS Security Token Service (AWS STS) グローバルエンドポイントに対する今後の変更 – アプリケーションのレジリエンシーとパフォーマンスの向上を支援するため、AWS では AWS STS グローバルエンドポイント (https://sts.amazonaws.com) に対する変更を行っています。お客様が対応する必要のあるアクションはありません。2025 年初頭を皮切りに、STS グローバルエンドポイントへのリクエストは AWS でデプロイされたワークロードと同じリージョン内で自動的に処理されます。例えば、アプリケーションが米国西部 (オレゴン) リージョンから sts.amazonaws.com を呼び出す場合、呼び出しは米国東部 (バージニア北部) リージョンではなく、米国西部 (オレゴン) リージョンでローカルに処理されます。これらの変更は今後数週間内にリリースされ、2025 年中盤までにデフォルトで有効になっている AWS リージョンに順次導入される予定です。 今後予定されている AWS とコミュニティのイベント AWS Public Sector Day London (2 月 27 日) – 公共部門のリーダーやイノベーターとともに、AWS が政府、教育、ヘルスケアの分野でデジタルトランスフォーメーションをどのように実現しているのかを探りましょう。 AWS Innovate GenAI + Data Edition – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンス。このカンファレンスは、APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 今後開催される追加の AWS 主導の対面イベント と デベロッパー向けのバーチャルイベント をご覧ください。 おすすめの本をお探しですか? Amazon の VP 兼 CTO であるワーナー ヴォゲルス博士は、皆さんに読んでもらいたい おすすめの本のリスト を毎年の始めに公開しています。今年のリストは特にすばらしいと思います! 2 月10 日週のニュースは以上です。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 次回をお楽しみに :) Matheus Guimaraes | @codingmatheus 原文は こちら です。

本記事は 2025 年 1 月 31 日に AWS Public Sector Blog で公開された Data dissemination for public sector on AWS を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 組織が情報に基づいた意思決定を行い、イノベーションを促進するためには、データの共有が不可欠です。 アマゾン ウェブ サービス (AWS) は、大規模なデータを安全に配信するためのさまざまなツールとサービスを提供しています。 公共の利益のためにオープンデータの公開、ビジネス目的でのプライベートデータセットの収益化、さらには社内での協業などの用途で、AWS は必要なインフラストラクチャとサポートを提供します。 AWS のクラウドサービスを活用することで、組織はチームや AWS パートナー、ユーザーとの安全なデータ共有が可能になり、価値のある洞察を得て成長につなげることができます。 AWS のデータ共有機能は、単なる要件の充足にとどまらず、今日のデータ駆動型環境における戦略的優位性の確保を実現します。 Open Data on AWS データ共有の利点が広く認識されるようになり、オープンデータの取り組みへの注目が高まっています。 AWS は、 Open Data on AWS プログラムを通じてこの動きをサポートしています。 Registry of Open Data on AWS では、幅広いデータセットが保管・公開されており、 AWS オープンデータスポンサーシッププログラム を活用することでストレージコストを抑えることもできます。 Registry of Open Data on AWS には、行政データ、科学研究、ライフサイエンス、気候、衛星画像、地理空間情報、ゲノムデータなど、さまざまなオープンデータセットが登録されています。 Open Data on AWS は、Registry of Open Data on AWS を通じてコラボレーションとイノベーションを促進しています。データプロバイダーは AWS の信頼性の高い安全なインフラストラクチャを使用してデータセットを公開でき、研究者や開発者は、データをダウンロードや保存することなく、価値あるデータに簡単にアクセスして分析やアプリケーション開発に活用できます。AWS オープンデータスポンサーシッププログラムにより、価値の高いデータセットを公開する際のストレージ費用を AWS が負担します。また、データプロバイダーと利用者の双方が、データセットに関連するノートブックや分析結果、引用文献などの情報をレジストリページで共有できます。 Open Data on AWS の利点: グローバルな影響力: Open Data on AWS では、世界中のユーザーがデータセットにアクセスでき、グローバルな協業と発展が可能になります。 成長とイノベーションの加速: AWS にデータを保存することで、各種 AWS サービスを使用した迅速なデータ処理・分析が可能になります。これにより、データから洞察を得ることができます。 コンピューティング、分析、機械学習など、 AWS の幅広いサービスを活用することで、クラウド上で効率的かつ大規模なデータ分析を実現できます。 AWS Data Exchange AWS Data Exchange は、AWS 上でサードパーティのデータを簡単に検索、購読、利用できるサービスです。 認定データプロバイダーのデータ製品カタログを提供しており、組織はサードパーティデータのライセンス取得、取り込み、管理といった一般的な課題に悩まされることなく、必要なデータに素早くアクセスできます。 AWS Data Exchange は、データ製品の発見から購読、配信までを一貫して提供する完全なエンドツーエンドサービスです。 Open Data on AWS からのデータセット を含むさまざまなデータセットのインポートが可能で、 購読 や データアクセス権限の管理 を効率的に行えます。また、データプロバイダーが AWS Marketplace でデータ製品を 公開して収益化する ためのプラットフォームも提供します。 この統合的なアプローチにより、調達から収益化までのデータ取引の全プロセスが AWS エコシステム内で効率化されます。 AWS Data Exchange を利用する最大の利点の一つが、配信の効率化です。 データプロバイダーは他のデータカタログと同様に、自社のデータ製品を容易に公開できます。プロバイダーはデータを掲載・販売でき、利用者はこれらのデータセットを自社のアプリケーションやワークフローで検索、購読、使用できます。 AWS マネジメントコンソール や API を通じて必要な製品を購読でき、個別のライセンス契約や複雑なデータ転送プロセスの管理が不要となるため、データ共有が効率化されます。 AWS Data Exchange は AWS の規模とセキュリティを活用することで、信頼性が高く一貫性のあるデータ配信を実現しています。 AWS 経由の直接配信により、高い可用性と耐久性が確保され、 AWS の包括的なセキュリティ管理とコンプライアンス認証の恩恵も受けられます。これにより、プロバイダーは知的財産を安全に保護でき、利用者は受け取ったデータの真正性と最新性を確認できます。 AWS Data Exchange はデータの売買をより円滑にします。 標準化された従量課金制の料金モデル により、利用者は必要なデータを容易に購入・使用できます。これにより、価値あるデータへのアクセスが容易になり、あらゆる規模の組織がサードパーティデータを自社のアプリケーションや分析に活用できるようになります。結果として、イノベーションの促進とビジネス価値の向上につながります。 AWS Data Exchange の利点: 豊富なデータコレクション: 世界中の 300 以上のプロバイダーによる 3,500 以上のデータセットにアクセスできる一元化されたデータリポジトリを提供します。 データ収集の効率化: データ収集プロセスを一元化し、迅速化します。 単一の API で複数のプロバイダーからのデータ取り込みを一元管理できます。 AWS サービスとのネイティブ統合: AWS の分析サービスや 機械学習モデルとシームレスに連携し、データからの迅速な洞察の抽出を可能にします。 また、AWS の認証とガバナンスもサポートしています。 Storage Browser for Amazon S3 AWS は、 Storage Browser for Amazon S3 の一般提供を 2024 年 12 月 1 日に開始しました。この機能により、開発者はカスタマイズ可能なファイルブラウザをアプリケーションに直接組み込むことができ、個人ファイルの管理や小規模な共同作業が必要なケースで特に威力を発揮します。 オープンデータポータルや研究プラットフォームと統合できるため、 Amazon Simple Storage Service (Amazon S3) バケットに保存された大規模なオープンデータセットへの簡単なアクセスが可能になります。例えば、科学系の研究機関では研究データの共有に活用でき、データセット全体をダウンロードすることなく、他の研究者が価値ある情報への閲覧やアクセスが可能になります。 これにより、オープンサイエンスとグローバルな研究協力が促進されます。 このツールを使用することで、ユーザーはアプリケーション環境を離れることなく、Amazon S3 バケット内のデータへのシームレスなアクセス、表示、操作が可能になります。 Storage Browser for Amazon S3 は一般的なファイル操作をサポートし、アプリケーションのブランディングに合わせたカスタマイズが可能なため、ビジネス用途から一般消費者向けまで幅広いアプリケーションに対応できます。 Amazon S3 データアクセスをアプリケーションに直接統合することで、ユーザー体験と生産性が大幅に向上し、Amazon S3 保存ファイルの管理のために別の管理画面を行き来する必要もなくなります。 この機能により、アプリケーションワークフロー内でのクラウドストレージの利便性が向上します。今日から、 Storage Browser for Amazon S3 をはじめてみましょう 。 Storage Browser for Amazon S3 の利点: アプリケーションとの統合: アプリケーションに直接組み込みが可能で、直感的なユーザー体験を提供します。 データ移動の削減: Amazon S3 のデータへの直接アクセスにより、大規模データセットのコピーや移動が不要になります。データセット全体のコピーやダウンロードを必要とする従来の方式と比べ、はるかに効率的です。 リアルタイムアクセス: アプリケーション内で Amazon S3 データのリアルタイムな閲覧、検索、操作が可能です。データ転送のリクエストと待機が必要な他の方法と比べ、より迅速な作業が可能です。 Build-your-own (BYO) Lens on AWS 独自ソリューションである Build-Your-Own (BYO) Lens on AWS を活用することで、組織独自の視点でデータを解析できる仕組みを構築できます。カスタマイズされた基盤を開発することで、チーム間のスムーズなデータ共有が可能になります。組織の専門知識、経験、対象分野への理解を活かすことで、より深い洞察を得ることができます。BYO Lens on AWS は組織固有のニーズ、優先事項、意思決定プロセスに合わせてカスタマイズでき、得られた洞察を迅速に実行に移せます。 BYO Lens on AWS は、データの準備、分析、可視化という３つの基本ステップで構成されています。 AWS の各種サービスを活用することで、これらの基本ステップを容易に実装できます。 Amazon QuickSight 、 AWS Glue 、 Amazon Athena 、 AWS Lambda などのサービスにより、特定のニーズに合わせたデータを加工が可能です。また、 Amazon S3 などのデータストレージ特化型サービスにより、複数のデータソースを統合できます。 AWS のサービスはスケーラブルに設計されているため、BYO Lens on AWS のワークフローで大量のデータを処理できます。 BYO Lens on AWS のワークフローは高度なセキュリティを備えており、カスタムデータ配信レンズで生成されたデータや得られた洞察の機密性、完全性、可用性を確保します。 これらの AWS サービスは、共通データワークフローの中で次のように組み合わせて使用できます。 データ取り込み: データ配信側でユーザーが情報を要求する際に連携して機能します。さまざまなカスタムデータソースを生データとして Amazon S3 に格納し、 Amazon S3 イベント通知 と Amazon EventBridge で自動的にアプリケーションに送信できます。処理用の計算アプリケーションに生データが送信されると、データ変換が開始されます。 データ配信とセキュリティ: ユーザーは Amazon Route 53 で管理されているドメインにアクセスし、 Amazon CloudFront / Amazon S3 によりコンテンツが配信されます。 カスタム BYO Lens on AWS は AWS WAF により、クロスサイトスクリプティング、SQL インジェクション、その他の一般的な攻撃から保護されます。 データ配信: コンテンツから呼び出された API リクエストは Amazon API Gateway に送られ、 Amazon Cognito が発行したトークンを使用してリクエストの認可が行われます。 認可が成功すると、AWS Lambda はこれらの API リクエストの実行と応答を管理し、データの配信、変換、取り込みのワークフローをシームレスにつなぎます。 データ変換: ETL (抽出・変換・ロード) 処理には AWS Glue を活用し、処理後のデータは Amazon S3 に格納されます。 この ETL 処理の過程で、 AWS Glue Data Catalog によってデータカタログが自動生成されます。ユーザーからのリクエストを受けた際は、 AWS Lambda を介して Amazon Athena が起動され、データカタログを参照しながら Amazon S3 上のデータに対して SQL クエリを実行します。クエリの実行結果は、 AWS Lambda、 Amazon API Gateway、 Amazon CloudFront という一連の流れを通じてユーザー側に戻されます。 BYO Lens の利点: 完全なコントロール: システムアーキテクチャ、データソース、データ変換、配信ワークフローを完全にコントロールできます。これにより、既存システムとの連携やユーザー体験のカスタマイズが可能となります。 AWS サービス選択の柔軟性: マネージドサービスに縛られることなく、要件に最適な AWS サービスを自由に選択できます。 セキュリティ/データガバナンス: 独自の基盤構築により、データガバナンス、アクセスポリシー、セキュリティ対策をきめ細かく管理できます。また、組織内の各チームに対して、アーキテクチャ内の特定サービスへのアクセス権限をより詳細なレベルで設定できます。 カスタマイズ: 組織のビジュアルアイデンティティとユーザーニーズに沿った、独自のユーザー体験、ブランディング、インターフェースを実現できます。これにより、より統一感のあるブランド体験を提供できます。さらに、 AWS 環境内の既存のデータパイプライン、分析ツール、その他のビジネスシステムとのデータ連携を円滑に行い、効率的なサービスエコシステムを構築できます。 図 1. BYO Lens on AWS におけるデータ配信の一般的なデータワークフロー。 主要なコンポーネントには Amazon Route 53、Amazon CloudFront、Amazon S3、Amazon API Gateway、AWS Lambda、Amazon Cognito、Amazon DynamoDB、Amazon Athena、AWS Glue、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Container Service (Amazon ECS)、Amazon EventBridge が含まれています。 まとめ AWS は、Open Data on AWS、AWS Data Exchange、Storage Browser for Amazon S3、Build-your-own (BYO) Lens on AWS など、データ配信のための包括的なツールとサービスを提供しています。 これらのソリューションにより、公開データセットから商用データ製品まで、さまざまなデータ共有のニーズに対応でき、組織は大規模なデータを安全かつ効率的に配信することができます。 Open Data on AWS はオープンデータの取り組みを支援し、AWS Data Exchange はサードパーティのデータ製品の発見と利用を促進します。 Storage Browser for Amazon S3 はアプリケーションへのファイルブラウザの組み込みを可能にし、BYO Lens on AWS はカスタマイズ可能なデータ解析基盤を提供します。これらはいずれも、AWS の強固なインフラストラクチャとセキュリティ機能を活用しています。 その他の参考資料 Improving customer experience for the public sector using AWS services Storage Browser for Amazon S3 を使用して、アプリケーションを通じてユーザーをデータに接続 著者について Austin Park は、連邦文民機関を支援するアマゾン ウェブ サービス (AWS) のソリューションアーキテクトです。 ストレージを専門としており、AWS のツールを使ってシンプルなプロセスを効率化し、お客様が可能性を最大限に引き出せるようにすることに情熱を注いでいます。 Raaga N.G は、連邦文民機関を支援するアマゾン ウェブ サービス (AWS) のソリューションアーキテクトです。 アナリティクスを専門としており、複雑な問題を解決し、顧客が目標を達成できるよう支援することに情熱を注いでいます。 Rayette Toles-Abdullah は、アマゾン ウェブ サービス (AWS) の連邦文民機関を支援するプリンシパルソリューションアーキテクトです。 デジタルトランスフォーメーション、企業戦略、システムインテグレーション、クラウド運用、ガバナンス、アプリケーションモダナイゼーションを専門としています。

本記事は 2024 年 5 月 21 日に公開された “ How 20 Minutes empowers journalists and boosts audience engagement with generative AI on Amazon Bedrock ” を翻訳したものです。 この投稿は 20 Minutes の Aurélien Capdecomme と Bertrand d’Aure との共著です。 月間 1900 万人の読者を持つ 20 Minutes は、フランスの主要メディアです。このメディアは主に若く活発な都市部の読者を対象に有用で関連性が高く、アクセスしやすい情報を提供しています。毎月約 830 万人の 25 歳から 49 歳までの人々が情報を得るために 20 Minutes を選んでいます。 2002 年に設立された 20 Minutes はニュースを、印刷物、ウェブ、モバイルプラットフォームを通じて、毎月フランス国民の 3 分の 1 以上 (39%) に届けています。 20 Minutes の技術チームとして、私たちは組織のウェブおよびモバイル製品の開発と運用、そして革新的な技術イニシアチブの推進に責任を負っています。数年にわたり機械学習と人工知能 (AI) を積極的に活用し、デジタル出版のワークフローを改善し、読者に関連性がありパーソナライズされた体験を提供してきました。生成 AI の到来、特に大規模言語モデル (LLM) の登場により、私たちは現在 AI バイデザインの戦略を採用し、新しい技術製品を開発するたびに AI の適用を評価しています。 私たちの主要な目標の 1 つは、ジャーナリストに最高級のデジタル出版体験を提供することです。私たちのニュースルームのジャーナリストは、内製でカスタムしたデジタル編集体験である Storm を使ってニュース記事に取り組んでいます。 Storm は サーバーレス コンテンツ管理システム (CMS) である Nova のフロントエンドとして機能しています。これらのアプリケーションは、私たちの生成 AI の取り組みの中心となっています。 2023 年、私たちは生成 AI が肯定的な影響を及ぼす可能性のあるいくつかの課題を特定しました。これには記者向けの新しいツール、視聴者の関与を高める方法、そして広告主が私たちのコンテンツのブランドセーフティを自信を持って評価できるようにする新しい方法が含まれます。これらのユースケースを実装するために、私たちは Amazon Bedrock を利用しています。 Amazon Bedrock は、 AI21 Labs 、 Anthropic 、 Cohere 、 Meta 、 Stability AI 、 Amazon Web Services(AWS) などの有力な AI 企業から、単一の API を通じて高性能な基盤モデル (FM) を選択できるだけでなく、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供するフルマネージドサービスです。 このブログ記事では、生成 AI を使ってデジタルパブリッシングの課題に取り組んでいるさまざまなユースケースについて概説しています。私たちは実装の技術的側面に踏み込み、基盤モデルプロバイダーとして Amazon Bedrock を選択した理由を説明します。 課題と使用事例の特定 昨今のペースの早いニュース環境では、デジタル出版社にとって課題と機会の両方が存在します。 20 Minutes では、技術チームの主要な目標の 1 つは、ジャーナリストのための新しいツールを開発することです。これらのツールは反復作業を自動化し、報道の質を向上させ、より広範な読者層に到達できるようにします。この目標に基づき私たちは生成 AI が肯定的な影響を与えることができる 3 つの課題とそれに対応するユースケースを特定しました。 最初のユースケースは、デジタル出版プロセスの一環としてジャーナリストが行う反復的な手作業を自動化して最小限に抑えることです。ニュース記事の作成の中核は、調査、執筆、編集作業に関わります。しかし記事が完成した後、記事の要約、カテゴリ、タグ、関連記事などのサポート情報とメタデータを定義する必要があります。 これらのタスクは面倒に感じられるかもしれませんが、 検索エンジン最適化 (SEO) にとって重要であり記事の読者層の拡大にもつながります。これらの反復作業の一部を自動化できれば、ニュース編集室での時間を主要な記者業務に集中させつつ、コンテンツの読者層を拡大できる可能性があります。 2 つ目の使用例は、 20 Minutes でニュース通信社の記事をどのように再発行しているかです。ほとんどのニュース機関と同様に、 20 Minutes は フランス通信社 (AFP) などの ニュース通信社 に加入し、国内外のニュースを配信するフィードを購読しています。 20 Minutes のジャーナリストは読者層に関連する記事を選び、編集方針とわれわれの読者が慣れ親しんだ独自のトーンに合わせて書き直し、編集、拡張します。これらの記事を書き直すことは、検索エンジンが重複したコンテンツを低く評価するため、 SEO にも必要不可欠です。この作業にはパターンがあるため、再発行プロセスを簡素化し、その時間を短縮するために AI ベースのツールを構築することにしました。 私たちが特定した 3 つ目の最終的な使用例は、公開したコンテンツのブランドセーフティについての透明性を高めることです。デジタル出版社である 20 Minutes は、潜在的な広告主に対してブランドセーフな環境を提供することを約束しています。コンテンツは広告やマネタイズに適しているかどうかに基づいて、ブランドセーフである、またはブランドセーフではないと分類されます。広告主やブランドによって、適切と見なされるコンテンツの種類が異なります。例えば一部の広告主は、軍事紛争などの取り扱いが難しい話題に関するニュースコンテンツの横に自社のブランドが表示されるのを望まない可能性があり、薬物やアルコールに関するコンテンツの横には表示されたくないと考える広告主もいるかもしれません。 Interactive Advertising Bureau (IAB) や Global Alliance for Responsible Media (GARM) などの組織は、コンテンツのブランドセーフティを分類するための包括的な ガイドライン や フレームワーク を策定しています。これらのガイドラインに基づき、 IAB などのデータプロバイダーは、 20minutes.fr などのウェブサイトを定期的にクロールしブランドセーフティスコアを算出することでデジタル出版社のブランドセーフティを自動評価しています。 しかしながらこのブランドセーフティースコアはサイト全体のものであり、個々のニュース記事については細かく分けられていません。大規模言語モデル (LLM) の推論能力を考慮し、業界標準のガイドラインに基づいた記事ごとの自動ブランドセーフティー評価を開発することにしました。これにより広告主に対して 20 分のコンテンツのブランド安全性をリアルタイムで細かく提供できるようになります。 私たちの技術ソリューション 20 Minutes では 2017 年から AWS を使用しており、可能な限りサーバーレスサービスの上にシステムを構築することを目指しています。 デジタルパブリッシングフロントエンドアプリケーションの Storm は、 React と Material Design を使って構築されたシングルページアプリケーションで、 Amazon Simple Storage Service (Amazon S3) と Amazon CloudFront を使ってデプロイされています。当社の CMS バックエンド Nova は、 Amazon API Gateway と複数の AWS Lambda 関数を使って実装されています。 Amazon DynamoDB は 20 Minutes の記事の主要なデータベースとして機能しています。新しい記事や既存の記事の変更は DynamoDB Streams によってキャプチャされ、 AWS Step Functions の処理ロジックを呼び出し、 Amazon OpenSearch に基づく検索サービスに送られます。 私たちは、 AWS PrivateLink を使用して Amazon Bedrock を統合しています。これにより、パブリックインターネットを経由することなく、 Amazon Virtual Private Cloud (VPC) と Amazon Bedrock の間に プライベート接続 を作成できます。 Storm で記事を作業する際、ジャーナリストは Amazon Bedrock を使って実装されたいくつかの AI ツールにアクセスできます。 Storm はタイトル、リード文、本文、画像、ソーシャルメディアの引用などのさまざまなコンテンツブロックを組み合わせて完全な記事を作成できるブロックベースのエディターです。 Amazon Bedrock を使えば、ジャーナリストは記事の要約提案ブロックを生成し、それを直接記事に配置することができます。記事全文をコンテキストとした単一のプロンプトを使って要約を生成しています。 Storm CMS はジャーナリストに記事のメタデータの提案も行います。これには適切なカテゴリ、タグ、さらにはテキスト内リンクの推奨が含まれます。他の 20Minutes コンテンツへの参照リンクは、検索エンジンが関連する内部および外部リンクを多く含むコンテンツをより高くランク付けするため、ユーザーエンゲージメントを高めるのに重要です。 これを実装するため、 Amazon Comprehend と Amazon Bedrock を組み合わせて記事のテキストから最も関連性の高い用語を抽出し、OpenSearchの内部の分類データベースに対して検索を行っています。その結果に基づいて、 Storm は他の記事やトピックにリンクすべき用語のいくつかを提案し、ユーザーはそれらを受け入れるか拒否することができます。 ニュース速報は AFP などのパートナーから受信次第、 Storm で利用可能になります。ジャーナリストはこれらの速報を閲覧し 20minutes.fr で再掲載するものを選択できます。すべての速報は掲載前にジャーナリストによって手作業で加工されます。加工のために、ジャーナリストはまず Amazon Bedrock の LLM を使って記事の書き直しを行います。この際、低い temperature のsingle-shot プロンプトを使用し、 LLM に記事の解釈を変更せず、文字数と構造をできるだけ維持するよう指示します。書き直された記事は他の記事と同様に Storm でジャーナリストが手作業で編集します。 新しいブランドセーフティー機能を実装するため、 20minutes.fr に掲載される新しい記事すべてを処理しています。現在、記事のテキストと IAB のブランドセーフティーガイドラインの両方をコンテキストに含む single-shot プロンプトを使用し、 LLM から感情評価を得ています。その後レスポンスを解析し、感情を保存し、各記事に対して広告サーバーがアクセスできるようにパブリックに公開しています。 教訓と展望 20 Minutes で生成 AI のユースケースに取り組み始めたとき、機能を繰り返し改良し、本番環境に導入できるスピードの速さに驚きました。 Amazon Bedrock の統合された API のおかげで、モデルを簡単に切り替えて実験し、各ユースケースに最適なモデルを見つけることができます。 上記のユースケースでは、全体的な高品質、特にフランス語のプロンプトを認識し、フランス語の完了を生成する能力が優れているため、 Amazon Bedrock 上の Anthropic の Claude を主要な大規模言語モデルとして使用しています。20 Minutes のコンテンツはほぼ完全にフランス語なので、この多言語対応能力は私たちにとって非常に重要です。適切なプロンプトエンジニアリングが成功の鍵であり、完了品質を最大化するために Anthropic のプロンプトエンジニアリングリソース を熱心に活用しています。 ファインチューニング や 検索拡張生成 (RAG) などのアプローチに頼らなくても、ジャーナリストに本当に価値を提供するユースケースを実装できます。当社のニュース編集室のジャーナリストから収集したデータに基づくと、当社の AI ツールは 1 記事あたり平均 8 分の時間を節約できます。毎日約 160 本のコンテンツを発行していることから、これはすでに大きな時間の節約となり、ジャーナリストはニュースを読者に報じることに集中できるようになります。 このようなユースケースの成功は、技術的な取り組みだけでなく、製品、エンジニアリング、ニュース編集室、マーケティング、法務チームとの緊密な協力にも依存しています。これらの役割から代表者が集まり、 AI 委員会を構成しています。この委員会は、20 Minutes における AI の透明性と責任ある利用を確保するための明確な方針とフレームワークを確立しています。例えば、AI の利用はすべてこの委員会で検討・承認される必要があり、AI で生成されたコンテンツはすべて人間による検証を経てから公開されます。 私たちは、デジタルパブリッシングに関しては生成 AI がまだ初期段階にあると考えていますが、今年はプラットフォームにさらに革新的なユースケースをもたらすことを期待しています。現在、 Amazon Bedrock でファインチューニングされた LLM を展開し、当社の出版物のトーンと声を正確に合わせ、ブランドの安全性分析機能を更に改善する作業を行っています。また、Bedrock モデルを利用して既存の画像ライブラリにタグ付けを行い、記事の画像に関する自動提案を行う予定です。 なぜ Amazon Bedrock か？ 複数の生成 AI モデルプロバイダを評価し、上記のユースケースを実装した経験に基づいて、 Amazon Bedrock を当社のすべての基盤モデルニーズの主要プロバイダとして選定しました。この決定に影響を与えた主な理由は次のとおりです: モデルの選択: 生成 AI の市場は急速に進化しており、AWS のアプローチは複数の主要モデルプロバイダーと協力することで、 単一の API を通じて大規模で成長し続ける基盤モデルにアクセスできることを保証しています。 推論パフォーマンス : Amazon Bedrock は低レイテンシーかつ高スループットの推論を実現します。オンデマンドと プロビジョニングされたスループット により、サービスはすべてのキャパシティのニーズを確実に満たすことができます。 プライベートモデルアクセス : AWS PrivateLink を使用して、Amazon Bedrock エンドポイントへのプライベート接続を確立し、パブリックインターネットを経由せずに推論のためのデータを送信することで、完全にデータを制御できます。 AWS サービスとの統合: Amazon Bedrock は AWS Identity and Access Management (IAM) や AWS Software Development Kit (AWS SDK) などの AWS サービスと緊密に統合されています。その結果、新しいツールや規約に適応することなく、既存のアーキテクチャに Bedrock を迅速に統合することができました。 まとめと今後の展望 このブログ記事では、 20 Minutes が Amazon Bedrock 上の生成 AI を活用して、ニュース編集室の記者をサポートし、より広範な読者層に到達し広告主にブランドの安全性を透明化する方法を説明しました。これらのユースケースでは、生成 AI を活用して記者に今日からより多くの価値を提供し、将来の有望な新しい AI ユースケースの基盤を築いています。 Amazon Bedrock の詳細を知るには、ドキュメント、ブログ記事、その他の顧客の成功事例などの Amazon Bedrock リソース を参照してください。 翻訳はソリューションアーキテクトの紙谷が担当しました。原文は こちら です。 著者について Aurélien Capdecomme は 20 Minutes の最高技術責任者であり、 IT 開発およびインフラストラクチャチームを率いています。効率的で最適化されたアーキテクチャの構築に 20 年以上の経験を持ち、サーバーレス戦略、スケーラブルなアプリケーション、 AI イニシアチブに強い焦点を当てています。彼は 20 Minutes でイノベーションとデジタル変革戦略を実施し、デジタルサービスのクラウドへの完全移行を監督しました。 Bertrand d’Aure は 20 Minutes のソフトウェア開発者です。技術者として訓練を受けた彼は、 20 Minutes のアプリケーションのバックエンドを設計・実装しており、特に記者がストーリーを作成するためのソフトウェアに重点を置いています。その他にも彼は執筆プロセスを簡素化するために、ソフトウェアに生成 AI の機能を追加する役割を担っています。 Dr. Pascal Vogel は Amazon Web Services のソリューション アーキテクトです。彼は EMEA 地域の企業顧客と協力し、サーバーレスと生成 AI に焦点を当てたクラウドネイティブソリューションを構築しています。クラウド愛好家の Pascal は、新しいテクノロジーを学び、クラウドの旅路で変革を遂げたいと考える同じ志を持つ顧客と交流することを愛しています。

本ブログは 株式会社ｉｉｍｏｎ  様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの尾形です。 昨今、多くの企業で SaaS (Software as a Service) を導入するケースが増加し、 SaaS 市場が拡大してきております。一方で SaaS を提供する側には、お客様に自社サービスを効果的に使っていただくために、利用するユーザーのアクティビティデータを基にした営業活動やカスタマーサポートを実現し、日々サービスの改善が求められています。 本記事では AWS 上で 自社 SaaS データ分析基盤を構築し、「提供している様々な機能を、より多くの SaaS ユーザーに活用してもらうこと」 や 「 SaaS ユーザーのデータに基づく営業活動の推進」 を実現された ｉｉｍｏｎ 様の事例をご紹介します。同社は Amazon QuickSight 、 Amazon Athena 、 Amazon Data Firehose などを利用して SaaS データ分析基盤を構築されています。 ｉｉｍｏｎ 様の状況と経緯 ｉｉｍｏｎ 様は、主に不動産仲介業務の効率化を目的としたデジタルトランスフォーメーション（DX）ツール「速いもんシリーズ」を提供しています。開発の背景として、不動産仲介の業務において広告業務や顧客対応時の作業など事務業務が全業務の約 50% 程度を占めるため、これらの作業を自動化・効率化することで、不動産仲介店舗の従業員が営業活動に集中できると考えました。 速いもんシリーズ 「速いもんを導入した不動産仲介店舗に、より多くのサービス機能を使いこなして業務を自動化・効率化していただくために、ｉｉｍｏｎ 様は「速いもんシリーズ」のサービス利用状況のアクティビティデータを営業活動に活用していました。しかし当時は、エンジニアがサービス利用状況のアクティビティデータ抽出を実施し、その後に営業が手動でデータを分析していたので、エンジニアによるアクティビティデータ抽出の工数及び営業によるデータ分析の工数が発生しました。そこでエンジニア及び営業の負担にならないアクティビティデータ分析基盤の構築は重要課題でした。 また、サービスを導入する不動産仲介店舗が増加することに伴い、店舗毎のサービス機能の利用数にばらつきが発生し、カスタマーサポートのチームが全ユーザーに対して、高い質のサポートを提供することが困難な状況でした。カスタマーサポートチームは、サービス導入後のチャーンレート (解約率) は重要な指標のため、前述の状況を改善したいと考えました。そこで、ユーザーのサービス利用状況のアクティビティデータを業務に活かせないか検討しました。 ソリューション / 構成内容 「速いもんシリーズ」は、サービスを利用するユーザーが機能を利用した頻度やクリック数などのアクティビティデータを収集しています。 データ分析基盤の構成 それらのアクティビティデータはリアルタイムでサービスから送られています。そこで Amazon Data Firehose を利用することにより、リアルタイムで送られるデータを一定期間バッファリングした後に Amazon S3 に保存しています。 Amazon S3 にデータを保存する際に工夫している点は 2 つあります。 Parquet 形式でデータ保存 Amazon Athena の検索に用いるパーティションを「日付」のみ使用 1 については、JSON 形式も検討しましたが、データ量が多くなると分析時の読み込みに時間がかかる懸念がありました。そこで、データの圧縮効率が高く、ストレージ容量の節約も実現できる Parquet 形式を採用しました。 2 については、「何をクリックしたのか」と「場所」のデータをペアで入れているため、それらもパーティションに含めることを選択肢として検討しました。しかし、取得するデータ量、流入するデータの偏り等が当初は不明だったため、後からでも変更できるようにシンプルな「日付」のみにしました。 Amazon S3 に保存されたデータは、 Amazon Athena で検索し、BI ツールの Amazon QuickSight に読み込ませています。 Amazon QuickSight は全社員が閲覧できるように設定しており、工夫している点が 2つ あります。 Amazon QuickSight の認証方式を営業 / カスタマーサポートとエンジニアで分ける Amazon QuickSight インメモリエンジンの SPICE の利用を用途にあわせて絞る 1 については、営業やカスタマーサポートが Amazon QuickSight を利用する場合、各営業向けに発行した ID・パスワードを利用して直接ログインする方式にしました。一方で、エンジニアは IAM ユーザーを用いた認証方式にしました。これは、エンジニアが日頃 IAM ユーザーを利用しているため、 Amazon QuickSight 用のユーザー認証より利便性が高いと判断したためです。 2 については、SPICE の利用により Amazon QuickSight のパフォーマンスを向上させることが可能ですが、対象期間の全てのデータを読み込む必要があったため、SPICE を活用しての差分更新が難しい状況でした。また、高頻度にデータが生成されるたびに Amazon Athena で対象期間の全てのデータをスキャンすると、コストが高くなる懸念もありました。これらの懸念を SPICE の利用が必要な Amazon QuickSight のダッシュボードを絞ることで払拭できました。 また、 Amazon QuickSight では、ユーザーの料金が従量課金であり、上限価格も決まっているため、利用するユーザーが増加した場合でもコストを抑えて利用することが可能です。そのため、全社員が Amazon QuickSight を利用できる運用にすることができました。 導入効果 データ分析基盤を導入することで、下記の 3 つの効果を得ることができました。 •これまでのデータ活用は 1 ヶ月で数回程度の頻度に留まっていたが、 導入後は毎日データを活用 するように変化 •データを活用したカスタマーサポートによって、ユーザーによる サービス機能の利用数が 2 倍に増加 •カスタマーサポートチームがユーザーの 解約リスクを発見する時間を 8 割程度削減 し、 サービス利用の継続率 99％ に貢献 上記の結果、サービスを導入する店舗が増加する中でも、効率的かつ質の高いカスタマーサポートの提供や営業活動を実現することができました。 今後、サービスを導入する不動産仲介店舗が増加し、流入するデータ量が増加しても、AWS サービスを組み合わせたデータ分析基盤で、アクティビティデータを元にした適切なサービス提供のための分析が可能であると考えています。また、全社員が Amazon QuickSight を利用可能になった結果、データ分析における新たな観点や切り口の発見にも繋がっています まとめ 今回は Amazon QuickSight 、 Amazon Athena 、 Amazon Data Firehose などを用いて、データ分析基盤を構築した事例を紹介しました。 データ分析基盤を構築し、営業やカスタマーサポートの業務に活用することで、「提供している様々な機能を、より多くの SaaS ユーザーに活用してもらうこと」や「 SaaS ユーザーのデータに基づく営業活動」を実現しました。これにより、サービス導入後のチャーンレート (解約率) の改善や営業による売上向上に繋がっております。 また、今回の株式会社ｉｉｍｏｎ 様の取り組みは AWS Japan 主催の SaaS イベント AWS SaaS Builders Forum – Tech Leaders Meetup でも発表いただきました。 SaaS のデータ分析に対してデータ分析基盤を導入することにご関心のあるお客様は、ぜひ AWS までお問い合わせください。 本ブログの執筆はアカウントマネージャー 尾形 龍太郎及びソリューションアーキテクト 文珠 啓介が担当しました。

本記事は、2023年9月25日に公開された Designing a Cloud Center of Excellence (CCOE) を翻訳したものです。 多くの企業は、クラウド・センター・オブ・エクセレンス (CCOE) がクラウドへの移行や、より広範なデジタルトランスフォーメーションを加速させることができると認識しています。これらの CCOE はさまざまな形態をとりますが、それは各企業が克服すべき独自の課題を持っているためです。それでもなお、CCOE の活用には一定のパターンやアンチパターンが存在します。このブログ記事では、CCOE の目的、その構成と運営方法、そしてそれによって期待される影響について明確にすることを目指します。 なぜ CCOE を設立するのか？ まず、 CCOE はクラウドへの移行やデジタルトランスフォーメーションを進める上で必須のものではありません。その設置は組織の判断によるものであり、多くの組織的な意思決定と同様に、さまざまな要因に依存します。特に重要なのは、企業が変革の過程で直面する課題の種類ですが、セキュリティ戦略、中央集権化と分散化、人事方針、スキル、さらには組織内の政治的要素も考慮されます。 成功したデジタルトランスフォーメーションを主導した同僚たちとの会話から、CCOE と呼ばれるグループを持たない企業もあれば、その名前のグループはあるものの、単にクラウド関連の意思決定に関与するリーダーの緩やかな集まりに過ぎないケースもあることが分かりました。 CCOE は、多くの企業が従来のデータセンター中心でウォーターフォール型の働き方から、クラウド中心で俊敏性を重視したデジタルな働き方へ移行する際に直面する共通の課題に対する部分的な解決策です。その名が示す通り、CCOE は主にクラウドへの移行に焦点を当てており、必ずしも広範な変革全体を対象とするわけではありません。CCOE が典型的に対処する課題は以下の通りです： クラウド移行は、企業内の人々が不安を感じるために停滞することがよくあります。クラウドは彼らにとって新しく、クラウドを活用する深いスキルが不足しています。また、クラウドに関する誤った情報が広く流布し、人々を不安にさせています。CCOE は、クラウドを推進し、正確な情報を提供し、移行が成功するために必要な重要なスキルを供給することで、この問題を解決します。 企業内では全員が「日常業務」を抱えており、新しい取り組みに時間を割く余裕がありません。CCOE はクラウド移行専任チームとして、その優先順位と成功指標を明確化し、移行プロセスに集中します。 クラウド移行の初期には、多くの技術的・アーキテクチャ的・ビジネス的な意思決定が必要です。特に重要なのは、セキュアなランディングゾーンを構築してセキュリティ体制を確立し、その中で企業のアプリケーションを展開できるようにすることです。CCOE はこれらの初期の意思決定を行い、企業が適切な方向へ進むよう導きます。 CCOE は、組織のクラウド移行に推進力を与え、初期段階で技術的にガイドし、リスクを軽減します。変革の過程で必要となる技術的、文化的、組織的、プロセス的な変更を促進し、移行を可能にする初期の専門知識を提供します。万能の解決策ではありませんが、その目標は、移行の速度と品質を向上させることにあります。 CCOE は一時的な組織か永続的な組織か？ CCOE の目的はクラウドへの移行を促進することであり、移行は有限のタスクであるため、CCOE は一時的なチームとして考えるのが最適です。初期段階に必要な専門知識を提供しますが、最終的には IT 組織のほぼ全員がクラウドスキルを習得する必要があります。また、CCOE はクラウドのプロセスとパターンを構築しますが、クラウドが「新しい標準」（つまり、企業の将来のあらゆることを支える技術基盤）となるため、最終的には IT 組織全体がクラウドの使用に優れるようになります。CCOE は、IT 部門がクラウド中心の組織に変革するためのイネーブラーとして機能します。 これは混乱を招きやすい概念です。多くの人々は、CCOE を企業に代わってクラウドプラットフォームを管理する永続的な部門として誤解して捉えることがあり、これは「クラウドプラットフォームエンジニアリング」と呼ばれることもあります。しかし、時間の経過とともに、「クラウドプラットフォームエンジニアリング」は単なるプラットフォームエンジニアリングとなり、組織として最適な形で IT 組織に統合されます。CCOE にセキュリティチームの代表者がいたとしても、クラウドセキュリティは最終的にセキュリティの一部となり、IT セキュリティチーム内に配置されるべきです。 危険なのは、クラウド関連のタスクのために別個のサイロを作ることです。最終的に、企業のプラットフォームのほとんどまたはすべてがクラウド上にあると想定すると、IT の管轄は単にクラウド、エッジデバイス/エンドユーザーデバイス、およびそれらに関連するアプリケーションとデータで構成されることになります。 長期的な IT 組織は、IT に最適な組織構造を採用するべきです。 CCOE はクラウドガバナンスを行うのか？ IT ガバナンスには複数の側面があり、“はい”とも“いいえ”、とも言えます。一つは、投資、優先事項、支出、プロジェクト監視に関するガバナンスです。このようなガバナンスは通常 CCOE の業務範囲外となります。多くの場合、ビジネス上の優先事項は、使用する技術プラットフォームに依存せず、クラウドガバナンスは IT ビジネスガバナンスとは分離されていません。ビジネスの優先事項はあくまでビジネスの優先事項です。 一方で、コンプライアンス、標準、およびセキュリティに関連するガバナンスもあります。CCOE の役割には、この種のクラウドガバナンスに対する初期的なアプローチを作成することが含まれます。特に興味深いのは、そののガバナンスのほとんどを自動化し、それによってクラウドを利用するすべての人々を支援する点です。 具体的には、CCOE はクラウドで機能的な能力を構築するチームに役立つアーキテクチャパターンを開発を支援します。また、CI/CD (継続的インテグレーションと継続的デリバリー) のための初期ツールチェーンを組み立てたり、モニタリングを設定したり、セキュリティコントロールやポリシー適用をクラウドに導入します。さらに、クラウドコスト管理に関する初期的な意思決定を支援します。 CCOE は「有効化によるガバナンス」を実践し、明確なガードレール（安全策）を整備することで、組織がクラウドを安心して利用できる環境を創出します。 CCOE が担当しないことは何か？ 理論的に CCOE に入れることができるが、そうすべきではない関連機能とは何でしょうか？ そして、将来的に CCOE が不要になったとき、 IT 組織の他の部分でどのような機能が継続するのでしょうか？ ほとんどの組織は、プラットフォームエンジニアリングチーム (クラウドを活用して、デリバリーチーム (DevOps チーム) がソフトウェアを作成および提供するために使用できるセルフサービスプラットフォームを提供するチーム) を必要とします。プラットフォームエンジニアリングチームは、クラウド環境におけるポリシーの実施や管理、つまり将来的には“継続的コンプライアンス”と“継続的監査”となるものを担います。CCOE は初期段階でプラットフォームエンジニアリングを行う場合もありますが、これは最終的にはより広いエンジニアリング組織の一部となります。 非常に大規模で複雑な移行プロジェクトの場合、プロジェクトマネジメントオフィス (PMO) が必要となるかもしれません。主に文化的な理由から、これを CCOE とは別組織として維持することをお勧めします。CCOE は管理者や組織者ではなく、支援者と考えるべきです。CCOE は専門知識をしますが、業務を指示して管理する役割ではありません。 デジタルトランスフォーメーション (DX) には、組織の非常に上層部での連携が必要です。ここで言葉を慎重に選んでいるのは、クラウド移行自体が継続的な上層部での連携を必要とするのではなく、より包括的な変革、すなわちビジネスをデジタル企業として再定義し、組織全体にわたる文化的変革を実現することが本質的に重要だからです。これは通常、CCOE の責任範囲ではなく、組織の上層部の継続的な関与が必要となります。むしろ、このような変革を推進するには、従来型のCoEよりも、柔軟な方向性決定のメカニズムの方が適している可能性が高いでしょう。 現代の変革には、AI を中心としたアプローチやデータ駆動型の要素が不可欠です。これらの活動にはテクノロジーが深く関与していることは明白です。AI は比較的新しい分野であるため、何らかの CoE が必要になる可能性があります。このような専門知識は組織のどこに位置づけられ、変革においてどのような役割を果たすべきでしょうか。これらの点については、今後のブログ記事でさらに詳しく解説していく予定です。 CCOE に必要なスキルは何か？ CCOE には、その目標を達成するため、あるいは CCOE 設立の契機となった課題を克服するために必要なスキルが求められます。クラウド移行の推進を妨げる主な要因が技術的なものである場合、適切な技術的役割が複数存在します。セキュリティが大きな懸念事項である場合は、セキュリティスキルを確保してください。移行を加速させる最良の手段が企業全体での技術的または事業的な啓蒙活動である場合、それらが CCOE に必要な重要なスキルとなります。コンプライアンスや報告の初期体制を確立することが重要な場合も、同様の考え方が適用されます。 おわりに CCOE は、多くの企業がクラウド移行における一般的な障害を克服するために用いるツールです。これは、最終的にはより広範なIT組織に吸収される一時的なチームとして考えるのが最適です。一時的とはどのくらいの期間でしょうか？それは移行の規模と速度によって異なります。組織構造はデジタルトランスフォーメーションの進行に伴い変化する可能性が高く、CCOE はその変化を定義し推進する役割を果たします。しかし、CCOE の目的は移行を加速することであるため、長期的なクラウド運用に必要なすべてのスキルを備えようとして、過度に複雑化したり長時間を費やしたりするのは得策ではありません。私は実用的なアプローチを提案します。移行に直面している課題は何か？これらの課題を解決するために CCOE が持つべきスキルと責任の範囲は何か？これらの課題を克服することで、移行からより迅速なビジネス成果を得るにはどうすればよいか？このように考えることで、あなたの CCOE を定義することができます。 著者について Mark Schwartz はアマゾンウェブサービスのエンタープライズストラテジストであり、『The Art of Business Value』および『A Seat at the Table: IT Leadership in the Age of Agility』の著者です。AWS 入社前は、米国国土安全保障省の一部である US Citizenship and Immigration Service の CIO、Intrax の CIO、そして Auctiva の CEO を務めていました。彼は Wharton で MBA、Yale でコンピュータサイエンスの学士号 (BS) と哲学の修士号 (MA) を取得しています。 翻訳者について 鈴木 香緒莉は、プロフェッショナルサービスのアソシエイトアドバイザリーコンサルタントで、デジタル戦略立案とそれに即した組織の変革に注力しています。 CCoE や AI CoE などの xCoE の組成支援などに従事しています。

本稿は、2025年1月17日に AWS Media & Entertainment Blog で公開された “ Configure live captions with SyncWords and AWS Elemental Media Services ” を翻訳したものです。 コンテンツクリエーター、プロデューサー、または放送者にとって、ライブストリーミング用に迅速かつ正確な文字起こし、吹き替え、または翻訳を提供することは困難な場合があります。しかし、必要な最先端のサービスを構成して、時間とお金の両方を節約する方法について説明します。 はじめに 世界中の消費者は、外国語で作成されたコンテンツを含め、これまで以上に多くのコンテンツにアクセスできます。消費者の中には、もともと難聴者向けに設計されたキャプション/字幕 (以下、キャプション) や、視力の弱い人向けの音声解説などのアクセシビリティサービスに依存している人もいます。 これ以外にも、キャプションは聴覚や視力に関係なく、さまざまな環境でも役立ちます (たとえば、音声が適さない公共の場など) 。また、より多くのコンテンツにこのようなアクセシビリティサービスを提供するよう放送局に義務付ける法律も制定されています。 キャプションや外国語の翻訳を提供するビデオオンデマンド (VOD) コンテンツには、多くのワークフローとソリューションがあります。今では、手間をかけずにライブストリーミングで同じことを行うための新しい簡単な方法もあります。Amazon Web Services (AWS) Elemental Services とライブキャプションサービス ( SyncWords ) を設定して、AI が生成する自動ライブキャプションと吹き替え (複数言語への翻訳を含む) を有効にする方法を説明します。 コンテンツ制作者、プロバイダー、放送局がライブ放送で直面する課題は、カメラキャプチャから画面表示までの時間が非常に速いため、正確でタイムリーなキャプションを生成することです。 現在、これを実現する1つの方法は、トランスクリプターに音声を聞いてもらい、話されていることをタイプして、それをメディアワークフローに反映させることです。これにはコストがかかり、人為的ミスが発生しやすく、テキストと音声の同期が困難になる可能性があります。 ライブ放送中、キャプションの表示は通常、ビデオ/オーディオよりも4〜8秒遅れます。一方、単語や文章の一部のスペルを間違えたり、完全に見落とされたりすることがあります。これらの問題により、エンドユーザーエクスペリエンスが低下します。例としては、プレゼンターがあるストーリーから別のストーリーにすばやく移動するライブニュースがあります。アクセシビリティサービス (キャプションなど) が数秒遅れると、動画が次のニュース記事に移ってから数秒後に、記事に関するテキストが表示されることがあります。 アクセシビリティサービスのユーザーに優れたエクスペリエンスを提供するには、タイミングと正確さが重要な要素です。これは、外出先や騒がしい環境でキャプションや字幕付きのライブストリーミングを視聴するモバイル視聴者に特に当てはまります。 タイミングと正確性の課題に加えて、放送局はライブキャプションを放送に挿入する際に大きなハードルに直面することがよくあります。多くの場合、ビデオ投稿段階の上流には専用のハードウェアが必要です。また、ソフトウェアベースのエンコーダーを使用して、 EIA-608 、 テレテキスト 、 digital video broadcasting (DVB) 字幕 などの特定のTVプロトコルにしたがってトランスポートストリームにユーザーデータを挿入する場合もあります。 ソリューション しかし、解決策はあります。 AWS Elemental MediaLive と AWS Elemental MediaPackage と SyncWords では、正確で同期された翻訳済みのキャプションを実現するための効率的なアプローチが提供されています。HTTP live streaming (HLS) のマニフェストの構造を活用することで、放送局は AI 機能をライブストリームにシームレスに統合できます。これにより、面倒なハードウェアが不要になり、プロセス全体が合理化されます。 AWS Elemental Link ( エンコーディングデバイス) 、AWS Elemental MediaLive、 SyncWords の AI キャプションサービス 、AWS Elemental MediaPackage を使用して、ライブキャプション用のクラウド中心のワークフローを設定する方法について説明します。 前提条件 このワークフローでは MediaLive サービスと MediaPackage サービスを使用します。AWSコンソールを使用してこれらのサービスのセットアップに精通していることを前提としています。そうでない場合は、 「AWS Elemental MediaLive の開始方法」 および 「AWS Elemental MediaPackage の開始方法」 を参照してください。 また、SyncWords のアカウントを持っていることも確認する必要があります。SyncWords に直接お問い合わせいただくか、 AWS マーケットプレイス で購入してください。 ワークフローの概要では、AWS Elemental Linkを示しています。これは、ビデオの暗号化とキーローテーションを備えた、高い弾力性と組み込みのセキュリティを備えたビデオの転送に最適な小型のハードウェアデバイスエンコーダーです。この例では、コントリビューションのソースフィードが Link に接続され、ソースストリームがエンコードされ、イーサネット接続を介して MediaLive に直接プッシュされます。Link の使用は必須ではありませんが、ソースをMediaLiveの入力として表示するためのプラグアンドプレイ機能を備えているため、使用するには最適なユニットです。 MediaLive で受け付けられるその他の入力は、MediaLive ユーザーガイドの 「セットアップ：入力の作成」 セクションにあります。 図 1: ワークフローの概要 設定 このサンプルワークフローは、MediaLive、SyncWords、および MediaPackage サービスで構成されています。 AWS マネジメントコンソール にログインし、AWS Elemental MediaPackageにアクセスして開始してください。 ステップ 1: まず MediaPackage でチャネルを作成します (ここでは v2 を使用) 。 チャネルグループを作成します。 次に、チャネルを作成します。MediaPackage v2 チャネルを作成するときは、SyncWords からのストリームアクセスを許可するカスタムチャネルポリシーを作成する必要があることに注意してください。 Publishing HLS streams from SyncWords Live to your AWS MediaPackage v2 Channel のポリシーを定義する方法について説明します。 チャネル内で、[ Create endpoint ] ボタンをクリックして HLS Origin エンドポイントを作成します。これは、SyncWords からストリームがプッシュされる先のエンドポイントです。 エンドポイントの[ Settings ]ページに、ステップ 2 で SyncWords HLS 出力を設定するために必要な MediaPackage HLS インジェストエンドポイント URL が表示されます。それを書き留めておいてください。 HLS Origin エンドポイントの[ Segment settings ] で [ Use audio rendition group ] ボックスが選択されていることを確認します。 注: MediaPackage v1 で設定する場合、カスタムチャネルポリシーを設定しないため異なります。代わりに、ステップ 2 で SyncWords HLS 出力を設定するときに、MediaPackage v1 HLS インジェストエンドポイントの URL、ユーザー名、およびパスワードを使用してください。 ステップ 2: SyncWords チャネルを設定します。 SyncWords のアカウントにログインします。 [ Services ] または [ Events ] に移動し、[ Create Service ] または [ Schedule an Event ] をクリックします。ここでは、図 2 に示すように、サービス設定を使用しています。 Service Nameを入力し、[ Create Service ] をクリックします。 図 2: SyncWords の [ Create Service ] 設定のスクリーンショット [ HLS Push」タイプとして、MediaLive が HLS をストリーミングするための入力エンドポイントを作成します。これにより、SyncWords サービスエンドポイントにアクセスするための一意の URL エンドポイント、ユーザー名、およびパスワードが自動的に生成されます。 注:ステップ 3 で MediaLive を設定するときは、URL、ユーザー名、およびパスワードの設定が必要になります。 MediaLiveからこのエンドポイントにストリーミングすると、接続ステータスが [ Not Connected ] から [ Connected ] に変わります。 図 3: SyncWords の [ Input Media ] 設定のスクリーンショット [ Transcript ] セクション (図4) で、Transcript Type を [ Automated (AI) ] に設定します。次に、ソースオーディオの認識に使用する Speech Engine とソース言語を選択します。必要に応じて、音声エンジンが問題を起こす可能性のあるカスタム用語 (名前や略語など) には、Add Dictionary を使います。 [ More Options ] で追加の設定を選択します。注:オプションは、選択した Speech Engine によって異なる場合があります。 図 4: SyncWords の [ Transcript ] 設定のスクリーンショット [ Translations ] セクション (図5) に、翻訳したい言語を追加します。これにより、エンドユーザークライアントにキャプションとして表示される出力言語が定義されます。MT Engine のドロップダウンリストから、希望する翻訳エンジンを選択します。 吹き替えオーディオトラックを作成したい言語の [ Audio ] ボックスを選択し、必要な吹き替え音声設定 (方言、性別、話者、話率) を選択します。 吹き替えトラックとミックスするオリジナル音声の音量を 0～50 の間でパーセンテージで設定します。 自動翻訳の精度を上げるには、カスタム用語集を追加し、ソース言語、ターゲット言語、カスタム用語集の各フィールドに入力します。翻訳が難しい用語や、ターゲット言語に翻訳されたバージョンがない用語には、用語集が必要になることがあります。用語集プリセットも作成できます。その方法については、 「 How to Create a Translation Glossary 」 で説明されています。 図 5: SyncWords の [ Translations ] 設定のスクリーンショット [ Outputs ] セクションで HLS 出力を作成します (図 6)。ドロップダウンから [ AWS MediaPackage ] と[ v2 ] を選択します。 MediaPackage v2 チャネルの [ Settings ] ページから HLS インジェストエンドポイント URL をコピーします (ステップ 1 を参照) 。 バッファサイズを設定します。注:翻訳を含むストリームでは、言語によって単語の順序が異なるため (ドイツ語では動詞が文の末尾にあることが多い) 、翻訳を処理するには少なくとも一文が必要です。 図 6: SyncWords の [ HLS Output ] 設定のスクリーンショット [ Save ] をクリックします (ボタンが [ Saved ] に変わります) 。必須の設定が欠けている場合は、[ Some data is invalid. ] という警告が表示され、感嘆符の付いた赤い円がその設定場所を示します。スクロールして探す必要があるかもしれません。 これで SyncWords サービスの設定が完了し、開始する準備が整いました。 ステップ 3: HLS を SyncWords チャネルにプッシュするために MediaLive チャネルを設定します。 MediaLive の入力とチャネルを作成します。 HLS 出力グループを追加し、[ Credentials (optional) ] セクションで [ Create parameter ] を選択します。URL、ユーザー名、パスワードにはステップ 2 で SyncWords が自動生成した設定値を使用します。 パラメータに名前を付けます。MediaLive チャネルが作成されると、このパラメータは AWS Systems Manager パラメータストアに自動的に保存されます。MediaLive チャネルをステップ2で作成したSyncWordsチャネルのソースとして受け入れるには、認証情報が必要です。 図 7: AWS Elemental MediaLive の [ HLS output group ] 設定のスクリーンショット MediaLive チャネルで HLS グループと HLS 出力のセットアップを続けます。設定が完了したら、 Create channel ボタンをクリックします。 ステップ 4: サービスの開始と監視: MediaLive チャネルを起動し、SyncWords サービスの設定で [ Start Service ] をクリックします。MediaLiveチャネルの状態が [ Running ] に変わり、SyncWords GUI の接続ステータスが [ Connected ] になるのを待ちます。注:起動フェーズには数分かかる場合があります。 MediaPackage Origin エンドポイントセクションの [ Preview ] リンクをクリックして、出力を監視してください。チャネルが実行されると、字幕と音声言語のリストが表示されます。お好みの再生クライアント (通常は再生クライアントの右下隅にあります) でキャプションと吹き替え言語トラックを選択してください。 注：SyncWords ライブワークフローでスタンドアロン字幕ファイル (SRT または VTT) が必要な場合は、ライブサービスがアーカイブされると、SyncWords Liveダッシュボードで直接利用できるようになります。 クリーンアップ 不必要なリソースの使用とコストを避けるために、使用していない MediaLive と SyncWords のチャネルを停止または削除します。 まとめ 字幕やキャプションのようなアクセシビリティサービスは、より多く、より質の高いものが求められています。AWS Elemental Media Services と SyncWords の AI キャプションおよび翻訳サービスを使用して、ライブキャプションや吹き替えオーディオトラックを作成することで、コンテンツを充実させることができます。 実際にお試しいただきライブ放送のクラウド環境における文字起こし、翻訳、吹き替えの効率的な実装を確認ください。 また、キャプションと翻訳の精度の高さ、エンドユーザーへのタイムリーな表示にもご注目ください。 AWS の担当者 にご連絡いただければ、当社がどのようにお客様のビジネスを加速させることができるかご説明致します。 参考リンク Multi-language automatic captions and audio dubbing made possible for live events with AWS Media Services and SyncWords Amazon Cloudfront – Content Delivery Network (CDN) AWS Elemental Live – Live streaming encoder Automated Captions and Translations Using AWS Elemental AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの金目, 井村が担当しました。原文は こちら をご覧ください。

本稿は、2024年12月19日に AWS Media & Entertainment Blog で公開された “ Delivering low-latency captions and voice translation for live sports, news, and OTT platforms with SyncWords and AWS ” を翻訳したものです。 本稿は、SyncWords の VP of Business Development and Strategy である Giovanni Galvez と共同執筆しました。 お客様からクラウドの自動音声認識 (Automatic Speech Recognition : ASR) テクノロジーを活用しながら、特にスポーツ中継やニュースのライブ配信で、低遅延でキャプションを実現する最善の方法について問い合わせがありました。AWS と SyncWords は、この課題に取り組み、生放送用のキャプションの埋め込みと音声翻訳を生成するために、 Secure Reliable Transport (SRT) プロトコルと SyncWords を使用して、安全で低レイテンシーのキャプション埋め込みワークフローを可能にしました。これらはハードウェアを追加することなく実現されています。 以前のブログでは、 HTTP Live Streaming (HLS) ワークフローをデプロイする生放送向けのキャプションと字幕の作成を自動化するために開発された Amazon Web Services (AWS) と SyncWords の実装方法について紹介しています。 Multi-language automatic captions and audio dubbing made possible for live events with AWS Media Services and SyncWords と Translate live sports automatically to reach international fans with AWS Media Services and SyncWords は、これらの実装を紹介しており、このブログを読む前に読んでおくと、より理解が深まります。 次のワークフロー図は、SyncWords の SRT ベースのソリューション、映像伝送のための AWS Elemental MediaConnect 、映像処理の AWS Elemental MediaLive 、オリジンおよびパッケージングサービスの AWS Elemental MediaPackage 、配信のための Amazon CloudFront  を使用した、自動化された低レイテンシーのキャプション埋め込みと音声翻訳のデプロイを示しています。 SyncWords は SRT の取り込みと出力をサポートし、クラウド内の動画処理ワークフローのための AWS Media Services とネイティブに統合されたクラウドベースの安全なキャプションおよび音声埋め込みソリューションをユーザーに提供します。 MediaLive が SRT Caller 入力 をサポートしたことで、SyncWords のキャプション付きのライブストリームを MediaLive に直接取り込むことができます。すべてのコンポーネントが同じ AWS リージョンにあり、MediaConnect が他のワークフロー要件に必要ない場合は、MediaConnect をバイパスできる可能性があります。以下は、MediaLive SRT Caller 入力を使用した簡略化されたワークフロー図です。 MediaConnect とシームレスに連携し、 AWS グローバルネットワーク を活用することで、クラウドベースの自動音声認識 (ASR)、SyncWords による費用対効果の高いキャプション埋め込みおよび音声翻訳サービスを利用できるようになり、また、MediaConnect による安全で低レイテンシーな伝送により、キャプション付ストリームを世界中の顧客やビジネスパートナーに配信できるようになります。   このワークフローを AWS にデプロイすると、次のような利点があります。 1. 複数の解像度とコーデックのネイティブサポート CEA-608 / CTA-708 キャプションプロトコルを使用して、SD、HD、および UHD (4K) 解像度のキャプションを SRT ストリームに挿入できます。HEVC および AVC ビデオコーデックと互換性があります。キャプションデータをエレメンタリービデオストリームに挿入するときにトランスコーディングは必要なく、1 秒未満で処理されます。  2. Amazon Elastic Kubernetes Services (Amazon EKS) によるスケールするキャプション処理 SyncWords のキャプションと音声翻訳サービスは AWS のサービス上に構築されており、Amazon EKS を用いて自動的にスケーリングします。また、二重パイプラインの冗長性をサポートするためにMediaLive と統合されています。お客様は、オンプレミスハードウェアの管理やプロビジョニングを負担することなく、キャプションサービスに集中できるようになります。サービスの冗長性とスケーラビリティは、高品質で信頼性の高いライブ体験を顧客に提供します。 3. MediaConnectと SRT を使った収益化 放送局は MediaConnect と SRT プロトコルを最大限に活用し、母国語を話す世界中の視聴者に向けてニュースやスポーツのキャプション付きライブストリームを安全に伝送し収益化することができます。さらに、 MediaConnect Entitlements を使用して、世界中のビジネスパートナーや顧客にコンテンツを配信できます。 まとめ このブログでは、AWS サービスと SyncWords を使用して、回復力のある低レイテンシーの SRT ストリーミングワークフローでライブイベントの自動キャプションを有効にする方法について説明しました。AWS を使用したライブイベントパイプラインの作成方法は、 AWS でのライブストリーミング ソリューションを参照してください。さらに、AWS Media Services を使い始めることに興味がある場合は、 製品ページ をご覧ください。ライブイベントにキャプションソリューションを統合するためのドキュメントについては、 SyncWords  をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの金目, 石井が担当しました。原文は こちら をご覧ください。

このブログ記事は Security Specialist Solutions Architect の Bryant Pickford と Sr. Cloud Infrastructure Architect の Umesh Kumar Ramesh、Sr. Product Manager の Kevin Lee によって書かれました。 2024年12月2日：この投稿は WAFV2 への移行を反映するように更新され、AWS WAF Classic のパートナーマネージドルールからパートナーマネージドルール（wafv2）への 1:1 のマッピングする内容が追加されています AWS WAF Classic のサポートは、2025 年 9 月 30 日に終了します。 2019 年 11 月、Amazon はより使いやすく豊富な機能を提供する AWS Web アプリケーションファイアウォール (WAF) の新しいバージョンを立ち上げました。この投稿では AWS WAF Classic から新しい AWS WAF に移行する方法をいくつかご紹介します。 AWS WAF のマネージドルール は AWS WAF で最も強力な機能の 1 つです。サービスでルールを直接作成または管理する必要なく、アプリケーションを保護するのに役立ちます。新しいリリースには、他の拡張機能とAWS WAF用の新しいAPIのセットが含まれています。 この作業を開始する前に、 AWS WAF がどのように機能するか を復習することをお勧めします。既に AWS WAF に精通している場合はスキップしてください。AWS WAF を初めて使用する、AWS WAF を展開するためのベストプラクティスを知りたい場合は、 AWS WAFを実装するためのガイドライン を読むことをお勧めします。 AWS WAFで変更されたもの こちらが AWS WAF の変更点のまとめです。 AWS Managed Rules for AWS WAF： 一般的な Web の脅威に対する保護を提供し、VPN、プロキシ、および TOR ネットワークに由来するボットとトラフィックをブロックするための Amazon IP reputation list と Anonymous IP list が含まれています 新しい API (wafv2)： 2 つではなく単一の API セットを使用して、すべての AWS WAF リソースを構成できます ( WAF および WAF-regional ) 簡素化されたサービス制限： Web ACL 毎により多くのルールを提供し、より長い正規表現パターンを定義できます。条件ごとの制限は排除され、Web ACL キャパシティユニット (WCU) に置き換えられました ドキュメントベースのルールライティング： JSON 形式のルールを Web ACL に直接書き込み表現できます。個々の API を使用して異なる条件を作成し、それらをルールに関連付け、コードを大幅に簡素化し、保守可能にする必要はなくなりました ネストと完全な論理操作のサポート： 複数の条件を含むルールを含むルールを書くことができます。また、[ a および not ( b または c ) ]などのステートメントを作成して、論理操作をネストすることもできます IP セットの可変 CIDR 範囲サポート： ブロックする IP 範囲を定義する柔軟性が高まります。新しい AWF WAF は IPv4 は /1 から /32、IPv6 は /1 から /128をサポートしています チェーン可能なテキスト変換： 受信トラフィックに対するルールを実行する前に、複数のテキスト変換を実行できます 改良されたコンソール体験： 視覚的なルールビルダーの機能と、より直感的なデザインを備えています Condition タイプの AWS CloudFormation サポート： JSON で書かれたルールは YAML 形式に素早く変換できます より高いクォータ： Web ACL 毎のルール、長い正規表現パターン、および条件ごとの制限を置き換える Web ACL キャパシティユニット (WCU) 設定可能なタイムウィンドウ： レートベースルールにおいて、リクエスト集約のためのタイムウィンドウの設定ができるようになりました。お客様は以前からサポートされていた 5 分に加えて、1 分、2 分、10 分のタイムウインドウを選択できるようになりました より低いレートベースの制限： レートベースルールにおいて、しきい値を低く設定できるようになりました。お客様は以前の最低 100 リクエストと比較して、評価ウィンドウ毎に最低で 10 リクエストから、レートベースルールを構成できるようになりました 多くの変更が導入されましたが、あなたがすでによく知っている概念と用語は同じままです。以前の API は AWS WAF Classic にリネームされました。 AWS WAF Classic の下で作成されたリソースは、新しい AWS WAF と互換性がないことに注意してください。 Web ACL キャパシティユニットについて Web ACL キャパシティユニット (WCU) は、2019 年 11 月に AWS WAF に導入された新しい概念です。WCU は Web ACL に関連付けられたルールを実行するために、必要な動作リソースを計算および制御するために使用される測定値です。WCU は Web ACL に追加できるルールの数を視覚化および計画するのに役立ちます。Web ACL が使用する WCU の数は、追加する ルールステートメント によって異なります。各 Web ACL の最大 WCU は 1,500 であり、ほとんどのユースケースで十分な量です。WCU がどのように機能するか、 各タイプのルールステートメントがどのように WCU を消費するか を十分に理解されておくことをお勧めします。 新しいAWS WAFへの移行を計画します AWS WAF Classic から新しい AWS WAF に移行するために役立つ 新しい API とウィザードを発表しました。AWS WAF Classic の下で Web ACL を解析し、展開した新しい AWS WAF の下に同等の Web ACL を作成する CloudFormation テンプレートを生成します。このセクションでは、ウィザードを使用して移行を計画する方法について説明します。 始める前に知っておくべきこと 最初に、Migration ウィザードは既存の Web ACL を調べます。Web ACL に関連付けられた変換ルール、IPセット、正規表現パターンセット、文字列マッチフィルター、およびアカウント所有のルールグループを調査して記録します。ウィザードを実行しても、既存の Web ACL の構成またはその Web ACL に関連するリソースを変更・削除することはありません。終了すると、新しい AWS WAF で使用するために変換された同等の Web ACL、ルールセット、フィルター、およびグループを含む CloudFormation テンプレートが S3 バケット内に生成されます。新しい AWS WAF で Web ACL を再現するには、テンプレートを手動で展開する必要があります。 次の制限に注意してください。 同じアカウントにある AWS WAF Classic のリソースのみが移行されます IP セットや正規表現パターンセットなど、共有リソースを参照する複数の Web ACL を移行すると、新しい AWS WAF の下で複製されます レートベースのルールに関連する条件は引き継がれません。移行が完了したら、ルールと条件を手動で再作成してください AWS マーケットプレイスで入手したマネージドルールは引き継がれません。一部のパートナーは、新しい AWS WAF で購読できる同等のマネージドルールを用意しています Web ACL との紐付けの設定は引き継がれません。これは意図的に行われ、移行が本番環境に影響を与えないようにしました。すべてが正しく移行されていることを確認したら、Web ACL をリソースに再度紐付けてください Web ACL のログはデフォルトで無効になります。切り替える準備ができたら、ロギングを再度有効化してください CloudWatch アラームを設定している場合は引き継がれません。 Web ACL が再作成されたら、再度アラームをセットアップする必要があります Migration ウィザードを使用して AWS WAF のセキュリティオートメーション を移行できますが、バックグラウンドで使用される Lambda 関数を変換しないためお勧めしません。代わりに、新しいソリューション（バージョン 3.0 以降）を再配置します。こちらは新しい AWS WAF と互換性があるように更新されています。 パートナーマネージドルールとのマッピング AWS マーケットプレイスのパートナーマネージドルールを AWS WAF Classic で使用するお客様のために、一部のセラーは新しい AWS WAF で同等のマネージドルールグループをリリースしています。移行中、次のマッピングガイダンスを使用して、新しい環境でこれらに再登録する必要があります Cyber Security Cloud Managed Rules for AWS WAF – HighSecurity OWASP Set: AWSManagedRulesCloudSecurityOWASPSet にマップします F5 Bot Detection Signatures for AWS WAF: AWSManagedRulesF5BotProtection にマップします F5 Web Application CVE Signatures for AWS WAF: AWSManagedRulesF5CVE にマップします F5 Rules for AWS WAF – API Security Rules: AWSManagedRulesF5APISecurityRules にマップします AWS WAF – Web Exploits Rules by F5: AWSManagedRulesF5WebExploitsOWASP にマップします Fortinet Managed Rules for AWS WAF – API Gateway: AWSManagedRulesFortinetAPISecurity にマップします Fortinet Managed Rules for AWS WAF – Complete OWASP Top 10: AWSManagedRulesFortinetOWASPTop10 にマップします 他のルールセットについては、AWS マーケットプレイスのセラーに新しい AWS WAF での提供を確認してください。移行には手動での対応が必要ですが、新しい AWS WAF は、より堅牢でスケーラブルで管理可能なソリューションを提供します。 AWS Firewall Manager と Migration ウィザードについて Migration API とウィザードの現在のバージョンは、AWS Firewall Manager が管理するルールグループを移行しません。Firewall Manager が管理する Web ACL でウィザードを使用する場合、関連するルールグループは引き継がれません。ウィザードを使用して Firewall Manager が管理する Web ACL を移行する代わりに、新しい AWS WAF のルールグループを再作成し、既存のポリシーを新しいポリシーに置き換えることができます。 注意 ：過去には、ルールグループは Firewall Manager の下に存在していた概念でした。ただし最新の変更により、AWS WAF の下にルールグループを移動しました。機能は同じままです 新しい AWS WAFに移行する Web ACL を AWS WAF Classic から新しい AWS WAF に移行するために、 Migration ウィザード を使用して実行可能な AWS CloudFormation テンプレートを作成します。このテンプレートは、AWS WAF ルールと対応するエンティティの新しいバージョンを作成するために使用されます。 1.新しい AWS WAF コンソールから、 Switch to AWS WAF Classic を選択して AWS WAF Classic に移動します。ウインドウの上部にメッセージボックスがあります。メッセージボックスの migration wizard のリンクを選択して、移行プロセスを開始します 図1：Migration ウィザードを開始 2. 移行するWeb ACLを選択します 図2：移行する Web ACL を選択 3. Migration ウィザード用の新しい S3 バケットを指定して、生成する AWS CloudFormation テンプレートを保存します。S3 バケット名は接頭辞 AWS-WAF-Migration- から始める必要があります。例えば AWS-WAF Migration-helloworld のように名前を付けます。デプロイするリージョンにテンプレートを保存します。例えば us-west-2 に Web ACL がある場合、us-west-2 に S3 バケットを作成し、Stack を us-west-2 にデプロイします。 Auto apply the bucket policy required for migration を選択して、API が S3 バケットにアクセスするために必要な権限を構成するために、移行に必要なバケットポリシーを適用します。 移行できないルールを処理する方法を選択してください。 Exclude rules that can’t be migrated（移行できないルールを除外する） 、 Stop the migration process if a rule can’t be migrated（ルールを移行できない場合は移行プロセスを停止する） のどちらかを選択します。ウィザードがルールを移行する能力は、前述の WCU 上限の影響を受けます。 図3：移行オプションを構成 注意： 必要に応じて次のコードを実行して、必要なアクセス許可を構成するために、以下のポリシーで手動で S3 バケットをセットアップできます。これを行う場合は Use the bucket policy that comes with the S3 bucket（S3 バケットに付属するバケットポリシーを使用する） を選択します。 <bucket_name> および <customer_account_id> をあなたの情報に置き換えることを忘れないでください 全ての AWS リージョン（waf-regional）の場合： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf-regional.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<BUCKET_NAME>/AWSWAF/<CUSTOMER_ACCOUNT_ID>/*" } ] } Amazon CloudFront（waf）の場合： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<BUCKET_NAME>/AWSWAF/<CUSTOMER_ACCOUNT_ID>/*" } ] } 4. 構成を確認し Start creating CloudFormation template を選択して、移行を開始します。AWS CloudFormation テンプレートを作成するには、Web ACL の複雑さによりますが、約 1分ほどかかります 図4：CloudFormation テンプレートを作成 5. 完了したら、生成されたテンプレートファイルを確認して、そうしたい場合は変更することができます。（例えばルールを追加することができます）続行するには Create CloudFormation stack（CroudFormation スタックの作成） を選択します。 図5：テンプレートを確認 6. AWS CloudFormation コンソールを使用して、Migration ウィザードによって作成された新しいテンプレートをデプロイします。 Prepare template から Template is ready を選択します。 Template source では Amazon S3 URL を選択します。デプロイする前に、テンプレートをダウンロードしてレビューして、リソースが期待通りに移行されていることを確認することをお勧めします。 図6：スタックを作成 7. Next を選択し、ウィザードの先に進みスタックを展開します。正常に作成されたら、新しい Web ACL を確認してリソースに関連付けることができます。 図7：移行を完了 移行後の考慮事項 移行が正しく完了したことを確認した後、新しい AWS WAF 機能のいくつかを活用するために構成を再検討することをお勧めします。 例えばアプリケーションのセキュリティを改善するために、Web ACL に AWS Managed Rule を追加することを検討してください。AWS Managed Rules は 3 つの異なるタイプのルールグループ を備えています。 ベースライン ユースケース別 IPレピュテーションリスト ベースラインルールグループは、悪意のある入力がアプリケーションに入力される前に停止したり、管理ページへのアクセスを防ぐのに役立つなど、さまざまな脅威に対する一般的な保護を提供します。ユースケース別のルールグループは、多くの異なるユースケースと環境に追加の保護を提供し、IP レピュテーションリストはクライアントのソース IP に基づいて脅威インテリジェンスを提供します。 また、古いルールの一部を再検討し、ルールを書き換えたり古いルールを削除したりすることで、最適化することを検討するべきです。例えば OWASPトップ 10 Web アプリケーションの脆弱性ホワイトペーパー から AWS CloudFormation テンプレートを展開してルールを作成した場合、AWS Managed Rules に置き換えることを検討するべきです。ホワイトペーパー内で見つかった概念は依然として適用されており、独自のルールを書くのに役立つ場合がありますが、テンプレートによって作成されたルールは、AWS Managed Rule に置き換わっています。 JSON を使って新しい AWS WAF で独自のルールを書くことについては、 Protecting Your Web Application Using AWS Managed Rules for AWS WAF ウェビナーをご視聴ください。それに加えて、 サンプル JSON/YAML を参照することができます。 移行後に CloudWatch メトリクスを再訪し、必要に応じてアラームを設定します。アラームは Migration API によって引き継がれておらず、メトリクス名も変更された可能性があります。また、 ロギングの構成を再度有効にする 必要があり、以前の Web ACL で持っていた可能性のあるフィールドの編集も必要です。 最後に、この時間を使用してアプリケーションチームと協力し、セキュリティポスチャを確認してください。アプリケーションによって頻繁に解析されているフィールドを調べ、それに応じて入力をサニタイズするルールを追加します。アプリケーションのビジネスロジックがそれらを処理できなかった場合、これらのケースをキャッチするためのエッジケースを確認し、ルールを追加します。また、リソースアソシエーションを新しい Web ACL に変更する際に、少し混乱がある可能性があるため、スイッチするときにアプリケーションチームと調整する必要があります。 AWS WAF を使用してコスト効率の高い Web アプリケーションを保護するための詳細については、 Cost-effective ways for securing your web applications using AWS WAF のブログをチェックしてください。 結論 この投稿が AWS WAF Classic から、新しい AWS WAF への移行を計画するのに役立つことを願っています。 AWS Managed Rule などの新しい拡張機能を備えており、独自のルールを作成する柔軟性を提供するため、新しいAWS WAFエクスペリエンスを探索することをお勧めします。 このブログは「 Migrating your rules from AWS WAF Classic to the new AWS WAF 」という記事の翻訳となります。 翻訳は Senior Solutions Architect の森が担当しました。

Amazon Web Services (AWS) は、ポスト量子暗号 (PQC:Post-Quantum Cryptography) への移行を進めています。AWS の他のセキュリティおよびコンプライアンス機能と同様に、PQC は 責任共有モデル の一部として提供されます。つまり、一部の PQC 機能はすべてのお客様に対して透過的に有効化されますが、他の機能はお客様が要件を満たすために選択して実装できるオプションになります。この移行は、インターネットなどの信頼されていないネットワークを介して通信するシステムから段階的に行われます。 暗号解読可能量子コンピュータ (CRQC: Cryptographically Relevant Quantum Computer) と呼ばれることもある大規模な量子コンピュータの脅威は、現在使用されている公開鍵暗号アルゴリズムを解読できる可能性があることです。これらのアルゴリズムは、ほとんどの通信プロトコルとデジタル署名スキームで使用されています。過去 8 年間、AWS は他の業界リーダー、政府機関、学術機関とともに、量子コンピューティングに対して耐性のある新しい公開鍵暗号アルゴリズムの提唱、研究、提案に取り組んできました。お客様は AWS が行う暗号化処理によってデータを保護しているため、私たちは早期から対策に着手し、将来的な PQC への移行における労力と影響を最小限に抑えました。AWS で使用されている公開鍵暗号を解読できるほど強力な量子コンピュータが現在存在する証拠はありませんが、私たちはそれを待っているつもりはありません。将来におけるお客様のデータのセキュリティを守るため、今のうちから対策を講じることを選びました。 この投稿では、AWS が PQC への移行の道のりがどこまで進んでいるかを簡潔にご紹介し、今後の方向性についてお伝えします。 過去 5 年間、私たちは米国国立標準技術研究所 (NIST) が評価中の PQC アルゴリズムの初期バージョンを、オープンソースライブラリと重要なセキュリティサービスの両方で展開し、お客様が PQC への移行によるパフォーマンスへの影響をテストできるようにしてきました。例えば、アルゴリズム実装のオープンソースライブラリ ( AWS-LC )、TLS 実装 ( s2n )、および AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager 、 AWS Certificate Manager (ACM) などのコアセキュリティサービスには、2019 年から NIST PQC 提案アルゴリズムの鍵カプセル化の実装が含まれています。 2024 年 8 月 13 日、 NIST は 3 つの新しいポスト量子暗号 (PQC:Post-Quantum Cryptography)の暗号アルゴリズムを連邦情報処理標準 (FIPS) として発表しました 。これは、2016 年に開始された NIST の量子コンピュータ PQC 標準化プロセスの結果です。AWS の従業員も、この 3 つの新 FIPS 標準を含む多くの暗号化スキームの提案に携わっています。 FIPS 203, Module-Lattice-based Key-Encapsulation Mechanism Standard (ML-KEM) 、当初 CRYSTALS-Kyber という名前で提出されたモジュール格子ベースの KEM FIPS 204, Module-Lattice-based Digital Signature Standard(ML-DSA) 、当初 CRYSTALS-Dilithium として提出されたモジュール格子ベースのデジタル署名アルゴリズム FIPS 205, Stateless Hash-Based Digital Signature Standard(SLH-DSA) 、SPHINCS+ として始まったステートレスハッシュベースの署名方式 多くのお客様は、量子コンピュータ時代における安全な暗号化の標準化プロセスを注視してきました。これには、米国政府の Commercial National Security Algorithms (CNSA) Suite 2.0 の PQC 採用に関する要件や、欧州委員会の Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography が含まれます。 第 1 ラウンドのPQCアルゴリズムが標準化されたことから、私たちは長期的なサポートのためにそれらを実装し始めることができます。暗号化操作を代行するサービスとオープンソースツールに依存しているお客様に、シームレスな移行を提供するために、PQC を実装するアプローチは次のとおりです。 AWS は今後数年にわたり、PQC への移行に多層的なアプローチを取ります。同時に進行するワークストリームは次のように定義しています。 ワークストリーム 1 : 既存システムの棚卸し、新しい標準の特定と開発、テスト、移行計画を行います。最初の一連のアルゴリズム標準は公開されましたが、PQC を特定のアプリケーションやプロトコルに統合するための互換性確保のため、追加の標準が今後公開される予定です。 ワークストリーム 2 : AWS に送信されるお客様データの長期的な機密性を確保するため、公開 AWS エンドポイントに PQC アルゴリズムを統合します。 ワークストリーム 3 : ソフトウェア、ファームウェア、文書の署名などの機能に使用される、新たなポスト量子の長期的な Root of Trust (信頼の起点) をお客様がデプロイできるよう、AWS 暗号化サービスに PQC 署名アルゴリズムを統合します。 ワークストリーム 4 : サーバーやクライアント証明書の検証など、セッションベースの認証に、ポスト量子署名を使用できるよう、AWS サービスに PQC 署名アルゴリズムを統合します。 ワークストリーム 1 この取り組みは、私達が現在進めている移行計画の外観であると捉えています。すでに私たちの全体的な戦略に反映されており、お客様のニーズに基づいて移行の優先順位付けを行っています。 お客様と同様に、私たちも暗号化を使用しているすべての場所を確認し、どの実装を移行する必要があり、優先順位をつける必要がありました。重要な決定の 1 つは、転送中 (in transit) の暗号化により重点を置き、保管中 (at rest) のデータの暗号化にはあまり重点を置かないことでした。公開鍵 (非対称) 暗号は、転送中の暗号化の基盤となるものです。なぜなら、信頼されていないネットワーク上で双方が共有秘密鍵のネゴシエーションを可能にするためです。しかし、現在広く使われている伝統的な公開鍵アルゴリズムが、暗号解読可能量子コンピュータ (CRQC) の実現により危険にさらされています。業界全体の現在の合意に基づけば、256 ビットの対称鍵暗号化に対する暗号解読可能量子コンピュータのリスクは、緩和する必要はありません。AWS の保管中のデータは 256 ビットの対称鍵暗号化で暗号化されているため、既存のお客様データを再暗号化したり、将来のデータを暗号化するために使用する対称アルゴリズムやキーを変更する必要はないと考えています。 対称暗号化キーやアルゴリズムの安全性は、暗号解読可能量子コンピュータによる暗号解読の脅威に晒されていませんが、公開鍵アルゴリズムを使用して共有対称鍵をネゴシエーションする場合があり、その際に対称鍵が危険にさらされる可能性があります。AWS で最初に PQC に移行する公開鍵暗号の用途は、まさにこの場合です。つまり、お客様と AWS サービスの公開エンドポイント間で共有対称鍵のネゴシエーションをする場合です。お客様が AWS サービスと通信するためのネットワークは、多くの場合 AWS やお客様のどちらの管理下になく、悪意のある第三者がデータを盗聴し、将来的に量子コンピュータを使って暗号を解読する可能性があります。ワークストリーム 2 では、この計画についてより詳しく説明しています。 次に AWS で PQC に移行するのは、長期的な Root of Trust (信頼の起点) として機能する公開鍵ペアを作成する機能です。これは通常、ソフトウェア、ファームウェア、ドキュメントにデジタル署名を適用するために使用されます。このような公開鍵ペアは、簡単に更新できないため、将来数年間にわたってデジタル署名の用途で有効である必要があります。人工衛星、ゲーム機、その他の IoT デバイスのファームウェアを考えてみてください。デバイスの寿命期間中に公開鍵ペアと署名アルゴリズムのコードを更新することが難しい場合があります。ワークストリーム 3 では、この計画をより詳しく説明しています。 AWS における公開鍵暗号の最後の領域は、一時的な Root of Trust (信頼の起点) として機能するキーペアを作成する機能を提供することです。これは通常、単一のトランザクション、Web セッション、または他の一時的なメッセージにデジタル署名を適用するために使用されます。この使用例の最も一般的な例は、デジタル証明書が TLS セッションでサーバーまたはクライアントを認証するために使用される方法です。ワークストリーム 2 と 3 が TLS セッションでのセッション鍵のネゴシエーションとデジタル署名のリスクを処理すると想定されるかもしれません。では、保護する残りの部分は何でしょうか? 実は、公開鍵暗号を利用してメッセージを交換する際には、広範囲のインターネットインフラストラクチャにおける標準と相互運用性に大きく依存します。業界がこれらの標準に合意し、相互運用性をテストするには時間がかかるため、このワークストリームが完了するまでに時間がかかります。ワークストリーム 4 では、この計画についてより詳しく説明しています。 AWS がどのように暗号化に関連するインベントリを作成し、PQC への移行計画を立てたかについて説明しました。暗号化の処理を AWS に全面的に任せていない場合、お客様は準備として何をすべきでしょうか? すべてのアプリケーションや業界に当てはまる単一のアプローチはありませんが、私たちが貢献したり、作業の一部として利用したりした推奨事項に関するより詳しい情報が記載されている関連するリソースをいくつかご紹介します。 CISA Quantum-: Migration to Post-Quantum Cryptography CISA Quantum-Readiness: Migration to Post-Quantum Cryptography CISA Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools ETSI TR 103 619 Migration strategies and recommendations to Quantum Safe schemes 組織全体の暗号技術/暗号システムの棚卸しを行って、PQC 移行の優先順位を付けることは、数年にわたる取り組みが必要かもしれません。しかし、短期的には次の 2 つの戦術的な対策を検討することをお勧めします。まず、ソフトウェアの更新バージョンを配布する機能を確保することです。これは、脆弱性管理やソフトウェアライフサイクル管理の観点から、組織にとって重要な機能です。この機能は、 AWS コマンドラインインターフェース (AWS CLI) と AWS SDK の新しい ポスト量子バージョンを公開した際に採用する必要があります。また、AWS サービスと通信するために TLS やその他の暗号化実装を使用するサードパーティ製品を更新する必要があるかもしれません。これにより、AWS が提供する PQC を活用できるようになります。 次に、組織全体で TLS 1.3 を採用する全社的な取り組みを開始することを強くお勧めします。TLS 1.3 および以降のバージョンは、従来からある公開鍵暗号を使ってセキュリティとパフォーマンスを改善しているだけでなく、PQC を使用できるようになることが義務づけられています。最近クライアントとサーバーで TLS 1.2 に更新した場合でも、システムを PQC の将来に備えるための作業が残っています。 ワークストリーム 2 お客様は、公開鍵暗号に基づくプロトコルを使用してクラウドサービスと通信します。これらのプロトコル (TLS など) は、お客様の通信の機密性が保たれ、転送中に改ざんされないことを保証するのに役立ちます。お客様の長期的な機密性の必要性を保護するために、私たちは量子コンピュータに対する長期的な対策として組み合わせた新しい鍵共有方式を先駆けて導入しました。この新しい方式は、 楕円曲線ディフィー・ヘルマン (ECDH) という従来からある鍵交換アルゴリズムと、新しく標準化された ML-KEM アルゴリズムなどのポスト量子鍵カプセル化方式を組み合わせたものです。得られた 2 つの鍵を組み合わせることで、ネットワークトラフィックを暗号化するためのセッション通信鍵が確立されます。攻撃者がこの新しい鍵共有方式によって提供される機密性を破るには、これらの公開鍵プリミティブ (ECDH と ML-KEM) の両方を解読する必要があります。 AWS は、 オープンソースの FIPS-140-3 検証済み暗号ライブラリ AWS-LC で ML-KEM を実装 することで、ポスト量子暗号の展開の第一歩を踏み出しました。AWS-LC は AWS 全体で使用されている中核的な暗号ライブラリです。このワークストリームに関連して、HTTPS エンドポイントを持つ AWS サービス全体で使用されているオープンソース TLS 実装 s2n-tls でも使用されています。 Internet Engineering Task Force (IETF) は現在、ポスト量子暗号を組み込んだ TLS プロトコル標準の最終化を進めています。この標準が完成すれば、AWS は s2n-tls を新しい仕様に合わせて更新します。IETF 標準に基づく s2n のバージョンに AWS-LC からの ML-KEM 実装を統合できれば、この s2n バージョンを HTTPS ベースのインターフェースを提供するすべての AWS パブリックエンドポイントに展開を開始します。これは、AWS SDK や AWS CLI を通じてアクセスされる大半の AWS サービスを表します。SFTP、IPsec、SSH などの他のインターフェースを提供する AWS サービスについては、IETF などの標準化機関がそれらのプロトコルの実装ガイダンスを公開次第、ML-KEM サポートを追加します。 AWS マネージドサービスエンドポイントを PQC over TLS に移行する一環として、 Elastic Load Balancing (ELB) 、 Amazon API Gateway 、 Amazon CloudFront など、ワークロードのサーバー側 TLS 終端を提供するサービスも有効化されます。これにより、これらのサービスで使用している同じデジタル証明書を使用でき、AWS がサーバー側で ML-KEM による TLS セッションのネゴシエーションを行います。これにより、既存の証明書を、未だ定義されていない PQC 標準のものに置き換えずとも、TLS セッションの長期的な機密性が提供されます。 ML-KEMへの移行をより円滑に進めるため、AWS は National Cybersecurity Center of Excellence (NCCoE) Migration to Post-Quantum Cryptography 、 Linux Foundation’s Post Quantum Cryptography Alliance 、 Rust TLS Project など、主要な業界イニシアチブと協力しています。これらのパートナーシップは、テクノロジー分野全体で PQC ソリューションの異なる実装間のシームレスな相互運用性を確保するのに不可欠です。 ワークストリーム 3 多くのお客様は、ファームウェア、オペレーティングシステム、プリインストールされたサードパーティーのアプリケーションを含むシステムを製造しています。これらのコンポーネントは、公開鍵ベースのルート認証で暗号署名されており、エンドユーザーにサービスを提供する際のシステムのセキュリティと真正性を維持しています。セットトップボックスに接続しているスマート TVのように、インターネットに接続されずに 10 年以上稼働するシステムもあります。 さらに、一部のお客様は、製造時にハードウェアに直接ルート証明書を埋め込む必要があります。この処理は、元に戻したり更新したりすることはできません。10 年以上の稼働を想定したデバイスでは、量子コンピュータが暗号解読に使えるようになった場合でも、これらの初期のルート証明書のセキュリティを堅牢に保つ必要があります。 コードや文書に署名するために長期間有効な Root of Trust (信頼の起点) を提供する必要性に対処するため、AWS は ML-DSA という新しいデジタル署名アルゴリズムを採用します。ML-DSA は、量子コンピュータを持つ攻撃者に対しても安全であると考えられています。AWS は最初に AWS Key Management Service (AWS KMS) の機能として ML-DSA を提供し、お客様が AWS KMS で使用される FIPS-140-3 Level 3 検証済みのハードウェアセキュリティモジュール (HSM) 内で PQC 鍵を生成し、署名操作の Root of Trust (信頼の起点) として使用できるようにします。この統合は、PQC ロードマップにおける重要なマイルストンを示すものであり、お客様に長期的なセキュリティニーズに対する安全でポスト量子の Root of Trust (信頼の起点) と認証を確立する機能を提供します。 この長期的な視点は、PQC を早期に実装することの重要性を強調しています。これにより、長期間オフラインであっても、システムの全運用期間中にわたってセキュリティが確保されるようになります。Amazon は AWS KMS のこの機能を使って自社の Root of Trust (信頼の起点) を保護しますが、皆様にもこの機能を活用して同様の対策を検討していただくことをお勧めします。 ワークストリーム 4 ワークストリーム 2 では、通信チャネルを介してデータを共有する際のデータの機密性に対するリスクから保護するために PQC を展開する方法について議論しました。ストーリーを完結するには、ポスト量子の世界において、通信チャネル経由でサーバーとクライアントの身元の真正性を保護する方法が必要になります。 デジタル署名は、今日のTLS や SSH などのネットワークプロトコルにおいて、エンドポイントの認証に使われています。お客様は、信頼できる認証局 (CA) から発行された証明書を使用しています。この証明書は、デジタル署名を使って公開鍵をアイデンティティにバインドしており、サービスとクライアントのエンドポイントを認証するために使われます。現在利用可能な PQC 標準 (ML-DSA など) の一部は、証明書と組み合わせて実装することで、量子コンピュータ時代のリスクに対処できます。しかし、認証局とデジタル証明書を使用するシステムの間での相互運用性テストと、さらなる標準化が進まない限り、この作業を開始することはできません。この遅れの主な理由は、署名付きメッセージの受信者が、現在、広く信頼された証明書をどのように検証しているかにあります。たとえば TLS プロトコルでは、証明書チェーンを提示するサーバーに接続するクライアントは、サーバーが本物かどうかを判断するために、各証明書に埋め込まれた PQC 署名をすべて検証する必要があります。これらの署名の形式と、証明書の発行・管理プロセスは、 Certificate Authority (CA) Browser Forum によって規定されています。CA Browser Forum のブラウザベンダー企業と証明書発行メンバーは、誰もが TLS セッションで広く信頼された証明書を安全に使えるようにするために、PQC が証明書の発行と検証にどのように機能するかを決定する必要があります。Amazon Trust Services は証明書発行者(訳者注 : 日本では一般に認証局/CAと呼称)であり、CA Browser Forum のメンバーです。私たちは、相互運用性テストを早めるためにこれらの標準の推進に関与しています。 広く信頼された証明書のための PQC の話がまとまりつつありますが、 AWS Private CA サービスは、ML-DSA などの PQC アルゴリズムを使用して、プライベート用の証明書を発行できます。プライベート用の証明書は、CA ブラウザフォーラムが公開するルールに厳密に従う必要がないためです。プライベート証明書を使用するお客様は、クライアントとサーバーの両方のソフトウェアを制御できるため、PQC 認証スキームのクライアントとサーバーの両方を自由に実装できます。ワークストリーム 3 が完了し、AWS KMS で署名操作に ML-DSA が使用可能になると、AWS Private CA はプライベートネットワークで PQC を採用する準備のできたお客様向けに、証明書発行の一部として PQC を提供することを検討します。オープンソースの AWS-LC と s2n ソリューションは、必要に応じてお客様がクライアントとサーバーで PQC 証明書の検証機能を実装するために利用できます。 結論 この投稿では、責任共有モデルにおいて AWS が PQC に移行する方法について説明しました。また、PQC 移行戦略の作成方法と、AWS がその戦略のどの部分を提供するかについてのガイダンスを提供しました。業界が新しい暗号化アルゴリズムへの移行を行う中で、新しい課題と機会が生まれるでしょう。PQC 移行に関する追加情報、ブログ投稿、および定期的な更新については、 AWS Post-Quantum Cryptography ページ を引き続きご覧ください。 AWS のポスト量子暗号について詳しく知りたい場合は、 post-quantum cryptography team にお問い合わせください。 この投稿に関する意見がある場合は、下のコメントセクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを立てるか、 AWS サポートに連絡 してください。 Matthew Campagna Matthew は Amazon Web Services の暗号化の専門家であり、シニア・プリンシパル・エンジニアです。同社全体の暗号化ソリューションの設計とレビューを管理し、ポスト量子暗号への移行を指導しています。余暇には、通勤と睡眠を行っています。 Melanie Goldsborough Melanie は AWS のシニアセキュリティスペシャリストで、20 年以上にわたるインテリジェンスとテクノロジーの経験を持っています。彼女は公的機関を中心としたセキュリティサービスのグローバル販売戦略を立案しています。Melanie の専門分野は、コンテンツ開発、経営層とのエンゲージメント、そして顧客やパートナーの世界規模でのセキュリティ実践の向上に向けたプログラムの実行です。 Peter M. O’Donnell Peter は AWS のプリンシパルソリューションアーキテクト(SA)で、セキュリティ、リスク、コンプライアンス分野の戦略アカウントチームの専門家です。9.5 年間にわたって AWS の SA を務め、データ保護、暗号化、ID 管理、脅威モデリング、コンプライアンス、セキュリティ文化、CISO とのエンゲージメントなどのセキュリティ関連トピックについて、同社の大規模かつ最も複雑な戦略的なお客様のサポートを行っています。 本ブログは Sr. Security Solutions Architect の勝原 達也が翻訳しました。原文は こちら を御覧ください。

この記事は 「 AWS Brings the Power of Generative AI to Ecommerce with the AI Shopping Assistant 」（記事公開日： 2024 年 11 月 26 日）の翻訳記事です。 自宅のリノベーションを計画しているとしましょう。たとえば、新しいデッキを増設したり、地下室を居心地の良い隠れ家に変えたりするといったものかもしれません。 PC を開いて建築資材を注文できるオンライン小売店に行ってみると、何百ものネジ、数十種類の木材、数え切れないほどの選択肢に直面するばかりです。エキサイティングな計画として始まったものが、今では選択肢にあふれたページを無限にスクロールしても、どの商品が自分の計画に最適かわからないので、面倒な作業のように感じます。 PC を閉じようとしたときに、生成 AI を搭載したショッピングアシスタントのアイコンを見つけました。 「デッキを作ろうとしているようですね。 お手伝いしましょうか？」 と訊かれます。数分後、必要なものはすべてショッピングカートに入っています。最初から最後まで正確に最適なものを提案してくれます。 AWS 提供のデモの一つである AI ショッピングアシスタント は、お客様固有のニーズに合わせてカスタマイズされた推奨商品を提示するなど、生成 AI がデジタル空間での案内役としてどのように機能するのかを確認していただけます。 小売業者が顧客向けにパーソナライズされたシームレスな体験を提供できるように設計されたこのアシスタントは、顧客がより迅速かつ自信を持って意思決定を行えるようにします。 AI ショッピングアシスタントは、選択肢を最も関連性の高いものだけに絞り込むことで、悩ましい選択の苦労を軽減して購入へと導き、ショッピングをより満足のいく体験に変えます。 また、小売業者が顧客と関わり、購入を手助けする新しい方法を見出してくれるので、購買意欲と実際の購買行動とを橋渡しします。 「ちょっと立ち寄ってみたくなる」 AI ショッピングアシスタントのいるオンラインショッピングサイト 多くの顧客にとって、適切な商品をすばやく見つけることが、ショッピング体験の成否を左右します。 AI ショッピングアシスタントは、自然言語処理と生成 AI を使用して、デッキに最適なネジの特定や特殊な電子部品の検索など、それぞれの買い物客の特定のニーズに合わせて、パーソナライズされた提案を用意します。AI アシスタントは幅広い商品詳細にアクセスできるので、店舗スタッフが店頭で案内するように、気の遠くなるような迷路のような選択肢を関連性の高いものだけに絞り込み、より魅力的なオンラインショッピング体験を実現します。 他の優れたアシスタントと同様、お薦めの関連商品を提示してリクエストに応えるだけではありません。 この「ちょっと立ち寄ってみる」ことで、プロジェクト固有のツールから補完的な商品まで、顧客は当初考えてもいなかった商品を見つけられるという意外な体験ができます。 こうしたパーソナライズされた提案のおかげで、買い物かごはより多くの商品でいっぱいになり、アップセルやクロスセルの機会を生み出します。これにより、客単価が引き上がると同時に顧客にとってより楽しいショッピング体験を提供することができます。 AI ショッピングアシスタントの仕組み AWS 上に構築された堅牢、かつ柔軟なアーキテクチャに支えられた AI ショッピングアシスタントは、複数の顧客タッチポイントにわたってパーソナライズされた効率的なサービスを提供します。 舞台裏でどのように機能するかを見てみましょう。 ユーザーインタラクションとフロントエンドアクセス : 顧客は Amazon CloudFront でホストされているシームレスなウェブベースのインターフェースを通じて AI アシスタントにアクセスします。 認証が完了すると、顧客は商品を調べては質問をしたり、固有のニーズに合わせてカスタマイズされたガイダンスを受けたりできます。 AppSync によるデータ統合と管理 : GraphQL API 統合レイヤーである AWS AppSync は、AI アシスタントのサービス間のデータフローを調整します。 このレイヤーは、顧客からのクエリの処理、 Amazon Bedrock とのやりとりの管理、 Amazon DynamoDB の更新などを行う AWS Lambda 関数を調整して、レコメンデーションが関連付けられているようにします。 生成 AI とセマンティック検索機能 : Amazon Bedrock はアシスタントの顧客クエリを解釈する能力を強化し、生成 AI を活用して正確な応答を提供します。 Amazon OpenSearch Service にベクトル化されたエントリとして保存された商品カタログデータのおかげで、リアルタイムなセマンティック検索と AI アルゴリズムに適したレコメンデーション提示の両方の機能を実現できるため、ショッピング体験をより楽しいものにします。 対話履歴によるパーソナライズ : Amazon DynamoDB には対話履歴が保存されるため、AI アシスタントは過去のやり取りを思い出し、各顧客のジャーニーや好みに合わせた回答を提供できます。 このアーキテクチャにより、小売業者は E コマースの Web サイトから店舗のキオスクまで、さまざまなプラットフォームに AI ショッピングアシスタントを導入して、進化し続ける顧客のニーズに対応できます。 以下の図は、これらのサービス間の連携の概要を視覚的に示しており、今日の小売需要を満たすアシスタントのスケーラビリティと柔軟性を示しています。 AI ショッピングアシスタントで小売戦略を強化しましょう AI ショッピングアシスタントは、小売業者が顧客と関わったり、サポートする方法を刷新し、オンラインや実店舗を問わず、パーソナライズされた効率的な新しいショッピング体験を提供できるよう支援します。希望に完璧に合った商品へと買い物客をシームレスに誘導し、関連するアドオンを提案し、購入決定までの負担が軽減できることを想像してみてください。これらすべてが、各顧客固有のニーズや好みに合わせたデジタルアシスタントによって実現されます。 次に何が待ち受けているのか、一緒に探求していきましょう。 この AI 主導のソリューションを御社のビジネスに合わせてカスタマイズする 方法 について、当社のチームにご相談ください。 生成 AI が小売戦略をどのように変革しているかについては AWS が re:Invent で発表した「 RCG 204 – Building an AI-powered shopping assistant 」と NRF で発表した NRF 2025 (ブース #5438) が参考になります。 AI ショッピングアシスタントがどのように顧客体験を向上させ、インテリジェントでパーソナライズされた小売の未来を提供することができるのかをご覧ください。 著者について Yuri Chamarelli Yuri Chamarelli は、デンバーオフィスをベースとするアマゾンウェブサービスのシニアスペシャリストソリューションアーキテクト (AWS) です。生成 AI のスペシャリストとして、お客様が AWS を使用して構築し、最先端のソリューションを提供できるよう支援することに注力しています。 Yuri は IoT と機械学習システムで 14 年以上の経験を持つ制御エンジニアです。 また、さまざまな業界の事業変革や事業オートメーションプロジェクトで複数の顧客を支援してきました。 Pat Reilly Pat Reilly は、シアトルオフィスをベースとするアマゾンウェブサービスのシニアスペシャリストソリューションアーキテクト (AWS) です。 生成 AI のスペシャリストとして、15 年以上にわたる機械学習と分析の経験を活かして、お客様が Amazon Bedrock を使用してエージェントワークロードを構築できるよう支援しています。 サッカーが好きな Pat は、休日にはサッカー場にいることが多いです。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

macOS 環境向けの AWS CodeBuild で Fastlane がご利用いただけるようになりました。AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、すぐにデプロイできるソフトウェアパッケージを作成する、フルマネージド継続的インテグレーションサービスです。 Fastlane は、モバイルアプリ開発のさまざまな側面を自動化するように設計されたオープンソースツールスイートです。コード署名、スクリーンショット生成、ベータ版の配布、アプリケーションストアへの送信などのタスクを管理するための一元化された一連のツールをモバイルアプリデベロッパーに提供します。一般的な継続的インテグレーションおよび継続的デプロイ (CI/CD) プラットフォームと統合し、iOS と Android の両方の開発ワークフローをサポートします。Fastlane は優れたオートメーション機能を提供しますが、デベロッパーはセットアップとメンテナンス中に課題に直面する可能性があります。特に Ruby の構文とパッケージ管理システムに慣れていないチームは、Fastlane の設定が複雑であると感じる可能性があります。モバイルプラットフォームやサードパーティーサービスの更新によって既存のワークフローの調整が必要になる場合があるため、Fastlane とその依存関係を最新の状態に保つには継続的な作業が必要です。 2024 年 8 月に CodeBuild for macOS を導入 したとき、お客様の課題の 1 つがビルド環境に Fastlane をインストールして維持することであることがわかりました。カスタムビルド環境に Fastlane を手動でインストールすることは可能でしたが、AWS は インフラストラクチャから差別化につながらない手間のかかる作業を取り除き 、お客様がビジネスにとって重要な側面により多くの時間を費やせるようにします。本日より、Fastlane はデフォルトでインストールされ、 buildspec.yaml ファイルで使い慣れたコマンド fastlane build を使用できるようになりました。 Fastlane とコード署名 App Store でアプリケーションを配布するには、デベロッパーは Apple Developer ポータルで生成されたプライベートキーを使用してバイナリに署名する必要があります。このプライベートキーと、それを検証する証明書は、ビルドプロセス中にアクセスできる必要があります。これは、開発チームにとって課題となる可能性があります。なぜなら、開発チームは、開発プライベートキー (特定のテストデバイスへのデプロイを可能にするもの) をチームメンバー間で共有する必要があるからです。さらに、App Store にバイナリをアップロードする前の署名プロセスでは、配布プライベートキー (App Store での公開を可能にするもの) が使用可能である必要があります。 Fastlane は、開発キーと配布キーおよび証明書の管理でもデベロッパーをサポートするという点で、多目的なビルドシステムです。デベロッパーは、 fastlane match を使用して、チーム内で署名マテリアルを共有し、個々のデベロッパーのマシンと CI 環境で安全かつ簡単にこれらにアクセスできるようにすることができます。 match を使用すると、プライベートキー、証明書、モバイルプロビジョニングプロファイルをセキュリティで保護された共有ストレージに保存できます。これにより、デベロッパーのノートパソコンであれ、クラウド内のサーバーマシンであれ、ローカルビルド環境が共有ストレージと同期された状態を維持できます。ビルド時に、アプリケーションに署名するために必要な証明書を安全にダウンロードし、 codesign ユーティリティがそれらの証明書を取得できるようにビルドマシンを設定します。 match を使用すると、GitHub、GitLab、Google Cloud Storage、Azure DevOps、 Amazon Simple Storage Service (Amazon S3) を通じて署名シークレットを共有できます。 これらのいずれかを既に使用していて、プロジェクトを CodeBuild に移行する場合、行うべきことはあまりありません。必要なのは、CodeBuild ビルド環境が共有ストレージにアクセスできることを確認することだけです (デモのステップ 3 をご覧ください)。 仕組みを見てみましょう Fastlane または CodeBuild を初めて使用するお客様のために、その仕組みをご紹介します。 このデモでは、 既存の iOS プロジェクト を使用して始めます。プロジェクトは、CodeBuild でビルドされるように既に設定されています。詳細については、以前のブログ記事「 AWS CodeBuild を利用して、継続的インテグレーションパイプラインに macOS を追加する 」をご覧ください。 3 つのステップで開始する方法を説明します: 既存の署名マテリアルを共有プライベート GitHub リポジトリにインポートする プロジェクトをビルドして署名するように fastlane を設定する CodeBuild で fastlane を使用する ステップ 1: 署名マテリアルをインポートする 私が読んだ fastlane に関する ドキュメント のほとんどでは、開始するために新しいキーペアと新しい証明書を作成する方法が説明されています。これは新しいプロジェクトには確かに当てはまりますが、実際には、プロジェクトと署名キーは既に存在している可能性があります。したがって、最初のステップは、これらの既存の署名マテリアルをインポートすることです。 Apple App Store は、開発と配布に異なるキーと証明書を使用します (アドホック証明書とエンタープライズ証明書もありますが、これらはこの記事の範囲外です)。使用ごとに 3 つのファイルが必要です (合計 6 つのファイル): Apple デベロッパーコンソールから作成してダウンロードできる .mobileprovision ファイル。プロビジョニングプロファイルは、ユーザーの ID、アプリケーション ID、アプリケーションが持つ可能性のある権限をリンクします。 Apple がプライベートキーを検証するために発行した証明書である .cer ファイル。これは、 Apple Developer ポータル からダウンロードできます。証明書を選択し、 [ダウンロード] を選択します。 プライベートキーを含む .p12 ファイル。キーは、 Apple Developer ポータル で作成したときにダウンロードできます。ダウンロードしていないが、マシン上に保存されている場合は、Apple Keychain アプリケーションからエクスポートできます。KeyChain.app は macOS 15.x では非表示になっていることに留意してください。 open /System/Library/CoreServices/Applications/Keychain\ Access.app で開くことができます。エクスポートするキーを選択し、右クリックして [エクスポート] を選択します。 これらのファイルを作成したら、次の内容を含む fastlane/Matchfile ファイルを作成します: git_url("https://github.com/sebsto/secret.git") storage_mode("git") type("development") # または、appstore を使用して配布署名キーと証明書を使用します # type("appstore") GitHub リポジトリの URL を置き換え、 このリポジトリがプライベートであるようにしてください 。これは、署名キーと証明書のストレージとして機能します。 その後、 fastlane match import --type appstore コマンドを使用して、既存のファイルをインポートします。各環境 ( appstore と development ) 用のコマンドを繰り返します。 初回は、 fastlane から Apple ID のユーザー名とパスワードの入力を求められます。証明書の有効性を検証したり、必要に応じて新しい証明書を作成したりするために、App Store Connect に接続します。セッション Cookie は ~/.fastlane/spaceship/<your apple user id>/cookie に保存されます。 fastlane match からもパスワードの入力を求められます。このパスワードを使用して、ストレージ上の署名マテリアルを暗号化するためのキーを生成します。このパスワードは、ビルド時に署名マテリアルをビルドマシンにインポートするために使用されるため、忘れないようにしてください。 コマンドとその出力全体を次に示します: fastlane match import --type appstore [✔] 🚀 [16:43:54]: Successfully loaded '~/amplify-ios-getting-started/code/fastlane/Matchfile' 📄 +-----------------------------------------------------+ | Detected Values from './fastlane/Matchfile' | +--------------+--------------------------------------+ | git_url. | https://github.com/sebsto/secret.git | | storage_mode | git | | type | development | +--------------+--------------------------------------+ [16:43:54]: Certificate (.cer) path: ./secrets/sebsto-apple-dist.cer [16:44:07]: Private key (.p12) path: ./secrets/sebsto-apple-dist.p12 [16:44:12]: Provisioning profile (.mobileprovision or .provisionprofile) path or leave empty to skip this file: ./secrets/amplifyiosgettingstarteddist.mobileprovision [16:44:25]: Cloning remote git repo... [16:44:25]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match. [16:44:27]: Checking out branch master... [16:44:27]: Enter the passphrase that should be used to encrypt/decrypt your certificates [16:44:27]: This passphrase is specific per repository and will be stored in your local keychain [16:44:27]: Make sure to remember the password, as you'll need it when you run match on a different machine [16:44:27]: Passphrase for Match storage: ******** [16:44:30]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [16:44:31]: 🔓 Successfully decrypted certificates repo [16:44:31]: Repo is at: '/var/folders/14/nwpsn4b504gfp02_mrbyd2jr0000gr/T/d20250131-41830-z7b4ic' [16:44:31]: Login to App Store Connect (sebsto@mac.com) [16:44:33]: Enter the passphrase that should be used to encrypt/decrypt your certificates [16:44:33]: This passphrase is specific per repository and will be stored in your local keychain [16:44:33]: Make sure to remember the password, as you'll need it when you run match on a different machine [16:44:33]: Passphrase for Match storage: ******** [16:44:37]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [16:44:39]: 🔒 Successfully encrypted certificates repo [16:44:39]: Pushing changes to remote git repo... [16:44:40]: Finished uploading files to Git Repo [https://github.com/sebsto/secret.git] Fastlane が署名マテリアルを Git リポジトリにインポートしたことを確認します。 次のビルドでこれらの署名マテリアルを使用するようにローカルマシンを設定することもできます: » fastlane match appstore [✔] 🚀 [17:39:08]: Successfully loaded '~/amplify-ios-getting-started/code/fastlane/Matchfile' 📄 +-----------------------------------------------------+ | Detected Values from './fastlane/Matchfile' | +--------------+--------------------------------------+ | git_url | https://github.com/sebsto/secret.git | | storage_mode | git | | type | development | +--------------+--------------------------------------+ +-------------------------------------------------------------------------------------------+ | Summary for match 2.226.0 | +----------------------------------------+--------------------------------------------------+ | type | appstore | | readonly | false | | generate_apple_certs | true | | skip_provisioning_profiles | false | | app_identifier | ["com.amazonaws.amplify.mobile.getting-started"] | | username | xxxx@xxxxxxxxx | | team_id | XXXXXXXXXX | | storage_mode | git | | git_url | https://github.com/sebsto/secret.git | | git_branch | master | | shallow_clone | false | | clone_branch_directly | false | | skip_google_cloud_account_confirmation | false | | s3_skip_encryption | false | | gitlab_host | https://gitlab.com | | keychain_name | login.keychain | | force | false | | force_for_new_devices | false | | include_mac_in_profiles | false | | include_all_certificates | false | | force_for_new_certificates | false | | skip_confirmation | false | | safe_remove_certs | false | | skip_docs | false | | platform | ios | | derive_catalyst_app_identifier | false | | fail_on_name_taken | false | | skip_certificate_matching | false | | skip_set_partition_list | false | | force_legacy_encryption | false | | verbose | false | +----------------------------------------+--------------------------------------------------+ [17:39:08]: Cloning remote git repo... [17:39:08]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match. [17:39:10]: Checking out branch master... [17:39:10]: Enter the passphrase that should be used to encrypt/decrypt your certificates [17:39:10]: This passphrase is specific per repository and will be stored in your local keychain [17:39:10]: Make sure to remember the password, as you'll need it when you run match on a different machine [17:39:10]: Passphrase for Match storage: ******** [17:39:13]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [17:39:15]: 🔓 Successfully decrypted certificates repo [17:39:15]: Verifying that the certificate and profile are still valid on the Dev Portal... [17:39:17]: Installing certificate... +-------------------------------------------------------------------------+ | Installed Certificate | +-------------------+-----------------------------------------------------+ | User ID | XXXXXXXXXX | | Common Name | Apple Distribution: Sebastien Stormacq (XXXXXXXXXX) | | Organisation Unit | XXXXXXXXXX | | Organisation | Sebastien Stormacq | | Country | US | | Start Datetime | 2024-10-29 09:55:43 UTC | | End Datetime | 2025-10-29 09:55:42 UTC | +-------------------+-----------------------------------------------------+ [17:39:18]: Installing provisioning profile... +-------------------------------------------------------------------------------------------------------------------+ | Installed Provisioning Profile | +---------------------+----------------------------------------------+----------------------------------------------+ | Parameter | Environment Variable | Value | +---------------------+----------------------------------------------+----------------------------------------------+ | App Identifier | | com.amazonaws.amplify.mobile.getting-starte | | | | d | | Type | | appstore | | Platform | | ios | | Profile UUID | sigh_com.amazonaws.amplify.mobile.getting-s | 4e497882-d80f-4684-945a-8bfec1b310b9 | | | tarted_appstore | | | Profile Name | sigh_com.amazonaws.amplify.mobile.getting-s | amplify-ios-getting-started-dist | | | tarted_appstore_profile-name | | | Profile Path | sigh_com.amazonaws.amplify.mobile.getting-s | /Users/stormacq/Library/MobileDevice/Provis | | | tarted_appstore_profile-path | ioning | | | | Profiles/4e497882-d80f-4684-945a-8bfec1b310 | | | | b9.mobileprovision | | Development Team ID | sigh_com.amazonaws.amplify.mobile.getting-s | XXXXXXXXXX | | | tarted_appstore_team-id | | | Certificate Name | sigh_com.amazonaws.amplify.mobile.getting-s | Apple Distribution: Sebastien Stormacq | | | tarted_appstore_certificate-name | (XXXXXXXXXX) | +---------------------+----------------------------------------------+----------------------------------------------+ [17:39:18]: All required keys, certificates and provisioning profiles are installed 🙌 ステップ 2: プロジェクトに署名するように Fastlane を設定する fastlane/Fastfile に Fastlane ビルド設定ファイルを作成します ( fastlane init コマンドを使用して開始できます)。 default_platform(:ios) platform :ios do before_all do setup_ci end desc "Build and Sign the binary" lane :build do match(type: "appstore", readonly: true) gym( scheme: "getting started", export_method: "app-store" ) end end match アクションが正しく機能するには、 setup_ci アクションが Fastfile の before_all セクションに追加されているようにしてください。このアクションは、適切な許可を持つ一時的な Fastlane キーチェーンを作成します。このステップを実行しないと、ビルドが失敗したり、一貫性のない結果が得られたりする可能性があります。 そして、ローカルビルドをコマンド fastlane build でテストします。キーと証明書をインポートする際に使用したパスワードを入力し、システムにプロジェクトのビルドと署名を実行させます。すべてが正しく設定されていると、同様の出力が生成されます。 ... [17:58:33]: Successfully exported and compressed dSYM file [17:58:33]: Successfully exported and signed the ipa file: [17:58:33]: ~/amplify-ios-getting-started/code/getting started.ipa +---------------------------------------+ | fastlane summary | +------+------------------+-------------+ | Step | Action | Time (in s) | +------+------------------+-------------+ | 1 | default_platform | 0 | | 2 | setup_ci | 0 | | 3 | match | 36 | | 4 | gym | 151 | +------+------------------+-------------+ [17:58:33]: fastlane.tools finished successfully 🎉 ステップ 3: Fastlane を利用するように CodeBuild を設定する 次に、CodeBuild でプロジェクトを作成します。それに役立つステップバイステップのガイドにはここでは立ち入りません。 前回の記事 または CodeBuild ドキュメント をご覧ください。 Fastlane 固有の設定は 1 つだけです。署名マテリアルにアクセスするには、Fastlane は環境変数として渡す 3 つのシークレットの値にアクセスする必要があります: MATCH_PASSWORD : 署名マテリアルをインポートする際に入力するパスワード。Fastlane はこのパスワードを使用して、GitHub リポジトリ内の暗号化されたファイルを解読します FASTLANE_SESSION : ~/.fastlane/spaceship/<your apple user id>/cookie にある Apple ID セッション Cookie の値。セッションの有効期間は数時間から数日間です。セッションの有効期限が切れたら、ノートパソコンからコマンド　 fastlane spaceauth を使用して再認証し、 FASTLANE_SESSION の値を Cookie の新しい値で更新します。 MATCH_GIT_BASIC_AUTHORIZATION : GitHub ユーザー名の Base 64 エンコードで、コロンと個人認証トークン (PAT) が続きます。プライベート GitHub リポジトリにアクセスするためのものです。PAT は、 GitHub コンソール の [プロファイル] > [設定] > [デベロッパーの設定] > [個人アクセストークン] で生成できます。この環境変数の値を生成するには、次のコマンドを使用します: echo -n my_git_username:my_git_pat | base64 。 これらの 3 つの値それぞれについて、 AWS Secrets Manager のシークレットの Amazon リソースネーム (ARN) またはプレーンテキストの値を入力できることに留意してください。 セキュリティ上重要な値を保存するには Secrets Manager を利用することを強くお勧めします 。 私はセキュリティを重視するユーザーなので、次のコマンドを使用して 3 つのシークレットを Secrets Manager に保存します: aws --region $REGION secretsmanager create-secret --name /CodeBuild/MATCH_PASSWORD --secret-string MySuperSecretPassword aws --region $REGION secretsmanager create-secret --name /CodeBuild/FASTLANE_SESSION --secret-string $(cat ~/.fastlane/spaceship/my_appleid_username/cookie) aws --region $REGION secretsmanager create-secret --name /CodeBuild/MATCH_GIT_BASIC_AUTHORIZATION --secret-string $(echo -n my_git_username:my_git_pat | base64) ビルドプロジェクトが Secrets Manager に保存されているシークレットを参照する場合、ビルドプロジェクトのサービスロールで secretsmanager:GetSecretValue アクションを許可する必要があります。プロジェクトの作成時に [新しいサービスロール] を選択した場合、CodeBuild はビルドプロジェクトのデフォルトのサービスロールにこのアクションを含めます。しかし、 [既存のサービスロール] を選択した場合は、このアクションをサービスロールに別途含める必要があります。 このデモでは、次の AWS Identity and Access Management (IAM) ポリシーを使用します: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-2:012345678912:secret:/CodeBuild/*" ] } ] } AWS マネジメントコンソール の CodeBuild セクションでプロジェクトを作成した後、3 つの環境変数を入力します。値は Secrets Manager のシークレットの名前であることに留意してください。 環境変数とその Secrets Manager シークレット名を buildpsec.yaml ファイルで定義することもできます。 次に、プロジェクトのルートにある buildspec.yaml ファイルを変更して、 fastlane を使用してバイナリをビルドおよび署名します。私の buildspec.yaml ファイルは次のようになりました: # buildspec.yml version: 0.2 phases: install: commands: - code/ci_actions/00_install_rosetta.sh pre_build: commands: - code/ci_actions/02_amplify.sh build: commands: - (cd code && fastlane build) artifacts: name: getting-started-$(date +%Y-%m-%d).ipa files: - 'getting started.ipa' base-directory: 'code' バックエンドの Amplify 設定を受け取るには、Rosetta スクリプトと Amplify スクリプトが必要です。プロジェクトで AWS Amplify を利用しない場合、これらは必要ありません。 ビルドファイルには、署名キーをダウンロードしたり、ビルド環境でキーチェーンを準備したりするものがないことに留意してください。 fastlane match がそれを実行してくれます。 新しい buildspec.yaml ファイルと ./fastlane ディレクトリを Git に追加します。これらのファイルをコミットしてプッシュします。 git commit -m "add fastlane support" && git push すべてがうまくいけば、CodeBuild でビルドが実行され、「 成功 」メッセージが表示されます。 料金と利用可能なリージョン CodeBuild for macOS が利用可能なすべての リージョン において、CodeBuild が使用するすべての macOS イメージに、追加料金なしで Fastlane がプリインストールされるようになりました。この記事の執筆時点では、これらのリージョンは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト) です。 私の経験では、 fastlane match を正しく設定するには少し時間がかかります。設定が完了したら、CodeBuild で動作させるのは非常に簡単です。これを CodeBuild で試す前に、ローカルマシンで動作することを確認してください。CodeBuild で問題が発生した場合は、環境変数の値を三重に確認し、CodeBuild が AWS Secrets Manager のシークレットにアクセスできることを確認してください。 さあ、(macOS で) ビルドしましょう! 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 みなさんいかがお過ごしでしょうか。私は週末に軽い気持ちで挑んだアイススケートによる筋肉痛が治っていません。 さて、2025 年 3 月 6 日 に AWS Innovate: Generative AI + Data がオンラインで開催されます。最新の AWS の生成 AI サービスとお客様事例を通じたユースケースを学ぶことができるイベントとなっています。アジェンダも公開されていますのでご覧の上ぜひご登録ください！ それでは、2 月 3 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「DeepSeek-R1 モデルが AWS で使用可能に」を公開 現在話題の DeepSeek ですが、1 月 30 日より Amazon Bedrock と Amazon SageMaker AI で DeepSeek-R1 モデルをデプロイできるようになっています。本記事では、 1) Amazon Bedrock Marketplace 、2) Amazon SageMaker JumpStart 、3) Amazon Bedrock Custom Model Import 、4) Amazon EC2 Trn1 インスタンス の4種類のデプロイ方法を紹介しています。ぜひお試しあれ。 ブログ記事「【開催報告】基盤モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術 ～ AWS Trainium2 & Amazon Bedrock Marketplace ～」を公開 2025 年 1 月 14 日に基盤モデル開発者向けのイベントを開催しました。こちらの記事はイベントの開催報告ブログです。 Amazon EC2 Trn2 インスタンスおよび Trn2 UltraServers と Amazon Bedrock Marketplace の紹介、生成 AI 基盤モデルを開発されたお客様セッションの様子が紹介されています。 ブログ記事「生成 AI を使用して商品画像から新機能を引き出す」を公開 この記事では、小売および消費財業界における生成 AI のユースケースを紹介しています。商品画像を生成 AI でテキスト化することで検索エンジン最適化 (SEO) を改善する、商品画像をベクトル化することでビジュアルデータの検索を可能にする、画像を生成させ商品のアイディエーションに活用する、といった例を挙げています。ユースケースの参考にぜひご覧ください。 ブログ記事「Amazon Q Developerにおけるリアルタイム実行によるコード生成の強化」を公開 Amazon Q Developer エージェント は、複数のファイルにまたがった自律的なコード生成機能を持っています。最近のアップデートで、コード生成に加えて自動でビルド・テストを実行させることもできるようになりました。使い方や例をブログで紹介しています。簡単に試すことができますので、ぜひ記事を読みながら体験いただければと思います。 サービスアップデート Amazon Q Business にて、ユーザークエリのオーケストレーション機能を追加 Amazon Q Business は、企業向けの生成 AI アシスタントサービスです。Salesforce などのビジネスツールや企業固有の情報と連携し、検索・データ活用することが可能になっています。今回のアップデートで、ユーザーの問い合わせ内容を Amazon Q Business が理解し、適切なデータソースに自動的に振り分けて応答生成することができるようになりました。使用するデータソースやビジネスツールを手動で選択する必要がなくなったのが嬉しいポイントです。 Amazon Q Developer の AWS コンソールエラー対応機能が全 AWS リージョンで利用可能に Amazon Q Developer は、権限不足、設定の誤り、サービス制限の超過といったコンソール上に表示されるエラーを診断する機能を提供しています。これまでバージニア北部とオレゴンリージョンのみで提供していましたが、この度全リージョンで利用可能になりました。 Amazon Q Developer にて、Pro Tier サブスクリプションのセットアップが容易に Amazon Q Developer Pro Tier サブスクリプションのセットアップ体験が改善され、設定と管理がより容易になりました。わずか 2 ステップでユーザーやチームのサブスクライブができるようになっています。 次回は、新しく執筆メンバーとして参加することになった ソリューションアーキテクト野間 が最新情報をお届けします！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 まだまだ寒い日が続きますが、みなさんいかがお過ごしですか。私は寒いのが苦手なので、家でゆっくりしたい派です。 少し先のイベントですが、AWS Innovate Generative AI + Data | 2025 年 3 月 6 日開催の 参加登録 が開始しました。AWS だけでなくお客様からの実際のユースケースのセッションも盛りだくさんです。ぜひ、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025 年 2 月 3 日週の主要なアップデート 2/3(月) AWS CodeBuild が Buildkite と統合されました AWS CodeBuild は、セルフホスト Buildkite ランナーのネイティブサポートを提供し、CodeBuild 環境内で Buildkite パイプラインジョブを実行できるようになりました。 AWS CodeBuild は、ソースコードをコンパイルし、テストを実行し、デプロイ準備の整ったソフトウェアパッケージを生成する、フルマネージド継続的インテグレーションサービスです。 Amazon EC2 で Microsoft SQL Server の VSS を使用した自動復旧をサポート Amazon EC2 において、VSS (Volume Shadow Copy Services) を使用した EBS スナップショットからの自動復旧が可能になりました。この機能により、実行中の Microsoft SQL Server データベースを停止することなく、AWS Systems Manager の Automation Runbook を使用して特定の時点への復旧を自動化できるようになりました。VSS は、アプリケーションが実行中でもデータのバックアップを取ることができる機能です。従来は手動で行っていた復旧作業が自動化され、大規模なデータベースでも数分以内に復旧できるようになります。また、新しいデータベースとして復元したり、特定の時点への復旧を行ったりすることも可能です。 2/5(水) AWS Step Functions で AWS アカウントあたり 100,000 個のステートマシンとアクティビティをサポート AWS Step Functions は、AWS のサービス間の連携を視覚的に構築できるワークフローサービスです。今回のアップデートでは、1 つの AWS アカウントで作成できるステートマシンとアクティビティの上限数が、従来の 10,000 から 100,000 へと 10 倍に引き上げられました。ステートマシンとは、システムの処理の流れを定義したものです。この変更により、より多くのワークフローを単一の AWS アカウント内で管理できるようになり、特に動的にワークフローを生成するようなアプリケーションの開発がしやすくなりました。このクォータの引き上げは自動的に全ての AWS アカウントに適用され、お客様側での特別な設定は不要です。 AWS IAM が暗号化された SAML アサーションのサポートを発表 AWS IAM において、SAML 認証情報の暗号化サポートが開始され、セキュリティが大幅に強化されました。SAML は多くのアイデンティティプロバイダー (IdP) が利用するオープンな標準規格で、シングルサインオン (SSO) を実現するために使用されます。この仕組みを通じて、企業のユーザーやアプリケーションは AWS Management Console へのログインや AWS API の呼び出しを行うことができます。今回のアップデートの主な特徴は、アイデンティティプロバイダーが IAM に送信する SAML 認証情報を暗号化できる点です。その結果、SAML 認証情報が中間者（エンドユーザーのウェブブラウザなど）を経由する場合でも、暗号化された状態で安全に転送されることが保証されます。 AWS Wickr でファイルを整理・アクセスできる専用スペースを提供開始 AWS Wickr に、ファイルを整理してアクセスするための専用スペース機能が追加されました。AWS Wickr は、セキュリティを最優先したメッセージングおよびコラボレーションサービスです。この新機能「Wickr Files」により、会話の中でファイルの管理がより便利になりました。Wickr ルームのモデレーターや、自己管理型のグループ会話のユーザーは、フォルダにファイルをアップロードして整理することができるようになりました。また、「Messages」と「Files」のタブを切り替えることで、必要なコンテンツにアクセスし、コラボレーションを効率化することができます。 Amazon Q Business がユーザークエリ管理のオーケストレーションを導入 Amazon Q Business の新機能として、ユーザーの問い合わせ管理のためのオーケストレーション機能が導入されました。Amazon Q Business は、仕事に関する情報検索、洞察の獲得、アクションの実行をサポートする生成 AI アシスタントです。今回のアップデートでは、ユーザーからの問い合わせを理解し、適切なデータソースやプラグインに自動的に振り分けて、関連性の高い回答を生成する機能が追加されました。これまでは、ユーザーが業務上の作業を完了し、データソースから洞察を得るために、異なる業務アプリケーション間を手動で切り替える必要がありました。しかし、このオーケストレーション機能により、ユーザーの問い合わせを企業固有のデータソースやプラグインに自動的に振り分けることで、手動での選択が不要になり、会話体験が大幅に向上しました。 2/6(木) Cost Optimization Hub が EC2 Auto Scaling グループの推奨事項をさらに拡充 Cost Optimization Hub の機能が強化され、EC2 Auto Scaling グループに関する新しいコスト最適化レコメンデーションが追加されました。今回のアップデートにより、アイドル状態の EC2 Auto Scaling グループの検出と、スケーリングポリシーや複数のインスタンスタイプを持つ EC2 Auto Scaling グループのサイジング推奨機能が利用できるようになりました。さらに、スタンドアロンの EC2 インスタンスとは別に、EC2 Auto Scaling グループを簡単にフィルタリングして集計できるため、コスト削減の可能性が高い EC2 Auto Scaling グループを特定しやすくなりました。 Amazon Q Developer で Pro tier サブスクリプションの新しい簡素化されたセットアップ機能を導入 Amazon Q Developer の Pro プランのセットアップ体験が新しく改善されました。Amazon Q は AWS が提供する開発者向けの AI 支援ツールで、今回のアップデートでは特に Pro プランの導入をよりシンプルにする改善が行われました。新しいセットアップ方法では、統合開発環境 (IDE) で Amazon Q Developer を試してみたいユーザーやチーム向けに、わずか 2 ステップの簡単なセットアップフローが用意されました。 Amazon GuardDuty の S3 向けマルウェア保護の料金が値下げ Amazon GuardDuty Malware Protection for S3 の価格が大幅に値下げされました。この機能は、Amazon S3 バケットに新しくアップロードされるオブジェクトに対してマルウェアスキャンを実施する、フルマネージドなセキュリティサービスです。2025 年 2 月 1 日より、データスキャンに関する料金が 85% 引き下げられます。これは、スキャンインフラストラクチャとデータ処理の効率化により実現した改善を、AWS のポリシーに基づいてお客様に還元するものです。GuardDuty Malware Protection for S3 の料金は、評価されるオブジェクトの数とスキャンされるデータ量の 2 つの要素に基づいて計算されます。今回の価格改定では、データスキャンの料金が引き下げられ、例えば US East (バージニア北部) リージョンでは、1 GB あたり $0.60 から $0.09 に下がります。 Amazon RDS for Oracle が 2025 年 1 月のリリースアップデートをサポート Amazon RDS for Oracle において、Oracle Database 19c および 21c に対する 2025 年 1 月のリリースアップデート (RU) のサポートが開始されました。このアップデートにより、Oracle データベースの最新のセキュリティパッチや機能改善が適用できるようになります。Amazon RDS for Oracle の各エンジンバージョンでサポートされている Oracle RU の詳細については、 Amazon RDS for Oracle のリリースノート で確認することができます。自動マイナーバージョンアップグレード (AmVU) オプションを有効にしている場合、AWS リージョンで Amazon RDS for Oracle が提供を開始してから 6 〜 8 週間後に、データベースインスタンスが最新の四半期 RU に自動的にアップグレードされます。これらのアップグレードは、事前に設定されたメンテナンスウィンドウの時間帯に実行されます。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

こんにちは！アマゾン ウェブ サービス ジャパンのソリューションアーキテクト金杉です。本ブログでは、3 月 6 日 (木) に開催される AWS Innovate について、その概要と見どころをご紹介します。 AWS Innovate は、年に 2 回開催される、特定のテーマに焦点を当てたテクノロジーオンラインイベントです。2025 年 3 月 6 日に開催する AWS Innovate では、Generative AI + Data をテーマとし、生成 AI やデータ活用における最新の技術動向や事例をみなさまにお届けする予定です (詳細・お申込みは こちら から)。生成 AI というテクノロジーが台頭してから早くも数年経ち、多くのお客様が PoC を経て、本番利用に移り、更にどのように価値を最大化できるかについて模索されています。このような背景から、今回は「生成 AI によるビジネス価値の創出」をテーマとし、「生成 AI ユーザージャーニー」、「データ活用」、「生成 AI アプリケーション開発」の3つの切り口で、全 16 のセッションをお届けします。生成 AI の利用を既に開始している方には、より広く・深く活用を進めるためのベストプラクティスを、生成 AI に興味を持っておりこれから使い始める方には活用のヒントを持ち帰っていただけます。AWS エキスパートのセッションに加え、実際に生成 AI を活用しビジネス価値を生み出しているお客様の事例も紹介してまいります。 生成 AI ジャーニーの進行 生成 AI は事業運営のあり方から働き方まで、我々の仕事に大きな変化をもたらしているのは周知の事実です。業界や組織によって、導入の度合いは異なるものの、生成 AI はこれからの数年間で世の中を大きく変える、ゲームチェンジャーになりうるテクノロジーです。振り返ってみると、2023年、生成 AI は急速に世界の議論の最前線へと台頭しました。多くの個人や組織はこの技術をキャッチアップし、PoC を通じてどのように活用できるか、実験を繰り返していました。2024 年、PoC で得た知見をもとに、生成 AI アプリケーションを本番環境で活用するようになってきました。そして 2025 年はその延長線上で、いかに生成 AI を広く、深く活用していけるかとともに、「どのようにビジネス効果を最大化できるか」に関心がシフトしつつあります。 加えて、AWS は多くのお客様の生成 AI ジャーニーに伴走する中で、「モデルの多様化」、「要件の高度化」、「活用領域の拡大」などのトレンドを観測しています。これには、驚異的なスピードで進化する大規模モデル及び専門領域に特化したカスタムモデルを開発する手法の多様化、「RAG」に加え「エージェント」や「マルチモーダル」などの新しい技術パターンの確立、そして社内利用から to B/to C 向けシステムにおける採用検討の加速、などの背景があります。 「データ」も生成 AI を活用していく上で重要な要素の一つです。世の中で公開されている基盤モデルは企業のプライベートなデータを使って学習されているわけではないので、当然ながら企業の自社コンテキストは把握していません。そのため競合優位性を高めていくためには、自社データを生成AIアプリケーションに組み込ませていくニーズが高まっています。価値を最大化するためには、データを鮮度の高い状態で素早く生成 AI アプリケーションに組み込ませる必要があります。しかし、多くの場合、企業内のデータはサイロ化しているため、統合して活用するにも作業が煩雑となり、工数、コストがかかりがちです。 今回の AWS Innovate では、これらの背景や課題を噛み砕いで説明し、AWS が提供するソリューションやベストプラクティスをオープニングセッションと 3 つのトラックで紹介していきます。 セッションと見どころの紹介 オープニングセッション オープニングセッションでは、生成 AI を活用状況の最新トレンドを踏まえ、ビジネス価値を最大化するためのベストプラクティスについてお話しします。従来専門家のみが扱えると考えられていた AI を、誰もがビジネス価値向上のための選択肢として考えられるようになりました。その背景や技術的な観測を説明した上で、AWS の取り組みやテクノロジーについてご紹介します。生成 AI をこれから導入する方、今後さらに活用を加速していきたい方に対し、AWS がこれまで多くのお客様を支援する過程で培ってきたノウハウをお伝えします。 ブレイクアウトセッション ブレイクアウトセッションでは 3 つのトラックをご用意しました。 １つ目は「生成 AI ユーザージャーニー」をテーマとしています。本トラックは １ つの AWS セッションと ４ つのお客様による事例セッションから構成されます。生成 AI をどのように活用していくかは企業のビジネス関心、利用フェーズ、スキルセットなどから画一的な答えはありませんが、新しい技術を取り入れていく上で成功事例から学べることは多く存在します。本トラックでは、まずAWS が、ビジネスモデルの変革を成し遂げた事例に共通する方程式を紹介し、三菱重工業株式会社様によるカスタマーサポート対応力向上、カラクリ株式会社様から独自 LLM による競合優越性確立、株式会社三菱UFJ銀行様による市場セールス部門での DX 推進、株式会社ゲームエイト様による自動監視による運用コスト削減に関するセッションをお届けします。 ２つ目は「ビジネスに寄与するデータ活用」というテーマで、生成 AI の価値最大化におけるデータの重要性を紹介します。生成 AI の効果を最大化するためには、大規模言語モデル (LLM) の日々向上する性能に加え、自社データを組み合わせ、差別化を図ることが効果的です。そして自社データを継続的に活用していくためには、長期的な観点からのデータ戦略が必要です。本トラックでは、データ戦略に含まれるデータの収集、品質担保、カタログ管理、ガバナンス、そしてデータが最終的にどのように生成 AI に活かせるかを数セッションに分けてお届けします。 最後に、３つ目のトラックでは「生成 AI アプリケーション開発」という観点から、最新のプラクティス・ソリューションを紹介します。生成 AI アプリケーションには SaaS のように手軽に始めるケース、API 経由で独自アプリケーションを構築するパターン、インフラレベルでモデルを独自開発するなど、様々な形態があります。本トラックでは多岐に渡る生成 AI アプリケーションの開発における手法やツール、活用のためのコツを紹介します。また、アプリケーション開発を促進するための、生成 AI による開発者支援のセッションもご用意しています。 当日のアジェンダはこちらです： タイムテーブルを PDF で見る AWS Innovate: Generative AI + Data をより楽しむために 本ブログを通じて、AWS Innovate: Generative AI + Data に少しでも興味を持っていただけた方は、ぜひ イベントページ から登録いただけると幸いです！改めて、今回の Innovate は「生成 AI によるビジネス価値の創出」をテーマとしています。皆さんに対し日進月歩な生成 AI テクノロジーの最新状況を紹介し、更なる活用に向けてヒントをお届けできればと考えています。より有意義な時間となるよう、自身や自社の生成 AI 活用状況を棚卸ししていただくと同時に、実際に AWS のコンソール からサービスを立ち上げて触ってみていただけると、当日の理解がより深まると思います。 それでは、3 月 6 日 (木) のみなさまのご参加をお待ちしています。当日はチャット形式のライブ Q＆A も実施しますので、AI/ML やデータ活用についての疑問点、お悩みなどもお気軽にお寄せください。みなさまと会話できることを楽しみにしております。 詳細・お申込みは こちら から みなさまのご参加をお待ちしています！ ソリューションアーキテクト 金杉

2025 年 1 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Entity Resolution 柔軟で設定可能なワークフローを使用し、複数のアプリケーション、チャネル、データストアにまたがる関連レコードの照合、リンク、拡張を簡単に行うことができるサービス AWS Entity Resolution について、機能の詳細や利用パターンをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データマッチングに課題を抱えている方 AWS を利用したデータコラボレーションを検討されている方 Customer360 など、データ活用に興味がある方 本 BlackBelt で学習できること AWS Entity Resolution を使用したデータマッチング環境の構築について、サービス概要と機能を学習できます。 また、データマッチングを検討、または課題をお持ちの方に向けて、具体的な利用パターンを知ることができます。 スピーカー 髙橋 伸幸 ソリューションアーキテクト AWS IoT Greengrass ネットワーク/セキュリティ編 AWS IoT Greengrass は、インテリジェント IoT デバイスをより速く構築するためのサービスと、IoT デバイス向けのエッジランタイムです。 本セミナーでは、AWS IoT Greengrass のネットワークセキュリティ編として、AWS IoT Greengrass におけるネットワークとセキュリティについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 IoT 製品やサービスの担当者 これから AWS IoT を用いた製品やサービスの開発を検討されている方 AWS IoT Greengrass をインターネット接続に制約があるネットワーク下で使用することを検討されている方 AWS IoT Greengrass のセキュリティの仕組みを把握したい方 本 BlackBelt で学習できること AWS IoT Greengrass をネットワークに制約がある環境で利用する場合の設定や構成例 AWS IoT Greengrass のセキュリティに関する機能や注意すべき点 スピーカー 中谷 友哉, 藤原 弘樹, 小坂 雄大 クラウドサポートエンジニア AWS MGN 大規模移行の計画と実行をお手軽にする便利な機能紹介編 AWS Application Migration Service (AWS MGN) は、お客様のアプリケーションを AWS に単純移行するために推奨される主要なサービスです。本コンテンツでは、大規模な移行、複数アカウントへの移行に活用できる AWS Application Migration Service の4つの機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS MGN を使用した大規模な移行における手順を簡素化したい方 AWS MGN を使用した複数アカウントへの移行を検討されている方 AWS MGN の機能についてより詳しく理解したい方 本 BlackBelt で学習できること AWS MGN の4つの機能（Application/Wave によるグルーピング、Import and Export 機能、Global View 機能、MGN Connector）の概要とメリット スピーカー 鈴木 槙将 ソリューションアーキテクト AWS Transit Gateway deep dive 本セッションでは AWS Transit Gateway の deep dive 編といたしまして、基礎的な概念や仕組みから、アーキテクチャパターン、見落としがちな注意点まで幅広くご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者 AWS のネットワーク設計を担当している方 AWS Transit Gateway について深く学びたい方 本 BlackBelt で学習できること 基礎的な概念や仕組みから、アーキテクチャパターン、見落としがちな注意点まで幅広くご紹介しています。 初学者から上級者まで AWS Transit Gateway の全てを学習できる内容となっています。 スピーカー 櫻井 俊和 シニアソリューションアーキテクト PrivateLink and Lattice – Amazon VPC Lattice Service 編 Amazon VPC Lattice は、異なる VPC や AWS アカウントにまたがるサービス間のネットワーク接続とアプリケーションレイヤールーティングを管理するサービスです。Blackbelt では、VPC Lattice の基本概念、構成要素、ユースケースについて学べます。 Resource Configuration などの利用については、PrivateLink and Lattice – AWS PrivateLink 編を公開予定です。そちらも合わせてご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon VPC Lattice について深く学びたい方 アプリケーションネットワークの構成でお悩みの方 異なる VPC 間のサービス通信の簡素化を目指している方 本 BlackBelt で学習できること Amazon VPC Lattice の概要 Amazon VPC Lattice の機能解説と使用方法 Amazon VPC Lattice のユースケース スピーカー 中本 翔太 ソリューションアーキテクト Amazon GuardDuty 基礎編 Amazon GuardDuty は、悪意のあるアクティビティや異常な動作をモニタリングし、 AWS 環境に対するセキュリティ脅威を検知するサービスです。本セミナーでは、Amazon GuardDuty の機能概要と調査方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon GuardDuty の使用を考えている方 Amazon GuardDuty がどのようなサービスか知りたい方 Amazon GuardDuty が検知した脅威の調査方法について知りたい方 本 BlackBelt で学習できること Amazon GuardDuty の機能の全体像や仕組みの理解 Amazon GuardDuty のデフォルト機能の詳細について Amazon GuardDuty を使用した基本的な調査の流れについて 他サービスを併用した脅威検知時の自動化や対応の流れについて スピーカー 藤田 皓大 クラウドサポートエンジニア Amazon Detective Amazon Detective は、AWS 環境におけるセキュリティ問題の調査と分析を支援するマネージドサービスであり、複雑なセキュリティインシデント調査を強力にサポートするサービスです。本セミナーでは、Amazon Detective の機能や利用方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS のセキュリティ運用を担当している方 クラウドセキュリティの可視化や調査機能に興味がある方 Amazon GuardDuty や AWS Security Hub をすでに有効化されている方 Amazon Detective について深く学びたい方 本 BlackBelt で学習できること Amazon Detective の各ユースケースにおける主要機能の理解 Amazon Detective を用いたセキュリティインシデントの調査方法 スピーカー 影山 諒 テクニカルアカウントマネージャー 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-02 AWS Database Migration Service ベストプラクティス – 運用・監視編 クラウドサポートエンジニア 大井 基彰 2025-03 AWS Database Migration Service トラブルシューティング クラウドサポートエンジニア 大石 明久 2025-03 AWS Well-Architected Framework 入門編 シニアパートナーソリューションアーキテクト 前田 賢介

Amazon Timestream for LiveAnalytics が AWS Database Migration Service (AWS DMS) のターゲットエンドポイントとして新たにサポートされました。この機能追加により、時系列データを AWS DMS でサポートされているソースデータベースから Timestream に移行できるようになります。 多くの業界のお客様が Timestream を採用して、リアルタイムの洞察を導き出し、重要なビジネスアプリケーションを監視し、Web サイトやアプリケーション全体にわたる何百万ものリアルタイムイベントを分析しています。AWS DMS の移行機能を使用する事で、ダウンタイムを削減しながら、既存の時系列データを移行し、進行中の時系列データを Timestream にレプリケートできるようになりました。尚、Timestream は AWS DMS Parallel Load および Parallel Apply 機能もサポートしているため、大量のデータを並行して処理可能であり、大幅に高速なデータ移行が可能になります。 本投稿では、AWS DMS でサンプル PostgreSQL ソースエンドポイントのターゲットとして Timestream を使用する方法を説明します。 ソリューションの概要 DMS で移行を設定するとき、ソースデータベースはデータが現在存在する場所であり、ターゲットデータベースはデータの転送先です。本投稿では、PostgreSQL ソースデータベースから Timestream ターゲットデータベースにデータを移行します。レプリケーションインスタンスは移行タスクを実行するコンポーネントであり、VPC 内のソースとターゲットの両方にアクセスする必要があります。本投稿では、まず Timestream データベースを設定し、データを移行するために AWS DMS に必要な AWS Identity and Access Management (IAM) アクセス許可を割り当てる方法を説明します。セットアップが完了したら、タスクを実行して、データが Timestream データベースに移行されたことを確認できます。 尚、AWS DMS Timestream エンドポイントは RDBMS ソース のみをサポートすることに注意してください。 前提条件 AWS DMS がどのように機能するかについて基本を理解している必要があります。AWS DMS を使い始めたばかりの場合は、 AWS DMS のドキュメント を確認してください。移行を実行するには、サポートされている AWS DMS ソース エンドポイントと Timestream ターゲットも必要です。 Timestream の IAM リソースの設定 Timestream データベースを AWS DMS ターゲットとして設定し、データ移行を開始するのは簡単です。まず、必要な権限を持つ IAM ロールを作成します。 IAM コンソールのナビゲーションペインで ポリシー を選択します。 ポリシーの作成 を選択します。 次のコードを使用して IAM ポリシーを作成します。 AWS リージョン、アカウント ID、データベース名を適宜更新します。本投稿では、ポリシーに dms-timestream-access という名前を付けます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDescribeEndpoints", "Effect": "Allow", "Action": [ "timestream:DescribeEndpoints" ], "Resource": "*" }, { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "timestream:ListTables", "timestream:DescribeDatabase" ], "Resource": "arn:aws:timestream: {region} : {account_id} :database/ {database_name} " }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "timestream:WriteRecords", "timestream:UpdateTable", "timestream:CreateTable" ], "Resource": "arn:aws:timestream: {region} : {account_id} :database/ {database_name} /*" } ] } このポリシーには、Timestream に対する 3 つの主要な権限が含まれています。 エンドポイントの参照権限 – Timestream エンドポイントを参照する機能を付与します。これは、他の Timestream アクセス許可と組み合わせて使用される DescribeDatabase 関数を使用する場合に重要です。 データベースの説明とテーブルリストへのアクセス – 特定のデータベースの説明を使用して、その存在と AWS DMS へアクセス可能かを確認できます。また、そのデータベース内のテーブルをリストすることもできます。これは、既存のテーブルを識別し、必要に応じて新しいテーブルを作成するために重要です。 データ挿入およびテーブル管理機能 – AWS DMS が Timestream にデータ挿入、テーブルの更新、またメモリまたはマグネティックストアの期間に変更が必要な場合に不可欠です。 これで、使用するロールに IAM ポリシーをアタッチできるようになりました。 IAM コンソールのナビゲーションペインで ロール を選択します。 ロールの作成 を選択します。 信頼されたエンティティタイプ で、 AWS サービス を選択します。 サービスまたはユースケース で、 DMS を選択します。 次へ を選択します。 ロールに名前を付けます (本投稿では、 dms-timestream-role という名前を付けます)。 作成したポリシーをアタッチします。 ロールを作成します。 Timestream データベースを作成する Timestream データベースを作成するには、次の手順を実行します。 Timestream コンソールのナビゲーションペインで データベース を選択します。 データベースを作成 を選択します。 設定を選択 で、 標準データベース を選択します。 名前 にデータベースの名前を入力します。 KMS キー は、キー ID を選択します。 データベースを作成 を選択します。 ターゲットの Timestream エンドポイントを作成する AWS DMS を使用して Timestream エンドポイントを設定するには、次の手順を実行します。 AWS DMS コンソールのナビゲーションペインで エンドポイント を選択します。 エンドポイントの作成 を選択します。 エンドポイントタイプ で、 ターゲットエンドポイント を選択します。 エンドポイント識別子 に、エンドポイントの名前を入力します (本投稿では、 timestream-target を使用します)。 ターゲットエンジン に、Amazon Timestream を選択します。 サービスアクセスロールの Amazon リソースネーム (ARN) に、前に作成したロール ( dms-timestream-role ) のロール ARN を入力します。 メモリストアの保持 については、ユースケースに応じて設定します。メモリストアの保持は時間単位で計算され、サポートされる範囲は 1 ～ 8,736 時間です。メモリストアは高速取り込み用に最適化されています。ベストプラクティスとして、移行するデータの大部分に対応できるようにメモリストアの保存期間を設定します。 マグネティックストアの保持 についても、ユースケースに応じて期間を設定します。 マグネティックストアの保持は日単位で測定され、サポートされる範囲は 1 ～ 73,000 日です。マグネティックストアはデフォルトでは読み取り専用ですが、エンドポイント設定を調整し、 EnableMagneticStoreWrites を true に設定することで書き込み機能を有効にできます。この変更を行うと、メモリストアの保存期間外のデータは、長期間保存するためにマグネティックストアに自動的に転送されます。マグネティックストアは履歴データを更新するように設計されており、大量の取り込みはサポートしていません。履歴データをマグネティックストアにロードすることが目的の場合は、AWS DMS を使用して CSV 形式で Amazon Simple Storage Service (Amazon S3) に移行してから、Timestream で バッチロード を使用することをお勧めします。マグネティックストアの保存期間より古い記録は自動的に削除されるため、保存期間の設定を慎重に検討する必要があります。 オプションとして、エンドポイントに CdcInsertsAndUpdates と EnableMagneticStoreWrites を設定できます。 CdcInsertsAndUpdates はブール型フィールドで、デフォルトでは false です。 true の場合、変更データキャプチャ (CDC) 中にソースデータベースへの削除操作の場合、Timestream への反映が行われません。 false の場合、ソースデータベースからデータ削除が行われるタイミングで Timestream へのデータ更新が行われます。これが望ましい動作である可能性がある理由は、本 Blog 執筆時点では、Timestream がレコード削除をサポートしていないためです。代わりに、AWS DMS は、数値タイプの場合は 0 の値、VARCHAR の場合は NULL 文字列、ブール値の場合は False を追加してレコードを null にします。これは、レコードにデータが含まれていないことを示すためです。削除する前の元のレコードを残しておきたい場合は、 CdcInsertsAndUpdates を true に設定します。 EnableMagneticStoreWrites もブール型フィールドです。デフォルトでは false です。 true の場合、メモリストアの保持期間外ではあるが、マグネティックストアの保持期間内であれば、レコードをマグネティックストアに直接書き込むことができます。但し、入力が大きいとスロットリングが発生するため、ほとんどのユースケースでは推奨されません。 EnableMagneticStoreWrites を true とするのは、一部のレコードがメモリストアの保存期間外にあり、それらのレコードをスキップしたくない場合を対象としています。 エンドポイントの作成 を選択して、ターゲットエンドポイントを作成します。 移行タスクを作成する Timestream ターゲットエンドポイントを使用して移行タスクを作成するには、次の手順を実行します。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。[ データベース移行タスクの作成 を選択します。 Timestream ターゲットで使用するレプリケーションインスタンスとソースデータベースエンドポイントを指定します。 ターゲットとして作成した Timestream エンドポイントを選択します。 完了したい移行のタイプに応じて、移行タスクを選択します。 タスク設定 セクションで、 JSON エディタ を選択し、それに応じて設定を調整します。 コードには次の主要なパラメータが含まれています。 ParallelLoadThreads – AWS DMS が各テーブルを Timestream ターゲットに最初にロードするために使用するスレッドの数を決定します。最大は 32 スレッドです。 ParallelLoadBufferSize – Timestream ターゲットの並列ロードスレッドによって使用されるバッファの最大レコード数を、デフォルトの 50 から最大 1,000 までの範囲で設定します。 ParallelLoadQueuesPerThread – ターゲットへのバッチロードのデータレコードを処理するために各スレッドがアクセスするキューの数を定義します。Timestream ターゲットのデフォルト設定は 1 で、範囲は 5 ～ 512 です。 ParallelApplyThreads – CDC ロード中に AWS DMS がデータを Timestream ターゲットにプッシュするために使用する同時スレッドの数を 0 ～ 32 の範囲の値で指定します。 ParallelApplyBufferSize – 各バッファーキューが保持できるレコードの最大数を示します。CDC ロード中に同時スレッドによってデータをタイムストリームターゲットにプッシュするために使用されます。デフォルトは 100、最大値は 1,000 です。 ParallelApplyQueuesPerThread – CDC 中に Timestream エンドポイントにバッチロードするデータレコードを抽出するためのスレッドあたりのキューの数を 1 ～ 512 の範囲で指定します。 これらのパラメータを設定する事で、レコード書き込みをバッチ処理で実施し、より高速な移行を有効にすることができます。 ParallelLoadQueuesPerThread および ParallelApplyQueuesPerThread のサイズは 100 に設定することをお勧めします。これは、Timestream への 1 回の書き込みあたりの最大レコード数であり、この方法で最高のスループットが得られるためです。 スループットに応じてスレッド数を調整する必要があります。 負荷に応じてスレッド毎のキューの数を調整する必要がありますが、インスタンスメモリをあまり消費しないように、50 程度の比較的低い値に設定すべきです。 Timestream ターゲットを使用して AWS DMS 移行タスクを設定する場合の最も重要な部分は、ソーステーブルが Timestream テーブルにどのようにマップされるかです。Timestream をターゲットとして使用する場合、Timestream には独自のマッピングルールがあります。いくつかのサンプルデータを使用して、これがどのように機能するかを見てみましょう。 テーブルが 2 つあるとして、1 つのテーブルは sensor_data 、もう 1 つのテーブルは sensors とします。次のスクリーンショットは、 sensor_data のデータの例を示しています。 このテーブルの作成に使用される SQL コマンドは次のとおりです。 CREATE TABLE sensor_data ( serial SERIAL PRIMARY KEY, sensor_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, temperature NUMERIC, humidity NUMERIC, light NUMERIC, co2 NUMERIC, humidityratio BOOLEAN ); 次のコマンドを使用して、テーブルにサンプルデータを入力します。 INSERT INTO sensor_data (sensor_time, temperature, humidity, light, co2, humidityratio) SELECT NOW() - (random() * (20 * INTERVAL '1 day')), (random() * (30 - 15) + 15)::NUMERIC(5,2), (random() * (90 - 10) + 10)::NUMERIC(5,2), (random() * (1000 - 10) + 10)::NUMERIC, (random() * (2000 - 300) + 300)::NUMERIC, (random() < 0.5)::BOOLEAN FROM generate_series(1, 10000); sensors テーブルの場合、データは重要ではありません。重要なのは、テーブルマッピングが Timestream の移行にどのような影響を与えるかを示すことです。 この例では、以下のようにテーブルマッピングを構成します。 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "{your_schema}", "table-name": "sensor_data" }, "rule-action": "include" }, { "rule-type": "object-mapping", "rule-id": "2", "rule-name": "timestream-map", "rule-action": "map-record-to-record", "object-locator": { "schema-name": "{your_schema}", "table-name": "sensor_data" }, "target-table-name": "sensor_data_timestream", "mapping-parameters": { "timestream-dimensions": [ "serial" ], "timestream-timestamp-name":"sensor_time" } } ] } 上のコードでは、 sensor_data テーブルのみをマッピングしています。サンプルデータではディメンジョン ( timestream-dimension )として serial を指定し、タイムスタンプ名 ( timestream-timestamp-name ) として sensor_time を設定します。 ディメンジョンとタイムスタンプ名は、Timestream のマッピングルールに必須です。 また、Timestream のマッピングルールを持つテーブルのみが移行されます。 使用可能なマッピングには次の 2 種類があります。 シングルメジャーマッピング – この場合、タイムスタンプまたはディメンション ( sensor_time および serial ) ではないすべての列が独自のレコードにマッピングされます。たとえば、 sensor_data テーブルについて考えてみましょう。ソースデータベース内の 1 レコード毎に、Timestream には 5 つのレコードが存在します。それぞれは同じ sensor_time と serial を持ちますが、温度のレコードが 1 つ、湿度のレコードが 1 つ、光のレコードが 1 つというような形で設定されます。 マルチメジャーマッピング – マルチメジャーマッピングを使用するには、 "timestream-timestamp-name":"sensor_time" と同じセクションに設定を追加します。ここで、マルチメジャーレコードのメジャー名として使用するソースの列を指定します。一例として、 serial: "timestream-multi-measure-name": "serial" のように記述して再利用してみましょう。これは、 serial の値が Timestream のディメンションだけでなくメジャー名としても使用されることを意味します。Timestream の結果は次のようになります。ソースデータベース内のレコード毎に、ディメンション: serial 、タイムスタンプ: sensor_time 、および serial の値のメジャー名を持つ 1 つのレコードが Timestream に存在します (最初の行の例では、このレコードは 1 になります)。このレコードには、ソースデータベースの各列のメジャー値が含まれます。マルチメジャーマッピングを使用する場合は、Timestream の 8,192 個の一意のメジャー名の制限に抵触しないように、通常は "timestream-hash-measure-name": True を使用する必要があります。詳細については、「 マルチメジャーレコードのパーティション化に関する推奨事項 」を参照してください。 本投稿では、単一メジャーマッピングを使用します。したがって、 sensor_data をマッピングするように設定すると、最初の選択ルールに sensors を追加した場合でも、 sensors は無視されます。 タスクの作成 を選択して、Timestream ターゲットエンドポイントを使用して移行タスクを作成します。 移行タスクの実行 タスクを開始するには、次の手順を完了してください。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。 作成したタスクを選択します。 アクション メニューで、 開始 を選択します。 Timestream データベースを監視して、移行アクティビティを表示できます。 移行の検証 データが Timestream にあることを確認するには、次の手順を実行します。 Timestream コンソールのナビゲーション ペインの 管理ツール で、 クエリエディター を選択します。 choose a database to query で、移行先のデータベースを選択します。 移行されたレコードの数を確認するには、次のクエリを入力します。 select count(*) from {your_db_name}."{your_table_name}" サンプルデータを表示するには、次のクエリを入力します。 select * from {your_db_name}."{your_table_name}” 少なくとも 10 行が移行されていると仮定すると、次のスクリーンショットに示すように、結果には選択したテーブル内の 10 行のレコードが表示されるはずです。 エラーハンドリング Timestream への移行時に直面する可能性のある一般的な問題を次に示します。 テーブルマッピングを作成するときは、 timestream-dimension と timestream-timestamp-name を必ず含めてください。また、 timestream-timestamp-name がソースデータベーステーブル内の実際の列であり、タイプが timestamp であり、大文字と小文字が正しいことを確認してください。次のコードを参照してください。 "mapping-parameters": { "timestream-dimensions": [ "serial" ], "timestream-timestamp-name":"sensor_time" } アクセスポリシーの IAM ロールに信頼関係として AWS DMS があることを確認します。これを確認するには、IAM コンソールで自分のロールに移動し、 信頼関係 を確認します。 ParallelLoad または ParallelApply を使用すると、インスタンスはより多くのメモリを使用します。メモリ不足が原因でタスクが失敗した場合は、インスタンスをスケーリングする必要があります。インスタンスのサイジングに関する推奨事項については、「 移行に適した AWS DMS レプリケーションインスタンスの選択 」を参照してください。 クリーンアップ 移行が完了したので、AWS DMS、Timestream、および IAM リソースをクリーンアップします。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。 作成したレプリケーションタスクを選択し、 アクション メニューで 削除 を選択します。 AWS DMS コンソールのナビゲーションペインで エンドポイント を選択します。 作成したエンドポイントを選択し、 アクション メニューで 削除 を選択します。 AWS DMS コンソールのナビゲーションペインで レプリケーションインスタンス を選択します。 作成したレプリケーションインスタンスを選択し、 アクション メニューで 削除 を選択します。 Timestream コンソールのナビゲーションペインで データベース を選択します。 削除するデータベースを選択し、 削除 を選択します。 IAM コンソールのナビゲーションペインで ロール を選択します。 作成したロールを選択し、 削除 を選択します。 IAM コンソールのナビゲーションペインで ポリシー を選択します。 作成したポリシーを選択し、 削除 を選択します。 これらの手順を完了したら、この投稿用に作成したすべてのリソースがクリーンアップされるでしょう。 結論 本投稿では、Timestream データベースを作成し、移行に必要なアクセス許可を AWS DMS に付与し、AWS DMS レプリケーションインスタンス、エンドポイント、タスクを作成することで、AWS DMS 移行をセットアップする方法を説明しました。次に、そのタスクを実行し、データが Timestream データベースに正常に移行されることを確認しました。これで、このタスクを独自のワークロードで実行できるようになりました。最後のステップ ( 移行タスクの作成と実行 ) は、AWS DMS タスク間で共通になりました。これにより、希望するリレーショナルデータベースから完全なエンドツーエンドの移行を実行し、データを Timestream データベースに表示できるようになります。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本記事は 2025 年 1 月 30 日に公開された “ Enhancing Code Generation with Real-Time Execution in Amazon Q Developer ” を翻訳したものです。 AI がソフトウェア開発における急速なイノベーションを推進する中で、高品質なコード生成を促進するためには、リアルタイムにテストできる信頼性の高い実行環境が不可欠です。開発者は、 AI が生成したコードがプロジェクトの要件を満たしているかを確認するためのデバッグと反復に多くの時間を費やし、その結果、機能の提供が遅れることもあります。以前の Amazon Q Developer の開発用エージェントはコード生成に重点を置いていました。最新のアップデートにより、エージェントはリアルタイムでコードをビルドしてテストし、開発者がレビューする前に変更を検証できるようになりました。この新機能は、コードレコメンデーションの品質向上、エラーの検出、生成されたコードとプロジェクトの最新状態の同期、そしてコード生成とテストワークフローの両方を効率化することによる開発プロセスの加速が含まれます。これらはコミュニティからのフィードバックに直接対応したものです。 自然言語による入力とプロジェクト固有のコンテキストにより、 Amazon Q Developer エージェント は複数のファイルにまたがる複雑な機能、バグ修正、テストスイートの実装を支援するように設計されています。たとえば、開発者は Amazon Q Developer エージェントに e コマースアプリケーションにチェックアウト機能を追加をリクエストするとしましょう。エージェントは既存のコードベースを分析し、ユニットテストの実行やコードのビルドを含め、数分以内にすべての必要なコード変更とテストを行い、コードがレビューの準備ができていることを確認します。このアプローチにより、開発効率が大幅に向上し、エラーが減少します。 IDE で Amazon Q Developer エージェントを使用するには、 Amazon Q 拡張機能をインストールし、チャットウィンドウで /dev コマンドを使用してリクエストを開始するだけです。 IDE で /dev コマンドが入力されると、エージェントはプロジェクトをパッケージ化して Amazon Q にセキュアな方法でアップロードし、プロジェクト固有のコード生成を開始します。 Amazon Q Developer エージェントは、単なるコード生成だけでなく、開発者とのリアルタイムな接続を維持し、プロセスの進捗を共有しながら、要求された機能のための洗練されたパッチや実装を提供します。 このリアルタイム実行は、開発環境とエージェントが使用できるコマンドを定義する Devfile によって動作します。プロジェクトに Devfile が存在しない場合、 /dev を初めて実行した際に Amazon Q Developer が作成を促します。Devfile がない場合でもエージェントはソリューションを開発できますが、ビルドや単体テストの実行によるフィードバックが得られないため、リアルタイムでの開発支援が制限されます。 Devfile は Devfile 2.2.0 スキーマ に準拠している必要があります。現在、 Amazon Q Developer は install 、 build 、および test コマンドをサポートしています。 Amazon Q Developer の最新アップデートにおける主な機能強化 カスタマイズ可能なコマンド: 開発者は Devfile でコマンドを指定することで、AI エージェントが実行するコマンドを制御できます。これにより、不要なステップを削減し精度を向上させることができます。 柔軟な環境セットアップ: 開発者は依存関係が事前に読み込まれたカスタム Docker イメージを使用して起動時間を短縮できます。これにより、エージェントに必要なツールをすべて備えた状態で動作できます。 サンドボックス化されたセキュリティ: Amazon Q Developer は、隔離された環境内で実行を安全に保護し、包括的なログ記録と堅牢なアクセス許可制御を提供して、行われた変更を保護します。 これらの仕組みにより、 Amazon Q Developer はサンドボックス内で直接テストを実行し、マイグレーションを適用し、インストールコマンドを実行して、反復的な改善のためにエージェントにフィードバックを提供できます。 セキュリティと隔離 AI によって生成されたコードの実行は、セキュリティ上慎重に扱う必要があるため、Amazon Q Developer エージェントはいくつかの保護機能を導入しています: 環境の隔離: コマンドは、非公開のインターネットリソースにアクセスするための認証情報が含まれない隔離された管理下のサンドボックス環境内で実行されます。この環境は、許可されたアクションのみが安全に実行されることを保証します。 Devfile 駆動: この機能には Devfile が必要で、 Devfile の設定により開発者は開発プロセス中にエージェントが使用するコマンドを制御できます。 Amazon Q Developer エージェントの開始方法 Amazon Q Developer を開始するには、 AWS Builder ID を持っているか、 Amazon Q の使用を許可する AWS IAM Identity Center インスタンスを持つ組織に所属している必要があります。 Visual Studio Code でソフトウェア開発に Amazon Q Developer エージェントを使用するには、まず Amazon Q 拡張機能 をインストールします。 Amazon Q Developer のページ で最新バージョンの拡張機能を見つけることができます。この拡張機能は、 JetBrains 、 Eclipse （プレビュー）、および Visual Studio IDE でも利用可能です。サポートされている IDE の詳細なリストと、各 IDE で利用可能な機能については、 Amazon Q Developer のドキュメント を参照してください。 認証後、 Amazon Q のチャットウィンドウで /dev と入力することで、機能開発エージェントを呼び出すことができます。 Amazon Q Developer は、 Amazon Q Developer エージェントによって生成されたコードを安全に実行するために、分離されたサンドボックス環境を活用します。これにより、生成されたコードを安全に実行し、元のコードベースと同期した状態を保ちます。プロセスの仕組みは以下の通りです： 実行環境の初期化: プロンプトを受け取ると、 Amazon Q Developer エージェントはサンドボックスインスタンスまたは開発者が指定した Docker コンテナを開始し、これをコード実行のためのサンドボックス環境として利用します。 安全なコマンド実行: Amazon Q Developer エージェントは、利用者にて定義した Devfile の仕様に基づいて、事前に指定されたシェルコマンドのリストを安全に実行します。 Devfile は開発環境の設定と依存関係をモデル化し、一貫した環境の再現を可能にし、手作業によるセットアップの労力を削減します。開発者は Devfile 内でカスタムコマンドを定義して、依存関係のインストール、テストの実行、データベースマイグレーションの適用、ビルドスクリプトの実行など、サンドボックス内のアクションを制御することで、精度と効率を向上させることができます。 フィードバックと同期: 各コマンドの実行後、コードの変更が追跡され、 AI エージェントにリアルタイムのフィードバックが提供されることで、反復的な改善が可能になります。 ユースケース例 1：既存のプロジェクトへのテストスイートの追加 GitHub の react-solitaire のような React ベースのアプリケーションの機能を強化したいとします。新機能を追加する際、既存の機能を維持し、アップデートのたびに壊れないようにすることが重要です。これを実現するために、継続的なテストとコードの反復のためのテストスイートを作成することを目指します。 これを説明するために、 GitHub から React プロジェクトをクローンし、環境と依存関係を定義する Devfile を追加します。 Devfile により、サンドボックス内でコードの変更を安全に実行・テストできるようになり、既存の機能に影響を与えずにアップデートを適用できます。 以下は React ベースのプロジェクトのシンプルな Devfile です。Devfile を使用すると、依存関係のインストール、プロジェクトのビルド、テストの実行 など、Amazon Q Developer が使用するコマンドを定義できます。 Example Devfile for a React-based Project schemaVersion: 2.0.0 components: - name: dev container: image: public.ecr.aws/aws-mde/universal-image:latest commands: - id: test exec: component: dev commandLine: "npm install && npm run test" リポジトリをクローンしたら、プロジェクトフォルダのルートに Devfile を配置します。次に、Visual Studio Code で Amazon Q のチャットを開き、 /dev コマンドを入力してリポジトリ用のカスタマイズされたテストスイートの作成を促します。 訳者注： Create test suite for my repo : このリポジトリのテストスイートを作って Amazon Q Developer エージェントはコードベースの分析を開始し、実施している変更や作業中のファイルについてリアルタイムで更新情報を共有します。エージェントはまずプロジェクト構造を調査し、必要な更新を計画し、そしてテストスイートを生成します。 数ステップの後、エージェントは必要なテストスイートを作成します。 その後、エージェントはテストを実行し、失敗がないか継続的に監視します。問題が検出された場合、すぐには停止せず、テストからのフィードバックに基づいてコードを積極的に改善し、このプロセスを最大3回繰り返します。3回の反復後も問題が解決しない場合、エージェントはプロセスを中止します。ただし、問題が修正された場合は、次のステップに進みます。たとえば、エージェントが Enzyme が React 18 をサポートしていないことを確認した際、その問題に対処し、テスト環境でテストを再実行しました。 問題が解決されると、エージェントは次のステップに進み、サンドボックスで変更したすべての変更とファイルを表示し、変更を受け入れるかフィードバックを提供するかを尋ねます。 出力に満足している場合は「Accept code」にて変更を受け入れることができ、満足していない場合は「Provide feedback & regenerate」にてエージェントにフィードバックを提供してコードの再生成を要求することができます。 ユースケース例 2：機能が更新された時のテストの再実行 テストの作成と実行に成功した後、エージェントは UI にゲーム名を表示する新機能を追加するよう指示されました。エージェントはリポジトリを分析し、更新が必要なファイルを特定し、変更を実装する正確な場所を決定しました。 更新を適用した後、エージェントはテストを実行して新機能を検証し、既存のコードベースとのシームレスな統合を促進し、開発プロセス全体を通じて信頼性を維持します。 エージェントによる変更を受け入れると、index.html ファイルが更新され、「Solitaire」というテキストが含まれるようになり、新しいコンテンツが既存のプロジェクトにスムーズに統合されます。 まとめ Amazon Q Developer のこの新しいアップデートの導入は、 AI 駆動の開発における重要な進歩を意味しています。これにより、 Amazon Q Developer エージェントはコード生成に重点を置いたツールから堅牢な実行エンジンへと進化しました。開発者がリアルタイムでコードの変更を検証およびテストできるようにすることで、 AI が生成するファイルと修正の正確性と信頼性を向上させることができます。 AWS のマネージドサンドボックスを使用したり、カスタム環境を持ち込んだりする柔軟なオプションにより、開発者は Amazon Q Developer エージェントの可能性を最大限に引き出すためのコントロールを得ることができます。この新しい実行機能により、チームはより迅速に反復し、十分な情報に基づいた調整を行い、ニーズに合わせた安全でインテリジェントなプラットフォームを活用できます。 VS Code または JetBrains の Amazon Q Developer の拡張機能 を更新またはインストールすることで、今すぐ試すことができます。 翻訳はApp Dev Consultantの宇賀神が担当しました。

私は 1 月 27 日週、バンコクで開催された AWS Community Day Thailand に参加し、すばらしい時間を過ごしました。このイベントは、 AWS アジアパシフィック (バンコク) リージョン の最近の立ち上げに続く、興奮が高まっている時期に開催されました。参加者は 300 名を超え、コミュニティからは AWS ヒーロー 1 名と AWS コミュニティビルダー 4 名を含む 15 名の講演者を招き、技術的な専門知識と経験を共有していただきました。 ハイライトは、AWS の Vice President & Chief Evangelist である Jeff Barr 氏による「Next-Generation Software Development」(次世代ソフトウェア開発) と題されるインスピレーションに満ちた基調講演でした。この基調講演により、この日の会場の空気は最高潮に達しました。この日は、AWS の Country Manager for Thailand である Vatsun Thirapatarapong の歓迎の挨拶で幕を開け、AWS ユーザーグループのボランティアと AWS タイチームの多大なサポートのおかげで、さらに特別な日となりました。 イベントの興奮を捉えた写真を次に示します: 1 月 27 日週の AWS のリリース 1 月 27 日週は 30 件以上のリリースがありましたが、私が注目したリリースをいくつかご紹介します: DeepSeek-R1 モデルが AWS で使用可能に – DeepSeek-R1 モデルを Amazon Bedrock と Amazon SageMaker AI にどのようにデプロイできるようになったのかについて、Channy が記事を書きました。これは、インフラストラクチャへの投資を最小限に抑えながら、生成 AI アプリケーションを構築およびスケールするのに役立ちます。 Amazon S3 Tables でテーブル制限がバケットあたり 10,000 に引き上げ – S3 Tables は、各テーブルバケットでの最大 10,000 個のテーブルの作成をサポートするようになりました。これにより、アカウントごとに 1 つの AWS リージョン内で 10 個のバケットにまたがって最大 100,000 個のテーブルにスケールできます。 Amazon S3 メタデータの一般提供を開始 – S3 メタデータは、簡単にクエリでき、自動化され、ほぼリアルタイムで更新されるメタデータを提供し、ビジネス分析とリアルタイム推論アプリケーションを簡素化します。AWS 分析サービスとの統合を含む、システム定義のメタデータとカスタムメタデータの両方をサポートします。 AWS Amplify が Lambda 関数用の TypeScript Data クライアントサポートを追加 – デベロッパーは、 AWS Lambda 関数内で Amplify Data クライアントを使用できるようになりました。これにより、フロントエンドとバックエンドのアプリケーション全体で一貫したタイプセーフなデータオペレーションが可能になります。 AWS Elastic Beanstalk が Amazon Linux 2023 で Python 3.13 、 .NET 9 、および PHP 8.4 のサポートを追加 – AWS Elastic Beanstalk は、Amazon Linux 2023 の強化されたセキュリティとパフォーマンス機能の恩恵を享受しながら、アプリケーションのデプロイに最新の言語機能と改善をもたらします。 community.aws より community.aws から、私が個人的に最も気に入っている 5 つの記事をご紹介します: Deploying DeepSeek-R1 Distill Llama Models on Amazon Bedrock (著者: Manu Mishra) Building Tile Slide (著者: Yash) Farm, Build, Fight! The survival RPG you never knew you needed (著者: AgentOk) PEP and PDP for Secure Authorization with Cognito (著者: Jimmy Dahlqvist) Q-Bits: Simplifying VPC configurations setup with AWS CloudFormation using Amazon Q Developer (著者: Suruchi Saxena) 今後予定されている AWS とコミュニティのイベント カレンダーを確認して、今後の AWS およびコミュニティのイベントにサインアップしましょう: AWS Korea re:Invent reCap Online (2 月 2 日～4 日) – re:Invent 2023 の主要な発表とイノベーションをまとめた、韓国のオーディエンス向けの仮想イベント。 AWS Community Day – 技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とするコミュニティ主導のカンファレンスに参加しましょう。次回の AWS Community Day は アフマダーバード (2 月 8 日) で開催予定です。 AWS Public Sector Day London (2 月 27 日) – 公共部門のリーダーやイノベーターとともに、AWS が政府、教育、医療の分野でデジタルトランスフォーメーションをどのように実現しているのかを詳しく見ていきます。 AWS Innovate GenAI + Data Edition – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンス。複数のリージョンで開催されます: APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日)。 今後開催予定の AWS 主導の対面イベント と、 デベロッパー向けの仮想イベント をさらにご覧ください。 AWS コミュニティ re:Invent re:Caps 最後に、AWS re:Invent の主要な発表やイノベーションについて知りたい場合は、AWS コミュニティがコミュニティの観点でこれらの発表の概要を共有しているので、最新情報を入手できます。 AWS コミュニティ re:Invent re:Caps デッキ をダウンロードしてください。 2 月 3 日週はここまでです。2 月 10 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024 年 12 月 2 日から 6 日の AWS re:Invent で、Amazon の CEO であるアンディー ジャシーは、Amazon が社内で約 1,000 の 生成 AI アプリケーションを開発した経験から得た 有益な教訓を共有しました 。ジャシーは、この大規模な AI デプロイから引き出した 3 つの重要な見解を示しました。これらの見解が Amazon のエンタープライズ AI 実装へのアプローチを形作りました。 1 つ目は、生成 AI アプリケーションをスケールするにつれて、コンピューティングコストが非常に重要になるということです。人々は、より優れた料金パフォーマンスを強く望んでいます。2 つ目は、本当に優れた生成 AI アプリケーションを構築するのは、実際にはかなり難しいということです。3 つ目は、やりたいことを選ぶ自由をビルダーに与えたときに使用されるモデルが多様であるということです。これは驚くことではありません。なぜなら、私たちは同じ教訓を何度も何度も学んでいるからです。それは、世界を支配するツールは 1 つだけではないということです。 アンディーが強調したように、Amazon が提供する幅広く奥深いモデルにより、お客様は独自のニーズにとって最適な機能を正確に選択できます。AWS は、お客様のニーズと技術の進歩の両方を注意深くモニタリングすることで、厳選されたモデルのセレクションを定期的に拡大し、業界で定評のあるモデルに加えて、有望な新しいモデルも含めるようにしています。この高性能で差別化されたモデルオファリングのこの継続的な拡大は、お客様が AI イノベーションの最前線に留まるのに役立ちます。 これが中国の AI スタートアップである DeepSeek につながります。DeepSeek は 2024 年 12 月に DeepSeek-V3 をリリースし、その後、2025 年 1 月 20 日に DeepSeek-R1 、6,710 億のパラメータを備えた DeepSeek-R1-Zero、および 15 億～700 億のパラメータを備えた DeepSeek-R1-Distill モデルをリリースしました。同社は 2025 年 1 月 27 日に、ビジョンベースの Janus-Pro-7B モデルを追加しました。これらのモデルは公開されており、 同等のモデルよりも 90～95% 手頃な料金でコスト効率が高いと言われています 。DeepSeek によると、同社のモデルは、強化学習などの革新的なトレーニング手法を通じて実現された推論機能に強みを持っています。 1 月 30 日より、 Amazon Bedrock と Amazon SageMaker AI で DeepSeek-R1 モデルをデプロイできるようになりました 。Amazon Bedrock は、API を通じて事前トレーニング済みの基盤モデルを迅速に統合したいチームに最適です。Amazon SageMaker AI は、高度なカスタマイズ、トレーニング、デプロイと、基盤となるインフラストラクチャへのアクセスを希望する組織に最適です。さらに、 AWS Trainium と AWS Inferentia を使用して、 Amazon Elastic Compute Cloud (Amazon EC2) または Amazon SageMaker AI を介して DeepSeek-R1-Distill モデルをコスト効率よくデプロイすることもできます。 AWS を利用して、インフラストラクチャ投資を最小限に抑えながら、この強力でコスト効率の高い DeepSeek-R1 モデルを使用することで、生成 AI のアイデアを構築および実験し、責任をもってスケールできます。また、セキュリティのために独自に設計された AWS のサービス上に構築することで、自信をもって生成 AI イノベーションを推進できます。Amazon Bedrock と Amazon SageMaker AI の両方のお客様が使用できる生成 AI アプリケーション用に保護レイヤーを追加するために、DeepSeek-R1 モデルのデプロイを Amazon Bedrock ガードレール と統合することを強くお勧めします。 1 月 30 日、DeepSeek-R1 モデルを AWS にデプロイする方法はいくつかあります: 1) Amazon Bedrock Marketplace (DeepSeek-R1 モデル) 、 2) Amazon SageMaker JumpStart (DeepSeek-R1 モデル) 、 3) Amazon Bedrock Cust om Model Import (DeepSeek-R1-Distill モデル) 、 4) Amazon EC2 Trn1 インスタンス (DeepSeek-R1-Distill モデル) 。 AWS で DeepSeek-R1 モデルの使用を開始するためのさまざまな方法をご紹介します。初めての AI アプリケーションを構築する場合でも、既存のソリューションをスケールする場合でも、これらの方法はチームの専門知識と要件に基づいた柔軟な開始点を提供します。 1.Amazon Bedrock Marketplace の DeepSeek-R1 モデル Amazon Bedrock Marketplace は、Amazon Bedrock の業界をリードするモデルの現在のセレクションに加えて、100 を超える人気、新興、および専門的な FM を提供しています。単一のカタログでモデルを簡単に見つけ、モデルをサブスクライブしてから、マネージドエンドポイントにモデルをデプロイできます。 Amazon Bedrock Marketplace の DeepSeek-R1 モデルにアクセスするには、 Amazon Bedrock コンソール に移動し、 [基盤モデル] セクションの [モデルカタログ] を選択します。モデルプロバイダーで検索またはフィルタリングすることで、DeepSeek を迅速に見つけることができます。 モデルの機能を含むモデルの詳細ページや実装ガイドラインを確認した後、エンドポイント名を指定し、インスタンスの数を選択して、インスタンスタイプを選択することで、モデルを直接デプロイできます。 また、VPC ネットワーキング、サービスロールの許可、暗号化の設定など、DeepSeek-R1 モデルのセキュリティとインフラストラクチャの設定をカスタマイズできるようにする高度なオプションを設定することもできます。本番デプロイの場合、組織のセキュリティとコンプライアンスの要件に合わせてこれらの設定を確認する必要があります。 Amazon Bedrock ガードレールを使用すると、ユーザー入力とモデル出力を個別に評価できます。生成 AI アプリケーションで望ましくない有害なコンテンツをフィルタリングすることで、定義した一連のポリシーを使用してユーザーと DeepSeek-R1 間のインタラクションを制御できます。Amazon Bedrock Marketplace の DeepSeek-R1 モデルは、Bedrock の ApplyGuardrail API でのみ使用でき、Amazon Bedrock の外部で使用可能なカスタム FM とサードパーティー FM のユーザー入力とモデル応答を評価できます。詳細については、「 Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する 」をお読みください。 Amazon Bedrock ガードレールは、 Amazon Bedrock エージェント や Amazon Bedrock ナレッジベース などの他の Bedrock ツールと統合して、責任ある AI ポリシーに整合した、より安全でセキュアな生成 AI アプリケーションを構築することもできます。詳細については、 AWS の責任ある AI ページにアクセスしてください。 Amazon Bedrock Marketplace で DeepSeek-R1 モデルをデプロイする方法については、このステップバイステップガイドをご覧ください。詳細については、「 Deploy models in Amazon Bedrock Marketplace 」にアクセスしてください。 2.Amazon SageMaker JumpStart の DeepSeek-R1 モデル Amazon SageMaker JumpStart は、FM、組み込みアルゴリズム、および数回クリックするだけでデプロイできる事前構築済みの機械学習 (ML) ソリューションを備えた ML ハブです。SageMaker JumpStart で DeepSeek-R1 をデプロイするには、 SageMaker Unified Studio 、 SageMaker Studio 、 SageMaker AI コンソール で DeepSeek-R1 モデルを見つけるか、または SageMaker Python SDK を通じてプログラムを使用して見つけることができます。 Amazon SageMaker AI コンソール で、SageMaker Unified Studio または SageMaker Studio を開きます。SageMaker Studio の場合は、 [JumpStart] を選択し、 [すべてのパブリックモデル] ページで「 DeepSeek-R1 」を検索します。 モデルを選択し、デプロイを選択して、デフォルト設定でエンドポイントを作成できます。エンドポイントが [InService] になると、そのエンドポイントにリクエストを送信して推論を行うことができます。 Amazon SageMaker AI の機能 ( Amazon SageMaker Pipelines 、 Amazon SageMaker Debugger 、コンテナログなど) を使用して、モデルのパフォーマンスと ML オペレーションのコントロールを導き出すことができます。モデルは AWS の安全な環境にデプロイされ、仮想プライベートクラウド (VPC) の制御下にあるため、データセキュリティのサポートに役立ちます。 Bedrock Marketpalce と同様に、SageMaker JumpStart の ApplyGuardrail API を使用して、生成 AI アプリケーション用のセーフガードを DeepSeek-R1 モデルからデカップリングできます。FM を呼び出さずにガードレールを使用できるようになったため、使用するモデルにかかわらず、標準化され、徹底的にテストされたエンタープライズセーフガードをアプリケーションフローにさらに統合できるようになりました。 Amazon SageMaker JumpStart で DeepSeek-R1 をデプロイする方法については、このステップバイステップガイドをご覧ください。詳細については、「 Discover SageMaker JumpStart models in SageMaker Unified Studio 」または「 Deploy SageMaker JumpStart models in SageMaker Studio 」にアクセスしてください。 3.Amazon Bedrock カスタムモデルインポートを使用した DeepSeek-R1-Distill モデル Amazon Bedrock カスタムモデルインポート では、基盤となるインフラストラクチャを管理することなく、単一のサーバーレス統合 API を通じて、カスタマイズされたモデルをインポートして既存の FM とともに使用できます。Amazon Bedrock カスタムモデルインポートを使用すると、15 億～700 億のパラメータを含む DeepSeek-R1-Distill Llama モデルをインポートできます。 Amazon Bedrock モデル蒸留に関する私のブログ記事 でご紹介したとおり、蒸留プロセスでは、6,710 億のパラメータを持つ大規模な DeepSeek-R1 モデルを教師モデルとして使用して、その動作と推論パターンを模倣するように、より小さく効率的なモデルをトレーニングします。 これらの公開モデルを Amazon Simple Storage Service (Amazon S3) バケットまたは Amazon SageMaker Model Registry に保存した後、 Amazon Bedrock コンソール 内で [基盤モデル] の [インポートされたモデル] に移動し、Amazon Bedrock を通じてフルマネージドサーバーレス環境にインポートしてデプロイします。このサーバーレスアプローチは、エンタープライズグレードのセキュリティとスケーラビリティを提供しながら、インフラストラクチャ管理の必要性をなくします。 Amazon Bedrock カスタムモデルインポートを使用して DeepSeek-R1 モデルをデプロイする方法については、この ステップバイステップガイド をご覧ください。詳細については、「 Import a customized model into Amazon Bedrock 」にアクセスしてください。 4.AWS Trainium と AWS Inferentia を使用した DeepSeek-R1-Distill モデル AWS Deep Learning AMI (DLAMI) は、小規模な CPU のみのインスタンスから最新の高性能マルチ GPU インスタンスまで、さまざまな Amazon EC2 インスタンスで深層学習に使用できるカスタマイズされたマシンイメージを提供します。DeepSeek-R1-Distill モデルを AWS Trainuim1 または AWS Inferentia2 インスタンスにデプロイして、極めて高いコストパフォーマンスを実現できます。 使用を開始するには、 Amazon EC2 コンソール に移動し、Deep Learning AMI Neuron (Ubuntu 22.04) と呼ばれる Neuron Multi Framework DLAMI を使用して trn1.32xlarge EC2 インスタンスを起動します。 起動した EC2 インスタンスに接続したら、 大規模言語モデル (LLM) を提供するオープンソースツールである vLLM をインストールし、Hugging Face から DeepSeek-R1-Distill モデルをダウンロードします。vLLM を使用してモデルをデプロイし、モデルサーバーを呼び出すことができます。 詳細については、AWS Inferentia および Trainium に DeepSeek-R1-Distill Llama モデルをデプロイする方法に関するこの ステップバイステップガイド をご覧ください。 Hugging Face で DeepSeek-R1-Distill-Llama-8B または deepseek-ai/DeepSeek-R1-Distill-Llama-70B モデルカードにアクセスすることもできます。 [デプロイ] を選択し、次に [Amazon SageMaker] を選択します。 [AWS Inferentia および Trainium] タブから、DeepSeek-R1-Distill Llama モデルをデプロイするためのサンプルコードをコピーします。 DeepSeek-R1 のリリース以降、Amazon EC2 および Amazon Elastic Kubernetes Service (Amazon EKS) へのデプロイに関するさまざまなガイドが公開されています。確認すべき追加資料をいくつか次に示します: Leveraging DeepSeek-R1 with CPU and GPU options on AWS (著者: Daniel Wirjo ) Benefits of installing DeepSeek on an Amazon EC2 instance (著者: Enrique Aguilar Martinez ) Deploying DeepSeek Llama models on Amazon EC2 inferentia instance (著者: Irshad Chohan ) How to deploy and fine-tune DeepSeek models on AWS (著者: Hugging Face ) Hosting DeepSeek-R1 on Amazon EKS Auto Mode (著者: Tiago Reichert ) 知っておくべきこと 知っておくべき重要な事項をいくつか次に示します。 料金 – DeepSeek-R1 などの公開モデルの場合、Amazon Bedrock Markeplace、Amazon SageMaker JumpStart、および Amazon EC2 のために選択した推論インスタンス時間に基づいて、インフラストラクチャ料金のみが課金されます。Bedrock カスタムモデルのインポートの場合、アクティブなカスタムモデルのコピー数に基づいて、モデル推論についてのみ、5 分単位で課金され。詳細については、 Amazon Bedrock の料金 、 Amazon SageMaker AI の料金 、および Amazon EC2 の料金 のページをご覧ください。 データセキュリティ – Amazon Bedrock と Amazon SageMaker のエンタープライズグレードのセキュリティ機能は、データとアプリケーションを安全かつプライベートにするのに役立ちます。これは、データがモデルプロバイダーと共有されず、モデルの改善にも使用されないことを意味します。これは、Amazon Bedrock と Amazon SageMaker の DeepSeek-R1 モデルなど、すべてのモデル (独自モデルおよび公開モデル) に適用されます。詳細については、「 Amazon Bedrock のセキュリティとプライバシー 」と「 Security in Amazon SageMaker AI 」にアクセスしてください。 今すぐご利用いただけます DeepSeek-R1 は現在、Amazon Bedrock Marketplace および Amazon SageMaker JumpStart で一般提供されています。Amazon Bedrock カスタムモデルインポートと、AWS Trainum および Inferentia チップを搭載した Amazon EC2 インスタンスを使用して、DeepSeek-R1-Distill モデルを使用することもできます。 Amazon Bedrock コンソール 、 Amazon SageMaker AI コンソール 、 Amazon EC2 コンソール で DeepSeek-R1 モデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock および AWS re:Post for SageMaker AI に、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2025 年 1 月 22 日に公開された Blog “ Announcing upcoming changes to the AWS Security Token Service global endpoint ” を翻訳したものです。 AWS は、2011 年 8 月に、AWS 米国東部 (バージニア北部) リージョンでホストされている単一のグローバルエンドポイント (https://sts.amazonaws.com) で AWS Security Token Service (AWS STS) をリリースしました。単一のリージョンへの依存を減らすために、AWS は 2015 年 2 月に AWS STS リージョンエンドポイント ( https://sts. {Region_identifier} . {partition_domain} ) をリリースしました。これらのリージョンエンドポイントを使用すると、ワークロードと同じリージョンで STS を使用できるため、パフォーマンスと信頼性が向上します。 しかし、多くのお客様やサードパーティのツールは引き続き STS グローバルエンドポイントを呼び出しており、その結果、これらのお客様は STS リージョンエンドポイントのメリットを受けられていません。今回、アプリケーションの耐障害性とパフォーマンスを向上させるために、お客様側での対応を必要とせずに、STS グローバルエンドポイントに変更を加えることにしました。これらの変更は今後数週間でリリースされる予定です。 本ブログでは、STS グローバルエンドポイントの今後の変更とその利点について説明し、今後使用する STS エンドポイントに関する推奨事項を説明します。 STS グローバルエンドポイントの変更点 STS グローバルエンドポイントに加えられる変更は、信頼性を高め、パフォーマンスを向上させるのに役立ちます。2025 年 1 月現在、STS グローバルエンドポイントへのすべてのリクエストは、米国東部 (バージニア北部) リージョンで処理されています。2025 年初頭から、STS グローバルエンドポイントへのリクエストは、AWS にデプロイされたワークロードと同じリージョンで自動的に処理されるようになります。例えば、アプリケーションが米国西部 (オレゴン) リージョンから sts.amazonaws.com を呼び出す場合、その呼び出しは米国東部 (バージニア北部) リージョンではなく、米国西部 (オレゴン) リージョンでローカルに処理されます。 この変更により、リクエストが デフォルトで利用可能なリージョン から送信された場合、STS グローバルエンドポイントへのリクエストはローカルで処理されます。 1 ただし、リクエストがオプトインが必要なリージョンから送信された場合、または AWS 外部 (オンプレミスネットワークやデータセンターなど) から STS を使用する場合、STS グローバルエンドポイントへのリクエストは引き続き米国東部 (バージニア北部) リージョンで処理されます。 この変更は、デフォルトで利用可能な AWS リージョンに 2025 年半ばまでに順次展開されます。まず欧州 (ストックホルム)から開始予定です。 既存のプロセスの中断を防ぐために、以下の対策を講じています AWS CloudTrail では、STS グローバルエンドポイントに対するリクエストのログは、リクエストがローカルで処理された場合でも、米国東部 (バージニア北部) リージョンに送信されます。STS リージョンエンドポイントに対するリクエストの処理は、引き続き CloudTrail のそれぞれのリージョンに記録され続けます。 STS グローバルおよびリージョンエンドポイントによって実行された操作の CloudTrail ログには、 endpointType と awsServingRegion の追加フィールドが含まれ、リクエストを提供したエンドポイントとリージョンを明確にします。 sts.amazonaws.com エンドポイントに対するリクエストは、どのリージョンがリクエストを処理したかに関係なく、 aws:RequestedRegion 条件キーの値として us-east-1 になります。 sts.amazonaws.com エンドポイントによって処理されたリクエストは、STS リージョンエンドポイントとリクエストクォータを共有しません。 1. さらに、ローカルでリクエストを処理するには、 sts.amazonaws.com への DNS リクエストを、Amazon Virtual Private Cloud (Amazon VPC) の Amazon DNS サーバー (Amazon Route 53 Resolver) で処理する必要があります。 推奨事項 可能な限り、適切な STS リージョンエンドポイント を使用することを引き続き推奨します。オンプレミスのネットワークやデータセンターなど、AWS の外部から STS を使用している場合は、STS 認証情報を使ってアクセスしたい AWS リソースと、同じリージョンの STS リージョンエンドポイントを使用することを推奨します。アジアパシフィック (香港) やアジアパシフィック (ジャカルタ) などのオプトインリージョンで開発している場合、ワークロードをホストしているオプトインリージョンの STS エンドポイントを使用することを推奨します。ブログ記事 リージョナル AWS STS エンドポイントの使用方法 の手順に従うことで、まだグローバル STS エンドポイントを使用しているワークロードを特定し、必要に応じて再構成する方法についての手順や方法を理解することができます。 このブログについて質問がある場合は、 AWS Support に連絡 してください。 Palak Arora Palak は AWS Identity の Senior Product Manager です。彼女は 8 年以上のサイバーセキュリティ経験を持ち、特に Identity and Access Management (IAM) 分野に特化しています。彼女は様々な業界の顧客がエンタープライズおよび顧客の IAM ロードマップと戦略を定義し、全体的な技術リスク環境を改善するのを支援してきました。 Liam Wadman Liam は AWS Identity チームの Principal Solutions Architect です。AWS でエキサイティングなソリューションを構築したり、顧客を支援したりしていないときは、ブリティッシュコロンビアの丘でマウンテンバイクに乗っていることが多いです。Liam は、LIAM を綴るには IAM が欠かせないと指摘します。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。