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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon EC2 Mac インスタンスで、開発者が Apple の システム整合性保護 (SIP: System Integrity Protection) をプログラム的に無効化できるようになりました。ルートレスとも呼ばれるシステム整合性保護 (SIP) は、Apple が OS X El Capitan (2015 年、バージョン 10.11) に導入したセキュリティ機能です。ルートユーザーアカウントの権限を制限することで、害を及ぼす可能性のあるソフトウェアからシステムを保護するように設計されています。macOS では SIP が デフォルトで有効になっています。 SIP は、保護されたファイルやフォルダへの変更を防ぎ、システム所有のファイルやディレクトリへのアクセスを制限し、不正なソフトウェアによる起動ディスクの選択を阻止することで、システムを保護します。SIP の主な目的は、1 つのパスワード、または脆弱性だけでマルウェアがデバイスを完全に制御できるようになる恐れのある、無制限のルートアクセスに関連するセキュリティリスクに対処することです。Apple は、パスワードが弱い、または設定されていない管理者アカウントで操作を行っているユーザーが多いことを特に考慮して、この保護を実装することで macOS ユーザーのためのより高度なセキュリティレベルの確保を目指しています。 SIP は日常的な使用に対して優れたマルウェア防止機能を提供しますが、開発者の場合は、開発やテストの目的で SIP を一時的に無効化しなければならないことがあります。例えば、新しいデバイスドライバやシステム拡張機能を作成するときは、コードをインストールしてテストするために SIP を無効にする必要があります。さらに、SIP は、ソフトウェアが正常に機能するために必要な特定のシステム設定へのアクセスをブロックする場合もあります。SIP を一時的に無効化することで、macOS 用のプログラムを微調整するために必要な許可が付与されますが、これは承認されたメンテナンスのために金庫室の扉を一時的に無効化するようなものであり、永久に開いたままにしておくわけではないのを覚えておくことが重要です。 Mac で SIP を無効化 するには、マシンへの物理的なアクセスが必要です。マシンは、 リカバリモードで再起動 し、 csrtutil コマンドラインツールを使用して SIP を無効にしてから、再び再起動する必要があります。 これまで、EC2 Mac インスタンスでは標準の SIP 設定で作業を行う必要がありました。物理的にアクセスする要件とリカバリモードで起動する必要性は、SIP の Amazon EC2 コントロールプレーンや EC2 API との統合を困難にしていました。これからはその煩わしさがなくなります! Amazon EC2 Mac インスタンスで SIP を自由に無効化し、再度有効化できるようになりました。その方法をご紹介しましょう。 仕組み 私が Amazon EC2 Mac インスタンスを起動したとしましょう。Apple シリコン M2 プロセッサで動作する mac2-m2.metal インスタンスです。SIP の無効化または有効化は、新しい EC2 API: CreateMacSystemIntegrityProtectionModificationTask を呼び出すという簡単なものです。この API は非同期で、インスタンスの SIP ステータスを変更するプロセスを開始します。進捗状況は、もう 1 つの新しい EC2 API である DescribeMacModificationTasks を使用して監視できます。把握しておく必要があるのは、使用したいマシンのインスタンス ID だけです。 前提条件 Apple シリコンベースの EC2 Mac インスタンスや、より最近のマシンタイプでは、新しい EC2 API を呼び出す前に ec2-user ユーザーパスワードを設定し、macOS でそのユーザーの セキュアトークン を有効にする必要があります。これには、マシンに接続して、ターミナルに 2 つのコマンドを入力する必要があります。 # on the target EC2 Mac instance # Set a password for the ec2-user user ~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user New Password: (MyNewPassw0rd) # Enable secure token, with the same password, for the ec2-user # old password is the one you just set with dscl ~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd 2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user… 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294) 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done # The error about the KeyChain is expected.I never connected with the GUI on this machine, so the Login keychain does not exist # you can ignore this error. The command below shows the list of keychains active in this session ~ % security list "/Library/Keychains/System.keychain" # Verify that the secure token is ENABLED ~ % sysadminctl -secureTokenStatus ec2-user 2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user SIP ステータスの変更 SIP ステータスを切り替えるためにマシンに接続する必要はありません。必要なのはマシンのインスタンス ID だけです。ノートパソコンでターミナルを開き、 AWS コマンドラインインターフェイス (AWS CLI) を使用して Amazon EC2 Mac のインスタンス ID を取得します。 aws ec2 describe-instances \ --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" \ --output text i-012a5de8da47bdff7 次に、このままノートパソコンのターミナルを使って、 create-mac-system-integrity-protection-modification-task コマンドで SIP を無効にします。 echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' &gt; tmpCredentials aws ec2 create-mac-system-integrity-protection-modification-task \ --instance-id "i-012a5de8da47bdff7" \ --mac-credentials fileb://./tmpCredentials \ --mac-system-integrity-protection-status "disabled" &amp;&amp; rm tmpCredentials { "macModificationTask": { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": {}, "startTime": "2025-03-14T14:15:06Z", "taskState": "pending", "taskType": "sip-modification" } } タスクが開始されたら、 aws ec2 describe-mac-modification-tasks コマンドでステータスを確認できます。 { "macModificationTasks": [ { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": { "debuggingRestrictions": "", "dTraceRestrictions": "", "filesystemProtections": "", "kextSigning": "", "nvramProtections": "", "status": "disabled" }, "startTime": "2025-03-14T14:15:06Z", "tags": [], "taskState": "in-progress", "taskType": "sip-modification" }, ... インスタンスがプロセスを開始し、一連の再起動を行います。その間、インスタンスにはアクセスできなくなります。このプロセスは、完了するまで 60～90 分かかる場合があります。完了後、コンソールのステータスが再び利用可能になったら、いつものように SSH または EC2 Instance Connect 経由でマシンに接続 します。 ➜ ~ ssh ec2-user@54.99.9.99 Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts. Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1 ┌───┬──┐ __| __|_ ) │ ╷╭╯╷ │ _| ( / │ └╮ │ ___|\___|___| │ ╰─┼╯ │ Amazon EC2 └───┴──┘ macOS Sonoma 14.3.1 ➜ ~ uname -a Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64 ➜ ~ csrutil --status System Integrity Protection status: disabled. SIP を無効化する状況 SIP の無効化はシステムを潜在的なセキュリティリスクにさらすことになるため、慎重に行う必要があります。とは言うものの、この記事の冒頭で話したように、macOS 用のデバイスドライバやカーネル拡張機能を開発するときは、SIP の無効化が必要になるかもしれません。古いアプリケーションの中には、SIP が有効になっているときに正しく機能しないものもあります。 SIP の無効化は、Spotlight のインデックス作成を無効にするときにも必要です。Spotlight は、Mac 上のアプリケーション、ドキュメント、E メール、その他アイテムをすばやく見つけるために役立ちます。デスクトップマシンでは非常に便利ですが、サーバーの場合はそうでもありません。ドキュメントの変更に合わせてインデックスを作成する必要がない場合は、Spotlight を無効にすることで 一部の CPU サイクルが解放され、ディスク I/O が軽減されます 。 知っておくべきこと Amazon EC2 Mac での SIP の無効化については、他にも知っておくべき事柄がいくつかあります。 SIP の無効化は、API と AWS SDK 、 AWS CLI 、 AWS マネジメントコンソール を使用して実行できます。 Apple シリコンでは、設定がボリュームベースになっています。そのため、 ルートボリュームを置き換える 場合は、SIP を再度無効にする必要があります。Intel では設定が Mac ホストベースなので、この場合もルートボリュームを置き換えると SIP が無効化されます。 SIP を無効化した後でインスタンスを停止して起動すると、SIP が再び有効になります。インスタンスを再起動しても、インスタンスの SIP ステータスは変わりません。 EBS ボリューム間で SIP ステータスを引き継ぐことはできません。つまり、EBS スナップショットからインスタンスを復元した後や、SIP が有効になっているインスタンスから AMI を作成する場合でも、SIP は再び無効になります。 これらの新しい API は、 Amazon EC2 Mac が提供されているすべてのリージョン で利用でき、追加料金はありません。今すぐお試しください。 – seb 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 20 日は、 AWS Product Lifecycle ページ をご紹介したいと思います。このページは、AWS 全体でのサービス可用性の変更に関する包括的な情報を提供する一元化されたリソースです。 新しい AWS Product Lifecycle ページは、すべてのサービス可用性情報を 1 つの便利な場所にまとめます。この専用リソースでは、1) 新規のお客様へのアクセス提供を終了するサービス、2) サポートの終了が発表されたサービス、3) サポート終了日を迎えたサービスの 3 つの主要変更カテゴリに関する詳細を把握できます。リストされている各サービスに固有のサポート終了日や推奨移行パスを確認し、関連ドキュメントへのリンクにアクセスできるため、サービスの移行をより効率的に計画できます。 AWS Product Lifecycle ページは、ワークロードに影響する可能性のある変更の最新情報を入手するために役立ち、サービス移行のより効率的な計画を可能にします。このリソースの一元的な性質により、サービスのライフサイクル情報を追跡するために必要な時間と労力が削減されるので、管理上のオーバーヘッドではなく、中核的なビジネス目標に集中できるようになります。 5 月 20 日の新しい AWS Product Lifecycle ページでは、以下のサービス変更と機能変更に関するアップデートをご覧いただけます。 2025 年の AWS サービス可用性アップデート 検討を重ねた結果、一部の AWS サービスと機能の可用性変更を発表することになりました。AWS では、サービスまたは機能のサポートを終了するという判断が、お客様の業務に大きな影響を与えることを理解しています。このような判断は、徹底した評価を経た上でのみ行われるものです。サポートの終了が必要な場合は、利用可能な代替サービスや機能に関する詳細なガイダンスと、移行のための包括的なサポートを提供します。 新規のお客様へのアクセス提供を終了するサービス 2025 年 6 月 20 日をもって、新規のお客様に対する以下のサービスまたは機能へのアクセス提供を終了します。既存のお客様は、引き続きサービスをご利用いただけます。 Amazon Timestream for LiveAnalytics サポートの終了が発表されたサービス 以下のサービスはサポート対象外となります。サービス固有のサポート終了日、詳しい移行情報については、個々のサービスドキュメントページをご覧ください。 Amazon Pinpoint AWS DMS Fleet Advisor AWS IQ AWS IoT Analytics AWS IoT Events AWS SimSpace Weaver AWS Panorama Amazon Inspector Classic Amazon Connect Voice ID サポート終了日を迎えたサービス 以下のサービスはサポート終了日に到達したため、アクセスできなくなりました。 AWS Private 5G AWS DataSync Discovery AWS Product Lifecycle ページ が利用可能になり、新しいページにはこの記事で説明したすべての変更が掲載されています。このページをブックマークするとともに、「 AWS の最新情報 」をチェックして、今後の AWS サービス可用性アップデートを確認することをお勧めします。この新しいリソースの使用方法の詳細については、 AWS または通常の AWS サポート連絡先に連絡して、影響を受けるワークロードの移行に関する具体的なガイダンスを受けてください。 – seb 原文は こちら です。

5 月 19 日は、AWS クラウドインフラストラクチャでの最新イノベーションを包括的に紹介する AWS Cloud Infrastructure Day をご紹介します。このイベントでは、コンピューティング、 人工知能と機械学習 (AI/ML) 、ストレージソリューション、ネットワーク機能、サーバーレス、アクセラレーテッドテクノロジー、およびグローバルインフラストラクチャの全体における最先端の進歩に焦点を当てます。 2025 年 5 月 22 日の午前 11 時 (米国太平洋夏時間) (米国東部夏時間の午後 2 時) から開催される 1 日限りの無料バーチャルイベント、AWS Cloud Infrastructure Day にぜひご参加ください。このイベントは、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch などの複数のプラットフォームで同時にストリーミングされます。 このイベントで予定されているハイライトをいくつかご紹介しましょう。 イベントのオープニングとして、 顧客を第一に考えるイノベーションという目標を掲げて Amazon Elastic Compute Cloud (Amazon EC2) がリリースされた 2006 年から AWS が辿ってきた道のりを、VP of EC2 Technology である Willem Visser が紹介します。Visser は、規模、キャパシティ、柔軟性に基づいてスタートアップワークロードとエンタープライズワークロードの両方をサポートするために、ほぼ 20 年の年月をかけてクラウドインフラストラクチャで達成されてきた進歩について語ります。 ストレージ機能やネットワーク機能といったサービスの並行的な進化など、AWS が完全なクラウドインフラストラクチャを創り出すためにコンピューティングインスタンスの域を超えた開発をどのように行ったのかを学ぶことができます。 GoDaddy の Principal Engineer である Todd Kennedy 氏は、GoDaddy の Graviton 導入ジャーニーと、Graviton から得たメリットを共有します。Kennedy 氏は、Rust ワークロードの Graviton への移行を明らかにする例も説明します。GoDaddy が 40% のコンピューティングコスト削減と、20% を超えるパフォーマンス向上を達成した方法を学びましょう。 このイベントでは、AWS クラウドインフラストラクチャに関連するさまざまなトピックを取り上げます。私が関心を持った興味深いトピックには、以下のようなものがあります。 エッジでの生成 AI – AWS のハイブリッドサービスとエッジサービス を使用して、データレジデンシー要件をきっかけとしたオンプレミスユースケースとエッジユースケースのための小規模言語モデル (SLM) を選択し、ファインチューニングして、デプロイする方法を学ぶことができます。 エージェント型 AI の監査性のためのサーバーレス – AWS Step Functions や AWS Lambda が不透明なエージェント型 AI システムの運用を透明かつ監査可能なワークフローに変換する方法を学ぶことができます。 アクセラレーテッドコンピューティング – サーバー、データセンター、 シリコンでの AWS のイノベーション を詳しく検証して、お客様が AI チップをどのように使用しているのかを学びます。生成 AI の使用を開始して、コストを削減する方法をご覧ください。 ネットワーク機能 – 物理的なファイバーネットワークからソフトウェア定義のネットワークまで、AWS のインフラストラクチャが比類のないパフォーマンスと信頼性を世界的な規模で実現する方法を学ぶことができます。このセッションでは、ハイブリッド環境のためのセキュアな接続ソリューションに重点を置きながら、最新のアプリケーションネットワークパターンについて説明します。 このイベントは、技術面での意思決定者や開発者に最適で、深い技術的インサイトと、最新の AWS クラウドインフラストラクチャソリューションの実践的なデモを提供します。 詳細については、イベントスケジュールを確認して、 AWS Cloud Infrastructure Day に登録してください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

コンテナワークロードを実行するときは、ソフトウェア脆弱性がリソースのセキュリティリスクをどのように引き起こすかを理解する必要があります。これまで、 Amazon Elastic Container Registry (Amazon ECR) イメージの脆弱性を特定することはできましたが、これらのイメージがコンテナ内でアクティブかどうかを判断したり、その使用状況を追跡したりすることはできませんでした。これらのイメージが実行中のクラスターで使用されているかどうかを把握できなかったため、実際のデプロイや使用パターンに基づいて修正を優先順位付けする能力にも限界がありました。 5 月 19 日より、 Amazon Inspector が脆弱性管理を強化する 2 つの新機能の提供を開始し、コンテナイメージをより包括的に確認できるようになりました。まず、Amazon Inspector が Amazon ECR イメージを実行中のコンテナにマッピングするようになりました。このため、セキュリティチームは環境内で現在実行されているコンテナに基づいて脆弱性の優先順位付けを行えるようになります。これらの新機能を使用することで、Amazon ECR イメージの脆弱性を分析するとともに、それらが現在実行中かどうか、コンテナ環境で最後に実行されたのはいつだったかに基づいて、検出結果に優先順位を付けることができます。さらに、クラスターの Amazon リソースネーム (ARN) を表示し、イメージがデプロイされている EKS ポッドまたは ECS タスクの数を確認することもできます。これは、使用状況と重大度に基づいた修正の優先順位付けに役立ちます。 次に、脆弱性スキャンのサポートを最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) に拡張するとともに、 Go Toolchain 、 Oracle JDK および JRE 、 Amazon Corretto 、 Apache Tomcat 、 Apache httpd 、 WordPress (コア、テーマ、プラグイン)、 Puppeteer などの追加のエコシステムに対するサポートも拡張しました。これらの拡張は、チームが高度に最適化されたコンテナ環境でも堅牢なセキュリティを維持するために役立ちます。 Amazon Inspector は、コンテナ上で実行されているイメージを継続的に監視して追跡することで、どのコンテナイメージが環境内でアクティブに実行されており、それらがどこにデプロイされているかをチームが特定できるようにして、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 内のコンテナで実行されている Amazon ECR イメージと、関連する脆弱性を検出します。このソリューションは、委任された管理者機能を用いて単一の AWS アカウント 、クロスアカウントシナリオ、および AWS Organizations の全体で Amazon ECR イメージを管理するチームをサポートし、コンテナイメージの実行パターンに基づく一元化された脆弱性管理を可能にします。 実際の動作を見てみましょう Amazon ECR イメージスキャン は、リポジトリの継続的な自動スキャン機能を提供するために Amazon Inspector と統合する 拡張スキャン を使用して、コンテナイメージ内の脆弱性を特定できるようにします。この新機能を使用するには、 Amazon ECR コンソール で拡張スキャンを有効にする必要があります。拡張スキャンは、「 Configuring enhanced scanning for images in Amazon ECR 」ドキュメントページの手順に従って有効化できます。 私は Amazon ECR 拡張スキャン機能を既に有効化しているので、追加のアクションは必要ありません。 Amazon Inspector コンソール のナビゲーションパネルにある [ 全般設定 ] に移動し、[ ECR scanning settings ](ECR スキャン設定) を選択します。ここでは、[ Last in-use date ](最終使用日) と [ Last pull date ](最終プル日) のいずれかを選択して [ Image re-scan mode ](イメージの再スキャンモード) を設定できます。ここではデフォルトの [ Last in-use date ](最終使用日) を使用し、[ Image last in use date ](イメージの最終使用日) を [14 days](14 日) に設定します。これらの設定により、過去 14 日の間に私の Amazon ECS または Amazon EKS 環境でイメージがいつ実行されたかに基づいて、Inspector がイメージを監視するようになります。これらの設定を適用すると、Amazon Inspector がコンテナで実行されているイメージに関する情報の追跡を開始し、その情報を脆弱性検出結果に組み込むようになるため、環境内のコンテナでアクティブに実行されているイメージに焦点を当てることができるようになります。 設定が完了したら、コンテナで実行されているイメージに関する情報が [ 詳細 ] メニューに表示されます。ここでは、EKS ポッドまたは ECS タスクの数とともに、最終使用日と最終プル日を確認できます。 [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) の数を選択すると、各イメージのクラスター ARN、最終使用日、タイプを確認できます。 クロスアカウントの可視性デモのため、2 つのアカウントに EKS ポッドがデプロイされたリポジトリを用意しました。[ Resources coverage ](リソースカバレッジ) メニューで [ Container repositories ](コンテナリポジトリ) に移動し、リポジトリ名を選択してから、[ Image tag ](イメージタグ) を選択します。以前と同様に、デプロイされた EKS ポッド/ECS タスクの数を確認できます。 デプロイされた EKS ポッド/ECS タスクの数を選択すると、それが別のアカウントで実行されていることがわかります。 [ 検出結果 ] メニューでは脆弱性を確認でき、そのうちの 1 つを選択すると、[ 影響を受けるリソース ] データで [ Last in use ](最終使用) 日と、脆弱性に関係する [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) を見つけることができます。これは、実際の使用状況に基づいて修正の優先順位付けを行うために役立ちます。 [ すべての検出結果 ] メニューでは、[ Account ID ](アカウント ID)、[ Image in use count ](使用中のイメージ数)、[ Image last in use at ](イメージの最終使用日) などのフィルターを使用して、アカウント管理内の脆弱性を検索できるようになりました。 主な機能と考慮事項 コンテナイメージのライフサイクルに基づく監視 – Amazon Inspector は、イメージのプッシュ日 (期間範囲は 14 日、30 日、60 日、90 日、180 日、または lifetime (ライフタイム))、イメージのプル日 (14 日、30 日、60 日、90 日、または 180 日)、停止期間 (Never (停止なし) から 14 日、30 日、60 日、90 日、または 180 日)、およびコンテナで実行されているイメージのステータスに基づいてイメージのアクティビティを判断できるようになりました。この柔軟性により、組織はその監視戦略をリポジトリイベントだけでなく、実際のコンテナイメージの使用状況に基づいてカスタマイズできるようになります。Amazon EKS と Amazon ECS のワークロードについては、最終使用、プッシュ期間、プル期間が 14 日に設定されており、これが新規のお客様のデフォルトになりました。 イメージランタイム対応の詳細情報 – 修正作業の優先順位付けを支援するため、Amazon Inspector の各検出結果には、コンテナでのイメージの最終実行日を示す lastInUseAt 日付と、イメージを現在使用しているデプロイされた EKS ポッド/ ECS タスクの数を示す InUseCount が含まれるようになりました。Amazon Inspector は、すべてのアカウントの Amazon ECR 最終プル日のデータと、Amazon ECS タスクまたは Amazon EKS ポッドコンテナで実行されているイメージのデータの両方を監視し、この情報を少なくとも 1 日 1 回更新します。Amazon Inspector はこれらの詳細情報をすべての検出結果レポートに統合し、 Amazon EventBridge とシームレスに連動します。検出結果は、ローリングウィンドウまたは固定範囲のオプションを使用する lastInUseAt フィールドに基づいてフィルタリングできます。また、過去 14 日、30 日、60 日、または 90 日間の最終実行日に基づいてイメージをフィルタリングすることも可能です。 包括的なセキュリティカバレッジ – Amazon Inspector は、単一のサービスを通じて、従来の Linux ディストリビューションと、最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) の両方に対する統合脆弱性評価を提供できるようになりました。拡張されたカバレッジにより、複数のスキャンソリューションを使用する必要がなくなるのと同時に、従来のディストリビューションから高度に最適化されたコンテナ環境におよぶコンテナエコシステム全体で堅牢なセキュリティプラクティスを維持することができます。このサービスは、一元化されたプラットフォームを通じた包括的な脆弱性管理を提供することでセキュリティ業務を合理化し、あらゆるコンテナタイプの効率的な評価を可能にします。 強化されたクロスアカウント可視性 – 単一アカウント、クロスアカウント設定、AWS Organizations 全体でのセキュリティ管理が、委任された管理者機能を通じてサポートされるようになりました。Amazon Inspector は、同じ組織内のコンテナで実行されているイメージの情報を共有します。これは、ゴールデンイメージリポジトリを維持しているアカウントにとっては特に有用です。Amazon Inspector は、リソースが API を使用するアカウントに属している場合、イメージが実行されている Amazon EKS クラスターと Amazon ECS クラスターのすべての ARN を提供するため、複数の AWS アカウント全体に対する包括的な可視性が得られます。システムは、デプロイされた EKS ポッドまたは ECS タスクの情報を少なくとも 1 日 1 回更新し、アカウントが組織に参加または離脱するときも正確性を自動的に維持します。 利用可能性と料金 – 新しいコンテナマッピング機能は、 Amazon Inspector が提供されている すべての AWS リージョン で利用でき、追加料金はありません。使用を開始するには、 AWS Inspector ドキュメント をご覧ください。料金の詳細と提供されているリージョンについては、 AWS Inspector の料金表ページ を参照してください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、テクニカルガイダンスでの惜しみない援助と、専門知識を提供してくれた Nirali Desai に感謝の意を述べたいと思います。この包括的な概要をまとめることができたのは彼女のおかげです。 –&nbsp; Eli 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

みなさん、こんにちは。ソリューションアーキテクトの深見です。OpenSearch Magazine の第 2 号をお届けいたします。本号では Amazon OpenSearch Service の最近のアップデート情報と、先日リリースされました OpenSearch 3.0 をはじめ OSS の OpenSearch Project にまつわるアップデートからピックアップしてご紹介します。また Hot Topic として OpenSearch のクエリを最適化する手助けになる機能の１つである Query Insights についてご紹介します。 OpenSearch Magazine は、 Amazon OpenSearch Service およびオープンソース版 OpenSearch の最新動向をキャッチアップいただくべく開設されました。開設の経緯や Amazon OpenSearch Service の概要につきましては、「 OpenSearch Magazine 開設のお知らせ 」よりご確認いただけます。 マネージドサービスのアップデート 直近でリリースされた、 Amazon OpenSearch Service に関する注目のアップデートについてご紹介していきます。 Amazon OpenSearch Service が OpenSearch バージョン 2.19 のサポートを開始 2025 年 4 月 30 日に Amazon OpenSearch Service で OpenSearch 2.19 を利用できるようになりました。OpenSearch 2.19 でのアップデートの中から ２ つピックアップしてご紹介します。 まずは、ハイブリッド検索において RRF（Relative Range Factor) が利用可能になりました。RRF は複数の検索システムの結果を順位の逆数をもとに並び替えるアルゴリズムです。 具体的な数式は、システム $r$ における文書 $d$ の順位 $r(d)$ とハイパーパラメーターである $k$ を用いて次のように計算されます。 この数式の意味を見ていきましょう。 まず、合成したいクエリ（ハイブリッド検索の場合、全文検索とベクトル検索）ごとに検索を実施します。 合成したい複数のクエリごとのランキング結果がでると、ドキュメントごとの順位の逆数をスコアとします。 クエリごとのスコアをそれぞれのドキュメントについて足し合わせることで最終的なスコアとする、と言った流れになります。 ハイブリッド検索を用いる際にベクトル検索のスコアと全文検索のスコアではスケールが異なることから単純にそのスコアをもとに並び替えをしてしまうと検索結果にバイアスが加わってしまいます。しかし、全文検索のスコアは相対的な値でありクエリやドキュメントの母集団によって異なったスケールをもつ値になるためベクトル検索のスコアと組み合わせるには複雑な計算が必要になってしまいます。そこで、RRF ではそれぞれの検索結果の順位を利用することでバイアスを軽減しながら検索結果の統合とリランクが可能になります。 ハイブリッド検索を利用する際には多くの場面で利用されているアルゴリズムのため、待望のアップデートでありました。OpenSearch で利用する場合は search pipeline 上の reranker として設定することで利用できます。 PUT /_search/pipeline/rrf-pipeline { "description": "Post processor for hybrid RRF search", "phase_results_processors": [ { "score-ranker-processor": { "combination": { "technique": "rrf", "rank_constant": 40 } } } ] } こちらのブログ でも詳しく紹介されていますので、合わせてご確認ください。 次に紹介するのは、 ML inference search です。ML inference search を利用することで、検索を行うロジックの前後で ML モデルを呼び出すことでクエリのリクエストやレスポンスの内容を書き換えたりエンリッチしたりすることができる機能になります。非常に柔軟な検索クエリを別のコンポーネントを用意することなく実現できます。例えば、クエリ対象の文字列を Embedding モデルに渡してベクトルに変換したり、LLM にわたすことでクエリ文字列とは違う表現の文章でエンリッチした上で検索を実施するといったことが可能になります。 レスポンスプロセッサー は 2.18 で、 リクエストプロセッサー が 2.19 で利用可能になっています。 その他にも、後述のHot Topicで紹介する Query Insights dashboard など多くのアップデートがありました。詳細は、 リリースブログ や リリースノート をご覧ください。 Amazon OpenSearch Ingestion のガイド付きビジュアルパイプラインビルダーの導入 2025 年 4 月 22 日のアップデートにより、 Amazon OpenSearch Ingestion で UI 上からパイプラインの構築が可能になるビジュアルパイプラインビルダーが利用可能になりました。これまでは、OpenSearch Ingestion のパイプラインを作成する際にはブループリントをベースにリソース ARN などの各種パラメータをユーザーが手書きする必要がありました。このアップデートにより、UI 上に表示される候補からリソースを選択することで自動でブループリントに入力がされるようになり、簡単にパイプラインを構築できるようになりました。 詳細は、こちらの ブログ をご確認ください。 OpenSearch Project の最新動向 OpenSearch Project では、2025 年 5月 6 日に OpenSearch 3.0 がリリースされました！OpenSearch 3.0 では多数のアップデートや新機能が追加されていますが、ベースとなる検索クエリのパフォーマンス向上に注目いただきたいです。詳細はぜひこちらの ブログ をご確認いただきたいところですが、 OpenSearch Big5 ワークロード において 以前までの最新バージョンである 2.19 と比べて 約 24% 高速 であるという結果になっています。これは、OpenSearch のベースの検索ライブラリである Apache Lucene や Java ランタイムのバージョンアップや OpenSearch 内部のロジックの最適化が要因となっています。 他にも、生成AI 界隈で注目のまとである MCP が OpenSearch にも登場しました。OpenSearch の MCP 関連機能では、OpenSearch への検索をエージェントに行わせるために利用できる MCP 組み込みサーバーの機能とOpenSearch の中のエージェントから外部の MCP サーバーを利用するための MCP クライアントの両面の機能が登場しています。詳細は、 OpenSearch における MCP の紹介ブログ をご覧ください。 3.0 に関するアップデートの詳細は、 リリースノート や リリースブログ をご確認ください。OpenSearch 3.0 は2025 年 5月時点でまだマネージドサービスの OpenSearch Service では利用できませんが、今後のアップデートが楽しみですね！ Hot Topic : Query Insights を使ったクエリ最適化 今号のHot Topic として Query Insights と その機能を OpenSearch Dashboard の UI で利用できる Query Insights dashboard についてご紹介します。 OpenSearch を利用して検索のやログ監視といったワークロードを運用していると、クエリが遅く感じ改善しようとされることは少ないありません。もしくは、一定の期間についてリソース使用量がスパイクしているような場合、その原因を探索することが求められる場合もあります。そういった際に、どのようなメトリクスを見て改善方法や問題の原因を検討するのが良いでしょうか？そう言った際に利用できる機能の１つが Query Insights になります。 Query Insights を利用することで、クエリの実行時間、CPU使用率、メモリ使用量などの主要なメトリクスを基準に設定した上位 N 件のクエリを履歴として保持することができます。また、クエリでつかわれている API やその構造をもとに類似しているクエリをグルーピングしたうえで、その中の上位 N 件のクエリグループを表示することもできます。 レイテンシーやリソース使用量について影響の大きなクエリを見つけることで、クエリ自体の改善やパターンに基づく予防策の検討に役立てることができます。 このように重要なメトリクスを追跡できる Query Insights ですが、2.19 より OpenSearch Dashboard の UI 上から 確認することができるようになりました。 UI 上ではクエリの履歴とそれに紐づく各メトリクスを確認することができます。この画面ではレイテンシーを基準に上位 N 件のクエリを探索するといったように、それぞれの項目をもとに履歴を並べかえることが可能です。また、期間やコーディネータノード ID でのフィルタや検索も可能です。 クエリの詳細ページでは、実際にどのようなクエリが実行されたのかや、実行タイムスタンプ、CPUとメモリの使用量、フェーズレベルのレイテンシー、インデックス、ノード、シャードなどのメタデータが確認可能です。 設定画面からは、メトリクスごとに上位何件を追跡するのか、グルーピング、履歴の保持期間や保存先の index の設定が可能です。 このように管理者がクエリパフォーマンスを監視する場合でも、開発者が特定のクエリの問題を調査する場合でもダッシュボード上から簡単にクエリの履歴の探索が可能になります。クエリのパフォーマンスに関してお悩みの場合はぜひ Query Insights dashboard をのぞいてみてください。 セットアップ手順と使用方法については、 Query Insights dashboards を参照してください。 まとめ 本号では、Amazon OpenSearch Service の最新アップデートとして、バージョン 2.19 に関連して RRF 対応と ML Inference の機能、OpenSearch Ingestion の ビジュアルパイプラインビルダーをご紹介しました。また OpenSearch Project のアップデートから、3.0 のアップデートの中からパフォーマンスの向上についてと MCP の機能をピックアップしてご紹介しました。そして、OpenSearch のクエリパフォーマンスを改善するのに有効な Query Insights という機能について解説しました。 今号の内容は以上になります。また次回をお楽しみに！ OpenSearch Project のロードマップは、 OpenSearch Project サイト および Github 上で公開されています。OpenSearch のロードマップについてご興味がございましたら、是非これらの情報をご確認ください。 https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/ https://github.com/orgs/opensearch-project/projects/206 著者について ソリューションアーキテクト 深見 修平 (Shuhei Fukami) 2021 年に AWS Japan に Solutions Architect として入社しました。現在は Analytics SAとして Amazon OpenSearch Service をはじめ、AWS Glue、Amazon SageMaker LakeHouse などの Analytics Service にまつわるお客様のデータ分析やビッグデータ処理にまつわるシステムの導入および活用を支援しています。