AWS の技術ブログ
全2973件
Amazon OpenSearch Service は、2020 年に kNN プラグインが導入されて以来、レキシカル検索とベクトル検索の両方を長年にわたりサポートしてきました。2023 年初頭に AWS が Amazon Bedrock を立ち上げるなど、生成 AI の最近の進歩を受けて、OpenSearch Service のベクトルデータベース機能と Amazon Bedrock ホストモデルを組み合わせて使用できるようになりました。これにより、セマンティック検索、検索拡張生成 (RAG)、推薦エンジン、高品質なベクトル検索に基づくリッチメディア検索を実装できます。最近、 Amazon OpenSearch Serverless のベクトルエンジン がローンチしたことで、このようなソリューションをさらに簡単にデプロイできるようになりました。 OpenSearch Service は、さまざまな検索と関連性ランキングの技術をサポートしています。レキシカル検索は、クエリに現れる単語をドキュメント内で探します。セマンティック検索はベクトル埋め込みによってサポートされ、ドキュメントとクエリをセマンティックな高次元のベクトル空間に埋め込みます。意味的に関連するテキストはベクトル空間内で近くに配置されることから、意味的に類似していると判断できます。その結果、クエリと同一の単語がなくても、類似するアイテムを返すことができます 公開されている OpenSearch Playground 上に、異なる手法の長所と短所を示す2つのデモを用意しました。1つはテキストベクトル検索とレキシカル検索を比較したもので、もう1つはテキストと画像のクロスモーダル検索とテキストベクトル検索を比較したものです。OpenSearch の Compare Search Results ツール を使用すると、異なるアプローチを比較できます。このデモでは、Amazon Bedrock でホストされている Amazon Titan ファンデーションモデルを埋め込みのために使用していますが、ファインチューニングは行っていません。データセットは、Amazon の衣料品、宝石、アウトドア製品の一部から構成されています。 背景 検索エンジンは、特殊な種類のデータベースです。ドキュメントやデータを保存し、その中から最も関連性の高いものを検索するクエリを実行できます。エンドユーザーの検索クエリは通常、検索ボックスに入力されたテキストで構成されます。そのテキストを利用する上で重要な 2 つの技術が、レキシカル検索とセマンティック検索です。レキシカル検索では、検索エンジンが検索クエリの単語とドキュメントの単語を比較・照合します。ユーザーが入力したすべての単語、またはほとんどの単語を含むアイテムのみが、クエリと一致します。セマンティック検索では、検索エンジンが機械学習(ML)モデルを使用して、ソースドキュメントのテキストを高次元のベクトル空間内の密なベクトルとしてエンコードします。これは「テキストをベクトル空間に埋め込む」とも呼ばれます。同様にクエリをベクトルとして符号化し、距離メトリックを使用して多次元空間内の近傍ベクトルを見つけます。近傍ベクトルを見つけるアルゴリズムは、kNN (k 最近傍)と呼ばれます。セマンティック検索では、クエリ内の個々の単語との一致による検索ではなく、クエリの埋め込みベクトルに近いベクトル空間内におけるベクトルの検索を行います。つまり、クエリと意味的に似ているドキュメントが検索されます。したがって、ユーザーはクエリに含まれている単語を一切含まないアイテムについても、関連性が高いものであれば検索することができます。 ベクトル検索 ベクトル検索 のデモは、ベクトル埋め込みがクエリを構成する単語だけでなく、クエリのコンテキストをどのように捉えることができるかを示しています。 上部のテキストボックスに、 tennis clothes とクエリを入力します。左側 (クエリ1) には、 amazon_products_text_embedding インデックスを使用した OpenSearch DSL (クエリのドメイン固有言語)のセマンティッククエリがあり、右側(クエリ2)には、 amazon_products_text インデックスを使用したシンプルなレキシカルクエリがあります。レキシカル検索は、服がトップス、ショーツ、ドレスなどであることを知らない一方で、セマンティック検索はそれを知っていることがわかります。 Compare semantic and lexical results 同様に、 warm-weather hat で検索した場合、セマンティックな結果は温かい季節に適したたくさんの帽子を見つけますが、レキシカル検索は、「温かい」と「帽子」という単語を含む結果を返します。これらは全て、温かい季節の帽子には適さず、寒い季節の帽子です。同様に、長袖の長いドレスを探している場合、 long long-sleeved dress で検索するかもしれません。レキシカル検索は、長袖の短いドレスや、説明に「ドレス」という単語が現れる子供のドレスシャツを見つけてしまいますが、セマンティック検索は、少数のエラーはあるものの、ほとんどの長袖の長いドレスを見つけるなど、関連性の高い結果を返しています。 クロスモーダル画像検索 テキストと画像のクロスモーダル検索 のデモは、テキストの説明を使って画像を検索する方法を示しています。これは、事前に生成したマルチモーダルな埋め込みを利用して、テキストの説明と関連する画像を見つけることで実現しています。視覚的類似性(左側)と テキストの類似性(右側)で検索を比較します。場合によっては、非常に似た結果が得られます。 Compare image and textual embeddings マルチモーダルモデルについて詳しく知りたい方は、AWS スペシャリストにお問い合わせください。 セマンティックサーチによる本番品質の検索体験の構築 これらのデモは、ベクトルベースのセマンティック検索と単語ベースのレキシカル検索の特性の違いと、OpenSearch Serverless のベクトルエンジンを利用して検索エクスペリエンスを構築することでどのようなことができるかを示しています。 もちろん、実際の検索エクスペリエンスでは、結果を改善するためにより多くのテクニックが使用されます。 特に、 OpenSearch Project における検証 では、レキシカル検索やベクトル検索だけの場合と比較して、業界標準のテストセットで測定した検索結果の品質が、レキシカルとベクトルのアプローチを組み合わせたハイブリッド検索を用いることで通常 15% 改善されることが示されています。これは、 NDCG@10 メトリック(上位 10 件の結果における正規化減損累積利得)で測定されます。 改善されるのは、レキシカル検索のほうが固有名詞の検索に対してベクトル検索よりも優れており、セマンティック検索のほうが幅広いクエリに対してより適しているためです。 たとえば、 セマンティック検索とレキシカル検索の比較 で、カヌーのブランド名である saranac 146 というクエリは、レキシカル検索では非常にうまく機能しますが、セマンティック検索では関連する結果が返されません。 これは、セマンティック検索とレキシカル検索の組み合わせが優れた結果をもたらす理由を示しています。 まとめ OpenSearch Serviceには、セマンティック検索と従来のレキシカル検索の両方をサポートするベクトルエンジンが含まれています。 デモページで示されている例は、さまざまな手法の長所と短所を示しています。 OpenSearch 2.9以 降を使用している場合、独自のデータにSearch Comparison Toolを使用できます。 詳細情報 OpenSearch のセマンティック検索機能の詳細については、以下を参照してください。 Amazon OpenSearch Service のベクトルデータベース機能の説明 Building a semantic search engine in OpenSearch The ABCs of semantic search in OpenSearch: Architectures, benchmarks, and combination strategies Using OpenSearch as a Vector Database Partner Highlight: Using OpenSearch to set up a hybrid system that uses text and vector search Documentation for Neural Search 著者について Stavros Macrakis は、Amazon Web Services の OpenSearch プロジェクトのシニアテクニカルプロダクトマネージャーです。検索結果の品質を向上させるツールを顧客に提供することに情熱を注いでいます。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文は こちら です。
Amazon Bedrock は、大規模言語モデル (LLM) やその他の基盤モデル (FMs) を使用した、生成 AI アプリケーションの構築およびスケーリングに最適なサービスです。お客様は Anthropic Claude のモデルなど、様々な高性能 FMs を活用して独自の生成 AI アプリケーションを構築できます。Anthropic が AWS 上での構築を初めて開始した 2021 年を振り返ると、Claude がこれほどの変革をもたらすことを誰も想像できませんでした。私たちは Amazon Bedrock を通じて、最先端の生成 AI モデルをあらゆる企業が利用できるように整えてきました。2023 年 9 月 28 日に Amazon Bedrock が一般公開され、わずか数か月で 1 万人以上のお客様が使用しており、その多くが Claude を選択しています。 ADP、Broadridge、Cloudera、Dana-Farber Cancer Institute、Genesys、Genomics England、GoDaddy、Intuit、M1 Finance、Perplexity AI、Proto Hologram、Rocket Companies など のお客様は、Amazon Bedrock で Anthropic Claude を使って、生成 AI におけるイノベーションと顧客体験の変革を行っています。そして本日 (3/4)、Amazon Bedrock に次世代の Claude (Claude 3 Opus, Claude 3 Sonnet, Claude 3 Haiku) をリリースするマイルストーンを発表します。 Anthropic の Claude 3 をご紹介 Anthropic は、それぞれ異なる用途に最適化された Claude の次世代モデルを 3 つ発表しました。Haiku は市場で最速かつ最もコスト効率の高いモデルで、即座に反応する高速でコンパクトな設計が特徴です。Sonnet は、ほとんどのワークロードで Claude 2 や Claude 2.1 よりもレスポンスが 2 倍速く、より高い知能を備えています。ナレッジ検索や営業の自動化など、迅速な応答を必要とするインテリジェンスなタスクを得意としており、スピードとインテリジェンスの理想的なバランスを実現しています。この性能は企業のユースケースにとって特に重要です。Opus は最も高度であり、多彩な基盤モデルです。深い推論力、高度な数学能力、コーディング能力を兼ね備え、非常に複雑なタスクでもトップレベルのパフォーマンスを発揮します。タスクの自動化、仮説生成、チャート・グラフ・予測の分析など、自由形式のプロンプト作成や新規シナリオの作成を驚くほど流暢に対応できます。そして本日 (3/4)、Amazon Bedrock で Sonnet が先行して提供されました。Anthropic の評価では、現在 LLM で使用されている重要なベンチマークである math word problem solving (MATH) と multilingual math (MGSM) にて、Claude 3 のファミリーモデルが同等のモデルより優れていることが示唆されています。 視覚能力 — Claude 3 モデルは言語だけでなく、画像・チャート・図表など、様々な形式のデータを理解するようにトレーニングされています。これにより、企業は多様なマルチメディアソースを統合し、クロスドメインの問題を解決する生成 AI アプリケーションを構築できます。例えば、製薬会社では医薬品の研究論文とタンパク質の構造図を組み合わせてクエリすることができる様になり、早期発見が期待できます。また、メディア企業では画像のキャプションやビデオスクリプトを自動的に生成することができます。 最高クラスのベンチマーク — Claude 3 は、数学問題・プログラミング演習・科学的推論など、標準化された評価にて世の中の既存モデルを上回っています。お客様は AI による高精度な応答を活用して、製造分野における特定の実験手順を最適化したり、文脈に基づいたデータを用いて財務報告の自動監査を行ったりすることができます。 Source: https://www.anthropic.com/news/claude-3-family 具体的に Opus は、大学レベルの専門知識 (MMLU)・大学院レベルの専門知識 (GPQA)・基本的な数学 (GSM8K) など、AI システムの一般的な評価に用いるベンチマークのほとんどで同等のモデルを上回っています。複雑なタスクにおいて高い理解力と流暢さを発揮し、AI の一般的な知能分野で先頭を走っています。 ハルシネーションの軽減 — 企業は自動化プロセスや顧客対応において、将来の状況を事前に見通したコントロールしやすい結果を AI システムに求めています。Claude 3 のモデルは、Constitutional AI の技術を用いてモデルの推論プロセスを明確にし、ハルシネーションのリスクを低減します。特に Claude 3 Opus は、複雑な自由形式の質問に対して Claude 2.1 よりも 2 倍の精度を実現し、誤った回答が出力される可能性を減らしています。ヘルスケア、金融、法務調査などの業界で Claude に信頼を寄せるお客様にとっては、ハルシネーションリスクを減らすことが安全性とパフォーマンスを確保するために不可欠です。Claude 3 ファミリーは、信頼できる生成 AI の出力として新しい基準を確立します。 Amazon Bedrock で Anthropic Claude 3 を利用するメリット Amazon Bedrock を通じて、お客様は Anthropic の最新モデルを簡単に構築できるようになります。これには自然言語モデルだけでなく、テキスト・画像・チャートなど、高度な推論が可能なマルチモーダル AI モデルも含まれます。このコラボレーションにより、お客様は生成 AI の運用を加速させてビジネス価値を提供できる様になりました。Amazon Bedrock の Anthropic Claude を活用したお客様の具体例を紹介します。 “私たちは AWS で生成 AI ソリューションを開発しており、パーソナライズされた旅行プランを通じて顧客に印象的な旅行を計画し、人生に一度きりの体験を創出する支援を行っています。 Amazon Bedrock 上で Claude を使用することにより、スケーラブルで安全な AI プラットフォームを素早く作成しました。このプラットフォームは数分で私たちのコンテンツを整理し、一貫性のある旅程のリコメンドを正確に提供することができます。結果として旅程生成のコストが約 80％ 削減し、顧客の好みに応じてコンテンツの再構成を行ったパーソナライズもできるようになりました。Lonely Planet が 50 年以上にわたって行ってきた、信頼できる地元の声を取り入れることも可能になりました。” — Chris Whyde, Senior VP of Engineering and Data Science, Lonely Planet “私たちは AWS と Anthropicと協力し、カスタムでファインチューニングされた Anthropic Claude を Amazon Bedrock にホストしました。最先端の暗号化、データプライバシー、安全な AI テクノロジーを活用しながら、生成 AI ソリューションを大規模かつ迅速に提供する戦略を支援しています。新しい Lexis + AI プラットフォームテクノロジーには、会話型検索・深い洞察を経た要約・インテリジェンスな法的文書の作成機能も備わっており、弁護士の効率性・効果・生産性の向上に役立ちます。” — Jeff Reihl, Executive VP and CTO, LexisNexis Legal & Professional “国内および世界の金融市場で活動するお客様のために透明性や効率の向上を目指し、規制報告要件の理解を自動化する作業に取り組んでいます。Amazon Bedrock 上の Claude を使用することで、処理および要約の能力を用いた実験でさらに高い精度が得られることにわくわくしています。Amazon Bedrock では様々な LLM を選択できるため、そのパフォーマンスと統合機能を高く評価しています。“ — Saumin Patel, VP Engineering generative AI, Broadridge Claude 3 のモデルファミリーは様々なニーズに対応しており、お客様はユースケースに最適なモデルを選択できます。これは、新しい製品・機能・プロセスのいずれであっても収益向上をもたらす、プロトタイプや本番開発における成功の鍵となります。Anthropic と AWS はお客様のニーズを第一に考え、あらゆる組織が重要だと捉えるポイントを押さえたモデルを提供します。 パフォーマンスの向上 — Claude 3 は、ハードウェアとソフトウェアの最適化により、リアルタイムのインタラクションが大幅に高速化されました。 精度と信頼性の向上 — 大規模なスケーリングと新しい自己監視手法により、長いコンテキストに対する複雑な質問への精度が 2 倍向上することが期待されます。さらに安全な、正直で役立つ AI であることを意味します。 よりシンプルで安全なカスタマイズ — 検索拡張生成 (RAG) などのカスタマイズ機能は、独自データのモデルトレーニングや多様なデータソースを用いたアプリケーション構築を簡略化し、顧客に合わせた AI を提供します。さらに、独自のデータは決してインターネットに公開されることはなく、AWS ネットワークを離れずにVPCを通じて安全に転送され、転送中および保存中も暗号化されます。 AWS と Anthropic は、責任を持って生成 AI の発展に取り組むことを明言しています。モデル機能を常に改善し、 Constitutional AI のようなフレームワークや、 AI に関する米国政府の自主的なコミットメント に取り組むことで、この変革をもたらすテクノロジーを安全かつ倫理的に開発・展開することができます。 生成 AI の未来 将来を見据えれば、お客様は最新世代のモデルを利用して、全く新しい種類の生成 AI を搭載したアプリケーションや体験を開発することになります。私たちは、複雑なプロセスの自動化や人間の専門知識増強、デジタル体験の再構築などで生成 AI の可能性を引き出し始めたばかりです。Amazon Bedrock で必要なツールを駆使し、マルチモーダル機能を備えた Anthropic のモデルを選択することにより、お客様は前例のないレベルでイノベーションを実現できます。例えば、文脈に基づいて迅速な対応を行う会話型アシスタントや、関連画像・図表・関連知識を直感的に組み合わせて意思決定するパーソナライズ済みの推薦エンジンを想像してみてください。また、実験データから仮説を生成し、新たな探究領域を提案して科学研究を加速する生成 AI も考えられます。Amazon Bedrock を通じ、生成 AI が提供する全てのメリットを活用することで、多くの新しい可能性が実現されます。このたびのコラボレーションによって、世界中の企業やイノベーターは責任を持って生成 AI の力を利用することができます。それは、全ての人々に利益をもたらす革新的な取り組みに必要となる、新しい領域を切り開くためのツールとなるでしょう。 まとめ 生成 AI はまだ初期段階ですが、強力なコラボレーションと革新的な取り組みが生成 AI の新しい時代を切り開いています。これからお客様が何を構築されるのか、とても楽しみです。 詳細情報 本ブログの詳細情報をご覧になりたい方は、以下のリンクをご参考ください。 Access to the most powerful Anthropic models begins today on Amazon Bedrock Matt Wood のブログ: Introducing Claude 3 AWS News Blog: Anthropic’s Claude 3 Sonnet foundation model is now available in Amazon Bedrock Amazon Bedrock の Anthropic Claude 3 について: Anthropic’s Claude on Amazon Bedrock Amazon Bedrock について学ぶ : 基盤モデルを使用して生成 AI アプリケーションを構築する最も簡単な方法 AWS での生成 AI について 生成 AI のビジネス価値を引き出す方法について: Unlocking the business value of Generative AI 著者について Swami Sivasubramanian は、AWS のデータベースアナリティクスおよび機械学習担当のバイスプレジデントです。Swami はすべての AWS データベース・分析・AI & 機械学習サービスを監督しています。彼のチームの使命は、データを保存、アクセス、分析、視覚化、予測するための完全なエンドツーエンドのデータソリューションを使用して、組織がデータを活用できるよう支援することです。 本ブログはソリューションアーキテクトの澤亮太が翻訳しました。原文は こちら です。
はじめに 今日(2/29) から、 AWS Amplify Hosting 上で新しくデプロイされるアプリケーションのビルドイメージは、デフォルトで Amazon Linux 2023 が使用されます。Amazon Linux 2023 を利用することで、Amplify Hosting 上でアプリケーションをビルドする際に、より新しいバージョンの Node.js、Ruby、Python を使用できます。 Amplify Hosting は、アプリケーションを自動的にビルドできるように、事前にパッケージがインストールされたデフォルトのビルドイメージを管理しています。これまでデフォルトのビルドイメージは Amazon Linux 2 がベースになっており、インストールされているパッケージにいくつか制限がありました。今日からデフォルトのビルドイメージには Node.js 18 と 20 が事前にインストールされるようになりました。さらに、Python 3.10 と 3.11 もインストールされています。また、これらのプログラミング言語の新しいバージョンがリリースされたときには、nvm や pyenv を使用してインストールすることもできます。Next.js 14 を使用している開発者は、ビルドイメージへのカスタム設定なしで、アプリを 簡単にデプロイ できるようになります。 手順 このブログ記事では、AWS Amplify Hosting 上に既にアプリケーションがあり、Amazon Linux 2023 にアップグレードしたい場合に、ビルドイメージを Amazon Linux 2 から Amazon Linux 2023 にアップグレードする方法を示します。 前提条件として、 Amplify Hosting でホストされているアプリ が必要です。 まず、Amplify Console のサイドバーからアプリケーションの Build settings にアクセスします。 次に、 Build image settings セクション までスクロールし、Edit ボタンをクリックします。 これによりモーダルボックスが開き、既存のアプリをビルドするために新しい Amazon Linux 2023 イメージを選択できるようになります。 ビルドイメージを変更した後、 Save をクリックしてください。アプリケーションでトリガーされる新しいビルドは、新しく選択したイメージを使用します。Amazon Linux 2 に戻す場合は、上記の手順に従ってそのイメージを選択することができます。 まとめ このブログ記事では、Amazon Linux 2023 をビルドイメージとして使用するように Amplify Hosting アプリケーションを更新する方法を紹介しました。Amplify Hosting で新しく作成するアプリケーションは、デフォルトでこのビルドイメージを使用するため、変更する必要はありません。 次のステップとして、Next.js、Nuxt などを使用して構築された SSR または静的アプリを、 Amplify Hosting を使用してデプロイできます。フィードバックや機能リクエストは、 コミュニティ Discord にてお待ちしています。 この記事の翻訳はソリューションアーキテクト 安達翔平(さばみそ) が担当しました。原文は こちら です。
Terraform は、 HashiCorp が提供する、もっとも人気のある infrastructure-as-code (IaC) プラットフォームの 1 つです。 AWS Step Functions は、開発者が AWS のサービスを利用して分散アプリケーションを構築したり、プロセスを自動化したり、マイクロサービスをオーケストレーションしたり、データと機械学習 (ML) のパイプラインを作成できるよう支援するビジュアルワークフローサービスです。 このブログでは、Terraform を利用してワークフロー (Step Functions ステートマシン) をデプロイするユーザーのためのベストプラクティスを紹介します。AWS Step Functions の Workflow Studio を使用してステートマシンを作成して Terraform でデプロイする方法と、プロジェクト構造、モジュール、パラメータの代入、リモートステートなど、運用に関するベストプラクティスを紹介します。 このブログを読み進める前に、Terraform と Step Functions の両方について十分に理解しておくことをお勧めします。Step Functions や Terraform が初めての場合は Introduction to Terraform on AWS Workshop や、AWS Step Functions Workshop の中の Managing State Machines with Infrastructure as Code セクションの 「Terraform」オプションを参照してください。 Step Functions と Terraform のプロジェクト構造 ソフトウェアプロジェクトにおいてもっとも重要なことの1つは、その構造です。自分自身やチームの他のメンバーが効率的にコーディングを開始できるように、わかりやすく整理されている必要があります。 Terraform を使用した Step Functions プロジェクトでは、多くの可動部分やコンポーネントが含まれる可能性があるので、可能な限りモジュール化してラベルをつけることがとても重要です。モジュール化され、再利用性や拡張性に優れたプロジェクト構造を見ていきましょう。 mkdir sfn-tf-example cd sfn-tf-example mkdir -p -- statemachine modules functions/first-function/src touch main.tf outputs.tf variables.tf .gitignore functions/first-function/src/lambda.py tree 先に進む前に、上記のコマンドで作成したディレクトリ、サブディレクトリ、ファイルを確認してみましょう。 /statemachine には、Step Functions のステートマシン定義を記述した Amazon States Language (ASL)の JSON コードを配置します。ここがオーケストレーションロジックの配置場所となるので、インフラストラクチャコードから分離しておくことをお勧めします。プロジェクトで複数のステートマシンをデプロイする場合は、その定義ごとに JSON ファイルが必要になります。必要に応じて、ステートマシンごとにフォルダを分けて、ロジックをさらにモジュール化して分離することもできます。 /functions サブディレクトリには、ステートマシンの中から利用される AWS Lambda 関数の実際のコードが含まれています。このコードをここに保持しておくと、 main.tf ファイル内にインラインで記述するよりもはるかに読みやすくなります。 最後のサブディレクトリは /modules です。Terraform モジュールは、アーキテクチャの新しいコンセプトを表現する、高レベルの抽象的概念です。ただし、すべてのものにカスタムモジュールを作成するという罠にはまらないでください。そうするとコードのメンテナンスが難しくなってしまうことが考えられます。 多くの場合は AWS provider リソースで十分です。 Terraform AWS modules など、 Terraform Registry から利用できる人気の高いモジュールもあります。プロジェクト内でコードが冗長にならないように、可能な限りモジュールを再利用しましょう。 プロジェクトのルートにある他のファイルは、すべての Terraform プロジェクトに共通のものです。 terraform init の実行後に Terraform プロジェクトによって隠しファイルが作成されるので、 .gitignore を追加します。 .gitignore の中に何を記述するかは、コードベースやお使いのツールがバックグラウンドでサイレントに作成するものに大きく依存します。後のセクションで、 .gitignore 内で *.tfstate を指定して Terraform State を安全にリモート管理するためのベストプラクティスについて説明します。 初期コードとプロジェクトのセットアップ 単一の Lambda 関数のみを実行するシンプルな Step Functions ステートマシンを作成します。 そのためにはステートマシンが参照する Lambda 関数を作成する必要があります。まず Lambda 関数のコードを用意し、前述のディレクトリ構造の中のファイルに保存する必要があります。 functions/first-function/src/lambda.py import boto3 def lambda_handler(event, context): # Minimal function for demo purposes return True Terraform では、メインの設定ファイルの名前は main.tf です。 Terraform CLI はこのファイルをローカルディレクトリから探します。 テンプレートを複数の .tf ファイルに分割できますが、 main.tf はそのうちの1つである必要があります。 このファイルでは、テンプレートのリソース定義とともに、必要なプロバイダとその最小バージョンを定義します。(翻訳者補足: provider のバージョン制約の指定については Terraform 公式ドキュメント も参照してください) 以下の例では、Lambda 関数を 1 つ実行するだけのシンプルなステートマシンに必要な最小限のリソースを定義しています。 Lambda 関数とステートマシンがそれぞれ使用する 2 つの AWS Identity and Access Management (IAM) ロールを定義しています。 Lambda 関数コードを ZIP 圧縮する data リソースを定義し、Lambda 関数の定義で使用します。 また、全体を通して aws_iam_policy_document データソース を使用していることにも注目してください。この公式データソースを使用することで、統合開発環境 (IDE) と Terraform の両方が terraform apply を実行する前に、ポリシーが不正な形式でないかを確認できます。 最後に、Lambda 関数が実行ログを保存するために使用する Amazon CloudWatch ロググループを定義しています。 Terraform { required_providers { aws = { source = "hashicorp/aws" version = "~>4.0" } } } provider "aws" {} provider "random" {} data "aws_caller_identity" "current_account" {} data "aws_region" "current_region" {} resource "random_string" "random" { length = 4 special = false } data "aws_iam_policy_document" "lambda_assume_role_policy" { statement { effect = "Allow" principals { type = "Service" identifiers = ["lambda.amazonaws.com"] } actions = [ "sts:AssumeRole", ] } } resource "aws_iam_role" "function_role" { assume_role_policy = data.aws_iam_policy_document.lambda_assume_role_policy.json managed_policy_arns = ["arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"] } # Create the function data "archive_file" "lambda" { type = "zip" source_file = "functions/first-function/src/lambda.py" output_path = "functions/first-function/src/lambda.zip" } resource "aws_kms_key" "log_group_key" {} resource "aws_kms_key_policy" "log_group_key_policy" { key_id = aws_kms_key.log_group_key.id policy = jsonencode({ Id = "log_group_key_policy" Statement = [ { Action = "kms:*" Effect = "Allow" Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current_account.account_id}:root" } Resource = "*" Sid = "Enable IAM User Permissions" }, { Effect = "Allow", Principal = { Service : "logs.${data.aws_region.current_region.name}.amazonaws.com" }, Action = [ "kms:Encrypt*", "kms:Decrypt*", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:Describe*" ], Resource = "*" } ] Version = "2012-10-17" }) } resource "aws_lambda_function" "test_lambda" { function_name = "HelloFunction-${random_string.random.id}" role = aws_iam_role.function_role.arn handler = "lambda.lambda_handler" runtime = "python3.9" filename = "functions/first-function/src/lambda.zip" source_code_hash = data.archive_file.lambda.output_base64sha256 } # Explicitly create the function’s log group to set retention and allow auto-cleanup resource "aws_cloudwatch_log_group" "lambda_function_log" { retention_in_days = 1 name = "/aws/lambda/${aws_lambda_function.test_lambda.function_name}" kms_key_id = aws_kms_key.log_group_key.arn } # Create an IAM role for the Step Functions state machine data "aws_iam_policy_document" "state_machine_assume_role_policy" { statement { effect = "Allow" principals { type = "Service" identifiers = ["states.amazonaws.com"] } actions = [ "sts:AssumeRole", ] } } resource "aws_iam_role" "StateMachineRole" { name = "StepFunctions-Terraform-Role-${random_string.random.id}" assume_role_policy = data.aws_iam_policy_document.state_machine_assume_role_policy.json } data "aws_iam_policy_document" "state_machine_role_policy" { statement { effect = "Allow" actions = [ "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogGroups" ] resources = ["${aws_cloudwatch_log_group.MySFNLogGroup.arn}:*"] } statement { effect = "Allow" actions = [ "cloudwatch:PutMetricData", "logs:CreateLogDelivery", "logs:GetLogDelivery", "logs:UpdateLogDelivery", "logs:DeleteLogDelivery", "logs:ListLogDeliveries", "logs:PutResourcePolicy", "logs:DescribeResourcePolicies", ] resources = ["*"] } statement { effect = "Allow" actions = [ "lambda:InvokeFunction" ] resources = ["${aws_lambda_function.test_lambda.arn}"] } } # Create an IAM policy for the Step Functions state machine resource "aws_iam_role_policy" "StateMachinePolicy" { role = aws_iam_role.StateMachineRole.id policy = data.aws_iam_policy_document.state_machine_role_policy.json } # Create a Log group for the state machine resource "aws_cloudwatch_log_group" "MySFNLogGroup" { name_prefix = "/aws/vendedlogs/states/MyStateMachine-" retention_in_days = 1 kms_key_id = aws_kms_key.log_group_key.arn } Workflow Studio と Terraform の統合 Step Functions のステートマシンを作成するためには様々なツールが利用できるので、状況に応じて適切な開発手法を理解することが重要です。今回の場合は、Workflow Studio と Terraform でのローカル開発を組み合わせる手法が良いでしょう。このワークフローは、アプリケーションのすべてのリソースを同じ Terraform プロジェクト内で定義し、 AWS リソースの管理に Terraform を利用することを前提としています。 図1 – Terraform で Step Functions ステートマシンを作成するワークフロー Lambda 関数や Amazon S3 バケット、 Amazon DynamoDB テーブルなど、ステートマシン で呼び出す予定のリソースの Terraform の定義を記述し、 terraform apply コマンドを使用してデプロイします。これを Workflow Studio を使用する前に行うことで、ステートマシンの最初のバージョンの設計がしやすくなります。ステートマシンをローカルの Terraform プロジェクトにインポートした後、追加のリソースを定義できます。 Workflow Studio を使用して、ステートマシンの最初のバージョンを視覚的に設計できます。必要なリソースはすでに作成済みなので、すべてのアクションとステートをドラッグアンドドロップしてリンクし、どのように見えるかを確認できます。最後に、実際にステートマシンを実行して動きを確認できます。 ステートマシンの最初のバージョンの設計が完了したら、ASL ファイルをエクスポートして、Terraform プロジェクトに保存します。Terraform リソースタイプ aws_sfn_state_machine を使用し、保存した ASL ファイルを definition フィールドで参照します。 Terraform がリソースを動的に命名し、それに伴って Amazon Resource Name (ARN) が最終的に変化することを想定して、ASL ファイルをパラメータ化しておく必要があります。コードの更新やリファクタリングが困難になるため、ASL ファイルに ARN をハードコーディングすることは避けましょう。 最後に、 terraform apply を実行し、Terraform 経由でステートマシンをデプロイします。 シンプルな変更の場合は Workflow Studio での作業からやりなおすよりも、 Terraform プロジェクト内のパラメータ化された ASL ファイルを直接変更したほうが良いでしょう。 ASL ファイルをプロジェクトの一部としてバージョン管理することで、手動での変更作業によって意図せずステートマシンが破壊されてしまうことを防止できます。仮にステートマシンが破壊されてしまったとしても、以前のバージョンに簡単にロールバックできます。 ステートマシンに大規模な変更を加える場合は、コンソールで Workflow Studio の利点を活用することが望ましいでしょう。 しかし、ローカルで開発している間もステートマシンの視覚的な表現を継続的に確認したいと考えることがほとんどでしょう。幸いにも、 Visual Studio Code (VS Code) に直接統合されている別のオプションがあり、Workflow Studio と同様にステートマシンを視覚的にレンダリングできます。この機能は、AWS Toolkit for VS Code の一部です。AWS Toolkit for VS Code とのステートマシンの統合の詳細については、 こちら を参照してください。以下は、パラメータ化された ASL ファイルと VS Code でのレンダリングによる視覚化の例です。 図2 – VS Code 内で可視化された Step Functions ステートマシン パラメータの代入 Terraform テンプレートで Step Functions のステートマシンを定義する際は、その定義をテンプレート内に記述することも別のファイルに記述することもできます。テンプレート内にステートマシンの定義を直接記述すると可読性が低下し、管理が難しくなる可能性があります。 ベストプラクティスとして、ステートマシンの定義を別のファイルに記述しておくことをお勧めします。ステートマシンの定義にパラメータを渡すためには、Terraform の templatefile 関数 を利用できます。 templatefile 関数はファイルを読み取り、指定された変数セットを使用してコンテンツをレンダリングします。 以下のコードスニペットで示すように、 templatefile 関数を使用して、Lambda 関数の ARN やステートマシンに渡すその他のパラメータとともに、ステートマシン定義ファイルをレンダリングします。 resource "aws_sfn_state_machine" "sfn_state_machine" { name = "MyStateMachine-${random_string.random.id}" role_arn = aws_iam_role.StateMachineRole.arn definition = templatefile("${path.module}/statemachine/statemachine.asl.json", { ProcessingLambda = aws_lambda_function.test_lambda.arn } ) logging_configuration { log_destination = "${aws_cloudwatch_log_group.MySFNLogGroup.arn}:*" include_execution_data = true level = "ALL" } } ステートマシンの定義内で、 ${ … } で区切られた補間シーケンスを使用して文字列テンプレートを指定する必要があります。 以下のコードスニペットのように、 templatefile 関数によって渡される変数名を使用してステートマシンを定義します。 "Lambda Invoke": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": { "Payload.$": "$", "FunctionName": "${ProcessingLambda}" }, "End": true } templatefile 関数が実行されると、変数 ${ProcessingLambda} が、デプロイ時に生成された実際の Lambda 関数の ARN に置き換えられます。 Terraform State のリモート管理 Terraform を実行するたびに、管理対象のインフラストラクチャと構成に関する情報が State ファイルに保存されます。デフォルトでは、Terraform はローカルディレクトリに terraform.tfstate という State ファイルを作成します。 前述したように、 .gitignore ファイルに .tfstate ファイルを含めることをお勧めします。これによりソース管理にコミットすることがなくなり、意図せず機密情報が露出してしまうことを防ぎ、 State に関するエラーが発生してしまう可能性を低減することができます。 このローカルファイルを誤って削除すると、Terraform は以前に作成されたインフラストラクチャを追跡できなくなります。その場合、更新された設定で terraform apply を実行すると、Terraform がインフラストラクチャを新しく作成するため、作成済のインフラストラクチャとの間で競合が発生します。 バージョン管理や暗号化、共有を可能にするため、Terraform の State をリモートのセキュアなストレージに保存することをお勧めします。Terraform は、backend 設定ブロックを使用した S3 バケットへの State の保存をサポートしています。Terraform が State ファイルを S3 バケットに書き込むように設定するには、バケット名、リージョン、キー名を指定する必要があります。 また、State ファイルを誤って削除してしまうことを防ぐために、S3 バケットで バージョニングを有効 にし、 MFA 削除 を設定することをお勧めします。 さらに、ターゲットの S3 バケットに対して適切な IAM 権限 が Terraform に付与されていることの確認が必要です。 複数の開発者が同じインフラストラクチャを操作する場合は、Terraform は State ロックを使用して、同じ State に対する同時実行を防止することもできます。ロックの制御には DynamoDB テーブルを使用できます。使用する DynamoDB テーブルは、 LockID というパーティションキー ( String 型) が必要があり、Terraform はそのテーブルに対する適切な IAM 権限 を持つ必要があります。 terraform { backend "s3" { bucket = "mybucket" key = "path/to/state/file" region = "us-east-1" attach_deny_insecure_transport_policy = true # only allow HTTPS connections encrypt = true dynamodb_table = "Table-Name" } } この リモートState の設定により、 S3 で State を安全に保存し、維持できます。 インフラストラクチャに変更を適用するたびに、Terraform は S3 バケットから最新の State を自動的に取得し、DynamoDB テーブルを利用してロックを取得します。変更を適用した後、最新の State を S3 バケットにプッシュし、その後ロックを解除します。 クリーンアップ terraform apply を実行して Lambda 関数、Step Functions ステートマシン、バックエンドの State ストレージの S3 バケット、その他の関連リソースをデプロイした場合は、AWS アカウントで料金が発生しないように、 terraform destroy を実行してこれらのリソースを削除して環境をクリーンアップしてください。 まとめ このブログでは AWS Step Functions ステートマシンのデプロイに Terraform を活用するための包括的なガイドを提供しています。適切に構造化されたプロジェクト、コードの初期セットアップ、 Workflow Studio と Terraform の統合、パラメータの代入、 State のリモート管理の重要性について説明しました。 これらのベストプラクティスに従うことで、開発者はクリーンでモジュール化された再利用可能なコードを維持しながら、ステートマシンをより効果的に作成および管理できます。 infrastructure-as-code (IaC) を導入し Workflow Studio 、 VS Code 、 Terraform などの適切なツールを使用すると、スケーラブルでメンテナンスしやすい分散アプリケーションを構築したり、プロセスを自動化したり、マイクロサービスをオーケストレーションしたり、AWS Step Functions を使用したデータと機械学習 (ML) のパイプラインを作成できます。 Step Functions を Terraform と共に利用する方法をより深く学習したい場合は、Serverless Land で公開されている パターン や ワークフロー をご確認ください。また、 Step Functions 開発者ガイド も参照してください。 著者について Ahmad Aboushady Ahmad Aboushady は、UAE を拠点とする AWS の Senior Technical Account Manager です。彼はリージョン全域のエンタープライズサポートのお客様が AWS 上のワークロードを最適化し、クラウドへの取り組みを最大限に活用できるように支援しています。 Patrick Guha Patrick Guha は、テキサス州オースティンを拠点とする AWS の Solutions Architect です。 彼は、クラウドでのゲノミクスやヘルスケア、ハイパフォーマンス コンピューティング ワークロードに焦点を当てた非営利の研究顧客を支援しています。 Patrick は Electrical and Computer Engineering の BS を取得しており、現在 Engineering Management の MS 取得を目指して取り組んでいます。 Aryam Gutierrez Aryam Gutierrez はマドリードを拠点とする AWS の Senior Partner Solutions Architect です。彼は、AWS でビジネスを成長させるという最終目標に向けて、戦略的パートナーが拡張性の高いソリューションを構築したり、さまざまなパートナープログラムを活用してビジネスを差別化できるようにサポートしています。 本記事は 2023/09/18に投稿された Best Practices for Writing Step Functions Terraform Projects を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。
Amazon QuickSight はAWSが提供するクラウドネイティブの統合型BIサービスです。サーバーレスのため、運用管理の負担が少ないだけでなく、ビジネスユーザーがデータから多くのインサイトを得られる機能を提供しています。このたび銀行業界向けのサンプルダッシュボードを DemoCentral 上に公開しましたので、本ブログにて使い方の解説をいたします。 組織内でデータ利活用を推進するためには、各種ツールの使い方に加え、どのような可視化を行えばよりよいインサイトにつながるかについての理解も重要です。本ブログでは、銀行業界に従事する方々がイメージしやすいようATMの配置戦略というテーマをサンプルシナリオとしてとりあげ、どのような観点でグラフや表（以下、ビジュアル）を構成していくとよいかについて解説していきます。ぜひ実際のダッシュボードをブラウザの別タブや別ウィンドウとして開いた状態で見比べながら当ブログを読み進めて頂ければと思います。 ダッシュボード解説 データの可視化において重要なポイントは、得られたインサイトから実際に行動可能なアクションへと繋げることです。そのためダッシュボードを作る際は必ず「意思決定者は誰であり、どのようなアクションが実行可能か」を意識して構築することが肝要です。今回は架空の銀行を例に、チャネル戦略担当マネージャーが、コスト最適化のためにATMの配置最適化や削減を検討するためのダッシュボードという位置付けでサンプルを作成しています。 ATMチャネル分析 当ダッシュボードは3つのタブから構成されており、メインとなるのが一番左の ATMチャネル分析 タブです。まずATMチャネル分析タブから解説していきます。 上図がATMチャネル分析ダッシュボードの全体像です。ダッシュボードに配置するビジュアルは一般に左上から右下に向かって、概況から詳細へと粒度をブレークダウンしながら配置することがベストプラクティスとされており、当ダッシュボードもそれに従い構成しています。それでは上から順に各ビジュアル要素についてみていきましょう。 自行ATMの取引件数概況を把握する①（ ナラティブ） 1つめがナラティブです。この例のように、ナラティブを使って文章のなかに重要な数値情報とそこから得られるインサイトを埋め込むことで、読み手の違いによって発生する解釈の違いや、初めてダッシュボードを参照するユーザーがグラフや表を読み解く手間を軽減することが可能です。このシナリオで担当マネージャーは、自行で運営管理するATM（以下、自行ATM）で採算が取れる閾値として、ATM1台当たり日平均50件以上の取引が行われることを一つの目標として設定していましたが、月次サマリを参照すると残念ながら目標には到達できておらず、何らかのアクションが必要なことが示唆されています。 自行ATMの取引件数概況を把握する②（ KPI） 2つ目がKPIです。KPIはその名の通り、重要な業務評価指標をシンプルに数字として示したものとなっており、今回のシナリオでは自行ATMの1台当たり日平均取引件数を設定しています。このビジュアルで得られるインサイトとしては、前述のナラティブと類似していますが、一瞥で概況をつかみやすい点が特徴で、ダッシュボードを参照し慣れた担当マネージャーにとって有用なものとなっています。 自行ATM廃止要否を判断する（コンボグラフ） 3つ目はコンボグラフです。棒グラフと折れ線グラフという2種類のグラフをひとつに統合したビジュアル要素で、X軸（横軸）を時間軸とすることで時系列での傾向を分析できるようにしています。先ほど確認したKPIでは当初設定していた目標を直近割り込んでしまったことが確認できましたが、このコンボグラフを参照することでどのような推移を経て現在に至ったのかを確認することができます。緑色の折れ線グラフがKPIである「自行ATMの1日あたり1台あたりの平均取引件数」の推移を示したものになります。2023年3月付近から顕著に低下している様子が確認できます。棒グラフは、自行ATM以外も含めたATM種別ごとの総取引件数の推移です。キャッシュレス決済の台頭による影響でしょうか、そもそもATMを使った現金取り扱い件数自体が徐々に低下している様子が確認できます。担当マネージャーがこれまで1年間にわたって低稼働ATMの廃止を進めてきているにもかかわらず、KPIである平均取引件数の低下を抑えきれていないことから、ATMを使った取引全体件数低下の勢いがATM廃止措置の効果を上回ってしまっており、採算ラインを維持するためにはさらなる廃止措置が必要かもしれないことを示唆しています。 Tips：ダッシュボード上に表現されていない情報の追加確認（QuickSight Q） 担当マネージャーがこれまでATM台数を削減してきたことはダッシュボード上のビジュアルに表現されていませんが、QuickSight Qという機能を使い自然言語で質問を投げかけることで確認が可能です。QuickSight Qの利用方法については、後述の「QuickSight Qに質問をする（補足1：QuickSight Qサンプル質問集/用語集）」をご参照ください。サンプル質問が複数用意されていますが、 例4：ATM台数の前年比較 という質問を投げかけることでATM台数が前年比削減されてきていることを確認できます。 Tips：KPI目標の見直し（スライダー） 今回、KPI目標である1日1台あたりの平均取引件数50件を赤色点線にて表示していますが、こちらの目標値は画面右上のスライダーに紐づけることで可変としています。例えばスライダーで目標値を50件→35件に下方修正してみましょう。すると、前述したナラティブ内の記載も変化していることに気づいたでしょうか。QuickSightではこのようにインタラクティブなダッシュボードをコーディングなしに構築することが可能です。 時間帯によるATM種別ごとの取引傾向を把握する（棒グラフ/ヒートマップ） 続けて棒グラフとヒートマップをあわせてみていきましょう。棒グラフについては皆さん普段から使い慣れているかと思いますので説明は割愛します。ヒートマップは2つの軸の関係を1つの指標で比較する際に用いることのできるグラフです。この例では、 取引時間帯（0時台～23時台） という軸と ATM種別（自行ATM、コンビニATM、その他ATM） という2軸の関係を 取引件数 という指標で比較しています。まず棒グラフを参照するとATM種別としては 自行ATM（無人店、本支店） の取引が大半を占めていることが確認できます。加えてヒートマップを参照することで、特に日中時間帯に自行ATMの利用割合が高いこと、反対に19時台以降は（自行ATMで稼働している端末があるにもかかわらず）コンビニATMの利用割合が高まっていることが確認できます。これを見た担当者はひとつの案として「夜間帯についてはコンビニATM側へ利用者を誘導し、自行ATMとしては稼働時間の短縮を推し進めてコスト削減を図る」というアクションプランを検討することができそうです。 廃止、稼働時間短縮対象のATMを特定する（表） これまで様々なビジュアルを確認してきた中で担当マネージャーは、平均取引件数が少ないATMの廃止や、夜間時間帯に稼働しているATMの稼働時間短縮を検討したいと考えています。対象明細については一覧表で確認していきます。ここではQuickSightのフィルタ機能を使うことでインタラクティブなダッシュボードを実装しています。低稼働ATM一覧の直上にある稼働時間フィルタで All と指定することで、自行ATM全体の中で平均取引件数が少ない端末を順にリストアップし、廃止対象のATMを選定することが可能です。次に稼働時間フィルタを 7:00-24:00 と指定することで夜間時間帯に稼働しているATMに限定してリストアップすることができます。ここでリストアップされた対象ATMについては、まずは稼働時間を短縮してみるというアクションも検討することができそうです。 Tips：前月比の算出方法について 上記一覧表の右端には前月比という計算フィールドを用意しています。こちらは各ATMの日平均取引件数が前月比どの程度増減したかを百分率で表示している項目です。前月比、前年同月比といった計算項目をQuickSight上で追加する方法についてはブログ記事「 Amazon QuickSight に比較および累積の日付/時刻計算を追加する 」を参照ください。なお一覧表などのビジュアルを作成する際、最新月データに絞って表示させたいという要件はよく見受けられますが、前月比データを出力させたい場合、ビジュアルに対し最新月フィルタを適用してしまうと、前月データを抽出できず前月比の算出ができなくなってしまうため一工夫が必要です。解決方法としては QuickSight Communityでの過去QA が参考になります（当ダッシュボードでも同じ解決方法で実装しています）。 取引件数の地理的分布から新たなATM設置戦略を検討する（マップ） 最後にご紹介するのがMapです。QuickSightでは郵便番号や住所などの位置情報をもとに、数値データを地図上にマッピングするビジュアルが用意されています。今回は、ATMの設置郵便番号をもとに取引件数を地図上にプロットしています。 こちらを見ると、地図下中央部付近（ Kawasaki-Shi, Miyamae-Ku など）にATMが設置されていない一方で、それを取り囲む領域（ Tokyo Ota-Ku, Komae-Shi, Machida-Shi など）では相応の取引件数が発生していることが確認できます。これまで同行は無人店含め都道府県境を跨ることを避けてATMの設置を進めてきましたが、地図にマッピングすることで、ホワイトスペースの存在に気づき新たなATM設置先を検討する材料にもできそうです。 QuickSight Qに質問をする（補足1：QuickSight Qサンプル質問集/用語集） 次に真ん中のタブ 補足1：QuickSight Qサンプル質問集/用語集 について解説します。 QuickSightには、ダッシュボード上のデータをもとに自然言語での問い合わせに対し回答を生成、提示してくれるQuickSight Qという機能があります。当機能は2024年3月時点で英語にしか対応しておらず、英語にて問い合わせをしていただく必要がありますが、日本語データを含むダッシュボードでも工夫することで利用が可能です。今回ATM稼働状況ダッシュボードでも当機能を利用できるようにしています。 まず、QuickSight Qを利用するには、QuickSight上で トピックス というものを作成する必要があります。トピックスは、自然言語での問い合わせを実現する、１つもしくは複数のデータセットのコレクションで、Authorがデータセットを選択して作成することもできますが、ダッシュボードを公開するときに、ダッシュボードで定義しているデータセットからトピックスを新規作成し、さらに分析へリンクするまでの操作を、一気に実施することもできます。トピックスでは、自然言語の問合せで使用するフィールドの指定、問い合わせする言葉や表現に合わせて、フレンドリー名の指定やシノニム（同義語）の設定など、フィールドのセマンティック定義を適宜設定することができます。また、フィードバックの内容や質問の履歴もこのトピックスの画面から確認でき、そのフィードバック内容から定義を追加や更新したりすることで、返答の精度を上げていくこともできるようになっています。 当ダッシュボードの上部を参照すると、 Q のアイコンと financial-atm という青字タイトルの右隣に Type a question about your data と記載されているバーがあり、質問が入力できることがわかります。financial-atmとは、今回このダッシュボード用に作成したトピックス名で、そのトピックス名をクリックするとユーザーが利用可能な（アクセス権が付与された）その他のトピックスを参照することができます。 今回日本語のカラム名をもつ日本語データに対して英語で問い合わせをするため、トピックス上でシノニム（同義語）に英語名を定義しており、その内容は「補足1：QuickSight Q サンプル質問集/用語集」シートの下部にある用語集より確認できます。 では、実際にQuickSight Qに英語で問い合わせてみます。このダッシュボードでは、同シートにサンプルの質問集を例１から7まで用意しており、日本語による質問の意味と、それを翻訳した英語の質問を明記しています。シノニム定義の英単語を使用していることが下線から分かります。英語の質問文をコピーして上部のバーにペーストすることで、対応する日本語（意味）と同等の質問を問い合わせることができるようになっています。 QuickSight QではWhy（なぜ）の質問もすることができます。ダッシュボード上では、ATMの取引件数が下がってきている傾向がコンボグラフで表示されていましたが、何に起因しているかをQuickSight Qに問い合わせて確認してみます。例５の質問をコピーして、ペーストします。シノニム定義のフィールドが正しく認識されているかどうか、また、データ（Aug 2023）も正しくフィールドを認識できているかどうかは、質問を入力した後に該当する下線部分をクリックすることで確認することができます。デフォルトでは一番上のフィールド名で認識されていますが変更することもできます。 また、返答の上部に、QuickSight Qが解釈した質問が表示されており、なぜ日平均取引数の平均集計が2023年8月から変動あったか、と記載されています。集計方法が平均でなく合計等、意図しない集計方法である場合はここで変更できます。対象月は2023年8月となっていますが、こちらも変更でき範囲指定にすることも可能です。 返答内容をみると、2023年8月の日平均取引数が前月より4%下がっていることに対する寄与分析結果が確認できます。そのキードライバーとしてまず ATM番号 があり、ATM番号05151のATMにて日平均取引件数が30%下がっていると記載されています。全体への寄与率は2%と少ないですが、30%も下がっていることは特徴的です。 では、このATM番号05151とは、どこのATMかを次に問い合わせてみます。例６の質問をコピーしてペーストします。 ATM番号05151の設置場所を問い合わせると、 目黒区 であることがわかり、 設置郵便番号 も表示されます。この情報から地図上どこのATMなのかを確認します。右のアイコンから、 Visual Types（ビジュアルタイプ） を選択し、 Points on map（地図上のポイント） を選択します。そうすると、郵便番号から、詳細のロケーションを地図上で確認することができます。 この地図の結果を Pinboard（ピンボード） に追加して、いつでも後からすぐに参照できるようにします。右のアイコンから Add to Pinboard をクリックすると、追加されます。Pinboardへのアクセスは、 上部Qバーの右端のアイコンです。クリックすると、 My Pinboard が表示され、今回追加された地図上のポイントを確認することができます。この地図上のポイントを、このトピックスに参照権があるユーザーに、簡単に共有することもできます。 先ほどの寄与分析の結果では、２つ目のキードライバーは 設置住所 であり、 港区 にて前月比4％のマイナスになっており、寄与率も 22% と高く記載されていました。港区における低下率4%は全体の低下率とほぼ同じ値です。それでも、港区がキードライバーと分析された背景には、ATM総台数が影響しているかもしれません。こちらもQuickSight Qに問い合わせてみましょう。例７の質問をコピーしてペーストします。 表示された結果は、よく見るとcountで集計されています。ATMのユニーク数が知りたいので、水平棒グラフの上にある count of ATM番号 を選択し、 aggregation から DISTINCT COUNT を選択します。そうすると、都市別のATMユニーク数が正常に表示されます。港区のATM数は115台もあり、他の区や市と比べて、かなり多いのがわかります。 このように、QuickSight Qを利用すると、ダッシュボード上に表現できていないことを、閲覧者が直接ダッシュボード上で問い合わせることで、その場で回答を取得することができます。QuickSight Qを利用しない場合は、ダッシュボードの作成者に依頼をしてグラフや表を追加してもらう必要があるため、大幅に時間短縮を図ることができ、ビジネスの現場でも効果的にご利用いただけます。その他のサンプル質問など、ぜひQuickSight Qをお試しください。 QuickSightに至るまでのデータの流れを理解する（補足２：全体概要図） 一番右のタブ 補足２：全体概要図 では、今回のサンプルダッシュボードが一般にどのようなデータソースをもとに、どのような前処理を経由してQuickSightに取り込まれていくかの全体像を示しています。今回のサンプルダッシュボードに限らず、データ可視化をする際は、前処理としてデータの加工集計処理（ETL処理）を施したうえで、可視化ツールへInputする手法をとることがあります。当概要図ではETL処理実装として AWS Glue を用いるイメージで記載しておりますがあくまで一例であり、他にも選択肢はあります。AWS上でのETL処理の実装については AWSで実践！Analytics Modernization ～ETL 編～ が参考になります。なお当概要図はあくまで概念的なものを示したものであり、実際のデータソースはさらに細分化され、加工集計処理もより複雑なものとなりうる点は留意してください。 まとめ 本ブログ記事では先日公開された銀行業界向けサンプルダッシュボードが、アクションにつながるInsightを提供するために、どのような考え方に基づき構成されているかを中心に紹介しました。 QuickSight自体の使い方や各ビジュアル要素作成時の操作手順等については説明を割愛しましたが、興味のある方は是非、 Amazon QuickSight – Visualization Basics (Japanese) ワークショップをご参照ください。今回のサンプルダッシュボードで利用しているビジュアル含め、QuickSightで取り揃えている様々なビジュアルについて、Step-by-Stepの操作手順付きで作成方法をご案内しています。 また金融業界ではデータ利活用を推進する上で、セキュリティやガバナンスについても特に厳しい基準が求められることがありますが、QuickSightでは 行レベル や 列レベル のアクセス制限、 接続元IPアドレスによるアクセス制御 、 操作ログの記録 などをサポートしており、各業界でのデータ利活用促進を支援しています。 当ブログでは、QuickSightでのデータ可視化に絞って紹介しましたが、実際に企業内でデータを利活用するためには、そこに至るまでのデータ活用戦略の検討や、分析基盤の構築も必要です。AWSでは金融機関に求められる水準のセキュリティレベルを備えつつ、将来的なニーズの変化や利用規模拡大に柔軟に対応可能で、コスト最適なデータ分析基盤を構築できるリファレンスアーキテクチャを 金融リファレンスアーキテクチャ データ分析プラットフォーム として提供しております。是非あわせてご参照ください。 著者プロフィール 中嶋理人（Masahito Nakajima）はAWS Japan のソリューションアーキテクト。普段は地域金融機関のお客様を中心に技術支援を行っています。好きなAWSサービスはAmazon QuickSightとAmazon Connect。 ヴィルキャン坂下和香奈（Wakana Vilquin-Sakashita)は、QuickSight のシニアソリューションアーキテクト。
みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 What’s newには上がっていないのですが、大事なニュースなのでこちらでおしらせします。東京リージョンにおけるAmazon Bedrockで、 AnthropicのClaude 2.1をご利用いただけるように なりました。Claude 2.1のために海外リージョンを利用している場合は、東京リージョンに変更することでレイテンシの改善が期待できますのでもしよろしければぜひ。 さて、機械学習技術を楽しみながら学ぶことができる AWS DeepRacer リーグが今年もやってきます 。高いランキングに入ることができれば、素敵な賞品やre:Inventへのご招待チケットを獲得するチャンスがあります。我こそは！と思う方のチャレンジをお待ちしています。 それでは、2 月 26 日週のアップデートを振り返ってみましょう。 2024 年 2 月 26 日週の主要なアップデート 2/26(月) Amazon CloudWatch LogsがIPv6をサポート Amazon CloudWatch LogsでIPv6をご利用いただけるようになりました。サーバからのログ収集はもちろんですが、インターネットに接続されたIPv6デバイスが大量に存在するケースでもNATを介することなく直接ログを収集することが可能になることもメリットです。 Amazon RDS for MariaDBで新しいマイナーバージョンを利用可能に Amazon RDS for MariaDBでバージョン10.11.7, 10.6.17, 10.5.24, 10.4.33をご利用いただけるようになりました。セキュリティ修正やバグ修正が行われているので、テスト実施のうえでアップグレードをお勧めします。 2/27(火) Amazon EC2 C7a/R7aインスタンスの対応リージョンが拡大 東京リージョンほか3つのリージョンで、C7aインスタンスがご利用いただけるようになりました。C7aは最大3.7GHzで動作する第4世代のAMD EPYCプロセッサ(Genoa)を搭載し、C6aと比較して最大50%高いパフォーマンスを発揮します。同時にR7aインスタンスが欧州の3リージョンでご利用いただけるようになりました。 2/28(水) Amazon RDSの2つの読み取り可能スタンバイを備えたMulti-AZ配置でgp3ボリュームを利用可能に Amazon RDSではMulti-AZ配置を構成する際に2種類の方法が提供されています。そのうちのひとつである「2つの読み取り可能なスタンバイを備えたMulti-AZ」配置を選択した際に、ストレージボリュームとしてgp3ボリュームを選択できるようになりました。gp3ではパフォーマンスを柔軟にプロビジョニングできるので、コスト最適化が容易になります。 2/29(木) Amazon Q for BuisnessがQ applicationsのメタデータのブースティングが可能に Amazon Qのアプリケーションはユーザの問い合わせに応答する際に、社内の情報をふまえた応答を生成するためにRAG(Retrieval Augmented Generation)という手法を利用することがあります。今回メタデータのブースティングに対応したことにより、社内情報の検索結果リストにおけるランキングを微調整できるようになり、これによってより関連性の高い回答を返すよう調整できるようになります。 Amazon Security LakeがAmazon EKSの監査ログに対応 Amazon Security LakeはAWS環境やSaaSアプリケーション、オンプレミス、クラウド等からのセキュリティデータを、専用のデータレイクに自動的に一元化するサービスです。今回、Amazon Security LakeがAmazon EKSの監査ログに対応し、より幅広いセキュリティログを一元管理できるようになりました。 Amazon Security LakeがOCSF 1.1.0とApache Icebergをサポート Amazon Security LakeがOCSF(Open Cybersecurity Schema Framework)のバージョン1.1.0と、Apache Icebergテーブルをサポートしました。 Amazon EC2 m7i.metal-24xlインスタンスをVMware Cloud on AWS(VMC)がサポート Amazon EC2 m7i.metal-24xlインスタンスがVMCでご利用いただけるようになりました。このインスタンスタイプはコンピューティングリソースとストレージが分離される仕組みになっており、ストレージとしてAmazon FSx for NetApp ONTAPかVMware Cloud Flex Storageをご利用頂く形となります。現時点ではバージニア、オハイオ、オレゴン、アイルランド、ストックホルムのリージョンでご利用いただけます。 Amazon EKSがAmazon Linux 2023をサポート Amazon EKSがAmazon Linux 2023(AL2023)をサポートしました。AL2023は種々の機能強化がはいっていますが、EKSと組み合わせて利用した場合のメリットは こちら をごらんください。 3/1(金) Amazon BedrockでMistral AI基盤モデルが利用可能に Amazon BedrockでMistral AIが提供するMixtral 8x7BとMistral 7Bをご利用いただけるようになりました。Amazon Bedrockは異なる基盤モデルを同じAPIで利用できることが特徴のひとつで、用途に応じて最適なモデルを容易に選択できます。今回のアップデートで、選択肢がさらに広がったことになります。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )
はじめに 業界調査会社 IHS Markit によると、2021 年末までに世界で導入される IP カメラの推定台数は 10 億台に近づいており、ガートナーの Emerging Tech：ガートナー社の「Emerging Tech: Revenue Opportunity Projection of Computer Vision」レポートによると、主要市場における企業向けコンピュータビジョン（CV）ソフトウェア、ハードウェア、サービスは、2022 年の 1260 億ドルから 2031 年までに 3860 億ドルの世界収益を生み出すと予想されています。オンプレミスでの IP カメラの導入の多くは、ネットワークビデオレコーダー（NVR）を利用して、カメラからの映像や音声の記録、保存、再生を処理し、その接続は一般的にリアルタイムストリーミングプロトコル（RTSP）などを使用して実装されています。IP カメラは個人の家庭の監視だけでなく、商業および公共市場での監視にも使用されています。このような IP カメラからのメディアをキャプチャするために NVR を設置することがいつも可能だとは限らない一方で、カメラの台数が増えるにつれて、コンピュータ・ビジョン解析ソリューションを構築して、イベントを迅速に検出し、エンド・ユーザーまたはプロの監視チームにインテリジェントな通知を行うことがますます重要になっています。 このブログでは、RTSP 経由で IP カメラストリームを Amazon Kinesis Video Streams にセキュアに取り込むためのクラウドゲートウェイの構築方法について説明します。Amazon Kinesis Video Streams は、kvssink と呼ばれる GStreamer プラグインを含め、メディアを AWS に安全にストリーミングするための SDK を提供します。GStreamer は人気のあるオープンソースのメディアフレームワークで、カスタムのメディアパイプラインを作成し、多数のカメラやビデオソースとの統合を大幅に簡素化することができます。このブログ記事では、NVR のような新しいハードウェアをオンプレミスに導入できない顧客のために、クラウドベースのゲートウェイを構築することに焦点を当てています。同じタイプのアプローチは、既存のオンプレミス NVR からのメディアの安全なストリーミングを実装するために使用することができます。 概要 以下のアーキテクチャ図は、このソリューションがお客様のアカウントに展開するリソースを示しています。 図1：RTSP から Amazon Kinesis Video Streams ソリューション・アーキテクチャへのオンプレミス IP カメラ・ビデオ・ストリームの取り込みのための AWS Fargate ベースのゲートウェイ クラウド・ゲートウェイはここでは AWS Fargate アプリケーションとしてデプロイされますが、Fargate 上でも Amazon Elastic Compute Cloud（Amazon EC2）上でも実行できます。Fargate 上で動作するアプリケーションは GStreamer メディアパイプラインで構成され、 Kinesis Video Streams の C++ Producer SDK の一部である Kinesis Video Streams Gstreamer プラグインを利用します。GStreamer プラグインを含む Kinesis Video Streams Producer SDK を AWS Fargate コンテナ内でコンパイルします。したがって、GStreamer マルチメディアフレームワークと Kinesis Video Streams Producer SDK のコンパイル時の依存関係は、Fargate アプリケーションの一部としてインストールする必要があります。 図 1 の Amazon Virtual Private Cloud (Amazon VPC) アーキテクチャには、インターネット・ゲートウェイまたは Egress-only インターネット・ゲートウェイが使われます。RTSP ストリームのビットレートと、このブログのソリューションを使用して統合するカメラの総数に応じて、インターネットゲートウェイまたは Egress 専用ゲートウェイを使用して、ネットワークトラフィックをコスト最適化します。NAT ゲートウェイを使用することもできますが、1 台以上の IP カメラからビデオデータを取り込む場合、NAT ゲートウェイは最もコスト最適化されたアプローチではありません。詳細については、 Amazon VPC の価格 を参照してください。ブランチオフィスのデータセンターと AWS リソースの間にセキュアな接続を作成するために、上記のアーキテクチャでは AWS Direct Connect または AWS Site-to-Site VPN を利用しています。詳細については 、AWS Well-ArchitectedFramework の Hybrid Networking Lens を参照してください。 前提条件 Kinesis Video Streams、Amazon EC2 または Fargate、Amazon VPC の全権限を持つ AWS アカウント Linux オペレーティングシステムとコマンドラインの使用に精通していること C++ アプリケーションのコンパイルや CMake の使用に慣れていると便利ですが、必須ではありません。 AWS CLI、AWS CDK、Docker ツールがインストールされたシステム ウォークスルー Cloud Gateway for Amazon Kinesis Video Stream リポジトリには、Amazon EC2 および Fargate デプロイメント用の AWS Cloud Development Kit（CDK）が含まれています。サンプルアプリケーションを AWS アカウントにデプロイする手順は、リポジトリの README に含まれています。以下は、サンプル・レポジトリを自分のアカウントにデプロイするために必要な手順の概要です： ステップ1: Kinesis Video Stream の作成 Kinesis Video Stream を作成 するには、希望のリージョンで AWS マネージメントコンソール を開きます。Create video stream を選択し、ストリーム名に CloudGatewayStream を入力します。Default configuration ラジオボタンを選択したままにします。 ステップ2：インターネットゲートウェイで Amazon VPC の作成 Amazon EC2 または Fargate コンテナを実行できるようにするには、 VPC を作成する 必要がある。次に、Cloud Gateway がリモート・カメラに接続できるように Internet Gateway を作成 する。 ステップ3：SSH キーペア と IAM ユーザーの作成 Amazon EC2 を認証するための SSH キーペアを作成 する。 GStreamer の起動スクリプトで Kinesis Video Streams へのアクセスを提供する IAM ユーザーを作成 する。 ステップ4: RTSP ストリームを取り込むクラウドゲートウェイの作成 Amazon EC2 を使用して Cloud Gateway を構築し、サービスとして稼働する GStreamer をインストールするか、コンテナとして稼働する Cloud Gateway を構築するかを選択できます。Cloud Gateway をコンテナとして実行するには、まず Docker コンテナをビルドし、それをデプロイする必要があります。Docker コンテナを構築するには、Amazon EC2 を作成し、Docker ツールをインストールして、 GStreamer とスタートアップ・スクリプトを含む Ubuntu コンテナを構築します。すでにローカルマシンに docker ツールがインストールされている場合は、それを代わりに使うこともできます。次に、ビルドした Docker イメージを保存するための Elastic Container Repository（ECR）を作成 します。最後に、構築した Docker イメージを使ってクラウドゲートウェイのインスタンスを起動する Fargate クラスタ 、 タスク 、 サービスを 作成します。 ステップ5: ビデオストリームの表示 Kinesis Video Stream Console に移動し、Video Streams を選択し、最後にビデオストリームを選択します。メディア再生コンポーネントを展開し、ビデオストリームの表示を開始します。ストリームの例を以下に示します： 図2: オンプレミスIPカメラからのKinesisビデオストリームの表示 ビデオストリームを表示するために AWS Console に頼る代わりに、 Amazon Kinesis Video Streams Media Viewer アプリケーションを見て、ビデオストリームをWebアプリケーションに組み込む方法を学んだり、 Kinesis Video Streams からの HLS または DASH ストリーミングセッション URL をお好みのビデオプレーヤーで使用したりすることができます。 後片付け 将来のコストを避けるために、不要になった場合は以下の手順で作成したリソースを削除します。 Cloud Gateway for Amazon Kinesis Video Stream CDK プロジェクトを使用した場合は、 cdk destroy コマンドを実行してデプロイメントを削除します。 CDK プロジェクトを削除する EC2 を削除する Fargate アプリケーションの削除 Kinesis Video Streams からストリームを削除する 作成した Amazon VPC を削除する まとめ この投稿では、オンプレミスの IP カメラから Amazon Kinesis Video Streams にメディアをインジェストし、ライブ・ストリーミング、ビデオの保存と再生を行うクラウド・ゲートウェイの構築方法を学びました。このアプローチでは、オンプレミスのハードウェアを追加することなく、既存のIPカメラと統合することができます。また、Fargate 上のクラウドゲートウェイを使用してオンプレミスのソースからビデオデータを取り込む際に、AWS の AWS well-architected プリンシパルを適用してコストを最適化します。このソリューションは、家庭や企業に設置されたカメラで使用することができ、RTSP ストリームからビデオデータを取り込むことに重点を置いている。クラウドゲートウェイのスケーリングが必要な使用例については、 Amazon EC2 の自動スケーリング または Fargate の自動スケーリングガイド を使用してください。 Kinesis Video Streams の詳細については スタートガイド を、その他の GStreamer パイプラインサンプルについては Kinesis Video Streams Producer SDK GStreamer Plug-in のサンプル をご覧ください。GStreamer の効果的な使用方法については、 GStreamer アプリケーション開発マニュアル をご覧ください。また、Kinesis Video Streams にメディアをインジェストするためのクラウドゲートウェイを構築したら、 次のビデオ でビデオストリームで使用するローコードコンピュータビジョンアプリケーションの構築方法をご覧ください。 この記事は David Malone と Brian M. Slater によって書かれた Build a Cloud Gateway to Ingest RTSP video to Amazon Kinesis Video Streams の日本語訳です。この記事は IoT Solution Architect の井上が翻訳しました。 <!-- '"` -->
Community AWS re:invent 2023 re:caps が継続! 最近、 AWS User Group Kenya がホストするこれらのイベントの 1 つに招待され、この素晴らしいコミュニティで学び、時間を過ごすことができました。 AWS ユーザーグループケニア 2月19日週のリリース 2月19日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS Lambda 用 .NET 8 ランタイム – AWS Lambda は、マネージドランタイムとコンテナベースイメージの両方として .NET 8 をサポートするようになりました。このサポートにより、API の強化、Native Ahead of Time (Native AOT) サポートの改善、およびパフォーマンスの向上を含む .NET 8 の機能が提供されます。.NET 8 は、C# 12、F# 8、PowerShell 7.4 をサポートしています。 AWS Toolkit for Visual Studio 、AWS Extensions for .NET CLI、 AWS サーバーレスアプリケーションモデル (AWS SAM)、 AWS CDK 、およびその他の Infrastructure as Code を使用して、.NET 8 で Lambda 関数を開発できます。 AWS からの発表の完全なリストについては、 「AWS の最新情報」ページ をご覧ください。 AWS のその他のニュース 皆さんの好奇心をくすぐると思われるその他のプロジェクト、プログラム、ニュースをいくつかご紹介します。 2月初め、私はこの画像を使って、 現在進行中の PartyRock ハッカソン に人々の注目を集めることができました。ハッカソンへの参加期限が間近に迫っているので、時間がなくなる前に必ずサインアップしてください。 Amazon API Gateway – 2023 年に Amazon API Gateway は 100 兆件を超える API リクエストを処理しましたが、API 駆動型アプリケーションに対する需要は引き続き高まっています。API Gateway は、あらゆる規模の API を簡単に作成、公開、保守、モニタリング、保護できるようにするフルマネージド型サービスです。2023 年に API Gateway で大規模なワークロードをオンボーディングしたお客様から、その可用性、セキュリティ、サーバーレスアーキテクチャを理由にこのサービスを選んだとの声がありました。規制対象の業界では、パブリックインターネットから分離され、 Amazon 仮想プライベートクラウド (VPC) からのみアクセス可能な API Gateway のプライベートエンドポイントが高く評価されています。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。 近日開催される AWS イベント Build on Generative AI Twitch ショー のシーズン 3 が始まりました。 毎週月曜日の午前 9 時 (太平洋標準時)/正午 (東部標準時)/18 時 (中央ヨーロッパ標準時 ) に Twitch で参加して 、 生成 AI 対応アプリケーションの構築 方法などを学びましょう。 EMEA タイムゾーンにお住まいの場合は、登録して 2 月 29 日に開催される AWS Innovate Online 生成 AI & データエディション を視聴する時間がまだあります。Innovate Online イベントは無料のオンラインイベントで、AWS での構築に関するインスピレーションを得て、知識を深めてもらうことを目的としています。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA 地域のいずれであるかにかかわらず、 お客様のタイムゾーンで今後開催される AWS Innovate Online イベントについては、こちらをご覧ください 。 AWS コミュニティ re:Invent re:Cap – 世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent からの最新の発表について学びましょう。 こちらで、 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます 。 2月26日週のニュースは以上です。3月4日週に次回 Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。
2月26日、メキシコの AWS リージョンへの取り組みについてお知らせできることを嬉しく思います。この AWS メキシコ (中部) リージョンは、AWS 南米 (サンパウロ) リージョンに南米の第 2 のリージョンとなり、AWS のお客様は、国内に留めておく必要のあるワークロードやデータの実行と保存を行うことができるようになります。 メキシコでの作業 このリージョンには 3 つのアベイラビリティーゾーン (AZ) が含まれます。それぞれの AZ はリージョン内の他のゾーンから物理的に独立していますが、AZ レベルのイベントがビジネス継続性にもたらすリスクを最小限に抑えるのに十分な距離が維持されています。これらのアベイラビリティゾーンは、完全冗長の専用ファイバーを介した高帯域幅、低レイテンシーのネットワーク接続によって相互に接続されます。 この発表を含め、AWS では、現在 5 つの新しいリージョン (ドイツ、マレーシア、メキシコ、ニュージーランド、タイ) と 15 の新しいアベイラビリティーゾーンを準備しています。 メキシコでの AWS の投資 近々予定されている AWS メキシコリージョンは、高度で安全なクラウドテクノロジーをお客様に提供するために AWS がメキシコで行っている最新の投資です。2020 年以降、AWS はメキシコに 7 つの Amazon CloudFront エッジロケーションを立ち上げました。データ、動画、アプリケーション、API を世界中のユーザーに低レイテンシーおよび高速転送速度で配信する Amazon CloudFront は、高度にセキュアでプログラム可能なコンテンツ配信ネットワーク (CDN) です。 2020 年には、AWS はメキシコで AWS Outposts を立ち上げました。AWS Outposts は、ほぼすべてのオンプレミスまたはエッジロケーションに AWS インフラストラクチャとサービスを提供するフルマネージドソリューションのファミリーで、真に一貫したハイブリッドエクスペリエンスを実現します。AWS は、2023 年に AWS Local Zones をケレタロで立ち上げ、メキシコにおけるインフラストラクチャフットプリントを再度拡張しました。AWS Local Zones は、コンピューティング、ストレージ、データベース、およびその他の一部のサービスを人口密集地、業界、IT センターの近くに配置する AWS インフラストラクチャデプロイの一種で、お客様はミリ秒単位 (1 桁) のレイテンシーを必要とするアプリケーションをエンドユーザーに配信できます。2023 年、AWS は AWS Direct Connect ロケーションをケレタロに設立し、お客様は、AWS と自身のデータセンター、オフィス、またはコロケーション環境の間でプライベート接続を確立できるようになりました。 ここでは、メキシコのお客様、そしてお客様が取り組んでいるエキサイティングで革新的な作業をご紹介します。 Banco Santander Mexico は、商業銀行と証券金融にフォーカスする国内有数の金融グループであり、2,050 万人以上の顧客にサービスを提供しています。「AWS は当社のデジタルトランスフォーメーションの戦略的パートナーです」と北米の IT インフラストラクチャ責任者である Juan Pablo Chiappari 氏は語ります。「AWS の幅広いサービスのおかげで、私たちはより迅速にイノベーションを起こし、顧客体験を向上させ、運用コストを削減することができました」。 SkyAlert は、地震が発生しやすい地域に住む多くの人々に迅速に警告し、自然災害防止の文化を促進する革新的なテクノロジー企業です。地震の際に身を守るための適切なツールを企業や個人の顧客に提供するために、SkyAlert は自社のインフラストラクチャを AWS に移行しました。AWS 上で稼働するモノのインターネット (IoT) ソリューションとその効率的なアラートサービスを実装した結果、SkyAlert はすばやくスケールして数百万通のメッセージを数秒で送信できるようになり、地震発生時の人命救助に貢献しています。 Kueski は、メキシコとラテンアメリカの中産階級向けのオンライン融資企業です。同社はビッグデータと高度な分析を活用して、わずか数分で融資の承認と提供を行っています。同種のプラットフォームとして、同社は、地域で最速の成長を遂げていて、既に数千件の融資を行っています。同社は AWS と共に生まれました。 ナスダックが支援する Bolsa Institucional de Valores (BIVA) メキシコを拠点とする証券取引所です。BIVA は、国内外の投資家向けに取引および市場ソリューションのための最先端技術を提供し、企業に上場および保守サービスを提供しています。BIVA は、低レイテンシーのニーズを実現するために、イノベーションのビジョンの一環として、取引および市場監視システムを含むディザスタリカバリサイトを AWS に移行し、メキシコのケレタロにある AWS Local Zones で利用可能なエッジコンピューティング機能を使用することによってクラウドへの移行を 2023 年に開始しました。 ご期待下さい! メキシコの AWS リージョンは 2025 年初頭に提供開始の予定です。いつものように、このブログをサブスクライブすると、新しいリージョンがいつオープンするかをいち早く知ることができます！ AWS グローバルクラウドインフラストラクチャの詳細については、 グローバルインフラストラクチャのページ を参照してください。 – Irshad 原文は こちら です。
フランスに本拠を置く AI 企業である Mistral AI は、公開されているモデルを最先端のパフォーマンスに高めるというミッションを掲げています。同社は、チャットボットからコード生成まで、さまざまなタスクに使用できる高速かつ安全な大規模言語モデル (LLM) の作成を専門としています。 2 つの高性能 Mistral AI モデルである Mistral 7B と Mixtral 8x7B がまもなく Amazon Bedrock で利用可能になることをお知らせします。AWS は、 AI21 Labs 、 Anthropic 、 Cohere 、 Meta 、 Stability AI 、 Amazon などの他の大手 AI 企業と並ぶ 7 番目の基盤モデルプロバイダーとして Mistral AI を Amazon Bedrock で利用できるようにします。これらの 2 つの Mistral AI モデルを使用すると、Amazon Bedrock を利用して生成 AI アプリケーションを構築およびスケールするためのユースケースに最適な高性能 LLM を柔軟に選択できます。 Mistral AI モデルの概要 非常に期待されているこれらの 2 つの Mistral AI モデルの概要を次に示します。 Mistral 7B は、Mistral AI の最初の基盤モデルであり、自然なコーディング機能で英語のテキスト生成タスクをサポートします。低レイテンシーを実現するために最適化されており、サイズの割にメモリ要件は低く、スループットは大きいです。このモデルは強力で、テキストの要約や分類から、テキスト補完やコード補完まで、さまざまなユースケースをサポートします。 Mixtral 8x7B は、テキストの要約、質疑応答、テキストの分類、テキスト補完、コード生成に最適な、人気のある高品質の Sparse Mixture-of-Experts (MoE) モデルです。 適切な基盤モデルを選択することが、成功を収めるアプリケーションを構築するための鍵となります。Mistral AI モデルがお客様のユースケースに適している理由を示すいくつかの利点を見てみましょう。 コストとパフォーマンスのバランス – Mistral AI モデルの顕著な利点の 1 つは、コストとパフォーマンスの驚くべきバランスが実現されているということです。Sparse MoE を使用することで、コストをコントロールしながら、これらのモデルを効率的かつスケーラブルにして、手頃な料金で利用できるようになります。 高速な推論速度 – Mistral AI モデルの推論速度は非常に高速で、低レイテンシーを実現するために最適化されています。また、このモデルは、サイズの割にメモリ要件は低く、スループットは大きいです。この機能は、本番ユースケースをスケールする場合に最も重要です。 透明性と信頼性 – Mistral AI モデルは透明性が高く、カスタマイズ可能です。これにより、組織は厳しい規制要件を満たすことができます。 幅広いユーザーがアクセス可能 – Mistral AI モデルには誰でもアクセスできます。これは、あらゆる規模の組織が生成 AI 機能をアプリケーションに統合するのに役立ちます。 近日リリース予定 Mistral AI の一般公開モデルが間もなく Amazon Bedrock で利用可能になります。いつものように、このブログをサブスクライブしていただくことで、これらのモデルが Amazon Bedrock でいつ利用可能になるのかを誰よりも早く知ることができます。 詳細はこちら Amazon Bedrock 製品ページの Mistral AI 引き続きご期待ください。 – Donnie 原文は こちら です。
Amazon Bedrockの基盤モデルの一つであるClaude 2.1が東京リージョンでアクセスできるようになりましたので報告します。 Claude 2.1は200,000トークンのコンテキストウィンドウ 、幻覚（ハルシネーション）発生率の低減、長い文書の精度の向上、システムプロンプト、関数呼び出しとワークフローオーケストレーションのためのベータツール使用機能など、企業向けの主要な機能を提供します。 Amazon Bedrock ユーザガイド 上で、東京リージョンでClaude 2.1がサポートされていることが確認できます。日本国内からClaude 2.1をご利用のお客様の場合、東京リージョンを利用することで海外リージョンのモデルにアクセスするよりもレイテンシの改善が期待されます。 実際にコンソール上で確認していきます。東京リージョンでAmazon Bedrockのモデルアクセスタブにアクセスし、”Claude”にチェックを入れ変更を保存します。 プロバイダータブにClaude 2.1モデルが表示されていることが確認できました。 続いてプレイグラウンドのチャット機能からClaude 2.1を選択します。 東京リージョンでClaude 2.1モデルにアクセスできました！ APIからも同様にアクセスすることが可能です。 Amazon Bedrockの詳細については ユーザガイド をご参照ください。 機械学習ソリューションアーキテクト 卜部
このブログ記事では、AWS Outposts ラックを複数のワークロードで利用する際の Amazon Elastic Compute Cloud (Amazon EC2) のキャパシティプランニングと、その管理の方法を紹介します。これにより、お客様は Outposts ラック上で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts ラックのリソースを利用できます。 株式会社野村総合研究所では、 このキャパシティ管理戦略を用いて、Outposts で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts のリソースを利用しています。 AWS Outposts の特徴 Outposts は、フルマネージド型の AWS インフラストラクチャ、ネイティブな AWS のサービス、API、およびツールを、お客様のオンプレミス施設で提供します。これにより、今までクラウドへの移行が困難であった低遅延ネットワーク要件のワークロードや、特定のロケーションでデータを保存する、データレジデンシーの要件があるワークロードを稼働させることができます。Outpostsは、オンプレミスのインフラストラクチャの調達、管理、アップグレードのために必要なお客様の作業を取り除きます。 AWS Outposts ラックの注文 Outposts ラックを注文する際は、Amazon EC2 のインスタンスタイプのうち、汎用 (M5)、コンピューティング最適化(C5)、高速コンピューティング (G4dn)、メモリ最適化 (R5)、ストレージ最適化 (I3en) の中から、必要なインスタンス数を算出し、それに見合った Outposts ラック上のサーバーの台数を指定して注文します。サーバー1台は、24xlarge のインスタンスサイズに相当します。 AWS Outposts のキャパシティプランニング Outposts は、物理的に接続された 1 つ以上の Outposts ラックを 1 つの論理 Outpost (以下 Outpost) として管理できます。これにより、コンピューティング容量とストレージ容量のプールを提供します。 Outpost は、単一の目的のワークロードだけでなく、特性の異なる複数のワークロードを集約することができます。Outposts 活用のユースケースとして、オンプレミスのリソースとの低遅延接続、データレジデンシーに留まらず、その周辺ワークロードを含めた、ハイブリッドワークロードにおける中継環境、クラウドへの段階的移行のための環境など、複数のニーズに応えることができます。 AWS リージョンにおける Amazon EC2 の容量は限りがないように見えますが、Outpost の容量には限りがあり、注文したコンピューティング容量の合計によって制約されます。 Outpost で高可用性の設計とする場合、N+M 可用性モデルをサポートするのに十分なコンピューティングキャパシティを注文する必要があります。N は必要なサーバー数、M はサーバー障害に対応するためにプロビジョニングされたスペアサーバーの数です。N+1 と N+2 が最も一般的な可用性レベルです。 Outpost では、各サーバー (C5 、 M5 、 R5 など) は、単一ファミリーの Amazon EC2 インスタンスをサポートします。Amazon EC2 でインスタンスを起動する前に、各サーバーが提供する Amazon EC2 インスタンスサイズを指定するスロッティングレイアウトを準備する必要があります。スロッティングレイアウトの例として、m5.large インスタンスを 48 台起動できる単一インスタンスサイズのレイアウトや、m5.large が 4 台、m5.xlarge が 4 台、m5.2xlarge が 3 台、m5.4xlarge が 1 台、m5.8xlarge が 1 台起動できるサイズ混在のレイアウトが挙げられます。 Outpost で N + M 可用性モデルを実現するためには、各サーバーごとにスロッティングレイアウトを設定し、インスタンスサイズ別に Amazon EC2 の容量プールとして管理します。例えば、サーバーが 4 台あった場合、Amazon EC2 のキャパシティ容量は 4 × 24xlarge です。すべて m5.xlarge を割り当てた場合は合計 96 台の m5.xlarge インスタンスが起動ができます。ただし、全ての Amazon EC2 容量プールを消費する形でインスタンスを起動してしまうと、⼀つのサーバーで障害が発⽣した際に、別のサーバーでインスタンスを再起動することができなくなってしまいます。そのため、Amazon EC2 容量プールで N + M サーバーの可⽤性を考慮する場合は、容量プールの使⽤率が 100 % にならないように設計します。例えば N + 1 可用性の場合、4 台のサーバーの内、 1 台のサーバーを余剰リソースとして確保することになるため、実際に利用できる Amazon EC2 のキャパシティ容量は 3 × 24xlarge となります。 このような設計は、単一のワークロードや必要なリソース量の変化が激しくない場合には難しくはないと考えられます。しかし、複数のワークロードを Outpost で稼働させる場合、リソースへの要求が重複したり、他のワークロードが過剰にリソースを消費してしまう可能性を考慮しなくてはなりません。そこで、Outpost ではキャパシティ予約とリソース共有を使うことで、ワークロードごとのリソースを確保する仕組みを作る事ができます。 Outpost でのキャパシティ予約とリソース共有 AWS Organizations を利用すると、1 つの Outpost のリソースを複数の AWS アカウントで利用することができます。Outpost のオーナーアカウントである Organizations の管理アカウントと、メンバーアカウントの間で、Outpost のリソースを共有できます。Organizations の管理アカウントでは、Outpost でのキャパシティ予約を利用して、メンバーアカウントに配分するリソースのプールを作成します。 この Outpost でのキャパシティ予約を、リソース共有機能を使って、Organizations のメンバーアカウントに割り振ることができます。これにより、特定の AWS アカウントで意図しない Amazon EC2 インスタンスの過剰な消費が発生しても、該当のワークロードで割り当てているキャパシティ予約済みのリソースを保護できます。 Outpost オーナーアカウントである Organizations 管理アカウントで、Outpost 上の全てのリソースのキャパシティ予約を作成すれば、共有先のメンバーアカウントでは一切割り当てた分以上のインスタンスを起動させない、厳密な管理も可能です。しかし、リソース割り当て量を増減したり、キャパシティ予約では管理されない Elastic Load Balancing (ELB) や Amazon Relational Database Service (Amazon RDS) のインスタンスを起動したい場合は、その都度全てのキャパシティ予約を変更する必要があり、運用が煩雑になります。そのため、メンバーアカウントに割り当てるキャパシティ予約は本番環境のみとしたり、最低限確保したい容量のみとして、予約されないリソースをバッファとして用意しておくこともできます。その場合、意図しないリソース消費が発生した際は、そのバッファ分の Amazon EC2 インスタンスは起動できるため、これを Amazon CloudWatch で監視するといった工夫をすることも必要でしょう。 このように、Outpost 全体のキャパシティへの影響の考慮が必要なユースケースとして、例えば本番環境と開発環境を同じ Outpost 上に展開しても、ワークロードごとの影響を抑えることができます。 本ブログの著者について Yuki Taniguchi Yuki は AWS のソリューションアーキテクトとして、日本の金融業界を担当しています。2011年から銀行システムの設計・開発・プロジェクトマネジメントに携わる。2019年から現職。
2024年2月に、アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス17階にある AWS Startup Loft の一角に AWS Outposts servers lab Tokyo がオープンしました。 これによりお客様やパートナー様が AWS Outposts サーバー の実機をご覧いただけるだけで無く、自社のアプリケーションや自社製品をテストすることも可能になりました。 AWS Outposts サーバーを発注する前のフィジビリティスタディや使用感の確認、運用方法の検討等にご利用いただけます。 現在ラボには AWS Outposts サーバーの 2U モデル（インテル社製 CPU 搭載モデル）と 1U モデル（AWS Graviton2 搭載モデル）が各1台設置してあります。 AWS のマネジメントコンソールをからこの環境を操作して、ワークロードを構築し、検証することが可能です。 設置されているAWS Outpostsサーバー1Uおよび2Uの写真 また AWS Outposts の特徴であるオンプレミスネットワークとのダイレクトな接続も体験いただけます。 こちらのラボでは、利用者が持ち込んだ機器を LAN 経由で Outpost サーバーと接続することで、実際の利用シーンに即したテストなど様々な検証を行うことが可能です。 例としては図1のような構成でテストが可能です。 図1 アクセス遅延の比較検証 この環境ではオンプレミスの LAN 上に存在する機器 Outpost サーバー上に作られたワークロードが直接通信するようなシステム環境を再現することができます。 実際にお客様がお持ちの IoT 機器やセンサー等のデータをオンプレミスにあるワークロードで処理することで効率的なシステムが構築可能かどうかを実体験することができます。 もちろん AWS データセンターで提供される AWS の様々なマネージドサービスとのシームレスな連携もテストすることが可能です。 ラボの利用に当たっては、営業担当に連絡していただくか、 こちら から AWS Outposts のスペシャリストへ直接コンタクトしてください。 是非この機会に、皆様がお持ちのワークロードを AWS Outposts サーバー上で稼動させることを検討してみませんか？ 検証を行うことで製品を AWS Outposts servers Ready な状態にすることが可能です。是非ご利用お待ちしております。
生成 AI は組織の想像力をかき立て、世界中のあらゆる規模の業界で顧客体験を変革しています。数十億パラメーターの大規模言語モデル (LLM) とトランスフォーマーによって促進された AI 機能の飛躍的な進歩により、新たな生産性の向上や創造的な能力などへの扉を開きました (訳者注 : トランスフォーマーについては以降本記事では扱いませんが、詳しく知りたい方は、 人工知能におけるトランスフォーマーとは何ですか? をご確認ください) 。 組織が従業員や顧客のために生成 AI を評価して採用するにあたり、サイバーセキュリティ担当者は、この進化するテクノロジーのリスク、ガバナンス、コントロールを迅速に評価する必要があります。アマゾン ウェブ サービス (AWS) の最大かつ最も複雑な顧客を扱うセキュリティリーダーとして、私たちは生成 AI のトレンド、ベストプラクティス、急速に進化する生成 AI の状況、および関連するセキュリティとプライバシーへの影響について定期的に相談を受けています。その精神のもと、生成 AI セキュリティへの取り組みを加速させるために利用できる主要な戦略を紹介したいと思います。 この記事は、生成 AI のセキュリティ保護に関するシリーズの第 1 回目であり、導入する生成 AI ワークロードのタイプに基づいて、リスクとセキュリティの影響へのアプローチに役立つメンタルモデルを確立します。そして、生成 AI ワークロードを保護する際にセキュリティリーダーと実務者が優先すべき重要な考慮事項について説明します。続く記事では、顧客のセキュリティ要件を満たす生成 AI ソリューションの開発、生成 AI アプリケーションの脅威モデリングのベストプラクティス、コンプライアンスとプライバシーに関する考慮事項を評価するためのアプローチについて詳しく説明し、生成 AI を使用して自社のサイバーセキュリティ運用を改善する方法を探ります。 どこから始めるか あらゆる新しいテクノロジーと同様に、関連する範囲、リスク、セキュリティ、コンプライアンス要件を理解するには、そのテクノロジーの基礎をしっかりと理解することが重要です。生成 AI の基礎について詳しく知るには、まず 生成 AI とは何か 、その独特の用語やニュアンスについて学び、 組織が顧客にイノベーションを起こすためにどのように生成 AI を活用しているのか事例 を調べることから始めることをお勧めします。 生成 AI の調査や採用を始めたばかりの方は、まったく新しいセキュリティの規律が必要になることを想像するかもしれません。セキュリティに関する独自の考慮事項はありますが、幸いなことに、生成 AI ワークロードは、本質的にはデータ駆動型コンピューティングワークロードの一つであり、同じセキュリティ対策の多くを継承しています。実際に、長年にわたってクラウドサイバーセキュリティのベストプラクティスに投資したり、 Top 10 security items to improve in your AWS account 、 AWS Well-Architected Framework のセキュリティの柱 、 AWS Well-Architected Framework Machine Learning Lens などの情報源からの規範的なアドバイスを取り入れてきているのであれば、順調に進んでいると言えるでしょう。 ID とアクセス管理、データ保護、プライバシーとコンプライアンス、アプリケーションセキュリティ、脅威モデリングなどの中核的なセキュリティ領域は、他のワークロードと同様に、生成 AI ワークロードにとっても依然として非常に重要です。たとえば、生成 AI アプリケーションがデータベースにアクセスする場合、データベースのデータ分類とは何か、そのデータを保護する方法、脅威を監視する方法、アクセスを管理する方法を知る必要があります。しかし、長年にわたるセキュリティプラクティスを強調するだけでなく、生成 AI ワークロードがもたらす固有のリスクと追加のセキュリティ上の考慮事項を理解することが重要です。この記事では、新しいものからよく馴染みのあるものまで、考慮すべきセキュリティ要素について説明します。 これを念頭に置いて、最初のステップであるスコーピングについて説明しましょう。 スコープの決定 あなたの組織は、生成 AI ソリューションの推進を決定しました。では、セキュリティリーダーまたはセキュリティ実務者として何をすべきでしょうか？どのようなセキュリティ対策でもそうであるように、セキュリティ保護の範囲を理解する必要があります。ユースケースに応じて、サービスプロバイダーがサービスとモデルの管理に対してより多くの責任を負うマネージドサービスを選択するか、独自のサービスとモデルを構築するかを選択できます。 AWS クラウドでさまざまな生成 AI ソリューションをどのように使用できるかを見てみましょう。AWS では、セキュリティは最優先事項であり、お客様に業務に適したツールを提供することが重要であると考えています。たとえば、AI21 Labs、Anthropic、Cohere、Meta、stability.ai、 Amazon Titan が提供する、使いやすい事前学習済みの基盤モデル (FM) をサーバーレスで API 駆動の Amazon Bedrock で使用できます。 Amazon SageMaker JumpStart では、事前学習済みの FM を使用しながらもさらなる柔軟性を提供し、AI ジャーニーを安全に加速できます。 Amazon SageMaker で独自のモデルを構築してトレーニングすることもできます。チャットボットなどの Web インターフェースや API を介してコンシューマー向けの生成 AI アプリケーションを利用したり、組織で調達した商用のエンタープライズアプリケーションへ生成 AI 機能を組み込むなどの予定があるかもしれません。これらのサービスはそれぞれ、インフラストラクチャ、ソフトウェア、アクセス、データモデルが異なるため、セキュリティに関する考慮事項も異なります。一貫性を確立するために、これらのサービスを論理的に分類し、「スコープ」と名付けました。 セキュリティスコーピングの取り組みを簡素化するために、選択する生成 AI ソリューションに応じて考慮すべき主要なセキュリティ領域をまとめたマトリックスを作成しました。これを生成 AI セキュリティスコーピングマトリックスと呼んでいます (図 1 参照) 。 図 1 : 生成 AI セキュリティスコーピングマトリックス 最初のステップは、ユースケースがどのスコープに収まるかを判断することです。スコープには 1 ～ 5 の番号が付けられており、所有権が最も小さいものから大きいものまでが示されています。 生成 AI の購入利用 : スコープ 1 : コンシューマーアプリ — あなたのビジネスは、無料または有料で、パブリックなサードパーティの生成 AI のサービスを利用しています。このスコープでは、トレーニングデータやモデルを所有したり表示したりすることはできず、変更や拡張もできません。プロバイダーの利用規約に従って、API を呼び出すか、アプリケーションを直接使用します。 例 : ある従業員が生成 AI チャットアプリケーションを操作して、今後のマーケティングキャンペーンのアイデアを生み出します。 スコープ 2 : エンタープライズアプリ — あなたのビジネスは、生成 AI 機能が組み込まれたサードパーティのエンタープライズアプリケーションを使用しており、組織とベンダーの間にビジネス関係が確立されています。 例 : 会議の議題の作成に役立つ生成 AI 機能が組み込まれたサードパーティのエンタープライズスケジューリングアプリケーションを使用します。 生成 AI の構築 : スコープ 3 : 事前学習済みのモデル — あなたのビジネスは、既存のサードパーティの生成 AI 基盤モデルを使用して独自のアプリケーションを構築します。API を介してワークロードと直接統合します。 例 : Amazon Bedrock API による Anthropic Claude 基盤モデルを使用するカスタマーサポートチャットボットを作成するアプリケーションを構築します。 スコープ 4 : ファインチューニングされたモデル — あなたのビジネスは、ビジネス特有のデータを使用して既存のサードパーティ生成 AI 基盤モデルをファインチューニングし、ワークロードに特化して新しく拡張されたモデルを生成することで、ビジネスにさらに磨きをかけています。 例 : API を使用して基盤モデルにアクセスし、マーケティングチームが製品やサービス固有のマーケティング資料を作成できるようにするアプリケーションを構築します。 スコープ 5 : 自身でトレーニングしたモデル — あなたのビジネスは、所有しているまたは取得したデータを使用して、生成 AI モデルをゼロから構築し、トレーニングします。あなたはモデルのあらゆる側面を所有しています。 例 : 業界特有の深いデータのみに基づいてトレーニングされたモデルを作成し、その業界の企業にライセンスを供与して、まったく新しい LLM を作成したいと考えています。 生成 AI セキュリティスコーピングマトリックスでは、さまざまなタイプの生成 AI ソリューションにまたがる 5 つのセキュリティ領域を特定しています。各セキュリティ領域の固有の要件は、生成 AI アプリケーションのスコープによって異なる場合があります。どの生成 AI スコープが導入されているかを判断することで、セキュリティチームは迅速にフォーカスの優先順位を決め、各セキュリティ領域の範囲を評価できます。 それぞれのセキュリティ領域を調べて、スコーピングがセキュリティ要件にどのように影響するかを考えてみましょう。 ガバナンスとコンプライアンス — リスクを最小限に抑えながらビジネスを強化するために必要なポリシー、手順、報告。 法律とプライバシー — 生成 AI ソリューションを使用または作成するための特定の規制、法律、およびプライバシー要件。 リスク管理 — 生成 AI ソリューションに対する潜在的な脅威と推奨される緩和策の特定。 コントロール — リスクを軽減するために使用されるセキュリティコントロールの実装。 レジリエンス — 可用性を維持しビジネスの SLA を満たす生成 AI ソリューションを設計する方法。 「生成 AI をセキュアにする」ブログシリーズでは、生成 AI セキュリティスコーピングマトリックスを参考にして、AI 導入の範囲に応じてさまざまなセキュリティ要件と推奨事項がどのように変化するかを理解しやすくしています。調達、評価、セキュリティアーキテクチャのスコーピングなどの社内プロセスで、生成 AI セキュリティスコーピングマトリックスを採用して参照することをお勧めします。 何を優先すべきか ワークロードのスコープが特定されたので、今こそビジネスを迅速かつ安全に前進させる必要があります。優先すべき機会の例をいくつか見てみましょう。 ガバナンスとコンプライアンス、法律とプライバシー 図 2 : ガバナンスとコンプライアンス コンシューマー向け市販アプリ (スコープ 1) とエンタープライズ向け市販アプリ (スコープ 2) では、利用規約、ライセンス、データ主権、その他の法的開示に特に注意する必要があります。組織のデータ管理要件に関する重要な考慮事項を概説し、組織に法務部門と調達部門がある場合は、必ずそれらの部門と緊密に連携してください。これらの要件がスコープ 1 または 2 のアプリケーションにどのように適用されるかを評価してください。データガバナンスは重要であり、既存の強力なデータガバナンス戦略を活用して、生成 AI ワークロードに拡張することができます。組織のリスクアペタイトとスコープ 1 とスコープ 2 のアプリケーションで達成したいセキュリティ態勢の概要を説明し、適切なデータタイプとデータ分類のみを使用するように指定するポリシーを実装します。たとえば、スコープ 1 のアプリケーションを使用する際に、個人を特定できる情報 (PII)、機密データ、または専有データの使用を禁止するポリシーを作成することを選択できます。 サードパーティモデルに必要なデータと機能がすべて揃っている場合は、スコープ 1 とスコープ 2 のアプリケーションが要件を満たす可能性があります。ただし、自社のビジネスデータを集約、関連づけ、解析したり、新しい洞察を得たり、反復作業を自動化したりすることが重要な場合は、スコープ 3、4、または 5 のアプリケーションをデプロイする必要があります。たとえば、組織では事前学習されたモデルを使用することを選択するかもしれません (スコープ 3) 。さらに一歩進んで、組織のデータを含む Amazon Titan などのサードパーティモデルのバージョンを作成したいと思うかもしれません。これをファインチューニングと呼びます (スコープ 4) 。あるいは、提供したデータでトレーニングした、まったく新しいファーストパーティモデルをゼロから作成することもできます (スコープ 5) 。 スコープ 3、4、5 では、データをモデルのトレーニングやファインチューニングに使用したり、出力の一部として使用したりできます。ソリューションがアクセスできる資産のデータ分類とデータタイプを理解する必要があります。スコープ 3 のソリューションでは、たとえばプロンプトへの入力として、 Agents for Amazon Bedrock の支援を受けて 検索拡張生成 (RAG : Retrieval Augmented Generation) を通じて提供されたデータに対してフィルタリングメカニズムを使用する場合があります。RAG はクエリされたデータをプロンプトの一部として利用することにより、トレーニングやファインチューニングの代わりに使用できます。これにより、LLM のコンテキストが拡張され、ファインチューニングやトレーニングによってデータをモデル自体に直接埋め込むのではなく、ビジネスデータを応答の一部として使用できる生成と応答が提供されます。図 3 は、RAG による生成 AI のプロンプトと応答で顧客データをどのように使用できるかを示すデータフロー図の例です。 図 3 : 検索拡張生成 (RAG) 一方、スコープ 4 と 5 では、修正されたモデルを、モデルのファインチューニングやトレーニングに使用される最も機密性の高いレベルのデータ分類に分類する必要があります。モデルはトレーニング対象のデータのデータ分類を反映します。たとえば、モデルのファインチューニングまたはトレーニングに PII を提供した場合、新しいモデルには PII が含まれることになります。現在、承認に基づいてモデルの出力を簡単にフィルタリングするメカニズムはなく、ユーザーが他の方法では表示する権限がないデータを取得する可能性があります。これは重要なポイントです。モデルの周囲にアプリケーションを構築し、RAG データフローの一部としてビジネスデータにフィルタリング制御を実装できます。これにより、機密データをモデル内に直接配置することなく、データセキュリティの細分性を高めることができます。 図 4 : 法律とプライバシー 法的な観点から、サービスプロバイダーのエンドユーザー使用許諾契約 (EULA)、サービス条件 (TOS)、およびスコープ 1 から 4 でサービスを使用するために必要なその他の契約上の合意の全てを理解することが重要です。スコープ 5 については、法務チームがモデルの外部使用について独自の契約上の利用規約を定める必要があります。また、スコープ 3 とスコープ 4 については、サービスプロバイダーのサービス利用に関する法的条件と、そのサービス内でのモデルの利用に関するモデルプロバイダーの法的条件の両方を必ず確認してください。 さらに、 欧州連合 (EU) の一般データ保護規則 (GDPR) の「消去の権利」または「忘れられる権利」の要件がビジネスに適用される場合は、プライバシーに関する懸念も考慮してください。要求に応じて削除する必要のあるデータを使用してモデルをトレーニングまたはファインチューニングすることによる影響を慎重に検討してください。モデルからデータを削除する唯一の完全に効果的な方法は、トレーニング用データセットからデータを削除し、新しいバージョンのモデルをトレーニングすることです。データの削除がトレーニングデータ全体のほんの一部である場合、これは現実的ではなく、モデルのサイズによっては非常にコストがかかる可能性があります。 リスク管理 図 5 : リスク管理 AI 対応アプリケーションは AI 非対応アプリケーションのような振る舞い、見た目、使用感がありますが、LLM とのやりとりが自由形式であるため、さらなる精査とガードレールが必要になります。生成 AI ワークロードにはどのようなリスクが当てはまるか、またそれらを軽減するにはどうすればよいかを特定することが重要です。 リスクを特定する方法はたくさんありますが、一般的なメカニズムはリスク評価と脅威モデリングの 2 つです。スコープ 1 とスコープ 2 では、サードパーティプロバイダーのリスクを評価して、そのサービスから発生する可能性のあるリスクと、そのプロバイダーが責任を負うリスクをどのように軽減または管理するかを理解します。同様に、そのサービスの利用者としてのリスク管理責任が何であるかを理解する必要があります。 スコープ 3、4、5 については脅威モデリングを実装することです。特定の脅威と生成 AI アプリケーションの脅威モデリング手法については今後のブログ記事で詳しく説明しますが、LLM に固有の脅威の例を挙げてみましょう。脅威アクターは、プロンプトインジェクションなどの手法を使用する可能性があります。これは、LLMに予期しない、または望ましくない方法で応答させるために、慎重に作成された入力です。この脅威は、特徴量の抽出（特徴量とは、機械学習（ML）モデルのトレーニングに使用されるデータの特性または性質のこと）、名誉毀損、内部システムへのアクセスなどに使用できます。ここ数ヶ月、 NIST 、 MITRE 、 OWASP は、AI および LLM ソリューションのセキュリティ保護に関するガイダンスを公開しています。MITRE と OWASP が公開しているアプローチのどちらでも、最初に挙げられる脅威はプロンプトインジェクション（モデルへの回避攻撃）です。プロンプトインジェクションの脅威は新しいように聞こえるかもしれませんが、多くのサイバーセキュリティ専門家には馴染み深いものです。これは本質的に、SQL インジェクション、JSON または XML インジェクション、コマンドラインインジェクションなどのインジェクション攻撃を進化させたもので、多くの実務者が対処に慣れています。 生成 AI ワークロードの新たな脅威ベクトルは、脅威モデリングと全体的なリスク管理の実践に新たなフロンティアを生み出します。前述のように、既存のサイバーセキュリティ対策がここでも適用されますが、この分野特有の脅威を考慮して適応する必要があります。組織内で生成 AI アプリケーションを作成している開発チームやその他の主要な利害関係者と深く連携するには、微妙な違いを理解し、脅威を適切にモデル化し、ベストプラクティスを定義する必要があります。 コントロール 図 6 : コントロール コントロールは、リスクを軽減するためにコンプライアンス、ポリシー、およびセキュリティ要件を実施するのに役立ちます。優先順位の高いセキュリティコントロールの例である ID とアクセス管理について詳しく見ていきましょう。いくつかの背景を述べると、推論（入力に基づいて出力を生成するモデルのプロセス）の間、ファーストパーティまたはサードパーティの基盤モデル（スコープ 3 ～ 5 ）は不変です。モデルの API は入力を受け入れ、出力を返します。モデルはバージョン管理され、リリース後は静的です。モデル自体では、新しいデータを保存したり、時間の経過とともに結果を調整したり、外部データソースを直接組み込んだりすることはできません。モデルの外部にあるデータ処理機能の介入がなければ、モデルは新しいデータを保存したり変化したりしません。 最新のデータベースと基盤モデルのどちらにも、クエリを行うエンティティの ID を使用するという概念があります。従来のデータベースには、テーブルレベル、行レベル、列レベル、さらには要素レベルのセキュリティ制御があります。一方、基盤モデルでは、現在のところ、含まれている可能性のある特定のエンベディングにきめ細かくアクセスすることはできません。LLM におけるエンベディングとは、単語、音、グラフィックなどの各オブジェクトを表現するためにモデルがトレーニング中に作成する数学的表現であり、オブジェクトのコンテキストや他のオブジェクトとの関係を説明するのに役立ちます。エンティティは、モデル全体とそれが生成する推論へのアクセスを許可されるか、まったくアクセスできないかのどちらかです。つまり、従来のデータベースでは、各エンティティが行、列、テーブル、またはセルレベルでデータベース内のどのデータにアクセスできるか制御できる一方で、現世代の FM では、学習データのエンべディングが一度モデルに組み込まれると、どのオブジェクト由来のエンべディングであるかを区別してアクセス制御することはできないということです（訳者注 : 原文ではベクトルデータベース内の特定のエンベディングに関する記載がありますが、こちらの翻訳では執筆者に意図を確認し補足説明を加えた内容を記載しています）。言い換えると、今日のテクノロジーでは、エンティティにモデルへの直接アクセス権を付与すると、そのモデルがトレーニングされたデータすべてに対する権限をエンティティに付与することになります。アクセス時には、情報は 2 つの方向に流れます。プロンプトとコンテキストがユーザーからアプリケーションを介してモデルに流れ、生成された出力がモデルからアプリケーションに戻ってユーザーに推論応答を提供します。モデルへのアクセスを許可すると、これらのデータフローの両方の実行を暗黙的に承認することになり、これらのデータフローのどちらかまたは両方に機密データが含まれる可能性があります。 たとえば、あなたのビジネスが Amazon Bedrock 上でアプリケーションを構築したとします。スコープ 4 では基盤モデルをファインチューニングし、スコープ 5 では独自のビジネスデータに基づいてモデルをトレーニングしたとします。 AWS Identity and Access Management (IAM) ポリシーは、特定のモデルを呼び出す権限をアプリケーションに付与します。ポリシーでは、モデル内のデータのサブセットへのアクセスを制限することはできません。IAM では、モデルを直接操作する場合、モデルへのアクセスに制限されます。 { "Version": "2012-10-17", "Statement": { "Sid": "AllowInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": "arn:aws:bedrock:*:: <foundation-model> / <model-id-of-model-to-allow> } } この場合、最小権限を実装するにはどうすればよいでしょうか。ほとんどのシナリオでは、アプリケーションレイヤーが Amazon Bedrock エンドポイントを呼び出してモデルと対話します。このフロントエンドアプリケーションでは、 Amazon Cognito や AWS IAM Identity Center などの ID ソリューションを使用してユーザーを認証および承認し、ロール、属性、ユーザーコミュニティに基づいて特定のアクションと特定のデータへのアクセスを適宜制限できます。たとえば、アプリケーションはユーザーの権限に基づいてモデルを選択できます。あるいは、アプリケーションが Amazon Kendra や Amazon OpenSearch Serverless などのサービスを使って、外部データソースにクエリを実行して、生成的な AI レスポンス用のジャストインタイムデータを提供することで RAG を使用する場合もあります。その場合は、認可レイヤーを使用して、ユーザーの役割と資格に基づいて特定のコンテンツへのアクセスをフィルタリングします。ご覧のように、ID とアクセス管理の原則は組織が開発する他のアプリケーションと同じですが、生成 AI ワークロードの固有の機能とアーキテクチャ上の考慮事項を考慮する必要があります。 レジリエンス 図 7 : レジリエンス 最後に、 CIA のトライアド で指摘されているように、可用性はセキュリティの重要な要素です。レジリエントなアプリケーションを構築することは、組織の可用性と事業継続性の要件を満たすために不可欠です。スコープ 1 とスコープ 2 については、プロバイダーの可用性が組織のニーズと期待にどのように合っているかを理解する必要があります。基盤となるモデル、API、またはプレゼンテーション層が利用できなくなった場合の混乱が、ビジネスにどのような影響を与える可能性があるかを慎重に検討してください。さらに、複雑なプロンプトや生成された出力がクォータの使用量にどのように影響するか、またはアプリケーションの課金にどのような影響を与えるかを検討してください。 スコープ 3、4、5 では、複雑なプロンプトやコンプリーションを考慮して適切なタイムアウトを設定してください。また、モデルで定義されている割り当てられた文字制限のプロンプト入力サイズを確認することもできます。また、期待するユーザーエクスペリエンスを実現するために、 バックオフや再試行 、 サーキットブレーカーのパターン など、レジリエントな設計に関する既存のベストプラクティスを検討してください。ベクトルデータベースを使用する場合、さまざまな障害モードに対する回復力を高めるために、高可用性構成と災害復旧計画を立てることをお勧めします。 推論モデルパイプラインとトレーニングモデルパイプラインの両方におけるインスタンスの柔軟性は、きわめてクリティカルなワークロードのためにコンピューティングを確保したり事前にプロビジョニングしたりすることに加えて、アーキテクチャ上の重要な考慮事項です。Amazon Bedrock や SageMaker などのマネージドサービスを使用する場合、マルチリージョンデプロイ戦略を実装する際には、AWS リージョンの可用性と機能の同等性を検証する必要があります。同様に、スコープ 4 と 5 のワークロードをマルチリージョンでサポートする場合、リージョン全体でファインチューニング用データまたはトレーニング用データが利用できることを考慮する必要があります。SageMaker を使用してスコープ 5 のモデルをトレーニングする場合は、 チェックポイント を使用してモデルをトレーニングしながら進行状況を保存してください。これにより、必要に応じて最後に保存したチェックポイントからトレーニングを再開できます。 AWS Resilience Hub および Well Architected Framework の「 信頼性の柱 」と「 オペレーショナルエクセレンスの柱 」で確立されている、既存のアプリケーションレジリエンスのベストプラクティスを必ず確認して実装してください。 結論 この記事では、確立されたクラウドセキュリティの原則が、生成 AI ソリューションを保護するための強固な基盤をどのように提供するかを概説しました。既存のセキュリティ手法やパターンの多くを使用しますが、生成 AI の基礎と、対処しなければならない独自の脅威とセキュリティ上の考慮事項についても学ぶ必要があります。生成 AI のセキュリティスコーピングマトリックスを使用すると、生成 AI ワークロードの範囲と、適用される関連するセキュリティ範囲を判断するのに役立ちます。対象範囲が決まったら、重要なセキュリティ要件の解決に優先順位を付け、ビジネスで生成 AI ワークロードを安全に使用できるようにします。 「生成 AI をセキュアにする」シリーズの今後の記事では、これらのトピックやその他のセキュリティトピックを引き続き探っていきますので、是非ご覧ください。 この記事についてご質問がある場合は、 AWS サポートにお問い合わせください 。 著者について Matt Saner Matt は AWS のセキュリティスペシャリストを率いるシニアマネージャーです。彼と彼のチームは、世界最大かつ最も複雑な組織が重大なセキュリティ課題を解決するのを支援し、セキュリティチームがビジネスのイネーブラーになるのを支援しています。AWS に入社する前、Matt はファイナンスサービス業界で 20 年近く働き、テクノロジー、セキュリティ、リスク、コンプライアンスのさまざまな課題を解決してきました。彼は生涯学習（セキュリティは決して静的ではない）を重視し、ニューヨーク大学でサイバーセキュリティの修士号を取得しています。おもしろいことに、彼は一般航空機の操縦を楽しむパイロットでもあります。 Mike Lapidakis Mike はセキュリティとコンプライアンス、移行とモダナイゼーション、ネットワーキング、レジリエンスの各ドメインで構成される AWS インダストリースペシャリスト SA チームを率いています。このチームは、技術的支援、教育、顧客支援、経営陣との連携を通じて、地球上で最大の顧客がビジネスを変革するための強固な基盤を確立できるよう支援しています。Mike は、10 年以上にわたり、さまざまなアーキテクチャやコンサルティングの役割において、組織のクラウド上でのモダナイゼーションを支援してきました。 翻訳はプロフェッショナルサービス本部の藤浦が担当しました。 原文はこちら です。 「AWS Security and Risk Management Forum ～レジリエントな未来：生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント～」 のご案内 2024 年 3 月 19 日に東京にて表題のイベントが開催されます。本イベントでは、生成 AI の活用やクラウドの活用の最新動向および生成 AI の押さえるべきポイント、AWS 内の取り組みについて米国セキュリティ部門のディレクターが直接解説します。また、有識者や外部ゲストを迎え、クラウドにおけるセキュリティ、リスクマネジメントに焦点を当てた各種対策を具体的に解説します。ご希望の方は、 こちらから ご登録をお願いいたします。
画像や動画などのコンテンツを自社サービスのユーザーに共有・公開するとき、肌の露出が多い画像や暴力的な画像など、不適切なものを取り除きたい場面は多くあります。特に、ユーザーが生成したコンテンツを他のユーザーに公開するときや、生成 AI が作成したコンテンツを広く公開するときには、コンテンツの品質を担保することは重要です。しかし、画像や動画の確認を全て人力で行うのは、コンテンツの量が膨大になるほど時間がかかってしまいます。そんなときに、Amazon Rekognition のモデレーション機能を使えば、不適切なコンテンツを検出できます。 このブログでは、Amazon Rekognition カスタムモデレーションを用いて、モデレーション機能を自身のワークロードにカスタマイズする方法をご紹介します。ユースケースやカスタムモデレーション機能の利用方法、実際に試してみた際の精度をご紹介します。 Amazon Rekognition のカスタムモデレーションとは？ Amazon Rekognition は、機械学習を使用して画像や動画の分析を行えるサービスです。物体やシーンの検出、人の顔の検出や比較、動画におけるシーンや動線の分析など、様々な分析にお使いいただけます。そのなかでもモデレーション機能は、画像や動画に含まれる不適切なコンテンツを検出するものです。 こちらのページ にあるように、検出対象となるのは肌の露出や暴力などのカテゴリーです。検出時にはカテゴリーのタグが付加されるので、ニーズに応じて不適切なカテゴリーのコンテンツを選択的に検出できます。 なお、Amazon Rekognition のモデレーション機能には、2024 年 2 月に アップデート がありました。新しい検出対象のラベルが追加されたほか、モデルの精度が向上し、アニメーションやイラスト付きのコンテンツを識別する新しい機能が導入されました。2024 年 2 月時点では、新しい検出対象のラベルは 英語版のドキュメント にまとめられています。 Amazon Rekognition の基本的な機能は、自身でモデルを用意しなくても分析対象のデータさえ用意すれば利用できます。しかし、追加学習用のデータを用意すれば、自身のワークロードのためのカスタマイズもできます。そのなかでもカスタムモデレーションは、不適切なコンテンツの検出を自身でカスタマイズできる機能です。 Amazon Rekognition ユースケース Amazon Rekognition のカスタムモデレーションが使えるユースケースとして、管理者が直接作成したものでない画像が広く公開されるアプリケーションが考えられます。具体的には下記のような例が挙げられます。 ユーザーが投稿した画像を他のユーザーが閲覧できる ソーシャルネットワーキングサービスの投稿 ユーザー登録時のアイコン 生成 AI が生成した大量の画像をユーザーに公開・配布する 生成 AI を利用したゲームやエンターテインメント AI による画像変換プラットフォーム このようなときに、広くユーザーに公開されるのが望ましくないコンテンツには下記のような例があるでしょう。もちろん、何を公開していいかはユースケースにも依存します。 有名キャラクターなど著作権・肖像権を侵害するコンテンツ 性的なコンテンツや暴力的なコンテンツ タバコやアルコールなど対象年齢や見せ方によっては倫理的に不適切となりうるコンテンツ 競合他社のロゴなど自社製品として望ましくないコンテンツ ここからは、このそれぞれについて、Amazon Rekognition をどのように利用できるか紹介していきます。 性的なコンテンツや暴力的なコンテンツ このようなコンテンツは、Amazon Rekognition のデフォルトのモデレーション機能を用いれば検出できます。しかし、デフォルメされたイラストや、独特なタッチで描かれたイラストなど、コンテンツによっては Amazon Rekognition が十分な精度で検出できないかもしれません。この場合の対応策は大きく 2 種類考えられます。1 つ目は、検出のしきい値を下げる方法です。Amazon Rekognition のモデレーションでは、モデルがどれくらいの確度で不適切なコンテンツだと予想した場合にラベルを付与するかのしきい値を、自身で決めることができます。このしきい値を下げたうえで、検出されたコンテンツは人力で二重に確認するという方法が取れます。そして 2 つ目の方法が、カスタムモデレーションの利用です。デフォルトの機能でうまく検出できなかった画像を入力して学習させることで、モデルをカスタマイズできます。 タバコやアルコールなど対象年齢や見せ方によっては倫理的に不適切となりうるコンテンツ タバコやアルコールも Amazon Rekognition のデフォルトのモデレーション機能の検出対象に含まれます。しかし、場合によっては常に対象のコンテンツを規制したくないこともあるでしょう。その場合には、デフォルトのモデルを利用しつつ、モデレーション機能の検出のしきい値を上げることが解決策になることもあるでしょう。しかし、低いしきい値で検出されるものが規制したいものであるとは限りません。そのような場合には、特定のケースだけを規制するために、カスタムモデレーションによるモデルのカスタマイズが使えます。 有名キャラクターなど著作権・肖像権を侵害するコンテンツ 不特定のコンテンツの著作権侵害に対応したい場合は、Amazon Rekognition のモデレーション機能では対処できません。ただし、具体的なユースケースによっては Amazon Rekognition の他の機能が使える可能性はあります。例えば、特定のキャラクターを検出して公開を防止したい場合は、Amazon Rekognition のカスタムラベル機能を用いれば解決できます。これは、検出対象オブジェクトのラベル付き画像を用意して、Amazon Rekognition の物体検出機能をカスタマイズするものです。また、肖像権の侵害を防ぎたい場合には、Amazon Rekognition の顔検出機能を用いることができます。さらに、有名人の顔検出をしたい場合は、Amazon Rekognition の 有名人認識機能 が役に立ちます。 なお、Amazon Bedrock 上のモデル Amazon Titan Image Generator が生成した画像で著作権の請求が生じた場合は、 Amazon は上限なしの知的財産補償を提供します 。Amazon Rekognition とは直接関係ないですが、Amazon Titan Image Generator を利用する場合は参考にしてください。 競合他社のロゴなど自社製品として望ましくないコンテンツ この例は、有名キャラクターの映り込みを防ぐ例と似ています。不特定のコンテンツの検出は難しいですが、対象となるコンテンツを絞れば検出は可能です。ロゴなど特定のオブジェクトを検出したい場合はカスタムラベルを利用すれば検出でき、風景など画像全体にわたって検出したい場合はカスタムモデレーションが利用できます。 Amazon Rekognition カスタムモデレーションを使ってみる この章では、Amazon Rekognition カスタムモデレーションの使い方をご紹介すると同時に、実際に使ってみた際の精度を確認します。今回は架空のシナリオとして、A 国におけるギャンブル規制を想定してみます。A 国では違法なギャンブルとして、「ゆで玉子を見せてそれが固茹でか半熟か当てる」という「たまごギャンブル」が流行っています。そこで、A 国のあるサービスでは、このギャンブルを想起させる画像は規制したいと考えています。もちろん一般的にはそのようなギャンブルは存在しないので、Amazon Rekognition のデフォルトのモデレーション機能では「たまごギャンブル」は規制対象になっていません。そこで、このブログでは Amazon Rekognition カスタムモデレーションを利用して「たまごギャンブル」を検出することにします。 今回は「たまごギャンブル」に関係する画像として、ゆでたまごを不適切なコンテンツとして検出します。ゆでている途中や殻を剥く前の生玉子も、今回の検出の対象となります。一方で、割った生玉子や目玉焼きなど、「たまごギャンブル」とは直接関係ない画像は、検出対象ではありません。実際の画像の例は、このあとの「画像の準備」の項でお見せします。 画像の準備 まずは画像を準備します。用意する画像についての推奨事項は Amazon Rekognition のデベロッパーガイド に書かれています。モデレーション機能をカスタマイズする前に、Amazon Rekognition のカスタマイズしていないデフォルトのモデレーション機能を用い、検出精度を確認してください。このとき、本当は検出対象としたいのにデフォルトの機能では検出できなかった画像を、「偽陰性」の画像と呼びます。逆に、本当は検出してほしくないのにデフォルトの機能で検出されてしまった画像を、「偽陽性」の画像と呼びます。高い精度を得るためには、偽陽性と偽陰性の画像を含めて、下記の条件を満たすような画像データセットを準備することが推奨されています。 デフォルトで偽陽性が出る画像をトレーニング用に 20 枚以上 デフォルトで偽陰性が出る画像をトレーニング用に 50 枚以上 テスト用の画像を 20 枚以上 デフォルトで誤った予測が出る画像だけでなく正しい予測が出る画像も用意する 今回は、デフォルトでは不適切なコンテンツの検出に失敗する偽陰性の画像に焦点を当てます。そのため、デフォルトで偽陰性が出るような「たまごギャンブル」関係の画像 70 枚以上と、ギャンブルと関係ないただの玉子の画像を登録しておきます。一方で、今回の「たまごギャンブル」のシナリオでは、デフォルトで偽陽性の画像は存在しません。そのため、偽陽性の画像は用意しません。 用意した画像の登録方法は複数ありますが、今回は Amazon S3 にバケットを作成してデータを入れておきます。下記は検出対象の画像例です。 ギャンブルに使われるゆで玉子を作っている画像 ディーラーがゆで玉子を取り出している画像 一方で、割った生玉子や目玉焼きは、今回のギャンブルとは関係ありません。下記が関係ない画像の例です。 生玉子 目玉焼き プロジェクトの作成 Amazon Rekognition カスタムモデレーションでは、カスタム内容ごとに「アダプター」を定義します。そして、複数のアダプターは 1 つのプロジェクト内で管理できます。したがって、まずはプロジェクトを作成します。Amazon Rekognition カスタムモデレーションの画面において、下の画像の「プロジェクトを作成」をクリックします。 続いて、プロジェクト名とアダプター名を決めます。 その後、モデルのカスタマイズに利用する画像をアダプターに登録します。今回は、先ほど Amazon S3 にアップロードした画像を利用します。「S3 バケットから画像をインポートする」を選択したあと、該当バケットの URI を入力します。 最後に、テストデータの提供方法を選びます。「自動分割」を選択すると、アップロードした画像を自動でトレーニングデータとテストデータに分けてくれます。今回はこちらの自動分割を選択します。ここまでできたら、「プロジェクトを作成」をクリックします。 画像のラベルづけ 続いて、画像にモデレーションのためのラベルを付加します。この作業は Amazon Rekognition の UI 上で進められます。今回は、ゆでたまごに関係する画像にはすべて「Gambling」のタグをつけていきます。 一方で、ゆでたまごには関係ない画像には「Safe」の画像をつけていきます。今回、割った生玉子は規制の対象外です。 モデルのトレーニング 上記で登録したラベルは、ドラフト状態になっている間は保存されていません。「ドラフトを保存」をクリックして 保存します。その後、「アダプターをトレーニング」をクリックします。 遷移後の画面で再度「アダプターをトレーニング」を押し、トレーニングを開始します。なお、この画面でトレーニングの際の「信頼度のしきい値」を変更することもできます。信頼度のしきい値を高く設定してトレーニングすると、不適切な画像を敏感に検出する代わりに、適切な画像も誤って検出してしまう可能性が上がります。つまり、トレーニング後の偽陰性が減り、代わりに偽陽性が増えやすくなります。今回はデフォルトの 50 のままで進めます。今回は、130 枚の画像を登録して 22 分でトレーニングが終了しました。 アダプターの精度確認 トレーニングが終わったら、アダプターの精度を確認してみましょう。アダプターの詳細画面で、あらかじめ登録したテスト画像に対する精度を確認できます。 この画面では、偽陽性と偽陰性それぞれの改善率が書かれています。この改善率は、カスタムしていないデフォルトのモデレーション機能による検出精度と比較した際のものです。今回のアダプター作成の目的は、Rekognition のベースモデルで偽陰性が出る「たまごギャンブル」の画像を陽性として検出したいというものでした。ですので、偽陽性は元々存在せず、偽陽性の改善率が 0% なのは問題ありません。一方、偽陰性の改善率が 5% と低くなっていることは問題です。「ラベルごとのパフォーマンス」の欄を見ると、ギャンブルのラベルがついている画像 21 枚のうち 20 枚は検出できていません。 このように精度が低い際の解決策として、画像をより多く用意し再度トレーニングすることが考えられます。しかし、場合によっては、このアダプターのままでも精度を上げられる方法があります。それは、信頼度のしきい値の変更です。今回は偽陰性を検出したいので、トレーニングの際の信頼度のしきい値を上げるか、テストの際の信頼度のしきい値を下げることによって、偽陰性となる画像をより敏感に検出できます。試しにアダプターの詳細画面で信頼度のしきい値を 45% に下げると、「偽陰性の改善」の項が一気に上がります。なお、これでも偽陰性が改善されていない画像は残っています。また、現実的な問題では、アダプターにより偽陽性のデータが増えることもあるかもしれません。そのような場合は、適切に予測できなかった画像のデータを重点的に増やしてトレーニングし直せば精度が上がると考えられます。 アダプターの利用 学習したアダプターは、CLI や SDK 経由で利用できます。利用方法は ブログ「Announcing Rekogniton Custom Moderation: Enhance accuracy of pre-trained Rekognition moderation models with your data」 や Amazon Rekognition のドキュメントの DetectModerationLabels の項 を参考にしてください。今回は、撮影した画像をランダムに 2 つに分け、それぞれアダプターに入力する画像と入力しない画像としています。前者の画像が 130 枚あるのに対して後者の画像は 52 枚です。この後者の画像で精度を確認してみます。下記は、検出する際の信頼度のしきい値を 45% とした際の結果です。基本的にはうまく分類できていますが、一部、ギャンブルに関するのにアダプターによって関係ないと判定されている画像があります。このような場合は、信頼度のしきい値の変更もしくはアダプターの再学習で対応します。 本ブログでは、Amazon Rekognition のカスタムモデレーション機能についてご紹介してきました。本機能の使い道について議論したうえで、「たまごギャンブル」という架空のシナリオに基づいて実際にカスタムモデレーション機能を利用する方法をご紹介しました。なお、今回の「たまごギャンブルのシナリオ」はひとつの例で、データセットの特性や実際の状況などによって精度は変わります。ユーザーや生成 AI が生成したコンテンツをサービスに組み込むことが増えている昨今、コンテンツのモデレーション機能の必要性は高まっていると考えられます。ぜひ皆様も本機能を試していただけますと幸いです。
2023 年 11 月 27 日 – 12 月 1 日 にラスベガス開催された AWS re:Invent では、 メディア＆エンターテインメント業領域における最新動向、最先端の AWS 活用事例、新サービス・新機能を紹介しました。また、2023年 11 月 15 日 – 11 月 17 日 に幕張メッセで開催された、Inter BEE では、 Create. Deliver. Monetize をテーマに、AWS ブースでコンテンツ制作、放送、メディアサプライチェーン＆アーカイブ、Direct-to-Consumer ＆ ストリーミング、データ活用 ＆ AIML の 5 つのソリューション分野での展示を行い、ブース内シアターや同時開催の 主催者セミナーでは、様々なお客様に最新事例を発表頂きました。 本セミナーでは、上記 2 つのイベントのハイライトを、メディア & エンターテインメント業界のお客様向けにご紹介しました。 セミナーのアジェンダ: AWS re:Invent 2023 メディア業界向けサービス紹介および活用事例紹介 Recap: InterBEE 2023 AWS re:Invent 2023 メディア業界向けサービス紹介および活用事例紹介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト , 小役丸 達也 [ 資料 ] AWS re:Invent 2023 で発表されたサービスアップデートの紹介をメディア & エンターテイメント業界に関連するものを中心に行いました。加えて、メディア & エンターテイメント業界向けのセッションから重要な事例をピックアップして詳しく紹介しました。 Recap: InterBEE 2023 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト , 井村 紀彦 [ 資料 ] 2023 年 11 月 15 日〜 17日にかけて幕張メッセで開催された Inter BEE では、 Create. Deliver. Monetize をテーマに、AWS ブースでコンテンツ制作、放送、メディアサプライチェーン＆アーカイブ、Direct-to-Consumer＆ストリーミング、データ活用＆AIML の 5 つのソリューション分野での展示を行いました。ブース内シアターや同時開催の 出展者セミナーでは、様々なお客様に最新事例を発表頂きました。Inter BEE における発表のハイライトを要約してご紹介しました。 InterBEE 2023 については以下ポストもご参照ください。 【 Inter BEE 2023 ※情報更新】AWS 展示のご紹介 【 Inter BEE 2023 ※情報更新】AWS スポンサーのご紹介 【開催報告&資料公開】Inter BEE 2023 AWS 出展者セミナー 【開催報告&資料公開】Inter BEE 2023 AWS ブースセミナー スペシャルセッション おわりに 本ブログでは、2024 年 2 月 1 日に開催されたメディア業界のお客様向けの AWS re:Invent Recap セミナーを紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 山口が担当いたしました。
これまでのブログ投稿で、Well-Architected Framework Review(WAFR) を実行するための最初の 2 つのフェーズについて説明しました。 最初のフェーズは 準備 で、2 番目のフェーズは レビュー を実施することです。 このブログ投稿では、3 番目のフェーズである 改善 について詳しく説明します。 図1 – WAFR のフェーズ 改善フェーズ ワークロードのアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューしているこの時点で、 以前 説明した通り、レビューのための必要な準備を行い、 こちらの推奨事項 に従って実際のレビューを完了させたはずです。その結果、レビュー中に収集した回答に基づいて、アーキテクチャのリスクを特定したはずです。これらのリスクを、 高リスクの問題 (High Risk Issues, HRI) と中リスクの問題 (Medium Risk Issues, MRI) と呼びます （詳細は後ほど説明します）。改善フェーズでは、改善計画（時には対応計画 (Treatment Plan) と呼ばれる）の作成を開始します。つまり、これらのリスクのリストを作成し、ビジネスへの影響を理解し、ソリューションを見つけ、最後に組織の優先事項に従ってこれらのソリューションを実装していきます。 以下のサイクルは、WAFR の改善フェーズに含まれる主なステップを示しています。各ステップの詳細について説明します。 1- リスクの特定 （別名：改善機会） [所要時間: 1日] WAFR の文脈上で使用されるリスクには 2 つのカテゴリがあります。高リスクの問題 ( HRI ) と中リスクの問題 ( MRI ) です。 HRI はビジネスに重大な悪影響を及ぼす可能性のあるアーキテクチャと運用の選択肢です。組織の業務、資産、個人に影響を与える可能性があります。セキュリティの柱における HRI の例は、AWS アカウントを保護していないことです。 MRI もビジネスに悪影響を与える可能性がありますが、その影響度は HRI ほどではありません。セキュリティの柱における MRI の例は、定期的に認証情報の監査とローテーションを行っていないことです。 HRI/MRI レポートの生成 HRI/MRI を視覚的に特定する最初のステップは、確認した各ワークロードのリスクを示すレポートを生成することです。 AWS Well-Architected Tool (AWS WA Tool) の ダッシュボード から、ワークロードとそれに関連する HRI および MRI にアクセスできます。 また、共有されたワークロードも含めることができます。 ダッシュボードを使用すると、ワークロード、柱、または重要度（高または中）で問題をフィルタリングできます。 この図は、いくつかのサンプルワークロードを含むダッシュボードの例を示しています。 下にスクロールさせると、HRI/MRI のリストが表示されます。柱または重要度でフィルタリングできます。例えば、これは信頼性の柱で発見された HRI/MRI のリストです。改善項目を選択すると、Well-Architected Framework からそれに関連するベストプラクティスに直接移動します。そこから、問題を修復するために必要な推奨アクションと必要なリソースについて読むことができます。 これらの全ての結果を 1 つのレポートにまとめるには、WA Tool のダッシュボードから [レポートの生成] を選択します。 このレポートを組織内のレビューチームと共有することを推奨します。通常、私はお客様に対して、次のステップに備えるために、実施した内容、主な調査結果、改善案をまとめた要約メールをお送りしています。 2- リスクの理解 [所要時間: 2-3 週間] リスクに対処する前に、ビジネスに対するその潜在的な重大性と影響、組織にもたらす価値、およびその改善を実装するためのチームの労力を理解することが重要です。HRI と MRI の定義に基づいてビジネスに対するリスクのレベルを評価する際には、次の質問を考えてみましょう。 リスクが影響を及ぼす可能性はどの程度か？ お客様への影響は何か？ 結果としてのビジネスへの影響は何か？ リスクを完全に排除できるか、それとも軽減するのみか？ 誰がリスクを負っているか？ 誰がリスクの排除や軽減のための改善作業を担うか? 主要なステークホルダーやビジネスオーナーにこれらの質問に答えてもらうことで、焦点を当てるべき最も重要なリスクのリストの作成と、それらに対処するための時間を予測するのに役立ちます。 架空のワークロードを使用して、例を示しましょう。 HRI/MRI やビジネスにもたらすリスクについてチームと話し合った後、対処が必要な次の HRI を特定しました。 3- 規範的なソリューションの決定 [所要時間: 4-5 週間] 組織のコンテキスト上でリスクと改善の機会を理解したら、チームと協力して、リスクに対する適切で規範的なソリューションを決定する必要があります。このフェーズでは、各チームが自分の領域で発見された HRI に取り組み、HRI に対処するための規範的なソリューションを決定する必要があります。このステップでは、追加の調査、ディスカッション、概念実証の構築が必要になる場合があります。このフェーズでは、ソリューションの実装の詳細に急がないことが重要です。次のステップで説明するように、質問に含まれている HRI がワークロードの優先事項であると決まった際に、後でそれを行います。このステップの目的は、ソリューションの複雑さと必要なリソースを理解することで、ステップ 4 の優先順位リストの作成時にそれらを考慮できるようにすることです。 今回の例では、3 つの HRI について次のソリューションを決定しました。 4- 実装と追跡 [所要時間: 3-6 ヶ月] まず優先順位をつけましょう。無制限の時間とリソースを持っている組織は存在しません。WAFR の結果として特定された全ての HRI/MRI に同時に取り組もうとするのは、WAFR から最大限のメリットを得る正しい方法とは限りません。私はいつもお客様に、ビジネスへの影響が大きく、実装がそれほど難しくない HRI/MRI の数を選んで始めることを推奨しています。ソリューションを実装します。改善を追跡し、そのアプローチを反復します。 しかし、実装する上で最も重要な項目に優先順位を付けるにはどうしたらよいでしょうか? ソリューションの優先順位を可視化するのに役立つツールの 1 つが、 アイゼンハワースタイルのプロット です。このツールを使用する方法は様々です。評価する際には、改善の重要性（ビジネスにもたらす価値の大きさ）と改善を実装するための労力（必要な時間、実装の複雑さ、人数など）の両方を考慮してください。 分析を行うと、ビジネスに最も影響を与えるリスクのセットが得られます。同時に、これらのリスクは実装が複雑ではありません。これらは、最初の反復で実装を開始するのに適した候補となります。 このモデルを今回の例に適用してみましょう。 今回の例で特定された HRI をレビューした結果、次のことが判明しました。 これはプロットを使用した分析の様子です。REL1、COST1、OPS4 を優先順位として決定した後、実装を開始し、次の HRI/MRI のセットについてこのプロセスを繰り返します。 図 9 – 影響度/複雑さを考慮したソリューションの優先順位付け ソリューションの特性 特定されたリスクに対するソリューションを選択する際には、次の点を考慮してください。 S.M.A.R.T : ソリューションを SMART の観点から考えましょう。良いソリューションは、具体的な (Specific) アウトプットがあるもので、測定可能 (Measurable) で、達成可能 (Achievable) で、問題と関連性があり (Relevant) 、期限が設定されている (Time-bound) べきです。 オーナー: 全てのソリューションについて、オーナーを特定しましょう。 シンプルで複雑でない: 複雑なソリューションは機能しますが、改善をより困難で長期化させます。常に複雑性よりもシンプルさを選択しましょう。 Two-way Door ソリューション: ソリューションは拡張可能で、時間とともに改善・進化するように設計されるべきです。可能であれば、アーキテクチャが発展しても適応できない静的なソリューションは避けてください。 パターンベース: コード化、再利用、再共有できるソリューションを目指しましょう。車輪の再発明は避けましょう。 いくつかの例 をチェックしてください。 タイムライン 「これらのステップを実行していくための典型的なタイムラインはどのようなものか」と疑問に思われるかもしれません。それに対する一概に決まった答えはありません。組織はそれぞれ異なり、独自の課題があるからです。しかし、多くのお客様との成功した WAFR の事例から見る限り、このフェーズには 90-180 日かけることを推奨します。この期間がより長くなるような HRI/MRI のリストである場合は、優先順位を付けて短いリストを取り出すことを推奨します。そうすれば、プロセスの実践を始めて改善を図ることができます。その後、残りの項目に対して繰り返し実施できます。 まとめ このブログ投稿では、WAFR の結果として特定されたアーキテクチャの HRI/MRI に対処するための改善計画を策定する際に踏むステップについて順を追って説明しました。改善計画を策定する前に、リスクを理解して分析し、優先順位を付け、そのソリューションを見極め、最も影響力のあるリスクを対象に優先的なアプローチを決定する必要があります。それを達成するのに役立ついくつかのツールとリソースを紹介しました。また、優れたソリューションを生み出す特性についてもいくつか紹介しました。皆さんの次のステップは、組織にある 2,3 のワークロードに対して Well-Architected Framework Review(WAFR) を実施することの重要性についてチームと話し合うことです。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。
Well-Architected Framework Review (WAFR) を成功させるには、準備、レビュー、改善の 3 つのフェーズがあります。このブログシリーズの パート 1 では、準備フェーズについて説明しました。このパートでは、第 2 フェーズ、つまり実際のレビューにおけるベストプラクティスについて詳しく説明します。 図 1 – WAFR のフェーズ 準備フェーズ の推奨事項に従っていると仮定すると、この時点で、レビューしたいワークロードを特定し、スポンサーを特定し、レビューする柱とその優先順位を決定し、使用する レンズ （ある場合）とレビューセッションの形式を決定しているはずです。また、レビューの質問に答えるために、ワークロードに関する必要なデータも収集しているはずです。 WAFR のゴール WAFR の成功のためのいくつかの推奨事項について深く掘り下げる前に、レビューの最終目標はシステムアーキテクチャを 改善 して、これらのシステムがビジネスニーズをより良くサポートできるようにすることであることを再確認しておくことが重要です。アーキテクチャ改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと比較することから始まります。レビューの質問に回答することでこれを行います。各柱に対し質問のセットがあります。回答に基づいて、改善領域、つまり 高リスクの問題 (High-Risk-Issues, HRI) および 中リスクの問題 (Medium-Risk-Issues, MRI) を特定します。次に、優先順位に基づいたアプローチを使用して、これらのリスクを改善するための対応計画の作成に取り組みます。 WAFR のベストプラクティス 1- 期待値を設定します。 WAFR は全ての参加者にとって大きなコミットメントです。メインのステークホルダーと事前にこの話し合いを行い、レビューの前・最中・後の期待値と役割を明確にします。彼らのサポートが得られることを確認しましょう。 2- 監査ではなく対話であることを意識します。 WAFR セッションで最も良い結果を出すのは、チェックリストや採点の機会としてではなく、対話の機会としてステークホルダーが捉える場合です。これにより、ベストプラクティスの見逃しを責められることなく、全てのチームメンバーがシステムについて自由に話すことを促します。これはアーキテクチャリスクの発見に役立ちます。 3- チームスポーツの精神を持って、チームの全員が役割を果たすべきです。 例えば、柱のスポンサーはその柱内のすべての質問に正しく答えるべきです。スポンサーは、レビュー中に特定されたリスクの改善計画を所有する必要があります。これはレビューの改善フェーズで異なるチーム間で特定されたリスクの優先順位付けと解決策を見つける必要がある場合に、より重要になります。これはこのブログシリーズの パート 3 で議論されています。 4- 1 回きりのチェックではなく、継続的なチェックが必要です。 物事は常に変化するので、その変化を放っておかないようにすべきです。組織内で WAFR（またはそのカスタマイズバージョン）を定期的に実施することを習慣化させる、もしくは、テストから本番への移行など、ワークロードのライフサイクルの大きなマイルストーンごとに合わせて実施することを推奨します。 5- より早いうちに実施することが望ましいです。 本番ではなく設計段階にあるうちは、意思決定に影響を与え変更を促進することがより容易であるからです。 6- AWS Well-Architected Tool (AWS WA Tool) を使用します。 WAFR の質問は ホワイトペーパー として利用できます。しかし、レビューには AWS WA Tool を使用することを推奨します。このツールを使用することで、質問を追跡したり、メモを取ったり、様々なマイルストーンを作成したり、質問のコンテキストを理解したり、実証済みのベストプラクティスを理解したり、ブログ、re:Invent トーク、ドキュメントなどの質問に含まれているベストプラクティスに対する追加リソースを検索したりできます。 AWS WA Tool の使用は、カスタムレンズを作成することにも役立ちます。カスタムレンズを使用することで、独自の柱、質問、ベストプラクティスを作成できます。カスタムレンズの質問は、特定のテクノロジーに合わせてカスタマイズできるため、組織内のガバナンスニーズを満たすのに役立ちます。 こちらの例をご覧ください: カスタムレンズと AWS Well-Architected Tool を使用した Well-Architected Review のカスタマイズ 組織における AWS Well-Architected カスタムレンズライフサイクルの実装 カスタムレンズライフサイクルのベストプラクティス: 計画と実装 カスタムレンズライフサイクルのベストプラクティス: 測定と改善 レビューフェーズでは、特定のベストプラクティスが実装されているかどうかを説明するために必要なメモを取ることが重要です。実装されている場合は、質問のチェックボックスにチェックを入れます。実装されていない場合は、なぜ実装されていないのかを説明するためにメモ欄にメモを取ります。「ロードマップ上にあるか？」「他の要件と競合しているか？」「単に見落とされただけか？」これらの質問への回答は、チームが後で改善計画を作成する場合に役立ち、他のレビュアーにとってもチームと所有者が変更される場合に役に立ちます。 マイルストーン は私がお勧めするもう 1 つの機能です。マイルストーンは特定の時点でのワークロードの状態を記録します。複数のセッションを実施する場合や、改善項目に取り組む場合に、マイルストーンを保存して進捗を測定できます。 7- 時間を有効活用します。 WAFR は短時間で完了し、数日ではなく数時間で終わらせるべきです。 レビュープロセスを簡潔に保つために、ベストプラクティスを検証するためのフォローアップ質問をすることと、質問のコンテキスト内に留め、技術的な深い議論に時間をかけすぎずに、バランスを保つことが重要です。 例えば、モニタリングは 6 つの柱全てにわたって取り上げられるトピックです。しかし、コンテキストは柱ごとに異なります。運用上の優秀性の柱をレビューする際のモニタリングは、可観測性についてであり、メトリクスと KPI を設定することにより、ワークロードの健全性を理解することです。セキュリティの柱では、モニタリングのコンテキストは、環境の監査、悪意のあるアクティビティの追跡、不正な動作の理解などにシフトします。 もう 1 つ注意点としては、レビュー中に技術的な議論に深入りしすぎないことです。例えば、サービスの設定の詳細を調べる場合などです。また、解決策の部分に飛び込むことも避けてください。レビュー中に正しいソリューションをその場で推奨するのに十分な時間と必要な詳細がないからです。代わりにメモを取り、 パート 3 でみていくように、改善フェーズの一環としてこのトピックをフォローアップしてください。 8- 「多分」は「違う」と捉えるようにします。 場合によっては、ベストプラクティスが実装されているかどうかチームで確信が持てないことがあります。その場合は、実装されていないベストプラクティスを考慮し、WA Tool のメモにそのことを文書化する必要があります。このようにすることで、改善フェーズの一環として、ソリューション（またはさらなる検証）をフォローアップとして含めることができます。 9- 必要に応じてスケールさせ、自動化を図ります。 大規模な組織で多数のワークロードがある場合は、ワークロードをレビューし、リスクを特定し、それらを修正するための自動化された拡張性のあるプロセスを構築することを検討してください。 ここに私の同僚が作成した、組織に WAFR を統合する方法の例がいくつかあります。組織に合わせて、これらのソリューションを調整および再利用できます。 AWS CloudFormation を使用した Well-Architected Review の作成と更新 (Lab) Well-Architected Review のカスタムレポートの構築 (Lab) : AWS Well-Architected Tool APIを使用して、AWS Well-Architected のデータを集中化されたレポーティングツールに統合する例です。 エンタープライズ全体での Well-Architected Review のスケーリング（re:Invent 2022セッション） : ワークロードのレビューとスケーラブルなアーキテクチャヘルスレポーティングの構築のための標準化された一貫したアプローチの作成例です。 Trusted Advisor および AWS Well-Architected Tool によるクラウド最適化（re:Invent 2022セッション） : このセッションでは、クラウド最適化の機会を特定するために、AWS Well-Architected Framework、AWS Well-Architected Tool、AWS Trusted Advisor を統合する方法を紹介します。 AWS Well-Architected Framework のベストプラクティスに沿った AWS 上の DevOps（re:invent 2022セッション） : 組織の DevOps プラクティスを AWS Well-Architected Framework の柱に整合させる例です。 統合された AWS Trusted Advisor インサイトを使用した Well-Architected Framework Reviews の加速（ブログ投稿） まとめ このブログ記事では、様々な業界のお客様と実施した多数の Well-Architected Framework Reviews から得た教訓の一部を紹介しました。WAFR の最終目的は、アーキテクチャのリスクを特定し、対処することです。そこに辿り着くには、まずワークロードアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューする必要があります。WAFR を実施する際、いくつかの推奨事項に従い、回避すべきアンチパターンがあります。レビューは会話形式で、正直であり、文書化されており、週ではなく日単位で完了する必要があります。複数のワークロードのレビューを実施する場合は、組織のベストプラクティスに従ってプロセスを自動化およびスケールする必要があります。SA やお客様からのリソースの例をいくつか示し、その方法を紹介しました。次のステップでは、リスクを特定した後、それらに対処するための改善計画を作成する必要があります。これは パート 3 でカバーされます。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。
「私のワークロードは “Well-Architected” だと言えますか？私のチームはクラウドのベストプラクティスに従っていますか？他のお客様はソリューション X をどのように実装していますか？サービス Y を構成する最適な方法は何ですか？」 これらは、お客様のアーキテクチャが AWS のベストプラクティスに沿っているかどうかを検証したいというお客様から普段いただく質問の例です。その答えの内容はお客様の技術ドメインの種類によって異なりますが、一般的にお客様が従う確立された設計原則があり、これらに従うことで、システムが期待通りに機能する可能性が高まります。これらの設計原則とベストプラクティスは、 AWS Well-Architected Framework の中核をなしており、運用上の優位性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 本の柱 に渡っています。 AWS では、あらゆるものにベストプラクティスがあり、ワークロードに対して実施する Well-Architected Framework Review(WAFR) も例外ではありません。チームの経験、ワークロードの複雑さ、レビューする柱、後に取り上げるその他の要因など、複数の要因によって、WAFR は大掛かりな取り組みになる可能性があります。これらのベストプラクティスを認識していることは、チームがレビューに投資している時間がアーキテクチャのリスクを特定し、それらに対処するという期待される結果につながることを確実にするための鍵となります。この 3 部構成のブログシリーズでは、AWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有します。パート 1 では、レビューの準備方法をお話しします。 パート 2 では実施方法をカバーし、 パート 3 ではアーキテクチャのリスクを特定し、それらを修正するための計画を作成する方法をカバーしています。 WAFR とは何か テクノロジーシステムを構築することは、他の製品を構築することと変わりません。製品を業界の標準に沿って構築するためには、守るべき プラクティス (practices) と規範があります。しかし、プラクティスを整備するだけでは不十分です。チームがこれらのプラクティスを 認識 (aware) し、 準拠 (follow) していることを確認するための 仕組み (mechanism) を実装する必要があります。 AWS のベストプラクティスを 学習 (Learn) し、アーキテクチャをこれらのベストプラクティスと照らし合わせて 計測 (Measure) し、アーキテクチャのリスクを特定して、それらに対処するための 改善 (Improve) 計画を作成する 一貫したプロセス (Consistent process) が、AWS Well-Architected Framework Review(WAFR) と呼ばれるものです。 図 1 – Well-Architected Framework Review サイクル WAFR の目的は何か？なぜ必要なのか？ WAFR の最終的な目標は、システムアーキテクチャを 改善 することで、そのシステムがビジネスニーズをより適切にサポートできるようにすることです。アーキテクチャの改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと照らして比較することから始まります。これを実現するために、レビューの質問に回答します。各柱に対して質問のセットがあります。これらの質問は、特定のベストプラクティスがアーキテクチャに実装されているかどうかを検証します。回答に基づき、AWS Well-Architected Tool (AWS WA Tool) の支援を受けて、アーキテクチャ内で高リスク、中リスク、低リスクの領域を特定します（後ほど詳しく説明します）。次のステップは、これらのリスクの影響の高いものを特定することにより、優先順位に基づいたアプローチでリスクの解決に取り組み始めることです。その後、それらに対処するための改善計画を作成します。今回の投稿と本シリーズの次の投稿で、これらの各ステップの詳細を説明します。 WAFR のフェーズ WAFR には、準備 (Prepare), レビュー (Review), 改善 (Improve) の 3 つのフェーズがあります。以降のセクションでは、各フェーズについて詳しく説明し、そこから最大限のメリットを引き出すためのベストプラクティスを紹介します。 図 2 – Well-Architected Framework Review のフェーズ 準備 WAFR の準備は、平均して実際のレビュー日の約 3 週間前から開始されます。 これは、レビューチームの結成にかかる時間、レビューする柱の数、組織によってレビューを完了することに与えられた優先順位などの要因に左右されます。 このフェーズでは、レビューセッションに招待するチーム、レビューする作業量、レビューセッションの形式を決定します。 また、レビューの質問に答えるのに役立つアーキテクチャに関する必要なデータを収集する必要があります。 それぞれをより詳しく見ていきましょう。 1- ワークロードを定義する WAFR の準備の最初のステップは、レビューしたいワークロードを特定することです。ワークロードとは、組織にビジネス価値を提供するコンポーネント（テクノロジー、人、プロセス）の集合です。これは、リーダーがコミュニケーションするビジネスとテクノロジーのレベルです。例えば、お客様が注文およびそれを追跡できるウェブサイトと、そのバックエンドをサポートするインフラストラクチャおよびプロセスは、ワークロードです。 2- コアチーム（スポンサー）を定義する WAFR を成功させるための重要な要素は、最初から適切な人に参加してもらうことです。 レビューするワークロードを特定した後、ワークロードの所有者を特定する必要があります。時にスポンサーと呼ばれることもあります。ワークロードのスポンサーとは、そのワークロードの成功（または失敗）に最終的に責任を持つ個人（またはチーム）のことです。この人物は、レビューの結果として特定されたアーキテクチャ上のリスクに対処するための影響力と行動をとる適切な権限を持っている必要があります。例えば、チームの優先事項を変更したり、外部委託したりすることが考えられます。 各柱についてスポンサーを特定する必要があります。組織の構造や規模によっては、1 人が複数の柱を担当したり、1 つの柱を複数のチームが担当したり、あるいはその両方の場合があります。ここでの目的は、各柱についてレビューの質問に答える適任者がいることを確認し、後に対応計画の一環としてその柱で特定されたリスクに対処できるようにすることです。 レビュー対象の柱をより全体的に俯瞰するために、異なるチームから個人を招待する必要があるかもしれません。例えば、信頼性の柱をレビューする場合、データベース、ネットワーク、セキュリティ、運用の専門家 (Subject Matter Expert, SME) を含める必要があるかもしれません。運用上の優秀性の柱をレビューする場合は、エンタープライズアーキテクトやアプリケーション開発部門、ビジネス/ファイナンス部門などを含める必要があるかもしれません。 3- 柱とレンズを決定する 6 つの柱の視点からワークロードを包括的に見ることが最も理想的です。しかし、特定の柱にだけ焦点を当てる必要がある状況もあるかもしれません。例えば、セキュリティの慣行を変更した場合、ベストプラクティスとの整合性を確認したいと考えるかもしれません。この場合、セキュリティの柱のみをレビューすることを選択する可能性があります。 Well-Architected Framework に記載されている通りの柱の順序に従うことを推奨します。運用上の優秀性の柱から始めて、持続可能性の柱で終わるようにします。しかし、組織の優先事項は異なる可能性があります。このフェーズでは、レビューする柱の順序を決定する必要があります。 レビューする際に検討するもう1つの点は、 AWS Well-Architected レンズ を使用するかどうかです。このレンズは Well-Architected のガイダンスを特定の業界や技術領域に特化して拡張したものです。例えば、ワークロードが主にサーバーレスを利用している場合は、 サーバーレスアプリケーションレンズ に対してレビューする必要があるかもしれません。データ分析ワークロードを実行している場合は、レビューに データ分析レンズ を含める必要があるでしょう。このように業界や領域に応じてレンズを選択します。利用可能なレンズの一覧は こちら から確認できます。 4- セッションのタイプを決定する 選択した柱とチームの参加可能性に応じて、レビューセッションの形式を決定する必要があります。選択肢としては、6 つの柱の 1 日レビュー、または選択されたいくつかの柱について数日かけて複数のセッションを実施する方法があります。1 日レビューを実施することは通常、スケジュール設定が難しいですが、すべてのステークホルダーがベストプラクティスを議論するために集まることができるので、最も価値があります。通常、この形式は最も改善の機会を明らかにするのに役立ちます。複数のセッションは、地理的に分散したチーム、または大規模なチームがあり、同時に集まることが困難な場合の良い選択肢です。このアプローチは維持しやすいですが、異なるマイルストーンで異なるチームに更新するために、少し余分な作業が必要になる場合があります。 レビュー中のチーム間のコミュニケーションが重要です。なぜなら、質問への回答や問題の特定を集団で行うのに役立つからです。そのため、AWS WA Tool の質問にチームで回答する際は、非同期的ではなく、ライブセッションとして WAFR を実施し、回答をその場で共有することを推奨します。 5- レビューに必要なデータを収集する レビューセッションを実施する前に、レビュー対象のワークロードについての詳細な情報を収集することを推奨します。例えば、システムの主要コンポーネント、バックエンド、運用を担当する主要なプロセスとチームを説明しているアーキテクチャ図やドキュメントを確認します。 より複雑なワークロードの場合は、 AWS Trusted Advisor におけるベストプラクティスに対する 自動評価を行うチェック機能 を利用できます。これには、コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービス制限が含まれます（訳注：2024 年 2 月 26 日翻訳時点で運用上の優秀性も含みます）。Trusted Advisor を有効にして、 AWS Organizations のすべてのアカウントをチェックできます。 詳細は こちら をご確認ください。そして、Trusted Advisor の推奨アクションを利用して、ベストプラクティスへの準拠状況をより深く理解し、レビューや後の対応計画の策定にこれらの詳細を取り入れることができます。 AWS Well Architected と AWS Trusted Advisor を利用したデータドリブンなコスト最適化の達成方法 の例もご参照ください。 まとめ このブログ記事では、Well-Architected Framework Review の最初のフェーズである「準備フェーズ」について詳しく取り上げました。 お客様とレビューを実施する中で学んだステップと教訓の一部をご紹介しました。 これらの推奨事項により、レビューがよりスムーズに進み、参加者の時間を最大限に活用できるようになります。 ステップには、レビュー対象のワークロードの定義、適切なコアチームとスポンサーの特定、 柱とセッションタイプの選択、そして事前に必要なデータの収集が含まれます。 これらのステップにより、レビュー日の準備が整います。 このブログシリーズの パート 2 と パート 3 で、WAFR についてさらに詳しく取り上げます。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの陳です。 テレコム業界に携わるお客様やパートナー様、5G やエッジ等の最新技術の動向にご興味のある方々を主な対象として、2024 年 1 月 31 日に「AWS re:Invent Recap インダストリー編 – テレコム業界向け」をウェビナーで開催しました。 本記事では、当日の内容・動画を皆様にご紹介します。 ウェビナー開催の背景 世界中の AWS ユーザーが集まり、ベストプラクティスや最新情報を学ぶための年次カンファレンス「AWS re:Invent」が 2023年11月ラスベガスで開催されました。本イベントでは、AWS re:Invent の 発表内容より、テレコム業界領域における最新動向、AI を駆使した事例、モバイルネットワークのクラウドアーキテクチャー、クラウドへの移行で直面する課題と解決法等の内容をお届けしました。 下記は発表内容をセッションごとのサマリとなります。 サマリは Amazon Bedrock による生成された内容をベースに加工しました。 1. テレコム業界の AWS re:Invent ハイライト 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第二ソリューション部 ソリューションアーキテクト 陳 誠 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、AWS のテレコム業界向けの最新動向とお客様の事例を紹介しました。AWS はクラウドインフラ、テレコムワークロード、付加価値サービス、デベロッパープラットフォームの4つのレイヤーで通信事業者の変革を支援しています。 インフラ面では、33 のリージョンをカバーするグローバルな展開力で通信事業者を支援します。ローカルゾーンの提供によりエッジまで一貫性のある管理が実現できます。コンピューティング能力に関しては、新世代プロセッサー AWS Graviton 4 により大幅な性能向上が図れます。 付加価値サービスとして、メキシコの Smartlite 様がAR/VRソリューションを活用し、収益化に成功した事例を紹介しました。ITプラットフォームでは、Dish 様がコンタクトセンターをクラウド化した結果、エージェントの生産性が25%向上しました。 5G 関連では、ハワイの MVNO である Mobi 様が、5Gコアネットワークを1週間以内で稼働できた事例が発表されました。韓国のLGU+様では、災害対策としてのクラウド活用が進められています。 AI 活用の面では、ネットワーク運用業務の効率化が期待できます。ケーブルテレビ大手の Cox Communications 様がその好例として取り上げられていました。 AWS は通信事業者と協力し、こうした先進的な取り組みを通じて、クラウドを活用した次世代のテレコムの実現を目指しています。 2. 通信事業者のための生成系 AI の活用方法 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト 菊地 貴彰 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、AWS と Altman Solon 社の調査をもとに通信事業者の生成 AI の動向を紹介した後に、AWS re:Invent で発表された生成 AI の活用事例を紹介しました。Allied Market Research 社の調査によると、2026 年までに 95 % の通信事業者がデータ、分析、AI の取り組みを導入する見込みと言われています。すでに先進的な通信事業者は生成 AI を活用してビジネスに高い付加価値をもたらしていますが、世界的に見ても生成 AI の導入はまだ初期段階にあります。 生成 AI の導入初期段階で多いユースケースは、カスタマーサービスの顧客向けチャットボットです。従来のルールベースから、生成 AI ベースのチャットボットに移行し、会話の質を高めてコンタクトセンターでのやり取りを減らすなどの効果が期待されています。その次に多いユースケースは、従業員生産性向上を目指したガイド付き支援です。 生成 AI 活用における課題は、データのセキュリティやプライバシー、データガバナンスへの懸念、技術的リソース不足、生成 AI の出力の信頼性への懸念などが挙げられています。技術的リソース不足も背景にあって独自に基盤モデルを構築することよりも、既存のマネージドサービス活用を望む声が大きいことがわかっています。 AWS の生成 AI サービスとして、Amazon Bedrock が注目されています。主要な基盤モデルからニーズに合わせて選択可能であり、基盤モデルのカスタマイズもできます。検索拡張生成（RAG）や一連のタスクの自動化ができるエージェントのマネージドサービスも提供しており、生成 AI をお客様のアプリケーションに簡単に組み込めます。 生成 AI の活用事例として、Cox Communications 様のガイド付き従業員支援と Globe Telecommunications 様のパーソナライゼーションを紹介しました。生成 AI の活用により、前者はネットワーク問題の発見、診断、解決にかかる時間を大幅に短縮でき、後者は顧客体験の向上に貢献したことが確認できました。通信事業者における生成 AI は今後拡大すると見込まれるため、その動向に注視する必要があると考えられます。 3. テレコム業界におけるクラウドアーキテクチャのご紹介 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト 宮崎 友貴 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、通信事業者の主要な 5つのワークロード (ビジネスソリューション、カスタマーエクスペリエンス、OSS/BSS、5Gコア/IMS、5G RAN) について、それぞれの現在の課題と AWS クラウド上での参考アーキテクチャーを紹介しました。 具体的には、TMフォーラムの ODA に準拠した AWS 独自のクラウドネイティブなビジネスソリューションフレームワーク、コネクテッドカスタマージャーニーと 生成 AI によるカスタマーエクスペリエンスの向上、コスト最適化と低レイテンシーを考慮した OSS/BSS のモダナイゼーション、AWS Local Zones や AWS Outposts を活用した 5Gコア/IMS のリファレンスアーキテクチャ、数千拠点に展開可能な Amazon EKS Anywhere や AWS Outposts を使用した O-RAN リファレンスアーキテクチャー等について解説がありました。 事例として、Smart Home を提供している TELUS 様の例が紹介され、デバイス、ネットワーク、AWSサービス、CSPサービス、アプリケーションからなる層構造の論理アーキテクチャが説明されました。また、Liberty Latin America 様は、複数の国やデータセンターにまたがるモノリシックなプラットフォームを統合し、アジャイルな方法で最新のアプリケーションを短期間で導入できるようになったBSSのマイグレーション実績が紹介されました。さらに、Telefónica Germany 様による 5G コアを AWS上で実装され、優れたネットワーク品質とカスタマーエクスペリエンスの向上につなげられた事例が紹介されました。 4. 通信事業者における大規模ワークロード移行のクラウドジャーニー 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト 加藤 知愛 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、LG U+ 様のクラウド移行の事例を紹介しました。LG U+ 様は韓国 3 位のキャリアで、2007 年から LG エレクトロニクスのセットトップボックスを使った VOD サービスを開始しました。現在のこのサービスの加入者数は 500 万人規模です。15 年以上サービス提供しており、チャンネル数が増え、日々 1.3 億のデータが更新されるなど、バックエンドが複雑化していました。 硬直化したアーキテクチャからくるサービス品質低下を解消するため、AWS へのクラウドマイグレーションを決定しました。1 年の準備期間で、アプリケーションのマイクロサービス化、CI/CD パイプライン構築、IaC（Infrastructure as Code）導入などを行いました。マイグレーションでは、サービスを無停止で移行する方針を打ち出し、AWS Database Migration Service (AWS DMS) を使ったデータベースの移行、API の Strangler パターンの採用、マイクロサービス化を段階的に実施しました。 マイクロサービス化では 78% の API をモダナイズしました。コンテナ基盤の Amazon Elastic Kubernetes Service (Amazon EKS) 上でマイクロサービスを展開し、データベースも Amazon Aurora に移行しました。CI/CD パイプラインと IaC により、ソフトウェアのリリースのスピードが向上しました。また、Amazon Aurora のスケーラビリティにより、負荷増時の対応力が向上しました。 準備に 1 年、移行に 1 年の計 2 年で、サービスを止めることなくマイグレーションを完了しています。自社主導の着実な準備と段階的な移行が成功の鍵でした。AWS によりビジネスの成長と継続的なプラットフォーム革新が可能になりました。 クラウドマイグレーションには長期的視点が重要です。丁寧な準備と段階的な移行で既存サービスを維持しながら、マイクロサービス化と CI/CD 等のアジャイル手法を取り入れ、サービス品質とスピードを両立させることができました。大規模システムの移行には時間がかかりますが、LG U+ 様の事例はその道筋を示しています。 まとめ 2024 年 1 月 31 日に開催した「AWS re:Invent Recap インダストリー編 – テレコム業界向け」の振り返りとして、開催概要や発表の見どころ紹介、お客様事例をご紹介いたしました。セミナーにご参加いただいた方、誠にありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考になりましたら幸いです。内容に関して、ご質問やご要望がございましたら、お問い合わせページ、もしくは担当営業までご連絡をお願いします。 このブログの著者 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第二ソリューション部 陳 誠 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 菊地 貴彰 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 宮崎 友貴 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 加藤 知愛