5 月 29 日、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Serverless 向けの専用 Model Context Protocol (MCP) サーバーが、 AWS ラボ GitHub リポジトリ で利用できるようになりました。これらのオープンソースソリューションは、AI 開発アシスタントの機能を拡張し、事前にトレーニングされた知識を超える、リアルタイムの状況に応じた対応を可能にします。AI アシスタント内の 大規模言語モデル (LLM) は公開文書に依存していますが、MCP サーバーは最新のコンテキストとサービス固有のガイダンスを提供して、一般的なデプロイエラーを防ぎ、より正確なサービスインタラクションの提供を支援します。 これらのオープンソースソリューションを使用すると、 Amazon Web Services (AWS) の機能と設定に関する最新の知識を、構築およびデプロイプロセス中に利用して、アプリケーションをより迅速に開発できます。 統合開発環境 (IDE) でコードを記述する場合も、本番環境の問題をデバッグする場合も、これらの MCP サーバーは Amazon ECS、Amazon EKS、AWS Serverless 機能を深く理解した AI コードアシスタントをサポートし、コードから本番環境への移行を加速します。 コマンドライン (CLE) の Amazon Q Developer などの一般的な AI 対応 IDE と連携し、自然言語コマンドを使用してアプリケーションの構築およびデプロイをサポートします。 Amazon ECS MCP Server は、ロードバランサー、ネットワーク、オートスケーリング、モニタリング、Amazon ECS タスク定義、サービスなど、関連するすべての AWS リソースを設定することで、数分以内にアプリケーションをコンテナ化して、Amazon ECS にデプロイします。自然言語による指示を利用して、クラスター運用の管理、自動スケーリング戦略の実装、リアルタイムのトラブルシューティング機能の使用を行うと、デプロイの問題を迅速に特定して解決できます。 Kubernetes 環境の場合、 Amazon EKS MCP Server は、特定の EKS 環境に関する最新のコンテキスト情報を AI アシスタントに提供します。最新の EKS 機能、ナレッジベース、クラスター状態の情報にアクセスできます。これにより、AI コードアシスタントは、初期設定から本番環境のデプロイまで、アプリケーションのライフサイクル全体を通じて、より正確でカスタマイズされたガイダンスを得ることができます。 AWS Serverless MCP Server は、サーバーレスパターン、ベストプラクティス、AWS サービスに関する包括的な知識を備えた AI コーディングアシスタントを提供することで、サーバーレス開発体験を向上させます。 AWS Serverless Application Model Command Line Interface (AWS SAM CLI) 統合を使用すると、実証済みのアーキテクチャパターンを実装しながら、イベントを処理してインフラストラクチャをデプロイできます。この統合により、アプリケーション開発プロセス全体の機能ライフサイクル、サービス統合、運用要件が合理化されます。サーバーは、コード決定としてのインフラストラクチャ、 AWS Lambda 固有のベストプラクティス、AWS Lambda イベントソースマッピングのイベントスキーマに関するコンテキストガイダンスも提供します。 実際の動作を見てみましょう AWS MCP サーバーを初めて使用する場合は、 AWS ラボ GitHub リポジトリの「インストールとセットアップ」ガイド でインストール手順を確認してください。インストールしたら、次の MCP サーバー構成をローカルセットアップに追加します。 コマンドライン用 Amazon Q をインストールし、設定を ~/.aws/amazonq/mcp.json に追加します。既に Amazon Q CLI を使用している場合は、設定のみを追加します。 { "mcpServers": { "awslabs.aws-serverless-mcp": { "command": "uvx", "timeout": 60,       "args": ["awslabs.aws_serverless_mcp_server@latest"], }, "awslabs.ecs-mcp-server": { "disabled": false, "command": "uv", "timeout": 60, "args": ["awslabs.ecs-mcp-server@latest"], }, "awslabs.eks-mcp-server": { "disabled": false, "timeout": 60, "command": "uv", "args": ["awslabs.eks-mcp-server@latest"], } } } このデモでは Amazon Q CLI を使用して、サンプルコードとして Amazon Nova モデルクックブックリポジトリ の 02_using_converse_api.ipynb を利用して動画を理解するアプリケーションを作成します。これを行うには、次のプロンプトを送信します。 I want to create a backend application that automatically extracts metadata and understands the content of images and videos uploaded to an S3 bucket and stores that information in a database.I'd like to use a serverless system for processing.Could you generate everything I need, including the code and commands or steps to set up the necessary infrastructure, for it to work from start to finish? - Use 02_using_converse_api.ipynb as example code for the image and video understanding. Amazon Q CLI は、MCP サーバー awslabs.aws-serverless-mcp-server を含む必要なツールを特定します。AWS Serverless MCP サーバーは、1 回のやりとりで、堅牢なアーキテクチャを構築するためのすべての要件とベストプラクティスを決定します。 Amazon Q CLI にアプリケーションの構築とテストを依頼しましたが、エラーが発生しました。Amazon Q CLI は利用可能なツールを使用して、問題を迅速に解決しました。 Amazon DynamoDB テーブルで作成されたレコードを確認して、 dog2.jpeg ファイル を使用してアプリケーションをテストし、成功を確認しました。 動画処理機能を強化するために、メディア分析アプリケーションをコンテナ化されたアーキテクチャに移行することにしました。そこで、次のプロンプトを使用しました。 I'd like you to create a simple application like the media analysis one, but instead of being serverless, it should be containerized.Please help me build it in a new CDK stack. Amazon Q Developer がアプリケーションの構築を開始します。この時間を利用してコーヒーを買いに行きました。コーヒーを片手にデスクに戻ったとき、アプリケーションの準備ができていたので、嬉しい驚きを覚えました。すべてが現在の基準を満たしていることを確認するために、私は単純に次のように尋ねました。 please review the code and all app using the awslabsecs_mcp_server tools  Amazon Q Developer CLI は、すべての改善点と結論をまとめた概要を提供します。 必要な変更をすべて行うように依頼します。準備ができたら Amazon Q Developer の CLI に、すべて自然言語を使用して私のアカウントにデプロイするように依頼します。 数分後、S3 バケットから必要なすべてのネットワークへの、完全なコンテナ化されたアプリケーションができたことを確認しました。 Amazon Q Developer CLI にアプリのテストを依頼して the-sea.mp4 動画ファイル を送信したところ、タイムアウトエラーが返されました。そこで、Amazon Q CLI は awslabsecs_mcp_server ツールの fetch_task_logs を使用してログを確認し、エラーを特定して修正することを決定しました。 新規デプロイ後、もう一度試してみたところ、アプリケーションは動画ファイルを正常に処理しました Amazon DynamoDB テーブルにレコードが表示されています。 Amazon EKS MCP サーバーをテストするために、auction-website-main フォルダーにウェブアプリのコードを置いています。堅牢なウェブアプリを作成したいと考えているため、Amazon Q CLI にこのプロンプトを手伝ってほしいと依頼しました。 Create a web application using the existing code in the auction-website-main folder.This application will grow, so I would like to create it in a new EKS cluster Docker ファイルが作成されると、Amazon Q CLI は awslabseks_mcp_server の generate_app_manifests を、アプリケーション用の Kubernetes マニフェストを作成するための信頼できるツールとして識別します。 次に、 manage_eks_staks ツールを使用して新しい EKS クラスターを作成します。 アプリケーションの準備が整うと、Amazon Q CLI によってデプロイされ、作成した内容の概要が表示されます。 クラスターのステータスはコンソールで確認できます。 数分後、 search_eks_troubleshoot_guide ツールを使用していくつかの問題を解決すれば、アプリケーションを使用できるようになります。 これで、Amazon Q CLI による自然言語コマンドのみを使用して、Amazon EKS にデプロイされた Kitties マーケットプレイスのウェブアプリケーションが完成しました。 今すぐご利用いただけます AWS ラボ GitHub リポジトリ にアクセスして、これらの AWS MCP サーバーの使用を開始し、AI を活用した開発を強化してください。リポジトリには、コードを変更せずに既存の AWS Lambda 関数を AI アクセス可能なツールに変換する AWS Lambda 関数を実行 するための実装ガイド、設定例、その他の専用サーバー、および Amazon Bedrock ナレッジベースへのシームレスなアクセスを提供する Amazon Bedrock Knowledge Bases Retrieval MCP サーバー が含まれています。リポジトリ内の他の AWS 専用サーバー には、より信頼性の高い迅速なアプリケーションの構築を開始するためのドキュメント、設定例、実装ガイドが含まれています。 AWS Serverless と Containers 向け MCP サーバーの詳細と、それらが AI 支援アプリケーション開発を変革する方法については、「 AWS Serverless MCP サーバーの紹介: 最新アプリケーションのための AI を活用した開発 」、「 Amazon ECS MCP サーバーを使用した AI 支援のコンテナデプロイの自動化 」、「 Amazon EKS MCP サーバーを使用したアプリケーション開発の加速 」を参照してください。 –  Eli 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 早いもので、6 月 25 日（水）、26 日（木）の二日間、日本最大のAWSを学ぶイベント、AWS Summit Japan が開催されます。我々AWSメンバーは一年に一度のこの一大イベントに向けて、準備を進めています。AWS セッションだけでなく、お客様セッションもリアルな実体験が聞けますので、おすすめです。また会場にはDemo展示や、ワークショップ、ハッカソンなどが開催されており、一日中 AWS について楽しく学べるようになっています。会場で皆様にお会いできるのを楽しみにしています。事前登録は こちら から可能です。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年5月26日週の主要なアップデート 5/27(火) Amazon RDS for MySQL が Extended Support マイナーバージョン 5.7.44-RDS.20250508 を発表 Amazon RDS for MySQL の新しいExtendedサポートマイナーバージョン 5.7.44-RDS.20250508 がリリースされました。今回のアップデートの重要なポイントは、Extended サポートという MySQL の長期サポートオプションが追加されたことです。通常、MySQL のメジャーバージョンのサポート期間が終了すると、セキュリティパッチや不具合修正が提供されなくなりますが、Extended サポートを利用することで、標準サポート終了後も最大 3 年間、重要なセキュリティパッチやバグ修正の提供を受けることができます。これは、ビジネス要件に応じて、新しいメジャーバージョンへのアップグレードを計画的に進められることを意味します。延長サポートの詳細については、Amazon RDSユーザーガイド および価格に関する FAQ をご覧ください。 Amazon Aurora DSQLが一般利用可能に Amazon Aurora DSQLが一般提供開始となりました。これは、アクティブ-アクティブの高可用性とマルチリージョンの強力な一貫性を備えた、最速のサーバーレス分散型SQLデータベースです。Aurora DSQL を使用することで、事実上無制限のスケーラビリティと最高レベルの可用性を持ち、インフラ管理が不要なアプリケーションを構築できます。単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を実現するように設計されており、単一障害点がなく、障害からの自動復旧が可能です。マルチリージョンの強力な一貫性により、どのリージョンのエンドポイントに対する読み取りと書き込みも、強力な一貫性と耐久性が保証されます。 詳細については、Aurora DSQL の 概要ページ 、 ブログ記事 、 価格ページ 、 ドキュメント をお読みください。現時点で東京、大阪リージョンはシングルクラスター構成となります。 AWS Backup が Amazon Aurora DSQL のサポートを開始 AWS Backup が、常時利用可能なアプリケーション向けのサーバーレス分散型 SQL データベースである Amazon Aurora DSQL のサポートを開始しました。これにより、Aurora DSQLを使用している組織は、AWS Backup の完全マネージド型データ保護機能を活用できるようになります。AWS Backup と AWS Organizations の統合により、組織全体のアカウントにわたって一元的に不変なバックアップを作成・管理し、データ保護を標準化することが可能になりました。Aurora DSQL ユーザーは、AWS Backup の包括的なデータ保護機能を利用できます。具体的には、自動スケジューリング、保持期間の管理、改ざん不可能で論理的にエアギャップされたバックアップボールト、リージョン間およびアカウント間のコピー、そしてコスト効率の高いコールドストレージなどの機能が含まれます。この統合により、バックアップ管理が効率化され、組織は Aurora DSQL と他の AWS リソースにわたってデータ保護戦略を統一することができます。 AWS Neuron が NxD 推論の 一般提供開始、新機能、および改良されたツールを発表 AWS Neuron の最新バージョン 2.23 がリリースされ、推論、トレーニング機能、開発者ツールにわたる多くの改善が発表されました。この更新の最も重要なポイントは、NxD Inference ライブラリ (NxDI) が一般提供されたことです。このライブラリは、複数チップを使用する推論処理において推奨されるソリューションとなります。Persistent Cache のサポートによりコンパイル時間が短縮され、モデルの読み込み時間も最適化されています。トレーニングワークロードに関しては、NxD Training ライブラリが Llama モデル向けに Context Parallelism のサポート (ベータ版) を導入し、シーケンス長を 32K まで拡張できるようになりました。また、DPOスタイルのデータセットを使用したORPOによるモデルアライメントのサポートも追加されました。サードパーティライブラリのサポートも強化され、PyTorch Lightning 2.5、Transformers 4.48、NeMo 2.1 に対応しています。Neuron Kernel Interface (NKI) では、32ビット整数演算の新機能、Trainium2 向けの改善されたISA機能、新しいパフォーマンスチューニング API が導入されました。 5/28(水) Amazon Neptune が MCP (Model Context Protocol) サーバーを発表 Amazon Neptune の新機能として、MCP (Model Context Protocol) サーバーの提供が開始されました。この新しいサーバーにより、開発者やAIアシスタントが Amazon Neptune とより簡単にやり取りできるようになり、生成系AIのワークフローにグラフデータベースのクエリを簡単に組み込むことが可能になりました。MCP サーバーは AWS が提供する Model Context Protocol ツール群の一部として、openCypher や Gremlin といったクエリ言語をサポートし、スキーマの検出や自然言語でのクエリ実行を可能にします。これにより、Amazon Q CLI や Cursor、Claude Code などの MCP 対応ツールと Neptune を連携させることができ、複雑なコードを書くことなく、普通の英語で質問してグラフデータベースからの応答を得ることができます。ナレッジグラフの構築や関係性の分析、AI アシスタントの機能強化など、さまざまなユースケースにおいて、これまで以上に直感的かつ効率的にグラフデータを探索・クエリすることが可能になりました。Amazon Neptune MCP Server は、Amazon Neptune が提供されているすべての AWS リージョンで利用可能になりました。詳しくは、 ブログ でNeptune MCP Serverの詳細をご覧ください。 Cost Optimization Hub で Savings Plans と予約の設定をサポート AWS の請求とコスト管理コンソール内の機能である Cost Optimization Hub に、新しい機能が追加されました。この更新により、Savings Plans や予約インスタンスに関する設定をカスタマイズできるようになり、お客様の希望する契約条件に基づいたコスト最適化の推奨事項と潜在的な節約額を確認できるようになりました。Cost Optimization Hub は、EC2 インスタンスのサイズ最適化、graviton への移行、アイドル状態のリソース、予約インスタンス、Savings Plans などに関する AWS のコスト最適化の推奨事項を簡単に特定、フィルタリング、集計できる機能です。今回の更新で、契約期間を 1 年または 3 年から選択できるようになり、支払いオプションについても全額前払い、一部前払い、前払いなしの中から選択できるようになりました。これにより、お客様の組織が望む契約条件に合わせた、より正確な潜在的な節約額を把握することが可能になります。例えば、組織の方針として 1 年契約のみを検討している場合、その条件に基づいた推奨事項と節約額を確認できるため、より実用的な情報を得ることができます。この機能強化により、組織のポリシーや予算計画に沿ったコスト最適化の検討が、さらに効率的に行えるようになりました。 AWS Network Firewall が複数の VPC エンドポイントをサポート AWS Network Firewall に、複数の VPC エンドポイントをサポートする新機能が追加されました。この更新により、1 つのファイアウォールで複数の Amazon VPC に対してセキュリティ保護を提供できるようになりました。AWS Network Firewall は、AWSが提供するマネージド型のクラウドネイティブなファイアウォールサービスで、すべてのAmazon VPC に必要なネットワーク保護を簡単に導入することができます。これまでは1つのファイアウォールに対して1つの VPC エンドポイントしか設定できませんでしたが、今回のアップデートにより、1つのアベイラビリティゾーンあたり最大 50 個の VPC エンドポイントを関連付けることが可能になりました。これにより、複数の VPC のトラフィックを 1 つのファイアウォールで一元的に検査できるようになり、運用の複雑さを軽減し、コストを削減することができます。 Amazon FSx for NetApp ONTAP が ONTAP FlexCache ボリュームのライトバックモードをサポート Amazon FSx for NetApp ONTAP において、ONTAP FlexCache ボリュームの write-back モードがサポートされるようになりました。Amazon FSx for NetApp ONTAPは、NetAppの人気ファイルシステム ONTAP をベースにした、フルマネージド型の共有ストレージサービスです。今回のアップデートにより、複数の AWS リージョンやオンプレミス環境に分散された書き込み負荷の高いワークロードで、より高速なパフォーマンスを実現できるようになりました。FlexCacheは、データへの分散アクセスを可能にする ONTAP のキャッシュ技術です。これまでは、write-around モードのみがサポートされており、FlexCache ボリュームへの書き込み操作は、必ず元のボリュームに戻って確認される必要があったため、書き込みの遅延が大きくなっていました。今回のアップデートで導入されたwrite-backモードでは、FlexCache ボリュームにローカルで書き込みをキャッシュし、非同期で元のボリュームを更新することで、書き込み遅延を削減します。これにより、複数のAWSリージョン間やクラウドとオンプレミス環境間で運用が必要な、コンテンツ共同作成、分散データベース、エンジニアリングワークフローなどの書き込み負荷の高い分散アプリケーションのパフォーマンスを向上させることができます。このアップデートは、地理的に分散したチームでの作業や、グローバルなデータ処理を必要とするビジネスにとって、特に有益な機能強化となります。詳細については、 FSx for ONTAP ユーザーガイド を参照してください。 5/29(木) Amazon OpenSearch Service が スクリプトプラグイン をサポート Amazon OpenSearch Service に新機能が追加されました。この新機能により、Script プラグインのサポートが開始されました。これは、検索やインデックス作成時のスコアリング、ソート、フィールド値の変換などの操作のために、新しいスクリプト言語やカスタムスクリプト機能を OpenSearch に追加できるようになるものです。これまでは、カスタムプラグインを使用して OpenSearch の検索と分析機能を拡張することはできましたが、今回のアップデートにより、カスタムプラグインの一部として ScriptPlugin インターフェースを実装し、OpenSearch のスクリプト機能を拡張できるようになりました。OpenSearch Service のコンソールや API を使用して、カスタムプラグインをアップロードし、ドメインに関連付けることができます。その際、OpenSearch Service は、プラグインパッケージのバージョン互換性、セキュリティ、許可されたプラグイン操作について検証を行います。 AWS DataSync がクラウド間のデータ転送を簡素化し高速化 今回のアップデートにより、他のクラウドプロバイダーのストレージと Amazon S3 の間で、直接データを転送できるようになりました。これまでは DataSync エージェントの導入が必要でしたが、その必要がなくなり、より簡単にデータ転送が可能になりました。対応している他社クラウドのストレージサービスには、Google Cloud Storage、Microsoft Azure Blob Storage、Oracle Cloud Object Storage が含まれます。新機能では、DataSync Enhanced mode を使用することで、データの準備、転送、検証を並列処理し、より高速な転送速度を実現します。また、事実上無制限のオブジェクト数に対応し、詳細なメトリクスとレポート機能を使用して転送状況を監視することができます。この機能強化により、他のクラウドから AWS へのデータ移行やデータパイプラインの構築がより効率的になり、お客様は複雑なエージェント設定なしで、シンプルにクラウド間のデータ転送を実現できるようになりました。特に、複数のクラウドサービスを利用している企業や、クラウド移行を検討している組織にとって、大きなメリットとなる機能です。詳細は、DataSyncの ドキュメント を参照ください。 AWS サーバーレスおよびコンテナ向けの新しい Model Context Protocol (MCP) サーバーを発表 AWS Lambda、Amazon ECS (Elastic Container Service)、Amazon EKS (Elastic Kubernetes Service)、そして Finch 向けの Model Context Protocol (MCP) サーバーのリリースを発表しました。MCP サーバーは、AI コードアシスタントが AWS のサーバーレスやコンテナサービスをより深く理解し、より効果的に開発支援を行うための標準インターフェースです。このアップデートにより、開発者はAIアシスタントを活用して、より迅速にアイデアを本番環境へと展開できるようになります。MCP サーバーの特徴は、AWSの運用ベストプラクティス、Well-Architected フレームワークの原則、そしてサービス固有の最適化を組み込んでいる点です。これにより、開発者は自然言語で要件を説明するだけで、AI コードアシスタントがサービスの設定やインフラのセットアップ、サービス間の連携を適切に処理できます。また、MCP サーバーは、ログ記録、モニタリング、セキュリティ制御、トラブルシューティングなどの運用面でも AI による支援を提供し、運用管理を大幅に簡素化します。このアップデートは、特にAWSの技術に詳しくない開発者にとって、複雑な AWS サービスの利用をより身近なものにし、効率的な開発を可能にする重要な進化といえます。AI アシスタントがAWSのベストプラクティスに基づいて適切なガイダンスを提供することで、より信頼性の高いアプリケーション開発が実現できるようになります。AWS ServerlessとContainers 用の MCP サーバーの詳細と、それらがAI支援アプリケーション開発をどのように変革できるかについては、 AWS News Blog をご覧ください。 5/30(金) Mountpoint for Amazon S3 で fstab を使用した S3 バケットの自動マウントが可能に Amazon S3 のバケットをマウントするためのツール「Mountpoint for Amazon S3」に、新しい機能が追加されました。EC2 インスタンスの起動時に S3 バケットを自動的にマウントできるようになりました。この機能により、インスタンスの起動時やリブート時に毎回手動でマウントする必要がなくなり、より簡単に S3 バケットを利用できるようになります。これまでは、EC2 インスタンスを起動するたびに手動でマウント作業を行い、マウントオプションが正しく設定されているかを確認する必要がありました。今回のアップデートでは、Linux システムの標準的な設定ファイルである fstab に Mountpoint の設定を追加することで、自動マウントが可能になります。fstab は Linux システム管理者がよく使用するファイルで、コンピュートインスタンス上の全てのマウントポイントの情報を一元管理するために使われています。 AWS Pricing Calculatorが一般提供を開始し、割引と購入コミットメントに対応 AWS Pricing Calculator が、AWSコンソールで一般提供開始となりました。この新しいツールでは、ワークロードのコスト見積もりと AWS の請求全体の見積もりという 2 種類の見積もり機能を提供します。お客様は過去の使用状況をインポートしたり、新規の使用量を設定したりしてコストを見積もることができます。さらに、AWS Pricing Calculator では3つの料金設定オプションが用意され、割引や既存の契約を含めた見積もりが可能になりました。これにより、AWS の価格設定や数量割引、既存の契約がワークロード全体の見積もりコストにどのように影響するかを確認できます。新しい料金設定機能では、価格割引と購入契約の両方を含めることで、コストシナリオにおける潜在的な節約額とコスト最適化をより明確に把握できます。この機能は、Savings Plans や Reserved Instance などの既存の契約が AWS 全体のコストにどのような影響を与えるかを理解したい組織にとって特に有用です。 Amazon Redshift の RA3 プロビジョニングクラスターでクラスター再配置がデフォルトで有効に Amazon Redshift の RA3 プロビジョンドクラスターにおいて、クラスターの再配置機能がデフォルトで有効になりました。この機能は、新しいクラスターを作成する場合やスナップショットから復元する場合に適用されます。クラスターの再配置機能とは、リソースの制約によってクラスターの運用に支障が出た場合に、クラスターを別のアベイラビリティゾーン (AZ) に移動できる機能です。移動後も同じエンドポイントを維持するため、アプリケーション側での変更は不要です。Amazon Redshift はすでにドライブやノードの障害を自動的に検知して復旧する機能を備えていますが、クラスターの再配置機能により、AZレベルの問題に対する可用性保護がさらに強化されました。紹介は ドキュメント を参照ください。 AWS 向け Red Hat Enterprise Linux の提供開始を発表 Red Hat社とAWSが共同で提供する新しいサービス「 Red Hat Enterprise Linux (RHEL) for AWS 」が、 RHEL 10 から一般提供開始されることが発表されました。このサービスは、Red Hatの企業向けLinuxソフトウェアとAWSのネイティブ統合を組み合わせた画期的なソリューションです。AWS上でRHELを最適な状態で実行できるように特別に設計されており、AWSに特化した性能プロファイルで事前にチューニングされたイメージを提供します。主な特徴として、 Amazon CloudWatch との連携による監視機能、AWS Command Line Interface (CLI) の統合、コンテナネイティブツールを使用したイメージモード、起動時からランタイムまでの強化されたセキュリティ、そしてElastic Network Adapter (ENA) のサポートによる最適化されたネットワーク機能が含まれています。詳細は、 Red Hat Enterprise Linux on Amazon EC2 FAQs ページ を参照してください。 Amazon MWAA でタスク実行を中断せずに環境を更新できるように Amazon Managed Workflows for Apache Airflow (MWAA) において、実行中のタスクを中断せずに環境をアップデートできる機能が追加されました。この機能は Apache Airflow バージョン 2.4.3 以降でサポートされています。Amazon MWAA は、ワークフローのオーケストレーションに使用される Apache Airflow を管理型サービスとして提供するものです。これまでは環境のアップデート時に実行中のタスクが中断されてしまう課題がありましたが、今回のアップデートでより柔軟な運用が可能になりました。具体的には、新しいアップデートオプションを選択することで、Airflowのスケジューラーとウェブサーバーコンポーネントの置き換え、新しいワーカーの準備、そして実行中のワーカータスクの完了を待ってから古いワーカーを削除するという、段階的なアップデートプロセスが実現できます。これにより、ビジネスの継続性を保ちながら、システムの更新が可能になります。特に大規模な環境や重要なワークフローを実行している場合に、このアップデート機能は非常に有用です。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

この記事は、2025年4月23日に公開された “ Introducing the AWS Well-Architected Video Streaming Advertising Lens ” を翻訳したものです。 Amazon Web Services (AWS) にて、AWS Well-Architected Video Streaming Advertising (VSA) Lens を発表いたします。VSA Lens は、 レンズホワイトペーパー とカスタムレンズで構成されており、 AWS Well-Architected Tool のレンズカタログで利用可能になります。今すぐ必要な場合は、アカウント担当者に連絡してアクセスをご依頼ください。 今回初版が発表された VSA Lens は、 AWS Well-Architected Framework を拡張したものです。AWS Well-Architected Frameworkは、AWS のお客様とパートナーがクラウドアーキテクチャを改善し、技術的リスクを低減するのに役立ちます。VSA Lens は、AWS 上で極めて高いスループットのビデオストリーミング広告ワークロードを設計・運用するお客様に、アーキテクチャ上のベストプラクティスを提供します。VSA Lens は以下の6つの柱に基づいています： 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 VSA Lens の初版には、アトリビューションおよびアドベリフィケーションソフトウェアに関する規範的なガイダンスが含まれています。また、高可用性ソリューションや最先端の人工知能・機械学習（AI/ML）ツールに関する内容も組み込まれています。さらに、データ転送コストの管理および、変動するリアルタイム広告トラフィックの負荷分散最適化に関する戦略にも対応しています。 このブログでは、VSA Lens の概要を説明し、AWS Well-Architected Tool のワークロードレビューに VSA Lens を追加する方法を示します。 Video Streaming Advertising Lens の新たな機能は何ですか？ アドサーバー、SSP（サプライサイドプラットフォーム）、DSP（デマンドサイドプラットフォーム）向け広告ワークロードの運営における広告ビジネス目標の整合性確保 広告キャンペーンの優先順位と組織構造を評価・更新するプロセス 広告に関するリスクの評価と自動的な緩和 手作業によるエラーのリスクを低減するための広告配信インフラストラクチャデプロイメントの自動化 パフォーマンス指標の確立 — 各広告プロセスと手順に対する KPI（重要業績評価指標）と SLO（サービスレベル目標）の定義 ベストプラクティスと実装ガイダンスの提供 — 特に、ビジネス上、最も重要な分野でワークロードを改善するために使用できる実践的なガイダンスを提供 アーキテクチャとリンク集 — 広告プロジェクトを支援するさまざまな新製品、機能、現行の業界ベストプラクティスを反映した、多くの新しいドキュメント、ブログ、ガイド、ビデオへのリンクの提供 VSA Lens は誰が使用すべきですか？ VSA Lens は以下のような様々な役割の方にご活用いただけます： ビジネスリーダー：実装に対する理解を広範囲に深めることができます 最高技術責任者（CTO）：新しい AWS サービスと実装ガイダンスの使用方法を理解することができます ソリューションアーキテクト：AWS Well-Architected Framework の考え方に沿ったソリューションの構築方法を学ぶことができます 運用チーム：より広範な広告ワークロードの運用を可能とする革新的なインフラストラクチャを監視・管理することができます セキュリティチーム：堅牢なセキュリティ要件に基づいて広告ワークロードを強化することができます まとめ 新しい VSA Lens は利用可能です。Lens ホワイトペーパーを使用して、AWS Well-Architected Framework の原則に従って広告ワークロードを改善してください。アーキテクチャに VSA Lens を適用することで、設計の安定性と効率性を検証し、評価の際に特定された課題に対する推奨事項を得ることができます。 AWS は、この広告 Lens を強力なツールとして継続的に発展させることに尽力しています。新しい AWS サービスの立ち上げ、業界トレンドの変化、そして（持続可能性のような）新たな柱の追加に応じて、VSA Lens を迅速に更新していきます。私たちの使命は、適切に構築される広告ワークロードの設計と展開をサポートし、お客様がビジネス目標の達成に集中できるようにすることです。 AWS エンタープライズサポート、AWS ソリューションアーキテクト、AWS プロフェッショナルサービス、そして広告コミュニティの皆様の Lens への貢献に感謝します。新しい AWS Well-Architected VSA Lens の開発にあたり、幅広い横断的視点、専門知識、さまざまなバックグラウンドや経験と言った貢献を受けました。 ビジネスを加速させるためのご支援については、 AWS の担当者 にお問い合わせください。 さらに詳しく Running high-throughput, real-time ad platforms in the cloud – クラウドベースのリアルタイム広告プラットフォームのベストプラクティス AWS for Advertising & Marketing のホームページ – 比類のないコストパフォーマンスで超低レイテンシーの広告ワークロードを実行 翻訳は、テクニカルアカウントマネージャーの馬場が担当しました。 Abraham Lobo Abraham Lobo はメディア・エンターテイメント分野のプリンシパルテクニカルアカウントマネージャーで、AWS 上でのメディアおよび広告を専門にしています。 Basil Badawiyeh Basil Badawiyeh はメディア・エンターテイメント分野のシニアエンタプライズサポートマネージャーで、メディアおよび広告領域における AWS 上のワークロードのオペレーションを専門にしています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。6月になりました。6月と言えば！AWS Summit です！6月25日と26日に AWS Summit Japan が開催されます。今回のブログ内でも紹介していますが、AWS Summitでの展示内容の情報が出始めています。AWS メンバーが頑張ってデモアプリなどを開発していますので楽しみにしてください。また、イベントの 事前登録 もお忘れなく！ また、先日 Anthropic社 から待望の Claude 4 がリリースされ Bedrock でも利用可能となりました。今回は「Claude Opus 4」と「Claude Sonnet 4」という2つのモデルが登場し、特にコーディングや複雑な推論タスクで革新的な性能を見せています。生成AIの進化が加速する中で、それぞれのモデルの特徴を理解して使い分けることがますます重要になってきていると感じます。実際、Anthropic社 も Claude 4 のベストプラクティスガイド を既に公開しており、効果的な活用方法についての情報提供を積極的に行っていますので是非参照してみてください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「NTT データの AWS ジャパン生成 AI 実用化推進プログラム成果報告 : AI Agent によるクリエイティブ業務支援ソリューション開発」 株式会社 NTT データは、2024 年度の AWS ジャパン生成 AI 実用化推進プログラムに参画し、AI Agent によるクリエイティブ業務支援ソリューションを開発されました。このソリューションは、Web検索、デザイン案生成、画像生成の3つのエージェントを、Supervisor Agent が統括する形で構成されており、LangGraph フレームワークを用いて実装されています。Amazon Bedrock のClaude 3.7 Sonnet 他複数のAIモデルを組み合わせることで、多様な表現力を実現しています。実際のデザイン関連企業との協業を通じて、調査業務で75%の効率化を達成し、デザイン案の生成においてもアイデア創出の支援に成功しています。またAWSのマネージドサービスを活用することで、約2ヶ月という短期間でソリューションを構築することができました。ブログでは、開発の背景となるビジネス的課題から、具体的なソリューションのアーキテクチャ、そして実際の導入による効果を包括的に紹介しています。 AWS生成AI国内事例ブログ「三菱重工グループが挑戦する企業変革 ～生成AI戦略から価値創出までの実践記録〜」 このブログでは、三菱重工業株式会社（MHI）と三菱重工業機械システム株式会社（MHI-MS）が生成AIの全社活用に向けた取り組みを紹介しています。まず、デジタルイノベーション本部主導でAI Center of Excellence（AI-CoE）の体制を確立し、AWS の CAF-AI フレームワークを活用した戦略を策定し、次に、生成AIデザインワークショップを通じて具体的なユースケースを特定し、経営層から実務者層まで一体となって事業価値の創出方法を検討しました。そして、「Experience Based Acceleration（EBA）」という手法でプロトタイピングを実施し、わずか3日間で高水準のプロトタイプを完成させ、事業価値の実現可能性を確認しました。この取り組みは、デジタル部門と事業部門の連携、スキル開発、そして挑戦する文化の醸成という複数の成果をもたらしています。エンタープライズ企業における生成 AI 活用のアプローチとして参考になるのではないでしょうか。 ブログ記事「AWS Summit Japan 2025 製造業ハイライト展示の見どころ紹介！」を公開 2025年6月25日と26日に AWS Summit Japan が開催されます。このブログでは製造業向け展示ブースと製造業に関するセッションの情報をご紹介しています。特に生成AIの実践的な活用例の展示が予定されています。スマート生産エリアでは産業用ロボットのトラブルシューティングを生成AIアシスタントが支援し、サプライチェーンエリアではAI/ML/GenAIを活用した最適化ソリューションを展示します。特に注目すべきは、スマートプロダクト＆サービスエリアで紹介される複数のAIエージェントによるリアルタイムサポートと、エージェンティックコーディングによる開発プロセスの革新です。さらに、データエリアではAmazon Q in QuickSightによる自然言語でのデータ分析や、グラフDBと生成AIを組み合わせた業務横断的な分析機能が紹介され、製造業における生成AI活用の包括的なソリューションを体験できます。是非ブログの内容を参照いただき、イベント参加の際の参考にしてみてください。 ブログ記事「Amazon Connect, Amazon Lex, Amazon Bedrock Knowledge Bases を活用してコンタクトセンターに音声とチャットの生成 AI エージェントをデプロイする」 このブログでは、コンタクトセンター向け生成 AI エージェントソリューションを紹介しています。 DoorDash は Amazon Connect、Amazon Lex、Amazon Bedrock Knowledge Bases を活用し、わずか 2 か月で音声・チャット対応の AI エージェントを構築、配達員からの問い合わせに対して2.5 秒以内の応答速度を実現し、日々数十万件の電話対応を処理しています。システムはサーバーレスアーキテクチャを採用しており、運用負荷を最小限に抑えながら、ハルシネーション検出や会話分析などの高度な機能も提供します。実装手順からカスタマイズ方法まで、オープンソースで提供される実践的なソリューションの詳細をご覧ください。 サービスアップデート Amazon Neptune MCP サーバーの発表 グラフデータベースの Amazon Neptune の MCP サーバーが発表されました。openCypher や Gremlin クエリ、スキーマ探索、自然言語によるクエリが可能になり、複雑なコードを書くことなく、Amazon Q CLI や Cursor、Claude Code などのツールと連携できます。特に注目すべき点は、自然言語で質問を投げかけることで、グラフデータベースからの応答が得られる機能です。これにより、ナレッジグラフの構築や関係性の分析、AIアシスタントの機能強化など、より直感的かつ効率的なグラフデータの活用が可能になります。 AWS Serverless と Containers 向けの MCP サーバーの発表 Lambda、ECS、EKS、Finch 向けの MCP サーバーを発表しました。この新機能により、AIコードアシスタントが AWS のサーバーレスやコンテナサービスのベストプラクティスを理解し、より実用的なコード生成が可能になります。開発者は自然言語で要件を記述するだけで、AIアシスタントがサービスの設定やインフラのセットアップ、サービス間の連携を適切に処理できるようになります。さらに、ロギング、モニタリング、セキュリティ制御、トラブルシューティングなどの運用面でもAIによるサポートが受けられ、より効率的なアプリケーション開発が実現できます。 AWS MCP のアップデートは こちら に集約されておりますのでチェックしてみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅での焼き鳥で串打ちにハマっています。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの林です。 通信事業者の方々、通信業界に関わられている方々、 AI 活用や最新技術の動向にご興味のある方々を主な対象として、2025 年 5 月 15 日に「テレコム業界向け： Mobile World Congress (MWC) 2025 Recap 」をウェビナーで開催しました。 本記事では、当日の内容・動画を皆様にご紹介します。 ウェビナー開催の背景 2025 年 3 月 3 日から 3 月 6 日までスペイン・バルセロナで開催されたテレコム業界最大のイベント Mobile Word Congress (MWC) 2025。AWS は現地にて、3 回目のブース出展を行いました。10 万人以上の来場者を集めた今回のイベントでは、通信事業者様やパートナー様と AWS の協業による数々の取り組みがデモンストレーション含め展示されました。今回のウェビナーでは、テレコム業界向けの AWS の取り組みとして、「ネットワークのモダナイゼーション」「ネットワークオペレーションの高度化」「ソフトウェア主導型のビジネス変革」「新規ビジネスユースケースの創出」のテーマで、様々な事例をご紹介しました。 1. MWC 2025 における AWS 出展内容のハイライト |  Video アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信第一ソリューション部 部長　川崎 一青 資料は こちら からダウンロード頂けます。 まず川﨑より、MWC 2025 における AWS の出展の全体像をご説明いたしました。今回の出展では、通信業界向けの新たなAWS サービスの発表と、24 のデモ展示、多数のセッションを通じて、通信事業者各社の変革への取り組みが紹介されました。 特に注目を集めたのは、通信業界の要件に対応した新しい AWS Outposts の発表です。高スループット対応の Outposts rack と Cloud RAN 向けの Outposts server により、低レイテンシー、高スループット、リアルタイムパフォーマンスの要件に対応し、オンプレミスに延伸したAWSインフラストラクチャにネットワーク機能をデプロイすることが可能となります。 また、 AWS IoT Device Management のマネージドインテグレーション機能も発表され、異なるプロトコルやメーカー間の互換性問題を解消し、統一的なデバイス制御と SDK を提供することで、スマートホームなどのサービス開発を加速することが可能となります。 Verizon、BT、Orange、Swisscom など、世界の主要な通信事業者とのセッションも多数行われ、各社が AWS を活用し、5G コアの展開や Cloud RANの評価、オペレーション高度化、AI を活用した顧客サービスの改善などを行なった取り組みが紹介されました。これらの取り組みは、通信業界が直面する課題に対する革新的なソリューションを提示するとともに、 AWS が通信業界の変革において重要な役割を果たしていることを示しています。 2. ネットワークのモダナイゼーション |  Video アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信第二ソリューション部 ソリューションアーキテクト　林　文傑 資料は こちら からダウンロード頂けます。 林からは、ネットワークのモダナイゼーションをテーマとして、通信事業者のネットワーク構築・運用における課題と、それらに対する生成 AI や AWS インフラを活用したソリューション事例についてお届けしました。 通信事業者は、ネットワークデプロイの自動化、ベンダー開発の効率化、そしてデプロイ環境の最適化といった課題に直面しています。これらの課題に対し、 MWC 2025 で展示/デモンストレーションされた、 AWS が通信事業者およびパートナーと協業したソリューション事例を対応する3つの観点からご紹介しました。 以下に各観点の概要をまとめましたのでご参照ください。 【デプロイ自動化】 ネットワークデプロイの自動化において、 NTT DOCOMO では Open RAN 向けコンテナ環境の構築およびそのライフサイクル自動化を、 AWS クラウドサービスを使って実現しています。また、 TELUS では Samsung および ng-voice とのローミングプロジェクトにおいて生成AIを活用したデプロイ自動化の PoC を実施し、実証を進めています。 LLM・RAG により設計書やネットワーク機能設定を元にIaCアーティファクトを自動生成し GitOps ワークフローで効率的に展開しています。 【ベンダー開発】 ベンダー開発の効率化において、 Ericsson では、カスタム言語モデル、 RAG 、エージェントを活用してエンジニアのナレッジソースへのアクセスを容易にし、エンジニアの製品設計・開発を支援しています。エージェントへの仕様問い合わせ、コード検索、コードの説明、コード生成を実施することで、複雑な技術的な問いでインサイトに辿り着く時間が数時間から数分に短縮され、レガシーコードに対し 4-10% の効率向上を実現しています。 【デプロイ環境】 デプロイ環境の最適化において、 AWS は新たに高スループット対応の Outposts rack および Cloud RAN 向けの Outposts server を発表しました。これにより、 AWS をオンプレミスに延伸し、低レイテンシ、高スループット、リアルタイム性能が求められる UPF/CU/DU をホストすることが可能になります。O2 Telefónica や Orange といった通信事業者がこれらの新しい AWS Outposts の導入や検証を予定しており、ネットワークのクラウド化を推進しています。 これらの事例は、生成AIやクラウドインフラの活用により、通信事業者のネットワーク開発・構築における課題解決と効率化が着実に進んでいることを示しています。 3. ネットワークオペレーションの高度化 |  Video アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信第一ソリューション部 ソリューションアーキテクト　宮崎　友貴 資料は こちら からダウンロード頂けます。 宮崎からは、通信事業者のネットワークオペレーションの高度化をテーマとして、通信事業者の運用における課題と、それらに対するAWSの生成AIやAI/MLを活用したソリューション事例についてお届けしました。 通信事業者は、監視、原因特定、復旧処置の各フェーズにおいて、 5G や Open RAN による複雑性の増加に伴う様々な課題に直面しています。これらの課題に対し、MWC 2025で展示/デモンストレーションされた、 AWS が通信事業者およびパートナーと協業したソリューション事例をご紹介しました。 以下に各社の解決事例の概要をまとめます。。 【SK Telecom】 SK Telecom は、日々検出される異常が多くノイズに埋もれる問題や、複数のネットワークドメイン・ベンダーによる一元的な把握が困難という監視フェーズの課題、および適切なリソース配分が必要な復旧処置フェーズの課題に対し、トラフィックデータを用いてスループットの予測を行う推論モデルにより、アプリケーションのリソースの自動スケールを実現しています。 RAN SMO への AI 活用に向け、 AWS が設計済の ML Platform ブループリント（IaC）を活用しています。 【NTT DOCOMO】 NTT DOCOMO は、ネットワークトポロジーが不明確で原因の切り分け・特定が困難という原因特定フェーズの課題に対し、 Amazon Neptune を活用した商用データでの検証では、動的に変化するネットワークトポロジーをグラフデータ化し、警報が同時に大量発生するような複雑な障害ケースにおいて、数千台以上の機器の中から障害被疑ノードを15秒という短時間で特定することに成功しています。 【StarHub/SUTD/SynDesignTek】 StarHub/SUTD/SynDesignTek は、監視から原因特定、復旧処置までの一連のフェーズにおける課題に対し、 Amazon Bedrock を活用し、ネットワーク構成と状態を理解したマルチ AI エージェントによる運用支援機能を備えた統合 O-RAN 運用ライフサイクルプラットフォームを構築し、トラブルシューティング時間を数週間から数分に短縮することに成功しています。 【O2 Telefonica】 O2 Telefonica は、監視フェーズにおける警報の集約、原因特定フェーズでの切り分け、そして復旧処置フェーズまでの E2E プロセスにおける課題（人手による作業のミスリスクや、マニュアル化されていない複雑な障害の復旧時間の長時間化）に対し、 Tech Mahindra が開発したAIを活用した自律型ネットワーク運用プラットフォーム（ANOP）を導入しました。これにより、アラーム集約やインシデント管理などの運用プロセス自動化を実現し、インシデント対応時間を40%以上改善、復旧までの平均時間（MTTR）を 30% 以上改善しました。 これらの事例では、 Amazon Bedrock（生成AI）、 Amazon SageMaker（機械学習）、 Amazon Neptune（グラフデータベース）といった AWS サービスを活用し、障害の検知時間/復旧時間の短縮、ヒューマンエラーの防止、運用コストの削減を実現しています。 4. ソフトウェア主導型のテレコムビジネスの変革 |  Video アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信第一ソリューション部 ソリューションアーキテクト　岡本　篤志 資料は こちら からダウンロード頂けます。 岡本からは、ソフトウェア主導型のテレコムビジネスの変革をテーマとして、通信事業者のビジネスオペレーションが抱える課題と、それらの課題に対して、生成 AI とともにクラウドに最適化されかつ通信業務に特化したパートナーのソフトウェアサービスを活用したソリューション事例、 AI エージェントとの協業を課題解決の手段として活用した事例ついてお届けしました。 通信事業者は、プロダクト開発/営業、販売/デリバリー、運用/サポートの各フェーズにおいて、ヒューマン主導型の様々な課題に直面しています。これらの課題に対し、 MWC 2025 で展示/デモンストレーションされた、 AWS が通信事業者およびパートナーと協業したソリューション事例を3つご紹介しました。 以下に各事例の概要をまとめました。 【WIM/Symphonica：デジタルブランドの立ち上げを加速】 AWS 上のAI主導のノーコードプラットフォームにより、メキシコ市場でデジタルモバイルブランドを 90 日という短期間で立ち上げを実現しました。 Amazon EKS上に構築したクラウドネイティブな OSS システムと、 Amazon Bedrock を活用したコネクター生成により、 5 分以内での簡単なモバイル接続体験を実現しています。 【Amdocs/NVIDIA： B2B サービスの収益化と運用革新】 AI駆動の統合された B2B 顧客体験により、営業からサービス提供までの効率化を実現しました。ビジネスフローに対する Agentic なオーケストレーションの適用とデジタルツインを活用し、ネットワーク展開計画を意識した営業の実現、運用コストの 30% 削減、サービス品質の最大 25% 向上、ネットワーク使用可能率の最大 15% 向上を達成しています。 【Radcom/ServiceNow： AI 制御の苦情予測とアシュアランス自動化】 AIによる苦情予測と顧客体験スコアの統合により、効率的な問題解決を実現しました。 Amazon SageMaker による顧客の苦情を予測するための AI モデルと、 Bedrock Agents を活用したカスタマイズされた AI モデル、 LLM 、ナレッジベースを使った RAG により、ネットワークチケット解決時間を 30% 短縮、予測型 AI によりチケット量を 40% 削減、解約率を 3% 改善しています。 これらの事例は、生成 AI との協業による自動化、ノーコード開発、生成 AI を活用した Agentic なオーケストレーション適用、オペレーション自動化、予兆監視/事前アクションといったソフトウェア主導型のアプローチにより、新規顧客の獲得、既存顧客の体験向上、解約リスク低減といった成果を実現しています。 5. 新しいビジネスユースケースの創出 |  Video アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信第二ソリューション部 ソリューションアーキテクト　川岸　基成 資料は こちら からダウンロード頂けます。 川岸からは、新しいビジネスユースケースの創出をテーマとして、通信事業者の立ち位置を活かしたビジネス変革の取り組みについてお届けしました。こちらでは、スマートホーム、 Network API、コンタクトセンター、エッジの活用の4つの領域における取り組みを AWS 活用のポイントを交えてご紹介しました。 以下に各領域の概要をまとめました。 【スマートホーム】 AWS は、センサー、カメラ、家電製品など、多様なタイプのデバイスの統合と制御を簡素化するための AWS IoT Device Management のマネージドインテグレーション機能 のプレビューを発表しました。通信テクノロジー企業である TELUS は AWS とのパートナーシップを基礎にマネージドインテグレーション機能を活用することで、 IoT デバイスを統合したシンプルな体験を実現する SmartHome+ プラットフォームを開発しました。 Telefónica の事例では、 AWS の生成 AI と IoT 技術、Alexa Smart Properties を組み合わせた在宅高齢者向け AI エージェントを開発しました。家族や友人との通話、ビデオ通話、メッセージ、写真共有などのコミュニケーション機能や、緊急通報、ヘルプ要請機能を提供し、高齢者の孤独防止と自立支援を実現しています。 【コンタクトセンター】 SMB向けの Amazon Connect を活用した SaaS コンタクトセンターソリューションでは、従業員が数人しかいないような顧客層でも利用できるコミュニケーションプラットフォームを提供します。30 分以内に専用のコンタクトセンターを立ち上げ可能で、生成 AI を活用したコールフローの自動生成や、 Amazon Location Services を使用した GPS での位置確認による現場作業員と顧客間のコミュニケーション改善を実現しています。 【Network API】 Deutsche TelekomとDroniq は、 Network API を活用して公共安全活動向けのドローンソリューションを開発しました。 Quality on Demand API を使用して帯域幅と遅延の保証をオンデマンドでリクエストし、ドローンのシームレスな運用を実現しています。また、 VerizonとAquimo は、 QoS Network API によるゲームトラフィックの優先制御を行い、スタジアム内の混雑した環境でも低遅延で高品質なゲーム体験を提供しています。 【エッジの活用】 Intel との協業により、 AI ハードウェアを搭載した宅内ゲートウェイに、エッジ環境に最適化された圧縮版SLMを実装しました。エージェントオーケストレーターが問い合わせの複雑さを判断し、大部分の問い合わせを端末上で処理することで、レイテンシー削減や帯域幅使用を最小化しています。 これらの事例は、通信事業者が持つユーザー、サービス、デバイスの接点を活かし、生成 AI 、IoT やエッジコンピューティングなどの最新技術を組み合わせることで、新たな価値創造とビジネス機会の拡大を実現していることを示しています。 まとめ 本ウェビナーでは、2025 年 5 月 15 日に開催した「テレコム業界向け： Mobile World Congress (MWC) 2025 Recap 」の振り返りとして、開催概要や発表の見どころ、お客様事例をご紹介しました。セミナーにご参加いただいた方、誠にありがとうございました。ご参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考としてお役立ていただければ幸いです。ご質問やご要望がございましたら、 お問い合わせページ 、もしくは担当営業までご連絡をお願いします。 このブログの著者 林　文傑 (Bunketsu Hayashi) アマゾン ウェブ サービス ジャパン 技術統括本部　ストラテジックインダストリー技術本部　通信グループ　通信ソリューション第二部 ソリューションアーキテクト

みなさんこんにちは。ソリューションアーキテクトの落水です。 2025 年 5 月 29 日に「 Amazon EKS Auto Mode で Kubernetes の運用をシンプルにする 」というオンラインセミナーを開催しました。 本セミナーでは、Amazon EKS の新機能 Amazon EKS Auto Mode を掘り下げ、Kubernetes の運用がどのようにシンプルになるのかを紹介しました。また、実践的な内容として、EKS Auto Mode 利用時のノードの自動更新や EKS Auto Mode への移行方法などについても詳しく解説しました。 セッションの紹介 Amazon EKS Auto Mode で Kubernetes の運用をシンプルにする AWS ソリューションアーキテクト 鈴木 祥太 資料ダウンロード AWS ソリューションアーキテクトの鈴木より、Amazon EKS Auto Mode が登場した背景や、Amazon EKS Auto Mode による責任共有モデルの変化など EKS クラスターの運用体験がどのように変わるのかを紹介しました。Amazon EKS Auto Mode が提供するコンピューティング、ネットワーキング、ストレージ、セキュリティといったクラスター機能についても解説しています。Amazon EKS ならびに Amazon EKS Auto Mode をこれから活用していくという方は、ぜひこちらの資料をご確認ください。 Amazon EKS Auto Mode への移行手法を詳解 AWS ソリューションアーキテクト 落水 恭介 資料ダウンロード AWS ソリューションアーキテクトの落水より、既存の EKS クラスターにおいて Amazon EKS Auto Mode へワークロードを移行する方法について紹介しました。マネージド型ノードグループや Fargate、Karpenter などコンピューティング環境の管理方法ごとに移行手順を詳細に解説しています。また、Amazon EKS Auto Mode への移行における考慮事項についても説明しています。Amazon EKS Auto Mode への移行や検証を予定している方は、ぜひこちらの資料をご確認ください。 EKS Auto Mode とノードの終了 AWS シニアソリューションアーキテクト 林 政利 資料ダウンロード AWS ソリューションアーキテクトの林より、Amazon EKS Auto Mode のノードのライフサイクル管理に関する詳細な解説を行いました。Amazon EKS Auto Mode ではセキュリティの観点から AMI の定期的な更新を行うため、ノードのライフサイクルに対して考慮事項が発生しますが、Pod Disruption Budget や terminationGracePeriod などを適切に設定することでワークロードを安全に実行できます。Amazon EKS Auto Mode を利用中あるいは移行を検討している方は、ぜひこちらの資料をご参考ください。 まとめ 本セミナーでは、Amazon EKS Auto Mode をテーマに基本的な内容から発展的なトピックまで幅広くご紹介いたしました。今後も引き続き、様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。

みなさん、こんにちは。ソリューションアーキテクトの松本です。この記事では、 三菱重工業株式会社 （以下、MHI）、 三菱重工機械システム株式会社 （以下、MHI-MS）が生成 AI を活用して大きな事業価値を創出していくために歩まれている旅路をご紹介します。その旅路は、Step1 : 生成 AI の全社活用を推進する戦略や AI Center of Excellence (AI-CoE) 体制の策定、Step2 : 事業価値ある生成 AI のユースケースの特定、Step3 : ユースケースのプロトタイピングと 3 つのステップを進んできています。AWS と共に歩んだ 3 つのステップを、エンタープライズにおける生成 AI 活用のアプローチとしてご紹介します。 三菱重工業株式会社について 創業 100 年を超える MHI は、日本のものづくりの代表的企業です。4 つの事業領域で 500 以上の製品（発電用タービン、CO2 回収、造船、航空、防衛、宇宙など）・技術を保有しています。そして信頼と実績のある製品や技術をデジタルを活用して変革すべく、ΣSynX というブランドで様々なソリューションの提供を開始しています。2024 年には DX グランプリを受賞しました。 MHI・デジタルイノベーション本部（以下、DI 本部）は MHI グループ全体の情報システム部門であり、DX 推進の中心として生成 AI の可能性を探索していました。 三菱重工機械システム株式会社について 三菱重工機械システム株式会社は、1968 年に設立された三菱重工グループで最多の事業、製品、技術を有し、設備インフラ事業本部、モビリティー事業本部、印刷紙工機械事業本部の 3 事業本部で構成されており、メカトロニクス技術を核に、社会生活を支える高品質で安全な設備や機械装置、サービスを提供しています。 また、少子高齢化による労働人口の不足やお客様の更なるニーズに応えるため、近年は DX 化を加速させ、より付加価値の高い製品の開発やサービスの創出にスピード感を持って取り組んでいます。 Step 1 : 戦略と体制を策定する DI 本部はグループ事業会社に生成 AI のチャットアプリケーションを既に提供していました。それにより生成 AI の利用者が増え、利用者は便益を実感し、利用者から活用を拡大していきたいという声が高まっていました。DI 本部は全グループ事業会社に生成 AI の便益を展開していきたいと考えていましたが、様々な課題を解決していく必要がありました。課題とは、事業価値あるユースケースを特定していくこと、ナレッジやシステムを共有して投資効率を向上していくこと、安全な利用のためのガバナンスを整備していくこと、人材や能力を強化していくこと、推進体制を確立していくことなどが挙げられます。各課題は相互に関係し合うため、個別に解決するのでなく、複合的に解決していく必要がありました。そこで、AWS Professional Services を利用し、生成 AI の全社活用を推進する戦略や体制（ AI-CoE（AI Center of Excellence） ）の策定に着手しました。AWS の生成 AI の導入フレームワークである CAF-AI (AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI) を活用しながら、2 〜 3 ヶ月に渡って議論を積み重ね、戦略・行動計画・体制を明確にしました。 策定した戦略で特徴的なことは、 オペレーティングモデル を、各グループ事業会社が個別に主導する分散型でなく、DI 本部とグループ事業会社が連携する連携型に移行していくことを考慮しながら、DI 本部が主導する中央集権型から開始することです。具体的には、グループ事業会社の生成 AI のユースケース特定やシステム開発を、DI 本部が先導するというものです。 Step 2 に向けて : DI 本部とグループ事業会社が連携する 戦略を実行するために、DI 本部とグループ事業会社の連携を開始し、最初に連携したのが MHI-MS となります。DI 本部と MHI-MS は数年前から DX を協同しており、挑戦する土壌が整っていました。 MHI-MS で DX を推進されている技術戦略室の松岡室長は、DI 本部と連携して生成 AI の活用を加速されたことについて、次のようにコメントしています。 「人材不足が深刻化する中で生成 AI の活用は業務の効率化やイノベーション創出において極めて重要な役割を果たす手段であり、競争力を強化する上でもいち早く導入するべきと考えています。」 Step 2 : 生成 AI のユースケースを特定する MHI-MS にとって事業価値のある生成 AI のユースケースを、Professional Services による数日間の「生成 AI デザインワークショップ」を通じて特定しました。このワークショップは Amazon 流のイノベーション創出メカニズム「Working Backwards」をもとに、生成 AI が適したユースケースを創出・発掘するためのワークショップです。MHI-MS の経営者層が参加する前半と、事業の現場を理解している事業部門と生成 AI 等のデジタル技術を理解しているデジタル部門のいずれも実務者層が参加する後半の 2 つから構成されます。 前半では、MHI-MS の経営者層が AWS のファシリテーションのもと議論を重ね、1) 事業目標を改めて特定し、2) 目標を達成するために解決すべき課題や目標達成の判断に用いる指標を特定し、3) 解決するためのアイデアの仮説を立て、4) 組織的に生成 AI 活用という挑戦に取り組んでいくために大切にしていく価値観や姿勢についての指針となる文書を作成します。事業目標から議論を開始することで、生成 AI という手段で何ができるかではなく、事業価値創出のために生成 AI という手段をどう活用するか、という観点が一貫します。その観点に基づいた解決策と、挑戦に向けた姿勢に関する文章が作成され、後半の実務者層に引き継がれます。 この前半には MHI-MS の全 CxO と全事業本部長が参加され、事業目標がしっかりと反映された 3 つのユースケースが特定されました。 後半では、実務者層が前半の結果を引き継いだ上で、Amazon のイノベーション創出メカニズムである「Working Backwards」に基づいて議論を重ねます。1) ペルソナを具体化し、2) ユーザージャーニーにおける課題を特定し、3) 具体的な解決案を創出し、4) Amazon のイノベーション創出のための文章である「PRFAQ」の作成や、ペーパープロトタイピングを通じて、解決案をより具体化し、5) MVP（顧客に価値を提供できる最小限のプロダクト）を計画します。 このワークショップにも全ての事業本部が参加しました。また、事業本部毎にチームを組成するのではなく、課題毎に事業本部混成でチームを組成し、多様な視点で解決案の具体化が図られました。 このワークショップの特徴の一つである PR/FAQ (プレスリリースとよくある質問) の執筆について簡単に触れておきましょう。お客様を起点に逆算の発想でアイデアを整理するこの手法では、実際に開発に取り掛かるまでに、最も重要な「対象となるお客様は誰か」「彼らは何を必要としているのか」にフォーカスすることができます。 初めて触れるこの手法に戸惑いを覚える方もいますが、今回ワークショップに参加したメンバーには「まずやってみよう」という前向きなマインドがありました。新しいことを前に腰が引けてしまうのではなく、「まずやってみよう」が先にくる人であることが成功条件の一つなのかもしれません。 そして Day 1 から約 2 ヶ月後に開催した報告会では、実務者層から経営層に対して生成 AI をどのように導入し、どれほどの事業価値を創出していくか、次段階のプロトタイピングに移行していくユースケースを報告しました。報告会の講評には Day 1 に参加した経営者層が出席し、その全員が Day1 からの深化に好意的な評価を述べていました。参加者がワークショップを通じて練りに練った 3 つのユースケースとそのソリューションは、生産性向上 (費用削減) を実現するだけでなく、売上向上を実現していくストーリーが盛り込まれ、効果の規模や確実性等の観点から、3 つのユースケースのうち、まずは 2 つについて次段階のプロトタイピングに移行することが決定しました。 実務者層の MHI-MS・角倉主席は、具体化したユースケースについて、次のようにコメントしています。「異なる製品を取扱うメンバーで一つのユースケースについて検討を進めてみると、想像していた以上に共通の課題があることが分かりました。共通の課題に対して、様々な角度から解決のアイデアが生まれ、短い時間で複数の課題を解決するソリューションが提案できました。」 経営者層の MHI-MS・高畠 CTO/CDO は、所属組織が混成のチームにも関わらず活発なコラボレーションがなされたことについて、次のようにコメントしています。「当社は、それぞれのメンバーが、違った製品に関わっています。そのため育った環境も違うため、いろいろな発想ができるという強みがあります。こうしたメンバーが連携を深めていくことで、企業価値を向上させようという狙いがありますが、今回の活動は、まさにそうした狙いに合ったものになりました。」 Step 3 : ユースケースをプロトタイピングする Step 2 で特定された生成 AI ユースケースのフィジビリティを検証するため、Professional Services による 2 ヶ月間の「生成 AI プロトタイピング支援」を活用してプロトタイピングを進めました。 このプロトタイピングでは「EBA (Experience Based Acceleration)」という方法を採用しました。EBA とは、参加者がみずから手を動かしてプロトタイピングを行い、AWS メンバーがその伴走をすることで、プロトタイプというアウトプットを生むだけでなく、アウトプットを継続的に生んでいける能力を育むものです。 EBA ではユースケース毎に開発チームを組成します。各チームは MHI-MS の事業部門のメンバーが Product Owner を務め、DI 本部のデジタル部門のメンバーが開発者を務めました。PO を務めた事業部門のメンバーはこれまで PO だけでなく、システム開発経験がない方が大半であり、新たなロールに挑戦されました。開発者を務めたデジタル部門メンバーは日常的に AWS を用いて開発業務をおこなっているエキスパート開発者と、経験の浅いチャレンジャー開発者から構成されました。エキスパート開発者は、MVP と言えども多くの機能や高い性能が望まれていたので、それらを 3 日間で実現することに、チャレンジャー開発者は実装スキルを早期に取得し、貢献できる範囲と量を拡大することに挑戦していきました。 前半の 1 ヶ月半は、チームビルディング、生成 AI 開発やアジャイル開発に必要なスキルの取得、バックログの定義、環境やデータの準備を進めます。生成 AI のプロトタイピングで特に重要となるのが、データの準備です。必要となる事業部門のデータを特定してシステムからデータを抽出し、必要に応じてデータの前処理を行いました。開発者は、高い性能の実現や、その評価のため、例えば Advanced RAG や LLM-as-a-Judge に関連したナレッジやスキルを取得していきました。また開発者だけでなく PO も、プロンプトエンジアリングのスキルを取得していきました。 そして本番の 3 日間は全員が一同に会し、コーポレートカラーである赤色のパーカーに身を包んで共同作業に取り組み、プロトタイプ完成を目指しました。参加メンバーがデザインしたこのパーカーにはファースト・ペンギンのイラストが描かれ、失敗を怖れずに勇気を持って挑戦しようという全員の意思が反映されていました。 実装では、エキスパート開発者だけでなくチャレンジャー開発者も大きく貢献しました。加えて、開発者だけでなく事業部門の PO もプロンプトエンジニアリングを駆使して機能の追加や性能の向上に貢献しました。完成したプロトタイプの水準の高さに関する参加者からのコメントは後述します。 そして、最終日である 3 日目には 2 チームとも計画していた以上の機能が実装されたプロトタイプが完成し、フィジビリティが検証でき、次段階のプロダクションに移行することが決定されました。 チャレンジャー開発者の DI 本部・平尾社員は、実装スキルの取得について、次のようにコメントしています。「AWS Professional Services の伴走支援のもと、EBA という実践形式で未知の技術領域に挑み、自ら手を動かしながら短期間で大きくスキルを高めることができました。また、この経験を通じて、技術への向き合い方や考え方にも大きな変化が生まれたと感じています。」 エグゼクティブスポンサーの MHI-MS・小嶋 CEO は、次のようにコメントしています。「AI を用いた実務への展開はこれからの省力化・省スキル化には欠かせない要素になると考えています。またこの AI 技術も事業環境の変化もこれまで以上に加速していくのでスピード感を持って改善していく必要があると考えています。そういう意味でも関係者が集まり短期間でプロトタイプモデルを作成する手法は大変整合性があると思っています。」 今後の展望 半年に満たない期間にも関わらず、生成 AI ジャーニーの歩みを Step 1から 3 へと進められました。Step 4 としてプロダクションへの移行も歩み始めました。今回参加したファースト・ペンギンからのバトンをつなぐべく、第 2、第 3 の事業部門への展開も計画されています。 エグゼクティブスポンサーの DI 本部・日浦部長は、次のようにコメントしています。「生成 AI という新たな技術に接して、これをどのように経営に生かしていけばよいのか、悩みを抱える部門は多くあります。各部門の経営を預かるリーダ層、現場を知悉する実務層、デジタル技術に日頃接する開発者が集中的にワークする本手法は、DX 推進の強力な武器として期待を集めています。既に第 2 弾に着手していますが、この手法を我々自身でも推進していけるように取り込み、根付かせていきたいと考えています。」 エンタープライズ企業が、DX グランプリ 2024 受賞企業である MHI の生成 AI の旅路から学べることは多岐に渡ります。生成 AI のインパクトを全社の事業の最前線に展開していく段階で戦略を明確にすること、デジタル部門と事業部門が連携して取り組む体制を構築すること、事業価値からユースケースを特定すること、俊敏にプロトタイピングをして合目的性を検証すること、取り組みのなかで個のスキルやチームのコラボレーションを開発すること、そして何よりファースト・ペンギンとして実験に挑戦すること、などが挙げられます。 生成 AI の真価は、技術そのものではなく、事業価値に変換できるかどうかにあります。生成 AI を活用した事業価値の創出について、AWS の担当者に是非ご相談ください。今回の記事のように、貴社ならではの価値創出の旅路をサポートいたします。 松本 修一 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。

本稿は、株式会社ドワンゴ（以下、ドワンゴ）におけるクラウド環境のセキュリティ改革をリードされた青木 良樹様/結城 清太郎様/坂井 薫平様に寄稿いただきました。 はじめに 株式会社ドワンゴ は（以下、ドワンゴ）、デジタルテクノロジーによって新たな価値を生み出し続けるエンターテインメント企業です。当社の事業の中でもニコニコ事業は国内有数の動画・生放送配信プラットフォームとして多くのユーザーおよびクリエイターの皆様に愛され、ご利用いただいています。本稿はそんなニコニコ事業における従来のセキュリティ対策に加え、2024年6月初旬に発生したサイバー攻撃を契機に取り組んだセキュリティ改革の概観を紹介するものです。 改革の経緯 ニコニコ事業はインフラストラクチャの大改革として従来のオンプレミスから AWS への全面移行を推し進めてきており、その過程の一部を過去の AWS Summit でも発表してきました。AWS への全面移行には「開発・運用効率の向上」「多種多様な技術的選択肢の獲得」といった目的がありつつも、これまでのオンプレミスを前提としたインフラストラクチャ技術とは異なる観点での技術的な投資が必要になります。とりわけセキュリティ分野については2022年の移行開始当初より優先度の高い技術領域として、積極的な取り組みを進めてきました。その甲斐もあって、2024年6月初旬に発生したサイバー攻撃では、AWS 環境への攻撃者による侵害行為を未然に防ぐことができたものと考えています。サイバー攻撃以前より推し進めてきた取り組みについて、具体例をいくつか紹介します。 ・社内標準となる「セキュリティガイドライン」の策定・展開 ・ AWS Trusted Advisor や AWS Security Hub を用いた「予防」的な攻撃対策の導入 ・重要度の高いサービスにおける Amazon GuardDuty を用いたインシデント管理フローの策定・運用 ・ AWS CloudTrail による AWS Organizations 内のユーザーアクティビティの監視 「セキュリティガイドライン」についてはサービスにおけるセキュリティ対策の社内標準として現在も活用されています。これらの取り組みの一部は AWS Summit Tokyo 2023 での当社 七田によるセッション でも触れられているため、興味のある方は参照いただければと思います。 事前の対策が奏功したと考えられる一方、サイバー攻撃はニコニコの AWS 全面移行の道半ばで起こった出来事です。ニコニコを復旧するにはオンプレミスで稼働していたシステムを AWS 上で再構築する必要があることに鑑みれば、AWS 環境の重要度がこれまで以上に増していくことは明らかです。私たちはこれを契機に AWS 環境における大規模なセキュリティ改革に取り組むこととしました。 採用ソリューションと構成 サイバー攻撃の発生時、私たちは直ちにオンプレミスと AWS の間のネットワークを切断し、一部のメンバーを除くすべての開発者によるサインインを無効化すると共に、当時の AWS 環境において侵害行為と思しき挙動が見られないことを確かめるべく、AWS 環境の総点検を実施しました。総点検の結果、幸いにして AWS 環境に攻撃者の侵害が及んでいないと判断することができました。総点検によって安全性を確認した後も予断は許さない状況です。先述の通りニコニコの AWS 全面移行は道半ばであり、ニコニコを復旧するには AWS への移行が完了していない全てのシステムについて、それらを AWS 環境上で再構築する必要があることが早い段階で明らかになっていました。これは言い換えると「従来以上に AWS 環境のセキュリティが事業に与える影響が増すこと」を意味します。また、一度安全性を確認した後も私たちを取り巻く環境は常に変化していくことから、継続的にセキュリティ対策を維持・向上させていく必要があると考えました。 そこで、社内の AWS チーム・セキュリティチームに加え、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）のアカウントチーム・スペシャリストチームが一丸となって、AWS 環境のセキュリティレベルの向上に取り組むこととなりました。セキュリティレベル向上に取り組んだ結果として作り上げられたのが次に示すセキュリティプラットフォームです。従前のセキュリティ対策を拡張する形で実現されたものになります。 前提としてニコニコでは、 AWS Control Tower と AWS Organizations を軸に据えたマルチアカウント・アーキテクチャを採用しています。マルチアカウント・アーキテクチャについては AWS Well-Architected フレームワークの考え方 に則り、システム・環境の組み合わせによって AWS アカウントを作成・管理するようにしています。 各 AWS アカウント上で採用される AWS サービス・技術スタックはニコニコの各システムを担当するチームの裁量に委ねられていますが、AWS 環境のセキュリティレベルを包括的に高めようとする場合、すべての AWS アカウントに対する統一的なセキュリティベースラインを敷くことが重要です。ニコニコではセキュリティ対策の基本思想として「予防 (Prevention)」と「検知 (Detection)」の二点に着目し、設計を推し進めました。 予防（Prevention） 「予防」のフェーズではニコニコをサイバー攻撃から守るために重要な役割を果たすソリューションを採用します。図中にもある通り、 AWS Security Hub や AWS Trusted Advisor のような AWS におけるセキュリティ・ベストプラクティスに違反する項目を検査する AWS サービスを積極的に採用、すべての AWS アカウントの違反項目を精査し、セキュリティベースラインの底上げを図りました。これらのサービスはサイバー攻撃以前より導入しておりましたが、このタイミングで違反項目への対策をより一層強化しました。また、AWS Organizations の機能である Service Control Policy を導入することによって、各チームのアジリティは維持しつつ、 各 AWS アカウントにおける不必要かつセキュリティホールとなりがちな操作を一元的に制限しています。この方法によって、文字通りの越えてはならないガードレールのような境界を引きつつ、そのルールを逸脱しなければ、その内側での自由な往来を認めるような形での運用を取り、制限と運用効率に関するバランスを取ることができています。ここで触れられているのはあくまで一例ですが、サイバー攻撃による被害を未然に防ぐにはこうした従前の対策が最も重要であると考えられます。 検知（Detection） しかし、いかなる対策も完全とは言えません。サイバー攻撃の手法は日夜研究されており、常に新しい手法が生まれ、世の様々なシステムに対してその手法が試行されています。いつの日にか攻撃者が、私たちの講じた多層防御を突破する可能性を完全に否定できるわけではありません。そこで、実際に攻撃が発生した場合にそれを速やかに「検知」し、その攻撃を封じ込める必要が生じます。このフェーズでは GuardDuty を用いた脅威の検知を基本線に置きつつ、CloudTrail によるすべての AWS アカウントのユーザーアクティビティの監視を通じ、不審な行動を即座に検知可能な仕組みを設計しています。何らかの不審な行動が見られた際には即座に社内外の連携先に通知が届き、速やかにインシデントの分析にあたることができるようなフローを設計しています。 インシデントを検知した際の分析・対処の流れについて ここまで説明してきたセキュリティの基本設計を前提に、実際にインシデントが発生した際の対応にまつわる部分について説明します。 先述の通り、検知した不審な行動は複数の連絡手段に対して通知され、インシデントの分析が開始されます。インシデントの分析の結果、それが攻撃であると判断されれば、被害の拡大を防ぐために速やかに対処します。しかしながら、このような運用は常に新しい脅威へのキャッチアップを続け、更には24時間体制での迅速かつ高い精度での対処が求められるものです。こうした対処の品質にまつわる課題について、外部のセキュリティ事業者の協力による強化を図ることで、効率的かつ合理的な体制の構築を目指しました。メインのトラブルシューターは自社のエンジニアが担いつつも、外部のセキュリティ専門家による支援が受けられる体制を整備しました。 また AWS re:Invent 2024 では、検知の機能に加え、実際のインシデント分析を強化可能な AWS サービスとして、 AWS Security Incident Response が発表されました。早速ニコニコではこのサービスの導入を進めています。このサービスを導入することで、単なる脅威の「検知」機能に留まらず、発生したセキュリティ検出結果のトリアージと調査を自動化し、AWS のセキュリティエンジニアと24時間連携できるなど、セキュリティインシデントの復旧に向けてサポートを受けることができます。AWS ・セキュリティの両分野における専門家が、実際に AWS アカウント上のリソースレベルで一緒に分析にあたってくれるなど、ニコニコのような24時間体制で事業を展開する企業にとって非常に心強いサービスになっています。 導入の効果と所感 ここまでの説明から、サイバー攻撃に端を発する一連の流れの中で、従前の対策に加えて多くの AWS サービスを採用し、セキュリティ改革に取り組んできたことがご理解いただけたかと思います。セキュリティレベルの向上を目的に AWS サービスの採用を決めること自体は決して難しいことではありません。しかしそれに留まらず、採用を決めたサービスを中心としたアーキテクチャや運用フロー、更にはそのサービスの利用に伴い発生する費用などの要素についても考えを及ぼさねばなりません。 AWS のセキュリティ系サービスには、そのサービスの ON / OFF に加え、サービス内の機能を細かく制御できるオプションが豊富に用意されています。 GuardDuty を例にとると、同サービス内には「S3 プロテクション」「ランタイムモニタリング」のように複数の保護プランが用意されており、保護する対象を細かに制御することが可能です。このような機能レベルの柔軟性によって「いま自分たちにできること・必要なこと」に着目し、現実的な費用感でセキュリティレベルの向上を図ることができたのではないかと考えています。また、実際の導入に向けたアーキテクチャの設計では、最初に基礎となる運用フローを定義した後、メインの AWS サービスだけでなく Amazon Simple Notification Service などの接着剤となる AWS サービスを積極的に活用するよう努めました。これによって開発工数を削減でき、導入に至るまでのスピードを大幅に加速できたと感じています。導入時にはいくつもの工夫を凝らして構築を進めたため、それらのエピソードについてもいつか別の機会にお話できればと思います。 セキュリティレベルの向上という観点では、実際に攻撃と思しき挙動を未然に防ぐことができているのはもちろんのこと、ニコニコのセキュリティ対策の有効性を外部のセキュリティ事業者を交えて客観的に評価いただいています。加えて AWS Security Incident Response や GuardDuty といった AWS サービスによる不審な行動の検知については、現実的に起こり得る攻撃シナリオを想定した場合に有効なセキュリティ対策としてその価値を発揮してくれていると感じています。 むすび 幸いにしてニコニコの AWS 環境には、2024年6月初旬に発生したサイバー攻撃による侵害が及ぶことはありませんでした。しかし、AWS だからといって何もせずとも完全無欠なセキュリティ対策が実現可能なわけではありません。AWS の 責任共有モデル にもある通り、顧客が責任を負わねばならない領域については、顧客自身の手によってセキュリティ対策を講じる必要があります。AWS には、私たち自らがセキュリティ対策を講じる際に役立てることができる豊富なサービスがあり、また、その導入を手助けしてくれる強力なアカウントチームが存在します。紹介した事例は AWS を利用する立場にあるニコニコがセキュリティ改革に取り組んだものですが、この改革は AWS の豊富なサービス・アカウントチームによる協力なしには実現できなかったと考えられます。本稿をお読みいただいている皆様も、自身の担当するシステムのセキュリティ対策を考える際には AWS ジャパン に相談することを強くおすすめします。 KADOKAWA グループではグループを横断的にサポートするエンジニアリングチームが中心となって、今回紹介した事例を基にした包括的なセキュリティ対策を進めています。しかし、先述のようにセキュリティ分野における攻撃手法の多様性は増す一方です。ニコニコを含む KADOKAWA グループはここで歩みを止めることなく、今後も自社の展開するサービスのセキュリティレベル向上に持続的に取り組んでいきます。今後ともニコニコならびに KADOKAWA グループの提供するサービスをご愛顧いただけますと幸いです。 著者 青木 良樹 株式会社ドワンゴ　技術本部　クラウドエンジニアリング部　部長 結城 清太郎 株式会社ドワンゴ　グループ基盤サービス本部　クラウドサービス部　部長 坂井 薫平 株式会社ドワンゴ　技術本部　本部長

本ブログは、宇宙航空研究開発機構 (JAXA) へのインタービューを元に、 Amazon Web Services Japan (AWS) が執筆しました。 JAXAは政府全体の宇宙開発利用を技術で支える中核的実施機関として、宇宙航空分野の研究開発に取り組んでおり、その中でも本ブログで登場します宇宙輸送技術部門は、地球と宇宙を結ぶ輸送手段である「ロケット」を扱う部署になります。基幹ロケット開発や、コスト低減・高い信頼性・柔軟なサービスの実現を目的として研究開発に取り組まれています。今回はロケットのデジタル化活動の一環としてJAXAで行ったDX (デジタルトランスフォーメーション) を目指した技術実証の取り組みについて紹介します。 課題と背景 衛星の用途に応じて打ち上げる軌道など異なるため、ロケットのミッションは打ち上げごとに異なります。そのためロケットミッションごとにシミュレーションを行う必要があります。これまでロケットミッション解析にはオンプレミスでサーバを用意して利用されることが多く、JAXAの宇宙輸送技術部門でも同じようにオンプレミスにサーバを解析用に用意して利用していました。 ロケットミッション解析では、解析時間分の待ち時間が長いことも課題でした。今回対象とする計算はモンテカルロ法の計算が中心となります。1ケースあたりは数分程度と短い処理ではありますが、通常は1パターンにつき数十万ケースの計算が必要です。さらに複数のパターンを扱うことが多く、数パターンとなると100万ケースを超える計算を行わなくてはなりませんでした 解析を実施したい時期が集中すると、限られた計算リソースでは迅速に解析を進めていくことは難しく、必要な解析ケースの検討に時間をかけ、最低限の解析を実施することが通例でした。また、複数のミッションを同時期に解析する必要がある場合などは限られた計算リソースでは長い解析時間分の待ち時間が生じることもあり、一方で最大必要計算リソースに合わせてオンプレミスのサーバを準備するとコストが過大となる問題もありました。 このように解析時間を短縮する必要に迫られている中で、クラウドを活用できないかを考えることになりました。セキュリティを確保し必要なだけ計算リソースを確保しつつ、コスト低減を図る必要がありました。リソースを都度購入していたのでは、そのセットアップや維持など含め時間やコストがかかってしまいます。そのためこれまでオンプレミス環境で行っていた計算を AWS を使って実施してみることにしました。また要件によっては日本国内の計算リソースで実施したい場合も出てくると考えられたため、今回はAWS上の日本国内のリソースを使って実証することになりました。 検討した事項と実際のシステム概要 これまでと別の環境でシミュレーションや解析を行う場合には、これまでと同一の結果となるかの検証が必要となります。またどの程度リソースを確保していくかということも検討する必要があります。 既存環境はx86系のCPUを利用していましたので、AWS上でも同様にx86系のCPUが搭載されたAmazon EC2 インスタンスで試すことになりました。現在のオンプレミスの環境にまずはそろえる形でスタートし、CPUコア数やメモリを増やしていく形でのテストを行いました。また複数台を連携した計算についてもテストを実施しました。メモリよりもCPUコア数が必要であるワークロードであり、コスト最適化の観点からも今回の実証ではC7i系のインスタンスを中心に利用することとしました。実際にシステムをAWS上で実行し、これまでのJAXAの保持していた解析内容とクラウド上での解析結果を比較し、完全一致することが確認できました。同じx86系であるため予想通りではありましたが、これでAWS上のインスタンスを安心して使うことができることになります。 AWSであればインスタンスを一度停止すればCPU、メモリのサイズを変更して同じ起動ディスク環境で起動できるため、その時に必要な性能で利用することができるので、オンプレミスで購入していた時に比べて柔軟性が増しますし、必要な性能に合わせて拡張も縮小もできる点が利点となります。またAWS上では必要に応じて複数インスタンスを利用して並列で処理することもできるため、解析時間の短縮になりますし、利用した分だけとなるため、2倍のリソースを使って計算しても時間が半分になれば、ほぼコストは変わらない試算が可能となります。最終的には100万近いケースをシミュレーションして解析する必要がありますが、それぞれ並列で実行できるため複数環境を並列で利用して時間短縮を行うことができます。 実際に実証で利用した構成が下記となります。実際に計算で利用するインスタンス群は、プライベートサブネットに置き隔離された状態で実行されます。セキュリティ確保の面からもAWSのマネージドサービスであるAWS Systems Manager の Session Manager の機能を使いインスタンスへログイン等をしています。複数台利用する場合には、ヘッドノードからデータを計算ノードへ転送し処理を実行します。ヘッドノード自体も計算ノードの一部として機能します。今回はクラウドの利用検証ということもあり、特に実行する環境やプログラムはオンプレミスで利用していたものと同様にセットアップしているため、AWSのインスタンスを最大限活用するような設定等の最適化はしていません。  図1 検証システム構成図 ((主なサービスを記載) 導入効果と今後の展開 今回の実証では45万ケースの解析処理を単位として比較を実施しました。既存で保有しているオンプレミスでの計算環境とAWS上に構築した環境でほぼ同等のCPU、メモリの場合で比較した場合、40％実行時間を削減することができました。これは既存オンプレミスでは様々な処理に使うため、多くのライブラリや所内インフラに接続するためのセキュリティ設定などががされていますが、AWS上では閉じた構成で必要なライブラリだけを入れたシンプルな構成にできたこと、AWS上では新しい世代のCPUを使えるなどの結果と考えられます。 オンプレミス環境よりも潤沢にリソースを使えることから、併せて複数台利用した並列処理も実施しました。その結果、3台のEC2を利用して計算に物理コア数384を利用した場合では、オンプレミスの20倍以上処理を早く完了でき、10時間を切ることができました。コストに関しても必要な時にだけ立ち上げることで必要経費を抑えていくことができる目処が立ちました。パターン数が増えた場合などは、仮想ディスクに相当するEBS (Amazon Elastic Block Store) を複製して同一環境を立ち上げることができるため、数十分で新たな環境を作成できることも実際に確認しました。 一方で、物理コア数384を利用した場合に頭打ちになっている状況が見られました。前述のようにオンプレミスと同様の設定であるため、複数インスタンス利用時のデータ送信などの多重化等の最適化が実施できていないなどの点が原因として上げられます。また、これまで実施していなかった環境であるため、CPU、メモリの比率などについても十分に精査できていないため、最適な環境を見つけられていない可能性もまだあるかと考えられます。インスタンスの選定も今回はコスト重視で検証を実施したためC系のインスタンスとしましたが、最大サイズのインスタンスの利用が混み合う場合には、別のタイプ、例えばMやR系などのインスタンスや、サイズを落として台数を増やすなどの戦略が考えられると思いますが、それらについてコスト、性能、時間の観点で検証を進め、最適化していけると良いと考えられます。またArm系のインスタンスもコスト効率化の意味で選択肢にも入ると考えられますので、これまでと同一結果になるかなどの検証もできれば考えています。 解析によっては、海外リージョンも利用してリソースの確保やコスト最適化もできる場合もあるかと考えられますので、実際の利用にあたっては要件やコストに応じて選択していけると良いと考えられます。 まとめ オンプレミスで実行していたロケットミッション解析をクラウドで実施するための検証をAWS上で実施し、AWS上の環境においてもオンプレミス上で実施していたのと同一の解析結果となることを確認できました。また、AWS上の環境を利用することでこれまで10日近くかかっていた解析を半日で実施できるなど、解析処理の迅速化だけでなくコスト最適化等の可能性も見いだすことができました。今回はクラウドを利用した場合の効果についての最初の検証ができたと考えられます。さらなる高速化や安定的な運用ができる可能性が残されているため、それらについて今後検証等実施していければ良いと考えられます。 これまで解析には時間がかかるというのが常識でしたが、解析処理を高速化してこれまで10日近くかかっていた処理が1/20以下となる半日以下で実現できました。これをさらに高速化していき、数時間、あるいはもっと短縮して数十分で見られる世界が実現できていけば、仕事の仕方も大きく変えるDXができ、本来注力したい事項に集中できることが期待されます。 この記事を書いた人 櫻田 武嗣 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター シニアソリューション アーキテクト “業務や研究内容に適したシステム構成のディスカッション等を通して技術面から皆様にご支援をしております”

5 月 27 日は、皆さんに Amazon Aurora DSQL の一般提供開始についてお知らせします。Amazon Aurora DSQL は、常時利用可能なアプリケーション向けの最高速のサーバーレス分散 SQL データベースで、実質上無制限のスケーラビリティと最高レベルの可用性を備えており、インフラストラクチャの管理は不要です。パッチ適用、アップグレード、メンテナンスのダウンタイムによる運用上の負担をなくすだけでなく、簡単な手順をいくつか行うだけで新しいデータベースを作成できる、使い勝手の良い開発者エクスペリエンスも確保できます。 AWS re:Invent 2024 で Aurora DSQL のプレビュー が発表されたときは、複雑なリレーショナルデータベースの課題を単純化するこの革新的なソリューションにお客様から大きな期待が集まりました。基調講演では、Amazon.com の CTO であるワーナー ヴォゲルス博士が、Aurora DSQL の設計内で複雑性を前もって管理することについて話しました。ほとんどの従来型データベースとは異なり、Aurora DSQL は、query processor、adjudicator、journal、crossbar などの複数の独立したコンポーネントに細分化されています。 これらのコンポーネントは凝集性が高く、明確に指定された API を介して通信し、ワークロードに基づいて単独でスケールします。このアーキテクチャは、低レイテンシーとグローバルな時刻同期で、複数のリージョン間における強固な一貫性を実現します。Aurora DSQL が舞台裏でどのように機能するかに関する詳細については、 ワーナー ヴォゲルス博士の基調講演 を視聴し、 Aurora DSQL ストーリー をお読みください。 Amazon Aurora DSQL のアーキテクチャ アプリケーションは、最高速の分散 SQL 読み取り/書き込み機能を使用し、データベースシャーディングやインスタンスのアップグレードを行わなくてもワークロードの要求に合わせてスケールできます。Aurora DSQL では、アクティブ/アクティブ構成の分散アーキテクチャが、単一のリージョンで 99.99% の可用性、複数のリージョンで 99.999% の可用性を実現するように設計されています。つまり、リージョンのクラスターエンドポイントに接続できないというまれな状況でも、アプリケーションは強固な一貫性で読み取りと書き込みを継続することができます。 シングルリージョン構成では、Aurora DSQL がすべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたすべてのログデータを 3 つのアベイラビリティーゾーンにあるユーザーストレージレプリカに同期レプリケーションします。クラスターストレージレプリカはストレージフリート全体に分散され、自動的にスケールして最適な読み取りパフォーマンスを確保します。 マルチリージョンクラスターは、シングルリージョンクラスターと同じレジリエンシーと接続性を提供しながら、ピアリングされたクラスターリージョンごとに 1 個ずつ配置された、合計 2 個のリージョナルエンドポイントを使用して可用性を向上させます。ピアリングされたクラスターのエンドポイントは、どちらも単一の論理データベースを提供し、強力なデータ整合性で同時読み取り/書き込み操作をサポートします。3 番目のリージョンはログ限定のウィットネスリージョンとして機能するので、クラスターリソースやエンドポイントはありません。つまり、地理的位置、パフォーマンス、またはレジリエンシーといった目的のためにアプリケーションと接続のバランスを取ることができるので、読み取り元に同じデータを一貫的に提供することが可能になります。 Aurora DSQL は、マイクロサービスやイベント駆動のアーキテクチャを使用するアプリケーションのサポートに最適な選択肢であり、銀行、e コマース、旅行、小売りなどの業界向けに、高度なスケーラビリティを備えたソリューションを設計できます。また、マルチテナントの Software as a Service (SaaS) アプリケーションや、マルチリージョンのスケーラビリティとレジリエンシーを必要とする支払い処理、ゲームプラットフォーム、ソーシャルメディアアプリケーションといったデータ駆動型のサービスにも最適です。 Amazon Aurora DSQL の使用を開始する Aurora DSQL は、シンプルなコンソールエクスペリエンスをはじめとして、使い勝手の良いエクスペリエンスを提供します。使い慣れた SQL クライアントを使用して既存のスキルセットを活用したり、他の AWS サービスと統合してデータベースの管理を改善したりできます。 Aurora DSQL クラスターを作成するには、 Aurora DSQL コンソール にアクセスし、 [クラスターを作成] を選択します。ニーズに適したデータベースインフラストラクチャを確立できるように、 [シングルリージョン] か [マルチリージョン] の構成オプションを選択できます。 1.シングルリージョンクラスターの作成 シングルリージョンクラスターは、 [クラスターを作成] を選択するだけで作成できます。それ以外は必要ありません。 数分後に、Aurora DSQL クラスターが作成されたことを確認できます。クラスターを接続するには、 PostgreSQL インタラクティブターミナル 、 DBeaver 、 JetBrains DataGrip などのお気に入りの SQL クライアントを使用することも、データベースのエンドポイントと認証トークン (パスワード) を使用する プログラム可能な各種アプローチ を取ることもできます。 自動化されたトークンの生成とローテーション のために AWS Secrets Manager と統合して、インフラストラクチャ全体での認証情報管理のセキュア化と簡素化を図ることができます。 認証トークンを取得するには、クラスターの詳細ページで [接続] > [トークンを取得] の順に選択します。 [認証トークン (パスワード)] セクションで [管理者として接続] を選択したら、 [エンドポイント (ホスト)] にあるエンドポイントと生成された認証トークンをコピーします。 その後は、 [CloudShell で開く] を選択し、数回クリックするだけで、クラスターにシームレスに接続できます。 Aurora DSQL クラスターを接続したら、 サンプル SQL ステートメント を実行してクラスターをテストします。アプリケーションの SQL ステートメントは、Python、Java、JavaScript、C++、Ruby、.NET、Rust、Golang などの お気に入りのプログラミング言語 を使用してクエリすることもできます。Django、Ruby on Rails、AWS Lambda アプリケーションを使用してサンプルアプリケーションを構築し、Amazon Aurora DSQL とやり取りすることができます。 2.マルチリージョンクラスターの作成 マルチリージョンクラスターを作成するには、他方のクラスターの Amazon リソースネーム (ARN) を追加して、クラスターをピアリングする必要があります。 1 番目のクラスターを作成するには、コンソールで [マルチリージョン] を選択します。 [ウィットネスリージョン] を選択する必要もあります。このリージョンはピアリングされたリージョンに書き込まれたデータを受信しますが、エンドポイントはありません。 [クラスターを作成] を選択します。既にリモートリージョンクラスターがあるという場合は、オプションでその ARN を入力できます。 次に、 [クラスターの作成] を選択して既存のリモートクラスターを追加するか、別のリージョンに 2 番目のクラスターを作成します。 ここでは、ピアクラスター ARN を 1 番目のクラスターとして、2 番目のクラスターを作成できます。 2 番目のクラスターが作成されたら、マルチリージョンの作成を完了するために us-east-1 内のクラスターをピアリングする必要があります。 1 番目のクラスターのページに移動し、 [ピアリング] を選択して、両方のクラスターのクラスターピアリングを確認します。 これで、マルチリージョンクラスターが正常に作成されました。他のリージョンにあるピアに関する詳細は、 [ピア] タブで確認できます。 Aurora DSQL を実際に体験するには、こちらの ステップバイステップワークショップ を利用できます。このワークショップでは、アクティブ/アクティブ構成のレジリエンシーを備えたサンプル小売リワードポイントアプリケーションを構築しながら、アーキテクチャ、主な考慮事項、ベストプラクティスについて説明します。 Aurora DSQL をプログラム的に作成して管理するには、 AWS SDK 、 AWS コマンドラインインターフェイス (AWS CLI) 、 Aurora DSQL API を使用できます。詳細については、「Amazon Aurora DSQL User Guide」の「 Setting up Aurora DSQL clusters 」を参照してください。 プレビュー後に追加された機能 プレビュー期間中にお寄せいただいたフィードバックや提案を使用して、新しい機能を追加しました。これらの新しい機能をいくつかご紹介します。 コンソールエクスペリエンス – マルチリージョンクラスターの作成やピアリング、AWS CloudShell を使用した簡単な接続を行えるように、クラスター管理エクスペリエンスを改善しました。 PostgreSQL 機能 – PostgreSQL ビューや既存データを含むテーブルの一意のセカンダリインデックスに対するサポートを追加し、正確なテーブル統計を手動で維持する必要をなくす Auto-Analyze を導入しました。Aurora DSQL の PostgreSQL 互換 機能に関する情報をご覧ください。 AWS サービスとの統合 – 完全なスナップショットバックアップと Aurora DSQL クラスター復元のための AWS Backup 、プライベートネットワーク接続のための AWS PrivateLink 、Aurora DSQL リソースを管理するための AWS CloudFormation 、Aurora DSQL 操作をログに記録するための AWS CloudTrail といった、さまざまな AWS サービスとの統合を行いました。 Aurora DSQL は、生成 AI モデルとデータベースが自然言語を使用して簡単にやり取りできるようにすることで開発者の生産性を向上させる Model Context Protocol (MCP) サーバーの提供を開始しました。例えば、 Amazon Q Developer CLI をインストールして Aurora DSQL MCP サーバー を設定できます。Amazon Q Developer CLI は Aurora DSQL クラスターにアクセスできるようになりました。データベースのスキーマを手軽に調べたり、テーブルの構造を理解したりすることや、複雑な SQL クエリを実行することさえも可能です。これらはすべて、追加の統合コードを作成することなく実行できます。 今すぐご利用いただけます 5 月 27 日から、Amazon Aurora DSQL のシングルリージョンクラスターとマルチリージョンクラスター (2 つのピアリージョンと 1 つのウィットネスリージョン) を米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) の AWS リージョンで、シングルリージョンクラスターをアジアパシフィック (大阪)、アジアパシフィック (東京)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ) の AWS リージョンでご利用いただけます。 料金は月単位で請求され、読み取り/書き込みなどのすべてのリクエストベースのアクティビティに対し、Distributed Processing Unit (DPU) と呼ばれる単一の正規化された請求単位が使用されます。ストレージはデータベースの合計サイズに基づいており、GB-月単位で測定されます。シングルリージョンクラスターまたはマルチリージョンピアクラスターごとに、データの 1 つの論理コピーに対する料金のみが請求されます。AWS 無料利用枠の一環として、毎月最初の 100,000 DPU と 1 GB-月のストレージが無料になります。詳細については、「 Amazon Aurora DSQL Pricing 」をご覧ください。 Aurora DSQL コンソール で Aurora DSQL を無料でお試しください。詳細については、「 Aurora DSQL User Guide 」をご覧ください。 AWS re:Post for Amazon Aurora DSQL 、または通常の AWS サポートの連絡先を通じてお寄せいただくフィードバックもお待ちしています。 – Channy 原文は こちら です。

本ブログは、株式会社 NTT データ テクノロジーコンサルティング事業部 主任 鯨田 連也氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 伊藤 が共同で執筆しました。 はじめに 株式会社 NTT データは、2024 年度の AWS ジャパン生成 AI 実用化推進プログラム に参画し、AI Agent によるクリエイティブ業務支援ソリューションを開発しました。本稿では、開発の背景となるビジネス的課題から、具体的なソリューションのアーキテクチャ、そして実際の導入による効果を包括的に紹介します。また、デザイン関連の企業様との協業を通じて得られた実践的な知見についても共有します。 背景と目的 広告作成やデザイン制作などのクリエイティブ業務において、作業の属人化やクリエイティブ制作に要するコストが課題となっています。例えば、スーパーやコンビニの店舗では、専門的なデザイナーがいないことが多く、非専門人材である店舗スタッフが広告（店内 POP）を作成することが一般的だと考えられます。その結果、広告作成業務が特定の人に偏り、品質のばらつきや、業務時間の増加などの作業負荷が発生します。また、広告デザイン制作を外注する場合、金銭的コストに加え、製作会社との打合せや修正依頼のやり取り、確認作業などの時間的なコストも発生します。 さらに、経験豊富なデザイナーのような専門人材においても、クリエイティブプロセスの効率化や質の向上が求められる場面は少なくありません。例えば、担当者によっては発想が似たようなものになり、デザインのバリエーション作成が困難になる課題や、自由な発想ができずデザインのアイデア出しに時間がかかってしまう課題があります。 これらの課題を解決するために、生成 AI や AI Agent を活用することで、デザイナーでない非専門人材でも一定水準のクリエイティブを短時間・低コストで作成できるソリューションの開発を目指しました。加えて、専門人材に対しても、アイデア創出のための壁打ち相手や、デザインのラフ案作成に活用できるようなソリューションを目指しました。 デザイン関連の企業様との協業 11 月に開催された AWS 生成 AI Frontier Meet Up にて登壇した際、同じくご参加されていたデザイン関連の企業様が弊社のソリューションに興味を持って下さり、協業の機会をいただきました。本企業様は、展示会やイベントの企画や運営、ブースのデザインを手掛けております。今回の協業では、NTT データのソリューションを実際に利用いただき、現場目線での多様なフィードバックをいただくことで、ソリューションの改善や機能追加へのヒントを得ることを目的としています。 協業でソリューションをご利用いただくに際し、業務の課題についてヒアリングを行うと、以下の課題を持たれていることが分かりました。 ① 情報収集の時間的コスト: 顧客や競合・トレンドの調査に時間を割く余裕が無い ② アイデア創出の属人化: アイデア創出プロセスやクリエイティブの意図は、担当者の感覚に依存している ③ アイデア具体化の非効率性: 顧客とのイメージの認識に乖離がある場合、大きな手戻りが発生し、制作のやり直しや再調整に多くの時間を要する 上述の課題を解決するために、①には Web 検索 Agent 、②には デザイン案生成 Agent 、③には 画像生成 Agent を開発しました。しかし、これらの Agent をどのように連携させ、適切に実行するかが課題でした。例えば、デザイン案生成 Agent が生成したデザイン案を基に、画像生成 Agent にデザインを生成させる際に、どのように Agent 間で情報を受け渡すか、また、Agent の実行タイミングをどのように制御するかなどの課題がありました。そのうえ、異なる職種の方が利用する前提のため、利用シーンに応じて実行すべき Agent や Agent の実行順序を動的に決定する必要がありました。 ソリューション 複数の Agent を統括する Supervisor Agent を利用した Multi Agent ソリューションを開発しました。Supervisor Agent は、ユーザーの要望に応じて実行すべき Agent を動的に決定し、各 Agent 間の実行結果を別の Agent に連携することができます。例えば、ユーザーが「”生成 AI” をテーマとした展示会のポスターデザインを作成したい」と要望した場合、まず、Supervisor Agent は デザイン案生成 Agent を実行した後に、画像生成 Agent を実行するように計画します。そして、実際にデザイン案生成 Agent を実行し、生成 AI から連想されるデザイン案を複数提示します。その後、ユーザーが選択したデザイン案を画像生成 Agent に連携し、デザインを複数生成します。なお、各 Agent の詳細については後述します。 図1. Supervisor 型の Multi Agent のイメージ 本ソリューションの特徴は、前述の Supervisor 型の Multi Agent である点に加え、Agent 思考過程が可視化されている点や、Human in the Loop による Agent の生成結果 (出力) の改善が可能である点です。特に、Agent の出力の根拠や意図を言語化することにより、デザイナー同士やデザイナーと顧客同士での議論が円滑になると考えられます。また、ユーザーが Agent の出力への再検討を依頼した場合、Supervisor Agent が自律的に改善点を検討します。これにより、生成 AI の利用方法に不慣れなユーザーでも、生成 AI 自身に改善点を考えさせることができるため、UX の向上が期待されます。 図2. ソリューションの特徴 Agent の開発フレームワークとして、 LangGraph を採用しました。LangGraph は、Agent の処理や実行順序をノードとエッジで表現し、Agent の複雑な処理フローを高い自由度で実装することが可能です。LangGraph では、Multi Agent を実現するための様々な機能が提供されており、例えば、Agent の短期記憶機能である Checkpoints を利用することで、Agent 間の情報連携が容易になります。さらに、 SubGraph や handoff (Command) という機能を利用することで、Supervisor Agent と別の Agent (Agentic Workflow) 間の実行制御を委譲できます。 Agent に利用している LLM には、 Amazon Bedrock の Claude 3.7 Sonnet および Azure OpenAI の GPT-4o を採用しています。また、画像生成 AI には、Amazon Bedrock の Amazon Nova Canvas および Azure OpenAI の DALL·E 3 を利用しています。多様なモデルを利用できるようにすることで、利用シーンに応じて各モデルの持つ独自の処理能力や得意分野、表現力を活かしたコンテンツの生成を行うことを狙いとしています。 Web 検索 Agent Web 検索 Agent は、ユーザーが指示した内容をWeb検索し、調査結果を要約する Agent です。通常の検索に加え、画像検索にも対応しています。例えば、「NTT データについて、企業理念を含めて調べて」と依頼すると、Supervisor Agent が検索クエリを生成し、Web 検索 Agent に検索クエリを連携します。そして、Web 検索 Agent は Web 検索を行い、検索結果を整理し回答します。回答には、Web 検索時の URL の引用情報も含まれています。 最終的な検索結果を踏まえて、後述のデザイン案生成 Agent や画像生成 Agent に依頼することも可能です。また、複数の検索結果を Supervisor Agent に要約させることも可能です。 図3. Web 検索 Agent の実行結果例 デザイン案生成 Agent デザイン案生成 Agent は、イベントコンセプトなどのキーワードから、複数のデザイン案を生成するAgent です。例えば、「(先程の検索結果の) サステナビリティというキーワードを基に、NTT データの生成 AI に関する展示会のポスターデザインを作成して」と依頼すると、Supervisor Agent は、「デザイン案生成 Agent を実行した後、画像生成 Agent を実行すべき」と考え、デザイン案生成 Agent を実行します。デザイン案生成 Agent は、ユーザーが提示したキーワードから連想される単語やテーマを思考し、より具体的なデザイン案とその根拠を複数提示します。なお、デザイン案生成 Agent は、以前の他の Agent の実行結果や、ユーザーの会話履歴を考慮してデザイン案を提案します。 最終的に生成されたデザイン案を選択すると、そのデザイン案を後述の画像生成 Agent に連携し、デザイン画像を生成することができます。また、デザイン案を再検討させたい場合、Agent 自身に改善点を考えさせることや、ユーザー自身が改善点を指摘することが可能です。 図4. デザイン生成 Agent の実行結果例 (抜粋) 画像生成 Agent 画像生成 Agent は、デザイン案に基づいて画像生成を行う Agent です。例えば、「木のシルエットを基本形状とし、内部に青や緑の発光する回路パターンが流れるデザインの画像を作成して」と依頼すると、Supervisor Agent は画像生成 Agent にユーザーが提示したデザイン案を連携し、画像生成 Agent を実行します。画像生成 Agent は、デザイン案を基に画像生成 AI に適した英語のプロンプトを作成した後、画像生成を行います。 最終的に生成されたデザイン画像を基に、修正依頼を行うことや、別のタスクを実行するために別の Agent を呼び出すことも可能です。 図5. 画像生成 Agent の実行結果例 (抜粋) アーキテクチャ Amazon Bedrock を中心に AWS マネージドサービスを多く活用することで、約 2 ヶ月でソリューションを構築することができました。アプリケーションは Amazon ECS 上のコンテナで実行され、ALB を介して外部からアクセス可能です。アプリケーション上で Supervisor Agent に依頼を行うと、Amazon Bedrock の Claude 3.7 Sonnet または Azure OpenAI の GPT-4o が呼び出され、ユーザーの意図を理解し適切な Agent を選択・実行します。Agent との会話履歴や生成した画像は、高速アクセスと自動スケーリングに優れた Amazon DynamoDB や、コスト効率の高い堅牢なストレージである Amazon S3 に保存しております。また、LangGraph の Checkpoints のデータを保存する不揮発領域として、当時は PostgreSQL または SQLite のみ対応していたため Amazon RDS に保存しております。 本ソリューションは AWS CDK を利用して Infrastructure as Code 化しており、他のお客様の AWS 環境でも同様のサービスのデプロイが可能です。 図6. アーキテクチャ 導入効果 それぞれの Agent を業務でご利用いただいた際の評価をまとめます。 表1. 各 Agent の評価結果 Agent 評価 結果 Web検索Agent ◯ • 調査実務の75%効率化することができた • 作業内容画像検索については、一般的なものもあった デザイン生成Agent ◯ • Agentの思考過程がユーザーのアイデア出しの参考になった • 新規なアイデアの生成には、改善の余地あり 画像生成Agent △ • 生成画像は、現場のグラフィックデザインとの乖離が大きい • 個社のデータを活用し、企業独自のデザインを生成できるよう なチューニングが必要 まとめ AWS ジャパン生成 AI 実用化推進プログラムを通し、AI Agent によるクリエイティブ業務支援ソリューションを開発することができました。また、デザイン関連の企業様と協業し、実際にソリューションをご利用いただくことで、調査業務において約 75 %の効率化を実現し、デザイン案の生成においてもユーザーのアイデア創出をサポートするなどの成果を上げることができました。今後は、頂いたフィードバックを基にした機能改善や、幅広いお客様への業務への適用を目指します。 弊社の生成 AI を活用したクリエイティブ業務支援の取り組みや、本稿の技術的詳細については、以下のブログでも公開しております。是非ご覧下さい。 広告作成を効率的に：生成 AI と Agent の活用事例 LangGraph×Bedrock による複数の Agentic Workflow を利用した Supervisor 型マルチエージェントの実装：広告素材作成アプリケーション 著者 鯨田 連也 株式会社 NTT データ テクノロジーコンサルティング事業本部 テクノロジーコンサルティング事業部 データサイエンティスト (主任) 伊藤 威 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト

本記事は 2025 年 5 月 21 日に公開された “ Amazon Q Developer CLI supports image inputs in your terminal ” を翻訳したものです。 この記事では、 Amazon Q Developer Command Line Interface (CLI) の画像サポート機能が開発プロセスをどのように変革するかをご紹介します。Q Developer CLI は 最近 (バージョン 1.10.0) 、画像のサポートを追加 し、視覚的な情報を処理する能力を拡張して開発者の生産性を向上させました。この新機能により、開発者はコマンドラインから直接、Q Developer CLI に対して図表やアーキテクチャ設計図、その他の画像ファイルを入力し、やり取りできるようになります。 現代のソフトウェア開発では、アイデアを伝えるために視覚的な表現がますます重要になっています。たとえば、アーキテクチャ図はシステムコンポーネントとその関連性を示し、エンティティ・リレーションシップ (以下、ER) 図はデータベース構造を可視化します。こうした画像ファイルを実際のコードに変換する作業は、通常、手作業による解釈と実装が必要で、エラーが発生しやすいプロセスです。 Q Developer CLI の新しい画像サポートは、開発者が画像を直接 Q Developer CLI エージェントに入力して分析できるようにすることで、このギャップを埋めます。私はこの機能を使って、手書きのアイデアからきちんとした設計文書へ、そして Infrastructure as Code へとアーキテクチャ図を変換できることにワクワクしています。新しいプロジェクトを始める場合でも、日々の作業を効率化する場合でも、さまざまなユースケースでこの機能を活用していきたいと思います。 リリース時点で、Q Developer CLI は JPEG、PNG、WEBP、GIF の画像形式をサポートし、1回のリクエストで 10 枚の画像をアップロードできます。Q Developer CLI の画像サポート機能を利用するには、Q developer CLI の最新バージョン（1.10.0 以上）を使用する必要があります。最新バージョンへのアップグレードまたはインストールには、この ガイド を使用してください。 Q Developer CLI の画像サポートの利点をご紹介するために、以下の 4 つのシナリオを例として使用します。 ユースケース 1: アーキテクチャ図から Infrastructure as Code を生成する 次の図は、画像をリサイズするアプリケーションです。ユーザーが画像をアップロードする送信元 Amazon S3 バケットと、画像をリサイズして送信先 S3 バケットに保存する AWS Lambda 関数が含まれています。Q Developer CLI を使用して、アーキテクチャ図をコードに変換できるようになりました。 画像リサイズアプリケーションのアーキテクチャ 次のスクリーンショットでは、Q Developer CLI に「参考として使える、ベストプラクティスを使用した Terraform テンプレートをください」とお願いしました。CLI に画像をドラッグ＆ドロップすると、その画像のパスがプロンプトに自動で追加される点にもご注目ください。 Q Developer によって生成された Terraform コードを表示する CLI 前の画像は、Q Developer CLI が生成したレスポンスの一部です。 Q Developer は、画像リサイズアプリケーションの構築を始めるために必要な Terraform テンプレートを返します。Q Developer CLI は画像を分析し、コンポーネントとその関係を特定して、対応する Terraform コードを生成しました。画像には表示されていませんが、レスポンスには Python での Lambda 関数のコードと、Lambda 関数に必要な IAM 権限も含まれていました。 これまでであれば、この図を Infrastructure as Code に変換するには、各コンポーネントを人力で解釈し、それぞれに対応する設定を記述する必要がありました。しかし、画像サポートにより、このプロセスの多くを自動化できるようになりました。さらに、Q Developer との対話を通じて、生成されたコードを改良したり、特定の実装の詳細について質問したり、追加要件に基づいて修正を要求したりして、最終的にコードを .tf ファイルに出力できます。 ユースケース 2: ER 図をデータベーススキーマに変換する 2 つ目のシナリオでは、大学向けのコース管理ソフトウェアを開発するデータモデリングチームの一員である場合を考えてみましょう。私は、その中核となるデータ構造を示す ER 図を作成しました。現在では、この ER 図を SQL に変換する作業を Q Developer の支援を受けて進められます。 コース管理のエンティティ関係図 次のスクリーンショットでは、Q Developer CLI に ER 図を使用してデータベーススキーマを作成するよう依頼しました。 ユーザープロンプトと Q Developer によって生成された SQL を表示する CLI Q Developer によって生成された SQL を表示する CLI 前の画像は、Q Developer CLI が生成したレスポンスです。 Q Developer は図を分析し、エンティティ、属性、リレーションを特定して、データベーススキーマを作成するための適切な SQL コードを生成しました。 Q Developer が結果を生成した後、Q Developer との対話を通じて、文字列の長さ、インデックスなどの変更を要求したり、設計の決定に関する説明を求めたりして、このスキーマを改良できます。 ユースケース 3: 手書き画像を設計文書に変換する 紙の上でアイデアをブレインストーミングし、それをチームと共有したいシナリオを考えてみましょう。次の画像では、ウェブサイトの注文フローを手書きで描いています。ウェブサイトユーザーがウェブサイトから書籍を注文すると、アプリケーションは在庫を更新し、支払いと配送のアクションを呼び出します。Q Developer CLI を使用して、手書きのアイデアから文書を作成できるようになりました。 ウェブサイトの手書き注文フロー 次の例では、Q Developer にこの画像を参照して設計文書を作成するよう依頼しました。 ユーザープロンプトと Q Developer によって生成されたレスポンスを表示する CLI 上のスクリーンショットは、Q Developer がまず画像を読み取り、手書き図の内容を理解したことを表しています。 Q Developer によって生成されたレスポンスを表示する CLI 前のスクリーンショットは、Q Developer CLI が生成したレスポンスの一部です。 Q Developer はアイデアを、システムアーキテクチャ、プロセスフロー、データモデル、機能要件、技術要件を含む設計文書に変換しました。Q Developer に内容を .md ファイルに出力するよう依頼もできます。これにより、アイデアから実行までの時間が短縮され、文書作成が効率化されます。 ユースケース 4: スクリーンショットから UI モックアップ/ワイヤーフレームを構築する ユースケース 3 の設計文書から、ユーザーインターフェイス（UI）の構築を始めたいとします。Q Developer に参照画像を提供して、UI の初期ワイヤーフレームを生成できます。 サンプルの書籍販売ウェブサイトのホームページ この例では、Q Developer に Vue.js で新しいウェブサイトのフロントエンドを生成するよう依頼しました。 ユーザープロンプトと Q Developer によって生成されたレスポンスを表示する CLI Q Developer によって生成された Vue.js コードを表示する CLI 前の画像は、スクリーンショットのウェブサイトのフロントエンドを再現するための Q Developer CLI が生成した Vue.js コードの一部です。コードを確認した後、Q Developer CLI にこれらのファイルをローカル環境にファイルとして作成するよう依頼できます。 このアプローチにより、ワイヤーフレーム作成におけるミスの起こりやすい作業を減らし、繰り返しのセットアップ作業ではなく、創造的な設計判断に集中できます。このように、開発サイクルを加速し、コンポーネント間の一貫性を確保しつつ、特定のプロジェクト要件に合わせて簡単にカスタマイズできる基盤を提供できます。 その他の活用の可能性 前述の例に加えて、Q Developer CLI はさまざまな種類の画像を分析できます。例えば、次のようなものです。 フローチャートとプロセス図 オブジェクト指向設計のためのクラス図 ネットワークトポロジー図 エラーメッセージやアプリケーション状態のスクリーンショット このように多様な画像に対応できることで、Q Developer CLI はさまざまな開発プロセスのための強力なツールとなります。 まとめ Amazon Q Developer CLI への画像サポートの追加は、ソフトウェア開発における視覚的表現とテキスト表現の間のギャップを埋める上で、大きな一歩です。コマンドラインから図表やその他の画像ファイルを直接操作できるようにすることで、Amazon Q Developer は設計から実装への変換効率を向上させ、エラーを減らし、開発サイクルを加速します。ぜひこの新機能を試して、ご自身の開発プロセスをどのように改善できるか体感してみてください。 Q Developer とその機能について詳しく知るには、 ドキュメント をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Keerthi Sreenivas Konjety Keerthi Sreenivas Konjety は Amazon Q Developer のスペシャリストソリューションアーキテクトで、AI、ML、データエンジニアリングの分野で 3.5 年以上の経験を持っています。彼女の専門知識は、AWS のお客様の開発者生産性の向上にあります。仕事以外では、写真撮影と AI コンテンツ作成 を楽しんでいます。

テクノロジーコミュニティには、志を同じくする他の人々と学び、人脈を築く多くの機会があります。5 月 19 日週、AWS の多くのお客様が AWS Summit Dubai に参加し、ライブデモ、最先端の AI/ML ツールのハンズオンエクスペリエンスなど、多くのイベントに参加しました。私は、ここ南アフリカで ダーバンのデータ & AI コミュニティ に参加して、コミュニティからインスピレーションを得て学ぶ 1 日を過ごしました。インドでは、 AWS Community Day Bengaluru が開催され、多くの熱心な技術愛好家が集まり、学習と人脈作りの 1 日を過ごしました。 5 月 19 日週のリリース 私が注目したリリースを以下に記載しました。 Anthropic から提供されているコーディング向けの最も強力な Claude 4 の Amazon Bedrock での利用 – 5 月 22 日、Anthropic は、次世代の Claude モデルである Opus 4 と Sonnet 4 をリリースしました。この 2 つのモデルは、コーディング、高度な推論、次世代の有能な自律型 AI エージェントのサポートを目的として設計されたモデルです。どちらのモデルも Amazon Bedrock での一般提供が開始されているので、モデルの高度な推論機能とエージェント機能の両方にすぐにアクセスできるようになりました。 EKS ダッシュボードでの複数の AWS リージョンとアカウントにわたる Kubernetes クラスターの可視性の一元的な表示 – クラウドアーキテクトとクラスター管理者が複数の Kubernetes クラスターにわたる組織全体での可視性を一元的に表示できる EKS ダッシュボードが発表されました。 AWS Product Lifecycle ページと AWS サービス可用性の更新 – すべてのサービス可用性情報を 1 つの便利な場所にまとめるために AWS Product Lifecycle ページが導入されました。AWS Product Lifecycle ページでは、新規のお客様の受付を終了するサービス、サポート終了が発表されたサービス、サポート終了日を迎えたサービスを詳細に把握できます。 AWS コスト異常検出と AWS User Notifications の統合 – Amazon EventBridge 経由の AWS User Notifications を使用して、サービス、アカウント、またはコストに関連する要素に基づいて高度なアラートルールを設定し、予期しない支出の変化をより迅速に特定して対応できます。 AWS CloudShell 上の Amazon DynamoDB ローカル – CloudShell の dynamodb ローカルエイリアスを使用して DynamoDB をローカルで起動し、コンソール内の任意の場所で DynamoDB テーブルを開発およびテストできるようになりました。AWS CLI や DynamoDB ローカルをダウンロードおよびインストールする必要はありません。 弊社は AWS サービス全体で IPv6 サポートを加速しています。5 月 19 日週、 EC2 パブリック DNS 名 を使用した IPv6 経由の EC2 インスタンスへのパブリックアクセス、 AWS Organizations に接続するための新しいデュアルスタックエンドポイント、 Amazon Lightsail へのデュアルスタック PrivateLink インターフェイス VPC エンドポイントのサポートが開始されました。詳細について、 IPv6 に関する最新情報 を参照してください。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Strands による AI エージェントの構築 – 今月初め、Strands Agents が発表されました。これは、わずか数行のコードで AI エージェントを構築して実行するモデル主導型のアプローチを採用したオープンソース SDK です。この SDK を使い始める際に役立つように、同僚の Dennis Traub が Strands で AI エージェントを構築する方法に関する一連のガイド を公開しています。 Amazon Q CLI キャンペーンでゲームを構築 – アジア太平洋、日本、または中国 (APJC) 地域にお住まいの方は、キャンペーンに参加してゲームを作成してください。2025 年 5 月 20 日～6 月 20 日の間に体験を共有していただいた方に T シャツをお届けします。 Amazon Q CLI を使用してチェスゲームを構築 する例を紹介しておきます。 多要素認証 (MFA) で EC2 インスタンスを保護する方法 – Google Authenticator を使用して MFA を実装して Amazon Linux 2023 EC2 インスタンスのセキュリティを強化する方法を学ぶことができます。この設定では、ユーザーはインスタンスに接続するときに SSH キーペアと時間ベースのワンタイムパスワードの両方をアプリケーションから提供する必要があるので、必要不可欠な保護レイヤーが追加されます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしてください。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください。開催地は、 テルアビブ (5 月 28 日)、 シンガポール (5 月 29 日)、 ストックホルム (6 月 4 日)、 シドニー (6 月 4日～5 日)、 ワシントン (6 月 10日～11 日)、 マドリード (6 月 11 日) です。 AWS re:Inforce – 6 月 16日～18 日には、ペンシルバニア州フィラデルフィアで AWS re:Inforce が開催されます。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスにご参加ください。開催地は、 米国ミルウォーキー (6 月 5 日) と ケニアのナイロビ (6 月 14) 日です。 5 月 26 日週のニュースは以上です。6 月 2 日週にお届けする次回の Weekly Roundup もお楽しみに! – Veliswa 原文は こちら です。

AWS Fault Injection Service (FIS) が Amazon Application Recovery Controller (ARC) のゾーンオートシフトのリカバリーアクションをサポートするようになった ことをお知らせいたします。この統合により、障害を注入するイベントの作成とゾーンオートシフトのトリガーを同一実験内で行えるようになり、より包括的なテストが可能になりました。これにより、アベイラビリティーゾーン (AZ) の障害時にアプリケーションがどのように動作するかを観察できます。 アプリケーションを複数の AZ にデプロイすることは、AWS で可用性の高いアプリケーションを構築するための重要な戦略です。各 AZ は 障害分離境界 として機能し、デプロイ、ネットワークの問題、停電、人的ミスなどの障害は、その特定のゾーン内に封じ込められ、システム全体には影響を与えません。このマルチ AZ アプローチにより、1 つの AZ で問題が発生しても、アプリケーションは利用可能な状態を維持でき、より信頼性が高く、耐障害性のあるものとなります。 ゾーンシフトとゾーンオートシフト AZ に障害が発生した場合、 ゾーンシフト を復旧メカニズムとして使用し、AWS リージョン内の障害が発生した AZ から同じリージョン内の正常な AZ にトラフィックを移動させることができます。これにより障害を分離し、アプリケーションが別の AZ で顧客にサービスを提供し続けることができます。この機能をさらに強化するため、 ARC がサポートするリソースのリスト を拡張し、 Amazon EC2 Auto Scaling グループ 、 Amazon Elastic Kubernetes Service 、そしてクロスゾーンロードバランシングが有効または無効な Application Load Balancer および Network Load Balancer が含まれるようになりました。 ARC の ゾーンオートシフト は、復旧時間の最小化に役立ちます。AWS は、内部モニタリングシステムが顧客に影響する可能性のある AZ 障害を検出した場合、自動的にオートシフトを開始します。オートシフトは、ゾーンオートシフト用に設定された AWS リソースのトラフィックを、影響を受けたゾーンから一時的に移動させます。問題が解決すると、トラフィックは再びすべての AZ に分散されます。 AWS FIS AZ の可用性：電源の中断 お客様は、 AWS FIS を使用して、AZ 内のリソースと AWS サービスに障害を発生させることで、アプリケーションが AZ レベルのイベントにどのように応答するかを検証してきました。 AZ 可用性：電源の中断シナリオ は、複数の FIS アクションを組み合わせることで、AZ での完全な電源中断で予想される多くの症状を作り出します。このシナリオでは、単一の AZ 内の特定のリソースセットに対して、ゾーンのコンピューティングリソース (Amazon EC2、EKS、ECS) の停止、AZ 内でのコンピュートのスケーリングの禁止、サブネット接続の損失、 Amazon Relational Database Service (RDS) のフェイルオーバー、 Amazon ElastiCache のフェイルオーバー、 Amazon Elastic Block Store ボリュームの無応答化を引き起こすことで、一時的に「電源を切る」状態を作り出します。 AZ 中断のテストにおける一般的な落とし穴は、ネットワーク接続のブロックのみに焦点を当てることです。しかし、この方法はお客様が管理するネットワーク内のリソースにのみ影響を与えるにとどまり、ネットワーク構成とは独立して動作する AWS マネージドサービスには影響を与えません。FIS AZ シナリオは、リソースと AWS マネージドサービスの両方に対する中断をシミュレートすることで、より包括的なテストソリューションを提供します。 AZ の可用性：電源の中断シナリオは、アプリケーションの耐障害性をテストし改善するための大きな利点を提供します。このシナリオでは、マルチ AZ アプリケーションが実際の障害発生時にどのように動作するかを観察できます。この管理された実験を実行することで、アーキテクチャ、監視システム、運用手順における潜在的な弱点を発見できます。これにより、アプリケーションの耐障害性と全体的な信頼性が向上し、復旧時間の短縮が可能になり、災害復旧計画のコンプライアンス要件にも対応できます。 AWS FIS とゾーンオートシフトを組み合わせる 復旧戦略において重要な側面は、テストを行う能力です。ビジネスニーズに合わせてシステムがより急速に進化するクラウドでは、レジリエンステストが特に重要です。また、手順の有効性確認、チームの対応準備状況の評価、パフォーマンス指標の検証、潜在的な問題の特定にも役立ちます。 そのため、AZ の可用性：電源の中断シナリオが、ゾーンオートシフトとどのように連携するかをご紹介できることを嬉しく思います。これらの機能を組み合わせることで、障害発生時の AWS の動作をテストできるようになりました。つまり、影響を受けた AZ からトラフィックを自動的に移す動作を確認できます。この統合されたテストアプローチにより、AZ でのインフラストラクチャに障害が発生した際にアプリケーションがどのように動作するかをより包括的に把握できます。 ゾーンオートシフトのための AWS FIS 復旧アクション 今回のリリースでは、最初の 復旧アクション とともに、AWS FIS アクションの新しいカテゴリを導入しました。新しい AWS FIS 復旧アクションにより、ゾーンオートシフトを有効にしているお客様は、FIS AZ の可用性：電源の中断シナリオを実行して、AZ での完全な電源中断の想定される状態を再現し、実際の障害時に AWS がどのようにゾーンオートシフトを起動するかを実証できます。また、単純に正常な AZ からトラフィックを移すだけでは発見できない問題も発見できます。つまり、実際に AZ が使用不能になった時に初めて表面化するアプリケーションの隠れた依存関係がわかります。 復旧アクションを含む AWS FIS 実験テンプレートの作成 AWS FIS を使用してゾーンオートシフトをテストする 方法を見てみましょう。この記事では新しい統合機能について説明します。AZ の可用性：電源の中断シナリオを使用した実験を作成したことがない場合は、 AWS Fault Injection Service シナリオライブラリでカオスエンジニアリングを始めるための基礎 で、セットアップ方法の詳細な手順を参照してください。 開始するには、AWS FIS シナリオライブラリから AZ の可用性：電源の中断 シナリオを選択して、実験テンプレートを作成します。 アクションとターゲットを指定 の下に、ゾーンオートシフトが追加されているのが確認できます。下部には、新しいリカバリーアクション Start-ARC-Zonal-Autoshift とそのターゲット ARC-Managed-Resources が表示されています。 ゾーンオートシフトアクションの設定を見てみましょう。 アクションタイプ: ここでは、 aws:arc:start-zonal-autoshift アクションとともに、新しい ARC アクションタイプが表示されます。 次のあと開始: アクションは、実験開始後 5 分間待機するように FIS-Wait アクションで設定されており、イベント発生から一定時間が経過した状況をシミュレートしてからゾーンオートシフトを開始します。実際のイベントでは、症状が始まってから数分後にオートシフトがトリガーされることが予想されます。 ターゲット:   ARC-Managed-Resources という名前のターゲットが自動的に作成され、対象となるリソースを定義します。 Availability Zone identifier:  ゾーンオートシフトでトラフィックを移動させる AZ を選択します。また、 共有パラメータを編集 を使用することで、実験内のすべてのアクションに対して一貫した値で共有パラメータを設定できます。 Duration: 時間の値は、実験内の他のアクションが終了してトラフィックの移行を開始するタイミングと同時に、ゾーンオートシフトが終了するように設定されます。期間は、上記で説明したゾーンオートシフトをトリガーする前の 5 分間の待機時間を考慮して、 [ 障害継続時間 - 5 minutes] に設定されます。たとえば、実験の停止時間が 30 分の場合、ゾーンオートシフトの期間は 25 分に設定されます。 ARC-Managed-Resources ターゲット設定では、ゾーンオートシフトに含めるリソースを定義できます。デフォルトでは、アカウント内でゾーンオートシフトが有効化されている、サポート対象の AWS リソースが含まれます。これらのリソースは、 ゾーンシフトへオプトインされている 必要があります。 ターゲットメソッド:  デフォルトでは、 リソースタグ、フィルター、パラメータ オプションが選択されます。 リソースタグ: デフォルトでは、キー名が AzImpairmentPower 、キー値が RecoverAutoshiftResources のリソースタグが作成されます。これらのリソースタグを、実験対象とするゾーンオートシフト対応リソースに設定できます。 これまでの設定オプションは、他の FIS アクションと同様です。 aws:arc:start-zonal-autoshift アクションの新機能として、 リソースパラメータ が追加され、ターゲットとするリソースについてより柔軟な設定が可能になりました。 この新しいパラメータ群は、 ターゲットメソッド (リソース ID やリソースタグなど) に加えて、リソースを対象とするための Managed resource types と Zonal autoshift status を提供します。 Managed resource types: ゾーンオートシフトをサポートするリソース (Auto Scaling グループ、Application Load Balancer、Network Load Balancer、および/または EKS クラスター) から、ターゲットとするものを 1 つ以上選択します。 Zonal autoshift status: 対象とする管理対象リソースタイプは、ゾーンオートシフトが Enabled 、 Disabled 、またはその両方の状態にすることができます。デフォルトでは、 Enabled が事前に選択されています。このパラメータを Disabled に設定すると、ゾーンオートシフトは無効だがゾーンシフトにオプトインしているリソースを対象とすることができます。これにより、ゾーンオートシフトを有効にする前にアプリケーションの動作を事前に確認することができます。 FIS リカバリーアクション の詳細については、 AWS Fault Injection Service ユーザーガイド を参照してください。 料金と利用可能地域 AWS FIS は、使用した分だけ料金が発生します。前払い費用や最低料金はありません。アクションの実行時間と実験に含まれるアカウント数に基づいて課金されます。料金の詳細については、 FIS の料金ページ をご覧ください。 ゾーンオートシフトの使用自体に追加料金はかかりませんが、AZ からの切り替え時に追加のトラフィックを処理するために、複数のアベイラビリティーゾーンでリソースを事前にスケーリングするための追加コストや、 CloudWatch 、 データ転送 などの関連コストを考慮する必要があります。 FIS のリカバリーアクションは、FIS とゾーンオートシフトが利用可能なすべての AWS リージョンで利用できます。FIS が利用可能な AWS リージョンのリストについては、 FIS サービスエンドポイント をご覧ください。ゾーンオートシフトが利用可能なリージョンのリストについては、 ゾーンオートシフトの AWS リージョン提供状況 をご覧ください。 まとめ AWS Fault Injection Service の AZ の可用性: 電源の中断シナリオと ARC のゾーンオートシフトを組み合わせることで、AZ 障害に対するテストと復旧メカニズムの検証を同時に実行できます。この組み合わせたテストアプローチにより、インフラストラクチャの中断時におけるアプリケーションの動作をより包括的に評価できます。 AWS Fault Injection Service と ARC ゾーンオートシフト を使用して、アプリケーションのレジリエンステストを今すぐ始めましょう。本番環境に展開する前に、非本番ワークロードで小規模なテストから開始できます。 実践的な演習として、 AWS Fault Injection Service シナリオライブラリでカオスエンジニアリングの旅を始める というステップバイステップのガイドを試して、最初の実験をセットアップしてみてください。 耐障害性を維持し、テストを継続しましょう！ Daniel Cil Daniel Cil は南カリフォルニアを拠点とするシニアレジリエンススペシャリストソリューションアーキテクトです。AWS の業界別および戦略的なお客様が AWS クラウド上のワークロードに対して、耐障害性のあるアーキテクチャを設計し、レジリエンスのベストプラクティスを実装できるよう支援しています。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。

本稿は、JFE 条鋼株式会社による AWS 移行の取り組みについて、主導された JFE 条鋼株式会社 神庭 公一様、JFE システムズ株式会社 齋藤 誠様、株式会社エクサ 中西 広行様より寄稿いただきました。 はじめに JFE 条鋼株式会社 (以下、JFE 条鋼) は、鉄鋼製品の中でも主に形鋼と鉄筋棒鋼を製造、販売する電炉メーカーです。電気炉を使用して鉄スクラップを主原料とした製品を製造する電炉業界は、資源リサイクルの担い手として持続可能な循環型社会に貢献する重要な役割を担っています。同社は、この精錬技術を活かした資源リサイクル事業も中核事業として展開しています。 電炉業界は、原材料となるスクラップ価格が短期間で変動する厳しい環境下において、競争力の維持・強化が求められています。このような状況下で操業効率化が急務となる中、データサイエンスの活用を検討しましたが、従来のオンプレミス環境では多額の初期投資が必要で、システムリソースの柔軟な拡張も困難でした。さらに、主要なサーバのメーカー保守終了が迫っており、システム基盤の見直しが必要な時期を迎えていました。 このような事業環境の中で、JFE 条鋼は、デジタルトランスフォーメーション (DX) による業務効率化と高度化を推進する方針を決定しました。特に、2035 年以降に予測される労働人口の大幅な減少を見据え、データドリブンで高頻度かつ自動的・自律的な業務プロセスを実現できる基盤が必要でした。そこで、最新のデータ分析サービスや機械学習機能を柔軟に活用でき、高度なデータ処理基盤を迅速に構築できる AWS への移行を選択しました。 プロジェクト体制とアプローチ このような課題認識のもと、AWS 環境構築、ネットワーク設計、アプリケーション移行など、多岐にわたる専門性が求められるプロジェクトを成功させるため、それぞれの強みを持つ 3 社での協業体制を構築しました。事業会社として JFE 条鋼は業務要件を熟知していることから全体統括と要件定義を担当し、基盤とネットワークについては AWS 環境構築の豊富な実績を持つ 株式会社エクサが基盤設計と SASE の導入を担当しました。また長年、基幹系業務システムの維持管理・保守を担当しており、当社環境を熟知している JFE システムズ株式会社が、その知見を活かしてアプリケーション移行と運用設計を担当しました。さらに、鉄鋼業に深い知見を持つ AWS の営業担当者とソリューション・アーキテクトが継続的にサポートし、当社の課題認識や取り組みの方向性を十分に理解した上で、適切な技術支援を提供したこともプロジェクトをスムーズに進められた要因となりました。 システム基盤のアーキテクチャ AWS 環境を長期的に運用していくためには、まず適切なガバナンス体制の確立が不可欠です。そこで、システム基盤の構築にあたり、最初のステップとして AWS Control Tower を採用しました。これにより、複数の AWS アカウントを一元的に管理し、セキュリティとコンプライアンスの基準を組織全体で統一的に適用できる環境を整えました。さらに、生産管理システムなどの基幹業務システムと、データサイエンス環境を明確に分離し、それぞれの特性に応じたセキュリティポリシーとガードレールを設定しました。基幹システムではセキュリティとガバナンスを重視した厳格な制御を行う一方、データサイエンス環境では分析業務に必要な柔軟性を確保し、セキュリティを担保しながらデータ活用促進を実現しました。 また、ネットワークについては SD-WAN (Software-Defined Wide Area Network) の導入により、拠点間通信の冗長化とインターネットアクセスの最適化を行いました。その結果、従来の専用線による接続と比較して、より柔軟で効率的なネットワーク構成となりました。 図 1 マルチアカウント基盤アーキテクチャ図 生産管理システムの移行 第一弾として 1 つの製造所の生産管理システムの移行を実施しました。そこでは、システムの可用性を確保するため複数の対策を講じました。 まず、アプリケーションサーバーについては、既存アプリケーションの特性を考慮し障害発生時にはスナップショットからの復旧とする構成を採用しました。また、データベースについては Amazon RDS のマルチ AZ 構成を採用し、障害発生時の自動フェイルオーバーを可能としました。 次に、BCP (事業継続計画) 対策として東京と大阪のリージョン間でのバックアップと定期的なデータ同期の仕組みを構築しました。AWS Backup を活用し、EC2 や RDS のスナップショットを日次で取得しリージョンをまたがって保管することで、広域災害にも対応可能な構成としました。 図 2 生産管理システムアーキテクチャ図 データ活用基盤の確立 JFE 条鋼では、AWS 移行を機にデータ活用の基盤を刷新し、製造現場のデータをリアルタイムで収集、分析し、業務改善に活用する環境を整備しています。 FA と IT の連携を実現するオープンなエッジコンピューティング基盤 EdgeCross を採用し、各製造設備からのデータを収集しています。収集したデータは、時系列データに最適化された Amazon Timestream に格納し、大規模な製造設備データの効率的な管理と高速な分析を行っています。これにより、製造プロセスの詳細な時系列分析や、設備の稼働状況のリアルタイムモニタリングなど、時間軸に沿った多様なデータ活用が可能となっております。 さらに、可視化基盤として Amazon QuickSight を採用し、製造ラインの稼働状況や KPI のリアルタイムモニタリングを行っています。このような取り組みにより、現場のオペレータから管理者まで必要な情報をタイムリーに確認できる環境を構築しました。 図 3 データ活用基盤アーキテクチャ図 得られた効果と今後の展望 生産管理システムの AWS 移行により、まずハードウェアの運用から解放され、システムの可用性も向上しました。特に、マルチ AZ 構成の採用やバックアップの自動化により、システムの信頼性が向上しました。また、データ活用の面では製造現場のデータをリアルタイムで分析し、業務改善に活用できる環境が整いました。 今後は、これらの基盤を活用し収集したデータを活用した予知保全や品質向上など、より高度なデジタル化を推進します。特に注力するのがプロセス全体の高速化です。従来の日次バッチ処理的な業務プロセスから脱却し、データ処理の高速化・高頻度化を進めます。これにより、サプライチェーンの変化や操業状況の変化にリアルタイムで対応できる体制を目指します。 また、操業により近い業務システムへの展開も段階的に進めます。まずは集計的な機能から着手し、実績を確認しながらより操業に近い領域へと範囲を拡大する計画です。現行システムと新システムが併存する中で、データの連携方式やユーザーインターフェース、運用方式の一貫性確保など、想定される課題に対しては AWS の機能を最大限活用して解決を図ります。 このような業務プロセスの改革とデータ処理の高度化を相互に連携させ、スパイラル的な進化を図ります。 まとめ このように、当社は AWS 移行プロジェクトを通じて、システム基盤の近代化と業務プロセスの革新を進めています。AWS を活用しセキュリティと利便性を両立する環境を構築し、生産管理システムの安定稼働とデータ活用基盤の整備を行いました。これにより、データドリブンな業務プロセスの基盤が整いました。 今後は、これらの基盤をさらに発展させ、予知保全や品質向上に向けたデータ分析を深化させ、データ処理の高速化・高頻度化を進めます。従来の日次バッチ処理的なプロセスから脱却し、よりリアルタイムな対応を可能とする業務プロセスへと進化させます。最終的には、人間の役割を「オペレーター」から「デザイナー」へと進化させ、より創造的な業務への転換を図ることで、持続可能な企業成長を実現します。 執筆者 神庭公一 JFE 条鋼株式会社 業務イノベーション推進部業務改革グループマネージャー 大学学部卒業後、鉄鋼会社にて生産管理、営業（輸出・国内）の業務の後、システム部門へ。2013年度に現会社に出向・移籍し、現在に至る。社内業務システムとそのインフラに関する企画・構築・運用全般を担当。 斎藤誠 JFE システムズ株式会社 産業ソリューション事業本部 鉄鋼関連事業部 関連企業第2開発部第3グループ 大学院卒業後、JFE システムズに入社。以降、JFE 条鋼担当システムエンジニアとして、業務システム開発、オンプレミスサーバの設計・構築を担当。2023 年から基幹業務システムの AWS リフトプロジェクトをリーダとして推進 中西広行 株式会社エクサ 基盤システム本部 基盤ソリューション部　第 ２ ソリューション室 大学卒業後、株式会社エクサに入社。以降、セキュリティソリューション、および、クラウドエンジニアとして、システム基盤の設計構築を担当。2023 年より、JFE 条鋼様 AWS マルチアカウント環境の構築運用、および、SASE 導入プロジェクトをリーダーとして推進

「Amazon Q CLI でゲームを作ろう」キャンペーンは、AIコーディングアシスタントを実際に体験し、 Amazon Q CLI を使って自分のペースで新しいゲームを作り出すための創造性と想像力を発揮する機会です。この学習機会は 2025 年 5 月 20 日から 6 月 20 日まで実施され、アジア太平洋、日本、中国地域の参加者のみが T シャツを獲得できます（対象国のリストは下記に記載）。 T シャツを獲得するために必要なステップは以下の通りです： 1: Amazon Q CLI を使ってゲームを作ろう 2: あなたが何をどのように作ったかについてブログを書くか、あなたの体験についての動画を録画して、ソーシャルメディアに投稿しよう 3: Amazon Q ブランドの T シャツをゲットしよう ステップバイステップガイド Step 1 : AWS Builder ID に登録し、 このリンク から独自の community.aws ユーザー名を取得してください。サポートが必要な場合や他の参加者とネットワークを構築したい場合は、 このリンク から Discord サーバーに参加してください。 Step 2 : Amazon Q CLI をマシンにインストールしてください。Ricardo Sueiras による Linux と Windows へのインストール方法ガイドがあります。また、 PyGame または他のゲームライブラリをラップトップにインストールしてください。 Step 3 : Amazon Q CLI とのチャットセッションを開始し、チャット内のプロンプトだけでゲームを作成しましょう。Amazon Q CLI の可能性を探るため、できるだけ革新的なゲームを作ってみてください。 Step 4 : 作成したものについてブログを書くか、ビデオを作成してください。ハッシュタグ #AmazonQCLI を付けて SNS で公開投稿をしてください。地域言語 (例 : 日本語) での投稿も歓迎します。オプションとして、コードを GitHub リポジトリにホストすることもできます。 Step 5 : Tシャツ 獲得フォーム に記入してください。 注：中国語、日本語、韓国語など、あなたの話す言語でゲームを作成できます。 始めるためのインスピレーションが必要ですか？ Derek Bingham（AWS シニアデベロッパーアドボケイト） が週末に息子と一緒に Amazon Q CLI を使ってゲームを作った ブログ や、 Haowen Huang（香港 シニアデベロッパーアドボケイト） による Amazon Q CLI を利用した Vibe Coding でゲームを作った ブログ をご覧ください。 Amazon Q CLI 関連の今後のAWSユーザーグループミーティングについては、近日中に更新されます。 この活動を楽しみ、新しいことを学び、プロセスを楽しんでいただければ幸いです。 どのようなクールなゲームが作られるか楽しみにしています。 Amazon Q CLI についてのフィードバックは、Discord のフィードバックチャンネルでお知らせください。 追加リソース Amazon Q CLI セルフサービスワークショップ 規約 AWS は、不完全、不正、または重複したエントリーを失格とする権利を有します。 プライバシー – 参加者情報は、景品の提供とプログラム分析の目的でのみ使用されます。 AWS は、予告なしにいつでもキャンペーンをキャンセル、変更、または中断する権利を有します。 景品は譲渡できず、現金価値はありません。 よくある質問 Tシャツを獲得できる対象国はどこですか？ : オーストラリア、バングラデシュ、ブータン、ブルネイ、カンボジア、中国、フィジー、香港、インド、インドネシア、日本、ラオス、マレーシア、モルディブ、ミャンマー、ネパール、ニュージーランド、パキスタン、パプアニューギニア、フィリピン、シンガポール、韓国、スリランカ、台湾、タイ、ベトナム 以前は APAC 地域にいましたが、別の地域に移動しました。T シャツをもらえますか？ : 残念ながら、いいえ。 T シャツはいつ届きますか？ : T シャツは毎週金曜日に発送が開始されますが、物流準備のため、その週の水曜日までに提出された応募のみが対象となります。 送料は支払いますか？ : いいえ。送料と税金は当社が負担します。一部の国では、配送が困難であったり、追加の通関料金が発生したり、税関に連絡する必要がある場合があります。そのような場合は、通関のために税関に連絡し、料金を負担する必要があります。 複数の応募に対して複数の T シャツをもらえますか？ : 参加者 1 人につき 1 枚の T シャツのみです。 Amazon の従業員は参加できますか？ : キャンペーンに直接関わる主催者または関連会社の従業員は参加資格がありません。 本記事は「 Build Games with Amazon Q CLI and score a T shirt  」を翻訳したものです。

Anthropic は 5 月 22 日、次世代の Claude モデルである Opus 4 と Sonnet 4 をリリースしました。コーディング、高度な推論、次世代の有能な自律型 AI エージェントのサポートを目的として設計されたモデルです。どちらのモデルも Amazon Bedrock で一般提供を開始しました。開発者はモデルの高度な推論機能とエージェント機能の両方にすぐにアクセスできるようになりました。 Amazon Bedrock は Anthropic の最先端モデルで AI の選択肢を広げ、 エンタープライズグレードのセキュリティ と 責任ある AI 管理を備えた革新的なアプリケーションの自由な構築を実現します。どちらのモデルも、タスクプランニング、ツールの使用、エージェントの操作性を向上させることで、AI システムの可能性を拡張しています。 Opus 4 の高度なインテリジェンスを使用すると、大規模なコードベースのリファクタリング、リサーチの統合、部門を超えたエンタープライズオペレーションの調整など、長時間実行されるコンテキストの多いタスクを処理するエージェントを構築できます。Sonnet 4 は大規模な効率化に向けて最適化されているため、サブエージェントとして、またはコードレビュー、バグ修正、本番グレードのコンテンツ生成などの大量のタスクに適しています。 生成 AI を使用して構築する場合、多くの開発者は長期的なタスクに取り組みます。多くの場合、これらのワークフローには多段階のプロセス、大規模なコンテキスト全体の計画、長期にわたる多様なインプットの統合など、深く持続的な推論が必要となります。これらのワークフローのいい例として、大規模プロジェクトのリファクタリングやトランスフォーメーションを支援するデベロッパー AI エージェント があります。既存のモデルでも迅速かつ問題なく対応できるかもしれませんが、特にコーディング、調査、エンタープライズワークフローなどの分野では、一貫性とコンテキストを長期にわたって維持することは依然として困難な場合があります。 Claude Opus 4 Claude Opus 4 は、Anthropic の最も高度なモデルであり、最小限の監視で複雑なタスクを推論、計画、実行できる高度な AI エージェントを構築できるように設計されています。Anthropic ベンチマークでは、これが現代の市場で入手可能なコーディングモデルのうち、最良であることが示されています。これは、コンテキストの拡張、深い推論、適応型の実行が不可欠なソフトウェア開発シナリオに優れています。開発者は Opus 4 を使用して、プロジェクト全体でのコードの記述やリファクタリング、フルスタックアーキテクチャの管理、大まかな目標を実行可能なステップに分割するエージェントシステムの設計を行うことができます。 SWE-bench や TAU-bench などの エージェント中心のベンチマークやコーディングで優れたパフォーマンスを発揮する ため、多段階の開発ワークフローを処理するエージェントを構築する場合、自然な選択肢となります。例えば、Opus 4 は、プロセス全体を通して要件とアーキテクチャコンテキストを追跡しながら、技術文書の分析、ソフトウェア実装の計画、必要なコードの記述、反復的な改良を行うことができます。 Claude Sonnet 4 Claude Sonnet 4 は、パフォーマンス、応答性、コストのバランスを取ることで Opus 4 を補完するもので、大量生産ワークロードに適しています。コードレビューの強化、バグ修正の実装、即時のフィードバックループを使用した新機能開発など、日常的な開発タスク向けに最適化されており、パフォーマンスが向上しています。また、ほぼリアルタイムのアプリケーション向けの本番環境対応の AI アシスタントにも活用できます。Sonnet 4 は、Claude Sonnet 3.7 のドロップイン代替品です。マルチエージェントシステムでは、Sonnet 4 はタスク固有のサブエージェントとしてうまく機能します。対象を絞ったコードレビュー、検索と検索、またはより広範なパイプライン内での個別の機能開発などの処理を行うことができます。また、Sonnet 4 を使用すれば、高いスループットおよび開発者に合わせたアウトプットを維持しながら、継続的インテグレーションとデリバリー (CI/CD) パイプラインの管理、バグのトリアージの実行、API の統合などを実行できます。 Opus 4 と Sonnet 4 は、ほぼ瞬時の応答と、より深い推論のための拡張思考という 2 つのモードを備えたハイブリッド推論モデルです。インタラクティブなアプリケーションでは、ほぼ即時の応答を選択することができます。また、リクエストにおいてより詳細な分析と計画が必要になる場合は、拡張思考を有効にできます。思考は、ソフトウェアエンジニアリング、数学、科学研究などの分野での長期にわたる推論タスクに特に役立ちます。最大トークン数を設定するなどしてモデルの思考予算を設定することで、レイテンシーと回答深度の間のトレードオフをワークロードに合わせて調整できます。 開始方法 Opus 4 または Sonnet 4 の動作を確認するには、AWS アカウントで 新しいモデルを有効化 します。その後、Opus 4 のモデル ID anthropic.claude-opus-4-20250514-v1:0 と Sonnet 4 のモデル ID anthropic.claude-sonnet-4-20250514-v1:0 で Bedrock Converse API を使用して、コーディングを開始できます。メッセージをサポートするすべての Amazon Bedrock モデルで機能する、一貫した API が提供されるため、Converse API の使用をお勧めします。つまり、一度コードを書いたら、そのコードをさまざまなモデルで使用できるということです。 例えば、コードリポジトリの変更をマージする前にコードをレビューするエージェントを記述したとします。 Bedrock Converse API を使用してシステムプロンプトとユーザープロンプトを送信する、次のコードを記述します。次に、エージェントはストリーミングされた結果を消費します。 private let modelId = "us.anthropic.claude-sonnet-4-20250514-v1:0" // Claude に応答方法を指示するシステムプロンプトを定義します let systemPrompt = """ あなたは Swift、特に Swift 6 の同時実行に関する深い専門知識を持つシニア iOS デベロッパーだとします。あなたの仕事は、並行処理に関連するエッジケース、潜在的な競合状態、Task、TaskGroup、Sendable、@MainActor、@preconcurrency などの Swift 同時実行プリミティブの誤用の特定に焦点を当てたコードレビューを行うことです。 コードを注意深く見直し、同時実行環境で予期しない動作を引き起こす可能性のあるパターンやロジックにフラグを立てる必要があります。例えば、適切な分離なしに共有可変状態にアクセスすること、アクターの誤用、同時実行の境界を越える非 Sendable 型などです。 正確な技術用語を用いて理由を説明し、安全性、予測可能性、正確性を向上させるための推奨事項を提示してください。必要に応じて、慣用的な Swift 6 を使用して具体的なコード変更やリファクタリングを提案してください """ let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt) // テキストプロンプトと画像を含むユーザーメッセージを作成します let userPrompt = """ 次の Swift コードで同時実行の問題がないか確認してください。 うまくいかない可能性があること、およびその修正方法を教えてください。 """ let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt) // テキストと画像の両方のコンテンツを含むユーザーメッセージを作成します let userMessage = BedrockRuntimeClientTypes.Message( content: [prompt], role: .user ) // ユーザーメッセージでメッセージ配列を初期化します var messages: [BedrockRuntimeClientTypes.Message] = [] messages.append(userMessage) // 推論パラメータを設定します let inferenceConfig: BedrockRuntimeClientTypes.InferenceConfiguration = .init(maxTokens: 4096, temperature: 0.0) // ストリーミングを使用して Converse API の入力を作成します let input = ConverseStreamInput(inferenceConfig: inferenceConfig, messages: messages, modelId: modelId, system: [system]) // ストリーミングリクエストを実行します do { // ストリームを処理します let response = try await bedrockClient.converseStream(input: input) // ストリームイベントをイテレーションします for try await event in stream { switch event { case .messagestart: print("AI-assistant started to stream"") case let .contentblockdelta(deltaEvent): // テキストコンテンツが到達したら処理します if case let .text(text) = deltaEvent.delta { self.streamedResponse + = text print(text, termination: "") } case .messagestop: print("\n\nStream ended") // ストリーミングされた応答から完全なアシスタントメッセージを作成します let assistantMessage = BedrockRuntimeClientTypes.Message( content: [.text(self.streamedResponse)], role: .assistant ) messages.append(assistantMessage) default: break } } 同僚の Dennis は、皆さんがすぐに使用を開始できるように、複数のユースケースとさまざまなプログラミング言語に対応する 幅広いコード例 をご用意しています。 Amazon Bedrock で今すぐご利用いただけます このリリースにより、開発者はフルマネージド型のサーバーレスサービスである Amazon Bedrock で、Anthropic が開発した次世代の Claude モデルにすぐにアクセスできるようになります。既に Amazon Bedrock で Claude を使用して構築している方でも、使用を開始したばかりの方も、このシームレスなアクセスにより、インフラストラクチャや複雑な統合を管理することなく、最先端の基盤モデルを使用した実験、プロトタイプ作成、拡張を迅速に実行できます。 Claude Opus 4 は、北米の米国東部 (オハイオ、バージニア北部) と米国西部 (オレゴン) の AWS リージョン でご利用いただけます。Claude Sonnet 4 は、北米の AWS リージョンだけでなく、APAC、欧州 (米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、欧州 (スペイン)) でもご利用いただけます。 クロスリージョン推論 を通じて 2 つのモデルにアクセスできます。クロスリージョン推論は、地域内の最適な AWS リージョンを自動的に選択して、推論リクエストを処理するのに役立ちます。 Opus 4 を使用すると、最も困難な開発タスクに取り組むことができます。一方、Sonnet 4 はスピードと機能の最適なバランスを備え、ルーチンワークに優れています。 料金 と Amazon Bedrock でのこれらの新しいモデルの使用方法 について、今すぐご確認ください。 – seb 原文は こちら です。

このブログは 2024 年 5 月 16 日に Josh Hart, Kim Banga, Thomas Moore によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 アプリケーションはログファイルを生成し、アドホックレポート、コンプライアンス、または監査の目的で確実に保存する必要があります。時間が経つにつれて、このような比較的小さなログファイルのコレクションの量が増え、費用対効果の高いストレージとデータ管理が重要になります。これらのファイル内のデータにアクセスしてクエリを実行することも、データから洞察を得るのに役立ちます。 イベントログを生成するサービスの例としては、 AWS CloudTrail があります。CloudTrail は AWS アカウント内の API 呼び出しとユーザーアクティビティを追跡します。これらのログファイルは、セキュリティ監視、変更追跡、トラブルシューティングに役立ちます。ただし、CloudTrail のログは Amazon S3 バケットに個別のファイルとして保存され、各ファイルのサイズは通常 128 KB 未満です。CloudTrail のログファイルの数は、数週間、数か月にわたるアクティビティによって数千または数百万に増え、それに比例してストレージコストも上昇します。Amazon S3 では、ストレージコストを削減するために Amazon S3 標準 – 低頻度アクセス（ S3 Standard-IA ） や S3 Glacier Instant Retrieval などのストレージクラスを提供していますが、 請求可能な最小オブジェクトサイズは 128 KB で、オブジェクトごとの Amazon S3 ライフサイクル 移行料金がかかります。 S3 Intelligent-Tiering では、 128 KB 未満のオブジェクトを保存できますが、常に高頻度アクセス階層の料金が課金されます。また、大量の小さなファイルを低頻度アクセス階層に移行することには、多大なコストがかかる可能性があります。 本投稿では、 AWS Step Functions を使用して、小さなファイルの大規模なコレクションをより少ない大きなオブジェクトにコンパクション（または結合）するパターンについて説明します。コンパクションは、圧縮などのアーカイブ重視のソリューションに代わる、クエリに適した選択肢を提供します。また、S3 ライフサイクル移行コストを削減することで、アーカイブにも役立ちます（アーカイブ用のコンパクションに焦点を当てた s3tar や Java ベース のソリューションを参照）。さらに、多くの小さなオブジェクトをまとめてコンパクションすることで、128 KB の最小課金サイズを超えるほど大きくなります。加えて、アドホッククエリのパフォーマンスが向上し、既存のコードやツールを変更することなく、クエリをその場で実行できます。 コンパクションとアーカイブの比較 コンパクションという用語は、ファイルの形式や構造を変更せずに、複数のファイルを連結、集約、またはその他の方法で1つの大きなファイルにまとめることを指します。これは、アーカイブファイル形式（.zip や .tar など）を使用してデータを保存するアーカイブとは区別されます。 コンパクションとアーカイブのどちらを選択するかは相互に排他的ではありません。 要件やアクセスパターンに基づいて、圧縮されたデータをコンパクションしたり（例： gzip を使用）、コンパクションされたデータをアーカイブ用に圧縮したりすることができます。 コンパクション（集約）：データの分析的価値を維持し、クエリのパフォーマンスを向上させます。頻繁にデータのクエリや分析を行う必要がある場合に有益です。小さなファイルをより少数の大きなオブジェクトに統合し、その場でより効率的にクエリを実行できるようにします。これらの大きなオブジェクトが Amazon S3 のストレージコストをどのように削減できるかを実証します。コンパクションは、結合されるオブジェクトが意味的に同等である場合に最も効果的です。例えば、ログエントリのストリームや個別の JSON ラインは、ファイル構造を変更せずに集約できます。ただし、オブジェクトキーやメタデータに保存されている詳細情報は失われることに注意してください。集約は S3 ライフサイクルを通じた移行リクエストを減らすことができ、アーカイブに役立ちます。 アーカイブ：クエリの頻度が低い、またはクエリが不要な場合の長期保存に適しています。コンパクションをおこなうことによってさらにコストを最適化できる可能性があります。ファイルごとの JSON オブジェクトや異種のファイルタイプなど、ファイルに包括的な構造がある場合、アーカイブがより適しています。アーカイブ形式は、ディレクトリ構造や元のファイルに関するメタデータも保存できます。 ここで紹介するコンパクション方法は、軽量のサーバーレスパターンを使用してファイルの連結を調整します。 結果として得られる集約ファイルは、その場でクエリ可能な状態を維持します。これにより、データの分析的価値を保持しながら、ストレージコストを最適化し、クエリパフォーマンスを向上させることで、より費用対効果が高く迅速に洞察を得ることができます。 コンパクションの基準として Amazon S3 prefix を使用する S3 Standard Infrequent Access と S3 Glacier Instant Retrieval の請求対象オブジェクトの最小サイズは 128 KB で、小さなオブジェクトに対する過剰なライフサイクル移行料金からユーザーを保護するためのものですが、 大量の小さなログファイルを書き込みたい場合には課題となる可能性があります。コンパクションパターンは、この課題に対処する方法を提供します。また、このパターンはストレージクラス間でオブジェクトを移動する際の S3 ライフサイクル移行コストを回避します。 例えば： Standard ストレージクラスを使用するバケットに、1 KB の 10,000,000 個のオブジェクトがあるとします。 これらを S3 Standard に保存するコストは、1 か月あたり $ 0.23 です。 これらを S3 Standard-IA にそのまま保存する場合のコストは、1 か月あたり $ 16 です（ 128 KB × 10,000,000 × 0.0125 $ / GB ）。 これらを 1,000 個のオブジェクトにコンパクションすると、移行コストは $ 0.01 になり、ストレージコスト（ 1,000 個の出力ファイルに均等に分散されると仮定）は 1 か月あたり $ 0.13 になります。 これらの価格詳細は、執筆時点での US-East-1 リージョンに基づいています。最新情報については、 Amazon S3 料金表 を参照してください。 このトレードオフは、読み取りの粒度が低下することです。コンパクションパターンを使用すると、書き込みと同じ粒度（例えば、各個別のイベントではなく毎日のデータ）ではなく、コンパクションされた形式でのみオブジェクトを取得できます。 コンパクションの比率は、ソース S3 バケット内の prefix の粒度に依存します。例えば、 prefix が日付ごとに日単位の粒度で分割されている場合、各日に対して 1 つの圧縮された出力ファイルが生成されます。入力と出力の間で同じ粒度を維持することで、ソースデータと同じスキーマを使用して、コンパクションされたオブジェクトの効率的なクエリが可能になります。このパターンの例を次の図に示します： これらのより少数で大きなオブジェクトを S3 Standard-IA または S3 Glacier ストレージクラスに移行することで、ストレージコストを削減できます。その後、 ライフサイクルポリシー を使用して、追加料金なしで古い未コンパクションデータを削除することができます。 AWS Lambda と AWS Step Functions 分散マップを使用したオブジェクトのコンパクション このパターンのサンプル実装は GitHub で公開されています。詳細な説明とデプロイ手順については、 README に詳述されている手順に従ってください。この実装では、 AWS Lambda 関数を使用して複数の Amazon S3 prefix を反復処理し、各 prefix 内の小さなファイルの内容を読み取って結合し、それらを 1 つのファイルに集約して宛先バケットに書き込みます。 Lambda では消費したコンピューティング時間に対してのみ料金が発生するため、指定したスケジュールのみ実行する必要があるコンパクションプロセスに適したソリューションとなります。 AWS Step Functions は、アプリケーションコンポーネントの実行を簡単に調整できる完全マネージド型サービスです。Step Functions を使用することで、ファイルのコンパクション Lambda 関数の呼び出しを管理が容易なワークフローに調整できます。小さなファイルを保持するprefix 階層が複数あることを考えると、特定の prefix で発生するファイルのマージは他の prefix から完全に独立しているため、圧縮を並行して実行すると便利です。 Step functions の 分散マップ は、並列データ処理をオーケストレーションするための機能です。この実装例では、ファイルのコンパクションを並列化するために分散マップを使用しています。 このパターンを示す例を次の図に示します： 実行手順は以下の通りです： Amazon EventBridge のスケジュールルールを使用してワークフローをスケジュールします。 Step Functions ワークフローは、設定された日数後に開始されます。呼び出し間隔（日数で測定）が、次の実行でコンパクション対象となる小さなファイルが作成された期間に直接対応するのが合理的です。例えば、完全なソリューションを、30 日ごとに分散マップステートを呼び出すスケジュールルールと共にデプロイし、呼び出し前の 30 日間に作成された小さなファイルを（並列で）コンパクションすることができます。 要求された prefix 内のすべてのファイルをリストアップするために Lambda 関数が呼び出されます。このリストは分散マップステップへの入力として使用されます。 ソースリスト内の各 prefix に対して、その prefix 内のオブジェクトをコンパクションするために並列の Lambda 関数が呼び出されます。 コンパクションされたオブジェクトは、宛先バケット内の同じ prefix 構造に書き込まれます（実際には、これはソースと同じバケットでも構いません）。 注意：この実装例では、キー自体に識別情報が含まれていないことを前提としています。もしそうでない場合 （例えば、キーにオブジェクト内のレコードのID範囲が含まれている場合、例：101-200.json 、201-300.json など）、正しい名前でファイルを出力するか、識別情報をルックアップテーブルに保存するようにソリューションを修正してください。 ソリューションのパフォーマンスとコスト テスト実行では、単一の Lambda 関数の実行で、約 12 分間で 22,000 以上の小さなログファイルを順次コンパクションすることができました。ログファイルは各数 KB で、合計で約 250 MB でした。 複数の prefix に対して同時にコンパクションを実行するために分散マップステートを呼び出した場合、同じ総数のファイルが約 50 秒でコンパクションされました（ 1340 % の時間短縮）。 これは、個々の Lambda 関数の実行時間を最小化するために Step Functions の並列処理を使用することの利点を示しています。これは重要です。なぜなら、 Lambda の最大実行タイムアウトは 15 分だからです。並列処理を採用しない場合、 15 分以内に順次コンパクションできるファイルの最大数に常に注意を払う必要があります。 このソリューションは、大量の小さなデータファイルを持つ環境に対して効率的にスケールします。サーバーレスソリューションとして、基盤となるコンピューティングは AWS によって管理されるため、運用オーバーヘッドは最小限であり、圧縮の実行中に消費されたリソースに対してのみ支払いが発生します。 Step Functions は、関連する prefix のリストを特定してからコンパクションを完了するまでに必要な状態遷移に基づいて課金されます。前述の並列呼び出しテスト実行の場合、全体のコストは AWS 無料利用枠 でカバーされます。無料利用枠以外では、このソリューションは 1,000 個の prefix あたり1回の実行で $ 0.22 未満のコストがかかります。コンパクションを月 1 回実行する場合、年間合計は $ 2.64 です。詳細については、 Lambda と Step Functions の料金ページをご覧ください。 このパターンの効率性は、小さなファイルのサイズと数量だけでなく、ソースバケット内のパーティション全体にどのように分散しているかにも依存します。例えば、 prefix あたりの小さなファイルが少なすぎる場合、コンパクションプロセスのコストとパフォーマンスの向上は、結果としてコンパクションされたオブジェクトが数桁大きくなる場合ほど顕著ではありません。このソリューションを採用する前に、パーティショニング戦略を見直すことが重要です。 Amazon Athena を使用したコンパクションオブジェクトのクエリ実行時のパフォーマンス向上 小さなファイルを圧縮してアーカイブするのではなく、コンパクションをする理由は、データへのリアルタイムアクセスを可能にするためです。アーカイブベースのアプローチでは、クエリを実行する前にデータを解凍する追加のオーバーヘッドが発生します。これは、 CloudTrail を使用した必要に応じた分析や、データレイク内の頻繁にアクセスされないデータに適用されます。 Amazon Athena は、 S3 バケット内に保存された構造化および半構造化データ上で動作するサーバーレス SQL エンジンです。ログ分析の例を取ると、 Athena は必要に応じたクエリと分析に適しています。 Athena は、スキャンされたデータの GB 単位で料金が設定されています。 Athena の主要なパフォーマンス要因の 1 つは、 Amazon S3 内のオブジェクトのパーティション構造です。 コンパクションパターンを使用する際は、ソースデータの時間粒度に合わせてファイルを集約することが重要です（例えば、 Amazon S3 のパーティション構造が年/月/日の場合は日単位）。これにより、クエリ実行時にデータの過剰選択や破棄を防ぐことができます。ソースデータの粒度を超えてファイルをコンパクションすると、クエリパフォーマンスが非効率になり、コストが増加するリスクがあります。例えば、ソースデータが日単位でパーティション化されている場合（2024/02/01 など）、ファイルをコンパクションすべき最も細かいレベルは 1 日単位です。ソースデータの粒度よりも高いレベルでファイルをコンパクションすると、データを効果的にフィルタリングする能力を失うリスクがあり、これは大規模なデータセットに対して過剰選択、コスト増加、クエリパフォーマンスの低下につながります。詳細については、「 prefix を使用してオブジェクトを整理する 」を参照してください。 Athena のパフォーマンスに影響を与えるもう一つの要因は、ファイルのサイズです。多数の小さなファイルは、結果を計算する際にオーバーヘッドを追加する可能性があります。ここでコンパクションがクエリ実行時間を短縮できます。一般的に、ファイルサイズを数百 MB 程度にすることが推奨されます。Athena のクエリパフォーマンスの最適化に関する詳細については、「 Amazon Athena のパフォーマンスチューニング Tips トップ 10 」を参照してください。 以下の例では、1.4 GB のデータが 10,000 個のファイル（1 ファイルあたり 0.14 MB）に分割され、S3 バケット内で日単位でパーティション化されています。 1 日あたり数百の個別ファイルが存在する可能性があります。Athena を使用してこの生データにクエリを実行すると、クエリのパフォーマンスは次のようになります： 同じクエリをコンパクションされたバージョンのデータに対して実行すると、クエリ実行時間は約 66 % 短縮され、クエリの完了時間が短縮されることでクエリの同時実行性も向上します。コンパクションによってファイル数は 293 個（1 ファイルあたり 4.8 MB）に減少しました。以下のスクリーンショットは、スキャンされたデータ量が、圧縮されていないまたは別の形式に変換されていないデータと同じであることを示しています： データ量が増加するにつれて、実行パフォーマンスは線形的にスケールします。以下の例では、約 58 万 2 千個のオブジェクト（合計約 83 GB、1 ファイルあたり 0.14 MB）が 336 個のファイル（1 ファイルあたり 247 MB）にコンパクションされています。クエリを実行すると、同様のパフォーマンス向上が観察されます。以下のスクリーンショットの 1 枚目は、生データが 40 秒で取得されたことを示しています： 次のスクリーンショットは、コンパクションされたデータと改善されたクエリ実行時間 9.7 秒を示しています： 比較のため、同じ実行結果を以下の表に示します： データセット 1： Format Total objects Total size (GB) Average object size (MB) Execution time (s) Raw 10,000 1.4 0.14 16 Compacted 293 1.4 4.8 6.8 データセット 2： Format Total objects Total size (GB) Average object size (MB) Execution time (s) Raw 582,000 83 0.14 40.7 Compacted 336 83 247 9.7 コンパクションアプローチのもう一つの利点は、その実装がクエリエンジンに対して透過的であることです。スキーマとフォーマットが同じであるため、ソースバケットの「ホット」または生データと、「コールド」またはコンパクションされたバケットのデータの両方にまたがってクエリを実行し、結合やユニオンを行うことができます。これにより、最新のデータを保持しながら、集計プロセスを定期的または低頻度で実行することが可能になります。生データとコンパクションデータにまたがってユニオンを実行するクエリの例を、以下のスクリーンショットに示します： Athena を使用してアーカイブデータをクエリする方法の詳細については、ブログ「 Simplify querying your archive data in Amazon S3 with Amazon Athena 」を参照してください。 クリーンアップ GitHub リポジトリからソリューションをデプロイした場合は、予期せぬコストを避けるために 、必ず クリーンアップ手順 に従ってください。 結論 本投稿では、Amazon S3 上の小さなオブジェクトを効率的にコンパクションする方法を探り、ログデータのストレージコストを最適化する効果的な方法であることを示しました。AWS Step Functions を活用することで、数千の小さなオブジェクトを迅速かつ効率的にコンパクションできます。AWS Lambda を使用してコンパクションを実行することで、データコンパクションソリューションのコストを削減し、運用オーバーヘッドを軽減できます。 多数の小さなファイルを、一致する prefix 階層を持つ宛先バケット内のより大きなオブジェクトに集約する際、データのクエリのしやすさは維持されます。Amazon Athena でのコンパクションされたデータに対するクエリ時間は、より少ない数の大きなファイルをスキャンするオーバーヘッドが減少するため、50 〜 70 % 短縮される可能性があります。さらに、コンパクションされたオブジェクトを S3 Standard-IA や S3 Glacier ストレージ Tier に移行する際、このソリューションを定期的に実行することで、ストレージコストを最大 80 % 削減できます。 始めるには、このパターンの実装を示す GitHub 上の サンプルコード を確認してください。この例には、テストデータの生成方法と、お客様の環境でソリューションを試す手順が含まれています。 <!-- '"` --> Josh Hart Josh は Amazon Web Services の Principal Solutions Architect です。彼は英国の ISV のお客様と協力して、AWS での SaaS アプリケーションの構築と近代化を支援しています。 Kim Banga Kim は AWS の Solutions Architect で、英国とアイルランドのソフトウェア企業と協力して、AWS のサービスを最大限に活用してビジネス目標を達成できるよう支援しています。彼のバックグラウンドはクラウドネイティブ開発とマイクロサービスアーキテクチャであり、堅牢で安全でコスト最適化されたソリューションを構築するための最新のパターンを探求することに強い関心を持っています。 Thomas Moore Thomas は AWS の Senior Solutions Architect で、英国とアイルランドの ISV や B2B 組織と連携しています。AWS では、お客様のマルチテナント型 SaaS トランスフォーメーションを支援しています。彼は IT インフラストラクチャ、特に航空、小売、製造業界の企業組織で 10 年以上の経験があります。彼は自動化とサーバーレステクノロジーの活用に情熱を注いでいます。

5 月 21 日、クラウドアーキテクトとクラスター管理者が Kubernetes クラスター全体で組織全体の可視性を維持することを可能にする一元的なビュー、EKS ダッシュボードを発表しました。EKS ダッシュボードでは、複数の異なる AWS リージョンやアカウントにデプロイされたクラスターを統合ビューで監視できるので、クラスターインベントリの追跡とコンプライアンスの評価に加えて、バージョンアップグレードなどの運用アクティビティの計画が容易になります。 Kubernetes デプロイをスケールする組織では、可用性の向上、事業継続性の確保、またはデータ主権の維持を目的として、さまざまな環境にわたって複数のクラスターが実行されることがあります。ただし、このような分散型のアプローチでは、複数のリージョンやアカウントにまたがる分散型のセットアップで可視性と制御を維持することが困難になることがあります。現在、多くのお客様はサードパーティーのツールを使用してクラスターの一元的な可視化を行っていますが、ID とアクセスのセットアップ、ライセンスコスト、メンテナンスのオーバーヘッドなどの複雑さに対処する必要があります。 EKS ダッシュボードは AWS コンソール 内でネイティブダッシュボード機能を提供することで、このエクスペリエンスを簡素化します。ダッシュボードは、3 つの異なるリソース (クラスター、マネージドノードグループ、EKS アドオン) に関するインサイトを提供し、クラスター分布に関する集約インサイトをリージョン、アカウント、バージョン、サポートステータス、延長サポートの EKS コントロールプレーンの予測コスト、クラスターヘルスメトリクスに基づいて表示することができます。自動フィルタリングで特定のデータポイントをドリルダウンできるため、注意が必要なクラスターをすばやく特定して集中できます。 EKS ダッシュボードをセットアップする EKS コンソールのダッシュボードへは、AWS Organizations の 管理 アカウントと 委任された管理者 アカウントからアクセスできます。セットアッププロセスは簡単で、必要な操作は Amazon EKS コンソールの組織設定ページで信頼されたアクセスを一度有効にすることだけです。信頼されたアクセスは、 [ダッシュボード設定] ページからアクセスできます。信頼されたアクセスを有効にすると、管理アカウントでダッシュボードを表示できるようになります。セットアップと設定の詳細については、公式の AWS ドキュメント を参照してください。 EKS ダッシュボードのクイックツアー ダッシュボードには、Kubernetes クラスターのグラフィカルビュー、表形式、マップビューが表示され、高度なフィルタリングや検索機能を利用できます。データをエクスポートして、詳細な分析やカスタムレポートの作成を行うこともできます。 クラスターに関する主要な情報を表示する EKS ダッシュボードの概要。 クラスターの視覚化に役立つさまざまなウィジェットが用意されています。 マネージドノードグループは、インスタンスタイプ分布、起動テンプレート、AMI バージョンなどに基づいて視覚化できます。 世界中のすべてのクラスターを確認できるマップビューもあります。 EKS クラスターを超えて EKS ダッシュボードは Amazon EKS クラスターだけに限定されたものではなく、オンプレミスまたは他のクラウドプロバイダーで実行されている接続された Kubernetes クラスターを可視化することもできます。接続されたクラスターでは、ネイティブの Amazon EKS クラスターと比較してデータの忠実度に制限がある場合がありますが、この機能を使用すると、ハイブリッドまたはマルチクラウド環境を実行している組織で真に統合された可視性が得られます。 今すぐ利用可能 現在、EKS ダッシュボードは米国東部 (バージニア北部) リージョンで利用可能で、すべての商用 AWS リージョンのデータを集約できます。EKS ダッシュボードを使用するための追加料金はありません。詳細については、 Amazon EKS のドキュメント を参照してください。 この新機能は、お客様がインフラストラクチャの管理ではなくアプリケーションの構築とスケーリングに集中できるようにすることで、Kubernetes の運用を簡素化するという当社の継続的な取り組みを示しています。お客様がどのように EKS ダッシュボードを使用して Kubernetes の運用を強化しているかを見るのを楽しみにしています。 – Micah 原文は こちら です。

この記事は DoorDash の Vraj Shah と Chaitanya Hari との共著です。 DoorDash は、世界中の 30 か国以上で消費者と地元の好みのビジネスをつないでいます。Door Dash は、Dasher として知られる契約配達員からの大量の電話対応で大きな課題に直面していました。2023 年末時点で 3,700 万人以上のアクティブな消費者と月間 200 万人のアクティブな Dasher を抱える同社は、 Dasher により効率的なセルフサービス体験を提供することで、ライブエージェントの負担を軽減する必要性を認識しました。 この課題に対処するため、DoorDash のコンタクトセンターチームは、高水準の問題解決と顧客満足度を維持しながら、迅速かつ大規模に解決策をデプロイするために 生成 AI の力を活用したいと考えました。道路上にいる間はテキストよりも電話でのサポートを好む Dasher には、最小限の応答遅延で迅速で信頼性の高い支援が必要です。この低遅延要件は、 DoorDash が音声による効果的なセルフサービスソリューションを追求する上で重要な要素となりました。 ライブエージェントによる支援の必要性を減らすために、DoorDash は AWS Generative AI Innovation Center と協力してわずか 2 か月で、Dasher に低遅延のセルフサービス音声体験を提供するソリューションを構築しました。 このソリューションは、音声対応の会話型 AI サービスである Amazon Lex 、主要な AI スタートアップと Amazon からの基盤モデル (FM) を API を通じて利用可能にし、ユースケースに最適なモデルを選択できる完全マネージド型サービスである Amazon Bedrock 、そして大規模言語モデル (LLM) をデータソースに接続する完全マネージド型サービスの Amazon Bedrock のナレッジベース を使用しています。これは、フルサーバーレスアーキテクチャで、基盤となるインフラストラクチャを管理することなくペタバイト規模のワークロードを実行できる Amazon OpenSearch Serverless を使用しています。 このソリューションは 1 日数十万件の電話に対応し、2.5 秒以内に Dasher の質問に回答しています。また、自動テスト、会話分析、監視と可観測性、LLM ハルシネーションの防止と検出を含む運用機能も提供しています。 「私たちはDasherが最も一般的な質問や問題について、できるだけ迅速かつ効率的に支援を受けられるようにしたいと考えていました。それによって彼らの時間と労力を節約し、DoorDash のセルフサービス機能への信頼を高めることができます」 – Chaitanya Hari, Contact Center Product Lead at DoorDash. この記事では、AWS サービスを使用してコンタクトセンターに生成 AI エージェントをデプロイする方法を紹介します。 ソリューション概要 この記事では、Example Corp Hospitality Group という架空のホテルチェーンの例を使用します。以下は、顧客と LLM による自動エージェントとの対話の例です： 顧客 : こんにちは、家族旅行に最適な場所を探しています エージェント : Example Corp Family Getaways では、テーマパーク、国立公園、歴史的な名所などの人気観光スポット近くにある家族向けホテルやリゾートを提供しています。リゾートには広々とした宿泊施設、全年齢向けのアクティビティ、多様な食事オプションがあり、忘れられない家族の思い出を作ることができます。 顧客 : どこにありますか？ エージェント : Example Corp Family Getaways は、フロリダ州オーランド、カリフォルニア州アナハイム、バージニア州ウィリアムズバーグ、テネシー州ピジョンフォージ、テキサス州サンアントニオ、アリゾナ州スコッツデール、ミズーリ州ブランソン、ウィスコンシン州ウィスコンシンデルズ、ペンシルベニア州ハーシーなど、さまざまな人気の休暇先で家族向けリゾートを提供しています。 顧客 : ピジョンフォージが面白そうですね。 エージェント : ピジョンフォージのリゾートでは、ドリーウッドやその他の近隣のアトラクションの興奮を楽しみながら、大自然を体験する機会を家族に提供しています。宿泊客は室内ウォーターパーク、ミニゴルフコース、ファイヤーピット周辺での夜のスモア焼きを楽しむことができます。 顧客 : 子供向けメニューはありますか？ エージェント : テネシー州ピジョンフォージの Example Corp Family Getaways リゾートでは、ピザ、チキンナゲット、マカロニチーズなどのお気に入りを含む専用の子供向けメニューなど、家族向けの食事オプションを提供しています。 自分の AWS アカウントでソリューションをデプロイして、このサンプルソリューションを試すことができます。以下の図はソリューションアーキテクチャを示しています。 ソリューションの主要コンポーネントのデプロイとテストの手順を説明します： ソリューションが質問に回答するために使用するコンテンツを保存する Amazon Bedrock Knowledge Bases を設定する AWS CloudFormation スタック Amazon Lex ボットとコアとなる検索拡張生成（RAG）に基づく質問応答機能を実装する AWS Lambda 関数を作成する CloudFormation スタック （オプション）会話分析ダッシュボードを有効にするデータパイプラインをデプロイする CloudFormation スタック （オプション）LLM ハルシネーションの非同期検出機能を有効にする CloudFormation スタック （オプション）生成された回答と正解の回答を比較し、合格/不合格の評価と説明を提供するための自動テスト機能を利用できる Amazon SageMaker の Jupyter ノートブック 必要なすべてのものは、 GitHub リポジトリ でオープンソースとしても提供されています。 ※ 日本のお客様向けの補足事項 ： 本ソリューションは、英語のみに対応していますが、「RAGソリューションスタックのデプロイ」の実施後に、Amazon Lex の日本語追加を行い、Lambda 関数の該当コードにおけるプロンプトを日本語に修正することで、日本語による応対も簡易的に検証可能です。LLM として Anthropic の Claude 3 Haiku、Claude 3 Sonnet を選択した場合は、Lambda 関数コードの bedrock_utils/hotel_agents/anthropic.py と bedrock_utils/conversational_agents/anthropic.py のプロンプトを日本語に修正します。 前提条件 このアプリケーションに必要なリソースとコンポーネントを作成および管理するための権限を持つ AWS アカウントと AWS Identity and Access Management (IAM) ロールおよびユーザーが必要です。AWS アカウントをお持ちでない場合は、 「新しい AWS アカウントを作成して有効化する方法を教えてください。」 を参照してください。 このソリューションでは、Amazon Bedrock を使用して ナレッジベースから質問に対する回答を見つけます。次に進む前に、少なくとも以下のAmazon Bedrockモデルへのアクセスをリクエストしてください（既にアクセスが有効な環境ではこの作業は不要です）： Amazon Titan Embeddings G1 – Text Cohere Embed English v3 と Cohere Embed Multilingual v3 Anthropic の Claude 3 Haiku と Anthropic の Claude 3 Sonnet Amazon Connect と統合する場合は、ご自身のアカウントで利用可能な Amazon Connect インスタンスがあることを確認してください。まだない場合は作成できます。会話分析スタックをデプロイする場合は、Amazon QuickSight が 必要となるため、アカウント内で有効になっていることを確認してください。 執筆時点では、このソリューションは以下の AWS リージョンで利用可能です：アジアパシフィック（シンガポール、シドニー、東京）、カナダ（中部）、ヨーロッパ（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）。 Amazon Bedrock ナレッジベースのデプロイ Amazon Simple Storage Service (Amazon S3) をデータソースとして使用するナレッジベースには、CloudFormation スタックを使用できます。ナレッジベースをセットアップするには、以下の手順を実行します： AWS アカウントにサインインし、“Launch Stack” を選択して CloudFormation テンプレートをデプロイします 「次へ」をクリックし、スタック名を入力します（例：contact-center-kb）。 S3 bucket where you will store your content : 既存の S3 バケット名を入力します（例：contact-center-kb-{your-account-number}）。これはデモソリューションのコンテンツが保存される場所です。まだ S3 バケットがない場合は作成してください。 S3 prefix for your content (optional) : 何も入力しないでください。 Choose an embedding model : 埋め込みモデルを選択します（例：amazon.titan-embed-text-v2:0） Choose a chunking strategy (default, fixed-size, or none) : “Fixed-sized chunking” （固定サイズのチャンキング戦略）を選択します。 For fixed-size chunking, choose a maximum number of tokens per chunk : チャンクサイズを指定します。Amazon Titan 埋め込みモデルを使用する場合は “600” 、Cohere 埋め込みモデルの場合は “512” を入力します。これは約 1 ページ分のテキストに相当します。 For fixed-size chunking, choose an overlap percentage between chunks : チャンクのオーバーラップの割合として “10” を入力します。 Index Details : 4 つのエントリ（インデックス名、ベクトルフィールド名、メタデータフィールド名、テキストフィールド名）はデフォルト値のままにします。 「次へ」を選択します。 「スタックオプションの設定」ページの下部で、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します。 「確認して作成」のページで、「送信」を選択します。 スタックのデプロイには約 10 分かかります。 サンプルコンテンツのアップロードと ナレッジベースのテスト このソリューションのデモサンプルには、架空のホテルチェーン Example Corp Hospitality Group に関する質問に答えることができる LLM ベースのホテルボットが含まれています。このホテルチェーンのコンテンツを、ナレッジベーススタック用に指定した S3 バケットにロードする必要があります。 CloudFormation スタックによって使用される S3 バケットは、スタックの「出力」タブで確認できます。 AWS Command Line Interface （AWS CLI）または AWS Management Console のいずれかを使用して、 GitHub リポジトリの content セクション から以下のフォルダをアップロードします。PDF 版または Word 文書版（Word 版推奨）のいずれかを選択できます。 corporate family-getaways luxury-suites party-times seaside-resorts waypoint-inns 完了すると、S3 バケットの最上位レベルには、それぞれ単一の Word または PDF ドキュメントを含む 6 つのフォルダがあるはずです。 Amazon Bedrock コンソールで、ナビゲーションペインの「ナレッジベース」を選択します。 CloudFormation によって作成されたナレッジベースを選択して開きます。「1 つ以上のデータソースが同期されていません」というメッセージが表示されます。 データソースを選択し、「同期」を選択します。 同期プロセスは数分しかかかりません。 データソースが同期された後、ナレッジベースを開くと、マネジメントコンソールの右側で ナレッジベースによる質問回答をテストできます。必要なモデルが Amazon Bedrock の「モデルアクセス」ページで有効になっていることを確認してください。 LLM（ Anthropic の Claude 3 Haiku など）を選択し、質問を始めましょう！アップロードしたサンプル文書を読んで、質問のアイデアをいくつか考えてみるとよいでしょう。 ハルシネーション検出スタックのデプロイ（オプション） オプションの非同期ハルシネーション検出機能を使用したい場合は、このスタックをデプロイします。それ以外の場合は、次のセクションに進みます。この CloudFormation スタックは、非同期ハルシネーション検出が必要な RAG ベースのソリューションで使用できます。 “Launch Stack” を選択します 「次へ」をクリックし、スタック名を入力します（例：contact-center-hallucination-detection） Select an LLM : ハルシネーション検出を実行する LLM を指定します。執筆時点では、ハルシネーション検出に推奨される LLM が 8 つあります。デフォルト値の “Claude V3 Sonnet” を選択します。 Create a Customer-Managed Key? : オプションで、“Create a Customer-Managed Key?” で、 Amazon Simple Queue Service （Amazon SQS）キューと Lambda 関数の Amazon CloudWatch Logs ロググループを暗号化するための Amazon Key Management Service （AWS KMS）カスタマーマネージドキー（CMK）を作成します（本番環境では推奨）。 このスタックには2種類の Amazon CloudWatch アラームがあります： ERROR アラーム – ハルシネーション検出作業を実行する Lambda 関数のコードの問題に関するもの WARNING アラーム – Lambda 関数が実際にハルシネーションを検出した場合のためのもの どちらのアラームタイプもオプションですが、有効化することを推奨します。 Create CloudWatch ERROR alarms? : ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Create CloudWatch WARNING alarms? : WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。 Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。 「次へ」を選択します。 「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します 「確認と作成」ページで、「送信」を選択します。 スタックのデプロイには約 1 〜 2 分かかります。 スタックが完了したら、CloudFormation スタックの「リソース」タブで作成されたリソースを確認できます。特に、 Lambda 関数のコードを確認してください。 アラーム通知用のメールアドレスを入力した場合は、サブスクリプションの確認を求めるメールリクエストを受け取るはずです。アラームが発生した場合に通知を受け取るには、メール本文の “Confirm subscription” をクリックしてください。 RAGソリューションスタックのデプロイ Amazon Connect と統合する場合は、アカウントでインスタンスが利用可能であることを確認してください。まだない場合は作成できます。Amazon Lex ボットと Lambda 関数をデプロイするには、以下の手順を完了します： “Launch Stack” を選択します 「次へ」をクリックし、スタック名を入力します（例：contact-center-rag-solution） Lex bot name : Amazon Lex ボットの名前を入力します（例：hotel-bot） Number of conversation turns for context : コンテキスト用に保持する会話ターンの数を指定します。これは異なるユースケースとデータセットに合わせて最適化できます。hotel-bot デモには、デフォルトの 4 を試してみてください。 Conversation logs group ARN : オプションで、Amazon Lex の会話ログ用に既存の CloudWatch Logs ロググループ ARN を指定します。会話分析スタックをデプロイする予定の場合は、これが必要になります。 まだロググループがない場合は作成してください 。 Number of AWS Lambda provisioned concurrency units (use 0 for no provisioned concurrency) : オプションで、Amazon Lex ボットハンドラー関数の Lambda Provisioned Concurrency 単位の値を入力します。ゼロ以外の数値を設定すると、Lambda コールドスタートを防ぐことができます。本番環境と内部テストに推奨されます。開発には、0 または 1 が推奨されます。 Create a Customer-Managed Key? : オプションで、Lambda 関数の CloudWatch Logs ロググループを暗号化するための KMS CMK を作成するオプションを選択します（本番環境で推奨）。 Connect instance ARN : Amazon Connect と統合する場合に指定します。Amazon Connect インスタンス ARN を入力します。 Connect contact flow name : Amazon Connect と統合する場合に指定します。スタックが作成する新しいコンタクトフローの名前を入力します。 Knowledge Base ID : 作成したナレッジベーススタックからナレッジベースIDを提供します。これは知識ベーススタックの「出力」タブで確認できます。 Knowledge Base S3 bucket : ナレッジベースで使用している S3 バケットを提供します（ナレッジベーススタックの「出力」タブで参照できます）。 SQS Queue Name : ハルシネーション検出スタックを作成した場合に、SQS キュー名を入力します。（ハルシネーション検出スタックの「出力」タブで参照できます） SQS Queue Encryption Key ARN : ハルシネーション検出スタック用に KMS キーを選択した場合は、KMS キー ARN を入力します。 「次へ」を選択します。 「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します 「確認と作成」ページで、「送信」を選択します。 スタックの完了には数分かかります。 RAG ソリューションを試すには、Amazon Lex コンソールに移動し、hotel-bot ボットを開きます。ボットには英語言語セクションが 1 つあります。 ナビゲーションペインで「インテント」を選択し、このサンプルボットの意図を確認します。以下が含まれます： ホテルチェーンと様々なホテルブランドの質問に関連するインテント – Accommodations 、 Amenities 、 CorporateOverview 、 Locations 、 Parking などが含まれます。これらのインテントは Amazon Lex によって RAG ソリューションにルーティングされます。技術的には、このような種類のリクエストを FallbackIntent で処理することもできるため、これらのインテントは省略して RAG に転送することも可能です。しかし、これらのインテント（およびそのサンプル発話）を含めることで、Amazon Lex に各ドメインの言語に関する情報を付与し、speech-to-text エンジンを最適化して文字起こしの精度を向上させることができます。さらに、これらのインテントを含めることは会話分析にも役立ちます。 SwitchBrand – このインテントは、会話の途中でユーザーが「他のホテルはどうですか？」などと言えるようにすることで、会話のフローを改善するために設計されています。 Booking – これは、発信者をライブエージェントキューにルーティングする例を示しています。 SpeakToAgent – このインテントは、発信者が特にライブエージェントをリクエストする場合のためのものです。 Welcome 、 Goodbye 、 Help – これらの会話サポートインテントは、会話の開始と終了、またはボットができることを尋ねるためのものです。 FallbackIntent – これは、他のインテントに一致しない質問やリクエストのための標準インテントです。このサンプルソリューションでは、そのようなリクエストもRAG ソリューションにルーティングされ、LLM がナレッジベース内のコンテンツに基づいて回答できるようになっています。 SelectKnowledgeBase と SelectLLM – これらは、ユーザーが RAG ソリューションに異なるナレッジベースインスタンス（複数利用可能な場合）や異なる LLM を使用するよう指示することを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外のデプロイメントにのみ含めるべきです。Amazon Bedrock で利用可能な任意の LLM で RAG ソリューションをテストできます。また、必要に応じて会話の途中で別のナレッジベースや LLM に切り替えることもできます。 ToggleLLMGuardrails （LLMガードレールの切り替え）と ToggleLLMContext （LLMコンテキストの切り替え） – これらは、ユーザーがプロンプトベースの LLM ガードレールをオフまたはオンに切り替えたり、ナレッジベースからの情報取得を無効または有効にしたりすることを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外の環境にのみ含めるべきです。必要に応じて、会話の途中でこれらの設定をオフやオンに切り替えることができます。 Amazon Lex コンソールで「テスト」を選択して、ソリューションを試すことができます。 いくつかのサンプル会話を試してみてください。例えば： “We’re looking for a nice place for a family vacation” (「家族旅行に素敵な場所を探しています」) と尋ねると、ボットは Example Corp Family Getaways offers family-friendly resorts…” (「Example Corp Family Getaways では家族向けの宿泊施設を提供しています…」) と応答します。 “Where are they located?” (「どこにありますか？」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「Example Corp Family Getaways には…に所在地があります」) と応答します。 “Tell me more about the one in Pigeon Forge” (「ピジョンフォージについてもっと教えてください」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「テネシー州ピジョンフォージの Example Corp Family Getaways リゾートは…」) と応答します。 質問のアイデアについては、アップロードした サンプルドキュメント を参照してください。 ハルシネーション検出スタックをデプロイした場合は、テスト時に得た回答の評価を確認できます。ハルシネーション検出スタックの詳細ページの「リソース」タブで、「HallucinationDetectionFunctionLogGroup」エントリを選択します。これにより、Lambda ハルシネーション検出関数の CloudWatch Logs ロググループが開きます。ログステートメントを調査して、ハルシネーション検出プロセスがどのように機能しているかを確認できます。 Amazon Connect と統合している場合は、指定した Amazon Connect インスタンスに新しいコンタクトフローが作成されています。 音声でテストするには、電話番号を要求し、このコンタクトフローに関連付けて、電話をかけるだけです！ 会話分析スタックのデプロイ（オプション） このスタックは QuickSight を分析に使用するため、このスタックをデプロイする前に AWS アカウントですでに有効になっていることを確認してください。 “Launch Stack” を選択します CloudWatch Logs log group for Lex Conversation Logs : Amazon Lex 会話ログを保存している CloudWatch ロググループの名前（※ ARNではない点に注意）を入力します。これは、RAGソリューションをデプロイした CloudFormation スタックにも使用した CloudWatch Logs ロググループです。 Purge Source Logs? : ロググループからソースログストリームを削除するオプションを選択します。テストの場合は “no” を選択します。 Redact Sensitive Data? : 会話ログから機密データを編集するオプションを選択します。テストの場合は “no” を選択します。 List of PII entity types to redact : 個人を特定できる情報（PII）のエンティティタイプを設定します。ここでは、デフォルト値のままにしておきます。 Minimum confidence score for Amazon Comprehend redaction : PII の信頼スコアのしきい値を設定します。ここでは、デフォルト値のままにしておきます。 Allow unredacted application logs? : データパイプラインの Lambda 関数の編集されていないログを許可するオプションを選択します。テストの場合は “yes” を選択します。 Create a Customer-Managed Key (CMK)? : KMS CMK を作成するオプションを選択します。 作成された CMK は、会話データを格納するためにこのスタックが作成する S3 バケットのデータを暗号化するために使用されます。これにより、どの IAM プリンシパルがデータを復号化して表示できるかを制御できます。この設定は本番環境で推奨されます。 Create CloudWatch ERROR alarms? : Amazon Lex データパイプラインで、ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。 Create CloudWatch WARNING alarms? : Amazon Lex データパイプラインで、WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。 「次へ」を選択します。 「スタックオプションの設定」ページで「次へ」を選択します 「確認と作成」ページで、IAM 機能メッセージを承認し、「送信」を選択します スタックの完了には約 5 分かかるはずです。 以下の図はスタックのアーキテクチャを示しています。 Amazon Lex が CloudWatch Logs (1) に会話ログエントリを書き込むと、 Amazon Data Firehose によって取得され、S3 バケット (2) にストリーミングされます。その過程で、Lambda 変換関数 (3) がデータの JSON 構造を簡素化し、クエリ目的でよりユーザーフレンドリーにします。Lambda 関数は Amazon Comprehend (4) を使用して機密データを編集することもでき、オプションで CloudWatch Logs ロググループからエントリを消費する際に削除することもできます。 スケジュールベース (5 分間隔) で、 AWS Glue クローラー (5) が S3 バケットの新しいデータを検査し、 Amazon Athena (6) がデータへの SQL インターフェースを提供するために使用するデータスキーマを更新します。これにより、QuickSight (7) のようなツールがデータのほぼリアルタイムのダッシュボード、分析、視覚化を作成できるようになります。 QuickSightダッシュボードの設定（オプション） QuickSight ダッシュボードを作成する前に、Amazon Lex コンソールに戻り、ダッシュボード用のデータを生成するためにいくつかの質問をしてください。パイプラインがこの新しい会話データを処理して QuickSight で利用できるようになるまで約 5 分かかります。 QuickSight でダッシュボードと視覚化を設定するには、以下の手順を完了します。 QuickSight コンソールで、ユーザープロファイルアイコンを選択し、「QuickSight を管理」を選択します。 「セキュリティとアクセス許可」の、「QuickSight の AWS のサービスへのアクセス」の「管理」を選択します。 「Amazon S3」の下で、「S3 バケットを選択」を選択します。 会話分析スタックによって作成された S3 バケットへのアクセスを有効にします（12文字の一意の識別子が前に付いた「lex-conversation-logs」という名前になります）。書き込み権限を有効にする必要はありません。 「完了」を選択し、次に「保存」を選択します。 QuickSight メニューアイコンを選択して、QuickSight のメインページに戻ります。 ナビゲーションペインで「データセット」を選択します。 「新しいデータセット」を選択します。 データセットソースのリストから「Athena」を選択します。 データソース名を入力します（例：contact-center-analytics）。 「データソースを作成」を選択します。 「テーブルの選択」ウィンドウで、データベースを選択し、「lex_conversation_logs」テーブルを選択して、「データの編集/プレビュー」を選択します。 これにより、新しい QuickSight データセットが開きます。利用可能なさまざまな属性を確認し、テストからいくつかの結果を見ることができます。 データの表示速度を向上させるために、「クエリモード」に「SPICE」オプションを選択できますが、その場合、追加のテストに基づいてデータの更新を確認したい場合は、SPICEを更新する（または毎時自動更新スケジュールを設定する）必要があります。 現時点では、設定を「直接クエリ」のままにしておきます。 準備ができたら、「保存して視覚化」を選択します。 「新しいシート」ウィンドウでデフォルトを維持し、「作成」を選択します。 これにより分析ページが開き、視覚化の作成を開始できます。 自動テストノートブック（オプション） 自動テスト機能を試すには、SageMaker Jupyter ノートブックが必要です。または、Jupyter ノートブックをサポートする統合開発環境（IDE）やその他の環境でノートブックをローカルで実行することもできます。 Amazon SageMaker AI コンソールのナビゲーションペインの “Notebooks” を選択します。 「ノートブックインスタンスの作成」を選択します。 ノートブックに名前を付けます（例：contact-center-rag-testing）。 マルチスレッドテストを有効にするには、ml.m5.2xlarge（8 vCPU）やml.m5.4xlarge（16 vCPU）などの大きなインスタンスを選択することをお勧めします。使用していないときは停止することを忘れないでください。 プラットフォーム識別子のデフォルト設定（Amazon Linux 2、Jupyter Lab 4）を維持します。 「追加設定」の下で、「ボリュームサイズ（GB）」の設定を 50 GB に増やします。 「アクセス許可と暗号化」セクションの「IAMロール」で、ドロップダウンリストから「新しいロールを作成」を選択します（ロール作成ウィザードは使用しないでください）。 「IAMロールの作成」ウィンドウで、アクセスを提供したい S3 バケットを指定できます（このソリューションには必要ありません）。 「ロールの作成」を選択します。 「ノートブックインスタンスの作成」を選択します。 ノートブックインスタンスが利用可能になるまでには数分かかります。作成中に、Amazon Bedrock と Amazon Lex にアクセスするために必要なインラインポリシーを追加するためにIAM ロールを更新できます。 「ノートブックインスタンス」ページで、ノートブックインスタンス（例：contact-center-rag-testing）を開き、“IAM ロール ARN” の下のエントリを選択してロールを開きます。 次のインラインポリシー（GitHubリポジトリの notebooks/iam-roles フォルダで利用可能）を追加します。必要に応じてこれらのロールを修正して、リソースアクセスを制限できます。 bedrock-agents-retrieve.json bedrock-invoke-model-all.json lex-invoke-bot.json opensearch-serverless-api-access.json ノートブックインスタンスが起動した後、「Jupyter を開く」を選択してノートブックを開きます。 以下をノートブックインスタンスにアップロードします（必要に応じて、ファイルをローカルで圧縮し、圧縮アーカイブをアップロードして、SageMaker で解凍することもできます）。 bedrock_helpers.py – このスクリプトはノートブックの LLM インスタンスを設定します。 bedrock_utils – すべてのサブフォルダとファイルをアップロードし、フォルダ構造が正しいことを確認してください。 run_tests.ipynb – このノートブックはテストケースのセットを実行します。 generate_ground_truths.ipynb – 質問のセットが与えられると、このノートブックは潜在的な正解の回答を生成します。 test-runs – このフォルダにはExcelワークブックが含まれているはずです。 run_tests.ipynb ノートブックを開きます。 2 番目のセルで、bot_id と bot_alias_id の値を Amazon Lex ボットの値に置き換えます（これらは RAG ソリューションスタックの「出力」タブで確認できます）。 これらの値を更新した後、“Restart the kernel and run all cells” のアイコンを選択します。 ml.m5.2xlarge インスタンスタイプを使用している場合、 test-runs/test-cases-claude-haiku-2024-09-02.xlsx ワークブックの 50 のテストケースを実行するのに約 1 分かかるはずです。完了すると、ノートブックの test-runs フォルダに対応するテスト結果ワークブックが見つかるはずです。 数分後、会話分析ダッシュボードでもテスト結果を確認できます。 ソリューションをユースケースに適応させる このソリューションは最小限の作業で特定のユースケースに適応させることができます： Amazon Bedrock ナレッジベース のサンプルコンテンツを置き換える – S3バケットのコンテンツを置き換え、ユースケースに合ったフォルダ構造に整理します。置き換えたコンテンツ用に新しいナレッジベースを作成できます。 Amazon Lex ボットのインテントをユースケース用のインテントで置き換える – ユースケース用に有効にしたい対話を反映するように Amazon Lex ボットの定義を変更します。 bedrock_utils コードの LLM プロンプトを変更する – Amazon Lex ボット実行 Lambda 関数で、 bedrock_utils フォルダの LLM プロンプト定義を確認します。例えば、LLMベ ースのエージェントの役割に関するユースケース固有の定義を提供します。 必要に応じてボットハンドラーコードを変更する – Amazon Lex ボット実行 Lambda 関数で、 TopicIntentHandler.py 関数のコードを確認します。知識ベース検索では、このコードはトピックとしてサンプルホテルブランドを使用する例を提供します。このメタデータ検索クエリを、ユースケースに適したものに置き換えることができます。 クリーンアップ おめでとうございます！AWS サービスを使用して音声対応のコンタクトセンター生成 AI エージェントソリューションをセットアップするためのすべての手順を完了しました。 ソリューションを AWS アカウントにデプロイする必要がなくなった場合は、デプロイしたCloudFormation スタック、および作成した場合は SageMaker ノートブックインスタンスを削除できます。 結論 コンタクトセンター 生成 AI エージェントソリューションは、Amazon Bedrock、Amazon Bedrock Knowledge Bases、OpenSearch Serverless、Amazon Lex などのサービスを使用して、コンタクトセンターでの Q&amp;A 会話を自動化するためのスケーラブルで費用対効果の高いアプローチを提供します。 ソリューションコードはオープンソースとして提供されています。これを自分のソリューションの出発点として使用し、GitHub プルリクエストを通じて修正と機能を提供することで、より良いものにするのを手伝ってください。GitHub リポジトリを参照してコードを調査し、最新の変更についてはCHANGELOG を、最新のドキュメント更新については README を確認してください。 専門家のサポートについては、AWS Generative AI Innovation Center、 AWS Professional Services 、および AWS Partners がお手伝いします。 翻訳はソリューションアーキテクト新谷が担当しました。原文は こちら です。