レンゴー株式会社について レンゴーは、たゆまぬ意識改革とイノベーションを通じて、あらゆる産業のすべての包装ニーズに対し、総合的なソリューションでお応えする「GPI=ゼネラル・パッケージング・インダストリー」です。物流と暮らしの豊かさを支え、より良い社会、持続可能な社会の実現を目指して取り組んでいます。 はじめに データ活用が企業の競争力を左右する時代において、多くの企業がデータ駆動組織への転換を模索しています。私たちレンゴーも例外ではなく、長年にわたりデータ活用の拡大に取り組んできました。しかし、その道のりは順調とは言えませんでした。思うような成果が得られない中、私たちはAWSとパートナー企業( 株式会社JSOL )の協力を得て、自社の課題に特化した研修プログラムを開発しました。このアプローチが功を奏し、社内でのデータ活用の取り組みに変化の兆しが見え始めています。本稿では、同様の課題に直面している企業の皆様に向けて、私たちの取り組みと経験から得た気づきを共有します。 データ活用を妨げる三つの課題 レンゴーは、製紙業界が直面する厳しい経営環境と2024年問題として知られる物流危機への対応を迫られていました。業界全体が原材料コスト上昇、環境規制強化、デジタル化による紙需要減少という三重苦に直面する中、データ活用による業務変革が不可欠との判断に至りました。そして、2021年から2023年にかけて、全社で使用する汎用データ基盤の構築に取り組みました。各工場から収集したデータをデータ基盤に集約し、Amazon QuickSightを使って可視化できる分析基盤を構築しました。 技術的な基盤は整ったものの、実際のデータ活用は思うように進展しませんでした。データは蓄積されているにもかかわらず、それを業務改善や意思決定に活かすという段階に至らなかったのです。インフラ構築だけではデータ駆動組織への転換は実現しないという問題に直面しました。私たちはこの問題を引き起こす要因として、「ソフトスキル」「ハードスキル」「ツール」の3つの観点があると仮説を立てました。 (1) 業務部⾨⾃らデータを活⽤する⾵⼟の醸成(ソフトスキル) データ基盤の整備は進んでいたものの、データ活用は情報システム本部や一部の研究開発部門にとどまり、業務部門にまで浸透していませんでした。特に顕著だったのは、現場においてデータを活用して業務効率化を図るという発想自体がないことでした。多くの現場担当者は長年培われた経験や勘を頼りに業務を遂行しており、既存の業務プロセスに特段の課題を感じていませんでした。「今までもうまくいっているのだから」という意識が強く、変革の必要性を実感できていなかったのです。 この状況を打開するためには、データ活用によって得られる具体的なメリットを現場レベルで理解してもらう必要がありました。更に、データを活用して業務改善に取り組むモチベーションを喚起し、継続的な改善に取り組む文化を醸成することが求められていました。 (2) データ分析スキルの取得(ハードスキル) もちろん、データ活用に対する意欲を持つ社員は一定数存在しています。しかし、自身の業務に課題を感じ、改善意欲を持つ担当者がいても、普段の業務に求められるスキルセットと、データ分析に必要なスキルセットとの間には大きな乖離があります。製造現場や営業部門など、それぞれの専門分野では高い能力を持つ社員でも、データ分析については未経験であることがほとんどでした。 この問題を解決するためには、データ分析について基礎から体系的に学ぶ機会を提供することが不可欠でした。担当者一人ひとりが、自らの業務課題とデータ活用を結びつけられるよう、机上の知識の取得するだけでなく、実践的なスキルを習得できるプログラムを構築することが求められていました。 (3) QuickSightの認知度向上(ツール) 業務部門の中でも、一部の部門はデータからレポートを作成する業務を担っていましたが、そういった部署においてもデータ活用は進んでいませんでした。データ分析ツールとしてQuickSightが導入されていたにもかかわらず、従来と変わらずExcel等の表計算ソフトを用いて手作業でレポートを作成していました。 こうした状況の背景には、BIツールの提供する価値や機能が十分に理解されていないという問題がありました。多くの社員はBIツールを「難しい専門家向けのシステム」と捉え、自分たちの業務とは関係ないものだと認識していました。 この問題を解決するためには、まずBIツールを活用するメリットを実感してもらう必要がありました。また、自部門の業務に直結するユースケースを示し、ツールの基本的な操作方法を習得してもらうことで、「自分たちにも使える」という認識を持ってもらうことが重要でした。 目指すべき姿と自社にカスタマイズされた教育プログラムの開発 レンゴーの中期経営計画においても、DXによる価値創出が重要な戦略として位置づけられていました。この目標を実現するためには、組織全体でデータ活用の文化を醸成し、個々の社員が目的意識を持ってデータを活用し、業務改善に取り組む体制になっていることが必要不可欠です。 図1 デジタイゼーション・デジタライゼーションとデジタルトランスフォーメーション(DX) しかし、前述した「ソフトスキル」、「ハードスキル」、「ツール」の三つの課題を解決するためのノウハウは社内にありませんでした。そこで私たちは、AWSが提供している無償の データ活用ワークショッププログラム に着目し、これをベースとして研修プログラムを作成することを検討しました。しかし、AWS の担当者からプログラムの内容をヒアリングする中でプログラムを適用するだけでは、人手とコンテンツのカスタマイズ性の面で、当社特有の課題に対応できない可能性があることがわかりました。そこで、データ活用に対して専門知識を持つパートナー企業を交え、3社共同で研修プログラムの開発に取り組むことを決断しました。そして、研修を前述した3つの課題に対し、それぞれの会社が強みを発揮できる内容に構成しました。 (1) Working Backwards を使用した課題解決手法の習得(ソフトスキル) 研修プログラムの核となる特徴として、Amazonが社内で実践している課題解決のフレームワーク「Working Backwards」を取り入れました。この手法は、目標から逆算して必要なステップを明確化するアプローチで、データ活用においても非常に効果的です。その際、架空のシナリオではなく、現実の課題を題材とすることで、研修の実効性を高めることを目指しました。研修の中で参加者が自部門で実際に直面している課題を題材とし、その課題を解決するために最適なダッシュボードがどのようなものかを検討します。そして、研修期間内に、QuickSightでダッシュボードを作成するところまで実践します。 このアプローチを取ることで、参加者は、課題解決のプロセスを体系的に学ぶことができるだけでなく、データ分析の有用性を体感できます。そして、研修終了時には、明日から実務で使える具体的な成果物を持ち帰ることができるため、学びを即座に実践に移す橋渡しとなります。 (2) データ分析関連の知識を網羅的に学ぶことができるコンテンツの開発(ハードスキル) 初学者でもついていけるような研修プログラムを設計する為、私たちはJSOLに協力を依頼しました。JSOLを選定した理由は主に二つあります。一つ目は、同社が データ活用支援 において豊富な実績を持っていたことです。そして、二つ目の理由は、レンゴーの汎用データ基盤の構築をJSOLが担当していたという点です。データの構造や特性を熟知しているパートナーであれば、より実践的な研修内容を構築できると考えました。 そして、JSOL主導で統計学の基礎知識から始まり、データ分析の手法、そして効果的なダッシュボードデザインの実践に至るまで、データ分析プロセス全体を網羅する包括的な研修コンテンツを作成しました。このコンテンツを設計する際に意識したことは、①「データ分析の経験がまったくない社員でも無理なく参加できること」と、②「データ分析に必要な知識を網羅的に習得できること」の2つです。単なる概念理解にとどまらず、実務で即座に活用できる知識の習得を重視しました。 (3) 実データを使用したQuickSightハンズオンの実施(ツール) レンゴーではコスト効率の高さとAWS環境との親和性を評価し、Amazon QuickSightをBIツールとして導入してます。ダッシュボードを作成する為には、受講者にQuickSightのスキルを習得してもらう必要がありました。そこで、架空のデータではなく、レンゴー社内に実際に蓄積されている業務データを活用することにこだわりハンズオンコンテンツを作成しました。また、ハンズオン手順書についても、初心者が躓きやすいポイントを予測し、詳細な操作ガイドと補足説明を作成するなど、レンゴー社員の視点から理解しやすいコンテンツ作成を意識しました。 このアプローチには二つの重要な狙いがありました。一つ目は、参加者に「実際の業務でどのようにデータを活用するか」の具体的なイメージを掴んでもらうことで、二つ目が新たに必要なデータセットが生じた際に、情報システム部門に相談する方法を知ってもらうことです。データ分析をしたいが「誰に相談すればいいのかわからない」という心理的障壁を取り除くことを目指しました。 全社に向けてデータ活用研修を開催 今回開発した研修プログラムを、2024年11月から2025年1月の3ヶ月間にわたり、東京と大阪の2会場で開催しました。そして、計6日間のカリキュラムに、異なる業務部門から20人が参加しました。この6日間の内訳について掘り下げて説明します。 図2 研修の様子 (1) データ分析の基礎固め 最初の2日間では、統計学の基礎知識やAmazonの「Working Backwards」の学習、そして基本的なQuickSightのハンズオンを通じて、データ分析の土台を固めました。加えて、2日目が終了した時点で、参加者に対し「自部門が抱える実際の課題」を見つけてくるという宿題を課しました。 図 3 研修に使用したコンテンツ (2) 実業務に直結するダッシュボードイメージ作成 3日目は、各参加者が持ち寄った業務課題に対して議論を展開しました。課題の本質を掘り下げた上で、課題を解決するためのダッシュボードを手書きで作成しました。この作業を通して、効果的な可視化方法等をダッシュボード設計の基本原則を実践を通して学んでもらいました。 図 4 ダッシュボード作成ワークショップ (3) QuickSightを使用したダッシュボード作成 4日目と5日目は、手書きで設計したダッシュボードイメージをAmazon QuickSightを使用したインタラクティブなダッシュボードへと具現化する作業に取り組みました。その際、質問をリアルタイムで受け付ける体制を取り、参加者の疑問をその場で解消するよう努めました。 図 5 ダッシュボードイメージ (4) 成果報告会 研修の集大成として6日目には、各部門の上席者を招いた成果報告会を開催しました。参加者が自らが特定した業務課題と課題を解決するために作成したダッシュボードについて発表を行い、自部門の上長に対し成果を共有しました。この報告会は、学びの成果を組織全体に波及させる重要な機会となりました。 図 6 成果報告会の様子 研修がもたらした組織変革の兆し 研修終了時には、研修に参加した20人全員が、自部門の課題解決に直結する実用的なダッシュボードを完成させました。基礎から体系的に学べるカリキュラムにしたことで、6日間という長期間かつ高密度の研修にもかかわらず、一人のリタイアも出しませんでした。さらに喜ばしいことに、研修終了後も社内にデータ活用の土壌が着実に育ちつつあります。具体的には次の3つの成果を得る事ができました。 (1) 参加者主導によるダッシュボードの全国展開 研修プログラムの最も顕著な成果として、参加者が自部門でのデータ活用の推進役となり、実際の業務改善に直結するダッシュボードが全国展開という事例が挙げられます。特に注目すべきは「取り組み状況検索」と名付けられた分析ダッシュボードの開発と普及です。このダッシュボードは、これまで各営業担当者が個別に時間をかけて調査・集計していた情報を一元的に可視化し、即座にアクセスできるようにしたものです。この成功事例は、当初私たちが懸念していた「研修で終わり」という状況に陥らなかったことを如実に示しています。この研修の主要な狙いの一つであった「データを活用する土壌の醸成」が実際に起こった結果だと認識しています。 (2) QuickSight ユーザーの増加 研修プログラムの効果は、具体的な数字としても明確に表れています。研修終了から3ヶ月という短期間のうちに、Amazon QuickSightのAuthor権限(ダッシュボードを自ら作成・編集できる権限)を持つユーザーが100名以上も増加しました。この数字は、単なるツール導入の成功を超え、「自らデータを分析し、可視化する」という行動変容が組織内で広がりつつあることを示しています。また、来期以降も同研修を実施する予定であることを踏まえると、この増加傾向が一時的なものではなく、今後も継続して拡大していく見込みです。 (3) データ収集・蓄積依頼の増加 研修終了後には、データ活用の基盤となるデータの収集・蓄積プロセスにおいても、変化が見られています。これまでレンゴーでは、情報システム部門が主導して「重要と思われるデータ」を特定し、業務部門に対してその活用を提案するという「プッシュ型」のアプローチが一般的でした。しかし研修実施後、この流れは完全に逆転し、業務部門から情報システム部門へのデータ収集依頼が殺到するという「プル型」の状況へと変化しました。現在では、情報システム部門が全てに対応しきれないほどの要件が寄せられており、業務部門と綿密な対話を重ねながら優先度を設定し、段階的に対応を進めている状況です。この変化は、データ活用の価値が業務部門に深く理解され、自らの業務課題解決のためにデータを積極的に活用しようという意識が広がった結果だと言えるでしょう。 これまでに述べた様々な成果から、レンゴー社内においてデータ活用を行う文化が着実に醸成されつつあると判断しています。しかし、私たちはこれを通過点に過ぎないと認識しています。真のデータドリブン組織への変革は一朝一夕に成し遂げられるものではなく、継続的な取り組みが不可欠です。そのため、今回紹介した研修プログラムは単発の施策ではなく、来期以降も継続して実施していく予定です。この活動を継続・拡大していくことで、レンゴー全体のデータ活用促進とDX推進をさらに加速させ、中期経営計画で掲げたDXによる価値創出の実現に向けて着実に前進していきます。 まとめ 本稿では、レンゴーがデータ活用を全社的に拡大するために取り組んだ包括的なアプローチについてご紹介しました。データ駆動組織を作るためには、「ソフトスキル」「ハードスキル」「ツール」という3つの要素全てを同時に、そして継続的に推し進めることが必要です。この認識のもと、私たちはAWSとパートナー企業であるJSOLの協力を得て、三つの観点を網羅する包括的な研修プログラムを構築しました。私たちの取り組みはまだ始まったばかりですが、すでに具体的な成果が表れ始めています。この経験が、同様の課題に直面している他の企業の皆様にとって、データドリブン経営への道筋を考える一助となれば幸いです。 図 7 社内広報(表紙) 著者について レンゴー株式会社 情報システム本部 情報システム第一部 課長代理 平田 匡人(Tadahito Hirata) SIer、事業会社にてシステム企画構想から運用保守まで約15年従事。特にアフターサービス分野、グローバルシステム構築に強みを持つ。現在は、段ボール・紙器・軟包装事業の基幹システム運用保守とDX案件に従事。データ分析分野においては、データ分析人材育成のプロジェクトリーダーとして推進している。
映画スタジオのように、膨大な量のビデオファイル、スクリプト、アニメーションアセットを扱う会社を想像してみてください。これらのファイルは Amazon FSx for Lustre などの高性能ファイルシステムに格納されます。Amazon FSx for Lustre は、世界で最も普及している高性能ファイルシステム上に構築された完全マネージド型の共有ストレージです。各ファイルには POSIX 情報などのメタデータがあります。スタジオのプロジェクトが増えるにつれて、ファイルやディレクトリの数も増えます。ファイルの検索や、ファイルへのアクセス、ディレクトリ内の一覧表示を実施する必要がある場合、システムはこのメタデータをすばやく取得して管理する必要があります。しかしながら、従来のファイルシステムでは、ファイル数が特に数百万または数十億に増加すると、メタデータ操作が大幅に遅くなる可能性があります。この速度低下がボトルネックとなり、ファイルの取得が遅れ、チームの生産性が低下する可能性があります。これは、厳しい締め切りの中で作業する場合に非常に重要です。 FSx for Lustre は、CPU と GPU を最大容量で使用し続け、TB/秒のスループットと数百万 IOPS に達する高速ストレージを必要とするアプリケーション向けに設計されています。何千ものコンピューティングインスタンスから同じファイルやディレクトリへ同時アクセスをサポートしながら、ファイル操作において一貫性のあるミリ秒未満のレイテンシーを提供することは、多くのワークロードを実現に結びつきます。FSx for Lustre は、 図 1 に示すようにオブジェクトストレージサーバ (OSS) を使用して複数のノードにファイルを分散します。そのため、ストレージ容量とスループットのバランスをとるために、各読み取りまたは書き込み操作はクラスター全体で並列化されます。FSx for Lustre は専用のメタデータサーバ (MDS) を使用してメタデータ操作をサポートします。 図 1. スケーラブルなメタデータ機能以前の FSx for Lustre 構成図 ファイルシステムのメタデータパフォーマンスは、ファイルシステムが 1 秒あたりに作成、一覧表示、読み取り、削除できるファイルやディレクトリの数を決定します。メタデータを集中的に使用するワークロードでは、多数の小さなファイルの作成、処理、操作が必要となることが多くあります。FSx for Lustre は、プロビジョニングされたストレージ容量に基づいて、デフォルトのメタデータパフォーマンスレベルを自動的に提供します。スケーラブルなメタデータ機能がリリースされる以前は、デフォルトよりも多くのメタデータ操作を必要とするユーザーは、より大きなファイルシステムを作成するか、データを複数のファイルシステムに分割する必要がありました。スケール可能なメタデータのリリースにより、ユーザーはプロビジョニングされたストレージとは独立して、利用可能なメタデータ IOPS を最大 15 倍まで増やすことができるようになりました。これにより、最もメタデータを集中的に使用するワークロードでも利用が可能になります。さらに、この機能は 図 2 に示すように、ファイルシステムの作成時に有効にすることも、ファイルシステムの作成後に有効にすることも可能で、特定のファイルシステムに対してメタデータ操作専用の IOPS の量を増やすことができます。 図 2. スケーラブルなメタデータ機能を備えた FSx for Lustre 構成図 ワークロードやユースケース この新機能により、データ管理が合理化され、機械学習(ML)、電子設計自動化(EDA)、財務分析リスクシミュレーションなど、メタデータを多用するワークロードを必要とするユースケースの効率が向上します。EDA における基礎設計や、研究者がプロジェクト作成中にデータセットの名前を変更するといった作業負荷は、メタデータを多用する性質上、ファイルシステムに大きな負荷をかけます。 MDTest を使用してこれらの操作の上限をテストできます。 メタデータパフォーマンス 特定のワークロードに FSx for Lustre ファイルシステムを導入するには、パフォーマンスを最適化する上でメタデータ IOPS がどのように重要な役割を果たすかを理解する必要があります。 図 3a に示すように、自動モードの FSx for Lustre はファイルシステムのストレージ容量に基づいてメタデータ IOPS を自動的に割り当てるため、プロセスが簡素化されます。このアプローチでは、IOPS の数とストレージのサイズが相関関係にあるため、手動で調整しなくても大半のワークロードで適切なレベルのパフォーマンスが得られます。たとえば、1,200 GiB のストレージを備えたファイルシステムは自動的に 1,500 のメタデータ IOPS を受け取りますが、大規模なシステムでは 12,000 GiB を超える容量の場合、最大 12,000 メタデータ IOPS にスケールアップします。 一方、 ユーザープロビジョニングモード では、よりきめ細かい制御が可能です。ストレージ容量に関係なく、必要なメタデータ IOPS の正確な値を手動で指定できます。このモードは、自動モードでは対応しきれないメタデータ IOPS を要するワークロードに適しています。 図 3a. ファイルシステムのメタデータパフォーマンス FSx for Lustre は、 図 3b に示すように、ファイルの作成、削除、ディレクトリ操作などにメタデータ操作を分類し、それぞれ 1 秒あたりの処理レートが異なります。これは、数百万にも及ぶファイルシステムの IOPS とは異なります。たとえば、ファイル削除の操作はプロビジョニングされた IOPS ごとの 1 秒あたりの処理レートが 1 であるのに対し、ファイル作成やファイルを開く操作は 1 秒あたりの処理レートが 2 となります。プロビジョニングされた IOPS の値を、ワークロードが必要とする特定の種類の操作に合わせれば、FSx for Lustre はメタデータを効率的に処理できるようになります。この最適化は、ファイルシステム全体のパフォーマンスを向上させるだけでなく、ストレージや運用上のニーズの拡大に応じたスケーラビリティもサポートします。 図 3b. ファイルシステムのメタデータパフォーマンス 前提条件 この操作手順では、次の前提条件を満たす必要があります。 AWS アカウント FSx for Lustre ファイルシステムの作成および変更 Slurm を利用した既存の AWS ParallelCluster の使用 AWS ParallelCluster での Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの作成 Lustre クライアントのチューニングに関する理解 Linux コマンドラインの実践的な知識 Amazon CloudWatch ダッシュボードの作成 メタデータパフォーマンスの設定方法 新しい FSx for Lustre ファイルシステムを作成する場合、 図 4a に示すように、メタデータパフォーマンスを自動モードとして定義する新しいオプションがあります。この場合、IOPS はファイルシステムの容量 (24 TiB のストレージあたり 12,000 メタデータ IOPS) に基づいて自動的に定義されます。または、 図 4b に示すように、ユーザープロビジョニングモードとして定義することもできます。この場合、ユーザーはメタデータ IOPS の値に 1,500、3,000、6,000、あるいは 192,000 メタデータ IOPS までの 12,000 の倍数を指定できます。ユーザーは、 AWS マネジメントコンソール 、 AWS Command Line Interface (AWS CLI), 、または AWS Software Development Kits (SDKs) を使用して、メタデータパフォーマンスを向上させる機能を持った FSx for Lustre ファイルシステムを作成できます。 図 4a. メタデータ設定の自動モード 図 4b. メタデータ設定のユーザープロビジョニングモード テストの実行 このセクションの目標は、さまざまなワークロードシナリオにおける標準のメタデータ設定とスケールされたメタデータ設定のメタデータパフォーマンスを比較することです。また、これらのテストをお客様の AWS アカウントで再現する手順についても説明します。 図 5 は、コンソールで作成されたファイルシステムの例を示しています。この特定のファイルシステムは 12 TiB のストレージで構成されており、1,500 MB/秒のスループット (125 MB/秒) と 192,000 のメタデータ IOPS を実現しています。この構成は、スループット要件は低くメタデータ操作が集中するアプリケーション向けに調整されています。 図 5. 192,000 メタデータ IOPS で作成されたファイルシステム このテストシナリオでは、2 組の大規模ファイルシステムを作成しました。いずれも P250 と P1000 のスループット構成で、一方はスケールされたメタデータを持たないサイズが 12 TiB のファイルシステム、もう一方は 192,000 IOPS のスケールされたメタデータを持つサイズが 12 TiB のファイルシステムです。 AWS ParallelCluster を使用して、この HPC ベンチマークを実行するためのクラスターを構築しました。以下の設定の c5.9xlarge インスタンスタイプのクライアント EC2 インスタンスが 200 個あります。 Instance type: c5.9xlarge Operating Systems: Amazon Linux 2 Linux Kernel: 5.10.219-208.866.amzn2.x86_64 mpi version: Open MPI 4.1.6 lustre version: 2.12.8_198_gde6dd89_dirty ENA driver: 2.12.0g Ranks for job: 800 ParallelCluster: 3.10.1 Lustre クライアント側のパラメータ sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50 sudo lctl set_param osc.*.max_dirty_mb=64 Lustre パフォーマンス設定の詳細については、 FSx for Lustre パフォーマンスガイド とオンラインの Lustre ドキュメント を詳しく調べてください。 テストツールとして、このシナリオではオープンソースの MDTest を使用してメタデータの I/O シミュレーションを行います。 MDTest のインストールと実行 次のコマンドは、OpenMPI ライブラリとコンパイラを使用してユーザーの PATH と LD_LIBRARY_PATH で実行しました。 $ git clone https://github.com/hpc/ior.git $ cd ior $ ./bootstrap $ ./configure --prefix=/opt/parallelcluster/shared $ make all $ make install この時点で、トラブルシューティングを行ったり、テストを積極的に監視したりしたい場合に備えて、MDTest を起動するためのインタラクティブジョブを実行しています。 $ srun --nodes=200 --ntasks-per-node=32 --time=12:00:00 --pty bash -i EC2 インスタンスが利用可能になった時点で、そのテストを実施するために、自分の UID がフルアクセス権限を持つサブディレクトリを作成しました。 (例) $ sudo mkdir -p /fsx/mdTestFiles $ chown 1000:1000 /fsx/mdTestFiles 次に、ジョブを実行します。このジョブは 3 回繰り返され、ワークロードの平均を確認できます。 $ mpirun --mca plm_rsh_num_concurrent 800 --mca routed_radix 800 --mca routed direct --map-by node --mca btl_tcp_if_include eth0 -np 800 /opt/parallelcluster/shared/bin/mdtest -F -v -n 4000 -i 3 -u -d /fsx/mdtestFiles MDTest オプションの説明 : -F: ファイルのみでテストを実行 (ディレクトリを含まない) -v: 詳細出力 -n 4000: ランクごとに create/stat/read/remove を行うディレクトリやファイルの数 -i 3: テストを実行する反復回数 -u: 各ランクに固有の作業ディレクトリ -d: ジョブのルートディレクトリ 図 6 は単一メタデータターゲット (MDT) を持つ 12 TiB のファイルシステムで実行された最初のジョブの出力例を示しています。 図 6. MDTest 実行時の出力例 このセクションでは、先の図における単一メタデータターゲット (MDT) 12 TiB の FSx for Lustre ファイルシステムの最初のテストで確認されたことを詳しく説明します。ファイル作成 (create) は、1 つのプロセスイベントで 1 ファイルずつ作成されます。これは小さな書き込みワークロードと解釈できます。統計 (stat) の観点から見ると、これは Lustre にとってコストのかかる操作になる可能性があり、ツリーウォークや大規模な “ls -l” がどのように動作するかを表しています。ファイルの読み取り (read) は読み取りワークロードであり、ファイルの削除 (remove) はファイルシステムからファイルを完全に消去することです。メタデータサーバへの負荷は、イベントごとに異なります。 図 7 はクライアントの数とキャパシティを同じ条件に保ちながら、異なるファイルシステムタイプで実施した複数回の実行結果を包括的にまとめた表になります。 図 7. MDTest の結果 上の表は、それぞれメタデータ IOPS が 12,000 と 192,000 のファイルシステムのパフォーマンスの違いを示しています。パフォーマンスの違いは操作タイプに関連しており、メタデータ IOPS が高いほどすべてのテストで改善が見られます。ワークロードの要件によって FSx for Lustre のメタデータ IOPS を高める明確な方法があります。 ファイルシステムのメタデータメトリクスの監視 ファイルシステムの稼働時には、CloudWatch メトリクスを使用してメタデータのパフォーマンスを監視し、増加するワークロード要件に対応するため、必要に応じてパフォーマンスをスケールアップすることができます。FSx for Lustre の監視は、システムの安定性を維持し、発生する可能性のある問題に迅速に対処するために不可欠です。CloudWatch は監視の中心的なツールとして機能し、FSx for Lustre からリアルタイムのメトリクスを継続的に収集して処理します。CloudWatch アラームを設定すると、異常時やパフォーマンスのしきい値に超えたときに、管理者は Amazon Simple Notification Service (Amazon SNS) を通じて即座に通知を受け取ることができ、潜在的な問題を軽減するための対応が可能になります。 FSx for Lustre は、デフォルトで 1 分間隔でメトリクスデータを CloudWatch に自動的に送信し、これらのメトリクスは raw バイトで報告されます。CloudWatch とその機能の詳細については、 CloudWatch ユーザーガイド を参照してください。 FSx for Lustre は、そのメトリクスを CloudWatch の FSx 名前空間に発行します。新しいスケーラブルメタデータ機能により、 図 8a、8b、8c に示すような 新しいメトリクス を利用して、メタデータ操作の詳細を確認できるようになりました。新しいメトリクスには DiskReadOperations や DiskWriteOperations 、 FileCreateOperations 、 FileOpenOperations 、 FileDeleteOperations 、 StatOperations 、 RenameOperations があります。これらのメトリクスからより詳細なデータが利用可能になるため、 FileSystemID (特定のファイルシステム用) と StorageTargetID (特定の MDT – メタデータターゲット用) を使用してデータを絞り込むことができます。 図 8a. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8b. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8c. CloudWatch ダッシュボードにおける新しいメタデータメトリクス FSx for Lustre のスケーラブルなメタデータ用の AWS CloudFormation テンプレートをダウンロードするにはこちらを利用してください : 料金 このソリューションを試す場合、費用が発生します。このソリューションでは EC2 インスタンス、FSx for Lustre ファイルシステム、および CloudWatch ダッシュボードを実行しています。 料金の詳細は、 FSx for Lustre 、 EC2 インスタンス 、および CloudWatch の料金ページで確認できます。 クリーンアップ 今後の確認に備えて、必要なすべてのパフォーマンスの実行をバックアップします。 FSx for Lustre ファイルシステムと関連するコンピューターリソースを削除して、そのプロジェクトの課金を終了してください。CloudFormation ページよりダッシュボードを削除して、アカウントから削除してください。 必要に応じて ParallelCluster を管理してください。コストを節約するために、不要になったら削除してください。 まとめ この新機能の影響は広範囲に及び、特に要求の厳しい AI/ML や HPC ワークロードを実行している組織にとって重要です。これらのワークロードでは、多くの場合、膨大な数の小さなファイルの作成、処理、操作が行われ、メタデータパフォーマンスに大きな負荷がかかります。Amazon FSx for Lustre ではメタデータパフォーマンスをスケールすることで、ユーザーはワークロードを 1 つのファイルシステムに統合できます。これは、ワークロードを分割せずにワークロードをより大規模に実行すること、メタデータパフォーマンスを容易に向上させ変化するパフォーマンス要件に適応すること、メタデータパフォーマンスをストレージ容量から切り離してリソースの使用を最適化することで実現されます。 このブログは 2025 年 2 月 21 日に Tom McDonald (Senior Workload Storage Specialist) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの奥野が担当しました。 <!-- '"` --> TAGS: Amazon FSx for Lustre , AWS Cloud Storage , High-Performance Computing (HPC) , machine learning Tom McDonald Tom McDonald は AWS の Senior Workload Storage Specialist です。Atari 400 やテープの再プログラミングから始まり、Tom はあらゆるストレージサービスのパフォーマンス向上に長年関心を持ち続けてきました。資源開発分野でファイルシステムや高性能コンピューティングの 20 年以上の経験を持つ Tom は、コミュニティやガイダンスを通して多くの方を支援することに情熱を持っています。
AWS の生成 AI コスト最適化に関する全 5 回構成 シリーズ の 4 回目のブログでは、前回までの議論を踏まえて AWS の生成 AI を活用したアシスタントである Amazon Q の価値を最大化することに焦点を当てます。以前の記事では、 Amazon EC2 と SageMaker AI による AI モデル構築のコスト最適化 と Amazon Bedrock で基盤モデルを使用する際のコスト最適化 について説明しましたが、今回は Amazon Q を利用する際のコスト最適化戦略を探ります。適切な料金プランの選択、戦略的ユーザー管理の実装から、コンテンツのインデックス作成の最適化やコスト予測可能性の向上まで、機能性とコスト効率のバランスを取るのに役立つ実践的なアプローチを紹介します。生成 AI を活用したアシスタントとして Amazon Q Business を使用する場合でも、開発者の生産性を高めるために Amazon Q Developer を使用する場合でも、これらのベストプラクティスは、Q の利用について情報に基づいた意思決定を行うのに役立ちます。 Amazon Q を理解する: Business と Developer Amazon Q Business は、情報の検索、コンテンツの生成、およびタスクの自動化を支援するように設計された AI 搭載アシスタントです。利点として、迅速な対応による生産性の向上、コンテキストを踏まえた回答、安全なデータアクセスによる意思決定の強化やビジネスツールとのシームレスな統合などがあります。生成 AI のニーズに応えて Amazon Q Business を採用するケースが増えるにつれ、投資収益率(ROI)を最大化するには、コスト最適化戦略を理解することが重要になります。 Amazon Q Developer は、リアルタイムのコード提案システムと自動タスク実行を通じてソフトウェア開発を促進し、生産性の向上と開発期間の短縮を実現しています。このツールにより、開発ライフサイクル全体にわたる迅速なオンボーディング、コード品質の向上やセキュリティ統合が可能になります。Amazon Q Developer は、あらゆる規模のビジネスに対応できるようにユーザー単位の価格を設定しており、JetBrains、VS Code、Visual Studio や Eclipse などの IDE と統合できます。Amazon Q Developer について言えば、先日、私たちはコスト最適化の機会を見つけるのに役立つ魅力的な新しいコスト最適化推奨機能を発表しました。この機能は、自然言語での会話を通じ、インスタンスのライトサイジング、Savings Plans やリザーブドインスタンスの購入やアイドル状態のリソースの終了などのコスト最適化の機会を見つけるのに役立ちます。これは、コードの作成中にリソースの使用を最適化し、コストを最適化するための効率的な方法となります。 図 1. Amazon Q によるコスト最適化分析 それでは、メイントピックである Amazon Q のコストを最適化するための実践的なヒントに戻りましょう。 料金プランの選択 始めに決めることは、適切な料金プランを選択することです。Amazon Q Business には、Amazon Q Business Lite と Amazon Q Business Pro の 2 つの料金プランがあります。 Amazon Q Business の料金 をご覧ください。ビジネス要件に合わせてプランを慎重に選択することで、最大 85% のコスト削減を実現できます。Amazon Q Business Lite の料金は、ユーザー 1 人につき 1 か月あたり $3 です。安全なデータアクセスや権限に応じた応答などの基本機能を提供します。応答の最大サイズは 1 ページまでとなります。(訳注:1 ページのサイズは ドキュメント 参照)Amazon Q Business Pro は、ユーザー 1 人につき 1 か月あたり $20 です。すべての Amazon Q Business Lite 機能に加えて、Amazon Q Apps、コンテンツ作成ツールや最大 7 ページの長い応答が含まれます。Amazon Q Business Pro のユーザーは、Q in QuickSight (Reader Pro) を使用して構造化データに関するインサイトを得たり、一般的なサードパーティアプリ用のカスタムプラグインやマネージドプラグインを使用したり、画像ベースの応答を受け取ったりすることもできます。 Amazon Q Business 料金プランの変更 Amazon Q Developer にも、Amazon Q Developer 無料利用枠と Amazon Q Developer Pro の 2 つの料金プランがあります。 Amazon Q Developer の料金 をご覧ください。無料利用枠では、Amazon Q Developer を簡単に使い始めることができます。無料利用枠には、コードの提案、CLI の補完、CLI の統合がありますが、 高度な機能への 1 ヶ月あたりのアクセスが制限されています。Amazon Q Developer Pro は 1 か月あたり $19 で、無料利用枠のすべての機能に加えて、エンタープライズアクセス制御、コードベースのカスタマイズやクエリ作成、コード変換などの高度な機能に対する制限の緩和が含まれます。 料金プランの決定は、より高い料金プランを無条件で選択するのではなく、ユースケースとユーザーニーズを分析して決定する必要があります。これにより、ユーザーが実際に利用する機能に見合った料金プランとなるためコスト効率を維持できます。 戦略的ユーザー管理 Amazon Q Business と Amazon Q Developer のユーザーアクセスを管理することは、コストの最適化と業務の効率化にとって非常に重要です。これは、サービスの料金がユーザーごとに設定されているためです。厳格なユーザー管理手法を導入することで、その機能を本当に必要とするユーザーだけがアクセスできるようにし、非アクティブなユーザーやたまにしか使用しないユーザーによる不必要なライセンスコストを防ぐことができます。ユーザーアカウントを定期的に監査し、離職したユーザーのアクセス権を削除し、使用パターンが最小限であるユーザーにはライセンスの必要性を再評価する必要があります。さらに、ユーザーを役割とニーズに基づいて適切な権限階層とグループに分割することで、データアクセスをより適切に制御し、セキュリティコンプライアンスを維持し、リソースの浪費を防ぐことができます。ユーザー管理に対するこの戦略的なアプローチは、ユーザーのコストを削減するだけでなく、サービスの使用状況をより適切に監視するのにも役立ちます。 コンテンツインデックスの最適化 Amazon Q Business は、データソースの接続による検索拡張生成(RAG)をサポートしています。 Amazon Q Business データソースの接続 を参照してください。インデックス作成プロセスは単位時間ごとの料金設定で、1 つのアベイラビリティーゾーンのスターターインデックスを作成するか、3 つのアベイラビリティーゾーンにまたがってエンタープライズインデックスを作成できます。インデックス作成の時間と頻度を最小限に抑えることは、インデックス作成コストにプラスの影響を与えます。インデックス費用の例については、 Amazon Q Business の料金ページ の「価格設定の例」セクションの例 3 から 5 を参照してください。インデックス作成コストを管理するうえで重要な 2 つの手段は、「同期モード」と「同期実行スケジュール」です。 同期モードには 2 つのオプションがあります。「Full sync」 を選択すると、Amazon Q は以前の同期ステータスに関係なく、すべてのコンテンツを同期してインデックスを作成します。「New, modified, or deleted content sync」を選択すると、Amazon Q は新規、変更、削除されたコンテンツのみを同期します。データを段階的に追加または変更する場合は、コストを最小限に抑えるために 「New, modified, or deleted content sync」 を選択する必要があります。データソースに大きな変更を加える必要がある場合は、「Full sync」 を選択して同期を 1 回実行するとよいでしょう。その後、「New, modified, or deleted content sync」に戻す必要があります。 「「Sync run schedule」では、インデックス作成の頻度を設定できます。選択できる項目は、時間単位、日単位、週単位、月単位、またはカスタム(cron 式)です。接続されているデータソースが更新される頻度と、ソリューションに必要なデータのインデックス作成頻度に基づいて、インデックス作成頻度を最適化する必要があります。この設定の実行頻度が高すぎると、予期しないコストが発生する可能性があります。 結論 Amazon Q Business と Amazon Q Developer の最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できます。この予測可能性とフルマネージド型のサービスを組み合わせることで、インフラストラクチャの管理を気にすることなく価値の提供に集中できます。 ここまで、料金プランの選択、ユーザー管理やコンテンツインデックスの最適化を通じて、Amazon Q Business と Amazon Q Developer のコストを最適化するための主な要素について説明してきました。次回のブログでは、AI ソリューションと連動するサービス (ストレージ、ベクトルデータベース、データ転送やレポート) のコスト最適化戦略について説明します。費用対効果が高くスケーラブルな AI アプリケーションを構築するための重要なインサイトをお見逃しなく。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。
コンタクトセンターにおける予期せぬサービス中断は、深刻な影響を及ぼす可能性があります。エージェントがシステムにアクセスできない、顧客が接続の問題に直面する、そしてサポートチームがサービスの迅速な復旧に追われることになります。このようなシナリオは極端に思えるかもしれませんが、現代のコンタクトセンター運営においては、このような状況に対する机上演習が不可欠です。 このブログ記事では、Amazon Web Services (AWS) が提供する AI を活用したクラウドコンタクトセンターソリューション、 Amazon Connect 向けのいくつかの机上演習を紹介します。これらは、コンタクトセンターの移行に際しての様々なシナリオの確認や、予期せぬ事態に備えたプロセスと手順の更新に役立つはずです。 机上演習とは 机上演習は、企業規模を問わず重要な取り組みです。机上演習は、サイバー攻撃、自然災害、システム障害などの危機に対する対応計画をテストでき、体系的に管理された環境を構築するのに役立ちます。演習では、企業のシニアエグゼクティブ、部門長、危機管理チームなどの主要な利害関係者が参加し、戦略的な議論と意思決定プロセスに関わることが必要です。潜在的な脅威や混乱に対処する訓練を通して、企業は緊急時対応手順の不足やずれを特定し、コミュニケーションや連携を改善、実際の事態が発生した際の各チームの役割をしっかりと理解することができます。 また、机上演習は組織のリスク管理戦略を改善し、組織のレジリエンスを高め、予期せぬ課題に直面した際に、自信をもって迅速かつ効果的に対応する能力を構築し、最終的には企業の業務継続と評判を保護することに役立ちます。 1) Amazon Connect サービスの中断 シナリオ : Amazon Connect で一時的なサービス停止が発生し、特定のリージョンでコンタクトセンターでの通話の発信や受信ができなくなりました。顧客がサポートエージェントに連絡できず、エージェントも通話を処理するためのシステムにアクセスできません。 主な方針 : 事象が自身の Amazon Connect インスタンスに限定されているのか、複数のリージョンに影響しているのかを確認します AWS PHD でサービスの問題を確認します CloudWatch メトリクス を使用して、潜在的な原因(接続性の問題、API 制限など)を調査します エンドユーザーとステークホルダーに対して、停止の状況と復旧予想時間を通知する方法を決定します 代替システムへの通話の転送や、異なるリージョンの使用など、回避策を実施します 2) 品質低下または遅延発生 シナリオ : 顧客通話の一部で高い遅延と音声品質の低下が発生し、顧客体験の悪化につながっています。この問題は、特定の地域のエージェントと顧客との間の通話に影響を与えているようです。 主な方針 : Amazon Connect の音声メトリクスと Amazon CloudWatch を使用してネットワークパフォーマンスを調査します SIP トランキングや電話統合など、関係する第三者システムの状態を確認します 問題が地域のインフラまたはネットワーク輻輳に関連しているかを特定します Amazon Connect Voice Analytics ツールや CloudWatch Logs などの診断ツールを使用して音声品質をテストします AWS サポートに連絡する際、サポートのトラブルシューティングに役立つよう、 HAR ファイル/コンソールログを準備します(参照: https://repost.aws/ja/knowledge-center/support-case-browser-har-file ) 3) コンタクトフローの設定ミス シナリオ : 新しく更新されたコンタクトフローにより、顧客が正しい部署にルーティングされない状況が発生しています。意図したエージェントにつながらず、顧客との接続が切断されたり、誤ったキューに転送されたりしています。 主な方針 : CloudWatch メトリクス で「ContactFlowErrors」と「ContactFlowFatalErrors」を確認します 影響を受けたコンタクトを特定し、 CloudWatch のコンタクトフローログでエラーに関する詳細情報を確認します コンタクトフローを確認し、設定ミス(不適切な条件、誤ったキューへのルーティングなど)を特定します 設定変更が問題の原因である場合、機能を復旧するためのロールバック計画またはホットフィックスを実施します 変更後にコンタクトフローをテストし、問題が解決されたことを確認します チームとエンドユーザーに変更内容を文書化して伝達します 4) Amazon Connect インスタンスの動作が遅い シナリオ : Amazon Connect インスタンスにおいて、エージェントのログインにかかる時間、コールのルーティング、管理ダッシュボードのパフォーマンスに遅延が発生しています。これは顧客とエージェントの両方の体験に影響を与えています。 主な方針 : Amazon CloudWatch を使用してシステムのパフォーマンスとリソース使用状況を監視します 同時使用のスパイクや Amazon Connect のサービス制限を確認します 問題が高トラフィック量または設定エラーに関連しているかを特定します 関連リソースのスケールアップや使用パターンの調整など、是正措置を講じます 5) AWS Lambda 関数のタイムアウト シナリオ : カスタム統合(例:データベースからの顧客データの取得)に使用される Lambda 関数がタイムアウトし、通話処理に遅延を引き起こし、その結果、通話の切断や情報取得の遅延が発生しています。 主な方針 : Lambda 関数 のログを確認し、タイムアウトが発生している理由(例:遅いデータベースクエリ、関数のロジックエラー)を特定します Amazon Connect の外部で Lambda 関数を手動でテストし、パフォーマンスの問題を確認します Lambda のタイムアウト設定を変更し、関数のコードを調整してパフォーマンスを改善します Lambda 関数が AWS サービスの制限に達していないか、リソースの制約に抵触していないかを調査します 6) CRM (Customer Relationship Management) 統合の問題 ( 例:Salesforce、ServiceNow) シナリオ : Amazon Connect から発信された通話で、CRM への顧客データの取り込みが失敗し、エージェントが顧客対応時に必要な情報にアクセスできない状況が発生しています。 主な方針 : Amazon Connect と CRM システム間の API 統合が機能しているか調査する CRM または Amazon Connect の統合に関する最近のアップデートや変更で問題の原因となった可能性があるものを確認する 両システム間の認証と承認の設定(API キー、IAM ロールなど)を確認する Amazon Connect と CRM 間の接続を手動でテストし、エラーがないかログを確認する 7) ルーティングプロファイルの設定ミス シナリオ : エージェントが誤ったルーティングプロファイルに割り当てられており、その結果、間違ったキューからの通話を受信したり、まったく通話を受信できない状態になっています。 主な方針 : ルーティングプロファイル を確認し、正しいエージェントに割り当てられていることを確認します キューに配置されるメンバーとスキルが適切に設定され、通話が適切にルーティングされるようにします 異なるエージェントでルーティングロジックをテストし、通話が正しくルーティングされることを確認します 設定の不一致を調整し、システムの改善状況を監視します 8) 高い通話放棄率 シナリオ : コンタクトセンターで異常に高い通話放棄率が発生しています。顧客がエージェントに到達する前に、またはキュー待機中に電話を切ってしまっています。 主な方針 : Amazon Connect のメトリクスを使用してキューの長さと待ち時間をモニタリングし、許容範囲を超えていないか確認します コンタクトフローの設定を確認し、推定待ち時間が顧客に明確に伝えられているか検証します エージェントの稼働状況にボトルネックがないか、またはシステムが過負荷になっていないか確認します 待ち時間を短縮し、より正確な待ち時間予測を提供するために IVR やルーティング戦略を調整します 9) エージェントの認証失敗 シナリオ : エージェントが Amazon Connect インスタンスにログインできない状態です。アイデンティティプロバイダー(例:AWS IAM Identity Center 、Active Directory)の設定ミスが原因と考えられる認証エラーが発生しています。 主な方針 : Amazon Connect とアイデンティティプロバイダーの連携が有効な状態を維持しているか確認します エージェントのログインに影響を与える可能性のある IAM ロール 、ポリシー、またはセキュリティ設定の最近の変更を確認します 認証やアクセス許可のエラーについて CloudWatch Logs を確認します 問題がアカウント固有のものかシステム全体に及ぶものかを切り分けるため、異なるアカウントでエージェントのログインをテストします 10) 顧客データの不整合 シナリオ : Amazon Connect または統合されたシステム (AWS Lambda、Amazon DynamoDB など)に保存されている顧客データが、顧客とのやり取りの中で一貫性を持っていません。例えば、以前のケースメモや顧客の設定が次の通話でエージェントに表示されないなどの問題が発生しています。 主な方針 : データ統合のプロセス(Lambda、DynamoDB、Salesforce など)が正しく機能していることを確認します 通話中にリアルタイムで顧客データが正しく取得、保存、更新されていることを確認します 不整合の原因となる可能性のあるデータ同期の問題を調査します エージェントのデータ取得の一貫性を確保するための修正を実装し、将来のデータの不一致に備えてログ記録とエラー処理を見直します 11) マルチチャネル体験の品質低下 シナリオ : 顧客のマルチチャネル体験(音声、チャット、メール)が低下し、顧客が異なるチャネル間で一貫性のない対応を受けています。 主な方針 : Amazon Connect と他のチャネルとの統合を確認します 各チャネルのコンタクトフローが正しく設定されており、顧客データがチャネル間で共有されていることを確認します(例:音声からチャットへ、またはその逆にコンテキストを受け渡せているか) すべてのチャネルの CloudWatch メトリクスを監視し、特定のチャネルのパフォーマンスが低下していないか確認します 各チャネル(音声、チャット、メール)を個別にテストし、品質低下の性質を確認します チャネル間のエスカレーションオプション(例:チャットから音声通話への転送)を実装し、顧客のコンテキストがチャネル間で保持されることを確認します まとめ このブログ記事では、Amazon Connect の 11 種類の多様な机上演習シナリオを紹介し、コンタクトセンター環境で発生する可能性のある一般的な問題のトラブルシューティングと解決に向けた包括的なアプローチを紹介しました。それぞれの課題に対処するための詳細な手順を確認することで、みなさまが Amazon Connect の機能を効果的に管理するための貴重な知見を得られることを願っています。 これらの演習は問題解決技術を強化するだけでなく、安定的な運用を維持するための事前計画、テスト、継続的なモニタリングの重要性も示しています。コンタクトセンターのマネージャーであれ、技術専門家であれ、これらのシナリオを練習することで、実際の問題に自信を持って効率的に取り組むために必要なレジリエンスと専門知識を身につけることができます。 そして、継続的にこのような演習を通じて改善することで、Amazon Connect 環境の堅牢性を維持し、優れた顧客体験の提供を保つことができます。 Renato Gentil Renato は、アイルランドを拠点とする AWS での 7 年以上の経験を持つシニアテクニカルアカウントマネージャーです。4 つの AWS 認定資格を保有しており、世界中のさまざまな顧客と大規模なレジリエンスプロジェクトに取り組み、机上演習やインシデント管理プロセスを通じてレジリエンスの改善を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。
数万人の顧客が Amazon DynamoDB の グローバルテーブル を最終的整合性で正常に使用していますが、さらに強力なレジリエンスに対する新たなニーズが出てきています。多くの組織は、DynamoDB の複数アベイラビリティゾーンアーキテクチャと最終的整合性のグローバルテーブルが要件を満たすことを見出していますが、決済処理システムや金融サービスのような重要なアプリケーションには、さらに高い要求があります。 これらのアプリケーションでは、顧客は稀なリージョン全体のイベント時にゼロ目標復旧時点 (RPO) を要求します。つまり、アプリケーションが任意のリージョンから最新のデータを読み取れるようにする必要があります。マルチリージョンアプリケーションは、場所に関係なく常に同じデータにアクセスする必要があります。 6 月 30 日より、Amazon DynamoDB グローバルテーブルの新機能として、マルチリージョン強整合性 (MRSC) がご利用いただけるようになりました。これにより、ゼロ RPO (目標復旧時点) を実現できます。この機能は、 2024 年の AWS re:Invent でプレビュー として初めて発表され、グローバル規模で高い耐障害性を備えたアプリケーションの構築を簡素化します。 以下は、既存の空の DynamoDB テーブルから MRSC を有効にする方法です。 次の手順で、既存の空の DynamoDB テーブルに対して MRSC を有効にできます。あるリージョンでアプリケーションの処理が中断された場合でも、MRSC レプリカを保持する別のリージョンにトラフィックをリダイレクトすることで、最新のデータを用いて処理を継続できることが保証されます。 はじめに この新しい機能の使い方を順を追ってご説明します。 MRSC を利用開始するには、データが含まれていない既存の DynamoDB テーブルからグローバルテーブルを作成する必要があります。既存のテーブルに移動し、 グローバルテーブルタブ を選択して、 レプリカの作成 を選択します。 MRSC の可用性アーキテクチャでは、3 つの AWS リージョンが必要です。MRSC は、3 つのフルレプリカを構成することも、2 つのレプリカとウィットネスで構成することもできます。ウィットネスには、必要な可用性を確保するための変更データのみが複製され、テーブルデータ全体のコピーは保持されません。 次のスクリーンショットは、2 つのレプリカとウィットネスで MRSC を構成する方法を示しています。代わりに 3 つのフルレプリカで MRSC を構成するには、 リージョン 2 をウィットネスとして構成する のチェックを外すことで設定できます。 既存のテーブルをプログラムで更新する必要がある場合は、次のプロンプトを使用して、必要なコマンドを生成するために Amazon Q CLI を利用できます。 > ねえ Q! us-east-1 リージョンの 「demo-mrsc」という DynamoDB テーブル を、us-east-2 リージョンにまたがるマルチリージョン強整合性 (MRSC) 対応に更新し、us-west-2 リージョンにウィットネスを構成します その後すぐに、Q CLI は次のコマンドを返してきます。 > マルチリージョン強整合性を有効にするには、適切なパラメータを指定して、update-table コマンドを使用して DynamoDB テーブルを更新する必要があります。以下のように実行します: aws dynamodb update-table \ --table-name demo-mrsc \ --replica-updates '[{"Create": {"RegionName": "us-east-2"}}]' \ --global-table-witness-updates '[{"Create": {"RegionName": "us-west-2"}}]' \ --multi-region-consistency STRONG \ --region us-east-1 処理が完了したら、MRSC グローバルテーブルのステータスを確認できます。DynamoDB グローバルテーブルに ウィットネス が設定されていることを確認できます。ウィットネスは、マルチリージョン強整合性による高い耐障害性を維持しつつ、コストを削減します。 次に、アプリケーション内で ConsistentRead を使用することで、強整合性を持ってデータを読み取ることができます。以下は Python の例です: import boto3 # 使用するリージョンに合わせて DynamoDB クライアントを設定する dynamodb = boto3.resource('dynamodb', region_name='us-east-2') table = dynamodb.Table('demo-mrsc') pk_id = "demo#test123" # リージョン間で強整合性を保った読む response = table.get_item( Key={ 'PK': pk_id }, ConsistentRead=True ) print(response) 最も強力なレジリエンスを必要とするオペレーションには、 ConsistentRead=True を使用できます。最終的な整合性で問題ないような重要度の低い処理では、このパラメータを省略することで、パフォーマンスの向上とコストの削減が期待できます。 知っておくべき追加情報 以下の点にご注意ください: 可用性 — Amazon DynamoDB のマルチリージョン強整合性機能は、以下の AWS リージョンで利用できます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (大阪、ソウル、東京)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ) 価格設定 — マルチリージョン強整合性の料金は、既存のグローバルテーブルの料金体系に従います。DynamoDB は最近、グローバルテーブルの料金を最大 67% 削減し、これまで以上に高耐障害性のアーキテクチャを手頃な価格で利用できるようになりました。詳しくは、AWS Database Blog の Amazon DynamoDB がオンデマンドスループットとグローバルテーブルの料金を引き下げ の記事をご覧ください。 アプリケーションの最高レベルの耐障害性を実現し、どのリージョンにおいても常に最新のデータを読み取れる、常時稼働のアプリケーションを構築する方法については、 Amazon DynamoDB グローバルテーブル のページをご覧ください。 開発をお楽しみください! — Donnie 原文は こちら です。
6 月 30 日、 AWS Graviton4 プロセッサと最新の第 6 世代 AWS Nitro Card を搭載した Amazon Elastic Compute Cloud (Amazon EC2) C8gn ネットワーク最適化インスタンスの一般提供が発表されました。EC2 C8gn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供します。これは、EC2 ネットワーク最適化インスタンスの中でも最高レベルの帯域幅です。 C8gn インスタンスは、セキュリティおよびネットワーク仮想アプライアンス (仮想ファイアウォール、ルーター、ロードバランサー、プロキシサーバー、DDoS アプライアンス)、データ分析、密結合クラスターコンピューティングジョブなど、要求が最も厳しいネットワーク集約型ワークロードを実行するために使用できます。 EC2 C8gn インスタンスの仕様 C8gn インスタンスは、最大 192 個の vCPU と 384 GiB のメモリを提供し、Graviton3 ベースの EC2 C7gn インスタンス よりも最大 30% 優れたコンピューティングパフォーマンスを実現します。 C8gn インスタンスの仕様は次のとおりです。 インスタンス名 vCPU 数 メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8gn.medium 1 2 最大 25 最大 10 c8gn.large 2 4 最大 30 最大 10 c8gn.xlarge 4 8 最大 40 最大 10 c8gn.2xlarge 8 16 最大 50 最大 10 c8gn.4xlarge 16 32 50 10 c8gn.8xlarge 32 64 100 20 c8gn.12xlarge 48 96 150 30 c8gn.16xlarge 64 128 200 40 c8gn.24xlarge 96 192 300 60 c8gn.metal-24xl 96 192 300 60 c8gn.48xlarge 192 384 600 60 c8gn.metal-48xl 192 384 600 60 C8gn インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または AWS SDK を使用して起動できます。 現在 C7gn インスタンスを使用している場合は、新しい C8gn インスタンスでも同様の vCPU/メモリ比率が提供されるため、ネットワーク集約型ワークロードの C8gn インスタンスへの移行を簡単に行えます。詳細については、一連の Graviton リソース をご覧ください。これらは、Graviton インスタンスタイプへのアプリケーションの移行を開始するために役立ちます。 また、「 Level up your compute with AWS Graviton 」ページにアクセスして、Graviton 導入ジャーニーを開始することもできます。 今すぐご利用いただけます Amazon EC2 C8gn インスタンスは、本日から米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。2 つのメタルインスタンスサイズが提供されるのは、米国東部 (バージニア北部) リージョンのみです。これらのインスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス 、または ハードウェア専有インスタンス および 専有ホスト として購入できます。 Amazon EC2 コンソール で C8gn インスタンスをぜひお試しください。詳細については、「 Amazon EC2 C8g Instances 」ページをご確認ください。ご意見やご要望がありましたら、 EC2 の AWS re:Post 、または通常の AWS サポート窓口までお寄せください。 – Channy 原文は こちら です。
本ブログはユーザックシステム株式会社様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。ISV(独立系ソフトウェアベンダー)/SaaS業界のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 企業の業務プロセスの自動化・効率化を支援するユーザックシステム株式会社様(以下、ユーザックシステム様)は、 Amazon Bedrock を活用し、従来は自動化が困難であった非定型の受注業務に生成AI を活用することによって自動化に成功しました。本記事では、生成AIを活用した受注業務における効率化の取り組みについてご紹介します。 お客様の状況と検証に至る経緯 ユーザックシステム様は、20年以上にわたり受注業務の効率化に取り組んできました。同社のRPA(Robotic Process Automation)ソリューション「Auto ジョブ名人」により、定型的な業務の自動化は着実に進展していました。 しかし、「得意先や担当者ごとに対応が異なる」「処理に人の判断が必要」といった非定型業務は、依然として人手に依存せざるを得ない状況が続いていました。特に食品卸業界では、FAXやメールでの注文書のやり取りが主流であり、これらを確認して社内システムに入力する作業に多大な工数を要していました。 また、取引先や社内システムごとに独自のルールが存在するため、受注担当者が一人前になるまでに約1年の経験が必要でした。さらに「昨今の人手不足も相まって、受注業務における生産性向上は喫緊の課題となっていました」とユーザックシステム様は当時を振り返ります。 ソリューション/構成 この課題を解決するため、ユーザックシステム様は「Knowfa 受注AIエージェント」の開発に着手しました。このシステムは、生成AIとRPAを組み合わせることで、非定型の受注業務の完全自動化を目指すソリューションです。(プレスリリースは こちら ) システムの処理フローは以下の通りです。 注文担当者が、お客様からのFAX や電子メールで届いた注文書の画像をシステムに登録する システムが注文書の画像を分析し、文字や数字を自動的に読み取る (例:商品名、個数、お客様情報など) システムは読み取った情報を使って、過去の注文データベースから類似の注文内容を探し出す(例:同じお客様の過去の注文や、似た商品の注文履歴など) システムは 2 で読み取った注文内容と 3 の過去のデータを照らし合わせて、注文内容を判断する (例:商品コード、注文数の確認など) 導入効果 Knowfa 受注AIエージェントの導入により、以下のような顕著な効果が得られました。 AIエージェントが判断業務を担い、人はチェック業務だけに専念する役割分担を確立。これまでRPAで対応できなかった受注業務の80%自動化に成功。 Amazon Bedrockのセキュリティや信頼性により、気密性の高いデータを扱うエンドユーザーにとって安心材料に。 また「AWSのサーバーレスアーキテクチャとマネージドサービスの活用により、エンジニア3名とプロジェクトマネージャー1名という少人数体制でも、約4ヶ月という短期間でβ版開発を実現できました」と、技術面でのメリットを説明します。 今後の展望 今後の展開について、ユーザックシステム様は次のように意欲を示しています。 「現在はFAX注文書を中心に対応していますが、今後はメールやその他の受注業務への展開も計画しています。Amazon Bedrock エージェントを活用し、AIエージェントの自律性を高めながら、対応可能な業務の範囲を拡大していきたいと考えています」 ユーザックシステム株式会社 : 上野 真裕様(中央) Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗(左端)、ソリューションアーキテクト 呉 敏禎(右端)
みなさん、こんにちは!製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS Summit Japan 2025 が開催され、製品設計・エンジニアリング分野の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」において、多くの関心をいただきました! 今回の展示では、 Research and Engineering Studio on AWS (RES) による CAD(コンピューター支援設計)/CAE(コンピュータ支援エンジニアリング) 環境のクラウド化と、その環境上で Amazon Q Developer を活用した CAE アプリケーションによる流体解析のデモを実施いたしました。従来の製品設計・CAE 解析プロセスがどのように効率化されるのかをご紹介します。 従来の課題と RES による解決 研究・開発環境の課題 研究とエンジニアリングにおけるイノベーションの阻害要因として以下のような例が挙げられます。 海外の設計チームとデータ共有や打ち合わせが難しく、各拠点でバラバラに作業することになり、同じような問題を何度も解決する無駄が発生する ワークステーションの設定やソフトウェアのインストール、ライセンス管理などに時間を取られ、本来の設計・解析業務に集中できない 手持ちのワークステーションでは大規模な CFD(計算流体力学)解析ができず、「もっと高性能なコンピューティングリソースが欲しい」と思っても簡単には増強できない Research and Engineering Studio on AWS (RES) とは RES は、研究開発チームがクラウドの専門知識を必要とせずに研究者とエンジニアがワークロードを実行できる環境を管理および構築するためのオープンソースの使いやすいウェブベースのポータルです。 図1 RESアーキテクチャ 管理者にとってのメリット インストール、設定、管理が楽になる ハードウェア調達を待つ必要なし、数分で環境構築完了 各拠点への CAD 環境配布も仮想環境で一括管理(図2) 仮想環境により設計拠点に捉われずに CAD 環境の展開やバージョンアップなどのメンテナンスも容易 プロジェクト全体の AWS 使用状況とコストを一元的に監視・管理(図3) 既存の ID 認証システム( AWS マネージド AD サービス )と統合でき、セキュリティとガバナンスを一元管理 エンドユーザーにとってのメリット Web ポータルにログインしてタスクに集中できる 最適なコンピュータ環境を使用することで開発の時間を短縮(図4) AWS リソースの管理を習熟する必要は無い 自宅でも出張先でも、どこからでも同じ環境にアクセス可能 大規模解析の時だけ高性能 GPU、普段は低コスト環境で無駄なし 共有データにアクセスできる環境でチーム間の共同作業が可能 図2 Virtual Desktops 図3 Virtual Desktop Dashboard 図4 選択できる高性能な仮想サーバ(Amazon EC2 インスタンス)一例 RES の使用開始方法 GitHub のAmazon Web Servicesリポジトリ にホストされている RES ソースコードをダウンロードします。 RESの起源となる事例 – Amazon Lab126の事例 – Amazon Lab126 は、カリフォルニア州サニーベールに拠点を置く、 Amazon の研究所です。このラボには Amazon Devices のハードウェア、ソフトウェア、運用チームが含まれており、Amazon Echo や Amazon Kindle など 知名度の高い製品を開発しています。 Amazon Lab126 では、老朽化した、コストのかかるオンプレミスの CAE 環境を使用していました。そのためエンジニアリングチームが必要とするスケーラビリティと使いやすさを提供できませんでした。 AWS ベースの CAE 機能を有効にするために、Amazon Lab126 は、最も多くの I/O 集中型ワークロード向けに Amazon FSx for Lustre を使用しました。また、 AWS Backup を使用してクラスターの耐障害性を高める新しいスケールアウトコンピューティングフレームワークを作成しました。 これにより、CAE ジョブの実行を3倍高速化し、新規ユーザーを数週間ではなく1日足らずでオンボーディングすることが可能になりました。必要に応じて新しい CAE クラスターを起動でき、製品設計の革新を推進することができました。 デモ:RES 環境での Amazon Q Developer を活用したCFD(計算流体力学)解析業務支援 アーキテクチャ 図5 RES 環境での Amazon Q Developer を活用した CFD 解析 アーキテクチャ 想定ユーザー例:若手エンジニア 想定ユーザープロファイル : 学歴・基礎知識:機械工学科卒業、CFD 理論は学習済み 実務経験:CAD 基本操作可能(FreeCAD 等)、流体力学基礎知識あり プログラミング:Python 基礎レベル CFD 経験:学生時代に OpenFOAM を少し触った程度 課題 : 学生時代の簡単な CFD と実務レベルのギャップが大きい 多機能・高機能な CAE ソフトは使い方がよくわからない 上司から「バイクフレームの空力解析やって」と言われたが、実務経験なし 社内に CFD 専門家がいない(または忙しくて教えてもらえない) Amazon Q Developer による設計プラン作成 Amazon Q Developer(生成 AI 会話アシスタント)とのチャットやり取りで設計目標等を相談し、設計プランドキュメントを作成してもらいます。 図6 バイクフレーム CFD 解析 設計プランドキュメント例 Amazon Bedrock Knowledge Bases による RAG 活用 市販 CAE アプリケーションのユーザーガイドは web で一般公開されているケースが少なく、ソフト購入者のみが見れるケースが一般的です。従って生成 AI モデルで十分に学習済みではないため、Amazon Q Developer が自律的に判断して Amazon Bedrock Knowledge Bases で必要な CAE アプリケーションのマニュアルもしくはドキュメントを RAG(検索拡張生成) 検索して操作ガイドや解析自動実行 Java マクロファイルなどを作成してユーザーに提示します。 2 つの利用方法 1. GUI 操作ガイド CAE アプリケーションの GUI 画面で操作を行っていきたい場合は、Amazon Q Developer が生成した詳細な操作ガイドに従って操作していきます。 図7 バイクフレーム CFD 解析 CAE アプリケーション GUI 操作ガイド例 2. Java マクロ自動実行 CAE でユーザーサブルーチンでカスタマイズしたり自動化するなどの目的でコードを書く必要がある場合(マクロ機能の実行イメージの場合)には、Amazon Q Developper にコードを生成させて利用するようなユースケース(マクロファイルの実行ボタンを押すだけで自動解析実行が行われるイメージ)も考えられます。 図8 バイクフレーム CFD 解析 CAE 自動化コード例 赤字で示された箇所のような、パラメータの数値を変更するだけで様々なバリエーションの解析が自動実行できます。 図9 バイクフレーム CFD 解析 メッシュ分割、流速分布図 CAE アプリケーションを実行時に、ハイスペックな EC2 インスタンスに変更して処理することで、シミュレーション時間を大幅に短縮できます。 RES と同じ AWS 上に構成した HPC (ハイパフォーマンスコンピューティング) クラスタで処理させて、これまで実現できなかった大規模で高精度な解析にチャレンジすることも可能です。 図10 並列処理による解析時間の変化 まとめ AWS Summit Japan 2025 の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」では、RES による CAD/CAE 環境のクラウド化と、Amazon Q Developer を活用した CFD(計算流体力学)解析業務支援のデモを通じて、製品設計・エンジニアリング分野における以下のような革新的な変化を実現できることを示しました。 技術面での革新 専門知識の民主化 : 若手エンジニアでも高度な CFD 解析を実行可能 学習コストの削減 : 生成 AI による対話的な学習とガイダンス 自動化の推進 : Java マクロによる解析プロセスの自動化 運用面での改善 迅速な環境構築 : 数分でのワークステーション起動 柔軟なリソース管理 : 需要に応じたスケーリング コスト最適化 : 使用量ベースの課金とリソース管理 組織面での効果 グローバルコラボレーション : 地理的制約を超えた共同作業 知識の共有 : チーム間での専門知識の共有促進 イノベーションの加速 : 技術的制約の解消による創造性の向上 AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、RES 環境での Amazon Q Developer 活用による製品設計・エンジニアリング分野でのデジタルトランスフォーメーションを推進し、競争力の向上を実現していきましょう。 著者プロフィール 山田 航司 (Koji Yamada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。
私がシアトルを訪れるたびに空港で最初に出迎えてくれるのは、 レーニア山 です。 Amazon Web Services (AWS) で最も革新的なプロジェクトがこの山にちなんで名付けられていることをご存知でしたか? Project Rainier は、米国内の複数のデータセンターで AI モデルをトレーニングするために、世界で最も強力なものとなることが期待されるコンピュータを作成する新しいプロジェクトです。Anthropic は、現在最も大規模なトレーニングクラスターの 5 倍の計算能力を備える高度な Claude モデル バージョンを開発する予定です。 Project Rainier を支える主要テクノロジーは、 AWS がカスタム設計した Trainium2 チップ です。このチップは、複雑な AI モデルのトレーニングに必要となる膨大なデータ処理に特化しています。大規模なシステム全体での超高速な通信とデータ共有を可能にする、新しいタイプの Amazon EC2 UltraServer と EC2 UltraCluster のアーキテクチャ内で、何千個もの Trainium2 チップが接続されることになります。 チップからソフトウェアに及ぶテクノロジースタックのあらゆるコンポーネントを設計し、最大限の効率性と信頼性のためにシステム全体を最適化することを可能にする、 Project Rainer での AWS の垂直統合 に関する詳細をご覧ください。 6 月 23 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon FSx for OpenZFS のための Amazon S3 アクセス – Amazon S3 Access Points を通じて FSx for OpenZFS ファイルデータにアクセスし、分析することができます。このため、ファイルシステムからデータを移動しなくても、AWS の AI/ML サービスや分析サービスとシームレスに統合できるようになります。FSx for OpenZFS データを S3 に保存されているかのように扱うことができるため、Amazon Bedrock、Amazon SageMaker、AWS Glue や、その他の S3 ベースのクラウドネイティブアプリケーションを含めたさまざまなアプリケーションのために S3 API 経由でデータにアクセスすることが可能になります。 Amazon S3 の Apache Iceberg テーブル向けの sort および z-order コンパクション – 新しい sort および z-order コンパクションを使用して、クエリパフォーマンスの向上とコスト削減を実現できます。S3 Tables では、sort コンパクションが定義された列順序に基づいてデータファイルを自動的に整理し、z-order コンパクションは効率的な複数列のクエリのためにメンテナンス API 経由で有効化できます。 Amazon CloudWatch 調査 – 異常の特定、関連するシグナルの表面化、および修復手順の提案に役立つ Amazon CloudWatch の AI 駆動の調査機能を使用することで、AWS 環境内での運用上のトラブルシューティングを迅速化することができます。この機能は、CloudWatch データウィジェット、複数の AWS コンソール、CloudWatch アラームアクション、または Amazon Q チャットを通じて開始でき、チームコラボレーションと Slack や Microsoft Teams との統合を可能にします。 Amazon Bedrock ガードレールの Standard ティア – 新しい Standard ティアを使用することで、AI コンテンツの安全対策を強化できます。このティアは、最大 60 の言語全体でのコンテンツフィルタリング機能とトピック拒否機能の改善、誤字等の表記ゆれ検出の向上、プロンプト攻撃に対する保護の強化を実現します。この機能では、有害コンテンツのブロック、モデルハルシネーションの防止、個人を特定できる情報 (PII) のリダクション、自動推論チェックによる事実に基づく主張の検証を行うためのセーフガードを設定できます。 プライベートホストゾーン向けの Amazon Route 53 Resolver エンドポイント – プライベートホストゾーンのサブドメイン向けの新しい Route 53 DNS 委任機能を使用することで、AWS とオンプレミスインフラストラクチャ全体での DNS 管理を簡素化できます。この機能は、インバウンドとアウトバウンド両方の Resolver エンドポイントで活用できます。ネームサーバーレコードを使用してオンプレミスインフラストラクチャと Route 53 Resolver クラウドサービス間でサブドメイン権限を委任できるため、複雑な条件付き転送ルールが不要になります。 Java 変換向けの Amazon Q Developer CLI – 新しい Amazon Q Developer Java 変換コマンドラインインターフェイス (CLI) を使用して、Java アプリケーションのアップグレードを自動化し、スケールすることができます。この機能は、Java バージョン 8、11、17、または 21 からバージョン 17 または 21 へのアップグレードをコマンドラインから直接実行します。このツールは選択的な変換オプションを提供するため、変換計画から特定のステップを選択し、ライブラリのアップグレードをカスタマイズすることができます。 新しい AWS IoT Device Management マネージド統合 – 新しいマネージド統合機能を使用することで、複数のメーカーやプロトコル全体でのモノのインターネット (IoT) デバイス管理を簡素化できます。この機能は、デバイスが直接接続するか、ハブまたはサードパーティークラウド経由で接続するかにかかわらず、それらデバイスを制御するための統合インターフェイスを提供します。この機能には、事前構築された Cloud-to-Cloud (C2C) コネクタ、デバイスデータモデルテンプレート、および ZigBee、Z-Wave、Wi-Fi プロトコルをサポートする SDK が含まれていますが、カスタムコネクタやデータモデルを作成することも可能です。 AWS のお知らせに関する詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース AWS サービス用のさまざまな Model Context Protocol (MCP) サーバー がリリースされました。皆さんが関心を持つと思われる MCP サーバー関連のチュートリアルをいくつかご紹介します。 AWS costs estimation using Amazon Q CLI and AWS Cost Analysis MCP – Amazon Q CLI と AWS Cost Analysis MCP サーバーを併用することで、AWS ベストプラクティスに従う高度なコスト分析を実行できます。詳しい例とステップバイステップの手順を使用して、基本的な設定と高度なテクニックを説明します。 Supercharging AWS database development with AWS MCP servers – MCP の背後にある中核的概念について学び、新しい AWS MCP サーバーが自然言語プロンプトを通じてデータベース開発を加速する方法を実証できます。 Create your own MCP server with C# and .NET with Amazob Q CLI – Amazon Q CLI を MCP クライアントとして使用して、C# MCP サーバーを構築し、テストするためのローカル開発環境を設定することで、AI 駆動のアプリケーションを作成、反復、改善する能力を強化します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS NY Summit – コンピューティング、ストレージ、生成 AI における最新かつ最新鋭の AWS テクノロジーに焦点を当てた Swami の基調講演からインサイトを得ることができます。ニュースブログチームもエキサイティングなニュースをいくつか用意しています。直接参加できない場合でも、 グローバルライブストリームに登録 して参加することが可能です。また、最寄りの都市で 7 月と 8 月に開催される予定の Summit の日付も確認しておきましょう。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 6 月 30 日週のニュースは以上です。7 月 7 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。
6 月 25 日より、 Amazon S3 Access Points を Amazon FSx for OpenZFS ファイルシステムにアタッチして、 Amazon Simple Storage Service (Amazon S3) に格納されているかのようにデータにアクセスできるようになりました。この新機能を使用すると、S3 と連動する Amazon Web Services (AWS) の幅広い 人工知能 (AI)、 機械学習 (ML)、 分析 サービスやアプリケーションで使用するデータとして FSx for OpenZFS 内のデータにアクセスできます。ファイルデータは引き続き FSx for OpenZFS ファイルシステムに格納されます。 組織は数百エクサバイトのファイルデータをオンプレミスで保存しており、このデータを AWS に移動して、優れた俊敏性、信頼性、セキュリティ、スケーラビリティを実現し、コストを削減したいと考えています。ファイルデータの AWS への移動後に、組織がそのデータをさらに活用したいと考えるのはめずらしいことではありません。例えば、多種多様な AWS 生成 AI サービスと機械学習サービス を使用して、エンタープライスデータで 生成 AI アプリケーションを強化したり、機械学習モデルをトレーニングしたりすることを考えます。また、新しい AWS アプリケーションで独自のファイルデータを使用する柔軟性も求めています。ところが、AWS データ分析サービスとアプリケーションの多くは、Amazon S3 に保存されたデータをデータレイクとして使用するように構築されており、移行した後で Amazon S3 と連動するツールをデータソースとして使用できます。これまで、これには Amazon FSx for OpenZFS ファイルシステムと Amazon S3 バケット間でデータをコピーするためのデータパイプラインが必要でした。 FSx for OpenZFS ファイルシステムに Amazon S3 Access Points をアタッチすると、ファイルプロトコルと Amazon S3 API 操作の両方を経由する統合アクセスが維持され、データの移動やコピーが必要なくなります。 GetObject 、 PutObject 、 ListObjectsV2 などの S3 オブジェクト操作を使用したファイルデータの読み取りや書き込みが行えます。1 つのファイルシステムに数百個の S3 Access Point をアタッチでき、各 Access Point にはアプリケーション固有の許可を設定できます。これらの S3 Access Point は、S3 バケットにアタッチされる S3 のアクセスポイントと同様のきめ細かなアクセス許可コントロールをサポートします。これには、 AWS Identity and Access Management (IAM) アクセスポイントポリシー や パブリックアクセスブロック のほか、 仮想プライベートクラウド (VPC) へのアクセスを制限するなどのネットワークオリジンコントロールが含まれます。データはそのまま FSx for OpenZFS ファイルシステムに格納されるため、引き続き ネットワークファイルシステム (NFS) を使用してデータにアクセスし、既存のデータ管理機能からメリットを得ることができます。 S3 API を使用することで、データが S3 に格納されているかのように Amazon FSx for OpenZFS ファイルシステム内のファイルデータを使用して、 検索拡張生成 (RAG) ワークフローのために Amazon Bedrock で生成 AI アプリケーションを強化し、 Amazon SageMaker で ML モデルをトレーニングして、 Amazon Athena と AWS Glue で分析や ビジネスインテリジェンス (BI) を実行できます。また、データを移動したりリファクタリングしたりすることなく、 Apache Spark や Apache Hive などのオープンソースツールを使用してインサイトを生成することも可能です。 始めましょう S3 Access Point は、 Amazon FSx コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成し、Amazon FSx for OpenZFS にアタッチできます。 まず、 Amazon FSx for OpenZFS ファイルシステムのドキュメントページ にある手順に従ってファイルシステムを作成します。次に、Amazon FSx コンソールで [アクション] に移動し、 [S3 Access Point を作成] を選択します。 標準設定をそのまま変更せずに作成します。 作成の進行状況は、Amazon FSx コンソールで監視できます。 利用可能になったら、新しい S3 Access Point の名前を選択し、Access Point の概要を確認します。概要には自動生成されたエイリアスが含まれています。このエイリアスは、通常 S3 バケット名を使用する場所ならどこでも機能します。 バケットスタイルのエイリアスを使用すると、S3 API 操作経由で FSx データに直接アクセスできます。 ListObjectsV2 API を使用してオブジェクトを一覧表示する GetObject API を使用してファイルを取得する PutObject API を使用してデータを書き込む データには引き続き NFS 経由でアクセスできます。 S3 API 経由で FSx データにアクセスする以外にも、S3 内のデータを処理する幅広い AI、ML、分析サービスを使用してデータを活用できます。私の例を挙げると、私の旅行サポートアプリケーションリポジトリである WhatsApp-Powered RAG Travel Support Agent: Elevating Customer Experience with PostgreSQL Knowledge Retrieval から取得した 航空会社のカスタマーサービス情報が含まれる PDF をデータソースとして使用して、 Amazon Bedrock のナレッジベース を作成しました。 Amazon Bedrock のナレッジベースを作成するため、「 ナレッジベースの Amazon S3 に接続する 」ユーザーガイドの接続ステップを実行しました。データソースとして Amazon S3 を選択し、S3 ソースとして S3 Access Point エイリアスを入力してから、ナレッジベースを設定して作成しました。 ナレッジベースが同期されるとすべてのドキュメントが表示され、 ドキュメントソース が S3 になっていることがわかります。 最後に、ナレッジベースに対してクエリを実行し、コンテキストに即した回答を提供するために Amazon FSx for OpenZFS ファイルシステムのファイルデータが正常に使用されたことを確認しました。そうすることで、データの移動を必要としないシームレスな統合が行われたことがわかります。 知っておくべきこと 統合とアクセスコントロール – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 エンドポイント経由での標準 S3 API 操作 (GetObject、ListObjectsV2、PutObject など) をサポートし、AWS Identity and Access Management (IAM) の許可とファイルシステムユーザー認証によるきめ細かなアクセスコントロールを使用します。S3 Access Point には、S3 バケット名を使用してデータにアクセスするための自動生成された Access Point エイリアスが含まれています。Amazon FSx リソースへのパブリックアクセスはデフォルトでブロックされます。 データ管理 – データは Amazon FSx for OpenZFS ファイルシステムに留まるものの、Amazon S3 内にあるかのようにアクセスできるため、データを移動またはコピーする必要がなくなります。ファイルデータは引き続き NFS ファイルプロトコル経由でアクセスできます。 パフォーマンス – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 バケットアクセスと同様に、数十ミリ秒範囲のファーストバイトレイテンシーを実現します。パフォーマンスは Amazon FSx ファイルシステムのプロビジョンドスループットに合わせてスケールし、最大スループットは基盤となる FSx ファイルシステムの設定に基づいて判断されます。 料金 – Amazon FSx の標準料金に加えて、S3 Access Points 経由のリクエストとデータ転送に対する Amazon S3 料金が請求されます。詳細については、「 Amazon FSx for OpenZFS の料金 」ページをご覧ください。 Amazon FSx for OpenZFS システムへの Amazon S3 Access Points のアタッチは、Amazon FSx コンソール、AWS CLI、または AWS SDK を使用して今すぐ開始できます。この機能は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、ストックホルム)、およびアジアパシフィック (香港、シンガポール、シドニー、東京) の各 AWS リージョン でご利用いただけます。 – Eli 原文は こちら です。
本ブログは 2025 年 6 月 17 日に公開された Amazon News “ AWS rolls out 3 key security capabilities at re:Inforce, helping customers simplify and scale ” を翻訳したものです。 新しいツールにより、お客様はデジタル資産をより適切に保護できるようになります。また、重要なセキュリティ問題の特定し、サイバー攻撃から防御するなど、さまざまな対策が可能になります。 重要なポイント AWS は生成 AI 時代の新たな脅威に対応するため、3 つの強化されたセキュリティサービスを導入します AWS Security Hub は、チームが重要な問題を一元的に特定し対処するのに役立ちます AWS Shield の新しいプロアクティブなネットワークセキュリティ分析により、攻撃者に悪用される前にセキュリティギャップを発見して修正することが容易になります Amazon GuardDuty は、拡張脅威検出機能をコンテナベースの環境にも拡張し、検出されにくい複雑な攻撃パターンを特定します Amazon Web Services (AWS) は 2025 年 6 月 16 日 〜 18 日に、米国ペンシルベニア州フィラデルフィアで開催された AWS re:Inforce において、あらゆる規模のお客様がデジタル防御を強化するための新しいセキュリティ機能群を発表しました。 AWS の年次クラウドセキュリティカンファレンスである AWS re:Inforce では、世界中のセキュリティ専門家、パートナー、ビルダーが集まり、生成 AI 時代における新たなセキュリティ課題への対応について議論を交わしています。 組織がますます高度化するサイバー脅威に直面する中、AWS は本日 (2025 年 6 月 17 日) に、セキュリティ管理を簡素化しながらより包括的な保護を提供することを目的とした 12 の新機能を発表しました。以下はその主要な 3 つのサービスです。 AWS Security Hub:システムへのアクティブな脅威を迅速に特定し優先順位付けするためのサポート AWS Security Hub は、お客様が最も重要なセキュリティ問題を特定し、迅速に対応してリスクを軽減するのに役立ちます。これは「セキュリティコマンドセンター」のような役割を果たし、異なるタイプのセキュリティアラートと脆弱性の間の関連性を明らかにします。これにより、セキュリティチームはクラウドシステムへのアクティブな脅威を迅速に特定し、優先順位を付けることができます。すべての情報を一箇所にまとめることで、Security Hub は組織のセキュリティ状態をより明確に把握できるようにし、複数のセキュリティツールから手動で情報を収集する必要性を取り除きます。AWS Security Hub は本日から AWS のお客様向けにプレビュー版として利用可能です。 AWS Shield:お客様のオンラインシステムを事前に保護 AWS Shield は、ネットワークセキュリティの設定ミスや弱点を事前に発見することで、ウェブサイトやオンラインアプリケーションの保護方法を強化しています。このサービスは、お客様のセキュリティリソースのマップを作成し、SQL インジェクション (ハッカーがウェブサイトフォームを通じてデータにアクセスしようとする攻撃) や分散型サービス拒否 (DDoS) 攻撃 (攻撃者が偽のトラフィックでウェブサイトを過負荷にしてクラッシュさせる攻撃) などの一般的な攻撃に対する脆弱性を特定します。AWS Shield は、重要度別に問題を強調表示するわかりやすいダッシュボードと、問題を迅速に修正するためのステップバイステップの手順を提供します。お客様は、最も高性能な生成 AI を搭載した業務用アシスタントである Amazon Q を使用して、複雑なセキュリティ設定をナビゲートする代わりに、簡単な会話を通じてガイダンスを得ることもできます。 Amazon GuardDuty:コンテナベースのアプリケーション向け拡張脅威検出の提供 AWS は Amazon GuardDuty 拡張脅威検出の機能拡張を発表し、Amazon Elastic Kubernetes Service (Amazon EKS) で実行されるコンテナベースのアプリケーションを保護できるようになりました。GuardDuty はお客様のシステム全体のさまざまなセキュリティシグナルを接続し、検出されにくい高度な攻撃パターンを検出します。EKS 監査ログ、ランタイム動作、AWS アクティビティを監視することで、GuardDuty は複雑な多段階攻撃を特定できます。これらの改善された検出機能により、セキュリティチームは潜在的な問題の調査に費やす時間を減らし、実際の脅威に対処する時間を増やすことができ、ビジネス運営への影響を軽減します。 セキュリティの課題が進化し続ける中、AWS はお客様が潜在的なリスクに先んじて対応できるよう取り組んでいます。例えば、AWS はすべてのタイプの AWS アカウントにおいて、すべてのルートユーザーに対して 100% の多要素認証を強制しています。本日発表された新しいセキュリティ機能により、お客様はより深い可視性を得て、セキュリティ運用を効率化し、クラウド環境をより効果的に保護することができます。 イノベーションを促進するセキュリティ機能を構築し、組織が迅速にスケールする自信を与えるガードレールを作成することで、AWS はお客様が少ない労力でより強固なセキュリティポスチャを構築できるよう支援し、より多くのリソースを成長に集中させることを可能にしています。 これらのセキュリティトピックと AWS re:Inforce で議論されている内容について詳しくは、リンク先をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
はじめに みなさんこんにちは。ソリューションアーキテクトの光吉です。2025 年 5 月 20 日にヘルスケア・ライフサイエンスと半導体業界のお客様を AWS にお招きして「ハイテク製造・ヘルスケア・ライフサイエンス業界向けセキュリティインシデント疑似体験 GameDay 」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティへの取り組みを知って頂ければ幸いです。 AWS GameDayとは AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWSが提供するユニークなトレーニングプログラムですです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。 このプログラムの特徴は、実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。 参加者は、Amazon GuardDuty、AWS CloudTrailといった実際のAWSセキュリティサービスのログを SIEM on Amazon OpenSearch Service というソリューションから確認し、インシデントの検知から対応までを体験します。このハンズオン形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。 この AWS GameDay の魅力の一つは、ゲーミフィケーションの要素を取り入れている点です。チーム間で競い合いながら学習を進めることで、参加者のモチベーションを高く保ちつつ、効果的な学習を実現しています。さらに、チームでの協力が必要となるため、組織内のコミュニケーション能力の向上にも役立ちます。 セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDayは、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会となっています。多くの企業がクラウド環境でのビジネスを展開する現代において、このような実践的なセキュリティトレーニングの重要性は、ますます高まっているといえるでしょう。 AWS GameDay の流れ、イベントの様子 さて、今回は9社、57名の方々に参加いただきました。多くは情報システム部に所属する皆さまでセキュリティの意識も高く真剣に取り組んでいただいておりました。皆様は3から4名ごとにチームに分かれてインシデントが発生したというシナリオを元に実際の AWS 環境にログインいただき制限時間2時間の中で調査を行っていただきました。具体的には外部向け Web サービスを AWS で公開していたが脅威を検知したにもかかわらず原因がわからないというシナリオでゲームは進行します。 実際の AWS GameDay の様子 各チームの進行状況は得点として可視化されてリアルタイムに確認ができる 最終結果 – 優勝チームの紹介 ゲーム本編が終了いたしましたら結果発表となります。今回最も得点を獲得した優勝チームは第一三共株式会社の皆様(梅田 新さま、岡本 康希さま、髙市 伸宏さま、岡本 敦之さま)が率いるチームでした。おめでとうございました。 第一三共株式会社の皆様からはコメントを頂戴しています。 イベントに関するご感想 高度なログ解析を体験することができる、大変有意義で楽しいイベントでした!本物に近いインシデントのストーリーを通じて、ログや検知の重要性を真剣に学ぶことができました。 普段に行っていたセキュリティ設定やベストプラクティスの意味を、改めて深く理解することができました。 チームでの協力や、他チームとの競い合いを通じて、本当に楽しい切磋琢磨を体験することができました。また機会があればぜひ参加させていただきたいです!イベントの開催ありがとうございました! 工夫された点 時間が限られていることから手分けして課題に取り組み、スタックした場合にはペアまたはモブで解決に当たりました。普段からモブで作業をしているチームワークが発揮できたと思います。 表彰の様子(おめでとうございます!) 解説とパートナーソリューションについて 表彰後、今回のシナリオで実際に何が起きていたのかを AWS から解説させていただきました。インシデントの検出にはまずは Amazon GuardDuty が効果的であり、根本原因と被害範囲の調査のためにはしっかりと必要なログを保管し、いつでも取得できるような状態にしておくことが肝要です。今回は AWS のサービスだけでインシデントの調査を行っていただきましたが、こういった実際に起きうるインシデントに対して有用なサービスは他にもあります。そこで今回は AWS のパートナーである3社にも登壇いただき、パートナーソリューションについても紹介いただく場を提供させていただきました。 Splunk 2003年の創業以来、Splunkは、お客様が組織内のデータの広大かつ深遠な迷宮を探索するお手伝いをしています。 Splunkが目指すのは、より安全でレジリエントなデジタル世界を創造することです。Splunkは、組織の運営と安全を支えるセキュリティ運用、IT運用、エンジニアリングの各チームを支援することで、この目標に着実に近づいています。現在、世界最大級の大規模かつ複雑な環境を運用する多くの組織が、ミッションクリティカルなシステムを保護するためにSplunkを活用しています。 サイバーセキュリティクラウド 株式会社サイバーセキュリティクラウドは、「世界中の人々が安心安全に使えるサイバー空間を創造する」をビジョンに掲げ、Webアプリケーションのセキュリティサービスや脆弱性管理、クラウドセキュリティに関するサービスを提供する、日本発のセキュリティメーカーです。当社が提供する『CloudFastener(クラウドファスナー)』は、AWSに対応したフルマネージド型のセキュリティサービスです。脅威検知、脆弱性管理、データ保護などの支援を、お客様の環境や組織体制に応じて柔軟に提供し、ガバナンス・ポリシーの策定から復旧・修正対応まで、AWS環境におけるセキュリティ運用をワンストップで包括的にサポートします。 KnowBe4 Know Be4は、世界で70,000社以上に採用されているセキュリティ意識向上トレーニングとフィッシング訓練のグローバルリーダーです。ヒューマンリスクマネジメントプラットフォーム(HRM+)は、従業員のセキュリティに関する人的な脆弱性と強みを可視化し、個別に最適化されたトレーニングを提供。これにより、効果的にセキュリティ意識を向上させ、行動変容を促します。 トレーニングコンテンツは34ヶ国語以上に対応。多様なビジネス環境に対応し、「人的」セキュリティを強化することで、強固なセキュリティ文化の構築を支援します。 GameDayの後 さて、それでは実際に運用しているサービスに今回の経験を活かしていただくにはどうすればよいでしょうか。 今回体験いただいた Amazon GuardDuty、AWS CloudTrail や SIEM on Amazon OpenSearch Service を導入するのも良さそうですし、紹介いただいたパートナーソリューションを導入したりといった施策を進めるのも良さそうです。ただ、現実のサービスはゲームの状況よりも複雑です。単にサービスやソリューションを導入するのではなく、運用しているサービスの現状を把握し、必要な手立てを認識する必要があります。 そこで AWS では AWS Well-Architected Framework (W-A) をご用意しています。W-A はAWSがクラウドを10年以上の運用してきた経験や数多くのお客様とのやりとりをもとに作りあげた クラウド設計・運用のベストプラクティス集です。優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性という 6つの柱に基づいて設計されており、気になる要素だけ利用いただくことも可能です。今回であればセキュリティの柱を利用して、まずは運用しているサービスの状況把握をしてみるのはいかがでしょうか。 AWS ではこれからもヘルスケア・ライフサイエンス、そして半導体業界の皆さまに貢献できるよう、クラウド技術のご紹介や各種イベントを実施いたします。積極的に活用いただけますと幸いです。 このブログはアマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト光吉 隆雄が執筆しました。
こんにちは。ソリューションアーキテクトの疋田です。 2025 年 5 月 14 日に「 Apache Iceberg on AWS ミートアップ ~話題のIcebergをAWSで徹底活用~ 」と題したイベントを開催しました。ご参加いただきました皆様には、改めて御礼申し上げます。 本セミナーでは、AWS における Iceberg の活用についてさまざまな角度からご紹介しました。Iceberg 活用の全体像に加えて、マネージドな Iceberg のストレージである Amazon S3 Tables Bucket 、既存データレイクからの移行における考え方、リアルタイムデータ処理を実現するストリーミングワークロードの実装方法、更には機械学習における活用まで、幅広いトピックをご紹介しました。本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開致します。 すでに Iceberg を活用されている方も、これからはじめる方も是非ご確認下さい! セッションの紹介 Apache Iceberg on AWS アマゾン ウェブ サービス ジャパン合同会社 Principal Big Data Architect 関山 宜孝 資料ダウンロード 本セッションでは、Apache Iceberg の概要と主要なユースケース、AWS 上での利用方法についてご紹介しました。Iceberg は大規模なデータセットの分析に利用できるオープンテーブルフォーマットであり、様々な規模のデータを効率的かつ便利に扱う仕組みをもちます。異なるツール間を繋ぐ共通的なテーブル仕様としても機能し、幅広いユースケースに活用できます。AWS はオープンソースの Iceberg をより便利に利用するための仕組みをワンストップで提供しています。 Amazon Data Firehose や AWS Glue Zero-ETL によって、個別のデータパイプラインを実装しなくても様々なデータストアから Iceberg テーブルにデータを取り込むことができます。また、AWS Glue Data Catalog のテーブル最適化によりフルマネージドで Iceberg テーブルをメンテナンスすることができ、パフォーマンスとコストを継続的に最適化できます。AWS で Iceberg を活用することで、オープンソースの Iceberg を最大限活かしながら、データの取り込みやテーブルのメンテナンスをより簡単に実現できます。 Amazon S3 Tables – テーブルバケットと汎用バケット アマゾン ウェブ サービス ジャパン合同会社 Senior Storage Specialist Solutions Architect 焼尾 徹 資料ダウンロード 本セッションでは、AWS で Apache Iceberg を活用する際のストレージの選択肢である、 Amazon S3 Tables バケット と Amazon S3 汎用バケット について、汎用バケットの特徴を振り返りながら深掘りしました。S3 Tables は、表形式のデータに最適化された新しいバケットタイプで、Iceberg の仕組みをフルマネージドに提供します。S3 Tables によって、テーブルの内部的な仕組みを意識することなく、安全かつ効率的に Iceberg を利用できます。一方で、汎用バケット上での Iceberg の活用は歴史があり、カスタマイズ性が高く、Amazon S3 やIceberg の機能をフル活用できます。AWS では、それぞれのストレージをユースケースに応じて使い分けることができます。 Apache Iceberg 移行アプローチの勘所 アマゾン ウェブ サービス ジャパン合同会社 Analytics Specialist Solutions Architect 疋田 宗太郎 資料ダウンロード 本セッションでは、既存のデータレイクを Iceberg へ移行する際のアプローチについてご紹介しました。 Iceberg への移行を検討する際は、まず移行を通じて実現したい目的を確認し、それに基づいて移行後の構成を設計することが大切です。 Glue Data Calotag は Hive テーブルと Iceberg の両方を同時に管理できるため、全てのデータを一度に移行する必要はなく、移行の効果が大きいテーブルから段階的に実施できます。データパイプラインを Iceberg へ移行する際の対象は大きく分けてデータ取り込み / 変換ジョブ、テーブルデータ、コンシューマー側のツールの 3 つの要素が挙げられます。それぞれについて、データ規模、ファイル形式、更新頻度、移行方式、書き込み処理の扱い、移行前後のデータの検証、コストなどのポイントを抑えながら移行を計画していくことが重要です。 Apache IcebergとAWSで実現するストリーミングワークロード アマゾン ウェブ サービス ジャパン合同会社 Analytics Specialist Solutions Architect 深見 修平 資料ダウンロード 本セッションでは、Iceberg を活用したストリーミングワークロードに焦点を当てて AWS のサービスをどのように活用できるかご紹介しました。Iceberg のスキーマが柔軟に変更できる点や、データ品質を担保するための Write-Audit-Publish (WAP) の仕組み、Merge-on-Read (MOR) による性能最適化など、ストリーミングデータを扱うのに適した利用方法をご紹介しました。AWS での実装オプションとしては、 AWS Glue 上での Apache Spark Structured Streaming, Amazon Managed Service for Apache Flink 上での Apache Flink など多様な連携方法が利用できます。特に、Amazon Data Firehose は幅広いデータソースから Iceberg テーブルへのマネージドなデータの取り込みが可能です。また、プレビュー中の MySQL や PostgreSQL から Iceberg テーブルへの CDC 連携機能を使用すると、データベースの変更をニアリアルタイムで Iceberg テーブルへと取り込むことができます。 三菱UFJ銀行 金融市場領域におけるApache Iceberg / PyIcebergの可能性 株式会社三菱 UFJ 銀行 市場企画部市場エンジニアリング室 福田 晃平 氏 資料ダウンロード 最後は株式会社三菱 UFJ 銀行 (以下、三菱 UFJ 銀行)における、金融時系列テーブル管理における Iceberg と PyIceberg 活用の取り組みについて紹介しました。三菱 UFJ 銀行の市場部門では、伝統的な機械学習や生成 AI におけるモデルガバナンスとデータガバナンスを効果的に実現するため、特徴量のデータ品質管理やバージョン管理を実現するための仕組みを必要としていました。それらのデータはレコードレベルの更新や、スキーマ構造の柔軟な変更といった要件にも対応していく必要があります。 これらの要件に対応できるツールとして、Iceberg の活用に注目しました。Iceberg は、タグやブランチによるバージョン管理など、先述した特徴量のガバナンスに必要な多くの機能を備えています。しかしながら、日次時系列データのようにユースケースによっては〜数千万レコード程度のそれほど大きくないデータもあり、大規模なデータを扱う分散処理の仕組みを必ずしも必要としないことがあります。また、データサイエンティストのスキルセットとしても、JVM 系言語のスキルセットがない場合も多く、より慣れ親しんだツールによる活用を必要としていました。一方で、データやモデルのガバナンスはデータ規模に依存せずデータサイエンス共通の課題でもありました。 そこで、PyIceberg の検証を行うことにしました。PyIceberg は Python で Iceberg を操作するためのライブラリであり、Python のランタイムさえあれば簡単に Iceberg を操作できます。特徴量データの管理に求められる要件の PyIceberg での実現可能性を検証した結果、PyIceberg 単体ではテーブルメンテナンスなどに限界があるものの、AWS Glue の マネージドな機能で補完することで、 Amazon SageMaker AI や Glue、 AWS Lambda を組み合わせた堅牢な ML データ管理基盤を構築できることが示されました。 これらの検証結果を踏まえて、PyIceberg を活用してモデルガバナンスとデータガバナンスを実現しながら、データサイエンティストが伸び伸びと開発できるワークフローを整備していく展望が示されました。 まとめ 今回は、AWS での Iceberg の活用をテーマに、様々なセッションを用意させていただきました。本イベントをきっかけに、Iceberg を利用いただくことで、皆様のデータ分析ワークロードが少しでも楽になり、幸せになることを願っております。今後も、お客様のシステム運用を少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 疋田
2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催いたしました。本イベントには 22 社 50 名の方々にご参加いただき、生成 AI を活用したデータ分析の新しい可能性について、実践的な学びの場を提供することができました。 イベントの背景と目的 近年、企業の意思決定においてデータ活用は不可欠となっています。しかし、多くの企業が膨大なデータから迅速に意思決定につながるインサイトを得ることに苦心し、データ分析の専門知識を持つ人材の不足に直面しています。さらに、システム部門はダッシュボード作成に十分な工数を割くことができず、ビジネス部門は分析スキルの不足や情報の複雑さにより、効果的にデータ活用ができないという現状があります。これらの課題に対し、生成 AI 技術を活用した BI ツールが新たなソリューションとして注目を集めています。本ワークショップでは、AWS の最新サービスである Amazon Q in QuickSight を通じて、生成AI x BI のデータ分析アプローチを体験していただく機会を設けました。 セッション内容 生成 AI x BI の概要説明とデモ ワークショップの最初のセッションでは、データ分析における生成 AI の可能性と Amazon Q in QuickSight の機能について解説を行いました。自然言語でのダッシュボード作成、データの解釈に関する Q&A 機能、そしてデータストーリーの自動生成という 3 つの機能について、消費財業界向けのサンプルデータを用いたデモを実施しました。システム部門ユーザーとビジネス部門ユーザーそれぞれの視点から、具体的な活用シーンを紹介し、生成 AI と BI の融合がもたらす具体的なビジネス価値について説明しました。 ハンズオン 続くセッションでは、参加者の皆様に実際の Amazon Q in QuickSight を使用したダッシュボードの作成とデータ分析を体験していただきました。消費財業界の受注・出荷データを用いて、テーブル形式のビジュアルや時系列の積み上げ棒グラフなど、様々な形式のデータ可視化を自然言語での指示で作成しました。参加者は「受注金額が一番多い日」や「発注者ごとの出荷金額」といった具体的な問いかけを行い、Amazon Q in QuickSight が即座に適切なビジュアルと回答を提供する、これまでにない分析体験を得ることができました。 ユースケースディスカッション ディスカッションパートでは、参加者は実際の業務課題に基づいたデータ分析ダッシュボードの設計に取り組みました。このセッションでは、現場の具体的な課題からスタートし、生成 AI を活用した解決策の提案まで、段階的なアプローチで議論を深めていきました。 まず個人ワークでは、現場で直面している課題を具体的なストーリーとして言語化することに注力しました。参加者は「○○部署の A さんが××を見れなくて『XYZ できない』と困っている」という形式で課題を特定し、その可視化に必要な条件を 5W1H の形式で整理しました。 続くダッシュボード設計のフェーズでは、各参加者が具体的なラフスケッチを作成しました。ダッシュボードを端的に表現するタイトルの設定、ビジュアルの効果的な配置、フィルター機能の活用方法、KPI の視覚化方法など、実用的な観点から設計を進めました。特に今回は、生成 AI の活用を前提として、自然言語での問いかけとそれに対する期待する描画内容を具体的に検討し、Amazon Q in QuickSight の特徴を活かしたアイディアを考えていただきました。 グループディスカッションでは、各参加者が自身のダッシュボード案を説明し、活発な質疑応答が行われました。議論は特定した現場の課題、提案するダッシュボードの概要、生成 AI の活用方法、実装における工夫点など、多岐にわたりました。各グループで選出された代表者による全体発表では、実務に即した具体的な提案が共有され、参加者全員で知見を深めることができました。 懇親会 セッション終了後の懇親会では、参加者同士の交流を深めながら、各グループから提案されたダッシュボードのアイデアについて投票を行いました。参加者からの投票ではアルフレッサ伊賀様が、AWS メンバーからの投票ではアクタス則武様のアイデアが選出されました。両者とも、実務における課題を踏まえた実践的な提案として高く評価されました。 お客様の声 ワークショップ全体を通じて、他のお客様との交流による新しい知見の獲得や、BI と生成 AI の具体的な活用シーンの理解、実践的なハンズオン体験について、多くの好評の声をいただきました。特に、今後の活用領域として売上・業績予測や複数データの横断分析、自然言語による簡易作成機能への期待が寄せられ、具体的な業務適用への検討意欲も高まりました。 おわりに 本ワークショップは、生成 AI を活用したデータ分析の可能性と実用性について、参加者の皆様に具体的なイメージを持っていただく貴重な機会となりました。今後も、お客様のビジネス課題解決に貢献できるよう、より実践的で価値のある機会を提供してまいります。ご参加いただいた皆様に心より御礼申し上げます。
本記事は 2025 年 6 月 5 日に公開された “ Access Claude Sonnet 4 in Amazon Q Developer CLI ” を翻訳したものです。 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。この最新モデルは、SWE-bench でのエージェント型コーディングにおいて最先端の 72.7% のスコアを記録しており、コーディングにおいて優れた性能を発揮しています(詳細については Claude 4 の発表 をご覧ください)。強化されたコーディングと推論機能により、複雑なコードの分析、日常的な開発タスクの最適化、バグ修正の実装、bash コマンドの実行、新機能の開発を、高速なフィードバックループとより正確な応答で支援します。 Claude Sonnet 4を活用するために、Amazon Q Developerでは特定のClaude Sonnetモデルを簡単に選択できるようになっており、CLIでより柔軟な操作が可能になっています。 Claude Sonnet 4: バランスの取れたインテリジェンスを持つ高性能モデル Claude Sonnet 3.7: 拡張された思考能力を持つ高性能モデル Claude Sonnet 3.5: 高性能インテリジェントモデル Claude モデルの機能と比較の詳細については、 Anthropic モデル概要 を参照してください。 このブログ記事では、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法を説明し、簡単なデモを紹介します。 Claude Sonnet 4 の選択方法 Amazon Q Developer CLI の最新バージョン( v1.11.0 以降)に更新してください。インストール手順については、 Amazon Q for command line のインストール を参照してください。Claude Sonnet 4 には以下のオプションでアクセスできます: アクティブなチャット中に /model コマンドを使用して claude-4-sonnet を選択 q chat --model claude-4-sonnet で新しいチャットを開始 q settings chat.defaultModel claude-4-sonnet でデフォルトモデルとして設定 --model パラメータと設定でサポートされているモデル名は以下の通りです: claude-3.5-sonnet claude-3.7-sonnet (デフォルト) claude-4-sonnet モデル選択の優先順位 Q Developer CLI は以下の順序でモデルを選択します: 現在のセッションでのモデル選択( /model または --model による) 設定でのユーザー構成設定 システムデフォルト( Claude 3.7 Sonnet ) 主要な動作 Q Developer CLI エージェントは、特定のモデルが選択されていない場合、Claude 3.7 Sonnet をデフォルトとします。アクティブなチャットセッション中は、 /model コマンドを使用してモデル間をシームレスに切り替えできます。チャットの継続性はセッション間で維持され、会話が再開されたときにシステムは以前に選択されたモデルを保持します。Claude Sonnet 4 を好む場合、ユーザー設定でデフォルトモデルとして設定すると、すべての新しいチャットセッションに自動的に適用されますが、必要に応じて特定のモデル選択で設定を上書きできます。 図 1: セッションで読み込まれたモデルを表示する Q Developer CLI Claude Sonnet 4 と Q Developer CLI の実際の動作 Q Developer CLI で Claude Sonnet 4 に切り替えた後、その機能を実際のコーディング例で探ってみましょう。こちらがデモンストレーションで使用するプロンプトです。 以下の機能を持つ Python コマンドライン to-do リストアプリを作成してください: - 説明と優先度(low/medium/high)付きのタスクを追加 - インデックスでタスクを完了としてマーク - 優先度、次に挿入順でタスクをソート表示 - 完了ステータスを表示([x] 完了、[ ] 保留中) - 空のタスクと無効なインデックスのエラーハンドリング - タスクはメモリ内のみに保存 このアプリケーションを実装するコードを提供してください。 図 2: Claude Sonnet 4 の動作を示す Q Developer CLI インターフェイス 上記のデモンストレーションでは、Claude Sonnet 4 を使用した Q Developer CLI が、プロンプトで提供された要件を超えて、引用された説明を含む高度なコマンド解析、包括的なエラーハンドリング、型ヒントで強化されたクリーンなオブジェクト指向設計を実装しました。インターフェイスには、明確なエラーメッセージと列挙型(enum)を使った、シンプルで見やすい優先度の管理、タスクを明確に表現するフォーマットされた出力などを備えた、有用なガイダンスシステムが特徴です。 さらに、Claude Sonnet 4 を使用した Q Developer CLI は、実用的なエラーハンドリングの例と明確な使用方法を含む to-do アプリケーションの README ドキュメントも生成し、プロンプトの要件を構造化された使いやすいアプリケーションに変換しました。 まとめ Claude Sonnet 4 が利用可能になったことは、Amazon Q Developer の機能における重要な進歩を意味します。複雑なコードリファクタリングから効率的なドキュメント作成まで、Claude Sonnet 4 は複雑なタスクも日常的な開発作業も効率的に実行する手助けをします。 複雑なタスクに Claude Sonnet 4 を選択するか、特定のニーズに他のモデルを使用するかにかかわらず、Amazon Q Developer はあなたの好みに適応し、作業の進め方の効率性を維持しながら AI アシスタンスを最適化します。 Amazon Q Developer の最新バージョン( v1.11.0 )が CLI に登場し、強化されたモデル機能と選択オプションであなたの開発をサポートします。インストール手順については、 Amazon Q for Command line のインストール を参照してください。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Kirankumar Chandrashekar は、Amazon Q Developer に焦点を当てた AWS の生成 AI スペシャリストソリューションアーキテクトです。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code の深い専門知識を持ち、Amazon Q Developer を使用して顧客の開発プロセスの向上を支援しています。Kirankumar は複雑な顧客の課題を解決することに情熱を持ち、音楽、料理、旅行を楽しんでいます。
Amazon Nova は、Amazon Bedrock で利用できる、最先端のインテリジェンスと業界をリードするコストパフォーマンスを実現する新世代の基盤モデルで、4 つの理解モデル、2 つのクリエイティブコンテンツ生成モデル、1 つの Speech-to-Speech モデルが含まれます。Amazon Nova 理解モデルは、テキスト、画像、動画入力を受け入れてテキスト出力を生成するモデルで、機能、品質、スピード、コストについて幅広い選択肢を提供します。 この記事では 、Amazon Nova 理解モデルのプロンプトエンジニアリングの ベストプラクティス に従って、パフォーマンスを最適化する方法を紹介します。 Amazon Nova 理解モデルの特徴 Amazon Nova モデルには様々なニーズに合うように設計された 4 つの理解モデルが含まれています。 Amazon Nova Micro – 非常に低コストで最小レイテンシーのレスポンスを提供するテキストのみのモデルです。 Amazon Nova Lite – 非常に低コストのマルチモーダルモデルで、画像、動画、テキストの入力を高速で処理できます。 Amazon Nova Pro – 幅広いタスクの精度、速度、コストを最適に組み合わせた、高性能のマルチモーダルモデルです。 Amazon Nova Premier – 複雑なタスクに最適なマルチモーダルモデルであり、コスト効率の高いアプリケーション向けのカスタムモデルを蒸留するための教師にもなります。 各モデルの料金の詳細については、 Amazon Bedrock の料金ページ をご覧ください。 Amazon Nova 理解モデルのプロンプトエンジニアリング モデルを効果的に導いて品質の精度を向上させるため、明確な指示で構造化されたプロンプトを反復的に改善することが重要です。ユースケースに最適なプロンプトを開発できるように、次の要素を検討することをお勧めします。 プロンプトのユースケースの定義する タスク – モデルが具体的に何をするか ロール – モデルが想定すべきロール 応答スタイル – 出力の構造やトーン 指示 – モデルが順守すべきガイドライン 思考連鎖を利用するか モデルの応答を制限する明確で強い指示を与える Step-by-Step で考えることで構造的思考を促す フォーマットと構造 ##Task##、##Context##、##Example## のように、区切り文字を使用してプロンプトのセクションを分ける JSON、YAML、Markdown などの出力形式を指定する DO、DO NOT、MUST など、強い指示や制限を使用する 事前入力(prefill)して、前書きを省略したり指定した形式で出力することを誘導する Amazon Nova 理解モデルのプロンプト例 議事録を要約する以下の例を考えてみましょう。ベストプラクティスに従って Amazon Nova Pro のプロンプトは以下のシステムプロンプトから始まります。ここでは temperature を 0.2、 topP を 0.9 にしています。 あなたは会議議事録の分析と要約に長けた経験豊富なエグゼクティブアシスタントです。あなたの主な責任は、複雑な議論を明確で実行可能な要約にまとめることです。 以下の指示に従ってください。 ##INSTRUCTIONS## 1. ##NOTES## にある会議議事録を読んで理解してください 2. すべての出力を ##OUTPUTS## というセクションにマークダウン形式で入れてください。 3. 会議議事録を 5 文以内に要約してください。これを「全体概要」というセクションに入れてください。 4. 特定の人向けのアクションアイテムと、完了する必要があるものを数値で挙げてください。このリストを「アクションアイテム」というセクションに入れてください。 5. 該当する場合は、次回の会議でさらに詳しく議論する必要があるトピックをリストアップしてください。これを「次回の会議のトピック」というセクションに入れてください。 ユーザプロンプトには、以下の SF 風の架空の議事録を用意しました。最後に ##OUTPUTS## という文字列を事前入力して、前書きの省略とマークダウン形式での出力を誘導しています。 ##NOTES## ミーティング開催日:2050 年 3 月 5 日 ミーティング時間:午後 2 時 場所:銀河間本部会議室 3B 出席者: - キャプテン・スターダスト - ドクター・クェーサー - レディ・ネビュラ - サー・スーパーノヴァ - ミス・コメット 午後 2 時 5 分にキャプテン・スターダストが招集したミーティング 1. 最新のチームメンバー、コメットさんの紹介 2. プラネット・ゾグへの最近のミッションについての議論 - キャプテン・スターダスト:「全体的には成功だったが、ゾギアンとのコミュニケーションは難しかった。私たちは語学力を向上させる必要があります。」 - クエーサー博士:「同感です。すぐにゾギアン-英語辞書の作成に取り掛かります。」 - レディ・ネビュラ:「ゾギアンの料理は文字通りこの世のものとは思えませんでした!船でゾギアンのフードナイトをすることを検討すべきだ。」 3. セクター7における宇宙海賊問題への取り組み - サー・スーパーノバ:「この海賊に対処するには、もっと良い戦略が必要だ。彼らは今月、すでに 3 隻の貨物船を略奪しました。」 - キャプテン・スターダスト:「その地域でのパトロールを増やすことについて、スタービーム提督と話そう。 - クエーサー博士:「船が海賊に発見されないようにするのに役立つ新しいクローキング技術の開発に取り組んできました。プロトタイプを完成させるにはあと数週間かかります。」 4. 毎年恒例の銀河間ベイクオフのレビュー - レディ・ネビュラ:「私たちのチームがコンペティションで2位になったことを報告できてうれしいです!私たちのマーシャン・マッド・パイは大ヒットでした! - コメットさん:「来年は1位を目指しましょう。ジュピターゼリーの秘密のレシピがあって、それが勝つかもしれないと思う。 5. 次回のチャリティ募金活動の計画 - キャプテン・スターダスト:「インターギャラクティック・チャリティ・バザーのブースには、クリエイティブなアイディアが必要です。」 - サー・スーパーノバ:「『ダンク・ザ・エイリアン』のゲームはいかがですか?エイリアンの格好をしたボランティアに水風船を投げてもらうこともできます。」 - クエーサー博士:「勝者には賞品がもらえる『あの星の名前』トリビアゲームを作れるよ。」 - レディ・ネビュラ:「皆さん、素晴らしいアイディアですね。物資を集めてゲームの準備を始めましょう。」 6. 今後のチームビルディング・リトリート - コメットさん:「ムーン・リゾート・アンド・スパでのチームビルディング・リトリートを提案したいです。最近のミッションを終えて、絆を深め、リラックスする絶好の機会です。」 - キャプテン・スターダスト:「素晴らしいアイディアですね。予算を確認して、実現できるか見てみます。」 7. 次回の会議の議題項目 - ゾギアン英語辞典の最新情報 (クエーサー博士) - クローキング技術の進捗報告 (クエーサー博士) - セクター 7 (キャプテン・スターダスト) でのパトロール強化の結果 - 銀河間チャリティーバザーの最終準備 (全て) 会議は午後 3 時 15 分に延期されました。次回の会議は、2050 年 3 月 19 日午後2時に会議室3Bで開催される予定です。 銀河間本部。 ##OUTPUTS## 以下は Amazon Nova Pro の出力になります。マークダウン形式で出力され、各アクションアイテムの明確な担当者も特定しています。 ### 全体概要 会議では、新しいチームメンバーの紹介、プラネット・ゾグへのミッションの議論、宇宙海賊問題への取り組み、銀河間ベイクオフのレビュー、チャリティ募金活動の計画、チームビルディング・リトリート、そして次回の会議の議題項目について話し合われました。 ### アクションアイテム 1. クエーサー博士:ゾギアン-英語辞書の作成を開始する。 2. キャプテン・スターダスト:スタービーム提督とセクター7でのパトロール増加について話し合う。 3. クエーサー博士:新しいクローキング技術のプロトタイプを完成させる。 4. 全員:銀河間チャリティーバザーのブースのための物資を集める。 5. キャプテン・スターダスト:ムーン・リゾート・アンド・スパでのチームビルディング・リトリートの実現可能性と予算を確認する。 ### 次回の会議のトピック 1. ゾギアン英語辞典の最新情報 (クエーサー博士) 2. クローキング技術の進捗報告 (クエーサー博士) 3. セクター 7 でのパトロール強化の結果 (キャプテン・スターダスト) 4. 銀河間チャリティーバザーの最終準備 (全て) Function calling 生成 AI エージェントの台頭により Tool use(function calling) は 大規模言語モデル (LLM)にとって最も重要な機能のひとつとなりました。ジョブに適したツールを低レイテンシーで正しく選択するモデルの能力が、エージェントを使ったシステムの成功と失敗の分かれ目になる場合があります。 Amazon Nova 理解モデルの Tool use は構造化された API の呼び出しをサポートしており、ツール設定スキーマによるツールの選択をサポートしています。また、これらのツールをいつ発動させるか、させないかを決定するメカニズムも提供しています。 以下の例では、 ツール設定スキーマを渡してツールを呼び出しています。Amazon Nova 理解モデルではツールを呼び出す際に Greedy Decoding を使用するように、 temperature 、 topP 、 topK を 1 に設定することが推奨されています。 Converse API を使用する場合は、 temperature 、 topP は、 inferenceConfig 属性で指定し、 topK は additionalModelRequestFields 属性で指定します。これによりモデルはツールの選択において最高の精度を持つようになります。Greedy Decoding パラメータやその他のツールの使用例については、 Tool use (function calling) with Amazon Nova で詳しく説明されています。 tool_config = { "tools": [{ "toolSpec": { "name": "get_recipe", "description": "構造化されたレシピ生成システム", "inputSchema": { "json": { "type": "object", "properties": { "recipe": { "type": "object", "properties": { "name": {"type": "string"}, "ingredients": { "type": "array", "items": { "type": "object", "properties": { "item": {"type": "string"}, "amount": {"type": "number"}, "unit": {"type": "string"} } } }, "instructions": { "type": "array", "items": {"type": "string"} } }, "required": ["name", "ingredients", "instructions"] } } } } } }] } input_text = "チョコレートラバケーキのレシピを教えてください" messages = [{ "role": "user", "content": [{"text": input_text}] }] # 推論パラメーターを指定 inf_params = {"topP": 1, "temperature": 1} # additionalModelRequestFields でモデル固有の推論パラメータ (topK=1) を指定 response = client.converse( modelId="us.amazon.nova-lite-v1:0", messages=messages, toolConfig=tool_config, inferenceConfig=inf_params, additionalModelRequestFields={"inferenceConfig": {"topK": 1}} ) まとめ Amazon Nova 理解モデルは、Amazon Bedrock で利用可能な高性能かつコスト効率に優れた次世代基盤モデルです。4 つの理解モデルは、機能、品質、スピード、コストに応じて選択できます。Amazon Nova 理解モデルのパフォーマンスを最適化するには、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことが推奨されます。また、これらの手法を活用することでより安価なモデルでも十分なパフォーマンスを発揮しコスト最適化に寄与する可能性があります。
はじめに アマゾン ウェブ サービス (以下、AWS) は、2025年6月30日に Amazon Connect の機能として Amazon Connect Global Resiliency(以下、ACGR)を 日本で一般提供開始 しました。これにより、AWS アジアパシフィック(東京)リージョンで Amazon Connect インスタンスをご利用されているお客様が、AWS アジアパシフィック(大阪)リージョンのインスタンスに設定を同期し、フェイルオーバーできるようになりました。日本国内にある2つの AWS リージョン間で Amazon Connect Global Resiliency を利用することによって、地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることができます。また、データを日本国内に保持しながら、コンタクトセンターの可用性を高めることができます。 本ブログでは Amazon Connect が備えている信頼性について改めて解説した上で、ACGR の機能概要と利用にあたりお客様にご理解いただきたい事項、日本で利用可能なACGR の機能についてご紹介します。ACGR の詳細な解説については、 管理者ガイド をご参照ください。 Amazon Connect の信頼性 Amazon Connect は、AWS グローバルインフラストラクチャ上にデプロイされるオムニチャネルのクラウドコンタクトセンターです。AWS グローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心に構築されています。AWS リージョンは、低レイテンシー、高スループット、高い冗長性を備えたネットワークによって接続された、物理的に独立した複数のアベイラビリティーゾーンを提供します。アベイラビリティーゾーンは、単一または複数のデータセンターインフラストラクチャよりも可用性が高く、耐障害性に優れ、スケーラブルです。 Amazon Connect は、サービスを提供している各 AWS リージョンにおいて、3つ以上のアベイラビリティーゾーン (AZ) に冗長な専用ネットワーク経路を持つ、複数の通信事業者と接続しています。特定のコンポーネント、データセンター、または AZ 全体に障害が発生した場合、影響を受ける箇所は自動的にシステムから除外されます。これにより、お客様に一貫した品質の体験を提供することが可能です。 Amazon Connect に接続する各通信事業者は、アクティブ/アクティブ構成で複数の AZ に接続されています。これにより、ネットワーク経路や AZ 全体の障害がお客様の体験に影響を与えることはありません。また、異なる通信事業者の複数電話番号を利用するデザインにすることで、万一通信事業者に障害が発生した場合でもお客様は別の電話番号を利用してコンタクトセンターに問い合わせることが可能になり、影響を最小限に抑えることができます。詳細については Amazon Connect の耐障害性 をご覧下さい。 図1.単一リージョンのテレフォニーとソフトフォンのアーキテクチャ(出典: Amazon Connect 管理者ガイド ) マルチリージョンの Amazon Connect デプロイメントを検討されるお客様はまず、シングルリージョン/マルチ AZ デプロイメントではお客様のニーズを満たせない理由を明確にし、理解することが重要です。次に、お客様の災害復旧やビジネス継続性に関する要件が、運用やコンプライアンス、その他の規則や規制に関連し、マルチリージョンを必須要件としているかなどを 、AWS のソリューションアーキテクトと議論してください。また、お客様の本番環境で ACGR をご利用いただくには、 AWS Well-Architected Framework の Amazon Connect Custom Lens を確認することが前提条件となります。Well-Architected Framework のレビューを実施することで、ACGR の必要性を確認することができます。 ACGR の機能概要 ACGR は、Amazon Connect に地理的なテレフォニー(電話通信)の冗長性を提供し、予期しないリージョンの機能停止や中断が発生した場合に、インバウンドトラフィックとエージェントを別のリージョンの Amazon Connect インスタンスに分散する柔軟なソリューションを提供します。お客様は複数の AWS リージョンに Amazon Connect をデプロイし、どのリージョンで着信コールを受信し、エージェントが対応するかを API によって制御できます。 コンタクトセンターのお客様は、フェールオーバー後も同一の電話番号を使用して問い合わせが可能です。 コンタクトセンターのエージェントは、フェールオーバー後もログインし直すことなく業務継続が可能です。 ソースインスタンスとレプリカインスタンスは、自動的に双方向で設定を同期します。 これらの機能を理解するために、以下ではいくつかの概念と関連用語を解説します。 トラフィック分散グループ (TDG) トラフィック分散グループ (TDG) は、異なる AWS リージョンにある Amazon Connect インスタンスをリンクするリソースです。ACGR の使用を開始すると、デフォルトの TDG が1つ作成されますが、事業部別窓口などのユースケースに基づいて TDG を追加することもできます。TDG では、トラフィックやエージェントログインの分散を割合 (%) で指定します。コンタクトセンターの管理者はTDG ごとの割合を操作することで、お客様の問い合わせトラフィックをルーティングするリージョンと、エージェントがログインするリージョンを変化させることができます。 図2.トラフィック分散グループ(出典: Amazon Connect Global Resiliency Workshop ) グローバルサインイン ACGR により、コンタクトセンターのエージェントは業務開始時に1度サインインするだけで、どのリージョンを利用しているかを意識することなく、現在アクティブなリージョンを利用してお客様の問い合わせに対応できます。管理者が API を使用して TDG のエージェントログイン先を変更した場合、エージェントが再ログインすることなくアクティブなリージョンに切り替わります。これは、エージェントが ACGR に対応するオプションを有効化したカスタム CCP を利用している場合、またはエージェントワークスペースを使用している場合に有効です。 図3.グローバルサインイン(出典: Amazon Connect Global Resiliency Workshop ) グローバル設定管理 (GSM) ACGR の利用を開始する際は、API を使用してソースインスタンスのレプリカを作成します。これにより、グローバル設定管理サービスは初期レプリケーションプロセスとして、AWS リージョン間で Amazon Connect 設定を複製します。この最初のステップが正常に完了すると、複製されたリソースに対して行われた変更は、ソースまたはレプリカインスタンスのいずれであっても、リージョン間で継続的に双方向で同期されます。同期対象のリソースは こちら を参照してください。レポート、ルール、ビューなどのデータや設定は対象外です。また Amazon Connect が連携している Amazon Lex や AWS Lambda、Amazon S3 上のデータも同期の対象外です。対象外の設定やデータのうち運用に必要となるものは、お客様の責任において設定やデータの複製を実施いただく必要があります。 図4.グローバル設定管理(出典: Amazon Connect Global Resiliency Workshop ) ACGR の監視と運用 ACGR の運用は、お客様と AWS の共同責任です。AWS は2つの AWS リージョンでフェイルオーバーするためのインフラストラクチャを提供する責任があります。お客様は、インスタンス設定を最新の状態に保ち、お客様ごとのビジネス要件に基づいてトラフィックとエージェントの分散を管理する責任があります。また、インスタンスを監視しシステム状態とパフォーマンスにおける異常や、通常と異なる動作を発見する仕組みを準備することが求められます。さらにお客様は、独自の事業継続プロセス (BCP) および標準運用手順 (SOP) において、フェールオーバーの承認プロセスや判断基準を定義しておく必要があります。 ACGR の運用にあたっては、Amazon Connect インスタンスのモニタリングと、ACGR のモニタリングも必要となります。インスタンスのモニタリングでは、アクティブな通話数やコンタクトフローのエラーなどにより、Amazon Connect の健全性を確認します。ACGR のモニタリングは、設定のミラーリングプロセスを確認することで、ACGR 自体の健全性を確認します。これらの監視にあたっては、 Amazon CloudWatch や AWS CloudTrail を活用することができます。 日本における ACGR 利用上の注意事項 AWS アジアパシフィック (大阪) リージョンの Amazon Connect は、AWS アジアパシフィック (東京) リージョンのビジネス継続性を確保するために、音声、チャット、タスクのチャネルを利用することが可能です。2025年6月30日時点では、アジアパシフィック (大阪) リージョンにおいて以下の機能はサポートされていません。 Amazon Lex Amazon Connect Contact Lens Amazon Q in Connect Amazon Connect Customer Profiles Amazon Connect Cases アプリ内通話、ウェブ通話、ビデオ通話機能、および画面共有機能 予測、キャパシティプランニング、スケジューリング Amazon Connect アウトバウンドキャンペーン このため TDG による分散は、通常時が東京100% / 大阪0%、フェールオーバー時は東京0% / 大阪100% という設定で運用されることになると想定しています。これ以外の設定で東京と大阪を同時に利用する場合、お客様およびエージェントごとの体験に差異が生じる恐れがあります。また、フェールオーバー時に継続利用可能な電話番号は、2025年6月30日時点で TFN (料金無料通話番号)をサポートします。 まとめ ACGR の一般提供開始により、地理的に離れた場所での災害対策を必要とするお客様や、国内でデータを保存する要件のあるお客様のニーズにお応えすることが可能になります。ACGR の利用を開始するには、AWS のアカウントチーム、テクニカルアカウントマネージャー、または Amazon Connect ソリューションアーキテクトにお問い合わせください。詳細なセットアップの方法や、切り替えテストの手順、ベストプラクティスについては、 Amazon Connect Global Resiliency Workshop を参照してください。
みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 先週は年に一度のAWS Summitが開催され、私はいくつかのブースで展示の担当をしていました。会場では、興味津々で「これを家に帰ってすぐ作ってみたい!」と言いながら、一生懸命メモを取っているお客様もいて、デモを開発して本当によかったと感じました。展示ブースではAIやIoTを組み合わせたものが多く、実際に動く様子を見てもらえると、楽しさやワクワク感がさらに増すなと思いました。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月23日週の主要なアップデート 6/23(月) Amazon WorkSpaces Core マネージドインスタンスによる VDI 移行の簡素化を発表 Amazon WorkSpaces Core Managed Instances を発表しました。これは仮想デスクトップ環境 (VDI) の移行をより簡単にするための新機能です。この機能は EC2 Managed Instances をベースにしており、お客様の AWS アカウント内でリソースをプロビジョニングできます。また、永続的および非永続的なワークロードに対するインフラストラクチャのライフサイクル管理も自動的に行います。また、既存の割引、Savings Plan、およびオンデマンドキャパシティ予約(ODCR)のようなその他の機能を、WorkSpacesのシンプルな運用で利用できるようになっています。 Amazon VPC のデフォルトルートテーブル容量が増加 Amazon VPC のルートテーブルのデフォルト容量が拡大されたことをお知らせします。これまでルートテーブルに設定できるルート数は 1 テーブルあたり 50 個が上限でしたが、今回のアップデートで 500 個まで拡張されました。従来は 50 個以上のルートを設定したい場合、制限緩和のリクエストを AWS に申請する必要がありましたが、この手続きが不要になります。 Amazon Time Sync Service がナノ秒のハードウェアパケットタイムスタンプに対応 Amazon Time Sync Service に、ナノ秒単位のハードウェアパケットタイムスタンプ機能が追加されました。この機能は、対応する Amazon EC2 インスタンスで利用可能です。この新機能により、Amazonのネットワークインフラストラクチャと AWS Nitro System を活用して、入力されるすべてのネットワークパケットに 64 bit のナノ秒精度のタイムスタンプを付与することができます。この機能により、EC2 インスタンスに届くパケットの順序や公平性の判定、片方向のネットワーク遅延の測定が可能になり、オンプレミスのソリューションと比較してより高い精度と正確性で分散システムのトランザクション速度を向上させることができます。 6/24(火) カスタマーカーボンフットプリントツールに地域ベースの排出量データが追加 AWSのカーボンフットプリントを計測するツール「Customer Carbon Footprint Tool (CCFT)」が機能強化されました。これまでは市場ベース方式 (MBM) による排出量計算のみでしたが、今回のアップデートで地域ベース方式 (LBM) による計算も追加されました。さらに、CloudFront の使用による推定排出量が、既存の EC2 や S3 と同様にサービスごとの内訳で確認できるようになりました。LBM と MBM の違いについては、 GHG プロトコルのスコープ 2 ガイダンス を参照ください。 Amazon Bedrock Guardrails がコンテンツフィルターと拒否トピックの階層化を発表 Amazon Bedrock Guardrails の新機能として、コンテンツフィルターと制限トピックに関する新しい階層が発表されました。Amazon Bedrock Guardrails は、有害なコンテンツやプロンプト攻撃を検出・ブロックし、特定のトピックを制限したり、個人を特定できる情報 (PII) を入力プロンプトやモデルの応答から編集したりするための設定可能な保護機能を提供します。また、モデルの誤った出力 (ハルシネーション) を検出・ブロックし、自動推論チェックを使用してモデルの応答における事実の主張を特定、修正、説明する機能も備えています。この Guardrails は、Amazon Bedrock でホストされているファンデーションモデル、自己ホスト型モデル、Bedrock 以外のサードパーティモデルなど、あらゆるモデルに ApplyGuardrail API を使用して適用できます。これにより、一貫したユーザー体験を提供し、安全性とプライバシー制御の標準化を支援します。また、新しく追加された Standard tier では、誤字脱字などの変更を含むコンテキストをより深く理解し、最大 60 の言語に対応したコンテンツの検出とフィルタリングが可能になります。 re:Post と re:Post Private に インテリジェント検索機能を発表 AWS re:Post と AWS re:Post Private に、新しい「インテリジェント検索」機能が追加されました。この機能により、AWS に関する情報をより効率的に、直感的に検索できるようになります。従来は AWS の公式ドキュメントやコミュニティの投稿など、複数のソースを個別に検索する必要がありましたが、インテリジェント検索では、これらの情報源から統合的に回答を得ることができます。例えば、IAM のパーミッション関連のエラーについて調べたい場合、自然な言葉で質問するだけで、AWS の様々なリソースから総合的な回答が得られます。セットアップは re:Post Private Administration Guide を参照ください。 6/25(水) AWS Glue で、フルテーブルアクセス権限を持つ AWS Lake Formation テーブルに対する Apache Spark の機能が強化 AWS Glue で Lake Formation のテーブルに対する Apache Spark の機能が強化されました。AWS Glue 5.0 の Apache Spark ジョブにおいて、ジョブロールが完全なテーブルアクセス権を持っている場合、AWS Lake Formation で登録されたテーブルに対する読み書き操作が可能になりました。これにより、同一の Apache Spark アプリケーション内で、Apache Hive やIcebergテーブルに対して CREATE、ALTER、DELETE、UPDATE、MERGE INTO などのデータ操作言語 (DML) 操作が実行できるようになりました。詳しくは、AWS Glue の ドキュメント をご覧ください。 Amazon Bedrock Flows が永続的な長時間実行とインラインコードサポートのプレビューを発表 Amazon Bedrock Flows は、基盤モデル (FM)、Amazon Bedrock Prompts、Amazon Bedrock Agents、Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails、その他の AWS サービスを連携させて、生成系 AI のワークフローを構築・拡張できるサービスです。今回のアップデートでは、長時間実行可能な永続的な実行機能とインラインコードのサポートがプレビューとして発表されました。これにより、ワークフロー開発と管理が大幅に効率化され、生成系 AI アプリケーションの構築に集中できるようになります。Amazon Bedrock Flows で長時間実行とインラインコード実行のプレビューが開始されました。従来は各ステップで 2 分のタイムアウト制限がありましたが、今回のアップデートで 15 分まで延長され、複雑な生成 AI ワークフローを実行しやすくできるようになりました。また、簡単なデータ処理のために Lambda 関数を作成する必要がなくなり、Python スクリプトを直接実行できるインラインコードノードが追加されました。 Amazon SageMaker で Git から S3 への自動同期がサポートされました Amazon SageMaker Unified Studio において、プロジェクトの Git リポジトリから Amazon S3 バケットへ自動的にファイルを同期する新機能をリリースしました。Amazon SageMaker Unified Studio は、AWS のアナリティクスや AI/ML サービスの機能やツールを統合した、データと AI 開発のための統合環境です。この環境では、単一のインターフェースからワークフローの構築、デプロイ、実行、監視が可能です。この新機能の最も重要なポイントは、開発環境で行ったコード変更を本番環境に自動的に反映できることです。これにより、手動での作業が不要となり、開発者のワークフローが効率化されます。詳細は ドキュメント を参照ください。 6/26(木) Amazon Braket が IQM Garnet で動的な回路機能を追加 Amazon Braket で、IQM 社の Garnet という量子プロセッシングユニット(QPU)上での動的回路機能の実験的サポートが開始されました。この機能強化により、量子研究者や開発者は回路の途中で測定を行い、その結果に基づいて後続の操作を制御できるようになりました。動的回路は量子エラーの軽減や修正に不可欠な要素であり、量子ビットの再利用による効率化や、条件付きロジックを必要とするアルゴリズムの実験を可能にします。この新機能により、ユーザーは 1 回の回路実行中に量子ビットをリセットして再利用したり、測定結果に基づいて条件付きの操作を適用したりすることができます。 Amazon CloudWatch で AWS Glue Data Catalog の使用状況メトリクスが利用可能に AWS Glue Data Catalogの利用状況メトリクスが Amazon CloudWatch で利用可能になりました。これは、データレイクハウス環境での API 利用状況を詳しく把握したいというお客様のニーズに応える重要なアップデートです。AWS Glue Data Catalog は、データレイクハウスのメタデータを管理するサービスですが、今回のアップデートにより、その API の使用状況を CloudWatch で監視できるようになりました。この機能は、Data Catalog が利用可能なすべての AWS リージョンで利用可能です。詳細は ブログ を参照ください。 AWS IoT Device Management の マネージド統合機能が 一般提供開始 AWS IoT Device Management で「マネージド統合」が一般提供開始されました。この機能は、異なるメーカーや接続プロトコルを使用する IoT デバイスの管理を簡素化することを目的としています。開発者は、直接接続、ハブベース、サードパーティのクラウドベースなど、接続タイプに関係なく、単一の統合インターフェースを通じて多様な IoT デバイスの導入と管理が可能になりました。マネージド統合では、Cloud-to-Cloud (C2C) コネクタとデバイスデータモデルテンプレートを使用できます。プレビュー段階では、パートナーやベンダーから提供される事前構築された C2C コネクタのカタログと、80 個以上のデバイスデータモデルテンプレートにアクセスできましたが、今回の一般提供では、開発者が独自のコネクタを作成・公開し、テンプレートをカスタマイズして新しいデータモデルを作成できるようになりました。 6/27(金) Amazon Route 53 が Resolver エンドポイントのキャパシティ使用率メトリックを提供開始 Route 53 Resolverエンドポイントのクエリ処理能力 (キャパシティ) を監視するための新しい Amazon CloudWatch メトリクス (ResolverEndpointCapacityStatus) が利用可能になりました。この機能により、VPC 内の Resolver エンドポイントに関連付けられた Elastic Network Interface (ENI) のキャパシティ状態を簡単に確認できるようになります。これまでは、DNSクエリの数を 5 分間隔で監視し、手動で制限に達する時期を予測する必要がありましたが、新機能では各エンドポイントのキャパシティ状態を直接確認できます。 AWS Firewall Manager が AWS WAF L7 DDOS マネージドルールをサポート AWS Firewall Manager において、AWS WAF の L7 DDoS 対策のマネージドルールがサポートされるようになりました。これは、アプリケーション層 (L7) での DDoS 保護を強化する機能です。AWS WAF のマネージドルールグループが、Amazon CloudFront や Application Load Balancer (ALB) などの AWS サービス上で動作するアプリケーションに対する DDoS 攻撃を自動的に検知し、軽減します。 Amazon Q の Java 開発者向けアップグレード変換 CLI が一般提供開始 Amazon Q Developer の Java アップグレード変換用 CLI (コマンドラインインターフェース) が一般提供開始されたことをお知らせします。この機能により、コマンドラインから Amazon Q Developer の変換機能を呼び出し、大規模な Java のアップグレードを実行できるようになりました。この新機能では、Java アプリケーションを Java 8、11、17、21 のソースバージョンから、Java 17 または 21 のターゲットバージョンへアップグレードすることが可能です。これは従来の IDE に加えて、新たに CLI でも利用できるようになりました。 AWS Summit でご覧いただいたものをこれから手元で試してみるのも面白いかもしれませんね。Summit 開催後には、ふりかえりブログが出てくると思いますので、そちらもお楽しみに。それでは、また来週お会いしましょう! 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。
2025年5月12日〜16日、経済産業省が推進するプログラム『 Generative AI Accelerator Challenge(GENIAC) 』の採択者と共に、米国ベイエリアおよびシアトルの米大手モデルプロバイダーを訪問し、技術交流セッションを実施しました。GENIAC は、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が推進する取り組みで、日本国内の生成 AI 基盤モデル開発力を底上げし、企業等の創意工夫を促すことを目的とするものです。AWSは計算資源の提供や技術支援、コミュニティ形成支援を行っております。今回の訪米は、グローバルモデルプロバイダーとの意見交換及び最新トレンドの把握を目的として、GENIACコミュニティに参画する6社( 株式会社リコー 、 カラクリ株式会社 、 ウーブン・バイ・トヨタ株式会社 、 松尾研究所 、 株式会社ユビタス 、 フューチャー株式会社 )から経営層・技術責任者計7名をお招きしました。 左から松尾研究所 村上取締役、上林様、フューチャー株式会社 森下 Senior Architect、ウーブン・バイ・トヨタ株式会社 小堀 Director、株式会社リコー 中田乙一 様、カラクリ株式会社 中山CPO、株式会社ユビタス 中坪 Senior Director プログラム概要 1. Japan Innovation Campusでのビジネスセッション(5/12 11 am – 1 pm) 経済産業省が主催するシリコンバレーのイノベーション拠点である Japan Innovation Campus にて、日本からの参加者6社は日本人起業家3名( Glasp Nakayashiki CEO, I’mbesideyou Kamiya CEO, and Ando COO)とのパネルディスカッションを実施しました。日本と米国の市場の違いや米国でのビジネスの魅力やチャレンジついてのインプットを得ました。また現地VCとAWSによるMeet Upイベントでは株式会社ユビタスが参加し、現地VCであるElevation CapitalのKrishna Mehra (AI Partner)および現地スタートアップ企業であるAdoptAのDeepak Anchala (CEO)と意見交換をしました。日本への投資意欲の実態を体感するとともに、AI Drivenな事業創造の重要性を認識しました。 2.Anthtropicとの対話セッション(5/12 3pm – 5 pm) Anthropic は、サンフランシスコに拠点を置くAIスタートアップで、安全性と信頼性を重視した大規模言語モデル(LLM)の開発を行っています。創業者はOpenAIの元メンバーであり、同社の「Claude」は、高度な対話能力と直感的な操作性で注目を集めています。Anthropicからは、Jason Kim氏、Ethan氏、Sam氏が参加し、知見共有セッションを実施しました。Claude Codeの活用方法や顧客実装に関する知見が共有され、双方にとって示唆を得られる生産的な技術交流となりました。 3.Metaとの対話セッション(5/13 9 am – 12 pm) Meta は、生成AI分野でも積極的に開発を進めており、独自の大規模言語モデル「Llama(ラマ)」シリーズを提供しています。Metaからは、Eissa Jamil氏(パートナーエンジニアリングマネージャー)、Christine Hayden氏(カスタマーサクセスリード)、Hamid Shojanazeri氏(Llama/PyTorchのパートナーエンジニアリングマネージャー)、Joe Spisak氏(ジェネレーティブAIディレクター)が参加し、GENIAC参加者と3時間に及ぶ討議を行いました。 4.NVIDIAとの対話セッション(5/13 2 pm – 6 pm) NVIDIA は、GPU(グラフィックス処理ユニット)で世界的に知られる半導体企業であり、生成AIの基盤を支える中心的な存在です。NVIDIAからは、Yogesh Agrawal氏(データセンタービジネス担当VP)、Jacon Kern氏(AWS Cosellリード)、Mukundhan Srinivasan氏(NeMo GTM)、Jeff Lattomus氏(DGXC セールスリーダー)が参加し、GENIAC参加者との対話を行いました。NVIDIAのプロダクトチームとサービスソリューションアーキテクトより、NeMo、NIMs、Dynamoに関する最新の技術情報とトレンドについて詳細な説明が行われました。NVIDIA DGX Cloudの紹介では、NVIDIAとAWS合同のQ&Aセッションが実施されました。 5.Annapurna Labとの対話セッション(5/14 10 am – 12 pm) Annapurna Labsは、Amazonが買収した半導体開発企業で、AWSの独自チップの設計を担っています。代表的な製品には、推論用チップ「 Inferentia 」や学習用チップ「 Trainium 」があり、これらはコスト効率よく大規模なAIワークロードを処理するために最適化されています。AWSからは、AnnapurnaのHead of BD/GTMであるKamran Khanが参加し、GENIAC参加者との対話を行いました。Karakuriの中山CPOから現状の活用方法についてシェアされるとともに、Trainiumの今後の展望について共有されました。 6.Cohereとの対話セッション(5/14 2 pm – 4 pm) Cohere は、カナダ・トロント発のAIスタートアップで、エンタープライズ向けに特化した大規模言語モデル(LLM)の開発を行っています。CohereからはSaurabh氏(CTO)とGokce氏(MLリサーチャー)が参加しました。 7.AWS Bedrockの市場動向(5/15 3 pm – 5 pm) AWSからは Amazon Bedrock のGTMチームのEugene Kawamoto(Director)が参加しました。Eugene Kawamotoは、Amazon BedrockおよびAI ServicesのGTMの立場から見たAWSの現状と米国における生成AIのニーズとトレンドについて共有しました。生成AIのトレンドとしてAgentic AIの普及とそのエコシステムについての重要性についての言及がありました。日本の参加者を交えた生成AIのモデル開発とGTMのアイデアについての意見交換がされました。 8.Amazon SageMaker HyperPod、Amazon AGIチームによるEBCセッション(5/16 9 am – 11 am) AWSからは、 Amazon SageMaker HyperPod サービスチームのRajneesh SinghとAmazon AGI AIインフラストラクチャの製品責任者であるSejun Raが登壇し、Amazon NovaとAmazon SageMaker HyperPodを使用したモデル開発に関する説明を行いました。 参加者の声 株式会社カラクリ 中山CPO: 世界トップ企業の専門家たちや現地で挑戦する日本人起業家たちと会話し、そこで得た知見をもとに先を見据えた意思決定ができました。セッティングしていただいたAWSの皆様ありがとうございました。 ウーブン・バイ・トヨタ株式会社 小堀 Director: 今回の視察ではAnthropic、Meta、Cohereなど生成AI開発の最前線を視察し大いに刺激を受けた。一方で、日本のAI事業社にとって資金調達やユースケース拡大の課題も認識でき大きな学びがありました。 松尾研究室 村上取締役: Big Techの強さはもちろん感じましたが、日本のモデル開発事業者やAIエンジニアが十分戦えるレベルにいることを再確認することもできました。勝ち筋を見極め協調と差別化のバランスを取ることが重要です。今回得た知見を活用し、今後も松尾研として日本全体を支援していきます。 株式会社ユビタス 中坪 Senior Director: 今回の視察ではAnthropic、Meta、Cohereなど生成AI開発の最前線を視察し大いに刺激を受けた。一方で、日本のAI事業社にとって資金調達やユースケース拡大の課題も認識でき大きな学びがありました。 フューチャー株式会社 森下 Senior Architect: この度は貴重な視察の機会を設けていただきありがとうございました。今後自社のビジネスをどのように展開していくかという点で多くの示唆をいただき、また今後国内企業が成功を収めるためには様々な国内外の企業と協力体制を築いていくことが重要になると感じました。 株式会社リコー 中田乙一様: AWSチームの皆様の献身的なサポートのおかげで、貴重なネットワーキングの機会を得ることができました。米国やカナダの主要企業との対話を通じて、当社が取り組むべき注力分野やアプローチについて新たな視点を得ることができ、大変有意義でした。さらに、参加組織間の強いつながりも生まれ、特に意味のある経験となりました。 AWSは今後もGENIACコミュニティの活動を継続的に支援していきます。また、AWSは生成AIの社会実装を加速するために「 生成AI実用化推進プログラム 」も展開しています。これは、製造業、金融、医療、教育など幅広い業界のニーズに応じて、生成AIのビジネス現場での具体的な活用を支援する取り組みです。コミュニティイベントも開催されますので、ぜひ奮ってご参加ください。 このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャーである田村 圭が執筆しました。
みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 先週開催された AWS Summit Japan 2025 、みなさまお楽しみいただけましたか? 残念ながら参加できなかった、という方も 7/11 までの期間限定でコンテンツを配信中となっておりますので、ぜひ上記サイトよりご登録の上ご覧ください! 今週は AWS Summit Week でしたが、Amazon Bedrock Guardrailsの日本語対応や AWS ジャパン 生成AI実用化推進プログラムの新プラン(GENIAC-PRIZE 応募者支援プラン及び Agentic AI 実用化推進プラン)が発表されています。Summit コンテンツも視聴しながら、ぜひ本ブログもキャッチアップにお役立てください! それでは、6月23日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Amazon Bedrock Guardrails が日本語に対応しました 」を公開 Amazon Bedrock Guardrails が待望の日本語コンテンツフィルタリングに対応し、日本語特有の表現や文脈を理解した高精度な有害コンテンツ検出が可能になりました。従来は英語のみの対応だったため、日本語での生成AI アプリケーション開発では十分な安全対策が困難でしたが、今回のアップデートにより個人情報や機密情報の漏洩防止、不適切なトピックの拒否設定などが日本語環境でも実現できます。 ブログ記事「 生成AI実用化推進プログラムに2つの新プランを追加 」を公開 AWS ジャパンが「生成AI実用化支援プログラム」において、日本の生成AI実用化を加速するための2つの新プランを追加しました。新プランでは、経済産業省とNEDOが主催する「GENIAC-PRIZE」への応募者の計算リソースの調達から実装・事業化までを一貫してサポートする「GENIAC-PRIZE応募者支援プラン」と、自律的なAI(Agentic AI)の実用化を総合的に支援するために設計思想策定から運用体制確立までをサポートする「Agentic AI実用化推進プラン」の二つを新たに提供しています。従来のプランも含めて、みなさまのご興味に応じてぜひ応募をご検討ください。 ブログ記事「 AWS Summit Japan 2025で体験!生成 AI でロボットが人間の指示を理解する未来 」を公開 AWS Summit Japan 2025で発表された IoT、ロボット、LLM の融合技術は、物理世界とデジタル世界の境界を取り払う革新的なアプローチとして大きな注目を集めています。この技術により、工場の製造ロボットが自然言語で作業指示を理解し、IoT センサーからのリアルタイムデータを基に自律的に判断・行動することが可能になり、従来の定型的な作業から創造的な問題解決まで幅広く対応できるようになります。 サービスアップデート Amazon Q Developer の Java アップグレード変換機能が CLI で一般提供開始 Amazon Q Developer Java アップグレード変換 CLI の一般提供が開始されました。この CLI を使えば、コマンドラインから Java アプリケーションのソースコードを最新バージョンにアップグレードできます。主な機能は、Java 8/11/17/21 から 17/21 へのアップグレード、選択的なライブラリアップグレード、Oracle から PostgreSQL への SQL 変換です。米国東部 (バージニア北部) と欧州 (フランクフルト) の AWS リージョンで Linux と Mac OS から利用可能です。 Amazon CloudWatch Investigations でトラブルシューティングを加速(一般提供開始) Amazon CloudWatch Investigations が一般提供開始されました。AIエージェントが環境内の異常を探し、根本原因を特定し、修復ステップを提案することで、平均解決時間を短縮します。調査は80以上のAWSコンソールから開始でき、チームで協力して結果を追加・確認できます。関連するドキュメントや修正案も表示され、Slackなどのコミュニケーションツールとも統合できます。この機能は追加費用なしで、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (スペイン)、欧州 (ストックホルム) で利用できます。 Amazon Bedrock Guardrails にコンテンツフィルターと拒否トピックのための新しい機能 Tier を追加 Amazon Bedrock Guardrailsは、コンテンツフィルターと拒否トピックの新しい Tier を発表し、柔軟性と使いやすさが向上しました。新しい「スタンダード」Tier により、望ましくないコンテンツをより的確に検出・フィルタリングでき、最大60の言語がサポートされます。 Amazon Bedrock Flows で永続的な長時間実行とインラインコードサポートをプレビュー提供開始 Amazon Bedrock Flows に永続的な長時間実行機能とインラインコードサポートが追加されました(プレビュー)。これにより、ワークフローの実行時間が15分に延長され、カスタムモニタリングコードが不要になり、簡単なデータ処理のためのLambda関数設定のオーバーヘッドがなくなります。これらの機能強化で、ワークフロー開発と管理が合理化され、生成的AIアプリケーション構築に集中できるようになります。 Amazon SageMaker HyperPod で NVIDIA B200 GPU を搭載した P6 インスタンスが利用可能に Amazon SageMaker HyperPod で最新の NVIDIA B200 GPU を搭載した P6 インスタンスが利用可能になりました。P6-B200インスタンスは、8基のBlackwell GPUと1440 GBの高帯域幅GPUメモリを搭載し、従来のP5enインスタンスと比べて最大2倍のパフォーマンスを発揮します。これらのインスタンスは、米国西部(オレゴン)リージョンのSageMaker HyperPodフレキシブルトレーニングプランで利用可能です。 今週は以上でした。それでは、また来週お会いしましょう! 著者について 三厨 航(Wataru Mikuriya) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近読んだ本は「春にして君を離れ」です。