2022 年に リリース されて以来、 Customer Carbon Footprint Tool (CCFT) は、 Amazon Web Services (AWS) サービスの使用に関連する二酸化炭素の推定排出量を提供することで、二酸化炭素排出を追跡、測定、確認するお客様のサステナビリティジャーニーをサポートしてきました。 2025 年 4 月、AWS は CCFT で大規模なアップデート を実施しました。これには、二酸化炭素排出データへのより簡単なアクセス、 AWS リージョン ごとの排出量の可視化、ロケーション基準手法 (LBM) の包含、更新された独立検証済みの方法論、ならびに AWS 請求コンソール内の専用ページ への移行が含まれます。 CCFT は、 温室効果ガス (GHG) プロトコル の排出区分 (企業の排出を分類するもの) から情報を得ています。今日は、CCFT にスコープ 3 排出量データが追加され、スコープ 1 排出量が更新されたことをお知らせします。新しい排出カテゴリは既存のスコープ 1 と 2 のデータを補完するもので、お客様がそれぞれの二酸化炭素排出量データを包括的に把握できるようにします。 この更新された方法論には、新たな排出カテゴリが組み込まれています。非常用発電機 (ディーゼル) 内の燃料燃焼による既存のスコープ 1 排出量に加えて、スコープ 1 の冷媒と天然ガスが追加されました。全排出量でスコープ 1 排出量が占める割合はわずかですが、AWS はお客様に二酸化炭素排出量の全体像を提供します。 スコープ 3 のどのカテゴリをモデルに含めるかを決定する上で、AWS は全体的なカーボンインパクトに対する各カテゴリの重要性を検討し、排出量の大部分が網羅されていることを確実にしました。この点を考慮して、方法論には以下の内容が含まれることになりました。 燃料及びエネルギー関連活動 (GHG プロトコルの「FERA」) – これには、購入した燃料の上流排出量、購入した電力の上流排出量、送配電 (T&D) 損失が含まれます。AWS は、LBM とマーケット基準手法 (MBM) の両方を使用してこれらの排出量を計算します。 IT ハードウェア – AWS は、原材料の抽出から、製造、AWS データセンターへの輸送におよぶ排出量を追跡する、包括的な Cradle-to-Gate アプローチを採用しています。計算方法には、エンジニアリング属性を用いた積み上げ法ベースのライフサイクルアセスメント (LCA)、外挿法、代表カテゴリ平均ベースの LCA、および産業関連分析法ベースの LCA の 4 つを使用します。AWS では、全体的な排出量に大きく貢献するコンポーネントに対して最も詳細で正確な手法を優先しています。 建築物と機器 – AWS は、建築、使用、寿命期間終了の各段階からの排出量を考慮する、確立された全建築物ライフサイクルアセスメント (wBLCA) 基準に従っています。分析の対象となるのは、データセンターの外郭構造、部屋、およびエアハンドリングユニットや発電機などの長納期機器です。この方法論は、積み上げ法ベースのライフサイクルアセスメントモデルと産業関連分析法の両方を使用して、包括的な分析範囲を提供します。 分析後、スコープ 3 排出量を資産の耐用年数 (IT ハードウェアの場合は 6 年間、建築物の場合は 50 年間) で均等償却して、お客様に割り当てることができる月次排出量を計算します。この償却とは、各資産の総エンボディドカーボンを運用期間全体に平等に分配することを意味し、早期廃止や延長使用などのシナリオが考慮されています。 これらのアップデートはすべて方法論バージョン 3.0.0 の一部であり、第三者機関によって独立検証された 最新の方法論ドキュメント で詳しく説明されています。 CCFT へのアクセス方法 使用を開始するには、 AWS Billing and Cost Management コンソール に移動し、[ コストと使用状況の分析 ] で [ Customer Carbon Footprint Tool ] を選択します。ダッシュボードで二酸化炭素排出量データにアクセスしたり、CSV ファイルをダウンロードしたりでき、基本的な SQL を使用してすべてのデータをエクスポートすることも、 AWS Data Exports や Amazon Quick Sight と統合してデータを視覚化することも可能です。 AWS では、ユーザーが有意義な前年比較を行えるように、方法論のバージョン 3 を使用して 2022 年 1 月までの履歴データを再計算しました。現在 CCFT に表示されるすべてのデータは、バージョン 3 を使用しています。バージョン 3 を使用した履歴データを確認するには、[ カスタムデータエクスポートの作成 ] を選択します。新しいデータエクスポートには、排出量をスコープ 1、2、3 ごとに分類する新しい列が含まれるようになりました。 AWS の推定排出量と推定削減量も確認できます。デフォルトで、このツールは 38 か月分のデータの MBM を使用して計算された排出量を表示します。LBM を使用して計算された排出量は、ダッシュボードの [ 計算方法 ] フィルターで [ LBM ] を選択することで確認できます。二酸化炭素排出量の測定単位は、業界標準測定値である二酸化炭素換算メートルトン (MtCO2e) です。 [ 二酸化炭素排出量の概要 ] には、二酸化炭素排出量の経時的な傾向が表示されます。また、AWS サービスの使用による排出量やすべての AWS リージョンの排出量も確認できます。詳細については、AWS ドキュメントで「 Viewing your carbon footprint 」をお読みください。 お客様の声 一部のお客様にはこれらのアップデートへの早期アクセスが提供されており、次のようなご意見をいただいています。 Impact at Salesforce の シニアバイスプレジデントである Sunya Norman 氏は、「効果的な脱炭素化は、特にスコープ 3 排出量におけるカーボンフットプリントの可視化から始まります。業界平均は出発点に過ぎません。AWS のようなクラウドプロバイダーから得られるきめ細かな二酸化炭素データは、私たちのクラウドインフラストラクチャに関連する実際の排出量をよりよく理解し、削減対策を最も重要な箇所に集中させるために欠かせません」と話しています。 SAP の Head of Environmental Management である Gerhard Loske 氏は、「CCFT に対する最新のアップデートは、SAP のサステナビリティ目標の管理に役立つ大きな前進です。新しいリージョン固有のデータを使用することで、排出の発生源をより正確に把握し、的を絞った対応策を講じることが可能になりました。また、近々追加されるスコープ 3 排出量によって、AWS ワークロード全体における二酸化炭素排出量をより詳しく把握できるようになります。これらの改善は、データの有意義な気候変動対策への変換を容易にしてくれます」と語りました。 Pinterest の Global Sustainability Lead である Mia Ketterling 氏は、スコープ 3 排出量データのメリットを強調し、「スコープ 3 排出量データを CCFT に含めることで、AWS は Pinterest のような顧客がデジタル事業におけるカーボンフットプリント全体をより正確に測定して報告できるようにしています。透明性の向上は、バリューチェーンの全体で有意義な気候変動対策を推進するために役立ちます」と話しました。 12 月に開催される AWS re:Invent に現地参加するならば、Customer Carbon Footprint Tool が環境イニシアティブをサポートする方法を AWS、Adobe、Salesforce のテクニカルリーダーが明らかにするイベントにぜひご参加ください。 今すぐご利用いただけます スコープ 1、2、3 を対象とする CCFT では、排出量を経時的に追跡してサステナビリティ目標に向けた傾向を理解し、実施した二酸化炭素削減プロジェクトの影響を確認することができます。詳細については、 Customer Carbon Footprint Tool (CCFT) ページ をご覧ください。 AWS Billing and Cost Management コンソール でこれらの新特徴量をお試しいただき、 AWS re:Post for the CCFT 、または通常の AWS サポート担当者を通じてフィードバックをお寄せください。 – Channy 原文は こちら です。

私は、今年 1 年を通じて世界中のテクノロジーコミュニティが主催し、参加してきたすべてのアクティビティからインスピレーションを得てきました。ここ南半球では、近づいてきた夏休みに夢をふくらませ始め、今年スタートしたアクティビティの一部が終わりを迎えようとしています。南アフリカのテクノロジーコミュニティは、今年のアクティビティを楽しく締めくくる方法として私と同僚が今月いっぱい開催している Amazon Q Developer コーディングチャレンジ に参加中です。第 1 回目は 10 月 13 日週の金曜日にヨハネスブルグで開催され、次はダーバンとケープタウンで開催される予定です。 10 月 13 日週のリリース では、私が注目した 10 月 13 日週のリリースをご紹介しましょう。 Kiro がすべての開発者にご利用いただけるようになりました – 90 日以上前に Kiro がリリースされて以来、10 万人を超える開発者が Kiro を試すためのウェイティングリストに登録しましたが、このたびウェイティングリスト登録が終了しました。AI を用いたコーディングに対するこの仕様駆動のアプローチを試してみたいとお考えならば、 今すぐサインアップ しましょう。 Amazon EC2 Capacity Manager – オンデマンドインスタンス、スポットインスタンス、キャパシティ予約を使い、複数のアベイラビリティーゾーンとアカウントの全体で何百ものインスタンスタイプを運用するという規模で Amazon Elastic Compute Cloud (Amazon EC2) を使用している皆さんに朗報です。 すべてのアカウントと AWS リージョンのキャパシティ使用状況を単一のインターフェイスから監視、分析、管理するための一元化されたソリューションを提供する EC2 Capacity Manager が利用可能になりました 。 Amazon EBS Volume Clones – 時折、修正を本番環境に実装する前に非本番環境でテストするための本番データが必要になることがあります。通常は、このデータの EBS スナップショットを作成し、そのスナップショットから新しいボリュームを作成しますが、それと同時にこのプロセスの運用オーバーヘッドに対処しなければなりません。同一のアベイラビリティーゾーン内で EBS ボリュームのポイントインタイムコピーを瞬時に作成できる新機能、 Amazon EBS Volume Clones の提供開始についてお読みください 。 その他のアップデート こちらは、私が興味深いと感じたプロジェクト、ブログ記事、ニュースです。 AWS Transfer Family SFTP コネクタが VPC ベースの接続のサポートを開始 – Amazon Virtual Private Cloud (Amazon VPC) 環境経由でのリモート SFTP サーバーへの接続を AWS Transfer Family SFTP コネクタがサポートするようになりました 。 ビジネスが進化するにつれて、AWS リージョン間でワークロードを移行する必要が生じる場合があります。新しい地域のユーザーに対するレイテンシーの低減や、リージョン固有のコンプライアンス要件への対応を検討しているのかもしれませんし、製品の提供範囲を拡大している独立系ソフトウェアベンダーである場合もあるでしょう。理由が何であれ、特に暗号化されたリソースを扱う場合は、リージョン間の移行を慎重に計画する必要があります。 暗号化された Amazon EC2 インスタンスの AWS リージョン間での移行を AWS KMS キーを共有せずに実行する方法をお読みください 。 モノのインターネット (IoT) デバイスは、家庭から産業環境に及ぶさまざまな環境で私たちが交流する方法を変革しました。ところが、接続されるデバイスの数が増えるにつれて、それらを管理する複雑性も増大します。 Amazon Bedrock AgentCore を使用してデバイス管理エージェントを構築する方法 を学びましょう。 近日開催予定の AWS イベント 今後のイベントをチェックして、ぜひご登録ください。 AWS re:Invent 2025 (2025 年 12 月 1〜5 日、米国ラスベガス) – 毎年恒例の AWS フラッグシップカンファレンスは、P2Pラーニング、専門家主導のディスカッション、貴重なネットワーキング機会を通じてコラボレーション型のイノベーションを実現します。 AWS Builder Center に参加して、AWS コミュニティで AWS ビルダーとともに学び、構築し、交流しましょう。今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 10 月 20 日週のニュースは以上です。10 月 27 日週にお届けする次回の Weekly Roundup もお楽しみに! – Veliswa 原文は こちら です。

本ブログは、2025 年 7 月 1 日に公開された Improve recovery resilience with AWS Backup support for Multi-party approval を翻訳したものです。 組織は、進化するサイバー脅威からバックアップを保護する必要があります。包括的なバックアップと復旧戦略には、分離を確保した上で改ざんを防ぐ不変性、バックアップの信頼性を確保するための整合性検証、そして必要な時に使用できる可用性、3 つの基本的な柱が大切です。これらの柱は、効率的なデータ保護の基盤を形成します。分離を伴う不変性により、バックアップは変更されず消去不可能で、本番インフラストラクチャから分離され元の状態を維持します。整合性検証は、バックアップが破損しておらず復元可能であることを確認します。利用可能性は、復元が必要になった時にバックアップを確実に利用できることが保障され、重要な状況でのビジネス継続性を確保します。これらの要素が組み合わさることで、組織で最も価値があるといえるデータを多様な脅威から守る堅牢なセキュリティフレームワークが完成します。 AWS Backup は、堅牢なデータレジリエンス戦略の基盤を提供します。複数の アベイラビリティーゾーン (AZ) にわたってバックアップを保存することで、 99.999999999% (イレブンナイン) の耐久性 を提供します。 AWS Backup Vault Lock は、バックアップの改ざんを禁止することで不変性を確保します。 AWS Backup 復元テスト は、バックアップの整合性を検証し、パートナーソリューションと統合してフォレンジック分析機能を拡張します。AWS Backup は、バックアップ対象となる基盤の AWS サービスと少なくとも同等レベルの回復力と耐久性を維持し、データ保護戦略の強固な基盤を提供します。 しかし、重大なセキュリティインシデント中にバックアップへのアクセスを確保するには、これらのネイティブ機能を超えた追加の制御が必要です。バックアップシステムが本番環境と認証境界を共有している場合、単一の認証情報が侵害されると両方の環境に影響を与える可能性があります。これにより、脅威アクターは本番データを暗号化し、復旧メカニズムへのアクセスをブロックして、バックアップと復旧戦略全体を損なう可能性があります。 このブログは 2 部構成になります。パート 1 となる本ブログでは、より堅牢なアプローチが必要となる背景を探り、新しくリリースされた マルチパーティ承認 と AWS Backup Logically air-gapped vault の統合を紹介し、AWS 環境での設定手順を説明します。 パート 2 では、ベストプラクティスと実用的な例を含む、AWS 環境でのマルチパーティ承認ワークフローの設定に関する実装ガイダンスを提供します。 従来の復旧アーキテクチャにおける連鎖障害のリスク 既存のバックアップと復旧戦略には、重要な考慮事項があります。それは、保護対象である本番環境と同じ認証境界を共有することが一般的だということです。データへのアクセスは適切に実装されたアイデンティティ戦略によって管理され、本番システムとバックアップシステム間で明確に分離された、より堅牢な復旧機能を実現するべきです。しかし、この重要な分離はしばしば見過ごされています。バックアップがソースアカウントの認証情報と密結合している場合、ソースアカウントの侵害がバックアップにまで波及する可能性があります。これは AWS Organizations において潜在的な脅威となります。クロスアカウントアクセスと共有認証依存関係が、セキュリティインシデントの影響範囲を拡大する可能性があるためです。 本番アカウントで昇格された権限を取得した脅威アクターを考えてみましょう。彼らは本番データを暗号化し、復旧メカニズムへのアクセスをブロックする可能性があります。この課題は、組織が拡大するにつれてさらに重要になります。単一の認証情報の侵害が、複数のアカウントとワークロードにわたってビジネス継続性に影響を与える可能性があるからです。本番アカウントと同じ信頼境界内にバックアップを維持する従来のアプローチは、脅威が悪用できる単一障害点を作り出し、最後の防御線であるべきものを脆弱なターゲットに変えてしまいます。 AWS セキュリティフレームワーク: データ保護の構成要素 スケーラブルなセキュリティの基盤として機能する AWS Organizations は、企業は組織全体にわたって多層防御コントロールをデプロイおよび管理でき、相乗効果のあるセキュリティ体制を構築できます。 Service Control Policies (SCP) は、アカウント全体で権限を制限するガードレールとして機能し、 Resource Control Policies (RCP) は特定のリソースに対する 大まかな制御 を提供します。 AWS Identity and Access Management (IAM) アクセス許可境界 は、IAM プリンシパルのアクセス許可を制約し、最小権限の原則に沿って、当初意図されたものを超えないようにします。 AWS Key Management Service (AWS KMS) は、カスタマー管理キーを使用した暗号化によりデータを保護でき、クロスアカウントコピーにより、バックアップの物理的分離を確保して復旧力を向上させます。しかし、これらのコントロールは強力である一方、従来の単一承認フレームワーク内で動作しており、内部攻撃や認証情報の侵害により、これらの保護を回避される可能性があります。 AWS Backup の Logically air-gapped vault この課題に対処するため、AWS Backup は AWS Backup Logically air-gapped vault のマルチパーティ承認 をサポートし、運用の俊敏性を損なうことなくセキュリティを強化します。次のシナリオを考えてみてください。AWS Backup Vault Lock によって保護された不変のバックアップを作成し、AWS Backup Logically air-gapped vault で サービス所有鍵による暗号化 を通じて分離したとします。ランサムウェアインシデントの際に、脅威アクターがバックアップアカウントまたは組織の管理アカウントへのルートアクセスを取得したとします。バックアップは安全に保存されたままですが、アカウントへのアクセスを回復するために AWS Support に連絡する必要があります。 マルチパーティ承認は、図 1 に示すように、バックアップへの独立したアクセスパスを作成する仕組みです。この仕組みでは、重要な操作を実行する際に複数の承認者による合意が必要となり、一人の判断だけでは変更できないようになっています。これにより、一方的な変更や不正な操作を防ぐことができます。このネイティブな AWS 機能を使用することで、信頼できる個人で構成された承認チームを、AWS Backup Logically air-gapped vault に関連付けることができます。悪意のある行為により AWS アカウントにアクセスできなくなった場合、これらの承認チームは、現在の AWS Organizations 外のアカウントも含めて、1 つまたは複数の復旧アカウントからのボールト共有リクエストを承認できます。これにより、復旧に必要なバックアップへのアクセスを得るための手続きが不要になり、 目標復旧時間 (RTO) が改善されます。 図 1: マルチパーティ承認ワークフロー ユースケースとデプロイパターン マルチパーティ承認と AWS Backup Logically air-gapped vault の統合により、データ保護のための堅牢なフレームワークが構築できます。 Sheltered Harbor などに準拠する組織では、バックアップが不変性を維持し、本番インフラストラクチャからの分離を提供し、整合性検証を可能にすることが求められます。AWS Backup Logically air-gapped vault は、3 つの主要な機能を通じてこれらの基本要件に対応します。コンプライアンスモードによるロックを使用してバックアップの不変性を維持し、Logically air-gapped vault を通じて本番インフラストラクチャからの分離を提供し、AWS Backup 復元テストとの統合を通じてバックアップデータの検証を可能にします。このアーキテクチャは、元のインフラストラクチャから完全に分離されたバックアップを維持する必要がある金融機関やその他の規制対象企業にとって特に価値があります。 以下のセクションでは、組織がさまざまなシナリオでこの機能を戦略的に実装する方法について説明します。特に、2 つの重要なユースケースについて詳しく説明します。 AWS アカウント復旧 : AWS Backup Logically air-gapped vault をホストする単一の AWS アカウントにアクセスできなくなった場合に、マルチパーティ承認がどのように復旧を可能にし、重要なセキュリティインシデント中でもビジネス継続性を確保するかを説明します。 AWS Organizations 復旧 : Organizations 全体が侵害される複雑なシナリオを検証し、マルチパーティ承認が復旧のライフラインをどのように提供するかを説明します。 AWS アカウントの復旧 AWS Backup Logically air-gapped vault をホストしている AWS アカウントが、セキュリティインシデントや認証情報の侵害により完全にアクセス不可能になるシナリオを考えてみましょう。従来の復旧方法では AWS Support への連絡が必要となり、ビジネスの中断が長期化します。しかし、マルチパーティ承認を使用すると、次の図に示すように、事前定義された復旧戦略を実装できます。 このプロセスは、一元管理されたマルチパーティ承認チームの事前設定から始まります : 組織内の信頼できる個人で構成される マルチパーティ承認チームを作成します 。 作成した 承認チームを共有します 。 関連する AWS Backup Logically air-gapped vault と マルチパーティ承認チームを関連付けます。 アクセシビリティの侵害が発生した場合 : AWS Resource Access Manager (RAM) を使用し、承認チームを 1 つ、もしくは複数の復旧アカウントに共有します。 復旧チームが、1 つまたは複数の復旧アカウントから Vault 共有リクエストを送信します。 マルチパーティ承認がトリガーされ、Logically air-gapped vault へのアクセス要求が保留中であることを承認者に通知します。 指定されたマルチパーティ承認チーム内のメンバーがリクエストに 応答 し、共有を承認します。 チームから必要な数の承認を受け取ると、Logically air-gapped vault が復旧アカウントでアクセス可能になります。 これで侵害された所有アカウントとは独立して、Logically air-gapped vault 内のバックアップを使用してリカバリ操作を実行できるようになりました。 この仕組みにより、単独の個人がバックアップデータに一方的にアクセスすることを防ぎ、堅牢なセキュリティ制御を維持しながらビジネス継続性を確保できます。プロセス全体で AWS のネイティブなインターフェースを使用することで、侵害されたアカウントの認証システムへの依存を排除し、RTO を大幅に短縮します。 図 2: AWS クロスアカウント マルチパーティ承認ワークフロー このアーキテクチャを実装することで、侵害された可能性のあるインフラストラクチャから独立して動作する、信頼できる復旧パスを作成できます。これにより、最も重要なセキュリティインシデントに対しても、回復力のあるソリューションを提供します。 AWS Organizations の復旧 前のシナリオでは個別アカウントの侵害に対処しましたが、Organization 全体にアクセスできなくなる状況にも備える必要があります。これは、大規模な侵害、重大な設定ミス、管理アカウントの侵害、または悪意のある内部関係者によって発生する可能性があります。このような場合、復旧プロセスにはさらに堅牢で独立した信頼モデルが必要になります。 このプロセスは、中央管理されたマルチパーティ承認チームの事前設定から始まります。これは図 3 にも示されています : プライマリインフラストラクチャとは別の復旧用 Organization を作成します。 この Organization 用に独立したアイデンティティプロバイダー (IdP) を設定し、マルチパーティ承認と関連付けます。 この独立した IdP を使用して、組織内の信頼できる個人で構成されるマルチパーティ承認チームを作成します。 AWS RAM を使用して、このマルチパーティ承認チームを AWS Backup Logically air-gapped vault を使用するアカウントと共有します。 関連する AWS Backup Logically air-gapped vault に マルチパーティ承認チームを関連付けます 。 アクセシビリティの侵害が発生した場合 : AWS RAM を使用して、承認チームを 1 つまたは複数の復旧アカウントと共有します。 指定された復旧チームのメンバーが、1 つまたは複数の復旧アカウントから Vault 共有リクエストを開始します。 マルチパーティ承認ワークフローがトリガーされ、Logically air-gapped vault へのアクセス要求が保留中であることをチームメンバーに通知します。 指定されたマルチパーティ承認チーム内の承認者が承認リクエストに 応答 し、共有を承認します。 承認チームから必要な数の承認を受け取ると、Logically air-gapped vault が復旧アカウントでアクセス可能になります。 侵害された所有アカウントに依存することなく、Logically air-gapped vault のバックアップを使用して復旧操作を進めることができるようになりました。 図 3: Organization を横断したマルチパーティ承認ワークフロー このアーキテクチャは、Organization 全体がアクセス不能になった場合でも、重要なバックアップデータへのアクセスを維持する復旧パスを作成します。最小権限の原則と独立したアイデンティティ制御を組み合わせることで、最も厳格なコンプライアンス、規制、セキュリティ復旧シナリオに対して最高レベルの回復力を提供できます。 ハイレベル参照アーキテクチャ AWS Backup のリファレンスアーキテクチャには、次の図に示すように、複数の保護と検証レイヤーが含まれます。プライマリワークロードアカウントでは、本番システムがローカルの AWS Backup ボールトにバックアップされます。そこから、これらのバックアップのコピーが同じアカウント内の AWS Backup Logically air-gapped vault に送信され、さらなる分離レイヤーを提供します。データの整合性を確保するため、この Logically air-gapped vault は AWS RAM を通じて専用のフォレンジックアカウントと共有されます。フォレンジックアカウントでは、AWS Backup 復元テストがサードパーティソリューションと併せて実施され、バックアップデータの整合性と復旧可能性が検証されます。この継続的な検証プロセスにより、バックアップが破損せず信頼性を保つことが保証されます。 復旧シナリオでは、2 つのパスが利用できます。まず、AWS RAM を通じたデフォルトの共有により、フォレンジックアカウントの認証されたユーザーが、通常の状況下または迅速なデータ損失復旧のためにバックアップにアクセスして検証できます。次に、プライマリアカウントまたは Organization 全体にアクセスできなくなった状況では、マルチパーティ承認によりバックアップに安全にアクセスできます。この 2 つのアプローチにより、日常的な運用の柔軟性と堅牢な危機復旧メカニズムの両方が提供され、潜在的なセキュリティインシデントの規模に関係なく、重要なデータへの利用可能性と整合性が確保されます。 図 4: AWS Backup のリファレンスアーキテクチャ まとめ 効果的な復旧戦略には、3 つの重要な柱が必要です。分離を確保し改ざんを防ぐ不変性、信頼性を確保する整合性検証、そして可用性です。AWS Backup は、不変性と分離のための vault lock を備えた Logically air-gapped vault、整合性検証のための AWS Backup 復元テスト、そして重要なセキュリティインシデント中でもバックアップへの信頼性の高いアクセスを確保するマルチパーティ承認を通じて、これらを提供します。マルチパーティ承認は、単一アカウントのインシデントから組織全体のイベントまで、バックアップアクセスを可能にすることで復旧戦略を変革します。最小限の必要な承認ベースの決定フローと独立した ID インフラストラクチャにより、従来の認証方法が失敗した場合でも復旧パスを利用可能にします。 今すぐ復旧計画にマルチパーティ承認を使用することを検討し、あらゆるシナリオにおいて組織が重バックアップデータへのアクセスを維持できるようにしてください。職務の明確な分離と独立したアイデンティティメカニズムを備えたこれらの復旧パターンを実装することで、あらゆるサイバーインシデントから復旧する組織の能力が強化されます。常に覚えておいてください。復旧戦略は必要な時に実行できるかが鍵となります。

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 企業のESG（環境・社会・ガバナンス）への取り組みが重視される中、サプライチェーン全体の透明性確保と人権リスク管理は喫緊の課題となっています。特に2023年以降、企業サステナビリティ・デューディリジェンス指令など、人権問題に関する法規制が厳格化され、企業はより効率的かつ高頻度なリスク分析手法を模索しています。 本記事では、 Amazon Neptune と Amazon Bedrock を組み合わせた GraphRAG（Graph Retrieval-Augmented Generation）技術を活用し、サプライチェーン上のリスク検知の実現に向けた 株式会社リネア 様 の取り組みをご紹介します。 リネア様の状況と経緯 株式会社リネア様は、すべての業界の企業が容易に自社サプライチェーン上の多様なリスクを検知・分析できる仕組みを提供するサービスの開発に取り組まれています。その一例として、人権リスクにフォーカスしたユースケースの構築を行いました。以下はプロダクトの利用イメージです。 近年、多くの企業が自社の直接取引先だけでなく、その背後にある調達先や委託先を含めたサプライチェーン全体の人権リスク分析を求められるようになってきました。 しかし、特に間接サプライヤーの情報取得には大きな困難があり、サプライチェーン全体のリスク分析は時間と費用がかかるため、実施している企業であっても、年に1回程度にとどまっています。理想的には、サプライチェーンのリスクは年に数回の定期チェックに加え、構成変更や関連企業のニュースが出た時点で臨時に再評価すべきです。しかし、従来のやり方では頻度やスピードに限界がありました。 こういった課題に対して、リネア様は、Amazon Neptune と Amazon Bedrock を組み合わせて GraphRAG を実装し、サプライチェーンのリスク検知サービス開発に着手しています。Amazon Bedrock の長文処理で自然言語問い合わせを可能にし、Amazon Neptune のグラフ分析で多段の取引関係を効率的に探索することで、定期分析に加え、構成変更や関連ニュースなどのイベント発生時にも迅速に臨時評価が可能となります。リレーショナルデータベース（RDS）では非効率ですが、Amazon Neptune はノードとエッジで関係を自然に表現でき、多段依存のリスクを早期に把握できます。 このような理由から、Amazon Neptune と Amazon Bedrock が採用されました。 ソリューションと構成 このソリューションでは、GraphRAG を実現するために Amazon Neptune と Amazon Bedrock を組み合わせたアーキテクチャを採用しています。 この構成の特徴は複雑なグラフ検索アルゴリズムをユーザーが意識することなく、自然言語での質問だけで容易に分析が可能な点です。 以下の図は、利用者が任意のタイミングで検知・分析を行う場合のアーキテクチャです。 このアーキテクチャでは、まず情報配信ベンダーから取得した企業情報、取引関係情報、不芳情報、ニュース情報などのデータを生成 AI によって成形し、Amazon Neptune でグラフデータベースとして企業間の複雑な関係性を格納します。ユーザーからの自然言語による問い合わせに対しては、Amazon Bedrock で生成AIモデルである Anthropic 社の Claude 3.7 Sonnet を活用することで、自然言語から複雑なグラフクエリに変換を行い、Amazon Neptune に問い合わせを行います。 それにより、ユーザーが複雑なクエリやグラフ探索アルゴリズムを意識せずに、文章で質問を投げるだけで分析可能なシステムを実現しています。 なお、当該システムは現在開発段階であり、今後の開発推進とともに全体最適化の観点から構成を変更する可能性があります。 導入効果 サプライチェーン上の人権リスク検知サービスの導入により、以下の効果が期待されています。 １. 業務効率化 サプライチェーンリスク調査作業の工数を大幅に削減します。 関連サプライヤーを含む関連先調査整理: 5 日（国内企業のみの場合）または数か月〜半年（海外企業や 4 次サプライヤー以降も調査する場合）→ 0 日（完全自動化） リスク特定・データ収集・調査: 5 日 → 0 日（完全自動化） リスク評価・優先順位付け: 3 日 → 1 日（一部自動化） 合計で、従来 13 日〜半年程度かかっていた作業を、1 日程度に短縮できます。特に整理するのが困難だった関連サプライヤー情報を自動的に整理できるようになり、調査工数が 90% 以上削減されています。 ２. 高頻度な人権リスク分析の実現 本システムにより、以下のような高頻度な人権リスク分析・報告が可能です。 既存サプライヤーの定期再評価（年に 1 回程度から高頻度化） 新規サプライヤー契約時の人権リスクチェック 重大ニュース・アラートによるオンデマンド分析（不定期・即時対応） 監査対応時の分析（年 1〜2 回） NGO・メディア指摘時の証拠提示 CSR/ESG レポート作成・取締役会報告、社内研修・説明資料の根拠データ取得（月 1 回程度、最新事例へ容易に更新） ３. 業界へのインパクト また、以下のような業界全体へのインパクトが期待されています。 企業のリスク評価体制の強化 欧州だけでなく北米やアジア各国でも法規制が始まっており、人権リスク分析は義務化されつつある中、企業の人権リスク対策の強化は必須となっています。サプライチェーン上の分析を容易にすることで、リスク評価頻度を増やし、企業の人権リスク分析体制の底上げが期待できます。 テロ資金供与対策への取り組み強化 FATF（Financial Action Task Force／金融活動作業部会）から、日本の AML/CFT 対策（マネーロンダリング・テロ資金供与対策）は国際基準と比較して不十分と評価されており、特に企業の実効性のあるアプローチが不足していると指摘されています。サプライチェーン上から人権問題を起こす可能性のある組織との取引を検知できるようになることで、日本の AML/CFT 対策の強化に繋がることが期待されます。 また、本取り組みは、アマゾンウェブサービスジャパン合同会社 広域事業統括本部主催の「ビジネスをグロースする生成AIコンテスト2025」決勝において、総合1位となる「Gold Award」を 受賞獲得 されました。 今後の展望 リネア様では、2027年度の本システムの本格導入に向けてさらなる開発に取り組まれています。 開発スケジュールとしては、2025 年 7 月から簡易的な GraphRAG デモ機の開発を開始し、グラフデータベース開発、リスク評価機能開発、リスク可視化・アラート・問い合わせ機能開発と段階的に進めていく計画です。 まとめ 本事例は、企業が自らの得意分野であるサプライチェーン管理に対して、生成 AI とグラフデータベースを組み合わせた GraphRAG 技術を活用し、新たなサービス開発を実現した好例です。リネア様の新技術への積極的な姿勢と、AWS が提供する使いやすい生成 AI サービスとグラフデータベースの組み合わせが、革新的なソリューション開発につながりました。 リネア様の GraphRAG によるサプライチェーンリスク検知サービスは、Amazon Neptune と Amazon Bedrock を組み合わせることで、従来は困難だったサプライチェーン上の人権リスク調査業務を強力に支援し、高頻度での実施を可能にしました。即日対応が可能となる本システムにより、企業は人権リスク管理体制を強化し、社会的責任を果たすことができるようになることが見込まれます。 今後、このようなシステムが普及することで、企業が簡単にサプライチェーン上での人権リスク評価をできるようになり、世界における日本の人権問題、金融犯罪対策の底上げ・強化につながることが期待されます。 生成 AI を活用した新サービス開発、業務の効率化、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 ソリューションアーキテクト 古屋　楓 アカウントマネージャー　ク　シイ

本記事は 2025 年 10 月 21 日に公開された Kandyce Bohannon による “ Multimodal Development with Kiro: From Design to Done ” を翻訳したものです。 ソフトウェアアーキテクチャとエンジニアリングは、アートでありサイエンスでもあります。私たちは複雑な問題を解決するエレガントな設計を作り上げますが、初期設計から最終デプロイまでのどこかで、そのビジョンが失われてしまうことがあります。多くの開発者やアーキテクトの方なら、これを身をもって経験したことがあるでしょう。システム図を何時間もかけて完璧に仕上げても、実装がその設計からどんどん逸れていってしまうのです。要件が変わり、開発者があなたの書いた図を異なって解釈し、気がつくと美しいアーキテクチャは、デプロイされる前から時代遅れになった妥協の寄せ集めになってしまいます。 従来のシステム開発は破綻しています。図と実際にデプロイされるコードの間のギャップは時間を無駄にし、技術的負債を生み出し、的外れなシステムを提供します。しかし、そうである必要はありません。 私は最近、Kiro を使って金融取引システムを構築する際に、この課題に正面から取り組みました。これは、アーキテクチャの失敗が実際の金銭的損失やコンプライアンス上の悪夢につながるようなプロジェクトです。従来なら ER 図（エンティティ・リレーションシップ図）をデータベーススキーマに落とし込み、UML（統一モデリング言語）図をサービスインターフェースに変換するのに数週間かかるところを、Kiro のマルチモーダルなエージェントチャットを使うことで、ホワイトボードに描いたスケッチが数日で本番コードに変わりました。 Kiro がどのように視覚的な図とコード、ドキュメントを同時に処理することで、私の開発プロセスを根本から変えたのか。そして、あなたのプロセスもどう変えられるのかをご紹介します。 ホワイトボードの写真から TypeScript モデルへ 私はほとんどのプロジェクトと同様に、ホワイトボードと数本のマーカーから始めました。私がスケッチした ER 図 は、金融取引システムの中核となるエンティティを示していました。口座に接続されたユーザーがポジションを保持し、注文を実行して取引が行われます。そして、それらすべてがリアルタイムの市場データによって支えられています。 ここで Kiro のマルチモーダル機能が真価を発揮します。私は図を手動で変換する代わりに、ホワイトボードの写真を直接 Kiro にアップロードし、構築したいものについて会話を始めました。 Kiro は単に画像を見るだけでなく、手描きの図で表現されたエンティティ、関係、ビジネスロジックを理解しました。数分以内に、視覚的な入力を分析し、私が描いたものだけでなく、実際の金融取引システムに必要な暗黙の要件を捉えた包括的な仕様を作成しました。 視覚的な図は Kiro に構造的なコンテキストを提供してくれました。そして、チャットでの会話を通じて、どの図でも捉えることのできないビジネスのニュアンスを追加できました。私たちはコンプライアンスと規制要件、レイテンシに対する期待値、セキュリティの考慮事項について議論しました。やり取りのたびに、Kiro は私の元の視覚的設計と完璧な整合性を保ちながら仕様を更新してくれました。 ここで Kiro のマルチモーダルアプローチがその価値を証明します。Kiro は私の ER 図を受け取り、ホワイトボードのスケッチに対応する実際の TypeScript モデルを生成しました。生成されたコードは構文的に正しいだけでなく、元の図で暗示されていたビジネスロジック、関係、制約も含んでいました。User、Account、Order、Trade、Position などのエンティティは、適切な検証、関係、メソッドを持つ完全に形成された TypeScript クラスになりました。 途中で Kiro に作成するように頼んで生成されたクラスとデータベーススキーマを見ると、ホワイトボードに描いた単純な ER 図がプロダクション対応のシステムにどう進化したかがわかりました。最初は考えていなかった追加のオブジェクトタイプとの関係まで発見されました。たとえば、監査証跡、ユーザー権限、ポートフォリオ階層、実際の金融取引システムに不可欠な規制コンプライアンスフィールドなどです。 アーキテクチャの議論からインフラストラクチャ図へ 金融取引システムのスケーラビリティ、セキュリティ、デプロイ要件についての会話に基づいて、Kiro は包括的なクラウドに依存しない Kubernetes アーキテクチャを作成しました。この計画とともに、Kiro はシステムアーキテクチャを視覚化する Mermaid 図を含むドキュメントを作成しました。図は有益でしたが、読みやすさを向上させ、さまざまな表示プラットフォームでより良いスケーリングを可能にするために、SVG 形式に変換するよう Kiro に依頼しました。 Kiro のアーキテクチャ設計は、金融取引システム特有のパフォーマンスとコンプライアンス制約に対処しました。低レイテンシ取引サービスは、CPU ピニングと最適化されたネットワーク構成を特徴とする専用ノードプールにデプロイされました。データ層は、複数のアベイラビリティゾーンに分散された StatefulSets で実行される PostgreSQL と TimescaleDB を通じて高可用性を実現しました。イベント駆動メッセージングは、注文処理とリアルタイム市場データストリーミングに Kafka を使用し、包括的なセキュリティはネットワークポリシー、ポッドセキュリティ標準、シークレット管理のための HashiCorp Vault を実装しました。システムは、改変不能なの監査ログ、データレジデンシー制御、自動コンプライアンス監視を通じて規制コンプライアンスを念頭に置いて設計されました。 Kiro は、金融取引システムがデプロイ環境間での移植性を必要とすることを理解していました。設計されたアーキテクチャは、Amazon EKS (AWS)、Google Kubernetes Engine (Google Cloud)、Azure Kubernetes Service (Azure)、またはオンプレミス Kubernetes クラスターで変更なしに実行され、クラウドに依存しないままコンテナ化されたアプリケーションの業界ベストプラクティスを組み込んでいます。 このアーキテクチャ図は次のフェーズのインプットになりました。視覚的な Kubernetes アーキテクチャと議論のコンテキストの両方を使用して、Kiro はアーキテクチャの決定を実装する完全な Kubernetes マニフェストを生成しました。生成された Infrastructure as Code（IaC）には、コンプライアンスと環境管理のための適切なラベリングを持つ名前空間の組織、各コンポーネントに最適化されたアンチアフィニティルールとリソース制限を持つサービスデプロイメント、永続ボリューム要求を持つデータベースの StatefulSet 構成が含まれていました。ネットワークポリシーはサービス間のマイクロセグメンテーションを実装し、金融ワークロード向けにカスタムメトリクスを使用したHorizontal Pod Autoscalerが設定されました。Horizontal Pod Autoscaler がありました。これらすべてが Kubernetes のベストプラクティスに従ってセキュリティを確保していました。 生成された Kubernetes リソースには、本番環境対応の構成が含まれていました。たとえば、Pod Disruption Budget、リソースクォータ、モニタリング用のアノテーションなどです。Kiro は、私たちの上流のアーキテクチャ設計に関する会話を、クラウドネイティブのベストプラクティスに則りながら、特定の要件にも対応したデプロイ可能なインフラストラクチャへと変換してくれました。 マルチモーダルの利点と結果 このアプローチが非常に強力だった理由は、Kiro が画像を処理できるという点だけではありません。Kiro は視覚的な図を理解し、会話のコンテキストを維持し、生成されたコードファイルを参照しながら、これらすべての異なる入力タイプにわたって一貫性を保つことができたのです。そして同時に、実装の細部を超えて考えるよう私に問いかけてくれました。 従来の AI 開発ツールでは、各フェーズで別々の操作が必要でした。たとえば、図を解釈するツール、仕様書を生成する別のツール、コード生成のための 3 番目のツール、インフラストラクチャ計画のためのさらに別のツールなどです。そして、それぞれのツールを使う度に、引き継ぎによりコンテキストが失われ、不整合が生じ、手動での調整が必要になっていました。結果として、数週間の追加開発時間と、各ツールの出力が元の設計意図から逸脱することによる大幅な変更が発生していました。 Kiro のエージェントベースのアプローチは、開発プロセス全体を通じてトレーサビリティを維持できるようになります。3 日間、およそ約 15 時間の開発時間の後、私は最初に描いたビジュアル設計に一致する、ほぼ完成状態の金融取引システムが出来上がっていました。生成されたコードは、私がスケッチしたエンティティと関係を直接反映しており、会話を通じて明らかになったすべての複雑な追加の情報を取り込んでいました。各フェーズは次のフェーズに情報を引き継ぎつつ、元のホワイトボードのスケッチへのトレーサビリティを維持していました。Kiro はコンプライアンスやパフォーマンス、スケーラビリティといった複雑な技術的課題に対しても、私と一緒に取り組み、安心して解決へ導いてくれました。 最も重要なのは、Kiro のエージェントは単にコードを生成するだけではなかったという点です。設計上の判断に対して意見を述べたり、規制対応のための改善を提案したり、当初は想定していなかったパフォーマンスのボトルネックを特定したりしてくれました。このような共同作業のアプローチによって、さまざまなツールやセッションに分断されることなく、最初に描いた設計ビジョンを一貫して維持することができました。 これからはマルチモーダル この経験は、「AI エージェントが複数のタイプの入力を同時に理解し処理できるときに、どれほどの可能性があるか」を示しています。ホワイトボードの写真から生成されたコード、アーキテクチャ図からインフラストラクチャ構成まで、各ステップは設計の整合性を維持しながら前のステップの上に構築されます。 もし、せっかくの美しい設計とは切り離された実装になるのを見るのにうんざりしているなら、マルチモーダル開発をぜひ試してください。手描きの図から始めて、Kiro にアップロードし、視覚的な設計を理解させ、プロダクションまで一貫してその整合性を維持するのを手伝ってもらいましょう。これからの開発は「ビジュアル設計」と「コード生成」のどちらかを選ぶのではありません。両方をシームレス扱える AI を活用し、最初に描いたビジョンを損なうことなく、そのままプロダクションまで無傷で届けられる未来が始まっています。 図からデプロイまでの道のりをスムーズにする準備はできていますか？ Kiro を無料で始めて 、マルチモーダル開発をぜひ自分で体験してみてください！自分の図をアップロードするだけで、視覚的な設計から動作するコードへのシームレスな移行を体験できます。 X や LinkedIn であなたの体験をぜひシェアしてください。 Discord コミュニティ に参加して、マルチモーダル開発を使って作業の流れを変革している他の開発者とつながりましょう。 設計と実装の間のギャップはもう存在する必要がありません。マルチモーダル AI を使えば、あなたの図はそのままコードになり、あなたのビジョンはこれまでよりも速く、より正確に現実のものになります。 翻訳は App Dev Consultant 宇賀神が担当しました。

本記事は、2025 年 10 ⽉ 9 ⽇に公開された Automate governance of Amazon Quick Suite features using custom permissions を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 Amazon QuickSight は、2025 年 10 月 9 日に Amazon Quick Suite へと進化し、単一の BI 製品から、ビジネスインサイト、リサーチ、自動化のための AI エージェントを含む包括的なスイートへと拡張され、統合されたエクスペリエンスを提供します。Quick Suite は、セキュリティとユーザーアクセスポリシーを維持しながら、ユーザーがよりスマートかつ迅速に作業できるよう支援します。あらゆるスキルレベルのビジネスユーザーが、数日ではなく数分で関連するデータソース全体から回答を見つけ、自然言語でデータを分析し、洗練されたビジュアライゼーションを作成し、ツールを切り替えることなくインサイトに基づいてすぐに行動し、あらゆるタスクを自動化できます。これらの機能強化の中核にあるのは、構造化データソースと非構造化データソースの統合であり、これが 強力な新機能 を推進しています。 Quick Suite は、洗練された権限管理システムを提供します。アカウント、ロール、ユーザーレベルにまたがるこのマルチティアアプローチにより、組織は特定のニーズに合わせた正確なアクセス制御を実装できます。現在のアーキテクチャの主要な機能強化の 1 つにより、管理者は最小権限の原則を適用し、シームレスなユーザーエクスペリエンスを維持しながら、アカウントレベルで特定の機能へのユーザーアクセスを制限できるようになりました。きめが粗い制御、きめ細やかな制御の両方を提供することで、Quick Suite は、エンタープライズグレードのセキュリティとコンプライアンス基準を遵守しながら、最新の AI イノベーションを自信を持って採用できるよう企業を支援します。このイノベーションと制御のバランスにより、Quick Suite は、現代のデータ分析と AI 駆動の意思決定の複雑さに対応する組織にとって、極めて重要なツールとして位置づけられています。 この記事では、カスタムパーミッションを使用してアカウントレベルで機能レベルの制限をプログラムで実装する包括的なガイドを提供します。これにより、組織は生成 AI の最新イノベーションを採用しながら、エンタープライズグレードのセキュリティ、コンプライアンス、制御をサポートできます。新規および既存の Quick Suite アカウントサブスクリプションの両方で、アカウントレベルで AI ベースの機能をオフにするためのカスタムパーミッションの適用方法について説明します。 ソリューション概要 このソリューションは、Quick Suite と以下の AWS サービスを使用して、AWS アカウントにカスタムパーミッションを適用します。 AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を可能にするサービスです。 AWS Management Console 、 AWS Command Line Interface (AWS CLI)、AWS SDK および API を通じて実行されたアクションを含む、AWS アカウントで実行されたアクションを記録します。 Amazon EventBridge は、イベントを使用してアプリケーションコンポーネントを接続するサーバーレスサービスで、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。 イベントに一致するルールを作成し、1 つ以上のターゲット関数またはストリームにルーティングできます。 AWS Lambda は、サーバーのプロビジョニングや管理なしに、アプリケーションやバックエンドサービスのコードを実行できるサーバーレスのイベント駆動型コンピューティングサービスです。 200 以上の AWS サービスや Software as a Service (SaaS) アプリケーションから Lambda をトリガーでき、使用した分だけ料金を支払います。 AWS CloudFormation は、宣言型言語でテンプレートを記述することで、AWS およびサードパーティのリソースをモデル化、プロビジョニング、管理できる Infrastructure as Code (IaC) サービスです。 AWS リソースのコレクションを単一のユニットとして作成および管理でき、反復可能な方法でインフラストラクチャを作成および維持することが簡単になります。 AWS Identity and Access Management (IAM) は、ユーザーの AWS リソースへのアクセスを安全に制御するのに役立ちます。 IAM を使用して、誰が AWS リソースを使用できるか (認証)、どのリソースを使用できるか、どのように使用できるか (認可) を制御できます。 詳細については、 IAM User Guide を参照してください。 シナリオ 1: 新規 Quick Suite アカウントサブスクリプション 次の図は、新しい Quick Suite アカウントサブスクリプションのソリューションアーキテクチャを示しています。 このソリューションアーキテクチャは CloudFormation スタックとしてパッケージ化されており、AWS アカウントに必要なリソースをデプロイします。これらのリソースは、新しい Quick Suite サブスクリプションの作成時にトリガーされる準備が整っています。サブスクリプションは、AWS CLI、コンソール、またはその他のプログラムによるアプローチを通じて作成できます。スタックをデプロイすると、EventBridge が 2 分ごとにルールをトリガーして Lambda 関数を実行します。このルールは、Quick Suite へのサブスクリプションが正常に完了した後に無効化されます。この関数は、パブリック Quick API を通じてアカウントレベルでカスタムパーミッションの作成と割り当てをオーケストレーションします。このコードを通じて作成される特定のカスタムパーミッションは、アカウントレベルで新しい Quick Suite AI 機能を無効化します。 このアプローチは、BI 専用の機能のための環境を用意したい場合や、新機能をより広範囲に採用するための評価中に一時的に新機能を無効にしたい場合に最適です。テスト目的など、異なるユーザーに異なるカスタム権限のセットを適用する方法の詳細については、 Establishing enterprise governance in Amazon Quick Suite using custom permissions を参照してください。 前提条件 以下の前提条件を満たしている必要があります: 既存の Quick Suite サブスクリプションがないこと AWS アカウントへの管理者アクセス権限 CloudTrail が有効化されていること EventBridge が有効化されていること CloudFormation によるリソースの作成 次の手順に従って、CloudFormation でリソースを作成します。 Launch Stack を選択して、アカウントレベルのカスタムアクセス許可を自動的に適用するために必要なリソースをプロビジョニングします。 Next を選択します。 スタックの名前 (例: custom-permissions-qs-stack ) を入力し、 Next を選択します。 各種リソースの IAM ポリシーとロールの作成を確認し、 次へ を選択します。 設定を確認し、 Submit を選択します。 シナリオ 2: 既存の Quick Suite アカウントサブスクリプション このセクションでは、既存の Quick Suite アカウントサブスクリプション用にデプロイする CloudFormation テンプレートを提供します。 前提条件 以下の前提条件を満たしている必要があります: 既存の Quick Suite サブスクリプション AWS アカウントへの管理者アクセス CloudFormation によるリソースの作成 以下の手順に従って、リソースを作成します。 Launch Stack を選択して、リソースをプロビジョニングします: Next を選択します。 スタックの名前 (例: quicksight-custom-permissions ) を入力し、 Next を選択します。 Lambda 関数の IAM ポリシーとロールの作成を確認し、 Next を選択します。 設定を確認し、 Submit を選択します。 CloudFormation テンプレートは、AWS アカウントに必要なリソースを作成します。スタックをデプロイすると、パブリック Quick API を通じてアカウントレベルでカスタムパーミッションの作成と割り当てを調整する Lambda 関数が自動的にトリガーされます。このコードを通じて作成される特定のカスタムパーミッションは、アカウントレベルで新しい Quick Suite AI 機能を無効にします。 ソリューションの検証 設定を検証するには、以下の手順を実行してください。 Quick Suite のホームページに移動し、すべての新しい AI 機能がオフになっていることを確認します。 または、管理者として、右上隅のユーザーアイコンを選択して Manage account ページに移動します。 ランディングページで、新しい AI 機能を制限するカスタムパーミッションがアカウントレベルで適用されていることを確認します。 これらの権限をさらにカスタマイズするには、 Manage を選択し、プロファイルの横にあるオプションメニュー (3 つのドット) を選択して、 Edit を選択します。 各機能が選択されていることを確認し、その特定の機能が制限されていることを示します。 クリーンアップ クリーンアップするには、CloudFormation スタックを削除して、スタック内にプロビジョニングされたリソースを削除します。 CloudFormation コンソールのナビゲーションペインで、 スタック を選択します。 作成したスタックを選択し、 削除 を選択します。 これにより、CloudTrail イベント、EventBridge ルール、Lambda 関数、および各リソースに関連するロールとポリシーが削除されます。 まとめ この投稿では、新規および既存の Quick Suite サブスクリプションの両方に対して、新しい AI 機能を制限するカスタムパーミッションをプログラムで適用する方法を示しました。このソリューションにより、これらの機能をアカウントレベルで自動的に無効化することが可能になります。アカウント内の異なるユーザーに異なるパーミッションセットを適用できます。たとえば、アカウント内のすべてのユーザーに展開する前にテストを行う指定されたユーザーセットを持つことができます。詳細については、 Establishing enterprise governance in Amazon Quick Suite using custom permissions を参照してください。 組織が Quick Suite 内で AI を活用した分析と自動化機能を採用し続ける中、堅牢なカスタムパーミッションフレームワークは、イノベーションを安全に、そして組織のガバナンス要件に沿って進めることを支援します。このアクセス制御への包括的なアプローチにより、Quick Suite は単なる強力な分析サービスではなく、組織のニーズとともに成長する、安全でエンタープライズ対応のソリューションとして位置づけられます。 カスタムパーミッションを適切に設定することで、組織が Quick Suite の高度な機能の使用を拡大する際に、セキュリティ体制の強化、規制コンプライアンス、運用上の信頼性を実現できます。詳細については、 Creating a custom permissions profile in Amazon Quick Suite を参照してください。 ご質問やフィードバックがございましたら、コメントをお寄せください。 さらなる議論や質問への回答を得るには、 Quick Suite Community をご確認ください。 著者について Srikanth Baheti は、Amazon Quick Suite の Specialized World Wide プリンシパルソリューションアーキテクトです。コンサルタントとしてキャリアをスタートし、複数の民間企業や政府機関で働いてきました。その後、PerkinElmer Health and Sciences および eResearch Technology Inc で勤務し、AWS サービスとサーバーレスコンピューティングを使用した高トラフィックの Web アプリケーションや、レポーティングプラットフォーム向けの高度にスケーラブルで保守性の高いデータパイプラインの設計と開発を担当しました。 Andy Son は、Amazon Quick Suite のソリューションアーキテクトです。AWS に入社する前は、プリセールスエンジニアとして、さまざまな業界のクライアントと協力し、アナリティクスの導入と実装を成功に導いてきました。 Ashok Dasineni は、Amazon Quick Suite のソリューションアーキテクトです。AWS に入社する前は、銀行および金融分野のクライアントや組織と協力し、不正行為の調査と防止に注力していました。ビジネスプロセスの改善、コスト削減、収益増加のための革新的なソリューションを設計・実装し、世界中の企業がデータを通じて最高の可能性を達成できるよう支援してきました。 Vaidy Janardhanam は AWS のソリューションアーキテクトで、生成 AI ビジネスインテリジェンスに注力しています。Vaidy は、お客様がクラウド上でデータおよび分析アプリケーションを設計・構築するのを支援しています。AWS サービスを使用して、世界中のお客様の本番環境への移行を加速してきました。

本記事は、2025 年 10 ⽉ 9 ⽇に公開された Establishing enterprise governance in Amazon Quick Suite using custom permissions を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 Amazon QuickSight は、2025 年 10 月 9 日に Amazon Quick Suite へと進化し、単一の BI 製品から、ビジネスインサイト、リサーチ、自動化のための AI エージェントを含む包括的なスイートへと拡張されます。Quick Suite は、セキュリティとユーザーアクセスポリシーを維持しながら、ユーザーがよりスマートかつ迅速に作業できるよう支援します。あらゆるスキルレベルのビジネスユーザーが、数日ではなく数分で関連するデータソース全体から重要な情報を見つけ、自然言語でデータを分析し、洗練されたビジュアライゼーションを作成し、ツールを切り替えることなくインサイトに基づいてすぐに行動し、あらゆるタスクを自動化できます。これらの機能強化の中核にあるのは、構造化データと非構造化データソースの統合であり、スイートの強力な新機能を推進しています。 今日の急速に進化する生成 AI の状況において、企業は環境内でユーザーが利用できる機能や能力に対する堅牢なガバナンスと正確な制御をますます重視しています。Amazon QuickSight が Amazon Quick Suite へと進化し、幅広いエージェント型 AI 機能を導入する中で、安全でスケーラブルかつ柔軟なアクセス管理の必要性がこれまで以上に重要になっています。 が これに対処するため、Quick Suite では、Manage Quick Suite コンソールからアクセス可能な、強化された カスタム権限 コントロールを導入しています。これらのコントロールは、きめが粗い制御ときめ細やかな制御の両方のアクセス制限をサポートしており、管理者がシームレスで生産的なユーザーエクスペリエンスを維持しながら、特定の機能へのユーザーアクセスを制限することで、最小権限の原則を実施するのに役立ちます。 Quick Suite の権限は、アカウントレベル、ロールレベル、ユーザーレベルの 3 つの階層レベルで構成されています。明確な優先順位モデルにより、ユーザーレベルの権限はロールレベルの権限を上書きし、ロールレベルの権限はアカウントレベルの権限よりも優先されます。この柔軟なアーキテクチャにより、管理者は組織の特定のニーズに合わせてセキュリティポリシーをカスタマイズできます。 このブログ記事では、カスタムパーミッションを使用して、機能レベルおよびオペレーションレベルのガバナンスを実装するための包括的なガイドを提供します。これにより、組織は生成 AI の最新イノベーションを自信を持って採用しながら、エンタープライズグレードのセキュリティ、コンプライアンス、制御を提供できます。 カスタムパーミッションのメリット Amazon Quick Suite のカスタムパーミッションは、セキュリティの強化、ガバナンスの向上、ユーザーエクスペリエンスの改善といった戦略的な利点を提供します。これらのメリットを理解することで、管理者はこの機能を効果的に活用する方法について、情報に基づいた意思決定を行うことができます。 主な利点は次のとおりです。 セキュリティとコントロール 最小権限の原則 : ユーザーアクセスを必要な機能のみに制限します。 きめ細かなアクセス制御 : 機能の利用可能性を正確に制御します。 マルチレベル管理 : アカウント、ロール、ユーザーレベルで権限を制御します。 ニアリアルタイムの適用: カスタム権限は適用後すぐに有効になるため、サインアウトして再度サインインする必要はありません。 柔軟性とスケーラビリティ 階層的なオーバーライド : ユーザー権限はロール権限をオーバーライドし、ロール権限はアカウント権限をオーバーライドします。 対象を絞った例外 : グループ全体に影響を与えることなく、個々のユーザーに対して特定のアクセスルールを作成します。 動的な調整 : ビジネスニーズの変化に応じて権限を変更します。 エンタープライズ機能 包括的なカバレッジ : すべての主要な機能 (Flows、Research、Chat Agents、Dashboards) へのアクセスを制御します。 複数の実装オプション : コンソールインターフェイスまたは CLI や API を使用してプログラムで管理します。 運用上のメリット バランスの取れたイノベーション : 適切なコントロールを維持しながら、高度な機能の使用を保護します。 一貫した適用 : 大規模な組織全体でセキュリティポリシーを統一的に適用します。 生産性の維持 : ユーザーエクスペリエンスを損なうことなくアクセスを制限します。 これらのメリットにより、組織は適切なガバナンスを維持しながら、Amazon Quick Suite の機能を安全に使用できます。 一般的なユースケース Quick Suite でカスタムパーミッションを活用するユースケースの例には、以下のようなものがあります。 アカウントレベルで、すべての新しい Quick Suite 機能にグローバルな制限を適用する。 特定のユーザーセットに対して新機能へのアクセスを許可し、他のすべてのユーザーに対してはアクセスを制限する。このアプローチにより、より広範な展開の前に、特定のユーザーセットによる新機能の制御されたテストと評価が可能になります。 アカウントレベルで特定の機能を制限するとともに、ロールレベルで新しいデータソースを作成する機能など、より詳細な機能を制御する。 カスタム権限管理の前提条件 Amazon Quick Suite の管理者は、自動的にカスタムパーミッションを管理する権限を取得するわけではありません。これは、特に役割の分離とアクセス制御が重要なエンタープライズ環境において、カスタムパーミッション管理を厳格に制御するために設計された意図的なセキュリティ対策です。適切な AWS Identity and Access Management (IAM) パーミッションがない場合、Quick Suite 管理者は、カスタムパーミッション設定にアクセスするために必要な IAM パーミッションがロールに不足していることを示すブロックメッセージに遭遇します。 Amazon Quick Suite 内でカスタムパーミッションを効果的に管理するには、次の前提条件を満たす必要があります。 Quick Suite Admin Pro または Admin ロール: Quick Suite Admin または Admin Pro ロールが割り当てられている必要がありますが、これだけではカスタム権限を管理するアクセス権は付与されません。この機能には、追加の権限 (以下の通り) が必要です。 コア IAM 権限: IAM ユーザーまたはロールは、Quick Suite 内でカスタム権限を管理するために、以下のコア権限を持っている必要があります。これらの権限は明示的に付与する必要があり、Quick Suite 内でカスタム権限プロファイルを管理するために不可欠です。 {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "quicksight:CreateCustomPermissions",                 "quicksight:DeleteCustomPermissions",                 "quicksight:DescribeCustomPermissions",                 "quicksight:ListCustomPermissions",                 "quicksight:UpdateCustomPermissions"              ],             "Resource": "arn:aws:quicksight:*:*:*"         }      ] } 注意: インターフェースには Quick Suite と表示されますが、すべての API オペレーションと IAM アクセス許可は、既存の Amazon QuickSight の命名規則を引き続き使用します。IAM ポリシーの設定や AWS CLI および API 呼び出しを使用する際には、この違いを念頭に置くことが重要です。 IAM フェデレーションまたは IAM Identity Center : 組織の構成に応じて、AWS アカウント所有者は必要なコアカスタムパーミッションを作成し、これらのパーミッションを特定のグループとユーザーに割り当てる必要があります。パーミッションは IAM フェデレーションまたは IAM Identity Center で管理できます。 IAM フェデレーションの場合、必要なコアカスタムパーミッションを持つ特定の IAM ロールを Quick Suite 管理者に割り当てます。承認されると、これらの管理者はすべてのレベル (アカウント、ロール、ユーザー) でカスタムパーミッションを設定できます。 IAM Identity Center の場合、上記のパーミッションを持つ アクセス許可セット を作成し、カスタムパーミッションを管理するための適切なパーミッションを持つユーザーまたはグループに割り当てます。 以下は、IAM Identity Center が有効化されたアカウントのユーザーから見たアクセスポータルのスクリーンショットです。このユーザーには、必要なコアカスタムパーミッションを含む aqs-custompermission パーミッションセットが割り当てられています。 これらのアクセス許可セットは、AWS アクセスポータルで利用可能なロールとして表示されます。複数のアクセス許可セットに割り当てられたユーザーは、アクセスポータルにサインインし、アカウントを選択して、スクリーンショットに示されているように割り当てられたアクセス許可セットを選択できます。管理者ユーザーは、Quick Suite にアクセスし、Quick Console に移動して、エンタープライズ要件を満たすカスタムアクセス許可を設定できます。 Manage Quick Suite Console: Custom permissions へのアクセスは、ショートカットを使用するか、コンソールの左パネルにある Permissions セクションに移動することで管理できます。 複数レベルにわたるカスタムパーミッション 管理者は、カスタム権限プロファイルを作成して適用することで、Amazon Quick Suite の機能へのアクセスを管理できます。これらの権限は、アカウントレベルで適用して Quick Suite 全体の機能へのきめが粗いアクセスを管理することも、ユーザーまたはロールレベルで適用して特定の機能へのきめきめ細やかなアクセスを制御することもできます。 ベストプラクティスとして、管理者はアカウントレベルで Chat Agents、Integrations、Flows、Automate、Knowledge Base、Spaces、Research、Dashboards、Analyses などの機能を制限または無効化できます。ユーザーまたはロールレベルでは、管理者は Quick Suite 内の個々の機能を制限するために、より詳細な制御を定義できます。 設定可能な機能の完全なリストについては、 カスタムパーミッション のドキュメントを参照してください。 それでは、カスタムパーミッションを使用して機能や能力を管理および制限する方法を見ていきましょう。まず Quick Suite コンソール UI を使用し、次に API を使用します。 Flows 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Quick Flows を無効にすることができます。 アカウント内の Flows の制限 Amazon Quick Suite アカウントのすべてのユーザーに対して Flows の使用を制限するには、次の手順に従ってください。 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account、Permissions、Custom permissions を選択します。 New profile を選択します。 Flows チェックボックスを選択し、カスタム権限プロファイルの名前 (例: Restrict-Flows ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 適用されると、Quick Suite アカウントのすべてのユーザーに対して Flows が制限されます。 制限付き Flows の体験 アカウントレベルで Flows が制限されている場合の影響は次のとおりです。 ユーザーエクスペリエンスへの影響 Flows オプションが左側のナビゲーションメニューに表示されなくなり、エンドユーザーにとってこの機能の可視性が失われます。 ユーザーは、反復的なタスクを自動化するための新しい Flows を作成できなくなります。 チャットフッターの Flows メニューアイコンが非表示になり、この機能へのエントリーポイントが削除されます。 ユーザーは既存の Flows にアクセスしたり実行したりできなくなり、Flows とのすべてのユーザーレベルのインタラクションが事実上無効になります。 サービス全体への影響 Flows がアカウントレベルで制限されると、ユーザーまたはロールレベルでのより具体的な機能によって上書きされない限り、アカウント全体のすべてのユーザーに対してこの機能が完全に無効になります。 Flows 関連のすべての機能 (作成、実行、アクセス) が一律に制限され、サービス全体で制限が一貫して適用されます。 Automate 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Automate を無効にできます。 アカウントでの Automate の制限 Amazon Quick Suite アカウントのすべてのユーザーに対して Automate の使用を制限するには、次の手順に従ってください。 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Automate チェックボックスを選択し、カスタム権限プロファイルの名前 (例: Restrict-Automations ) を入力し、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限付き Automate の使用体験 Automate がアカウントレベルで制限されている場合の影響は次のとおりです: ユーザーエクスペリエンスへの影響 左側のナビゲーションメニューから Automate オプションが削除され、ユーザーは自動化インターフェースにアクセスできなくなります。 ユーザーは新しい自動化プロジェクトやタスクを作成できなくなります。 既存の自動化タスクやプロジェクトへのアクセスがブロックされ、ユーザーはそれらを実行できなくなります。 ユーザーは以前に作成した自動化タスクやプロジェクトを変更できなくなります。 実行されたタスクの実行ステータスの確認を含む、自動化のパフォーマンスを監視する機能が非表示になります。 ナビゲーションパネルの Automate セクションが完全に非表示になり、この機能へのすべてのエントリーポイントが削除されます。 サービス全体への影響 Automate 機能がアカウントレベルで制限されると、アカウント全体のすべてのユーザーに対してこの機能が完全に無効化されます。 自動化に関連するすべての機能 (作成、変更、実行、監視) が体系的に無効化されます。 これにより、管理上の制限への完全なコンプライアンスが確保され、サービス全体で自動化関連機能とのあらゆる形式のインタラクションが防止されます。 スペース 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Spaces を無効にできます。 アカウント内の Spaces の制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Spaces チェックボックスを選択し、カスタム権限プロファイルの名前 (例: restrict-spaces ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限付き Spaces の体験 アカウントレベルで Spaces が制限されている場合の影響は次のとおりです。 ユーザーインターフェースへの影響 左側のナビゲーションメニューとすべてのインターフェースから Spaces オプションが削除されます。 ユーザーは新しいスペースを作成したり、既存のスペースにアクセスしたりすることができなくなります。 サービス全体への影響 Space 内のカスタムナレッジハブ組織機能が利用できなくなります。 すべてのコラボレーティブワークスペースへのアクセスが制限されます。 Space 共有機能とコラボレーション機能が非表示になります。 チャットエージェント: チャットエージェントインターフェース内で Spaces オプションが表示されなくなります。 チャットアシスタント/エージェント内でリソースを選択するためのドロップダウンメニューに Spaces が含まれなくなります。 リサーチエージェント: リサーチエージェント内に Spaces を含めるオプションが利用できなくなります。 Spaces 機能がアカウント全体で完全に無効化されます。 アカウントレベルでの Spaces 機能のこの包括的な制限により、ユーザーは Spaces 機能のあらゆる側面を操作したり利用したりすることができなくなります。 次の GIF は、アカウントレベルの変更を適用する前の Spaces 機能を示しています。 次の GIF は、アカウントレベルの Spaces 制限が適用された後のエクスペリエンスを示しています。 アクション 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Quick Actions を制限できます。 アカウント内のアクションの制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Actions チェックボックスを選択し、カスタム権限プロファイルの名前 (例: restrict-actions ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限されたアクションの体験 Actions がアカウントレベルで無効化されている場合、サービス全体で以下の制限が適用されます: ユーザーインターフェースへの影響 Connections メニューの Integrations セクションから Actions タブが削除されます。 インターフェースメニューからすべてのアクション関連オプションが非表示になります。 新しい Actions の作成ができなくなります。 既存の Actions へのアクセスがブロックされます。 次のスクリーンショットに示すように、Quick Suite ブラウザ拡張機能内のすべてのアクションが呼び出せなくなります。 サービス全体への影響 制限はアカウント内のすべてのスペースに一律に適用されます。 チャットエージェントは Actions を呼び出すことができません。 Actions に関連する統合機能は無効になります。 Action は自動化タスクで利用できません。 Quick Dashboard の機能: Actions は Quick Dashboard のビジュアル内から利用できなくなります ダッシュボード内のテーブルビジュアルで Actions ベースのアラートを設定できません アカウントレベルの制限により、ユーザーが自動化されたアクションを設定、変更、または呼び出すことを防ぎ、包括的なサービス制御を確保します。これにより、システムの安定性を維持しながら、セキュリティコンプライアンスを保ちます。 チャットエージェント 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Chat Agents を無効にすることができます。 アカウント内のチャットエージェントの制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Chat Agents チェックボックスを選択し、カスタムアクセス許可プロファイルの名前 (例: Restrict-Chat-Agents ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の省略記号) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限付きチャットエージェントの体験 Chat Agents がアカウントレベルで無効化されている場合、サービス全体で以下の制限が適用されます。 ユーザーエクスペリエンスへの影響 左側のナビゲーションパネルから Chat Agents オプションが削除されます。 Quick Suite 内のデフォルトの AI チャットアシスタントである My Assistant がブロックされます。 新しいチャット会話の開始が制限されます。 既存のチャット履歴へのアクセスが無効になります。 チャットインターフェースが完全に非表示になります。 保存されたチャット設定にアクセスできなくなります。 Quick Suite ブラウザ拡張機能内のすべてのカスタムチャットエージェントが利用できなくなります。 Quick Suite ブラウザ拡張機能内の My Assistant エージェントが利用できなくなります。 サービス全体への影響 チャット機能がシステムレベルで無効化され、すべてのユーザーに影響を与え、サービス全体の関連コンポーネントが無効化されます。 研究 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して Research Agent を無効にすることができます。 アカウント内での Research Agent の制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Research チェックボックスを選択し、カスタム権限プロファイルの名前 (例: Restrict-Research ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限された Research Agent の体験 アカウントレベルで Research が無効になっている場合、サービス全体で以下の制限が適用されます: ユーザーエクスペリエンスへの影響 すべてのユーザーの左側のナビゲーションパネルから Research オプションが削除されます。 ユーザーは新しいリサーチクエリを開始できなくなります。 ユーザーは以前のリサーチ履歴にアクセスできなくなります。 この機能は表示されなくなり、アクセスできなくなるため、一貫したユーザーエクスペリエンスが保証されます。 ユーザーは共有されたリサーチレポートにアクセスできなくなります。 サービス全体への影響 Research Agent はアカウントレベルで完全に無効化されます。 すべての AI を活用したリサーチ機能がサービス全体で無効化されます。 システムレベルの強制により、ユーザーはこの機能にアクセスできなくなります。 分析 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対して分析機能を無効にすることができます。 アカウント内の分析の制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Analyses チェックボックスを選択し、カスタム権限プロファイルの名前 (例: Restrict-Analyses ) を入力して、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の省略記号) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限付き分析の体験 アカウントレベルで分析が無効になっている場合、サービス全体で以下の制限が適用されます: ユーザーインターフェースへの影響 Quick Sight メニューの左側のナビゲーションパネルで Analyses オプションが利用できなくなります。 データセットからの Create Analyses オプションが無効になります。 既存の Analyses がユーザーに利用できなくなります。 Analyses への直接 URL アクセスがブロックされます。 Dashboard の Save as Analyses オプションが利用できなくなります。 共有フォルダまたはマイフォルダ内の Analyses が無効になります。 サービス全体への影響 Analyses 機能がアカウント全体で完全に無効になります。 すべての分析の作成、編集、表示機能がブロックされます。 ダッシュボードは分析から構築されますが、分析へのアクセスを制限しても、既存のダッシュボードの機能には影響しません。ユーザーは、ダッシュボードの作成に使用された基礎となる分析にアクセスできなくても、通常どおりダッシュボードを表示して操作できます。この制限により、公開されたダッシュボードコンテンツへのアクセスは継続しながら、すべての分析関連機能をユーザーが利用できないようにします。 ダッシュボード 管理者は、Amazon Quick Suite のアカウントレベルで、すべてのユーザーに対してダッシュボードの作成と編集機能を無効にすることができます。 アカウント内のダッシュボードの制限 必要な IAM ポリシーが有効になっている管理者ユーザーとして Amazon Quick Suite にサインインします。 Quick Suite で、右上のユーザープロファイルアイコンをクリックし、 Manage Quick Suite を選択します。 左側のナビゲーションで、 Manage Account, Permissions, Custom permissions を選択します。 New profile を選択します。 Dashboards チェックボックスを選択し、カスタム権限プロファイルの名前 (例: Restrict-Dashboards ) を入力し、 Create を選択します。 Profiles ページにリダイレクトされます。 作成したプロファイルを見つけ、メニューアイコン (縦の三点リーダー) を選択し、 Set as account profile を選択します。 Confirm account profile restrictions ダイアログで、 confirm と入力し、 Restrict & Save をクリックします。 制限付きダッシュボードの使用体験 アカウントレベルで Dashboards が無効になっている場合、サービス全体で以下の制限が適用されます: ユーザーインターフェースへの影響 Quick Sight メニューの左側のナビゲーションパネルから Dashboards オプションが削除されます。 ユーザーは既存のダッシュボードにアクセスしたり、新しいダッシュボードを公開したりできなくなります。 ダッシュボードへの直接 URL アクセスがブロックされます。 お気に入りからダッシュボードオプションが削除されます。 既存または新規の分析において、ダッシュボードを公開するオプションが削除されます。 ダッシュボードの構築に使用されたデータセットは、使用状況タブからダッシュボードにリダイレクトできなくなります。 サービス全体への影響 制限はアカウント内のすべてのスペースに一律に適用され、既存のダッシュボードはスペースからアクセスできなくなります。 Spaces : スペース内のダッシュボードが制限されます。 Research : ダッシュボードをスペースを通じてソースとして使用できなくなります。 Scenarios : Data to Insights シナリオでは、Quick Sight ダッシュボードからデータを選択するオプションは表示されますが、 Find data を選択してもダッシュボードにアクセスできません。ダッシュボードがない場合でも、 Upload file オプションを使用して Scenarios でデータを探索することができます。 Stories : データストーリーを構築する際、ダッシュボードにアクセスできません。その結果、既存のデータストーリーは作成時に使用された元のビジュアルを表示しませんが、その他のすべてのコンテンツは影響を受けません。ピンボードから保存されたビジュアルを使用してデータストーリーを作成し続けることができます。 Dashboards 機能はアカウント全体で完全に無効化されます。この制限により、すべてのダッシュボード関連機能がユーザーにアクセス不可能となり、ダッシュボードアクセスに対する包括的な制御を維持しながら、Quick Suite の他の機能を通じた代替的なデータ探索方法を保持します。 機能レベルの制限 (ロールとユーザーレベル) 管理者は、すべてのレベルで機能レベルの制限を適用できます。デモンストレーションの目的で、ここではロールレベルとユーザーレベルの設定に焦点を当てます。以下の例は、管理者が機能セット全体を無効にすることなく、より広範な機能内の特定の関数を制限する方法を示しています。 カスタムプロファイルを作成し、Quick Sight 機能制限の下にある Creating or updating all data sources オプションを選択して、他の機能を無効にすることなく機能を非表示にします。 API を使用して、 Author ロール にカスタムプロファイルを適用します。 現在、権限はコンソール UI ではなく、API を使用してロールまたはユーザーレベルでのみ割り当てることができます。ロールレベルの権限を適用する API の詳細については、 ロールのカスタム権限を更新する セクションを参照してください。 Author プロファイルを使用してログインし、カスタム権限を検証します。 ロールレベルでの機能制限 Author ロールのデータソース作成を制限することを検討してください。 この制限を持つ Author としてログインした場合: 左パネルの Datasets メニューの data source タブにある Create data source オプションがブロックされます。 左パネルのメニューで Data source タブの Datasets を選択すると、 Create data source オプションが利用できなくなり、Author ロールを持つユーザーが新しいデータソースを作成できなくなります。 Author は既存のすべてのデータソースにアクセスできますが、外部アプリケーションやデータベースから新しいデータソースを作成する権限はありません。 ユーザーレベルでの機能制限 このアプローチは、管理者が特定の機能へのアクセスを定義されたユーザーセットに制限する必要がある場合に特に有用です。アカウントレベルで制限を適用し、ユーザーレベルで選択的にアクセスを許可することで、承認されたユーザーに対する例外を維持しながら、より広範なアクセスを拒否できます。 個々のユーザーに対して Chat Agents の作成を制限するには: カスタムプロファイルを作成し、Quick Suite の機能制限で「Create Chat Agents」オプションを選択することで、新しいエージェントの作成を制限しつつ、共有されたエージェントとのチャットは可能にします。 API を使用して、特定のユーザーにカスタムプロファイルを適用します。 現在、権限はコンソール UI ではなく、API を使用してロールまたはユーザーレベルでのみ割り当てることができます。ロールレベルの権限を適用する API の詳細については、以下の「 ユーザーのカスタム権限を更新する 」セクションを参照してください。 同じユーザープロファイルでサインインし、カスタムパーミッションを検証します ユーザーがこの制限付きでログインした場合: Chat Agents  が左パネルメニューに表示され、正常に表示されます。 ユーザーはすべてのチャットエージェントのリストを表示し、既存のものにアクセスできますが、チャットエージェントウィンドウにアクセスしている間は Create Chat Agents オプションが利用できなくなります。 ユーザーは既存のすべての Chat Agents にアクセスできますが、新しいチャットエージェントを作成する権限はありません。 権限が適用される優先順位 Quick Suite アカウントでカスタムパーミッションを効果的に実装するには、異なるパーミッションレベルがどのように相互作用し、互いにオーバーライドするかを理解することが重要です。パーミッションシステムは、複数のカスタムパーミッションセットがユーザーに適用される可能性がある場合に、どのパーミッションが優先されるかを決定する明確な階層構造に従っています。 ユーザーレベルのカスタム権限 : 個々のユーザーに直接適用されるカスタム権限は、権限階層において最も高い優先度を持ちます。これらの権限は、その特定のユーザーに対するロールレベルの権限やアカウントレベルの権限を上書きするため、管理者はロール全体の権限を変更することなく、特定のユーザーに対して例外を作成できます。 ロールレベルのカスタム権限 : ロール (Admin、Admin Pro、Author、Author Pro、Reader、または Reader Pro) に適用されるカスタム権限は、それらのロールのデフォルト権限よりも優先されます。カスタム権限プロファイルがロールに割り当てられると、そのロールを持つすべてのユーザーは、ユーザーレベルのカスタム権限で上書きされない限り、それらの制限の対象となります。 アカウントレベルの権限 : 各ロールに関連付けられた標準権限は、最も低い優先度を持ちます。これらの権限は、カスタム権限 (ユーザーレベルまたはロールレベル) が指定されていない場合、アカウント内のすべてのロールに適用されます。 大企業である AnyCompany Inc. が Quick Suite でカスタムパーミッションを実装し、さまざまな組織レベルでアクセスを管理する例を考えてみましょう。この組織は、セキュリティ要件と特定のビジネスニーズのバランスを取るために、3 つの異なるパーミッションレイヤーを確立することを目指しています。 アカウントレベルでは、AnyCompany Inc. のガバナンスポリシーの一環として、Flow 機能が全社的に制限されています。しかし、ビジネスアナリストチーム (全員に Reader Pro ロールが割り当てられている) には、データ機密性プロトコルに沿って、Research と Chat Agents へのアクセスを制限するという追加の制限が必要です。ユーザーレベルでは、特定のビジネスアナリストである John Smith が特別プロジェクトのために昇格されたアクセス権を必要としており、これは権限を細かく設定できることを示しています。 結果として得られるカスタムパーミッション構造は、アカウント、ロール、ユーザーの各レイヤーが必要に応じてカスタマイズおよびオーバーライドできることを示しています。 John Smith の結果的なアクセス権限 (ユーザーレベル): Flows : アクセス可能 (アカウント制限のユーザーレベルでの上書き) Research : アクセス可能 (ロール制限のユーザーレベルでの上書き) Chat Agents : 既存のエージェントにアクセス可能 (ロール制限のユーザーレベルでの上書き) Create Chat Agents : 制限あり (特定のユーザーレベルでの制限) その他すべての機能 : 通常のアクセス Reader Pro ロールを持つユーザー (ロールレベル): Flows : アクセス可能 (アカウント制限のロールレベルでのオーバーライド) Research : 制限あり (ロールレベルでの制限) Chat Agents : 制限あり (ロールレベルでの制限) その他すべての機能 : 通常のアクセス その他すべてのユーザー (アカウントレベル): Flows : 制限あり (アカウントレベルのポリシーが適用されます) その他すべての機能 : 通常のアクセス パイロットフェーズの完了後、AnyCompany Inc は John Smith のカスタム権限プロファイルを更新することを決定しました。元のプロファイルは「Create Chat Agents」機能のみを制限していましたが、改訂されたプロファイルでは、進化するガバナンス要件に合わせて、より広範な制限が導入されています。更新されたカスタム権限プロファイルには、以下の制限が含まれています: フロー機能 リサーチ機能 チャットエージェントを許可 – 既存のエージェントへのアクセスを許可しながら、「チャットエージェントの作成」機能を制限し続けます 変更されたプロファイルが適用されると、John Smith は Flows と Research の両方へのアクセスを失い (以前は保持していた)、新しい Chat Agents の作成は引き続き制限されますが、既存の Chat Agents とその他すべての Quick Suite 機能へのアクセスは保持されます。以下は、John の更新されたアクセス権の概要です。 Flows : 制限あり (更新されたユーザーレベルの制限により、以前のアクセス権を失います) Research : 制限あり (更新されたユーザーレベルの制限により、以前のアクセス権を失います) Chat Agents : 既存のエージェントにアクセス可能 (アクセス権が維持されます) Create Chat Agents : 制限あり (以前の制限が継続されます) その他すべての機能 : 通常のアクセス プログラムによるアプローチを使用したカスタムパーミッション カスタムパーミッションは、AWS CLI または API を使用して実装することもできます。以下の例は、AWS CLI または API を使用して、Flow、Actions、Automate などの新機能や、既存の Quick Sight 機能を無効にする方法を示しています。 CLI を使用している場合は、次のコマンドを使用して詳細を取得します。 aws quicksight create-custom-permissions help すべてのカスタム権限プロファイルの一覧表示 新しいカスタム権限を設定する前に、既存のカスタム権限プロファイルと、Quick Account 内のさまざまなレベルで既に設定されている権限を確認してください。アカウント内のすべてのカスタム権限プロファイルをプログラムで一覧表示するには、次のように list-custom-permissions API を使用します。 注: 以下の例では、<<864571xxxxxx>> をご自身の AWS アカウント ID に置き換えてください。 aws quicksight list-custom-permissions --aws-account-id <<864571xxxxxx>> 4 つの異なるカスタムパーミッションを持つアカウントでコマンドを実行した後のサンプル出力: {     "CustomPermissionsList": [         {             "Arn": "arn:aws:quicksight:us-east-1:864571xxxxxx:custompermissions/deny-actions",             "CustomPermissionsName": "deny-actions",             "Capabilities": {                 "ExportToCsv": "DENY",                 "ExportToExcel": "DENY",                 "ExportToPdf": "DENY"             }         },         {             "Arn": "arn:aws:quicksight:us-east-1:864571xxxxxx:custompermissions/deny-chat-agents",             "CustomPermissionsName": "deny-chat-agents",             "Capabilities": {                 "CreateChatAgents": "DENY"             }         },         {             "Arn": "arn:aws:quicksight:us-east-1:864571xxxxxx:custompermissions/deny-all",             "CustomPermissionsName": "deny-all",             "Capabilities": {                 "ExportToCsv": "DENY",                 "ExportToExcel": "DENY",                 "ExportToPdf": "DENY"             }         },         {             "Arn": "arn:aws:quicksight:us-east-1:864571xxxxxx:custompermissions/res-action",             "CustomPermissionsName": "res-action",             "Capabilities": {                 "Action": "DENY"             }         }     ],     "Status": 200,     "RequestId": "8e2e3d34-5553-4477-a0e4-f081295eefe1" } カスタムパーミッションを使用したアクセス制限 Amazon Quick Suite でカスタム権限プロファイルを使用して、きめが粗い制御 (機能) またはきめ細やかな制御のアクセス (機能内の機能) を制御します。 カスタム権限プロファイルを作成します。 カスタム権限プロファイルを確認します。 適切なカスタム権限を割り当てます (アカウント、ロール、またはユーザーに対して)。 割り当てられたカスタム権限を確認します。 カスタム権限プロファイルの作成 create-custom-permissions API は、アカウント、ロール、またはユーザーレベルのプロファイルを含む、さまざまなスコープのカスタム権限プロファイルを作成するために使用されます。単一の機能、複数の機能に対する権限の定義、または Quick Suite や Quick Sight 内の特定の機能の制限をサポートしています。 以下の機能がサポートされています:           {             "Dashboard": "DENY",             "Analysis": "DENY",             "Automate": "DENY",             "Flow": "DENY",             "KnowledgeBase": "DENY",             "Action": "DENY",             "Space": "DENY",             "ChatAgent": "DENY",             "Research": "DENY"           } 次の機能がサポートされています。           {             "ExportToCsv": "DENY",             "ExportToExcel": "DENY",             "ExportToPdf": "DENY",             "PrintReports": "DENY",             "CreateAndUpdateThemes": "DENY",             "AddOrRunAnomalyDetectionForAnalyses": "DENY",             "ShareAnalyses": "DENY",             "CreateAndUpdateDatasets": "DENY",             "ShareDatasets": "DENY",             "SubscribeDashboardEmailReports": "DENY",             "CreateAndUpdateDashboardEmailReports": "DENY",             "ShareDashboards": "DENY",             "CreateAndUpdateThresholdAlerts": "DENY",             "RenameSharedFolders": "DENY",             "CreateSharedFolders": "DENY",             "CreateAndUpdateDataSources": "DENY",             "ShareDataSources": "DENY",             "ViewAccountSPICECapacity": "DENY",             "CreateSPICEDataset": "DENY",             "ExportToPdfInScheduledReports": "DENY",             "ExportToCsvInScheduledReports": "DENY",             "ExportToExcelInScheduledReports": "DENY",             "IncludeContentInScheduledReportsEmail": "DENY",             "PublishWithoutApproval": "DENY",             "UseBedrockModels": "DENY",             "CreateChatAgents": "DENY",             "UseAgentWebSearch": "DENY",             "PerformFlowUiTask": "DENY"                        } 以下のサンプル create-custom-permissions API 呼び出しは、エクスポート機能を制限するプロファイルを作成します。 aws quicksight create-custom-permissions --aws-account-id <<864571xxxxxx>> --custom-permissions-name deny-all-capabilities  --capabilities 以下は customperm.json ファイルの内容です。           {             "Dashboard": "DENY",             "Analysis": "DENY",             "Automate": "DENY",             "Flow": "DENY",             "KnowledgeBase": "DENY",             "Action": "DENY",             "Space": "DENY",             "ChatAgent": "DENY",             "Research": "DENY"           } このコマンドが正常に実行されると、次の出力が表示されます。 { "Status": 201, "Arn": "arn:aws:quicksight:us-east-1:<<864571xxxxxx>>:custompermissions/deny-all-capabilities", "RequestId": "c3d0a3e1-0c67-4581-a0d6-58fa9fd6386a" } カスタム権限プロファイルの確認 カスタム権限プロファイルを作成した後、適切な describe-*-custom-permissions API 関数を使用して確認と検証を行ってください。これにより、権限が意図したとおりに設定され、ガバナンスポリシーと整合していることを確認できます。 describe-custom-permissions API を使用して、新しく作成されたカスタムパーミッションを確認します。 aws quicksight describe-custom-permissions  --aws-account-id  <<864571xxxxxx>>  --custom-permissions-name    deny-all-capabilities コマンド実行後のサンプル出力: { "Status": 200,     "CustomPermissions": {         "Arn": "arn:aws:quicksight:us-east-1:864571xxxxxx:custompermissions/deny-all-capabilities",         "CustomPermissionsName": "deny-all-capabilities",         "Capabilities": {             "Dashboard": "DENY",             "Analysis": "DENY",             "Automate": "DENY",             "Flow": "DENY",             "KnowledgeBase": "DENY",             "Action": "DENY",             "Space": "DENY",             "ChatAgent": "DENY",             "Research": "DENY"         }     },     "RequestId": "8f9df543-c093-47de-92ba-77abe8a9e39c"     } カスタムパーミッションの割り当て カスタムプロファイルの作成を確認したので、次にそれらをさまざまなレベルで割り当てていきます。まずアカウントレベルから始め、次にロールレベル、最後にユーザーレベルで割り当てます。 アカウントのカスタムパーミッションの更新 次の例は、 UpdateAccountCustomPermission API を使用して、アカウントレベルで割り当てられたカスタムパーミッションを更新する方法を示しています。 aws quicksight update-account-custom-permission --aws-account-id <<864571xxxxxx>>  --custom-permissions-name deny-all-capabilities コマンド実行後のサンプル出力: { "RequestId": "5e12bf76-0173-4a35-aae7-bb892ffb0138", "Status": 200 } ロールのカスタムパーミッションの更新 以下の例は、 UpdateRoleCustomPermission API を使用して Author ロールのカスタム権限を更新し、このロールを持つユーザーがデータソースを作成できないように制限する方法を示しています。 aws quicksight update-role-custom-permission --aws-account-id <<864571xxxxxx>> --role AUTHOR --namespace default --custom-permissions-name deny-datasource ユーザーのカスタム権限の更新 次の例では、 UpdateUserCustomPermission API を呼び出して、ユーザーに割り当てられたカスタムパーミッションを更新し、デフォルトの名前空間内でチャットエージェントを作成する機能を拒否します。 aws quicksight update-user-custom-permission --aws-account-id <<864571xxxxxx>> --user-name C1-admin --namespace default --custom-permissions-name  deny-chat-agents ロールに割り当てられたカスタムアクセス許可の確認 カスタムパーミッションの割り当てが正常に完了したら、各レベルで設定されたパーミッションを確認し、正確性とコンプライアンスを確保することが重要です。 割り当てられたカスタム権限プロファイルの説明 (アカウントレベル) 次の例は、アカウントに割り当てられているカスタムアクセス許可プロファイルを返します。なお、アカウントには常に 1 つのカスタムプロファイルのみを割り当てることができます。 aws quicksight describe-account-custom-permission --aws-account-id <<864571xxxxxx>> API の実行が成功すると、次の出力が表示され、deny-all カスタム権限プロファイルがアカウントレベルで適用されます。 {     "CustomPermissionsName": "deny-all-capabilities",     "RequestId": "b430726f-c3ec-4f9b-a55c-4b04d2f3596e",     "Status": 200 } 割り当てられたカスタム権限プロファイルの説明 (ロールレベル) 次の例では、Author ロールに割り当てられたカスタムアクセス許可プロファイルを取得します。ロールには、任意の時点で 1 つのカスタムプロファイルのみを割り当てることができることに注意してください。 aws quicksight describe-role-custom-permission --aws-account-id <<864571xxxxxx>> --role AUTHOR --namespace default コマンドが正常に実行されると、次の出力が表示され、 deny-datasource プロファイルがロールレベルで適用されます。 { "CustomPermissionsName": "deny-datasource", "RequestId": "6b9cc3ff-71f9-4e8e-a588-c48b63fa8696", "Status": 200 } 割り当てられたカスタム権限プロファイルの説明 (ユーザーレベル) 次の例では、ユーザーレベルで割り当てられたカスタムアクセス許可プロファイルを取得します。ユーザーには、任意の時点で 1 つのカスタムプロファイルのみを割り当てることができることに注意してください。 aws quicksight describe-user --aws-account-id <<864571xxxxxx>> --user-name <<user-name>> --namespace default コマンドが正常に実行されると、次の出力が表示され、 deny-chat-agents プロファイルがユーザーレベルで適用されます。 { "Status": 200, "User": { "Arn": "arn:aws:quicksight:us-east-1:<<864571xxxxxx>>:user/default/C1-author", "UserName": "<<user-name>>", "Email": "c1author@test.com", "Role": "AUTHOR_PRO", "IdentityType": "IAM_IDENTITY_CENTER", "Active": true, "PrincipalId": "74c80498-5041-70b9-29fd-0df9f9995351", "CustomPermissionsName": "deny-chat-agents" }, "RequestId": "94ad152c-6021-4f3d-a4d5-2c17696b5859" } カスタムアクセス許可の割り当て解除 未使用または不要なカスタムパーミッションを定期的にクリーンアップして、安全で適切に管理された環境を維持することをお勧めします。これは、 delete-*-custom-permission API を使用して実行できます。この API は、Amazon Quick Suite 内のさまざまなレベルでの割り当て解除をサポートしています。 カスタム権限プロファイル (アカウントレベル) の割り当て解除のサンプル API: aws quicksight delete-account-custom-permission --aws-account-id <<864571xxxxxx>> ロールのカスタム権限の割り当てを解除するサンプル API: aws quicksight delete-role-custom-permission --aws-account-id <<864571xxxxxx>> --role AUTHOR --namespace default ユーザーのカスタム権限を割り当て解除するサンプル API: aws quicksight delete-user-custom-permission --aws-account-id <<864571xxxxxx>> --user-name C1-admin --namespace default カスタム権限プロファイルのサンプル API を削除します: aws quicksight delete-custom-permissions --aws-account-id <<864571xxxxxx>> --custom-permissions-name deny-all-capabilities まとめ Amazon Quick Suite の強化されたカスタムパーミッションは、エンタープライズデータガバナンスとセキュリティ管理における大きな進歩を表しています。管理者にアカウント、ロール、ユーザーレベルで機能アクセスに対する詳細な制御を提供することで、組織は特定の運用要件とコンプライアンス基準に沿った高度なセキュリティフレームワークを実装できるようになりました。 階層的な権限構造では、ユーザーレベルの権限がロールレベルの権限を上書きし、ロールレベルの権限がアカウントレベルの権限を上書きします。この構造により、セキュリティと生産性のバランスを取るために必要な柔軟性が提供されます。このアプローチにより、組織は広範なセキュリティポリシーを確立しながら、全体的なガバナンスを損なうことなく、特定のユーザーやチームに対して的を絞った例外を作成する能力を維持できます。 直感的な Manage Quick Suite コンソールを通じて実装する場合でも、AWS CLI や API を通じてプログラム的に実装する場合でも、カスタムパーミッションは管理者に次のことを可能にします。 Research、Automate、Chat Agents などの機密性の高い機能へのアクセスを制限することで、最小権限の原則を適用します。 きめ細かなユーザーレベルおよびロールレベルのオーバーライドにより、運用の柔軟性を維持します。 一貫した適用により、大規模なエンタープライズ環境全体でセキュリティポリシーをスケールします。 動的な権限調整により、進化するビジネスニーズに適応します。 詳細については、Quick Suite の カスタムパーミッション のドキュメントを参照してください。 著者について Raji Sivasubramaniam は、AWS のプリンシパルソリューションアーキテクトで、アナリティクスと AIML を専門としています。Raji は、世界中の Fortune 500 および Fortune 100 企業向けに、エンドツーエンドのエンタープライズデータ管理、ビジネスインテリジェンス、AIML ソリューションのアーキテクチャ設計を専門としています。マネージドマーケット、医師ターゲティング、患者分析など、さまざまな医療データセットを用いた統合医療データとアナリティクスに関する豊富な経験を持っています。 Neeraj Kumar は、AWS のシニアワールドワイドソリューションアーキテクトで、組織がデータを活用する方法を変革するエンタープライズ規模のソリューションを設計しています。自動車、製造、通信セクターにおけるデータとアナリティクスの 20 年以上の経験を持ち、Amazon Quick Suite と AI を活用したアナリティクスを使用して画期的なインサイトを引き出すためのグローバルカスタマーへのガイダンスを提供し、統合 AI/BI ランドスケープのモダナイゼーションとデータドリブン変革の加速を支援しています。 Salim Khan は、Amazon Quick Suite のスペシャリストソリューションアーキテクトです。Salim は、エンタープライズビジネスインテリジェンス (BI) ソリューションの実装において 16 年以上の経験を持っています。AWS に入社する前は、自動車、ヘルスケア、エンターテインメント、消費財、出版、金融サービスなどの業界に対応する BI コンサルタントとして働いていました。企業全体にわたって、ビジネスインテリジェンス、データウェアハウス、データ統合、マスターデータ管理ソリューションを提供してきました。

本ブログは株式会社 WhiteBox 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの中道です。 伴走型戦略 DX ファームの株式会社情報戦略テクノロジー様のグループ会社で、　IT 案件マッチングプラットフォームを運営する株式会社 WhiteBox 様は、飲み会の幹事の仕事を全て AI エージェントに丸投げできるサービス「KanpAi（カンパイ）」を開発されました。 本システムの開発においては、AI コーディングエージェントを利用した AI 駆動開発を活用し、通常なら数ヶ月を要する規模の開発を、わずか 3 週間で完成させ、2025年6月26日に開催された「AWS Summit Japan 2025 生成 AI ハッカソン」において最優秀賞を獲得されました。本記事では、AI駆動開発によって作られた AI エージェントシステムである「KanpAi」の詳細についてご紹介いたします。   お客様の状況と経緯 株式会社情報戦略テクノロジーグループの株式会社WhiteBox様では、親会社である株式会社情報戦略テクノロジー様の「 IT 業界の構造的課題を解決する」というミッションのもと、常に新しい技術を活用した生産性の高い開発体制を模索されておりました。特に、新規サービスのプロトタイピングにおいては、以下の課題が存在していました。 開発速度の限界 従来の開発手法では、アイデアの着想から実装、テスト、リリースまでの一連のサイクルに時間がかかり、市場やお客様のニーズに迅速に応えることが難しい場面がありました。特に今回のハッカソンのような極端な短納期開発では、従来の手法では実現が困難でした。 リソースの制約 少人数のチームで新しいサービスを開発する場合、インフラ構築、バックエンド、フロントエンド、そして本来注力すべきコアなロジック開発まで、一人のエンジニアが担う範囲が広くなり、専門性を活かしきれないという課題がありました。 非効率な反復作業 アプリケーション開発には、定型的なコードの記述や、APIの接続部分など、多くの反復作業が伴います。これらの作業に時間を取られ、より創造的な機能やユーザー体験の向上といった本質的な価値創出に集中しきれない状況がありました。 これらの課題を抜本的に解決し、開発者の創造性を最大限に引き出すためのアプローチとして、　AI コーディングエージェントを活用したAI　駆動開発（AI-Driven Development）に大きな可能性を感じていました。     ソリューション / 構成内容 「KanpAi」は、AI エージェントを用いた次世代の飲み会幹事の代行システムです。予算や人数や好みに合わせたAI によるお店のリサーチと予約、進行状況を把握しお店に出る前に行う二次会の先回り手配を実現します。また、参加者の好みや過去のフィードバック結果を学習させることで、「KanpAi」 を成長させることが可能です。   6つの専門AI エージェントによる自動化 システムの核となるのは、それぞれ専門的な役割を持つ6つのAI エージェントです。 会場リサーチ提案エージェント 予算や参加人数、条件や要望といった入力情報を元に、最適な会場を選定します。単に条件に合う店を探すだけでなく、なぜその店がおすすめなのかという理由も含めてLINEに通知します。 Web予約エージェント 会場の選定が完了したら、Web 予約エージェントが会場のWeb予約システムに自動的にアクセスし、予約を完了させます。予約確認もLINEで即座に通知されます。 二次会リサーチ提案エージェント 飲み会当日、二次会会場を探し、提案を行なうエージェントです。一次会の進行状況を把握し、適切なタイミングで二次会会場を自動的に探し提案します。LINEに通知された候補から選択すると、予約エージェントが予約を代行します。 電話予約エージェント Web予約に対応していない店舗に対して、実際に架電を行い、予約を行なうエージェントです。AI音声による自然な会話で予約交渉を行い、電話予約の結果はLINEで通知されます。 精算計算エージェント 飲み会後の事後処理として、参加者の役職によって傾斜をかけるなど、事情に合わせた割り勘を提案します。上司は多め、新人は少なめといった、日本の飲み会文化に配慮した柔軟な計算を行うことができるエージェントです。 継続学習エージェント 最後に今回の体験のフィードバックを入力することで、「継続学習エージェント」がフィードバックを受け、「KanpAi」は成長していきます。   「KanpAi」のバックエンドは、 AWSのサーバーレスアーキテクチャを全面的に採用し、迅速な開発とスケーラビリティを両立させています。各AI エージェントは独立したマイクロサービスとして機能し、AWS Lambda とAmazon Bedrock で実装されています。 Amazon Bedrockによるマルチエージェントの実現 本システムの中核であるAI エージェントの思考能力は、Amazon Bedrock を通じて実現しています。例えば、「会場リサーチ提案エージェント」では、ユーザーの要望（予算、エリア、料理の好みなど）を自然言語で理解し、最適な会場を推薦するためにClaude Sonnet 4 を利用しています。思考プロセスを担うLLMを柔軟に選択・変更できるAmazon Bedrock　の利点を活かし、エージェントのタスクごとに最適なモデルを使い分ける構想を持っています。 Amazon Rekognition とAmazon Connect の活用 飲み会中の写真から盛り上がり度を判定する「カンパイメーター」機能では、画像・動画分析サービスのAmazon Rekognitionを活用し、人物の表情や人数から独自の盛り上がり度スコアを算出しています。また、「電話予約エージェント」では、テキストを自然な音声に変換し、実際にお店へ電話発信を行うためにAmazon Connectを連携させています。これにより、Web予約に対応していないお店へもアプローチが可能となり、ユーザー体験を大きく向上させています。このように、AWSが提供する多様なマネージドサービスとAI サービスを組み合わせることで、アイデアを迅速に形にし、かつ高機能なアプリケーションを短期間で構築を実現されています。   導入効果 AI 駆動開発による開発工数の劇的な削減 限られた期間の中、AI 駆動開発の導入を行うことで多機能なアプリケーション開発を実現されました。 開発期間を数ヶ月から3週間へ短縮 CursorなどのAIコーディング支援ツールを全面的に活用し、定型的なコードやユニットテストの自動生成、コードのリファクタリングなどをAIに任せました。これにより、従来の手法であれば最低でも数ヶ月以上を要する規模のプロジェクトを、わずか3週間で完成させることができました。 開発者の創造性を最大化 Lambda関数のボイラープレートコード、API連携部分、エラーハンドリングなど、定型的な実装の大部分をAIが担当することで、エンジニアはより創造的で付加価値の高い、AIエージェントのプロンプト設計やビジネスロジックの考案に集中することができました。 プロトタイピングの高速化 アイデアを即座にコードに落とし込み、動くプロトタイプを短時間で作成できるため、チーム内でのフィードバックサイクルが格段に高速化しました。動くものを短時間で作り、フィードバックを集めてすぐに反映させる、というサイクルを高速に回し続けることで、サービスの方向性を早期に固め、ユーザー体験のブラッシュアップに時間を費やすことができました。 加えて、株式会社 WhiteBox 様は2025年6月26日に開催された 「AWS Summit Japan 2025 生成AIハッカソン ～それ AIエージェントがやります～」 において 「WhiteBoxお酒同好会」 として参加し、本プロダクトによって最優秀賞を獲得されました。   今後の展望 「KanpAi」のサービス展開 ハッカソンでの反響を受け、将来的にはユーザーインターフェースの改善や対応エリアの拡大、個人の好みを学習するパーソナライズ機能の強化など、多くのアイデアを検討されています。一方で「KanpAi」 は技術的な可能性を追求する中で生まれたサービスでもあるため、これまで培った知見をお客様のDX を支援する事業のプロジェクトに活かしていくことを目指されています。 (※「KanpAi」の正式なリリース時期は現時点では未定となります。) AI エージェントとAI 駆動開発の今後の活用 AI駆動開発の手法を「KanpAi」だけでなく、株式会社 WhiteBox 様が提供する全てのサービス、そして株式会社情報戦略テクノロジー様グループが手掛けるDX支援プロジェクト全体へと展開されることを計画されています。 自社内に「AIエージェント開発フレームワーク」を構築し、高品質なAIエージェントを迅速に開発できる体制を整えることで、お客様のビジネス課題を解決するソリューションをこれまで以上のスピードで提供することに取り組まれています。 『 「人にしかできない、創造的な仕事へ誰もが集中できる世界」の実現に向け、今後もAI技術の活用を推進し、IT業界全体の生産性向上に貢献していきたいと考えています。』 株式会社情報戦略テクノロジー AI Officer　藤本 雅俊 氏   Amazon Web Services Japan アカウントマネージャー 中道 野々香 ソリューションアーキテクト 小林 大樹

アマゾン ウェブ サービス ジャパン（以下、AWS）は、官公庁・教育・医療といった公共機関の大規模なクラウド移行を包括的に支援するために、AWSのクラウド移行支援プログラムである AWS ITトランスフォーメーションパッケージ 公共版（ITX for PS） を2024年6月にリリースし、公共機関におけるデジタル・トランスフォーメーションを支援してきました。そしてこの度、初等中等教育の課題解決、および教育DXの推進支援に向けて、AWSは包括的な支援メニューとして、ITトランスフォーメーションパッケージ教育版（ITX for Education）をリリースしました。このブログでは、ITX for Educationについて詳細を説明します。 初等中等教育を取り巻く環境 初等中等教育では、2019年12月に文部科学省から発表された「 GIGAスクール構想 」以降、国によるデジタル化の進展が急ピッチで進められてきました。各種EdTechサービスやデジタル教科書の導入、文部科学省CBTシステム「 MEXCBT 」や「 学習eポータル 」の導入・展開、 次世代校務DX による教員の働き方改革の実現、そしてNext GIGAとしてGIGAスクール構想第二期を迎えました。そして、2025年6月、デジタル庁、総務省、文部科学省、経済産業省から「 教育DXロードマップ 」が発出され、今後の教育DXの目指すべき姿が示されています。このデジタル化の一連の流れは、政府が進める「 クラウド・バイ・デフォルト（Cloud by Default） 」の原則に基づいており、AWSは、一貫して、日本の初等中等教育の課題に向き合い、ソリューションを提供することで教育DXの進展に貢献してきました。 初等中等教育における課題 初等中等教育では3つの主要な課題が顕在化しているといえます。第一に、教職員の業務負担過多により、月45時間を超える時間外勤務の割合が小学校25％、中学校43％、高等学校28％に達し、子供たちと向き合う時間が不足している状況です※。そのため校務DXによる業務効率化とデジタルツールの活用が急務となっています。第二に、一人一台端末は整備されたものの、学習ツールの導入・活用が進まず、子供たちの多様性に対応した個別最適な学習環境の構築が課題となっています。第三に、GIGAスクール構想でデジタル化が進展したものの、教育データを活用したエビデンスベースの指導や学習者へのフィードバックの浸透はこれからです。また、専門知識を必須としない分析ツールの開発もが必要です。これらの課題を解決することにより、すべての子供たちの「自分らしい学び」の実現を目指す必要があります。 ※ 文部科学省令和６年度教育委員会における学校の働き方改革のための取組状況調査 教育DX推進のためのITX for Education ITX for Educationは、教育委員会、提案・構築事業者、EdTech企業を対象としており、三つの柱で構成されています。 一つ目は、次世代校務DX推進です。次世代校務DXではクラウド化、モダン化が不可欠となりますが、AWSでは、教育委員会をはじめ、民間企業、ガバメントクラウドなど、数多くのクラウド移行の実績があり、これらのノウハウが蓄積されています。このノウハウを教育委員会、提案・構築事業者に提供し、スムーズなクラウド移行を支援します。結果として、教職員の負荷軽減を実現し、児童生徒および教員の能力を最大限に活用できる環境構築に寄与します。 二つ目は、多様なEdTechサービスの提供です。教育DX実現のためには、EdTechサービスの活用が不可欠です。AWSでは、多様な学びのための学習環境整備、また、教職員の負荷軽減などに対応したEdTechサービスを教育委員会、提案・構築事業者へ積極的にエンゲージメントします。 三つめは、生成AIによる教育データの分析・活用の推進です。AWSでは、生成AIを活用した教育データの利活用、教職員の負荷軽減、多様な学びのための学習環境整備、それぞれのユースケースを対象とした概念実証（PoC）の実施、プロトタイピングの作成、ソリューションの実装と本番環境への拡張計画の作成を支援します。 次世代校務DX化に向けた豊富なアセスメントプログラム それでは、ITX for Educationの具体的なメニューについてみていきたいと思います。 まずは、クラウド化に向けたアセスメントプログラムです。校務支援システムのクラウド化を進めるために重要な、次期システム検討の初期段階でのクラウド化による費用対効果の検証や、実現性の検証を様々なアセスメントにより支援します。経済合理性評価（クラウド・エコノミクス）では、クラウド移行を通じて得られる経済メリット（コスト削減効果）の試算を実施し、具体的な金額ベースで提示します。また、移行方法検討支援では、移行対象システムを俯瞰的に分析し、各教育委員会にマッチした戦略的なクラウド移行パターンを推奨します。また、クラウドによるモダン化を検討中の教育委員会に対しては、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示します。データベース（DB）移行支援では、脱商用データベースや同一データベースの移行について、移行先となるマネージドサービスの検討を支援します。ライセンス評価支援は、現在のシステム環境を第3者機関により評価し、3rd Partyライセンスを最適化します。これらのアセスメントプログラムは、いずれか一つを選択することも、複数を活用することも可能で、プログラムはAWSの専門チームが支援し、全て無償で提供します。 次世代校務DX化に向けたデータプラットフォーム検討支援 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」では、データ駆動型教育や、教育委員会内、学校内のデータを生成AIで最大限活用することを目指すお客様に対して、AWSの専門チームが各教育委員会の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示します。 データプラットフォーム検討支援を通じて、現行データ基盤の成熟度を把握することで、今後の教育データ連携基盤の戦略策定に活用できます。また、To-Beアーキテクチャ検討を通して、現行基盤の単純移行にとどまらず、クラウドでの機能強化のヒントが得られます。 次世代校務DX化に向けたゼロトラストネットワーク対応支援 教育委員会では、これまで校務系ネットワークと学習系ネットワークを分離させる、いわゆるネットワーク分離方式が推奨されてきました。しかしながら、この方式により校務系データと学習系データの連携が困難であり、教育データ利活用の観点で大きな課題となっていました。そこで次世代校務DXでは、校務系システムのクラウド化に伴い、インターネットを通じた、強固なアクセス制御による対策、いわゆるゼロトラスト・ネットワークの構築が推奨されています。ゼロトラスト・ネットワークは、デジタル資産を保護するための概念的なセキュリティモデルと関連メカニズムの集合体であり、単一の製品やソリューションではありません。また、各教育委員会のお客様がどこまで踏み込んだ対策をするかで金額面、構成面で大きな違いが出てきます。AWSでは、これらを踏まえ、専門チームが、お客様の要望を確認し、AWS製品のみならず、3rd Partyソリューションも含めた最適な構成の策定を支援いたします。 EdTechソリューション エンゲージメント支援 教育DXの課題となっているデジタル化による教職員の負担軽減や、多様の学びのための学習環境の整備については、EdTech各社のサービス導入も解決策となります。デジタル化による教職員の負荷軽減に関しては、デジタル採点、Web出願、保護者連絡・集金、コンタクトセンターなどのソリューション導入で、また、多様な学びのための学習環境の整備については、授業支援/学習管理、CBT/分析、デジタル教材/デジタルドリル、英語Speaking、プログラミング/AIなどのソリューション導入で課題解決に貢献します。これらのEdTechソリューションについて、AWSに相談いただくことで、最適なソリューションを提供するEdTech企業にエンゲージメントし、各教育委員会の課題を解決します。なお、ご紹介可能なEdTechサービスは、今後順次追加の予定です。 教育機関でのデータ利活用と生成AI活用支援 生成AIは、その登場以来、様々な企業や公共機関で導入され、大きな業務変革を実現しています。学校現場においても、文部科学省が 学校現場における生成AIの利用について のサイトを立ち上げ、初等中等教育段階の学校現場における生成AIの適切な利活用を実現するための参考となる資料や留意事項を本サイトにまとめており、ガイドラインに沿った積極的な活用を推奨しています。 生成AIは、教育DXの課題となっている教育データ利活用、デジタル化による教職員の負担軽減や、多様な学びのための学習環境の整備、すべてにおいて課題解決へ大きな効果が期待できます。教育データ利活用については、学習分析・データマイニング、教育データの自動レポート作成、予測分析とリスク検知などのユースケースが考えられます。デジタル化による教職員の負担軽減については、教材・コンテンツの作成や、個別最適化されたフィードバックの作成、指導計画策定などのユースケースが考えられます。また、多様な学びのための学習環境の整備については、パーソナライズされた学習体験の提供や、多言語・アクセシビリティ対応、特別支援教育への応用などのユースケースが考えられます。AWSでは、生成AIの専門チームから、これら教育機関向け生成AIユースケースを対象とした概念実証（PoC）の実施、ソリューションの実装と本番環境への拡張計画の作成を支援します。また、必要に応じて生成AIプロトタイプの作成という実装面の支援や、AWSクレジット提供によるコスト負担軽減の支援も実施します。（AWSクレジットの提供については、別途審査があります。） まとめ 冒頭で説明した通り、「GIGAスクール構想」以降、日本の初等中等教育ではデジタル化が目覚ましく進んできました。しかしながら、教育DX実現はこれからです。AWSは、教育DXの実現に向け、ITX for Educationを中心に各教育委員会、提案・構築事業者、EdTech企業を支援し、『誰もが、いつでもどこからでも、誰とでも、自分らしく学べる社会』を目指します。 ITX for Educationの始め方 ご関心のある方は、1） Webフォーム からお問い合わせ頂く、あるいは 2）パブリックセクター　教育・研究事業本部のメーリングリスト（jp-ps-edu-edt-k12@amazon.com）までご連絡ください。 ※ メーリングリスト宛にご連絡をいただく際は、＠が全角になっておりますので、半角に置き換えてください。

生成AIの向かう先 2025年10月時点での生成AI活用はまず生産性の向上、つまり人間が行う業務の代わりをさらに効率化していくことに主眼が置かれています。しかしながら生成AIの価値はそれだけにとどまらず、今後は人間の置き換え以上のビジネス効果をもたらすことが期待されます。一般業務の改善の次に来るのは特定の業務や業界に特化したソリューションであると言われています。実際Gartner*は、2027年までに生成AI モデルの半数以上がドメイン固有(特定の産業または業務機能に特化)となると予測しています。これは2024年時点でのドメイン固有の割合1%と比べると飛躍的な伸び率と言えるでしょう。 参考： “2027年までに企業が利用する生成AI モデルの半数以上がドメイン固有(特定の産業または業務機能に特化)となり、 2024年の1％から大幅に増加する” *Gartner, Generative AI Models, Worldwide, 2023-2029, Q2’25 それぞれの業界課題と生成AIを使った解決例 それでは業界に特化した課題とどのように生成AIがそれらを解決できるのか、いくつかのユースケースを使って解説しましょう。 「金融業界向けAIソリューション」 金融業界では新たなビジネスモデルを模索する一方、厳格なコンプライアンス対応、レギュレーションの遵守が求められています。例えばコールセンターでの音声データのチェックは、経験のある専門家が音声を聞いてチェックしているケースが多くあります。もちろんすべての音声記録をチェックできればよいのですが現実的には困難でしょう。また大量の作業を行えば、チェックの品質の低下も懸念されます。このような作業に生成AIを活用することで、膨大な音声記録を一定の品質でチェックすることが可能になります。クレジットカードのレギュレーションチェックもとても手間がかかる一方、属人化している業務です。大手クレジットカード会社ですと年に2回の大きなレギュレーションの変更があり、そのドキュメントのページ数は1000ページになることもあります。また変更の内容によっては複数部署での対応が必要となり、その影響範囲と内容の注意点を説明する資料を作ることも大きな負担となっています。こういった課題を解決するために、生成AIを利用して大量の文書を分析し、変更内容や影響範囲をチャットでわかりやすく教えてくれる仕組みが考えられます。 「製造業界向けAIソリューション」 製造業では生産の自動化が進む一方、人材不足、技術継承が大きな課題となっています。例えば設備管理においては、人がそれぞれ設備を目視でチェック、紙の報告書に記載してあとからパソコンに入力するといったことが行われているケースはまだまだ多いでしょう。加えて何らかの異常を検知した際に正しい判断を、短い時間で行うことは経験者が持つ暗黙知のなせる技とも言えます。こういった属人化を解消するために、例えばアナログメータをAIカメラが読み取り定期的に記録、異常があれば通知する仕組みが考えられます。 また過去の記録から最適な対応策をAIがアドバイスする仕組み、手袋をしていてパソコン入力ができない作業者を補助する音声によるデータの記録、マニュアルの必要な部分を読み出して解説する機能などで、生産性の飛躍的な向上を目指します。 「エンターテイメント、レジャー業界向けAIソリューション」 エンターテイメント、レジャー業界で新たな収益の柱をもたらすことが期待されるのはパーソナライゼーションです。エンターテイメントの世界ではSNSを通じた顧客接点の拡大が重要になってきています。デバイスとしては多くの場合にスマートフォンになるわけですが、通常は横型で作成されている映像コンテンツを縦型にに編集するのは、実は容易ではありません。単純に映像を中央で切り取るとストーリー上重要な部分をカットしてしまうこともあり得るからです。このような作業はとても手間がかかりかつセンスが求められます。AIによるプロフェッショナルなテクニックを用いた編集で短時間に大量のコンテンツ変換ができれば、SNSへの情報発信もタイムリーにできるようになります。レジャー・トラベル業界でもパーソナライゼーションの導入が加速しています。多種多様なサービスを提供するトラベル体験のパーソナライゼーションは、それぞれのサービスごとのAIエージェントとスーパーバイサーエージェントが情報をやり取りすることで実現できます。 業界固有の知見を持つパートナーの価値 上記のような業界固有のソリューションの開発には、AI技術や実装方法の知識や経験だけではなく、それぞれの業界に高い知見をもつパートナーの存在が欠かせません。AWSには各業界に精通した様々なパートナーが多数存在し、専門知識とソリューションの活用、セキュリティとコンプライアンス、コスト最適化やイノベーションの加速をAWSと一緒にご支援させていただいています。 AWS パートナーは業界の規制や組織構造、プロセスを熟知しており、AI の活用の仕方やビジネス効果を出すためのプロセス等の適切なアドバイスをすることが可能です。実際に上述した業界特有の課題に対して様々な AWS パートナーが AI ソリューションを開発しています。「 AI の導入を考えているけどどこから手を付けてよいかわからない」、「ビジネスとして効果が出せるのか悩んでいる」、「AI 技術の進歩が早く、最適な AI 技術の選択に不安を感じている」といったような課題をお持ちの方にはぜひとも以下に紹介するイベントにご参加いただきたいと思います。 AWS Industry GenAI Innovation Dayイベント概要 生成AI（Generative AI）の実用フェーズが加速する中、先進企業はすでに具体的な成果を生み出しています。製造現場のスマート化、金融サービスの革新、レジャーやエンターテインメントの進化など、各業界で実践的なソリューションが次々と実現されています。 本イベントでは、業界をリードするAWS認定パートナーが、製造、金融など分野における活用事例と導入のポイントをご紹介します。 各パートナーによる最新ソリューションのプレゼンテーションに加え、特別企画として、AWSガイド付きのブースツアーを予定しております。少人数グループで効率的にすべてのソリューションをご体験いただけます。各ブースでは実機デモを交えながら、貴社特有の課題に対する解決策を専門家と直接ご相談いただける機会がございます。 また、ブース訪問された方には、AWSオリジナルグッズをご用意しております。 ビジネス革新に向けた確かな一歩を踏み出すための、実践的な機会です。 皆様のご参加を心よりお待ちしております。 ※より充実したディスカッションの場とするため、定員を120名とさせていただいております。 定員に達し次第、申し込みを締め切らせていただきます。 日時：2025 年 11 月 4 日（火）14:00–17:30（13:30 受付開始） 場所：AWS 目黒オフィス 目黒セントラルスクエア 21 階（東京都品川区上大崎 3-1-1） 主催：アマゾン ウェブ サービス ジャパン合同会社 参加費：無料（要事前申込） 参加申込： こちらのお申込みフォーム からお申込みください。 展示テーマ 「金融業界向けAIソリューション」 金融業界では新たなビジネスモデルを模索する一方、厳格なコンプライアンス対応、レギュレーションの遵守が求められています。本イベントではコールセンター等の音声データ分析による金融規制対応の自動化、決済カードレギュレーションチェックプロセス業務効率化、脱属人化を実現するAIソリューションを紹介します。 「製造業界向けAIソリューション」 製造業では生産の自動化が進む一方、人材不足、技術継承が大きな課題となっています。より少ない人数で質の高い設備管理が行えるような、AIカメラソリューション、設備管理の自動化、作業実績の自動記録からマニュアルの音声での呼び出しまで、製造・プラントの現場で役に立つソリューションをご紹介します。 「エンターテイメント、レジャー業界向けAIソリューション」 エンターテイメント、レジャー業界で新たな収益の柱としてより適切なパーソナライゼーションが期待されています。顧客接点の可能性を広げるSNS向け動画自動編集、個人に最適化された旅行体験を提供する最新のAIサービスをご紹介します。 来場者特典 事前お申込みのうえ当日ブースツアーで５箇所以上にご参加いただきましたお客様へ 先着 100 名限定 で、イベント特製の持ち運び可能コンパクトPCスタンドをプレゼントいたします！ ※ 画像はイメージです。実物と異なる場合がございます。 当日はソリューションプロバイダー各社の展示ブースで製品デモをご覧いただけるほか、各社と個別にご相談できる機会も提供いたします。 こちらのお申込みフォーム からお申込みください。 皆様のご参加を楽しみにお待ちしております！

Amazon Redshift は、標準 SQL と既存のビジネスインテリジェンス（BI）ツールを使用してデータを簡単かつ費用対効果高く分析できる、高速でペタバイト規模のクラウドデータウェアハウスです。何万もの顧客が Amazon Redshift を利用してエクサバイト規模のデータを分析し、複雑な分析クエリを実行して、最高のコストパフォーマンスを実現しています。 完全マネージド型の AI 駆動による Massively Parallel Processing（MPP）アーキテクチャを備えた Amazon Redshift は、迅速かつコスト効率的にビジネス意思決定を推進します。以前、Amazon Redshift はコンピュート集約型ワークロードに最適化された DC2（Dense Compute）ノードタイプを提供していました。しかし、これらはコンピュートとストレージを独立してスケーリングする柔軟性に欠け、現在利用可能な多くの最新機能をサポートしていませんでした。分析需要の増大に伴い、多くのお客様が DC2 から RA3 または Amazon Redshift Serverless へアップグレードしています。これらは独立したコンピュートとストレージのスケーリングを提供し、 データ共有 、 ゼロ ETL 統合 、 Amazon Redshift ML による組み込みの人工知能および機械学習（AI/ML）サポートなどの高度な機能を備えています。 この記事では、ターゲットアーキテクチャと移行戦略を計画するための実践的なガイドを提供し、アップグレードオプション、主要な考慮事項、および成功したシームレスな移行を促進するためのベストプラクティスをカバーしています。 DC2 ノードから RA3 および Redshift Serverless へのアップグレードプロセス アップグレードへの第一歩は、新しいアーキテクチャをどのようにサイジングすべきかを理解することです。このために、AWS はプロビジョニングされたクラスター用の 推奨表 を提供しています。Redshift Serverless エンドポイントの構成を決定する際は、RPU とメモリの関係を調べることで、コンピューティング容量の詳細を評価できます。各 RPU は 16 GiB の RAM を割り当てます。ベース RPU 要件を見積もるには、DC2 ノードクラスターの合計 RAM を 16 で割ります。これらの推奨事項は、初期ターゲットアーキテクチャのサイジングに関するガイダンスを提供しますが、ワークロードのコンピューティング要件に依存します。要件をより適切に見積もるには、 Redshift Test Drive を使用して潜在的な構成を実行する概念実証の実施を検討してください。詳細については、「 Redshift Test Drive を使用してワークロードに最適な Amazon Redshift 構成を見つける 」および「 Amazon Redshift で概念実証を実施する 」を参照してください。ターゲット構成とアーキテクチャを決定した後、アップグレード戦略を構築できます。 アーキテクチャパターン 最初のステップは、ソリューションのターゲットアーキテクチャを定義することです。「 Amazon Redshift のパフォーマンスを大規模に最適化するためのアーキテクチャパターン 」で提示されているオプションから、ユースケースに最も適合するメインのアーキテクチャパターンを選択できます。次の図に示すように、主に2つのシナリオがあります。 執筆時点では、Redshift Serverless には手動のワークロード管理機能がなく、すべてが自動ワークロード管理で実行されます。独立したスケーリングとより良いパフォーマンスを実現するために、ユースケースに基づいてワークロードを複数のエンドポイントへ分離することを検討してください。詳細については、「Amazon Redshiftのパフォーマンスを大規模に最適化するためのアーキテクチャパターン」を参照してください。 アップグレード戦略 DC2 ノードから RA3 ノードまたは Redshift Serverless へのアップグレード時には、2つのアップグレードオプションから選択できます： リアーキテクチャ ： 最初のステップでは、ワークロードを評価してモダンなデータアーキテクチャの導入効果があるかを判断します。次に、DC2 ノードからのアップグレードと同時に、既存プラットフォームのリアーキテクチャを実施します。 段階的アプローチ ： これは2段階の戦略です。第1段階では、ターゲットの RA3 または Serverless 構成への単純な移行を行います。第2段階では、最先端の Redshift 機能を活用してターゲットアーキテクチャをモダナイズできます。 通常、段階的なアプローチを推奨しています。これにより、将来の最適化を可能にしながら、よりスムーズな移行が実現できます。段階的アプローチの第1段階は、以下のステップで構成されています： 既存の DC2 クラスターに相当する RA3 ノードまたは Redshift Serverless の構成を評価します。プロビジョニングされたクラスターの サイジングガイドライン またはサーバーレスエンドポイントの コンピューティング容量オプション を使用します。 Redshift Test Drive を使用して、非本番環境で選択したターゲット構成を検証します。この自動化ツールにより、本番ワークロードのシミュレーションプロセスが簡素化されます。さまざまな潜在的なターゲット構成で包括的な what-if 分析を実行できます。 特定のターゲット構成の価格対性能比に満足できたら、次のセクションで詳述する方法のいずれかを使用してアップグレードプロセスに進みます。 Redshift RA3 インスタンスと Redshift Serverless は、ゼロ ETL、 Amazon Redshift Streaming Ingestion 、 データ共有を使用したマルチウェアハウス書き込み 、独立したコンピュートとストレージのスケーリングなど、強力な新機能へのアクセスを提供します。これらのメリットを最大限に活用するために、現在のアーキテクチャの包括的なレビュー（段階的アプローチの第2段階）を実施し、Amazon Redshiftの最新機能を使用したモダナイゼーションの機会を特定することをお勧めします。例えば： データ共有を使用したマルチウェアハウスアーキテクチャ を実装し、ワークロードを分離してパフォーマンスを向上させる 現在、トランザクショナルソースから Amazon Redshift へのデータ転送に AWS Database Migration Service （AWS DMS）を使用している場合は、ゼロ ETLを実装して運用を効率化し、メンテナンスのオーバーヘッドを削減する アップグレードオプション DC2 から RA3 または Redshift Serverless へのクラスターのリサイズまたはアップグレードには、 スナップショットの復元 、 Classic resize 、 Elastic resize の3つの方法から選択できます。 スナップショットの復元 スナップショット復元方式は、既存の（ソース）クラスターのスナップショットを取得することから始まる順次的なプロセスに従います。このスナップショットは、希望する性能で新しいターゲットクラスターを作成するために使用されます。作成後、データがターゲットクラスターに正しく転送されたことを確認して、データの整合性を検証することが不可欠です。重要な考慮事項として、最初のスナップショット後にソースクラスターに書き込まれたデータは、同期を維持するために手動で転送する必要があります。 この方式には以下の利点があります： 既存の DC2 クラスターに影響を与えることなく、新しい RA3 または Serverless セットアップの検証が可能 異なる AWS リージョンまたはアベイラビリティーゾーンへの復元の柔軟性を提供 移行中の書き込み操作に対するクラスターのダウンタイムを最小限に抑える ただし、以下の考慮事項に留意してください： セットアップとデータの復元は、Elastic resize よりも時間がかかる場合があります。 スナップショット作成後にソースクラスターに書き込まれた新しいデータは、ターゲットへの手動コピーが必要になるため、データ同期の課題に直面する可能性があります。このプロセスは完全な同期を達成するために複数回の反復が必要になる場合があり、カットオフ前にダウンタイムが必要になることがあります。 新しい Redshift エンドポイントが生成されるため、接続の更新が必要になります。元のエンドポイントを維持するため、 両方のクラスターの名前変更 を検討してください（新しいターゲットクラスターが元のソースクラスターの名前を採用するようにしてください）。 Classic resize Amazon Redshift はターゲットクラスターを作成し、バックアップおよび復元を使用してソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータは、新しいクラスターに正確に転送されます。ソースクラスターは最初に再起動し、数分間使用できなくなるため、ダウンタイムは最小限に抑えることができます。すぐに再開され、バックグラウンドでリサイズが継続される間、読み取りと書き込みの両方の操作が可能になります。 Classic resize は2段階のプロセスです： ステージ1（クリティカルパス）： このステージでは、ソースとターゲットの構成間でメタデータの移行が行われ、ソースクラスターが一時的に読み取り専用モードになります。この初期フェーズは通常、短時間で完了します。このフェーズが完了すると、クラスターは読み取りおよび書き込みクエリで使用可能になります。KEY 分散スタイルで最初に構成されたテーブルは一時的に EVEN 分散を使用して保存されますが、プロセスのステージ2でオリジナルの KEY 分散に再分散されます。 ステージ2（バックグラウンド操作）：このステージは、データを元の分散パターンに復元することに焦点を当てています。この操作は、主要な移行プロセスに影響を与えることなく、低優先度でバックグラウンドで実行されます。このステージの期間は、再分散されるデータ量、進行中のクラスターワークロード、使用されているターゲット構成など、複数の要因によって異なります。 全体的なリサイズ期間は、主に処理されるデータ量によって決まります。Amazon Redshift コンソールで進行状況を監視するか、変換中のテーブルの完了率を表示する SYS_RESTORE_STATE システムビューを使用して監視できます（このビューへのアクセスにはスーパーユーザー権限が必要です）。 Classic resize アプローチには、以下の利点があります： すべての可能なターゲットノード構成がサポートされています ソースクラスターの包括的な再構成により、データスライスがノードごとのデフォルトに再バランスされ、ノード間でデータが均等に分散されます ただし、以下の点に留意してください： ステージ2 では、最適なパフォーマンスのためにデータを再分散します。しかし、ステージ2 は低い優先度で実行され、ビジーなクラスターでは完了までに長時間かかることがあります。プロセスを高速化するには、KEY DISTSTYLE を持つテーブルに対して ALTER TABLE DISTSTYLE コマンドを手動で実行できます。このコマンドを実行することで、データの再配布を優先的に実行でき、進行中のステージ2 プロセスによる潜在的なパフォーマンス低下を軽減できます。 ステージ2 のバックグラウンド再分散プロセスのため、 リサイズ操作 中はクエリの完了に時間がかかることがあります。軽減策として同時実行スケーリングの有効化を検討してください。 データ分散を高速化するため、リサイズを開始する前に不要で使用されていないテーブルを削除してください。 リサイズ操作に使用されるスナップショットは、この操作専用になります。そのため、テーブルの復元やその他の目的には使用できません。 クラスターは仮想プライベートクラウド（VPC）内で動作する必要があります。 このアプローチでは、Classic resize を開始する前に取得した新しいまたは最近の手動スナップショットが必要です。 ビジネスへの影響を最小限に抑えるため、オフピーク時間またはメンテナンスウィンドウ中に操作をスケジュールすることをお勧めします。 Elastic resize Elastic resize を使用してノードタイプを変更する場合、Amazon Redshift は順次プロセスに従います。まず既存のクラスターのスナップショットを作成し、そのスナップショットの最新データを使用して新しいターゲットクラスターをプロビジョニングします。バックグラウンドでデータが新しいクラスターに転送される間、システムは読み取り専用モードのままです。リサイズ操作が完了に近づくと、Amazon Redshift は自動的にエンドポイントを新しいクラスターにリダイレクトし、元のクラスターへのすべての接続を停止します。このプロセス中に問題が発生した場合、システムは通常、手動介入を必要とせずに自動ロールバックを実行しますが、そのような障害は稀です。 Elastic resize にはいくつかの利点があります： 平均 10 ～ 15 分で完了する迅速なプロセスです ユーザーはプロセス中もデータへの読み取りアクセスを維持でき、中断は最小限に抑えられます クラスターエンドポイントは操作中および操作後も変更されません このアプローチを検討する際は、以下の点に留意してください： Elastic resize 操作は、 EC2-VPC プラットフォーム を使用するクラスターでのみ実行できます。そのため、Redshift Serverless では利用できません。 ターゲットノード構成は、既存のデータに対して十分なストレージ容量を提供する必要があります。 すべてのターゲットクラスター構成が Elastic resize をサポートしているわけではありません。そのような場合は、Classic resize またはスナップショット復元を検討してください。 プロセスが開始された後、Elastic resize を停止することはできません。 データスライスは変更されません。これにより、データまたは CPU の偏りが発生する可能性があります。 アップグレード推奨事項 次のフローチャートは、適切な Amazon Redshift アップグレード方法を選択するための意思決定プロセスを視覚的にガイドします。 Amazon Redshift をアップグレードする際、その方法はターゲット構成と運用上の制約によって異なります。Redshift Serverless の場合は、常にスナップショット復元方式を使用します。RA3 プロビジョニングクラスターにアップグレードする場合は、2つのオプションから選択できます。ダウンタイムを伴う完全なメンテナンスウィンドウが許容できる場合はスナップショット復元を使用し、ダウンタイムを最小限に抑えたい場合は Classic resize を選択します。Classic resize は、データスライスをノードごとのデフォルトにリバランスし、ノード間でデータを均等に分散させるためです。特定の範囲内での特定のノードタイプの変更（例：DC2 から RA3）には Elastic resize を使用できますが、Elastic resize はスライス数を変更しないため、データや CPU の偏りが生じる可能性があり、後で Redshift クラスターのパフォーマンスに影響を与える可能性があるため、推奨されません。ただし、既存のクラスターでノードを追加または削減する必要がある場合は、Elastic resize が引き続き主要な推奨事項となります。 移行のベストプラクティス 移行を計画する際は、以下のベストプラクティスを検討してください： Amazon Redshift Advisor または Amazon CloudWatch を使用して、移行前の評価を実施する。 ユースケースとワークロードに基づいて、適切なターゲットアーキテクチャを選択する。Redshift Test Drive を使用して、適切なターゲットアーキテクチャを決定する。 手動スナップショットを使用してバックアップを作成し、自動ロールバックを有効にする。 ステークホルダーにタイムライン、ダウンタイム、変更内容を伝える。 新しいアーキテクチャの詳細とエンドポイントでランブックを更新する。 ベンチマークとデータチェックサムを使用してワークロードを検証する。 最終同期と切り替えにはメンテナンスウィンドウを使用する。 これらのプラクティスに従うことで、パフォーマンス、コスト、運用の継続性のバランスを取りながら、低リスクな移行を実現できます。 結論 Redshift DC2 ノードから RA3 ノードまたは Redshift Serverless への移行には、パフォーマンス、コスト効率、および最小限の中断をサポートするための構造化されたアプローチが必要です。ワークロードに適したアーキテクチャを選択し、移行後のデータとワークロードを検証することで、組織はデータプラットフォームをシームレスに最新化できます。このアップグレードにより長期的な成功が促進され、チームは RA3 のスケーラブルストレージまたは Redshift Serverless の自動スケーリング機能を最大限に活用しながら、コストとパフォーマンスを最適化できるようになります。 著者について Ziad Wali は、AWS のアナリティクススペシャリストソリューションアーキテクトです。データベースとデータウェアハウジングにおいて10年以上の経験を持ち、信頼性が高く、スケーラブルで効率的なソリューションの構築を得意としています。仕事以外では、スポーツや自然の中で過ごすことを楽しんでいます。 Omama Khurshid は、Amazon Web Services のアナリティクスソリューションアーキテクトです。彼女は、さまざまな業界のお客様が信頼性、拡張性、効率性に優れたソリューションを構築できるよう支援することに注力しています。仕事以外では、家族との時間を過ごしたり、映画鑑賞、音楽鑑賞、新しい技術の学習を楽しんでいます。 Srikant Das は、Amazon Web Services のアナリティクス スペシャリスト ソリューションアーキテクトとして、アナリティクスと AI においてスケーラブルで堅牢なクラウドソリューションを設計しています。技術的な専門知識に加えて、魅力的なブログを通じて旅行の冒険やデータインサイトを共有し、ソーシャルメディア上で分析的な厳密さとストーリーテリングを融合させています。 翻訳は、ソリューションアーキテクトの駒野が担当しました。原文は こちら です。

本ブログは 株式会社クリエイティブ・ウェブ様 と アマゾン ウェブ サービス ジャパン合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの齋藤です。 最近、多くのお客様から「コールセンター業務の効率化」や「問い合わせ対応の品質向上」についてのご相談をいただく機会が増えています。特に、生成 AI を活用した業務改善への関心が高まっており、実際の導入事例を求める声を多く耳にします。 その一方で、「生成 AI をコールセンター業務にどう活用すればいいのかわからない」「過去のナレッジをうまく活用できていない」といった課題をお持ちの方も多いのではないでしょうか？ 今回ご紹介する事例は、株式会社クリエイティブ・ウェブ様が Amazon Bedrock をはじめとしたマネージドサービスを活用して開発された、コールセンターお問い合わせ管理システムです。RAG (Retrieval-Augmented Generation) 技術を用いることで、過去の対応履歴を活用した対応サジェスト機能を実現し、問い合わせ対応の効率化と品質向上を同時に達成された事例となります。 お客様の状況と課題 株式会社クリエイティブ・ウェブ様は、システム・PC サポート・Web サイト・EC 関連の問い合わせ対応サービスを提供しており、日々多様な問い合わせに対応されています。 従来のコールセンター業務では、以下のような課題を抱えていらっしゃいました： 業務効率面での課題 手作業による情報管理: 問い合わせ内容や対応方法の記録・管理が属人的で、情報の一元化ができていない 対応品質のばらつき: 担当者によって対応方法が異なり、サービス品質に差が生じている ナレッジ活用の困難: 過去の対応事例が蓄積されているものの、類似ケースを検索・参照するのに時間がかかる 業務管理面での課題 進捗状況の把握困難: 受電から完了までのステータス管理が不十分で、対応漏れや遅延が発生するリスク 引き継ぎ作業の非効率: 担当者が変わる際の情報共有に時間がかかる 対応データの活用不足: 蓄積された対応履歴を分析して改善に活かせていない ソリューション・構成内容 これらの課題を解決するため、株式会社クリエイティブ・ウェブ様は AWS の生成 AI サービスを活用して「コールトラック」システムを開発されました。 システムアーキテクチャ システムは AWS のマネージドサービスを中心としたサーバーレス構成で設計されています： Amazon Bedrock: RAG 機能による過去対応履歴の検索 Amazon OpenSearch Service: 過去の対応履歴データの検索・インデックス化 AWS Lambda: 各種処理の実行基盤 Amazon Relational Database Service (Amazon RDS): 問い合わせ情報と対応履歴の管理 Amazon Simple Storage Service (Amazon S3): 対応関連ドキュメントの保存 Amazon API Gateway: フロントエンドとバックエンドの連携 主要機能 1. 問い合わせ情報管理機能 受電、保留、対応中、完了といったステータス管理 担当者、顧客情報、問い合わせ内容、対応方法の詳細記録 リアルタイムでの進捗状況可視化 2. RAG による過去対応履歴の検索 Amazon Bedrock の基盤モデルを活用し、過去の対応事例から最適な対応方法をサジェスト Amazon OpenSearch Service による高速な類似事例検索 文脈を理解した自然な日本語での回答生成 3. 自動要約機能 問い合わせ内容を箇条書きで入力すると、AI が自動的に要約 対応記録の標準化と効率化を実現 4. ナレッジの自動蓄積・学習機能 全ての対応履歴を自動でデータ化 定期的な RAG への取り込みによる継続的な学習 蓄積されたナレッジの品質向上 実際の画面 オペレーターが受電・架電時に使用するメイン画面です。対応者の状況 (対応可能・対応中・離席中) が一目でわかり、ワンクリックでステータスを変更できるため、スムーズな電話対応業務をサポートします。 「言った言わない」の確認や、対応内容の振り返りが簡単に行えます。通話音声の再生に加え、文字起こしデータと AI の要約が確認できます。さらに、電話対応を自動評価するため、教育にも利用可能です。 質の高い対応履歴は、AI の精度向上に不可欠です。この機能は、履歴の内容を AI が評価し、「より良いナレッジ」となるように文章を自動で校正。手間をかけずにナレッジの品質を維持できます。 対応履歴の作成時間を大幅に短縮します。箇条書きで入力したキーワードやメモを元に、AI が状況説明から対応内容までを瞬時に文章化。対応者は、文章作成の負担から解放されます。 日々の頑張りが「見える化」され、モチベーションアップに繋がります。受電数や対応件数などの成果がポイントとして貯まり、そのポイントでバーチャルペットを育てて楽しむことができます。 全体の業務状況をダッシュボードで可視化します。月・日・時間別の対応件数、カテゴリ別の割合など多角的に分析し、データに基づいた最適な人員配置や育成計画を支援します。 導入効果 お問い合わせ管理システムの導入により、以下の大きな効果を実現されました： 1. 対応効率の大幅向上 初回解決率の向上: RAG による過去対応履歴の検索により、一回目の対応で解決するケースが約 30% 増加 対応時間の短縮: 平均対応時間を従来比で約 40% 削減 情報検索時間の短縮: 過去事例の検索時間を従来の 5 分から 1 分以下に短縮 2. サービス品質の標準化 対応品質の均質化: 全担当者が同等レベルの対応サジェストにアクセスできるため、サービス品質が標準化 新人教育期間の短縮: 蓄積されたナレッジを活用することで、新人でも早期に高品質な対応が可能 3. データ活用による継続改善 対応パフォーマンスの可視化: 対応件数、時間、解決率などの KPI を自動集計・分析 改善点の特定: データ分析により、頻出する問い合わせパターンや対応改善点を特定 ナレッジの品質向上: 継続的な学習により、サジェストの精度が徐々に向上 4. コスト削減効果 人件費の最適化: 対応効率向上により、同じ人員でより多くの問い合わせに対応可能 教育コストの削減: 標準化されたナレッジにより、新人教育にかかる時間とコストを削減 技術的なポイント RAG の実装における工夫 株式会社クリエイティブ・ウェブ様では、RAG システムの精度向上のために以下の工夫を実装されました： 多層的な検索戦略: キーワード検索とセマンティック検索を組み合わせた高精度な類似事例抽出 文脈理解の強化: 問い合わせの背景情報も含めて分析し、より適切なサジェストを生成 フィードバックループ: 実際の対応結果をフィードバックとして活用し、継続的にモデルの精度を向上 コスト最適化の取り組み 適切なモデル選択: 問い合わせの複雑さに応じて、Amazon Nova、Claude 3 Sonnet と Haiku などを使い分け サーバーレス構成: 必要な時だけリソースを使用するため、運用コストを最小化 段階的なスケーリング: 問い合わせ量に応じた自動スケーリングにより、効率的なリソース利用を実現 今後の展望 株式会社クリエイティブ・ウェブ様では、お問い合わせ管理システムのさらなる発展を計画されています: 短期的な改善計画 音声認識機能の追加: 電話内容の自動文字起こしによる記録作業の完全自動化 多言語対応: グローバル展開を見据えた多言語サポート機能 リアルタイム分析: 対応中のリアルタイムサジェストとエスカレーション判定 長期的なビジョン 予測分析機能: 問い合わせ内容から将来のトラブルを予測し、事前対応を可能にする機能 顧客感情分析: 音声や文章から顧客の感情を分析し、適切な対応トーンを提案 業界特化型展開: 特定業界のナレッジベースを構築し、より専門的な対応を支援 お客様の声（株式会社クリエイティブ・ウェブ様） Amazon Bedrock を活用した RAG システムの導入により、これまで活用しきれていなかった過去の対応履歴が貴重な資産として生まれ変わりました。新人スタッフでもベテランと同等の対応品質を提供できるようになり、お客様満足度の向上と業務効率化を同時に実現できています。 AWS のマネージドサービスを活用することで、インフラ運用の負担を最小限に抑えながら、高度な AI 機能を短期間で実装することができました。特に Amazon Bedrock の多様なモデル選択肢により、コストと性能のバランスを最適化できた点が大きなメリットでした。 今後は、このシステムをベースにさらなる機能拡張を計画しており、コールセンター業務の完全自動化に向けて取り組んでいきます。 まとめ 今回は、Amazon Bedrock を活用した RAG システムにより、コールセンター業務の効率化と品質向上を同時に実現された株式会社クリエイティブ・ウェブ様の事例をご紹介しました。 特に注目すべきは、単なる AI ツールの導入ではなく、業務プロセス全体を見直し、データ駆動型の改善サイクルを構築された点です。これにより、継続的にサービス品質が向上する仕組みを実現されています。 同様の課題をお持ちのお客様、特に「コールセンター業務の効率化を図りたい」「過去のナレッジを有効活用したい」「問い合わせ対応の品質を標準化したい」といったニーズをお持ちの方には、非常に参考になる事例だと思います。 また、AWS では、生成 AI を活用したソリューション開発を支援するさまざまなイベントやプログラムを定期的に開催しております。技術セッションやハンズオンを通じて実際に技術に触れることができますので、ぜひご参加ください。 https://aws.amazon.com/jp/events/ ご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社クリエイティブ・ウェブ : 片桐 翼様 (左)、大皿 綾馬様 (中央)、藤井 龍生様 (右) 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amaozn API Gateway などのサーバレスのサービスが好きです。

本稿は、2025 年 10 月 17 日に公開された “ Charting the life of an Amazon CloudFront request ” を翻訳したものです。 Amazon CloudFront は、AWS ネイティブの Content Delivery Network (CDN) サービスです。CDN は、エンドユーザーにより近い世界中のエッジロケーションのネットワークを使用し、エッジでコンテンツをキャッシュすることで、Web アクセラレーションを提供します。しかし、CloudFront はそれ以上のことができます。エッジでの機能として、地理的フィルタリング、関数の実行、 AWS Web Application Firewall (WAF) フィルタリングの実行など、さまざまな機能を備えています。この投稿では、CloudFront ディストリビューションへのクライアントリクエストのライフサイクルを探求し、特にこれらの機能の実行順序に注目します。この理解は、Web アプリケーションの配信最適化、Web アプリケーションのセキュリティ保護、および CDN 設定のトラブルシューティングにおいて不可欠です。 リクエストのライフサイクルを見ていく前に、CloudFront クライアントリクエストに関わるインフラストラクチャの構成要素を探ってみましょう。 図 1: CloudFront エッジロケーションと リージョン別エッジキャッシュ エッジキャッシングの概要 CloudFront の Point of Presence (POP)、別名エッジロケーションは、リクエストが最初に到達するサーバーグループです。エッジロケーションは、リクエストに対して応答する(コンテンツがキャッシュされている場合)か、次のレイヤーに転送するかを判断します。エッジロケーションは世界中に分散配置されており、通常の AWS リージョン よりも小規模です。説明を分かりやすくするため、POP を 1 つの単位として考えることができます。図 1(公式 CloudFront ドキュメントより引用)は、この構成を示しています。 この概要説明で十分なケースもありますが、実際には CDN 設定のトラブルシューティング、キャッシング最適化、動的コンテンツ配信のパフォーマンス改善などのために、リクエスト-レスポンスの流れをより詳細に理解する必要があります。注目すべき点は、ビューワーからのリクエストとレスポンスが CloudFront ネットワーク内の複数のレイヤーを通過することです。POP では初期接続処理、負荷分散、キャッシング、 CloudFront Functions の実行が行われ、リージョン別エッジキャッシュ (REC) では高度なキャッシュ最適化、 Lambda@Edge の実行、オリジンサーバーへの接続、リクエストの折りたたみ、オリジンタイムアウト設定などが処理されます。また、キャッシュ効率をさらに向上させるオプション機能として Origin Shield を有効化できます。 HTTP(s) プロトコルに加えて、CloudFront はプロトコルの拡張機能もサポートしています。例えば、HTTP/2 上に構築されたオープンソースの Remote Procedure Call (RPC) フレームワークである gRPC や、TCP ベースのプロトコルである WebSocket があります。WebSocket は、リアルタイムアプリケーションで永続的な接続が必要な場合に、クライアントとサーバー間で長時間持続する双方向通信を実現するのに適しています。 本記事では HTTP(s) のリクエストとレスポンス処理に絞って解説し、gRPC と WebSocket 接続については別の記事で詳しく説明する予定です。 DNS 名前解決と POP ユーザーが CloudFront 経由で Web サイトにアクセスするところから始まります(次の図を参照)。通常、Web サイトは カスタムドメイン名 を CloudFront のドメイン名に紐付けて設定されています。CloudFront は DNS リクエストからユーザーの位置情報を判断し、そのリクエストを処理するのに最適なエッジロケーションの情報を DNS レスポンスとして返します。この際、CloudFront はインターネットネットワークの健全性、ネットワーク負荷など複数の要素を考慮して、ビューワーに最適な POP の IP アドレス(複数)を提供します。エンドユーザーの所在地に応じて、リクエストに応答するインフラを制限することで、コスト削減と異なる価格クラスの活用が可能です。CloudFront ディストリビューションで選択した価格クラスによって、ユーザーが利用できる POP が限定されます。また、 CloudWatch Network Monitor と CloudWatch Internet Monitor を利用することで、AWS 上でホストされているアプリケーションのネットワークおよびインターネットのパフォーマンスと可用性について、運用上の可視性を得ることができます。 CloudFront で エニーキャスト 静的 IP を使用している場合、DNS 解決によって最適な CloudFront POP を決定するプロセスは異なります。本記事では エニーキャスト IP を使用しないケースを想定しています。 図 2: CloudFront リクエストの経路 接続確立と TLS ネゴシエーション DNS 名前解決が完了すると、クライアントアプリケーション(Web ブラウザやモバイルアプリなど、ビューワーと呼ばれます)は、最適な POP の IP アドレスリストを受け取ります。クライアントアプリケーションは、これらの IP のいずれかを使用して POP への接続を確立し、必要に応じて別の IP を使ってフェイルオーバーすることができます。CloudFront は IETF 標準に準拠し、ポート 80/443 で HTTP、HTTPS、WebSocket を 受け付けます 。すべての POP は AWS Shield Standard によって保護されており、UDP フラッドや SYN フラッドなどの一般的な DDoS ボリューメトリック攻撃から守られています。次のレイヤーでは、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) 接続が正しく確立されているかを確認します。CloudFront ディストリビューションに設定された セキュリティポリシー によって、使用可能なプロトコルと暗号スイートが定義されます。 リクエストルーティングと検証 リクエストはリクエストルーターに引き渡されます。POP のリクエストルーターは、クライアント接続を複数のキャッシュサーバーに負荷分散します。ここには重要なセキュリティレイヤーも存在し、クライアントからのリクエストが Request for Comments (RFC) に準拠しているか、不正または曖昧な構文による脅威が含まれていないかを確認することで、キャッシュサーバーを監視・保護しています。このレイヤーによって、キャッシュレイヤーに転送されるリクエストが適切なフォーマットで HTTP 仕様に準拠していることが保証されます。この段階で、CloudFront ディストリビューションの設定に基づき、許可されるプロトコル、HTTP メソッド、地理的制限が評価されます。 AWS WAF リクエストの負荷分散とアクセス前のセキュリティチェックの後、CloudFront ディストリビューションで AWS WAF が有効化されている場合は、リクエストは AWS WAF のウェブアクセスコントロールリスト (ウェブ ACL) に設定されたルールによって処理されます。AWS WAF は Web アプリケーションファイアウォールであり、SQL インジェクション、クロスサイトスクリプティング、ボット攻撃、DDoS 攻撃などのアプリケーションレイヤーの攻撃からアプリケーションを守るために、リクエストを監視します。AWS WAF は、キャッシュビヘイビア、リクエスト/レスポンスヘッダーポリシー、CloudFront Functions や Lambda@Edge といったエッジコンピューティング関数などのコンテンツ処理ルールよりも必ず先に実行されます。 ビヘイビア この段階で、ユーザーはビヘイビアセクションにて、CloudFront がリクエストをどのように処理するかを定義できます。ビヘイビアは URL のパスパターンごとに異なる設定を持つことができます。ビヘイビア設定では、使用するオリジン、許可する HTTP メソッド、キャッシュポリシー、関数の紐付け、そしてオリジンリクエストポリシーを指定します。オリジンリクエストポリシーでは、どのパラメータ(ヘッダー、クエリ文字列、Cookie)をオリジンに転送するかを定義します。また、機密情報を保護するためのフィールドレベル暗号化も設定可能です。 CloudFront キャッシング CloudFront は、CloudFront Functions の Viewer Request 関数(設定されている場合)の実行後、POP のキャッシュに問い合わせを行います。POP 内には、キャッシュヒット率を最大化するための複数レイヤーのキャッシュが存在します。最初のレイヤーにオブジェクトがキャッシュされていない場合、リクエストは次のレイヤーへ、さらに次へと順次転送されていきます。ただし、無限にレイヤーを増やすことはできないため、各キャッシュスタック内のキャッシュサーバー数や、最初のレイヤーが参照できるピアの数には上限があります。POP 内のすべてのキャッシュレイヤーでオブジェクトが見つからない場合、リクエストは REC に転送されます。 REC REC には POP と同様のキャッシュレイヤーがあり、キャッシュ容量の拡大と Lambda@Edge 関数の実行に必要なコンピューティングインフラを提供しています。REC は POP とオリジンサーバーの間に位置する大容量のキャッシュレイヤーとして機能し、キャッシュヒット率のさらなる向上、オリジンへのリクエスト削減、そして Lambda@Edge の実行基盤としての役割を果たします。 Lambda@Edge の ビューワーリクエスト関数を定義している場合、CloudFront が REC のキャッシュを確認する前に、この段階で実行されます。その後、REC のキャッシュにオブジェクトが存在しない場合、Lambda@Edge のオリジンリクエスト関数が実行されます。 CloudFront ディストリビューションで Origin Shield を有効化している場合、すべての REC はオリジンサーバーへリクエストを送る前に Origin Shield を経由するため、オリジンサーバーへの負荷を削減できます。Origin Shield はユーザーのオリジンサーバーに近い場所に配置され、オリジンへのトラフィック帯域幅とリクエスト数を減らすことで、キャッシング効率を高めます。 オリジン接続側の最終レイヤー (REC または Origin Shield) は、コンテンツオリジンとの間で永続的な接続を維持し、効率的なデータ転送を実現します。 オリジンタイムアウト設定 (カスタムオリジンの場合) では、ユーザーは以下の値を調整することができます: 接続試行回数: CloudFront がオリジンサーバーへの接続を試みる回数を設定します。 接続タイムアウト: CloudFront がオリジンサーバーへの接続確立を試みる際の待機時間(秒)を指定します。 レスポンスタイムアウト: CloudFront がオリジンにリクエストを転送してからレスポンスを待つ時間、およびオリジンからレスポンスパケットを受信した後、次のパケットを受信するまでの待機時間を設定します。 オリジンリクエストポリシー では、エッジからオリジンサーバーへ接続する際に使用する最小 SSL バージョンも定義されます。 オリジンからのレスポンス リクエストがすべてのキャッシュレイヤー、REC、Origin Shield のいずれにも存在しない場合、オリジンサーバーから取得されます。オリジンはパブリック IP でアクセス可能なリソースですが、 VPC オリジン と組み合わせることでプライベートリソースにすることも可能です。オリジンが URL で指定されている場合、この段階で DNS 名前解決が実行されます。これにより、 Amazon Route 53 のレイテンシーベースルーティングや地理的位置情報ルーティングといったルーティングポリシーを活用して、最適なオリジンの場所を決定できます。 レスポンスは、リクエストとは逆の経路をたどって戻ります。オリジンサーバーからのレスポンスは REC に返されます。リクエストがキャッシュ可能で圧縮が有効な場合、レスポンスは圧縮されます。キャッシュの保持期間は CloudFront ビヘイビアのキャッシュポリシーで管理されます。Lambda@Edge のオリジンレスポンス関数が定義されている場合は、この段階で実行され、その結果が REC にキャッシュされます。Lambda@Edge のビューワーレスポンス関数が定義されている場合も実行されます。セキュリティ上の理由から、レスポンスに対して実行される関数はレスポンスボディの読み取りはできませんが、置き換えることは可能です。処理は POP へと続きます。CloudFront Functions の ビューワーレスポンス関数が定義されている場合は POP で実行され、最終的なコンテンツがクライアントに配信されます。図 2 は、このリクエスト/レスポンスの流れにおける主要なステップをまとめたものです。 まとめ 本記事では、ビューワーから Amazon CloudFront を経由してオリジンサーバーへと至る単一のリクエスト、そしてオリジンサーバーからビューワーへ戻るレスポンスの流れを追いながら、CloudFront が提供する様々なレイヤーと機能について解説しました。 各機能の実行順序と、それぞれがどのレイヤーで動作するかについて理解が深まったことと思います。ぜひこの知識を活かして、お使いの CloudFront 設定(キャッシュ設定、エッジ関数、AWS WAF、AWS Shield など)を見直し、CloudFront CDN の持つすべての力を最大限に活用してください。 著者について Sanchith Kandaka Sanchith は、コンテンツデリバリとアプリケーションセキュリティの分野で 15 年以上の経験を持ち、エッジ関連のあらゆる技術に情熱を注いでいます。ソリューションアーキテクトおよびソリューションエンジニアを経て、現在は AWS のスペシャリストソリューションアーキテクトとして、Amazon CloudFront、AWS WAF、AWS Shield などの AWS Edge Services および境界保護サービスを専門としています。 Jorge Prado Jorge は、ノースカロライナの AWS でシニアテクニカルアカウントマネージャーを務めています。エンタープライズサポートのお客様が最適なソリューションを見つけ、運用面での優れた成果を達成できるよう支援することに情熱を持っています。専門分野はネットワーキング技術です。プライベートでは、読書や映画鑑賞、お子さんとのゲームを楽しんでいます。 翻訳は Solutions Architect の長谷川 純也が担当しました。

本ブログは株式会社ファイン様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 皆様こんにちは。AWSジャパン アカウントマネージャーの松家です。 近年、多くのお客様が生成AIの検証段階から本番環境への適用に移行されています。また、開発現場にも生成AIが活用される時代になり、アイデアから実装に至るまでのスピードも劇的に早くなっていることを実感しています。 「建築CGのデジタル素材」という市場において高品質なデジタル商品、サービスを提供されている 株式会社ファイン様 は実際のビジネス課題を解決する機能をAWS上で開発するハッカソンイベント AWS DEVCRAFTに参加。Amazon SageMakerやAmazon Bedrockを通じてAmazon Titan Multimodal Embeddings を活用し、設計からわずか1か月半で生成された建築AIパースのイメージに近い商品をレコメンドする機能を開発されました。 本記事では生成AIを活用した業務効率化、および顧客満足度向上の取り組みについてご紹介いたします。 お客様の状況と検証に至る経緯 株式会社ファイン様は施主の要望と設計者の見識から建築パース画像を生成するサービス「AI PERS（AIパース）」を提供されています。このサービスはお客様に大変好評だったものの、いくつか運用面で課題が残っていました。 • 施主のイメージは具体化出来るが、実際の商品とのマッチングや検索に時間がかかってしまう。 • 営業や設計の商談に差が出てしまい、お客様の検討の温度感が高い間に提案が出来ずに至ってしまう。 そこで、生成AIを活用してこれらの課題を解決できないかと考えました。 ソリューション / 構成 施主が選択したプランから、理想のお部屋イメージを入力すると入力内容に基づき建築AIパースが生成されます。その生成されたAIパースのイメージと、実際に販売している商品とをベクトル検索を通じておすすめ度の1-5位を表示します。 機能全体のフロー • 生成された画像の中から検索をかけたい部位を検出します。今回は床を想定しています。 • その床部分だけをAWS Lambdaを用いて切り抜きます。 • 切り抜かれた画像をAmazon Bedrock に渡し、ベクトル化モデルのAmazon Titan Multimodal Embeddings を活用し、ベクトル化を実施します。 • Amazon RDS PostgreSQLでベクトル検索を行い、類似品を検索します。 導入効果 ファイン様の「レコメンド AI」により、以下の効果が期待されています。 • 出力されたAIパースのイメージに近い商品を探す時間を75% 削減し、担当者の工数削減に寄与する。 • ベクトル検索を通じて、おすすめ度合いに応じて1-5位まで瞬時に表示できるため、顧客体験の標準化や向上を図る。 今後の展望 今後の展開について、ファイン様は次のように意欲を示しています。 • AIパースサービスからの連携だけでなくSNSなどの写真画像を入力としての機能拡張 • 自社のパース制作アプリケーションの自動仕様設定機能として組み込み • 自社のコンテンツ配信サービス（データステーション）の検索機能としての組み込み AWS DEVCRAFTでの取り組み内容発表時の様子 株式会社ファイン 開発部 ゼネラルマネージャー 雑賀 崇 氏

このブログ記事は、株式会社ギフティ様が執筆し、Amazon Web Services Japan が監修しています。 はじめに 株式会社ギフティ (以下、ギフティ) は「eギフトを軸として、人、企業、街の間に、さまざまな縁を育むサービスを提供する」をビジョンに掲げ、カジュアルギフトサービス「giftee」や、法人・自治体向けにeギフトを活用したソリューションを提供する「giftee for Business」などを展開しています。 本稿では、弊社の「giftee for Business」のソリューションのうちの一つであり、2025年4月1日より提供を開始したキャンペーン基盤「giftee Reward Suite」のインフラ構築事例を紹介いたします。 giftee Reward Suite は、企業の会員サービスと連携し、既存会員向けの効果的なキャンペーン施策やリワードプログラムの実装を継続して実現するための SaaS です。ユーザー認証から条件判定、抽選、ギフト配布までを一括で提供することで、企業が手軽にキャンペーンを実施できます。 giftee Reward Suite では、主に Amazon Elastic Kubernetes Service (以下、EKS) クラスタの運用管理がよりシンプルになる点に魅力を感じて、 Amazon EKS Auto Mode (以下、EKS Auto Mode) を採用しています。EKS Auto Mode は2024年12月の AWS re:Invent において一般提供が開始されました。これは、Kubernetes クラスタのコンピューティング、ストレージ、およびネットワーキングの管理を自動化する新機能です。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、Kubernetes の実行や管理を簡素化することができます。クラスタ管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進により注力することが可能です。本稿では、「giftee for Business」における EKS Auto Mode の導入に至った経緯、採用したアーキテクチャ、導入効果、そして今後の展望についてご説明します。 プロジェクトの概要 本プロジェクトの開発は2024年1月頃にスタートし、2025年4月1日に 日本生命保険相互会社をクライアントとしてサービスインを迎えること が決定していました。開発体制としては、フロントエンド主担当1名、バックエンド主担当2名、そしてインフラ担当1名（筆者）の計4名で開発を進めました。 プロジェクト期間は長く見えるかもしれませんが、法人向け SaaS システムとしての要件定義や設計をゼロベースで検討する必要があるため、インフラ構築にかけられる実質的な期間は限られていました。このため、短期間での効率的な構築が求められる状況でした。 EKS Auto Mode を採用した経緯 アーキテクチャとしては、マイクロサービス的な構想があることや、インフラ側でも複雑な要件が発生する可能性が高い状況であったので Kubernetes の採用も積極的に視野に入れて検討していました。開発当初は EKS on EC2 のマネージドノードで構築を進めていましたが、プロジェクト体制や兼務の問題があり、その運用負荷の高さが大きな課題でした。 そうした最中、2024年12月に EKS Auto Mode が発表され、アドオン等の AWS マネージドな領域が大きく広がり、EKS クラスタの運用管理がよりシンプルになる点に魅力を感じ、すぐに検証を開始しました。その後、採用を決定し2025年4月より本番環境でサービス稼働しています。 採用する上で大変だった点については後述しますが、今回の対象のワークロードは一般的な Web サーバー等のステートレスの構成が多く、EKS Auto Mode や Karpenter などの採用の際に注意が必要な長時間実行されるバッチ処理やステートフルなリソースも少ない構成でした。これが短期間での検証から採用に踏み切れた決め手のうちの一つと考えています。 なお、補足しておくと、EKS Auto Mode は長期実行のワークロードでも利用可能です。その場合の注意点や設定については、AWS ブログ「 Amazon EKS Auto Mode のノード自動更新を Deep Dive する ~ 長期実行ワークロードを正しく取り扱う 」が大変参考になります。 アーキテクチャ概要 特徴として、EKS Auto Mode のデータプレーン側の EC2 ノードは、高可用性のため 3AZ に冗長化されています。また本記事に直接関連しない箇所については、一部表記を省略しております。 図 1 giftee Reward Suite アーキテクチャ概略図 導入の効果 EKS Auto Mode の導入により、運用負荷が大幅に軽減されたのが最大のメリットであると感じています。具体的な効果は以下の3点です。 クラスタ管理の簡素化：従来、EKS クラスタでは、AWS Load Balancer Controller や Kube proxy などの各種アドオンを自分たちで管理する必要がありました。EKS Auto Mode はこれらを AWS の責任範囲で自動的に管理してくれるため、バージョンアップといった運用タスクの負荷が軽減されました。 ノード管理の効率化：開発当初は、EKS Managed ノードで Auto Scaling Group を利用して EC2 インスタンスのノードを管理していました。EKS Auto Mode では Karpenter をベースとしたクラスターオートスケーラーを含めて AWS の責任で管理されるため、自身で管理する必要がない点もメリットだと感じています。 セキュリティ：EKS Auto Mode のノードでは、Bottlerocket と呼ばれるコンテナの実行に最適化された OS が利用され、セキュリティアップデートやパッチなどが AWS の責任で自動的に適用されることにより、セキュリティの安全性が確保されています。また、ノードの最大存続期間が21日に設定されており、自動的に新しいノードに置き換えられるため、セキュリティのベストプラクティスである定期的なノードの定期的な入れ替えが運用負荷なしに実現できています。 導入時の検討と課題 EKS Auto Mode は、従来の EKS に比べて AWS マネージドな領域が広がり、ユーザの運用がシンプルになる一方で、ユーザー側で設定できる範囲は狭まるというトレードオフがあると言えます。このため、導入にあたっては下記の事項について検討しましたが、今回のワークロード特性上、結果的に大きな制約とはなりませんでした。 ノードの自動更新：EKS Auto Mode では、セキュリティの観点から最大21日ごとにノードが自動的に置き換えられます。これは、ホストサーバーにデータを保存するようなステートフルなワークロードや、長時間実行されるバッチ処理などがある場合は検討すべきポイントになります。ただ今回のワークロードは、データベースとして RDS や Valkey などのサービスを活用し、アプリケーション自体はステートレスな設計にしていました。また、バッチ処理もいくつか存在するものの、短時間で処理が終了するものであり、かつ冪等性も考慮していたため、制約にはなりませんでした。 カスタム AMI の利用制限：EKS Auto Mode ではカスタム AMI を持ち込むことができません。これも、特定のソフトウェアをホストサーバーに事前にインストールしておく必要があるようなケースでは課題となり得ますが、今回のアプリケーションはホストサーバーに依存しない設計になっていたため、この点も制約とはなりませんでした。 Security Group per Pod (SGPP) の非サポート：EKS Auto Mode では、Pod 単位でセキュリティグループを付与する Security Group per Pod (SGPP) が現時点ではサポートされていません。しかし、今回のアプリケーションで、Pod 単位でセキュリティ分離を行うモチベーションは強くありませんでした。また、将来的に特定のアプリケーションからのみ、ある AWS サービスへのアクセスを許可する要件が発生しても、NodeClass を利用して NodePool ごとに異なる Security Group を適用することで、一定のセキュリティ分離は達成できると見込んでいたため、大きな制約とは判断しませんでした。とはいえ、他アプリケーションでも EKS Auto Mode を利用することを想定すれば、pod レベルで Security Group が付与できる方がより良いと考えているため、今後 SGPP 相当の機能がリリースされることを期待しています。 一方で、Karpenter や EC2 ノードの管理等、AWS がマネージドで提供する機能の挙動を理解する必要があるという点は大変だったかもしれません。上記で述べた通り、EKS Auto Mode では今までユーザーが担う必要があった部分も AWS の責務範囲になっていますが、これらの機能が AWS マネージドになったからといって、もちろんその挙動を理解しなくても良いわけではなく、同様に理解する必要があります。 今回、キャッチアップに苦労した部分もありましたが、 EKS Auto Mode のワークショップ やコミュニティ勉強会の中で、AWS のプロフェッショナルの方々や、EKS を運用している事業会社のコミュニティメンバーとのディスカッションを通じて、理解を深めることができたと感じています。 今後の展望 「giftee Reward Suite 」を、今後より多くのお客様にご利用いただくための機能開発と、サービスの安定運用に引き続き注力していきます。 特にインフラ面では Karpenter の設定最適化を進めることでインフラコストの効率化をはかりたいと考えています。具体的には、スポットインスタンスの活用等を行う予定です。 まとめ 本稿では、「giftee Reward Suite」 における Amazon EKS Auto Mode の導入事例をご紹介いたしました。 EKS Auto Mode を採用することで、Kubernetes の優れたアーキテクチャを活用しつつ、クラスターの運用管理をシンプルにすることができました。Kubernetes の採用をご検討されており、運用負荷に懸念をお持ちの方々にとって、本事例が参考になれば幸いです。 著者について 牧 純平 SIer でのキャリアを経て、2022年に株式会社ギフティへ入社。 法人向けギフトキャンペーンサービスの開発に従事し、現在はプラットフォームエンジニアリング組織の立ち上げを推進。 Rui Lee (リー) AWS Japan のソリューションアーキテクトとして、Web 業界のお客様を中心にアーキテクチャの設計・構築を支援しています。

本投稿は、Suchindranath Hegde と Mahesh Kansaraと Leonid Slepukhinと Sridhar Ramasubramanian による記事 「 Data masking and performance improvements in AWS DMS 3.5.4 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) のレプリケーションエンジンバージョン 3.5.4 で新機能が利用可能になったことをお知らせできることを嬉しく思います。 このリリースには、セキュリティ強化のためのデータマスキングと、データ検証時のパフォーマンス向上という 2 つの主要な機能強化が含まれています。 この投稿では、これら 2 つの機能について詳しく説明します。この新バージョンで利用可能なすべての新機能のリストは、 リリースノート を参照してください。 セキュリティ強化のためのデータマスキング データ保護を強化するため、お客様からデータマスキング機能のリクエストがありました。これにより、移行中にカラムレベルで機密データを変換し、GDPR などのデータ保護規制への準拠を支援します。AWS DMS を使用することで、カラムレベルで保護が必要な情報を編集したデータのコピーを作成できるようになりました。 データベース移行中のお客様にとって最大の懸念事項の 1 つは、口座番号、電話番号、メールアドレスなどの機密情報の安全な取り扱いです。AWS DMS 3.5.4 では、3 つの柔軟な データ変換ルール を実装しました： 数字マスク 数字のランダム化 ハッシュマスク これらの変換ルールを説明するために、「EMPLOYEES」というテーブルを Amazon RDS for Oracle インスタンス から Amazon RDS for PostgreSQL インスタンスに移行します。 以下の手順を完了してください： ソース (Oracle) インスタンスで以下のテーブル DDL を使用して EMPLOYEES テーブルを作成します： CREATE TABLE EMPLOYEES ( EMPLOYEE_ID NUMBER(6) PRIMARY KEY, FIRST_NAME VARCHAR2(50) NOT NULL, LAST_NAME VARCHAR2(50) NOT NULL, EMAIL VARCHAR2(100) UNIQUE, PHONE_NUMBER VARCHAR2(20), HIRE_DATE DATE NOT NULL, JOB_TITLE VARCHAR2(50), SALARY NUMBER(10,2), DEPARTMENT_ID NUMBER(4), MANAGER_ID NUMBER(6), ACCOUNT_NUMBER VARCHAR2(20), CREATED_DATE DATE DEFAULT SYSDATE ); CREATE SEQUENCE emp_seq START WITH 1 INCREMENT BY 1 NOCACHE NOCYCLE ; EMPLOYEES テーブルにいくつかのレコードを挿入します。 INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'John', 'Smith', 'john.smith@company.com', '555-0101', DATE '2020-01-15', 'CEO', 150000, 10, NULL,'456-123-456-789'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Sarah', 'Johnson', 'sarah.johnson@company.com', '555-0102', DATE '2020-03-20', 'IT Director', 120000, 20, 1,'666-000-111-222'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Michael', 'Brown', 'michael.brown@company.com', '555-0103', DATE '2021-02-10', 'Software Engineer', 85000, 20, 2,'777-333-444-555'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Emily', 'Davis', 'emily.davis@company.com', '555-0104', DATE '2021-06-15', 'HR Manager', 75000, 30, 1,'899-987-654-321'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'David', 'Wilson', 'david.wilson@company.com', '555-0105', DATE '2022-01-20', 'Software Engineer', 80000, 20, 2,'567-111-222-333'); 「移行のみ」または「移行および複製」オプションを使用して AWS DMS タスクを作成 します。 次のテーブルマッピングルール JSON を使用して AWS DMS タスクを設定します。 ACCOUNT_NUMBER 列には文字 # で、 PHONE_NUMBER 列には乱数で、 EMAIL 列にはハッシュでマスキングします。また、変換ルールを使用してすべての文字を小文字に変換するなど一部の文字を変換していますが、これはオプションです。 {     "rules": [         {             "rule-type": "transformation",             "rule-id": "171087779",             "rule-name": "171087779",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "ACCOUNT_NUMBER"             },             "rule-action": "data-masking-digits-mask",             "value": "*",             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "171057753",             "rule-name": "171057753",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "PHONE_NUMBER"             },             "rule-action": "data-masking-digits-randomize",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169940283",             "rule-name": "169940283",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "EMAIL"             },             "rule-action": "data-masking-hash-mask",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169926638",             "rule-name": "169926638",             "rule-target": "column",             "object-locator": {                 "schema-name": "%",                 "table-name": "%",                 "column-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169918368",             "rule-name": "169918368",             "rule-target": "table",             "object-locator": {                 "schema-name": "%",                 "table-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169908300",             "rule-name": "169908300",             "rule-target": "schema",             "object-locator": {                 "schema-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "selection",             "rule-id": "169895493",             "rule-name": "169895493",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES"             },             "rule-action": "include",             "filters": []         }      ] } 次の出力例では、データマスキングを適用した PostgreSQL インスタンスの出力を確認することができます: dmsdb=> select employee_id,phone_number,email,account_number from admin.employees ;   employee_id | phone_number |                               email                               | account_number -------------+--------------+------------------------------------------------------------------+-----------------            20 | 685-9897     | FDC2A4ABC53872D0F934B5614DDC312DAA165895065BB00A5986849AADE8C322 | ***-***-***-***            21 | 579-3441     | 3A4FA9FE0AA0A2B468EDF13A29A75C4E3A20650243143D834D7898D40AA0FA2F | ***-***-***-***            22 | 156-9277     | 0985B1D142A4067E397DF5AB56B03E3BF4857FB1F229CB39B49CE06E46B7AA98 | ***-***-***-***            23 | 238-5321     | D07EAB207F4F1366C1E35B35E33F7842FF3EEB2C80E47FDAEB0900B49EE77697 | ***-***-***-***            24 | 536-1233     | 3D438AF13A839ACDC24FD0CE8EB8C8C45083B90A31DF3583A88131614086C3B9 | ***-***-***-*** (5 rows) 以下の画像は、比較のために Oracle での出力例を示しています。 前述の例では、データマスキング機能を使用して機密情報をマスキングする方法を示しました。詳細については、 データマスキングを使用して機密情報を隠す を参照してください。 データ検証パフォーマンスの強化 データの整合性を維持することは、どのデータベース移行においても重要ですが、多くの場合、時間とリソースを大量に消費するプロセスです。AWS DMS 3.5.4では、高速パーティション検証などの革新的な手法を使用して検証プロセスを合理化する 拡張データ検証機能 によってこの課題に対処しています。 強化されたデータ検証の主な利点には、以下のようなものがあります： レプリケーションインスタンスから AWS DMS のソースおよびターゲットエンドポイントへのリソース使用量の再分配 潜在的なネットワーク使用量の減少 LOB データ型を含まない幅広いテーブルに効率的 拡張データ検証機能は、Oracle から PostgreSQL、SQL Server から PostgreSQL、Oracle から Oracle、SQL Server から SQL Server など、特定の AWS DMS による移行パスで利用できるようになりました。この機能を使用するには、環境が 前提条件 を満たしていることを確認してください。 AWS DMS が拡張データ検証を使用しているかどうかは、 Amazon CloudWatch ログを見れば確認できます。次のようなメッセージが表示されます: 2025-02-12T21:23:26 [VALIDATOR ]I: Fast validation of table 'dbo'.'customer' : partition : 178 (partition_validator.c:1001) パフォーマンスの向上を定量化するために、以下のスクリーンショットに示す設定で HammerDB を使用してベンチマークを実施しました。 ベースラインとして、検証を無効にしたフルロードと変更データキャプチャ (CDC) タスクを作成し、約 9,300 万レコード (サイズ 15 GB) を Amazon RDS for SQL Server から Amazon Aurora PostgreSQL 互換エディション へ、合計 9 つのテーブルにわたって移行しました。 次に、2 つの 検証のみ タスクを実行しました。1 つは AWS DMS 3.5.3 で、もう 1 つは AWS DMS 3.5.4 で、どちらも r6i.xlarge インスタンスを使用しました。 検証を高速化するために、 PartitionSize を 100,000 に、 ThreadCount を 15 に増やしました： "ValidationSettings": { "PartitionSize": 100000, "ThreadCount": 15, "ValidationOnly": true } 次のスクリーンショットは、エンジンバージョン 3.5.4 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。 次のスクリーンショットは、エンジンバージョン 3.5.3 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。 AWS DMS 3.5.3 と比較して、AWS DMS 3.5.4 で実行した場合、検証のみのタスクの TaskMemoryUsage が 91% 減少し、基盤となるAWS DMS レプリケーションインスタンスの CPU 使用率が 95% 削減されることがわかります。検証のみのタスクを別に実行したいお客様は、この機能を使用して、AWS DMS レプリケーションインスタンスのコンピューティングとメモリをより有効に活用できます。 まとめ この投稿では、AWS DMS 3.5.4 におけるデータマスキングと強化されたデータ検証の変換ルールについて説明しました。 データマスキング機能を実装することで、データベース移行プロセス全体を通じて機密情報を確実に保護できます。 拡張データ検証機能により、DMS レプリケーションインスタンスのリソース消費を抑えながら、検証を実行するすべての利点を得ることができます。 これらの機能を試してみて、あなたのユースケースにどのように役立ったかをコメント欄でお聞かせください。 著者について Suchindranath Hegde は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。 Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。 彼は開発およびエンジニアリングチームと密接に協力して、移行およびレプリケーションサービスの改善に取り組んでいます。 また、お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を使用する際のソリューションの価値向上を支援しています。 Leonid Slepukhin は、Amazon Web Services の Database Migration Service (DMS) チームのシニアデータベースエンジニアです。 AWS DMS のコア機能の開発に取り組み、社内外の顧客が複雑なデータベース移行とレプリケーションの課題を解決するのを支援することを専門としています。 DMS の機能強化と、AWS クラウドへのデータベース移行を成功させるための技術的専門知識の提供に重点を置いています。 Sridhar Ramasubramanian は、AWS Database Migration Service チームのデータベースエンジニアです。 AWS のお客様のニーズにより適合するよう、DMS サービスの改善に取り組んでいます。

本投稿は、Veeramani A と Manoj Ponnurangam による記事 「 Best practices to handle AWS DMS tasks during PostgreSQL upgrades 」を翻訳したものです。 AWS Database Migration Service は、データのセキュリティとデータの整合性を提供しながら、データベースを Amazon Web Services (AWS) に移行およびレプリケーションするためのマネージドソリューションを提供します。AWS DMS は、ソースとターゲットのデータベースが同じエンジンを使用する 同種の移行 と、異なるデータベース環境間の 異種の移行 の両方に対応しています。 AWS DMS は、PostgreSQL データベースから サポートされているターゲット へのデータ移行を容易にし、また サポートされているソース から PostgreSQL データベースへの移行も可能にします。これにより、企業がデータインフラストラクチャをクラウドに移行するための堅牢な経路を提供します。 ソリューションの概要 オープンソースの PostgreSQL は、頻繁に発生するバグ、セキュリティ問題、データ破損の問題の修正を含む 新しいマイナーバージョンとメジャーバージョンをリリース することがあります。一般的に、Amazon RDS は、 新しいエンジンバージョンが利用可能になってから 5 か月以内にサポート することを目指しています。特定のバージョンがサポートされなくなった場合には PostgreSQL インスタンスをアップグレードする必要があります。問題の解決や新しい改善の導入、あるいはコンプライアンスの遵守やデータ保護のためにも PostgreSQL インスタンスをアップグレードする必要があります。 進行中の AWS DMS タスクのソースまたはターゲットとして設定されている PostgreSQL データベースをアップグレードする場合は、これをアップグレード計画に組み込むことが重要です。 この記事では、PostgreSQL のマイナーバージョンまたはメジャーバージョンへのアップグレード中に AWS DMS タスクを処理するためのベストプラクティスについて説明します。 前提条件 この記事のソリューションをテストするには、以下のリソースが必要です： AWS DMS レプリケーションインスタンス RDS for PostgreSQL または Amazon Elastic Compute Cloud（Amazon EC2）かオンプレミスで実行されている PostgreSQL ソースとターゲットのエンドポイント ソースまたはターゲットでPostgreSQLを指定する AWS DMS タスク PostgreSQL のバージョンアップグレードの理解 PostgreSQL のアップグレードが AWS DMS タスクにどのように影響するかを詳しく見る前に、PostgreSQL におけるメジャーバージョンとマイナーバージョンのアップグレードについて明確に理解しておきましょう。 マイナーバージョンは、セキュリティの脆弱性を修正し、バグを修正し、一般的に新機能を追加しません。 マイナーリリースは内部ストレージ形式を変更せず、常に同じメジャーバージョン番号の前後のマイナーリリースと互換性があります。 例えば、バージョン 14.10 は、バージョン 14.9 およびバージョン 14.16 と互換性があります。 PostgreSQL のメジャーリリースでは、システムテーブル、データファイル、内部データストレージ形式も変更される可能性があります。RDS for PostgreSQL は、ネイティブの pg_upgrade ユーティリティを使用して、インスタンスを新しいメジャーバージョンにアップグレードします。アップグレードの詳細については、 Amazon RDS の PostgreSQL DB エンジンのアップグレード をご参照ください。 マイナーリリースとメジャーリリース、またはバージョンアップグレードのいずれもダウンタイムが発生するため、適切なメンテナンスウィンドウ内で実施する必要があります。できればデータベースへのクエリが最も少ない時間帯にスケジュールされたメンテナンスウィンドウをこのアップグレード作業のために計画することをお勧めします。 AWS DMS と PostgreSQL の連携 AWS DMS を使用して PostgreSQL ソースから PostgreSQL ターゲットにデータを移行する場合を想定しましょう。 フルロード中、AWS DMS はソースの PostgreSQL データベースに接続し、テーブルマッピングで定義されたテーブルで select * を実行してデータをアンロードします。ソースから取得したデータは、PostgreSQL ターゲットに向けてレプリケーションインスタンスの CSV ファイルに書き込まれます。PostgreSQL ターゲットの場合、AWS DMS は COPY コマンドを使用して、CSV ファイルのデータをターゲットの PostgreSQL テーブルにロードします。 移行中の継続的な変更を取り込むために、AWS DMS はソースの PostgreSQL データベースに論理レプリケーションスロットを作成します。スロットは、変更のストリームを表し、ソースの PostgreSQL データベースで実行された順序でクライアントに再生することができます。DMS は、レプリケーションスロットからの変更のロジカルデコーディングに test_decoding または pglogical プラグイン のいずれかを使用します。ソースの PostgreSQL データベースで pglogical プラグインが利用可能な場合、DMS は pglogical を使用してレプリケーションスロットを作成します。そうでない場合は、 test_decoding プラグインが使用されます。ソースから読み取られた変更は、レプリケーションインスタンス上のソーターコンポーネントに渡されます。ソーターコンポーネントはトランザクションをコミット順にソートし、その後、DMS タスクの設定に基づいて、順次またはバッチモードでこれらの変更をターゲットデータベースに適用します。 レプリケーションスロットは、フルロード + CDC および CDC のみのタスクにおいて重要な役割を果たします。 これは、ソースの PostgreSQL データベース上で必要なログ先行書き込み (WAL) ファイルを保持する役割を担っています。 ソースデータベース上でレプリケーションスロットが削除されると、DMS はソースデータベースからの継続的な変更を処理できなくなります。 PostgreSQL のアップグレードが AWS DMS タスクに与える影響 以下のセクションでは、ソースまたはターゲットの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード中に、DMS タスクをどのように扱うかについて説明します。 ソース PostgreSQL データベースのアップグレード時 フルロードのみの DMS タスクは、1 回限りのデータ移行用に設計されています。 これらのタスクは、ソースの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード後に安全に再開できます。 フルロード + CDC および CDC のみの DMS タスクは、進行中の変更をターゲットデータベースに継続的に複製します。PostgreSQL のアップグレード中に、フルロード + CDC および CDC のみの DMS タスクを処理する場合、次のセクションのベストプラクティスに従ってください。 マイナーリリースまたはバージョンアップグレード マイナーバージョンのアップグレードを行う前に、実行中の AWS DMS レプリケーションタスクを停止してください。マイナーバージョンのアップグレードが完了したら、DMS タスクを再開できます。 メジャーバージョンアップグレード 執筆時点で、DMS は PostgreSQL バージョン 9.4 以降 (9.x バージョン)、10.x、11.x、12.x、13.x、14.x、15.x、および 16.x をサポートしています。 メジャーバージョンアップグレードを実行する際は、レプリケーションインスタンスが新しい PostgreSQL バージョンをサポートしていることを確認してください。 pg_upgrade を使用してメジャーバージョンアップグレードを進めるには、ソースの PostgreSQL データベース上のレプリケーションスロットを削除する必要があります。これらのスロットを削除しないと、アップグレードプロセスに影響を与える可能性があります。レプリケーションスロットを削除せずにアップグレードを試みると、 pg_upgrade_precheck.log に 1 つ以上の論理レプリケーションスロットによってブロックされたためインスタンスをアップグレードできなかったというメッセージが表示され、アップグレードは失敗します。ただし、レプリケーションスロットを削除すると AWS DMS タスクが無効になり、進行中のレプリケーションタスクを再開できなくなります。 この問題に対処し、メジャーバージョンアップグレード中に進行中のレプリケーションタスクを管理するには、以下の手順を使用します： PostgreSQL データベースへのすべてのアプリケーション接続を停止します。以下を使用してアクティブな接続を監視します： select * from pg_stat_activity where datname = 'database_name'; 必要に応じて、残りの接続を以下のコマンドで終了します： select pg_terminate_backend(pid) from pg_stat_activity where datname = 'database_name'and pid <> pg_backend_pid(); AWS DMS タスクのメトリクスを監視して、 CDCLatencySource と CDCLatencyTarget の両方がゼロに近いことを確認します。これにより、DMS タスクが変更を遅延なく複製していることを確認できます。ターゲットで awsdms_txn_state を使用してタスクステータスを取得することもできます（タスク設定「 TaskRecoveryTableEnabled = True 」で有効にできます）。次の画像は、 CDCLatencySource と CDCLatencyTarget の Cloudwatch メトリクスを示しています。 レイテンシーがゼロに近づいたら、実行中のアクティブなレプリケーション DMS タスクをすべて停止してください。 ソースの PostgreSQL データベースから既存のレプリケーションスロットを削除します。 postgres=> select * from pg_replication_slots ; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size -----------------+-------------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+--------------- bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde | test_decoding | logical | 14405 | postgres | f | f | | | 898 | 0/5936F798 | 0/5F1A3440 | reserved | (1 row) postgres=> SELECT pg_drop_replication_slot('bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde'); pg_drop_replication_slot -------------------------- (1 row) レプリケーションスロットがないことを確認してください。 postgres=> select * from pg_replication_slots ; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size -----------+--------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+--------------- (0 rows) PostgreSQLデータベースのインプレイスアップグレードを完了してください。 アップグレードプロセスが正常に完了したことを確認します。データベースレベルの検証チェックを実行して、アップグレード後にデータベースが期待通りに動作していることを確認します。アプリケーションを開始する前に、DMS タスクを処理するために step 8 または step 9 のいずれかに従ってください。 CDC のみのタスクを新しく作成してください。タスク設定で、 ソーストランザクションの CDC 開始モード の カスタム CDC 開始モードを無効にする を選択します。古いタスクと同様に、他のタスク設定とテーブルマッピングを定義します。 タスクが作成されたら、CDC のみのタスクを開始します。これにより、ソースの PostgreSQL データベースに新しいレプリケーションスロットが作成され、レプリケーションスロットが作成された時点からの変更の移行が開始されます。 または、指定されたログシーケンス番号 (LSN) から開始する DMS CDC のみのタスクを使用して、ソース PostgreSQL データベースにレプリケーションスロットを手動で作成することもできます。ソースにレプリケーションスロットを作成し、 confirmed_flush_lsn を記録してください。 confirmed_flush_lsn は、論理スロットのコンシューマーが PostgreSQL エンジンにデータを受信したことを確認した最後の LSN を表します。 この LSN より前にコミットされたトランザクションに対応するデータは、もはや利用できません。 a. ソースエンドポイントの設定を変更し、ソース PostgreSQL データベースで作成した目的のスロットを SlotName として追加します。 b. タスク設定を変更してください。 カスタム CDC 開始モードを有効にする を選択し、 ログシーケンス番号を指定する (訳者注 : DMS マネジメントコンソールの新しいナビゲーションの場合 「ネイティブな CDC 開始点」) を選択して、 confirmed_flush_lsn から LSN を入力します。 DMS タスクを開始し、変更が問題なくターゲットデータベースに移行されていることを確認します。 アプリケーションを起動し、DMS CDC レプリケーションを監視します。 ターゲットの PostgreSQL データベースをアップグレードする時 AWS DMS CDC は、ターゲットの PostgreSQL データベースのマイナーバージョンアップグレードの影響を受けません。 DMS のターゲットとして設定された PostgreSQL データベースをアップグレードする前に、DMS タスクを停止し、マイナーバージョンアップグレードが成功した後に再開してください。 DMS のターゲットとして設定された PostgreSQL データベースでメジャーバージョンアップグレードを実行する場合： 現在のレプリケーションインスタンスエンジンのバージョンが新しい PostgreSQL バージョンをサポートしていることを確認してください。 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされている場合は、AWS DMS タスクを停止し、メジャーバージョンのアップグレードを完了してから DMS タスクを再開できます。 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされていない場合は、DMS タスクを停止して、ターゲットの PostgreSQL データベースでメジャーバージョンのアップグレードを完了する必要があります。また、レプリケーションインスタンスを、ターゲットの PostgreSQL データベースの現在のバージョンをサポートするバージョンにアップグレードする必要があります。ターゲットデータベースとソースデータベースの両方が互換性のあるメジャーバージョンに更新されたら、DMSタスクを再開できます。 クリーンアップ この投稿で作成したリソースを削除することで、変更を元に戻し、継続的な料金の発生を避けることができます： このソリューションのテストのために作成され、不要となった RDS for PostgreSQL インスタンス と EC2 インスタンス を削除します。 このソリューションのテストのために作成された AWS DMS タスクを削除します 。 AWS DMS のソースエンドポイントとターゲットエンドポイントを削除します 。 AWS DMS レプリケーションインスタンスを削除します 。 まとめ この投稿では、PostgreSQL データベースを AWS DMS のソースまたはターゲットとして構成している場合に、アップグレード時に DMS タスクをどのように扱うかについて説明しました。 このソリューションを試してみて、フィードバックや質問をコメントで共有してください。 About the Authors Veeramani A は Amazon Web Services のクラウドデータベースエンジニアで、AWS Database Migration Service とAmazon RDS for PostgreSQL で SME(Subject Matter Expert)を務めています。15 年以上にわたる多様なデータベーステクノロジーの経験を持つ彼は、AWS へのデータベース移行を進めるお客様に戦略的ガイダンスと技術的専門知識を提供しています。 Manoj Ponnurangam は、Amazon Web Services のクラウドデータベースエンジニアとして働いています。彼はAmazon RDS for Oracle、Amazon RDS for PostgreSQL、AWS DMS の SME(Subject Matter Expert) です。Manoj はリレーショナルデータベースを15 年扱ってきた経験があります。彼はお客様と協力して、さまざまなデータベースや移行プロジェクトに関する指導や技術支援を提供しています。

こんにちは！ アマゾン ウェブ サービス ジャパンのソリューションアーキテクト馬渕です。 2025 年 11 月 21 日 (金) 15:30-17:00 、AWS Japan の目黒オフィスにて、Dify と AWS に関するイベント「 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」の開催が決定しました。社内の生成 AI 活用を加速するために Dify を利用したいお客様、すでに Dify を利用していてさらにセキュアなデータも扱いたいお客様、Dify Enterprise を利用したいものの導入・運用に不安をお持ちのお客様に、今後のさらなる活用のためのヒントをご提供します。 Dify のご紹介と、 AWS とのシナジーのご紹介 Dify は、生成 AI アプリをノーコードで開発できるプラットフォームです。技術者以外でも AI アプリが作れる使いやすさから多くのお客様の注目を集めており、社内の生成 AI 基盤として PoC ・本番導入しているお客様が増えてきています。Dify には SaaS 利用するか自社の環境にセルフホストするかの 2 つの利用方法があり、後者のセルフホスト方式では多くのお客様が AWS 上で Dify をデプロイし、セキュアに社内の生成 AI 推進を実現しています。なお、前者の Dify Cloud も AWS 上で稼働しており 、AWS 上での Dify の稼働実績を十分に裏付けるものになっています。 また、AWS では、AWS 上に Dify をスケーラブルかつマネージドな環境でセルフホストするための AWS CDK サンプル や、それをワンクリックでデプロイするための AWS Generative AI Solution Box を公開しています。また、 AWS 上に簡易な構成で Dify 環境を構築し、その上で AI アプリケーションを構築する方法を学ぶワークショップ も公開しており、Dify を通じたお客様の生成 AI 活用をご支援しています。 GitHub 上で公開している Dify on AWS with CDK サンプルのアーキテクチャ Dify Enterprise のメリットとユースケース そして、 Dify をエンタープライズ規模でセキュアに社内利用するのに役立つのが Dify Enterprise です。OSS 版 Dify の機能に加えて、自社 IdP とのシングルサインイン機能や、マルチワークスペースによるアプリケーション利用の細かい権限管理など、社内利用に役立つガバナンス向上のための機能を備えています。 Dify Enterprise のライセンスは AWS Marketplace 上でも購入可能 になっており、これを用いて AWS 上にデプロイすればセルフホスト時の基盤の費用とライセンス費用を効率的に管理することが可能です。 Dify Enterprise を利用することで特にメリットのあるユースケースの 1 つが、セキュアなデータソースとの連携です。Dify には様々な SaaS やアプリケーションと連携できるプラグインのエコシステムがあり、例えば企業のデータウェアハウスと連携して社内データを活用した生成 AI アプリケーションを構築できます。Dify Enterprise の権限管理機能では、アプリケーションやプラグインへの細やかなアクセス可否を制御できるため、公開範囲が厳密なデータソースを連携するアプリケーションであっても安心して組み込むことが可能になります。 11/21(金) のイベントの詳細 今回のイベントでは、企業で社内の生成 AI 活用を推進する方を対象に、Dify Enterprise をご活用いただくための情報をご提供いたします。Dify の最新情報アップデートや、 Dify Enterprise ならではのセキュアなデータを扱うユースケースのご紹介に加えて、Dify の Eliter Partner でもあり AWS パートナーでもある株式会社リコー様にもご登壇いただき、Dify Enterprise の構築・運用のナレッジについてご共有いただきます。 開催概要 タイトル : 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 日時 : 2025年11月21日（金）15:30-17:00 (15:00 開場) 終了後、懇親会あり 参加費 : 無料 お申し込み方法 : イベントの ランディングページ よりフォームにアクセスしてお申し込みください 開催場所 : 〒153-0064 東京都目黒区下目黒1-8-1 ARCO TOWER 19 F JR線・東急目黒線・東京メトロ南北線・都営地下鉄三田線 目黒駅より徒歩約5分 [ google map ] [ ARCO TOWERへのアクセス方法 ] アジェンダ 開始 終了 コンテンツ プレゼンター 15:30 15:35 オープニング アマゾン ウェブ サービス ジャパン 合同会社 15:35 15:55 Dify Updates : RAG 2.0, MCP 株式会社 LangGenius 15:55 16:15 Dify Enterprise でセキュアなデータを扱おう 〜Snowflake と連携してインサイトを生む〜 株式会社 LangGenius アマゾン ウェブ サービス ジャパン 合同会社 16:15 16:30 Dify on AWS の選択肢と、AWS で Dify を使う理由 アマゾン ウェブ サービス ジャパン 合同会社 16:30 16:50 パートナーと進める Dify 活用 株式会社リコー 16:50 17:00 Q&A / クロージング アマゾン ウェブ サービス ジャパン 合同会社 17:00 18:00 懇親会 – ※ アジェンダやスピーカーは変更となる可能性がございます。 こんな課題をお持ちのお客様に 機密性の高いシステムと生成 AI の安全な連携方法を模索している 部門やプロジェクトごとに異なるセキュリティレベルでの AI 活用を検討している コンプライアンスを確保しながら生成 AI の全社展開を進めたい Dify を活用したいが、その導入・運用のナレッジやリソースに不安がある お申し込み方法 イベントの ランディングページ よりフォームにアクセスしてお申し込みください。会場の定員の都合上、抽選とさせていただく場合がございますのでご了承ください。ご不安・ご不明点がある場合は、 AWS の担当営業にお声がけください。

本記事は 2025 年 10 月 10 日に公開された “ Boosting Unit Test Automation at Audible with Amazon Q Developer ” を翻訳したものです。 Amazon の子会社である Audible は、オーディオストーリーテリングの大手プロデューサーかつプロバイダーです。オーディオブック、ポッドキャスト、特別にキュレーションされた Audible Originals を含む 100 万タイトル以上の膨大なライブラリを持っています。Audible は没入感のあるオーディオ体験で、日常を学習や想像力、エンターテイメントの機会に変えています。数百万のエンドユーザーがデバイス間でシームレスな体験を楽しめるよう、堅牢なテストが重要です。 テストカバレッジが不十分なコードベースを引き継いだ経験はありませんか？あるいは、締切に間に合わせるために急いでコードを書き、「後で」テストを追加すると約束したことは？私たちは皆そのような経験があります。テストは重要ですが、締切が迫ると優先度が下がりがちです。そこで Amazon Q Developer のエージェント機能が登場し、開発者のテスト生成アプローチを変革しています。このブログでは、Audible が Amazon Q Developer を活用してユニットテストカバレッジを向上させた方法を紹介します。 ソフトウェアテストのビジネスユースケース ベロシティの高い開発環境では、厳しい締切の下でテストサイクルが圧縮されることが多く、品質に問題が生じやすくなります。Amazon Q Developer は包括的な基準を維持しながらテストを加速し、この状況を変えます。自動テスト生成、エッジケースの特定、修正提案により、チームは短い時間で徹底的なテストを実行できます。これにより迅速なリリース、QA リソースの最適化、本番環境への準備強化を実現します。 適切なテストが実装されていない各関数は、作り直し、バグ、メンテナンスの課題につながる可能性があります。さらに、引き継いだコードベースは特別な課題を提示します。開発者は既存機能のテストを書くのに数週間を費やすか、テストなしでの開発を続けるかという難しい選択を迫られます。 Amazon Q Developer は適切なテストカバレッジに必要な時間と労力を削減し、これらの課題に対処します。テストを面倒な作業から効率的なプロセスに変え、チームがコード品質を確保しながら新機能の提供に集中できるようにします。 Amazon Q Developer：コードベースのテストカバレッジ拡張 Amazon Q Developer のエージェント機能は、ソフトウェアテスト生成に高度なアプローチを提供します。汎用的なテストを生成する従来ツールとは異なり、Amazon Q Developer はコードの意図、ビジネスロジック、エッジケースを分析します。単にテストを生成するだけでなく、コードの動作を包括的に検証する意味のあるテストスイートを作成します。 今回紹介する専用のテスト生成機能以外にも、Amazon Q Developer はテストを支援するさまざまな方法を提供します。テスト計画生成のための会話型プロンプトの使用、既存コードのテスト改善要求、テスト作成時の Amazon Q Developer とのペアプログラミングなどが可能です。テスト開発プロセス全体に AI アシスタンスを統合する柔軟性により、Amazon Q Developer は開発者にとって多用途なパートナーとなります。 Amazon Q Developer のワークフローアーキテクチャ 以下のアーキテクチャ図は、Audible がテスト生成とコード変換の両方で Amazon Q Developer を活用した方法を示しています。 Amazon Q Developer の開発プロセスは、2つの主要な機能を実証します。 テスト生成： Amazon Q Developer は Java クラスを分析し、ユニットテスト、エッジケーステスト、例外処理テストを含む包括的なテストスイートを作成します。 コード変換： Amazon Q Developer は自動移行タスクを実行します。これには JDK 8 から JDK 17/21 へのアップグレード、言語バージョン互換性の処理、 JUnit 4 から JUnit 5 への変換、テストフレームワークの構文とアノテーションのモダナイゼーション、非推奨 API とコードパターンの更新が含まれます。 この開発プロセスがとくに強力なのは、AI 機能と人間の専門知識を組み合わせる点です。エキスパート開発者が日常の開発プロセスで AI を活用できるようにします。Amazon Q Developer はコードベースを分析してコンテキストとして使用し、エッジケースを特定し、自動変換を実行します。一方で開発者はドメイン知識を適用し、出力がビジネス要件と期待される動作に合致することを確保します。 Amazon Q Developer の可能性を活用する Audible のアプローチ Audible チームは、Amazon Q Developer を活用してテストカバレッジを向上させるために以下のステップに従いました。 コード生成： Audible チームは Amazon Q Developer を活用し、Java クラスの追加ユニットテストを生成してテストカバレッジを強化しました。対象には静的メソッドや既存のテストケースを持つメソッドも含まれます。このアプローチは彼らの堅牢なテスト戦略を補完しました。Amazon Q Developer はクラス、メソッド、パラメータ、戻り値の型、例外を調べる能力を持っています。null 入力チェックや空文字列チェックなど、見落としやすいエッジケースをカバーするユニットテストを自動的に特定します。 対象を絞った要求： Audible チームは Amazon Q Developer に以下を提供するよう具体的に依頼しました。 Java クラス内の指定されたメソッドをカバーするユニットテストの提案 テストされていないエッジケースを対象とするユニットテストの推奨事項 エラー処理と例外シナリオに対処するテストケースの推奨事項 Audible チームはテスト生成とコード変換の両方で Amazon Q Developer を使用し、大幅な改善を達成しました。成功の鍵は体系的な開発プロセスで、対象を絞ったプロンプトとともに豊富なコンテキストを提供することでした。 開発者の作業の流れ Audible は自動化ツールからの出力をレビューするため、人間参加型のアプローチを採用しています。上記の開発プロセスは完全なプロセスを示しています。：（1）IDE でクラスファイルを開く、（2）特定のメソッドを選択してプロンプトを追加する、（3）この組み合わされたコンテキストを Amazon Q Developer に送信する、（4）生成されたテストを受け取る、（5）テストをレビューしてコードベースに統合する。 効果的なプロンプトとアプローチ Audible チームは Amazon Q Developer が対応できる対象を絞った要求を使用し、構造化されたアプローチに従いました。 コード生成： チームは Java クラスを Amazon Q Developer に提供し、個々のメソッドのテストを生成しました。対象には静的メソッドや、既にいくつかのテストがあるが完全なカバレッジが不足しているメソッドも含まれます。Amazon Q Developer はクラス、メソッド、パラメータ、戻り値の型、例外を調べ、null 入力チェックや空文字列チェックなどのエッジケースをカバーするユニットテストを自動的に特定しました。 特定のリクエストのための汎用サンプルプロンプト 基本的なテスト生成： 以下の Java メソッドのユニットテストを生成してください。すべての可能な入力シナリオとエッジケースをカバーすることに焦点を当ててください： [メソッドコードをここに] 以下のテストを含めてください： - 有効な入力シナリオ - Null 入力チェック - 空文字列検証 - 例外処理 エッジケースフォーカス： ユーザー入力を処理するこのメソッドがあります。見落としている可能性のあるエッジケースをカバーするユニットテストを提案してもらえますか？境界条件とエラーシナリオにとくに注意してください： [メソッドコードをここに] 手動フレームワーク移行（Q Developer Chat 経由）： この JUnit 4 テストを JUnit 5 形式に変換してください。アノテーションを更新し、適切な場合は最新の JUnit 5 機能を使用するようにしてください： [JUnit 4 テストコードをここに] 注意：Amazon Q Developer のコード変換機能は、コードベース全体で JUnit4 から JUnit5 への移行を自動的に処理できますが、Audible は上記のように手動でターゲット化された変換のために会話型インターフェイスも使用しました。両方のアプローチが利用可能です。自動変換の詳細については ドキュメント を参照してください。 テスト生成： チームのリクエストに基づいて、Amazon Q Developer は適切なアサーションとテストメソッドでこれらの領域に対処する特定のテスト提案を生成しました。 実装： 開発チームは、レビュー後に提案されたテストを実装しました。 ドキュメント： Amazon Q Developer は、テストの目的、テストがカバーしている機能の領域を説明するコメントを追加する能力を持っています。さらに、Amazon Q Developer は、readme ファイルやプロジェクトドキュメントなど、他の側面に関連するドキュメントを生成する能力も持っています。 定量化可能な結果 Amazon Q Developer を活用することで、Audible チームは以下を達成しました。 10 以上の主要パッケージ が包括的なユニットテストカバレッジを受けました テストクラスあたり約 1 時間 の節約（通常 8-10 の個別テストを含む） 5,000 以上のテストケース が Amazon Q Developer のコード変換と手動での会話支援の両方を使用して JUnit4 から JUnit5 に正常に移行されました Amazon Q Developer のコード変換を使用し、 JDK8 から JDK17 への移行にて  50 時間以上の手作業を節約 AI 支援変換による人的エラーの削減 主要機能の実証結果 Amazon Q Developer は、手動テストで見落とされがちないくつかの領域で優れていました。 包括的な例外テスト： 標準的な null 入力チェックと空文字列検証を超えて、 IllegalArgumentException 、 NullPointerException 、カスタムビジネス例外のテストを自動的に提案しました。例外の投げ方と特定のエラーメッセージの両方の検証を含みます。この体系的なアプローチによりテストカバレッジがより完全になり、エラー処理がより堅牢になりました。 自動エッジケース検出： Amazon Q Developer はプロンプトなしで null ポインタ例外処理のインライン提案を行い、プロセスをよりスムーズで高速にしました。 AI 支援による手動フレームワーク移行： Amazon Q Developer のパターン認識は会話支援を通じて移行プロセスを加速しました。チームはチャットを通じて Amazon Q Developer に JUnit4 から JUnit5 へのテスト構文を手動で変換するよう依頼できました。たとえば、以前のセットアップには @UseDataProvider と @DataProvider アノテーションを持つ JUnit4 構文がありました。必要な作業はコードブロックをハイライトし、Send to Prompt して、Amazon Q Developer にテストを JUnit5 互換にするよう依頼することだけでした。数秒以内に ParameterizedTest アノテーションと Stream of Arguments を持つ信頼性の高い JUnit5 テストを生成し、手動で実装できました。 コンテキスト分析： Amazon Q Developer は既存のコードベースを分析してパターンを認識し、チームのコーディングスタイルとテスト規約に一致するテストを生成しました。 まとめ Amazon Q Developer はテスト生成プロセスを時間のかかる作業から効率的な開発プロセスに変換し、チームが最小限の労力で包括的なテストカバレッジを達成できるようにします。これにより開発者はコード品質と信頼性を向上させながら、より価値の高い活動に集中できます。 ビジネスへの影響は大きく、テストが負担でなくなるとチームは自然により良いテスト手法を採用します。全体的なコード品質が向上し、より高速な開発サイクルとメンテナンス時間の削減という好循環を作り出します。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Kirankumar Chandrashekar は AWS の Generative AI Specialist Solutions Architect で、Q Developer、Kiro、AI を使用した Developer Productivity などの次世代開発者体験ツールに焦点を当てています。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code の深い専門知識を持ち、革新的な AI 駆動ソリューションを通じて顧客の開発サイクルを加速し、開発者の生産性を向上させることを支援しています。Amazon Q Developer を活用することで、チームがアプリケーションをより高速に構築し、日常的なタスクを自動化し、開発作業の流れを合理化できるようにしています。Kirankumar は、複雑な顧客の課題を解決しながら開発者の効率を向上させることに専念しており、音楽、料理、旅行を楽しんでいます。   Alex Torres は AWS の Senior Solutions Architect で、AWS 上でのアプリケーションのアーキテクチャ設計、設計、構築において Amazon.com をサポートしています。セキュリティ、ガバナンス、開発者向けエージェント AI の深い専門知識を持ち、顧客が最先端のクラウド技術を活用して人々の生活を形作る製品を作成することを支援しています。革新的な AWS ソリューションを通じて複雑な課題を解決するチームの支援に情熱を注ぎ、Alex は最高水準のセキュリティとガバナンスを維持しながら顧客の成功を推進することに専念しています。仕事以外では、料理とハイキングを楽しんでいます。   GK は Senior Customer Solutions Manager で、AWS の顧客としての Amazon をサポートする戦略的顧客アドバイザーです。AWS での 4 年間で、開発者の生産性向上と AWS サービス全体での Amazon のニーズの擁護に焦点を当て、ユーザー体験を向上させ、2つの組織間のより深い連携を推進してきました。高度な Amazon チームとの彼女の仕事は、最終的に内部と外部の両方の AWS 顧客に利益をもたらすソリューションの提供を支援しています。GK は、GenAI が開発者と非開発者の間のギャップをどのように埋めているかにとくに関心があり、GenAI とセキュリティの課題解決に多くの時間を費やしています。彼女はサンフランシスコベイエリアを拠点とし、ハイキングとキャンプを楽しんでいます。   Aditi Joshi は Audible のソフトウェアエンジニアで、Amazon プラットフォーム全体での Audible の存在拡大に取り組んでいます。フルスタック開発者として、主に Web 技術、クラウドサービス、JavaScript と Java などのプログラミング言語を使用して、Amazon iOS アプリでの Audible 購入機能の導入などの最近のプロジェクトを含む、クロスプラットフォーム統合機能を構築・強化しています。ユーザーインターフェイス開発、レスポンシブデザイン、Web 技術の専門知識を持ち、Audible オファーの紹介と Amazon エコシステム全体での Audible の可視性向上に焦点を当てています。Aditi は、クリーンで効率的なコードでスケーラブルなシステムを構築することに焦点を当てたソフトウェアアーキテクチャとユーザー体験に情熱を注いでいます。コーディング以外では、旅行、ヨガ、音楽鑑賞を楽しんでいます。   Sam Park は Audible のソフトウェア開発エンジニアで、Amazon プラットフォーム全体での Audible 機能の構築に焦点を当てています。Amazon Cart を通じた Audible 購入の有効化、および Amazon iOS と Android アプリ内での Audible の可視性拡大において重要な役割を果たしてきました。彼の仕事は、検索、商品ページ、チェックアウト、カート体験を含む Amazon エコシステム内の複数のタッチポイントにわたっています。Sam は、直感的な顧客体験を創出するソリューションの開発と、開発効率と生産性を向上させるための GenAI の活用に情熱を注いでいます。仕事以外では、旅行、バスケットボール、クリーブランド・キャバリアーズの応援を楽しんでいます。

2025 年 9 月 30 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer Meetup #3 生成AIの利用を中心としたソフトウェア開発の新しいアプローチであるAI-DLCおよびその活用実績のご紹介 」のイベントの様子をレポートします。 このイベントは、生成 AI を中心としたソフトウェア開発に対する新たなアプローチである、 AI 駆動開発ライフサイクル (AI-DLC) をテーマに実施しました。まず Developer Specialist SA の金森から AI-DLC が必要とされる背景と、AI-DLC の概要、進め方をご紹介しました。続いて、すでに AI-DLC を体験していただいた LINE ヤフー株式会社様、株式会社サイバーエージェント様、東京海上日動システムズ株式会社様に、実際の進め方や学び、今後の展望などについて発表していただきました。 現地参加・オンライン参加合わせて 200 名以上の方にご登録いただきました。参加者の方からは「実際に AI-DLC を実施した結果としての良い点、課題点が聞けたことが良かったです。」とのご感想をいただきました。AI-DLC を始めて知った方、これから AI-DLC の実施を検討されている方、すでに AI-DLC を体験されて改善に取り組まれている方、それぞれの皆様にご参考いただける情報をお届けしました。 現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 イベント概要 開催日時: 2025年9月30日 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー LINE ヤフー株式会社様「AI-DLC を活用した、 負荷試験環境の構築」 株式会社サイバーエージェント様「CA 流、現場と伴走する AI 駆動開発 (AI-DLC)」 東京海上日動システムズ株式会社様「AI-DLC 体験記」 Developer Specialist SA 金森政雄, Amazon Web Services Japan G.K. 「AI 駆動開発ライフサイクル (AI-DLC) ソフトウェアエンジニアリングの再構築」 登壇資料: こちらからダウンロード (zip) AI 駆動開発ライフサイクル(AI-DLC)ソフトウェアエンジニアリングの再構築 スピーカー: Developer Specialist SA 金森政雄, Amazon Web Services Japan G.K. はじめに、Developer スペシャリストソリューションアーキテクトの金森より、AI-DLC をご紹介しました。 まず、ソフトウェア開発における生成 AI 利用に対する既存のアプローチの課題を挙げ、AI-DLC が必要とされる背景について述べました。続いて、開発プロセスを生成 AI が制御し、開発者が最終的な責任を保持するという AI-DLC のコンセプトを示し、AI-DLC を構成する各ステップの詳細についてご説明しました。そして AI-DLC を実践するためのアプローチであり、ご登壇いただいた各社様にご体験いただいた、AI-DLC Unicorn Gym についてケーススタディに基づいて仕組みや期待される成果についてご説明しました。 AI-DLC についてさらに詳しく知りたい方は、添付資料と併せてブログ「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」をご覧ください。 LINEヤフー株式会社 様「AI-DLC を活用した、 負荷試験環境の構築」 LINE ヤフー株式会社様からは「AI-DLC を活用した、 負荷試験環境の構築」と題して、負荷試験環境の構築に AI-DLC を実践した事例についてご紹介いただきました。負荷試験ツールである Locust の設定や API、DB 初期化スクリプト等を AI-DLC を応用して作成した際の留意事項や実際の手順、工夫や今後の展望についてご説明いただきました。 一次情報は社員が普段から利用しているツールから MCP Server 経由で取得していることや、AI-DLC のアウトプットを新規担当者のキャッチアップ資料などに活用していること、AI-DLC を軽量にカスタマイズして取り入れていることをご紹介いただきました。AI エージェントとの対話内容の例や実際のアウトプットについてもご共有いただきました。これからの展望として、アウトプットであるドキュメントの更新・メンテナンスの仕組みについても検討されていることをご紹介いただきました。 株式会社サイバーエージェント様 「CA 流、現場と伴走する AI 駆動開発 (AI-DLC)」 株式会社サイバーエージェント様からは「CA 流、現場と伴走する AI 駆動開発」と題して、AI 駆動開発の全社展開を目指す背景とその実践についてお話しいただきました。AI 駆動開発の浸透・普及により AI 活用を強化し、競争力のあるプロダクトを作ることの重要性や、AI を前提とした開発文化の定着には全社への浸透、行動様式や意思決定プロセスの変革も必要である、と言う方針についてご紹介いただきました。既存プロジェクトへの AI-DLC の適用においてはドメイン知識に関するコンテキストの不足や、伝達の難しさについてお話しいただいたのち、Code を Single source of truth とすることや、ドメインごとに独立したコンテキストを与えるという AI へのドメイン知識の伝達方法をご説明いただきました。最後に、AI 活用の普及には継続的に開発チームとコミュニケーションし、二人三脚で進めていくことが重要であるとも述べていただきました。 AI-DLC Unicorn Gym 実施内容の詳細はブログ「 既存開発フローに AI-DLCを適用する 」と「 AWS 発「AI-DLC」ワークショップレポート！現場に適用するには？ 」も併せてご覧ください。 東京海上日動システムズ株式会社様 「AI-DLC 体験記」 東京海上日動システムズ株式会社様からは「AI-DLC 体験記」というタイトルで、AI-DLC ワークショップにご参加いただいた背景や準備、当日の様子や今後の展望についてご紹介いただきました。要件定義から実装フェーズの効率化の検証のため、既存システム改修と新規システム構築を対象とし、さまざまな部門・役割のメンバーが参加されたという背景をお話しいただきました。ワークショップ当日の成果物の例や完成したアプリケーションもご紹介いただきました。最後に各参加者からのフィードバックや、今後の AI-DLC を広く導入するための取り組みについてご説明いただきました。 AI-DLC Unicorn Gym 実施内容の詳細はブログ「 東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦 」も併せてご覧ください。 おわりに 今回の Amazon Q Developer Meetup #3 では、AI 駆動開発ライフサイクル (AI-DLC) をテーマとしてその概要と実際に体験されたお客様からの事例をご紹介いただきました。LINE ヤフー株式会社様、株式会社サイバーエージェント様、東京海上日動システムズ株式会社様にご登壇いただき、実施の背景や体験していただいた内容、学びや今後の展望についてお話しいただきました。今後も、開発者の皆様が生成 AI をより有効に活用していただくための AI-DLC をはじめとしたプラクティスや Amazon Q Developer や Kiro といったツールについて発信・アップデートをお届けします。 次回予告: Amazon Q Developer & Kiro Meetup #4 AWS サポートが語るよくある問い合わせ紹介とKiroのユースケース紹介 次回から Amazon Q Developer & Kiro Meetup にシリーズ名をアップデートします！ Amazon Q Developer & Kiro Meetup #4 では AWS サポートエンジニアから Amazon Q Developer に関するよくあるお問い合わせとその回答を、株式会社アド・ダイセン様から Kiro のユースケースをご紹介いただきます。皆様のご登録をお待ちしています。 参加登録: Amazon Q Developer Meetup & Kiro #4 AWS サポートが語るよくある問い合わせ紹介とKiroのユースケース紹介 開催日時: 2025年10月31日 (金) 19:00-21:00 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 お客様登壇 株式会社アド・ダイセン ソリューション部 部長 吉田 和弘 様「非エンジニアが生成AIでチームのイノベーション文化を創った実践事例」 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用をご支援しています。Amazon Q Developer や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。