本ブログは 2023 年 9 月 28 日に公開されたBlog ” How AWS threat intelligence deters threat actors ” を翻訳したものです。 Amazon Web Services (AWS) のクラウドインフラストラクチャ全体で、私たちは毎日、混乱や損害を引き起こす可能性のある何百ものサイバー攻撃を検知し、成功裏に阻止しています。これらの重要ではあるものの、ほとんど表に出ない成果は、グローバルなセンサーネットワークと、それに関連する一連の防御ツールによって達成されています。これらの機能を使用することで、私たちのネットワーク、インフラストラクチャ、そしてお客様に対するサイバー攻撃の実行をより困難かつコストも高くなるようにしています。さらに、他の責任ある事業者と協力して、彼らのインフラストラクチャ内で活動する脅威アクター(攻撃者)に対して行動を起こすことで、インターネット全体をより安全な場所にすることにも貢献しています。クローバル規模の脅威インテリジェンスを迅速な行動に変えることは、セキュリティを最優先事項とする私たちのコミットメントの一環として行っている多くのステップの 1 つに過ぎません。これは終わりのない取り組みであり、私たちの能力は常に向上していますが、私たちは今、お客様やその他の利害関係者に現在行っていることと将来の方向性について知っていただくべき時期に来たと考えています。 AWS クラウドを使用したグローバル規模の脅威インテリジェンス AWS は、クラウドプロバイダーの中で最大のパブリッククラウドのネットワーク規模を持ち、その規模により、インターネット上の特定の活動について比類のない洞察や知見を得ることができます。数年前、AWS のプリンシパルセキュリティエンジニアである Nima Sharifi Mehr は、その規模を活かし、脅威に対抗するための情報収集に新たな手法を模索し始めました。これを受けて、私たちのチームは MadPot と呼ばれる社内ツールスイートの構築を開始しました。その結果、Amazon のセキュリティ研究者たちは、お客様に悪影響を与える可能性のある何千ものサイバー脅威を発見し、研究し、阻止することに成功しました。 MadPot は 2 つの目的を達成するために構築されました。1 つ目は、脅威活動の発見と監視、2 つ目は、AWS のお客様やその他の人々を保護するために、可能な限り有害な活動を阻止することです。MadPot は、洗練された監視センサーシステムと自動対応機能に成長しました。これらのセンサーは、世界中で毎日 1 億件以上の潜在的な脅威の相互作用とプローブ(探査)を観察し、そのうち約 50 万件の観察された活動が悪意のあるものとして分類されるレベルに達します。この膨大な脅威インテリジェンスデータは取り込まれ、相関付けられ、分析されて、インターネット全体で発生している潜在的に有害な活動に関する実行可能な洞察を提供します。自動対応機能は、特定された脅威から AWS ネットワークを自動的に保護し、インフラストラクチャが悪意のある活動に使用されている他の企業に対して連絡用のコミュニケーションを開始します。 このような種類のシステムは ハニーポット として知られています。これは脅威アクターの行動を捕捉するための囮（おとり）システムであり、長年にわたって貴重な観察と脅威インテリジェンスのツールとして機能してきました。しかし、MadPot を通じて私たちが取るアプローチは、AWS のスケールとシステムの背後にある自動化によって、独自の洞察を得ることができます。脅威アクターを引き付け、その行動を観察して対処できるようにするため、私たちはこの膨大なシステムを正当で無害に見えるターゲットで構成されているように設計しました。管理された安全な環境で実システムを模倣することで得られる観察結果や洞察は、多くの場合即座に活用でき、有害な活動の阻止やお客様の保護に役立ちます。 もちろん、脅威アクターはこのようなシステムが存在することを知っているため、彼らは頻繁に戦術を変更します。そして、私たちも常に対策を更新しています。MadPot が常に動作を変化させ進化し続け、悪意のある行為者の戦術、技術、手順 (TTP) を明らかにする活動への可視性を維持できるよう、多大なリソースを投入しています。この情報を AWS Shield や AWS WAF などの AWS ツールで迅速に活用し、自動対応を開始することで、多くの脅威を早期に軽減しています。また、適切な場合には、 Amazon GuardDuty を通じて脅威データをお客様に提供し、お客様が独自のツールや自動化プロセスで対応できるようにしています。 攻撃の試みまで 3 分、無駄にする時間はない MadPot によるシミュレートされたワークロード内で新しいセンサーを起動してから約 90 秒以内に、インターネットをスキャンするプローブによってワークロードが発見されるのを観察できます。そこから平均してわずか 3 分で、侵入や攻撃の試みが行われます。これらのワークロードが公開されておらず、脅威アクターにとって目立つような他のシステムの一部でもないことを考えると、この時間の短さは驚くべきものです。これは、スキャンが行われている激しさと、脅威アクターが次のターゲットを見つけるために採用している高度な自動化を明確に示しています。 これらの試行が進行するにつれて、MadPot システムは脅威アクターの行動に関するテレメトリ、コード、試行されたネットワーク接続、その他の重要なデータポイントを分析します。脅威アクターの活動を集約して、利用可能なインテリジェンスのより完全な全体像を生成すると、この情報はさらに価値が高まります。 攻撃を阻止して業務の継続性を確保する MadPot では、詳細な脅威インテリジェンス分析も実施されます。システムは捕捉したマルウェアをサンドボックス環境で起動し、異なる手法から得られた情報を脅威パターンに結びつけます。収集されたシグナルから十分な確信が得られる場合、システムは可能な限り脅威を阻止するための行動を取ります。例えば、脅威アクターのリソースを AWS ネットワークから切断するなどの対応を取ります。あるいは、特定された脅威の阻止に協力してもらうため、コンピュータ緊急対応チーム (CERT)、インターネットサービスプロバイダー (ISP)、ドメインレジストラ、政府機関などのより広いコミュニティと共有する情報を準備することもあります。 インターネット業界の主要企業として、AWS は可能な限りセキュリティコミュニティを支援し、協力する責任を負っています。セキュリティコミュニティ内での情報共有は長年続く慣例であり、私たちは何年にもわたってこの取り組みに積極的に関与してきました。 2023 年第 1 四半期： ボットネット対策のセキュリティ活動において、インターネット脅威センサーから 55 億シグナル、アクティブネットワークプローブから 15 億シグナルを収集・使用しました。 130 万件以上のボットネットから発信された DDoS 攻撃を阻止しました。 約 1000 台のボットネット C2 ホストを含むセキュリティインテリジェンスの調査結果を、関連するホスティングプロバイダーやドメインレジストラと共有しました。 23 万件の L7/HTTP(S) DDoS 攻撃の発信源を追跡し、外部の関係者と協力してその解体に取り組みました。 MadPot の有効性を示す 3 つの例：ボットネット、Sandworm、Volt Typhoon 最近、MadPot は不審なシグナルを検出、収集、分析しました。その結果、 free.bigbots.[tld] (トップレベルドメインは省略) というドメインをコマンド＆コントロール (C2) ドメインとして使用する分散型サービス拒否 (DDoS) ボットネットを発見しました。ボットネットは、無関係な第三者に属する侵害されたシステム (コンピューター、ホームルーター、IoT デバイスなど) で構成されており、これらのシステムは既に侵害されており、ターゲットに大量のネットワークパケットを送信するコマンドを待機するマルウェアがインストールされています。この C2 ドメイン下のボットは、1 時間あたり 15 ～ 20 件の DDoS 攻撃を、約 8 億パケット/秒の速度で実行していました。 MadPot がこの脅威を追跡する中で、私たちのインテリジェンスにより、ボットからの非常に多数のリクエストに対応する C2 サーバーが使用する IP アドレスのリストが明らかになりました。私たちのシステムは、AWS ネットワークへのアクセスからそれらの IP アドレスをブロックし、AWS 上の侵害されたお客様のコンピューティングノードが攻撃に参加できないようにしました。その後、AWS の自動化は収集した情報を使用して、C2 システムをホストしていた企業と DNS 名を管理していたレジストラに連絡しました。C2 をホストしていたインフラを所有する企業は 48 時間以内にそれらをオフラインにし、ドメインレジストラは 72 時間以内に DNS 名を廃止しました。DNS レコードを制御する能力を失った脅威アクターは、C2 をネットワーク上の別の場所に移動させてネットワークを容易に復活させることができなくなりました。3 日も経たないうちに、この広く分散したマルウェアとその運用に必要な C2 インフラは機能停止に追い込まれました。その結果、インターネット全体のシステムに影響を与えていた DDoS 攻撃は停止しました。 MadPot は、クラウドインフラだけでなく、さまざまな種類のインフラを標的とする脅威アクターを検出し理解するのに効果的です。これには、マルウェア、ポート、使用される可能性のある手法も含まれます。そのため、MadPot を通じて、Sandworm と呼ばれる脅威グループを特定しました。これは、Cyclops Blink という、侵害されたルーターのボットネットを管理するために使用されるマルウェアに関連するクラスターです。Sandworm は、WatchGuard ネットワークセキュリティアプライアンスに影響を与える脆弱性を悪用しようとしていました。攻撃コード（ペイロード）を詳細に調査することで、IP アドレスだけでなく、AWS のお客様への侵害の試みに関与していた Sandworm の脅威に関連するその他のユニークな属性も特定しました。MadPot のさまざまなサービスを模倣し、詳細な相互作用を行う独自の能力により、脅威アクターが標的としているサービスや、このアクターによって開始された侵害後のコマンドなど、Sandworm キャンペーンに関する追加の詳細を捕捉することができました。この情報をお客様に通知し、お客様は迅速に脆弱性を緩和するための行動を取りました。この迅速な対応がなければ、このアクターはお客様のネットワークに足がかりを得て、お客様がサービスを提供している他の組織にアクセスできた可能性があります。 最後の例として、MadPot システムを使用して、政府のサイバーおよび法執行機関が Volt Typhoon を特定し、最終的に阻止することができました。Volt Typhoon は、重要インフラ組織に対するステルス的で標的型のサイバースパイ活動に重点を置いた、広く報道されている国家が支援する脅威アクターです。MadPot 内での調査を通じて、脅威アクターが提出したペイロードに固有のシグネチャが含まれていることを特定しました。これにより、一見無関係に見えていた Volt Typhoon の活動を識別し、特定することができました。MadPot でのやり取りの完全な履歴を保存するデータレイクを使用することで、何年分ものデータを非常に迅速に検索し、最終的にこの固有のシグネチャの他の例を特定することができました。このシグネチャは 2021 年 8 月にさかのぼってペイロードとして MadPot に送信されていました。以前のリクエストは一見無害な性質を持っていたため、偵察ツールに関連していると考えました。その後、脅威アクターが最近の数ヶ月間に使用していた他の IP アドレスを特定することができました。私たちは調査結果を政府当局と共有し、これらの通常は関連付けが困難な通信情報が、米国政府のサイバーセキュリティ・インフラセキュリティ庁 (CISA) の調査に役立ちました。私たちの作業と他の協力機関の作業により、2023 年 5 月の サイバーセキュリティアドバイザリー が発行されました。現在も、このアクターが米国のネットワークインフラストラクチャを探査し続けているのを観察しており、適切な政府のサイバーおよび法執行機関と詳細を共有し続けています。 AWS のお客様とより広範なユーザーを対象とした、グローバル規模の脅威インテリジェンスの活用 AWS では、セキュリティが最優先事項であり、セキュリティ問題がお客様のビジネスに混乱をもたらすことを防ぐために懸命に取り組んでいます。インフラストラクチャとお客様のデータを守るために、グローバル規模の洞察を活用し、大量のセキュリティインテリジェンスをリアルタイムで大規模に収集し、自動的にお客様を保護するのに役立てています。可能な限り、AWS Security とそのシステムは、最も効果的な場所で脅威を阻止します。多くの場合、この作業は主に舞台裏で行われています。先に説明したボットネットの事例で示したように、グローバル規模の脅威インテリジェンスを活用し、悪意のある活動の直接的な影響を受ける組織や関係者と協力して、脅威を無効化しています。我々は MadPot からの脅威検出結果を AWS セキュリティツールに組み込んでいます。これには、 AWS WAF 、 AWS Shield 、 AWS Network Firewall 、 Amazon Route 53 Resolver DNS Firewall などの予防サービスや、 Amazon GuardDuty 、 AWS Security Hub 、 Amazon Inspector などの検出・対応サービスが含まれます。適切な場合には、セキュリティインテリジェンスを直接お客様の手に届けることで、お客様が独自の対応手順や自動化を構築できるようにしています。 しかし、私たちの取り組みは、AWS 自体の境界をはるかに超えて、セキュリティ保護と改善を拡大しています。世界中のセキュリティコミュニティや協力企業と密接に連携し、脅威アクターの特定と排除に取り組んでいます。今年の上半期には、ボットネットの制御インフラを停止するため、関連するホスティングプロバイダーやドメインレジストラと、約 2,000 のボットネットの指令サーバーに関する情報を共有しました。また、約 230,000 件のレイヤー 7 DDoS 攻撃の発信源を追跡し、外部の関係者と協力して解体しました。私たちの防御戦略の有効性は、脅威インテリジェンスを迅速に捕捉、分析、行動に移す能力に大きく依存しています。これらの措置を講じることで、AWS は一般的な DDoS 防御を超え、保護の範囲を AWS の境界を越えて拡大しています。 MadPot とその現在の機能について情報を共有できることを嬉しく思います。詳細については、AWS re:Inforce 2023 でのプレゼンテーション「 How AWS threat intelligence becomes managed firewall rules 」や、2023 年 9月 28 日に公開され概要を説明した「 サイバー犯罪からお客様を守るために Amazon が使用する脅威インテリジェンスツール MadPot のご紹介 」をご覧ください。この記事には、MadPot の元々の開発者である AWS セキュリティエンジニアに関する有益な情報も含まれています。今後、脅威インテリジェンスと対応システムの開発・強化を進めるにつれて、私たちからさらに多くの情報を発信していく予定です。これにより、AWS とインターネット全体をより安全な場所にすることを目指しています。 この投稿に関するフィードバックがある場合は、以下の コメント セクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Mark Ryland Mark はバージニア州を拠点とする Amazon のセキュリティ部門のディレクターです。テクノロジー業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーシップを発揮してきました。AWS で 12 年以上のキャリアを持ち、最初は AWS ワールドワイドパブリックセクターチームのソリューションアーキテクチャおよびプロフェッショナルサービスのディレクターとして始め、最近では AWS CISO オフィスを設立してリードしています。 本ブログは Security Solutions Architect の中島 章博が翻訳しました。

本ブログは 2023 年 9 月 28 日に公開された Amazon News ” Meet MadPot, a threat intelligence tool Amazon uses to protect customers from cybercrime ” を翻訳したものです。 サイバー犯罪を阻止することは容易ではありませんが、Amazon は地道に自社の責務を果たし、優れた成果を上げています。 その秘密とは？ MadPot と呼ばれるあまり知られていないプロジェクトです。2010 年代後半に開始されたこの取り組みは、AWS の主要なクラウドサービスプロバイダーとしての規模を活用し、攻撃を企てる者を偽装されたデジタルターゲットに誘導して、彼らの手法を研究し、対策を講じるために役立てられています。 導入以来、この技術は Amazon の絶えず進化するサイバーセキュリティ戦略の重要な要素となり、企業、政府、そしてインターネットに多大な恩恵をもたらし続けています。 例えば 2022 年 5 月、 Volt Typhoon と呼ばれる国家が支援するハッカー集団が米国の重要インフラ全体にスパイウェアを仕掛けたとされた際、MadPot により、Amazon がこの脅威についてより詳しく分析し、どのような影響があるかの詳細情報を提供しました。これにより Amazon は、攻撃の影響を受けた顧客に警告を発し、犯罪者を調査する連邦機関に貴重な情報を提供することができました。 同様の活用例では、ロシアに関連するハッキンググループ Sandworm は、あるセキュリティアプライアンスへの脆弱性を悪用しようとしましたが、実際にはそれは MadPot でした。MadPot から得られた情報を活用して、Amazon はこのグループの IP アドレスやその他の特徴的なシグネチャに関する情報を捕捉し、ある顧客がハッキンググループの標的になっていることを発見しました。そして、被害を回避するのに間に合うよう、その顧客にこの脅威を警告することができました。 MadPot の仕組み MadPot は、ネットワークセンサーから収集した脅威インテリジェンスと、Amazon Web Services (AWS) のネットワーク制御および他のインターネット関連事業者との協力による脅威の阻止を活用して、これらすべてを行っています。 脅威インテリジェンス機能は、何万もの脅威センサーによって支えられており、これらのセンサーは一般に「 ハニーポット 」として知られる同社のデジタルおとりに対する 1 日 1 億回以上の接続試行を監視しています。これらの相互作用を通じて収集されたすべてのデータにより、Amazon は脅威状況に関する幅広い理解を深め、そのクラウドインフラストラクチャの強化に活用しています。 脅威阻止システムは、データ分析手法とインテリジェンス抽出技術（ネットワークプローブなど）を組み合わせて活用し、MadPot のデータを洞察に変換します。これらの洞察は、自動化システムや IT セキュリティ担当者 (人間の判断が必要な場合) が脅威を無効化するために使用できます。結果によっては、 Amazon GuardDuty 、 AWS Shield 、 AWS WAF などのセキュリティサービスの更新もします。また、 Amazon Inspector の Vulnerability intelligence (脆弱性インテリジェンス) にも情報を提供します。さらに、MadPot は悪意のある活動に関与していることが判明したユーザをブロックまたは取り除くように、インターネットサービスプロバイダーやホスティング事業者に自動的にリクエストを送信することも頻繁に行っています。 「このシステムを運用することで、実質的にインターネット全体をより安全にしています」と Amazon Security のディレクター、Mark Ryland は述べています。「MadPot の検出能力と防御能力により、お客様に潜在的な脅威を警告し、多くの場合サイバー犯罪者の動きを阻止するという強力な二段構えの対策が可能になります。」 インターネット全体を保護する MadPot は、 AWS のプリンシパルセキュリティエンジニアである Nima Sharifi Mehr の発案から生まれました。世界中でデータ侵害が急増する中、彼はサイバー脅威に対抗するための情報収集に新しいアプローチを探し始め、デジタルおとりのアイデアをテストし始めました。わずか数ヶ月で、Amazon のセキュリティ研究者たちは、顧客に影響を及ぼす可能性のあった何千ものサイバー脅威を発見し、研究し、阻止することに成功しました。 現在、MadPot は Amazon のサイバーセキュリティ戦略の柱となっており、社内の各チームがこれを活用して世界中のお客様やパートナーを保護すると同時に、グローバルなサイバーセキュリティの基準を引き上げています。 「PadPotは、Amazon 全体で脅威インテリジェンスとマルウェアの検体を収集するための主要な情報源となりました」と Sharifi Mehr は述べました。「Amazonの巨大なグローバルインフラストラクチャ全体にデプロイすることで、私たちのシステム、およびセキュリティ確保のために当社を信頼している何億人ものお客様を保護について、可能性の限界を押し広げることができます。」 詳細は、 AWS 脅威インテリジェンスによる脅威アクターの阻止 をご参照ください。 本ブログは Security Solutions Architect の 中島 章博が翻訳しました

2024 年 8 月 29 日にクリエイティブなコンテンツ制作に関わるお客様向けに、クラウドを活用してクリエイティビティと作業効率を最適化する最新のサービスと情報をご紹介するセミナーを行いました。 AWSが推進するフルクラウドの制作環境の最新情報に加え、2024年4月にローンチした最新のレンダーマネージメントツールであるAWS Deadline Cloudの実際の使用方法も含めたご紹介と実際の作業環境の構築をご紹介。 合わせて、Deadline Cloudのユーザー事例として株式会社毎日放送様をお招きして、使い勝手や構築におけるチャレンジなどをお話しいただきました。 また、ゲストスピーカーとして株式会社ワコム様をお迎えして、リモート接続環境におけるペンタブレットの描き味を改善する最新のソリューションであるWacom Bridgeをご紹介頂きました。 セミナーのアジェンダ: アマゾンウェブサービス (AWS) ジャパン : クラウド上でのコンテンツ制作環境の現状 アマゾンウェブサービス (AWS) ジャパン : Deadline Cloudのご紹介 株式会社毎日放送 様 : Deadline Cloudの本番運用に向けての検証 株式会社ワコム 様 : Wacom Bridgeのご紹介 クラウド上でのコンテンツ制作環境の現状 アマゾン ウェブ サービス ジャパン合同会社 WWSO Advanced Compute 事業本部 Visual Compute担当シニアスペシャリスト 　菊地 蓮 [ 資料 ] クラウド上でのコンテンツ制作環境におけるAWSのコミットメントと最新の事例についてご紹介します。 Deadline Cloudのご紹介 アマゾン ウェブ サービス ジャパン合同会社　WWSO Advanced Compute 事業本部 Visual Compute担当シニアソリューションズアーキテクト 　森 大樹 [ 資料 ] AWSのレンダーマネージメントサービスであるDeadline Cloudのご紹介と実際の構築の流れを解説します。 Deadline Cloudの本番運用に向けての検証 株式会社毎日放送 総合技術局 制作技術センター　村井 亨 様 [ 資料 ] 現在、毎日放送ではAWS Thinkbox Deadline 10 を運用していますがDeadline Cloud を利用することで、フルマネージドでより簡単に環境を構築できるようになりました。今年度中の本番運用を目指し、テストを開始しました。現時点での検証結果をご報告します。 Wacom Bridgeのご紹介 株式会社ワコム ブランドビジネス ポートフォリオマネジメント サービス マネージャー 　淺田 一 様 [ 資料 ] クラウドで動作するリモートマシン上でのペンタブレットの使い心地を飛躍的に向上させる新たなテクノロジーソリューションである、Wacom Bridgeをご紹介頂きます。また、ペンタブレットを現在業務に使用されているアーティストの方にWacom Bridgeを使って頂き、使用感についてインタビュー形式にて語って頂きます。 おわりに 本ブログでは、2024 年 8 月 29 日に開催されたコンテンツ制作を行われているお客様向けに開催したセミナーの内容について紹介させて頂きました。 今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 菊地が担当いたしました。

この記事は Amazon DataZone introduces OpenLineage-compatible data lineage visualization in preview を翻訳したものです。 Amazon DataZone で OpenLineage 互換の API を使用したデータリネージ機能のプレビュー版 の提供を開始したことをお知らせできることを嬉しく思います。この機能により、 Amazon DataZone 上のデータアセットのリネージ (データの流れや変遷) のキャプチャ、保存、そして可視化が可能になります。 Amazon DataZone の OpenLineage 互換 API により、ドメイン管理者やデータプロデューサー (データ提供者) は、より広範囲のリネージイベントをキャプチャして保存できるようになりました。Amazon DataZone 内の情報に加え、 Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、およびその他の AWS サービスで行った変換も含めることができます。これにより、Amazon DataZone を閲覧するデータコンシューマー (データ利用者) はデータアセットの出所を確認することができ、データプロデューサーはデータアセットの使用状況を把握することで変更の影響を評価できるようになります。 この記事では、Amazon DataZone のデータリネージの最新機能、OpenLineage との互換性、そして AWS Glue、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) など、他のサービスから API を通じて Amazon DataZone にリネージを取り込む方法について説明します。 データリネージの重要性 データリネージによって、データアセットの全体像を把握し、オブジェクトの出所とその関連性の連鎖を確認できるようになります。データリネージがあれば時間の経過に伴うデータの変遷を追跡でき、データの出所、変更履歴、そしてデータパイプライン内での最終的な行き先を明確に理解できるようになります。データの出所が透明化されることで、データコンシューマーはそのデータが自分たちの用途に適しているかどうかを的確に判断できるようになります。データリネージはテーブル、カラム、ジョブなどの情報を含むため、影響分析やデータに関する問題への対処が可能になります。例えば、ある項目が下流のソースコードにどのような影響を与えるかを確認できます。このようにして、変更をコミットする前に十分な情報に基づいて判断を下し、下流で望ましくない変更が発生するのを回避できます。 Amazon DataZone のデータリネージは、 API として提供される OpenLineage 互換の機能です。これにより、OpenLineage 対応システムや API からリネージイベントをキャプチャし、可視化できます。さらに、データの出所や変換を追跡し、組織間におけるデータの利用状況を的確に把握できるようになります。Amazon DataZone のビジネスデータカタログ内のアクティビティは、リネージとして可視化されます。また、カタログ化されたアセットだけでなく、ビジネスデータカタログの外で発生したアクティビティも、API を使用してプログラム的にキャプチャします。これにより、データの流れと利用状況を包括的に理解できるようになります。 さらに、Amazon DataZone はイベントごとにリネージのバージョン管理を行い、いつでも必要なときにリネージを可視化したり、アセットやジョブの履歴全体で変遷を比較することができます。過去のリネージを確認することで、データがどのように進化してきたかを深く理解できるため、トラブルシューティング、監査、およびデータアセットの整合性の確保に欠かせない機能だといえます。 次のスクリーンショットは、Amazon DataZone のデータカタログで可視化されたリネージグラフの例を示しています。 OpenLineage 互換のデータリネージ機能の概要 さまざまなアナリティクスサービスにわたってデータリネージを一貫してキャプチャし、それらを統一されたオブジェクトモデルに組み込むことが、リネージ情報から洞察を得るための重要な要素となります。 OpenLineage は、リネージを収集および分析するためのフレームワークを提供するオープンソースプロジェクトです。また、メタデータを記録するためのオブジェクトモデルのリファレンス実装と、主要なデータアナリティクスツールとの統合機能も提供しています。 OpenLineage における主要な概念を以下に挙げます。 リネージイベント (Lineage event) – OpenLineage は一連のイベントを通してデータのリネージ情報をキャプチャします。 イベント とは、データパイプラインにおいてデータの取り込み、変換、利用などの特定の操作を表すものです。 リネージエンティティ (Lineage entity) – OpenLineage における エンティティ は、データセットやテーブルなど、リネージプロセスに関わるさまざまなデータオブジェクトを表します。 リネージ実行 (Lineage run)  – リネージ実行 は、データパイプラインやジョブの実行を表す概念であり、複数のリネージイベントとエンティティから構成されます。 リネージ形式 (Lineage form type) – 形式または ファセット (データの分類や検索に用いる属性情報) は、リネージエンティティやイベントに関する追加のメタデータやコンテキスト情報を提供し、より豊かで記述的なリネージ情報を実現します。OpenLineage はラン、ジョブ、データセットのファセットを提供しており、カスタムファセットを構築することも可能です。 Amazon DataZone のデータリネージ API は OpenLineage 互換であり、OpenLineage の機能を拡張しています。具体的には、リネージ情報を柔軟に拡張可能なデータ構造 (オブジェクトモデル) に保存するためのエンドポイントを提供しています。 OpenLineage は特定のデータソースとの統合機能 も提供しています。Amazon DataZone はこれらのデータソースとの統合を簡単に行うことができます。Amazon DataZone のデータリネージ API がこれらのフォーマットを解釈し、リネージのデータモデルに変換するためです。 次の図は、Amazon DataZone のリネージデータモデルの例を示しています。 Amazon DataZone では、すべてのリネージノードが実際のリソースを表しています。つまり、リネージノードとテーブル、ビュー、アセットなどの論理的または物理的リソースとの間に 1 対 1 のマッピングがあるということです。ノードは特定のジョブの特定の実行を表すか、テーブルやアセットのノードやサブスクライブしたアセットのノードを表します。 ノードの各バージョンは、タイムスタンプで実際のリソースに何が起きたのかを管理しています。Amazon DataZone のリネージは、外部で発生したデータ移動の変遷を共有するだけでなく、Amazon DataZone 内でのアセット作成、キュレーション (メタデータの整備) 、公開、サブスクリプションなどのアクティビティによるリネージも表します。 Amazon DataZone でデータリネージのモデルを構築するには、2 種類のデータリネージを取得する必要があります。 Amazon DataZone 内のリネージアクティビティ – これには、カタログに追加され公開されたアセットが含まれ、その後サブスクリプションの詳細が自動的に取得されます。プロデューサープロジェクトの視点 (例えば、選択したプロジェクトがブラウジング中のアセットの所有プロジェクトであり、そのプロジェクトのメンバーである場合) では、データセットノードの 2 つの状態が表示されます。 インベントリアセットタイプのノードは、未公開の段階にあるカタログ内のアセットを定義します。他のプロジェクトのメンバーはインベントリアセットをサブスクライブできません。詳細については、 Amazon DataZone でのインベントリデータの作成とデータの公開 を参照してください。 公開済みアセットタイプのノードは、組織全体のデータユーザーが利用可能な実際のアセットを表します。これは、他のプロジェクトのメンバーがサブスクライブできるアセットタイプです。そのアセットのプロデューサープロジェクト以外のコンシューマーの視点では、公開済みアセットノードのみが表示されます。 Amazon DataZone の外部で発生したリネージアクティビティは、 PostLineageEvent を使用することでそのプログラムから取得できます。カタログ化されたアセットのデータ処理の前後でこれらのイベントを取得することで、データプロデューサーとデータコンシューマーはデータの移動を包括的に把握し、データの出所またはその消費を確認できます。この記事の後半で、リネージイベントを連携するための API の使用方法について説明します。 Amazon DataZone には 2 種類のリネージノードが用意されています: データセットノード (Dataset node) – Amazon DataZone では、リネージの可視化機能ではテーブルやビューを表すノードを表示します。プロジェクトの視点によって表示される内容は異なり、プロデューサーはインベントリと公開済みアセットの両方を表示できますが、コンシューマーは公開済みアセットしか表示できません。アセット詳細ページのリネージタブを最初に開くと、カタログ化されたデータセットノードがリネージグラフの上流または下流の探索の開始点になります。データセットノードには、Amazon DataZone から自動で生成されるリネージノードと、独自に作成するリネージノードがあります。 自動生成データセットノード (Automated dataset node) – これらのノードには、Amazon DataZone カタログに公開された AWS Glue または Amazon Redshift アセットに関する情報が含まれています。自動的に生成され、ノード内に対応する AWS Glue または Amazon Redshift のアイコンが含まれています。 カスタムデータセットノード (Custom dataset node)  – これらのノードには、Amazon DataZone カタログに公開されていないアセットに関する情報が含まれています。ドメイン管理者 (プロデューサー) が手動で作成し、ノード内にはカスタムアセットアイコンが表示されます。これらは、OpenLineage イベント形式を使用して作成されたカスタムリネージノードです。 ジョブノード / ジョブ実行ノード (Job node / Job run node)  – このノードは、特定のジョブの最新の実行とその実行の詳細を表すジョブの詳細をキャプチャします。このノードは、そのジョブの複数の実行もキャプチャでき、ノード詳細の History  タブで表示できます。ノードの詳細はアイコンを選択すると表示されます。 Amazon DataZone でのデータリネージの可視化 Amazon DataZone は、データプロデューサーとデータコンシューマー向けに統合的な操作環境を提供します。アセット詳細ページではリネージの情報がグラフで表示されており、上流または下流のデータ間の関係を容易に把握できます。アセット詳細ページにはグラフをナビゲートするための次の機能があります。 カラムレベルのリネージ – データセットノードで利用可能な場合、カラムレベルのリネージを展開できます。これにより、データソースのカラム情報が利用可能であれば、上流または下流のデータセットノードとの関係が表示されます。 カラム検索 – データセットに 10 個以上のカラムがある場合、ノードには最初に表示されないカラムに移動するためのページ送りが表示されます。データセットノードには検索機能があり、この機能を使うと検索結果には該当するカラムだけが表示され、探したいカラムをすぐに見つけることができます。 データセットノードのみを表示 – ジョブノードを除外したい場合は、グラフビューアーの Open view control のアイコンを選択し、 Display dataset nodes only の設定を切り替えます。これにより、グラフからすべてのジョブノードが表示されなくなり、データセットノードのみを移動できるようになります。 詳細ペイン – 各リネージノードは次の詳細をキャプチャして表示します。 すべてのデータセットノードには、 Lineage info、Schema、 History の 3 つのタブがあります。 History タブには、そのノードでキャプチャされたリネージイベントのバージョンが一覧表示されます。 ジョブノードには、 Job info と History のタブを持つ詳細ペインがあり、ジョブの詳細が表示されます。詳細ペインにはジョブの一部として実行されたクエリや式もキャプチャされます。 バージョンタブ – Amazon DataZone データリネージのすべてのノードには、キャプチャされたリネージイベントに基づく履歴としてバージョン管理が行われます。選択したタイムスタンプでリネージを表示すると、リネージページに新しいタブが開き、異なるタイムスタンプ間で比較できます。 次のスクリーンショットはデータリネージの可視化の例を示しています。 Lineage タブで Preview を選択し、 Try sample lineage リンクを選択すると、サンプルデータでどのように可視化されるかを体験できます。新しいブラウザタブが開き、ガイドツアーを利用するかどうかに関わらず、サンプルデータを使ってこの機能をテストして使い方を学ぶことができます。次のスクリーンショットはサンプルデータのリネージを表示した例です。 ソリューションの概要 ここまでは Amazon DataZone の新しいデータリネージ機能を説明しました。次は AWS Glue のテーブルと ETL (抽出、変換、ロード) ジョブ、Amazon Redshift、そして Amazon MWAA からリネージ情報をキャプチャする方法を見ていきましょう。 スタートアップスクリプトは Amazon DataZone の新しい GitHub リポジトリ でも入手できます。 前提条件 このウォークスルーを行うには、以下の前提条件を満たしている必要があります: 1 つの AWS アカウント AWS Identity and Access Management (IAM) ユーザーで、以下のサービスへのアクセス権限があること: AWS Cloud9 AWS CloudFormation AWS CloudShell Amazon DataZone AWS Glue Amazon S3 1 つの Amazon DataZone ドメイン データレイクの環境が作成された 1 つの Amazon DataZone プロジェクト この記事の手順を実行する AWS アカウントで AWS Lake Formation を使用して AWS Glue Data Catalog の権限を管理している場合は、データベースとテーブルを作成する権限を持つユーザーとしてログインしてください。詳細については、 Lake Formation の暗黙的なアクセス許可 を参照してください。 CloudFormation スタックの起動 このユースケースのリソースを AWS CloudFormation で作成するには、以下の手順を実行してください: CloudFormation スタックを us-east-1 でデプロイします: Stack name には、スタックの名前を入力します。 Next を選択します。 I acknowledge that AWS CloudFormation might create IAM resources with custom を選択します 。 Create stack を選択します。 スタックの作成とリソースのプロビジョニングが完了するのを待ちます。 CREATE_COMPLETE ステータスが表示されれば次のステップに進めます。 AWS Glue テーブルからのデータリネージのキャプチャ この例では、AWS Glue テーブルからリネージメタデータを収集するために必要なコマンドを実行するため、ブラウザベースのシェルである CloudShell を使用します。以下の手順を実行してください。 AWS Glue コンソールで、ナビゲーションペインから Crawlers を選択します。 CloudFormation テンプレートによって作成されたクローラー AWSomeRetailCrawler を選択します。 Run を選択します。 クローラーの実行が完了すると、 Succeeded ステータスが表示されます。 では、CloudShell を使用してリネージのメタデータを収集しましょう。 extract_glue_crawler_lineage.py ファイルをダウンロードします。 Amazon DataZone コンソールで CloudShell を開きます。 Actions メニューから、 Update file を選択します。 extract_glue_crawler_lineage.py ファイルをアップロードします。 次のコマンドを実行します: sudo yum -y install python3 python3 -m venv env . env/bin/activate pip install boto3 次のような結果が得られるはずです。 すべてのライブラリと依存関係が構成されたら、次のコマンドを実行して inventory テーブルからリネージのメタデータを収集します。なお、 dzd_Your_domain は自身の DataZone ドメイン ID に置き換えます: python extract_glue_crawler_lineage.py -d awsome_retail_db -t inventory -r us-east-1 -i dzd_Your_domain スクリプトは設定情報の確認を求めてきます。 yes と入力します。 スクリプトが正常に実行されたことを示す通知が表示されるはずです。 Inventory テーブルからリネージ情報をキャプチャした後、データソースジョブを実行するには、以下の手順を行います。 Amazon DataZone データポータルで、 Sales を開きます。 ナビゲーションペインで Data  タブを選択し、 Data sources を選択します。 データソースジョブを選択し、 Run を選択します。 この例では、 awsome_retail_db データベースを指すデータソースジョブ SalesDLDataSourceV2 がすでに作成されていました。データソースジョブの作成方法の詳細については、 AWS Glue Data Catalog の Amazon DataZone データソースを作成して実行する を参照してください。 ジョブが正常に実行されると、確認メッセージが表示されます。 Amazon DataZone によって生成されたリネージグラフを見てみましょう。 Data inventory タブで Inventory テーブルを選択します。 Inventory アセットページで新しく追加されている Lineage タブを選択します。 Lineage タブでは、Amazon DataZone が 3 つのノードを作成したことがわかります。 Job / Job run – アセットのテクニカルメタデータを収集するために使用される AWS Glue クローラーを表しています Dataset – このアセットに関連するデータを含む S3 オブジェクトを表しています Table – クローラーによって作成された AWS Glue テーブルを表しています Dataset ノードを選択すると、Amazon DataZone はアセットを作成するために使用された S3 オブジェクトに関する情報を提供します。 AWS Glue ETL ジョブからのデータリネージのキャプチャ 前のセクションでは、データアセットのデータリネージグラフを生成する方法について説明しました。次に、AWS Glue ジョブのデータリネージグラフを作成する方法を見ていきましょう。 先ほど起動した CloudFormation テンプレートは、 Inventory_Insights という名前の AWS Glue ジョブを作成しました。このジョブは Inventory テーブルからデータを取得し、すべての店舗で利用可能な製品の合計データを集計した新しい Inventory_Insights テーブルを作成します。 CloudFormation テンプレートは、この記事用に作成された S3 バケットに openlineage-spark_2.12-1.9.1.jar ファイルもコピーしています。このファイルは、AWS Glue ジョブからリネージメタデータを生成するために必要です。この OpenLineage Spark プラグインは、 AWS Glue 3.0 (この記事の AWS Glue ジョブ作成に使用したバージョン) と互換性のある 1.9.1 バージョンを使用しています。異なるバージョンの AWS Glue を使用している場合は、 OpenLineage Spark プラグインファイル の対応するバージョンをダウンロードする必要があります。 OpenLineage Spark プラグインは、AWS Glue DynamicFrames を使用する AWS Glue Spark ジョブからデータリネージを抽出することができません。代わりに Spark SQL DataFrames を使用してください。 extract_glue_spark_lineage.py ファイルをダウンロードします。 Amazon DataZone コンソールで CloudShell を開きます。 Actions メニューから Update file を選択します。 extract_glue_spark_lineage.py ファイルをアップロードします。 CloudShell コンソールで、次のコマンドを実行します (CloudShell セッションの有効期限が切れている場合は新しいセッションを開きます)。 python extract_glue_spark_lineage.py --region "us-east-1" --domain-identifier 'dzd_Your Domain' スクリプトによって表示される情報を確認し、 yes と入力して確定します。 次のメッセージが表示されます。これは、スクリプトを実行した後で AWS Glue ジョブのリネージメタデータをキャプチャする準備ができたことを意味します。 Cloud formation テンプレートで作成した AWS Glue ジョブを実行します。 AWS Glue コンソールで、ナビゲーションペインから ETL jobs  を選択します。 Inventory_Insights ジョブを選択し、 Run job  を選択します。 Job details タブを見ると、このジョブには次の構成があることがわかります: キー --conf には以下の値が設定されています spark.extraListeners=io.openlineage.spark.agent.OpenLineageSparkListener --conf spark.openlineage.transport.type=console --conf spark.openlineage.facets.custom_environment_variables=[AWS_DEFAULT_REGION ; GLUE_VERSION ; GLUE_COMMAND_CRITERIA ; GLUE_PYTHON_VERSION ; ] キー --user-jars-first  の値には true  が設定されています Dependent JARs path は S3 のパスである  s3://{your bucket}/lib/openlineage-spark_2.12-1.9.1.jar  が設定されています AWS Glue のバージョンは 3.0 に設定されています ジョブの実行中、CloudShell コンソールに次の出力が表示されます。 これは、スクリプトが AWS Glue ジョブからリネージメタデータを正常に収集できたことを意味します。 AWS Glue ジョブによって作成されたデータをもとに AWS Glue テーブルを作成します。この例では、AWS Glue クローラーを使用します。 AWS Glue コンソールで、ナビゲーションペインから Crawlers を選択します。 CloudFormation テンプレートによって作成されたクローラー  AWSomeRetailCrawler を選択し、 Run を選択します。 クローラーの実行が完了すると、次のメッセージが表示されます。 クローラーの実行が完了したら、次のコマンドを実行して inventory_insight テーブルからリネージのメタデータを収集します。 dzd_Your_domain は自分の DataZone ドメイン ID に置き換えてください: python extract_glue_crawler_lineage.py -d awsome_retail_db -t inventory_insight -r us-east-1 -i dzd_Your_domain Amazon DataZone ポータルを開き、Amazon DataZone でどのような図が表示されるか確認します。 Amazon DataZone ポータルで、 Sales プロジェクトを選択します。 Data タブで、ナビゲーションペインから Inventory data を選択します。 データソースジョブを再実行し、 inventory insights アセットを選択します。 Lineage タブでは、Amazon DataZone によって作成された図を確認できます。この図には 3 つのノードが表示されています。 AWS Glue テーブルを作成するために使用された AWS Glue クローラー クローラーによって作成された AWS Glue テーブル Amazon DataZone にカタログ化されたアセット 作成した inventory_insights テーブルを生成するために実行した AWS Glue ジョブのリネージ情報を確認するには、図の左側にある矢印アイコンを選択します。 そうすると、 Inventory_insights テーブルの完全なリネージグラフを確認できます。 図の左側のインベントリノードにある青い矢印アイコンを選択します。 カラムの変遷と、それらに加えられた変換を確認できます。 図中のノードを選択すると、その詳細を確認できます。例えば、 inventory_insights ノードには次の情報が表示されます。 Amazon Redshift からのデータリネージのキャプチャ Amazon Redshift からリネージグラフを生成する方法を見ていきましょう。この例では、Redshift クラスターが存在する仮想プライベートクラウド (VPC) への接続を構成できるため、AWS Cloud9 を使用します。AWS Cloud9 の詳細については、 AWS Cloud9 ユーザーガイド を参照してください。 この記事に含まれる CloudFormation テンプレートには、Redshift クラスターの作成やこのセクションで使用するテーブルの作成は含まれていません。Redshift クラスターの作成方法の詳細については、 ステップ 1: サンプルの Amazon Redshift クラスターを作成する を参照してください。このセクションで必要なテーブルを作成するには、次のクエリを使用します。 Create SCHEMA market create table market.retail_sales ( id BIGINT primary key, name character varying not null ); create table market.online_sales ( id BIGINT primary key, name character varying not null ); /* Important to insert some data in the table */ INSERT INTO market.retail_sales VALUES (123, 'item1') INSERT INTO market.online_sales VALUES (234, 'item2') create table market.sales AS Select id, name from market.retail_sales Union ALL Select id, name from market.online_sales ; Redshift クラスターへのアクセスを許可するセキュリティグループに AWS Cloud9 環境の IP アドレスを追加するのを忘れないようにしてください。 requirements.txt と extract_redshift_lineage.py ファイルをダウンロードします。 File  メニューから Upload Local Files  を選択します。 requirements.txt と extract_redshift_lineage.py ファイルをアップロードします。 次のコマンドを実行します: # Python をインストール sudo yum -y install python3 # 依存関係のセットアップ python3 -m venv env . env/bin/activate pip install -r requirements.txt 次のメッセージが表示されるはずです。 AWS 認証情報を設定するには、次のコマンドを実行します: export AWS_ACCESS_KEY_ID= <<Your Access Key>> export AWS_SECRET_ACCESS_KEY= <<Your Secret Access Key>> export AWS_SESSION_TOKEN= <<Your Session Token>> extract_redshift_lineage.py スクリプトを実行し、リネージグラフを生成するために必要なメタデータを収集します: python extract_redshift_lineage.py \ -r region \ -i dzd_your_dz_domain_id \ -n your-redshift-cluster-endpoint \ -t your-rs-port \ -d your-database \ -s the-starting-date 次に、Amazon DataZone データベースに接続するためのユーザー名とパスワードを入力します。 確認メッセージが表示されたら yes と入力します。 設定が正しく行われた場合、次の確認メッセージが表示されます。 では、Amazon DataZone でこの図がどのように作成されたかを見ていきましょう。 Amazon DataZone データポータルで、 Sales プロジェクトを開きます。 Data タブで、 Data sources を選択します。 データソースジョブを実行します。 この記事では、Amazon DataZone プロジェクトに Redshift データソースを追加するために、 Sales_DW_Enviroment-default-datasource という名前のデータソースジョブを作成済みです。データソースジョブの作成方法については、 Amazon Redshift の Amazon DataZone データソースを作成して実行する を参照してください。 ジョブを実行すると、次の確認メッセージが表示されます。 Data タブで、ナビゲーションペインから Inventory data を選択します。 total_sales アセットを選択します。 Lineage タブを選択します。 Amazon DataZone は Total Sales テーブルの 3 つのノードで構成されるリネージグラフを作成します。任意のノードを選択して詳細を確認できます。 Job/ Job run ノードの横にある矢印アイコンを選択すると、より詳細なリネージグラフを表示できます。 Job / Job run を選択します Job Info セクションには、合計売上テーブルを作成するために使用されたクエリが表示されます。 Amazon MWAA からのデータリネージのキャプチャ Apache Airflow はバッチ処理型のワークフローを開発、スケジューリング、そして監視するためのオープンソースプラットフォームです。Amazon MWAA は、最新の Airflow プラットフォームを使ってワークフローを管理できる Airflow の管理サービスです。OpenLineage は openlineage-airflow パッケージを使って Airflow 2.6.3 との統合をサポートしており、同様の機能を Amazon MWAA でプラグインとして有効にできます。有効にすると、このプラグインは Airflow のメタデータを OpenLineage イベントに変換し、 DataZone.PostLineageEvent で取り込めるようになります。 次の図は、OpenLineage を使用してデータリネージをキャプチャし Amazon DataZone に登録するにあたって、Amazon MWAA で必要な構成を示しています。 このワークフローでは、Amazon MWAA DAG を使用してデータパイプラインを呼び出します。プロセスは次のとおりです。 openlineage-airflow プラグインは、Amazon MWAA で リネージを行うためのバックエンド機能  として設定されています。DAG 実行に関するメタデータがプラグインに渡され、OpenLineage 形式に変換されます。 収集されたリネージ情報は、Amazon MWAA の環境に応じた  Amazon CloudWatch のロググループに書き込まれます。 ヘルパー関数がログファイルからリネージ情報をキャプチャし、 PostLineageEvent API を使用して Amazon DataZone に登録します。 この記事で使用している例では、Amazon MWAA のバージョン 2.6.3 、そして OpenLineage プラグインのバージョン 1.4.1 を使用しています。OpenLineage がサポートする他の Airflow バージョンについては、 サポートされている Airflow バージョン を参照してください。 OpenLineage プラグインの Amazon MWAA への設定とリネージのキャプチャ OpenLineage を使用してリネージを収集する際は、 Transport 構成を設定する必要があります。これは、OpenLineage がイベントを出力する場所 (コンソールや HTTP エンドポイントなど) を指定します。 ConsoleTransport を使用すると、OpenLineage イベントが Amazon MWAA タスクの CloudWatch ロググループに記録され、ヘルパー関数を使って Amazon DataZone に登録できます。 Amazon MWAA で設定された S3 バケットに追加された requirements.txt ファイルに以下の内容を設定します: openlineage-airflow==1.4.1 Airflow 環境の MWAA 設定の Airflow logging configuration セクションで、ログレベル INFO で Airflow タスクログを有効にします。次のスクリーンショットはサンプルの設定を示しています。 正しく設定すれば Airflow にプラグインが追加されます。プラグインが追加されたかどうかは Airflow UI の Admin メニューから Plugins を選択することで確認できます。 この記事では、サンプルの DAG を使用して Redshift テーブルにデータを取り込みます。次のスクリーンショットは、グラフビューの DAG を示しています。 DAG を実行し、実行が正常に完了したら、Airflow 環境 ( airflow-env_name-task ) の Amazon MWAA タスク CloudWatch ロググループを開き、 console.py という式でフィルタリングして、OpenLineage から出力されたイベントを選択します。次のスクリーンショットは、その結果を示しています。 Amazon DataZone へのデータリネージの登録 CloudWatch にリネージイベントを出力できました。次のステップは、Amazon DataZone にそれらを登録し、データアセットに関連付けてビジネスデータカタログ上で可視化することです。 ファイル requirements.txt と airflow_cw_parse_log.py をダウンロードし、AWS リージョン、Amazon MWAA 環境名、Amazon DataZone ドメイン ID などの環境詳細を収集します。 Amazon MWAA の環境名は Amazon MWAA コンソールから取得できます。 Amazon DataZone ドメイン ID は、Amazon DataZone サービスコンソールまたは Amazon DataZone ポータルから取得できます。 CloudShell に移動し、 Actions メニューから Upload files を選択し、 requirements.txt と extract_airflow_lineage.py をアップロードします。 ファイルがアップロードされたら、次のスクリプトを実行して Airflow タスクログからリネージイベントをフィルタリングし、Amazon DataZone に登録します。(訳註： your_domain_identifier  は自身の DataZone ドメイン ID に、 your_airflow_environment_name は自身の Airflow 環境名に置き換えます) # 仮想環境をセットアップし、依存関係をインストールする python -m venv env pip install -r requirements.txt . env/bin/activate # スクリプトを実行する python extract_airflow_lineage.py \ --region us-east-1 \ --domain-identifier your_domain_identifier \ --airflow-environment-name your_airflow_environment_name extract_airflow_lineage.py 関数は、Amazon MWAA タスクのロググループからデータリネージイベントをフィルタリングし、Amazon DataZone 内の指定されたドメインにデータリネージを登録します。 Amazon DataZone でのデータリネージの可視化 DataZone にリネージが登録された後、DataZone プロジェクトを開き、 Data タブに移動して Amazon MWAA DAG がアクセスしたデータアセットを選択します。この記事ではサブスクライブされたアセットの例を示します。 Amazon DataZone に登録されたデータリネージを可視化するには Lineage タブに移動します。 ノードを選択して追加のリネージメタデータを確認します。次のスクリーンショットでは、リネージの生成元が airflow とマークされていることがわかります。 結論 この記事では、Amazon DataZone のデータリネージのプレビュー機能、その仕組み、AWS Glue、Amazon Redshift、Amazon MWAA からリネージイベントをキャプチャしてアセットのブラウジング体験の一部として可視化する方法について説明しました。 Amazon DataZone の詳細と開始方法については Getting started guide を参照してください。Amazon DataZone の最新のデモと利用可能な機能の簡単な説明については、 YouTube プレイリスト をご覧ください。 著者について Leonardo Gomez は AWS のプリンシパルアナリティクススペシャリストであり、10 年以上にわたるデータマネジメントの経験があります。データガバナンスを専門としており、データの可能性を最大限に活かしながらデータの民主化に取り組んでいる世界中の顧客を支援しています。 LinkedIn で彼とつながってください。 Priya Tiruthani は AWS の Amazon DataZone でシニアテクニカルプロダクトマネージャーを務めています。彼女はデータアナリティクスに必要なデータの発見とキュレーションの改善に注力しています。特にデータガバナンスとアナリティクスの分野で、顧客のエンドツーエンドのデータジャーニーを簡素化するための革新的な製品を作ることに情熱を注いでいます。仕事以外では、ハイキングやネイチャーフォトグラフィー、最近ではピックルボールというスポーツを楽しんでいます。 Ron Kyker は AWS の Amazon DataZone でプリンシパルエンジニアを務めており、チームのためにイノベーションの推進、複雑な問題の解決、エンジニアリングの優秀性の基準設定に尽力しています。仕事以外では、友人や家族とボードゲームを楽しんだり、映画鑑賞、ワインテイスティングなどを趣味としています。 Srinivasan Kuppusamy は AWS の ProServe でデータ分野のシニアクラウドアーキテクト を務めており、AWS のクラウドのテクノロジーを活用してお客様のビジネス課題を解決するのを支援しています。彼の関心分野はデータアナリティクス、データガバナンス、AI/ML です。 翻訳はパートナーソリューションアーキテクトの丸山 大輔が担当しました。原文は こちら です。

本ブログは、株式会社日立パワーソリューションズと Amazon Web Services Japan 合同会社が共同で執筆しました。 株式会社日立パワーソリューションズ は、風力や太陽光など再生可能エネルギー、火力・水力プラント、工場の電気設備、生産設備など社会インフラを中心に幅広い分野で保守サービス事業を展開しています。本ブログでは、同社が AWS の生成 AI 技術を活用して、社会インフラにおける保守業務の効率化と知識共有に取り組んだ事例をご紹介します。 課題：多岐にわたる保守業務の技術伝承 日立パワーソリューションズは、風力発電設備から工場の生産ラインまで、多岐にわたる設備の保守を行っています。また、日立グループの製品のみならず他社製品も対象とすることから、保守を行う上では幅広い機器に関する知識を習得することが重要となっています。しかし現在、シニア層が保守作業員の約 10 %を占めるなど高齢化が進んでおり、そういったベテランの退職による知識喪失の深刻化への危機意識があります。そのため、ベテラン保守作業員の知識を若手・中堅社員へ確実かつ効率的に継承し、サービス品質を維持・向上させるための仕組みを構築することが重要な課題となっていました。 ソリューション：AWS を活用した生成 AI 環境の構築 これらの課題に対し、同社は AWS のサービスを活用した、社内で活用するための生成 AI 環境「Power AI Ground（パワグラ）」を構築しました。パワグラは現場の保守員を支援することを目的としており、従来から推進しているナレッジマネジメントと組み合わせることにより、保守知識の定型化・高度活用を狙っています。フィールド作業支援、保守マニュアルや指示書からの必要な情報の検索・集約、保守作業員の教材作成というユースケースを想定し、実作業への適用に向けて保守現場とのコミュニケーションを重ねています。 図1 パワグラの想定ユースケース システムアーキテクチャは以下の通りです： 図2. システムアーキテクチャ   パワグラでは、自然言語検索サービスである Amazon Kendra を社内ナレッジベースとして活用し、生成 AI 基盤サービスである Amazon Bedrock を組み合わせることで、RAG（Retrieval-Augmented Generation）を実現しました。これにより、一般的なチャットボットと比較し、ハルシネーション(生成 AI による事実と異なる文章の生成) を抑制しつつ、自社の業務に必要なマニュアルデータや過去の作業指示書、作業報告書などを効果的に活用した高品質な回答を生成できるようになりました。また、他社の類似サービスを用いて構築した場合と比較しても、価格メリットがあり、サンプルコードで構築が容易かつ、技術支援が充実しているといった点から AWS を採用するに至りました。 経営戦略本部 湯田晋也担当本部長は「AWS の各種サービスや支援を活用することで、当初は 6 ヶ月かかると思っていた、生成 AI ソリューションの構築・効果検証を 3 ヶ月で終えることができました。また、RAG の仕組みにより、社内にある専門性の高い保守知識に関しても高い回答精度を実現することができました。」と述べています。 導入プロセスと工夫 システムの開発にあたっては、AWS や生成 AI の知識を持った人財が不足しているという課題がありました。そこで、まずは AWS の RAG 構築ワークショップへ参加することで、迅速に検証環境を構築しました。 ワークショップでは  GitHub 上にある RAG 構築のサンプルコード をもとに、実際のデータと連携してソリューションを構築する手順を学ぶことができただけでなく、様々な技術的な質問も行うことができ、その後の検証をスムーズに進めることができました。 次に、RAG の効果を測定するべく、過去の作業報告書や設備マニュアルのデータをもとに報告書作成を支援するユースケースに絞り、回答精度を検証しました。 開発当初は 40% ほどしか精度が出ませんでしたが、原因を調査したところ、特に Excel で記述された帳票データをもとにした回答精度が悪いことが判明しました。そこで、  Anthropic 社のユーザガイド を参考に、Claude モデルに合わせ、多様なフォーマットの報告帳票文書のうちテキスト部分を AWS Lambda で XML 形式に変換した上で、Kendra に取り込むといった工夫をしました。これにより、帳票データであっても回答精度を 40% から 90% へと大幅に向上させることができました。 図3. 帳票データを XML 変換するための仕組み 導入効果 今回の検証では回答精度 90% という良好な結果が得られたことから、今後の開発によって、保守手順文書を作成する際に設備マニュアルから引用するための工数を削減し、文書作成に要する時間を削減可能な見込みとなっています。また、同じ部品が違う呼び名で書類に記載されている場合など、従来の文書検索では類似語辞書を用意しなければ対応できないようなケースでも対応できるようになり、より柔軟性の高い回答が得られることが確認できています。 これらの結果を踏まえ、ベテランエンジニアの知識共有という当初の課題についても解決できそうだとの見通しが得られました。 今後の展望 日立パワーソリューションズでは、生成AI環境を独自に構成することで、生成 AI を活用するためのノウハウを習得することにも繋がりました。今後に向けて、自社の業務内容に合わせた生成 AI 環境「Power AI Ground（パワグラ）」をより発展させ、実運用で役立てていく予定となっています。社内で培った経験をもとに、社外向けのソリューション展開も検討しています。 まとめ 本事例は、AWS の生成 AI 技術が、多岐にわたる事業領域を持つ企業の技術伝承と業務効率化に大きく貢献できることを示しています。特に、Amazon Kendra と Amazon Bedrock の組み合わせによる RAG の実現は、専門性の高い多様な知識を効果的に活用する上で重要な役割を果たしました。さらに、サンプルコードを活用することで、3 ヶ月という期間で迅速に実装でき、より自社の業務課題に合わせた形でカスタマイズを行うことができました。 本件に関してご質問がございましたら、 株式会社日立パワーソリューションズ Web ページ よりお問い合わせください。 AWS は今後も、お客様のビジネス課題解決に向けて、最先端の生成 AI 技術と柔軟なクラウドインフラ、そして活用のご支援を提供してまいります。生成 AI に関してご興味のある方は、ぜひ AWS にお問い合わせください。

はじめに みなさん、生成AIサービス、活用していますか？ もっと生成AIを活用して、もっと多くの人がその恩恵を受けられるきっかけを提供したい！そんな想いから、AWSは、生成AIを使って日々の仕事を楽に、そして楽しくするサービスを開発するハッカソン「 AWS Japan 生成AI ハッカソン 」を開催することしました。 このハッカソンでは、企業における生成AI活用促進にフォーカスし、社員の方々が日々の仕事をもっと便利に、楽に、楽しくすることができるアプリを見出そうとしています。また同時に生成AIがもたらす高度な機能を組み込むだけでなく、開発する過程においても生成AIを駆使し、効率的に開発できることを皆さまと体験していけたらと考えています。 ハッカソンでご利用いただくのは「Amazon Bedrock」。Amazon Bedrock は単一のAPIを介してAI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデル (FM) を選択できるフルマネージドサービスです。Amazon Bedrockによってイノベーティブなサービスの開発が作りやすい環境が整ったといえるでしょう。 ご存じのとおり、ハッカソンではビジネス課題からユースケースを作成し、アーキテクチャーを定義して動くサービスとして実装し、プレゼンテーションまでを行います。この一連の流れを「生成AI」というキー・テクノロジーをベースに競い合い、楽しみながら経験できるのは非常に貴重な機会といえるでしょう。 以下に、ハッカソン参加の応募要領、評価基準などについてご紹介します。ぜひ皆さん奮ってご応募ください。 ハッカソンのテーマ テーマは 「生成AIを活用したアプリで社員がもっと楽しく、楽に仕事をすることが出来る仕組みを作ろう」です！ 生成AIが世に広く知られるようになって数年が経ちますが、企業に所属する社員の皆さんの中には日々の仕事においてその恩恵を十分に得られていない方も多いのではないでしょうか。生成AIの力を活用すればもっと仕事は楽に、楽しくできるはず。例えば、煩雑な作業を低減したり、創造性をかきたてたり、コミュニケーションを円滑化したり、抜け漏れを防止してくれたり・・・などなど、アイデアは無限に広がっていくでしょう。ぜひ、この機会にみなさんのアイデアを形にしてみませんか？ 審査について 審査ポイント 成果物に対する審査は、特に以下のポイントを重視します。 有用性 ユースケースの明確さ（対応する機会） アプリケーションの品質 生成AIの適用度 創造性 使うのが楽しくなるアプリケーションかどうか / 頻繁に使いたくなるアプリケーションかどうか 審査員の得点の合計および参加者相互の投票により、受賞候補者が決定され、総合得点が最も高い受賞候補者が受賞者となります。  審査員は QuizKnock 伊沢氏、鶴崎氏をはじめとする 豪華な顔ぶれが勢ぞろい! 審査にあたっては、多様な観点を網羅し、その価値を正しく審査できるよう各領域に通じた方々に審査員をお願いすることとしています。QuizKnock 伊沢 拓司氏は審査だけでなく、決勝戦ではナビゲーターとしても登場。決勝戦の舞台をよりエキサイティングに彩ります。そして、現役の AWSユーザーとしてアプリを実際に開発されている QuizKnock 鶴崎 修功氏や、データサイエンティストとしてのバックグラウンドを持ち、ライオン株式会社のDX戦略をリードされている 中林 紀彦氏など、まさに今イノベーションをリードする識者の方々による審査が行われます。さらに、アマゾン ウェブ サービス ジャパン合同会社でプロトタイピング & クラウドエンジニアリング チームを率いる 中田 光昭がAWS 開発のエキスパートとして審査に参加します。     参加要領 / ハッカソンの流れ このハッカソンは、チーム（最大４名）での参加をお願いしています。また、アイデアソン、ハッカソンはオンラインにて実施します。 希望者にはビジネスメンタリング、テクニカルメンタリングをそれぞれ実施します。 AWS Japan 生成 AI ハッカソンの流れ   応募要領/参加規約 参加条件 企業に所属する方でチームを組むことが出来る方 20歳以上の方 ハッカソンの各イベント（アイデアソン（イベントへの参加）、ハッカソン（ハッカソン期間中に開発を実施できること）、発表会（対面イベントへの参加））に参加可能であること 期日までに成果物を提出することができること チームでAWSアカウントを使用することができること AWSを使用してアプリケーションの開発と稼働を行うこと（※ハッカソン用としてAWS クレジットクーポン 25$を各チームに進呈します） Amazon Bedrockを使用すること 参加規約に同意できること チームメンバーの役割（例） ビジネスアイデアを出す アプリを設計する プログラミングを含む、実装を行う UIデザインをする プレゼンテーションを作成する 必要となる成果物 アプリケーションプログラム（デプロイされていること） ユースケースの説明スライド アプリケーションのアーキテクチャーの説明スライド アプリケーションのデモ動画 2.－4.を網羅したプレゼンテーション 参加までの流れ 当ページの登録フォームよりエントリー（代表者の方が必要事項を記入し、登録してください。10月2日締め切り） 本選への参加可否を確認する（10月４日までに代表者のメールアドレス宛にメールにてご連絡します） 本選参加確定の場合、代表者以外の各メンバーの方も全て別途ご案内する登録ページから登録する スケジュール 10月7日（月）17:00 ～18:00　説明会（オンライン） 10月11日（金）13:00- 17:00 アイデアソン（オンライン） 10月14日～25日　ハッカソン（オンライン：ただし、10月18日にオンラインにてメンタリングイベントを開催） 10月31日　14:00～18:00　発表会（対面：ザ・プリンス パークタワー東京（東京都港区）にて開催 ※ プレゼンテーションは10月25日までにいったん提出していただきます 賞品 優勝チーム：MacBook Pro もしくは25万円相当の物品、AWS クレジットクーポン USD500、優勝トロフィー 準優勝チーム：iPad Air もしくは10万円相当の物品、AWSクレジットクーポン USD 300、準優勝トロフィー ３位チーム：3万円相当の副賞、AWS クレジットクーポン USD 200、3位トロフィー なお、最終審査の結果、該当チームなしの場合もございます。  副賞・記念品の内容は現在検討中のため、変更となる場合がございます。 ハッカソン参加のメリット AWS Japan 生成AIハッカソンへ参加することのメリットをまとめました。ぜひ今一度ご覧ください。 生成AIアプリ開発を一通り体験できる：生成AIを組み込んだアプリ開発を、構想～設計～実装～発表までの一連の流れを体験することができます チームで協力しながら開発できる：チームでの参加なので、メンバーの得意分野を生かし協力しながら一つのものを作り上げることができます（参加希望多数の場合は選考の上参加チームを決定します） AWS BedRockが詳しくわかる：今回はAWS Bedrockを使って開発していただくことになりますので、AWS BedRockを詳しく知ることができます（参加チームにはもれなく25$ のAWS クレジットクーポンを進呈します） メンタリングを受けられる：アイデアソン、ハッカソン期間中にビジネスメンタリング、テクニカルメンタリングを受けることができます（希望者のみ） 大規模イベントの中で発表できるプレゼンテーションは 10 月 31日開催の AWS の生成AIをテーマとしたカンファレンス「AI Day」にて行い、上位 3 チームは 多くのオーディエンスを前にプレゼンテーションを行うことができます。また、AWSが発行するWebマガジン「builders.flash」にてレポート記事が掲載されます。 著名な審査員による審査：審査員には、QuizKnock 伊沢氏、鶴崎氏をはじめ、生成AIやアプリケーション開発、ビジネス開発に通じた著名な方々を想定しています。 総額200万円を超える副賞：みごと上位入賞された皆さまにはチーム単位でなく、メンバーそれぞれに賞品を贈呈いたします 最後に 生成AIサービスを作ってみたい、でもなかなかきっかけがない、という方はぜひチャレンジしてみてください。従来の開発とは異なる生成AIサービス開発ならではの気づきがあるでしょう。企業が今一番注目している生成AIの活用を皆さんがリードするチャンスです！ ぜひ こちらから ご応募ください

生成 AI の概要 生成人工知能 (生成 AI) は、会話、ストリー、画像、動画、音楽など新しいコンテンツやアイデアを生成できる AI の一種です。AI 技術は、画像認識、自然言語処理 (NLP)、翻訳などの従来とは異なるコンピューティングタスクで、人間の知能をまねようとしています。 生成 AI では、巨大なデータで事前に学習された大規模な機械学習 (ML) モデルがサポートされています。生成 AI では、次の 2 種類のモデルを認識する必要があります。 基盤モデル (FMs) は、一般化されたラベル無しのデータでトレーディングされ、パターンと関係性を学習させ、次の系列の項目を予測する ML モデルです。 大規模言語モデル (LLMs) は、FM のサブクラスの 1 つで、系列の次に来る単語を予測するようにトレーディングされています。 マッキンゼーの調査 では、63 のユースケースで生成 AI が年間 2.6 兆から 4.4 兆米ドルの付加価値を生み出す可能性があると推定されています。これは、英国の GDP 3.1 兆米ドルと比べても非常に大きな数字です。 多くの SAP のお客様は、この新しい技術からどのようにビジネスの成果を向上できるかを尋ねています。いくつかの質問例は次のとおりです。 SAP お客様向けに利用可能な生成 AI 活用ユースケースは何ですか ? 生成 AI は SAP お客様にどのようなビジネス価値を提供できますか ? 生成 AI を活用して SAP 環境をモダナイズするために何を提供していますか ? 生成 AI 活用はどこから始めるべきですか ? お客様の生成 AI 活用は、誰が支援できますか ? SAP のビジネスプロセスに生成 AI の導入をどのように成功させますか？ 最近、AWS と SAP は戦略的な協業を拡大し 、クラウド ERP (Enterprise Resource Planning) を変革し、企業が生成 AI の活用を支援しています。この協業アナウンスには以下の取り組みが含まれています。 SAP AI Core の Generative AI Hub は、Amazon Bedrock の生成 AI モデルと連携できます。これにより、SAP お客様が高パフォーマンスの大規模言語モデルと基盤モデルにアクセスして、カスタマイズされた AI アプリケーションを構築できるようになります。 SAP は、将来の SAP Business AI オファリングの学習と構築に AWS Trainium と Inferentia チップを使用する予定です。これにより、AI モデル開発プロセスを加速できます。実際の検証では、SAP エンジニアが同等の Amazon EC2 インスタンスで 23 日かかるところを、2 日で生成 AI LLMs の学習とファインチューニングを行いました。 このブログは、SAP お客様の質問に答え、AWS での生成 AI 活用のジャーニーを始めることを支援し、SAP への投資からより多くの価値を引き出すことを目的に書いています。 生成 AI はどう SAP お客様を支援するのか AWS チームは、多くの SAP お客様との会話から、お客様が検証や実装を行っている一般的な生成 AI の活用ユースケースを特定しました。以下のリストは網羅的なものではありませんので、他にビジネス課題を解決するためのユースケースを検討したい場合はご連絡ください。 No ペルソナ ユースケース ビジネスベネフィット 関連 AWS サービス ビジネスユースケース 1 販売在庫分析者 倉庫の在庫状況のリアルタイムインサイトを収集し、在庫切れと過剰在庫の状況を回避 製品の入手可能性や価格の安定性に関するお客様の信頼向上 Amazon Bedrock 2 Order-to-Cashの分析者 生成 BI 機能を使用してセルフサービスレポートを作成 Order-to-Cash プロセスを最適化し、処理時間とプロセスのボトルネックを削減し、意思決定を向上 Amazon Q in QuickSight 3 セールスアカウントマネージャー 販売ドキュメントを要約および分析することで顧客インサイトを獲得 顧客の注文とニーズを 360 度ビューで把握し、アップセリングの機会を創出 Amazon Q Business または Amazon Bedrock 4 調達管理者 RFP (提案依頼書) で記載した要件に対する複数の回答と見積もりを確認 RFP 回答の分析における生産性を向上させ、調達の意思決定を迅速化 Amazon Q Business 5 マスターデータ管理者 生成 AI を使用して、複数の言語での製品説明と画像を生成 SAP におけるマスターデータの生産性と正確性を向上させ、グローバル運用での非効率を回避 Amazon Q Business または Amazon Bedrock 6 エグゼクティブ (VP、SVP など) SAP レポートからリアルタイムインサイトを取得し、C レベル向けの電子メールを生成 CxO レベルと取締役会レベルでの意思決定を加速 Amazon Bedrock 7 財務監査管理者 SAP に集められた様々な財務取引に基づき、会社の方針に従ってリルタイム監査インサイトと異常を収集 監査コンプライアンスを迅速に処理し、異常に対する不要なエスカレーションを回避 Amazon Bedrock 8 支払債務管理者 調達から支払いまでのプロセスにおけるリアルタイムインサイトから、請求書の照合と異常の検出を実施 支払いを迅速に処理し、ベンダーとの関係を改善し、異常に迅速に対処 Amazon Bedrock 9 法務担当者 保険の補償範囲を理解するために保険ポリシー文書を要約 請求プロセスの完全性を確保し、長期的には顧客とベンダーとの関係を改善 Amazon Q Business または Amazon Bedrock 10 従業員 調達プロセスに関する会社の方針を理解 コンプライアンスを確保し、サービスと設備の調達を加速 Amazon Q Business 11 従業員 従業員福利厚生、補償範囲、請求プロセスに関する会社の方針を理解 従業員の生産性と福利厚生に対する満足度を向上 Amazon Q Business 技術的なユースケース 12 SAP ABAP 開発者 Eclipse IDE で ABAP プログラムを生成することで SAP プロジェクトを加速 開発者の生産性を最大 70% 向上 Amazon Bedrock 13 SAP ABAP 開発者 グローバル展開のための多言語印刷フォームを生成 印刷フォームを 1 回作成し、翻訳が優れた LLM により固定テキストと SAP の長いテキストを処理して、グローバルに展開 Amazon Bedrock 14 SAP ABAP 開発者 適切なドキュメントが不足の場合でも、プログラムから技術仕様とテストスクリプトを作成 SAP コンサルタントと開発者の仕様とテストスクリプトの正確性を向上 Amazon Q Business 15 SAP システム管理者 システム管理のタスクを迅速に完了 SAP システムの保守における生産性の向上とミスの削減 Amazon Q Developer AWS の生成 AI サービス AWS は、SAP お客様向けに、事前パッケージ化された生成 AI アプリケーション、独自の生成 AI アプリケーションの構築、独自の大規模言語モデル (LLMs) の開発など、生成 AI サービスを提供しています。 生成 AI スタック AWS サービス その他のサービス SAP コンテキスト 独自の大規模言語モデル開発 AWS Trainium は、AWS が 1000 億パラメータ以上のモデルの深層学習トレーニングに特化して開発した第 2 世代の機械学習アクセラレータです。一方、 AWS Inferentia アクセラレータは、AWS が Amazon EC2 上の深層学習と生成 AI の推論アプリケーションに低コストで高性能を実現するよう設計したものです。 GPU、SageMaker、Ultra Cluster、EFA、EC2 Capacity Blocks、Neuron この最も高度なシナリオでは、SAP のお客様は社内の AI/ML 機能に大きな投資を伴います。事前トレーニングされた LLM がビジネスドメインに適合しないため、独自の LLM を構築するシナリオです。 独自の生成 AI アプリケーション構築 Amazon Bedrock は、FM を使用して生成 AI アプリケーションを構築およびスケーリングするための環境を提供します。これは、主要な AI 企業から高性能の FM を選択できる、完全マネージドサービスです。セキュリティ、プライバシー、責任ある AI に関する幅広い機能も提供されます。また、ファインチューニング、検索拡張生成 (RAG)、タスクを実行するエージェントの構築もサポートしています。 Guardrails, Agents, Fine-Tuning, Retrieval Augmented generation このコンテキストでは、SAP のお客様は Bedrock で利用可能な Anthropic Claude、Amazon Titans、Stability AI などの事前トレーニングされた LLM を活用したいシナリオです。提供される LLM は、プロンプトエンジニアリング、検索拡張生成、ファインチューニングなどの一般的な手法を使用することで、十分にユースケースを満たすことができます。 パッケージ化された生成 AI アプリケーション Amazon Q は、ビジネスに合わせてカスタマイズできる、作業向けの生成 AI アシスタントです。会社のデータ、情報、システムに接続することができます。 Amazon Q in QuickSight は、自然言語プロンプトを使用してビジネスデータからインサイトを簡単に作成・活用できる生成 BI アシスタントです。これにより、ダッシュボードやストーリーの作成が加速し、ビジネスプロセスでの意思決定が迅速化されます。 Amazon Q in AWS Supply Chain は、サプライチェーンプロセスの最適化を支援する生成 AI アシスタントです。 Amazon Q in Connect は、顧客の質問に対する応答とアクションを提案し、迅速な問題解決と顧客満足度の向上を実現します。エージェントは、リアルタイムの会話中に、さまざまなリポジトリからのナレッジ記事、Wiki、FAQ にアクセスできます。 Amazon Q Developer SAP のお客様の大半は、おそらくこのカテゴリに該当し、事前構築された生成 AI サービスを活用してイノベーションを始めるでしょう。 数ステップの設定作業を実行することで、従業員の生産性を向上させるための独自の生成 AI アシスタントを構築できます。また、企業の意思決定を加速するために、ビジネスユーザがセルフサービスでレポートを作成できるように独自の生成 BI 機能を構築できます。 Amazon Q Developer は、ソフトウェア開発ライフサイクルの加速に役立ちます。 SAP ユースケースにおける Amazon Q と Amazon Bedrock の比較 Amazon Q と Bedrock の提供内容について詳しく見ていきましょう。これらは、事前構築されたサービスと生成 AI 機能を揃っているサービスにより、SAP のユースケースの大半をカバーし、生成 AI の採用を加速します。 Amazon Q Business は、エンタープライズデータに基づいて質問への答え、文書の要約、コンテンツ生成、タスク実行ができるように構成できる、マネージドサービスの生成 AI アシスタントです。AWS クラウドサービス内のさまざまなサービスに組み込まれています。ここでは 2 つの提供内容について説明します。 Amazon Q Business は、社内ポータル、SharePoint、Amazon S3 バケットなどの企業データソースと連携することで、独自の生成 AI アシスタントを作成するのに最適なオプションです。これらのナレッジベースを活用して質問に答えられる機能により、企業がメリットを得るための最も手軽な方法となります。 Amazon Q in QuickSight は、ユーザーにセルフサービスのレポーティングプラットフォームを提供することで、生成 BI の利活用が始められます。ユーザーは、SQL 文、結合メカニズム、その他の技術要素を理解しなくても、自然言語で独自のビジュアルダッシュボードやストーリーを作成できます。 AWS Supply Chain と Amazon Connect は、特定のビジネスシナリオ向けに構築されたマネージドサービスです。これらのサービスを使用すると、Amazon Q がデフォルトで組み込まれることで、重要なビジネスプロセスの生産性が向上します。 一方、Amazon Bedrock は、開発者に完全マネージド型の機械学習サービスを提供し、カスタム AI モデルとアプリケーションの構築、デプロイ、スケーリングを可能にします。さまざまな大規模言語モデルを評価、選択、調整する機能を備えています。モデル開発とトレーニング、モデルホスティングとデプロイ、監視とオブザベーション、セキュリティとコンプライアンス、スケーラビリティとコスト効率、さらに幅広い AWS エコシステムとの統合のための管理環境を提供します。Amazon Bedrock は、インフラストラクチャとオペレーションをマネージドで実施しているため、AI アプリケーションの開発プロセスを簡素化し、開発者がモデル開発とアプリケーションロジックに集中できるようにします。 Amazon Q と Bedrock がサポートするセキュリティ標準 Amazon Q Business では、ユーザーのアクセス許可に基づいて適切なコンテンツにアクセスできるようデータのアクセス制御をサポートしています。Okta、Azure AD、Ping Identity などの外部 SAML 2.0 対応の ID プロバイダーと Amazon Q Business の Web エクスペリエンスを統合することで、ユーザー認証と認可を管理できます。 Amazon Bedrock は、お客様のプロンプトを AWS モデルの学習やサードパーティへの配布に使用することはありません。各モデルプロバイダーは、自身のモデルをアップロードするためのエスクローアカウントを持っています。Amazon Bedrock の推論アカウントにはこれらのモデルを呼び出す権限がありますが、エスクローアカウント自体には Amazon Bedrock アカウントへの送信権限はありません。さらに、モデルプロバイダーは Amazon Bedrock のログやお客様のプロンプトにアクセスできません。 Amazon Bedrock は、お客様の学習データを基盤モデルの学習やサードパーティへの配布に使用することはありません。使用タイムスタンプ、ログインしたアカウント ID、サービスによってログに記録されたその他の情報など、その他の使用データもモデルの学習に使用されることはありません。 Amazon Q と Bedrock を SAP に連携する方法 前述の考慮事項を踏まえ、Amazon Q と Bedrock を活用して SAP 環境で生成 AI 機能を有効にする方法について、いくつかのアーキテクチャガイダンスを説明します。これらは SAP での生成 AI の使用事例を網羅したリストではありません。アーキテクチャガイダンスは、ランドスケープと要件によって異なる可能性があります。 SAP ユースケースでは、まずSAP BTP の Generative AI Hub を検討 ブログ AWS と SAP の生成 AI サービスを活用しセキュアでスケーラブルなビジネス環境に では、SAP AI Core サービスが大規模言語モデルなどの AI アセットをお客様に公開し、SAP BTP エコシステム上で実行される SAP アプリケーション向けの統一インターフェースを提供しています。 このジョイントリファレンスアーキテクチャ (JRA) では、SAP AI Core の Generative AI Hub を Amazon Bedrock へのアクセスとライフサイクル管理レイヤーとして使用し、アプリケーションが基盤モデルを利用できるエンドポイントを提示しています。 Generative AI Hubを通じて、SAP は SAP エコシステム全体でコンテンツフィルタリング、SAP 固有のリスク軽減、セーフティガードレールを一元的に適用し、潜在的なビジネスおよび法的リスクに対する規制準拠のアプローチを提供しています。 図 0. SAP AI Core を通じて Amazon Bedrock 呼出し SAP インサイトの参考構成 (例：ユースケース 1 ) 下の画像は、カスタムレポートの作成がなくても、セールスマネージャーが SAP Fiori Launchpad から直接在庫状況を問い合わせることができる機能を説明しています。これにより、従来のカスタム開発するための約 14 人日の ABAP 開発とテスト工数を削減できる可能性があります。 ユースケースの流れ: 英語でのクエリ: “Product highest inventory value at Chennai Warehouse” “The product with highest inventory value at Chennai Warehouse is Infrared Camera with total value of $1700” 図 1. SAP インサイト SAP Datasphere と SAP S/4HANA との統合機能を備えた SAP HANA Cloud を活用しています。このシナリオでは、SAP Build Apps でユーザからの自然言語でのクエリを受け、API Gateway が提供する REST API をトリガーできます。この REST API 自体が Lambda 関数をトリガーし、Amazon Bedrock で提供される Retrieval Augmented Generation (RAG) をトリガーします。これは SAP HANA Cloud からのデータと連携できます。この構成は、AI Core 上の SAP Generative AI Hub を使用して、レイテンシを最小化しパフォーマンスを向上させるように変更することも可能です。 図 2. SAP インサイトアーキテクチャ図 ビジネスユーザー向けのセルフサービスレポーティングの参考構成 (例：ユースケース 2) Amazon Q in QuickSight が、ビジュアル作成とストーリーを通じて、ビジネスユーザーが自身でセルフサービスレポートを作成できる方法を、以下の画像で説明します。これにより、専門のデベロッパーやアナリティクスチームを関与しなくても、さまざまなレポートの作成に要する時間を数日から数時間に短縮できる可能性があります。 ユースケースの流れ: ターゲットオブジェクト に沿ったストーリーを作成するために英語のプロンプトを入力します ストーリーを作成するために含める必要なダッシュボードのビジュアルを選択します ビルドをクリックします タイトルは Amazon Q によって自動的に生成されます セクションは Amazon Q によってストーリーの流れで作成されます 最後に結論が生成され、推奨事項生成で完成になります 図 3. Amazon Q in QuickSight によるセルフサービスレポーティング SAP Datasphere と SAP S/4HANA との統合機能を備えた SAP HANA Cloud を活用しています。Athena は、データフェデレーション機能を使って SAP HANA Cloud からデータ参照するように構成できます。ビジネスユーザーは、Athena を通してデータを取得し、Amazon Q in QuickSight で自然言語プロンプトを使ってビジュアルダッシュボードやストーリーを作成できます。 SAP のデータソースウィザードは、この構成を実現するための関連 Lambda 関数を作成します。 図 4. セルフサービスレポーティングの参考構成 SAP 向け生成 AI アシスタントの参考構成 (例: ユースケース 2、3) 下の画像は、Amazon Q が SAP Work Order アプリケーションの作業手順書とチャットすることで、保守エンジニアを支援する方法を説明しています。これにより、数百ページの印刷や、特定の情報を探すための各ページの確認が不要になり、プラント保守の生産性、正確性、作業品質が向上します。 ユースケースの流れ: メンテナンスオーダーには、バルブの修理方法を説明した作業手順 PDF を添付しました SAP にアップロードされたら、その PDF は Amazon Q Business でクロールされ検索可能になります。ユーザーは「How to repair the control valve if it has leakages ?」のように、ドキュメントを問い合わせることができます 図 5. SAP 向けの生成 AI アシスタント SAP ERP または S/4HANA には、トランザクションデータ (構造化データ) と文書 (非構造化データ) の両方が含まれています。 トランザクションデータは Amazon AppFlow を使用して Amazon S3 バケットに抽出できます。これを Redshift にロードするか、または Athena で直接読み取ることができます。Amazon Q in QuickSight は、Redshift または Athena のいずれかをデータソースとして使用し、自然言語プロンプトを使用したセルフサービスレポーティングの生成的 BI 機能を可能にします。これにより、SQL やプログラミングの知識がなくてもビジネスユーザーが独自のダッシュボードやストーリーを作成できます。ポイント 1、4、6 を参照してください。 SAP トランザクションに添付された請求書、契約書、見積書等の文書は、 AWS SDK for SAP ABAP または SAP Content Server を使用して S3 バケットに抽出できます。これらの非構造化データは、Amazon Q Business でクロールされインデックス付けされ、AWS IAM Identity Center によってエンドユーザーのアクセスが制御できます。 図 6. SAP 向け生成 AI アシスタントの構成図 上の図のステップの説明: AWS SDK for SAP ABAP を通じて、SAP レポート、添付ファイル、アーカイブデータを Amazon S3 バケットに抽出します Amazon Q は、Amazon S3 バケットに抽出されたデータ (購買発注書、請求書、マテリアルマスター、品目マスター、保守発注書、作業指示書など) をクロールします Amazon Q は、プロジェクト情報、作業ログ、現場写真、現場安全観察、日次調査などを含む他のデータソース (SharePoint、Jira、Zendesk など) からもクロールします S3 からの構造化データとレポートは、Athena 経由又は Redshift にロードでき、その後 Amazon Q と QuickSight を使用して、S3 に保存できるストーリーボードやレポートを作成できます AWS IAM Identity Center を統合して、Active Directory、Okta、その他のアイデンティティプロバイダーでユーザー認証ができます ユーザーは Web ブラウザから Amazon Q と QuickSight にアクセスでき、Fiori などの SAP フロントエンドに埋め込むこともできます ABAP Assistant for SAP の参考構成 (例：ユースケース 12) 下の画像は、Bedrock の機能を Eclipse 開発ツールに統合することで、ABAP コードとドキュメントを生成する方法を説明しています。この機能により、ABAP プログラミングを高速化し、ABAP ドキュメントの作成を支援することで、SAP での Clean Core 実装を加速できると考えられ、開発者の生産性が 70% 向上すると期待できます。 SAP ABAP Assistant プラグイン を使えば、SAP 開発者は Eclipse IDE から ABAP コードと ABAP ドキュメントを生成できます。ABAP Assistant Eclipse プラグインは Eclipse IDE にインストールされ、開発者の個人パソコンで動きます。 ユースケースの流れ: ビジネス要件に基づいて ABAP プログラムを作成するためのプロンプトを書き、Amazon Bedrock を呼び出します プロンプトから ABAP プログラムが自動生成されます 図 7. SAP 向け ABAP アシスタント 図 8. SAP 向け ABAP アシスタントの構成図 上の図のステップの説明: ABAP 開発者は、コマンドラインインターフェース (AWS CLI) を使用して AWS IAM Identity Center で認証を行い、プラグインで使用される認証情報を取得します。 ABAP 開発者は、SAP システムを Eclipse の ABAP プロジェクトとして追加します。 ABAP 開発者が ABAP Assistant プラグインを呼び出すと、設定された AWS Identity and Access Management (IAM) ロールを引き受け、Amazon Bedrock を呼び出すために必要な認証情報を生成するために AWS Security Token Service (STS) が呼び出されます。 ABAP Assistant プラグインは、Amazon Bedrock サービスを呼び出して ABAP コードとドキュメントを生成し、結果を Eclipse に返します。 まとめ 私たちは、さまざまな生成 AI の SAP ユースケースとその潜在的なビジネス価値について説明しました。また、SAP 環境での変革を始め、加速させるのに役立つ AWS のサービスオファリングについても説明しました。 これから、お客様の SAP 環境のために生成 AI の力を解き放つことが可能になりました。Amazon Q と Bedrock を使えば、これまでにないほど簡単に始められます。 Amazon Q のドキュメント と ブログ をご確認し、Amazon Q 搭載の生成 AI アシスタントの設定方法を学んでください。ステップバイステップのガイド、サンプル構成、ベストプラクティスがあり、SAP に添付されたドキュメントの要約から、意思決定を加速するための推奨事項の生成まで、あらゆることをサポートできる Q モデルをすばやく展開できます。 Amazon Q in QuickSight を使って、ビジネスユーザー向けのセルフサービスレポーティングを始め、生成 BI アシスタントとして、ビジュアルダッシュボードやストーリーを簡単に作成することで、意思決定スピードを向上させます。 Amazon Bedrock のドキュメント と ブログ もご確認ください。Bedrock は、大規模言語モデルを構築し、本番規模で展開するための包括的な基盤を提供します。Bedrock を使えば、事前学習済みモデルを調整し、安全にホストし、SAP アプリケーションに統合できます。 AWS Generative AI for SAP ワークショップ を試して、Bedrock、Amazon Q、QuickSight の機能を体験してください。このワークショップは現在、SAP AI Core の Generative AI Hub を含めるように改訂中です。 PartyRock も忘れずに探索して、Bedrock 搭載のプレイグラウンドで AI 生成アプリの構築を体験してください。 最後に、 Amazon Bedrock の生成 AI モデルを統合する SAP AI Core の Generative AI Hub を検索してみましょう。これにより、SAP お客様は高性能な大規模言語モデルと基盤モデルにアクセスして、AI アプリケーションを構築できるようになります。 AWS for SAP ブログ を確認し、SAP への投資からより多くの価値を得る方法について情報を収集してください。今日から Amazon Q と Amazon Bedrock を使い始め、ビジネスに生成 AI の力を解き放ちましょう! SAP on AWS ディスカッションへの参加 お客様のアカウントチームと AWS サポートチャネルに加えて、最近 re:Post – AWS コミュニティ向けの質問と回答のサイトをローンチしました。AWS for SAP ソリューションアーキテクトチームは、AWS for SAP のトピックを定期的に監視し、お客様やパートナーの皆様をサポートできる議論や質問に回答しています。質問がサポート関連でない場合は、re:Post に参加してコミュニティのナレッジベースに貢献することをご検討ください。 クレジット このブログへの貢献に感謝したいチームメンバー: Gyan Mishra, Adren D Souza, Derek Ewell, Beth Sharp, Spencer Martenson。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

本ブログは、株式会社 朝日新聞社 と Amazon Web Services Japan が共同で執筆しました。 株式会社 朝日新聞社 は 140 年以上と国内有数の歴史を持つメディア企業であり、紙からデジタルまで幅広い媒体で情報を提供しています。本ブログでは朝日新聞社が開発したコンテンツ制作支援サービス 「ALOFA」 の概要とそのなかでどのように Amazon Bedrock が活用されているかを紹介します。 コンテンツ制作における課題 コンテンツ制作の現場では、取材の音声データの文字起こしに膨大な時間と手間がかかる、使いたい音声・動画ファイル、シーンを見つけるのが大変、大量の取材データが PC のストレージを圧迫してしまう、大量のデータをうまく活用できないなどの課題に直面する場合があります。朝日新聞社ではそのような課題を解決するために、コンテンツ制作支援サービスを開発しました。現在このツールは朝日新聞社の記者に提供され、記者の記事制作における効率化に貢献しています。このコンテンツ制作支援サービスは現在社内向けに公開されていますが、社外への展開も検討しています。 ソリューションの概要 本コンテンツ制作支援サービス ALOFA では独自の音声認識モデルを活用し高品質な文字起こし体験を提供します(業務効率化の取り組みにご興味がある方は「 株式会社朝日新聞社での文字起こしシステムにおけるサーバーレスの活用 – 処理時間を短縮し業務貢献しながらクラウド費用も削減した話 」をご覧ください)。以下の図 1 は ALOFA の画面イメージになります。 図 1 ALOFAの画面イメージ ALOFA のエディタを使って音声を聴きながら書き起こし文を細かく修正することができます。独自の話者分離モデルによる話者の識別に加え、話し言葉特有の冗長表現を検知・削除できる機能を搭載しています。また、ハイライト機能や要約、チャプター生成機能によってファイルの内容や重要な部分がすぐに把握できます。 ALOFA は AWS 上で稼働しておりサーバーレスのサービスを活用して実現しています。生成 AI は要約やチャプターの生成などに利用しており、生成 AI のプラットフォームとして Amazon Bedrock を利用しています。 Amazon Bedrock は 単一の API を介して 複数のモデルを選択することができるため、特定のタスクの解決するためにどのモデルが最適なのかを容易に検証することができます。朝日新聞社では用途に応じて最新の複数のモデルを検証し、それぞれの用途に最も適したモデルを採用しました。また Amazon Bedrock は AWS の他のサービスから容易に呼び出せるため、既存のワークロードに生成 AI を容易に導入できます。以下の図 2 がアーキテクチャーの概要になります。 図 2 コンテンツ制作支援サービスのシステム構成 本システムでは並列処理の中で Amazon Bedrock を呼び出すユースケースがあり、 Amazon Bedrock へのリクエストが多くなってしまう場合があります。急激なリクエストの増加に対応するため以下の図 3 の様に AWS Lambda から複数リージョンのエンドポイントを呼び出すアーキテクチャーを採用しています。推論処理を複数のリージョンに分散することにより安定的に生成 AI を活用することができています。 図 3 Amazon Bedrock のマルチリージョンアーキテクチャーイメージ まとめ 本ブログでは 朝日新聞社で開発されたコンテンツ制作支援サービスの紹介とその中で Amazon Bedrock がどのように活用されているかを紹介しました。 Amazon Bedrock を利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。 本ブログは、株式会社朝日新聞社メディア事業本部メディア研究開発センター 山野氏、嘉田氏、杉野氏とソリューションアーキテクトの紙谷が共同で執筆いたしました。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター PdM 兼機械学習エンジニア　山野 陽祐 文字起こしサービスの開発全般と機械学習のモデル構築に従事しています。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター 機械学習エンジニア兼バックエンドエンジニア　嘉田　紗世 主に文字起こしサービスの開発や画像分野の研究に従事しています。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター 機械学習エンジニア　杉野　かおり 文字起こしサービスに関する研究や、データ作成基盤運用に従事しています。

はじめに コンタクトセンターのエージェントは、複雑なワークフローを伴うトピックでもお客様をサポートしています。 Amazon Connect エージェントワークスペース 内のステップバイステップガイドは、特定のユースケースを処理する方法をエージェントに明確な手順として示します。ステップバイステップガイドはエージェント向けのワークフローで、エージェントの選択に基づいて分岐したり、外部システムとデータを送受信したりできます。ステップバイステップガイドはエージェントの生産性を高め、トレーニング時間を短縮し、一貫したカスタマーエクスペリエンスの提供を支援します。このようにステップバイステップガイドを操作する際、エージェントは機密データや極秘データを収集・入力することも頻繁にあります。そのようなデータは、通話ログや画面録画に記録されるべきではありません。 このブログ記事では、特定のステップバイステップガイドが呼び出されたときに自動的に録画を一時停止し、ワークフローが完了したら録画を再開するソリューションについて詳しく説明します。このソリューションでは、ワークフロー区間中の記録を自動的に停止する方法についても説明しています。 ソリューションの概要 このソリューションでは、 AWS CloudFormation テンプレート を使用して、必要なコンタクトフローと AWS Lambda 関数 を作成します。Amazon Connect コンタクトフローの ログ記録動作の設定 ブロックは、機密情報を収集する ステップバイステップガイドビューを呼び出す前にコンタクトフローのログ記録を無効にします。ビューが完了すると、コンタクトフローの ログ記録動作の設定 がコンタクトフローのログ記録を再開します。 SuspendContactRecording API は、コンタクトメディアとエージェントの画面の録画を一時停止します。コンタクトフローでは、Lambda 関数がビューを表示ブロックの前に SuspendContactRecording API を呼び出します。完了すると、別の Lambda 関数がコンタクトフローで ResumeContactRecording API を呼び出して、録画を再開します。 必要なアセットがデプロイされた後、ユーザーは次の手順で作成されたコンタクトフローに Amazon Connect の電話番号を指定する必要があります。テスト時に通話の発信者は 1 を押して新しい銀行口座を開設の希望を選び、ステップバイステップガイドを利用するエージェントに接続します。 このソリューションのアーキテクチャ図は以下の通りです。 ステップバイステップガイド内のビューに入力されたデータはすべてチャットとして記録されることに注意してください。ガイドの記録を削除して、意図しないデータ漏えいを防ぐため、このデータは適切に保護または消去する必要があります。 デプロイ手順 前提条件 このブログ投稿の手順を実施するには、以下の通り、サービスの使用方法の理解、サービスの権限の用意が必要です。 管理者アクセス権限を持ち、マネジメントコンソールにアクセス可能な AWS アカウント ロールとポリシーを作成するための AWS IAM へのアクセス権限 電話番号が割り当てられ、通話録音と画面録画が有効になっている Amazon Connect インスタンス スタックを実行するための AWS CloudFormation ステップ 1: Amazon Connect インスタンスの詳細を取得します AWS マネジメントコンソール にサインインし、Amazon Connect インスタンスと同じリージョンを選択します このスタックを展開する対象の Amazon Connect インスタンスの ARN を特定してメモします。「 Amazon Connect インスタンスの ID/ARN を検索する 」を参照してください Amazon Connect ダッシュボードのキューセクションに移動します BasicQueue を検索します。検索結果からキュー名をクリックします 追加のキュー情報を表示 という名前のセクションを展開します。ARN をメモします 左の画像をクリックし、AWS CloudFormation テンプレートを起動します 一意のスタック名を入力します。この例では、 SBS-pause-recording を使用しています このスタックを展開する Amazon Connect インスタンスの ARN と、Contact Flow を関連付ける Amazon Connect キューの ARN を入力します IAM リソースの作成に同意します スタックの作成 を選択して、必要なアセットをプロビジョニングします。これには 10 分かかります このスタックの状態が CREATE_COMPLETE になるまで待ちます Amazon Connect インスタンスに移動し、電話番号にフロー SBS-pause-recording-SBSPauseResumeDemoHandler を関連付けます ソリューションのテスト URL https:// （Amazon Connect インスタンスエイリアス名） .my.connect.aws/agent-app-v2 を使用して、エージェントワークスペースにログインします。Connect インスタンスエイリアス名は、 このリンク から確認できます フロー SBS-pause-recording-SBSPauseResumeDemoHandler に関連付けられた電話番号に架電します 通話が接続され、番号の入力を求められたら、 1 を押して新しい銀行口座開設の手続きを選びます エージェントがエージェントワークスペースで着信を受け入れると、ステップバイステップガイドが自動的にロードされます 「新しい口座を開く (Open a new account) 」ボタンをクリックします 「新しいリクエストを開始 (Start a new request) 」をクリックします 新しい口座フォームに顧客情報を入力します 「 送信 (submit) 」をクリックします フォームに入力された情報に不足がなければ、以下の画面に推移します この時点で、通話を切断し、コンタクトを閉じることができます  (エージェントワークスペースで通話を切断し、コンタクトを閉じることが必要です。コンタクトを閉じることにより、録音が完了し、すべての必要なログの生成が開始されます。) AWS マネジメントコンソールで CloudWatch に移動します 左側の ログ を展開します。 ログ の下の ロググループ をクリックします ロググループ内で、Amazon Connect インスタンスのロググループをクリックします。ここで、行われたテスト通話のログを検索できます 通話の詳細が表示されます。この ページ で LoggingBehavior を検索すると、通話の接続後、最初にログが有効になった箇所が表示されます。2 回目の LoggingBehavior のログは、ログ記録が再度有効になった箇所を示します。2 回目の LoggingBehavior が有効になったログメッセージと、その前のログメッセージの時間差に注目してください。ログ記録が一時停止された時間差が確認できます Contact Lens で通話録音と画面録画が有効になっている場合、録音と録画を確認でき、エージェントが機密情報を記録している間、録音と録画が一時停止されていることがわかります。 クリーンアップ 今後の課金を避けるため、作成されたすべてのアセットを削除してください。以下のスクリーンショットのように CloudFormation でスタックを削除することで、アセットを削除できます。 訳注: 電話番号とコンタクトフローの紐づけを解除してから削除を行う必要があります 結論 このブログ記事では、ステップバイステップガイドを使用してエージェントが機密情報を扱う際に、セキュリティコンプライアンスを維持する方法を示しました。このソリューションを使用すると、機密データの収集中に録音と録画を一時停止できます。他の詳細については、 Amazon Connect のドキュメント にアクセスするか、AWS の担当者にお問い合わせください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

この記事は Migrating from AWS App Mesh to Amazon ECS Service Connect (記事公開日: 2024 年 9 月 24 日) を翻訳したものです。 慎重に検討した結果、2026 年 9 月 30 日をもって AWS App Mesh のサポートを終了することを決定しました。この日まで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリソースの作成や新しいアカウントのオンボーディングなど、通常通りにサービスを利用できます。また、AWS はこの期間中も、AWS App Mesh にセキュリティと可用性に関する重要な更新を引き続き提供します。新規のお客様は、2024 年 9 月 24 日以降、AWS App Mesh にオンボーディングできなくなります。 re:Invent 2022 で、AWS は Amazon ECS Service Connect をリリースしました。これは、 Amazon Elastic Container Service (Amazon ECS) 内のマイクロサービスを接続する新しい方法です。本投稿では、Service Connect の詳細と、 AWS App Mesh から Service Connect への移行戦略について説明します。Service Connect は、外れ値検出やリトライによって、コンテナ化されたマイクロサービスの信頼性を向上させます。また、アプリケーションレベルのネットワーキングメトリクスを Amazon CloudWatch に送信することで、オブザーバビリティも向上させます。Service Connect では、マネージドなネットワーキングデータプレーンを利用することで、サイドカープロキシの管理に伴う差別化につながらない重労働が不要になります。 App Mesh と Service Connect の比較 サービスメッシュは抽象化レイヤーを通じて、ルーティングルールを実装し、セキュリティレイヤーを追加し、オブザーバビリティを提供します。App Mesh から Service Connect への移行をはじめる前に、Service Connect の抽象化レイヤーを理解し、App Mesh の抽象化レイヤーと比較することが重要です。このセクションでは、Amazon ECS にデプロイされた多層アプリケーションを使用して、これらの抽象化を説明します。 次の図 1 は、サービスメッシュを実装する前のサンプルアプリケーションを示しています。フロントエンドサービスと、ユーザー、ストックという 2 つのバックエンドサービス API で構成されています。3 つのサービスは、長時間稼働する サービス として Amazon ECS にデプロイされており、1 つ以上のタスクが実行されています。Application Load Balancer や Network Load Balancer といったロードバランサーは、耐障害性を提供し、アーキテクチャ内の各サービスのタスク全体にトラフィックを分散します。 図 1: サービス間のルーティングをロードバランサーで提供するサンプルアプリケーション このアーキテクチャで App Mesh を利用する場合、抽象化によってルーティングルールとセキュリティ境界を実装します。各マイクロサービスは、 App Mesh の Virtual Service にカプセル化されます。Virtual Service には、 App Mesh の Virtual Node と呼ばれる複数のバージョンのアプリケーションがあり、 App Mesh の Virtual Router が Virtual Node 間のルーティングルールを実装している場合があります。 次の図 2 は、App Mesh を利用するサンプルアプリケーションを示しています。3 つの Amazon ECS サービスの各タスクに対して、セルフマネージドの Envoy プロキシ をサイドカーコンテナとしてデプロイします。このプロキシは、App Mesh のルーティング、信頼性、オブザーバビリティといった機能を実装しています。また、サービス間のクライアント側のルーティングも提供されるため、必要なロードバランサーの数を減らすことができます。 AWS Cloud Map の名前空間 はサービスディスカバリに利用され、各リソースは App Mesh リソースの論理的な境界である App Mesh の Mesh にアタッチされます。 図 2: App Mesh を利用するサンプルアプリケーション Service Connect はこれらの抽象化を効率化し、サイドカーコンテナの Envoy プロキシは Service Connect プロキシ として AWS がフルマネージドに管理します。Service Connect の抽象化には「クライアント」と「サーバー」サービスが含まれます。「サーバー」サービスは、別のマイクロサービスと通信する場合、「クライアント」としても機能します。この場合、 「クライアント / サーバー」サービス と呼ばれます。AWS Cloud Map の名前空間は、サービスを検出し、リソースの論理的な境界を定義します。 次の図 3 は、Service Connect を利用するサンプルアプリケーションのアーキテクチャを示しています。フロントエンドアプリケーションは「クライアント」サービスになり、AWS Cloud Map 名前空間の一部になりますが、エンドポイントは公開されません。ユーザー API とストック API は、どちらも名前空間にアタッチされた「サーバー」サービスであり、「クライアント」が接続するためのエンドポイントを公開しています。 図 3: Service Connect を利用するサンプルアプリケーション App Mesh から Service Connect への移行 Amazon ECS サービスを、App Mesh の Mesh と Service Connect の名前空間の両方に同時に含めることはできません。したがって、移行を実行するには、Amazon ECS サービスを再作成する必要があります。このプロセス中のダウンタイムを回避するために、 Blue/Green 移行戦略 を実装できます。このアプローチでは、各 Amazon ECS サービスのコピーを作成し、2 つの環境間でトラフィックを徐々に移行します。Blue/Green 移行戦略でトラフィックをきめ細かく移行するには、 Amazon Route 53 加重ルーティング 、 Amazon CloudFront の継続的デプロイ 、 Application Load Balancer の加重ターゲットグループ など、いくつかの方法があります。 次の図 4 は、App Mesh から Service Connect へのアプリケーションの移行を示しています。エンドユーザーは Amazon Route 53 加重ルーティングを通じて、App Mesh 環境から Service Connect 環境へ徐々に移行されます。Service Connect は、アプリケーションレベルのネットワーキングメトリクスを無料の CloudWatch メトリクスとして提供します。この移行プロセスでは、Service Connect 環境に送信されるトラフィックの量を、 加重レコードの重みを調整 することで徐々に増加できます。Service Connect が提供するメトリクスを利用して、管理者は負荷の増加をモニタリングして設定の誤りを検出できます。 図 4: App Mesh を利用するアプリケーションから Service Connect を利用するアプリケーションへのトラフィック移行 各サービスメッシュの環境には個別のサービスディスカバリ実装があるため、サービスメッシュ環境をまたぐネットワーク通信はありません。エンドユーザーからの接続は、それぞれのサービスメッシュ内に残ります。たとえば、トラフィックが App Mesh を利用するフロントエンドに送信された場合、アクセスされるバックエンド API は App Mesh の Mesh に含まれるバックエンド API になります。App Mesh を利用するフロントエンドは、Service Connect 環境のバックエンドサービスとは通信できません。 機能の比較 Service Connect を利用すると、プロキシ管理や複数の抽象化レイヤーが不要になり、サービスメッシュの管理に伴うオーバーヘッドがなくなります。AWS は Service Connect に多くの投資を行っており、強力なロードマップを策定していますが、現時点では、すべての Envoy プロキシ機能が Service Connect で利用できるわけではありません。このセクションでは、Service Connect と App Mesh の機能の違いについて説明します。 ネットワークの信頼性の向上 : App Mesh と Service Connect はどちらも、Envoy の 外れ値検出 や リトライ を利用して、サービス間の信頼性を高めています。App Mesh ではこれらの設定を変更できますが、Service Connect では独自のデフォルトがあります。タイムアウトに関しては、Service Connect でも設定の変更が可能です。 高度なトラフィックルーティング : App Mesh では、仮想的なルーティングメカニズムを利用して、Virtual Router により複数の Virtual Node 間、すなわち複数のマイクロサービスのバージョン間でトラフィックをきめ細かくルーティングできます。Service Connect では、高度なトラフィックルーティングは利用できません。 オブザーバビリティ : App Mesh では、 トラフィックメトリクス を取得してモニタリングサービスに送信し、オブザーバビリティダッシュボードを構築する必要があります。Service Connect では、 アプリケーションレベルのネットワーキングメトリクス を無料の CloudWatch メトリクスとして提供します。これらのメトリクスは、 CloudWatch コンソール と Amazon ECS コンソール に表示されます。 セキュリティ : App Mesh と Service Connect はどちらも、サービス間の通信を暗号化するための TLS をサポートしています。App Mesh では、 AWS プライベート CA (AWS PCA) の GENERAL_PURPOSE モード の証明書を活用できます。一方で Service Connect では、簡単な設定で低コストな AWS PCA の SHORT_LIVED_CERTIFICATE モード の証明書を活用できます。また、App Mesh では 相互 TLS 認証 を実装できますが、Service Connect では相互 TLS 認証を利用することはできません。 リソースの共有 : AWS Resource Access Manager (AWS RAM) では、App Mesh の Mesh を複数の AWS アカウントで共有できます。これにより、Mesh という同じ論理的な境界に属しながら、アプリケーションを複数のアカウントに分散できます。Service Connect では、AWS Cloud Map 名前空間を複数の AWS アカウントで共有することはできません。そのため、現時点では、サービスメッシュに含まれる全てのアプリケーションを、同じ AWS アカウントにデプロイする必要があります。 まとめ 本投稿では、App Mesh から Amazon ECS Service Connect への移行について説明し、2 つのサービスの主な違いを説明しました。Service Connect が提供する効率的な抽象化とマネージドなネットワーキングデータプレーン、およびトラフィックルーティング、オブザーバビリティ、セキュリティ、リソース共有に関する考慮事項について説明しました。 App Mesh を利用しており、Service Connect への移行を検討している場合は、本投稿で紹介している Blue/Green 移行戦略をご検討ください。Service Connect の詳細については、 Amazon ECS ドキュメント と、 Amazon ECS Immersion Day ワークショップ をご確認ください。このワークショップでは、サンプルの 小売アプリケーション をデプロイして、サービスを実際に体験できます。 App Mesh を利用する Amazon Elastic Kubernetes Service (Amazon EKS) のお客様向けの移行ガイダンスについては、今後の AWS ブログをお待ちください。 翻訳はソリューションアーキテクトの落水が担当しました。原文は こちら です。

Background : 背景 現在、放送、ライブストリーミングそしてビデオ配信をオンプレミスの素材またはローカルネットワークの送信先に行うお客様には、ライブビデオワークフローを構築する際にさまざまな選択肢があります。これらのオプションにはすべてトレードオフがあり、オンプレミスとクラウドの両方でのハイブリッド展開が必要な場合に理想的なものはありません。 お客様は、アマゾンウェブサービス (AWS) から AWS Elemental Live などのオンプレミスのエンコーディングアプライアンスおよびソフトウェアを購入してデプロイできます。ただし、アプライアンスを維持し、ソフトウェアを最新の状態に保つための運用コストは、新機能の導入やビデオ品質の向上を妨げる可能性があります。お客様がオンプレミスとクラウドの両方のライブビデオワークフローをハイブリッドに導入している場合、管理と監視の複雑さは増すばかりです。また、クラウドへの移行を希望するお客様は、すでにデータセンターにハードウェアを導入しているか、長期リース契約を結んでいる場合があります。 多くのお客様が AWS Elemental MediaLive ( MediaLive ) のフルマネージド機能の使用を希望しますが、serial digital interface (SDI) などのビデオ素材はオンプレミスに固定されています。これを解決する 1 つの方法は、 AWS Elemental Link などのクラウド制御デバイスを使用することですが、これらのデバイスはマルチチャネル環境のニーズや、エンコード設定を正確に制御したい場合のニーズを満たさない可能性があります。また、お客様によっては、ローカルで管理されたコンテンツ配信ネットワーク (CDN) またはパッケージャーでのラストマイル配信のエンコーディングを必要とし、この処理のためにクラウドへのストリームの往復を行うと、不必要な複雑さとコストが増えます。 Introducing AWS Elemental MediaLive Anywhere : AWS Elemental MediaLive Anywhere のご紹介 AWS Elemental MediaLive Anywhere は MediaLive の機能で、管理にクラウドを利用しながら、オンプレミスでライブ動画エンコードを実行できます。その名の通り、MediaLive を使用してほぼどこからでも動画をエンコードできるようになりました。MediaLive Anywhere はお客様のハードウェアにデプロイされ、ビデオ処理はオンプレミスで実行され、構成、制御、監視、および管理タスクはクラウドで実行されます。MediaLive Anywhere を使用すると、ハイブリッドワークフローの運用を改善し、ビデオの転送を最小限に抑え、オンプレミスのビデオ素材と送信先に接続できます。 AWS Elemental の GM である Manish Rao 氏は次のように述べています。「ライブ動画素材をクラウドに移行できない場合、MediaLive Anywhere がクラウドをあなたの元に運んでくれます。動画素材や送信先がオンプレミスで固定されている場合や、引き続き使用したいコンピューティングリソースがある場合、MediaLive Anywhere は MediaLive と同じ優れた機能、API、監視ツール、コンソール、従量課金制の価格設定を提供して、あらゆる場所でのエンコーディングを可能にします。」 Streamline live video operations and simplify on-premises encoding : ライブビデオの運用効率化とオンプレミスのエンコーディングの簡素化 MediaLive Anywhere を使用すると、一貫性のある API、チャンネルプロファイル、ログ、およびメトリックを使用して、ハイブリッドまたはオンプレミスのビデオエンコーディングを管理できます。オンプレミスの場所が複数ある場合でも、全てのチャネルを 1 か所で設定、制御、監視できます。MediaLive Anywhere でチャンネルを開始するたびに、最新の機能やアップデートが提供されます。ソフトウェアアップデートを心配することなく、新しいコーデックやエンコーディング品質などの最新のビデオ処理機能を利用できます。 Netflix のライブ エンコーディング テクノロジーのシニア エンジニアリング マネージャーである Flavio Ribeiro 氏は以下のように述べています。「 AWS Elemental MediaLive Anywhere は、加入者にライブ動画を配信する方法を変革する能力を持っています。オンプレミスとクラウドのワークフロー間の一貫性のあるエクスペリエンス、自動化されたソフトウェアアップデート、統合サポートにより、新しいビデオワークロードをどこにでも簡単に展開して制御できるようになります。」 SDI などのオンプレミスに固定されたビデオ素材や、マネージド CDN やパッケージャーのようなローカルネットワークの送出先がある場合は、接続性が重要です。MediaLive Anywhere を使用すると、オンプレミスのビデオ素材をエンコードすることで複雑さを軽減できます。同様に、ライブビデオをローカルネットワークの宛先に送信する必要がある場合に、オーバーヘッドを削減し、クラウドへの不要なストリームの往復を回避できます。 TV 2 Danmark のライブテクノロジー担当スタッフエンジニア、Loke Dupont 氏は次のように述べています。「 MediaLive Anywhere は、オンプレミスとクラウドのライブエンコーディングの運用を大幅に簡素化します。クラウド内の単一ポイントからすべてを制御でき、ソフトウェアのアップグレードを自動的かつ透過的に行うことができるため、運用ではなくユーザーエクスペリエンスに集中する時間が得られます。」 Ease migration and improve streaming efficiency : 容易なマイグレーションとストリーミング効率の向上 特にライブ動画のワークフローがほとんどオンプレミスにある場合は、AWS Elemental Live アプライアンスとソフトウェアが依然として適切な選択である場合があります。AWS とこれらのアプライアンスを再販する AWS パートナーは、2024 年 4 月にリリースされた AWS Elemental Live L900 シリーズアプライアンスの新ラインナップを含め、お客様が自社のデータセンターで使用できる最も汎用性が高く、機能が充実した物理エンコーディングアプライアンスの提供に取り組んでいます。 オンプレミスとクラウドをハイブリッドに導入している場合は、MediaLive Anywhere の方が適しています。加えて、既存設備のリースの期限が切れるのを待っていたり、長期的な設備投資を行っていてクラウドへの移行が遅れたりすることがあります。MediaLive Anywhere は、オンプレミスハードウェアの管理からフルマネージドクラウドエンコーディングへの移行を容易にするように設計されています。ハードウェアによっては、データセンターに導入されたハードウェアをクラウド制御のエンコーダーとして再利用できます。既存の AWS Elemental Live L800 および L900 シリーズのアプライアンスをお持ちのお客様は、数ステップで MediaLive Anywhere に移行できます。 MediaLive Anywhere を使用し従量課金制に移行することで、リニアストリーミングの経済性も向上させることができます。運営しているチャンネルの料金だけを、実行する必要がある時間のみ支払うことで、24 時間 365 日のチャンネルやライブイベントをストリーミングする費用対効果を高めることができます。また、各ハードウェアデバイスで実行するチャネル数を柔軟に選択でき、十分に活用できない可能性のあるソフトウェアライセンスの購入に縛られることもありません。 PBS とその 330 を超える加盟局は、米国民に対する重要な使命を果たすため、商業放送とは一線を画した信頼できる番組を提供し、視聴者を単なる消費者ではなく市民として扱っています。MediaLive Anywhere により、PBS はローカル番組の取り込みと放送局のオンライン視聴者への配信を効率化すると同時に、リニアビデオストリームカタログ全体の運用管理をクラウドに統合できます。 Get started : MediaLive Anywhereを開始する AWS Elemental MediaLive Anywhere は、 AWS パートナー を通じて購入できる従量課金制のサービスとアプライアンスで構成されています。AWS では、お客様がすぐに利用できるよう、ハードウェアの組み立て、統合、テストを行うパートナーから MediaLive Anywhere のハードウェアを購入することを推奨しています。ハードウェアと AWS サービスの両方をパートナーを通じて購入することも、お客様の AWS アカウントを使用してサービスの支払いを行うこともできます。既存の AWS Elemental Live アプライアンスの変更や、代替ハードウェアのオプションを検討するには、 営業担当者 にお問い合わせください。 Bridge Digital Inc. の創設者兼 CEO である Richie Murray 氏は、「 MediaLive Anywhere の販売、統合、優先サポートを提供できることを嬉しく思います」と述べています。「 COTS ハードウェアと MediaLive を組み合わせることで、従量課金制のシーズンイベントに最適な堅牢なハイブリッドソリューションを実現します。AWS Elemental アプライアンスの販売経験が豊富なBridge Digital Inc. は、MediaLive Anywhere をお客様に提供できることを誇りに思っています。」 Insys Video Technologies の CEO、Krzysztof Bartkowski 氏は次のように述べています。「 Insys Video Technologies は、MediaLive Anywhere のローンチパートナーとしてハードウェアを提供し、お客様が Cloud Video Kit を通じてクラウドとオンプレミスのライブエンコーディングワークフローを管理できるようになることを嬉しく思います。当社のインテグレーションにより、お客様は複数のツールや個別のワークフローを実行する必要がなくなります。 drm.cloud サービスによるコンテンツ保護を含む単一のツールを使用して、最適なリソース使用量を選択するだけです。」 LOGIC media solutions GmbH のマネージングディレクターである Jens Gnad 氏は、次のように述べています。「当社のソフトウェア ポータル で AWS Elemental Live Anywhere を使用して AWS が導入した革新的なアプローチに貢献できることを光栄に思います。このハイブリッドソリューションは、クラウドへの移行を進めるお客様に当社が提供している推奨事項と完全に一致しています。ポータル は、アクセスが容易なブラウザベースのフロントエンドを提供しており、お客様のローカルインフラストラクチャ上で MediaLive Anywhere を導入、制御、監視できます。」 Now available : 今すぐご利用いただけます AWS Elemental MediaLive Anywhere は、AWS Elemental MediaLive が利用できるすべての AWS リージョン で利用できます。 詳細については、 AWS パートナーリセラーにお問い合わせ いただくか、AWS ドキュメントの MediaLive Anywhere ユーザーガイド をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はメディアエッジスペシャリストソリューションアーキテクトの長澤、加藤、メディアソリューションアーキテクトの金目が担当しました。原文は こちら をご覧ください。

Amazon SageMaker Data Wrangler には、機械学習 (ML) プロジェクトで最も時間と手間のかかる作業であることが多い機械学習のデータ準備を効率化および加速するためのビジュアルインターフェイスが用意されています。 Amazon SageMaker Canvas は、コードを書かなくても ML モデルを構築してデプロイできる、ローコードのビジュアルインターフェイスです。お客様からのフィードバックに基づいて、我々はSageMaker Data Wrangler の高度な ML 特有のデータ準備機能を SageMaker Canvas に統合しました。これにより、データの準備、 ML モデルの構築、デプロイのための、エンドツーエンドでコード不要のワークスペースがユーザーに提供されます。 SageMaker Canvasでは、MLワークフローの複雑な部分を抽象化することで、コードを記述しなくてもデータを準備し、モデルを構築または使用して、非常に正確なビジネスインサイトを生成できます。さらに、SageMaker Canvasでデータを準備すると、ページの読み込みが最大で10倍速くなり、データ準備のための自然言語インターフェイス、各ステップでデータのサイズと形式を表示する機能、データフローを繰り返し処理するために改善された 置換処理 や 順序変更 など、多くの拡張機能が提供されます。最後に、同じインターフェイスでワンクリックでモデルを作成することも、SageMaker Canvas データセットを作成して基礎モデル (FM) を微調整することもできます。 この投稿では、既存の SageMaker Data Wrangler flows (データ変換処理の一連の流れを定義したもの) を SageMaker Studio Classic から SageMaker Canvas に移行する方法 を示します。SageMaker Canvas にファイルをインポートする前の中間ステップとして、SageMaker Studio Classic から Amazon Simple Storage Service (Amazon S3) にファイルを移動する例を紹介します。 ソリューション概要 大まかな手順は次のとおりです。 SageMaker Studio でターミナルを開き、フローファイルを Amazon S3 にコピーします。 Amazon S3 から SageMaker Canvas にフローファイルをインポートします。 前提条件 この例では、フローファイルを Amazon S3 に移行するためのステージングフォルダとして data-wrangler-classic-flows というフォルダを使用します。移行フォルダを作成する必要はありませんが、この例では SageMaker Studio Classic のファイルシステムブラウザ部分を使用してフォルダが作成されています。フォルダーを作成したら、関連する SageMaker Data Wrangler フローファイルを慎重に移動して統合してください。次のスクリーンショットでは、左側のペインに表示されているように、移行に必要な 3 つのフローファイルが data-wrangler-classic-flows フォルダーに移動されています。これらのファイルの 1 つである titanic.flow が開き、右側のペインに表示されます。 フローファイルを Amazon S3 にコピーする フローファイルを Amazon S3 にコピーするには、次の手順を実行します。 SageMaker Studio Classic で新しいターミナルを開きます。「ファイル」メニューで「ターミナル」を選択します。 新しいターミナルを開いたら、次のコマンドを入力して、選択した Amazon S3 の場所にフローファイルをコピーします (NNNNNNNNN は AWS アカウント番号に置き換えてください)。 cd data-wrangler-classic-flows target="s3://sagemaker-us-west-2-NNNNNNNNNNNN/data-wrangler-classic-flows/" aws s3 sync . $target --exclude "*.*" --include "*.flow" 次のスクリーンショットは、Amazon S3 同期プロセスの例を示しています。すべてのファイルがアップロードされると、確認メッセージが表示されます。上記のコードは、お客様固有の入力フォルダと Amazon S3 ロケーションのニーズに合わせて調整できます。フォルダを作成したくない場合は、ターミナルに入るときにディレクトリ変更 (cd) コマンドをスキップするだけで、元のフォルダに関係なく、SageMaker Studio Classic ファイルシステム全体のすべてのフローファイルが Amazon S3 にコピーされます。 ファイルを Amazon S3 にアップロードしたら、Amazon S3 コンソールを使用してファイルがコピーされたことを確認できます。次のスクリーンショットでは、元の 3 つのフローファイルが S3 バケットに入っていることを確認しています。 Data Wrangler フローファイルを SageMaker Canvas にインポートする フローファイルを SageMaker Canvas にインポートするには、次の手順を実行します。 SageMaker Canvas アプリケーションのナビゲーションペインで「 Data Wrangler 」を選択します。 [ Import data flows ] を選択します。 [ Select a data source ] で [ Amazon S3 ] を選択します。 [ Input S3 endpoint ] に、先ほど SageMaker Studio から Amazon S3 にファイルをコピーするために使用した Amazon S3 ロケーションを入力し、[ Go ] を選択します。下のブラウザを使用して Amazon S3 ロケーションに移動することもできます。 インポートするフローファイルを選択し、[ Import ] を選択します。 ファイルをインポートすると、次のスクリーンショットに示すように、SageMaker Data Wrangler ページが更新され、新しくインポートされたファイルが表示されます。 SageMaker Canvas にて SageMaker Data Wrangler のデータ変換を使う いずれかのフロー (この例では titanic.flow を選択) を選択して SageMaker Data Wranglerのトランスフォーメーションを起動します。 現在ビジュアルインターフェイス ( Amazon SageMaker Canvas の ML データ準備を高速化 ) または自然言語インターフェイス ( Amazon SageMaker Canvas の新機能で自然言語を使用してデータを探索および準備する ) を使用して、データフローに分析と変換を追加できるようになりました。 データに問題がなければ、プラス記号を選択して [ Create model ] を選択するか、[ Export ] を選択して データセットをエクスポート して ML モデルを構築して使用します。   別の移行方法 このブログでは、Amazon S3 を使用して SageMaker Data Wrangler フローファイルを Amazon SageMaker Studio Classic 環境から移行する方法についてのガイダンスを提供しました。 AWS ドキュメント には、Data Wrangler フローファイルをインポートする他の方法が記載されています。Studio Classic と Canvas アプリケーションが同じ Amazon EFS ストレージボリュームを共有している場合、データフローを Studio Classic の Data Wrangler から SageMaker Canvas の Data Wrangler に移行するためのワンクリックインポートオプションが表示されます。 または、ローカルマシンを使用してフローファイルを転送することもできます。最後に、SageMaker Studio ツリーコントロールからローカルマシンに単一のフローファイルをダウンロードし、Canvas に手動でインポートすることもできます。正解も不正解もありません。使い慣れた方法を自由に選択してください。 Clean up 移行作業が完了したら、SageMaker Studio Classic で実行中の SageMaker Data Wrangler アプリケーションをすべてシャットダウン します。コストを節約するために、 Amazon Elastic File System (Amazon EFS) ボリュームである SageMaker Studio Classic ファイルブラウザからすべてのフローファイルを削除することもできます。Amazon S3 の中間ファイルはどれでも削除できます。フローファイルが SageMaker Canvas にインポートされると、Amazon S3 にコピーされたファイルは不要になります。 完了したら SageMaker Canvas からログアウトし、再び使用する準備ができたら再起動できます。   まとめ 既存の SageMaker Data Wrangler flows を SageMaker Canvas に移行するのは簡単です。これにより、SageMaker Canvas のエンドツーエンドでコード不要の機械学習ワークフローを活用しながら、すでに開発したデータ準備のフローを使用できます。この記事で解説した手順に従うことで、データセットを変換する処理を SageMaker Canvas 環境にシームレスに移行できます。これにより、MLプロジェクトが合理化され、ビジネスアナリストや技術者以外のユーザーがより効率的にモデルを構築してデプロイできるようになります。 今すぐ SageMaker Canvas の活用を始めて、データ準備、モデル構築、デプロイのための統合プラットフォームの力を体験してください！ 著者について Charles Laughlin は、アマゾンウェブサービス（AWS）の主任AIスペシャリストです。Charles はサプライチェーン管理の修士号とデータサイエンスの博士号を取得しています。Charles は Amazon SageMaker サービスチームで働いており、リサーチやお客様の声をサービスロードマップの参考にしています。仕事では毎日、さまざまな AWS のお客様と協力して、最先端の AWS テクノロジーとソートリーダーシップでお客様のビジネスの変革を支援しています。   Dan Sinnreich は Amazon SageMaker のシニアプロダクトマネージャーで、ノーコード/ローコードサービスの拡大に注力しています。彼は ML とジェネレーティブ AI をより身近なものにし、それらを応用して困難な問題を解決することに専念しています。仕事以外では、ホッケー、スキューバダイビング、サイエンスフィクションを読んだりしています。   Huong Nguyen は AWS のシニアプロダクトマネージャーです。SageMaker Canvas と SageMaker データラングラーの機械学習データ準備を率いており、15 年にわたり顧客中心のデータ主導型の製品を構築してきた経験があります。   Davide Gallitelli は、EMEA地域のAI/MLのスペシャリストソリューションアーキテクトです。ブリュッセルを拠点とし、ベネルクス全域のお客様と緊密に連携しています。彼は幼い頃からデベロッパーとして活躍し、7 歳でコーディングを始めました。彼は大学卒業後にAI/MLを学び始め、それ以来ずっとAI/MLに夢中になっています。   翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です

はじめに みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 2024年9月5日に「 AI 時代に技術を活かす！人材と組織、そして活用プロセス構築のポイントを解説！ ～進化し続ける技術を活用するために効果的な組織と人材育成のあり方、そしてそれらを導入する際の課題と対策について学ぶ～ 」を開催しました。 このブログでは、当日参加できなかった方や、参加したけれども内容を振り返りたい方に向けて、ご自身の取り組みの参考としていただくために当日のセッション内容のまとめを紹介します。 セッション内容の紹介 ビジネスを加速させる組織（xCoE）にこれから求められること – 河口 由美子、アマゾン ウェブ サービス ジャパン合同会社 AWS プロフェッショナルサービス本部 プラクティスマネージャー CS&O Advisory – 山泉 亘、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージメント統括本部 シニアカスタマーソリューションマネージャー 本セッションでは、最新の CCoE ストラクチャーの解説を通じて、CCoE が単なるクラウド技術の適用だけではなくビジネスを加速させるため必要であること、サーバント・リーダーシップとも呼ばれる行動特性、そして CCoE にこれから求められることを紹介しました。加えて、AI CoE を例に他専門領域における xCoE の考え方を紹介しました。 エンタープライズのお客様でクラウドを効果的に推進するためには、CCoE（もしくは、クラウドに限定しない xCoE）の立ち上げが必要だという認識は既に多くの方々が持たれていると思います。一方で、そのストラクチャーは汎化が困難であり、他社事例の流用が必ずしも最短経路ではないという認識を持つお客さまもいらっしゃいます。その存在意義や、効果的な立ち振る舞いはどこにあるのか、各社にとって効果的な CCoE はどうやって定義するのかに悩む方々は少なくありません。 本セッションで紹介した本質的な行動特性や考え方は、組織の成長を考え続けるチームである限り変わることがありません。それが、CCoE であっても xCoE であっても、はたまた「CoE」という単語を組織名称に使っているかに関わらず、変わることがありません。技術発展の著しい世の中にあって、その変化を受け入れ、順応し、活用しようとする組織的なメカニズムをぜひ追求してください。 AWSではクラウドであってもAIであっても強化すべきCapabilityを定義しており、これらはテクノロジーの導入をどうビジネス成果に結びつけていくか、ジャーニーのガイド役となります。推進のやり方に悩まれたり、相談する先が必要なときには、ぜひAWSへご相談ください。 参考リンク： 今から始める CCoE、3 つの環境条件と 3 つの心構えとは AI/ML CoE (Center of Excellence) の設立 その他、CCoE に関連するブログ記事（今後随時追加） 資料のダウンロードは こちら から 知識だけでは不足する？！実践力と経験値を磨く体験型学習イベントのすゝめ – 鈴木 宏昌、アマゾン ウェブ サービス ジャパン合同会社 トレーニングサービス本部 シニアラーニングコンサルタント 本セッションではDX推進する際に「クラウドスキル人材育成のために研修を提供したのに、実践力が足りなくて活躍できない」という課題に対して、研修と実践のギャップ構造を埋めるための体験型学習メソッドをご紹介しました。組織横断でクラウド推進を担っているCCoEや、ペーパードライバーではなくプロジェクトに寄与する人材育成方法を模索されるリーダーの皆様に、「なにを学べばよいか」ではなく「成果に繋げるためには、どうやって学べばよいか」という具体的な方法論を持ち帰っていただけたと思います。 ビッグデータ、IoT、コンテナ、サーバレス、生成AIなど様々な技術が次々に生まれ、新たな技術やスキルを使える人材のニーズは日々大きくなっています。そして、それらを学ぶための研修コンテンツも多くの選択肢がありますが、教科書的なInputに終始するため実際のプロジェクトで遭遇するようなシチュエーションや課題を学ぶ機会がありません。そのため現場に入っても時間をかけながら失敗しにくい環境で教科書的な知識を少しづつアップデートするしかないのです。これが「習熟の空白地帯」の正体であり、失敗しにくいからこそ責任範囲を広げにくく、結果としてペーパードライバー化します。 AWS Jamを用いた体験型学習はAWSに関する「習熟の空白地帯」を解消できる１つの方法論です。様々なお客様の現場で発生したトラブル、インシデントや、シチュエーションに応じたベストプラクティスやソリューションを「手順のないハンズオン」として数百ものシナリオにしています。つまり、Inputされた教科書的な知識を使ってAWS Jamのシナリオ解くことで、失敗できる環境のなかで実践味のあるシチュエーションで自分のスキルを試すことができるのです。手順がないハンズオンのため、状況の把握・解決策の調査・仮説検証を繰り返すことになり、知識だけではなく課題解決能力が求められます。さらに、AWS Jamを経て気付いた知識不足や新たな知見を調査・復習してチームにプレゼンテーションすることで、浅い気付きから詳細な理解へ知見を深めつつチーム全体の底上げを行うことができます。 体験型学習の方法論とサイクルはAWS以外の技術にも応用ができます。ぜひ、みなさまの現場でお試しください。 参考リンク： AWS Jam AWS Skill Builder AWS 初学者向けの勉強方法 6 ステップ！2024 年版！ 資料のダウンロードは こちら から AWSへの大規模移行を包括的にご支援 ～ITトランスフォーメーションパッケージの全貌～ – 今井 宏樹、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター統括本部 マイグレーションアドバイザー 本セッションでは、クラウドジャーニーにおけるお客様の課題や懸念を題材に、技術的観点、セキュリティやシステム運用にフォーカスをしがちな移行プロジェクトを、最も重要な要素である「人(People)」「プロセス(Process) 」に向けてどのようにフォーカスするべきか、AWSからのご支援を提供できる包括的支援パッケージ、 IT トランスフォーメーションパッケージ（ITX）と共にご紹介いたしました。 お客様がオンプレミス環境等からクラウドへ移行をご検討される際、AWSの専門チームがお客様へのコンサルティングに利用するフレームワークであるCloud Adoption Framework（CAF）にお客様課題を当てはめた場合、技術的観点の課題が全体の30％程度、各組織毎に状況が異なり主体的に解決が必要である人やプロセスなどの非技術的観点の課題が70％を占めておりました。お客様が最終的なITシステムの稼働を目標にするあまり、どうしても技術的観点から移行プロジェクトの推進（クラウド移行）にフォーカスしてしまいますが、実際はクラウド移行を順調に進める事が出来ているプロジェクトというのは、移行検討、プロジェクトの立上げという前段のステップを確実に実施されているという結果が出ています。そのためAWSでは、このクラウドジャーニーを評価（Assess）・準備（Mobilize）・移行（Migration & Modernization）の「3つのフェーズ」で捉え、それぞれのフェーズでお客様課題に対応する形で必要な支援策をご用意したものがITXになります。 AWSはお客様の移行プロジェクトを成功に導くために、ITXの活用を推奨しています。移行検討のステップ、評価のフェーズでは、オンプレミス環境の経済的現状評価と分析、またクラウド化した場合の経済的評価へのご支援策であるクラウドエコノミクスを利用し、TCO観点の評価を実施するだけではなく、ITに関わる労働生産性の改善やビジネス影響の重要性の評価をきっかけにしたクラウド移行への決断へ繋げる事を推奨しています。またそこからプロジェクトの立上げのステップを視野に入れ、準備フェーズではCAFを利用した組織全体としてのクラウド準備状況評価であるマイグレーションレディネスアセスメントを活用し、組織的な課題、特に人やプロセスの課題を明確にいたします。更にそこから、クラウド推進組織であるCCoE立ち上げ・運用をAWSがご支援する事で、実際のクラウド移行のプロジェクトを成功に導く事ができると考えております。 ITXをご活用頂く事で、クラウドジャーニーにおいてお客様の現状を分析、より重要な人・プロセスに関した課題解決にフォーカスする形で、AWSはお客様のAWSはお客様のクラウドジャーニーを成功へ向けて伴走いたします。 参考リンク： AWS ITトランスフォーメーションパッケージ ファミリー（ITX） クラウド移行を成功させるための設計：5つの落とし穴と停滞の防ぎ方 クラウドジャーニーの歩み方 資料のダウンロードは こちら から おわりに AWSへの大規模なシステムの移行をサポートするITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。これから小林と共に週刊生成AI with AWS を書いていきます。よろしくお願いします！ 「 AWS Innovate 」 が今週の木曜 (9 月 26 日) にオンラインで開催されます。 ”Migrate. Modernize. Build.” をテーマに、生成AI 活用を含むモダナイゼーションの実践方法を学ぶイベントとなっています。インフラ、アプリ、データの各領域で、どう生成AI を活用してモダナイズするかを、エキスパートが分かりやすく解説するセッションを用意しています。ぜひ奮ってご参加ください。 引き続き「 AWSジャパン生成AI実用化推進プログラム 」も募集中です。こちらの方もよろしくお願いいたします。 それでは、9 月 16 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ゼネット様、Amazon Bedrock を活用した e ラーニング向け AI 自動回答システムで講師の工数を削減 株式会社ゼネット様は、 e ラーニング学習用コンテンツ登録プラットフォーム「 Xlabo 」を提供しています。多くの受講生が利用する一方で、受講生からの質問対応やソースコードレビュー対応に講師の時間の半分が取られる、繁忙期には講師の順番待ちで受講生の満足度が低下する、といった課題を抱えていました。そこで、Amazon Bedrock の Claude 3.5 Sonnet を活用した、自動質問回答機能と自動ソースコードレビュー機能を実装しました。Claude 3.5 Sonnet 採用の決め手は、受講生が添付する画像の文字抽出能力とコード理解力の高さでした。システムが24 時間 365 日高い精度で質疑応答できるようになった結果、講師陣が研修の実習時間中に行うサポート工数が半分以下に削減され、受講生の学習効率が大幅に向上するといった効果を得られています。 ブログ記事「RAG の精度を向上させる Advanced RAG on AWS の道標」を公開 RAG (検索拡張生成) は、より高い精度の回答やより高度な応用を実現しようとすると、追加の工夫が必要になるケースがあります。この記事では、RAG を拡張する Advanced RAG の様々な手法や AWS での実装方法を紹介しています。Advanced RAG の各手法の難易度にも触れていますので、RAG の改善を目指している方は是非この記事を道標として参考にされてはいかがでしょうか。 サービスアップデート Amazon Q generative SQL for Amazon Redshift の一般提供を開始 Amazon Redshift では、Redshift Query Editor V2 というウェブベースの Query Editor 機能が提供されています。Amazon Q generative SQL for Amazon Redshift は、Redshift Query Editor V2 上で自然言語で質問を入力すると、生成AI によって推奨の SQLコードが生成される機能です。クエリの作成が簡単になり、生産性向上が期待できます。昨年11月にプレビュー版が出ていましたが、今回一般提供開始となりました。東京リージョンでもご利用いただけます。 AWS Chatbot で、Microsoft Teams と Slack から Amazon Bedrock Agents にアクセスが可能に AWS Chatbot は、Microsoft Teams や Slack を通じた AWS リソースの操作や、これらのチャットツールへの通知転送を実現する ChatOps サービスです。今回、AWS Chatbot を利用して、 Microsoft Teams や Slack のチャットから Bedrock Agents を直接呼び出すことができるようになりました。これまでチャットツールと Bedrock Agents の統合には独自実装が必要でしたが、AWS Chatbot と Bedrock Agents の接続設定のみで統合が可能になっています。 AWS Neuron が、Neuron Kernel Interface（NKI）、NxD Training、JAXサポートをトレーニング向けに導入 AWS Neuron は、生成AI に特化して構築された AWS Inferentia と Trainium インスタンス用の SDK です。このリリースでは、AWS Neuron に Neuron Kernel Interface (NKI) (ベータ版) が導入され、開発者は最適化されたコンピュートカーネルを独自に構築できるようになりました。また、効率的な分散トレーニングを可能にするライブラリである NxD Training と JAX フレームワーク (共にベータ版) も導入されています。詳細については Neuronリリースノート をご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 今週木曜(9/26)は AWS Innovate がオンラインで開催されます。テーマは、”Migrate. Modernize. Build.”で、多くの事例セッション、AWS サービスを利用したモダナイズ手法、生成AIを含む最新のテクノロジー等を学ぶことができます。ご興味ある方はぜひ以下を参照してください。 – AWS Innovate – 2024 年 9 月 26 日 (木) オンライン開催 それでは、先週の主なアップデートについて振り返っていきましょう。この週もかなり発表が多かったため、説明はできるだけシンプルにしています。詳細は原文のWhat’s newや説明中に記載したリンク等を参照してください。 2024年9月16日週の主要なアップデート 9/16(月) Announcing general availability (GA) of Amazon Q generative SQL for Amazon Redshift – AWS Amazon Redshift Query Editor v2 で Amazon Q による生成AIアシスト機能が一般提供開始（GA）になりました。自然言語で表現した内容からSQLを生成させるなど、クエリ作成時にアシストを受けることが可能になっています。 9/17(火) AWS Chatbot now allows you to interact with Amazon Bedrock agents from Microsoft Teams and Slack – AWS AWS Chatbot で Slack および Microsoft Teams のチャネルから Amazon Bedrock Agent とやり取りする機能が追加されました。これまではこういったカスタムチャットの実現にはLambda等で連携コードを作成する必要があったのですが、この機能によりコーディングなしでSlackやTeamsのチャネルからBedrockエージェントを呼び出す仕組みを構築することが可能になります。 AWS Amplify now supports long-running tasks with asynchronous server-side function calls – AWS AWS Amplify は、AWS AppSync API からの非同期の AWS Lambda 呼び出しをサポートするようになりました。この機能により、APIはクライアントへの応答をブロックすることなく、より複雑で長時間実行されるプロセス（長い実行時間を要するGraphQLクエリ等）を処理することが可能です。 AWS Transfer Family increases throughput and file sizes supported by SFTP connectors – AWS AWS Transfer Family で SFTP コネクタが改善され、サポートされる最大ファイルサイズは 150 GB 、最大スループットは 100 Files/秒に増加しました。Transfer for SFTPの機能については、 こちらのドキュメント 、もしくは こちらのハンズオン 資料をご確認ください。 Amazon Keyspaces (for Apache Cassandra) now supports add-column for multi-Region tables – AWS Amazon Keyspaces (for Apache Cassandra) に、既存のマルチリージョンテーブルに列を追加する機能が追加されました。レプリカリージョンの1つでマルチリージョンテーブルのスキーマを変更するだけで、テーブルが存在する他のリージョンにもレプリケーションされます。Amazon Keyspaces (for Apache Cassandra) はサーバーレスで提供される Apache Cassandra 互換データベースサービスです。 Announcing general availability of AWS SDK for Swift – AWS AWS SDK for Swift の一般提供開始（GA）が発表されました。AWS SDK for Swift は、Apple プラットフォーム、AWS Lambda、および Linux ベースの Swift on Server アプリケーションからAWSにアクセスするための、モダンで使いやすいネイティブ Swift インターフェイスを提供するSDKです。詳細は こちらのブログ をご覧ください。 AWS CodeBuild now supports managed GitLab runners – AWS AWS CodeBuild で、 Managed GitLab self-hosted runner がサポートされました。GitLabの CI/CD ジョブイベントを(Webhook経由で)受信したことをトリガーに CodeBuild で一時的にホストして実行するようプロジェクトを構成できます。詳細は こちらのドキュメント をご覧ください。 Amazon S3 Express One Zone now supports AWS-KMS with customer managed keys – AWS Amazon S3 Express One Zone で、AWS Key Management Service による、ユーザー管理するキーを使用したサーバーサイド暗号化 (SSE-KMS) がサポートされました。デフォルトでは、S3 Express One Zone は S3 Managed Key (SSE-S3) を使用してすべてのオブジェクトをサーバーサイドで暗号化しています。詳細は こちらのブログ をご覧ください。 9/18(水) Amazon Corretto 23 is now generally available – AWS AWS が提供する、無料で商用利用可能な OpenJDK ディストリビューション、 Amazon Corretto 23 が利用可能になりました。 こちらのページからダウンロード可能 です。Corretto 23 のサポート期間は2025年4月までです（LTSではありません）。 Amazon OpenSearch Service now supports i4g and i4i instances – AWS Amazon OpenSearch Service で、i4g (Gravitonベース) と i4i (INTELベース）のインスタンスが選択可能になりました。それぞれの特徴はこちらのブログをご覧ください（ EC2 I4g 、 EC2 I4i ) 。東京・大阪を含む多くのリージョンで利用可能です。 Introducing Amazon EC2 X8g Instances – AWS Amazon EC2 X8g インスタンスが一般提供開始（GA）になりました。現在、 US East (N. Virginia)、 US West (Oregon)、 Europe (Frankfurt)リージョンで利用可能です。X8g は AWS Graviton4 プロセッサを搭載しており、前世代の X2gd インスタンスと比較して、最大3倍のvCPU数(48vCPU)、最大3倍のメモリ(3TiB)を搭載可能であり、最大60%高いパフォーマンスを提供します。詳細は こちらのホームページ をご覧ください。 9/19(木) AWS Database Migration Service now includes enhanced monitoring – AWS AWS Database Migration Service (AWS DMS) に Enhanced Monitoring Dashbord が追加されました。これにより、複数の DMS タスクの全体、およびカスタマイズされたメトリックを監視したり、特定のレプリケーションインスタンス上のタスクの使用率を視覚化する等、問題の根本原因を特定しやすくなります。本機能は AWS DMS が利用可能なすべての AWS リージョンで利用可能になっています。詳細は こちらのドキュメント をご覧ください。 Amazon SES now offers automated complaint rate recommendations – AWS Amazon Simple Email Service (SES) に Virtual Deliverability Manager (VDM) Advisor が追加されました。VDM Advisor は、メールのcomplaint rate (苦情率)がベストプラクティスで許容されるレベルに近づいたり、それを超えたりした場合にアドバイスを提供するものです。詳細は こちらのドキュメント をご覧ください。 Amazon RDS Performance Insights supports Aurora cluster-level configuration – AWS Amazon RDS Performance Insights が Aurora クラスターレベルでの設定をサポートするようになりました。これにより簡単な操作もしくはAPIコールで Aurora クラスター内のすべてのインスタンスにパフォーマンスインサイトまたは拡張モニタリングを設定できます。 9/20(金) AWS CloudFormation Git sync now supports pull request workflows to review your stack changes – AWS AWS CloudFormation Git sync で、CloudFormation に変更をデプロイする前に、プルリクエストコメントを使用してスタックの変更を確認できるようになりました。CloudFormation は Git リポジトリを監視し、デプロイファイルの変更を検出するたびに、変更セットのデプロイをトリガーします。今回の新機能でこの際に PR レビューが出来るようになり、望ましくない変更を検出しやすくなります。詳細は こちらのドキュメント もしくは ブログ をご覧ください。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

この投稿は、IMSA (International Motor Sports Association) のシステムテクノロジーシニアディレクターである David McSpadden と共同で執筆されました。 図 1: デイトナ 24 時間レースに出場した 10 台の GTP クラスの 1 台 はじめに モータースポーツの世界では、トラック上での車のスピードに合わせてデータも追従する必要があります。IMSA (国際モータースポーツ協会) は、AWS と協力してファンにリアルタイムで車両テレメトリを提供しました。 北米で最高の権威をもつスポーツカーレース団体である IMSA のレースは、4 つの車両クラスが同時にコース走行するという独自の特徴があります。フェラーリ、ランボルギーニ、ポルシェなど多くのメーカーが並走し、最長で 24 時間に及ぶレースで競います。Grand Touring Daytona (GTD) および GTD PRO クラスは一般道を走る車両が選ばれますが、Le Mans Prototype 2 (LMP2) と Grand Touring Prototype (GTP) クラスは最高速度を実現するためのハイパーカーデザインが採用されています。本記事では新たに設けられた GTP クラスの車両、テレメトリ、そして IMSA や AWS がリアルタイムデータを配信する仕組みについて説明します。 GTP クラスの車両 – 自動車の限界を押し広げる GTP クラスの車両は 2023 年に IMSA に導入されました (図 1)。最新のクラスで、ハイブリッドパワートレインを特徴としています。これは従来型の内燃機関 (ICE) と電気モーターとバッテリーの組み合わせです。GTP クラスの車両はグリッド上で最速で、ピットではエンジンの音はなく電気モーターで無音で発進し、ピットロードを進んだ先で内燃機関がバンプスタートし轟音を上げます。この電気駆動からガソリンエンジン始動への移行が、レースファンにとって独特で満足感のある音の調べを生み出します。 毎シーズン、WeatherTech スポーツカー選手権は、最大レースのひとつであるロレックス 24 時間デイトナレース (24 時間のマルチクラスレース) (図 2) から始まります。このロレックス 24 時間レースはマシンとチームの耐久性を試し、限界に挑みます。GTP クラスのハイブリッドシステムの導入により、新しい戦略的課題が生じ、生データへのより速いアクセスが必要となりました。そうです、トラック上の車の速さがが目を引くかもしれませんが、その車から送られるデータの方がさらに速いのです。 図 2: Porsche Penske #7 GTP マシン。2024 年ロレックス デイトナ 24 時間レースの GTP クラスで優勝 ソリューションの概要 テレメトリデータの取得の第一歩は、ソースからです。GTP クラスの車両には 180 を超えるセンサーが装備されており、車両のパフォーマンスのあらゆる側面をカバーするデータを収集しています。これには、エンジン回転数、ハイブリッド車の残り電力、車速、トランスミッションギアなどの指標が含まれます。このデータは、4G LTE 無線モデムを使ってリアルタイムで Amazon Kinesis Data Streams に送信されます (図 3)。 図 3: IMSA レーシングライブテレメトリアーキテクチャ Kinesis Data Streams は、高可用性でフルマネージドの、データ量に応じてスケーリングするサーバーレスのストリーミングデータサービスです。 この場合、データプロデューサーである GTP クラス車両からのデータ量にも対応できます。車両からのテレメトリデータは AWS Fargate 上で実行されるアプリケーションによって Data Stream から取り出されます。Fargate はサーバーレスコンピューティングエンジンで、コンテナイメージをコンピューティングインフラストラクチャを管理する必要なく、スケーリング可能です。 この構成では、Fargate がインバウンドのデータレコードを解析、処理、および補強するためのアプリケーションロジックを提供します。結果として得られるのは、テレメトリデータだけでなく、タイミング、スコア、エントリデータを含む、単一の使いやすいデータストリームです。この処理が完了すると、 AWS AppSync を利用して、データストリームをすべてのコンシューマに向けてファンアウトします。 AWS AppSync は、サーバーレスの GraphQL と Pub/Sub API で、アプリケーションはリアルタイムでデータを照会、更新、発行できます。AWS AppSync は、以前にテレメトリデータを補強した Fargate アプリケーションから更新を受け取ります。加えて、AWS AppSync は、車/レースの過去のメトリクスをいくつか Amazon DynamoDB テーブルに保存します。DynamoDB テーブルには、各周回のリーダーボードのポイントインタイムスナップショットなど、過去のチェックポイントが保管されています。これはライブダッシュボードを補完します。 最後に、Angular アプリケーションは AWS AppSync からアップデートを購読し、ファンがサーキットからでも世界中のどこからでも、リアルタイムでデータを閲覧できるようにします。このウェブページとコードは、 Amazon Simple Storage Service (Amazon S3) バケットにホスティングされ、 Amazon CloudFront でフロントエンドが構成されています。これにより、ダッシュボードページを堅牢で高い可用性を持った静的ウェブホスティングで提供でき、アプリの利用者を数万人単位までスケールすることができます。さらに、Amazon CloudFront がユーザからアプリケーションバックエンドまでの全体的な地理的パスを短縮することで、ライブダッシュボードの待ち時間を削減します。静的サイトが CloudFront ディストリビューションを通して提供されるだけでなく、AWS AppSync API も別の管理された CloudFront ディストリビューションを通して提供され同じ利点を活用します。 車からファンへのデータの流れ全体は 1 秒以内で完了します。ロレックス 24 時間レースでは、650 万件のメッセージが正常に処理され、配信されました。その結果、車のパフォーマンスを把握でき、またファンとのエンゲージメントを深めることができました。 図 4: ロレックス 24 時間レースの観客席から見た、モバイルデバイス上のテレメトリダッシュボード 図 4 はデイトナ国際スピードウェイでモバイル端末に表示されているダッシュボードの実際の様子です。LTE 接続を介して、1秒未満のレイテンシーでファンにリアルタイムの車両テレメトリデータが提供されていました。これにより、レースに非常に没入できるファン体験が提供されました。サイドラインに立つファンは、アプリを使ってリアルタイムでピットストップを監視し、エネルギーの補給状況、タイヤ交換の指示、車両のジャッキアップ状況を確認できました。 図 5: ロレックス 24 で Web ブラウザで表示されたライブテレメトリダッシュボード 会場外の観客は、IMSA.com を訪れると同様の画面を見ることができました (図 5)。今年の ロレックス 24 時間レースでは、このダッシュボードに対する反応は非常に良好でした。レース開始直後にこのアプリケーションが一般に公開されると、数時間のうちにテレメトリダッシュボードには 11,500 人のユニークユーザーから 28,000 件を超えるページビューがありました。レース中に 106 カ国からユーザーがデータを確認したことで、IMSA の国際的な広がりを裏付けることができました。 テレメトリダッシュボードはテレビやラジオの放送室でも大好評でした。リリース直後から、放送スタッフがテレメトリのストリームを分析し、実況に取り入れ始めました。 このようにリアルタイムでデータを利用できると、世界中のレーシングファンに対してより詳しい状況説明ができ、すでにスリリングなストーリーラインに一層の彩りを添えることができます。ロレックス 24 時間レースでデビューして以来、IMSA のレース中継に定着しています。 今後の展望 IMSA と AWS がともに取り組んだ結果、構想から実現まで 4 か月足らずで完了しました。これにより、AWS サービスと既存のワークフローがお互いにいかに簡単に補完し合えるかが証明されました。AWS AppSync と Kinesis Data Streams を活用したこのようなアーキテクチャは、他のスポーツリーグでも簡単に取り入れられ、チームとファンにできるだけ早くデータを届けられるようになるでしょう。2024 年シーズンが進むにつれて、このソリューションのさらなる更新とアップグレードが予想されます。追加のデータソースからの情報や、サステナビリティに関するより深い分析が期待できます。お楽しみに! 本記事は「 Enduring Race Pace: How IMSA delivers real-time GTP telemetry to the fans 」を翻訳したものです。 著者について Ryan Kiel Ryan Kiel is a Senior Solutions Architect for AWS based out of Virginia. As part of AWS Sports, he helps leagues and franchises with their cloud journey on AWS by leveraging best practices and the newest technology. Outside of work, Ryan is a hockey, golf, and motorsports enthusiast. Carlos Valdes Carlos is a Senior Technical Account Manager for AWS based out of Florida. As part of AWS Enterprise Support, he is a technical advocate for his customers, helping to enable them in their cloud journey and accelerate their outcomes. Edmund Chute Edmund is a Specialist Solutions Architect for AWS based in San Francisco, California. As a member of the AWS Worldwide Specialist Organization ’ s Solution Builders team, he collaborates closely with customers to drive innovation through rapid prototyping development. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

Amazon Web Services (AWS) 上で実行されるお客様のアプリケーションでは、個人を特定できる情報 (PII) や保護された健康情報 (PHI) などの機密データを扱う必要がある場合があります。その結果、機密ログデータがアプリケーションの Observability データの一部として意図的または意図せずに記録される可能性があります。包括的なログ記録はアプリケーションのトラブルシューティング、モニタリング、(原因)分析に重要ですが、記録された機密情報はデータセキュリティとコンプライアンスの観点から重大なリスクとなります。 高度に規制された業界の顧客は通常、GDPR、CCPA、HIPAA、SOX、GLBA、PCI DSS、ISO/IEC 27001、SEC サイバーセキュリティガイダンス、州のプライバシー法、FTC 消費者保護法など、多数の厳格なデータ保護規制を遵守する必要があります。データ漏えいや非準拠は、莫大な罰金、訴訟、評判の失墜、事業の中断、システムのダウンタイム、顧客離れにつながる可能性があります。 このブログでは、 Amazon CloudWatch Logs Data Protection を使用してログ内の機密データを検出および保護する方法、データ保護を検証する方法、非準拠の結果を収集および報告する方法を学びます。また、 Amazon CloudWatch アラーム 、通知、さらなる是正アクションを作成する方法についても学び、コンプライアンス要件を満たすために活用できます。 ソリューションの概要 Amazon CloudWatch Logs には、ログ記録されるデータから機密情報を自動的にマスクする CloudWatch Logs Data Protection があります。有効にすると、パターンマッチングと機械学習(ML)ベースのマスクが適用され、クレジットカード番号、社会保障番号などの機密データ種別が「*(アスタリスク)」で置き換えられます。現在、すぐに利用できる多くの マネージドデータ識別子 があり、簡単に、そして大規模に適用できます。さらに、CloudWatch Logs Data Protection では、ビジネスの特定のニーズに合わせて カスタムデータ識別子 を定義する機能もあります。マネージドデータ識別子は、資格情報、金融情報、PII（個人を特定できる情報）、PHI（保護された医療情報）、デバイス識別子を検出できます。この機能は、より細かい制御のためにロググループレベルで有効にしたり、アカウント内のすべてのログに大規模に適用するためにアカウントレベルで有効にしたりできます。 CloudWatch Logs Data Protection を有効にすると、データ保護規制に関する顧客のコンプライアンス要件を次の 3 つの重要な点で満たすのに役立ちます。 機密顧客データは、ロギングシステムに到達する前に匿名化されます。これにより、プレーンテキストデータの漏洩や不正アクセスのリスクを軽減し、以下の機密データを保護することができます。 社内の一般従業員で機密情報を閲覧する権限のない者(内部の脅威に備えるため、信頼できるアクセスのみを許可する考え方に沿った対応) ベンダーやサードパーティシステムが所有するダウンストリームシステム マスキングにより、コンプライアンス監査が簡素化されます。ログには機密データが保護されていることが証明され、元の値をマスキングせずに保存・保護する必要はありません。 マスクは一度定義すれば、簡単にスケールして適用できます。 実現 CloudWatch Logs で データ保護ポリシー を作成する際、アカウントレベルまたは特定のロググループレベルで作成できます。アカウントレベルのデータ保護ポリシーは、アカウント内のすべての既存および将来のロググループに適用されますが、ロググループレベルのデータ保護ポリシーは特定のロググループにのみ適用されます。アカウントレベルとロググループレベルのログデータ保護ポリシーは組み合わせて機能し、特定のユースケースのデータ識別子をサポートします。 CloudWatch Logs Data Protection をロググループレベルで有効化 ビジネスニーズやアプリケーションの設計方法によっては、より詳細な制御のためにロググループレベルでデータ保護を有効にしたい場合があります。 CloudWatch コンソール を開き、Logs > Log Groups 画面に移動します。 対象のロググループを選択し、メニューまたは「データ保護」タブから、データ保護ポリシーを作成します。 図 1. CloudWatch コンソールでデータ保護ポリシーを作成する ビジネスニーズに応じて、マネージドデータ識別子（例えば顧客や商品など、お客様の企業固有のデータ）を選択してください。 監査結果を送信するためのロググループを新規に作成するか、既存のものを選択してください。 監査先の選択は任意ですが、監査とレポーティングのために強く推奨されます。 図 2. データ保護ポリシー構成を保存 CloudWatch Logs Data Protection をアカウントレベルで有効化 アカウントレベルでデータ保護ポリシーを有効にすると、アカウント内のすべてのロググループに適用されるので便利です。これは現在のロググループと、このアカウントの下で今後作成されるロググループに適用されます。 左下の 設定 に移動し、 ログ タブを選択して 設定 を選択します 図 3. データ保護アカウントポリシーの作成 ビジネスニーズに関連するすべての マネージドデータ識別子 を選択し、監査結果の 監査先 を選んで、 データ保護をアクティブ化 します。 図 4. データ保護アカウントポリシーを保存 カスタムデータ識別子の構成 独自のデータ識別子を使用して、独自のカスタム正規表現を定義し、マネージドデータ識別子が利用できない場合のユースケースに対応できます。金融機関の一般的な例は、 SWIFT コード(ビジネス識別コード: BIC)です。SWIFT コードは、ビジネストランザクションのルーティングとビジネス関係者の識別のための国際標準です。SWIFT コードは、金融機関の名称、国、所在地、支店を識別する 8 桁から 11 桁のコードです。SWIFT コードそのものは機密情報ではありませんが、ビジネスニーズに応じてトランザクションログ内で保護することを選択できます。独自のデータ識別子は、マネージドデータ識別子と組み合わせて使用することもできます。また、長期保持のニーズに応じて監査結果を Amazon Simple Storage Service (Amazon S3) バケットに送信したり、リアルタイムストリーミングのために Amazon Data Firehose に送信することもできます。 図 5. カスタムデータ識別子構成を定義する ログ内の機密データのマスク化の検証 ロググループのログを確認することで、機密データがマスクされていることを確認できます。これは CloudWatch Live Tail でリアルタイムに近い形で実行できます。または、 CloudWatch Logs Insights を使用してログデータを照会することもできます。 図 6. ログ内の機密データのマスキングを確認する 図 7. Live Tail で機密データのマスキングを確認する 図 8. Logs Insights での機密データマスキングの検証する 特権アクセスを持つユーザーで非マスク化されたデータを表示する マスクされていないデータを表示する には、 logs:Unmask の権限が必要です。次の CloudWatch Logs Insights クエリの例を使用すると、マスクされていないログを確認できます。 fields @timestamp, @message, unmask(@message) | sort @timestamp desc | limit 20 図 9. 特権を昇格して非マスク化されたデータを表示する 検出結果に対するアラームと通知の定義 CloudWatch は、デフォルトで LogEventsWithFindings という名前のメトリクスを作成し、特定のロググループに機密データが含まれるログイベントの数をカウントします。このメトリクスに基づいて CloudWatch アラームを定義すれば、機密データが検出されたときに通知を受け取り、その後対処アクションを行うことができます。 図 10. 検出結果のデフォルトメトリックによるログイベントのアラームの定義 以下は アラームの定義の例です。期間中のデータポイントの数を集計するために、サンプル数統計を選択します。これは、発生するたびにカウンタが 1 増えます。静的しきい値タイプ、以上条件と、しきい値を 1 に設定します。通知を送信するために、新しい Amazon Simple Notification Service (Amazon SNS) トピックを作成するか、既存のトピックを選択します。通知を受け取るメールアドレスをそのトピックに登録します。 図 11. アラームのメトリクス設定を指定する 図 12. アラームのメトリクス条件を指定する 図 13. アラームに対して SNS トピックへの通知を設定する 機密データ監査の結果と報告 各ロググループの機密データイベント数は、ロググループページで素早く確認できます。 図 14. ロググループページで機密データ件数を確認する コンプライアンスのニーズに従って、機密データの監査結果を CloudWatch Logs に送信することを選択した場合、各ログイベントに対して次の通り監査結果が生成されます。ロググループのリソース ARN とどのデータ識別子を確認することで、機密データが検出されたイベントソースを簡単に特定できます。これらの監査結果を Amazon S3 または Amazon Data Firehose に送信することも選択できます。 図 15. 機密データ監査の検出結果のログイベント構造を表示する まとめ このブログでは、機密データを扱うアプリケーションを持つお客様が、Amazon CloudWatch Logs Data Protection を活用して、ログ内の機密データを検出・保護し、データプライバシー規制の準拠要件を満たす方法をご紹介しました。また、CloudWatch Logs Data Protection を有効にする方法、機密データのマスキングを検証する方法、特権を持つユーザーが非マスク化されたデータを表示する方法、機密データの監査結果を収集して報告する方法、結果に対してアラームと通知を定義し、さらに修復アクションを行う方法についても説明しました。CloudWatch Logs 全体のセキュリティについて詳しくは、 Amazon CloudWatch Logs のセキュリテ ィ をご覧ください。 著者について Sasi Kiran Malladi Sasi Kiran Malladi は AWS の Principal Technical Account Manager です。AWS の最も大規模で戦略的な エンタープライズ企業が AWS をどのように利用するかに直接影響を与えています。Sasi は、経営陣がアジリティを取り入れ、高い影響力のあるクラウド変革を実現し、クラウド ソリューションが高い拡張性、柔軟性、および回復力を持つようにサポートしています。彼は金融サービス業界に深い専門知識を持ち、最大規模の銀行、決済、資本市場、保険会社の顧客と協力してきました。AWS に入社する前は、ソリューション アーキテクト ディレクターとして、お客様のデジタル/クラウド変革とアプリケーション現代化の取り組みをサポートしていました。LinkedIn: linkedin.com/in/sasikiranm David Myers David Myers は、AWS Enterprise Support の Sr. Technical Account Manager です。20 年以上の技術経験があり、キャリアの始まりからObservability が含まれていました。David Myers は Amazon Web Services でお客様が Observability の経験を改善することを愛しています。 本記事は、 How Amazon CloudWatch Logs Data Protection can help detect and protect sensitive log data を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

この記事は Cordial’s journey implementing Bottlerocket and Karpenter in Amazon EKS (記事公開日: 2024 年 8 月 8 日) を翻訳したものです。 概要 Cordial は、マーケティング戦略を完全に自動化するためのツールを提供するクロスチャネルマーケティングプラットフォームです。マーケティングの遂行を自動化することで、Cordial はテクノロジーチームが本来の強みである構築と創造性に集中できるようにします。Cordial の堅牢なプラットフォームを使用して、マーケターにデータアクセスと管理を委任することで、テクノロジーチームを支援します。顧客中心のアプローチで設計された Cordial は、データを活用して創造性を高め、効率を向上させ、コストを削減し、収益性の高い成長を促進する AI (人工知能) 搭載の高速、柔軟、相互接続された一連のツールとサービスを提供します。 2014 年の発足以来、大手企業ブランドは Cordial を選び、メール、SMS、モバイルアプリ、ソーシャルメディア、ダイレクトメールなどを横断して高い転換率のメッセージを自動化し、スケーラブルな収益の促進と長期的な顧客との関係を実現しています。Cordial は 2022 年と 2023 年の Deloitte Technology Fast 500TM で最も成長が早い企業に選ばれ、テクノロジー、成長、企業文化に関する 複数の賞 を受賞しています。 この指数関数的な成長を維持し、将来の拡大に備えるため、Cordial は次世代のインフラストラクチャプラットフォームを構築する旅に出ました。その中核となるコンピューティングプラットフォームは Amazon Elastic Kubernetes Service (Amazon EKS) で、以前のプラットフォームは Amazon Elastic Compute Cloud (Amazon EC2) 上にありました。この記事では、Cordial が Amazon EKS 環境内で Bottlerocket をオペレーティングシステム (OS)、 Karpenter をノードライフサイクルマネージャーとして実装した旅路に迫り、運用効率の向上とセキュリティ体制の改善を目指しました。 セキュリティ体制と運用効率の改善 Amazon EKS を利用する前は、アプリケーションを Amazon EC2 上で実行し、複数の Auto Scaling グループがスケーリングプロセスを容易にしていました。クロスチャネルマーケティングプラットフォームとして、アプリケーションの動作には次の 2 つの重要な原則がありました。 クライアントからのメッセージは即座に送信される必要 クライアントがメッセージ配信をトリガーするたびに、遅延なく即座に送信する必要があります。 クライアントからのメッセージは常に送信される可能性 このサービスのリアルタイム性から、メッセージは予測可能なパターンなしに常に送信される可能性があります クライアントが増えるにつれ、以下のような運用効率と セキュリティ体制の制限に直面しました。 アプリケーションの起動の遅延 コンピューティングのスケーリングの課題 スポットインスタンスなどのコスト効率の良いインスタンス購入オプションが利用できない課題 デバッグのワークフローが非効率的 チャレンジ-1: 起動時間の遅延とコンピューティングのスケーリングの課題 最初の大きな課題は、ノードの起動とアプリケーションの起動にかかる時間でした。インスタンスのユーザーデータスクリプトを使用して、起動時にアプリケーション環境をインストールおよび構成しました。ユーザーデータのシェルスクリプト内で実行された自動タスクには、 Amazon Elastic Block Store (EBS) ボリュームのフォーマットなどの一般的な構成要件、アプリケーションレベルの依存関係のインストール、特定のランタイムパラメータを使用したアプリケーション環境のブートストラップなどがありました。 そのため、アプリケーションがクライアントリクエストを受け付けられるようになるまでに、標準の Amazon EC2 Auto Scaling プロビジョニングプロセスから最大 5 分の遅延が発生していました。この起動の遅さにより、ワークロードの需要に基づいてリアルタイムにキャパシティを追加することができず、これがインスタントメッセージ配信の目標に直接影響を与えていました。 クライアントのリクエストをすぐに処理できるようにするため、一部の容量がアイドル状態になっていたにもかかわらず、常に最大容量を維持する必要がありました。これにより、運用が非効率的なデザインになってしまいました。 チャレンジ-2: スポットインスタンスが利用できない課題 ノードの起動プロセスが 5～10 分かかるため、残念ながらサービス品質を維持しながら Spot Instance の中断 の 2 分間の警告に安全に対応することができませんでした。これにより、Spot Compute の使用が不可能になり、コスト効率が悪くなりました。 チャレンジ-3: セキュリティ強化の課題 当社のソリューションでは、コンプライアンス目標を維持するために、Center for Internet Security (CIS) ベンチマークチェックを備えた汎用 OS を使用していました。将来の成長に向けたソリューションを計画する必要があったため、セキュリティ対策を強化するために、最小限のパッケージ、攻撃対象領域の縮小、そして既定の強化機能を備えたコンテナに最適化された OS を検討する必要がありました。 チャレンジ-4: デバッグワークフローの改善 デバッグのワークフローでは、ワーカーノードにログを記録し、基盤となるノード上のプロセスを監視およびデバッグするために strace ユーティリティをインストールする必要がありました。これはアクセスの観点からセキュリティーリスクとなります。そのため、デバッグパッケージがブートアップ時に既定でインストールされないようにすることが、セキュリティの観点から要件となりました。これにより運用オーバーヘッドも増加し、継続的な監視が必要となりました。 ソリューションの概要 上記の課題に対処するため、私たちは複数フェーズからなる取り組みを開始しました。。 フェーズ-1 では、メッセージングコンポーネントをコンテナ化し始めました。これにより、依存関係が減り、スケーラビリティの問題に対処できるようになります。 フェーズ-2 では、コンテナ化されたアプリケーションの管理、スケーリング、デプロイに必要なコアコンピューティングプラットフォームとして Amazon EKS に焦点を当てました。最初は、マネージド型ノードグループを使用してワーカー ノードをプロビジョニングし、Cluster Autoscaler を使用して必要なスケーリングプロセスを処理する標準的なセットアップから始めました。この結果、ユーザーデータスクリプトの削除に伴う起動時間の短縮など、すぐに成果が得られました。これは、ほとんどの構成が Kubelet レベルまたはコンテナレベルで構成可能だったためです。これにより、アプリケーションの起動プロセスは、当初の 5 〜 10 分の待ち時間から大幅に短縮されました。起動プロセスが高速化したことから、ワークロードの一部のプロセスでスポットインスタンスの実装も開始しました。 このセットアップを迅速に行うには、予想していたよりも複雑で時間がかかりました。さまざまな顧客をオンボーディングし始めると、クラスターには、ユニークな要件とスポットプールの多様性に対応するために、複数のインスタンスタイプ、サイズ、アーキテクチャが必要になりました。Cluster Autoscaler には、いくつかの課題がありました。ノードグループ内で使用されるインスタンスタイプは、正確なスケーリング計算のために同じ RAM と CPU コア数を持つ必要があったためです。これにより、Compute Optimized と General Purpose インスタンスタイプなど、混在したキャパシティのノードグループを作成することができませんでした。さらに、同じ Auto Scaling グループ内で、さまざまなインスタンスサイズやアーキテクチャ (x86 と ARM) のノードグループを作成することもできませんでした。Cluster Autoscaler にはスポット容量を優先し、オンデマンドをフォールバックオプションとして定義するための優先スケーリングの機能がありますが、コントローラーの処理に時間がかかりすぎました。 フェーズ-3 では、スケーラビリティの課題に対処するため、Kubernetes 向けに構築されたオープンソースのノードライフサイクル管理プロジェクト Karpenter を採用しました。Karpenter 内の NodePool カスタムリソース定義 により、複数のインスタンスタイプ、サイズ、アーキテクチャに関する要件を解決できました。Karpenter が “instant” タイプの EC2 Fleet API と連携してノードをプロビジョニングしたことで、ノードの起動時間を 30 秒以下に抑えることができました。また、Karpenter 固有の 中断制御フロー と中断予算を組み合わせることで、未使用の容量を統合し、コスト効率の良い設計を実現できました。 フェーズ-4 では、セキュリティ体制を強化するため、AWS がコンテナ実行用に設計したオープンソースの Linux ベースの OS である Bottlerocket の実装を開始しました。 一般的な Linux ディストリビューションでデフォルトでインストールされているパッケージ、ツール、インタープリター、依存関係の多くは、コンテナをホストするだけでは必要ありません。Bottlerocket はこれらの余分なソフトウェアを除外することでセキュリティオーバーヘッドを改善しました。 Bottlerocket は API 中心の設計を採用しており、Report API を備えています。これにより、OS レベルのレポーティングを自動化するメカニズムが提供されました。 Bottlerocket Report API を使用して、Bottlerocket と Kubernetes CIS ベンチマークに対してレポートを実行できました。 Phase-3 までのソリューションでは、sed (ストリームエディター) を使用して Kubelet の JSON 設定ファイルを直接変更する必要があり、エラーが発生しやすいワークフローでした。しかし、Bottlerocket は Kubernetes 設定を行うための宣言型の TOML 設定フォーマット を提供してくれたため、より簡単に設定ができ、複雑さが低減されました。 Bottlerocket には SELinux の強制モードの設定が組み込まれており、すべての非特権コンテナに制限の厳しい container_t ラベルが付与されます。また、セキュアシェルアクセスを提供しないことで、Bottlerocket は既存のメカニズムと併せて、開発者のデバッグ環境周りに必要なモニタリングフレームワークを安全な方法で実現するのに役立ちました。 図 1: Cordial の Amazon EKS アーキテクチャ 達成された成果と次のステップ 上記の設計を実装した後、次の図に示すように、Horizontal Pod Autoscaler が Custom Metrics を使用するようにすることで、Pod のスケーリングプロセスの改善も開始しました。 Pod Count Tasks in Queue per Pod Amazon EKS、Karpenter、Bottlerocket を使用することで、クラスターのサイズをその時点で必要な作業に合わせて調整し、必要に応じて拡大縮小できます。Karpenter の高速なノードプロビジョニング時間、多様な計算オプション、ノード統合機能により、常にピーク容量で実行する必要がなくなり、運用効率が向上し、ソリューションのコンピューティング部分だけで約 18% のコスト削減と 80% の起動時間改善が実現しました。Bottlerocket の目的別設計と API 中心の設計により、セキュリティが強化され、Karpenter と組み合わせることで、将来のスケーリングに適した設計のソリューションが実現しました。 結論 この記事では、Cordial チームが Amazon EKS、Karpenter、Bottlerocket を実装することでユーザーエクスペリエンスを改善した方法について説明しました。AWS と Cordial の協力により、Cordial のアプリケーション環境のモダナイゼーションが成功しました。また、Cordial がビジネス価値を高めるために、環境をさらに最適化することに注力していることも説明しました。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

本ブログは株式会社ゼネット様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの山澤です。 最近、 IT 関連市場規模の拡大に伴い、年々 IT 人材のニーズが高まっているという話をよく耳にします。 このような状況において、講師の負担を最小限に抑えつつ、いかに効率的に IT エンジニアを育成するかは、非常に重要なテーマではないでしょうか。 本記事では、このような課題に対する取り組みとして、株式会社ゼネット様の事例をご紹介します。同社は IT エンジニア向けの e ラーニングシステムに、 Amazon Bedrock を活用した自動質問回答機能と自動ソースコードレビュー機能を導入しました。これにより、受講生からの質問やソースコードレビューに素早く対応できるようになり、同時に講師の生産性も大幅に向上しました。 お客様の状況と検証に至る経緯 株式会社ゼネット様は、 e ラーニング学習用コンテンツ登録プラットフォーム「 Xlabo 」を提供しております。新人向けの Java 研修、 Ruby 研修、 AWS 研修など、様々なプログラムを通じて、実務で活躍できる IT エンジニアの育成に力を入れてきました。現在では年間 100 名以上の受講生を受け入れるほどまで事業を拡大し、リピート率も高い研修となっておりますが、以下のような課題感がありました。 IT 技術者に向けた研修を実施している中で、受講生からの質問対応やソースコードレビュー対応に講師の時間の半分が取られている 繁忙期は受講生が 50 名を超えることもあり、講師の順番待ちなどで受講生自体の満足度が低下する そこで、Amazon Bedrock を利用し、生成 AI による自動での質問回答を行うことで、上記の課題解決に向けて、検証することになりました。 お客様が開発された生成 AI を活用した受講生向け機能 株式会社ゼネット様は、 Amazon Bedrock の Claude 3.5 Sonnet を活用し、 2 つの新しい機能を開発しました。お客様曰く、これらの機能は、実際の講師と同じくらい、あるいはそれ以上の精度で回答できるようになっているとのことです。 1. 自動質問回答機能 まずは、質問への回答の面で受講生をサポートする機能を公開されています。ただ、質問に答えるだけではなく、質問をより適切な質問にブラッシュアップするサポートもされている点が特徴的です。 例えば「エラーで躓いています。エラーのデバッグ方法を教えてほしいです。」という、ファジーな質問に対して、以下のような質問内容へのアドバイスと、より良い質問の提案をレコメンデーションすることで、期待する回答が返ってきやすい質問にするサポートをします。 また、画面キャプチャなど画像付きで質問されたい受講生も多くいらっしゃいます。そのため、テキストだけではなく、画像を質問の入力に加えていただき、「添付画像の問題が理解できませんでした。解説をお願いします。」のような質問を受け付けられるようにしているのも特徴的です。 このようなサポートは初めての技術を学ぶ受講生にとって、ありがたい機能なのではないでしょうか？ この機能は、図が示すとおり、2 つのフェーズで構成されています。 Phase 1 ：質問内容をチェックし、より良い質問の仕方を提案します。これにより、受講生の質問する能力を向上させます。 Phase 2 ：質問に対する回答を作成します。 2. 自動ソースコードレビュー機能 次に、受講生が提出したプログラムコードをレビューする機能も公開されています。 設問作成者があらかじめレビューの観点を登録しておくことで、 LLM （大規模言語モデル）によるレビューの範囲を制限しています。これにより、受講生がまだ学んでいない内容を含めた指摘がされないように実装されています。 また、プログラムの実行やレビュー観点でのチェックで問題がなかった場合には、プラスアルファで学ぶと良い知識を提供します。提出されたコードに対するアドバイスを LLM にさせると、学習者がまだ習得していない表現や文法を含めた内容を生成してしまう可能性があります。そのため、設問の条件などを考慮し、受講生の学習進度に合わせたアドバイスをされている点が特徴的です。 例えば、「プログラムの終了には “System.exit(0);” を使うこと」という指示のある Java 言語に関する設問に対して、指示に従ってコードを記述した場合、 LLM は「 System.exit(0) の使用は一般的にはメインメソッド内で避けるべきです。代わりに、エラー処理を行うメソッドを作成し、早期リターンを使用することで、コードの可読性と保守性が向上します。」といったアドバイスがされる可能性があります。このような設問条件に矛盾するアドバイスが提供されないように実装されています。 この機能は、図が示すとおり、3 つのフェーズで構成されています。 Phase 1 ： プログラムを実行します。実行の結果、エラーが発生した場合には、LLM を用いて、ユーザに対して、実行エラーの解説をします。 Phase 2 ：プログラムの実行でエラーが発生しなかった場合は、 LLM を用いて、設問作成者があらかじめ登録したレビュー観点を基にチェックをします。レビューで問題がある場合は、ユーザに対して、レビューの結果をお伝えします。 Phase 3 ：レビュー観点を基にチェックで問題がなかった場合は、LLM を用いて、ユーザーに対して、プラスアルファで学ぶと良い知識をお伝えします。ただし、学習者がまだ習得していない表現や文法を含む情報を LLM が生成する可能性があるため、 LLM を用いて出力内容が設問の範囲内であるかを確認し、未学習の表現や文法を含む知識が提供されないよう対策を講じています。 プロンプトの工夫に加えて、このようにステッププロンプト（一度きりの命令ではなく、複数のステップに分けて回答を生成する手法）を採用することで回答の精度を大きく向上させることに成功されたとのことです。 精度の検証と結果 また、お客様は、複数の LLM の性能評価を実施されました。以下 2 つの重要な観点において、Claude 3.5 Sonnet が優れた精度を確認されたため、システムへの採用を決定されました。 1. 画像認識と文字抽出能力 Claude 3.5 Sonnet は、画像内のテキストや数値を高精度で認識し、正確に抽出することができました。これにより、自動質問回答機能で、学習者が以下のような設問の画像を添付し、質問をすることが可能となりました。 2. コード構造の理解と再現能力 Claude 3.5 Sonnet はソースコードのインデントやスペースといった構造要素を高い精度で認識し、必要に応じて指摘することができました。これにより、自動ソースコードレビュー機能で、学習者が提出したコードの形式や構造の適切さを正確に評価し、より質の高いフィードバックを提供することが可能となりました。 導入効果 システムをリリースした結果、以下 2 つの効果を得ることができました。 24 時間 365 日の質疑応答が実現でき、かつ 1 分以内での回答が可能になった。これによって受講生の学習効率が大幅に向上した 質問応答をシステムに託したことで、講師陣が研修の実習時間中に行うサポートの工数が半分以下に削減された 今回のアプローチでは、LLM が出力する内容を受講者の習得範囲内に制限しています。このしくみにより、受講者の学習進捗状況に合わせた形で、プラスアルファの知識を提供することができました。このような機能は、教育関連のシステムを提供しているお客様にとって有用ではないかと考えています。 まとめ 今回は、 Amazon Bedrock を活用して、e ラーニング向けシステムに自動質問回答機能と自動ソースコードレビュー機能を追加したお客様事例をご紹介いたしました。LLM の進歩により、テキスト処理だけでなく画像認識も可能になり、AI をより幅広い場面で活用できるようになったと実感しています。AWS を使った生成AIの活用に興味をお持ちの方は、お気軽にご相談ください。 また、今回紹介した「Xlabo」は、 2025 年 1 月からプラットフォーム型のサービスとして販売を予定しています。現在、無料モニターを募集中ですのでご興味のある方は、 こちら からお問い合わせください。 株式会社ゼネット : システム事業部 西島 由祐様（右から 2 番目）、武内 潤一様（左から 2 番目） Amazon Web Services Japan : アカウントマネージャー 浜崎 佳子（左端）、ソリューションアーキテクト 山澤 良介（右端） [Appendix] アーキテクチャ 今回の記事では、お客様が力を入れて取り組まれた生成AIの活用についてご紹介することに重点を置いたため、アーキテクチャの細かい説明は割愛しますが、これらの機能は、インフラストラクチャの管理、運用負荷の少ないマネージドサービスで構成されています。 ソリューションアーキテクト 山澤 良介 (X – @ymzw230 )

本投稿は、Director of Solutions Architecture for Search Services at Amazon Web Services である Jon Handler によって 2024 年 9 月 16 日に投稿された 記事 の日本語版です。 私は常に検索にまつわる課題を愛してきました。検索の本質は、質問を受け取り、その質問を理解し、そして最適な回答を取得することです。私は博士課程で AI ロボティクスのプロジェクトを主導し、計画フラグメントのライブラリを検索を通じて実世界の状況と結びつけました。以前の仕事では、商用検索エンジンを一から構築しました。そして AWS でのキャリアでは、ソリューションアーキテクトとして働き、顧客が様々な形態の検索サービスを採用するのを支援してきました。 多くの開発者と同様に、私もオープンソースに情熱を持っています。これは、学者が自分の分野での過去の業績を基礎にし、そこから恩恵を受けて、より大きな利益のために働くという私の学歴に部分的に由来するものです。私は、単一の目的を持つ小規模なプロジェクトから、熱心で積極的なコミュニティを持つ大規模なイニシアチブまで、数多くのオープンソース技術を使用し、貢献してきました。検索コミュニティは、独自の特別で学術的な趣があります。検索自体が情報検索、心理学、(象徴的な) AI といった長年の学術的な取り組みに関連しているからです。オープンソースソフトウェアはこのコミュニティで重要な役割を果たしてきました。検索技術は、特に過去 10-15 年の間に、Apache Lucene、Apache Solr、Apache ライセンス 2.0 バージョンの Elasticsearch、そして OpenSearch のようなオープンソースプロジェクトを通じて民主化されてきました。 本日、Linux Foundation が OpenSearch Software Foundation を 発表 したことに、私は非常に興奮しています。 OpenSearch Foundation 創設の一環として、AWS は OpenSearch の所有権を Linux Foundation に移管しました。 2021 年 4 月のプロジェクトの立ち上げ時に OpenSearch を紹介 するにあたって、私たちは「ユーザーが安全で高品質な、完全にオープンソースの検索および分析スイートを、新しい革新的な機能の豊富なロードマップとともに継続して利用できることを確実にする」という希望について話しました。私たちはその願いとコミットメントを維持しています。今回の移管によりそのコミットメントを深め、オープンなガバナンスを備えたより広範なコミュニティを取り込んで、その目標を支援します。 この発表に関して、 2 つの重要なポイントがあります。一つは、 Amazon OpenSearch Service の顧客にとっては、何ら変更がないという点です 。他方、オープンソース側では多くのことが変わり、それはサービスにとって純粋な利益となります。私たちは、コミュニティとのより深い協力と参加によって推進される、OpenSearch プロジェクトのイノベーションの加速を含む未来に向かって進んでいます。最終的には、それらがサービスに反映され、AWS の顧客に利益をもたらすことになります。 Amazon OpenSearch Service: これまでの取り組み Amazon は、当初よりオープンな環境で OpenSearch に取り組むことに焦点を当てていました。最初の課題は、コードのインポートと名前変更機能を備えた作業用コードベースをリリースすることでした。2021 年 7 月に OpenSearch 1.0 をローンチし、2021 年 9 月にマネージドサービスを Amazon OpenSearch Service に改名しました。Amazon OpenSearch Service のローンチに合わせて、エンジンの選択肢として OpenSearch 1.0 のサポートを発表しました。 Amazon のチームとコミュニティが OpenSearch プロジェクトで成長し、イノベーションを起こすにつれて、私たちはそれらの変更を対応するバージョンのサポートとともに Amazon OpenSearch Service にもたらしました。AWS では、コミュニティと共同でアイデア、RFC、機能リクエストを公開し議論することで、オープンソースを受け入れました。時間が経ち、プロジェクトが進むにつれて、コミュニティのメンテナーを採用し、AWS 内外の様々なソースからの貢献を受け入れました。 Amazon OpenSearch Service の顧客として、今後もオープンソースからマネージドサービスへの更新と新バージョンの流れを見ることができるでしょう。また、プロジェクト、そのコミュニティ、およびコードベースの成長に対する私たちの投資によって推進される継続的なイノベーションを体験することになります。 現在、OpenSearch プロジェクトは 7 億回以上のソフトウェアダウンロード、数千人のコントリビューター、200 人以上のプロジェクトメンテナーの参加により、大きな勢いを得ています。OpenSearch Software Foundation は、プレミアメンバーとして AWS、SAP、Uber、一般メンバーとして Aiven、Aryn、Atlassian、Canonical、Digital Ocean、Eliatra、Graylog、NetApp® Instaclustr、Portal26 の支援を受けてスタートします。 Amazon OpenSearch Service: 今後の展開 この発表は Amazon OpenSearch Service に何の変更ももたらしません。Amazon は引き続き、増加するコミッターとメンテナーとともに、OpenSearch プロジェクトのイノベーションと貢献にコミットしています。むしろ、より広範で深い参加によってグローバルコミュニティからより多様なアイデアがもたらされることで、このイノベーションは加速するでしょう。このコミットメントの核心には、「ユーザーが安全で高品質な、完全にオープンソースの検索および分析スイートを、新しい革新的な機能の豊富なロードマップとともに継続して利用できることを確実にする」という創設時からの継続的な願いがあります。私たちは、プロジェクトと密接に協力し続け、コードの改善に貢献し、それらの改善をマネージドサービスにもたらします。 この発表は、Amazon OpenSearch Service への接続や使用方法を変更するものでもありません。OpenSearch Service は引き続きフルマネージドサービスとして、サービスが提供するエンドポイントを通じて OpenSearch と OpenSearch Dashboards を提供します。また、既存のマネージドサービスが提供する各種機能も引き続きご利用いただけます。Amazon OpenSearch Service を使用している場合は、何も変更する必要がないということです。財団への移行によるライセンスの変更やコストの変更も生じません。 Amazon は引き続きプロジェクトに専門知識を提供し、クラウドネイティブな大規模分散システム、検索、分析、機械学習、AI など、顧客が最も必要とする新しいイノベーションに資金を提供します。Linux Foundation はまた、クラウドネイティブなオープンソースプロジェクトにとって重要な Cloud Native Computing Foundation (CNCF) などの他のオープンソース組織との協力を促進します。私たちの目標は、お客様の最もチャレンジングな課題をオープンソースファーストで解決し続けることです。最後に、オープンソースという製品の性質をふまえると、顧客と協力して問題をコードで一緒に解決する大きな機会があると考えています。私たちはその機会を楽しみにしています。 私たちは、常にお客様に OpenSearch プロジェクトへの参加をお奨めしてきました。現在、このプロジェクトには、Amazon 内外のさまざまな背景を持つメンバーが配置された運営委員会と技術運営委員会による、明確に定義された構造と管理が行われています。運営委員会はプロジェクトの資金調達と管理を担当し、技術運営委員会はプロジェクトの技術的な方向性を担当します。これにより、当社のマネージド サービスで使用しているテクノロジーの形成に直接参加できるようになる可能性が広がります。このプロジェクトは、問題の報告や機能リクエストから、RFC へのコメントやコードの貢献まで、大小を問わず、 Amazon OpenSearch Service をお使いの皆様の貢献を歓迎します。 まとめ プロジェクト、コミュニティ、そして Amazon OpenSearch Service にとって、今は素晴らしい時期です。AWS の顧客は、使用時に変更を加える必要はなく、Apache ライセンス 2.0 や価格にも変更はありません。しかし、Linux Foundation への移行は、オープンソースの世界からテクノロジーへ、そしてそこから Amazon OpenSearch Service への協力の精神をもたらすのに役立ちます。検索が成熟し続けるにつれて、私たちは共に質問をより良く理解し、関連性の高い結果を提供し続けることができるようになります。 OpenSearch Foundation の発表に関する詳細は、 AWS オープンソースブログ でご覧いただけます。 著者について Jon Handler は、カリフォルニア州パロアルトに拠点を置くアマゾン ウェブ サービスの検索サービスのソリューション アーキテクチャのディレクターです。 Jon は OpenSearch および Amazon OpenSearch Service と緊密に連携し、OpenSearch の検索およびログ分析ワークロードを抱える幅広い顧客にヘルプとガイダンスを提供します。 AWS に入社する前、Jon のソフトウェア開発者としてのキャリアには、大規模な e コマース検索エンジンのコーディングに 4 年間従事していました。 Jon は、ペンシルバニア大学で文学士号を取得し、ノースウェスタン大学でコンピュータ サイエンスと人工知能の理学修士号と博士号を取得しています。