みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 What’s New にお知らせが無く先週の 週刊AWS で紹介が出来なかったのですが、注目度が高いため冒頭に紹介させてください。Amazon Bedrock 関連の 3 機能が東京リージョンで提供を開始しました。RAG 機能の実装を支援する Knowledge bases for Amazon Bedrock、幅広いユースケースや複雑なタスクの実行をサポートする Agents for Amazon Bedrock、責任ある AI のためにセーフガードの仕組みを導入できる Guardrails for Amazon Bedrock の 3 つが提供されています。生成 AI でより本格的で複雑なことを実現しようと思った際に、これらの機能を使って実現の手間を低減できます。ぜひ東京リージョンでもご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年5月6日週の主要なアップデート 5/6(月) AWS Amplify Gen 2 is now generally available AWS Amplify Gen 2 の一般提供を開始しました。Gen 2 は、コードファーストの開発体験がコンセプトとなっており、フロントエンドエンジニアが利用する TypeScript 言語をそのまま活用して、認証バックエンド、データバックエンド、ストレージバックエンドなどの構成を表現し、構築が出来ます。元々の Gen 1 Amplify ではバックエンド環境を構築するときに、Amplify CLI を利用して構築しており、使い方の学習や、実現できる内容を理解するハードルがありました。Gen 2 は、TypeScript でコードを基にバックエンドを表現できるようになり、IDE 上の IntelliSense 自動補完機能を活用しながら、プログラマに馴染みのある手法で開発がやりやすくなりました。新たに Amplify を利用する場合は、Gen 2 の利用をおすすめします。Gen 1 を利用している場合は、Gen 2 へ移行ツールが、今後利用できる予定となっています。それまでは、引き続き現在の Gen 1 をご利用ください。 詳細はこちらのブログ を参照ください。Gen2 と Gen1 の機能比較は、 こちらの Document を参照ください。 Amazon RDS for Oracle now supports April 2024 Release Update Amazon RDS for Oracle で、19c、21c を対象にした 2024 年 4 月のリリースアップデート (RU) を提供しました。パッチ適用やバグ修正などが盛り込まれております。リリースアップデートの詳細は、 RDS for Oracle のリリースノート をご覧ください。自動マイナーバージョンアップグレード (AmVU) オプションが有効になっている場合、お客様の DB インスタンスは、6〜8週間で最新の四半期 RU にアップグレードされます。これらのアップグレードはメンテナンスウィンドウ中に行われます。 5/7(火) Announcing Amazon Bedrock Studio preview Amazon Bedrock Studio のプレビューを開始しました。Bedrock Studio は Knowledge Bases、Agents、Guardrails なども活用しながら、Generative AI のプロトタイプを開発するウェブベースの開発環境です。生成 AI アプリケーションの開発スピードを加速できるメリットがあります。Knowledge Bases や Agents を活用して、会社内のデータや外部の API と連携しながら生成 AI を利用する環境をすぐに構築し、使い勝手を確かめながら導入効果の測定などにご活用いただけます。また、会社の ID 認証基盤 (例 : Microsoft Entra ID, Google Workspace など) を使って Bedrock Studio へアクセスを提供でき、AWS マネジメントコンソールへ権限付与なしにご利用いただけるため、組織内の展開がやりやすくなる仕組みがあります。詳細は こちらのブログ を参照ください。 Agents for Amazon Bedrock now supports Provisioned Throughput pricing model Agents for Amazon Bedrock で Provisioned Throughput のサポートを開始しました。Provisioned Throughput は、トークンを処理するリソースを事前に準備することで、一定の保証されたスループットを提供するものです。通常のオンデマンド利用の際には、決められた上限が設定されており、使い方によってはスロットリングエラーが発生する場合があります。今回発表した Provisioned Throughput を使うことで事前に必要なリソースが確保でき、エラーの発生を抑えることが可能になります。 料金の詳細はこちら を参照ください。 Amazon Titan Text Premier is now available in Amazon Bedrock Amazon Bedrock で、新たに Amazon Titan Text Premier モデルを提供開始しました。Amazon Titan Text Premier は、高度で高性能、かつコストパフォーマンスに優れた LLM で、エンタープライズグレードのテキスト生成アプリケーションに最適な性能を発揮するよう設計されています。個人的に注目しているのが、高性能なモデルに加えて Token あたりのコストが安価な点です。1,000 input token あたり$0.0005、1,000 output token あたり $0.0015 となっており、比較的安価な料金帯となっています。現在のところ、日本語は明確なサポートとしては含まれておりませんが、「日本語で回答して」といったリクエストを行うと、日本語の回答が得られることもありました。バージニア北部リージョンでご利用いただけます。ベンチマーク結果や利用方法を含めた詳細は こちらのブログ を参照ください。 Announcing a larger instance bundle for Amazon Lightsail Amazon Lightsail で、16 vCPU と 64 GB メモリの大きなインスタンスバンドルが新たに提供されるようになりました。高性能インスタンスバンドルは、大きな負荷の増加に対処できる能力が必要な一般的なワークロードに最適です。この新しいバンドルを使えば、ウェブおよびアプリケーションサーバー、大規模データベース、仮想デスクトップ、バッチ処理、エンタープライズアプリケーションなどを実行できます。Linux オペレーティングシステム (OS) で利用可能です。Windows ベースのものは提供していません。 5/8(水) Amazon SageMaker now integrates with Amazon DataZone to help unify governance across data and ML assets Amazon SageMaker と Amazon DataZone の統合が提供されるようになりました。DataZone は、組織内に存在するデータの意味を解説する管理機能、検索を行い欲しいデータを探索するデータカタログ機能、セキュリティを意識したデータ共有機能などがあります。アップデートで、SageMaker Studio の画面から DataZone 上で管理されているデータを検索し利用する機能が追加されました。機械学習エンジニアがデータを使ってモデルを作成していく際に、どんなデータが組織内に存在しているか簡単に把握できるようになり、試行錯誤に伴うデータ探索の時間を削減できるようになりました。また、機会学習エンジニアが作成したモデルや特徴量データをカタログに公開することもできるようになり、作成した成果物を組織内に共有し、互いのコラボレーションがやりやすくなる機能があります。詳細は こちらのブログ をご参照ください。 New Generative Engine with three synthetic English Polly voices テキストデータから音声を合成する際に利用できる Amazon Polly で、表現力豊な 3 つの Generative エンジンを追加しました。今回のアップデートで、アメリカ英語音声としてルースとマシュー、イギリス英語音声としてエイミーが追加されました。AWS マネジメントコンソールで簡単に試してみると、英語のアクセントなどがとてもネイティブ感があり、クリアなサウンドに聞こえました (聞き分けられるほどの英語スキルはないですが…)。新しい 3 音声は、バージニア北部リージョンでご利用いただけます。 5/9(木) Amazon Cognito introduces tiered pricing for machine-to-machine (M2M) usage Amazon Cognito で、マシン間認証 (Machine-to-Machine) の価格設定を導入しました。従来あるユーザーベースの価格設定は、変更ありません。マシン間認証とは、ユーザー (人間) による操作ではなく、システム間やアプリケーション間の認証連携の際に適用されるものです。具体的には、Amazon Cognito でアプリクライアントのクレデンシャルを発行し、それを連携したいシステム側で利用することで、新しい料金体系が適用されます。新しい料金体系は、アプリクライアントごとの毎月課金と、アクセストークンの発行数による従量課金となります。詳細は こちらの「Machine-to-machine authorization」タブ をご確認ください。 Amazon QuickSight launches SPICE capacity auto-purchase API Amazon QuickSight で SPICE 容量の自動購入 API を新たに追加しました。以前は、QuickSight のウェブコンソール画面から、SPICE 自動購入を手動で ON にする作業が必要でした。この API 追加によって、AWS SDK や AWS CLI などを使ってプログラム側から自動的に自動購入を ON に指定できるようになり、シームレスな環境作成が実現できます。 5/10(金) Amazon RDS for PostgreSQL supports pgvector 0.7.0 Amazon RDS for PostgreSQL で、データベースにベクトルデータを保存する用途などに利用できる pgvector 0.7.0 をサポートしました。pgvector 0.7.0 では、新たにベクトルデータを保存するためのデータ型として、halfvec が追加されました。これは、いままで 32 ビットでベクトルデータを保存していたことに対して、半分の 16 ビットで保存できるようになり、データキャッシュなどを行う際のメモリ使用量を半分でき、コストパフォーマンスを改善できるうれしさがあります。また、halfvec は新たにベクトルデータを格納する際の index build time を早くできる特性をもっており、より高速な利用を期待できます。生成 AI の Embedding や、自然言語処理、画像認識などの分野で役立つアップデートとなります。利用できるバージョンの制限があり、PostgreSQL 16.3、15.7、14.12、13.15、12.19 のバージョンで実行可能です。 2024 年度の AWS Summit Japan が 6 月 20 日(木)、21 日(金)に開催されます。 事前登録サイト が公開されたため、ぜひ忘れないうちに登録とカレンダーの予約をお願いします。基調講演、150 を越えるセッション、250 を越える EXPO コンテンツが体験できます。また、QuizKnock が AWS Summit 内で、クイズ大会やミニステージに登壇していただける予定になっております。こちらもぜひお立ち寄りください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

製造業、特に化学、素材や製薬の事業では自社製品の新しい用途の発見が新規市場の開拓に欠かせません 。 富士フイルム がフィルムで培った抗酸化機能を化粧品に転用した事例 、 森下仁丹がバイオカプセルの技術をレアメタルの回収に転用した事例 は自社製品の可能性を広げた好例といえます。しかし、可能性を感じる一方で新しい用途の発見に困難を感じているお客様が多いと思います。テクノポートのアンケートに基づくと、 用途開発を行っている企業の 84.5% が自社だけで有望な用途を発見するのは限界 と回答しています。多様な新製品の登場や脱炭素の市場動向など、製品と求められる性能は多様であり、膨大な情報から自社製品の適合可能性を発見し育てるのは容易ではありません。先ほど挙げた富士フイルムでも、化粧品への応用可能性を発見してから成功を収めるまで長い期間を要しています。 近年の生成 AI は新規用途の発見にどのように役立つでしょうか ? 生成 AI は高い文章処理能力を持つため、膨大な情報から有望な用途を検出するのに利用できると期待できます。実際、 三井化学では生成 AI を用途の探索に活用していますし 、 日本ガイシでは基盤モデルを活用した新規用途探索の高精度化と高速化の実証実験を開始しています 。三井化学では事業部門の 1 テーマにつき 500 万件以上の特許やニュース、ソーシャルメディアといった外部情報と、三井化学固有の辞書を入力に使用しています。日本ガイシでは、 Stockmark が開発した最新の特許や論文、ニュースなどの外部情報を学習したモデル と日本ガイシが保有する特許や論文などの社内外文書を使用しています。これらの事例から、生成 AI の活用においては外部の情報と内部の情報の 2 つが必要なことがわかります。富士フイルムであれば抗酸化作用、森下仁丹であれば被膜技術に関する社内の文書や特許、論文が「内部の情報」にあたるでしょう。これを外部の特許やニュース、ソーシャルメディアなどと突合させることで有用な新規用途を見つける流れになります。 生成 AI で「外部の情報」と「内部の情報」を突合し、新規用途を発見するにはどんな手法があるでしょう? 三井化学のように、外部と内部それぞれの情報をもとに生成 AI を含む機械学習モデルに判断させるか、日本ガイシのように「すでに専門知識を学習した」モデルに情報を与え判断させる 2 つのアプローチが考えられます。少し専門的な用語になりますが、前者の代表的な手法はモデルに対する外部知識の挿入 (Retrieval Augmented Generation: RAG) 、後者の代表的な手法はモデルの追加学習 (Fine Tuning / Continuous Pretraining) と呼ばれます。前者と後者は、移動するときに配車サービスを使用するか車を買うかに似ています。配車サービスでは車を持つ必要がないように、前者は特別なモデルを必要としない点がメリットです。一方で、必要な知識や情報すべてを生成 AI へ入力しないといけないため入力長が長くなり対応できるモデルが限られる、また料金が高額になるデメリットがあります。移動距離が長くなるほど高額かつ高級な車にしなければらならないイメージです。車を買ってしまえば自由にどこへでも行けるように、後者は初期費用が必要なもののモデルを構築してしまえば入力は短く済み自由にカスタマイズできます。それぞれにメリットとデメリットがありますが、今回は後者の手法を紹介します。というのも、 1 日にチェックするべき情報一つ一つに対し各製品の各特性の応用可能性を分析するなら、必要なリクエスト数は情報・製品・特性の掛け算になり膨れ上がります。この場合、単純にコストがかかるだけでなくモデルの利用制限に抵触する可能性があります。例えば、 Amazon Bedrock で Claude (Sonnet) を利用する場合、 1 分間当たりリクエスト可能な数は 500 という制限があります 。そのため、一時的にコストがかかっても内部の情報に精通したモデルを構築し、外部の情報を判断してもらうことはメリットがあると考えています。「内部の情報」は「外部の情報」に比べて変化が緩やかで特化型のモデルを作っても時代遅れになりにくい点もポイントです。 AWS で「内部の情報」を学習した生成 AI モデルを使い「外部の情報」から用途を見つけるにはどうしたらよいでしょうか? エンジニアの方向けに、アーキテクチャーの構成例を示します。 自社のオンプレミス環境から用途検索を行うアプリケーション (Amazon ECS) へのアクセスを行う想定です。「内部の情報」を学習したモデルは、 Hugging Face 上で公開されている Stockmark が開発したビジネスに関連するオープンな情報や特許などで学習した基盤モデル を AWS DataSync で取得した社内文書で追加学習して構築しています。 Stockmark のモデルはまだ未対応ですが、 Amazon SageMaker JumpStart に掲載済みのモデルであれば Amazon S3 にデータを配置し画面からボタンを押す、 API を呼ぶだけで学習を起動できます 。 このような構成を取ることで、セキュアかつ高効率に用途の探索ができます。学習したモデルは、 SageMaker real-time endpoint でホスティングしています。 2024 年 5 月の段階で Amazon Bedrock の Custom model import 機能 が Preview となり、本機能を利用すれば他のモデルと同様に API 形式でモデル呼び出すことも可能です。 「外部の情報」の検索には Amazon Kendra を利用しています。 Amazon Kendra はマネージドな検索サービスで、内部の情報同様 AWS DataSync で取得した外部の情報の検索に使用しています。検索結果をホスティングした追加学習済みのモデルに送り、分析結果をアプリケーションに返却します。 先にご紹介した日本ガイシの実証実験では Stockmark と本構成に近い取り組みをしており、 Stockmark 独自モデルを追加学習し日本ガイシ固有のモデルを検証することがアナウンスされています 。海外では Bloomberg が金融文書で学習させたモデルを発表している通り、 自社のドメイン、さらには自社固有の製品情報を学習させることで 自社ビジネスのパートナーとなるようなモデルを構築する試みが様々な会社で進んでいます 。基盤モデルの開発に取り組むリコーでは、 企業独自の AI モデルを簡単に作成できるサービスの提供も始めています 。自社ビジネスパートナーとなるようなモデルに対しては、商談前や会議中といったリアルタイムな応答が求められる場で使われることもあるでしょう。自社固有のモデルを AWS 環境内でホスティングすることで、応答速度や利用制限といった外部の制約に縛られることなく業務を加速でき、秘中の秘である自社の製品情報を学習したモデルをセキュアに利用することができます。 本記事では、生成 AI により新規用途の発見を加速させる手法をご紹介しました。 外部と内部の情報を生成 AI に入力し分析させる方法と、自社ドメインの知識を学習したモデルを利用する方法の 2 つを紹介し、後者の可能性と AWS で実装するためのアーキテクチャー例をご紹介しました。自社独自のモデルの構築というと非常に高度なスキルと金額、何より時間がかかると思われるかもしれません。しかし、 Stockmark がオープンソースでモデルを公開しているように、高性能かつ日本語に特化したモデルの入手は容易になっており、ゼロから学習する必要はなくなりつつあります。 AWS では Amazon SageMaker JumpStart に掲載済みのオープンソースのモデルであれば容易に追加学習できますし、掲載されていないモデルも基盤モデルの学習・推論に特化した AWS Trainium / AWS Inferentia という自社設計の機械学習アクセラレーターを用いることでコスト効率よく、短期間で学習を完了できます。 2023 年に LLM 開発支援プログラムに参加されたお客様には 3 日で学習を完了された例もあります。 AWS Trainium / AWS Inferentia の詳細は 「 AWS Trainium を活用した日本語大規模言語モデルの分散学習と AWS Inferentia2 上での推論環境構築 」をぜひご参照ください。もちろん、前者のアプローチを試したい場合であっても Amazon Bedrock を通じて Claude など日本語でも ChatGPT / GPT-4 同等の性能を持つモデルを利用しすぐにアプリケーションを実装することができます。 どんなアプローチをしたい場合であっても最適なサービスを提供できる品ぞろえが AWS をご活用いただくメリットです。 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。  

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 皆さんもお気づきだとおもいますが、AWSでは生成AIに注力しています。AWSは「お客様からのフィードバックにもとづいてサービス開発をおこなう」ということを昔から大切にしてきました。最近AWSが生成AIに力を入れているのは、まさにこの理由からです。私自身、常日頃いろいろなお客様と会話をするわけですが、生成AIに興味を持っていない方はほぼいない、といっても過言ではない状況ですから、AWSの注力ぶりは個人的には頷ける印象を持っています。 これから先も、たくさんのニュースやサービスアップデートが出てくるでしょう。ところが、あるお客様から「アップデートが多すぎて把握しきれない」というコメントを頂きました。と、いうことでお客様の声にお答えして新しいブログシリーズ、週刊生成AI with AWSを始めてみようと思います。 週刊AWS のように、毎週月曜日をメドに先週分のニュースやサービスアップデートをコンパクトにまとめてお伝えします。週刊AWSと同じトピックを取り上げることもあると思いますが、大切な情報が漏れるよりは重複したほうが良いという考え方で、カブリはOKというポリシーにしたいと思います。 それでは、5 月 6 日週の生成AI with AWS界隈のニュースをお届けしていきましょう。 さまざまなニュース Amazon Qの一般利用開始に際して、Andy JassyがXにコメントをポスト Andy JassyはAWSを立ち上げた当事者で、現在はAmazon全体のCEOを務めています。Andyはポストの中で、Amazon Qは企業のデータ活用とソフトウェア開発の加速を目的とした生成AI搭載アシスタントで、開発者や従業員の方々が「大変だけれども競争力につながらない作業」に費やす時間を大幅に削減することを目指しているとコメントしています。すでにAmazon Qを利用しているお客様の名前についてもご紹介していますので、ぜひ原文をごらんください。 Adam SelipskyもAmazon Qの一般利用開始についてXにポスト AWSのCEOであるAdam SelipskyもAmazon Qの一般利用開始についてポストしています。Amazon Qは、その名前を持った様々なプロダクトから構成されているのですが、全体感をざっくりと把握するにはAdamのポストを見ていただくのがおすすめです。短い文章で良い具合にまとまっています。 Werner VogelsがブログでAIによる会議の議事録取得アーキテクチャを紹介 WernerはAmazonのCTOです。彼は All Things Distributed というブログを運営しているのですが、そのブログにAIの技術を利用して、会議中の会話をテキストに書き起こし、要約を出力する仕組みを構築する方法を紹介する記事が投稿されました。会議の音声データをAmazon S3にアップロードすると、Amazon Transcribeでテキストへの書き起こしを行い、Amazon Bedrockの経由でClaude 3 Sonnetに要約させ、その結果をS3に書き戻すという具合です。ブログの後半ではAmazon Qを試してみた感想も掲載されていますので、ぜひご一読を。 サービスアップデート 新モデルAmazon Titan Text PremierがAmazon Bedrockから利用可能に Amazonが開発・提要する基盤モデルであるAmazon Titanファミリーに新たな仲間が加わりました。大規模言語モデル(LLM)のAmazon Titan Text Premierです。Titan Text Premierは要約、テキスト生成、分類、Q&A、情報抽出などテキストに関する多彩なタスクをサポートし、Knowledge Bases for Amazon Bedrockによる検索拡張生成(RAG)アーキテクチャでの利用や、Agents for Amazon Bedrockによる複数ステップを順序立てて実行する処理に最適化されています。Bedrockのフルマネージドな仕組みで動きますので、お客様はBedrockのAPIを呼び出す方法だけ学習すれば、デプロイや管理運用の手間なくTitan Text Premierをご利用いただけます。 ブログ記事 も公開されています。デモ動画や性能評価の結果も掲載されています。 生成AIアプリケーション開発のためのWebインタフェース、Amazon Bedrock Studioをプレビュー提供開始 複数の開発者の方が協力しながら生成AIアプリケーションを開発するためのWebインタフェース、Amazon Bedrock Studioのプレビュー提供を開始しました。シングルサインオン(SSO)に対応していますので、組織内のIDを利用してログインすることができます。Bedrock Studioは、Knowledge BasesやAgents、Guardrailsなどを利用したプロトタイプを素早く開発できる環境を提供します。Bedrock Studio自体は無料でご利用頂くことができ、Bedrockをご利用いただいた料金だけが発生します。詳細については ブログ をぜひ。画面ショットが沢山あるので、イメージを掴みやすくなっています。 Agents for Amazon Bedrockがプロビジョンドスループット料金モデルに対応 Amazon Bedrockにはオンデマンドと、プロビジョンドスループットの料金モデルが用意されています。オンデマンドは入出力トークン数に基づく従量課金、プロビジョンドスループットは単位時間あたりに処理できる入出力トークン数のスループットを確保し固定金額を支払うモデルと考えてください（ 料金体系はこちら ）。今回、新たにAgents for Amazon Bedrockでもプロビジョンドスループットの料金モデルをご利用いただけるようになりました。 Amazon SageMaker NotebooksがG6インスタンスをサポート Amazon SageMaker Studioは機械学習開発の作業をエンドツーエンドでサポートする、Webベースの統合開発環境です。SageMaker NotebooksはSageMaker Studioの一部として提供されるフルマネージドなJupyterLab環境で、開発やデータ操作などのNotebookを利用した作業を素早く実行可能です。今回、SageMaker NotebooksのインスタンスとしてAmazon EC2 G6インスタンスが利用できるようになりました。G6は最大8つのNVIDIA L4 Tensor Core GPU(24GBメモリ)と、第3世代のAMD EPYCプロセッサを搭載しており、G4dnインスタンスと比較してディープラーニング用途で最大2倍の性能を発揮します。 Amazon SageMakerとAmzon DataZoneが統合され、データとML資産の統合管理が容易に Amazon DataZoneは組織内のデータを素早くカタログ化・発見・共有・管理するためのデータ管理サービスです。Amazon SageMakerと統合が行われたことによって、機械学習プロジェクトの管理者は、DataZoneを利用してプロジェクト関係者間の成果・データの共有や、アクセス許可の管理を実行できるようになりました。また、機械学習エンジニアやデータサイエンティストの方にとっては、利用可能なデータを発見して、機械学習で利用することがこれまでよりも簡単に実行できるようになるメリットがあります。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

AWS Amplify は、Gen 2 における Function の一般提供を発表できることを喜ばしく思います。Amplify Functions は TypeScript を使って定義、作成、使用されます。これらは、カスタムクエリやミューテーションのハンドラーであっても、認証リソースのトリガーであっても構いません。Amplify Functions の実態は、 AWS Lambda によって提供されていますが、Amplify を使えばアプリと同じコードベースや言語でサーバーレス関数をデプロイできます。関数はさまざまなユースケースで使用されますが、多くの場合、リソースの動作を拡張または変更してアプリ向けのカスタマイズされたユーザーエクスペリエンスを構築します。 Amplify Gen 2 では、リソースは resource ファイル (つまり resource.ts ) で定義されていますが、Function も対応する handler ファイル (つまり handler.ts ) で作成されます。Function を使用すると、ファイルを保存するたびにソースコードをホットスワップすることで、素早く反復処理を行えます。TypeScript ベースのリソース定義、TypeScript ベースの handler から始めると、リソースまたは handler ファイルを保存するたびに、 esbuild を使ってソースコードがバンドルされ、数秒で再デプロイされます。 Amplify Functions では、各 Function 用に tsconfig.json やビルドプロセスを書く必要はありません。 必要最小限のリソース定義とハンドラーを作成し、デプロイするだけです。 Functions 最大の利点は、ほとんどあらゆるリソースで使えることです! Amplify Functions で最も頻繁に使われるユースケースの一例は次のとおりです。 Amplify でネイティブサポートされていないリソース (例えば AI/ML 向けの Amazon Bedrock) に接続する ユーザー情報をユーザープロファイルデータレコードにリンクするなど、Amplify の既定の認証フローを変更する ストレージバケットにアイテムがアップロードされた際にイベントを実行する (例えば画像のリサイズ) データリソースに対するカスタムクエリやミューテーションのためのリゾルバーを作成する ここでは、Amplify アプリ内の カスタム AWS リソースとして Amazon Bedrock と対話する関数を構築し、カーソルルームに保存された画像に基づいて俳句を生成します。 この関数は、カスタムクエリのハンドラーとしてデータリソースにアタッチされます。 TypeScript を用いた関数リソースの定義 Amplify Functions を使い始めるには、リソース定義が必要です。 // amplify/functions/generateHaiku/resource.ts import { defineFunction } from "@aws-amplify/backend" export const generateHakiu = defineFunction({ name: "generateHaiku", }) そして対応する ハンドラー ( handler.ts ) ファイルは次のようになります: // amplify/functions/generateHaiku/handler.ts export const handler = async () => {} 個人用のクラウドサンドボックス が動作していれば、ハンドラーファイルを保存するとすぐに、最初の関数のデプロイが開始され、数秒以内にデプロイが完了します。 Amplify リソースとの関数の利用 関数がストレージリソースから画像を 読み取る ためには、アクセス権を付与する必要があります。Amplify リソースへのアクセス権は共通の言語で付与され、Amplify は IAM の用語をストレージの read や Auth の addUserToGroup のようなリソースに適した言葉に単純化します。関数のリソース定義を使って、ストレージリソースの room/ パスへのアクセス権を許可しましょう。 import { defineStorage } from "@aws-amplify/backend"; import { generateHaiku } from "../functions/generateHaiku/resource"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: allow => ({ 'room/*': [ allow.authenticated.to(['get', 'write', 'delete']), allow.guest.to(['get', 'write', 'delete']), // grant the "generateHaiku" function "read" access allow.resource(generateHaiku).to(['read']) ] }) }); カスタムクエリのリゾルバーとしても Function を利用できます。前に作成したリソース定義を使って、カスタムクエリを作成します。 // amplify/data/resource.ts import { type ClientSchema, a, defineData } from '@aws-amplify/backend'; import { generateHaiku } from '../functions/generateHaiku/resource'; const schema = a.schema({ // ... generateHaiku: a.mutation() // specify a "roomId" argument .arguments({ roomId: a.string() }) // we'll return the Haiku as a string .returns(a.ref('Haiku')) // authorize using an API key .authorization(allow => [allow.authenticated()]) // specify the "generateHaiku" function we just created .handler(a.handler.function(generateHaiku)) }).authorization((allow) => [allow.authenticated()]); // ... これにより、生成された Data クライアントを使用して、Function を型安全な方法で呼び出すこともできます。クエリが client.queries.generateHaiku() で呼び出されると、Function が実行され、Storage リソースから読み取れるようになります。 任意の AWS サービスでの関数の利用 Amplify は AWS Cloud Development Kit (CDK) の上に構築されているため、Amplify が一級のサポートを提供していない AWS サービスとやり取りする必要がある場合は、CDK を使用して Amplify が生成したリソースを拡張または変更できます。 たとえば、Amplify リソースからデータを使用して別の AWS サービス、Amazon Bedrock と通信するための関数を構築します。 // amplify/backend.ts import { Stack } from "aws-cdk-lib/core" import { Effect, PolicyStatement } from "aws-cdk-lib/aws-iam" import { defineBackend } from "@aws-amplify/backend" import { auth } from "./auth/resource" import { data } from "./data/resource" import { storage } from "./storage/resource" import { AMAZON_BEDROCK_MODEL_ID, generateHaiku } from "./functions/generateHaiku/resource" /** * @see https://docs.amplify.aws/react/build-a-backend/ to add storage, functions, and more */ const backend = defineBackend({ auth, data, storage, generateHaiku, }) // ... // access the "generateHaiku" function from your defined backend const generateHaikuFunction = backend.generateHaiku.resources.lambda // use built-in CDK construct methods to extend the Function's role generateHaikuFunction.addToRolePolicy( new PolicyStatement({ effect: Effect.ALLOW, actions: ["bedrock:InvokeModel"], resources: [ `arn:aws:bedrock:${ Stack.of(generateHaikuFunction).region }::foundation-model/${AMAZON_BEDROCK_MODEL_ID}`, ], }) ) TypeScript サポートの拡張 Amplify Functions の定義方法と他のリソースへの接続方法を見てきたところで、次は Amplify が TypeScript を使った Functions の作成体験をどのように向上させているかを見ていきましょう。 環境変数への型指定 Amplify は環境変数について、型の絞り込まれた参照を生成します。環境変数が明示的に宣言されている場合は、関数で生成される env 参照で利用可能になります。例えば、使用する Amazon Bedrock モデル (モデルの詳細は AWS の Amazon Bedrock ドキュメント を参照) を指定する場合は以下のようになります。 // amplify/functions/generateHaiku/resource.ts import { defineFunction } from "@aws-amplify/backend"; export const AMAZON_BEDROCK_MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0"; export const generateHaiku = defineFunction({ name: "generateHaiku", environment: { AMAZON_BEDROCK_MODEL_ID, }, }); この環境変数は、 environment のキーを使って env で利用できるようになります。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.AMAZON_BEDROCK_MODEL_ID) または、ストレージなどの他のリソースへのアクセスを指定した場合は、Amplify がそのリソースのメタデータ (Amazon S3 バケット名など) への参照を作成します。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.GEN_2_MULTI_CURSOR_DEMO_APP_BUCKET_NAME) 型付きハンドラ関数 関数をカスタムクエリやミューテーションのリゾルバーとして割り当てる場合、Amplify は Function のハンドラー用の型を特別に提供します。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" import { type Schema } from "../../data/resource" // use the prebuilt handler type from your Schema type Handler = Schema["generateHaiku"]["functionHandler"] export const handler: Handler = async (event) => { // arguments are typed based on the query definition const { roomId } = event.arguments // to satisfy the handler's "returnType" requirement, return the Haiku return { content: "", roomId, } } 事前設定済みの TypeScript ビルド create-amplify で Amplify アプリを作成すると、Amplify は最新の設定を含む TypeScript プロジェクト設定ファイルをスキャフォールディングし、 esbuild を使用して Functions をバンドルします。 ファンクションのエントリポイントごとに個別の設定を心配する必要はありません。また、ビルドスクリプトも不要です。 esbuild と最新の TypeScript プロジェクト設定を使用することで、Amplify は他のモジュールからの TypeScript ファイルのインポートを可能にします。 モノレポの環境では、これによりビジネスロジックをモジューラー化し、パッケージの TypeScript を JavaScript にコンパイルする必要がなくなるため、Functions 間で再利用できます。 関数内のシークレット Amplify Funcsions は、Lambda 関数と他のAWSサービスに依存した環境変数を定義する際の複雑性と、AWS SDKが実行時にシークレット値を解決するためのお決まりの記述を不要にします。 シークレットは、個人の Cloud 環境インスタンスで使用する場合は CLI で作成されるか、 ブランチデプロイの場合は Amplify コンソールで作成されます 。 Amplify Sandbox では、CLI を使用してシークレットが設定されます。 npx ampx sandbox secret set MY_SECRET Secrets は次に、 secret() を使って関数の environment にバインドできます。 // amplify/functions/generateHaiku/resource.ts import { defineFunction, secret } from "@aws-amplify/backend" export const generateHakiu = defineFunction({ name: "generateHaiku", environment: { MY_SECRET: secret("MY_SECRET") }, }) そして環境変数と同様に利用できます。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.MY_SECRET) Get Started Today! これまでに以下のことを説明しました。 Amplify Functions の定義方法 カスタムクエリやミューテーションのリゾルバとして Amplify Functions を使う方法 Amplify Functions に他の Amplify リソースへのアクセスを許可する方法 Amplify Functions に任意の AWS サービスへのアクセスを許可する方法 Amplify Functions での環境変数とシークレットの使用方法 Amplify Functions のハンドラの型付けや、その他の TypeScript の機能の使い方 これらの機能が実際の設定でどのように組み合わされているかを確認するには、 day-3 ブランチのサンプルアプリ を参照してください。 今すぐ Amplify Functions を使い始めるには、 npm create amplify@latest を実行し、 Amplify Functions のドキュメント を参照して詳細を確認してください! 本記事は、 Amplify Functions: Create serverless functions using TypeScript, powered by AWS Lambda を翻訳したものです。翻訳は Solutions Architect の 吉村 が担当しました。

本記事は、 Amazon Personalize launches new recipes supporting larger item catalogs with lower latency を翻訳したものです。翻訳は Solutions Architect の小川翔が担当しました。 パーソナライズされた顧客体験は、今日のユーザーを惹きつけるために不可欠です。しかし、ユーザーの行動の変化に適応する本当にパーソナライズされた体験を提供することは、チャレンジングかつ時間のかかるものです。 Amazon Personalize を使えば、機械学習の専門知識がなくても簡単に Amazon が使用しているものと同じ機械学習テクノロジーを使って、ウェブサイト、アプリ、メールなどをパーソナライズできます。Amazon Personalize が提供する レシピ (特定のユースケース用のアルゴリズム) を使えば、商品やコンテンツのおすすめ、パーソナライズされた並べ替えなど様々なパーソナライズを実現できます。 2024/5/2、Amazon Personalize の2つの高度なレシピ、 User-Personalization-v2 と Personalized-Ranking-v2 の一般提供を発表できることを嬉しく思います。これらのレシピは 最新の Transformer アーキテクチャ に基づいており、より大規模な商品カタログに対応しながら低レイテンシーを実現しています。 この投稿では、新機能の概要を説明し、モデルの学習プロセスとユーザーへの推薦方法をご案内します。 新レシピのメリット 新しいレシピでは、スケーラビリティ、レイテンシー、モデルのパフォーマンス、機能性が強化されています。 高いスケーラビリティ – 新しいレシピでは最大 5 百万アイテムのカタログと 30 億件のユーザーとアイテムのインタラクションデータを用いた学習が可能になり、大規模カタログや何十億もの利用イベントがあるプラットフォームでの適用が可能になりました。 レイテンシーの短縮 – 大規模データセットの場合でも、推論時間と学習時間が短縮されたことで、エンドユーザーの待ち時間を削減できます。 パフォーマンスの最適化 – Amazon Personalize でのテストでは、v2 レシピがレコメンデーションの精度を最大 9 % 高め、レコメンデーションのカバレッジを最大 1.8 倍にする結果が出ています。カバレッジが高いということは、Amazon Personalize がカタログの多くのアイテムを推薦できるということです。 推論レスポンスにアイテムメタデータを返す – 新しいレシピではアイテムメタデータがデフォルトで追加料金なしで有効化されているので、ジャンル、説明、入手可能性など、メタデータを推論レスポンスに含めることができます。これにより追加作業なしにユーザーインターフェースでレコメンデーションを充実させることができます。Amazon Personalize を生成 AI と組み合わせる場合は、メタデータをプロンプトに取り入れることもできます。大規模言語モデルに豊富な文脈を提供することで、商品属性を深く理解しより関連性の高いコンテンツを生成することができるようになります。 高度な自動化されたオペレーション  – 新しいレシピはモデルの学習とチューニングのオーバーヘッドを削減するように設計されています。例えば、Amazon Personalize はトレーニング設定の単純化と、カスタムモデルの最適な設定を内部的に自動選択します。 ソリューションの概要 User-Personalization-v2 および Personalized-Ranking-v2 レシピを使用するには、まず Amazon Personalize のリソースをセットアップする必要があります。データセットグループを作成し、データをインポートして、ソリューションバージョンを作成し、キャンペーンをデプロイしてください。詳細な手順については、 Getting Started をご覧ください。 この投稿では、キャンペーンをデプロイするために Amazon Personalize コンソールを使った方法に沿ってご案内します。代わりに SDK を使ってソリューション全体を構築することもできます。また、非同期のバッチフローを使って一括で推薦を取得することもできます。ここでは、 MovieLens 公開データセット と User-Personalization-v2 レシピを使って、ワークフローを説明します。 データセットの準備 次の手順でデータセットを準備してください: データセットグループを作成 します。各データセットグループには、最大 3 つのデータセット (ユーザー、アイテム、インタラクション) を含めることができ、 User-Personalization-v2 および Personalized-Ranking-v2 ではインタラクションデータセットは必須です。 スキーマ を使用して、インタラクションデータセットを作成します。 Amazon Simple Storage Service (Amazon S3) から、 インタラクションデータを Amazon Personalize にインポート します。 モデルの学習 データセットのインポートジョブが完了したら、トレーニングの前にデータを分析できます。Amazon Personalize の Data analysis 機能では、データに関する統計情報と、トレーニングの要件を満たしてレコメンデーションを改善するためのアクションを確認できます。 これで、モデルを学習する準備が整いました。次にモデルを学習する手順を示します。 Amazon Personalize コンソールで、ナビゲーションメニューから Dataset groups を選択します。 作成したデータセットグループを選択します。 Create solutions を選びます。 Solution name には、ソリューション名を入力します。 Solution type では、 Item recommendation を選びます。 Recipe では、新しい aws-user-personalization-v2 のレシピを選びます。 Training configuration セクションで、 Automatic training では Turn on を選択します。これにより、定期的なトレーニングでモデルの有効性を維持することができます。 Hyperparameter configuration で、 Apply recency bias （最新データへの重み付け） を選択します。これにより、モデルがインタラクションデータセットの最新のアイテムインタラクションデータにより重みを置くようになります。  Create solution を選びます。 Automatic training を有効にした場合、Amazon Personalize は最初のソリューションバージョンを自動的に作成します。ソリューションバージョンとは、トレーニングされた ML モデルのことを指します。ソリューションバージョンが作成されると、Amazon Personalize はレシピとトレーニング設定に基づいて、ソリューションバージョンに紐づくモデルをトレーニングします。ソリューションバージョンの作成を開始するまでに最大で 1 時間かかります。 ナビゲーションペインの Custom resources で、 Campaigns を選択してください。 Create campaign を選択してください。 キャンペーンは、学習済みモデル (ソリューションバージョン) をデプロイして、リアルタイムの推薦を生成します。v2 レシピで学習したソリューションで作成されたキャンペーンでは、推薦結果にアイテムのメタデータを含めるオプトインが自動的にオンになります。推論リクエストの際にメタデータ列を選択できます。 キャンペーンの詳細を入力してキャンペーンを作成します。 推薦情報を取得する キャンペーンの作成または更新後、ユーザーが最も関心を示すと思われる順に、アイテムの推薦リストを取得できます。 キャンペーンを選択し、 View details を選びます。 Test campaign results セクションで、ユーザー ID を入力し、 Get recommendations を選択します。 次の表は、ユーザーに対する推薦結果です。推薦された商品、関連スコア、商品メタデータ (タイトルとジャンル) が含まれています。 これで、User-Personalization-v2 をウェブサイトやアプリに組み込んで、顧客一人ひとりに合わせた体験を提供できる準備ができました。 クリーンアップ この投稿に従って作成した、アカウント内の不要なリソースは必ず削除してください。キャンペーン、データセット、データセットグループは、Amazon Personalize コンソールまたは Python SDK を使用して削除できます。 まとめ Amazon Personalize の新しい2つのレシピ（ User-Personalization-v2 と Personalized-Ranking-v2 ）はレシピは、大規模なアイテムカタログに対応し、レイテンシの削減、パフォーマンスの最適化により、パーソナライズを次のレベルに引き上げます。Amazon Personalize の詳細は、 Amazon Personalize 開発者ガイド を参照してください。 著者について Jingwen Hu は AWS AI/ML の Amazon Personalize チームでシニアテクニカルプロダクトマネージャーとして働いています。余暇には旅行と現地の食べ物を探索するのを楽しんでいます。 Daniel Foley は Amazon Personalize のシニアプロダクトマネージャーです。人工知能を活用してお客様の最大の課題を解決するアプリケーションの構築に取り組んでいます。仕事の合間には、熱心なスキーヤーとハイカーでもあります。 Pranesh Anubhav は、Amazon Personalize のシニアソフトウェアエンジニアです。顧客に対するスケーラブルな機械学習システムの設計に情熱を持っています。仕事以外では、サッカーをするのが大好きで、レアル・マドリードの熱心な追随者です。 Tianmin Liu は、Amazon Personalize のシニアソフトウェアエンジニアです。様々な機械学習アルゴリズムを用いて、大規模な推薦システムの開発に従事しています。余暇時間は、ビデオゲームをプレイしたり、スポーツを観戦したり、ピアノを弾くことが好きです。 Abhishek Mangal は、Amazon Personalize のソフトウェアエンジニアです。様々な機械学習アルゴリズムを使って大規模な推薦システムの開発に携わっています。余暇にはアニメを視聴することが好きで、ワンピースが最近の物語として最高傑作であると考えています。 Yifei Ma は、AWSAILabs のシニアアプライドサイエンティストであり、レコメンダーシステムに従事しています。彼の研究興味は、能動学習、生成モデル、時系列解析、オンライン意思決定にあります。仕事以外では、航空機愛好家です。 Hao Ding は、AWS AI Labsのシニアアプライドサイエンティストであり、Amazon Personalizeのレコメンデーションシステムの進化に取り組んでいます。彼の研究関心は、レコメンデーション基盤モデル、ベイズ深層学習、大規模言語モデル、およびそれらのレコメンデーションへの応用にあります。 Rishabh Agrawal は、 AWS の AI サービスに携わるシニアソフトウェアエンジニアです。余暇には、ハイキング、旅行、読書を楽しんでいます。

AWS Amplify を使用したファイルストレージの新しい体験をご紹介できることを喜ばしく思います。 この強力なストレージソリューションは、 Amazon Simple Storage Service (Amazon S3) と簡単に統合でき、Amplify のフルスタック TypeScript 開発者体験を通じて、開発者がファイル構造をより詳細に制御し、柔軟に設定できるようになります。経験豊富な開発者でも、これから始める初心者の方でも、Amplify Storage ならクラウドベースのファイル保管を直感的に管理でき、アプリケーションの要件に応じて確実に実装できます。 本日、AWS Amplify Storage におけるフルスタック TypeScript エクスペリエンスを発表します。Amplify Storage を使うことで、以下のことが可能になります。 5 行に満たないコードでストレージバケットを定義 パスベースのアクセス許可を構成 Amplify のゼロコンフィグ UI コンポーネントとクライアントライブラリを使用して、ストレージバックエンドからファイルのアップロードとダウンロード Amplify コンソールの新しくデザインされたファイルブラウザを使用して、ファイルとフォルダを管理 先週、新しい開発者体験である Amplify Gen 2 が一般提供されました。ストレージ以外のこのリリースについて詳しく知りたい方は、 フルスタック TypeScript : AWS Amplify を再び紹介 をお読みください。 Amazon S3 上に構築された、簡素化された新しいストレージインターフェイス Amplify Storage の機能をより深く理解するため、コードサンプルを用いて説明します。このブログ記事で紹介されている Storage 機能の実働サンプルは こちらのソーシャルルームデモアプリ を参照してください。 5 行未満のコードでストレージバケットをデプロイ Amplify Gen2 で注目すべき機能の 1 つが、TypeScript ベースのバックエンド構築体験です。これにより、わずか数行のコードでストレージリソースを構成および管理できます。さらに、サンドボックス環境でストレージ機能を即座にテストできるため、チームの全開発者が独立して反復処理を行えます。 バックエンド構成にストレージを追加するには、新しいフォルダ amplify/storage と、 amplify/storage/ の下に resource.ts ファイルを作成します。 ストレージバックエンドを定義するには、 defineStorage 関数を使用して、ストレージリソースの分かりやすい名前を指定します。この名前はストレージリソースを簡単に識別するエイリアスとして機能しますが、実際に作成される S3 バケットには、アプリケーションの個別かつセキュアなストレージ場所を確保するために、一意の識別子が付加されることに注意が必要です。 下記のコードは、新しく作成された amplify/storage/resource.ts ファイルに記述されます。ここでは、ストレージバックエンドオブジェクトを定義し、ストレージリソースに「gen2-multi-cursor-demo-app」という名前を付けています。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app' }) }); 次に、このストレージオブジェクトを amplify/backend.ts ファイルのバックエンド定義に含めます。 これで backend.ts ファイルは次のようになるはずです。 import { defineBackend } from '@ aws-amplify/backend'; import { auth } from './auth/resource'; import { data } from './data/resource'; import { storage } from './storage/resource'; const backend = defineBackend({ auth, data, storage }); ストレージリソースを定義すると、サンドボックス環境はその変更をすぐに認識し、ローカル開発用のストレージリソースのデプロイを開始します。このシームレスな統合により、ローカル開発環境ですぐに強力なクラウドストレージ機能を活用できます。 ストレージバックエンドのパスベースアクセス許可のカスタマイズ Amplify Storage では、ストレージリソースへのアクセス管理を細かく制御できます。ゲストユーザー、認証済みユーザー、所有者、ユーザーグループ、さらには関数まで、さまざまなユーザーロールに対して個々のファイルパスへの細かなアクセス許可を定義でき、特定の要件に合わせることができます。デモアプリでは、サインイン済みのユーザーが各ルームで画像をアップロードできるようにします。また、サインインしていない「ゲストユーザー」はアップロードされた画像を閲覧できるようにします。この機能を実現するには、ストレージリソースに特定のアクセス制御を定義する必要があります。目的のアクセス権限は次のとおりです。 ゲストユーザーは読み取り専用アクセスを持ち、アップロードされた画像を閲覧できるようにします。 認証済み (サインイン済み)のユーザーは、フルアクセス権を持ち、新しい画像のアップロード、既存の画像の閲覧、必要に応じてすべての画像の削除ができるようにします。 上記の規則に基づいて、アクセス定義は次のようになります。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: allow => ({ 'room/*': [ allow.guest.to(['get']), allow.authenticated.to(['get', 'write', 'delete']) ] }) }); ストレージリソースでは、デフォルト拒否 (deny-by-default) ポリシーを導入していることに注意が必要です。これにより、 amplify/storage/resource.ts ファイルを通して明示的にアクセスが許可されない限り、ユーザーがストレージリソース内のあらゆるファイルパスやディレクトリにアクセスできません。この原則に従うことで、アクセス権限を厳密に管理し、潜在的な脆弱性を最小限に抑えられます。 さらに、ユーザーグループに全アクセス権を付与することもできます。この例では、管理者ユーザーにストレージリソースへの完全なアクセス権を付与したい場合、まず認証バックエンド( amplify/auth/resource.ts ファイル)でユーザーグループを作成する必要があります。このグループリソースを「admin」と命名します。 amplify/auth/resource.ts ファイルは次のようになります。 import { defineAuth } from '@ aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true }, groups: ['admin'] }); このグループへのアクセスは、 amplify/storage/resource.ts ファイル内で個別に指定できるようになりました。 export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: (allow) => ({ 'room/*': [ allow.guest.to(['get']), allow.authenticated.to(['get', 'write', 'delete']), allow.groups(['admin']).to(['read', 'write', 'delete']) ] }) }); ストレージバックエンド定義にアクセス認証機能を組み込むための詳細については、 こちらの包括的なドキュメントを参照してください 。 Amplify の UI とクライアントライブラリによるファイルのアップロードとダウンロード Amplify の UI コンポーネント Storage Image と Storage Manager を使用して、画像表示やファイルアップロードの機能を数分で実装したり、 Amplify ライブラリ でファイル管理機能をさらにカスタマイズして、アプリの要件を満たすことができます。クライアント API の新しい path パラメータを使用すると、カスタム定義されたストレージ構造やアクセス権限を利用できます。 デモアプリを拡張する前に、ターミナルウィンドウで npx ampx sandbox を実行していることを確認してください。このクラウドサンドボックスを使用すると、構成されたストレージバックエンドに対してアプリをテストできます。 ストレージバックエンドを設定したので、次はこの新機能とやり取りするようアプリを更新する時間です。 フルスタック TypeScript : AWS Amplify を再び紹介 で紹介したデモアプリを使います。また、 サンプルリポジトリ (branch: day 1) からクローンすることもできます。 Amplify Storage の uploadData API を使って、画像を設定済みのストレージバックエンドにアップロードします。アップロードした画像の一時 URL (プライベートファイルへのセキュアなアクセスを提供する一時的な URL)を取得するため、 getUrl API も使用し、画像を表示できるようにします。 次のコードサンプルでは、 getUrl と uploadData API の使用例を確認できます。データモデルの更新を含む残りのコードサンプルについては、 PictureManager.tsx を参照してください。 import { getUrl, uploadData } from "aws-amplify/storage"; // ... // getUrl API const imageUrls = ( await Promise.all( pictures.map(async (item) => await getUrl({ path: item.path })) ) ).map((item) => item.url.toString()); // ... // uploadData API const result = await uploadData({ path: `room/${ roomId }/${ file.name } `, data: file, }).result ; 次に、ユーザーがアップロードした画像を消去して、リフレッシュできるようにする方法を実装します。これには、Amplify Storage の remove API を使用します。 await Promise.all(pictures.map((item) => remove({ path: item.path }))); 注意 : このデモアプリケーションの完全な動作サンプルについては、 Amplify Social Room サンプルアプリ (ブランチ: day 2) を参照してください。以下のように、部屋ごとに画像のアップロードとクリアができます。 コミットした変更内容は git push でワーキングブランチにプッシュします。バックエンド側の変更はすべて、Amplify のCI/CD ワークフローの一環として自動的にデプロイされます。ビルドが完了すれば、更新内容をチームで共有できるURL にアクセスできます！ Amplify コンソールでストレージファイルブラウザを再設計 これらの新しいストレージ機能を補完するため、Amplify コンソールにストレージリソースのコンテンツを管理する専用のタブが追加されました。デプロイされたアプリをテストすると、このインターフェースでストレージリソースの更新状況を確認できます。ファイルやフォルダを簡単に追加、移動、削除できるので、オンデマンドでストレージリソースを整理、管理できます。ユーザーフレンドリーなコンソール環境から直接管理できます。 まとめ おめでとうございます！ Amplify Gen 2 の最新のバックエンド構築と保管機能を使って、完全に機能するアプリの実装とデプロイが完了しました！これからも新しい Amplify の機能を次々と公開していく予定ですので、引き続き最新情報に注目してください！ Amplify はオープンソースプロジェクトであり、高いパフォーマンスでスケーラブルなアプリを構築するために、どのように支援できるかコミュニティからのフィードバックを常に歓迎しています。 Discord サーバー での議論に参加したり、各種の GitHub プロジェクト で機能リクエストやバグを報告したりすることで、お客様からのご意見をお聞かせください。Amplify の詳細を知り、構築を始めるには、 ドキュメントガイド をご覧ください。 この記事は、 Amplify Storage: Now with fullstack TypeScript, powered by Amazon S3 を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。

AWS は re:Invent 2023 で Amazon CloudWatch Application Signals を発表しました。これは Java アプリケーションの健全性をモニタリングして理解するための新機能です。本日、Application Signals が Python アプリケーション のサポートを開始したことをお知らせします。 Application Signals を有効化することで、コード変更なしで Python アプリケーションに AWS Distro for OpenTelemetry (ADOT) を導入できるようになります。これにより、Python を使って開発されたライブラリやフレームワークの主要なメトリクスとトレースを収集できます。カスタムコードの作成やダッシュボードの作成なしに、運用上の健全性の優先順位付けやパフォーマンス目標のモニタリングが可能になります。 このブログ記事では、Amazon EKS クラスター上でデプロイされた Python アプリケーションに Application Signals をシームレスに統合する方法について詳しく説明します。具体的には、 Django フレームワークで開発された Python アプリケーションと、 psycopg2 、 boto3 、 requests などの人気のあるライブラリを使用したアプリケーションをモニタリングすることに焦点を当てます。その後、Application Signals コンソールを使用して、アプリケーションの稼働状況を可視化します。 ソリューションの概要 以下に、このソリューションの詳細な技術的な概要を示します。 デモアプリケーションは Spring Cloud と Django フレームワークで構築されており、各サービスは Eureka discovery-service に登録されます。 アプリケーションコードは G itHub リポジトリ にあります。 insurances と billing の 2 つのサービスは Django フレームワークで記述されており、 Django REST フレームワークを通じて API を公開し、requests ライブラリを使用して外部サービスを呼び出しています。 サービスは psycopg2 を使用して Amazon RDS for PostgreSQL とやり取りし、 boto3 ライブラリを使用して AWS DynamoDB に請求情報を格納しています。 図 1: デモアプリケーションで使用される Python のライブラリとフレームワーク 図 2 に示すリソースを Terraform でデプロイします。CloudWatch エージェントと Fluent Bit をデーモンセットとしてデプロイし、 Amazon CloudWatch Observability EKS アドオン を使用します。これらのコンポーネントは、メトリクス、ログ、トレースを管理します。 図 2: ソリューションアーキテクチャ 前提条件 1. 有効な AWS アカウントを準備してください 2. AWS Command Line Interface (AWS CLI) バージョン 2 をインストールしてください 3. AWS CLI の資格情報を設定してください 4. Terraform をインストールしてください 5. Kubectl をインストールしてください 6. Docker をインストールしてください 解決策の手順解説 Application Signals の有効化 アカウントの Application Signals を有効化する手順 に従ってください。 Terraform を使用したアプリケーションのデプロイ 以下のコマンドを実行して、Terraform を使用してアプリケーションをデプロイするために必要な 環境変数を設定 し、バックエンドとして Amazon S3 バケットを設定 します。 export AWS_REGION = aws s3 mb s3://tfstate-$(uuidgen | tr A-Z a-z) export TFSTATE_KEY = application-signals/demo-applications export TFSTATE_BUCKET =$(aws s3 ls --output text | awk '{ print $ 3 }' | grep tfstate-) export TFSTATE_REGION =$ AWS_REGION export TF_VAR_cluster_name = app-signals-demo export TF_VAR_cloudwatch_observability_addon_version = v1.5.1-eksbuild.1 次に、 アプリケーションリポジトリをクローン し、 Terraform を使用してインフラストラクチャをデプロイ します。リソースのプロビジョニングに成功するまで 15 ～ 20 分かかります。 git clone https://github.com/aws-observability/application-signals-demo cd application-signals-demo/terraform/eks terraform init -backend-config ="bucket =${ TFSTATE_BUCKET }" -backend-config ="key =${ TFSTATE_KEY }" -backend-config ="region =${ TFSTATE_REGION }" terraform apply --auto-approve kubectl の設定 次のコマンドを実行して、 kubeconfig ファイルを更新し、 Amazon EKS Cluster エンドポイントをローカルに追加 してください。 aws eks update-kubeconfig --name $ TF_VAR_cluster_name --region $ AWS_REGION --alias $ TF_VAR_cluster_name Kubernetes リソースのアノテーションを使ったデプロイ Python アプリケーションで Application Signals を有効にするには、クラスターのマニフェスト YAML に instrumentation.opentelemetry.io/inject-python: 'true' というアノテーションを追加する必要があります。このアノテーションを追加すると、アプリケーションが自動的にインストルメント化され、メトリクス、トレース、ログを Application Signals に送信するようになります。 spec: replicas: 1 selector: matchLabels: io.kompose.service: billing-service-python template: metadata: labels: io.kompose.service: billing-service-python annotations: instrumentation.opentelemetry.io/inject-python: 'true' /demo-app/k8s/ の下にある デプロイ用の YAML ファイルには、必要なアノテーションが含まれています。以下のコマンドを実行してすべてのリソースをデプロイします。まず、アプリケーションをコンパイル、Docker イメージを作成し、リモートの ECR (Amazon Elastic Container Registry) の Docker リポジトリにプッシュしてから、EKS クラスターにデプロイします。 cd ../.. ./mvnw clean install -P buildDocker export ACCOUNT = `aws sts get-caller-identity | jq .Account -r` export REGION =$ AWS_REGION ./push-ecr.sh ./scripts/eks/appsignals/tf-deploy-k8s-res.sh デプロイの結果の検証 アプリケーションリソースが 正常にデプロイされたことを確認 するため、以下のコマンドを実行してください。ステータスが Running のポッドのリストが表示されるはずです。 kubectl get pods #Output NAME READY STATUS RESTARTS AGE admin-server-java-5c57ddcb46-t4b9l 1/1 Running 0 7m1s billing-service-python-6bf9766cfc-5g67s 1/1 Running 0 6m52s config-server-58d94894-dzdhz 1/1 Running 0 6m47s customers-service-java-69c5d75cc9-5hwrw 1/1 Running 0 6m42s customers-service-java-69c5d75cc9-tfrts 1/1 Running 0 6m43s discovery-server-d6bff754f-xgrxv 1/1 Running 0 6m36s insurance-service-python-6745799b9b-4hdxc 1/1 Running 0 6m33s pet-clinic-frontend-java-5696d89cd8-cpvj2 1/1 Running 0 6m56s pet-clinic-frontend-java-5696d89cd8-mlggq 1/1 Running 0 6m56s vets-service-java-5b6969b8d6-cfvsb 1/1 Running 0 6m29s visits-service-java-85b9c5c45-p57m5 1/1 Running 0 6m25s visits-service-java-85b9c5c45-vwkht 1/1 Running 0 6m25s visits-service-java-85b9c5c45-vx6gj 1/1 Running 0 6m25s 次に、以下のコマンドを実行して アプリケーションにアクセスするための URL を取得してください。ウェブブラウザでその URL を開き、 アプリケーションを体験することができます 。URL が有効になるまで 2～3 分かかる場合があります。 echo "http://$(kubectl get ingress -o json --output jsonpath ='{.items[0].status.loadBalancer.ingress[0].hostname }')" CloudWatch Canary を作成し、トラフィックを生成する 次に、以下のスクリプトを実行して Canary を作成 します。このスクリプトは 10 分間実行され、アプリケーションのトラフィックを生成します。 endpoint =$(kubectl get ingress -o json --output jsonpath ='{.items[0].status.loadBalancer.ingress[0].hostname }') cd scripts/eks/appsignals/ ./create-canaries.sh $ AWS_REGION create $ endpoint CloudWatch Application Signals を使用したアプリケーションの可視化 CloudWatch コンソール に移動し、左側のナビゲーションペインの Application Signals セクションにある サービス  を選択します。 サービスダッシュボード CloudWatch Application Signals は、初期状態で追加のセットアップを必要とせずに、 サービス ダッシュボードからサービスの一覧を自動的に作成します。この統合されたアプリケーション中心のビューは、ユーザーがサービスとどのように対話しているかを全体的に把握するのに役立ちます。パフォーマンスの異常が発生した場合、この機能を使ってトラブルの切り分けをすることができます。 図 3: サービスダッシュボード 詳細なサービス情報と依存関係 サービス詳細ページには、Application Signals 機能を使用しているサービスについて、サービスの概要、オペレーション、依存関係、Canary、クライアントからの要求が表示されます。 このページを表示するには、 CloudWatch コンソール を開き、左側のナビゲーションペインの Application Signals セクションにある Services を選択します。そして、 Services テーブルまたは Top service  あるいは依存関係テーブルから、 任意のサービス名を選択 してください。 図 4 に示すように、 Service Overview セクションでは、サービスを構成するコンポーネントを要約し、トラブルシューティングが必要な問題を特定するための重要なパフォーマンスメトリクスをハイライトしています。 図 4: Service Overview Service operations タブに移動し、オペレーションを選択、メトリクスチャートの特定の時間ポイントをクリックすると、選択したポイントに関連する相関トレース、主要な要因、アプリケーションログを含むペインが開きます。 図 5: Service operations トレース ID をクリックすると、トレースの詳細ページに移動します。そこではこのトレース ID に関連するすべてのアップストリーム及びダウンストリームのサービスが、AWS X-ray トレースマップに表示されます。 図 6: サービスオペレーションメトリクスと関連付けられたトレースを可視化 Top Contributors セクションでは、 Call Volume、Availability、Average Latency、Errors と Faults のメトリックを、インフラストラクチャコンポーネント別に直接表示します。 Application Logs タブでは、関連するアプリケーションログを表示するための Logs Insights クエリを確認できます。 図 7: Top Contributors と Application Logs 数クリックすると相関のあるトレースが表示されます。これにより、手動でトレースを別々に照会することなく問題の根本原因を理解できます。 サービスマップ サービスマップを表示するには、 CloudWatch コンソール を開き、左側のナビゲーションペインにある Application Signals セクションの Service Map を選択して 図 8 に示されているように、 billing-service-python のサービスノードを選択すると、それらのサービス間の接続およびサービスの依存関係ノードを確認できます。これにより、アプリケーションのトポロジーと実行フローを理解しやすくなります。サービスの運用と開発が別組織の場合に特に有用です。 図 8: サービスマップを使ってアプリケーショントポロジーを表示 サービスレベル目標 (SLOs) Application Signals を使用して、最も重要なビジネス オペレーションのサービス レベル目標 (SLO) を定義します。これらのサービスの SLO を定義すると、SLO ダッシュボードでそれらを監視できるようになり、最も重要なオペレーションの概要を素早く把握できます。SLO の条件には、レイテンシ、可用性、CloudWatch メトリクスが含まれ、包括的な監視機能を提供します。 PetClinic アプリケーションの SLO 作成 の手順に従って、 SLO を作成 してください。 図 9: サービスレベル目標 (SLO) を作成し可視化する クリーンアップ 注意: アプリケーションを正常に削除するには、前に定義した 環境変数の値 が必要です。 料金の発生を停止するには、次のコマンドを実行してアプリケーションをクリーンアップしてください。所要時間は 15 ～ 20 分です。 cd ../../.. ./scripts/eks/appsignals/create-canaries.sh $ AWS_REGION delete kubectl delete -f ./scripts/eks/appsignals/sample-app/alb-ingress/petclinic-ingress.yaml cd ./terraform/eks terraform destroy --auto-approve 結論 このブログでは、Amazon EKS クラスター上で実行されている Python アプリケーションを、コード変更を行うことなくシームレスに計装するための CloudWatch Application Signals の活用方法について説明しました。この強力な機能により、アプリケーションサービスのゴールデンメトリクス (リクエスト数、可用性、レイテンシー、障害、エラー) とトレースを簡単に収集でき、監視とトラブルシューティングが容易になります 。 さらに、Application Signals が提供する既製のダッシュボードを使うことで、アプリケーションサービスの全体の活動状況と運用の健全性をどのように視覚化できるかを説明しました。これらのダッシュボードを活用することで、主要なパフォーマンスメトリクスにすばやくアクセスし、トレースと関連付けて、根本的な問題を数クリックで簡単に特定して対処できます。次のステップとして、お客様の環境で Application Signals を試してみることをお勧めします。 CloudWatch Application Signals のドキュメント を参照して、さらに詳しい情報を確認するか、 One Observability Workshop の CloudWatch Application Signals のユースケース を体験してみてください。 著者について Yagr Xu Yagr は、AWS の Senior Solutions Architect で、IT 業界での経験は 15 年以上です。ソフトウェア開発者、データエンジニア、そしてソリューションアーキテクトとして従事してきました。モダンなクラウドアーキテクチャの設計と複雑な技術的課題の解決のために顧客との協働を楽しんでいます。仕事の合間には、アイスホッケー、サッカー、バスケットボール、バドミントンなどのスポーツに情熱を注いでいます。 Jay Joshi Jay は、AWS の Senior Cloud Support Engineer で、Amazon CloudWatch と Route 53 を専門としています。モニタリングとオブザーバビリティを活用してシステムを強化する顧客のサポートに情熱を注いでいます。プライベートでは、アニメを観ることと家族と時間を過ごすことが好きです。LinkedIn: /jayjoshi31 本記事は、 Monitor Python apps with Amazon CloudWatch Application Signals (Preview) を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

コンテナ化されたアプリケーションを監視するには、正確性と効率性が求められます。アプリケーションの規模が大きくなるにつれて、アプリケーションとインフラストラクチャのメトリクスを収集して要約することは困難になります。この課題に対処する方法の 1 つは、AWS が提供するネイティブのモニタリングツール Amazon CloudWatch Container Insights を使用することです。 Amazon CloudWatch Container Insights は、お客様がAmazon Elastic Kubernetes Service クラスター (Amazon EKS) 上で実行されるアプリケーションからメトリクスとログを収集、集計、および要約するのに役立ちます。2023 年 11 月 6 日、AWS は、コンテナレベルの詳細な正常性、パフォーマンス、ステータスメトリクスを収集し、コントロールプレーンのメトリクスも収集する Container Insights の拡張バージョン をアナウンスしました。さらに 2024 年 4 月 10 日、AWS はAmazon EKS の Windows ワークロード向けに Amazon CloudWatch Container Insights の提供を開始しました。 お客様は、 container_cpu_utilization 、 pod_cpu_requested 、 pod_cpu_limit などのメトリクスを Windows アプリケーション用に収集できるようになりました。アウトオブボックスのパフォーマンスメトリクススダッシュボードを使用して、アプリケーションの健全性を理解し、Amazon EKS 上のコンテナ化された Windows アプリケーションの問題を効率的にデバッグできます。CloudWatch Container Insights は、 埋め込みメトリクス形式 を使用してメトリクスデータをパフォーマンスログイベントとして収集します。このデータから、Amazon CloudWatch は、クラスター、ノード、ポッド、サービスレベルで CloudWatch メトリクスとして集約メトリクスを作成します。Container Insights が収集するメトリクスは、CloudWatch の自動ダッシュボードで利用できます。メトリクススの収集は CloudWatch Agent が行い、ログの収集は Fluent Bit が行います。CloudWatch Agent と Fluent Bit の両コンポーネントは、 Amazon CloudWatch Observability EKS Add-on を有効にするときとデプロイされます。 本記事では、Amazon EKS Windows クラスターに Container Insights を有効化するプロセスを説明します。 Amazon EKS Windows クラスターの Container Insights のセットアップ 前提条件 AWS アカウント Kubectl eksctl AWS Command Line Interface (AWS CLI) v2 AWS CLI の認証情報が設定済み Amazon EKS Windows クラスターの作成 まず、Amazon EKS Windows クラスターの作成から始めましょう。クラスターをセットアップする最も簡単な方法は、Amazon EKS の公式 CLI ツールである eksctl を使用することです。以下のコマンドは、 eks-windows-ci という名前のクラスターを作成し、クラスターに 2 つの Linux ノードを追加します。現在、Windows ノードとポッド ネットワーキングをサポートするには、少なくとも 1 つの Linux ノードが必要です。ただし、この例では、高可用性を実現するために 2 つの Linux ノードを指定しています。 この記事を書いている時点で、サポートされている Amazon EKS の最新バージョンは 1.29 であり、サポート対象の Amazon EKS バージョンならどれを選んでも構いません。 eksctl create cluster \ --name eks-windows-ci \ --version 1.29 \ --nodegroup-name linux-ng \ --node-type m5.large \ --region us-east-1 \ --nodes 2 \ --nodes-min 1 \ --nodes-max 3 \ --node-ami-family AmazonLinux2 \ --disable-pod-imds 次に、クラスターにいくつかの Windows ノードを追加する必要があります。eksctl を使用してクラスターを作成した場合は、以下のコマンドで実行できます。別のクラスターで作業する場合は、 ドキュメント を参照して、Windows ノードグループの作成方法とクラスターへの接続方法を確認してください。 利用するリージョンで最新の Windows AMI ID を確認するには、AWS Systems Manager Parameter Store を照会します。手順については、 Amazon EKS ドキュメント をご覧ください。 eksctl create nodegroup \ --region us-east-1 \ --cluster eks-windows-ci \ --name windows-ng \ --node-type m5.large \ --nodes-min 2 \ --node-ami-family WindowsServer2022FullContainer \ --disable-pod-imds 次に、 Amazon VPC IP Address Manager (IPAM) を有効にするために amazon-vpc-cni configmap を変更しましょう。 cat << EOF > amazon-vpc-cni.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true" --- EOF kubectl apply -f amazon-vpc-cni.yaml クラスターが起動して実行中であることを確認するために、kubectl コマンドを使用しましょう。 nht-admin:~/environment $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME ip-192-168-10-132.ec2.internal Ready <none> 2d11h v1.28.5-eks-5e0fdde 192.168.10.132 107.23.236.165 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 ip-192-168-14-178.ec2.internal Ready <none> 2d v1.28.5-eks-5e0fdde 192.168.14.178 54.80.175.223 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 ip-192-168-29-193.ec2.internal Ready <none> 2d11h v1.28.5-eks-5e0fdde 192.168.29.193 3.90.176.199 Amazon Linux 2 5.10.205-195.807.amzn2.x86_64 containerd://1.7.11 ip-192-168-33-121.ec2.internal Ready <none> 2d11h v1.28.5-eks-5e0fdde 192.168.33.121 18.207.151.28 Amazon Linux 2 5.10.205-195.807.amzn2.x86_64 containerd://1.7.11 ip-192-168-46-41.ec2.internal Ready <none> 2d11h v1.28.5-eks-5e0fdde 192.168.46.41 52.90.145.146 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 Amazon CloudWatch Observability EKS アドオンのインストール Container Insights を有効にする最も簡単な方法は、 Amazon CloudWatch Observability EKS アドオン をデプロイすることです。Amazon CloudWatch Observability EKS アドオンは、CloudWatch エージェントと Fluent-bit エージェントを Amazon EKS クラスターにインストールします。Amazon CloudWatch Observability EKS アドオンを利用することで、デフォルトでAmazon EKSに対する Container Insights の拡張されたオブザーバビリティと CloudWatch Application Signals が有効になります。なお、CloudWatch Application signals は現在 Windows ではサポートされていません。このアドオンを使用すると、Amazon EKS クラスターからインフラストラクチャに関するメトリクス、アプリケーションパフォーマンスに関するテレメトリデータ、コンテナのログを収集できます。Fluent Bit がクラスターからコンテナログを CloudWatch Logs に送信します。これにより、コンテナからのアプリケーションとシステムログを把握できます。Amazon EKS アドオンを使用するには、クラスターのワーカーノードで使用される IAM ロールに必要な IAM 権限を設定します。Windows ワーカーノードの場合は、インスタンスロールに IAM ポリシーを関連付けます。 my-windows-worker-node-role を Windows ノードグループの IAM ロールに置き換えてください。 aws iam attach-role-policy --role-name <<my-windows-worker-node-role>> --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy aws eks create-addon --cluster-name eks-windows-ci --addon-name eks-pod-identity-agent --addon-version v1.1.0-eksbuild.1 --configuration-values $'nodeSelector: \n \"kubernetes.io/os\": \"linux\"' --resolve-conflicts OVERWRITE Linux ワーカーノードでは、 EKS Pod Identities アドオン を利用します。 EKS アドオンをデプロイしましょう。EKS Pod Identity エージェントのデーモンセットは Linux ノードでのみデプロイされるように nodeSelector を設定していることに注目してください。この記事の執筆時点では、EKS Pod Identity エージェントは Windows ワーカーノードでサポートされていませんでした。nodeSelector を指定することで、デーモンセットが Windows ワーカーノードにデプロイされないようにしています。 aws eks create-addon --cluster-name eks-windows-ci --addon-name eks-pod-identity-agent --addon-version v1.1.0-eksbuild.1 --configuration-values $'nodeSelector: \n \"kubernetes.io/os\": \"linux\"' --resolve-conflicts OVERWRITE eksctl create podidentityassociation --cluster eks-windows-ci --namespace amazon-cloudwatch --service-account-name cloudwatch-agent --role-name eks-cw-role --permission-policy-arns arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --region us-east-1 次に、以下のように Amazon CloudWatch Observability アドオンをインストールしてください。 aws eks create-addon --cluster-name eks-windows-ci --addon-name amazon-cloudwatch-observability Amazon CloudWatch Container Insights は、お客様の EKS クラスターで有効になります。簡単にオンボーディングできるように、EKS コンソールでクラスターを選択し、アドオンタブを表示することで同じアドオンが使用できます。拡張されたメトリクスとログが CloudWatch コンソール に出てくるようになります。以下のコマンドを使って、CloudWatch Container Insights が正常にデプロイされたことを確認しましょう。 $ kubectl get pods -n amazon-cloudwatch NAME READY STATUS RESTARTS AGE amazon-cloudwatch-observability-controller-manager-6d5954fcttgw 1/1 Running 0 44h cloudwatch-agent-9fvj6 1/1 Running 0 44h cloudwatch-agent-cfzmb 1/1 Running 0 44h cloudwatch-agent-windows-fmlbt 1/1 Running 0 44h cloudwatch-agent-windows-g298d 1/1 Running 0 44h cloudwatch-agent-windows-pw9pl 1/1 Running 0 44h fluent-bit-ctls2 1/1 Running 0 44h fluent-bit-windows-5t57v 1/1 Running 5 (44h ago) 44h fluent-bit-windows-6qhm4 1/1 Running 8 (43h ago) 44h fluent-bit-windows-mcdrm 1/1 Running 6 (19h ago) 44h fluent-bit-wmgp6 1/1 Running 0 44h 注: Windows では、 pod_network_rx_bytes や pod_network_tx_bytes などのネットワークメトリクスは、ホスト OS のコンテナでは収集されません。 CloudWatch のロググループコンソールでも、Fluent Bit エージェントがログの送信を開始したことを確認しましょう。以下のロググループに Windows EC2 インスタンスが表示されるはずです。 CloudWatch ロググループのコンソール サンプルアプリケーションをデプロイして、CloudWatch Container Insights ダッシュボードを確認します。 Container Insights が提供する様々なダッシュボードを理解するため、Windows アプリケーションのサンプルをデプロイしましょう。このアプリケーションは、基本的な Windows IIS サーバを実行します。 cat << EOF > windows-workloads.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: multiple-containers namespace: multiple-containers spec: selector: matchLabels: app: multiple-containers tier: backend track: stable replicas: 1 template: metadata: labels: app: multiple-containers tier: backend track: stable spec: containers: - name: multiple-containers-container-1 image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t google.com " - name: multiple-containers-container-2 image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t amazon.com " nodeSelector: kubernetes.io/os: windows --- apiVersion: apps/v1 kind: Deployment metadata: name: standard-2022-deployment spec: selector: matchLabels: app: standard-2022-deployment tier: backend track: stable replicas: 1 template: metadata: labels: app: standard-2022-deployment tier: backend track: stable spec: containers: - name: standard-2022-deployment image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t google.com " nodeSelector: kubernetes.io/os: windows --- apiVersion: apps/v1 kind: Deployment metadata: name: deployment-web-service namespace: web-service spec: selector: matchLabels: app: deployment-web-service tier: backend track: stable replicas: 1 template: metadata: labels: app: deployment-web-service tier: backend track: stable spec: containers: - name: deployment-web-service image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - | Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\ServiceMonitor.exe'; echo '<html><body><br/><br/><H1>Windows Container Workshop - Windows LTSC2019!!!</H1></body></html>' > C:\inetpub\wwwroot\iisstart.htm; C:\ServiceMonitor.exe 'w3svc'; nodeSelector: kubernetes.io/os: windows --- apiVersion: v1 kind: Service metadata: name: standard-2022-service namespace: web-service spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: deployment-web-service tier: backend track: stable sessionAffinity: None type: LoadBalancer --- EOF kubectl apply -f windows-workloads.yaml 一度デプロイすると、AWS コンソールから、拡張された Container Insights ページが以下のように表示され、クラスター、kube-state、コントロールプレーンのメトリクスの概要が示されます。Container Insights ダッシュボードには、クラスターのステータスとアラームが表示されます。CPU とメモリの使用量が高いリソースを素早く特定するために、事前に設定されたしきい値を用いて、パフォーマンスへの影響を避けるための積極的な対応を可能にします。 Container Insights の Overview さらに、CPU やメモリ使用率などの重要なメトリクスについて、クラスター、ノード、ワークロード、ポッド、コンテナの上位 10 件を確認できます。コンテナレベルまでの情報を提供できることで、Site Reliability Engineer (SRE) がパフォーマンスの問題を特定する平均時間を短縮できます。 トップ 10 リスト クラスター名をクリックすると、パフォーマンスモニタリングダッシュボードが開き、パフォーマンスを分析するための各種ビューが表示されます。表示されるビューには以下のようなものがあります。 クラスター全体のリソース使用率の概要を示すクラスター全体のパフォーマンスダッシュボードビュー 個別のノードレベルのメトリクスを可視化するノード パフォーマンスビュー CPU、メモリ、ネットワークなどのポッド単位のメトリクスに焦点を当てたポッドパフォーマンスビュー 個々のコンテナの使用率メトリクスを詳細に確認できるコンテナのパフォーマンスビュー 例えば、クラスター全体のパフォーマンスダッシュボードから見て全体像をとらえることができます。さまざまなビューを切り替えることで、クラスターからノード、ポッド、コンテナへと徐々に絞り込み、根本原因を見つけることができます。 パフォーマンスダッシュボード マルチテナント環境では、ノイジーネイバー事象を回避するため、各アプリケーションのパフォーマンスを理解することが重要です。そのような場合、の概要ダッシュボードを使用すると、リソースを多く消費しているアプリケーションを簡単に特定し、予防措置をとることができます。以下のダッシュボードは、複数コンテナ名前空間における「名前空間の概要」が表示されており、リソース使用状況の全体像を提供しています。 Namespaceのパフォーマンスダッシュボード Amazon CloudWatch Container Insights のサービスダッシュボードでは、Kubernetes サービスの Pod のコンテナインスタンスの CPU、メモリ、ネットワークパフォーマンスのメトリクスが提供されます。これらのインサイトを活用することで、リソース使用量を最適化したり、コンテナ化されたサービスの問題をより的確に特定できるようになります。 パフォーマンスメトリクスダッシュボードでは、CPU、メモリ、ネットワーク使用率などの主要メトリクスを使用して、アプリケーションの健全性の概要を示します。このダッシュボードは CloudWatch メトリクスと CloudWatch ロググループと統合されているため、ダッシュボードのパネルの 3 つのドットをクリックし、「ログを表示」を選択するだけで、問題の原因を調査できます。Log Insights には事前に用意されたクエリがあり、ログデータを分析してインサイトを得ることができます。 サービスのパフォーマンスダッシュボード メトリクスビューを選択して、対応するメトリクスに移動し、アクションの列の下にある「アラームを作成する」を選択すると、指定したしきい値を超えた際に通知を送ることができます。このダッシュボードは、pod_cpu_utilization メトリクスを使用して、Amazon EKS サービス 「standard-2022-service」 のアラーム作成プロセスを示しています。 メトリクスコンソール アラームの作成 収集されたすべてのメトリクスは、ContainerInsights 名前空間の下で利用可能です。特定のメトリクスに対してアラームを作成したい場合は、この名前空間を使用してメトリクスにアクセスし、対応するアラームを作成できます。 CloudWatch 名前空間における Container Insights クリーンアップ リソースを削除するには、次のコマンドを実行してください。 eksctl delete cluster --name eks-windows-ci 結論 この記事では、Amazon EKS Windows クラスターの Container Insights を有効にするプロセスを紹介しました。数回クリックするだけで、コントロールプレーンとデータプレーンの両方の詳細なメトリクスを収集できます。すぐに使えるダッシュボードを使用して、Windowsワークロードのパフォーマンスの問題を特定するまでの時間と解決にかかる平均時間を短縮できます。Amazon EKSクラスター上で拡張された CloudWatch Container Insights を有効にして、Amazon EKSクラスター上で実行されている Windows ワークロードのトラブルシューティングを効率的に開始するには、 このリンク を使用してください。 著者について Vikram Venkataraman Vikram Venkataraman は、Amazon Web Servicesの Principal Specialist Solutions Architect です。顧客がコンテナ化されたワークロードのモダナイズ、スケーリング、ベストプラクティスの採用を支援しています。彼は Observability に情熱を傾けており、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for Open Telemetry などのオープンソースの AWS Observability サービスに焦点を当てています。 Kulwant Singh Kulwant Singh は Amazon Web Services の Software Development Engineer で、コンテナや Kubernetes などのコンテナオーケストレーターと仕事をしています。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

高速でパーソナライズされた体験を提供するために、Web アプリケーションの構築とレンダリング方法は、長年にわたって大きく進化してきました。その過程で、Web アプリケーションを構築する開発者の役割も、この進化を反映して変化してきました。本記事では、フルスタックの Web 開発の進化過程と、急速に変化する Web アプリケーションエコシステムやユーザーのニーズに対し、開発者が AWS Amplify を使って適応する方法について説明します。 Server-Side Rendering の黎明期 1990 年代とインターネットの初期段階では、Web アプリケーションは主にサーバー側でレンダリングされるアプリケーションでした。これは、HTML ファイルがサーバーに格納され、ブラウザクライアントがダウンロードする静的コンテンツからはじまりました。動的なコンテンツを提供するために、開発者はサーバープログラミング言語 (ASP、Java、PHP、Ruby など) を使って HTML をレンダリングするようになりました。これによって、アプリケーションをユーザーごとに動的に変化させることができるようになりました。アプリケーションは、データベースからデータを取得し、エンドユーザー向けにカスタマイズした状態でそのデータを提供できるようになりました。アプリケーションのユーザー数が増加するにつれ、パフォーマンスが課題となりました。ユーザーは、すべてのインタラクションにおいてページ全体のリロードが必要となったため、ユーザー体験が低下しました。加えて、開発者はサーバーに関連する運用、セキュリティ、スケーラビリティなども管理する必要がありました。 Client-Side Rendering (CSR) と Single Page Application (SPA) の台頭 2000 年代には、 Asynchronous JavaScript and XML (AJAX) と呼ばれるクライアントサイドレンダリングの基礎となるアプローチが登場しました。これにより、ページのリロードなしでデータを非同期に取得できるようになりました。2010 年代中頃には、より高速でパーソナライズされた Web 体験の探求が続きました。それにより、React や Vue などの JavaScript ベースのフレームワークが登場しました。これらのフレームワークは、 Single Page Application (SPA) を構築する革新的なアプローチを導入しました。 従来のマルチページアプリケーションでは、ユーザーの操作ごとにサーバーが新しいページ全体を送信する必要がありましたが、SPA ではユーザーインターフェイスコンポーネントを最初にロードし、その後ユーザーがアプリケーションと対話するときに動的にコンテンツを表示します。これにより、ユーザーの操作がより効率的でシームレスになりました。 このアプローチは、アプリケーションをより効率的に管理する方法を示しました。ここでは、フロントエンドはバックエンドから切り離されています。さらに、エッジ・コンピューティングの進歩を活用し、 コンテンツ・デリバリー・ネットワーク (CDN) にデプロイすることで、インフラストラクチャを管理することなくスケーリングし、グローバルトラフィックへの対応を向上させることができます。 Server-Side Rendering (SSR) の再浮上 Client-Side Rendering はユーザ体験を向上させましたが、いくつかの課題が生じました。 まず、初期レンダリングでコンテンツを取得してからクライアントサイドでレンダリングするため、動的コンテンツの描画に時間がかかるようになりました。さらに、初期レンダリングが空の HTML になるため、コンテンツがなく検索エンジンに最適化されないことがあります。 その結果、機能強化されたサーバー側のアプローチが新しく登場しました。まず、Static Site Generations (SSG) です。ビルド時に静的コンテンツを生成します。静的ファイルは CDN から提供できるため、アプリケーションのグローバルトラフィック処理能力も向上します。次に、Server-Side Rendering (SSR) がアプリケーションで再び使われるようになり、ユーザーのリクエスト時にコンテンツを生成します。これにより、最新の状態に更新された個別のコンテンツを高速に提供できます。これらのアプローチは、 サーバーレスコンピューティング の登場により恩恵を受けています。サーバーレスコンピューティングを使えば、基盤となるインフラストラクチャを心配することなくコードを実行できます。 フルスタックフレームワークの台頭 Client-Side Renderingと Server-Side Rendering にはそれぞれ長所と短所があることをお話ししました。そのため、顧客にとって最高の体験を提供するにはどう構築すべきか判断するのは難しくなります。結果として、開発者はこれらのレンダリングアプローチの利点を活かせるフレームワークを多く利用するようになっています。今日では、 Next.js (React を使用するアプリケーション向け) や Nuxt (Vue.js を使用するアプリケーション向け) などのフルスタックフレームワークは、データフェッチ、レンダリング、キャッシングについてそれぞれの考えに基づいたアプローチを提供しています。これらは単一のコードベースで対応できるので、複数のスタックやデプロイが必要なケースの大変さが軽減されます。例えば、以下のようなものがあります。 Next.js API ルート は、 /api/ フォルダ内に関数を置くだけで、直感的に公開 API を作成できます。 Next.js App Router および React Server Component (RSC) では、 use client と use server という指示を使用して、コンポーネントをレンダリングする場所を指定できます。 イテレーションの速度と、変化するお客様のニーズに適応することが成功の鍵となります。 フルスタックフレームワークの台頭により、開発者はコードを書くことから優れた製品を作ることへと、継続的にフォーカスする点をを移していくことができます。 AWS Amplify : フルスタックの Web、モバイル、AI アプリを構築するために必要な全て フレームワークに加えて、開発者はニーズに応じた適切なクラウド インフラストラクチャにイテレーションとデプロイを簡単に行えるプラットフォームが必要です。 AWS Amplify は、AWS のクラウドバックエンドに接続するための使いやすいライブラリとホスティング プラットフォームを提供します。これには API、ストレージ、認証が含まれます。アプリケーションが成長すると、Amplify は AWS Cloud Development Kit (CDK) で定義されたインフラストラクチャでの拡張性を提供します。Amplify を使えば、開発者は深いクラウド専門知識なしにアプリケーションを数百万人のユーザーにスケールアップできます。Amplify は、Next.js や Nuxt などの一般的なフレームワークに対して ゼロコンフィグデプロイ をサポートし、Amazon S3、Amazon CloudFront、AWS Lambda 全体にわたるデプロイを処理します。 re:Invent 2023 で、AWS Amplify は Gen 2 の開発者体験のパブリックプレビューを発表しました。これは現在 一般提供 されています。開発者コミュニティからのフィードバックを受け入れた変更により、より迅速なイテレーションと自信を持ったリリースが可能になりました。これには、CLI ツールの面倒さを避ける コードファーストの開発者体験 と、 Amazon Q Developer のようなサービスからの AI アシスタンスが含まれています。 また、ローカルテストを通じて素早くイテレーションできるパーソナルクラウドサンドボックスや、フロントエンドとバックエンドの両方を 1 か所で管理できるファイルベースの規約などの機能も含まれています。 生成 AI 時代への進化 生成 AI の進化に伴い、開発者は高速なユーザー体験の実現という再び 新たな課題 に直面しています。まず、生成 AI の基盤モデルは応答に長い時間がかかる可能性があるため、非同期や streaming パターンを検討する必要があります。さらに、ユーザーの会話履歴のようなメモリを管理する必要が出てくる可能性があります。これらの課題はモダンなフレームワークやプラットフォームの重要性を示しています。 AWS Amplify の各機能を活用することで、お客様に魅力的なエクスペリエンスを提供するための機能を統合し、適応できるようになります。ここでは Amplify が  AWS AppSync とデータベースや API への非同期のクエリを提供する、マネージド GraphQL サービスと、主要な基盤モデルへの API アクセスを提供する Amazon Bedrock を活用しています。詳しくは、この フルスタックアプリケーションのサンプル を参照してください。 まとめ 本記事では、Web でのアプリケーション開発の進化について学びました。まず Server-Side アプリケーション、 Client -Side アプリケーションの起源に立ち返り、その後の Server-Side アプローチの適応について掘り下げました。フルスタックフレームワークを使ってクラウドでアプリケーションを構築・スケーリングする方法、サーバーレス、エッジコンピューティング、そして生成 AI などの新しいテクノロジーを活用する方法を探りました。最終的にはこの進化により、高速で、個人に最適化された、AI 駆動のユーザー体験を構築できるようになります。 まずは、 AWS Amplify の新しいコードファーストの開発者体験 でフルスタックの Web アプリケーションを構築してみましょう。 本記事は、「 The evolution of full-stack development with AWS Amplify 」を翻訳したものです。 著者について Daniel Wirjo Daniel is a Solutions Architect at AWS, focused on FinTech and SaaS startups. As a former startup CTO, he enjoys collaborating with founders and engineering leaders to drive growth and innovation on AWS. Outside of work, Daniel enjoys taking walks with a coffee in hand, appreciating nature, and learning new ideas. Fred Hoskyns Fred Hoskyns is a Senior Enterprise Account Manager at AWS. Having worked in both commercial and technical roles at AWS, he partners with enterprises on their cloud and technology strategy. Beyond this, he is passionate about helping people move into technology roles, and providing developers with the latest tools to enhance their productivity. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

Amazon Bedrock では、主要な人工知能 (AI) 企業が提供する高性能な基盤モデル (FM) を利用できるため、生成 AI アプリケーションの構築とスケールする事が容易になります。これらのモデルの中には、特定のユースケースに合わせて微調整したりカスタマイズしたりできるウェイトが公開されているものもあります。ただし、カスタマイズされた FM を安全かつスケーラブルな方法で導入することは容易ではありません。 4月23日より、Amazon Bedrock では、サポートされているモデルアーキテクチャ ( Meta Llama 2、Llama 3、 Mistral など ) のカスタムウェイトをインポートし、オンデマンドモードを使用してカスタムモデルを提供する機能がプレビューで追加されました。 Amazon SageMaker と Amazon Simple Storage Service (Amazon S3) から、 Hugging Face セーフテンサー形式のウェイト付きのモデルをインポートできます 。 この方法では、コード固有のデータセットで Llama 2 をさらにトレーニングして作成された Code Llama 2 のコード専用バージョンなど 、既存のカスタマイズモデルで Amazon Bedrock を使用できます。また、データを使用して独自のビジネスケースに合わせてモデルを微調整し、生成されたモデルを Amazon Bedrock にインポートすることもできます。 これが実際にどのように機能するかを見てみましょう。 カスタムモデルを Amazon Bedrock に持ち込む Amazon Bedrock コンソールでは 、ナビゲーションペインの [ 基盤モデル] セクションから [インポートされたモデル ] を選択します。これで、Amazon Simple Storage Service (Amazon S3) バケットまたは Amazon SageMaker モデルからモデルウェイトをインポートすることで、カスタムモデルを作成できます。 S3 バケットからモデルウェイトをインポートすることにしました。別のブラウザタブでは、 セーフテンソル形式でウェイトを提供するこのプルリクエスト（PR） を使用して、 Hugging Face Web サイトから MistralLite モデルをダウンロードします 。 プルリクエストは現在マージの準備が整っているため 、これを読んだ時点でメインブランチの一部になっている可能性があります。 MistralLite は微調整された Mistral-7B-v0.1言語モデルで 、最大32K トークンのロングコンテキストを処理する機能が強化されています。 ダウンロードが完了したら、モデルをインポートするのと同じ AWS リージョンの S3 バケットにファイルをアップロードします。Amazon S3 コンソールにある MistralLite モデルファイルは次のとおりです。 Amazon Bedrock コンソールに戻って、モデルの名前を入力し、提案されたインポートジョブ名はそのままにしておきます。 モデルインポート設定でモデルウェイトを選択し 、S3を参照してモデルウェイトをアップロードした場所を選択します。 Amazon Bedrock に S3バケットのファイルへのアクセスを許可するために、 新しい AWS ID およびアクセス管理（IAM） サービスロールを作成して使用するオプションを選択します。「 View permissions details 」リンクを使用して、ロールに何が含まれるかを確認します。そして、ジョブを提出します。 約 10 分後、インポートジョブは完了します。 これで、インポートされたモデルがコンソールに表示されます。リストには、モデルの Amazon リソースネーム (ARN) と作成日も表示されます。 モデルを選択すると、モデルファイルの S3 の場所など、詳細情報を取得できます。 モデルの詳細ページで、[ Open in Playground ] を選択して、コンソールでモデルをテストします。テキストプレイグラウンドでは、モデルのプロンプトテンプレートを使用して質問を入力します。 <|prompter|>LLM の長いコンテキストをサポートするうえでの主な課題は何か？</s><|assistant|> MistralLite のインポートモデルは、これらの課題のいくつかについて素早く答え、説明してくれます。 Playground では、温度や最大長などの設定を使用してユースケースに合わせてレスポンスを調整したり、インポートしたモデルに固有のストップシーケンスを追加したりできます。 API リクエストの構文を確認するために、Playground の右上にある 3 つの小さな縦の点を選択します。 View API syntax を選択し、AWS コマンドラインインターフェイス (AWS CLI) を使用してコマンドを実行します 。 aws bedrock-runtime invoke-model \ --model-id arn:aws:bedrock:us-east-1:123412341234:imported-model/a82bkefgp20f \ --body "{\"prompt\":\"<|prompter|>What are the main challenges to support a long context for LLM?</s><|assistant|>\",\"max_tokens\":512,\"top_k\":200,\"top_p\":0.9,\"stop\":[],\"temperature\":0.5}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt 出力はプレイグラウンドで得たものと似ています。ご覧のように、インポートされたモデルの場合、モデル ID はインポートされたモデルの ARN です。モデル ID を使用して、インポートしたモデルを AWS CLI と AWS SDK で呼び出すことができます。 知っておくべきこと サポートされているモデルアーキテクチャの独自のウェイトを、米国東部 (バージニア北部) AWS リージョンの Amazon Bedrock に持ち込むことができます。モデルのインポート機能は現在プレビュー版です。 カスタムウェイトを使用する場合、Amazon Bedrock はモデルをオンデマンドモードで提供し、使用した分のみお支払いいただき、時間ベースの契約は不要です。料金に関する詳細については、「 Amazon Bedrock pricing 」を参照してください。 モデルのインポート機能は AWS Identity and Access Management (IAM) を使用して管理され、この機能を必要とする組織内のロールにのみ許可できます。 今回の発表により、セキュリティとプライバシーが組み込まれたカスタムモデルを使用して、生成 AI アプリケーションの構築とスケールする事が容易になりました。 詳細はこちら。 Amazon Bedrock User Guide . community.aws サイトにアクセスして 、詳細な技術コンテンツを検索したり、他の企業が自社のソリューションで Amazon Bedrock をどのように使用しているかを調べたりできます。 – Danilo 原文は こちら です。

本記事は、2024 年 4 月 30 日に投稿された Accelerate software development and leverage your business data with generative AI assistance from Amazon Q を翻訳したものです。 我々は生成 AI があらゆる顧客体験を革新する可能性があると考えています。そのために、 生成 AI スタックの 3 層 すべてで最も包括的な機能を提供すべく、急速にイノベーションを進めています。これには以下が含まれます。 上位層: 革新的なアプリケーションへの投資 中間層: 生成 AI アプリケーションを簡単かつ迅速に構築するためのツール 下位層: 大規模言語モデル (LLM) や他の基盤モデル (FM) を学習し、推論や予測を行うためのインフラ これらすべてのレイヤーは生成 AI の進化に重要ですが、本記事では上位層にあたるアプリケーション層への投資について説明します。 生成 AI アシスタントを使って、開発者やビジネスアナリスト、さらに顧客サービスやサプライチェーン運用などの専門分野の従業員まで、誰もが今まで以上に生産的、創造的、データ主導的になれます。しかし、作業時に真に役立つ生成 AI アプリやアシスタントには、組織のデータ、顧客、業務、ビジネスを理解することが求められるものの、現在のアシスタントの多くは、簡単にカスタマイズができず、企業が必要とするデータプライバシーとセキュリティの要件を満たすように設計されていません。 Amazon Q は、ソフトウェア開発の加速とビジネスデータの活用を可能にする、最も優れた生成 AI 機能を備えたアシスタントとして開発されました。今日は Amazon Q Developer 、 Amazon Q Business 、 Amazon Q in QuickSight が利用可能になったこと、そして新機能が多数追加されたことをお伝えできてうれしく思います。Dr. Matt Wood の動画で、今日のアナウンスとデモの概要を見ることができます。 Amazon Q は、現在最も機能が優れた業務支援アシスタントで、私たちは設計段階からセキュリティとプライバシーを意識して構築しました。従業員が通常アクセスできないデータソースには、Amazon Q 経由でもアクセスできません。本記事ではたくさんの優れた機能と体験をご紹介しますが、ここではその中の一部を取り上げたいと思います。 Amazon Q Developer – 開発ライフサイクル全体をサポートする開発アシスタント Amazon Q Developer は、開発者と IT 専門家が直面するすべてのタスク (コーディング、テスト、アップグレード、トラブルシューティング、セキュリティスキャンと修正、AWS リソースの最適化、データエンジニアリングパイプラインの作成など) をサポートします。既に顧客は Amazon Q Developer の価値を認めており、デジタルトランスフォーメーションサービスを提供する Eviden は 20 ~ 40 % の生産性向上、医療関連企業の Switchboard MD は新機能のデプロイ時間を 25 % 削減、倉庫管理と在庫ストックソリューション企業の Datapel Systems は 70 % 以上という素晴らしい効率改善を実現しています。 Amazon Q Developer では、リアルタイムに近いコード提案とレコメンデーションを生成することで、開発者がより早く、より安全にアプリケーションを構築できるようサポートします。実際、複数行にわたるコード提案を行うアシスタントでは、Amazon Q Developer が最も高いコード受入率だと報告されています。BT グループは Amazon Q Developer のコード提案の 37 %を、National Australia Bank は 50 %を受け入れたと報告しています。これらのコーディング支援機能の一部は、以前は Amazon CodeWhisperer によって提供されていましたが、現在は Amazon Q Developer の一部になっています。 Amazon Q Developer エージェントは様々なタスク、例えば、機能の実装、ドキュメントの作成、コードのリファクタリング、ソフトウェアのアップグレードを自動的に実行できる機能を備えています。Amazon Q Developer に E コマースアプリの新しいチェックアウト機能を追加するよう依頼すると、既存のコードベースを分析し、複数のファイルにまたがる実装計画を立て、承認を受けると、必要なすべてのコード変更とテストを数分で実行します。この機能の実動作は、 Implement an API with Amazon Q Developer Agent for Software Development でご覧いただけます。また、ソフトウェア開発の能力をベンチマークするデータセット SWE-Bench のリーダーボードで 13.4 %、SWE-bench リーダーボード (Lite) で 20.5 % という最高スコアを達成しました。これらの機能強化は、数日中にお客様にご利用いただけるようになります。 Amazon Q はアプリのアップグレードも自動化でき、数日の作業を数分に短縮できます。Amazon の 5 人のチームは、Amazon Q Code Transformation エージェントを使用して 1,000 を超える本番環境のアプリケーションを Java 8 から Java 17 に 2 日でアップグレードしました (1 アプリあたりの所要時間は平均 10 分未満)。これによって数か月分の時間を節約し、アプリのパフォーマンスも向上しました。現在、Amazon Q は Java 言語のアップグレードを実行できますが、近々、.NET のクロスプラットフォーム環境の Linux への移行を支援することで、ライセンス料の節減に貢献する機能が追加される予定です。コード変換エージェントの実動作については Amazon Q Developer Agent for Code Transformation で Java アプリをアップグレードする で確認してください。 加えて、「 What instances are currently running in us-east-1 ? ( us-east-1 リージョンで現在実行中のインスタンスは何ですか？) 」や「 What’s my S3 bucket encryption ? (私の S3 バケットの暗号化設定は何ですか？) 」あるいは「 What were my EC2 costs by region last month ? (先月の EC2 コストをリージョン別に教えてください。) 」といった、自身の AWS アカウントについての質問を Amazon Q Developer に質問できるようになり、Amazon Q Developer が要約した回答とそれをさらに学ぶためのリンクを用いて、リソースや詳細をリスト化してくれます。 Amazon Q Developer の詳細は、 AWS ニュースブログ でご確認ください。 Amazon Q Business によって、従業員はより創造的で、データ駆動型で、効率的で、生産性の高い存在に Amazon Q Business を提供する私たちのビジョンは、生成 AI の力を企業に広く利用してもらい、企業が保有するあらゆるデータから洞察を得られるようにし、アクションを起こし、アプリケーションを構築することです。 ほとんどの企業は、アクセスしにくくかつ活用されていない大量のデータを抱えています。Amazon Q Business では、従業員が企業ポリシー、製品情報、業績、コードベース、人材、その他多数のトピックにまたがる業務データに対して、質問に答えられます。これは、企業のデータリポジトリに接続し、データを論理的に要約、トレンド分析し、データについて対話することを可能にしています。Amazon Q Business は、他の生成 AI アシスタントよりも多くのビルトイン、マネージド、セキュリティ保護されたデータコネクタを備えているため、これが可能になっており、Wiki、社内イントラネット、Atlassian、Gmail、Microsoft Exchange、Salesforce、ServiceNow、Slack、Amazon Simple Storage Service (Amazon S3) などの一般的なビジネスツールが含まれます。カスタムプラグインを利用すれば、休暇申請といったアクションを Amazon Q Business に直接実行させることも可能です。最新の売上データの概要を知りたい、見込みとなるお客様の競合情報を探したい、といった場合でも、Amazon Q Business の自然言語処理機能は、分散したドキュメント、データベース、チャットログから関連する情報をすばやく統合し、一貫性のある回答にまとめます。 今日の最も興味深いお知らせの 1 つが、Amazon Q Business の機能である Amazon Q Apps です。 Amazon Q Apps は、生成 AI が搭載されたアプリを会話から数秒で構築可能にし、日々の作業を合理化・自動化することを容易にしてくれます。Amazon Q Apps でアプリを作成するのは簡単です。従業員は、作りたいアプリの形式を自然言語で説明する、もしくはAmazon Qと問題解決方法について会話しながら作成することができます。例えば、マーケターは Q Apps に顧客の名前、使用製品、ビジネス上の課題や影響を入力するだけで、説得力のある顧客事例を生成するアプリを作れます。アプリは数秒で作成され、その後、組織内のマーケティング部門とで共有できます。他の例については Amazon Q Apps の紹介 (プレビュー) をご覧ください。 Smartsheet の製品・イノベーション統括責任者である Praerit Garg 氏に話を聞き、Amazon Q Business が従業員の回答時間の短縮と生産性の向上、さらには新入社員のオンボーディングの迅速化にどのように役立っているかについて議論しました。 AWS ニュースブログ および AWS Machine Learning ブログ で Amazon Q Business の詳細を確認してください。 生成 BI により詳細なダッシュボードを数分で構築し、ビジネスユーザーが素早く洞察を得ることが可能に 従来、企業は貴重な構造化データの大半をデータベースやデータウェアハウスに保存し、ビジネスインテリジェンス (BI) ツールでのみアクセス可能でした。ビジネスの経営陣がデータから情報を抽出する必要があった場合、多くのタスクを抱えているビジネスアナリストに頼んでダッシュボードを作成してもらう必要がありました。その作業には数日から数週間を要することがよくあり、ダッシュボードができたとしても、重要な洞察を抽出し共有するのは困難でした。しかし今や、Amazon Q が AWS のクラウド向けの統合 BI サービス Amazon QuickSight に先進的な生成 AI 技術を導入しました。Amazon Q in QuickSight によって、ビジネスアナリストは自然言語を用いて、ダッシュボードの構築を数時間から数分に短縮できるようになりました。また、データへのアクセシビリティが高まることによって、組織全体で誰もがデータに基づいた意思決定ができるようになります。Amazon Q によって、ビジネスユーザーがダッシュボードの AI による要約を閲覧したり、ダッシュボードで表示されている以外のデータにもすぐに質問することができます。さらに詳細でカスタマイズ可能なデータストーリーを作成することができ、重要な洞察、トレンド、動向を明確にできます。そしてこれは自然言語で行いたいことを質問するだけで操作できるのです。 営業支援ソリューションを提供する Showpad は、複雑なユーザーインターフェースや SQL の知識が無くともデータに問い合わせが可能な機能を顧客に提供できるようになりました。統合には 1 週間強の時間しかかからず、Showpad は自身の体験にシームレスに利用できるようカスタマイズできました。また、ヘルスケアIT企業の Clinigence Health は Amazon Q in QuickSight を利用して、従来はデータからインサイトやトレンドを把握するために数時間かかっていたプロセスを数分でできるようになりました。 Amazon Q in QuickSight の詳細については、 AWS Business Intelligence ブログ をご覧ください。 Amazon Q Developer 無料利用枠を含む新料金体系 これらの新機能に加えて、Amazon Q が使いやすくなる新しい料金体系を発表しています。個人向けには、IDE とコマンドラインでのコーディングが無料で、Amazon Q Developer Agent などの高度な機能を限られた範囲で無料で利用できる Amazon Q Developer 無料利用枠 があります。組織でのライセンス管理や、コードベースをカスタマイズすることで、より関連性の高いコーディング候補を得られる、高度な機能を希望するお客様向けに、月額 19 ドル/ユーザーで Amazon Q Developer Pro をご利用いただけます。月額 20 ドル/ユーザーのサブスクリプション Amazon Q Business Pro では、Amazon Q Apps や Amazon Q in QuickSight (Reader Pro) の利用を含む、Amazon Q Business の全機能をご利用いただけます。最後に、Amazon Q Developer Pro と Amazon Q Business Pro の無料トライアルを 2024 年 6 月 30 日まで利用できます。 Amazon Q Developer、Amazon Q Business、Amazon Q in QuickSight で、これらの新機能を提供できることをうれしく思います。生産性を高め、組織のデータをより効果的に活用し、新しい働き方を生み出すお手伝いを我々は始めたばかりです。 この発表の詳細を知るためのリソースについて プレスリリース: AWS、ソフトウェア開発を加速し企業の内部データを活用するための最も高機能な Generative AI 対話アシスタント「Amazon Q」の一般提供を発表 Amazon Q デベロッパーセンター : 詳細な技術コンテンツを確認し、ソフトウェア開発作業を加速する方法を学ぶ community.aws : 詳細な技術コンテンツを確認し、ビルダーコミュニティが Amazon Q をどのようにソリューションで活用しているかを学ぶ AWS の Generative AI サービス について詳細を学ぶ Amazon Q 入門 (15 分のコース) Amazon Q Business 入門 (Amazon Q Business の機能とユースケースを紹介し、Amazon Q を使ったチャットボット構築方法を教える 1 時間のコース) 著者について Swami Sivasubramanian は、AWS のデータベースアナリティクスおよび機械学習担当のバイスプレジデントです。Swami はすべての AWS データベース・分析・AI & 機械学習サービスを監督しています。彼のチームの使命は、データを保存、アクセス、分析、視覚化、予測するための完全なエンドツーエンドのデータソリューションを使用して、組織がデータを活用できるよう支援することです。

4 月は新規リリースが目白押し! この傾向は4月29日週から続き、セキュリティ、分析、DevOps などのさまざまなドメインをサポートする多くの新しいリリースと、生成 AI のさらにエキサイティングな新機能が追加されました。 AWS Summit London 2024 を見逃した方も、 オンデマンドでセッションを視聴 できます。VP & Marketing Director, EMEA の Tanuja Randery による基調講演や、今後数週間にわたって公開される予定の多くの分科会セッションもご覧いただけます。 4月29日週のリリース 5月6日週のハイライトのうち、私の目に留まったものをいくつかご紹介します。 AWS CodePipeline の任意のステージからの手動および自動ロールバック – AWS CodePipeline で V2 パイプラインを使用している場合、ソース以外の任意のステージを良好な以前の既知の状態にロールバックできるようになりました。障害が発生した場合に最後に成功したパイプライン実行のソース変更を使用する自動ロールバックを設定するか、コンソール、API、または SDK から任意のステージの手動ロールバックを開始して、ロールバックに使用するパイプライン実行を選択することもできます。 AWS CodeArtifact が RubyGems をサポート –  Ruby コミュニティの皆さんに朗報です。Gem を AWS CodeArtifact に保存できるようになりました！ RubyGems.org と統合すると、CodeArtifact はクライアントからリクエストされたすべての Gem を自動的に取得し、CodeArtifact リポジトリにローカルに保存します。つまり、ファーストパーティとパブリックの両方の Gem を一元管理できるので、開発者は単一のソースから依存関係にアクセスできます。 AWS CodeArtifact でリポジトリを作成し、「rubygems-store」を選択して、[Public upstream repositories] ドロップダウンでリポジトリを RubyGems.org に接続します。 Amazon EventBridge Pipes が AWS PrivateLink からのイベント配信をサポート – AWS PrivateLink を使用することで、パブリックインターネットを経由せずに イベントを Amazon EventBridge Pipes ターゲットに配信できるようになりました。 Amazon Virtual Private Cloud (VPC) のプライベートサブネットのイベントをポーリングできます。トラフィックをプライベートに保つために追加のインフラストラクチャをデプロイする必要はありません。 Amazon Bedrock のローンチが続いています。 Cohere Command R と R+ を使用して、スケーラブルなエンタープライズグレードの生成 AI ワークロードを実行 できるようになりました。そして、 Amazon Titan Text V2 が検索拡張生成 (RAG) 改善のために最適化 されました。 AWS Trusted Advisor – 昨年、お客様がプログラムでレコメンデーションを利用できるようにする Trusted Advisor API がローンチされました。新しい API が利用可能になり、 レコメンデーションからリソースを除外 できるようになりました。 Amazon EC2 – 今週、EC2 ユーザー向けに新たに 2 つのすばらしいローンチがありました。 AMI を「保護済み」としてマーク して、誤って登録が解除されるのを防ぐことができるようになりました。また、 説明するだけでアクティブな AMI を簡単に見つける ことができるようになりました。 Amazon CodeCatalyst – CodeCatalyst コンソールで Git コミットの履歴を表示 できるようになりました。 一般提供の状況 5月6日週は、多くの新しいサービスと機能の一般提供が開始されました。 Amazon Q in QuickSight – Amazon Q で生成 BI が Amazon QuickSight に導入され、自然言語を使用するだけで美しいダッシュボードを自動的に構築できるようになりました。この機能は、現在、一般提供中です。使用を開始するには、 Quicksight の料金ページ にアクセスしてすべてのオプションを参照するか、QuickSight アカウントあたり最大 4 人のユーザーが生成 AI のすべての新機能を使用できる 30 日間の無料トライアルを開始してください。 Amazon Q の Amazon QuickSight によって可能になった新しい生成 AI 機能により、自然言語クエリを使用してダッシュボードを作成、並べ替え、フィルターできます。(出典: AWS ドキュメント ) Amazon Q Business (GA) と Amazon Q Apps (プレビュー) – 2023年の AWS re:Invent 2023 でローンチした Amazon Q Business の一般提供も開始され、Microsoft 365、Salesforce、 Amazon Simple Storage Service (Amazon S3) 、Gmail など、40 以上の一般的なエンタープライズシステムとシームレスに接続できるようになりました。これで Amazon Q Business がお客様のビジネスについて知ることができるため、従業員は、コンテンツの生成や問題の解決に加えて、お客様のビジネスに固有のアクションを実行できるようになります。 また、カスタムプラグインのサポートも提供されているので、任意のサードパーティアプリケーションとの独自の統合を作成できます。 Amazon Q Business の一般提供に伴い、任意のサードパーティ API に接続するための独自のカスタムプラグインを作成する機能もローンチされました。 このリリースのもう 1 つのハイライトは、Amazon Q Business との会話から、または生成するものを説明することでアプリをすばやく生成できる Amazon Q Apps のローンチです。Amazon Q Business のすべてのガードレールが適用され、管理者が管理するライブラリを介してアプリを同僚と簡単に共有できます。Amazon Q Apps は現在プレビュー中です。 Amazon Q Business と Amazon Q Apps の詳細 については、これらの新機能のガイドを提供する Channy Yun の投稿を参照してください。 Amazon Q Developer – Q Developer を使用して、で開発者フローを完全に変更する ことができます。これには、Q&A、一般的なエラーの診断、テストを含むコードの生成など、以前は Amazon CodeWhisperer として知られていたすべての機能が搭載されています。拡張された結果、SQL を生成することや、自然言語を使用してデータ統合パイプラインを構築することが可能になりました。プレビューでは、AWS アカウントのリソースについて説明すること、および AWS Cost Explorer からコストデータを取得して分析することができます。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS オープンソースのニュースと更新  – 同僚の Ricardo は、AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Claude 3 の詳細 – Claude 3 の使用を開始するための良質のソースを探している場合、私の同僚の Haowen Huang による「 Mastering Amazon Bedrock with Claude 3: Developer’s Guide with Demos 」という優れた投稿がお勧めです。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。次のいずれかの最寄りの都市でご登録ください: シンガポール (5 月 7 日)、 ソウル (5 月 16～17 日)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、 マドリード (6 月 5 日)。 AWS re:Inforce – ペンシルバニア州で 6 月 10～12 日に開催される AWS re:Inforce において、2 日半かけて行われる、生成 AI の時代におけるクラウドセキュリティの没入型学習をぜひご体験ください。 AWS Community Day  – 世界中のエキスパート AWS ユーザーや業界リーダーによる技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにぜひご参加ください。日程は、 トルコ (5 月 18 日)、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) です。 GOTO EDA Day London – 5 月 14 日にロンドンで開催されるこのイベントに参加して 、スケーラビリティ、耐障害性、拡張性の高いアプリケーションを構築するためのイベント駆動型アーキテクチャ (EDA) について学びましょう。このカンファレンスは、GOTO、AWS、および複数のパートナーによって主催されます。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 5月6日週はここまでです。5月13日週の Weekly Roundup もお楽しみに! — Matheus Guimaraes この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

製造業において効率性と冗長性の絶妙なバランスは、市場競争力に大きく寄与します。INVISTA は、ポリマーや繊維などを扱う化学中間製品のグローバル企業です。同社は先ごろ実施した全面的な業務の見直しにより、単なる改善ではなく、事実上完全な変革を成し遂げました。INVISTA はデジタルツインの取組みにおいて、Amazon Web Services ( AWS ) に支援を依頼し、 AWS パートナーである Matterport ( 空間データの先駆的企業 ) と AWS IoT TwinMaker （建築物、工場、産業機器、製造ラインのデジタルツインを簡単に開発できるサービス）の間にシナジーを見出しました。この仮想化によって、業務効率、安全性、イノベーションにおけるパラダイムシフトが起きたのです。 【 INVISTA の課題】複雑な業務を合理化 ナイロン 6,6 や ポリプロピレンの生産供給におけるリーディングカンパニーである INVISTA は、定年退職が迫る従業員の持つノウハウを維持したいと考えていました。ノウハウ継承の方法として、仮想的なナレッジベース構築が不可欠でした。他の従業員が、そこに蓄積された専門知識に基づいて業務を行うためです。さらに INVISTA は、現代の製造業に共通する課題に直面していました。それは、互いに離れた拠点にまたがる複雑なデータセットを管理しながら、保有設備の性能を維持することです。成功するためには、設備の稼働率を高め、現場作業を改善し、運営コストを削減しながら、職場の安全性と持続可能性に関する企業および社会的責任を果たしたうえで、運営コストは削減することが極めて重要でした。INVISTA は Matterport と協力し、 AWS IoT TwinMaker と Matterport の統合により、製造施設のデジタルツインを開発しました。 【解決策】AI を活用した持続可能な操業デジタルツイン Matterport デジタルツインと AWS IoT TwinMaker の統合は、画期的なソリューションでした。AWS IoT TwinMaker で3D描画を実現することにより、INVISTA は現場作業員に対して場所や状況に応じた良質な判断材料を提供できます。すなわち現場では、デジタルツインからも状況を知ることで、問題発生時に独力で素早く問題に対処できます。加えて、システムへのナレッジ追加が容易なことから、コラボレーションも促進されます。INVISTA は現在、Matterport と AWS で稼働する、従業員が協力して作り上げたナレッジベースを保有しており、それは絶えず成長し続けています。Matterport は既に、ほぼあらゆるワークロードに対応するセキュアで可用性の高い Amazon Elastic Compute Cloud ( Amazon EC2 ) と、完全マネージドなコンテナオーケストレーションサービスである Amazon Elastic Container Service ( Amazon ECS ) を利用しているため、AWS IoT TwinMaker との統合はほぼシームレスに行えました。 二社の協業体制は、以下の分野で恩恵をもたらしています。 リモートサービス管理 : 施設や設備のリモート監視と管理を容易にします。この機能により、現地作業の必要性が大幅に低減し、運用コストが削減され、サステナビリティ目標の達成にも一助となります。 IoT センサーの生データ、映像、および基幹システムのデータを取込んだ Matterport デジタル ツインを利用することで、運用上の判断材料がほぼリアルタイムに把握できます。これにより、場所を選ばず迅速な意思決定と問題解決が可能になります。 予防保全 : データ分析による予防保全によって、装置の稼働時間を延ばし、ピーク性能を維持できます。この機能の統合により、劣化等の傾向を見つけ、装置の健全性を監視し、問題が深刻化する前に予防保全を行うことができます。 簡単に物理環境のデジタルモデルを作成できるようにすることで、製造オペレーションの可視化と最適化が容易になり、施設資産の高い性能を確実に維持することができます。 従業員を教育し、ノウハウ喪失を防ぐ : Matterport のデジタルツインを使って、システムとオペレーションの没入感を備えた 3D ビューを構築し、従業員研修のための魅力的で対話的なプラットフォームを構築します。このアプローチは、学習体験を向上するだけでなく、社内ノウハウの効率的な維持と伝承にも役立ちます。 実世界の環境を正確にモデル化し、物理システム上のデータソース群を仮想空間のレプリカに連携することで、ナレッジグラフを自動生成させることができるようになり、時間効率と正確性が向上します。これは、運用ナレッジを体系的に維持する上で不可欠であり、従業員の離職で重要情報を失うリスクを軽減できます。 INVISTA Architectural Design: Matterport and AWS IoT TwinMaker Integration 【実装】データから洞察を得る ソリューション実装のプロセスは、Matterport の技術を用いて INVISTA が保有する施設の詳細なデジタルツインを作成することから始まりました。これらデジタルレプリカは後に、AWS IoT TwinMaker を通じて IoT センサーの生データ、映像、基幹システムのデータなど様々なデータソースを統合する基盤となりました。この統合により、INVISTA は次の能力を獲得しました。 統一的な 3D ビュー: 工場内各所の運用状況が没入感をもって見渡せることで、意思決定能力を向上させます。 ライブデータの埋め込み: 全プラントの運用状況が一元管理されたダッシュボードにアクセスし、管理が行えます。データをニアリアルタイムに分析し、洞察を得ることで、運用の最適化と予防保全を行います。 遠隔での協働作業: チームメンバーがリモートで協力できる環境を整え、会社全体への効果を促進することで、コストを削減し、運用の安定性を高めます。 【成果】将来の成功に向けた青写真 INVISTA が従来型からデジタルを活用した運用に舵を切ったことは、事実上、製造業界に新しい標準を提案することとなりました。Matterport と AWS IoT TwinMaker の統合はコスト削減のみならず、明日の産業界に恩恵をもたらす変革の種をまくことができました。主な成果の例として、以下のものがあります: 運用効率の向上: ニアリアルタイムの監視、シミュレーション、最適化ができるため、生産性が大幅に向上し、コスト削減につながりました。 安全性と持続可能性の向上: 現地作業の必要性が減り、関連業務のマネジメントが改善されたことは、これまでにない安全性と持続可能性を備えた運用モデルが実現できることを示しました。 データドリブンな意思決定: 実世界のデータと既存システムのシームレスな統合により、過去に例のない立体データからの示唆が得られ、業務全体で継続的に高い能力を発揮するために、情報に基づく意思決定ができるようになりました。 上述した Matterport デジタルツインと AWS ワークロードの統合による成果は革新的なものであり、複数の重要な領域で大きな改善をもたらします。この統合は、複雑なデータセット群の管理を合理化し、推論と分析による予防保全で設備の稼働率を向上させるだけでなく、現地作業の必要性を減らすことでサステナビリティ目標達成にも貢献する上、運用コストと環境への影響を最小限に抑えられます。さらに、Matterport デジタルツインに、 IoT の生データ、映像、基幹システムのデータを組み込むことで、ニアリアルタイムの気づきと意思決定が可能となり、運用効率が一層高まります。 加えて、全てのデータソースが連携するMatterport デジタルツインに、単一の統合インターフェイスを作ることで、業務効率が向上するだけでなく、社内ナレッジ喪失のリスクが大幅に軽減されます。3D 化されたビューを活用できる研修シナリオで、効率性の向上、生産量の増加、パフォーマンス改善に特に効果を発揮します。ナレッジグラフを自動生成できるようにするために、各種データソースを物理システムの仮想レプリカに連携しています。これは、実世界の環境をモデル化するうえで重要な役割を果たし、短期間で忠実にデジタル表現を構築します。 Matterport と AWS IoT TwinMaker の統合により、INVISTA は全社的な効率性を実現するために必要なツールを手に入れました。これは伝統的な業務運用からデジタル運用への移行を促進し、直接的なコスト削減だけでなく、継続的な改革と革新の基盤が築かれました。 この戦略的アプローチにより、INVISTA は製造業界のリーダーとしての地位を維持し、自信を持って将来の課題に立ち向かうことができるでしょう。 総じて、Matterport と AWS IoT TwinMaker の統合は効率的で柔軟性があり、製造オペレーションの可視化、監視、最適化を実現するための持続可能なプラットフォームを提供することから、INVISTA 従業員の効率性向上と社内ノウハウ喪失防止に、大きく寄与しています。この技術的進歩は、INVISTA のデジタル変革を後押しし、革新的なデジタルソリューションを通じて操業を管理し、高パフォーマンスを維持するための、業界における新しい標準を確立しています。 INVISTA のデジタルツイン　その道のり をハノーバーメッセ 2024で紹介 ハノーバーメッセ2024では、Matterport と AWS が共同ブースを出展します。そこでは、INVISTA にフォーカスした「Unlocking Operational Excellence: Invista’s Digital Twin Journey」（操業の卓越性を解き放つ : INVISTA のデジタルツイン導入の道のり）と題するプレゼンテーションが、ハイライトの1つです。4月22日の午後3時（中央ヨーロッパ時間）に予定されているこのセッションでは、INVISTA の Grant Johnson 氏、AWS の Pallavi Chari 氏、Matterport の Brittany Schramm 氏が登壇します。参加者は、INVISTA がデジタルツイン技術を採用した先進的な取り組みについて貴重な洞察を得ることができるでしょう。MatterportとAWS IoT TwinMaker の統合がどのように運用を革新し、業界に新基準を打ち立てたかを深く理解できるでしょう。 【まとめ】イノベーションを導く INVISTA の事例 は、Matterport のデジタルツイン技術と AWS IoT TwinMaker の持つ堅牢な機能との組合せが、大きな力を生むことを証明するものです。企業が将来を見据える中で、この統合の成功は、テクノロジーを活用して運用の卓越性を実現するための青写真を提供しています。Matterport と AWS のパートナーシップは、製造業界における可能性を実質的に再定義するだけでなく、デジタルイノベーションがどのように実際のビジネス成果に繋がるかを示しています。 今後、INVISTA のデジタルツイン導入から得られた教訓は、間違いなく様々な業界での実現に影響を与えていくでしょう。Matterport と AWS IoT TwinMaker によるたった1つのデジタルツインが、運用に革命を起こす可能性を秘めていることの証です。 Matterport と AWS が製造業の運用の未来を形作っていく方法についてさらに学びましょう TAGS: AWS for Industrial , AWS IoT TwinMaker , aws manufacturing Krishna Doddapaneni Krishna は、AWS で IoT 分野における業界パートナー向けのワールドワイドテクニカルリードです。日頃、パートナーと顧客が構築する極めて挑戦的で革新的な IoT 製品やソリューションの支援をしています。Krishna は、無線センサーネットワークで博士号、ロボットセンサーネットワークでポスドク研究員を務めました。彼は「コネクテッド」ソリューション、テクノロジー、セキュリティとそのサービスに情熱を注いでいます。 Katie Lameti Katie Lameti は、Matterport で AWS とのグローバルパートナーシップを率いています。彼女は AWS 内の各チームや AWS パートナーネットワーク内の他組織と協力し、顧客がビジネス価値を促進するデジタルツインソリューションの構想、調達、実装、拡張を支援する市場開拓の戦略を策定しています。 Paul Park Paul Park は、Matterportのパートナーマーケティングディレクターであり、AWS との共同マーケティングの戦略、企画、実行を主導しています。Paul は製品マーケティングとビジネス開発の思考を組合せ、共同のメッセージング、マーケティングコンテンツ、キャンペーン計画を立案しています。 Roberto Quintana Roberto Quintana は、IoT、エッジコンピューティング、アナリティクス分野でイノベーションと成長を牽引する経験豊富なテクノロジーリーダーです。20年以上にわたるキャリアの中で、Amazon Web Service ( AWS ) や Nokia Networks などの業界大手企業で重要な役割を果たしてきました。現在、Roberto は AWS の IoT およびエッジテクノロジーパートナーシップグローバルマネージャーを務め、戦略的なテクノロジーパートナーシップを通じて、戦略、市場開拓の主導、最先端ソリューションの開発を推進しています。 この投稿は、「 INVISTA’s operational transformation with Matterport and AWS IoT TwinMaker 」 を AWS Japan SA の田中豊洋が翻訳しました。

本記事は、2024年4月30日に投稿された Amazon Q Business and Amazon Q in QuickSight empowers employees to be more data-driven and make better, faster decisions using company knowledge を翻訳したものです。 2024年4月30日、 Amazon Q の一般提供を発表しました 。Amazon Q は、ソフトウェア開発を加速し、企業の内部データを活用するための最も優れた生成 AI 搭載アシスタントです。AWS の Data and Machine Learning の バイスプレジデント である Swami Sivasubramanian は「プレビュー期間中、Amazon Q を用いて顧客企業の従業員の生産性が 80 % 以上向上する可能性があるという初期兆候が見られ、今後導入を予定している新機能によって、これがさらに高まっていくと考えています」と述べました。どの組織でも従業員は、週に数時間を内部情報の検索に費やしています。また、分析の集約、レポート作成、プレゼンテーション作成、ダッシュボードからの洞察の作成と検索、さまざまな顧客や対象者向けのコンテンツ作成にも時間を費やしています。Amazon Q Business と Amazon Q in QuickSight は、これらの作業をより効率化するために開発しました。 Amazon Q Business は、生成 AI が搭載されたアシスタントであり、質問の回答、文章の要約、コンテンツの生成が可能で、組織内のシステムに保存されているデータや情報を元にセキュアにタスクが完了できます。これにより、従業員がより創造的で、データ駆動型で、効率的で、生産性が高くなります。 Amazon Q Business は他のどの生成AIアシスタントよりも多くのデータソースと統合可能 Amazon Q Business は、Wiki、社内イントラネット、Atlassian、Gmail、Microsoft Exchange、Salesforce、ServiceNow、Slack、Amazon Simple Storage Service ( Amazon S3 ) など、40 以上の一般的に使用されているビジネスツールに簡単かつ安全に接続でき、これは、他のどの生成 AI アシスタントよりも多い値です。企業のデータリポジトリを Q に接続するだけで、すべてのデータを検索し、論理的に要約、トレンドを分析し、エンドユーザーとデータに関して対話することができます。これにより、ビジネスユーザーは、組織内のどこにあるデータでも、すべてのデータにアクセスすることができます。Web ベースのインターフェイスを用いた Amazon Q Business のユースケースをご覧ください。 セキュリティとプライバシーを第一に考えて設計 Amazon Q Business は、設計時からセキュリティとプライバシーを考慮して構築されています。既存の ID、ロール、アクセス許可とシームレスに統合し、高レベルのセキュリティを維持しながら、個々のユーザーとのやり取りをパーソナライズできます。企業の情報に基づいて正確な回答を生成し、機密トピックを制限し、キーワードをブロックし、不適切なコンテンツを除外できます。また、顧客のコンテンツを、他の顧客のためのモデルの訓練に使用することはありません。Amazon Q Business のセットアップと管理方法を学びたい場合は、 News Blog: Amazon Q Business をご覧ください。 生成 BI によって、アナリストやビジネスユーザーが数分で詳細なダッシュボードを作成可能に Amazon QuickSight は、AWS のクラウド向け統合ビジネスインテリジェンス (BI) サービスです。 Amazon Q in QuickSight により、ビジネスアナリストは自然言語を使用して数分で BI ダッシュボードを作成し、可視化や複雑な計算が容易に行えます。ビジネスユーザーが、ダッシュボードで表示しきれていないデータについて質問をしても、即座に回答を得られる唯一の BI プロダクトであり、主要な洞察、傾向、要因を強調した詳細でカスタマイズ可能なデータストーリーも作成できます。ビジネスユーザーは、「 build a story about how the business has changed over the last month for a business review with leadership (経営陣との会議で、過去 1 か月間の事業の変化についてストーリーを作成して) 」と質問すると、Amazon Q は多角的な視点からデータストーリーを数秒で作成し、事業改善の方法といった具体的なアイデアを織り交ぜながら、具体的な洞察や視覚的な情報を補完し、様々な側面からデータを説明してくれます。ユーザーはレイアウトを変更することができ、テキストや画像、テーマをカスタマイズしてドキュメントやプレゼンテーションを簡単に共有することができ、Amazon Q を用いてテキストを書き直したり、改善することも可能です。Amazon QuickSight の最新機能については AWS Business Intelligence Blog を、自社データに基づくコンテンツ作成と共有については Unlock the power of Generative BI with Amazon Q in QuickSight をご覧ください。 会話から数秒で生成 AI 駆動のアプリを作れるよう支援する、画期的な機能 2024年4月30日、従業員が自社のデータを利用して、コーディング経験がなくても生成 AI アプリケーションを簡単かつ迅速に作成できるAmazon Q Business の新機能 Amazon Q Apps (プレビュー) を発表しました。Amazon Q Apps では、従業員は自然言語で自分が欲しいアプリを記述するか、Amazon Q Business によって問題の解決に至った既存の会話を利用し、Amazon Q が 1 クリックで、希望のタスクを達成するアプリを即座に生成します。そして、そのアプリは組織内で簡単に共有可能です。 例えば、新入社員向けのオンボーディングプランを立てるのは、長くて手間のかかる業務です。新入社員の役割に応じた適切なコンテンツを見つけるため、さまざまなデータストアやドキュメントを探し求める必要があり、多くの時間を要します。そして、それらコンテンツも、陳腐化していたり、役割に十分に合致していなかったりします。Amazon Q を使えば、人事担当者は新入社員の名前と社員 ID を入力するだけで、その社員向けのオンボーディング計画を自動で作成するアプリを簡単に作ることができます。わずか数秒で、Amazon Q Apps は最新のデータを使用して、その社員の役割や部署に合わせたパーソナライズされたオンボーディング計画を自動生成するアプリを構築します。そして、人事担当者はそのアプリを会社の採用担当者と共有し、自チームに合わせたオンボーディングプランを即座に構築できるようになります。このように、Amazon Q Apps を使えば、ビジネスユーザーが簡単に、迅速にかつセキュリティを確保しつつ、企業の情報をベースにアプリを構築し、生産性を向上できます。 Introducing Amazon Q Apps の動画を見れば、導入が簡単であることをお分かりいただけるでしょう。 Smartsheet の企業開発・戦略担当シニアバイスプレジデントである Bani Bedi は次のように述べました。 “Amazon Q Business は、Smartsheet におけるナレッジ管理を効率化し、従業員の生産性を高めています。以前は、3,300 人の従業員が必要な情報を公開されているヘルプドキュメント、トレーニングコース、数百の全従業員向け Slack ヘルプチャネルから探すのが非常に難しい状況でした。私たちは組織ナレッジを一つの AI エンジンに統合し、従業員に即座に回答を提供することで、従業員の生産性を大幅に向上させています。” 詳しくは、 AWS Fireside Chat with Smartsheet のインタビューをご覧ください。 Amazon Q Business と Amazon Q in QuickSight について案内できることを大変うれしく思っています。AWS における生成 AI に関する詳しい情報は、 AWS Generative AI をご覧ください。 著者について Mukesh Karki は Amazon Q Business の General Manager です。 Tracy Daugherty は Amazon Quicksight の General Manager です。

1. はじめに 製造業における品質管理は非常に重要な課題です。製品の外観や組立状態を確認し、欠陥の有無を判断する外観検査工程は、高い品質を維持するうえで欠かせません。この検査工程を人手に頼らず自動化できれば、コスト削減と品質の安定化が期待できるため、さまざまな検査工程の自動化が試みられています。今でも外観検査のソリューションとしてAWSではAmazon Lookout for Visionというサービスを提供していますが、今回は違う切り口から、Amazon Titan Multimodal Embeddings G1を使って生成AIで同じような外観検査ができるかトライしてみました。 Embedding方式の利点は、製品カテゴリーを問わず同じ数値化モデルを活用できる点にあります。サンプル画像の数値化自体は製品に依存しないので、一度、数値化の仕組みを構築すれば、様々な製品に汎用的に適用可能となります。こうした柔軟性と効率性が、Amazon Lookout for Visionとは異なる特長となっています。また、このような汎用化により、AWSサービスに比べてコストを抑えられる可能性があります。さらに、既に外観検査モデルを持っている場合には、Embeddingを使ってモデルの改良を容易に行えるというメリットがあります。Embedding方式とLookout for Visionはそれぞれ長所があり、用途に応じた使い分けが重要です。 2. 検査画像について 今回は外観検査のサンプルとして、下記のような ガラス瓶の口の部分を極端にクローズアップして撮影したものを使ってみたいと思います。下記のように良品であれば、透明なガラス瓶の中心部を同心円状の輪郭が取り囲んでいるような形状になります。 一方で不良品の画像は、下記のようにビンの淵に汚れがある場合や（よく見ないとわかりづらいですが今回は透明なテープを貼っています）、ビンの中に何かが混入してしまっていたりといった、いくつかパターンを用意してみました。 3. 判定ロジックの作成 3-1 学習データの準備 冒頭でも記載しましたが、今回は生成AIに2023年の11月にAmazon Bedrockで一般提供開始となったAmazon Titan Multimodal Embeddings G1モデルを利用します。 手順としてはシンプルで、まず初めにAmazon Titan Multimodal Embeddings G1を使って良品画像からEmbeddingを取得します。Embeddingとは、画像データをベクトル表現＝数値化することを指していて、画像の視覚的な特徴が圧縮されてベクトル化されます。今回は、画像を数値化するのにAmazon Titan Multimodal Embeddings G1を使って、分類自体はk近傍法(k-Nearest Neighbors)という別の手法を用います。 画像のembeddingは同じカテゴリーの画像は近いベクトル値になり、異なるカテゴリーの画像は離れたベクトル値になる性質があります。分類に利用する、k近傍法(k-Nearest Neighbors)は、 未知のデータ点に対して学習データ中の最近傍k個のデータ点の多数決により分類を行います。今回は良品画像・不良品画像のそれぞれのクラスを作成し、当該クラス分類に近いかどうかで良品・不良品を判定します。 Embeddingによって同じカテゴリーの画像が近接するよう写像されていれば、k近傍法による良品/不良品の判別が有効に機能すると期待できます。 さらに、この手法の利点は、モデル作成のハードルと、計算コストが比較的低いうえ、小規模データでも高速に判定できるところにあります。一方で大規模データでは計算コストが高くなる懸念がありますが、他の手法と柔軟に連携しやすいという点もあり、状況に合わせて最適な手法を組み合わせられることで、 より高い判別性能を発揮できます。 それでは、実際にAmazon Titan Multimodal Embeddingsを使って画像のEmbeddingを取得していきます。コードの一部を抜粋するとこのようになります。 出力のベクトルサイズは1,024 (デフォルト)、384、256から選択できますが、今回はより低次元の256次元にしてみました。 for i in range(start_num, end_num+1): file_path = os.path.join(f'{file_prefix}{i}.jpg') with open(file_path, "rb") as image_file: input_image = base64.b64encode(image_file.read()).decode("utf8") body = json.dumps( {"inputText": "xxx", "inputImage": input_image, "embeddingConfig": { "outputEmbeddingLength": 256 } }) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-embed-image-v1", accept="application/json", contentType="application/json", ) response_body = json.loads(response.get("body").read()) embedding = response_body.get("embedding") embedding_list_normal.append(embedding) こちらを実行すると、このような下記の画像1枚につき、このようなベクトル表現を特徴量として得ることができます。 最初の検証では、良品画像のみ40枚分, 不良品画像40枚、合計80枚分繰り返します。 [0.040440526, -0.030406332, 0.019856136, -0.03709767, -0.027063366, 0.0038649105,　-0.02639588, -0.014976015, 0.010845318, -0.041676126, -0.00282769, -0.0050448384, （中略） 0.05363304, -0.0126655055, -0.054597393, 0.0004961308, -0.04483083, 0.013465457,0.025360549, -0.0052477336, 0.057870768, 0.045011103, -0.013245691, -0.076108955, -0.025926728, 0.0072124046, -0.13566567, -0.016753113] 3-2 モデルの作成 次にk近傍法(k-Nearest Neighbors)を使って良品画像と不良品画像の学習モデルを作っていきます。コードはこのようになります。embedding_listには、先ほど出力した良品画像＋不良品画像の合計80枚の画像のEmmbedingのリストが入っており、Yには正解ラベルのリストになります。 X= np.array(embedding_list) knn = KNeighborsClassifier(n_neighbors=3) knn.fit(X, Y) なお、この合計80枚の画像から抽出されたEmbeddingが、うまくクラス分類できているのかt-SNEという手法を使って256次元を2次元まで削減しグラフにプロットしてみたいとおもいます。 t-SNEは高次元データを低次元に視覚化する手法で、緑色の点が良品を赤色の点が不良品を表しています。グラフを見ると、概して良品と不良品がある程度分離されている傾向が見られます。 この傾向を見ても今回のサンプル画像を使ったEmbeddingによるクラス分類は、ある程度うまくいきそうだということが視覚的にもわかると思います。このようにして、良品画像および不良品画像のクラス分類が完成しました。 4. テストデータの準備 それでは、テスト画像を40枚ほど用意します。このテスト画像には、良品と不良品の画像が混ざった形で入っています。 今回は20枚の画像は良品、もう20枚は不良品という構成にしてみました。不良品の画像のパターンは小さな欠けから、大きな損傷、異物の混入など複数のパターンを用意します。 この合計40枚のテスト画像のEmbeddingを先ほどの手順で出力しておきます。 ■良品画像の例 ■不良品画像の例 それでは、先ほど訓練した良品画像の学習データとの距離を計算していきます。コードはこのようになり、良品画像のクラスに対して距離が近ければ近いほど＝良品画像と近い特徴を持ち、その逆は＝不良品画像の特徴を持ちます。 X_new = np.array([i]) #テスト画像 y_pred = knn.predict(X_new)　#良品・不良品判定 5. 検証結果 これらの40枚のテスト画像に対して、以下のような結果が出ました。 良品→不良品と判定したケースは4件ありました。 それぞれ、Accuracy（正解率）：90％、Precision（適合率）：100％、Recall（再現率）：80％、F値：0.889となっています。 正解率とは、全体に対する正しい判定の割合です。 適合率(Precision)が100%ということは、良品と判定されたものは全て実際の良品だったことを意味します。 一方で、再現率(Recall)が80%ということは、実際の良品の80%が良品と判定できていたことになります。なお、F値という指標があります。これは0から1の値をとり、1に近いほど識別がうまくできていることを示します。 実際の製造現場では、製品の安全性と品質を最優先し、偽陰性(不良品を良品と誤判定)を防ぐことが重視されます。今回のモデルでは、ある程度の偽陽性はありましたが、不良品は100％判定でき製品の安全性と品質を守る観点では良好な結果だと言えます。 また、今回はある程度の精度が出ましたが、実際に良好な結果が得られない場合は、学習データの質や量を変えてみることで、さらなる精度向上が図れる可能性があるかもしれません。今回のケースでも学習データを半分の40枚に減らして、不良品としてパターンの多い画像を増やしたところ、正解率が95%まで向上しました。他にも、信頼度を見て評価用データから閾値を決めて、良品と不良品の境界をより詳細に設定していく方法も考えられます。 なお、冒頭に記載したように今回のプログラムを使って今回の仕組みを汎用化できるか、他のデータセットを使って検証してみたところ、環境や条件にもよりますが正解率が95％となり高い精度が出すことができました。 まとめ 今回、Amazon Titan Multimodal Embeddingsを活用した簡易的な外観検査を実施してみました。今回作成したモデルは、ある程度の偽陽性はありましたが、不良品は100％判定でき製品の安全性と品質を守る観点では良好な結果が得られたのではないかと思います。 本手法のポイントは、画像をAmazon Titan Multimodal Embeddings G1を利用してEmbeddingして数値化したことです。これにより、画像のタスクを数値データのアルゴリズムに落とし込むことができるようになりました。画像を数値化することで、これまでのさまざまな機械学習の手法を活用した分類が可能になります。 ただし、この方法は、今回のケースような固定された既知のサンプルに対しては比較的高い精度が期待できますが、環境条件や撮影状況が常に変化する場合には精度が低下する可能性があります。すべてのケースに万能に適用できるわけではなく、実運用時には検査対象物や環境の違いによって、結果がある程度異なる可能性があることに留意が必要です。 さらに、今回は不良品画像が十分にあるケースを考えてみましたが、必ずしも不良品画像が十分にない場合もあると思います。 その際には、生成AIに不良品かどうか直接質問したり、不足するデータを人工的に生成してモデル学習をするといったアプローチも検討できるかもしれません。このように、生成AIによる外観検査の実用化に向けては、様々な工夫の余地が残されています。本試行が、その第一歩として、生成AIの活用可能性を示す有意義な機会となれば幸いです。 著者について 秦 将之 アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 製造業界のお客様向けに技術支援を担当しています。好きなサービスはAmazon SageMakerとAmazon Bedrockです。週末はジムで体力づくりしています。

はじめに Anthropic が 2024年 3月に Claude3 を発表 し、4月には Meta が Llama3 を発表 するなど、生成 AI の進化は止まるところを知りません。一方、生成 AI の進化を支える大規模言語モデルの開発及び運用に掛かるコスト、計算機リソースの確保は多くの企業が抱える大きな課題です。AWS では機械学習 (ML) アクセラレーターチップ AWS Trainium 、 AWS Inferentia2 を自社開発し、これらの課題解決に取り組んでいます。（ Anthropic では AWS Trainium、Inferentia の活用を表明しています ） 本ブログでは、前半で、AWS Trainium 搭載 Amazon EC2 Trn1 インスタンス を活用した日本語大規模言語モデルの開発事例、大規模分散学習の課題及び実現方法について解説します。 ブログ後半では、公開された日本語大規模モデルを Inferentia2 搭載 Amazon EC2 Inf2 インスタンス 上で推論実行する方法について、手順を追って解説します。１時間以内で完走できる内容ですので、公開された各種モデルの検証、活用に興味をお持ちの方は後半から読み進めて頂いても結構です。 AWS 自社設計 ML アクセラレーター搭載インスタンス 本章では、ブログの本題に入る前に、AWS が提供している生成 AI / ML モデルのトレーニング及び推論向けインスタンスについて紹介します。 AWS では、生成 AI / ML モデルのトレーニング向けのインスタンスとして、業界で広く利用されている NVIDIA 社 A100 Tensor Core GPU を搭載した Amazon EC2 P4d インスタンス 、最新 H100 GPU を搭載した P5 インスタンス を提供しています。2024年 4月には L4 GPU を搭載した 推論向け G6 インスタンス の一般提供を開始しました。 一方、AWS は、クラウド向けに最適化されたカスタムシリコンの設計に何年も投資しており、お客様の幅広いワークロードにおいて、自社設計チップファミリー AWS Graviton プロセッサ、AWS Trainium、Inferentia 機械学習アクセラレーターが活用されています。2023年 11月には年次イベント AWS re:Invent において、それぞれの次世代版となる AWS Graviton4 プロセッサと AWS Trainium2 アクセラレーターを発表 しました。 AWS Trainium 搭載 Amazon EC2 Inf2 インスタンス Amazon EC2 Trn1 インスタンスは、生成 AI / ML モデルのトレーニング向けに開発した AWS Trainium アクセラレーターを搭載したインスタンスです。 他の同等の ML トレーニング向けインスタンスと比較し、コストを最大 50% 削減します。Trn1 インスタンスでは、小規模モデルのトレーニングを想定して Trainium を１つ搭載した trn1.2xlarge と、大規模モデルの分散学習を想定して Trainium を 16個搭載した trn1.32xlarge の２つのサイズを用意しています。また Trn1 インスタンスと比較してネットワーク帯域を 2 倍にし、1600 Gbps の Elastic Fabric Adapter (EFAv2) に対応した trn1n.32xlarge インスタンスも提供しています。 インスタンスサイズ  Trainium アクセラレーターメモリ (GiB)  vCPU インスタンスメモリ (GiB) ローカル NVMe ストレージ (TB) NW帯域 (Gbps) EBS帯域 (Gbps) trn1.2xlarge 1 32 8 32 0.5 最大 12.5 最大 20 trn1.32xlarge 16 512 128 512 8 800 80 trn1n.32xlarge 16 512 128 512 8 1600 80 Trn1 インスタンス及び Trainium アクセラレーターの概要及び、小規模モデルのトレーニング（ファインチューニング）については、「Trn1 独自設計チップ AWS Trainium 搭載 Amazon EC2 Trn1 インスタンスで ML トレーニングを高速実行（ 基礎編 、 実践編 ）」をご参照下さい。 AWS Inferentia2 搭載 Amazon EC2 Inf2 インスタンス Amazon EC2 Inf2 インスタンスは、初代 Inf1 インスタンスと比較し、最大 3 倍のコンピューティング性能、最大 4 倍のアクセラレーターメモリ、最大 4 倍のスループット、10 分の 1 以下の低レイテンシーを実現します。 AWS Inferentia2 には Trainium と同じ世代となる Neuron コア v2 を搭載しており、大規模モデルの推論だけでなく、小規模モデルのファインチューニングも実行可能です。Inf2 インスタンスは既に東京リージョンでもローンチ済みなので、学習モデルを国内に保持しておきたい場合や、ネットワークレイテンシーを最小化したい場合には、東京リージョンにてデプロイ可能です。 インスタンスサイズ  Inferentia2 アクセラレーターメモリ (GiB)  vCPU インスタンスメモリ (GiB) ローカルストレージ NW帯域 (Gbps) EBS帯域 (Gbps) inf2.xlarge 1 32 4 16 EBS のみ 最大 15 最大 10 inf2.8xlarge 1 32 32 128 EBS のみ 最大 25 最大 10 inf2.24xlarge 6 192 96 384 EBS のみ 50 30 inf2.48xlarge 12 384 192 768 EBS のみ 100 60 AWS Trainium を活用した大規模言語モデルの分散学習 アマゾン ウェブ サービス ジャパンは 2023年 7月、国内に法人または拠点を持つ企業・団体の生成 AI 基盤モデル・大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を立ち上げました。本プログラムに採択された17 社の採択企業の多く（11社）では、AWS Trainium を活用し、短期間で日本語大規模言語モデルの開発を完了しました。ストックマーク株式会社、カラクリ株式会社、株式会社わたしは、 rinna株式会社ではプログラムを通して開発したモデルを Hugging Face Hub 上で公開 しており、広くご活用頂けるようになっています。中でも stockmark-13b 、 karakuri-lm-70b-chat-v0.1 は 2000 回 以上ダウンロードされた人気の日本語モデルとなっています。 AWS LLM 開発支援プログラムの総括については「 基盤モデル開発に挑む各社が成果を共有。AWS LLM 開発支援プログラム 成果発表会 」をご参照下さい。 大規模言語モデルの分散学習は、アクセラレーターチップ、インスタンスといった計算機リソースだけでは実現できません。効率的に実行するためには、分散学習ライブラリ、クラスタ管理フレームワーク、 Amazon FSx for Lustre 共有ファイルシステムなど、複数のサービスを組み合わせることが不可欠です。 本章では、はじめに Trainium 上で分散学習を実行する上で鍵となる分散学習ライブラリについて、サンプルスクリプトとともに解説します。続いて、AWS が提供するクラスタ管理フレームワークの選択肢と、大規模分散学習では避けられないノード障害に対する対策について解説していきます。 分散学習ライブラリ AWS Neuron は Trainium、Inferentia 上での機械学習ワークロードを最適化するための SDK です。PyTorch を用いた大規模言語モデルの分散学習では、AWS Neuron 上で実行する分散トレーニングライブラリ、 AWS Neuron Reference for NeMo Megatron 及び NeuronX Distributed を提供しています。その際、AWS Neuron では、 PyTorch XLA をバックエンドのコンパイラとして利用しています。 AWS Neuron Reference for NeMo Megatron AWS Neuron Reference for NeMo Megatron（以下、neuronx-nemo-megatron） は、既存のオープンソースパッケージ Nemo と Apex を AWS EC2 Trn1 インスタンスおよび AWS Neuron に対応させたライブラリです。いち早く Llama2 モデルの事前学習に対応したこともあり、2023年 8月と 9月に AWS LLM 開発支援プログラム採択企業向けに実施した Prototyping Camp では、neuronx-nemo-megatron と AWS ParallelCluster を使用し、Llama2 モデルのマルチノード分散学習環境の構築から推論実行までの一連の流れを完走しました。実際、採択企業の多くで neuronx-nemo-megatron を利用した大規模言語モデルの分散学習を実施しています。Llama2-7B、13B、70B それぞれのモデルの継続事前学習を実行する チュートリアル を用意しているため、大規模言語モデルの分散学習で必要となる環境構築の負荷を大幅に削減することが可能です。 NeuronX Distributed NeuronX Distributed は、Neuron デバイス上で分散学習、分散推論を実行するための XLA ベースのライブラリです。モデルの大規模化に伴い、モデルを単一デバイス上でトレーニングすることは不可能になるので、シャーディング技術を利用してモデルを複数のデバイスに分割する必要があります。NeuronX Distributed では、 テンソル並列 、 パイプライン並列 、データ並列からなる 3D Parallelism と ZeRO-1  を使った Optimizer の重みのシャーディングに対応しています。また、アクティベーションメモリを削減するための シーケンス並列 と、フォワードパスでアクティベーションの一部を保存せずバックワードパス中に再計算する事でメモリの使用量を削減する アクティベーション再計算（selective activation checkpointing） にも対応しています。 以下は Llama2-70B モデルの事前学習を実行するサンプルスクリプト の一部です。こちらのサンプルスクリプトでは、 trn1.32xlarge インスタンス上の合計 32 個の Neuron コア全てをテンソル並列で利用し、４つのインスタンスでパイプライン並列を、残り（16ノードでの分散学習の場合は 32 x 16 / 32 / 4 = 4）をデータ並列として利用しています。さらに ZeRO-1、シーケンス並列（以下のスクリプト内では設定していないがデフォルトで利用）、アクティベーション再計算を利用しています。Llama2-13B/70B モデルでの事前学習を実行する チュートリアル を合わせてご参照下さい。 # Global batch size : ${GBS:=1024} # Input sequence length SEQ_LEN=4096 # Pipeline parallel degree PP_DEGREE=4 # Tensor parallel degree TP_DEGREE=32 # Data paralell size DP=$(($PROCESSES_PER_NODE * $WORLD_SIZE / $TP_DEGREE / $PP_DEGREE)) # Batch size per model replica BS=$(($GBS / $DP)) # Number microbatches for pipeline execution # Setting same as BS so each microbatch contains a single datasample NUM_MICROBATCHES=$BS . . torchrun $DISTRIBUTED_ARGS run_llama_nxd.py \ --train_batch_size $BS \ --use_meta_device_init 1 \ --training_dir $DATA_PATH \ --training_config $SCRIPT_DIR/70B_config \ --max_steps $max_steps \ --seq_len $SEQ_LEN \ --pipeline_parallel_size $PP_DEGREE \ --tensor_parallel_size $TP_DEGREE \ --num_microbatches $NUM_MICROBATCHES \ --lr 0.00015 \ --min_lr 1e-05 \ --beta1 0.9 \ --beta2 0.95 \ --weight_decay 0.1 \ --warmup_steps 2000 \ --constant_steps 0 \ --use_zero1_optimizer 1 \ --use_selective_checkpoint 1 \ --qkv_linear 1 \ --kv_replicator 4 \ --tb_dir $tb_dir |& tee $LOG_PATH/log クラスタ管理フレームワーク 採択企業の多くでは Prototyping Camp で体験頂いた AWS ParallelCluster を使って、マルチノードでの分散学習環境を構築頂きました。AWS では他にも様々な選択肢を用意しています。2023年 11月、AWS re:Invent では大規模な分散学習に特化したマネージドサービス Amazon SageMaker HyperPod を発表、ローンチしています。HyperPod については「 大規模な分散トレーニングに特化したインフラストラクチャ、Amazon SageMaker HyperPod のご紹介 」をご参照下さい。 また、 Amazon Elastic Kubernetes Service (Amazon EKS) を用いた分散学習については「 Train Llama2 with AWS Trainium on Amazon EKS 」を、Amazon SageMaker を用いた分散学習については「 Simple guide to training Llama 2 with AWS Trainium on Amazon SageMaker 」をそれぞれ合わせてご参照下さい。 耐障害性 (resiliency) に対するアプローチ 分散学習を実施する際のノード数は、学習するモデルのパラメータサイズ、学習データのサイズ（トークン数）、学習を実施する期間や計算機リソースの確保の容易性など、様々な要素から決定されます。ノード数の規模が大きくなると、ノード障害の発生を想定した耐障害性、リカバリー機能の確保は Trn1 インスタンスに限らず、一般的に発生する切実な問題です。今回、株式会社リコー様では、64 インスタンスの trn1.32xlarge (1,024 Trainium アクセラレーター、2,048 Neuron コア) を用いた大規模分散学習を実施頂きました。ノード障害を自動的に検知し、必要に応じて正常なノードとノード交換を実施、その後、学習ジョブを直近で保存された最新のチェックポイントから自動再開する仕組みを分散学習ライブラリ上に実装することによって、大規模クラスタでの学習を成功裏に導きました。これらの実装は最新版 neuronx-nemo-megatron、NeuronX Distributed ライブラリ内に既に組み込まれています。 AWS Inferentia2 上で日本語大規模言語モデルの推論環境を構築 AWS LLM 開発支援プログラムの支援を受けて、AWS Trainium 上で開発されたモデルのいくつかは、 Hugging Face Hub 上で公開 されています。Trainium 上で学習したモデルのデプロイ先に制限はありません。AWS Inferentia2 を搭載した Amazon EC2 Inf2 インスタンス、GPU インスタンスのどちらでも推論実行が可能です。また、GPU 上で学習されたモデルを Inf2 インスタンス上にデプロイすることも可能です。 本章では、Inferentia2 上で大規模言語モデルの分散推論を実現するための分散推論ライブラリについて解説した後、公開された日本語大規模言語モデルを Inferentia2 上にデプロイする方法を解説します。また、本章の最後では本番環境への導入に向けた次のステップを紹介します。 分散推論ライブラリ Transformers NeuronX 大規模言語モデルの分散推論（自己回帰サンプリングによるテキスト生成）では、AWS Inferentia2 及び Trainium に最適化した Transformers NeuronX ライブラリを提供しています。小規模なモデルであればモデルを単一デバイス上にデプロイすることが可能ですが、大規模言語モデルの場合には、分散学習時と同様にテンソル並列を用いて、モデルを複数の Neuron コア間に分割して実装します。 最大サイズの inf2.48xlarge には、12 Inferentia2 アクセラレーター、24 Neuron コアが搭載されています。より高い性能（低レイテンシー）が求められる場合は、並列度を最大限上げる事が求められるので、テンソル並列度を 24 で実装することが推奨されます（さらに性能を求める場合には trn1.32xlarge をテンソル並列度 32 で利用することも可能）。一方、運用コストを重視する場合には、アクセラレーターメモリの容量を超えない限りの少ないテンソル並列度にする必要があります。70億、130億パラメータのモデルであれば、単一の Inferentia2 上にテンソル並列度 2 で、700億パラメータのモデルであれば、 inf2.24xlarge もしくは inf2.48xlarge 上に並列度 8 で実装可能です。 事前準備 70億、130億パラメータのモデルであれば、32GBのアクセラレーターメモリを持つ単一の Inferentia2 アクセラレーター上にデプロイ可能です。ここでは inf2.8xlarge インスタンスを起動し、130億パラメータのモデルを実際に活用してみましょう。EC2 の立ち上げ方については こちらのドキュメント をご参照下さい。本ブログ内の検証は、東京リージョン ( ap-northeast-1 ) で、以下の Deep Learning AMI Neuron (Ubuntu 22.04) AMI を利用し実施しました。また大規模モデルを扱う場合はストレージ容量に注意が必要です。ここでは EBS 512GBを用意しました。 インスタンスを起動後、SSH で接続します。モデルの推論を実行する際に Jupyter Notebook を使用しますので、SSH ポートフォワーディングを設定しておきましょう。 ssh -i "<pem file>" ubuntu@<instance DNS name> -L 8888:127.0.0.1:8888 インスタンスに接続すると、以下のような画面が表示されます。2024年 5月 10日現在、最新となる Neuron 2.18.2 がプリインストールされていることが分かります。 Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-1031-aws x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro ============================================================================= __| __|_ ) _| ( / Deep Learning AMI Neuron 2.18.2 (Ubuntu 22.04) ___|\___|___| ============================================================================= * Supported EC2 instances: Inf1, Inf2, Trn1, Trn1n. * To activate pre-built pytorch-1.13 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_pytorch_1_13/bin/activate' * To activate pre-built pytorch-1.13 environment for Inf1, run: 'source /opt/aws_neuron_venv_pytorch_1_13_inf1/bin/activate' * To activate pre-built pytorch-2.1 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_pytorch_2_1/bin/activate' * To activate pre-built transformers environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_transformers_neuronx/bin/activate' * To activate pre-built tensorflow-2.10 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_tensorflow_2_10/bin/activate' * To activate pre-built tensorflow-2.10 environment for Inf1, run: 'source /opt/aws_neuron_venv_tensorflow_2_10_inf1/bin/activate' * Neuron driver version:: 2.16.7.0 Neuron は定期的にアップデートされ、新しい機能の追加、対応するモデルの拡充、性能向上、バグフィックスなどが提供されます。それでは、次のコマンドを実行して仮想環境をアクティブ化しましょう。 source /opt/aws_neuronx_venv_transformers_neuronx/bin/activate ここで、最新の PyTorch Neuron 環境が正しくインストールできているかどうか確認しておきましょう。 Neuron ドキュメント上 で各パッケージの最新バージョンが確認可能です。 (aws_neuronx_venv_transformers_neuronx) ubuntu@ip-xx-xx-xx-xxx:~$ pip list | grep neuron aws-neuronx-runtime-discovery 2.9 libneuronxla 2.0.965 neuronx-cc 2.13.72.0+78a426937 torch-neuronx 2.1.2.2.1.0 transformers-neuronx 0.10.0.360 (aws_neuronx_venv_transformers_neuronx) ubuntu@ip-xx-xx-xx-xxx:~$ dpkg -l | grep neuron hi aws-neuronx-collectives 2.20.22.0-c101c322e amd64 neuron_ccom built using CMake hi aws-neuronx-dkms 2.16.7.0 amd64 aws-neuronx driver in DKMS format. hi aws-neuronx-oci-hook 2.3.0.0 amd64 neuron_oci_hook built using CMake hi aws-neuronx-runtime-lib 2.20.22.0-1b3ca6425 amd64 neuron_runtime built using CMake hi aws-neuronx-tools 2.17.1.0 amd64 Neuron profile and debug tools 130 億パラメータモデルを用いた推論実行 それでは、株式会社わたしはが公開している大喜利言語モデル（ Watashiha-Llama-2-13B-Ogiri-sft ）を実行してみましょう。 Jupyter Notebook を起動し、以降のセルを実行していきます。 jupyter notebook 最初にモデルをダウンロードし、Neuron コア上で動作できるようにコンパイルを実行します。コンパイルする際には、バッチサイズとテンソル並列度を指定する必要があります。 inf2.8xlarge では Inferentia2 を 1 個（Neuronコアを 2 個）搭載しているので、ここでは tp_degree=2 と設定しています。 from transformers_neuronx import NeuronAutoModelForCausalLM from transformers import AutoTokenizer model_path = "watashiha/Watashiha-Llama-2-13B-Ogiri-sft" neuron_model = NeuronAutoModelForCausalLM.from_pretrained( model_path, batch_size=1, tp_degree=2, amp='bf16' ) neuron_model.to_neuron() Watashiha-Llama-2-13B-Ogiri-sft は、大喜利データでファインチューニングされたモデルです。指定のフォーマットでプロンプトを用意しましょう。 prompt = """ 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 入力の文は大喜利のお題です。お題に沿った面白いボケを生成してください。 ### 入力: マジシャンのショーでアシスタントが消えたまま戻ってこない時の一言。 ### 応答: """ tokenizer = AutoTokenizer.from_pretrained("watashiha/Watashiha-Llama-2-13B-Ogiri-sft") input_ids = tokenizer.encode(prompt, return_tensors="pt") 最後に、推論を実行します。 generated_sequences = neuron_model.sample(input_ids, sequence_length=128, top_k=50) output = tokenizer.decode(generated_sequences[0], skip_special_tokens=True) print(output) 推論結果の例 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 入力の文は大喜利のお題です。お題に沿った面白いボケを生成してください。 ### 入力: マジシャンのショーでアシスタントが消えたまま戻ってこない時の一言。 ### 応答: 帰りの支度をしております。 面白いボケは生成されましたでしょうか？プロンプトを変更したり、繰り返し推論を実行しどのようなボケを生成できるか試してみましょう。 他にも、 CyberAgentLM2-7B (CALM2-7B) 、 Stockmark-13b 、 ELYZA-japanese-Llama-2-13b-fast など、Llama2 をベースとしたモデルであれば、Trainium で学習したモデルかGPUで学習したモデルかに関わらず、同様の手順で推論実行可能です。 ここではコンパイルを実行するため inf2.8xlarge を使用しましたが、あらかじめコンパイル済みのモデルを利用することで、推論処理自体はより安価な inf2.xlarge でも実行可能です。 700 億パラメータモデルを用いた推論実行 700 億パラメータのモデルを実行するためには、アクセラレーターメモリの制約上、複数の Inferentia2 によりテンソル並列度を上げて実行する必要があります。ここではカラクリ株式会社が公開している KARAKURI LM 70B Chat v0.1 を inf2.48xlage 上で実行してみましょう。必要な手順は先程の 130 億パラメータモデルの場合と同じです。 inf2.48xlage では Inferentia2 を12 個（Neuronコアを 24 個）搭載しているので、ここでは全ての Neuron コアを活用すべく、 tp_degree=24 と設定しています。 from transformers_neuronx import NeuronAutoModelForCausalLM from transformers import AutoTokenizer model_path = "karakuri-ai/karakuri-lm-70b-chat-v0.1" neuron_model = NeuronAutoModelForCausalLM.from_pretrained( model_path, batch_size=1, tp_degree=24, amp='bf16' ) neuron_model.to_neuron() 先程と同様に、モデルが期待するフォーマットに合わせてプロンプトを用意します。 prompt = """以下は人間とAIアシスタントとの会話です。 Human: こんにちは。 AI: こんにちは、私はAIアシスタントです。何かお手伝いできることはありますか？ Human: 週末に日帰りで東京に遊びに行こうと思っています。日帰りなので、短時間で回れるおすすめの観光プランを教えてください。 AI: """ tokenizer = AutoTokenizer.from_pretrained(model_path) input_ids = tokenizer.encode(prompt, return_tensors="pt") 推論実行についても、先程の 130 億パラメータモデルの例と同じです。700 億パラメータということで、より複雑なテキスト生成が実現できていることが分かります。 generated_sequences = neuron_model.sample(input_ids, sequence_length=512, top_k=50) output = tokenizer.decode(generated_sequences[0], skip_special_tokens=True) print(output) 推論結果の例 以下は人間とAIアシスタントとの会話です。 Human: こんにちは。 AI: こんにちは、私はAIアシスタントです。何かお手伝いできることはありますか？ Human: 週末に日帰りで東京に遊びに行こうと思っています。日帰りなので、短時間で回れるおすすめの観光プランを教えてください。 AI: 素晴らしいアイデアですね！東京には短時間で回れる多くの観光スポットがあります。たとえば、次のスポットをお勧めします： 皇居 - 東京の美しい庭園と巨大な城を眺めながら散策できます。 浅草寺 - 東京の最も有名な寺院の1つで、伝統的な日本の文化を体験できます。 東京タワー - 東京の街並みを見渡すことができるタワーで、東京タワーの周辺はショッピングや食事に最適です。 原宿&表参道 - ショッピング、ストリートアート、食べ物のための流行の発祥の地です。 明治神宮 - 東京の壮大な神社の1つで、静かで平和な雰囲気があります。 これらのスポットはいずれも都心周辺に位置し、短時間でアクセスできます。また、それぞれのスポットには、観光バス、電車、タクシー、レンタル自転車などを使用してアクセスできます。 同じ Llama2 ベースで 700億パラメータを持つ Swallow-70b-hf も同様に実行可能です。また、株式会社ELYZAでは日本語大規模言語モデル ELYZA-japanese-Llama-2-70b を体験可能なデモサイト を、Amazon EC2 Inf2 インスタンスを用いて運用しています。 本番環境への導入に向けて ここまで Amazon EC2 Inf2 インスタンス上で大規模言語モデルの推論（テキスト生成）を実行する手順について説明してきました。GPU インスタンス上での実行とさほど変わらない手順で実行可能なことがお分かり頂けたと思います。 Transformers NeuronX では、 重みの 8 ビット量子化に対応 しており、量子化する事で 700 億パラメータモデルを tp_degree=8 で実行する事が可能です。この場合、 inf2.48xlarge ではモデルのサービングを 3 ワーカーで、 trn1.32xlarge では 4 ワーカーで運用可能となり、よりコスト性能を重視した運用が可能になります。また、性能向上を求める際の機能として speculative sampling にも対応 しています。 ここでは、実際に本番環境でモデルのサービングを行う際に活用頂ける２つのサービスを紹介します。 Amazon SageMaker LMI コンテナ Amazon SageMaker では、モデルの並列処理と大規模モデル推論用の Large Model Inference (LMI) Containers を提供しています。AWS Inferentia2、Trainium用の LMI コンテナでは、内部に Neuron SDK、Transformers NeuronX ライブラリ、 DJLServing 高性能モデルサーバーを取り込み、SageMaker 上での本番環境での推論運用を実現しています。より詳細については 「 大規模モデル推論コンテナを使って AWS Inferentia2 に大規模言語モデルをデプロイ 」、「 Amazon SageMaker 上で AWS Inferentia2 と AWS Trainium を使って、低コストで高性能な生成系 AI 推論を実現 」をご参照下さい。 Hugging Face Text Generation Inference (TGI) Hugging Face社では、大規模言語モデルの本番推論ワークロードに利用可能な Text Generation Inference (TGI) を提供しています。TGI には最新の Transformers NeuronX ライブラリを搭載し、Trainium、Inferentia2 の高い性能、低いコストを維持したまま Transformers ライブラリを簡単に利用するためのインタフェースである Optimum Neuron と共に、Neuron デバイスに最適化したデプロイ環境を提供しています。「 Deploy Llama 2 70B on AWS Inferentia2 with Hugging Face Optimum 」も併せてご参照下さい。 まとめ 本ブログでは Llama2 ベースの日本語モデルについて取り上げましたが、他の新しいモデルにも順次対応しています。 Transformers NeuronX では、 Mistral-7B 、 MIxtral 8x7B にも対応しており、 Swallow-MS-7b-v0.1 、 Swallow-MX-8x7b-NVE-v0.1 、 karakuri-lm-8x7b-chat-v0.1 といった日本語モデルにも対応可能です。また、2024年 4月に発表された Llama3 8B 、 70B モデルにもいち早く対応し、Llama3 ベースの日本語モデル llama-3-youko-8b も Inferentia2 上で動作可能です。 モデルの対応状況については Neuron ドキュメント および AWS Neuron レポジトリ をご参照ください。また AWS Trainium、Inferentia2 を活用しモデルの開発、運用を行っている企業の活用事例は こちらのリポジトリ 上にまとめていますので合わせてご参照下さい。 本ブログが、AWS Trainium、Inferentia2 を活用して日本語大規模言語モデルを扱う際の道標となれば幸いです。 著者について 常世 大史 は、AWS Annapurna Labs のソリューションアーキテクトです。日本を拠点とし、AWS による買収以前から Annapurna Labs が提供する技術でお客様を支援してきました。ここ最近は、AWS Trainium、Inferentia の技術支援に注力しています。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの黒田です。 通信事業者の方々、通信業界に関わられている方々、5G やエッジコンピューティングなどの最新技術の動向にご興味のある方々を主な対象として、2024年4月18日に「テレコム業界向け：Mobile World Congress (MWC) 2024 Recap」をウェビナーで開催しました。 本記事では、当日の内容・動画を皆様にご紹介します。 ウェビナー開催の背景 2024年2月26日から2月29日までスペイン・バルセロナで開催されたテレコム業界最大のイベント Mobile Word Congress (MWC) 2024。AWS は現地にて、昨年に引き続き２回目のブース出展を行いました。通信事業者様やパートナー様と AWS の協業による数々の取り組みがデモンストレーション含め展示されました。今回のウェビナーでは、テレコム業界向けの AWS の取り組みとして、「通信事業者の変革」「産業のデジタル化」「消費者体験の再考」のテーマで、様々な事例をご紹介しました。 1. MWC 2024 における AWS 出展内容のハイライト AWS 技術統括本部　ストラテジックインダストリー技術本部　通信グループ 本部長　山内 晃 資料は こちら からダウンロード頂けます。 まず山内より、今回の出展内容のハイライトとして、MWC 2024 における AWS の取り組みについての概要説明をお届けしました。 今回の最大のトピックは、ちょうど MWC 2024 開幕日に合わせて発表した NTTドコモとのモバイルネットワーク構築に関する取り組みです(*)。こちらは、5G の無線アクセスネットワーク (Radio Access Network / RAN)、コアネットワーク、衛星通信の3要素で構成されています。 (*) 引用元: https://press.aboutamazon.com/aws/2024/2/ntt-docomo-selects-aws-to-deploy-nationwide-5g-open-radio-access-network https://aws.amazon.com/jp/about-aws/whats-new/2024/02/ntt-docomo-selects-aws-to-deploy-nationwide-5g-open-radio-access-network/ まず、5G RAN 領域では、モバイルの基地局を構成するコンポーネントを、Amazon EKS Anywhere というコンテナ基盤を使って日本全国に展開する取り組みが行われています。また基地局だけでなく 5G のコアネットワーク (端末の位置登録、認証、セッション管理などを司るコンポーネント) でも、その一部にオンプレミスとのハイブリッド構成で AWS を活用頂く為の開発も進んでいます。さらに、Amazon が開発中の低軌道衛星ブロードバンド Project Kuiper と提携し、基地局が建てづらい山や島といった地域のエリアカバレッジ向上や、被災地の通信復旧などの取り組みも検討しています。5G におけるモバイル通信そのものが、部分的に AWS 上で稼働するという非常にミッションクリティカルな領域での取り組みとなりますので、引き続きご注目頂ければと思います。 2. 通信事業者の変革 AWS 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信ソリューション第一部 ソリューションアーキテクト　黒田 由民 資料は こちら からダウンロード頂けます。 黒田からは、通信事業者の変革をテーマとして、通信事業者のチャレンジ、それらに対するクラウド化されたネットワークへの期待と、AWS がその期待に対し何を提供できるかについてお届けしました。 通信事業者様は、5G に必要不可欠なクラウドプラットフォームの自前構築による煩雑さ、ネットワーク運用の煩雑さ、それらに伴うコスト面での収益化への影響といった様々なチャレンジに直面しております。これらチャレンジに対し、RAN、コアネットワーク、IP Multimedia Subsystem (IMS)、Operations Support System (OSS) /Business Support System (BSS) の各領域の観点から、(1) 5G ネットワークを構築する手法としてのネットワーククラウド化への期待と、(2) これら期待に応える AWS が提供する価値を、MWC 2024 で展示/デモンストレーションされた、AWS が通信事業者様及びパートナー様と協業したソリューション内容を踏まえてご紹介しました。 以下に各領域毎の概要をまとめました。 【RAN】 ネットワークをクラウド化することにより、クラウドからエッジまでの連続性、市場投入時間の短縮、品質運用の高度化、等が期待されています。これらに対する AWS の提供する価値としては、Nokia と協業したソリューション内容を具体例に挙げると、AWS Outposts を活用した RAN アプリのクラウド / エッジでの適材適所の配置、パートナーソリューションの事前インテグレーションによる市場投入の加速、そして生成AI と機械学習を活用し自然言語チャットボットを使った RAN NW 診断とKPI 異常検知が挙げられます。 【コアネットワーク】 コアネットワークは信号やパケットが集約される 5G ネットワークの中枢の為、突発的なリソース調整や、作業ミス影響範囲減少を目的とした人的介入の最小化などがネットワークのクラウド化として期待されます。また違った観点にはなりますが、国際ローミング向けの NW 機能の容易な海外展開も期待されています。これらに対する AWS の提供する価値としては、(1) LG U+ と協業したソリューション内容からは、時系列予測と機械学習をそれぞれ使ったトラフィックの予測と異常検知から、パイプラインを介しトラフィックスコアに応じて、自動的かつ柔軟にリソースを増減できる仕組みが挙げられます。また、(2) SK Telecom との協業からは、国際ローミングユーザーの訪問先近くの AWS リージョンに User Plane Function (UPF) を配置しユーザートラフィックをローカルブレークアウトさせることで、ユーザーのウェブアクセス遅延時間を最小化し、顧客体験の向上に寄与している点も挙げられます。 【IMS】 IMS は音声サービスを司るがゆえに、ネットワークのクラウド化による迅速な障害発見や是正処置など品質・運用の高度化、等が期待されています。対する AWS の提供する価値としては、TELUS と協業したソリューション内容の具体例から、障害発生時のリアルタイムアラート、生成 AI を用いて運用者への是正アクション推奨とクローズドループを使った是正処置、そして生成 AI チャットインターフェースを介し運用者が自然言語を使ってのネットワークのオンデマンドオブザーバビリティが挙げられます。 【OSS/BSS】 OSS/BSSでは、ネットワーククラウド化によりサービス多角化と並行した TCO 削減、等が期待されています。対する AWS の提供する価値として、Amdocs と協業したソリューション内容の具体例から、スタジアム向けのプライベートネットワーク接続サービスのライフサイクル管理において、生成 AI とAWSサービスを組み合わせて導入から運用、インシデント対応、予防保守までと管理範囲を多角化しながら、シームレスに自動化することで TCO の削減に寄与していることが挙げられます。 3. 産業のデジタル化 AWS 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信ソリューション第二部 ソリューションアーキテクト　陳 誠 資料は こちら からダウンロード頂けます。 陳からは、AWS が通信事業者様やパートナー様と協業して、金融、農業、製造、運用、医療、教育の各分野における産業のデジタル化の取り組みをお届けしました。これら取り組みは今回 MWC 2024 にて多数の展示とデモンストレーションを介して紹介されました。 以下に各分野での概要をまとめました。 【金融: Network API を活用したセキュアなデジタル認証】 API プラットフォームプロバイダである Axiata Digital Labs と協業し、CAMARA ベースの 通信事業者 API フェデレーションプラットフォーム Sinergi を開発。Sinergi は、インドネシアの主要通信事業者である XL Axiata と Indosat Ooredoo Hutchison の Network API を AWS 上で 1つのポータルに統合しています。フィンテック企業等はこの単一の統合ポイントから複数の通信事業者の API にアクセスできるようになり、例えば SIM スワップ API を活用したデジタル本人確認などのサービスを提供できます。 【農業: 5G と MEC を活用した農業 DX】 カナダの通信事業者 TELUS と協業し、5G、生成AI などの最新技術を活用した農業向けのワンストッププラットフォームを提供。農家が AI チャットボットとの会話を通して、ドローンを用いた除草ソリューションの提案を受けたり、農作物の健康状態のモニタリングを実現したりなど、生産性向上や労働時間の削減に寄与しています。 【製造: 製造業におけるスマートな欠陥検出】 アメリカの製造業大手の JABIL と協業し、プライベート5G、エッジコンピューティング、コンピュータビジョン、ワイヤレスカメラを活用し、製造ラインでのリアルタイム製品欠陥検出を実現。高速プライベート 5G ネットワークと AWS Snowball Edge に配置した画像解析モデルによって、組立ラインのリアルタイムのカメラ映像を平均 60ミリ秒の遅延で解析することで、組立終了後の検査不合格を大幅に削減し、生産性向上に寄与しています。 【運輸: 港湾のプライベート 5G ネットワークの収益化】 港湾向けプライベート 5G ネットワークを提供する Verizon Business Group と協業し、入港時の航運会社向けに B to B to X のマルチテナントプラットフォームを開発。例えば入港者はタブレットでアプリを起動し、ビデオカメラによる「作業者安全検査」やドローンによる「在庫検査」などのサービスを発注、注文に基づいてプライベート 5G ネットワークおよび関連のビデオ分析やドローン監視などのサービスがユーザーテナント内でデプロイされます。このソリューションは航運会社に便利なサービスを提供しつつ、マルチテナントのフレームワークでコスト削減を実現でき、Verizon Business Group にとっても収益化に繋がります。 【医療: コネクティッド医療現場】 5G ソリューションプロバイダの Celona と協業し、プライベート 5G と Multi Operator Exchange (MOXN) ソリューションを使い、病院キャンパス内カバレッジを拡大させ通信環境を改善。プライベート 5G によるキャンパス内のプライベート接続だけでなく、MOXN と T-Mobile の Build Your Own Coverage の仕組みを利用し、来訪者や持ち込みモバイル向けにもパブリック接続の屋内カバレッジを増強しました。その結果、医療スタッフ間の音声コミュニケーションや患者モニタリング向けデバイスの通信品質が向上し、従来のシステム (分散アンテナシステム) と比べて TCO を40～60% 低く抑えています。 【教育: 没入型ゲームによる医療教育の変革】 アメリカのソリューションプロバイダの Level Ex が、AWS のエッジコンピューティングサービスの一つである AWS Wavelength を利用し、低遅延・高帯域のネットワーク環境上で AR/VR を活用した医療トレーニングソリューションを開発。ソリューションを GPU ベースのエッジコンピューティングに配置することで 30ミリ秒の低遅延で 4K 映像の仮想トレーニング環境を構築、これにより AR/VR を介してゲームのように手術の模擬練習ができ、臨場感と操作性を高めたソリューションとなっています。 4. 消費者体験の再考 AWS 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信ソリューション第一部 ソリューションアーキテクト　小林 新一 資料は こちら からダウンロード頂けます。 小林からは、消費者体験の向上をテーマとした AWS の取り組みをお届けしました。こちらでは、生成 AI によるモバイルデバイス顧客体験強化と、統合型スマートホームソリューションの2つの事例を通じて、AWS がネットワーク、デバイス、ホームデータの統合的な活用により、ユーザーにとって利便性の高いサービスを提供していることをご紹介しました。 以下に２つの事例の概要をまとめました。 【生成 AI によるモバイルデバイスの顧客体験強化】 モバイルデバイスにおいてゲームは顕著なユースケースの一つです。モバイルゲームではネットワーク越しに他のユーザと対戦や交流することが特徴のため、ユーザの操作性に影響するネットワークの低遅延性や、モバイルデバイスの安定性が重要な体験要素になります。これまで問題が発生した際のネットワーク障害調査やデバイス診断には通常数週間以上かかることが課題でした。Mavenir と協業したネットワーク診断ソリューションでは、⽣成 AI を活⽤したネットワーク障害時のデバッグファイルの解析、過去の障害ケースとの照合、AIチャットボットとの会話による問題特定、解決方法の提示を受けることができ、ネットワーク障害の調査・解決までの時間を短縮できます。また MCE と協業したモバイルデバイス診断アプリでは、生成 AI チャットボットが組み込まれており、デバイスの不調というユーザの NPS (Net Promoter Score) 低下の要因を緩和するソリューションが提案され、例えばゲーミフィケーションされたデバイス操作テストや、AIによる端末のアップグレードの提案など新たな体験をユーザに提供します。 【統合型スマートホームソリューション】 スマートホーム市場には多様な製品が存在するがゆえに、異なるプラットフォームとサイロ化されたデータが存在するという課題があります。今回、TELUS と AWS の協業により、多様な IoT デバイスを統合的に管理するソリューションを開発しました。BLE、ZigBee、Wi-Fi、Matter など複数の通信プロトコルに対応し、異なるホームデバイスの容易な追加や、マルチ音声アシスタントによる制御も実現しています。また生成 AI チャットボットとの会話により、デバイスをコントロールしたり、利用パターンに基づいたルーチンを簡単に構築することができます。一つのコントロールパネルから全てのデバイスを制御・監視し、トラブルシューティングすることも可能です。センサーデータはヘルスケアとも関係が深く、宅内の各種センサーデータを集約することで、例えば生活や健康状態を包括的に把握したり、転倒検知によって高齢者のサポートをしたりすることも可能です。このように両社のコラボレーションにより、デバイスの統合管理、AI 活用によるユーザー体験の最適化、ヘルスケア機能の強化など、スマートホームの体験を大幅に変革する先進的な取り組みが実現しています。 まとめ 本ウェビナーでは、2024 年 4 月 18 日に開催した「テレコム業界向け：Mobile World Congress (MWC) 2024 Recap」の振り返りとして、開催概要や発表の見どころ、お客様事例をご紹介しました。セミナーにご参加いただいた方、誠にありがとうございました。ご参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考としてお役立ていただければ幸いです。ご質問やご要望がございましたら、 お問い合わせページ 、もしくは担当営業までご連絡をお願いします。 このブログの著者 黒田 由民 (Yoshimi Kuroda) 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信ソリューション第一部 ソリューションアーキテクト

Amazon Bedrock の Knowledge base 機能 を使用すると、 Amazon Bedrock の 基盤モデル（FM）に自社のデータを安全に接続して、検索拡張生成 (RAG) を行うことができます。 検索によって取得した自社データを利用することで、 FM を再学習することなく、より関連性の高く、文脈に即した正確な応答を生成できるようになります。 この記事では、Amazon Bedrock の Knowledge base の RetrieveAndGenerate API に特化した2つの新機能について説明します。Knowledge base から取得する検索結果の最大数の設定と、Knowledge base のプロンプトテンプレートを使用したカスタムプロンプトの作成です。これらは検索タイプとともにクエリオプションとして指定できるようになりました。 新機能の概要と利点 Knowledge base から取得する最大結果数（ソースチャンクの最大数）を指定するオプションでは、ベクトルストアから取得し、回答生成のために FM に渡される検索結果の数を制御できます。これにより、生成のために提供される背景情報の量を、複雑な質問には多く、簡単な質問には少なくカスタマイズできます。この機能では最大 100 件の結果を取得できます。 このオプションは、関連する文脈の可能性を高め、それによって生成された応答の精度を上げ、ハルシネーション（幻覚）を減らすのに役立ちます。 カスタムナレッジベースのプロンプトテンプレートでは、デフォルトのプロンプトテンプレートを独自のものに置き換えて、応答生成のためにモデルに送信されるプロンプトをカスタマイズできます。これにより、ユーザーの質問に応答する際の FM のトーン、出力形式、動作をカスタマイズできます。 このオプションを使用すると、医療や法律などの業界や分野に合わせて用語を微調整できます。さらに、特定のワークフローに合わせたカスタム指示や例を追加できます。 以下のセクションでは、 AWS マネジメントコンソール または SDK を使用してこれらの機能を使用する方法について説明します。 前提条件 以下の手順を進めるためには、既存の Knowledge base が必要です。Knowledge base を作成する手順については、 Knowledge baseを作成する をご覧ください。 コンソールからソースチャンクの最大数を設定する コンソールでソースチャンクの最大数オプションを使うには、次の手順に従ってください: Amazon Bedrock コンソール画面で、左側のナビゲーションペインから Knowledge base を選択します。 作成済みの Knowledge base を選択します。 Test Knowledge base を選択します。 設定アイコンを選択します。 Knowledge base のテストを開始する前に、 Sync data source を選択してください。 Configurations の、 Search Type については、ユースケースに合わせて適切な検索タイプを選択してください。 この記事では簡単のためデフォルトの検索を使用しますが、ユースケースに応じてセマンティック検索やハイブリッド検索を利用することもできます。ハイブリッド検索の詳細については、 Knowledge bases for Amazon Bedrock now supports hybrid search をご覧ください。 「 Maximum number of source chunks 」を展開し、取得するソースチャンクの最大数を設定してください。 新機能の価値をデモンストレーションするため、生成されたレスポンスの精度を高める方法の例を示します。 Amazon の Knowledge base を作成するためのソースデータとして、Amazon の年次報告書と株主への手紙 ( 2023 年の Amazon 10-K 文書 、 2022 年の株主への手紙 、 2021 年の株主への手紙 、 2020 年の株主への手紙 、 2019 年の株主への手紙 ) を使用しました。 実験用のクエリは「Amazon の年間収益が 2,450 億ドルから 4,340 億ドルに増加したのはいつの年ですか?（”In what year did Amazon’s annual revenue increase from $245B to $434B?”）」です。 この質問に対する正しい回答は、「 Amazon の年間売上高は 2019 年の 2,450 億ドルから 2022 年には 4,340 億ドルに増加しました」です。これは、 ナレッジベース内の文書 に基づいています。この例では、ナレッジベースから取得した文脈情報に基づいて最終的な回答を生成するために、Claude v2 を言語モデルとして使用しました。また、Claude 3 Sonnet と Claude 3 Haiku も言語モデルとしてサポートされています。 別のクエリを実行し、異なる設定での取得の比較を検証しました。同じ入力クエリ (“Amazon の年間収益が 2,450 億ドルから 4,340 億ドルに増加したのはいつの年ですか?”) を使用し、結果の最大件数を 5 に設定しました。 次のスクリーンショットに示すように、生成されたレスポンスは「申し訳ありませんが、このリクエストに対応できません (“Sorry, I am unable to assist you with this request.”)」でした。 次に、最大結果を 12 に設定し、同じ質問をします。生成された応答は「 Amazon の年間売上高は、2019 年の 2,450 億ドルから 2022 年には 4,340 億ドルに増加しました（”Amazon’s annual revenue increase from $245B in 2019 to $434B in 2022.”）」でした。 この例で示したように、検索結果の件数に基づいて正しい回答を取得できました。最終的な出力が参照したデータソースの詳細を確認したい場合は、 Show source details を選択し、Knowledge base に基づいて生成された回答を検証してください。 Knowledge base プロンプト テンプレートのカスタマイズ (コンソール) ユースケースに応じて、デフォルトのプロンプトをカスタマイズすることもできます。コンソールでこれを行うには、以下の手順に従ってください。 前のセクションの手順を繰り返して、Knowledge base のテストを開始します。 Generate responses を有効にします。 レスポンス生成のためのモデルを選択します。 この記事では、例として Claude v2 モデルを使用しています。Claude 3 Sonnet および Haiku モデルも利用可能です。 Apply を押します。 モデルを選択すると、 Configuration の下に Knowledge base prompt template という新しいセクションが表示されます。 Edit を選択してプロンプトをカスタマイズします。 プロンプトテンプレートを調整して、Knowledge base から取得した結果を使用してコンテンツを生成する方法をカスタマイズします。 この記事では、カスタムのプロンプトと Amazon の財務諸表を使用して「財務アドバイザー AI システム」を作成する例をいくつか示しました。プロンプトエンジニアリングのベストプラクティスについては、 プロンプトエンジニアリングのガイドライン を参照してください。 さまざまな方法でデフォルトのプロンプトテンプレートを自身にカスタマイズし、レスポンスを確認します。 デフォルトのプロンプトでクエリを試しましょう。「Amazon の 2019 年と 2021 年の収益は何でしたか?（”What was the Amazon’s revenue in 2019 and 2021?”）」と質問します。以下が結果です。 出力結果から、Knowledge base から取得したデータに基づいてレスポンスを生成していることがわかります。 引用リンクも参考として出力されています。 例えば出力形式を JSON として標準化するなど、生成されたレスポンスのフォーマットに関する追加の指示を与えたい場合、プロンプトテンプレートの一部として、情報を取得した後の別のステップとしてこれらの指示を追加することができます。 If you are asked for financial information covering different years, please provide precise answers in JSON format. Use the year as the key and the concise answer as the value. For example: { year:answer } 最終的な回答が、JSON 形式になっていることがわかります。 プロンプトをカスタマイズすることで、生成される回答の言語も変更できます。次の例では、モデルにスペイン語で回答を提供するよう指示しています。 デフォルトのプロンプトから $output_format_instructions$を削除すると、生成された回答からの引用が削除されます。 以下のセクションでは、SDK でこれらの機能を使用する方法について説明します。 SDK を使用してソースチャンクの最大数を設定する SDK で最大結果数を変更するには、次のような構文を使用します。この例では、クエリは「Amazonの年間収益が2,450億ドルから4,340億ドルに増加したのは何年ですか?（”In what year did Amazon’s annual revenue increase from $245B to $434B?”）」です。正しい回答は「Amazonの年間収益は2019年の2,450億ドルから2022年の4,340億ドルに増加しました。（”Amazon’s annual revenue increase from $245B in 2019 to $434B in 2022.”）」となります。 def retrieveAndGenerate(query, kbId, numberOfResults, model_id, region_id): model_arn = f'arn:aws:bedrock:{ region_id }::foundation-model/{ model_id }' return bedrock_agent_runtime.retrieve_and_generate( input ={ 'text': query }, retrieveAndGenerateConfiguration ={ 'knowledgeBaseConfiguration': { 'knowledgeBaseId': kbId, 'modelArn': model_arn, 'retrievalConfiguration': { 'vectorSearchConfiguration': { 'numberOfResults': numberOfResults, 'overrideSearchType': "SEMANTIC", # optional } } }, 'type': 'KNOWLEDGE_BASE' }, ) response = retrieveAndGenerate("In what year did Amazon's annual revenue increase from $245B to $434B?", \ "", numberOfResults, model_id, region_id)['output']['text'] retrievalConfiguration の下にある numberOfResults オプションでは、取得したい結果の数を選択することができます。RetrieveAndGenerate API の出力には、生成されたレスポンス、ソース属性、取得したテキストチャンクが含まれます。 以下は、numberOfResults パラメータの値を変えた場合の結果です。まず、numberOfResults = 5 に設定します。 次に、numberOfResults = 12 に設定します。 SDK を使用して知識ベースのプロンプトテンプレートをカスタマイズする SDK を使用してプロンプトをカスタマイズするために、異なるプロンプトテンプレートを使用して次のクエリを使用します。この例では、クエリは「2019年と2021年のAmazonの収益はいくらでしたか?（”What was the Amazon’s revenue in 2019 and 2021?”）」です。 以下はデフォルトのプロンプトテンプレートです: """You are a question answering agent. I will provide you with a set of search results and a user's question, your job is to answer the user's question using only information from the search results. If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question. Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion. Here are the search results in numbered order: $search_results$ Here is the user's question: $query$ $output_format_instructions$ A: """ 以下はカスタマイズしたプロンプトテンプレートです: """Human: You are a question answering agent. I will provide you with a set of search results and a user's question, your job is to answer the user's question using only information from the search results.If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question.Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion. Here are the search results in numbered order: $search_results$ Here is the user's question: $query$ If you're being asked financial information over multiple years, please be very specific and list the answer concisely using JSON format {key: value}, where key is the year in the request and value is the concise response answer. Assistant: """ def retrieveAndGenerate(query, kbId, numberOfResults,promptTemplate, model_id, region_id): model_arn = f'arn:aws:bedrock:{ region_id }::foundation-model/{ model_id }' return bedrock_agent_runtime.retrieve_and_generate( input ={ 'text': query }, retrieveAndGenerateConfiguration ={ 'knowledgeBaseConfiguration': { 'knowledgeBaseId': kbId, 'modelArn': model_arn, 'retrievalConfiguration': { 'vectorSearchConfiguration': { 'numberOfResults': numberOfResults, 'overrideSearchType': "SEMANTIC", # optional' } }, 'generationConfiguration': { 'promptTemplate': { 'textPromptTemplate': promptTemplate } } }, 'type': 'KNOWLEDGE_BASE' }, ) response = retrieveAndGenerate("What was the Amazon's revenue in 2019 and 2021 ?"", \ "", , , , )['output']['text'] デフォルトのプロンプトテンプレートでは、次のようなレスポンスが得られます。 レスポンスを特定のフォーマット（JSON など）に標準化したい場合、既存のプロンプトをカスタマイズすることで、生成されるレスポンスの出力フォーマットに関する追加の指示を設定することができます。カスタムプロンプトテンプレートを使用すると、次のような JSON フォーマットのレスポンスが得られます。 generationConfiguration の promptTemplate オプションでは、回答生成をより細かく制御するためにプロンプトをカスタマイズできます。 結論 この記事では、Amazon Bedrock の Knowledge base の 2 つの新機能について紹介しました。検索結果の最大数の調整と、RetrieveAndGenerate API のデフォルトプロンプトテンプレートのカスタマイズです。これらの機能をコンソールや SDK で設定して、生成されたレスポンスのパフォーマンスと精度を向上させる方法を示しました。最大結果数を増やすことでより包括的な情報が得られ、プロンプトテンプレートをカスタマイズすることで、特定のユースケースにより適合するように FM への指示を微調整できます。これらの機能強化により、柔軟性と制御性が向上し、RAG ベースのアプリケーションにおいてテーラーメイドのエクスペリエンスを提供できるようになります。 AWS 環境での実装を開始するための追加リソースについては、以下を参照してください。 ユーザーガイド: Amazon Bedrock の知識ベース YouTube 動画: RAG を使用して生成 AI アプリケーションのレスポンスを改善する GitHub リポジトリのコードサンプル: Amazon Bedrock Knowledge base – RAG ワークフローを構築するためのサンプル 翻訳は Solutions Architect 小林が担当しました。原文は こちら をご覧ください

このブログは 2024 年 3 月 27 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 生成 AI は急速に産業を変革しており、先週サンフランシスコのモスコーンコンベンションセンターで開催された Game Developer Conference (GDC) 2024 でもその地殻変動は確実に感じられました。 Amazon Web Services (AWS) for Games はクラウドベースのゲーム開発向け最新テクノロジーを紹介するだけでなく、 2024 年版「 AWS ゲーム開発者向け生成 AI ガイド 」を含む、開発者向けの生成 AI を推し進める資料にハイライトを当てました。 この新しい電子書籍では、生成 AI がゲーム開発の高速化からより魅力的なプレイヤー体験の実現、パブリッシュ作業の合理化に至るまで、イノベーションの新時代を引き起こしている方法を掘り下げています。これはスタジオに実用的な生成 AI 機能に関する背景やガイダンスを提供し、テクノロジースタックを検討し、ゲーム開発者の使用事例を発見するために作られました。ぜひ チェック して下さい。以下では GDC 2024 での AWS for Games の活動をまとめています。 AWS デモ GDC を通し、Play & Learn ラウンジには AWS の生成 AI 専門家が常駐し、大規模言語モデル (LLM) と生成 AI サービスが、非プレイヤーキャラクター ( NPC ) をよりダイナミックで賢いものにする方法を実演しました。 Titan Image のデモ では、生成 AI と Amazon Bedrock を使って、実際に画像アセットを作成するタスクを解決するための高度な手法を紹介しました。 ダイナミックな NPC との会話デモ では、Epic Games の Unreal Engine MetaHuman を使って生成 AI アプリケーションとして NPC を構築する例「 Ada 」を紹介し、NPC とプレイヤーとの対話をよりダイナミックで賢いものにし、Amazon Bedrock が支える生成 AI によってプレイヤー体験を強化しました。 Gilded Mansion のデモ では、AWS Bedrock と Anthropic の Claude を使って構築された謎解きゲームを紹介し、プレイヤーが事件の手がかりを探すためにゲーム内のキャラクターと会話する様子を見せました。Play & Learn ラウンジを訪れた人々は、 Amazon Luna からストリーミングされるビデオゲームをプレイしながら、開発プロセスに関わるスタジオやサービスについて学ぶこともできました。 AWS セッションのハイライト ゲームの世界で無限にコンテンツを作る、生成 AI の活用 : Saltwater Games が、無料プレイ可能なポストアポカリプスなオープンワールドクラフト・サバイバルゲーム「 Resurgence 」の生成 AI アーキテクチャについて詳しく解説します。Amazon Bedrock で動作する同作の ThorAI の技術や、コンパニオンモバイルゲーム「 Missing 」のフルボイス化された対話式のゲーム内 NPC について深く掘り下げます。さまざまな生成 AI サービスとソリューションの実際の使用例を探ります。 ゲームにおけるコンテンツモデレーションへの生成 AI 活用 : 機械学習と生成 AI が、音声チャット、テキストメッセージ、画像、動画、ライブストリーミングなどのコンテンツモデレーションに活用されています。人間のモデレーターがこの技術を使って意思決定の効率を高め、手動レビューが必要な有害コンテンツの量を最小限に抑える方法や、健全なゲームコミュニティを育成しながらプレイヤーのエンゲージメントを維持する方法を紹介します。 「 Baldur’s Gate 3 」から生み出される魔法のデータの捕捉 : 「 Baldur’s Gate 3 」はプレイヤーの選択によって大きく影響を受ける、複雑なストーリーラインに基づいて作られています。 Larian Studios がプレイヤーの位置や個別のストーリーを通る流れを表す複雑な状態セットの違いを捕捉する為に、AWS を導入した方法を探ります。ユーザーがアップロードした何百万ものクロスセーブの処理からゲームプレイ分析に至るまで、これらのデータ捕捉システムがプレイヤーと開発者の両方にどのようにサービスを提供し、早期アクセスリリースから 3 年後の本リリースが大成功するまでどのように拡張されたかをご覧ください。 2023 年リリースの No.1 カジュアルゲーム「 MONOPOLY GO! 」の構築とスケーリング : Scopely の「 Monopoly Go! 」は 2023 年 4 月にリリースされ、すぐに世界で最も人気のカジュアルモバイルゲームになり、6 か月で 10 億ドルの収益を上げました。このゲームのアーキテクチャと設計の考え方、スケーリングに使われた AWS サービス、学んだ教訓についてお話しします。 Bungie 創設者 Alexander Seropian が語るゲーム開発の未来 : Look North World 創設者で Bungie 創設者でもある Alexander Seropian 氏を迎え、フォートナイト ユニバースで新しい体験を提供するために Unreal Editor for Fortnite (UEFN) を使って開発を進める同社について、詳細をお話頂きます。また、開発キャリアを通して学んだ教訓、新しいアプローチが生み出す機会、クラウドでの構築とゲームの面白さに注力することの重要性についても説明します。 プロダクトマネージャーのジレンマ – ライブゲームの管理における健全なバランスの取り方 : プロダクトマネージャーはリソースの配分と時間の使い方をより効率的にしなければなりません。ライブゲームの管理には、成熟したプレイヤーを常に新しいコンテンツで引き留め、オファーをパーソナライズし、新規プレイヤーを惹きつけ、できるだけ早くコアループに誘導することのバランスが必要です。CleverTap Gaming と AWS for Games から、ゲームチームが LiveOps をどのように推進し、ゲームを管理するかを選択する際のアプローチの概要を紹介します。 コミュニティクラブハウス開発者サミット : 安全で社会的なゲームプラットフォームの構築 : Netflix Games の信頼と安全に関する責任者である Christina Camilleri 氏、Roblox の信頼と安全管理に関するシニアディレクターである Joel Silk 氏、Keywords Studios の信頼と安全に関する責任者である Kaila Jarvis 氏、Spry Fox の Chief Creative Officer の Daniel Cook 氏、そして AWS の EMEA 地域 Game Tech 事業戦略責任者 Shayan Sanyal 氏を迎え、「安全性を事後対応ではなく、プラットフォーム設計に統合したらどうなるか」という重要な問いについて深く議論します。意図して不正利用を防止する機能を備えたプラットフォームが、プレイヤー満足度の向上、プレイヤーの滞留と魅力の促進にどのように役立つかを探ります。 AWS イベント 月曜日の夜、AWS、Amazon Games、Women in Games International (WIGI) は共同でミナギャラリーで Women in Games イベントを開催しました。WIGI の CEO、Joanie Kraut 氏が進行するパネルディスカッションでは、Tiny Rebel Games の CEO、Susan Cummings 氏、Maximum Entertainment の CEO、Christina Seelye 氏、Netflix Games Studio のリクルーター、Marie Ablaza 氏から洞察を得ました。このイベントは業界の仲間と交流する機会となると共に、ゲーム業界で女性や女性であることを自認する人々に多様性と包括性、機会を広げる事を促進した人の功績を称えるものでした。 水曜日の夜には AWS for Games パートナーショーケース が開催され、AWS の理念を主導するリーダー、ゲームスタジオ、テクノロジーパートナーが一堂に会し、今日のゲームを構築、革新、成長させるための最新のゲームテクノロジーについて議論しました。このイベントでは、生成 AI、クラウドゲーム開発、ゲームバックエンドの最新トレンドと技術について、30 分間のパネルセッションが行われました。スピーカーには、AAA 級スタジオの Epic Games と Warner Bros Games Avalanche Software の代表者や、Sprocket Games や UneeQ などの革新的なスタートアップ企業の代表者が含まれていました。 パートナーに関するニュース Heroic Labs は、業界をリードするゲームサーバー「 Nakama 」と AWS の専用ゲームサーバー管理サービス Amazon GameLift との、オープンソースのネイティブ統合を発表しました。この直接的な統合により両サービスの強みが融合し、ゲーム開発者向けのシームレスで強力なプラットフォームが実現し、プレイヤーに比類のない体験を提供できるようになります。開始方法と、セッションベースのマルチプレイヤーを新たな高みに引き上げる方法を ご確認下さい 。 また AWS は Pragma を正式に AWS Select Technology パートナーに指定しました。この発表に関連してPragma の CTO である Chris Cobb 氏は、「 AWS エコシステムとの深い統合により、スタジオに対して高速で信頼性の高いデプロイ、テスト、モニタリングを提供できるようになった 」と 述べています 。 新しいソリューションのリリースとアップデート 生成 AI AWS は 2 つの新しい生成 AI ソリューションをリリースしました。「 Guidance for Dynamic Non-Player Character (NPC) Dialogue on AWS 」( サンプルコード ) は、Unreal Engine MetaHuman、大規模言語モデルオペレーション (LLMOps)、生成 AI を使って、NPC とそれに関連するインフラストラクチャを自動的に作成するプロセスを支援し、NPC の会話能力を向上させます。パートナーソリューション「 PlusMusic Adaptive Music Platform 」は、AI によって音楽をムード、テーマ、体験にマッピングし、デジタルワールドに動的で没入感のある音響空間を作成するのを支援します。開発者は 37 万 5 千曲以上のフルライセンスされたトラックをライブラリから選択でき、音楽ライセンスの手続きが簡素化され時間を節約できます。 GDC で生成 AI ソリューションを紹介したことに加え、 AWS for Games はゲームの構築、実行、成長を支援するための提案とアップデートをいくつか発表しました。詳細な解説と適用例は以下の通りです。 コミュニティヘルス 「 Guidance for Responsible Content Moderation with AI Services on AWS 」 ( サンプルコード ) は、他の方法に比べてより正確でコスト削減できる AI を使ったユーザー生成コンテンツ (UGC) のモデレーションを実演します。 パートナーソリューション「 GGWP Platform 」は、ゲームコミュニティを保護・育成し、よりポジティブなプレイヤー体験を創出するための直感的なツールを提供します。 一元的なゲーム分析 パートナーソリューション「 ClickHouse Cloud 」は、膨大なデータ量とリアルタイムクエリレスポンスに対応した、極めて高速、シームレス、スケーラブルで、使いやすいオンライン分析データベースです。 パートナーソリューション「 GameAnalytics Data Suite 」は、開発者が独自のデータパイプラインを構築する手間を省き、包括的で費用対効果の高いデータソリューションを提供します。 セッションベースゲームのインフラ 「 Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS 」 ( サンプルコード ) は、グローバルゲームサーバーの設定を自動化し、Agones や OpenMatch といったオープンソースフレームワークを Amazon Elastic Kubernetes Service (Amazon EKS) 上に構成するための手順を示します。 「 Guidance for Multiplayer Session-Based Game Hosting on AWS 」( アーキテクチャと サンプルコード がアップデートされました ) は、Amazon GameLift を使ったグローバルスケールのマルチプレイヤーゲーム開発を開始するのに役立ち、今回クロスプラットフォームサポートに合わせて Custom Game Backend Framework と統合されました。 プレイヤーインサイト 「 Guidance for AI-Driven Player Insights on AWS 」 ( サンプルコード ) は、ラベル付きプレイヤーデータを取り込み、プレイヤー行動を予測する最適な機械学習モデルを自動的に構築、トレーニング、チューニング、デプロイするエンドツーエンドの機械学習パイプラインを構築するプロセスを自動化します。 バージョン管理とデジタルアセット管理 「 Guidance for Building Perforce Helix Core on AWS 」( アーキテクチャがアップデートされました )　は、ゲーム開発者が人気のバージョン管理ツール「 Perforce Helix Core 」を、高い可用性を持つ複数の AWS リージョンにまたがってデプロイするのを助けます。これにはオンプレミスデータセンターやリモートクライアントからの安全な接続も含みます。 「 Guidance for Intelligent Identification of 2D/3D Assets on AWS 」は、AI/ML を使って 2D/3D アセットを自動的に識別・管理する事で、ゲームスタジオがこれらを手動で処理するのに比べて時間を節約し、正確性を高める事を助けます。 ワークステーション 仮想デスクトップのパートナーソリューション「 HP Anyware with Epic Games Unreal Engine 5 for Windows 2022 」は、オンデマンドでゲーム開発の最新ソリューションをもたらします。 AWS for Games、お客様、パートナー、そして参加者の皆様のおかげで、今年の GDC は大成功を収めることができました。心から感謝致します! 翻訳はソリューションアーキテクトの長田が担当しました。

　こんにちは。ソリューションアーキテクト (以下 SA) の高野です。 　2024 年 4 月 25 日に「 AWS 春の Observability 祭り 2024 〜Observability 獲得までの旅〜 」と題したイベントを開催しました。昨年秋に実施させていただいた AWS 秋のObservability 祭り以来の Observability をテーマにしたイベントになります。ご参加いただきました皆様には、改めて御礼申し上げます。昨年の開催報告ブログは こちら 。 　本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開致します。今回は、Observability の獲得プロセスをテーマに様々なセッションを行いました。Observability 獲得の全体像を俯瞰し、各ステップで具体的に役立つ AWS のサービス、AWS における Observability のベストプラクティスと最新のアップデートをご紹介しました。システムに Observability を獲得したい方はぜひご確認下さい！ セッションの紹介 Observability ジャーニーの全体像 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 津郷 光明 資料ダウンロード   　セミナー開始は、SA 津郷より、Observability 獲得プロセスの全体像ということで、「何から始めればいいのか？」「どこを目指せばいいのか？」という疑問に対する解決のヒントになる AWS Observability Maturity Model を紹介しました。AWS Observability Maturity Model で定義している 4 つの成熟度のステージとその内容を紹介しました。皆様が現状の取り組んでいるレベルがどのステージなのかご確認いただき、次に目指すべきステージとその内容を把握することで、ロードマップ策定に役立てていただければと考えております。また、Observability に取り組むにあたり、大事な考え方である「無理なく・必要な場所から取り組む」、「システムの実装だけで終わりではない」、「継続的な取り組みが大切」というメッセージをお伝えしました。 Observability ジャーニーを実現するための AWS サービス：CloudWatch 編 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 津和崎 美希 資料ダウンロード   　次に、SA 津和崎より、AWS Observability Maturity Model の各ステージで利用できる Amazon CloudWatch 関連のサービスを紹介しました。テレメトリーデータを収集するサービスとして、CloudWatch の基本のサービスである CloudWatch Metrics (メトリクス)、CloudWatch Logs (ログ)、 AWS X-Ray (トレース) を紹介しました。収集したテレメトリーデータを分析するために、X-Ray のトレースマップから、レイテンシーやエラー率と言ったメトリクスを確認したり、CloudWatch Logs Insights に画面遷移して、根本原因を調査することができることを例示しました。次に、テレメトリーデータをもとに異常検知する CloudWatch Anomaly Detection や、機械学習で運用データやアプリケーションのメトリクスやイベントを分析し、通常の運用パターンから逸脱する動作を特定でき、現在及び将来の問題に対処するためのレコメンデーションを提示してくれる Amazon DevOps Guru を紹介しました。AWS では各ステージで適したサービスを用意していますので、AWSでのシステムにおける Observability を始める最初の選択肢として CloudWatch や X-Ray の利用を検討いただければと考えております。 Observability はじめの一歩 CloudWatch Synthetics アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 堀 貴裕 資料ダウンロード   　SA 堀より、Observability を獲得するために何から始めるといいか？という問いをテーマに、アプリケーションになるべく手を入れずにユーザ視点でアプリケーションが正常性を監視できる外形監視サービスである Amazon CloudWatch Synthetics を Demo を交えて紹介しました。CloudWatch Synthetics はよくあるユースケースではブループリントが用意されており、コーディングなしで外形監視を行うことができるサービスです。是非、何から始めるか迷われている方は、CloudWatch Synthetics を使って、自身のシステムの外形監視から始めてみてはいかがでしょうか？ Observability ジャーニーを実現するための AWS サービス：OSS 編 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 藤原 和弘 資料ダウンロード   　SA 藤原より、AWS Observability Maturity Model の各ステージで利用できる Open-source Managed Service を紹介しました。テレメトリーデータを収集するサービスとして、OpenTelemetry の安全で本番環境に適した AWS サポートのディストリビューションである AWS Distro for OpenTelemetry (以下 ADOT) が今できることの紹介や、Prometheus や Grafanaのマネージドサービスである Amazon Managed Service for Prometheus や Amazon Managed Grafana (以下 AMG) の紹介をしました。AMG では、テレメトリーデータの分析方法について例示しました。昨今、特定ベンダーに依存しない OpenTelemetry の需要が高まってきています。今後高度化していく Observability を実現しやすくするために、AWS 環境では、ADOT を利用してテレメトリーデータを収集し、柔軟にバックエンドリソースを変更できるようにしておくことをおすすめします。 AWS Observability ベストプラクティス大紹介 アマゾン ウェブ サービス ジャパン 合同会社 テクニカルアカウントマネージャ 日平 大樹 資料ダウンロード   　テクニカルアカウントマネージャの日平より、AWS で Observability を実装する上でのベストプラクティスガイドである AWS Observability Best Practices の紹介をしました。5 つのベストプラクティスの概要のご紹介と、ベストプラクティスのカテゴリ毎の内容の概要を紹介しました。本ガイドを活用することで、一般的な落とし穴を回避し、皆様のシステムに Observability をもたらす手助けになると思います。具体的な AWS のサービスに対してのガイドも記載されていますので、是非参考にしてみて下さい！ AWS Observability 関連最新アップデート アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 宮崎 友貴 資料ダウンロード   　最後は SA 宮崎より、AWS における Observability 関連の最新アップデートや事例を紹介しました。AWS への専用ネットワーク接続である AWS DirectConnect や VPN 等を経由したハイブリットネットワークのパフォーマンス監視を行える Amazon CloudWatch Network Monitor、AWS 上で実行されているアプリケーションを自動でモニタリングし、健全性やパフォーマンスを可視化する Amazon CloudWatch Application Signals、CloudWatch Logs で機械学習により、ログのパターンを自動で認識したり、異常を検知したりする機能等、最新機能アップデートを紹介しました。また、システム規模が拡大にするにあたり、Observability もスケールアップする必要があり、都度発生した課題を継続的に解決してきた Stripe 様の事例をご紹介しました。本事例にご興味のある方は、 こちら をご確認下さい。 まとめ 　今回は、Observability をどのように獲得していけば良いか迷っている方々を対象に、Observability 獲得プロセスを「旅路 (ジャーニー)」に例えて、様々なセッションを用意させていただきました。本イベントをきっかけに、皆様のシステム運用が少しでも楽になり、皆様が幸せになることを願っております。今後も、お客様のシステム運用を少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 ソリューションアーキテクト 高野 翔史