はじめに 「 AWS 金融リファレンスアーキテクチャ 日本版 」は金融機関の厳格な要件に応えるためのリファレンス実装として 2022 年 10 月に初版をリリースして以来、継続的に進化を続けています。GitHub で公開されている本アーキテクチャは、金融機関が AWS 上でセキュアかつレジリエントなシステム構築を行うための実装例として活用いただいています。 図1：AWS 金融リファレンスアーキテクチャ日本版の概要図 勘定系ワークロードについて 金融システムの中でも特に勘定系システムは、預金、為替、融資などの中核業務を担う存在です。そのため、金融リファレンスアーキテクチャ日本版の 勘定系ワークロード ではミッションクリティカルなシステムに必要な高可用性を実現するためのアーキテクチャを提示しています。 この度、勘定系ワークロードに AWS の レジリエンスライフサイクルフレームワーク に基づいた機能追加を行いました。リエンスライフサイクルフレームワークは、「目標設定」「設計と実装」「評価とテスト」「運用」「対応と学習」という5つのステージで構成される継続的なプロセスであり、アプリケーションの回復力を段階的に向上させるためのガイドラインです。 今回のアップデート（v1.6）では、このフレームワークに沿って勘定系ワークロードの可用性と回復力を高める以下の3つの機能を追加しました： Amazon CloudWatch Synthetics Canary × AWS Step Functions  で構築する、東京リージョンから大阪リージョンへの自動切替 勘定元帳データベースとして  Amazon Aurora DSQL  を選択肢に追加 Amazon CloudWatch Application Signals の導入によるマイクロサービスのオブザーバビリティ強化 本ブログでは、これらの機能について詳しく解説します。 1. Amazon CloudWatch Synthetics Canary × AWS Step Functions で構築する、東京リージョンから大阪リージョンへの自動切替 従来の勘定系ワークロードのサンプルアプリケーションでは、災害発生時の東京リージョンから大阪リージョンへの切り替えは、人による判断後に手動オペレーションで実施する前提でした。今回のアップデートでは、より迅速なサービス復旧を優先するユースケースを想定し、外形監視の導入により人による判断を介さない自動フェイルオーバー機能を追加しました。 自動フェイルオーバーはアプリケーションに対して Synthetics Canary による外形監視でアプリケーションの正常性を判断しています。切り替えの自動化にあたっては、監視の誤検知による意図しないフェイルオーバーを防ぐため、2 つのリージョンから外形監視を行い、両リージョンの外形監視が同時に一定期間失敗した場合に、自動フェイルオーバーを実行する仕組みを採用しました。これにより特定のリージョン間の通信障害による意図しないフェイルオーバーの発生を回避しています。 具体的な処理フローは次のようになります。 東京リージョンで稼働するアプリケーションに対して、大阪リージョンとオレゴンリージョンから Canary による外形監視を行い、そのステータスを Amazon CloudWatch Alarm がチェック 1 分毎に Canary を実行し、 2 回連続で失敗すると CloudWatch Alarm が ALARM 状態へと遷移 大阪リージョンの CloudWatch Alarm が OK から ALARM 状態に遷移した際、 Amazon EventBridge Rules 経由で フェイルオーバー処理をキックする Step Functions ステートマシンを起動 2 リージョンの CloudWatch Alarm がともに ALARM 状態の場合、フェイルオーバー処理を実行 図2：フェイルオーバーの処理フロー サンプルアプリケーションでは仕組みのわかりやすさを優先し、短時間で自動フェイルオーバーする設定値を採用しました。自動フェイルオーバーの閾値はシステムに依存するものであり、要件に応じた適切な値の設計が必要です。運用要件によっては、自動フェイルオーバーは行わずに監視へ障害通知のみ行い、人による判断後に手動でのフェイルオーバーが現実的な設計となるでしょう。 2. 勘定元帳データベースとして Amazon Aurora を選択肢に追加 勘定系システムにおいてデータの整合性確保と迅速な災害復旧は最重要課題です。 Amazon Aurora PostgreSQL の Global Database を使用すると、リージョン間の非同期レプリケーションにより、優れた RPO と数分程度でのリージョンフェイルオーバーを迅速に実現することができます。一方で、金融機関の中には「RPO をさらに短縮したい」「リージョン障害時のサービス復旧をより迅速に実現したい」「複数のリージョンを Active-Active 構成で運用したい」というニーズもあります。 今 回の勘定系ワークロードの アップデートでは、2024 年に発表された Aurora DSQL を勘定系ワークロードの新たな選択肢として追加しました。Aurora DSQL は、マルチリージョンでの同期レプリケーションにより RPO をゼロにするとともに、リージョン障害時でも即座に他のリージョンでサービスを継続できます。 従来の Aurora PostgreSQL は引き続き有力な選択肢ですが、お客様の要件によっては Aurora DSQL も新たな選択肢として検討いただくことができます。 なお、今回のアップデートはドキュメントのみの更新となります。Aurora DSQL に対応した CDK コードの実装は今後のリリースを予定しています。 図3：Aurora DSQL の場合のリファレンスアーキテクチャ Aurora DSQL の最大の特徴は、マルチリージョンでの同期レプリケーションによる強力なデータ整合性です。Aurora PostgreSQL の Global Database では非同期レプリケーションのため若干の RPO が発生しますが、Aurora DSQL では同期レプリケーションにより RPO をゼロにすることができます。これは勘定系システムにおける重要なトランザクションデータの損失リスクを大幅に低減します。 また、Aurora DSQL は Active-Active 構成をサポートしており、複数のリージョンで同時に読み書き処理を実行できます。これにより、リージョン障害が発生した場合でも、他のリージョンで即座にサービスを継続することが可能です。従来のプライマリ・セカンダリ構成では、フェイルオーバー処理に数分を要していましたが、Aurora DSQL では障害発生時の切り替え時間を大幅に短縮できます。 Aurora DSQL の導入にあたっては、いくつかの設計上の考慮事項があります。特に Aurora DSQL は楽観的同時実行制御を採用しているため、高い同時実行性を持つアプリケーションでは、トランザクションのコミット時にシリアライゼーションエラーが発生する可能性があります。このため、アプリケーション側でのリトライ処理の実装が重要です。 より詳細な解説は GitHub リポジトリの ドキュメント を参照してください。 3. Amazon CloudWatch Application Signals の導入によるマイクロサービスのオブザーバビリティ強化 勘定系ワークロードのサンプルアプリケーションは、Balance Service（口座残高管理）、Count Service（取引回数管理）、Transaction Service（取引処理）、Transaction Worker（非同期処理のオーケストレーション）といった複数のマイクロサービスで構成されています。これらのサービスが相互に連携する分散システムでは、データベースなど個々のインフラレベルの監視だけではサービス全体の稼働状況を把握することが困難です。これまでの勘定系ワークロードでは  AWS Distro for OpenTelemetry (ADOT) による計測の仕組みは実装されており、マイクロサービスが稼働するコンテナからテレメトリ情報を送信することは出来ていたものの 、その情報を使ってサービス間の依存関係や影響範囲を可視化するためにはメトリクスの関連付けやダッシュボードの設計・構築をゼロから自分で行う必要がありました。 そこで今回のアップデートでは Amazon CloudWatch Application Signals を導入することで、マイクロサービス全体の可観測性を向上させました。CloudWatch Application Signals は、ADOT からアプリケーションのメトリクスやトレースを自動収集し、「アプリケーションの可用性とパフォーマンスを自動で見える化する」機能です。言わば、ADOT は観測の“センサー”で、CloudWatch Application Signals はそのデータを使って“健康診断レポート”を作る仕組みです。最も重要な改善は、サービス間の依存関係が自動的に可視化されることです。例えば、Transaction Service が Balance Service を呼び出す際の応答時間やエラー率がサービスマップ上でリアルタイムに表示されます。これにより、障害発生時に「どのサービスが影響を受けているか」「根本原因はどこにあるか」を迅速に特定できるようになりました。以下は可視化の例（各マイクロサービスの Latency）となります。 図4：各マイクロサービスの Latency の可視化 さらに、CloudWatch Application Signals が提供する SLI (Service Level Indicator) と SLO (Service Level Objective) ベースのマネジメント機能、標準ダッシュボードにより、ビジネス観点での健全性を把握することも可能になりました。従来の CPU 使用率やメモリ使用率といったインフラメトリクスに加えて、「取引処理の成功率」「口座残高照会の応答時間」といったビジネス価値に直結する指標を中心とした監視が可能になりました。これは金融サービスにとって特に重要で、システムの技術的な正常性とビジネス的な正常性を統合して評価できます。 分散トレーシングの強化も大きなメリットです。一つの取引リクエストが複数のマイクロサービスを経由する際、そのリクエストの完全なライフサイクルを追跡できます。例えば、振込処理で Transaction Service → Balance Service → Count Service という流れで処理される場合、各サービスでの処理時間、待機時間、エラーの発生箇所を一つのトレースで確認できます。これにより、パフォーマンスのボトルネックや障害の根本原因を特定する時間が大幅に短縮されます。 実際に運用の現場でご利用いただく際には、追加でダッシュボードを制作し、一目で各サービス、サービス間、もしくはサービス全体の稼働状況がわかるようにすることも多いでしょう。これらは運用体制など個別の環境に合わせて用意する必要がありますが、その構築の参考となるよう、サンプルとして簡易なダッシュボードがデプロイされるようにしてあります。 実装詳細は  GitHub リポジトリ をご確認ください。 まとめ 今回ご紹介した勘定系ワークロードの 3 つの機能強化は、AWS のレジリエンスライフサイクルフレームワークに沿った継続的な改善の一環です。 金融リファレンスアーキテクチャはオープンプロジェクトとして GitHub で公開しています。GitHub にはサンプルアプリケーションや自動フェイルオーバー機能、監視設定などの実装コードやドキュメントがすべて含まれています。これらはそのままデプロイして即座に動作確認をしていただくことができるため、金融機関の皆様がシステムを構築する際の参考としてご活用いただくことが可能です。 このリファレンスアーキテクチャを活用し、より安全で回復力の高いシステム構築に取り組まれることを願っています。また、より良い金融リファレンスアーキテクチャの発展に向けて、皆様からのフィードバックもお待ちしております。 本ブログ記事は、AWS のソリューションアーキテクト 嶋田朱里、疋田洋一、小野卓人、深森広英 が執筆いたしました。

本記事は、サザビーリーグ IRIS の今上様、奥様に寄稿いただいたものです。 はじめに サザビーリーグは、「ファッション」「生活雑貨」「飲食」を中心とした小売業を営み、北海道から沖縄まで全国約 600 店舗を展開しています。これまで、店舗とデータセンター間の通信には Cisco ASA5545 を中心とした VPN 構成を採用してきました。しかし、ASA5545 のサポート終了（ 2025 年 9 月末）を目前に控え、後継機器の選定が急務となりました。 本記事では、従来のオンプレミス機器更新では数千万円規模のコストが見込まれた中、AWS 上に構築した仮想ルータを活用することで、コストを大幅に削減し、店舗への影響を最小限に抑えながら VPN 基盤の移行を実現した事例をご紹介します。 既存構成と直面した課題 弊社では長年にわたり、約 400 店舗でルータを設置して ASA5545 と Easy VPN *1 で接続し、残りの 200 店舗では Cisco AnyConnect *2 を用いたリモートアクセス VPN を運用してきました。Easy VPN は店舗側が動的 IP アドレスでも接続可能な仕組みで、通信回線のコスト削減に大きく貢献していました。 *1 Easy VPN (Cisco Easy VPN) : Cisco 独自の VPN 技術で、クライアント側の設定を簡素化し、動的 IP アドレスでも VPN 接続を可能にする仕組み。店舗のような多拠点展開に適している。  *2 Cisco AnyConnect : SSL VPN クライアントソフトウェア。PC やモバイルデバイスから安全にリモートアクセスを実現する。 ところが、ASA5545 の後継機器である FirePower では Easy VPN がサポートされておらず、FlexVPN *3 への移行が必要となります。この変更は店舗ルータの設定変更を伴うため、遠隔での切替が困難でした。結果として、400 店舗に技術員を派遣し、ルータの設定変更または入替を行う必要があり、作業費だけで数千万円規模、機器購入・構築費を含めるとそれ以上のコストが見込まれました。加えて、店舗での作業中は通信が停止し、店舗の営業にも支障が出る可能性がありました。複数のベンダーに相談した結果、Cisco Meraki *4 ルータへの全店舗入替では機器費と作業費で数千万円規模、CATO *5 などの SASE *6 導入では年間ライセンス費用が数千万円規模と、いずれも現実的な選択肢とは言えませんでした。 *3 FlexVPN (Cisco IOS FlexVPN) : Cisco IOS XE ベースの次世代 VPN 技術。IKEv2 をベースとし、より柔軟な設定が可能だが、既存の Easy VPN 環境からの移行には設定変更が必要。 *4 Cisco Meraki : クラウド管理型ネットワーク機器。中央管理コンソールから全拠点のルータ・スイッチ・無線 AP を一元管理できるが、全店舗の機器入替が必要。 *5 CATO Networks : クラウドベースの SASE プラットフォームを提供するベンダー。 *6 SASE (Secure Access Service Edge) : ネットワークとセキュリティ機能をクラウドで統合的に提供する新しいアーキテクチャモデル。SD-WAN、ファイアウォール、ゼロトラストネットワークアクセスなどを包含する。 AWS 上の仮想ルータによる突破口 そこで弊社が選択したのが、AWS 上に Cisco Catalyst 8000V Edge Software（C8000V） *7 を構築する方式です。C8000V は仮想ルータでありながら Easy VPN をサポートしているため、店舗ルータの VPN Peer アドレスを変更するだけで切替が可能でした。これにより遠隔操作での切替が実現でき、現地作業が不要となりました。 VPN の動作確認や切替手順を確認するため、C8000V 環境を構築して PoC（Proof of Concept：概念実証）を実施しました。Cisco ルータによる疑似店舗環境で切替テストを行い、Cisco 921、891、892、1812 など、店舗で使用されているすべての機種で切替が成功しました。夜間に遠隔で切替作業を行うことで、店舗への影響も最小限に抑えることができました。また、仮想環境のため機器の発注や納品がなく、短期間、低コストで構築ができました。 *7 Cisco Catalyst 8000V Edge Software : Cisco IOS XE をベースとした仮想ルータ。Amazon EC2 インスタンス上で動作し、物理ルータと同等の機能を提供する。Easy VPN や FlexVPN の両方をサポート。 アーキテクチャ概要 移行後のアーキテクチャでは、店舗ルータから Easy VPN で Amazon EC2 上に構築した Cisco Catalyst 8000V に接続し、 AWS Transit Gateway を経由して AWS Direct Connect で社内ネットワークと接続する構成となっています。 AWS 移行に伴う技術的課題とその克服 BGP ルート数制限による通信断の危機 AWS 移行において最初に直面した課題は、AWS Direct Connect の BGP（Border Gateway Protocol：経路情報を交換するルーティングプロトコル）セッションが、デフォルトでは最大 100 ルートまでしかアドバタイズできないという仕様でした。弊社では約 400 店舗それぞれに固有の IP セグメントを割り当てており、POS レジや複合機など固定 IP で運用されている機器も多いため、セグメントの変更は現実的ではありませんでした。そのため、既存のセグメントを維持したまま、AWS へのルーティングを順次切り替えていく方針を採用しました。 しかし、100 ルートを超えたタイミングで、閉域網から AWS への通信が遮断される事態が発生しました。AWS への上限緩和申請も検討しましたが、複数の AWS パートナーを介し関連する AWS アカウントで申請するには社内外の調整に時間を要するため、最終的には店舗展開の順序を見直し、セグメントの集約を行うことでこの課題を乗り越えました。 C8000V ライセンスの適切な選定 C8000V ライセンスには複数の Tier（Essentials Tier 0〜3）があり、Tier が上がるほど VPN セッション数や IPsec スループットが増加します。弊社では既存のネットワークベンダーや Cisco 社にも相談しながら、現行の VPN セッション数やスループットを想定し、最適な Tier を慎重に選定しました。この選定は VPN 基盤の安定性に直結するため、導入前の段階で十分な情報収集と検討を行い、必要な性能を満たすライセンスを確保することで、安定した運用を実現しています。 VPN 構成の落とし穴── VGW の制約 AWS 上の VPN 環境と社内ネットワークを接続するにあたり、当初は Virtual Private Gateway（VGW） を検討しましたが、VGW では VPN 接続した店舗から社内ネットワークへのトランジット通信ができないという 制約 *8 がありました。そのため、AWS Direct Connect との接続点としては Transit Gateway（TGW）を採用しました。TGW を利用することで、店舗・Direct Connect（社内ネットワーク）を一元的に接続・ルーティングできる柔軟性を得られました。一方で TGW は通信量に応じたデータ処理料が発生するため、コスト面での考慮も必要でしたが、可用性と拡張性を優先して TGW を選定しました。 *8 単一の Direct Connect ゲートウェイにアタッチされた仮想インターフェイスと、同じ Direct Connect ゲートウェイに 　関連付けられた仮想プライベートゲートウェイの VPN 接続との間の直接的な通信は未サポート。 災害リスクへの備えとクラウドの強み 従来の VPN ゲートウェイはオンプレミスのデータセンターに設置していましたが、2019 年の台風 15 号では大規模停電が発生し、インターネット回線が約 1 週間停止しました。結果として、全国 600 店舗がネットワークから切断される事態が発生しました。今回の AWS 移行により、耐障害性の向上とハードウェア依存からの脱却を実現しました。さらに、構築・移行費用を最小限に抑え、店舗への影響も限定的にできました。既存店舗は Easy VPN で切替、新店舗やルータ入替店舗には FlexVPN を展開することで、柔軟かつ将来性のある VPN 基盤を構築できました。 成果と効果 今回のプロジェクトにより、従来のハードウェア更新では数千万円規模のコストが見込まれたところ、数百万円規模の PoC 投資で実現可能性を検証し、大幅なコスト削減を達成しました。遠隔切替による現地作業の削減により作業効率が向上し、店舗営業への影響を最小化できました。また、災害時の耐障害性が向上し、将来的な店舗展開への柔軟な対応も可能となりました。技術的な面では、仮想環境による迅速な展開が可能となり、クラウドベースの管理・監視により運用負荷が軽減されました。さらに、店舗数の増減への柔軟な対応というスケーラビリティも確保できています。 まとめ 今回のプロジェクトは、AWS の柔軟性と拡張性、そして仮想ルータの選択肢があったからこそ実現できました。従来のハードウェア更新アプローチでは実現困難だった大幅なコスト最適化、運用負荷軽減、可用性向上、そして将来性確保を達成することができました。 小売業界における店舗ネットワークの課題に対し、AWS クラウドサービスを活用した実践的なソリューション事例として、同様の課題を抱える企業の参考になれば幸いです。今後も AWS のクラウド基盤を活用し、店舗ネットワークのさらなる安定性と拡張性を追求していきます。 著者について 今上 一樹（Kazuki Imagami） 株式会社サザビーリーグＩＲＩＳ インフラグループ　プロジェクトマネージャー 2012年にサザビーリーグへ入社。社内SEとして、AWSをはじめとするクラウド基盤の構築・運用に加え、ネットワーク、グループウェア、セキュリティ対策など幅広い領域を担当。現場との対話を重視し、業務改善と安定運用の両立を目指して日々取り組んでいる。 奥 隆宏（Takahiro Oku） 株式会社サザビーリーグＩＲＩＳ インフラグループ　リーダー ネットワークに関する知見が高く、全国600店舗のVPN基盤をAWSへ移行するプロジェクトをはじめ、社内Proxyの更改、無線APの刷新など、インフラ領域の大規模案件を推進。安定性と拡張性を両立させる設計力と実行力に定評がある。

本日、 AWS Billing and Cost Management において、複数の組織からのコストと使用状況データを含むカスタム請求ビューを作成する新機能を発表しました。これにより、組織外の AWS アカウントとカスタム請求ビューを共有できるほか、複数のカスタム請求ビューを組み合わせて統合されたマルチソースビューを作成することも可能になりました。この機能を使用して、単一の AWS アカウントから AWS Cost Explorer および AWS Budgets を通じて、複数の組織にわたるコスト管理データにアクセスできるようになります。 マルチソースカスタム請求ビューを使用する理由 お客様のビジネスは、AWS 上の複数の組織 (管理アカウント) にまたがる場合があります。従来は、これらの各組織のコスト管理データに個別にアクセスすることしかできませんでした。マルチソースカスタム請求ビューを使用することで、複数の組織のコスト管理データを含む統合ビューを作成できるようになりました。これらのビューには、AWS Cost Explorer および AWS Budgets からアクセス可能で、組織をまたいで AWS のコストと使用状況を可視化、把握、管理できるとともに、予算設定による計画やコスト管理の改善が可能になります。 子会社、買収した企業、または独立した組織として運営されている事業部門を管理している場合でも、マルチソースカスタム請求ビューにより、AWS の請求やアカウント構造を統合することなく、必要な財務の可視性が一元的に提供されます。 前提条件 マルチソースカスタム請求ビューを使用する前に、以下の準備が必要です： 各組織で AWS Cost Explorer を有効にする AWS コスト管理のきめ細かなアクセス制御へ移行する 各組織の管理アカウントからカスタム請求ビューを作成する権限を持っていること AWS Resource Access Manager (RAM) を使用してアカウント間で請求ビューを共有する権限を持っていること 必要な権限の詳細については、「 AWS コスト管理にアイデンティティベースのポリシー (IAM ポリシー) を使用する 」を参照してください。 単一アカウントから複数の組織にまたがるコスト管理データへアクセスする あなたの会社が、AWS を利用している別の会社を買収したとします。あなたの会社は AnyCompany A という組織を管理しており、買収した会社は AnyCompany B という組織を管理しています。FinOps 管理者として、単一のアカウントから両方の組織全体のコスト管理データへアクセスできるようにしたいと考えています。これを実現するために、以下の手順でマルチソースカスタム請求ビューを作成することができます。 ステップ 1： AnyCompany B の組織からカスタム請求ビューを作成する まず、 AnyCompany B の組織に対応するすべてのコストと使用状況データを含む新しいカスタム請求ビューを作成します。 AnyCompany B の組織の管理アカウントから、 Billing and Cost Management コンソール に移動し、「コスト管理の設定」ページ内にある「Billing View (請求ビュー)」を選択します。新しいカスタム請求ビューを作成し、「コスト管理データを次の条件でフィルタリング」の項目で「フィルターなし (すべてのデータ)」を選択します。このカスタム請求ビューには、割引、クレジット、返金を含む組織全体のコストと使用状況データが含まれます。 図 1. AnyCompany B の組織のすべてのコスト管理データを含むカスタム請求ビューを作成する ステップ 2：カスタム請求ビューを AnyCompany A の組織の管理アカウントと共有する ビューを作成したら、 AnyCompany A の組織の管理アカウントに共有します。ビューを共有するには、ビューの作成後に「共有」タブにアクセスし [共有] を選択します。共有ページから、「任意のアカウントと共有」を選択します。管理権限として、 AWSRAMPermissionBillingViewFullAccess を選択します。これにより、受信者は当該ビューを他のビューのソースとして使用するための権限を得ます。これを利用して、複数の組織のコストと使用状況データを統合することができます。アカウントID 111122223333 ( AnyCompany A の組織の管理アカウント) を入力し、 [共有] を選択します。これで、作成したカスタム請求ビューが選択したアカウントと共有されます。 図 2. アカウント 111122223333 にカスタム請求ビューを共有する ステップ 3： AnyCompany A の組織の管理アカウントからリソース共有を承認する AnyCompany A の組織の管理アカウント 111122223333 にて、リソース共有の招待を承認します。承認は、Billing and Cost Management コンソールの「Billing View (請求ビュー) 」ページ内にある「請求ビューの招待」から実行できます。 AnyCompany B の組織の管理アカウントからの招待を選択し、承認 (Accept) してください。招待を承認できる期間は 12 時間であることに注意してください。12 時間が経過すると、招待は期限切れとなり、承認できなくなります。この操作は AWS RAM からも実行できます。詳細については、「 リソース共有への招待の受け入れと拒否 」を参照してください。 図 3. Billing and Cost Management コンソールからリソース共有の招待を受け取る ステップ 4： AnyCompany A の組織のカスタム請求ビューを作成する 111122223333 から、 AnyCompany A の組織に対応するコストと使用状況データを含むカスタム請求ビューを作成します。ステップ 1 と同じ手順に従ってください。 図 4. AnyCompany A の組織のカスタム請求ビューを作成する ステップ 5： AnyCompany A と AnyCompany B のデータを統合した新しいマルチソースカスタム請求ビューを作成する 111122223333 から、ステップ 1 とステップ 4 で作成したビューをデータソースとして使用する、新しいマルチソースビューを作成します。まず、 [Create multi-source view (マルチソースビューを作成)] を選択して、新しいカスタム請求ビューを作成します。 ステップ 1 とステップ 4 で作成したビューを選択してください。両方の組織のすべてのコスト管理データを含めるには、「コスト管理データを次の条件でフィルタリング」の項目で「フィルターなし (すべてのデータ)」を選択します。または、アカウント ID やコスト配分タグによってコストと使用状況データをフィルタリングすることもできます。情報を確認し、 [作成] を選択します。このカスタム請求ビューには、 AnyCompany A の組織と AnyCompany B の組織の両方のコストと使用状況データが含まれます。 図 5. マルチソースビューを作成する これで、アカウント 111122223333 は、単一の管理画面 (シングルペイン・オブ・グラス) から AnyCompany A と AnyCompany B のコスト管理データを統合的に参照できるようになり、セットアップが完了しました。Cost Explorer、Billing and Cost Management ダッシュボード、および AWS Budgets でカスタム請求ビューを使用して、両方の組織全体の支出パターンを監視、分析、予測することができます。このビューは、FinOps 活動専用のメンバーアカウントなど、他のアカウントとも共有でき、メンバーアカウントからすべての組織のコスト管理データにアクセスできるようになります。 各カスタム請求ビューには、最大 20 個のソース請求ビューを含めることができます。コンソールで、カスタム請求ビューのビュー詳細ページに移動し、「設定の詳細」タブを選択すると、「ソースビュー」の項目にすべてのソースが一覧表示されます。また、billing:ListSourceViewsForBillingView API を使用することもできます。 aws billing list-source-views-for-billing-view \ --arn "arn:aws:billing::111122223333:billingview/custom-multi-source-view" { "arn": "arn:aws:billing::111122223333:billingview/custom-multi-source-view", "sourceViews": { { "arn": "arn:aws:billing::444455556666:billingview/custom-custom-bv_anycompany_b", "type": CUSTOM, "associationStatus": ACTIVE }, { "arn": "arn:aws:billing::111122223333:billingview/custom-bv_anycompany_a", "type": CUSTOM, "associationStatus": ACTIVE } } } マルチソースカスタム請求ビューへのアクセスに関連するコストについて理解する Cost Explorer コンソールまたは AWS Budgets を通じたマルチソースカスタム請求ビューへのアクセスは無料です。Cost Explorer API を使用してプログラムでデータをクエリする場合は、各 API リクエストにつきソースごとに $0.01 が課金されます。例えば、カスタム請求ビューに 2 つのソースが含まれている場合、各 API 呼び出しのコストは $0.02 になります。 結論 カスタム請求ビューを用いて、複数の組織にまたがるコスト管理データの統合ビューを作成できるようになり、ビジネス全体の AWS 支出を効果的に管理するために必要な財務の可視性が提供されます。Cost Explorer や AWS Budgets などの既存の AWS コスト管理ツールを活用することで、カスタムデータパイプラインを構築したり、複雑なレポートインフラストラクチャを維持することなく、複数の組織におけるコストを監視および最適化できます。マルチソースカスタム請求ビューを開始するには、 請求ビューユーザーガイド にアクセスし、AWS Billing and Cost Management コンソールの「コスト管理の設定」ページから最初のカスタム請求ビューを作成してください。 翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文は こちら です。 Erik Nestorovic Erik は AWS Billing and Cost Management サービスのシニアテクニカルプロダクトマネージャーです。彼は、お客様が必要なデータにアクセスできるようにすることで、クラウド財務管理の目標達成を支援するツールの構築に注力しています。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週から週刊 AWS を皆様にお届けする新たなメンバーとして活動させていただきます。どうぞよろしくお願いします！ では早速、今週も 週刊AWS をお届けします。 2025年12月11日（木）に、The Linux Foundation 主催、アマゾン ウェブ サービス ジャパン合同会社からも登壇予定の 「OpenSearchCon JAPAN」 が開催されます。本イベントでは、OpenSearchに関する最新情報や先端技術事例、ユースケースや今後のロードマップなどが紹介される予定です。OpenSearchを利用したデータ分析やリアルタイム検索基盤の最新トレンドを学びたい方、バージョン移行での課題解決事例に関心がある方に特におすすめとなっております。ぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月20日週の主要なアップデート 10/20(月) Amazon ECS が API アクティビティの洞察のために AWS CloudTrail データイベントを公開開始 Amazon ECS で AWS CloudTrail データイベントがサポートされ、ECS Agent の API アクティビティを詳細に監視できるようになりました。従来では見えなかった ECS エージェントの動作 (タスクのポーリングやテレメトリセッション開始など) が記録され、セキュリティ監査やトラブルシューティングが格段に効率化されます。運用チームはコンテナインスタンスの問題を迅速に特定でき、コンプライアンス要件も満たしやすくなります。詳細は こちらの Developer Guide をご参照ください。 10/21(火) Amazon CloudWatch Database Insights が RDS for SQL Server のオンデマンド分析を提供開始 Amazon CloudWatch Database Insights が RDS for SQL Server のオンデマンド分析に対応しました。従来は数時間かかっていたデータベースの性能問題の特定が、機械学習による自動分析で数分に短縮されます。性能のボトルネックを自動検出し、具体的な改善提案も提供されるため、データベース管理者の負担が大幅に軽減されます。RDS コンソール、AWS API、AWS SDK、または AWS CloudFormation を使用して、RDS for SQL Server データベースで Advanced モードを有効にすることで利用開始できます。 Amazon Bedrock Data Automation が動画の追加フォーマットと画像の高速処理をサポート Amazon Bedrock Data Automation で新しい動画フォーマット AVI、MKV、WEBM と新コーデックをサポート開始しました。これまで対応していなかった古いアーカイブ映像や Web 動画も分析可能となりました。さらに画像処理が最大 50% 高速化し、大量の画像データをより短時間で処理できます。企業の動画アーカイブ活用や AI アプリケーションの処理速度向上に役立ちます。詳細は こちらのドキュメントをご参照ください。 AWS、Nitro Enclaves が全ての AWS リージョンで利用可能になったことを発表 AWS Nitro Enclaves が全リージョンで利用可能になりました。これは EC2 インスタンス内で機密データを安全に処理するための隔離された環境 (エンクレーブ) を作成できる機能です。従来は一部リージョンでしか使えませんでしたが、今回ニュージーランド、タイ、ジャカルタ、スペイン、チューリッヒなど多数のリージョンに拡大されました。金融データや個人情報など高度な機密性が求められるアプリケーションで、攻撃対象領域を大幅に削減できます。Amazon EC2 インスタンスと Nitro Enclaves と併用される他の AWS サービスの仕様料金以外に追加料金は不要です。詳細は こちらをご参照ください。 10/22(水) AWS の Customer Carbon Footprint Tool に Scope 3 排出量データが追加されました AWS Customer Carbon Footprint Tool (CCFT) が Scope 3 排出データに対応し、クラウド利用による CO2 排出量をより包括的に把握できるようになった。従来は直接的な排出のみの計測でしたが、今回のアップデートでサーバーの製造、AWS 施設への電力供給、データセンター設備輸送まで含むライフサイクル全体の排出量を可視化できます。2022年1月からの履歴データも確認できます。これにより、企業の持続可能性目標達成に向けた意思決定に活用可能です。詳細は こちらをご参照ください。 Amazon S3 メタデータが 3 つの追加 AWS リージョンで利用可能になりました Amazon S3 Metadata がフランクフルト、アイルランド、東京リージョンで新たに利用可能になりました。S3 Metadata は、S3 バケット内のオブジェクトメタデータを自動的に収集し、ほぼリアルタイムで更新される Apache Iceberg テーブルとして提供する完全マネージドサービスです。バケット内のオブジェクトが追加・更新・削除されると、メタデータテーブルも自動的に同期されるため、常に最新の状態を保ちます。これまで手動で管理していたメタデータの整理が自動化され、ビジネス分析や機械学習の推論処理でデータを効率的に活用できるようになります。詳細は こちらの Blog 記事をご参照ください。 Amazon CloudWatch がインタラクティブなインシデントレポート機能を導入 Amazon CloudWatch で、インシデント発生後の分析レポートを自動生成する機能が追加されました。従来は手動でデータを収集して報告書を作成する必要がありましたが、新機能ではテレメトリデータ、お客様の入力、調査中に実行されたアクションを自動的に収集・関連付けし数分で包括的なレポートが完成します。レポートには、エグゼクティブサマリー、イベントのタイムライン、影響評価、実行可能な推奨事項まで含まれるため、インシデント後分析を通じた運用体制の継続的改善に役立ちます。東京リージョンを含む 12 リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 10/23(木) 一般提供開始: リアルタイム入札ワークロード向け AWS RTB Fabric AWS RTB Fabric がリアルタイム広告向けのフルマネージドサービスとして一般提供開始されました。広告技術 (AdTech) パートナーとの接続を 3 ステップで実現し、プライベートで高性能なネットワーク環境を通じて 1 桁ミリ秒の超低遅延を実現するフルマネージドサービスです。従来の標準的なクラウドネットワーキングコストを最大 80 % 削減でき、前払いも不要です。内蔵モジュールによりトラフィックの最適化、入札効率の向上、入札レスポンス率の向上が可能です。AdTech 企業とより迅速に接続してターゲットオーディエンスにリーチし、キャンペーン規模を拡大、広告費用対効果を高めるためのパフォーマンスを向上させることができます。東京リージョンを含む 6 リージョンで利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon Quick Sight が新しいデータ準備エクスペリエンスの一般提供を発表 Amazon Quick Sight で新しいビジュアルデータ準備機能が正式提供開始されました。これまでプログラミングや SQL が必要だった高度なデータ変換が、コードを書かずに実行できるようになります。データのクリーニングや結合作業を直感的な操作で行え、データセットの参照レベルも 3 から 10 に拡張されました。また、異なるデータソース間の結合処理能力が 1GB から 20GB へと 20 倍向上したことで、より大規模なデータ処理が可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Connect アウトバウンドキャンペーンがプレビューダイヤリングをサポートし、エージェントの制御を強化 Amazon Connect のアウトバウンドキャンペーンで preview dialing (プレビューダイヤル) モードが追加されました。今回のアップデートでエージェントは顧客の名前や残高、過去のやり取り履歴を事前に確認してから最適なタイミングで電話をかけられるようになりました。これにより顧客エンゲージメントの向上とコンプライアンス要件への対応が可能になります。東京リージョンを含む 10 のリージョンで利用できます。詳細は こちらの Web ページをご参照ください。 10/24(金) AWS Lambda が非同期呼び出しの最大ペイロードサイズを 256 KB から 1 MB に増加 AWS Lambda の非同期呼び出しで送信できるデータサイズが 256 KB から 1 MB に拡大されました。これまで大きなデータを扱う際は分割や圧縮が必要でしたが、今回のアップデートにより機械学習の出力データや詳細なユーザープロファイルなど、より複雑で大容量のデータを一度に処理できるようになります。詳細は こちらのドキュメント をご参照ください。 AWS Transfer Family でサーバーの ID プロバイダータイプの変更がサポートされました AWS Transfer Family で、サービス停止なしに認証プロバイダー (IdP) タイプを変更できるようになりました。従来は認証方式を変更する際にサーバーを停止する必要がありましたが、今回のアップデートにより SFTP や FTPS サーバーの運用中に、サービス管理認証、Active Directory、カスタム IdP 間でシームレスに切り替え可能です。これにより企業の認証システム統合やセキュリティ要件変更時も、ファイル転送サービスを継続しながら対応できます。詳細は こちらのドキュメントをご参照ください。 Aurora DSQL がリソースベースポリシーをサポート開始 Amazon Aurora DSQL でリソースベースポリシーがサポート開始されました。このアップデートにより、特定の IAM プリンシパルに対して実行可能なアクションを直接リソースレベルで指定できるようになりました。さらに Block Public Access (BPA) 機能も利用でき、パブリックエンドポイントや VPC エンドポイントへのアクセスをより厳密に制限可能です。バージニア北部、オハイオ、オレゴン、大阪、東京、ソウル、アイルランド、ロンドン、パリ、フランクフルトリージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japanのソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きなAWSサービスはAmazon Lightsail とAmazon Q Developer で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。ようやく秋の深まりを感じる空気となりました。今年も残すところあと2ヶ月ほどとなりましたが、生成AIの世界は相変わらず目まぐるしい進化を続けています。AWS re:Invent 2025 (2025年12月1日～5日) の開催も近づいてきており、今年はどのような革新的な発表があるのか、今から楽しみでなりません。特に生成AI分野での発表の期待が高まりますね。 直前のご案内になりますが、「AWS 生成 AI 活用ワークショップ～ Amazon Q Developer で生成 AI の一歩先へ！ ～」という Amazon Q Developer のワークショップイベントを 10月29日(水) に開催予定です。ご興味のある方は 申し込みページ を参照ください。 そして繰り返しのお知らせですが「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「NTT西日本の AWS 事例：Amazon Bedrock Knowledge Bases を活用した営業支援 AI ボットの開発」を公開 NTT西日本様がビジネスチャット「elgana」上でAmazon Bedrock Knowledge Basesを活用した営業支援AIボットを開発し、営業担当者の情報検索効率化を実現しました。従来は複数システムに散在していた膨大なマニュアルや資料の検索に時間がかかっていた課題を、RAG（Retrieval-Augmented Generation）技術により解決し、質問に対して即座に回答を提示するとともに関連マニュアルページへのリンクも提供する仕組みを構築しています。実際の営業担当者によるトライアルでは「知りたい情報に素早くアクセスできる」「マニュアルを探す時間が減った」との好評を得ており、今後はAmazon Bedrock AgentCoreを活用したAgentic RAGへの発展も視野に入れています。企業内ナレッジを効果的に活用したRAGシステムの具体的な実装例として、メタデータフィルタリングによる検索精度向上や、AI回答の信頼性確保の手法など、実用的な生成AIアプリケーション構築のベストプラクティスを学べる事例となっています。 ブログ記事「[資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催しました」を公開 2025 年 9 月 30 日に AWS Startup Loft Tokyo (目黒) で開催された「Amazon Q Developer Meetup #3 生成AIの利用を中心としたソフトウェア開発の新しいアプローチであるAI-DLCおよびその活用実績のご紹介」のイベントの様子をレポートしています。このイベントは、生成 AI を中心としたソフトウェア開発に対する新たなアプローチである、AI 駆動開発ライフサイクル (AI-DLC) をテーマに実施しました。LINEヤフー様、サイバーエージェント様、東京海上日動システムズ様の3社が実際にAI-DLCを体験した事例を発表し、負荷試験環境構築での活用事例や全社展開への取り組み、金融業界でのワークショップ体験談など、具体的な実践方法や学び、課題点について発表していただきました。 ブログ記事「Amazon Q Developer で Audible のユニットテスト自動化を強化」を公開 Amazonの子会社であるAudibleが、Amazon Q Developerのエージェント機能を活用してユニットテストカバレッジの向上と開発効率化を実現しました。従来は締切に追われてテスト作成が後回しになりがちだった課題に対し、Amazon Q Developerがコードの意図やビジネスロジック、エッジケースを自動分析してJavaクラスの包括的なテストスイートを生成し、null入力チェックや例外処理テストまで網羅的にカバーしています。その結果、10以上の主要パッケージで包括的テストカバレッジを実現し、テストクラスあたり約1時間の節約、5,000以上のテストケースのJUnit4からJUnit5への移行、JDK8からJDK17への移行で50時間以上の手作業削減を達成しました。単純なコード生成を超えて開発プロセス全体の効率化を実現する具体例として、AI支援によるテスト駆動開発の実践方法や、レガシーコードの品質向上アプローチ、人間とAIの協働による継続的品質改善の手法を学べる事例となっています。 AWS生成AI国内事例ブログ「株式会社ファイン様のAWS 生成AI活用事例：建築AIパース生成サービスにレコメンドAI機能を実装。担当者の商品検索時間を75%削減し、顧客満足度も向上。」を公開 建築CGのデジタル素材を提供する株式会社ファイン様は既存の建築AIパース生成サービス「AI PERS」にレコメンド機能を追加して業務課題を解決しました。従来は生成されたパース画像から実際の商品を探すのに時間がかかっていた問題に対し、Amazon SageMaker、Amazon Bedrock、Amazon Titan Multimodal Embeddingsを活用してベクトル検索システムを構築し、設計からわずか1か月半で実装を完了しています。システムでは生成されたAIパース画像から床部分を自動切り抜きしてベクトル化し、Amazon RDS PostgreSQLで類似商品を検索することで、おすすめ度を瞬時に表示する仕組みを実現しました。 AWS生成AI国内事例ブログ「株式会社クリエイティブ・ウェブ様の AWS 生成 AI 事例「Amazon Bedrock を活用したコールセンターお問い合わせ管理システムの実現」のご紹介」を公開 システム・PCサポート・Webサイト関連の問い合わせ対応サービスを提供する株式会社クリエイティブ・ウェブ様が、Amazon BedrockによるRAG（Retrieval-Augmented Generation）技術を活用してコールセンターお問い合わせ管理システム「コールトラック」を開発し、業務効率化と品質向上を実現しました。従来は手作業による情報管理や対応品質のばらつき、過去ナレッジの活用困難といった課題があったものの、Amazon OpenSearch Service、AWS Lambda、Amazon RDS、Amazon S3を組み合わせたサーバーレス構成により、過去の対応履歴から最適な対応をサジェストする機能を構築しています。その結果、初回解決率30%向上、平均対応時間40%削減、情報検索時間を従来の5分から1分以下に短縮するなど大幅な業務改善を達成し、新人スタッフでもベテランと同等の対応品質を提供できるようになりました。さらにAI による自動要約機能や対応履歴の自動評価機能により、継続的な品質向上とナレッジの蓄積も実現しています。蓄積された過去データをRAGシステムで有効活用する実践例として、コールセンター業務の包括的なデジタル変革手法や、マネージドサービスを活用した短期間でのAIシステム構築アプローチを学べる事例となっています。 ブログ記事「製造・金融・メディア・レジャー 業界における生成AI活用の最前線」を公開 2025年11月4日にAWS目黒オフィスで「AWS Industry GenAI Innovation Day」が開催されます。金融業界の音声データ分析によるコンプライアンス自動化、製造業界のAIカメラ活用設備管理、エンターテイメント業界のSNS動画自動編集など、製造・金融・エンターテイメント・レジャー各業界の具体的課題を解決する実践的なAIソリューションを体験できるイベントの内容が紹介されています。 AWS生成AI国内事例ブログ「株式会社 WhiteBox 様の AWS 生成 AI 活用事例 : Amazon Bedrock で AI エージェントを活用した次世代飲み会幹事代行システム「KanpAi」を開発。 AI 駆動開発の活用で数か月の開発工数を3週間に削減。」を公開 株式会社WhiteBox様が、Amazon Bedrockを活用してAIエージェントによる次世代飲み会幹事代行システム「KanpAi」を開発し、AI駆動開発の活用により通常数ヶ月を要する開発工数をわずか3週間に短縮することに成功しました。システムは会場リサーチ提案、Web予約、二次会リサーチ提案、電話予約、精算計算、継続学習の6つの専門AIエージェントで構成され、それぞれがAWS LambdaとAmazon Bedrockで実装されており、Amazon RekognitionやAmazon Connectも活用して高度な機能を実現しています。複数の専門AIエージェントを組み合わせたマルチエージェントシステムの構築例として、各エージェントの役割分担や連携手法、AI駆動開発による劇的な開発期間短縮の実現方法などを学べる事例となっています。 ブログ記事「Kiro によるマルチモーダル開発：設計から完成まで」を公開 AWSの開発エージェントツールKiroが、ホワイトボードの手描き図から実際のプロダクションコードまでを一貫して処理するマルチモーダル開発アプローチを実現し、金融取引システムの開発において従来数週間を要する作業をわずか3日間で完成させることに成功しました。Kiroは手描きのER図を理解してTypeScriptモデルを自動生成し、アーキテクチャの議論からKubernetesマニフェストまでを一気通貫で作成することで、設計の整合性を保ちながら各開発フェーズを連携させています。テキストベースの対話を超えて視覚的な設計情報も同時に処理できるマルチモーダルAIの活用により、設計ビジョンと実装の間のギャップを解消し、より迅速で正確なシステム開発が可能となる新しいアプローチを紹介しています。 AWS生成AI国内事例ブログ「株式会社リネア様の AWS 生成 AI 事例：GraphRAGで実現するサプライチェーンリスク検知と管理への取り組み」を公開 株式会社リネア様が、Amazon NeptuneとAmazon Bedrockを組み合わせたGraphRAG（Graph Retrieval-Augmented Generation）技術を活用し、サプライチェーン上の人権リスク検知サービスの開発に取り組み、従来5日から数ヶ月を要していたサプライチェーンリスク調査を1日程度に短縮することに成功しました。Amazon Neptuneでグラフデータベースとして企業間の複雑な関係性を格納し、Amazon Bedrockで自然言語による問い合わせを複雑なグラフクエリに変換する仕組みを構築しています。ユーザーが複雑なクエリやグラフ探索アルゴリズムを意識することなく、文章での質問だけで多段の取引関係を効率的に分析できます。複雑な関係性データを自然言語で効率的に分析できるアプローチとして参考になる事例です。 サービスアップデート Amazon Nova がコンテンツモデレーション設定のカスタマイズをサポート Amazon Nova が、機密コンテンツの処理や生成が必要な特定の用途において、コンテンツモデレーション設定のカスタマイズ機能をサポート開始しました。この新機能により、そうした要件を持つ企業は、安全性、機密コンテンツ、公平性、セキュリティの4つのドメインにおいて、自社のビジネス要件に応じた細かな設定調整が可能になります。ただし、児童保護やプライバシー保護といった基本的な安全対策は変更できない仕組みになっており、責任あるAI利用が担保されています。この機能は現在、米国東部 (バージニア北部)リージョンで Amazon Nova Lite および Amazon Nova Pro にて利用可能です。 Amazon Bedrock Data Automationが動画フォーマット追加対応と画像処理高速化を実現 Amazon Bedrock Data Automation が新たにAVI、MKV、WEBM形式の動画ファイルとAV1、MPEG-4 Visual（Part 2）コーデックに対応し、さらに画像処理速度が最大50%向上しました。Amazon Bedrock Data Automation は、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、ヨーロッパ (アイルランド)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、米国西部 (オレゴン) と米国東部 (バージニア北部)、GovCloud (米国西部) の 8 つの AWS リージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

本ブログは ロジカル・アーツ株式会社様 と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 はじめに 近年、コールセンター業務における効率化と顧客体験の向上は、多くの企業にとって重要な課題となっています。特に、オペレーターの業務負荷軽減やサービス品質の均一化は、欠かせない要素です。 今回は、ロジカル・アーツ様が AWS 上で構築した次世代コールセンターソリューションの取り組みについてご紹介します。同社は、Amazon Connect と Amazon Bedrock を組み合わせることで、データ処理の高速化と生成 AI の活用を実現し、コールセンター業務の課題解決に取り組んでいます。 課題と背景 多くのコンタクトセンターが抱える課題は、日々の業務の中で顕在化しています。たとえば、アフターコールワークの負担が大きく、オペレーターは通話後の記録や処理に多くの時間を取られており、ロジカル・アーツ様の事前調査によれば１コールにつき約 20 分もの時間を要することがあります。オペレーターごとに対応品質にばらつきが生じやすく、顧客満足度の安定化が難しいという悩みもあります。さらに、アウトバウンドコールを手作業で行っている現場では、効率が上がらず、オペレーターの負担やコストが増大しがちです。加えて、リモート席を含むオペレーターの状況管理が煩雑になり、管理者の負担も大きくなっています。 こうした課題は、業務効率や顧客体験、従業員体験の向上を阻む大きな壁となっています。同社は、これらの悩みを解決するために、AI による自動文字起こしや会話議事録作成、プレディクティブコール、シートマップなどの機能を提供し、短期間で業務効率化と品質向上を目指しました。 特に、多くの複雑なオペレーターの方の課題解決に応えていくためには、CTI システムの基盤強化と先進技術の導入が不可欠でした。 AWS サービスの採用理由 同社は、生成 AI について検証した結果、特に長文処理で Anthropic 社の Claude はコストも安く、ハルシネーションの課題をクリアし、求めていたレベルの効果を安定して実現することができました。そして、AI による自動文字起こしや会話議事録作成では最適な AI モデルを柔軟に選択できるようにする構想があったため、複数の大規模言語モデルを単一サービスから利用できる Amazon Bedrock が理想的でした。 また、CTI アプリケーション開発の難しさと工数の多さという課題に対して、Amazon Connect を基盤としたアプローチが最適解だと判断しました。Amazon Connect は海外も含めて多くの実績があり信頼性が高く、CTI 基盤として採用していることは、セキュリティ面においてもお客様への訴求力が高く、安心してご利用いただける要素でした。 AWS プラットフォーム上で一貫したアーキテクチャを構築できる点も重要な採用理由となりました。データ処理の高速化と生成 AI の統合において、AWS のサービス群がシームレスに連携することで、高機能かつ拡張性のあるソリューションを実現できます。さらに、AWS 環境内に閉じたセキュアな環境を構築でき、1 つのプラットフォームで完結することで請求書の簡略化も可能となることが決め手となりました。 ソリューションの概要 同社が提供する「 HARMONY 」は、Amazon Connect の標準機能に、生成 AI を活用した独自の AI 機能をプラスしたブラウザベースのソフトウェアです。クラウドベースのオールインワンプラットフォームとして、業務効率化や利便性向上を短期間で実現できるのが特長です。Amazon Connect の標準 CCP（ソフトフォン）と置換可能で、導入もシンプルかつスピーディー。企業の従業員体験（EX）と顧客体験（CX）を同時に高めることをサポートし、コンタクトセンターの業務効率 UP を短期で実現可能にします。 ソリューションの構成 HARMONEY ではサーバレスサービスを採用し、操作性の高いUI/UXを実現しつつ、数十万件を超える大量データでも高速な検索・表示を実現しています。 アーキテクチャ全体   CRM連携機能部分 技術的な工夫 単なる文字起こしだけでなく、文字起こしされた内容を編集したり、会話内容の校正をすることも可能です。これ以外にも、通話内容の記録から議事録の生成も可能で、コールセンター業務における一連の作業を効率的に行えるようになっています。   各機能で使われる生成 AI は、モデルを変更したりプロンプトカスタマイズすることも可能。 会話内容をAIが解析し、必要な項目を自動で抽出・入力することで、ミスを防止し、業務負担を大幅に軽減。オペレータは顧客との対応に集中できます。この機能は、より複雑な処理が可能なモデルを必要としていましたが、Amazon Bedrock は用途に応じてモデルを使い分けることが可能なので、迅速に対応できるようになっています。 実際の導入効果 業務効率の向上 生成 AI による会話リアルタイム文字起こしと会話議事録生成機能により、エージェントのアフターコールワーク（ACW）時間が 75% 削減され、従来 20 分かかっていた作業が 5 分で完了できるようになりました。この時間短縮により、電話対応件数が 100% 増加し、従来 20 人で対応していた業務量を 10 人で処理できるようになったことで、人的リソースの最適化を実現しました。 プレディクティブコール機能では、従来のスマートフォンでの手動入力による架電作業から、1 日 1 万件のアウトバウンドコール発信が可能な自動化システムへと進化。さらに、HARMONY は 1 回線（1 つの電話番号）の契約のみで固定オプション料金で利用できるため、従来の回線使用料を含むシステムと比較してランニングコストを 85% 削減することに成功しました。 サービス品質の向上 オペレーターは通話中に議事録やメモを取る必要がなくなり、顧客との会話に集中できるようになったことで、顧客サービスの質が向上しました。また、生成 AI を活用することで、オペレーターごとにばらつきがあった通話記録の品質問題も解決。一貫して高品質な記録が自動的に生成されるようになりました。 導入による デジタルトランスフォーメーション 促進 導入企業の中には、蓄積された基幹システムのデータを AWS に移行して、HARMONY と連携させたいという要望が出てきています。これは当初想定していなかった効果であり、コールセンター業務を超えたデータ活用の可能性が広がっています。顧客企業が AWS エコシステムへの移行を検討するきっかけとなり、より包括的なデジタルトランスフォーメーションへの道筋を示すことにもつながっています。 今後の展開 ロジカル・アーツ様では、本システムのさらなる進化と認知度向上を目指しています。 機能ごとのマルチエージェント機能の実装 より高度なAI エージェント活用による機能拡充 コールセンター/CRM デモ＆コンファレンス 2025 in 東京 への出展 まとめ 本事例は、Amazon Connect と Amazon Bedrock を組み合わせることで、コールセンター業務の効率化と品質向上を実現しています。特に、生成 AI の活用により、オペレーターの業務負荷軽減とサービス品質の均一化という課題を解決することができました。 生成 AI を活用した新製品開発、業務の効率化、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 ソリューションアーキテクト 大松

エグゼクティブやそのチームに実用的で客観的なインサイトを提供する Gartner は、 2025 Gartner Magic Quadrant for Contact Center as a Service (CCaaS) を発表しました。AWS は、AI を活用したクラウドネイティブなカスタマーエクスペリエンスソリューションである Amazon Connect によって、リーダーに選出されました。 Amazon Connect は、Amazon.com 自身のカスタマーサービス業務を支えるテクノロジーをベースに構築されており、すべての顧客接点において AI ドリブンの機能を提供します。Amazon Connect は発表以来、クラウドファーストかつ AI ネイティブに設計されており、組織にエンタープライズグレードの俊敏性と拡張性を提供します。 3 年連続でリーダーとして認定されたことは、私たちの継続的なイノベーションを反映していると考えています。カスタマージャーニー全体で AI を活用することにより、企業は Amazon Connect によりサービス提供を向上させながら、柔軟な従量課金制の価格モデルで運用コストを最適化できます。Amazon Connect で、組織は最先端の AI を活用しカスタマーエクスペリエンス戦略への迅速な適応、差別化されたブランド価値と顧客ロイヤルティの推進が可能です。私たちはこのリーダーへの選出は、Amazon Connect が、企業の顧客エンゲージメント方法を革新し、効率的でパーソナライズされたインテリジェントなカスタマーサービスの新しい基準を設定する、という信念を裏付ける内容と考えています。 Gartner によると、AWS は実行能力とビジョンの完全性により CCaaS のリーダーと判断されました。 前回の Magic Quadrant の発表以降、Amazon Connect は AI の消費量ではなくチャネル使用量に連動した価格設定の提供で、すべてのチャネルにわたってファーストパーティ AI を提供し、AI 導入の障壁を排除することに全力で取り組んできました 。Virgin Media O2 などのお客様は、苦情解決の迅速化、NPS スコアの向上、処理時間の短縮など、大きな成果を上げています。また富士通では イントラデイ予測での 96% を超える精度や、品質保証における 15% の効率向上を報告しています。 Gartner のレポートは、お客様のビジネスに適したクラウドコンタクトセンターソリューションを評価する際の有益なガイダンスを提供しています。 このリンクより、 2025 Gartner Magic Quadrant for CCaaS のレポート に無料でアクセスいただけます。 Amazon Connect についてさらに詳しく知るには、 Amazon Connect のページ をご覧ください。 Amazon Connect で顧客サービス体験を変革する準備はできましたか？ お問い合わせ ください。 この図は、Gartner, Inc. が発行したより大きな調査文書の一部であり、文書全体の文脈で評価されるべきものです。 Gartner の文書は、 AWS にリクエストすることで入手可能です。 GARTNER および Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。すべての権利は留保されています。All rights reserved. Gartner は、その調査出版物に記載されているいかなるベンダー、製品またはサービスも推奨するものではなく、また、テクノロジーユーザーに対して、最高の格付けまたはその他の指定を受けたベンダーのみを選択するよう助言するものでもありません。Gartner の調査出版物は、 Gartner の調査組織の見解で構成されており、事実の記述として解釈されるべきものではありません。ガートナーは、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は、2025 年 10 ⽉ 21 ⽇に公開された Expand your dashboard design with font customization for axes and data labels in Amazon Quick Sight を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 Amazon Quick Sight は、 Amazon Quick Suite の機能の 1 つで、散在する企業データを実用的なインサイトに変換し、組織が大規模にデータドリブンな意思決定を迅速に行えるよう支援します。この記事では、Quick Sight のビジュアルにおける軸とデータラベルの新しいフォントカスタマイズ機能について、より読みやすくブランドに一貫性のあるダッシュボードを作成するための手順とベストプラクティスを含めて説明します。 フォントのカスタマイズが重要な理由 タイポグラフィは、効果的なデータ可視化において重要な役割を果たします。明瞭で適切に選択されたフォントは、オーディエンスがデータをより速く読み理解するのを助け、ダッシュボードを読みやすくし、組織のアイデンティティを強化します。 具体的には、フォントのカスタマイズは以下の点で役立ちます。 視覚障害のあるユーザーや小さな画面でダッシュボードを閲覧するユーザーを含む、すべてのユーザーにとっての可読性を向上させます 視覚的な階層を確立し、重要な情報 (例: 軸のタイトルと軸のラベル) に注意を向けさせます ブランディングを強化し、ダッシュボードがプロフェッショナルなデザイン基準に沿っていることを保証します 詳細については、 Elevate your dashboards with font customization in Amazon QuickSight を参照してください。 ソリューション概要 最新の Quick Sight アップデートでは、サポートされているチャートタイプ全体で、データラベルと X 軸および Y 軸の両方に対する包括的なテキストスタイリングオプションが導入されました (サポートされているチャートタイプの完全なリストについては、 Axes and grid lines on visual types in Quick Suite および Data labels on visual types in Quick Suite を参照してください)。新機能には以下が含まれます: フォントサイズのピクセルレベルでの制御 フォントファミリーの選択 テキストスタイリング: 太字、斜体、下線 カスタムテキストカラー これらの新機能は、軸とラベルのカスタマイズを拡張し、既存の凡例とタイトルのオプションを補完することで、ダッシュボードのビジュアルデザインをより細かく制御できるようにします。 この投稿では、Quick Sight チャートの軸とデータラベルに対する新しいフォントカスタマイズ機能について説明します。これらの機能強化により、ダッシュボードの外観を細かく調整して、組織のブランディングに合わせたり、エンドユーザーの可読性を向上させたりできます。具体的には、以下の内容を実演します。 チャートの軸とデータラベルのフォントプロパティを設定する ダッシュボード全体で一貫したタイポグラフィを適用する 可読性のベストプラクティスを実装する 前提条件 始める前に、以下のものが揃っていることを確認してください。 アクティブな Quick Sight Standard または Enterprise Edition のサブスクリプション Quick Sight への Author または Admin アクセス権限 ダッシュボードに少なくとも 1 つのビジュアル (チャートまたはグラフ) が作成されていること チャートの軸とデータラベルのカスタマイズ 著者として、チャートの軸やデータラベルのフォントをカスタマイズするには、わずか数ステップで開始できます。チャート軸のフォント設定を変更するには、次の手順を実行してください。 分析を編集モードで開きます。 更新したいチャートビジュアルを選択します (この例では、縦積み上げ棒グラフを選択します)。 メニューバーの鉛筆アイコンを選択します。 書式設定ペインで、 X 軸 または Y 軸 を展開します。 以下のプロパティを調整します: フォントファミリー テキストサイズ スタイル (太字、斜体、または下線。ただし、下線は軸タイトルではサポートされていますが、軸ラベルではサポートされていないことに注意してください) 色 チャートの種類によって、使用される用語が異なります。 棒グラフと折れ線グラフ : X 軸と Y 軸 円グラフ : 値 ヒートマップ : 行と列 データラベルのフォント設定を変更するには、次の手順を実行してください。 Format visual ペインで、 Data labels を展開します。 Show data labels をオンにします。 以下のプロパティを調整します。 Font family Text size Style (bold または italic) Color ダッシュボードのタイポグラフィのベストプラクティス フォントのカスタマイズを実装する際は、次のガイドラインに従ってください。 一貫性を保つ – ダッシュボード全体で同じフォントまたは補完的なフォントを使用し、統一感を持たせます 可読性を優先する – さまざまなデバイスや画面サイズでテストします。デスクトップで見栄えが良くても、モバイルでは窮屈に見える場合があります 階層構造を使用する – 重要な要素 (軸のタイトル、データラベル) を強調しますが、圧倒しないようにします。軸とデータラベルはメインストーリーをサポートするものであり、競合するものではありません 優れた可読性を確保する – 適切なコントラスト設定、十分なフォントサイズを使用し、明瞭性を損なう過度に装飾的なフォントは避けます コンテキストを確認する – 背景色、チャートの密度、テキストの重なりはすべて判読性に影響します。向きとスタイルを調整して、乱雑さを軽減します まとめ これらの新しいフォントカスタマイズ機能により、Quick Sight で洗練された、ユーザーフレンドリーで、ブランドに一貫性のあるダッシュボードを構築できます。データラベルや軸のフォントを設定することで、可読性を向上させ、ブランディング基準に合わせ、ユーザーに適したダッシュボードを作成できます。 これらの機能を今日から活用して、分析の視覚的な魅力と機能性を向上させましょう。開始するには、次のステップを検討してください。 Amazon Quick Suite ユーザーガイド を確認してください Quick Sight の高度な可視化オプション を探索してください より多くのヒントとベストプラクティスについては、 AWS Analytics コミュニティ に参加してください 著者について Priya Kakarla は、Amazon Quick Suite のスペシャリストソリューションアーキテクトで、ヘルスケア、金融、デジタルネイティブビジネスにわたる経験を持っています。データに基づいた意思決定を推進するエンドツーエンドの分析ソリューションの設計と実装を顧客に支援しています。直感的でスケーラブルな分析を通じて組織を支援することに情熱を持ち、強い顧客志向と、実際のビジネス成果を達成する革新的でパーソナライズされたソリューションの提供へのコミットメントで知られています。仕事以外では、新しい場所を探索したり、さまざまな料理を試したり、家族や友人と充実した時間を過ごすことを楽しんでいます。 Vasha Bhatari は Amazon Quick Sight のシニアプロダクトマネージャーで、BI の移行を簡素化し、お客様が容易に分析をモダナイズできるソリューションを推進しています。2017 年に Amazon に入社して以来、ラストマイルのルート最適化、データベース移行、ビジネスインテリジェンスにわたる取り組みをリードし、複雑なデータの課題に幅広い経験をもたらしています。仕事以外では、次の旅行を計画したり、新しい食べ物を試したり、太平洋岸北西部の最高のハイキングやカヤックスポットを探索したりしています。 Nicholas Soto は、Amazon Quick Sight のソフトウェア開発エンジニアです。高速で使いやすいフロントエンドシステムの構築に情熱を注いでいます。仕事以外では、ロッククライミングや読書を楽しんでいます。

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 などのサーバレスのサービスが好きです。