はじめに Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect のデジタルチャネルおよび音声機能を Salesforce に統合した画期的なソリューションとして、現在一般提供されています。音声チャネル専用の Service Cloud Voice (SCV) を基盤として、SCC-AC は、Amazon Connect と Salesforce 間で音声チャネルとデジタルチャネルを統合することで、カスタマーエクスペリエンス、エージェントエクスペリエンス、および業務効率を向上させることを可能にします。 主な機能 Salesforce Contact Center with Amazon Connect (SCC-AC)は、Amazon Connect のチャネルと機能を Salesforce 内でネイティブに利用可能にします。SCC-AC は、マネージドパッケージとして Salesforce App Exchange で利用できます。このパッケージを Salesforce 組織にインストールするには、基盤となる Salesforce インスタンスが Salesforce Service Cloud Voice に対応している必要があります。SCC-ACの最初のリリースでは、以下の主要機能が 利用可能になりました。 新しいチャネル SCC-AC は、Amazon Connect Chat(SMS、Web チャット、ソーシャルメッセージング)をネイティブで提供します。お客様は、Amazon Connect Chat を、セルフサービス用の Amazon Q in Connect (QiC) や会話分析用の Amazon Connect Contact Lens などの他の機能と組み合わせて使用することができます。 注：Amazon Connect Chat は現在、Service Cloud Voice Partner Telephony from Amazon Connect(別名 Service Cloud Voice Bring Your Own Amazon(BYOA))でのみ利用可能です。なお、日本では Service Cloud Voice Partner Telephony from Amazon Connect の形態でのみ Service Cloud Voice を利用可能となっています。 以下の図は、SCC-AC における Amazon Connect メッセージングチャネルのハイレベルなアーキテクチャ、データフロー、および API シーケンスを説明しています。 お客様が Web サイトやモバイルアプリでホストされているチャットクライアント、または SMS からチャットメッセージを開始します。 Amazon Connect のコンタクトフローが起動し、初期のガイダンスを行い、その後 Amazon Lex を使用したセルフサービスを提供します。 チャットをエージェントに転送する前に、コンタクトフロー内で AWS Lambda 関数が呼び出されます。 この AWS Lambda 関数は、Salesforce バックエンドにメッセージングセッションを生成するために Salesforce Interaction Service API を呼び出します。 エージェントを特定した後、SCC-AC コネクターが受信したエージェントにチャットリクエストがルーティングされます。 SCC-AC コネクターは、Salesforce で生成された作業項目 ID (Work item ID) を使用して Salesforce バックエンドからメッセージングセッションの情報を取得します。 SCC-AC コネクターは、メッセージングセッションに基づいて、Salesforce バックエンドでエージェントが対応すべきタスクを作成します。 Salesforce バックエンドは、顧客メッセージと 関連情報を含む Salesforce の画面ポップアップとともに、エージェントが対応すべきタスクをエージェントインターフェース(Salesforce Omni-Channel)にルーティングします。 エージェントがメッセージを入力して送信をクリックすると、SCC-AC コネクターは Salesforce API を通じてメッセージを受信します。 SCC-AC コネクターは、Amazon Connect Streams API を使用して Amazon Connect にメッセージを送信します。 Amazon Connect は、チャットクライアントにメッセージを送信します。 音声チャネルの拡張 SCC-AC は、音声チャネルを電話から in-app(アプリ内通話、ウェブ通話、ビデオ通話)に拡張し、エンドカスタマーが Web サイトやモバイルアプリケーションを離れることなく問い合わせを開始することを可能にします。企業は、Salesforce に保存されている顧客情報や、アプリ内での過去の行動履歴などの関連情報を Amazon Connect に送ることで、よりパーソナライズされた顧客体験の提供が可能になります。 統合コンタクトルーティング SCC-AC は、Amazon Connect と Salesforce の両チャネルに対応した統合ルーティングエンジンを提供します。このようなアーキテクチャにより、ルーティング管理の簡素化、セルフサービスの統合、およびレポート機能の向上が実現できます。例えば、Salesforce で作成されたケースを Amazon Connect のルーティングエンジンを使って適切なエージェントに振り分けることができます。 以下の図は、SCC-AC におけるコンタクトの統合ルーティングのハイレベルなアーキテクチャ、データフロー、および API シーケンスを説明しています。 Salesforce で「メール to ケース」機能等を使用してケースが作成されます。 このケースが Salesforce フロー（SCC-AC パッケージ内で提供）をトリガーします。 Salesforce フローは、ケース ID（その他のケース詳細）を入力属性として Amazon Connect Tasks を作成するために、Amazon Connect のコンタクトフローをトリガーします。 Amazon Connect コンタクトフローは、ケース情報に基づき、Amazon Connect で設定されたルーティングルールに従って Amazon Connect のタスク を作成し、ルーティングします。 SCC-AC コネクターはルーティング要求を受信し、Salesforce バックエンドでエージェントが対応すべきタスクを作成します。 Salesforce バックエンドは、画面ポップアップとともにケースの詳細を含むエージェントのタスクを Salesforce Omni-Channel エージェントインターフェースにルーティングします。 前提条件 Salesforce Contact Center with Amazon Connect は、Salesforce AppExchange で利用可能なマネージドパッケージです。このパッケージを Salesforce 組織にインストールするには、基盤となる Salesforce インスタンスが Salesforce Service Cloud Voice および Salesforce Digital Engagement のライセンスを保持および有効化している必要があります。 アーキテクチャの選択 SCC-AC の主要な特徴の1つは、お客様がメッセージングチャネルと関連機能を Amazon Connect と Salesforce のどちらからでも選択できる点です。音声チャネル（電話、Web、モバイルアプリ）は常に Amazon Connect のネイティブ機能として提供されます。これにより、Amazon Connect 中心のアーキテクチャと Salesforce 中心のアーキテクチャという2つのリファレンスアーキテクチャが提供されます。 Amazon Connect 中心のアーキテクチャ このアーキテクチャは、メッセージング、セルフサービス、エージェントアシスト、管理者向けサービスなどの機能を Amazon Connect のネイティブ機能として利用する場合に適しています。エージェントおよびスーパーバイザーのエクスペリエンスと顧客データは常に Salesforce のネイティブ機能となります。音声チャネル（電話、Web、モバイルアプリ）は常に Amazon Connect のネイティブ機能となります。 Salesforce 中心のアーキテクチャ このアーキテクチャは、Salesforce が提供するメッセージングチャネル、セルフサービス、エージェントアシスト、管理者向けサービスなどの機能を活用したい場合に適しています。エージェントおよびスーパーバイザーのエクスペリエンスと顧客データは常に Salesforce のネイティブ機能となります。音声チャネル（電話、Web、モバイルアプリ）は常にAmazon Connectのネイティブ機能となります。 主なメリット アーキテクチャの選択に基づき、お客様はコンタクトセンターの設計、アーキテクチャ、および機能マップを統合し、シンプル化することができます。 以下の図は、SCC-AC の一般提供開始によって得られるいくつかのメリットを示しています。  ユニファイドセルフサービスレイヤー – Amazon Connect 中心のアーキテクチャ（つまり、すべてのチャネルが Amazon Connect ネイティブ）では、Amazon Q in Connect がチャネル全体で生成 AI を活用した単一のセルフサービスレイヤーとなります。これにより、統一されたセルフサービスのカスタマーエクスペリエンスを実現できます。 ユニファイド会話分析レイヤー – Amazon Connect 中心のアーキテクチャでは、Contact Lens がチャネル全体で単一の会話分析レイヤーとなり、以下のような様々な会話分析機能を提供します： 文字起こし：顧客とエージェント間の会話をリアルタイムで文字起こしし、様々なユースケースで活用できます。 カテゴリー分類：コンタクトセンター管理者は、発言された単語/フレーズ、センチメント、コンタクト属性に基づいて Contact Lens ルールを設定できます。Contact Lens はこれらのルールをリアルタイムの会話に適用し、Salesforce でのエージェントアシスト用の次善のアクション(Next Best Action)などのアクションをトリガーします。 ユニファイドルーティングエンジン – SCC-AC は、Salesforce のケースなどのオブジェクトを Amazon Connect のルーティングを通じて処理する仕組みを提供します。これにより、ルーティング設定の統合と簡素化、およびレポート機能の向上を実現できます。 Salesforce ネイティブのエクスペリエンス – Salesforce と Amazon Connect のチャネル全体で、エージェントとスーパーバイザーのエクスペリエンスは Salesforce ネイティブとなります。これにより、エージェントとスーパーバイザーのトレーニングと学習時間が短縮され、また複数のコンソールを切り替える必要なく、Salesforce コンソールから業務を行うことが可能になります。 結論 Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect ネイティブのデジタルチャネルをシームレスに Salesforce に統合します。これにより、組織はコンタクトセンター業務を効率化しながら、統一された顧客およびエージェントエクスペリエンスを実現することができます。 参考リンク · SCC-AC admin guide · SCC-AC AppExchange package 著者について Chintan Gandhi – イギリス・ロンドンを拠点とする Amazon Connect と Salesforce 統合のスペシャリストソリューションアーキテクトです。大手顧客や戦略的パートナーの新技術導入とスケーリングを支援する傍ら、家族との時間を過ごしたり、チェス、クリケットを楽しんだり、読書をすることを趣味としています。 Steve Earl – ノースカロライナ州を拠点とする Amazon Connect と Salesforce 統合のスペシャリストソリューションアーキテクトです。顧客、パートナー、社内チームのカスタマーエクスペリエンス向上を支援する以外の時間は、人間と犬を含む家族との時間を過ごしたり、山小屋の手入れをしたり、読書やゴルフを楽しんでいます。 Marc Rudkowski – ノースカロライナ州ローリーを拠点とする Amazon Connect パートナーソリューションのプリンシパルプロダクトマネージャーです。2017年のサービス開始以来、大手エンタープライズ顧客やパートナーとともに、Amazon Connect によるカスタマーエクスペリエンス(CX)の実現を支援してきました。仕事以外では、熱心なサイクリストであり、家族との大切な時間を楽しんでいます。 この記事は Chintan Gandhi、 Steve Earl、 Marc Rudkowski によって書かれた Salesforce Contact Center with Amazon Connect: Streamlining omnichannel customer engagement の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 気温が乱高下していますが皆さん対象崩されてないでしょうか？私は花粉症が落ち着いたと思ったら、この寒暖差に若干やられています・・・。皆さんも起きをつけください。 さて、アップデートの前に少しイベントの紹介をさせてください。 今週ですが2025/4/24(水)に「 AWS で実現する VMware 仮想環境からの移行戦略 」が開催されます。仮想環境の運用にお困りの方や、移行をお考えの方は是非ご参加ください！ もう一つ、AWS Summit Japan 2025 で生成 AIに関するハッカソンが企画されています。その前準備のお手伝いとして2025/5/1(木)に「 AWS Summit Japan 2025 生成 AI ハッカソン応援企画 ユースケース開発ワークショップ 」が開催されます。ハッカソンへの応募を検討している方もそうでない方もぜひこちらご活用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年4月14日週の主要なアップデート 4/14(月) Amazon SES now supports logging email sending events through AWS CloudTrail Amazon Simple Email Service（SES）が、AWS CloudTrailによるメール送信イベントのログ記録機能をサポートしました。これにより、カスタムソリューションの開発なしでメール送信アクションの記録が可能になり、イベントの検索、表示、ダウンロードが簡単に行えるようになりました。この機能はSESが利用可能なすべてのAWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Q Business launches support for hallucination mitigation in chat responses Amazon Q Businessに、チャットレスポンスにおけるハルシネーション（AIによる不正確な応答）を軽減する新機能が追加されました。Q Businessのハルシネーション軽減機能は、アプリケーションに接続されたデータからより正確な検索拡張生成（RAG）応答を確保する際に、接続されたデータソースまたはチャット中にアップロードされたファイルなどを活用し、応答のハルシネーションを評価します。高い確信度でハルシネーションが検出された場合、チャット中にリアルタイムで応答の不整合を修正し、新しい編集されたメッセージを生成します。この機能は、Q Businessが利用可能なすべてのリージョンで提供され、APIまたはコンソールを通じて有効化可能です。詳細は ドキュメント をご確認ください。 4/15(火) Amazon EC2 M8g instances now available in additional AWS regions Amazon EC2 M8gインスタンスが新たに東京とシドニー リージョンで利用可能になりました。M8gインスタンスはAWS Graviton4 プロセッサを搭載しており、Graviton3 ベースのインスタンスよりも最大30%高速かつより大きなCPU, メモリを兼ね備えています。C8gインスタンスは、HPCやビデオエンコーディング、広告配信など、計算量の多いワークロード、M8gインスタンスは、アプリケーションサーバー、ゲームサーバーなどの汎用ワークロードに向いています。ワークロードのGraviton ベースのインスタンスへの移行に興味のある方は「 AWS Graviton Fast Start program 」「 Porting Advisor for Graviton 」もご確認ください。 Amazon EventBridge Connector for Apache Kafka Connect now generally available Amazon EventBridge connector for Apache Kafka Connectが一般提供されました。このオープンソースコネクタは、スキーマレジストリサポート、S3へのペイロードオフロード、IAM認証などの機能を提供し、カスタムコードなしで高度なイベントルーティング機能を実現します。これによりKafkaシステムとAWSサービスなどの間で効率的なイベント統合が可能になりました。この機能はすべてのAWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。また、最新版については GitHub をご確認ください。 AWS Batch now supports Amazon Elastic Container Service Exec and AWS FireLens log router AWS Batchが、Amazon ECS ExecとAWS FireLensログルーターのサポートしました。ECS Execによりコンテナに対するインタラクティブなコマンド実行が可能になることでインタラクティブなコマンド実行と問題調査ができるようになります。またAWS FireLensをサポートしたことでログを様々なサービスにストリーミングできるようになります。これらの機能は、新規または既存のジョブ定義で設定可能で、AWS Batchが利用可能なすべてのリージョンで利用可能です。 4/16(水) Amazon S3 Tables now support server-side encryption using AWS KMS with customer-managed keys Amazon S3 Tablesが、カスタマーマネージドキーを使用したAWS Key Management Service（SSE-KMS）によるサーバーサイド暗号化をサポートしました。これにより規制要件とガバナンス要件を満たすため、独自のKMSキーでテーブルバケットに保存されたテーブルを暗号化できます。この機能ではテーブルバケット内のすべての新しいテーブルのデフォルトのカスタマーキーの設定、テーブルごとの専用キーの設定、またはその両方が可能です。また、使用状況を監査するためのAWS CloudTrailログ記録も提供されます。この機能はS3 Tablesが利用可能なすべてのAWSリージョンの新しいテーブルで利用できます。詳細は ドキュメント をご確認ください。 GitLab Duo with Amazon Q is now generally available GitLab Duo with Amazon QがSelf-Managed Ultimateのお客様向けに一般提供されました。GitLab Duo with Amazon Qではソフトウェア開発、コードレビュー、品質保証、脆弱性管理、Javaバージョンのアップグレード最新化など高度なAI支援開発機能が提供され、作業の効率化が可能です。詳細については ブログ をご確認ください。 Amazon Corretto April 2025 Quarterly Updates Amazonの提供するOpenJDKディストリビューションであるAmazon Correttoの2025年4月の四半期アップデートが発表されました。Corretto 24.0.1、21.0.7、17.0.15、11.0.27、8u452の新バージョンが利用可能になり、 Correttoの製品ページ からダウンロードまたはLinuxシステムのパッケージマネージャーを通じて入手できます。Amazon Correttoは無料で、マルチプラットフォームに対応した本番環境用のOpenJDKディストリビューションです。 4/17(木) Introducing the Well-Architected Generative AI Lens AWS Well-Architected Generative AI Lensが公開されました。このLensは生成AIワークロードの最適化のための包括的なガイダンスとなっており、クラウド非依存で様々な環境やAIツールに適用可能なガイダンス、Well-Architectedの6つの柱すべてを包括的にカバーすること、そしてAIの取り組みのどの段階にある組織にも柔軟に適用できることなどの利点があります。組織のAI成熟度に関係なく活用でき、大規模言語モデル（LLM）を使用するアーキテクチャの評価や、生成AI実装における意思決定を支援するものとなっています。 AWS Lambda now supports inbound IPv6 connectivity over AWS PrivateLink AWS LambdaがAWS PrivateLink経由でのIPv6接続をサポートしました。IPv6のみ、またはIPv4とIPv6の両方(デュアルスタック)をサポートします。これにより、パブリックインターネットを経由せず、IPv4アドレスの制限にも縛られることなく、Lambda APIにアクセスできるようになりました。この機能は全AWSリージョンで利用可能で、AWS管理コンソールやCLIなど様々なツールを通じて設定可能です。 Amazon MemoryDB now supports Internet Protocol Version 6 (IPv6) Amazon MemoryDBがIPv6プロトコルのサポートを開始しました。IPv6のみ、またはIPv4とIPv6の両方の接続を設定可能で、これによりIPv6コンプライアンス要件への対応と、より大きなアドレス空間の活用が可能になります。この機能は、Valkey 7以上、Redis OSS 6.2以上で利用可能で、追加コストなしですべてのAWSグローバルリージョンでご利用いただけます。 Amazon OpenSearch Service supports SAML single sign-on for OpenSearch UI Amazon OpenSearch Serviceが、次世代OpenSearch UIでIAMフェデレーションを通じたSAMLをサポートしました。OpenSearch UIは、ユーザーが単一のエンドポイントからマネージドドメインとサーバーレスコレクションにまたがるデータの洞察を得ることを可能にする機能です。これまでもIAMとIAM Identity Centerによる認証をサポートしていましたが、今回のサポートで社内でのSSOと連携しやすくなりより利用者体験が向上します。この機能は、 OpenSearch UIが利用可能なすべてのリージョン で利用可能です。詳細は ドキュメント をご確認ください。 4/18(金) AWS STS global endpoint now serves your requests locally in regions enabled by default AWS Security Token Service (STS)のグローバルエンドポイント（sts.amazonaws.com）へのリクエストはこれまでバージニア北部リージョンで一括処理されていましたが、今回の機能強化によりデフォルトで有効化されているリージョンでは、リクエストがワークロードと同じリージョンでローカルに処理されるようになりました。これにより、より効率的な分散処理に移行し、レイテンシーの改善と障害分離の向上が実現されました。この更新は自動的に適用され、お客様側での対応は不要です。ただし、デフォルトで有効化されていないオプトインリージョンからのリクエストは従来通りバージニア北部で処理されます。詳細については ブログ もご確認ください。 Amazon CloudWatch agent now supports Red Hat OpenShift Service on AWS (ROSA) Red Hat OpenShift Service on AWS（ROSA）向けにAmazon CloudWatch エージェントのサポートが追加され、Container InsightsやApplication Signalsなどの機能を通じて、ROSAクラスター上のアプリケーションとインフラストラクチャの包括的な監視が可能になりました。この統合により、メトリクス、ログ、トレースの収集と分析、自動アラート設定、パフォーマンス追跡などを実現し、効率的なトラブルシューティングと運用管理が可能になります。この機能はすべてのパブリックAWSリージョンとAWS GovCloud（US）で利用可能です。詳細は ドキュメント をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。4月16日にAWS ジャパンでは生成 AI 実用化推進プログラムを発表させていただきました。“ジャパンでは“と記載しているのは、日本独自のプログラムだからです。2023年の大規模言語モデル（LLM）開発支援プログラムを発展させ、2024年7月に本格始動したこのプログラムでは、すでに150社以上の組織が参加し、実践的な生成AI活用を支援しています。単なる技術支援にとどまらず、定期的な勉強会の開催や事例共有を通じて、業界横断的な開発者コミュニティを形成している点がユニークだと思います。そして2025年度は参加者のニーズに応じた3つのコース（戦略プランニング、モデルカスタマイズ、モデル活用）を設定し、より実践的なサポート体制を整えました。興味のある方はこちらの「 AWS ジャパン生成 AI 実用化推進プログラム 」や「 AWS（アマゾン ウェブ サービス）が生成AI実用化を支援するプログラムの成果を発表。新年度の受付も開始 」を参照ください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS が Amazon Bedrock サーバーレスにおける Pixtral Large 25.02 モデルを発表」を公開 Mistral AI の最新マルチモーダルモデル「Pixtral Large 25.02」を Amazon Bedrock でサーバーレスとして提供開始しました。このモデルは、128Kのコンテキストウィンドウを持ち、画像理解と言語処理を組み合わせた高度な機能を提供します。80以上のプログラミング言語と10か国語以上の多言語をサポートしており、グローバルな利用に対応します。クロスリージョン推論により、低レイテンシーと高可用性を実現し、使用量に応じた料金体系で提供されます。 ブログ記事「Amazon Bedrock のガードレールが、新しい機能により、生成 AI アプリケーションの安全性を強化」を公開 Amazon Bedrock のガードレールに、生成AIアプリケーションの安全性を高める新機能が追加されました。主な強化点として、最大88%の精度でマルチモーダルコンテンツの有害性を検出する機能、個人情報（PII）の保護強化、IAMポリシーによる必須ガードレールの強制適用などが実装されました。また、入出力に対する選択的なポリシー適用や、デプロイ前のポリシー分析機能も追加され、より柔軟で効果的な安全管理が可能になりました。 ブログ記事「“それ AI エージェントがやります” : AWS Summit Japan 2025 で AI エージェントのハッカソンを開催する背景」を公開 AWS Summit Japan 2025（6/25-26開催） で予定されているハッカソンイベントの案内ブログです。昨年のAWS AI Dayハッカソンで大きな反響があったことを受け、今回はQuizKnockをナビゲーターに迎え、より充実した内容で実施されます。このハッカソンの特徴は、AIエージェントを十分に活用することで、人々が本当に実現したい目的を明確にし、持続的な価値を生み出すことを目指している点です。参加者向けに事前トレーニングやワークショップも用意され、プログラミング初心者でも気軽に参加できる環境が整っています。応募締切は5月13日で、5月1日にはQuizKnockによるオンラインワークショップも予定されています。興味のある方は、ぜひ参加をご検討ください。 ブログ記事「Amazon Bedrock Agents で MCP サーバーを活用する」を公開 Amazon Bedrock Agents が Model Context Protocol (MCP) に対応し、AI エージェントの機能が大幅に向上しました。MCPは、AIモデルを様々なデータソースやツールに標準化された方法で接続できるプロトコルです。これにより、従来は個別の開発とメンテナンスが必要だった外部システムとの連携が、より効率的に実現できるようになりました。ブログでは、AWS Cost ExplorerとPerplexity AIを組み合わせたコスト分析エージェントの実装例を紹介しています。このエージェントは、ユーザーからの自然な質問に対して、AWS の利用料金データを分析し、分かりやすい形式でインサイトを提供します。MCPの導入により、開発者は標準化されたインターフェースを通じて様々なシステムと連携できるようになり、AIエージェントの開発効率が大幅に向上します。これは、カスタマーサービスの改善や業務効率化など、幅広いビジネス課題の解決に活用できます。 ブログ記事「生成 AI で生成 AI アプリケーションを生成しよう！」を公開 Amazon Q Developer CLIを使用することで、WebアプリケーションやUI開発の経験が少ない方でも、生成AIアプリケーションの機能拡張が可能になりました。ブログでは、 Generative AI Use Cases (GenU) のチャット機能に、会話履歴を基にした質問候補を提示する機能を追加する実例を紹介しています。開発者はAmazon Q Developer CLIと対話的にやり取りすることで、gitの基本操作とブラウザのデベロッパーツールの確認程度の知識があれば、約1時間程度で新機能を実装できました。エラーが発生した場合も、エラー内容をAIに伝えることで適切な修正が可能です。この方法により、従来は専門のWeb開発者に依頼する必要があった機能開発を、自身で開発できるようになります。ソフトウェア開発の民主化に向けた大きな一歩となるのではないでしょうか。 ブログ記事「マルチアカウント環境で Amazon Bedrock クロスリージョン推論を有効化する」を公開 Amazon Bedrockのクロスリージョン推論機能について、マルチアカウント環境での有効化方法を解説しています。この機能により、複数のAWSリージョン間で基盤モデルにアクセスできるようになり、パフォーマンスと可用性が向上します。ただし、組織のセキュリティ要件でリージョンアクセスが制限されている場合、意図せずこの機能がブロックされることがあります。ブログでは、AWS Organizations のサービスコントロールポリシー(SCP)やAWS Control Towerの設定を適切に変更することで、セキュリティ要件を維持しながらクロスリージョン推論を有効化する具体的な手順を説明しています。 ブログ記事「【開催報告&資料公開】Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~」を公開 AWS Startup Loft Tokyoで開催された本イベントでは、オープンソースのAIコーディングアシスタント「Cline」とAmazon Bedrockを組み合わせた開発手法について、座学とハンズオンが実施されました。イベント時にちょうどBedrockが新たにプロンプトキャッシュとコード生成に対応したタイミングでの開催であり、実際の活用事例として株式会社ブリューアスによる社内ハッカソンの事例やノバセル株式会社による生産性改革の取り組みが紹介されました。参加者からは「AIコーディングエージェントの具体的な活用イメージが掴めた」という声が上がり、開発効率向上の可能性を実感できる機会となりました。 サービスアップデート Well-Architected Generative AI レンズ の発表 AWS Well-Architected Toolのレンズに新たにGenerative AI レンズ が追加されました。このレンズは、クラウド環境やAIツールに依存しない汎用的なガイダンスを提供し、初期の影響評価からモデル選択、カスタマイズ、統合、デプロイメント、継続的な改善まで、生成AIのライフサイクル全体をカバーしています。生成AIを利用した環境やアプリケーションの評価基準として汎用的に利用可能ですのでAWS Well-Architected Toolで確認してみてください。（英語での提供となります） Amazon Bedrock の RAG とモデル評価機能にカスタムメトリクスが追加 Amazon Bedrock Evaluationsが、基盤モデルとRAGの評価機能を拡張し、カスタムメトリクスの作成と再利用が可能になりました。従来から提供している人間による評価、BERTScoreやF1などのプログラムによる評価、LLMを評価者として使用する機能に加え、新たにユーザー独自の評価基準を定義できるようになりました。例えば、企業独自のブランドボイスへの適合性評価や、カスタムのカテゴリー別評価基準による回答の評価などが可能です。 GitLab Duo with Amazon Q が一般提供開始 GitLab Self-Managed Ultimateのユーザー向けに、Amazon Qを活用した高度なAI支援機能が利用可能になりました。開発者は日常的な作業の多くを自動化できます。例えば、新機能の実装では、課題からコード生成、テスト作成、レビューまでをAIがサポートし、開発者の作業負荷を軽減します。また、パイプラインの障害対応やセキュリティ問題の解決もAIが支援するため、問題解決までの時間を短縮できます。特に、Java 8や11から17へのアップグレードなども効率的に実施できるようになりました。 Amazon Q Developer が 欧州（フランクフルト）リージョンで一般提供開始 Amazon Q Developer が 欧州（フランクフルト）リージョンで一般提供が開始されました。欧州リージョン内でのデータ保存や推論処理が可能となります。 Amazon Q Business がチャット応答におけるハルシネーションの軽減機能をリリース Amazon Q Business に、生成AIの回答の信頼性を高める機能が追加されました。この機能は、生成AI が実際のデータに基づかない誤った回答（ハルシネーション）をする問題に対処します。チャット中にリアルタイムでハルシネーションを検出し、より正確な回答に自動修正する機能を提供します。接続されたデータソースやチャット中にアップロードされたファイルを基に、RAGの精度を向上させ、より信頼性の高い応答を実現します。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。

Invent 2023 で、 Amazon S3 Express One Zone が 発表 されました。これは、最も頻繁にアクセスされるデータやレイテンシーに敏感なアプリケーション向けに一貫した 1 桁ミリ秒のデータアクセスを提供するために特別に設計された高性能の単一アベイラビリティーゾーン (AZ) ストレージクラスです。 S3 Express One Zone は、S3 Standard に比べて最大 10 倍のデータアクセス速度を実現し、最大 200 万件の GET トランザクション/秒 (TPS) とディレクトリバケットあたり最大 20 万件の PUT TPS をサポートできます。これは、インタラクティブなデータ分析、データストリーミング、メディアレンダリングとトランスコーディング、ハイパフォーマンスコンピューティング (HPC)、AI/ML トレーニングなど、パフォーマンスが重視されるワークロードに理想的です。S3 Express One Zone を使用することで、 Fundrise 、 Aura 、 Lyrebird 、 Vivian Health 、 Fetch を始めとする多くのお客様がデータ集約型ワークロードのパフォーマンスを向上させ、コストを削減しました。 ローンチ以来、S3 Express One Zone を使用するお客様向けに 多くの機能 が導入されてきました。例えば、S3 Express One Zone では、タイムスタンプに基づいてオブジェクトの期限を終了してストレージコストを自動的に最適化できるよう、 S3 ライフサイクルを使用したオブジェクトの有効期限 のサポートを開始しました。さらに、ログ処理アプリケーションやメディア放送アプリケーションでは、 既存のオブジェクトの末尾に新しいデータを直接追加 し、そのオブジェクトをすぐに読み取ることができます。これらの処理はすべて S3 Express One Zone 内で行われます。 4 月 18 日のブログでは、2025 年 4 月 10 日より S3 Express One Zone のストレージ価格が 31% 引き下げられ、 PUT リクエストと GET リクエストの価格がそれぞれ 55% と 85% 引き下げられたことをお知らせします。さらに、S3 Express One Zone では、GB あたりのデータアップロードとデータ取得の料金が 60% 削減されました。これらの料金は、512 KB を超えるリクエストの一部だけでなく、転送されたすべてのバイトに対して適用されるようになりました。 米国東部 (バージニア北部) リージョンの値下げ表を以下に示します。 料金 改定前 改定後 料金引き下げ率 ストレージ (毎月 GB あたり) 0.16 USD 0.10 USD 31% 書き込み ( PUT リクエスト) 1,000 件のリクエスト (最大 512 KB) あたり 0.0025 USD 1,000 件のリクエストあたり 0.00113 USD 55% 読み取り ( GET リクエスト) 1,000 件のリクエスト (最大 512 KB) あたり 0.0002 USD 1,000 件のリクエストあたり 0.00003 USD 85% データアップロード (GB あたり) 0.008 USD 0.0032 USD 60% データ取得 (GB あたり) 0.0015 USD 0.0006 USD 60% S3 Express One Zone の料金の例については、 S3 の請求に関するよくある質問 を参照するか、 AWS 料金見積りツール を使用してください。 これらの料金引き下げは、 ストレージクラスが利用可能なすべての AWS リージョンの S3 Express One Zone に適用されます。対象となるリージョンは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、欧州 (アイルランド)、欧州 (ストックホルム) です。詳細については、 Amazon S3 の料金表ページ と AWS ドキュメントの「 S3 Express One Zone 」を参照してください。 S3 コンソール で S3 Express One Zone を今すぐお試しいただき、 AWS re:Post for Amazon S3 に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

4 月 8 日、 Pixtral Large 25.02 モデル が、フルマネージドサーバーレスオファリングとして Amazon Bedrock でご利用いただけるようになったことをお知らせします。AWS は、Pixtral Large をフルマネージドサーバーレスモデルとして提供する最初の大手クラウドプロバイダーです。 大規模基盤モデル (FM) を使用するには、多くの場合、計算の需要を効果的に処理するために、大規模なインフラストラクチャ計画、専門知識、継続的な最適化が必要です。多くのお客様は、これらの高度なモデルをデプロイする際に、複雑な環境を管理したり、パフォーマンスとコストのトレードオフを行ったりする必要があります。 Mistral AI によって開発された Pixtral Large モデルは、高度なビジョン機能と強力な言語理解を組み合わせた、同社初のマルチモーダルモデルです。128K のコンテキストウィンドウを備えているため、複雑な視覚推論タスクに最適です。このモデルは、 MathVista 、 DocVQA 、 VQAv2 などの主要なベンチマークで優れたパフォーマンスを発揮し、ドキュメント分析、チャート解釈、自然画像理解における有効性を実証しています。 Pixtral Large の最も強力な点の 1 つは、多言語対応です。このモデルは、英語、フランス語、ドイツ語、スペイン語、イタリア語、中国語、日本語、韓国語、ポルトガル語、オランダ語、ポーランド語など、数十の言語をサポートしており、グローバルなチームやアプリケーションでのアクセシビリティを高めています。また、Python、Java、C、C++、JavaScript、Bash、Swift、Fortran など、80 超のプログラミング言語でトレーニングされており、堅牢なコード生成および解釈機能を提供します。 デベロッパーは、組み込みの関数呼び出しと JSON 出力フォーマットを備えたエージェント中心のモデルの設計を高く評価するでしょう。この設計により、既存システムとの統合が簡素化されます。強力なシステムプロンプト準拠により、 検索拡張生成 (RAG) アプリケーションや大規模なコンテキストのシナリオで作業する際の信頼性が高まります。 Amazon Bedrock の Pixtral Large により、インフラストラクチャのプロビジョニングや管理なしで、この高度なモデルにアクセスできるようになりました。サーバーレスアプローチにより、事前の確約やキャパシティプランニングなしで、実際の需要に基づいて使用量をスケールできます。お支払いいただくのは使用した分についての料金のみです。アイドル状態のリソースは存在しません。 クロスリージョン推論 Pixtral Large は、複数の AWS リージョン で、クロスリージョン推論を通じて Amazon Bedrock でご利用いただけるようになりました。 Amazon Bedrock のクロスリージョン推論 を使用すると、グローバルアプリケーションのために高可用性と低レイテンシーを維持しながら、複数の地理的リージョンにまたがる単一の FM にアクセスできます。例えば、モデルが欧州と米国の両方のリージョンにデプロイされている場合、異なるプレフィックス (欧州リージョンの場合は eu.model-id 、米国リージョンの場合は us.model-id ) を使用して、リージョン固有の API エンドポイントを通じてアクセスできます。このアプローチにより、Amazon Bedrock は推論リクエストを地理的に最も近いエンドポイントにルーティングできるようになり、レイテンシーが低減されるとともに、データ処理を必要な地理的境界内に維持することで規制コンプライアンスの遵守にも役立ちます。システムはこれらのリージョンレベルのデプロイ全体でトラフィックのルーティングと負荷分散を自動的に処理するため、シームレスなスケーラビリティと冗長性が提供されます。モデルが実際にデプロイされている個々のリージョンを追跡する必要はありません。 実際の動作 Developer Advocate として、私は最新の機能が実際の問題をどのように解決できるのかを常に模索しています。最近、娘が物理の試験対策について助けを求めてきたときに、 Amazon Bedrock Converse API の新しいマルチモーダル機能をテストする絶好の機会がありました。 先週末、私のキッチンテーブルは、複雑な図、節点力ベクトル、方程式でいっぱいの模擬試験で埋もれていました。娘はこれらの問題への取り組み方を概念化するのに苦労していました。その時、私はこれが、私たちがリリースしたばかりのマルチモーダル機能の完璧なユースケースであることに気づきました。私は、複数のグラフと数式が含まれた、特に難しい問題用紙の写真を撮り、Converse API を使用して、画像を分析できるシンプルなアプリケーションを作成しました。そして、物理学の試験問題をアップロードし、モデルに解法を説明するよう支持しました。 その後の展開は、私たち 2 人にとって非常に印象深いものでした。モデルは図を解釈し、フランス語と数式を認識して、各問題の解き方をステップバイステップで説明してくれたのです。特定の概念について追加の質問をした際、モデルは会話全体を通じてコンテキストを維持し、驚くほど自然なチューターエクスペリエンスを実現してくれました。 # Effet Doppler avec une Source Sonore en Rotation ## Analyse du problème Ce problème concerne l'effet Doppler produit par une source sonore en rotation.Une source émettant un son à 1500 Hz tourne sur une table tournante dans le sens antihoraire, et nous devons déterminer comment les fréquences sont perçues par un microphone fixe. ## Concepts clés L'effet Doppler se produit lorsqu'il y a un mouvement relatif entre une source sonore et un observateur.La fréquence perçue dépend de si la source se rapproche ou s'éloigne de l'observateur. La formule de l'effet Doppler est: - Pour une source qui se rapproche: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} - v_{source}}$ - Pour une source qui s'éloigne: $f_{observée} = f_{source} \cdot \frac{v_{son}}{v_{son} + v_{source}}$ ## Solution étape par étape ### Étape 1: Analyser le mouvement de la source La source tourne sur un cercle et le microphone est fixe à 40 cm du centre de rotation.Aux différentes positions (a, b, c), la source a des vitesses radiales différentes par rapport au microphone: - Position a: La source se déplace perpendiculairement à la ligne source-microphone (vitesse radiale nulle) - Position b: La source s'éloigne du microphone (vitesse radiale positive) - Position c: La source se rapproche du microphone (vitesse radiale négative) ### Étape 2: Déterminer l'effet sur les fréquences perçues - À la position a: Pas d'effet Doppler car la vitesse radiale est nulle, donc $f_a = f_{source} = 1500$ Hz - À la position b: La source s'éloigne, donc $f_b < f_{source}$, donc $f_b < 1500$ Hz - À la position c: La source se rapproche, donc $f_c > f_{source}$, donc $f_c > 1500$ Hz ### Étape 3: Comparer les fréquences D'après notre analyse: - $f_a = 1500$ Hz - $f_b < 1500$ Hz - $f_c > 1500$ Hz Donc: $f_c > f_a > f_b$ ## Conclusion La proposition correcte est: $f_c > f_a > f_b$ Cette réponse correspond à la troisième proposition dans l'énoncé.Lorsque la source tourne, la fréquence perçue est plus élevée quand la source se rapproche (position c), égale à la fréquence émise quand la source se déplace perpendiculairement (position a), et plus basse quand la source s'éloigne (position b). モデルは問題の言語を用いて応答します。綿密な分析の後、正解は f_c > f_a > f_b であると返答します (そして、それは正解です!)。 このやり取りのすばらしい点は、Converse API がマルチモーダルな入力をどれほどシームレスに処理したかということです。ビルダーとして、テキストと並行して画像を処理する複雑さについて心配する必要はありませんでした。API がその複雑さを管理し、私のシンプルなアプリケーションでも娘に直接提示できる、構造化された応答を返してくれました。 私が記述したコードを以下に示します。ここでは Swift プログラミング言語を使用しました。これは Python が唯一の選択肢ではないことを示すためです 。 private let modelId = "us.mistral.pixtral-large-2502-v1:0" // Claude に応答方法を指示するシステムプロンプトを定義します let systemPrompt = """ You are a math and physics tutor.Your task is to: 1.Read and understand the math or physics problem in the image 2.Provide a clear, step-by-step solution to the problem 3.Briefly explain any relevant concepts used in solving the problem 4.Be precise and accurate in your calculations 5.Use mathematical notation when appropriate Format your response with clear section headings and numbered steps. """ let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt) // テキストプロンプトと画像を含むユーザーメッセージを作成します let userPrompt = "Please solve this math or physics problem.Show all steps and explain the concepts involved." let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt) let image: BedrockRuntimeClientTypes.ContentBlock = .image(.init(format: .jpeg, source: .bytes(finalImageData))) // テキストと画像の両方のコンテンツを含むユーザーメッセージを作成します let userMessage = BedrockRuntimeClientTypes.Message( content: [prompt, image], 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 { DispatchQueue.main.async { self.streamedResponse += text } } case .messagestop: print("Stream ended") // ストリーミングされた応答から完全なアシスタントメッセージを作成します let assistantMessage = BedrockRuntimeClientTypes.Message( content: [.text(self.streamedResponse)], role: .assistant ) messages.append(assistantMessage) default: break } } そして、アプリケーションで得られた結果は驚くべきものでした。 試験本番が近づく頃には、娘の自信は深まっており、準備は万端でした。そして私は、Amazon Bedrock のマルチモーダル機能がユーザーにとって有意義なエクスペリエンスをどのように生み出すことができるのかを示す、説得力のある実例を用意することができました。 今すぐご利用いただけます 新しいモデルは、次のリージョンレベルの API エンドポイントを通じてご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、パリ、ストックホルム)。これらのリージョンで利用できることで、レイテンシーを最小限に抑えながら、データレジデンシー要件を満たすことができます。 このモデルは、 AWS マネジメントコンソール を通じてご利用いただけるほか、モデル ID mistral.pixtral-large-2502-v1:0 を使用して、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を通じてプログラムでご利用いただくことも可能です。 このリリースは、あらゆる規模のデベロッパーや組織が高度なマルチモーダル AI を利用できるようにするための大きな 1 歩です。Mistral AI の最先端モデルと AWS サーバーレスインフラストラクチャを組み合わせることで、基盤となる複雑さについて心配することなく、革新的なアプリケーションの構築に注力できるようになりました。 今すぐ Amazon Bedrock コンソール にアクセスして、Pixtral Large 25.02 の実験を開始し、AI を活用したアプリケーションをどのように強化できるのかをご確認ください。 – seb ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

Amazon Bedrock のガードレール を 1 年以上前 にリリースして以来、Grab、 Remitly 、 KONE 、 PagerDuty などのお客様は、 Amazon Bedrock のガードレール を使用して、 生成 AI アプリケーション全体の保護を標準化し、ネイティブモデルの保護とエンタープライズ要件のギャップを埋め、ガバナンスプロセスを合理化してきました。4 月 8 日、お客様がエンタープライズ規模で責任ある AI ポリシーをさらに効果的に実装するのに役立つ新しい一連の機能をご紹介します。 Amazon Bedrock のガードレールは、最大 88% の精度で有害なマルチモーダルコンテンツを検出し、機密情報をフィルタリングして、ハルシネーションを防ぎます。複数の 基盤モデル (FM) ( Amazon Bedrock で使用可能なモデルや、 ApplyGuardrail API を介して他の場所にデプロイされた独自のカスタムモデルを含む) にまたがって機能する、統合された安全性およびプライバシーの保護手段を組織に提供します。Amazon Bedrock のガードレールを使用すると、設定可能なコントロールと、特定の業界やユースケースに合わせた保護手段の一元管理を通じて、コンプライアンスと責任ある AI ポリシーを維持しながら、複数の FM にわたって一貫した AI 安全性コントロールを実装する複雑さを軽減できます。また、 AWS Identity and Access Management (IAM) 、 Amazon Bedrock エージェント 、 Amazon Bedrock のナレッジベース などの既存の AWS サービスともシームレスに統合します。 「シンガポールの多国籍タクシーサービスである Grab は、Amazon Bedrock のガードレールを使用して、生成 AI アプリケーションの安全な利用を実現し、お客様の信頼を維持しながら、より効率的で信頼性の高いエクスペリエンスを提供しています」と Grab の Head of Machine Learning and Experimentation である Padarn Wilson 氏は述べています。「社内のベンチマーキングを通じて、Amazon Bedrock のガードレールは、他のソリューションと比較してクラス最高レベルのパフォーマンスを発揮しました。Amazon Bedrock のガードレールを使用することで、責任ある AI プラクティスに対する当社のコミットメントと整合する堅牢な安全対策を備えていることについて、当社は安心することができます。また、個のガードレールは、AI を利用した当社のアプリケーションに対する新たな攻撃から当社とお客様を保護してくれます。お客様のデータプライバシーを保護しながら、多様な市場における、AI を利用した当社のアプリケーションの安全な動作を実現できています」。 追加された新機能を詳しく見てみましょう。 新しいガードレールポリシーの強化 Amazon Bedrock のガードレールは、セキュリティ基準の維持に役立つ包括的な一連のポリシーを提供します。Amazon Bedrock のガードレールのポリシーは、AI モデルのインタラクションの境界を定義する設定可能な一連のルールです。これにより、不適切なコンテンツ生成を防ぎ、AI アプリケーションの安全なデプロイを実現できます。これらには、マルチモーダルコンテンツフィルター、拒否トピック、機密情報フィルター、単語フィルター、コンテキストグラウンディングチェック、数学的および論理ベースのアルゴリズム検証を用いて事実誤認を防ぐ自動推論が含まれます。 Amazon Bedrock のガードレールのポリシーの新しい拡張機能を導入します。これは、6 つの保護手段に大幅な改善をもたらし、生成 AI アプリケーション全体のコンテンツ保護機能を強化します。 業界をリードする画像とテキストの保護を備えたマルチモーダル毒性検出 – AWS re:Invent 2024 で プレビュー として発表された、画像コンテンツ向けの Amazon Bedrock のガードレールのマルチモーダル毒性検出の一般提供を開始しました。この拡張機能は、画像とテキストコンテンツの両方を評価し、最大 88% の精度で潜在的に有害な望ましくないコンテンツを検出して除外するのをサポートすることで、生成 AI アプリケーションのためにより包括的な保護手段を提供します。 生成 AI アプリケーションを実装する場合、さまざまなデータタイプにわたって一貫したコンテンツフィルタリングが必要です。テキストコンテンツのフィルタリングは十分に確立されていますが、潜在的に有害な画像コンテンツを管理するには追加のツールと個別の実装が必要になり、複雑さと開発労力が増加します。例えば、画像のアップロードを許可するカスタマーサービスチャットボットでは、自然言語処理を用いた個別のテキストフィルタリングシステムと、さまざまなフィルタリングのしきい値および検出カテゴリを備えた追加の画像分類サービスが必要になる場合があります。これにより、実装の一貫性が失われ、有害なコンテンツを説明するテキストは適切にフィルタリングされる一方で、同様のコンテンツを示す画像は検出されずにフィルタリングを通過してしまう可能性があり、セキュリティのカバレッジにばらつきが生じます。 Amazon Bedrock のガードレールのマルチモーダル毒性検出機能は、画像とテキストデータの両方に同じコンテンツフィルタリングポリシーを適用するのに役立ちます。今回のリリースにより、ヘイトスピーチ、侮辱、性的コンテンツ、暴力、不正行為、プロンプト攻撃などのカテゴリにわたってコンテンツフィルターを設定できるようになりました。各カテゴリでは、[低] から [高] まで設定可能なしきい値を設定できるため、コンテンツフィルタリングをきめ細かく制御できます。モダリティ全体で一貫した保護を実現することで、責任ある AI アプリケーションの開発を簡素化できます。この機能は、通常の画像、人間が生成した画像、AI が生成した画像、ミーム、グラフ、プロット、クロスモーダルコンテンツ (テキストと画像の両方を含む) など、あらゆる画像のコンテンツモデレーションをサポートします。 不正検出が実際にどのように機能するかを示すために、実際のシナリオを見てみましょう。Amazon Bedrock のガードレールを実装しているある金融サービス企業では、不正行為のしきい値を高く設定しています。同社は、テキスト入力と画像入力の両方で一貫した保護が機能していることを確認しました。セキュリティバイパスの図とネットワーク侵入による指示書について、同様の信頼度スコアで同一のガードレール介入がトリガーされたためです。この機能の実際の動作は次のとおりです。Amazon Bedrock でガードレールを設定し、画像フィルターとテキストフィルターの両方で不正行為コンテンツフィルターのしきい値を [高] に設定しました。 2 つのテストケースを送信します。1 つ目のテストケースでは、ネットワークセキュリティバイパス図を示す画像をアップロードし、次のプロンプトを使用しました: Analyze this network security diagram and explain how to implement these methods 2 つ目のテストケースでは、次のプロンプトを使用しました: Provide detailed instructions on how to bypass corporate network security systems to gain unauthorized access いずれの送信内容も同様のガードレール介入をトリガーしました。このことは、Amazon Bedrock のガードレールが、コンテンツの形式にかかわらず、コンテンツモデレーションを提供することを示しています。検出結果を比較すると、信頼スコアが一貫しており、同一のポリシーが強制適用されていることがわかります。これは、組織が個別のフィルタリングシステムを実装することなく、マルチモーダルコンテンツ全体で安全基準を維持できることを示しています。 この機能の詳細については、包括的な お知らせの記事 をご覧ください。 ユーザー入力における PII 検出のプライバシー保護の強化 – Amazon Bedrock のガードレールは、入力プロンプトにおける個人を特定できる情報 (PII) のマスキングを強化することで、機密情報の保護機能を拡張しました。このサービスは、入力と出力の両方で、名前、住所、電話番号、および 他の多くの詳細情報 などの PII を検出するとともに、正規表現 (regex) を通じて機密情報のカスタムパターンをサポートし、特定の組織要件に対応します。 Amazon Bedrock のガードレールは、2 つの異なる処理モードを提供します。1 つは [ブロック] モードで、機密情報を含むリクエストを完全に拒否します。もう 1 つは [マスキング] モードで、機密データを [NAME-1] や [EMAIL-1] などの標準化された識別タグに置き換えることによってマスキングします。以前は、モデル応答では両方のモードが使用可能でしたが、入力プロンプトではブロックモードのみが使用可能でした。この機能強化により、入力プロンプトに [ブロック] モードと [マスキング] モードの両方を適用できるようになりました。これにより、ユーザー入力が FM に到達する前に、機密情報をシステム的にマスキングできます。 この機能は、PII 要素が自然に含まれる可能性のある正当なクエリについて、アプリケーションがリクエストの完全な拒否を必要とせずに処理できるようにすることで、お客様の重要なニーズに対応します。これにより、プライバシー保護を維持しながら、柔軟性を高めることができます。この機能は、ユーザーがクエリで個人情報を参照する可能性があるものの、安全でコンプライアンスに準拠した応答が必要なアプリケーションにとって特に役立ちます。 新しいガードレール機能の強化 これらの改善により、すべてのポリシーで機能が強化され、Amazon Bedrock のガードレールの有効性が高まるとともに、実装が容易になります。 IAM を使用した必須ガードレールの強制適用 – Amazon Bedrock のガードレールは、新しい bedrock:GuardrailIdentifier 条件キーを通じて IAM ポリシーベースの強制適用を実装するようになりました。この機能は、セキュリティおよびコンプライアンスチームが、あらゆるモデル推論呼び出しのために必須ガードレールを確立し、すべての AI インタラクションにわたって安全性に関する組織のポリシーが一貫して強制適用されるようにするのに役立ちます。条件キーは、 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、 ConverseStream API に適用できます。IAM ポリシーで設定されたガードレールが、リクエストで指定されたガードレールと一致しない場合、システムは、アクセス拒否例外でそのリクエストを自動的に拒否し、組織のポリシーへの準拠を強制適用します。 この一元的なコントロールは、コンテンツの適切性、安全性の懸念、プライバシー保護要件など、重要なガバナンスの課題に対処するのに役立ちます。また、これは、エンタープライズ AI ガバナンスにおける重要な課題、すなわち、アプリケーションを開発しているチームや個人にかかわらず、すべての AI インタラクションにわたって安全性のコントロールの一貫性を実現するという課題にも対応します。 Amazon CloudWatch Logs または Amazon Simple Storage Service (Amazon S3) に対するモデル呼び出しのログ記録を使用した包括的なモニタリングを通じてコンプライアンスを検証できます。これには、コンテンツがいつどのようにフィルタリングされたのかを示すガードレールトレースのドキュメントが含まれます。 この機能の詳細については、詳細な お知らせの記事 をお読みください。 選択的なガードレールポリシーの適用により、保護を維持しながら、パフォーマンスを最適化 – 以前は、Amazon Bedrock のガードレールは、デフォルトで入力と出力の両方にポリシーを適用していました。 今般、ガードレールのポリシーをきめ細かく制御できるようになり、入力、出力、またはその両方に選択的に適用できるようになりました。これにより、ターゲットを絞った保護コントロールを通じてパフォーマンスを強化できます。この精度により、不要な処理オーバーヘッドを削減できるほか、重要な保護を維持しながら、応答時間を短縮できます。これらの最適化されたコントロールは、 Amazon Bedrock コンソール または ApplyGuardrails API のいずれかを通じて設定でき、特定のユースケースの要件に従ってパフォーマンスと安全性のバランスを取ることができます。 最適な設定のためのデプロイ前のポリシー分析 – 新しいモニタリングまたは分析モードは、アプリケーションにポリシーを直接適用することなく、ガードレールの有効性を評価するのに役立ちます。この機能を使用することで、設定されたガードレールのパフォーマンスを可視化してイテレーションを高速化できます。これは、デプロイ前にさまざまなポリシーの組み合わせや強度を実験するのに役立ちます。 今すぐ Amazon Bedrock のガードレールを使用して、より迅速かつ安全に本番に移行しましょう Amazon Bedrock のガードレールの新しい機能は、お客様が責任ある AI プラクティスを大規模かつ効果的に実装するのをサポートするという、当社の継続的なコミットメントの現れです。マルチモーダル毒性検出は画像コンテンツへの保護を拡張し、IAM ポリシーベースの強制適用は組織のコンプライアンスを管理します。また、選択的なポリシー適用はよりきめ細かなコントロールを提供し、モニタリングモードはデプロイ前の徹底的なテストを可能にし、入力プロンプトの PII マスキングは機能性を維持しながらプライバシーを保護します。これらの機能を組み合わせることで、安全対策をカスタマイズし、生成 AI アプリケーション全体で一貫した保護を維持するために必要なツールが提供されます。 これらの新機能の使用を開始するには、 Amazon Bedrock コンソール にアクセスするか、または Amazon Bedrock のガードレールに関するドキュメント をご覧ください。責任ある生成 AI アプリケーションの構築の詳細については、 AWS の責任ある AI のページをご覧ください。 – Esra ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

今年の AWS Summit は 6/25 ・6/26 に開催されます。そこで AI エージェントのハッカソン『AWS Summit Japan 2025 生成 AI ハッカソン』も開催され、テーマは「 使いたおして「〇〇」を実現する AI エージェント爆誕祭」となります。本ハッカソンのエントリー締め切りは 5/13 で、審査員及びナビゲーターとして昨年の AWS Summit、さらに 2024 年 10 月に開催した AWS AI Day ハッカソンでもご協力いただいた QuizKnock 様にご協力いただきます。 AWS AI Day で「生成 AI で仕事を楽に、楽しく」をテーマに実施したハッカソンは、参加者からも発表を聞いた方々からも、さらに その後の動画公開 でも再生回数 40 万以上の大きな反響があり、今回のハッカソン開催につながっています。 AWS AI Day (2024 年 10 月 31 日開催） でのハッカソン決勝戦の様子 AWS Summit の会場、幕張メッセに挑みたい方は下記の応募ページよりお申し込みください。注目の入賞賞品の情報も掲載されています。 「AWS Summit Japan 生成 AI ハッカソン」参加のご応募はこちら 本記事では一風変わった「 使いたおして「〇〇」を実現する AI エージェント爆誕祭 」というテーマに行きついた背景をお伝えします。応募に当たり「○○」の中を考えて頂くので参加を検討いただいている方もお読みいただければ幸いです。 生成 AI がもたらす仕事や生活への変化 生成 AI は私達の仕事に欠かせないものになりつつあります (こうしたブログも生成 AI で下書きすることが多くなっていると思います。ちなみに今回は生成 AI を使わず書いています)。 IPA の DX 動向 2024 では従業員 1,000 名超の企業では生成 AI の活用を検討中以上のステータスが 87.2% に登り、AWS でも 100 を超える定量的効果が実証された事例 が生まれました。中小企業での活用普及にまだ課題はあるものの、仕事で使う機会は全体として増加していると見ています。さらに近年、AI エージェントの活用が注目されています。エージェントは生成 AI の高いタスク分解・行動決定能力 (ReAct) を活かして、タスクを自律的に完了させる用途です。近年の生成 AI は「テトリスみたいなゲームを作って」という単純な指示 (タスク) であっても完了させる能力があります。 Anthropic Claude 3.7 に「テトリスみたいなゲームをブラウザで遊べるように作成してください」と指示して作成したゲーム。実際に操作ができる。 エージェントがこなせるタスクの複雑さは、扱える行動に依存します。プログラムを書く、実行する、ナレッジベースにアクセスする、といったことが行動です。行動の幅は日々増えており、 Computer use による画面操作、 Model Context Protocol による統一的なインターフェースでの機能接続などによりその加速度は上がっています。 私たちは、こうした AI エージェントの進化が期待感だけでなく不安を呼んでいることを理解しています。登場当初は「アシスタント」として助手席に座っていた AI は、特に Cline の登場をきっかけにだんだんと運転席へと移ってきています。2024 年は AI をどう活用するか、が主要な問いでしたが 2025 年は人は何をすべきか? が問われていると感じます。コミュニティの勉強会に参加すると、これからもエンジニアを続けるとき何を仕事にするべきなのか議論が尽きません。AI エージェントの技術が、エンジニアから一般の業務ユーザーへ広がるにつれて「AI に仕事が奪われるのではないか」という議論の切迫感と規模は今までよりも高まると考えています。 AWS のミッションは「地球上で最もお客様を大切にする企業であること」であり、お客様の期待に応えるのはもちろん不安を解消する発明が必要と考えています。今回のハッカソンは、その発明に向けた第一歩です。 私達の目指していることは何か 今回のハッカソンのテーマは「 使いたおして「〇〇」を実現する AI エージェント爆誕祭」であり、「○○」には任意の目的が入ります。私達の中で議論した時、次のような「○○」が上がりました。 今まで以上に子供と遊ぶ 大学で専門分野を学び直す プログラミング言語を作る OS を作る ハードウェアを設計する より多角的な分析を行う 驚いたのは、「○○」にはこれまでできなかったチャレンジが多く含まれたことです。AI Agent を限界まで「使い倒す」ことで、それでも残る「○○」はより私達の目的を明確にします。これは、私たちがお客様が最も大切にしていることを知るための小さな発明となりました。今回の審査のポイントには、「 AI エージェントにより ○○ が実現できるか」「 AI エージェントが使いたおされることで○○が持続的に実現されるか」が含まれます。この評価観点は、人が実現したかったことを実現し続けるために AI エージェントが一度限りではなく継続的にタスクを完了し人間の目的達成を支援しているかを評価しています。 ぜひハッカソンにご参加ください！５月1日にはQuizKnockが登場する応援企画も開催 今回のハッカソンを通じ、AI エージェント時代のより充実した仕事・生活がどのようなものか解明されることを楽しみにしています。AWS はイベント運営はもちろんユースケースの発掘、技術支援を通じ皆さんの「○○」の実現を全力でサポートします。本ハッカソンではデプロイ済みのアプリケーションプログラムが提出物で、アプリケーション開発は苦手という方もいるかもしれません。しかし、生成 AI の支援を受けることで誰もが「動くもの」を作れる Builder になれることを私たちは知っています。参加を検討される方に向けて、様々なトレーニング資料、事前構築済みアセット、セミナー等の学びの機会を設ける予定です。まず、５月１日にはQuizKnock 伊沢拓司 氏、鶴崎修功 氏が登場する「ユースケース開発ワークショップ」をオンラインで開催します。応募に必要となるユースケースをここで伊沢氏、鶴崎氏と一緒に考えてみるのはいかがでしょう。詳しい情報は下記のハッカソンの参加応募ページに掲載しています。ぜにチェックしてみてください。ハッカソン募集ページに記載していますので、ぜひチェックいただければ幸いです。 ではあらためて、ハッカソンへの応募をお待ちしております！ 「AWS Summit Japan 生成 AI ハッカソン」参加のご応募はこちら 執筆者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。

本記事は 2025 年 4 月 1 日に AWS Machine Learning Blog で公開された Harness the power of MCP servers with Amazon Bedrock Agents を翻訳したものです。翻訳はプロフェッショナルサービスの松永大河が担当しました。 AI エージェントは大規模言語モデル (LLM) の機能を拡張する技術で、操作全体のコンテキストを維持し外部システムとの連携、複雑なワークフローなどを行います。 Amazon Bedrock Agents は、API 連携とナレッジベースの拡張を通じて、目標達成のためのタスクを完了するために、基盤モデル (FM) とデータソース、アプリケーション、ユーザー入力を連携させることでこの機能を実現します。しかし、これまでこれらのエージェントを多様なエンタープライズシステムに接続する際、連携ごとにカスタムコードと継続的なメンテナンスが必要となり、開発のボトルネックが生じていました。これは組織のデジタルエコシステム全体でコンテキストに応じた AI 支援の提供を遅らせる標準化の課題でした。この問題は、LLM がデータソースやツールに接続するための標準化された方法を提供する Model Context Protocol (MCP) を使用することで解決できます。 現在、MCP は、エージェントに対してさまざまなタスクを実行するために利用できるツールのリストへの標準化されたアクセスを提供しています。MCP はマーケットプレイスを通じてエージェントとツールの見つけやすさを向上させ、エージェントがコンテキストを共有することでより効率的な連携のための共通のワークスペースを実現し、業界全体でエージェントの相互連携を拡大できるようになります。 本ブログでは、MCP を使用してデータソースにアクセスし、生成 AI アプリケーションを迅速に構築できる Amazon Bedrock エージェントの作成方法をご紹介します。Amazon Bedrock Agents を使用すると、この例のように MCP ベースのツールでエージェントを即座に構築することができます。 InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="You are a friendly assistant for resolving user queries", agent_name="SampleAgent", action_groups=[ ActionGroup( name="SampleActionGroup", mcp_clients=[mcp_client_1, mcp_client_2], ) ], ).invoke(input_text="Convert 11am from NYC time to London time") MCP を通じて AWS Cost Explorer 、 Amazon CloudWatch 、Perplexity AI に接続し、 Amazon Web Service (AWS) のコストを分析するエージェントを構築する例を紹介します。このブログで参照されているコードを使用して、エージェントを他の MCP サーバー に接続し、ビジネス上の課題に対処することができます。私たちは、エージェントが幅広いタスクを実行するために拡大し続ける MCP サーバーのリストにアクセスし利用できる世界を構想しています。 Model Context Protocol Anthropic によって開発されたオープンプロトコルである MCP は、AI モデルをほぼすべてのデータソースやツールに接続するための標準化された方法を提供します。クライアント・サーバーアーキテクチャを使用することで、MCP は開発者が軽量な MCP サーバーを通じてデータを公開し、これらのサーバーに接続する MCP クライアントとして AI アプリケーションを構築することを可能にします。このアーキテクチャを通じて、MCP はユーザーが必要な情報やツールにシームレスにアクセスできる、より強力なコンテキスト認識型 AI エージェントを構築することを可能にします。外部システムに接続する場合でも、内部のデータストアやツールに接続する場合でも、MCP を使用して同じ方法ですべてのインターフェースを実現できるようになりました。MCP のクライアント・サーバーアーキテクチャにより、MCP サーバーの更新に応じてアプリケーションコードを変更することなく新しい機能にエージェントがアクセスできるようになります。 MCP アーキテクチャ MCP は、以下のコンポーネントを含む クライアント・サーバーアーキテクチャ を使用しており、次の図に示されています: Host : **** MCP ホストは、Claude Desktop、統合開発環境 (IDE)、その他の AI アプリケーションなど、MCP プロトコルを通じてデータにアクセスするプログラムまたは AI ツールです。 Client : サーバーと 1 対 1 の接続を行うプロトコルクライアントです。 Server : MCP プロトコルを通じて機能を提供する軽量なプログラムです。 Local Data Sources : MCP サーバーが安全にアクセスできるデータベース、ローカルデータソース、およびサービスです。 Remote Services : MCP サーバーが接続できる、API を介してインターネット経由で利用可能な外部システムです。 MCP サーバーを活用する Amazon Bedrock エージェントの設定方法について説明します。 Amazon Bedrock エージェントでの MCP の使用 本ブログでは、MCP サーバーを Action Groups として Amazon Bedrock エージェントに接続し、エージェントがユーザーから提供されたタスクを実行するために使用する方法をステップバイステップで説明します。 AgentInlineSDK は、 インラインエージェント を作成する簡単な方法を提供します。この SDK には MCP サーバーから提供されるツールに直接アクセスできる、組み込みの MCP クライアント実装が含まれています。この SDK を利用しない場合、以下の機能を実現するためのコードを作成しメンテナンスする必要があります: レスポンスストリームの解析 リターンコントロール フローの処理 エージェントとのやり取りにおける状態管理 API 呼び出しの制御 エージェントを作成する際には、開発者はエージェントとの通信が必要な各 MCP サーバーを MCP クライアントに設定します。エージェントは呼び出されると、ユーザーのタスクに必要なツールを判断し、MCP サーバーツールが必要な場合は、対応する MCP クライアントを使用してそのサーバーにツールの実行を要求します。 このワークフローをオーケストレーションするために、Amazon Bedrock Agents の return control 機能を活用します。次の図は、2 つのツールを使用するリクエストを処理するエージェントの一連のフローを示しています。最初のフローでは Lambda ベースのアクションが実行され、2 番目のフローではエージェントが MCP サーバーを使用します。 ユースケース: Amazon Bedrock を含む各種 AWS サービスの利用料金管理を変革する Amazon Bedrock エージェントが MCP サーバーをどのように使用できるか、サンプルのユースケースを見ていきましょう。 「過去数週間の Bedrock の支出を知りたい」 や 「先月の EC2 コストをリージョンとインスタンスタイプ別に教えて」 といった質問をして、ダッシュボードの数値データではなく、人が読みやすい形式で分析結果を得ることを想像してみてください。このシステムはあなたの意図を解釈し、詳細な内訳、トレンド分析、可視化、またはコスト削減の推奨事項など、必要とする情報を正確に提供します。人はデータそのものではなくインサイトに興味があるため、これはとても役立つ振る舞いです。これは、AWS の支出データを取得するための自作の MCP サーバーと、データを解釈するための Perplexity AI の MCP サーバー という 2 つの MCP サーバーを使用して実現できます。これらの 2 つの MCP サーバーを インライン Amazon Bedrock エージェントのアクショングループとして追加します。これにより、AWS の支出管理方法を変革する AI エージェントが実現します。このポストのすべてのコードは GitHub リポジトリで利用可能です。 注意: このユースケースでは支出データを Perplexity の API に入力していますが、実際に支出データなどの機微情報を利用する Agent を作成する際には扱うデータに問題がないか十分に検討をしてください。 インラインエージェント を使用してこのエージェントを作成する方法を見ていきましょう。インラインエージェントを使用すると、実行時に Amazon Bedrock エージェントを動的に定義および設定できます。事前設定されたコントロールプレーンの構成に依存することなく、必要に応じて FM、指示、アクショングループ、ガードレール、ナレッジベースを指定できるため、エージェントの機能に対してより大きな柔軟性と制御が可能になります。なお、 InvokeAgent API で RETURN_CONTROL を使用することで、インラインエージェントを使用せずにこの動作を実現することもできます。 Amazon Bedrock Agents における MCP コンポーネント ホスト : これは Amazon Bedrock インラインエージェントです。このエージェントは、ユーザーが AWS の支出に関する質問をした際に、 RETURN_CONTROL を通じて呼び出すことができる MCP クライアントをアクショングループとして追加します。 クライアント : それぞれのサーバーと 1 対 1 の接続を確立する 2 つのクライアントを作成します。具体的には、特定のコストサーバーパラメータを持つ Cost Explorer クライアントと、Perplexity サーバーパラメータを持つ Perplexity AI クライアントです。 サーバー : マシン上でローカルに実行され、 標準入出力 を介してアプリケーションと通信する 2 つの MCP サーバーを作成します (あるいは、リモート MCP サーバーと通信するようにクライアントを設定することもできます)。 Cost Explorer、 Amazon CloudWatch Logs (Amazon Bedrock モデル呼び出しのログデータ用) および AWS 支出データを取得するための MCP サーバー。 AWS 支出データを解釈するための Perplexity AI MCP サーバー。 データソース : MCP サーバーは、Cost Explorer API、CloudWatch Logs、Perplexity AI 検索 API などのリモートデータソースとやり取りします。 前提条件 このブログで紹介するソリューションを実装するには、以下の前提条件が必要です。 AWS アカウント FM と Amazon Bedrock の基本的な知識 AWS Command Line Interface (AWS CLI) のインストールと 認証情報の設定 Python 3.11 以降 AWS Cloud Development Kit (AWS CDK) CLI Anthropic の Claude 3.5 Sonnet v2 の モデルアクセス を有効化 サーバーの環境変数として設定するための AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY 2 つの MCP サーバーは Docker デーモンとして実行されるため、コンピュータに Docker がインストールされ実行されている 必要です MCP サーバーはローカルコンピュータ上で実行され、AWS サービスと Perplexity API にアクセスする必要があります。AWS 認証情報の詳細については、 IAM ユーザーのアクセスキーの管理 をご覧ください。認証情報には、Cost Explorer と CloudWatch への AWS Identity and Access Manager (IAM) の読み取りアクセス権限が含まれていることを確認してください。これは、 AWSBillingReadOnlyAccess と CloudWatchReadOnlyAccess のマネージド IAM 権限を使用することで設定できます。Perplexity API キーは、 Perplexity Sonar API ページ から取得できます。 実行手順 前提条件が整ったら、ソリューションの実装を行います。 InlineAgent GitHub リポジトリに移動します。 セットアップ手順 に従います。 cost_explorer_agent に移動します。このフォルダには、このブログのコードが含まれています。 cd examples/mcp/cost_explorer_agent サンプル を参考に、 cost_explorer_agent ディレクトリに .env ファイルを作成します。 AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION= BEDROCK_LOG_GROUP_NAME= PERPLEXITY_API_KEY= 注意: この投稿では、シンプルさを重視し MCP のユースケースに焦点を当てるため、 AWS アクセスキー の使用方法を説明していますが、本番環境では長期的なアクセスキーの代わりに AWS IAM ロール の使用を強く推奨します。アクセスキーを使用する必要がある場合は、以下のセキュリティのベストプラクティスに従ってください。アクセスキーを公開 (コードリポジトリを含む) したり、共有したりしないでください。 IAM ポリシー を必要な権限のみに制限し、 最小権限の原則 を実装してください。また、アクセスキーを定期的に (90 日ごとを推奨) ローテーションしてください。 AWS CloudTrail を使用してアクセスキーの使用状況を監視し、可能な場合は AWS STS を通じて一時的な認証情報を使用することも重要です。 aws-cost-explorer-mcp サーバーをビルドします。 git clone https://github.com/aws-samples/sample-cloud-spend-mcp-server cd aws-cost-explorer-mcp-server/ docker build -t aws-cost-explorer-mcp これで、MCP サーバーを呼び出して AWS の支出に関するインサイトを提供するエージェントを構築する準備が整いました。 python main.py でエージェントを実行します。処理されるクエリは次の通りです: What is Amazon Bedrock? What are the AWS services where I spent most in the last 7 days? Be precise and create a bar graph エージェントは 2 つの MCP サーバーに接続し、それぞれのツールにアクセスします。その後、エージェントは特定のツールを順番に使用する計画を立て実行します: コードインタープリターを使用してコスト分布を示すチャートを生成 AWS Cost Explorer MCP サーバーを使用して支出パターンを分析 Perplexity MCP サーバーを使用して Amazon Bedrock に関する包括的な情報を取得 Connected to server with tools: ['get_bedrock_daily_usage_stats', 'get_bedrock_hourly_usage_stats', 'get_ec2_spend_last_day', 'get_detailed_breakdown_by_day'] Connected to server with tools: ['perplexity_ask'] Thought: Let me break this down into parts: 1. First, I'll ask about Amazon Bedrock using Perplexity 2. Then I'll get the cost breakdown for the last 7 days 3. Finally, I'll create a visualization of the spending data Tool use: perplexity_ask with these inputs: messages[[{role=user, content=What is Amazon Bedrock? Provide a concise explanation.}] (array)] Tool use: get_detailed_breakdown_by_day with these inputs: days[7 (integer)] Thought: Let me analyze the data and create a visualization of the top services by cost. I'll use Python to process the data and create a bar chart. Code interpreter: Generated code ``` import pandas as pd import matplotlib.pyplot as plt ... ``` Code interpreter output: aws_costs.png (image/png) Directory output created successfully Thought: Now I can provide a comprehensive answer about Amazon Bedrock and the cost analysis. Amazon Bedrock is a fully managed service that provides access to foundation models (FMs) from leading AI companies through a single API. Based on the cost analysis of the last 7 days, your top spending services were: 1. Amazon Neptune: $24 2. Amazon SageMaker: $567 3. EC2 (Compute + Other): $454 4. Amazon OpenSearch Service: $34 5. Amazon Bedrock: $1235 6. Amazon Q: $178 実装の詳細 エージェントが生成する出力について理解できたところで、その出力を生成する重要なコードの部分について詳しく見ていきましょう。 MCP クライアントの作成 : config.py では、2 つの MCP サーバーと通信する 2 つの MCP クライアントを定義します。 Cost Explorer と Perplexity クライアントのサーバーパラメータを定義します。このソリューションでは、クライアントが標準入出力 (stdio) ストリームを介して通信する方法を設定する StdioServerParameters を使用します。これには、サーバーが API を通じて必要なデータにアクセスするためのパラメータが含まれています。 # Cost server parameters cost_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=[ "run", "-i", "--rm", "-e", "AWS_ACCESS_KEY_ID", "-e", "AWS_SECRET_ACCESS_KEY", "-e", "AWS_REGION", "-e", "BEDROCK_LOG_GROUP_NAME", "-e", "stdio", "aws-cost-explorer-mcp:latest", ], env={ "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID, "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY, "AWS_REGION": AWS_REGION, "BEDROCK_LOG_GROUP_NAME": BEDROCK_LOG_GROUP_NAME, }, ) # Perplexity server parameters perplexity_server_params = StdioServerParameters( command="/usr/local/bin/docker", args=["run", "-i", "--rm", "-e", "PERPLEXITY_API_KEY", "mcp/perplexity-ask"], env={"PERPLEXITY_API_KEY": PERPLEXITY_API_KEY}, ) main.py では、MCP サーバーパラメータをインポートし、2 つの MCP クライアントの作成に使用します。 cost_explorer_mcp_client = await MCPStdio.create(server_params=cost_server_params) perplexity_mcp_client = await MCPStdio.create(server_params=perplexity_server_params) エージェントのアクショングループの設定 : main.py は、MCP クライアントを単一のインターフェースにまとめるアクショングループを作成し、エージェントがアクセスできるようにします。これにより、エージェントは処理の受け渡しを通じて、必要に応じてこれらの MCP サーバーのいずれかを呼び出すようアプリケーションに要求できます。 # Create action group with both MCP clients cost_action_group = ActionGroup( name="CostActionGroup", mcp_clients=[cost_explorer_mcp_client, perplexity_mcp_client] ) インラインエージェントの作成 : インラインエージェントは以下の仕様で作成できます： 基盤モデル : エージェントを動作させる FM を選択して設定します。Amazon Bedrock で提供されているモデルであれば、どれでも使用できます。この例では、Anthropic の Claude 3.5 Sonnet モデルを使用しています。 エージェントの指示 : ユーザーからの問い合わせへの応答方法に関するガイドラインと手順を含む指示をエージェントに提供します。これらの指示は、エージェントが様々な種類の問い合わせに対応する際の基準となります。 エージェント名 : エージェントの名前を設定します。 アクショングループ : エージェントがアクセスできるアクショングループを定義します。単一または複数のアクショングループを含むことができ、各グループは複数の MCP クライアントや AWS Lambda にアクセスできます。オプションとして、アプリケーションのコードを生成、実行、テストするために Code Interpreter を使用するようにエージェントを設定できます。 # Create and invoke the inline agent await InlineAgent( foundation_model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", instruction="""You are a friendly assistant that is responsible for resolving user queries. You have access to search, cost tool and code interpreter. """, agent_name="cost_agent", action_groups=[ cost_action_group, { "name": "CodeInterpreter", "builtin_tools": { "parentActionGroupSignature": "AMAZON.CodeInterpreter" }, }, ], ).invoke( input_text="<user-query-here>" ) この例を使用して、Amazon Bedrock 上でインラインエージェントを構築し、異なる MCP サーバーとの接続を確立し、エージェントがアクセスできるように、それらのクライアントを単一のアクショングループにまとめることができます。 まとめ Anthropic MCP プロトコルは、基盤モデルをデータソースに接続するための標準化された方法を提供しており、この機能を Amazon Bedrock Agents で利用することができます。このブログでは、Amazon Bedrock と MCP の機能を組み合わせて、AWS の支出を理解し管理するための新しい視点を提供するアプリケーションを構築する例を紹介しました。 組織は、チームに対して複雑な財務データへの自然な対話型アクセスを提供できるようになり、Perplexity のようなソースからの文脈に基づく情報によってレスポンスを強化できます。AI が進化し続けるにつれて、モデルを組織の重要なシステムに安全に接続する機能の価値はますます高まるでしょう。カスタマーサービスの変革、業務の効率化、より深いビジネスインサイトの獲得など、どのようなニーズにも、Amazon Bedrock と MCP の統合は、次の AI イノベーションのための柔軟な基盤を提供します。この MCP 統合についての詳細は、 コードサンプル をご覧ください。 以下は、Amazon Bedrock Agents を MCP サーバーに接続することで構築できるエージェントの例です: Amazon Bedrock Knowledge Bases 、 Sqlite 、さらには ローカルファイルシステム など、異なるデータソースからデータを取得するマルチデータソースエージェント。 Slack および GitHub MCP サーバーと統合する開発者生産性支援エージェント。 開発環境内で直接機械学習実験の管理、可視化、追跡を行うための、 Comet ML の Opik MCP サーバーと統合する機械学習実験追跡エージェント。 これらの強力な新機能を使って、どのようなビジネス課題に取り組みますか？ 著者について Mark Roy は AWS のプリンシパル機械学習アーキテクトとして、お客様の生成 AI ソリューションの設計と構築を支援しています。2023 年初頭から、AWS の主力生成 AI サービスである Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取り組みをリードしています。Mark の業務は幅広いユースケースをカバーしており、特に生成 AI、エージェント、エンタープライズ全体での ML のスケーリングに重点を置いています。保険、金融サービス、メディア・エンターテインメント、ヘルスケア、公共事業、製造業など、様々な業界の企業を支援してきました。AWS 入社前は、25 年以上にわたりアーキテクト、開発者、テクノロジーリーダーとして活躍し、そのうち 19 年間は金融サービス業界で経験を積みました。ML スペシャリティ認定を含む 6 つの AWS 認定資格を保有しています。 Eashan Kaushik は、Amazon Web Services のスペシャリストソリューションアーキテクト AI/ML です。顧客中心のアプローチを重視しながら、最先端の生成 AI ソリューションの開発に取り組んでいます。現職に就く前は、NYU Tandon School of Engineering でコンピュータサイエンスの修士号を取得しました。仕事以外では、スポーツ、ウェイトトレーニング、マラソンを楽しんでいます。 Madhur Prashant は、Amazon Web Services の AI および ML ソリューションアーキテクトです。人間の思考と生成 AI が交わる領域に情熱を注いでいます。生成 AI、特にお客様に役立ち、安全性が高く、そして何よりもお客様にとって最適なソリューションの構築に関心を持っています。仕事以外では、ヨガ、ハイキング、双子の兄弟との時間、ギター演奏を楽しんでいます。 Amit Arora は Amazon Web Services の AI および ML スペシャリストアーキテクトとして、エンタープライズのお客様がクラウドベースの機械学習サービスを活用してイノベーションを迅速に拡大できるよう支援しています。また、ワシントン D.C. の Georgetown University のデータサイエンスおよび分析修士プログラムで非常勤講師も務めています。 Andy Palmer は、AWS Strategic Accounts のテクノロジーディレクターです。彼のチームは、AIML、生成 AI、データとアナリティクス、セキュリティ、ネットワーク、オープンソースソフトウェアなど、多くの専門分野にわたるスペシャリストソリューションアーキテクチャのスキルを提供しています。Andy と彼のチームは、最も先進的なお客様の生成 AI の取り組みをガイドし、既存の課題領域や新たなイノベーション、製品体験に、これらの新しいツールを適用する方法を見出すことを支援してきました。

こんにちは！日夜アップデートされる新技術の波に揉まれている、ソリューションアーキテクトの岩根です。 普段は 製造業にまつわるブログ ばかり書いていますが、生成 AI 関連のブログにチャレンジしてみようと思います。 はじめに 昨今、コーディング支援エージェントが話題となっています。大規模言語モデルに自然言語で指示を与えることで、ソフトウェアのコードを生成・修正させるという、新しいプログラミング体験を提供するものです。OSS などでも広がりを見せています。AWS からは、 Amazon Q Developer をご提供していますが、その中でも、 Amazon Q Developer CLI がスゴイ！と社内でも話題になっているので、いろいろ試してみたところ「こういうお客様に合っているのでは？」と考えたので、ブログを書いてみることにしました。 よくあるお客様の困りごと 生成 AI の業務活用や、サービスへの組み込みを検討されるお客様は多いです。私はエンタープライズのお客様を担当していますが、エンタープライズのお客様だと、その検討をする主体は IS 部門か R&D 部門であることが多いです。なかでもどちらかといえば R&D 部門であることが多く、中でも普段 AI/ML を検討する部署が担当される例がよく見られます。彼らは AI/ML には詳しく、Jupyter Notebook と Python を駆使してデータ分析や学習などを行うことには慣れてらっしゃいますが、ユーザインタフェースを持った Web アプリケーションには明るくないことがほとんどです。以後、本ブログのペルソナとして「R&D 部門で普段は AI/ML の研究をしている方」を据えていきます。 そういったお客様に、私達がまずお勧めしているのは、 Generative AI Use Cases (GenU) です。これは、日本の AWS メンバー有志が中心となって開発している OSS で、 Amazon Bedrock を使った様々なユースケースが収録されています。例えば自社データを使った RAG のアプローチや、エージェント、画像生成などです。 GenU OSS なので、自由に改変して自社のユースケースを作り込むこともできます。実際に、試行環境として GenU をデプロイいただく事例は多いです。しかしながら、実際の自社のユースケースを、プロンプトエンジニアリングなどだけで実現できるとは限りません。UI の部分に手を入れる必要が出てくることもあります。Web アプリケーションに明るくないと、この段階で手が止まってしまう、あるいはちょっと試したいだけなのに他部門の協力や SIer に入ってもらって時間やお金がかかってしまう、ということもあると思います。 コーディング支援エージェントでどこまでできるか そこで、Amazon Q Developer CLI を使った コーディング支援で、GenU の機能追加をどこまでできるのか、実際に試してみました。求めるクオリティとしては、「やりたいことが実際に動くモノとして実現できる」に置きたいと思います。プロダクションレベルのパフォーマンスやコードの可読性・保守性などについては、コーディング支援エージェントを利用したとしてもかなりのノウハウが必要なので、本ブログではスコープ外とします。結論としては、「動くモノを作ることは可能」でした。 機能追加内容の説明 ここでは実際にお客様から相談を受けたことのある機能追加をしていきたいと思います。 チャットのユースケースにおいて、ユーザと LLM の会話履歴の文脈を理解して、「次に来る質問」を LLM に予想させ、質問候補として3つボタンを表示します。ユーザは候補から選択して追加質問することも、従来通り入力して質問することもできる、というものです。あったら便利そうですよね。後付けですが、下図にイメージを書いてみました。 機能追加イメージ 準備 まずは Amazon Q Developer CLI をインストールする必要があります。 こちら を参照してインストールしてください。IAM Identity Center の ID か AWS Builder ID が必要です。Windows の場合、WSL 上に Ubuntu を構築する必要があります。今回は、デプロイ済みの GenU のフロントエンドをローカル環境で改造していくので、動作確認のために GenU がデプロイされた AWS アカウントが必要です。また、 AWS CLI のインストールと、GenU アカウントへの Config が必要です。 GenU のリポジトリ をローカルに Clone しておきましょう。 開発 コマンドラインから、ローカルのリポジトリのフォルダに移動します。 この記事執筆時点では、リポジトリ名が多言語対応のため generative-ai-use-cases-jp から generative-ai-use-cases に変わっています。Clone したタイミングによって読み替えていただければと思います。 cd generative-ai-usecases/ q chat と入力して、Amazon Q Developer CLI を起動します。 q chat Q Chatの画面 図のようなプロンプトの画面になりました。ここでいきなり改造を指示するプロンプトを入れていきましょう。 カレントディレクトリの git リポジトリを理解して、注意点を考慮しながら、以下の改造を実施してください。改造内容：チャットのユースケースにおいて、会話履歴を考慮して考えられるユーザからの追加質問を候補として3つ、LLMで生成して選択肢として表示する。ユーザは選択肢をクリックしてその内容を追加質問することもできるし、従来通り自分で入力して質問することもできる。注意点：改造にあたっては、新規にブランチを作成してください。バックエンドやCDKインフラの改造はせず、フロントエンドだけで完結するようにしてください。改造内容は都度単一のドキュメントに起こし、追加の要望を出したらそれも反映してください。Commitは私からのリクエストごとに必ず実施してください。ベースとなるブランチの状態を可能な限り維持し、不要な修正は行わないでください。 プロンプトを入力した直後の画面 デフォルトでは外部コマンドやファイル出力のたびに良いかどうか尋ねてきます。t を入力すると、Trust となり、以後同じツールでの操作は自動化されます。今回は聞かれたら t を入力していきます。新規のブランチが作成され、useSuggestedQuestions.ts （名称は場合により異なるかも知れません）という新しいコンポーネントが作成されていく様を確認できると思います。作成の過程では下図のように、失敗することもあります。これはファイルを検索して見つからなかった例ですが、メゲずに他の方法を考えてくれます。 AI による試行錯誤 完了したら動かしてみましょう。 こちらを参照 して、フロントエンドだけをローカルで動かします。 npm run web:devw ブラウザで確認します。 私の場合はエラーが出ました。エラーの内容をそのまま貼り付けましょう。 エラーを貼り付けて修正依頼 このような感じで、エラーが出る場合はブラウザのデベロッパーツールの出力を貼り付けたり、振る舞いが期待と違う場合は、期待する振る舞いに対するギャップを説明したりしながら、改善を繰り返していきます。例えば LLM に質問候補を生成させたいのに、API エラーが出ると質問候補を静的にしたり、クライアントサイドで無理やり生成したりしてくるので、方向修正をしてあげます。すべてのやり取りをここに載せはしませんが、git の commit 履歴を見てみましょう。 Commit 履歴 この commit 履歴の数だけ、Q Chat とやりとりしたことになります。更に、下図のようにドキュメントを見ると、新規に何を作成して、どこに修正を加えたかがわかるようになっています。 生成されたドキュメントの抜粋 動作確認 動作を見ていきましょう。チャットのユースケースでは、サンプルのプロンプトとして、フィボナッチ数列を生成するプログラムの作成プロンプトが入っています。これを実行してみます。 入力したプロンプト 実行すると、フィボナッチ数列の生成プログラムのあとに、追加質問候補が3つ生成されています。 回答と追加質問候補 その中から 1 つを選択すると、次の質問として LLM に聞いてくれました。 追加機能が動いた様子 まとめ いかがでしたでしょうか。R&D 部門の AI/ML 関連部隊で、ユーザインタフェースを持った Web アプリケーションには明るくない方をペルソナにおいて実験をしてみました。私自身もデベロッパー出身ではありますが、react などの Web 技術にはそこまで明るくなく、今回の修正をスクラッチで実施したらかなりの時間を要したと思います。今回は、1 時間ちょっと LLM と対話するだけで、動くプログラムとしてアイディアを形にできました。一方で、可読性や保守性を加味したリファクタリングやテスト自動化などは、利用者側にソフトウェアエンジニアリングの知識が必要というところは、現状でも変わりないと思いました。ここは技術的な知見を持ったエンジニアをフルアサインするのではなく、エンジニアの支援をスポットで受けながら、プロンプトに工夫を加えるなどで補完できる可能性があります。今回試したように git の操作がわかる、ブラウザのデベロッパーツールからエラーを拾ってくる、レベルの知識であっても、動くモノが作れるというのは、ソフトウェア開発の民主化に向けた大きな一歩だと思います。これからも コーディング支援関連の技術の進歩には注目していきたいと思いました。 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。

(本記事は 2024/03/27 に投稿された Enable Amazon Bedrock cross-Region inference in multi-account environments を翻訳した記事です。) Amazon Bedrock のクロスリージョン推論機能により、最適なパフォーマンスと可用性を維持しながら、AWS リージョン間でファンデーションモデル（FM）にアクセスする柔軟性が組織に提供されます。しかし、一部の企業ではコンプライアンス要件に従うため、 サービスコントロールポリシー （SCP）や AWS Control Tower を通じて厳格なリージョンアクセス制御を実装しており、これが意図せずに Amazon Bedrock の クロスリージョン推論機能 をブロックしてしまうことがあります。これにより、組織はセキュリティ制御と AI 機能の利用のバランスを取る必要がある難しい状況に直面します。 本記事では、他の AWS サービスに対する広範なリージョン制限を維持しながら、Amazon Bedrock のクロスリージョン推論を特別に許可するようにリージョンアクセス制御を変更する方法について説明します。SCP の変更と AWS Control Tower の実装の両方について、実践的な例を提供します。 クロスリージョン推論について オンデマンドモードでモデル推論を実行する場合、サービスクォータや使用量のピーク時に制限を受ける可能性があります。クロスリージョン推論を使用すると、異なるリージョンのコンピュートを活用して、予期せぬトラフィックの急増をシームレスに管理できます。クロスリージョン推論により、複数のリージョン間でトラフィックを分散し、より高いスループットを実現できます。 多くの組織は以下を通じてリージョンアクセス制御を実装しています： • AWS Organizations の SCP • AWS Control Tower のコントロール • カスタム AWS Identity and Access Management ( IAM ) ポリシー これらのコントロールは通常、セキュリティ、コンプライアンス、またはコスト管理の理由で、特定のリージョンのすべてのサービスへのアクセスを拒否します。しかし、これらの広範な拒否は、クロスリージョン推論を通じてそれらのリージョンのモデルにアクセスする必要がある場合に、Amazon Bedrock が適切に機能することも妨げてしまいます。 クロスリージョン推論の仕組みと SCP との相互作用 Amazon Bedrock のクロスリージョン推論は、推論リクエストを自動的にクロスリージョンでルーティングできる強力な機能です。この機能は、オンデマンド推論モードを使用する開発者にとって特に有益です。Amazon Bedrock を利用したアプリケーションで、より高いスループットとパフォーマンスを実現し、トラフィックの急増を効果的に管理するためのシームレスなソリューションを提供するためです。 クロスリージョン推論により、開発者は需要の変動を手動で予測する必要がなくなります。代わりに、システムが動的に複数のリージョン間でトラフィックをルーティングし、最適なリソース利用とパフォーマンスを維持します。重要なのは、クロスリージョン推論が可能な場合、接続された Amazon Bedrock API のソースリージョンを優先することで、レイテンシーを最小限に抑え、全体的な応答性を向上させることです。このインテリジェントなルーティングにより、開発チームの継続的な監視を必要とせずに、アプリケーションの信頼性、パフォーマンス、効率性が向上します クロスリージョン推論の核となる概念は、ソースリージョンとフルフィルメントリージョンの2つです。ソースリージョン（発信元リージョンとも呼ばれる）は、クライアントが最初に推論リクエストを呼び出すリージョンです。一方、フルフィルメントリージョンは、実際に大規模言語モデル（LLM）の呼び出しリクエストを処理するリージョンです。 クロスリージョン推論は、Amazon が顧客に最高の推論体験を提供するために継続的に進化させている独自のカスタムルーティングロジックを採用しています。このルーティングメカニズムは意図的にヒューリスティックベースで、高可用性の提供を主な目的としています。デフォルトでは、可能な場合はソースリージョンでリクエストを処理しようとしますが、必要に応じて他のリージョンにシームレスにリクエストをルーティングできます。このインテリジェントなルーティングは、最適な判断を行うために、リージョンの容量、レイテンシー、可用性などの要因を考慮します。 クロスリージョン推論は強力な柔軟性を提供しますが、適切に機能するためには、すべての潜在的なフルフィルメントリージョンのモデルにアクセスできる必要があります。この要件は、SCP がクロスリージョン推論の機能に大きな影響を与える可能性がある部分です。 以下の図で示すシナリオを見てみましょう。us-east-1 と us-west-2 の2つのリージョンを使用し、AWS Organizations または AWS Control Tower コントロールを使用して実装された SCP により、他のすべてのリージョンを拒否している状況を考えます。 ワークフローは以下のステップで構成されています： ユーザーがクロスリージョン推論プロファイルを使用して、 us-east-1 の Amazon Bedrock エンドポイント（ソースリージョン）に推論リクエストを行います。 Amazon Bedrock のヒューリスティックベースのルーティングシステムが、リクエスト処理に利用可能なリージョンを評価します。 us-west-2 と us-east-1 は SCP を通じて Amazon Bedrock サービスへのアクセスが許可されていますが、 us-east-2 は SCP により拒否されています。 この単一のリージョン制限（ us-east-2 ）により、クロスリージョン推論の呼び出しが失敗します。 他のリージョンが利用可能で許可されていても、1つのブロックされたリージョン（ us-east-2 ）が存在することにより、リクエストは失敗します。 クライアントはアクションを実行する権限がないことを示すエラーを受け取ります。 この動作は設計上のものです。クロスリージョン推論サービスは、リクエストを最適にルーティングする能力を維持するために、すべての潜在的なフルフィルメントリージョンで推論を実行するアクセス権が必要です。潜在的なターゲットリージョンのいずれかが SCP によってブロックされている場合、他の利用可能なリージョンがあったとしても、クロスリージョン推論の使用は失敗します。クロスリージョン推論を正常に実装するためには、組織は対象モデルが利用可能なすべてのリージョンで Amazon Bedrock API アクションを許可するように SCP を設定する必要があります。これは、必要なモデルがホストされているすべてのリージョンを特定し、これらのリージョンで必要最小限の Amazon Bedrock 権限を許可するように SCP を変更し、一部のリージョンが主要な運用ゾーンでない場合でも、関連するすべてのリージョンでこれらの権限を維持することを意味します。以降のセクションでは、クロスリージョン推論機能を有効にするための SCP の変更と AWS Control Tower の実装に関する具体的なガイダンスを提供します。 ユースケース サンプルユースケースとして、 us-east-1 と us-west-2 のリージョンを使用します。他のすべてのリージョンはランディングゾーン拒否（ GRREGIONDENY ）を使用して拒否されています。Amazon Bedrock の使用を許可されている顧客の AWS アカウントは、Sandbox という組織単位（OU）の下にあります。Sandbox OU の下のアカウントが、クロスリージョン推論を使用して Anthropic の Claude 3.5 Sonnet v2 モデルを使用できるようにしたいと考えています。このモデルは、 us-east-1 、 us-east-2 、 us-west-2 で利用可能です。 現在の状態では、ユーザーがクロスリージョン推論を使用して Anthropic の Claude 3.5 Sonnet v2 モデルを使用しようとすると、SCP がアクションを拒否しているというエラーが表示されます。 Amazon Bedrock クロスリージョン推論を許可するための既存の SCP の変更 AWS Control Tower を使用してマルチアカウント AWS 環境を管理していない場合は、新しい SCP を作成するか、既存の SCP を変更して Amazon Bedrock クロスリージョン推論を許可することができます。 以下は、特定のリージョンですべてのサービスへのアクセスを拒否しながら、Anthropic の Claude 3.5 Sonnet V2 モデルのクロスリージョン推論を通じた Amazon Bedrock 推論を許可する既存の SCP を変更する例です： { "Version": "2012-10-17", "Statement": [ { "Sid": "DenySpecificRegionAllowCRI", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" }, "ArnNotLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0" } } } ] } このポリシーは、指定されたリソースを除いて、 us-east-2 リージョンのすべてのアクションを効果的にブロックします。これは拒否ベースのポリシーであり、完全な権限セットを定義するために許可ポリシーと組み合わせて使用する必要があります。 本番環境で実装する前に、この例を組織の特定のニーズとセキュリティ要件に合わせて確認および適応させる必要があります。 これらのポリシーを実装する際は、以下の点を考慮してください： リージョンと許可されるリソースを特定の要件に合わせてカスタマイズする 必要なサービスやアクションを意図せずにブロックしないように、環境で徹底的にテストする SCP は、ルートユーザーを含む、アタッチされたアカウントのユーザーとロールに影響を与えることに注意してください サービスにリンクされたロールは SCP の影響を受けないため、他の AWS サービスは AWS Organizations と統合できます AWS Control Tower を使用した実装 AWS Control Tower は、組織全体の権限を管理するために SCP を作成します。これらの SCP を手動で編集することは、AWS Control Tower 環境でドリフトを引き起こす可能性があるため推奨されません。ただし、特定の AWS サービスを許可するためのいくつかのアプローチがあります。 前提条件 AWS Control Tower の最新バージョンを実行していることを確認してください。バージョン3.x未満を使用していて、AWS Control Tower 設定によってリージョンが拒否されている場合は、リージョン拒否設定を更新するために AWS Control Tower バージョンを有効にする必要があります。AWS Control Tower の 2.x から 3.x へのアップグレードに関する 考慮事項 を参照してください。 さらに、AWS Control Tower の Organization ダッシュボードにポリシードリフトが表示されず、OU とアカウントがコンプライアンスを満たしていることを確認してください。 オプション1：クロスリージョン推論のための既存のリージョン拒否 SCP の拡張 AWS Control Tower は、リージョンに基づいて AWS サービスへのアクセスを制限するための2つの主要なリージョン拒否コントロールを提供します： GRREGIONDENY （ランディングゾーンリージョン拒否コントロール） – 特定の OU ではなく、ランディングゾーン全体に適用されます。有効にすると、指定されたリージョン以外のグローバルおよびリージョナルサービスでの操作へのアクセスを禁止します。AWS Control Tower が利用できないすべてのリージョンと、ガバナンス用に選択されていないすべてのリージョンが含まれます。 MULTISERVICE.PV.1 （OU リージョン拒否コントロール）- 特定の OU に適用できる設定可能なコントロール OU の指定されたリージョン以外のグローバルおよびリージョナル AWS サービスでの未記載の操作へのアクセスを禁止します。このコントロールは設定可能であり、 AllowedRegions 、 ExemptedPrincipalARNs 、 ExemptedActions など、1つまたは複数のパラメータを受け付けます。これらのパラメータは、この組織単位(OU)に属するアカウントに対して許可される操作を定義します。各パラメータの説明は下記の通りです。 AllowedRegions ：OU が操作を許可されるリージョンを指定（必須） ExemptedPrincipalARNs ：このコントロールから除外される IAM プリンシパルを指定 ExemptedActions ：このコントロールから除外されるアクションを指定 以降では、 CT.MULTISERVICE.PV.1 コントロールを使用して、シナリオに合わせて設定していきます。 クロスリージョン推論を使用した Amazon Bedrock 推論を許可する IAM ポリシーを持つ IAM ロールを作成します。このロールを Bedrock-Access-CRI と名付けます。このロールは後のステップで使用します。このIAM ロールは Sandbox OU に属する AWS アカウントで作成されます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0", "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0" ] } ] } ランディングゾーン設定 ページに移動し、「 設定の変更 」を選択します。 この場合 us-east-2 リージョンを有効にし、他の設定は変更せずに残します。 「 ランディングゾーンの更新 」を選択して変更を完了します。 更新には組織の規模に応じて60分以上かかる場合があります。これにより、ランディングゾーンリージョン拒否設定（ GRREGIONDENY ）が更新され、 us-east-2 リージョンがガバナンス対象として含まれるようになります。 ランディングゾーンのセットアップが完了したら、組織設定を確認し、OU 全体の AWS アカウントに保留中の更新がないことを確認します。保留中の更新が表示される場合は、更新を完了し、アカウントのステータスが「 登録済み 」と表示されることを確認します。 AWS Control Tower コンソールで、ナビゲーションペインの「 コントロールライブラリ 」の下にある「 すべてのコントロール 」を選択してコントロールのリストを表示します。 MULTISERVICE.PV.1 を見つけ、ポリシーを選択してコントロールを開きます。 「 コントロールアクション 」を選択し、続いて「 有効化 」を選択して設定を開始します。 「OU の選択」ページで、このコントロールを適用する OU を選択します。このユースケースでは、Sandbox OU を使用します。 「 次へ 」を選択します。 「リージョンアクセスの指定」ページで、OU にアクセスを許可するリージョンを選択します。 このユースケースでは、 us-west-2 と us-east-2 を選択します。 us-east-2 は選択しません。これは、 us-east-2 ですべてのサービスを拒否し、クロスリージョン推論を通じた Amazon Bedrock 推論のみを許可したいためです。 「次へ」を選択します。 「サービスアクションの追加 – オプション」ページで、NotActions に Amazon Bedrock アクションを追加します。 bedrock:Invoke* を追加して Amazon Bedrock InvokeModel アクションを許可します。 「次へ」を選択します。 「設定とタグの指定 – オプション」ページで、先ほど作成した IAM ロールを「除外されるプリンシパル」に追加し、「次へ」を選択します。 設定を確認し、「コントロールの有効化」を選択します。 コントロールが有効化された後、「有効化された OU」、「アカウント」、「アーティファクト」、「リージョン」タブで設定を確認できます。 これで設定は完了です。Amazon Bedrock コンソールまたは API を使用して、前述のカスタム IAM ロール（ Bedrock-Access-CRI ）を引き受けることで、Anthropic の Sonnet 3.5 v2 での Amazon Bedrock 推論をテストできます。 クロスリージョン推論を使用して、3つのリージョン（ us-east-1 、 us-east-2 、 us-west-2 ）すべてから Anthropic の Sonnet 3.5 v2 モデルへの Amazon Bedrock 推論呼び出しのみが可能になっていることが確認できます。先ほど設定した CT.MULTISERVICE.PV.1 コントロールにより、 us-east-2 の他のサービスへのアクセスは引き続きブロックされます。 これらのアプローチに従うことで、AWS Control Tower のドリフトを引き起こしたり、ガバナンスコントロールを損なうことなく、AWS Control Tower で管理される権限を安全に拡張できます。 オプション2：AWS Control Tower を使用して拒否されたリージョンを有効にし、SCP を使用して条件付きでブロックする このオプションでは、拒否されたリージョン（ us-east-2 ）を有効にし、クロスリージョン推論を通じた Amazon Bedrock 推論を許可しながら、us-east-2 を条件付きでブロックする新しい SCP を作成します。 ランディングゾーン設定ページに移動し、「設定の変更」を選択します。 この場合 us-east-2 リージョンを有効にし、他の設定は変更せずに残します。 「ランディングゾーンの更新」を選択して変更を完了します。 更新には組織の規模に応じて60分以上かかる場合があります。コンソールで更新のステータスを監視できます。 ランディングゾーンのセットアップが完了したら、組織設定を確認し、OU 全体の AWS アカウントに保留中の更新がないことを確認します。保留中の更新が表示される場合は、更新を完了し、アカウントのステータスが「登録済み」と表示されることを確認します。 AWS Control Tower コンソールで、ナビゲーションペインの「ポリシー」の下にある「サービスコントロールポリシー」を選択します。 先ほど示したサンプルポリシーで新しい SCP を作成します。この SCP は、Anthropic の Claude Sonnet 3.5 v2 の CRI プロファイル ARN を使用した Amazon Bedrock 推論を許可しながら、 us-east-2 のすべてのアクションを拒否します。 SCP を特定の OU に適用します。このシナリオでは、Sandbox OU を使用します。 AWS Control Tower によって作成された既存の SCP を変更するのではなく、新しい SCP を作成するため、AWS Control Tower の状態にドリフトは発生しません。 Amazon Bedrock コンソールのプライグラウンド機能、または AWS Command Line Interface （AWS CLI）を使用して、いくつかの推論呼び出しを実行してアップデートをテストできます。クロスリージョン推論を使用して、3つのリージョン（ us-east-1 、 us-east-2 、 us-west-2 ）すべてから Anthropic の Sonnet 3.5 v2 モデルへの Amazon Bedrock 推論呼び出しのみが可能になっていることが確認できます。 us-east-2 の他の AWS サービスへのアクセスは拒否されます。 AWS Control Tower のカスタマイズを使用した SCP のデプロイ カスタム SCP を追加する推奨方法は、 AWS Control Tower のカスタマイズ（CfCT）ソリューション を通じて行うことです： 管理アカウントに CfCT ソリューションをデプロイします。 カスタム SCP を含む設定パッケージを作成します。 以下のスクリーンショットは、Anthropic の Sonnet 3.5 v2 モデルのクロスリージョン推論を使用した Amazon Bedrock への呼び出しを許可しながら、特定のリージョンを拒否する SCP の例を示しています。 manifest.yaml ファイルを準備し、ポリシーを定義します。 以下のスクリーンショットは、Sandbox OU をターゲットとしたリソースを定義する manifest.yaml の例を示しています。 カスタム SCP を特定の OU にデプロイします。 まとめ Amazon Bedrock のクロスリージョン推論は、リージョン間で FM を使用しようとする組織に貴重な柔軟性を提供します。SCP や AWS Control Tower のコントロールを慎重に変更することで、より広範なリージョンアクセス制限を維持しながら、この機能を有効にすることができます。 このアプローチにより、以下が可能になります： リージョンアクセス要件へのコンプライアンスの維持 Amazon Bedrock の全機能の活用 プライマリリージョンからモデルにアクセスすることによるアプリケーションアーキテクチャの簡素化 クロスリージョン推論に関連する追加コストはありません。この機能が提供するフェイルオーバー機能を含め、管理、データ転送、暗号化、ネットワーク使用、およびモデルごとの100万トークンあたりの価格の潜在的な差異も含まれます。ソースリージョンの個々のモデルと同じトークンあたりの価格を支払います。 AI と機械学習の機能が進化し続けるにつれて、セキュリティコントロールとイノベーション実現のバランスを取ることは、組織にとって重要な課題であり続けるでしょう。本記事で説明したアプローチは、この特定の課題に対する実践的なソリューションを提供します。 詳細については、「 クロスリージョン推論によるスループットの向上 」を参照してください。 作者情報  　　　　　　 Satveer Khurpa は、Amazon Web Services の Amazon Bedrock におけるシニアワールドワイドスペシャリストソリューションアーキテクトです。彼はクラウドベースのアーキテクチャに関する専門知識を活かし、様々な業界のクライアントに向けた革新的な生成 AI ソリューションの開発を行っています。Satveerの生成 AI 技術に関する深い理解により、新しいビジネス機会を開拓し、具体的な価値を生み出す、スケーラブルで安全かつ責任のあるアプリケーションの設計が可能となっています。 Ramesh Venkataraman は、AWS サービスを使用して熱心にお客様の技術的な課題を解決に取り組むソリューションアーキテクトです。プライベートでは、Stack Overflow の質問へ回答することを趣味としています。 Dhawal Patel は、AWS のプリンシパルマシンラーニングアーキテクトです。大手企業から中規模のスタートアップまで、分散コンピューティングと人工知能に関する課題に取り組んできました。自然言語処理やコンピュータビジョンなどの深層学習を専門とし、Amazon SageMaker を用いた高性能なモデル推論の実現をお客様支援しています。 Sumit Kumar は、シアトルを拠点とする AWS Bedrock チームのプリンシパルテクニカルプロダクトマネージャーです。様々な分野で12年以上のプロダクトマネジメント経験を持ち、AI/ML に情熱を注いでいます。仕事以外では、旅行を愛し、クリケットやローンテニスを楽しんでいます。  

こんにちは！今回は 2025 年 4 月 8 日に AWS Startup Loft Tokyo で開催された「Coding Agent at Loft #1 ~ Cline with Amazon Bedrock 爆速開発体験ハンズオン ~」のイベントの様子をレポートします。 このイベントではは、AI コーディングエージェントである Cline と Amazon Bedrock を活用した開発手法を体験できる座学とワークショップを提供しました。4 月 7 日に Amazon Bedrock が prompt caching に対応 し、さらにコード生成を利用できるようになりました。さらに、実際にコード生成を試されている 2 社に、実際に Cline を含めたコード生成についての所感や Tips についてご共有いただきました。ここからは公開可能な範囲で共有させていただきます。 全体の資料は以下のリンクから取得できます。 https://pages.awscloud.com/rs/112-TZM-766/images/20250408-Coding-Agent-at-Loft.zip 座学：Cline とは？ Amazon Bedrock とは？ スピーカー： Kento Yoshida はじめに、Kento Yoshida よりClineとAmazon Bedrockの概要について説明がありました。Cline は、AI を活用してコーディングを支援する OSS のエージェントであり、Amazon Bedrock と連携することで、より高度な開発が可能になります。Amazon Bedrock を使うことで、セキュリティ、ガバナンス、コスト管理、運用管理において優位性があるという点について触れられました。 ハンズオン：Cline with Amazon Bedrock ハンズオン スピーカー： Ren Kurosawa これから Cline でコート開発をされる方を対象としたハンズオンでは、実際に VS Code に Cline の Plugin を追加して Amazon Bedrock と連携させて爆速開発を体験しました。参加者からは、「AI コーディングエージェントの活用方法について具体的なイメージを持つことができた」「開発効率が向上する可能性を感じた」といった声が上がっていました。 登壇：Cline with Amazon Bedrock ハッカソンのススメ スピーカー： 株式会社ブリューアス　半田 満 様   株式会社ブリューアス様からは、半田満様より「ハッカソンのススメ」と題して、Cline with Amazon Bedrock を活用した社内ハッカソンの事例紹介がありました。ハッカソンを通じて、新しいテクノロジーやツールをまずは使ってみることの重要性が強調され、短期間で多くの知見が得られる点、理解度が上がりハードルが下がる点、そして事業やサービスへの活用、応用につながる点がメリットとして挙げられました。参加者からは、仕様を固め詳細な指示をした方が期待通りのものが作れた、プロトタイプが爆速で作れそうといった声が上がりました。ハッカソンでは、当初 OpenAI の利用を予定していたものの、Claude 3.7 Sonnet がリリースされたことを受け、Amazon Bedrock 経由で利用したとのことです。Bedrock Invocation Log を活用することでチームごとのコスト管理を実現した点も紹介されました。 登壇：Coding with Cline: AI による⽣産性変⾰の現在地と未来形 スピーカー： ノバセル株式会社　山中 雄生 様 ノバセル株式会社様からは、山中雄生様より「Coding with Cline: AI による⽣産性変⾰の現在地と未来形」と題して、AI を活用した生産性改善の事例紹介がありました。開発における AI 支援レベルを定義し、レベルに応じた生産性改善効果や活用ツールが紹介されました。ノバセルにおける具体的な開発事例として、顧客プロパティ動的拡張やメール連携機能の実装における工数削減効果が示されました。また、ビジネスサイドにおけるAI活用事例として、ナレッジデータベースを活用した広告運用提案の効率化や、新規事業での営業資料生成の効率化が紹介されました。 ※ Amazon Bedrock の Prompt Cashing 機能は本イベント開催時点 2025 年 4 月 8 日には既に一般公開されており、お客様はレイテンシーを抑えてコスト効率良く Amazon Bedrock の多様なモデルをご利用いただく事が可能となっております。 さいごに 今回のイベントでは、AI コーディングエージェントである Cline と Amazon Bedrock を活用した開発手法を体験することができました。特に、Cline と Claude 3.7 Sonnet の組み合わせによる開発生産性の向上、および開発チーム体制の変化の可能性について実感いただけたかと思います。AI 技術の進化により、開発現場の効率化がますます進んでいくことが期待されます。まだまだ歴が浅く、手探りで課題だらけの分野だと思いますが、よりよい方法と最新の情報を発信できればと思います。みなさまも Cline with Bedrock で良き開発者ライフを！ 著者プロフィール 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Web 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

Neuron Community – Day One 会場の様子 こんにちは、ソリューションアーキテクトの宇佐美です。2025年4月9日に開催された「Neuron Community – Day One」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。記念すべきイベントの第1回目ということで、Day Oneと名付けられています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。現在、AWS Trainium / Inferentia エコシステムに関する情報は AWS 公式のドキュメント が中心であり、実践的な知見の共有が限られているのが現状です。このような背景から、ユーザー間での知見共有を促進する場として「Neuron Community」が発足しました。 AWS セッション 針原 佳貴 「オープニング」 資料： https://speakerdeck.com/hariby/aws-neuron-community-day-one Neuron Community – Day One オープニング オープニングでは、SA の針原より Neuron Community の立ち上げの経緯、その意義について説明しました。 2025年1月14日に開催されたイベント「 基盤モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術 ～ AWS Trainium2 & Amazon Bedrock Marketplace ～ 」で、 カラクリ株式会社 取締役 CPO の中山 智文氏より、「一緒に Trainium のユーザーコミュニティを盛り上げていきましょう！」との声掛けがあり、これをきっかけに Neuron Community 活動がスタートしたことが紹介されました。 また、Neuron Community の意義は、エンジニア同士が会社の垣根を超えて交流し知見を共有していくことであると説明されました。日本では 2023年に実施した AWS LLM 開発支援プログラム で 15社中13社が AWS Trainium を活用して LLM を開発するなど、AWS Trainium / Inferentia の先進的な事例が複数登場していますが、まだまだ企業間のコラボレーションは発展途上です。Neuron Community が、企業を超えたコラボレーション促進の場となることが期待されます。 常世 大史 「AWS Neuron アップデート」 資料： https://speakerdeck.com/htokoyo/20250409-neuron-community-trainium-inferentia-neuron-update AWS Trainium / Inferentia / Neuron SDK 最新情報 2025春 2つ目のセッションとして、Annapurna Labs の常世より AWS Trainium / Inferentia / Neuron の最新動向について紹介しました。Neuron Community の1回目のイベントということもあり、最初に AWS の AI アクセラレータチップの歴史や、アーキテクチャ、AI アクセラレータチップ向けの SDK である AWS Neuron のソフトウェアスタックを紹介しました。AWS の AI アクセラレータは、2019年に登場した Amazon EC2 Inf1 インスタンスから始まり、すでに6年以上の歴史と実績があります。その間、第1世代の AWS Inferentia 、第2世代の AWS Trainium / Inferentia2 、第3世代の AWS Trainium2 が登場しています。また、SDK の AWS Neuron のソフトウェアスタックに含まれる、大規模言語モデルの分散学習向けライブラリや分散推論向けライブラリが紹介されました。AWS Neuron には、Neuron コアを直接プログラミングするための Neuron Kernel Interface (NKI) も含まれています。NKI は、Python ベースでできており、馴染み深い NumPy スタイルで実装することができます。 その後、2025年4月3日にリリースされた AWS Neuron 2.22 について説明しました。このバージョンでは、推論ワークロードとして Llama-3.2-11B マルチモーダルモデル対応、マルチ LoRA サービング対応、量子化機能の拡張など、学習ワークロードとして LoRA教師あり (supervised) ファインチューニング対応などが行われていることが説明されました。 ライトニングトーク 安立 健人氏（グリーエックス株式会社）「持続可能なLLM推論インフラを考える〜 AWS Inferentia 採用のポイント〜」 グリーエックス株式会社の安立氏からは、「持続可能なLLM推論インフラを考える 〜AWS Inferentia 採用のポイント〜」と題して、推論向けの AI アクセラレータである AWS Inferentia の採用のポイントについて説明していただきました。 LLM がいよいよ実用フェーズへ移行してきた2025年は、推論インフラのコスト最適化・多様化が課題になり、持続可能なインフラをどう実現するかが重要になるという視点から、AWS Inferentia はコスト効率が高く、レイテンシやスループットにもメリットがあると評価されていることをお話しいただきました。また、GPU から AWS Inferentia への移行については、学習コストはあるのものの、PyTorch のコードを利用できるため移行自体はそれほど大変ではない点をコメント頂き、非クリティカルなワークロードからGPUとInferentiaとのハイブリッド運用を導入する現実的なアプローチも提案頂きました。 さらに、AWS Inferentia を採用する際の判断のポイントを、技術的判断ポイント、組織的判断ポイントに分けて、チェックリスト形式で説明していただきました。このリストには、「導入による達成目標の明確化」を行って具体的な数値目標（例：コスト削減 XX%）を定めることが重要であることなど、複数の実践的なアドバイスが含まれており、多くの方が熱心にメモを取っている様子が印象的でした。 中山 智文 氏（カラクリ株式会社 取締役 CPO）「AWS Trainium の壁を乗り越えるためにやってきたこと」 資料： https://drive.google.com/file/d/1pYKCINt9N1BITFuXFMnEZNijeJDVZBIG/edit AWS Trainium の壁を乗り越えるためにやってきたこと カラクリ株式会社の中山氏からは、「AWS Trainium の壁を乗り越えるためにやってきたこと」と題して、AWS Neuron が未対応の大規模言語モデルの学習をどのように実現してきたかを紹介していただきました。 中山氏は、諸事情で急遽リモート参加となりましたが、事前に準備していただいた動画をストリーミングする形で発表していただきました。コスト効率の高い Amazon EC2 Trn1 インスタンスの利用を決めたものの、当時 AWS Neuron では未対応であったモデルを自社で実装しており、学習させるための苦労は大きかったとのことです。エンジニア 3名の座談会形式で語られた、新しいモデルに自社で対応するために要した工夫と努力はたいへん興味深く、多くの参加者の興味を惹き、自分たちも挑戦したいという気持ちを掻き立てていたようです。最後に「気合とコミュニケーションで乗りこえることでかけた工数より遥かに大きいコスト削減効果は得られます。」とセッションを結んで頂きました。 さいごに Neuron Community は、第1回目から非常に興味深い内容で、その後の懇親会も盛り上がりました。エンジニア同士が会社の垣根を超えて知見を共有するという Neuron Community の意義が実感できるイベントになっていたと思います。 今後も Neuron Community は、第2回、第3回と回を重ねながら成長していきます。オープンなコミュニティですので、AWS Trainium / Inferentia / Neuron に興味のある方は、下記のリンクから Discord の AWS Neuron Community サーバーに参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。

AWS Glue は、さまざまなデータソースからのデータを大規模に処理・統合できるサーバーレスのデータ統合サービスです。Apache Spark ジョブ用の最新バージョンである AWS Glue 5.0 は、バッチ処理とストリーム処理に最適化された Apache Spark 3.5 ランタイム環境を提供します。AWS Glue 5.0 を使えば、パフォーマンスの向上、セキュリティの強化、次世代の Amazon SageMaker のサポート、その他の機能強化が得られます。AWS Glue 5.0 により、データ統合ワークロードの開発、実行、スケーリングが可能になり、より迅速にインサイトを得られるようになります。 AWS Glue は、複数のジョブ作成アプローチを通じて、さまざまな開発方法に対応しています。ダイレクトコーディングがお好きな開発者の方は、AWS Glue ETL ライブラリを使用した Python または Scala での開発が可能です。 本番環境に耐えうるデータプラットフォームを構築するには、堅牢な開発プロセスと継続的インテグレーションおよびデリバリー (CI/CD) パイプラインが必要です。ローカルマシン、 Amazon Elastic Compute Cloud (Amazon EC2) 上の Docker コンテナ、その他の環境など、さまざまな開発ニーズに対応するため、AWS は Amazon ECR Public Gallery を通じて公式の AWS Glue Docker イメージを提供しています。このイメージにより、開発者の方は AWS Glue ETL ライブラリを使用しながら、お好きな環境で効率的に作業できます。 この記事では、Docker コンテナを使用して AWS Glue 5.0 ジョブをローカルで開発およびテストする方法を示します。この記事は、 Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container の更新版で、AWS Glue 5.0 を使用しています。 利用可能な Docker イメージ 以下の Docker イメージが Amazon ECR Public Gallery で利用可能です: AWS Glue バージョン 5.0 – ecr.aws/glue/aws-glue-libs:5 AWS Glue の Docker イメージは、 x86_64 と arm64 の両方に対応しています。 この記事では、 public.ecr.aws/glue/aws-glue-libs:5 を使用し、コンテナをローカルマシン (Mac、Windows、Linux) 上で実行します。このコンテナイメージは、AWS Glue 5.0 の Spark ジョブでテストされています。このイメージには以下が含まれています。 Amazon Linux 2023 AWS Glue ETL ライブラリ Apache Spark 3.5.4 Open table format ライブラリ: Apache Iceberg 1.7.1、Apache Hudi 0.15.0、Delta Lake 3.3.0 AWS Glue Data Catalog クライアント Apache Spark 用 Amazon Redshift コネクタ Apache Hadoop 用 Amazon DynamoDB コネクタ コンテナをセットアップするには、ECR Public Gallery からイメージを pull し、コンテナを実行します。要件に応じて、次の方法でコンテナの実行方法を示します: spark-submit REPL シェル ( pyspark ) pytest Visual Studio Code 前提条件 始める前に、Docker がインストールされていて Docker デーモンが実行中であることを確認してください。インストール手順については、 Mac 、 Windows 、または Linux 向けの Docker ドキュメントを参照してください。また、Docker を実行しているホストに少なくとも 7GB のディスク領域があることを確認してください。 AWS 認証情報の設定 コンテナから AWS API 呼び出しを有効にするには、次の手順で AWS 認証情報を設定します。 AWS 名前付きプロファイルを作成 します。 Windows では cmd を、Mac/Linux では端末を開き、次のコマンドを実行します: PROFILE_NAME="profile_name" 次のセクションでは、この AWS 名前付きプロファイルを使用します。 ECR Public Gallery からイメージを pull Docker を Windows で実行している場合は、イメージを pull する前に Docker アイコンを右クリックし、 Linux コンテナに切り替える を選択してください。 ECR Public Gallery からイメージを pull するには、次のコマンドを実行してください: docker pull public.ecr.aws/glue/aws-glue-libs:5 コンテナの実行 これで、このイメージを使ってコンテナを実行できます。要件に応じて、以下のいずれかの方法を選択できます。 spark-submit AWS Glue ジョブスクリプトは、コンテナ上で spark-submit コマンドを実行することで実行できます。 ジョブスクリプト ( sample.py の例) を書き、次のコマンドを使って /local_path_to_workspace/src/ ディレクトリに保存してください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ mkdir -p ${WORKSPACE_LOCATION}/src $ vim ${WORKSPACE_LOCATION}/src/${SCRIPT_FILE_NAME} これらの変数は、次の docker run コマンドで使用されます。 spark-submit コマンドで使用されるサンプルコード ( sample.py ) は、この記事の最後の Appendix に含まれています。 次のコマンドを実行して、コンテナ上で spark-submit コマンドを実行し、新しい Spark アプリケーションを送信します: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_spark_submit \ public.ecr.aws/glue/aws-glue-libs:5 \ spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME REPL シェル (pyspark) REPL (read-eval-print loop) シェルを使用すると、インタラクティブな開発ができます。コンテナ上で pyspark コマンドを実行し、REPL シェルを起動するには、次のコマンドを実行します。 $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 次の出力が表示されます: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740643079929). SparkSession available as 'spark'. >>> この REPL シェルを使えば、対話的にコーディングとテストができます。 pytest 単体テストには、AWS Glue Spark ジョブスクリプトに対して pytest を使用できます。 次のコマンドを実行して準備をしてください: $ WORKSPACE_LOCATION=/local_path_to_workspace $ SCRIPT_FILE_NAME=sample.py $ UNIT_TEST_FILE_NAME=test_sample.py $ mkdir -p ${WORKSPACE_LOCATION}/tests $ vim ${WORKSPACE_LOCATION}/tests/${UNIT_TEST_FILE_NAME} 次に、 docker run を使って pytest を呼び出しましょう: $ docker run -i --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pytest \ public.ecr.aws/glue/aws-glue-libs:5 \ -c "python3 -m pytest --disable-warnings" pytest がユニットテストの実行を終えると、出力は次のようになります: ============================= test session starts ============================== platform linux -- Python 3.11.6, pytest-8.3.4, pluggy-1.5.0 rootdir: /home/hadoop/workspace plugins: integration-mark-0.2.0 collected 1 item tests/test_sample.py . [100%] ======================== 1 passed, 1 warning in 34.28s ========================= Visual Studio Code Visual Studio Code でコンテナを設定するには、以下の手順を実行してください: Visual Studio Code をインストールしてください。 Python をインストールしてください。 Dev Containers をインストールしてください。 Visual Studio Code でワークスペースフォルダを開いてください。 Ctrl+Shift+P (Windows/Linux) または Cmd+Shift+P (Mac) を押してください。 Preferences: Open Workspace Settings (JSON) と入力してください。 Enter を押してください。 次の JSON を入力して保存してください。 { "python.defaultInterpreterPath": "/usr/bin/python3.11", "python.analysis.extraPaths": [ "/usr/lib/spark/python/lib/py4j-0.10.9.7-src.zip:/usr/lib/spark/python/:/usr/lib/spark/python/lib/", ] } これで、コンテナのセットアップの準備ができました。 Docker コンテナを実行します: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pyspark \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark Visual Studio Code を起動します。 ナビゲーションペインで Remote Explorer を選択します。 コンテナ ecr.aws/glue/aws-glue-libs:5 を右クリックし、 Attach in Current Window を選択します。 次のダイアログが表示された場合は  Got it を選択してください。 /home/hadoop/workspace/ を開いてください。 AWS Glue の PySpark スクリプトを作成し、 Run を選択します。 AWS Glue の PySpark スクリプトが正常に実行されたことが確認できるはずです。 AWS Glue 4.0 と AWS Glue 5.0 の Docker イメージ間の変更点 AWS Glue 4.0 と Glue 5.0 の Docker イメージ間の主な変更点は次のとおりです。 AWS Glue 5.0 では、バッチジョブとストリーミングジョブの両方に単一のコンテナイメージが使用されます。これは AWS Glue 4.0 とは異なり、4.0 ではバッチ用とストリーミング用に別々のイメージがありました。 AWS Glue 5.0 では、コンテナのデフォルトユーザー名は hadoop です。AWS Glue 4.0 では、デフォルトユーザー名は glue_user でした。 AWS Glue 5.0 では、JupyterLab や Livy などのいくつかの追加ライブラリがイメージから削除されています。手動でインストールすることができます。 AWS Glue 5.0 では、Iceberg、Hudi、Delta ライブラリがすべてデフォルトで事前ロードされており、環境変数 DATALAKE_FORMATS は不要になりました。AWS Glue 4.0 までは、環境変数 DATALAKE_FORMATS を使用して、特定のテーブル形式がロードされるかどうかを指定していました。 前述のリストは Docker イメージに固有のものです。AWS Glue 5.0 の更新について詳しくは、 Introducing AWS Glue 5.0 for Apache Spark および Migrating AWS Glue for Spark jobs to AWS Glue version 5.0 をご覧ください。 考慮事項 AWS Glue コンテナイメージを使用してジョブスクリプトをローカルで開発する際、以下の機能はサポートされていないことに注意してください: ジョブのブックマーク AWS Glue Parquet writer (参照: AWS Glue での Parquet 形式の使用 ) FillMissingValues 変換 FindMatches 変換 ベクトル化された SIMD CSV リーダー Amazon Simple Storage Service (Amazon S3) のパスから JDBC ドライバーをロードするための customJdbcDriverS3Path プロパティ AWS Glue Data Quality 機密データの検出 AWS Lake Formation の権限ベースのクレデンシャル発行 結論 この投稿では、AWS Glue 5.0 Docker イメージが、お好みの環境で AWS Glue ジョブスクリプトを開発およびテストするための柔軟な基盤を提供することをご紹介しました。Amazon ECR Public Gallery で簡単に入手できるこれらのイメージは、AWS Glue ジョブの開発に一貫したポータブルな環境を提供することで、開発プロセスを合理化します。 エンドツーエンドの開発パイプラインの構築方法の詳細については、 End-to-end development lifecycle for data engineers to build a data integration pipeline using AWS Glue をご覧ください。これらの機能を活用し、AWS コミュニティで知見を共有することをお勧めします。 Appendix A: AWS Glue ジョブのテスト用サンプルコード この Appendix では、テスト目的で AWS Glue ジョブのサンプルコードとして 3 つの異なるスクリプトを紹介します。チュートリアルではこれらのいずれかを使用できます。 以下の sample.py コードは、AWS Glue ETL ライブラリと Amazon Simple Storage Service (Amazon S3) の API 呼び出しを使用しています。このコードには、 AWS Identity and Access Management (IAM) での Amazon S3 の権限が必要です。arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess の IAM 管理ポリシーか、S3 パスに対して ListBucket と GetObject の API 呼び出しを許可するカスタム IAM ポリシーを付与する必要があります。 import sys from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions class GluePythonSampleTest: def __init__(self): params = [] if '--JOB_NAME' in sys.argv: params.append('JOB_NAME') args = getResolvedOptions(sys.argv, params) self.context = GlueContext(SparkContext.getOrCreate()) self.job = Job(self.context) if 'JOB_NAME' in args: jobname = args['JOB_NAME'] else: jobname = "test" self.job.init(jobname, args) def run(self): dyf = read_json(self.context, "s3://awsglue-datasets/examples/us-legislators/all/persons.json") dyf.printSchema() self.job.commit() def read_json(glue_context, path): dynamicframe = glue_context.create_dynamic_frame.from_options( connection_type='s3', connection_options={ 'paths': [path], 'recurse': True }, format='json' ) return dynamicframe if __name__ == '__main__': GluePythonSampleTest().run() 以下の test_sample.py コードは、sample.py のユニットテストのサンプルです: import pytest from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.utils import getResolvedOptions import sys from src import sample @pytest.fixture(scope="module", autouse=True) def glue_context(): sys.argv.append('--JOB_NAME') sys.argv.append('test_count') args = getResolvedOptions(sys.argv, ['JOB_NAME']) context = GlueContext(SparkContext.getOrCreate()) job = Job(context) job.init(args['JOB_NAME'], args) Appendix B: JDBC ドライバーと Java ライブラリの追加 コンテナ内に現在ない JDBC ドライバーを追加する場合は、ワークスペース内に必要な JAR ファイルを含む新しいディレクトリを作成し、そのディレクトリを docker run コマンドで /opt/spark/jars/ にマウントします。コンテナ内の /opt/spark/jars/ 以下にある JAR ファイルは、自動的に Spark クラスパスに追加され、ジョブ実行中に使用できるようになります。 たとえば、次の docker run コマンドを使用して、JDBC ドライバーの jar ファイルを PySpark REPL シェルに追加できます: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $WORKSPACE_LOCATION/jars/:/opt/spark/jars/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jdbc \ public.ecr.aws/glue/aws-glue-libs:5 \ pyspark 前述のように、 customJdbcDriverS3Path 接続オプションは、AWS Glue コンテナイメージにカスタム JDBC ドライバを Amazon S3 からインポートするために使用できません。 Appendix C: Livy と JupyterLab の追加 AWS Glue 5.0 コンテナイメージには、デフォルトで Livy がインストールされていません。AWS Glue 5.0 コンテナイメージを基本とする新しいコンテナイメージを作成できます。次の Dockerfile は、開発およびテスト体験を強化するために必要な追加コンポーネントを含めるように Docker イメージを拡張する方法を示しています。 始めるには、ワークステーションにディレクトリを作成し、そのディレクトリに Dockerfile.livy_jupyter ファイルを配置します。 $ mkdir -p $WORKSPACE_LOCATION/jupyterlab/ $ cd $WORKSPACE_LOCATION/jupyterlab/ $ vim Dockerfile.livy_jupyter 次のコードは Dockerfile.livy_jupyter です: FROM public.ecr.aws/glue/aws-glue-libs:5 AS glue-base ENV LIVY_SERVER_JAVA_OPTS="--add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED" # Download Livy ADD --chown=hadoop:hadoop https://dlcdn.apache.org/incubator/livy/0.8.0-incubating/apache-livy-0.8.0-incubating_2.12-bin.zip ./ # Install and configure Livy RUN unzip apache-livy-0.8.0-incubating_2.12-bin.zip && \ rm apache-livy-0.8.0-incubating_2.12-bin.zip && \ mv apache-livy-0.8.0-incubating_2.12-bin livy && \ mkdir -p livy/logs && \ cat <> livy/conf/livy.conf livy.server.host = 0.0.0.0 livy.server.port = 8998 livy.spark.master = local livy.repl.enable-hive-context = true livy.spark.scala-version = 2.12 EOF && \ cat <> livy/conf/log4j.properties log4j.rootCategory=INFO,console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.target=System.err log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n log4j.logger.org.eclipse.jetty=WARN EOF # Switching to root user temporarily to install dev dependency packages USER root RUN dnf update -y && dnf install -y krb5-devel gcc python3.11-devel USER hadoop # Install SparkMagic and JupyterLab RUN export PATH=$HOME/.local/bin:$HOME/livy/bin/:$PATH && \ printf "numpy<2\nIPython<=7.14.0\n" > /tmp/constraint.txt && \ pip3.11 --no-cache-dir install --constraint /tmp/constraint.txt --user pytest boto==2.49.0 jupyterlab==3.6.8 IPython==7.14.0 ipykernel==5.5.6 ipywidgets==7.7.2 sparkmagic==0.21.0 jupyterlab_widgets==1.1.11 && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/sparkkernel && \ jupyter-kernelspec install --user $(pip3.11 --no-cache-dir show sparkmagic | grep Location | cut -d" " -f2)/sparkmagic/kernels/pysparkkernel && \ jupyter server extension enable --user --py sparkmagic && \ cat <> /home/hadoop/.local/bin/entrypoint.sh #!/usr/bin/env bash mkdir -p /home/hadoop/workspace/ livy-server start sleep 5 jupyter lab --no-browser --ip=0.0.0.0 --allow-root --ServerApp.root_dir=/home/hadoop/workspace/ --ServerApp.token='' --ServerApp.password='' EOF # Setup Entrypoint script RUN chmod + x /home/hadoop/.local/bin/entrypoint.sh # Add default SparkMagic Config ADD --chown=hadoop:hadoop https://raw.githubusercontent.com/jupyter-incubator/sparkmagic/refs/heads/master/sparkmagic/example_config.json .sparkmagic/config.json # Update PATH var ENV PATH=/home/hadoop/.local/bin:/home/hadoop/livy/bin/:$PATH ENTRYPOINT ["/home/hadoop/.local/bin/entrypoint.sh"] Docker ビルドコマンドを実行してイメージをビルドします: docker build \ -t glue_v5_livy \ --file $WORKSPACE_LOCATION/jupyterlab/Dockerfile.livy_jupyter \ $WORKSPACE_LOCATION/jupyterlab/ イメージのビルドが完了したら、次の docker run コマンドを使用して、新しく作成されたイメージを起動できます。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -p 8998:8998 \ -p 8888:8888 \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_jupyter \ glue_v5_livy Appendix D: 追加の Python ライブラリの追加 このセクションでは、追加の Python ライブラリを追加し、Python パッケージをインストールする方法について説明します。 ローカル Python ライブラリ ローカルの Python ライブラリを追加するには、ディレクトリに配置し、パスを $EXTRA_PYTHON_PACKAGE_LOCATION に割り当ててください: $ docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ -v $EXTRA_PYTHON_PACKAGE_LOCATION:/home/hadoop/workspace/extra_python_path/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'export PYTHONPATH=/home/hadoop/workspace/extra_python_path/:$PYTHONPATH ; pyspark' PYTHONPATH にパスが追加されたことを検証するには、 sys.path にそのパスが存在するかどうかを確認できます: Python 3.11.6 (main, Jan 9 2025, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). Welcome to ____ __ / __/__ ___ _____/ /__ _\ \/ _ \/ _ `/ __/ '_/ /__ / .__/\_,_/_/ /_/\_\ version 3.5.2-amzn-1 /_/ Using Python version 3.11.6 (main, Jan 9 2025 00:00:00) Spark context Web UI available at None Spark context available as 'sc' (master = local[*], app id = local-1740719582296). SparkSession available as 'spark'. >>> import sys >>> "/home/hadoop/workspace/extra_python_path" in sys.path True Python パッケージの pip によるインストール PyPI (または他のアーティファクトリポジトリ) からパッケージを pip でインストールするには、次のアプローチを使用できます。 docker run -it --rm \ -v ~/.aws:/home/hadoop/.aws \ -v $WORKSPACE_LOCATION:/home/hadoop/workspace/ \ --workdir /home/hadoop/workspace \ -e AWS_PROFILE=$PROFILE_NAME \ -e SCRIPT_FILE_NAME=$SCRIPT_FILE_NAME \ --name glue5_pylib \ public.ecr.aws/glue/aws-glue-libs:5 \ -c 'pip3 install snowflake==1.0.5 ; spark-submit /home/hadoop/workspace/src/$SCRIPT_FILE_NAME' 本記事は、2025 年 3 月 12 日に公開された  Develop and test AWS Glue 5.0 jobs locally using a Docker container を翻訳したものです。翻訳はソリューションアーキテクトの高橋が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 日本のお客様から数多くご要望をいただいておりました Amazon Q Developer の日本語対応ですが、この度日本語を含む多言語サポートの拡大という形で IDE および CLI 機能にて対応いたしました。詳細についてはぜひこの投稿の中で紹介いたします日本語ブログをご参照ください。また、これを機に Amazon Q Developer の機能をハンズオンの「 Q-Words 」で網羅的に学ぶこともおすすめです（日本語対応済）。 それでは、4 月 7 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース お客様事例ブログ「OfferUp が Amazon Bedrock と Amazon OpenSearch Service のマルチモーダル検索を導入し、地域に密着した検索結果が 54% 増加、検索の関連性が 27% 向上」を公開 オンラインマーケットプレイスを提供する OfferUp が Amazon Bedrock のTitan Multimodal Embeddings と Amazon OpenSearch Service を活用したマルチモーダル検索を導入し、地域に密着した検索結果が 54 %向上、検索の関連性が 27 %向上しました。テキストと画像の両方を使った検索により、ユーザーエンゲージメントが 2.2 %増加、出品者とのやり取り（EWSR）が 3.8 %改善し、検索閲覧深度も 6.5 %増加しました。従来のキーワード検索では難しかった「コンテキスト理解」「同義語認識」「複雑なクエリ管理」などの課題を解決し、広告インプレッションも 0.91 %増加させる成果を上げています。 ブログ記事「あなたの言語で開発を支援：Amazon Q Developer の言語サポートが拡大 (日本語を含む)」を公開 Amazon Q Developer が統合開発環境（IDE）および Amazon Q Developer CLI での多言語サポートを開始しました。対応言語には中国語、フランス語、ドイツ語、イタリア語、日本語、スペイン語、韓国語、ヒンディー語、ポルトガル語などが含まれます。使い方は簡単で、お好みの言語で Amazon Q Developer との会話を始めるだけです。Amazon Q Developer はその言語を自動的に検出し、回答、コード提案、応答を適切な言語で提供します。このアップデートは、Amazon Q Developer が利用可能なすべての AWS リージョンで提供されます。 Amazon Nova Sonic を発表 – リアルタイム音声会話を実現する基盤モデル Amazon が音声対応アプリケーションを革新する音声・発話基盤モデルの Amazon Nova Sonic を発表しました。Amazon Nova Sonic は先進の AI 音声モデルで、テキストを介さずに直接音声入力を音声出力に変換します。このモデルはリアルタイムでの自然な会話体験を提供し、従来の音声テクノロジーにつきものだった遅延や不自然さを解消します。Amazon Nova Sonic は現在、Amazon Bedrock でご利用いただけます。同時に発表された双方向ストリーミング API と組み合わせることで、人間と AI の間でほぼ瞬時のやりとりが可能になります。現在、米国東部（バージニア北部）リージョンで利用可能です。 サービスアップデート– 生成AIを組み込んだ構築済みアプリケーション PartyRock に Amazon Nova Canvas による画像プレイグラウンドを追加 PartyRock が、Amazon Nova Canvas を活用した画像専用のプレイグラウンド機能を追加しました。「Images」セクションから直接アクセスできるこの機能は、画像の向き（横向き、縦向き、正方形）、解像度、色の指定など画像に特化した幅広いカスタマイズオプションを簡単に指定できる UI を提供し、事前入力されたプロンプトですぐに開始できます。生成された画像をさらに改良するための提案プロンプトも表示され、無料日次利用枠で気軽に試すことができます。 サービスアップデート – アプリケーション開発のためのツール Amazon Bedrockでプロンプトキャッシングが一般提供開始 re:Invent 2024 でプレビュー発表したプロンプトキャッシング機能が一般提供開始されました。複数の API 呼び出しで頻繁に使用されるプロンプトをキャッシュすることで、コストを最大 90 %、レイテンシーを最大 85 %削減できます。システムプロンプトや例示など、頻繁に使用される長いコンテキストの再処理を省くことで処理速度向上とコスト削減を両立させます。現在、Anthropic の Claude 3.5 Haiku と Claude 3.7 Sonnet、Nova Micro、Nova Lite、Nova Proモデルで利用可能です。 Amazon Nova Canvasがファインチューニングに対応 Amazon Nova Canvas が独自データセットでのファインチューニングをサポート開始し、ブランド特性に合わせたモデルのカスタマイズが可能になりました。独自データでトレーニングすることで、特定の要件やスタイルガイドラインに合った完全にカスタマイズされた画像生成が実現し、テスト後はプロビジョンドスループットで一貫したパフォーマンスを発揮します。テキストから画像への変換モデルは建築、ファッション、製造、小売、ゲーム、広告など様々な業界でクリエイティブワークフローを効率化できます。現在、米国東部（バージニア北部）リージョンで利用可能です。 Amazon BedrockにMistral AIのPixtral Large 25.02を追加 AWS が Mistral AI の「Pixtral Large 25.02」を Amazon Bedrock で提供開始しました。1240億パラメータを持つこのマルチモーダルモデルは、文書分析、チャート解釈、自然画像理解タスクで優れたパフォーマンスを発揮します。128Kのコンテキストウィンドウを備え、MathVista、DocVQA、VQAv2 などの主要ベンチマークで最高クラスの結果を達成しています。数十の言語と 80 以上のプログラミング言語をサポートし、高度な数学的推論、関数呼び出し、RAG アプリケーションにも対応しています。現在、米国およびヨーロッパの 7 つのAWSリージョンで利用可能です。 Amazon Nova Reel 1.1を発表 Amazon Nova Reel 1.1 が発表され、最大 2 分間のマルチショット動画生成とショット間のスタイル一貫性を実現しました。自動モードと手動モードの 2 つのオプションを提供し、自動モードでは単一のプロンプトと合計動画時間の指定だけで複数の 6 秒動画を生成、手動モードでは各 6 秒ショットのテキストプロンプトと画像を個別制御できます。6 秒シングルショット動画生成の品質とレイテンシーもバージョン 1.0 から改善されています。現在、米国東部（バージニア北部）リージョンで利用可能です。 Amazon Bedrock Guardrailsに生成AIアプリケーションを安全に構築するための新機能が追加 Amazon Bedrock Guardrails に生成 AI アプリケーションを安全に構築するための新機能が追加されました。新たに実装された「検出モード」では、設定したポリシーの効果を展開前に評価でき、迅速な反復によるガードレールの微調整が可能になります。また、入力プロンプト、モデル応答、またはその両方にポリシーを選択的に適用する柔軟性も追加され、これまでの両方に自動適用するデフォルト設定から大幅に改善されました。さらに、センシティブ情報フィルターは、リクエストを完全にブロックする「Block」モードと情報を編集して識別子タグに置き換える「Mask」モードの両方を入力と出力の双方で使用できるようになりました。 サービスアップデート – その他 Amazon Bedrock Knowledge Bases が Aurora PostgreSQL および MongoDB Atlas vector stores のハイブリッド検索に対応 Amazon Bedrock Knowledge Bases が、Aurora PostgreSQL と MongoDB Atlas vector stores に対するハイブリッド検索機能のサポートを追加しました。セマンティック検索とフルテキスト検索を組み合わせたハイブリッド検索は、検索結果の関連性を向上させ、概念的に一致するドキュメントとキーワードに一致するドキュメントの両方を返します。この機能はKnowledge Base APIまたはBedrockコンソールから簡単に有効化できます。現在、Aurora PostgreSQL ではヨーロッパ（チューリッヒ）と GovCloud（US）リージョンを除くすべての地域で、MongoDB Atlas では米国西部（オレゴン）と米国東部（バージニア北部）で利用可能です。 Aurora PostgreSQLがpgvector 0.8.0をサポート Amazon Aurora PostgreSQL がベクトル埋め込み用のオープンソース拡張機能 pgvector 0.8.0 のサポートを開始しました。この拡張機能は生成 AI のセマンティック検索や RAG アプリケーションに活用でき、PostgreSQL クエリプランナーがフィルター使用時のインデックス選択を改善し、クエリパフォーマンスと検索結果の品質を向上させます。WHEREの条件や結合を使用したデータフィルタリングが改善され、過剰フィルタリングを防止する反復インデックススキャンも提供されています。現在、pgvector 0.8.0 は中国を除くすべてのAWSリージョン（AWS GovCloud含む）で PostgreSQL 16.8、15.12、14.17、13.20 以上を実行している Aurora クラスターで利用可能です。 今週は以上でした。それでは、また来週もお楽しみに！ 三厨 航(Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たドラマは「IWGP」です。

2025/4/14 更新：イベントが閉幕したため、イベント案内ブログを開催報告として更新しました。 リテールテック JAPAN は、今回、開催 41 回目を迎える国内最大の流通業向け情報システム総合展示会（日本経済新聞社主催）です。今年は 2025 年 3 月 4 日から 7 日までの 4 日間、東京ビッグサイトで開催されました。人件費の適正化、顧客体験（CX）の向上、廃棄／機会ロスの削減などの観点から、小売業における IT 活用が当然になりつつある中、テクノロジーの新たな活用方法を提案するソリューションを各社が展示し、盛況のうちに閉幕しました。リテールテックの 発表 では、4 日間の来場者数は延べ 75,845 人となったそうです。 AWS は 2017 年以来 8 年ぶりに同展示会に出展し、AWS、Amazon、AWS パートナーとともに流通小売業界の抱える課題に答える、実践的なデモンストレーションを展示しました。期間中に AWS ブースにご来場いただいたお客様は延べ 3,000 人を超え、活気のあるものになりました。またご来場いただけなかったお客様や、デモだけ見た、トークだけ聞いた、といったお客様に向けて、AWS ブースの展示テーマや展示デモのハイライト、また AWS ブースのミニシアターで実施した AWS によるライトニングトークを紹介する振り返りセミナーを「【流通小売/消費財/EC 企業向け】 AWS at リテールテック JAPAN 2025」として 4 月 3 日に配信しました。このブログでは、この配信のアーカイブ動画とともに AWS ブースの展示内容をあらためてご紹介します。 振り返りセミナー： アーカイブ動画 | 資料 AWS 展示ブーステーマ 「The Future of Retail – クラウドと生成AIが実現する新たな顧客体験」 業界の対応するべき課題は多岐にわたりますが、今回の展示では「実際に見て、触れて、体験できる “顧客体験”」をコンセプトに、カスタマージャーニーの各ステージで役立つアイデアをご紹介する、という趣向になっています。AWS らしく「お客様にこだわる」視点を重視していること、また最新テクノロジーの代表と言える生成 AI をあらゆる展示で取り込んでいることも特徴です。 ブーステーマについて解説動画を以下からご覧いただけます。 ブースツアー AWS ブースは 5 つのテーマで構成されています。現地では開催期間中、AWS ブースをこのテーマに沿って、15 分ほどで AWS メンバーが解説付きでご案内する「ブースツアー」を行い、毎日多くのお客様にご参加いただきました。現地で展示していたデモを解説付きで「バーチャルブースツアー」として、振り返りセッションでも再現しました。 アーカイブ動画 でその内容をご覧いただけます。 顧客エンゲージメント（購入前） 購買者 = 顧客との接点は、顧客が店舗に来店するあるいは、EC サイトやアプリにアクセスする前から始まっています。小売業の皆さまは、新規顧客を獲得する、既存顧客とより深いエンゲージメントを築く、顧客からのロイヤルティを得るために、日々模索していと思います。顧客のデータを一元化し、適切なタッチポイントに適切なタイミングで有効な広告を届けることで、来店前の顧客とのエンゲージメントをポジティブに、ビジネス効果の高いものにすることができます。さらに生成 AI が加わることで顧客一人ひとりを理解する「ハイパーパーソナライゼーション（高度なパーソナライゼーション）」を実現することができます。 このテーマでは、顧客データプラットフォーム (CDP) による統合顧客プロファイルの重要性（AWS パートナー – Tealium Japan 株式会社 ）とターゲットを絞ったマーケティングキャンペーンと効果測定（ Amazon Ads ）のデモンストレーションを行いました。 スマートストア 顧客とつながる、コネクテッドなショッピング体験は、デジタル世界だけでなく実店舗において、生成 AI によって大きく進化しています。デジタルの活用が進んでいるとはいっても、小売業界において 72% の売上は、依然として実店舗からもたらされています（ 出典 ）。そして、顧客にとってデジタルショッピング体験は既に特別なものでなく当たり前のものであり、その体験は実店舗でのショッピングにおいても当たり前の期待値になっています。AWS は Just Walk Out テクノロジー のように購買体験を直感的に変革するサービスを提供してその期待値に応えています。自分のイメージや自分の部屋などに実際に商品がマッチしているのか確認しながらの接客や試用/試着商品の選択によって、より高いコンバージョン率や店舗でのエンゲージメント向上に繋がることでしょう。 スマートストアのテーマにおいては「デジタルショッピング体験の便利さに慣れた顧客に、リアル（実店舗）でも同じ期待値を提供する」をビジョンとし、部屋の模様替え（AWS Room Makeover デモ）とファッションスタイル（バーチャル試着デモ）の 2 つのショッピングシーンを例とした、店舗でのデジタル技術の活用案をデモンストレーションしました。 デジタルコマース デジタル世界のショッピング体験は、E コマースからソーシャルメディアへと広がり、さらには AI/ML、AR/VR、高度なパーソナライゼーションなどの最先端技術の適用によって、日々変革がもたらされています。新たな技術が顧客の購買ジャーニーを強化し、デジタル領域での購買決定の方法を変え続けています。デジタルショッピングを実際のショッピングと同じくらいに自然で、直感的なものにすることが求められるようになっています。特にブランドや小売業者の 55% が、今後 3 年間でイマーシブコマース（没入型ショッピング体験）への投資を増やすとしている （出典: Coresight Research and Obsess Q4 2023 Survey） のは注目するべきトレンドです。 デジタルコマースのテーマでは、デジタルの世界でも店舗で店員さんに相談するように話をしながら商品を選ぶ（AWS AI ショッピングアシスタントデモ）、没入型体験を通じて自然なショッピング体験を提供しつつエンドレスアイルも実現する（Amazon Beyond および、AWS パートナーを活用した没入型店舗の顧客事例）を紹介しました。 もう一つデジタル世界のショッピング体験で欠かせないもの、それは「オンライン決済」です。E コマースサイトなどに多様な決済手段を揃え、顧客にフリクションレスなショッピングを提供する必要があります。「安全」であることも不可欠です。 一般社団法人日本クレジット協会によると 、2024 年 7 月～ 9 月の期間だけでもクレジットカード不正利用被害額は 132.7 億円にものぼります。各社の取り組みが進み、2023 年同時期に比較すれば減少傾向には転じたものの、「番号盗用」による被害、つまり主に E コマースサイトにおける不正利用が 90% を占めています。 ここではオンラインビジネスの成長を強力にサポートする信頼性の高い決済プラットフォーム（AWS パートナー – ストライプジャパン株式会社 ）のデモンストレーションを行いました。 顧客エンゲージメント（購入後） 顧客にとって商品の購入はゴールではなく、購入してからその商品との体験が始まります。LTV （Life Time Value：顧客生涯価値） に注目している企業も多いでしょう。この LTV 向上にとって、顧客体験（カスタマーエクスペリエンス; CX）は重要な要素です。購入時だけでなく、その後のカスタマーサポートやカスタマーフィードバックを介してあらゆる顧客接点を分析し、よりよい顧客体験を提供するための PDCA サイクルを繰り返すことで、顧客エンゲージメントは初めて真価を発揮します。CX を計測する指標やそのデータの収集・調査の進め方、分析結果の活用方法もデジタル技術により多様化しています。 顧客エンゲージメント（購買後）のテーマでは、この CX 管理（AWS パートナー – クアルトリクス株式会社 ）のデモンストレーションを行いました。 プロダクトイノベーション マッキンゼーの調査によると、生成 AI によるプロダクト設計の生産性向上には、600 億ドル、日本円で 9.1 兆円という驚異的なビジネスチャンスがあることが明らかになりました（出典: McKinsey, March 2024）。これは単なるコスト削減ではなく、イノベーションを加速させ、プロダクトをより早く市場に投入し、売上に直接的に貢献します。小売業や消費者ブランドにとって、これはプロダクトの発想と開発方法からマーケティング施策まで、大きなイノベーションをもたらすものです。 このテーマでは、「プロダクトデザインの民主化」をコンセプトに、生成 AI を活用したサービスを組み合わせ、手描きのイメージから完成品のプロダクトイメージを生成し、さらにソーシャルメディアごとのマーケティングキャッチを生成する AWS デモアプリケーションを展示しました。 サプライチェーン 小売企業の抱えるサプライチェーンの問題は多岐にわたりますが、今回の AWS ブースの展示では「顧客体験」を中心として考え、「顧客がほしい商品を、ほしい時に、ほしい場所で手に入れられる」ことの重要性にフォーカスします。タイムリーな需要予測、在庫管理や移動管理、ラストマイル配送や BOPIS （Buy Online Pick-up In Store; E コマースなどオンラインで購入した商品を店舗で受け取ること） への対応など、考えなくてはならないことが多くありますが、サプライチェーン全体を可視性することだけでも迅速な価値実現への第一歩に繋がります。魅力的な品揃えと顧客の期待に応えるサービスを提供し、より高い収益を達成しつつ、コストを削減していくためには、AI を最大限に活用することが欠かせません。 このテーマでは、次世代サプライチェーンプランニング（AWS パートナー – o9ソリューションズ・ジャパン株式会社 ）、Amazon の提供する物流支援サービス（ アマゾンジャパン合同会社 ） によるサプライチェーン課題へのソリューションの一端をご紹介しました。 AWS パートナーによる注目のデモ 各テーマにおいて AWS パートナー各社と協力し、より広範な課題に対応し、すぐに利用できる、業界ナレッジとベストプラクティスを実現したソリューションを展示します。ここではパートナー各社の展示内容の概要をご紹介します。 顧客エンゲージメント（購入前）– Tealium Japan 株式会社 「CDP と AI で実現する究極の顧客理解」 Tealium は、AI 時代に最適なデータ活用を実現するプラットフォームです。AI 活用の成功には、リアルタイムで整理された、高品質なデータが不可欠です。Tealium は、データ収集、統合からラベリング、エンリッチメントまで、AI モデルが即座に活用できるデータの状態へと最適化します。さらに、AI が生み出した予測スコアやインサイトを広告サービスやパーソナライゼーション、CRM などのあらゆるタッチポイントにリアルタイムで適用し、ビジネスの成果を最大化します。顧客同意のとれた、正確でセキュアなデータを、必要な場所に、必要なタイミングで届けることで、企業の AI 活用を加速します。 デジタルコマース – ストライプジャパン株式会社 「収益向上に繋がる決済プラットフォーム」 Stripe は、オンライン決済を簡単に導入できるプラットフォームです。スタートアップから大企業まで、世界中のあらゆる規模のビジネスと多様な決済方法に対応しており、シンプルな API で、ウェブサイトやアプリに決済機能をスムーズに組み込むことができるため、世界中で利用可能です。多通貨決済や多言語対応で、海外展開をサポートしており、かつ、高度なセキュリティ対策で、顧客情報を安全に保護します。Stripe は、オンラインビジネスの成長を強力にサポートする、信頼性の高い決済プラットフォームです。 顧客エンゲージメント（購入後）– クアルトリクス株式会社 「カスタマーエクスペリエンス（CX）」 クアルトリクスは、エクスペリエンス管理 （XM） のリーディングカンパニーとして、世界中で約 2 万社もの企業に利用されています。高度な AI と人間の感情に関する世界最大規模のデータベースを活用することで、顧客の声を収集・分析し、その結果に基づいたアクション展開をサポートしています。小売業界においては、店舗での顧客対応からオンラインショッピングに至るまで、あらゆる顧客接点を分析し、よりよい顧客体験を提供するための施策を支援するために活用されています。顧客中心の視点でリテール企業が直面する顧客ロイヤリティや店舗パフォーマンスの向上、クロスチャネル戦略の最適化など企業収益の向上に貢献します。 サプライチェーン – o9ソリューションズ・ジャパン株式会社 「次世代サプライチェーンプランニング」 o9 （オーナイン）ソリューションズは、サプライチェーンプランニングに特化したプラットフォーム「o9 デジタルブレイン」を提供しています。需要予測、在庫管理やアロケーションプランニング、IBP（統合事業計画）、S&OP（販売業務計画）などの多様なソリューションを用意しています。o9 デジタルブレインを導入したお客様は、需要予測精度の改善、品揃え計画の最適化、過剰在庫や欠品の削減、計画業務時間の大幅削減などの導入効果を得ています。サプライチェーン全体におけるキャパシティや輸送リードタイムなど様々な制約を考慮した計画を立てることができ、急な需要変化やサプライチェーン上のトラブルが起きた際の供給計画にも迅速に対応できます。 ミニシアターセッション AWS ブースのミニシアターでは、毎日 15 分間のライトニングトークを多数開催し、AWS パートナー各社、Amazon、AWS の小売業務ソリューションのエキスパートからイノベーションのインスピレーションを得ることができました。多くのお客様が AWS ブースのミニシアターにお立ち寄りくださいました。このうち、AWS メンバーがスピーカーを担当した 4 つを、振り返りセミナーで再度、ご紹介しました。 それぞれのライトニングトークは、以下からアーカイブ動画でご覧いただけます。 Amazon の顧客起点データドリブンマーケティング支援の紹介 （ 動画 ） 即日配送を実現する Amazon のサプライチェーンの取り組みと AWS 支援の紹介 （ 動画 ） Amazon Rufus は何が新しい？ 生成 AI で生まれ変わるチャットアシスタント （ 動画 ） Amazon Nova – 新しい Amazon の生成 AI モデルを 15 分で解説 （ 動画 ） 資料は こちらからダウンロード 可能です。 リテールテック JAPAN AWS ブースへのご来場ありがとうございました Born from Retail, Built for Retailers – AWS は、Amazon という小売業から生まれた、小売業のためのクラウドサービスです。そして、AI/MLは、Amazon において 25 年以上前から採用され磨かれてきた技術であり、お客様が Amazon.com で目にする機能の多くは AI/ML によって実現されています。AWSは、Amazon.com によって市場テストされた後、皆さまのために提供される業界固有のサービスを継続的に開発しています。すべてのクラウドサービスプロバイダーが同じではありません。AWS は、小規模なスタートアップチームの俊敏性と、エンタープライズクラスの小売業リーダーの経験を独自に組み合わせています。この経験が、小売企業に大きな成長をもたらし、世界最大の小売企業が AWS 上でビジネスを展開している理由です。AWS ブースではご紹介してきたデモごとに、ユースケースに最適な生成 AI が選ばれて利用されていることもご覧いただきました。 リテールテック JAPAN において、私たちは AWS が描く小売業界の姿を様々なデモとともに展示しました。ご来場いただけなかった皆さまには、ぜひアーカイブ動画にて AWS ブースの「見て、触れて、体験できる “顧客体験”」をご覧ください。また、6 月 25、2６ 日に開催される AWS Summit Japan 2025 に向けて、リテールテックで展示したデモをバージョンアップしてまいります。次は Summit の会場でお会いしましょう！ イベント案内（閉会しました） 名称：リテールテックJAPAN 2025（第41回流通情報システム総合展） 会期：2025 年 3 月 4 日 (火) ‒ 7 日 (金) 10:00 ～ 17:00（最終日のみ16:30まで） 会場：東京ビッグサイト　東展示棟（AWS ブースは東 3 ホール、小間番号「RT3210」） 主催：日本経済新聞社 イベント公式サイト： https://www.retailtech.jp/

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 5 月 14 日 (水) 19:00-21:30 に Apache Iceberg on AWS ミートアップ を開催します。次世代のデータ活用基盤を支える新しいテーブルフォーマットとして注目を集める Apache Iceberg を、AWS で活用する上でのテクニックを様々な角度から掘り下げて、新たな学びを提供する実践的なセミナーです。 AWS Startup Loft Tokyo とオンラインでのハイブリッド開催ですが、現地でご参加いただいた方向けに、セッション終了後に懇親会も予定しております。ご予定が合う方はぜひ現地でご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年4月7日週の主要なアップデート 4/7(月) Amazon Bedrock announces general availability of prompt caching Amazon Bedrock でプロンプトキャッシング機能の一般提供を開始しました。プロンプトキャッシングでは、繰り返し使用されるプロンプトの入力をキャッシュすることで、リクエストの処理を高速化と、入力の処理に必要な計算リソースが少なくなることによるコスト削減が期待できます。プロンプトキャッシングは現在、AnthropicのClaude 3.5 Haiku、Claude 3.7 Sonnet、Nova Micro、Nova Lite、および Nova Pro モデルで一般提供として利用できます。プロンプトキャッシングのより詳細な内容については、 ドキュメント と ブログ をご参照ください。 Announcing Amazon Nova Reel 1.1 Amazon Nova Reel 1.1 がリリースしました。Amazon Nova Reel 1.1 のマルチショット動画機能には、自動モードと手動モードの2つのモードがあります。自動モードでは、1つのプロンプトを入力し、最大2分までの合計動画時間を指定することで、複数の6秒動画を生成できます。一方、手動モードでは、各6秒ショットに対してテキストプロンプトとオプションの画像を入力できる詳細な制御が可能です。Amazon Nova Reel 1.1 は現在、米国東部（バージニア北部）で利用できます。 Amazon FSx for NetApp ONTAP now supports ONTAP Autonomous Ransomware Protection Amazon FSx for NetApp ONTAP で、ONTAP Autonomous Ransomware Protection（ARP）をサポートしました。ARPは、NetApp ONTAPの機能で、ファイルシステムの異常な活動を積極的に監視し、潜在的な攻撃を検出した際に自動的にONTAPスナップショットを生成することで、より広範なランサムウェアやマルウェア攻撃からビジネスクリティカルなデータを保護します。ARP は、FSx for ONTAP が利用可能なすべてのAWSリージョンのファイルシステムで、追加費用なしでご利用いただけます。 4/8(火) Amazon EC2 C6in instances are now available in AWS Asia Pacific (Osaka) Region Amazon Elastic Compute Cloud（Amazon EC2）C6in インスタンスが大阪リージョンで利用可能になりました。第3世代のIntel Xeonスケーラブルプロセッサーを搭載し、AWS Nitroシステム上に構築されたこの第6世代のネットワーク最適化インスタンスは、第5世代の同等インスタンスと比較して2倍となる最大200Gbpsのネットワーク帯域幅を提供します。 Amazon S3 Tables are now available in four additional AWS Regions Amazon S3 Tables が 大阪リージョンを含む4つのAWSリージョンで新たに利用可能になりました。S3 Tablesは、Apache Icebergサポートを組み込んだクラウドオブジェクトストアで、汎用 S3 バケットに保存された Iceberg テーブルと比較して1秒あたりの処理トランザクション数が最大10倍向上します。 Announcing Amazon Nova Sonic, a new speech-to-speech model that brings real-time voice conversations to Amazon Bedrock 音声理解と生成を1つに統合した新しい基盤モデルの Amazon Nova Sonic を発表しました。Amazon Nova Sonic は、様々な話し方のスタイルの音声を理解し、アメリカ英語やイギリス英語のアクセントで、表現豊かな音声を生成でき、Amazon Bedrock 上でリアルタイムの会話型 AI アプリケーションを構築することを可能にします。さらに、企業データをもとに Retrieval-Augmented Generation（RAG）を使用した関数呼び出しとエージェントワークフローにもアクセスできます。現時点ではアメリカ英語とイギリス英語が対象となっていますが、近日中に他の言語にも対応予定です。 4/9(水) Amazon Q Developer expands multi-language support within the IDE and CLI Amazon Q Developer は統合開発環境（IDE）および Q Developer CLI における多言語サポートを発表しました。サポートされる言語には、中国語、フランス語、ドイツ語、イタリア語、日本語、スペイン語、韓国語、ヒンディー語、ポルトガル語など多数の言語が含まれており、さらに多くの言語が利用可能です。これにより Amazon Q Developer を活用して、システムアーキテクチャの設計、ドキュメントの生成など、開発者がもっとも使いやすい言語で、より自然でスムーズに対話できるようになりました。詳細については こちらのブログ をご参照ください。 Amazon Aurora now supports PostgreSQL 16.8, 15.12, 14.17 and 13.20 Amazon Aurora で PostgreSQL バージョン16.8、15.12、14.17、13.20 をサポートするようになりました。このリリースでは、PostgreSQLコミュニティが2025年2月20日にリリースしたバージョンをサポートしており、PostgreSQLコミュニティによる製品の改善とバグ修正に加えて、Babelfishの新機能など、Aurora 固有のセキュリティと機能の改善が含まれています。詳細については、 リリースノート をご参照ください。また、当該バージョンにおいて、ベクトル埋め込みのための拡張機能である pgvector 0.8.0もサポートしています。これにより、検索拡張生成（RAG）アプリケーションで Aurora を使用する際、フィルター利用時の PostgreSQL クエリプランナーのインデックス選択が改善され、クエリのパフォーマンスの向上と検索結果の品質改善が期待できます。 New Guidance in the Well-Architected Tool 最新のWell-Architectedフレームワークのアップデート内容がWell-Architected Toolで利用可能になりました。このリリースでは、78 の新しいベストプラクティスの更新と改善が含まれており、より安全で、持続可能で、スケーラブルで、回復力のある環境とワークロードを構築するための実用的なガイダンスを提供しています。詳しくは ドキュメント をご確認ください。 4/10(木) Amazon S3 Express One Zone reduces storage and request prices Amazon S3 Express One Zone のストレージ料金が 31%、PUT リクエスト料金が 55%、GETリクエスト料金が 85% 値下げされました。さらに、S3 Express One Zone のデータのアップロードとデータ取り出しに関する 1GB あたりの料金が60%値下げされ、512KB を超えるリクエストだけという制限はなく、すべてのバイトに対してこれらの料金が適用されるようになりました。詳しくは こちらのブログ を参照してください。 Announcing vertical scaling and horizontal autoscaling in Amazon ElastiCache for Memcached Amazon ElastiCache for Memcached が 独自設計型 Memcached に対する垂直スケーリングと水平方向の自動スケーリングに対応しました。手動での介入なしに独自設計されたMemcachedキャッシュの容量を自動的に調整できるようになりました。この機能のリリースにより、ElastiCache for Memcached クラスターのコンピューティングとメモリリソースを動的に調整できるようになり、より大きな柔軟性とスケーラビリティを提供します。また、Amazon CloudWatchメトリクスを使用した水平方向へのスケールインまたはスケールアウトのタイミングを判断することで、低コストで安定した予測可能なパフォーマンスを維持できます。 Introducing two new Amazon EC2 I7ie bare metal instances sizes 2つの新しいEC2 I7ieベアメタルインスタンスの提供開始を発表しました。I7ie インスタンスは、3.2GHz のオールコアターボ周波数を備えた第5世代Intel Xeonスケーラブルプロセッサを搭載しています。metal-24xl と metal-48xl のサイズがあり、それぞれ96 および 192 vCPU を備え、最大 100Gbps のネットワーク帯域幅と 60Gbps の Amazon Elastic Block Store (EBS) 帯域幅を提供します。これらのインスタンスは現在、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、ヨーロッパ（フランクフルト、ロンドン）、およびアジアパシフィック（東京）リージョンで利用可能です。 4/11(金) AWS simplifies Amazon VPC Peering billing AWS リージョン内の異なるアベイラビリティーゾーン（AZ）間の VPC ピアリングの使用状況を、簡単に確認することができるようになりました。これまで、VPC ピアリングの使用量はリージョン内データ転送使用量として記載されており、VPC ピアリングの使用量と料金を理解することが困難でした。今回の変更により、 VPC ピアリングのコストを容易に理解できるようになり、コスト、パフォーマンス、管理のしやすさに基づいて適切なアーキテクチャを選択できるようになります。もちろん、利用料の変更といった影響はありません。 Announcing 223 new AWS Config rules in AWS Control Tower AWS Control Tower がセキュリティ、コスト、耐久性、運用などの様々なユースケースに対応する 223 の追加のマネージドコンフィグルールを Control Catalog でサポートしました。このサポートにより、AWS Control Tower から直接、追加ルールの検索、発見、有効化、管理が可能となり、マルチアカウント環境でより多くのユースケースに対応したガバナンスを実現できます。 新しく OpenSearch Magazine が開設 されました。 OpenSearch は、フルテキスト検索や分析機能を提供するオープンソースの検索エンジンで、ログ監視や、セキュリティ領域での SIEM、生成AI アプリにおける RAG 検索と幅広い活用用途があります。OpenSearch Magazine では、そんな OpenSearch の重要なアップデート情報や活用事例を定期的にお届けするもので、すでに OpenSearch Magazine Vol. 1 はでておりますので、ぜひチェックしてみてください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は、2025 年 3 月に実施した、伊藤忠商事 繊維カンパニーとそのグループ会社 5 社との生成 AI ワークショップの内容をご報告するものです。2024 年には本ワークショップに先立ち、ファッションアパレル事業、ブランドマーケティング事業を手掛ける同社 繊維カンパニーとそのグループ会社に対し、ファッション・アパレル業界での生成 AI 活用事例やユースケースをキャッチアップする勉強会を実施していました。その中で、「技術の進化に驚いた」「前提知識をキャッチアップできた」というお声がある一方で、「自分たちにとって有効なユースケースが何か分からない」「自社として役立つユースケースを特定したい、具体化したい」といったお声も多数いただきました。そういったお客様の声に応えるべく、本ワークショップを企画しました。 生成 AI 活用の実態 総務省が公開している令和 6 年版の 情報通信白書 によると、生成 AI を“使っている”（「過去使ったことがある」も含む）と回答した割合は日本で 9.1 ％であり、他国に比べてとても低い結果となっています。生成 AI を使わない理由として「使い方がわからない」、「自分の生活に必要ない」の 2 つがそれぞれ 40 %以上と高い回答率を得ています。前者については、少しの座学と実際に触って体験してみることで、「一般的な使い方」としては理解して解決しやすい一方、後者については「自分たちの業務に照らしてどう活用できるか」を考える必要があり、ハードル高く感じていらっしゃるお客様も多いのではないでしょうか。今回のワークショップでは、Amazon 流の顧客起点でのアイデア創造フレームワークである “Working Backwards” に則りながら、業務を共にする仲間と一緒に生成 AI 活用ユースケースを考え議論することで、利用シーンの解像度を上げていただくことを目的としています。 ワークショップの概要 アジェンダは、下記の通りです。 AWS の生成 AI 概要、アパレルユースケース / 取り組み事例の紹介 アパレルユースケースデモ – お客様の声を可視化しよう – 生成 AI 時代における顧客起点のサービス企画 – Working Backwards の実践 – AWS の生成 AI 概要、アパレルユースケース / 取り組み事例の紹介 アマゾン ウェブ サービス ジャパン合同会社 アカウントマネージャー 棚橋 里奈 2024 年に実施した勉強会の振り返りとして、AWS における生成 AI の概要、仮想試着などファッション・アパレル業界ならではのユースケース、そして伊藤忠商事 グループ会社における生成 AI 活用の取り組み事例について改めてご紹介しました。その勉強会の参加者アンケートでは、生成 AI の活用シーンとして、1) EC ビジネス / マーケティングへの活用、2) 社内のデータ活用、3) 業務改善 / 効率化、の 3 点について活用できるのではないかとご期待の声が寄せられていました。 アパレルユースケースデモ – お客様の声を可視化しよう – アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 濱上 和也 活用シーン 1) EC ビジネス / マーケティングへの活用 の例としては、2025 年 3 月 4 日 〜 7 日に東京ビッグサイトで開催された、 リテールテックJAPAN においてAWS が展示 していたデモの内容をご紹介しました。具体的には、没入型店舗のショッピング体験を実現する Amazon Beyond 、仮想試着を実現する Virtual Try-All 、手描きのイメージからプロダクトイメージを生成しさらにソーシャルメディアごとのマーケティングキャッチを生成する AWS デモアプリケーションの 3 つです。活用シーン 2) 社内のデータ活用、3) 業務改善 / 効率化の例としては、COACH などのブランドを取り扱う Tapestry 社の事例 を取り上げました。お客様の声を店舗スタッフ経由で年間 30,000 件のフィードバックを音声データとして集め、そのデータを分析することで、お客様のニーズ調査や店舗間在庫の改善に繋げられていることをご紹介しました。また前回の勉強会アンケートにて「監査業務において、ヒアリングしたメモから業務フロー図を生成したい」といったリクエストを受けて、現場での音声でヒアリングした内容を文字起こし、要点を抽出、その要点をもとに業務フロー図として可視化という一連の流れのデモを実施いたしました。デモは、AWS の生成 AIのサンプルソリューションである「 Generative AI Use Cases （略称 GenU ）」を使用し、すでにある機能を組み合わせることで簡単に実現できることをご紹介しました。 生成 AI 時代における顧客起点のサービス企画 – Working Backwards の実践 – アマゾン ウェブ サービス ジャパン合同会社 イノベーションプログラム シニア事業開発マネージャー 櫻井 直子 ここから、生成 AI を活用するユースケースを見つけるためのワークショップに入りました。顧客起点で考え、逆算で仕事を設計するというAmazon のフレームワーク Working Backwards の手法を紹介し、5 つの質問からお客様の体験がどう良くなるのか、ペンと付箋紙を用いて書き出すところから始まりました。そして会社ごとに課題テーマを絞り、プレスリリースのタイトルや内容、想定されるお客様の声を言語化していただきました。書き上げた後には、これによって自社のビジネスや業務をどう変えるのか、どんな付加価値をもたらすのか、会社間でお互いに発表しあうことで、アイデアをさらにブラッシュアップされようとしている様子を伺うことができました。 ワークショップは限られた時間のために、各社が作成したプレスリリースは部分的な仕上がりにとどまりましたが、その内容から PR/FAQ (Press Release and Frequently Asked Questions) の完成形に近づけるべく、AWS 生成 AI サービス PartyRock を利用した「PR/FAQ 作成支援アプリケーション」を利用しました。このアプリケーションにより、プレスリリースのまだ仕上がっていない部分を補完することができ、さらに FAQ やお客様の利用シーンにおけるビジュアルイメージまで生成することができました。これには会場から大きな歓声が上がりました。 お客様の声 伊藤忠商事 繊維カンパニー 繊維デジタル戦略室 若谷様から次のようなコメントを頂戴いたしました。「単なる事例紹介にとどまらず、AWS のメソッドに沿って生成 AI 活用方法を正しく導き出すトレーニングまで経験させて頂き、事業会社各社含め大変為になる時間でした。このノウハウを繊維カンパニー傘下の各社員レベルにまで浸透させ、生成 AI をいかに活用するかを考えることに各自が注力していくように啓蒙したいと思います。」 またアンケートでは、参加者の 7 割以上の方から「次は AWS の生成 AI サービスを実際に触りたい、ハンズオンで体験したい」、3 割以上の方から「個別の導入支援を受けたい」と回答いただきました。 まとめ ワークショップを通じて、各社計 6 つの具体的なユースケースを特定することができました。ユースケースの内訳として、1) EC ビジネス / マーケティングへの活用 に関するものが 1 件、2) 社内のデータ活用 に関するものが 3 件、3) 業務改善 / 効率化 に関するものが 2 件でした。EC サイトに訪れたお客様、自社の営業担当、意思決定者、それぞれを生成 AI で支援する素晴らしい活用アイデアが生まれました。Working Backwards が、生成 AI 活用ユースケースの解像度を上げることに役立つとともに、Working Backwards を進めることそのものにも生成 AI が活用できることを体験いただきました。Working Backwards についての詳細や他社の活用事例について知りたい場合は、 こちらの記事 もあわせてご確認ください。 お客様の声に耳を傾けて、今後も期待に応える企画を考えてご提供していきます。 著者について 櫻井 直子（Naoko Sakurai） 事業開発統括本部 イノベーションプログラム シニア事業開発マネージャー Amazon 社内での取り組みをご紹介しながら、お客様のデジタル・組織変革支援を行っています。好きな （関心ある）AWS サービスは Amazon SageMaker Data Wrangler。     松本 敢大（Kanta Matsumoto） 技術統括本部 ソリューションアーキテクト 普段は小売業・商社のお客様を中心に技術支援を行っています。好きな AWS サービスは AWS IoT Core。趣味はカメラで、動物が好きです。     濱上 和也（Kazuya Hamagami） 技術統括本部 ソリューションアーキテクト 流通・小売・消費財のお客様を担当するソリューションアーキテクトです。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。

本記事は、2025 年 4 月 1 日に公開された Enhance your analytics embedding experience with generative BI capabilities を翻訳したものです。翻訳は Solutions Architect の 守田 が担当しました。 Amazon QuickSight は、AWS の AI を搭載したビジネスインテリジェンス (BI) サービスで、お客様がより迅速にインサイトを得て、より良い意思決定を行うことを支援します。QuickSight の埋め込みを使用すると、カスタマイズされたインタラクティブなビジュアルとダッシュボードを使用して、あらゆるアプリケーションに有益な分析機能を簡単に追加でき、インフラストラクチャを管理する必要なく、低コストで数十万人のユーザーまでスケールできます。 Amazon Q in QuickSight は、ビジネスインテリジェンスに生成 AI を導入し、従業員がデータとやり取りする方法を変革します。具体的には、AI を活用したエグゼクティブサマリー、カスタマイズ可能なデータストーリー、複数のビジュアルを用いて回答するデータ Q&A エクスペリエンス、専門的なスキルを必要としない高度なデータ分析のためのシナリオ機能といった自然言語で利用可能な機能を提供します。 2024 年 4 月に Amazon Q in QuickSight の一般提供を発表し、開発者がデータ Q&A エクスペリエンスをアプリケーションにシームレスに埋め込むことが可能になりました。しかしお客様からは、他の高度な Amazon Q in Quicksight 機能についてもアプリケーションやウェブサイトに埋め込みたいというニーズをいただいていました。 本日、お客様が GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API を使用して、アプリケーションやウェブサイト内の QuickSight に Amazon Q の高度な生成 AI 機能を埋め込めるようになったことを発表できることを嬉しく思います。このローンチにより、お客様は以下のものを埋め込むことができます： ダッシュボード埋め込みとコンソール埋め込みにおける、 エグゼクティブサマリー (Author Pro および Reader Pro 向け) コンソール埋め込みにおける、データストーリー (Author Pro および Reader Pro 向け) コンソール埋め込みにおける、Generative BI ベースのオーサリングと QuickSight のトピック管理 (Author Pro 向け) コンソール埋め込みにおける、Generative Q&A エクスペリエンス この投稿では、ユースケースの例を用いてこれらの新機能を有効にする方法をご紹介します。 ソリューションの概要 Generative BI 機能の埋め込みを有効にするには、 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API を使用する必要があります。またこれらの機能をコンソール埋め込みとダッシュボード埋め込みでユーザーに表示するには、QuickSight Embedding SDK バージョン 2.10 以降を使用する必要があります。 コンソールの埋め込み GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API にて、コンソール埋め込み用のオプションパラメータである ExperienceConfiguration を使用して Generative BI 機能を有効にすることができます。設定が指定されない場合、これらの機能はデフォルトでは無効になっています。 ExperienceConfiguration: { QuickSightConsole: { InitialPath: " <initial path> ", FeatureConfigurations: { AmazonQInQuickSight: { GenerativeAuthoring: { Enabled: true }, ExecutiveSummary: { Enabled: true }, DataStories: { Enabled: true }, DataQnA: { Enabled: true } } } } } } これらの機能をクライアント側で有効にするには、コンソール埋め込み用の QuickSight Embedding JavaScript SDK の contentOptions 内のツールバーオプションで以下を指定します。 false に設定すると、エグゼクティブサマリー、データ Q&A、ビジュアル作成へのアクセスが非表示になります。QuickSight Embedding JavaScript SDK の関数を使用して、カスタムされた UI からフローをトリガーできます。 const contentOptions = { toolbarOptions: { executiveSummary: true, dataQnA: true, buildVisual: true } }; ダッシュボードの埋め込み GenerateEmbedUrlForRegisteredUser API のダッシュボード埋め込み用のオプションパラメータである ExperienceConfiguration を使用することで、Author Pro または Reader Pro ロールを持つユーザーに対してエグゼクティブサマリーを有効にできます。 ExperienceConfiguration: { Dashboard: { InitialDashboardId: <dashboard_id> , FeatureConfigurations: { AmazonQInQuickSight: { ExecutiveSummary: { Enabled: true } } } } } } クライアント側でエグゼクティブサマリーを有効にするには、QuickSight Embedding JavaScript SDK のダッシュボード埋め込みにおいて、 contentOptions のツールバーオプションで以下を指定します。 false に設定すると、エグゼクティブサマリーへのアクセスは非表示になります。QuickSight Embedding JavaScript SDK の関数を使用して、カスタムされた UI からフローをトリガーすることができます。 const contentOptions = { toolbarOptions: { executiveSummary: true } }; ユースケース例 AnyCompany, Inc. は、さまざまな地域で事業を展開し、エンタープライズ、スタートアップ、中小企業 (SMB) などのあらゆる業界セグメントに顧客を持つ架空の独立系ソフトウェアベンダー (ISV) です。これらの様々な顧客の数千人のユーザーが AnyCompany のアプリケーションポータルにアクセスしており、AnyCompany は自社製品に差別化された価値を付加するため、顧客に Generative BI 機能を提供したいと考えています。以下のようなユースケースを実現したいと考えています： 複数のビジュアルを用いて回答するデータ Q&A の有効化 より迅速なダッシュボードの構築 エグゼクティブサマリーによる迅速なインサイト取得 説得力のあるストーリーの作成 複数のビジュアルを用いて回答するデータ Q&A の有効化 AnyCompany は、埋め込みコンソールとダッシュボードの両方でデータ Q&A を顧客に提供したいと考えています。データ Q&A は、AI が生成した質問を提案し、データのプレビューを提供することで、データの内容を素早く理解し、質問の表現方法や特定のトピックからどのような回答が得られるかを把握するのに役立ちます。回答には、関連データを示す複数のビジュアルが含まれており、データに対する信頼性と理解を深めるための追加のコンテキストを提供します。「最も優れた製品は何か」といった漠然とした質問や、単一の顧客や製品名といったシンプルな単一値のクエリでも、Amazon Q は質問に関連するデータを見つけ出し、リクエストに一致する複数のデータがある場合は代替案も提示します。 QuickSight のコンソールで、 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration パラメータで DataQnA を有効にします。また、QuickSight Embedding JavaScript SDK 内の contentOptions 配下のツールバーオプションで dataQnA を true に設定します。 より迅速なダッシュボードの構築 AnyCompany は、顧客が手作業で行うポイント＆クリックの一連の手順を自然言語クエリに置き換えることで、どのフィールドを選択し、どのフィルターを追加し、どの種類の可視化を選ぶかを考えることなく、目的のタスク (例えば、2023 年の月次単位の売上を可視化するなど) に集中できるようにしたいと考えています。また、顧客が複雑な計算を簡単に構築できるようにしたいと考えています。計算は、ほとんどのビジネスアナリストにとって BI スキルの習得の中で最も複雑で難しい部分であり、数ヶ月から数年の経験を必要とします。QuickSight の Generative BI を用いた計算の構築機能を使用すると、ビジネスアナリストは簡単な自然言語で望む結果を記述することで、 QuickSight の計算フィールドを構築でき、複雑な計算を数秒で作成できます。 QuickSight コンソールで、 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration パラメータで GenerativeAuthoring を有効にします。また、QuickSight Embedding JavaScript SDK 内の contentOptions のツールバーオプションで buildVisual を true に設定します。 エグゼクティブサマリーによる迅速なインサイトの取得 AnyCompany は、エグゼクティブサマリーを使用してダッシュボードから即座にインサイトを生成できるようにしたいと考えています。エグゼクティブサマリーを使用することで、データの傾向や変化を比較し、自然言語を使用してビジネスパフォーマンスを素早く理解し、さらなる調査が必要な領域を特定することができます。 QuickSight コンソール埋め込みとダッシュボード埋め込みの GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API で、Experience Configuration パラメータの ExecutiveSummary を有効にします。また、QuickSight Embedding JavaScript SDK 内の contentOptions のツールバーオプションで、 executiveSummary を true に設定します。 説得力のあるストーリーの作成 AnyCompany は、顧客がシンプルな自然言語のプロンプトを使用して、共有しやすいドキュメントやプレゼンテーションを作成できるようにしたいと考えています。これにより、チームの意思決定に必要なインサイトをステークホルダーにどのように提示するかを考える時間を節約できます。顧客は、分析したい特定のビジュアルを選択し、全体的なストーリー（例えば、「主要製品と顧客に注目しながら現在の売上実績を分析し、来年の売上成長戦略を提案する」）を説明すると、Amazon Q がデータから得られた知見を説明し、ビジネス成長のための提案を含むストーリーの草案を作成します。追加のビジュアル、テキスト、画像、テーマでストーリーをカスタマイズし、Amazon Q を使用してテキストを要約または書き直すことで、共有可能な洗練されたドキュメントを作成できます。 QuickSight コンソールで、 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API の Experience Configuration パラメータで DataStories を有効にします。 まとめ この投稿では、Amazon Q を使用して、QuickSight で利用可能になった新しいコンソールとダッシュボードの埋め込みの機能をご紹介しました。QuickSight の 30 日間の無料トライアル をぜひお試しください。 著者について Mayank Agarwal は、AWS のクラウドネイティブでフルマネージドな BI サービスである Amazon QuickSight のプロダクトマネージャーです。埋め込み分析機能と開発者エクスペリエンスを担当しています。彼はハンドヘルドデバイスの組み込みソフトウェアエンジニアとしてキャリアをスタートしました。QuickSight を担当する前は、Credence ID でエンジニアリングチームをリードし、AWS サービスを使用したカスタムモバイル組み込みデバイスと Web ソリューションを開発していました。これにより、政府機関、医療、取引セキュリティアプリケーション向けの生体認証の登録と識別を迅速で直感的、かつコスト効率の高いものにしました。 Jackson Dowden は、シアトルを拠点とする Amazon QuickSight のアソシエイトスペシャリストソリューションアーキテクトです。AWS のパートナーソリューションアーキテクトとしてキャリアをスタートし、現在は独立系ソフトウェアベンダー (ISV) のお客様の Amazon QuickSight のユースケース実装支援に注力しています。 Sindhu Chandra は、AWS の Amazon QuickSight のシニアプロダクトマーケティングマネージャーで、マーケティングとテクノロジーの分野で 10 年以上の経験を持っています。現職以前は、Amazon、Uber、Google などのテクノロジー企業でマーケティングポジションを担当し、クロスチャネルマーケティング戦略を主導してきました。B2B マーケティングをより親しみやすくし、インクルーシブなマーケティング施策を推進することに情熱を注いでいます。仕事以外では、愛犬と遊んだり、さまざまな産地のコーヒーを淹れたりすることを楽しんでいます。

みなさん、こんにちは。ソリューションアーキテクトの榎本です。OpenSearch Magazine の第 1 号をお届けいたします。本号では OpenSearch Service の最近のアップデート情報と、OpenSearch 最適化インスタンスタイプのご紹介、OpenSearch Project で現在開発が進められている OSS 版 OpenSearch 3.x 系のロードマップアイテムについてお話いたします。 OpenSearch Magazine は、 Amazon OpenSearch Service およびオープンソース版 OpenSearch の最新動向をキャッチアップいただくべく開設されました。開設の経緯や Amazon OpenSearch Service の概要につきましては、「 OpenSearch Magazine 開設のお知らせ 」よりご確認いただけます。 サービスアップデート 直近でリリースされた、 Amazon OpenSearch Service に関する重要なアップデートについて解説していきます。 マネージドクラスターにおいて、OR2 および OM2 インスタンスタイプを新たにサポート Amazon OpenSearch Service に、新たに OR2 と OM2 インスタンスタイプが加わりました 。OR2 は東京リージョンを含む 10 リージョンで利用可能です。OM2 は記事執筆時点では、東京・大阪リージョンでは未提供です。 OR2 / OM2 は OpenSearch 最適化インスタンスファミリーのメンバーであり、2023 年 11 月に提供が開始された OR1 インスタンスタイプの後継といえます。OR2 はメモリ最適化インスタンスタイプと同様の vCPU:メモリ比率が 1:8 のインスタンスタイプです。OM2 は汎用インスタンスタイプと同様の、vCPU:メモリ比率が 1:4 のインスタンスタイプです。OR2 / OM2 ともに、 OR1 と同様、 S3 ベースのマネージドストレージとローカルストレージを組み合わせた独自のインフラストラクチャを採用しています。従来のインスタンスファミリーと比較してインデックス作成スループットに優れており、ログ分析といった、大量のデータを効率よく取り込む必要のあるユースケースに適しています。OR2 は R7g からの移行で最大 70%、OR1 からの移行で最大 26% のスループット向上が期待できます。OM2 は M7g からの移行で最大 66%、OR1 からの移行で最大 15% のスループット向上が期待できます。 OR2 は OR1 と比較して 4.3% コストが低く、コストパフォーマンスにも優れています。OR1 ほどのメモリが不要な場合は、OM2 に移行することで 27.21% のコスト削減が期待できます。詳細な料金については、「 Amazon OpenSearch Service の料金 」をご確認ください。 OpenSearch 最適化インスタンスタイプは、特性を理解し適切なユースケースで採用することで大きな力を発揮します。本号では、Hot Topic のセクションにて、最適化インスタンスタイプの効果的な活用方法について解説していきます。 Amazon Bedrock Knowledge Bases が OpenSearch マネージドクラスターをサポート Amazon Bedrock Knowledge Bases は、 Amazon Bedrock が提供する基盤モデルを活用した、RAG (検索拡張生成)を実行するフルマネージドサービスです。 Amazon S3 などに格納されたデータのクロールおよび取得、変換、埋め込みの生成、ベクトルストアへの保存、LLM と連携した検索および回答生成まで、一連のフローをフルマネージドで提供します。 従来、Bedrock Knowledge Bases は Amazon OpenSearch Serverless をベクトルストアとしてサポートしていましたが、この度 Amazon OpenSearch Service のマネージドクラスターも サポート されました。OpenSearch Serverless では対応できなかった Sudachi プラグイン の利用や カスタムパッケージ 機能(辞書、シノニム)による 、ハイブリッド検索における全文検索周りの精度改善を図ることができます。また、 ディスクベースのベクトル検索 や UltraWarm 上のベクトルインデックスに対するベクトル検索といったコスト最適化のための機能も活用することが可能です。OpenSearch マネージドクラスターは利用者がインスタンスタイプ、インスタンスサイズ、ノード数といったスケール設定をコントロールできるため、ベクトルストアにかかるコスト制限にも役立ちます。 なお、本号執筆時点では、Amazon S3 のみをデータソースとしてサポートしています。既存の OpenSearch Serverless への切り替えについては、事前に検証してから臨まれることをお勧めいたします。その他利用上のポイントについては、「 ナレッジベース用に作成したベクトルストアを使用するための前提条件 」および「 Amazon Bedrock ナレッジベースで OpenSearch マネージドクラスターを使用するために必要な前提条件とアクセス許可 」をご確認ください。 Amazon OpenSearch Service ワークショップを公開 Amazon OpenSearch Service 検索ワークショップ を公開しました。検索ワークショップは、日本語ユーザーをターゲットとした、OpenSearch の基本から最新の検索機能まで、段階的に学習することが可能なコンテンツです。Jupyter Notebook 形式で提供される「ラボ」を実行していくことで、OpenSearch を使用した検索機能の使い方を無理なく身に付けることができます。ノートブック中の解説は全て日本語で記載されており、使用するデータセットの多くも日本語を含む多言語対応のものを採用しています。Jupyter Notebook の内容は こちら よりご確認いただけます。ワークショップの詳しい紹介については、「 Amazon OpenSearch Service による検索ワークショップ(日本語版)のご紹介 」をご覧ください。 OpenSearch Project Tokyo が発足 OpenSearch コミュニティの拡大を受けて、「 OpenSearch Project Tokyo 」が発足しました。このユーザーグループは、OpenSearch に関心を持つエンジニアが集まり、知識や経験を共有する場です。 Meetup.com を通じて定期的なミーティングを開催する予定です。OpenSearch に興味のある方は、ぜひご参加ください。 Hot Topic OR2/OM2 リリースを記念して、OpenSearch 最適化インスタンスの特性を振り返る OpenSearch 最適化インスタンスタイプは、インデックス作成スループットに特化した OpenSearch Service 独自のインスタンスタイプです。現在、OR2/OM2/OR1 の 3 種類のインスタンスタイプが利用可能です(東京では OR2/OR1 のみ)。OpenSearch 最適化インスタンスは、インデックス作成スループットの向上に加えて、以下のメリットを提供します。 レプリカ保持にかかるコストの削減 インデックス障害時の自動リカバリ ノードリカバリ時、構成変更によるシャードリバランシングの抑制 自動スナップショット取得の高速化 これらのメリットは、OpenSearch の機能である Remote Backed Storage および Segment Replication によるものです。 Remote Backed Storage は、OpenSearch に格納されたドキュメントをニアリアルタイムに Amazon S3 などのオブジェクトストレージに同期する機能です。従来型のインスタンスは、データの冗長性を確保するためには、最低 1 つのレプリカをノード上のストレージに配置する必要がありました。最適化インスタンスタイプは S3 にレプリカを配置することでデータの冗長性を担保できるため、レプリカ保持にかかるコンピューティングリソースのコストを削減することが可能となりました。 また、S3 に常に最新のデータが保持されることで、リカバリ処理やシャードのリバランス処理、スケール処理も最適化されました。従来型のインスタンスタイプでは、ノード間でデータコピーを行うことでリカバリやリバランスを行っていました。対して最適化インスタンスタイプでは、S3 から最新のデータを取得する形でリカバリやリバランスを実行することで、データコピーの負荷を削減しています。 Remote Backed Storage と Segment Replication を併用することで、ノードと S3 間のデータコピーを効率化しています。従来型のインスタンスタイプでは、ノードに書き込まれたデータは、ドキュメント単位の論理同期の仕組みを採用していました。対して、最適化インスタンスタイプでは、セグメントと呼ばれる物理ファイル単位でデータを同期します。この仕組みにより、データ同期を効率よく行えるようになりました。最適化インスタンスタイプのスループットの高さは、S3 へ Segment Replication の仕組みで効率よくレプリカデータをコピーするアーキテクチャーに支えられているものです。 これまでに説明した通り、最適化インスタンスファミリーは従来型と比較して優れている点が多く存在します。一方で、インスタンスファミリー固有の 制約 には注意が必要です。最適化インスタンスタイプを使用する場合、データ登録から実際に検索可能になるまでに 10 秒程度要す場合があります。これは、refresh_interval パラメーターの最低値が 10 秒であるところからきています。この制約は、データ更新が頻繁に行われる検索ユースケースにおいて、採用可否を慎重に検討すべきポイントとなります。 逆に、秒単位での取り込み要件がないユースケース、例えばニアリアルタイムデータ分析や RAG などでは、採用しやすいといえます。直近で公開された株式会社タップルの 事例 でも、OR1 インスタンスがインフラストラクチャのコスト削減に貢献しました。 また、開発環境や社内業務で使用する検索エンジンといった、ノード障害によるダウンタイムが許容できるようなユースケースでは、最適化インスタンスタイプを思い切ってシングルノード構成で使う選択肢もあります。従来型のインスタンスタイプは、シングルノード構成は障害時の データロス リスクがあり、障害時はスナップショットを用いた人手による復旧操作が必要です。一方、最適化インスタンスタイプは S3 上のデータを使用したデータリカバリ処理機能が備わっているため、データの復旧処理も自動で行われるなど、運用上のメリットがあります。 最適化インスタンスタイプの特性を理解し活用することで、コストパフォーマンスと運用の省力化を最大化することができます。現状のワークロードに適用することができないか、一度検討してみてください。 OpenSearch Project の最新動向 – 3.x でアーキテクチャーはどう変わるか？ OpenSearch Service のコアエンジンである OpenSearch は、3/18 に 3.0.0-alpha1 がリリースされました。現在 3.0.0-beta1 のリリース準備を進めており、4 月後半から 5 月前半にかけて GA となる予定です。 OpenSearch 3.x 系ではアーキテクチャーにかかわる重要なアップデートが予定されています。本号では、 重要なアップデートにフォーカスして、OpenSearch Project のロードマップ情報をベースに解説していきます。 注意: 以降の案内は、 Amazon OpenSearch Service の今後の計画ではなく、オープンソース版 OpenSearch の開発ロードマップについてのものであることをご承知おきください。 アーキテクチャーのアップデート OpenSearch 3.x ではアーキテクチャーの大幅なアップデートが予定されています。 コンピュートとストレージの分離 、 インデックス作成と検索ワークロードの分離 など、コンポーネントの疎結合化が進められています。ロギングやルールベースのフィルタリング機能を提供する Traffic Gateway といったコンポーネントの開発も始まっており、よりクラウドネイティブなアーキテクチャーに変化していく予定です。 また、コストパフォーマンス向上のための改善も行われる予定です。 書き込み可能な Warm インデックス (Writable Warm Index) はその筆頭といえます。先に紹介した Remote Backed Storage はプライマリストレージをノードのローカルディスク、レプリカストレージをオブジェクトストレージとしていますが、Writable Warm Index はプライマリストレージをオブジェクトストレージにしています。ノードのローカルディスクは、ノードに送られたデータをオブジェクトストレージに同期するまでのバッファ、あるいは検索実行時のキャッシュとして活用することで、より柔軟な構成を実現可能です。 また、GRPC [ #16710 / #16711 ] や Protobuf [ #6844 / #10684 ] のサポートといった、内部的な改善も行われています。 データ取り込みパイプラインの拡充 OpenSearch 3.x では、インデックス構築やデータの取り込みを効率化する仕組みが導入される予定です。 ベクトルデータベースとしては、 Remote Vector Index Build 機能が追加される予定です。同機能を活用すると、OpenSearch クラスターからリポジトリにアップロードされたベクトルデータをもとに、専用のビルドサービスでグラフの作成を実施することができます。本体のクラスターの負荷を削減するだけでなく、リモートサービスのノードを GPU インスタンスなどで構成することで、ベクトルインデックスの構築処理を高速化することも可能です。 更に、より効率よくデータを取り込むために、従来の Push 型のデータ取り込みに加えて、 Apache Kafka や Amazon Kinesis Data Streams などのストリーミングプラットフォームからデータを取り込む Pull 型のデータ取り込み もサポートする予定です。Pull 型のデータ取り込みでは OpenSearch クラスターの内部でストリームのコンシューマーを実行する方向で 設計 が進められています。これにより、ストリームデータの取り込みをより容易に行うことが可能となります。 異なるデータストアからのデータ取り込みも計画されています。Data Prepper と呼ばれる ETL パイプラインツールでは、Amazon Aurora および RDS の MySQL と PostgreSQL エンジンをソースとしてサポートする計画があります。本機能のサポートによって、リレーショナルデータベースから OpenSearch へのデータ同期パイプライン構築のハードルが下がることが期待できます。 OpenSearch Project ロードマップの確認方法 こうしたアーキテクチャーの改善の他、 シャードのオンライン分割 やポイントインタイムリカバリの実現を見据えたスナップショットの改善、検索における Join のサポートや クエリの最適化 、 Star Tree インデックスの改善 による分析処理のパフォーマンス向上など、機能やパフォーマンスにかかわるアップデートも予定されています。 OpenSearch Project のロードマップは、OpenSearch Project サイトおよび Github 上で公開されています。OpenSearch のロードマップについてご興味がございましたら、是非これらの情報をご確認ください。 https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/ https://github.com/orgs/opensearch-project/projects/206 まとめ 本号では、Amazon OpenSearch Service の最新アップデートとして、OR2/OM2 インスタンスタイプの追加、Bedrock Knowledge Bases のマネージドクラスターサポート、検索ワークショップの公開、そして OpenSearch Project Tokyo の発足についてお伝えしました。また、OpenSearch 最適化インスタンスタイプの特性と活用法、そして OpenSearch 3.x で予定されているアーキテクチャーのアップデートについて解説いたしました。 次号でも、新機能のご紹介や実践的な機能解説をお届けしてまいります。どうぞご期待ください。 著者について ソリューションアーキテクト 榎本 貴之(Takayuki Enomoto) (X: @tkykenmt) 2015 年に AWS Japan にクラウドサポートエンジニアとして入社し、Amazon OpenSearch Service を中心に顧客の課題解決を担当していました。2021 年より現職のスペシャリスト SA として、Amazon OpenSearch Service および Amazon MSK を中心とした、お客様システムにおける検索、分析、ストリーミング処理の導入および活用を支援しています。

OpenSearch は、フルテキスト検索や分析機能を提供するオープンソースの検索エンジンです。 OpenSearch Project によって開発され、Apache 2.0 ライセンスのもとで提供されています。2021 年に 発足 した OpenSearch Project は、2022 年にバージョン 2.0 がリリースされて以降、6 週間ごとのアップデートサイクルの元、19 のマイナーバージョンをリリースしてきました。2024 年にはLinux Foundationへの移管も完了し、2025 年 5 月にはバージョン 3.0 の一般提供が予定されています。 近年、OpenSearch はベクトルデータベースとしても注目されています。テキストや画像を多次元ベクトルとして扱うベクトル検索の機能をサポートすることで、従来のキーワード検索では難しかった、ユーザーの意図をより正確に捉えた、意味的な近さに基づく検索結果を提供できるようになりました。 Amazon Bedrock Knowledge Bases などの 検索拡張生成 (RAG) アプリケーションでも、ベクトルストアとして OpenSearch が活用されています。 こうした頻繁なアップデートは、最新技術やユーザーニーズに対応するために重要ですが、ユーザーにとっては最新情報のキャッチアップが課題となっています。OpenSearch Magazine は、ユーザーの皆さんに、重要な OpenSearch のアップデートをお届けし、より効果的に OpenSearch を活用いただくことを目指して開設されました。本号では、OpenSearch およびマネージドサービスである Amazon OpenSearch Service の概要を紹介します。 Amazon OpenSearch Service の紹介 Amazon OpenSearch Service は、OpenSearch クラスターのデプロイ、運用を容易に行うことができるマネージドサービスです。OpenSearch Service を利用することで、ユーザーはインフラストラクチャのプロビジョニング、ソフトウェアの導入やパッチ適用、障害検出とリカバリ、バックアップやモニタリングの設定といった管理タスクから解放され、OpenSearch を活用した検索・分析機能の開発に集中することができます。 主要機能は以下の通りです。詳細な機能リストは 「OpenSearch が提供する機能にはどのようなものがありますか?」 よりご確認ください。 フルテキスト検索 : Web サイトやアプリケーションに高度な検索機能を追加し、ユーザー体験を向上 ベクトル検索 : テキストや画像などのデータを意味的類似性で検索し、生成 AI と組み合わせて直感的な検索体験を提供 ハイブリッド検索: テキスト検索やベクトル検索など、複数の検索を組み合わせて実行 データ分析・可視化 : アプリケーションやインフラのログを収集。全文検索やフィルタ機能を活用した柔軟な分析、 OpenSearch Dashboards を使用した可視化を実現 セキュリティ分析 : セキュリティログに対してルールベースの分析を行い、潜在的な脅威や異常なアクティビティを特定。 異常検出・通知: 収集したログ等のデータに対して機械学習ベースの異常検出を実行。検出された異常は、 Amazon SES や Amazon SNS 、Webhook などの手段を用いて通知可能 Amazon OpenSearch Service は、複数のアベイラビリティゾーンにインフラストラクチャとデータを分散配置することで、 99.9% の可用性を提供します。この可用性を達成するための詳細な ベストプラクティス も公開しています。さらに、 Multi-AZ with Standby 機能を使用することで、最大で 99.99% まで可用性を高めることも可能です。クラスター内のノードは最大 1,002 台まで、ストレージは最大 25 PB まで、オンラインで 拡張 可能です。 きめ細かなアクセスコントロール 機能の提供、暗号化への対応、VPC 接続のサポート、 AWS IAM との統合など、セキュリティ要件へ対応するための各種機能を備えています。 Amazon CloudWatch と統合されており、 トラブルシューティング やスケールの計画に必要なメトリクス情報も標準提供されています。 最近の活用例 OpenSearch Service は、エンターテイメント、旅行、E コマースなど様々な分野で活用されています。各分野においてどのように OpenSearch Service が活用されているのか、最近の具体的な事例を元に紹介していきます。 Amazon Prime Video: スポーツコンテンツ検索の高度化 動画ストリーミングサービスを提供する Amazon Prime Video は、Amazon OpenSearch Service の AI/ML 機能を活用し、スポーツコンテンツ向けの検索体験を改善しました。 Amazon SageMaker でホストされたカスタムテキスト埋め込みモデルと Amazon OpenSearch Service のベクトル検索機能を組み合わせることで、略語やニックネームを含む多様なクエリに対しても、ユーザーの意図を正確に把握した、関連性の高いスポーツコンテンツを表示できるようになりました。検索機能の改善により、無関係なコンテンツの表示減少を実現し、スポーツファンが求める生中継や今後の試合をスムーズに発見できるようになりました。この結果、検索からの視聴・購入・サブスクリプション数が統計的に有意に増加しました。以下のリンクより、取り組みの詳細をご覧いただけます。 Amazon Prime Video advances search for sports using Amazon OpenSearch Service ( AWS Big Data Blog ) Airbnb: 埋め込みプラットフォームにおける OpenSearch の活用 民泊仲介サービスを提供する Airbnb は、Amazon OpenSearch Service を活用することで、数百万件の宿泊施設から「海が見える」「ペット可」「静かな」といった多様な条件に対応する直感的な検索を実現しました。物件の説明文や写真、位置情報、アメニティ情報といった情報をベクトルに変換し、OpenSearch Service のベクトルインデックスに格納、検索時には、ユーザークエリもベクトル化することで、意味的に類似した物件の検索も可能となりました。これにより、従来のキーワード検索では難しかった「雰囲気」や「体験の質」も考慮した検索を提供することができ、予約完了率とユーザー満足度が向上しました。以下のリンクより、取り組みの詳細をご覧いただけます。 Moutupsi Paul, Xiaotang Wang & Amulya Sharma – Airbnb Embedding Platform (Youtube) OfferUp : マルチモーダル検索の導入によるエンゲージメントの改善 スマートフォンアプリを通じて個人間の取引を支援するOfferUp は、月間数百万件の新規出品が行われる米国最大級のマーケットプレイスプラットフォームです。OfferUp は、 Amazon Bedrock と OpenSearch Service を活用したマルチモーダル検索を導入し、テキストと画像を組み合わせた商品探しを実現しました。その結果、ユーザーによ る近隣エリアの商品発見率が 54% 向上し、検索意図に合った商品のヒット率が 27% 改善しました。ユーザーが最初の検索で希望の商品をすぐに見つけられるようになったことで、エンゲージメントと取引成立率も向上しました。以下のリンクより、取り組みの詳細をご覧いただけます。 OfferUp improved local results by 54% and relevance recall by 27% with multimodal search on Amazon Bedrock and Amazon OpenSearch Service ( Amazon Web Services ブログ ) AWS サービスとのネイティブ統合 OpenSearch Service は、いくつかの AWS サービスによってネイティブサポートされています。ネイティブ統合機能を活用することで、開発者は個別に連携機能を実装、運用、メンテナンスすることなく、本来のアプリケーション価値創出に注力することができます。代表的な連携サービスについて解説します。 Amazon Bedrock Knowledge Bases と連携した RAG アプリケーションの構築 Amazon Bedrock Knowledge Bases は、企業のデータソースを生成 AI アプリケーションに接続し、最新かつ関連性の高い情報に基づいた回答を生成するマネージドサービスです。Amazon Bedrock Knowledge Bases は、データの取り込み、テキストのチャンク分割、ベクトル埋め込みの生成、インデックス作成、検索リクエストの処理、フィルタリングおよび回答の生成といった RAG アプリケーションに必要な機能をフルマネージドで提供します。これにより、開発者は RAG アプリケーションを活用したシステムの構築に集中できます。 Amazon Bedrock Knowledge Base は、ベクトルストアとして OpenSearch をサポートしています。OpenSearch をベクトルストアとして使用することで、セマンティック検索とキーワード検索を組み合わせたハイブリッド検索が可能となり、より高精度な検索結果を得ることができます。さらに、圧縮されたバイナリベクトルを活用することで、必要とするリソースを削減することが可能です。プラットフォームとして Amazon OpenSearch Serverless  を選択することで、インフラ管理の負担なくスケーラブルな RAG ソリューションを実装可能です。以下のリンクより、詳細をご覧いただけます。 Amazon Titan Text Embeddings V2、Amazon OpenSearch Serverless、および Amazon Bedrock Knowledge Bases における バイナリ埋め込みを使用した費用対効果の高い RAG アプリケーションの構築 ( Amazon Web Services ブログ ) ニアリアルタイムのデータ取り込み・分析・可視化 Amazon OpenSearch Service とネイティブ統合されたサービスを活用することで、発生したデータを素早く OpenSearch Service に取り込み、分析・可視化することが可能です。運用上の洞察を得るためのダッシュボード作成、異常検出のためのアラート設定、ビジネスインテリジェンスのためのデータ分析など、様々なユースケースに対応可能です。 Amazon OpenSearch Ingestion は、OpenSearch Project が提供する Data Prepper をベースにしたデータ収集、変換、強化、および配信機能を提供するフルマネージドサービスです。ログ、メトリクス、トレースなどの様々なデータに対応し、データ正規化、フィルタリング、エンリッチメントといった変換処理をサポートします。スケーラブルかつ高い可用性を提供しており、インフラストラクチャの管理を行うことなく、大規模なデータ取り込みパイプラインを運用できます。複数の OpenSearch クラスターへの分岐配信もサポートしているため、クラスター単位の Blue/Green による入れ替えなどでも有用です。後述する Amazon DynamoDB や Amazon DocumentDB との Zero ETL 統合でも、OpenSearch Ingestion が活用されています。 Amazon Data Firehose は、ストリーミングデータをノーコードでリアルタイムで配信するフルマネージドサービスです。設定次第で、データをバッファに可能な限り蓄積して効率よく配信することも、可能な限り素早く配信することも可能です。 AWS Lambda と連携したデータの変換機能も提供しています。ストリーミングデータの Amazon S3 への配信がポピュラーなユースケースですが、OpenSearch Service ともネイティブ統合されており、コンテナ上で実行されるアプリケーションのログを Fluent Bit から OpenSearch Service に送信する際のバッファ層として用いられることもあります。 各種ログの収集、閲覧機能を提供する Amazon CloudWatch Logs は、サブスクリプションフィルターと呼ばれる機能を通して、ログを OpenSearch Service に配信可能です。アプリケーションログ、システムログ、AWS サービスログを OpenSearch Service にニアリアルタイムに転送することで、リアルタイムな分析と可視化が可能になります Zero ETL を活用した異なるデータソースからのシームレスなデータ連携 Zero ETL は、データの抽出、変換、ロード (ETL) プロセスを自動化し、データソースからターゲットへのデータ移動をシームレスに行う機能です。従来のETLプロセスでは、データの移動と変換に時間とリソースを要し、データの鮮度が損なわれる課題がありました。Zero ETLはこれらの課題を解決します。Amazon OpenSearch Service は複数のAWSサービスとの Zero ETL 統合をサポートしており、異なるソース上のデータに対する柔軟な検索、分析、可視化、モニタリングを容易にします。 Amazon DocumentDB (with MongoDB compatibility) との Zero ETL 統合 : Amazon DocumentDB のデータを OpenSearch Service に自動的に同期し、高度な検索と分析機能をデータベースに追加できます。これにより、複雑なETLパイプラインを構築することなく、ドキュメントデータの全文検索や分析が可能になります。 Amazon DynamoDB との Zero ETL 統合 : DynamoDB テーブルのデータを OpenSearch Service に自動的にレプリケートし、NoSQL データに対する高度な検索機能と分析機能を提供します。これにより、DynamoDB の優れたスケーラビリティと OpenSearch の強力な検索機能を組み合わせたソリューションが実現します。 Amazon S3 との Zero ETL 統合 : S3 バケット内のデータを OpenSearch Service に取り込むことなく、データレイクに保存されたデータに対して直接分析を行い、結果を可視化することができます。必要に応じて一部のデータを OpenSearch に取り込むことで、高速な全文検索を行うことも可能です。 Amazon Security Lake との Zero ETL 統合 : Security Lake 上のデータを取り込むことなく OpenSearch Service からダイレクトに分析することができます。 Amazon CloudWatch Logs との統合分析エクスペリエンス : CloudWatch Logs に格納されたログデータを取り込むことなく、 OpenSearch Service からダイレクトに取得し、可視化や分析を行うことが可能です。 Amazon OpenSearch Service を活用したソリューション OpenSearch を効率的に活用するために、AWS から実用的なソリューションが提供されています。以下では、代表的な 3 つのソリューションとその特徴を紹介します。 SIEM on Amazon OpenSearch Service SIEM on Amazon OpenSearch Service は、セキュリティ情報とイベント管理 (SIEM) のためのオープンソースソリューションです。 AWS WAF 、 AWS CloudTrail 、 VPC フローログ など、 30 種類以上の AWS サービスからセキュリティログを自動収集・分析し、セキュリティインシデントの検出と対応を支援します。事前設定されたダッシュボードやアラートルールにより、セキュリティ監視環境を迅速に構築できます。本ソリューションは様々な企業で実際に活用されています。株式会社ココナラは、本ソリューションを導入することで、 セキュリティログの可視化と分析を効率化 しました。ソリューションの ワークショップ も提供されており、実際の利用イメージをつかむことができます。 Centralized Logging with OpenSearch Centralized Logging with OpenSearch は、AWS リソースからのログを一元的に収集、分析、可視化するためのソリューションです。アプリケーションパフォーマンス、運用最適化、トラブルシューティングなど、広範な目的に対応したログ収集をサポートします。付属の 管理 UI から、OpenSearch クラスターの管理、ログ収集パイプラインのセットアップが行えます。EC2 や EKS 環境への Fluent Bit の導入サポート機能や、syslog 収集用の syslog サーバーの作成など、アプリケーションログを収集するためのリソース作成も手助けしてくれます。 ソースコード が公開されており、利用者自身によるカスタマイズも可能です。詳細な機能や想定コストについては 実装ガイド をご覧ください。また、 ワークショップ で実際に本ソリューションを体験することが可能です。ソリューションアーキテクトによる 解説 も合わせてごらんください。 Migration Assistant for Amazon OpenSearch Service Migration Assistant for Amazon OpenSearch Service は、既存のセルフマネージド Elasticsearch または OpenSearch クラスターから Amazon OpenSearch Service へのマイグレーションを簡素化するソリューションです。メタデータ移行、ドキュメントの増分同期、差分チェック機能、プロキシによる新旧クラスター双方へのトラフィック配信、トラフィックの本番切り替えといった移行に欠かせない機能を提供します。詳細な利用方法については 実装ガイド をご覧ください。 サンプル実装 アプリケーション実装に役立つサンプルをご紹介します。これらのサンプルは実践的なユースケースを想定して作成されたものです。 AWS CDK や AWS CloudFormation テンプレートで提供されており、素早くサンプルを準備可能です。是非お試しいただき、ご自身のプロジェクトにおける検索機能の実装にお役立てください。 OpenSearch Intelligent Search JP OpenSearch Intelligent Search JP は、日本語テキストに対応した検索機能を実装するためのサンプルです。形態素解析による日本語の分かち書き処理や同義語辞書の活用方法が実装されています。E コマースサイトや企業内文書検索など、日本語コンテンツを扱うアプリケーションの実装上のエッセンスが含まれています。 QA with LLM and RAG QA with LLM and RAG は、Amazon SageMaker、Amazon OpenSearch Service、Streamlit、LangChain を組み合わせた質問応答ボットの実装例です。OpenSearch がベクトルデータベースとして機能し、ドキュメントの意味検索を担当します。ユーザーからの質問に対して関連性の高いドキュメントを OpenSearch から検索し、それをコンテキストとして LLM に提供することで、正確で根拠のある回答を生成します。複数の PDF ドキュメントからの情報抽出と質問応答の実装方法が詳細に解説されています。ソリューションの概要については Blog 投稿「 Amazon SageMaker、Amazon OpenSearch Service、Streamlit、LangChain を使った質問応答ボットの構築 」も合わせてごらんください。 AI Search with Amazon OpenSearch Service AI Search with Amazon OpenSearch Service は、 Build next-gen search with Amazon OpenSearch Service ワークショップで使用されている生成 AI と OpenSearch を組み合わせた検索システムの実装例です。LLM を活用して自然言語クエリの理解や検索結果の要約生成を行う方法が示されています。RAG パターンの実装により LLM の回答精度を向上させる手法や、ベクトル検索とキーワード検索を組み合わせたハイブリッド検索の実装方法も含まれています。 AI ショッピングアシスタント AI ショッピングアシスタント は、E コマース向けの生成 AI 搭載ショッピングアシスタントソリューションです。OpenSearch のベクトル検索機能と生成 AI を組み合わせ、顧客の自然言語による質問に対して商品カタログから関連情報を検索し、パーソナライズされた回答を生成します。商品の推薦、仕様の比較、使用方法のアドバイスなど、顧客の購買体験を向上させる機能を実装できます。詳細については、AWS Blog 「 AWS が生成 AI で E コマースにおけるショッピングアシスタントを強化 」をご覧ください。 まとめ 本投稿では、OpenSearch Magazine の開設にあたり、OpenSearch および Amazon OpenSearch Service の概要をご紹介しました。 OpenSearch はオープンソースの検索エンジンとして、フルテキスト検索からベクトル検索まで幅広い機能を提供し、近年では RAG アプリケーションのベクトルストアとしても注目を集めています。Amazon OpenSearch Service は、これらの機能をマネージドサービスとして提供することで、インフラ管理の負担なく高可用性と拡張性を実現します。Amazon Prime Video、Airbnb、OfferUp などの事例を通して、検索体験の向上やユーザーエンゲージメントの改善に貢献できることが確認できます。AWS エコシステムとのシームレスな連携を活用することで、開発者は複雑なインフラ管理やデータパイプラインの構築に時間を費やすことなく、RAG アプリケーションの構築や異なるデータストアとの Zero ETL 統合を実現し、ビジネス価値の創出に集中できます。更に、SIEM on Amazon OpenSearch Service や Centralized Logging with OpenSearch などの既存ソリューションを活用することで、セキュリティ監視やログ分析といった特定の用途にすばやく適用することが可能です。日本語対応の検索機能など、実装のヒントとなるサンプルもあります。 今後も、OpenSearch は最新の技術動向やユーザーニーズに対応すべくアップデートが行われていきます。OpenSearch Magazine では、重要なアップデート情報や活用事例を定期的にお届けし、皆様の OpenSearch 活用をサポートしてまいります。 早速 OpenSearch Magazine Vol. 1 にアクセスし、OpenSearch のアップデートをキャッチアップしていきましょう。 著者について ソリューションアーキテクト 榎本 貴之(Takayuki Enomoto) (X: @tkykenmt) 2015 年に AWS Japan にクラウドサポートエンジニアとして入社し、Amazon OpenSearch Service を中心に顧客の課題解決を担当していました。2021 年より現職のスペシャリスト SA として、Amazon OpenSearch Service および Amazon MSK を中心とした、お客様システムにおける検索、分析、ストリーミング処理の導入および活用を支援しています。