生成AIが急速に普及する中、文部科学省が2023年7月に「初等中等教育段階における生成AIの利用に関する暫定的なガイドライン」を公表しました。⽂部科学省では、当ガイドラインを踏まえ、リーディングDXスクール事業におけるパイロット的な取組として、教育活動や校務において⽣成AIの活⽤に取り組む学校を指定し、「効果的な教育実践の創出」を⾏うことで、今後の更なる議論に資するよう、知⾒の備蓄をすすめることとしています。パイロット校に指定されたうちの1校が⼋丈町⽴富⼠中学校です。富⼠中学校での⽣成AI活⽤を⽀援したライフイズテック株式会社にお誘いいただき、2023年12⽉に中学2年⽣の授業を視察しました。本記事ではその模様をレポートします。 素敵なウェルカムボードでお迎えしてくださいました！ 八丈島の魅力を伝えるオリジナルチャットボットを制作！ 富士中学校では、ライフイズテック株式会社の協力のもと、3年前から生徒が島の魅力を探究し、「ライフイズテック　レッスン」を活用したWebサイト制作を通じて島外に発信するという地域課題解決型の取組を進めています。 今回は、富士中学校の２年生が、生成AIを活用しながら「八丈島の魅力を伝えるチャットボット」を制作しました。ライフイズテック レッスンを活用して制作を進めているオリジナルのWebサイトに、このチャットボットを搭載させ、Webサイトをさらに充実させようというものです。子どもたちがAIを使って新たな価値の「生産者」になるために「課題解決をベースに生成AIの使い方を学び実践する」という高度なチャレンジになります。 チャットボットは、ライフイズテック社で開発中の学校向け生成AIサービスを利用して、計6時間の授業で作成しました。生成AIが書いたプログラミングコードを、ブラウザのみでコードを記述/ 実行 / デバッグできるクラウドベースの統合開発環境（IDE）である AWS Cloud9で動作を確認しながらチャットボットを作成していきます。学校向け生成AIサービスは、学校向けに特化した機能やUI・UXの最適化を図ってあり、生徒も教師も安心安全に生成AIを利活用できるようになっています。 最初の2時間では、チャットボットの枠組を作るため、学校向け生成AIサービスを活用し必要なプログラミングコードを生成しました。 視察した3-4時間目では、先生が生成AIのプロンプトの書き方や、個人情報・著作物など入力してはいけない文言についてレクチャーをした後、プロンプトを体験。最初は何を入れるべきか、躊躇していた生徒もいましたが、「どんなことでも入れて大丈夫だよ」という声掛けで、どんどん活用できるようになり、「八丈島の魅力を伝えるチャットボット」を作成するためのアイディアを練りました。プロンプトの回答が返ってくるのに少し時間がかかるので、その間は教材を見たり、別の作業をしたりと工夫していました。次に、練ったアイディアをチャットボット制作画面に入れました。実際にチャットボットが思うような操作をするか確認。真剣な顔をして、集中して取り組んでいる生徒たちの姿が印象的でした。 ライフイズテック社で開発中の学校向け生成AIサービスにはプロンプトのヒントを出す工夫などがあり、生徒たちが使いやすいインターフェースになっています チャットボットはAWS Cloud9を立ち上げて作成します 「チャットボットが観光施設の問い合せ先の電話番号を伝えてしまうけど、大丈夫かな？」と先生に聞いている生徒も。先生からは「観光施設に、電話番号を出してもよいか、電話で聞いてみたら？」とアドバイスされ、「電話だと緊張するから、メールで聞いてみる」とのこと。実社会と結びついた学習の広がりを感じた一幕でした。 最後の5-6時間で、画像生成AIを使って、チャットボットのキャラクターを作成しました。3-4時間目で先取りで作業をしている生徒もいました。狙った画像が出るまで、何度もプロンプトを工夫していました。 画像生成はAmazon SageMakerにStable Diffusionをデプロイして利用しています 山下孝輔先生は、「（生徒たちは）面白かったでしょう。響くものがありました。」と手応えを感じてくださったと同時に、「生成AIを利用すると、中学生も高度なことができてしまう。ただどこまで理解しているかは、確認が必要」「生成AIに『使われない』ために、自分の思いやアイデアをいかに取り入れられるか、AIを使っていかに発展させられるかということに今後チャレンジしていきたい」と語っていました。 放課後の時間にも、クラスの半数以上の生徒たちが残っていて、続きの作業をしていましたが、そこで一番盛り上がっていたのは、先生の顔を真似た画像を生成する競争でした！ 生徒が生成AIを使うための工夫 今回、富士中学校での授業に協力したライフイズテック社は、次世代デジタル人材育成を手がけ、「中高生ひとり一人の可能性を一人でも多く、最大限伸ばす」をミッションに2010年に創業したEdTech企業です。主力事業である中学校・高校向けクラウド教材「ライフイズテック レッスン」は、全国600以上の自治体で4,000校の公立・私立学校、約120万人が利用(2023年8月時点)する、情報・プログラミング学習サービスへと成長しています。さらに生成AIの登場以降、すでに数多くの生成AI×教育の新サービス開発や取組を進めており、AIネイティブのための教育変革を牽引しています。 本授業で利用した学校向け生成AIサービスのプロダクトマネージャーの窪田秀行氏から、「文章生成／画像生成を生徒のみなさんが簡単かつ安心して使うことができる環境の提供が必要と考えています。例えば、画像生成のためのプロンプト入力の場面においては、必要な構成要素及びその入力例の組み合わせからプロンプト作成できる機能を具備し、プロンプトの専門知識の必要性を軽減させる工夫をしています。また、生成された画像を安心・安全に生徒画面へ届けるための仕組みとして、Amazon Rekognitionを活用させていただき、性的・暴力的な画像の生成を抑止する機能も搭載しています。」と生徒が生成AIを使うための工夫を教えていただきました。 今回の視察した授業では、中学生が最先端のことを学び、AIの利用者に留まらず、AIを使った課題解決者や開発者といった「生産者」への一歩を踏み出したことに感銘を受け、生徒たちを頼もしく感じました。 【参考：AWS導入事例】ライフイズテック株式会社 「本格化する情報教育をオンラインプログラミング教材で支援全国の中高生が“学び”に没頭できる環境を AWS で実現」 このブログは、アマゾン ウェブ サービス ジャパン合同会社　パブリックセクター　教育事業本部　初等中等教育/EdTech営業部　アカウントエグゼクティブである 尾島菜穂 が執筆しました。

3月4日週は忙しい一週間でした。新しい種類の Amazon CloudFront インフラストラクチャ、 Amazon Simple Storage Service (Amazon S3) に保存されているデータをより効率的に分析する方法、および新しい生成 AI 機能を導入しました。 2月26日週のリリース 注目すべき内容はこちらです。 Amazon Bedrock – Mistral AI の Mixtral 8x7B および Mistral 7B ファンデーションモデルが Amazon Bedrock で一般利用可能になりました。詳細については、 Donnie の投稿 をご覧ください。ここでは、同僚の Mike により、 Mistral 7B と Mixtral 8x7B モデル についてより詳しく説明します。 Amazon Bedrock のナレッジベース – ハイブリッド検索のサポートにより 、検索で得た結果、特にキーワード検索結果の関連性を高めることができます。 AWS 機械学習ブログ 内のこの投稿にあるより多くの詳細と例をご覧ください。 Amazon CloudFront – インターネットサービスプロバイダー (ISP) およびモバイルネットワークオペレーター (MNO) のネットワーク内で、エンドユーザーに最も近い場所にデプロイされる新しいタイプの CloudFront インフラストラクチャである 埋め込み型 Point of Presence (POP) の利用が可能になったと発表しました。埋め込み型 POP は、大規模なライブストリーム動画、ビデオオンデマンド (VOD)、ゲームダウンロードなどのサービスを提供するためにカスタマイズされています。現在、CloudFront は世界 200 以上の都市に 600 以上の埋め込み型 POP を導入しています。 Amazon Kinesis Data Streams – ストリーム内のデータをリアルタイムで分析して視覚化できるように、 AWS マネジメントコンソールで SQL クエリをワンクリックで実行することを可能にしました 。 Amazon EventBridge – API 送信先が コンテンツタイプのヘッダーのカスタマイズ をサポートするようになりました。独自のコンテンツタイプを定義することで、 CloudEvents へのサポートなど、より多くの API 送信先 HTTP ターゲットを利用可能にすることができます。詳細については、 AWS Lambda のプリンシパルエンジニアである Nik によるこの X/Twitter スレッドを参照してください 。 Amazon MWAA – Amazon Managed Workflows for Apache Airflow (MWAA) で Apache Airflow バージョン 2.8 に向ける環境を作成できるようになりました 。詳細については、この AWS ビッグデータブログ投稿 をご覧ください。 Amazon CloudWatch Logs – IPv6 をサポートする CloudWatch Logs を使用すると 、IPv4 と IPv6 の両方をサポートするデュアルスタックネットワーク上で Amazon CloudWatch ロググループを実行することにより、ネットワークスタックを簡素化できます。 IPv6 をサポートする AWS サービス に関する詳細情報について、このドキュメント内で確認できます。 SQL Workbench for Amazon DynamoDB – このクライアント側アプリケーションで拡張可能な高性能データモデルを視覚化して構築する際に、 開発環境間でのテーブルのクローン作成 が可能になりました。この機能を使用すると、複数の開発環境で同じ状態の Amazon DynamoDB テーブルを使用して、コードを開発およびテストすることができます。 AWS Cloud Development Kit (AWS CDK) – 新しい AWS AppConfig レベル 2 (L2) コンストラクト は、機能フラグや動的設定データを含む AWS AppConfig リソースのプロビジョニングを簡素化します。 Amazon Location Service – iOS および Android プラットフォーム用の認証ライブラリを使用して 、 Amazon Location Service をモバイルアプリに簡単に統合できるようになりました。ライブラリは API キーと Amazon Cognito 認証をサポートしています。 Amazon SageMaker – Amazon S3 Express One Zone ストレージクラスを使用して、Amazon SageMaker モデルのトレーニングを加速し、トレーニングデータ、チェックポイント、およびモデルアウトプットの読み込み時間を短縮することができるようになりました 。S3 Express One Zone はパフォーマンスに重点を置くアプリケーションのために特別に設計されたもので、より速いクラウドオブジェクトストレージ、安定な一桁のミリ秒単位レベルのリクエスト遅延および高いスループットを提供します。 Amazon Data Firehose – CloudWatch Logs のメッセージ抽出 をサポートするようになりました。CloudWatch Logs レコードはネストされた JSON 構造を使用しており、各レコード内のメッセージはヘッダー情報に埋め込まれています。ヘッダー情報にフィルタを掛けて、埋め込まれたメッセージのみを送信先に配信することがより容易になり、その後の処理とストレージのコストを削減します。 Amazon OpenSearch – Terraform は今、Amazon OpenSearch Service の完全に管理されたデータインジェスト層である Amazon OpenSearch Ingestion のデプロイメントをサポートするようになりました 。これにより、ペタバイト規模のデータを取り込んで処理した後に、Amazon OpenSearch が管理するクラスターやサーバーレスコレクションでデータをインデックス化することが可能になります。詳細については、この AWS ビッグデータブログ投稿 をご覧ください。 AWS Mainframe Modernization – AWS Blu Age Runtime は AWS Fargate 上の Amazon ECS でのシームレスなデプロイが可能になり 、サーバーレスコンテナで近代化されたアプリケーションを実行できるようになりました。 AWS Local Zones – アトランタに新設された Local Zones は 、リアルタイムゲーム、ハイブリッド移行、メディアやエンターテインメントのコンテンツの作成、ライブビデオストリーミング、エンジニアリングシミュレーションなど、ミリ秒単位の低遅延が求められるユーズケースに向けるアプリケーションをサポートします。 AWS からの発表の完全なリストについては、 「AWS の最新情報」ページ をご覧ください。 その他の AWS のニュース 皆さんが興味を持ちそうな追加のプロジェクト、プログラム、ニュース項目をいくつか紹介します。 PartyRock Hackathon は今月終了ですが、 まだ参加してコードなしのアプリを作る時間があります! これは、新しい場所を訪れる際に何をすべきかを計画するのに役立つクイックアプリのスクリーンショットです。 Amazon Bedrock のナレッジベースを用いた創薬のための RAG の使用 – 生成 AI の非常に興味深い使用例です。 複雑なクエリを生成および自動修正し、さまざまなデータソースにクエリを実行する、堅牢なテキストから SQL へのソリューションを構築するための 完全なソリューションを紹介します。 AWS での .NET 8 サポート の素敵な概要です。これはプラットフォーム全体の .NET の最新長期サポート (LTS) バージョンです。 AWS WAF トラフィック概要ダッシュボードの紹介 – AWS WAF によって保護されたアプリケーションのセキュリティ態勢について、情報に基づいた意思決定を支援する新しいツールです。 Mountpoint for Amazon S3 を使用してハイパフォーマンスコンピューティング (HPC) デプロイの速度とコストを改善する方法に関するヒントをいくつか紹介します。 Mountpoint for Amazon S3 は、コンピューティングインスタンスに S3 バケットをマウントし、ローカルファイルシステムとしてアクセスするために使用できるオープンソースのファイルクライアントです。 私の同僚である Ricardo が、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、デモをハイライトするこの 週刊オープンソースニュースレター を執筆しています。 今後の AWS イベント AWS Summit シーズンが戻ってきていることを実感していたはずです! 最初のイベントはヨーロッパで、 パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 ロンドン (4 月 24 日) で参加できます。3 月 12 日に ブリュッセルで開催される AWS 公共部門シンポジウム では、公共部門の業界リーダーや AWS の専門家に会うことができます。 AWS Innovate は、インフラストラクチャとアプリケーションを設計、デプロイ、運用するための適切なスキルを身に付けるのに役立つオンラインイベントです。 アメリカ大陸向けの AWS Innovate Generative AI + Data Edition は 3 月 14 日に開始されます。これは、2 月に開催したアジア太平洋地域と日本、EMEA のイベントに続くものです。 世界中の AWS ユーザーグループ および AWS クラウドクラブ からのボランティアが主催する AWS コミュニティ re:Invent re:Cap イベントがまだいくつかあります。これらのイベントでは、 AWS re:Invent からの最新の発表について知ることができます。 こちらで、近日中に開催されるすべての対面およびバーチャルイベントを 閲覧することができます 。 今週のニュースは以上です。3月11日週に次回 Weekly Roundup もお楽しみに! – Danilo この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

2月26日週、 Mistral AI モデルが Amazon Bedrock に導入される予定であること を発表しました。その記事では、Mistral AI モデルがお客様にとって最適である可能性がある理由をいくつか詳しく説明しました。Mistral AI は、コストとパフォーマンスのバランス、高速な推論速度、透明性と信頼を提供し、幅広いユーザーによるアクセスが可能です。 3月1日、2 つの高性能 Mistral AI モデルである Mistral 7B と Mixtral 8x7B が Amazon Bedrock で使用可能になったことを発表します。Mistral AI は、 AI21 Labs 、 Anthropic 、 Cohere 、 Meta 、 Stability AI 、 Amazon などの他の大手 AI 企業に次ぐ、Amazon Bedrock で最先端のモデルを提供する 7 番目の基盤モデルプロバイダーです。この統合により、Amazon Bedrock で最適な高性能基盤モデルを柔軟に選択できるようになります。 Mistral 7B は、Mistral AI の最初の基盤モデルであり、自然なコーディング機能で英語のテキスト生成タスクをサポートします。低レイテンシーを実現するために最適化されており、サイズの割にメモリ要件は低く、スループットは大きいです。Mixtral 8x7B は、テキストの要約、質疑応答、テキストの分類、テキスト補完、コード生成に最適な、人気のある高品質の Sparse Mixture-of-Experts (MoE) モデルです。 Amazon Bedrock で Mistral AI モデルがどのように見えるのかを次に示します。 Mistral AI モデルの開始方法 Amazon Bedrock で Mistral AI モデルの使用を開始するには、まずモデルにアクセスする必要があります。Amazon Bedrock コンソールで、 [モデルアクセス] を選択してから、 [モデルアクセスを管理] を選択します。次に、Mistral AI モデルを選択し、 [モデルアクセスをリクエスト] を選択します。 選択した Mistral AI モデルにアクセスできるようになったら、 [プレイグラウンド] セクションの [チャット] または [テキスト] でプロンプトを使用してモデルをテストできます。 Mistral AI モデルをプログラムで操作する また、 AWS コマンドラインインターフェイス (CLI) と AWS Software Development Kit (SDK) で Amazon Bedrock API を使用してさまざまな呼び出しを実行することもできます。AWS SDK を使用して Amazon Bedrock Runtime API を操作する Python のサンプルコードを次に示します。 import boto3 import json bedrock = boto3.client(service_name="bedrock-runtime") prompt = "<s>[INST] INSERT YOUR PROMPT HERE [/INST]" body = json.dumps({ "prompt": prompt, "max_tokens": 512, "top_p": 0.8, "temperature": 0.5, }) modelId = "mistral.mistral-7b-instruct-v0:2" accept = "application/json" contentType = "application/json" response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) print(json.loads(response.get('body').read())) Mistral AI モデルの動作 アプリケーションを AWS SDK と統合し、Amazon Bedrock を利用して Mistral AI モデルを呼び出すことで、さまざまなユースケースを実装する可能性を広げることができます。ここでは、サンプルプロンプトで Mistral AI モデルを使用する、私が個人的に気に入っているユースケースをいくつかご紹介します。その他の例については、Mistral AI ドキュメントページの「 プロンプト機能 」をご覧ください。 テキストの要約 – Mistral AI モデルは長い記事からでも要点を抽出できるため、重要なアイデアや核となるメッセージをすぐに把握できます。 You are a summarization system.In clear and concise language, provide three short summaries in bullet points of the following essay. # Essay: {insert essay text here} パーソナライゼーション – 言語の理解、推論、学習という AI の中核的な機能により、Mistral AI モデルはより人間らしい質のテキストを使用して回答をパーソナライズできます。Mistral AI モデルの精度、説明機能、多用途性により、個々のユーザーに合わせたコンテンツを提供できるため、パーソナライゼーションタスクに役立ちます。 You are a mortgage lender customer service bot, and your task is to create personalized email responses to address customer questions.Answer the customer's inquiry using the provided facts below.Ensure that your response is clear, concise, and directly addresses the customer's question.Address the customer in a friendly and professional manner.Sign the email with "Lender Customer Support." # Facts <INSERT FACTS AND INFORMATION HERE> # Email {insert customer email here} コード補完 – Mistral AI モデルは、自然言語とコード関連のタスクについて、非常に高い理解度を備えています。これは、コンピュータコードや通常の言語を使用する必要があるプロジェクトにとって不可欠です。Mistral AI モデルは、コードスニペットの生成、バグ修正の提案、既存のコードの最適化に役立ち、開発プロセスを加速します。 [INST] You are a code assistant.Your task is to generate a 5 valid JSON object based on the following properties: name: lastname: address: Just generate the JSON object without explanations: [/INST] 知っておくべきこと その他の情報をいくつかご紹介します。 利用可能なリージョン – Amazon Bedrock における Mistral AI の Mixtral 8x7B および Mistral 7B モデルは、米国西部 (オレゴン) リージョンでご利用いただけます。 Mistral 7B と Mixtral 8x7B の詳細 – Amazon Bedrock での Mistral AI モデルについてさらに詳しく知りたい場合は、私の同僚の Mike による「 Mistral AI – Winds of Change 」というタイトルの記事もぜひお読みください。 今すぐご利用いただけます Mistral AI モデルは現在、Amazon Bedrock でご利用いただけます。皆さんが構築するものを見るのが楽しみです。まずは、「 Mistral AI on Amazon Bedrock 」にアクセスしてください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2024 年 2 月 29 日に AWS オンラインセミナー「 プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 」を開催しました。 本イベントは、プラットフォームエンジニアリングの基本的な概要と現状について解説した上で、SRE や DevOps との関連性、どんな課題をどう解決するのか、実装するとなれば、AWS でどう実現するのかといった点についてご紹介させていただきました。400 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！ アジェンダ AWS メンバーから、プラットフォームエンジニアリングに関する 3 つのセッションを 2 時間でお届けしました。本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ チームとプラットフォームをクラウドネイティブな開発に最適化する (45 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Specialist Solutions Architect, Containers 林 政利 クラウドネイティブな開発では、アプリケーションとクラウドリソースの垣根はあいまいになり、開発チームと運用チームの役割も自ずと変化します。「運用チームがインフラストラクチャーを用意し、開発チームが作ったアプリケーションを載せる」という開発スタイルから、さまざまなクラウドの機能をネイティブに活用したクラウドネイティブ開発へと移行する組織にとって、「基盤 (プラットフォーム)」というものの考え方も大きく変わってくることになります。このセッションでは、プラットフォームエンジニアリングというアプローチを紹介し、クラウドネイティブな開発でどのようにチームと基盤を最適化するべきかご紹介します。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-1-team_platform_cloudnative.pdf 動画: https://youtu.be/Bs2hTbWJveo ちがいからみる Platform Engineering – クラウドネイティブ化に伴って生じた新たなチームトポロジー (45 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Tech Training Specialist 山田 遼太 近年、急速なデジタル変革が進む中で、企業は IT インフラストラクチャの信頼性と効率性を確保するために新たなアプローチを模索しています。そこで、Site Reliability Engineering（SRE）とプラットフォームエンジニアリングが注目を集めています。本セッションでは、SRE とプラットフォームエンジニアリングの役割と相違について探究します。どちらも IT インフラストラクチャに関する技術を扱いますが、責任範囲、目的、チームトポロジー、コミュニケーションスタイルなどが異なります。これらの異なる側面に焦点を当てながら、それぞれの役割がどのように組織において共存し、相互補完的になり得るかについて議論します。さらに、組織がプラットフォームエンジニアリングを導入する際の潜在的な利点や課題、実践的なエンジニアリングにおいて活用できる具体的な手法やベストプラクティスについても提案します。これにより、お客さまは組織のニーズや目標に合わせて、SRE とプラットフォームエンジニアリングを効果的に組み合わせ、持続可能な IT インフラストラクチャを構築するための手法を理解することができます。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-2-platformengineering_differences.pdf 動画: https://youtu.be/w6kDd5B4OSs Amazon ECS で実現するプラットフォームエンジニアリング (30 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Solutions Architect 後藤 健汰 ビジネスの拡大やサービスの増加に伴う開発組織の急速な規模拡大により、組織には様々な課題が生じます。そのような状況下で、開発者体験や生産性を向上させ、ビジネス価値の創出を加速することを目的とした「プラットフォームエンジニアリング」というアプローチが、近年注目を集めています。本セッションでは、開発組織が拡大する中で様々な課題を抱えている、または将来的に直面する可能性があると考えられるお客様が「プラットフォームエンジニアリング」を導入していく上で、抑えておくべき考慮事項や Amazon ECS をはじめとしたプラットフォーム構築に活用できる技術についてご紹介いたします。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-3-amazon_ecs_platformengineering.pdf 動画: https://youtu.be/u8KEQl1wIgU いただいた質問とその回答 セッション当日に頂いたご質問の中で、回答しきれなかったものをこの場で回答させていただきます。 Q. ストリームアラインドチームをプラットフォームエンジニアリングがサポートし負荷を軽減するゴールデンパスの例が IaC テンプレートの利用促進となる理解で正しいでしょか？ A. 正しいです。さらにいうと、テンプレートの利用促進だけではなく、ゴールデンパスのトレーニングや、アーキテクチャレビューもその一例になります。 Q. 受託開発では業務要件を組織内に持っておらず、これを整理し、かみ砕き、複数のコンポーネントを統合した時の結果を保証する必要があります。ストリームアラインドチーム型で構成する時には従来の SI 系開発と比較してこの分割統合の難易度がさらに上がると思うのですが、プラットフォームチームのような、ここをサポートする方法はあるのでしょうか。 A. 受託開発でプラットフォームエンジニアリングの難易度が上がる、というのはご認識の通りです。特に、アプリケーション実装の一部を受託開発して納品し、発注側で統合し、保守運用を他の会社に外注する、というような、ストリームが組織で細かく分断されているケースでプラットフォームエンジニアリングを導入することは現実的ではないでしょう。プラットフォームエンジニアリングは、DevOps の文化が下地にあるため、まずはストリームを「引き継ぐ」場面を最小化する必要があります。例えば、受託開発のスコープを技術的なコンポーネントを単位にするのではなく、ビジネスのユーザーストーリー単位とし、そのストーリーのストリーム、つまり開発から保守運用までを一貫して受注するようなビジネス構造が必要です。多くのストリームとストリームアラインドチームが並行して稼働している環境で、そのチームを支援するような疎結合なプラットフォームを構築できます。 Q. 分散型プラットフォームと中央集権型のプラットフォームはエンジニアの組織規模によってどちらが優れているとかありますでしょうか？ A. 「最小限のプラットフォームから始める」という観点からは、分散型のプラットフォームから検討するといいでしょう。チームの負荷やスケーラビリティが確保しやすくなります。そこから、エンジニアの組織規模によっては、すべてのチームで強制的に適用したいポリシーや開発手法もあるでしょう。このような部分に限って段階的に中央集権的なプラットフォームを導入していくことができます。例えば、AWS のアカウントは BLEA と AWS Control Tower で必要なポリシーが設定されたものを中央集権的に管理し、 アプリケーションのデプロイは CDK テンプレートを開発者に配布するという分散型のプラットフォームで運用するという構成も考えられます。 Q. プラットフォームチームは内製すべきでしょうか？内製するとしてプラットフォームチームはまずどういったメンバーで構成すべきですか？ A. プラットフォームチームは内製すべきです。これは、良いプラットフォームを作るためにサポート対象のストリームアラインドチームのフィードバックを受け続ける環境が必要だからです。一般的には、プラットフォームチームはクラウドインフラストラクチャーに詳しい運用チームのメンバーで構成されます。しかし、ストリームアラインドチームをサポートするには、ソフトウェア開発の経験が必要です。これは、CI/CD やソースコードの管理戦略、テスト戦略、アプリケーションモニタリングなどが含まれます。このような経験や知識を持つメンバーもあわせてプラットフォームチームを構成するといいでしょう。 Q. 中央集権型プラットフォームモデルと従来型の開発/運用分立モデルの明確な相違点は何でしょうか。（従来の「アプリケーション開発チーム」「運用チーム」が「ストリームアラインドチーム」と「プラットフォームチーム」に名前が変わっただけのようにも見えます） A. 明確な相違点は、チームの自律性です。中央集権型のプラットフォームモデルであっても、プラットフォームエンジニアリングの文化ではストリームアラインドチームは自律的に設計、開発、運用を行います。プラットフォームが使いやすいものであれば採用するし、そうでなければ採用しません。逆に、「プラットフォーム」を運用しているチームが、別チームの作ったアプリケーションを引き継いで運用している、というような状態であれば、従来の開発/運用分立モデルと同じだと言えるでしょう。 Q. プラットフォームチームが行うテンプレートのサポートを AmazonQ が代替できる場合、ストリームアラインドチームが直接 AmazonQ を利用する形態でプラットフォームエンジニアリングが成立しますでしょうか？ A. 成立します。しかし、Amazon Q が提案したテンプレートが本当に要件に合うものか判断できる知見がストリームアラインドチームには必要になります。もし、現時点でそうした知見に不安があるようであれば、プラットフォームチームはさらにレビューやトレーニングをストリームアラインドチームへ提供するというサポートが必要です。 Q. 中央集権型のプラットフォームの実現方法として k8s を利用したものが例として上がっていましたが、ECS を利用した場合の具体的なイメージを知りたいんですが何か良い資料はないでしょうか？ A. 本セミナーの「Amazon ECS で実現するプラットフォームエンジニアリング」のセッションで、ECS を前提にした具体的なイメージが紹介されておりますので、ぜひご参照ください Q. 分散型のプラットフォームでは、ストリームアラインドチームからプラットフォームへの実運用 IaC コードなどのフィードバックも GitHub などで管理する認識でよいでしょうか、それともサンプルコードのフィードバックだけを受けるのでしょうか A. これは、プラットフォームエンジニアリング導入のフェーズで変わる部分です。最初は、サンプルコードを提供して、そのフィードバックを受けます。このフェーズでは、プラットフォームチームはストリームアラインドチームと並走してサンプルコードを参考にしたアプリケーション開発、運用のフィードバックを受けることになるでしょう。そして、ストリームアラインドチームの運用が進んだ段階で、サンプルコードを汎用化し、GitHub で管理し、さらに広いストリームアラインドチームへ配布してフィードバックを受けるフェーズへ進みます。もちろん、すでに実運用されているシステムがあれば、サンプルコードを提供するフェーズをスキップして、その内容を直接汎用化することも考えられます。 Q. 弊社では中央集権型のプラットフォームレイヤーを設けており、AWS 上でインフラ構築をしておりますが、成果として構築されたインフラが開発チームのニーズを満たさず、結果として開発チームが調査しプラットフォームチームに修正を依頼しており、開発チームの負荷の増大や開発スケジュールの遅延の原因となっております。プラットフォームチームに「アプリを良く動かすためのインフラの構築」をさせるための方策等あればご教授いただけませんでしょうか。 A. プラットフォームエンジニアリングの観点からは、次に挙げる二点で開発チームのニーズを満たすことが考えられます。まず、「中央集権型のプラットフォーム」が何を提供するのか、というのを明確にします。そして、提供する機能がプラットフォームが開発チームの要件を満たさない部分は、分散型のプラットフォームの考え方を採用し、自律的に作業を行えるようにする、ということが重要です。プラットフォームエンジニアリングのベースにはチームの考え方があり、チームに自律性と必要な権限がなければ実践が難しいというのが実際のところです。また、プラットフォームはプロダクトとして開発する必要があり、例えば開発チームの KPI のような明確な品質の基準を設けるということも重要になるでしょう。 Q. 方法論を DevOps に変えていきたいという現場要求はありつつ、外的な要求、例えば認証規格 (ISO27017 ISMSクラウドセキュリティだとか) によりある程度手法の制約が出るケースがあると思います。社内は頑張って説得するにしても、対外的には(例えば監査機関に)何かしらロジカルに回答する必要があるわけですが、どんなアプローチを取っていったらいいのでしょうか。 A. 適切な回答のためには、準拠すべき要件の土台となる原理・原則や、その要求の背景を学び、解釈をアップデートしていく必要があります。具体的なアプローチとしては「 The Era Of DevSecOps ～AWSサービスによる DevOps とセキュリティのマリアージュ～ 」という発表の中でも触れられておりますので、ぜひご参照ください。 Q. 19 頁 The ROAD to SRE？ Devops でなくとも普通にやることやらないといけないことのように思えましたがどういう意図の説明でしたでしょうか？ 「 The ROAD to SRE 」は、SRE で取り組むべきことについて記述された Medium の記事を参考にお話しさせていただきました。SRE の実践を組織に導入する方法はいくつかありますが、どこから始めればいいか迷うことがあります。具体的なエリアを4 つ示すことで、SRE が具体的にどのエリアの信頼性に関する取り組みを行うのかについて説明させていただきました。 Q. ツーピザチームの自主的に機能するための権限というのは、例えばどのような権限になりますでしょうか? 予算とか、アーキテクチャ選択の自由等でしょうか? A. ツー・ピザ・チームが自律的に機能するためには、権限と環境の両方が揃っていることが重要です。権限については、ツー・ピザ・チームがお客様のために独立してイノベーションを起こすことができる権限が必要と考えています。従来型の組織構造では、上層部での意思決定によって方針が決まり、具体的なアクションを遂行することのみを求められるような場合があります。一方で、ツー・ピザ・チームは、お客さまに最高の価値を届けるために、チーム内で自ら決断しアクションを遂行します。ここには、技術選定に関わるものから、どのプロジェクトに注力するか、アイデアの創出から実行、継続的な業務改善から絶え間ない製品のイテレーションやイノベーションに至るまであらゆるものに対する権限が含まれます。もう一つの環境の観点では、範囲内での予算を利用できることや、サービスをエンドツーエンドで所有して実行するのに必要なリソース (エンジニアリング、テスト、製品とプログラムの管理、運用など) がチームに組み込まれていることなどイノベーションを起こす上で必要なあらゆるものが含まれています。ただし、自律性と無秩序は別物です。Amazon では無秩序にならないよう適切なレベルの監督体制を確立します。ここでは従来のように上層部がすべての意思決定で乗り越えなければならない障壁となるわけではありません。むしろ、障害を取り除くことをサポートします。Amazon において組織を監督するために用いられている仕組みの 1 つにナラティブと呼ばれる文書があります。Amazon では、新しいサービスのリリース前に運用上の準備状況を厳密にレビューし、サービスのアーキテクチャ、そのリリースの質と手順、および関連するインシデントやイベントの管理手順のさまざまな側面が適切に定められ、文書化するために詳細な確認を行うナラティブを用意しています。ツー・ピザ・チームは説明責任を果たすために、決められたナラティブを作成し提供しなければなりません。 Q. Platform というものがよくわからないです。内部の開発チームに所属している方から品質に不安があるという声があがっています。そういった品質的な部分は Platform Team にお願いして品質の向上基盤、テスト自動化などの API を platform として提供してもらうとかもできるのでしょうか？それらも局所的な要件になるのですか？ A. 特定の課題がプラットフォームによって提供されるべき課題かどうかというのは、組織全体が抱えている課題の状況によって異なります。多くの開発チーム（ストリームアラインドチーム）が抱えている共通の認知負荷であれば、プラットフォームチームにによって解決できるようなプロダクトを作成するチャンスと捉えられます。もしプラットフォームとして課題解決をする場合は、開発チームはプラットフォームチームに対して適切なフィードバックを提供する、機能要求を送るなどのコラボレーションをしながら、適切なプロダクトの開発をサポートすることが推奨されます。 Q. EmbeddedSRE の認知負荷がすごく大きくなるような気がしますがどうなのでしょうか？ A. Embedded SRE チームには、信頼性に関わる技術的に際立った専門性を有しているメンバーを集めます。また、チームにアサインされた場合も、アサインされたチームが抱えている信頼性に関する課題解決や、信頼性に関わる知識の移譲を行うため、サービス自体に関するドメイン知識が求められることはありません。 Q. AWS における two pizza teamとは、特定サービスに強い権限を持つ少数のサービスアラインドチームという理解で相違ないでしょうか？ A. はい。詳しくは、「 高いパフォーマンスを発揮する組織 – Amazon ピザ 2 枚チーム | AWS Executive Insights 」をご確認ください。 Q. プロトタイプエンジニアとプラットフォームエンジニアの違いはなんなのでしょうか？ A. 一般的にプロトタイプエンジニアは「特定の顧客のユースケースを実現するプロトタイプを開発し、技術的な実現性を確認する」ことを責務として持つロールです。それに対してプラットフォームエンジニアは、ストリームアラインドチームの認知負荷を軽減し開発生産性を高めることを目的とした「プラットフォーム」を開発・運用することを責務として持つロールになります。両方ともにストリームアラインドチームを支援しますが、異なる責務を持ったロールと言えます。 Q. プラットフォームチームは、一般的な組織としてどの部署（情シスのインフラチームとか。。）が担当するのが一般的なのでしょうか？また、兼務したりするのでしょうか？ A. 一般的には、プラットフォームを開発するケイパビリティを持った人材でプラットフォームチームを組成することが多いと考えています。兼務については開発組織の文化などにもよりますが、プラットフォームの開発においては、開発チームと積極的にコラボレーションをする必要があるので、開発チームに対して一定のコミットを求める必要があります。 Q. 責務の分担はプロジェクト開始タイミングで決めた方が良いと思いますが、プロジェクト開始前に開発と運用のマネージャー層だけで決めた方が良いのでしょうか。それとも開始直後にメンバーにヒアリングして現場の意見も含めた方が良いのでしょうか。トップダウン、ボトムアップのどちらの方が成功しやすいのか、実績などからお分かりでしたらご教示ください。 A. 現場の意見を踏まえた上で、最終的にはマネージャー層の合意が必要だと考えています。開発チームの教育などにも一定のコストがかかる可能性があるため、現場のメンバーだけでは決められず、また責務分担の現実的な落とし所を決める際には現場のメンバーの意見が重要になるためです。 Q. セッション３のゴールデンパスの実装において、IaC テンプレートの抽象化のレベルをどう決定していくかに悩んでいます。決定の仕方や、例などを教えていただくことはできるでしょうか。 A. 様々な要因がありますが、開発チームが持っている技術的なナレッジを考慮する、というのは大切です。また「どの程度抽象化するべきか」についてユーザーにヒアリングをしながら決めていく、というのも有効な方法になります。もし抽象化の必要がなくカスタマイズ性を重視するのであれば、一切抽象化していない IaC コードをテンプレートとして提供するというのも、選択肢の一つになりえます。 Q. プラットフォームチームの運用負荷を下げる事が容易になる AWS サービス一覧はありますでしょうか？ A. プラットフォームの構成によって、様々な AWS サービスが活用できます。例えば、プラットフォームチームによる AWS アカウントの管理や統制を支援するサービスとして AWS Control Tower や AWS Control Tower Account Factory といったサービスがあります。 Q. 開発チームとプラットフォームチームがスキルや文化の違い、コミュニケーション不足などで衝突している場面を多くの現場で見かけますが、プロジェクトが成功するためにプラットフォームチームが心がけるポイントなどはございますか？ A. 開発チームへのスキルトランスファーや文化の啓蒙も、プラットフォームチームの責務のひとつです。具体的には、ユーザーのニーズに対応する適切なドキュメントを整備するであったり、開発チーム向けの勉強会やデモを提供するといった、Platform as a Product の思想に基いた活動が大切です。 Q. TVPという考え方がありました。これであれば、あまり深かけずにできることから実現できそうですが、プラットフォームエンジニアリングを選ばないほうが良いケースってどういうものがありますか？ A. プラットフォームエンジニアリングのアプローチを適用すべきかどうかは、現在の開発組織が抱える課題について明らかにした上で、その課題を改善するためにプラットフォームエンジニアリングが必要かを明らかにする必要があります。 こちらのブログ に開発組織の運用モデルの評価について記載がありますので、ぜひご参照ください。 Q. 非常にためになるセミナーを開催頂きありがとうございます。以下、ご教授願います。複数のシステムを運用しており、各システムはそれぞれアカウント（システムごと、本番、開発ごと）が異なっている状況下です。AWS 上でプラットフォーム（例えば CICD 機能など）を提供する場合にこのようなプラットフォームは 1 つのアカウントに集約して各システムとクロスアカウントで連携するのが望ましいのか、もしくは各アカウントに部品を提供していく形で連携するのが望ましいのか。指標や考え方があればご教授頂きたい。 A. ひとつの考え方として、提供する「部品」の責務を持つのはどのチームか？によって決定するという考え方があります。もし CI/CD パイプラインの責務を開発チームに持たせるのであれば、各 AWS アカウントに配置した方が、トラブルシュート時の確認などが容易に実現できます。 おわりに 本セミナーにご参加いただいた皆様、改めてありがとうございました。今後も様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。

ノーベル賞受賞者のダニエル・カーネマンによる世界的なベストセラー「ファスト & スロー あなたの意思はどのように決まるか?」によると、人々は直感的もしくは論理的に意思決定を行います。直感は迅速な意思決定につながり、合理的思考は意思決定を遅らせます。組織においては、その逆です。直感は長い意思決定プロセスにつながり、データや事実に基づく意思決定はプロセスの短縮につながります。 直感ドリブン ( 訳註 : データドリブンとは対照的に、意思決定が誰かの直感に基づいていること ) のカルチャーでは、他人は誰かの証明不能な直感に従うことになります。意見がぶつかり合い、最終的に勝つのは、最も素晴らしいストーリーを語れる人か、最も給料が高い人です。データドリブンの組織は通常、より少ない議論でより高い成功確率の意思決定を、より迅速に行います。 しかし、データドリブンのカルチャーを採用することは容易ではありません。確立された行動を変えなければならず、意思決定に必要なデータはしばしば入手できず、正しく解釈できません。 「意見」を「疑問と実験」に変える 経験や直感、信念に基づく自己主張は、議論や意思決定プロセスを開始するのに役立つ重要な資質です。直感ドリブンの組織では、人々は、意見から解決策へとすぐに飛躍します。意見はしばしば感嘆符 ( ! ) 付きで表現され、別の感嘆符 ( ! ) 付きの意見が重ねられます。 データドリブンの組織では、意見の最後に疑問符 ( ? ) が付き、「試してみよう」という返答を引き出します。意見は疑問につながり、それが仮説となって小規模に試行され、検証されます。あらゆる観点と結果を比較検討した経験のある人々は、データと実験の結果に基づいて意思決定を行います。 意思決定プロセスを導くのは直感ではなく、対象を絞った実験からのデータです。 「無作為なデータ保存」から、「意図的なインサイトの生成」へと変える データドリブンのカルチャーを取り入れたい組織はしばしば、データがない、データが多すぎる、または意味のないデータを持っていることに気づきます。これは通常、データが無計画で保存されているためです。データウェアハウスとデータレイクはフリーマーケットになり、場合によっては貴重なものを見つけることができますが、ほとんどのアイテムは役に立たず、コストに見合う価値もありません。 データドリブンの組織は、特定の課題に特化したデータを生成します。彼らは意見を裏付けるための実験を定義して実施し、必要となる正確なデータとインサイトを生み出します。質問、意味、構文に応じて、さまざまなテクノロジーを使用してデータを保存、処理、分析、視覚化します。データは特定の明示的な目的で収集され ( 目的制限 ) 、処理される理由から必要なものに限定されるため ( データ最小化 ) 、データ保護にも役立ちます。 AWS は、エンドツーエンドのデータ戦略の構築に役立つテクノロジーを提供しています。 (データを使って組織を改革する方法の詳細については、 AWS for Data をご覧ください。) 「ストーリーの語り聞かせ」から「データリテラシー」へ変える 直感ドリブンの組織では、無数のパワーポイントスライドを使用してストーリーを伝えることが不可欠なスキルとなり、意思決定会議というよりも、サーカスのショーになってしまうことがよくあります。データと統計は使われていますが、それは「ストーリー」を裏付けるためだけに使われています。これらの統計は文脈から外れていることが多く、特にフォーキャストは統計的に有意ではありません。 多くの組織では、従業員は合計と平均を理解しています。しかし、彼らは中央値、標準偏差、パーセンタイル、またはコホートを理解していません。データを適切に生成、準備、特に視覚化する方法を知りません。組織によっては、ほぼ毎年、より新しく、より便利で、よりカラフルなビジネスインテリジェンスツールを導入しているのに、ツールの使い方は言うまでもなく、基本的なデータリテラシー ( 訳註 : データを適切に読み、分析し、伝える能力 ) について従業員にトレーニングすることを忘れています。 一方、データドリブン組織では、ストーリーの語り聞かせは意図的に制限され、データに基づく推論が優先されます。たとえば、AWS では、社内の意思決定の基礎として、プレゼンテーションの代わりにドキュメントを使用しています。 これにより、誰もが意思決定者になることができます。お客様のことを念頭に置いて、より迅速に意思決定が下されます。 Matthias Patzak Matthias は AWS ソリューションアーキテクチャのプリンシパルアドバイザーを務めた後、2023 年初頭にエンタープライズストラテジストチームに加わりました。この役職では、マティアスは経営陣と協力して、クラウドがイノベーションのスピードやITの効率を高め、自社のテクノロジーが生み出すビジネス価値を高めるのにどのように役立つかについて、人、プロセス、テクノロジーの観点から検討しています。AWS に入社する前は、マティアスは AutoScout24 で IT 担当副社長を務め、Home Shopping Europe でマネージングディレクターを務めていました。両社とも、リーン・アジャイルのオペレーションモデルを大規模に導入し、クラウドトランスフォーメーションを成功させた結果、納期の短縮、ビジネス価値の向上、企業価値の向上を実現しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

これまでの年月を経て、ユーザーが検索エンジンに期待するものは進化してきました。ほとんどのユーザーにとって、迅速に文字通りに関連性の高い結果を返すだけでは、もはや十分とはいえません。今では、ユーザーは意味的理解を通じてさらに関連性の高い結果を取得したり、メタデータのテキスト検索ではなく画像の視覚的類似性を通じて検索することを可能にする方法を求めています。 Amazon OpenSearch Service には、検索エクスペリエンスを強化できる多くの機能が含まれています。2023 年にそのツールキットに追加した OpenSearch Service の機能と拡張についてうれしく思っています。 2023 年は、人工知能 (AI) と機械学習 (ML) の分野で急速なイノベーションがあった年であり、検索はその進歩の大きな受益者となりました。2023年を通じて、Amazon OpenSearch Service は、アプリケーションの書き換えやカスタムオーケストレーションの構築を行うことなく、最新の AI/ML テクノロジーを利用して既存の検索エクスペリエンスを改善および拡張できるよう、検索チームをサポートする投資を行ってきました。これにより、迅速な開発、反復、製品化が可能になります。 これらの投資には、新しい検索メソッドの導入と、利用可能なメソッドの実装を簡素化する機能が含まれています。本記事では、これらの機能を振り返っていきます。 背景: レキシカル検索とセマンティック検索 まず始めに、レキシカル検索とセマンティック検索の違いを確認しておきましょう。 レキシカル検索 レキシカル検索では、検索エンジンが検索クエリの単語とドキュメントの単語を比較し、単語と単語が一致するかどうかを照合します。 ユーザーが入力した単語を含むアイテムのみがクエリと一致します。BM25 のような用語頻度モデルに基づく従来のレキシカル検索は、広く使用されており、多くの検索アプリケーションでは効果的です。 しかし、レキシカル検索技術は、ユーザーのクエリに含まれる単語を超えて進むことが困難であり、その結果、高い関連性を持つ潜在的な結果が常に返されているとは限りません。 セマンティック検索 セマンティック検索では、検索エンジンは ML モデルを使用して、ソースドキュメントのテキストやその他のメディア(画像や動画など)を高次元のベクトル空間内の密ベクトル (dense vector) としてエンコードします。これはテキストをベクトル空間に埋め込むことから、「埋め込み」とも呼ばれます。同様にクエリもベクトルとしエンコードし、次に距離メトリックを使用して多次元空間内の近傍ベクトルから一致するものを探索します。近傍ベクトルを探索するアルゴリズムは k 最近傍 (k-NN) と呼ばれます。セマンティック検索は個々のクエリ用語とのマッチングを行いません。ベクトル空間内でクエリのベクトル埋め込みに近いベクトル埋め込みを持つドキュメントを見つけます。そのため、クエリに含まれる単語のいずれも含まない場合でも、クエリと意味的に類似した関連性の高いアイテムを返すことができます。 OpenSearch は数年にわたりベクトル類似性検索 (k-NN および Approximate k-NN)を提供してきました。この取り組みは、本機能を採用した顧客にとって貴重なものとなりました。 しかし、k-NN の恩恵を受ける機会のあるすべての顧客が本機能を採用したわけではありません。その理由は、採用にあたり、相当なエンジニアリング努力とリソースが必要であるためです。 2023年のリリース: 基本事項 2023 年に、OpenSearch Service でいくつかの機能と改善がリリースされました。これには、検索機能の継続的な強化のための基本的な構成要素である新機能が含まれています。 OpenSearch Compare Search Results ツール Compare Search Results は、OpenSearch Service バージョン 2.11 より一般提供されている、OpenSearch Dashboards 上で 2 つのランキング技術の検索結果を並べて比較できるツールです。本ツールにより、あるクエリが別のクエリよりも良い結果を生み出すか判断できます。ML アシステッドモデルによって動作する最新の検索手法を試したいユーザーにとって、検索結果の比較機能は欠かせません。また、自社のコーパスに対して、各手法のメリットを理解するために、レキシカル検索、セマンティック検索、ハイブリッド検索技術を比較したり、フィールド重み付けやステミングや、レンマ化の戦略のような調整を比較することもできます。 次のスクリーンショットは、Compare Search Results ツールの使用例を示しています。 セマンティック検索およびクロスモーダル検索の詳細や、Compare Search Results ツールのデモを試すには、 Amazon OpenSearch Service ベクトルエンジンを使用したセマンティック検索の試行 を参照してください。 Search pipelines 検索の実践者は、検索クエリと結果を強化する新しい方法を導入しようとしています。OpenSearch Service バージョン 2.9 から一般提供されている Search pipelines を使用すると、アプリケーションソフトウェアを複雑にすることなく、検索クエリと結果の処理をモジュール化された処理ステップの組み合わせで構築できます。フィルタなどの関数のプロセッサを統合し、新しく格納されたドキュメントに対してスクリプトを実行する機能を追加することで、検索アプリケーションの精度と効率を高め、カスタム開発の必要性を減らすことができます。 検索パイプラインには、filter_query、rename_field、script request の3つの組み込みプロセッサに加えて、独自のプロセッサを構築したい開発者向けの新しい開発者中心の API が組み込まれています。OpenSearch は、今後のリリースでこの機能をさらに拡張するために、追加の組み込みプロセッサを継続的に追加していきます。 次の図は、検索パイプラインのアーキテクチャを示しています。 Byte-sized vectors in Lucene これまで、OpenSearch の k-NN プラグインは、ベクトル要素が 4 バイトを占有する float 型のベクトルのインデックス作成とクエリをサポートしてきました。これはメモリとストレージの両面でコストがかかる場合があります。特に大規模なユースケースでは顕著です。 OpenSearch Service バージョン 2.9 から利用可能な新しい byte 型のベクトルを使用することで、メモリ必要量を 4 分の 1 に削減し、クオリティ(再現率)の大きな低下なく検索レイテンシを大幅に短縮できます。 詳細は、 OpenSearch のバイト量子化ベクトル をご参照ください。 新しい言語アナライザのサポート OpenSearch Service は以前より、IK (中国語)、Kuromoji (日本語)、Seunjeon (韓国語)など、複数の言語アナライザープラグインをサポートしていました。新たに、Nori(韓国語)、Sudachi (日本語)、Pinyin (中国語)、STConvert Analysis (中国語)のサポートを追加しました。これらの新しいプラグインは、TXT-DICTIONARY パッケージタイプに加えて、ZIP-PLUGIN という新しいパッケージタイプとして利用できます。OpenSearch Service コンソールの [パッケージ] ページや、AssociatePackage API を使用することでこれらのプラグインをクラスターに関連付けられます。 2023年のリリース: 操作性の向上 OpenSearch Service は、2023年に主要な検索機能内の使いやすさを向上させる改善も行いました。 Neural search によるセマンティック検索 これまで、セマンティック検索を実装するには、テキスト埋め込みモデルを検索とインジェストに統合するためのミドルウェアをアプリケーションが担当し、コーパスのエンコードをオーケストレーションし、クエリ時に k-NN 検索を使用する必要がありました。 OpenSearch Service はバージョン 2.9 で Neural search を導入し、開発者が大幅に軽減された定型作業なしにセマンティック検索アプリケーションを構築および運用できるようにしました。セマンティック検索では、テキストクエリからベクトルを生成し k-NN クエリを呼び出すため、 アプリケーションでドキュメントやクエリのベクトル化を行う必要がありません。 Neural search 機能によるセマンティック検索は、ドキュメントやその他のメディアをベクトル埋め込みに変換し、テキストとそのベクトル埋め込みの両方をベクトルインデックスに格納します。 検索時にニューラルクエリを使用すると、Neural search はクエリテキストをベクトル埋め込みに変換し、ベクトル検索を使用してクエリとドキュメントの埋め込みを比較し、最も近い結果を返します。 この機能は OpenSearch Service バージョン 2.4 で当初実験的にリリースされ、バージョン 2.9 で一般提供されるようになりました。 AI/ML コネクタによる AI パワー検索機能の実現 OpenSearch Service 2.9 より、Neural search のような機能を実現するために、AWS の AI と ML サービスやサードパーティの代替サービスとの接続が可能な、すぐに利用できる AI コネクタを提供しました。 たとえば、本番環境でモデルを適切に管理するための包括的な機能を提供する Amazon SageMaker 上にホストされた外部の ML モデルに接続できます。 フルマネージドな体験を通じて最新のファンデーションモデルを使用したい場合は、マルチモーダル検索のようなユースケースを実現するために Amazon Bedrock のコネクタを使用できます。 当初のリリースには Cohere Embed へのコネクタが含まれており、SageMaker と Amazon Bedrock を通じて、さらに多くのサードパーティのオプションにアクセスできます。 これらの統合の一部は、 OpenSearch Service コンソールの統合 (次のスクリーンショットを参照)を介してドメインで構成でき、SageMaker へのモデルの自動デプロイも可能です。 統合モデルは OpenSearch Service ドメインにカタログ化されるため、チームは統合され利用可能な様々なモデルを発見できます。モデルとコネクタのリソースについて細かいセキュリティ制御を有効にするオプションがあり、モデルとコネクタレベルのアクセスを管理できます。 オープンなエコシステムを育成するために、パートナーがAIコネクタを簡単に構築および公開できるフレームワークを作成しました。テクノロジープロバイダーは、OpenSearch と自社サービス間のセキュアな RESTful 通信を記述したJSONドキュメントである ブループリント を簡単に作成できます。テクノロジーパートナーはコミュニティサイトで自社のコネクタを公開でき、セルフマネージドクラスタや OpenSearch Service で、これらのAIコネクタをすぐに利用できます。各コネクタのブループリントは、 ML Commons GitHubリポジトリ で参照できます。 スコアの組み合わせによってサポートされるハイブリッド検索 Neural search のためのベクトル埋め込みや自然言語処理のための大規模言語モデル (LLM) などのセマンティック技術は、検索を革新し、手動の同義語リスト管理や微調整の必要性を減らしました。 一方で、テキストベース(レキシカル)検索は、部品番号やブランド名などの重要なケースでセマンティック検索よりも高いパフォーマンスを発揮します。ハイブリッド検索は2つの方法を組み合わせたもので、BM25単体と比較して14%高い検索の適合率(NDCG@10で測定 – ランキング品質の尺度)を実現するため、ユーザーは両方の長所を活かすためにハイブリッド検索を利用したいと考えています。スコアの正確性とパフォーマンスの詳細なベンチマークについては、 OpenSearch 2.10 で一般公開されたハイブリッド検索による検索の適合率向上 を参照してください。 これまで、各メソッドの関連性スケールの違いから、これらを組み合わせることは困難でした。以前はハイブリッドアプローチを実装するために、複数のクエリを個別に実行し、スコアの正規化と結合を OpenSearch の外で行う必要がありました。OpenSearch Service 2.11 で導入された新しい ハイブリッドスコアの組み合わせと正規化 クエリタイプを使用することで、OpenSearch が 1 つのクエリ内でスコアの正規化と結合を処理できるようになりました。これによりハイブリッド検索の実装が容易になり、検索の関連性を向上させるより効率的な方法が実現できました。 新しい検索方法 最後に、OpenSearch Service に追加された新しい検索メソッドを紹介します。 Neural sparse search OpenSearch Service 2.11 では、 Neural sparse search が導入されました。これは、従来の用語ベースのインデックスとよく似た新しい種類のスパース埋め込みメソッドですが、低頻度の単語とフレーズがより適切に表現されています。スパースセマンティック検索は、トランスフォーマーモデル(BERT など)を使用して、語彙のミスマッチ問題をスケーラブルな方法で解決する情報豊富な埋め込みを構築します。これにより、レキシカル検索と同様の計算コストとレイテンシを発揮できます。OpenSearch におけるこの新しい Sparse search 機能は、それぞれ異なる利点を持つ 2 つのモードを提供します。ドキュメントのみのモードと、バイエンコーダーモードです。ドキュメントのみのモードは、BM25 検索に匹敵する低レイテンシーなパフォーマンスを発揮できますが、密な方法と比較して高度な構文の制限があります。バイエンコーダーモードは、より高いレイテンシーで実行しながらも、検索の関連性を最大化できます。このアップデートにより、パフォーマンス、精度、コストの要件に最適なメソッドを選択できるようになりました。 マルチモーダル検索 OpenSearch Service 2.11 では、Neural search を使用したテキストと画像のマルチモーダル検索が導入されました。この機能により、製品カタログのアイテム(製品画像と説明文)のような画像とテキストのペアを、視覚的および意味的な類似性に基づいて検索できるようになります。これにより、より適切な結果を提供できる新しい検索エクスペリエンスが可能になります。例えば、「白いブラウス」で検索することで、製品タイトルが「クリーム色のシャツ」であっても、その説明に一致する画像の製品を検索できます。このエクスペリエンスを実現している機械学習モデルは、意味と視覚的特徴を関連付けることができます。画像で検索して視覚的に類似した製品を検索したり、テキストと画像の両方で検索して、特定の製品カタログアイテムに最も類似した製品を見つけることもできます。 アプリケーションにこれらの機能を組み込むことで、カスタムミドルウェアを構築することなく、マルチモーダルモデルに直接接続し、マルチモーダル検索クエリを実行できるようになりました。Amazon Titan Multimodal Embeddings モデルは、この方法をサポートするために OpenSearch Service と統合できます。マルチモーダルセマンティック検索を始める方法のガイダンスについては、 マルチモーダル検索 を参照してください。また、今後のリリースでさらに入力タイプが追加されることをご期待ください。また、 テキストと画像の クロスモーダル検索のデモ を試すこともできます。これは、テキストの説明を使用して画像を検索する方法を示しています。 まとめ OpenSearch Service は、検索アプリケーションを構築するためのさまざまなツールを提供していますが、最適な実装は、コーパスやビジネスニーズ、目標によって異なります。検索の実践者の方には、ユースケースに適したものを見つけるために、 利用可能な検索メソッド のテストを開始することをおすすめします。2024 年以降も、OpenSearch の検索実践者が最新・最高の検索テクノロジーを手元で利用できるよう、速いペースでの検索イノベーションが続くことが期待されます。 著者について Dagney Braun は、Amazon Web Services の OpenSearch チームのプロダクト シニア マネージャーです。 OpenSearch の使いやすさを向上させ、すべてのお客様のユースケースをより良くサポートするためのツールを拡張することに熱心です。 Stavros Macrakis は、Amazon Web Services の OpenSearch プロジェクトのシニアテクニカルプロダクトマネージャーです。検索結果の品質を向上させるツールを顧客に提供することに熱心です。 Dylan Tong は、Amazon Web Services のシニアプロダクトマネージャーです。 OpenSearch のベクトルデータベース機能を含む AI と機械学習 (ML) に関する OpenSearch の製品イニシアチブを率いています。Dylan は、データベース、アナリティクス、AI/ML ドメインの製品とソリューションの作成において、顧客と直接働く経験を数十年にわたって積んでいます。Dylan はコーネル大学でコンピュータサイエンスの学士号と修士号を持っています。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文は こちら です。

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 &amp; データエディション を視聴する時間がまだあります。Innovate Online イベントは無料のオンラインイベントで、AWS での構築に関するインスピレーションを得て、知識を深めてもらうことを目的としています。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA 地域のいずれであるかにかかわらず、 お客様のタイムゾーンで今後開催される AWS Innovate Online イベントについては、こちらをご覧ください 。 AWS コミュニティ re:Invent re:Cap&nbsp;–&nbsp;世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent からの最新の発表について学びましょう。 こちらで、 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます 。 2月26日週のニュースは以上です。3月4日週に次回 Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、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) &nbsp;メキシコを拠点とする証券取引所です。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 引き続きご期待ください。 –&nbsp; 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:*:: &lt;foundation-model&gt; / &lt;model-id-of-model-to-allow&gt; } } この場合、最小権限を実装するにはどうすればよいでしょうか。ほとんどのシナリオでは、アプリケーションレイヤーが 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&nbsp; ～レジリエントな未来：生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント～」&nbsp;のご案内 2024 年 3 月 19 日に東京にて表題のイベントが開催されます。本イベントでは、生成 AI の活用やクラウドの活用の最新動向および生成 AI の押さえるべきポイント、AWS 内の取り組みについて米国セキュリティ部門のディレクターが直接解説します。また、有識者や外部ゲストを迎え、クラウドにおけるセキュリティ、リスクマネジメントに焦点を当てた各種対策を具体的に解説します。ご希望の方は、 こちらから ご登録をお願いいたします。