注記: お客様は自身の GitHub ランナーを管理する必要がなくなりました。AWS CodeBuild を使用すると、管理された GitHub Actions セルフホストランナーを利用できるようになり、強力なセキュリティ境界と低い起動レイテンシーを備えた一時的でスケーラブルなランナー環境を提供します。CodeBuild を使えば、独自のインフラストラクチャを維持したり、スケーリングロジックを構築する必要がありません。すべてが CodeBuild によって完全に管理されます。開始するには、単に Webhook を作成して、 CodeBuild で GitHub Actions ジョブ を自動的にトリガーするだけです。 概要 GitHub Actions は、ワークロードのビルド、テスト、デプロイ活動を自動化できる継続的インテグレーションおよび継続的デプロイプラットフォームです。 GitHub セルフホステッドランナー は、GitHub Actions パイプラインを実行するための柔軟でカスタマイズ可能なオプションを提供します。これらのランナーを使用すると、独自のインフラストラクチャ上でビルドを実行でき、コードのビルド、テスト、デプロイ環境を制御できます。これにより、セキュリティリスクとコストを削減し、GitHub ホステッドランナーでは利用できない特定のツールやテクノロジーを使用できるようになります。このブログでは、AWS 環境に GitHub セルフホステッドランナーをデプロイする際に考慮すべきセキュリティ、パフォーマンス、コストのベストプラクティスを探ります。 ベストプラクティス あなたのセキュリティにおける責任を理解する GitHub のセルフホステッドランナーは、設計上、ワークフロースクリプトやリポジトリのビルドプロセスを通じて、 GitHub リポジトリ内で定義されたコードを実行します。 AWS ランナー実行環境のセキュリティは、 GitHub の実装のセキュリティに依存することを理解する必要があります。 GitHub のセキュリティの完全な概要は本ブログの範囲外ですが、 GitHub の環境を AWS の環境と統合する前に、少なくとも以下の GitHub のセキュリティ設定を確認し、理解することをお勧めします。 GitHub のユーザーを連携し、ディレクトリを通じてアイデンティティのライフサイクルを管理します。 GitHub リポジトリの管理特権を制限し、権限を管理できるユーザー、リポジトリへの書き込み、リポジトリ設定の変更、GitHub アプリのインストールを制限します。 セルフホステッドランナーの登録と、グループ設定への制御を制限します。 GitHub ワークフローへの制御を制限し、 サードパーティのアクションを使用する際は GitHub の推奨事項に従います 。 パブリックリポジトリからセルフホステッドランナーへのアクセスを許可しません。 一時的なAWS 認証情報を使用してセキュリティリスクを軽減する できるだけ一時的な認証情報を使用してください 。デフォルトで1時間以内に期限切れになり、ローテーションさせたり明示的に取り消す必要はありません。一時的な認証情報は、 AWS Security Token Service (STS) によって作成されます。フェデレーションを使用してAWSアカウントにアクセスする場合、 assume role 、または Amazon EC2 インスタンスプロファイルや Amazon ECS タスクロールを使用する場合は、すでに STS を使用しています。 ほとんどの場合、 AWS で「実行」されないサービスでも、一時的でない AWS Identity and Access Management (IAM) 認証情報 (アクセスキー) は必要ありません。 AWS の外部のワークロードに IAM ロールを拡張でき、長期的な認証情報を管理する必要がなくなります。 GitHub Actions では、 OpenID Connect (OIDC) を使用することをお勧めします。 OIDC は分散型認証プロトコルで、 sts:AssumeRoleWithWebIdentity を使って STS によってネイティブにサポートされています。 GitHub やその他の多くのプロバイダーもサポートしています。 OIDC を使えば、個々の GitHub リポジトリとそれらの対応するアクションに最小特権の IAM ロールを作成できます。 GitHub Actions はこの目的で利用できる OIDC プロバイダーを各アクションの実行に公開 しています。 一時的な AWS 認証情報と GitHub セルフホステッドランナー 個別にロールを付与したいリポジトリが多数ある場合、単一のアカウントでの IAM ロールの数に制限に達する可能性があります。私は マルチアカウント戦略でこの問題を解決 することを提案しますが、かわりに以下に挙げるアプローチで拡張することもできます: 属性ベースのアクセス制御 (ABAC) を使用して、GitHub トークン内の要求 (リポジトリ名、ブランチ、またはチームなど) を AWS リソースタグと照合する。 GitHub のリポジトリをチームまたはアプリケーションに論理的にグループ化することで、役割のサブセットを少なくするための役割ベースのアクセス制御 (RBAC) を使用します。 GitHub ワークフローに提供されたIDに基づいて、 ID ブローカーパターン を使用して認証情報を動的に提供します。 エフェメラルランナーを使用する GitHub Action のランナーを「エフェメラル」モードで実行するように設定します。これによりジョブごとに要求に応じて個別の一時的な実行環境が作成 (および破棄) されます。この短い環境の存続期間とビルドごとの分離により、マルチテナントの継続的インテグレーション環境であっても基盤となるホストで各ビルドジョブが他のジョブから分離されているため、データ漏洩のリスクが軽減されます。 ジョブごとに新しい環境がオンデマンドで作成されるためアイドル状態のランナーを待つ必要がなく、auto-scalingが簡単になります。オンデマンドでランナーをスケーリングできるため、ビルドインフラストラクチャを不要な時 (例えば営業時間外) に停止する必要がなくコスト効率の良い設定が可能です。さらに最適化するには、開発者がワークフローにインスタンスタイプタグを付けて、それぞれのワークフローに最適なインスタンスタイプを起動できるようにすることを検討してください。 エフェメラルランナーを使用する際には、いくつかの考慮事項があります: ジョブはランナー EC2 インスタンスが起動し、準備が整うまでキューに残されます。これには最大 2 分かかる場合があります。このプロセスを高速化するには、前提条件がすべてインストールされた最適化された AMI を使用することをご検討ください。 各ジョブが新しいランナーで起動されるため、ランナーでキャッシングを利用することはできません。例えば、 Docker イメージやライブラリは常にソースから取得されます。 ランナーグループを使用しセキュリティ要件に基づいてランナーを分離する 単一の GitHub ランナーグループでエフェメラルランナーを使用すると、そのランナーグループを共有するすべてのリポジトリで使用される同じ AWS アカウントのリソースプールを作成することになります。組織のセキュリティ要件により、実行環境をリポジトリごとやデプロイ環境 (開発、テスト、本番など) ごとにさらに分離する必要がある場合があります。 ランナーグループを使うと、リポジトリごとにワークフローを実行するランナーを定義できます。複数のランナーグループを作成すると、さまざまな種類のコンピューティング環境を提供できるだけでなく、ワークフローの実行を相互に分離された AWS の場所に配置できます。たとえば開発ワークフローを1つのランナーグループに、テストワークフローを別のランナーグループに配置することができ、それぞれのエフェメラルランナーグループは別の AWS アカウントにデプロイされます。 ランナーとは、 GitHub ユーザーに代わってコードを実行するものです。 最低限、エフェメラルランナーグループを AWS アカウントに含め、この AWS アカウントの組織の他のリソースへのアクセスを最小限に抑えることをお勧めします。 組織のリソースへのアクセスが必要な場合は、 OIDC による IAM ロールの引き受けを通じて、リポジトリごとに付与できます。そしてこれらのロールには、必要なリソースに対する最小特権アクセスのみを与えることができます。 Amazon EC2 ウォームプールを使用してランナーの起動時間を最適化する エフェメラルランナーは、強力なビルド分離、シンプルさ、セキュリティを提供します。ランナーは必要に応じて起動されるため、ジョブはランナーの起動と GitHub への登録を待つ必要があります。通常 2 分以内に行われますが、この待ち時間はある状況では許容できない可能性があります。 事前に登録されたエフェメラルランナーのウォームプールを使用すると、待ち時間を短縮できます。これらのランナーは、 GitHub ワークフローイベントの受信を積極的に待ち受け、ワークフローイベントが発生するとすぐに、登録済みの EC2 ランナーのウォームプールでピックアップされます。 ウォームプールを管理するための複数の戦略がありますが、 AWS Lambda を使ってエフェメラルランナーをスケールアップ・ダウンする以下の戦略をお勧めします: GitHub セルフホステッドランナーのウォームプールの流れ GitHub ワークフローイベントは、マスターリポジトリへのコードのプッシュやプルリクエストのマージなどのトリガーで作成されます。このイベントは、Webhook と Amazon API Gateway エンドポイントを介して Lambda 関数をトリガーします。Lambda 関数は、GitHub ワークフローイベントペイロードの検証とオブザーバビリティ用のイベントログ、メトリクスの構築に役立ちます。オプションで、ウォームプールの補充にも使用できます。ウォームプールの EC2 インスタンスを起動、スケールアップ、スケールダウンするための別の バックエンド Lambda 関数があります。EC2 インスタンス (ランナー) は起動時に GitHub に登録されます。登録されたランナーは、GitHub の内部ジョブキューを使って着信の GitHub ワークフローイベントをリッスンし、ワークフローイベントがトリガーされるとすぐに、ウォームプールの 1 つのランナーにジョブの実行が割り当てられます。ジョブが完了すると、ランナーは自動的に登録解除されます。ジョブは、GitHub ワークフローで定義されたビルドやデプロイリクエストです。 ウォームプールを導入することで、待ち時間が 70〜80% 短縮されることが期待されます。 考慮事項 ランナーのオーバープロビジョニングの可能性があるため、複雑さが増します。これは、ランナーの EC2 インスタンスが起動して準備完了状態に達するまでの時間と、スケールアップ Lambda が実行される頻度に依存します。例えば、スケールアップ Lambda が 1 分ごとに実行され、 EC2 ランナーの起動に 2 分かかる場合、スケールアップLambdaは 2 つのインスタンスを起動します。これを軽減するには、 Auto Scaling グループを使用して EC2 ウォームプールと所望の容量を管理し、 GitHub ワークフローイベント(ビルドジョブリクエストなど)に基づく予測スケーリングポリシーを関連付けます。 この戦略は、Windows または Mac ベースのランナーをサポートする場合、起動時間が変わる可能性があるため、修正する必要があるかもしれません。 GitHub セルフホステッドランナーの起動を高速化するために最適化された AMI を使用する Amazon Machine Images (AMI) は、ランナーの EC2 インスタンスを起動するために使用できる、事前構成され最適化されたマシンイメージを提供します。AMI を使用することで、依存関係とツールがすでにインストールされているため、新しいランナーの起動時間を短縮できます。すべてのインスタンスが同じバージョンの依存関係とツールを実行するため、ビルド間の一貫性が保証されます。マシンイメージはランナーインスタンスとして使用される前にテストおよび承認されるため、ランナーは安定性と セキュリティコンプライアンスの向上の恩恵を受けることができます。 GitHub のセルフホステッドランナーとして使用する AMI を構築する際には、以下の点に留意する必要があります: ビルドに適切な OS ベースイメージを選択します。これはご利用されている技術スタックとツールセットに依存します。 イメージの一部として GitHub ランナーアプリをインストールします。ランナーの管理オーバーヘッドを減らすために、自動ランナー更新を有効にしてください。特定のランナーバージョンを使用する必要がある場合は、テストされていない変更を回避するために ランナーの自動更新を無効 にすることができます。無効にした場合、新しいバージョンが利用可能になった後 30 日以内にランナーを手動で更新する必要があることに注意してください。 信頼できるソースからビルドツールと依存関係をインストールします。 ランナーログがキャプチャされ、選択した SIEM (Security Information and Event Management )に転送されることを確認します。 ランナーには GitHub にアクセスするためのインターネット接続が必要です。これには、ネットワーク設定に応じてインスタンスでプロキシ設定を構成する必要がある場合があります。 ランナーが必要とするあらゆるアーティファクトリポジトリを構成します。これにはソースと認証が含まれます。 EC2 Image Builder などのツールを使用して、AMI の作成を自動化し、一貫性を実現します。 スポットインスタンスを利用してコストを削減する ランナーのスケーリングアップおよびホットプールの維持に関連するコストは、オンデマンド価格と比較して最大 90% の節約につながる スポットインスタンス を使用することで最小限に抑えることができます。ただし、 2 分間の通知でスポットインスタンスが終了することを許容できない、長時間実行されるビルドやバッチジョブが必要となる場合があります。そのため、そのようなジョブはオンデマンド EC2 インスタンスにルーティングし、その他のジョブはスポットインスタンスで処理するという、インスタンスの混合プールを持つことが適切なオプションとなります。これは、ランナーの起動 / 登録時に ラベルを割り当てる ことで実現できます。その場合オンデマンドインスタンスが起動され、コスト削減のために Savings Plans を適用することができます。 Amazon CloudWatch を使用して、監視のためのランナーメトリクスを記録する EC2 ベースの GitHub セルフホステッドランナーのメトリクスを生成することは、全体的なプラットフォームの可観測性にとって非常に重要です。GitHub ランナーのメトリクスの例としては、1 分間に待機中または完了した GitHub ワークフロー イベントの数、ウォームプールで起動して利用可能な EC2 ランナーの数などがあります。 トリガーされたワークフローイベントとランナーログを Amazon CloudWatch に記録し、 CloudWatch の組み込みメトリクス を使用して、キューイングされたワークフローイベント数、進行中のイベント数、完了したイベント数などのメトリクスを収集できます。ワークフローイベントペイロードの一部である “started_at” と “completed_at” のタイミング要素を使用すると、ビルド待ち時間を計算できます。 例として、以下は Amazon Cloud Watch Logs に記録された GitHub ワークフローイベントのサンプルです。 { "hostname": "xxx.xxx.xxx.xxx", "requestId": "aafddsd55-fgcf555", "date": "2022-10-11T05:50:35.816Z", "logLevel": "info", "logLevelId": 3, "filePath": "index.js", "fullFilePath": "/var/task/index.js", "fileName": "index.js", "lineNumber": 83889, "columnNumber": 12, "isConstructor": false, "functionName": "handle", "argumentsArray": [ "Processing Github event", "{\"event\":\"workflow_job\",\"repository\":\"testorg-poc/github-actions-test-repo\",\"action\":\"queued\",\"name\":\"jobname-buildanddeploy\",\"status\":\"queued\",\"started_at\":\"2022-10-11T05:50:33Z\",\"completed_at\":null,\"conclusion\":null}" ] } 上記のログから \”status\”:\”queued\”,\”repository\”:\”testorg-poc/github-actions-test-repo\c, \”name\”:\”jobname-buildanddeploy\” ,and workflow \”event\” の要素を取り込んでメトリクスを使用するには、選択した言語に基づいた CloudWatch メトリクスクライアントライブラリを使用して、アプリケーションコードまたは メトリクスを送信するための Lambda を利用して埋め込みメトリクスを構築できます。( クライアントライブラリを使用した埋め込みメトリクス形式でのログの作成 ) 原則それらのライブラリの 1 つが内部で行うのは、ログイベントから要素をディメンションフィールドにマップすることで、CloudWatch がそれを読み取りメトリクスを生成することができるようになります。 console.log( JSON.stringify({ message: '[Embedded Metric]', // Identifier for metric logs in CW logs build_event_metric: 1, // Metric Name and value status: `${status}`, // Dimension name and value eventName: `${eventName}`, repository: `${repository}`, name: `${name}`, _aws: { Timestamp: Date.now(), CloudWatchMetrics: [{ Namespace: `demo_2`, Dimensions: [ ['status', 'eventName', 'repository', 'name'] ], Metrics: [{ Name: 'build_event_metric', Unit: 'Count', }, ], }, ], }, }) ); サンプルアーキテクチャー GitHub Webhook イベントの処理 CloudWatchメトリクスは、要件に基づいてダッシュボードに公開したり、外部ツールに転送したりできます。メトリクスを取得できれば、CloudWatchアラームと通知を構成して、プールの枯渇を管理できます。 まとめ このブログ記事では、AWS の EC2 セルフホステッドランナーを使用する際のセキュリティ、スケーラビリティ、コスト効率性に関するベストプラクティスをいくつか説明しました。一時的な認証情報とエフェメラルランナーを組み合わせることで、セキュリティとビルド汚染のリスクを軽減できることを説明しました。また、AMI と EC2 ウォームプールを使用することで、ランナーの起動とジョブ実行を高速化できることも示しました。最後に、適切なシナリオでランナーにスポットインスタンスを使用することで、コスト効率を最大化できることを説明しました。 リソース: Use IAM roles to connect GitHub Actions to actions in AWS Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2 Creating logs in embedded metric format using the client libraries – Amazon CloudWatch GitHub – awslabs/aws-embedded-metrics-node: Amazon CloudWatch Embedded Metric Format Client Library GitHub – philips-labs/terraform-aws-github-runner: Terraform module for scalable GitHub action runners on AWS 本ブログはソリューションアーキテクトの紙谷が翻訳しました。原文は こちら です。

予想されていたとおり、 AWS Summit ニューヨーク では、たくさんのエキサイティングなリリースやアップデートが発表されました。 AWS Summit ニューヨーク 2024 年注目の発表 のハイライトをご覧ください。 私の同僚で、AWS ニュースブログのライター仲間でもある Veliswa Boya と Sébastien Stormacq は、先週 AWS Community Day カメルーン に出席しました。クラウドテクノロジーについて積極的に学び、意見交換を楽しむ素晴らしい専門家、メンター、学生と出会い、素敵な時間を過ごしたとのことです。 動画再生にアクセス すると、その場の雰囲気を感じ、講演の一部を視聴することができます。 7月8日週のリリース ニューヨーク Summit でのリリースに加えて、私が注目したものをいくつかご紹介します。 Amazon Bedrock の高度な RAG 機能ナレッジベース – これには、お客様が独自のチャンキングコードを Lambda 関数として記述できるようにするカスタムチャンキングオプション、テーブルなどの複雑なデータから情報を抽出するスマート解析、クエリをより単純なサブクエリに分割して、それぞれに関連する情報を取得し、その結果を最終的な包括的な回答にまとめるクエリ再定式化が含まれます。 Amazon Bedrock Prompt Management と Prompt Flows – 開発者とプロンプトエンジニアが各々のユースケースについて基盤モデルから最適なレスポンスを得るのに役立つ、Prompt Management のプレビュー版です。Prompt Flows では、直感的なビジュアルビルダーを使用して、ワークフローの作成、テスト、デプロイを加速できます。 Amazon Bedrock での Anthropic の Claude 3 Haiku の微調整 (プレビュー) – 独自のタスク固有のトレーニングデータセットを提供して、 Claude 3 Haiku を微調整およびカスタマイズし、モデルの精度、品質、一貫性を高め、生成 AI をビジネスに合わせてさらに調整できます。 Amazon Q Developer チャットでの IDE ワークスペースコンテキスト認識 – Q Developer のチャットメッセージに @workspace を追加して、現在 IDE で開いているプロジェクトのコードについて質問できるようになりました。Q Developer は、すべてのコードファイル、構成、プロジェクト構造を自動的に取り込んでインデックスを作成し、IDE 内のアプリケーション全体におよぶ包括的なコンテキストをチャットに提供します。 Amazon Q Business の新機能 – Amazon Q Business の新しいパーソナライゼーション機能 が自動的に有効になります。企業の従業員プロファイルデータを使用して、ユーザーエクスペリエンスを改善できます。OCR を前処理やテキスト抽出に使用することなく、 スキャンした PDF のテキストコンテンツや PDF 文書に埋め込まれた画像から回答を得る ことができるようになりました。 AWS Graviton4 を搭載した Amazon EC2 R8g インスタンスの一般提供 – Amazon EC2 R8g インスタンスは、データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリを大量に消費するワークロードに適しています。これらは AWS Graviton4 プロセッサを搭載しており、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが最大 30% 向上しています。 Amazon MemoryDB のベクトル検索の一般提供 – MemoryDB のベクトル検索により、リアルタイムの機械学習 (ML) と生成 AI アプリケーションが可能になります。1 桁ミリ秒単位のクエリで数百万ものベクトルを保存し、99% 以上のリコール率かつ最高レベルのスループットでレイテンシーを更新できます。 Valkey および Redis オープンソース用のオープンソースクライアントライブラリ、Valkey GLIDE のご紹介 – Valkey は、キャッシュやメッセージキューなどのさまざまなワークロードをサポートする、オープンソースの key-value データストアです。Valkey GLIDE は Valkey の公式クライアントライブラリの 1 つで、すべての Valkey コマンドをサポートしています。GLIDE は Valkey 7.2 以降と Redis オープンソース 6.2、7.0、7.2 をサポートしています。 Amazon OpenSearch Service の強化 – Amazon OpenSearch Serverless は、 時系列収集のワークロードを最大 30 TB までサポートするようになり 、より大量のデータを扱うユースケースが可能になりました。また、データを自動的に取得してスマートに管理する 革新的なキャッシュメカニズム が、データ取得の高速化、ストレージの効率的な使用、コスト削減につながります。 Amazon OpenSearch Service では、 OpenSearch Dashboards Log Explorer に AI を活用した自然言語クエリ生成のサポートが追加 されました。これにより、PPL に習熟していなくても、ログ分析をすぐに開始できます。 Secrets Manager Agent for AWS Secrets Manager のオープンソースリリース – Secrets Manager Agent は、言語にとらわれないローカル HTTP サービスで、コンピューティング環境にインストールして使用すると、Secrets Manager からシークレットを読み取ってメモリにキャッシュすることができます。ネットワーク呼び出しを行う代わりに、Secrets Manager からシークレットを読み取り、メモリにキャッシュできます。 Amazon S3 Express One Zone が AWS CloudTrail のすべてのイベントのログ記録のサポートを開始 – S3 Express One Zone に対して API コールを行ったユーザーと API コールが行われた日時に関する詳細を取得できるため、データの可視性が向上し、ガバナンス、コンプライアンス、運用監査が容易になります。 Amazon CloudFront がウェブアプリケーションのマネージドキャッシュポリシーを発表 – これまで、Amazon CloudFront のお客様にはマネージドキャッシュポリシーにおいて 2 つの選択肢があり、それ以外の場合はカスタムキャッシュポリシーを作成する必要がありました。新しいマネージドキャッシュポリシーでは、CloudFront はオリジンから返された Cache-Control ヘッダーに基づいてコンテンツをキャッシュし、ヘッダーが返されない場合はデフォルトでキャッシュを行いません。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 既存のサービスがさらに多くのリージョンでご利用いただけるようになりました。 Amazon Relational Database Service (Amazon RDS) Data API for Aurora PostgreSQL を、 さらに 10 の AWS リージョンでご利用いただけるようになりました 。 Amazon Managed Workflows for Apache Airflow (MWAA) を さらに 9 つの AWS リージョンでご利用いただけるようになりました 。 Amazon Simple Notification Service (Amazon SNS) のお客様は、 カナダ西部 (カルガリー) リージョンでアプリケーションをホスト し、200 を超える国と地域の消費者にテキストメッセージ (SMS) を送信できるようになりました。 Apache HBase テーブルのバックアップと復元の Amazon EMR サポートは、 アジアパシフィック (ソウル) リージョンでご利用いただけます。 Amazon Cognito が カナダ西部 (カルガリー) および アジアパシフィック (香港) リージョンで利用できるようになりました。 AWS の他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 コンテキストウィンドウのオーバーフロー: 障壁を打ち破る – このブログ記事では、生成人工知能 (AI) モデルの複雑な仕組みについて紹介し、CWO (コンテキストウィンドウオーバーフロー) の制限を理解して軽減することが重要な理由を詳しく説明します 。 Agents for Amazon Bedrock を使用して、インフラストラクチャをコードとしてインタラクティブに生成する – このブログ記事では、 Agents for Amazon Bedrock を使用して、アップロードされたアーキテクチャ図から、組織標準に準拠するカスタマイズされた IaC スクリプトを直接生成する方法について説明します。 AWS Step Functions ワークフローを使用した Amazon Bedrock のモデルカスタマイズの自動化 – このブログ記事では、反復可能かつ自動化されたワークフローのオーケストレーションによる Amazon Bedrock モデルのカスタマイズと、 AWS Step Functions がモデルカスタマイズの主な課題の克服に役立つ方法について説明します。 AWS オープンソースのニュースと更新 – 同僚の Ricardo Sueiras が AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ボゴタ (7 月 18 日)、 台北 (7 月 23～24 日)、 AWS Summit メキシコシティ (8 月 7 日)、 AWS Summit サンパウロ (8 月 15 日)。 AWS Community Days  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催される AWS Community Day は、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 7月15日週はここまでです。7月22日週の Weekly Roundup もお楽しみに! — Abhishek この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

7月10日、 Amazon MemoryDB のベクトル検索 の一般提供についてお知らせします。これは、インメモリパフォーマンスとマルチ AZ 耐久性を備えたリアルタイム機械学習 (ML) および 生成人工知能 (生成 AI) アプリケーションの開発用の新機能で、ベクトルの保存、インデックス作成、取得、検索に使用できます。 今回のリリースにより、Amazon MemoryDB は、Amazon Web Services (AWS) で人気の高いベクトルデータベースの中で、最も高いリコール率での最速のベクトル検索パフォーマンスを実現しました。従来、緊張関係にあったスループット、リコール、レイテンシーのトレードオフを行う必要はもうありません。 1 つの MemoryDB データベースを使用して、アプリケーションデータと数百万のベクトルを保存できるようになりました。最大リコールレベルでのクエリと更新の応答時間は、1 桁ミリ秒です。これにより、生成 AI アプリケーションアーキテクチャを簡素化すると同時に、最高のパフォーマンスを実現し、ライセンスコスト、運用上の負担、データに関する洞察を提供するための時間を削減することができます。 Amazon MemoryDB のベクトル検索では、既存の MemoryDB API を使用して、 検索拡張生成 (RAG) 、異常 (不正) 検出、ドキュメント検索、リアルタイムレコメンデーションエンジンなどの生成 AI ユースケースを実装できます。また、 Amazon Bedrock や Amazon SageMaker などの人工知能や機械学習 (AI/ML) サービスを使用してベクトル埋め込みを生成し、それらを MemoryDB に保存することもできます。 MemoryDB のベクトル検索のメリットが最も大きいユースケースはどれですか? MemoryDB のベクトル検索は、次の特定のユースケースに使用できます。 1.検索拡張生成 (RAG) 用のリアルタイムのセマンティック検索 ベクトル検索を使用すると、大規模なデータコーパスから関連する箇所を取得して、大規模言語モデル (LLM) を拡張できます。これは、ドキュメントコーパスを取り出して個別のテキストバケットにまとめ、 Amazon Titan Multimodal Embeddings G1 モデル などの埋め込みモデルを使用してチャンクごとにベクトル埋め込みを生成し、これらのベクトル埋め込みを Amazon MemoryDB に読み込むことによって行われます。 RAG と MemoryDB を使用すると、リアルタイム生成 AI アプリケーションを構築して、項目をベクトルとして表現することで類似の製品やコンテンツを見つけたり、テキスト文書を意味的な意味を捉えた密度の高いベクトルとして表現してドキュメントを検索したりできます。 2.低レイテンシーかつ高耐久性のセマンティックキャッシュ セマンティックキャッシュは、基盤モデル (FM) の以前の結果をメモリに保存することで計算コストを削減するプロセスです。以前に推論された回答を質問のベクトル表現と一緒に MemoryDB に保存し、LLM から別の回答を推論する代わりに、それらを再利用できます。 ユーザーのクエリが、定義済みの類似性スコアに基づいて前の質問と意味的に類似している場合、MemoryDB は前の質問に対する回答を返します。このユースケースにより、生成 AI アプリケーションが FM に新たなリクエストを行うことで、より低いコストでより迅速に応答できるようになり、顧客により速いユーザーエクスペリエンスを提供できます。 3.リアルタイムの異常 (不正) 検出 ベクトルで表されるトランザクションデータと、それらのトランザクションが不正または有効のどちらとして識別されたかどうかを表すメタデータを保存することで、ベクトル検索を使用して異常 (不正) を検出し、ルールベースの機械学習プロセスやバッチ機械学習プロセスを補完できます。 機械学習プロセスでは、正味の新規取引が不正取引を表すベクトルとの類似度が高い場合に、ユーザーの不正取引を検出できます。MemoryDB のベクトル検索を使用すると、バッチ ML モデルに基づいて不正なトランザクションをモデル化し、通常のトランザクションと不正なトランザクションを MemoryDB にロードして、主成分分析 (PCA) などの統計的分解手法を使用してベクトル表現を生成することで、不正を検出できます。 インバウンドトランザクションがフロントエンドアプリケーションを通過するときに、PCA を介してトランザクションのベクトル表現を生成することで、MemoryDB に対してベクトル検索を実行できます。また、トランザクションが過去に検出された不正トランザクションと非常に似ている場合は、1桁ミリ秒以内にトランザクションを拒否して、不正のリスクを最小限に抑えることができます。 Amazon MemoryDB でのベクトル検索の開始方法 MemoryDB でベクトル検索を使用して、簡単なセマンティック検索アプリケーションを実装する方法を見てみましょう。 ステップ 1.ベクトル検索をサポートするクラスターを作成する MemoryDB クラスターを作成して、 MemoryDB コンソール 内でベクトル検索を有効にすることができます。クラスターを作成または更新するときに、 [Cluster settings] (クラスター設定) で [Enable vector search] (ベクトル検索を有効にする) を選択します。ベクトル検索は、MemoryDB バージョン 7.1 およびシングルシャード構成で使用できます。 ステップ 2.Amazon Titan 埋め込みモデルを使用してベクトル埋め込みを作成する Amazon Titan Text Embeddings やその他の埋め込みモデルを使用してベクトル埋め込みを作成できます。この埋め込みは Amazon Bedrock で利用できます。AWS サービスと統合された LangChain ライブラリ を備えた単一の API を使用して PDF ファイルを読み込んだり、テキストをチャンクに分割したり、ベクトルデータを取得したりできます。 import redis import numpy as np from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import BedrockEmbeddings # Load a PDF file and split document loader = PyPDFLoader(file_path=pdf_path) pages = loader.load_and_split() text_splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", ".", " "], chunk_size=1000, chunk_overlap=200, ) chunks = loader.load_and_split(text_splitter) # Create MemoryDB vector store the chunks and embedding details client = RedisCluster( host=' mycluster.memorydb.us-east-1.amazonaws.com', port=6379, ssl=True, ssl_cert_reqs="none", decode_responses=True, ) embedding = BedrockEmbeddings ( region_name="us-east-1", endpoint_url=" https://bedrock-runtime.us-east-1.amazonaws.com", ) #Save embedding and metadata using hset into your MemoryDB cluster for id, dd in enumerate(chucks*): y = embeddings.embed_documents([dd]) j = np.array(y, dtype=np.float32).tobytes() client.hset(f'oakDoc:{id}', mapping={'embed': j, 'text': chunks[id] } ) Amazon Titan Text Embeddings モデルを使用してベクトル埋め込みを生成したら、MemoryDB クラスターに接続し、MemoryDB HSET コマンドを使用してこれらの埋め込みを保存できます。 ステップ 3.ベクトルインデックスを作成する ベクトルデータをクエリするには、 FT.CREATE コマンドを使用してベクトルインデックスを作成します。ベクトルインデックスも、MemoryDB キースペースのサブセット上でコンストラクトおよび管理されます。ベクトルは JSON または HASH データ型で保存でき、ベクトルデータへの変更はすべてベクトルインデックスのキースペースで自動的に更新されます。 from redis.commands.search.field import TextField, VectorField index = client.ft(idx:testIndex).create_index([ VectorField( "embed", "FLAT", { "TYPE": "FLOAT32", "DIM": 1536, "DISTANCE_METRIC": "COSINE", } ), TextField("text") ] ) MemoryDB では、数値フィールド、タグフィールド、テキストフィールド、ベクトルフィールドの 4 種類のフィールドを使用できます。ベクトルフィールドは、フラット検索 (FLAT) と Hierarchical Navigable Small Worlds (HNSW) アルゴリズムを使用した、固定サイズのベクトルの K-最近傍検索 (KNN) をサポートしています。この機能は、ユークリッド、コサイン、内積などさまざまな距離計量をサポートしています。ここでは、ベクトル空間の 2 点間の角距離の尺度であるユークリッド距離を使用します。ユークリッド距離が小さいほど、ベクトルは互いに近づきます。 ステップ 4.ベクトル空間を検索する FT.SEARCH コマンドと FT.AGGREGATE コマンドを使用してベクトルデータをクエリできます。各演算子は、インデックス内の 1 つのフィールドを使用して、インデックス内のキーのサブセットを識別します。MemoryDB のベクトルフィールドと、事前定義されたしきい値 ( RADIUS ) に基づくクエリベクトルとの間の距離によって、フィルタリングされた結果をクエリして見つけることができます。 from redis.commands.search.query import Query # Query vector data query = ( Query("@vector:[VECTOR_RANGE $radius $vec]=>{$YIELD_DISTANCE_AS: score}") .paging(0, 3) .sort_by("vector score") .return_fields("id", "score") .dialect(2) ) # Find all vectors within 0.8 of the query vector query_params = { "radius": 0.8, "vec": np.random.rand(VECTOR_DIMENSIONS).astype(np.float32).tobytes() } results = client.ft(index).search(query, query_params).docs 例えば、コサイン類似度を使用する場合、 RADIUS 値の範囲は 0～1 で、値が 1 に近いほど、検索中心に近いベクトルが見つかります。 クエリベクトルの 0.8 以内のすべてのベクトルを検出した結果の例を次に示します。 [Document {'id': 'doc:a', 'payload': None, 'score': '0.243115246296'}, Document {'id': 'doc:c', 'payload': None, 'score': '0.24981123209'}, Document {'id': 'doc:b', 'payload': None, 'score': '0.251443207264'}] 詳細については、RAG と MemoryDB をベクトルストアとして使用した 生成 AI アプリケーションのサンプル をご覧ください。 GA での新機能 re: Invent 2023 では、MemoryDB のベクトル検索の プレビュー 版をリリースしました。お客様からのフィードバックに基づいて、現在ご利用いただけるようになった新機能と改善点は次のとおりです。 VECTOR_RANGE により、MemoryDB を低レイテンシーで耐久性のあるセマンティックキャッシュとして動作させることができるようになり、生成 AI アプリケーションのコスト最適化とパフォーマンスの向上が実現します。 SCORE を使用すると、ベクトル検索を行う際の類似度によるフィルタリングが改善されます。 メモリ内のベクトルが重複しないようにするための共有メモリ。ベクトルは MemoryDB キースペース内に格納され、ベクトルへのポインタはベクトルインデックスに格納されます。 高いフィルタリングレートでのパフォーマンスの向上により、最もパフォーマンスが高い生成 AI アプリケーションを実現します。 今すぐご利用いただけます ベクトル検索は、MemoryDB が現在利用可能なすべてのリージョンでご利用いただけます。詳しくは、AWS ドキュメントの Amazon MemoryDB のベクトル検索 をご覧ください。 MemoryDB コンソール をお試しいただけましたら、 AWS re:Post for Amazon MemoryDB または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに 技術の進歩が進む中で、次のイノベーションの重要な要素としてSpatial Computingがあげられます。ゲーム、メディア、製造業や建築業に至るまで様々な業界の企業がSpatial Computingの導入や活用に取り組んでいます。最近のSpatial Computing領域での最も大きなニュースはAppleからVision Proが発売されたことでしょう。Vision Proを利用することでSpatial Computingの世界で、より直感的なインタラクティブかつ没入的な体験をすることが可能になります。 Amazon Web Services（AWS）ではSpatial Computingに関連した施策として NVIDIA Omniverseの活用 や、 Visual Assets Management System(VAMS) などの取り組みがありますが、本記事ではVision Pro向けUnityアプリケーションのビルド方法について解説していきます。 AWSを利用したビルドパイプライン 以前の記事で、UnityモバイルアプリのビルドパイプラインをAWS上に実装する方法を、実際にデプロイできるコードとともに紹介しました: Unityモバイルアプリのビルドパイプラインを実装する 元記事からの再掲にはなりますが、AWSでビルドパイプラインを構築する利点は以下のとおりです: レジリエンス : AWS上のビルドパイプラインは耐障害性が高く、無停止で動き続けることができます。 スケーラビリティ : 開発のフェーズに合わせてキャパシティを柔軟に調整できます。 セキュリティ : AWSでは多くのセキュリティサービスが利用でき、パイプラインに統合することでシステムの信頼性を高め、お客様の制作物を保護します。 Vision Proのアプリケーション開発においても、安定したビルドパイプラインの存在は重要でしょう。iOSアプリビルドの環境はVision Proアプリのビルドにも利用できるため、本記事でも上記記事のパイプライン実装をそのまま利用することができます。 アーキテクチャ あらためて、今回のビルドパイプラインのアーキテクチャをおさらいしましょう。GitHub に本アーキテクチャを実装したサンプルを公開しています: Unity Build Pipeline with Jenkins and EC2 Mac このサンプルには以下が含まれます: ECS Fargate 上の Jenkins マスター EC2 Linux spot インスタンスと EC2 Mac インスタンス上の Jenkins エージェント Linux 上では Docker エージェントも利用可能 EC2 Linux 上 の Unity Accelerator (オプショナル) ビルドキャッシュをスポットインスタンス間で共有する仕組み ( 記事 を参照) AWS CDK による自動化されたデプロイ 上記はご利用の AWS アカウントにデプロイしてすぐに試せるようになっていますので、ぜひご確認ください。 またUnityビルドにおいて必要となることも多い、Unity のフローティングライセンス管理サーバーを AWS 上に構築するIaC実装も合わせて公開しています。こちらも合わせてご確認ください: Unity Build Server with AWS CDK 実際にビルドしてみよう それでは上記のアーキテクチャを利用してVision Proアプリケーションをビルドする手順を簡単に紹介します。 なお、ビルドパイプラインは構築できているものとしますが、構築のための詳細な方法はこちらをご参照ください: ビルドパイプラインのCDKプロジェクトのデプロイ手順 。AWS CDKを利用してデプロイでき、2〜3個のCLIコマンド実行だけでデプロイが完了します。 今回は、ビルド対象のVisionOSプロジェクト例として、こちらを利用します: aws-samples/unity-vision-os-sample-app 上記をローカルに git clone し、Unityでプロジェクトを開くと、以下のようなプロジェクトであることが分かります。 今回のJenkinsパイプラインでは、以下の手順でビルドします: EC2 Linux (spot)上のUnityでUnityプロジェクトからXcodeプロジェクトを生成する 1のプロジェクトをS3にコピー EC2 Mac上に2をコピーし、Xcodeでビルドする まず、1の準備をします。Unityを含むコンテナイメージとして、 game-ci/docker が利用可能です。しかしながら、2024年7月現在において、VisionOS向けのモジュールを含むイメージは Docker Hub に公開されていません。このワークアラウンドとして、自分でイメージをビルドし、Amazon ECRレポジトリにイメージをプッシュすることができます。下記はイメージをビルドするためのコマンド例です: git clone https://github.com/game-ci/docker.git cd docker/images/ubuntu/editor # Unityのversionは適宜変更してください docker build --build-arg="module=visionos" --build-arg="version=2022.3.31f1" --platform linux/amd64 . イメージがビルドできたら、ECRレポジトリにプッシュしましょう。上記のCDKプロジェクト内でレポジトリを作成するため、そのレポジトリにプッシュすることをお勧めします。Jenkinsからイメージを利用するために必要なクレデンシャルも、そのレポジトリ向けにすでに設定されているためです。 また、3のためにEC2 Macをセットアップする必要があります。具体的には、以下の操作です: Xcodeのインストール provisioning profileや証明書の設定 EC2 MacにはVNC経由で接続でき、通常のMac端末と同じGUIで操作することが可能です。EC2 Macインスタンスに接続するための手順は、こちらを参照してください: EC2 Macインスタンスのセットアップ 。provisioning profileなどの設定は会社により方法が異なると思われるため、本手順では割愛します。検証用の手順としては、こちらが参考になるかもしれません: AWS Game tech workshop これで準備ができました。あとはJenkinsのGUIからパイプラインを作成するだけです。サンプルのJenkinsfileは先程のリポジトリに同梱されています: aws-samples/unity-vision-os-sample-app ポイントは以下のとおりです: カスタムのgame-ciコンテナイメージを利用 : 以下のagentブロックで、先ほどビルドしたコンテナイメージを参照しています。 registryCredentialsId や $ECR_REPOSITORY_URL などは、CDKデプロイ時に設定された値です。 agent { docker { label 'linux' image "${ECR_REPOSITORY_URL}:latest" args '-u 0 --entrypoint= ' registryCredentialsId "ecr:${AWS_REGION}:ecr-role" registryUrl "$ECR_REGISTRY_URL" } } UnityのビルドターゲットをVisionOSに設定 : executeMethodによるビルド実行時に、ターゲットをVisionOSに設定しています unity-editor \ -quit \ -batchmode \ -nographics \ -executeMethod ExportTool.ExportXcodeProject \ -projectPath "./" ExportTool.cs XcodeのSDKをVisionOSに設定 : xcodebuildコマンド呼び出し時に -sdk xros オプションを指定します xcodebuild -scheme Unity-VisionOS -sdk xros ... 公開されたリポジトリを使って、下図のように直接Jenkinsパイプラインを試すこともできます: ビルドが完了したら、Jenkinsからアーティファクトをダウンロードして確認することができます。 なお、今回はスケーラビリティやコスト効率のためにEC2 Linux スポットインスタンスを活用していますが、より小規模なワークロードなどでは、EC2 Macのみ使うこともできます。EC2 Mac上にUnityエディタをインストールし、Xcodeプロジェクトの生成からビルドまで完結させる方法です。どの種類のEC2インスタンスをJenkinsエージェントとしてデプロイするかは、 bin/jenkins-unity-build.ts  から設定できますので、そちらもご確認ください。 まとめ この記事では、EC2 MacやEC2 Linuxスポットインスタンスを利用したJenkinsパイプラインを構築し、Vision OSアプリケーションをビルドする方法を紹介しました。本方法により、パイプラインのリジリエンス・スケーラビリティ・セキュリティを高く実現することができます。いくつかの簡単なコマンドを実行するだけで本パイプラインをデプロイできるようになっているので、ぜひお試しください。

AWS では 2024 年 4 月に Amazon Q Business をリリースした際、 Amazon Q Apps のプレビュー版 もリリースしました。 Amazon Q Apps は、組織のデータに基づいて生成人工知能 (生成 AI) を利用したアプリケーションを作成するための、Amazon Q Business 内の機能です。ユーザーは自然言語を使用してアプリを構築し、それを組織のアプリライブラリに安全に公開して、誰もが使用できるようにすることができます。 プレビュー中にフィードバックや提案を収集してきましたが、7月10日、Amazon Q Apps を一般公開しました。Amazon Q Apps の API や、個々のカードレベルでデータソースを指定する機能など、プレビュー中には使用できなかった新機能もいくつか追加しています。 新機能については後ほど詳しく説明しますが、まず Amazon Q Apps の使用を開始する方法を見てみましょう。 会話を再利用可能なアプリに変える Amazon Q Apps では、Amazon Q Business との会話からアプリを生成できます。Amazon Q Apps は会話のコンテキストをスマートにキャプチャして、特定のニーズに合わせたアプリを生成します。実際の動作を見てみましょう。 この記事を書き始めたとき、Amazon Q Business の協力を得て、Amazon Q Apps の製品概要を生成することを考えました。結局のところ、Amazon Q Business は従業員の生産性を高めるために存在しているからです。そこで、製品メッセージドキュメントを Amazon Simple Storage Service (Amazon S3) バケットにアップロードし、 Amazon Q Business 用の Amazon S3 コネクタ を使用して、データソースとして追加しました。 次のプロンプトから会話を始めます。 私は、Amazon Q Apps のリリースに関する記事を書いています。 製品の簡単な説明は次のとおりです。従業員は、幅広い Amazon Q Business アプリケーション環境内で、軽量かつ特定の目的のための Amazon Q Apps を作成できます。 製品の概要と主な機能の一覧表示を生成してください。 会話を開始してみて、製品の説明を記載した製品概要を作成することは、組織内の他のメンバーにとっても役立つことに気付きました。 [Create Amazon Q App] (Amazon Q App を作成) を選択して、再利用および共有可能なアプリを作成します。 Amazon Q Business では、Amazon Q App を作成するプロンプトが自動生成され、必要に応じて確認と編集を促すプロンプトが表示されます。 Q にとって既知の製品/サービスに関するデータを利用して、製品またはサービスの短い説明を取り込み、その製品/サービスの概要と、主要機能の一覧を出力するアプリを構築します。 [Generate] (生成) を選択してアプリの作成を続行します。4 枚のカード (ユーザー入力を取得する 2 枚の入力カードと、製品の概要および主要機能を表示する 2 枚の出力カード) を含む Product Overview Generator アプリを作成します。 カードのサイズを変更したり移動したりすることで、アプリのレイアウトを調整できます。 また、個々のテキスト出力カードのプロンプトが自動的に生成されるので、これらを表示したり編集したりできます。 [Product Overview] (製品概要) カードの編集アイコンを選択すると、サイドパネルにプロンプトが表示されます。 サイドパネルでは、テキスト出力カードのソースを選択し、大規模言語モデル (LLM) の知識または承認されたデータソースのいずれかを使用して、出力を生成することもできます。承認されたデータソースについては、この Amazon Q Business アプリケーション用に設定されているデータソースを 1 つ以上選択できます。このアプリを作成するために設定した マーケティング (Amazon S3) データソースを選択します。 お気付きかもしれませんが、基本プロンプトや個々のテキスト出力カードのプロンプトを変更することなく、会話自体から完全に機能するアプリを生成しました。 [Publish] (公開) を選択すると、このアプリを組織のアプリライブラリに公開できます。しかし、アプリを公開する前に、Amazon Q アプリを作成する別の方法を見てみましょう。 自然言語を使用して生成 AI アプリを作成する Amazon Q Business での会話を起点としてアプリを作成する代わりに、 [Apps] (アプリ) を選択し、作成したいアプリを自分の言葉で説明することができます。または、事前に設定された例のいずれかのプロンプトを試してみることもできます。 目的に合わせてプロンプトを入力し、 [Generate] (生成) を選択してアプリを作成できます。 チームとアプリを共有する レイアウトとプロンプトの両方に満足し、アプリを共有する準備が整ったら、一元化されたアプリライブラリにアプリを公開して、この Amazon Q Business アプリケーション環境のすべてのユーザーがアクセスできるようにします。 Amazon Q Apps は Amazon Q Business の強固なセキュリティとガバナンスコントロールを継承しており、データソース、ユーザー権限、ガードレールを確実に維持します。そのため、他のユーザーがアプリを実行すると、基礎となるデータソースでアクセスできるデータに基づく回答のみが表示されます。 作成した Product Overview Generator アプリでは、 [Publish] (公開) を選択します。アプリのプレビューが表示され、最大 3 つのラベルを選択できます。ラベルは、組織内の部門やその他のカテゴリ別にアプリを分類するのに役立ちます。ラベルを選択したら、プレビューポップアップでもう一度 [Publish] (公開) を選択します。 アプリはすぐに Amazon Q Apps ライブラリで利用可能となり、他のユーザーが使用、コピー、ビルドできるようになります。 [Library] (ライブラリ) を選択して Amazon Q Apps ライブラリを閲覧すると、作成した Product Overview Generator アプリが見つかります。 特定のニーズに合わせてアプリライブラリ内のアプリをカスタマイズする Amazon Q Apps では、共有アプリを特定のニーズに合わせてカスタマイズおよび調整することで、個人またはチームの生産性をすばやく向上できます。ゼロから始める代わりに、既存のアプリを確認したり、そのまま使用したり、アプリを変更して独自のバージョンをアプリライブラリに公開したりできます。 アプリライブラリを閲覧して、カスタマイズするアプリを見つけましょう。 [General] (一般) というラベルを選択して、そのカテゴリのアプリを検索します。 ドキュメントをレビューして文法上の間違いを修正する、 Document Editing Assistant (ドキュメント編集アシスタント) アプリを見つけました。新しいバージョンのアプリを作成して、ドキュメントの概要も含めたいとします。その方法について説明します。 [Open] (開く) を選択するとアプリが開き、 [Customize] (カスタマイズ) オプションが表示されます。 [Customize] (カスタマイズ) を選択すると、アプリのコピーが作成され、変更を加えられるようになります。 アプリタイトルの編集アイコンを選択して、アプリの タイトル と 説明 を更新します。 このアプリの生成に使用された元の アプリプロンプト が表示されます。プロンプトをコピーして、同様のアプリを作成する際の出発点として使用できます。これにより、追加したい機能の説明を含め、Amazon Q Apps Creator に処理を任せることができます。または、このアプリのコピーの変更を続行することもできます。 既存のカードを編集または削除するオプションがあります。例えば、カードの編集アイコンを選択すると、 [Edited Document] (編集済みドキュメント) のテキスト出力 カードのプロンプトを編集できます。 機能をさらに追加するには、ユーザー入力、テキスト出力、ファイルアップロード、または管理者が事前設定したプラグインなどのカードを追加できます。例えば、ファイルアップロードカードを使用して、質問への回答を絞り込んだり、微調整したりするための別のデータソースとしてのファイルを提供できます。プラグインカードを使用すると、フォローアップとして実行する必要のあるアクションアイテムの Jira チケットの作成などを行えます。 [Text output] (テキスト出力) を選択して、ドキュメントを要約する新しいカードを追加します。タイトルを「Document Summary (ドキュメント概要)」とし、次のようなプロンプトを入力します。 @Upload ドキュメントに数行で要点を要約してください これで、このカスタマイズしたアプリを新しいアプリとして公開し、組織内の全員と共有できるようになりました。 プレビュー後の追加機能 前述のとおり、プレビュー期間中にお寄せいただいたフィードバックや提案を基に、新しい機能を追加しました。追加した新機能は次のとおりです。 カードレベルでのデータソースの指定 – アプリ作成時に示したように、出力の生成元となるデータソースを指定できます。応答の精度を向上させるためにこの機能を追加しました。 Amazon Q Business インスタンスでは、複数のデータソースを設定できます。ただし、アプリを作成する際、ユースケースによってはこれらのデータソースのサブセットのみが必要となる場合があります。この機能によって、アプリ内のテキスト出力カードごとに特定のデータソースを選択できるようになりました。また、必要に応じて、データソースを使用する代わりに LLM ナレッジを使用するようにテキスト出力カードを設定できます。 Amazon Q Apps API – アプリ、アプリライブラリ、アプリセッションを管理するための API を使用して、Amazon Q Apps をプログラムで作成および管理できるようになりました。これにより、Amazon Q Apps のすべての機能を、お好みのツールやアプリケーションに統合できます。 留意点 リージョン – Amazon Q アプリは現在、Amazon Q Business が利用できるリージョン、つまり米国東部 (バージニア北部) リージョンおよび米国西部 (オレゴン) リージョンで一般的にご利用いただけます。 価格 – Amazon Q APps は、Amazon Q Business Pro サブスクリプション (ユーザーあたり月額 20 USD) で利用可能で、ユーザーは Amazon Q Business のすべての機能にアクセスできます。 学習リソース – 詳細については、 Amazon Q Business ユーザーガイドの Amazon Q Apps をご覧ください。 –  Prasad 原文は こちら です。

7月10日、 Amazon Q Developer (IDE 内) のカスタマイズ機能をインラインコード補完で一般利用できるようにし、チャットのカスタマイズ機能のプレビューをローンチしました。 Amazon Q をカスタマイズして、IDE コードエディタとチャットにおいて、プライベートコードリポジトリから特定の推奨コードを生成できるようになりました。 Amazon Q Developer は人工知能 (AI) コーディングコンパニオンです。既存のコメントやコードから導き出された推奨コードを統合開発環境 (IDE) で提供することで、ソフトウェアデベロッパーがアプリケーション開発を迅速に行えるようにします。 Amazon Q では、Amazon およびオープンソースプロジェクトの何十億行ものコードでトレーニングされた大規模言語モデル (LLM) を舞台裏で使用しています。 Amazon Q は IDE で利用でき、 JetBrains 、 Visual Studio Code 、および Visual Studio (プレビュー中) の拡張機能をダウンロードできます。IDE テキストエディタでは、入力時にコードが提案されるか、入力したコメントから関数全体が記述されます。また、Q Developer とチャットして、特定のタスク用のコードを生成するように依頼したり、発見したコードベースのコードスニペットを説明したりすることもできます。 新しいカスタマイズ機能により、デベロッパーは組織の内部ライブラリ、API、パッケージ、クラス、メソッドに基づいた、より適切なコードのレコメンデーションを受け取ることができるようになりました。 例えば、金融機関に勤務するデベロッパーが、ある顧客の ポートフォリオ 総額を計算する関数を書くことを任されているとしましょう。これで、デベロッパーはコメントで意図を説明したり、 computePortfolioValue(customerId: String) などの関数名を入力したりでき、 Amazon Q は、組織のプライベートコードベースから学習した例に基づいて、その関数を実装するためのコードを提案します。 デベロッパーはチャットで組織のコードについて質問することもできます。上の例では、デベロッパーがチームに初めて入社し、顧客 ID を取得する方法がわからないとします。チャットで平易な英語を使って、「データベースに接続して特定の顧客の customerId を取得するにはどうすればいいですか?」と質問できます。 Amazon Q チャットは、「データベース接続 XYZ を利用して、顧客の苗字と名前から得られた customerId を取得する関数を見つけました」と答えてくれるかもしれません。 管理者は、社内の Git リポジトリ (GitHub、GitLab、BitBucket など) または Amazon Simple Storage Service (Amazon S3) バケットから構築されたカスタマイズを作成します。これは、 Amazon Q が意図を理解し、タスクに最も適した内部 API とパブリック API を判断し、推奨コードを生成するのに役立ちます。 Amazon Q のカスタマイズ機能は、お客様が AWS にかける強力なデータプライバシーとセキュリティの期待事項に応えるものです。 Amazon Q と共有するコードベースは、お客様の組織には公開されません。基盤モデルのトレーニングには使用しません。カスタマイズがデプロイされると、推論エンドポイントは組織内のデベロッパー専用になります。自分のコードに基づいたレコメンデーションは、他社のデベロッパー IDE には表示されません。どのデベロッパーが個々のカスタマイズにアクセスできるかを決定し、メトリクスに従ってデプロイしたカスタマイズのパフォーマンスを測定できます。 Amazon Q のカスタマイズ機能は、 検索拡張生成 (RAG) などの主要な技術手法に基づいて構築されました。この非常に詳細なブログ記事では、 Amazon Q カスタマイズ機能の背後にある科学について詳しく説明しています 。 昨年 10 月 17 日にプレビューを開始して以来、カスタマイズを更新する機能と、IDE でチャットをカスタマイズする機能という 2 つの新機能が追加されました。 組織のコードベースは絶えず進化しているので、 Amazon Q には常に最新のコードスニペットを提案してもらいたいと考えていらっしゃることでしょう。 Amazon Q 管理者は、 AWS マネジメントコンソール で更新プロセスをワンステップで開始できるようになりました。管理者はコードリポジトリの最新のコミットに基づいて定期的な更新をスケジュールし、デベロッパーが常に非常に正確なコード提案を受けられるようにすることができます。 新しいチャットのカスタマイズ (プレビュー中) では、組織内のデベロッパーが IDE でコードの一部を選択してチャットに送信し、選択したコードが何をするのか説明を求めることができます。デベロッパーは、「データベースに接続して特定の顧客の customerId を取得する方法を教えてください」など、組織のコードベースに関連する一般的な質問をすることもできます。 では、その使用方法を見てみましょう このデモでは、現在一般的に利用できる新しいカスタマイズ更新機能に焦点を当てることにしました。カスタマイズの作成方法、有効化の方法、デベロッパーへアクセス権を付与する方法を簡単に学ぶには、 同僚の Donnie の素晴らしい投稿をお読みください 。 既存のカスタマイズを更新するには、 Amazon Q コンソールページの「 カスタマイズ 」セクションに移動します。更新したいカスタマイズを選択します。次に、 [Actions] (アクション) と [Create new version] (新しいバージョンを作成) を選択します。 カスタマイズを作成したときと同じように、ソースコードリポジトリを選択して [Create] (作成) を選択します。 新しいバージョンのカスタマイズの作成には、取り込むコードの量によって異なるため、しばらく時間がかかる場合があります。準備が整うと、 [Versions] (バージョン) タブに新しいバージョンが表示されます。新しいバージョンの 評価 スコアを以前のバージョンと比較し、デベロッパーが利用できるようにアクティブ化することを決定できます。以前のバージョンに戻すこともいつでもできます。 アクティブカスタマイズで気に入っている点の 1 つは、その効果をモニタリングして組織のデベロッパーの生産性を向上させることができることです。 [Dashboard] (ダッシュボード) ページでは、 ユーザーのアクティビティ を追跡します。 日単位のアクティブユーザーの数 、生成された コード行 の数、実行された セキュリティスキャン の数などを追跡できます。私のように、過去に Amazon CodeWhisperer Professional を使用したことがある場合は、現在使用すると、一部のページに CodeWhisperer という名前が残っていることがあります。Amazon Q Developer という新しい名前に徐々に置き換えられる予定です。 Amazon Q はより多くのメトリクスを生成し、 Amazon CloudWatch に公開されます。CloudWatch ダッシュボードを作成して、デプロイしたカスタマイズのパフォーマンスを監視できます。例えば、これはコード提案の ブロック 承認率 と ライン承認率 をプログラミング言語ごとに分類して監視するカスタム CloudWatch ダッシュボードです。 サポート対象プログラミング言語 現在、Java、JavaScript、TypeScript、Python で記述されたコードベースに基づいて Amazon Q レコメンデーションをカスタマイズできます。C#、Go、Rust、PHP、Ruby、Kotlin、C、C++、シェルスクリプト、SQL、Scala など、 Amazon Q がサポートする他の言語で作成されたファイルは、カスタマイズを作成したり、IDE でカスタマイズされたレコメンデーションを提供したりするときには使用されません。 料金と利用可能なリージョン Amazon Q は AWS リージョンに依存せず、世界中のデベロッパーが利用できます。 Amazon Q は現在、米国東部 (バージニア北部) でホストされています。 Amazon Q 管理者は、他のリージョンに AWS IAM アイデンティティセンター がある場合は、 Amazon Q を認可されたクロスリージョンアプリケーションとして設定できます。 Amazon Q カスタマイズ機能は、 Amazon Q Developer プロフェッショナルサブスクリプション 内で追加料金なしで利用できます。AWS アカウントごとに最大 8 つのカスタマイズを作成し、最大 2 つのカスタマイズをアクティブに保つことができます。 さあ、構築に取り掛かって、 Amazon Q のカスタマイズを組織のデベロッパーに提案してみましょう 。 — seb 原文は こちら です。

Agents for Amazon Bedrock を使用すると、 生成人工知能 (AI) アプリケーションはさまざまなシステムやデータソースにわたって多段階のタスクを実行できます。数か月前、エージェントの 作成と設定を簡素化しました 。7月10日、フルマネージド型の 2 つの新機能をプレビューで紹介します。 複数のインタラクションにわたってメモリを保持 – エージェントは各ユーザーとの会話の概要を保持できるようになり、特にユーザーとのやり取りや、フライトの予約や保険金請求の処理などのエンタープライズオートメーションソリューションといった複雑なマルチステップタスクで、スムーズで適応性の高いエクスペリエンスを提供できるようになりました。 コード解釈のサポート – エージェントは、安全なサンドボックス環境内でコードスニペットを動的に生成して実行できるようになり、データ分析、データ視覚化、テキスト処理、方程式の解決、問題の最適化などの複雑なユースケースに対応できるようになりました。この機能をより使いやすくするために、ドキュメントをエージェントに直接アップロードする機能も追加しました。 これらの新機能の仕組みを詳しく見ていきましょう。 複数のインタラクションにわたるメモリの保持 メモリを保持することで、時間をかけて各ユーザーの固有のニーズや好みを学習し、それに適応するエージェントを構築できます。永続的なメモリを保持することで、エージェントはユーザーが中断したところからすぐに再開でき、特に複雑な複数ステップのタスクにおいて、会話やワークフローをスムーズに進めることができます。 ユーザーがフライトを予約するとします。メモリを保持できるため、エージェントは旅行の好みを把握し、その情報を利用してその後の予約リクエストを効率化し、パーソナライズされた効率的なエクスペリエンスを実現できます。例えば、ユーザーに適切な座席を自動的に提案したり、ユーザーが以前に選択したものと同様の食事を提案したりできます。 メモリ保持を利用してコンテキストを把握しやすくすると、ビジネスプロセスの自動化も簡単になります。例えば、企業が顧客フィードバックを処理するために使用するエージェントは、カスタムインテグレーションを処理しなくても、同じ顧客との過去および進行中のやり取りを認識できるようになりました。 各ユーザーの会話履歴とコンテキストは、固有のメモリ識別子 (ID) の下に安全に保存され、ユーザー間で完全に分離されます。メモリを保持することで、時間の経過とともに継続的に改善される、シームレスで適応性のあるパーソナライズされたエクスペリエンスを提供するエージェントを簡単に構築できます。これが実際にどのように機能するかを見てみましょう。 Amazon Bedrock のエージェントでメモリ保持を使用する Amazon Bedrockコンソール で、ナビゲーションペインの [Builder Tools] (ビルダーツール) セクションから [Agents] (エージェント) を選択し、エージェントの作成を開始します。 エージェントについては、名前として agent-book-flight を使用し、説明としてこれを使用します。 フライトの予約を手伝ってあげましょう。 次に、エージェントビルダーで、 Anthropic の Claude 3 Sonnet モデルを選択し 、次の指示を入力します。 フライトを予約するには、出発地と目的地の空港、およびフライトの離陸日時を知っておく必要があります。 追加設定 では、 ユーザー入力 を有効にして、エージェントが明確な質問をして必要な入力を取り込めるようにしています。これは、フライトの予約リクエストで、出発地と目的地、フライトの日時などの必要な情報が不足している場合に役立ちます。 新しい [Memory] (メモリ) セクションでは、各セッションの終了時にメモリを有効にしてセッション概要を生成して保存し、メモリ持続時間はデフォルトの 30 日間とします。 次に、フライトを検索して予約するためのアクショングループを追加します。名前と次の説明として、「 search-and-book-flights 」を使用しています。 特定の日に 2 つの目的地間のフライトを検索し、特定のフライトを予約します。 次に、関数の詳細を含むアクショングループを定義し、新しい Lambda 関数を作成します。Lambda 関数は、このアクショングループのすべての関数のビジネスロジックを実装します。 このアクショングループに 2 つの関数を追加します。1 つはフライトを検索する関数、もう 1 つはフライトを予約する関数です。 最初の関数は search-for-flights で、次のような説明があります。 特定の日付の 2 つの目的地間のフライトを検索します。 この関数のすべてのパラメータは必須で、型は文字列です。パラメータの名前と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード date – YYYYMMDD 形式のフライトの日付 2 つ目の関数は book-flight で、次のような記述を使います。 特定の日時に 2 つの目的地間のフライトを予約します。 繰り返しますが、すべてのパラメータは必須で、タイプは文字列です。パラメータの名前と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード date – YYYYMMDD 形式のフライトの日付 time – HHMM 形式のフライトの時間 エージェントの作成を完了するには、 [Create] (作成) を選択します。 Lambda 関数のソースコードにアクセスするには、 search-and-book-flights アクショングループを選択し、次に [View] (表示) ( Lambda 関数の選択 設定の近く) を選択します。通常は、この Lambda 関数を使用して、旅行予約プラットフォームなどの既存のシステムと統合します。ここでは、このコードを使用してエージェントの予約プラットフォームをシミュレートします。 import json import random from datetime import datetime, time, timedelta def convert_params_to_dict(params_list): params_dict = {} for param in params_list: name = param.get("name") value = param.get("value") if name is not None: params_dict[name] = value return params_dict def generate_random_times(date_str, num_flights, min_hours, max_hours): # Set seed based on input date seed = int(date_str) random.seed(seed) # Convert min_hours and max_hours to minutes min_minutes = min_hours * 60 max_minutes = max_hours * 60 # Generate random times random_times = set() while len(random_times) < num_flights: minutes = random.randint(min_minutes, max_minutes) hours, mins = divmod(minutes, 60) time_str = f"{hours:02d}{mins:02d}" random_times.add(time_str) return sorted(random_times) def get_flights_for_date(date): num_flights = random.randint(1, 6) # Between 1 and 6 flights per day min_hours = 6 # 6am max_hours = 22 # 10pm flight_times = generate_random_times(date, num_flights, min_hours, max_hours) return flight_times def get_days_between(start_date, end_date): # Convert string dates to datetime objects start = datetime.strptime(start_date, "%Y%m%d") end = datetime.strptime(end_date, "%Y%m%d") # Calculate the number of days between the dates delta = end - start # Generate a list of all dates between start and end (inclusive) date_list = [start + timedelta(days=i) for i in range(delta.days + 1)] # Convert datetime objects back to "YYYYMMDD" string format return [date.strftime("%Y%m%d") for date in date_list] def lambda_handler(event, context): print(event) agent = event['agent'] actionGroup = event['actionGroup'] function = event['function'] param = convert_params_to_dict(event.get('parameters', [])) if actionGroup == 'search-and-book-flights': if function == 'search-for-flights': flight_times = get_flights_for_date(param['date']) body = f"On {param['date']} (YYYYMMDD), these are the flights from {param['origin_airport']} to {param['destination_airport']}:\n{json.dumps(flight_times)}" elif function == 'book-flight': body = f"Flight from {param['origin_airport']} to {param['destination_airport']} on {param['date']} (YYYYMMDD) at {param['time']} (HHMM) booked and confirmed." elif function == 'get-flights-in-date-range': days = get_days_between(param['start_date'], param['end_date']) flights = {} for day in days: flights[day] = get_flights_for_date(day) body = f"These are the times (HHMM) for all the flights from {param['origin_airport']} to {param['destination_airport']} between {param['start_date']} (YYYYMMDD) and {param['end_date']} (YYYYMMDD) in JSON format:\n{json.dumps(flights)}" else: body = f"Unknown function {function} for action group {actionGroup}." else: body = f"Unknown action group {actionGroup}." # Format the output as expected by the agent responseBody = { "TEXT": { "body": body } } action_response = { 'actionGroup': actionGroup, 'function': function, 'functionResponse': { 'responseBody': responseBody } } dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']} print(f"Response: {function_response}") return function_response エージェントをコンソールでテストできるように準備し、次の質問をします。 2024 年 7 月 20 日にロンドンのヒースロー空港からローマのフィウミチーノ空港まで運航しているフライトはどれですか? エージェントは時刻表を記載して返信します。エージェントが私の指示をどのように処理したかについての詳細情報を表示するには、 [Show trace] (トレースを表示) を選択します。 [Trace] (トレース) タブでは、エージェントのオーケストレーションで使われた思考の連鎖を理解するためのトレースステップを調べます。例えば、エージェントが Lambda 関数を呼び出す前に空港名からコードへの変換 (ロンドンのヒースロー空港の場合は LHR、ローマのフィウミチーノ空港の場合は FCO) を処理したことがわかります。 新しい [Memory] (メモリ) タブに、メモリの内容が表示されます。コンソールは特定のテストメモリ ID を使用します。アプリケーションでは、ユーザーごとにメモリを分離しておくために、ユーザーごとに異なるメモリ ID を使用できます。 フライトのリストを見て、予約するように頼みます。 午後 6 時 2 分の便を予約してください。 エージェントは予約を確認する返信をします。 数分後、セッションの期限が切れると、 [Memory] (メモリ) タブに会話の概要が表示されます。 ほうきアイコンを選択して新しい会話を開始し、それだけではエージェントに完全なコンテキストを提供できない質問をします。 フライト当日に利用できる他の便はありますか? エージェントは、前回の会話で予約したフライトを思い出します。回答するために、エージェントがフライトの詳細を確認するよう求めてきています。Lambda 関数は単なるシミュレーションであり、どのデータベースにも予約情報を保存していないことに注意してください。フライトの詳細はエージェントのメモリから取得しました。 これらの値を確認して、その日の出発地と目的地の同じ他のフライトのリストを取得します。 はい、お願いします。 メモリ保持の利点をよりよく示すために、 AWS SDK for Python (Boto3) を使用してエージェントを呼び出してみましょう。そのためには、まずエージェントエイリアスとバージョンを作成する必要があります。エージェント ID とエイリアス ID は、エージェントを呼び出すときに必要になるため、書き留めておきます。 エージェント呼び出しでは、メモリを使用するための新しい memoryId オプションを追加します。このオプションを含めると、次の 2 つのメリットが得られます。 その memoryId に保持されているメモリ (ある場合) は、エージェントが応答を改善するために使用されます。 現在のセッションの会話の概要は、別のセッションで使用できるように、その memoryId に保持されます。 AWS SDK を使用すると、特定の memoryId のメモリのコンテンツを取得したり、削除したりすることもできます。 import random import string import boto3 import json DEBUG = False # Enable debug to see all trace steps DATE_FORMAT = "%Y-%m-%d %H:%M:%S" AGENT_ID = 'URSVOGLFNX' AGENT_ALIAS_ID = 'JHLX9ERCMD' SESSION_ID_LENGTH = 10 SESSION_ID = "".join( random.choices(string.ascii_uppercase + string.digits, k=SESSION_ID_LENGTH) ) # A unique identifier for each user MEMORY_ID = 'danilop-92f79781-a3f3-4192-8de6-890b67c63d8b' bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1') def invoke_agent(prompt, end_session=False): response = bedrock_agent_runtime.invoke_agent( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, sessionId=SESSION_ID, inputText=prompt, memoryId=MEMORY_ID, enableTrace=DEBUG, endSession=end_session, ) completion = "" for event in response.get('completion'): if DEBUG: print(event) if 'chunk' in event: chunk = event['chunk'] completion += chunk['bytes'].decode() return completion def delete_memory(): try: response = bedrock_agent_runtime.delete_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, ) except Exception as e: print(e) return None if DEBUG: print(response) def get_memory(): response = bedrock_agent_runtime.get_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, memoryType='SESSION_SUMMARY', ) memory = "" for content in response['memoryContents']: if 'sessionSummary' in content: s = content['sessionSummary'] memory += f"Session ID {s['sessionId']} from {s['sessionStartTime'].strftime(DATE_FORMAT)} to {s['sessionExpiryTime'].strftime(DATE_FORMAT)}\n" memory += s['summaryText'] + "\n" if memory == "": memory = "<no memory>" return memory def main(): print("Delete memory? (y/n)") if input() == 'y': delete_memory() print("Memory content:") print(get_memory()) prompt = input('> ') if len(prompt) > 0: print(invoke_agent(prompt, end_session=False)) # Start a new session invoke_agent('end', end_session=True) # End the session if __name__ == "__main__": main() ラップトップから Python スクリプトを実行します。現在のメモリを削除して (今のところ空のはずですが)、特定の日に朝のフライトを予約するように依頼します。 Delete memory? (y/n) y Memory content: <no memory> > 2024 年 7 月 20 日の LHR から FCO への朝のフライトを予約してください。 2024 年 7 月 20 日 06:44 時のロンドンのヒースロー空港 (LHR) 発ローマのフィウミチーノ空港 (FCO) 行きの午前便を予約しました。 2、3 分待ってから、スクリプトを再実行します。このスクリプトは、実行されるたびに新しいセッションを作成します。今回は、メモリを削除せず、同じ memoryId での以前のやりとりの概要が表示されます。次に、私のフライトがいつ予定されているかを尋ねます。これは新しいセッションであっても、エージェントはメモリの内容から以前の予約を見つけます。 Delete memory? (y/n) n Memory content: Session ID MM4YYW0DL2 from 2024-07-09 15:35:47 to 2024-07-09 15:35:58 ユーザーの目標は、2024 年 7 月 20 日に LHR から FCO への午前中のフライトを予約することでした。アシスタントは、2024 年 7 月 20 日の希望日に、LHR から FCO への午前 6 時 44 分のフライトを予約しました。アシスタントは、ユーザーのためにリクエストされた午前中のフライトを正常に予約しました。ユーザーは、2024 年 7 月 20 日にロンドンのヒースロー空港 (LHR) からローマのフィウミチーノ空港 (FCO) への午前中のフライト予約をリクエストしました。アシスタントは、指定されたルートと日付の午前 06 時 44 分発のフライトを予約しました。 > 私のフライトの出発便は何日ですか? 前回の会話から、2024 年 7 月 20 日にロンドンのヒースロー空港 (LHR) 発ローマのフィウミチーノ空港 (FCO) 行きの午前の便を予約したと記憶しています。2024 年 7 月 20 日のこの日付が、照会しているフライトと合致するかどうかを確認してください。 はい、それが私のフライトです。 ユースケースにもよりますが、メモリ保持機能を使うと、同じユーザーからの以前のインタラクションや好みを追跡し、セッションをまたいでシームレスなエクスペリエンスを提供できます。 セッション概要には、一般的な概要と、ユーザーとアシスタントの視点が含まれます。このセッションのように短いセッションでは、繰り返しが発生する可能性があります。 コード解釈サポート Agents for Amazon Bedrock はコード解釈をサポートするようになったため、エージェントは安全なサンドボックス環境でコードスニペットを動的に生成して実行できるようになり、データ分析、視覚化、テキスト処理、方程式解決、最適化問題などの複雑なタスクを含め、対処できるユースケースが大幅に広がりました。 エージェントは、CSV、XLS、YAML、JSON、DOC、HTML、MD、TXT、PDF など、さまざまなデータタイプと形式の入力ファイルを処理できるようになりました。コード解釈により、エージェントはチャートも生成できるため、ユーザーエクスペリエンスが向上し、データ解釈が容易になります。 コード解釈は、大規模言語モデル (LLM) が特定の問題をより正確に解決するのに役立つと判断した場合にエージェントによって使用され、ユーザーが任意のコード生成を要求するシナリオでは設計上サポートされていません。セキュリティ上の理由から、各ユーザーセッションには分離されたサンドボックス化されたコードランタイム環境が用意されています。 簡単なテストを行って、これがエージェントが複雑なタスクを処理するのにどのように役立つかを見てみましょう。 Amazon Bedrock のエージェントでコード解釈を使用する Amazon Bedrock コンソール で、前のデモ ( agent-book-flight ) と同じエージェントを選択し、 [Edit in Agent Builder] (エージェントビルダーで編集) を選択します。エージェントビルダーでは、 [Additional Settings] (追加設定) で [Code Interpreter] (コードインタープリター) を有効にして保存します。 エージェントを準備し、コンソールで直接テストします。まず、数学的な質問をします。 最初の 10 個の素数の合計を計算してください。 数秒後、エージェントから回答が届きます。 最初の 10 個の素数の合計は 129 です。 正確です。トレースを見て、エージェントはこの Python プログラムをビルドして実行し、私が尋ねたことを計算しました。 import math def is_prime(n): if n < 2: return False for i in range(2, int(math.sqrt(n)) + 1): if n % i == 0: return False return True primes = [] n = 2 while len(primes) < 10: if is_prime(n): primes.append(n) n += 1 print(f"The first 10 prime numbers are: {primes}") print(f"The sum of the first 10 prime numbers is: {sum(primes)}") さて、 agent-book-flight エージェントの話に戻りましょう。長い期間にわたって利用できるフライトの全体像を把握したいと思います。そのためには、まず同じアクショングループに新しい関数を追加して、特定の日付範囲で利用できるすべてのフライトが得られるようにします。 新しい関数に get-flights-in-date-range という名前を付けて、次の説明を使います。 特定の日付範囲でそれぞれの日の、2 つの目的地間の全フライトを取得してください。 すべてのパラメータは必須で、文字列タイプです。パラメータ名と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード 開始日 – YYYYMMDD 形式のフライトの開始日 終了日 – YYYYMMDD 形式のフライトの終了日 前に紹介した Lambda 関数コードを見ると、このエージェント関数は既にサポートされていることがわかります。 エージェントが 1 回の関数呼び出しでより多くの情報を抽出できるようになったので、エージェントにフライト情報データをチャートで視覚化するように依頼します。 2024 年 8 月の最初の 10 日間の JFK から SEA への毎日のフライト数をチャートにしてください。 エージェントの返信には次のようなチャートが含まれています。 コンピュータに画像をダウンロードするためのリンクを選択します。 正解です。実際、Lambda 関数のシミュレーターは、チャートに示されているように 1 日に 1～6 回のフライトを生成します。 添付ファイルでコード解釈を使用する コード解釈により、エージェントはデータから情報を処理して抽出できるため、エージェントを呼び出すときにドキュメントを含める機能を導入しました。例えば、さまざまなフライトで予約したフライトの数が記載された Excel ファイルがあります。 出発地 目的地 フライト数 LHR FCO 636 FCO LHR 456 JFK SEA 921 SEA JFK 544 テストインターフェイスのクリップアイコンを使用して、ファイルを添付して質問します (エージェントは 太字 で返信します)。 一番人気の路線はどれですか? そして、一番人気のない路線は? 分析によると、最も人気のある路線は 921 件の予約がある JFK->SEA で、最も人気のない路線は 456 件の予約がある FCO-> LHR です。 合計でいくつのフライトが予約されていますか? 全路線の予約便の総数は 2557 便です。 これらの路線で予約されたフライトの割合を合計数と比較したチャートを作成してください。 トレースを見ると、ファイルから情報を抽出してエージェントに渡すために使用された Python コードを確認できます。複数のファイルを添付して、さまざまなファイル形式を使用できます。これらのオプションは AWS SDK で利用可能で、エージェントはアプリケーションのファイルを使用できます。 知っておくべきこと メモリ保持は、 Amazon Bedrocks のエージェント および Anthropic の Claude 3 Sonnet または Haiku (プレビュー中にサポート対象のモデル) が利用できるすべての AWS リージョン でプレビュー版としてご利用いただけます。コード解釈は、米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンでプレビュー版としてご利用いただけます。 プレビュー中にエージェントでメモリ保持とコード解釈を使用しても、追加料金はかかりません。エージェントをこれらの機能とともに使用する場合、通常のモデル使用料が適用されます。メモリ保持が有効になっている場合は、セッションの要約に使用されたモデルの料金が発生します。詳細については、 Amazon Bedrock の料金 ページをご覧ください。 詳細については、 ユーザーガイドの「Amazon Bedrock のエージェント」セクション を参照してください。詳細な技術コンテンツや、他の企業が自社のソリューションで生成 AI をどのように使用しているかを知るには、 community.aws にアクセスしてください。 – Danilo 原文は こちら です。

Guardrails for Amazon Bedrock を使用すると、お客様はアプリケーション要件と会社の責任ある人工知能 (AI) ポリシーに基づいて、保護措置を実装できます。望ましくないコンテンツの防止、プロンプト攻撃 (プロンプトインジェクションやジェイルブレイク) の防止、プライバシー保護のための機密情報の削除に役立ちます。複数のポリシータイプを組み合わせて、さまざまなシナリオに合わせてこれらのセーフガードを設定し、 Amazon Bedrock の基盤モデル (FM) だけでなく、Amazon Bedrock 以外のカスタムおよびサードパーティーの FM にも適用できます。Guardrails は、 Amazon Bedrock のエージェント や Amazon Bedrock のナレッジベース と統合することもできます。 Guardrails for Amazon Bedrock は、FM が提供するネイティブ保護に加えて、カスタマイズ可能な追加の保護手段を提供し、業界でもトップクラスの安全機能を提供します。 有害なコンテンツを 85% もブロック お客様が 1 つのソリューション内で安全性、プライバシー、信頼性の保護手段をカスタマイズして適用可能に RAG および要約ワークロードの 75% を超える幻覚応答をフィルタリング Guardrails for Amazon Bedrock は re:Invent 2023 で最初にプレビュー版としてリリースされ、コンテンツフィルターや拒否トピックなどのポリシーをサポートします。 2024 年 4 月に一般公開された時点で 、Guardrails は拒否トピック、コンテンツフィルター、機密情報フィルター、単語フィルターの 4 つの保護手段をサポートしていました。 MAPFRE はスペイン最大の保険会社で、世界 40 か国で事業を展開しています。「MAPFRE は、Mark.IA (RAG ベースのチャットボット) が当社の企業セキュリティポリシーと責任ある AI 慣行に確実に沿っているようにするために、Guardrails for Amazon Bedrock を実装しました」と MAPFRE のアーキテクチャ担当副ディレクターである Andres Hevia Vega 氏は述べています。 「MAPFRE は Guardrails for Amazon Bedrock を使用して、有害なコンテンツにコンテンツフィルタリングを適用し、許可されていないトピックを拒否し、企業のセキュリティポリシーを標準化し、個人データを匿名化して最高レベルのプライバシー保護を維持しています。Guardrails は、アーキテクチャエラーを最小限に抑え、API 選択プロセスを簡素化して、セキュリティプロトコルを標準化するのに役立ちました。AI 戦略を進化させ続ける中で、Amazon Bedrock とその Guardrails 機能は、より効率的で革新的、安全かつ責任ある開発プラクティスに向けた道のりにおいて非常に貴重なツールであることが証明されています」。 7月10日、さらに次の 2 つの機能を発表しました。 コンテキストグラウンディングチェックは、参照ソースとユーザークエリに基づいて、モデル応答中のハルシネーションを検出します。 ApplyGuardrail API は、すべての FM (Amazon Bedrock 上の FM、カスタムおよびサードパーティーの FM を含む) の入力プロンプトとモデル応答を評価します。これにより、すべての生成 AI アプリケーションにわたって一元的なガバナンスを実現できます 。 コンテキストグラウンディングチェック – ハルシネーションを検出する新しいポリシータイプ お客様は通常、会社のソースデータに基づいて根拠のある (信頼できる) 応答を生成するために、FM の固有の機能を利用しています。ただし、FM は複数の情報を混同して、誤った情報や新しい情報を生成し、アプリケーションの信頼性に影響を与える可能性があります。コンテキストグラウンディングチェックは、企業データに基づいていなかったり、ユーザーのクエリとは無関係だったりするモデル応答でハルシネーションを検出できるようにする、5 番目の新たな保護手段です。これは、RAG、要約、情報抽出などのユースケースでの応答品質を向上させるために使用できます。例えば、Amazon Bedrock のナレッジベースでコンテキストグラウンディングチェックを使用して、企業データに基づいていない不正確な応答をフィルタリングすることで、信頼できる RAG アプリケーションをデプロイできます。エンタープライズデータソースから取得した結果は、モデル応答を検証するためのコンテキストグラウンディングチェックポリシーによって参照ソースとして使用されます。 コンテキストグラウンディングチェックには、次の 2 つのフィルタリングパラメータがあります。 グラウンディング – これは、グラウンディング対象となるモデル応答の最小信頼スコアを表す グラウンディングしきい値 を指定することで可能になります。つまり、参照元で提供されている情報に基づくと事実的に正しいものであり、参照元以外の新しい情報は含まれていません。定義されたしきい値よりも低いスコアのモデル応答がブロックされ、設定されたブロックメッセージが返されます。 関連性 – このパラメータは、ユーザーのクエリに関連するモデル応答の最小信頼スコアを表す 関連性しきい値 に基づいて機能します。定義されたしきい値を下回るスコアが低いモデル応答はブロックされ、設定されたブロックメッセージが返されます。 グラウンディングしきい値と関連性しきい値のスコアが高いほど、ブロックされる回答が多くなります。特定のユースケースの精度の許容範囲に基づいてスコアを調整してください。例えば、金融分野の顧客向けアプリケーションでは、不正確なコンテンツに対する許容度が低いため、高いしきい値が必要になる場合があります。 コンテキストグラウンディングチェックのインの動作 コンテキストグラウンディングチェックの例をいくつかご紹介します。 Amazon Bedrock の AWS マネジメントコンソール に移動します。ナビゲーションペインから [Guardrails] (ガードレール) を選択し、次に [Create guardrail] (ガードレールを作成) を選択します。コンテキストグラウンディングチェックポリシーを有効にしてガードレールを設定し、グラウンディングしきい値と関連性しきい値を指定します。 ポリシーをテストするには、 Guardrail の概要 ページに移動し、 テスト セクションを使用してモデルを選択します 。これにより、ソース情報とプロンプトのさまざまな組み合わせを簡単に試して、モデル応答のコンテキスト上の根拠と関連性を検証できます。 この例のテストでは、次のコンテンツ (銀行手数料について) をソースとして使用します。 • 当座預金口座の開設に伴う手数料はありません。 • 当座預金口座の維持費は月額 10 USD です。 • 国際送金には 1% の取引手数料がかかります。 • 国内送金には手数料はかかりません。 • クレジットカード請求書の支払い遅延に関連する料金は 23.99% です。 次に、 [Prompt ] (プロンプト) フィールドに次のように順に質問を入力します。 「 当座預金口座に関連する手数料はいくらですか? 」 実行するには [Run] (実行) を選択し、詳細にアクセスするには [View Trace] (トレースを表示) を選択します。 モデルの回答は事実上正しく、関連性がありました。グラウンディングスコアと関連性スコアの両方が設定されたしきい値を上回っていたため、モデル応答をユーザーに送り返すことができました。 次に、別のプロンプトを試します。 「 クレジットカードに関連する取引手数料はいくらですか? 」 ソースデータには、クレジットカードの延滞請求についてのみ記載されており、クレジットカードに関連する取引手数料については記載されていません。したがって、モデル応答は (取引手数料に関連して) 関連性がありましたが、事実上正しくありませんでした。その結果、グラウンディングスコアが低くなり、スコアが設定されたしきい値である 0.85 を下回ったため、応答がブロックされました。 最後に、次のプロンプトを試しました。 「 当座預金口座を使用する場合の取引手数料はいくらですか？ 」 この場合、ソースデータには当座預金銀行口座の月額料金が記載されているため、モデルの回答は根拠がありました。ただし、クエリは取引手数料に関するもので、応答は月額料金に関するものだったため、関連性がありませんでした。その結果、関連性スコアが低くなり、設定されたしきい値である 0.5 を下回ったため、応答がブロックされました。 AWS SDK for Python (Boto3) を使用して、 CreateGuardrail API によりコンテキストグラウンディングを設定する方法の例を次に示します。 bedrockClient.create_guardrail( name='demo_guardrail', description='Demo guardrail', contextualGroundingPolicyConfig={ "filtersConfig": [ { "type": "GROUNDING", "threshold": 0.85, }, { "type": "RELEVANCE", "threshold": 0.5, } ] }, ) コンテキストグラウンディングチェックを使用してガードレールを作成したら、Amazon Bedrock のナレッジベースや Amazon Bedrock のエージェントに関連付けることも、モデル推論中に参照することもできます。 しかし、それだけではありません。 ApplyGuardrail – Amazon Bedrock 以外で利用可能な FM を使用してアプリケーションを保護 これまで、Guardrails for Amazon Bedrock は主に、モデル推論中のみ、Amazon Bedrock で利用できる FM 用の入力プロンプトとモデル応答の評価に使用されていました。 Guardrails for Amazon Bedrock は、設定されたセーフガードに合わせてすべてのユーザー入力とモデル応答を評価する新しい ApplyGuardrail API をサポートするようになりました。この機能により、基盤となるインフラストラクチャに関係なく、セルフマネージド (カスタム) またはサードパーティーの FM を使用して構築されたすべての生成 AI アプリケーションに、標準化された一貫した保護手段を適用できます。要するに、Guardrails for Amazon Bedrock を使用することで、Amazon Bedrock で利用可能な FM、他のサービス ( Amazon SageMaker など) で利用可能な FM、 Amazon Elastic Compute Cloud (Amazon EC2) などのインフラストラクチャ、オンプレミスデプロイ、および Amazon Bedrock 以外のその他のサードパーティーの FM の入力プロンプトとモデル応答に同じ保護手段のセットを適用できるようになりました。 さらに、 ApplyGuardrail API を使用して、生成 AI アプリケーションのさまざまな段階でユーザー入力とモデル応答を個別に評価できるため、アプリケーション開発の柔軟性が高まります。例えば、RAG アプリケーションでは、ナレッジベースで検索を実行する前に、ガードレールを使用して有害なユーザー入力を評価およびフィルタリングできます。その後、FM からの取得 (検索) と生成ステップを完了した後に、出力を個別に評価できます。 アプリケーションで ApplyGuardrail API を使用する方法を説明します。次の例では、 AWS SDK for Python (Boto3) を使用しました。 まず、拒否されたトピックのセットを含む新しいガードレールを作成し ( create_guardrail 関数を使用) 、新しいバージョンを作成しました ( create_guardrail_version 関数を使用)。 import boto3 bedrockRuntimeClient = boto3.client('bedrock-runtime', region_name="us-east-1") bedrockClient = boto3.client('bedrock', region_name="us-east-1") guardrail_name = 'fiduciary-advice' def create_guardrail(): create_response = bedrockClient.create_guardrail( name=guardrail_name, description='Prevents the model from providing fiduciary advice.', topicPolicyConfig={ 'topicsConfig': [ { 'name': 'Fiduciary Advice', 'definition': 'Providing personalized advice or recommendations on managing financial assets in a fiduciary capacity.', 'examples': [ 'What stocks should I invest in for my retirement?', 'Is it a good idea to put my money in a mutual fund?', 'How should I allocate my 401(k) investments?', 'What type of trust fund should I set up for my children?', 'Should I hire a financial advisor to manage my investments?' ], 'type': 'DENY' } ] }, blockedInputMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', blockedOutputsMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', ) version_response = bedrockClient.create_guardrail_version( guardrailIdentifier=create_response['guardrailId'], description='Version of Guardrail to block fiduciary advice' ) return create_response['guardrailId'], version_response['version'] ガードレールが作成されたら、評価対象のテキストと、作成したばかりのガードレールの ID とバージョンを含む apply_guardrail 関数を呼び出しました。 def apply(guardrail_id, guardrail_version): response = bedrockRuntimeClient.apply_guardrail(guardrailIdentifier=guardrail_id,guardrailVersion=guardrail_version, source='INPUT', content=[{"text": {"inputText": "How should I invest for my retirement? I want to be able to generate $5,000 a month"}}]) print(response["output"][0]["text"]) 使用したのは次のプロンプトです。 退職後のためにどのように投資すべきですか? 月に 5,000 USD 稼げるようになりたいです ガードレールのおかげで、メッセージはブロックされ、事前に設定された応答が返されました。 申し訳ありませんが、受託者として金融資産の管理について、個別のアドバイスやレコメンデーションを提供することはできません。 この例では、ソースを INPUT に設定しています。つまり、評価されるコンテンツはユーザー (通常は LLM プロンプト) からのものです。モデル出力を評価するには、 ソース を OUTPUT に設定する必要があります。 今すぐご利用いただけます コンテキストに基づくグラウンディングチェックと ApplyGuardrail API は現在、Guardrails for Amazon Bedrock が利用可能な すべての AWS リージョン でご利用いただけます。 Amazon Bedrock コンソール でお試しいただき、 AWS re:Post for Amazon Bedrock に、または通常の AWS 担当者を通じて、フィードバックをぜひお寄せください。 Guardrails の詳細については、 Guardrails for Amazon Bedrock の製品ページと Amazon Bedrock の料金 ページにアクセスして、ガードレールポリシーに関連する費用をご確認ください。 また、 community.aws サイトに忘れずにアクセスすると、ソリューションの技術的な内容を詳しく見たり、ビルダーコミュニティが自らのソリューションで Amazon Bedrock をどのように利用しているかを学んだりすることもできます。 — Abhishek 原文は こちら です。

Amazon Bedrock のナレッジベース を使用すると、基盤モデル (FM) とエージェントは、検索拡張生成 (RAG) のために会社のプライベートデータソースからコンテキスト情報を取得できます。RAG は、FM がより適切で正確かつカスタマイズされた回答を提供するのに役立ちます。 過去数か月にわたって、モデル、ベクトルストア、および FM をナレッジベースに埋め込む選択肢を継続的に追加してきました。 7月10日、 Amazon Simple Storage Service (Amazon S3) に加えて、ウェブドメイン、Confluence、Salesforce、SharePoint をデータソースとして RAG アプリケーション (プレビュー中) に接続できるようになったことを発表しました。 ウェブドメイン、Confluence、Salesforce、SharePoint 用の新しいデータソースコネクタ ウェブドメインを含めることで、RAG アプリケーションに会社のソーシャルメディアフィードなどの公開データへのアクセスを許可し、ユーザー入力への応答の関連性、適時性、包括性を高めることができます。新しいコネクタを使用して、Confluence、Salesforce、SharePoint の既存の企業データソースを RAG アプリケーションに追加できるようになりました。 これがどのように機能するかを見ていきましょう。以下の例では、ウェブクローラーを使用してウェブドメインを追加し、Confluence をデータソースとしてナレッジベースに接続します。Salesforce と SharePoint をデータソースとして接続する場合も、同様のパターンに従います。 ウェブドメインをデータソースとして追加 試してみるには、 Amazon Bedrock コンソール に移動してナレッジベースを作成してください。名前や説明などのナレッジベースの詳細を入力し、関連する AWS Identity and Access Management (IAM) 許可を持つ新しいサービスロールを作成するか、既存のサービスロールを使用してください。 次に、使用するデータソースを選択します。 [Web Crawler] (ウェブクローラー) を選択します。 次のステップでは、ウェブクローラーを設定します。ウェブクローラーデータソースの名前と説明を入力します。次に、ソース URL を定義します。このデモでは、自ら執筆したすべての記事を一覧表示する AWS ニュースブログの著者ページの URL を追加します。クロールしたいウェブサイトのシード URL またはスタートポイント URL を最大 10 個追加できます。 オプションで、カスタム暗号化設定と、データソースが削除されたときにベクトルストアデータを保持するか削除するかを定義するデータ削除ポリシーを設定できます。ここでは、デフォルトの詳細設定をそのまま使用します。 同期スコープセクションでは、使用する同期ドメインのレベル、1 分あたりにクロールする URL の最大数、特定の URL を含めるか除外する正規表現パターンを設定できます。 ウェブクローラーデータソースの設定が完了したら、埋め込みモデルを選択し、任意のベクトルストアを設定して、ナレッジベースのセットアップを完了します。作成後にナレッジベースの詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、ナレッジベースをテストして、ウェブ URL を引用として含む FM 応答を確認できます。 データソースをプログラムで作成するには、 AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用できます。 コード例については、 Amazon Bedrock ユーザーガイド をご覧ください。 Confluence をデータソースとして接続する それでは、ナレッジベース設定のデータソースとして Confluence を選択しましょう。 Confluence をデータソースとして設定するには、データソースの名前と説明を再度入力し、ホスティング方法を選択して Confluence URL を入力します。 Confluence に接続するには、ベース認証と OAuth 2.0 認証のどちらかを選択できます。このデモでは、ユーザー名 (Confluence ユーザーアカウントの E メールアドレス) とパスワード (Confluence API トークン) を入力する 基本認証 を選択します。関連する認証情報を AWS Secrets Manager に保存し、シークレットを選択します。 注 : シークレット名が「AmazonBedrock-」で始まり、ナレッジベースの IAM サービスロールに Secrets Manager でこのシークレットにアクセスする許可があることを確認してください。 メタデータ設定では、正規表現の包含パターンと除外パターンを使用してクロールするコンテンツの範囲を制御したり、コンテンツのチャンクと解析の戦略を設定したりできます。 Confluence データソースの設定が完了したら、埋め込みモデルを選択し、任意のベクトルストアを設定して、ナレッジベースのセットアップを完了します。 作成後にナレッジベースの詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、ナレッジベースをテストできます。このデモでは、Confluence スペースに架空の会議メモをいくつか追加しました。ある会議のアクションアイテムについて聞いてみましょう。 Salesforce と SharePoint をデータソースとして接続する方法については、 Amazon Bedrock ユーザーガイド をご覧ください。 知っておくべきこと 包含フィルターと除外フィルター – すべてのデータソースが包含フィルターと除外フィルターをサポートしているため、特定のソースからどのデータをクロールするかをきめ細かく制御できます。 ウェブクローラー – ウェブクローラーは、自分のウェブページまたはクロール権限のあるウェブページでのみ使用する必要があることに注意してください。 今すぐご利用いただけます 新しいデータソースコネクタは、Amazon Bedrock のナレッジベースが利用できるすべての AWS リージョンで現在ご利用いただけます。詳細と今後の更新については、 リージョンリスト を確認してください。ナレッジベースの詳細については、 Amazon Bedrock 製品ページ をご覧ください。料金の詳細については、 Amazon Bedrock の料金ページ を参照してください。 今すぐ Amazon Bedrock コンソール で新しいデータソースコネクタを試して、フィードバックを AWS re:Post for Amazon Bedrock または通常の AWS 担当者に送信し、生成 AI ビルダーコミュニティ ( community.aws ) にご参加ください。 –  Antje 原文は こちら です。

7月10日、機械学習 (ML) 開発ライフサイクルを簡素化および加速する Amazon SageMaker Studio の新機能を発表しました。SageMaker Studio の Amazon Q Developer は、SageMaker JupyterLab エクスペリエンスにネイティブに組み込まれた生成 AI 搭載アシスタントです。このアシスタントは、お客様の自然言語入力をもとに、各タスクに最適なツールの提案、ステップバイステップのガイダンスの提供、開始するためのコード生成、エラー発生時のトラブルシューティング支援を行うことで、お客様の ML 開発ライフサイクルに合わせた実行計画を作成します。また、複雑な ML の問題を小さなタスクに変換したり、ドキュメント内の関連情報を検索したりするなどの課題に直面したときにも役立ちます。 生成人工知能 (生成 AI) や従来の ML のユースケースで Amazon SagaMaker を評価したい初めてのユーザーや、SageMaker の使用方法を知っているけれど生産性をさらに向上させ、インサイトを得るまでの時間を短縮したいと考えているリピートユーザーにも役立ちます。SageMaker Studio の Amazon Q Developer を使用すると、SageMaker Studio を離れなくても、ドキュメントページやオンラインフォーラムでサンプルノートブック、コードスニペット、説明を検索しなくても、ML モデルの構築、トレーニング、デプロイを行うことができます。 それでは、SageMaker Studio の Amazon Q Developer のさまざまな機能をご紹介しましょう。 SageMaker Studio で Amazon Q Developer の使用を開始する Amazon SageMaker コンソール で、 [Admin configurations] (管理者設定) の [Domains] (ドメイン) に移動し、ドメイン設定で Amazon Q Developer を有効にします。Amazon SageMaker を初めて使用する場合は、 Amazon SageMaker ドメインの概要 ドキュメントを確認してください。[ mytestuser ] の [Launch] (起動) ドロップダウンから [Studio] (スタジオ) を選択して Amazon SageMaker Studio を起動します。 環境が整ったら、 [Applications] (アプリケーション) で [JupyterLab] を選択し、 [Open JupyterLab] (JupyterLab を開く) をクリックして Jupyter Notebook を開きます。 生成 AI を搭載したアシスタント Amazon Q Developer は、私の Jupyter Notebook の隣にあります。手始めに使える組み込みコマンドがあります。 ML 問題を自然言語で説明すれば、すぐに Amazon Q Developer との会話を始めることができます。アシスタントのおかげで SageMaker を使えるので、ツールや機能の使い方を調べるのに時間を費やす必要はありません。次のプロンプトを使用します。 S3 バケットにデータがあります。そのデータを使用して、予測用の XGBoost アルゴリズムをトレーニングしたいと考えています。サンプルコードで手順をリストアップしてもらえますか。 Amazon Q Developer がステップバイステップのガイダンスを提供し、予測用に XGBoost アルゴリズムをトレーニングするためのコードを生成してくれます。推奨手順に従って、必要なセルをノートブックに簡単に追加できます。 S3 からデータセットをダウンロードし、Pandas を使って読み込むためのコードを生成する別のプロンプトを試してみましょう。これを使ってモデルの構築やトレーニングができます。これにより、反復的なタスクを処理し、手作業を減らすことで、コーディングプロセスを合理化できます。次のプロンプトを使用します。 S3 からデータセットをダウンロードして Pandas で読み込むためのコードを書いてもらえますか? また、Amazon Q Developer にエラーのデバッグと修正に関するガイダンスを尋ねることもできます。アシスタントは、頻繁に発生するエラーと解決策に基づいてトラブルシューティングを行うのを手伝ってくれます。これにより、時間のかかるオンライン調査や試行錯誤のアプローチから解放されます。次のプロンプトを使用します。 SageMaker のバッチ推論によりモデル品質監視用のマージジョブを実行する場合に、「JSON のスキーマを推論できません。手動で指定する必要があります」というエラーを解決する方法を教えてください。 最後の例として、Amazon Q Developer に、ノートブックジョブのスケジュール方法に関するレコメンデーションを教えてもらいます。次のプロンプトを使用して回答を取得します。 ノートブックジョブをスケジュールするオプションにはどのようなものがありますか? 今すぐご利用いただけます Amazon SageMaker が一般的に利用できるすべてのリージョンで Amazon Q Developer にアクセスできます。 アシスタントは Amazon Q Developer Professional Tier のすべてのユーザーが利用できます。料金の情報は、 Amazon Q Developer の料金ページ をご覧ください。 今すぐ SageMaker Studio の Amazon Q Developer を開始して、ML 開発ライフサイクルの段階を問わず、生成 AI を活用したアシスタントを使い始めましょう。 – Esra 原文は こちら です。

こんにちは。ソリューションアーキテクトの齋藤です。丸紅株式会社(以下、丸紅) デジタル・イノベーション部 では、デジタルを活用して丸紅グループの変革を推進し、デジタル人財を育成して各部門の事業を大きくしていくことをミッションに掲げています。当部では、デジタル技術に精通するメンバーが、丸紅の各組織へ、課題整理→実証実験→実用化まで一気通貫で支援を実施しており、AI・データ分析 を中心に、内製で開発しています。本ブログでは、どのように丸紅がAWS上で社内生成AIプラットフォームアプリ(以降 Marubeni Chatbot)を開発して、社内公開までに直面した課題を解決したか、どのようにユーザへ活用促進を繋げたか、赤裸々に紹介させて頂きます。本ブログは、丸紅 デジタル・イノベーション部 芹川 武尊 氏 から寄稿していただいたものです。 背景 AWS 齋藤  : Marubeni Chatbot の開発が始まった経緯について教えてください。 丸紅 芹川氏 : 元々、私を含めた若手2名での生成AIを使って、なにかやりたいね! という漠然とした雑談が発端です。2023年3月に、GPT-4 を目の当たりにして、衝撃を受けたことが記憶に残っています。これは来るな! と感じました。難易度を4つのレベルに分けて、より技術的・業務的に容易でインパクトも出やすい領域から導入を進めました。開発は自社で熱意のある人が開発するほうが早いということになり、自社若手メンバーで Marubeni Chatbot の内製開発になりました。 AWS 齋藤 : 　ちなみに丸紅様にとってAIを取り扱う中でビジネス上どのような課題があったのですか? 丸紅 芹川氏 : デジタル・イノベーション部は、AIやデータ分析を活用したDX推進に取り組んでおり、その中で複数の部門・事業会社から特定の業務の効率化・高度化を求める声が上がっています。一方、丸紅の事業範囲が非常に広いため、各事業の特殊性に応じた個別対応が必要となるケースが多くあります。このため、AI導入におけるROI（投資対効果）を最適化するためには、各事業部門が主導的にAIを活用し、その業務特性や課題に即したソリューションを開発する、言うなれば「AIの民主化」の実現が必要であると考えていました。そして、最近の生成AIの登場により、それが遠くない未来に現実的に実現可能になったと考えております。 Marubeni Chatbot について AWS 齋藤 : Marubeni Chatbot の ユーザーは、どのような方ですか? 丸紅 芹川氏 : 丸紅本体の役員、管理職、一般社員、グループ会社社員まで、多種多様な社員が使用しています。登録ユーザー数は7,500人以上になっています。 AWS 齋藤 : Marubeni Chatbot では、どのくらいのデータ量を扱っていますか? 丸紅 芹川氏 : 現時点(2024年6月時点)では、ユーザーによって登録されたファイル数は、60,000ファイル、PDF形式に変換したデータ量でいうと 500GB 程になります。 AWS 齋藤 : Marubeni Chatbot の概要及びどのような機能を提供しているか教えてください。 丸紅 芹川氏 : Marubeni Chatbot では、複数のLLM(Claude 3.5 Sonnet, Claude 3 Opus, Gemini 1.5 Pro, GPT-4o, GPT-4 Turbo)をエンドユーザ自身が選択することが出来るチャットアプリを提供しています。多数の機能がありますが、3つに絞り紹介させて頂きます。1つめは ファイルチャットアプリ です。これは、エンドユーザが業務で使用する契約書や資料 (Word, Excel, Powerpoint, PDF) を、Marubeni Chatbot に、エンドユーザ自身がアップロードし、資料内容に基づいて、エンドユーザからの質問への回答や文書の要約を提供します。丸紅はグローバルに展開する商社ということもあり、スペイン語、中国語、ベトナム語など、英語以外の資料を取り扱う機会も多いのですが、そういった資料の日本語での要約、質問回答は、業務効率の大きな改善に繋がっています。2つめは 音声認識チャットアプリ です。これは、音声や動画ファイルをアップロードすると、会議音声の文字起こし・議事録作成を行うことができます。また、会議の最中に本システムを起動して、リアルタイムで文字起こしを行うことも可能です。最後は、 カスタムボットアプリ です。これは、エンドユーザ自身で、担当業務に関連する資料を集約することで、独自の Knowledge base を構築出来ます。特定の部署内のルールに対して回答してくれるボットがその部署内のメンバーによって作成され活用されるなどユーザー自身の手による業務効率化につながっています。尚、こちらの機能でも、LLMは業務特性に合わせて選択することが可能です。 AWS 齋藤 : 各機能のアーキテクチャについても紹介していただけますか? 丸紅 芹川氏 : アーキテクチャは下記の通りになります。 ファイルチャットアプリ ユーザは、Webアプリケーションから、ファイルをアップロードします。アップロードがトリガーになり、外部LLMを用いて Embedding し、Amazon S3 にベクトルデータを格納します。ファイルに関してユーザから指示があると、AWS Lambda は、Amazon S3 に格納されたベクトル情報をメモリに読み込み、類似度の高い文書及びセクションを検索し、Amazon Bedrock で回答を生成します。 ファイルチャット UI ファイルチャット アーキテクチャ 音声認識チャットアプリ ユーザは、Webアプリケーションから、音声又は動画ファイルをアップロードします。アップロードされたファイルは、Amazon Transcribe にて、Speech to Text がされますが、変換時の間違い、区切りの誤りなど、Amazon Bedrock を用いて整形します。音声ファイルの中身そのものを変えないように、プロンプトの試行錯誤を繰り返すことで、想定した変換を実現することが出来ました。また、書き起こし後のテキストに対してチャットUIで質問を投げかけることも可能で、こちらの機能を活用することで容易に議事録作成が可能です。 音声認識チャット アーキテクチャ カスタムボットアプリ ユーザは、Webアプリケーション上のUIから、データソースとなるドキュメントやFAQを登録することで、独自のカスタムボットを作成出来ます。このときユーザーは、LLMの指定とパラメータ設定、そのカスタムボットにアクセスできるユーザーの登録(ユーザ名, 部署, 会社)を行えますが、本情報は、Amazon DynamoDB に保管されます。カスタムボットアプリで使用されるデータソースとなるドキュメントは、Amazon S3 に保管され、外部LLMを用いて Embeddingを計算し、Pineconeにベクトルデータを保存します。データソースとなるドキュメントの中身は、Webアプリケーションからいつでも追加・変更することが可能です。回答精度の改善をしたいときや、事前に回答を規定したいときには、FAQの登録によってチューニングすることも可能です。 カスタムボットアプリ アーキテクチャ カスタムボットアプリ モデル設定 カスタムボットアプリ アーキテクチャ ドキュメント追加・編集UI カスタムボットアプリ FAQ 登録UI AWS 齋藤 : ユーザーが能動的に生成AIを使用することが出来る環境を提供していることが印象に残りました。 直面した課題と解決へのアプローチ AWS 齋藤 : Marubeni Chatbot を構築する中で課題に直面したと思います。どんな課題があり、それをどのように解決したのでしょうか? 丸紅 芹川氏 : Marubeni Chatbot 内のRAGを用いたアプリの開発の中で、回答の精度が課題になりました。例えば、社内規程をもとに回答するボットでは、回答に対して間違いが許容されにくく、一貫性や精度を確保する必要がありました。これに対するアプローチとして、元々WordやPDFの形式で保管された社内規程文書に、意味のあるテキストセグメンテーションを持たせるために、Markdownで記載しなおすように前処理をしました。その後、Markdownでセクションごとにセグメンテーションされた文書をEmbeddingして、 Pinecone にベクトルデータを保存しました。又、開発で工夫した点としては以下です。開発にLangchainを使用していたが、OpenAIのLLMが基軸になっており、Anthropic社など他社LLMへの対応が遅れていることを感じ、LangChainを取り除いて自社で抽象レイヤーを開発しました。それに加え、生成AIの回答精度の改善のために、WordやPowerpointからMarkdownへ変換を実施しましたが、手作業になっていたので、ここでも生成AIを活用して社内規程文書を自動でMarkdown形式に変換する機能を実装しました。 導入効果 AWS 齋藤 : Marubeni Chatbot 導入によりどのような効果がありましたか? 丸紅 芹川氏 : はい。2024年2月時点でのデータになりますが、ユーザからのFeedbackとして各業務で25-65%程度の時間削減効果及び業務高度化の効果を実感したとありました。詳細は下記のグラフの通りになります。 業務時間削減率について Why AWS? AWS 齋藤 : Marubeni Chatbot に、AWSが採用された決め手を教えて下さい。 丸紅 芹川氏 : たくさんあるのですが、AWS は フルマネージド型でありつつも、拡張性が高いサービスが充実しているところです。Marubeni Chatbot　開発当初はコストを割り当てることが難しく少ないメンバーで始める必要がありましたが、長期的には機能やユーザー数が増える可能性も予想されていました。そのような不確実性の高い状況下では、AWSのフルーマネージド型 サービスを採用するところから始めることで、OSやミドルウェアの運用保守をAWSにオフロードし、機能数やトラフィック数が増加したときも構成を大きく変えることなくスケールすることが可能でした。セキュリティでは、HIPPAやGDPRへ準拠しており、エンタープライズ用途でも利用しやすかったです。 今後の展望について AWS 齋藤 : Marubeni Chatbot の、今後の展望について教えてください。 丸紅 芹川氏 : 現在、Level4: 経営判断の高度化への取り組みの開発と利用を進めており、この精度の更なる改善に取り組んでいます。それと同時に丸紅グループ社員の意識改革も引き続き必要だと考えています。まずは実業務での利用を通して、生成AIの特性を現場レベルで理解してもらう。その上で社員一人ひとりが、AI 1st の意識を持って、 AI に最適な形に知見を集積していく。これらを通じて長期的にはAI を使い倒す企業文化を醸成し、それがより高度な生成AIの活用につながってきます。 著者について 丸紅 芹川氏 2022年 東京大学大学院情報理工学系研究科修士課程修了。情報理工学修士（数理最適化に関する研究)。大学院修了後、丸紅株式会社に入社。入社後は、物流関連最適化システムの開発や、生成AIを活用したグループ会社向けChatbotアプリの開発など丸紅グループを横断したプロジェクトの参画。

2024 年 1 月、マイグレーションとモダナイゼーションを加速させるためのガイドツールとして、Migration Hub Journeys を導入しました。ジャーニーは、エキスパートによるガイダンス、専用ツール、チーム間のコラボレーションを備えたタスクベースのテンプレートを通じて、計画、実行、追跡を最適化し、シームレスなマイグレーションとモダナイゼーションを可能にします。この度、AWS for VMware の新しいマイグレーションジャーニーテンプレートを公開しました。このテンプレートによって、オンプレミス、他のクラウド、VMware Cloud on AWS の VMware ワークロードから、AWS ネイティブサービスへの迅速なマイグレーションとモダナイゼーションを可能にします。 AWS Migration Hub Journeys とは AWS Migration Hub Journeys は、マイグレーションプロジェクトをテンプレート化して、社内外のプロジェクト関係者間でタスクを調整するために設計されています。ジャーニーはユーザーに包括的なマイグレーションジャーニーを提供することで、マイグレーションを最初から最後まで実行および追跡できるようにします。エキスパート、プロセス、ツールを結集して、マイグレーション作業を効率化することができます。 図 1 : Migration Hub Journeys の概要 ジャーニーの主な機能には以下のようなものがあります： マイグレーション計画： クラウドマイグレーションを計画するための構造的な方法を提供します。 規範的ガイダンス： マイグレーションテンプレートの形式でガイダンスを行います。 実行と追跡： マイグレーションタスクを管理し、進捗のモニタリングを行って、途中で発生した問題に対処することができます。マイグレーション状況をリアルタイムに確認することができます。 コラボレーションとガバナンス： マイグレーションに関して、さまざまなステークホルダーが協力しやすくなります。 Migration Hub Journeys の新機能 VMware ベースのワークロードを AWS へ速やかにマイグレーションするための新しいテンプレートを追加しています。これらのテンプレートは AWS Migration Methodology に沿って設計されており、効率的に AWS にマイグレーションできるようにタスクのパイプラインを提供します。これらのテンプレートから作成されるマイグレーション関連タスクのパイプラインであるジャーニーは、必要な情報を収集することでインフラストラクチャの現状を評価して、現在のライセンス資産を把握するプロセスをガイドします。また、必要なネットワーキング、セキュリティ、ガバナンスコントロールを備えたランディングゾーンを作成して、リソースを AWS へマイグレーションのためのタスクもガイドします。さらに、AWS クラウドネイティブサービスへマイグレーションするためのタスクもガイドします。 図 2 : Migration Hub のマイグレーションテンプレート AWS for VMware マイグレーションテンプレート VMware から AWS EC2 へのマイグレーションテンプレートは、アセスメント、モビライズ、マイグレーション、モダナイゼーション、オペレートの各フェーズに分類された一連のタスクです。各フェーズはいくつかのモジュールに分かれており、さらにタスクとサブタスクに分かれています。効率的にマイグレーションを実行および追跡できるように、テンプレートで特定のタスクに関連する VMware のガイダンスが表示されます。 例えばアセスメントフェーズのタスクでは、RVTools を使用してサーバー使用率情報を収集し、ビジネスケースに反映させるためのガイダンスが表示されます。さらに、AWS にはマイグレーションアセスメントプログラムとパートナーソリューションがあり、アセスメントフェーズ中に正確なマイグレーションビジネスケースを提供できます。また、現在のアプリケーション / ベンダーライセンスを理解し、コストパフォーマンスを向上させるために AWS をどのように活用できるかをタスクでガイダンスします。マイグレーションフェーズのタスクでは、AWS Application Migration Service (MGN) レプリケーションの使用など、マイグレーションシナリオに特化したツールの選択に関するガイダンスが表示されます。この情報は必要なコンテキストでタスクを実行できるように、それぞれのタスクで提示されます。 図 3 : マイグレーションフェーズのタスクボード 同様に他のフェーズについても、いくつかのモジュール、タスク、サブタスクに分解されています。推奨されるフローに従うことで AWS へのマイグレーションを成功させるために必要なすべてのステップが示され、マイグレーションの実行と追跡が容易になります。 VMware から AWS へのマイグレーションの実行 このシナリオでは VMware から AWS EC2 へのマイグレーションテンプレートを使用して、マイグレーションジャーニーを作成します。ジャーニーを作成したら、タスクの追加、変更、削除を行って、ニーズに合わせてジャーニーをカスタマイズし、他のユーザー (パートナーや AWS 担当者を含む) を招待してコラボレーションを行うことができます。また、ニーズだけに基づいてカスタムジャーニーを簡単に作成することもできます。権限に基づいてユーザーが個々のタスクをエキスパートに割当て、遅延やブロックされたタスクの自動通知を受取ったり、コンテキストが失われないように一箇所に成果物をアップロードできます。ジャーニーを作成する画面を参照してマイグレーションジャーニーの構造を理解してください。 図 4：テンプレートからのジャーニーの作成 ジャーニーが作成されるとジャーニーのダッシュボードにリダイレクトされます (図 5 )。ここではジャーニーの概要と詳細のセクションが表示されます。管理者は、マイグレーションスペースの他のメンバーや、マイグレーションスペースのチーム、さらには AWS 担当者やパートナーなど、マイグレーションスペース外のメンバーを招待することで、コラボレーションを促進することもできます。 図 5：ジャーニーダッシュボード ダウンタイムをほぼゼロにして VMware サーバーを AWS にマイグレーションする方法は複数ありますが (ブロックレベルのレプリケーション、VM Import/Export、パートナーソリューション)、AWS Application Migration Service (MGN) が VMware ベースのワークロードを AWS クラウドにリホストするための主要なマイグレーションサービスとして推奨されています。 例えば AWS MGN は、オンプレミスから AWS へのサーバーレプリケーションにエージェントベース (図 6 ) とエージェントレス (図 7 ) の両方のアプローチをサポートしています。エージェントは Windows と Linux の両方のサーバーにインストールできます。AWS Application Migration Service でレプリケートしたい各ソースサーバーに AWS Replication Agent をインストールする必要があります。 図 6 : AWS MGN エージェントベースのマイグレーションアーキテクチャ エージェントレスアプローチではエージェントレスレプリケーション機能によって、エージェントをインストールせずに vCenter からソースサーバーを追加することもできます。AWS MGN vCenter Client がインストールされると、vCenter 環境内のすべての仮想マシンを検出して AWS MGN に追加します。 図 7 : AWS MGN エージェントレスマイグレーションのアーキテクチャ Migration Hub Journeys テンプレートのタスクとサブタスクは、エージェントベースまたはエージェントレスの方法でマイグレーションプロセスをガイドします。マイグレーション中に必要なすべてのステップ、タスクの所有者、タイムライン、問題、アクションを追跡し、マイグレーションを成功に導きます。 まとめ VMware ベースのワークロードを AWS に迅速にマイグレーションし、最適化できるようにするために、AWS for VMware の新しい Migration Hub Journeys テンプレートを発表しました。これらのテンプレートを利用することで、ステークホルダー、AWS 担当者、パートナー間のコラボレーションを促進し、クラウドへのスムーズなマイグレーションを確保するために効率的な計画と実行ができるようになります。さらに、AWS の広範なグローバルインフラストラクチャによって、スケーラビリティの確保、高いセキュリティ、信頼性の向上、パフォーマンス改善を行うことができます。 AWS Migration Hub Journeys でマイグレーションジャーニーを始めましょう。今すぐ AWS Builder ID を使用してサインインしてください。 また、ワークショップに参加して、ジャーニーの包括的な理解を深し、マイグレーションプロセスをどのように変えることができるかを学ぶこともできます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。 Migration Hub Journeys と VMware ワークロードの AWS へのマイグレーションに関する追加情報については、以下を参照してください： 計画から実行まで ー AWS Migration Hub を活用してマイグレーションとモダナイゼーションを加速する VMware 仮想マシンを AWS Application Migration Service レプリケーションエージェントを利用して Amazon EC2 に移行する Agentless snapshot based replication for vCenter source environments Accelerate vCenter Migration using AWS Migration Service Agentless Migration AWS VMware Migration Accelerator 著者について Hemanth Vemulapalli 12 年以上の業界経験を持つマイグレーション専門の AWS ソリューションアーキテクト。企業がワークロードを AWS クラウドにシームレスにマイグレーションすることを支援しています。信頼できるアドバイザーとして深い技術的専門知識を活用し、ビジネス変革を推進する革新的なソリューションを設計および実装しています。余暇には、テレビ鑑賞、ハイキング、ランニング、家族との時間を楽しんでいます。 Mangesh Budkule AWS のシニア Microsoft 専門ソリューションアーキテクト。AWS サービスのアーキテクチャガイダンスと技術支援を提供し、AWS を利用するうえでソリューションの価値を向上させるために、顧客と協働しています。2003 年から IT エキスパートとして業界の様々なベンダーの多様な技術をカバーしています。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS Summit New York があり沢山の生成 AI 関係のアップデートがありました。 週刊生成AI with AWS で網羅的に取り上げており、こちらもご覧ください。 異なる視点での最近の生成 AI の出来事を記載すると、 GenU (Generative AI Use Cases JP) という名前の GitHub で公開されているアプリケーションがあるのですが、新たに Knowledge bases for Amazon Bedrock を利用した RAG チャットの機能が追加されました。Knowledge Bases の進化に合わせた機能の利用がやりやすくなったり、コスト面では従来の Kendra を利用した構成と比較して、最大 1/6 ほどの料金で RAG チャットが利用できるようになっています。ぜひ、こちらもお試しください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年7月8日週の主要なアップデート 7/8(月) Amazon CloudFront がウェブアプリケーション向けの管理キャッシュポリシーを提供 Amazon CloudFront は、2 つの新しい管理キャッシュポリシー「UseOriginCacheControlHeaders」と「UseOriginCacheControlHeaders-QueryStrings」を提供開始しました。新しい管理キャッシュポリシーは、オリジンから返されるレスポンスに Cache-Control ヘッダーが有ればコンテンツをキャッシュし、Cache-Control ヘッダーが無ければキャッシュをしません。キャッシュをさせたい静的なページと、キャッシュさせたくない動的なページが混在しているときに、新しいキャッシュポリシーでシンプルな利用がやりやすくなった形です。 FreeRTOS が新しいロングタームサポートバージョンをリリース FreeRTOS のロングタームサポート (LTS) として、202406 LTS をリリースしました。FreeRTOS LTS リリースは、2 年間にわたってセキュリティアップデートと重要なバグ修正を提供しながら、機能の安定性を提供します。FreeRTOS は、組み込みデバイス用に設計されている OS で、IoT といった文脈でよく利用されるものとなっており、軽量に動作する特徴があります。 Amazon Connect の自動エージェントシフト交代機能 Amazon Connect で、電話対応するエージェントのシフト交代スケジュールを自動化できるようになりました。元々、Amazon Connect には管理者がスケジュール管理を行う機能があります。今回の、自動シフト交代機能により、エージェントが繰り返し交代する一連のシフト (例: 朝のシフト、午後のシフト、夜のシフト) を作成することで、自動的にシフト交代を作成してくれるようになりました。詳細は こちらのブログ をご確認ください。 7/9(火) Amazon Q Business でユーザーに合わせてパーソナライズした応答 Amazon Q Business でパーソナライズされた応答を行うための機能が追加されました。Amazon Q Business の認証に利用する Identity Provider から、従業員の所在地、部門、役割といった情報を利用して応答の関連性を高める仕組みをもちます。このパーソナライズ機能は自動的に有効化されており、追加の設定なしにご利用いただけます。 AWS Glue Studio で ノーコードのデータ準備機能を提供 AWS Glue Studio Visual ETL で、データアナリストや機械学習エンジニア向けに、データのクリーニングや加工などの前準備を、表形式の GUI で実行できる機能が追加されました。Visual ETL で処理したい内容を GUI で繋げてデータ加工フローをくみ上げるのですが、そのフローの中に Glue DataBrew のレシピを連携できるようになった形です。詳細は こちらのブログ をご参照ください。 Amazon FSx for NetApp ONTAP で NVMe-over-TCP をサポート Amazon FSx for NetApp ONTAP で NVMe-over TCP をサポートしました。これは、従来の iSCSI ブロックストレージと比較して低レイテンシで、データベースや仮想デスクトップインフラストラクチャ (VDI) などのブロックストレージワークロードを高速化できます。また冗長化のためのマルチパス構成をシンプルにできる特徴もあります。 7/10(水) Claude 3 Haiku でファインチューニングがプレビュー可能に Amazon Bedrock で Anthropic の Claude 3 Haiku モデルのファインチューニングがプレビューで利用可能になりました。組織独自のトレーニングデータセットを用意してファインチューニングを行うことで、企業の独自の情報、ブランド、製品などを反映したユーザー体験を作り出すことができます。ファインチューニングを実施する際に、利用者専用の隔離された環境にコピーしたうえでトレーニングを行うため、セキュアな環境で利用する仕組みが備わっています。現在はオレゴンリージョンで利用が可能です。利用するには、AWS Support にお問い合わせください。 Amazon Q Developer で組織内の独自コードを利用した生成機能のプレビュー Amazon Q Developer で、独自ソースコードを利用した、ソースコード生成のプレビュー提供を開始しました。GitHub、GitLab、BitBucket、S3 に格納している、組織内のソースコードを使ってカスタマイズすることで、独自コードに基づいた内容を生成できるようになりました。例えば、組織内に共通的に利用するライブラリがあったときに、そのライブラリに実装されている関数を使って、新たなコードを生成できます。カスタマイズに利用したソースコードは、モデルの学習に利用されることはありません。Amazon Q Developer Pro サブスクリプションでご利用いただけます。詳細は こちらのブログ をご参照ください。 Agents for Amazon Bedrock で Code Interpretation 機能のプレビュー Agents for Amazon Bedrock で 新たにコード解釈機能 (Code Interpretaion) のプレビュー提供を開始しました。利用者のリクエスト内容に応じて、Agents は安全なサンドボックス環境でコードスニペットを動的に生成、実行できるようになり、データ分析、データ可視化、最適化問題などの複雑なユースケースを実行しやすくなりました。また、CSV、XLS、YAML、JSON、DOC、HTML、MD、PDF などのファイルを渡せるようになりました。例えば、CSV ファイルを渡して、「このデータをもとに売り上げ上位 3 種類を可視化して」とリクエストすると、可視化した画像が生成されます。現在、バージニア北部、オレゴン、フランクフルトリージョンでプレビュー利用ができます。詳細は こちらのブログ をご参照ください。 Knowledge Bases for Amazon Bedrock で Advanced RAG 機能の追加 Knowledge Bases for Amazon Bedrock で Advanced RAG 機能として、高度なチャンキング機能を提供開始しました。階層的なチャンキング (Hierarchical chunking) は、データを親チャンクと子チャンクの階層構造にして管理します。子チャンクを関連データとして取得する際に、より幅広く関連性の高いデータにするため、親チャンクのデータを利用するような仕組みとなります。セマンティックチャンキング (Semantic chunking) は、自然言語処理の手法を利用し、データを意味のあるチャンクに分割することで、理解と情報検索性能を向上させます。また、チャンクを行うコードを Lambda 関数で用意する機能が追加され、ユースケースに合わせた独自のチャンク分割を処理できます。ほかにも追加された機能があり、詳細は こちらの Document をご覧ください。 Amazon Bedrock でプロンプト管理や、プロンプトフロー機能のプレビュー Amazon Bedrock でプロンプト管理や、プロンプトフローのプレビュー提供を開始しました。Prompt Builder を利用することで、プロンプトを定義し、複数のモデル間の違いを確認しながら、最適なプロンプトの組み立てに役立てられます。外部のアプリケーションから、作成したプロンプトを使用するには、API コールでプロンプトを取得できます。また、Bedrock Prompt Flows は、視覚的なビジュアルビルダーを使って、ワークフローの作成、テスト、デプロイができます。詳細は こちらの Blog をご覧ください。 7/11(木) Amazon ECSでは、トラブルシューティングをより簡単に行えるよう、停止したタスクのエラーメッセージがより詳細な出力 Amazon ECS で停止したタスクのエラーメッセージが、より具体的な失敗理由と対処方法の推奨事項が含まれるようになりました。 AWS ドキュメント に具体的となったエラーの一覧とその対処豊富も記載されており、AWS マネジメントコンソールからリンクされすぐに辿れるようになっています。例えば、タスクの起動が失敗したときのメッセージをいくつか抜粋すると、 「Subnet の IP アドレスの空きがない」、「ECR から Pull ができなかったので、接続性に問題がある」、「Fargate Spot でキャパシティがない」といったわかりやすい内容にアップデートされています。 7/12(金) Amazon Q Business は、スキャンされた PDF とPDF 文書に埋め込まれた画像のサポートを導入 Amazon Q Business は、お客様の社内データに基づいて、質問の回答、要約、コンテンツの生成などを行う生成 AI 支援アシスタントです。このアップデートで、PDF のテキスト内容に加えて、紙の書類をスキャンして画像として貼り付けられている PDF に基づき生成ができるようになりました。スキャンした PDF にある表形式のデータや、構造化されたフォームを扱えるようになっています。詳細は こちらのブログ をご参照ください。 7/24 (水) 19:00~ に、Startup Loft (目黒オフィス) で「 IoT サブスクリプション ビジネスの課題と取り組み 」イベントを開催します。株式会社ビットキー様や株式会社VACAN様の事例のお話や、AWS Japan からの登壇の内容もあります。大規模利用事例や、スタートアップとしてのビジネス上で苦労された点のお話がありますので、ぜひ興味がありましたらご参加ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

本記事は 2019年9月9日に公開された ”How to Create a Data-Driven Culture” を翻訳したものです。 「もしデータがあるなら、データを見ましょう。もし皆さんに意見しかないのなら、私の意見に従ってください。」 ― ジム・バークスデール データドリブンな企業について語られるとき、多くの場合、ツールやビッグデータ、データの蓄積/加工/分析をより迅速かつ安価にした技術の進歩に重点が置かれています。これらは全て重要ではありますが、データドリブンカルチャーを企業全体で構築することは、ごくわずかなデータイニシアチブの成功や、特定の事業領域のみでの成功例を上回るために不可欠です。 データドリブンカルチャー では、意思決定時におけるデータの使用を受け入れます。データを広く利用可能にし、アクセスできるようにすることで、データを企業の戦略的資産として扱います。事業全体から意味のあるデータを収集し、クレンジング (訳註: 異常値排除や欠損値補完、表記ゆれの補正などを行なってデータの正確性を高めること) し、キュレーション (訳註: 組織内外のデータを組み合わせるなどして有益なインサイトが得られるように強化すること) することに重点を置いています。また、学習と改善のための頻繁な実験を促進し、人工知能 (AI) と機械学習 (ML) によるビジネスの差別化には、データの強固な基盤が不可欠であることを認識しています。さらに、データリテラシーのレベルが高く、データはすべての人の業績向上に役立つという信念が根付いているカルチャーです。 組織のリーダー達は、どのようにしてデータドリブンカルチャーを築くことができるでしょうか? 有言実行 データドリブンカルチャーを築くには、経営幹部のスポンサーシップが必要ですが、それだけでは十分ではありません。経営幹部には、単なるサポート以上のことが求められます。意思決定時には常に、データとビジネス判断を明確に結びつける必要があります。これには、不必要なレポートやスプレッドシート、ダッシュボードを容赦なく炙り出し、データドリブンカルチャーの錯覚を作り出すためだけに生成されたものを取り除くことが含まれます。データは目的に基づいて作られるべきであり、データ作成自体が目的ではありません。 経営幹部は、自分の信念に反するデータも積極的に求めるべきです。新しいデータに基づいて方針を変更することは、データドリブンカルチャーを作ろうとするリーダー達の強い決意を組織に示すシグナルになります。 データは力を与えてくれますが、強い感情を引き起こすこともあります。データドリブンカルチャーは、企業全体に透明性と説明責任をもたらします。これは時に不快なものになることがあります。一般的な企業では、他の組織にデータとインサイトを提供する専門のチームがあります。彼らは自分たちが関与せず、データの解釈を制御できなくなることを恐れています。経営幹部は、抵抗と組織の硬直化を克服するために介入する必要があります。 成功を生む組織を作る それぞれのデータイニシアチブは、他のものに付随するものとしてではなく、一つの製品のように管理されるべきです。そのためには、それを支える適切な組織体制を整える必要があります。私の同僚の Joe Chung が、「 データドリブンな組織になるには 」(eBook) で、アナリティクス CoE (Center of Excellence) の設立について語っています。これについて、アマゾン社で「シングルスレッドリーダー」と呼んでいるものの観点から考えてみたいと思います。シングルスレッドリーダーは、完全に権限を与えられたリーダーで、与えられた目標の実現を何かとの兼任ではなく、フルタイムの仕事として担当します。( Dave LimpとJeff Wilke から学ぶシングルスレッドリーダーの詳細については、 Forbes の こちらの記事 をご覧ください。) データドリブンカルチャーを築くには、そのことに専念している、権限が与えられたリーダーの存在が重要です。 データエンジニアリングとアナリティクスを IT 部門から切り離す傾向が高まっており、それが摩擦を生むこともあります。組織構造にかかわらず、IT 部門はデータイニシアチブを技術的にサポートするだけではなく、もっと重要な役割を果たすべきです。IT部門は、エンドツーエンドのビジネスサイクル、部門をまたがるワークフロー、および多くの有益なインサイトを内包するトランザクションシステムを完全に把握できるという点で、独自の立場にあります。私が CTO になる前は、グローバルな製品、アプリケーション、およびデータチームを率いていました。エンドツーエンドのオーナーシップを持つことで、私のチームは、サイロを解消する優れたデータ分析プラットフォームを構築できただけでなく、トランザクションシステムのギャップに対処してデータをより適切に収集して活用できるようになりました。十分な説明責任を果たしながらも周囲にフェンスが増えないよう、インクルーシブな構造を作りましょう。 データを部門の所有物ではなく、組織全体の資産として扱う 多くの企業では、データサイロは組織のサイロによって厳重に守られています。多くの場合、それには意味があって、組織内のメンバーが特定のデータ要素の意味や変数、算出方法、パターンを理解して正しく使用できるようにしています。これをデータにアクセスできない理由にしないでください。むしろ、こうした「守護者」を「教育者」に変えましょう。各部門のデータ専門家に教育と支援の主導権を握ってもらい、全ての社員がデータを正しく使用して企業のデータリテラシーを高められるようにしましょう。 これらのサイロは、データの相関分析も妨げます。多くのケースで組織は、収益、コスト、在庫、および顧客フィードバックを別々に見ています。これは、営業、財務、オペレーション、およびカスタマーサポートがそれぞれ独自のデータセットを抱え込んで守っているためです。今日のデジタル世界では、組織はデータを利用して顧客体験を向上させ、より良い製品を生み出すために、相関関係を利用してさまざまな手段をより動的に見つけて適用する必要があります。データを「制限」するのではなく、データへの「アクセスを増やす」というゴールから始める、軽量なデータガバナンス構造を構築しましょう。 データを民主化する データドリブンカルチャーとは、データを使って大きな意思決定を行うことだけではありません。データドリブンカルチャーは、現場で働く従業員の、日々の多くの小さな意思決定を、データを使って行えるようにします。デジタルエコノミーではスピードが重要であり、データを使用して製品のアイデア、設計上の決定、仮説を迅速にテストすることで、ビジネスの俊敏性を高めることができます。 高頻度な意思決定でビジネス価値を生み出し続ける企業 は、HiPPO (最も給料の高い人の意見) に基づく意思決定をやめ、非中央集権型のデータドリブンな意思決定プロセスへ移行しています。 Epic Games 社と、世界中で 1 億 2500 万人以上のプレイヤーが集まる大成功を収めたゲーム「フォートナイト」を例にとってみましょう。Epic 社は AWS を使用してゲーマーの満足度やインタラクションに関する最新の情報を収集し、そのデータをゲームデザイナーに提供しています。ゲームデザイナーはこのデータを使用して、ゲームをするたびに手作りされているように感じられるマップの自動生成や、導入または廃止する武器の決定など、追加すべき新しい体験について決定を下します。これにより、ゲーマーの体験が向上し、ユーザーコミュニティのエンゲージメントが高まっています。 同じ言語を話す 言語は古くから文化の確立と維持において重要な役割を果たしてきました。共通の言語は、文化を形成する価値観、信念、アイデアを伝えるのに役立ちます。データドリブンカルチャーも例外ではありません。データドリブンカルチャーを築くためには、企業はデータに関する共通の語彙を作る必要があります。そのためには、まず全社が理解する主要なビジネス指標の定義から始めますが、その指標に反映される変数群も特定することになります。企業内の機能はさまざまな成功指標に基づいて測定されることが多いため、これは思ったよりはるかに困難です。 一貫性を保つには、企業全体が説明責任を持ち可視性もある主要な成果指標をいくつか作成します。次に、全体の成果に直接影響する機能ごとに、それらをより小さな指標に分解します。単に「できること」を測定するのではなく、「すべきこと」を測定してください。重要なのは、この指標のリストを短くすることです。それらを特定したら、共通の定義について合意し、全員がそれを理解していることを確認します。一貫性、正確性、およびそれらに関する教育を確保するための継続的なメカニズムを構築することが重要です。 まとめると、データドリブンカルチャーがうまくいくのは、上級管理職が関与し、中間管理職に権限が与えられ、現場従業員が活性化され、サイロが排除されたときです。データドリブンカルチャーは、客観性、透明性、そして革新性をもたらすため、楽しく働ける環境です。成功している組織は、データドリブンカルチャーを大規模に推進することで、データを市場における差別化要因とし、社内を統合しています。 — Ishit Twitter | LinkedIn | Blogs | Email このトピックについてさらに知りたい How to Build Data Capabilities , Ishit Vachhrajani In Search of Silver Bullets: Moving Beyond Dreaming of Data , Phil Le-Brun The CFO as Catalyst for the Data-Driven Enterprise , AWS Executive Insights The Power of the Data-Driven Enterprise , AWS Executive Insights Ishit Vachhrajani Ishit は、大企業の元 CXO と上級管理職で構成されるエンタープライズストラテジストのグローバルチームを率いています。エンタープライズストラテジストは、世界の大手企業の経営陣と提携して、クラウドによってスピードと俊敏性を高め、イノベーションを推進し、新しい運用モデルを形成する能力により、顧客のニーズにより多くの時間を費やすことができることを理解できるよう支援しています。AWS に入社する前、Ishit は A+E Networks の最高技術責任者として、クラウド、アーキテクチャ、アプリケーションと製品、データ分析、技術運用、サイバーセキュリティにわたるグローバルテクノロジーを担当していました。Ishitは、オペレーションコストを大幅に削減しながら、クラウドへの移行、アジリティ向上のための再編成、統一されたグローバルファイナンスシステムの実装、業界をリードするデータ分析プラットフォームの構築、グローバルなコンテンツ販売および広告販売製品の刷新など、A+E における大きな変革を主導しました。彼は以前、NBCUniversalおよびグローバルコンサルティング組織でリーダーシップポジションを歴任してきました。Ishit は、A+E Networks の「Create Great」と呼ばれる CEO 賞を含むいくつかの賞を受賞しています。彼は次世代のリーダーの指導に情熱を注いでおり、多くのピア・アドバイザリー・グループに参加しています。Ishit は、インドのニルマ工科大学で計装制御工学の学士号を取得し、学業成績により金メダルを獲得しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました (オリジナルは こちら 。)

みなさんこんにちは！ソリューションアーキテクトの多田です。 暑い夏がやってきましたね。皆様それぞれの夏を過ごされているかと思いますが、夏の暑さも吹き飛ばす、ホットなイベント AWS Builders Online Series が2024年7月18日(木) に開催されます。 >> AWS Builders Online Series のお申込みはコチラ AWS Builders Online Series はどんなイベント？ AWS Builders Online Series は、初心者を対象とした AWS の基礎を幅広く学ぶことができるオンラインイベントです。「初学者を対象とした」と書きましたが、既に AWS をご利用のお客様も、最新情報を取り入れ基礎から解説いたしますので、これまで触れたことのないサービスのキャッチアップにもってこいだと考えています。 今回の AWS Builders Online Series では、AWS 基礎、生成 AI、モダンアプリケーション開発の 3 つのテーマにフォーカスし、ゼロから学べるよう構成いたしました。デモを交えた分かりやすい説明により、すぐに実践に役立つ知識を習得していただきます。本イベントは、全てのセッションがライブ配信され、リアルタイムで皆様の質問に回答します。 モダンアプリケーション開発の基礎 7月1日からテーマごとに「 AWS 基礎 」「 生成 AI 実践入門 」とリレー形式で紹介しており、本記事では、 「モダンアプリケーション開発の基礎」 の5つのセッションについて紹介いたします！ 「モダンアプリケーション開発の基礎」のテーマは、コンテナ、サーバーレス、オブザーバビリティ、Webアプリ開発、SaaS の全 5 セッションで構成されております。モダンアプリケーション開発が必要とされる背景、そして各技術が解決する課題を理解することができます。説明パートに加えて、デモパートもご用意しているため、実際の画面を見ながら理解を深めやすい構成になっております。それでは各セッションの見どころをご紹介していきます。 14:40 – 15:10 BOS-08: はじめてのコンテナワークロード – AWS でのコンテナ活用の第一歩 概要: コンテナを使ったアプリケーション開発が注目されています。しかし、コンテナのメリットがいまいちわからない、使い方がわからないという方も多いのではないでしょうか。このセッションでは、コンテナの基本的な概念とメリットを解説した後、AWS 上のコンテナサービスの概要を説明します。デモを交えて紹介するため、コンテナ初心者の方でも AWS 上でのコンテナ利用イメージが掴めるはずです。（学べるサービス: Amazon ECS, Amazon EKS, AWS App Runner, Amazon ECR, AWS Fargate） 本セッションは以下のような方々に特におすすめとなっております。 コンテナに興味がある方 これからコンテナワークロードの構築を始める方 15:20 – 15:50 BOS-09: はじめてのサーバーレス – AWS Lambda でサーバーレスアプリケーション開発 概要: サーバーレスでは、サーバーを管理しなくてもアプリケーションを構築して実行できます。このセッションでは、AWS におけるサーバーレスアプリケーションを開発する方法をご紹介します。サーバーレスが小規模から始めて機能をすばやく追加できる方法をご覧ください。AWS Lambda、Amazon API Gateway、Amazon DynamoDB といったサーバーレスアプリケーションを開発するのに役立つ AWS サービスを紹介します。 本セッションは以下のような方々に特におすすめとなっております。 サーバーレスに興味のある方 サーバーレスという言葉を聞いたことがあるけれど何から始めれば良いのかわからない方 これからモダンなAWSの使い方へシフトしていきたいと考えている方 16:00 – 16:30 BOS-10: AWS ではじめるオブザーバビリティ – システムのどこで・何が・なぜ起こってるのかを理解する 概要: アプリケーションの障害や運用上の問題に直面した場合、ユーザに影響が及ぶ前に、迅速に問題を解決することが重要です。マイクロサービスなどの分散型アプリケーションの場合は構成が複雑化し、迅速な問題解決がさらに困難になります。本セッションではこのような複雑化するアプリケーションに対しても、システムの動作状況、パフォーマンス、健全性に関する洞察を得るために重要なオブザーバビリティの概要を解説した上で、AWS でオブザーバビリティをはじめる第一歩として Amazon CloudWatch や AWS X-Ray の活用方法をご紹介します。(学べるサービス: Amazon CloudWatch, AWS X-Ray) 本セッションは以下のような方々に特におすすめとなっております。 オブザーバビリティに興味のある方 アプリケーションの開発・運用に関わる方 これからAWSサービスを利用したオブザーバビリティの実践に取り組む方 16:40 – 17:10 BOS-11: AWS Amplify ではじめる Web アプリケーション開発 概要: Web アプリケーション開発では、実際にユーザーが触れる部分の開発以外にも、認証やストレージ、ホスティング、CI/CD など考慮しなければいけない要素が多岐にわたります。AWS Amplify はそういったバックエンド要素を統合できるサービスとなっており、AWS Amplify を活用することで効率的に環境を構築し開発に集中することができるようになります。本セッションでは、Web アプリケーション開発のプロセスを整理した上で AWS Amplify の概要や最新情報、活用方法についてご紹介します。(学べるサービス: AWS Amplify) 本セッションは以下のような方々に特におすすめとなっております。 開発を始めたばかりの開発者の方 開発に携わるプロダクトマネージャーやデザイナーの方 Web アプリケーションの開発方法や課題を再認識したい方 AWS Amplify に興味のある方 17:20 – 17:50 BOS-12: SaaS ビジネスモデルの理解と、AWS を用いたサービス価値向上のアプローチ 〜生成 AI に触れて〜 概要: Software as a Service (SaaS) とは、ソフトウェアの配信モデルであり、ビジネスモデルです。配信モデルに関しては、ブラウザからインターネット越しで利用できことを考えると想像しやすいかもしれないですが、ビジネスモデルと呼ばれるのはどのような点にあるのでしょうか？本セッションでは、SaaS というビジネスモデルの理解と、生成 AI がどのように SaaS にどのような価値をもたらすのかについて、ユースケースを交えながら説明したいと思います。(学べるサービス: SaaS 一般, Amazon Bedrock) 本セッションは以下のような方々に特におすすめとなっております。 SaaS に興味がある方 SaaS プロダクトの成長を考えている方 まとめ AWS Builders Online Series の「モダンアプリケーション開発の基礎」セッションについて見どころをご紹介してきました。コンテナ、サーバーレス、オブザーバビリティ、Webアプリ開発、SaaS とこれから AWS を始める方、最近始めたという方を中心に、お役に立つ内容がまとまっておりますのでぜひご覧いただけると幸いです。 >> AWS Builders Online Series のお申込みはコチラ このブログの筆者 多田　慎也 (Shinya Tada) ソリューションアーキテクト

組織は、広大なグローバルサプライチェーンを横断してサステナビリティコンプライアンスを維持するという複雑な課題に直面しています。従来の電子メールやバラバラなメッセージングツールを使用して、世界中のサプライヤーからデータを収集し、そのデータの正確性を監査することは非効率で間違いが発生しやすいです。組織が現代のサプライチェーン環境の中で舵取りする際、デジタルと物理的な変革を受け入れることは、レジリエンスを高め、コストを最適化し、持続可能な成長を促進するために不可欠です。また、サステナビリティの規制準拠と報告の要件に対応しつつ、既存のデータ収集プロセスを改善する必要があります。AWS データセンターハードウェアの規制コンプライアンスを検証する責任を負う Amazon の Global Trade and Product Compliance (GTPC) チームは、 AWS Supply Chain Sustainability を活用することで大きな成功を収めています。取引先とのやり取りが改善され、データ収集プロセスが合理化され、詳細なデータ要求コンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 現在の電子メールとマニュアルのアプローチには、以下のような課題があります。 データセキュリティの脆弱性：要件を守らないと、機密データが漏洩するリスクがあります。 分断された調整業務：別々のチームメンバーがサプライヤーからデータを要求すると、重複した要求、見落とされた要求、遅延した応答、非効率的な作業分担が発生します。 分断されたコミュニケーション：メールのスレッドでは、文書要求に関する一貫した会話を維持することが困難で、誤解とデータ取得の遅延が生じます。 メトリクスの欠如：文書収集の進捗状況やサプライヤーの応答時間などのメトリクスを追跡できないため、パフォーマンスの監視とプロセス改善が阻害されます。 AWS Supply Chain Sustainability は、すべてのサプライヤーおよび取引先から ESG データを要求、収集、監査するプロセスを簡素化します。製品ライフサイクルアセスメント、製品安全基準の証明書、使用される有害物質に関する報告書などの詳細情報を要求するデータ収集フォームを簡単に配布できます。サプライヤーがフォームに記入すると、その回答がセキュアで監査可能なリポジトリに収集されます。この合理化されたアプローチにより、メールスレッドやファイルフォルダに散在する規制対応データの課題が解消されます。排出量、材料、その他の規制データを集中化された場所でアクセスでき、レポート作成、監査、分析が効率化されます。 この集中型モデルは、データ保護を強化し、冗長なデータを排除し、柔軟なワークロード割り当てを可能にします。構造化されたコミュニケーションを促進して遅延を減らし、データ主導の最適化のための広範囲にわたる追跡を可能にします。AWS Supply Chain は、分断されたデータとプロセスを統一することで、信頼できる唯一の情報源を提供し、可視性、コラボレーション、および業務効率を向上させます。メール主導のプロセスを集中型のデータ収集と報告の仕組みに置き換えることで、運用効率、コンプライアンス順守、協力会社との関係を改善し、相互の成長と成功のためのエコシステムを育成します。 このブログ投稿では、GTPC が AWS Supply Chain Sustainability を導入して、サステナビリティコンプライアンス成果物の収集プロセスを改善した方法を説明し、この解決策の使用方法について順を追ったガイドを提供しています。 Amazon GTPC は大幅な手作業を排除 GTPC チームは、規制コンプライアンスのために AWS データセンターのハードウェアを検証し、サプライヤーおよびテストラボと協力して必須ドキュメントを収集しています。通常、数千件のコンプライアンス成果物を収集し、その数は年々大幅に増加すると予想されています。GTPC チームは AWS Supply Chain Sustainability を活用し大きな成功を収めています。 「GTPC は AWS Supply Chain Sustainability モジュールを使用して、AWS サプライヤーからのコンプライアンス成果物の収集を管理し、監査履歴を保持しています。Sustainability モジュールは効率的でユーザーフレンドリーなツールで、パートナーとの重複した連絡やデータリクエストを回避し、要求の最新状況を全チームに提供できます。さらに、サプライヤーは必要なすべてのコンプライアンス成果物を１つの画面で確認できるため、サプライヤーエクスペリエンスも向上します。」GTPC のシニアマネージャー、 Nishant Jain の言葉です。 取引先とのやり取りの改善、データ収集プロセスの合理化、詳細なデータ要求のコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC が AWS Supply Chain Sustainability を成功裏に導入したことは、コンプライアンスデータ収集の合理化、サプライヤーとの協力関係の強化、業務効率の向上において、この製品の有効性を示しています。これらの魅力的な利点により、自社のサステナビリティ報告とコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、GTPC と同様の成功を収めることができます。 次のセクションでは、AWS Supply Chain Sustainability のセットアップと使用開始の手順を説明し、サステナビリティデータ管理プロセスを変革する方法を順を追って紹介します。 前提条件 このブログ投稿では、あなたが前述のサービスの使用を理解しており、次の前提条件を満たしていることを前提としています: Amazon Web Services, Inc. (AWS) のアカウントをお持ちです。アカウントをお持ちでない場合は、 アカウント有効化ガイド に記載されている手順に従ってください。 AWS Supply Chain のアカウントも必要になります。まだお客様でない場合は、 AWS Supply Chain のウェブサイトをご覧いただき、詳細をご確認の上、サインアップしてください。 AWS Supply Chain Sustainability を活用してコンプライアンスを合理化 分かりやすくするため、このブログでは AWS Supply Chain Sustainability を利用する２種類のユーザータイプに言及しています。 要求者 とは、このケースでは GTPC のように、コンプライアンス文書プロセスを管理する担当者のことです。 パートナー とは、要求者から文書要求を完了する必要のある部品、材料、または商品を提供するサプライヤーやベンダーのことです。以下のセクションでは、要求者とパートナーの両方の役割について、定義されたユーザーエクスペリエンスと設定を概説しています。 サステナビリティダッシュボードは、要求者が取引先のオンボーディングおよびあらゆる成果物データリクエストの状況を確認できるメイン画面です。次のスクリーンショットにサンプルのダッシュボードが表示されています。 最初のページには、 Getting Started の概要と、主要な導入指標を含む Partner Overview セクションが含まれています。 Onboarding metrics は、段階別の取引先の参加状況を要約しています。 Data requests は、成果物収集リクエストの状況を要約しています。サンプルのスクリーンショットでは、リクエスト組織の取引先参加成功率は 38%、成果物データリクエストの回答率は 30%です。これにより、要求者は取引先の参加とリクエストのフォローアップ活動を優先付けすることができます。 要求者は、コンプライアンスレポート文書を要求するために、３つのステップに従います: 1) 取引先を招待する、2) 成果物データを要求する、3) 取引先の回答を確認する。 要求者のインタラクションおよびプロセス ステップ１: 取引先を招待する 要求者側では、取引先を 2 つの方法で追加できます。パートナー概要画面に直接情報を入力することで、取引先情報を手動で追加できます。また、取引先の情報が外部のサプライチェーン管理システムで管理されている場合は、サプライチェーンデータレイク (SCDL) に取引先の情報を取り込むこともできます。これらのオプションにより、新規および既存の取引先を柔軟に追加できます。追加後、取引先に対して成果物データリクエストを行うために、取引先を招待する必要があります。招待プロセスでは、取引先が AWS Supply Chain を通じた双方向通信を承認することを確認します。これにより、取引先のビジネスワークフローを簡素化した管理が可能になり、取引先が成果物収集リクエストを表示して応答するために必要となります。取引先の招待画面を以下に示します。 ステップ２: データリクエストを作成する 要求者側では、次のスクリーンショットに示すように、取引相手に送信するデータリクエストのタイプを選択できます。シンプルなレポートテンプレートを選択するか、前回のデータリクエストで保存したテンプレートを使用できます。データリクエストのタイプを選択すると、リクエスト名、説明、データリクエストの詳細などの主要なレポートパラメータを入力する必要があります。また、レスポンス形式を設定したり、取引相手に従ってもらう詳細なガイダンスの提供もできます。 ステップ３:取引先の回答を確認する 要求者としては、「サステナビリティ」ページの Data Request の下に、開始されたすべてのデータリクエストとその主要なマイルストーンを確認できます。次のスクリーンショットに示されています。リンクをクリックすると、特定のデータリクエストを選択し、取引先の提出内容を確認できます。成果物の有効性、リクエストの完全性を評価したり、追加のリクエストを行ったり、アプリケーションから直接追加情報を要求できます。 取引先のインタラクションおよびプロセス 次のセクションでは、取引先の役割とアプリケーションとの対話について説明します。取引先は、成果物収集リクエストに対して２つのステップで対応できます。 1) 要求者の招待を確認して承認する、2) データリクエストを確認して応答する。 ステップ１: 要求者の招待を確認して承認する 取引先として、AWS Supply Chain に参加し、データ収集の共同作業のための要求者の招待を受け入れるためのメールを受け取ります。その後、オンボーディングプロセスを完了することで、プロフィールを設定できます。オンボーディングが完了し、共同作業の招待を受け入れると、要求者に通知されます。要求者はデータ収集要求を送信できるようになります。 ステップ２: データリクエストを確認して応答する 取引先として、完了する必要があるすべてのデータリクエストの概要を示すダイジェストメールを受け取ります。次に、メールのリンクをクリックすると、成果物データリクエスト画面に接続され、保留中のリクエストをすべて表示できます。下図のように、成果物データリクエストページに直接移動して、オープンデータリクエストを表示し、必要な情報を提供できます。リクエストを拒否し、該当する理由コードの文書化もできます。要求者は、データリクエスト送信を確認し、すべての応答が完了した場合はワークフローを終了します。 サステナビリティのセットアップと構成に関する追加情報と詳細は、AWS Supply Chain ユーザーガイド に記載されています。 AWS Supply Chain Sustainability は、GTPC の課題に対処するために以下の利点を提供しました。 シームレスなコミュニケーション： AWS Supply Chain により、GTPC とそのサプライヤーおよび取引先間のシームレスなコミュニケーションが可能になり、深い対話とタイムリーな対応が可能になりました。 可視性の向上： GTPC は作業の重複を最小限に抑え、リソースの活用を最大化することで、ワークフロー内で時間を節約することができました。この可視性により、透明性と説明責任が向上し、持続可能な実践の改善案が特定され、規制の非準拠リスクが軽減されました。 監査可能なコミュニケーション：AWS Supply Chain により、GTPC とその取引先間の監査可能なコミュニケーションが容易になり、やり取りと交換の明確な記録が確保されました。 セキュリティコンプライアンスの改善： AWS Supply Chain は、アプリケーションを通じて重要な成果物の交換を効果的に簡素化し、データを安全かつ確実に転送する方法を提供しました。GTPC はデータの監査可能な記録を持ち、データ収集と検証プロセスの前例のない可視性を獲得しました。 パフォーマンス追跡：GTPC は成果物収集の進捗状況とサプライヤーの応答時間を追跡し、必要に応じてデータ要求を調整することができました。このようなプロセスの可視性と制御により、GTPC は規制コンプライアンスの進捗に影響を与える可能性のある取引先ネットワークの変更、課題、問題を認識することができました。 まとめ 消費者や規制当局が透明性と説明責任を求める中、組織は自社の事業活動とサプライチェーンにわたり、正確かつ包括的なサステナビリティデータを収集する圧力が高まっています。取引先ネットワークから信頼できるデータを入手することは、意味のある分析し、戦略的な意思決定に役立て、進化するサステナビリティ基準とコンプライアンスに準拠するために不可欠です。しかし、多くの企業は非効率的な手作業のプロセスとバラバラなデータソースに苦しんでいます。 AWS Supply Sustainability を活用することで、Amazon の Global Trade and Product Compliance (GTPC) チームは、コンプライアンスデータ収集プロセスを合理化することに成功しました。毎年数千の成果物を収集する責任がある GTPC は、集中型の自動化ソリューションを採用することで、業務効率の大幅な改善を実現しました。取引先とのやり取りの改善、データ収集の合理化、詳細なコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC の成功は、AWS Supply Chain Sustainability がサステナビリティデータ管理プロセスに変革的な影響を与えることを示しています。この解決策の中央集権的アプローチは、散在するデータ、分断された通信、可視性の欠如に関連する課題を排除し、同時にサプライヤーとの協力と運用効率を向上させます。これらの魅力的な利点により、サステナビリティ報告およびコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、同様の改善を推進できます。 AWS Supply Chain を訪問して、持続可能なビジネス慣行を通じた相互の成長と成功を促進するエコシステムの詳細を学びましょう。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン500企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。

組織は、広大なグローバルサプライチェーンを横断してサステナビリティコンプライアンスを維持するという複雑な課題に直面しています。従来の電子メールやバラバラなメッセージングツールを使用して、世界中のサプライヤーからデータを収集し、そのデータの正確性を監査することは非効率で間違いが発生しやすいです。組織が現代のサプライチェーン環境の中で舵取りする際、デジタルと物理的な変革を受け入れることは、レジリエンスを高め、コストを最適化し、持続可能な成長を促進するために不可欠です。また、サステナビリティの規制準拠と報告の要件に対応しつつ、既存のデータ収集プロセスを改善する必要があります。AWS データセンターハードウェアの規制コンプライアンスを検証する責任を負う Amazon の Global Trade and Product Compliance (GTPC) チームは、 AWS Supply Chain Sustainability を活用することで大きな成功を収めています。取引先とのやり取りが改善され、データ収集プロセスが合理化され、詳細なデータ要求コンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 現在の電子メールとマニュアルのアプローチには、以下のような課題があります。 データセキュリティの脆弱性：要件を守らないと、機密データが漏洩するリスクがあります。 分断された調整業務：別々のチームメンバーがサプライヤーからデータを要求すると、重複した要求、見落とされた要求、遅延した応答、非効率的な作業分担が発生します。 分断されたコミュニケーション：メールのスレッドでは、文書要求に関する一貫した会話を維持することが困難で、誤解とデータ取得の遅延が生じます。 メトリクスの欠如：文書収集の進捗状況やサプライヤーの応答時間などのメトリクスを追跡できないため、パフォーマンスの監視とプロセス改善が阻害されます。 AWS Supply Chain Sustainability は、すべてのサプライヤーおよび取引先から ESG データを要求、収集、監査するプロセスを簡素化します。製品ライフサイクルアセスメント、製品安全基準の証明書、使用される有害物質に関する報告書などの詳細情報を要求するデータ収集フォームを簡単に配布できます。サプライヤーがフォームに記入すると、その回答がセキュアで監査可能なリポジトリに収集されます。この合理化されたアプローチにより、メールスレッドやファイルフォルダに散在する規制対応データの課題が解消されます。排出量、材料、その他の規制データを集中化された場所でアクセスでき、レポート作成、監査、分析が効率化されます。 この集中型モデルは、データ保護を強化し、冗長なデータを排除し、柔軟なワークロード割り当てを可能にします。構造化されたコミュニケーションを促進して遅延を減らし、データ主導の最適化のための広範囲にわたる追跡を可能にします。AWS Supply Chain は、分断されたデータとプロセスを統一することで、信頼できる唯一の情報源を提供し、可視性、コラボレーション、および業務効率を向上させます。メール主導のプロセスを集中型のデータ収集と報告の仕組みに置き換えることで、運用効率、コンプライアンス順守、協力会社との関係を改善し、相互の成長と成功のためのエコシステムを育成します。 このブログ投稿では、GTPC が AWS Supply Chain Sustainability を導入して、サステナビリティコンプライアンス成果物の収集プロセスを改善した方法を説明し、この解決策の使用方法について順を追ったガイドを提供しています。 Amazon GTPC は大幅な手作業を排除 GTPC チームは、規制コンプライアンスのために AWS データセンターのハードウェアを検証し、サプライヤーおよびテストラボと協力して必須ドキュメントを収集しています。通常、数千件のコンプライアンス成果物を収集し、その数は年々大幅に増加すると予想されています。GTPC チームは AWS Supply Chain Sustainability を活用し大きな成功を収めています。 「GTPC は AWS Supply Chain Sustainability モジュールを使用して、AWS サプライヤーからのコンプライアンス成果物の収集を管理し、監査履歴を保持しています。Sustainability モジュールは効率的でユーザーフレンドリーなツールで、パートナーとの重複した連絡やデータリクエストを回避し、要求の最新状況を全チームに提供できます。さらに、サプライヤーは必要なすべてのコンプライアンス成果物を１つの画面で確認できるため、サプライヤーエクスペリエンスも向上します。」GTPC のシニアマネージャー、 Nishant Jain の言葉です。 取引先とのやり取りの改善、データ収集プロセスの合理化、詳細なデータ要求のコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC が AWS Supply Chain Sustainability を成功裏に導入したことは、コンプライアンスデータ収集の合理化、サプライヤーとの協力関係の強化、業務効率の向上において、この製品の有効性を示しています。これらの魅力的な利点により、自社のサステナビリティ報告とコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、GTPC と同様の成功を収めることができます。 次のセクションでは、AWS Supply Chain Sustainability のセットアップと使用開始の手順を説明し、サステナビリティデータ管理プロセスを変革する方法を順を追って紹介します。 前提条件 このブログ投稿では、あなたが前述のサービスの使用を理解しており、次の前提条件を満たしていることを前提としています: Amazon Web Services, Inc. (AWS) のアカウントをお持ちです。アカウントをお持ちでない場合は、 アカウント有効化ガイド に記載されている手順に従ってください。 AWS Supply Chain のアカウントも必要になります。まだお客様でない場合は、 AWS Supply Chain のウェブサイトをご覧いただき、詳細をご確認の上、サインアップしてください。 AWS Supply Chain Sustainability を活用してコンプライアンスを合理化 分かりやすくするため、このブログでは AWS Supply Chain Sustainability を利用する２種類のユーザータイプに言及しています。 要求者 とは、このケースでは GTPC のように、コンプライアンス文書プロセスを管理する担当者のことです。 パートナー とは、要求者から文書要求を完了する必要のある部品、材料、または商品を提供するサプライヤーやベンダーのことです。以下のセクションでは、要求者とパートナーの両方の役割について、定義されたユーザーエクスペリエンスと設定を概説しています。 サステナビリティダッシュボードは、要求者が取引先のオンボーディングおよびあらゆる成果物データリクエストの状況を確認できるメイン画面です。次のスクリーンショットにサンプルのダッシュボードが表示されています。 最初のページには、 Getting Started の概要と、主要な導入指標を含む Partner Overview セクションが含まれています。 Onboarding metrics は、段階別の取引先の参加状況を要約しています。 Data requests は、成果物収集リクエストの状況を要約しています。サンプルのスクリーンショットでは、リクエスト組織の取引先参加成功率は 38%、成果物データリクエストの回答率は 30%です。これにより、要求者は取引先の参加とリクエストのフォローアップ活動を優先付けすることができます。 要求者は、コンプライアンスレポート文書を要求するために、３つのステップに従います: 1) 取引先を招待する、2) 成果物データを要求する、3) 取引先の回答を確認する。 要求者のインタラクションおよびプロセス ステップ１: 取引先を招待する 要求者側では、取引先を 2 つの方法で追加できます。パートナー概要画面に直接情報を入力することで、取引先情報を手動で追加できます。また、取引先の情報が外部のサプライチェーン管理システムで管理されている場合は、サプライチェーンデータレイク (SCDL) に取引先の情報を取り込むこともできます。これらのオプションにより、新規および既存の取引先を柔軟に追加できます。追加後、取引先に対して成果物データリクエストを行うために、取引先を招待する必要があります。招待プロセスでは、取引先が AWS Supply Chain を通じた双方向通信を承認することを確認します。これにより、取引先のビジネスワークフローを簡素化した管理が可能になり、取引先が成果物収集リクエストを表示して応答するために必要となります。取引先の招待画面を以下に示します。 ステップ２: データリクエストを作成する 要求者側では、次のスクリーンショットに示すように、取引相手に送信するデータリクエストのタイプを選択できます。シンプルなレポートテンプレートを選択するか、前回のデータリクエストで保存したテンプレートを使用できます。データリクエストのタイプを選択すると、リクエスト名、説明、データリクエストの詳細などの主要なレポートパラメータを入力する必要があります。また、レスポンス形式を設定したり、取引相手に従ってもらう詳細なガイダンスの提供もできます。 ステップ３:取引先の回答を確認する 要求者としては、「サステナビリティ」ページの Data Request の下に、開始されたすべてのデータリクエストとその主要なマイルストーンを確認できます。次のスクリーンショットに示されています。リンクをクリックすると、特定のデータリクエストを選択し、取引先の提出内容を確認できます。成果物の有効性、リクエストの完全性を評価したり、追加のリクエストを行ったり、アプリケーションから直接追加情報を要求できます。 取引先のインタラクションおよびプロセス 次のセクションでは、取引先の役割とアプリケーションとの対話について説明します。取引先は、成果物収集リクエストに対して２つのステップで対応できます。 1) 要求者の招待を確認して承認する、2) データリクエストを確認して応答する。 ステップ１: 要求者の招待を確認して承認する 取引先として、AWS Supply Chain に参加し、データ収集の共同作業のための要求者の招待を受け入れるためのメールを受け取ります。その後、オンボーディングプロセスを完了することで、プロフィールを設定できます。オンボーディングが完了し、共同作業の招待を受け入れると、要求者に通知されます。要求者はデータ収集要求を送信できるようになります。 ステップ２: データリクエストを確認して応答する 取引先として、完了する必要があるすべてのデータリクエストの概要を示すダイジェストメールを受け取ります。次に、メールのリンクをクリックすると、成果物データリクエスト画面に接続され、保留中のリクエストをすべて表示できます。下図のように、成果物データリクエストページに直接移動して、オープンデータリクエストを表示し、必要な情報を提供できます。リクエストを拒否し、該当する理由コードの文書化もできます。要求者は、データリクエスト送信を確認し、すべての応答が完了した場合はワークフローを終了します。 サステナビリティのセットアップと構成に関する追加情報と詳細は、AWS Supply Chain ユーザーガイド に記載されています。 AWS Supply Chain Sustainability は、GTPC の課題に対処するために以下の利点を提供しました。 シームレスなコミュニケーション： AWS Supply Chain により、GTPC とそのサプライヤーおよび取引先間のシームレスなコミュニケーションが可能になり、深い対話とタイムリーな対応が可能になりました。 可視性の向上： GTPC は作業の重複を最小限に抑え、リソースの活用を最大化することで、ワークフロー内で時間を節約することができました。この可視性により、透明性と説明責任が向上し、持続可能な実践の改善案が特定され、規制の非準拠リスクが軽減されました。 監査可能なコミュニケーション：AWS Supply Chain により、GTPC とその取引先間の監査可能なコミュニケーションが容易になり、やり取りと交換の明確な記録が確保されました。 セキュリティコンプライアンスの改善： AWS Supply Chain は、アプリケーションを通じて重要な成果物の交換を効果的に簡素化し、データを安全かつ確実に転送する方法を提供しました。GTPC はデータの監査可能な記録を持ち、データ収集と検証プロセスの前例のない可視性を獲得しました。 パフォーマンス追跡：GTPC は成果物収集の進捗状況とサプライヤーの応答時間を追跡し、必要に応じてデータ要求を調整することができました。このようなプロセスの可視性と制御により、GTPC は規制コンプライアンスの進捗に影響を与える可能性のある取引先ネットワークの変更、課題、問題を認識することができました。 まとめ 消費者や規制当局が透明性と説明責任を求める中、組織は自社の事業活動とサプライチェーンにわたり、正確かつ包括的なサステナビリティデータを収集する圧力が高まっています。取引先ネットワークから信頼できるデータを入手することは、意味のある分析をし、戦略的な意思決定に役立て、進化するサステナビリティ基準とコンプライアンスに準拠するために不可欠です。しかし、多くの企業は非効率的な手作業のプロセスとバラバラなデータソースに苦しんでいます。 AWS Supply Sustainability を活用することで、Amazon の Global Trade and Product Compliance (GTPC) チームは、コンプライアンスデータ収集プロセスを合理化することに成功しました。毎年数千の成果物を収集する責任がある GTPC は、集中型の自動化ソリューションを採用することで、業務効率の大幅な改善を実現しました。取引先とのやり取りの改善、データ収集の合理化、詳細なコンプライアンス追跡により、 GTPC は年間約 3,000 時間の業務時間を節約できるようになる見込みです。 GTPC の成功は、AWS Supply Chain Sustainability がサステナビリティデータ管理プロセスに変革的な影響を与えることを示しています。この解決策の中央集権的アプローチは、散在するデータ、分断された通信、可視性の欠如に関連する課題を排除し、同時にサプライヤーとの協力と運用効率を向上させます。これらの魅力的な利点により、サステナビリティ報告およびコンプライアンス要件に対して AWS Supply Chain Sustainability を採用することで、同様の改善を推進できます。 AWS Supply Chain を訪問して、持続可能なビジネス慣行を通じた相互の成長と成功を促進するエコシステムの詳細を学びましょう。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン 500 企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。

本稿では株式会社NTTドコモ（以下、DOCOMO）において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 全４回の内容は以下からアクセスできますので、ご興味のある回をご覧いただければ幸いです。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜 第四回　AWSでのライブ配信アーキテクチャ 第四回　AWSでのライブ配信アーキテクチャ 1.はじめに 第四回では、Lemino のライブ配信について、配信基盤を AWS Media Services やマネージドサービスで再構築について説明します。新たな映像配信基盤は、ボクシングの世界戦など注目度の高いライブ配信を支え、ユーザーの獲得に貢献し、アクティブユーザー数（MAU）は、サービス開始から 3 か月で約 7 倍の 500 万に達しました。 2.基本的な配信基盤のアーキテクチャ Lemino では、VOD の配信だけでなく多種多様なライブ配信を複数同時に実施することが可能です。ライブ配信の最大チャンネル起動実績も 30 に達し、2024 年には最大 50 チャンネルまで拡張する予定で、ライブ配信の規模はさらに拡大する見込みです。 これを可能にしているのは、 AWS Media Services です。 Lemino の担当者が初めて AWS Media Service に触れたのは、約4年前のハンズオンがきっかけです。２日間のハンズオンで一通りの配信に必要なクラウドのマネージドサービスを学び、そこからオンプレミスで培った映像の技術を用いて、大規模な配信に耐える構成を作り上げてきました。(参考ハンズオン： AWSで動画配信を始めよう ) AWS Media Services では、Multi-AZ による冗長化された信頼性の高いサービスをソフトウェア、ハードウェアの管理をすることなく、マネージドサービスで活用することができます。従量課金体系であるため、ライブ配信毎にチャンネルを新規作成しライブ終了後に削除することで、ライブ配信時以外の料金発生を抑え費用を最小限に抑えることが可能です。加えて、東京リージョン・大阪リージョン・ソウルリージョンで同じAWSのマネージメントコンソールや CLI などを使って、配信の環境を整えることができるため、マルチリージョン構成を容易に実現することができます。 こうした可用性の設計は Reference architecture についての AWS Blog が用意されているため、参考に設計しています。 Lemino では、iPhone や Android スマートフォンや、タブレット、パソコン、スマートテレビ・レコーダーなど様々な機種に対応しておりますが、これに対応するには、Apple HLS 、DASH-ISO などの形式で出力し、適切な DRM 設定を行う必要があります。DRM についても Secure Packager and Encoder Key Exchange (SPEKE) を活用して利用できます。 参考： SPEKEとは？ 配信の内容によっては、タイムシフト表示を有効化したり Live コンテンツをアーカイブ配信のために、VOD に変換する必要があります。 AWS Elemental MediaPackage はこうした必要な機能をサポートし、ボクシングの世界戦のような大規模配信でもオリジンとして機能するスケーラビリティを持っています。 リアルタイムエンコーダは AWS Elemental MediaLive を活用して配信仕様に従ったビデオ・オーディオのエンコード出力を行っています。MediaLive は Amazon S3 に事前に保存された MP4 などの形式の映像ファイルからの配信を行うことが可能であるため、この機能を活用し擬似ライブのような配信にも対応しています。 また、エンコーダへの映像入力に関しては AWS Elemental MediaConnect を組み合わせて利用することで、さまざまなロケーションから安定した映像ソースの伝送を行っています。例えば、大規模なスポーツ会場から Live を配信する場合は、現地のオンプレミス機材から映像伝送を行う必要がありますが、パケットロスを防ぐため RTP+FEC や RTMP 、 Zixi など様々なプロトコルで動画を伝送する必要があります。 MediaConnect と MediaLive を利用することでこれらの映像伝送を簡単に行うことができます。 他にも、小規模な練習場のような大規模なオンプレミス機器の設置が困難な場所からクラウドに動画を配信する場合、 AWS Elemental Link という僅か 450 g の小型の専用デバイスを現地に持って行って配信に活用しています。AWS Elemental Link は電源をつなぐ、ネットワークと接続する、カメラからの映像音声を SDI あるいは HDMI で接続する、この3つだけで、AWS Elemental MediaLive に高品質な映像を伝送することが可能です。この映像伝送にはパケットロスの耐性の高い Zixi プロトコルが利用されます。動画配信の仕組みに精通したエンジニアでなくとも現地から映像を送ることができるため、エンジニアが配信都度現地に行く必要がないため、配信にかかる作業負担が大きく軽減されています。 最近の配信では、無料の広告付き配信を行っています。この配信では広告をあらかじめ映像にうめ込んだり、映像の最初に広告を入れるのではなく、Live の途中で、できるだけ試聴体験を邪魔しないように広告を入れる SSAI（Server Side Ad Insertion） によるミッドロール広告も活用を始めています。これらの広告配信は AWS Elemental MediaTailor で短期間で付け加えることができ、配信の特性ごとに一番良い方法で配信できるよう現在も調整を続けています。 Lemino では、こうした多様なライブの運用工数も最適化しています。ライブ配信の構成を AWS で統一したことで、 AWS Media Services を簡単にデプロイできる仕組みを AWS の API を使用して構築し、エンジニアが関与せずともライブ担当者のみで定型的な配信環境構築作業を実行できるようになりました。 3.配信時の CDN の構成について Lemino ではNTT DOCOMOのモバイルネットワーク・ CDN を活用しつつ、 Amazon CloudFront や他社の CDN も活用できるようにすることで、大規模配信の際に必要となる帯域を事前に調整しています。これを実現しているのが、 Amazon Route53 と Amazon CloudFront の Origin Shield です。 CDN-A / CDN-B / CDN-C を活用する場合、３つの CDN のオリジンに Origin Shield を有効化した CloudFront を活用します。そうすることで、CloudFront はすべてのオリジンフェッチを Origin Shield を介してルーティングし、コンテンツが Origin Shield のキャッシュにまだ保存されていない場合にのみオリジンにリクエストを送信します。これは、オリジンの負荷を下げることにつながり、大規模配信時もオリジンへの過負荷によって、配信に影響が出るリスクを低減します。また、 Lambda@Edge を Origin Shield とともに使用して、動的なマニュフェストの変換なども可能にしています。 エンドユーザーからのアクセスを CDN-A / CDN-B / CDN-C にどのように割り振るかを決定するのは Amazon Route53 です。 加重ルーティングを活用して普段はCDN-A 7割、CDN-B 2割、CDN-C 1割のような割合で配信しておいて、CDN-C に異常があった場合、加重の比率を変更することで、CDN の障害から回復することが可能です。また、IPベースのルーティングも併用することで、所定のIPアドレスからは所定のネットワークを経由して映像を配信し、効率的にライブ配信を行なっています。 4.まとめ 昨今の映像サービスでは、様々な場所から様々な形式で入手した映像を、多種多様なデバイスに安定して配信することが配信規模に関わらず求められます。AWSを利用することで最小限の費用と労力でこれらの実現が可能です。今後も、AWS のMedia Servicesの新機能もうまく活用しつつ、Lemino の配信をよりよくする挑戦を続けていきます。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　岸 里奈 株式会社NTTドコモで提供している映像配信サービス『Lemino』のライブ・VOD・広告含めた映像配信システムの開発を担当しているエンジニア。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和崎美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様のAWS 活用を支援していますが、Observability についてはAWS 社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Service のご支援にも手を広げるなど、幅広い AWS 活用をご支援しています。

re:Invent 2023 のニュースブログ記事 で、 Amazon S3 Express One Zone をご紹介しました。これは、最も頻繁にアクセスされるデータや、レイテンシーの影響を受けやすいアプリケーションのために、一貫した 1 桁ミリ秒のデータアクセスを提供するために特別に設計された、高性能な単一アベイラビリティーゾーン (AZ) ストレージクラスです。これは要求の厳しいアプリケーションに適しており、S3 Standard と比較して最大 10 倍優れたパフォーマンスを実現するように設計されています。S3 Express One Zone は、S3 ディレクトリバケット を使用して、単一の AZ にオブジェクトを保存します。 7月9日より、S3 Express One Zone は AWS CloudTrail データイベントログ記録をサポートするようになり、既にサポートされていた CreateBucket や DeleteBucket などの バケットレベル のアクションに加えて、 PutObject 、 GetObject 、 DeleteObject などのすべてのオブジェクトレベルのオペレーションをモニタリングできるようになりました。これにより、ガバナンスとコンプライアンスの監査が可能になり、S3 Standard ストレージクラスと比較して 50% 低い S3 Express One Zone のリクエストコストを活用できるようになります。 この新しい機能を使用すると、どの S3 Express One Zone オブジェクトが作成、読み取り、更新、または削除されたかを迅速に判断し、API コールのソースを特定できます。不正な S3 Express One Zone オブジェクトへのアクセスを検出した場合は、アクセスを制限するためにすぐにアクションを実行できます。さらに、 CloudTrail 統合 を Amazon EventBridge と併用して、データイベントによってトリガーされるルールベースのワークフローを作成することもできます。 Amazon S3 Express One Zone の CloudTrail データイベントログ記録の使用 Amazon S3 コンソール で開始します。 ディレクトリバケットの作成 のステップに従って、S3 バケットを作成し、バケットタイプとして [ディレクトリ] 、 [アベイラビリティーゾーン] として [apne1-az4] を選択します。 [ベース名] に s3express-one-zone-cloudtrail と入力すると、該当のアベイラビリティーゾーンのアベイラビリティーゾーン ID を含むサフィックスが自動的に追加され、最終的な名前が作成されます。最後に、 [データは単一のアベイラビリティーゾーンに保存されます] のチェックボックスをオンにして同意し、 [バケットを作成] を選択します。 S3 Express One Zone のデータイベントログ記録を有効にするために、 CloudTrail コンソール に移動します。名前を入力して、S3 ディレクトリバケットのイベントを追跡する CloudTrail 証跡を作成 します。 [ステップ 2: ログイベントを選択する] で、 [高度なイベントセレクターが有効になっています] が選択された状態で [データイベント] を選択します。 [データイベントタイプ] で、 [S3 Express] を選択します。すべての S3 ディレクトリバケットのデータイベントを管理するには、 [ログセレクターテンプレート] として [すべてのイベントをログに記録] を選択できます。 ただし、イベントデータストアでは、S3 ディレクトリバケット s3express-one-zone-cloudtrail--apne1-az4--x-s3 のイベントのみをログに記録したいと考えています。この場合、 [ログセレクターテンプレート] として [カスタム] を選択し、ディレクトリバケットの ARN を指定します。詳細については、「 Filtering data events by using advanced event selectors 」に関するドキュメントをご覧ください。 最後に、 [ステップ 3: 確認および作成する] に進みます。これで、CloudTrail によるログ記録が有効になりました。 S3 Express One Zone の CloudTrail データイベントログ記録の操作: S3 コンソール を使用して、S3 ディレクトリバケットにファイルをアップロードおよびダウンロードします。 AWS CLI を使用して、 Put_Object と Get_Object を送信します。 $ aws s3api put-object --bucket s3express-one-zone-cloudtrail--apne1-az4--x-s3 \ --key cloudtrail_test \ --body cloudtrail_test.txt $ aws s3api get-object --bucket s3express-one-zone-cloudtrail--apne1-az4--x-s3 \ --key cloudtrail_test response.txt CloudTrail は、ログファイルを gzip アーカイブで S3 バケットに公開し、バケット名、アカウント ID、リージョン、日付に基づいて 階層的に 整理します。AWS CLI を使用して、証跡に関連付けられたバケットを一覧表示し、テストを実行した日付のログファイルを取得します。 $ aws s3 ls s3://aws-cloudtrail-logs-MY-ACCOUNT-ID-3b49f368/AWSLogs/MY-ACCOUNT-ID/CloudTrail/ap-northeast-1/2024/07/01/ 次の 4 つのファイル名が取得されます。2 つはコンソールテストから、もう 2 つは CLI テストから取得されます: 2024-07-05 20:44:16 317 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2044Z_lzCPfDRSf9OdkdC1.json.gz 2024-07-05 20:47:36 387 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2047Z_95RwiqAHCIrM9rcl.json.gz 2024-07-05 21:37:48 373 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T2137Z_Xk17zhf0cTY0N5bH.json.gz 2024-07-05 21:42:44 314 MY-ACCOUNT-ID_CloudTrail_ap-northeast-1_20240705T21415Z_dhyTsSb3ZeAhU6hR.json.gz これらのファイルで PutObject イベントを検索してみましょう。最初のファイルを開くと、 PutObject イベントタイプが表示されます。ご承知のとおり、ブラウザの S3 コンソール経由で 1 回、CLI を使用して 1 回、合計 2 回のアップロードを実行したばかりです。API コールを実行したソースのタイプである userAgent 属性はブラウザを参照するため、このイベントは S3 コンソールを使用したアップロードを参照します。CloudTrail イベントの詳細については、「 Understanding CloudTrail events 」のドキュメントをご覧ください。 {...}, "eventTime": "2024-07-05T20:44:16Z", "eventSource": "s3express.amazonaws.com", "eventName": "PutObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} ここで、AWS CLI を使用して送信された PutObject コマンドに対応するイベントの 3 つ目のファイルを確認すると、 userAgent 属性にわずかな違いがあることがわかります。この場合、これは AWS CLI を参照しています。 {...}, "eventTime": "2024-07-05T21:37:19Z", "eventSource": "s3express.amazonaws.com", "eventName": "PutObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "aws-cli/2.17.9 md/awscrt#0.20.11 ua/2.0 os/linux#5.10.218-208.862.amzn2.x86_64 md/arch#x86_64 lang/python#3.11.8 md/pyimpl#CPython cfg/retry-mode#standard md/installer#exe md/distrib#amzn.2 md/prompt#off md/command#s3api.put-object", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} では、2 つ目のファイルの GetObject イベントを見てみましょう。イベントタイプが GetObject であり、 userAgent がブラウザを参照していることがわかります。つまり、このイベントは S3 コンソールを使用したダウンロードを参照しています。 {...}, "eventTime": "2024-07-05T20:47:41Z", "eventSource": "s3express.amazonaws.com", "eventName": "GetObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} 最後に、AWS CLI から送信した GetObject コマンドの詳細とともに、4 つ目のファイルのイベントを表示します。 eventName と userAgent が想定どおりであることがわかります。 {...}, "eventTime": "2024-07-05T21:42:04Z", "eventSource": "s3express.amazonaws.com", "eventName": "GetObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "MY-IP", "userAgent": "aws-cli/2.17.9 md/awscrt#0.20.11 ua/2.0 os/linux#5.10.218-208.862.amzn2.x86_64 md/arch#x86_64 lang/python#3.11.8 md/pyimpl#CPython cfg/retry-mode#standard md/installer#exe md/distrib#amzn.2 md/prompt#off md/command#s3api.put-object", "requestParameters": { ... }, "responseElements": {...}, "additionalEventData": {...}, ... "resources": [ { "type": "AWS::S3Express::Object", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3/cloudtrail_example.png" }, { "accountId": "MY-ACCOUNT-ID", "type": "AWS::S3Express::DirectoryBucket", "ARN": "arn:aws:s3express:ap-northeast-1:MY-ACCOUNT-ID:bucket/s3express-one-zone-cloudtrail--apne1-az4--x-s3" } ], {...} 知っておくべきこと 開始方法 – CloudTrail コンソール、CLI、または SDK を使用して、S3 Express One Zone のために CloudTrail データイベントログ記録を有効にできます。 リージョン – CloudTrail データイベントログ記録は、 S3 Express One Zone が現在利用可能なすべての AWS リージョン でご利用いただけます。 アクティビティログ記録 – S3 Express One Zone の CloudTrail データイベントログ記録を使用すると、 PutObject 、 GetObject 、 DeleteObject などのオブジェクトレベルのアクティビティや、CreateBucket や DeleteBucket などのバケットレベルのアクティビティをログ記録できます。 料金 – S3 ストレージクラスと同様に、ログ記録されたイベントの数とログを保持する期間に基づいて、CloudTrail での S3 Express One Zone データイベントのログ記録についての料金をお支払いいただきます。詳細については、 AWS CloudTrail の料金 ページをご覧ください。 S3 Express One Zone のために CloudTrail データイベントログ記録を有効にすると、高性能ストレージのガバナンスとコンプライアンスを簡素化できます。この新機能の詳細については、「 S3 ユーザーガイド 」をご覧ください。 – Eli. 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの 新谷です。2024 年 6 月 20 、21 日に AWS Summit Japan が開催され、 2 日間で 150 以上のセッションと 250 以上のブース展示が行われました。その中には、高い信頼性要件に対し工夫を凝らしながら耐障害性の高いワークロードを構築したお客様事例セッションもありました。また、AWS セッションや AWS Village のブース展示においても、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2024 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 事例セッションより 日本最大口座数を保有する SBI証券のオンライン取引システムの AWS マイグレーション 株式会社SBI証券/ SBIシンプレクス・ソリューションズ株式会社 様 日本最大の口座数を保有する SBI証券様は、新 NISA やゼロ革命 (取引手数料無料化) により拡大するトランザクションに備えて、 OMS（Order Management System） およびその関連するシステムを AWS へマイグレーションし、ビジネスの急激な拡大に対応可能なプラットフォームと顧客への継続的な安定した環境を提供することを実現されました。 AWS の SA とともに金融のベストプラクティスをリファレンスとした、低遅延かつ高い可用性と高負荷トランザクションによる高いパフォーマンス性能が求められるミッションクリティカルなシステムの移行についてお話頂きました。 Oracle Exadata の RDS for Oracle 移行によるフルクラウド化 auコマース＆ライフ株式会社 様 auコマース&amp;ライフ様は au Payマーケットのアプリケーションを AWS 移行するとともにアーキテクチャ刷新を進めていましたが、オンプレミスに残る Oracle Exadata と接続する AWS Direct Connect が単一障害点となっていました。実際にスイッチ故障により長時間停止が発生し、サービス継続性に対するリスクが顕在化したことから、オンプレミスの Oracle Exadata から Amazon RDS for Oracle (Enterprise Edition) への移行を決定しました。移行後は Performance Insights の可視化で性能改善に繋げやすくなった点や、データセンターとの通信レイテンシが低減されお客様体験向上にも繋がった点を効果として挙げています。今後は信頼性とコストのバランスを考慮しながらデータベース含めたマイクロサービス化を推進していくそうです。 AWS セッションより 金融機関様のマルチリージョン事例からクラウドのレジリエンスを紐解く AWS ソリューションアーキテクト 山北 嶺より、金融機関様のレジリエンス事例と技術的な検討ポイントを解説するセッションをお届けしました。Capital One 様ではビジネスチームが利用者目線で目標とする可用性を検討した上で、カード限度額引き上げ処理には Amazon Aurora グローバルデータベース、カード決済処理には Amazon DynamoDB グローバルテーブルを採用するという要件に合わせたデータストア戦略を選択しています。また、住信SBIネット銀行様は、インターネットバンキングにマルチリージョンアーキテクチャを採用し、Amazon Aurora グローバルデータベースの昇格を含めてリージョン切換えのオペレーションを自動化していることを解説しました。 AWS でレジリエントな分散システムを構築するためのデザインパターン AWS ソリューションアーキテクト 新谷 歩生より、 AWS 上でレジリエンスを高めるためのアプローチやデザインパターンを解説するセッションをお届けしました。アプリケーションを機能単位で分割することで、障害時の影響範囲を小さくできます。一方で分散システムの複雑性が高くなるため、グレイスフルデグラデーション、リトライとエクスポネンシャルバックオフ、サーキットブレイカー等レジリンスを高める設計がより重要となります。また、ケーススタディとして仮想の EC サイトを例に、分散トランザクションの障害管理パターンである Saga パターン、書き込みと読み込みで個別の信頼性要件に対応するための手法としてイベントソーシングと CQRS パターンを解説しました。 インシデントの影響を封じ込めるクラウドアーキテクチャの実践 AWS ソリューションアーキテクト 奥野 友哉より障害の影響範囲を狭める手法として、セルベースアーキテクチャとシャッフルシャーディングを解説するセッションをお届けしました。セルベースアーキテクチャは、アプリケーションをセル単位で複製し、論理的な境界を作成することによって、障害時の影響を全体の一部に抑える設計手法であり、Amazon EBS 内部や、 Amazon Music でも採用されています。セルルーター、セル、コントロールプレーンという要素で構成され、それぞれの設計ポイントを解説しました。また、レジリエンスを更に高める手法として、クライアントに対して複数のワーカー (シャード) を割り当てるシャッフルシャーディングもご紹介しました。 アーキテクチャ道場 2024！ AWS ソリューションアーキテクトが 2 つのお題に対して、レジリエンスをテーマに設計したアーキテクチャを紹介します。 1 つ目は、 AZ 内で発生するグレー障害 （インフラは正常だが、アプリケーションは正常応答しないようなケース） への対処です。 AZ 隔離を対処の前提とし、 AZ の独立性を高める手法と障害検出方法について解説しました。 2 つ目は、依存性障害 （外部のサードパーティサービスが正常でなくなった場合に障害となるケース）への対処です。アプリケーションとサードパーティサービスの間にプロキシサービスを配置し、負荷の緩和と障害影響の遮断を行う手法を解説しました。どちらの例も障害が発生した場合に、その影響をコントロールするために参考となる手法です。レジリエンス向上に興味のある方はぜひご確認ください。 AWS FIS で始めるChaos Engineering 入門 AWS ソリューションアーキテクト 安藤 麻衣より、ミニステージ にて AWS FIS で始める Chaos Engineering 入門 のプレゼンテーションを行いました。分散システムの信頼性を向上させるカオスエンジニアリングについて、基本的な考え方や手法を解説し、カオスエンジニアリングを始める際に活用できるサービスとして AWS Fault Injection Service を紹介しました。 AWS ブース展示より AWS Resilience ブース資料は こちら からダウンロード頂けます。 AWS Resilience ブースでは、障害注入と Resilience （回復力） の確認をテーマにデモを実施しました。マルチリージョンで構成された、ミッションクリティカルな株価サービスをに対して、AWS Fault Injection Service (FIS) で障害を注入し、ワークロードの変化と回復力の確認を行うデモを実施しました。具体的には、 FIS を通じて、リージョン障害を想定した障害を注入し、障害が発生した際の影響や、 DNS フェイルオーバーによる切り替わり、自動復旧した様子をワークロードのモニターを通じて確認いただきました。デモを通して、 Resilience （回復力）とモニタリングの重要性についてご紹介しました。 金融業務を支えるプラットフォーム ～最新事例～ ブース資料は こちら からダウンロード頂けます。 こちらのブースでは、⾦融インダストリーの⾼信頼性を担保するフレームワーク「⾦融リファレンスアーキテクチャ⽇本版」の最新アップデートをご紹介しました。来場者様向けの体験型のデモとして、ブースに設置された大きなボタンを押すと銀行アプリケーションが東京リージョンから大阪リージョンに数分で自動で切り替わるものをご提供し、多くのお客様に興味をもってマルチリージョンを体験して頂けました。このデモには Fault Injection Service による故障注入や、 AWS Resilience Hub によるアプリケーション回復力の自動評価も含まれます。 AWS が提供するお客様参加型のイベント 「FSI Resiliency Quest」 GameDay についてもご紹介し、ゲーム形式でレジリエンスを学ぶ機会として多くの来場者様から開催のご要望を頂きました。 Chaos Kitty で楽しくインシデント対応ゲームをしよう！ ブース資料は こちら からダウンロード頂けます。 Chaos Kitty は、 AWS のアーキテクチャを物理的に表現し、楽しみながら障害対応の体験学習ができるソリューションです。 Web 3 層 アーキテクチャを IoT 電球の色で示し、正常時は緑、異常時は赤に変わる仕組みとなっています。AWS SUMMIT Japan 2024 では、Amazon CloudWatch ダッシュボードでリソースの稼働状況やリクエスト状況を把握しながら実際にアプリケーションの障害と復旧を体感頂くゲームをご提供しました。 まとめ レジリエンスに関する様々な事例が多くのセッションとブースを通じてお届けできた AWS Summit Japan 2024 でした。ビジネスや社会へのインパクトの大きいワークロードでクラウド活用が進む中で、年々レジリエンスへの注目度が高まっていることが感じられます。ミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド移行を検討頂いている皆様に少しでも参考になれば幸いです。 著者 石倉 徹 パートナー技術統括本部 第三技術部 パートナーソリューションアーキテクト 深森 広英 グローバルフィナンシャルサービス シニアソリューションアーキテクト 新谷 歩生 技術統括本部 ストラテジックインダストリー技術本部 通信グループ シニアソリューションアーキテクト