PART2：Oracle DatabaseからAmazon Auroraへの移行 -移行作業編- PART1 では、農林中央金庫がコスト削減の重要なポイントである Amazon Aurora の採用に至った経緯や、ベンダーの NTTデータとどのような点を評価していったかを解説しました。 PART2 では、Amazon Aurora の採用に至った後、移行フェーズにおいて実際に Oracle Database から Amazon Aurora へ移行する際にどのような非互換対応を実施したのか、性能試験時に考慮したポイントについて、お客様の声をご紹介させていただきます。 非互換対応について データベース選定時に実施した非互換調査では、いくつかの対応が必要な部分が存在することを認識していました。しかし、ロックの取得範囲の違いによる障害など、発生タイミングに依存して有無が変わる事象については、机上では影響範囲を網羅するのが難しい部分がありました。そのため、試験を通じて詳細な確認を行いました。非互換対応として実施したものの一部をご紹介します。 項番 概要 内容 1 暗黙の型変換 DB定義とSQLクエリでカラムのデータ型の不一致がある場合、Oracleは自動的にデータ型が変換され正常終了するが、PostgreSQLではエラーとなる 2 サブクエリやTBLの別名定義 OracleとPostgreSQLで、表の別名の使用ルールが異なる（OracleはFrom句のサブクエリに別名を使用しなくても良いが、PostgreSQLでは必須など） 3 集約関数のネスト 集約関数（avg、max、sumなど）をネストして使用する場合、Oracleは正常終了するがPostgreSQLではエラーとなる。 また、上記の他に対応に苦慮した非互換としては次のものがあり、それぞれ以下の表の通り対応を進めました。 項番 概要 内容 1 Database Link(異なるインスタンスを跨ぐ更新) 同一処理において複数のDBインスタンスに対して更新を行うような処理に対しては、Database Linkによる参照ではなく、「DB①に対する接続情報」、「DB②に対する接続情報」を定義し、これらを使い分けてDB更新するような対応が必要となり影響も大きかった。 2 PL/SQLのトランザクション制御（エラー制御の変更） 処理内のとあるSQLで一意制約が発生し、その後管理テーブルにSTSを書き込むといったような処理がある場合、トランザクションを分割させる必要がある。（同一トランザクションで処理しようとすると、後発のSQL（管理テーブルへの書き込み）が必ずエラーになる。） 3 空・Nullの扱いの差 PostgreSQLでは、NULLと空文字の違いが区別されるため、例えば「SELECT * FROM テーブル１ WHERE KEN_CD = ”」という構文においてOracleでは取得出来ていたレコードが取得できなくなってしまう。影響の大きかった非互換のひとつ。 これに対する対応として、移行時にDBデータを空文字⇒NULLに変換する対応と、AP（JAVA）-DB（SQL）間のオブジェクト変換時に空文字⇒NULLへのコンバータ処理を新たに作成して対応している。） 試験方法・方針について 本プロジェクトでは品質を最優先としており、本番データをマスク化した上で活用しながら、全機能の十分な試験を実施しました。本番データの活用によって、ほぼ全ての SQL について現行環境と新環境の比較を行うことができました。また、合わせて影響度合いに応じてチューニングを検討しました。さらにテスト効率の向上を目的として、テストデータの準備や現行・新環境の比較などの定型作業の自動化を図り、作業効率の向上に努めました。 試験時のポイント： 全ての SQL について空振りがない形で現行・新環境の比較を実施し、機能単体の正当性を確認 日々の全更新データを本番環境から流用し、データの網羅性を担保 想定されるピーク時のワークロードをツールで再現し、性能試験を実施 現行本番との比較確認やデータの準備を自動化・定型作業化することで効率化 また、試験においては製造・試験の生産性なども確認し、事前の想定から大きな乖離はありませんでした。さらに、NTT データに即時のチューニングが可能な体制を構築していただいたため、パフォーマンスが劣化する SQL があった場合も、業務要件上必須の性能が満たせるよう、迅速にチューニングを施すことで影響を最小限にしつつ対応する事ができました。 性能試験について 性能試験では、不適切な実行計画が選択されることによるパフォーマンス劣化が多くみられました。特に、数百万行以上の大規模テーブル同士の結合クエリでは、そうした傾向が顕著でした。そのため、ヒント句を活用して最適な実行計画を選択させる対応を行いました。また、アプリケーション側で大量の SQL を発行するような Loop 処理についても、1回あたりの通信時間の増加によって処理時間が伸びる傾向があったため、SQL 発行回数を減らすといった、アプリケーション側でのチューニングも実施する場面がありました。 Part 3 に続く。

PART1：Oracle DatabaseからAmazon Auroraへの移行 -検討編- 農林中央金庫は、農林水産業を支える全国金融機関として、金融業務をはじめとした経営健全性確保に向けた指導など、多岐に渡って日本の農林水産業の発展に貢献されています。また、JA・信農連(信用農業協同組合連合会)・農林中央金庫で構成されたJAバンクは、1 つの金融機関として機能するよう運営されており、貯金量 100 兆円超、店舗数 6,000 超、ATM 10,000 台超を誇る巨大金融グループです。 JAバンクの基幹システムである「JASTEM システム」は、2002 年に勘定系と情報系の 2 つで構成されて構築されました。情報系は、勘定系で処理した取引情報や顧客情報を蓄積し、JA 職員が渉外活動やデータ分析等で利用することがメインの役割です。 この度、経営環境の変化に伴うコスト削減要求の高まりや、ビジネスの加速に対応するため、2018 年から 2022 年にかけて、全国 6,493 店舗(2022 年 3 月時点)の JASTEM 情報系システムを Amazon Web Services(AWS)に移行する大規模プロジェクトを実施しました。データベースを Oracle Database から Amazon Aurora に更改したことによるライセンスコスト削減や、ハードウェア費用の削減により、13 年間で 100 億円以上の TCO 削減が見込まれています。 本ブログでは、コスト削減の大きなポイントである Amazon Aurora への移行について、移行検討から移行後の効果までをお客様の声とともにご紹介します。 AWSへの移行を決定した背景 当初はメインフレームの COBOL 環境で運用していた JASTEM 情報系システムは、2010 年のオープン化、2014 年の仮想化、2018 年の IA サーバーへの基盤更改といった形で、計画的にオープン系アーキテクチャへの移行を進めてきました。これにより、いわゆる「技術負債(レガシー技術)」の解消を図ってきました。 一方で、約 4 年ごとの周期で行う基盤更改に、検討から本番までに長い時間がかかっていた事が課題でした。そのため、基盤更改の効率化とコスト削減・合理化を図るべく、クラウド移行の検討を始めました。 この移行プロジェクトでは SI ベンダーの NTT データに支援を仰ぎながら、AWS を含む主要クラウドベンダーを複数の観点から比較しました(図 1 参照)。その結果、現行プログラムプロダクトとの親和性が高く、インフラ導入費用のみならず、長期的な運用コストを含めた TCO (トータルコスト)ベースでも高いコスト削減効果が期待できたことから、AWSの採用に至りました(図 2 参照)。 図1:評価・検証のポイント 図2:AWS移行によるコスト効果 Amazon Aurora PostgreSQLへの移行を決断した背景 JASTEM 情報系システムではこれまで、Oracle Database を利用していました。しかし、主に以下の 3 つの観点から Amazon Aurora の評価を行い、非機能要件(特に性能面)を落とさずにコスト削減が可能であると判断し、Amazon Aurora への移行を決断しました。 コスト競争力 Amazon Auroraはライセンス費用が不要な分、従来比で3割程度の削減が実現できると見込みました。アプリケーションの改修コストも相当程度発生するものの、全体としては安価になると分かりました。ただし、小規模システムではコスト効果が限定的になる可能性があるため、移行対象システムの規模感が重要であると認識しました。 可用性の高さ 3つのアベイラビリティーゾーン（AZ）に渡り、6つのデータコピーを保持するため、エンタープライズ利用に耐えうる可用性があることから、現行環境と同等の可用性の高さが実現可能と判断しました。 ベンダーロックインリスクの低減 Amazon Aurora は、OSS の PostgreSQL との互換性を持っているため、ベンダーロックインのリスクが低いことを評価しました。 一方で、アプリケーションの非互換改修や処理結果の確認といった開発リスクが伴う点は認識していました。 移行対象データベースの概要 DBエンジン：Oracle Database Enterprise Edition データ量：最も大きなクラスタで約3TB、全体で約25TB SQL数：約15,000本 プロシージャ数：351本(※非互換のみ) 可用性要件：99.99% Enterprise Editionオプション製品：Oracle Partitioning, Oracle Diagnostics Pack, Oracle Tuning Pack NTTデータの支援体制 本プロジェクトでは、NTT データが提供するプロフェッショナルサービス「あすぽす(※1)」を活用し、アセスメントから実装まで一気通貫で支援いただきました。 ＜※1 お客様のシステムに最適なデータベースの選定から、移行・導入までを一気通貫で行うプロフェッショナルサービス。PostgreSQLのコミッターも在籍しており、多くのマイグレーション実績を持つ。＞ ご参考：  あすぽす | デジタルテクノロジーディレクター® (ndigi.tech) データベースエンジンを選定する際に実施した内容 Oracle Database と PostgreSQL の非互換に関する情報を収集した上で、机上確認・実機検証を通して実現性を見極めました。具体的には、SQL*Loader やシノニムといった、Oracle Database 固有の機能に依存した設計となっているアプリケーションの有無を確認しました(※図 3 参照)。また、SQL の変換のみで対応可能な場合であっても、単純な置き換えレベルで対応可能か・作り替えが必要となるか、といった基準で「修正難易度」の精査(※図 4 参照)を行い、試験の検討・検証方法の策定を実施しました。 図3:機能面・非機能面での精査 図4:影響調査のアウトプットイメージ 更に NTT データの過去プロジェクト実績や、NTTグループの OSS ノウハウ、社外 PGECons 活動報告などを活用して、現行環境に対する非互換調査を協力しながら行いました。具体的には、Oracle 固有のヒント句の利用箇所やパーティション利用箇所の有無などを確認し、本プロジェクトの性能要件に対する影響度合いを踏まえて、十分対応可能と判断しました。 Part 2 に続く。

今日のグローバルサプライチェーンの複雑な状況において、正確な需要予測は極めて重要ですが、それだけでは十分ではありません。企業は予測精度を向上させ、最適な在庫を実現するために、高度な分析能力や機械学習（ML）の導入に投資を行ってきました。しかし、これらの広範な取り組みにもかかわらず、2021年以降、 在庫売上高比率 は上昇を続けており、需要と供給の変動に対応するために過剰在庫を抱えていることを示しています。この事実は、予測の改善と実際のビジネス価値の実現との間に、まだ重要な要素が欠けていることを示唆しています。 サプライチェーンの混乱が深刻な時期には、企業間の業務知識がより一層重要になります。効果的なステークホルダーとのコミュニケーションがなければ、どんなに高度な予測でも急速に陳腐化し、ビジネス価値が低下し、組織は急激な市場の変化に対して脆弱な状態に置かれてしまいます。 サプライチェーンの真の価値を引き出す鍵は、最先端の需要予測と効果的なステークホルダーの協働を組み合わせることにあります。この投稿では、 AWS Supply Chain の革新的なソリューションが、機械学習を活用した高品質な予測を実現するだけでなく、有意義な協働を促し、重要なビジネスインサイトを捉え、あらゆる市場環境で経済的価値を最大化する需要計画を作成する方法について探ります。 高付加価値な需要計画の構築 従来の需要計画は、過去のデータを元に可能な限り正確な予測を生成することのみに焦点を当てた単一ステップのプロセスです。今日のような非常に変化が激しい環境では、過去の出来事から同じ結果が生じない可能性があり、専門家からの追加的な意見も重要であるため、そのようなやり方では限定的な成功しか得られません。 AWS Supply Chain は、真に価値のある需要計画には 2 段階のアプローチが必要であることを認識しています。 Step 1: 機械学習を使用して強力なベースライン予測を構築する 最初のステップでは、需要プランナーは AWS Supply Chain の高度な分析・機械学習機能を活用して、ベースライン予測を生成します。次に予測モデルの分析機能が組織のデータセットで実行され、プランナーが最適な機械学習モデルを選択する際に支援を行い、外部要因と製品の切り替えを考慮に入れて初期精度を最大化します。例えば、DeepAR+ のようなアルゴリズムは、数百項目におよぶ時系列の特徴量データを含む大規模なデータセットで動作し、将来の関連する時系列のデータ項目とメタデータの項目を元に予測出力を生成します。 Step 2: ステークホルダーとの協働を推進し、合意に基づく需要計画を構築する 2 番目の重要なステップは、協調的な改善プロセスです。プランナーは AWS Supply Chain の直感的なユーザーエクスペリエンスを活用して、ベースラインとなる予測をステークホルダーと共有し、洞察を収集し、重要な業務上の前提条件を把握します。このプロセスにより、ベースラインに対する必要な上書きや調整が可能となり、最終的な計画が業務の全体感や整合性を保ったものになることが担保できるようになります。 従来、需要計画プロセスがビジネス価値を生み出しているかの評価は、平均絶対誤差率（MAPE）や加重平均絶対誤差率（WAPE）などの精度指標に頼ってきました。これらの指標は全体的なパフォーマンスを評価する上で依然として重要ですが、2 段階プロセスの各ステップで付加される価値を測定する上では不十分です。これらは実績値からの予測の乖離のみに注目するため、協業の過程で与えられる重要な情報や、行われ調整を見落としてしまいます。 ここで、 予測価値付加（FVA） の概念が重要となります。FVA は機械予測と人的介入の有効性を予測プロセスにおいて個別に測定し、組織がどの活動が本当に価値を生み出し、どの活動がノイズやバイアスを生む可能性があるかを特定するのに役立ちます。FVA を分析することで、企業は最も重要な部分に努力を集中させ、需要計画プロセスを最適化できます。例えば、 世界的な寝具メーカーのテンパー・シーリー・インターナショナルや RS コンポーネンツ は、FVA を成功裏に導入し、どの入力が本当に予測を改善し、どれがノイズを生んでいるかを理解することで恩恵を受けています。 AWS Supply Chain の統合ソリューションは、この 2 段階プロセスを促進し、実績値をナイーブ予測や合意予測と比較し、2 段階プロセスの各ステップでの価値付加を評価するための FVA を計算するためのレポーティングおよび分析ツールを提供します。これにより、組織は単なる精度指標を超えてビジネス価値を最大化する需要計画を作成することが可能になります。 ただ予測するのではなく、自分の未来を切り開け 需要計画は精度だけの問題ではありません。それは実際のビジネス価値を生み出すことです。AWS Supply Chain の 2 段階アプローチは、最先端の ML 予測と強力なコラボレーションツールを組み合わせることで、このプロセスを支援します。データに基づく分析と人間の専門知識の両方を活用することで、組織は未来を予測するだけでなく、それを形作る需要計画を作成できます。今日の変動の激しい市場では、これは単なる優位性ではなく、必要不可欠なものです。AWS Supply Chain で、需要計画をビジネスを前進させる戦略的優位性に変えましょう。以下のステップから始めてください： 現在のプロセスを評価する：予測精度と協調的なインプットのバランスを組織がどのように取っているか評価します。両者の価値を本当に最大限に活用できていますか？ AWS Supply Chain を検証する：アカウント管理者に デモをリクエスト し、統合された ML 予測とコラボレーションツールがどのように需要計画を変革できるかをご覧ください。 技術概要を把握する： AWS Workshop Studio で自己ペースの技術的なウォークスルーを体験してください。インスタンスの作成、データの取り込み、ユーザーインターフェースのナビゲート、インサイトの作成、需要計画の生成方法を学べます。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Amit Shah Amit Shah は、AWS Supply Chain のプリンシパル スペシャリスト ソリューション アーキテクトです。彼の役割は、サプライチェーンの幹部や技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するために顧客のサプライチェーンを変革することです。彼はリーン・シックス・シグマ ブラックベルト認定を受けており、メディカルテック製造、テクノロジー、E コマース、クラウドインフラストラクチャなど、フォーチュン 500 企業の幅広い業界で、ビジネスとプロセスの変革を推進する 18 年以上の業界経験を持っています。Amit は、サンフランシスコ湾岸地域を拠点としています。

サプライチェーン管理の領域では、経済の変動や多様化する顧客ニーズにより、常に変化にさらされています。このような環境下では、効率性と適応力が極めて重要です。多くの企業では、手作業のプロセスを削減し、効率性を高め、全体的なパフォーマンスを向上させるため、自動化ソリューションを求めています。 前回 お伝えした通り、AWS Supply Chain ソリューションは、可視性の向上とコスト最適化および俊敏性を促進する実用的な分析情報という利点を提供します。このソリューションは、需要計画、供給計画、インサイトなどの機能を提供し、中核的なサプライチェーン機能を効率化し、企業が市場環境に適応するのを支援します。新しいソリューションの採用にはそれに伴う課題があり、このブログではそれらを探ります。既存のワークフローとの統合から、業務を中断することなくニーズに対応することまで、組織はソリューションの可能性を十分に実現するために、これらの複雑さに自信を持って対処する必要があります。 導入における課題の軽減 新しいサプライチェーンソリューションの導入は重要な決定であり、多くの場合、実践的な考慮事項が伴います。例えば、そのソリューションが既存の組織プロセスにどの程度うまく統合されるか、特定の運用ニーズに対応できるか、また実装が現在のワークフローを妨げないかといった点です。実際に導入を決定する前の段階で、ソリューションの真価を見極めることは容易ではなく企業にとって、それが本当に自社の目標、リソース、プロセスに適合するかを評価することを難しくしています。 これらの一般的な導入課題に対応するため、AWS Supply Chain の新しいテストドライブ機能は、スピーディーで使いやすい実践的な試用環境を提供します。テストドライブにより、組織は AWS Supply Chain に素早く親しみ、様々な設定を試し、シナリオを実行し、ユーザーインターフェースを評価することができます。 この対話型エクスペリエンスにより、顧客はデータ取り込みから需要と供給の計画、そしてインサイトの生成まで、AWS Supply Chain の一連の機能を確認することができます。テストドライブは、企業がソリューションのメリットを実感することを可能にします： 簡素化されたセットアップ : 自動車、医療、小売、公共事業業界向けの事前に準備されたデータセットにより、組織はデータ収集、準備、ソリューション設定を必要とせず、すぐにソリューションのテストを開始できます。これにより、お客様は AWS Supply Chain の価値評価に直ちに集中することができます。 レスポンシブな体験 : AWS Supply Chain のテストドライブは、アクセスした日に応じて調整されるライブのような環境を提供します。つまり、予測日、在庫予測、補充スケジュールが自動的に更新され、実世界の計画タイムラインをシミュレートします。このレスポンシブな設定により、現実的なシナリオベースの洞察が生まれ、プランナーは実際の業務で行うような意思決定プロセスを、あたかも今日実施しているかのように体験できます。 没入型の検証 : テストドライブは、企業が AWS Supply Chain モジュールを直接体験できる、安全でインタラクティブな環境を提供します。ユーザーはインターフェースにアクセスし、設定をテストし、データ処理ワークフローを理解することで、AWS Supply Chain の機能について洞察を得ることができます。この実践的な経験により、ユーザー体験とソリューション設定にすでに慣れているため、本格的な実装へのスムーズな移行が可能となり、チームは自社の特定の業務に対するソリューションの適合性と価値に自信を持つことができます。 テスト実施ガイド この記事を進めるにあたり、以下の前提条件があります： AWS アカウントと AWS Supply Chain インスタンスがセットアップされていること ポリシーとアクセス許可を作成するための AWS Identity and Access Management (IAM) ロールを作成および変更する権限があること テストドライブ機能は、簡単な操作で開始できるよう設計されており、ワンクリックで利用を開始できます。 Step 1：テストドライブにアクセスします。 ログイン後、AWS Supply Chain のランディングページに移動し、 テストドライブ スイッチをクリックします。 Step 2: 業種を選択します。 自動車、医療、公共、小売などの事前に用意された業種データセットから選択してください。 Step 3: モジュールを確認します。 テストドライブは、企業が AWS Supply Chain モジュールを直接体験できる、安全でインタラクティブな環境を提供します。ユーザーはインターフェースにアクセスし、設定をテストし、データ処理ワークフローを理解することで、AWS Supply Chain の機能について洞察を得ることができます。この実践的な経験により、ユーザー体験とソリューション設定にすでに慣れているため、本格的な実装へのスムーズな移行が可能となり、チームは自社の特定の業務に対するソリューションの適合性と価値に自信を持つことができます。 需要計画 : &nbsp; シミュレーションされた業界の需要パターンに基づいて予測を生成し、予測を調整をしてみることで、AWS Supply Chain がお客様固有の需要計画ニーズをどのようにサポートできるかを確認できます。 供給計画 : 原材料と完成品の購買計画、および補充推奨事項を確認するために、補充タイムラインを生成し、供給ルールをカスタマイズします。AWS Supply Chain がお客様のビジネスニーズに合わせてどのように在庫を管理するかを評価します。 在庫分析 : 業界シナリオに基づいた在庫予測、ネットワークの可視化、リードタイムの変動、およびリスク評価にアクセスし、詳しく調べることができます。これらのインサイトが業務ニーズにどのように適合するかを評価し、AWS Supply Chain があなたのビジネスに適しているかを判断できます。 これらの簡単な操作手順と実践的なシナリオテスト機能により、テストドライブを通じて AWS Supply Chain の機能を実際に体験し、自社のビジネスでの活用方法を具体的にイメージすることができます。 まとめ AWS Supply Chain は、たとえば小売業の需要予測から医薬品の在庫計画、自動車業界のサプライチェーンリスク評価、公益事業のサプライヤー管理まで、幅広い業界とサプライチェーン機能に対応しています。ワンクリックのオファリングとして、AWS Supply Chain のテストドライブ機能は、サプライチェーン業務を近代化したい組織にとって簡単な出発点を提供します。テストドライブ機能は、企業が AWS Supply Chain の潜在的な導入を迅速かつ容易に探索することを支援します。事前設定されたデータセットと業界固有のモジュールを備えた柔軟な環境を提供することで、テストドライブは顧客が最小限の準備と既存の業務と並行して、サービスの可能性を体験できるようにします。テストドライブは完全な導入の代替とはなりませんが、評価段階を簡素化し、企業が AWS Supply Chain がニーズに合うソリューションかどうか を判断するのに役立ちます。 AWS Supply Chain は、前払いのライセンス料や長期契約なしで利用できます。テストドライブ機能は、既存の AWS Supply Chain の顧客と初めて AWS Supply Chain を検証する組織の両方に、ハンズオンの試用環境を提供することで、この柔軟性を拡張します。詳細情報の入手と開始、およびセルフペースの技術的ウォークスルーについては、 AWS Supply Chain ウェブサイトと&nbsp; ワークショップ をご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Jyothi Bodas Jyothi Bodas は、AWS Supply Chain でベテランのソフトウェア開発マネージャーであり、戦略的な見識と技術的な専門知識を通じて、会社の成功に大きく貢献しています。AWS Supply Chain のデータオンボーディングシステムの創設メンバーの1人として、重要なアプリケーションの戦略、アーキテクチャ、ソリューションの開発に重要な役割を果たしています。UPS とAmazon Web Services（AWS）での15年以上にわたるエンジニアリングとリーダーシップの役割を通じて、Jyothi は豊富な知識と専門性をもたらしています。顧客のニーズの変化に合わせて調整された革新的で信頼性の高いソリューションを提供する情熱に、卓越性と顧客満足への彼女のコミットメントが表れています。インドのオスマニア大学でコンピュータサイエンスとエンジニアリングを専攻して卒業しました。専門的な取り組みの外では、Jyothi はサプライチェーンマネジメントや AI、ML などの新興技術に関する継続的な学習に時間を捧げ、ハイキングやその他のフィットネス活動を通じて活動的な生活を送っています。 <!-- '"` -->

はじめに 2024 年 12 月、リテールメディアにおけるデータコラボレーションワークショップを開催しました。本記事では、本ワークショップの開催背景と当日の内容をご紹介いたします。 Retail Media は「第3の広告」として注目され、2019年頃からアメリカを中心に市場を牽引しています。しかし、日本ではまだまだこの市場はアーリーステージにあります。本領域が加速しない原因の一端として、異業種間のデータコラボレーションによるCustomer360 の実現というデジタルマーケティングのノウハウにとどまらず、実店舗の購買体験向上に向けたオフライン施策にまで踏み込む難しさが存在します。この市場を加速させるため、AWSはCyberAgent Inc.（以下CA 社）と共同でワークショップを開催しました。Retail Media に高い興味を持つ日本を代表する企業にお集まりいただき、AWS Clean Rooms を活用したデータコラボレーションのユースケースの議論を実施しました。加えてCA 社のSolution を組み合わせることで、実店舗でも十分活用可能な協業に踏み込んだアクションプランを策定できる場を提供することを目指しました。 開催概要 参加者 5 社 / 36名 参加企業様 イオン様 アダストリア様 SIROK 様 オンデーズ様 ヴィンクス様 アジェンダ 開会のご挨拶 / 参加企業ご紹介 CA のRetail Media サービスの紹介 AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション Next Step のご案内 / 閉会のご挨拶 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、各企業ごとにデータコラボレーションする際の協業内容について議論を行いました。 データコラボレーションの基本 データコラボレーションとは 本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。まず、データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、個人情報を含むデータの保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。実際、多くのグローバル企業がデータコラボレーション強化を推進しており、日本においても今後のビジネス戦略において重要な役割を果たすことが予想されます。 各セッションのハイライト CAのRetail Mediaサービスの紹介 CyberAgent, Inc. AI 事業本部 AI POS カンパニー プロダクト責任者 早川 裕太氏 CA 社早川氏より、Retail Media を取り巻くマーケットの状況とCA社の取り組みをご紹介いただきました。CA 社は創業期よりインターネット広告事業を展開してきました。近年では、広告効果最大化を実現する中で培ったノウハウや、約100名規模のAI研究者の技術力などを活かすことで、協業によるパートナー企業のDX推進および広告事業の創出等を行っております。Retail Media においては、消費者、小売、広告主の三方良しを目指した技術の価値転換を図っており、デジタルサイネージ（ミライネージ）をはじめとしたいくつかのサービスをすでに展開しています。お客様の購買体験向上に向けて、コンサルテーションからソリューション提供まで一気通貫して協業が可能な旨を語られました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 黒澤 蓮 アマゾン ウェブ サービス ジャパン 黒澤より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。まずはデータコラボレーションを支える AWS Clean Rooms というマネージドサービスについてご紹介しました。主な特徴として、暗号化技術によるセキュアなデータ共有、SQL を用いた柔軟な分析環境、実行する SQL の制御機能、緻密なアクセス制御、大規模データセットに対するスケーラビリティがあります。このサービスにより、企業は自社データを保護しつつ、連携先企業とのデータコラボレーションを実現し、新たなビジネス機会を創出できます。これに加えて新機能で企業間で類似セグメントの作成を支援する AWS Clean Rooms ML、名寄せのサービスである AWS Entity Resolution のご説明をいたしました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。参加企業の皆様には事前に各社のデータ資産や活用課題を伺った上で、実践的なユースケースを準備したことで、より深い議論が可能となりました。イオン様、アダストリア様のテーブルでは、グループデータ戦略としてどのようにデータを活用するかの話と、それが実現した上でのポイント戦略や広告効果の測定など幅広いテーマについて、個別課題の解決に向けた議論を実施しました。オンデーズ様、SIROK 様は新規ユーザーをどのように増やしていくかの課題感に対して、Retail Media を通じた顧客開拓の戦略を議論されました。最後にヴィンクス様は、CA 社と両社の強みを活かし、リテールのお客様のビジネス成長に寄与するためのデータ活用における協業の新たな可能性を見つけることができました。 お客様の声 本ワークショップは、Retail Media におけるデータコラボレーションの可能性を探る貴重な機会となりました。参加企業の皆様からは、「事業領域の異なる企業間でのディスカッションが想像以上に有意義な時間でした」「自分たちだけでは想像もできないアイディアがたくさん出てきた」といった前向きな声を多数いただきました。ワークショップ後のアンケートでは、参加者のCSAT が4.8/5.0 と本ワークショップに対してポジティブなフィードバックを頂き、データコラボレーションに対する高い期待が伺えます。 おわりに 本ワークショップを通じて、Retail Media 実現に向けた大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業の皆様、そして共催であるCyberAgent 社の皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、Customer Solutions Managerの池田 飛鳥が担当しました。

この記事は Raja GT, Shing Poon, Vedanth Srinivasan により作成された「 Building a Manufacturing Digital Thread using Graph and Generative AI on AWS 」を翻訳した内容です。 製造業の大多数の組織がデジタルトランスフォーメーションの取り組みを受け入れる中、戦略的資産としてのデータの役割がますます重要になってきています。製品ライフサイクル全体を通じてデータを効果的に活用することで、製造業は全体的なコスト削減、製品品質の向上、サプライチェーンの合理化、そして顧客への差別化されたソリューションの提供につながる重要な洞察を引き出すことができます。しかし、データ駆動型の変革を実践に移すことは容易ではありません。 アクセンチュアの調査 によると、経営幹部の 73% が、レガシーデータ、資産、および業務からデータに基づく洞察を得ることができないと報告しています。 ほとんどの製造業組織において、製品ライフサイクルデータは通常、製品ライフサイクル管理 (PLM) 、企業資源計画 (ERP) 、製造実行システム (MES) 、顧客関係管理 (CRM) 、およびその他の企業アプリケーションといった企業システムに保存されています。企業インフラが分断されていることにより、生成されたデータは多くの場合断片化し、使用されないままとなっています。 Seagate の委託 を受け、IDC が実施した調査によると、企業が生成するデータの 68% が活用されていないことが明らかになりました。また、この報告書はデータの提供者と利用者の間のデータがつながっていないことを指摘しています。 製品ライフサイクルの様々な段階にわたるデータを活用し、製造業の関係者がより良い意思決定を行うことができるよう支援することが、ビジネス変革の必須事項となっています。しかし、製品ライフサイクル全体でのデータ管理とコンテキスト化は、データの表現方法や使用パターンが、それを扱う特定の担当者のペルソナに応じて変化するため、困難が伴います。製造業の企業がデータを統合しコンテキスト化するために用いる一つのアプローチが、 デジタルスレッド (Digital Thread) の構築です。これにより、製品のライフサイクル全体を通じて生成される信頼できるデータ (要件、製品情報、製品コスト、文書、サプライチェーン、品質、欠陥、保守など) のシームレスで相互接続された流れを確立します。製品が構想から設計、製造、現場運用に至る複数のライフサイクル段階を経る中で、デジタルスレッドは多様なデータソースを接続し、ある時点での製品性能を分析し、データ駆動型のビジネス成果を推進する筋道を確立します。 デジタルスレッドのためのナレッジグラフと生成 AI 異種の企業システム間の統合を確立するには、データソース間のポイントツーポイント統合など、いくつかのアプローチがありますが、デジタルスレッドを確立するための実用的な方法の一つは、ナレッジグラフ (知識グラフ) を使用して製造データとその関係性を表現することです。 ナレッジグラフを用いることで、様々なデータソースからの接続されたデータの繋がりを作成し、オブジェクト間の非常に複雑な関係性を表現することができます。ナレッジグラフは、複雑な関係性を効率的に保存、検索、可視化することでデータを整理できるように設計されています。さらに、データを関係者にとって利用しやすくし、より良い意思決定を行うための知識獲得を支援します。 製品の企画から廃棄までのライフサイクル全体にわたってデータを接続するデジタルスレッドは、依存関係を追跡し、エンドツーエンドの追跡可能性を確保する能力を必要とします。ナレッジグラフは、分散したデータを接続することでこれらのセマンティックレイヤーを実現し、企業全体でシームレスなデータ接続性を可能にします。 図 1: 製造デジタルスレッド – ナレッジグラフ 図 1 に示すグラフでは、企画、製品データ、生産指示書などのエンティティがノード (頂点) として表現され、それらの間のセマンティックな接続がエッジ (辺) として表現されています。このデジタルスレッドグラフにより、相互に接続された製造企業のデータをシームレスにナビゲートすることができ、複雑な関係性を容易に理解することができます。例えば、部門横断チームや意思決定者が部品と関連する欠陥や要件との関係を理解するのに役立ち、品質の向上や設計プロセスの改善につながります。ナレッジグラフのクエリは、企業内の様々な関係者の意思決定プロセスに不可欠な、コンテキスト固有の視点や関連情報の抽出を容易にします。 ナレッジグラフはデジタルスレッドの開発に理想的ですが、グラフクエリの自動化や自然言語テキストの生成には課題が生じる可能性があります。ユーザー体験を向上させるために、大規模言語モデル (LLM) を活用して複雑なグラフデータを解釈し、関係性を分析してクエリを生成し、デジタルスレッドグラフに基づいて自然言語で結果を提供することができます。 このブログでは、 Amazon Neptune と Amazon Bedrock の機能を組み合わせて、製造業のデジタルスレッドアプリケーションを作成する方法について説明します。グラフと生成 AI テクノロジーを組み合わせることで、ビジネス関係者が会話形式で素早く洞察を得ることができるようになります。 デジタルスレッドソリューションフレームワーク 様々な製品ライフサイクルプロセス (Design, Manufacture, Operation) から得られるデータが、このデジタルスレッドソリューションフレームワークの基盤を形成しています。次の層は、PLM、ERP、MES などの中核的な企業システムを包含しており、これらは企業内の人、プロセス、エンジニアリング、製造データなどの特定の側面を管理します。その次の層はナレッジグラフで構成されます。ナレッジグラフがこれらのシステムからのデータを接続して関係性を確立し、洞察を導き出し、相互に接続された製造企業データの包括的な理解を促進します。最後に、大規模言語モデルがナレッジグラフと統合され、高度なグラフクエリの作成と自然言語機能を可能にします。 図 2: 製造デジタルスレッドソリューションフレームワーク 図 2 に示すように、このソリューションは、様々なシステムからのデータをシームレスに接続し、製造業のデジタルスレッドフレームワークを通じて洞察を得られるようにすることで、イノベーションを加速することを目指しています。このフレームワークは、データが相互に接続されたインテリジェントな構造を確立し、製造業の関係者の意思決定プロセスを強化します。 ソリューションアーキテクチャ 製造業のデジタルスレッドソリューションアーキテクチャは、フルマネージド型のグラフデータベースサービスである Amazon Neptune と、フルマネージド型の生成 AI サービスである Amazon Bedrock を必須要素として統合することで実装されています。さらに、これらのコンポーネントは様々な AWS サービスによって強化され、デジタルスレッドのための包括的なソリューションを構築しています。 図 3: 製造デジタルスレッドソリューションアーキテクチャ 図 3 に示すように、このソリューションは 15 を超える AWS サービスを活用し、デジタルスレッド機能の開発をサポートするための 10 の重要な機能を提供します。 1. 製造組織における主要な関係者を特定する デジタルスレッドの取り組みを開始するには、製造組織内の主要な関係者を特定することが不可欠です。例えば、システムエンジニアリング、設計エンジニアリング、製造エンジニアリング、サプライチェーン、運用、品質チームが含まれます。彼らの固有のビジネス上の関心事やユースケースを理解することにより、デジタルスレッドの基盤の構築が可能となります。 2. デジタルスレッドを構築するためのデータソースを特定する 包括的なデジタルスレッドを構築するために必要なデータソースを特定します。これらには、PLM、ERP、CRM、MES/MOM、およびその他の社内企業アプリケーションが含まれる場合があります。主要なビジネス上の課題、提供元システム、およびデータを特定することで、企業は業務の全体的な視点を得るために不可欠なデータを確実に取り込むことができます。 3. データ統合 特定されたデータソースを AWS Data Migration Service (DMS) や、大規模なデータセットの移動には AWS DataSync を使用して AWS クラウドに取り込みます。 4. S3 にデータをアップロード データの取り込みが成功したら、そのデータを Amazon Simple Storage Service (Amazon S3) にロードします。 5. バルクローダーを使用して Amazon Neptune グラフデータベースにデータをロード Amazon Neptune のバルクローダー機能を活用して、Amazon S3 に保存されたデータを Amazon Neptune に取り込みます。Amazon Neptune で作成されたグラフのエッジとノードが、グラフベースのクエリの基礎となります。 6. 生成 AI モデルを使用 Amazon Bedrock から基盤モデルを選択します。Amazon Bedrock は、単一の API を通じて主要 AI 企業と Amazon の高性能な基盤モデルの選択肢を提供する、フルマネージド型サービスです。また、生成 AI アプリケーションを構築するための幅広い機能セットも備えています。 7. ナレッジグラフと LLM の接続を確立し、LangChain を使用して統合 Amazon Bedrock (Claude 3.5 Sonnet) と Amazon Neptune の間のリンクを確立し、LangChain を使用してそれらをシームレスに統合します。これにより、基盤モデルからクエリを生成し、ナレッジグラフに対してクエリを実行し、結果を自然言語でユーザーに返すプロセスを調整します。 8. アプリケーションレイヤーの作成 以下の要素を組み合わせてアプリケーション層を作成します: Streamlit アプリケーション コンテナ化されたアプリケーションの実行のための AWS Fargate コンテナイメージ管理のための Amazon Elastic Container Registry トラフィック分散のための Elastic Load Balancing (ELB) 安全なユーザー認証のための Amazon Cognito AWS Copilot CLI を通じてデプロイされるこのセットアップは、デジタルスレッドデータとの関係者のシームレスな対話のための、スケーラブルで安全なユーザーインターフェースを確保します。 9. セキュリティ Amazon VPC を活用して、デジタルスレッドアプリケーションを安全かつ隔離されたネットワークで運用します。 AWS Identity and Access Management (IAM) によってアクセス制御を強化し、 AWS Certificate Manager (ACM) で証明書を管理し、 AWS WAF で Web アプリケーションのセキュリティを確保します。 10. 管理とガバナンス AWS CloudTrail を活用してアクティビティを追跡し透明性を高め、 Amazon CloudWatch でリソースを監視し、 AWS CloudFormation でデジタルスレッドアプリケーションのリソースデプロイメントを自動化します。 詳細については、 GitHub リポジトリで提供されている ガイダンス 、 ワークショップ 、サンプルコードを参照してください。 図 4: 製造デジタルスレッドアドバイザー 図 4 は、PLM、MES、ERP、CRM システムからの企業データを組み合わせ、自然言語による問い合わせを通じてインテリジェントな洞察を提供する、対話型デジタルスレッドアドバイザーを示しています。 デジタルスレッドのユースケース ナレッジグラフと生成 AI に基づく製造業のデジタルスレッドを使用することで、組織はシームレスなデータ統合を通じて効率性とイノベーションを引き出すことができます。主要なユースケースには以下が含まれます: 要件から品質へのトレーサビリティ: 製品要件と品質の間のトレーサビリティの維持が難しい課題となる場合があります。製造業のデジタルスレッドを活用することで、組織は初期要件が最終製品の品質にどのように影響するかについてはっきりと見ることができます。このアプローチにより、関係者は重大な問題を引き起こす前に、積極的に課題を特定し、対策を提案することが可能になります。 製品開発におけるサプライヤーコラボレーションの効率化: 複数のサプライヤーとの協力や設計仕様の管理は、製品開発プロセスを複雑にする可能性があります。ナレッジグラフと生成 AI を活用することで、組織は製品とサプライヤーの情報をシームレスに接続できます。この統合により、サプライヤーの選択が最終製品にどのように影響するかについてリアルタイムの洞察が得られ、より多くの情報を基に意思決定が可能になり、開発プロセス全体が効率化されます。 サステナビリティのためのサプライチェーンの最適化: サプライチェーンにおけるサステナビリティの実現は、現代の製造業にとって重要な目標です。デジタルスレッドを活用することで、組織は製品、サプライヤーから物流に至るまで、サプライチェーンのあらゆる観点を接続することができます。総合的な視点を持つことで、カーボンフットプリントやその他のサステナビリティ指標に関する洞察が得られ、組織は炭素排出量を削減するための戦略を策定することが可能になります。 文脈を踏まえた洞察による顧客サポートの強化: 効果的な顧客サポートを提供するには、製品の全体的なジャーニーを深く理解する必要があります。設計、製造、顧客フィードバックを含む接続されたデジタルスレッドを活用することで、サポートチームは大局的な視点から洞察を得ることができるようになります。これにより、問題をより迅速かつ正確に解決することが可能となり、最終的に顧客満足度とロイヤルティの向上につながります。 さらに、グラフと生成 AI を使用した製造業のデジタルスレッド機能は、上記で言及したユースケースを超えて、製品ライフサイクル全体および産業全体にわたって業務を変革する機会を提供します。 まとめ この投稿では、AWS でナレッジグラフと生成 AI を使用してデジタルスレッドを構築する方法について検討しました。ナレッジグラフと LLM は、接続された製造業のデジタルスレッドを作成する上で不可欠です。グラフは複雑な製造プロセスをナビゲートするために必要なデータの接続性と追跡可能性を提供し、一方で LLM はグラフから価値ある洞察を抽出し、それらを自然言語で提示します。ナレッジグラフと生成 AI の力を活用することで、製造業の組織はデータのアクセシビリティや、コラボレーション、追跡可能性、効率性を向上させ、より迅速なデータ駆動型の意思決定プロセスを実現します。 この記事はソリューションアーキテクトの村松 謙が翻訳しました。原文は こちら 。 Raja GT Raja GT は、アマゾンウェブサービスのワールドワイドシニアパートナーソリューションアーキテクトです。製造パートナーと緊密に連携して、技術戦略を策定し、戦略的パートナーが AWS で業界ソリューションを構築して拡大できるよう支援しています。航空宇宙、自動車、ヘルスケア、エネルギー業界で 20 年以上の経験を持ち、製品ライフサイクル管理、サプライチェーン、スマートマニュファクチャリング、革新的なクラウドソリューションの構築を専門としています。 Shing Poon Sing Poonは、メルボルンのアマゾンウェブサービスのシニアテクニカルアカウントマネージャーで、小売およびサプライチェーン業界を専門としています。2022 年にソリューションアーキテクトとして AWS に入社して以来、データと AI に関する専門知識を活かして、顧客との複雑なビジネス課題を解決してきました。Shingは、公益事業、グローバルサプライチェーン、製造部門にわたる豊富な経験を持ち、安全で信頼性が高くスケーラブルなソリューションを通じてデジタル変革を推進しています。テクノロジー以外にも、彼は熱心なコーヒー醸造家であり、2人の息子のために専任のTAMを務めています。 Vedanth Srinivasan Vedanth Srinivasan は、アマゾンウェブサービスのエンジニアリング&amp;デザインおよび市場開拓 (GTM) 向けソリューションの責任者です。業界横断型ソリューションに重点を置いているのは、ハイパフォーマンスコンピューティング (HPC) や製品ライフサイクル管理 (PLM) などのコンピュータ支援エンジニアリング (CAE)、製品ライフサイクル管理 (PLM) のほか、モデルベースシステムエンジニアリング (MBSE)、デジタルスレッド、デジタルツインソリューションなどの高次ワークロードです。自動車、航空宇宙、防衛、石油・ガス、ヘルスケア業界にわたる高度なエンジニアリング・ワークフローの開発と展開において 20 年以上の経験があります。

本記事は、2025 年 1 月 29 日に公開された Generative AI operating models in enterprise organizations with Amazon Bedrock を翻訳したものです。 生成 AI は、お客様や従業員のエクスペリエンスを向上させる革新的なアプリケーションの創出を可能にし、革命をもたらします。 インテリジェントなドキュメントの処理 、翻訳や要約、カスタマーサポートのエージェントを支援する柔軟で洞察に富んだ応答、パーソナライズされたマーケティングコンテンツ、画像やコードの生成などは、生成 AI を使用したユースケースの一例であり、実運用されているものです。 大規模な組織では、複数の事業部門 (LOB) が存在し、中央で管理する組織が存在することが多く、 Amazon Web Services (AWS) のマルチアカウント戦略と共に AWS Organizations を適用するのが一般的です。 ランディングゾーン を導入して、セキュアなアカウント作成を自動化し、ログ、監視、監査など、アカウント全体にわたる管理を合理化します。 LOB は独自のアカウントやワークロードを運用しますが、 Cloud Center of Excellence (CCoE) などの統括チームが、アイデンティティ、ガードレール、アクセスポリシーを管理しています。 生成 AI の導入が進むにつれ、企業は生成 AI のオペレーティングモデルを確立していく必要が生じてきます。オペレーティングモデルは、事業運営を駆動する組織設計、コアプロセス、テクノロジー、役割や責任、ガバナンス体制、そして財務モデルを確立するものです。 本記事では、適用可能な生成 AI のオペレーティングモデルを考察します。 オペレーティングモデルのパターン 俊敏性、ガバナンス、統制などの優先事項に応じて異なる生成 AI のオペレーティングモデルを採用することができます。生成 AI のガバナンスとは、この技術の責任ある開発、導入、利用を促進するフレームワーク、ポリシー、プロセスを意味します。 リスクを軽減し、説明責任を果たし、生成 AI システムと倫理原則や組織目標との整合性を図るためのさまざまな方策を包含するものです。次の図に示すように、3 つの代表的なオペレーティングモデルのパターンは、分散型 (Decentralized) 、中央集権型 (Centralized) 、そして連携型 (Federated) です。 分散型モデル 分散型では、生成 AI の開発や導入は、各 LOB が独自に主導し管理します。LOB は、それぞれの AWS アカウントの AI のワークフロー、モデル、そしてデータを独自に管理します。 これにより、各 LOB はニーズに応じた生成 AI のソリューションを迅速に試行し導入することができるため、市場投入までの時間が短縮され、俊敏性を高めることができます。しかし分散型であっても多くの場合は、LOB は全社的なガバナンス管理と整合性を図り、本番環境への導入にあたっては CCoE チームの承認を得る必要があります。アクセスポリシー、モデルのリスク管理、データプライバシー、コンプライアンス体制などについて、グローバルなエンタープライズの基準に則る必要があるため、ガバナンスが複雑になりえます。 中央集権型モデル 中央集権型では、生成 AI に関連する取り組みは生成 AI/ML を統括するチームが行い、全社にわたる AI のワークフロー、モデル、そしてデータをエンドツーエンドで導入から管理まで行います。 LOB は、AI に関するニーズを統括するチームに伝え、迅速性や市場投入までの時間はトレードオフとなりますが、より強力なトップダウン型のガバナンスを実現します。中央集権型では、市場投入までの時間がボトルネックとなる可能性があるため、LOBからのニーズに効率的に対応できるよう、チームに十分な人員や自動されたプロセスを適切に導入する必要があります。チームの規模を拡大できない場合、中央集権型のアプローチのメリットはガバナンスですが、デメリットの方が大きくなる可能性があります。 連携型モデル 連携型は、生成 AI のプロセスのうち主要なアクティビティを中央の生成 AI/ML プラットフォームチームが管理することで、バランスを取るものです。 LOB が AI のユースケースを開発する一方で、中央のチームがガードレール、モデルのリスク管理、データプライバシー、そしてコンプライアンス体制を整備します。これにより、LOB の迅速なイノベーションを実現しながら、中央がガバナンス領域を監視することができます。 生成 AI のアーキテクチャのコンポーネント オペレーティングモデルのパターンについて説明する前に、このセクションでは、アーキテクチャで使用されるコンポーネントと AWS のサービスの概要について簡単に説明します。 大規模言語モデル (LLM) 大規模言語モデル (LLM) は、数十億のパラメータを含み、膨大なデータで事前学習された大規模な ML モデルです。LLM は、ハルシネーション、つまり LLM が確信を持って回答しているものの、実際には不正確な回答を提供するということが起こる可能性があります。さらに、LLM の学習に使用したデータが古くなっている可能性もあり、不正確な回答につながることがあります。LLM が不正確な情報を提供する可能性を軽減する 1 つの方法は、 Retrieval Augmented Generation (RAG) と呼ばれる技術を使用することです。RAG は、ナレッジの検索とテキスト生成モデルを組み合わせた高度な自然言語処理技術です。RAG は、事前学習済みの言語モデルと検索ベースのアプローチを組み合わせ、より情報量が多く正確な応答を生成します。RAG を設定するには、関連するソースドキュメントをモデルに提供するベクトルデータベースが必要です。RAG を使用すると、関連するドキュメントのセグメントやその他のテキストが検索され、LLM に共有され、コンテンツの品質と関連性を高めた的確な応答が生成されます。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった AI 業界をリードする企業が提供する高性能な 基盤モデル (FM) を、単一の API を使用して選択できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任あるAIを備えた生成 AI アプリケーションを構築するために必要な機能も幅広く備えています。 Amazon SageMaker JumpStart では、AI21 Labs、Cohere、LightOn などのサードパーティプロバイダーの独自 FM へのアクセスを提供します。さらにAmazon SageMaker JumpStart は、Hugging Face などのサードパーティソースからのオープンソース FM の導入や管理も行えます。 データソース、埋め込み、ベクトルストア コンテキストや関連情報を提供する組織固有のデータは、通常、内部データベース、データレイク、非構造化データリポジトリ、またはドキュメントストアに存在し、これらを総称して組織データソースまたは独自データストアと呼ばれます。 ベクトルストアは、効率的な最近傍探索アルゴリズムと適切なインデックスにより、大量のベクトルを保存し、検索するためのシステムです。 組織のデータの埋め込み（ベクトル形式でのデータの数学的表現）だけでなく、データの生のテキストもチャンク単位で含まれます。これらのベクトルは、専用の埋め込み生成 LLM によって生成され、組織のテキストチャンクを処理して数値表現（ベクトル）を作成し、ベクトルストアにテキストチャンクと共に保存されます。ベクトルストアや埋め込みについて詳しく知りたい場合は、「 生成 AI アプリケーションでベクトルデータベースが果たす役割 」を参照ください。 Amazon Bedrock Knowledge Bases を使用すると、Amazon Bedrock の FM を企業のデータに安全に接続して RAG を実現できます。Amazon Bedrock Knowledge Bases は、さまざまなサポート対象のデータソースからのデータ取り込みを容易にし、データのチャンク処理、パース処理、埋め込みを管理し、ベクトルストアに追加します。これらの機能が提供されるため、Amazon Bedrock Knowledge Bases は、RAG を使用して強力な会話型 AI システムを構築するための、フルマネージド型のサーバーレスの選択肢として考えることができます。 ガードレール コンテンツフィルタリングのメカニズムは、望ましくない有害なコンテンツを最小限に抑えることで、アプリケーションの要件や責任ある AI のポリシーに準拠し、ユーザーと AI のやり取りを制御するためのセーフガードとして実装されています。ガードレールは、ユーザーからの入力と FM からの出力を確認し、安全性が確保されていないトピックをフィルタリングもしくは拒否したり、個人を特定できる情報 (PII) を削除したりすることで、生成 AI のアプリケーションにおけるコンテンツの安全性とプライバシーを強化することができます。 Amazon Bedrock Guardrails は、Amazon Bedrock の機能であり、セーフガードを講じるために使用できます。貴社のポリシーに基づいて、何を条件とするかを決定します。これらのセーフガードは、フレームワークに依存しません。特定のユースケースに合わせて構成を変更した複数のガードレールを作成できます。Amazon Bedrock Guardrails の詳細については、「 Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます 」、「 新しい安全フィルターとプライバシーコントロールを備えた Amazon Bedrock のガードレールが利用可能になりました 」を参照してください。 オペレーティングモデルのアーキテクチャ このセクションでは、3 種類のオペレーティングモデルについて概要を説明します。 分散型モデル 分散型モデルでは、LOB が AWS アカウントを所有し管理します。各 LOB はそれぞれの AWS アカウントで生成 AI のコンポーネント、共通機能、アプリケーション、Amazon Bedrock の構成を設定し管理します。このモデルでは LOB が Amazon Bedrock の機能を活用しながら独自の要件に応じて生成 AI のソリューションをカスタマイズすることができます。 このモデルでは、LOB は LLM やガードレールなどのコアコンポーネントを設定し、Amazon Bedrock のサービスアカウント (図中の “Amazon Bedrock Service Account”)&nbsp; でホスティング、処理、そしてインターフェイスのエンドポイントのプロビジョニングといったことを管理します。そのエンドポイントを通じて、LOB は Amazon Bedrock のサービスにアクセスし、やりとりできます。 LOB は、 Amazon CloudWatch Logs および AWS CloudTrail を使用してニーズに合わせてログの取得、分析、監査を行い、アカウントで構成した Amazon Bedrock のサービスの監視や監査を行います。Amazon Bedrock のコストや利用状況は、LOB の AWS アカウントに記録されます。分散型モデルを採用することで、LOB は生成 AI のソリューションを分散型の構成で管理しながら、Amazon Bedrock のスケーラビリティ、信頼性、セキュリティのメリットを享受できます。 次の図は、分散型モデルのアーキテクチャを示しています。 中央集権型モデル 中央の AWS アカウントが、再利用可能なエージェント、プロンプトフロー、共有ライブラリといった生成 AI のコア機能の構成や管理を行う中心的なハブとして機能します。 LOB チームは中央のチームに事業固有の要件やユースケースを提供し、中央のアカウントで要件に沿うように生成 AI のコンポーネントを統合しオーケストレーションします。 生成 AI のソリューションの設定やオーケストレーションは、中央のアカウントで保持されます。しかし一般的には、LOB 固有のリソースやサービスとの連携が必要になり、それを容易にするために、中央のアカウントは LOB の AWS アカウントの API ゲートウェイやその他の連携ポイントを利用します。連携ポイントを通じて、中央の生成 AI のオーケストレーションと、 LOB の業務に特化したアプリケーション、データソース、サービスとの間で、安全で統制されたやりとりが可能になります。この中央集権型のオペレーションモデルは、組織全体における生成 AI のソリューションの共通化、ガバナンス、スケーラビリティを促進します。 中央のチームは、共通の標準、ベストプラクティス、組織のポリシーを順守しながら、生成 AI のコンポーネントの効率的な共有や再利用を可能にします。さらに、LLM やガードレールといった Amazon Bedrock のコアコンポーネントについては、Amazon Bedrock のサービスアカウントで AWS がホストや処理を担い、安全でスケーラブルでハイパフォーマンスな実行環境を確保します。この中央集権型モデルでは、Amazon Bedrock の監視や監査は中央のアカウントで実行できるため、生成 AI のすべてのアクティビティや構成の包括的な監視、監査、分析が可能になります。Amazon CloudWatch Logs は、組織全体における生成 AI のオペレーションの包括的な可視化を実現します。 生成 AI のソリューションの設定やオーケストレーションを中央のアカウントに集約し、同時に LOB 固有のリソースとの安全なインテグレーションを可能にすることで、このオペレーティングモデルは生成 AI の運用における標準化、ガバナンス、集中管理を促進します。AWS のマネージドのインフラストラクチャやサービスのスケーラビリティ、信頼性、セキュリティ、一元化された監視の機能を活用しながら、LOB 固有の要件やユースケースとの統合も可能にします。 以下は、中央集権型オペレーションモデルのアーキテクチャです。 連携型モデル 連携型モデルでは、Amazon Bedrock により、LOB チームがそれぞれの AWS アカウントで、生成 AI の共通機能を開発し、コントリビューションできる協働的なアプローチが可能になります。再利用可能なエージェント、プロンプトフロー、共有ライブラリなどの共通機能を、専任チームまたは CCoE が管理する中央の AWS アカウントに移行することができます。 中央の AWS アカウントは、生成 AI の共通的なコンポーネントを統合しオーケストレートするためのハブとして機能し、アクショングループやプロンプトフローの統一されたプラットフォームとなります。生成 AI のソリューションの設定やオーケストレーションは、LOB の AWS アカウントで保持されますが、LOB は中央のアカウントの Amazon Bedrock エージェント、プロンプトフロー、そしてその他の共有コンポーネントを使用することができます。 この連携型モデルにより、LOB は生成 AI のソリューションの主導権を維持し、中央で管理されるコンポーネントを再利用するといったメリットを享受しながら、特定の事業要件に合わせてカスタマイズすることができます。中央のアカウントは、生成 AI の共有コンポーネントの共通化、ガバナンス、スケーラビリティを維持し、組織全体のコラボレーションや標準化を促進します。 Payment Card Industry (PCI)、PII、 General Data Protection Regulation (GDPR) 、 Health Insurance Portability and Accountability Act (HIPAA) に関連するような機密データは、LOB の AWS アカウントで保持される傾向があります。このアプローチでは、LOB がベクトルストアでセンシティブなビジネスデータを管理できるようにし、適切なガバナンスやセキュリティ対策なく中央のチームや CCoE がアクセスできないようにすることができます。 連携型モデルは、分散型の開発、中央集権型の連携、中央集権型の監視を組み合わせたものです。このオペレーティングモデルは、コラボレーション、再利用性、標準化を促進すると同時に、LOB が 生成 AI のソリューションを管理できるようにします。AWS のマネージドインフラストラクチャとサービスのスケーラビリティ、信頼性、セキュリティ、中央でのモニタリング機能を使用し、自律性とガバナンスの調和のとれたバランスを促進します。 以下は、連携型オペレーションモデルのアーキテクチャです。 コスト管理 全社的に Amazon Bedrock の利用状況や、LOB 毎のコストを分析したい場合があるかもしれません。各 LOB の AWS アカウントの基盤モデルのコストや利用状況を追跡するに、LOB 毎のモデルの呼び出しを記録するソリューションを実装できます。 Amazon Bedrock は現在、 推論プロファイル を使用したモデル呼び出しのリソースをサポートしています。推論プロファイルを定義して、Amazon Bedrock の利用状況のメトリクスを追跡したり、モデル呼び出しのリクエストを監視したり、スループットを向上させるためにモデル呼び出しのリクエストを複数の AWS リージョン にルーティングしたりすることができます。 推論プロファイルには 2 つのタイプがあります。Amazon Bedrock にあらかじめ定義されている クロスリージョン推論プロファイル は、モデルのリクエストをルーティングできる複数の AWS リージョンを含んでいます。もう 1 つは アプリケーション推論プロファイル で、これはオンデマンドのモデル呼び出しのリクエストを送信する際に、コストとモデルの使用状況を追跡するためにユーザーが作成するものです。コスト配分タグなどのカスタムタグをアプリケーション推論プロファイルに添付することができます。プロンプトを送信する際には、推論プロファイル ID または Amazon リソース名 (ARN) を含めることができます。この機能により、さまざまな LOB、コストセンター、もしくはアプリケーションのコストの追跡や監視をすることができます。アプリケーション推論プロファイルの詳細については、「 Amazon Bedrock を使用した生成 AI のコストと使用状況の追跡、配分、管理 」を参照してください。 結論 生成 AI のオペレーティングモデルは中央集権型モデルから始めることが多いですが、生成 AI の技術開発の急速な発展、俊敏性の必要性、そして価値を迅速に獲得したいという要求の高まりにより、連携型モデルへと向かっていく傾向があります。 連携型のオペレーティングモデルでは、LOB は専門知識や事業課題を精通しているといった利点を活かして、生成 AI のソリューションを用いたイノベーションや実験を進めていくための自由度を獲得することができます。 データアクセスの方針、モデルのリスク管理、コンプライアンスの監視といった AI のワークフローにおける重要な要素は、中央のクラウドガバナンスチームによって管理されます。LOB が開発し、成功を収めた生成 AI ソリューションは、中央のチームによって全社的な再利用が推進され、展開されます。 この連携型モデルは、ドメインの問題に最も精通している LOB からのイノベーションを加速させると同時に、中央のチームは、組織のポリシーに準拠したソリューションを管理、強化、拡張し、それらを効率的に他の関連する事業分野に展開することができます。 このオペレーティングモデルを維持するために多くの場合、LOB と協働するビジネスオーナーを擁した専任のプロダクトチームを設置します。このチームは、LOB の変化するニーズに対応し、LLM やその他の生成 AI 技術の急速な進歩に遅れを取らないよう、生成 AI のサービスの継続的な進化、リファクタリング、強化を担当していきます。 連携型モデルは、完全に分散化された取り組みの場合に生ずるリスクを軽減しながら、過度に中央集権化されたアプローチで生ずるボトルネックを最小限に抑えるといったバランスをとるものです。 中央のチームの調整によってビジネスの俊敏性を向上させ、AI の状況が進化する中で、イノベーションのゴール、リスクの許容、迅速な価値の創出といったニーズに応じ、かつコンプライアンスに準拠しながら品質の高い生成 AI の機能の実現を加速することができます。 企業が生成 AI による革命を活用する場合、Amazon Bedrock は、組織のニーズに合わせた柔軟なオペレーティングモデルを構築する理想的な基盤となります。中央集権型、分散型、連携型のいずれのアプローチから始める場合でも、AWS は生成 AI のライフサイクル全体をサポートする包括的なサービスを提供しています。 Amazon Bedrock を試して、組織に適したオペレーティングモデルをどのように実装していくか、フィードバックをお寄せください。 著者について Martin Tunstall は、AWS のプリンシパルソリューションアーキテクトです。金融業界で 30 年以上の経験を持ち、グローバルな金融および保険業界のお客様が Amazon Web Services (AWS) の可能性を最大限に引き出せるよう支援しています。 . . Yashar Araghi は、AWS のシニアソリューションアーキテクトです。インフラおよびアプリケーションのセキュリティソリューションの設計と構築で 20 年以上の経験があります。政府、教育、金融、エネルギー、インフラなど、さまざまな業界のお客さまと仕事をしてきました。AWS での過去 6 年間では、お客様が AWS で安全で信頼性が高く、パフォーマンスに優れ、コスト最適化されたクラウドソリューションの設計、構築、運用できるよう支援してきました。 . 翻訳者について 川口賢太郎 (Kentaro Kawaguchi) と 白木文香 (Ayaka Shiraki) は、AWS プロフェッショナルサービスのシニア CS&amp;O アドバイザリーコンサルタントとシニア PT でアドバイザリーコンサルタント、デジタル戦略立案とそれに即した組織の変革に注力しています。 CCoE や AI CoE などの xCoE の組成支援などに従事しています。

本ブログは 2025 年 1 月 13 日に公開された Blog “ AWS re:Invent 2024: Security, identity, and compliance recap ” を翻訳したものです。 AWS re:Invent 2024 は、12 月 2 日から 6 日までラスベガスで開催され、54,000 人以上の参加者が 2,300 以上のセッションとハンズオンラボに参加しました。AWS が主催するこのイベントは、世界中のクラウドコンピューティングコミュニティにとって、革新的な技術と知見を共有する場となりました。 このブログでは、 オンデマンドセッション と、カンファレンスの前後で発表された主要なセキュリティ、アイデンティティ、コンプライアンスに関する発表内容を取り上げます。イベントを見逃した方や、重要なポイントを振り返りたい方のために、AWS のセキュリティに関する主要なアップデートを包括的に解説します。今年のイベントでは、ゼロトラスト、生成 AI を活用したセキュリティ、アイデンティティとアクセス管理、DevSecOps、ネットワークとインフラストラクチャのセキュリティ、データ保護、脅威検出とインシデント対応のベストプラクティスに重点が置かれました。 主な発表内容 ID とアクセス管理に関して、AWS Organizations 全体で権限管理を規模拡大するのに役立つ複数の新機能をリリースしました。 リソース コントロール ポリシー (RCP) – RCP は、組織内の AWS リソースに対して予防コントロールを一元的に作成および適用するために使用できる、新しいタイプの組織ポリシーです。RCP を使用することで、AWS でワークロードをスケールする際に、AWS リソースに対して許可される最大の権限を一元的に設定できます。 ルートアクセスの一元管理 – ルートアクセスの一元管理により、ルート認証情報を一元的に管理し、認証情報の監査を簡素化し、AWS Organizations で管理される AWS メンバーアカウント全体で、範囲を限定した特権的なタスクを実行できるようになりました。 宣言型ポリシー – 宣言型ポリシーは、組織内の AWS サービスのベースライン構成など、意図した設定を強制する方法を簡素化します。 Amazon Cognito は 4 つの新機能を発表しました。 機能ティア – Amazon Cognito は、Essentials と Plus の 2 つのユーザープールの機能ティアを開始しました。Essentials ティアは、包括的で柔軟なユーザー認証とアクセス制御機能を提供し、安全でスケーラブル、かつカスタマイズされたサインアップとサインインエクスペリエンスの実装を支援します。Plus ティアは、アプリケーションに対して高度なセキュリティニーズを持つお客様向けに、不審なサインインに対する脅威保護機能を提供します。 開発者向けコンソール – Amazon Cognito は、クイックウィザードとユースケース固有の推奨事項を備えた、合理化された導入手順を提供するようになりました。このアプローチにより、これまで以上に迅速かつ効率的に設定を行い、エンドユーザーに提供することができます。 Managed Login – この機能は、お客様の企業やアプリケーションのブランディングに合わせてパーソナライズできる、フルマネージド型のホステッドサインインおよびサインアップエクスペリエンスです。Managed Login / マネージドログインは、パスワードレス認証やローカライゼーションなどの共通の手間のかかる作業の設計と保守を軽減します。 パスワードレス認証 – パスワードレス認証により、パスキー、メール、テキストメッセージを使用してアプリケーションへのユーザーアクセスを保護できます。ユーザーがパスキーを使用してサインインすることを選択した場合、Apple MacBook の Touch ID や PC の Windows Hello 顔認証などの組み込み認証機能を使用できます。 環境内のセキュリティ問題を発見するために、 Amazon GuardDuty は Extended Threat Detection を開始しました。これは、AWS アカウント、ワークロード、データを標的とする高度な多段階の脅威を特定するために使用できる機能です。新しい攻撃シーケンスの検出結果を使用することで、長期間にわたる複数のリソースとデータソースをカバーできるようになり、一次分析にかける時間を減らし、ビジネスへの影響を最小限に抑えるために重大な脅威への対応により多くの時間を費やすことができます。 Amazon OpenSearch Service が Amazon Security Lake との zero-ETL 統合 を提供開始し、OpenSearch Service を通じてセキュリティデータをその場で直接クエリおよび分析できるようになりました。この統合により、これまでコストが高く分析が困難だった大量のデータソースを効率的に分析できるようになり、セキュリティ調査の合理化とセキュリティ環境の包括的な可視化が可能になります。データを選択的に取り込める柔軟性があり、複雑なデータパイプラインを管理する必要がないため、分析コストを削減しながら効果的なセキュリティ運用に集中できるようになりました。 AWS Security Incident Response は、環境内のセキュリティ問題への対応を支援する新しいサービスです。このサービスは、自動化された監視と調査、迅速なコミュニケーションと連携、そして AWS カスタマーインシデントレスポンスチーム (CIRT) への 24 時間 365 日のアクセスを組み合わせることで、セキュリティインシデントへの準備、対応、復旧を迅速に行うことができます。 ゼロトラスト の分野では、 AWS Verified Access と Amazon VPC Lattice の両方が、非 HTTPS リソースへのアクセスのサポートを開始しました。Verified Access を使用すると、TCP、SSH、RDP などのプロトコルを介して、VPN を使用せずに社内アプリケーションへの安全なアクセスを提供できます。Amazon VPC Lattice 向け VPC リソースのローンチにより、VPC Lattice サービスネットワークを通じてアプリケーションの依存関係にアクセスできるようになりました。TLS、HTTP、HTTPS、そして新たに TCP を含む追加プロトコルを使用して、異なる VPC、アカウント、オンプレミスでホストされているアプリケーションに依存する各種リソースにアクセスできます。AWS Verified Access を使用して非 HTTP(S) プロトコルでゼロトラストアクセスを有効にする方法については、 オンデマンドセッション をご覧ください。 Amazon Route 53 Resolver DNS Firewall は、高度な DNS 脅威に関連する不審な DNS トラフィックを監視およびブロックするために使用できる新機能を備えた、新しい高度なファイアウォールルール機能の提供を開始しました。 Amazon Virtual Private Cloud は、 ブロックパブリックアクセス 機能をリリースしました。これは、管理者が各 VPC のインターネットトラフィックを確実にブロックするために、一元的に実装できるワンクリックの一括設定機能です。 生成 AI ワークロードを本番環境にデプロイするお客様が増えるにつれて、適切なセキュリティ制御が重要になってきています。 Amazon Bedrock では、これを支援する 2 つの新機能をリリースしました 自動推論チェック – 自動推論チェックは、ハルシネーションを検出し、大規模言語モデルのレスポンスが正確であることを検証可能な証明を提供します。自動推論チェックにより、ドメインエキスパートは、運用ワークフローや組織の人事方針などの分野における知識を要約した自動推論ポリシーと呼ばれる仕様をより効率的に構築できます。Amazon Bedrock ガードレールのユーザーは、生成されたコンテンツを自動推論ポリシーと照合して不正確な点や明示されていない前提を特定し、記述が正確である理由を検証可能な方法で説明できます。 マルチモーダル有害コンテンツの検出 (プレビュー) – Amazon Bedrock ガードレールは、画像コンテンツに対するマルチモーダル有害コンテンツの検出をサポートするようになり、組織が画像にコンテンツフィルターを適用できるようになりました。パブリックプレビューで利用可能なこの機能により、独自の画像データ保護機能を構築したり、手間がかかり間違いやすい手動評価に時間を費やしたりする必要がなくなります。 AWS は、お客様の成功を支援するため、引き続きパートナーと密接に連携しています。 AWS re:Invent では、3 つの新しいパートナープログラムが開始されました AI セキュリティカテゴリー – AWS セキュリティコンピテンシーの AI セキュリティカテゴリーは、AI 環境のセキュリティ確保と高度な脅威からの AI ワークロードの防御に関する深い経験を持つ AWS パートナーを特定するのに役立ちます。このカテゴリーのパートナーは、機密データの漏洩防止、インジェクションの脅威の防止、セキュリティ態勢管理、責任ある AI フィルタリングの実装などの分野での能力が検証されています。 AWS Security Incident Response スペシャライゼーション – 現在、AWS のお客様は、社内のセキュリティインシデント対応能力をサポートするために、さまざまなサードパーティのツールやサービスを利用しています。お客様とパートナーの双方をより良くサポートするため、AWS はセキュリティイベントの準備、対応、復旧を支援する新しいサービス AWS Security Incident Response を導入しました。認定された AWS パートナーと共に、AWS Security Incident Response は、Amazon GuardDuty やその他の脅威検出ツールからの優先順位付けされたセキュリティ調査結果を AWS Security Hub を通じて監視、調査、エスカレーションします。AWS Security Incident Response は、優先度の高いインシデントのみを特定してエスカレーションするように設計されています。 Amazon Security Lake Ready スペシャライゼーション – このスペシャライゼーションは、Amazon Security Lake と統合するソフトウェアソリューションを技術的に検証し、お客様への導入実績を示した AWS パートナーを認定するものです。これらのソリューションは、AWS パートナーソリューションアーキテクトによって、アーキテクチャの妥当性と実証済みのお客様の成功が技術的に検証されています。 オンデマンドでコンテンツを体験 現地で参加できなかった方や、セッションをもう一度視聴したい方は、 オンデマンド で利用可能なセッションをご覧いただけます。 Matt Garman による CEO キーノート では、AWS がお客様とパートナーの皆様により良い未来を構築していただくために、基盤となる構成要素を再構築し、まったく新しい体験を開発している様子をご覧いただけます。また、 re:Invent 2024 の他のキーノート も視聴できます。 AWS CISO の Chris Betz による Security Innovation Talk をご覧いただき、最新の AWS イノベーションがどのようにお客様の迅速な対応とセキュリティの維持を支援しているかをご確認ください。AWS がどのように組織のセキュリティを製品、サービス、プロセスに統合・自動化し、セキュリティチームがビジネスに最大の価値をもたらす業務に集中できるようにしているかをご紹介します。また Chris は、AWS がセキュリティイノベーションをスケールし、セキュリティコミュニティに投資することで、インターネットをより安全にする取り組みについても共有します。 以下のような重要なトピックについて学ぶため、AWS のセキュリティ、アイデンティティ、コンプライアンスに関する分科会や新機能発表のトークを オンデマンド で視聴できます How AWS scales active defense (AWS がアクティブディフェンスを拡張する方法) Building a resilient and effective culture of security (レジリエントで効果的なセキュリティ文化の構築) How to maintain and automate compliance on AWS (AWS でのコンプライアンスの維持と自動化の方法) The AWS approach to secure generative AI (生成 AI に対する AWS のセキュリティアプローチ) Generative AI for security in the real world (実世界におけるセキュリティのための生成 AI) Digital sovereignty: Overcome complexity and enable future-readiness (デジタル主権：複雑さを克服し、将来に備える) 6 月 16 日から 18 日にフィラデルフィア (ペンシルベニア州) で AWS re:Inforce 2025 が開催されます。このイベントにぜひ参加して、現地でセキュリティ学習の機会を得ることをご検討ください。みなさまとお会いできることを楽しみにしています！ これらの新しい発表がお客様の組織のセキュリティポスチャの改善にどのように役立つかについて話し合いたい場合は、AWS がお手伝いします。今すぐ お問い合わせ から AWS アカウントチームにご連絡ください。 このブログに関する質問がある場合は、 AWS Security, Identity, &amp; Compliance re:Post で新しいスレッドを開始するか、 AWS Support にお問い合わせください。 Marshall Jones Marshall は AWS のワールドワイドセキュリティスペシャリストソリューションアーキテクトです。エッジ、脅威検知、コンプライアンスなどの様々なセキュリティ領域に焦点を当てた AWS コンサルティングとセキュリティアーキテクチャの経験を持ちます。現在は、セキュリティの有効性を高めリスクを低減するため、エンタープライズの AWS ユーザーによる AWS セキュリティサービスの導入と運用を支援することに注力しています。 Apurva More Apurva は AWS セキュリティ、ID、およびコンプライアンスチームのメンバーで、スタートアップから大企業まで、グローバルなプロダクトマーケティングにおいて 13 年の経験を持っています。市場ポジショニング、競合分析、カスタマーインサイトの専門家として知られ、製品ビジョンと市場ニーズ、ビジネス目標を整合させるため、部門を超えて協働しながら、ターゲット層に響く製品を展開し、収益成長を推進してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

昨年12月の AWS re:Invent に現地参加いただいた製造業のお客様を対象に、2025年2月7日(金)に「AWS re:Invent 2024 製造業のお客様向け 現地参加業 Meet-up」を開催しました。AWS re:Invent で学習いただいた内容を振り返りつつ、それを受けて各社で行っている活動内容をご共有いただき、今後の社内活動の発展につなげるネットワーキングの場としてしていただくことを目的としています。ご参加いただいた皆さまには、改めて御礼申し上げます。本ブログでは、当日のレポートをお届けします。 当日のアジェンダ オープニング AWS re:Invent Recap AWS re:Invent 2024 参加企業によるピッチコンテスト ピッチコンテスト表彰式・懇親会 クロージング AWS re:Invent Recap アマゾン ウェブ サービス ジャパン 技術統括本部 自動車・製造グループ 本部長 岡本 京 AWS re:Invent で発表された最新情報や製造インダストリーでの取組みについて、アマゾン ウェブ サービス ジャパン 技術統括本部 自動車・製造グループ 本部長 岡本よりダイジェストレポートをお届けしました。冒頭はクイズを実施し、re:Invent は昨年何回目だったか？、re:Invent 2024 で提供されたセッションの数は？と歴史や規模を振返りました（13回目、2,300セッションです！）。新しい Building Block として Inference (推論) が加わり、 Amazon Nova や Amazon Bedrock の数学的手法を使った新しいガードレール機能、複数 AI エージェントのオーケストレーションを容易にする機能のアップデートなどを振返りました。また、製造業のお客様事例をピックアップして紹介しました。イタリアの産業用車両メーカーである Iveco Group では、AWSと戦略的パートナーシップを提携し、車両ソフトウェア開発環境の整備、技術文書管理システム、図面解析システムを構築し、例えば技術図面の検索時間90%短縮、技術文書の誤りを75％削減しています( PRO202 )。イギリスのミールキット会社の Gousto は、工場のダウンタイム検知システムを構築し、稼働率目標を98％達成、スループットも10％向上しています( MFG202 )。製薬会社の Moderna はサプライチェーン管理プラットフォームを4ヶ月で構築し、配送時間短縮、在庫管理の改善を実現しています( BIZ220 )。エレベーター企業の KONE は生成AIを活用した技術者支援アプリを開発し、250人のフィールドサービス担当者に展開中です( AIM302 )。その他、エッジコンピューティング活用事例として Wiwynn 社が AWS Outposts を利用してアプリのデプロイ時間を90％削減している例などを紹介しました( HYB201 )。 AWS re:Invent 2024 参加企業によるピッチコンテスト 実際に現地参加いただいたお客様から、AWS re:Invent での学びと経験を自社に持ち帰り具体的に何を実現されようとしているのか、今後の活動見込みをご紹介いただきました。 三菱電機株式会社 AI戦略プロジェクトグループ 塚田 真規 様 お客様資料 ピッチコンテストのトップバッターは三菱電機株式会社 AI戦略プロジェクトグループ 塚田様に務めていただきました。AI戦略プロジェクトグループは、生成AI関連の取り組みを主導し、全社的な検証環境の提供や開発加速化支援を行っています。また、エンジニア同士のつながりを重視し、「 Serendie Bootcamp コミュニティ」（1,400人以上が参加）や「 MAWS-UG 」といったコミュニティを運営しています。これらのコミュニティを活用し、事前交流会や事後報告会など、様々なイベントを実施しています。生成AIの具体的な活用事例として、生産ラインのトラブル対応の効率化プロジェクトを紹介していただきました。Amazon Bedrock の Multi-agent collaboration 機能と Model Dilsillation (蒸留) 機能を活用し、属人性の高い作業の自動化と運用コストの削減を目指しています。最後に、AWS re:Invent の現地参加の意義として、登壇者との直接交流を通じた「しこう」（考える思考とトライアルの試行）に触れることができる点を挙げ、そこで得た知見を社内で共有することの重要性を強調しました。 株式会社ＤＮＰ デジタルソリューションズ コミュニケーションプロセス開発本部第１部 IPS オフショア課 Nguyen Dinh Hoang 様 続いて、株式会社ＤＮＰ デジタルソリューションズ コミュニケーションプロセス開発本部第１部 IPS オフショア課の Hoang 様より、参加報告をいただきました。ＤＮＰ 社からは熱意のあるメンバー4名で参加され、AWS 関連サービスのキャッチアップ、現地でしか体験できないハンズオンセッションへの参加と Expo での交流を目的としていました。特に印象的だったのは、世界中から6万人が集まる規模感と、セッションの質の高さ、基礎から応用まで実務に即した内容で、開発者と直接対話できたことでした。また、AWS re:Invent で知った AWS Builders Cards (カードゲーム形式の学習教材) にインスピレーションを受け、同社のIPS (Information Processing Service) 業務の改善に向けて、社内向けにアレンジした教材を独自に開発しています。これにより、リモートワーク環境下でのコミュニケーション活性化や、新フレームワークの理解促進につながっています。 得られた知見を活かした自己成長と、より効率的な学習教材の開発という具体的な成果を挙げ、「行って良かった」と締めくくりました。 ダイキン工業株式会社 テクノロジー・イノベーションセンター 主任技師 前川 博志 様 三社目は、ダイキン工業株式会社 テクノロジー・イノベーションセンター 前川様からの参加報告です。AWS re:Invent でインパクトが大きかったことの1つとして、Amazon CTO Dr. Werner によるキーノートから「Simplexity」という言葉を挙げました。システムはどんどん複雑になっていくので、自分たちで扱える単位に分割して、ある部分を他者に委ねることが重要と考え、例えば Amazon Aurora DSQL のようなものを自分たちで作ろうとすると複雑になりコストも掛かるが、AWS のサービスをうまく使うことで、自分たちで複雑なシステムを開発・管理する負担をオフロードしていけるのではないか、と述べました。また、敢えてこの時代に AWS re:Invent に現地参加したことの意義について触れ、Chalk Talk や Code Talk といったホワイトボーディングやソースコードを見ながらのセッションが非常に多く、日本では考えられないほど大盛況になっていたのに驚き、現地で対面で話すことの意義が大きいと感じています。自社に帰ってからは、社内コミュニティに AWS メンバーを巻き込んだり、他社コミュニティとの共同イベント実施の企画、社内の RAG システム戦略を Amazon Bedrock を最大限活用するものにアップデートしています。 コニカミノルタ株式会社 技術開発本部 システム技術開発センター アーキテクチャ開発部 第1グループ 井田 匠海 様 最後に、コニカミノルタ株式会社 技術開発本部 システム技術開発センター アーキテクチャ開発部 第1グループ 井田様より、初めて参加した AWS re:Invent でのご経験を共有いただきました。先端技術と熱気に触れることで当事者意識が芽生え、モチベーションが向上したこと、言語の壁を超えて、自然とコミュニケーションが生まれていったことを現地参加の効果として挙げています。また、ぜひ取り入れていきたい新サービスとして、 Amazon Q Developer 、 AWS Transfer Family Web Apps 、 Centrally managing AWS IAM root access を挙げ、その理由とともに紹介しました。また、 AWS GameDay にも参加し、57チーム中22位という成績を収め、グローバルな技術レベルを体感できた点についても触れました。最後に、AWS初心者や英語が苦手な人でも、グローバルな基準を実際に見られる貴重な機会として、イベントへの参加を強く推奨しました。一週間という集中的な学習期間で、専門分野を超えた人との繋がりや、新しい技術への知見を得られる機会として、非常に有意義な経験だったとの報告でした。 ピッチコンテスト表彰式・懇親会 コンテストはご参加いただいた約30社の皆さまで投票を行い、見事第1位に選ばれたのは、三菱電機株式会社 塚田様の発表でした。おめでとうございます！その他3社の皆様も、ご登壇いただきありがとうございました。懇親会では、登壇された方を囲むようにして質問をされる方が続いたり、それぞれの AWS re:Invent 体験談の共有、各社のコミュニティ事情について意見交換し合ったりなど、積極的な交流がされていました。 まとめ AWS re:Invent の期間中には日本企業向けの Meet-up もありますが、開催後にフォローアップの Meet-up イベントを AWS 主催で行うのは実は初めてのことでした。AWS re:Invent に現地参加された方々は、最新技術のキャッチアップや活用、社外との交流に意欲的なだけでなく、学んだことを自社に持ち帰って、自社のサービスや業務改善に素早く取り入れたり、より多くの仲間に体験を共有し、コミュニティを活性化することで同じ経験を広げていきたいとするモチベーションが高い方ばかりでした。「2ヶ月前の熱気を思い出せてとても満足だった」「現地は人が多すぎて、製造業同士で交流するチャンスがなかったので、大変ありがたいです」「ぜひ大阪などでも開催いただきたいです！」「他社の参加された方が持ち帰った内容や、自社での共有、活用方法をお聞きでき、とても参考になった。ぜひ来年も開催していただきたい。」などのコメントが寄せられました。また1年後も、さらにスケールアップした Meet-up が開催できるのを楽しみにしています。 本ブログはソリューションアーキテクトの中山 七美が執筆しました。

みなさん、初めまして。今週から週刊生成AIを担当する、AWS ソリューションアーキテクトの野間です。AWSや生成AIにあまり詳しくない方にも分かりやすいブログにしたいと思いますのでよろしくお願いします。 先週に引き続いてのご案内となりますが、2025 年 3 月 6 日 に&nbsp; AWS Innovate: Generative AI + Data &nbsp;がオンラインで開催されます。最新の AWS の生成 AI サービスとお客様事例を通じたユースケースを学ぶことができるイベントとなっています。アジェンダも公開されていますのでご覧の上ぜひご登録ください！ 早速今週も盛りだくさんの内容になっています。2 月 10日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Benchmark Education社、AWSの生成AIで採点を加速し学生へのフィードバックを強化」 教育関連企業のBenchmark Educationは、先生方の採点業務の負担を減らすため、AWSと協力してAIを活用した採点支援ツールを開発しました。このツールは、生徒の記述式の回答を自動で採点し、フィードバックを提供します。先生はAIの採点結果を確認し、必要に応じて修正することができます。導入後、未採点の課題が減少し、先生方は生徒と直接関わる時間を増やすことができるようになりました。このように、AIを活用することで、教育現場での業務効率化と生徒へのサポート向上を実現しています。 ブログ記事「Amazon Bedrockインラインエージェントを使用した動的なロールベースAIエージェントの構築」 Amazon Bedrockの「インラインエージェント」について説明しています。インラインエージェントは、ユーザーの役割や状況に応じて動的に機能を変更できるAIアシスタントを作成できる機能です。例として、HR（人事）アシスタントを構築し、従業員と管理者で利用できる機能を動的に変更する方法が紹介されています。従業員は休暇申請や経費精算などの基本的な機能を、管理者はそれらに加えて人事評価などの追加機能を利用できます。この機能により、複数のエージェントを作成することなく、1つのAIアシスタントで柔軟な対応が可能になります。 ブログ記事「Amazon Bedrock AgentsによるSAPインスタンス管理の活用」 このブログは、AWSのAmazon Bedrock Agentsを使用してSAPシステムの管理を効率化する方法について説明しています。Amazon Bedrock AgentsとLambda関数を組み合わせることで、従来は手作業で行っていたSAP管理タスクを自動化することができ、管理者の作業効率が向上します。SAPの管理者は、自然言語を使ってSAPシステムの起動・停止、パラメータの確認、ログファイルの分析などの作業を実行できるようになります。また、Knowledge Base機能を使用することで、大量のログファイルから必要な情報を素早く見つけることも可能です。 ブログ記事「Amazon Bedrockで学習データを自動生成し、質問応答システムのファインチューニングを実現」 このブログは、Amazon Bedrockを使用して大規模言語モデル(LLM)のファインチューニングを行う方法について説明しています。特に、データが不足している場合に、より大きな言語モデル（教師モデル）を使って合成データを生成し、それを使って小さなモデル（生徒モデル）をファインチューニングする手法を紹介しています。この方法により、限られたデータでもモデルのパフォーマンスを向上させることができます。実験結果も紹介されていますので是非ご参照ください。 ブログ記事「Amazon SageMaker AIでMedusa-1を使用したLLM推論の高速化を実現」 このブログは、大規模言語モデル(LLM)の推論速度を向上させるMedusaというフレームワークについて解説しています。Medusaは、モデルに追加のヘッドを付け加えることで、複数のトークンを同時に予測できるようにし、約2倍の速度向上を実現します。Amazon SageMakerを使用して、まずLLMのファインチューニングを行い、その後Medusaヘッドを追加して学習させる方法が説明されています。モデルの品質を維持したまま処理速度を向上させることができるので、リアルタイムの文章生成や会話システムなどの低遅延が求められるアプリケーションに有効です。 ブログ記事「Amazon Bedrockモデル評価における判定者としてのLLM」 このブログは、Amazon Bedrockで提供される「LLM-as-a-judge」という新機能について説明しています。この機能は、大規模言語モデル（LLM）の性能を自動的に評価するためのツールです。従来は人手で行っていたAIモデルの評価を、別のAIモデルが評価者（ジャッジ）となって自動的に行うことができ、評価にかかる時間とコストを大幅に削減できます。品質、ユーザー体験、指示への従順性、安全性など、様々な観点からモデルの性能を評価することができ、AWSのコンソールやPythonのSDKを使って簡単に利用することができます。企業がAIモデルの性能を効率的に評価し、最適なモデルを選択するのに役立つソリューションとなっています。 ブログ記事「概念から現実へ：RAGの実証実験から本番環境への移行ガイド」 このブログは、RAG（Retrieval Augmented Generation）を、実験段階から本番環境へ移行する際の重要なポイントについて解説しています。RAGを本番環境で運用する際には、品質、コスト、レイテンシーのバランスを取ることが重要で、Amazon Bedrockを活用することで効率的に実装できます。また、データの取り扱い方や分割方法、セキュリティ対策、システムの評価方法など、実用化に向けた具体的な最適化手法についても説明されています。RAGシステムを本番環境で活用したい開発者やエンジニアにとって、実践的なガイドラインとなる内容となっています。 ブログ記事「行政サービスの効率化に向けたAI活用のリーダーシップ」 このブログは、政府機関におけるAI活用とクラウド技術の重要性について説明しています。米国政府のデジタル変革において、セキュリティや効率性を確保しながら、政府機関がAIやクラウド技術を活用することで、より良い公共サービスを提供できることが示されています。例えば、米国空軍では予測メンテナンスにAIを活用し、航空機の運用効率を向上させています。また、シンガポールや英国などの事例も紹介され、世界中の政府機関がAWSを活用してデジタル変革を進めていることが分かります。 ブログ記事「Amazon SageMaker JumpStartでFalcon 3モデルが利用可能に」 Amazon SageMaker JumpStartでFalcon 3モデルファミリーの提供を開始しました。Falcon 3は、アブダビのTechnology Innovation Institute（TII）が開発した、科学、数学、コーディング能力に特化したオープンソースの言語モデルです。現在、SageMaker JumpStartでは、1Bから10Bまでの様々なサイズのモデルが利用可能で、ユーザーはUIを使用した簡単な操作か、PythonのSDKを使用したプログラミングのどちらかの方法でモデルをデプロイすることができます。このサービスにより、機械学習の専門家でなくても、高度な言語モデルを簡単に利用することが可能になりました。 ブログ記事「Amazon Bedrock Agentsを使用したバーチャル気象予報士の構築」 このブログは、Amazon Bedrock Agentsを使用して、天気予報に関する質問に答えることができるAIバーチャル気象予報士を構築する方法について説明しています。このソリューションでは、ユーザーが自然な言葉で天気に関する質問をすると、AIが適切な回答を提供します。システムの構築には、Amazon Bedrock Agents、AWS Amplify、AWS Lambda、Amazon Cognitoなどの複数のAWSサービスが使用されており、ユーザー認証から天気情報の取得まで、すべての機能が統合されています。例えば「今日ダラスでバーベキューができますか？」といった質問に対して、天気状況を考慮した回答を提供することができます。 ブログ記事「Amazon Pharmacy、生成AIで処方箋処理時間を90%改善」 Amazon Pharmacyをご存じでしょうか？、Amazonが提供するオンライン薬局サービスです。このブログでは、Amazon PharmacyがAWSの生成AIを活用して処方箋処理を改善した事例を紹介しています。Amazon Pharmacyは、生成AIを処方箋の受付、保険確認、処理、配送まで全体のプロセスに組み込むことで、処方箋の処理時間を90%削減することに成功しています。また、HIPAA準拠のチャットボットを導入することで、お客様は従来の対面式の薬局よりも素早く必要な情報を得られるようになりました。開発期間も9ヶ月から3ヶ月に短縮され、データ管理とテストを重視した開発アプローチが成功の鍵となりました。このケースは、生成AIが医療分野の顧客体験を大きく向上させる例を紹介しています。 ブログ記事「AWSの生成AIを活用したHansenによる通信事業者向け製品カタログの最適化」 このブログは、HansenとAWSが中心となり開発した、AIを活用した製品ライフサイクル管理ソリューション紹介しています。このソリューションは、Amazon Bedrockの生成AIを使用して、通信サービスプロバイダー（CSP）の製品カタログを分析し、最適化するためのレコメンデーションを提供しています。従来は手作業で時間がかかっていたカタログ分析や製品の最適化が、AIアシスタントによって数秒で実行できるようになりました。 ブログ記事「Amazon Bedrockにおける最小権限アクセスの実装」 このブログは、Amazon Bedrockにおける最小権限アクセスの実装方法について説明しています。最小権限アクセスとは、ユーザーやプログラムに必要最小限の権限のみを付与するセキュリティの考え方です。ブログでは、モデルの選択から運用までの各段階で、どのようにアクセス制御を実装すべきかを具体的に解説しています。 ブログ記事「最新のコミュニケーションハブを使用したAI駆動の顧客体験の構築」 このブログは、SMSやWhatsApp、メールなどの複数のコミュニケーションチャネルを一元管理し、そこにAmazon Bedrockなどの生成AIサービスを組み合わせることで、パーソナライズされた顧客対応を実現する方法を紹介しています。顧客とのやり取りデータを一元管理し、分析できる仕組みも紹介されており、効果的な顧客対応実現の参考になります。 ブログ記事「Amazon Q Business、企業のナレッジベースの大規模統合を簡素化」 このブログは、企業の大規模なデータを効率的に取り込み、処理する方法を紹介しており、特にAWSのサポートエンジニアリングチームでの実際の活用事例を基に解説しています。Amazon Q Businessを使用することで、社内の文書やデータを安全に統合し、自然な会話形式で必要な情報にアクセスできるようになります。このソリューションにより、企業は業務効率を向上させ、より迅速な情報アクセスと意思決定が可能になります。 ブログ記事「国防総省のためのゼロトラスト構築：国防総省CIOゼロトラストプログラム管理室長Les Callからのインサイト」 このブログは、米国国防総省(DoD)のゼロトラスト戦略の実装に関する内容を解説しています。従来のセキュリティモデルでは十分な対応が難しくなってきている中、DoDはAWSと協力してゼロトラストアーキテクチャの導入を進めています。組織全体での相互運用性の確保や、AIを活用した予防的なセキュリティアプローチの採用など、様々な取り組みが行われています。 ブログ記事「Rich Data CoとAWSの生成AIによる与信判断の変革」 このブログは、Rich Data Co (RDC)という企業がAWSの生成AIを活用して、クレジット審査の意思決定を改善する取り組みについて説明しています。Amazon Bedrockを活用してデータサイエンスチームをサポートする「データサイエンスアシスタント」と、ポートフォリオマネージャーや分析者をサポートする「ポートフォリオアシスタント」という2つのAIアシスタントを開発・構築され、複雑な質問への回答やコード生成、データベース検索などの機能を提供しています。 ブログ記事「Amazon BedrockとAppianの生成AIスキルによるビジネスプロセスの革新」 このブログは、AmazonのBedrockとAppian社の生成AIスキルを組み合わせたビジネスプロセス改革についての取り組みを紹介しています。特に住宅ローン処理の期間短縮や、金融サービスでのデータ抽出時間の削減、法的文書のレビュー効率化などの事例が紹介されています。 ブログ記事「DeepSeek-R1、CrewAI、Amazon SageMaker AIを使用したエージェントAIソリューションの構築」 このブログは、Amazon SageMaker AIとDeepSeek-R1、CrewAIを組み合わせて、AIエージェントシステムを構築する方法について説明しています。研究を行うエージェントと文章を作成するエージェントの2つを連携させて動作させる実践的な例を紹介しています。 ブログ記事「Crop.photoとAmazon Rekognitionによる一括画像編集の自動化」 このブログは、AWSのパートナーであるEvolphin Software社が提供する「Crop.photo」というサービスについて説明しています。Crop.photoは、AIを活用した画像の一括編集ツールで、主にEコマースやスポーツ業界向けに開発されました。Amazon Rekognitionと連携することで、大量の商品画像やスポーツ選手の写真を自動で効率的に処理することができます。例えば、ある小売業者では画像編集の生産性が70%向上し、数日かかっていた作業が数秒で完了できるようになりました。 ブログ記事「コンソール上の Amazon Q からベストプラクティスを学ぼう」[翻訳記事] このブログは、Amazon Qの活用方法について説明しています。Amazon Qは、AWSコンソール上で開発者やIT担当者の作業をサポートする便利なツールです。具体的には、AWSサービスの学習支援、コードスニペットの生成、システム設計のアドバイス、コスト分析などができます。質問をすると自然な会話形式で回答が得られ、AWSの知識が少ない方でも簡単に利用できます。また、プロンプトの書き方のコツもなど、より良い回答を得るためのヒントも記載されています。 ブログ記事「20 Minutes 社がAmazon Bedrock で生成 AI を活用してジャーナリストを支援し購読者を惹きつけている方法」[翻訳記事] このブログは、フランスの主要メディア「20 Minutes」が、ジャーナリストの作業効率を向上させるため、記事の要約作成や関連タグの提案、ニュース通信社からの記事の書き直しなどの作業を生成AIを利用して自動化しています。また、広告主向けに記事のブランドセーフティ（広告掲載に適しているかどうか）を自動評価する機能も実装しました。その結果、1記事あたり平均8分の時間短縮を実現し、ジャーナリストが本来の取材・執筆業務に集中できるようになりました。 ブログ記事「AWS が生成 AI で E コマースにおけるショッピングアシスタントを強化」[翻訳記事] このブログは、AWSが提供する新しいAIショッピングアシスタントについて紹介しています。このAIアシスタントは、オンラインショッピングをより便利で楽しいものにするために開発されました。例えば、DIYプロジェクトのための建材選びなど、商品選択に迷う顧客に対して、パーソナライズされたアドバイスを提供します。Amazon Bedrockなどの最新のAI技術を活用し、顧客の質問に自然な対話で応答しながら、最適な商品を推薦することができます。 サービスアップデート Amazon Q Developer now supports upgrade to Java 21 Amazon Q Developerは、Java 21へのアップグレードをサポートするようになりました。開発者は安全にシステムを最新化することができ、性能向上やセキュリティ強化といったメリットを得ることができます。この機能は、Visual Studio CodeやIntelliJ IDEAといった一般的な開発ツールで利用可能です。 Amazon Q generative SQL is now available in additional regions Amazon Q generative SQLの提供リージョンを拡大し、米国東部（オハイオ）とアジア太平洋（ソウル）でも利用可能になりました。Amazon Q generative SQLは、Amazon Redshiftのウェブベースのクエリエディタで使用できる機能で、自然言語を使用してSQLクエリを作成できます。この機能により、SQLの専門知識に関係なく、ユーザーは会話形式でデータベースに対してクエリを実行することができます。 AWS HealthScribe now supports GIRPP note template for behavioral health AWS HealthScribeの新機能として、メンタルヘルスに関する診療記録をGIRPP形式で自動生成する機能をリリースしました。この機能は、医師と患者の会話を生成AIが自動的に文書化することで、医療従事者の記録作成の時間を大幅に削減することができます。この機能は米国東部（バージニア北部）リージョンで利用可能となっています。 Anthropic’s upgraded Claude 3.5 Sonnet now available in the Asia Pacific (Sydney) Region Anthropicの最新モデル「Claude 3.5 Sonnet」がアジアパシフィック（シドニー）リージョンで利用可能になりました。 以上、今週も盛りだくさんでしたが、さらにもう一つだけ。 AWSのBIサービスである Amazon QuickSight に生成AIアシスタントである Amazon Q の機能が追加され、自然言語で質問や分析ができるのはご存じでしょうか？その生成AIの機能を簡単に試していただけるデモサイトが こちら にあります。Amaon Q in QuickSight は正式には日本語サポートをしていないのですが、すでにかなり日本語を解釈するようになっています。デモサイトには日本語のサンプル質問文がありますので、ぜひ試してみてください。 それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2024 年 12 月のアップデートまとめ はお読みいただけましたでしょうか。2025年のアップデートをお届けする最初のブログ更新となります。本年も Amazon Connect の最新情報や有益な情報をお届けできるよう努めてまいります。 今月も アップデート 情報を中心に以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025 年 1 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートについて 注目#1: Amazon Connect Contact Lens launches new real-time dashboard (Amazon Connect Contact Lens が新しいリアルタイムダッシュボードをリリース) 注目#2: Amazon Connect Contact Lens dashboards now provide configurable groupings and filters (Amazon Connect Contact Lens のダッシュボードに、設定可能なグループ化とフィルタが表示されるように) Amazon Connect のダッシュボード機能に、コンタクトセンター運用の効率化を支援する2つのアップデートがありました。1つ目のアップデートでは、Amazon Connect Contact Lens に新しいダッシュボードが追加され、エージェントのリアルタイム監視機能が大幅に強化されました。エージェントのステータス、経過時間に応じた強調色表示や、コンタクトのライブモニタリング、割り込み機能など、スーパーバイザーの迅速な状況把握とアクションをサポートする機能が実装されています。さらに2つ目のアップデートでは、ダッシュボードのカスタマイズ機能が拡充され、ウィジェットレベルでのフィルタリングやグループ化、メトリクスの追加・削除が可能になりました。これにより、各ビジネスのニーズに合わせた詳細な分析や、キューの着信や応答状況の把握、顧客対応のパフォーマンス測定がより柔軟に行えるようになります。これら2つのアップデートにより、コンタクトセンターのリアルタイム監視と分析機能が格段に向上し、より効果的な運用管理が可能となりました。これらのダッシュボードのカスタマイズ機能は、Amazon Connect が提供する6つのダッシュボード (会話型分析ダッシュボード、キューおよびエージェントパフォーマンスダッシュボード、フローパフォーマンスダッシュボード、日中予測パフォーマンスダッシュボード、エージェントパフォーマンスの評価ダッシュボード、アウトバウンドキャンペーンのパフォーマンスダッシュボード) で利用可能です。詳細な設定方法は 管理者ガイド を参照してください。 2. 2025年1月のアップデート一覧 Amazon Connect Cases now provides more granular search capabilities and customizable case list views (Amazon Connect Cases がより詳細な検索機能とカスタマイズ可能なケースリストビューの提供を開始) – 01/31/2025 Amazon Connect Cases では、エージェントとスーパーバイザーがエージェントワークスペース内でカスタムフィールド値を使用したケースのフィルタリングが可能になりました。これにより、検索結果の絞り込みや関連するケースの検索が容易になります。ユーザーは、業務に応じて、カスタムカラムの追加、既存カラムの非表示または再配置、ページあたりのケース数の調整を行うことで、ケースリストビューと検索結果のレイアウトをカスタマイズすることもできます。これらの機能強化により、ユーザーはケースリストビューを自らの業務スタイルに合わせてカスタマイズし、ケース管理のワークロードをより効率化することが可能です。 &nbsp;関連リンク 管理者ガイド ワークショップ Amazon Connect now supports agent time off scheduling up to 24 months in the future (Amazon Connect で最大 24 か月先までのエージェントの休暇スケジュールがサポートされるようになりました。) – 01/31/2025 Amazon Connect Forecasting, capacity planning, and scheduling に、エージェントが最大 24 か月先の休暇をスケジュールできる機能が追加されました。これにより、マネージャーとエージェントは事前に休暇を計画しやすくなり、エージェントは 休暇を最大 24 か月前 に予約できるようになります。さらに、スケジュールグループの事前に承認された休暇期間（グループ手当）を一度に最大27か月分までアップロードできるようになりました。これらの制限の引き上げにより、エージェントは個人の時間をより柔軟に計画できるようになり、マネージャーは将来の人員配置のニーズを把握できるようになり、より効率的なリソース配分の計画が可能になります。 関連リンク 管理者ガイド Amazon Connect now provides daily headcount projections in capacity plan downloads (Amazon Connect でダウンロードされるキャパシティプランに日次の人員予測が含まれるようになりました) – 01/22/2025 Amazon Connect Forecasting, capacity planning, and scheduling でキャパシティプランをダウンロードした際に日次の人員予測(日次メトリクスシート)が含まれるようになり、人員配置の要件をより高い精度で確認できるようになりました。週次と月次の予測は既に以前からキャパシティプランに含まれていましたが、今回のリリースで日単位の人員要件を最大 64 週先まで確認できるようになります。このようにきめ細かく確認できるので、季節性に配慮し、日レベルでさまざまな想定縮小率を適用しながら、雇用する人員数などの人員配置と雇用に関する重要な決定を簡単に行えるようになります。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect agent workspace now supports audio optimization for Citrix and Amazon WorkSpaces virtual desktops (Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップのオーディオ最適化をサポートするように) – 01/21/2025 Amazon Connect エージェントワークスペースは、Citrix および Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境からカスタマーサービスエージェントのローカルデバイスに音声をリダイレクトする機能をサポートするようになりました。音声リダイレクトにより、仮想デスクトップで処理される音声通話の音声品質が向上し、遅延が軽減され、エンドカスタマーとエージェント両方のエクスペリエンスが向上します。 関連リンク 管理者ガイド Release Notes Amazon Connect outbound campaigns can connect a call with an agent in under 2 seconds (Amazon Connect アウトバウンドキャンペーンで 2 秒以内にエージェントに電話をつなげることが可能に) – 01/18/2025 自動通話分類をサポートしながら、キャンペーンコールに出たお客様を利用可能なエージェントに 2 秒未満でつなぐように Amazon Connect アウトバウンドキャンペーン を設定できるようになりました。この機能強化は、組織が米国の電話消費者保護法 (TCPA) などのテレマーケティングの法律に関する規制コンプライアンスをサポートするのに役立ち、カスタマーエンゲージメントとエージェントの生産性も向上します。通話分類では、機械学習 (ML) を使用して通話の結果が自動的に分類されるので、エージェント入力が不要になります。そのため、エージェントの生産性が向上し、カスタマーエンゲージメントの効率が上がります。アウトバウンドコールのパフォーマンスを最適化するために、Amazon Connect の ベストプラクティス に従って接続レイテンシーを短くすることをお勧めします。Amazon Connect アウトバウンドキャンペーンは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now offers a public preview of persistent agent connections for faster call handling (Amazon Connect で通話処理を高速化する永続的なエージェント接続のパブリックプレビューの提供を開始) – 01/17/2025 Amazon Connect で、エージェントと Amazon Connect 間のオープンな通信チャネルを維持できるようになり、お客様との接続の確立にかかる時間を短縮できるようになりました。コンタクトセンターの管理者は、会話の終了後も永続的に接続を維持するようにエージェントのユーザープロファイルを設定できます。こうすると、その後の通話がつながるまでの時間が短縮されます。Amazon Connect の永続的なエージェント接続により、お客様がエージェントとつながるまでの時間が短くなるので、アウトバウンドキャンペーンの通話において米国の電話消費者保護法 (TCPA) などのテレマーケティングの法律に関するコンプライアンス要件を容易にサポートできるようになります。このプレビューは Amazon Connect を利用できるすべての AWS リージョン で対応しており、Amazon Connect サービスの利用と関連する電話料金の標準価格以上の追加料金はありません。 関連リンク 管理者ガイド Release Notes Amazon Connect Screen Recording now available in AWS GovCloud (US-West) (Amazon Connect の画面録画が AWS GovCloud (米国西部) で利用可能に) – 01/17/2025 Amazon Connect の画面録画が AWS GovCloud (米国西部) で利用できるようになり、政府および公共部門のお客様に対象が拡大されたことを発表いたします。この機能は、品質保証の目的でお客様とやり取り中にエージェント画面を録画できるようにするもので、以前は Amazon Connect が稼働するすべての商用 AWS リージョンで利用できました。今回の発表により、AWS GovCloud (米国) のお客様にもこの同じ強力な機能が提供されるようになります。 Amazon Connect の画面録画は、コンタクトセンターが品質保証プロセスの強化を目指すのに有用なツールです。スーパーバイザーや品質保証チームは、お客様とやり取り中のエージェントデスクトップのアクティビティをキャプチャして、エージェントのパフォーマンス、手順の遵守、改善の機会について洞察を深めることができます。この機能は、組織が高水準なカスタマーサービスを維持し、規制を確実に遵守し、エージェントのトレーニングや開発に関連する分野を特定するのに役立ちます。 関連リンク 管理者ガイド Amazon Connect Contact Lens launches new real-time dashboard (Amazon Connect Contact Lens が新しいリアルタイムダッシュボードをリリース) – 01/16/2025 Amazon Connect Contact Lens に新しいダッシュボードが追加され、1 つのインターフェイスから数回クリックするだけで、エージェントのアクティビティをリアルタイムで監視し、お問い合わせのリッスン、お問い合わせへの割り込み (引き継ぎ)、エージェントの状態の変更などのアクションをすぐに実行できるようになりました。このダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。お問い合わせ処理後にエージェントがどれくらいの時間稼働していたかを追跡し、特定のステータスでの時間を色分けして表示できるようになり、すぐに対応する必要があるライブのお問い合わせをリッスンすることができるようになりました。たとえば、エージェントがエラー状態の場合は自動的に赤色で強調表示し、ステータスを利用可能に戻すために追加の支援が必要なエージェントをすばやく視覚的に示すことができます。このダッシュボードは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens dashboards now provide configurable groupings and filters (Amazon Connect Contact Lens のダッシュボードに、設定可能なグループ化とフィルタが表示されるように) – 01/16/2025 Amazon Connect Contact Lens ダッシュボードでは、ウィジェットレベルのフィルタとグループを定義したり、列を並べ替えたりサイズを変更したり、新しいメトリクスを削除または追加したりできるようになりました。これらのダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。特定のウィジェットをさらにカスタマイズして、ビジネスニーズに最適なダッシュボードを作成できるようになりました。たとえば、キューに入れられたお問い合わせ、平均キュー応答時間、および放棄されたお問い合わせを組み合わせ、最も重要なキューでフィルター処理した 1 つの折れ線グラフを作成できます。これにより、お問い合わせの量の増加が待機時間と顧客放棄率の両方にどのように影響するかをすばやく確認できます。これらのダッシュボードは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens launches agent performance evaluations for email contacts (Amazon Connect Contact Lens がメールでの問い合わせに関するエージェントのパフォーマンス評価を提供開始) – 01/10/2025 Amazon Connect でのメールに対するエージェントのパフォーマンスを評価できるようになりました。これにより、マネージャーは、単一の使いやすいウェブインターフェイスで複数のコンタクトチャネル (音声、チャット、メール、タスク) 全体でのエージェントのパフォーマンスを評価し、エージェントの経時的なコンタクトセンター全体で集約されたインサイトを得ることができます。今回のリリースにより、マネージャーはメールスレッドとメールでのやり取りのその他の詳細 (処理時間など) を 1 つの UI で確認することで、エージェントのパフォーマンスを評価できます。コンタクトセンターでは、パブリック API を使用して、サードパーティのシステムからのデータ (CSAT、販売量、顧客維持率など) をメール問い合わせのパフォーマンス評価に組み込むこともできます。これにより、マネージャーはエージェントのパフォーマンスに関する包括的なインサイトを得ることができます。Contact Lens のパフォーマンス評価が既に利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens now provides free trials for conversational analytics and performance evaluations (Amazon Connect Contact Lens が会話分析とパフォーマンス評価向けに無料トライアルの提供を開始)　- 01/09/2025 Amazon Connect Contact Lens は、会話分析とパフォーマンス評価を初めて使用するユーザー向けに無料トライアルの提供を開始しました。音声向け会話分析を初めてご使用のお客様は、最初の 2 か月間にわたって、1 か月あたり 最初の 100,000 分の音声通話について、無料トライアルを利用して無料でご使用いただけます。さらに、Contact Lens のパフォーマンス評価を初めて使用するお客様には、最初のパフォーマンス評価を提出した日から 30 日間の無料トライアルが提供されます。無料トライアルにより、初めてご利用になるお客様は、追加費用をかけずに、コンタクトレンズの会話分析と評価を自分の環境で試験的に利用できます。この Contact Lens の無料トライアルは、Contact Lens をサポートしているすべての AWS リージョンで利用できるようになります。 関連リンク 管理者ガイド Release Notes 3. AWS Contact Center Blog のご紹介 Improving customer engagement with modern voice experiences （英語記事） デジタル時代における顧客サービスの革新的な進化について、クラウド技術とAIを活用した次世代の IVR (自動音声応答)システムを紹介します。 Amazon Connect などのクラウドベースのソリューションにより、従来の固定的なメニュー方式から、より自然で個別化された顧客対応が可能になり、顧客満足度の向上とビジネス効率の改善を実現しています。この記事では、クラウド技術を活用した最新のコンタクトセンターソリューションと、AI 技術を組み合わせた会話型 IVR システムの具体的なメリットや導入事例について詳しく解説しています。 Amazon Connect を提供する AWS が 2024 Gartner Magic Quadrant for Contact Center as a Service のリーダーに選出 （日本語翻訳） Gartner が発表した2024年の Contact Center as a Service（CCaaS）部門の Magic Quadrant において、AWS が2年連続でリーダーに選出されました。AWS の提供する Amazon Connect は、Capital One や Intuit など多数の大手企業に採用されており、AI を活用した革新的なクラウドコンタクトセンターソリューションとして高い評価を受けています。この記事では、Amazon Connect の Gartner Magic Quadrant での評価について解説しています。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2024 年 11 月 25 日に公開された “ Working with AWS AppSync Events: Serverless WebSockets for Pub/Sub ” を翻訳したものです。 AWS AppSync は、アプリケーションをイベント、データ、AI モデルに接続することを簡素化し、管理します。新しく追加された AWS AppSync Events により、開発者はサーバーレス WebSocket 経由で、それらのサブスクライブしたクライアントに対して任意のイベントソースからの更新を配信することで、リアルタイムの体験を作成できます。AWS AppSync Events は、GraphQL に縛られないスタンドアロンな Pub/Sub サービスを提供します。 この記事では、リーダーボードというシンプルで実用的なユースケースから始めます。ただし、今後の記事では、様々な認証方式、データの拡張、イベント API が役立つその他のシナリオについても紹介していきます。 アプリケーションの概要 一時リーダーボードは、その名の通り、データを永続化しないリーダーボードです。これは短時間で終了するゲームでよく使われますが、過去に何が言われたかよりも、その瞬間に何が言われたかが重要な、大量のメッセージの行き来するチャットアプリでもこのアーキテクチャは当てはまります。 このソリューションを自分で実装したい場合は、コードと導入手順を このリポジトリ からクローンできます。 以下のスクリーンショットに示されているように、このアプリケーションは 単一のページから 、ユーザーがリアルタイムですべてのプレーヤーの位置情報の更新を サブスクライブすることができる ようになっています。外部ソースからイベントが投稿されるのをシミュレートするため、「シミュレートスコアリング」ボタンが含まれており、 「シミュレートスコアリング」ボタンをクリックすると 一定の間隔で一連の更新が配信されます。 アーキテクチャがシンプルであることが重要なポイントです。認可サービス、API、データベースは必要ありません。ウェブアプリケーション内で直接イベント API を利用しているだけなのです。 フルスタックアプリケーションの作成 AWS コンソールでこれを設定する方法が最も簡単ですが、この記事では AWS CDK の L1 コンストラクタを使用して Event API を作成する方法を示します。 さらに、AWS 上でフルスタックアプリケーションを構築する際、AWS Amplify Gen 2 は TypeScript ファーストな開発環境を提供することで優れており、必要に応じて CDK L2 および L1 の構成要素に移行することができます。 AWS Amplify は Publish/Subscribe の簡素化のために使用されますが、イベント API を使うには必須ではありません。 Amplify Gen 2 でフロントエンドリポジトリを初期化するには、次のコマンドを実行してください。 npm create amplify そのコマンドは、AWS CDK と Amplify JavaScript ライブラリを自動的にインストールするだけでなく、開発者が AWS バックエンドを追加/変更できる amplify ディレクトリも生成します。 次に、 auth フォルダと data フォルダを削除しても構いません。これらは、このプロジェクトでは必要とされない Amazon Cognito と AWS AppSync GraphQL の設定を参照しています。 最後に、 amplify/backend.ts を更新して、不要なサービスの記述を削除します。 import { defineBackend } from '@aws-amplify/backend' const backend = defineBackend({}) AWS CDK を使用したイベント API の作成 AWS Amplify を使って、フルスタック CDK プロジェクトを作成しています。Amplify は複数の AWS サービスを抽象化していますが、AWS が提供するサービスの幅が広いため、CDK コンストラクタを利用してフォールバックするサービスも多数あります。これにより、開発者はこれらのコンストラクタが追加されるとすぐに、コード内で AWS サービスを使い始めることができます。 この機能を活用するため、 AWS AppSync の API を作成するために使用される L1 コンストラクトをインポートします。 はじめに、アプリケーションを構成する最小単位の要素をすべて含む個別のリソーススタックを作成します。 amplify/backend.ts ファイルに、次の行のコードを追加してください。 const customResources = backend.createStack('custom-resources-leaderboard') これは単にサービスをグループ化するために使用できる論理的なコンテナです。 本ガイドの目的に沿ったイベント API は、3 つの部分に分かれています。 API そのもの API が発行とサブスクリプションに使用できる名前空間 API を保護するために必要な認証メカニズム import { AuthorizationType, CfnApi, CfnApiKey, CfnChannelNamespace, } from 'aws-cdk-lib/aws-appsync' // previous code... // new code const cfnEventAPI = new CfnApi(customResources, 'cfnEventAPI', { name: 'realtime-leaderboard', eventConfig: { authProviders: [{ authType: AuthorizationType.API_KEY }], connectionAuthModes: [{ authType: AuthorizationType.API_KEY }], defaultPublishAuthModes: [{ authType: AuthorizationType.API_KEY }], defaultSubscribeAuthModes: [{ authType: AuthorizationType.API_KEY }], }, }) new CfnChannelNamespace(customResources, 'cfnEventAPINamespace', { name: 'default', apiId: cfnEventAPI.attrApiId, }) const cfnApiKey = new CfnApiKey(customResources, 'cfnEventAPIKey', { apiId: cfnEventAPI.attrApiId, description: 'realtime leaderboard demo', }) AWS AppSync Events は最近リリースされたため、現時点では L1 コンストラクトのみが利用可能です。より簡潔なコンストラクト (L2) は現在開発中です。L2 が利用可能になれば、この記事を更新します。 この API イベントが認証に API キーを使用していることに注目してください。これは開発目的とテストには適していますが、 ドキュメント では、AWS Identity and Access Management (IAM)、Amazon Cognito、OIDC、AWS Lambda の権限を含む認証モードの使用方法も示されています。 バックエンドリソースの作成の最後のステップは、解決された値をフロントエンドアプリケーションに渡すことです。幸いなことに、Amplify の JavaScript ライブラリは、必要な値が設定されたフォーマットで渡されている限り、イベントへの接続、公開、サブスクライブが簡単にできるようにアップデートされています。 amplify/backend.ts ファイルの最後に、次のコードを貼り付けてください。 backend.addOutput({ custom: { events: { url: `https://${cfnEventAPI.getAtt('Dns.Http').toString()}/event`, api_key: cfnApiKey.attrApiKey, aws_region: customResources.region, default_authorization_type: AuthorizationType.API_KEY, }, }, }) バックエンドをデプロイする準備ができました。これにより、プロジェクトのルートに amplify_outputs.json ファイルが作成され、フロントエンドを構成するために必要な出力が含まれます。 AWS アカウントを設定していない場合は、Amplify の こちらのガイド に従って認証情報を設定してください。 次のコマンドを実行してデプロイします。 npx ampx sandbox # npx ampx sandbox --profile your-profile-name AWS Amplify を利用したイベント API への接続、公開、サブスクライブ このプロジェクトの リポジトリ は、すでに Amplify で構成されています。これは components/configureAmplify.tsx ファイルに示されており、 app/layout.tsx ファイルで利用されています。 あとは、フロントエンドから関連するメソッドを呼び出して、バックエンドが機能することをテストするだけです。 設計上、AWS AppSync Events は Amplify ライブラリを必要としません。ネイティブの WebSocket プロトコルを使用して クライアントを構成 することが可能です。Amplify は単に、ボイラープレートを防ぐための便利なソリューションを提供するだけです。 app/page.tsx ファイルでは、バックエンドで作成した default という名前のチャネルへの接続を設定する必要があります。また、クライアントでセグメントを作成することもできます。この動作を確認するため、 useEffect 内で次のコードでアプリケーションに接続します。 const channelConnect = async () =&gt; { try { const channel = await events.connect('/default/leaderboard') channelRef.current = channel channel.subscribe({ next: handleNewData, error: (err) =&gt; console.log(err), }) } catch (e) { console.log('Error connecting to channel: ', e) } } Amplify の events.connect 関数は、 default/leaderboard チャネルへの接続を確立するために使用されます。これにより、そのチャネルからの受信データをサブスクライブできるようになります。 「Simulate Scoring」ボタンをユーザーがクリックするたびに、イベントを発行します。これは同じページから発生していますが、Lambda 関数や他のシステムやアプリケーションからも簡単に追加できます。 データの公開には events.post 関数が使用され、 app/page.tsx ファイル内の次のコードで示されているように、ランダムなプレーヤーが選択され、ランダムなスコア更新が与えられ、イベント API に投稿されます。 const handlePublish = async () =&gt; { for (let i = 0; i &lt;= 10; i++) { const randomItem = leaderboardData[Math.floor(Math.random() * leaderboardData.length)].id const randomScore = Math.floor(Math.random() * 20) await events.post('/default/leaderboard', { id: randomItem, score: randomScore, }) await new Promise((resolve) =&gt; setTimeout(resolve, 100)) } } まとめ この記事では、AWS AppSync Events がグリーンフィールドとブラウンフィールドの両方のアプリケーションで使用できるシンプルな Pub/Sub ソリューションを提供することを説明しました。また、Amplify Gen 2 を使用して L1 コンストラクタを導入し、開発者が新しく発表された機能を IaC でよりすばやく使用できるようになることを紹介しました。 このアプリケーションはシンプルなデモンストレーションではありましたが、AWS AppSync Events は、ゲームやライブオークションなど大規模なユーザが見込まれるサービスにまで適用できることに注意が必要です。 月 250,000 件のリアルタイムイベント API 操作を無料で利用できます。AWS AppSync Events の詳細については、 ドキュメントページ をご覧ください。価格に関する詳細は、 価格ページ をご確認ください。 翻訳は Solutions Architect の 吉村 が担当しました。

本記事は、2024 年 11 月 22 日に公開された “ Building RAG-based applications with AWS Amplify AI Kit and Neon Postgres ” を翻訳したものです。 現代のアプリケーション開発は、優れた開発体験 (DX) を提供するツールだけでなく、入門から本番環境への道のりの間の適切なバランスを含むようになりました。この考え方が、 Amplify AI kit のリリースの背景にあります。大規模言語モデル (LLM) との対話やプロンプトからコンテンツを生成するなどの一般的な AI タスクを抽象化することで、開発者は市場投入までの時間を短縮し、ボイラープレートコードの作成を避けることができます。 この記事では、入門の段階を超えて、Amplify のデフォルトのデータベースモデルではなく、 Neon からサーバーレス Postgres データベースを使用して製品データを取得します。そうすることで、検索拡張生成 (RAG) を使用して LLM と対話するために必要なコードを簡素化します。 アプリケーションの概要 アプリケーションの利用者にとって魅力的なのは、既存の製品と競合するのではなく、AI を活用して既存の製品を強化するためにどのように使用されるかです。それをわかりやすく説明するシンプルで効果的な方法は、顧客が対話できるチャットボットを作成することです。実際のシナリオでは、顧客が自分で買い物をするのを妨げることはありませんではなく、自然言語を使用して購入へ導くものです。 アーキテクチャ的に言えば、ユーザーが当サイトを訪問するたびに、LLM 対応のボットとチャットできます。これらのモデルは一般的なデータで学習されていますが、製品情報も反映できることが望ましいです。製品情報はいつでも変更される可能性があるため、データベースにアクセスして最新情報を引き出すことが重要です。一般情報に加えて特定の情報にもアクセスできる機能を持つのが強力であり、 Tools (「function-calling」とも呼ぶ) によってこの機能が実現されます。 覚えておく必要がある重要な概念は、LLM がツールを使用することを選択した場合、ユーザーに代わってデータにアクセスするわけではないということです。LLM は単に、ユーザーのプロンプトに基づいて、最適なツールを伝えているだけです。その後、アプリケーションが呼び出す関数を決定します。 その関数からのレスポンスは、LLM に送り返され、エンドユーザーに対して自然な言語表現として整形されます。 想像できるように、このパターンを自分で調整するのは面倒なだけでなく、エラーにつながる可能性があります。幸いなことに、この複雑な作業は Amplify AI kit がデフォルトで行ってくれます。 具体的には、本プロジェクトでは Amazon Bedrock の Claude 3.5 Haiku を使用します。Amplify を使えば、データベースの 1 つに対応するツールを指定できます。本プロジェクトの場合、製品情報を含む Neon Postgres データベースが該当します。 Neon でサーバーレス Postgres データベースを作成 既存のデータソースに 接続できる ことは、開発者がデフォルトのデータベースである Amazon DynamoDB 以外で、Amplify の Schema 自動生成機能を使って、デフォルトのデータベースである CRUD 操作を自動的に生成できることを意味します。 Neon データベースのセットアップは簡単です。アカウントを作成すると、プロジェクトの作成を求められます。 Neon は Git のようにブランチベースのプロジェクトをサポートしています。これらは main ブランチのコピーです。私の場合、 dev/mtliendo という名前のブランチを作成するオプションがあります。これは推奨されますが、必須ではありません。いずれの場合も、ブランチの接続文字列は、次のセクションで必要になるのでコピーしておく必要があります。 デフォルトのデータベースは設定されましたが、まだテーブルは含まれていません。つまり、テーブルスキーマがまだ定義されていません。SQL を書く方法を知らない方は、がっかりするかもしれません。幸いにも、Neon の「Generate with AI」機能がこの問題を解決します。やりたいことを LLM に伝えると、レスポンスが生成されます。 SQL エディターで、次のように記述します。 Create a table schema called “Products”. Each product has a random id, an “updated at” field that is a date-time, a “created at” field that is a date-time, a “price in cents” field that is a number, a “name”, and a “description”. プロンプトを実行した後、次のレスポンスが表示されました。 CREATE TABLE Products ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, price_in_cents INTEGER NOT NULL, name VARCHAR(255) NOT NULL, description TEXT ); その後、コードを変更してするオプションがあり、構文が問題なければコマンドを実行できます。 設定が期待どおりに行われたことを確認するには、サイドバーの「Tables」リンクをクリックすると、スキーマを確認できるほか、 データを格納 できます。 このプロジェクトでは、データベースにいくつかのアイテムを追加しました。また、次のセクションでデータベース接続文字列をコピーしておく必要があるので、忘れずにコピーしてください。接続文字列はサイドバーの「Overview」セクションにあります。 AI Kit による Amplify Gen 2 の強化 AWS Amplify は、フロントエンドアプリケーションを AWS で動作するバックエンドに接続する最も簡単な方法です。NextJS などの JavaScript フレームワークを使用したアプリがすでに作成されている場合は、プロジェクトのルートで次のコマンドを実行して初期ファイルを生成することができます。 npm create amplify これにより、Amplify の依存関係がインストールされ、 amplify ディレクトリが作成されます。そのディレクトリのコードを変更する前に、Amplify AI kit に必要な他の依存関係をいくつかインストールします。 npm i @aws-amplify/ui-react @aws-amplify/ui-react-ai これらは、このあとすぐに利用する UI コンポーネントです。 まず、Amplify に products テーブルを含むデータベースを検査させ、バックエンドで利用できるようにします。最初のステップは、接続文字列を秘密鍵として保存することです。このシークレットは、 AWS Systems Manager の Parameter Store に保存されます。幸いなことに、Amplify にはシンプルな方法が用意されています。 ターミナルで次のコマンドを実行してください。 npx ampx sandbox secret set SQL_CONNECTION_STRING これにより、 SQL_CONNECTION_STRING という環境変数が設定され、その値の入力を求められます。そこで、Neon からコピーした接続文字列を貼り付けてください。そして、Enter キーを押してください。 この節では、ローカルマシンに AWS Amplify が既に設定済みであることを前提としています。Amplify の設定が必要な場合は、 ドキュメント の手順を参照してください。 シークレットを保存したら、Amplify にデータベースの内部を調べさせて、フロントエンドアプリケーションで利用できる CRUD 操作を作成するよう指示できます。 npx ampx generate schema-from-database --connection-uri-secret SQL_CONNECTION_STRING --out amplify/data/schema.sql.ts このコマンドを実行すると、 amplify/data フォルダに schema.sql.ts ファイルが作成されます。このファイルは Amplify によって管理されているため、修正しないでください。このコマンドを実行した後、ファイルの内容は次のスクリーンショットのようになります。 Amplify はこのファイルを使用して、Postgres データベースを a.model メソッドで機能する形式にマッピングします。 Amplify がこの機能をサポートするために裏で何をしているのかを知りたい場合は、 ドキュメントを確認してください 。 import { type ClientSchema, defineData, a } from '@aws-amplify/backend' import { schema as generatedSqlSchema } from './schema.sql' const sqlSchema = generatedSqlSchema.setAuthorization((models) =&gt; [ models.items.authorization((allow) =&gt; [allow.authenticated().to(['read'])]), ]) const schema = a.schema({ chat: a .conversation({ aiModel: a.ai.model('Claude 3.5 Haiku'), systemPrompt: 'You are a helpful assistant, that focuses on selling and upselling merchandise', tools: [ a.ai.dataTool({ name: 'MerchQuery', description: 'Search for questions regarding merchandise, shopping apparel, and item prices.', model: a.ref('items'), //! This refers to the name of our table modelOperation: 'list', }), ], }) .authorization((allow) =&gt; allow.owner()), }) const combinedSchema = a.combine([sqlSchema, schema]) export type Schema = ClientSchema&lt;typeof combinedSchema&gt; export const data = defineData({ schema: combinedSchema }) Neon データベースをアプリケーションに組み込んだので、 amplify/data/resource.ts ファイルにインポートし、Amplify AI kit のチャットボット/対話エンジン機能と組み合わせることができます。このファイルで何が行われているかを説明します。 4 行目: ここでは、Neon の products テーブルに対する認証ルールを割り当てています。この場合、サインインしたユーザーのみが read 操作を実行できます。 8 行目: chat という識別子を作成しています。これは、最低限 LLM の名前とそのふるまいを指示するプロンプトを受け取る 会話 ボットです。モデル名は型付けされており、インテリセンスで利用可能であることに注意が必要です。 13 行目: ツールを与えることでボットを強化しています。名前と説明は自分で定義できますが、 model は Neon データベースの名前を参照する必要があります。現在サポートされている modelOperation は list のみです。 22 行目: DynamoDB テーブルがサインインしたユーザーの会話履歴を追跡しています。 これらすべての要素を組み合わせることで、データベース内の項目を認識できる大規模言語モデルと安全に対話できる、フルマネージドなソリューションが実現します。 ソリューションをテストするために、次のコマンドを実行して AWS バックエンドをデプロイします。 npx ampx sandbox 一度デプロイすると、Amplify の設定を読み込み、クライアントサイドアプリケーションに適用して、Amplify が提供する設定、UI コンポーネント、フックを利用することができます。 import { generateClient } from 'aws-amplify/api' import { Schema } from '@/amplify/data/resource' import { useEffect } from 'react' import { Amplify } from 'aws-amplify' import awsconfig from '@/amplify_outputs.json' import { withAuthenticator } from '@aws-amplify/ui-react' import { AIConversation, createAIHooks } from '@aws-amplify/ui-react-ai' import '@aws-amplify/ui-react/styles.css' Amplify.configure(awsconfig) const client = generateClient&lt;Schema&gt;() const { useAIConversation } = createAIHooks(client) 一度設定すれば、チャット、会話状況の認識、ストリーミング、ロード状態、認証を備えたフロントエンド全体を、約 20 行のコードで構築できます。 function Home() { const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation('chat') return ( &lt;div className="flex justify-center items-center m-10 max-w-screen-md"&gt; &lt;AIConversation avatars={{ user: { username: 'Focus Otter' } }} messages={messages} handleSendMessage={handleSendMessage} isLoading={isLoading} variant="bubble" welcomeMessage="Hello! I'm your helpful storefront assistant. Feel free to ask me questions about my merch!" /&gt; &lt;/div&gt; ) } export default withAuthenticator(Home) 上記のコードを、この投稿の最初のスクリーンショットと比較してみてください。Amplify AI kit の新しい AIConversation コンポーネントは、多様なプロパティを設定可能にしながら、フルチャット UI を提供します。これにより、特定のニーズに合わせてさらにカスタマイズできます。 まとめ この投稿では、検索拡張生成（RAG）を使ってLLMとの会話をサポートするフルスタックアプリケーションを構築する際の複雑さについて説明しました。そして、AWS Amplify の新しい AI kit が、定型的な部分を抽象化することによって、この経験を大幅に簡素化し、開発者がアプリケーションを真に差別化する部分に集中できるようにする方法を見てきました。これまで見てきたように、セットアップが簡単だからといって拡張性が犠牲になることはありません。Neon から Postgres データベースを作成し、我々のツールと一緒に使うことでそれを証明しました。 Amplify AI kit は、スケーラブルでセキュアなフルスタック・アプリケーションを構築するための新たな一歩です。自身のアプリケーションで Amplify AI kit を使い始めるには、 ドキュメント を参照して、今すぐ始めましょう。 翻訳は Solutions Architect の 吉村 が担当しました。

こんにちは！アマゾンウェブサービスジャパン合同会社で、製造業のお客様を支援しているソリューションアーキテクトの森です。 2025年 1月 29日にオンラインセミナー「AWS re:Invent Recap – インダストリー編 製造業編」を開催致しました。 製造業のお客様のクラウド活用はエンジニアリングチェーン、サプライチェーン、サービスチェーンなど様々な領域で進んできています。昨年から注目されている生成 AI の活用も各領域で進んでおり、re:Invent 2024 でも関連するセッションが多数公開されました。本セミナーでは、製造業でクラウドの活用をご利用・ご検討いただいているお客様を幅広く対象として、 re:Invent 2024 で発表された最新の事例及びサービスを分かりやすくご紹介しています。セミナーの開催報告として、AWS の製造業におけるフォーカス領域である、プロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーンのパートでご紹介した内容や、当日の資料・動画などを公開します。 re:Invent 2024 製造業向けサマリー アマゾンウェブサービスジャパン合同会社 シニア事業開発マネージャー　舛重 国規 [ 資料 ] AWSの製造業領域における取り組みは、プロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーンの各領域において、横断的に生成 AI・機械学習の技術を組み合わせて展開されています。 re:Invent 2024 の Keynote では Amazon CEO Andy Jassy による、Amazon での AI 活用事例、製造業各社による生成 AI 活用の事例が紹介されました。また、AWS 独自の産業データファブリック (IDF) フレームワークを中核とした、製造業向けソリューションの展開や、Expo ホールでの e-Bike スマートファクトリーのデモを通じて、製品品質向上や生産効率化への具体的なアプローチを紹介しました。組み込みソフトウェア開発においては DevOps アプローチの導入など、製造業のデジタル変革を促進する様々な取り組みが紹介されました。 プロダクトエンジニアリングに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 シニアソリューションアーキテクト　吉廣 理 [ 資料 ] このセッションでは、プロダクトエンジニアリング関連の最新動向と事例をご紹介しました。CAD、CAE、PLM の 3つの主要ワークロードにおけるクラウド活用の利点として、リソースの柔軟な調整による無駄のない投資、並列処理による計算時間の短縮、HPC に最適化された EC2 インスタンスの提供などを例にあげています。事例として、Autodesk 社の 3D Generative AI 基盤モデル開発、Iveco グループのバーチャルエンジニアリング、サムスンエレクトロニクスの半導体工場設計、Astera Labs の半導体設計、Realta Fusion の核融合開発など、様々な業界のお客様の取り組みが紹介されていました。また、 AWS Parallel Computing Service (PCS) や Research and Engineering Studio on AWS (RES) などのサービスが紹介され、プロダクトエンジニアリングの効率化と高度化を支援する AWS の取り組みを紹介しました。 スマート製造に関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　岩根 義忠 [ 資料 ] 製造業は労働力不足、技術伝承、カーボンニュートラルの対応、品質向上など、様々な課題に直面しています。このセッションでは、特にこれらの中から、労働力不足と技術伝承の課題に注目し、 AWS IoT SiteWise を中核とした産業データファブリック (IDF) のアプローチを紹介しました。成功事例として Total Energies のバイオガスサイトを 1ヶ月で IoT SiteWise に接続して OT/IT の統合を進めた取り組み、Gousto のデータ駆動型 食品工場の取り組み、Rehrig Pacific Company の製造プロセス最適化、フォルクスワーゲンのデータプラットフォーム構築の事例を紹介しました。これらの事例から データ統合とその活用において、スモールスタートで始めて改善を重ねていく手法の有効性を強調しました。また、 AWS Outposts によるハイブリッドクラウド活用や、IoT SiteWise の新機能である生成 AI アシスタントなど、AWS サービスを活用した具体的なソリューションについてもご紹介しました。 サプライチェーンに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　水野 貴博 [ 資料 ] このセッションでは製造業のサプライチェーンに関する最新動向と事例を紹介しました。サプライチェーン管理において、データの統合とリアルタイムな可視化、AI や機械学習の活用による予測精度の向上、そして管理全体の状況が一目で分かるコントロールタワーの構築が重要なトレンドとなっていることを紹介しました。具体的な事例として、自動車業界における企業間データ連携の Catena-X における BMW と AWS との協業の取り組み、Moderna の医薬品サプライチェーン最適化、北米トヨタのデジタルトランスフォーメーションの取り組みを紹介しました。サプライチェーンに関連する AWS Professional Service のコンサルティングメニューとして倉庫自動化最適化支援 (WAO) を、AWS サービスのアップデートとして AWS Supply Chain の機能拡張（Amazon Q 対応および QuickSight との統合）をご紹介しました。 スマート製品＆サービスに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　村松 謙 [ 資料 ] このセッションではスマート製品サービスに関する最新トレンドと事例をご紹介しました。IoT デバイスの市場規模は急速に拡大しており、2030年までに世界で 55億台に達する見込みで、エッジ AI 市場も 2026年までに 380億ドルの規模に成長すると予測されています。re:Invent 2024 ではブリヂストン、LGエレクトロニクス、KONE、富士通など様々な企業が AWS のサービスを活用して、製品開発、運用保守、顧客サービスの向上等で成果を上げていることを紹介されました。また AWS からは、GitLab への Amazon Q Developer 機能の統合や AWS IoT SiteWise の新機能など、スマート製品&amp;サービス分野に関連するサービスのアップデートについても紹介しました。特に AI やエッジコンピューティングの活用が、製造業のデジタルトランスフォーメーションにおいて重要な役割を果たしていることが強調されていました。 おわりに 本セミナーでは AWS re:Invent 2024 における製造業のプロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーン領域における最新の事例を紹介しました。また、お客様とデジタルトランスフォーメーションを推進する AWS の取り組みやサービスアップデートを紹介しました。データの活用や処理の高度化、自動化などによって、現在の業務をより効率的に行うことができる可能性はあります。中長期的な視点でのロードマップを検討する際、クラウドの効果的な活用が鍵となります。DX やクラウド利用に関してAWSにぜひご相談ください。お客様と共にソリューションを検討し、ご支援をさせていただきます。 本ブログは事業開発マネージャーの舛重国規、ソリューションアーキテクトの吉廣 理、岩根義忠、水野貴博、村松 謙、森 啓が執筆しました。 AWS の製造業に対する取り組みを紹介するウェブサイトもございます。 こちら も是非ご参照ください。

概要 2025 年 3 月 6 日に、AWS 上のデータベース移行に関する新たな視点をご提供する特別セミナー、「AWS で実現するデータベース マイグレーション戦略」を開催いたします。本セミナーでは、AWS Vice President の Jeff Carter が、オンプレミスの Oracle Database からの移行体験を共有し、実際に達成したビジネス価値と運用効率化についてお話しする予定です。 このブログでは、このセミナーの登壇者である Jeff Carter のこれまでのキャリアと、本セッションでご紹介する Amazon.com の移行について少しだけ触れたいと思います。 このセミナーのお申し込みは、 こちら から。 Jeff Carter Jeff Carter は、Amazon Web Services のデータベース製品およびサービスのポートフォリオを担当する Vice President です。このロールには、商用 (Oracle、SQL Server) およびオープンソース (Postgres、MySQL、MariaDB) データベースを提供するリレーショナルデータベースサービス (RDS) のほか、Graph データベースの Neptune、Redis ベースのサービスである ElastiCache と MemoryDB、DocumentDB や Timestream などの purpose-built databases も含まれます。 この役職に就く前の Jeff は、eCommerce Foundation (eCF) team チームの一員として、Amazon.com のビジネスに 5 年間携わっていました。そして Amazon.com での最初の 2 年半の間、「データウェアハウス」を担当するビッグデータテクノロジーチームを率い、コンシューマー組織のデータベースからの移行を進めました。この移行には、「世界最大級」の Oracle データウェアハウスを AWS サービスに置き換えることや、Amazon.com ウェブサイトと倉庫ネットワークを運営していたトランザクション処理システムを Oracle から AWS のテクノロジー (7,500 システム) に移行するプロジェクト「Rolling Stone」が含まれています。Jeff は、このプロジェクトを主導し、プロジェクトを成功に導いた経験を持つデータベース移行のエキスパートです。 Amazon.com の移行プロジェクト Amazon.com は創業以来、エンタープライズ規模のデータ管理に 5,000 以上のOracle Database を活用してきました。しかし、急速な成長に伴い、データベース管理の複雑さ、プロビジョニングの煩雑さ、キャパシティプランニングの困難さなど、多くの課題に直面していました。さらに、ライセンスの費用は、ビジネスの持続可能性の観点からも変革が必要な状況でした。この状況に対して、Jeff の指揮のもと、移行プロジェクトがスタートしました。 プロジェクトでは、AWS の技術コアチームを編成し、各システムに最適な AWS サービスの選定を行いました。例えば、クリティカルなサービスには Amazon DynamoDB 、安定したスキーマが必要なサービスには Amazon Aurora を採用するなど、目的に応じて最適なサービスを選択しました。また、経営層からのスポンサーシップなど技術以外のマネジメント業務もプロジェクトを円滑に進めるための重要な要素でした。 そして、2019 年、Amazon.com は 5,000 以上の Oracle Database の AWS への移行プロジェクトが無事完了しました。この移行によって様々な効果を確認することができています。 移行が完了した時の動画が こちら です。 セミナーのご案内 この度、本プロジェクトを主導した Jeff Carter を招き、特別セミナーを開催いたします。 Jeff が 実際に経験した Oracle Database 移行について、戦略から実践方法について具体的にご説明いたします。 コスト最適化、パフォーマンス向上、運用効率化を実現するデータベースモダナイゼーションなど、第一人者から直接学べる貴重な機会です。ぜひご参加ください。 日時：2025 年 3 月 6 日（木） 14:00 – 17:00 JST （受付開始 13:30) 場所：アマゾン ウェブ サービス ジャパン合同会社 〒141-0021 東京都 品川区上大崎 3-1-1 目黒セントラルスクエア 21F アジェンダ 14:00-14:50 基調講演： データベースモダナイゼーション戦略と成功事例 *逐次通訳あり (Jeff Carter, VP/Amazon Relational Databases) 14:50-15:40 Oracle Database Migration Journey &amp; Oracle Database@AWS Introduction 15:40-16:00 休憩 16:00-16:30 移行ベストプラクティスと顧客事例 16:30-17:00 Meet AWS Expert/AWS Sales このセミナーのお申し込みは こちら スピーカー Jeff Carter は、Amazon Web Services のデータベース製品およびサービスのポートフォリオを担当する Vice President です。 矢木 覚は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。 内山 義夫は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年3月6日(木) 14:00-17:00に「 AWS で実現するデータベースマイグレーション戦略 」というイベントが開催されます。先日発表されたOracle Database@AWSは、今後 Oracle の有力な移行先になる一方で、AWS には他にも様々なデータベースサービスを提供しており、AWS 上の Oracle データベース移行に関する新たな視点をご提供する特別セミナーです。そして基調講演では、AWS Vice President の Jeff Carter が、オンプレミス Oracle データベースから Amazon DynamoDB への移行した際のビジネス価値と運用効率化体験の講話も予定しており、Oracle データベースを AWS 上に移行することを検討されている方は、気づきを得られる絶好の機会と思います。ぜひご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年2月10日週の主要なアップデート 2/10(月) Amazon Redshift Serverless announces reduction in IP Address Requirements to 3 per Subnet Amazon Redshift Serverless でサブネットごとに必要な IP アドレス数が3つに削減されました。Amazon Redshift Serverless ワークグループ(ワークグループ)を作成する際や、Redshift Processing Units(RPU) のワークグループを更新する際、サブネットに少なくとも9つの空き IP アドレスが必要でした。今回の対応により Enhanced VPC Routing(EVR) を有効にせずにAmazon Redshift Serverless を使用する場合は、Amazon VPC の各サブネットで空き IP アドレスが3つあれば良くなり、Amazon VPC サブネットネットワークの空き IP アドレスを心配する必要がなくなります。 Amazon CloudWatch now provides lock contention diagnostics for Aurora PostgreSQL Amazon CloudWatch Database Insights で、Aurora PostgreSQL 向けにロック競合を分析する機能を提供するようになりました。この機能により、Database Insights コンソールでロック状況を可視化でき、ブロッキングセッションと待機セッションの関係が表示され、ロック競合の原因となっているセッション、クエリ、オブジェクトを素早く特定できます。ロック競合診断機能は、CloudWatch Database Insights の Advanced モードでのみ利用可能です。 Amazon EFS now supports up to 10,000 access points per EFS file system Amazon Elastic File System (Amazon EFS) は、ファイルシステムごとのアクセスポイントの制限を 1,000 から 10倍の 10,000 に引き上げました。このリリースにより、共有データセットへのアクセスを管理するのがさらに簡単になり、単一の EFS ファイルシステムで数千人のユーザーへのアクセス管理をシームレスにスケーリングできるようになります。新しい EFS アクセスポイントの制限は、すべてのファイルシステムに自動的に適用されます。 2/11(火) Amazon DynamoDB now supports auto-approval of quota adjustments Amazon DynamoDB のアカウントレベルとテーブルレベルのスループットクォータの調整リクエストに対して、 AWS Service Quotas &nbsp;を通して数分以内に自動承認を受けることができるようになりました。今までは、調整リクエストを行う際、Service Quotas では調整対象の Amazon DynamoDB の割り当てと目的の値を指定した上で、AWS サポートがリクエストを確認し、承認して調整を行っていました。今回のリリースによって、数クリックで、自動的に承認され、調整を行うようになり、調整が完了するまでの時間削減へつながります。 AWS Secrets and Configuration Provider now integrates with Pod Identity for Amazon EKS AWS Secrets and Configuration Provider (ASCP) が Amazon Elastic Kubernetes Service (Amazon EKS) Pod Identity と統合されました。ASCP は業界標準のKubernetes Secrets Store CSI Driver のプラグインで、Kubernetes ポッド内で実行されるアプリケーションが AWS Secrets Manager からシークレットを簡単に取得できるようにします。これまで ASCP は IAM Roles for Service Accounts (IRSA) を認証に使用していましたが、新しい任意のパラメータ「usePodIdentity」を使えば、IAM 認証に IRSA または Pod Identity を選択できます。今回統合により、ASCP と EKS Pod Identity の両コンポーネントの長所が組み合わされ、Amazon EKS 環境におけるシークレット管理が効率的かつ安全に行えるようになります。 2/12(水) Amazon Elastic Block Store (EBS) now adds full snapshot size information in Console and API Amazon Elastic Block Store (Amazon EBS) で、EBS スナップショットのフルスナップショットサイズが表示されるようになりました。EBS スナップショットはインクリメンタル方式で、ボリュームの複数のスナップショットを時間の経過とともに取得した場合、各スナップショットには新しく追加されたブロック、もしくは変更されたブロックのみが格納され、変更されていないブロックは以前のスナップショットからの参照されます。そのスナップショットに直接格納されているブロックと、以前のスナップショットから参照されているすべてのブロックを合わせた、スナップショットを構成するすべてのブロックの合計サイズが表示されます。これは、新しく変更されたブロックのサイズのみを指す、「インクリメンタルスナップショットサイズ」とは異なることにご注意ください。 AWS AppSync enhances resolver testing with comprehensive context object mocking AWS AppSync でリゾルバーおよび関数のユニットテスト中に、ID 情報、スタッシュ変数、エラー処理を含むコンテキストオブジェクトのすべてのプロパティを包括的にモックできるようになりました。開発者は、テスト環境でリゾルバースタッシュ (ctx.stash) とエラートラッキング (ctx.outErrors) にアクセスして検証することにより、効率的に関数とリゾルバーをテストでき、さらに ctx.identity に関連する呼び出し側の情報のみを含めることで、ID のモッキングが簡単になりました。これにより、リゾルバーのテスト結果の可視性が向上し、開発者がリゾルバーの実装をより効果的にトラブルシューティングして最適化できるようになります。 2/13(木) Amazon EC2 M7g instances are now available in additional regions Amazon Elastic Compute Cloud (Amazon EC2) M7g インスタンスが大阪リージョンで利用可能となりました。高いコンピューティング性能を提供する AWS Graviton3 プロセッサを搭載しており、従来のEC2インスタンスと比較して最大 60% のエネルギー消費量を削減し、最大 30Gbps のネットワーキング帯域幅と、Amazon Elastic Block Store (EBS) への最大 20Gbps の帯域幅を提供します。 Amazon RDS for PostgreSQL supports minor versions 17.3, 16.7, 15.11, 14.16, 13.19 Amazon Relational Database Service (RDS) for PostgreSQL で、最新のマイナーバージョンの 17.3、16.7、15.11、14.16、および 13.19 をサポートしました。pg_active 2.1.4、pg_cron 1.6.5、pg_partman 5.2.4などの PostgreSQL エクステンションの更新も含まれています。 AWS Network Load Balancer now supports removing availability zones ネットワークロードバランサー(NLB) でアベイラビリティーゾーン (AZ) を削除する機能がリリースされました。この機能のリリース前は、既存の NLB に AZ を追加することはできましたが、AZ を削除することはできませんでした。この機能を使用することで、ELB API、CLI、またはコンソールを使用して有効なサブネットのリストを更新することで、NLB から AZ を削除できます。AZ を削除すると、 NLB のゾーナル Elastic Network Interface(ENI) が削除され、潜在的に中断を引き起こす可能性があります。この機能を安全に使用する方法については、 ドキュメント と AWSブログ を参照してください。 2/14(金) AWS CloudTrail network activity events for VPC endpoints are now generally available AWS CloudTrail で VPC エンドポイントのネットワーク アクティビティに対するサポートが開始されました。VPC エンドポイントのネットワーク アクティビティ イベントにより、ネットワーク内のリソースにアクセスしている対象の詳細を確認できるため、データ境界内での悪意のある行為や不正なアクションを特定し対応する能力が向上します。Amazon S3、Amazon EC2、AWS Key Management Service (AWS KMS)、AWS Secrets Manager、AWS CloudTrail の 5 つの AWS サービスについて、VPC エンドポイントのネットワーク アクティビティ イベントを有効にすることが可能です。 AWS Lambda adds application performance monitoring (APM) for Java and .NET runtimes via Application Signals AWS Lambda が Java と .NET のマネージドランタイムで Amazon CloudWatch Application Signals をサポートするようになりました。Amazon CloudWatch Application Signals はアプリケーションパフォーマンスモニタリング(APM)ソリューションで、Lambda を使用して構築したサーバーレスアプリケーションの健全性とパフォーマンスを簡単に監視できます。今までは、Python と Node.js のマネージドランタイムの Lambda 関数でApplication Signals のサポートをしていましたが、今回のリリースにより、Java 11、Java 17、Java 21、および .NET 8 Lambda のマネージドランタイムを使用した Lambda 関数で Application Signals を有効にできるようになりました。 ところで、AWS の BI サービスである Amazon QuickSight に生成 AI アシスタントである Amazon Q の機能が追加され、自然言語で質問や分析ができるのはご存じでしょうか？その生成 AI の機能を簡単に試していただけるデモサイトが こちら にあります。Amaon Q in QuickSight は正式な日本語サポートはまだですが、すでにかなり日本語を解釈するようになっています。デモサイトには日本語のサンプル質問文もありますので、ぜひ試してみてください! それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

2025 年 2 月 17 日更新：日本語フルサポートではないので正式にアナウンスはされていませんが、日本語でプロンプトできるようになっています。 DemoCentral も、全て日本語のサンプル質問に置き換えました！日本語の解釈において不備がある場合は、ぜひ QuickSight Community にお知らせいただけると、今後の改善リストに追加され対応されます。 Amazon QuickSight は AWS が提供するクラウドネイティブの統合型 Business Intelligence(BI) サービスです。サーバーレスのため、運用管理の負担が少ないだけでなく、ビジネスユーザーがデータから多くのインサイトを得られる機能を提供しています。Amazon QuickSight は継続的に機能強化を続けており、2024年4月には、生成 BI 機能である Amazon Q in QuickSight が一般提供が開始されました。Amazon Q in QuickSight により、ビジネスアナリストやビジネスユーザーは自然言語を使用して簡単にビジュアルを作成したり、データから洞察を得ることができます。 このたび、小売向けの生成 BI 機能を利用できるサンプルダッシュボードを DemoCentral 上の こちら で公開しました。本記事ではサンプルダッシュボードの使い方を解説します。 BI ダッシュボードにおける生成 BI 機能のニーズ AWS では、小売り業界で頻繁に使われる可視化パターンを盛り込んだ Amazon QuickSight のダッシュボードとして、以前よりDemoCentral の こちら で公開しています。経営層、商品企画者、店長、マーケターなどの活用シーンで、売上が目標に達しているかを、時系列、商品、販売チャネルといった観点で分析してインサイトを得ることができ、 こちら の記事で解説しています。 実際にダッシュボードが利用される状況を考えてみると、ダッシュボードにはない分析をしたい場合があります（ダッシュボードからの気付きにより新たな仮説や疑問が生じるので、悪いことではありません）。ダッシュボードを作成するビジネスアナリストではなく、参照がメインの経営層や店長などのビジネスユーザーにとっては、都度ビジネスアナリストにダッシュボードの作成を依頼せずにすぐに知りたいというニーズは大いにあり得ます。また、ふわっとした仮説や疑問に対してダッシュボードを作成することも現実的ではありません。 整理すると、以下のニーズとなります。 ダッシュボードにない分析をしたい ダッシュボード開発に時間をかけたくない ダッシュボード操作（フィルターなど）の教育に時間をかけたくない（または、操作を覚えるのが面倒） このような、完成度の高いダッシュボードをはじめから用意せずにスモールスタートでデータ活用を始めたい、というニーズに対して、Amazon Q in QuickSight の生成 BI を使用したマルチビジュアル質疑応答エクスペリエンスが有効です。ダッシュボードで表現されていないデータに対して自然言語で質問をすると、ビジュアルと文章による回答が返されます。 サンプルダッシュボードの概要 サンプルダッシュボード は 4つのタブから構成されており、メインとなるのが一番左の 売上分析 タブです。 図1 : 売上分析 タブ こちらは、売上全体の状況を商品カテゴリと販売チャネルの観点から分析することを狙いとして、表1 に示す 3 つのパートに分かれています。 パート 説明 関心のあるユーザー（例） 全体 達成率、上位の店舗や部門、年間遷移を把握するための可視化 経営層 部門、店舗：概要 部門→商品や、地域→店舗、についての売上を分析するための可視化 店長、商品企画者 部門、店舗：明細 部門（商品）や店舗についての明細を分析するためのピボットテーブル 同上 表1 : 売上分析 タブの構成説明 前述した以前からあるダッシュボードと比較するとシンプルな作りになっていますが、スモールスタートでデータ活用を始めているという想定です。例えば、レビューデータはあるものの、マーケターから分析のニーズが出てきていないためビジュアル化されていません（一旦どういったデータがあるかだけ レビューデータ タブに表示しています）。 Amazon Q in QuickSight によるダッシュボードにはない分析の実施 サンプルダッシュボードには、Amazon Q in QuickSight の質疑応答機能が実装されています（※1）。DemoCentral では、埋め込みのエクスペリエンスとして実装されており、ページ上部に質問バーを表示する形式と、全画面でフル表示する 2 つのオプションがあります。 質疑応答の利用については、 Qサンプル質問①② タブにて、質問していただけるサンプル質問を用意しています（※2）。ダッシュボードにある店舗と商品に対しての掘り下げや比較といった詳細分析に加えて、レビューの分析を、自然言語で問い合わせて洞察を得ることができます。 以下は、店舗同士の売上達成率を比較したい場合の問い合わせと回答です。売上達成率の全体、各店舗、月毎の遷移が右側でビジュアル化されているのと、左側でそれらを要約した文章が生成されています。 図2 : Amazon Q in QuickSight の質疑応答機能の例 – 店舗同士の売上達成率を比較 期待するビジュアルが得られない場合は、より直感的なビジュアル形式を選択することもできます。以下の例は、商品部門名別売上高を 2019 年の 1 月と 2 月で比較した問い合わせと回答です。増減を直感的に把握するため、表形式から水平棒グラフに変更しています。 図3 : Amazon Q in QuickSight の質疑応答機能の例 – 商品部門名別売上高の比較 ビジュアルの表示形式だけでなく、 推奨インサイト を確認することもできます。サンプル質問を参考に、色々と試してみてください。 （※1）機能の詳細については、 こちらのブログ にて紹介されています。 （※2）生成 BI 機能は 2025 年 2月時点でまだ日本語を正式サポートしていませんが、できるだけ正確な回答を受け取ることができるようになっています。 実際の問い合わせやフィードバックに基づくダッシュボードの充実化 Amazon Q in QuickSight の質疑応答機能を利用するには、トピックというデータセットのコレクション定義を設定する必要があります。トピックには、ユーザーが実際にした質問や、フィードバックの状況を参照することができます。回答の精度を高めるためにレビューして、設定をアップデートして精度を高めることができます。 質疑応答機能を充実化する以外にも、頻繁に問い合わせされているものについてはダッシュボードに追加することもできます。問い合わせをしなくても欲しい情報を素早く入手できるようになるので、新たな仮説や疑問が生じて、Amazon Q in QuickSight で問い合わせる、というデータ分析のサイクルができるかもしれません。 図 4 : トピックの管理者は Suggested Questions タブより多く問い合わせられている質問を確認できる 今回紹介しているサンプルダッシュボードは、スモールスタートでデータを活用を始めているという想定で以前よりあるサンプルダッシュボードと比較するとシンプルな作りであることを説明しました。例えば以下のような問い合わせから、以前よりあるサンプルダッシュボードのシート作成のきっかけとすることで、シンプルなダッシュボードをビジネスユーザーの実際のニーズに合わせて充実化することができます。 店舗同士の比較に関する問い合わせ → 自店vs類似店 シート作成へ 返品に関する問い合わせ → 返品調査 シート作成へ レビューに関する問い合わせ → 商品レビュー シート作成へ まとめ 本記事では、BI ダッシュボードにおける生成 BI 機能のニーズと、先日公開された小売向けの生成 BI 機能を利用できる Amazon QuickSight によるサンプルダッシュボードの紹介と問い合わせ例、そしてダッシュボードの充実化方法について紹介しました。 本記事では紹介しませんでしたが、Amazon Q in QuickSight は、自然言語でダッシュボードを作成やビジュアルの変更、関数などの計算フィールドの作成機能も提供しています。ビジネスユーザーだけでなく、ビジネスアナリストも含めたデータ分析をAmazon QuickSight は包括的に支援しています。 図 5 : Amazon Q in QuickSight によるデータ分析の促進イメージ 是非、サンプルダッシュボードを触れていただき、生成 BI によるデータ分析の可能性について体験してみてください！ 更新履歴 2024/12/17　新規作成 2025/2/17　DemoCentral の日本語サンプルに置き換えに合わせてアップデート — 本ブログは、ソリューションアーキテクトの平井が作成しました。

このブログは 2024 年 11 月 9 日に Ganesh Shenoy によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 イントロダクション 水の不足は、広範囲に及ぶ影響を伴う緊急のグローバルな課題です。人口の増加、気候変動の影響、そして都市化の進行により、多くの地域で淡水資源への需要が供給を上回り続けています。効率的な水管理は、長期的な持続可能性とレジリエンスにとって極めて重要です。 水効率の重要性 水は、エネルギー生産、農業から製造業、家庭での利用に至るまで、現代社会の事実上あらゆる側面を支える重要な資源です。しかし、水の使用効率が悪いと、次のような重大な経済的および環境的コストにつながる可能性があります。 水供給の逼迫と水不足のリスク 水を大量に消費する産業の運営費の増加 水の処理と配水のためのエネルギー消費量の増加 生態系の劣化と生物多様性の損失 干ばつと気候変動の影響の深刻化 水の使用量を最適化し、効率化対策を実施することで、組織は水の使用量を削減し、コストを削減し、環境管理に貢献できます。 水を大量に使用するインダストリーにフォーカスする 特定のインダストリー、例えば発電、石油・ガス抽出、公益事業の運営などは、特に水を大量に使用します。例えば、熱電発電所は冷却システムに膨大な量の水を必要とします。2020 年の米国では、電力セクターは 47.5 兆ガロン の水を使用しました。同様に、石油・ガス産業の採掘で岩盤を破砕する手法でも、大量の水が必要です。米国で最も生産性の高い油田の 1 つである パーミアン盆地 は、この傾向を示しています。そこでのフラッキング用の水使用量は、2011 年の 1 つの井戸あたり約 120 万ガロンから 2016 年には1井戸あたり約 1,100 万ガロンに増加しました。これらのセクターで水使用効率を改善することで、大きな経済的および環境的利益を得ることができます。 水使用効率に関する AWS ガイダンスの紹介 組織の水使用効率化の取り組みを支援するため、Amazon Web Services (AWS) は、クラウドベースのテクノロジーを使用して水使用量データを収集、監視、最適化するための包括的なガイダンスを作成しました。このガイダンスは以下の詳細なフレームワークを提供します。 インダストリー活動や水道事業において、IoT デバイスやゲートウェイを使用して水使用量のテレメトリデータを収集します。 AWS IoT SiteWise または AWS IoT Core を使用してデータを取り込み、 Amazon Timestream や Amazon S3 などのホットおよびコールドデータストアに生のテレメトリデータを保存します。 AWS Lambda や AWS Glue などのサーバーレスサービスを使用してデータを処理および変換します。 可視化とレポート用に最適化されたデータストアに処理済みデータを保存します。 水の使用量と効率を監視するためのリアルタイムダッシュボードとカスタムアプリケーションを構築します。 予測や異常検出などの高度な分析を可能にし、水の消費を最適化し、潜在的な問題を特定します。 積極的な水管理のための通知とアラートを設定します。 AWS のデータ管理、分析、および機械学習 (ML) 機能の力を活用することで、水を多用するインダストリーは以下のような利点を引き出すことができます。 運用コストの削減 : 水の使用を最適化することで、企業は水の調達、処理、廃棄に関連する費用を最小限に抑え、大幅なコスト削減につながります。 環境の持続可能性の向上 : 効率的な水管理は、業界の水のフットプリントを削減し、より持続可能な未来に貢献し、水不足のリスクを軽減します。 規制遵守の改善 : 環境規制の増加に伴い、このガイダンスは企業が水管理基準を遵守し、規制当局に透明性を提供することを支援します。 データドリブン型意思決定の利用 : このガイダンスは、企業が予測や予測モデリングなどの高度な分析の力を活用し、水の使用と最適化に関する情報に基づいたデータドリブン型の決定を下せるようにします。 AWS の水使用効率ガイダンスは、発電、石油・ガス抽出、公益事業運営などの水を多用する産業が持続可能な水管理の実践を実施するためのロードマップを提供しています。 まとめ 効率的な水の使用は、長期的な持続可能性、コスト削減、環境管理にとって極めて重要です。AWS の水使用効率ガイダンスは、組織がクラウドコンピューティングとデータドリブン型の技術の力を活用して、水管理の実践を最適化するのに役立ちます。 次のリンクにアクセスして、 AWS Guidance for Water Use Efficiency をご覧ください。 参考情報 AWS Water Stewardship Commitment Sustainability at Amazon 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: analytics , AWS for Industrial , machine learning Ganesh Shenoy Ganesh Shenoy は、スウェーデンのストックホルムに拠点を置く AWS のソリューションアーキテクトで、中小企業をサポートしています。彼は、持続可能なクラウドの実践を推進しながら、データドリブンの意思決定を可能にするクラウドソリューションの設計を専門としています。 北欧のお客様と提携して、ビジネスの成長と環境責任を推進するソリューションを構築します。

本稿は、塩野義製薬株式会社による、従来型の解析環境の問題を根本解決する “オンデマンド計算環境” の開発について、当該の内製開発をリードされた、データサイエンス部 髙市 伸宏 様より寄稿いただきました。 1. イントロダクション 塩野義製薬は、1878年に創業して以来、“常に人々の健康を守るために、必要な最もよい薬を提供する” ことを掲げて活動を続けています。近年ではSHIONOGI Group Vision (2030年Vision) として、“新たなプラットフォームでヘルスケアの未来を創り出す” ことを目指して、革新的なヘルスケア製品・サービスをグローバルに創出し、社会課題に挑戦する試みを進めています。 その中でデータサイエンス部は、高度データ活用技術を通じたソリューション創出や業務プロセスの変革を推進する立場にあり、その目的のために、各種の計算基盤を保有し、稼働させてきました。また、その基盤環境は一定の統制のもとで全社に開放し、全社での活用をしてまいりました。 本ブログでは、その計算基盤環境を、クラウドネイティブで革新的な環境へと作り替えた取り組みをご紹介します。 2. 背景 Python言語やR言語といったオープンソース言語による統計解析や機械学習といったデータ解析は、今や多くの企業のデータサイエンス活動として見られるようになりました。その環境は、一般的には比較的大きな計算資源を持つ計算機を解析環境として設け、多くのユーザーで共用することによって、望むデータ解析の実現と、ガバナンスと、コスト効率が図られます。 しかし、この方式には以下のようなリスクがあります。 共用している計算機の障害発生により、多くのユーザーの解析が停止する ユーザー同士の操作が、同一計算機上で互いに干渉する 多数のユーザーの操作により、GPU等の計算資源の奪い合いが発生する 多様化するタスク、データモダリティに対して、柔軟に対応できない 上記の事象はすべて、発生すればするほど、本来果たすべきデータサイエンス活動の速度を、時には極端に落としてしまうことになります。よって、前述のリスクを根本のレベルから回避していくことが会社としては必要であり、課題でした。 この課題の根本にあるギャップ (理想像とのギャップ) は、要約すれば、解析環境の “スケール性”、“独立性”、“柔軟性” でした。一方でAWSクラウドには、使い方次第で、これらに対応できる各種のサービスが設けられていました。よって、従来の解析環境を単純に移行する (“リフト” する) のではなく、AWSクラウドに “シフト” することで、その利点を的確に引き出せば、根本的な解決が図れるものと捉えました。 図1 従来型環境のリスクと、解決方針 3. 開発の方針 まず設計の思想として、解析環境の共有という方針からの脱却を図りました。すなわち、解析環境はユーザー個人単位に分割して、ユーザー個人が、必要な時に、必要なだけの計算資源を持つ解析環境を、セルフサービスで (“オンデマンド” で) 得られるようにする、という方針を取りました。さらに、その解析環境は、多種多様なタスクに対応できるよう、複数種類をあらかじめ用意しておく方針を取りました。 このような方針を取ることで、計算機の共用により発生していた課題 (障害等による検討のストップ、ユーザー操作同士の干渉、計算資源の枯渇、自由度の不足) の、根本的な解決を図ることとしました。 そしてこのセルフサービスによる払い出しは、 AWS Service Catalog を核として構成することで非常にシンプルな実現が図れるため、それを採用することとしました。 AWS Service Catalogは、組織が承認したクラウドリソースやアプリケーションをあらかじめカタログ化しておき、ユーザーが安全かつ簡単に利用できるようにするサービスです。今回は、解析環境のテンプレートを Service Catalog 上に複数種類用意しておき、ユーザーが必要なときに必要なだけ払い出せるようにしました。そしてこのように、AWS Service Catalogを核として構成する一連の仕組みを、我々は独自に、“AWSオンデマンド環境” と呼称することとしました。 図2 開発方針 4. ソリューションの概要 この “AWSオンデマンド環境” では、以下の事項が実現しました。 ユーザーは、事前申請により得た権限範囲で、数種類の個人用解析環境を、自由に払い出すことができる ユーザーは、CPU性能、GPU性能、ディスク容量などの性能を、自身のタスクに応じて、自ら指定できる ユーザーは、セキュリティグループのようなインフラ知識を全く意識することなく、極めて簡単に払い出すことができる 自身が払い出した個人用解析環境は、ユーザーが自らの意思で削除することができる ユーザーの権限は、 AWS IAM Identity Center に基づく権限セット (許可セット) によって円滑な付与を実現しました。AWS Service Catalogによって払い出す個人用解析環境の定義は、あらかじめ S3 (Amazon Simple Storage Service) のバケットに配置した AWS CloudFormation テンプレートからのデプロイにより実現します。そのデプロイのアクションは、デプロイに使用するIAMロールを指定する機能である、AWS Service Catalogの起動制約 (Launch Constraints) を利用することで、ユーザーの権限を不必要に大きくすることに由来する事故を防ぎ、安心して、解析環境のデプロイ・削除が可能な仕組みを実現しています。 図3 AWS アーキテクチャ図 さらに、個人環境払い出しに使用するCloudFormationテンプレートには、バリデーションチェック付きの入力欄 (パラメタ) を設けておくことで、必ず一定の基本タグが与えられるようにしました。 一方で、払い出しの事前には値が決まらず、払い出しの瞬間にルールベースで値が決定するタグについては、まずそのルールを Amazon EventBridge ルールとして実装し、タグの付与は AWS Lambda の関数として実装しました。AWS Service Catalog由来の払い出し実行のイベントを引き金に、Amazon EventBridge ルール経由で、当該の Lambda 関数が起動するようにすることで、追加のタグが必ず付与されるようにしました。 これらの方法の組み合わせにより、払い出しの背景情報を持つ一定のタグが一貫して入るようにすることで、多数の社内ユーザーによる利用実績データを、乱れなく蓄積することも実現しました。 図4 タグ付け戦略図 5. 各種の成果 この “AWSオンデマンド環境” の実現により、従来法が抱えていた課題を根本的に解決したことに加えて、金銭的コスト、時間的コストのいずれも、従来法に比較して改善しました。特に時間的コストは、個人用解析環境を得るまでの時間がそれまでの1万分の1となり、飛躍的に向上しました。 さらに今回の仕組みは、解析環境を個人の単位に分割したものであるため、大きな試行錯誤を行ったとしても他ユーザーへの影響が原理的に発生せず、しかも個人解析環境は、従来法では到底考えられなかった、個人解析環境の破棄が可能になりました。これは、これまでは取り入れることができなかった “スクラップ＆ビルド” の考えを、データサイエンスに取り入れることを可能にしました。 図5-1 各種成果の図 図5-2 各種成果の図 また、確立したこの “AWSオンデマンド環境” からは、複数の機械学習モデルや、それを組み込んだアプリケーションが生まれ、社内デプロイまで到達するものも生まれました。 さらに当環境は、データサイエンス部だけでなく社内の他部門からの利用も受け付けており、現在では合計8部門の50名超のユーザーまで拡大して、各種の活用が見られています。 利用部門からは、“混雑に関係なく、いつでも、任意の性能の解析環境が得られる”, “個人専用の環境であり、他ユーザーへの影響が発生しないので、思い切った検討ができる”, “必要が無くなった際だけでなく、環境を壊してしまった際に、リスク無く捨てられる点が大きい。安心してチャレンジできる” といった、多数の声が得られています。 この “AWSオンデマンド環境” からは、これまでに累計500回を超える解析環境の払い出しがなされており、今もなお多数の仮説・検証サイクルの高速な実行を実現しています。 6. まとめと今後の展望 AWS Service Catalogを中心技術に、計算基盤環境を、クラウドネイティブで革新的な環境へと作り替えた取り組みを、具体的なエピソードを交えてご紹介させていただきました。 今後もこの環境は、MLOpsなどを志向した拡張機能の付与にも挑みつつ、それらの活動を通じ、AWSクラウドの力の最大限に活用して、より一層の成果の創出に取り組んでまいります。 執筆者 髙市 伸宏 塩野義製薬株式会社 DX推進本部 データサイエンス部 データエンジニアリングユニット コンピュータサイエンスグループ 2011年に大学院卒業後、塩野義製薬に入社。CMC研究本部で原薬製造法の研究開発 (プロセス化学研究) に従事。2019年よりデータマネジメント管轄部門に異動し、2021年よりデータサイエンス部に所属。主な担当業務はデータマネジメントや解析システム構築・運営にかかる企画立案と推進、新規技術導入検討など。クラウドコンピューティングを得意とする。

本記事は 2025 年 2 月 7 日に公開された “ Learning AWS best practices from Amazon Q in the Console ” を翻訳したものです。 AWS を活用するオペレーター、管理者、開発者、その他多くのユーザーは、 AWS コンソールを利用する際に、権限の不足や AWS Lambda のコードのバグなど、さまざまな課題や一般的な問題に直面します。AWSは、コンソールを利用するユーザーが直面するこれらの課題を軽減するために、 Amazon Q をリリースしました。 Amazon Q は、コードの作成、質問への回答、コンテンツの生成、問題の解決、 AWS リソースの管理、およびアクションの実行を支援する、AWS の生成 AI を活用したアシスタントです。 Amazon Q の一機能として Amazon Q Developer があります。AWS マネジメントコンソール、AWS コンソールモバイルアプリケーション、AWS のウェブサイト、AWS のドキュメントサイト、および AWS Chatbot と統合されたチャットチャネルで、Amazon Q Developer と対話しながら AWS サービスについて学べます。Amazon Q Developer に AWS タスクのベストプラクティス、推奨事項、ステップバイステップの手順、および AWS リソースやワークフローの設計について質問できます。 このブログ記事では、Amazon Q Developer を活用して、コンソール上でコードスニペットを生成したり、ワークロードを設計したり、コストを分析したりする方法など、さまざまなトピックをインタラクティブに解決するためのベストプラクティスを紹介します。 前提条件 これらの例を実際に試すには、以下の前提条件が必要です。 AWS アカウントを保持していること AWS コンソールへのアクセス権限があること&nbsp; Amazon Q へのアクセス権限があること 概要 以下は、コンソールでの Amazon Q Developer の活用方法の例です: 特定の AWS サービスについて学び、それらのサービスを効果的に活用するためのベストプラクティスを探る AWS Software Development Kit (SDK) または AWS Command Line Interface (CLI) を使用してタスクを自動化するコードスニペットやスクリプトを生成する ワークロードを設計し、最適化する コストを理解する 注意 – コンソールの Amazon Q は、その非決定的な性質により、以下の例で示されているものとは異なる出力を生成する場合があります。 開始するには、 AWS コンソールにサインイン し、図 1 に示すように右側のパネルの Amazon Q アイコンをクリックして Amazon Q Developer サービスにアクセスします。必要に応じて認証を行います: 図 1: Amazon Q Chat にアクセスする AWS サービスとベストプラクティスを Q を使って学ぶ このセクションでは、Amazon Q を活用して AWS サービスについて学ぶ方法と、AWS のサービスを適切に利用するためのベストプラクティスの概要を紹介します。 AWS サービスを学ぶ 初学者でも経験豊富なユーザーでも、Amazon Q を使えば AWS の機能を発見し、必要なときにいつでも役立つ情報を得ることができます。 たとえば、メトリクスに基づいてコンピュートインスタンスを自動的にスケーリングする方法を学びたい場合、コンソールで Amazon Q に質問できます。 サンプルプロンプト: I need to set a autoscaling group for EC2 instances with this requirement, if CPU utilization goes above 50% for 5 minutes then it should add new instance and if CPU utilization drops below 50% for 5 minutes then it should delete 1 instance. （日本語訳: 以下の要件で EC2 インスタンスのオートスケーリンググループを設定する必要があります。 CPU 使用率が 5 分間 50% を超えた場合は新しいインスタンスを追加する。 CPU 使用率が 5 分間 50% を下回った場合は1つのインスタンスを削除する。） 図 2: 特定のメトリクスとしきい値に基づくコンピュートインスタンスの自動スケーリングに関する、ユーザーのプロンプトと Amazon Q からの応答 Amazon Q は、プロンプトで提供された要件に基き、 Auto Scaling グループ を設定するためのすべてのステップを提示します。 AWS サービスについて具体的な質問をする コンソールの Amazon Q は、ベストプラクティスを考慮しながら、ビジネス価値を提供するシステムを運用する際にも役立ちます。自然言語のプロンプトを使用して、 AWS サービスを使うときのベストプラクティスを学べます。 サンプルプロンプト: I am using API Gateway for REST APIs. I have configured timeout for requests. I would like to learn additional best practices to reduce and handle long running requests. （日本語訳: REST API に API Gateway を使用しています。リクエストのタイムアウトを設定しましたが、長時間実行されるリクエストを減らし、適切に処理するための追加のベストプラクティスを学びたいです。） 図 3: コンピュートコストの削減に関する、ユーザーのプロンプトと Amazon Q からの応答 図 3 に示すように、 Amazon Q は Amazon API Gateway での長時間実行リクエストを最適化するさまざまな方法を要約します。例えば、タイムアウトの実装、可能であれば長時間実行の操作を非同期呼び出しにすることや、その他いくつかの最適化の方法を提示します。 AWS SDK または AWS CLI を使用してタスクを自動化するコードスニペットやスクリプトの生成に Q を活用する 開発者やシステム管理者は、ドキュメントを調べる時間をかける代わりに、Q を使用してタスクを自動化するコードスニペットやスクリプトを生成できます。 S3 からデータを読み取る AWS Lambda 関数の作成方法 例えば、開発者が Amazon S3 バケットからデータを読み取る AWS Lambda 関数を作成したいが、どのように始めればよいかわからない場合、 Amazon Q が支援します。 図 4: Lambda 関数の作成手順に関するユーザーのプロンプトと Amazon Q の応答 図 5: Lambda 関数の作成に関するサンプルコードを含む Amazon Q の応答 図 4 および 5 に示すように、 Amazon Q は Lambda 関数の作成方法について、参考用のサンプルコードを含むステップバイステップの手順を返します。 AWS CLI を使用して S3 バケットにファイルをアップロードする方法 開発者や IT プロフェッショナルが AWS CLI を頻繁に使用しているものの、タスクを実行するための適切なコマンドを見つけるのに苦労している場合、 Amazon Q は非常に役立ちます。 サンプルプロンプト: How do I upload a file to an S3 bucket using the AWS CLI? （日本語訳: AWS CLI を使用して S3 バケットにファイルをアップロードするにはどうすればよいですか？） 図 6: S3 バケットへのファイルアップロード用の CLI コマンドに関する、ユーザーのプロンプトと Q からの応答 図 6 に示すように、 Amazon Q は S3 バケットにファイルをアップロードするための CLI コマンドを返します。さらに、アップロードされたことを確認するためのコマンドも提案しています。 他のサービスの使用を自動化するコードを記述するために Console-to-Code を活用する Console-to-Code はコンソールでの操作を記録し、生成 AI を使用して好みの言語でコードを提案します。現在、 CLI コマンド、 CDK Java 、 CDK Python 、 CDK TypeScript 、 CloudFormation JSON/YAML をサポートしています。 例えば、開発者が Amazon EC2 インスタンスと Amazon RDS データベースインスタンスを含む CloudFormation YAML を生成したい場合、開発者は Amazon EC2 と Amazon RDS のコンソールに移動し、右側で Console-to-Code アイコンを選択し、「 記録を開始 」を選択します。 以下の図に示すように、 Amazon EC2 インスタンスと Amazon RDS DB インスタンスを起動したら、記録を停止し、 CloudFormation YAML テンプレートをそのままダウンロードします。 図 7: Amazon EC2 と Amazon RDS データベースインスタンスの起動を記録する Console-to-Code 図 8: Console-to-Code の記録から Infrastructure-As-Code を生成する 図 9: Console-to-Code の記録から生成された CloudFormation YAML テンプレート ワークロードを設計し最適化するために Q を活用する このセクションでは、Amazon Q を活用して新しいワークロードを設計し、既存のワークロードを最適化することに焦点を当てます。 ワークロードの設計 ここで、開発者が以下の要件を持つ新しい金融サービスアプリケーションを構築したいと考えています: アーキテクチャはサーバーレスかつイベント駆動であること 入金や出金などの機能を提供すること 低コストで効率的な AWS サービスを使用すること 1秒あたり数千のリクエストに達する可能性があるトラフィックスパイクにスケールすること REST API をサポートすること 以下のプロンプトをコピーしてチャットウィンドウに貼り付け、 Amazon Q Developer に問い合わせてみましょう: サンプルプロンプト: How can I build a new financial services application with the following requirements: it should be serverless and event driven, must provide functionality as deposits and withdrawals, It should use low-cost efficient AWS services, It should scale with traffic spikes that can reach thousands of requests per second, and lastly it should support REST APIs. （日本語訳: 以下の要件を持つ新しい金融サービスアプリケーションを構築するにはどうすれば良いですか？サーバーレスでイベント駆動であること、入金と出金などの機能を提供すること、低コストで効率的な AWS サービスを使用すること、1秒あたり数千のリクエストに達する可能性があるトラフィックスパイクにスケールすること、そして REST API をサポートすること。） Amazon Q はこのワークロードの設計方法について回答を提供します。以下が Amazon Q から受け取ったサンプル回答です: 図 10: アーキテクチャについての Amazon Q からの応答 Amazon Q は以下のように回答しました: ご説明いただいた要件を持つ新しい金融サービスアプリケーションを構築するために、以下の AWS サービスとアーキテクチャをお勧めします: サーバーレスおよびイベント駆動アーキテクチャ: コアアプリケーションロジックには AWS Lambda を使用し、サーバーのプロビジョニングや管理なしでコードを実行できるようにします。 AWS Lambda を、REST API 用の Amazon API Gateway 、データベース用の Amazon DynamoDB 、イベント駆動メッセージング用の Amazon SNS/SQS などの他のサーバーレスサービスと統合します。 入金と出金機能: 顧客口座情報と取引詳細を保存するデータベースとして Amazon DynamoDB を使用します。 入金と出金のロジックを、 Amazon API Gateway または Amazon SNS/SQS からのイベントによってトリガーできる AWS Lambda 関数で実装します。 低コストで効率的な AWS サービス: 消費したコンピュート時間に対してのみ課金される AWS Lambda と、リクエストごとの料金モデルを提供する Amazon DynamoDB を活用します。 REST API のコストを低く抑えるために、リクエスト毎の料金モデルを提供する Amazon API Gateway を活用します。 低コストで可用性が高く、スケーラブルなメッセージング機能のために Amazon SQS と Amazon SNS の使用を検討します。 スケーラビリティとハイパフォーマンス: AWS Lambda や他のサーバーレスサービスは、1 秒あたり数千のリクエストのトラフィックスパイクを処理するために、自動的にスケールします。 Amazon API Gateway のキャッシュ機能、 Amazon DynamoDB の自動スケーリング、 Amazon SQS のメッセージバッチ処理などの機能を使用することで、さらにパフォーマンスを最適化できます。 REST API のサポート: RESTful API を公開するために、 AWS Lambda のアプリケーションロジックを Amazon API Gateway と統合します。 Amazon API Gateway は、ルーティング、認証、スロットリングを含む API 管理を処理します。 開始するには、以下の AWS ドキュメントの確認をお勧めします: サーバーレスアプリケーションのための AWS Lambda サーバーレスアプリケーションの構築のための Amazon API Gateway NoSQL データベース用の Amazon DynamoDB メッセージング用の Amazon SNS および Amazon SQS 他にご質問がありましたらお知らせください！ 出典: Key AWS services – Financial Services Industry Lens Harnessing the scale of AWS for financial simulations | AWS HPC Blog RPC と REST の違いはなんですか？ – AWS 上記のように、 Amazon Q は提供された要件に基づいてアーキテクチャの推奨サービスと、それらのサービスへのリンクも提供しました。 ワークロードの最適化 ここで、開発者や IT プロフェッショナルが AWS に Amazon EC2 を中心としたアーキテクチャを運用しており、Server-1-demo という名前のインスタンスをデプロイしているケースを想定します。そして、その環境を、コスト削減のために最適化したいと考えているとします。 前のセクションと同様に、コンソール内の Amazon Q チャットで新しいチャットウィンドウを開き、以下のプロンプトを入力します: サンプルプロンプト: Based on the current CPU utilization of my EC2 Server-1-demo, what do you recommend I do to cost optimize? （日本語訳: 現在の CPU 使用率を考慮して、EC2 Server-1-demo のコストを最適化するにはどうすればよいですか？） その結果、 Q は以下のような応答を提供します: 図 11: Amazon Q からの最適化に関する応答 図のとおり、 Amazon Q は Server-1-demo の CPU 使用率のコンテキストを考慮し、 AWS Graviton などの活用を含む推奨事項を提示しました。なお、AWS Graviton は Amazon EC2 で実行されるクラウドワークロードに最高の価格性能を提供するように設計されたインスタンスタイプです。 コストを理解するためにQ を活用する コンソールで Q を活用するもう一つの方法は、コストの分析です。開発者や IT プロフェッショナルは Amazon Q を使用して AWS Cost Explorer からコストデータを取得・分析できます。AWS のコストについて質問すると、実際の AWS アカウントのコストを反映した回答を、自然言語で受け取れます。 それでは、新しい Amazon Q のコンソールチャットウィンドウを開き、以下のプロンプトを試してみましょう: サンプルプロンプト: Show me the breakdown of EC2 costs by instance type for the last 30 days. （日本語訳: 過去 30 日間の EC2 コストをインスタンスタイプ別に表示してください。） 図 12: 過去1か月の EC2 コストの内訳に関する Amazon Q からの応答 図 12 に示されているように、Amazon Q Developer は過去 30 日間の EC2 インスタンスタイプごとの詳細な内訳を提供しました。 では、別の例を試してみましょう: サンプルプロンプト: What was my cost breakdown by service for the past three months? （日本語訳: 過去 3 か月間のサービス別コスト内訳を教えてください。） 図 13: 過去 3 か月間の支出分析に関する Amazon Q からの応答 図 13 に示すとおり、 Amazon Q は総支出に対する割合を含む詳細なコスト内訳を提供し、 AWS の使用状況とコストを簡単に理解できるようにします。この機能により、最もコストの高いサービスを素早く特定し、時間の経過に伴う支出傾向を追跡できます。最も正確な情報を得るには、定期的に AWS Cost Explorer でコストデータを確認してください。この機能の詳細については、 この機能をより詳しく説明しているブログ をご確認ください。 コンソールでの Amazon Q の活用に関するベストプラクティス 前のセクションでは、 AWS アプリケーションのアーキテクチャとアカウント管理のために Amazon Q の機能を活用する例を紹介しました。いずれの場合も、 Amazon Q に与える入力は出力の品質に直接影響します。ツールがシナリオや回答すべき内容を理解できるよう、質問は簡潔で明確で、必要な詳細情報を含んでいる必要があります。生成 AI チャットボットに効果的な入力を行うための推奨方法のことを「プロンプトエンジニアリング」といいます。以下のベストプラクティスに従うことで、 Amazon Q の使用時に、より良い結果を得ることができます: Q に実行してほしいタスクを指定する：概念の説明、サービスの比較、メリットとデメリットの列挙、 CLI コマンドの生成、コードスニペットの生成、シナリオに対するアーキテクチャオプションの提案など。 コンテキストを提供する：なぜこの概念を知る必要があるのか？どの部分のアプリケーションやアーキテクチャにその知識を適用するのか？ 図 14: より良い回答を提供するために Amazon Q が追加の詳細を求めている この例では、シナリオの形式で返すよう指定しました。また、シナリオについて知りたいサービスと、シナリオのエッジケース（インスタンス作成後）を指定しました。 Amazon Q は私たちの質問を要約し、要求に応じてシナリオと関連情報を提供しました。 一連の質問を複数の質問に分割する 一度に1つのタスクについて尋ねる 最初の回答で終わらず、その情報を使用して質問を続け、 Q がより充実した回答を提供できるようにする 図 15: Amazon Q がチャットのコンテキストを使用して回答を提供している このシナリオでは、提供された入力だけでは Q が十分な回答を生成できなかったため、追加の詳細な情報を求め、それらを回答のコンテキストとして考慮しました。 アカウントのセキュリティに関する質問には注意してください。コンソールの Amazon Q は、アカウントのセキュリティに関する回答を提供しない場合があります。 入力できる文字数は最大 1000 文字までです。これも、入力を簡潔にする必要がある理由の1つです。 新しいトピックを開始する場合は、新しい会話を作成してください。不要なコンテキストは、新しい状況に対する Q の回答の具体性を低下させます。 図 16: Amazon Q はセキュリティに関するヒントを提供しません。新しい会話を作成してください。最大文字数は 1000 文字です。 まとめ このブログ記事では、 AWS の生成 AI 搭載アシスタントである Amazon Q が、開発者、 DevOps エンジニア、アーキテクトの生産性向上とスタートアップ時間の短縮のために AWS コンソールでどのように活用されているかを様々な観点から探りました。 Amazon Q は AWS コンサルタントとして機能し、 AWS サービスの理解とベストプラクティスの実装、コードスニペットの生成や CLI コマンドの自動化など、様々なタスクについてアドバイスを提供します。特定のニーズに基づいて新しいワークロードを設計し、既存のワークロードを強化する機能について、詳細な例を用いて実証しました。また、 AI アシスタントから質の高い応答を引き出すための明確で簡潔なプロンプトの作成である、プロンプトエンジニアリングの重要性についても説明しました。コンソールでの Amazon Q の機能を活用することで、 AWS ユーザーはワークフローを効率化し、クラウドジャーニーを加速させることができます。経験豊富なクラウドアーキテクトであっても、これから始める方であっても、この AI 搭載アシスタントはパートナーとして、 AWS の領域をナビゲートし、新しいレベルの効率性を引き出すお手伝いをします。この記事で説明したベストプラクティスに従って、 Amazon Q の可能性を探求し続け、実験してください！ 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Brendan Jenkins Brendan Jenkins は、エンタープライズの AWS のお客様に技術的なガイダンスを提供し、ビジネス目標の達成を支援する Amazon Web Services (AWS) のテックリードソリューションアーキテクトです。 DevOps および機械学習技術を専門分野としています。 Renu Yadav Renu Yadav は Amazon Web Services (AWS) のソリューションアーキテクトで、エンタープライズレベルの AWS のお客様に技術的なガイダンスを提供し、ビジネス目標の達成を支援しています。 Renu は DevOps を専門分野とする学習への強い情熱を持っています。この分野での専門知識を活かし、 AWS のお客様のクラウドインフラストラクチャの最適化とソフトウェア開発およびデプロイメントプロセスの効率化を支援しています。 Maria Mendes Maria Mendes はソリューションアーキテクトで、2022年から CSC SA チームの一員として中小企業のお客様と働いています。 Maria の日常業務は、アーキテクチャのレビュー、 AWS サービスのベストプラクティスガイダンスの提供、お客様とのワークショップの実施、複数のお客様が参加する AWS イベントでの講演活動などです。彼女は幅広い分野に精通したソリューションアーキテクトであり、また AWS 内の DevOps サービスに焦点を当てた技術フィールドコミュニティのメンバーでもあります。