このブログ記事は Senior Solutions Architect の Dmitriy Novikov と Senior Edge Specialist Solutions Architect の Harith Gaddamanugu によって書かれました。 ネットワークセキュリティオペレーターの多くの方にとって、アプリケーションの稼働時間を守ることは、ネットワークトラフィックのベースラインを設定し、不審な送信者を調査し、リスクを軽減するための最善の方法を決定するという、時間のかかる課題となっています。このプロセスを簡素化し、常にネットワークセキュリティの状態を把握することが、セキュリティオペレーションスタッフを増員することなくアプリケーションを拡張しようとしている IT 組織の目標となっています。この課題に対処するため AWS WAF でアプリケーションを保護している場合に、セキュリティ状況に関する十分な情報に基づいて意思決定ができるようにするための AWS WAF traffic overview ダッシュボード を導入しました。 この記事では新しいダッシュボードを紹介し、AWS WAF を使用してアプリケーションの全体的なセキュリティを把握して、ダッシュボードから得られる洞察に基づいて意思決定できるようにするための、いくつかのユースケースを詳しく説明します。 Traffic overview ダッシュボードの紹介 AWS WAF の Traffic overview ダッシュボードには、セキュリティ関連のメトリクスが表示されるため、分散型サービス拒否 (DDoS) イベント発生時に レートベースのルール を追加するなど、数クリックでセキュリティリスクを特定して対処できます。これらのダッシュボードには、AWS WAF がアプリケーションの Web トラフィックを評価する際に収集する Amazon CloudWatch メトリクスをほぼリアルタイムで表示することができます。 これらのダッシュボードはデフォルトで利用できるため、追加の設定は必要ありません。AWS WAF で監視する各 Web ACL について合計リクエスト数、ブロックされたリクエスト数、許可されたリクエスト数、ボットと非ボットのリクエストの割合、ボットカテゴリ、CAPTCHA 解決率、上位 10 件のマッチしたルールなどのメトリクスが表示されます。 総リクエスト数、ブロックされたリクエスト数、ブロックされた一般的な攻撃などのデフォルトメトリクスにアクセスすることも、最も重要なメトリクスと視覚化を選んでダッシュボードをカスタマイズすることもできます。 これらのダッシュボードは可視性を高め、以下のような質問に答えることができます: AWS WAF で検査されたトラフィックの何%がブロックされていますか? ブロックされているトラフィックの主な発信国はどこですか? AWS WAF が検知して保護している攻撃は何ですか? 今週のトラフィックパターンは先週と比べてどうですか? ダッシュボードには CloudWatch との間でネイティブかつシームレスな統合が用意されており、ダッシュボードと CloudWatch を行き来しながら、より詳細なメトリクスを CloudWatch で確認することができます。また、既存の CloudWatch ウィジェットやメトリクスを Traffic overview ダッシュボードに追加し、実績のある可視性をダッシュボードに取り込むこともできます。 Traffic overview ダッシュボードの導入とともに、AWS WAF の Sampled requests は Web ACL 内のスタンドアロンタブになりました。このタブでは、AWS WAF が検査した Web リクエストのルールマッチのグラフを確認できます。さらに、リクエストサンプリングを有効にしている場合、AWS WAF が検査した Web リクエストのサンプルをテーブルビューで確認できます。 リクエストのサンプルには Web ACL のルールの条件に一致した最大 100 件のリクエストと、ルールに一致せず Web ACL のデフォルトアクションが適用されたリクエスト 100 件が含まれます。サンプル内のリクエストは、過去 3 時間以内にコンテンツへのリクエストを受信した保護リソースからのものです。 以下の図は Traffic overview ダッシュボードのレイアウトの一例を示しています。ここでは攻撃タイプ、クライアントデバイスタイプ、国別などのアクションの取れる洞察が、表示されるカテゴリごとに検査されたリクエストが分類されています。この情報と期待するトラフィックプロファイルを比較することで、さらに調査する必要があるか、すぐにトラフィックをブロックするかを判断できます。図1 の例では、Web アプリケーションがフランスからのトラフィックを想定しておらず、デスクトップ専用のアプリケーションである場合、モバイルデバイスからのフランス発信のリクエストをブロックすることを検討するかもしれません。 図1: 複数のカテゴリを示すセクションがあるダッシュボード ユースケース1: ダッシュボードを使用してトラフィックパターンを分析する Webトラフィックの可視化に加えて、新しいダッシュボードを使って潜在的な脅威や問題を示すパターンを分析できます。ダッシュボードのグラフやメトリクスを確認することで、さらなる調査が必要な異常なトラフィックの増加や減少を発見できます。 トップレベルの Traffic overview では、ハイレベルのトラフィックとパターンが表示されます。そこから、特定のルールやルールグループの傾向とメトリクスを確認するために Web ACL メトリクスに掘り下げることができます。ダッシュボードには許可されたリクエスト、ブロックされたリクエストなどのメトリクスが表示されます。 予想されるトラフィックパターンからの逸脱に関する通知やアラートは、イベントを探る合図となります。探索中、ダッシュボードを使ってイベントを孤立させるのではなく、より広い文脈を理解できます。これにより、セキュリティイベントや設定ミスのルールを示す異常なトレンドを検出するのが簡単になります。例えば、通常は特定の国から 1 分あたり 2,000 件のリクエストがあるサービスで、突如 1 万件のリクエストがあった場合は調査する必要があります。ダッシュボードを使用すると、さまざまな側面からトラフィックを確認できます。リクエストの増加だけでは脅威の明確な兆候とはならないかもしれませんが、予期せぬデバイスタイプなどの別の兆候があれば、フォローアップ対応を取る十分な理由となります。 次の図は Web ACL のルールによるアクションと、最も一致したルールを示しています。 図2: ウェブリクエストの多次元的なダッシュボード このダッシュボードでは、時間経過に伴うブロックされたリクエストとアクセス許可されたリクエストのトップも表示されます。ブロックされたリクエストの異常なスパイクが、特定の IP アドレス、国、またはユーザーエージェントからのトラフィックのスパイクに対応しているかどうかを確認してください。これは、悪意のある活動またはボットトラフィックの試みを示している可能性があります。 次の図は、特定のベクターが保護されたウェブアプリケーションに対して使用されていることを示す、ルールへのマッチ件数が不相応に多いことを示しています。 図3: 最上位のルールは、攻撃のベクトルを示している可能性があります 同様に上位の許可されたリクエストを確認してください。特定のURLへのトラフィックに急増が見られた場合は、アプリケーションが適切に機能しているかどうかを調査する必要があります。 トラフィックを分析した後の次のステップ トラフィックパターンを分析した後、検討すべき次のステップは以下の通りです。 調査結果に基づいて、正常または悪意のあるトラフィックとより一致するように AWS WAF ルールを調整します。 正規表現 や条件を調整することで、False Positive（偽陽性）や False Negative（偽陰性）を減らすことができるかもしれません。正常なトラフィックをブロックしているルールを調整します AWS WAF のロギング を設定し、専用のセキュリティ情報およびイベント管理 （SIEM）ソリューションがある場合は、異常に対する自動アラートを可能にするためにロギングを統合します 既知の悪意のある IP を自動的にブロックするように AWS WAF を設定します。特定された脅威の発信元に基づいて IP ブロックリストを維持できます。さらに Amazon 脅威リサーチチームが定期的に更新する、 Amazon IP レピュテーションリスト のマネージドルールグループを使用できます 特定のページへのトラフィックの急増が見られた場合は、不審なパターンの原因がアプリケーションの問題でないかをチェックします トラフィックフローで新しい攻撃パターンを発見した場合は、それをブロックする新しいルールを追加します。次に、メトリクスを確認して、新しいルールの影響を確認します DDoS 攻撃やその他の悪意のあるトラフィックのスパイクのために送信元 IP を監視します。レートベースのルールを使って、これらのスパイクを緩和するのに役立ちます トラフィックフラッディングが発生した場合は、DDoS 保護付きの CloudFront を使用して、追加の保護レイヤを実装します 新しいダッシュボードにより、アプリケーションに到達するトラフィックについて貴重な洞察が得られ、トラフィック分析における推測の必要がなくなります。得られた洞察を活用して AWS WAF の保護を細かく調整し、可用性やデータが影響を受ける前に脅威をブロックできます。潜在的な脅威を検出し、保護を最適化するための情報に基づいた決定を行うために、データを定期的に分析してください。 例えば、ダッシュボードで過去のトラフィックパターンと比べて、トラフィックが発生すると予測していない国から不審な急増があった場合、Web ACL に 地理的一致ルールステートメント を作成して、そのトラフィックが Web アプリケーションに到達するのを防ぐことができます。 このダッシュボードは、洞察を得るための優れたツールであり、AWS WAFマネージドルールがトラフィックを保護する方法を理解するのに役立ちます。 ユースケース2: オンボーディング中のボットトラフィックを理解し、Bot Control ルールグループを細かく調整する AWS WAF Bot Control を使用するとスクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。ルールグループのターゲットインスペクションレベルを使用すると、自己識別しないボットにチャレンジできるため、悪意のあるボットがWebサイトに対して操作することが困難になり、コストがかかります。 Traffic overview ダッシュボードの Bot Control タブでは、現在のトラフィックの内、ボットからのものがどの程度か (Bot Control を有効にしていない場合はリクエストのサンプリング、有効にしている場合は実時間の CloudWatch メトリクスに基づいて) 確認できます。 オンボーディングフェーズではこのダッシュボードを使用してトラフィックを監視し、さまざまなタイプのボットからのトラフィックがどの程度あるかを理解します。これをボット管理のカスタマイズの出発点として利用できます。例えば Bot Control ルールグループをカウントモードで有効にし、望ましいトラフィックが誤ってラベル付けされていないか確認できます。次に、「 AWS WAF Bot Control の例: 特定のブロックされたボットを許可する 」で説明されているように、ルールの例外を追加できます。 次の図はボットによって生成、検出されたリクエストのさまざまな次元を視覚化するウィジェットのコレクションを示しています。カテゴリとボリュームを理解することでさらにログを詳しく調査すべきか、望ましくないトラフィックはそのカテゴリをブロックするか情報に基づいた決定を下すことができます。 図4: ダッシュボード上のボット関連メトリックのコレクション 開始した後は同じダッシュボードを使って、ボットトラフィックを監視し、自己識別しない高度なボットに対するターゲット検出を追加するかどうかを評価できます。ターゲット保護ではブラウザ問い合わせ、フィンガープリンティング、行動のヒューリスティクスなどの検出手法を使用して、悪意のあるボットトラフィックを特定します。AWS WAF トークンはこれらの高度な保護に不可欠です。 AWS WAF はサイレントチャレンジや CAPTCHA パズルに正常に応答したクライアントに対して、トークンを作成、更新、暗号化します。トークンを持つクライアントが Web リクエストを送信すると暗号化されたトークンが含まれ、AWS WAF はトークンを復号化してその内容を検証します。 Bot Control ダッシュボードの「トークンステータス」ペインには、様々なトークンステータスラベルのカウントと、リクエストに適用されたルールアクションのペアが表示されます。 IP token absent thresholds ペインには、トークン無しでリクエストを多数送信した IPに関するデータが表示されます。この情報を使って AWS WAF の設定を細かく調整できます。 例えば Bot Control ルールグループ内で、有効なトークンがないリクエストがルールグループの評価を終了し、Web ACL による評価が続行される可能性があります。トークンがない、またはトークンが拒否されたリクエストをブロックするには、マネージドルールグループの直後に実行されるルールを追加して、 ルールグループが処理しなかったリクエストをキャプチャしてブロック できます。図5 に示す Token status ペインを参照してトークンを取得するリクエストの量を監視し、そのようなリクエストをレート制限またはブロックするかどうかを決定できます。 図5: トークンステータスではトークンを取得するリクエストの量を監視できます CloudFront セキュリティダッシュボードとの比較 AWS WAF traffic overview ダッシュボードは、AWS WAF で保護されているリソースに到達する Web トラフィックの全体的な可視性を向上させます。一方 CloudFront セキュリティダッシュボード は、AWS WAF の可視性と制御を CloudFront ディストリビューションに直接もたらします。潜在的な脅威や問題を示す可能性のあるパターンの詳細な可視性と分析が必要な場合は、AWS WAF traffic overview ダッシュボードが最適です。アプリケーションの配信とセキュリティを一箇所で管理し、サービスコンソール間を移動することなくアプリケーションのトップセキュリティトレンド、許可および遮断されたトラフィック、ボット活動を確認したい場合は、CloudFront セキュリティダッシュボードの方が適している可能性があります。 可用性と価格設定 新しいダッシュボードは AWS WAF コンソールでトラフィックをより適切に監視できます。デフォルトで無料で利用でき、追加の設定は必要ありません。CloudWatch ロギングには別の価格モデルがあり、フルロギングを有効にしている場合は CloudWatch の料金が発生します。CloudWatch の料金の詳細については こちら をご覧ください。環境のニーズに合わせてダッシュボードをカスタマイズすることもできます。 結論 AWS WAF traffic overview ダッシュボードを使用すると、Web セキュリティの状況と境界保護を改善する必要があるトラフィックパターンについて、実行可能な洞察を得ることができます。 この記事では、ダッシュボードを使用して Web アプリケーションを保護する方法を学びました。トラフィックパターン分析と次の可能なステップを説明しました。さらに、ボットからのトラフィックを観察し、アプリケーションのニーズに応じてそれらに関連するアクションを実行する方法を学びました。 AWS WAF traffic overview ダッシュボードは、ほとんどのユースケースに対応し、Web トラフィックのセキュリティ可視性のデフォルトのオプションとして設計されています。もしカスタムソリューションを作成したい場合は「 Deploy a dashboard for AWS WAF with minimal effort 」というブログのガイダンスを参照してください。 このブログは「 Introducing the AWS WAF traffic overview dashboard 」と題された記事の翻訳となります。 翻訳は Senior Solutions Architect の森が担当しました。

こんにちは、AWS トレーニングデリバリーマネージャー の西村航です。 こんな悩みをかかえている方はいませんか？「生成 AI を勉強したいんだけど何から勉強すればよいだろう？」という方、または「基盤モデルをチューニングしたり自社開発したりすることに興味があるけど、どこかに勉強方法がまとまってないかな？」という方。本記事はそういった 生成 AI を勉強したい初学者の方や生成 AI を活用した開発がしたいエンジニアの方を対象にした記事になります。 どこで生成 AI を勉強するのか？ AWS Skill Builder で勉強しましょう。AWS Skill Builder は AWS のオンライン学習センターです。何度でも視聴できるオンデマンドの AWS デジタルトレーニング、AWS 認定の公式練習問題、ゲーム形式で AWS を学べる AWS Cloud Quest などなど、幅広い AWS 学習コンテンツにアクセスすることができます。さらに AWS Skill Builder の 有償サブスクリプション にお申し込みいただくと、AWS 認定の公式模擬試験、ハンズオンラボ、AWS Jam Journey などの追加コンテンツをお楽しみいただけます。 本記事では 生成 AI を勉強する方法に関して、学習リソースとして AWS Skill Builder やイベント資料・ブログ記事をご紹介しつつ、４つのステップに分けてお話していきます。 ステップは勉強の内容や目的によって分かれています。 ステップ 1：生成 AI の基礎を勉強したい初学者の方 ステップ 2：公開済み生成 AI 基盤モデルや API をまず活用してみたいエンジニアの方 ステップ 3：公開済み生成 AI 基盤モデルをチューニングしたいエンジニアの方 ステップ 4：生成 AI の基盤モデルを自社開発したいエンジニアの方 それではここから各ステップに分けて詳細にお話していきます。 ステップ1. 生成 AI とは 本ステップは、エンジニアロールではない営業職や企画職の方なども含めた生成 AI 初学者を対象に、そもそも生成 AI とは何か？ユースケースは？といった生成 AI の基礎内容を取り扱います。 1. AWS で始める生成系 AI for Entry ：AWS における生成 AI の学習の第一歩となる日本オリジナルコースです。これから生成 AI を業務で活用していく上で、そもそも生成 AI とは何なのか、どのような技術的背景や種類があるのか、業務で活用する上でのユースケースや課題などを学習します。また、それらの課題に対して、AWS がどのように活用できるかを学習します。 2. Generative AI for Executives ：生成 AI の概要を説明するコースです。受講者は、生成 AI とは何か、それがどのようにして経営者の懸念や課題に対応するのか、またどのようにしてビジネスの成長をサポートするのかを学びます。また、AI が数多くの業界に大変革をもたらす可能性をどれほど秘めているのかも学びます。 3. Introduction to Generative AI – Art of the Possible ：3部構成のシリーズの1個目です。生成 AI とそのユースケースやリスクと利点について紹介するコースです。このコースを修了すると、受講者は生成 AI、およびそのリスクと利点の基本を説明できるようになります。また、自身のビジネスでコンテンツ生成をどのように活用できるかを説明できるようになります。 4. Planning a Generative AI Project ：3部構成のシリーズの2個目です。生成 AI に関する技術的な基本と主要な用語について学ぶコースです。また、生成 AI プロジェクトを計画するためのステップを学び、生成 AI を使用するリスクと利点を評価します。 5. Building a Generative AI-Ready Organization ：3部構成のシリーズの3個目です。このコースを修了すると、生成 AI 対応組織の構築に関する主な考慮事項を説明できるようになります。また、従業員をスキルアップさせ、職場に生成 AI の思考を導入するためのツールや知識を身に付けることができます。 6. AI ユースケースエクスプローラー ： AI に関してユースケースを探すことができるサイトになります。業種やビジネス機能やビジネス成果、テクノロジー など複数のフィルタリングメニューから選択することもできますので、興味のあるユースケースが探しやすい構成となっています。 7. 生成系 AI でプロダクトの価値を高めるには ：自社の現状を分析して、生成 AI でプロダクトの価値を上げる3ステップを知ることができる資料です。すぐに始めることができる生成 AI 活用プロジェクトチャートなど AWS の機械学習のサービスをどのように使うのか分かりやすく記載されています。 ステップ2. プロプライエタリ 本ステップでは、エントリーレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルや API を活用する際に必要な情報を取り扱います。 1. Amazon Bedrock Getting Started ：Amazon Bedrock は生成 AI アプリケーションの構築とスケールを素早く行うための基盤モデルと一連のツールを提供するフルマネージドサービスです。このコースでは、Amazon Bedrock の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。また、チャットボットソリューションを構築するために、他の AWS サービスと Amazon Bedrock を組み合わせて使用したアーキテクチャも確認することができます。 2. Amazon Bedrock で始める生成系 AI アプリケーション ：Amazon Bedrock を使った 生成 AI アプリケーションでどんなことができるのかを、実際にサンプルアプリケーションを動かしながら紹介するコースです。アプリケーションのコードは公開されていますので、実際に動かしてみたいという方は、動画を見ながら一緒に環境構築してみていただくこともできます。 3. Foundations of Prompt Engineering ：効果的なプロンプトを設計するための原則、テクニック、ベストプラクティスについて学習するコースです。プロンプトエンジニアリングの基礎から高度なプロンプトテクニックまでカバーしています。また、基盤モデルを操作する際に、プロンプトの誤用を防ぎ、バイアスを軽減する方法についても学習します。 4. Amazon CodeWhisperer – Getting Started ：Amazon CodeWhisperer は生成 AI を活用した高度なコーディングコンパニオンで、ユーザーの入力時にユーザーとやり取りしながらコードを提案することで、コーディングの効率と生産性を高めます。このコースでは、サポートされている統合開発環境 (IDE) やコードエディタに CodeWhisperer をインストールして、使用する方法を学習します。 5. Amazon Transcribe Getting Started ：Amazon Transcribe は、音声をテキストに変換できるフルマネージドの人工知能 (AI) サービスで、自動音声認識技術 (ASR) を用いて音声をテキストに変換します。この Getting Started コースでは、Amazon Transcribe の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。 6. Amazon Kendra Getting Started ：Amazon Kendra は、機械学習による高精度な検索結果と非構造化データの検索機能を提供する自然言語検索サービスです。このコースでは、Amazon Kendra の利点、特徴、一般的なユースケース、技術的概念について学習します。また、ユースケースにさらに適応できる Amazon Kendra を使用した検索ソリューションのアーキテクチャも確認します。 7. PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス ：PartyRock は生成 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。PartyRock でアプリケーションを作成してカスタマイズして公開する一連の流れをブログ記事で確認することができます。 8. Build Using Amazon CodeWhisperer ：AWS の安全なサンドボックス環境で一連の課題をこなすことで、DevOps プロフェッショナルの皆様に Amazon CodeWhisperer による構築を実際に経験してもらう、実践的なハンズオンラボです。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 9. Build a Question-answering Bot using Generative AI ：このハンズオンラボでは、AWS のサービスに関する質問に答えるチャットボットを作成します。ハンズオンラボは、大規模言語モデル (LLM) のデプロイ、Amazon Kendra データソースとの統合、さらに、ユーザーの質問に対する回答を見つけるために、LLM にクエリを実行して検索拡張生成 (RAG) を使用する Amazon Lex V2 チャットボットの作成といった実践的な経験を提供するよう設計されていますので、このハンズオンラボを実施することで言語モデルの基本的な機能に情報を追加して強化する方法を理解できます。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 ステップ3. チューニング 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルをチューニングする情報を取り扱います。 1. Amazon SageMaker JumpStart で始める生成系AI ：Amazon SageMaker は、機械学習モデルの構築、トレーニング、デプロイを簡単にするフルマネージドサービスです。このコースでは、生成 AI に興味があるが、どのように始めればよいかわからないという方に向けて、Amazon SageMaker を使って、シンプルかつ迅速に生成 AI の基盤モデルをデプロイしたり、チューニングする方法を紹介します。Amazon SageMaker の機能には、ユーザーが迅速に機械学習を開始できるよう Amazon SageMaker JumpStart と呼ばれる機械学習ハブが含まれています。今回のコースでは、画像生成のユースケースをテーマに、Amazon SageMaker JumpStart で公開されている基盤モデルの利用方法をデモ動画で解説していきます。 2. AWS Cloud Quest: Machine Learning ：AWS Cloud Quest は、AWSのサービスを利用した演習や実習を通して、実践的なAWSスキルを身につけることができるロールベースの学習ゲームです。AWS Cloud Quest ではいくつかの技術領域から選択できるロールがありますが、本 Machine Learning Role では AWS AI サービスを使用したソリューション構築を支援するソリューション構築課題を探索します。なお、2024年3月時点では英語版のみの提供となります。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 3. Jam Journey GenAI re:Invent 2023 ：re:Invent 2023 にて使用されたハンズオンラボです。AWS 環境を触りながら与えられた課題を解決していく実践形式のハンズオンラボで、生成 AI をテーマにした課題が複数ピックアップされています。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 4. AWS AI Week For Developers ：オンラインイベント AWS AI Week for Developers の動画を YouTube で視聴することができます。生成 AI を中心とした AI 技術の基礎から最新情報、そして開発者視点の活用方法 / 適用事例など、「まだ生成 AI について十分な知識がない」とお考えの方から、すでに知識をお持ちの方まで、スキルレベルに合わせた内容になっており、どなたにもお楽しみいただけるコンテンツとなっております。 ステップ4. スクラッチ 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、生成 AI の基盤モデルを自社開発する際に必要な情報を取り扱います。 1. AWS で作る自社用基盤モデル (YouTube) ：本セッションでは、AWS が提供する機械学習基盤を活用して、自社用の大規模言語モデルを独自に学習させるためのベストプラクティスや事例について取り扱います。基盤モデルの特徴と独自構築の必要性、基盤モデル構築のための開発プロセス、基盤モデル作成に関わる AWS の支援体制・テクノロジーを順を追ってお話します。 2. AWS での生成 AI 基礎 Technical Deep Dive Series ：YouTube にて視聴できる英語の動画コンテンツになります。本コンテンツでは、最先端の基盤モデルを事前トレーニング、ファインチューニング、デプロイするための概念的な基礎、実践的なアドバイス、実践的なガイダンスなど技術的に深堀りすることができます。 3. 大規模言語モデルからはじめる生成AI ：DeepLearning.AI と AWS が共同で Coursera 上で提供するコースです。このコースを受講することにより、データサイエンティストやエンジニアの方は、実世界のアプリケーション向けに LLM を選択、トレーニング、ファインチューニング、デプロイするエキスパートになるための準備を整えることができます。このオンデマンドコースは、約 16 時間の動画、クイズ、ハンズオンラボ、追加の読み物を含む 3 週間のコンテンツで構成されています。 4. FMOps/LLMOps : 生成系 AI の運用と MLOps との違い ：最近、多くのお客様は大規模言語モデル (Large Language Model: LLM) に高い期待を示しており、生成 AI がビジネスをどのように変革できるか考えています。しかし、そのようなソリューションやモデルをビジネスの日常業務に持ち込むことは簡単な作業ではありません。本ブログ記事では、MLOps の原則を利用して生成 AI アプリケーションを運用化する方法について説明します。これにより、基盤モデル運用 (FMOps) の基盤が築かれます。さらに、Text to Text のアプリケーションや LLM 運用 (LLMOps) について深掘りします。 Next Action Next Action では、さらに生成 AI を活用したシステム構築に向けて提案や実装方法の引き出しを増やしていくための、ワークショップ・フレームワーク・事例を取り扱います。 Action 1. Workshop で理解を深める 1. Generative AI Use Cases JP ：生成 AI を活用したビジネスユースケースのデモンストレーションです。 2. Amazon Bedrock Workshop ：Amazon Bedrock を通じて基盤モデルを活用する実践的な体験を提供するワークショップです。 3. Generative AI Workshop ：ユースケースに活用できる生成 AI モデルの構築、トレーニング、デプロイについて、エンドツーエンドで理解できるワークショップです。 4. ML Enablement Workshop ：組織横断的にチームを組成し、機械学習による成長サイクルを実現する計画を立てるワークショップです。 Action 2. フレームワークを理解する 1. CAF-AI ：CAF-AI は AI への移行を支援する目的で設計されており、AI/ML によってビジネス価値を生み出そうとする組織にとってのメンタルモデルを示しています。 2. Machine Learning Lens | AWS Well-Architected ：MLワークロードを設計する際に適用することができるガイダンスとアーキテクチャーの原則です。 Action 3. 事例やアップデートを確認する 1. AWS サービス別資料 (機械学習とAI) ：AI/ML のサービス別資料です。 2. AWS Summit Tokyo 2023(機械学習とAI) ：AI/ML カテゴリの AWS Summit Tokyo 2023 セッション資料です。 3. AWS ブログ(カテゴリ：GenerativeAI) ：AWS 公式ブログに投稿されている生成 AI の記事です。 まとめ 本記事では AWS Skill Builder で生成 AI を勉強する 4 ステップ を紹介しました。 今日から早速始めてみましょう。 最後まで読んでいただき、本当にありがとうございました！ 著者について 西村 航 (Wataru Nishimura) @kuwablo AWS トレーニングサービス本部 トレーニングデリバリーマネージャー ジャスミン茶が好きです。

Claude 3 によってパワーアップされた生成 AI、Next.js、 AWS Amplify 、 Amazon Bedrock  の世界に飛び込んでいきましょう。このガイドでは、ユーザーが食材のリストを入力し、Claude 3 が入力された食材にもとづいて美味しいレシピを提案するレシピ提案アプリの作成方法を紹介します。 2023 年 11 月、AWS Amplify は次世代のフルスタックアプリ構築機能の パブリックプレビュー を発表しました。 Amplify Gen 2 はコードファーストの開発者エクスペリエンスを採用しており、開発者は TypeScript と AWS Cloud Development Kit ( AWS CDK ) を使用して、認証やデータ利用のユースケースを含むクラウドリソースを定義およびプロビジョニングできます。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの先進的な AI 企業から選択した高性能な基盤モデル (FM) をフルマネージドで提供するサービスです。単一の API を通じてこれらのモデルにアクセスできるほか、セキュリティ、プライバシー、責任ある AI の観点を考慮した生成型 AI アプリケーションを構築するために必要な幅広い機能を利用できます。Amazon Bedrock では、選択したモデルに関係なく単一の API にアクセスできるため、異なる FM を利用したり、コード変更を最小限に抑えて最新バージョンのモデルにアップグレードしたりする柔軟性が得られます。 AWS Amplify は、データ管理、UI コンポーネント、ホスティングなどの機能群を提供し、クラウドでの Web アプリ開発を加速します。生成AI アプリを構築する際、Amplify はプロセスを簡略化し、シームレスな開発に必要なツールを提供します。さらに、AWS CDK が Amplify Gen 2 を動作させることで、Amazon Bedrock への接続はほんの数行のコードで実現できます。この強力な組み合わせにより、レシピジェネレーターアプリの開発、デプロイ、スケーリングを効率的に行うとともに、セキュリティとパフォーマンスを確保できます。 前提条件 AWS アカウント 。Amplify は AWS 無料利用枠 が含まれています。 Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキストエディタ。このガイドでは VSCode を使用しますが、好みの IDE を使用できます。 Amazon Bedrock モデルアクセス Amazon Bedrock を使用すると、ユーザーはさまざまな生成 AI モデルへのアクセスをリクエストできます。 この例では、Anthropic の Claude 3 Sonnet へのアクセスが必要です。 以下の手順に従ってアクセスをリクエストしてください。 ステップ 1: AWS コンソールにサインインし、Amazon Bedrock に移動します。リージョン選択から us-east-1 リージョンを選択します。 ステップ 2: Claude モデルを選択し、 「モデルアクセスをリクエスト」 ボタンをクリックしてください。 ステップ 3:   「モデルアクセスを管理」 ボタンを選択 ステップ 4: Claude 3 Sonnet のオプションをチェックし、 「変更を保存」 ボタンをクリックしてください。 リポジトリのクローン ステップ 1: AWS Samples の リポジトリ に移動し、Fork ボタンから自分のリポジトリに Fork します ステップ 2: 端末で以下のコマンドを実行してアプリをクローンします git clone https://github.com/[REPLACE_YOUR_GITHUB_NAME]/recipe-ai ステップ 3: 端末で以下のコマンドを実行することで、VSCode で新しくクローンしたリポジトリのディレクトリを開きます。 cd recipe-ai code . -r VSCode でリポジトリフォルダを開きます。amplify ディレクトリにはバックエンドの詳細設定が含まれています。（次のセクションで説明します） ステップ 4: 以下のコマンドを実行して、Amplify Gen 2 パッケージを含む必要なパッケージをインストールします npm ｃi Amplify バックエンド 最終的なアプリ(記事の冒頭の gif を参照)では、ユーザーは食材を入力し、Amazon Bedrock からレシピをリクエストするボタンをクリックします。 このコードはクローンしたリポジトリにあります。 ここでは、Amplify アプリを Amazon Bedrock と接続するための主要なステップを説明します。 リポジトリには、データディレクトリを含む amplify フォルダがあります。 amplify/data/resource.ts ファイルには、食材のリストを受け取り、それらの食材に基づいてレシピを生成するために Amazon Bedrock にリンクできる GraphQL クエリを定義しました。このクエリは、Amazon Bedrock からのレスポンスを構造化するためにカスタムタイプを使用します。 GraphQL API のスキーマは 2 つの主要な部分から構成されます: askBedrock クエリは、 ingredients という文字列の配列を受け取り、 BedrockResponse を返します。 .authorization([a.allow.public()]) を使用して公開アクセス可能にしました。 .handler(a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" })) 行は、 bedrockDS をデータソースとして使用し、 bedrock.js 内で定義されているこのクエリのカスタムハンドラを設定します。 BedrockResponse は body と error の 2 つの文字列型フィールドを持つカスタムタイプです。このカスタムタイプは、 askBedrock クエリからのレスポンスを構造化するために使用されます。 ... const schema = a.schema({ BedrockResponse: a.customType({ body: a.string(), error: a.string(), }), askBedrock: a .query() .arguments({ ingredients: a.string().array() }) .returns(a.ref("BedrockResponse")) .authorization([a.allow.public()]) .handler( a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" }) ), }); ... amplify/backend.ts ファイルでは、Amazon Bedrock へのクエリを接続するために bedrockDS という名前の HTTP データソースを作成します。このデータソースは、 us-east-1 リージョンの Bedrock サービスに関連付けられています。さらに、 addToPrincipalPolicy メソッドを使用して、 bedrockDS データソースのプリンシパルに新しいポリシーを追加します。ポリシーステートメントは、許可されたリソースとアクションを指定します。この場合、リソースは Claude 3 モデルの AWS ARN(Amazon リソースネーム)であり、許可されたアクションは bedrock:InvokeModel です。 const bedrockDataSource = backend.data.resources.graphqlApi.addHttpDataSource( "bedrockDS", "https://bedrock-runtime.us-east-1.amazonaws.com", { authorizationConfig: { signingRegion: "us-east-1", signingServiceName: "bedrock", }, } ); bedrockDataSource.grantPrincipal.addToPrincipalPolicy( new PolicyStatement({ resources: [ "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", ], actions: ["bedrock:InvokeModel"], }) ); amplify/data/bedrock.js  ファイルには、 askBedrock ハンドラの実装のロジックが含まれています。 これは、クエリの入力パラメータ、つまり ingredients を利用してプロンプトを生成し、メッセージ配列の一部としてプロンプト文字列をリクエスト本文に含めることで、Claude 3 モデルに対して POST リクエストを使用し、 HTTP データソース (今回はAmazon Bedrock) に送信します。 export function request(ctx) { const { ingredients = [] } = ctx.args ; const prompt = `Suggest a recipe idea using these ingredients : ${ ingredients.join( "," )}.` ; return { resourcePath: `/model/anthropic.claude-3-sonnet-20240229-v1:0/invoke`, method: "POST", params: { headers: { "Content-Type": "application/json", }, body: { anthropic_version: "bedrock-2023-05-31", max_tokens: 1000, messages: [ { role: "user", content: [ { type: "text", text: `\n\nHuman:${ prompt } \n\nAssistant:`, }, ], }, ], }, }, }; } export function response(ctx) { return { body: ctx.result.body, }; } アプリを実行すると(次のセクションで示されているように)、 amplifyconfiguration.json という名前のファイルが自動的に生成されます。このファイルには、API のエンドポイントの詳細が含まれています。 src/app/amplify-utils.ts で、以下のように Amplify クライアントライブラリを初期化して設定します。次に、Amplify バックエンドへの完全型付き API リクエストを容易にするデータクライアントを作成します。 import config from "@/../amplifyconfiguration.json"; import { Amplify } from "aws-amplify"; import { generateClient } from "aws-amplify/data"; import { type Schema } from "../../amplify/data/resource"; Amplify.configure(config); export const amplifyClient = generateClient(); このアプリは、 src/app/page.tsx ファイルを使用して、食材のリストを送信するためのフォームをユーザーに提示します。 送信されると、 src/app/actions.ts ファイルの generateRecipe 関数が呼び出され、生成されたレシピを取得してユーザーに表示します。 src/app/actions.ts ファイルには、 generateRecipe 関数があります。この関数は Amplify クライアントを利用して askBedrock クエリを呼び出し、食材をパラメータとして渡して Amazon Bedrock から AI 生成されたレシピを取得します。 import { amplifyClient } from "./amplify-utils"; export async function generateRecipe(formData: FormData) { const response = await amplifyClient.queries.askBedrock({ ingredients: [formData.get("ingredients")?.toString() || ""], }); const res = JSON.parse(response.data ?.body !); const content = res.content[0].text ; return content || ""; } アプリの実行 ステップ 1 : Amplify は各開発者に個人用のクラウド サンドボックス環境を提供し、高速なビルド、テスト、反復のための隔離された開発スペースを提供します。クラウド サンドボックス環境を開始するには、新しいターミナル ウィンドウを開き、次のコマンドを実行します: npx amplify sandbox ステップ 2: ローカルホスト開発サーバーを起動するために、以下のコマンドを実行します。 npm run dev アプリのデプロイ アプリが正しく機能するようになったので、Amplify でデプロイしてホストしましょう。Amplify は、組み込みの CI/CD を備えたフルマネージドのホスティングサービスを提供し、Git ブランチを使用した本番環境とステージング環境の設定を簡素化します。Gen 2 では、リポジトリの各 Git ブランチごとに Amplify のフルスタック環境が作成されます。 ステップ 1: AWS コンソールにサインインし、使用したい AWS リージョンを選択します。パブリックプレビューのバナーをクリックし、「 Amplify Gen 2 を試す 」を選択します。 ステップ 2 : 「オプション 2: 既存のアプリケーションを使用して開始」 を選択し、 GitHub を選んだ後、 「次へ」 を選択して進めます。 ステップ 3 GitHub にログインし、「 Authorize AWS Amplify 」ボタンをクリックします。 ステップ 4: ドロップダウンリストからリポジトリとブランチを選択し、 「次へ」 を選択して進めます。 注: ドロップダウンリストにリポジトリが表示されない場合は、「 View GitHub permissions 」ボタンをクリックしてください。次に、リポジトリを選択し、アクセスを許可するために「 Install & Authorize 」ボタンをクリックしてください。 ステップ 5: 設定を確認し、 「次へ」  ボタンをクリックして進めてください。 ステップ 6: 最後に、「 保存してデプロイ 」ボタンをクリックして、デプロイプロセスを開始します。 ステップ 7: デプロイプロセスが完了するのを待ち、 「デプロイされたURLにアクセス」 ボタンを使用して Web アプリを開きます。 リソースのクリーンアップ このチュートリアルを終えたので、以下に示すように Amplify コンソールからアプリを削除することで、バックエンドリソースを削除し予期しないコストを防ぐことができます。 結論 おめでとうございます! AWS Amplify Gen 2 と Amazon Bedrock を使用して、生成 AI の力を借りたレシピジェネレーターアプリを開発することに成功しました。 加えて、Amplify Hosting を使用して AWS にアプリをデプロイしました。 Amplify Gen 2 を始めるには、 クイックスタートチュートリアル をお試しください。 フィードバックや機能リクエストは、 コミュニティ Discord にご参加ください。 この記事は、 Use Generative AI and Next.js with AWS Amplify to build a Fullstack Recipe Generator を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people ’ s lives easier. You can find Mo on YouTube or on Twitter .

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 寒暖差が激しく体調管理が難しいですが、みなさんいかがお過ごしでしょうか？ 自分は数年ぶりに風邪をひいてしまい、やっと回復しました。みなさんもお気を付けください。 さて、直近でいくつかイベントが予定されています。ご都合つく方はぜひご活用ください！ 2024 年 3 月 28 日 (木) – サーバレスで始めるAWS データベースサービス-RDS/Aurora編 – AWS 物流 DX セミナー 2024 2024 年 4 月 11 日 (木) – IBM Db2 の資産を AWS で活用する – 生成 AI の新展開 – マルチモーダル生成 AI の活用方法 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月18日週の主要なアップデート 3/18(月) Get visibility to your auto deployment configuration with a new StackSets API AWS CloudFromation StackSetsにListStackSetAutoDeploymentTargets APIが追加されました。AWS CloudFormation StackSetsは、複数のアカウントおよび AWS リージョン のスタックを 1 度のオペレーションで、作成、更新、削除できるようにする機能です。StackSetsはOUをターゲットにすることができますが、自動デプロイする際OUによって利用可能なリージョンが違う場合、どのOUのどのリージョンに適用されているか各アカウントにログインして確認する必要がありました。今回のアップデートはこれを一覧表示できるAPIのリリースです。 AWS Secrets Manager announces support for Amazon Redshift Serverless data warehouse AWS Secrets ManagerがAmazon Redfhift サーバレスをサポートしました。これにより、データウェアハウスへのユーザー認証情報のローテーションを管理するといった認証情報の面倒な作業が不要になり、AWS Secrets Managerから直接作成および設定が可能になります。この機能はAmazon Redshift サーバーレスが利用可能なすべての AWS リージョンでご利用いただけます。詳細は ドキュメント もご確認ください。 New Amazon SageMaker integration with NVIDIA NIM inference microservices Amazon SageMakerとNVIDIA NIM inference microservicesが統合され、NVIDIAアクセラレータコンピューティングインフラストラクチャ上で大規模言語モデル(LLM)の価格パフォーマンスをさらに向上させることができるようになりました。NIMはNVIDIA AI エンタープライズソフトウェアプラットフォームの一部としてLLMによる推論用の高性能なAIコンテナを提供する機能です。推論のために最適化された様々なLLMのコンテナを提供しており。Llama 2 (7B、13B、70B)、Mistral-7b-Instruct、Mixtral-8x7b、NVIDIA Nemotron-3 などがサポートされる他、それ以外のモデルのGPU最適化バージョンを作成するためのツールも提供します。Amazon SageMaker が利用可能なすべての AWS リージョンでアクセスできます。詳細については ブログ もご確認ください。 Amazon Managed Service for Apache Flink adds support for Apache Flink 1.18 Amazon Managed Service for Apache FlinkがApache Flink 1.18をサポートしました。Ver 1.18で新たにサポートされる機能などの詳細については ドキュメント をご確認ください。同時にAmazon Managed Service for Apache Flinkの インプレースアップグレードのサポート も発表されています。これによりより簡素にトレーサビリティを確保してアップグレードが可能です。インプレースアップグレードの詳細は こちら もご確認ください。 3/19(火) Amazon Corretto 22 is now generally available Amazon Corretto 22の一般提供がGAしました。Linux, MacOS, Windows各々のバージョンを こちら からダウンロード可能です。OpenJDK 22のフィーチャーリリースの詳細に関しては OpenJDK 22のプロジェクトページ をご確認ください。 Amazon DynamoDB now supports AWS PrivateLink DynamoDBがPrivateLinkをサポートしました。これによりVPCや、オンプレミスからのプライベートネットワークからインターフェイスエンドポイントを介してアクセス可能になります。DynamoDBのPrivateLinkは全ての商用リージョンで使用可能です。詳細は ドキュメント もご確認ください。 AWS CodeBuild now supports custom images for AWS Lambda compute AWS CodeBuildで、AWS Lambda を使用してソフトウェアパッケージのビルドとテストを実行する際に、これまではマネージドコンテナイメージのみ利用可能でした。今回のアップデートによりLambdaの場合もAmazon ECRに保存されているコンテナイメージを使用できるようになり柔軟性が上がります。このアップデートは東京を含む10のリージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 3/20(水) AWS announces a 7-day window to return Savings Plans Savings Plansを購入後、7日以内であれば返品できるようになりました。Savings Plansは柔軟な価格設定モデルで、1年または3年の利用契約をすることで、最大72%削減できる購入方法です。今回のアップデートで購入した後に最適ではないと気付いた場合に返品し、別の貯蓄プランを再購入でるようになりました。この機能は、中国リージョンを除くすべての AWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Neptune Database is now available in AWS Asia Pacific (Osaka) Region 大阪リージョンでAmazon Neptuneをご利用可能になりました。エンジンバージョン 1.1.0.0 以降および、R5、R5d、R6g、R6i、X2g、T4g、サーバーレスのインスタンスタイプがご利用いただけます。 Amazon Aurora zero-ETL integration with Amazon Redshift announces support for data filtering and CloudFormation Amazon MySQL to RedshiftのZero-ETL integrationでデータフィルタリングと、CloudFormationによるリソース設定・デプロイをサポートしました。データフィルタリングを使うことでレプリケートされるデータベースやテーブルを指定することができるので、より効率的にデータ分析との統合が可能になります。この機能は東京を含む9のリージョンでご利用いただけます。こちらの ブログ もご確認ください。 Amazon DynamoDB now supports resource-based policies Amazon DynamoDBがリソースベースのポリシーをサポートしました。リソースにアクセスできるIDおよびIAMプリンパルと、実行できるアクションを指定することが可能です。これにより、IAMプリンシパルによるクロスアカウントアクセスの制御も簡素化することができます。この機能はすべてのAWS 商用リージョンで利用できます。詳細については ドキュメント もご確認ください。 3/21(木) Amazon RDS Multi-AZ deployments with readable standby instances now support C6gd database instances Amazon RDSのc6gdインスタンスが２つの2つの読み取り可能なスタンバイを備えたマルチAZ 構成をサポートしました。PostgreSQLのバージョン 16.1以降、15.2以降、14.5以降、13.8以降、およびMySQLのバージョン 8.0.28以降で利用できます。東京、大阪リージョンを含む14のリージョンで利用可能です。 Announcing Package Group Configuration in AWS CodeArtifact AWS CodeArtifactがパッケージグループ設定の機能をサポートしました。この機能を使うと、パッケージ形式、名前空間および名前に基づいてCodeArtifactのパッケージをグループ定義できます。パッケージグループにPublish、External Upstream、Internal Upstreamのルール設定ができるため、意図しない公開や、パブリックリポジトリからのインポートを制御しセキュリティを強化できます。 3/22(金) Amazon DataZone launches enhancements to Amazon Redshift integration Amazon DataZoneとAmazon Redshiftの統合機能が強化されました。Datazone管理者はDefaultDatawarehouseBlueprint上にパラメーターセットを作成することができるようになりました。パラメーターセットを元にして環境プロファイルを作成することで、利用者は自分でパラメータ設定することなく環境を作成できるためプロセスを簡略化できます。この機能は東京を含む13のリージョンで利用可能です。詳細は ドキュメント もご確認ください。 Amazon MSK Connect now supports deleting worker configurations and tagging resources Amazon MSK ConnectでCloudFormationを利用したワーカー設定の削除やリソースのタグ付、カスタムプラグインの管理等がサポートされました。このアップデートによりリソースの管理やデプロイの自動化が容易になります。これらの機能はAmazon MSK Connect が利用可能なすべてのAWSリージョンでご利用いただけます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

※このブログは ” Highlighting modern innovations in cloud-based broadcast production at Inter BEE 2023 ” を翻訳したものです。 このブログは、Waves Audio Ltd のアソシエイト・プロダクト・マネージャー兼プロダクト・アプリケーション・エンジニアである Daniel Kamhaji が共同執筆しています。 はじめに このブログ記事では、 2023 年 11 月 15 日～ 17 日に幕張メッセで開催された Inter BEE で、アマゾンウェブサービス（ AWS ）ジャパンが紹介した、クラウドベースの放送制作における最新のイノベーションについて詳しく説明します。Inter BEE 2023 の AWS ブースでの Waves Cloud MX の役割に焦点を当てて、放送制作を形作るテクノロジーとコラボレーションをご紹介します。イノベーションが、信頼性が高く高度なライブプロダクションワークフローの基準をどのように設定しているかを明らかにします。さらに、AWS が提供するシグナルフローと配信サービスについても触れ、それらが日本市場に与える影響と、世界中のライブ放送とメディア制作の進化する状況に焦点を当てています。 Inter BEE 2023 における AWS ブース AWS Japan ブースで Waves Audio や業界のリーダーたちと未来の放送技術を紹介 国際放送機器展「 Inter BEE 」は、コンテンツビジネスにおける最新のイノベーションをグローバルに紹介する展示会です。毎年開催されるこのイベントと展示会は、テクノロジーの先駆者たちとのコラボレーションの拠点となり、放送ソリューションとワークフローの機能を紹介しています。Waves Audio Ltd. は、Inter BEE 2023 に AWS Japan と共に参加し、クラウドワークフローにおける業界の革新を紹介し、ライブ放送制作技術の一連のツール群を紹介しました。業界リーダー間の団結を示すブースでは、 ソニーの M2L-X ソフトウェアビジョンスイッチャー 、 SiennaND プロセッシングエンジン 、 Viz Trio &   Viz Engine 、 Telos Alliance Infinity VIP 、 Ateme TitanLive 、 LiveU Cloud Connect 、 TAG Video Systems  Multiviewer 、 Waves Cloud  MX オーディオミキシングプラットフォーム 、基本的なメディアサービス機能を提供する AWS Elemental により統合されました。これらの要素が一体となって、現在の技術的実装度合いを実証し、放送制作の発展のための実践的な青写真を提供するまとまりのあるエコシステムを作り上げています。 Inter BEE 2023 の AWS ブースでのライブプロダクション・デモンストレーションシステム コア接続 : NDI プロトコルによるストリームの簡略化 NDI (ネットワーク・デバイス・インターフェース) は、NewTek が標準的な LAN ネットワークを使用した IP 伝送およびライブプロダクション用に開発したオープンプロトコルです。その使いやすさと信頼性により、制作チェーンのさまざまな要素をつなぎ、理解のしやすさと信頼性によりプロセスの合理化を促進する、放送環境における魅力的なツールとなっています。 オペレーターのための操作方法 Waves Cloud MX は中心的な役割を担い、NDI オーディオ入力をライブフィードとして 4ch 、NDI による追加の 8ch のローカル再生を巧みにミックスして、洗練された最終ミックスを生み出しました。 NVIDIA GRID  ドライバーを搭載した Windows サーバー上で g4dn.4xlarge タイプの   Amazon Elastic Compute Cloud  (Amazon EC2) インスタンスを活用することで、本番環境では CPU パワーをオンデマンドでスケールアップし、必要に応じて最適なパフォーマンスを実現できます。 この適応性により、オペレーターはオーディオ処理用の広範なツールキットを活用できます。これらには、複数のマイクのリアルタイム自動バランスを実現する Dugan Speech プラグイン 、複雑なオーディオシェーピング用の F6 Floating-Band Dynamic EQ 、正確なノイズ抑制用の WNS 、正確なラウドネスメータリング用の WLM および Dorrough プラグインなどがあり、それぞれがプレミアムなサウンド体験に貢献しています。 150 種類以上の Waves プラグインを幅広く取り揃えているため、オーディオプロフェッショナルに豊富なインテリジェントでクリエイティブな機能を提供できます。Cloud MX のライセンスは   Amazon Elastic Block Store  (EBS) ドライブでアクティベートされるため、インスタンス間のライセンス移動が容易になり、デプロイプロセスが合理化されます。 NICE DCVとWaves FITコントローラーによる制御と仮想化の強化 操作感とバーチャルを融合させた Waves FIT コントロールサーフェス は、オーディオオペレーターにハンズオンフェーダーとエンコーダーインターフェースを提供します。コントローラーはローカルコンピューターに直接接続され、Amazon EC2 環境の RTP Midi を介して UDP IP パケットを介して制御情報を送信します。このセットアップにより、低レイテンシー測定により、オペレーターとクラウド間の応答性が向上します。 NICE DCV とタッチパネルディスプレイは、もう1つのコントロールサーフェスとしてリモートデスクトップ操作を提供しました。ユーザーは複数のタッチディスプレイでミキサーを操作でき、Waves Cloud MX の EC2 インスタンスに接続することで、ミキサーのウィンドウを好みに合わせて柔軟に広げたり配置したりできます。これにより、オペレーターは NICE DCV を介してローカルコンピューターのスピーカー構成でオーディオをモニタリングすることもでき、専用の Waves ASIO NDI コントロールパネルを使用してさまざまなオーディオドライバーやプロトコルの制限を回避できます。これにより、オーディオを Windows システムオーディオに送ることができます。 タッチスクリーンとフィットコントローラーを備えた Waves オーディオディスプレイ シグナルフロー : ライブ制作の全体像 1. このシステムの信号フローは、定義された経路をたどります。セキュア・リライアブル・トランスポート（ SRT ）ストリームは、Sienna の「 IP Connect SRT 」を介してオンプレミスの場所から送信され、NDI ストリームに変換され、本番環境ですぐに使用できます。 2. ブースのプレゼンテーションステージでは、 AWS Elemental Link デバイスを使用してライブ映像を撮影しました。これらのデバイスは、エンコーディングにおいて重要な役割を果たし、カメラやビデオ制作機器などのライブビデオソースをクラウドにリンクします。 3. さらに、LiveU は自社の LiveU Cloud Connect ソリューションを使用して、ブースでライブ信号を提供しました。このシステムは、LiveU LU800 マルチカメラフィールドユニットと LiveU クラウド EC2 インスタンスを効率的にブリッジし、LiveU の信頼性の高いトランスポートストリームプロトコル（ LRT ）を介したスムーズで統合された接続を保証します。 4. Amazon S3  はシステムのコアリポジトリとして機能し、Sienna ND プロセッシングエンジン、ソニーのスイッチャー、Waves Audio などの要素間でコンテンツを共有できます。デモシステムのメイン配信ハブおよび中央ストレージとして機能し、各パートナーソリューション用のビデオファイルやオーディオファイルなどのコンテンツを準備します。 5. その後、EC2 インスタンスでホストされる Sienna ND プロセッシングエンジンは、受信ストリームを処理し、メディアソースから追加のストリームを作成します。これにより、NDI 対応カメラからのライブフィードと事前に録画されたコンテンツの両方が、制作セットアップ内の目的の宛先向けに管理および準備されます。 6. NDI ストリームがセットアップをナビゲートすると、ソニー のM2L-X ソフトウェアベースのスイッチャーが ソニー製コントロールパネルでビデオスイッチングを管理し、エクスペリエンスをさらに向上させます。さらに、Viz Trio と Viz Engine によるグラフィックの強化により、視覚体験がさらに洗練され、リアルタイムのグラフィックレンダリングと管理が可能になり、視覚的に魅力的でダイナミックなライブコンテンツが視聴者に配信されます。同時に、32 ビットの浮動小数点倍精度ミックスエンジンを搭載した Waves Cloud MX は、オーディオフィードをミキシングして処理します。ミキサーは、処理されたオーディオを NDI を介して Sienna ND の「 NDIソースコネクト 」に送り、次に「オーディオエンベッダー」に送り、そこでビデオと同期します。その後、この新しい結合フィードは、ソニーのスイッチャーを介してループバックされます。 7. 番組全体は SRT ストリームを介して   AWS Elemental MediaConnect にブロードキャストされ、そこでライブビデオフィードの管理と配信が実行されます。 この段階で、 SRT 信号は Ateme TitanLive を通過し、ライブプロダクションとマスタープレイアウトシステムの間の接続ブリッジとして機能し、そこでライブビデオフィードを管理および配信します。その後、Ateme TitanLive は放送を複数のストリーミングプラットフォームに配信し、コンテンツの作成から視聴までの流れを完了します。さらに、 AWS Elemental MediaConnect の出力信号は、 TAG VS Multiveier ソリューションと    AWS Elemental MediaLive に送られ、クラウドマスタープレイアウトのデモンストレーションに向けてさらにモニタリングと処理が行われます。 ライブプロダクションデプロイメントのアーキテクチャ概要 結論 : 業界をリードするソリューションを統合して放送技術を進歩させる Inter BEE 2023 はクラウドベースの放送制作技術におけるイノベーションのショーケースだった。さまざまなメーカーの統合や AWS サービスの使用など、これらの進歩は、ライブ放送制作のワークフローに革命をもたらしています。これは、信頼性と最先端のパフォーマンスへのこだわりが日本市場ですでに話題を呼んでおり、ライブ放送やメディア制作への期待を変えています。 詳細については、以下のリソースを参照してください。 Inter BEE ウェブサイト 国際放送機器展とその業界における意義について詳しくは、Inter BEE の公式ウェブサイトをご覧ください。 WavesAudio ウェブサイト Waves Audio のウェブサイトにアクセスして、Waves Cloud MX をはじめとするオーディオミキシング技術の最新イノベーションをご覧ください。 ソニー M2L-X ソフトウェアビジョンスイッチャー ソニーの M2L-X ソフトウェアビジョンスイッチャーと、ビデオスイッチングテクノロジーにおけるその役割などについて詳しく学んでください。 Viz Trio と Viz Engine これらのテクノロジーの詳細については、Viz Trio と Viz Engine のサイトをご覧ください。 SiennaND プロセッシングエンジン さまざまなプロトコルなどのストリーム処理のための主要コンポーネントである SiennaND プロセッシングエンジンをご覧ください。 NDI (ネットワークデバイスインターフェイス) 中核となる接続フレームワークである NDI と、オーディオストリームとビデオストリームの統合を簡素化する上での NDI の役割について学んでください。 Ateme TitanLive Ateme TitanLive がさまざまなストリーミングプラットフォームへの放送コンテンツの配信にどのように貢献しているかをご覧ください。 Telos Alliance Infinity VIP このテクノロジーの詳細については、Telos Alliance Infinity VIP ページをご覧ください。 LiveU Cloud Connect IP ベースのライブブロードキャストソリューションの詳細については、LiveU Cloud Connect ページを参照してください。 Tag Video Systems Multiviewer Tag Video Systems Multiviewer の詳細をご覧ください。 メディア・ インテグレーション株式会社 日本最大のプロ仕様制作ソフトウェアの販売代理店であり、Waves 製品の日本における公式再販業者です。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 執筆及び翻訳は SA 斎藤、確認は SA 小林が担当しました。原文は こちら をご覧ください。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、 こちらのリンク からご確認ください。 4．クラウド利活用の重要なポイント 一方、私たちが新たにクラウド上での開発を進めている次世代スマートメーターシステムでは、前回の 第 2 回のブログの 3 章 でご紹介したように、疎結合アーキテクチャによる拡張性とシステム開発に対する柔軟性、高い可用性の実現、マネージドサービス活用によるスケーラビリティや俊敏性、および運用最適化の実現、スマートメーターデータを分析し利活用するための AWS のデータ分析サービスの活用、という 3 つの開発方針に基づいて取り組んでいます。 この方針に沿って TCO 削減を含めたクラウドメリットを最大限に享受するため、AWS サービスの最適な組み合わせでシステム開発を進めていくことが重要ですが、AWS は多様なサービスや機能を提供しており、それぞれに特長や利用方法も異なります。要件やニーズにマッチした最適なサービスや機能を選択するためには、AWS クラウドを正しく理解して使いこなしていくことが肝要です。また、データの保護やアクセス制御など適切なセキュリティ対策を実現していくためには、AWS クラウドのセキュリティ機能やベストプラクティスを理解して使う必要があります。 こういった背景を踏まえて、AWS クラウド上でシステム開発を進めるうえで特に重要なのは、次の三つのポイントだと考えています。 私たち自身がシステムとクラウドを正しく理解すること。 システムベンダーがクラウドを正しく理解して受け入れ、積極的な活用に向けた体制整備ができていること。 私たち自身もシステムベンダーも、継続的なクラウドスキル獲得と向上を図っていくこと。 つまり、私たち自身の強い意志は不可欠ですが、それだけでクラウド活用を成功させることは容易ではなく、やはりクラウド活用を積極的に伴走してくれるシステムベンダーを私たちが適切に選択し、綿密に協業しながらシステム開発を進めることが不可欠です。 4-1. システムとクラウドに対する私たち自身の正しい理解 従来のシステム開発の経緯を顧みて、上記の方針に沿って着実にシステム開発を進めていくためには、アプリケーションシステムの全体像を私たち自身が正しく捉えることが重要と考え、業務とシステムの両面から現行システムへの理解を深めるよう取り組みを進めています。同時に、クラウド活用の議論を進めていくためにも、私たち自身がまずクラウドを正しく理解することも重要です。この点については、 第 2 回のブログの 5 章 の共通基盤の導入とシステム統制で詳しくご紹介した通りです。つまり、私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダーとしっかり連携して協調しながら進めることができると考えています。 クラウド活用に関連して、よくある議論として「自分たちが所有することで得られる安心」に根差した意見提起がなされることもありますが、私たちはこれまで取り組んだ結果として、「クラウドを正しく理解する」ことで、自分たちが所有する以上のメリットがクラウド活用により享受できると考えています。特にフォーカスされやすいセキュリティ面で言うと、AWS を利用する場合、AWS 自身が多種多様なセキュリティ対策とそれを保証するための 認証 を取得しています。こうした対策を自分たち自身で実現しようとすると、自らがその検討や実装に時間を割く必要があります。しかし、餅は餅屋です。セキュリティ面を含めたインフラの整備や維持運用はクラウド事業者にアウトソーシングし、私たちはそれらを適切に利用しながら環境準備する( 責任共有モデル )とともに、本来実現したい業務要件に的を絞り、システム開発に本質的に注力すべきと考えています。 4-2. システムベンダーの適切なクラウドの理解と体制整備 また、正しいクラウド活用に向けては、私たちがクラウドを活用しようとする理由や動機、またどのように取り組もうとしているか、その方針などクラウド活用に係る基本スタンスの整理と、システムベンダーへのメッセージングも非常に重要です。クラウド活用方針を正しく伝えない限り、従来のサーバを Amazon EC2(EC2) 上に載せ換えてクラウド実現しただけ、ということになりかねません。それがたとえパッケージシステムであっても、そのまま EC2 の上に載せただけではクラウドの本質的なメリットを享受できるような取り組みとは言えません。クラウドメリットを最大限享受していくうえでは、マイクロサービスアーキテクチャの思想に根差し、AWS サービスのビルディングブロックを形成しながら AWS マネージドサービスをフル活用するようなシステム構想など、多様なサービスや機能を適材適所で選択しながら開発を進めていく必要性があります。 従来、オンプレミスでサーバ環境を整備しシステムを構築してきたシステムベンダーは、ともすればクラウド上に従来のシステムを組む方向に流れがちだと感じており、ユーザである私たちの強いニーズや意図を明確にシステムベンダーに示し、それを伝えなければ、クラウド活用に係る検討さえもなかなか進まないという状況はよく見られるかと思います。システムベンダーがクラウド活用の必要性を腹落ちして理解し、従来のやり方を刷新し、将来性を見据えて積極的なクラウド活用を一体的に推進できるよう、システムベンダーを活用する私たちからの積極的な働きかけは不可欠です。つまり、保有する安心感やメリットからクラウド活用へのマインドチェンジが重要なポイントだと考えます。アプリケーション開発を担うのはシステムベンダーであることから、このマインドチェンジは、私たちユーザのみならずシステムベンダーも一緒に実現すべきなのは明白です。そういった姿勢で並走できるシステムベンダーを私たちが選択し、相互に協調したシステム開発でなければクラウドの正しい活用は成功し得えないといえます。 その大前提としては、システムベンダーがそもそも正しくクラウドを理解していることが必須です。まず、システムベンダーがこれまで組み上げてきたアプリケーションシステム自体が、クラウド上でも正しく動くことを前提として理解を進め、クラウドの仕様や要件を適切に取り入れ組み直すことで、システムの移行や運用におけるトラブルや障害を防ぐことができます。また、その際には AWS のサービスやその機能を正しく理解することを通して、マイクロサービスの考え方やサーバレスアーキテクチャ、各種マネージドサービスの活用などクラウドメリットを最大限享受できるように設計開発を進めることで、システム自体の性能や信頼性を向上させることができます。堅牢なシステムの組み上げには、クラウドセキュリティを正しく理解することも不可欠です。 こういった協業関係を深化させるうえでも、 第 2 回のブログの 5 章 で説明したような共通基盤の導入を通して私たちがインフラを統制し、アプリ開発を担うシステムベンダーに必要な環境を共有する形で協業体制を整理してシステム開発を進めることも有効と考えています。 なお、私たちのプロジェクトにおいては、 AWS Professional Services も本プロジェクトに参画し、システムベンダーの自律的な取り組みを促しながら、システムベンダーの全体統括や技術支援という立ち位置で、私たちやシステムベンダーと常にコミュニケーションを図りながら強力なプロジェクト推進に協力いただいています。 4-3.　継続的なクラウドスキル獲得と向上 こういったクラウド活用推進において重要な考え方として、コンテナやサーバレスに代表されるクラウドと相性の良い技術の採用とその技術習得は非常に重要です。新しい技術を採用することが目的であればシステムとして導入することでゴールを達成できますが、 第 2 回のブログの 5 章 の共通基盤に係る説明でも触れた通り、自分たちのスキル醸成を狙うためには技術力向上の実現とは切り離せない取り組みであり、これら AWS クラウドの技術を理解しながら活用することも必須と考えています。新しい技術の習得やそれに伴うスキル醸成には、どうしても属人的な活動になりがちですが、それをいかに組織的に実現するか、当社の関係者にモチベーション高く活動を継続的に行っていくかという観点は、私たちが目指すスマートメーターシステムの実現や、その先のデータ利活用の更なる高度化にとっても必要不可欠だと考えています。 5. まとめ 本ブログでは、私たちのスマートメーターシステムの取り組みについて、現行世代システムのクラウドシフトとフルクラウドによる次世代システムの開発という、性格の異なる二つのプロジェクトの同時並行の様を、私たちの着眼点や留意事項を中心にご紹介してきました。 いずれのシステムもクラウドをベースにする、という判断は大きな判断であり、ブログの中でも紹介致しました通り、詰めた社内議論を経て、やっと合意形成を取り付けて進めてきました。クラウド推進側にも慎重側にも、踏み込んだ議論を要求してきたこともあり、私たちも非常に苦労してここまで進めて参った次第です。 AWS の紹介で海外の同業者との意見交換の場を持つことができましたが、そこで聞けたのは、私たちが経験してきたような社内議論を繰り広げてクラウド採用に至った等の話でした。日本に比べて進んでいる印象の海外事業者といえども社内にはクラウド慎重派がいて、クラウドの導入が手放しで円滑に進んでいるわけではない、ということがよく分かりました。また、国にもよりますが、規制当局がクラウドの利用に制限を設けたり、そもそも OT システムについてはクラウド利用を認めていなかったりなどの事情があることも分かりました。 このように、クラウドの利活用については、まだ慎重に考える関係者や制約となる規制の存在など、課題が残っているものの、これもブログにてお示しした通り、システムの将来における拡張性や柔軟性、これから間違いなく肝になるデータ利活用の環境整備、という観点からクラウドの徹底的な利活用は避けて通れないと考えています。 クラウドを徹底的に利活用していくためには、私たちのようなエンドユーザーとシステムベンダーの双方が、何を目指しているのか、そのためにどういう仕組みを導入しようとしているのか等々、相互理解を深め、双方ともに知見や知識、スキルを磨き続けていく意識が問われてくると考えています。私たちが導入した共通基盤の考え方や、それに伴うインフラ統制やアカウント管理のあり方などが、そうした意識を形にした一つの姿だと思います。また、こうした地道な意識浸透の活動を進めていくに当たって、クラウドのプロ中のプロである AWS、なかんずく AWS Professional Services の方々に負うところが非常に大きく、彼らのサポート無しには私たちの活動は簡単に頓挫していたように思います。私たちの取り組みはまだまだ道半ばではありますが、この場をお借りして改めてお礼申し上げます。 このブログが、読者皆様方のこれから先のシステム開発にあたって、クラウド利用を考えられる一助になれば幸いです。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 連載記事として、以下も公開されておりますので、ぜひご参照ください。 第 1 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 1 回) – 前半 」 第 2 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 2 回) – 前半 」 1. はじめに 本稿では、三部構成で当社の取り組みをご紹介してきました。 第 1 回 は、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。 第 2 回 では、次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組みをご紹介しました。最後となる今回、第 3 回は、現行スマートメーターシステムのクラウド移行を中心に、私たちのクラウド活用に関する思いとこだわり、及びその取り組みについてご紹介します。 2. オンプレミスからクラウド活用へ 　当社の現行スマートメーターシステムは、第 1 回のブログで記載した通り、他電力に先立って開発を進めていた当時の背景もあって、昨今のようなメーターデータの収集管理システムのパッケージソリューションが存在しない中、複数のシステムベンダーとの協力のもと試行錯誤しながらシステム開発を進め、システムベンダーの技術や仕様に基づいて組み上げたシステムを、当社データセンターで構築しました。スマートメーターは 2012 年から当社管内のお客さまに本格導入を開始し、2023 年 3 月に全戸導入が完了するまで、スマートメーターの設置台数の拡大に伴い、現行システムで利用するサーバ数も増台しながらも、継続的な安定稼働を実現してきました。 一方で、そのような経緯で開発されたシステムであるため、独自 OS や商用データベースおよびミドルウェア採用に伴う経済性や将来持続性の問題、開発と運用のシステムベンダー依存に伴うシステムのブラックボックス化、業務処理ロジックの隠匿化などの課題に直面しており、また、スマートメーター収容数の拡大に伴うサーバハードウェアの増台、サーバのメーカー保守切れ対応の継続的な発生、さらにそのリプレイスに伴う OS やミドルウェアの技術検証など影響範囲が広く、コスト面だけではなく人的な業務負担も大きくなっていました。加えて、昨今の社会情勢の大きな変化により、半導体枯渇によるサーバのハードウェアの調達納期の遅延に代表される将来の不確実性といった、様々な課題も顕在化しています。そしてそのような複雑な状況が、スマートメーターから収集されるデータの柔軟かつ高度な利活用の拡大の障壁となっていました。 自社のオンプレミス環境でシステム運用していれば、私たちと同じような状況に陥り、同様の課題に直面するケースも多いかと思います。私たちは、それら課題に対する包括的な解決方策として、クラウド技術の活用が一つの選択肢になると考え、現行スマートメーターシステムのクラウドシフトを指向することにしました。 3. 現行スマートメーターシステムにおけるクラウド活用方針 本章では、私たちの現行システムにおける AWS 機能やサービスの捉え方やシステム移行の方針についてご紹介します。掲げた方針は 3 点あります。 現行システムのクラウド移行に向けた取り組み方針 AWS クラウドのサービスで代替できるものは、AWS に任せてオフロードする AWS クラウドならではの柔軟性をフル活用する 開発を進めながら AWS クラウドの技術革新や新サービスを随時取り込む 3-1. AWS クラウドサービスへのオフロード オンプレミスではディスク故障など日々のハードウェア障害にも個々に対処していく必要がありますが、クラウドではそういった障害対応は AWS にオフロードし私たちは意識する必要がなくなります。また、オフロードする割合を高めることで、インフラの構築や運用保守は、単にサービスの利用という形に置き換えることができます。つまり、データベースさえも組み上げる必要はなく、単にサービスを選んで利用するだけというように、システム構築の体制や考え方も大きく変わります( 図 1 )。 私たちのオンプレミスのサーバシステムでは、信頼性確保に必要となるクラスタソフトなどミドルウェアはシステムベンダー各社各様のものを採用されてきましたが、こういったミドルウェアはまず脱却の対象として位置付けました。その実現のため、 Amazon Elastic File System(EFS) や Amazon FSx 等を活用したステートレス化を含めたアプリケーション改修を実施するとともに、 Elastic Load Balancing(ELB) を活用したサーバ群のヘルスチェックを組み合わせ、かつ、マルチ AZ による拠点間冗長も実現しながら、システム全体としてのシステム信頼度を向上させています。 併せて、商用データベースの脱却も基本としています。検討当初から DB on Amazon EC2 の考え方は一切取らず、 Amazon Aurora または Amazon RDS の AWS マネージドサービス活用を前提とした移行検討を行っています。こういった AWS の各種マネージドサービスの積極活用の考え方は、マネージドサービスを活用した方が信頼性や運用保守性の向上とともに、運用負荷軽減に確実につながると評価した結果です。 図 1. AWS マネージドサービス活用による IT インフラ業務の AWS へのオフロード 3-2. AWSクラウドならではの柔軟性の活用 クラウドでは、リソースを必要な時に使って不要となれば捨てる、という身軽さがあり、「後戻りできる」というメリットがあります。 例えば、従来はサーバのリソースサイジングを緻密に行ったうえで、サーバの調達や導入に時間をかけながら進めていましたが、クラウドにおいては、「好きなときに、好きなリソースを、好きなだけ使える」という従量課金の考えのもと、その時点で決めた構成やソリューションを、よりよいものに柔軟に変更できます( 図 2 )。私たちの検討においては、インスタンスの変更も柔軟かつ簡単であることから、リソースサイジングを綿密に行うことなく、机上検討や実機検証を進めながらインスタンスタイプの選定を進めています。 図 2. AWS を活用する IT インフラ調達観点でのメリット また、従来は本番環境や開発環境をそれぞれ整備するのに、それぞれ大きな手間とコストをかけてきました。私たちは、今回、IT インフラの構築において Infrastructure as Code（IaC）を積極活用しています。IaC を活用し IT インフラのデプロイを自動化することで、人的ミスも回避することができますし、システム構成の見直しもアプリ開発を進めながら柔軟に対応可能です( 図 3 )。 図 3. AWS における IaC メリット 3-3.技術革新や新サービスの随時取り込み 導入当時には適切と判断したアーキテクチャであったとしても、導入からの時間経過に伴う技術革新により、当時よりも選択肢が増えたことで検討の幅が広がり、より良い構成を選択できる可能性があります( 図 4, 図 5 )。 例えば、私たちが検討を進める中で、「 Network Load Balancer(NLB) でセキュリティグループのサポートを開始 」という発表が 2023 年 8 月にありました。当初は、NLB についてはセキュリティグループチェーンの対象外としていましたが、この発表を受けて設計変更した結果、システム全体にわたるセキュリティグループのチェーン化を取り込みシンプルな仕組みでのセキュリティ確保が実現できています。 現在進めている、次世代スマートメーターシステムの構築においても、同様により良いサービスや機能が提供開始された場合には、それを活用しながら開発を進める方向です。 図 4. AWS の技術革新による新サービス・新機能の提供拡大 図 5. アナリティクス分野を含めて拡大する AWS サービス(抜粋) 本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「 3．現行スマートメーターシステムにおけるクラウド活用方針まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 3 回) – 後半 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

はじめに 2023 年初頭の初回リリース以来、 AWS Systems Manager for SAP チームは SAP のお客様が AWS で SAP システムを管理できるように、お客様からのフィードバックに基づいてサービスの強化に取り組んできました。このブログでは、AWS Systems Manager Application Manager でリリースされた次の 2 つの機能強化について説明します。 AWS System Manager Application Manager コンソールによる SAP HANA データベースシステムの登録:AWS Systems Manager Application Manager コンソールが導入される前は、SAP HANA データベースシステムの登録と検出には AWS コマンドラインインターフェイス (CLI) を使用する必要がありました。AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP HANA データベースへの運用アクティビティの登録と実行が可能になりました。これには、シングルノードと高可用性 SAP HANA データベースシステムの両方のサポートが含まれます。 AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタグ付けを統合すると、AWS Systems Manager Application Manager コンソールから SAP HANA アプリケーションのインサイトを確認できます。複雑な SAP ワークロードを実行している AWS のお客様は、SAP 自動化タスクの管理に苦労することがよくあります。多くのお客様が、オンプレミスでのデプロイから引き継いだツールやスクリプトを使用しており、これらのアプリケーションの管理と運用を一元的に管理してほしいという要望がありました。SSM Application Manager には、SAP アプリケーションの管理を容易にするためのこれらの 機能が備わっています 。AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタギングとの統合が開始されたことで、お客様は AWS Systems Manager Application Manager コンソールから登録された SAP HANA アプリケーションのアプリケーション詳細を表示できるようになります。この統合により、特定の SAP アプリケーションのコンテキストにおけるリソース、インスタンス、モニタリング、および推定コストに関する詳細が提供され、カスタマーエクスペリエンスが向上します。 概要 このセクションでは、AWS Systems Manager Application Manager コンソールで SAP HANA データベース (シングルノード及び高可用性) システムを簡単に登録する方法を示します。 前提条件 ここに記載 されているバージョン要件を満たす SAP HANA データベースシステム AWS Systems Manager for SAP ユーザーガイド の「はじめに」セクションに記載されているステップを完了しました。 AWS Systems Manager Application Manager コンソールによる SAP HANA データベースシステムの登録 リンク先 の AWS Systems Manager コンソールを開きます。 左側のナビゲーションペインで Application Manager を選択します。 Create Application を選択し、 Enterprise Workload を選択します。 Application name  (例:「HANADBHA」) を入力し、SAP HANA Database High Availability のように Application Description を入力します。 Browse instances を選択し、登録したい SAP HANA データベースのインスタンス ID を選択します。注:高可用性 SAP HANA データベースを登録するには、プライマリノードまたはセカンダリノードのインスタンス ID を選択できます。 登録する SAP HANA データベースシステムの SAP System identifer (SID) と SAP instance number を入力します。 HANA システムデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットの Secret ID を選択します。 テナントデータベースを追加するには、 Add credential を選択します。 テナントデータベース名を入力し、HANA テナントデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットのシークレット ID を選択します。 Create を選択します。 登録プロセスが完了するまでに約 3 ～ 5 分かかります。 登録が完了すると、登録が完了したことを知らせる緑色のメッセージバーがコンソールの上部に表示されます。 登録が完了すると、アプリケーションマネージャー画面に戻り、登録したアプリケーションが一覧表示されます。 アプリケーションの詳細を表示 登録したアプリケーションの詳細を表示するには、 Find Application でアプリケーション名を検索します。登録されたアプリケーションが一覧表示されたら、以下に示すようにリスト内のアプリケーション名を選択します。 Application Manager 画面でアプリケーションを選択すると、次に示すように、Application type, Application ID, Application source など、登録したアプリケーションの詳細が表示されます。Application Manager アプリケーションの操作方法や AWS リソースに関する運用情報の表示方法の詳細については、 アプリケーションの使用 を参照してください。 システムを構成するコンポーネントを確認するには、 Resources タブを選択し、Topology セクションまでスクロールします。 登録したシステムは高可用性システムなので、3 つのコンポーネントが登録されていることがわかります。 HDB – HDB00 = 論理データベースを表す親コンポーネント HDB – HDB00-sappridb = プライマリデータベースホストエンティティを表す子コンポーネント HDB – HDB00-sapsecdb = セカンダリデータベースホストエンティティを表す子コンポーネント *注-登録プロセスでは、プライマリデータベースのインスタンス ID を選択するだけで良く、セカンダリデータベースは AWS Systems Manager for SAP によって自動的に検出され登録されます。 特定のコンポーネントに関する追加情報を表示するには、コンポーネント名の左にあるラジオボタンを選択します。この例では、SAP HANA データベースバージョン、OS バージョン、SAP HANA System Replication モード、SAP ホスト名など、SAP Systems Manager for SAP によって登録されたセカンダリ SAP HANA データベースシステムの詳細を確認します。 Application Manager コンソールで SSM for SAP の設定が完了すると、さまざまなウィジェットが有効になっていることがわかります。まず、Overview タブから特定の SAP アプリケーションのダッシュボードを確認します。詳細については、 Register an application with AWS Systems Manager Application Manager を参照してください。 SAP アプリケーションを Amazon CloudWatch Application Insights とコストレポートにオンボードする アプリケーションのタグ付け機能により、SSM Application Manager は SAP アプリケーションを実行している特定の EC2 インスタンスにタグを適用できます。登録後は、SAP システムのログを SSM コンソールに追加するための追加の手動設定や追加の手順は必要ありません。インサイトを表示するには、SSM Application Manager の Monitoring タブから SAP アプリケーションを CloudWatch Application Insights にオンボードする必要があります。 以下の手順に従って、SAP application with CloudWatch Application Insights for SSM で SAP アプリケーションをオンボーディングします。 Application Manager コンソールで SAP アプリケーションを見つけて選択し、Application Details ビューに移動します。 Components ツリーで、アプリケーション名を選択します。 Monitoring タブの Application Insights セクションに移動し、 Add an Application ボタンを選択します。 これにより、 CloudWatch Application Insights の Add an Application widget ウィジェットが開きます。 Specify application details ページの Select an Application or resource group のドロップダウンリストから、SAP リソースを含む SSM for SAP アプリケーションの名前を選択します。 Monitor EventBridge events で、”integrate Application Insights monitoring with CloudWatch Events” チェックボックスを選択すると、通知や Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health API, Amazon RDS、Amazon S3、AWS Step Functions から分析情報を取得できます。 Integrate with AWS Systems Manager OpsCenter で、 Generate AWS Systems Manager OpsCenter OpsItems for remedial actions の横にあるチェックボックスを選択すると、選択したアプリケーションで問題が検出されたときに通知を表示して受け取ることができます。お客様の AWS リソースに関連する OpSitems と呼ばれる運用上の作業項目を解決するために実行されるオペレーションを追跡するには、SNS トピック ARN を指定します。 Next を選択してモニタリングの設定を続行します。 表示されている特定の HANA データベースの箇条書きアイコンを選択します。  Review detected components ページでは、監視対象コンポーネントとそのワークロードが CloudWatch Application Insights によって一覧のように自動的に検出されます。 Next を選択します。  Specify component details ページで、HANA データベースのユーザー名とパスワードを入力します。 Next を選択します。 Review and submit でアプリケーション監視設定を確認し、 Submit を選択します。 アプリケーション詳細ページが開き、アプリケーションの概要、監視対象コンポーネントとワークロード、および監視対象外のコンポーネントとワークロードのリストを表示できます。設定を送信すると、アカウントが SAP アプリケーションのすべてのメトリクスとアラームをデプロイします。これには最大 2 時間かかることがあります。 Application Manager コンソールに戻り、お使いの SAP アプリケーションを見つけて選択し、アプリケーション詳細ビューの Monitoring タブに移動します。これで、アプリケーションインサイトの監視情報が表示されるはずです。 Monitoring タブでは、SAP アプリケーションからのアプリケーションインサイトとアラームを確認できます。 Instances タブ のスクリーンショットをご覧ください。 EC2 インスタンスには、自動的に追加された新しい AWS Application タグが付けられます。これにより、EC2 コンソールにアクセスしなくても EC2 インスタンスの停止などのアクションを実行したり、EC2 インスタンスの詳細を表示したりできます。 Compliance タブでは、コンプライアンス違反項目、保留中のパッチ、修正すべきランブックを確認できます。 Runbooks タブでは、選択した Runbook の実行ログとステータスを確認できます。Compliance、Opsitems、Runbooks などの一部のタブは、現在のバージョンでは SAP アプリケーションに対応していません。今後 SSMSAP が SSM AppManager とより緊密に統合されるときに、これらのタブを含める予定です。 Logs タブでは、CloudWatch から SAP アプリケーションのログにアクセスできます。 Cost タブでは、アプリケーションのコスト履歴とコスト傾向を調べたり、それに合ったコスト削減の推奨事項を受け取ったり、リソース支出を最適化したりできます。現在統合されている SSM for SAP 用 Cost Explorer では、HANA (シングルノード、HA) が稼働している基盤となる EC2 インスタンスに基づいてコスト計算を行うことができます。 結論 このブログでは、AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP ワークロードで運用アクティビティを登録および実行する方法について説明しました。また、AWS Systems Manager (SSM) アプリケーションマネージャーコンソールを使用して、1 つの画面から SAP アプリケーションを管理および運用する方法についても学びました。SSM アプリケーションマネージャーと MyApplications には、SAP アプリケーションの管理を容易にするためのこれらの機能が備わっています。 SAP ワークロードの移行、近代化、革新において、何千ものお客様が AWS を信頼している理由については、 SAP on AWS ページ をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

(Source: MIXI, Inc) MIXI,Inc.(MIXI) has been providing MIXI M, a platform system & wallet service that offers authentication through payment in a one-stop manner, to consumers. On this occasion, MIXI implemented 3D Secure in MIXI M. 3D Secure is a mechanism that confirms the consumer’s purchase intention through additional authentication, realizing a more secure and safe online payment experience. The following is an visualization of the payment experience including 3D Secure from the consumer’s perspective. PCI 3DS (Payment Card Industry Data Security Standard) requires the use of an HSM (Hardware Security Module) certified to FIPS 140-2 Level 3 or higher, or PCI PTS certified for some key management. Therefore, AWS Key Management Service(KMS) could not be used previously, but it became compliant in May 2023 because the internal HSM of AWS KMS was upgraded to FIPS 140-2 Level 3 . There were no precedent cases of PCI 3DS compliance using AWS KMS at the customer’s planning stage. Through support from AWS, the design progressed with AWS KMS as the primary option instead of AWS Cloud HSM. The primary reason is that MIXI understand the advantages of utilizing AWS KMS and clear points of conversation with the PCI 3DS QSA (Qualified Security Assessor) became apparent. Reduction of compliance workload In case of using AWS, compliance responsibilities are shared between the user and AWS based on a shared responsibility model. The higher the level of abstraction of services used, such as managed services, the smaller the user’s responsibility scope and the more compliance work that can be offloaded to AWS. It was clear that using AWS KMS would reduce the amount of compliance work required compared to the initial plan to use AWS CloudHSM. This was beneficial as ongoing work is needed to maintain compliance after conforming to PCI 3DS. Reduction of operation workload In case of using AWS CloudHSM, the user needs to handle some backups of HSMs and cluster management themselves. With AWS KMS, as it is a managed service, everything can be left to AWS. As the customer actively adopts managed services that allow operation with few people, there was a major benefit to using the more managed AWS KMS compared to AWS CloudHSM. AWS SDK In case of using AWS CloudHSM, use of HSM standard SDKs like PKCS #11 or OpenSSL Dynamic Engine was needed for accessing keys. With AWS KMS, keys can be accessed using the familiar AWS SDKs, making development and testing easier. Ease of access control PCI 3DS has requirements for physical and logical access protection of keys. Physical access is AWS’ responsibility for both services, but logical access protection requires work from both the user and AWS. With AWS CloudHSM, protection must follow the HSM specifications, while with AWS KMS there was a benefit to being able to use key policies and the familiar AWS Identity and Access Management (AWS IAM) system that had been used previously. Running costs AWS CloudHSM uses hourly billing so HSM costs are incurred, meaning a minimum configuration of 2 units would cost around $3,400 per month, and adding extra units one by one is needed for scaling out. On the other hand, AWS KMS incurs costs by request, so payment can be made cost-effectively according to the number of requests. Therefore, it was possible to greatly reduce costs from what was originally estimated. Architecture We will introduce the architecture involved in implementing 3D Secure in MIXI M. The customer has been actively utilizing managed services like Amazon API Gateway in MIXI M previously, and also complies with PCI DSS. Operations that use keys managed by AWS KMS are executed via REST API. As long as it is within the request quota defined by AWS KMS, no additional work is incurred due to increases or decreases in access. VPC Endpoint is utilized to call the API through a private route. Changes to keys managed by AWS KMS and key usage can be checked via AWS CloudTrail. Logical access to AWS KMS is managed by key policies, and IAM users or IAM roles that can access keys can be limited from the key side. Voice of the Customer Fumitoshi Taoka (Development Head Office, MIXI M Business Division, MIXI Corporation) Compliance with PCI 3DS was unprecedented and highly challenging for MIXI. When we consulted our AWS account team, they instantly understood our needs and promptly set up a meeting with a security specialist. In the meeting, they provided a lot of useful information, which ultimately allowed us to respond to PCI 3DS compliance rapidly while ensuring security and reliability. Kosuke Asami (Development Head Office, MIXI M Business Division, MIXI Corporation) At MIXI M, a small team does full-stack development and operations, so reducing operation and development costs is always the top priority. By using AWS KMS, we were able to significantly reduce the operation costs required for PCI 3DS and focus on developing the 3D secure system. We fully utilize AWS’s fully managed services, and through that, we have reconfirmed that there are major benefits to reducing development and operation costs. Summary Our customer, MIXI, was able to keep operation costs low while achieving implementation of 3D secure and compliance with PCI 3DS by utilizing AWS KMS. Going forward, they aim to continue optimizing their architecture by leveraging the benefits of managed services, and advancing implementation of various features that will lead to improving their services. Authors Shuhei Akiyama (Game Solutions Architect) Tomohiro Nakashima (Senior Security Solutions Architect)

3月21日より、パッケージリポジトリの管理者は、新しい AWS CodeArtifact パッケージグループ設定機能を使用して、複数のパッケージの設定を 1 か所で管理できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 CodeArtifact は、組織がアプリケーション開発に使用されるソフトウェアパッケージを安全に保存および共有することを容易にする、フルマネージドパッケージリポジトリサービスです。CodeArtifact は、 NuGet 、 Maven 、 Gradle 、 npm 、 yarn 、 pip 、 twine 、および Swift Package Manager などの人気のビルドツールやパッケージマネージャーで使用できます。 CodeArtifact は、 npmjs.com 、 maven.org 、 pypi.org などのパブリックリポジトリからのパッケージのオンデマンドインポートをサポートしています。これにより、組織のデベロッパーは、唯一の信頼できるソースである CodeArtifact リポジトリからすべてのパッケージを取得できるようになります。 シンプルなアプリケーションには通常、数十のパッケージが含まれています。大規模なエンタープライズアプリケーションには、何百もの依存関係が存在する場合があります。これらのパッケージは、ネットワークアクセス、暗号化機能、データ形式の操作などの一般的なプログラミングの課題を解決するコードを提供することで、デベロッパーが開発とテストのプロセスをスピードアップするのに役立ちます。これらのパッケージは、組織内の他のチームによって作成されたり、サードパーティーによって保守されたりする場合があります (例: オープンソースプロジェクト)。 サプライチェーン攻撃のリスクを最小限に抑えるために、一部の組織では、内部リポジトリで使用可能なパッケージと、これらのパッケージの更新を承認されたデベロッパーを手動で精査します。リポジトリ内のパッケージを更新するには 3 つの方法があります。組織内の選択されたデベロッパーがパッケージの更新をプッシュする場合があります。これは通常、組織の内部パッケージを使用する場合に当てはまります。パッケージはアップストリームリポジトリからインポートされる場合もあります。アップストリームリポジトリは、承認されたパッケージの全社的なソースや、人気のオープンソースパッケージを提供する外部パブリックリポジトリなど、別の CodeArtifact リポジトリである場合があります。 デベロッパーにパッケージを公開するさまざまな方法を示す図を以下に示します。 リポジトリを管理する場合、パッケージをダウンロードおよび更新する方法を定義することが重要です。例えば、外部のアップストリームリポジトリからのパッケージのインストールや更新を許可すると、組織は タイポスクワッティング 攻撃や 依存関係の混乱 攻撃にさらされます。有名なパッケージの悪意のあるバージョンを、わずかに異なる名前で公開しようとしている不正行為者を想像してみてください。悪意のあるパッケージは、 coffee-script ではなく、「f」が 1 つだけ含まれた cofee-script であるとします。 アップストリーム外部リポジトリからの取得を許可するようにリポジトリが設定されている場合、深夜まで働いている、集中力を欠いたデベロッパーが、 npm install coffee-script ではなく、 npm install cofee-script と入力してしまえばおしまいです。 CodeArtifact は、パッケージを更新する 3 つの可能な方法として 3 つの許可を定義します。管理者は、内部の publish コマンド、内部のアップストリームリポジトリ、または外部のアップストリームリポジトリからのインストールと更新を allow または block できます。 これまで、リポジトリ管理者はこれらの重要なセキュリティ設定をパッケージごとに管理する必要がありました。本日の更新により、リポジトリ管理者はパッケージのグループのために、これらの 3 つのセキュリティパラメータを一度に定義できるようになりました。パッケージは、そのタイプ、名前空間、および名前によって識別されます。この新しい機能は、リポジトリレベルではなくドメインレベルで動作します。これにより、管理者はドメイン内のすべてのリポジトリでパッケージグループのルールを適用できます。すべてのリポジトリで パッケージオリジンコントロール の設定を保守する必要はありません。 仕組みの詳細 私が CodeArtifact を利用して内部パッケージリポジトリを管理しており、私の組織によって精査済みの AWS SDK for Python ( boto3 とも呼ばれます) のバージョンのみを配布したいと考えているとします。 AWS マネジメントコンソール で CodeArtifact のページに移動し、精査済みのパッケージを内部のデベロッパーに提供する python-aws リポジトリを作成します。 これにより、作成したリポジトリに加えてステージングリポジトリが作成されます。 pypi からの外部パッケージは、まず pypi-store 内部リポジトリにステージングされます。ここで私は、 python-aws リポジトリに提供する前にこれらのパッケージを検証します。ここは、デベロッパーがこれらのパッケージをダウンロードするために接続する場所です。 デフォルトでは、デベロッパーが CodeArtifact に対して認証し、 pip install boto3 と入力すると、CodeArtifact はパブリック　 pypi リポジトリからパッケージをダウンロードし、それらを pypi-store にステージングして、 python-aws にコピーします。 ここで、CodeArtifact がアップストリームの外部 pypi リポジトリからパッケージの更新を取得するのをブロックしたいと考えているとします。 python-aws には、 pypi-store 内部リポジトリから私が承認したパッケージのみを提供してもらいたいと考えています。 本日リリースした新機能により、この設定をパッケージのグループに適用できるようになりました。自分のドメインに移動し、 [パッケージグループ] タブを選択します。その後、 [パッケージグループを作成] ボタンを選択します。 [パッケージグループの定義] を入力します。この式は、このグループにどのパッケージが含まれるのかを定義します。パッケージは、パッケージ形式、オプションの名前空間、名前という 3 つのコンポーネントの組み合わせを使用して識別されます。 許可された各組み合わせで使用できるパターンの例をいくつか次に示します: すべてのパッケージ形式: /* 特定のパッケージ形式: /npm/* パッケージ形式と名前空間のプレフィックス: /maven/com.amazon~ パッケージ形式と名前空間: /npm/aws-amplify/* パッケージ形式、名前空間、名前のプレフィックス: /npm/aws-amplify/ui~ パッケージの形式、名前空間、名前: /maven/org.apache.logging.log4j/log4j-core$ あらゆる可能性を知るために、 ドキュメント をぜひお読みください。 この例では、Python パッケージには名前空間の概念がありません。また、グループには pypi からの boto3 で始まる名前を持つすべてのパッケージが含まれるようにしたいと考えています。そのため、 /pypi//boto3~ と記述します。 その後、パッケージグループのセキュリティパラメータを定義します。この例では、組織のデベロッパーが更新を公開することを望んでいません。また、CodeArtifact が外部アップストリームリポジトリから新しいバージョンを取得することも望んでいません。内部ステージングディレクトリからのパッケージ更新のみを承認したいと考えています。 [親グループから継承] のすべてのチェックボックスをオフにします。 [公開] と [外部アップストリーム] で [ブロック] を選択します。 [内部アップストリーム] の [許可] をそのままにします。その後、 [パッケージグループを作成] を選択します。 一度定義すると、デベロッパーは、 python-aws リポジトリで承認されているものとは異なるパッケージバージョンをインストールできなくなります。デベロッパーとして別のバージョンの boto3 パッケージをインストールしようとすると、エラーメッセージが表示されます。これは、 boto3 パッケージの新しいバージョンがアップストリームステージングリポジトリでは使用できず、外部アップストリームリポジトリからパッケージやパッケージの更新を取得できないようにする block ルールがあるためであり、想定内のことです。 同様に、管理者が依存関係置換攻撃から組織を保護したいと考えているとします。すべての内部 Python パッケージの名前は会社名 ( mycompany ) で始まります。管理者は、 mycompany で始まる pypi.org パッケージからデベロッパーが誤ってダウンロードするのをブロックしたいと考えています。 管理者は、 /pypi//mycompany~ のパターンで、 publish=allow 、 external upstream=block 、 internal upstream=block を使用してルールを作成します。この設定では、内部のデベロッパーまたは CI/CD パイプラインはこれらのパッケージを公開できますが、CodeArtifact は、 mycompany.foo や mycompany.bar など、 mycompany で始まるパッケージを pypi.org からインポートしません。これにより、これらのパッケージに対する依存関係置換攻撃が防止されます。 パッケージグループは、 CodeArtifact が利用可能なすべての AWS リージョン で追加料金なしでご利用いただけます。これは、パッケージとパッケージの更新を内部リポジトリに配置する方法をより適切に制御するのに役立ちます。また、 タイポスクワッティング や 依存関係の混乱 など、さまざまなサプライチェーン攻撃を防ぐのにも役立ちます。これは、CodeArtifact リポジトリを作成および管理するために、Infrastructure as Code (IaC) ツールに今すぐ追加できる追加設定の 1 つです。 今すぐ最初のパッケージグループを設定しましょう 。 — seb 原文は こちら です。

本記事は、「 Event Recap: AWS news from Mobile World Congress 2024 」（2024年3月6日公開）を翻訳したものです。 Mobile World Congress (MWC) 2024 は、10 万人以上の出席者、2,700 社以上の出展者、スポンサー、パートナー、そして1,100 人のスピーカーとリーダーが参加しました。AI、収益化のオポチュニティ、およびクラウドが通信業界にもたらす変革などのトピックが深く議論されました。 「このイベントは、将来を展望し、AI、5G、API が新しい可能性をを示します。 GSMA Open Gateway のような共同イニシアチブを感謝します。」と GSMA のジェネラルディレクターである Mats Granryd は述べました。 AWS は、生成 AI、Network API、5G、Network Transformation などのトピックで、多数のお客様とパートナーのアナウンスメントを発表しました。20 以上の AWS デモを通じて、通信領域の変革、産業のデジタル化、消費者体験の改善におけるる AWS のイノベーションを見ることができました。AWS Recap ビデオをご覧ください。 MWC 2024 での AWS のハイライトをお届けします。 生成 AI は everywhere 通信事業者は、コストと効率の合理化、より良いユーザーエンゲージメント、革新的な新サービスを推進するために、人工知能（AI）、機械学習（ML）、生成 AI を期待しています。エンタープライズグレードのセキュリティとプライバシー、他種類の基盤モデル（LLM）の選択権、データファーストのアプローチ、パフォーマンスが高くコストが低いインフラストラクチャ、これら生成 AI によるイノベーションを加速するための要素を AWS が提供し、通信事業者から信頼を得られています。 MWC 2024 では、AI に焦点を当てたセッションが 40 以上あります。生成 AI は私たちが生きる、働く、そしてコミュニケーションする方法を変えようとしています。 BT グループ は、 Amazon Q のコーディングコンパニオン（ Amazon CodeWhisperer ）を活用し、ソフトウェアエンジニアに生成 AI コーディングアシスタンスを提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% です。これは、生成 AI が提供できる価値、効率、およびサポートの素晴らしい例です。 Tele2 は、Internet of Things（IoT）ユーザーサポートソリューションに Amazon Bedrock を活用していると発表しました。このソリューションは AWS サービスを活用し、Tele2 IoT のユーザーサポートエージェントが複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答に役立ちます。 Network API への関心は史上最高 Application Programming Interfaces（API）を受け入れることは、通信事業者が将来に備えた組織への変革の中心です。McKinsey は、Network API の市場が今後 5〜7 年間で、通信とエッジコンピューティングに関連して、通信事業者に約 100〜300 億ドルの収益をもたらす可能性があると推定しています。さらに API 自体から追加で 10〜30 億ドルの収益が生み出される可能性があります。 GSMA Open Gateway イニシアチブは、AWS を含む 21 のモバイルネットワークオペレーターとクラウドプロバイダーの支援を受けて、MWC 2023 で発表されました。それ以来、Open Gateway は 47 のオペレーターに拡大し、APIがネットワークのユニークな特性を公開することを利用して、革新的なユースケースやアプリケーションを構築したい開発者を引き付けています。 MWC 2024 に向けて、AWS は Verizon、Telefónica、T-Mobile、Orange、Liberty Global を含む世界中の通信事業者と協力して、 AWS 開発者に対し通信事業者のネットワーク API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用していますが、ネットワーク API を活用しながら、 AWS Marketplace を通じてより多くの開発者やユーザーにお届けできます。多くのアプリケーションがAWS 上でテレコ API を活用して金融サービス、ゲーム、没入型体験を提供しています。採用が進むにつれて、世界中でより多くのオペレーターと協業していく予定です。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 Vonage は、新しいソリューションの提供を加速するために AWS とのコラボレーションを発表しました。詐欺対策ソリューションを最初のソリューションとして提供します。AWS の生成 AI サービスは、ソリューションの詐欺検出能力を強化し、モバイル詐欺から自身をより効果的に保護しつつユーザー体験を改善することを可能にします。 通信業界におけるネットワーク変革 世界中の通信事業者は、クラウドの経済性、拡張性、および俊敏性を活用してネットワークを変革し、より重要なことにフォーカスすることができます。これには、通信事業者のコアネットワークの変革、投資の収益化、産業のデジタル化、消費者体験の改善、レジリエンスとセキュリティの向上が含まれます。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商業展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表しました。北米でローミングのアーキテクチャを進化させる最初の通信事業者になることを目指して、海外旅行のユーザーにより高い信頼性と高速のローミングサービスを提供します。一方、欧州では、スイスの通信事業者である Sunrise Business が、スイスの中小企業のクラウド化を加速するために AWS と協力していると発表しました。 ラテンアメリカでは、 Beyond ONE / Virgin Mobile が、地域の通信セクターにおける成長とイノベーションを推進するために AWS と協力していると発表しました。Virgin Mobile は、 AWS Regions と AWS Outposts および AWS Local Zones を含む AWS ハイブリッドクラウド技術の組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 以下で他の発表についてもご覧ください。 Women in Tech AWSはテクノロジー分野における多様性を推進し、女性のテクノロジー分野でのキャリアを支援しています。 GSMA によると、MWC 2024 は 26% の女性参加者が参加し、1,100 人のスピーカーのうち 40% が女性でした。今年、AWS はテレコム業界における女性が直面する機会と課題についてのパネルディスカッションを主催し、AWS エグゼクティブレセプション中にテレコムエコシステム全体にわたる多様性へのコミットメントを強化しました。 デモ 今回の MWC 2024 では、AWS は 3つの主要なテーマを通じて、20 以上のデモを展示しました。 1/ 通信事業の変革 このエリアのデモは、CSP のネットワーククラウド化（RAN、Core、IMS、OSS/BSS など）のジャーニーにフォーカスします。統合的な自動化、オーケストレーション、および生成型 AI ツールチェーンの活用により、新たな成長機会の創出、OPEXの削減、持続可能性の向上、およびレジリエンスの強化を実現しています。reCap のビデオをご覧ください： 例として、Samsung Cloud RAN は、Amazon Bedrock および Anthropic Claude v2 とともに Amazon Bedrock Agents を使用して、AIを用いた RAN 設定チューニングを実現し、最大 25% のパフォーマンス向上を達成できました。 2/ 産業のデジタル化 このエリアのデモでは、AWS がいかに通信事業者を支援し、医療、製造、旅行およびホスピタリティ、金融サービスなどの産業をデジタル化しているのかを示しています。これは、プライベートネットワークソリューション、Network API、パブリック MEC などの通信サービスの革新、ビジネスモデルの革新を通じて実現しています。reCap のビデオをご覧ください： AWS、Accenture、および Verizon は協力し、製造業で 5G の価値を示すために、オンプレミス 5G およびプライベートモバイルエッジコンピューティング（MEC）を展開しました。AWS は Jabil の製造施設で、組み立てラインの異なる場所でのライブストリームカメラの映像を、 AWS Snowball Edge に転送し、コンピュータビジョンのモデルで処理される新しいソリューションを展開しました。このソリューションは、組み立てラインの不良ユニットの誤検出率を 95% 削減しました。 3/ 消費者体験の改善 このエリアのデモは、AWS が通信事業者および ISV と共同開発しているいくつかの革新的なソリューションを紹介しています。これらのソリューションは面白く、スマートで、パーソナライズされた消費者体験につながります。 私たちの SmartHome+ デモでは、TELUS との協力により、AWS 生成 AI、 AWS IoT Core 、および Alexa Voice Services を活用しています。このデモは、TELUS が消費者とのインタラクションを変革し、高度な接続性とAIの時代においてスマートソリューションを拡大していることを示しています。 MWC 2024 に参加しましたか？ AWS for Telecom をフォローしていただければ、今年のイベントのハイライトや、最新のニュースをチェックすることができます。 Mobile World Congress 2025 でお待ちしております！ MWC 2024 における AWS の発表 概要 AWSは、AI-RAN Alliance への参加を発表しました。 AI-RAN Alliance はモバイル通信技術にAIを統合し、無線アクセスネットワーク（RAN）技術とモバイルネットワークを進化させることを目的とした新しい協業イニシアチブになります。 Canonical は、AWS との協業を拡大し、Amazon EKS Anywhere のユーザーが オープン RAN の商用展開で使用するリアルタイム Ubuntu をサポートすることを発表しました。 Unmanned Life は、Liberty Global および AWS とのデジタルトランスフォーメーションにおける GSMA Foundry Excellence Award を受賞しました。受賞したユースケースは、アントワープ港での U-Security の展開であり、Liberty Global の Telenet を通じたドローン接続のためのスライスされた 5G ネットワークと、AWS Snowball Edge デバイスを介したエッジでの AI コンピュータビジョン分析を活用しています。 生成 AI Amdocs は AWS と協業して新しいソリューションを開発しました。Amazon Bedrock でホストされる Anthropic の Claude モデルは、ネットワークデータと Amdocs のアルゴリズムによって生成された洞察にアクセスし、情報の抽出、要約、データのリアルタイム集約などのタスクを実行します。 BT グループ は、Amazon Q のコーディングコンパニオン（CodeWhisperer）を展開し、ソフトウェアエンジニアに生成 AI コーディング支援を提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% になります。最初の4ヶ月間で Amazon Q によって生成されたコードは 100,000 行を超えており、退屈で繰り返しの多い時間のかかる作業の約 12% を自動化しています。BTグループは現在、ビジネス全体で 1,200 人のエンジニアにこのソリューションを広げています。 CelcomDigi は、AWS とのコラボレーションを発表しました。Amazon Bedrock を利用し、従業員が生成 AI ソリューションの実験、革新、実装するための AI サンドボックスを設立します。これには、人事、カスタマーサービス、法務、財務など、CelcomDigi の運用プラットフォームに統合される可能性のあるユースケースが含まれます。 Maxis は、マレーシアのエンタープライズ顧客向けの生成 AI および 5G ユースケースの分野で、イノベーションを加速するための新しい AWS とのコラボレーションを発表しました。Maxis はこれにより、AWS の先進的な機械学習機能を活用し、AI モデルを大規模に構築、トレーニング、およびデプロイして、人工知能の可能性を繰り広げていきます。 MYCOM OSI は、Amazon Bedrockを使用して構築された新しい生成 AI ベースのエキスパートアプリケーションコンセプト、Experience Assurance and Analytics (EAA) GenAie を発表しました。これは、CSP のフロントラインの運用チームとビジネスチームが複雑なネットワークおよびサービスの問題を支援します。データを民主化し、運用コストを削減し、顧客体験を改善することを可能にします。 Snowflake は、AWS と協力して通信分野を変革し、技術的な業務クエリの解決を数日から数分に短縮していることを発表しました。AWS は Snowflake と協力して GenTwin を構築しました。これは、プライベート5G、Amazon Bedrock を活用した生成 AI、および AWS IoT TwinMaker を活用したデジタルツインの組み合わせで、革新的なネットワークオペレーションソリューションです。業界に前例のない効率化、自動化、および適応性を提供し、ネットワーク運用に変革的な時代の幕開けを告げています。 Tele2 は、Amazon Bedrock を活用した IoT ユーザーサポートソリューションを立ち上げると発表しました。このソリューションは AWS サービス活用し、2023 年末の Tele2 IoT Talks でユーザーに披露されました。これにより、Tele2 IoT のユーザーサポートエージェントは、複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答を提供できるようになります。 ネットワーク変革 AWS は、Verizon、Telefónica、T-Mobile、Orange、Liberty Global などの通信事業者と共に、 AWS の開発者に対し通信事業者の Network API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用しており、これにより開発者は通信事業者の API にもアクセスし、AWS Marketplace を通じてより多くの開発者やユーザーにサービスをお届けします。 Beyond ONE/Virgin Mobile は、地域の通信分野における成長とイノベーションを推進するために AWS との協業を発表しました。Virgin Mobile は、AWS Regions と AWS Outposts および AWS Local Zones を含む AWS のハイブリッドクラウドソリューションの組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 BICS は、AWS と協力して新しいクラウドベースのローミングサービスを立ち上げ、国内外で旅行している際に、より速く、より信頼性の高いインターネットアクセスを提供し、モバイルローミング体験を向上させます。BICS は、そのローミング接続プラットフォームを AWS のグローバルインフラストラクチャに移行することにより、従来の国際モバイルローミングサービスよりも最大 5倍 速くローミングインターネット接続を提供することができます。 Casa Systems は、無線と有線の融合（wireless wireline convergence: WWC）における画期的な取り組みを発表しました。Casa の仮想 5G コアの制御プレーン機能を AWS Region に展開し、Casa の仮想化アクセスゲートウェイ機能（AGF）と 5G コアのユーザープレーン機能をプライベートクラウドで展開しました。この取り組みは、通信におけるクラウドネイティブネットワークソリューションの成長を示しています。 Clear Mobitel と NEC Corporation は、AWS 上に構築された NEC の最先端の 5G スタンドアローン（SA）クラウドネイティブコアネットワークソリューションの英国での展開に成功したと発表しました。 Finetwork は、エンドユーザーに対してファイバー、TV、モバイルサービスを含むトリプルプレイオプションをより柔軟で費用効果の高い方法で提供できるようにするために、Amdocs を選び、コアビジネスシステムを変革します。AWS 活用した Amdocs AI ベースの Digital Brands Suite as a Service は、Finetwork のオファリングを強化し、エンドユーザーによりシンプルなデジタルカスタマーエクスペリエンスを提供することを可能にします。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商用展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 NTT DOCOMO は、NEC、AWS、および Red Hat、Qualcomm、Hewlett Packard Enterprise、Dell Technologies の組み合わせによるさらなるオプションを追加したと発表しました。 NTT DOCOMO & OREX は、AWS が OREX パートナーグループに参加したと発表しました。コンテナ管理ソフトウェア、オートメーションフレームワーク、およびオープン RAN ライフサイクル管理を含むエンドツーエンドの オープン RAN クラウドプラットフォームソリューションを提供します。 Omantel は、オマーンのためのソブリンクラウドを作成するために AWS との協力を発表しました。この戦略的関係の目標は、特にオマーンの政府機関や規制産業におけるデータ所在地とセキュリティ要件に対処することです。Omantel は、AWS と協力してクラウドセンターオブエクセレンス（CCoE）を立ち上げ、オマーンの組織がクラウドへの移行を成功させるためのトレーニング、エネーブルメント、およびサポートを提供します。さらに、AWS は Omantel がデジタル変革を追求する際の優先クラウドプロバイダーとなります。 Qvantel は、Etisalat Misr by e& と契約し、AWS Outposts 上で実行される Qvantel Flex BSS ソリューションを実装して、Etisalat BSS のデジタル変革を支援します。 Red Hat は、通信サービスプロバイダーがハイブリッドクラウドで 5G の採用と展開を加速し、管理を容易にするためのコラボレーションを発表しました。Tech Mahindra の Multi-mode Companion Cloud with Red Hat OpenShift は、AWS 上で実行され、RAN、エッジコンピューティング、トランスポート、5Gコアにまたがる複数のハイブリッドクラウドでのネットワークユースケースをサポートします。 Samsung は、AWS との画期的なコラボレーションを通じて 5G イノベーションを牽引します。仮想化ネットワークの未来を垣間見せ、次世代サービスと機能のさまざまな要求を満たすための革新的な道と改善された能力を提供しています。 Sateliot は、Kongsberg Satellite Services (KSAT) 商用ネットワークである KSATlite を介して、5G サービスメッセージング接続を達成したと発表しました。AWS を使用して、Sateliot は完全に仮想化されたクラウドネイティブの 5G コアを Narrowband (NB)-IoT Non-Terrestrial Networks (NTN) 用に構築し、Sateliot のエンドツーエンドサービスをサポートする柔軟で低コストで超スケーラブルなナローバンドソリューションを提供します。 スイスの通信事業者の Sunrise Business は、スイスの中小企業のクラウド化を加速するために AWS との協業を発表しました。Sunrise Business のユーザーは事前定義済みのモジュール化の製品パッケージからベネフィットを得られます。この製品パッケージは、中小企業の要件に合わせてクラウドと通信機能を提供します。この新サービスは、Amazon Simple Storage Service (Amazon S3)、Amazon Elastic Compute Cloud (Amazon EC2)、および AWS Storage Gateway などの AWS サービスをベースに構築されています。 Telstra は、AWS および Nokia との世界初のコラボレーションで、Nokia の IP マルチメディアサブシステム（IMS）のハイブリッドネットワークアーキテクチャの耐久性検証を発表しました。この IMS 検証では、特にネットワークの信頼性、耐久性、およびユーザー体験の向上を目指した AWS との長期的な戦略関係に基づいています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表し、北米で初めてローミングのアーキテクチャを進化させます。海外旅行中のユーザーにより高い信頼性と高速なネットワークを提供する通信事業者になることを目指します。TELUS は、仮想化されたローミングゲートウェイを使用し、世界中の AWS リージョン内に自社のネットワークを収容することができます。これにより、トラフィックはカナダを経由する必要はなく、TELUS のネットワークを収容している最も近い AWS リージョンに直接ルーティングされ、モバイルサービスの速度と応答性が大幅に向上します。 Verizon Business と Audi AG は新しいパートナーシップを発表しました。ドイツのノイシュタットにある Audi 自動車の試験トラックで最先端のプライベートワイヤレスネットワークと技術テスト環境を構築します。Audi の試験トラックは、5G および LTE のデュアルモジュラープライベートワイヤレスプラットフォーム（Nokia）、プライベートマルチアクセスエッジコンピュート（MEC）機能（AWS）、リアルタイムビデオおよびデータ伝送技術（Smart Mobile Labs）、C-V2X 通信、および音声、データ、自動運転、安全性などをカバーするモバイル/自動車アプリケーションで実装されます。 Vodafone Ireland は、AWS 上の Celfocus BSP の成功展開を発表しました。プロジェクトの主な目的は、AWS が選ばれたクラウドプロバイダーとして、クラウドへの移行における可用性、耐久性、スケーラビリティの要件を確保し、将来の BSP ロードマップへの展開の入り口になります。 Vonage は、AWS とのコラボレーションを発表し、新しいソリューションの提供を加速します。最初のソリューションは、詐欺対策ソリューションであり、AWS の生成 AI サービスを活用することにより、詐欺検出機能を強化します。ユーザーがモバイル詐欺から自身をよりよく保護しつつユーザー体験を改善することを可能にします。 ネットワーク収益化 2degrees は、MVNO およびデジタルブランド市場への卸売ビジネスをモダナイズ化するために Totogi を選択しました。これは、ユーザー、コミュニティ、および環境への 2degrees の継続的なコミットメントの一環であり、MVNO ブランドを繁栄させるための software-defined offering になります。Totogi が選ばれた理由として、Totogi の Charging-as-a-Service（CaaS）は、AWS の AI サービスの Amazon Bedrock および機械学習（ML）サービスの Amazon SageMaker を使用して構築され、迅速なオンボーディングとMVNO ユーザーに対する効率的なサービスを提供できます。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 DigitalRoute、Intraway Symphonica、および Totogi は、Trektel のもとに 、AWS と協力してモバイル仮想ネットワークオペレーター（MVNO）in-a-box ソリューションを導入しています。業界の go-to-market の能力強化が狙いとなります。 Ericsson は、Wipro と協力し、AWS 上で ODIDO の Billing インフラストラクチャのモダナイズ化と発表しました。ODIDO のモバイル仮想ネットワークオファリング（MVNO）である Ben の全加入者が、AWS上でホストされる Ericsson Billing への移行に成功しました。 Intel は、AWS との継続的な連携により、ユーザーがバーティカルマーケットにおけるプライベートネットワークの加速を支援すると発表しました。最新の事例として、Integrated Private Wireless（IPW）on AWS プログラムのシステムインテグレーターとして Amdocs が追加されました。このプログラムを通じて、AWS のユーザーは、エンドツーエンドの Amdocs Mobile Private Network（MPN）サービスにアクセスし、Intel® Xeon® プロセッサが入る AWS Outposts サーバー上に構築されたインフラストラクチャを利用することが可能になります。 Liberty Global は、AWSとの協力で、Network-as-a-Service（NaaS）フレームワークを作成すると発表しました。開発者がイノベーションのために、NaaS を通じて、Liberty Global の固定およびモバイルネットワークにアクセスできます。Liberty Global の通信ネットワークと AWS のグローバルクラウドインフラストラクチャおよび既存の開発者エコシステムの組み合わせを活用して、NaaS ならではの魅力的なユースケースを開発することを目指しています。 著者について Chivas Nambiar Chivas Nambiar は、アマゾン ウェブ サービス (AWS) の Global Telecom Business Unit のゼネラルマネージャーです。 彼は、通信事業者、ネットワーク機器プロバイダー、ISV がクラウドに移行してビジネス変革を支援する世界規模のチームを率いています。 彼のチームは、クラウドの積極的な導入を推進し、コスト削減を実現し、ビジネスの俊敏性を高め、イノベーションを加速し、世界中のさまざまな通信ドメインにわたって新しいビジネスチャンスを創出してきました。 Chivas は熟練なエンジニアでありながら、チームを構築し、顧客やパートナーと協力してイノベーションを加速することに情熱を注いでおり、電気通信業界の変革に専念しています。 2020 年に AWS に入社する前は、Verizon Communications 社で通信業界に 17 年間勤務しました。彼の最後の役職では、クラウドおよびプラットフォーム エンジニアリングの担当エグゼクティブ ディレクターとして、Verizon の広範な IT およびネットワーク システム ポートフォリオから 1,000 を超えるビジネス クリティカルなアプリケーションをパブリック クラウドに移行する取り組みを主導しました。 以前の職務では、Chivas はグローバルな 24 時間年中無休の運用チームと、Voice Over IP (VoIP) および Wi-Fi 製品の開発と実装に取り組むエンジニアリング チームを運営していました。 Chivas は仕事がないときは、水が大好きな子どもについていくために水泳を習い、大家族の集まりのためにグリルを楽しんでいます。 翻訳はソリューションアーキテクトの陳誠が担当しました。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 このブログでは、昨年末のAWS re:Invent 2023 で発表された新機能・Knowledge Bases for Amazon Bedrock を活用して、設計開発や研究における特許検索を効率化する方法について解説します。 はじめに　過去の関連ブログ 前々回、 こちらのブログ で、AWS の生成系 AI サービス・ Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用し、設計開発ドキュメントを効率的に作成する方法について解説しました。 前回、 こちらのブログ で、Amazon Bedrock の Stable Diffusion XL v0.8 ( by Stability AI 社) モデルを指定して、 Playgrounds の画像生成機能を手軽に使用し、新規プロダクト開発において意匠を文章から作るような、企画構想を充実させる方法について解説しました。 Knowledge Bases for Amazon Bedrock について Knowledge Bases for Amazon Bedrock を使用すると、 Amazon Bedrock 内から 基盤モデル をデータソースに接続して 検索拡張生成 (RAG) を行うことができます。 RAG は、プライベートデータの使用と基盤モデルを組み合わせた技術です。仕組みを理解するために、 Amazon Bedrock のチャット機能 と比較します。まずチャット機能のイメージ図です。 次に、Knowledge bases for Amazon Bedrock （RAG）のイメージ図です。 上のレーンの流れを説明します。①データソースから②ドキュメントを管理しやすいチャンク（通常2〜8語程度からなる意味を形成する塊）に分割し、③ Embedding （埋め込み：テキストを言語モデルが処理しやすい数値ベクトル表現に変換する）を生成し、④埋め込みを ベクトルDB に格納します。 下のレーンでは、水色の箇所が通常のチャット機能と共通する部分になりますが、⑤ユーザーの問い合わせに対して上のレーンと同様に Embedding を生成し、⑥ベクトル DB と照らし合わせて似たドキュメントを検索した上で、検索結果を加味して Text モデルが回答生成し、ユーザーに回答します。 これによって、例えばデータソースを社内ストレージに指定することで世に出ていない自社固有の回答をセキュアに生成したり、または外部の信頼できる知識ベースから事実を検索して、最新の正確な情報に基づいて回答を生成することが可能になります。 Knowledge Bases for Amazon Bedrock を使用することで、RAGの機能がコード不要で、Amazon Bedrock のマネージドな機能で簡単に実現でき、エージェントの構築時間を短縮できます。また、ナレッジベースを追加することで、プライベートデータを活用できるようにモデルを継続的にトレーニングしたりする必要がなくなるため、費用対効果も向上します。 なお、本ブログの内容は2024年3月21日時点の内容に基づいて執筆しています。執筆段階では東京リージョンにおいては Knowledge Bases for Amazon Bedrock は利用できません。 現時点で Knowledge Bases for Amazon Bedrock が利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、執筆段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 今回のテーマは設計開発における特許検索です。特許を検索する際の主な課題は以下のようなものがあります。 特許の内容は一見難解であることが多いため、解釈が難しい 新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難 こういった課題に対して、Knowledge Bases for Amazon Bedrock を活用して、特許データが保管されているデータソースを対象として RAG を実行することで解決を試みましょう。 Knowledge Bases for Amazon Bedrock のデータソースは現状、 Amazon S3 が指定できるようになっています。Amazon S3 に検索対象のデータを保管しますが、例えばもし世の中に存在する全ての特許ファイルを保管してしまうと、データ保存コストやベクトル DB を作成するコストが大幅に上がってしまうため、例えば関連する大きなテーマで絞り込むなどして、RAG を行う目的に応じて適切な特許ファイルを保管するようにしましょう。 Knowledge Bases for Amazon Bedrock の使用にあたって発生する料金については以下関連サービスの料金ページをご参照ください。 Amazon Bedrock Amazon S3 Amazon OpenSearch Serverless 今回はサンプル題材として、筆者が過去に発明した以下の特許3件を対象に、Bedrock で実現した RAG の仕組みに取り込みます。PDF ファイルをダウンロードして Amazon S3 に保存 します。 JP2013174393A JP2013174394A JP2014194291A 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に オーケストレーション という項目が表示されます（※初回アクセス時はペーンが表示されておらず「Get started」ボタンを押す必要がある場合があります）ので、配下にある ナレッジベース 機能にアクセスしてみましょう。これが Knowledge Bases for Amazon Bedrock になります。 ここからページ下部にあるオレンジ色の「ナレッジベースを作成」をクリックします。 まずナレッジベース名を入力します。識別しやすい名前をつけてください。 画面下部にある IAM 許可については、「新しいサービスロールを作成して使用」を選択します。サービスロール名は自動的に付与されたもので構いません。 「次へ」を押すと、データソース設定ステップに進みます。 ここではデータソース名を入力します。ナレッジベース名のときと同様、識別しやすい名前をつけてください。 また、RAG のデータソースとなる S3 の URI を指定します。今回のサンプル題材である特許 PDF 3ファイルが保存された S3 バケットのURIを指定します。PDF ファイルを S3 バケットに保存する方法はこちらをご参照 ください。なお、Knowledge Bases for Amazon Bedrock は 次のファイル形式 をサポートしています。 「次へ」を押すと、埋め込みモデルの選択画面に進みます。埋め込みモデルは、RAG のイメージ図のところで説明した Embedding モデルに相当します。ここでは、Amazon が提供する Titan Embeddings G1 – Text モデルを選択します。このモデルは、テキスト検索や、テキスト間のセマンティック類似性の測定、クラスタリングなどのユースケースに活用ができ、日本語もサポートされています。 画面下のほうにあるベクトルデータベースについては、「新しいベクトルストアをクイック作成」を選択します。 「次へ」を押すと、確認して作成ステップに進みます。これまでのステップでの設定をあらためて確認し、一番下にあるオレンジ色の「ナレッジベースを作成」ボタンを押すと、ベクトルデータベース作成、ナレッジベース作成が自動的に開始されます。作成が完了したら、「同期」ボタンを押します。データソースの同期が完了するまでに要する時間はデータ量によりますが、今回のような サンプル題材 PDF 3ファイルの場合は、筆者のネットワーク環境では数秒ですぐに完了しました。 今後、例えばデータソース内の PDF ファイルが新たに100個追加された場合など、更新があったときは同様にデータ同期を実施すると RAG のデータソースが都度更新されることになります。 データソース同期が完了すると、ナレッジベースをテストすることができます。画面右側にあるオレンジ色の「モデルを選択」をクリックします。ここでいうモデルは、 RAG のイメージ図のところで説明した Text モデルに相当します。 候補として提示された基盤モデルの中から選択しますが、ここでは Anthropic 社の Claude の中で最新バージョンの v 2.1 モデルを指定します。 わずかこれだけの前準備で Knowledge Bases for Amazon Bedrock が使用可能な状態になりました。 特許検索における課題への対応 それでは、特許検索における以下課題にどのように対応できるかを見ていきましょう。 課題1 「特許の内容は一見難解であることが多いため、解釈が難しい」 今回のサンプル題材の3つはいずれも極低温冷凍機という一般の方には馴染みが薄いプロダクトを対象としています。その中の一つ、たとえば、 JP2013174393A の文章を見てみますと、馴染みが薄い方には文意を読み取るのが難しいかもしれません。発明者の私ですら正直理解するのが困難です。 そこで、Bedrockに対して以下のような質問を投げてみましょう。以下画像のメッセージ入力欄に質問を書き、オレンジ色の実行ボタンを押します。 Bedrockへの質問「特許JP2013174393Aについて。この特許はどのような内容で、どのような点に新規性、進歩性があるのか、中学生にもわかる言葉で簡潔に説明してください。」 すると、以下画像の紫枠のように、回答を返してくれました。 極低温冷凍機がどういう原理で動作しているかや、特許要件として重要な要素である新規性・進歩性は「弾性手段」を設けてモータ負荷を軽減する工夫を取ったところにあるということが簡潔に要約されました。 また、回答文の中に[1]、[2]といったリンクが付いています。[1]、[2]は回答の元になった文書を指しており、これによって、ファイル内の広範囲に及ぶ情報の中のどの箇所を根拠として回答したかが明らかになり、ユーザーは回答の信頼性を簡単に確認できます。 課題2 「新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難」 自分の思いついた発明内容は既に他人によっても発明されており、特許取得されていたというのはよくあるケースです。手戻りの無駄が発生することを防ぐために、以下のようなRAGを使って類似特許を確認する事前確認を取りましょう。 例えば、極低温冷凍機に関する以下のような発案をした場合です。 Bedrockへの質問「モーターの回転運動を往復運動に変換するネジ螺合駆動形式の極低温冷凍機を発案しました。これによって従来の形式よりも機構部分の部品点数が少なくコストが低くできます。これと内容が重複する既存特許はデータソースの中にありますか？」 これに対しても課題1のときと同様の形式で以下回答を返してくれました。 Bedrockからの回答「はい、データソースの中に本発明と内容が重複する既存特許があります。[1] [2] [3] [4] [5] 特許文献1から5は、モーターの回転運動を螺合機構(ネジ機構)によってディスプレーサの往復運動に変換する極低温冷凍機に関するものであり、本発明と同様に機構部分の部品点数が少なくコストが低減できることが記載されています。[6] [7] [8] [9] [10] 」 これはデータソース内にある JP2013174394A という特許を指します。 このような形で、概要のような曖昧な文章からでも類似特許を検索でき、重複を指摘してくれます。今回はサンプル題材3ファイルをデータソースに保存しただけですが、データが膨大になるほどより効果を発揮します。 ただし、プロンプト（質問文の書き方）によっては似たような特許が存在するにも関わらず検索されない場合もあります。プロンプトが望ましい形で書かれていた場合であっても、 出願するにあたっての判断のためには弁理士など専門家によるチェックを依頼することを推奨します。 また、今回のような利用方法をする場合には、著作権など法的な問題がないことをご確認のうえ実施いただきますようお願いします。 まとめ いかがでしょうか。今回は特許検索を題材としましたが、取り扱った二つの課題解決応用以外にも、データソース内にある特許を組み合わせて新たな発明を検討するような使い方をするなど、他にも様々な活用アイデアが考えられると思います。 また、特許検索以外にも、社内文書をデータソースにした RAG は多種多様なユースケースが考えられます。例えば、自社製品の設計過去トラブル集をデータソースとし、新規製品の設計を行うに当たって困っている検討箇所があった場合に、注意すべき点を問いかけて、該当する過去の失敗事例やその解決策を提示してもらう、などが考えられます。 新機能の Knowledge Bases for Amazon Bedrock を活用して、少ない前準備で手軽に RAG を実施し、業務を効率化させていきましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているシニア事業開発マネージャーの川又です。 2024 年 3 月 14 日に製造業向けオンラインセミナー「データ活用による製造業のトランスフォーメーション」を開催いたしました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 今回のセミナーは、製造業の皆様や、製造業のお客様を持つパートナーの皆様から、よくご要望をいただく、「製造業におけるデータ活用やお客様での事例」を単にプレゼンテーションでご紹介するだけではなく、実際に視聴者の皆さまにより具体的にイメージを持っていただけるようデモも交えながらお伝えさせていただきました。それぞれのセッションの内容を本ブログと動画でお届けいたします。 オープニングセッション：製造業におけるデータジャーニーとベストプラクティス 登壇者: AWS エンタープライズ技術本部 ハイテク・製造・自動車産業グループ 製造第一ソリューション部・部長 河村 聖悟 資料リンク 私達の暮らしの中では、天気や交通状況など、日常生活の様々な場面でデータに基づいた判断が行われています。製造現場においてもデータの力を活用できれば、生産効率・最適化など多くのメリットがありますが、現場には課題が山積みです。デジタル化されていない情報が多数存在して、可視化は部分的であり、オペレーションが分断されているなどの課題が挙げられます。課題対策の指針として「製造業におけるデータジャーニー」というロードマップをご紹介します。 製造業におけるデータジャーニー 「製造業におけるデータジャーニー」は、データ運用の成熟度によって4つのエリアに分かれています。エリア1は「局所的なリアルタイムの可視化」、エリア2は「全社的な可視性」、エリア3は「予測的オペレーション」、エリア4は「コスト最適化オペレーション」です。必ずしもすべてのエリアを順番に進む必要はなく、現在の成熟度から次のステップを知ることが重要です。 エリア１：局所的なリアルタイムの可視化 エリア 1「局所的なリアルタイムの可視性」では、パイロット施設や重要要素を特定し、優先ワークロードにソリューションやダッシュボードを導入します。既存設備からデータを取り出すことが重要で、現場ノウハウから生産管理者への情報伝達を円滑にします。大きな投資は不要ですが、全体最適化を見据えたロードマップを意識しつつ、将来的な展開を見越した取り組みが求められます。 エリア２：全社的な可視性 エリア 2「全社的な可視性」では、全社的なデータレイク戦略の構築が求められます。企業全体のデータレイクと OT / IT 接続戦略が必要不可欠です。リアルタイムなデータは、意味のあるコンテキストを持った状態での可視化が分析に必要であり、優先順位を付けたユースケースについて、丁寧に複数の場所で段階的に実施していくことが重要です。現場にとってインセンティブが少ないため、中期的な視点で各現場・部門との調整を行い、PoC を実施して小さな成功体験を積み重ねていく必要があります。 エリア３：予測的オペレーション エリア 3「予測的オペレーション」では、アナリティクスや AI、機械学習を活用して工場の財務計画や生産能力計画でリソースの最適化を図ります。過去のデータだけでなく、仮説に基づいた予測を行う仕組みが必要不可欠です。標準のモデルなどを活用した予測データ・グラフから新たな気づきを得ることで、これまでにない観点や改善や、判定条件を設ける事で機械同士の連携や自動化が可能になり、フィードバックループを作り出せます。現場では手戻りや重複作業の削減、多品種少量生産への対応など、エリア3のメリットを享受できるようになります。 エリア４：コスト最適化オペレーション エリア 4「コスト最適化オペレーション」では、企業がビジネスプロセス全体を最適化する能力を獲得します。アナリティクスに基づく最適化がモデルと意思決定プロセスに統合されることで、真のコスト削減と、統一されたインターフェイスにより工場・工程を横断した全体最適化が実現できます。設計・デザイン・スマートファクトリー・スマートプロダクトがデータでつながり、製品やプロセスの継続的な改善につながります。エリア4に至るには、企業全体のデータ統合と、新しいデータ駆動型の企業運営モデルへの関係者全員のコミットメントが必須条件となります。 モダンデータ戦略の成功要因としての３本の柱 製造におけるデータジャーニーを支える大切な3つの柱をご紹介します。1 つ目は「マインドセット」の柱です。データドリブンなカルチャーを取り入れてデータ活用を進めるためには、意識改革が不可欠であり、経営層からの強いコミットメントが求められます。2 つ目は「人材とプロセス」の柱です。イノベーションを最も促進できる組織構造・役割・プロセスを定義してコミュニケーションを密にし、データ活用の舞台・教育体制を提供することを指します。最後に「テクノロジー」の柱があります。パフォーマンス、費用対効果、安全性、スケーラビリティに優れた、クラウドデータアーキテクチャの活用に代表されます。これら 3 つの柱が、データ活用を企業文化に根付かせる鍵となります。 製造業における AWS の幅広いケイパビリティ 講演の中では、製造業のデータジャーニーを力強くサポートする AWS の幅広いサービスとケイパビリティをご紹介しました。AWS は、工場のエッジ、オンプレミス、既存システムとの連携を強くサポートします。エッジでは、エンドツーエンドのセキュリティ、開発、デプロイ、管理の機能を提供します。様々なデータフォーマット・転送形式に対応したデータ収集機能や、柔軟なデータレイクのインフラ、データ管理に関するセキュリティ、アクセス権限管理機能を提供しています。目的別のデータベース、豊富な分析手段、機械学習のツール、リアルタイム分析の可視化機能が、データジャーニーのジャンプスタートを可能にします。 製造におけるデータジャーニーでは誰もが主役 データジャーニーを推進するには、経営層、生産管理者、現場の全ての関係者がコミットし、同じ歩幅でなくとも、同じ方向を向いて小さな一歩を踏み出す必要があることをお伝えしました。完全なデータ利活用は一朝一夕にはできませんが、クラウドの力を借りてすぐに開始可能であり、製造業のデータ活用の可能性を身近に感じていただけたら嬉しいです。AWS は、お客様とともに製造業のデータジャーニーを歩んでいく所存です。 ここからは、製造業におけるデータジャーニーのいくつかのエリアについて、詳細な説明やデモをご紹介します。 デモ１：業務改善につながる生産関連データ活用 登壇者: AWS ソリューションアーキテクト 山田 航司 資料リンク このセッションでは、データジャーニーのフェーズ1「ローカライズされたリアルタイムの可視性」における、既存の設備からデータを取り出す方法がイメージできるように、ミニチュアスマートファクトリーデモをご覧いただきました。スマートファクトリーデモでは、受注に応じた加工を施して出荷する 「多品種少量の受注生産品」の生産ストーリーを設定しました。 このような複雑化したオペレーションに生じやすい課題として、「人手に頼った生産によりヒューマンエラーが起こりやすくなる」や「生産の不安定化」といった課題が挙げられます。対応策として、設備装置から発生するデータを AWS IoT SiteWise や AWS IoT Core に集め、生産稼働状況をニアリアルタイムで可視化することで、異常やイレギュラーが発生してからアクションに移るまでの時間を短縮し、稼働率を高める方法をご説明しました。 既存設備を新しい機能をもった設備に入れ替える必要はなく、PLC などまずはできるところから可視化していくが重要であり、ミニチュア工場の中のどの部分が既存設備にあたるかや、 AWS IoT Greengrass をインストールした産業用 PC を新規で設置すれば生産データ活用のためにクラウドにデータを送れるようになることをビジュアルで解説しました。 デモ２：予測的オペレーションを実現する AWS Supply Chain 登壇者: AWS ソリューションアーキテクト 水野 貴博 資料リンク このセッションでは、サプライチェーン領域においてデータジャーニーのフェーズ3「予測的オペレーション」を実現する AWS Supply Chain をご紹介しました。サプライチェーンの領域では、エンタープライズリソースプランニング (ERP)、倉庫管理システム (WMS)、注文管理システム (OMS)、輸送管理システム (TMS) など、システムがサイロ化されているケースが多く、サプライチェーンのデータを統合し、エンドツーエンドのプロセスの可視化を実現し、予測的なオペレーションを実現することが難しいとされてきました。 AWS Supply Chain は、サプライチェーンデータレイクによる統合データ管理を提供し、既存のプロセスを最適化することができます。統合されたデータを活用し、予測精度の向上、過剰在庫の削減、サイクルタイムの短縮を可能にします。 AWS Supply Chain の「データ取込み」「在庫可視化」「デマンドプランニング」そして、2024 年にリリースされたばかりの「サプライプランニング」「N – Tier 可視化」について、デモを交えてご紹介しました。最後に 2024 年後半リリース予定の生成 AI アシスタント「Amazon Q」をご紹介しました。自然言語インターフェースによるサプライチェーンデータに対して「何が」「なぜ」「もし～だったら」という問い合わせを行う様子をご覧頂きました。 デモ３：クラウドネイティブ BI Amazon QuickSight 登壇者: AWS ソリューションアーキテクト 岩根 義忠 資料リンク このセッションでは、データジャーニーのフェーズ2「全社的な可視性」に至ることの価値と、その一例としてのデモをご覧いただきました。データドリブンな意思決定を一貫した KPI に基づいて素早く行えるようになると、意思決定サイクルが組織の各階層で頻繁になり、結果として組織・工場のアジリティを高めることができます。 こうしたアジリティを高めるための、一貫した KPI に基づくデータドリブンな意思決定の一例として、 Amazon QuickSight を用いた製造ダッシュボードのデモをご紹介しました。また、BI ツールによる可視化や分析レポートのために必要とされる専門知識のハードルを下げ、「データ分析の民主化」を成し遂げるために、自然言語による直感的なダッシュボード作成や、ダッシュボードから得られる洞察を自然言語でレポート化できる Amazon Q in QuickSight (Preview) によるダッシュボード作成とレポート作成のデモをご紹介しました。 部門や工程の壁を超えたクラウドへのデータ集約と、強力な可視化ツール、生成AIの組み合わせにより、「現場に可視化のパワーを与える」ことが可能となり、さらに次の段階の「予測的オペレーション」に向け、改善活動の志向が全体最適に向かうことが期待されます。 終わりに 本セミナーでは、 製造業におけるデータジャーニーとベストプラクティスをご紹介するプレゼンテーションから、工場の可視化‐複数工場の現在の稼働状況を遠隔地から把握するデモ、サプライチェーンに関わるデータ活用とデモ、製造現場のデータ活用における思想設計やユースケース設定に立ち戻ったデータ活用推進のアイディアやデモや AWS の提供する新機能活用などを通して、AWS がご支援する製造業におけるデータ活用を紹介しました。 本ブログは、事業開発マネージャーの川又俊一、ソリューションアーキテクトの 河村聖悟、山田航司、水野貴博 、岩根義忠が執筆しました。

こんにちは。ソリューションアーキテクト (以下 SA) の津和崎です。 2023 年 11月 7日に「AWS Media Road Show 2023 – AWSメディアサービスを使ったコンテンツ配信の最前線」と題したイベントを開催しました。AWS Media Serviceの最新情報をAWS Elemental R&DのProduct Managerが直接解説するLoft Eventです。ご参加いただきました皆様には、改めて御礼申し上げます。 当日の様子と実施内容 セッションの紹介 MediaLive/MediaConnect最新動向 AWS Elemental R&D Head of Product, Live Services Mike Cronk 資料ダウンロード クラウドベースのライブ制作と UHD OTTストリーミングによって、業界をリードする品質・拡張性・回復力をどのように実現しAWSユーザーのお客様が収益を最大化しているか、Paramount Global、National Hockey League（NHL）、ロレックス・パリ・マスターズ（テニストーナメント）、Sky Sports、PGAツアー、Stan. の事例を紹介し、数多くのスポーツやイベント会場からクラウドを活用してライブ制作する利点を紹介しています。多くのVODサービスで最高品質がUHDにシフトするなかで、エンコードに必要な分散処理の課題を解決するMediaLiveの内部的改善、エンコーダーまでのMediaConnectを活用した伝送、パッケージング・配信まで、クラウドをフル活用したアーキテクチャをご紹介しています。Media Live/Media Connectは現在、東京・大阪リージョンでの展開も進んでおり、コンテンツを国外に出すことなく2つのリージョンによるDRが実現できます。 MediaTailor Channel Assembly最新動向 AWS Elemental R&D Senior Prod Manager Phil Harrison 資料ダウンロード Live・VOD問わずパーソナライズされた広告挿入およびチャネルアセンブリを可能にするAWS Elemental MediaTailor について、本セッションではVODとLive to VODへの広告挿入についての基本機能の紹介と利点、ユースケース、それがどのような技術で動いているかをご紹介し、Case StudyとしてSeven West Mediaでの活用事例をご紹介しています。Media Tailorで広告挿入する場合のレファレンスとして、手動でスケジュールしたタイミングで広告を挿入するアーキテクチャ・AIによるユーザーごとにパーソナライズされた広告挿入に対応できるアーキテクチャをそれぞれ紹介し、直近の機能リリース（Liveソースへの対応・Channel Assemblyで迅速なスケジュール更新等）についても紹介しています。 MediaTailor SSAI (Server Side Ad Insertion)最新動向 AWS Elemental R&D Senior Product Manager Peter Henning 資料ダウンロード AWS Elemental MediaTailorにてサーバーサイド広告挿入をする場合のアーキテクチャとして、ライブ・VODそれぞれに対しての広告挿入のレファレンスアーキテクチャを紹介し、広告のトランスコーディングやレポート、オブザーバビリティ、AWS 以外の多様なAdサーバーへの対応、大阪リージョンの対応など深掘りして機能の紹介をしています。 特に、オーバーレイ広告についてはPeacockの事例・IBCにてデモが行われたスクィーズ/フレーム広告などもご紹介し、コンテンツと合成された形で広告を表示し、視聴者は広告中もコンテンツを見続ける視聴体験が可能になる利点・機能をご紹介しています。加えて、マニュフェストによるCreative IDシグナリングにより、広告再生のコントロールをどのようにして実現するか、HLS インタースティシャルへの対応予定についても詳しく紹介しています。 MediaConvert最新動向 AWS Elemental R&D Principal Product Manager Max Denton 資料ダウンロード AWS Elemental MediaConvertを活用したトランスコーディングについて、東京に加え大阪リージョンでも活用できるようになった状況やSony LIV・Slackでの活用事例をご紹介しております。 最新機能の紹介としては、取得できるメトリクスの追加や動画の品質を向上するための機能として、圧縮効率の向上・AI Human Vision System を使用した知覚できないほどの微細なノイズの除去・シャープネスの調整機能など、 Bandwidthを低く保ったまま動画品質を向上させる方法を紹介しております。トランスコードのためのワークフローを改善する機能として、ビデオソースの置き換え機能、コンテナ・オーディオ・キャプションはそのままでビデオエッセンスのみをパススルーできる「トランスマックス」機能、出力先のS3 Tierを変更できる機能など、さまざまな変更に対応している点を詳しく紹介しています。 まとめ 今回は、U.S.から来日したMedia サービスのProduct ManagerよりAWS メディアサービスを使ったコンテンツ配信の最新情報をご紹介いたしました。本イベントが、より高品質でスケーラブルな配信がより短期間に数多く、収益性も伴う形で実現するためのきっかけになれば幸いです。 AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 津和崎美希

3月18日週はストレージの話題からお届けします。 3月11日週、 Amazon Simple Storage Service (Amazon S3) の 18 年にわたるイノベーションを祝うイベントが AWS Pi Day 2024 で開催されました。Amazon S3 のマスコットである Buckets も参加して、非常に楽しいイベントとなりました。 4 時間にわたるライブストリームでは、ユーモアを交えながら、 PartyRock を使用した パイのレシピ 、デモ、コード、そして生成 AI と Amazon S3 に関するディスカッションが紹介されました。 AWS Pi Day 2024 — 2024 年 3 月 14 日の Twitch ライブストリーム ライブストリームを見逃した場合は、 録画 を見ることができます。今週、 community.aws の AWS Pi Day 2024 に関する投稿 も更新して、ショーのメモとセッションクリップを追加する予定です。 3月11日週のリリース 私が注目したいくつかのリリースをご紹介します。 Anthropic の Claude 3 Haiku モデルが Amazon Bedrock で利用可能に — 最近、 Anthropic が基盤モデル (FM) の Claude 3 ファミリー (Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus) を発表しました。このファミリーの中で最も高速でコンパクトな Claude 3 Haiku が Amazon Bedrock で利用できるようになりました。詳細については、 Channy の投稿 を参照してください。さらに、同僚の Mike が、 Amazon Bedrock での Haiku の使用を開始する方法を紹介する動画 を community.aws で公開しています。 AWS CloudFormation で最大 40% 速くスタックを作成  — AWS CloudFormation の CONFIGURATION_COMPLETE という新しいイベントでスタックを最大 40% 速く作成できるようになりました。このイベントを使用すると、CloudFormation はスタック内の依存リソースの並行作成を開始し、プロセス全体がスピードアップします。この新しいイベントでは、リソースの一貫性チェックが不要なシナリオでも、ユーザーはスタック作成プロセスをより細かく制御することもできます。詳細については、 この AWS DevOps ブログ記事 を参照してください。 Amazon SageMaker Canvas がモデルレジストリ統合を拡張 — SageMaker Canvas のモデルレジストリ統合が拡張され、時系列予測モデルに加えて、 SageMaker JumpStart で微調整されたモデルが含まれるようになりました。ユーザーは、これらのモデルをワンクリックで SageMaker モデルレジストリに登録できるようになりました。この機能強化により、モデルレジストリの統合が、リグレッション/分類表モデルや CV/NLP モデルなど、Canvas でサポートされているすべての問題タイプに拡張されます。その結果、機械学習 (ML) モデルの本番環境へのデプロイが効率化されます。 詳細については、デベロッパーガイドを参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のニュース記事、オープンソースプロジェクト、Twitch ショーを紹介します。 Build On Generative AI — 生成 AI のすべてを網羅する人気の ウィークリー Twitch ショー のシーズン 3 が盛り上がりを見せています。 私の同僚の Tiffany と Darko が、毎週月曜日 9:00 US PT のストリーミングで生成 AI のさまざまな側面についてディスカッションし、ゲストスピーカーのデモを紹介しています。 今日のエピソード では、ゲストの Martyn Kilbryde が、Amazon Bedrock を使用して JIRA エージェントを構築する方法を紹介しています。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 PyTorch 用の Amazon S3 コネクタ — PyTorch Lightning のユーザーは、 PyTorch 用 の Amazon S3 コネクタ を使用してモデルチェックポイントを Amazon S3 に直接保存できるようになりました。PyTorch 用の Amazon S3 コネクタを使用すると、Connector for than writing to Amazon Elastic Compute Cloud (Amazon EC2) インスタンスストレージに書き込むよりも 40% 速く PyTorch Lightning モデルチェックポイントを保存できます。PyTorch Lightning トレーニングジョブから Amazon S3 でチェックポイントを直接保存、読み込み、削除することも可能になりました。  GitHub のオープンソースプロジェクトをチェックしてください。 AWS のオープンソースに関するニュースと最新情報 — 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた Open Source Newsletter を毎週 執筆しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS at NVIDIA GTC 2024 — NVIDIA GTC 2024 開発者カンファレンスが今週 (3 月 18 日～21 日) にカリフォルニア州サンノゼで開催されます。お近くの方は、ブース #708 の AWS で生成 AI のデモを確認し、ブース内のシアターで生成 AI、ロボティクス、アドバンストコンピューティングの最新製品について、AWS、AWS パートナー、エキスパートのお客様からインスピレーションを得てください。  AWS セッションをチェックして、1 対 1 のミーティングをリクエストしてください。 AWS Summit — AWS Summit シーズンの到来です! 最初の開催地である パリ (4 月 3 日) を皮切りに、 アムステルダム (4 月 9 日)、 シドニー (4 月 10 日～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15 日～16 日)、そして ソウル (5 月 16 日～17 日) での開催が予定されています。AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。 AWS re:Inforce — ペンシルバニア州フィラデルフィアで開始される AWS re:Inforce (6 月 10 日～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 今週はここまでです。3月25日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

3月14日は AWS Pi Day です ! 太平洋標準時の午後 1 時から始まる Twitch のライブ配信にご参加ください 。 18 年前のこの日、西海岸のある小売企業が オブジェクトストレージサービスを開始し 、 Amazon Simple Storage Service (Amazon S3) を世界に発表しました。世界中の企業のデータ管理方法が変わるとは思いもしませんでした。2024 年に進むと、 現代のビジネスはすべてデータビジネスです 。私たちは、 データがどのようにしてデジタルトランスフォーメーションを推進するのに役立つか 、そして 生成人工知能 (AI) がどのようにしてビジネスに予想外の有益な新しい機会をもたらすのかについて、数え切れないほどの時間を費やしてきました。私たちの対話は進化し、差別化された生成 AI アプリケーションの作成において、独自のデータがどのような役割を果たすかについての議論を取り入れるようになりました。 Amazon S3 は、実質的にどんなユースケースにも対応できる 350 兆以上のオブジェクトとエクサバイト規模のデータを保存し、1 秒あたり平均 1 億回以上のリクエストを処理していることから、皆様の生成 AI の旅の出発点になる可能性があります。しかし、最も重要なのはデータの量や保存場所ではなく、その品質です。質が高いデータでモデル応答の精度と信頼性を向上させることができます。 最高データ責任者 (CDO) を対象とした最近の調査では 、CDO のほぼ半数 (46%) が、生成 AI の実施における最大の課題の 1 つがデータ品質だと考えています。 今年の AWS Pi Day では、Amazon S3 の誕生日にあたり、データレイクから高性能ストレージまで、 AWS Storage がどのようにデータ戦略を変革し、生成 AI プロジェクトの出発点となるかを観察していきます。 このライブオンラインイベントは、 AWS Innovate: Generative AI + Data edition の終了直後の本日 (2024 年 3 月 14 日) 午後 1 時 (太平洋標準時) に始まります。 Twitch の AWS OnAir チャンネル でライブ配信され、AWS の専門家による 4 時間の新しい教育コンテンツが取り上げられます。データと既存のデータアーキテクチャを使用してカスタマイズされた生成 AI アプリケーションを構築および監査する方法を学ぶだけでなく、最新の AWS ストレージイノベーションについても学ぶことができます。通常通り、このショーでは実践的なデモは満載、皆様がこれらのテクノロジーを直ちに使い始める方法を実際に見ることができます。 生成 AI のデータ 消費者活動、ビジネス分析、IoT センサー、コールセンターの記録、地理空間データ、メディアコンテンツ、またその他の要因によるデータは驚異的な速度で増加しています。このようなデータの増加は、生成 AI のすさまじい成長の原動力です。基盤モデル (FM) は、インターネットからのペタバイト規模のウェブページデータを含むオープンリポジトリである Common Crawl などのソースから提供される大量のデータセットに基づいてトレーニングされます。FM からの応答をさらにカスタマイズするために、組織はより小規模なプライベートデータセットを使用しています。これらのカスタマイズされたモデルは、次に、更に多くの生成 AI アプリケーションを促進し、お客様とのインタラクションを通じて、データフライホイールのためにさらに多くのデータを生成します。 業界、ユースケース、地域に関係なく、今すぐ始められるデータイニシアティブは 3 つあります。 まず、 既存のデータを使用して AI システムを差別化します 。ほとんどの組織の基盤は大量のデータです。このデータを使用して、特定のニーズに合わせて基盤モデルをカスタマイズおよびパーソナライズできます。パーソナライゼーション技術には、構造化されたデータが必要なものもあれば、そうでないものもあります。その他には、ラベル付きのデータまたは未加工データが必要なものもあります。 Amazon Bedrock と Amazon SageMaker には、さまざまな既存の基盤モデルを微調整または事前トレーニングするための複数の解決策が用意されています。また、お客様や協力者のために ビジネスのエキスパートである Amazon Q をデプロイし、 すぐに使用可能な 43 のサポートされるデータソース 内の 1 つ以上を標的として指定することも可能です。 しかし、AI 利用の拡大に役立つ新しいデータインフラストラクチャの構築は望んでいないでしょう。生成 AI は、既存のアプリケーションと同じように組織のデータを消費します。 その次に、 既存のデータアーキテクチャとデータパイプラインを生成 AI と連携させ 、データアクセス、コンプライアンス、およびガバナンスに関する既存のルールを引き続き遵守することを望んでいます。当社のお客様は、AWS に 1,000,000 を超えるデータレイクをデプロイしていました。データレイク、Amazon S3、および既存のデータベースは、生成 AI アプリケーションを構築するための優れた出発点です。 検索拡張生成 (RAG) をサポートするために、複数のデータベースシステムでベクターストレージと検索へのサポートを追加しました。 Amazon OpenSearch Service は論理的な出発点かもしれません。ただし、 pgvector を PostgreSQL 用の Amazon Aurora 、および PostgreSQL 用の Amazon Relational Database Service (Amazon RDS) と一緒に使用することもできます。また最近、 Amazon MemoryDB for Redis 、 Amazon Neptune 、 Amazon DocumentDB (MongoDB 互換) 用の ベクターストレージと検索 を発表しました。 また、現在既に導入されているデータパイプラインを再利用または拡張することも可能です。皆様の多くは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 、 Amazon Managed Service for Apache Flink 、 Amazon Kinesis などの AWS ストリーミングテクノロジーを使用して、伝統的な機械学習 (ML) や AI でリアルタイムのデータ準備を行っています。これらのワークフローを拡張してデータの変更を捕捉して、ベクトルデータベースの更新によりほぼリアルタイムで大規模言語モデル (LLM) に変更を反映させたり、MSK のネイティブストリーミングインジェストを用いて Amazon OpenSearch Service にナレッジベースの変更を反映させたり、 Amazon Kinesis Data Firehose を通じて Amazon S3 の統合データストリームで微調整データセットを更新したりすることができます。 LLM のトレーニングにおいて、スピードが重要です。データパイプラインは、トレーニングクラスター内の多くのノードにデータをフィードできる必要があります。Amazon S3 にデータレイクを持つお客様は、パフォーマンス要件を満たすために、 Amazon S3 Express One Zone のようなオブジェクトストレージクラスや、 Amazon FSx for Lustre のようなファイルストレージサービスを利用しています。 FSx for Lustre は緊密な統合を実現し、使い慣れた高性能ファイルインターフェイスを利用することで、オブジェクトデータ処理の高速化を可能にします。 幸いなことに、データインフラストラクチャが AWS サービスで構築されている場合、生成 AI のデータを拡張する方向に既に大きな進歩を遂げました。 第 3 に、 自分自身の最高の監査人にならなければなりません。 すべてのデータ組織には、生成 AI のために定められた規制、コンプライアンス、コンテンツ管理に対して、事前に備える必要があります。トレーニングやカスタマイズにどのデータセットが使用されているか、また、モデルがどのように意思決定を行ったかを知っておく必要があります。生成 AI のような急速に変化している分野では、未来を予測する必要があります。AI システムをスケールする間、完全に自動化されている方法ですぐにそれを実行する必要があります。 データアーキテクチャでは、 AWS CloudTrail 、 Amazon DataZone 、 Amazon CloudWatch 、 OpenSearch など、さまざまな AWS サービスを監査に使用され、データ使用量が管理および監視されています。これは AI システムへ簡単に拡張できます。生成 AI に AWS Managed Services を使用している場合は、組み込まれたデータの透明性を高める機能を利用できます。CloudTrail サポート付きの生成 AI 機能を発表するのは、企業からのお客様には、AI システムの監査証跡を持つことがいかに重要であるかを理解しているからです。Amazon Q でデータソースを作成すると、そのデータソースは CloudTrail に記録されます。CloudTrail イベントを使用して、 Amazon CodeWhisperer によって作られた API コールをリストで表示することもできます。 Amazon Bedrock には 80 を超える CloudTrail イベントがあり、これらを使用してファンデーションモデルの使用方法を監査するのが可能です。 前回の AWS re:Invent カンファレンスでは 、 Amazon Bedrock 向けのガードレール についても紹介しました。これにより、避けるべきトピックを指定できます。また、 Bedrock は、制限されたカテゴリーに該当する質問に対し、承認済みの回答のみをユーザーに提供します リリースされたばかりの新機能 Pi Day は、AWS ストレージとデータサービスの革新を祝う機会でもあります。ここでは、今回発表された新機能の一部を紹介します。 PyTorch 用 Amazon S3 コネクタ は今、 PyTorch Lightning のモデルチェックポイントを Amazon S3 に直接保存することをサポートするようになりました。モデルチェックポイントは通常、トレーニングジョブを一時停止する必要があるため、チェックポイントの保存に必要な時間は、エンドツーエンドのモデルトレーニング時間を直接に影響します。PyTorch Lightning はオープンソースのフレームワークで、PyTorch で行われるトレーニングやチェックポイントの作成にレベルの高いインターフェースを提供します。 この新しい統合の詳細については、「最新情報」の投稿を参照してください 。 Amazon S3 on Outposts 認証キャッシュ – この新機能は、Amazon S3 のアイデンティティ認証および承認データをローカルの Outposts ラックに安全にキャッシュすることで、リクエストのたびに親 AWS リージョンへの往復する必要をなくして、ネットワークでの往復によって生じるレイテンシーの変動を減少します。 Amazon S3 on Outposts 認証キャッシュの詳細については、「最新情報」の投稿 、および AWS ストレージブログチャネルで発表されたこの新規投稿を参照してください 。 Mountpoint for Amazon S3 Container Storage Interface (CSI) ドライバー は Bottlerocket で使用できます。Bottlerocket は Linux に基づき、コンテナーのホストを目的とするオープンソースの無料オペレーティングシステムです。 Mountpoint for Amazon S3 に基づいて構築された CSI ドライバーは、 Amazon Elastic Kubernetes Service (Amazon EKS) と自己管理型 Kubernetes クラスター内のコンテナによって、S3 バケットをアクセス可能なボリュームとして表示します。これにより、アプリケーションがファイルシステムインターフェイスを介して S3 オブジェクトにアクセスできるため、アプリケーションコードを変更せずに高い集計スループットを実現します。 「最新情報」の投稿には、Bottlerocket 用の CSI ドライバーに関する詳細が記載されています 。 Amazon Elastic File System (Amazon EFS) は、ファイルシステムあたりのスループットを 2 倍向上させました。当社は Elastic Throughput の制限について 、読み取りオペレーションでは最大 20 GB/秒、書き込みでは最大 5 GB/秒までに引き上げました。つまり、機械学習、ゲノミクス、データ分析アプリケーションなど、スループットをさらに重視するワークロードに EFS を使用できるようになりました。 EFS でのスループットの向上についての詳細は、「最新情報」の投稿を参照してください 。 今月初めに実行した重要な変更は、他にもあります。 Amazon S3 Express One Zone ストレージ クラスと Amazon SageMaker の統合 – トレーニングデータ、チェックポイント、およびモデルアウトプットの読み込み時間を短縮することで、Amazon SageMaker モデルのトレーニングを加速できるようになります。 この新しい統合の詳細については、「新機能」の投稿を参照してください 。 Amazon FSx for NetApp ONTAP は、ファイルシステムあたりの最大スループットキャパシティを 2 倍 (36 GB/秒から 72 GB/秒まで) に増加し、ONTAP のデータ管理機能をさらに幅広いパフォーマンスを重視するワークロードに使用できるようになりました。 Amazon FSx for NetApp ONTAP の詳細については、「最新情報」の投稿を参照してください 。 ライブ配信中に期待できること 本日において開催された 4 時間のライブショーでは、これらの新機能のいくつかについて説明する予定です。私の同僚の Darko さんが、AWS の専門家を多数招いて実践的なデモンストレーションを行います。皆様が生成 AI プロジェクトでデータを活用する方法を探すのに手伝いをします。こちらは当日のスケジュールです。すべての時間は太平洋標準時 (PT) タイムゾーン (GMT-8) で表記されます。 既存のデータアーキテクチャを生成 AI までに拡張 (午後 1 時～午後 2 時)。 AWS のデータレイク上で分析を行っているなら、生成 AI のためのデータ戦略に向けて、既に大きく前進していると言えます。 生成 AI のコンピューティングへのデータパスを加速 (午後 2 時～午後 3 時)。 モデルトレーニングと推論のコンピューティングデータパスには、速度が大事です。それを実現するさまざまな方法をご覧ください。 RAG と微調整でカスタマイズ (午後 3 時～午後 4 時)。 基本的な基盤モデルをカスタマイズする最新の技術をご覧ください。 GenAI の最高のオーディターになりましょう (午後 4 時～午後 5 時)。 コンプライアンスの目標を達成するために、既存の AWS サービスを活用しましょう。 AWS Pi Day ライブストリーム に今すぐご参加ください。 お会いできるのを願っています! — seb 原文は こちら です。

このブログ記事は、AWS エンタープライズサポート担当テクニカルアカウントマネージャーの Tanya Pahuja と Sumit Bhardwaj 、および AWS シニアソリューションアーキテクトの Karan Desai によって書かれました。 消費者向けのウェブサイトやモバイルアプリでは、ユーザーの画面にコンテンツが読み込まれるスピードが、ユーザーのブラウジング体験やビジネスの成功に直接影響します。コンテンツの読み込みに時間がかかると、ユーザーはトランザクションを完了する前にページを放棄する可能性があり、収益に影響します。 Amazon CloudFront のようなコンテンツ配信ネットワーク（CDN）を利用すれば、データ、動画、アプリケーション、API を低遅延かつ高速で世界中のユーザーに安全に配信し、ウェブサイトのパフォーマンスを向上させることができます。HTML 、画像、スタイルシート、JavaScript ファイルなどのウェブサイトの静的コンテンツは、CloudFront の エッジロケーション やリージョン別エッジキャッシュにキャッシュされたコピーから提供できます。新しく更新されたコンテンツや API コールなど、キャッシュできない動的コンテンツは、CloudFront によってオリジンサーバーからフェッチされ、 AWS グローバルネットワーク を使用して高速かつ最適化された経路で配信されます。 パフォーマンスを向上させるには、CloudFront ディストリビューションを設定することで、ウェブサイトのトラフィックが CloudFront のグローバルに分散されたエッジネットワーク経由で配信されるように設定するだけです。CloudFront を使用してコンテンツを配信するように設定したら、ウェブサイトのパフォーマンスを監視して、得られるメリットを理解し、パフォーマンスをさらに最適化するために設定を変更する必要があるかどうかを確認する必要があります。この投稿では、 Amazon CloudWatch Real User Monitoring (RUM) を使用してウェブサイトのパフォーマンスを監視し、CloudFront を使用してコンテンツを配信した場合と使用しない場合のユーザーエクスペリエンスの違いに関する洞察を得る方法を紹介します。 CloudFront に対する模擬モニタリングとリアルユーザーモニタリング（RUM） 通常、ウェブサイトのパフォーマンスを測定するために、2 つの異なるタイプのモニタリングを使用することができます。 模擬モニタリング： ユーザーのウェブサイトへのジャーニーとインタラクションのシミュレーションを使用して、ウェブサイトのパフォーマンスを監視する方法です。これは、地域、ネットワーク、デバイス、およびブラウザなどの変数が事前に決定され、変更されない制御された環境で行われます。外部変数を制御することは、バックエンドのインフラおよびアプリケーション側にパフォーマンスのボトルネックが存在する場所を理解し、パフォーマンスの問題の原因を特定するのに役立ちます。しかし、これは必ずしもユーザーが実世界で経験することを表すものではありません。 リアルユーザーモニタリング： パッシブ・モニタリングの一種で、実際のユーザーとウェブサイトとのやり取りを分析するものです。通常、アプリケーション内にコードの一部を挿入することで、ユーザーのブラウジング体験に影響を与えることなく、クライアントやブラウザからのフィードバックを収集します。これにより、顧客がウェブサイトとどのようにやり取りしているか、また、特定のデバイス、ブラウザ、およびネットワーク上でのウェブサイトのパフォーマンスに関する顧客の経験について洞察することができます。 アーキテクチャー概要 まず、 Application Load Balancer（ALB） の背後にある Amazon Elastic Compute Cloud（Amazon EC2） インスタンス上にウェブアプリケーションをデプロイすることから始めます。既存のウェブアプリケーションを使用するか、この チュートリアル に従ってサンプルの 3 層ウェブアプリケーションをデプロイすることができます。公開 ALB エンドポイント URL を使って、ブラウザからこのウェブサイトにアクセスします。これは CloudFront を実装する前のユーザーのベースライン体験を表しています。 十分なデータが得られたら、このディストリビューションの「オリジン」として先ほど使用したのと同じ ALB を指す CloudFront ディストリビューション を構成します。CloudFront は各ディストリビューションに一意のドメイン名を提供します。それでは、ブラウザからウェブサイトにアクセスしますが、今回は CloudFront の URL を使用します。これは CloudFront が実装された後のユーザーエクスペリエンスを表しています。2 つのテストから取得したデータを比較することで、コンテンツ配信のために CloudFront を使用することでユーザーが得られるパフォーマンスの向上を理解することができます。次の図はテストのアーキテクチャーを示しています。 図 1：ソリューションのアーキテクチャー図 CloudFront に対する CloudWatch モニタリング RUM の利用に入る前に、CloudWatch と直接統合されている CloudFront の運用メトリクスを調べることができます。これらのメトリクスは CloudWatch コンソール で利用でき、追加コスト無しで利用できます。以下のスクリーンショットにあるように、CloudFront ディストリビューションによって提供された HTTP リクエストの数、ユーザーによってダウンロードおよびアップロードされたバイト数、4XX および 5XX エラーの数を監視することができます。また、CloudFront ディストリビューションのキャッシュヒット率や、キャッシュされていないコンテンツを提供する際のオリジンレイテンシなど、追加コストで追加のメトリクスをオンにすることもできます。 図 2：CloudWatch 上の CloudFront モニタリングメトリクス このデータは、ウェブサイトの健全性を判断したり、ウェブサイトへのユーザートラフィックの概要を把握したりするのに役立ちます。しかし、ウェブサイトのパフォーマンスに関するユーザー・エクスペリエンスについての洞察は得られません。そこで RUM を活用します。 RUM を使ってウェブサイトのパフォーマンスを検証する 次に、同じウェブアプリケーションの RUM を使って計測しましょう。このためには、まず CloudWatch RUM でアプリケーションモニター を作成し、それによって生成された コードスニペット を、パフォーマンスをモニターしたいウェブサイトの HTML ページに挿入する必要があります。※CloudWatch RUM のアプリケーションモニターはドメイン毎に作成します。CloudFront 独自のドメインを使用して比較を行う場合は、CloudFront を使用する場合と使用しない場合でドメインが異なることがあります。その場合は検証を行う毎にコードスニペットをドメイン毎に入れ替えて検証してください。 1) CloudFront を使用しない場合の RUM CloudWatch RUM ウェブクライアントを埋め込みスクリプトとしてインストールするには、RUM ウェブクライアント設定コードスニペットをアプリケーションの <head> 要素内、他の <script> タグの上に貼り付ける必要があることに注意してください。 図 3：HTML ページに挿入された CloudWatch RUM スクリプトの例 パフォーマンスタブには、ページのロード時間やユーザーが遭遇したエラーなど、ウェブページのバイタルサインが表示されます。バイタルサインは 3 つのレベル ([Positive] (良好)、[Tolerable] (許容範囲)、[Frustrating] (不良)) に分けられます。 図 4：ページのロード時間を示す CloudWatch Performance タブ また、ユーザーのブラウザ上でウェブページを完全にロードするために必要な各ステップにかかる時間も確認できます。これには、初期接続の確立にかかる時間、SSL ハンドシェイク、コンテンツの最初のバイトをロードする時間、完全なロード時間などが含まれます。 図 5：ウェブページの読み込みにかかる各ステップの時間の内訳の例 この図の例では、この特定のユーザーがウェブページをロードするのにかかる平均時間は 764ms で、最初の接続に 278ms、最初のバイトに 280ms かかっていることがわかります。これをベースラインとして、CloudFront を使って同じウェブページを配信したときのパフォーマンスを比較することができます。 2) CloudFront を使用する場合の RUM AWS コンソールで先ほど作成した CloudFront ディストリビューションにアクセスし、CloudFront ドメインの URL を取得することができます。そして、ブラウザでこの URL を使ってウェブサイトにアクセスすることができます。これで再びCloudWatch RUM に新しいデータポイントが送信され、CloudFront を使用してコンテンツが配信されたときのユーザーエクスペリエンスが表示されます。パフォーマンスメトリクスを再び見てみましょう。 図 6: CloudFront を使用した場合のページのロード時間を示す CloudWatch Performance タブ 図 7：CloudFrontを使用したウェブページのロードにかかる各ステップの時間の内訳 先の例では、同じユーザーがウェブページをロードするのにかかった時間の合計が 447ms になったことがわかります。最初の接続には 17.5ms しかかかっていません。ALB の前に CloudFront をデプロイすることで、ページのロード時間がほぼ 40% 短縮され、ユーザーエクスペリエンスが向上していることがわかります。 CloudWatch RUM は、CloudFront を使用して配信されるウェブサイトについて、いくつかの追加の洞察を提供します。以下のスクリーンショットに見られるように、異なる地域のユーザーに対するウェブサイトのパフォーマンスを確認し、どのユーザーが良いエクスペリエンスを得ているか、またはページのロード時間が長いためにフラストレーションのたまるエクスペリエンスを得ているかを比較することができます。 図 8：CloudWatch RUM が提供する、ユーザーの地理的位置によるページロードパフォーマンスの例 また、以下のスクリーンショットのように、異なるブラウザやデバイスタイプを使用してウェブサイトにアクセスしたユーザーの閲覧体験の詳細を取得することもできます。 図 9：CloudWatch RUMが提供する、ユーザーのブラウザ別のページロードパフォーマンスの例 さらに、以下のスクリーンショットに見られるように、RUM が監視しているすべてのイベントのオリジナルログエントリや、ウェブサイトをナビゲートするユーザージャーニーにアクセスすることができます。 図 10 : クラウドウォッチ RUM の raw イベントログの例 また、以下のスクリーンショットのように、ランディングページからウェブサイト、その後のインタラクションまでのユーザージャーニー全体を追跡することもできます。 図 11 : CloudWatch RUM を使用してトラッキングされたユーザージャーニーの例 まとめ この投稿では、RUM を使用してエンドユーザーのウェブサイトのパフォーマンスに関する洞察を得る方法と、CloudFront を活用することで得られる改善を監視する方法について学びました。このデータが得られれば、アプリケーションのどの部分をさらに最適化すればユーザーエクスペリエンスが向上するかを特定でき、 CloudFront が提供する様々な機能 を設定することでウェブサイトのパフォーマンスをさらに向上させることができます。 本記事は、「 Prepare and run performance tests for Amazon Cloudfront with Real User Monitoring 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

IBM Db2は、ミッションクリティカルなシステムで信頼されているデータベースとして知られています。最近では、そのポテンシャルをクラウドでさらに活かそうとする企業が増えています。そこで、クラウドでのDb2活用方法とオンプレミスからのスムーズな移行戦略を解説する特別オンラインセミナーを企画いたしました。 本セミナーは、AWSをこれから始める方を対象に、初歩から専門知識まで段階的に解説します。 最初のセッションでは、AWSの概要、そしてAWSがどのようにしてリレーショナルデータベースの運用課題（パフォーマンス、運用効率、コスト効率、可用性、災害復旧）を解決できるかをご紹介します。 続いて、AWSのマネージドデータベースサービスであるAmazon RDS for Db2に焦点を当て、オンプレミス環境からクラウドへの移行がもたらす変化とそのメリットを、具体的かつ詳細に解説します。さらに、AWSへの移行プロセスを、実践的なステップに分けてご説明し、参加者の皆様が直面するかもしれない疑問や課題に対する答えを提供します。 AWSの基礎からAmazon RDS for Db2の活用法、効率的な移行プロセスまでを網羅し、参加者の皆様が直面する疑問や不安を解消する内容を2時間のセミナーにコンパクトにまとめました。 Db2のクラウド活用を始めるための貴重な洞察を得る絶好の機会です。ぜひお申し込みください！ 4月11日(木) オンラインセミナー 「IBM Db2 の試算を AWS で活用する」アジェンダ 時間 セッション 10:00 – 10:35 リレーショナルデータベースの課題と AWS による解決 Amazon RDS for Db2 の紹介を行う前に、AWS の特徴及び AWS が性能や運用、コスト最適化、および可用性と DR などリレーショナルデータベースにつきまとう課題をどのように解決できるか説明します。IBM Db2 に関する知識があっても AWS に関して知識が足りない、という方には欠かせないこの後のセッションを理解する上での AWS の前提知識について短時間で学ぶことができます。 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 野間 愛一郎 10:35 – 11:15 Amazon RDS for Db2 紹介 AWS が提供するマネージド型のデータベースサービスである Amazon RDS for Db2 に関して Amazon RDS の基本から説明します。RDSの概要や特徴といった基本から説明しますので、Amazon RDS についての知識がなくとも Amazon RDS for Db2 のメリットや特徴を短時間で学ぶことができます。加えて、オンプレミスの IBM Db2 との違いについても説明します。 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 下佐粉 昭 11:15 – 12:00 AWS へのマイグレーション方法と支援サービス AWS ではお客様が移行先のデータベースを選択するために Database Freedom Workshop を提供しています。お客様環境の Db2 のアセスメントを含むこのプログラムでは、アセスメント結果を基に適切な移行先を決定する上でのガイドを提供します。今回のセッションでは、この Database Freedom Workshop の紹介のみならず、パートナー各社の移行支援サービスや、実際に移行を行ったお客様の事例紹介を通じて、現在利用している Db2 の今後に関して誰に相談すればいいのか、AWS からどのような支援が提供されるのか、どのようなステップで検討を進めればよいのかを学ぶことができます。 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 矢木 覚 ※当日の進行により、時間割が若干変更となる場合がございます。 参加費：無料 参加登録： こちらのページよりお申し込みください スピーカー紹介 スピーカーはオンプレミスのDb2利用経験のあるAWSメンバーが担当します。 野間 愛一郎 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 主に製造業のお客様を担当するソリューションアーキテクトとして活動。お客様の多種多様な要件に合わせてAWS上にソリューションを構成するため幅広く技術支援を行っている。前職ではIBM Db2の製品担当として大規模データベースやミッションクリティカルシステムを支援、データベースコミュニティの立ち上げなどにも貢献した。 下佐粉 昭 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 前職では、IBM Db2のプリセールスエンジニアとして活動。著書に「即戦力のDB2管理術」。 現職ではソリューションアーキテクトとしてRDS for Db2の技術支援をお客様・パートナーに提供している。 矢木 覚 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 前職では、Oracle Databaseのプリセールスエンジニアとして活動。商用データベースに関する多数のwebコンテンツを作成。現職ではソリューションアーキテクトとしてRDS for Oracle, RDS for Db2を担当。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

AWS Config は、AWS アカウント内または AWS Organizations 全体の AWS リソースの設定変更を追跡するサービスです。AWS Config は設定レコーダーを使用してリソースの変更を検出し、それらを設定項目 (CI) として追跡します。クラウドインフラストラクチャの複雑さが増すにつれ、CI の数は指数関数的に増加しています。ワークロードは、短い間隔でリソースを作成、更新、削除することが必要であり、従来の静的なものではなく動的なものになりつつあります。過去には、設定レコーダーは継続的な記録のみをサポートしており、本番環境でない場合でも、追跡対象のリソースへの変更が発生したタイミングでそれをすべてキャプチャしていました。 この度、AWS Config の定期的な記録機能の提供を発表できることを大変嬉しく思います。この新機能により、設定レコーダーの記録頻度を日次に設定することが可能になりました。これまでの継続的な記録や設定項目の更新に代わり、過去 24 時間で変更があった場合に、リソースの最新の状態を表す設定項目が記録されるようになります。24 時間の周期内で、そのリソースタイプの定期的な記録が有効になっているリソースを作成および削除した場合は、設定項目は生成されません。定期的な記録を使用することで、すべてのリソースタイプのデフォルトの記録頻度を日次にしつつ、特定のリソースタイプをカスタマイズする設定が可能です。または、リソースタイプごとに設定することもできます。これにより、コンプライアンスやセキュリティ上の重要なリソースタイプの場合は従来の継続的な記録を使用して連続的に追跡し、本番以外のアカウント内の Amazon EC2 インスタンスなどは日次で定期的に追跡するように指定することが可能です。 定期的な記録のメリットには以下が含まれます: コスト効率 : 日次での記録により構成変更の記録頻度が下がることで、関連コストを削減できます。定期的な記録は継続的な記録とは異なる課金体系であることに注意が必要です。詳細は AWS Config の料金ページ をご確認ください。 混乱の最小化 : 定期的な記録による日次での記録は、過去 24 時間で変更があった際に設定項目が記録されるため、通知の頻度を下げてアラート疲れの回避に適した情報フローを提供します。 リソースタイプに対して定期的な記録または継続的な記録を使用するかどうかの決定にあたっては、セキュリティとコンプライアンスの要件を考慮することが重要です。リソースタイプのリアルタイムモニタリングや詳細な分析が必要な場合は、継続的な記録を使用することをおすすめします。詳細は 記録頻度 のページをご覧ください。 この投稿では、AWS Config の定期的な記録を開始する方法を紹介します。既存の設定レコーダーを AWS コンソールで更新して、継続的な記録ではなく定期的な記録を利用するようにします。さらに、AWS コンソールでカスタマイズ可能なオーバーライドを使用した定期的な記録のデモも行います。次に、 AWS CLI を使用して、定期的な記録用に設定レコーダーを設定する例を紹介します。AWS Config を初めて設定する場合は、 ワンクリックセットアップ から開始してください。 AWS Config での定期的な記録の設定 既存の AWS Config ユーザーが、特定のリソースタイプで定期的な記録を利用するように設定レコーダーの設定を更新したいシナリオについて説明します。デフォルトでは、記録範囲内のすべてのリソースタイプは、定期的な記録を明示的に選択しない限り、継続的な記録が採用されます。 設定レコーダーの記録方法における記録戦略には次の 2 つのオプションがあります: カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ : AWS Config はオーバーライドの設定で 記録から除外 に指定したリソースタイプを除く、すべての現在および将来のサポートされているリソースタイプの設定変更を記録します。AWS Config の設定レコーダーを初めて設定する場合、これがデフォルトのオプションです。 特定のリソースタイプ : AWS Config は、指定したリソースタイプの設定変更のみを記録します。リソースタイプの記録を停止することを選択した場合でも、すでに記録されている設定項目は変更されません。 既存の設定レコーダーを定期的な記録に変更するには、次の手順を参照してください。 AWS Config コンソール に移動します。 ナビゲーションペインで、 設定 を選択します。 編集 を選択します。現在の記録戦略に応じて、ステップ 4 の「カスタマイズ可能なオーバーライドのあるすべてのリソースタイプの場合」またはステップ 5 の「特定のリソースタイプの場合」に進んでください。 記録戦略として カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ が設定されている場合は以下のとおりです。 すべての現在および将来のリソースのデフォルトの記録頻度として、 継続的な記録 または 日次記録 を選択できます。デフォルトの記録頻度は継続的な記録に設定されています。 特定の リソースタイプ の記録頻度を変更したり、特定のリソースタイプを 記録から除外 に指定するために、任意のオーバーライドを追加できます。 注意 : グローバルリソースタイプの IAM リソースタイプを除外するには、このバンドルタイプをリストから選択し、記録から除外することを選択してください。バンドルの詳細については、AWS Config 記録方法の 設定 を参照してください。 図 1 AWS Config 記録方法 – カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ 現在、 特定のリソースタイプ が記録戦略として設定されている場合は以下のとおりです。 ドロップダウンを使用して、記録するリソースタイプを追加または削除できます。 頻度では、リソースタイプごとに 連続 または 日次 を選択できます。 図 2 AWS Config 記録方法 – 特定のリソースタイプ 記録戦略を更新したら、 保存 を選択してください。 設定 の下部で、更新された設定レコーダーの設定を確認できます。 図 3 AWS Config 設定 AWS CLI を使用した既存の設定レコーダーの更新 このセクションでは、 AWS CLI を使用した定期的な記録の設定 の例をいくつか示します。 前提条件 AWS CLI を使用して既存の設定レコーダーを更新するには、既存の設定レコーダーの roleARN と name の情報が必要です。 describe-configuration-recorders コマンドを使用して、現在の設定レコーダーの name と roleARN を調べることができます。 $ aws configservice describe-configuration-recorders { "ConfigurationRecorders": [ { "roleARN": "arn:aws:iam::123456789012:role/config-role", "name": "default" } ] } すべてのリソースタイプへの定期的な記録の適用 put-configuration-recorder コマンドを使用して、設定レコーダーに設定を行うことができます。この例では、更新対象のレコーダーを識別するために、前提条件のステップでメモした設定レコーダーの name と roleARN を指定しています。 recording-group をすべてのサポートされているリソースに設定し、すべてのグローバルリソースタイプを true に設定しています。最後に、 recording-mode において記録頻度として recordingFrequency を DAILY に設定しています。 すべてのリソースタイプに定期的な記録を適用するには、ターミナルに以下のコマンドを入力します。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true --recording-mode recordingFrequency=DAILY カスタマイズ可能なオーバーライドのあるすべてのリソースタイプを使用した定期的な記録の適用 すべてのリソースタイプに対して継続的な記録を行いたいが、カスタマイズ可能なオーバーライドを使用して特定のリソースタイプを定期的に記録したい場合は、 recording-mode オプションを使用する際に JSON ファイルを利用して設定することができます。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true -- recording-mode file://recordingMode.json 以下は recording-mode で指定している JSON ファイル file://recordingMode.json の例です。 { "RecordingFrequency": "CONTINUOUS", "RecordingModeOverrides": [ { "RecordingFrequency": "DAILY", "ResourceTypes": [ "AWS::EC2::Instance", "AWS::DynamoDB::Table" ] } ] } JSON の例では、 RecordingFrequency が CONTINUOUS に設定され、継続的な記録がすべてのリソースタイプに指定されていることがわかります。しかし、EC2 インスタンスと DynamoDB テーブルの 2 つに関してはオーバーライドが定義されていて、定期的な記録が指定されています。 RecordingModeOverrides を利用することで、どのリソースタイプを継続的な記録の対象外とするか指定することが可能です。 コマンドオプションの詳細については、 AWS CLI コマンドリファレンス を参照してください。 まとめ このブログ記事では、AWS Config の定期的な記録を使用して、日次でリソースの最新の構成変更をキャプチャする方法について学びました。これにより、AWS Config によって検出される変更の数を削減できます。次に、AWS マネジメントコンソールと AWS CLI を使用して定期的な記録を設定する方法を学びました。AWS Config の設定レコーダーの詳細については、 設定レコーダーの管理 を参照してください。 著者について Abraham Musa Abraham は AWS の Cloud Foundations チームの Cloud Operations Specialist Solutions Architect でニューヨークを拠点に働いています。彼は AWS Control Tower、AWS Organizations、AWS Service Catalog や AWS Config に詳しいです。Abraham は元軍人で旅行が好きです。 Megan Velez Rivera Megan は公共領域のお客様を支援している Solutions Architect です。12 年以上の米国政府との協働経験から、Megan はお客様に複雑なクラウドインフラストラクチャの設計、実装、支援を行っています。彼女はお客様のクラウドオペレーションとオブザーバビリティ向上にも熱心に取り組んでいます。 Chris Sordan Chris はニューヨークを拠点にする Solutions Architect です。彼はエンタープライズのお客様に対し、設計上のベストプラクティスを使用してお客様の AWS 利用促進を支援しています。彼は革新的なソリューションを通じてお客様の技術的な目標を達成することに喜びを感じています。彼はジャズやスポーツイベントに参加することが趣味です。 Craig Edwards Craig Edwards はボストンを拠点とする AWS の Cloud Foundations チームと働く Cloud Operations Specialist Solutions Architect です。彼は AWS Config、AWS CloudTrail、AWS Audit Manager や AWS Systems Manager に詳しいです。Craig は元軍人で、父で、自転車に乗ることが好きです。 原文は こちら です。翻訳は SA 桂井が行いました。

NFTにおける画像生成 NFT(Non-Fungible Token)市場では、プログラムによって自動生成されたデジタルアート作品が多数取引されています。これらの作品はジェネラティブアートと呼ばれ、アルゴリズムを用いて無数のバリエーションの作品を生成することができます。 代表的な手法として、CryptoKittiesのようにキャラクターのパーツ(体、目、耳、尾など)を予め用意し、それらをランダムに組み合わせることで新しいキャラクターを生成する方法があります。この方法ではアーティストがルールを決めた上で、そのルールに基づいてさまざまなバリエーションの新しい画像をプログラムで作り出すことができます。最近では、DALL・EやStable Diffusionなどの生成AIを活用し、テキストのプロンプトからNFT用の画像を自動生成する試みも増えています。 NFT(Non-Fungible Token)は1点モノのデジタルアートであることが多く、多数のNFTを作成する場合は素材となる多様な画像が必要です。しかしアーティストにとって多数の画像を手作業で作成することは大きな負担です。 そこで注目されているのが、生成AIを活用した自動画像生成です。 本記事では、生成AIを使ったNFT用の大量画像生成の方法を解説します。 生成AIが持つ創造性を活用することで、効率的かつ魅力的なバリエーション豊かなNFT用の画像生成が期待できます。 Amazon Bedrockを用いたNFT用の画像生成 NFT用の向けに大量の画像を効率よく生成する手法としてお勧めするのが、Amazon Web Services が提供する Amazon Bedrock の生成AIを使用する方法です。 Amazon Bedrockはクラウド上で動作する生成AIの基盤モデルで、大規模言語モデルや画像生成モデルをAPI通じて呼び出せます。基盤モデルに対してテキストのプロンプトを入力することで高品質な画像を生成してくれます。NFT用の場合、コンセプトなどのテキストを入力することで、作品の世界観を反映した多様なバリエーション画像を大量生成できます。 Amazon BedrockとStable Diffusionを使用して生成した画像 Amazon Bedrockを使ってNFT用の画像を生成するには、まずコンセプトとなる入力画像を用意します。作品のイメージを決め、その世界観や構成を示した代表的な画像です。 この入力画像をbase64形式にエンコードし、テキスト形式のプロンプトと合わせてAmazon Bedrockに入力することで、画像の持つ特徴を生成AIに伝えられます。その結果、入力画像の世界観や構図を保ちつつ、プロンプトで指定した要素を含んだ新しい画像を生成できます。 AWS Step Functions Distributed MapとAmazon Bedrockを使用した大量生成 AWS Step FunctionsのDistributed Mapを使うと、Amazon Bedrockによる画像生成を並列で実行できます。これにより大量のバリエーション画像を効率的に生成できます。ただし、Amazon Bedrockにクオータの制限があるため、並列実行数は低めに設定しましょう。 Distributed Mapは、CSVやJSON等で定義された入力データを並列のブランチに分割して処理し、結果をまとめる機能です。NFT用画像を生成する場合、入力値であるプロンプト定義をJSON形式で事前に用意しておきます。プロンプト定義はプログラムを用いて、例えば「髪型をショートカットにする」「髪色を金色にする」「背景色を金屏風にする」などさまざまな要素を事前に用意し、乱数に基づいて選択すると思いもよらない組み合わせができて面白いかもしれません。 このようにプロンプトとAWS Step FunctionsとAmazon Bedrockを組み合わせることで、大量のバリエーションに富んだNFT用の画像を効率よく生成できます。 AWS Step Functionsに渡す入力値の例です. 使用する生成AIのモデルや入力画像を保存しているAmazon Simple Storage Service(Amazon S3)の情報も一緒に渡します。 id や rank といった情報を生成AIのseed値に変換して用いることでバリエーションを増やすこともできます。 [ { "id":"A1", "rank":"nomal","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is brown, backglound color is white" }, { "id":"A2", "rank":"vip","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is gold, backglound color is red" }, ] 大量に生成する場合、再現性を確保するためにプロンプトの管理や保存が必要となります。また、並列実行数の制御やエラーハンドリングなど、細かな制御を実装する必要が出てきます。AWS Step Functionsの Distributed Map を使用することで、プロンプトや入力値等のパラメータの管理は事前に作成したJSONファイルに、並列実行数の制御やエラーハンドリングはAWS Step Functionsに任せることができるため、エンジニアが実装する箇所を減らすことができます。 サンプルコード aws-samplesの nft-image-generator でサンプルコードを公開しています。これを使用することにより、AWS Step FunctionsとAmazon Bedrockを組み合わせたNFT用画像生成の仕組みを体験することができます。 環境構築の方法や使用方法についてはGithubのドキュメントを参照してください。 実際に生成した画像 冒頭で作成した画像を入力画像として使用し、複数のバリエーションを生成しました。キャラクターのイメージやコンセプト、世界観などを維持しながら、髪色や髪型、メガネの色や形などが少しずつ異なる画像に仕上がったと思います。 Amazon Bedrockを使用して入力画像をベースに生成した画像 まとめ NFT用の画像生成には、生成AIを活用することで効率的に多様なバリエーションを作り出すことができます。 今回使用したアセットはaws-samplesのnft-image-generatorで公開しています。NFT用の画像生成についてチャレンジしたい方はご活用ください。 深津 颯騎 Amazon Web Service JapanのBlockchain Prototyping Engineer. Blockchain, Web3に関わるお客様を中心に技術支援を行っています。