2025 年の第 2 週を迎えるにあたり、中国では旧正月の準備の始まりを意味する、伝統的な祝日である臘八節 (ろうはちせつ) をお祝いしています。この日、中国の人々は、さまざまな穀物やドライフルーツ、木の実を組み合わせた特別なお粥、 臘八粥 (ろうはちがゆ) を用意します。この 栄養価の高い料理は、調和、繁栄、幸運を象徴し、それぞれの成分は生命の多様性と豊かさを表します。伝統的なこの慣習は、ブッダが乳粥を食べて悟りを開いたときにまでさかのぼり、物質的栄養と精神的栄養の両方の象徴となっています。旧暦の 12 月 8 日に開催されるこの祭りは、中国で最も重要な伝統的な祝日であり、家族の再会と再生を祝う春節までのカウントダウンの始まりです。 グローバルなテクノロジーコミュニティが成長を遂げる中、このような文化的なお祝いは、包括的なイノベーションと進歩の共有の重要性を私たちに思い出させてくれます。 1 月 6 日週のリリース Amazon Web Services (AWS) が 1 月 13 日週にリリースした内容をご紹介します。 新しい AWS アジアパシフィック (タイ) リージョン – AWS は、3 つのアベイラビリティーゾーンを備えた新しいアジアパシフィック (タイ) AWS リージョン の立ち上げにより、グローバルインフラストラクチャを拡大しました。この追加によって、タイおよび東南アジア全域のお客様は、タイ国内のデータレジデンシーを維持しながら、より少ないレイテンシーで顧客にサービスを提供できるようになります。新しく立ち上げられたリージョンは、AWS サービスの全範囲をサポートし、急速に成長している ASEAN 市場での当社の存在感を強化します。 バンコクの新しい AWS Direct Connect 拠点 – タイリージョンの立ち上げに伴い、AWS ではバンコクに新しい AWS Direct Connect 拠点を設立し、既存のインフラストラクチャを拡張しました。この追加により、タイのお客様が AWS サービスにアクセスする際の接続オプションが改善され、ネットワークレイテンシーが短縮されます。 データベースと分析 Amazon DynamoDB 用の設定可能なポイントインタイムリカバリ期間 – Amazon DynamoDB では、ポイントインタイムリカバリ (PITR) 期間をカスタマイズできるようになりました。つまり、お客様はテーブルごとに 1～35 日の範囲のリカバリ期間を指定できます。この強化によって、組織はコスト効率を最大化しながら、正確なコンプライアンス要件を満たすことができるようになります。この機能は、AWS GovCloud (米国西部) および中国リージョンを含むすべての AWS リージョンでご利用いただけます。柔軟にデータのリカバリ期間を設定できるため、お客様はビジネス要件や規制上の義務を正確に遵守するバックアップポリシーを作成できます。 Amazon MSK Connect API と AWS PrivateLink – Amazon Managed Streaming for Apache Kafka Connect (Amazon MSK Connect) API は AWS PrivateLink のサポートを開始しました。これにより、お客様は仮想プライベートクラウド (VPC) 内のプライベートエンドポイントを介して MSK Connect API にアクセスできるようになります。この強化によって、トラフィックが AWS ネットワーク内に留まるため、セキュリティが強化され、データ漏洩が軽減されます。 生成 AI と機械学習 SageMaker コードエディタの Amazon Q Developer – Amazon Q Developer が Amazon SageMaker コードエディタの統合開発環境 (IDE) に統合され、AI を活用したコード支援を通じて、開発者のエクスペリエンスが向上しました。インテリジェントなコード提案、ドキュメント支援、コンテキストに基づく推奨事項を SageMaker 開発環境内で直接利用できるようになりました。 管理とガバナンス AWS Chatbot の AWS Systems Manager Automation – AWS Chatbot では、 AWS Systems Manager Automation ランブックの推奨事項が 20 件追加され、自動運用管理の機能が拡張されました。これらの新しい推奨事項は、お客様がチャットベースの対話を通じて業務タスクを合理化し、ベストプラクティスをより効率的に実装するのに役立ちます。 AWS Transit Gateway コスト分析の強化 – コストアロケーションタグを使用して、Transit Gateway のデータ処理料金を分析する新機能をリリースしました。この機能により、ネットワークコストの可視性と管理性が向上し、組織は AWS Transit Gateway の使用状況を効率的に追跡および最適化できるようになります。強化されたコスト分析ツールにより、ネットワークトラフィックパターンと関連コストに関する詳細な洞察を得ることができます。 その他の AWS ニュースとハイライト 2024 年に最も人気のあった DevOps ブログ記事</t1> – 回顧的なブログ記事「2024 年に最も多くアクセスされた DevOps とデベロッパーの生産性に関するブログ記事」が、今週の AWS で最も注目された記事となりました。このまとめでは、2024 年に最も影響力があった DevOps コンテンツを紹介し、注目のトピックとベストプラクティスに関する洞察を提供しています。この記事では、継続的インテグレーションと継続的開発 (CI/CD)、Infrastructure as Code (IaC)、自動化の実践に関する主要な開発について考察しています。 生成 AI の新しいセキュリティコース – AWS Skill Builder は、AWS での 生成 AI アプリケーションの保護に焦点を当てた新しいコースをリリースしました。この包括的なトレーニングでは、 人工知能と機械学習 (AI/ML) ワークロードのセキュリティのベストプラクティスを実装し、データ保護、モデルセキュリティ、コンプライアンス要件に対処する方法を学ぶことができます。このコースは、急速に発展する生成 AI の分野における専門的なセキュリティ知識に対する需要の高まりに応えます。 Amazon Connect Contact Lens の無料トライアル – Amazon Connect Contact Lens の会話分析とパフォーマンス評価を初めて使用するユーザー向けに、無料トライアルをご紹介します。新規のお客様は、2 か月間、毎月最大 100,000 音声分まで無料で処理できます。また、初めてパフォーマンス評価を行うユーザーには、最初の評価から 30 日間の無料トライアルが提供されます。このイニシアチブにより、お客様は追加費用なしで Contact Lens の機能を普段の環境で体験できます。無料トライアルは、Contact Lens がサポートされているすべての AWS リージョン でご利用いただけます。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 2025 年は、開発者、アーキテクト、ビジネスリーダー、クラウドジャーニー初心者などのあらゆる方に、また 2024 年に何が起こったかに関わらず、新しい機会をもたらします。 この記事は、 Weekly Roundup シリーズ の一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! – Betty 原文は こちら です。

本記事は 2024/9/13 に投稿された  Happy Sad app leverages AWS generative AI to improve student well-being  を翻訳した記事です。パブリックセクターソリューションアーキテクトの山本が担当しました。 新型コロナウイルスのパンデミックは、学生のメンタルヘルスと幸福度に大きな影響を与えました。実際、2021 年から 2022 年の学年度中、 公立学校の 87 %  が、パンデミックが学生の社会的・感情的発達に悪影響を及ぼしたと報告しています。これらの影響はパンデミック後も長く続き、学生の社会的・感情的幸福は依然として管理者、教師、そして親の主な関心事となっています。この継続的な危機に対処するため、 The Happy Sad Company が設立されました。 元 Instagram のデータサイエンティストで、同社の創設者である Hannah Oldknow は下記のように述べています。「私たちは、親として、教師として、そして長年のテック起業家としての経験に基づいて、Happy Sad アプリを設計しました。」「私たちのプラットフォームの目標は、『我が子はどうしているか？』という問いに答えることです。」 Oldknow は、教師、親、そして児童が、児童の社会的・感情的幸福をより良く理解するのに役立つアプリを構想しました。 アプリの戦略的計画、スケーリング、そして立ち上げにおいて、 アマゾン ウェブ サービス（AWS） との協力は明確な選択肢でした、と Oldknow は述べています。The Happy Sad Company は、 Amazon GuardDuty 、 AWS Lambda 、 Amazon CodeGuru などの AWS の高度なツールを活用することで、アプリ開発を大幅に加速させました。そして、チームは、 Metis や  Gaggle などの他の 教育技術（EdTech） 企業と AWS が行った取り組みに感銘を受けました。 人工知能（AI）を活用して児童の利用を促進 、教師をサポートする Happy Sad アプリには 2 つの目的があります。K6（幼稚園から 6 年生）の児童がアプリにアクセスすると、雲の形をした絵文字や、児童個々にパーソナライズされたアクセサリーで彩られたゲーム化された体験に入ります。この目的は、よく知られている CASEL フレームワーク に基づいた社会的・感情的戦略の適用を通じて、児童の感情的な自己認識を向上させることです。 アプリのもう 1 つの目的は、教育者に個々の児童の「メンタルヘルスレポートカード」を提供することです。これはアプリ内での児童の活動と反応に基づき生成されます。教師はこのデータを閲覧し、個々の児童や教室全体の感情状態のパターンや傾向を識別できます。データから導き出された AI の洞察は、保護者とも共有できるようエクスポートすることができます。 最終的には、創設者たちは、このアプリが児童の社会的・感情的幸福の早期通知システムとして機能し、児童の感情的健康が低下し始めた場合に、教師や保護者に警告を発することを構想しています。 「現在、私たちは独自の AI をトレーニングをしており、児童のベースラインの低下を予測できるようにしています。これにより、保護者や教師が児童の潜在的な問題に先手を打った対策を取るができるようになります。」と Oldknow は述べています。 AWS の専門知識がアプリ開発を加速 AWS からの各段階における強力なサポートにより、The Happy Sad Company はアプリ開発を迅速に進めることができました。同社は、AWS が他の EdTech 企業と持つ幅広い経験を活用し、プロトタイプ開発プロセスの指針とすることができました。 「AWS と提携した理由の一つは、特にコンプライアンスに関して、課題がどこにあるかをガイドしてくれることを知っていたからです」と Oldknow は述べています。 戦略的計画からスケーリング、そして立ち上げまで、AWS の複数部門のチームが Happy Sad のアプリ開発プロセス全体を通じて深い専門知識とサポートを提供しました。 「私たちは Happy Sad チームと多くのワークショップを開催し、アプリを構築する際にどの AWS サービスを使用するのが最も適切かを、より良く理解できるよう支援しました。」と、AWS のソリューションアーキテクトである Daniel Wells は述べています。 ソリューションアーキテクトに加えて、 スタートアップ Activate チーム 、アカウント管理チーム、go-to-market チーム、そしてワールドワイドパブリックセクターチームなど、様々な AWS チームが各段階で専門知識を共有しました。 AWS のガイダンスは、アプリ開発プロセスを改善するために利用可能な AI 駆動ツールをナビゲートする上で特に有益であることが証明されました。2 つの特許出願中のネイティブ AI プログラムを持つ The Happy Sad Company の経験豊富な AI チームは、AWS テクノロジーを採用する価値をすぐに認識しました。チームは、AI を使用してアプリのコードを最適化する方法を提案するツールである Amazon  CodeGuru Reviewer  の使用を決定し、また、セキュリティを監督し、アプリ内の悪意のある行動を監視するために Amazon GuardDuty  を使用することを決めました。 コンプライアンスを優先しつつ、コストを削減 学生の幸福に対するケアは教育の中心です。教育テクノロジーの成長に伴い、そのケアは現在、児童のデータプライバシーにまで及んでいます。学生オンラインプライバシー保護法（COPPA）は、13 歳未満の子どもたちのプライバシーを保護するために、ウェブサイトやオンラインサービス（アプリを含む）に要件を課しています。これは The Happy Sad Company にも当てはまる優先事項です。 「 Happy Sad チームは、アプリを安全でコンプライアンスに準拠したものにすることに焦点を当てていました」と、AWS の教育担当チーフテクノロジストの Leo Zhadanovsky は述べています。「私たちのチームでは、必要に応じてコンプライアンス要件を満たすための詳細なガイダンスを提供しました。」 COPPA に準拠したアプリ開発を優先することで、AWS は The Happy Sad Comoany との密接なパートナーシップをさらに強化しました。 「 Leo のチームは、データプライバシーを維持するためのガードレールを設定する素晴らしい仕事をしてくれました。これは、ユーザーの信頼を維持するために必要なものです」と Oldknow は述べています。 Happy Sad アプリには、需要の急増に管理オーバーヘッドを大きく増やすことなくシームレスに適応できる、柔軟でスケーラブルなインフラストラクチャが必要でした。それと同時に、AWS のサーバーレスコンピューティングサービスが理想的なソリューションであることが証明されました。サーバーレスコンピューティングプラットフォームである AWS Lambda  を使用することで、チームは固定ハードウェアへの高額な資本支出投資を回避しました。代わりに、AWS が提供する事実上無制限のセキュアなコンピューティングリソースのプールに即座にアクセスし、実際に使用したキャパシティに対してのみ支払うことができました。Zhadanovsky が説明するように、このようなサーバーレスアプローチは「過剰なプロビジョニングがないことを保証し、自動スケーリングは、必要なときに必要なキャパシティ・リソースにアクセスできること」を意味します。 Happy Sad アプリの市場投入 Happy Sad アプリは、K6（幼稚園から 6 年生）の児童のメンタルヘルスのための強力な教室リソースとして、急速に採用が広がっています。アプリの使用は、アメリカ全土の教師の間で急速に広がっており、ロサンゼルス統一学区、ヒューストン独立学区、コロンバス（オハイオ州）市学区など、より大規模な学区でも採用されています。教師の間でのリソース利用率は 50 〜 70 % の間で変動し、一方、児童ユーザーの利用率は現在、月平均約 80 % になっています。 「保護者の方々は、このアプリが進む方向性に興奮しています」と Oldknow は述べています。「多くの保護者が、子どもたちのメンタルヘルスについてより深い認識を提供できるツールを求めていました。私たちはそれを提供できることに胸を躍らせています。」 AWS公共部門ブログの関連記事： Introducing ‘Get started with generative AI on AWS: A guide for public sector organizations’ How Gaggle’s ReachOut program uses AWS to ease the K12 mental health crisis Metis adds real-time collaboration to classroom live streams with Amazon IVS BriBooks improves children’s creative writing with generative AI, powered by AWS     AWS Public Sector Blog Team AWS パブリックセクターブログチームは、世界中の政府、教育、非営利セクター向けに記事を執筆しています。パブリックセクター向け AWS について詳しく知るには、ウェブサイト（ https://aws.amazon.com/government-education/ ）をご覧いただくか、Twitter（@AWS_gov, @AWS_edu, and @AWS_Nonprofits）でフォローしてください。

2024 年 12 月 1 日、テストの合理化と 生成 AI アプリケーションの改善に役立つ Amazon Bedrock の 2 つの新しい評価機能を発表しました。 Amazon Bedrock ナレッジベースで RAG 評価 (プレビュー) のサポートを開始 – Amazon Bedrock ナレッジベース を使用して、自動ナレッジベース評価を実行して、 検索拡張生成 (RAG) アプリケーションを評価および最適化できるようになりました。評価プロセスでは、 大規模言語モデル (LLM) を使用して評価のメトリクスを計算します。RAG 評価では、さまざまな設定を比較し、設定を調整して、ユースケースに必要な結果を得ることができます。 Amazon Bedrock Model Evaluation に LLM-as-a-Judge (プレビュー) を追加 – 人間による評価を行う場合と比べて、わずかなコストと時間で、人間並みの品質でテストや他のモデルを評価できるようになりました。 これらの新機能により、AI を活用したアプリケーションの評価を迅速かつ自動的に行い、フィードバックループを短縮し、改善をスピードアップすることで、本番環境への移行が容易になります。これらの評価では、正確性や有用性、および回答拒否や有害性などの責任ある AI 基準を含む、品質に関する複数の側面を評価します。 簡単かつ直感的に理解できるように、評価結果は各スコアの自然言語による説明を出力とコンソールに表示し、スコアは解釈しやすいように 0 から 1 に正規化されています。ルーブリックはすべてジャッジプロンプトとともに文書に公開されているため、サイエンティストでなくてもスコアの導出方法を理解できます。 実際にどのように機能するか見てみましょう。 Amazon Bedrock ナレッジベースで RAG 評価を使用する Amazon Bedrock コンソールの [Inference and Assessment] (推論と評価) セクションで [Evaluations] (評価) を選択します。そこに、新しい [Knowledge Bases] (ナレッジベース) タブが表示されます。 [Create] (作成) を選択し、評価の名前と説明を入力して、メトリクスを計算する [Evaluator model] (評価者モデル) を選択します。今回は、Anthropic の Claude 3.5 Sonnet を使います。 評価するナレッジベースを選択します。以前、 AWS Lambda デベロッパーガイド PDF ファイル のみを含むナレッジベースを作成しました。このようにすることで、評価のために AWS Lambda サービスについて質問することができます。 検索機能だけを評価することも、検索して生成するワークフロー全体を評価することもできます。この選択は、次のステップで利用できるメトリクスに影響します。検索と応答生成の両方を評価することにし、使用するモデルを選択します。今回は Anthropic の Claude 3 Haiku を使います。 Amazon Bedrock Guardrails を使用したり、応答生成モデルの後に [configurations] (設定) リンクを選択してランタイム推論設定を調整したりすることもできます。 これで、評価するメトリクスを選択できます。 [Quality] (品質) セクションで [Helpfulness] (有用性) と [Correctness] (正確性) を選択し、 [Responsible AI metrics] (責任ある AI メトリクス) セクションで [Harmfulness] (有害性) を選択します。 次に、評価に使用するデータセットを選択します。これは、この評価用に準備して Amazon Simple Storage Service (Amazon S3) にアップロードした JSONL ファイルです。各行には会話が含まれ、その中のメッセージごとに参照応答があります。 {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"A trigger is a resource or configuration that invokes a Lambda function such as an AWS service."}]}],"prompt":{"content":[{"text":"What is an AWS Lambda trigger?"}]}}]} {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"An event is a JSON document defined by the AWS service or the application invoking a Lambda function that is provided in input to the Lambda function."}]}],"prompt":{"content":[{"text":"What is an AWS Lambda event?"}]}}]} 評価の結果を保存する S3 の場所を指定します。評価ジョブでは、S3 バケットが Amazon Bedrock ユーザーガイドに記載されているクロスオリジンリソース共有 (CORS) 許可で設定 されている必要があります。 サービスにアクセスするには、Amazon Bedrock が引き受けることができる AWS Identity and Access Management (IAM) サービスロールを作成または提供する必要があります。これにより、評価で使用される Amazon Bedrock および Amazon S3 リソースへのアクセスが可能になります。 数分後に評価が完了したので、結果を閲覧します。評価の実際の所要時間は、プロンプトデータセットのサイズ、使用したジェネレータおよび評価者モデルによって異なります。 一番上の メトリクスサマリー では、すべての会話の平均スコアを使用して全体的なパフォーマンスを評価します。 その後、 生成メトリクスの内訳 に、選択した各評価メトリクスの詳細が表示されます。私の評価データセットは小さかった (2 行) ので、大きな分布を見る必要はありません。 ここから、会話例とその評価も確認できます。すべての会話を見るには、S3 バケットの全出力を確認することができます。 なぜ 有用性 が 1 を少し下回っているのかに興味があります。 有用性 が見れるように、 会話例 の拡大とズームを行います。そこには、生成された出力、評価データセットと共に提供したグラウンドトゥルース、およびスコアが表示されます。モデルの推論を見るためにスコアを選びます。モデルによると、より詳細な情報があれば役立ったようです。モデルは本当に厳しい審査員です。 RAG 評価の比較 ナレッジベースの評価の結果は、それ自体では解釈が難しい場合があります。このため、コンソールでは複数の評価の結果を比較して違いを理解できます。これにより、関心のあるメトリクスが改善されているかどうかがわかります。 例えば、以前、他に 2 つのナレッジベースの評価を実行しました。これらは、同じデータソースを持つナレッジベースに関連していますが、チャンクと解析の設定が異なり、埋め込みモデルも異なります。 2 つの評価を選択し、 [Compare] (比較) を選択します。コンソールで比較できるようにするには、評価が同じメトリクスを対象とする必要があります。 [At a Glance] (概要) タブでは、スパイダーチャートを使用してメトリクスを視覚的に比較しています。この場合、結果はそれほど変わりません。主な違いがあるのは 忠実度 スコアです。 [Evaluation details] (評価の詳細) タブには、スコアの違いなど、各メトリクスの結果の詳細な比較が表示されます。 Amazon Bedrock Model Evaluation で LLM-as-a-judge (プレビュー) を使用する Amazon Bedrock コンソールでは、ナビゲーションペインの [Inference and Assessment] (推論と評価) セクションで [Evaluations] (評価) を選択します。 [Create] (作成) を選択した後、 Automatic: Model as a judge (自動: Model as a judge) オプションを選択します。 評価の名前と説明を入力し、評価メトリクスの生成に使用される 評価モデル を選択します。ここでは Anthropic の Claude 3.5 Sonnet を使います。 次に、評価したいモデルである [Generator model] (ジェネレータモデル) を選択します。モデル評価は、より小さく、より費用対効果の高いモデルがこのユースケースのニーズを満たしているかどうかを把握するのに役立ちます。ここでは Anthropic の Claude 3 Haiku を使います。 次のセクションでは、評価する メトリクス を選択します。 [Quality] (品質) セクションで [Helpfulness] (有用性) と [Correctness] (正確性) を選択し、 [Responsible AI metrics] (責任ある AI メトリクス) セクションで [Harmfulness] (有害性) を選択します。 [Datasets] (データセット) セクションでは、評価データセットが保存される Amazon S3 の場所と、モデル評価ジョブの結果が保存される S3 バケット内のフォルダを指定します。 評価データセット用に、別の JSONL ファイルを用意しました。各行には、プロンプトと参考用の回答が記載されています。形式はナレッジベースの評価とは異なることに注意してください。 {"prompt":"Write a 15 words summary of this text:\n\nAWS Fargate is a technology that you can use to run containers without having to manage servers or clusters.With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers.This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.","referenceResponse":"AWS Fargate allows running containers without managing servers or clusters, simplifying container deployment and scaling."} {"prompt":"Give me a list of the top 3 benefits from this text:\n\nAWS Fargate is a technology that you can use to run containers without having to manage servers or clusters.With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers.This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.","referenceResponse":"- No need to manage servers or clusters.\n- Simplified infrastructure management.\n- Improved focus on application development."} 最後に、Amazon Bedrock にこの評価ジョブで使用されるリソースへのアクセスを許可する IAM サービスロールを選択できます。 評価の作成が完了しました。数分後、評価が完了します。ナレッジベースの評価と同様に、結果は メトリクスの概要 から始まります。 生成メトリクスの内訳 には各メトリクスの詳細が記載されています。いくつかのサンプルプロンプトの詳細も見ることができます。評価スコアをよりよく理解するために、 有用性 を確認します。 評価のプロンプトはモデルによって正しく処理されており、その結果を自分のユースケースに適用できます。この評価で使用したものと同様のプロンプトをアプリケーションで管理する必要がある場合は、評価モデルが良い選択肢です。 知っておくべきこと これらの新しい評価機能は、次の AWS リージョン でプレビュー版として利用できます。 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ)、南米 (サンパウロ) での RAG 評価 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、ソウル、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ、チューリッヒ)、南米 (サンパウロ) での LLM-as-a-Judge 利用可能な評価者モデルはリージョンによって異なることに注意してください。 料金は、モデル推論用の標準的な Amazon Bedrock の料金 に基づいています。評価ジョブ自体に追加料金はかかりません。評価者モデルと評価対象モデルの請求は、通常のオンデマンド料金またはプロビジョニング料金に従って行われます。ジャッジプロンプトテンプレートは入力トークンの一部であり、透明性を高めるため、このようなジャッジプロンプトは AWS のドキュメントに記載されています。 評価サービスはリリース時点では英語コンテンツ向けに最適化されていますが、基盤となるモデルではサポート対象の他の言語のコンテンツも処理できます。 使用を開始するには、 Amazon Bedrock コンソール にアクセスしてください。詳細については、 Amazon Bedrock のドキュメント をご覧になり、 AWS re:Post for Amazon Bedrock にフィードバックを送信してください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。これらの新機能で何を構築するのか教えてくださいね! – Danilo 原文は こちら です。

本記事は 2024年11月27日に公開された ” Export AWS Migration Hub data for Import into AWS Application Migration Service ” を翻訳したものです。 AWS Application Discovery Service (ADS) は、AWS への移行準備としてサーバーを検出します。ADS は、 既存のソース からデータをインポートするか、サーバーのパフォーマンスとネットワーク通信データを収集する 検出エージェント 、または、 エージェントレスコレクター を展開することで、検出を実行します。収集されたデータは、 AWS Migration Hub に送られ、そこでサーバーをアプリケーショングループに分類することが可能です。移行の 準備フェーズ の重要な部分は、サーバーを 移行ウェーブ に分けること、および ADS によって観測されたパフォーマンスメトリクスに基づいて Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのレコメンデーションを取得することです。移行ウェーブは Migration Hub 内で構成可能です。 この投稿では、移行ウェーブを含む移行計画の構築方法、EC2 インスタンスのレコメンデーション取得、および Migration Hub からのデータのエクスポート方法を説明します。その後、 AWS Application Migration Service (AWS MGN) にデータをインポートする方法を紹介します。 ADS で収集されたデータは Migration Hub 内で整理され、AWS MGN で使用できるようエクスポートできます。AWS MGN は、AWS に移行するためのサービスです。移行元サーバーのデータを AWS にレプリケートし、移行元サーバーを Amazon EC2 インスタンスと Amazon Elastic Block Store ボリュームで AWS ネイティブに実行するように自動的に変換します。Migration Hub のデータを AWS MGN にインポートすると、指定されたアプリケーションとウェーブに従って移行を実行できます。AWS MGN が起動する Amazon EC2 インスタンスは、ADS のパフォーマンスメトリクスの情報を元に生成された Amazon EC2 インスタンスのレコメンデーションと一致します。 この投稿では、Migration Hub に収集されたデータがすでに存在することを前提としています。 サーバーを移行ウェーブごとにグループ化 移行ウェーブは、技術的および非技術的な依存関係を持つアプリケーションとインフラストラクチャの集まりで、同時にグループとして移行する必要があります。Migration Hub を使用すると、サーバーをアプリケーションにグループ化し、アプリケーションの集合体である移行ウェーブを定義できます。 以下の手順に従って移行ウェーブを作成してください。 Migration Hub 内の アプリケーション メニューから、ウェーブに割り当てたいアプリケーションを選択します 図 1 – Migration Hub のアプリケーションメニューのスクリーンショット、アプリケーションの選択を表示 選択したアプリケーションの鉛筆アイコンをクリックすると、Wave ID を入力できます。同じ Wave ID のすべてのアプリケーションは、AWS MGN 内の ウェーブ にまとめられます 図2 – Wave ID の編集画面のスクリーンショット Migration Hub からデータをエクスポートし、EC2 インスタンスのレコメンデーションを取得する Amazon EC2 インスタンスのレコメンデーション は、既存のパフォーマンス要件を処理できる最も安価な Amazon EC2 インスタンスタイプを選択するために使用されます。これらの推奨事項を生成するために使用されるデータは、ADS によって収集された実際の使用率メトリックス、または Migration Hub に手動でインポートされた詳細なパフォーマンス情報です。 以下の手順に従って Amazon EC2 インスタンスの推奨事項をエクスポートしてください。 Migration Hub 内の アプリケーション メニューから、EC2 インスタンスのレコメンデーションを生成したいアプリケーションを選択してください 図3 – Amazon EC2 インスタンスのレコメンデーションでアプリケーションを選択するスクリーンショット アクション メニューから「 EC2のレコメンデーションを取得 」を選択してください サイジングの設定 を選択してください。Discovery エージェント、またはエージェントレス コネクタを使用した場合は、時系列の利用率データに基づく 利用率のパーセンタイル を使用できます。 リージョン 、 テナンシー 、 料金モデル を選択してください 図4 – インスタンスのレコメンデーションの設定を選択するスクリーンショット エクスポートに含まれるサーバーやアプリケーションを追加したり削除したりすることができます エクスポートのレコメンデーション を選択して、エクスポートします zipファイルをダウンロードします。zipファイル内には2つのCSVファイルが含まれています。 EC2InstanceRecommendations-#### – EC2インスタンスのレコメンデーションが含まれています MgnInventory-#### – AWS MGN にインポートできるデータが含まれています AWS MGN にサーバー情報をインポート MgnInventory-#### CSVファイルは、AWS MGN にインポートできます。 アプリケーションの情報は AWS MGN 上のアプリケーションリソースに変換され、そのアプリケーションに属するすべてのサーバーがグループ化されます。ウェーブの情報は AWS MGN 上のウェーブリソースに変換され、そのウェーブに属するすべてのアプリケーションがグループ化されます。ウェーブとアプリケーションの両方で、AWS MGN を使うユーザーは複数のサーバーに対する一括操作を実行したり、移行の状況を集約して監視することができます。 残りの情報は EC2 起動テンプレートを設定するために使用され、テストとカットオーバーの目的で起動される Amazon EC2 インスタンスに適用されます。これにはインスタンスタイプとサブネットが含まれます。 VMware 固有の属性 ( vmname や vmmoref など) を移行した Amazon EC2 インスタンスにタグとして追加できるよう、「 サーバータグを転送 」を有効にすることができます。 次の CSV 内のフィールドに注意してください。 mgn:server:user-provided-id – 重複を避けるため、このフィールドの初期値は、Migration Hub 内の ホスト名 と サーバーID の連結になっています。この値は任意の値に変更できます。この ID は、AWS Replication Agent をインストールする際に使用する user-provided-id と 一致する必要 があります。 エージェントのインストール中、デフォルトの ID はソースサーバーのホスト名になります。インストールパラメーター –user-provided-id を使用すると、デフォルトの ID を上書きできます。インストールパラメーターの使用方法については、 Linux および Windows のインストール手順をご覧ください。 mgn:wave:name – このフィールドの値には、Migration Hub で構成したウェーブが含まれています。 mgn:launch:instance-type – このフィールドの値には、レコメンデーションされたインスタンスタイプが含まれています。 mgn:launch:nic:0:private-ip:0 – このフィールドの値は、移行されるサーバーの IP アドレスを設定するために使用されます。Migration Hub からのエクスポートでは、この値が AWS で同じ IP アドレスを使用するように移行元ソースサーバーの現在の IP アドレスに設定されます。移行されるサーバーが異なる IP 範囲の Amazon Virtual Private Cloud (Amazon VPC) に入る場合は、このフィールドを空白にする必要があります。 AWS MGN にデータをインポートするには、次の手順に従ってください。 AWS MGN の インポート メニューから ファイルを選択 をクリックし、Migration Hub からダウンロードした CSV ファイルをインポートします 図5 – AWS MGN のインポートメニューでファイルを選択するスクリーンショット Migration Hub からダウンロードした CSVファイルを選択します インポート を選択します インポート履歴 を使用して、インポート操作の状況を追跡できます Migration Hub のサーバーと ウェーブ構成、Amazon EC2 インスタンスタイプのレコメンデーションが AWS MGN に追加されました。 図6 – AWS MGN 内の Migration Hub からインポートされた「ウェーブ」のスクリーンショット まとめ AWS Migration Hub と AWS Application Discovery Service (ADS) は、AWS への移行の調査、計画、実行に利用できます。ADS は、Amazon EC2 インスタンスタイプのレコメンデーションに重要なパフォーマンスメトリクスを収集するために使用できます。Migration Hub は、サーバーをアプリケーションとウェーブにグループ化することができ、一緒に移行する必要があるアプリケーションを定義します。調査・計画時に収集したデータに基づいて生成された Amazon EC2 インスタンスのレコメンデーションをエクスポートすることで、移行の実行フェーズに反映させることができます。エクスポートされたデータは、移行サービスの AWS Application Migration Service (AWS MGN) に直接インポートできる形式になっています。AWS MGN は、Migration Hub からのエクスポートに従って、アプリケーション、移行ウェーブ、インスタンスタイプの設定を行います。 Migration Hub と AWS Application Migration Service の機能についてさらに詳しく知りたい方は、ぜひ公式ドキュメントを確認してみてください。 著者について Peter Giuliano Peter Giuliano は、AWSのシニア・マイグレーション・ソリューション・アーキテクトで、オンプレミスおよびクラウドインフラストラクチャで20年以上の経験を持っています。AWSでは、お客様がクラウドへの大規模な移行を計画し実行するのを支援し、お客様の経験と教訓が共有されるよう努めています。仕事以外では、ランニングが趣味で、新しい場所を旅行するのが好きです。 この記事の翻訳はソリューションアーキテクトの須山健吾が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 あけましておめでとうございます。本年も週刊生成 AI with AWS と、週刊 AWS をよろしくお願いいたします。 1 月に入り AWS 公式ウェブマガジン、builders.flash の記事が公開されていますので生成 AI に関係するものをピックアップしてみます。精度評価・信頼性・セキュリティ・高度な RAG 構築などの実用的なテクニックが記載されていますので興味に合わせてご覧ください。 Amazon Bedrockを用いた掲示板投稿監視システムの実現~株式会社ゲームエイトによる生成AI実装解説 (株式会社ゲームエイト様) AI技術で高校生の未来を支援する『AI-m（エイム）』~面接練習の革新 (株式会社マイナビ様) 生成AIセキュリティの歩き方 Amazon Bedrock Knowledge Basesでもサポート開始(preview)した噂のGraphRAGとは一体なんなのか?! それでは、1 月 6 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 三協立山株式会社様、生成 AI アシスタントを１か月でリリースし議事録作成時間を 75% 削減 三協立山株式会社様 は、生成 AI 活用による生産性向上を目的とした社内向けサービス 「AI ふたば」を展開していました。プログラミングなどの一部の業務で活用されていた一方で、業務での活用シーンが不明確であることや、RAG が導入されていないことなどの理由から、会社全体での活用が進まないという課題を抱えていました。そこで、上記の課題解決に向けて Generative AI Use cases JP (以下、GenU) の導入を検討しました。GenU をカスタマイズし、業務での活用シーンに即した 50 パターンほどのプロンプトテンプレートを導入したことで社内の利用者が 1.5 ～ 2 倍程度拡大したそうです。さらに当初から要望の多かった議事録作成機能をリリースしたことで、年間で 1 万 5000 時間の業務時間削減効果が見込まれています。 ブログ記事「Amazon Nova のご紹介: フロンティアインテリジェンスと業界をリードする料金パフォーマンス」を公開 昨年の 12 月 3 日に、 Amazon Bedrock で利用可能な基盤モデル (FM) である Amazon Nova を発表しました。Amazon Nova は最先端のインテリジェンスと業界トップクラスの価格パフォーマンスを実現します。この記事では、Amazon Nova のそれぞれのモデルの特徴・プロンプト例・呼び出し方例を紹介しています。 サービスアップデート Amazon Q Developer が Amazon SageMaker Code Editor IDE で利用可能に Amazon SageMaker Studio をご利用のお客様は、Code Editor（Visual Studio Code）IDE 内で Amazon Q Developer による生成AI アシスタンスを利用できるようになりました。Q Developer を使用することで、トラブルシューティングに関するガイダンスを得たり、コード生成を行ったりすることが可能になり、機械学習開発プロセスの効率化が期待できます。この機能は、SageMaker Studio が利用可能なすべての AWS リージョンでご利用いただけます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

本ブログは 2025 年 1 月 8 日に公開された「 New AWS Skill Builder course available: Securing Generative AI on AWS 」を翻訳したものとなります。 Amazon Web Services（AWS） 上での生成 AI ワークロードをセキュアにするためにお客様をサポートする、新しい AWS Skill Builder コース「 Securing Generative AI on AWS 」の提供開始をお知らせします。 この包括的なコースは、セキュリティの専門家、アーキテクト、人工知能および機械学習（AI/ML）エンジニアが AWS クラウド上の生成 AI アプリケーションおよびモデルのセキュリティのベストプラクティスを理解し、実装するための助けとなるを目的としています。 AWS Skill Builder は、AWS のお客様およびパートナーがデジタルトレーニング、セルフペースラボ、その他のコースタイプを通じてクラウドスキルを構築するための学習センターです。AWS Skill Builder には、お客様が AWS セキュリティの概念を理解し、実践的な経験を得るための様々な AWS セキュリティコンテンツがあります。 コースのハイライトは以下の通りです（訳者注：コンテンツは英語となります）。 生成 AI セキュリティスコープマトリックスの紹介 – この革新的なフレームワークを使用して、異なる AI 実装を分類し、保護する方法を学びます。 主要な AI セキュリティフレームワークのカバレッジ – OWASP Top 10 for Large Language Models (LLMs) と MITRE ATLAS フレームワークについての洞察を得ます。 実践的なセキュリティ戦略 – 様々な AI のスコープにおけるガバナンス、法律、リスク、コントロール、レジリエンスの分野にわたる包括的なセキュリティを実装するスキルを開発します。 実世界での応用 – コンシューマアプリケーション、エンタープライズソリューション、事前学習済みのモデル、ファインチューニングされたモデル、自身で学習したモデルをカバーするケーススタディにセキュリティのコンセプトを適用します。 コースを受講するには 無料の AWS Skill Builder アカウントにサインアップします。 コースカタログで「Securing Generative AI on AWS」を検索します。 コースに登録して学習を始めましょう！ 補足情報 生成 AI セキュリティに関するさらなる情報については、以下のブログシリーズをご確認いただくことをお勧めします。 生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介（日本語） 生成 AI をセキュアにする: 関連するセキュリティコントロールの適用（日本語） 生成 AI をセキュアにする: データ、コンプライアンス、プライバシーに関する考慮点（日本語） 私たちは皆さまのフィードバックや貢献を大切にしています。コースを完了した後にご意見や洞察があれば、コースのフィードバックから、または AWS サポート にお問い合わせください。 Anna McAbee Anna は、AWS で金融サービス、生成AI、インシデント対応にフォーカスしたセキュリティスペシャリストソリューションアーキテクトです。仕事以外では、テイラー・スウィフトを楽しみ、フロリダ・ゲイターズ・フットボールチームを応援し、NFL を観戦し、世界中を旅することを楽しんでいます。 Pablo Roesch Pablo は、AWS のテクニカルシニアプロダクトマネージャーで、セキュリティおよびクラウド運用トレーニングポートフォリオを管理しています。彼は生成 AI を活用してコース開発と市場投入戦略を革新し、技術的専門知識とイノベーティブなアプローチを組み合わせています。Pablo は、パッケージ化された仮想マシンアプリケーションとの外部通信（US 11,7973,26 B2）の特許を保有しており、クラウドおよび仮想化技術における彼の専門知識を反映しています。 Meg Peddada Meg は 10 年以上の経験を持つシニアセキュリティソリューションアーキテクトで、セキュリティ、リスク、コンプライアンスを専門としています。彼女の専門知識はガバナンス、セキュリティ自動化、脅威管理、アーキテクチャに及びます。余暇には、バレーボール、アートとクラフト、新しいブランチ体験を見つけることを楽しんでいます。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 私は年初に趣味のパデルの大会に出て、リフレッシュしてきました。みなさんはどんな年末年始を過ごされましたか？ 今年も新たな機能が追加されていってますね。それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月6日週の主要なアップデート 1/7(火) Amazon DynamoDB now supports configurable point-in-time-recovery periods Amazon DynamoDB では、ポイントインタイムリカバリ (PITR) の期間を設定できるようになりました。PITR を使用したデータリカバリの期間をテーブル単位で 1～35 日の範囲で指定できます。PITR は、DynamoDB のデータを偶発的な書き込みや削除から保護し、リカバリ期間内の任意の秒数までデータをリストアすることができます。 これにより、バックアップのリカバリ期間を設定することで、データリカバリ期間を短縮する必要があるコンプライアンスや規制要件を満たすことができます。 Announcing 20 additional AWS Systems Manager Automation runbook recommendations in AWS Chatbot AWS は、AWS Chatbot のイベント通知のコンテキストアクションボタンとして、AWS Systems Manager Automation で20 個の推奨ランブックの一般提供を発表しました。 このリリースにより、お客様は Microsoft Teams や Slack チャネルから AWS Systems Manager オートメーションを実行し、AWS Security Hub や Amazon ECS 関連のイベントに対処できるようになります。詳細は、AWS Chatbot の ドキュメント または AWS Chatbot の製品ページ を参照してください。 1/8(水) Amazon Q Developer is now available in Amazon SageMaker Code Editor IDE Amazon SageMaker は、SageMaker Studio コードエディタにおける Amazon Q Developer の一般提供を発表しました。 SageMaker Studio の顧客は、コードエディター (Visual Studio Code – オープンソース) IDE 内で、Q Developer によるジェネレーティブ AI アシスタンスを利用できるようになりました。 Q Developer を使用することで、データサイエンティストと ML エンジニアは、SageMaker の機能、コード生成、トラブルシューティングに関する専門家のガイダンスにアクセスできます。 これにより、退屈なオンライン検索やドキュメントレビューの必要性がなくなり、差別化されたビジネス価値を提供する時間を確保できるため、生産性が向上します。 Amazon Connect Contact Lens now provides free trials for conversational analytics and performance evaluations Amazon Connect Contact Lens は、会話分析とパフォーマンス評価を初めて利用するユーザー向けに無料トライアルを提供するようになりました。 音声用会話アナリティクスを初めてご利用になるお客様には、最初の 2 ヶ月間、月間 10 万分の音声通話を無料でお試しいただけます。 さらに、初めて Contact Lens のパフォーマンス評価を使用する顧客には、最初のパフォーマンス評価を提出した日から 30 日間の無料トライアルが提供されます。 1/9(木) AWS Compute Optimizer now expands idle and rightsizing recommendations for Amazon EC2 Auto Scaling groups AWS Compute Optimizer は、スケーリングポリシーと複数のインスタンスタイプを持つAmazon EC2 Auto Scaling グループに、アイドル状態と適切なサイズ調整の推奨事項を追加しました。 新しい推奨事項により、スケーリングポリシーや複数のインスタンスタイプを使用している Auto Scaling グループのコストとパフォーマンスを最適化するためのアクションを、専門的な知識やエンジニアリングリソースを必要とせずに実行できるようになります。 1/10(金) AWS CodeBuild now supports batch builds with reserved capacity and Lambda compute AWS CodeBuild は、バッチビルド機能を拡張し、リザーブドキャパシティフリートおよび Lambda コンピューティングのサポートを追加しました。この機能拡張により、ビルドバッチに対してオンデマンドインスタンス、リザーブドキャパシティフリート、Lambda コンピューティングリソースを組み合わせて選択できるようになります。バッチビルドでは、1 つのプロジェクト内で複数のビルドを同時に実行し、それらを調整することが可能です。この機能は、マルチプラットフォームプロジェクトや相互依存するビルドプロセスを持つ開発者に特に有用です。ビルドシーケンスは、ビルドリスト、ビルドマトリックス、または依存関係グラフを使用して定義できます。CodeBuild はこれらのビルドのオーケストレーションを管理し、開発と統合プロセス全体を効率化します。 Amazon Connect Contact Lens launches agent performance evaluations for email contacts Amazon Connect Contact Lens は、メールコンタクトに対するエージェントのパフォーマンス評価機能をリリースしました。この新機能により、マネージャーは Amazon Connect 内でメールを含むすべてのコンタクトチャネル（音声、チャット、メール、タスク）におけるエージェントのパフォーマンスを、使いやすい単一のウェブインターフェースで評価できるようになりました。また、エージェントグループ全体のパフォーマンスを時系列で集約した洞察も得られます。 インフルエンザも流行っているので、みなさんも体調には気をつけてください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本ブログは 2024 年 12 月 17 日に公開された「 How DeNA Co., Ltd. accelerated anonymized data quality tests up to 100 times faster using Amazon Redshift Serverless and dbt 」を翻訳したものです。 本ブログは 株式会社ディー・エヌ・エー（以下 DeNA ） と Amazon Web Services Japan が共同で執筆しました。 DeNA は「一人ひとりに想像を超える Delight を」というミッションのもと、ゲーム、ライブコミュニティ、ヘルスケア・メディカル、スポーツ・スマートシティ、モビリティなど多岐にわたる事業を展開しています。中でもヘルスケア・メディカル事業では、機密性の高いデータを扱っており、同社のデータポリシーに準拠するためにデータ処理に関して以下の要件を設定しています： データポリシーに準拠したデータ処理 – 必要に応じて機密性の高いデータをマスキングや削除を行い、匿名化データに変換します。加えて区分値に無効な値が含まれないようにするなど、的確且つ損失なくデータの処理を行います。 データポリシーに準拠した匿名化データの品質テスト – 加工後のデータ品質問題を迅速に特定し対処するため、データ品質テストを実施して高品質なデータを常に維持します。 本ブログでは、DeNA が Amazon Redshift Serverless と dbt ( dbt Core ) を組み合わせて、匿名化データの品質テストを高速化した事例をご紹介します。なお、本取り組みについては DeNA Engineer Blog にも記載があります。そちらも併せて参考いただけると幸いです。 解決したい課題 データ品質テストは、毎月 10 TB のデータに対して 1,300 件のテストを実施する必要があります。今までデータ品質テストは AWS 上の Amazon Elastic Compute Cloud (Amazon EC2) で Python で実装されたバッチジョブを実行して行ってきました。しかし、事業とデータ量の拡大に伴い、以下の課題に直面しました。 パフォーマンス – エンジニアがビッグデータ処理を想定してバッチを設計していなかったため、データ品質テストの完了に数日から数週間を要していました。 コスト – 特に大規模なデータセットに対して、バッチの設計によりコストが増加しました。実装上、データをメモリにロードして処理する必要があり、大規模なテーブルのデータを扱う際には、メモリ容量が大きな EC2 インスタンスを利用する必要がありました。 保守性 – バッチの実装がエンジニアごとに大きく異なり、保守に必要な知識が属人化していたため、保守のコストが増大していました。 Redshift Serverless と dbt への移行 これらの課題を解決するため、DeNA は以下の理由から Redshift Serverless と dbt (オープンソースのデータ変換ツール) を採用しました。主な理由は以下の通りです：  Redshift Serverless によりスケーラブルでコスト効率の高い処理が可能  dbt により利用技術を標準化して運用がしやすいデータ品質テストの実装が可能 この決定は様々なソリューションを比較検討した結果なされました。当初 DeNA は既存の Python バッチジョブを並列化することを検討しました。しかし、現時点で保守負荷が高く改修が難しい Python バッチに手を入れるのは工数が多くかかり、また属人化による高い保守負荷を解決することにはつながらないため、採用を見送りました。代わりに、ヘルスケア・メディカル事業で利用している dbt を採用し、大規模な分散処理が可能な AWS のサービスと組み合わせて利用することを決定しました。dbt は SQL 中心のテンプレートエンジンで、反復的で拡張可能なデータ変換を SQL と Python で記述することができます。dbt には data tests という、SQL を利用してデータモデルやテーブルが期待されるルールや条件に従っているかを検証するテスト機能があり、データの整合性や制約違反を検出してデータ品質を高めることができます。この機能を利用することで、事業における利用技術を統一化することができ、運用性や汎用性の高い SQL を利用してデータ品質テストを実装することができます。また dbt を大規模分散処理が得意なマネージドサービスに接続することで、コスト効率を向上させながら処理を高速化できると考えました。 AWS は dbt を接続してデータを処理できるサービスとして、 Amazon Redshift や  AWS Glue などを提供しています。今回 DeNA は Redshift Serverless を採用しました。主な採用理由は、サーバーレスによる低い運用負荷と高いコストパフォーマンスに加え、データウェアハウスサービス特有の構造化されたデータへの優れた処理パフォーマンスです。 ソリューションの概要 DeNA は以下のアーキテクチャを設計しました。コスト効率や運用性の観点で、すべてのコンポーネントをサーバーレスで構築しました。 設計のポイント データ品質テストの対象となるデータは Amazon Simple Storage Service (Amazon S3) に配置されるため、配置をトリガーに Amazon EventBridge 経由で AWS Step Functions の ステートマシン (ワークフロー) を起動しました。1種のデータで複数のファイルが提供されるため、すべてのファイルの配置が完了したことを確認できるように、提供元のシステムから完了を示すファイルを Amazon S3 に配置するようにしました。 dbt は AWS のサーバーレスコンテナサービスである AWS Fargate を利用して Amazon Elastic Container Service (Amazon ECS) 上で実行するようにしました。Amazon ECS を採用した理由は、サーバーレス且つ従量課金で dbt を実行でき、過去 DeNA で Amazon ECS を利用したアプリケーションの開発・運用経験があったためです。また dbt が実行されるコンテナ上から Redshift Serverless に安全にアクセスできるようにするため、DeNA は コンテナに機密データを渡す Amazon ECS の機能 を使用し、AWS Secrets Manager に保存された接続のためのクレデンシャルを ECS タスク実行 IAM ロール を使用してコンテナに渡しました。 アクセス制御のため Redshift Serverless を制御の境目で別々の ワークグループ に分離しました。ワークグループはコンピューティングリソースの集合で、アクセス制御などのセキュリティ設定も含まれます。データ品質テストでは、データ品質の問題を調査するなどの運用の観点から運用者が実際に Query Editor V2 を利用して Redshift Serverless 上のデータベースにアクセスすることがあります。しかし扱っているデータの機密性が高いため、限定された人のみアクセスできるようにする必要があります。Redshift Serverless は データベースセキュリティ機能 を利用することで、データベース製品と同じように GRANT コマンド を利用して細かくデータへのアクセス制御を行うことが可能です。しかし今回は AWS Identity and Access Management (IAM) の機能を利用して、ワークグループへの 接続を IAM レベルで制御しました 。これにより、特定の IAM ロールを持つ人は特定の Redshift Serverless ワークグループへのアクセスに制限することができるようになり、IAM で認可の管理が統一的にできるようになりました。またワークグループを分離したことによって、処理で必要とする計算リソースである RPU (Redshift Processing Unit) を個別に調整することができ、コスト最適化にも寄与しました。 Amazon ECS 上で実行される dbt のログは Amazon CloudWatch Logs に送信されます。DeNA は メトリクスフィルター を利用してログを CloudWatch メトリクス に変換し、これらのメトリクスに基づいてアラームを作成しました。トリガーされたアラームは、 Amazon Simple Notification Service (Amazon SNS) を使用して AWS Lambda の関数を呼び出します。この Lambda 関数は、dbt の実行とデータ品質テストの結果レポートを作成し、DeNA 内部のチャットアプリケーションに送信します。DeNA はデータ品質テストの結果を elementary CLI を利用して可視化しました。elementary CLI は dbt ネイティブなデータオブザーバビリティソリューションで、dbt と連携してデータの状態を可視化することが可能です。これにより、エンジニア以外のユーザーでもデータ品質テストの状況を効率的に確認できるようになりました。 導入効果 DeNA はソリューションを設計して新しいプラットフォームに移行することで、直面していたすべての課題を解決することができました： パフォーマンス – 数日または数週間掛かっていた処理時間を 1~2 時間に短縮し、最大 100 倍の高速化を実現しました。以前は 877 分かかっていた特定のデータ品質テストが、Redshift Serverless の大規模分散処理機能により、現在では 1 分で完了できるようになりました。 コスト – 90% のコスト削減を実現できました。サーバーレスサービスで構築したため、データ品質テスト実行中のみのコスト発生となり、コスト圧縮を実現することができました。 保守性 – dbt による利用技術の標準化により、実装の属人化を無くすことができました。dbt の data tests 機能により、データ品質テストの実装が簡素化されました。elementary CLI により、エンジニア以外のユーザーにもデータ品質テストのオブザーバビリティが向上しました。AWS のサーバーレスサービスにより、ワークロードのインフラを管理するための運用コストがほぼゼロになりました。 まとめ 本ブログでは、DeNA が Redshift Serverless と dbt を組み合わせることで、データ品質テストを安全かつ効率的に加速できた事例をご紹介しました。この組み合わせは、DeNA のユースケースだけでなく、さまざまな業界における多様なビジネスユースケースにも適用可能です。 Redshift Serverless と dbt の組み合わせについて詳しくは、以下のリンクを参照ください。 dbt CLI and Amazon Redshift Manage data transformations with dbt in Amazon Redshift Implement data warehousing solution using dbt on Amazon Redshift Best Practices for Leveraging Amazon Redshift and dbt 著者について Momota Sasaki は、DeNA の主要子会社である DeSC ヘルスケア株式会社のエンジニアリングマネージャーです。彼は 2021 年に DeNA に入社し、DeSC ヘルスケア株式会社に出向しました。それ以来、一貫してヘルスケア事業に携わり、データプラットフォームの開発と運用をリードし、推進しています。 Kaito Tawara は、DeNA の主要子会社である DeSC ヘルスケア株式会社のデータエンジニアで、ヘルスケア事業のデータプラットフォームの改善に注力しています。ウェブシステムのバックエンド開発とデータサイエンスの経験を積んだ後、データエンジニアリングに転向しました。2023 年に DeNA に入社し、 DeSC ヘルスケア株式会社に出向しました。現在は名古屋市からリモートで勤務し、ヘデータプラットフォームの強化に貢献しています。 Shota Sato は、AWS Japan のアナリティクススペシャリストソリューションアーキテクトです。デジタルネイティブビジネスを行う顧客向けに AWS を活用したデータ分析ソリューションの提案を行っています。 このブログの翻訳はソリューションアーキテクトの佐藤 祥多が担当しました。

1 月 7 日、3 つのアベイラビリティーゾーンと API 名 ap-southeast-7 で、AWS アジアパシフィック (タイ) リージョンの一般提供を開始したことをお知らせいたします。 AWS アジアパシフィック (タイ) リージョンは、タイ初のインフラストラクチャリージョンであり、香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、および東京の既存のリージョン、ならびに中国の北京および寧夏リージョンに加わり、アジアパシフィックで 14 番目のリージョンとなります。 ルンピニ公園は、バンコク中心部にある 142 エーカーに及ぶ最大の緑地の 1 つです。 タイでは、進化するビジネスニーズと Thailand 4.0 などの政府のイニシアティブにより、クラウドコンピューティングの導入が急速に進んでいます。これらのイニシアティブは、新興テクノロジーを利用して、生産性を高め、競争力を強化し、持続可能な成長を推し進めることで、タイをイノベーションドリブンの経済に変革することを目指しています。 この新しい AWS リージョンは、スタートアップ、企業、政府機関、教育機関、非営利団体が、タイ国内にデータレジデンシーを維持しながら、アプリケーションを実行し、エンドユーザーにサービスを提供できるようサポートします。これは、タイのデジタルトランスフォーメーションの目標およびクラウドサービスの需要の高まりに資するものです。今後 15 年間で、Amazon Web Services (AWS) が計画しているタイにおける投資は、タイの国内総生産 (GDP) に 100 億 THB 貢献し、タイの現地企業で年間平均 11,000 人のフルタイム当量 (FTE) の雇用を支えると推定されています。 タイでの AWS の存在感の高まり タイでの当社の取り組みは、2013 年にバンコクに最初の AWS オフィスを開設したことから始まりました。それ以来、AWS はタイ国内でインフラストラクチャとサービスを継続的に拡大してきました。 Amazon CloudFront – 2020 年以降、AWS はタイ全土に 6 つの Amazon CloudFront エッジロケーションを設けました。これらのエッジロケーションは、非常に安全でプログラム可能な AWS コンテンツ配信ネットワーク (CDN) の一部であり、低レイテンシーと高速転送で、世界中のユーザーに対するデータ、動画、アプリケーション、API の配信を加速するように設計されています。 AWS Outposts – 同じ 2020 年に、AWS はタイ市場に AWS Outposts を導入しました。フルマネージドソリューションである AWS Outposts は、AWS インフラストラクチャとサービスをほぼすべてのオンプレミスまたはエッジロケーションで利用できるようにし、真に一貫したハイブリッドエクスペリエンスを実現します。このサービスは、低レイテンシー、ローカルデータ処理、またはローカルデータストレージを必要とするワークロードに特に役立ちます。 AWS Local Zones – 2022 年、AWS はバンコクでの AWS Local Zones の立ち上げを通じて、タイへの取り組みを強化しました。このインフラストラクチャデプロイにより、コンピューティング、ストレージ、データベース、および他の厳選されたサービスが、人口の多い場所、産業、IT センターのより近くで提供されるようになります。その結果、お客様は 1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに提供できます。 AWS Direct Connect – AWS は、接続オプションを強化するために 2023 年にバンコクに AWS Direct Connect ロケーションを設け、AWS アジアパシフィック (タイ) リージョンの立ち上げに合わせて新しい AWS Direct Connect ロケーションを追加しました。お客様は AWS Direct Connect を利用して、AWS リソースへの安全な専用ネットワーク接続を確立し、ネットワークパフォーマンスを改善するとともに、帯域幅コストを削減できます。 タイにおける AWS のお客様の成功事例 タイの組織は、イノベーションと変革を推進するために弊社のサービスを利用しています。例をいくつかご紹介します。 2C2P タイを拠点とする大手 FinTech スタートアップである 2C2P は、堅牢なセキュリティ機能を理由として AWS を選択しました。東南アジアのオムニチャネル決済サービスプロバイダーである同社は、暗号キー管理のために AWS CloudHSM、分散型サービス拒否 (DDoS) からの保護のために AWS Shield、機密性の高い認証情報を保護するために AWS Secrets Manager を利用して、世界中で何百万もの顧客決済を処理しています。 「AWS を通じて、安全かつ動的に、コンプライアンスに準拠してスケールし、決済取引量の急増に対応できるようになりました。AWS CloudHSM は、コンプライアンス要件を満たし、ビジネスの拡大を加速させる上で重要な役割を果たしています」と 2C2P の Chief Technology Officer である Myo Zaw 氏は述べています。 aCommerce 東南アジア最大級の e コマースイネーブラーである aCommerce は、AWS で生成 AI を活用した機能である AskIQ をリリースし、マーケットインテリジェンスに革命をもたらしました。この Software as a Service (SaaS) プラットフォームは、東南アジア最大級の e コマースサイト全体で、競合他社およびカテゴリについての包括的なパフォーマンス追跡機能を世界有数のブランドに提供します。 aCommerce Group の VP of Data Products である Leena Chanvirach 氏は、AWS とのコラボレーションの戦略的価値を強調しています。「AWS とのコラボレーションにより、クライアントはコアコンピテンシーとビジネス上の優先事項に注力できます。この両方の長所を兼ね備えたアプローチにより、ブランドは社内で高度なデータインフラストラクチャを構築および維持する負担なしに、競争上の優位性を獲得できます」。 Ascend Money 東南アジアの先駆的な FinTech 企業である Ascend Money は、特定のワークロードでアプリケーションパフォーマンスを最大 40% 改善しながら、コンピューティングコストを 70% 削減できました。Ascend Money は、Amazon EC2 インスタンスを使用して高度なコンピューティング戦略を実装し、運用を大幅に改善しました。 「AWS によって当社のパフォーマンスが大幅に改善され、より革新的なサービスをお客様に提供できるようになりました」と Ascend Money の Head of Technical Operations である Peerawit Phuangkaeo 氏は述べています。 ともにクラウドスキルを構築 AWS は、タイでクラウド教育とスキル開発のための包括的なプログラムを構築し、2017 年以降、50,000 人を超える個人にクラウドスキルのトレーニングを提供してきました。プログラムの一部は次のとおりです。 AWS Skill Builder AWS Skill Builder は、AWS のエキスパートから学び、クラウドスキルをオンラインで構築できるオンライン学習センターです。AWS は、600 を超えるコース (タイ語で提供されるコースは 106 あります) を提供することで、タイの学習者がクラウド教育をより利用しやすくしました。最近立ち上げられた Amazon AI Ready イニシアティブにより、特に成長している AI 分野での学習機会がさらに拡大しました。 AWS Educate 2016 年に提供が開始されてから、AWS Educate はタイの教育に変革をもたらしてきました。このプログラムは、タイ全土の教育カリキュラムにクラウドコンピューティングをうまく統合し、AWS リソースへの直接アクセスとハンズオンエクスペリエンスを学生に提供しています。その影響は大きく、20,000 人を超えるタイの学生がこのプログラムに登録しています。学生の教育を超えて、AWS Educate はタイの教育者のトレーニングに投資し、学生がデジタル経済の需要に対応できるようにするための、魅力的かつ実用的なクラウドコンピューティングコースを、これらの教育者が提供できるようにサポートしています。 AWS Academy 2017 年にタイで提供が開始されてから、AWS Academy は、学術的な学習と業界のニーズを結び付ける上で重要な役割を果たしてきました。国内の 30 を超える先駆的な大学やカレッジとの戦略的パートナーシップを通じて、AWS Academy は、クラウドスキルを備えたプロフェッショナルの強力なパイプラインを構築しました。このプログラムは、業界のニーズに合わせた包括的なクラウドコンピューティングカリキュラムを教育機関に提供し、すぐに仕事で用いることのできる実践的なスキルを学生が身につけて卒業できるようにします。 これらのさまざまなイニシアティブとプログラムを通じて、AWS は教育リソースを提供するだけでなく、クラウドテクノロジーを効果的に利用するために必要なスキルをワークフォースに身につけさせるのをサポートすることで、タイのデジタルの未来の基盤を構築しています。 タイにおける持続可能なイノベーションのサポート AWS の持続可能性への取り組みは、環境イニシアティブを推進しているタイの革新的な企業のサポートにも及びます。 BODA Technology & Consultancy AWS を活用した持続可能性のスタートアップである BODA は、エネルギー効率の最適化を実現するために、AWS IoT Core を利用して AI を活用したソリューションを開発しています。同社は、タイ全土の 100,000 を超える建物や工場の運用を成功裏に改善し、コストや環境への影響を抑えながら、これらの施設が効率を最大限に高められるようにしました。 GSPC Group タイの持続可能かつ先駆的な電力会社である GSPC Group を見れば、AWS がエネルギー部門のデジタルトランスフォーメーションをどのようにサポートしているのかを知ることができます。Global Power Synergy Public Company と Glow Energy の合併後、同グループは、太陽光発電所の運用を移行するために AWS クラウドを選びました。AWS および AWS パートナーである Dailitech と連携して、GSPC Group は、クラウドに移行してから、ハードウェア、ソフトウェア、ライセンスのコストを 20～25% 削減できました。 知っておくべきこと タイの AWS コミュニティ – タイには、2 人の AWS ヒーロー、7 人の AWS コミュニティビルダー、17,000 人を超える AWS User Group のメンバーがいます。AWS User Group Thailand への参加にご興味がある場合は、同グループの Facebook ページにアクセスしてください。 AWS のグローバル展開 – AWS は現在、世界中の 35 の地理的地域内の 111 のアベイラビリティーゾーンでサービスを提供しています。当社は、ドイツ、台湾、メキシコ、サウジアラビア王国、ニュージーランドにおいて、さらに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンを追加する計画を発表しました。 新しいアジアパシフィック (タイ) リージョンは、お客様のビジネスをサポートする準備ができています。詳細については、「 AWS グローバルインフラストラクチャ 」のページにアクセスしてください。そして、 ap-southeast-7 で構築を開始しましょう。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

明けましておめでとうございます! 私たちは、テクノロジーがインスピレーションに富む方法で人間の創意工夫を強化するのを目の当たりにしています。今後数年間、好ましい影響をもたらすためにテクノロジーを利用することで、成功についての考え方が再定義されるでしょう。Amazon の CTO であるワーナー ヴォゲルス博士は、2025 年以降について、将来を見据えたテクノロジーに関する 5 つの予測を提示しています: 明日のワークフォースはミッションドリブンである エネルギー効率の新しい時代がイノベーションを推進する テクノロジーが真実の発見に大きな役割を果たす オープンデータが分散型災害対策を推進する 意図駆動型の消費者向けテクノロジーが定着する ワーナー ヴォゲルスの 「Tech Predictions for 2025 and Beyond」eBook をダウンロードするか、またはワーナーの All Things Distributed ブログ を読み、これらのテクノロジーのトレンドが世界をどのように形作り、より革新的かつ効率的で目的のある未来への道を切り拓いているかについて詳しく学んでください。 AWS re:Invent 2025 の動画と re:Caps re:Invent での発表を知りたい場合や、最新の AWS イノベーションについてさらに詳しく知りたい場合は、次のようないくつかのオプションをご利用いただけます: 基調講演、イノベーショントーク、ブレイクアウトセッション をオンデマンドで視聴する。 主要な AWS re:Invent の発表の概要をダウンロードする。 世界中の AWS ユーザーグループ のボランティアが主催する、 実地で開催される無料コミュニティである re:Cap のセッション に参加する。 過去数週間のリリース 2024 年 12 月 16 日の 前回の Weekly Roundup 以降の、年末そして先週からのリリースをいくつか取り上げたいと思います。 Amazon SageMaker JumpStart と Amazon Bedrock で Llama 3.3 70B が利用可能に – Meta の Llama 3.3 70B は、モデルの効率性とパフォーマンスの最適化における大きな進歩を体現しています。Llama 3.3 70B は、テキストのみのアプリケーションのために使用される場合、 Llama 3.1 70B および Llama 3.2 90B と比較してより優れたパフォーマンスを発揮する、テキストのみのインストラクションチューニングモデルです。 Amazon SageMaker JumpStart と Amazon Bedrock の両方でこのモデルを使用できるようになりました。 Amazon Bedrock で Stable Diffusion 3.5 Large が利用可能に – Stability AI が提供する Stable Diffusion 3.5 Large は、 Amazon SageMaker HyperPod でトレーニングされた 81 億のパラメータを備えた、Stable Diffusion ファミリーで最も強力なモデルです。 Amazon Bedrock で Stable Diffusion 3.5 Large を使用して、テキストの説明から質の高い画像を生成できるようになりました。 Apache Flink 用の新しい Amazon Kinesis ソースコネクタ – Apache Flink コミュニティは、AWS オープンソースコントリビューションである AWS サービスコネクタのバージョン 5.0.0 をリリースしました。このリリースでは、以前の Kinesis Consumer に代わる、 Amazon Kinesis Data Streams からデータを読み取るための新しいコネクタである Kinesis Streams Source が導入されています。 Amazon WorkSpaces Personal での AWS Global Accelerator のサポート – Amazon WorkSpaces Personal は、 AWS Global Network とエッジロケーション を通じてストリーミングトラフィックを最適化することで WorkSpaces 接続パフォーマンスを強化するために、 AWS Global Accelerator (AGA) と統合するようになりました。この機能は、WorkSpaces に遠距離で接続するエンドユーザーを抱えるお客様に特に役立ちます。AGA 機能は、WorkSpaces ディレクトリレベルで有効にすることも、 Amazon DCV プロトコル を実行する個々の WorkSpaces のために有効にすることもできます。 AWS Resource Explorer の新しいリソースインサイト – 強化された Resource Explorer エクスペリエンスにより、 サポートされているリソースタイプ のために、複数の AWS サービスからの関連データとインサイトが一元化されます。新しい機能を使用すると、タグの管理、アプリケーションへのリソースの追加、 Amazon Q を使用した、リソースに関する追加情報の取得など、Resource Explorer コンソールから直接リソースに対するアクションを実行できます。 AWS Billing and Cost Management でのカスタム請求ビューの一般提供の開始 – カスタム請求ビュー を使用すると、 AWS 管理アカウント へのアクセスを付与することなく、 AWS Cost Explorer の単一のビューを使用して、複数の AWS アカウントにわたる関連コスト管理データへのアクセスを、アプリケーションおよびビジネスユニットの所有者に提供できます。コスト配分タグまたは特定の AWS アカウントに基づいて、コスト管理データのフィルタリングされたビューを作成できます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS at CES 2025 (1 月 7～10 日) – AWS は、自動車、モビリティ、輸送、製造の各業界向けに特別に構築された最新のクラウドサービスおよびソリューションのいくつかをご紹介します。 Amazon Experience Area に参加して、生成 AI、ソフトウェア定義車両、プロダクトエンジニアリング、サステナビリティ、新たなデジタルカスタマーエクスペリエンス、コネクテッドモビリティ、自動運転などの分野における最新のクラウド機能について学びましょう。 AWS at NRF 2025 (1 月 12～14 日) – Retail’s Big Show で AWS に参加して、生成 AI と最先端のテクノロジーが実際に役立っている様子をご覧ください。革新的なビッグアイデアセッションや厳選された TechTalks を聴き、小売業界の最新のトレンドやテクノロジーなどをご体験ください。 Amazon QuickSight 学習シリーズ – データスキルを強化することで 2025 年をスタートしましょう。1 月のオンライン学習シリーズに参加して、 re:Invent 2024 で発表された Amazon QuickSight の最先端の機能 について学びましょう。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 1 月 6 日週はここまでです。1 月 13 日週の Weekly Roundup もお楽しみに! – Prasad この記事は、 Weekly Roundup シリーズ の一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

12 月 3 日、最先端インテリジェンスと業界トップクラスの価格パフォーマンスを実現する新世代の最先端 基盤モデル (FM) である Amazon Nova を発表できたことを嬉しく思います。このモデルは Amazon Bedrock でのみご利用いただけます。 Amazon Nova を使用すると、ほとんどすべての 生成 AI タスクのコストとレイテンシーを削減できます。Amazon Nova をベースに構築することで、企業のワークロードに最適化されたさまざまなインテリジェンスクラスから、複雑なドキュメントやビデオの分析、チャートや図の理解、魅力的なビデオコンテンツの生成、高度な AI エージェントの構築を行うことができます。 画像やテキストを処理する必要があるドキュメント処理アプリケーションを開発する場合でも、大規模なマーケティングコンテンツを作成する場合でも、視覚情報を理解して処理できる AI アシスタントを構築する場合でも、Amazon Nova は、理解とクリエイティブコンテンツ生成という 2 つのカテゴリのモデルで必要なインテリジェンスと柔軟性を提供します。 Amazon Nova 理解モデルでは、テキスト、画像、またはビデオの入力を受け付けてテキスト出力を生成します。Amazon クリエイティブコンテンツ生成モデルでは、テキストと画像の入力を受け付けて画像またはビデオ出力を生成します。 理解モデル: テキストとビジュアルインテリジェンス Amazon Nova モデルには、さまざまなニーズを満たすように設計された 3 つの理解モデルが含まれています（4 つ目は近日公開予定）。 Amazon Nova Micro – Amazon Nova シリーズのモデルで最もレイテンシーの低いレスポンスを非常に低コストで提供するテキストのみのモデルです。Amazon Nova Micro は、コンテキストの長さが 128,000 トークンで、速度とコストを重視して最適化されているため、テキストの要約、翻訳、コンテンツの分類、インタラクティブなチャットとブレーンストーミング、単純な数学的推論とコーディングなどのタスクに優れています。Amazon Nova Micro では、精度を向上させるための微調整とモデル蒸留による独自データのカスタマイズもサポートしています。 Amazon Nova Lite – 画像、ビデオ、テキスト入力を高速に処理してテキスト出力を生成する、非常に低コストのマルチモーダルモデルです。Amazon Nova Lite は、お客様とのリアルタイムのやり取り、ドキュメント分析、および視覚的な質問応答タスクを高精度で処理できます。このモデルは、最大 30 万トークンの長さの入力を処理し、1 回のリクエストで複数の画像または最大 30 分のビデオを分析できます。Amazon Nova Lite は、テキストとマルチモーダルの微調整もサポートしており、モデル蒸留などの手法を使用して、ユースケースに最適な品質とコストを実現するように最適化できます。 Amazon Nova Pro – 精度、スピード、コストの最適な組み合わせで、幅広いタスクに対応する高性能マルチモーダルモデルです。Amazon Nova Pro は最大 30 万個の入力トークンを処理でき、複雑なワークフローを完了するために呼び出す API とツールを必要とするマルチモーダルインテリジェンスとエージェントワークフローに新しい標準を打ち立てます。視覚的な質問応答（ TextVQA ）やビデオ理解（ VATEX ）などの主要なベンチマークで最先端のパフォーマンスを実現しています。Amazon Nova Pro は、視覚情報とテキスト情報の両方を処理する強力な機能を発揮し、財務書類の分析にも優れています。30 万トークンの入力コンテキストで、15,000 行を超えるコードを含むコードベースを処理できます。Amazon Nova Pro は、Amazon Nova Micro と Lite のカスタムバリアントを抽出するための教師モデルとしても機能します。 Amazon Nova Premier – 複雑な推論タスクや、カスタムモデルの抽出に最適な教師として使用できる、当社の最も高性能なマルチモーダルモデルです。Amazon Nova Premier はまだトレーニング中です。2025 年初頭に発売を開始することを目標としています。 Amazon Nova 理解モデルは、 Retrieval-Augmented Generation (RAG) 、関数呼び出し、およびエージェントアプリケーションに優れています。これは、 Comprehensive RAG Benchmark (CRAG) 評価、 Berkeley Function Calling Leaderboard (BFCL) 、 VisualWebBench 、 Mind2Web の Amazon Nova モデルスコアに反映されています。 Amazon Nova を企業にとって特に強力なものにしているのは、そのカスタマイズ機能です。スーツを仕立てるようなものだと考えてください。高品質のファンデーションから始めて、ニーズに合わせて調整します。テキスト、画像、ビデオを使用してモデルをファインチューニングすることで、業界の用語を理解し、ブランドボイスを理解し、特定のユースケースに合わせて最適化できます。たとえば、法律事務所では、法律用語やドキュメント構造をよりよく理解するために Amazon Nova をカスタマイズする場合があります。 これらのモデルの最新のベンチマークスコアは、 Amazon Nova 製品ページ で確認できます。 クリエイティブなコンテンツ生成: コンセプトに命を吹き込む Amazon Nova モデルには、次の 2 つのクリエイティブコンテンツ生成モデルも含まれています。 Amazon Nova Canvas – インペイント、アウトペイント、背景削除などの豊富な編集機能を含む、スタイルとコンテンツを正確に制御しながらスタジオ品質の画像を生成する最先端の画像生成モデルです。Amazon Nova Canvas は、人間による評価だけでなく、 質問回答によるテキストと画像の忠実度評価 (TIFA) や ImageReward などの主要なベンチマークにも優れています。 Amazon Nova Reel – 最先端のビデオ生成モデルです。Amazon Nova Reel を使用すると、テキストプロンプトや画像を使用して短いビデオを制作したり、視覚スタイルやペースを制御したり、マーケティング、広告、エンターテイメント向けのプロ品質のビデオコンテンツを生成したりできます。Amazon Nova Reel は、ビデオの品質とビデオの一貫性に関する人間による評価において、既存のモデルよりも優れています。 Amazon Nova のすべてのモデルには安全制御が組み込まれており、クリエイティブコンテンツ生成モデルには責任ある AI の使用を促進するためのウォーターマーク機能が含まれています。 いくつかのユースケースで、これらのモデルが実際にどのように機能するかを見てみましょう。 ドキュメント分析に Amazon Nova Pro を使用する ドキュメント分析の機能を実証するために、AWS のドキュメントから PDF 形式の「 生成 AI サービスの選択 」決定ガイドをダウンロードしました。 まず、 Amazon Bedrock コンソール のナビゲーションペインで [ モデルアクセス ] を選択し、新しい Amazon Nova モデルへのアクセスをリクエストします。次に、ナビゲーションペインの [ プレイグラウンド ] セクションで [ チャット/テキスト ] を選択し、 mazon Nova Pro モデルを選択します。チャットでは、意思決定ガイドの PDF をアップロードして、次のことを尋ねます。 このドキュメントの要約を 100 字で書いてください。次に、デシジョンツリーを作成します。 出力は私の指示に従い、読む前にドキュメントを垣間見ることができる構造化されたデシジョンツリーを生成します。 ビデオ分析に Amazon Nova Pro を使用する ビデオ分析を示すために、2つの短いクリップを結合してビデオを作成しました（これについては次のセクションで詳しく説明します）。 今回は、 AWS SDK for Python (Boto3) を使用して Amazon Bedrock Converse API を使用して Amazon Nova Pro モデルを呼び出し、ビデオを分析します。 import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-pro-v1:0" VIDEO_FILE = "the-sea.mp4" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) with open(VIDEO_FILE, "rb") as f: video = f.read() user_message = "このビデオについて説明します。" messages = [ { "role": "user", "content": [ {"video": {"format": "mp4", "source": {"bytes": video}}}, {"text": user_message} ] } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, inferenceConfig={"temperature": 0.0}  ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Amazon Nova Pro は、API を使用してアップロードされたビデオ (前のコードと同様) や、 Amazon Simple Storage Service (Amazon S3) バケットに保存されたビデオを分析できます。 スクリプトでは、ビデオの説明をお願いしています。コマンドラインからスクリプトを実行します。結果は次のとおりです。 ビデオは海の岩だらけの海岸の眺めから始まり、次に砂浜で休んでいる大きな貝殻のクローズアップに移ります。 より詳細なプロンプトを使用して、オブジェクトやテキストなどの特定の情報をビデオから抽出できます。Amazon Nova は現在、ビデオのオーディオを処理していないことに注意してください。 ビデオ作成に Amazon Nova を使用する それでは、Amazon Nova Reel を使用してビデオを作成しましょう。テキストのみのプロンプトから始めて、参照画像を指定します。 ビデオの生成には数分かかるため、Amazon Bedrock API では次の 3 つの新しいオペレーションが導入されました。 StartAsyncInvoke – 非同期呼び出しを開始する GetAsyncInvoke – 特定の非同期呼び出しの現在のステータスを取得する ListAsyncInvokes – ステータスや日付などのオプションフィルタを使用して、すべての非同期呼び出しのステータスを一覧表示する Amazon Nova Reel は、カメラのズームや移動などのカメラコントロールアクションをサポートしています。この Python スクリプトは、次のテキストプロンプトからビデオを作成します。 砂の中の大きな貝殻のクローズアップ。シェルの周りには穏やかな波が流れています。サンセットライト。カメラのズームインが非常に近いです。 最初の呼び出し後、スクリプトはビデオの作成が完了するまで定期的にステータスをチェックします。ランダムシードを渡すと、コードが実行されるたびに異なる結果が得られます。 import random import time import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 S3_DESTINATION_BUCKET = "<BUCKET>" video_prompt = "砂の中の大きな貝殻のクローズアップ。シェルの周りには穏やかな波が流れています。サンセットライト。カメラのズームインが非常に近いです。" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": {"text": video_prompt}, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") スクリプトを実行します。 ステータス: 進行中 . . . ステータス: 完了 s3://BUCKET/PREFIX/output.mp4 でビデオの準備ができました 数分後、スクリプトが完了し、 Amazon Simple Storage Service (Amazon S3) の出力場所が出力されます。 AWS コマンドラインインターフェイス (AWS CLI) を使用して出力ビデオをダウンロードします。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-text.mp4 これが出来上がったビデオです。要求に応じて、カメラは被写体を拡大します。 Amazon Nova Reel を参考画像と共に使用する ビデオの作成をより適切に制御できるように、Amazon Nova Reel に次のような参照画像を提供できます。 このスクリプトは、参照画像とテキストプロンプトとカメラアクション（ 海岸の風景の上空を飛行するドローンビュー ）を使用してビデオを作成します。 import base64 import random import time import boto3 S3_DESTINATION_BUCKET = "<BUCKET>" AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 input_image_path = "seascape.png" video_prompt = "海岸沿いの風景の上空を飛行するドローンビュー" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) # 入力画像を Base64 文字列としてロードします。 with open(input_image_path, "rb") as f: input_image_bytes = f.read() input_image_base64 = base64.b64encode(input_image_bytes).decode("utf-8") model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": { "text": video_prompt, "images": [{ "format": "png", "source": { "bytes": input_image_base64 } }] }, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") 繰り返しますが、AWS CLI を使用して出力をダウンロードします。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-image.mp4 これが出来上がったビデオです。カメラは参照画像から開始し、前方に移動します。 責任ある AI の構築 Amazon Nova モデルは、モデル開発段階を通じてお客様の安全、セキュリティ、信頼に重点を置いて構築されています。これにより、お客様独自のユースケースを実現するための安心感と適切なレベルの制御が可能になります。 包括的な安全機能とコンテンツ管理機能が組み込まれているため、責任を持って AI を使用するために必要な制御が可能になります。生成されたすべての画像およびビデオには、デジタル透かしが含まれています。 Amazon Nova 基盤モデルは、その強化された機能に見合った保護機能を搭載して構築されています。Amazon Nova は、誤った情報、児童の性的虐待資料 (CSAM)、化学的、生物学的、放射線的、または原子力 (CBRN) のリスクの拡散に対抗するために安全対策を拡大しています。 知っておくべきこと Amazon Nova モデルは、米国東部 (バージニア北部) AWS リージョン の Amazon Bedrock でご利用いただけます。Amazon Nova Micro、Lite、Pro は、 クロスリージョン推論 により米国西部 (オレゴン) および米国東部 (オハイオ) リージョンでもご利用いただけます。 Amazon Bedrock では通常どおり、価格設定は従量課金制です。詳細については、 Amazon Bedrock の料金 をご覧ください。 新世代の Amazon Nova 理解モデルはあなたの言語を話します。これらのモデルは 200 以上の言語でコンテンツを理解して生成し、特に英語、ドイツ語、スペイン語、フランス語、イタリア語、日本語、韓国語、アラビア語、簡体字中国語、ロシア語、ヒンディー語、ポルトガル語、オランダ語、トルコ語、ヘブライ語で強力な機能を備えています。つまり、言語の壁を気にしたり、地域ごとに別々のモデルを維持したりすることなく、真にグローバルなアプリケーションを構築できるということです。クリエイティブコンテンツ生成用の Amazon Nova モデルは英語のプロンプトをサポートします。 Amazon Nova を試してみると、ますます複雑になるタスクを処理できることに気付くでしょう。これらのモデルを使用すると、最大 30 万トークンの長いドキュメントを処理したり、1 回のリクエストで複数の画像を分析したり、最大 30 分分のビデオコンテンツを理解したり、自然言語から大規模な画像やビデオを生成したりできます。そのため、これらのモデルは、迅速なカスタマーサービスインタラクションから、企業ドキュメントの詳細な分析や広告、e コマース、ソーシャルメディアアプリケーション用のアセット作成まで、さまざまなビジネスユースケースに適しています。 Amazon Bedrock との統合により、デプロイとスケーリングが簡単になります。 Amazon Bedrock ナレッジベース などの機能を活用して、独自の情報でモデルを強化したり、 Amazon Bedrock エージェント を使用して複雑なワークフローを自動化したり、 Amazon Bedrock Guardrails を実装して責任ある AI の使用を促進したりできます。このプラットフォームは、インタラクティブアプリケーションのリアルタイムストリーミング、大量のワークロードのバッチ処理、およびパフォーマンスの最適化に役立つ詳細な監視をサポートしています。 Amazon Nova で構築を開始する準備はできていますか? 今すぐ Amazon Bedrock コンソール で新しいモデルを試してみて、 Amazon Bedrock ドキュメント の Amazon Nova モデルセクションにアクセスして、 AWS re:Post for Amazon Bedrock にフィードバックを送ってください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。これらの新モデルで何を構築するのか教えてください! – Danilo 原文は こちら です。

こんにちは。 AWS パブリックセクター技術統括本部の押川です。 本ブログは、「詳細解説」シリーズの一つとして、標準準拠システムの AWS 上でのデータ連携について解説いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 庁内データ連携機能とは 2つの連携方式とデータ連携の要件 認証認可について AWS 上での実現方法 認証認可サーバーが必要な場合 認証認可サーバーが必要でない場合 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ まとめ ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 庁内データ連携機能とは 標準準拠システムが、他の標準準拠システムにデータを送信又は他の標準準拠システムからデータを受信すること、庁内データ連携機能と言います。例えば、住民記録システムから介護保険システムに対して、住民基本情報を連携する場合などが該当します。 2つの連携方式とデータ連携の要件 連携方式としては、「RESTによる公開用API連携」（以降、「API連携」という。）と「ファイル連携」の２つの方式を規定しています。 API連携 API連携は、RESTful APIを使用してシステム間でデータをやり取りする方式です。提供側業務システムは REST による API を利用側業務システムへ公開し、利用側業務システムはその API を呼び出します。 ファイル連携 詳しい仕様についてはデジタル庁が提供している「 ファイル連携に関する詳細技術仕様書 」などをご覧ください。 重要な点についてまとめると、以下のようになります。 ストレージを使用してシステム間でデータをやり取りする方式です。 オブジェクトストレージを利用し CSV ファイルよる連携を行います。基本的に、提供側業務システムは、オブジェクトストレージが提供するツール（API等）を利用して、オブジェクトストレージ上の所定の格納先に CSV ファイルを格納します。それが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上で CSV ファイルを格納することができます。 共通機能を提供する事業者はオブジェクトストレージ上に業務の組み合わせごとのバケットを作成し、そのバケットを利用してシステム間でのデータのやり取りを行います。バケットが業務の組み合わせごとに分かれているため、提供側業務システムは、利用側業務システム単位に別々の連携ファイルを作成します。 例えば、北海道札幌市において(市区町村コード=011002)、住民基本台帳(システム区分＋業務ID=0001)と印鑑登録(システム区分＋業務ID=0002)の業務の組み合わせのバケットを作成する場合、バケット名は「011002-0001-0002」とします。 異なるCSP間又はCSPとオンプレミス環境間でファイル連携を行う場合、API 連携で利用する認証認可サーバをIDプロバイダーとし、 CSPの認証認可機能と連携 (フェデレーション) させ、IDプロバイダーでオブジェクトストレージの認証を行う必要があります。 AWS 上では、オブジェクトストレージには Amazon S3 を用います。上述したように、Amazon S3 のバケットを業務の組み合わせごとに作成し、その中でフォルダ分けします。 認証認可について 詳しい仕様についてはデジタル庁が公開している「 地方公共団体情報システム　共通機能標準仕様書 」や「 「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス 」などをご覧ください。 重要な点についてまとめると、以下のようになります client_secret_jwt による JWT を用いた認証を行います。それが難しい時のみ、API Key の利用を当面認めますが、ガバメントクラウドでは原則認められていません。 API 認可サーバーは自治体内で原則 1 つ用意します。ただし、以下に当てはまる場合などは必要ありません。 ファイル連携において連携元/連携先の業務システムがどちらもAWS上で稼働する場合 ファイル連携で認可サーバーを利用しない方法を使う場合 利用側業務システムが複数の提供側業務システムにアクセスする場合にも、提供側業務システムごとにアクセストークンを発行し、複数の提供側業務システムへアクセス可能なアクセストークンの発行は行いません。 AWS 上での実現方法 認証認可サーバーが必要な場合 API 連携を行う場合 API 連携における RESTful API は、 Amazon API Gateway などを用いて実現します。また、API 連携において必要になる認証認可機能については、Amazon Elastic Container Service (Amazon ECS) や Amazon Aurora を利用してサーバーを構築します。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者 認証認可サーバーの実装 データの要求元・データの要求先にそれぞれクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセ ストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など ファイル連携で認証認可サーバーを構築する場合 ここでは、ファイル連携で認証認可サーバーを構築する場合について図を用いて説明します。 それぞれの事業者には、以下の業務が発生します。 共通機能の構築業者 IAM Role の作成 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者（共通機能の構築業者が兼任することも多い） 認証認可サーバーの実装 データ利用側にクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など 認証認可サーバーが必要でない場合 AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、認証認可サーバーを構築しない方法として以下の 2 つの方法があります。 AWS Transfer Family を用いて SFTP で暗号化して通信する オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする（SSM Agent, IAM Role Anywhere） AWS Transfer Family を用いて SFTP で暗号化して通信する場合 上述のように、API によるファイルのアップロードやダウンロードが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上でファイルを格納することができます。AWS Transfer Family というサービスによって、SFTP を用いて Amazon S3 にオブジェクトを格納・取り出せます。 データ提供側の業務システム構築業者 対象の S3 バケットをバックエンドにした Transfer Family のセットアップ データ要求元が作成した SSH キーを利用したユーザーの作成 ユーザーに対応する S3 へアクセス可能な IAM ロールの作成 データ利用側の業務システム構築業者 認証に利用する SSH キーの作成 オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする場合 AWS の機能を利用し、オンプレミスや他CSPのサーバーへ IAM の権限を付与することができます。 SSM Agent を使う方法や、 IAM Role Anywhere を用いる方法があります。 ここでは、 SSM Agent を用いて、オンプレミスにあるデータ利用側の業務システムが、AWS 上にあるデータ提供側の業務システムのデータを利用する方法について図を用いて説明します。 まず、 AWSマネジメントコンソールのAWS Systems Managerのページにて、SSM Agentをインストールする際の有効化に必要なコードとIDを発行します。そして、作成した SSM Agent 用ロールをデータ利用側システム（オンプレミス）のサーバーが引き受けます。次に、 IAM STS を利用して、Amazon S3 にアクセスできるタスク実行用ロールの一時認証情報を取得します。最後に、取得した一時認証情報で Amazon S3 にアクセスします。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 データ利用側の事業者の IAM ロールが引き受けることのできる、S3 へアクセスできる IAM ロールを作成 データ利用側の業務システム構築業者 オンプレミスのサーバが利用する IAM ロールの作成 データ提供側の事業者へS3 へのアクセスに利用する IAM ロールを通知 オンプレミスのサーバでIAMロールが利用できるよう SSM Agent の設定 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ ここまででにあげた 3 つの方法について、表にまとめました。方法を選択する際の参考になさってください。   SSM Agent Transfer Family 認証認可サーバー 特徴 導入手順がシンプル SFTP の利用が可能 ID/Password認証が可能 標準仕様に記載された方法 API認可や職員認証で利用する認証認可サーバーがある場合は新規構築が不要 別CSPでも同様の方法が可能 考慮点 SSM Agent の導入やアップデートの工数 1000 台以上利用の場合は追加料金が発生 一時的な認証情報の利用はできない 200USD/月程度のコスト 認証認可サーバーの運用保守コスト OAuth 2.0 に準拠した API の実装コスト ユースケース コストを安く済ませたい場合 データ利用側・提供側のサーバーで SFTP を用いたい場合 API 認可や職員認証で認証認可サーバーを構築する場合 まとめ 本ブログでは、ガバメントクラウド上での標準準拠システムデータ連携について詳細をご紹介しました。重要なポイントとしては、AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、複数の認可方法があるため、どのような業務が発生するかを把握して選択することが挙げられます。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

こんにちは。 AWS パブリックセクター技術統括本部の押川です。 ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 本ブログは、「ガバメントクラウド活用のヒント」シリーズの一つとして、ガバメントクラウド上に構築したシステムに対する運用保守経路についてご説明いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 運用保守経路としての Transit Gateway の利用 運用保守経路としての PrivateLink の利用 運用保守経路としての Systems Manager Session Manager の利用 補足: 複数のアカウントの EC2 で一度に同じコマンドを実行する 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守経路としてのTransit Gateway の利用 ガバメントクラウドの道案内『ASP＆運用管理補助者編』 の(4) 運用保守経路を確保する にもありますが、ガバメントクラウド上で構築した業務システムへの運用保守経路を構築する必要があります。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、閉域経由での運用保守経路を構築する必要がありますが、ここではベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築する場合について記載します。 以下のように、事業者運用拠点から閉域を経由してガバメントクラウド上の本番アカウントに接続できるようにして、EC2 への SSH 接続やデータベースへのクエリの実行などの運用管理を行うことを可能にします。 この接続形式では、本番アカウントと事業者運用拠点は IP リーチャブルであり、双方向に通信が可能です。 この方法のメリットは、構築が簡単で、後述する AWS PrivateLink などのコストがかからないという点があります。 この方法のデメリットは、本番アカウントと事業者運用拠点が IP リーチャブルであることから、両者の IP アドレス範囲が重複しないように設計する必要があったり、ルートテーブルを管理する必要があるなどの点です。 一般的に、事業者運用拠点から複数の自治体の本番アカウントを保守しなければならず、そのすべての IP アドレス範囲と重複しないように事業者運用拠点を設計することは難しいため、後述するように AWS PrivateLink などで接続する方式が取られています。 運用保守経路としての PrivateLink の利用 先ほど述べた、事業者運用拠点と本番アカウントの IP アドレスが重複してしまうなどの問題を解決するために、AWS PrivateLink で本番アカウントの EC2 や RDS に接続することがあります。 事業者運用拠点から AWS PrivateLink の VPC エンドポイントに直接接続できますが、運用管理アカウントに踏み台サーバー (Amazon EC2) を設置する場合もあります。 AWS PrivateLink を利用すると、VPC エンドポイントの費用がかかります。接続したい対象の数だけ用意する必要があります。 参考として、 「AWS PrivateLink ワークショップ」 もご活用ください。 決まった数個の VPC エンドポイントのみで Amazon EC2 に接続することができるようになるのが、次の方法です。 踏み台サーバーを Systems Manager に代替する AWS Systems Manager には、Session Manager という機能があり、SSH のポートを解放しなくても Amazon EC2 にログインして操作を行うことができます。 マネジメントコンソールからの利用が一般的ですが、ガバメントクラウドでは、マネジメントコンソールへアクセスするために払い出されるユーザーからは Session Manager を利用することができません。しかし、運用管理アカウント経由など、本番アカウントのマネジメントコンソールを介さなければ Session Manager を利用することができます。 閉域から Session Manager を利用するには、AWS CLI の以下のようなコマンドを実行します。 aws ssm start-session --target instance-id この場合、運用管理アカウントと本番アカウントに、 Session Manager を利用するために必要な数個のエンドポイントを設置するだけで本番 EC2 へのログインが可能になります。 Session Manager を利用するために必要な VPC エンドポイントについては、 こちらのドキュメント をご覧ください。 AWS Systems Manager Session Manager では EC2 にしかアクセスできないので、例えば RDS に SSH ログインをしてクエリを実行するなどの保守作業を行いたいといったようなケースでは、踏み台サーバーが必要になります。 補足:複数のアカウントの EC2 で一度に同じコマンドを実行する メンテナンスなどで、複数の EC2 で同時にコマンドを実行したい場合、 AWS Systems Manager Automation を使えます。 各本番アカウントで定義された実行権限のあるロールに運用管理アカウントから AssumeRole してアクションを実行します。この場合、どのようなコマンドを実行するかなどのアクションを管理する Runbook は運用管理アカウント内で一括管理できます。 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守作業とは少し違いますが、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合のインターネットへの経路の設定についても補足しておきます。 ガバメントクラウド上では、ネットワーク分離の考え方から インターネットゲートウェイを設置することが制限されています。そのため、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合は、運用保守アカウントに NAT ゲートウェイ・インターネットゲートウェイを設置し、そこへの経路を設置する必要があります。 この場合、本番アカウントからインターネットゲートウェイが IP リーチャブルではない方がセキュアですので、途中に AWS PrivateLink を挟みます。そして、その到達先として Amazon EC2 を設置し、そのサーバーを経由して NAT ゲートウェイ・インターネットゲートウェイにアクセスするようにします。 まとめ 本ブログでは、ガバメントクラウド上での運用保守経路について詳細をご紹介しました。複数のパターンのメリットとデメリットを把握し、適切な運用保守経路を構築することが必要です。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

本ブログは、三協立山株式会社と Amazon Web Services Japan が共同で執筆しました。 三協立山株式会社 は ビル・住宅・エクステリア建材の開発・生産・販売までを一貫して手がけるほか、アルミやマグネシウム合金の鋳造・押出・加工や販売を行っています。商業施設向けの陳列棚やショーケース、屋外看板などを提供し、メンテナンスも担っています。本ブログでは三協立山が開発した社内向けサービス 「AI ふたば」 の概要とその中でどのように Amazon Bedrock が活用されているかを紹介します。 　 課題と背景 三協立山では 2023 年 6 月に社長より生成 AI の積極的活用方針が示され、特に生産性向上を目指した取り組みを優先的に始めることになりました。 生成 AI の導入に向けて、社内ルールやガイドラインの整備、E-ラーニングの作成など、社員限定での利用環境の整備を進めていき初期バージョンの「AI ふたば」をリリースしました。この時点では Amazon Bedrock は 採用しておらず、他社の LLM を使って実装していました。しかし、実際の運用においていくつかの課題が浮き彫りとなってきました。 主な課題として以下が挙げられます： 文字数制限による議事録の自動作成への活用の難しさ 業務での具体的な活用シーンの不明確さ 自社情報の活用ニーズ（過去の資料検索の非効率性）への対応 また、プログラミングや文書作成業務に従事する一部のヘビーユーザーを除き、全社的な活用は進んでいない状況でした。社内情報を活用した RAG（Retrieval-Augmented Generation）の自社開発も試みましたが、実装の困難さに直面していました。これらの課題に対し、より実用的で効果的な生成 AI 活用の仕組みづくりが求められていました。 ソリューションの概要 そのような課題がある状況で AWS より Generative AI Use cases JP (以下、GenU) をご提案しました。CDK や React の経験が全くなく不安もあったそうですが、開発メンバーの川崎さんは「AWS はほぼ初心者で CDK も今回初めて存在を知ったくらいですが、Readme ファイルなども充実しており、想像以上に簡単に始めることが出来ました。」さらに「コーディングで分からないところは AI ふたば自身で確認をしながら進められ、ローカル環境で動かして画面を確認しながら修正ができるので敷居が低かった。議事録の文字起こし機能のバックエンド部分を非同期処理で実装することもできました。」と語っています。 また、GenU が元々持っていたプロンプトテンプレートを自社向けにカスタマイズし、業務での具体的な活用シーンに即して 50 パターンほど用意しています。 図 1 : AI ふたばの画面イメージ 自社データの活用については、GenU に含まれている Amazon Kendra を活用した RAG を採用しました。商品情報では「X.スタイル」と「クロス.スタイル」など言葉の揺らぎに対してはプロンプトやファイルの置き方を工夫したり、メタデータを活用して、検索精度を高めることに成功しました。また Amazon Bedrock にはない外部の LLM も利用できるようにカスタマイズを行っており、エンドユーザーに多くの選択肢を提供するように工夫しています。 以下の図 2 がAI ふたばのアーキテクチャーの概要になります。 図 2 : AI ふたばのシステム構成 導入効果と今後の展開 GenU をベースとしてカスタマイズをしたことで、AI ふたば Ver2 はたった１か月でリリースすることができました。Ver2 での議事録作成機能の追加やプロンプトテンプレートでユースケースを提示したことで社内の利用者は 1.5 ～ 2 倍程度拡大しました。また当初から要望の多かった議事録作成機能をリリース出来たことで年間で 1 万 5000 時間の業務時間削減効果が見込まれています。 川崎さんは「AWS は初心者で、しかも OSS として公開されている GenU をベースにして開発するという体験は、今までの既存アプリのバージョンアップ中心だった業務から、世の中の動きを知るきっかけになりました。IaC である CDK も初めて使いましたが、あまりの便利さにこれから他の開発でも CDK を使ってみようと思います。」と語っています。同じく開発メンバーの船場さんは「生成 AI も Amazon Bedrock を利用することで非常に簡単に実装できるということが 分かりました。」と語っています。 GenU はアプリケーションのソースコードはもちろん、AWS の各種サービスもビルディングブロックで組み合わされたものを CDK　の形で OSS として公開しています。そのままお使い頂くこともできますが、今回の事例のようにカスタマイズして使う事もできるようになっているのが特徴です。 情報システム統括室システム企画開発部の高畑部長は、「若手のメンバーが面白がって取り組んでくれた。GenU をベースにしながらも、Ver1 の見た目に寄せるようカスタマイズしたことでエンドユーザにとっても違和感なく展開することができました。」と語っています。 　 今後の展開としては以下のようなことを検討しています。 議事録機能の更なる改善 エージェント機能の追加 Amazon Kendra へのファイル連携機能の効率化 まとめ 本ブログでは 三協立山で導入した AI アシスタントサービスの紹介とその中で Amazon Bedrock や GenU がどのように活用されているかを紹介しました。 Amazon Bedrock を利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。 本ブログは、三協立山 株式会社と AWS のソリューションアーキテクトの水野が共同で執筆いたしました。 三協立山ショールームにて撮影 左から 情報システム統括室システム企画開発部 高畑 裕紀 部長 情報システム統括室システム企画開発部企画開発一課 船場 和馬 改革推進統括室デジタル改革推進部デジタル改革推進グループ 川上 貞昭 グループ長 情報システム統括室システム企画開発部企画開発一課 川崎 翔平 副主任 情報システム統括室システム企画開発部企画開発一課 阿閉 清紀 課長 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

ビジネス上の重要な処理に SAP システムを利用している企業は、高い可用性とパフォーマンスを求められるため、オブザーバビリティ戦略は運用の効率化に欠かせない重要な要素となります。 SAP HANA、SAP Business Suite on HANA、または SAP S/4HANA などのソリューションを実行する大規模な SAP 環境を持つ企業は、これらの環境に複数のモニタリングオプションがあります。SAP Solution Manager、Amazon CloudWatch Application Insights などのソリューションは、一般的にシステムの正常性とパフォーマンスを監視するために使用されます。しかし、エンタープライズのモニタリング戦略を見ると、SAP と非 SAP ソリューションを組み合わせ、さらにマルチクラウド構成にすることで、可視化やアラートを単一の画面上で表示するダッシュボードを実現し、長期的なアーキテクチャを最適化します。Prometheus や Grafana などのツールは、SAP と非 SAP 環境を組み合わせたシステム監視のセットアップを実現するため、SAP と Amazon のマネージドオファリング (Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG)) を使用する組織でも既に使用されており、クラウドネイティブ技術を提供します。 SAP のお客様も、RISE with SAP で AWS を選択することが増えています。RISE に移行していないお客様のために、この解決策により、SAP ワークロードの監視能力が向上します。このブログでは、 AWS Well-Architected Framework の SAP Lens のベストプラクティスに従って AMP と AMG を構成することで、SLES (SUSE Linux Enterprise Server) OS と SAP S/4HANA の監視ダッシュボードのセットアップ方法を学びます。 セットアップが完了すると、オペレーティングシステム、SAP アプリケーションサーバー、SAP 高可用性クラスターの各コンポーネントについて、複数のダッシュボードにまたがって SAP 環境全体の正常性を確認できます。 定義 このブログで使用する用語を定義しましょう。 オブザーバビリティ : オブザーバビリティ（可観測性）とは、システムの状態や性能を把握するための仕組みを指します。具体的には、システムの状態を示すメトリクス（指標）、ログ、トレースを用いて分析します。システムのパフォーマンスを理解することは、運用の優秀性を達成し、ビジネス目標を満たすための鍵となります。 「監視」という用語は時にオブザーバビリティとは異なると定義されますが、しかし監視はトレースやログ収集などの活動と並んで、システムを観測可能にする活動です。 Amazon Managed Prometheus (AMP) : AMP はメトリクスのためのサーバーレス、Prometheus 互換のモニタリングサービスで、大規模なコンテナ環境をセキュアに監視することを簡単にします。AMP を使えば、お客様は今日使っているオープンソースの Prometheus データモデルとクエリ言語を使って、ワークロードのパフォーマンスを監視できます。また、基盤となるインフラストラクチャを管理する必要がなく、スケーラビリティ、可用性、セキュリティの向上もあります。 Amazon Managed Grafana (AMG) : AMG は、完全にマネージドされ、セキュリティが確保されたデータ可視化サービスで、顧客はさまざまなデータソースから運用状況のデータを素早く照会、関連付け、視覚化できます。AMG は、拡張可能なデータサポートで広く利用されているデータ可視化ツール Grafana を簡単にデプロイ、運用、スケーリングできるようにしています。 前提条件 前提条件として、高可用性の有無にかかわらず、AWS アカウント内に SAP システムをセットアップする必要があります。設定を行うユーザーアカウントには、AWS IAM でロールを割り当てる権限が必要です。このブログでは、SAP S/4HANA システム (ASCS/ERS と SAP HANA DB クラスターおよび 2 つのアプリケーションサーバー) を、SLES for SAP 15 SP4 オペレーティングシステム上で動作させています。 アーキテクチャ まずはこのソリューションの基本的なアーキテクチャを理解しましょう。図 1 は AWS 上で SAP S/4HANA を高可用性 (HA) 構成にした典型的なアーキテクチャを、図 2 はオブザーバビリティのアーキテクチャを示しています。 すべての SAP システムは SAP 認定 Amazon EC2 インスタンス上にインストールされ、データの移動は全て VPC エンドポイントを経由します。 図 1: AWS 上の SAP S/4HANA 高可用性 (HA) アーキテクチャの表現 図 2: Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG) を使用した SAP の可観測性アーキテクチャ 設定と構成 図 3 の下に示すように、ソリューションを構成する手順は以下の通りです。 図 3: AMP を使用した SAP の監視構成と AMG での可視化のためのステップ AMP ワークスペースの作成と設定 データは AMP Workspace に「リモートライト」方式で取り込まれ、AMG のダッシュボードのデータソースとして使用されます。 ユーザー ID に Amazon Managed Service for Prometheus (AMP) コンソールから「Create workspace (ワークスペースの作成)」を選択する権限があることを確認し、図 4 に示すようにしてください。 図 4: AMP ワークスペースの作成 AMP でワークスペースが作成されると、サービスがリモート書き込み URL (図 5 に示されている) を提供します。後のセクションの構成手順でこの URL が必要になるので、 リモート書き込み URL を控えておいてください。 図 5: AMP ワークスペースエンドポイントの詳細例 EC2 IAM から AMP にメトリクスをストリーミングする AmazonPrometheusRemoteWriteAccess AWS 管理ポリシー を使用して、Amazon EC2 インスタンスの IAM ロールを作成します。このロールを EC2 インスタンスに割り当てるか、この新しく作成したロールで EC2 インスタンスを起動するか、または既存のロール ( AWS ドキュメント の図 6 のように) に AmazonPrometheusRemoteWriteAccess ポリシーを割り当てることができます。 図 6: AMP ポリシー名 VPC エンドポイント EC2 インスタンスから AWS バックボーンネットワークを経由して AMP にメトリクスをプライベートに送信するために、AMP 用の VPC エンドポイントを設定する必要があります。 VPC エンドポイントにより、VPC 内のリソース (この場合は EC2 インスタンス) から管理型サービスに安全にアクセスできるようになります。 次に、以下の手順で AMP の VPC インターフェイスエンドポイントを作成します: AWS コンソールから、VPC サービスの「Endpoints」を選択し、図 7 のように「Amazon WorkSpaces」サービスを選択します。 図 7: AMP 用の AWS VPC エンドポイントサービス名 VPC 内のリソースがこれらのインターフェイスエンドポイントに HTTPS で通信を行えるように、VPC 内のセキュリティグループを変更する必要がある場合もあります。インターフェイスエンドポイントの作成方法の詳しい手順は、 AWS ドキュメント で確認できます。 さらに、VPC から直接インターネットにアクセスできない場合は、図 8 に示すように、sigv4 がエンドポイントを介して機能できるよう、AWS Security Token Service 用のインターフェイス VPC エンドポイントも作成する必要があります。 図 8: AWS Security Token Service の VPC エンドポイントサービス名 Metrics Exporters と Prometheus の EC2 インスタンスへのインストールと設定 この手順では、EC2 インスタンス上に必要なエクスポーターと Prometheus エージェントをインストールする方法を学びます。 Prometheus のエクスポーターは、システムからメトリクスを収集し、Prometheus で読み取り可能にする役割を果たします。 Prometheus のエージェントは、メトリクスをエンドポイントに転送する役割を果たします。 各 SAP アーキテクチャコンポーネントのエクスポーターのリストは表 1 にまとめられています。 さらに、すべての EC2 インスタンスで Prometheus エージェントのインストールが必要で、そのことでデータを AMP に転送できるようになります。 SAP システムロール エクスポーター名 詳細情報の URL SAP ASCS/ERS クラスター ClusterLabs ha_cluster_exporter Prometheus node_exporter https://github.com/ClusterLabs/ha_cluster_exporter https://github.com/prometheus/node_exporter SAP アプリケーションサーバー SUSE sap_host_exporter Prometheus node_exporter https://github.com/SUSE/sap_host_exporter https://github.com/prometheus/node_exporter 表 1: SAP 各コンポーネントで EC2 にインストールするエクスポーターのリスト 2.1 Node Exporter Prometheus Node Exporter は、ハードウェアやカーネルに関する様々なメトリクスを公開し、それらのメトリクスを使って EC2 のヘルスステータスをダッシュボードで表示できます。 EC2 インスタンス上で node exporter をインストールして実行する手順は次のとおりです。( Prometheus のウェブサイト にも記載があります)。 Linux (SLES) オペレーティングシステムを実行している EC2 インスタンスで node exporter をインストール、展開、実行するには、以下のコマンドを実行してください。は node exporter のバージョン、-は OS のアーキテクチャに置き換えてください。 ダウンロードできる Node exporter パッケージは Prometheus のウェブサイト で確認できます。 wget https://github.com/prometheus/node_exporter/releases/download/v/node_exporter-.-.tar.gz tar xvfz node_exporter-*.*-amd64.tar.gz cd node_exporter-*.*-amd64 ./node_exporter Node Exporter はお好みのディレクトリ(例: /usr/local/bin)にインストールできます。実行すると、Node Exporter はローカルサーバーの 9100 番ポートの /metrics エンドポイントでメトリクスを公開します。 次の curl コマンドを実行して、9100 /metrics エンドポイントでメトリクスがエクスポートされていることを確認できます。 curl http://localhost:9100/metrics コマンドの出力は次のようになります: # HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total { cpu ="0",mode ="idle"} 6.8382833e + 06 node_cpu_seconds_total { cpu ="0",mode ="iowait"} 824.38 node_cpu_seconds_total { cpu ="0",mode ="irq"} 0 # その他の設定など この手順を完了すると、SAP の役割に関係なく、すべての SAP EC2 インスタンスに node exporter がインストールされます。 2.2 ASCS/ERS EC2 インスタンスでの HA クラスターエクスポーター Clusterlabs HA Cluster Exporter はステートレス HTTP エンドポイントです。 各 HTTP リクエストで、さまざまなクラスタコンポーネントのツールによって提供される既存の分散データを解析することで、クラスタの状況をローカルで検査します。 エクスポートされるデータには、次のような情報が含まれます。 ペースメーカークラスタの概要、ノードとリソースの統計情報 Corosync の通信リングのエラーとクォーラム投票 DRBD リソースなど 高可用性 SAP システムの設定では、corosync、pacemaker、フェイルオーバーの状態などのサービスの状況を把握することで、システムをよりよく理解し、障害の根本原因を特定するのに役立ちます。 ASCS と ERS の両方の EC2 インスタンスで、root ユーザーまたは sudo 権限を持つユーザーとしてエクスポーターパッケージをインストールして実行してください。 zypper install prometheus-ha_cluster_exporter ./ha_cluster_exporter HA Cluster Exporter を実行すると、デフォルトでポート 9664 の /metrics パスの下にメトリクスがエクスポートされます。 ホスト上で実行中の /usr/bin/ha_cluster_exporter プロセスを確認すれば、HA クラスタのプロセスの状態を確認できます。 2.3 アプリケーションサーバーインスタンス上の SAP ホストエクスポーター SAP Host Exporter はステートレスの HTTP エンドポイントです。 各 HTTP リクエストでは、SAPControl Web インターフェイスを介して SAP システムからランタイムデータを取得します。 エクスポートされたデータには、以下のような情報が含まれます: サービスプロセスを起動する サーバー統計を (統計情報を)キューに登録する SAP アプリケーションサーバー ディスパッチャーのワークプロセスキュー統計 sap_host_exporter をインストールするには、以下のコマンドを使用してください。 export DISTRO = SLE_15_SP4 # 自身の OS のバージョンに合わせて変更してください zypper addrepo https://download.opensuse.org/repositories/server:/monitoring/$ DISTRO/server:monitoring.repo zypper install prometheus-sap_host_exporter インストール後は、次のように exporter を実行し、図 9 に示されているように、Unix ドメインソケットを経由して SAPControl Web サービスに接続できます。 ./sap_host_exporter — sap-control-uds /tmp/.sapstream51213 図 9: SLES でプロセスとして実行されている sap_host_exporter サービス これにより、デフォルトでポート 9680 の /metrics パスでメトリクスを公開します。 SAP アプリケーションサーバーが実行中の SAP EC2 インスタンスで SAP ホストエクスポーターをインストールするには、これらの手順を実行してください。 2.4 Prometheus エージェント Prometheus は EC2 インスタンスからデータを収集し、AMP に保存します。したがって、このステップでは、リソースの使用量が少ない Prometheus のエージェントモードをインストールします。Prometheus に同梱されている UI 機能やアラート機能は必要ありません。また、AMP へのリモートライトを設定します。 Prometheus サーバーは任意のディレクトリにインストールできます。例えば /usr/bin です。この例では、以下のコマンドで示したように、SLES for SAP 15 SP4 オペレーティングシステムに Prometheus v2.49.1 をインストールします。 Prometheus がインストールされたディレクトリに移動します。 wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* Prometheus のインストールディレクトリ内に、YAML 形式で記述された設定ファイル prometheus.yml があります。ファイルの中身は次のようになっています。 # グローバル設定 global: scrape_interval: 15s # スクレイプ間隔を 15 秒に設定します。デフォルトは 1 分です。 evaluation_interval: 15s # 15 秒ごとにルールを評価します。デフォルトは 1 分です。 # scrape_timeout はグローバルのデフォルト (10 秒) が設定されています。 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # 1 つのエンドポイントのみをスクレイピングする構成: # ここでは Prometheus そのものです。 scrape_configs: # ジョブ名がラベル `job =` として、この構成からスクレイピングされた全てのタイムシリーズに追加されます。 - job_name: "EC1-CS" # metrics_path はデフォルトで '/metrics' に設定されます # scheme はデフォルトで 'http' に設定されます。 static_configs: - targets: ['localhost:9664','localhost:9100'] remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces//api/v1/remote_write sigv4: region: queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 私たちのユースケースに合わせるために、 prometheus.yml ファイルで次の変更を行う必要があります: job_name を、観測性ダッシュボード上でこのシステムを識別できるような名前に変更してください。例えば、SAP Application Server EC2 インスタンスについては「SAP S41 App Server」、SAP 中央サービス EC2 インスタンスについては「S41 ASCS/ERS」などです。 targets の : 設定を変更します。ホストは Exporter が実行されているホストを、ポートは Exporter がメトリクスを公開しているポートを指定します (例: localhost:9100)。上記のように、複数のターゲットを設定できます。例えば、SAP Application Server EC2 インスタンスの yml ファイルの設定では、SAP Host Exporter と Node Exporter からメトリクスをスクレイピングするために、’localhost:9680′ と ‘localhost:9100’ の 2 つのターゲットエントリがあります。 yml ファイルの最後に remote_write URL セクションを追加します。remote_write URL は、ステップ 1 で AMP 作成時に控えた URL に、AWS リージョン (例: us-east-1) を指定して変更してください。 prometheus.yml ファイルを更新したら、以下のコマンドを実行してエージェントモードで Prometheus を実行します。 ./prometheus --config.file =./prometheus.yml --enable-feature = agent & 各 SAP コンポーネントの正しいポートを特定し、すべての EC2 インスタンスでこれらの手順を実行してください。 このタイミングで、データが AMP に送信されており、Amazon Managed Grafana の構成が可能になりました。 Prometheus Agent Mode エージェントモードでは、リモートライトユースケースに最適化されています。クエリ、アラーティング、ローカルストレージが無効化され、カスタマイズされたタイムシリーズデータベースのライトアヘッドログに置き換えられます。その他の機能(スクレイピングロジック、サービスディスカバリ、関連設定) は同じままです。 エクスポーターを systemd サービスとして有効化する これらのエクスポーターやエージェントを起動時に自動起動するように設定することをお勧めします。これは systemctl を使って行うことができます。以下が HA クラスターの例です。 systemctl --now enable prometheus-ha_cluster_exporters 他のサービスについても同じように設定できます。 systemctl についての詳細は、 SUSE のドキュメント を参照してください。 AMG の設定と監視ダッシュボードのセットアップ AMG は、可視化ツールの人気製品である Grafana のフルマネージドサービスで、Amazon Managed Prometheus と連携することで、メトリクス、ログ、トレースに対するクエリ、可視化、アラートを行えるようになります。 この項では、Amazon Managed Grafana (AMG) の構成方法と SAP S/4HANA の監視ダッシュボードのセットアップ方法について説明します。 この項に記載されている手順は、Amazon Managed Service for Prometheus (AMP) サービスで収集された SAP のメトリクスに対する監視ダッシュボードをセットアップするために必要な AMG サービスの構成手順を示しています。 3.1 Amazon Grafana でワークスペースを作成する Amazon Managed Grafana において Amazon Managed Prometheus をデータソースとして、新しいワークスペースを作成しましょう。Amazon Managed Grafana におけるワークスペースは、Grafana サーバーの論理的なユニットです。 AWS コンソールから Amazon Grafana サービスを開き、図 10 のように希望のエイリアスでワークスペースを作成します AWS IAM Identity Center(ID センター) と SAML の間から、好みの認証アクセス方法を選んでください オプションですが、推奨されるのは、SAP VPC 内のデータソースに接続する場合、ワークスペースから SAP VPC への VPC 接続を選択すること (これにより、パブリックインターネット経由のリクエストを回避できます) Service Managed と Customer Managed の間から、権限管理方式を選んでください 最後に、図 11 に示されているように、Data Sources のリストから Amazon Managed Prometheus をデータソース名として選択します 図 10: AMG ワークスペースエイリアス 図 11: AMG のデータソース名 数分かかりますが、この段階で Grafana ワークスペースの準備が整いました。 3.2 Amazon Grafana ワークスペースを構成する AMG でワークスペースの作成が完了したら、次は Amazon Managed Service for Prometheus (AMP) との統合です。ステップには Grafana ワークスペースコンソールでの管理者権限によるユーザー作成、Grafana ワークスペースコンソールでの AMP データソースの構成、Grafana ワークスペースコンソールへの監視用ダッシュボードのインポートが含まれます。 AMG では、Grafana コンソールへのアクセスの認証基盤として、AWS IAM Identity Center と SAML を認証基盤として利用できます。AMG ワークスペースのアクセスと Grafana ワークスペースコンソールの設定には、管理者ユーザーを設定する必要があります。ユーザーは AWS IAM Identity Center または外部の ID プロバイダに設定できます。この記事では、AWS IAM Identity Center にユーザーを設定しました。AWS IAM Identity Center に設定されたユーザーには、 AWSGrafanaAccountAdministrator と AWSSSODirectoryAdministrator のポリシーが必要です ( こちら を参照)。オプションのロールを確認し、必要に応じて割り当ててください。ワークスペースへのアクセスの認証方式として SAML を選択した場合は、記載された手順に従ってください。 ユーザーの作成後、Amazon Managed Grafana (AMG) ワークスペースにユーザーを割り当て、Grafana コンソールを設定するユーザーに対して「管理者権限を付与する」アクションを実行します。実行するには、AWS コンソールから AMG を開き、「すべてのワークスペース」をクリックし、新しく作成したワークスペースをクリックします。認証タブ内で、AWS Identity Center でユーザーまたはグループを追加するか、SAML 設定を行います。ユーザーが追加されたら、そのユーザーを選択し、アクションロップダウンから「管理者権限を付与する」を選択します (図 12 参照)。この手順を完了すると、管理者権限を付与したユーザーは、このワークスペースの Grafana コンソールを管理者として利用できるようになります。 図 12: AMG 用の AWS IAM Identity Center ユーザー Grafana ビューアユーザー ダッシュボードの作成には Admin ユーザーのみを使用し、ダッシュボードの表示にはセキュリティおよびコスト最適化の観点から「ビューア」ユーザーの使用を推奨します。 Grafana ワークスペースコンソールの URL を取得します。これを行うには、AWS コンソール内の Amazon Grafana サービスを開き、 全てのワークスペース をクリックし、新しく作成したワークスペースに関連付けられているワークスペース URL を見つけてください。図 13 のように表示されます。 図 13: Grafana ワークスペース URL の例 前のステップで管理者として構成したユーザー認証情報を使って、ワークスペース URL にアクセスし、AMG ワークスペースコンソールにログインします Grafana ワークスペースコンソールにログインした後、「アプリ」->「AWS データソース」->「データソース」の順に選択し、Amazon Managed Service for Prometheus の中からステップ 1 で作成した Amazon Managed Prometheus ワークスペースをメトリクス収集用に選択します (図 14 の通り)。 図 14: Grafana ワークスペースのデータソース設定 Amazon Managed Prometheus ワークスペースをデータソースとして正常に追加できると、Administration -> Data sources タブに設定済みのデータソースとして表示されます (図 15 参照)。 図 15: AMG のデータソースとして AMP 3.3 SAP レポートをインポート Grafana のダッシュボードは JSON 形式のレポートを使って作成できます。独自のレポートを作成するか、Grafana で提供されているレポートをインポートすることができます。このブログでは、インポートオプションを使用しており、使用するレポートは以下の通りです。 Node Exporter を使用した OS レベルのデータ (ID 1860) ASCS/ERS 上で Pacemaker を実行している HA クラスター (ID 12229) SAP Application Server (ID 12761) AMG ワークスペースコンソールにログインし、ダッシュボードタブに移動します。図 16 のように、JSON レポートをアップロードするか、Grafana.com のレポート ID でインポートして、レポートをインポートしてください。 図 16: JSON アップロードまたは Grafana.com のダッシュボード ID を使用してダッシュボードをインポートする すべてのレポートを追加した後、次のような画面が表示されます: 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターダッシュボード 図 19: ノードがダウンしたときのマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP アプリケーションサーバーディスパッチャーキューダッシュボード 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターのダッシュボード 図 19: ノードがダウンしている場合のマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP Application Server ディスパッチャーキュー ダッシュボード AMG データソースとマルチクラウドダッシュボード 設定手順と図 22 に示されているように、Amazon CloudWatch、Amazon Athena などの他のデータソースを指定できます。これにより、SAP 以外のシステムだけでなく、ハイブリッドおよびマルチクラウド環境のダッシュボード化が可能になります。 図 22: AMG のデータソース 結論 Prometheus と Grafana は、SAP ランドスケープを監視・可視化するための強力なオープンソースツールです。 AWS での AMP と AMG の利用により、組織はよりよい自動化とセキュリティポスチャを得ることができます。 SAP の可観測性ダッシュボードを構築するための AMP と AMG を使用することで、Prometheus と Grafana のデプロイやインフラストラクチャの管理、定期的なソフトウェアアップデートの実施などの負担なく、一元的に可観測性ダッシュボードを確認できます。 この記事では、Amazon Managed Prometheus と Amazon Managed Grafana を使用して、SAP S/4HANA システムの SAP 監視ダッシュボードをセットアップする方法について説明しました。 また、Grafana の他のデータソースを使用して、非 SAP システムを組み込む方法についても説明しました。 AMG、ダッシュボードの種類、セキュリティ機能の詳細については、 AWS ドキュメンテーション を確認してください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 あけましておめでとうございます。本年も週刊生成AI with AWSと、週刊AWSをよろしくお願いいたします。今年も最新情報をギュッとまとめてお届けしますので、引き続きご期待くださいね。 それでは、12 月 23 日週と 30 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: アオラナウ株式会社、AWSのGenUを活用した社内RAGシステムで技術調査業務の効率化を実現 アオラナウ株式会社様はServiceNowの価値を最大化することに取り組んでいます。50名を超える従業員には、技術的な熟練度が高いメンバーと未経験のメンバーが混在しており、それぞれ情報検索や個人が抱える課題の解決に時間を要する、同僚への質問を躊躇してしまうという課題がありました。これを解決するために Generative AI Use Cases JP(GenU) を活用し、高度なRAGシステムを短期間・低コストで構築することに成功しました。これによってドキュメント検索時間が1/5に、未経験メンバーから熟練メンバーへの質問件数の減少、質問自体の質の向上という成果を上げています。 ブログ記事「個性的なモデルに出会える Amazon Bedrock Marketplace で基盤モデルの選択肢を増やそう」を公開 世の中には様々な生成AIモデルがあります。AWS re:Invent 2024ではAmazon Bedrock Marketplaceが発表され、100以上のモデルをAmazon SageMakerにデプロイし、BedrockのAPIでアクセスすることが可能になりました。これによってBedrockで選択できるモデルではカバーできない、特徴をもったモデルを利用したくなった場合にも、アプリケーションの変更を最小限に抑えて最適なモデルを活用しやすくなります。この記事では、Amazon Bedrock Marketplaceの使い方や、日本発のモデルについて紹介しています。 ブログ記事「Stable Diffusion 3.5 Large が Amazon Bedrock でご利用いただけるようになりました」を公開 Amazon BedrockでStable Diffusion 3.5 Largeが利用できるようになりましたので、その深掘り記事を公開しました。 ブログ記事「Amazon Bedrock アプリケーションで責任ある AI のコアディメンションに対応するための考慮事項」を公開 責任あるAI活用の考え方は、生成AIの活用において重要度が高いテーマです。この記事は英語版の翻訳ですが、「責任あるAI」に含まれる概念を整理し、Amazon Bedrockでどのようにそれを実現していくかを説明しています。安全なAI活用のために、なにから始めればいいのか悩んでいる方におすすめの記事です。（大作なので徐々に読み進めるのも良いアイデアです） サービスアップデート Amazon Bedrock Agents, Flows, Knowledge Basesがレイテンシ最適化モデルに対応 AWS re:Invent 2024で発表された推論時のレイテンシーを最適化する機能に、Amazon Bedrock Agents, Flows, Knowledge Basesが対応しました。この最適化機能はAnthropic Claude 3.5 Sonnetと、Meta Llama 3.1 70B/405Bに対応しており、これらのモデルを利用する際に精度を損なうことなく推論時の遅延時間を短縮することでユーザ体験の向上につながります。ちなみにオレゴンリージョンでクロスリージョン推論を介して利用することが可能です。 AWS NeuronがTrainium2とNxD Inferenceに対応 Neuron 2.21 が発表され、AWS Trainium 2 チップを搭載したAmazon EC2 Trn2インスタンスと、Trn2 UltraServersがサポートされました。同時に、PyTorch 2.5がサポートされ、 NxD Inference (ベータ)とNeuron Profiler 2.0(ベータ)が利用可能になっています。NxD InferenceはvLLMと統合されたPyTorchベースのライブラリで、大規模言語モデルやマルチモーダルモデルのデプロイを簡素化します。 Amazon SageMaker JumpStartでMeta Llama 3.3 70Bが利用可能に Amazon SageMaker JumpStartを利用してMeta Llama 3.3 70Bモデルを利用できるようになりました。SageMaker JumpStartは数クリックで事前構築済みの機械学習ソリューションを数回のクリックで起動できる機械学習ハブで、最新のモデルを簡単に利用できます。詳細については ブログ記事 が出ていますので、そちらもご覧ください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

想像力豊かなクリエイティブを大手広告代理店やグローバルブランド、エンターテイメント企業向けに制作するには、限りない想像力が必要です。そのためには、 Hornet が 25 年以上にわたって実写映像、ビジュアルエフェクト（VFX）、ストップモーション、モーションデザイン、3D、セルアニメーション、ブランド戦略の仕事で発揮してきたような創造性が求められます。 こちらのスタジオでは継続的な成長と進化のため、作品の需要に応えるためにインフラストラクチャをレベルアップする必要があり、必要に応じたスケーラビリティ確保のため、Hornet はクラウドを活用する計画を立てました。SI 企業の インテグレーテッド・メディア・テクノロジーズ（IMT） と協力して、スタジオは最終的に Amazon Web Services (AWS) とのインテグレーションを選択し、効率的なクラウドベースのレンダーファームをデプロイしました。 「私たちの業界では、プロジェクトの増減にともなうリソースキャパシティーが常に課題となっていました。クラウドはそのための完璧なソリューションです。制作量の急増や特殊なマシン要件に対応するために必要な機材をすべて購入またはレンタルすることは、楽しくも経済的でもありません。そのため、必要に応じてリソースを増減できることは、私たちにとって大きなメリットとなります。」と、Hornet のマネージングパートナー Greg Bedard 氏 は語ります。 また、Hornet のパイプラインテクニカルディレクター Kevin Poli 氏は次のように付け加えています。「さまざまなクラウドオプションを検討しましたが、AWS は他とは比較にならないほど優れていました。これは間違いなく最も成熟したテクノロジーです。」「AWS のトレーニングを受けるための素晴らしい教育リソースがたくさんあり、とても利用しやすかったです。」 画像提供: Hornet 将来を見据えた構築 長年にわたってレンダリング管理ソフトウェア AWS Thinkbox Deadline を使用していた Hornet によるクラウドプロバイダーの決定の背景には、AWS とのネイティブ統合の影響もありました。スタジオは当初、2021 年にオンプレミスと AWS でハイブリッドレンダリングソリューションを開発していましたが、新しいクラウドベースの AWS 実装をゼロから構築したいと考えていました。この戦略は、2023 年にニューヨーク市のソーホー地区にある新しい場所へのスタジオ移転において、オンプレミスのデータセンター構築に多額の投資をせずに規模を拡大するための基盤となりました。人口密度の高い地域に移転すると、物理的な拡張はほとんど不可能になるため、機械をレンタルまたは購入するという物流上の問題を回避したいと考えていたためです。 クラウドベースのレンダリングに最適化することがパズルの最初のピースでした。セキュリティの強化も優先事項でした。Hornet のパイプライン責任者である Gareth Porter 氏は、「ファイルアクセスをより適切に制御できるようにしたかったのです。」と述べています。「IMT チームは、セキュリティのナビゲートに特に役立ちました。さらに、リソースの効率化のためにワークフローを最適化しました。」 Hornet は IMT チームと AWS サポートと協力して、オンプレミスインフラストラクチャに接続された AWS クラウドスタジオ環境を構築しました。デプロイには Amazon Elastic Compute Cloud ( Amazon EC2 ) スポットインスタンス によるレンダリングが含まれ、現在は GPU ベースのバーチャルアーティストワークステーションを含むように拡張されています。これにより、スタジオのリモートアーティストは、デジタルコンテンツ制作（DCC）ソフトウェアをクラウド上でローカルワークステーションと同じ応答性で実行するために必要となる高いパフォーマンスを得ることができます。 「私たちは AWS を使うには十分な知識がありましたが、クラウド上で複雑なプロダクションワークフローを構築するには十分ではありませんでした。IMT のおかげで、機能的なシステムを管理しているインフラストラクチャの中核要素に置き換えることができました。」と Poli 氏は説明しました。 「私たちのワークフローは今ではずっと安定しています。このプロセスと経験を積むことで、クラウドを最も効率的に使用する方法と、より多く成功するために管理する方法を理解し始めています。」と Porter 氏は付け加えました。 画像提供: Hornet クラウドへの接続 Hornet のオンプレミスファームは、アイドル状態または利用可能なコンピューティングを備えたアーティストワークステーションと専用のレンダリングノードが混在しています。マシンのスペックはさまざまで、チームは可用性と要件に基づいてレンダリングジョブを割り当てます。 「もし締め切りが間近に迫っていて、1 時間分のレンダリングをこなす必要がある場合は、できるだけ多くのノードを立ち上げてそれを実行します。」と Porter 氏は説明します。「私たちは、このシナリオで最も費用対効果の高いマシンを選択することを目指しています。時間があれば、より少ないノードを選択するかもしれませんが、そうでない場合は、状況に応じて必要なリソースを手に入れます。」 スタジオは AWS Thinkbox Deadline 10 を使用してハイブリッドレンダリングファームを管理し、 スポットイベントプラグイン を活用して Amazon EC2 スポットフリート でレンダリングリソースをスケーリングしています。Hornet の主要な制作ツールには、Autodesk Maya、Foundary Nuke、Maxxon Cinema 4D、SideFX Houdini などがあります。また、Blender と Epic Games の Unreal Engine についても研究しています。 「Thinkbox Deadline のスポットイベントプラグインは素晴らしいです。このおかげで、逼迫した時間帯にレンダリング担当者にとって大変なストレスになりかねない多くのタスクが自動化されます」と Poli 氏は語ります。「使用量ベースのライセンス（UBL）も、私たちにとって非常に大きな意味があります。すべてのコンピューティング環境が揃っていますが、サードパーティのリソースにも依存しています。Thinkbox Deadline を使用すると、それらを簡単に導入できます。AWS は究極の追加機能です。」 「業界標準ツールのレンダリングライセンスを個別に購入すると、それぞれ数百ドルかかり、一度に 1 台のマシンでしか使用できませんが、使用量ベースのライセンスでは、同じレートで 1 時間に 100 台のマシンを起動したり、10 台のマシンを 10 時間利用したりできるので、柔軟なソリューションとして有効です。」と Porter 氏は説明しました。 Hornet チームは、ジョブのタグ付けを通じてより多くのクラウド使用状況データを収集するようになったおかげで、レンダリング予算をより正確に見積もり、プロジェクトごとの支出を予測できるようになり、より自信を持って利用できるようになりました。 画像提供: Hornet プロダクションでのAWS利用 クラウドの導入によって、Hornet はクライアントからのフィードバックをもとに、アーティスティックな戦略をたて、技術的な実現を最短の工程で実行できるようになりました。柔軟性の高いスケーラビリティにより、スタジオはより大規模で複雑な作業を引き受けられるようになりました。この能力は、仮想ワークステーションの利用が開始されるとさらに強化されます。アーティストの観点から見ると、クラウドで強化されたワークフローでは、ユーザー体験に影響を与えることなくレスポンスがすぐに返ってくるため、試行錯誤の時間を短縮し制作を加速することができます。 「私たちは主にコマーシャル分野に携わり、制作期間は通常 1 〜 2 か月なので、時間の余裕はありません。AWS は、すぐに立ち上げたり止めたりができるので、当社のようなスタジオにとってゲームチェンジャーとなります。」と Bedard 氏は言います。「ビジネスの観点から見ると、クラウドは非常に強力です。これまでクラウド制作を見てきましたが、他にこのような方法ははありません。」 「クラウドの外では、アーティストが数千フレームのシーケンスをレンダリングし、修正指示を受け取り、新しいバージョンを同じ日にサブミットすることは現実的ではありません。AWS といくつかの技術的な魔法でこれを実現できました。」と Poli 氏は言います。「予算とニーズに基づいてパラメータを調整できるので、レンダリング時間自体はあまり心配されません。アーティストは、限られたリソースの中で作業する代わりに、たくさんのテストをサブミットできます。また、ショットを仕上げるのに十分な計算能力があることを知っているので、より安心できます。」 Bedard 氏はこう締めくくりました。「当社の AWS ワークフローは、1 つの施設内でさまざまなクリエイティブ分野をサポートできるようにするための最善の道筋を示してくれます。特にレンダリングにおける使用量ベースのライセンス（UBL）は、私たちにとって大きなものでした。そして今、次のステップは仮想ワークステーションです。これらの基本的な要素は、パイプラインの成長と進化を続けるのに役立ち、IMT や AWS との関係により、はるかに早く開発面で達成したい場所にたどり着くことができました。」   クラウドベースのクリエイティブワークフローに AWS を使用する方法の 詳細を確認 するか、AWS for Media and Entertainment の担当者に お問い合わせ ください。 著者について Ellen Grogan Ellen Grogan は、AWS のメディアおよびエンターテイメント部門のシニアプロダクトマーケティングマネージャーです。 この記事は Hornet supercharges render capacity with AWS を翻訳したものです。翻訳はVisual Compute ソリューションアーキテクトの森が担当しました。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は、2024 年 11 月 22 日に公開された “ Simplifying developer experience with variables and JSONata in AWS Ste… ”を翻訳したものです。 この投稿は、Uma Ramadoss (サーバーレス担当 Principal Specialist SA) と Dhiraj Mahapatro ( Amazon Bedrock 担当 Principal Specialist SA) によって執筆されたものです。 AWS Step Functions において、変数と JSONata データ変換が導入されました。変数により、開発者は 1 つのステートでデータを割り当て、その後のステップで参照できるようになり、複数の中間ステートを経由してデータを受け渡す必要がなくなったため、ステートのペイロード管理が簡素になります。オープンソースのクエリおよび変換言語である JSONata により、日付と時刻の書式設定や数学的演算などの高度なデータ操作と変換できるようになりました。 この記事では、これらの新機能の強力な機能について詳しく説明します。具体的には、変数を使用したステート間のデータ共有を簡素にする方法と、高度な JSONata 式によるデータ操作の複雑さを軽減する方法について深く掘り下げていきます。 概要 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、HTTP API 統合など、複数のサービスを含む複雑なワークフローを構築するために Step Functions を利用します。 これらのワークフローの中で、さまざまなサービスとやり取りするためのステートを構築し、入力データを渡し、出力としてレスポンスを受け取ります。 Step Functions 自体の機能を超えた、日付、時刻、数値の操作には Lambda 関数を使用できますが、この方法では複雑になるにつれて、ペイロードの制限、データ変換の手間、さらなるステート変更などの課題が生じます。 これは、ソリューション全体のコストに影響を与えます。 この問題に対処するために、変数と JSONata を使用します。 これらの新機能を説明するために、 JSONPath ブログ で取り上げた保険業界の顧客オンボーディングプロセスのユースケースを考えてみましょう。 潜在顧客は、サインアップ時に名前、住所、保険への関心事項などの基本情報を提供します。 この Know-Your-Customer (KYC) プロセスでは、これらの詳細な情報を含むペイロードとともに Step Functions ワークフローが開始されます。 ワークフローでは、顧客の承認または拒否を判断し、通知します。 { "data": { "firstname": "Jane", "lastname": "Doe", "identity": { "email": "jdoe@example.com", "ssn": "123-45-6789" }, "address": { "street": "123 Main St", "city": "Columbus", "state": "OH", "zip": "43219" }, "interests": [ {"category": "home", "type": "own", "yearBuilt": 2004, "estimatedValue": 800000}, {"category": "auto", "type": "car", "yearBuilt": 2012, "estimatedValue": 8000}, {"category": "boat", "type": "snowmobile", "yearBuilt": 2020, "estimatedValue": 15000}, {"category": "auto", "type": "motorcycle", "yearBuilt": 2018, "estimatedValue": 25000}, {"category": "auto", "type": "RV", "yearBuilt": 2015, "estimatedValue": 102000}, {"category": "home", "type": "business", "yearBuilt": 2009, "estimatedValue": 500000} ] } } 従来のワークフロー図は新機能を適用する前のワークフローを示しており、新しいワークフロー図は変数と JSONata を適用して構築されたワークフローを示しています。 このワークフローは、 GitHub リポジトリ の main ブランチ (従来のワークフロー) と jsonata-variables ブランチ (新しいワークフロー) からアクセスできます。 図 1 : 従来のワークフロー 図 2: 新しいワークフロー セットアップ README の手順に従ってこのステートマシンを作成し、テストが完了したら後片付けを行ってください。 変数によるデータ共有の簡素化 変数を使用することで、後続のステートで参照される変数に、ステートの結果を宣言または代入することができます。1 つのステートで、静的データ、ステートの結果、JSONPath や JSONata 式、組み込み関数など、さまざまな値を持つ複数の変数を割り当てることができます。次の図は、ステートマシン内で変数がどのように割り当てられ、使用されるかを示しています。 図 3: 変数の割り当てとスコープ 変数のスコープ Step Functions における変数は、プログラミング言語と同様のスコープを持ちます。内部スコープと外部スコープがあり、それぞれのレベルで変数を定義します。内部スコープの変数は map、parallel、ネストされたワークフロー内で定義され、その特定のスコープ内でのみアクセス可能です。一方、外部スコープの変数はトップレベルで設定されます。一度変数が割り当てられると、実行順序に関係なく、後続のどのステートからでもこれらの変数にアクセスできます。しかし、このブログのリリース時点では、Distributed Map は外部スコープの変数を参照できません。 変数のスコープに関するユーザーガイド では、このようなエッジケースについて詳しく説明されています。 変数の割り当てと使用 変数の値を設定するには、特別なフィールドである Assign を使用します。このブログの後半にある JSONata の部分で、 {%%} の目的について説明しています。 "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" } 変数を使用するには、変数名の前にドル記号 ($) を付けて記述します。 { "TableName": "AccountTable", "Item": { "email": { "S": "{% $inputPayload.data.email %}" }, "firstname": { "S": "{% $inputPayload.data.firstname %}" },.... } JSONata によるデータ操作の簡素化 JSONata は、Json データ用の軽量なクエリおよび変換言語です。JSONata は、Step Functions 内の JSONPath と比較してより多くの機能を提供します。 QueryLanguage を "JSONata" に設定し、JSONata 式に {%%} タグを使用することで、ステートマシン内で JSONata を利用できます。 この設定 はステートマシンのトップレベルまたは各タスクレベルで適用できます。タスクレベルの JSONata を利用することで、JSONata と JSONPath の選択を細かく制御できます。この方法は、一部のステートを JSONata で簡素化し、残りのステートでは JSONPath を使い続けたい複雑なワークフローに有用です。JSONata は、JSONPath や Step Functions の組み込み関数よりも多くの関数と演算子を提供します。 ステートマシンレベルで QueryLanguage 属性を JSONata に設定 すると、JSONPath が無効になり、 InputPath 、 Parameters 、 ResultPath 、 ResultSelector 、 OutputPath の使用が制限されます。代わりに JSONata では Arguments と Output を使用します。 シンプルなステートの最適化 新しいステートマシンで最初に気づく点の 1 つは、以下の比較で示されるように、 Verification プロセスが Lambda 関数を使用していないことです。 図 4: Pass ステートに置き換えられた Lambda 関数 従来のアプローチでは、正規表現を使用してメールアドレスとソーシャルセキュリティナンバー (SSN) を検証する Lambda 関数が使用されていました。 const ssnRegex = /^\d{3}-?\d{2}-?\d{4}$/; const emailRegex = /^[a-zA-Z0-9._-] +@[a-zA-Z0-9.-] + \.[a-zA-Z]{2,4}$/; exports.lambdaHandler = async event => { const { ssn, email } = event ; const approved = ssnRegex.test(ssn) && emailRegex.test(email); return { statusCode: 200, body: JSON.stringify({ approved, message: `identity validation ${approved ? 'passed' : 'failed'}` }) } }; JSONata を使用すると、ステートマシンの Amazon States Language (ASL) を利用して正規表現を直接定義できます。 Pass ステートと JSONata の $match() を使用して、メールアドレスと SSN を検証します。 { "StartAt": "Check Identity", "States": { "Check Identity": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isIdentityValid": "{% $match($states.input.data.identity.email, /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/) and $match($states.input.data.identity.ssn, /^(\d{3}-?\d{2}-?\d{4}|XXX-XX-XXXX)$/) %}" } } } } 同様に、JSONata の高度な文字列関数 $length 、 $trim 、 $each 、 $not を使って、 Pass ステートの中で住所を検証できます。 { "StartAt": "Check Address", "States": { "Check Address": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isAddressValid": "{% $not(null in $each($states.input.data.address, function($v) { $length($trim($v)) > 0 ? $v : null })) %}" } } } } JSONata を使用する場合、 $states は 予約変数 になります。 結果の集計 以前は JSONPath では、 Choice ステート以外で式は使用できませんでした。しかし JSONata ではそのような制限はありません。この例では、 parallel ステートで各サブステップからの本人確認と住所確認の結果を収集しています。それらの結果を boolean 変数 isCustomerValid に集約しています。 "Verification": { "Type": "Parallel", "QueryLanguage": "JSONata", ... "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" }, "Next": "Approve or Deny?" } ここで重要な点は、 $states.result を介した結果へのアクセスと、{%%} 内での AND ブール演算子 の使用です。これにより、この変数を使用する後の Choice ステートがシンプルになります。 JSONata の Operators を使用することで、可能な限りこのような式を柔軟に記述でき、単純なデータ変換するをためのコンピュート層を削減できます。 さらに、 {%%} 内の式が true または false の値を返す限り、柔軟な JSONata 演算子および式を利用することで、 Choice ステートが簡単に使えるようになります。 JSONata 関数としての組み込み関数 Step Functions は、 Step Functions の組み込み関数 と同等の機能を提供するために、JSONata の組み込み関数が提供されています。 DynamoDB の putItem ステップでは、 States.UUID() 組み込み関数と同じ機能を持つ $uuid() の使用方法を示しています。 また、日付と時刻に関する JSONata 固有の関数も利用できます。 以下のステートは、DynamoDB テーブルにアイテムを挿入する前に、 $now() を使用して現在のタイムスタンプを ISO-8601 形式の文字列として取得する例を示しています。 "Add Account": { "Type": "Task", "QueryLanguage": "JSONata", "Resource": "arn:aws:states:::dynamodb:putItem", "Arguments": { "TableName": "AccountTable", "Item": { "PK": { "S": "{% $uuid() %}" }, "email": { "S": "{% $inputPayload.data.identity.email %}" }, "name": { "S": "{% $inputPayload.data.firstname & ' ' & $inputPayload.data.lastname %}" }, "address": { "S": "{% $join($each($inputPayload.data.address, function($v) { $v }), ', ') %}" }, "timestamp": { "S": "{% $now() %}" } } }, "Next": "Interests" } JSONata 式が ASL を利用してステートマシンを定義する際の開発者の負担を軽減するため、 S.$ 内で .$ 表記が不要になったことに注目してください。Step Functions 内で利用可能な 追加の JSONata 関数 についても調べてみてください。 高度な JSONata JSONata の柔軟性は、組み込み関数、 高階関数 のサポート、 関数型プログラミング構文 に由来します。JSONPath では、高度な式 "InputPath": "$..interests[?(@.category ==home) ]" を使用して、配列 interests から住宅保険関連の興味関心をフィルタリングしていました。JSONata は フィルタリング 以上の機能を提供します。たとえば、住宅保険の関心事を探し、カテゴリタイプが home の totalAssetValue を参照し、name や email などの既存のフィールドを JSONata 変数として参照できます。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests[category='home']{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果の JSON は次のようになります。 `{ "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1400000, "home": { "own": 2004, "business": 2009 } }` これらのステップに従うことで、すべての保険に関する関心事とその集約結果を収集し、1 つ上のレベルに進みます。カテゴリフィルターがもう存在しないことに注目してください。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果は次のようになります。 { "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1549000, "home": { "own": 2004, "business": 2009 }, "auto": { "car": 2012, "motorcycle": 2018, "RV": 2015 }, "boat": { "snowmobile": 2020 } } 複雑な式の探索 サンプルデータと JSONata プレイグラウンドを利用 して、要件に合った詳細で複雑な式を見つけてください。以下は JSONata プレイグラウンドの使用例です。 図 5: JSONata プレイグラウンド 考慮事項 変数のサイズ 1 つの変数の最大のサイズは 256KiB です。 この制限は、ステート出力を別々の変数に格納することで、Step Functions のペイロードサイズ制限を回避するのに役立ちます。 個々の変数のサイズは最大 256KiB ですが、単一の Assign フィールド内のすべての変数の合計サイズは 256KiB を超えることはできません。 この制限を回避するには Pass ステートを使用できますが、格納されたすべての変数の合計サイズは、1 回の実行につき 10MiB を超えることはできません。 変数の可視性 変数は、ステート間でデータを共有するのを簡単にする強力な仕組みです。使いやすく柔軟であるため、 ResultPath 、 OutputPath 、JSONata の Output フィールドよりも変数を優先してください。ただし、 Output を使う可能性のある場面が 2 つあります。1 つ目は、外側のスコープから内側のスコープの変数にアクセスできない場合です。この場合、 Output フィールドを使うと、ワークフローの異なるレベル間でデータを共有できます。2 つ目は、ワークフローの最終ステートからレスポンスを送信する際に、 Output フィールドを使う必要がある場合です。以下の JSONPath から JSONata への移行図に、その詳細を示しています。 図 6: JSONPath から JSONata への移行 さらに、特定のステートに割り当てられた変数は、同じステートからはアクセスできません。 "Assign Variables": { "Type": "Pass", "Next": "Reassign Variables", "Assign": { "x": 1, "y": 2 } }, "Reassign Variables": { "Type": "Pass", "Assign": { "x": 5, "y": 10, ## The assignment will fail unless you define x and y in a prior state. ## otherwise, the value of z will be 3 instead of 15. "z": "{% $x+$y %}" }, "Next": "Pass" } ベストプラクティス Step Functions の 検証 API は、ワークフローのセマンティックチェックを提供し、早期の問題発見を可能にします。 ワークフローの安全な更新を確実するために、検証 API と バージョニングとエイリアス を組み合わせて、段階的にデプロイすることをお勧めします。 JSONata の複数行の式は有効な JSON ではありません。したがって、セミコロン “;” で区切られた文字列として 1 行 を使用し、最後の行で式を返すようにしてください。 相互排他 QueryLanguage タイプの使用は相互に排他的です。変数の割り当て時に JSONPath/組み込み関数と JSONata を混在させないでください。たとえば、以下のタスクは失敗します。変数 b は JSONata を使用していますが、 c は組み込み関数を使用しているためです。 "Store Inputs": { "Type": "Pass", "QueryLanguage": "JSONata" "Assign": { "inputs": { "a": 123, "b": "{% $states.input.randomInput %}", "c.$": "States.MathRandom($.start, $.end)" } }, "Next": "Average" } JSONPath で変数を使用するには 、 QueryLanguage を JSONPath に設定するか、タスク定義からこの属性を削除してください。 結論 変数と JSONata により、AWS Step Functions は開発者が Amazon States Language (ASL) で通常のプログラミングパラダイムに合わせた簡潔なコードでエレガントなワークフローを記述できるようになり、開発者体験が向上しました。 開発者は、余分なデータ変換のステップを省略することで、より高速に、クリーンなコードを記述できるようになりました。 これらの機能は、新規および既存のワークフローの両方で使用できるため、JSONPath から JSONata と変数への移行を柔軟に行うことができます。 変数と JSONata は、AWS Step Functions が利用可能なすべての AWS リージョンで追加料金なしでお客様にご利用いただけます。 JSONata と 変数 のユーザーガイド、および jsonata-variables ブランチの サンプルアプリケーション を参照してください。 サーバーレスに関する知識を深めるには、 Serverless Land をご覧ください。

みなさん、明けましておめでとうございます。ソリューションアーキテクトの杉山です。年末年始で 1 週 Skip させていただいたため、2 週まとめて 週刊AWS をお届けします。 年末年始に SNS でバズっていた (?) レシピを使って、自宅で豚骨ラーメンを作りました。まるで外出先のお店でいただけるような味にできて、ちょっとした充実があり、リフレッシュできました。 それでは、主なアップデートについて振り返っていきましょう。 2024年12月23日 – 30日 週の主要なアップデート 12/23(月) Amazon SES Mail Manager でログ機能に対応 Amazon SES の Mail Manager でログ機能を提供開始しました。Mail Manager は組織内でメールを送受信する際に、コンプライアンスを一元的に管理できる機能セットです。例えば、DKIM が Pass になったメールのみ受信する、Trend Micro Virus Scanning と連携しウイルススキャン後にメールを受信する、といったルール管理が可能です。この Mail Manager に CloudWatch Logs、S3、Firehose へログを出力する機能が追加され、詳細なトラブルシュートなどがやりやすくなりました。詳細は こちらの Document を参照ください。 Amazon Lightsail API エンドポイントが IPv6 での接続をサポート Amazon Lightsail API エンドポイントが IPv6 プロトコルをサポートし、IPv6 での接続が可能になりました。従来のエンドポイントは IPv4 専用でしたが、新たに IPv6 接続が可能な dual-stack エンドポイント（例 : lightsail.ap-northeast-1.api.aws）が追加されました。詳細は こちらの Document を参照ください。 AWS CloudTrail が Internet Protocol Version 6 (IPv6) をサポート AWS CloudTrail は CloudTrail API エンドポイントでデュアルスタックを導入し、IPv6 での接続が可能になりました。また、AWS PrivateLink を使用して VPC から CloudTrail API エンドポイントにプライベートにアクセスする場合でも、デュアルスタックが利用可能です。 12/26(火) Amazon EKS が Kubernetes バージョンのサポートステータスなどを取得する API を追加 Amazon EKS で Kubernetes バージョンのサポートステータスなどを取得する API を追加しました。 DescribeClusterVersions API を AWS CLI や SDK などから利用でき、各 Cluster Version のリリース日、Standard Support の期限、Extended Support の期限などを確認できます。また、各バージョンについて、現状 Standard Support なのか、Extended Support なのか、サポート期限切れかどうかを確認できます。従来 AWS Document から確認 できましたが、これをプログラムから取得できるようになった形です。 12/27(水) Amazon EC2 I7ie インスタンスが AWS US East (Ohio)、US West (Oregon) リージョンで利用可能 Amazon EC2 で、I7ie インスタンスがオハイオ、オレゴンリージョンで利用可能になりました。I7ie は高密度ストレージ最適化インスタンスで、大規模なデータセットにアクセスする際に、非常に低いレイテンシーで、高いランダム読み取り/書き込み性能が必要なワークロードに最適です。最大 120 TB のローカル NVMe ストレージを提供し、前世代インスタンスと比較して最大 2 倍の vCPU とメモリを提供します。 1/2(木) AWS Application Discovery Service で IPv6 エンドポイントをサポート AWS Application Discovery Service (ADS) で、IPv6 エンドポイントをサポートしました。Application Discovery Service は、クラウド移行の一環で、移行元のサーバーやアプリケーションを自動的に発見し、それらのシステム構成、使用状況、パフォーマンスデータ、などの詳細な情報を収集します。リソースのサイジング、アプリケーション間の依存関係の把握などに利用できます。IPv6 をサポートするようになり、より幅広いネットワーク環境でご利用しやすくなりました。 1/3(金) AWS WAF コンソールに新しいトップインサイトのダッシュボード機能を追加 AWS WAF のコンソールダッシュボードに、トラフィックに関するインサイトを提供する、より充実したダッシュボード機能を追加しました。CloudWatch Logs に蓄積しているデータを活用し、URI Path、HTTP Method、接続元 IP、User agent などの属性ごとにトラフィックデータを確認できるダッシュボードを提供するものです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに 生成 AI の活用が企業の競争力を左右する時代となっています。しかし、 PwC 社の 生成AIに関する実態調査2024 春 米国との比較 によると、「必要なスキルを持った人材がいない」や「ノウハウがなく、どのように進めれば良いか、進め方がわからない」、「意義やメリット、費用対効果を感じない」といった課題があるなど、多くの企業では、生成 AI の導入にあたって、技術的なハードルや、コスト面での課題を抱えています。 アオラナウ株式会社 （以下、アオラナウ）は、AWS が提供する Generative AI Use Cases JP （通称: GenU）を活用することで、わずか 2 週間という短期間で社内 RAG システムを構築し、ドキュメント検索時間が従来の 1/5 程度に短縮するなど、大幅な業務効率化を実現しました。本ブログは、アオラナウがどのように GenU を活用したか、アオラナウの AI プロダクト開発部の金山 陽希氏から寄稿いただいたものです。 課題：ベンチャー企業における業務効率化の必要性 アオラナウは、従業員数 50 名を超えるベンチャー企業です。技術的な熟練度が高いメンバー（高度技術者）と、未経験メンバーが入り混じっており、プロジェクト運営の際に以下のような課題が生じていました。 高度技術者は、膨大な技術ドキュメントの効率的な探索に時間がかかる 未経験メンバーは、高度技術者への問い合わせに時間を使っており、双方の時間を使われる 未経験メンバーは、忙しい高度技術者への質問を躊躇してしまう これらの課題を解決するために、最新の生成 AI 技術である RAG を利用したいと思いましたが、AI 導入においては、限られた予算内で実施できるよう工夫する必要がありました。 ソリューション：GenU を活用した社内 RAG システムの構築 AWS の AI/ML ソリューションアーキテクトである呉 和仁氏（ @kazuneet ）に相談したところ、AWS が提供する Generative AI Use Cases JP （通称: GenU、以降 GenU と略す）をご紹介いただき、私たちは GenU を基盤とした社内 RAG システムの構築を決定しました。 ＜GenU を採用したポイント＞ すぐにデプロイできる AWS の技術者が構築した質の高いコードがすぐデプロイできる状態で用意されており、自社での開発工数を大幅に削減できることが魅力でした。導入手順も丁寧に解説されており、AWS 未経験者でも容易に導入することが出来そうでしたし、結果として容易でした。 カスタマイズの柔軟性 最新の LLM モデルを設定ファイルの変更のみで導入できたりと、カスタマイズが柔軟にできるように設計されておりました。また、GenU の利用状況のモニタリングや、ユーザーからのハルシネーション報告などをもとにデータを修正するシステムを簡単に連結することが出来ました。 コスト最適化 サーバーレスアーキテクチャが最大限活用されており、ほぼ利用分のみの安価な運用コストも大変魅力的でした。ベクトル DBに Pinecone などのサードパーティー製品を利用するためのガイドもあり、さらなるコスト最適化の検討が容易なように設計されていました。 アーキテクチャ システムは以下のように、GenU をベースとして、弊社独自に GenU を管理するためのシステムを構築しています。 ServiceNow の技術ドキュメント（日本語/英語）60,000 ページと、600,000 件の QA データを元にした社内 RAG システムを、2 週間で構築することができました。 アオラナウでの GenU 構成 ユーザーは、GenU の画面から、RAG チャットを利用して技術的な質問をすることが出来ます。 アオラナウでの GenU 利用イメージ GenU管理システムでは、ユーザーの利用状況のモニタリングや、ユーザーからのハルシネーション報告を元にデータの修正作業を行えるようにしています。 アオラナウでの GenU ダッシュボード GenU の導入効果 GenU を導入することで、以下のような効果を月々数万円程度のコストで実現することが出来ました。 高度技術者は、ドキュメント検索時間が従来の 1/5 程度に短縮 未経験者の高度技術者への問い合わせ件数が削減 未経験者はまず GenU で調査した後、高度技術者に深い内容を聞くという質問の質の向上 結果として、プロジェクトを効率的に進めることができるようになったと体感しています。 今後、プロジェクトの成果物まで生成 AI が作成サポート出来るか、検証していく予定です。 まとめ GenU の活用により、私たちは短期間かつ低コストで高度な RAG システムを構築することができました。特筆すべきは、AWS の MLSA である呉氏による手厚いサポートです。技術的な課題に直面した際も、迅速な解決策の提案をいただき、スムーズな導入を実現できました。 ベンチャー企業にとって、効率的なリソース活用は重要な課題です。GenU は、その解決策として非常に有効なツールとなりました。今後も、AWS の提供するサービスを活用しながら、さらなる業務改善を進めていきたいと考えています。 執筆者について アオラナウ株式会社の AI プロダクト開発チームです。 金山 陽希 フルスタックエンジニア。ソリューションの設計、実装を担当しています。 新しいAI技術と前職でのWebアプリケーション開発の経験を活かし、なにかを実現することを楽しんでいます。 近頃足回りを囲むパネルヒーターを手に入れたので、今冬はこれだけで乗り切ろうかと画策中。 宍戸 凌雅 オペレーションエンジニア。本プロジェクトで運用設計を主に担当しています。 前職で培った経験を活かし、効率的で効果的な運用フローの構築に努めています。 生成AIを仕事やプライベートで積極的に活用しており、その可能性を追求することで世の中に貢献したいと考えています。 趣味は散歩や筋トレで、体力づくりを楽しみながらリフレッシュしています。 鄭 巽 AIエンジニア兼開発リードとして、チーム管理作業と実装作業を担当しています。 前職で培った統計知識と開発経験を活かし、適切な解決策を考えて事業価値を創出しています。 画像認識や生成モデルの分野に興味を持ち、実務の中で実践できることを楽しんでいます。 人と技術の橋渡し役として、チームのモチベーションを高めつつ、成果を引き出せるよう努めています。 保田 駿介 ServiceNowコンサルタント。お客様とのPoC実施、プリセールス活動を実施。生成AIを含むAI/ML技術の支援を担当しています。 様々な業界のServiceNowやSalesforceの導入を支援していた経験を生かし、ビジネス上の課題や業務課題解決するためのAI/MLソリューションの提案や導入支援に努めています。 BizDevの役割ではありますが、技術面もキャッチアップを怠らず進めていこうと思ってます。 李 溶基 ServiceNowアーキテクト。AWSとServiceNowの連携部分の開発を担当。REST API開発経験を生かし、ビジネス上の課題を解決するためのAI/MLソリューションの提案や導入支援に努めています。 プライベートではランニングやジム通いを通じてストレスを発散しています 伊藤 芳幸 エンジニア。前職の経験を活かし、AI/ML技術とServiceNowを融合させ、企業の生産性向上の新しい可能性を模索しています。 新しい技術に触れることは楽しみの一つで、積極的に手を動かしています。プライベートでは育児に忙しい日々を送っていますが、フットサルやジム通いを通じてストレスを発散しています。 参考情報 Generative AI Use Cases JP Amazon Bedrock ユーザーガイド AWS Lambda 開発者ガイド Meta knowledge for retrieval augmented large language models (amazon science)