本記事は、AWSブログ AWS re:Invent 2024 – Powering Automotive and Manufacturing Innovation を日本語に翻訳し、日本のお客様向けに 補足情報 を追加したものです。 毎年恒例の AWS re:Invent が目前に迫ってきました！今年の同イベントは特に自動車業界と製造業の皆様にとって最も興味深いイベントになるでしょう。2024 年 12 月 2 日から 6 日にかけてラスベガスで開催される re:Invent 2024 では、AWS を活用してイノベーションとトランスフォーメーションを加速している先進的な自動車および製造業の内部を垣間見られます。自動車や製造に特化したセッションやデモンストレーションだけでなく、刺激的な基調講演、スキルが身につくブートキャンプ、同じ業界の参加者どうしが交流できるネットワーキング機会も提供されます。 今年の自動車および製造の主役は、生成 AI の変革力です。 生成 AI がこれらの業界で根本的な変革をどのように成し遂げているか、グローバルなエンジニアリングチームのコラボレーション強化、ソフトウェア開発とテストの迅速化、製品の市場投入スピードアップなどについて学べます。re:Invent 2024 で何を学び、何を体験できるかの一部を以下でご紹介します。 自動車 – モビリティの未来を加速する 自動車業界は急速な技術進歩に伴い大きな変革の最中にあり、re:Invent の自動車セッションと Expo ホールのデモを通して、その変革の姿を学ぶことができます。 自動車セッション では、ブレイクアウトセッション、チョークトーク、ワークショップ、ビルダーズセッションなど、さまざまな形式のセッションが用意されています。テクニカルセッションでは、車載ソフトウェア開発の加速や、車両データ分析アシスタントの構築方法などについて掘り下げて学べます。ブレイクアウトセッションでは、トヨタ、ホンダ、フォード、リヴィアン などのお客様事例を紹介します。 ベネチアンの Expo ホールにある「Industries Pavilion」では自動車デモを体験できます。トヨタの新型車に触れ、より詳しく知るためにバーチャルアシスタントと対話できます。さらに、生成 AI を活用したクラウド上でのソフトウェア開発・テストの高速化デモも体験できます。クラウド上でソフトウェアを変更し、それがデジタルコックピットのハードウェアで実際に動作するのを確認できます。 さらに、レーシングシートに座ってシミュレーション走行し、ダッシュボードでリアルタイムのドライビングデータを確認できます。そして、生成 AI 搭載のアプリケーションを使ってそのデータについて質問し、洞察を得ることもできます。 製造 – ものづくりの革新を加速する re:Invent 2024 では、お客様事例やインタラクティブに会話ができる展示を通じて、製造業でどんなことが実現できるようになるのかを示す、最先端のテクノロジーを紹介します。さまざまなセッションや Expo ホールのデモを通じて、製品開発の高速化、工場運営の最適化、新しい顧客体験を生み出す　software defined (ソフトウェア定義) プロダクトの創造など、AWS のテクノロジーを活用してものづくりを加速させている事例を見ることができます。 製造トラックはこれまでで最大規模となり、 幅広いコンテンツ が用意されています。ブレイクアウトセッションでは、フォルクスワーゲン、 Gousto、 Samsung、 Georgia-Pacific、 Rehrig Pacific などのお客様事例を紹介します。テクニカルなチョークトーク、ワークショップ、ビルダーズセッションでは、産業データファブリックの構築方法から、生成 AI を活用したオペレーターアシスタントの開発、製造現場とクラウドを結ぶシームレスなネットワークの構築など、幅広いトピックをカバーします。設計からスマートプロダクト、サプライチェーン、サステナビリティまで、製造バリューチェーン全体に関連するセッションを用意しています。 Expo ホールの製造エリアでは、設計・エンジニアリングからスマートマニュファクチャリングまで、さまざまな戦略的ワークロードに合わせたデモを展示します。このエリアの中心には「e-Bike スマートファクトリー」が展示されます。このデモでは、電動自転車の製造プロセス全体を再現し、AWS のサービスやソリューションを活用して、製品品質、操業効率、俊敏性の向上を実現する方法を紹介します。このスマートファクトリーのデモは、自転車シェアサービスのための e-Bike を設計、製造、管理する企業の事例を示しています。 デモでは、溶接、検査、シーリングの 3 つのステーションを通過する自転車フレームの動きを見ることができます。各ステーションでは、データを継続的に収集・処理し、分析してメトリクスを導出しています。これらのメトリクスは、アセット監視、予知保全、異常検知などのユースケースに活用され、メーカーが異常、欠陥、設備の問題を特定し、予測することを支援します。 e-Bike スマートファクトリーの他にも、生成 AI を活用して産業機械を大規模に接続する方法やデータ自動マッピング、産業データファブリックの構築など、 6 つのデモを展示します。 Industry Partner の参加 自動車と製造業の存在感をさらに高めるため、 Siemens、 Matterport、 MongoDB、 Belden、 Wind River Systems、 Upstage、 Claroty の 7 社の AWS パートナーが、 Industry Partnership Expo エリアに専用のブースを設けます。 AWS で動作するそれぞれのソリューションを紹介します。 re:Invent 2024 を体験しよう AWS re:Invent 2024 は、自動車および製造業のお客様にとって、自社のビジネストランスフォーメーションを加速する絶好の機会となります。洞察に満ちた 1 週間を過ごすことができる、必見のイベントです。ぜひ以下の準備をして、re:Invent 2024 に参加しましょう。 re:Invent 2024 の公式サイト で、最新情報を確認 「 自動車業界向け参加者ガイド 」と「 製造業向け参加者ガイド 」を活用して、カスタマイズしたアジェンダを作成 ベネチアンの Expo ホールにある「Industries Pavilion」を訪れ、 AWS の自動車および製造ソリューションについて詳しく学ぶ 日本のお客様に向けた情報 日本からのお客様向けには、現地において AWS Japan メンバーによる日本語でのブースのご案内や、個別ミーティング等を実施しています。担当の営業経由でお申し込みください。また、現地でも日本人スタッフへお気軽にお声がけください。 このブログは、Solutions Architect の黒田が翻訳しました。原文は こちら です。 Tiffany Pfremmer Tiffany は、Amazon Web Services の製造業および製造業に焦点を当てるシニアマーケティングマネージャーです。Rockwell Automation で 15 年以上の経験を持ち、マーケティング、品質、サービスなどさまざまな役割を担ってきました。Tiffany は、製造業のお客様に対して、バリューチェーンのあらゆる側面でお客様中心のソリューションを提供することにフォーカスしてきました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林大樹です。 近年、AI の進歩は目覚ましいものがありますが、特に生成 AI の発展には目を見張るものがあります。私自身もアイデアの壁打ちやプログラミングに大規模言語モデル (LLM) を活用しており、日々その有用性を実感しています。ところで、生成 AI の真価はテキスト処理だけにとどまらない、ということをご存知でしょうか。 例えば、最新のモデルには、画像も入力として利用できるマルチモーダルモデルと呼ばれるものもあります。本記事では、マルチモーダルモデルを利用した Amazon Bedrock の活用事例として、 株式会社コーテッグ様 の取り組みをご紹介します。 コーテッグ様の状況と経緯 株式会社コーテッグ様は、総合病院やクリニック、動物病院などの医療機関向けに、予約や受付の対応をスムーズに行うためのサービス「 ソトマチ 」を開発・提供されています。 ソトマチは、患者が医療機関の予約・受付を行う際に利用します。院内に設置された iPad 受付機や、ユーザー自身のスマホにインストールされた LINE のチャット UI から「診察券や保険証」(以降まとめて診察券と記載) の写真を送信することで、ユーザー登録やログインを不要としたスムーズな予約・受付を実現しています。 医療機関側では、診察券に記載された診察券番号や名前から患者のカルテを特定し、受付を行います。従来は受付のスタッフが人手で行っていたこの作業を自動化するために、ソトマチでは診察券に記載された内容を OCR で読み取り、システム上の登録データと照合する仕組みを導入しました。 しかし、この OCR システムには課題がありました。診察券は医療機関ごとに多種多様なデザインがあります。そのため、新しい医療機関にサービスを導入いただく際には、読み取り項目の設定や、読み取り精度の検証や調整といった事前設定に多くの時間を費やしていました。加えて、診察券のデザインが異なることから、単一の画像認識モデルでは読み取り精度が安定せず、誤って文字起こしが行われるケースも多く、そのような場合には、読み取り後に医療機関のスタッフの方が人手で修正を行っていました。 このような課題に対応するために Amazon Bedrock を活用し、機能改善を行いました。新しい「診察券の自動読み取り機能」は、事前設定を行わずとも、様々な診察券のデザインに対応することができます。さらに、正確に記載内容を読み取ることができており、受付業務の効率化やユーザー体験の向上に大きく貢献しています。 ソリューション／構成内容 Amazon Bedrock を利用した「診察券の自動読み取り機能」は以下のようなアーキテクチャから構成されています。従来の自動読み取り機能からの変更点として、診察券の OCR を行うコンポーネントを、従来の画像認識 AI モデルから、Amazon Bedrock に切り替えたことがあげられます。 Amazon Bedrock から利用できる基盤モデルの中には、Anthropic 社の Claude 3.5 Sonnet など、インプットとしてテキストだけではなく、画像も利用できるマルチモーダルモデルがあります。画像データを入力したうえで、「この画像から診察券番号と氏名を抽出してください」といったプロンプトを入力することで、OCR のように文字の読み取り処理を行うことが可能です。 ソトマチでは、従来の OCR 処理コンポーネントを Claude 3.5 Sonnet に置き換えました。診察券から抽出する項目などの条件をプロンプトで定義し、診察券の画像と併せて Claude 3.5 Sonnet に入力するだけで、高い精度で文字の読み取りができるようになりました。また、Amazon Bedrock は AWS Lambda から呼び出しており、既存のアーキテクチャをほとんど変更することなく、機能を置き換えることができています。 導入効果 ソトマチの「診察券の自動読み取り機能」を Amazon Bedrock で置き換えた結果、以下の 3 つの効果を得ることができました。 1. 医療機関ごとのフォーマット調整時間の削減 従来の画像認識モデルの場合は、診察券番号や氏名が書かれている位置が異なる場合、読み取り精度を向上させるために記載位置情報などの設定を行う必要がありました。しかし、Amazon Bedrock を利用した自動読み取りは特に設定を調整せずとも、柔軟に文字を読み取ることができるため、医療機関ごとの診察券フォーマットの調整が不要となりました 2. 読み取り精度の向上 患者名や診察券番号の抽出精度が向上しました。従来のモデルと比較して約 30% の精度改善が見られ、これにより読み取りミスが大幅に減少しています。以前は読み取りミスが発生すると、医療機関のスタッフが手作業でデータを修正する必要がありましたが、読み取り精度が向上したことにより、効率化を行うことができました。具体的には、1 医療機関あたり月間 30 時間もの作業量を削減することができており、導入医療機関 250 医院全体で見ると月間 7,500 時間の効率化に繋がっています。 3. 生成 AI を利用する際のセキュリティの担保 Amazon Bedrock へのすべての入出力データは、自身の AWS アカウント以外には非公開となっています。また、入出力データはサービスの改善や学習に利用されることがありません。そのため、診察券などの個人の情報が含まれるようなデータについても、安心して入力をすることが可能となっています。 まとめ 今回は AWS の生成 AI サービスである Amazon Bedrock を活用し、「診察券の自動読み取り機能」を改善する、というコーテッグ様の挑戦について紹介させていただきました。本事例は、最新の LLM が持つ画像解釈能力を実業務で活かした好例です。ソトマチではこの仕組みを応用して、 医療機関にて運用されている様々な書類 (紹介状や予約表、処方箋など) についてもデジタル化を行う機能を提供予定です。業務の特性上、従来の運用を大きく変えることができない医療施設に対して、生成 AI を活用したソリューションを提供し、医療施設の業務効率化に貢献していきたいとのことです。 コーテッグ様の成功事例が示すように、生成 AI の活用は業務プロセスの根本的な改善をもたらす可能性を秘めています。Amazon Bedrock を利用した生成 AI の活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 ソリューションアーキテクト 小林 大樹 (X – @kobayasd )

近年、ミッションクリティカルなワークロードでの AWS 活用が進むなか、レジリエンシーの確保は業務継続性、および、お客様体験の強化には必須となってきています。例えば、2023年４月には金融庁から「 オペレーショナル・レジリエンス確保に向けた基本的な考え方 」が公表され、「オペレーショナル・レジリエンス（業務の強靭性・復旧力）を確保することは国際的にも重要視されている」と記載されており、レジリエンスに対する関心は高まってきています。 AWS は目的別のレジリエンスサービス、統合型のレジリエンス機能、専門家によるガイダンスで構成された包括的なポートフォリオを通じて、お客様が可用性の高いアプリケーションをより容易に設計、構築、実行できるようにしています。 AWS Resilience Day はワークロードの回復力向上に役立つアーキテクチャのベストプラクティスや AWS サービスについて学べる対面イベントです。レジリエンスについて学ぶ座学と、ハンズオンを含む実践的なワークショップを通して、災害復旧、高可用性ワークロードの設計、エラー修正プロセスの実装について学んで頂けます。2023年に初めてミュンヘンで開催されてからこれまで世界13都市へ展開、今回ついに東京での開催となりました。 清々しい秋晴れの下、早朝から 70 名のお客様に目黒オフィスまで足を運んでいただきました。首都圏だけでなく、関西や九州からのご参加も！遠くからお越し頂き本当にありがとうございました！！ アジェンダ このセミナーは座学と ハンズオン を交互に織り交ぜながら進めていきます。 形式 タイトル スピーカー 資料 – オープニング 深森 広英 ※1 – 座学 AWSにおけるレジリエンス入門 Hyuntae Park ※6 Download 座学 レジリエンスの目標を設定する 猪又 赳彦 ※5 Download ハンズオン AWS Resilience Hubを活用したRPO/RTOの設定 川端 将宏 ※3 – 座学 レジリエンスの設計と実装 松本 耕一朗 ※2 Download ハンズオン 高可用性のための設計と実装 深森 広英 ※1 – ハンズオン ディザスタリカバリに備えた設計と実装 安藤 麻衣 ※2 – 座学 レジリエンスの評価とテスト 河角 修 ※2 Download 座学 レジリエンスの運用 新谷 歩生 ※1 Download ハンズオン AWS Fault Injection Serviceを用いたレジリエンス評価とテスト 三好 史隆 ※2 – 座学 インシデントへの対応と学習 中戸川 浩 ※6 Download ハンズオン インシデント対応からの学習 石倉 徹 ※4 – ※1. Sr.Solutions Architect, ※2. Solutions Architect, ※3. Partner Sales Solutions Architect, ※4. Partner Solutions Architect, ※5. Sr. Technical Account Manager, ※6. Technical Account Manager オープニング 総合司会の深森よりご挨拶です。本セミナーは、 AWS レジリエンスライフサイクルフレームワーク の 5 つの主要なステージに沿って進められます。みなさまにレジリエンスの向上に役立つさまざまな戦略、サービス、ツールについての学びを持ち帰って頂きたいという熱い思いをお伝えしました。 深森 広英 Sr. Solutions Architect AWS におけるレジリエンス入門 Q: 停止しないシステムを構築するにはどうすればよいでしょう？ A: システムは常に故障します。重要なのはシステムに障害が発生したときに何が起こるかです セッションはこんな問答から始まりました。このセッションではレジリエンスに関する AWS の責任共有モデルに基づき、AWS で耐障害性のあるアーキテクチャを構築し維持するためのコラボレーション、計画、継続的なレジリエンス活動の重要性を説くAWS レジリエンスライフサイクルフレームワークを紹介しました。またサービスオーナーシップモデルや Correction of Error (CoE) processes など AWS 自身がクラウドのレジリエンスを確保するために取り組んでいる活動や文化についても紹介しました。 Hyuntae Park Technical Account Manager レジリエンスの目標を設定する このセッションでは、ビジネスの要求とアプリケーションの回復力要件を一致させることの重要性について紹介しました。 レジリエンシーを考える際にはシステム全体で一つの RTO/RPO 目標を掲げがちですが、収益に直結するクリティカルなシステムと、それ以外の付加的なシステムを同列に扱うことは現実的ではありません。アプリケーションが提供する個々のユーザージャーニーの重要度に合わせたサービスレベル目標を定義し、より重要なものにレジリエンスの取り組みを集中させることの大切さをお伝えしました。このようにレジリエンシーはビジネス要件と密接に関わるため、経営陣を含む主要なステークホルダーの理解と関与を得て進めることが推奨されています。 猪又 赳彦 Sr. Technical Account Manager AWS Resilience Hub を活用したRPO/RTO の設定 AWS 上で稼働するアプリケーションのレジリエンシーは具体的にどう高めていけばよいでしょうか。ハンズオンでは AWS 上のアプリケーションの回復力を分析、管理、改善できるサービス AWS Resilience Hub の使い方も学びます。 AWS Resilience Hub – 目標 RTO / RPO を入力 まずは AWS Resilience Hub へアプリケーションの目標 RTO/RPO を入力します。 レジリエンスの設計と実装 再び座学セッションです。ここではレジリエンスの設計原則を活用してアーキテクチャとエンジニアリングのベストプラクティスを実装する方法について紹介しました。 セルアーキテクチャ、コントロールプレーンとデータプレーン、サーキットブレーカー、障害分離、静的安定性、グレースフルデグラデーション、バイモーダル動作など様々な例を挙げながら回復力のあるアーキテクチャやソフトウェアデザインパターンをご紹介しました。実開発でのトレードオフなど講師の経験を交えた Dive Deep した内容でした。 松本 耕一朗 Solutions Architect 高可用性とディザスタリカバリのための設計と実装 再びハンズオンです。AWS Resilience Hub を使ってアプリケーションのレジリエンシーを評価します。 AWS Resilience Hub – レジリエンシーの評価結果（改善前） アプリケーションが目標 RTO/RPO を満たしているかどうかの結果が得られました。リージョン障害時の RTO / RPO ともに目標値 (2hour/1hour) を満たしていません (Unrecoverable)。 AWS Resilience Hub – レジリエンシーの評価結果（改善後） AWS Resilience Hub が推奨する改善案に沿ってアプリケーションを修正し、目標 RTO / RPO を満たすようになったことを確認できました。 レジリエンスの評価とテスト 設計と実装の次は、評価とテストです。このセッションではカオスエンジニアリングを使用してシステムの弱点、脆弱性、障害モードを特定する方法について紹介しました。 システムが分散して大規模になるにつれ、起こりうる障害を予測しづらくなってきます。カオスエンジニアリングとテストは、予測不可能な状況においても回復力を発揮するアプリケーションを構築するためには欠かせない手法です。本番環境で問題が起きる前にアプリケーションをさまざまな障害シナリオにさらし、潜在的な弱点を発見する方法やその重要性について理解を深めました。 河角 修 Solutions Architect レジリエンスの運用 評価とテストを終えたら運用です。このセッションではシステムの健全性を効果的に監視し、プロセスを自動化する方法について紹介しました。 システムの健全性を担保するにはメトリクスを監視しますが、過剰にデータを集めてしまうと余計なコストがかかったり多すぎるアラートに圧倒されたりして、検知や復旧の遅れを生んでしまい返って逆効果です。ビジネス目標を踏まえ、アプリケーションにとって重要な測定項目を見つけることが大切であることをお伝えしました。 新谷 歩生 Sr. Solutions Architect AWS Fault Injection Service を用いたレジリエンス評価とテスト AWS Resilience Hub はレジリエンシーの目標 RTO / RPO を満たすアーキテクチャを提案するだけでなく、障害注入実験を行うための AWS CloudFormation テンプレートも提供します。これには AWS Resilience Hub の一機能である AWS Fault Injection Service が利用されます。 AWS Resilience Hub – 障害注入実験のテンプレート AWS CloudWatch Dashboard – バックエンドの応答状況 AWS Fault Injection Service が推奨するテンプレートから必要なものを選択し、“RDS インスタンスがフェイルオーバーした場合にも、フロントエンドとバックエンドは 2 分以上オフラインにならない” という仮説を検証しました。 インシデントへの対応と学習 インシデント発生後にはその分析を行いますが、最も重要なことは根本原因に立ち返りアクション項目を関係者で共有することです。このセッションでは根本原因を分析し、学んだ教訓を組織全体で共有して、同様のインシデントが将来的に発生しないようにすることの重要性について理解を深めました。 そしてレジリエンスに関する活動を継続することの重要性をお伝えしました。人やテクノロジーは常に変化するため、レジリエンスもそれらに適応させていく必要があります。 中戸川 浩 Technical Account Manager インシデント対応からの学習 最後のハンズオン演習では、AWS Resilience Hub でアプリケーションを再評価し、ベンチマークに対して継続的に評価する方法を学びました。 AWS Resilience Hub – 耐障害性スコア RTO/RPO の目標値に対する達成状況や、オペレーションに関する推奨事項の実装状況を基にして AWS Resilience Hub が算出する耐障害性スコアを確認しました。 ハンズオンは以上です。AWS Resilience Hub を利用して レジリエンスの目標設定、設計と実装、評価とテスト、運用、学習の レジリエンスライフサイクルフレームワーク を体感して頂きました。ハンズオンは 川端 将宏、深森 広英、安藤 麻衣、三好 史隆、石倉 徹 の 5 名が担当させて頂きました。 ハンズオンで学んだ AWS Resilience Hub については AWS Black Belt Online Seminar でもご紹介しております。こちらも是非ご参照ください。 AWS Resilience Hub Part1 基礎編 PDF / 動画 AWS Resilience Hub Part2 実践編 PDF / 動画 おわりに 本記事では東京で開催した AWS Resilience Day in Tokyo についてレポートしました。参加頂いたお客様からは「レジリエンスを高めるには技術だけでなく人やプロセスも極めて重要だと改めて気付いた」「AWS Resilience Hub や AWS Fault Injection Service などの具体的な使い方を学ぶ良い機会になった」などのご評価を頂きました。ご参加頂いたみなさま、本当にありがとうございました。頂いたフィードバックをもとにこれからも改善を重ねて参ります。本日の内容が少しでも皆様の業務のお役に立てば幸いです。 著者について 川端 将宏 (Kawabata Masahiro) Partner Sales Solutions Architect パートナー様のお客様担当チームをご支援するソリューションアーキテクトとして、主に金融サービス事業領域を担当しています。パートナー様のAWS案件創出支援や案件推進、技術支援、AWSスキル向上施策実施などを通じて、AWSのファンになっていただけるよう活動しています。 三好 史隆 (Fumitaka Miyoshi) Solutions Architect ソリューションアーキテクトとして主に製造業のお客様を担当しています。システム構築のためのアーキテクチャ提案や人材育成のためのワークショップ提供など、技術的な面からお客様のクラウド活用をご支援しています。

本ブログは 2023 年 12 月 18 日に公開された「 ISO 42001: A new foundational global standard to advance responsible AI 」を翻訳したものとなります。 人工知能（AI）は私たちの世代で最も変革をもたらす技術の 1 つであり、善のための力となり経済成長を促進する機会を提供しています。数千億のパラメータを持つ大規模言語モデル（LLM）の成長により、顧客体験の向上や従業員の生産性の向上など、新しい生成 AI のユースケースが開拓されました。AWS では、お客様と協力して安全性、公平性、セキュリティを最優先に AI システムを開発・使用することで、AI を責任を持って活用することに引き続き取り組んでいます。 AI 業界は 2023 年 12 月、 ISO 42001 の発行により重要な節目を迎えました。簡単に言えば、ISO 42001 は組織内で AI システムを管理するためのガイドラインを提供する国際的な マネジメントシステム規格 です。これは、組織が AI の開発と展開に関連するリスクを体系的に対処し、コントロールするためのフレームワークを確立します。ISO 42001 は責任ある AI 実践への取り組みを強調し、組織が自社の AI システムに特化したコントロールを採用することを奨励し、グローバルな相互運用性を促進し、責任ある AI の開発と展開の基盤を築くものです。 AI に対する信頼は極めて重要であり、AI ガバナンスを推進する ISO 42001 のような規格を取り入れることは、責任ある使用のアプローチを支援し、公衆の信頼を得るための 1 つの方法です。 AWS は、幅広い国際的な専門家コミュニティの一員として、 2021 年から ISO 42001 の開発に積極的に協力してきました。そして、この規格の最終発行前から基盤作りを始めていました。 国際規格は、責任ある AI ソリューションの開発と実装における世界的な協力を促進します。おそらく他のどの技術よりも、これらの課題に対処するには、テクノロジー企業、政策立案者、コミュニティグループ、科学者、その他の人々の間での協力と真の学際的な取り組みが必要であり、国際規格はその中で貴重な役割を果たしています。 また国際規格は、国内の規制要件をコンプライアンスメカニズムに変換するのに役立つ重要なツールであり、これには主にグローバルに相互運用可能なエンジニアリングの実践が含まれます。効果的な規格は、AI とは何か、責任ある AI とは何かについての混乱を減らし、業界が潜在的な危害の軽減に焦点を当てるのに役立ちます。AWS は、多様な国際的なステークホルダーのコミュニティと協力して、リスク管理、データ品質、バイアス、透明性など、さまざまなトピックに関する新たな AI 規格の改善に取り組んでいます。 AI システムやアプリケーションを責任を持って開発・展開する上での卓越性へのコミットメントを示す方法の 1 つとして、新しい ISO 42001 規格への適合があります。私たちは ISO 42001 の採用を引き続き追求し、お客様と共にそれを実現することを楽しみにしています。 私たちは、責任ある AI の未来に投資し、お客様や私たち全員が生活し活動するコミュニティの利益のために、国際規格の形成に貢献することに尽力しています。 著者について Swami Sivasubramanian は AWS のデータおよび機械学習部門の副社長です。この役職において、Swami は AWS のすべてのデータベース、分析、AI および機械学習サービスを統括しています。彼のチームの使命は、組織がデータを活用できるよう、保存、アクセス、分析、可視化、予測を行うための完全なエンドツーエンドのデータソリューションを提供することです。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

この記事は 「 BayCare’s St. Joseph’s Hospital cuts café wait times and improves operating efficiency with Just Walk Out 」（記事公開日： 2024 年 8 月 23 日）の翻訳記事です。 忙しい病院スタッフや来院者にとって、手短に食事を購入したいのに列に並ぶことは最も避けたいことです。フロリダ州タンパのセントジョセフ病院 (ベイケア・ヘルスシステムの一部) のカフェテリアは、アマゾンの Just Walk Out テクノロジーでリニューアルされ、もう列に並ぶ必要はなくなりました。 Just Walk Out は、ショッピング体験を簡素化し、スピードアップするために設計されています。人工知能( AI )、コンピュータービジョン、物体認識、深層学習モデルを組み合わせることで、あらゆる小売の環境で買い物客が選んだ商品を正確に判断できます。 セントジョセフ病院では、来院者は Season’s Café の入り口で、クレジットカード、モバイルウォレット、または従業員バッジを使ってゲートを通過します。このテクノロジーは、買い物客が棚から商品を手に取ったり、戻したりしたことを検知し、仮想の買い物カゴを作成します。会計の準備ができたら、買い物客は列に並ぶことなく退店し、選択した支払い方法で商品代金が決済されます。 Season’s Café. 出典: セントジョセフ病院 セントジョセフ病院は、病院が所有するカフェテリアに Just Walk Out を導入した全国初の病院です。「この技術がもたらした利便性と利用のしやすさに、みんな喜んでいます。私たちのスタッフ、医師、そして来院者も、素早く食品や飲み物を手に入れ、休憩や大切な人と過ごす時間を優先することができます。」と、ベイケア東部地区の食事、および栄養サービスディレクターの Erica Salgado 氏は述べています。 レジ待ちにさようなら 常にそうだったわけではありませんが、パンデミック中、病院は人手不足に陥り、長いレジ待ち列と20分以上の待ち時間が発生していました。そこで Salgado 氏はベイケアヘルスのイノベーションの VP である Craig Anderson 氏と一緒に、より迅速で円滑なカフェ体験を設計することにしたのです。 「患者のケアと品質は私たちの目標であり、Just Walk Out テクノロジーは、患者とそのゲストに合理化されたシンプルかつ正確なショッピング体験を提供し、時間を節約してくれます。」と Salgado 氏は述べています。 迅速になったサービスと営業時間の拡大 現在、カフェの飲食品コーナーの滞在時間はかつてないほど短くなりました。カフェで費やしていた平均時間は 25 分からわずか 3 分にまで短縮されました。「日勤の従業員は、列に並んで待つ必要がなく、その分、昼食時に休憩を取ることができます。従業員に多くの時間を返してあげることができました。」と Salgado 氏は述べています。 Season’s Café. 出典: セントジョセフ病院 病院の三交代勤務の従業員も、Season’s Café のアップグレードを喜んでいます。このカフェでは、24 時間新鮮な食品を提供しています。以前、カフェは午後 9 時に閉店していたため、夜勤の従業員の中には、シフト中ずっと食事なしで過ごさざるを得ない人もいました。「ヘルスケア組織として、私たちは患者と、患者のために働く人々の両方を第一に考えています」と、ベイケアのアプリケーションの VP である Brenda Goralski 氏は付け加えます。「Just Walk Out により、従業員はいつでもカフェを利用できるようになり、その結果、従業員は患者にさらに良いサービスを提供できるようになります。」 効率を高める合理的なオペレーション レジの列をなくしたことで、病院はレジを担当する従業員を、パンデミック以降、閉鎖されていた患者サービスや医師ラウンジなどのエリアに再配置することができました。「Just Walk Out テクノロジーにより、レジ係やバリスタなどの職種を再考し、労働力を最適化することができました。このテクノロジーは、コロナ後に対処できなかった労働力不足を間違いなく緩和してくれました。」とSalgado 氏は述べています。 結果として効率が向上し、病院は顧客スループットを向上させ、高い収益成長目標を達成するのに役立っています。カフェが再開されて以来、深夜シフトの売上は毎週増加しており、マネージャーは、簡単に商品を手に取って出るだけであることから、人々が平均してより多くの商品を購入するようになったことを確認しています。また、レジなし形式のおかげで、カフェにはより多くの商品を置くスペースができました。「レジがあった場所にドライ商品売り場を作りました。ヒートマップから、ここが非常に人気のあるスペースになっていることがわかります。」と Salgado 氏は述べています。 また、病院では、従業員がバッジを使ってカフェに入り、食事の支払いを行えるようになっています。そのためには、給与天引き、プリペイド定額支払い、食事プラン、ロイヤルティ特典など、様々なキャッシュレス決済プログラムを提供する Transact Campus の部門である Quickcharge に Just Walk Out を統合する必要がありました。「Amazon のスムーズなチェックアウト体験と統合された当社のキャッシュレス決済テクノロジーが、スピードが不可欠な医療環境の向上に役立っているのは喜ばしいです。」と、Transact のコマースソリューション担当 SVP 兼 GM である Arun Ahuja 氏は述べています。 可能性の拡大 Season’s Café. 出典: セントジョセフ病院 まだ始まったばかりですが、Salgado 氏はカフェの業績と買い物客からの前向きなフィードバックの両方に満足しています。また、常に学ぶ機会があると考えています。「前例のないことに取り組む際は、予測や計画できなかったことが多くあるものです」と述べています。得られた教訓の一つは、従業員が店舗をテストし、必要な調整を行えるよう、グランドオープン前に「ソフトローンチ」(練習期間)を設けることです。 総じて、ベイケア・セントジョセフ病院のチームは、彼らが成し遂げたことに大変喜んでいます。「私たちがこれを実行しているという事実は、私たちが限界を押し広げ、先を見据え、地域社会に最高のものを提供できるよう革新的かつ創造的であることの証です」と Salgado 氏は結論付けています。 お客様にスムーズでチェックアウト不要のショッピングを提供しましょう。ビジネスオペレーションを最適化および合理化しながら、より迅速でシームレスなショッピングをお客様に提供したいとお考えであれば、Just Walk Out テクノロジーがどのように役立つかについて、 お問い合わせください 。 著者について Sarah Yacoub Sarah Yacoub は、AWS のマーケティングシニアマネージャーで、アマゾンの Just Walk Out テクノロジーのマーケティングを担当しています。彼女はワシントン DC に拠点を置いています。 その他、Just Walk Out 事例に関連するブログ記事はこちらもご覧ください。 Aramark が米国本社に初の Just Walk Out ストアをオープン 本稿はソリューションアーキテクトの齋藤が翻訳を担当しました。原文は こちら 。

不気味な季節がやってきて、そして過ぎ去りました。ハロウィーンをテーマにしたリリースはありませんが、AWS は 10 月 28 日週、エキサイティングな数多くのリリースでハロウィーンを盛大に祝いました! AWS re:Invent 2024 までのカウントダウンが進む中、毎週ますます興味深いリリースが発表されているため、私たちは本当に「プレ」re:Invent の段階に入ったと言っても過言ではないと思います。 ご紹介すべきことがたくさんありますので、魔法使いの帽子をかぶり、「トリート」の大きな袋を開けて、10 月 28 日週の新着情報を詳しく見ていきたいと思います! デベロッパー向け 2024 年のハロウィーンでは、AWS から提供される、デベロッパー向けの「トリート」が不足することはありませんでした! AWS が VS Code IDE と AWS Toolkit で Lambda アプリケーションの構築エクスペリエンスを強化 – AWS は AWS Toolkit for Visual Studio Code で AWS Lambda 開発を強化し、IDE 内で直接、Lambda アプリケーションをコーディング、テスト、およびデプロイするためのガイド付きセットアップを提供するようになりました。サンプルのチュートリアルとワンクリックデプロイが含まれており、開発プロセスが簡素化されます。Lambda を使用したアプリケーションの構築は、魔法使いの工房で呪文を唱えるのと同じくらい直感的になりました! 静的ウェブサイトホスティングのための Amazon S3 との AWS Amplify の統合 – AWS Amplify Hosting は、シームレスな静的ウェブサイトホスティングのために Amazon S3 と統合し、 Amazon CloudFront を介したグローバル CDN サポートが提供されるようになりました。これによりセットアップが簡素化され、カスタムドメインと SSL 証明書を使用した安全で高パフォーマンスの配信が提供されます。サイトのホスティングは、ハロウィーンの夜にジャック・オー・ランタンを見つけるよりも簡単になりました! AWS Lambda が AWS Fault Injection Service (FIS) アクションのサポートを開始 – AWS Lambda が AWS Fault Injection Simulator (FIS) アクションのサポートを開始しました。これにより、デベロッパーは、レイテンシーや実行エラーなどの制御された障害を注入することで回復力をテストできるようになりました。これは、コードを変更せずに実際の障害をシミュレートし、モニタリングと運用の準備状況を改善するのに役立ちます。古いキャンディディスペンサーのテストに最適です! AWS CodeBuild がビルドの自動再試行のサポートを開始 – AWS CodeBuild は、ビルドの自動再試行を提供するようになりました。これにより、デベロッパーは、失敗したビルドの再試行制限を設定できます。これは、指定された制限までビルドを自動再試行することで手動での介入を減らし、幽霊に取りつかれたパイプラインを一掃するゴーストバスターのように、厄介で断続的な障害に対処できます! Amazon Virtual Private Cloud が新しいセキュリティグループ共有機能をリリース – Amazon VPC は、同じアカウント内の複数の VPC 間でのセキュリティグループの共有、および共有 VPC 内の参加者アカウントとのセキュリティグループの共有をサポートするようになりました。これにより、セキュリティ管理が合理化され、組織全体で一貫したトラフィックフィルタリングを実現できます。これで、ネットワークを安全に保つことが、デジタルゴブリンを追い払うのと同じくらいシームレスになりました! Amazon DataZone が、Tableau、Power BI などのツールでデータアクセスを拡張 – Amazon DataZone は、 Amazon Athena JDBC ドライバーをサポートするようになりました。これにより、Tableau や Power BI などの BI ツールからデータレイクアセットにシームレスにアクセスできます。これを使用することで、アナリストはデータを簡単に接続して分析できます。これで、データへのアクセスは、魔女がほうきに乗って飛ぶように容易になりました! 生成 AI Amazon Q と Amazon Bedrock では、生成 AI が魔法のように機能し続けています。10 月 28 日週のリリースをいくつかご紹介します。 Amazon Q Developer インラインチャット – Amazon Q Developer はインラインチャットサポートを導入しました。これにより、デベロッパーは、最適化、コメント、テスト生成などのアクションをコードエディタ内で直接実行できるようになりました。リアルタイムのインライン diff により、変更を簡単に確認できます。Visual Studio Code と JetBrains IDE でご利用いただけます。これは実質的にコードの魔法です。魔女の大釜は必要ありません! Meta の Llama 3.1 8B および 70B モデルが Amazon Bedrock でファインチューニング可能に – Amazon Bedrock は、Meta の Llama 3.1 8B および 70B モデルのファインチューニングをサポートするようになりました。これにより、デベロッパーは、独自のデータを使用して、これらの AI モデルをカスタマイズできます。128K のコンテキスト長を備えた Llama 3.1 は、大量のテキストを効率的に処理するため、ドメイン固有のアプリケーションに最適です。これで、暗い嵐の夜でも、AI は恐ろしいほど大量のデータを処理することに怯むことはないでしょう! Amazon Bedrock における Anthropic の Claude 3 Haiku のファインチューニングの一般提供を開始 – Amazon Bedrock における Claude 3 Haiku モデルのファインチューニングの一般提供が開始されました。これにより、精度を高めるために、データを使用してカスタマイズできます。AI をハロウィーンのコスチュームと同じくらいユニークにしましょう! コスト計画、コスト削減、追跡 予算を把握し、購入するキャンディの量をモニタリングするのに役立つ新しいリリースをいくつかご紹介します。 AWS で部分的なカード支払いが可能に – AWS は、クレジットカードまたはデビットカードによる部分的な支払いをサポートするようになりました。これにより、ユーザーは、複数のカードに月々の請求を分割できます。この柔軟性により、予算管理が、幽霊が幽霊屋敷中をすり抜けるようにスムーズになります! Amazon Bedrock が推論プロファイルにおけるコスト配分タグのサポートを開始 – Amazon Bedrock は、推論プロファイルのためのコスト配分タグをサポートするようになりました。これにより、お客様は、部門またはアプリケーションごとに生成 AI のコストを追跡および管理できます。これにより、財務管理が「トリック」ではなく、「トリート」になります! AWS Deadline Cloud が予算関連イベントを追加 – 視覚効果とアニメーションのワークロードのレンダリングと管理のために使用されるサービスである AWS Deadline Cloud は、予算関連のイベントを Amazon EventBridge を介して送信するようになりました。これにより、支出のリアルタイム更新と自動通知が可能になります。これは、想定外の不安を感じることなく、プロジェクトコストを管理するのに役立ちます! 「10 月 28 日週最も忙しいチーム」賞に輝いたのは…Amazon Redshift です! どうやら、 Amazon Redshift チームはハロウィーンが大好きで、多くのリリースで盛大に祝うことにしたようです! ハイライトをご紹介します。 生成 AI のための Amazon Redshift と Amazon Bedrock の統合 – Amazon Redshift は、SQL を使用した生成 AI タスクのために Amazon Bedrock と統合するようになりました。これにより、データウェアハウスで直接、テキスト生成などの AI 機能が追加されます。複雑な呪文なしで、リッチなインサイトを引き出すことができるようになりました! Amazon Redshift 向けの自動コピーの一般提供の開始を発表 – Amazon S3 から Amazon Redshift への継続的なデータインジェストの自動コピーの一般提供が開始されました。これにより、ワークフローが合理化され、データ統合が柔らかいカボチャを彫るのと同じくらいスムーズになります! Amazon Redshift がデータレイクテーブルのマテリアライズドビュー (MV) における増分更新のサポートを開始 – Amazon Redshift は、データレイクテーブルのマテリアライズドビューのための増分更新をサポートするようになりました。これにより、変更されたデータのみが更新され、効率性が高まります。これを使用することで、取りついてくるかのようなオーバーヘッドなしで、データを最新の状態に維持できます! AI 駆動型のスケーリングと最適化を備えた Amazon Redshift Serverless の発表 – Amazon Redshift Serverless は、AI 駆動型のスケーリングを提供し、ワークロードに基づいてリソースを自動調整するようになりました。これにより、身も凍るような驚きなしで、スムーズなパフォーマンスを実現できます! Amazon Redshift Data API の CSV 結果フォーマットのサポート – Amazon Redshift Data API は、SQL クエリ結果の CSV 出力をサポートするようになりました。これにより、データ処理の柔軟性が高まります。これにより、データの処理が、幽霊のささやきのようにスムーズになります! ハロウィーンウィークコンテストの準優勝は…Amazon CloudWatch です! Amazon CloudWatch チームも、今年のハロウィーンはキャンディを配るのに忙しくしていました! 早速見てみましょう。 Amazon CloudWatch がプロビジョンドパフォーマンスを超える EBS ボリュームをモニタリング – Amazon CloudWatch は、Amazon EBS ボリュームが IOPS またはスループットの制限を超えているかどうかを確認するメトリクスを提供するようになりました。これは、取りつかれているかのように感じる問題になる前に、パフォーマンスの問題を迅速に特定して解決するのに役立ちます! Amazon EBS ボリュームの I/O レイテンシーをモニタリングするための新しい Amazon CloudWatch メトリクス – Amazon CloudWatch は、Amazon EBS ボリュームの平均読み取りおよび書き込み I/O レイテンシーのメトリクスを提供するようになりました。これは、パフォーマンスの問題を特定するのに役立ちます。これらのインサイトは、追加コストなしで 1 分単位で使用できます。これは、ハロウィーンの幽霊のようにレイテンシーが忍び寄るのを防ぐのに役立つことでしょう! Amazon ElastiCache for Valkey がサーバー側の応答時間をモニタリングするための新しい CloudWatch メトリクスを追加 – Amazon ElastiCache は、読み取りおよび書き込みリクエストのレイテンシーに関するメトリクスを含むようになりました。これは、サーバーの応答時間をモニタリングするのに役立ちます。これは、パフォーマンスの問題が恐ろしいサプライズになる前に、迅速に特定して解決するのに資する機能です! まとめ 以上が 2024 年のハロウィーンのまとめです。皆さんはどうかわかりませんが、私にとってはこの時期が 1 年で一番のお気に入りで、その次に好きなのは新年です。どちらも予測不能な要素があり、とても楽しんでいます。ハロウィーンでは、どのようなコスチュームを着るのかにワクワクする一方で、新年には新しい可能性と新しい地平の開拓に焦点が当たります。 幸いなことに、AWS では 1 年を通して興奮とイノベーションをもたらしているため、新年まで待たなくても AWS を利用して新しい境地を開拓できます。そして、これを目の当たりにするには、 AWS re:Invent 2024 が最適です! 2025 年のハロウィーンには、どのような呪文やサプライズが待っているのでしょうか。次回まで、最新情報に注目しつつ、ほうきを準備しておいてください! 原文は こちら です。

11 月 1 日、米国西部 (オレゴン) AWS リージョンで、 Amazon Bedrock における Anthropic の Claude 3 Haiku モデル のファインチューニングの一般提供が開始されることをお知らせします。Amazon Bedrock は、Claude モデルをファインチューニングできる唯一のフルマネージドサービスです。Claude 3 Haiku モデルを独自のタスク固有のトレーニングデータセットでファインチューニングおよびカスタマイズして、モデルの精度、品質、一貫性を高め、ビジネスに合わせて 生成 AI をさらにカスタマイズできるようになりました。 ファインチューニングとは、重みを更新し、学習率やバッチサイズなどのハイパーパラメータをチューニングして最適な結果を得られるようにすることで、事前トレーニング済みの大規模言語モデル (LLM) を特定のタスクに合わせてカスタマイズする手法をいいます。 Anthropic の Claude 3 Haiku モデル は、Claude 3 モデルファミリーの中で最も高速かつコンパクトなモデルです。Claude 3 Haiku をファインチューニングすると、次の大きな利点がビジネスにもたらされます。 カスタマイズ – 企業やドメインの知識をエンコードすることで、より一般的なモデルと比較して、ビジネスにとって重要な分野で優れたパフォーマンスを発揮するモデルをカスタマイズできます。 専門的なパフォーマンス – より質の高い結果を生成し、会社の独自の情報、ブランド、製品などを反映した独自のユーザーエクスペリエンスを生み出すことができます。 タスク固有の最適化 – 分類、カスタム API とのインタラクション、業界固有のデータ解釈など、ドメイン固有のアクションのパフォーマンスを強化できます。 データセキュリティ – 安全な AWS 環境で安心してファインチューニングできます。Amazon Bedrock は、お客様のみがアクセスできるベース基盤モデルの別のコピーを作成し、このモデルのプライベートコピーをトレーニングします。 ドメイン固有のラベル付きデータを提供して Amazon Bedrock における Claude 3 Haiku モデルをファインチューニングすることで、特定のビジネスユースケースのためにパフォーマンスを最適化できるようになりました。 2024 年の初めに、当社は、お客様独自のデータソースで Anthropic の Claude モデルをファインチューニングするのをサポートするために、 AWS 生成 AI イノベーションセンター のエキスパートチームを通じてお客様との連携を開始しました。Amazon Bedrock における Anthropic の Claude 3 Haiku モデルを、 Amazon Bedrock コンソール で直接ファインチューニングできるようになりました。 Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファインチューニングを開始する Amazon Bedrock における Claude 3 Haiku モデルを簡単にファインチューニングする方法をご紹介します。ファインチューニングのワークフローの詳細については、AWS 機械学習ブログの記事「 Fine-tune Anthropic’s Claude 3 Haiku in Amazon Bedrock to boost model accuracy and quality 」にアクセスしてください。 Amazon Bedrock コンソール でシンプルなファインチューニングジョブを作成するには、ナビゲーションペインの [基盤モデル] セクションに移動し、 [カスタムモデル] を選択します。 [モデル] セクションで、 [モデルをカスタマイズ] ボタンを選択し、 [ファインチューニングジョブを作成] を選択します。 次に、独自のデータでカスタマイズするモデルを選択し、結果として得られたモデルに名前を付け、必要に応じて、 [モデルの詳細] セクションでモデルに関連付ける暗号化キーとタグを追加します。ジョブの名前を入力し、必要に応じて、 [ジョブの設定] セクションでジョブのタグを追加します。 トレーニングデータセットファイルの Amazon S3 の場所と、該当する場合は検証データセットファイルを [入力データ] セクションで選択できます。 各データセットは、シングルターンまたはマルチターンのメッセージング形式を使用した複数の JSON 行を含む JSON Lines (JSONL) ファイルを使用して作成できます。各 JSON 行は、 system とメッセージ ( message オブジェクトの配列) を含むサンプルです。 Amazon Bedrock における Anthropic の Claude 3.5 Sonnet モデル に関する最新情報をいくつかご用意しました。詳細については、Amazon Bedrock ドキュメントの「 Prepare the datasets 」にアクセスしてください。 {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "What’s the latest models to support Amazon Bedrock"},{"role": "assistant", "content": "Amazon Bedrock is a fully managed service that support Anthropic’s Claude 3 Sonnet, Haiku, and Opus models and the latest Claud 3.5 Sonnet model."}]} {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "How long context window of Claude 3.5?"},{"role": "assistant", "content": "Anthropic's Claude 3 models have a 200,000 token context window enabling you to relay a large volume of information to Claude.This translates to roughly 150,000 words, or over 500 pages of material."}]} {"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "Is Claude 3.5 available in Bedrock?"},{"role": "assistant", "content": "Anthropic’s most intelligent and advanced model, Claude 3.5 Sonnet, demonstrates exceptional capabilities across a diverse range of tasks and evaluations while also outperforming Claude 3 Opus."}]} [ハイパーパラメータ] セクションで、エポック、バッチサイズ、学習率乗数など、トレーニングで使用する ハイパーパラメータ の値を入力します。検証データセットを含めた場合は、 [早期停止] を有効にすることができます。これは、過学習を防ぎ、検証損失の改善が停止したときにトレーニングプロセスを停止するために使用される手法です。早期停止のしきい値と Patience の値を設定できます。 また、 [出力データ] セクションで、Amazon Bedrock がジョブの出力を保存する出力場所を選択することもできます。 [サービスアクセス] セクションで、適切な許可を持つ AWS Identity and Access Management (IAM) カスタムサービスロールを選択します。詳細については、Amazon Bedrock ドキュメントの「 Create a service role for model customization 」をご覧ください。 最後に、 [ファインチューニングジョブを作成] を選択し、ファインチューニングジョブが開始されるのを待ちます。 [カスタムモデル] セクションの [ジョブ] タブで、進行状況を追跡したり、停止したりできます。 モデルのカスタマイズジョブが完了したら、ジョブの送信時に指定した出力 Amazon Simple Storage Service (Amazon S3) フォルダ内のファイルを確認してトレーニングプロセスの結果を分析したり、モデルに関する詳細を表示したりできます。 カスタマイズされたモデルを使用する前に、 Amazon Bedrock のプロビジョンドスループット を購入し、その結果として得られたプロビジョンドモデルを推論のために使用する必要があります。プロビジョンドスループットを購入すると、コミットメント期間を選択し、モデルユニットの数を選択して、時間単位、日単位、月単位の推定コストを確認できます。Claude 3 Haiku モデルのカスタムモデル料金の詳細については、「 Amazon Bedrock の料金 」にアクセスしてください。 これで、コンソールプレイグラウンドでカスタムモデルをテストできます。カスタムモデルを選択し、Anthropic の Claude 3.5 Sonnet モデルが Amazon Bedrock で使用できるかどうかをたずねます。 次の回答が提示されます。 Yes.You can use Anthropic’s most intelligent and advanced model, Claude 3.5 Sonnet in the Amazon Bedrock.You can demonstrate exceptional capabilities across a diverse range of tasks and evaluations while also outperforming Claude 3 Opus. このジョブは、 AWS API 、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して完了できます。AWS CLI の使用の詳細については、AWS ドキュメントの「 Code samples for model customization 」にアクセスしてください。 Jupyter Notebook を使用している場合は、 GitHub リポジトリ にアクセスし、カスタムモデルのハンズオンガイドに従ってください。本番レベルのオペレーションを構築するには、AWS 機械学習ブログで「 Streamline custom model creation and deployment for Amazon Bedrock with Provisioned Throughput using Terraform 」を読むことをお勧めします。 データセットとパラメータ Claude 3 Haiku をファインチューニングする場合、最初に行うべきことはデータセットを確認することです。Haiku のトレーニングには、トレーニングデータセットと検証データセットの 2 つのデータセットが関係します。トレーニングを成功させるには、特定のパラメータに従う必要があります。これらは、 次の表に 概説されています。 トレーニングデータ 検証データ ファイル形式 JSONL ファイルサイズ <= 10GB <= 1GB 行数 32～10,000 行 32～1,000 行 トレーニング + 検証の合計 <= 10,000 行 トークンの制限 < 32,000 トークン/エントリ 予約キーワード プロンプトに「 \nHuman: 」または「 \nAssistant: 」が含まれないようにしてください データセットを準備する際には、小規模で高品質のデータセットから始めて、チューニング結果に基づいてイテレーションしてください。トレーニングデータを改良および改善するのに役立つよう、Claude 3 Opus や Claude 3.5 Sonnet などの Anthropic のより大きなモデルを使用することも考えられます。また、これらのモデルを使用して、Claude 3 Haiku モデルをファインチューニングするためのトレーニングデータを生成することもできます。これは、より大きなモデルが既にターゲットタスクで優れたパフォーマンスを発揮している場合に非常に効果的である場合があります。 適切なハイパーパラメータの選択とデータセットの準備に関する詳細なガイダンスについては、AWS 機械学習ブログの記事「 Best practices and lessons for fine-tuning Anthropic’s Claude 3 Haiku in Amazon Bedrock 」をお読みください。 デモ動画 Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファインチューニングを開始するのに役立つステップバイステップのチュートリアルについては、この詳細なデモ動画をご覧ください。 今すぐご利用いただけます Amazon Bedrock における Anthropic の Claude 3 Haiku モデルのファインチューニングの一般提供が、米国西部 (オレゴン) AWS リージョンで開始されました。今後の更新については、 詳細なリージョン一覧 をご確認ください。詳細については、Amazon Bedrock ドキュメントの「 Custom models 」にアクセスしてください。 今すぐ Amazon Bedrock コンソール で Claude 3 Haiku モデルのファインチューニングをお試しいただき、 AWS re:Post for Amazon Bedrock に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 お客様がこの新しいテクノロジーをビジネスで活用して生み出す成果を目にするのを楽しみにしています。 – Channy 原文は こちら です。

10 月 31 日、 Amazon QuickSight を搭載した AWS Supply Chain Analytics の一般提供についてお知らせします。この新機能は、AWS Supply Chain のデータを使用してカスタムレポートダッシュボードを構築するのに役立ちます。この機能により、ビジネスアナリストやサプライチェーンマネージャーは、カスタム分析の実行、データの視覚化、サプライチェーン管理オペレーションに関する実用的なインサイトの取得を行うことができます。 この仕組みを以下に示します。 AWS Supply Chain Analytics は AWS Supply Chain データレイクを活用し、Amazon QuickSight に埋め込まれたオーサリングツールを AWS Supply Chain のユーザーインターフェイスに直接提供します。この統合により、オペレーション分析のためのカスタムインサイト、メトリクス、主要業績評価指標 (KPI) を作成するための構成可能な統合エクスペリエンスが提供されます。 さらに、AWS Supply Chain Analytics には、そのまま使用することも、必要に応じて変更することもできる事前構築済みのダッシュボードが用意されています。起動時には、以下の事前構築済みダッシュボードが表示されます。 Plan-Over-Plan Variance: 2 つの需要計画を比較して、製品、サイト、期間などの主要なディメンションにおける単位と値の両方の差分が表示されます。 Seasonality Analytics: 前年同期の比較で需要が表示され、平均需要量の傾向に加えて、月次レベルと週次レベルの両方のヒートマップを通して季節性のパターンが示されます。 使用を開始する AWS Supply Chain Analytics の機能について順を追って説明します。 最初のステップは、AWS Supply Chain Analytics を有効にすることです。 [設定] に移動し、 [組織] を選択して [分析] を選択します。ここで、 Analytics のデータアクセスを有効化 できます。 これで、既存のロールを編集することや、分析アクセス許可を持つ新しいロールを作成することができるようになりました。詳細については、「 ユーザーのアクセス許可ロール 」を参照してください。 この機能を有効にした後に AWS Supply Chain にログインすると、 [Connecting to Analytics] (Analytics に接続) カードまたは左側のナビゲーションメニューの [分析] を選択して AWS Supply Chain Analytics の機能にアクセスできます。 これで、埋め込みの Amazon QuickSight インターフェイスをすぐに使用することができます。開始するには、 事前構築済みダッシュボード に移動します。 次に、 [Supply Chain Function] (サプライチェーン機能) ドロップダウンリストで必要な事前構築済みダッシュボードを選択できます。 この事前構築済みダッシュボードで私が最も気に入っているのは、簡単に始められることです。AWS Supply Chain Analytics によってすべてのデータセットと分析に加えて、ダッシュボードも用意されます。 [追加] を選択して開始します。 ダッシュボードページに移動すると、結果が表示されます。このダッシュボードはチームと共有することもできるので、コラボレーションの面でも改善できます。 カスタムダッシュボードを作成するために他のデータセットを含める必要がある場合は、 [データセット] に移動して [新しいデータセット] を選択します。 ここでは、AWS Supply Chain データレイクを既存のデータセットとして使用します。 次に [データセットを作成] を選択する必要があります。 分析に含める必要のあるテーブルを選択できます。 [データ] セクションには、使用可能なすべてのフィールドが表示されます。 asc_ で始まるすべてのデータセットは、Demand Planning、Insights、Supply Planning など、AWS Supply Chain によって生成されるデータセットです。 また、AWS Supply Chain に取り込んだすべてのデータセットも見つけることができます。データエンティティの詳細については、 AWS Supply Chain のドキュメントページ を参照してください。ここで注意すべき点は、AWS Supply Chain データレイクにデータを取り込んでいない場合、AWS Supply Chain Analytics を使用する前にデータを取り込む必要があるということです。データレイクにデータを取り込む方法については、 データレイク のページを参照してください。 この段階で分析を開始できます。 今すぐご利用いただけます AWS Supply Chain Analytics は、AWS Supply Chain が提供されているすべてのリージョンでの一般提供が開始されました。 AWS Supply Chain Analytics を活用して、オペレーションを変革してみてください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2024 年 9 月のアップデートまとめ はお読みいただけましたでしょうか。11月に入り、徐々に冬の訪れを感じる季節となりました。同時に、AWS re:Invent の開催が近づいてきていることも実感します。今年の re:Invent は12月2日から6日の開催となります。リアルタイム視聴を予定している方は今からスケジュールと体調を整えておきましょう！ それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2024 年 10 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートについて Amazon Connect now offers screen sharing ( Amazon Connect で画面共有が可能になりました ) Amazon Connect は、ウェブサイトやモバイルアプリケーションからパーソナライズされた音声およびビデオエクスペリエンスを提供できる アプリ内通話、ウェブ通話、ビデオ通話 を提供しています。今回のアップデートにより、Amazon Connect の画面共有機能を使ってエージェントは顧客の問題をすばやく理解し、解決を促進し、顧客の不満を軽減することができます。エージェントとエンドユーザーは、Amazon Connect のウェブ通話やビデオ通話で画面共有を活用し、コンテキスト情報を Amazon Connect に渡してカスタマーエクスペリエンスをパーソナライズできます。さらに、画面共有を特定のウェブページに制限することで、安全で安心なカスタマーエクスペリエンスを確保できます。フルマネージド型のコミュニケーションウィジェットを使用すると、わずか 1 行のコードで音声通話やビデオ通話に画面共有を追加できます。また、SDK を活用して、顧客向けに完全にカスタマイズされたエクスペリエンスを作成することも可能です。設定内容は こちら をご参照下さい。 2. 2024年10月のアップデート一覧 Amazon Connect now provides published forecast data in analytics data lake (Amazon Connect が公開された予測データを分析データレイクで提供) – 10/28/2024 Amazon Connect は、公開された予測 (短期および長期) データを分析データレイクとして提供を開始しました。これにより、分析データからレポートや洞察を簡単に生成できるようになりました。データレイクに公開された予測データを使用して、予測と実績を比較するダッシュボードを構築したり、これらのデータを売上予測などの他のデータセットと組み合わせて表示したりすることも可能です。今回のアップデートにより、公開されている各予測を手動でダウンロードする必要がなくなるため、分析データをビジネスインテリジェンスツールに自動的に取り込むことも可能になります。これらのレポートやインサイトを生成するには、 Amazon Athena を Amazon QuickSight やその他の任意のビジネスインテリジェンスツールと組み合わせて使用できます。この機能は、Amazon Connect の予測、キャパシティプランニング、およびスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Monitor Amazon Q in Connect by using CloudWatch Logs (CloudWatch Logs を使用して Amazon Q in Connect をモニタリングする) – 10/25/2024 Amazon Q in Connect は、エージェントに提供するリアルタイムのレコメンデーションや、自然言語を理解して検出された顧客の意図を把握するために Amazon CloudWatch Logs を使用できるようになりました。CloudWatch Logs でクエリを実行すると、会話、トリガー、インテント、レコメンデーションなど、問い合わせジャーニー全体を把握できます。また、この情報をデバッグに使用したり、AWS サポートに問い合わせたときに提供したりすることもできます。 関連リンク 管理者ガイド Release Notes Amazon Connect now offers screen sharing (Amazon Connectで画面共有が可能になりました) – 10/23/2024 Amazon Connect の画面共有機能により、エージェントは問題をすばやく理解して顧客を導き、解決を促進し、顧客の不満を軽減できます。エージェントとエンドユーザーは、Amazon Connect のウェブ通話やビデオ通話で画面共有を活用し、コンテキスト情報を Amazon Connect に渡してカスタマーエクスペリエンスをパーソナライズできます。さらに、画面共有を特定のウェブページに制限することで、安全で安心なカスタマーエクスペリエンスを確保できます。フルマネージド型のコミュニケーションウィジェットを使用すると、わずか1行のコードで音声通話やビデオ通話に画面共有を追加できます。また、SDK を活用して、顧客向けに完全にカスタマイズされたエクスペリエンスを作成することもできます。この画面共有機能は、アプリ内通話、ウェブ通話、ビデオ通話の機能が利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect launches iOS and Android Chat SDKs to support in-app chat experiences (Amazon Connect がアプリ内チャット体験をサポートする iOS および Android Chat SDK を発表) – 10/23/2024 Amazon Connect Chat で iOS と Android 用の SDK が提供されるようになりました。これにより、ネイティブのアプリ内チャットエクスペリエンスを提供して、顧客満足度を高め、運用コストを削減することができます。これらの SDK には、ネットワークとセッションを管理するための事前構築済みのコンポーネントとサンプル UX アプリケーションが用意されているため、統合を効率化し、シームレスで回復力のあるアプリ内チャットエクスペリエンスを保証します。Amazon Connect Chat SDK の機能では、Amazon Connect の通話、タスク、SMS、ウェブ通話と同じ生成 AI を活用したチャットボット、ルーティング、設定、分析、エージェントエクスペリエンスが活用されるため、オムニチャネル体験の提供が容易になります。たとえば、コールキューで待機している顧客にアプリ内チャットに切り替えるオプションを提供することで、待ち時間を短縮し、顧客満足度と業務効率の両方を向上させることができます。iOS と Android 用の Amazon Connect Chat SDK は、Amazon Connect Chat が利用できるすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Chat SDK for iOS Amazon Connect Chat SDK for Android Sample App Examples Amazon Connect Contact Lens dashboards now support additional customization capabilities (Amazon Connect Contact Lens ダッシュボードが、追加のカスタマイズ機能のサポートを開始) – 10/11/2024 Amazon Connect Contact Lens ダッシュボードに、メトリクスのパフォーマンスを色分けしたり、サービスレベルしきい値をカスタマイズしたり、ウィジェット内でメトリクスを切り替えたりする機能が追加されました。これらのダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。監視するメトリクスを変更してダッシュボードをさらにカスタマイズしたり、カスタム定義のしきい値に基づいてメトリクスのパフォーマンスを色分けすることも可能です。たとえば、サービスレベルが 70% を下回った場合は赤、70～90% の場合は黄色、90% を超える場合は緑を自動的に表示し、サービスレベルのパフォーマンスをすばやく視覚的に確認できます。この機能は、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect now supports using your customer’s initial chat message to personalize the customer experience (Amazon Connect では、お客様の最初のチャットメッセージを使用してカスタマーエクスペリエンスをパーソナライズできるようになりました) – 10/09/2024 Amazon Connect Chat では、顧客からの最初のメッセージをフローで使用できるようになったため、セルフサービスの完結率を向上させ、カスタマーエクスペリエンスをパーソナライズできるようになりました。最初のチャットメッセージを使用して、適切なステップバイステップガイドを表示したり、 Amazon Lex からのインタラクティブメッセージ (リストピッカー、カルーセルなど) をトリガーしたり、チャットを最適なエージェントにルーティングすることができます。たとえば、最初のメッセージが注文の問題に関するものであれば、直近の注文のリストピッカーをすぐにお客様に表示できます。あるいは、メッセージが配達のスケジュールの変更に関するものである場合は、日付と時刻のピッカーを表示して変更を促すこともできます。Amazon Lex でお客様の最初のメッセージを使用するには、Amazon Connect のフローデザイナー内の [ 顧客の入力を取得する ] ブロックにある [カスタマープロンプトまたはボットの初期化] オプションで[メッセージでボットを初期化]にチェックをするだけです。さらに、InitialMessage フロー属性 を使用してお客様の初期メッセージにアクセスし、 AWS Lambda を使用したフローの分岐や統合に活用できます。この機能は、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Q in Connect adds personalized guidance for agents (Amazon Q in Connect がエージェント向けのカスタマイズされたガイダンスを追加) – 10/08/2024 コンタクトセンターのエージェント向け生成 AI 搭載アシスタントである Amazon Q in Connect は、Amazon Connect およびその他のサードパーティ CRM システムからの顧客データを使用して、エージェントにパーソナライズされたガイダンスを推奨するようになりました。Amazon Q in Connect は、リアルタイムの音声またはチャットでの会話から顧客の意図を検出し、顧客データを理解してエージェントが言うべきことや取るべき行動を提案します。たとえば、顧客が客室をアップグレードするためにホテルに問い合わせをすると、Amazon Q in Connect はリアルタイムに会話を分析し、顧客のロイヤルティレベルを特定して、顧客に提供するアップグレードオプションと割引に関するステップバイステップガイドをエージェントに示します。Amazon Q in Connect を使用すると、コンタクトセンターのエージェントは、顧客満足度を高めながら、よりパーソナライズされた効率的な顧客対応を行えるようになります。この機能は、Amazon Q in Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect launches prompt customizations for Amazon Q in Connect (Amazon Connect が Amazon Q in Connect でのプロンプトカスタマイズをリリース) – 10/08/2024 コンタクトセンターのエージェント向け生成 AI 搭載アシスタントである Amazon Q in Connect で、コンタクトセンターのスーパーバイザーが会社のブランドやビジネスガイドラインに合わせて LLM プロンプトを事前設定できるようになりました。スーパーバイザーは、Amazon Q in Connect のトーンや行動を変えるようにプロンプトをカスタマイズして、特定の企業フレーズを取り入れたり、言語ガイドラインに従ったり、絶対的な一貫性が求められる状況に対して特定の「固定」応答を指定したりできます。例えば、顧客が医療保険会社に連絡したときに、請求拒否などのユースケースに敏感になるように Amazon Q in Connect をカスタマイズできます。請求の異議申し立てプロセスにステップバイステップガイドを使用するエージェントには、さまざまな種類の医学的アドバイスについて、共感のこもった言葉遣いと自動化された免責事項が提供されます。Amazon Q in Connect を使用すると、コンタクトセンターのエージェントは一貫性を持って会社のブランドを代表できるようになり、コンプライアンスリスクを軽減し、顧客満足度を高めることができます。この機能は、Amazon Q in Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect can now generate forecast for workloads with as little as one contact (Amazon Connect で、わずか 1 件の問い合わせからより小規模なワークロードの予測生成が可能に) -10/04/2024 Amazon Connect の 予測、キャパシティプランニング、スケジューリング 機能で、わずか 1 件の問い合わせから、小規模なワークロードの予測を生成できるようになりました。これにより、コンタクトセンターのマネージャーは需要予測を立てやすくなります。また、最小データ要件を満たすために履歴データを手動で準備する必要がなくなります。最小データ要件が緩和されることで、マネージャーは以前よりも小規模なワークロードの予測を作成できるようになり、キャパシティプランニングや人員配置が容易になります。また、Amazon Connect を使い始めたばかりのユーザーも本機能をすぐに利用を開始することが可能です。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect Contact Lens supports new read-only permissions for reports and dashboards (Amazon Connect Contact Lens が、レポートとダッシュボードの新しい読み取り専用権限のサポートを開始) -10/04/2024 Amazon Connect Contact Lens で、ユーザーがレポートとダッシュボードを読み取り専用として保存および公開できるようになりました。レポートを読み取り専用として公開すると、レポートまたはダッシュボードを作成したユーザーのみがレポートを編集でき、他のユーザーは閲覧やコピーの作成は可能ですが、編集はできません。たとえば、コンタクトセンターのマネージャーが、カスタムの読み取り専用ダッシュボードを設定し、それをチームのスーパーバイザーと共有して同じ指標を監視できるようにすると同時に、スーパーバイザーが独自のバージョンをカスタマイズして保存し、さらなる分析を行えるようにすることができます。この機能は、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect now supports multi-day copy and paste of agent schedules (Amazon Connect が数日間のエージェントスケジュールのコピーアンドペーストのサポートを開始) – 10/04/2024 Amazon Connect では、数日間のエージェントスケジュールのコピーがサポートされるようになり、エージェントスケジュールの管理がより効率的になりました。あるエージェントから別のエージェントに、または同じエージェントに数日間 (一度に最大 14 日間) のシフトスケジュールをコピーすることが可能です。たとえば、新しいエージェントが月の途中でチームに加わった場合、既存のエージェントのスケジュールから最大 14 日間のシフトスケジュールをコピーすることで、新しいエージェントに対してすぐにスケジュールを提示することができます。同様に、エージェントが数週間にわたって柔軟な勤務形態をとる場合は、最初の週のスケジュールを編集して、それを残りの週にコピーすることができます。数日間のエージェントスケジュールのコピーにより、エージェントスケジュールの管理に費やす時間が短縮され、マネージャーの生産性が向上します。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect launches the ability to initiate outbound SMS contacts (Amazon Connect がアウトバウンド SMS コンタクトを開始する機能をリリース) – 10/01/2024 Amazon Connect では、アウトバウンド SMS コンタクトを開始する機能がサポートされるようになりました。これにより、顧客が希望する通信チャネルで働きかけを行って、顧客満足度を高めることができます。コンタクト後のアンケート、予約のリマインダー、サービスの更新などのシナリオでプロアクティブな SMS エクスペリエンスを提供できるようになり、顧客は都合の良いときに対応できます。さらに、顧客に対し、コールキューで待機中に SMS に切り替えるオプションを提供できるため、保留時間をなくせます。開始するには、新しいメッセージ送信ブロックをコンタクトフローに追加するか、新しい StartOutboundChatContact API を使用してアウトバウンド SMS コンタクトを開始します。 関連リンク 管理者ガイド API Reference 3. AWS Contact Center Blog のご紹介 Amazon Connect と Service Quotas による効果的なコンタクトセンターの拡張 (日本語翻訳) Amazon Connect の利用拡大が進むと、顧客は効率的にスケーリングを管理し、クォータ(制限)を超過することによるデプロイの失敗やサービスの中断を防ぐために、クォータの可視性が必要になります。 Amazon Connect は Service Quotas との統合により、Amazon Connect インスタンスのサービスクォータ管理が改善されました。Service Quotas は、AWS マネジメントコンソールや AWS Command Line Interface(AWS CLI) を通じてアクセスできる、 AWS アカウント全体のクォータを効率的に管理し追跡するためのハブです。この統合によりアカウントとリソースのクォータ割り当てをナビゲートし最適化する上で、より広範な制御と柔軟性が実現されます。Service Quotas を使用することで、複数のソースにアクセスする必要なく、一つの場所で Connect のクォータを中央管理できます。またサポートされているクォータでは、 Amazon CloudWatch との統合により、設定可能なアラームを通じて積極的な管理も可能になり、指定されたクォータに近づくと適時アラートを提供します。このブログ記事では、Service Quotas の管理コンソール、AWS CLI を通して、リソース管理できるようになった Amazon Connect のクォータについて詳しく説明します。さらに、管理者が特定の Amazon Connect リソースのクォータを設定および管理する方法についても説明します。 Amazon Connect で簡単に実現する、生成 AI を活かしたより良いカスタマーエクスペリエンス (日本語翻訳) 生成 AI は 2023 年の大半において注目のトピックであり、2024 年になってもその勢いは衰えていません。この驚くべき技術に対する新しいイノベーションと創造的なユースケースは日々生まれています。カスタマーエクスペリエンス(CX)のユースケースにおける生成 AI の可能性は明確で魅力的です。しかし、新しい魅力的なアイデアにも、責任を持って安全に使用する方法や、効果を最大化する方法についての考慮すべき事項があります。3 部構成のブログ投稿シリーズの 第 1 部 では、生成 AI がコンタクトセンターの運用に直近で影響を与えうる 3 つの主要な領域について説明しました。それはエージェントの効率性の向上、分析と品質モニタリングの改善、そして顧客セルフサービスの改善です。シリーズの 第 2 部 では、これら 3 つの領域についてより深く掘り下げ、生成 AI を活用する際に生じる可能性のある課題と、リスクを軽減しながら価値を最大化するためのアプローチ方法について説明しました。そして今回の第 3 部では、カスタマーサービスのユースケースに対して生成 AI を迅速かつ簡単に有効化する方法をご紹介します。 AWS recognized as a Leader in 2024 Gartner Magic Quadrant for Contact Center as a Service with Amazon Connect (英語記事) Gartner が発表した 2024 年のコンタクトセンター・アズ・ア・サービス(CCaaS) のマジッククアドラントにおいて、Amazon Web Services(AWS) が2年連続でリーダーに選出されました。これは、AWS のクラウドコンタクトセンターソリューションである Amazon Connect の革新性と、あらゆる規模の企業に優れたカスタマーエクスペリエンスを提供する取り組みが評価された結果です。この記事では、Gartner の CCaaS マジッククアドラントにおける AWS の位置づけと、Amazon Connect の特徴について紹介します。 Rhythm Energy harmonizes customer experience with Amazon Connect (英語記事) テキサス州ヒューストンを拠点とする電力小売業者 Rhythm Energy 社は、カスタマーエクスペリエンスを重視し、再生可能エネルギーの普及に取り組んでいます。同社は、顧客サポート業務の効率化とカスタマーエクスペリエンスの向上を目指して、 従量課金モデル の Amazon Connect を導入し、チャットへの問い合わせボリュームの 600 %増加や 40 %のコスト削減など、大きな成果を上げています。この記事では、Rhythm Energy 社 の取り組みと、Amazon Connect 導入による具体的な効果、そして今後の取り組みについて紹介します。 Unlock organization-wide auditing ability for Amazon Connect flow changes (英語記事) コンタクトセンターの運用において、詳細な監査記録を保持し、一元的に状況を把握することは、セキュリティ、法令遵守、そして運用のベストプラクティスにとって非常に重要です。 以前のブログ記事 では、 AWS CloudTrail と Amazon Athena を活用して Amazon Connect の API の稼働を調査する方法を紹介しました。今回、Amazon Connect はさらに一歩進んで、Amazon Connect コンソールでのフロー管理アクティビティに対する AWS CloudTrail サポートが提供されました。これにより、ユーザーがコンタクトフローを追加、更新、または削除する都度、その記録が CloudTrail ログに取り込まれます。この新しい機能は、コンタクトセンターチームにさらなる可視性、レポーティング、およびコンプライアンス上の利点をもたらします。本ブログ記事では、AWS CloudTrail と Amazon Athena を組み合わせて、組織全体の AWS 環境における Amazon Connect のフロー管理アクティビティを一元的に分析および監査する方法について詳しく説明します。 Make your Amazon Connect chat experience more engaging with custom participants and generative AI-powered chatbots (英語記事) 現代の顧客は単なる迅速な回答以上のものを求めており、自然で直感的、かつ個人の好みに合わせたやりとりを期待しています。 Amazon Bedrock やサードパーティの AI ツールと Amazon Connect チャットを統合することで、企業が生成 AI の力を活用して顧客とのやりとりを強化することができます。この統合により、洗練された自然な会話が可能になり、単純な FAQ を超えた顧客にパーソナライズされたサポートを提供できるようになります。本ブログ記事では「Amazon Connect のチャット機能と生成 AI を統合し、顧客サービスを革新的に向上させる方法」、「Amazon Bedrock の基盤モデルに  Claude v2 を使用した生成 AI 駆動のメッセージングを、 Amazon Connect のチャットフロー に CreateParticipant API を通じて統合する方法」について説明します。また、事例紹介では、Adobe Inc. が自社開発のボットと Amazon Connect の統合が、デジタルメディア顧客サービスの自動化にどのように貢献しているかを説明します。 Personalize agent assistance with Amazon Q in Connect (英語記事) このブログでは、 Amazon Q in Connect のパーソナライゼーション機能によって、エージェントがカスタマイズされたカスタマーエクスペリエンスを提供するためにどのように時間を節約し、平均処理時間(AHT)の短縮と一次解決率(FCR)の向上につながるかを詳しく説明します。また、顧客データを活用して状況に応じたレコメンデーションを提供する方法や、エージェントの効率とエンドカスタマーエクスペリエンスの両方を向上させるために、業界の要件に合わせて Amazon Connect 内でその動作を直接カスタマイズする方法についても説明します。 Improve routing and self-service using Amazon Connect Customer Profiles and step-by-step guides (英語記事) 多くの組織が異なるシステムからの顧客データ統合に苦戦しており、これがパーソナライズされたカスタマーエクスペリエンスの提供を困難にしています。 Amazon Connect Customer Profiles と ステップバイステップガイド を組み合わせると、対話型メッセージングをチャットインタラクションに簡単に組み込むことができ、エージェントなしで顧客情報を収集できるようになるため、IVR 内で顧客を特定するための複雑な開発作業が不要になります。本ブログ記事では、顧客データへのアクセスと更新をより簡単に行える解決策を紹介し、複数のチャネルにわたる様々なパターンで顧客情報をシームレスに取得する方法を紹介します。これにより、IVR ルーティング、自動化されたセルフサービスの強化、効率的な問題解決のための顧客向けインターフェースのカスタマイズなどが可能になります。 re:Invent 2024: Your guide to customer experience with Amazon Connect (英語記事) AWS re:Invent 2024 は 2024 年 12 月 2 日から 6 日までラスベガスで開催され、世界中の参加者を迎えます。ブレイクアウトセッション、チョークトーク、ビルダーズセッション、ワークショップなど、多様な学習機会が提供されます。本ブログ記事では、AWS re:Invent 2024 における Amazon Connect 関連のセッションの概要と、参加者がイベントスケジュールを計画する際に役立つ情報をお知らせします。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

 はじめに 分散アプリケーションにおいてオブザーバビリティはパフォーマンスボトルネックやエラー率・アプリケーション全体が正常に稼働しているかを特定するのに重要な役目を果たします。コンテナでデプロイした AWS Lambda 関数を OpenTelemetry で計装しトレースを AWS X-Ray に送信するにはいくつか準備が必要です。このブログでは、OpenTelemetry Collector をビルドし、 Amazon ECR リポジトリにプッシュし、 Lambda のコンテナイメージにそれをコピーすることでこの問題を解決する方法を示します。 今回はセキュアで AWS がサポートする OpenTelemetry プロジェクトのディストリビューションである AWS Distro for OpenTelemetry を活用します。アプリケーションコードは OpenTelemetry SDK によって計装され、Lambda 関数の中で動作している OpenTelemetry Collector がトレースを収集し X-Ray に送信します。これによりコンテナでデプロイされた Lambda のパフォーマンスやアプリケーションが正常に動作しているかを監視できるようになります。 アーキテクチャ コンテナ化した Lambda からトレースを送信するアーキテクチャの全体像をお示しします。 画像を Amazon S3 バケットにアップロードすると Lambda 関数が実行されます Lambda 関数では外部のコンポーネントに対して API コールを実行します(今回の例だと Amazon Rekognition ) この処理は OpenTelemetry SDK によって計装されておりトレースを生成します Lambda Extension に追加されている OpenTelemetry Collector のなかの otlp receiver がトレースを受信し、 awsxrayexporter を使って X-Ray にトレースが送信されます 今回の例ではトレースを可視化するために X-Ray を用いていますが、他のオブザーバビリティバックエンドに切り替えることも可能です。 コンテナでデプロイした Lambda から X-Ray にトレースを送信するには zip で Lambda をデプロイする場合は Lambda Layer を使って比較的簡単にトレースを送信することができます。一方でコンテナで Lambda をデプロイする場合は Lambda Layer を使うことができず、依存物全てをコンテナにパッケージングする必要があります。 このブログでは OpenTelemetry Collector Lambda Extension を独自にビルドし、ECR リポジトリに保存し、Lambda のコンテナイメージにそれをコピーします。これによりコンテナで Lambda をデプロイしつつ OpenTelemetry を使ってトレースを X-Ray に送信することができます。 OTLP Receiver のエンドポイントについて ソースコードの中で OTLP Exporter のエンドポイントが設定されていないことに疑問を感じる方がいらっしゃるかもしれません。これについては OpenTelemetry Specification v1.38.0 時点では OTLP Exporter のデフォルトエンドポイントは localhost:4317 になって いて、今回ビルドした OpenTelemetry Lambda の Collector も OTLP Receiver が localhost:4317 で接続を受け付ける設定になっている ため明示的にエンドポイントを設定していません。今回使用している opentelemetry-otlp クレートでは ドキュメント にあるように opentelemetry_otlp::new_exporter() .tonic().with_endpoint() か環境変数 OTEL_EXPORTER_OTLP_ENDPOINT でエンドポイントを明示的に指定することもできます。 手順 こちらのリポジトリ の README に書かれた手順を実行していきます。 事前に必要なもの 以下のツールが必要です。 AWS CLI v2 Node.js Docker OpenTelemetry Collector Lambda Layer をビルドする Lambda からのトレースを収集し X-Ray などのバックエンドに送信するためには OpenTelemetry Collector が必要です。 OpenTelemetry Collector Lambda Extension Layer には awsxrayexporter が含まれておらず、このままでは X-Ray にトレースを送信することができません。そこで依存ライブラリに awsxrayexporter を追加した上で OpenTelemetry Collector をビルドします。まずはリポジトリをクローンしましょう。 git clone https://github.com/aws-samples/opentelemetry-lambda-container.git cd opentelemetry-lambda-container git clone https://github.com/open-telemetry/opentelemetry-lambda.git -b layer-collector/0.4.0 cp -r opentelemetry-lambda/collector/ otel-collector-lambda-extension rm -rf opentelemetry-lambda/ 1. awsxrayexporter を依存ライブラリに追加します。 otel-collector-lambda-extension/lambdacomponents/go.mod を以下のように編集します。 cd otel-collector-lambda-extension/lambdacomponents/ go mod edit --require=github.com/open-telemetry/opentelemetry-collector-contrib/exporter/awsxrayexporter@v0.92.0 2. otel-collector-lambda-extension/lambdacomponents/default.go を編集し awsxrayexporter を exporter に追加します。 import ( // import awsxrayexporter "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/awsxrayexporter" ) func Components(extensionID string) (otelcol.Factories, error) { ... exporters, err := exporter.MakeFactoryMap( // add awsxrayexporter here awsxrayexporter.NewFactory(), loggingexporter.NewFactory(), otlpexporter.NewFactory(), otlphttpexporter.NewFactory(), prometheusremotewriteexporter.NewFactory(), ) ... return factories, multierr.Combine(errs...) } 3. otel-collector-lambda-extension/Dockerfile を作成します。 FROM public.ecr.aws/docker/library/golang:1.20 as collector-builder WORKDIR /src COPY . . RUN go mod tidy RUN GO111MODULE=on CGO_ENABLED=0 installsuffix=cgo go build -trimpath -o collector . FROM scratch COPY --from=collector-builder /src/collector src/collector OpenTelemetry Collector のコンテナイメージをビルドし、ECR リポジトリにプッシュして Lambda 関数が Collector を Lambda Extension として使えるようにします。手順の中では us-east-1 リージョンを使用しますが、 AWS_DEFAULT_REGION で変更することも可能です。 export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_DEFAULT_REGION=us-east-1 cd opentelemetry-lambda-container/otel-collector-lambda-extension aws ecr create-repository --repository-name lambda-extension/otel-collector aws ecr get-login-password | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com docker build -t lambda-extension/otel-collector . docker tag lambda-extension/otel-collector:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/lambda-extension/otel-collector:v1 docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/lambda-extension/otel-collector:v1 Collector を Lambda 関数に含める opentelemetry-lambda-container/lambda-function/Dockerfile の <Your AWS account id> と <AWS Region> をお使いの AWS アカウントの ID とリージョンに書き換えます。 FROM public.ecr.aws/docker/library/rust:1.76.0 as rust-builder WORKDIR /rust/rust_app COPY src/ /rust/rust_app/src/ COPY Cargo.toml /rust/rust_app/ RUN apt-get update RUN apt-get install musl-tools -y RUN rustup update && \ rustup target add x86_64-unknown-linux-musl RUN cargo build --release --target x86_64-unknown-linux-musl FROM public.ecr.aws/lambda/provided:al2023 COPY --from=rust-builder /rust/rust_app/target/x86_64-unknown-linux-musl/release/bootstrap ${LAMBDA_RUNTIME_DIR}/bootstrap COPY --from=<Your AWS account id>.dkr.ecr.<AWS Region>.amazonaws.com/lambda-extension/otel-collector:v1 /src/collector /opt/extensions/collector COPY adot-config.yaml /opt/collector-config/config.yaml CMD [ "lambda-handler" ] AWS CDK でリソースをデプロイする Lambda 関数とその他のリソースを CDK でデプロイします。S3 バケットに画像をアップロードすると Lambda 関数が実行されるように設定されており、CloudFormation に出力される RekognitionSourceBucketName がその S3 バケット名を表しています。 以下のコマンドでデプロイします。 cd opentelemetry-lambda-container/lambda-trace npm install cdk deploy Lambda 関数を実行して動作確認する 以下のコマンドで画像ファイルを S3 バケットにアップロードします。 aws s3api put-object --bucket <RekognitionSourceBucketName> --key image.png --body <Some image file> ここ で生成される detect-label スパンが X-Ray のコンソール上で確認できます。 ここ で付与される label_num メタデータも確認できます。 おわりに このブログでは OpenTelemetry Collector の設定をカスタマイズして X-Ray 向けの Exporter を追加してビルドすることで、コンテナでデプロイした Lambda 関数から X-Ray にトレースを送信する方法を示しました。より詳細な情報は AWS Distro for OpenTelemetry , AWS Distro for OpenTelemetry Lambda で確認することができます。 One Observability Workshop を試して AWS でのオブザーバビリティを手を動かして体感いただけます。   著者について 苅野 秀和(Hidekazu Karino) 飛行機の勉強をしていたのが気づいたらなんやかんやあって AWS に入社してました。現在はウェブ系のお客様の技術支援を行いながら Rust を書いています。 週末は美味しいクロワッサンを求めてパン屋を探訪しています。

この記事では、 Itaú Unibanco が顧客からのデジタル資産サービスの需要増加にどのように対応し、 Amazon Managed Blockchain Access 、 Amazon Managed Blockchain Query 、および AWS Nitro Enclaves を活用して、企業レベルの革新的なサービスをデジタル資産分野に迅速かつスケーラブルに導入した方法をご紹介します。 ブラジルにおける導入動向 暗号資産の普及は、消費者とビジネスの好ましいトレンドの収束と、規制面での後押しが相まって、ラテンアメリカ全域で加速しています。 特にブラジルは、暗号資産の普及においてリーダーとしての地位を確立しつつあります。 ブラジルは近年、モバイル技術、政府の支援、消費者の習慣の変化により、デジタル決済へのシフトが加速しています。2020 年にブラジル中央銀行が導入したインスタント決済システム Pix は、ブラジル人が友人への送金、請求書の支払い、商品の購入を行う非常に人気のある方法となっています。1 億 5,000 万人以上のブラジル人が利用している Pix は、電話番号、メールアドレス、または ID を使用して銀行口座間の即時送金を可能にするリアルタイム決済システムです。デジタル決済手段をすでに利用している消費者は、暗号資産も早くから取り入れており、推定 1,600 万人が暗号資産を所有し、12,000 社が貸借対照表に暗号資産を保有しています。暗号資産は、高インフレに対する価値の保存、低手数料の送金の実現、分散型金融への参加などのユースケースで引き続き普及が進んでいます。 Chainalysis によると 、ブラジルは暗号資産の普及において世界第 9 位にランクされています。 地域の規制当局は、暗号資産およびデジタル資産業界の成長に向けた明確なガイドラインを確立しています。例えば、ブラジルの証券規制当局 CVM は、2022 年に 規制番号 175 を制定し、規制対象の投資ファンドがポートフォリオの最大 10% まで暗号資産に配分することを許可しました。これは、一般投資家の暗号資産へのアクセスを拡大する前向きな動きです。 さらに、2022 年 12 月、ブラジルは 仮想資産に関する法的枠組み （暗号資産法としても知られる）を公布し、2023 年 6 月に施行されました。この法律は、仮想資産を定義し、ブラジルで事業を行う仮想資産サービスプロバイダー (VASP) の要件を規定しています。 ブラジルは 2024 年に中央銀行デジタル通貨 (CBDC) である DREX を導入する計画を立てており、これは取引のセキュリティと効率性を向上させることを目的としています。この取り組みは、コアとなる金融ビジネスにおけるブロックチェーン技術とデジタル資産の利用を一層促進しており、その一環として、ブラジル中央銀行は DREX のパイロット版をテストするため、Itaú Unibanco などの主要な地元銀行を含む 14 の金融機関をプログラムの参加者として選定しました。さらに、このプロジェクトでは、標準的な決済を超えて、実世界の資産をブロックチェーン上でデジタル化するプロセスであるアセットトークン化など、多くの先進的なアプリケーションが実現可能になる可能性があります。 Itaú のデジタル資産管理ソリューション 2023 年 12 月 4 日、ラテンアメリカ最大手の銀行の 1 つである Itaú Unibanco は、選定された顧客向けに ÍON アプリを使用した Bitcoin と Ether のカストディサービスおよび暗号資産取引サービスの提供を開始しました。 これは、従来の資産を預けている信頼できるブランドによる暗号資産サービスを求める消費者需要に応えて、2022 年に設立された Itaú Digital Assets の取り組みの一環です。 現在、Itaú Unibanco は顧客向けの暗号資産取引サービスを段階的に展開しています。 資産管理サービスでは、すでに 10 億米ドルを取り扱っています。 2024 年には、新しい暗号資産商品の提供を開始し、リテールプラットフォームへのサービス拡大を予定しています。 資産管理ソリューションの開発にあたり、Itaú は従来のサービスと同様の厳格なセキュリティ、コンプライアンス、規制要件を満たしながら、ブロックチェーン技術の革新的な活用事例にも対応することを目指しました。 カストディサービスは、これらの目標を達成するために、次の図に示すように 5 つのレイヤーで構成されています。 レイヤーは以下のように構成されています。 セキュリティ – 第 1 層は、ハードウェアセキュリティモジュール (HSM) やマルチパーティ計算、機密計算などの実績のあるソリューションと先進技術を組み合わせて、安全なトランザクションを可能にし、顧客の鍵を (生成から保管まで) 保護することで、インフラストラクチャレベルのセキュリティに重点を置いています コンプライアンス – 第 2 層は、ブロックチェーンに保存されているデータとクレジットカードの購入や銀行取引などの従来のデータを分析し、KYC、KYT、AML (Know Your Counterparty、Know Your Transaction、Anti-Money Laundering) の要件を満たすことでコンプライアンスに対応します ガバナンス – 第 3 層は、各顧客に適切な権限とコントロールが設定されていることを確認することでガバナンスを提供します 監査 – 第 4 層は監査要件を満たします サービス – 最後に、第 5 層はステーキング、トレーディング、分散金融との統合などのサービスとともにカストディアプリケーション自体を提供します この資産管理ソリューションを構築するにあたり、Itaú は以下の 3 つの主要な課題を克服する必要がありました： 第一に、エンタープライズグレードのワークロードに必要な回復性を備えたブロックチェーンインフラストラクチャ自体の管理を簡素化する必要がありました。これには、ブロックチェーンノードの実行と保守、ノードクライアントソフトウェアを最新の状態に保つこと、ノード間のトラフィックのロードバランシングが含まれます。 第二に、パブリックブロックチェーンノードへの送信時点までのトランザクション情報を保護し、プライベート情報の共有を防ぐ、堅牢なデータ暗号化を実装する必要がありました。 第三に、セキュリティと暗号化レイヤーを使用して、鍵の生成、保存、トランザクションの署名を保護する必要がありました。この鍵はデジタル資産を保持する顧客のウォレットへのアクセスを制御するもので、情報の漏えいや不正使用があれば顧客の資金が危険にさらされることになります。 技術的な詳細 デジタル資産カストディの急速に進化する状況において、 AWS Nitro Enclaves は重要な技術として台頭しています。Nitro Enclaves は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス内に、暗号鍵の管理やトランザクションの署名などの機密性の高い操作に不可欠な、隔離された高度なセキュリティ環境を提供します。この隔離は、暗号鍵のセキュリティと整合性が最も重要となるデジタル資産の分野において不可欠です。Nitro Enclaves により、Itaú はデジタル資産取引に使用される鍵を外部の脅威から保護し、最高水準のセキュリティとコンプライアンスを維持することができます。 次の図は、デジタル資産のカストディ (保管) のアーキテクチャを示しています。これは、トランザクションを安全に署名し、パブリックブロックチェーンネットワークにブロードキャストするものです。 Amazon Managed Blockchain は、ブロックチェーン管理の運用面を大幅に効率化し、Bitcoin や Ethereum などの主要なネットワークに不可欠なインフラストラクチャサポートを提供します。 AMB Access は、これらのブロックチェーンノードへのフルマネージド型のゲートウェイを提供し、さまざまなブロックチェーンネットワークへの接続と対話を簡素化します。 さらに、AMB Query はブロックチェーンデータの処理効率を向上させます。 インデックス化されたブロックチェーンデータを提供し、複雑なブロックチェーンクエリをシンプルな API 呼び出しに変換することを可能にします。 このプロトコルを横断した統合アプローチにより、ブロックチェーンデータ管理に必要な複雑さと時間が削減され、全体的な効率性が向上し、コストを軽減し、リスクと運用の負担を低減します。 次の図は、AMB Access for Ethereum および Bitcoin を使用して、ブロックチェーン上の管理対象資産の入金、出金、送金を監視するためのアーキテクチャを示しています。 Nitro Enclaves と Managed Blockchain は AWS のファーストパーティサービスであり、セキュリティを維持しながら他のサービスとの連携を容易に実現できます。 Managed Blockchain とサーバーレスアプリケーションの統合により、Itaú はカスタムトランザクション管理と規制に準拠したインデックス作成ソリューションを開発することができます。 この統合により、デジタル資産管理の特定のニーズに合わせた、スケーラブルで効率的かつ安全なアプリケーションの作成が容易になります。 AWS のサーバーレスアーキテクチャにより、Itaú はサーバーインフラストラクチャの管理に手間をかけずに、デジタル資産サービスの革新と強化に注力でき、より俊敏で応答性の高い開発サイクルを実現できます。 「ブラジルは世界で最も急成長している暗号資産市場の 1 つであり、小売部門や機関投資家からの関心に加え、政府からの支援的な規制も整っています。Itaú は信頼できる規制対象の事業体として、包括的な暗号資産イニシアチブを通じてこのニーズに応えることで、最前線に立っています。AWS とのパートナーシップと AMB Access の活用により、市場投入までの時間を数か月短縮することができました。これは、急速に進化する市場における複数の事業分野での Itaú のリーダーシップ維持において、大きな戦略的意義を持っています。さらに、Amazon Managed Blockchain のスケーラビリティ、セキュリティ、信頼性により、私たちの取り組みが支えられているという安心感のもと、革新的な製品の提供に注力することができています。AMB Access のメリットを目の当たりにした後、ブロックチェーンに保存されている重要な残高や取引情報をより迅速に取得するために、AMB Query の活用を検討しています。」 – Itaú Digital Assets CIO、Caio Cesar Lopes Gomes まとめ AWS Managed Blockchain や Nitro Enclaves のような AWS テクノロジーの統合は、デジタル資産の安全かつ効率的な管理において大きな前進を表しています。 特にブラジルのような地域で暗号資産のユースケースが成長し続け、進化する中、堅牢でスケーラブル、かつ安全なデジタル資産ソリューションの必要性がますます重要になっています。 AWS は、ブロックチェーンソリューションを通じて、デジタル資産とトークン化の大きな可能性を探求しようとするビジネスに向けて強力なツールキットを提供しています。 デジタル資産への取り組みを強化したい企業の皆様には、AWS が提供するソリューションの数々をぜひ探求していただき、この変化の激しく急速に進化する領域で革新的なリーダーとしての地位を確立していただきたいと思います。 Ethereum、Bitcoin、Polygon 向けの AMB Access と AMB Query で 今すぐ始める ことができます。 本記事は、 How Itaú Bank simplified cryptocurrency custody with Amazon Managed Blockchain Access and Query を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 著者について John Liu は AWS の Web3/Blockchain 部門のプロダクトヘッドです。 製品部門の執行役員として 13 年、ポートフォリオマネージャーとして 10 年の経験を持っています。 AWS に入社する前は、クロスチェーンテクノロジー、DeFi、NFT に重点を置いたパブリックブロックチェーンプロトコルでプロダクトおよびビジネス開発のリーダーを 4 年間務めました。 それ以前は、フィンテック企業の最高製品責任者や、様々なヘッジファンドのポートフォリオマネージャーとして金融の専門知識を積み重ねてきました。 Everton Fraga は AWS のシニア Web3/ブロックチェーンスペシャリスト SA として、世界中の企業の Web3 インフラストラクチャとアプリケーションの構築を支援しています。 以前は Ethereum Foundation でソフトウェアエンジニアを務めていました。

こんにちは ! テクニカルインストラクターの室橋です。暑い暑いと思っていたら、突然寒くなってきましたね。体調にお気をつけてお過ごしください。 さて、生成 AI があらゆる業界で流行する昨今、生成 AI を適切に理解して利用することが求められています。 AWS Skill Builder では、生成 AI をこれから利用、学習される方向けの無償コースや、より実践的に学習をしていくことが可能なサブスクリプションのコースなど、様々なトレーニングをご提供しております。本ブログの内容を参考にして、生成 AI の活用をより良く進めていただけますと幸いです。 AWS Cloud Quest の生成 AI ロールが日本語化されました ! AWS クラウドをゲームベースで学習できるコンテンツである「 AWS Cloud Quest (以下 Cloud Quest) 」はご利用いただいておりますでしょうか ? Cloud Quest は、ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを使用しながら解いていく、RPG テイストのコンテンツです。ゲーム内で用意される AWS アカウントを一時的に使用できるため、サービスの使用料金などは気にせず、学習に集中してご利用いただけます。例えば、皆さんが車の運転をしたい、と思ったときには「学科試験の勉強」や「教習所での実技試験の練習」をして、免許を取って運転が出来るようになりますよね。Cloud Quest では、それと同じく「何度でも失敗できる安全な環境の中で、実際の環境を触りながら練習が可能 (もちろん、触るにあたってのサービスに関する知識の習得も可能) 」なコンテンツです。「Cloud Quest をまだ知らないよ」という方は、 こちらのブログ にて詳しくご案内しておりますので、是非ご確認ください。 Cloud Quest の中には、様々なカテゴリ (ロール) の課題が含まれています。無料でチャレンジ可能な Cloud Practitioner ロールをはじめとして、サブスクリプションにお申込みいただくことにより、 Solutions Architect、Machine Learning、Networking、Serverless Developer、Security、Data Analytics などの様々なカテゴリの課題に挑戦することができます。そしてこの度、 生成 AI ロール のすべての課題が日本語対応いたしました。生成 AI ロールには現在 27 の課題が用意されており、Amazon SageMaker や Amazon Bedrock を含めた、様々なサービスを組み合わせながら、生成 AI を利用したソリューション構築を学習することができます (生成 AI ロールのご利用には AWS Skill Builder のサブスクリプション登録が必要です) 。 ここで再度強調しておきますが、Cloud Quest では、ゲームの中で一時的に利用可能になる AWS アカウントを使用し、AWS を実際に操作しながらスキルを身につけていくことができます。このアカウントは、チャレンジが終了すると自動的に終了するアカウントのため、ご自身の AWS アカウントを使用することなく、サービスの利用料や、リソースの誤作成、削除漏れなどのミスを気にすることなく、ソリューションの構築に取り組んでいただけます。初めて利用するサービスを使ったソリューション構築には不安なところもあるかもしれませんが、Cloud Quest を使用して、より良い学習をお楽しみください。 さて、この度日本語化された課題を含め、生成 AI ロールの課題と、その中で触れられるサービスについて、一覧を掲載いたします。なお、課題や、課題中で使用するサービスには変更が発生する可能性があります。最新の情報はコンテンツ内にてご確認下さい。 2024年11月7日現在 課題名 主な利用サービス クラウドコンピューティングの基本 Amazon S3 クラウド、はじめの一歩 AWS, Amazon EC2 生成 AI の概要 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker, Amazon S3 Amazon SageMaker での LLM のファインチューニング Amazon SageMaker, Amazon API Gateway, AWS Lambda, Amazon S3 LangChain のパワーを活用 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker RLHF による基本モデルのファインチューニング Amazon API Gateway, Amazon DynamoDB, Amazon S3, Amazon SageMaker 基盤モデルによる 生成 AI アプリの構築 AWS Cloud 9, Amazon SageMaker ベクターデータベースによる LLM 機能の強化 Amazon SageMaker, Amazon OpenSearch Service, Amazon S3 翻訳サービスのバイアス緩和 AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon SageMaker 生成 AI コンテンツのモデレーター AWS Lambda, Amazon API Gateway, Amazon Comprehend, Amazon Rekognition, Amazon SageMaker 生成 AI チャットアプリの会話を中程度 AWS Lambda,Amazon SageMaker, Amazon DynamoDB, AWS Elastic Container Service, AWS Elastic Container Registry, AWS Fargate LLM によるインテリジェントなビデオとオーディオの Q&A AWS Lambda, Amazon S3, Amazon SageMaker, Amazon Transcribe 生成 AI によるノーコードインサイト抽出 Amazon Kendra, Amazon S3, Amazon SageMaker 安全な環境での SageMaker のプロビジョニング Amazon SageMaker, AWS IAM, AWS Service Catalog, Amazon S3, Amazon VPC LLM のファインチューニングを自動化 Amazon SageMaker, AWS CodeBuild, AWS CodeCommit, AWS CodePipeline, AWS Step Functions, Amazon SageMaker, Amazon S3 Amazon Bedrock によるプロンプトエンジニアリング AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon S3 LLM エージェントを使用したツールのビルドとデプロイ AWS Lambda, AWS Secrets Manager, Amazon Bedrock, Amazon Relational Database Service(RDS), Amazon S3 プロンプトエンジニアリングによるコード生成 AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront, Amazon CloudWatch 生成 AI によるコード品質の向上 Amazon SageMaker, Amazon CodeGuru, AWS CodeBuild, AWS Fargate, Amazon Bedrock, Amazon Elastic Container Registry ベクトルデータベースで信頼できる LLM を作成 AWS Secrets Manager, Amazon Bedrock, Amazon Relational Database Service(RDS), Amazon S3 Amazon Bedrock へのプライベートアクセスを設定する AWS Lambda, AWS PrivateLink, Amazon Bedrock, Amazon VPC 教育と学習のための生成 AI アプリ Amazon Bedrock, Amazon EC2, Amazon Elastic Container Registry, Amazon Elastic Container Service LLM を備えた最新のデータアーキテクチャ AWS Glue, Amazon Athena, Amazon Bedrock, Amazon SageMaker パーソナライズされたマーケティングのための生成 AI Amazon Bedrock, Amazon Personalize, Amazon SageMaker マルチモーダルエージェントによる財務洞察 AWS Lambda,Amazon SageMaker, Amazon Athena, Amazon Bedrock, Amazon Comprehend, Amazon DynamoDB プライベートデータを使用するサーバーレスチャットボット AWS Amplify, AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront AWS Q&A アプリケーションの生成 AWS Lambda, Amazon API Gateway, Amazon Bedrock, Amazon CloudFront, Amazon S3 興味のある内容が見つかりましたら、是非 Skill Builder のページ にアクセスして、 Cloud Quest の生成 AI ロール にチャレンジしてみてください。いきなりサブスクリプションはちょっと・・・と思われる方には、 無料でプレイ可能な Cloud Practitioner ロール もご用意しておりますので、まずは無料で学習を始めてみましょう ! Skill Builder 自体への登録は無料です。また、AWS アカウントをお持ちでない方も登録、利用が可能です 。 その他、生成 AI 関連コースを多数ご用意しております AWS Skill Builder では、上記の AWS Cloud Quest 以外にも、生成 AI 関連のコースを多数ご用意しております。下記にいくつか関連コースをピックアップしてみましたが、その他にも様々なコースをご用意しております。皆様の知りたい内容やニーズに合ったトレーニングを探して、是非知識を深めてみてください。 ■AWS Flash – AWS で始める生成 AI for Entry (Japanese) 日本語実写版 これから生成 AI を業務で活用していく上で、そもそも生成 AI とは何なのか、どのような技術的背景や、種類があり、業務で活用する上でのユースケースや課題を学習します。また、それらの課題に対して、AWS がどのように活用できるかを学習します。本コースは、AWS における生成 AI の学習の第一歩となる無償コースで、ユーザー登録のみでどなたでも学習いただけます。 ■AWS Flash – Introduction to Responsible AI (Japanese) このコースでは「責任ある AI」とは何か、なぜそれが重要なのかを概説します。責任ある AI とは、倫理的、透明、公正、かつ説明責任のある方法で AI を開発、デプロイ、使用することです。このコースでは、責任ある AI の主な要素と、公平性、説明可能性、プライバシー、堅牢性、ガバナンス、透明性に関するベストプラクティスの確立について説明します。このコースには、プレゼンテーション、実践例、ナレッジチェックが含まれます。本コースも無償コースのため、ユーザー登録のみでどなたでも学習いただけます。 ■Exam Prep Official Pretest: AWS Certified AI Practitioner (AIF-C01 – Japanese) AWS 認定プレテストは、本番のテストと同じ問題数を同じ制限時間で解くことができる AWS の公式コンテンツです。このプレテストは AWS の新しい認定である AWS Certified AI Practitioner (AIF-C01) の試験および試験ガイドに準拠しています。本番と同じ問題数、同じ制限時間で練習することで、自信を持って試験当日を迎えましょう。本コースのご受講にはサブスクリプションが必要です。 ■Digital Classroom – Developing Generative AI Applications on AWS (Japanese) このコースは、ファインチューニングなしで大規模な言語モデルを活用することに関心のあるソフトウェア開発者に、生成 AIを紹介することを目的としています。このコースでは、生成 AI の概要、生成 AI プロジェクトの計画、Amazon Bedrock 入門、プロンプトエンジニアリングの基礎、Amazon Bedrock と LangChain を使用して生成 AI アプリケーションを構築するためのアーキテクチャパターンについて説明します。本コースのご受講には年契約のサブスクリプションが必要です。 ※ Skill Builder のサブスクリプションについての説明に関しては こちらのページ より「AWS Skill Builder のサービスを比較」をご参照ください。 AWS Skill Builder にまだ慣れていない方は … AWS Skill Builder の利用自体が初めてで、コースの効率良い探し方を知りたい、という場合は AWS Skill Builder Learner Guide という、学習者用のガイドもご用意しております。Skill Builder の操作方法や、利用可能な様々なタイプのトレーニングについてご紹介しておりますので、利用が初めての方は是非ご参照ください。こちらは本ブログを作成している私が動画の声を当てております (笑)。 さて、季節が急に変わったようで、突然寒くなってきた今日この頃ですが、寒くなってきたからこそ ! 暖かなご自身のお部屋の中、オフィスなどで、AWS Skill Builder や AWS Cloud Quest を使ってクラウドの学習を楽しんでいただければと思います。

本ブログは 2023 年 9 月 15 日に公開された「 Responsible AI Best Practices: Promoting Responsible and Trustworthy AI Systems 」を翻訳したものとなります。 生成 AI の出現により、私たちの働き方、生活、世界との関わり方に変革をもたらす可能性と恩恵をもたらす潜在力が生まれました。しかし、このような強力な技術には責任が伴うことを認識することが重要です。 この頃、エグゼクティブの方々とお話しすると、AI を始めることに大きな熱意と興奮があります。生成 AI については特にです。しかし、彼らはよく「どうすれば責任ある安全な方法で、顧客に最高の体験を提供できるでしょうか？」と尋ねます。特に生成 AI に関して新たな課題が生じているのを目にするにつれ、これは重要な質問になります。 本ブログでは、公平性、透明性、アカウンタビリティ、プライバシーを重視した責任ある AI に関するいくつかの考慮事項とベストプラクティスをご紹介します。また、このエキサイティングな新技術を採用しイノベーションに乗り出す際に、エグゼクティブ、取締役、リーダーの方々が責任ある構築のために検討すべきステップについてもお伝えします。 生成 AI の時代における責任ある AI 生成 AI は、その増大する能力と高まるアクセシビリティにより、イノベーション、進歩、そして素晴らしい成果を達成する能力において、エキサイティングな機会を提供しています。しかし、こうした刺激的な機会に恵まれる中、潜在的なバイアスや害をよりよく理解し、対処する責任の増大が求められています。最近、AWS はホワイトハウス、政策立案者、テクノロジー組織、AI コミュニティと共に、自主的な取り組みを通じて AI の責任ある安全な使用を推進することに参加しました。これは、将来の生成 AI モデルを安全かつ責任を持って開発するために協力する必要性を認識したものです。 責任ある AI のベストプラクティスは、AI システムの責任ある、透明性のある、アカウンタビリティのある使用を促進する上で極めて重要です。AI テクノロジーが進化し、私たちの生活に浸透し続けるにつれて、責任ある AI の採用を促進するガイドラインとフレームワークを確立することが不可欠です。これらのベストプラクティスは、AI に関連する潜在的なリスク、バイアス、社会的影響に対処すると同時に、その変革の可能性を活用して個人、組織、社会に利益をもたらす必要があります。 これから説明する 9 つの責任ある AI のベストプラクティスは、技術的側面に留まらず、AI 導入の組織的および文化的側面に焦点を当てています。また組織内で責任ある AI の文化を促進するために、 リーダーシップのコミットメント 、部門横断的な協力、継続的な教育と啓発プログラムの必要性を強調しています。 人間中心のアプローチを取る 1. 多様で学際的なチームを組成する 必要な方針や戦略を決定するには、AI 専門家、データサイエンティスト、倫理学者、法律の専門家、ドメインエキスパートなど、多様な専門知識を持つチームを編成するのが最適です。チームは、AI 技術、責任ある考慮事項、法的枠組み、および AI が展開される特定のドメインについて、幅広い理解を持つべきです。この学際的なアプローチにより、AI の影響に関する全体的な視点と包括的な理解が確保されます。このチームは、あらゆる組織で責任ある AI 思考を形成し導入する上で重要な役割を果たします。 責任ある AI は単一の組織やグループ専属の管轄ではなく、AI エコシステムに関わるすべてのステークホルダーの積極的な参加と関与を必要とする、協力的な取り組みであることを覚えておくことが重要です。 2. 教育を優先する 責任ある AI の実践に関する教育は、AI 開発者やデータサイエンティストを超えて、従業員、ステークホルダー、そしてより広いコミュニティにまで及ぶ必要があります。教育プログラムは、責任ある AI の考慮事項、潜在的リスク、ベストプラクティス（責任ある AI の方針と手順を含む）についての意識を高めることに焦点を当てるべきです。バイアスの緩和、プライバシー保護、AI システムの説明可能性、AI 技術の責任ある使用に関するトレーニングの提供に特に重点を置く必要があります。 さらに、ガイドライン、ベストプラクティス文書、ケーススタディ、責任ある AI の実装例を含む内部リソースを作成することをお勧めします。これらのリソースを簡単にアクセスできるようにし、責任ある AI の進化する状況を反映するために定期的に更新します。 ここ には役立つリソースがあります。 3. AI の能力と人間の判断のバランスを取る 生成 AI の技術は、テキスト、画像、動画を含む非常にリアルなコンテンツを作成できます。しかし、AI はもっともらしく見えるが誤りを含む出力を生成することもあります。生成 AI を使用して法的文書を準備した弁護士が、存在しない判例を引用したという 報道 を見たことがあるかもしれません。このようなハルシネーション (幻覚) は、過度の最適化、データバイアス、文脈理解の限界、不十分または古いトレーニングデータなどの要因により発生する可能性があります。 AI システムはプロセスを合理化し効率を高める比類のない能力を提供しますが、人間の判断を十分に考慮する必要があります。人間は、幅広い知識、因果推論、共感、思いやり、文脈理解など、重要な資質を備えています。これは複雑で高リスクな意思決定シナリオにおいて重要となる可能性があります。AI を含むアプリケーションの責任ある使用と展開を促進するために、AI の能力と人間の判断の適切なバランスを取ることが重要です。 AI システムの決定の重要性と複雑さに基づいて、適切なレベルの人間の関与を検討する必要があります。この関与には、人間がAI システムと共に意思決定プロセスに積極的に関与する「ヒューマン・イン・ザ・ループ」、人間が AI システムの監視とコントロールを行う一方リアルタイムでの意思決定プロセスには積極的に関与しない「ヒューマン・オン・ザ・ループ」、あるいは人間が AI システムに対する最終的な意思決定権限とコントロールを持つ「ヒューマン・オーバー・ザ・ループ」のアプローチが含まれます。 バイアスを緩和し透明性を促進するための新しいメカニズムと手法を特定する 4. バイアスの緩和 生成 AI モデルは膨大な量のデータで訓練されています。基盤モデルや訓練データにバイアスが入り込むと、出力を生成する際に増幅され、永続化される可能性があります。これをそのまま放置すると、不公平、ステレオタイプの永続化、また多様性と表現が制限されることに繋がります。訓練データに偏りがあったり、サンプルのサイズに格差がある場合、または関連する特徴量に多様性が欠けている場合、バイアスが生じる可能性があります。 AI のバイアスの緩和には 2 つのアプローチが必要です。まず、組織は AI モデルの訓練中に多様で代表的なデータを優先的に使用する必要があります。幅広い視点、背景、人口統計を包む代表的なデータセットを取り入れることで、バイアスを緩和するのに役立ちます。次に、AI システムの開発と展開を通じてバイアスを緩和するための手法を実装することが重要です。これには、バイアスを緩和するためのデータの前処理や、公平でキャリブレーションされた AI 出力を促進するための後処理技術の実装が含まれます。 5. 透明性と説明可能性を促進する 生成 AI モデルは複雑で、モデルがどのように出力に至ったかを理解するのは難しい場合があります。生成 AI を使用していることをエンドユーザーいつ開示するか検討する必要があります。同様に、生成 AI モデルがどのように出力に至ったかの説明が必要な場合を考慮することが重要です。 モデルの開発と展開に関連する適切なプロセスを促進するメカニズムに焦点を当てます。これには、モデルのアーキテクチャ、入力データの要約、訓練プロセス、意思決定のメカニズムが含まれる場合があります。決定木やルールベースのシステムなどの解釈可能なアルゴリズムと手法を活用して、モデルがどのように機能するか理解を深めます。これには、特徴量の重要度分析、アテンションメカニズム、またはモデルの出力に最も影響を与える要因を強調する顕著性マップなどの手法が含まれる場合があります。 6. テスト、テスト、テスト 責任ある AI プログラムの有効性を確保するには、継続的なテストと評価が必要です。このテストには、モデル自体と、訓練に使用したデータセットを含むモデルの両方が含まれていることを確認してください。責任ある AI の実践を評価する際は、異なる人口統計グループ間の結果の格差やバイアスを測定するために公平性を評価する指標を検討してください。さらに、調査、フィードバックメカニズム、またはユーザーエクスペリエンスの評価を通じて、AI システムに対するユーザーの満足度と信頼度を測定します。責任ある AI プログラムの改善を推進するために、これらの調査結果を適切に文書化し、ステークホルダーに伝えることを検討してください。 リスクを最小限に抑えプライバシーを保護するために主要なセーフガードとガードレールを導入する 7. プライバシーに関する考慮事項を組み込む 生成 AI はモデルのトレーニングに大規模なデータセットを使用します。リスクを最小限に抑えるため、トレーニング中に匿名化技術を含む個人データの取り扱いに関するベストプラクティスを実施することが重要です。また、データの収集、処理、使用の制限など、適用されるプライバシー法や規制を考慮し、AI ガバナンスフレームワークにプライバシーに関する考慮事項を組み込む必要があります。 8. アプリケーションを特定のユースケースで定義する 生成 AI を広範囲に、あるいは際限のない自由回答形式の質問に答えるための万能ツールとして使用したくなるかもしれません。しかし、AWS のお客様には、特定のビジネスニーズに焦点を当てた価値の高いアプリケーションの特定のユースケースを定義することをお勧めします。アプリケーションのユースケースを特定することにより、アカウンタビリティとオーナーシップがより明確になり、透明性が高まり、リスクの評価と緩和が簡素化されます。また、より的を絞ったテスト、モニタリング、エラー処理も可能になります。 9. 知的財産権を保護し尊重する 生成 AI の台頭により、入力、出力、モデル自体の著作権、AI が生成したコンテンツの所有権、営業秘密の保護など、複雑な知的財産権 (IP) の課題が生じています。コンテンツを独自に作成する生成 AI モデルの自律性により、従来のクリエーターシップとオーナーシップの境界線が曖昧になっています (訳者注: 人間のクリエイターがコンテンツのオーナーであるという従来の対応関係が崩れてきていることを意味しています)。そのため、生成 AI の使用には、入力と出力の適切な使用を促進するための IP の法的な枠組みの慎重な検討が必要です。 AI システムで使用される独自のアルゴリズム、技術、プロセスを営業秘密として保護することは不可欠であり、機微情報への不正アクセスや開示を防ぐための堅固なセキュリティ対策が必要です。さらに、特定のモデルのデータフローを理解し、安全であることを確認し、入力が望まない形で第三者と共有されないようにすることが重要です。 結論 AI を責任を持って構築するための措置を講じることは、責任ある公正な成果を促進しながら AI の可能性を活用するために不可欠です。エグゼクティブは、安全で信頼できる AI を推進しながら、次の 10 年の AI イノベーションへと組織を導く機会があります。透明性、公平性、アカウンタビリティ、プライバシーの原則に従いバイアスに対処することで、信頼を構築し、社会的利益を促進し、AI システムに関連するリスクを緩和しながら、組織は生成 AI の可能性を最大限に活用できます。 Tom Godden Tom Godden は Amazon Web Services (AWS) のエンタープライズストラテジストでありエバンジェリストです。AWS に入社する前は、Foundation Medicine の最高情報責任者として、FDA が 規制する世界有数の癌ゲノムの診断、研究、患者転帰プラットフォームの構築を支援し、転帰の改善と次世代の精密医療への情報提供に貢献しました。それ以前は、オランダのアルフェン・アーン・デン・レインにある Wolters Kluwer で複数の上級技術リーダーシップの役割を務め、ヘルスケアおよびライフサイエンス業界で 17 年以上の経験を持っています。Tom はアリゾナ州立大学で学士号を取得しています。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

PGA TOUR は、より良い統計データを収集し、広く普及、さらにはファンを競技に近づけるための施策として、2024年の ZOZO Championship で  TOURCast を日本で初披露しました。これは CDW がサポートする革新的なスコアリングシステム ShotLink の新バージョンになります。PGA TOUR がこのような最新技術をアジアに持ち込めたのは今回が初めてで、Amazon Web Services(AWS) のクラウドの柔軟性とスケーラビリティを活用することで、実現に向けた課題を乗り越えることができました。 「私たちは過去 2 年間で、スコアリングシステムを完全に新しい AWS のソフトウェアスタックに置き換えました。それによってコース上の技術設置が非常に柔軟かつ機動力があるものになり、今大会で TOURCast を初めて実現できたのです」と、PGA TOUR のゴルフ技術責任者である Ken Lovell 氏は説明します。 この技術革新の中核には、入力ソースを区別しないクラウドベースのインフラストラクチャがあります。レーダーシステム、カメラ、手動入力といった様々なデータ収集手段からの情報を、システムはシームレスに処理できるのです。この柔軟性が、PGA TOUR が独自の制約に直面した ZOZO Championship での導入を可能にしました。 ZOZO Championship のフェアウェイにおいて、PGA TOUR のボランティアが、ショットの詳細データを入力し、ShotLink Select Plus にフィードバックする特殊なGPS機器を設置しています  [写真提供: PGA TOUR] 日本では、選手にトラッキングデバイスを装着させる代わりに、「フェアウェイごとに特殊な GPS 機器を持った要員を配置し、ショットの詳細を手動で入力しました」と Lovell 氏は明かします。「そして AWS 技術を活用したテクノロジースタックのおかげで、アイデアから実際の運用までわずか 4 か月でできたのです」。 グリーン周辺に設置される ShotLink Select Plus のための、レンジファインダーとアンテナを備えた 3 脚式設置台の例  [写真提供: PGA TOUR] この新しいアプローチの革新性は、PGA TOUR が既存のインフラストラクチャとデータ統合の方法を試しているところにあります。「システムは入力方法を気にしません。座標と選手情報さえあれば、AWS ソフトウェアスタックが残りを処理してくれます」 この柔軟性は、PGA TOUR と AWS のパートナーシップの直接的な成果です。AWS のクラウド技術を活用することで、PGA TOUR は大会ごとの特性に合わせてスケールアップ/ダウンできるシステムを構築できました。Lovell 氏は次のように述べています。「AWS を選んだ大きな理由は、自分たちのビジネスが独自のものであることを理解していたからです。究極の モジュール性と柔軟性を求めていました」。 このクラウドベースのアプローチによる恩恵は柔軟性だけにとどまりません。PGA TOUR は、現地の小規模なチームだけで全体の運用を遠隔から管理できるようになりました。「フロリダ本社からこの大会のシステムを管理できました」と Lovell 氏は説明します。「全てクラウドベースなので、場所は関係ありません。デバイスレベルとソフトウェアレベルの両方で、通信障害に対処できるストアアンドフォワード機能を組み込んでいます」。 しかし、このグローバル展開には課題もあります。データ処理のため遠くまで移動する必要があり、レイテンシーが重要な懸念事項となっています。「データがどれくらい速く移動できるかを試しているところです」と Lovell 氏は認めます。チームは AWS Direct Connect などのオプションを検討しており、APACリージョンにエンドポイントを設ける可能性も探っています。AWS Direct Connect は、お客様のネットワークを AWS に直接接続し、一貫したパフォーマンスと低レイテンシーを実現するクラウドサービスです。 PGA TOUR はこの導入に慎重なアプローチを取っています。大会中は TOURCast をライブで提供しましたが、チームは大会後により詳細な結果を検証してから一般公開する予定です。この拡大は PGA TOUR にとって単なる技術的な成果以上の意味があります。より広範なグローバルカバレッジに向けた戦略的な一歩となるでしょう。 ゴルフがグローバルに成長を続ける中、柔軟なクラウドベースの技術への投資により、PGA TOUR は国際的なファンのニーズに対応できる体制が整いました。AWS を活用した TOURCast の展開により、PGA TOUR は、この取り組みを通じて、単にゴルフのスコアリングシステムを構築したにとどまらず、スポーツ分野におけるグローバルな技術革新を実現することに成功しました。 ビジネスの成長を加速させるためにAWSをどのように活用できるか、詳しくは AWS 担当者 までご相談ください。 —- 参考リンク AWS for Sports AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは AWS 山口が担当いたしました。原文は こちら をご覧ください。

Amazon DataZone は、アマゾンウェブサービス（AWS）、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。2023 年 10 月に一般的提供を開始してから、継続して機能強化を続けています。 本ブログでは、Amazon DataZone の概要と、最近のアップデートや活用事例、簡単にはじめるための方法について簡単にご紹介します。詳細な情報のリンクも併せて記載しているので、ご興味がある方は、そちらの情報を確認いただき、理解を深めてください。 Amazon DataZone の概要と特徴 データ活用を進めていくにあたって、利用者は必要なデータを素早く発見して利用できることを求める一方で、管理者は適切な権限管理ルールに則り統制された環境を求めています。つまり、アジリティとガバナンスの両立が求められるわけですが、Amazon DataZone は、そのような要件を実現するソリューションです。 Amazon DataZone のコアコンポーネントは、図 1 に示す通り以下を提供します。 組織の境界を越えてデータを共有、検索するための Amazon DataZone ポータル ビジネス的な意味を蓄積し・共有するためのビジネスデータカタログ プロジェクトを作成してデータやツールなどの環境を、必要な人がアクセス可能になるまで IT 作業不要で実現する仕組み プロジェクト単位でだれがどのデータにアクセスできるかのアクセスコントロールと監査 図1 : Amazon DataZone のコアコンポーネント Amazon DataZone の詳細については、AWS Black Belt Online Seminar – Amazon DataZone Overview より確認いただけます。 PDF : https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-DataZone-Overview_1231_v1.pdf 動画 : https://www.youtube.com/watch?v=WGFJZNv2nDw （デモのパートは こちら からです） 2024 年の主要アップデート Amazon DataZone のアップデート情報については、ユーザガイドの What is new in Amazon DataZone? で紹介しています。どれもデータ活用に役立つ機能ですが、その中からピックアップしていくつかご紹介します。 主要アップデートサマリ ここで取り上げる Amazon DataZone アップデートを表 1 にまとめます。 日付 アップデート サマリ（ニーズ） 2024/4/3 AWS Glue Data Quality との統合 ・データ品質も参考にデータの利用判断をしたい 2024/6/14 高度な検索フィルタリング機能 ・効率的、かつ直感的にデータポータルから必要なデータを探したい 2024/6/17 カスタムブループリント ・既存リソースを Amazon DataZone に統合したい 2024/6/27 データリネージビジュアライゼーション機能（プレビュー） ・自分が作成したデータを誰が利用しているかを追跡したい ・データの出所を確認して分析に利用しているのが適切なデータか把握したい 2024/7/2 きめ細かなアクセス制御 ・共有するデータを行レベルおよび列レベルでデータをきめ細かく制御したい 2024/8/5 データプロダクトによるグループ化 ・共有するデータをグループ化してデータ共有のプロセスを簡素化したい ・特定のユースケースに必要なすべてのデータを簡単に見つけたい 2024/8/12 ドメインユニットと承認ポリシー ・ビジネスユニットやチームに関連するデータやプロジェクトを整理、作成、見つけたい 2024/10/17 AWS IAM Identity Center アカウントインスタンスのサポート ・AWS Organizations の組織インスタンスではなく、アカウントインスタンスを用いてユーザ管理、あるいは外部 IdP との SSO を実現したい 2024/10/18 プロジェクト内のメンバーに新しい肩書を追加 ・より細かくプロジェクト内のユーザーへの権限を制御したい 2024/10/30 Athena JDBC ドライバーによる認証をサポート ・Tableau、Power BI などのBI および分析ツールを使用して Amazon DataZone プロジェクトのサブスクライブ済みデータレイクアセットにクエリを実行したい  表1 : 主要アップデートサマリ ここからは、それぞれのアップデートについて紹介します。 Amazon DataZone と AWS Glue Data Quality の統合を開始（2024/4/3） AWS Glue Data Quality との統合が開始され、Amazon DataZone データポータルから、AWS Glue Data Quality の品質スコアを確認できるようになりました。また、API を使用して外部システムから品質スコアをインポートすることができます。これにより、データアナリストやデータエンジニアなどのデータコンシューマーは分析に使用するデータをデータポータルから検索する際に、データ品質スコアも参考に利用判断することができます。 図2 : Amazon DataZone データポータルで確認できるデータ品質（抜粋） 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-now-integrates-with-aws-glue-data-quality-and-external-data-quality-solutions/ 高度な検索フィルタリング機能を導入（2024/6/14） Amazon DataZone はビジネスデータカタログとして、組織全体で同じ定義が使用されるようにビジネス用語集を作成し、アセットに付与することができます。ビジネスカタログから必要なデータを検索するにあたって、ビジネス用語集からの検索機能を強化しました。具体的には、用語集の表示形式（図 4 左側）、「AND」「OR」検索（同図中央）、検索結果の調整に役立てられる選択したフィルターの要約（同図右上のオレンジ枠）です。これによって、コンシューマーはより効率的、かつ直感的にデータポータルから必要なデータを探すことができます。 図3 : データ用語集からのデータ検索 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-enhances-data-discovery-with-advanced-search-filtering/ AWS サービス向けのカスタムブループリント設定を開始（2024/6/17） Amazon DataZone は、カスタムブループリント設定により、既存の AWS IAM ロールや、Amazon S3 などの AWS サービスを使用して Amazon DataZone を設定できるようになりました。これにより、既存の Amazon S3 データレイクや Amazon Redshift データウェアハウス、AWS Glue ETL ジョブなどの AWS リソースを Amazon DataZone に統合できるようになるので、ガバナンスが強化されます。 図4 : 管理者によるカスタムブループリントのセットアップワークフロー 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-announces-custom-blueprints-for-aws-services/ データリネージビジュアライゼーション機能の開始（プレビュー）（2024/6/27） Amazon DataZone ではデータリネージのプレビューが導入され、お客様が OpenLineage 対応システムまたは API からのリネージイベントを視覚化し、ソースから使用までのデータ移動を追跡できるようになりました。これによって、データエンジニアなどのデータプロデューサーは、自分が作成したデータを誰が利用しているかを追跡するのに役立ちます。一方、データコンシューマーはデータの出所を確認することができるので、分析に利用しているのが適切なデータであるかどうかを把握するのに役立ちます。 図5 : Amazon DataZone データポータルで確認できるデータリネージ 詳細については、以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/news/introducing-end-to-end-data-lineage-preview-visualization-in-amazon-datazone/ 以下のブログでは、AWS Glue テーブルと ETL ジョブ、Amazon Redshift、Amazon Managed Workflows for Apache Airflow (MWAA) からリネージをキャプチャする方法について、CloudFormation スタック起動して確認することができます。 https://aws.amazon.com/jp/blogs/news/amazon-datazone-introduces-openlineage-compatible-data-lineage-visualization-in-preview/ きめ細かなアクセス制御の導入（2024/7/2） Amazon DataZone で、きめ細かなアクセス制御が導入され、データ所有者が行レベルおよび列レベルでデータをきめ細かく制御できるようになりました。例えば、テーブルに複数の地域のデータが含まれている場合、行フィルターを作成して、別々のプロジェクトに対して別々の地域の行へのアクセスを付与できます。さらに、列フィルターを使用すると、個人を特定できる情報 (PII) を含む列など、特定の列へのアクセスを制限して、必要かつ機密性の低いデータへのアクセスのみをデータコンシューマーに許可できます。 図6 : Amazon DataZone ポータルでの列フィルターの作成 詳細については、以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/news/enhance-data-security-with-fine-grained-access-controls-in-amazon-datazone/ データプロダクトによるビジネスユースケースベースのグループ化を提供（2024/8/5） Amazon DataZone で、特定のユースケースに必要なデータアセットをデータプロダクトとしてグループ化できるようになりました。例えば、マーケティングキャンペーンデータ、パイプラインデータ、顧客データといったマーケティング分析に必要となるデータをマーケティング分析というデータプロダクトとしてまとめることができます。データプロデューサーは、データプロダクトにビジネスコンテキストを追加し Amazon DataZone ポータルに公開することで、データコンシューマーはマーケティング分析に必要なすべてのデータを簡単に見つけることができます。 図7 : データプロダクトによるデータ共有プロセスの簡素化 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/blogs/big-data/introducing-data-products-in-amazon-datazone-simplify-discovery-and-subscription-with-business-use-case-based-grouping/ https://www.youtube.com/watch?v=MaXgOi0S0SQ ドメインユニットと承認ポリシーを発表（2024/8/12） Amazon DataZone で、ビジネスユニットやチームレベルでドメインを作成し、ビジネスニーズに応じてポリシーを管理できるようになりました。企業などの組織においては、複数のビジネスユニットやチームが階層型に構成されているケースが少なくありませんが、新しく導入されたドメインユニットにより実現できます。Amazon DataZone 管理者は、ドップレベルのドメイン配下に営業部門、マーケティング部門といったドメインユニットを作成し、ドメインユニットのオーナーを割り当てることができます。管理者やオーナーは、ドメインユニットに対するプロジェクトの作成や用語集、リソースの使用といったアクセスポリシーも設定できます。これにより、Amazon DataZone ユーザーは、ドメイン単位でカタログを参照や検索したり、特定のビジネスユニットが作成したデータをサブスクライブできます。 図8 : ABC Corpにおけるドメインユニットの例、ドメイン単位に承認ポリシーを設定できる 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/blogs/big-data/organize-content-across-business-units-with-enterprise-wide-data-governance-using-amazon-datazone-domain-units-and-authorization-policies/ https://www.youtube.com/watch?v=wGPzoPz1K4k AWS IAM Identity Center アカウントインスタンスのサポート（2024/10/17） Amazon DataZone で、AWS Organizations を設定していなくても、単一の AWS アカウントで AWS IAM Identity Center を有効できるようになりました。Amazon DataZone 管理者は AWS IAM Identity Center の有効化にあたって、組織インスタンスとアカウントインスタンスから選択することができます。これにより、AWS Organization の管理アカウントにアクセスできない場合でも、AWS IAM Identity Center のアカウントインスタンスを作成して、Amazon DataZone で該当インスタンスを有効化することによって、AWS IAM Identity Center によるユーザ管理や、Okta や Active Directory などの IdP と SSO を設定することができます。 プロジェクト内のメンバーに新しい肩書を追加（2024/10/18） Amazon DataZone で、プロジェクト内に追加するユーザー向けの肩書（権限ロール）に、従来の Owner, Contributor に加えてConsumer, Viewer, Steward が追加され、より細かくプロジェクト内のユーザーへの権限を制御できるようになりました。 これまで、プロジェクトにユーザーを追加する際にはそのユーザーを Owner もしくは Contributor として登録する必要があり、すべてのユーザーは Amazon DataZone 上で行うほとんどすべてのタスクを等しく行うことができました。今回、新たに追加された 3 つの肩書きにより、異なる役割をもつ多くの関係者をプロジェクトに追加して運用することがしやすくなりました。 表2 :肩書きと操作権限 Athena JDBC ドライバーによる認証をサポート（2024/10/30） Amazon DataZone は Athena JDBC ドライバーによる認証をサポートするようになりました。これにより、データコンシューマーは、Tableau、Domino、Power BI、MS Excel、SQL Workbench などの一般的な BI および分析ツールを使用して、Amazon DataZone 内のプロジェクトのサブスクライブ済みデータレイクアセットにクエリを実行できるようになりました。 図9 : これまでの Amazon DataZone データポータルのクエリエディタによるデータアクセス（上段）と、Athena JDBC ドライバによる BI および分析ツールからのアクセス（下段） 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/jp/blogs/big-data/expanding-data-analysis-and-visualization-options-amazon-datazone-now-integrates-with-tableau-power-bi-and-more/ https://www.youtube.com/watch?v=dFsoldpcF9M Tableau Desktop の詳細なセットアップ手順については以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/big-data/streamline-ai-driven-analytics-with-governance-integrating-tableau-with-amazon-datazone/ Amazon DataZone の活用事例 フォルクスワーゲンが複数のデータレイクにわたるデータアクセスを合理化した取り組み（2024/6/18） フォルクスワーゲン AG（VW）と AWS は 2019 年に戦略的パートナーシップを結び、デジタルプロダクションプラットフォーム（DPP）を共同開発するための戦略的パートナーシップを結びました。生産と物流の効率を 30% 向上させながら、生産コストを同程度削減する DPP の取り組みを進めていくにつれて、顕在化した以下課題に対して、Amazon DataZone を使用して効率的なデータアクセスを実現したかについて解説しています。 複数の独立したデータレイクに保存されているデータの共有 共有されたデータから利用可能なデータを発見してデータアクセスをリクエストするワークフローの円滑化 記事はシリーズ構成となっており、パート 1 について公開されています。 https://aws.amazon.com/blogs/big-data/how-volkswagen-streamlined-access-to-data-across-multiple-data-lakes-using-amazon-datazone-part-1/ ATPCO のイノベーションを加速させる取り組み（2024/7/25） ATPCO は航空会社が旅行会社などが顧客に適切なオファーを適切なタイミングで提供できるよう支援する航空小売業で、データ主導の意思決定を強化することを目指しています。同僚と話し合って潜在的なデータ資産を見つける状況から、Amazon DataZone などの AWS サービスを利用して、誰が何にアクセスできるのかを適切に管理しながら、すべての事業部門が高品質なデータを発見できるようにしてイノベーションを加速させる方法について解説しています。 解説にあたっては、ユースケースとして、航空券データ、価格データ、匿名化された顧客マスタといったデータソースと Amazon DataZone によるソリューション概要図も紹介しています。 図10 : ソリューション概要図 詳細については以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/how-atpco-enables-governed-self-service-data-access-to-accelerate-innovation-with-amazon-datazone/ フォルクスワーゲンオートヨーロッパが Amazon DataZone を使用してデジタルトランスフォーメーションを加速した取り組み (2024/10/31) フォルクスワーゲングループの工場であるフォルクスワーゲン・オートヨーロッパは、最先端のテクノロジーを活用してデジタル化への取り組みを強化するためデータ主導型の工場を目指していましたが、数日から数週間かかるデータアクセスまでのリードタイム、データコピーによる共有が引き起こす重複した作業やデータガバナンスの欠如とデータ品質の問題といった課題を抱えていました。この課題に対して、オンラインショッピング体験のような、データを利用するユーザーが分かりやすい仕様やビジネスコンテキスト、関連する属性を備えた高品質で安全なデータを閲覧してアクセスできるデータマーケットプレイスを構想し、ソリューションとして Amazon DataZone を使用したデータメッシュアーキテクチャを選択しました。ソリューションにより、データアクセス時間が数週間から数分に短縮されています。 ブログでは、ソリューションのキーとなるケイパビリティとアーキテクチャに加えて、データオーナー（データプロデューサー）、データエンジニア（データコンシューマー）、データソリューション管理者といった役割のユーザーが、データソリューションをどのように利用するかのユーザージャーニーについて紹介しています。 図 11 : ソリューションのキーとなるケイパビリティ（能力） 図 12 : ソリューションのアーキテクチャ 詳細については以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/big-data/how-volkswagen-autoeuropa-built-a-data-mesh-to-accelerate-digital-transformation-using-amazon-datazone/ はじめるには Amazon DataZone のベーシックな機能を体験できるハンズオンとして Amazon DataZone ハンズオン(ベーシック) がありますが、ありますが、解説記事が builders.flash で公開されています。 https://aws.amazon.com/jp/builders-flash/202411/amazon-datazone-hands-on/ Amazon DataZone のコアコンポーネントを AWS CDK を用いて効率的にデプロイして管理する方法について以下のブログで解説しています。記事では、ドメイン、データポータル、ビジネスデータカタログなどの構築手順と、既存の AWS Glue データベースを Amazon DataZone のデータソースとして公開する方法が紹介されています。 https://aws.amazon.com/blogs/big-data/streamline-your-data-governance-by-deploying-amazon-datazone-with-the-aws-cdk/ まとめ 本ブログでは、Amazon DataZone の概要と、最近のアップデートや活用事例について紹介しました。 生成 AI が注目されていますが、差別化となるデータの重要性がますます高まっています。データを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスである Amazon DataZone により、アジリティとガバナンスの両立しながら、データ活用を進めていくことができます。 本ブログが、皆さまのデータ活用の取り組みのお役に立てれば幸いです。 更新履歴 2024/7/29 新規作成 2024/8/19 データプロダクトと、ドメインユニットと承認ポリシーを追加 2024/10/23 AWS IAM Identity Center アカウントインスタンスのサポートと、プロジェクト内メンバーの新しい肩書きを追加 2024/11/7 Athena JDBC ドライバのサポートと事例を追加すると共に、Amazon DataZone ハンズオン(ベーシック) の解説記事のリンク（builders.flash）を追加 — 本ブログは、ソリューションアーキテクトの平井が作成しました。

本記事では、トラベルアシスタントアプリの作成方法について説明します。このアプリは、ユーザーの希望する目的地における人気の観光スポット、地域の体験、隠れた名所などをお勧めすることで、パーソナライズされた体験を提供します。このアプリの構築には、 AWS Amplify と Amazon Bedrock を使用します。 AWS Amplify Gen 2 は、バックエンド定義に TypeScript ベースのコードファーストの開発者体験（DX）を採用しています。Gen 2 の DX は、ホスティング、バックエンド、UI ビルド機能を備えた統合された Amplify 開発者体験と、コードファーストのアプローチを提供します。Amplify は、フロントエンド開発者がアプリのデータモデル、ビジネスロジック、認証、認可ルールの全てを TypeScript で表現するだけで、クラウドインフラストラクチャをデプロイできるようにします。Amplify は適切なクラウドリソースを自動的に設定し、基盤となる AWS サービスを手作業で統合する必要性を排除します。 Amazon Bedrock は、主要な AI 企業が提供する高性能な基盤モデル（FM）をフルマネージド型で提供するサービスです。これらの FM は単一のアプリケーションプログラミングインターフェース（API）を通じてアクセス可能で、安全で、プライベートで、責任ある生成 AI アプリケーションを構築するための機能も併せて提供されます。単一の API アクセスにより、異なる FM を柔軟に使用でき、最小限のコード変更で最新のモデルバージョンにアップグレードすることができます。 前提条件 AWS アカウント （Amplify は AWS 無料枠 の対象です） Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキストエディタ（このガイドでは VSCode を使用しますが、お好みの IDE を使用可能です） Amazon Bedrock での Claude 3 Haiku モデルへのアクセス権 リポジトリのクローン ステップ 1 : AWS Samples の リポジトリ に移動し、あなたの GitHub リポジトリにフォークします。 ステップ 2 : 以下のコマンドをターミナルで実行して、アプリをクローンします。 git clone https://github.com/ < YOUR_GITHUB > /travel-personal-assistant.git Bash ステップ 3 : 以下のコマンドをターミナルで実行して、新しくクローンしたリポジトリに VSCode でアクセスします。 cd travel-personal-assistant code . -r Bash VSCode が、次のセクションで説明するバックエンドの詳細を含む Amplify フォルダを含むリポジトリフォルダを開きます。 ステップ 4 : 以下のコマンドを実行して、Amplify パッケージを含む必要なパッケージをインストールします。 npm i Bash Amplify バックエンド 完成したアプリ（冒頭の GIF で示したもの）では、ユーザーは旅行に関する質問（例：「12 月にアイルランドに 7 日間行きたい」）を送信することで会話を開始します。コードはクローンしたリポジトリにあります。ここでは、Amplify アプリを Amazon Bedrock と接続するための主要なステップを説明します。 リポジトリには、auth（認証）、data（データ）、functions（関数）リソース用のディレクトリを含む amplify フォルダがあります。 デフォルトでは、 amplify/auth/resource.ts ファイルで設定された認証リソースは、ユーザーのサインアップメカニズムとしてメールを使用するように設定されています。 import { defineAuth } from '@aws-amplify/backend' ; /** * Define and configure your auth resource * @see https://docs.amplify.aws/gen2/build-a-backend/auth */ export const auth = defineAuth ( { loginWith : { email : true , } , } ) ; TypeScript amplify/data/resource.ts ファイルでは、文字列を返し、会話全体を含む JSON 文字列引数 conversation を引数にとる GraphQL クエリ chat を定義しています。認証は .authorization((allow) => [allow.authenticated()]) を使用して、認証されたユーザーのみがこのクエリにアクセスできるように設定されています。 .handler(a.handler.function(personalAssistantFunction)) の行は、このクエリのカスタムハンドラーとして personalAssistantFunction を設定します。 import { type ClientSchema , a , defineData } from "@aws-amplify/backend" ; import { personalAssistantFunction } from "../functions/personal-assistant/resource" ; const schema = a . schema ( { chat : a . query ( ) . arguments ( { conversation : a . json ( ) . required ( ) , } ) . returns ( a . string ( ) ) . authorization ( ( allow ) => [ allow . authenticated ( ) ] ) . handler ( a . handler . function ( personalAssistantFunction ) ) , } ) ; export type Schema = ClientSchema < typeof schema > ; export const data = defineData ( { schema , authorizationModes : { defaultAuthorizationMode : "userPool" , } , } ) ; TypeScript personalAssistantFunction Lambda 関数は、 amplify/functions/personal-assistant/resource.ts ファイルで定義・エクスポートされています。ここでは、環境変数 MODEL_ID を Claude 3 Haiku に設定しています。 import { defineFunction } from "@aws-amplify/backend" ; export const MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0" ; export const personalAssistantFunction = defineFunction ( { entry : "./handler.ts" , environment : { MODEL_ID , } , timeoutSeconds : 30 , runtime : 20 , } ) ; TypeScript amplify/functions/personal-assistant/handler.ts ファイルには、 personalAssistantFunction ハンドラーの実装が含まれています。ここでは、Bedrock ランタイムクライアントを初期化し、クエリの入力パラメータ conversation と systemPrompt 定数（応答方法に関するコンテキスト、指示、ガイドラインを Amazon Bedrock への提供するため）を使用して入力オブジェクトを生成し、それを使用して ConverseCommand を作成し、ランタイムクライアントを使用して Amazon Bedrock に送信します。応答のエラーを確認し、JSON 文字列として返します。 import { BedrockRuntimeClient , ConverseCommandInput , ConverseCommand , } from "@aws-sdk/client-bedrock-runtime" ; import type { Handler } from "aws-lambda" ; // Constants const AWS_REGION = process . env . AWS_REGION ; const MODEL_ID = process . env . MODEL_ID ; // Configuration const INFERENCE_CONFIG = { maxTokens : 1000 , temperature : 0.5 , } ; // Initialize Bedrock Runtime Client const client = new BedrockRuntimeClient ( { region : AWS_REGION } ) ; export const handler : Handler = async ( event ) => { const { conversation } = event . arguments ; const SYSTEM_PROMPT = ` To create a personalized travel planning experience, greet users warmly and inquire about their travel preferences such as destination, dates, budget, and interests. Based on their input, suggest tailored itineraries that include popular attractions, local experiences, and hidden gems, along with accommodation options across various price ranges and styles. Provide transportation recommendations, including flights and car rentals, along with estimated costs and travel times. Recommend dining experiences that align with dietary needs, and share insights on local customs, necessary travel documents, and packing essentials. Highlight the importance of travel insurance, offer real-time updates on weather and events, and allow users to save and modify their itineraries. Additionally, provide a budget tracking feature and the option to book flights and accommodations directly or through trusted platforms, all while maintaining a warm and approachable tone to enhance the excitement of trip planning. ` ; const input = { modelId : MODEL_ID , system : [ { text : SYSTEM_PROMPT } ] , messages : conversation , inferenceConfig : INFERENCE_CONFIG , } as ConverseCommandInput ; try { const command = new ConverseCommand ( input ) ; const response = await client . send ( command ) ; if ( ! response . output ?. message ) { throw new Error ( "No message in the response output" ) ; } return JSON . stringify ( response . output . message ) ; } catch ( error ) { console . error ( "Error in chat handler:" , error ) ; throw error ; // Re-throw to be handled by AWS Lambda } } ; TypeScript amplify/backend.ts ファイルでは、 addToRolePolicy メソッドを使用して、 personalAssistantFunction 関数のプリンシパルに新しいポリシーを追加します。ポリシーステートメントは、許可されたリソースとアクションを指定します。この場合、リソースは Claude 3 Haiku モデルの AWS ARN（Amazon Resource Name）で、許可されたアクションは bedrock:InvokeModel です。 import { defineBackend } from "@aws-amplify/backend" ; import { auth } from "./auth/resource" ; import { data } from "./data/resource" ; import { Effect , PolicyStatement } from "aws-cdk-lib/aws-iam" ; import { personalAssistantFunction , MODEL_ID } from "./functions/personal-assistant/resource" ; export const backend = defineBackend ( { auth , data , personalAssistantFunction , } ) ; backend . personalAssistantFunction . resources . lambda . addToRolePolicy ( new PolicyStatement ( { effect : Effect . ALLOW , actions : [ "bedrock:InvokeModel" ] , resources : [ ` arn:aws:bedrock:*::foundation-model/ ${ MODEL_ID } ` , ] , } ) ) ; TypeScript アプリを実行すると（次のセクションで説明）、 amplify_outputs.json という名前のファイルが自動的に生成されます。このファイルには API のエンドポイントの詳細が含まれています。 src/app/amplify-utils.ts では、以下のように Amplify クライアントライブラリを初期化・設定します。そして、Amplify バックエンドへのリクエストを容易にするためのデータクライアントを作成します。 import { generateClient } from "aws-amplify/api" ; import { Schema } from "../../amplify/data/resource" ; import { Amplify } from "aws-amplify" ; import outputs from "../../amplify_outputs.json" ; Amplify . configure ( outputs ) ; export const amplifyClient = generateClient < Schema > ( ) ; TypeScript src/app/layout.tsx ファイルでは、アプリのコンテンツを AuthWrapper コンポーネント（ src/app/components/AuthWrapper.tsx ）でラップしています。このコンポーネントは Amplify Authenticator を利用して、ユーザーがサインアップ、サインイン、パスワードリセット、多要素認証（MFA）のためのサインイン確認を行える完全な認証フローを提供します。 "use client" ; import { Authenticator } from "@aws-amplify/ui-react" ; import { ReactNode } from "react" ; interface AuthWrapperProps { children : ReactNode ; } export function AuthWrapper ( { children } : AuthWrapperProps ) { return < Authenticator > { children } < / Authenticator > ; } TypeScript アプリは、 src/app/page.tsx ファイルを使用して、AI アシスタントとチャットするためのコンポーネント（ src/app/components/Chat.tsx ）をユーザーに提供します。 "use client" ; import { Button , View , Heading , Flex , Text } from "@aws-amplify/ui-react" ; import Chat from "@/components/Chat" ; import { useAuthenticator } from "@aws-amplify/ui-react" ; export default function Home ( ) { const { user , signOut } = useAuthenticator ( ) ; return ( < View className = "app-container" > < Flex as = "header" justifyContent = "space-between" alignItems = "center" padding = "1rem" > < Text fontWeight = "bold" > { user ?. signInDetails ?. loginId } < / Text > < Heading level = { 3 } > Travel Personal Assistant < / Heading > < Button onClick = { signOut } size = "small" variation = "destructive" > Sign out < / Button > < / Flex > < View as = "main" > < Chat / > < / View > < / View > ) ; } TypeScript src/app/components/Chat.tsx ファイルでは、AI アシスタントとの会話を促進するためのシンプルなチャットインターフェースを作成しています。ユーザーのメッセージを取得するためのフォームを表示し、送信されると、 fetchChatResponse 関数を使用してチャットクエリを呼び出します。この際、現在の会話とユーザーの新しいメッセージをパラメータとして渡し、アシスタントの応答を取得して会話を更新します。 import React , { ChangeEvent , useEffect , useRef , useState } from "react" ; import { Button , Placeholder , View } from "@aws-amplify/ui-react" ; import { amplifyClient } from "@/app/amplify-utils" ; // Types type Message = { role : string ; content : { text : string } [ ] ; } ; type Conversation = Message [ ] ; export function Chat ( ) { const [ conversation , setConversation ] = useState < Conversation > ( [ ] ) ; const [ inputValue , setInputValue ] = useState ( "" ) ; const [ error , setError ] = useState ( "" ) ; const [ isLoading , setIsLoading ] = useState ( false ) ; const messagesRef = useRef ( null ) ; const handleInputChange = ( e : ChangeEvent < HTMLInputElement > ) => { setError ( "" ) ; setInputValue ( e . target . value ) ; } ; const handleSubmit = ( e : React . FormEvent < HTMLFormElement > ) => { e . preventDefault ( ) ; if ( inputValue . trim ( ) ) { const message = setNewUserMessage ( ) ; fetchChatResponse ( message ) ; } } ; const fetchChatResponse = async ( message : Message ) => { setInputValue ( "" ) ; setIsLoading ( true ) ; try { const { data , errors } = await amplifyClient . queries . chat ( { conversation : JSON . stringify ( [ ... conversation , message ] ) , } ) ; if ( ! errors && data ) { setConversation ( ( prevConversation ) => [ ... prevConversation , JSON . parse ( data ) , ] ) ; } else { throw new Error ( errors ?. [ 0 ] . message || "An unknown error occurred." ) ; } } catch ( err ) { setError ( ( err as Error ) . message ) ; console . error ( "Error fetching chat response:" , err ) ; } finally { setIsLoading ( false ) ; } } ; useEffect ( ( ) => { const lastMessage = conversation [ conversation . length - 1 ] ; console . log ( "lastMessage" , lastMessage ) ; ( messagesRef . current as HTMLDivElement | null ) ?. lastElementChild ?. scrollIntoView ( ) ; } , [ conversation ] ) ; const setNewUserMessage = ( ) : Message => { const newUserMessage : Message = { role : "user" , content : [ { text : inputValue } ] , } ; setConversation ( ( prevConversation ) => [ ... prevConversation , newUserMessage , ] ) ; setInputValue ( "" ) ; return newUserMessage ; } ; return ( < View className = "chat-container" > < View className = "messages" ref = { messagesRef } > { conversation . map ( ( msg , index ) => ( < View key = { index } className = { ` message ${ msg . role } ` } > { msg . content [ 0 ] . text } < / View > ) ) } < / View > { isLoading && ( < View className = "loader-container" > < p > Thinking ... < / p > < Placeholder size = "large" / > < / View > ) } < form onSubmit = { handleSubmit } className = "input-container" > < input name = "prompt" value = { inputValue } onChange = { handleInputChange } placeholder = "Type your message..." className = "input" type = "text" / > < Button type = "submit" className = "send-button" isDisabled = { isLoading } loadingText = "Sending..." > Send < / Button > < / form > { error ? < View className = "error-message" > { error } < / View > : null } < / View > ) ; } export default Chat ; TypeScript アプリの実行 ステップ 1 : Amplify は各開発者に個人のクラウドサンドボックス環境を提供し、迅速な構築、テスト、反復のための独立した開発スペースを提供します。クラウドサンドボックス環境を開始するには、新しいターミナルウィンドウを開き、以下のコマンドを実行します。 npx amplify sandbox Bash ステップ 2 : 以下のコマンドを実行して、ローカルホストの開発サーバーを起動します。 npm run dev Bash ステップ 3 : アプリのテスト後、 Ctrl+c でサンドボックスセッションを終了できます。サンドボックス環境のすべてのリソースを削除するプロンプトで Y を選択してください。 [ Sandbox ] Watching for file changes .. . File written: amplify_outputs.json ? Would you like to delete all the resources in your sandbox environment ( This cannot be undone ) ? ( y/N ) Y Bash アプリのデプロイ アプリが正しく機能することを確認したら、Amplify でデプロイしてホストしましょう。Amplify は、Git ブランチを使用した本番環境とステージング環境の設定を簡素化する、組み込みの CI/CD を備えたフルマネージド型のホスティングサービスを提供します。Gen 2 では、リポジトリの各 Git ブランチが、Amplify のフルスタックブランチに直接対応します。 ステップ 1 : AWS コンソールにサインインし、希望する AWS リージョンを選択します。AWS Amplify コンソールを開き、“Create new app” を選択します。 ステップ 2 : “Start building with Amplify“ ページで、“Deploy your app” から GitHub を選択し、“Next“ を選択します。 ステップ 3 : プロンプトが表示されたら、GitHub で認証を行います。自動的に Amplify コンソールにリダイレクトされます。アプリのリポジトリとメインブランチを選択し、“Next” を選択します。 ステップ 4 : 設定を確認し、“Next” を選択します。 ステップ 5 : 最後に、“Save and Deploy” ボタンをクリックしてデプロイプロセスを開始します。 ステップ 6 : デプロイプロセスが完了するのを待ち、“Visit deployed URL” ボタンをクリックして Web アプリを開くことができます。 リソースのクリーンアップ このチュートリアルが終了したら、予期しないコストを防ぐために、下図のように Amplify コンソールからアプリを削除してバックエンドリソースを削除することができます。 まとめ おめでとうございます！AWS Amplify Gen 2 と Amazon Bedrock を使用して、AI 搭載のトラベルアシスタントアプリの開発に成功しました。さらに、Amplify Hosting を使用して AWS 上にアプリをデプロイしました。Amplify Gen 2 を開始するには、 クイックスタートチュートリアル を試してみてください。また、フィードバックや機能リクエストを残すために、 コミュニティ Discord に参加することもできます。 本記事は、 Creating a Generative AI Travel Assistant App with Amazon Bedrock and AWS Amplify を翻訳したものです。翻訳は Solutions Architect の 都築 が担当しました。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people’s lives easier. You can find Mo on YouTube or on Twitter .

Blocksee は、非代替性トークン (NFT) やその他の暗号資産のマーケター向けに実用的な洞察を提供する Web3 の顧客関係管理 (CRM) とユーザーエンゲージメントソリューションを提供しています。 Blocksee は、Web3 製品マーケターがデジタルメンバーシップ、イベントチケット、プロモーションアセットに関心のあるユーザーから一次データを収集するため、Web サイトにコードスニペットを簡単に埋め込むか、または API にアクセスできるようにしています。 Amazon Managed Blockchain (AMB) などの AWS サービスによってサポートされている Blocksee は、従来のメールログインを利用した自動ウォレット作成から、NFT などのデジタル製品やサービスをユーザーが簡単に購入できるようにするクリック決済ソリューションまで、さまざまなツールを備えており、ブロックチェーンでサポートされたロイヤリティプログラム、トークンゲートされたコンテンツ、動的顧客ジャーニーを提供しようとするブランドにシームレスな移行を支援します。 デジタル資産と Web3 アプリケーションとのユーザー インタラクションに関するデータ駆動型の洞察を提供するために、Blocksee は Ethereum などの複数のパブリックブロックチェーンからオンチェーンデータの大量のデータを取り込み、分析する必要がありました。 このデータには、ファンジブルトークンやノン ファンジブルトークン (NFT) などのデジタル資産の現在および過去の所有権情報 (残高)、ならびに Web3 アプリケーションとそれらを下支えするスマートコントラクトとのユーザートランザクション/インタラクションが含まれていますが、これらに限定されるものではありません。 このデータを取得および処理するために、Blocksee はセルフマネージド型のブロックチェーン基盤から第三者のブロックチェーンデータプロバイダまでさまざまな技術ソリューションを検討しました。 抽出、変換、ロード (ETL) ワークフローとブロックチェーンデータのインデックス作成のためにブロックチェーンノードの運用に必要な計算、ストレージ、ネットワーキングリソースの高コストを考慮すると、セルフマネージド型のデータアーキテクチャではコスト効率の要件を満たすことはできないと Blocksee は判断しました。 ブロックチェーンノードの管理、データインデックス作成、ETL プロセスは特別なものではなく、自社で構築すると顧客向けの主要な機能開発に専念できなくなります。 Blocksee は次に、アプリケーションに必要なデータを提供できる第三者プロバイダを検討し、データニーズに対して複数の第三者プロバイダを使用したMinimum-Viable Product（MVP）を構築しました。しかし、Blocksee はデータの信頼性、コストパフォーマンス、データの品質に問題があり、ブロックチェーンデータのニーズに対する代替案を更に検討する必要がありました。Blocksee は、複数のプロバイダによる API からの集約された入力を使用するの方式から切り替え、パフォーマンスが高く信頼性のあるブロックチェーンデータを得るため、複数のパブリックブロックチェーンの統合ブロックチェーンデータ API である AMB Query を使用するようになりました。AMB Query を使うことで、Blocksee は複雑な複数のプロバイダによる API に対する開発サイクルを削減し、データニーズに対して予測可能な価格設定の単一の API を使用することでコストを最適化することができ、市場への投入時間を短縮することができました。 「AWS の Amazon Managed Blockchain サービスを利用する前の私たちのワークフローでは、チームが多数の RPC プロバイダーからデータフィードを集める必要があり、複雑な API の設定 と監視が必要でした。これにより開発期間が長くなり、ベンダーやステークホルダーとのフィードバックループが長期化していました。さらに、完全なデータセットを入手するために複数のサービスを支払う必要があったため、資金の非効率的な使用と、必ずしも高品質で信頼性の高いサービスを提供できるリソースを持たないスタートアップに過度に依存していました。Amazon Managed Blockchain を使えば、それらすべてを変えられます。信頼できる高速なブロックチェーンデータにアクセスできるようになり、当社のテクノロジースタックをより管理しやすく統合されたものにすることができました。」 – Eric Forst、Blocksee 共同創設者兼 CEO マーケターやプロジェクト管理者が Blocksee CRM ツールを立ち上げると、ブロックチェーンアドレス (ユーザー) に関するトークン残高データがスクリーン上に表示され、AI を用いたユーザーの行動分析などの追加の状況データと組み合わせて利用できるようになります。 以下は Blocksee のツールのスクリーンショットで、ユーザーが利用できるデータとインサイトの一例を示しています。 Blocksee は、ブロックチェインアドレスの ERC20 および ERC721 トークン残高を取得するために、AMB Query ListTokenBalances API を利用しています。これにより、特定のコントラクトによって生成された全てのトークンを照会できます。 ListTokenBalances API は、次のような様々な方法で利用できます。 特定のアドレス (コントラクトアドレスまたはウォレットアドレス) が保有しているすべてのトークンの残高をリストアップすること。 特定のコントラクトで作成されたすべてのトークンのオーナーとトークン残高をリストアップすること。 特定のトークン(例えば ERC-20 トークン)のすべてのオーナーの残高をリストアップすること。 1 つの API で、リストのそれぞれのアドレスに対して複数のトークンタイプの残高を取得できるようにしたことで、Blocksee が以前使用していたこのデータの取得と集約のメカニズムと比較して、パフォーマンスが 25 %向上し、コスト削減効果は 50 %と見積もられています。 Matt Kotnik さんは Blocksee の共同創設者兼 CTO で、AMB Query がアプリケーション実装に与えた影響について次のように述べています。 私たちは、 ListTokenBalances API を使用して、[ 前のプロバイダ ] に比べて 25 %以上のロード時間の改善ができるため、すでに大幅な読み込み速度の向上が見られています。また、Amazon のサービスが、チェーンにとらわれないシステムアーキテクチャを補完するものであるため、AMB はその他のブロックチェーンのサポート拡大にも貢献しています。これにより、デジタルインフラストラクチャの最も信頼できる名前の 1 つとのパートナーシップから得られる安心感があり、コア製品と顧客関係により重要な焦点を当てることができるようになりました。 AMB Query のデータクエリの REST API インターフェイスが標準化されているため、 一度に1 つまたは複数のブロックチェーンデータを問合せるリクエストの構文は大きく変わらないため、Blocksee は AMB Query でサポートされる新しいブロックチェーンを簡単に導入できます。 まとめ AMB Query が、米国東部 (バージニア北部) リージョンで一般提供開始になり、1秒未満のレイテンシーで履歴残高やトランザクションなどのブロックチェーンデータにアクセスできるようになりました。特別なインフラストラクチャを必要とすることなく、大規模かつ高速でブロックチェーンデータをお客様に提供します。 AMB Query のお客様は、主要なネットワークからのブロックチェーンデータを、実世界のアプリケーションがパフォーマンス要件を満たすスピードとスケールで受け取ることができます。お客様は、実行した API 呼び出しに対してのみシンプルで予測可能な料金を支払います。AMB Query の詳細については、 ユーザーマニュアル をご覧ください。その他の AMB 製品については、 Amazon Managed Blockchain をご覧ください。 本記事は、 How Blocksee built a Web3 CRM with blockchain data from Amazon Managed Blockchain Query を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津 颯騎 が担当しました。 著者について AJ Park は、AWS の Amazon Managed Blockchain チームでプロダクトマネージャーを務め、顧客向けのブロックチェーンと Web3 ソリューションの構築に情熱を注いでいます。それ以前は、20 年以上にわたりソフトウェア開発者とプロダクトマネージャーとしてデータ保護とストレージ分野で革新的な活動に取り組んでいました。 Forrest Colyer は、Amazon Managed Blockchain (AMB) サービスをサポートする Web3/Blockchain スペシャリスト ソリューションアーキテクトチームを管理しています。Forrest と彼のチームは、概念実証から本番環境まで、お客様のブロックチェーンワークロードの導入の各段階で深い技術的専門知識と戦略的指針を提供し、支援しています。コンソーシアムが主導するプライベートブロックチェーンソリューションと NFT や DeFi などのパブリックブロックチェーンの使用事例の両方の経験から、Forrest はお客様が高い影響力を持つブロックチェーンソリューションを特定して実装できるようサポートしています。

本ブログは 2024 年 10 月 26 日に公開されたBlog “ Exploring digital sovereignty: learning opportunities at re:Invent 2024 ” を翻訳したものです。 AWS re:Invent 2024 は、 Amazon Web Services (AWS) がクラウドコンピューティングのグローバルなコミュニティのために主催する学習型カンファレンスで、2024 年 12 月 2 日から 6 日まで、ネバダ州ラスベガスの複数の会場で開催されます。re:Invent では、クラウドを積極活用する人々が世界中から集まり、最新のクラウド業界のイノベーションを学び、AWS のエキスパートと会話し、人脈を築くことができます。深い技術的専門知識を身につけたい、投資の優先順位付けの方法を理解したい、設計段階からデジタル主権を考慮した AWS クラウドのサービスを詳しく知りたい、あるいは AWS Nitro System がワークロードのセキュリティをどのように強化するかを確認したいなど、re:Invent は私たちの デジタル主権 (Digital Sovereignty) ソリューションを探求する絶好の機会です。 今年は、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS Outposts など、AWS ハイブリッドやエッジサービスに関するセッションやハンズオンを通じて、高度なデジタル主権コントロール、セキュリティ機能、インフラストラクチャの選択肢について学ぶ多くの機会があります。 Expo では、AWS Village 内の Digital Sovereignty & Data Protection kiosk を訪れて、デモを見たり、近日利用開始予定の AWS European Sovereign Cloud について学んだり、AWS メンバーに質問や相談をすることができます。AWS が設計したチップや Outposts デバイスを見るには、AWS Village の AWS Next Gen Infrastructure Hub をチェックしてください。また、 AWS Partner Network (APN) ブースを訪れて、 AWS デジタル主権のパートナー に会って、パートナープログラムの利点を確認することもできます。 ブレイクアウトセッションとライトニングトーク セッションタイトルのリンクを選択するとセッション情報と時間場所を確認できます。AWS re:Invent のお客様のアジェンダにセッションの追加もできます。 SEC229 | ブレイクアウト | デジタル主権：複雑性を克服し、将来への準備を整える Max Peterson、VP、Sovereign Cloud、AWS 組織は、進化するデジタル主権の状況において、増大する複雑性に直面しています。強固なデジタル基盤を構築することで、イノベーションを妨げることなく、今日に求められている要件を満たし、組織の将来に備える取り組みを簡素化できます。このセッションでは、暗号化サービスから、発表されている AWS European Sovereign Cloud まで、AWS のソブリンクラウドサービスがどのようにして、お客様独自のニーズに応えるためにより多くのコントロールと選択肢が提供されているかを確認できます。お客様が AWS 上の生成 AI を含む新しいテクノロジーを活用する際に、重要なワークロードをどのように安全に保護しているかの方法と、AWS パートナーが提供する新しいデジタル主権ソリューションについて学びます。 HYB201 | ブレイクアウト | AWS を必要なあらゆる場所で：クラウドからエッジまで Jan Hofmeyr, VP, EC2 Networking and Hybrid Edge, AWS, and Jeff Feist, Executive Director – Hosting Solutions, Merck & Co., Inc. ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、またはデータ主権の要件により、一部はオンプレミスやエッジに残るかもしれません。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、 AWS IoT Core などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像処理、スマート製造、データ レジデンシー (所在地) 要件のある生成 AI アプリケーションなど、ハイブリッドクラウドおよびエッジコンピューティングワークロードをどのようにサポートするかについて学びます。 HYB309 | ブレイクアウト | ハイブリッドクラウドサービスによるデータレジデンシーに関するベストプラクティス Sherry Lin, Principal Product Manager, AWS; Lakshmi VP, Specialist SA – Hybrid Edge, AWS; and Kevin Ng, Senior Director, Core Engineering Products, GovTech データのプライバシー、セキュリティ、デジタル主権に関する懸念から、世界中の多くの政府が個人データや機密データを国境内に保持するためにデータ レジデンシー規制を強化しています。複数の地域で事業を展開する組織にとって、進化するデータ レジデンシー規制に対応することは課題となる可能性があります。このセッションでは、AWS Well-Architected Framework に従って、AWS Local Zones、AWS Dedicated Local Zones、AWS Outposts などのハイブリッドクラウドサービスを使用する際のデータ レジデンシーに関するベストプラクティスを紹介します。 IOT202 | ブレイクアウト | AWS IoTを活用したエッジにおけるLLMのデプロイと稼働 Nikit Pednekar, Principal Product Manager, AWS, and Stefano Marzani, WW Tech Leader, SDX, AWS 生成 AI と大規模言語モデル (LLM) の登場により、これらの技術を IoT エッジにどのように適用できるか気になっているのではないでしょうか。実際にエッジで LLM を実行することには多くの利点があります。ネットワーク帯域幅の有効利用、オフライン処理、低レイテンシー、データ主権の確保から、コスト削減、セキュリティ、差別化まで様々です。このセッションでは、AWS IoT サービスとエッジでの LLM の使用が、ジェスチャー認識、音声制御のための自然言語処理、リアルタイム予知保全、エネルギー最適化、異常検知などの実用的な成果と革新的な機能によって、ソリューションをどのように強化できるかを学びます。 KUB310 | ブレイクアウト | Amazon EKS のエッジおよびハイブリッドのユースケース Chris Splinter, Product Manager, AWS, and Gokul Chandra Purnachandra Reddy, Senior Solutions Architect, AWS 製造、ヘルスケア、通信、金融サービスなどの業界では、低レイテンシー、データの依存性、データ主権、その他の規制上の理由により、オンプレミス、エッジ、またはハイブリッドで実行する必要があるワークロードがあります。AWS サービスでデータを利用できるようになるまで、AWS への完全な移行を待つ必要があるかもしれません。このセッションでは、 Amazon EKS Anywhere などのサービスを活用して、オンプレミスでコンテナワークロードを実行し、VMware ベースのワークロードのモダナイズをサポートする実用的なアーキテクチャを紹介します。また、オンプレミスの Kubernetes デプロイメントを AWS クラウドに移行するためのベストプラクティスについても学びます。 PEX110 | ライトニング・トーク | パートナープログラムで成長と能力を加速 Mike Cannady, Director, Partner Core Public Sector, AWS 公共部門のビジネスを推進する AWS パートナープログラムの最新情報をご確認ください。このライトニング・トークに参加して、パートナー向けに特化したイノベーション (生成 AI プログラム、デジタル主権、ソリューション構築、マネージドサービスなど) を探索してください。初心者でもベテランでも、洞察とユースケースを得て、成長を加速して参加者のジャーニーを向上させることができます。この進化し続ける環境で、自己開発を加速し、先駆けの地位を確保しましょう。 インタラクティブセッション (チョークトークとワークショップ) (訳者注: チョークトーク（Chalk talk）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問できることもあります。) HYB304 | ワークショップ | データ主権を損なわずに RAG を実装する Aditya Lolla, Senior Solutions Architect, Hybrid Edge, AWS, and Robert Belson, Senior Developer Advocate, AWS 政府や標準化団体がデータ保護とプライバシーに関する規制を策定する中、組織はクラウド上の生成 AI ツールの使用と、データ主権の要件を満たすためにオンプレミスに保持する必要がある規制対象データを組み合わせる必要性が高まっています。このワークショップでは、 Amazon Bedrock の Agents を AWS Outposts や AWS Local Zones などのハイブリッドおよびエッジサービスに拡張し、オンプレミスデータを使用した検索拡張生成 (RAG) アプリケーションを構築してモデルの性能を向上させる方法を学びます。Amazon Bedrock、 AWS Lambda 、AWS ハイブリッドおよびエッジサービスをハンズオンで体験し、ハイブリッド Amazon Simple Storage Service (Amazon S3) 互換ソリューションを使用して Amazon S3 準拠のワークフローを構築します。参加の際はラップトップをご持参ください。 WPS207 | チョークトーク | AWS がデジタル主権の要件を満たすためにどのように支援できるか Mehmet Bakkaloglu, Principal Solutions Architect, AWS, and Addy Upreti, Principal Technical Product Manager – Digital Sovereignty, AWS 公共部門や、ヘルスケア、金融サービス、通信などの規制対象産業のお客様が、クラウドジャーニーにおいてデジタル主権に関する課題にどのように対処しているかを共有しています。このチョークトークでは、AWS が設計段階からデジタル主権を考慮していること、そしてデジタル主権のニーズを満たすことができる様々な機能について学ぶことができます。さらに、これらのニーズを満たすための選択肢をさらに提供するために、AWS European Sovereign Cloud がどのように構築されているかを確認できます。AWS がお客様の要件を満たしながら、クラウド移行をどのように加速できるかについて説明します。 HYB310 | チョークトーク | ハイブリッドおよびエッジサービスによるデータレジデンシー要件への対応 Sedji Gaouaou, Senior Solutions Architect, AWS, and Fabio Rodriguez, Head of Hybrid Cloud Solutions Architect, AWS データ レジデンシーは、個人識別情報 (PII)、金融データ、医療データ、または国家安全保障に関する情報など、センシティブな情報を収集・保存する組織にとって重要な考慮事項です。複数の地域で事業を展開する組織が、データ レジデンシー要件を満たしながらイノベーションを推進できるよう、AWS は AWS リージョン、AWS Dedicated Local Zones、AWS Local Zones、AWS Outposts など、複数のグローバルインフラストラクチャソリューションを提供しています。このインタラクティブなチョークトークセッションでは、これらのインフラストラクチャソリューションがデータ レジデンシーのニーズを満たしながら、デジタルトランスフォーメーションを加速させるのにどのように役立つかを紹介します。 パートナーとのセッションを含むデジタル主権に関するコンテンツの全容については、 AWS re:Invent カタログ を参照し、デジタル主権 (Digital Sovereignty) でフィルターをして絞り込んでください。現地参加できない方は、 バーチャル参加用の無料パスに登録 して、基調講演やイノベーショントークのライブ配信を視聴し、オンデマンドのブレイクアウトセッションにアクセスできます。ラスベガスでお会いできること、またはライブ配信でご参加いただけることを楽しみにしています！ Marta Taggart Marta はシアトルを拠点とする AWS セキュリティ製品マーケティングのプリンシパル・プロダクトマーケティングマネージャーで、デジタル主権に焦点を当てています。仕事以外では、保護犬のジャックが最高の人生を送れるようサポートしています。 Rachel Zheng Rachel はハイブリッドクラウドとエッジコンピューティングに焦点を当てたシニアプロダクトマーケティングマネージャーです。仕事以外の時間には、ハイキングをしたり、ベイエリアの新しいレストランを開拓したりしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 10 月 2 日に公開された「 Enhancing data privacy with layered authorization for Amazon Bedrock Agents 」を翻訳したものとなります。 お客様は、自社のアプリケーション内で生成 AI を使用することにいくつかの利点を見出しています。ただし、生成 AI を使用すると、アプリケーションの脅威モデルを検討する際に新たな考慮事項が追加されます。これは生成 AI の利用が、オペレーション効率を高めるために顧客体験を向上させるためであっても、よりカスタマイズされた特定の結果を生成するためであっても、その他の理由であっても同様です。 生成 AI モデルは本質的に非決定論的です。つまり、同じ入力が与えられても、モデルの確率的性質により、生成される出力は異なる場合があります。 Amazon Bedrock などのマネージドサービスをワークロードで使用する場合、Amazon Bedrock がアクセスするデータの保護を確実にするのに役立つ追加のセキュリティ上の考慮事項があります。 本ブログでは、生成 AI サービスを使用する際のデータのコントロールで直面する可能性のある現在の課題と、Amazon Bedrock 内のネイティブソリューションと階層化された認可を使用してそれらを克服する方法について説明します。 定義 まず始めに、いくつかの言葉の定義を確認してみましょう。 Amazon Bedrock エージェント: Amazon Bedrock エージェント を使用すると、企業のシステムやデータソースにわたる複数ステップのタスクを自律的に完了できます。エージェントは、入力データを充実させてより正確な結果を得ることや、繰り返しの多いタスクの自動化に使用できます。生成 AI エージェントは、エージェントがアクセスできる入力と環境のデータに基づいて意思決定を行うことができます。 階層化された認可: 階層化された認可とは、初めにアクセスされるポイントからアプリケーションコンポーネント間で複数の認可チェックを実装する手法です。これには、サービス間の認可、アプリケーションコンポーネント全体で真のエンドユーザーのアイデンティティを伝達すること、そしてサービスの認可に加えて各操作にエンドユーザーの認可を追加することが含まれます。 信頼できるアイデンティティの伝搬: 信頼できるアイデンティティを伝搬することで、AWS リソースへのユーザーアクセスの定義、付与、およびログ記録がより簡単になります。信頼できるアイデンティティの伝播は OAuth 2.0 の認可フレームワークに基づいて構築されているため、アプリケーションはパスワードを共有しなくてもユーザーデータに安全にアクセスして共有できます。 Amazon Verified Permissions: Amazon Verified Permissions は、証明可能な正しい Cedar ポリシー 言語を使用するフルマネージド型の認可サービスであり、より安全なアプリケーションを構築できます。 チャレンジ AWS で構築する場合、データやお客様の情報を安全に保つのに役立ついくつかのサービスや機能があります。これには、 Amazon Simple Storage Service (Amazon S3) のデフォルト暗号化や AWS Key Management Service (AWS KMS) キーによる保存時の暗号化、または Amazon S3 のプレフィックスや Amazon DynamoDB のパーティションキーを使用してテナントのデータを分離することが含まれます。これらのメカニズムは、保存中のデータの処理やデータパーティションの分離には優れています。しかし生成 AI を搭載したアプリケーションがユーザーの入力に基づいてさまざまなデータ（異なるタイプの機微データ、複数のテナントのデータなど）にアクセスできるようになると、機微データが漏洩するリスクが高まります（AWS のデータプライバシーの詳細については、 データプライバシーに関するよくある質問 を参照してください）。これは、データへのアクセスが、ワークロードのなかで呼び出し元のプリンシパルに代わって信頼できないアイデンティティ (モデル) に渡されるためです。 多くのお客様が、ユーザーの入力に追加情報を付加して応答を改善するために、アーキテクチャに Amazon Bedrock エージェント を使用しています。またエージェントは、反復的なタスクを自動化し、ワークフローを効率化するためにも使用されます。たとえば、チャットボットは、医療提供者向けに患者の検査結果をまとめるなど、ユーザーエクスペリエンスを向上させるための便利なツールになります。ただし、チャットボットソリューションを実装する際には、潜在的なセキュリティリスクと緩和戦略を理解することが重要です。 一般的な生成 AI アプリケーションのアーキテクチャには、 Amazon API Gateway を介してチャットボットエージェントを呼び出すものがあります。API Gateway は Amazon Cognito または AWS Lambda オーソライザーを使用して API 呼び出しを検証し、その後チャットボットエージェントにリクエストを渡してその機能を実行します。 チャットボットエージェントにユーザーが入力プロンプトを提供できる場合、潜在的なリスクが生じます。この入力により、プロンプトインジェクション（ OWASP LLM:01 ）または機微情報の漏出（ OWASP LLM:06 ）の脆弱性につながる可能性があります。根本的な原因は、チャットボットエージェントがその機能を果たすために、さまざまなデータストア (S3 バケットやデータベースなど) へのアクセス権を持つ AWS Identity and Access Management (IAM) サービスロール による広範なアクセス権限を必要とすることです。適切なセキュリティコントロールがない場合、あるテナントの脅威アクターが、別のテナントに属するデータにアクセスしたり操作したりする可能性があります。 解決策 すべてのリスクを軽減できる単一のソリューションはありませんが、コンシューマーアプリケーションの適切な脅威モデルを用意してリスク (データへの不正アクセスなど) を特定することは重要です。AWS では、適切な脅威モデルを作成するのに役立つ、いくつかの生成 AI セキュリティ戦略を提供しています。本ブログでは、コンシューマーアプリケーションをサポートするソリューションを中心に、アプリケーション全体にわたる階層化された認可に注目します。 注 : これは、ワークフォースアプリケーション向けの Trusted identity propagation (TIP) と Amazon S3 Access Grants を使用して実現することもできます。 コンシューマー向けの OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) などの強力な認証プロセスを多要素認証 (MFA) と組み合わせて使用することで、API Gateway でエージェントを呼び出すためのアクセスを統制できます。図 1 に示すように、リクエストのヘッダーにある JWT トークンを使用して、エージェントにカスタムパラメーターを渡すことをお勧めします。このような構成では、エージェントが記述された機能を実行する前に、 Amazon Verified Permissions を使用して isAuthorized リクエストを評価し、呼び出しユーザーが要求されたデータにアクセスできることを確認します。このアーキテクチャを図 1 に示します。 図 1: 認可アーキテクチャ アーキテクチャの手順は次のとおりです。 クライアントはアプリケーションフロントエンドに接続します。 クライアントは、認証のための Amazon Cognito ユーザープール UI へリダイレクトされます。 クライアントは Amazon Cognito から JWT トークンを受け取ります。 アプリケーションフロントエンドは、クライアントから提示された JWT トークンを使用して Amazon Bedrock エージェントへのリクエストを認可します。アプリケーションフロントエンドは、 InvokeAgent API 呼び出しに JWT トークンを追加します。 エージェントはリクエストを確認し、必要に応じてナレッジベースを呼び出たり、Lambda 関数を呼び出したりします。エージェントは、アプリケーションフロントエンドから提供された JWT トークンを Lambda 呼び出しコンテキストに含めます。 Lambda 関数は JWT トークンの詳細を使用して、Verified Permissions を使用して DynamoDB テーブルへの以降の呼び出しを認可します(6a)。呼び出しが認可された場合のみ DynamoDB テーブルを呼び出します (6b)。 ディープダイブ Amazon Bedrock エージェントをトリガーする API Gateway の背後にあるアプリケーションを設計する場合を考えます。このとき、 AssumeRole により Amazon Bedrock へのアクセス権を付与する信頼ポリシーを使用して、エージェント用の IAM サービスロールを作成する必要があります。このロールにより、Amazon Bedrock はエージェントアクショングループの Lambda 関数用 OpenAPI スキーマを S3 バケットから取得でき、指定されたモデルへの bedrock:InvokeModel アクションが可能になります。エージェントのセッションデータを暗号化するためにデフォルトの KMS キーを選択しなかった場合は、カスタマー管理の KMS キーにアクセスするための権限を IAM サービスロールに付与する必要があります。ポリシーと信頼関係の例を次に示します。 次のポリシーは、Amazon Bedrock モデルを呼び出す権限をエージェントに付与します。“Resource“ では、承認された基盤モデル(FM)を対象としています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicy", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:us-west-2::foundation-model/your_chosen_model" ] } ] } Plain text 次に、Amazon Bedrock エージェントに s3:GetObject へのアクセスを許可するポリシーステートメントを追加します。このステートメントでは、アカウント番号が組織内のアカウント番号と一致する S3 バケットを対象とします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentDataStorePolicy", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::S3BucketName/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Account_Number" } } } ] } Plain text 最後に、定義されたロールを引き受ける権限を Amazon Bedrock に付与する信頼ポリシーを追加します。また、 混乱する代理問題 を防ぐため、サービスがアカウントに代わって呼び出していることを確認するための条件も追加しました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentTrustPolicy", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "Account_Number" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock:us-west-2:Account_Number:agent/*" } } } ] } Plain text Amazon Bedrock エージェントはサービスロールを使用しており 、一般には利用者のアイデンティティを伝搬しません。これは、テナントのデータを保護する上での潜在的な問題につながる可能性があります。エージェントが未分類のデータ（訳者注: 保護の必要ないデータ）にアクセスしている場合、認可の呼び出し元に基づいてアクセスをさらに分離する必要がないため、階層化された認可を追加する必要はありません。ただし、アプリケーションが機微データにアクセスできる場合は、認可をエージェントの機能の処理に加える必要があります。 そのためには、エージェントを呼び出してトリガーされる Lambda 関数に認可の階層を追加します。まず、エージェントを初期化して、 Verified Permissions への isAuthorized 呼び出しを行います。 Allow 応答があった場合にのみ、エージェントは残りの機能を実行します。Verified Permissions からの応答が Deny の場合、エージェントはステータス 403 またはわかりやすいエラーメッセージをユーザーに返す必要があります。 Verified Permissions には、データへのアクセス時にどのように認可を行うかを規定するポリシーがあらかじめ組み込まれている必要があります。たとえば、呼び出し元のプリンシパルが医師の場合に、患者の記録へのアクセスを許可する次のようなポリシーがあるかもしれません。 permit( principal in Group::"doctor", action == Action::"view", resource ) when { resource.fileType == Sensitive && resource.patient == doctor.patient }; Plain text この例では、この決定を処理する認可ロジックはエージェントから呼ばれる Lambda 内にあります。そのために、Lambda 関数はまず、Amazon Bedrock エージェントにカスタムパラメータとして渡された JWT をデコードしてエンティティ構造を構築し、呼び出し元のプリンシパルのアクセスを評価します。リクエストされたデータには isAuthorized 呼び出しも含める必要があります。このデータが Verified Permissions に渡されると、提供されたコンテキストとポリシーストア内のポリシーを評価しアクセス可否を決定します。ポリシー決定ポイント (Policy Decision Point: PDP) として、許可または拒否の決定はアプリケーションレベルで実施する必要があることに注意します。この決定に基づいて、データへのアクセスが許可または拒否されます。アクセスされるリソースは、アプリケーションがアクセス制御を評価しやすいように分類する必要があります。たとえば、データが DynamoDB に保存されている場合、患者は Verified Permissions スキーマで定義された階層的に参照されるパーティションキーで区切ることも考えられます。 結論 本ブログでは、AWS ネイティブサービスを使用して Amazon Bedrock エージェントを使用するコンシューマーアプリケーション全体に階層化された認可を適用することで、データ保護を向上させる方法を学びました。また、 アイデンティティプロセスを通じてアクセス制御の適用を改善する手順を説明しました。これは Amazon Bedrock エージェントを使用してアプリケーションを構築するのに役立ち、データの強力な分離を維持することで意図しない機密データの漏洩を防ぐことができます。 Verified Permissions と Amazon Bedrock エージェントを使用してアプリケーション全体に階層化された認可を適用する方法について詳しく学ぶには、「 Secure Generative AI Solutions using OWASP Framework 」ワークショップをお勧めします。 本ブログについて質問がある場合は、 AWS サポートにお問い合わせください 。 Jeremy Ware Jeremy は、生成 AI ワークロードの ID アクセス管理とセキュリティを専門とするシニアセキュリティスペシャリストソリューションアーキテクトです。Jeremy と彼のチームは、AWS のお客様が高度でスケーラブルで安全なワークロードを実装してビジネス上の課題を解決できるよう支援しています。Jeremy は長年にわたり、多くのグローバル企業でセキュリティの成熟度を向上させてきました。自由時間には、Jeremy は家族と一緒にアウトドアを楽しんでいます。 Yuri Duchovny Yuri はニューヨークを拠点とするプリンシパルソリューションアーキテクトで、クラウドセキュリティ、アイデンティティ、コンプライアンスを専門としています。Yuri は大企業のクラウド変革を支援し、企業が最適なテクノロジーと組織的な意思決定を行えるよう支援しています。AWS での職務に就く前は、アプリケーションとネットワークのセキュリティ、DoS、不正防止に注力をしていました。仕事以外では、スキー、セーリング、世界中への旅行を楽しんでいます。 Jason Garman Jason は、バージニア州北部に拠点を置く AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。Jason は、世界の大手組織が重大なセキュリティ課題を解決できるよう支援しています。AWS に入社する前にはサイバーセキュリティ業界で、スタートアップを含む官民を問わないさまざまな役割を果たしていました。彼は出版作家で、サイバーセキュリティ技術に関する特許を保有しており、家族と一緒に旅行するのが大好きです。 翻訳はプロフェッショナルサービス本部の池澤、藤浦が担当しました。

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. Panel Discussion: A History of Digital Transformation Forged with AWS Shimpei Otani, Group Executive Officer (CTO & CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. Shigeru Horikawa, Director (Infrastructure), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yasuhiro Kitaguchi, Director (SCM & Integration Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yuichi Murata, Director (Core Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Kempei Igarashi, Senior Manager, Retail, Consumer Goods & Services Business Group, Amazon Web Services Japan G.K. Career and Responsibilities of the Panelists First, the panelists talked about their own careers. Mr. Otani joined Fast Retailing in 2016 with a mission of internalizing engineering and embedding technology in the business. Currently he is the Chief Technology Officer and also in charge of security. Regarding the relationship with AWS, almost all Fast Retailing services run on AWS, leveraging it for over 12 years. He also shared the facts that he was actually an AWS Solutions Architect in his previous role and had visited Fast Retailing as a service provider during that time. Since joining in 2012, Mr. Horikawa has experienced shifting from on-premises to cloud, with 12 years of experience working with AWS. Entering a company like Fast Retailing meant a major shift in his goals as an engineer, from system implementation to business results themselves. Since joining in 2018, Mr. Kitaguchi has been responsible for developing common platforms and the data integration platform. Currently his focus is on logistics process reform and preparing digital tools. His AWS involvement began after joining Fast Retailing, consulting with AWS product teams when building new systems to determine optimal architectures. Mr. Murata joined in 2017 and experienced the Ariake Project from launch. Starting with developing back-end systems for e-commerce, he went through roles in infrastructure and quality assurance before becoming department manager overseeing in-house development (his current role). E-commerce heavily utilizes AWS with ongoing support. He also introduced a new initiative leveraging Amazon Connect to reform call center operations. Dawn Period – Fostering Culture The discussion began with the theme “Dawn Period – Fostering Culture”. Mr. Horikawa, with the longest tenure, looked back on episodes from when he joined. He learned AWS through seminars and vendor support. Before deciding to use AWS, he gained experience while receiving support from AWS Solutions Architects and others. Initially there were no architecture review processes, and failures like system outages due to lack of quality assurance occurred. Architecture reviews were born by learning from such failures. Mr. Otani shared stories about the Ariake automated warehouse project, which unlike IT projects, had physical constraints like installing the warehouse hardware, giving him a taste of the pains unique to an apparel company. The project was still chaotic then without a clear picture, but consistently recruiting talented people has created an environment conducive to exchanging wisdom. Addressing critical issues collaboratively naturally fostered the current culture. Mr. Horikawa also talked about negotiating with AWS over a 4TB database instance for an SAP implementation. At the time he believed it could only be done on-premises, but looking ahead to future growth, he negotiated with AWS and made it happen. This experience taught him that even seemingly impossible things could be achieved through proper negotiation. As described above, Fast Retailing fostered their current culture by overcoming various failures and challenges with AWS from the dawn period of adoption. Unafraid to challenge and collaborate to solve issues formed the foundation of their culture. Closely cooperating with AWS to nurture this new culture was a major factor enabling Fast Retailing’s digital transformation. Transition Period – Architectural Changes The next theme was the transition period when the team at Fast Retailing implemented many architectural changes. Mr. Murata discussed shifting from the conventional monolithic EC package to a headless platform architecture, achieving microservices, immutable infrastructure adoption, multi-region deployment, leveraging open source and managed services, and standardizing technology. He reflected on the complexity of business logic and challenges with performance and scalability. Mr. Kitaguchi explained how they initially started by just lifting and shifting their on-premise applications onto the cloud, and then gradually moved towards containerization and building CI/CD pipelines with global deployment in mind. Cost-conscious tool provision and close collaboration with business departments for cost awareness were also covered. Mr. Otani talked about standardization initiatives. The background of adopting Amazon Aurora and Amazon ElastiCache as a standard and establishing criteria for programming languages and frameworks was introduced. The struggles with proliferating tools seem to have driven the perception that some standardization is essential. On the other hand, Mr. Otani also pointed out the importance of maintaining appropriate flexibility in technology selection. Excessive standardization causes loss of flexibility, so preserving suitable options for engineers is also important. These standardization efforts occurred during large-scale concurrent development. Architectural transformation was carried out in stages looking ahead to global expansion, achieving a break-down into platforms and microservices, achieving standardization, etc. Expansion Period – Globalization Regarding globalization challenges, Mr. Murata talked about local considerations. They operate multiple brands across roughly 30 markets, requiring a global platform while also addressing needs from each country. Proper prioritization and efficiency are important, but a “global-solution” does not necessarily fit all regions. Aspects like delivery methods and data privacy handling require localization. Mr. Otani added that technical issues cannot always be decided solely by engineers, sometimes requiring management judgment considering geopolitical risks. Mr. Horikawa talked about network optimization changes. Initially all store communication concentrated to Tokyo, but now leveraging the AWS network fully, connecting each country directly to the nearest AWS Region improved speed and availability by utilizing the AWS backbone network. Mr. Kitaguchi said based on the characteristics of location-based systems with high customization and requirements variation, they take an approach of building global core aspects like consistent inventory management and streamlining shipping/receiving workflows, then adding localized custom wrappers. Cultural alignment is also important in multinational teams. Shared values represented in the mission statement foster decision-making and unity in diverse teams. Building an inclusive environment through mission sharing offers something to learn for any organization driving a cloud journey. Security Mr. Otani, also CSO, commented on security. Information systems today especially require enterprise-wide security uplift. Security encompasses many aspects beyond just technology, like executive awareness and physical measures. In addition to IT security, operational measures are indispensable for protecting customer information. Fast Retailing aims not just to meet IT security standards, but exceed them. He emphasized holistically addressing security aligned to corporate mission and ingraining appropriate standards into organizational culture. However, excessive security rigidness risks losing the creativity and added value that IT brings. Striking the right balance between security and IT flexibility is key, with an important security team role being to maintain that balance. Summary Closing comments by members are summarized as follows: Selecting cloud and platform products should consider not just current capabilities, but future evolution based on organizational culture. AWS was initially established to address the business challenges of Amazon, a company rooted in retail. AWS shares a customer-centric culture with Fast Retailing in many ways. Fast Retailing evaluated AWS as a company that continues to evolve in order to address customer needs. Reflecting on their 12-year collaboration, Fast Retailing aims to strengthen strategic partnership with AWS for global expansion. Finally, they concluded the panel discussion with a heartfelt message inviting engineers from diverse backgrounds to join them and grow the team. Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail