生成 AI をセキュアにする : 生成 AI セキュリティスコーピングマトリックスの紹介

生成 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 の「信頼性の柱」と「オペレーショナルエクセレンスの柱」で確立されている、既存のアプリケーションレジリエンスのベストプラクティスを必ず確認して実装してください (訳者注：本ブログシリーズの 1 つである生成 AI ワークロードにおけるレジリエンス設計も是非ご確認ください)。

結論

この記事では、確立されたクラウドセキュリティの原則が、生成 AI ソリューションを保護するための強固な基盤をどのように提供するかを概説しました。既存のセキュリティ手法やパターンの多くを使用しますが、生成 AI の基礎と、対処しなければならない独自の脅威とセキュリティ上の考慮事項についても学ぶ必要があります。生成 AI のセキュリティスコーピングマトリックスを使用すると、生成 AI ワークロードの範囲と、適用される関連するセキュリティ範囲を判断するのに役立ちます。対象範囲が決まったら、重要なセキュリティ要件の解決に優先順位を付け、ビジネスで生成 AI ワークロードを安全に使用できるようにします。

「生成 AI をセキュアにする」シリーズの今後の記事では、これらのトピックやその他のセキュリティトピックを引き続き探っていきますので、是非ご覧ください。

この記事についてご質問がある場合は、AWS サポートにお問い合わせください。

著者について

翻訳はプロフェッショナルサービス本部の藤浦が担当しました。原文はこちらです。

Amazon Web Services ブログ