VMware ワークロードは長年にわたり、多くのエンタープライズ IT 環境の重要な基盤となってきました。しかし、ビジネスニーズの進化に伴い、多くの組織が現在これらのワークロードをどのように実行するのが最適か – クラウドに移行するか、オンプレミスに残るか – を評価しています。 AWS への移行は、組織が運用を効率化し、俊敏性を高め、技術的負債を削減しながらイノベーションを推進するのに役立つメリットを提供します。クラウドのスケーラブルで弾力的なリソースにより、企業は動的なワークロード要件を満たすためにオンデマンドでコンピューティング能力をプロビジョニングできます。この柔軟性はリソース利用を最適化するだけでなく、組織が消費したリソースに対してのみ支払うため、コスト削減にもつながります。 VMware ベースのワークロードを移行およびモダナイズ化しながらこれらのメリットを享受しようとする組織にとって、 AWS Migration Acceleration Program (MAP) が VMware ワークロードの移行をさらにサポートするように拡張されたことを発表できることを嬉しく思います。 MAP は、数十万のエンタープライズワークロードを移行した AWS の経験を活用して、クラウドへの移行を加速し簡素化する包括的で実績のあるクラウド移行プログラムです。MAP の拡張により、AWS は VMware ワークロードを AWS への移行に特化したツール、フレームワーク、リソース、トレーニングへのアクセスを提供します。 MAP は、Guardian Life が 18 ヶ月で 1,200 インスタンスにわたる 90 以上のアプリケーションを移行し、News Corp が 56 のデータセンターを 6 つに統合してインフラストラクチャの 75% をクラウドに移行し、Newsweek が全体的な月間運用コストを 75% 削減するのを支援しました。これらは、MAP が顧客にコスト削減 (1.5 倍)、スタッフの生産性 (5.7 倍)、ビジネスの俊敏性 (4.3 倍)、運用の回復力 (1.7 倍) の向上をどのように実現したかを示すほんの一例です。 既存の VMware ベースのワークロードを AWS でリホストするか、フルマネージド AWS サービス上でリプラットフォーム化するか、最新のクラウドサービスを使用してアプリケーションを完全にリアーキテクトするかにかかわらず、AWS MAP は移行を成功させるために必要なガイダンスと専門知識を提供します。MAP を使用することで、組織は実証済みの方法論とベストプラクティスを活用して、強固な AWS クラウド基盤を構築し、イニシアチブを加速し、リスクとコストを削減できます。 要約すると、MAP は AWS 認定移行パートナーと共に以下を提供します: リソースの適切なサイジングとライセンス支出の削減機会を特定するための無料の Optimization and Licensing Assessment (OLA) 。AWS ファイナンスのベンチマークデータによると、OLA を使用した顧客は 総所有コスト (TCO) を 36% 削減 できました。 対象となる移行に対して、AWSが提供する Cast、Cloudamize、CloudHedge、Concierto、Device42、Matilda Cloud、MontyCloud、RiverMeadow、Trianz およびその他の選定パートナーから、AWS 検証済みツールのライセンス。 AWS によるインベストメントにより、AWS サービスクレジット提供またはパートナー投資という形で、対象となる移行にかかる一時的な移行費用の相殺を顧客に支援します。 実証済みの方法論、フレームワーク、ツール、ベストプラクティス、専門知識。 クラウドスキルを構築し IT チームの準備を支援するための Migrating VMware Workloads to AWS と Migration Foundations Readiness Path を含む 500 以上のトレーニングコース。 私たちはサポートの準備ができています 最も包括的な機能、ツール、プログラム、専門知識、比類のないサービスの幅広さ、トレーニング、リソースを備えて、クラウドへの移行をサポートする準備ができています。コストの最適化、スケーラビリティの向上、新しいイノベーションの機会の解放を目指すなら、無料の 移行評価 をリクエストして今すぐ始めましょう。 さらに、無料のトレーニングモジュール Migrating VMware Workloads to AWS と Migration Foundations Readiness Path を探索して、ベストプラクティスを学び、その方法を確認してください。 専門家にご相談になりたい場合は、 こちら からお問合せください。 翻訳はソリューションアーキテクト 澤が担当しました。原文は こちら です。

こんにちは。ソリューションアーキテクトの阿南です。株式会社ファミリーマート（以下、ファミリーマート）システム本部 IT基盤部 クラウド推進グループでは、システム本部における AWS の開発・運用ガイドラインを定め、AWS システムの標準化を進めています。また、同 PMO・品質管理チームは、ファミリーマートのシステム開発プロジェクトにおいて客観的な視点で QCD を管理・コントロールしプロジェクトの品質を確保する取り組みをしています。本ブログは、ファミリーマートがどのように AWS 上で生成 AI をシステム開発に活用し、クラウド推進業務や品質管理業務の負荷低減を図っているか、ファミリーマート システム本部 IT 基盤部 クラウド推進グループ 朴明振 氏、柿澤拓哉 氏、同 PMO・品質管理チーム 藤田孝 氏から寄稿していただいたものです。 背景 AWS 阿南：クラウド推進業務に生成 AI を活用するに至った背景を教えてください。 ファミリーマート 朴氏：ファミリーマートはコンビニエンスストア事業に必要なシステムをオンプレミス環境で運用してきましたが、2017 年末からクラウドサービス (AWS) を活用することとなり、2024 年現在は多くのシステムが AWS で稼働しております。また、新規システムも多くが AWS 上での開発を予定しています。クラウド推進グループでは社内システムの AWS 移行・開発作業を支援しておりますが、生成 AI を利用することでより効率的な支援が可能であると判断し、導入を検討することになりました。 AWS 阿南：今回はクラウド推進業務に加えて、品質管理業務への生成 AI 活用もご検討されていますね。PoC の対象を拡大するに至った背景を教えてください。クラウド推進業務とは異なるニーズがあったのでしょうか？ ファミリーマート 藤田氏：PMO・品質管理チームはファミリーマートにおけるシステム開発の QCD 向上を目的として 2023 年に設立した新たなチームです。過去のシステム開発プロジェクトにおけるノウハウや教訓、PMO・品質管理チームメンバーのさまざまな知見を用いてプロジェクトを計画どおりの QCD で遂行していくことが求められます。システム開発の規模が大規模で複雑化することも多くあり、今までの教訓や担当者が持っている知見を効率的に活用をしていくことが望まれるという課題がありました。そのような背景の中、生成 AI を取り入れることで課題解決につながるのでは無いかと考えました。 チャットボットについて AWS 阿南：さっそくですが、業務を支援するために作成されたチャットボットについてお伺いしたいと思います。まずクラウド推進グループでは、どのような業務が対象となったのでしょうか？ ファミリーマート 朴氏：ファミリーマートでは既存システムとの連携とセキュリティ向上のためさまざまなルールを設けており、このルールに対した問い合わせ対応や手続きの案内などを対象として考えています。また、ファミリーマートでは AWS サポートセンターへ問い合わせた過去の実績をデータベースとして別途管理しており、ファミリーマート環境で発生したトラブルについて過去の実績を素早く回答を得られる仕組みも検討しています。 AWS 阿南：PMO・品質管理チームでは、どのような業務が対象となりましたか？ ファミリーマート 藤田氏：PMO・品質管理チームでは大きく３つの業務領域を対象としています。①品質向上（プロジェクトのリスク管理業務）②ノウハウ蓄積・共有（メンバー間でのノウハウ共有）③生産性向上（必要な社内情報に対してすみやかにアクセスして情報を入手出来ること） AWS 阿南：どちらの業務も、基準となるドキュメントやレビュー対象のドキュメントが存在し、その情報を効率的にまとめる、検索するという作業が重要なものですね。 ファミリーマート 朴氏：はい、そのため検索対象となるドキュメントを Amazon S3 のバケットに保存し、 Amazon Kendra から検索できるようにしました。Kendra の検索結果を Amazon Bedrock を通して大規模言語モデル（LLM）モデルを利用することで、自然言語での回答を得られる仕組みですね。またサポートへの問い合わせもクローズになるタイミングで自動的に S3 にアップロードし、定期的に Kendra に Syncできるようにしていますし、社内ドキュメントの内容も継続補強しています。 チャットボットのアーキテクチャ PoC の評価手法 AWS 阿南：評価手法についても事前に定義をして定量的な評価を実現されていました。どのような評価手法を取られたのかご紹介いただけますでしょうか？ ファミリーマート 藤田氏：PoC を開始するにあたり実施メンバー間でどうしたら効果的な PoC が出来るかディスカッションを経て PoC 計画を策定しました。ディスカッション時に多く懸念としてあがったのは PoC の進め方とゴールについてです。闇雲に実施しては最終評価が難しくなると考えたので、あらかじめ PoC 実施結果内容を定量的に測定することが出来るように工夫しました。具体的には、プロンプト自体に難易度のレベル定義づけをして（レベル低・中・高の順に進める）、生成された回答をさらに 5 段階（５：非常に役立つ〜 １：役立たない）で評価をし結果を数値化していきます。PoC の計画時点で最終評価があらかじめ定めたベースライン (3.0) の点数を超えることが出来れば次のステージに進むこととし、もし超えることが出来なければ PoC を中止することを事前に定義して進めました。 PoC で定義したプロンプトの難易度と結果評価レベル AWS 阿南：今回の PoC の評価はどのような結果となりましたか？ ファミリーマート 藤田氏：最終評価としては、全体平均 3.6 点となり事前に定めた基準「3.0」点を超える結果となりました。PoC で評価が高かったものは要約／テキスト生成／質問応答等の PoC カテゴリでした。PMO・品質管理チームではボリューム感のあるシステム開発ドキュメントを読み込むことも多いので、事前に生成 AI に要約させてポイントを理解して読むことで効率的／効果的に読込め生産性向上が期待出来ると考えています。逆にまだ実業務への活用には改善が必要があると思われたものは計算／推理を伴うものでした。 PoC の最終評価 工夫した点 AWS 阿南：今回活用の対象とした業務において、どのような要件があり、それらをどのような工夫で実現したか教えてください。標準的な RAG 構成では実現できないものがあったと思います。 ファミリーマート 柿澤氏：PMO・品質管理チームの業務では、各プロジェクトの設計資料が Kendra の検索対象となります。あるプロジェクトについての質問に他のプロジェクトの設計資料が参照されることが無いようにする必要がありました。PoC の段階では利用者も限定されていることもあり問題となることはありませんでしたが、今後対策すべき課題であると考えています。プロンプトで制御する方法も検討しましたが、厳密さを重視し、Kendra の Custom Document Enrichment 機能を用いて各ドキュメントにプロジェクトを示す属性を付与し、検索時に対象とするプロジェクトを Attribute Filter 機能で制限するという手法を採用予定です。 AWS 阿南：精度向上という観点では何か工夫がありましたか？ ファミリーマート 柿澤氏：AWS のブログ Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証 を参考に、Kendra に対するクエリを複数のクエリに拡張することで多様な検索結果を取得して精度を高める手法であるクエリ拡張を採用したいと考えております。PoC の中でそれぞれの質問に対して業務に役立つ回答が返ってきたかどうかを確認する過程で、役に立たない回答が返ってきた例では、そもそも Kendra からのドキュメント検索の時点で適切なドキュメントが検索できていないというケースが見られました。クエリ拡張を採用することにより、Kendra から適切なドキュメントを参照することができるようになり、最終的に Bedrock からもより業務に役立つ回答が生成できるようになる見込みとなります。 Why AWS？ AWS 阿南：システム本部支援のために、AWS の生成 AI を採用された決め手を教えてください。 ファミリーマート 朴氏：ファミリーマートでは既に多くのシステムが AWS で稼働しており、システム本部の開発業務をサポートするためのサービスとしては Bedrock と Kendra が最適であると思いました。また、GitHub の aws-samples にサンプルアプリケーション Generative AI Use Cases JP が公開されていて、迅速に PoC を進めることができることも大きい理由の一つです。 今後の展望について AWS 阿南：このチャットボットや、その他 AI の取り組みは今後どのように進めていく予定ですか。 ファミリーマート 朴氏：今のところは主な利用部署はクラウド推進グループと PMO・品質管理チームになっています。2024 年度下期から本格利用開始できるよう計画しています。また、AWS サービスと社内システムの開発タスクを連携して、システム本部全体的に活用できるように検討していく予定です。 著者について 朴 明振 韓国で大学を卒業し、日本でキャリアをスタート。インフラエンジニアとしてオンプレミス環境に関わりながら 2015 年に AWS と出会い、その後は AWS エンジニアとして会社に貢献しています。ファミリーマートには 2023 年入社、クラウド推進グループの CCoE メンバーとして主に AWS 環境の整備や改善を担当しています。 柿澤 拓哉 2012 年より SIer にて AWS をメインとしたインフラエンジニアとして従事。ファミリーマートの AWS の本格利用に伴い、2018 年より環境整備を担当し、現在もクラウド推進グループのメンバーとして対応。 藤田 孝 2024 年 1 月ファミリーマート入社。前職は SIer でシステム構築・運用やプロジェクトマネジメントを担当。専門領域はインフラ領域でファミリーマート PMO・品管チームにおいてもインフラ系のアーキテクトとしてシステム開発プロジェクトに対し客観的な視点で QCD 管理やコントロールを担当。

AWS User Group Japan (JAWS-UG) は、 「No Border」をテーマにした JAWS PANKRATION 2024 を主催しました。これは 24 時間のオンラインイベントで、世界中の AWS ヒーロー、AWS コミュニティビルダー、AWS ユーザーグループリーダーなどが、文化的なディスカッションからテクニカルトークまで、多岐にわたるトピックについて話し合います。このイベントの講演者の 1 人である Kevin Tuei 氏は、ケニアを拠点とする AWS コミュニティビルダー です。公の場での構築と、他の人との知識の共有の重要性を強調した Tuei 氏の講演は、このようなイベントにぴったりとマッチしていました。 8月19日週のリリース 8月19日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon S3 が条件付き書き込みのサポートを開始 –  Amazon S3 に条件付き書き込みのサポートが追加されました。これは、オブジェクトを作成する前にその存在をチェックする機能です。この機能を使用することで、複数のクライアントを使用する分散アプリケーションが共有データセット全体でデータを並行して同時更新する方法を簡素化できるようになります。各クライアントはオブジェクトを条件付きで書き込んで、別のクライアントが既に書き込んだオブジェクトが上書きされないようにすることができます。 AWS Lambda が再帰ループ検出 API を導入 – 再帰ループ検出 API により、個々の AWS Lambda 関数に再帰ループ検出を設定できるようになりました。これは、再帰パターンを意図的に使用する関数の再帰ループ検出を無効にすることで、これらのワークロードの中断を回避できるようにします。他の AWS サービスに対する Lambda の再帰ループ検出サポートの拡大に伴い、これらの API を使用することで意図的な再帰ワークフローの中断を避けることが可能になります。Lambda 関数の再帰ループ検出は、Lambda コンソール、AWS コマンドラインインターフェイス (CLI)、または AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (CDK) といった Infrastructure as Code ツールを使用して設定できます。この新しい設定オプションは、 AWS SAM CLI バージョン 1.123.0 と CDK v2.153.0 でサポートされています。 Amazon Bedrock バッチ推論 API の一般提供開始 – モデル評価、実験、オフライン処理の応答を得るために、 Amazon Bedrock を使用してプロンプトをバッチ処理できるようになりました。バッチ API を使用することで、基盤モデル (FM) を用いた推論をより効率的に実行できるようになります。また、応答を集約して、それらをバッチ分析することも可能です。使用を開始するには、「 Run batch inference 」を参照してください。 AWS のその他のニュース 2024 年 7 月に開始された AWS GenAI Lofts は、進化する生成人工知能 (AI) テクノロジー環境でイノベーションとコミュニティを育むように設計されたグローバルツアーです。Lofts は、世界中の主要 AI ホットスポットにコラボレーション型のポップアップスペースを設置することで、学び、構築し、つながるためのプラットフォームを開発者、スタートアップ、および AI 愛好家に提供します。イベントは世界各国で開催中です。お近くの開催地を見つけて、今すぐ参加しましょう。 今後の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントの詳細については、こちらをご覧ください 。個人的な話になりますが、私は8月26日週の木曜日に開催される AWS Summit Johannesburg で基調講演者の 1 人としてお話しできるのを楽しみにしています。 登録は現在も受け付け中です 。ここで参加者の皆さんにお会いできるのを心待ちにしています。 AWS Community Day – この記事の冒頭で紹介したものと同様の AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。ニューヨークにお住まいの場合は、8月26日週この地域で開催されるイベントがあります。 近日中に開催されるすべての対面およびバーチャルイベント は、こちらで閲覧することができます。 8月26日週のニュースは以上です。9月2日週の Weekly Roundup もお楽しみに! –  Veliswa 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server では、リージョン内リードレプリカとクロスリージョンリードレプリカの 2 つの一般的な読み取りスケール可用性オプションがあります。Amazon RDS のお客様はリードレプリカを使用して、分析ワークロードや読み取り目的のトランザクションワークロードをプライマリデータベースインスタンスからオフロードします。以前は、リードレプリカにはプライマリデータベースインスタンスが Multi-AZ 構成になっている必要がありました。ただし、お客様の中にはプライマリデータベースインスタンスの高可用性についてはあまり懸念していないものの、分析アプリケーションを低コストで提供するためにリアルタイムに近いデータレプリケーションを必要とするお客様もいます。プライマリインスタンスに対して分析クエリを実行すると時間がかかる傾向があり、その結果、他のトランザクション (OLTP) タイプのクエリがブロックされたりタイムアウトしたりする可能性があります。読み取り目的の分析クエリをプライマリインスタンスからオフロードすることで、ロックやブロッキング、クエリタイムアウトなどを減らし、プライマリインスタンスのパフォーマンスを向上させることができます。このようなお客様のニーズを考慮して、Amazon RDS for SQL Server は 2024 年 4 月 1 日に Single-AZ インスタンス用のリードレプリカを発表しました。 Multi-AZ 用の既存のリードレプリカ機能と同様に、Single-AZ 用の新しいリードレプリカ機能でも、Single-AZ インスタンスの読み取り可能なコピーを作成できます。Single-AZ のリードレプリカは、同じ AWS リージョン内またはリージョン間で作成できます。Single-AZ のクロスリージョンリードレプリカをクロスリージョンのディザスターリカバリーインスタンスとして使用することもできます。 この投稿では、Single-AZ のリードレプリカのアーキテクチャ、作成、監視について説明します。 Single-AZ のリードレプリカを使用するメリット Single-AZ リードレプリカには次の利点があります。 リードレプリカを使用して、Single-AZ プライマリインスタンスから分析ワークロードや読み取り目的のワークロードをオフロードできます。 リードレプリカを Single-AZ インスタンスに昇格させて、リージョン内またはリージョン間のディザスターリカバリーに役立てることができます。 Single-AZ のリードレプリカインスタンスの総コストは、Multi-AZ のリードレプリカインスタンスのコストに比べて低くなります。 同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカを作成できます。 Single-AZ のリードレプリカを使用する場合の制限事項 Single-AZ リードレプリカを使用するときは、次の制限に注意してください。 複数のリードレプリカを作成することは可能ですが、挿入、更新、削除を受け入れることができるのはプライマリ Single-AZ インスタンスのみです。 リードレプリカへの自動フェイルオーバーはできません。ただし、必要に応じてリードレプリカをスタンドアロンの Single-AZ インスタンスに昇格させることはできます。一度リードレプリカを昇格させると、元のプライマリ Single-AZ インスタンスのリードレプリカには戻すことはできません。 アベイラビリティグループのデータ同期モードは非同期であるため、特にリソース競合が発生してプロビジョニングが不十分なインスタンスでは、リードレプリカで同期レイテンシーが発生する可能性があります。SQL Server の設計上、REDO スレッドが対応するログレコードをリードレプリカに適用するまで、データ変更はリードレプリカに反映されません。 リードレプリカ内のデータベースのバックアップは作成できません。 プライマリ Single-AZ インスタンスで作成されたテーブルやデータベースユーザーなどのデータベースレベルのオブジェクトは、自動的にリードレプリカにレプリケートされます。ただし、リードレプリカインスタンスの作成後にプライマリ Single-AZ インスタンスに追加されたログインや SQL エージェントジョブなどのサーバーレベルまたはインスタンスレベルのオブジェクトは、リードレプリカインスタンスで手動で作成する必要があります。 ソリューション概要 リードレプリカを含む Single-AZ インスタンスは、プライマリアベイラビリティーゾーンの 1 つのノードとセカンダリアベイラビリティーゾーンの 2 番目のノードで構成されます。これらのノードにはそれぞれ独自の Always On アベイラビリティグループがあります。これらのインスタンス間の可用性グループにまたがる分散型可用性グループが作成されます。プライマリ Single-AZ インスタンスでコミットされたトランザクションは、非同期的にリードレプリカにレプリケートされます。プライマリ Single-AZ インスタンスとリードレプリカインスタンスには、フロントエンドアプリケーションの接続文字列に使用できる独自の RDS エンドポイントがあります。 次の図は、同じリージョン内の Single-AZ インスタンスのリードレプリカのアーキテクチャを示しています。 Single-AZ インスタンスのリージョンとは異なる別のリージョンにリードレプリカを作成することもできます。次の図は、クロスリージョンリードレプリカを備えた Single-AZ インスタンスのアーキテクチャを示しています。 同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカインスタンスを作成できます。より多くのリードレプリカを作成するビジネス上の理由がある場合は、プライマリインスタンスのリソース使用率を監視することが非常に重要であることに注意してください。ログレコードの読み取り、ログストリームの圧縮、および各レプリカへの送信を担当するバックグラウンドスレッドでは、リソースの競合 (CPU、スレッド、ネットワークなど) が発生し、パフォーマンスが低下する可能性があります。次の例は、2 つのリードレプリカを持つ Single-AZ インスタンスを示しています。RDS オートメーションは、作成したリードレプリカインスタンスごとに分散型可用性グループを作成します。 このアーキテクチャでは、OLTP タイプのトランザクションワークロードを Single-AZ エンドポイントに送信し、分析または読み取り目的のワークロードをリードレプリカエンドポイントに送信できます。 予期せぬ状況でリードレプリカの Single-AZ インスタンスがダウンし、回復不能な損傷を受けたり、アクセスできなくなったりした場合は、リードレプリカを Single-AZ インスタンスに昇格させて、アプリケーションのダウンタイムを減らすことができます。その後、Single-AZ インスタンス (プライマリに昇格したリードレプリカ) から新しいリードレプリカインスタンスを作成し、その新しいリードレプリカを指すように分析アプリケーションを再構成できます。 アプリケーションに同じ RDS Single-AZ またはリードレプリカインスタンスを指す接続文字列が複数ある場合は、対応する RDS エンドポイントを指す DNS レコードを作成することを検討してください。障害が発生した場合は、適切な RDS エンドポイントを指すように DNS レコードを更新できるため、1 つ以上のアプリケーションサーバーで複数の接続文字列を更新するオーバーヘッドを回避できます。 Single-AZ インスタンスに複数のリードレプリカを作成することは可能ですが、リソースの競合を避けるためにインスタンスのサイズ (インスタンスクラス、ストレージ IOPS、スループットなど) を適切に設定することが重要です。1 つ以上のリードレプリカの同期遅延は、SQL Server がプライマリデータベースレプリカのログファイルにログレコードを保持する原因になるためです。定期的なトランザクションログバックアップでは、ログレコードが送信されてリードレプリカにコミットされるまでログレコードをトランケートすることはできません。ログをトランケートできない場合、ログファイルは (設定されている場合) 自動的に拡張され 、最終的にディスク領域がいっぱいになり、プライマリインスタンスが停止する可能性があります。 以下のセクションでは、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して Single-AZ インスタンスのリードレプリカを作成する方法を示します。 前提条件 このソリューションを設定するには、次の前提条件を満たす必要があります。 Microsoft SQL Serverの 分散型可用性グループ に関する基本的な知識。 サポート対象バージョンの SQL Server Enterprise エディションを実行しているアクティブな Single-AZ インスタンス (サポートされているマイナーバージョンの詳細については、「 RDS for SQL Server を使用したクロスリージョンリードレプリカ 」を参照してください)。Standard エディションでは現在、リードレプリカはサポートされていません。手順については、「 DB インスタンスの作成 」を参照してください。 バックアップ保持期間が 0 日を超えるプライマリ Single-AZ インスタンスで自動バックアップが有効になっていること。 コンソールを使用した Single-AZ のリードレプリカの作成 コンソールを使用してリードレプリカを作成するには、次の手順を実行します。 Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。 データベース一覧から Single-AZ インスタンスを選択します。 [アクション] メニューで [リードレプリカの作成] を選択します。 注意 : DB インスタンスは、SQL Server バージョン 2016 Enterprise Edition (またはそれ以降のバージョン) を実行する Single-AZ インスタンスである必要があります。サポートされているマイナーバージョンの詳細については、 リンク を参照してください)。 [DB インスタンス識別子] に、新しいリードレプリカインスタンスの名前を入力します。 [インスタンスの設定] セクションで、リードレプリカに適したインスタンスクラス (たとえば、db.m5.xlarge) を選択します。 特定の可用性グループでは、リソースの競合や同期のレイテンシーを避けるためにすべてのレプリカは同じワークロードを処理できる同等のインスタンスクラスとボリュームタイプで実行する必要があります。詳細については、「 可用性レプリカをホストするコンピューターに関する推奨事項 (Windows システム) 」を参照してください。 [AWS リージョン] では、アプリケーションのビジネス要件に基づいて適切なリージョンを選択します。 [ストレージタイプ] で、適切なストレージタイプ (gp2/gp3/io1/io2) を選択します。ストレージがいっぱいにならないように、ストレージの自動スケーリングを有効 / 無効にすることもできます。 io1/io2 を選択した場合は、プロビジョンド IOPS にも適切な値を指定してください。 gp3 を選択した場合は、プロビジョンド IOPS とストレージスループットに適切な値を指定してください。 I/O レイテンシーによってクエリの実行や同期のレイテンシーが発生しないように、ソースインスタンスと同様 (またはそれ以上) のストレージ構成を使用することをお勧めします。 [接続] セクションで、DB サブネットグループ、パブリックアクセス、VPC セキュリティグループ、およびアベイラビリティーゾーンの適切な値を選択します。要件に応じて、デフォルトまたは既存の値を選択できます。デフォルトのポート番号は 1433 です。別のポート番号を使用する場合は、「追加設定」で変更できます。 必要に応じて、インスタンスの Microsoft Windows 認証を選択します (詳細については、「 RDS for SQL Server による AWS Managed Active Directory の操作 」を参照してください)。ソースの Single-AZ インスタンスが既に Windows Active Directory ドメインの一部になっている場合は、適切なディレクトリを選択できます。 Single-AZ インスタンスが暗号化されている場合は、リードレプリカインスタンスの [暗号を有効化] をチェックします。暗号化されていない Single-AZ インスタンスから暗号化されたリードレプリカインスタンスを作成することはできません。 Performance Insights では、新しいリードレプリカの作成時に Amazon RDS Performance Insights を有効にすることも、後で有効にすることもできます。 無料で 7 日間のパフォーマンス履歴を保存できます。詳細については、「 Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング 」を参照してください。 [拡張モニタリングの有効化] をチェックすることも、後で有効にすることもできます。 拡張モニタリング は OS 関連の指標をキャプチャし、サーバーのリソース消費量やキャパシティプランニングなどの分析に使用できます。詳細については、「 Enhanced Monitoring の概要 」を参照してください。最大 7 日間の保存期間に対する拡張モニタリングは無料です。 ログ記録を長期間保存するビジネス上の理由があるかもしれません。[ログのエクスポート] で [エージェントログ] と [エラーログ] をチェックして、ログが Amazon CloudWatch にエクスポートされるようにします。 IAM ロールには、CloudWatch にログを公開するために使用する AWS Identity and Access Management (IAM) ロールを入力します。 設定値を確認し、[リードレプリカの作成] をクリックします。 AWS CLI を使用した Single-AZ のリードレプリカの作成 AWS CLI の create-db-instance-read-replica コマンドを使用して、Single-AZ インスタンスのリードレプリカを作成することもできます。構文の例を以下に示します。 aws rds create-db-instance-read-replica —db-instance-identifier < RR_INSTANCE_NAME > \ —source-db-instance-identifier < SOURCE_SINGLEAZ_INSTANCE_NAME > \ —region us-west-2 Bash たとえば、リージョン内の Single-AZ リードレプリカの場合は、次のコードを使用します。 aws rds create-db-instance-read-replica --db-instance-identifier singleaz-inst1-rr1 \ --source-db-instance-identifier singleaz-inst1 \ --region us-west-2 Bash クロスリージョン Single-AZ リードレプリカの場合は、次のコードを使用します。 aws rds create-db-instance-read-replica \ --db-instance-identifier singleaz-inst1-rr2 \ --source-db-instance-identifier arn:aws:rds:us-west-2: < CUSTOMER_ID > :db: singleaz-inst1 \ --endpoint-url https://rds-siteb.us-east-1.amazonaws.com \ --region us-east-1 --source-region us-west-2 Bash Single-AZ インスタンスのリードレプリカインスタンスを監視 他のタイプのリードレプリカと同様に、リソース消費量 (CPU、メモリ、I/O) を監視し、インスタンスのリソースを適切なサイズにすることが重要です。このキャパシティプランニングには、過去のベースライン消費量と将来のワークロード予測を使用できます。この目的には、拡張監視やパフォーマンスインサイトなどのツールを使用することも、サードパーティ製のツールを使用することも、SQL Server の組み込みの 動的管理ビュー と 動的管理関数 を使用してカスタム監視スクリプトを作成することもできます。リソースの使用状況を監視するだけでなく、同期レイテンシーも定期的に監視することをお勧めします。Amazon RDS ReplicaLag メトリクスを表示するか、T-SQL クエリを使用して定期的にラグ情報を収集することで、CloudWatch を使用してレプリケーションラグをモニタリングできます。 SELECT AR . replica_server_name , DB_NAME ( ARS . database_id ) 'database_name' , AR . availability_mode_desc , ARS . synchronization_health_desc , ARS . last_commit_time , ARS . last_hardened_lsn , ARS . last_redone_lsn , ARS . secondary_lag_seconds , ARS . redo_queue_size FROM sys . dm_hadr_database_replica_states ARS INNER JOIN sys . availability_replicas AR ON ARS . replica_id = AR . replica_id WHERE is_local <> 1 -- AND DB_NAME(ARS.database_id) = ' <REPLACE WITH SPECIFIC DB NAME> ' ORDER BY AR . replica_server_name ; SQL リードレプリカに関する一般的な運用上の考慮事項 リードレプリカを使用するときは、次の点に注意してください。 Single-AZ インスタンスとそのリードレプリカインスタンスには、さまざまなインスタンスクラスとボリュームタイプを使用できます。リードレプリカインスタンスを過少プロビジョニングすることは可能ですが、CPU やメモリの圧力、I/O レイテンシーによるクエリパフォーマンスの低下やデータ同期の問題を避けるため、リソース消費量を定期的に監視し、インスタンスクラスとストレージタイプのサイズを適切に決定することが重要です。 リードレプリカを初めて作成するとき、RDS オートメーションは Single-AZ インスタンスにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットバックアップを作成します。このスナップショットから新しいボリュームが作成され、リードレプリカインスタンスにアタッチされます。基盤となるストレージが Amazon Simple Storage Service (Amazon S3) のスナップショットバックアップから新しく作成された EBS ボリュームに対してストレージブロックをウォームアップするバックグラウンドプロセスである S3 ハイドレーションと呼ばれるプロセスを実行するため、新しく作成されたリードレプリカでは I/O レイテンシーが若干長くなります。その結果、最初の数時間は Always On レプリケーションラグとクエリ実行時のレイテンシーも大きくなることが予想されます。データがロードされていない場所でボリュームにアクセスすると、データがロードされている間、ボリュームにアクセスするトランザクションのレイテンシが通常よりも長くなります。ボリュームサイズが大きいほど、ハイドレーションが完了するまでの時間が長くなります。 リードレプリカを使用して Single-AZ インスタンスでデータベースを作成またはリストアすることができます。Amazon RDS のオートメーションにより、リードレプリカ内のデータベースが自動的にリストアおよびペアリングされます。ただし、Single-AZ インスタンスで作成したログインや SQL Agent ジョブなどのサーバーレベルのオブジェクトは、既存のリードレプリカに自動的にレプリケートされません。 リードレプリカは、分析タイプのワークロードをオフロードするためによく使用されます。分析ワークロードは tempdb データベースリソースを大量に消費する傾向があります。 tempdb の競合によるクエリのパフォーマンスの低下を避けるには、リードレプリカ内の tempdb データベースを監視し、適切なサイズを設定することが重要です。 Single-AZ インスタンスのアップグレード (メジャーバージョンまたはマイナーバージョン) を開始すると、Amazon RDS オートメーションは Single-AZ インスタンスのアップグレードとともにすべてのリードレプリカをアップグレードします。アップグレード中はインスタンスとデータベースにアクセスできないため、スケジュールされたメンテナンスウインドウ内でアップグレードを実行する必要があります。さらに、Single-AZ インスタンスとリードレプリカインスタンスに異なるバージョンの SQL Server を使用することはできません。 Single-AZ インスタンスからリードレプリカインスタンスへのデータ同期では、適切でないボリュームによる IOPS とスループットがボトルネックになる可能性があります。Single-AZ インスタンスとリードレプリカインスタンスに関連するボリュームを定期的に監視し、適切なサイズを設定することが不可欠です。 リードレプリカインスタンスはいつでも削除できます。1 つ以上のリードレプリカインスタンスを持つ Single-AZ インスタンスを削除すると、そのリードレプリカインスタンスは自動的に Single-AZ インスタンスに昇格します。昇格した Single-AZ インスタンスは必要に応じて削除できます。 結論 この投稿では、Amazon RDS for SQL Server Single-AZ インスタンスのリードレプリカが、Single-AZ インスタンスのスケーリングと、ソースの Single-AZ インスタンスからの読み取り集中型ワークロードのオフロードにどのように役立つかについて説明しました。さらに、ソースの Single-AZ インスタンスが使用できなくなった場合のディザスターリカバリーにも使用できます。過去のリソース消費量と将来のトランザクションリソースの予測に基づいて、リードレプリカインスタンス (CPU、メモリ、I/O) のサイズを適切に設定することが重要です。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Junu Thankappan は、アマゾンウェブサービスのシニアデータベースエンジニアです。AWS RDS チームで主に商用データベースエンジンと SQL Server を担当しています。

本ブログは「 Network perimeter security protections for generative AI 」を翻訳したものとなります。 生成 AI ベースのアプリケーションは、ここ数年で人気が高まっています。大規模言語モデル (LLM) を使ったアプリケーションは、企業が顧客に提供する価値を高める可能性があります。本ブログでは、生成 AI アプリケーションのネットワーク境界の保護について詳しく説明します。ネットワーク境界の保護の検討すべき様々な領域を説明し、それらが生成 AI ベースのアプリケーションにどのように適用されるかを議論し、アーキテクチャパターンを提供します。生成 AI ベースのアプリケーションにネットワーク境界の保護を実装することで、不正使用、コスト超過、分散型サービス拒否攻撃 (DDoS)、その他の脅威アクターや好奇心旺盛なユーザーからの保護に役立つコントロールが得られます。 LLM の境界での保護 Web アプリケーションのネットワーク境界の保護は、次のような重要な質問に答えるのに役立ちます。 アプリにアクセスできるのは誰ですか? アプリに送信されるデータの種類は何ですか? アプリが使用できるデータ量はどのくらいですか? ほとんどの場合、他の Web アプリと同じネットワーク保護の方法が生成 AI アプリにも機能します。これらの方法の主な焦点は、アプリが作成する特定のリクエストや応答ではなく、アプリにアクセスしようとするネットワークトラフィックをコントロールすることです。ここでは、ネットワーク境界の保護の 3 つの主要な領域に焦点を当てます。 アプリのフロントエンドの認証と認可 Web アプリケーションファイアウォールの使用 DDoS 攻撃からの保護 これらのアプリで LLM を使用することに関するセキュリティ上の懸念 (プロンプトインジェクション、機密情報の漏洩、過剰な代理行為など) については、この記事の範囲外です。 フロントエンドの認証と認可 ネットワーク境界の保護を設計する際、まずユーザーが認証 (AuthN) されているかどうか、および生成 AI ベースのアプリケーションに特定の質問をする権限 (AuthZ) があるかどうかに基づいて、特定のユーザーにアプリケーションへのアクセスを許可するかどうかを決める必要があります。多くの生成 AI ベースのアプリケーションは認証レイヤーの背後に配置されているため、ユーザーはアプリケーションにアクセスする前に ID プロバイダーにサインインする必要があります。認証の背後にない公開アプリケーション (チャットボットなど) の場合、次の 2 つのセクションで説明する AWS WAF と DDoS 保護に関して、追加の考慮が必要です。 例を見てみましょう。 Amazon API Gateway はアプリケーションフロントエンドのお客様向けのオプションであり、認証と認可を使用してユーザーや API を可視化します。フルマネージドされたサービスで、開発者が大規模に API を公開、保守、監視、セキュアにするのに役立ちます。API Gateway では、 AWS Lambda オーソライザーを作成してアプリケーション内の API へのアクセスをコントロールします。図 1 は、この例でのアクセスの仕組みを示しています。 図 1: クライアント～ LLM 間のシグナルパスにおける API Gateway、Lambda オーソライザー、基本的なフィルター 図 1 のワークフローは次のとおりです。 クライアントは API Gateway がフロントエンドとなる API にリクエストを送信します API Gateway はリクエストを受信すると、OAuth、SAML、または他のメカニズムを通じてリクエストを認証する Lambda オーソライザー にリクエストを送信します。Lambda オーソライザーは、API Gateway に AWS Identity and Access Management (IAM) ポリシーを返し、リクエストを許可または拒否します 許可された場合、API Gateway は API リクエストをバックエンドアプリケーションに送信します。図 1 では、これは LLM セキュリティの領域で追加の機能を提供し、より複雑なフィルタリングの代わりとなる Lambda 関数です。Lambda オーソライザーに加えて、クライアントごと、またはクライアントがアクセスするアプリケーションメソッドごとに API Gateway でスロットリングを設定できます。 スロットリング により、DDoS 攻撃だけでなく、モデルクローニングやモデル反転攻撃に対してある程度の緩和策を提供できます 最後に、アプリケーションは AWS 上にデプロイされた LLM にリクエストを送信します。この例では、LLM は Amazon Bedrock にデプロイされています Lambda オーソライザーとスロットリングの組み合わせにより、境界での様々な保護メカニズムをサポートできます。まず、認証されたユーザーのみがアプリケーションにアクセスできるため、ボットや一般ユーザーのアクセスを防ぐことができます。次に、認証されたユーザーに対して、LLM への過剰な呼び出しによるコストを防ぐため、呼び出しレートを制限できます。そして、ユーザーがアプリケーションによって認証および承認された後、アプリケーションはユーザーが認可されているデータにのみアクセスできるように、ID の情報をバックエンドのデータアクセスレイヤーに渡すことができます。 API Gateway の他にも、AWS ではフロントエンドの認証と認可を提供するためのオプションがあります。 AWS Application Load Balancer (ALB) は、アクセス前に OIDC プロバイダーへの認証をリクエストする OpenID Connect (OIDC) 機能をサポートしています。内部アプリケーションの場合、 AWS Verified Access は、アイデンティティとデバイスの信頼シグナルの両方を組み合わせて、生成 AI アプリケーションへのアクセスを許可または拒否します。 AWS WAF 認証または認可の決定が行われた後、次の考慮事項はアプリケーション側のネットワーク境界の保護です。 OWASP Top 10 for Large Language Model Applications で説明されているように、生成 AI ベースのアプリケーションには新しいセキュリティリスクが特定されています。これらのリスクには、安全が確認されていない出力ハンドリング、安全が確認されていないプラグイン設計、およびアプリケーションが望ましい基準から外れた応答を返す原因となるその他のメカニズムが含まれます。例えば、脅威アクターは LLM への直接的なプロンプトインジェクションを作成し、LLM の不適切な動作を引き起こす可能性があります。これらのリスク (安全が確認されていないプラグイン設計) の一部は、ID の情報をプラグインやデータソースに渡すことで対処できます。ただし、これらの保護の多くは、ネットワーク境界の保護の範囲外であり、アプリケーション内のセキュリティの領域に該当します。ネットワーク境界の保護では、アプリケーションにアクセスできるユーザーを検証し、アプリケーションアクセスの前にアプリケーションレベルでネットワークルールとパターンに基づいて Web リクエストを許可、ブロック、または監視するルールをサポートすることに重点が置かれています。 さらに、ボットトラフィックは Web ベースのアプリケーションにとって重要な検討事項です。 Security Today によると、インターネットトラフィックの 47% がボットから発生しています。パブリックアプリケーションにリクエストを送信するボットは、より多くのリクエスト負荷を引き起こすため、生成 AI ベースのアプリケーションの使用コストを押し上げます。 ボットトラフィックから保護するため、アプリケーションへアクセスする前の境界の保護の一部として AWS WAF を実装できます。AWS WAF を使用すると、保護対象の Web アプリケーションリソースに転送される HTTP(S) リクエストを監視およびブロックするファイアウォールをデプロイできます。これらのリソースは、API Gateway、ALB、AWS Verified Access、およびその他のリソースの背後に存在します。Web アプリケーションの観点では、AWS WAF は LLM の呼び出しが行われる前に、アプリケーションへのアクセスを防止または制限するために使用されます。これは重要な検討事項です。なぜなら、LLM への入力と出力を保護するだけでなく、正当なトラフィックのみがアプリケーションにアクセスできるようにする必要があるからです。 AWS マネージドルール または AWS Marketplace のマネージドルールグループ では、ルールグループの一部として定義済みのルールが提供されます。 もうすこし前の例を掘り下げてみましょう。図 1 のアプリケーションがスケールアップし始めたので、 Amazon CloudFront の背後に移動することにしました。CloudFront は、エッジロケーションのグローバルネットワークを使用して、AWS への分散型のイングレスを提供する Web サービスです。分散型のイングレスを提供するだけでなく、CloudFront を使用すると AWS WAF ルールの一部として SQL インジェクション、ボット制御、その他のオプションに対する保護をグローバルにデプロイできます。図 2 の新しいアーキテクチャを見ていきましょう。 図 2:クライアントからモデルへのシグナルパスに AWS WAF と CloudFront を追加する 図 2 に示されたワークフローは次のとおりです。 クライアントは API にリクエストを送信します。DNS はクライアントを AWS WAF がデプロイされている CloudFront のロケーションに向けます CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを決定します。AWS WAF がトラフィックをブロックしない場合、AWS WAF はそれを CloudFront のルーティングルールに送ります 注: API Gateway へのアクセスを制限して、ユーザーが CloudFront ディストリビューションをバイパスしてAPI Gateway にアクセスできないようにすることをお勧めします。この目標を達成する方法の例は、「 Restricting access on HTTP API Gateway Endpoint with Lambda Authorizer 」ブログ記事にあります CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します さらに詳しく見るために、ボットトラフィックに焦点を当てましょう。 AWS WAF Bot Control を使用すると、スクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。Bot Control は、設定済みのルールと複数の検査レベルのオプションを提供します。たとえば、ルールグループの Targeted レベルを使用すると、自己識別しないボットにチャレンジを仕掛けることができるため、悪意のあるボットがあなたの生成 AI ベースのアプリケーションに対して操作するのがより困難で高コストになります。Bot Control のマネージドルールグループを単独で、または他の AWS マネージドルールグループと独自のカスタム AWS WAF ルールと組み合わせて使用できます。Bot Control は、図 3 に示すように、あなたのアプリケーションを標的にしているボットの数について詳細に可視化できます。 図 3: Bot Control ダッシュボードで確認できるボットリクエストと非ボットリクエスト この機能はどのように役立つでしょうか? 生成 AI ベースのアプリケーションでは、ボットやその他のトラフィックがアプリケーションをどのように標的にしているかを確認できます。AWS WAF は、特定のボットを許可したり、ボットトラフィックをアプリケーションからブロックしたりするなど、ボットトラフィックの Web リクエスト処理を監視およびカスタマイズするオプションを提供します。Bot Control に加えて、AWS WAF には、ベースラインルールグループ、ユースケース固有のルールグループ、IP レピュテーションルールグループなど、さまざまなマネージドルールグループが用意されています。詳細については、 AWS マネージドルールグループ と AWS Marketplace マネージドルールグループ のドキュメントをご覧ください。 DDoS 保護 本ブログで最後に取り上げるトピックは、LLM における DDoS です。他のレイヤー 7 アプリケーションに対する脅威と同様に、脅威アクターは非常に多くのリソースを消費するリクエストを送信する可能性があり、その結果サービスの応答性が低下したり、大量のリクエストを処理する LLM の実行コストが増加したりします。スロットリングは、ユーザーごとまたはメソッドごとのレート制限をサポートするのに役立ちますが、DDoS 攻撃はスロットリングでは対処が困難な、より高度な脅威ベクトルが使用されます。 AWS Shield は、インターネットに面するアプリケーションに対する DDoS 保護を提供し、Shield Standard ではレイヤー 3 と 4、Shield Advanced ではレイヤー 7 を保護します。例えば、Shield Advanced は、既にデプロイされている AWS WAF の一部である Web アクセスコントロールリスト (ACL) を使用して、エクスプロイトの一部である Web リクエストをカウントまたはブロックすることで、自動的にアプリケーションの脅威を緩和します。要件に応じて、Shield は複数のレイヤーで DDoS 攻撃から保護できます。 図 4 は、Shield を追加した後のデプロイメントの様子を示しています。 図 4: クライアントからモデルへのシグナルパスに Shield Advanced を追加する 図 4 のワークフローは次のとおりです。 クライアントは API にリクエストを送信します。DNS はクライアントを CloudFront のロケーションに向けます。そこには AWS WAF と Shield がデプロイされています CloudFront はリクエストを AWS WAF ルールに送り、トラフィックをブロック、監視、または許可するかを判断します。AWS Shield は、さまざまな既知の DDoS 攻撃ベクトルとゼロデイ攻撃ベクトル を軽減できます。設定に応じて、Shield Advanced と AWS WAF が連携して、個々の IP アドレスからのトラフィックをレート制限します。AWS WAF または Shield Advanced がトラフィックをブロックしない場合、サービスはそれを CloudFront のルーティングルールに送ります CloudFront はトラフィックを API Gateway に送り、図 1 で説明したのと同じトラフィックパスを通過します AWS Shield と Shield Advanced を実装すると、セキュリティイベントに対する保護と、グローバルおよびアカウントレベルのイベントの可視性が得られます。例えば、アカウントレベルでは、アカウントで見られたイベントの総数、各リソースの最大ビットレートとパケットレート、CloudFront の最大リクエストレートに関する情報が得られます。Shield Advanced では、Shield Advanced が検出したイベントの通知と、検出されたイベントと緩和策に関する追加情報にもアクセスできます。これらのメトリクスとデータは、AWS WAF とともに、あなたの生成 AI ベースのアプリケーションにアクセスしようとしているトラフィックの可視性を提供します。これにより、アプリケーションへのアクセスや LLM の呼び出しの前に、緩和機能が提供されます。 考慮事項 生成 AI アプリケーションをデプロイする際の境界の保護については、以下の点を考慮してください。 AWS では、フロントエンド側の認証と認可と、AWS WAF 側の両方で境界の保護を構成する複数のオプションを提供しています。アプリケーションのアーキテクチャとトラフィックパターンに応じて、 複数のリソース が AWS WAF で境界の保護を提供し、認証と認可の決定のために ID プロバイダーと統合できます また、Lambda 関数やその他の AWS サービスを使用して、デプロイメントアーキテクチャの一部として、より高度なLLM 固有のプロンプトフィルターと応答フィルターをデプロイすることもできます。境界の保護機能は、望ましくないトラフィックがエンドアプリケーションに到達するのを防ぐことに重点が置かれています LLM で使用される大半のネットワーク境界の保護は、他の Web アプリケーションのネットワーク境界の保護メカニズムと同様です。違いは、通常の Web アプリケーションと比べて、追加の脅威ベクトルが発生する点です。脅威ベクトルの詳細については、 OWASP Top 10 for Large Language Model Applications と MITRE ATLAS を参照してください 結論 本ブログでは、従来のネットワーク境界の保護戦略が、生成 AI ベースのアプリケーションに多層防御を提供する方法について説明しました。LLM ワークロードと他の Web アプリケーションの類似点と相違点について説明しました。認証と認可の保護が重要な理由を説明し、API Gateway を使用してスロットリングと Lambda オーソライザーを通じた認証を行う方法を示しました。次に、AWS WAF を使用してアプリケーションをボットから保護する方法について説明しました。最後に、AWS Shield がさまざまなタイプの DDoS 攻撃からスケーラブルで高度な保護を提供する方法について説明しました。ネットワーク境界の保護と生成 AI セキュリティの詳細については、 AWS Security Blog チャンネル の他のブログ記事を参照してください。 本ブログについてご質問がある場合は、 AWS サポートにお問い合わせください 。 Riggs Goodman III Riggs は AWS の Principal Partner Solution Architect です。現在の専門分野は AI セキュリティとデータセキュリティで、AWS で AI ワークロードを構築するための技術的ガイダンス、アーキテクチャパターン、リーダーシップを顧客とパートナーに提供しています。社内では、顧客とパートナーの課題に対処するための AWS サービスチーム全体の技術戦略とイノベーションの推進に注力しています。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

産業データは貴重なリソースであり、機械の性能、プロセス、製品に関する洞察を提供します。 このデータを収集して分析することで、企業は製品の品質を高め、効率を最適化し、サプライチェーンを管理し、予防保全を効果的にスケジュールできます。 ただし、産業用デバイスからのデータ収集は複雑なプロセスになる可能性があります。 通常、これらのデバイスはさまざまなベンダーによって製造されており、それぞれが独自のデータ形式、アドレッシング、およびプロトコルを使用しています。 また、実際の製造工程 (本番環境) に必要なソフトウェアを導入、運用していくためには、検証時よりもさらに複雑になることもあります。 Shop Floor Connectivity (SFC) は工場からのデータ収集を可能にするソリューションで、新規設備であってもレガシーなプロトコルを用いた既存設備であってもカスタマイズ可能な接続ソリューションを迅速に提供できます。 SFC は、既存の IoT データ収集サービスの制約に対処し、データ収集を統合することで、さまざまなベンダーの機器から一貫した方法でデータを収集し、さまざまな AWS サービスで使用できるようにしています。 SFC コンポーネント SFC を構成するコンポーネントには主に 3 つのタイプがあります。 プロトコルアダプター SFC コア ターゲットアダプター 図：SFC コンポーネントの概要 SFC コンポーネントの概要 プロトコルアダプター プロトコルアダプターは、いくつかの産業用デバイスからデータを読み取るために使用されます。このアダプターは、デバイスが使用しているプロトコルを抽象化し、追加のメタデータを含むデータを共通の形式で SFC コアに送信します。 このインターフェイスは、フレームワークの他の部分を変更することなく、新しいプロトコルアダプターで SFC を簡単に拡張できるように設計されています。 この記事の執筆時点で、SFC には Modbus TCP、MQTT、OPCUA、Ethernet/IP PCCC、ADS、SNMP、S7、および SQL 用のアダプターなどがあります。 (訳注：他にも対応プロトコルがあるため詳細は Github リポジトリ をご参照ください) SFC コア SFC コアコンポーネントは SFC フレームワークのコントローラーです。 プロトコルアダプターを介したデータ収集の設定とスケジューリングを処理します。 オプションで、60 種類以上の型変換などが可能な関数を組み合わせて、受信した各データ値を変換できます。これにより、複雑なデータ変換要件に対応できます。 SFC コアはエンドツーエンドにデータ型を忠実に連携でき、複雑な構造化データ型や多次元配列などについても、ソースから読み取ったデータ形式でターゲットに送信できます。 オプションとして、12 種類の集計関数を使用して、データをエッジでバッファリングして集約し、ネットワークトラフィックの削減が可能です。 SFC コアは AWS Secrets Manager と統合されているため、システム設定で使用するシークレットをプレースホルダーで指定できます。 ターゲットアダプター ターゲットアダプターは、SFC コアからデータを受信し、特定の AWS サービスやお客様独自のサービスに送信するコンポーネントです。 コンポーネントはオプションで Apache Velocity テンプレートを使用してデータ変換を適用し、受信サービスに必要な形式でデータを配信できます。 本記事の執筆時点では、 AWS IoT Analytics , AWS IoT Core , Amazon Kinesis Data Streams , Amazon Data Firehose , AWS Lambda , Amazon Managed Streaming for Apache Kafka (MSK) , Amazon Simple Storage Service (S3) , AWS IoT SiteWise , Amazon Timestream , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) のアダプターがあります。 ローカルファイルシステム、ターミナル出力、MQTT クライアント用の追加ターゲットも用意されています。 データ収集 データ収集は設定ファイルによって構成することができ、追加のコーディングは必要ありません。 これは、SFC コアプロセスにスケジュールを定義することによって実現されます。 各スケジュールの設定では収集間隔とデータソースを設定でき、様々な種類のデータソースから異なる形式のデータを設定をもとに読み取れます。ソースの種類はさまざまです。 ソースは、使用されるプロトコルアダプターと、そのアダプターを使用して読み取る必要がある値を定義します。 オプションで、変換と集計を定義して、収集したデータに適用できます。 1 つのスケジュールでは、収集および処理されたデータを送信するターゲットアダプターも指定します。 デプロイ SFC コアは、ユーザーが設定したコネクターとターゲットアダプターをロードする単一のプロセスとしてデプロイできます。 または、プロトコルアダプタ、ターゲットアダプタ、および SFC コアを、収集したデータを交換するために TCP/IP ストリームを介して通信する個々のサービスとして展開することもできます。 これらのサービスは、同じ物理マシンに配置することも、別の外部ハードウェアに配置することもできます。 この柔軟性により、データ収集と処理の負荷分散が可能になり、さまざまな接続要件と制限があるネットワークセグメントをまたいで展開できます。 以下の図は、いくつかのデプロイメント例を示しています。 図：SFC の構成例 SFC コンポーネントを実行するには Java 仮想マシンが必要です。 コンポーネントは、スタンドアロンのアプリケーション、コンテナとして、または AWS IoT Greengrass コンポーネントとして実行できます。 SFC の拡張 SFC は、新しいプロトコルとターゲットアダプタを簡単に実装し拡張できます。 新しいアダプターのコンポーネントを構築するには、開発者は SFC コアがアダプターと通信するために使用するアダプターのインターフェイスを実装する必要があります。 SFC は、開発者が SFC のコードを用いてプロトコルとターゲットの実装に集中できるように設計されていますが、必ずしも SFC のコードを修正する必要はありません。SFC は既存の設定 (Configuration) を組み合わせてカスタマイズされた設定プロバイダを構成できます。 SFC コンポーネントによって生成されるメトリクスは、 Amazon CloudWatch メトリクスやその他のメトリクスデータストアに送信できるように、カスタムメトリクスライター (書き込み機能) を構成できます。 カスタムログライターを設定することで、ロギング出力データをカスタムストアに書き込むこともできます。 OPC UA から Amazon S3 と AWS IoT Core への設定例 以下は OPC UA サーバーからデータを読み取り、データ加工や集計を行わずに AWS IoT Core サービスの MQTT トピックと Amazon S3 バケット内のオブジェクトに直接送信する簡単な設定例です。 さらに、下の画像には登場していませんがデバッグターゲットが含まれており、デバッグ目的でデータをコンソールに送信します。 図：設定ファイルで定義された構成のイメージ SFC 設定ファイル { "AWSVersion": "2022-04-02", "Name": "OPCUA to S3, IoT Core and console", "Schedules": [ { "Name": "OPCUA-DATA", "Interval": 1000, "Sources": { "OPCUA-SOURCE": ["*"] }, "Targets": ["IoTCoreTarget", "S3Target", "DebugTarget"] } ], "Sources": { "OPCUA-SOURCE": { "Name": "OPCUA-SOURCE", "ProtocolAdapter": "OPC-UA", "AdapterOpcuaServer": "OPCUA-SERVER", "SourceReadingMode": "Subscription", "Channels": { "ServerStatus": { "NodeId": "ns=0;i=2256" }, "SimulationCounter": { "NodeId": "ns=3;i=1001" }, "SimulationRandom": { "NodeId": "ns=3;i=1002" }, "LevelAlarm": { "NodeId": "ns=6;s=MyLevel.Alarm", "EventType": "ExclusiveLevelAlarmType" } } } }, "ProtocolAdapters": { "OPC-UA": { "AdapterType": "OPCUA", "OpcuaServers": { "OPCUA-SERVER": { "Address": "opc.tcp://sfc-server", "Path": "OPCUA/SimulationServer" } } } }, "Targets": { "IoTCoreTarget": { "TargetType": "AWS-IOT-HTTP", "TopicName": "sfc-data-topic", "Region": "eu-west-1", "CredentialProviderClient": "AwsIotClient" }, "S3Target": { "TargetType": "AWS-S3", "Region": "eu-west-1", "BucketName": "sfc-data-bucket", "Interval": 60, "BufferSize": 1, "CredentialProviderClient": "AwsIotClient", "Compression": "Zip" }, "DebugTarget": { "TargetType": "DEBUG-TARGET" } }, "AdapterTypes": { "OPCUA": { "JarFiles": ["/sfc/opcua/lib"], "FactoryClassName": "com.amazonaws.sfc.opcua.OpcuaAdapter" } }, "TargetTypes": { "AWS-IOT-HTTP": { "JarFiles": ["/sfc/aws-iot-http-target/lib"], "FactoryClassName": "com.amazonaws.sfc.awsiot.http.AwsIotHttpTargetWriter" }, "AWS-S3": { "JarFiles": ["/sfc/aws-s3-target/lib"], "FactoryClassName": "com.amazonaws.sfc.awss3.AwsS3TargetWriter" }, "DEBUG-TARGET": { "JarFiles": ["/sfc/debug-target/lib"], "FactoryClassName": "com.amazonaws.sfc.debugtarget.DebugTargetWriter" } }, "AwsIotCredentialProviderClients": { "AwsIotClient": { "IotCredentialEndpoint": "1234567890abcd.credentials.iot.eu-west-1.amazonaws.com", "RoleAlias": "TokenExchangeRoleAlias", "ThingName": "MyThingName", "Certificate": "/sfc/cert/certificate.crt", "PrivateKey": "/sfc/cert/private.key", "RootCa": "/sfc/cert/root.pem" } } } 設定のポイントとなる項目 Schedule : 設定の中心となるのが Schedule (スケジュール) で、この例では ‘OPCUA-DATA’ です。 このスケジュールは、データ取得のソースの概要を示し、収集間隔をミリ秒単位で設定し、データ配信のターゲットとなる宛先を指定します。 Sources : このセクションでは、データソースについて記述します。 この例では、単一の OPC UA ソースが定義されています。 このソース内の詳細として、アダプター名とデータの取得元となるアダプター内の特定のサーバーが含まれます。 チャンネルには、さまざまなタイプのソースアダプターに合わせたデータ項目が含まれています。 この例における OPC UA アダプターの場合、これらのチャンネルはデータノード、イベント、アラームなどのデータ項目を表し、それぞれが固有のノード ID で識別されます。 Protocol Adapters : 使用されるプロトコルアダプターは、このセクションで定義します。 各プロトコルアダプタータイプには固有の要素があります。 この例で使用されている OPC UA アダプターの場合、データが読み取られる実際の OPC UA サーバーの定義があります。 Targets : このセクションでは、データを配信する宛先を定義します。 ターゲットの種類ごとに、Amazon S3 ターゲットの場合は Amazon S3 バケット名、AWS IoT Core アダプターの場合はトピック名など、特定の要素があります。 Adapter Types and Target Types: 各アダプターとターゲットは各々の設定を持ちます。これらは AdapterTypes または TargetTypes セクションで設定する必要があります。 それぞれのタイプは、アダプターまたはターゲットを実装する JAR ファイルをロードする場所と、これらのインスタンスを作成するためのファクトリークラスの名前を定義します。 SFC コアは、この情報を使用して必要なアダプターとターゲットのインスタンスを作成します。 (注:これらのセクションは、アダプターまたはターゲットが SFC コアと同じプロセスで実行されている場合にのみ必要です。 アダプターまたはターゲットが IPC サービスとして実行される場合、アダプターはプロトコルまたはターゲットサーバーを参照します。これにより、アクセス可能なアドレスとポートが定義されます。) AWS IoT Credential Provider Clients: このセクションでは、AWS サービスへのアクセスを必要とするターゲットが使用するクライアントを定義します。各クライアントは、一時的な資格情報を取得するための X.509 証明書とキーファイルのセットを使用します。ロールエイリアスは、AWS サービスへのアクセスを許可するロールを指します。詳細については、AWS Security ブログの記事 “How to Eliminate the Need for Hardcoded AWS Credentials in Devices by Using the AWS IoT Credentials Provider” を参照してください。 SFC を利用開始するには SFC はソースコードとして提供されており、 https://github.com/aws-samples/shopfloor-connectivity から入手できます。GitHub の SFC リポジトリには、SFC の構成方法とカスタムコンポーネントの作成方法について詳しく説明されたドキュメントが含まれています。事前ビルドされた SFC パッケージは、 https://github.com/aws-samples/shopfloor-connectivity/releases からダウンロードできます。 SFC リポジトリには、この記事で使用した例の SFC のデプロイと構成に必要な手順を説明する包括的なクイックスタートガイドも含まれています。 投稿者について Arie Leeuwesteijn アマゾン ウェブ サービス (AWS) のプリンシパルソリューションビルダーである Arie Leeuwesteijn は、産業および製造業のクライアントに合わせたクラウドソリューションの設計を専門としています。 企業顧客を導く専門知識を持つ彼は、運用の最適化とビジネス価値の向上を目的としたクラウドサービスの実用化を促進しています。 このブログはソリューションアーキテクトの黒田が翻訳しました。原文は こちら です。

このブログは 2024 年 4 月 17 日に Bukhtawar Khan によって執筆された内容を翻訳したものです。原文は こちら を参照して下さい。 Amazon OpenSearch Service は最近、OpenSearch Optimized インスタンスファミリー (OR1) を導入しました。これは、内部ベンチマークで既存のメモリ最適化インスタンスと比較して最大 30% のコストパフォーマンスの向上を実現し、 Amazon Simple Storage Service (Amazon S3) を使用して 99.9999999% (イレブンナイン) の耐久性を提供します。この新しいインスタンスファミリーにより、OpenSearch Service は OpenSearch のイノベーションと AWS のテクノロジーを使用して、クラウドでのデータのインデックス作成と保存方法を再考します。 今日、お客様は大量のデータを取り込みながら、豊富でインタラクティブな分析を提供する機能により、運用分析に OpenSearch Service を広く使用しています。これらの利点を実現するために、OpenSearch は、データのインデックス作成とリクエストの処理を行う複数の独立したインスタンスを持つ大規模な分散システムとして設計されています。運用分析データが生成される速度と量が増加するにつれ、ボトルネックが発生する可能性があります。高いインデックス作成ボリュームを持続的にサポートし、耐久性を提供するために、OR1 インスタンスファミリーが構築されました。 この投稿では、OR1 インスタンスの新しいデータフローがどのように機能するか、新しい物理レプリケーションプロトコルによって高いインデクシングスループットと耐久性をどのように実現しているのかについて説明します。また、正確性とデータの整合性を維持するために解決したいくつかの課題についても詳しく説明します。 高スループットとイレブンナインの耐久性のための設計 OpenSearch Service は数万の OpenSearch クラスターを管理しており、高スループットと耐久性の目標を達成するために、お客様が使用する典型的なクラスター構成についての洞察を得ています。より高いスループットを達成するために、お客様はレプリカコピーを削除することでレプリケーションのレイテンシーを節約することがよくありますが、この構成では可用性と耐久性が犠牲になります。他のお客様は高い耐久性を必要とするため、複数のレプリカコピーを維持する必要があり、その結果、運用コストが高くなります。 OpenSearch Optimized インスタンスファミリーは、Amazon S3 にデータのコピーを保存することで、コストを低く抑えながら更なる耐久性を提供します。OR1 インスタンスでは、インデックス作成のスループットを維持しながら、高い読み取り可用性のために複数のレプリカコピーを構成しながら、インデックス作成のスループットを維持できます。 次の図は、OR1 でのメタデータ更新を含むインデックス作成フローを示しています インデクシングでは、個々のドキュメントは Lucene にインデックス付けされ、translog と呼ばれる先行書き込みログも追加されます。クライアントに確認応答を送り返す前に、すべての translog 操作は Amazon S3 でバックアップされたリモートデータストアに永続化されます。レプリカコピーが構成されている場合、プライマリコピーは正確性を保つためにすべてのレプリカコピーで複数のライターの可能性を検出するためのチェック (制御フロー) を実行します。 次の図は、OR1 インスタンスでのセグメント生成とレプリケーションのフローを示しています 新しいセグメントファイルが作成されるたびに、OR1 はそれらのセグメントを Amazon S3 にコピーします。転送が完了すると、プライマリは新しいセグメントがダウンロード可能になったことをすべてのレプリカコピーに通知する新しいチェックポイントを公開します。その後、レプリカコピーは新しいセグメントをダウンロードし、検索可能にします。このモデルは、Amazon S3 を使用して行われるデータフローと、ノード間トランスポート通信を介して行われる制御フロー (チェックポイントの公開と用語の検証) を分離します。 次の図は、OR1 インスタンスでのリカバリーフローを示しています OR1 インスタンスは、データだけでなく、インデックスマッピング、テンプレート、設定などのクラスターメタデータも Amazon S3 に永続化します。これにより、非専用のクラスターマネージャーセットアップでは一般的な障害モードであるクラスターマネージャークォーラムの損失が発生した場合でも、OpenSearch が最後に確認されたメタデータを確実に回復できるようになります。 インフラストラクチャの障害が発生した場合、OpenSearch ドメインは 1 つ以上のノードを失う可能性があります。このような場合、新しいインスタンスファミリーは、最後に確認された操作までのクラスターメタデータとインデックスデータの両方の回復を保証します。交換される新しいノードがクラスターに参加すると、内部クラスターリカバリーメカニズムは新しいノードのセットをブートストラップし、リモートクラスターメタデータストアから最新のクラスターメタデータを回復します。クラスターメタデータが回復された後、リカバリーメカニズムは、Amazon S3 から不足しているセグメントデータと translog を復元し始めます。次に、最後に確認された操作までのすべての未コミットの translog 操作が再生され、失われたコピーが復元されます。 OR1 の新しい設計では、検索の仕組みは変更されません。クエリは、インデックス内の各シャードのプライマリまたはレプリカシャードのいずれかによって通常どおり処理されます。データのレプリケーションに Amazon S3 を使用しているため、特定の時点ですべてのコピーが一貫性を保つまでに長い遅延 (10 秒程度) が発生する可能性があります。 このアーキテクチャの主な利点は、リーダーとライターの分離、コンピューティングレイヤーとストレージレイヤーの分離など、将来のイノベーションの基礎となるビルディングブロックとして機能することです。 レプリケーション戦略を再定義することでインデックス作成のスループットが向上する仕組み OpenSearch は、論理 (ドキュメント) レプリケーションと物理 (セグメント) レプリケーションの 2 つのレプリケーション戦略をサポートしています。論理レプリケーションの場合、データはすべてのコピーで個別にインデックス付けされるため、クラスターで冗長な計算が行われます。OR1 インスタンスは、データがプライマリコピーでのみインデックス付けされ、プライマリからデータをコピーすることで追加のコピーが作成される新しい 物理レプリケーション モデルを使用します。レプリカコピーの数が多い場合、プライマリコピーをホストするノードは、セグメントをすべてのコピーにレプリケートするために大量のネットワーク帯域幅を必要とします。新しい OR1 インスタンスは、 リモートストレージ オプションとして構成されている Amazon S3 にセグメントを永続的に保存することで、この問題を解決します。また、プライマリでのボトルネックなしにレプリカのスケーリングにも役立ちます。 セグメントが Amazon S3 にアップロードされた後、プライマリは新しいセグメントをダウンロードするようにすべてのレプリカに通知するチェックポイントリクエストを送信します。その後、レプリカコピーは増分セグメントをダウンロードする必要があります。このプロセスにより、データを冗長にインデックス付けするために必要なレプリカのコンピューティングリソースと、プライマリでデータをレプリケートするために発生するネットワークオーバーヘッドが解放されるため、クラスターはより多くのスループットを処理できます。レプリカが過負荷や遅いネットワークパスなどにより新しく作成されたセグメントを処理できない場合、レプリカは古い結果を返さないように一定のポイントを超えて失敗としてマークされます。 高い耐久性が良い理由と、それを適切に行うのが難しい理由 コミットされたすべてのセグメントは、作成されるたびに Amazon S3 に永続的に保存されますが、高い耐久性を達成する上での主な課題の 1 つは、スループットを犠牲にすることなく、クライアントへ確認応答を返す前にすべての未コミットの操作を Amazon S3 の translog に同期的に書き込むことです。新しいセマンティクスでは、個々のリクエストに追加のネットワークレイテンシーが発生しますが、他のスレッドがインデックスのリクエストを続けながら、指定された間隔まで単一のスレッドでリクエストをバッチ処理してドレインすることで、スループットへの影響がないようにしました。その結果、バルクペイロードを最適にバッチ処理することで、より多くの同時クライアント接続でより高いスループットを実現できます。 高い耐久性のあるシステムを設計する上での他の課題には、常にデータの整合性と正確性を強制することが含まれます。ネットワークパーティションなどの一部のイベントはまれですが、システムの正確性を損なう可能性があるため、システムはこれらの障害に対処する準備ができている必要があります。したがって、新しいセグメントレプリケーションプロトコルに切り替える際に、各レプリカで複数のライターを検出するなど、いくつかの他のプロトコルの変更も導入しました。このプロトコルは、クラスターマネージャークォーラムに基づいて新しく昇格されたプライマリが同時に新しい書き込みを受け入れている間に、分離されたライターが書き込みリクエストに応答できないようにします。 新しいインスタンスファミリーは、データの回復中にプライマリシャードの損失を自動的に検出し、Amazon S3 からデータを再ハイドレートしてクラスターを正常な状態に戻す前に、ネットワークの到達可能性に関する広範なチェックを実行します。 データの整合性のために、すべてのファイルは広範にチェックサムされ、ネットワークまたはファイルシステムの破損によってデータが読み取り不能になる可能性を検出して防止できるようにします。さらに、メタデータを含むすべてのファイルは不変になるように設計されており、破損に対する更なる安全性を提供し、偶発的な変更を防ぐためにバージョン管理されています。 データフローの再構想 OR1 インスタンスは、インフラストラクチャ障害時に失われたシャードのリカバリを実行するために、Amazon S3 から直接コピーを復元します。Amazon S3 を使用することで、プライマリノードのネットワーク帯域幅、ディスクスループット、およびコンピュートを解放でき、プライマリノードの調整を最小限に抑えてプロセス全体を調整することで、よりシームレスなインプレーススケーリングとブルー/グリーンデプロイメントエクスペリエンスを提供できます。 OpenSearch Service は、スナップショットと呼ばれる自動データバックアップを 1 時間間隔で提供します。これは、データが誤って変更された場合に、以前の時点の状態に戻るオプションがあることを意味します。しかし、新しい OpenSearch インスタンスファミリーでは、データがすでに Amazon S3 に永続的に保存されていることを説明しました。では、データがすでに Amazon S3 に存在する場合、スナップショットはどのように機能するのでしょうか？ 新しいインスタンスファミリーでは、スナップショットはチェックポイントとして機能し、ある時点で存在するセグメントデータを参照します。これにより、追加のデータを再アップロードする必要がないため、スナップショットはより軽量で高速になります。代わりに、その時点でのセグメントのビューを取得するメタデータファイルをアップロードします。これをシャロースナップショットと呼びます。シャロースナップショットの利点は、作成、削除、複製など、すべての操作に及びます。他の管理操作用に、 手動スナップショット で独立したコピーをスナップショットするオプションもあります。 まとめ OpenSearch はオープンソースのコミュニティ主導のソフトウェアです。レプリケーションモデル、リモートバックドストレージ、リモートクラスターメタデータなどの基本的な変更のほとんどは、オープンソースに貢献されています。事実、私たちはオープンソースファーストの開発モデルに従っています。 スループットと信頼性を向上させる取り組みは、学習と改善を続ける限り終わりのないサイクルです。新しい OpenSearh の最適化されたインスタンスは、将来のイノベーションへの道を開くビルディングブロックの基礎として機能します。私たちは信頼性とパフォーマンスの向上に向けた取り組みを継続し、新規および既存のソリューションビルダーが OpenSearch Service を使用して何を作成するかを楽しみにしています。本ブログにより、新しい OpenSearch インスタンスファミリーについての理解が深まり、このオファリングがどのように高い耐久性とより良いスループットを実現し、ビジネスのニーズに基づいてクラスターを構成するのに役立つかを理解できることを願っています。 OpenSearch への貢献に興味があれば、 GitHub issue を開いてあなたの考えを教えてください。また、OpenSearch Service で高いスループットと耐久性を実現した成功事例についてもぜひお聞かせください。 著者について Bukhtawar Khan  は Amazon OpenSearch Service のプリンシパルエンジニアです。分散型および自律型システムの構築に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。 Gaurav Bafna は Amazon Web Services で OpenSearch のシニアソフトウェアエンジニアです。分散システムの問題解決に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。 Sachin Kale は AWS で OpenSearch のシニアソフトウェア開発エンジニアです。 Rohin Bhargava は Amazon OpenSearch Service チームのシニアプロダクトマネージャーです。AWS での情熱は、顧客がビジネス目標を達成するために適切な AWS サービスの組み合わせを見つけるのを助けることです。 Ranjith Ramachandra は、Amazon OpenSearch Service のシニアエンジニアリングマネージャーです。ハイスケーラブルな分散システム、高性能でレジリエントなシステムに情熱を注いでいます。

English follows Japanese. Amazon Web Services （AWS）では、お客様の信頼を得て維持することが継続的な取り組みとなっています。お客様の業界のセキュリティ要件に応じて、コンプライアンスレポート、証明書、認証の範囲とポートフォリオを決定しています。 AWS が「政府情報システムのためのセキュリティ評価制度（以下、ISMAP ）」の下で更新（2024年4月30日付で 2024 年 12 月 31 日まで）されたことをお知らせいたします。 今回の登録範囲は、5リージョンが新たに追加されAWS アジアパシフィック（東京）リージョンと AWS アジアパシフィック（大阪）リージョンを含む 28 リージョンであり、 AWSサービスの14件追加されAmazon Bedrock を含む合計 171のAWS サービスです。 AWS は、2020 年 3 月に発効されて以来、ISMAP 運営委員会によるISMAP への認定を継続しております。 ISMAP は、パブリッククラウドサービスのセキュリティを評価する日本政府のプログラムです。ISMAP の目的は、政府調達のベースライン要件として、クラウドサービス事業者（CSP ）が遵守すべき共通のセキュリティ基準を示すものとなります。 本制度では、CSP が実施しなければならないクラウド・ドメイン、プラクティス、およびプロシージャに関するセキュリティ要件を導入しています。CSP は、ISMAP 登録事業者として申請するために、ISMAP が認定する第三者評価者である監査機関と契約し、セキュリティ要件への準拠を評価したうえで、日本政府のセキュリティ要件を満たした事業者として登録を行います。 ISMAP によるCSP の登録により、政府の調達部門や機関および重要インフラに該当するお客様は、登録されたCSP との連携を促進し、政府情報システムへのクラウドサービスの円滑な導入に貢献することができます。今回の更新は、日本政府が定めたコンプライアンス要件を満たし、安全なAWS のサービスをお客様に提供するために、AWS が積極的に取り組んできたことを示すものです。AWSを利用するサービスプロバイダーや顧客は、AWS サービスのISMAP 認証を活用して、自社のISMAP 認証プログラムをサポートすることができます。 ISMAP に登録されたAWSサービスの全リストは、 AWS Services in Scope by Compliance Program  で公開されております。 なお、ISMAP において登録されるクラウドサービスはAmazon Web Services となり、お客様はAmazon Web Services 全体の登録を受けたクラウドサービスとして利用することが可能です。AWS は、今回の監査対象期間において評価されたAWS の各種サービスを登録しています。AWS は継続的にサービスのアップデート、追加を行い、お客様への価値を提供しています。本登録外のサービスにおいても、お客様は各サービスの開発者ガイド、他の第三者による監査レポートの確認などによるリスク評価の上、お客様が設計するサービスへの利用可否を判断することが可能です。 また、AWS をインフラストラクチャとしてISMAP への登録を計画されているサービスプロバイダやお客様は、AWS Artifact よりISMAP Customer Package を利用することにより、責任共有モデルに基づくAWSの責任範囲とお客様の責任範囲、ISMAP において求められている様々なAWS からの情報提供、機能提供の概要を確認することが出来ます。なお、今回の更新にともない、ISMAP Customer Package の更新を予定しております。 なお、AWS の登録状況の確認や詳細なスコープ情報は、 ISMAP ポータル で確認することができます。 AWS では、これまで同様、お客様のビジネスニーズに基づいて、新しいサービスやリージョンをISMAP プログラムの対象にしていくことをお約束します。AWS におけるISMAP 認証の概要については、 ISMAP コンプライアンスページ を参照してください。ご不明な点がございましたら、ご遠慮なくAWSアカウントマネージャーまでお問い合わせください。 なお、Amazon Bedrock は、単一の API を介して AI21 Labs、 Anthropic、 Cohere、 Meta、 Mistral AI、 Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデル (FM) を選択できるフルマネージドサービスで、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。基盤モデル自体は、本ISMAP の対象範囲ではありません。詳しくは Amazon Bedrock の「よくある質問」 をご参照ください。 本Blogは、竹内 英稔、セキュリティアシュアランス本部グローバルAWSアシュアランス部 監査部長（日本）、および、松本 照吾、セキュリティアシュアランス本部セキュリティ本部 本部長、により執筆いたしました。 Earning and maintaining customer trust is an ongoing commitment at Amazon Web Services (AWS). Our customers’ security requirements drive the scope and portfolio of the compliance reports, attestations, and certifications we pursue. We’re excited to announce that AWS has achieved authorization under the Information System Security Management and Assessment Program (ISMAP) program, effective from December 1, 2023 to December 31, 2024. The authorization scope covers a total of 171 AWS services (an increase of 14 services over the previous authorization) including Amazon Bedrock, and across 28 AWS Regions (an increase of 5 Region over the previous authorization) including the Asia Pacific (Tokyo) Region and the Asia Pacific (Osaka) Region. This is the fourth time AWS has undergone an assessment since ISMAP was first published by the ISMAP steering committee in March 2020. ISMAP is a Japanese government program for assessing the security of public cloud services. The purpose of ISMAP is to provide a common set of security standards for cloud service providers (CSPs) to comply with as a baseline requirement for government procurement. ISMAP introduces security requirements for cloud domains, practices, and procedures that CSPs must implement. CSPs must engage with an ISMAP-approved third-party assessor to assess compliance with the ISMAP security requirements in order to apply as an ISMAP-registered CSP. The ISMAP program will evaluate the security of each CSP and register those that satisfy the Japanese government’s security requirements. Upon successful ISMAP registration of CSPs, government procurement departments, agencies, and critical infrastructure companies can accelerate their engagement with the registered CSPs and contribute to the smooth introduction of cloud services in government information systems. The achievement of this authorization demonstrates the proactive approach AWS has taken to help customers meet compliance requirements set by the Japanese government and to deliver secure AWS services to our customers. Service providers and customers of AWS can use the ISMAP authorization of AWS services to support their own ISMAP authorization programs. The full list of 171 ISMAP-authorized AWS services is available on the AWS Services in Scope by Compliance Program webpage , Note that the cloud service registered in ISMAP is Amazon Web Services, and customers can look as the scope. AWS has registered various AWS services under Amazon Web Services that have been evaluated during this audit period. AWS is continuously updating and adding services to provide value to customers. Even for services other than this registration, customers can determine whether or not they can be used for services designed by the customer after risk assessments based on the developer guide for each service, confirmation of audit reports by other third parties, etc. Also, by using the ISMAP Customer Package from AWS Artifact, our customers or partners can check the scope of responsibility of AWS and the scope of responsibility of customers based on the shared responsibility model, and the provision of information and functions from various AWS required by ISMAP. Note that we are planning to update the ISMAP Customer Package along with this update. And you can confirm the AWS ISMAP authorization status and find detailed scope information on the ISMAP Portal . As always, we are committed to bringing new services and Regions into the scope of our ISMAP program, based on your business needs. For an overview of ISMAP certification on AWS, see the ISMAP compliance page . If you have any questions, don’t hesitate to contact your AWS Account Manager. This blog was written by Takeuchi Hidetoshi, Security Assurance Division Global AWS Assurance Department Audit Manager (Japan), and Matsumoto Shogo, Head of Security Assurance, Japan.

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2024 年 9 月 26 日 (水) 13:00 ~ 17:10 に、モダナイゼーションやマイグレートをテーマにした AWS Innovate が開催されます。モダナイズによりビジネス価値を生み出すための主要なコンポーネントである、インフラ、アプリ、データの観点から最新のモダナイズ手法を学べるセミナーです。オンライン開催で空き時間に参加がしやすくなっており、ぜひ事前登録の上ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月19日週の主要なアップデート 8/19(月) AWS Code Build で Mac を利用したビルドサポート AWS CodeBuild で macOS アプリケーションをビルドできるようになりました。Apple M2 インスタンス上で macOS 14 Sonoma を稼働し、macOS アプリケーションのビルドを行う仕組みです。Apple システム (iOS、iPadOS、watchOS、tvOS、macOS) 向けのアプリケーションをビルド、テスト、署名、配布するには、Xcode を使用する必要がありますが、これを CodeBuild で対応できるようになった形です。料金についての留意点ですが、CodeBuild for macOS はリソースを事前に予約する仕組みで動作するため、ビルドが実行されていなくても、ビルド用マシンが確保されている時間分の料金が発生します。詳細は こちらのブログ をご参照ください。 Amazon S3 で認証されていない HTTP アクセスの料金を無料に変更 Amazon S3 は、認証されていないリクエストを無料にする変更を完了しました。この変更により、バケット所有者は、個々の AWS アカウントまたは AWS Organization の外部からリクエストを受けた場合、HTTP 403 (Access Denied) エラー応答を返しますが、認証されていないリクエストに関する料金は発生しません。2024 年 5 月 13 日にアナウンスされ、大半の S3 API に適用しましたが、現在すべての S3 API で対応しました。 SageMaker Pipelines で ML ワークフローを簡単に作成するドラッグ & ドロップ UI の対応 SageMaker Studio 内で利用できる SageMaker Pipelines で ML ワークフローを作成する際に、ドラッグ & ドロップでアイコンを配置する、視覚的にわかりやすい UI にアップデートしました。データサイエンティストや ML エンジニアは、コーディングをせずに、エンドツーエンドのAI/MLワークフローを作成して、モデルの Training、Fine-tune、デプロイができるようになりました。 こちらのドキュメント に新 UI の画像付きで紹介されています。 8/20(火) Amazon S3 で条件付き書き込みのサポートを追加 Amazon S3 で、オブジェクトの作成前にそのオブジェクトの存在をチェックできる条件付き書き込みのサポートを追加しました。この機能により、データのアップロード時に既存のオブジェクトを上書きしないようにする処理の簡素化などに利用できます。データのアップロード前にオブジェクトの存在をチェックする処理や、クライアントサイドのメカニズムを構築するといった負担を軽減できます。大規模な分析、分散機械学習、その他の高度に並列化されたワークロードのパフォーマンスやコスト効率の向上といったメリットがあります。 AWS Lambda で関数ごとに再帰的ループ検出の機能管理 AWS Lambda は関数ごとに再帰ループ検出の有効 or 無効を指定する機能をサポートしました。デフォルトで有効になっている Lambda の再帰ループ検出は、サポートされているサービス間の再帰呼び出しを自動的に検出して停止する予防的な機能です。いわゆる、無限ループを検知する機能となります。いままでは AWS アカウント単位の指定でしたが、関数レベルで制御できるようになりました。 8/21(水) Amazon Bedrock でバッチ推論機能の一般提供開始 Amazon Bedrock でプレビュー提供していたバッチ推論機能の一般提供を開始しました。バッチ推論は、推論リクエストを非同期で実行し、あとから結果を取得する仕組みです。オンデマンド料金の 50 % で利用できる点や、 Service Quota がオンデマンドとバッチ推論で分離されているのがうれしいポイントです。バッチ推論の完了時間は、ジョブのサイズなどさまざまな要因に依存しますが、一般的には 24 時間以内に完了すると期待できます。Anthropic、Meta、Mistral AI、Amazon のモデルで利用が可能ですが、リージョンによって利用可否が異なるため、 詳細はこちらの表 をご参照ください。 Amazon EventBridge Scheduler でデフォルトの Service Quota の上限緩和 Amazon EventBridge Scheduler でデフォルトのサービスクォータが引き上げられ、スケジュール数のクォータが 100 万から 1,000 万に、呼び出しスループットのクォータが 500 から 1,000 呼び出し/秒に増えました。また、CreateSchedule、DeleteSchedule、GetSchedule、UpdateSchedule の API リクエストレートのデフォルトクォータが、50 から 1,000 リクエスト/秒に引き上げられました。さらに上限を緩和したい場合、Service Quotas コンソールからリクエストする仕組みがあります。 8/22(木) AWS IAM で AWS PrivateLink をサポート AWS Identity and Access Management (IAM) で、AWS PrivateLink をサポートしました。PrivateLink を使用すると、IAM ロールの管理や一時的な認証情報の取得などを、パブリックインターネットを経由せずに AWS リソースへリクエストができます。組織内のセキュリティ基準を満たす選択肢が拡充した形です。 AWS CloudFormation の IaC Generator でリソース検出とテンプレートレビュー機能のアップデート AWS CloudFormation で、既存のリソースから CloudFormation Template ファイルを生成する IaC Generator に 2 つの新機能のアップデートがありました。IaC Generator がアカウント内のリソースのスキャンを終了した後、テンプレートに含めたいリソースをより簡単に見つけられるよう、さまざまなリソースタイプのグラフィカルな概要を表示するようになりました。また、リソースを選択した後、AWS Application Composer でテンプレートをプレビューできるようになり、視覚的に確認がやりやすくなりました。 AWS Amplify で複数の S3 バケットをサポート AWS Amplify で複数の S3 バケットのサポートを開始しました。Amplify Storage 機能は S3 と統合されており、ファイルのアップロードやダウンロードをライブラリ経由で簡単に実装できます。JavaScript ライブラリのみのサポートですが、アップロードやダウンロードを実装する際に、複数の S3 バケットを指定できるようになりました。詳細は こちらのブログ記事 をご参照ください。 8/23(金) Knowledge Bases for Amazon Bedrock で Claude 3.5 Sonnet をサポート Knowledge Bases for Amazon Bedrock で Claude 3.5 Sonnet をサポートしました。 Knowledge Bases には、RetrieveAndGenerate API があり、ユーザーのリクエストに基づくデータの取得と、テキスト生成をしてくれるものですが、この機能で Claude 3.5 Sonnet をサポートした形です。利用できるリージョンは、東京、バージニア北部、オレゴン、フランクフルトの 4 つです。 Amazon Connectは、コールバックを設定する新しい方法をサポート Amazon Connect で、コールバックを作成する前と、キューに入っている間にアクションを実行するフローを設定できるようになりました。例えば、お客様に電話をかける前に SMS で通知を自動送信したり、エージェントが参照できるように最新のお客様データに基づいてコールバック属性を更新したり、問題がすでに解決されている場合はコールバックを終了させることができます。また、お客様プロファイルやサードパーティアプリケーションからのお客様情報に基づいて、コールバックの優先順位を動的に変更したり、別のキューに転送したりすることも可能です。コールバックキューの処理が遅れすぎている場合にも同様の対応ができます。 AWS CDK のアップデート情報が、X のハッシュタグ #cdk_release でまとめられています。バージョン v2.154.0 では、Knowledge Bases for Amazon Bedrock で Advanced RAG を行う機能、やPDF 内の画像を読み取るための Advanced Parsing 機能を CDK L1 コンストラクトでサポートしています。また、Parameter Store のクロスアカウント対応や、ALB の mTLS サポートなどがあります。CDK に興味がある方は、X のハッシュタグ #cdk_release も定期的にご覧いただけますと幸いです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 9月26日に、オンラインイベント「 AWS Innovate 」が開催されます。このイベントは定期的に開催しているものですが、今回のテーマは「Migrate. Modernize. Build.」です。変化が早い時代に対応するためには、生成AIをはじめとする新しい技術の活用を視野に入れつつ、自分達も素早く変化することが必要です。今回のAWS Innovateではアジリティ、俊敏性を高めるためのヒントをお届けします。無料でご参加頂けますので、皆様のご参加をお待ちしています。 「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、8 月 19 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ユビタス様、Amazon EC2とAWS ParallelClusterにより大規模言語モデル開発を加速 株式会社ユビタス 様は、AIキャラクターソリューション「 UbiONE 」を展開しています。これは金融や医療など様々な業界向けにカスタマイズされた対話型のソリューションですが、各業界には固有の要件がありカスタマイズが必要です。ですが、従来の開発アプローチではこのカスタマイズに多大な労力とリソースが必要でした。これを解決するために Amazon EC2 P5インスタンス と AWS ParallelCluster を活用することで、学習時間を従来比で90%短縮するという成果を出しています。同時にフロントエンド環境としてAWSのサービスを組み合わせる事で、複数のカスタマイズされたAIキャラクターを高速に構築・管理できるようになりました。 ブログ記事「新入社員プロジェクト生成 AI を活用した Virtual Summit Assistant展示実施報告 @ AWS Summit Japan 2024」を公開 6月20日21日に開催したAWS Summit Japanでは、入社2年目の社員がチームを組み「Virtual Summit Assistant」を開発しました。これは生成AIを活用してAWS Summit Japanの来場者に対して会場配置やお勧めセッションを案内するアシスタントです。このブログ記事では開発の取り組みやアーキテクチャ、ブース展示などについて紹介しています。お客様への案内をするアシスタントは生成AIの活用領域として注目される分野のひとつです。そのための参考になる情報が詰まっていますので、ぜひご覧ください。 ブログ記事「PartyRock 展示で見えた生成 AI の可能性 – 業務活用への道筋 (AWS Summit Japan 2024)」を公開 こちらもAWS Summit Japanに関連したブログ記事で、生成AIを組み込んだアプリを簡単に試せるPartyRockに関するブース展示についての紹介記事です。このブース展示では新入社員がサポーターとしてお客様へのご説明やサポートを担当していました。たくさんのお客様とのやりとりを通じて感じた、「PartyRockからはじめる生成AIの業務活用」のアプローチ方法について紹介しています。 ブログ記事「AWS で大規模言語モデルにより生成された関数を使ってお客様がロボット学習を包括的に訓練する方法」を公開 ロボット工学の分野では、複雑な操作をともなう問題をはじめ古典的な経路計画アルゴリズムでは効率的に処理できないケースへの対応として、強化学習という技術が活用されています。強化学習においては、行動の成否を測る報酬関数を設計することが不可欠です。この記事では、大規模言語モデルを利用して報酬関数を生成するアプローチについて解説しています。 ブログ記事「Amazon Connectの生成AIによるエージェント生産性向上」を公開 前回の週刊生成AI with AWS でご紹介した「 Amazon Connect Contact Lensが提供するエージェントのパフォーマンス評価機能が東京リージョンで利用可能に 」ですが、この機能を解説する日本語のブログ記事が公開されました。コンタクトセンターで、お客様からのお問い合わせに対応するエージェントの方を補助し、生産性を高めるための機能ですので、こういった課題感をお持ちの方は是非一度目を通していただくことをお勧めします。 スライド資料「100 以上の生成 AI 事例に見るビジネスインパクト創出の方程式」を公開 AWSでは、他の取り組みと同様に生成AIに取り組みたいと考えるお客様の支援にも力を入れています。現時点でも様々な事例が出てきており、お客様との議論を通じて得られた知見もあります。これらの事例や知見をまとめたスライド資料を公開しました。このやり方が唯一の方法、という訳ではありませんが、ひとつの考え方として参考にして頂けるのではないでしょうか。 サービスアップデート Amazon Q Consoleでユーザが利用しているサブスクリプションの把握が容易に 管理者がAmazon Q Consoleを利用することで、ユーザが利用しているサブスクリプションを詳細に把握できるようになりました。具体的にはAmazon Q Developer Pro, Amazon Q Business Pro, Amazon Q Business Liteの利用状況を把握できます。ユーザ毎にサブスクリプションの状態(利用中、利用停止中、無料トライアル中など)を表示するとともに、ユーザが利用可能なアプリケーションやアカウントなどの関連情報も表示されます。これによってAmazon Qがどのように利用されているか、現状を把握することが容易になります。 Amazon Bedrockの一部モデルで、通常より50%安価なバッチ推論が利用可能に 基盤モデルの処理を非同期で実行するバッチ推論機能が一般利用開始になりました。バッチ推論を利用することで、モデルの評価や、即時性を必要としない一方で多くのパターンの処理が必要なケースへの対応が容易になります。また、今回Anthropic/Meta/Mistral AI/Amazonなどが提供する一部のモデルにおいて、バッチ推論の費用がオンデマンドの半額(50%)でご利用頂けるようになりました。リアルタイムの応答が必要ない場合はお得に利用できますので、ぜひご検討ください。 Knowledge Bases for Amazon BedrockでAnthropic Claude 3.5 Sonnetが利用可能に 検索拡張生成(RAG)を容易に実現できるKnowledge Bases for Amazon BedrockでAnthropicのClaude 3.5 Sonnetをご利用頂けるようになりました。このモデルは最大200,000のコンテキストウィンドウに対応し、複雑な推論や低レイテンシなど、RAGで頻繁に求められる性能を備えているとされています。 ブログ記事 もご覧ください。 Amazon SageMaker PipelinesでMLワークフロー作成向けにドラッグ&ドロップ形式の操作が可能に Amazon SageMaker Pipelinesはデータの前処理からモデルのモニタリングまで、機械学習のワークフロー全体をオーケストレーションし自動化するためのサービスです。今回、一連のワークフローを設定する際にドラッグ&ドロップで作業ができるようになり、コーディングが不要になりました。 Amazon SageMaker Canvasがデータフローのインポートに対応 コーディング不要で機械学習による正確な予測を実現するAmazon SageMaker Canvasでは、データ準備のための機能としてAmazon SageMaker Data Wranglerを利用できます。今回、このSageMaker Data WranglerがAmazon SageMaker Studio Classicからのデータフローのインポートに対応しました。これにより、機械学習の開発者やデータサイエンティストがSageMaker Studio Classicで開発したデータの前処理フローを流用して、SageMaker Canvasのユーザが簡単に高度なデータ処理を実行できるようになります。 ブログ記事 もありますのでこちらもどうぞ。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

2024年6月10日〜12日の3日間で、AWS re:Inforce 2024 が米国ペンシルベニア州フィラデルフィアにて開催されました。re:Inforce は、AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスで、今年は 250 を超えるセッション、100 以上のインタラクティブセッションを有する AWS セキュリティに関する最大規模のイベントです。 基調講演では、AWS CISO である Chris Betz が、冒頭に AWS の “Culture of Security” についてお伝えするとともに、AWS のセキュリティに関する最新のイノベーションとビジョンを共有しました。また基調講演の後半では Amazon CSO の Steve Schmidt が、生成 AI の安全な利用を支える強力なセキュリティ文化について独自の視点を共有し、Eli Lilly 社の Ash Edmondson 氏がエンタープライズ規模でクラウド活用を進めるために不可欠な”Trust”を形作っていくためのアプローチについて明かしました。 基調講演や発表された新サービス・新機能の詳細については、ぜひ本ブログ後半で紹介する “AWS re:Inforce 2024 re:Cap” の記事もご参照ください。 AWS re:Inforce 2024 Japan Tour 日本のお客様が AWS re:Inforce により簡単に参加し、一層役立てていただくことを目的とし、AWS では航空券や現地での移動・宿泊、より AWS re:Inforce を楽しんでいただくための特別コンテンツをパッケージングした Japan Tour を昨年より企画しています。今回も、Japan Tour を利用して多くの日本のお客様に現地を訪れていただくことができました。ここではそのコンテンツの一部をご紹介します。 ネットワーキングイベント 各社から参加されるお客様同士の交流を目的としたイベントが開催されました。この他にも、日本・東南アジア・オセアニア地区のお客様や AWS 関係者が集まったグローバルなディナーイベントもあり、活発に情報交換をしていただくことができました。 AWS CISO Chris Betz との交流会 AWS CISO で、今回の AWS re:Inforce 2024 の基調講演スピーカーである Chris Betz が参加する特別セッションが行われました。事前に参加者から募集した質問に対して、直接 Chris が答えていく形で、基調講演では語り尽くせなかった Amazon/AWS の Culter of Security やその背景などについて更に理解を深める場となりました。 EXPOツアー AWS re:Inforce は様々なセッションやワークショップの他に、グローバルの様々な AWS パートナーによる EXPO も開催されました。限られた時間のなかで効率的に動向を把握し、魅力的なセキュリティソリューションの発見につなげていただくために、同時通訳付きで、多様なジャンルのパートナーブースに訪問する EXPO ツアーを提供し、多くの方にご活用いただきました。 現地での最速 Wrapup セッション 基調講演や発表された新サービス・機能を最速で現地で解説する日本語の Wrapup セッションを開催しました。ツアー参加者の方が、帰国後の出張報告などで活用いただくことができる実務的な内容となっており、好評いただきました。 AWS ニューヨークオフィス訪問 – 日本人 AWS 従業員との交流会 & AWS Builder Studio ツアー ツアー参加者の方には、AWS re:Inforceイベント終了後に AWS ニューヨークオフィス へお連れし、NYC で働く日本人 AWS 従業員との交流会に参加いただきました。グローバルの金融の中心地であるニューヨークで活動する金融チームの従業員、AWS サービス開発チームに所属する従業員らとともに、グローバルからみる日本企業への大きな期待や Culture of Security を含む AWS のメカニズムや働き方、AWS のサービスを安心して使っていただくため日々取り組んでいることなどを紹介し、参加者の方が皆様耳を傾けていらっしゃいました。 またこのオフィスに併設されている AWS Builder Studio を見学するツアーも開催しています。AWS Builder Studio は AWS の様々なテクノロジーを活用したソリューションを体験し、プロトタイピングを進めていくためのスタジオです。参加された皆様からは、「実際に動作するソリューションに触れられて興味深い」「自社への応用について具体的に想像する機会になった」などの声をいただきました。 AWS re:Inforce 2024 re:Cap 2024年7月26日に、 AWS re:Inforce 2024 re:Cap イベント を実施しました。本イベントでは、AWS ユーザー様や、AWS パートナー様のセキュリティリーダー向けに実施されたセッション（ 資料 、 動画 ）に加え、AWS re:Inforce 2024 にて発表されたセキュリティ関連の新サービス・新機能に関するまとめ（ 資料 、 動画 ）やユーザー事例のダイジェスト（ 資料 、 動画 ）をご紹介しており、セキュリティ意思決定を行う経営層へ向けたメッセージから現場のエンジニアに役立つ情報まで幅広い内容をお届けしました。 さらに re:Cap ならではの内容として、現地イベントに参加した以下のお客様によるセッションレポートや、Japan Tour の魅力についてもご紹介いただきました。 株式会社みずほフィナンシャルグループ ＩＴ・システム統括部クラウド統括チーム 調査役 佐藤 慶彦様 株式会社日本経済新聞社、CDIO 室、セキュリティエンジニア 藤田 尚宏様（ 資料 、 動画 ） 株式会社電通総研 コーポレート本部サイバーセキュリティ推進部 シニアアーキテクト 松永 桂子様 また、Security-JAWS コミュニティを代表して吉江様、吉田様からは、現地セッションに登壇した貴重な実体験について共有いただきました。（ 資料 、 動画 ） 2024年8月19日には、Security-JAWS コミュニティの勉強会にて「AWS re:Inforce 2024 もう一つの re:Cap」（ 動画 ）として、上記 re:Cap イベントでは触れられなかったre:Inforce 2024 の裏側やこぼれ話、Japan Tour の体験についても紹介させていただいておりますので、合わせて録画をご覧ください。 おわりに 本ブログでは、AWS セキュリティ最大規模のカンファレンスである AWS re:Inforce 2024 の開催と Japan Tour、その後の re:Cap についてご紹介してきました。ご覧いただいた方にとって、AWS re:Inforce への興味・関心を持っていただければ幸いです。 AWS re:Inforce 2025 は、今回と同じフィラデルフィア、Pennsylvania Convention Center にて2025年6月16日〜18日までの3日間の日程で開催されることが決定しました。少々気が早いですが、皆様と AWS re:Inforce 2025 の会場でお会いできることを楽しみにしています！ 過去の同種イベントの開催報告 AWS re:Inforce 2022 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2022-recap-seminar/ AWS re:Inforce 2021 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2021-recap-seminar/ AWS re:Inforce 2019 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2019-recap-seminar/ 本Blogについて 本Blogはセキュリティソリューションアーキテクト勝原 達也にて執筆いたしました。 TAGS:  AWS Security ,  re:Infoce

概要 クラウド上で複雑な分散型システムを運用する際、問題の根本原因を迅速に特定し、インシデントを解決することは大変な作業です。トラブルシューティングでは、複数の AWS サービスからのメトリクス、ログ、トレースをチェックする必要があり、問題を包括的に把握することが必要ですが、容易ではありませんが困難です。効果的なインシデント解決に必要な時間と手間をどのように軽減できるでしょうか？ この問題の解決方法として、このブログでは、 Alarm Context Tool (ACT) を紹介します。これは、 Amazon CloudWatch Alarms に追加のコンテキストを提供し、トラブルシューティングと分析を支援するソリューションです。 AWS Lambda 、 Amazon CloudWatch 、 AWS X-Ray 、 AWS Health 、 Amazon Bedrock などの AWS サービスを活用し、メトリクス、ログ、トレースを集約、分析し、有意義な洞察を生成します。ACT はトラブルシューティングプロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。 主な利点 トラブルシューティングの簡素化 ACT は、CloudWatch、X-Ray、 Amazon RDS Performance Insights 、 CloudWatch Container Insights などさまざまな情報源から関連データを自動的に収集、分析します。これにより、根本原因を特定し、トラブルシューティングに要する時間を削減できます。異なる AWS サービスからのデータを統合することで、ACT はシステムの状態とパフォーマンスの包括的な状況を提供し、インシデントの迅速な解決を可能にします。 コスト効率 アラーム通知内に詳細なコンテキストと洞察を提供することで、ACT は手動によるデータ収集と解析に関連する運用上のオーバーヘッドとコストを削減します。オペレーターは複数の AWS サービスを深く確認することなく、問題を素早く理解できます。これにより、問題の診断に必要な時間と労力が削減され、運用コストが低減し、リソースの活用が向上し、平均修復時間 (MTTR) が短縮されます。 拡張されたオブザーバビリティ ACT は Amazon Bedrock の生成 AI 機能を活用して、所見の要約、潜在的な根本原因の特定、関連するドキュメントへのリンクの提示を行います。これにより、AWS 環境のオブザーバビリティが高まり、保守やオペレーション作業が簡素化されます。AI で強化されたインサイトの統合により、オペレータは実行可能な情報を受け取ることができ、ログやメトリクスの分析ではなく、問題の解決に集中できるようになります。 アーキテクチャ このソリューションは、AWS Lambda 関数、CloudWatch Alarms、X-Ray トレーシング、Amazon Bedrock の AI 機能を組み合わせて構築されています。アーキテクチャの概要は次のとおりです。 図1. アーキテクチャ図 CloudWatch Alarms は、Amazon SNS トピックに通知を送信します。 Lambda 関数 は、SNS トピックをサブスクライブします。 Lambda 関数 は、CloudWatch メトリクスとログ、X-Ray トレース、RDS Performance Insights、Container Insights、AWS Health などのソースからデータを集約します。 Amazon Bedrock は、集約されたデータを処理し、要約、インサイト、根本原因を生成します。 Amazon SES は、処理された情報を電子メールで関係者に送信します。 X-Ray トレーシング は、 Powertools for AWS Lambda (Python) から Tracer を使用することで、Lambda 関数の実行の詳細なトレースを提供し、関数のパフォーマンスと動作の深い可視化を実現します。 事例シナリオ: ACT の実用例 シナリオの概要 CloudWatch Synthetics Canary の障害により、アラームがトリガーされます。これは、マイクロサービス API の間欠的なエラーまたは高い待ち時間の兆候です。ACT Lambda 関数が呼び出されて、追加のコンテキストを収集し、問題の詳細な分析を提供します。ACT がこのシナリオでトラブルシューティングを簡素化する方法は次のとおりです。 図2. Alarm Context Tool のトレースマップ データの収集と分析 アラームがトリガーされると、ACT Lambda 関数は以下のデータ収集のステップを実行します: CloudWatch メトリクス: この関数は、エラー率、レイテンシー、リクエスト数などの関連メトリクスを CloudWatch から収集します。 CloudWatch Logs: この関数は、今回の Canary 実行に関連する関連ログを CloudWatch Logs から収集します。 X-Ray トレース: API の実行フローの中で、失敗の正確な場所を特定するために、詳細なトレースが取得されます。たとえば、トレースデータは films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルへのクエリ中に問題が発生したことを示しています。 ヘルスイベント: この関数は、特定のサービスに影響を与える可能性のある関連イベントについて AWS Health にクエリします。 アラーム履歴: この関数はアラームの履歴を検査し、今回の場合は、これが継続的に発生している問題であると判断します。 リソース情報: この関数は、特定のリソースである CloudWatch Synthetics Canary の詳細を取得します。 Amazon Bedrock 分析: Amazon Bedrock は集約されたデータを分析し、判明事項の概要を生成します。 生成 AI によるインサイト Amazon Bedrock は収集したデータを分析し、調査結果の要約を生成します。この例では、DynamoDB テーブルで読み取りトラフィックが高くなり、プロビジョンドスループットを超過しているため、Bedrock はこれをルート要因と特定しています。 通知と報告 この関数は、調査結果を要約し、潜在的な解決策を示して関係者に電子メールを送信します。この電子メールには以下の内容が含まれています。 Root Cause Analysis (根本原因分析): 収集されたデータに基づき、DynamoDB テーブルがプロビジョンドスループットを超えていることなどの主要な問題を特定します。 Alarm Frequency and Immediacy(アラームの頻度と緊急性): アラームの過去のデータを分析して、その起動頻度を判断し、根本的な問題が再発するか、断続的か、一回限りのものかを特定に役立ちます。 Additional Metrics Analysis (追加のメトリクス分析): 失敗したカナリア実行やサーバーサイドエラーなど、関連するメトリクスからの洞察。 Potential Solutions (潜在的な解決策): DynamoDB のプロビジョンドスループットを増やすこと、パーティションキーの設計を最適化すること、アプリケーションコードで指数関数的バックオフを実装することなどの推奨事項。 AWS Health イベント: システムに影響を与える可能性のある、メンテナンスイベントや変更の予定。 例の概要 (抜粋) Root Cause Analysis (根本原因分析) この問題は、DynamoDB テーブルの Movies がプロビジョニングされたスループット容量を超えていることに関連しているようです。 films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルをクエリしているときに、 ProvisionedThroughputExceededException が発生しました。 Alarm Frequency and Immediacy (アラームの頻度と緊急性) アラームは過去数時間に複数回トリガーされており、問題が繰り返し発生していることを示しています。OK 状態と ALARM 状態が頻繁に切り替わることから、問題はトラフィックの急増に関連していることがわかります。 Additional Metrics Analysis (その他のメトリクス分析) Failed メトリクスの値は 1 で、最近の Canary 実行 の失敗を示します。 5xx メトリクスの値は 1 で、サーバー側のエラー（502 Bad Gateway）を示唆しています。 SuccessPercent メトリクスは、Canary 実行が失敗した場合は 0% と表示されます。 Potential Solutions (潜在的な解決策) 問題を解決するには、次の手順を検討してください。 Movies DynamoDB テーブルのプロビジョニングされたスループット容量を増やします。 パーティションキー設計のベストプラクティスを実装する。 アプリケーションコードにジッターを伴うエクスポネンシャルバックオフを実装します。 Relevant Documentation (関連ドキュメント) DynamoDB Provisioned Throughput DynamoDB Read/Write Capacity Mode DynamoDB Guidelines for Tables 結論 このブログでは、Amazon CloudWatch Alarm をより豊富な文脈と洞察によって強化し、トラブルシューティングと分析を支援するソリューションである Alarm Context Tool (ACT) を紹介しました。ACT は複数の AWS サービスと Amazon Bedrock の生成 AI 機能を活用しています。これにより、インシデント解決プロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。 ACT について、さらに学び、使用を開始するには GitHub リポジトリ のセットアップ手順に従ってください。 ACT の使用ついての質問や改善の提案、問題がある場合は、 GitHub リポジトリ で気軽に Issue を作成してください。皆様のフィードバックと貢献を大切にし、ACT をより良いものにしていきます。 著者について Alex Livingstone Alexは、Amazon CloudWatch、AWS X-Ray、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for OpenTelemetry などのAWS オブザーバビリティツールに焦点を当てた Principal Solution Architect です。彼は、お客様がクラウドで運用し、アプリケーションに関する洞察を得るのを支援することが大好きです。ぜひ、LinkedIn (/aelivingstone) で彼を探してください 。 本記事は、 Respond to CloudWatch Alarms with Amazon Bedrock Insights を翻訳したものです。翻訳は テクニカルアカウントマネージャー の 日平 が担当しました。

通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch に 2 分の遅れで取り込まれるため、アラームが起動しない可能性があります。 Amazon CloudWatch アラーム を使用して AWS リソースを監視し、メトリクスが事前に定義されたしきい値を超えたときに自動的にアクションを実行していますか？ メトリクスに対してアラームを設定 したり、 ログに対してアラームを設定 したりし、 アラームを組み合わせ 、アラームがトリガーされたときに 特定のアクションを実行 していますか？ メトリクス数式 、 Metrics Insights クエリ 、または 別のリソースのデータソース に基づいてアラームを作成する必要があるユースケースがある場合、このブログはアラームの作成、管理、大規模な利用におけるベストプラクティスを理解するのに役立ちます。 このブログでは、一般的なアラームの推奨使用例について説明し、データ欠損シナリオや、アラームが発報するまでの時間を短くするための構成など、具体的な使用例についても詳しく説明します。 このブログでは、以下の内容を取り上げます。 すべての Amazon CloudWatch アラームの設定に適用される一般的なアラームの推奨事項 既存のアラームの調整 データが欠落している場合の推奨アラーム設定 より早い警告のための推奨アラーム設定 Metric Insights アラームを使用した動的アラームの作成 価値の低いアラームのクリーンアップ アラームの推奨事項 CloudWatch アラームを素早く設定し、モニタリングのベストプラクティスに従うには、CloudWatch コンソールの Alarm recommendations を使用します。CloudWatch は、他の AWS サービスによって公開されるメトリクスに対して設定することを推奨される アラームの推奨事項 を提供しています。これらの推奨事項は、モニタリングのベストプラクティスに従うためにアラームを設定する必要があるメトリクスを特定するのに役立ちます。推奨事項には、設定するアラームのしきい値も示されています。これらの推奨事項に従うことで、AWS インフラストラクチャの重要なモニタリングを見落とすことがなくなります。 CloudWatch コンソールのメトリクスのセクションで、推奨アラームのフィルタを選択できます。また、コンソールを使用して、推奨アラームの定義をインフラストラクチャとしてコード化したものをダウンロードし、このコードを使用して AWS CloudFormation 、 AWS CLI 、または Terraform でアラームを作成することができます。図 1 は、CloudWatch メトリクスのコンソール画面で利用可能な推奨アラームのフィルタを示しています。 図 1. CloudWatch Metrics コンソールのアラームに関する推奨事項 アラームの調整 アラームを作成するときは、期間、評価期間 (N)、アラームを発生させるデータポイント数 (M) の設定を指定して、CloudWatch がアラームの状態を変更するタイミングを評価できるようにします。M/N 設定の主な利点は、すべての ‘N’ データポイントではなく、’M’ データポイントでアラームの状態の変更を評価できることです。M/N 設定を使えば、状態の変更に考慮されるデータポイント数を決められます。ただし、アラームの状態を計算するには常に N 個のデータポイントが必要です。この期間内のデータポイント数が N 未満の場合、アラームは欠落データの扱いの設定に従って、不足分のデータポイントを補います。 図 2. CloudWatch アラームの評価 M/N 設定は、メトリクスが CloudWatch に遅延して受信された場合でも、アラームの誤った遷移を防ぎます。遅延したメトリクスは、メトリクスデータが正確に反映されない恐れがあります。この誤った遷移は、M/N 設定によって防ぐことができます。そのため、3/3 ではなく 2/3 のように M < N を設定することをお勧めします。ほとんどの場合、最新のデータポイントにはメトリクスの遅延の問題があります。そのため、M の設定を使用して、最新のデータポイントを除外できます。 例えば、次のような設定のアラームを考えてみましょう。 指標: MyMetric Threshold: >50 Period: 60(sec) 統計値: SUM Evaluation Period: 3 M / N: 2 / 3 この例では、アラームに戻される可能性のあるウィンドウは次のとおりです。 1) [12, 13, 40, 50, 60, 90, 10, 20] ==> 設定された数 (3) より多くのデータポイントがあっても、アラームは最新の N 個のデータポイントを使用して状態の判断を試みます。この場合、N は 3 です。アラームは最新の 3 つのデータポイント 90、10、20 を確認します。ここでは、アラームが実行されるには、2 つのデータポイントが閾値を超えている必要がありますが、1 つのデータポイントしか閾値を超えていません。 2) [12, 13, 40, 50, 60, 90, 100, 20] ==> 最新の 3 つのデータポイントのうち 2 つが閾値を超えているため、 ALARM 状態になります。 M 個を超えるデータポイントがブリーチ (breach) した場合、アラームは ALARM 状態に遷移します。 データが欠落している場合のアラームの設定 欠落データの扱いの設定は、サービスがダウンしてデータポイントを CloudWatch に公開できない場合の遅延時に、アラームが ALARM 状態に移行するまでの時間に大きな影響を与えます。各アラームについて、CloudWatch に欠落データ (TMD) ポイントを notBreaching、breaching、ignore、missing のいずれとして扱うかを指定できます。デフォルトの動作は missing です。欠落データ機能は、欠落データの動作が危険を示す場合は欠落データを breaching として扱うべきであるなど、さまざまなシナリオで役立ちます。欠落データを気にしない場合は、欠落データを notBreaching または ignore として設定することもできます。アラームの状態を判断するためには一定数のデータポイント(N 個)が必要ですが、実際にはデータポイントの個数が N に満たない x 個の場合、欠落データの扱い設定に従い、残りの N – x 個のデータポイントを仮想的に補完し、アラームの状態を判断します。 より早く警告するためのアラームの設定 より正確なアラームをより早期に検知したい場合、これが出来ない一般的な根本原因はデータ欠損です。つまり、メトリクスのデータポイントが常に遅れているため、または送信元のサービス/アプリ/リソースがダウンしているためにアラームで受信されない場合です。メトリクスデータが常に遅延して CloudWatch に取り込まれるため、アラームの遅延が発生する可能性があります。これにより、その期間の評価がすでに完了した後にメトリクスデータポイントがバックフィルされ、バックフィルされたデータポイントが閾値を超えていてもアラームが発生しません。 Metric Math を使用すれば、アラーム自体で欠落データを処理できます。Metrics Math (FILL、repeat) を使えば、最後の値を繰り返すことができ、データが遅延する場合に便利です。Metrics Math (FILL、breaching value) を使えば、ダウンタイムの際にアラームをより早く反応させることができます。 これらに対処するための推奨構成を含むいくつかのユースケースを見てみましょう。 ユースケース １ EC2 インスタンスがダウンしているため、データポイントが一部欠損している場合。アラーム設定は以下のとおりです。 Metric: EC2/CPUUtilization Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N: 2 / 3 Treat Missing Data : Breaching 上記の設定の場合、TMD が 「Breaching」 に設定されていても、アラームが ALARM 状態に移行するまでに 7 分かかります。インシデントの早期検知と復旧は、ビジネスとエンドユーザー体験にとって重要なため、この遅延は重要なワークロードには適さない可能性があります。 ソリューション : データポイントが欠落している場合に ALARM 状態への移行を早めるために、Metrics Math (FILL、breaching value) を使用することをお勧めします。たとえば、Metrics Math の FILL(m1,90) は、CPUUtilization メトリクスの欠落値を 90 に埋める式です。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかるのに対し、この設定では 2 分しかかかりません。 Metric: EC2/CPUUtilization ## FILL(m1,90) Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N: 2 / 3 Treat Missing Data: Breaching ユースケース 2: EC2 インスタンスに閾値を超えるデータポイントがあるが、通知が遅れアラーム状態に移行するのに時間がかかりすぎる場合。 Metric: EC2/CPUUtilization ## FILL(m1, REPEAT) Threshold: >80 Period: 60(sec) Statistic: AVG Evaluation Period: 3 M / N : 2 / 3 Treat Missing Data: Breaching 上記の設定では、TMD を 「Breaching」 に設定しても、アラームが ALARM 状態に遷移するまでに 7 分かかります。これは重要なワークロードには適さない可能性があります。 ソリューション : 違反データポイントがある場合に ALARM 状態への移行を速めるため、Metrics Math (FILL(m1, REPEAT)) を使用することをお勧めします。たとえば、Metrics Math FILL(m1, REPEAT) は、CPUUtilization メトリクスの違反値で埋めます。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかりますが、この設定では 2 分しかかかりません。 ユースケース 3: メトリクスデータが常に 2 分の遅延を伴って CloudWatch に取り込まれているため、アラームが発動することが無い場合。 ソリューション : このような状況では、M/N を高く設定すると役立ちます。たとえば、M/N を 3/5 ではなく 3/7 に設定すると、2 分後にバックフィルされる遅延データポイントを考慮しやすくなります。 上記のすべてのユースケースソリューションは、 AWS CloudFormation または AWS Cloud Development Kit (CDK) / Terraform を使用して、Metrics Mathとアラーム作成が自動化されるので、大規模に実装できます。 Metric Insights アラームを使用した動的アラーム SQL クエリを使って、アカウント間の動的なリソースフリート全体に対して Metrics Insights アラームを単一のアラームで設定できます。 Amazon CloudWatch Metrics Insights アラームを アカウント間 で CloudWatch アラームと Metrics Insights クエリを組み合わせることで、高速に変化する環境を一貫してモニタリングし、異常が検出されたときにアラートを発する動的なアラームを設定できるようになります。Metrics Insights アラームの一般的な使用例としては、アカウント内の Amazon DynamoDB テーブルへのリクエストがそのテーブルのプロビジョンド読み取りキャパシティユニットを超え、スロットリングが発生したときにアラームをトリガーしたり、アカウント内の Amazon ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラームをトリガーすることがあります。これらのユースケースは、アラームライフサイクルを最適化するために自動化できます。 価値の低いアラームのクリーンアップ 価値の低い、または構成ミスのある CloudWatch アラームを削除すると、CloudWatch アラームの費用を削減できます。AWS リージョン全体で数千の Amazon CloudWatch アラーム がある場合でも、リージョン全体で価値の低いアラームや構成ミスのあるアラームを素早く特定できます。 アラームの削除を自動化 することで、価値の低いアラームや構成ミスのあるアラームを削除し、コストを削減できます。 まとめ このブログでは、CloudWatch アラームを使用した信頼性の高いモニタリングのための重要なヒントと戦略について学びました。アラームの推奨事項の一般的なユースケースを説明し、欠落データのシナリオや警告を早期に発する設定など、具体的なユースケースについて詳しく説明しました。 詳細は、 AWS Observability ベストプラクティス 、 AWS One Observability ワークショップ 、 AWS re:Invent Observability 動画 を参照してください。 著者について Karthik Chemudupati Karthik Chemudupati は、コスト最適化とオペレーショナル・エクセレンスの実現を支援する AWS の Principal Technical Account Manager (TAM) です。彼は 20 年以上にわたりソフトウェアエンジニアリング、クラウドオペレーション、自動化の経験を持っています。2016 年に TAM として AWS に入社し、米国西部で 10 社以上の企業顧客と働きました。仕事以外では、家族と過ごす時間を楽しんでいます。 Sharmadha Muthuram Sharmadha Muthuram は、AWS Professional Services の Senior Cloud Infrastructure Architect です。お客様が AWS で成功するため、技術的なガイダンス、設計、および実装プロジェクトのリードを行っており、お客様のクラウド移行を円滑に行えるよう熱心に取り組んでいます。コンピューターエンジニアリングの修士号をイリノイ大学で取得しています。仕事の合間には、旅行や様々な料理を体験することが趣味です。 Jean Schwerer Jean Schwerer は CloudWatch の Senior Product Manager です。技術を愛する元エンジニアで、技術製品の製品管理に 10 年以上の経験を積んでおり、お客様の使用事例やニーズに深く知ることを楽しんでいます。 本記事は、 Elevating Your AWS Observability: Unlocking the Power of Amazon CloudWatch Alarms を翻訳したものです。翻訳は テクニカルアカウントマネージャーの日平が担当しました。

本記事は 2024年4月3日に公開された ” Build a personalized student companion powered by generative AI on Amazon Bedrock ” を翻訳したものです。 学生の学習ニーズは多様で、教育者が利用できるリソースは限られているため、 個別学習 は現代の教育における差し迫った課題です。一対一での相談や仲間との学習グループといった従来の学習サポート方法では、カスタマイズされたガイダンスを提供したり、知識のギャップを埋めるには不十分であることがよくあります。さらに学習者それぞれが異なる長所、短所、学習スタイルを持つという本質的な多様性が、この課題をより複雑にしており、画一的なアプローチはますます時代遅れになっています。 この急速に進化する環境において、 生成 AI と 大規模言語モデル（LLM） の出現は、これらの長年にわたる教育上の課題に取り組むための変革の機会をもたらしています。膨大なデータセットに基づいてトレーニングを受けた LLM は、自然言語を理解し、意味を解釈し、文脈的に関連性のある人間らしい応答を生成できます。 Retrieval-Augmented Generation（RAG） は、応答を生成する前にトレーニングデータ以外の信頼できる知識ベースを参照することで、LLMの出力をさらに向上させます。 この記事では、パーソナライズされた学習サポートの課題に対応する、自分のペースで進められる学生コンパニオンの導入方法を説明します。学生のプロフィールと教育機関の学習コンテンツコーパスを組み合わせることで、生成 AI モデルを使用して学生体験をパーソナライズし、各学生固有の長所と短所に合わせた教育支援を提供します。コンテンツ生成のための LLM を呼び出すための Amazon Bedrock 、教育コンテンツを統合するための Knowledge Bases for Amazon Bedrock 、更新されていく学生の成績データストアとして Amazon Aurora Serverless など、AWS サーバーレステクノロジーを利用しています。このアプローチは、AIの力を利用して、学習者の多様なニーズとスキルセットに応える、パーソナライズされた適応性のある学習コンパニオンを作成します。 前提条件 この記事で説明したアプローチを実装するには、次のものが必要です。 コース教材やその他の教育リソースなど、教育機関の学習コンテンツコーパスを含む既存の Amazon Simple Storage Service (Amazon S3) バケット。 登録されたモジュールや成績などの学生登録データを保存するための、ユーザーアカウントにある Amazon Aurora データベースインスタンス。 学生の ID を管理し、アプリケーションへのアクセスを許可するように設定された ID プロバイダーサービス。たとえば、 Amazon Cognito を使用してユーザーの認証と認可を処理することはできますが、サービスの設定はこの記事では対象外です。 ソリューション概要 パーソナライズされた学習コンパニオンは、各学生の独自のプロフィールとスキルセットに適応する必要があります。次のシナリオを考えてみましょう。科学に熱心なエマと、特定の概念に苦労しているマイケルが同じコースに登録されています。エマは理解を深めるために高度な洞察と難しい質問が役立つでしょうが、マイケルは教材を補強するために簡単な説明と追加の例が必要です。パーソナライズされた学習コンパニオンは、それに応じてアプローチを調整し、両方の学生がそれぞれの強みと改善すべき分野に合わせてカスタマイズされたサポートを受けられるようにします。 このワークフローを実証するために、この記事では次の図に示すアーキテクチャの概要を説明します。 図1.パーソナライズされた学習コンパニオンのハイレベルアーキテクチャ。主なコンポーネントは、学習コンパニオンチャットボット、Amazon Bedrock、Amazon Aurora Serverless、Amazon OpenSearch Serverless、Amazon S3 バケットです。 ソリューションの手順 パーソナライズされた学生コンパニオンを構築するワークフローは、次の手順に従います。 アプリケーションは、教育機関のデータベースから、成績や登録モジュールを含む学生の記録を取得します。 アプリケーションは学生データをプロンプトと組み合わせ、LLMを呼び出してパーソナライズされた学生プロフィールを作成します。 プロンプト拡張プロセスでは、学生のプロフィールと入力質問を統合し、学生固有の強みや改善すべき分野に応じてモデルの出力を調整します。 アプリケーションは、教育機関の学習コンテンツコーパスを検索して、学生の入力問題に関連する資料を探します。 LLMは、関連する学習教材とカスタマイズされた学生プロフィールの両方を組み込んだ個別の回答を生成するために呼び出されます。 学生の個々のプロフィールとニーズに合わせてカスタマイズされた回答が学生に配信されます。 ステップ1 — 学生記録の取得 パーソナライズされた学生プロフィールを生成するには、学生の学業成績、成績、履修モジュールからの構造化データを分析する必要があります。このデータには通常、学生が教育機関での学習期間中に継続的に更新される取引情報が含まれます。LLM を呼び出してプロフィール生成を行う際にこのデータを効果的に利用するには、RAG を使用します。RAG により、LLM は学生記録データベースから関連情報を取得して組み込むことができるため、生成されたプロフィールが学生の現在の学業状況と学習要件を正確に反映できるようになります。 以下の簡単なデータベーススキームは、Amazon Aurora PostgreSQL 互換エディションをデータベースとして使用する場合のユースケースを示しています。 CREATE TABLE student ( /* Students table, including student Id and name */ id SERIAL PRIMARY KEY, name TEXT ); CREATE TABLE module ( /* Modules table, including module ID and label */ id SERIAL PRIMARY KEY, label TEXT ); CREATE TABLE enrollment ( /* Students’ enrolled modules and grades */ id SERIAL PRIMARY KEY, student_id INTEGER REFERENCES student(id), module_id INTEGER REFERENCES module(id), grade INTEGER ); 次のコードスニペットは、データベースから学生の成績を取得するのに役立ちます。 import psycopg2 def get_student_modules_and_grades(connection_string, student_id): modules_and_grades = [] conn = psycopg2.connect(connection_string) cursor = conn.cursor() query = """ SELECT module.label, enrollment.grade FROM module JOIN enrollment ON module.id = enrollment.module_id WHERE enrollment.student_id = %s """ cursor.execute(query, (student_id,)) for row in cursor: module = { "label": row[0], "grade": row[1] } modules_and_grades.append(module) conn.close() return modules_and_grades ステップ 2 — パーソナライズされた学生プロフィールを作成する 前のステップの出力に基づいて、アプリケーションはLLMを呼び出して学生プロフィールを生成します。次のコードスニペットは、Amazon Bedrock で利用可能になった新しい Claude 3 Sonnet モデルを使用したこのステップを示しています。 import boto3 import json PROFILE_PROMPT = """ You are a student companion chatbot tasked with generating a unique profile for a student based on their enrolled modules and grades. The profile should have three parts: Domain of Speciality: Based on the modules the student is enrolled in, identify their likely domain or field of speciality. Main Strengths: Based on the grades obtained, determine the student's main strengths or areas of academic excellence. Areas of Improvement: Based on the relatively lower grades, suggest areas where the student could potentially improve. Here are the modules the student is enrolled in and the grades they have obtained: {modules_and_grades} Generate a student profile with the three parts mentioned above, keeping in mind the input modules and grades. Assistant: """ def create_user_profile(connection_string, student_id): PROFILE_PROMPT = PROFILE_PROMPT.format( modules_and_grades = get_student_modules_and_grades( connection_string, student_id)) bedrock = boto3.client(service_name='bedrock-runtime') messages = [ { "role": "user", "content": [ { "type": "text", "text": PROFILE_PROMPT} ] } ] body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1000, "messages": messages }) response = bedrock.invoke_model( modelId="anthropic.claude-3-sonnet-20240229-v1:0", contentType='application/json', accept='application/json', body=body ) response_body = json.loads(response.get('body').read() return response_body このコードは、学生が登録したモジュールと成績に基づいて、学生の専門分野、長所、改善点という3つの部分に分かれてパーソナライズされた学生プロフィールを返します。 ステップ3 — 学生プロフィールを使用して学習教材をカスタマイズする 学生固有のプロフィールが生成されたら、プロンプトエンジニアリングを使用して学生の入力クエリをプロフィールデータで拡張することができます。これにより学生の学業上のニーズや強みに合わせたパーソナライズされた学習コンテンツを生成できます。これにより、LLM は学生のプロフィールを理解し、それに応じて回答を調整することができます。以下はプロンプトのテンプレートです。 AUGMENTED_PROMPT = """ You are a personalized student companion chatbot. Your task is to provide a detailed answer to the following question while tailoring the response based on the given student profile: Student Profile: {student_profile} Learning material: {learning_corpus} Question: {input_question} When generating the answer, keep the following in mind: - Adjust the level of complexity and depth based on the student's strengths and areas of improvement identified in the profile. - Provide examples and explanations that align with the student's domain of specialty. - Offer suggestions or additional resources to help the student improve in areas where they may be struggling. Your personalized answer: """ ステップ 4 — 教育機関の学習コーパスからコンテンツを取得する 学生の意見に関連するコンテンツを取得するには、Amazon Bedrock でナレッジベースを作成し、教育機関の学習コンテンツコーパスをアップロードする必要があります。Knowledge Bases for Amazon Bedrock を作成する手順については、「 ナレッジベースを作成する 」を参照してください。その後、Bedrock retrieve API を使用してナレッジベースをクエリし、学生が入力した質問に関連する関連資料を取得できます。このステップを実装するコードスニペットは、LLMを呼び出すコードとともにステップ5に示されています。 ステップ 5 — LLM を呼び出してパーソナライズされたコンテンツを生成する 学生プロフィール、質問内容、およびナレッジベースから取得した関連資料が揃ったら、LLMを使用して、学生固有のニーズと強みに合わせた個別の回答を生成できます。まず、手順 3 の拡張プロンプトテンプレートを使用して、学生プロフィール、取得した学習教材、学生が入力した質問を 1 つのプロンプトに集約して、拡張プロンプトを作成します。次に、拡張されたプロンプトを使用して Amazon Bedrock API を通じて LLM を呼び出し、パーソナライズされたレスポンスを生成します。 次のコードスニペットは、このプロセスを示しています。 def question_answering_and_generation(kb_id, profile, question, prompt): # Retrieving contextual learning material from Bedrock Knowledge Base kb_client=boto3.client(service_name='bedrock-agent-runtime') response = knowledge_client.retrieve( knowledgeBaseId=kb_id,retrievalQuery={ 'text': question }) answer = response['retrievalResults'][0]['content'] # Augmenting the prompt for LLM invocation full_prompt = prompt.format( student_profile=profile, learning_corpus= answer, input_question=question) runtime_client = boto3.client('bedrock-runtime') messages = [ { "role": "user", "content": [ { "type": "text", "text": full_prompt } ] } ] body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 300, "messages": messages }) # Invoke Claude with the agumented prompt response = runtime_client.invoke_model( modelId="anthropic.claude-3-sonnet-20240229-v1:0", contentType='application/json', body=body #body=json.dumps({ "prompt": full_prompt }) ) # Return the generated response return json.loads(response.get('body').read()) 最後に、ステップ6でパーソナライズされた回答を学生に返します。 例 ソリューションを説明するために、この記事で前述したエマとマイケルの例を使用します。エマとマイケルの両方が数学のモジュールに在籍していて、ピタゴラスの定理について学んだ幾何学の授業に出席したばかりだとしましょう。エマの成績によると、彼女は自然科学と数学に堪能ですが、美術と外国語はまだ上達できます。反対に、マイケルは美術と文学には優れていますが、数学と応用科学には多少の困難があります。2人とも授業で見たピタゴラスの定理をよりよく理解するために、学生用コンパニオンチャットボットを使用します。 次のスクリーンショットでは、エマの見解とマイケルの学習中の学生コンパニオンに対する見解を示しています。 最初のスクリーンショットは、パーソナライズされた学生コンパニオンとのエマの体験を示しています。 図 2.ピタゴラスの定理に関するエマの質問に対する個別の回答。 スクリーンショットの最初の部分は、学習コンパニオンアプリケーションが、ステップ 2 でデータベースから抽出された現在の成績に基づいてエマの学生プロフィールをどのように更新したかを示しています。2つ目の部分では、このパーソナライズされたプロフィールと、教育機関の学習コーパスのコンテンツを使用して、数学と科学の豊富なバックグラウンドに基づいて回答をパーソナライズしました。 次のスクリーンショットは、パーソナライズされた学生コンパニオンとのマイケルの体験を示しています。マイケルの個人的な対応は、彼の美術の強みを活かした視覚的なアプローチをとることで、数学を改善したいという彼のニーズに応えています。 図 3.ピタゴラスの定理に関するマイケルの質問に対する個別の回答。 この例は、同じ入力クエリの結果が、各学生の固有の長所、短所、専門分野に合わせてカスタマイズされた個別の応答を生成する方法を示しています 結論 この記事では、生成 AI を使用して、学生固有のプロフィールとニーズに合わせてパーソナライズされた学習コンテンツを提供するソリューションについて説明しました。Amazon Bedrock を使用して大規模言語モデルを呼び出し、Amazon Aurora Serverless や Amazon Bedrock ナレッジベースなどの AWS サーバーレスサービスと統合することで、各学生の長所、短所、専門分野に基づいてカスタマイズされた説明を生成する適応型システムを構築しました。これにより、教育機関は自分のペースで AI 駆動型学習支援を大規模に提供できるようになり、多様な学習要件や限られた教育者リソースの課題に取り組むことができます。数学の授業の簡単な例で説明しましたが、ここで概説した原則は、分野や学習環境を超えて適用できます。全体として、この記事では、AWS の包括的な AI およびサーバーレスサービスを活用して、Amazon Bedrock で利用できる生成 AI の強力な機能を通じて、どのように個別教育を変革できるかを紹介しました。 さらに詳しく: 教育と学習の経験を改善するための生成AIアプリケーションを開発する。 AWS Behind the Cloud ポッドキャストの第 5 話 を視聴、生成 AI が世界の教育分野にどのような影響を与えているかについて詳しく学んでください。 誰にとってもいつでも利用可能で、個別化され、生涯にわたる 教育に AWS がどのように役立つか の詳細をご覧ください 高等教育におけるイノベーションの推進要因と、 AWS が高等教育機関のイノベーションにどのように役立つか について詳しく学んでください。 Nizar Kheir Nizar は Amazon Web Services (AWS) のシニアソリューションアーキテクトで、様々な業界にわたって15年以上活躍してきました。現在はフランスおよび EMEA に及ぶパブリックセクターの顧客と連携し、IT インフラストラクチャのモダナイズや AWS Cloud を活用したイノベーションの促進を支援しています。 本ブログはソリューションアーキテクトの田村健祐が翻訳しました。原文は こちら です。

8月19日より、 AWS CodeBuild を利用して macOS でアプリケーションを構築できます。 macOS 14 Sonoma で実行されるマネージド Apple M2 マシンでアーティファクトを構築できるようになりました。AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、すぐにデプロイできるソフトウェアパッケージを作成する、フルマネージド継続的インテグレーションサービスです。 Apple のシステム ( iOS 、 iPadOS 、 watchOS 、 tvOS 、および macOS ) 向けのアプリケーションの構築、テスト、署名、および配布には、macOS でのみ実行される Xcode を使用する必要があります。AWS クラウドで Apple のシステム向けに構築するユーザーは、継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインを Amazon Elastic Cloud Compute (Amazon EC2) Mac インスタンス で実行するように設定している可能性が高いです。 2020 年に Amazon EC2 Mac をリリースして以来 、私はさまざまな業界や地域の お客様とかなりの時間 を過ごし、macOS でのパイプラインの設定と最適化をサポートしてきました。最も単純な形式では、お客様のパイプラインは次の図のようになります。 パイプラインは、ソースコードリポジトリに新しいコミットまたはプルリクエストがある場合に開始されます。マシンにインストールされたリポジトリエージェントは、さまざまなスクリプトをトリガーして環境を設定し、アプリケーションを構築およびテストして、最終的に App Store Connect にデプロイします。 Amazon EC2 Mac は、macOS マシンの管理とオートメーションを大幅に簡素化します。私はよく申し上げるのですが、EC2 Mac インスタンスには、Amazon EC2 で私が好んで使用している機能 ( Amazon Elastic Block Store (Amazon EBS) ボリューム、スナップショット、仮想プライベートクラウド (VPC)、セキュリティグループなど) がすべて備わっており、クラウドで macOS を実行している Mac mini に適用されます。 ただし、お客様には 2 つの課題があります。1 つ目は、ビルドに必要なすべてのツールを備えた Amazon マシンイメージ (AMI) を準備することです。最小限のビルド環境には Xcode が必要ですが、 Fastlane (および Ruby ) や他のビルドまたは開発ツールとライブラリをインストールするのが一般的です。ほとんどの組織では、macOS と Xcode バージョンの複数の組み合わせに対応するために、複数のビルド環境が必要です。 2 つ目の課題は、ビルドの数と期間に応じて、ビルドフリートをスケールすることです。大規模な組織では通常、1 日あたり数百または数千のビルドがあり、数十台のビルドマシンが必要になります。そのフリートのスケールインとスケールアウトは、コスト削減に役立ちます。EC2 Mac インスタンスは、専用予約されています。1 つのインスタンスは 1 つの専有ホストに割り当てられます。 専有ホストのフリートをスケール するには、特定の設定が必要です。 これらの課題に対処し、macOS ビルドマシンの設定と管理を簡素化するために、本日は CodeBuild for macOS をご紹介します。 CodeBuild for macOS は、最近リリースされた リザーブドキャパシティフリート をベースとしています。これには、CodeBuild によって管理される、Amazon EC2 を利用するインスタンスが含まれます。リザーブドキャパシティフリートでは、ビルド環境用に一連のハードウェア専有インスタンスを設定します。これらのマシンはアイドル状態のままとなり、ビルドまたはテストをすぐに処理できる状態であるため、ビルド時間が短縮されます。リザーブドキャパシティフリートでは、マシンは常に実行されており、プロビジョニングされている限りコストが発生し続けます。 CodeBuild は、ビルドを実行するための標準ディスクイメージ (AMI) を提供します。これには、開発およびビルド環境用の Xcode、Fastlane、Ruby、Python、Node.js、および他の一般的なツールのプリインストールバージョンが含まれています。 インストールされているツールの詳細なリスト は、ドキュメントでご覧いただけます。今後、これらのツールの更新バージョンを含む追加のディスクイメージを提供する予定です。必要に応じて、独自のカスタムディスクイメージを使用することもできます。 さらに、CodeBuild を利用すると、自動スケーリングを簡単に設定できます。必要なキャパシティをお知らせいただければ、当社がそこからすべてを管理します。 CodeBuild for macOS の動作を見てみましょう どのように機能するかを示すために、iOS で AWS Amplify の利用を開始するという私のお気に入りのプロジェクト用に CI/CD パイプラインを作成します。このチュートリアルと、それに付随するソースコードは、クラウドベースのバックエンドを備えたシンプルな iOS アプリケーションを作成する方法について説明するためのものです。アプリケーションは、GraphQL API ( AWS AppSync )、NoSQL データベース ( Amazon DynamoDB )、ファイルベースのストレージ ( Amazon Simple Storage Service (Amazon S3) )、およびユーザー認証 ( Amazon Cognito ) を利用します。 AWS Amplify for Swift は、これらすべてのサービスを結び付けます。 チュートリアルと、アプリケーションのソースコードは、Git リポジトリで入手できます 。これには、 アプリケーションのビルド、テスト、およびデプロイを自動化するスクリプト が含まれています。 CodeBuild for macOS を利用して新しい CI/CD パイプラインを設定するには、大まかには次のステップを実行します: ビルドプロジェクトを作成します。 マシンの専有フリートを作成します。 1 個以上のビルドトリガーを設定します。 パイプライン定義ファイル ( buildspec.yaml ) をプロジェクトに追加します。 開始するには、 AWS マネジメントコンソール を開き、CodeBuild を選択して、 [プロジェクトを作成] を選択します。 [プロジェクト名] を入力し、 [ソース] コードリポジトリへの接続を設定します。この例では GitHub を使用します。CodeBuild は GitLab と BitBucket もサポートしています。ドキュメントでは、 サポートされているソースコードリポジトリ の最新リストをご覧いただけます。 [プロビジョニングモデル] で、 [リザーブドキャパシティ] を選択します。これは、Amazon EC2 Mac インスタンスを使用できる唯一のモデルです。まだフリートを定義していないため、ビルドプロジェクトの作成中に作成することにしました。 [フリートを作成] を選択します。 [コンピューティングフリートの設定] ページで、 [コンピューティングフリート名] を入力し、オペレーティングシステムとして [macOS] を選択します。 [コンピューティング] で、ビルドプロジェクトに必要なメモリの量と vCPU の数を選択し、 [キャパシティ] で必要なインスタンスの数を選択します。 この例では、 [マネージドイメージ] を使用します。これには、Xcode 15.4 と、iOS 17.5 のシミュレーターランタイムなどのパッケージが含まれています。ドキュメントで、 このイメージにプリインストールされているパッケージのリスト をご覧いただけます。 完了したら、 [フリートを作成] を選択して、CodeBuild プロジェクトの作成ページに戻ります。 次のステップとして、新しいサービスロールを作成して、ビルド環境に必要な許可を定義するよう CodeBuild に指示します。このプロジェクトのコンテキストでは、Amplify の設定をプルして AWS Secrets Manager にアクセスするための許可を含める必要があります。これを実行するためのステップバイステップの指示はここには記載しませんが、 サンプルプロジェクトコードには私が追加した許可のリストが含まれています 。 ビルドコマンドのセットをプロジェクト定義で提供するか、またはプロジェクトに含まれる buildspec.yaml ファイルで提供するかを選択できます。私は後者を選択します。 これはオプションですが、ビルドアーティファクトを S3 バケットにアップロードしたいと思います。S3 バケットでは、各ビルドをアーカイブできます。したがって、 [アーティファクト 1 – プライマリ] セクションで、 [タイプ] として [Amazon S3] を選択し、 [バケット名] とアーティファクトの [名前] を入力します。アップロードするファイル名は、 buildspec.yaml ファイルで指定されます。 ページの下部で、GitHub WebHook を追加するプロジェクトトリガーを設定します。これにより、GitHub 上のプロジェクトにコミットまたはプルリクエストが送信されるたびに CodeBuild がビルドを開始するように設定されます。 最後に、ページの下部にあるオレンジ色の [プロジェクトを作成] ボタンを選択して、このプロジェクトを作成します。 ビルドのテスト プロジェクトには、ビルドの準備、プロジェクトの構築、テストの実行、 Apple の TestFlight へのデプロイを行うためのビルドスクリプトが既に含まれています。 プロジェクトのルートに buildspec.yaml ファイルを追加して、これらの既存のスクリプトをオーケストレートします。 version: 0.2 phases: install: commands: - code/ci_actions/00_install_rosetta.sh pre_build: commands: - code/ci_actions/01_keychain.sh - code/ci_actions/02_amplify.sh build: commands: - code/ci_actions/03_build.sh - code/ci_actions/04_local_tests.sh post_build: commands: - code/ci_actions/06_deploy_testflight.sh - code/ci_actions/07_cleanup.sh artifacts: name: $(date +%Y-%m-%d)-getting-started.ipa   files: - 'getting started.ipa' base-directory: 'code/build-release' このファイルを Git リポジトリに追加し、次のコマンドで GitHub にプッシュします: git commit -am "add buildpsec" buildpec.yaml コンソールで、ビルドが開始されたことを確認できます。 ビルドを選択すると、ログファイルを表示したり、 [フェーズの詳細] を選択してビルドの各フェーズの高レベルのステータスを確認したりできます。 ビルドが成功すると、iOS アプリケーションの IPA ファイルが S3 バケットにアップロードされているのを確認できます。 CodeBuild が実行する最後のビルドスクリプトは、バイナリを App Store Connect にアップロードします。App Store Connect の TestFlight セクションで新しいビルドを確認できます。 知っておくべきこと Amazon EC2 Mac インスタンスを準備して最初のビルドを受け入れるまでに、8～10 分 かかります。これは CodeBuild に固有の事象ではありません。マシンの準備時間中に送信するビルドはキューに入れられ、マシンが使用可能になり次第、順番に実行されます。 CodeBuild for macOS はリザーブドフリートで動作します。ビルドの 1 分ごとに料金が発生するオンデマンドフリートとは異なり、リザーブドフリートは、ビルドが実行されていない場合でも、ビルドマシンがお客様専用に予約されている時間について課金されます。キャパシティ予約は、 Software License Agreement for macOS (第 3.A.ii 条) が定めるとおり、Amazon EC2 Mac の 24 時間の最小割り当て期間に従います。 マシンのフリートは、AWS アカウントの CodeBuild プロジェクト間で共有できます。フリート内のマシンは、お客様専用に予約されています。CodeBuild だけがマシンにアクセスできます。 CodeBuild はビルド間で作業ディレクトリをクリーンアップしますが、マシンは他のビルドに再利用されます。これにより、 CodeBuild ローカルキャッシュメカニズム を使用して、ビルド後に選択したファイルを迅速に復元できます。同じフリートで異なるプロジェクトを構築する場合は、新しいビルドを開始する前に、 macOS キーチェーン などのグローバル状態と、 SwiftPM および Xcode パッケージキャッシュ などのビルドアーティファクトを必ずリセットしてください。 カスタムビルドイメージを使用する場合は、それらが 64 ビット Mac-Arm アーキテクチャ用にビルドされているようにしてください。また、 AWS Systems Manager Agent (SSM Agent) をインストールして起動する必要があります。CodeBuild は、 SSM Agent を利用して独自のエージェントをインストールし、マシンを管理します。最後に、AMI が CodeBuild 組織 ARN で使用できることを確認します。 CodeBuild for macOS は、次の AWS リージョン でご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト)。これらは、Amazon EC2 Mac M2 インスタンスを提供しているリージョンと同じです。 今すぐ使用を開始して、 macOS で最初の CodeBuild プロジェクトを作成 しましょう。 — seb 原文は こちら です。

2023年 3 月、 Jeff Barr は マレーシアの AWS リージョン の計画を発表しました。8月19日、3 つのアベイラビリティーゾーンと API 名「ap-southeast-5」を備えた AWS アジアパシフィック (マレーシア) リージョンの一般提供についてお知らせできることを嬉しく思います。 AWS アジアパシフィック (マレーシア) リージョンは、マレーシア初のインフラストラクチャリージョンであり、アジアパシフィックでは香港、ハイデラバード、ジャカルタ、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京の既存のアジアパシフィックリージョンと、中国本土の北京および寧夏リージョンに加わる 13 番目のリージョンです。 クアラルンプールのオフィス街中心部にあるペトロナスツインタワー。 マレーシアの新しい AWS リージョンは、マレーシア政府による戦略的 マダニ経済政策 (Madani Economy Framework) を支援する上で極めて重要な役割を果たします。このイニシアチブは、2030 年までにすべてのマレーシア国民の生活水準を向上させるとともに、マレーシアおよび ASEAN 全体のイノベーションを支援することを目的としています。新しい AWS リージョンの構築と運用により、マレーシアの国内総生産 (GDP ) は約 121 億 ドル (573 億 MYR) 増加すると推定され、2038 年までに外部企業にて毎年平均 3,500 件以上のフルタイム相当の雇用が生まれるとされています。 マレーシアの AWS リージョンは、クラウドサービスに対する高い需要に応えながら、マレーシアおよび東南アジア全体のイノベーションをサポートするのに役立ちます。 マレーシアでの AWS 2016 年、Amazon Web Services (AWS) はマレーシア初の AWS オフィスを開設しました。それ以降、AWS はマレーシアのデジタルトランスフォーメーションを促進するために、インフラストラクチャとテクノロジーに継続的に投資し、毎月何十万ものアクティブなお客様をサポートしてきました。 Amazon CloudFront – 2017 年、AWS はマレーシア初のエッジロケーションの立ち上げを発表しました。これにより、エンドユーザーのパフォーマンスと可用性が向上しました。現在、マレーシアには 4 つの Amazon CloudFront ロケーションが存在します。 AWS Direct Connect – マレーシアのお客様のアプリケーションパフォーマンスの向上、データの保護、ネットワークコストの削減を引き続き支援するため、AWS は 2017 年、マレーシアに Direct Connect ロケーションを追加開設することを発表しました。現在、マレーシアには 2 つの AWS Direct Connect ロケーションがあります。 AWS Outposts – AWS インフラストラクチャと AWS サービスを拡張する完全マネージド型サービスである AWS Outposts は、低レイテンシー要件を満たすためにオンプレミスで実行する必要があるアプリケーションに最適です。2020 年以降、マレーシアのお客様は AWS Outposts を注文して、データセンターやオンプレミスのロケーションにインストールできるようになりました。 マレーシアの AWS のお客様 マレーシアでのクラウドの採用は、近年着実に勢いを増しています。マレーシアの AWS のお客様の例と、さまざまなワークロードで AWS がどのように使用されているかを次に示します。 PayNet – PayNet はマレーシアの全国決済ネットワークであり、マレーシアの金融市場向けの共通中心インフラストラクチャです。PayNet は AWS を使用して、MyDebit オンラインキャッシュレス決済システムや電子決済レポートなど、全国の重要な決済ワークロードを実行しています。 Pos Malaysia Berhad (Pos Malaysia) – Pos Malaysia は全国郵便および宅配サービスプロバイダーであり、マレーシアの全国郵便サービス義務に基づくサービスを提供する権限を持つ唯一の組織です。重要なアプリケーションを AWS に移行したことで、Pos Malaysia のビジネスの俊敏性が向上し、カスタマーエクスペリエンスの向上にもつながりました。また、 Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) を使用して、1,100 万を超える住所と 3,500 を超える小売タッチポイントのネットワークへの配送を処理できるようにコンピューティング能力を拡張し、サービスが中断されないようにしています。 Deriv – 世界最大のオンラインブローカーの 1 つである Deriv は、 Amazon Q Business を使用して、カスタマーサポート、マーケティング、採用部門にわたる業務の生産性、効率性、イノベーションを向上させています。Deriv は Amazon Q Business を活用することで生産性を向上し、オンボーディングにかかる時間の 45% 短縮を実現しました。 アジアパシフィック大学 – マレーシアを代表する工業大学の 1 つであるアジアパシフィック大学 (APU) は、Lambda などの AWS のサーバーレステクノロジーを使用して運用コストを削減しています。AWS サービスの自動スケーラビリティ機能により、高可用性と迅速なデプロイが実現され、学生やスタッフがいつでも APU のアプリケーションとサービスにアクセスできるようになり、全体的なユーザーエクスペリエンスが向上しました。 Aerodyne – Aerodyne Group は、ドローンベースのエンタープライズソリューションを提供する DT3 (ドローンテック、データテック、デジタルトランスフォーメーション) ソリューションプロバイダーです。世界中のドローン事業者の事業拡大を支援するために、AWS で DRONOS Software as a Service (SaaS) プラットフォームを実行しています。 ともにクラウドスキルを構築 AWS とマレーシアのさまざまな組織は、必要とされるクラウドスキルをマレーシアのビルダーが身に付けられるように、密接に連携してきました。取り組みの一部をご紹介します。 AWS re/Start による Program AKAR – Program AKAR は、AWS と PayNet によって開始された最初の金融サービス連携クラウドスキルプログラムです 。この新しいプログラムは、この分野でのキャリアに必要とされる応用可能なスキルを学生に習得させ、マレーシアのデジタル経済におけるスキルギャップの拡大を埋めることを目的としています。最初のコラボレーションの一環として、PayNet、AWS re/Start、WEPS は、2024 年に 100 人の学生を対象にプログラムを開始することを約束しました。まず、アジアパシフィック大学の 50 人の学生がパイロットとして参加します。 AWS Academy – AWS Academy は、無料ですぐに学習できるクラウドコンピューティングカリキュラムを学生に提供し、業界で認められた認定資格やクラウドでのキャリアに備えさせることで、産業界と学界のギャップを埋めることを目的としています。AWS Academy は現在、マレーシアの 48 の大学でさまざまな分野のコースを運営しています。2018 年以降、23,000 人の学生がこのプログラムを通じてトレーニングを受けています。 PETRONAS の AWS Skills Guild – PETRONAS は 50 か国以上に拠点を置くグローバルなエネルギーおよびソリューションプロバイダーで、2014 年以来 AWS を使用しています。また、AWS は PETRONAS と協力し、AWS Skills Guild プログラムを使用して従業員をトレーニングしています。 マレーシアの持続可能性に対する AWS の貢献 Amazon は「 気候変動対策に関する誓約 」(The Climate Pledge) により、2040 年までに事業全体で二酸化炭素排出量をネットゼロにすることにコミットしており、2025 年までに事業運営に必要な電力を 100% 再生可能エネルギーで賄えるように取り組みを進めています。 2023 年 9 月、AWS は世界のエネルギー転換における持続可能性と脱炭素化の取り組みを加速させるために、世界的なクリーンエネルギー企業である Petronas および Gentari との 連携を発表 しました。そのすぐ後の 2023 年 12 月、AWS の顧客である PKT Logistics Group は、世界におけるネットゼロカーボン達成への道のりを加速させるために、300 社を超えるグローバル企業と連携し、「The Climate Pledge (気候変動対策に関する誓約)」に参加した 最初のマレーシア企業 となりました。 2024 年 7 月、AWS と Zero Waste Management は共同で史上初の AWS InCommunities Malaysia イニシアチブである Green Wira Programme に取り組みました。このプログラムは、マレーシアの持続可能な未来を実現するために、学校で持続可能性に関する取り組みを行う教育者を養成するものです。 Amazon は、より持続可能な未来を創造するために、事業全体にわたって投資およびイノベーションに取り組んでいます。 知っておくべきこと マレーシアの AWS コミュニティ – マレーシアには、1 人の AWS ヒーロー、9 人の AWS コミュニティビルダー、そしてマレーシアのさまざまな都市にある 3 つの AWS ユーザーグループに所属する約 9,000 人のコミュニティメンバーが存在します。マレーシアの AWS ユーザーグループへの参加に興味がある場合は、 Meetup と Facebook のページにアクセスしてください。 AWS のグローバルフットプリント – この立ち上げに伴い、AWS の事業活動の場は、世界各地の 34 の地理的リージョンにおける 108 のアベイラビリティーゾーンに広がりました。また、メキシコ、ニュージーランド、サウジアラビア王国、台湾、タイ、および AWS European Sovereign Cloud に 18 のアベイラビリティーゾーンと 6 つの AWS リージョンを追加する計画も発表されました。 今すぐ利用可能 – 新しいアジアパシフィック (マレーシア) リージョンでは、お客様のビジネスをサポートする準備が整いました。このリージョンで利用できるサービスの詳細なリストは、「 リージョン別の AWS サービス 」ページに記載されています。 詳細については、「 AWS グローバルインフラストラクチャ 」のページにアクセスしてください。そして、 ap-southeast-5 で構築を開始しましょう。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

こんにちは。 AWS パブリックセクター技術統括本部の松本です。 2023 年 6 月、 自治体のお客様向け「ガバメントクラウド利用タスクリスト」を公開します というブログで、RFP/RFI にお役立ていただける作業内容一覧 (タスクリスト) を公開しました。 その後、GCAS (Government Cloud Assistant Service) の機能整備が進んだり、 地方公共団体情報システムのガバメントクラウドの利用について 【第 2.1 版】 や「ガバメントクラウド利用における推奨構成（AWS 編）」が一般公開されたりと、ガバメントクラウドの利用について様々なアップデートありました。 状況の変化に合わせタスクリストについて内容を更新したため、自治体においては調達仕様の策定、事業者においては事業者間の役割分担の明確化にご利用ください。 本ブログでは、2024 年版 タスクリストの概要と利用方法について解説します。 タスクリストの全体構成 2024 年版 タスクリストは 6 つのシートから構成されています。 以下の表でそれぞれのシートの概要を解説します。 シート名 概要 免責事項 本タスクリストを利用する上での注意点や免責事項が記載してあります。 テンプレート タスクリストのテンプレートです。本シートをコピーしてご利用ください。 単独利用方式中心の構成例 政令市に多い、単独利用方式を中心にガバメントクラウド環境を構成する場合のアーキテクチャを示しています。 単独利用方式中心の役割分担例 単独利用方式中心の場合について、テンプレートのシートを埋めた例を示しています。 共同利用方式中心の構成例 小-中規模自治体に多い、共同利用方式を中心にガバメントクラウド環境を構成する場合のアーキテクチャを示しています。 共同利用方式中心の役割分担例 共同利用方式中心の場合について、テンプレートのシートを埋めた例を示しています。 タスクリストの概要 大きくはタスクリストのテンプレートと、2 つの構成例 (単独利用方式中心/共同利用方式中心)の場合にタスクリストをどのように埋めていけばいいかについて記載した Excel ファイルとなっています。 例えば、タスクリストのテンプレートは以下の図のように大きく「タスクの分類・概要」が記載してある列と「関係する事業者名」を記載する列で構成されています。 構成例・役割分担例については以下の構成図をもとに「単独利用方式中心の例」と「共同利用方式中心の例」について記載しています。 構成例・役割分担例はあくまでサンプルですので、自治体ごとに最適な構成・役割分担をご採用ください。 各項目の概要や先行事例、ガバメントクラウドにおける事業者の役割定義について知りたい方は、 AWS Summit Japan 2024 の セッション「先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくこと」 をご視聴ください。 テンプレートの使い方 ① 構成図を書いてみる 構成図を書く際のポイント まず、ガバメントクラウド全体の構成を把握するために概要でいいので構成図を記載します。 構成図を記載するためのアイコン等は AWS アーキテクチャアイコン でダウンロードできます。 役割分担を明確にする目的で構成図を書く際のポイントについて以下にまとめましたので、ご参考ください。 ② 関係する事業者名を記載する 「2. テンプレート」シートをコピーし、事業者名をガバメントクラウド環境に関連する事業者名へ変更します。 可能であれば、「回線運用管理補助者」や「統合運用管理補助者」等、 地方公共団体情報システムのガバメントクラウドの利用について 【第 2.1 版】 に記載されている役割定義、利用方式についても併記します。 ③ 各タスクの担当事業者を決める 次に、各タスクを事業者へ割り振っていきます。各行について ◯ がつくようにしますが、タスクによっては複数の事業者が関係します。 その場合はテキストで各事業者が何を実施するのか補足を記載します。 タスクの担当を整理する中で「① 構成図を書いてみる」で作成した構成図に記載が漏れていた AWS サービスなどがあれば追記していきます。 完成した構成図と役割分担表を調達の際のドキュメントにお役立ていただいたり、事業者へ共有し委託作業範囲の明確化にご利用ください。 以上が 2024 年版 タスクリストの使い方でした。 ダウンロード タスクリストは以下リンクよりダウンロード可能です。 ガバメントクラウド事業者タスクリストのダウンロードはこちら まとめ この記事では 2024 年版 タスクリストの概要と利用方法についてお伝えしました。 自治体ごとに既存環境や各事業者の役割分担は異なり、整理に苦労されている方も多いと思います。 このタスクリストを事業者間の役割分担を明確化や調達の際のドキュメント作成にぜひご活用ください。 免責事項 タスクリストの情報はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本タスクリストはあくまで一例であり、全ての作業内容を充足するものではありません。 本タスクリストはガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本タスクリストの利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承の上、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けております。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

はじめに 2024 年 6 月 20 日、21 日に AWS Summit Japan を開催し、“あなたのアイデアをその場でアプリ化！生成 AI プレイグラウンド PartyRock” というタイトルでブースの展示を行いました。当日は、絶えずたくさんの来場者の方々にブースにお越しいただき、PartyRock でのアプリケーション作成を体験してもらうことができました。 本ブログでは、ブース展示のサポーターとして参加した新入社員の九曜と山本が、当日の様子や来場者の皆様から頂いた声を通し、PartyRock の魅力についてより皆さんにご紹介いたします。 PartyRock とは PartyRock とは、“誰でも生成 AI のアプリケーションを作成でき、実験を通して学べる教育ツール” です。メールのドラフトを作成したり、アイデアについて意見を求めたり、ちょっとした資料に使うイラストを作成したりなど、生成 AI は様々な用途で利用され始めています。PartyRock は、様々なユースケースをコーディング一切不要でアプリケーション化できる、AWS アカウント不要の Amazon Bedrock の生成 AI プレイグラウンドです。こんなアプリケーションが欲しいな…を言語化するだけで誰でも簡単にアプリケーションを作成することができます。また、自分で作成したアプリケーションを他の利用者にシェアすることも可能です。 そんな PartyRock の良さを、より多くの人に知ってもらいたい！という気持ちから、今回のブースの展示が企画されました。 また、PartyRock に関しましては、 PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス | Amazon Web Services ブログ にてより詳しく説明しています。 ブース紹介 今回の AWS Summit Japan 2024 PartyRock ブースでは、PartyRock をきっかけに、AWS での 生成 AI の可能性を来場者の方々に体験してもらおう！というテーマで展示制作を行いました。 当日は、AWS Summit Village にて PartyRock ブースを展示し、来場者の方々にあらかじめ用意したアプリケーション体験してもらったり、アイデアをその場でアプリケーション化していただきました。 あらかじめ用意したアプリケーションは、 AWS Summit Japan 2024 で紹介したサンプルアプリ集 誰でも簡単に生成 AI を活用！ AWS Japan メンバーが作った PartyRock アプリ集 | Amazon Web Servic… にてより詳しくご覧いただけます。 実際の様子 当日は絶えずたくさんの来場者の方々にブースにお越しいただきました。著者たちも当日ブースを対応しました。そこで特に人気だった PartyRock のアプリケーションをご紹介させていただきます。 人気だった PartyRock のアプリケーションのご紹介 難しいドキュメントも博士と太郎くんが何でも解説アプリ こちらのアプリケーションは、ドキュメントのファイルをアップロードし、“難しいドキュメントでも、博士と太郎くんが会話しながらわかりやすく解説してくれる” というものです。それぞれ博士と太郎くんの言葉遣いなども細かく再現されており、難しいドキュメントの内容がスラスラと読める便利アプリケーションです。博士と太郎くんイメージ画像も 生成 AI を用いて作成されます。 お客様からは「会話形式で解説してくれるのは面白い。」「博士の口調が『〜じゃ。』のようになっていて親しみやすい。」というように会話形式のスタイルに好印象を持った感想や、「わからない部分も追加で聞くと博士が答えてくれるので便利。」「会社のドキュメントを使って似たようなことができると良い。」といった利便性を評価した感想もいただきました。 新サービス企画支援アプリ こちらのアプリケーションは、サービス名と概要を入力するだけで、Amazon 流の新サービス検討プロセス「Working Backwards」に従って、新サービスの「プレスリリース」をドラフトします。サービス名と概要のインプットからアイデアを膨らまし、簡単に Amazon 風のサービス紹介、サービスイメージ画像を生成します。 お客様からは「一つの入力だけで、画像やテキストなどの様々なフォームの出力がチェーン状に繋げられて面白い」「出力結果を元にさらに詳しい内容をチャットで聞けるのはのはすごい」などの声をいただきました。 ブース全体を通して、ご来場いただいた方からは、 「AWS アカウント不要で使えるのは素晴らしい。」 「エンジニアでなくても簡単にアプリが作れる。IT を身近にするための良いサービス。ハッカソンに活用できそう。」 といったように、アプリに触れて PartyRock の良さを実感したコメントを多くいただきました。 PartyRock ブース展示中の様子 （新入社員でデザイン・発注を担当した PartyRock オリジナルグッズ）1/2 & PartyRock ブース展示中の様子 2/2 PartyRock から始まる、生成 AI 業務活用の可能性！ チャットボットや画像生成など、個人として生成 AI を利用している方は多いかもしれませんが、仕事や会社で活用を進めているという方はまだ比較的少ないのではないでしょうか？ AWS では、これまでに 100 以上の本番環境での生成 AI 活用を支援してきました。業種業界を問わず、早期に生成 AI 活用を実現しビジネス成果を上げたお客様には 3 つの共通点があります。 1 つ目は、生成 AI 活用プロジェクトに最大 4 人の少人数で取り組んでいること、2 つ目は、3 ヶ月以内というスピーディー企画・開発期間で本番導入に至っていること、そして 3 つ目は、システムを定量的に評価していることです。 これらの共通点は、AWS Japan のあらゆるお客様の生成 AI 活用を継続的に支援してきた経験から見えてきたものです。AWS Japan は 2023 年に AWS LLM 開発支援プログラムを提供し、基盤モデル開発を行う国内企業 17 社に技術支援を提供しました。2024 年には生成 AI 実用化推進プログラムを発表し、生成 AI の活用によってビジネス課題の解決にチャレンジする企業・団体に、包括的な支援を提供しています。 このセクションでは、PartyRock で触れていただいた AI の可能性を、実際に業務活用するための道筋をご紹介します。 AWS を用いた生成 AI 業務活用への道のり Phase 1：生成 AI 活用の計画を探索 生成 AI 業務活用への第一歩は、活用アイデアを探索することから始まります。ビジネスでの業務活用にあたり、まず「生成 AI でどのようなものが作れるのか」「それをどのように業務に活かすことができるのか」というアイデアを膨らませることが大切です。 そこで役に立つサービスが、今回 Summit でご紹介した PartyRock です。 PartyRock ホームページ画像 PartyRock で業務活用のアイデアを膨らませた次のステップでは、生成 AI に対する理解を深め、展開のためのアクションプランを立てていきます。 生成 AI を用いたシステムを導入するにあたり、社内で多くの人々が関係者となります。IT 知識の有無に関わらず、「導入を検討しているシステムがどのようなものなのか」「生成 AI でどのような効果が得られるのか」など、AI リテラシーを高めると共に、組織全体で計画を立てていくことが必要になってきます。 このような具体的なアクションプランを練る一つの方法は、AWS の提供する ML Enablement Workshop  （MLEW） の実施です。 MLEW は、生成 AI を含めた AI/ML 技術を自社ビジネスに適用し、成長につなげるための実行計画を策定するワークショップです。ワークショップでは、組織横断でのチームの組成企画を行い、ビジネス側と開発側が一体となり取り組みます。 ビジネスオーナーと開発者が一体となり、生成 AI が生み出すビジネス効果のコンセンサスを共有することが、プロジェクト成功の鍵となります。 株式会社ココペリにおける AWS 生成 AI 事例: ML Enablement Workshop によるユースケース特定とその検証 | A… PartyRock からのスタートではないですが、MLEW を実際に行ったお客様を紹介します。 ココペリ様は「中小企業にテクノロジーを届けよう」というビジョンのもと、IT 技術で全国の金融機関と共に中小企業同士を繋ぐサービスを提供しています。提供サービスの一つに、 中小企業 DX 支援プラットフォーム「Big Advance」 があります。 Big Advance に  AI/ML を活用する際に、技術的な側面のみならずビジネス視点での成長戦略を含めて練りたいとのことでワークショップを実施し、生成 AI のユースケースの特定、 タスクと効果測定 KPI の決定に繋がりました。 Phase 2：本番データを用いた検証 生成 AI でできることを理解し業務活用のアイデアを練ることができたら、次は、本番データを用いて実験を行ってみましょう。AWS ジャパンでは、お客様の AWS アカウント上に簡単にデプロイできる生成 AI アプリケーションのサンプル実装を公開しています。これらを利用することで、セキュアな実験環境を作って検証を行うことができます。ここでは、サンプルアセットを 2 つ紹介します。 Bedrock Claude Chat Bedrock Claude Chat  （BrChat）は生成 AI を用いたチャット機能をすばやくかつセキュアにデプロイできるアプリケーションです。検索拡張生成（RAG, Retrieval Augmented Generation）、またシステムプロンプトを埋め込んだカスタムボットの共有などチャットに特化した機能を提供しています。BrChat を使ってチャットボットを作成した ブログ も公開されていますのでご参照ください。 Generative AI Use Cases JP Generative AI Use Cases JP  （GenU） は 生成 AI の様々なユースケースをワンストップで試せるアプリケーションです。チャットだけでなく、要約、画像生成、検索拡張生成、文書校正、翻訳、 Web コンテンツの抽出といった機能をすぐに試し効果を体感できます。 独自の生成 AI ワークフローをすばやく構築する際には  Amazon Bedrock Prompt Flows  を使うこともできます。 Amazon Bedrock Prompt Flows は 7 月にプレビューが公開された機能で、GUI を使って基盤モデル、Knowledge Base、AWS Lambda などのAWS サービスを簡単に統合し、生成 AI ワークフローをデプロイすることができます。 実験の結果、狙ったユースケースを実現できたら、早期にテストユーザーに実験で作成した生成 AI ユースケースを試してもらい、想定したビジネス効果が得られそうかを確認します。 Phase 3：ユーザーへの展開を開始 Phase 2 で実験を重ね、一定の効果が見込めればユーザーへの本格的な展開に移行します。この段階では、Amazon Bedrock や Amazon SageMaker などの生成 AI アプリケーションを構築するためのサービスをフルに活用しましょう。この段階でも継続的に改善を重ね、必要に応じて Phase 1 や Phase 2 に立ち返ってみましょう。 ユーザーへの展開に成功しているお客様の事例を 2 つ紹介します。 北海道文化放送様 では、Amazon Bedrock を活用し FAX 受信からニュース原稿および動画までの作成フローを自動化し、毎月 100～120 本のコンテンツ増加を実現しました。 三井物産株式会社様 では、入札書類の解析を自動化するソリューションを開発し、解析作業を 70 % 短縮することに成功しました。 最後に 初めてブース展示に立ち、サービスをお客様に紹介するという経験は、私たち新入社員のソリューションアーキテクトとして非常に緊張するものでした。しかし、PartyRock を実際に体験していただき、お客様の生の反応を直に感じ取ることができ、貴重な機会になりました。 今回の AWS Summit Japan は、多くの人に PartyRock を体験していただき、新たなビジネスアイデアを考えるきっかけとなる有意義なイベントであったと思います。 生成 AI に興味をお持ちの方は、まずはぜひ PartyRock で気軽にアプリを作ってみてください。PartyRock が、生成 AI の業務活用ジャーニーをスタートさせるきっかけになると幸いです。 本ブログは、ソリューションアーキテクトの九曜と山本が執筆し、ソリューションアーキテクトの松本が監修しました。 著者について 九曜 克之 （Katsuyuki Kuyo） アマゾン ウェブサービス ジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 趣味はマンガを読むことです。 山本 ひかる （Hikaru Yamamoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 お客様の技術課題に Dive Deep できるよう毎日勉強中。 松本 敢大 （Kanta Matsumoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。好きな AWS サービスは AWS IoT Core。趣味はカメラで、動物が好きです。

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。 過去の記事はこちらになります。 ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』 ガバメントクラウド活用のヒント『ガバメントクラウド上で CIDR 重複を起こさないために！』 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 当記事 少し発展的な内容となっておりますので、ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、見積もりで注意すべきポイントについて扱っていきます。見積もりを作成したいベンダーの方々や、ベンダーから提出された見積もりに過不足がないかチェックしたい自治体の方々を対象としています。 ※このブログは、地方公共団体の基幹業務システムを構成する代表的な AWS サービスを対象として、見積もりのポイントを示すための参考情報であり、実際に構成するサービスは利用する ASP ベンダーのアプリケーションに依存しますのでご留意ください。 以下のセクションで構成されています。 コンピューティング費用の見積もり ネットワーク費用の見積もり ガバナンス・セキュリティ費用の見積もり バックアップ費用の見積もり AWS Pricing Calculator への入力 コスト削減のヒント まとめ ※本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。 コンピューティング費用の見積もり クラウド費用全体のうち、コンピューティング費用が大部分を占めるので、コンピューティングサービスの見積もりは非常に重要です。現行システムの OS/CPU/メモリや、CPU 使用率・メモリ使用率の情報があれば、それを参考にインスタンスを選定していきます。 Amazon EC2 の見積もり インスタンスタイプの選択 インスタンスタイプには、インスタンスファミリー、インスタンス世代、インスタンスの追加機能、インスタンスサイズなどの情報が含まれます。例えば、 c7gn.xlarge というインスタンスタイプでは、インスタンスファミリーが c、インスタンス世代が 7、追加機能が g と n、インスタンスサイズが xlarge であるということがわかります。 EC2 のインスタンスタイプの選択の詳細については、詳しくは「 AWS における効率的なコンピュートサービス活用入門 」の資料もご覧ください。 インスタンスファミリーの選択 インスタンスファミリーはメモリ・I/O・CPU クロック重視・GPU・FPGA 搭載などの種類を表します。多くの種類がありますが、一般的にはメモリ要件に合わせて、メモリは少なくてもよいときはコンピューティング最適化の C インスタンス、より大きいメモリ量が必要なときはメモリ最適化の R インスタンス、その他のときは汎用の M インスタンスを選択することが多いです。 定常的な CPU 性能が不要な検証環境などでは、安価に利用できる T インスタンスを選択する場合もあります。 例えば、インスタンスサイズとしては同じ medium を利用した場合でも、vCPU 数やメモリの大きさに以下のような違いがあります。 インスタンスタイプ vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) コスト (/GB 月 ) M7g.medium 1 4 EBS のみ 最大 12.5 最大 10 USD 0.0527 C7g.medium 1 2 EBS のみ 最大 12.5 最大 10 USD 0.0455 R7g.medium 1 8 EBS のみ 最大 12.5 最大 10 USD 0.0646 ※コストは東京リージョン、Linux のインスタンス インスタンス世代の選択 同じインスタンスファミリーでも、世代が進むにつれて数字が大きくなります。一般的には新しい世代の方が高性能でコストパフォーマンスもよいので、要件に合わせてできるだけ新しい世代のもののご利用をお勧めします。 インスタンスの追加機能の選択 第 6 世代以降では、すべてのインスタンスタイプで CPU タイプを表す記号が付与されています。例えば、　Intel Xeon 搭載なら i、AMD EPYC 搭載なら a、 AWS Graviton (Arm ベースの CPU) 搭載なら g です。ご利用のアプリケーションパッケージがご利用のインスタンスの CPU に対応しているか確認すると良いでしょう。 その他の情報については、 インスタンスタイプのページ などをご参照ください。 インスタンスサイズの選択 インスタンスサイズが増加すると、 vCPU 数とメモリ、EBS 帯域幅、ネットワーク帯域幅が増加します。移行対象となるシステムで現在利用している vCPU 数やメモリサイズを参考にして選択してください。 計算命令を多用するシステムであれば、CPU 数やクロック数を基準に見積もりを考えた方が良いでしょう。それに対し、I/O (データアクセス) が主体なものは、高速ストレージを主体に見積もりをする方が良いでしょう。データアクセス処理をメモリ領域で処理することで、高額な I/O コストを支払う場合に比べてメモリを増やす方が安価にすることが出来る場合があります。 また、現在のサーバリソースの使用率を加味することで、より適切なインスタンスの使用を検討できます。例えば、現行システムが AMD プロセッサを利用したオンプレミスサーバーで動いており、そのサーバーの CPU コア数が 8 で CPU 使用率が 20%、メモリが 32GiB で使用率が 70% の時、必要な vCPU 数が 2 、メモリが23GiB となるので、r6a.xlarge を選定する、ダウンサイジングという考え方も検討することが可能です。 Amazon EBS の見積もり EBS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります (マグネ ティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。 実際に利用しているサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパ シティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることが出来ます。 Amazon EBS ボリュームの種類については、 ドキュメント もご覧ください。 IOPS/スループットの追加 gp3 タイプを例に挙げて、IOPS/スループットの追加の考え方についてご説明いたします。gp3 では、デフォルトで 3,000 IOPS、125 MiB/秒のスループットを一貫したベースラインパフォーマンスとして提供しています。追加料金を支払うことで、最大で16,000 IOPS、1,000 MiB/秒のスループットまでプロビジョニングできます。また、EC2 のインスタンスごとに IOPS およびスループットの上限もございますのでご注意ください。 IOPS およびスループット追加は、実際に稼働した上で Amazon CloudWatch などで監視し、IOPS やスループットがボトルネックとなっている場合にご検討いただくことになると思います。 gp3 タイプの IOPS およびスループットの詳細については ドキュメント もご覧ください。 EBS のスナップショットの考え方 スナップショットの料金に関わってくるパラメータには、以下のようなものがあります。 スナップショットを取得する頻度 初期スナップショットの容量（=EBS の容量） 増分スナップショットあたりの増加容量 フルバックアップではなく増分バックアップですので、前回のスナップショットからの変更分のみ新たに保存されます。 RDS の見積もり RDSでは以下の要素に応じて料金が発生します。 利用するノード数 利用するノード数には、マルチ AZ 構成、リードレプリカ構成(数)なども含みます。 構築するインスタンスタイプ RDS のインスタンスタイプは、EC2 と同様に主に「汎用」、「メモリ最適化」、「コンピューティング最適化」、その他があり、RDS で実行するワークロードの特性により選択することになります。 既存システムから現状ワークロード指標を検討する場合、現状のワークロードを分析し、必要リソースを確認し初期見積もり値を決定します。繁忙期が存在する場合、繁忙期のワークロード量もさらに分析を行い加味することが必要です。パフォーマンス分析レポートを定期的に取得している場合は、そのレポートを基に分析を行うことも可能です。 新規システムとして検討する場合で、類似のシステム (利用者数や業務数・機能要件の観点に基づき) がある場合は、該当システムのリソース状況から選定し初期見積もりを行います。類似のシステムが無い場合、小規模・中規模想定のシステムとしてインスタンスタイプを見積もり、その後、パフォーマンステスト実施後に再度、ワークロードを分析し、改めて見積もりを行います。 初期見積もりが終わった後、早期に見積もりの妥当性を確認するための PoC を実施します。その結果を踏まえ、改めて必要なインスタンスタイプの見積もりを行います。 詳細については、以下のページもご覧ください。 Amazon RDS インスタンスタイプ | AWS DB インスタンスクラス – Amazon Relational Database Service RDS プロキシ利用有無 RDS プロキシは、基となるインスタンスの容量に基づいて料金が設定されています。サーバーレスアプリケーション (例: Amazon Lambda など) を開発している場合、データベース接続をプールおよび共有することでセッション接続・切断が効率的に行えます。 詳細については、以下のページもご参照ください。 Amazon RDS Proxy | 高可用性データベースプロキシ | Amazon ウェブサービス 商用ライセンス利用の有無 RDS で商用データベースを利用する際は、ライセンス費用も発生します。ライセンスの支払い体系としては、ライセンス持ち込み (BYOL) とライセンスインクルード (LI) があります。 データベースストレージボリュームサイズ RDS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります(マグネティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。 データベースストレージのボリュームは、実際のレコード件数に基づくサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパシティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易 (RDS ストレージの自動スケーリング) なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることができます。 詳細については、以下のページもご参照ください。 Amazon RDS DB インスタンスストレージ – Amazon Relational Database ServiceAmazon R… Amazon RDS DB インスタンスのストレージを使用する – Amazon Relational Database Service モニタリングとしての Performance Insights 利用有無と保存期間 データベースのモニタリング方法としては、Amazon CloudWatch メトリクスや、Enhanced Monitoring があります。 さらに、データベースアクティビティのモニタリング方法として Performance Insights が挙げられます。データベース内のパフォーマンスデータを蓄積してボトルネックを特定するのに役立ちます。直近で 7 日間のパフォーマンス履歴は、無料で保存できますが、それ以前のデータベースアクティビティを確認したい場合、料金が発生します。アプリケーションの実行サイクルを加味して、日・週・月・半期・年度の単位でデータベースアクティビティを分析する必要があるかをあらかじめ想定する必要があります。 詳細については、以下のページもご参照ください。 Amazon RDS の Amazon CloudWatch メトリクス – Amazon Relational Database Serv… 拡張モニタリングを使用した OS メトリクスのモニタリング – Amazon Relational Database Service Performance Insights（RDSのパフォーマンスを分析、チューニング）| AWS 料金 – Performance Insights | AWS バックアップストレージサイズ 自動バックアップが保持される日数として 1 日～ 35 日が選択できます。保存期間によりバックアップ料金が異なります。 CloudWatch を利用したRDSの監視・ログ出力 CloudWatch を利用し RDS の CPUUtilization、FreeableMemory などの監視や通知設定が可能となります。また、各ログの収集も可能となります。メトリックの数やダッシュボード利用数、アラーム設定数、ログサイズ等により CloudWatch の料金は異なります。 詳細は、 料金 – Amazon CloudWatch | AWS 　をご確認ください。 最後に 合わせて、以下の公式サイト情報もご確認ください。 料金 – Amazon RDS | AWS 料金 – Amazon Aurora | AWS Amazon RDS の月額費用を計算する方法を教えてください。 Amazon RDS のコスト見積もり ネットワーク費用の見積もり ガバメントクラウドの AWS アカウントでは、庁舎と AWS 環境を閉域で接続するために、AWS Direct Connect や AWS Transit Gateway などのサービスを活用します。ガバメントクラウドでよくある構成 3 パターンについて 2024 年 4 月時点での料金をまとめましたので、近いパターンをご参照ください。地方公共団体からガバメントクラウドへの接続パターンや、ネットワークアカウントとそれを管理するネットワーク構築運用補助者のタスクの詳細については、 ガバメントクラウドの道案内『ネットワーク構築運用補助者編』のブログ をご覧ください。また、現在の価格や詳しい情報については、それぞれのサービスの料金ページをご覧ください。 利用する AWS アカウントの整理 以下で説明するそれぞれのパターンについて、以下の 2 つのアカウントが出現します。 ネットワークアカウント：自治体庁舎からの専用線接続を集約するために存在するアカウントです。AWS Direct Connect で庁舎と AWS 環境を接続し、AWS Transit Gateway をハブとして、アプリケーションアカウント内の VPC との通信を実現しています。AWS Direct Connect や AWS Transit Gateway はこのネットワークアカウントに集約し、ネットワーク構築運用補助者が運用管理を行います。 アプリケーションアカウント：アプリケーションが動作しているコンピューティングリソースが存在するアカウントです。異なるベンダーの管理するアプリケーションアカウントが複数存在する場合が一般的です。 VPN や AWS PrivateLink なしの構成 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 （契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます） AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 AWSと外部: VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway アタッチメント から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS PrivateLink を利用した構成 共同利用方式 (アプリケーション分離) などで自治体庁舎の IP アドレス範囲とアプリケーションが存在する IP アドレス範囲が重複してしまう場合、通信するために AWS PrivateLink というサービスを用いることがあります。 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます) AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 AWS内: AWS PrivateLink を設置してアプリケーション VPC 通信を中継させる VPC について、VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: AWS PrivateLink のインターフェイスエンドポイントについて、時間単位で 0.014USD/時間、データ処理料金として 0.01USD/GB それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 (AWS PrivateLink 経由で通信するアカウントの場合) AWS内: ネットワークロードバランサー (NLB) の料金。詳しくは 料金ページ をご覧ください。 VPN を利用した構成 情報ハイウェイや地域データセンターなどで複数の自治体庁舎からの通信を集約する場合、 Site-to-Site VPN などを利用してネットワークスライシング (物理ネットワークを仮想的に分割すること) を行うことがあります。この場合ネットワークアカウントは複数の団体で共用になりますが、今回は 1 つ目の団体 (団体 A) が負担する料金についてまとめました。 ※一般的に Site-to-Site VPN はインターネット経由で用いるため、Direct Connect が必ずしも必要ではない点にご注意ください。今回 Direct Connect 経由で Site-to-Site VPN を利用しているのは、現行の自治体システムでは基本的に閉域を採用しているためです。 ネットワークアカウントでは以下の課金が発生します。 AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます) AWSと外部: Site-to-Site VPN の料金 0.048USD/時間 AWSと外部: Site-to-Site VPN を経由して AWS 外部に送信されたデータ量に対して 0.114USD/GB AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway の Private IP VPN アタッチメントに対して 0.07USD/時間 それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 AWSと外部: VPC から Direct Connect を経由して Direct Connect ロケーション方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間 AWS内: Transit Gateway アタッチメントから Transit Gateway に送信されたデータ量に対して 0.02USD/GB ここにあげた AWS の費用以外にも自治体庁舎側の回線費用などが発生する場合があります。 また、Direct Connect の通信経路は要件によって冗長化する必要が生じます。この場合、Direct Connect のコストが大きくなりますので、合わせてご確認ください。Direct Connect の冗長化については、AWS Black Belt Online Seminar AWS Direct Connect の 資料 をご覧ください。 ガバナンス・セキュリティ費用の見積もり ガバメントクラウドにおいて必須適用テンプレートによって自動適用されるガバナンスやセキュリティのサービスには、以下のようなものがあります。 AWS CloudTrail AWS を操作した際の証跡ログを半永久的に保存可能です。 データ処理やデータ保持に料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Config AWS リソースの構成変更記録、構成変更を管理します。リソースの設定や関係に変更があった際に配信される設定項目の数や、AWS Config ルールなど、評価の数に対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 Amazon GuardDuty 脅威の検知と継続的監視を行います。分析した CloudTrail イベント件数やログのデータ量などに対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Security Hub 組織内のさまざまなセキュリティデータを集約して、一元的に可視化したり優先順位づけします。実行されたセキュリティチェックの件数や他サービスからの検出結果の取り込み件数などに対して料金がかかります。詳細な料金体系については 料金ページ をご覧ください。 AWS Trusted Advisor お客様が AWS のベストプラクティスに準拠するための推奨事項を提供します。こちらはガバメントクラウドで加入しているサポートプラン (後述) に含まれております。 バックアップ費用の見積もり 地方公共団体情報システム非機能要件の標準 では、大規模災害が発生した際の標準的な復旧目標時間は「 1 か月以内に再開」とされています。これを満たしコストを抑えられる災害対策の手法として、セカンダリリージョン (東京リージョンを常時稼働させるリージョン (プライマリリージョン) とする場合は大阪リージョン) にバックアップを保持しておき、災害時はプライマリリージョンが復旧してから、データをセカンダリリージョンのバックアップから復元し、システムの稼働を再開するという手法が考えられます。 バックアップ戦略も含め、AWS でのディザスタリカバリ (DR) アーキテクチャとクラウドでのリカバリ戦略については、 こちらのブログ をご覧ください。どのようなDR戦略を取るかによって費用は変わってきますが、以下では一例としてバックアップ＆リストア方式を採用する場合の費用の計算方法について記載します。 バックアップ & リストア方式を採用する場合 自治体でよく用いられるバックアップ&リストア方式について、主にかかる費用としては以下のようになります。 東京リージョンにおいて追加でかかる費用 EC2 と EBS のバックアップストレージ料金：大阪リージョンにコピーする EC2 と EBS のスナップショット (AMI) を取得しますが、それを保存する容量に対して料金がかかります。 0.05USD/ 月GB です。 データベースのバックアップストレージ料金：大阪リージョンにコピーするデータベースのスナップショットを取得しますが、それを保存する容量に対して料金がかかります。ただし、料金がかからない場合もあります。例えば Amazon RDS for MySQL の場合は、データベースストレージの容量と同じ分だけ無料でバックアップに利用できます。 東京リージョンから大阪リージョンへの データ転送料 USD 0.09/ GB がかかります。 大阪リージョンにおいて追加でかかる費用 EC2 と EBS のバックアップストレージ料金：東京リージョンからコピーしてきたスナップショットを保存する容量に対して USD 0.05/ 月GB の料金がかかります。 データベースのバックアップストレージ料金：東京リージョンからコピーしてきたデータベースのスナップショットを保存する容量に対して料金がかかります。例えば、Amazon RDS for MySQL の場合は USD 0.095/ 月GiB です。 料金試算例については、こちらの資料もご覧ください。 東京と大阪リージョンを活用して、バックアップ＆リストア戦略で災害対策 ( DR ) を実現する AWS Pricing Calculator への入力 AWS Pricing Calculator で見積もりを作成する際の入力方法のヒントをご紹介します。 以下のヒントは、すべての項目について列挙しているわけではなく、迷うことが多いポイントについて整理したものですので、ご注意ください。 こちらの構成をもとに入力のヒントを作成しております。 EC2 関連費用の入力 リージョンを選択します。 テナンシー：通常、「共有インスタンス」を選択します。 ワークロード：通常、「一定の使用量」を選択します。 インスタンスタイプ：このブログの「コンピューティング費用の見積もり」の章を参考にして決定したインスタンスタイプを選択します。表示される表は、デフォルトではオンデマンド利用料が低い順に並んでいます。 お支払いオプション：「使用状況」は常に起動させるサーバーでは 「 100 Utilization percent per month」 を選択します。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。 「Amazon Elastic Block Store (EBS) – オプション」の章では、Amazon EBSの章を読んでいただき、 EBS の詳細についてご記入ください。以下の説明は gp3 インスタンスを選択された場合のものです。 IOPS は、3,000 IOPS までは無料、それ以上は追加料金がかかります。 スループットは、125 MiB/ 秒までは無料、それ以上は追加料金がかかります。 スナップショット頻度を選択すると、スナップショットあたりの増分を入力できます。これは一般的には EBS 自体の容量よりも小さい値です。 RDS 関連費用の入力 リージョンを選択します。 ガバメントクラウドでは通常、「使用状況」は常に起動させるデータベースでは「 100 %Utilized/Month」を選択します。 デプロイオプションは可用性などの要件に合わせてご選択ください。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。 RDS プロキシを利用する必要があるかどうかは、 こちらのページ をご覧ください。 インスタンスタイプやストレージ量は、このブログの「コンピューティング費用の見積もり」の章を参考にして決定したものを選択します。 バックアップストレージは、保持したいバックアップの容量を入力してください。ただし、インスタンスのストレージ量と同じ容量が無料で提供されるので、追加分を入力してください。 ネットワーク費用の入力 AWS Transit Gateway の費用は、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。 リージョンを選択します。 Transit Gateway のアタッチメント数は、 Direct Connect や VPC、VPN など Transit Gateway と接続するものすべての個数です。例えば冒頭の図の構成の場合 2 個になります。 「Transit Gateway のアタッチメントごとに処理されたデータ」は、アタッチメントごとに Transit Gateway に送信するデータ量の推定値を入力してください。 AWS PrivateLink をご利用になる場合の費用も、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。 AWS Direct Connect のポート料金や、AWS Direct Connect 経由で AWS の外に出る通信量にかかる費用については、AWS Direct Connect のサービスを選択した画面から入力してください。 リージョンを選択します。 「サービスの設定」に関わるポート数などの値は、ネットワーク構築運用補助者にご質問ください。 「データ転送 (送信)」に、AWS Direct Connect 経由で AWS の外に出る通信量をご入力ください。 ガバナンス・セキュリティ費用の入力 高額になりやすい費用として、Amazon CloudWatch の費用がございますので、そちらについて目安をご紹介いたします。 EC2 インスタンスが EC2 詳細モニタリングで 12 個の追加メトリクスを公開する場合、そのインスタンスでは最高価格階層で月額最大 3.60 USD、最低価格階層で月額最大 0.24 USD の料金が発生します。詳しくは、 こちら をご覧ください。 バックアップ費用の入力 東京リージョンから大阪リージョンへのデータ転送量については、「AWS Data Transfer」のメニューのうち送信データ転送から、「その他すべてのリージョン」を選択し、量を入力ください。 コスト削減のヒント 一般的には以下のような方法で、コストを削減できます。ぜひ参考にしていただいて、ガバメントクラウドの費用削減にお役立てください。 ダウンサイジング インスタンスタイプを小さいサイズに変更すると、大きな費用削減効果が得られます。大きいインスタンスサイズが適用されている場合は、現行のシステムの CPU 使用率やメモリ使用率などを鑑みて、より小さいインスタンスサイズが適用できないかをご検討いただくことをお勧めします。また、AWS ではアセスメントを支援する無償のプログラムがありますので、ぜひアカウント営業経由でお声掛けください。 見積もりからは離れますが、運用中に AWS Cost Explorer の「 サイズの適正化に関する推奨事項 」や Performance Insights で低使用率のインスタンスを確認し、インスタンスタイプを小さいサイズに変更できます。 リザーブドインスタンス等の割引オプションの利用 Amazon EC2 では、リザーブドインスタンスなどの割引オプションを適用することで、割引を得ることができます。現状、ガバメントクラウドでも、条件を満たせばリザーブドインスタンスなどの割引オプションを利用することができます。ガバメントクラウドにおける割引オプションの詳しい条件については、デジタル庁にご確認ください。 最新世代インスタンス利用 / コスト効率の良いCPUへ変更 冒頭でご説明したように、EC2 や RDS のインスタンスタイプに書かれている数字が大きいインスタンスの方が最新世代のインスタンスであり、コスト効率が高いです。言い換えると、同料金の場合でもスペックが向上するため、新しい世代を使えばインスタンスタイプを小さくできる可能性があります。 また、AWS Graviton プロセッサはクラウドワークロードに最高のコストパフォーマンスを提供するように設計されたプロセッサであり、移行することでコストパフォーマンスも向上する場合がございます。 AWS Graviton プロセッサへの移行の際に気をつける点については こちらのページ をご覧ください。 最新世代ストレージタイプ利用 インスタンスの世代と同様に、ストレージの世代も最新のものを利用した方がコストパフォーマンスが高いです。具体的には、gp2 ではなく gp3 を利用した方が良いでしょう。 開発環境を不使用時は停止する運用への変更 以下の 3 つの方法で、 EC2 の停止と起動をスケジューリングできます。 Amazon EventBridge スケジューラ と AWS Lambda : シンプルな実装方法にしたい場合はこちらが選択できます。 AWS Systems Manager Resource Scheduler : 既に　AWS Systems Manager (SSM) をご利用の場合は、こちらの方法を使うことで SSM での管理に統一できます。ただし、提供された機能を利用するため少しカスタマイズはしにくくなっています。 AWS Instance Scheduler : 複数のサービスを利用したソリューションです。複数のアカウントのインスタンスを管理できます。 また、負荷に時間や季節による変化があるようなシステムの場合、負荷に合わせて EC2 の台数を増減させたりインスタンスサイズを変化させたりすることで、負荷が小さい期間のコストを抑えることができます。合わせてご確認ください。 低コストのストレージクラスの利用 オブジェクトストレージである Amazon S3 では、スタンダードクラスのみでなく、アクセス頻度が少ない場合に費用削減効果を発揮する S3 Standard-Infrequent Access クラスや、アーカイブ保存用の S3 Glacier Deep Archive などがあります。保存するオブジェクトへのアクセス頻度を元に、最適なストレージクラスを選択されることをお勧めします。 増分バックアップの考慮 見積もり上でリージョン間転送料が多い場合、フルバックアップの想定で計算されていることがあります。実際には AWS Backup の機能などを用いることによって、フルバックアップではなく増分バックアップにすることができ、データ転送量を抑えることができる場合があります。 まとめ 本ブログでは、ガバメントクラウド上のシステムに関する見積もりで注意すべき点についてお伝えしました。 費用の大部分を占めるであろうコンピューティング費用の見積もりを中心に、見積もりに役立てていただけると幸いです。 自治体に所属している方または関連するベンダーの方で、このブログに関してご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した見積もりに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

はじめに コンタクトセンターのエージェントは、顧客対応時に様々な課題に直面します。技術的な問題のトラブルシューティング、請求に関する交渉の解決、または単に役立つ正確な情報を提供する場合など、幅広いトピックがあり、それらすべてに効果的に対応しなければなりません。これを実現するためには、顧客をサポートするために必要な様々な問題や技術に精通していく、数ヶ月、時には数年の経験が必要となります。 しかし、対応が終わった後も仕事は終わりません。エージェントは、顧客記録の更新、ケースメモの記録、未解決の問題のフォローアップなど、重要なアフターコールワークを完了する必要があります。この管理作業は時間がかかりますが、高い顧客満足度 (CSAT) スコアと運用効率を維持するために不可欠です。複数のチャネルを通じ、増え続ける顧客からの問い合わせに対応するため、エージェントは優れた顧客体験を提供しながら、大量の顧客対応を迅速に処理するプレッシャーにさらされています。この増大する作業量は、燃え尽き症候群、高い離職率、サービスレベルのばらつきにつながる可能性があります。 生成 AI は、顧客サービスのライフサイクル全体で人間のエージェントを補助し、生産性の大幅な向上の機会を提供します。日常的な対応後のタスクを自動化し、エージェントにリアルタイムの情報支援を提供することで、生成 AI はエージェントの力を増幅させる役割として機能し、エージェントがより速く賢く作業できるようにします。このブログ記事では、 Amazon Connect の生成 AI 機能が、顧客対応中と対応後の エージェントの生産性 をどのように向上させるかを探ります。 まず、 Amazon Q in Connect がリアルタイムのエージェント支援の提供、関連するステップバイステップガイドの推奨により、対応中のエージェントをどのようにサポートできるかを見ていきましょう。その後、Amazon Connect Contact Lens がエージェントのアフターコンタクトワークを支援する方法を紹介します。 Amazon Q によるリアルタイムのエージェント支援 Amazon Q in Connect では、生成 AI を使用しエージェントに対して回答やアクションの提案を行い、顧客の質問に対する問題解決を迅速化し、顧客満足度を向上させます。会話分析と自然言語処理 (NLP) を使用することで、Amazon Q in Connect は顧客の問題を自動的に検出し、エージェントが追加情報を必要とする場合には対話型の検索にも対応できます。 Amazon Q in Connect では、現在、ナレッジ記事、Wiki、FAQ から派生したソリューションだけでなく、 関連するステップバイステップガイドも推奨 し、現在のタスクを完了するために必要な適切な手順を提供します。Amazon Connect のステップバイステップガイドは、コンタクトセンターのエージェントが顧客からの問い合わせを迅速かつ効率的に解決するのに役立ちます。これらのカスタマイズ可能なガイドは、業務に合わせたワークフローを提供し、エージェントが顧客の問題に対処するために必要な手順を説明します。コーディング不要、ドラッグアンドドロップでワークフローを構築でき、管理者は注文処理、支払い管理、返品処理などさまざまな顧客対応のためのガイドを設計できます。これらのガイドは、顧客のコンテキストに基づいて動的に適応し、問題に関する関連情報を表示し、エージェントに適切なアクションを案内します。ステップバイステップガイドは、すでに Amazon Connect の エージェントワークスペース で利用可能です。Amazon Q in Connect は、この案内支援を表示し、生成された回答やソリューションと共にガイドを提供します。これにより、新しいエージェントの研修時間を短縮したり、経験豊富なエージェントの生産性を向上させることができます。エージェントは常に次の最適なステップを知ることができ、より迅速で正確な解決につながります。 またステップバイステップガイドをナレッジ記事に関連付けることで、関連する情報を表示でき、エージェントはエージェントワークスペースから離れることなく、質問に答えて問題を迅速に解決するための次のステップを実行できます。コンテキストに応じた情報とベストプラクティスガイドを得られることで、エージェントは問題をより速く処理でき、より一貫性と正確性のある解決策を提供できます。これにより、平均処理時間、最初の問題解決率、顧客満足度スコアなどの重要なメトリクスが改善されます。 では Amazon Q in Connect がエージェントの生産性を向上させる例を見てみましょう。 例: Amazon Q in Connect による顧客との対話支援 エージェントが支払い方法の更新を必要とする顧客と対話しています。顧客が「支払い方法の更新」をリクエストした後、Amazon Q in Connect は、リアルタイムで応答と関連するステップバイステップガイドの推奨を提供し、エージェントをサポートします。このガイドはプロセスを合理化し、エージェントにワークスペース内で顧客の請求情報を更新する正確な手順を示すことで、エージェントは複数のタブやアプリケーションを行き来する必要がなくなります。 このガイドはエージェントの他のアプリケーションと並んで対話型のフローとして提供されるため、文脈を失ったり作業の流れを中断することなく、シームレスに作業を進めることができます。 Amazon Q in Connect では、会話のトピックが変わった際にもエージェントが問題を処理できるよう支援します。例えば、顧客から返品についての電話があった場合、Amazon Q in Connect は当初、一般的な「返品と交換」ガイドを推奨するかもしれません。しかし、エージェントが不具合製品の問題であると特定すると、Amazon Q は特定の「不具合製品の返品」ワークフローを表示します。異なる記事を探す無駄な時間はなくなり、エージェントは正確な手順を画面で確認できます。 顧客対応後、エージェントは返金リクエストを送信する必要があります。エージェントが Amazon Q in Connect にチャットで「返金処理が必要」と質問すると、関連するナレッジベースの情報と承認されたプロセスのフローが表示されます。Amazon Q は自然言語のリクエストを処理し、正確な情報とタスク完了のための手順を返します。 関連する知識を手元で参照できることで、Amazon Q in Connect はエージェントの操作やアプリケーションの切り替えを最小限にし、エージェントが迅速に情報を見つけ、手順に従い、タスクを完了できるようにします。これにより、コンタクトセンターにおける大きな生産性の低下要因の 1 つを解消します。Amazon Q in Connect は、パフォーマンスメトリクスの向上だけでなく、新しいエージェントの研修時間を短縮し、より直感的なデスクトップ体験を提供します。これにより、従業員の満足度が向上し、高コストである離職が減少します。Amazon Q in Connect のような生成 AI 機能を備えることで、コンタクトセンターはナレッジベースを最大限に活用し、エージェントに高速でスマートな顧客サービスを提供する力を与えることができます。 ステップバイステップガイドとナレッジコンテンツの連携 Amazon Q in Connect でステップバイステップガイドを推奨事項とともに表示するためには、まずコンテンツにガイドを関連付ける必要があります。1 つのコンテンツに関連付けられるガイドは 1 つですが、必要に応じて複数のコンテンツに 1 つのガイドを関連付けることができます。管理者は、 Amazon Q in Connect API で利用可能な CreateContentAssociation を使用して、ナレッジコンテンツに関連するガイドを関連付けることができます。この API を使用すると、顧客タスクを効果的に解決するために必要なガイドつきワークフロー、フォーム、および埋め込まれたサードパーティアプリケーションでナレッジコンテンツを拡張することができます。他の Amazon Q in Connect API ( GetContentAssociation 、 ListContentAssociation 、 DeleteContentAssociation ) と組み合わせることで、いつ、どこで、どのように Amazon Q in Connect によるエージェントへの手順の支援を展開するか、完全に制御できます。 Amazon Connect Contact Lens によるアフターコンタクトワークの自動化 生成 AI が支援できるのは、エージェントとの対話中だけではありません。Amazon Connect Contact Lens は、会話分析と品質管理機能を提供し、コンタクトセンターがコンタクトの品質とエージェントのパフォーマンスを監視、測定、継続的に改善することで、よりよい全体的な顧客体験を実現できるようにします。 Contact Lens は、生成 AI によるコンタクト後の要約を提供 します。これは、 長い顧客との対話を、簡潔で一貫性があり前後関係が理解できるコンタクトサマリーに要約するものです。これにより、コールセンターの管理者はエージェントの対応をレビューする際に迅速に洞察を得て、品質とコンプライアンスのレビューに費やす時間を節約、エージェントのパフォーマンス改善の機会をより迅速に特定できるため、顧客体験を改善できます。 これらの要約は、エージェントがアフターコンタクトワーク (ACW) をより効果的に行うのに役立つものとなっています 。コンタクト後の要約を使えば、エージェントは顧客対話ごとに手動でメモを取る必要がなくなります。これは、エラーが発生しやすく、時間もかかるプロセスでした。この機能は、生成 AI の力を活用して、対話が終了するとすぐに前後関係が理解できるコンタクト後の要約を自動的に生成します。数秒で、全体の対話が分析され、主要な議論のポイント、提起された問題、取られたアクション、およびコンタクトからの他の重要なコンテキストを捉えた詳細な要約が、エージェントと管理者に提示されます。生成 AI による要約は、顧客記録にシームレスに添付できる、コンタクトの完全な記録を提供します。これにより、エージェントのワークフローからこの面倒な作業が排除されます。これにより、アフターコンタクトワークが削減され、エージェントは優れた顧客サービスの提供に時間を集中できるようになります。 Amazon Connect Contact Lens では、API、Kinesis Steams、問い合わせコントロールパネル (CCP)、連絡先の詳細ページを介してチャットと音声の要約にアクセスできます。これにより、 Amazon Connect Cases や Salesforce などの他のアプリケーションとのシームレスな統合が可能になり、エージェントは顧客の記録を迅速に更新し、プラットフォーム間でデータの一貫性を確保できます。これらの ACW 要約を活用する様々な方法について説明しましょう。 例: Amazon Connect Contact Lens の要約によるアフターコンタクトワークの効率化 エージェントが顧客との対話を完了した後、次の顧客との対話に移る前に ACW を行う必要があります。これを支援するため、Amazon Connect Contact Lens は CCP で対話の要約を提供しています。現在、音声対話がサポートされており、対話が切断されエージェントが ACW に移行された数秒後に、要約が CCP で利用可能になります。この画面では、完全な書き起こしと主要なハイライトが表示されますが、簡単な参照のために対話の要約が一番上に表示されます。エージェントはこの要約を参照して ACW 活動を完了したり、必要に応じて要約をラップアップのフィールドに直接コピーすることができます。 管理者にとって、コンタクトセンター全体で何が起こっているかを把握することは重要です。コンタクト詳細ページでは、エージェントがコンタクトを終了する前の ACW 中でも、ACW 要約はすぐに利用可能になります。音声とチャットの両チャネルでサポートされており、管理者、許可されたエージェント、または他の Amazon Connect ユーザーが、コンタクトの概要を素早く確認できます。 この要約は、コンタクトセンター内の他の用途でも役立つ可能性があります。Contact Lens の ListRealTimeContactAnalysisSegments (音声) および ListRealTimeContactAnalysisSegmentsV2 (チャット) API を使用すると、対話が終了した数秒後に 生成 AI が対応した会話の要約を返すことができます。 これらの API は、例えば ACW 活動を完了する際に参照するために要約をステップバイステップガイドに含めるなど、エージェント のワークフローに統合することができます。また、この API は、エージェント が使用する他のアプリケーションで ACW タスクを実行するためにも使用できます。 前述の方法に加えて、これらの要約は、コンタクトセンター全体で使用されるその他のアプリケーションの生産性を向上させるためにも使用できます。音声とチャットの両方のチャネルをサポートしている Amazon Kinesis Data Streams に対話の要約の直接 ストリーミング する機能により、コンタクトセンターは有効化されたすべての対話に対して、特に要約コンテンツに基づいて分析ツールやエージェント体験の強化を構築できます。 Amazon Kinesis を AWS Lambda や Amazon Data Firehose などのサービスに直接統合すれば、お客様はこのデータを活用してビジネス上の課題に対処し、Salesforce の顧客関係管理 (CRM) などのアプリケーションやシステムとシームレスに統合できます。この統合により、顧客データが最新の状態で維持され、エージェントの手動操作を必要とせずに様々な接点でアクセス可能になるため、全体的な運用効率と顧客満足度が向上します。 デモ Amazon Q in Connect と Contact Lens が、エージェントの対話をどのように支援するかご覧ください 結論 コンタクトセンターのエージェントは多大な作業負荷と事務的な負担に直面することが多く、それが生産性の妨げとなりエージェントの燃え尽き症候群につながる可能性がありますが、生成 AI の機能はこの課題に対する強力なソリューションを提供します。Amazon Connect では、生成 AI を活用して単調な作業を自動化し、対話中にリアルタイムの支援を提供し、包括的な対話後の要約を生成することで、エージェントがより効率的に業務を行い、より迅速な解決を実現し、全体的な顧客満足度を向上させることができます。状況に応じた知識を手元で参照できるようにし、ワークフローを合理的にすることで、エージェントは最も重要な業務、パーソナライズされた高品質のサービスを提供することに集中できます。企業が顧客体験を重視し続ける中、Amazon Connect の Amazon Q や Amazon Connect Contact Lens などの生成 AI 技術への投資は、生産性の向上、運用コストの削減、そしてより熱心で効果的なスタッフの育成に不可欠となるでしょう。AI の力を活用することで、コンタクトセンターは新たなレベルの効率性を実現し、大規模に優れた顧客体験を提供することができます。 Amazon Q in Connect の開始に役立つリソース インスタンスで Amazon Q in Connect を有効化する方法を学びたいですか ? Amazon Connect 管理者ガイドでは、Connect in Q を有効にする方法と機能の包括的な概要が提供されています。詳細は「 インスタンスで Amazon Q in Connect を有効にする 」をご覧ください。 Amazon Q in Connect を実際に体験したいですか ? この Amazon Q in Connect ワークショップ に従って、Amazon Q を有効化し、ドメインを設定し、コンテンツを接続し、生成 AI による応答とソリューションをエージェントに配信する方法を学びましょう。 ステップバイステップガイドを Amazon Q in Connect のコンテンツと統合したいですか ? Amazon Q in Connect では、コンテンツにビューを関連付けることができます。詳細は「 Amazon Q in Connect をステップバイステップガイドと統合する 」をご覧ください。 Amazon Connect ステップバイステップガイドの開始に役立つリソース Amazon Connect の最初のステップバイステップガイドの構築を開始したいですか ?   ステップバイステップガイドのワークショップ に従って、パーソナライズされた、動的で、コンテキストに応じた体験を提供するために Amazon Connect 属性と連携するサンプルガイドの構築、デプロイ、テストの方法についてさらに学びます。 ステップバイステップガイドを深く掘り下げたいですか ? Amazon Connect 管理者ガイド で、サードパーティのアプリケーションの連携の方法について詳しく学びます。 Amazon Connect Contact Lens の開始に役立つリソース Amazon Connect Contact Lens のハンズオン体験をしたいですか? Amazon Connect Contact Lens ワークショップ に従って、Amazon Connect Contact Lens 内で利用可能な機能のセットアップと探索方法を学びます。 生成 AI が生成する通話後の要約を学びたいですか? Amazon Connect 管理者ガイド で、これらの要約を有効化し、表示し、コンタクトセンターで使用する方法について学びます。 ステップバイステップガイドを深く掘り下げたいですか? Amazon Connect 管理者ガイド で、サードパーティのアプリケーションをオンボーディングする方法について学びます。 筆者紹介 Alex Schrameyer (代名詞 he/him) は、インディアナ州インディアナポリスに拠点を置く AWS のエージェントエクスペリエンス担当ワールドワイドソリューションアーキテクトリードです。卓越したエージェント体験こそが優れたカスタマーサービスの基礎であると考え、エージェントが優れた能力を発揮し、お客様に喜んでもらえる環境を作ることに重点を置いています。アレックスは世界中を旅するのが好きで、あなたの地元の野球場やテーマパークでも見かけるかもしれません。 TP Kohli は、AI/ML アプリケーションの構築、管理、およびスケーリングに注力するシニアプロダクトマネージャーです。彼は現在、生成 AI を使用して、コンタクトセンター顧客に最高の対話分析機能と品質管理機能を Amazon Connect で提供する責任者です。TP は、顧客のユースケースを解決すること、顧客の信頼を得ること、コンタクトセンターの顧客が対応の品質とエージェントのパフォーマンスを監視、測定、継続的に改善し、より良い全体的なエンドカスタマーエクスペリエンスを提供できるよう、最高のユーザーエクスペリエンスを提供することを愛しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。