このブログ記事は、AWS ソリューションアーキテクト 太田が執筆し、ソニー銀行様が監修しています。 ソニー銀行株式会社（以下、ソニー銀行）は 2025 年 5 月、同行の勘定系システム全体のアマゾンウェブサービス（以下、AWS）への移行を完了しました(プレスリリースは こちら )。 この新勘定系システムは、主要コンポーネントとしてコンテナ向けサーバーレスコンピューティングサービス AWS Fargate を活用したクラウドネイティブなアーキテクチャで設計されており、マイクロサービス化することで機能拡張にも柔軟に対応可能なシステム基盤上に構築されています。さらに、 API （アプリケーション プログラミング インターフェイス）を通じて他のシステムとも容易に接続が可能であるため、アプリケーションの拡張性と柔軟性にも優れています。アプリケーション開発に関しても、ライフサイクル全体の効率的な管理を行う AWS Code サービス群を利用した継続的インテグレーション / 継続的デプロイメント（CI/CD）パイプラインを構築することで開発工程を自動化し、より短い時間での機能拡張や新サービスのリリースを可能にしています。 本ブログでは、ソニー銀行のこれまでのクラウドジャーニーと、今回 AWS で稼働を開始した新勘定系システムの全容を紹介します。 新勘定系システム移行までの道のり ソニー銀行は最新のテクノロジーを活用した IT 戦略を進めるため、日本の金融機関の中でもいち早く 2011 年からクラウド導入の検討を開始しました。情報収集・調査を続ける中 AWS が、 FISC（公益財団法人金融情報システムセンター）の安全対策基準への適合性 などセキュリティ情報を積極的に公開 ・開示していること、豊富かつ高度な機能を揃えていること、 責任共有モデル で責任範囲が明確化されていることなどを評価して AWS の採用を決定しました。ソニー銀行は、2013 年末から一般社内業務システムと銀行業務周辺系システムを段階的に移行し、2019 年末には全システムの約 80% が AWS 上で稼働するようになりました。AWS の導入により最大 60% のインフラコスト削減を実現し、インフラ調達・構築期間も半分以下に短縮されました。さらに、可用性の高さも AWS 利用の大きな利点で、 マルチ AZ（アべイラビリティゾーン）、マルチリージョン の構成により高可用性を実現できるようになりました。 ソニー銀行は AWS 利用開始当初から、銀行の重要業務も含めた AWS 利用範囲の段階的な拡大を想定し、AWS アジアパシフィック（東京）リージョン（以下、東京リージョン）に続く国内第二のリージョンの開設を AWS に対して強く要望してきました。ソニー銀行を含むこうした顧客からの強い要望もあったため、2018 年には国内第二の AWS リージョンとなる大阪ローカルリージョンが開設、さらに 2021 年にはフルリージョン化され AWS アジアパシフィック（大阪）リージョン（以下、大阪リージョン）の開設に至りました。これにより銀行重要業務を AWS で稼働させることができるだけの可用性・耐障害性の実現が可能であると判断したソニー銀行は、勘定系システムの AWS 移行を開始しました。 新勘定系システムの概要 クラウドネイティブなシステム 新勘定系システムを設計するにあたってソニー銀行が最も重要視したのは、拡張性と柔軟性の高いシステムであることでした。これを実現するためにソニー銀行は、AWS のマネージドサービスである Amazon ECS / AWS Fargate、 Amazon Aurora を中核としたクラウドネイティブなインフラアーキテクチャを採用しました。新勘定系システムの主要機能は全てコンテナのサービスとして実装され、相互に API を通じて連携する疎結合なシステムとなっています。そのため機能拡張や新サービス追加を、システム全体を止めずに実施できるようになり、これまでよりはるかに短時間で高頻度に行えるようになります。またインフラストラクチャ自体も AWS CloudFormation を活用して IaC (Infrastructure as Code) 化することで、インフラストラクチャのデプロイや変更作業も自動化され、環境管理の効率性を高めています。 ソニー銀行 執行役員 福嶋 達也氏はこう語ります。「ソニー銀行では、ビジネスアジリティの向上を目指し、クラウドシフト戦略を推進してきました。周辺系システムから段階的にクラウド移行を進め、今回の新勘定系システム移行完了に伴い、クラウドに移行できるシステムはほぼ全て移行し終え、銀行業務における全方位でのクラウド化を実現しました。新勘定系システムは単純なクラウドへのリフトではなく、クラウドネイティブアーキテクチャを採用しており、新商品開発などの攻めの IT へより多くの戦略的投資が可能となります。」 アプリケーション開発環境でも AWS のマネージドサービスを活用し、開発環境自体の構築、運用、管理にかける工数を大きく減らしています。 AWS CodeBuild 、 AWS CodeDeploy 、 AWS CodePipeline を活用してアプリケーションのビルド、テスト、デプロイまでを自動化する CI/CD パイプラインを構築したことで、オンプレミスでのアプリケーション開発と比べて、アプリケーションの開発期間やリリース頻度が大幅に改善されました。アプリケーションのリリース後は、 Amazon RDS Performance Insights や Amazon CloudWatch Container Insights 、 AWS X-Ray による性能情報の計測や分析、および各種ログを集約管理した Amazon OpenSearch Service による稼働状況の監視や問題点の可視化、分析を可能にしています。 マルチリージョン構成での災害対策 銀行の勘定系というミッションクリティカルなシステムをクラウド化するにあたって、広域災害を想定した災害対策は必須要件です。日本国内での災害対策実現というソニー銀行の強い要望が後押しする形で、2021 年当時の大阪ローカルリージョンがフルリージョン化され、大阪リージョンが開設されました。ソニー銀行の新勘定系システムは、東京リージョンと大阪リージョンの 2 つのリージョンを利用した災害対策構成を取っており、本番環境では東京リージョンをメインサイトとし、これと同等の環境を災害対策サイトとして大阪リージョンにも構えています。 新勘定系システムでは、サーバー/コンテナ、データベース、アプリケーション、サービスなど様々なレイヤーに対して統合的な監視を実施しており、システム障害発生時には関係者に即時に通知される仕組みになっています。ノード障害や単一の AZ 障害では、サービス切り替えが発生し、即時に自動復旧できる設計となっています。一方で、複数の AZ、もしくは東京リージョン全体が被災するようなケースにおいては、システム全体を大阪リージョンへ切り替えて業務を継続します。特に早期復旧が必要となる対顧客向けのオンライン処理では、データベースの切り替えから接続先の変更までを短時間で実行し復旧する仕組みとなっています。 新勘定系システムでは勘定系データ、情報系データを Amazon Aurora PostgreSQL-compatible Edition に格納しており、正常稼働時は Amazon Aurora Global Database の機能によって東京リージョンから大阪リージョンへ常時データをレプリケーションしています。これにより、メインリージョンである東京リージョンの被災時においても、通常 1 秒未満の 目標復旧時点（RPO：Recovery Point Objective）を実現可能にしています。 図 1: 新勘定系システムの災害対策構成概要図 出所 : AWS AWS のベストプラクティスに則った運用とセキュリティ 新勘定系システムでは、AWS 上のシステム環境の可視化や運用作業の自動化などの機能を提供する AWS Systems Manager 、アプリケーションレイヤー (レイヤー 7) 保護のための WAF 機能を提供する AWS WAF 、DDoS 攻撃などの外部脅威からアプリケーションを保護する AWS Shield Advanced 、AWS リソースの設定変更を管理できる AWS Config 、AWS ワークロードおよびソフトウェアの脆弱性を検知する Amazon Inspector 、AWS アカウントとワークロードを継続的にモニタリングし脅威を検出する Amazon GuardDuty 、各 AWS セキュリティサービスの結果を確認、分析できる統合ダッシュボードを提供する AWS Security Hub 、SIEM (Security Information and Event Management) 基盤としての Amazon OpenSearch Service などの AWS サービスを標準で採用しており、AWS の運用とセキュリティ強化を効率よく実施しています。 新勘定系システムの設計にあたっては、AWS でのシステム運用とセキュリティに関するベストプラクティスを、 AWS Well-Architected Framework や AWS プロフェッショナルサービス を活用することで最大限に取り入れています。まず最初に、ソニー銀行および AWS アカウントチームによる Well-Architected レビューを実施し、運用面、セキュリティ、信頼性、パフォーマンス、コスト、サステナビリティの 6 つの観点からシステム設計を評価しました。その結果、さらに深掘りが必要な項目について AWS プロフェッショナルサービスが実機設定および設計書などのドキュメントのレビューを行い、現状の運用およびセキュリティ強化と、今後の継続的な改善の仕組み作りを実施しました。 またソニー銀行は日本の銀行として初めて、 AWS Countdown Premium ティア を採用しました。本番移行の 3 ヶ月前から移行後 1 ヶ月の計 4 ヶ月間本サービスを活用し、新勘定系システムの移行に向けたシステム準備状況の評価と、移行当日の支援体制、さらに移行後の運用体制の強化を実現し、万全の準備を整えて本番移行に臨みました。 外部との連携 新勘定系システムでは Amazon API Gateway を活用して Open API を実装しています。Open API により安全に銀行データを外部から参照でき、例えばフィンテック企業などと連携してより高度な銀行サービスを提供することも可能になります。この Open API の認証、認可の機能を実装するにあたり、ソニー銀行は Authlete を採用しました。Authlete は高いセキュリティ基準に準拠する認証、認可の機能を提供するオープンソースソフトウェアであり、金融業界において高い注目を集めています。Authlete を採用したことでソニー銀行は、認証、認可の仕組みの構築を効率化でき、高いセキュリティレベルを担保しながら開発コスト・期間を大幅に削減することができました。また Authlete は OAuth 2.0 や OpenID Connect などの認証・認可の標準規格に準拠しており、外部のシステムやサービスとの連携もスムーズに行えるため、Open API を通じた相互運用性を高めています。 また新勘定系システムは、SaaS サービスと AWS PrivateLink でセキュアに連携しています。新勘定系システムが AWS 上に構築されているからこそ、同じく AWS 上で稼働する各 SaaS サービスと AWS PrivateLink を通じたプライベート接続を確立することができ、セキュアなプライベート通信を可能にしています。今後も増えていく連携先システムが AWS 上にある場合には、積極的に PrivateLink 経由での連携を採用していく方針です。 今後の展開 新勘定系システムではクラウドネイティブで疎結合なアーキテクチャを採用したことにより、フィンテック企業など外部との連携や、Web3・生成 AI などの新技術の導入をこれまでより柔軟かつ容易に行えるようになりました。今後ソニー銀行は、金融業界を取り巻く環境の変化や、多様化するお客様のニーズに寄り添い、ソニー銀行ならではの先進的でユニークな商品・サービスをスピード感をもって提供していきます。 まとめ 本ブログでは、新たに AWS で稼働を開始したソニー銀行の勘定系システムの全体像をご紹介しました。銀行の勘定系システムというミッションクリティカルなワークロードを如何にして AWS 上で実装するか、それにより得られた様々なプラスの効果についてより多くの方々に知っていただけると幸いです。

リレーショナルデータベース管理システム（RDBMS）における、consistency（一貫性 / 整合性）はトランザクションの重要な特性の1つです。一貫性は、トランザクションが終了した後にデータが常に正しい状態に保たれるためのルールを定義します。データの一貫性により、トランザクションはテーブルに対して事前に定義された予測可能な方法でのみ変更を加えることができ、これによりデータの整合性に対する意図しない影響を防ぐことができます。 データベース移行の際にシステム停止時間を最小限に抑えるためには、まずはじめに移行元のデータベースから整合性のとれたスナップショットを取得する必要があります。その後、移行元のデータベースとの整合性を保ちながらレプリケーションを確立するために、整合性のとれたスナップショットを取得した時点のトランザクション位置を記録する必要があります。基本的な考え方として、スナップショット取得時点からレプリケーション開始までの間にトランザクションの欠落や抜けがある場合、移行先のデータベースの整合性は保証されません。 AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他の種類のデータストアの移行を支援します。 初期データロード、または AWS DMS のフルロードフェーズ、および変更データキャプチャ (CDC) が一貫した状態から開始されるトランザクション位置を管理するために、AWS DMS は TransactionConsistencyTimeout というタスク設定を実装して、AWS DMS タスクの開始時にオープントランザクションを処理するようにしました。 この記事では、さまざまなエンジンのフルロード + CDC タスクの開始時に AWS DMS がオープントランザクションを処理する方法について説明し、consistency timeout（整合性タイムアウト）の問題を回避するためのベストプラクティスを紹介します。 トランザクション整合性タイムアウトに関するよくある質問 移行元のデータベースの種類によって、 TransactionConsistencyTimeout に関して以下のような質問がよく寄せられます。 Oracle ソース – タスクを開始した時 Before load の状態で10分間も停止しているのはなぜですか。タスクログに表示される「open transaction」とは何を意味しますか。オープントランザクションのタイムアウトが発生するとどうなりますか。 SQL Server ソース – タスクを開始した時に、 Before load の状態で停止しているのはなぜですか。 PostgreSQL ソース – statement_timeout を設定していないのに、タスクの開始時にステートメントのタイムアウトが発生してタスクが失敗したのはなぜですか。 MySQL ソース – 長時間トランザクションが存在する場合、フルロードや CDC タスクの開始に支障が出るのでしょうか。 これらの疑問に答えるため、まず AWS DMS でのオープントランザクションとは何かを説明します。 AWS DMS におけるオープントランザクション AWS DMS におけるオープントランザクションとは、フルロード + CDC タスクの開始時点で、移行元のリレーショナルデータベースでコミットもロールバックもされていないトランザクションを指します。 前述した移行アプローチ同様、AWS DMS はフルロードを開始する際と、CDC のためのトランザクション位置を特定する際に、整合性のとれた状態を必要とします。 RDBMS エンジンごとにトランザクションログの実装方法が異なるため、AWS DMS も移行元の RDBMS によって異なる動作をします。以降のセクションでは、Oracle、SQL Server、PostgreSQL、MySQL を移行元とした場合に、AWS DMS がオープントランザクションをどのように処理するかについて説明します。 Oracle ソースからの移行時における AWS DMS のオープントランザクション処理について フルロード + CDC タスクの場合、タスク設定 TransactionConsistencyTimeout は、AWS DMS がフルロードオペレーションを開始する前にトランザクションが終了するのを待つ秒数を定義します。デフォルト値は 600 秒（10 分）です。タスクの開始時にトランザクションが開いている場合、AWS DMS はデフォルトで 10 分間待機します。 TransactionConsistencyTimeout 値に達すると、実行中のトランザクションがあってもフルロードが開始され、 TransactionConsistencyTimeout よりも長いトランザクションが将来のレプリケーションで失われます。 次の図では、フルロードタスク + CDC タスクが開始されると、合計 6 つのトランザクションのうち、AWS DMS ソースキャプチャプロセスによって特定されるオープントランザクションが 2 つあります。 トランザクション 1 – ソースキャプチャが開始された時点ではオープントランザクションですが、 TransactionConsistencyTimeout の時間枠内かつフルロードが開始される前にコミットされます。したがって、フルロードフェーズに含まれます。 トランザクション 2 – TransactionConsistencyTimeout の時間枠内およびフルロードが開始される前に開始およびコミットされます。したがって、フルロードフェーズに含まれます。 トランザクション 3 と 4 – フルロードフェーズ中にコミットされるため、キャッシュされた変更として、フルロードが終了した後に適用されます。 トランザクション 5 – フルロードフェーズで開始し、フルロードが完了した後にコミットされるため、CDC として、キャッシュされた変更が適用された後に適用されます。 トランザクション 6 – FailOnTransactionConsistencyBreached はデフォルトで false に設定されているため、タスクは続行されます。オープントランザクション B はスキップされ、 TransactionConsistencyTimeout 後にコミットされたため、データが失われます。 TransactionConsistencyTimeout と FailOnTransactionConsistencyBreached の設定に関するベストプラクティスについては、後のセクションで説明します。 次のログは、オープントランザクションがある場合の一般的な AWS DMS ログの例を示しています。 SOURCE_CAPTURE コンポーネントはオープンされているトランザクションの数を識別し、 SORTER は TransactionConsistencyTimeout の後にトランザクション整合性タイムアウトに関する警告を出力します。 xxxx-xx-xxT00:00:00 [SOURCE_CAPTURE ]I: Opened transaction list contains '6' transactions, these in-flight transaction(s) will not be copied (oracle_endpoint_capture.c:967) … xxxx-xx-xxT00:00:00 [SORTER ]I: 6 open transactions. Waiting for transaction consistency (sorter_transaction.c:322) … xxxx-xx-xxT00:10:00 [SORTER ]W: Transaction consistency timeout occurred. 6 transactions are still open (sorter_transaction.c:3575) SQL Server ソースからの移行時における AWS DMS のオープントランザクション処理について SQL Server を移行元として使用する場合も同様に、フルロード + CDC タスクの開始時にオープントランザクションが存在すると、AWS DMS の SOURCE_CAPTURE は以下のようなログを出力して検知します。 [SOURCE_CAPTURE ]I: do_get_best_lowset_position_for_highest_lsn_lookup(...) There is an outstanding active transaction!! It's oldest LSN is - '00000140:000217da:0001' It may be used as a '2nd chance' SELECT MAX() candidate. (sqlserver_log_queries.c:750) SQL Server のデフォルトの分離レベルである READ COMMITTED で、 READ_COMMITTED_SNAPSHOT が OFF の場合、他のトランザクションによって変更されたがまだコミットされていないデータの読み取りは許可されません。 そのため、フルロード + CDC タスクで移行中のテーブルにオープントランザクションが存在する場合、そのテーブルに対する select * は、タスクの対象範囲内のアクティブなトランザクションがコミットまたはロールバックされるまでブロックされます。タスクの対象範囲外のテーブルにオープントランザクションが存在する場合、AWS DMS は一定時間待機した後にタスクを開始します。この場合、AWS DMS はフルロード + CDC タスクの開始のためにコミットやロールバックを待つことはなく、タスクの実行にも影響はありません。 この動作の結果、データの損失は発生しません。ただし、タスク対象範囲内のテーブルに関連するオープントランザクションがコミットまたはロールバックされるまで、フルロード + CDCタスクは Before load 状態のままとなります。 PostgreSQL ソースからの移行時における AWS DMS のオープントランザクション処理について PostgreSQL を移行元とする場合、AWS DMS は PostgreSQL プラグイン pglogical または test_decoding を使用して SOURCE_CAPTURE コンポーネントを介して Write-Ahead Log (WAL) を読み取ります。 ただし、アクティブなトランザクションが存在する場合、レプリケーションスロットの作成処理 select * from pg_create_logical_replication_slot('slot_test','test_decoding'); は停止してしまいます。その結果、AWS DMS は変更を取得するためのレプリケーションスロットを作成できなくなり、ステートメントがタイムアウトするまで TransactionConsistencyTimeout の時間だけ待機します。 オープントランザクションが TransactionConsistencyTimeout の制限時間内にコミットまたはロールバックされれば、フルロード + CDC タスクは正常に開始され、データの損失も発生しません。しかし、オープントランザクションの実行時間が TransactionConsistencyTimeout を超えた場合、CDC の前提条件チェックが失敗し、以下のようなログが出力されます。 [SOURCE_CAPTURE ]E: RetCode: SQL_ERROR SqlState: 42P01 NativeError: 1 Message: ERROR: relation "pglogical.replication_set" does not exist; No query has been executed with that handle [1022502] (ar_odbc_stmt.c:3752) [SOURCE_CAPTURE ]E: RetCode: SQL_ERROR SqlState: 57014 NativeError: 1 Message: ERROR: canceling statement due to statement timeout; Error while executing the query [1022502] (ar_odbc_stmt.c:2581) [SOURCE_CAPTURE ]E: Could not find any supported plugins available on source (postgres_plugin.c:269) MySQL ソースからの移行時における AWS DMS のオープントランザクション処理について MySQL を移行元とする場合、AWS DMS は変更の取得に binlog を使用します。MySQL の binlog にはコミットされていないトランザクションは含まれません。そのため、フルロード + CDC タスクの開始時に、AWS DMS はコミットされたトランザクションのみを参照できます。オープントランザクションは、コミットされるタイミング（フルロード中かフルロード後か）に応じて、キャッシュされた変更または CDC 変更として扱われます。このため、MySQL を移行元として使用する場合、フルロード + CDC タスクにおいてトランザクションの整合性タイムアウトの問題は発生しません。 ベストプラクティス オープントランザクションを扱うためのベストプラクティスは以下の通りです。 データ移行の評価作業として、移行元データベースの長時間実行トランザクションを事前に十分確認し、アプリケーションやサービスの管理者と協力して、少なくとも移行フェーズの間はデータベース内の長時間トランザクションを最小限に抑えるためのプロセスを確立してください。 Oracleを移行元とする場合、トランザクションの整合性タイムアウトエラーが発生するとデータが失われる可能性があります。そのため、 FailOnTransactionConsistencyBreached を true に設定し、早期にタスクを停止させる方がよいでしょう。 フルロード + CDC タスクは、移行元データベースの負荷が低い時間帯に開始してください。また、フルロード + CDCタスクを開始する前に、移行元データベースで予定されているダンプ処理や 抽出・変換・読み込み（ETL）ジョブの完了を待つことを推奨します。これにより、トランザクションの整合性タイムアウト問題の発生可能性を抑制し、また、処理すべき変更データ量を減らすことで、より早く移行元データベースに追いつくことができます フルロード + CDC タスクを開始後、Before load 状態が長時間続く場合は、移行元データベースでオープントランザクションが存在していないか確認することを推奨します。 Oracle の場合は、 v$transaction ( 例 )を確認してください。Oracle スタンバイ（Active Data Guard または Amazon RDS リードレプリカ）データベースをソースとして使用する場合、ソースデータベースのプライマリデータベースでオープントランザクションの詳細を確認してください。 PostgreSQL の場合は、 pg_stat_activity （ 例 ）と pg_prepared_xacts （ 例 ）を確認してください。 SQL Server の場合は、 DBCC OPENTRAN または dm_tran_active_transactions を確認してください。 TransactionConsistencyTimeout はデフォルトで 10 分です。ソースデータベースに常に 10 分を超えるトランザクションがある場合は、 TransactionConsistencyTimeout の値を増やしてください。 TransactionConsistencyTimeout を増やすと、AWS DMS の待機時間が長くなるため、 TransactionConsistencyTimeout に達する前に、開いているトランザクションがコミットまたはロールバックされる可能性があります。 TransactionConsistencyTimeout を増やしても、この記事で説明されている整合性タイムアウト関連のエラーが原因で、ソースデータベースで長時間実行されているトランザクションや、タスク障害を回避するための解決策にはならないことに注意してください。AWS DMS がソースデータベースでトランザクションのコミットまたはロールバックを待っている間、タスクは進行しません。したがって、上記のベストプラクティスを適用することは依然として重要です。 データの欠落や整合性の問題を特定するために、 AWS DMS データ検証 を使用してください。 まとめ データベース移行プロジェクトにおいて、データの損失は決して許容できません。この記事では、オープントランザクションとは何か、そして異なるデータベースエンジンでフルロード + CDC タスクを開始する際に、AWS DMS がどのようにオープントランザクションを処理するのかについて説明しました。また、オープントランザクションに関連する問題を回避するため、AWS DMS タスクの計画から実行に至るまでのベストプラクティスを紹介しました。 著者について Wanchen Zhao は AWS のパートナーソリューションアーキテクトです。 Rishi Raj Srivastava は、アマゾンウェブサービスの AWS DMS チームに所属するデータベースエンジニアです。 Sudip Acharya は、インドのAWS ProServe チームのコンサルタントとして、社内外の Amazon カスタマーのデータベース最新化プロジェクトに関するガイダンスや技術支援を行い、お客様が AWS を使用する際のソリューションの価値向上を支援しています。特に、データベースや移行関連ツールの設計・実装を得意分野としています。 翻訳はクラウドサポートエンジニアの小池が担当しました。原文は こちら です。

本記事は 2025 年 4 月 29 日に公開された Introducing Just-in-time node access using AWS Systems Manager を翻訳したものです。 2025 年 4 月 29 日に AWS Systems Manager の新機能である ジャストインタイムノードアクセス の一般提供を開始しました。ジャストインタイムノードアクセスは、AWS Systems Manager で管理されている Amazon Elastic Compute Cloud (Amazon EC2) 、オンプレミス、およびマルチクラウドノードへの動的かつ時間制限付きのアクセスを可能にします。ポリシーベースの承認プロセスを導入することで、長期的なアクセス権を適切に管理しつつ、運用効率とセキュリティの両方を向上させることができます。 何千ものノードに運用を拡大する組織では、監査とコンプライアンスの目標をサポートするために、ID ベースの詳細な権限が必要で、長期的な認証情報を完全に排除したいと考えています。ノードアクセスに長期的な認証情報を使用する慣行は、セキュリティの脆弱性を生み出し、不正アクセスや潜在的な侵害のリスクを高めます。 これまで、お客様はセキュリティと運用効率の間で難しいトレードオフに直面していました。特定のリソースに誰がアクセスする必要があるかを慎重に決定するのではなく、IT チームは大規模なユーザーグループに過剰な権限を付与していました。この慣行は、運用上の利便性の必要性によるものですが、オペレーターの誤操作のリスクを高め、悪意のある行為者に機会を与えていました。長期的な認証情報を維持してセキュリティが侵害されるリスクを高めるか、インシデント対応を遅らせる制限的なアクセス制御を実装するかのどちらかでした。さらに、独自に構築したソリューションは保守や拡張が複雑になりがちでした。一方、エージェントを使用する AWS 以外のツールでは、ノードへのアクセスに別途 ID と権限が必要となっていました。 概要 ジャストインタイムノードアクセスは、運用チームが問題に迅速に対応できるようにしながら、最小権限アクセスを実装するのに役立ちます。これは AWS Organizations 全体でシームレスに機能し、単一のアカウントでも複数のアカウントでも一貫したアクセス制御を設定できます。この新機能により、管理者は承認ポリシーを通じて正確なアクセス制御を定義でき、誰がどのノードにどのような条件でアクセスできるかを指定できます。組織は、複数の承認者による手動承認プロセスと条件ベースの自動承認ポリシーのどちらかを選択でき、セキュリティ要件に合わせた柔軟性を提供します。 例えば、管理者はインシデント対応中のオンコールエンジニアに迅速にアクセスを提供するための自動承認ポリシーを確立し、オンコール AWS IAM Identity Center グループのオペレーターにのみアクセスを許可することができます。ジャストインタイムノードアクセスを通じて、オペレーターは必要なときにノードへのアクセスをリクエストできます。事前設定された承認ポリシーに基づいて、定義された時間経過後に自動的に期限切れになる一時的なアクセスを受け取ります。承認されると、インバウンドポートを開いたり SSH キーを管理したりする必要なく、ワンクリックのブラウザベースのシェル、 AWS Command Line Interface (AWS CLI) または Systems Manager でサポートされているリモートデスクトッププロトコル (RDP) を介して、これらのノードに直接アクセスできます。 承認プロセスを簡素化するために、ジャストインタイムノードアクセスは Amazon Q Developer を通じて Slack や Microsoft Teams などのツールと統合し、保留中のリクエストについて承認者に通知するためのメールも送信します。Systems Manager はまた、ジャストインタイムノードセッションアクセスリクエストのステータス更新のために Amazon EventBridge にイベントを発行します。これらのイベントは通知のために Amazon Simple Notification Service (Amazon SNS) にルーティングしたり、内部システムと統合したりすることができ、チームが既存のワークフローを通じてアクセスリクエストを追跡し対応することを可能にします。これにより、組織全体でアクセスリクエストを監視し、監査証跡を維持することができます。さらに、ジャストインタイムノードアクセスは、セッション中に実行されたコマンドをログに記録したり、RDP セッション中の操作を録画することで、オペレーターの作業の見える化を提供します。 Systems Manager は、アカウントごと、リージョンごとにジャストインタイムノードアクセスの無料トライアルを提供しており、この機能を評価することができます。この無料トライアル期間は、機能を有効化した月の残り期間と、その翌月の 1 か月間が含まれます。このトライアル期間中、追加料金なしで設定やアクセスポリシーをテストできるよう、すべての機能にアクセスできます。トライアルが終了すると、ジャストインタイムノードアクセスは有料サービスとなり、使用パターンに基づいて課金されます。詳細な価格情報とコスト内訳については、 AWS Systems Manager の料金 を参照してください。 ジャストインタイムノードアクセスの使用 ジャストインタイムのノードアクセスでは、管理者、オペレーター、承認者という3つの役割があります。管理者は承認ポリシーの設定と管理を、オペレーターは必要なノードへのアクセス要求を、承認者はそれらの要求の確認と承認を担当します。 この機能の設定と使い方について、具体例を用いて説明します。ここでは、オンコールエンジニアが本番環境の「r2d2-app-01」というインスタンスにアクセスする必要がある場合を想定します。図 1 には、アクセス対象となる可能性のあるインスタンス群が示されています。 図 1: Amazon EC2 コンソールに表示される EC2 インスタンスのリスト オンコールエンジニア（オペレーター）が本番システムへのアクセスをリクエストし、DevOps リード（承認者）が管理者が定義した承認ポリシー内でそれを管理する方法を紹介します。 管理者としてのジャストインタイムノードアクセスの設定 ステップ1 – ジャストインタイムノードアクセスの有効化 このウォークスルーでは、AWS Organizations のジャストインタイムノードアクセスを有効にします。まず、 Systems Manager 統合コンソール をセットアップする必要があります。統合コンソールがセットアップされたら、Systems Manager でジャストインタイムノードアクセスを有効にできます。 次に、展開のターゲットとする組織単位（OU）と AWS リージョンを選択できます。これにより、図2に示すように、組織全体または特定の領域でソリューションを実装する場所を正確に制御できます。 図 2: ジャストインタイムノードアクセスの有効化 ステップ2 – 承認ポリシーの作成 機能を有効にした後、次の重要なステップは承認ポリシーの作成です。承認ポリシーは、ユーザーがノードにアクセスする方法を決定します。これらのポリシーには、 自動承認 、 手動承認 、 アクセス拒否ポリシー の3種類があります。自動承認ポリシーは、ユーザーが自動的に接続できるノードを定義します。手動承認ポリシーは、指定したノードにアクセスするために提供する必要がある手動承認の数とレベルを定義します。アクセス拒否ポリシーは、指定したノードへのアクセスリクエストの自動承認を明示的に防止します。 この例では、「 r2d2-app-01 」ノードを含む Workload:Application01 でタグ付けされたノードに対する手動承認ポリシーの作成方法を説明します。 ポリシーを作成するには、 AWS Systems Manager コンソール に移動し、ナビゲーションペインで ジャストインタイムノードアクセス を選択し、 承認ポリシー タブおよび ローカルポリシー を選択して、 手動ポリシーを作成 を選択します。ポリシー設定にはいくつかの重要なコンポーネントが必要です。 まず、 承認ポリシーの詳細 セクションで、図 3 に示すように、承認ポリシーの名前と説明を入力し、最大アクセス期間を設定します。この期間は、承認されたアクセスが自動的に期限切れになるまでの有効期間を決定します。 図 3: 手動承認ポリシーページ ターゲット セクションでは、タグのキーと値のペアを使用して、ポリシーが適用されるノードを定義します。この例では、「 r2d2-app-01 」ノードを含む Workload:Application01 でタグ付けされたノードをターゲットにします。図 4 に示すように、この方法によって Application01 に関連するすべてのノードにポリシーが確実に適用されます。 図 4: 手動承認ポリシーのターゲット アクセスリクエストの承認 セクションでは、アクセスリクエストを承認する権限を持つ個人またはグループを指定します。このシナリオでは、DevOps リードの役割を承認者として割り当てます。アクセスリクエスト承認者は、図 5 に示すように、IAM Identity Center のユーザーとグループ、またはIAM ユーザー、グループ、ロールにすることができます。 図 5: アクセスリクエスト承認 また、 Cedar ポリシー言語 を使用して自動アクセスルールを定義することもでき、信頼されたシナリオでは手動承認の必要性を排除できます。自動承認ポリシーは、組織の事前承認されたアクセスルールブックと考えてください。これらのポリシーは、事前定義された条件と信頼レベルに基づいて、ユーザーが自動的にアクセスできるノードを指定します。詳細については、 ジャストインタイムノードアクセスの自動承認ポリシーの作成 および 自動承認およびアクセス拒否ポリシーのステートメント構造と組み込み演算子 を参照してください。 例えば、以下の Cedar ポリシーを使用して、「DevOpsTeam」グループのメンバーが Environment: Development でタグ付けされたノードに自動的にアクセスできるようにする自動承認ポリシーを作成できます： // Policy to permit access to Development nodes for members of the DevOpsTeam IDC group permit ( principal in AWS::IdentityStore::Group::"911b8590-7041-70fa-d20b-12345EXAMPLE", action == AWS::SSM::Action::"getTokenForInstanceAccess", resource) when { resource.hasTag("Environment") && resource.getTag("Environment") == "Development" }; オペレーターとしてのアクセスリクエスト オペレーターとして保護されたノードにアクセスする必要がある場合、リクエストプロセスが表示されます。Session Manager を通じて接続を試みる際、即座にアクセスが許可されるのではなく、アクセスリクエストの送信を求められます。図 6 に示すように、アクセスが必要な理由の入力が必要となります。 図 6: ノードへのアクセスをリクエストするオペレーター リクエスト送信後は、図 7 に示すように、 アクセスリクエスト タブでその状況を確認できます。承認プロセスの進行状況を追跡でき、アクセスが許可されるタイミングを正確に把握することができます。メール、Slack、Microsoft Teams、または他の統合プラットフォームなど、好みの通信チャネルを通じて通知を受け取ります。詳細については、 ジャストインタイムアクセスリクエストの通知の設定 を参照してください。 図 7: アクセスリクエストリストページ 承認の管理 承認者として、設定した通知チャネルを通じて保留中のアクセスリクエストの通知を受け取ります 。AWS Command Line Interface (AWS CLI) または好みの SDK を使用してプログラムでリクエストを承認することも、図 8 に示すように、Systems Manager コンソールの 私へのリクエスト タブでこれらのリクエストを確認することもできます。 図 8: 承認待ちのアクセスリクエストのリスト リクエストを確認した後、リクエストを承認または拒否し、オプションで決定に関連するコメントを追加できます。 アクセスサイクルの完了 リクエストが承認されると、オペレーターとして、アクセスが許可されたという通知を受け取ります。その後、図 9 に示すように、承認ポリシーに記載された期間、AWS マネジメントコンソールまたは AWS CLI を使用してノードに接続できます。 図 9: 管理対象ノードにアクセスするオペレーター まとめ このブログでは、AWS Systems Manager の新機能である ジャストインタイムノードアクセス を紹介しました。ジャストインタイムノードアクセスは、常時付与された権限を排除しながらも、Amazon EC2、オンプレミス、およびマルチクラウドノードへの迅速なアクセスを確保することで、運用効率とセキュリティ要件のバランスを取るという課題を解決します。柔軟なポリシーベースのアプローチと、手動および自動承認のサポートにより、運用能力を損なうことなくゼロスタンディング特権を実装できるようになりました。 Systems Manager はジャストインタイムノードアクセスの無料トライアルを提供しており、この機能を評価することができます。 詳細については、 Systems Manager を使用したジャストインタイムノードアクセス を参照してください。 ジャストインタイムノードアクセスの体験の完全なビジュアルツアーについては、この インタラクティブデモ をご覧ください。 Chetan Makvana Chetan Makvana は、Amazon Web Services のエンタープライズソリューションアーキテクトです。彼は AWS サービスを使用して、スケーラブルで回復力があり、安全でコスト効率の高いエンタープライズグレードのソリューションを設計し、お客様を支援しています。彼は技術愛好家であり、生成 AI、サーバーレス、アプリケーションのモダナイゼーション、DevOps を中心とした分野に興味を持つビルダーです。仕事以外では、番組の一気見、旅行、音楽を楽しんでいます。 Mark Brealey Mark Brealey は、シニアマイグレーションソリューションアーキテクトとして、パートナーが堅牢で安全、効率的なクラウドアーキテクチャを構築できるよう支援しています。彼は、組織が AWS インフラストラクチャを最大限に活用しながら運用の優秀性を確保するのに役立つスケーラブルなソリューションの設計を専門としています。 Anthony Verleysen Anthony Verleysen は、AWS Systems Manager チーム内のシニアプロダクトマネージャー – テクニカル（外部サービス）です。彼はノード管理機能に焦点を当てています。仕事以外では、Anthony は熱心なサッカーとテニスのプレーヤーです。 翻訳はソリューションアーキテクトの村田が担当しました。

この投稿では、四目並べ（プレイヤーがコマを連続して 4 つ並べて揃えるゲーム）のオンラインバージョンを作成するために必要なコアコンセプトを見ていきます。また、AWS Amplify Gen 2 が AWS バックエンドへの高速接続を可能にする方法と、WebSocket 接続を使用してプレイヤーがリアルタイムでゲームの更新を送信できるように AWS AppSync イベントの利用によってどのように実現できるかを確認します。この投稿を読み終わる頃には、IAM による承認処理を伴う AppSync イベントの使用に自信を持てるようになり、またその役割が現在のアプリケーション開発においてどのようなものであるかをよりよく理解できるはずです。 この投稿は AppSync イベントに関するシリーズの 2 件目の投稿です。 アナウンス投稿 にはこのサービスの概要が含まれていますが、AppSync Events を使用するための最初の投稿は こちら にあります。 アプリケーションの概要 最初に子供たちに人気のゲーム、三目並べで勝つ方法を教えたことを覚えています。ご存知ない人のために説明しておくと、これはいわゆる「 解決済み 」ゲームというもので、最適な戦略を取れば勝ちか引き分けを保証できる方法があります。これは子供たちにアルゴリズムを学ばせるのに最適でしたが、正直なところ、ゲームをする時間が楽しくなくなってしまったことは事実です。 幸いなことに、四目並べゲームを紹介したのは彼らがまだ幼い時でした。これは、すでに解決されたゲームですが、追跡することはより難しく、シンプルに楽しくプレーすることはずっと簡単です。 ゲームのコマを持ち運んだり、近くにいる必要はなく、私たちのアプリケーションは完全オンラインで、チャット機能をサポートしています。そして、プレイヤーにログインを要求するのではなく、ユーザー名を尋ねて、ユニークなゲームコードを生成し、そのコードをプレイ相手と共有できます。 ゲームを作成すると、あなたがプレイヤー 1 (赤) になります。ゲームに参加すると、あなたがプレイヤー 2 (黄色) になります。 相手のプレイヤーがいることを確認するために、ゲーム中はお互いにチャットを行えます。 同じ色のピースが縦、横、または斜めに 4 つ並んだら、ゲームは自動的に終了します。その後、プレイヤーは新しいゲームをするか、ゲームを完全に終了するかを選択できます。 コードとそれを自身のマシン上でホストし実行する手順が書かれた readme を含むものをご覧になるには、 リポジトリ をご覧ください。 ゲームが短命であるため、データをデータベースに保存する必要がありません。さらに、このアプリケーションのリアルタイム機能が中心となっているため、API は必要ありません。 実際、バックエンドは 2 つの中核的な AWS サービスで構成されています。 Amazon Cognito : Cognito ID プールは、イベント API への未認証アクセスに対して、限定された権限を提供します AWS AppSync イベント : 数百万のサブスクライバーに対応する独立した WebSocket エンドポイントです AWS AppSync イベント API の IAM 認証による作成 AppSync イベント API は、API キー、Cognito ユーザープール、AWS Lambda、OIDC、IAM を使って認可ができます。前回の記事では、API キーの構成方法を見ましたが、今後の記事では Lambda と Cognito の両方を紹介します。ただし、セキュアな未認証アクセスが必要なアプリケーションの場合は IAM 認証モードがよい選択肢であり、このセクションでは IAM について説明します。 Amplify では、Amplify プロジェクトを作成する際に、AWS CDK の薄いラッパーを利用します。 このプロジェクトでは AWS Amplify を使ってフルスタックアプリケーションを作成していますが、AWS AppSync のイベントを使用するのに Amplify は必須の部分ではありません。 amplify/backend.ts ファイルを見ると、 auth が構成されていることがわかります。 const backend = defineBackend({ auth }) この 1 行のコードで、Cognito ユーザープールと Cognito ID プールをセットアップします。ユーザープールはログイン済みユーザーを追跡するものですが、今回は使用しません。ID プールはログインしていないユーザーにアプリへのアクセスを許可するため、アプリケーションにとって重要です。この仕組みを示すために、Amplify を拡張するサービスを含む別の CDK スタックを作成します。 const customResources = backend.createStack('custom-resources-connect4') これは単に、サービスをまとめてメイン backend スタックの中にネストするための論理的な方法です。 この backend スタックに追加するアイテムはすべて、イベント API に関連するものになります。 const cfnEventAPI = new CfnApi(customResources, 'cfnEventAPI', { name: 'serverless-connect4', eventConfig: { authProviders: [{ authType: AuthorizationType.IAM }], connectionAuthModes: [{ authType: AuthorizationType.IAM }], defaultPublishAuthModes: [{ authType: AuthorizationType.IAM }], defaultSubscribeAuthModes: [{ authType: AuthorizationType.IAM }], }, }) new CfnChannelNamespace(customResources, 'cfnEventAPINamespace', { apiId: cfnEventAPI.attrApiId, name: 'game', }) 上記のように、まず AWS CDK の L1 コンストラクタを利用してイベント API を作成します。この際、API の名前を指定し、認証プロバイダー、接続、発行、サブスクライブを許可するプロバイダーを表す設定を渡します。 さらに、 game という root namespace を作成します。クライアントアプリはこの namespace に接続し、 /game/gameId/chat のように root から分岐することで、受信したい接続データをさらに特定できます。 Infrastructure-as-Code (IaC) でイベント API をセットアップするには、現時点では L1 コンストラクタを使用する必要があります。これらは直接、 CloudFormation リファレンス に対応しています。より高位の L2 コンストラクトが利用可能になった時点で、このシリーズの投稿は更新する予定です。 IAM を認証モードとして指定すると、イベント API を呼び出すことを許可するポリシーを Cognito Identity プールに割り当てる必要があります。 backend.auth.resources.unauthenticatedUserIamRole.attachInlinePolicy( new Policy(customResources, 'AppSyncEventPolicy', { statements: [ new PolicyStatement({ actions: [ 'appsync:EventConnect', 'appsync:EventPublish', 'appsync:EventSubscribe', ], resources: [`${cfnEventAPI.attrApiArn}/*`, `${cfnEventAPI.attrApiArn}`], }), ], }) ) 上記では、認証リソース (Cognito) から unauthenticatedUserIamRole を使用して、ポリシーを直接アタッチしています。Cognito には 2 つのロールが用意されていることに注意してください。1 つはユーザープールに格納されたログイン済みユーザー用の authenticatedRole 、もう 1 つはログインしていないユーザーに対してアイデンティティプールから権限を付与する unauthenticatedRole です。 Cognito に接続されたイベント API が設定できたので、フロントエンドアプリケーションに関連する値を渡し、接続、発行、サブスクライブ (メッセージの受信) に利用できるようにします。 backend.addOutput({ custom: { events: { url: `https://${cfnEventAPI.getAtt('Dns.Http').toString()}/event`, aws_region: customResources.region, default_authorization_type: AuthorizationType.IAM, }, }, }) Amplify JavaScript ライブラリは、 events オブジェクトの custom データ内に url 、 aws_region 、 default_authorization_type の項目が含まれていれば、イベント API と連携するようにアップデートされているので、ここのフォーマットは重要です。 このプロジェクトの readme に従えば、バックエンドが構成された後、開発者は npx ampx sandbox を実行して、これらのリソースを自分の AWS アカウントに検証環境としてデプロイできます。 AppSync イベント API への AWS Amplify による接続 Next.js アプリケーションでは、 app/page.tsx にホームページがあり、 app/game/[code]/page.tsx にゲームページがあります。 前のスクリーンショットに示されているように、ホームページは単にユーザーのユーザー名を取得し、ユーザーが新しいゲームを作成する場合、ゲームコードを生成します。そこから、ユーザーは code がゲームコードとなる 動的ルート に移動します。 app/layout.tsx ファイルで示されているように、Next.js アプリケーションは既に AWS バックエンドを使用するように構成されています。この設定は components/configureAmplify.tsx ファイルで確認できます。 app/game/[code]/page.tsx で、アプリケーションの作り込みが行われています。 aws-amplify/data ライブラリの events.connect メソッドを使用して、WebSocket エンドポイントに接続します。ページが最初にロードされた時に接続を行いたいので、 useEffect 呼び出し内で実装するのが最適です。 useEffect(() => { const subscribeToGameState = async (gameCode: string) => { const channel = await events.connect(`/game/${gameCode}`) const sub = channel.subscribe({ next: (data) => { dispatch({ type: 'UPDATE_GAME_STATE', newState: data.event }) }, error: (err) => console.error('uh oh spaghetti-o', err), }) return sub } const subPromise = subscribeToGameState(gameCode) return () => { Promise.resolve(subPromise).then((sub) => { console.log('closing the connection') sub.unsubscribe() }) } }, [gameCode]) 特定のチャネルへの接続を確立すると、そのチャネルへの発行とサブスクライブを開始できます。この使用例では、他のプレーヤーからメッセージを受信するたびに、データを reducer に送信して、新しい状態を UI にレンダリングできるようにしています。これは app/game/[code]/GameState.ts ファイルで確認できます。 最後の useEffect の部分では、ページが閉じられたりナビゲートされたりした際に、接続を切断します。これは、サブスクリプションの unsubscribe メソッドを呼び出すことで行われます。このようにすることで、メモリリークによるアプリケーションの速度低下を防ぐことができます。 イベントを発行することで、イベントソースからクライアントにデータを渡すことができます。このアプリでは、プレイヤーがボード上にピースを置いたり、「New Game」または「Reset Game」ボタンをクリックするたびに、それらの詳細を含むイベントを、チャネルの /game/${gameCode} セグメントに発行します。 await events.post(`/game/${gameCode}`, { board: newState.board, currentPlayer: newState.currentPlayer, winner: newState.winner, gameOver: newState.gameOver, }) ご覧のとおり、フルスタックアプリケーションでイベント API を利用するのはごくわずかのコードで済みます！ チャットメッセージを送信する場合も、プロセスは同じです。別の useEffect 呼び出しで、 /game/${gameCode}/chat というチャネル上でチャット接続を確立し、ユーザーがメッセージを入力して Enter キーを押すと、 await events.post(`/game/${gameCode}/chat`,newMessage) の呼び出しが送信されます。 まとめ この投稿では、Next.js のようなモダンなフロントエンドフレームワークと Amplify の機能、AppSync イベントの簡便性とスケーラビリティを組み合わせることで、アプリケーションを構築することができることを説明しました。また、Amplify の本来の機能に加えて、CDK の L1 コンストラクトを使用する方法も確認しました。 AWS AppSync イベント API は、フリーティアとして 250,000 回のイベント操作を提供し、大規模なサブスクライバー数に対応可能です。完全マネージドサービスなので、開発者は特定の API サービスに縛られることなく、アプリにリアルタイム機能を簡単に追加できます。 AWS AppSync のイベントの詳細は、 ドキュメントページ をご覧ください。 本記事は、2024 年 11 月 26 日に公開された “ Working with AWS AppSync Events: Real-time Web Games with Chat ” を翻訳したものです。翻訳は Solutions Architect の 吉村 が担当しました。

このブログは 2025 年 4 月 18 日に Sean Phuphanich (Principal Technologist at AWS)、Ivo Janssen (Senior Solutions Architect at AWS in the Nonprofit team)、Sujata Abichandani (Technical Account manager for strategic customers at AWS) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 多層防御のような階層型セキュリティ戦略では、予防が失敗した場合、軽減が重要になります。ほとんどの AWS ストレージサービスでは、不変のストレージとバックアップからのリカバリを使用して、ランサムウェアの影響を軽減しています。Autonomous Ransomware Protection (ARP) は、NetApp の ONTAP ファイルシステム上に構築された、信頼性が高く、スケーラブルで、高性能な共有ストレージを提供するフルマネージドサービスである Amazon FSx for NetApp ONTAP (FSx for ONTAP) の新しいセキュリティ機能です。ARP は、ランサムウェア攻撃からの検出機能と高速リカバリ機能の両方をさらに強化しています。AWS は複数の データの保護方法 と耐障害性のあるワークロードの実行方法をお客様に提供していますが、この記事では、NetApp Autonomous Ransomware Protection (ARP) とは何か、どのように機能するか、そしてそれを使用して FSx for ONTAP ファイルシステム上のデータ保護を強化する方法を説明します。 ARP がランサムウェアからどのように保護するか 図1 : ONTAP のセキュリティ機能 ARP は、ファイルシステムの異常なアクティビティをプロアクティブに監視し、潜在的な攻撃を検知すると ONTAP スナップショットを自動的に作成する NetApp ONTAP の機能です。これにより、ビジネスクリティカルなデータを、より広範なランサムウェア攻撃から保護することができます。ONTAP スナップショットは 、ファイルシステムへのリダイレクトオンライト（ROW）を使用し、数テラバイト規模のデータのバックアップとリカバリを数秒で実行できます。これは、ファイルシステムへのネットワーク転送に依存するあらゆるバックアップおよび復元方法よりもはるかに高速です。 ARP はワークロードのアクセスパターンを分析し、疑わしいアクティビティをプロアクティブに検出します。ARP の分析機能は、エントロピーの変化（ファイル内のデータのランダム性）、ファイル拡張子の種類の変化（一般的な拡張子の種類に一致しない拡張子）、ファイル IOPS の変化（暗号化されたデータを含む異常なボリュームアクティビティの急増）を検出し、潜在的なランサムウェアイベントを特定します。これらのパターンの一部またはすべてが、潜在的なランサムウェアイベントの兆候となる可能性があります。疑わしいアクティビティが検出されると、ARP は影響を受けるボリュームのスナップショットを自動的に作成し、疑わしい攻撃の重大度に応じて、 イベント管理システム（EMS） メッセージ、ONTAP CLI、または REST API で確認可能なアラートを生成します。 疑わしいイベントの詳細情報を表示するには、影響を受けたボリュームに関するレポートを生成し、攻撃の可能性と攻撃のタイムラインを確認できます。レポートを確認した後、アラートが誤検知または攻撃の疑いによって生成されたことを記録できます。攻撃が疑われる場合は、まず攻撃の範囲を把握して修復し、次に ARP によって作成されたスナップショットからデータを復旧します。アラートが誤検知によるものであると判断された場合、ARP によって作成されたスナップショットは自動的に削除されます。 ARP は、FSx for ONTAP で実行されている SMB または NFS ファイル共有への攻撃によるダウンタイムを軽減します。例えば、侵害されたコンピューティングインスタンスがファイル共有への承認済みアクセスを取得し、アクセス可能なすべてのデータを暗号化する可能性があります。ARP は攻撃を検知し、スナップショットを作成し、アラートを記録します（アラートは Syslog として他のシステムに転送できます）。管理者は攻撃アラートに対応し、影響を受けたファイルのレポートを確認し、復元プロセスを実行できます。 通常の使用パターンと疑わしいアクティビティを区別できないため、ARP による検出効果が低いワークロード があります。例えば、テスト環境や開発環境のように、数十万ものファイルを頻繁に作成または削除する場合、そのような動作はランサムウェアの活動と効果的に区別できません。 技術的なウォークスルー ARP を設定するには、次の手順を実行します。 機能のインストールと有効化 検出と報告 ランサムウェア攻撃後の復旧 この手順は、fsxadmin の認証情報を持ち、テスト環境の管理エンドポイント経由で ONTAP CLI に接続していること を前提としています。特に明記されていない限り、このガイド内のコマンドは ONTAP CLI 用です。 ARP のインストールと有効化 ARP には、「学習モード」（別名「ドライランモード」）と「アクティブモード」の2つのモードがあります。ARP は、ONTAP CLI または ONTAP REST API を通じて管理されます。 まず、既存のボリュームで ARP を学習モードで有効化します。 security anti-ransomware volume dry-run -volume <vol_name> -vserver <svm_name> または新しいボリュームで学習モードを有効化します： volume create -volume <vol_name> -vserver <svm_name> -aggregate <aggr_name> -size <nn> -anti-ransomware-state dry-run -junction-path </path_name> 既存のボリュームでは、学習モードとアクティブモードは新しく書き込まれたデータにのみ適用され、ボリューム内の既存のデータには適用されないことに注意してください。ボリュームで ARP が有効になった後、新しいデータに基づいて以前の通常のデータトラフィックの特性が想定されるため、既存のデータはスキャンおよび分析されません。 NetApp では、ボリュームをアクティブモードに変換する前に、最大 30 日間学習モード（上記参照）で動作させることを推奨しています。ARP は最適な学習期間間隔を自動的に決定し、学習モードからアクティブ モードへの切り替えを自動化します。切り替えは 30 日以内に完了する場合もあります。 アクティブ モードで ARP を直接有効にするには、既存のボリュームに対して次のコマンドを使用します。 security anti-ransomware volume enable -volume <vol_name> -vserver <svm_name>> SVM レベルで ARP をデフォルトで有効にすることができ、これは新しく作成されたすべてのボリュームに適用されます。 vserver modify -vserver <svm_name> -anti-ransomware-default-volume-state dry-run 最後に、ARP のステータスを確認できます。 security anti-ransomware volume show 特定のボリュームのステータスを確認するには: security anti-ransomware show -vserver <svm_name> -volume <vol_name> デフォルト値を含む ARP 設定オプションの詳細については、 ONTAP コマンドリファレンス を参照してください。 検出とレポート ARP は、ランダム化されたデータ、暗号化されたファイルの高い IOPS、または異常なファイル拡張子を検出するとアラートを生成します。アラートは EMS メッセージ、ONTAP CLI、または REST API で確認でき、誤検知またはランサムウェア攻撃の疑いの 2 種類があります。ランサムウェアの影響を受けた疑いのあるファイルのリストを含むレポートファイルは、ONTAP CLI を使用して生成できます。脅威を評価した後、管理者の対応に応じて、今後のファイルアクティビティが監視されます。 ARP が新しいファイル拡張子を検知した場合、および ARP がスナップショットを作成した場合にアラートを設定できます。詳細については、 Configure ARP alerts をご覧ください。攻撃検出パラメータは、特定のワークロードに合わせて変更できます。攻撃発生時に何が起こるかを理解していただくために、以下のコマンドの出力例をいくつか示します。 ARP がスナップショットを生成したかどうかを確認するには: napshot show -vserver <svm_name> -volume <vol_name> -snapshot Anti_ransomware_backup [サンプル出力] ---Blocks--- Snapshot Size Total% Used% ---------------- -------- ------ ----- Anti_ransomware_backup.2025-04-07_1503 3.40MB 0% 10% hourly.2025-04-07_1505 1.45GB 0% 98% hourly.2025-04-07_1605 140KB 0% 0% まず、攻撃の時間と深刻度を確認します。 security anti-ransomware volume show -vserver <svm_name> -volume <vol_name [サンプル出力] Vserver Name: fsx Volume Name: Vol1 State: enabled Dry Run Start Time: - Attack Probability: low Attack Timeline: 04/07/2025 15:08:57 Number of Attacks: 1 EMS ログでメッセージを確認することもできます。 event log show -message-name callhome.arw.activity.seen [サンプル出力] Time Node Severity Event ------------------- ---------------- ------------- ------------------------ 04/07/2025 11:27:55 cluster2-01 ALERT callhome.arw.activity.seen: Call-home message for Vol1 (UUID: c437827d-8062-11ed-9f93-005056a0123) svm1 (UUID: 4574c5fe-8916-11ec-b931-005056a0123) 次に、攻撃レポートを生成します。 security anti-ransomware volume attack generate-report -vserver <svm_name> -volume <vol_name> -dest-path <[svm_name:]vol_name/[sub-dir-name]> その後、ファイル システムからレポート ファイルを表示できます。 [サンプルファイル] 1 "4/07/2025 03:08:57" /folder/file1.jpg.cf242b 1 2 "4/07/2025 03:08:57" /folder/file2.jpg.2b591a 1 3 "4/07/2025 03:08:57" /folder/file3.jpg.4812e1 1 [file continues…] 攻撃の評価に基づいて、イベントを誤検知または潜在的なランサムウェア攻撃としてマークします。 攻撃を誤検知としてマークするには（このアクションによりスナップショットが削除されます）： anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [<extension identifiers>] -false-positive true 潜在的な攻撃に対処するには、まず攻撃への対応を行い、次に ARP によって作成されたスナップショットからデータを回復します。データが回復された後にのみ、実施した対応を記録し、監視を再開します。 anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [<extension identifiers>] -false-positive false 回復 データを復旧する前に、ARP によって検出された異常なアクティビティに対応することが重要です。ランサムウェア攻撃が確認された場合、ARP によって生成された「 Anti_ransomware_backup 」というスナップショットを使用してボリュームを復元できます。ランサムウェア攻撃が疑われる場合、ARP スナップショットはロックされます。ロックされたスナップショットは、攻撃が誤検知であると最初に特定されない限り削除できません。管理者は、ボリュームから特定のファイルを選択し、スナップショット全体を復元しないようにすることもできます。 攻撃が確認されたら、スナップショットからボリュームを復元できます。まず、 Anti_ransomware_backup スナップショットのロックを解除する必要があります。システム攻撃が報告されていない場合は、まず Anti_ransomware_backup スナップショットを復元し、その後で他のスナップショットをその上に復元する必要があります。 すべてのスナップショットを一覧表示します： volume snapshot show -vserver <svm_name> -volume <volume> スナップショットを復元します： volume snapshot restore -vserver <svm_name> -volume <volume> -snapshot <snapshot> 以前のスナップショットからデータを復元するには、まず ARP スナップショットのロックを解除する必要があります。攻撃を潜在的なランサムウェア攻撃としてマークし、疑わしいファイルを消去してください： anti-ransomware volume attack clear-suspect -vserver <svm_name> -volume <vol_name> [extension identifiers] -false-positive false 拡張子を識別するには、次のいずれかのパラメータを使用します。 [-seq-no integer] 疑わしいリスト内のファイルのシーケンス番号。 [-extension ext,… ] ファイル拡張子。 [-start-time date_time -end-time date_time] クリアするファイルの範囲の開始時刻と終了時刻を「MM/DD/YYYY HH:MM:SS」の形式で指定します。 コスト ARP は追加料金なしでご利用いただけますが、 FSx for ONTAP の標準料金が適用されます 。テストが完了したら、 未使用のリソースをクリーンアップして 追加料金が発生しないようにしてください。 追加オプション この記事の範囲を超えて、FSx for ONTAP は既存のセキュリティ対策に統合できます。 EMS イベント をセキュリティ情報イベント管理（SIEM）に取り込むことで、セキュリティイベントの可視化と一元管理が可能になります。また、サポートされているサードパーティ製ウイルス対策ソフトウェアを実行する ONTAP の機能である NetApp Vscan は、ファイルの書き込み時にマルウェア検出機能を統合できます。さらに広く、AWS 環境全体を保護するためのその他の方法については、 こちら をご覧ください。 まとめ ARP は、ファイルシステムをランサムウェア攻撃から保護することで、ビジネスの継続性を維持し、FSx for ONTAP に保存されているビジネスクリティカルなデータのデータ保護を強化します。このブログ記事では、クラウドワークロードの全体的なセキュリティ対策の重要な部分として、Amazon FSx for NetApp ONTAP の Autonomous Ransomware Protection (ARP) について説明しました。ARP は簡単にセットアップでき、従来のバックアップおよびリカバリソリューションよりも高速なリカバリ機能を提供します。CLI ベースの管理ツールを使用すると、ボリュームで ARP を有効にすることができます。その後、ARP は潜在的なイベントを検出し、自動的にスナップショットを作成します。管理者はレポートを表示し、イベントをランサムウェアまたは誤検知としてマークし、スナップショットからボリュームまたは個々のファイルを復元できます。ARP は、サービスが利用可能なすべての AWS リージョンのすべての FSx for ONTAP ファイルシステムで利用できます。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原、監修は Technical Account Manager 岡田が担当しました。 Sean Phuphanich Sean は AWS のプリンシパルテクノロジストであり、業界の複雑な課題解決に注力しています。AWS ストレージコミュニティのリーダーであり、Public Sector Zero Trust Lab チームをリードしており、ISV パートナーシップのテクニカルリーダーでもあります。 Ivo Janssen Ivo は AWS の Nonprofit チームに所属するシニアソリューションアーキテクトで、クラウドテクノロジーを通じて非営利団体のミッションを解決することに情熱を注いでいます。週末には、ボランティアのトラックマーシャルとしてレーストラックで活躍しています。 Sujata Abichandani Sujata は AWS の戦略的顧客担当シニアテクニカルアカウントマネージャーです。お客様の複雑な技術的問題のトラブルシューティングと解決を支援しています。ストレージシステム間のネットワーク接続ストレージ（NAS）の管理と移行に関する専門知識を有しています。

Meta の最新 AI モデルである Llama 4 Scout 17B と Llama 4 Maverick 17B が、 Amazon Bedrock でフルマネージドサーバーレスオプションとしてご利用いただけるようになりました。これらの新しい 基盤モデル (FM) は、Early Fusion テクノロジーを利用するネイティブなマルチモーダル機能を提供します。これは、アプリケーションでの正確な画像グラウンディングと拡張コンテキスト処理のために使用できます。 Llama 4 は、革新的な Mixture-of-Experts (MoE) アーキテクチャを採用しています。これは、コストと速度の両方を最適化ながら、推論タスクと画像理解タスク全体で強化されたパフォーマンスを提供します。このアーキテクチャアプローチにより、Llama 4 は、グローバルアプリケーション向けの拡張された言語サポートとともに、Llama 3 と比較して低コストで、改善されたパフォーマンスを提供します。 これらのモデルは既に Amazon SageMaker JumpStart で使用可能となっていましたが、今般、 エンタープライズグレードのセキュリティとプライバシー を活用して、 生成 AI アプリケーションの構築とスケールを効率化するために、Amazon Bedrock で使用できるようになりました。 Llama 4 Maverick 17B – 128 のエキスパートと合計 4,000 億のパラメータを備えたネイティブマルチモーダルモデル。画像とテキストの理解で優れたパフォーマンスを発揮し、多用途のアシスタントアプリケーションやチャットアプリケーションに適しています。このモデルは 100 万トークンのコンテキストウィンドウをサポートしており、長いドキュメントや複雑な入力の柔軟な処理を可能にします。 Llama 4 Scout 17B – 16 のエキスパート、170 億のアクティブなパラメータ、合計 1,090 億のパラメータを備えた汎用マルチモーダルモデル。これまでのすべての Llama モデルよりも優れたパフォーマンスを提供します。Amazon Bedrock は現在、Llama 4 Scout で 350 万トークンのコンテキストウィンドウをサポートしており、近い将来に拡張する予定です。 Llama 4 モデルのユースケース Llama 4 モデルの高度な機能は、さまざまな業界の幅広いユースケースのためにご利用いただけます: エンタープライズアプリケーション – ツールやワークフローを横断して推論し、マルチモーダル入力を処理して、ビジネスアプリケーションのために質の高い応答を提供できるインテリジェントエージェントを構築します。 多言語アシスタント – 画像を理解し、複数の言語で質の高い応答を提供するチャットアプリケーションを作成し、世界中のユーザーが利用できるようにします。 コードおよびドキュメントインテリジェンス – コードを理解し、ドキュメントから構造化データを抽出して、大量のテキストとコードにわたってインサイトに富んだ分析を提供できるアプリケーションを開発します。 カスタマーサポート – 画像分析機能でサポートシステムを強化し、顧客がスクリーンショットや写真を共有する際に、より効果的な問題解決を可能にします。 コンテンツ作成 – 複数の言語でクリエイティブなコンテンツを生成します。また、視覚的な入力を理解し、これに応答することもできます。 リサーチ – マルチモーダルデータを統合および分析し、テキストと画像にわたるインサイトを提供できるリサーチアプリケーションを構築します。 Amazon Bedrock での Llama 4 モデルの使用 Amazon Bedrock でこれらの新しいサーバーレスモデルを使用するには、まずアクセスをリクエストする必要があります。 Amazon Bedrock コンソール のナビゲーションペインで、 [モデルアクセス] を選択して、 Llama 4 Maverick 17B モデルと Llama 4 Scout 17B モデルに対するアクセスを切り替えます。 Llama 4 モデルは、会話型 AI インタラクションのための統合インターフェイスを提供する Amazon Bedrock Converse API を使用して、アプリケーションに簡単に統合できます。 AWS SDK for Python (Boto3) を Llama 4 Maverick と使用してマルチモーダル会話を実現する方法の例を次に示します: import boto3 import json import os AWS_REGION = "us-west-2" MODEL_ID = "us.meta.llama4-maverick-17b-instruct-v1:0" IMAGE_PATH = "image.jpg" def get_file_extension(filename: str) -> str: """Get the file extension.""" extension = os.path.splitext(filename)[1].lower()[1:] or 'txt' if extension == 'jpg': extension = 'jpeg' return extension def read_file(file_path: str) -> bytes: """Read a file in binary mode.""" try: with open(file_path, 'rb') as file: return file.read() except Exception as e: raise Exception(f"Error reading file {file_path}: {str(e)}") bedrock_runtime = boto3.client( service_name="bedrock-runtime", region_name=AWS_REGION ) request_body = { "messages": [ { "role": "user", "content": [ { "text": "What can you tell me about this image?" }, { "image": { "format": get_file_extension(IMAGE_PATH), "source": {"bytes": read_file(IMAGE_PATH)}, } }, ], } ] } response = bedrock_runtime.converse( modelId=MODEL_ID, messages=request_body["messages"] ) print(response["output"]["message"]["content"][-1]["text"]) この例は、テキストと画像の両方の入力をモデルに送信し、会話形式の応答を受信する方法を示しています。Converse API は、さまざまなモデル入力形式を扱う際の複雑さを抽象化し、Amazon Bedrock のモデル全体で一貫したインターフェイスを提供します。 よりインタラクティブなユースケースでは、Converse API のストリーミング機能も使用できます: response_stream = bedrock_runtime.converse_stream( modelId=MODEL_ID, messages=request_body['messages'] ) stream = response_stream.get('stream') if stream: for event in stream: if 'messageStart' in event: print(f"\nRole: {event['messageStart']['role']}") if 'contentBlockDelta' in event: print(event['contentBlockDelta']['delta']['text'], end="") if 'messageStop' in event: print(f"\nStop reason: {event['messageStop']['stopReason']}") if 'metadata' in event: metadata = event['metadata'] if 'usage' in metadata: print(f"Usage: {json.dumps(metadata['usage'], indent=4)}") if 'metrics' in metadata: print(f"Metrics: {json.dumps(metadata['metrics'], indent=4)}") ストリーミングを使用すると、モデル出力が生成されるのと同時に表示することで、アプリケーションはより応答性の高いエクスペリエンスを提供できます。 知っておくべきこと Llama 4 モデルは、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョン において、 Amazon Bedrock で、フルマネージドサーバーレスエクスペリエンスとともに 4 月 28 日よりご利用いただけます。 また、米国東部 (オハイオ) の Llama 4 には、 クロスリージョン推論 を介してアクセスできます。 Amazon Bedrock では、通常どおり、使用した分の料金のみをお支払いいただきます。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 これらのモデルは、テキストで 12 の言語 (英語、フランス語、ドイツ語、ヒンディー語、イタリア語、ポルトガル語、スペイン語、タイ語、アラビア語、インドネシア語、タガログ語、ベトナム語) をサポートし、画像処理では英語をサポートします。 これらの新しいモデルの使用を今すぐ開始するには、 「Amazon Bedrock ユーザーガイド」の「Meta Llama モデル」のセクション にアクセスしてください。また、 community.aws サイトの生成 AI セクションでは、ビルダーコミュニティがソリューションで Amazon Bedrock をどのように利用しているのかを詳しく知ることもできます。 – Danilo 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

4 月 28 日、 Amazon CloudFront SaaS Manager の一般提供の開始を発表いたしました。これは、 Software as a Service (SaaS) プロバイダー、ウェブ開発プラットフォームプロバイダー、複数のブランドやウェブサイトを持つ企業が、複数のドメインにわたる配信を効率的に管理するのに役立つ新機能です。お客様は既に CloudFront を利用して、低レイテンシーと高速転送でコンテンツを安全に配信しています。CloudFront SaaS Manager は、これらの組織が直面する重要な課題、すなわち、TLS 証明書、分散型サービス拒否 (DDoS) 攻撃に対する保護、パフォーマンスモニタリングを必要とするテナントウェブサイトの大規模な管理に対処します。 多数のドメインを管理するウェブ開発プラットフォームプロバイダーやエンタープライズ SaaS プロバイダーは、CloudFront Saas Manager を利用することで、世界中の CloudFront エッジロケーション、 AWS WAF 、 AWS Certificate Manager を利用するシンプルな API と再利用可能な設定を利用できるようになります。CloudFront SaaS Manager は、あらゆるお客様ドメインのために、高パフォーマンスのコンテンツ配信とエンタープライズグレードのセキュリティを提供しながら、運用上の複雑さを大幅に軽減します。 仕組み CloudFront では、 マルチテナント SaaS デプロイ を使用できます。これは、単一の CloudFront ディストリビューションが複数の異なるテナント (ユーザーまたは組織) のためにコンテンツを提供する戦略です。CloudFront SaaS Manager は、マルチテナントディストリビューションと呼ばれる新しいテンプレートベースのディストリビューションモデルを使用して、設定とインフラストラクチャを共有しながら、複数のドメインでコンテンツを提供します。ただし、単一のウェブサイトまたはアプリケーションをサポートしている場合は、標準ディストリビューションの方がより適しているか、または推奨されます。 テンプレートディストリビューションは、オリジン設定、キャッシュ動作、セキュリティ設定など、ドメイン全体で使用される基本設定を定義します。各テンプレートディストリビューションには、ウェブアクセスコントロールリスト (ACL) のオーバーライドやカスタム TLS 証明書など、ドメイン固有のオリジンパスまたはオリジンドメイン名を表すディストリビューションテナントが含まれています。 オプションで、複数のディストリビューションテナントは、視聴者にコンテンツを提供する CloudFront ルーティングエンドポイントを提供するのと同じ接続グループを使用できます。 DNS レコードは、 Canonical Name Record (CNAME) を使用して接続グループの CloudFront エンドポイントをポイントします。 詳細については、「Amazon CloudFront デベロッパーガイド」の「 Understand how multi-tenant distributions work 」にアクセスしてください。 CloudFront SaaS Manager の実際の動作 CloudFront SaaS Manager の機能をより良くご理解いただけるよう、例を挙げて説明します。MyStore という人気の e コマースプラットフォームを運営している会社があるとします。このプラットフォームは、顧客がオンラインストアを簡単に立ち上げて管理するのに役立ちます。MyStore のテナントは、優れたカスタマーサービス、セキュリティ、信頼性、使いやすさを既に享受しており、ストアの立ち上げに必要な設定はほとんどなく、直近 12 か月間のアップタイムは 99.95% です。 MyStore の顧客は、ブロンズ、シルバー、ゴールドの 3 つの異なる料金階層に均等に分散されており、各顧客には永続的な mystore.app サブドメインが割り当てられています。これらの料金階層は、さまざまな顧客セグメント、カスタマイズされた設定、運用リージョンに適用できます。例えば、ゴールド階層で、高度な機能として AWS WAF サービスを追加できます。この例では、MyStore は、プラットフォームでホストされるアプリケーションの増加に伴い、TLS 接続とセキュリティを処理するために独自のウェブサーバーを維持しないことにしました。同社は、CloudFront が運用上のオーバーヘッドの削減に役立つかどうかを評価しています。 MyStore の立場になり、CloudFront SaaS Manager を利用して、複数の階層に分散されている顧客のウェブサイトをどのように設定するのかを見てみましょう。まず、MyStore が提供する 3 つの料金階層 ( Amazon CloudFront コンソール の [SaaS] メニューの [マルチテナントディストリビューション] に示されている [ブロンズ]、[シルバー]、[ゴールド]) のそれぞれに対応するテンプレートとして機能するマルチテナントディストリビューションを作成できます。 マルチテナントディストリビューションを作成するには、 [ディストリビューションを作成] を選択し、同じ設定を共有する複数のウェブサイトまたはアプリケーションがある場合は [マルチテナントアーキテクチャ] を選択します。ステップに従って、ディストリビューションの名前、タグ、ワイルドカード証明書などの基本的な詳細を入力し、ウェブサイトやアプリケーションなどのコンテンツのオリジンタイプと場所を指定して、AWS WAF ウェブ ACL 機能を使用してセキュリティ保護を有効にします。 マルチテナントディストリビューションが正常に作成されたら、左側のナビゲーションペインの [ディストリビューションテナント] メニューで [テナントを作成] を選択して、ディストリビューションテナントを作成できます。ディストリビューションテナントを作成して、アクティブな顧客をブロンズ階層に関連付けることができます。 各テナントは、最大 1 つのマルチテナントディストリビューションに関連付けることができます。顧客の 1 つ以上のドメインをディストリビューションテナントに追加し、オリジンドメインやオリジンパスなどのカスタムパラメータ値を割り当てることができます。ディストリビューションテナントは、関連付けられているマルチテナントディストリビューションの TLS 証明書とセキュリティ設定を継承できます。また、テナント専用の新しい証明書をアタッチしたり、テナントのセキュリティ設定をオーバーライドしたりすることもできます。 ディストリビューションテナントが正常に作成されたら、このディストリビューションテナント内のドメインにトラフィックをルーティングするように DNS レコードを更新し、CloudFront アプリケーションエンドポイントをポイントする CNAME を作成することで、このステップを完了できます。詳細については、「Amazon CloudFront デベロッパーガイド」の「 ディストリビューションを作成する 」にアクセスしてください。 これで、各ディストリビューションテナント内のすべての顧客を表示して、マルチテナントディストリビューションを関連付けることができます。 顧客のビジネスニーズが高まった場合、ディストリビューションテナントを適切なマルチテナントディストリビューションに移行することで、顧客をブロンズ階層からシルバー階層にアップグレードできます。 月次メンテナンスプロセス中に、非アクティブな顧客アカウントに関連付けられており、かつ、安全に廃止できるドメインを特定します。ブロンズ階層を非推奨にして、現在ブロンズ階層にいるすべての顧客をシルバー階層に移行することを決定した場合は、マルチテナントディストリビューションを削除してブロンズ階層を関連付けることができます。詳細については、「Amazon CloudFront デベロッパーガイド」の「 ディストリビューションを更新する 」または「 Distribution tenant customizations 」にアクセスしてください。 デフォルトでは、AWS アカウントにはすべての CloudFront トラフィックを処理する 1 つの接続グループがあります。左側のナビゲーションペインの [設定] メニューで [接続グループ] を有効にすると、追加の接続グループを作成でき、トラフィック管理とテナント分離をより細かく制御できます。 詳細については、「Amazon CloudFront デベロッパーガイド」の「 Create custom connection group 」にアクセスしてください。 今すぐご利用いただけます Amazon CloudFront SaaS Manager は本日よりご利用いただけます。詳細については、 CloudFront SaaS Manager の製品ページ と ドキュメントページ にアクセスしてください。AWS での SaaS の詳細については、 AWS SaaS Factory にアクセスしてください。 今すぐ CloudFront コンソール で CloudFront SaaS Manager をお試しいただき、 AWS re:Post for Amazon CloudFront に対して、または通常の AWS サポート担当者を通じて、フィードバックをお寄せください。 – Veliswa 原文は こちら です。 _______________________________________________ ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! ( この アンケート は、外部の企業によって実施されます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS はこのアンケートを通じて収集されたデータを所有します。また、収集された情報をアンケートの回答者と共有することはありません。 )

ここ数か月で私たちが目撃したことの一つは、 基盤モデル (FM) におけるコンテキストウィンドウの拡大です。今日では多くの FM が、わずか 1 年前には想像もできなかったシーケンス長を処理できるようになりました。しかし、エンタープライズでの使用に必要な信頼性とセキュリティ基準を維持しながら、膨大な量の情報を処理できる AI を利用したアプリケーションを構築することは、依然として困難です。 これらの理由から、4 月 28 日より、フルマネージドサーバーレスオファリングとして、 Writer の Palmyra X5 および X4 モデルが Amazon Bedrock で提供開始されることをお知らせできることを喜ばしく思います。AWS は、Writer のフルマネージドモデルを提供する最初の大手クラウドプロバイダーです。Palmyra X5 は、Writer が本日リリースした新しいモデルです。Palmyra X4 は、以前は Amazon Bedrock Marketplace で提供されていました。 Writer の Palmyra モデルは、エンタープライズのセキュリティ基準と信頼性を維持しながら、複雑なエージェントベースのワークフローをサポートする堅牢な推論機能を提供します。Palmyra X5 は 100 万トークンのコンテキストウィンドウを備え、Palmyra X4 は 128K トークンのコンテキストウィンドウをサポートします。これらの広範なコンテキストウィンドウにより、これらのモデルは、アプリケーションおよびエージェント開発における従来の制約の一部を取り除き、より深い分析とより包括的なタスク完了を可能にします。 今回のリリースにより、Amazon Bedrock は、セキュリティ、プライバシー、 責任ある AI を備えた生成 AI アプリケーションの構築に必要な最先端のモデルとツールへのアクセスを継続的に提供します。 FM 開発のパイオニアである Writer は、業界をリードするモデルを Amazon SageMaker HyperPod でトレーニングおよびファインチューニングしています。最適化された分散トレーニング環境により、Writer はトレーニング時間を短縮し、モデルをより迅速に市場に投入しています。 Palmyra X5 および X4 のユースケース Writer の Palmyra X5 および X4 は、エンタープライズのユースケースのために特別に設計されており、強力な機能と、 System and Organization Controls (SOC) 2 、 Payment Card Industry Data Security Standard (PCI DSS) 、 Health Insurance Portability and Accountability Act (HIPAA) コンプライアンス 認証などの厳格なセキュリティ対策を組み合わせています。 Palmyra X5 および X4 モデルは、複数の業界にわたるさまざまなエンタープライズのユースケースで優れたパフォーマンスを発揮します: 金融サービス – Palmyra モデルは、投資銀行、アセットマネジメント、ウェルスマネジメントにわたるソリューションを強化します。これには、取引案件のサポート、10-Q、10-K、決算説明会のトランスクリプトからの要点抽出、ファンドおよび市場調査、パーソナライズされた大規模な顧客アウトリーチが含まれます。 ヘルスケアとライフサイエンス – 保険支払者と医療提供者は、Palmyra モデルを使用して、加入者の獲得やオンボーディング、異議申立てや苦情の対応、ケースマネジメントや利用管理、法人向け提案書 (RFP) 作成のためのソリューションを構築しています。製薬企業は、これらのモデルを、商用アプリケーション、メディカルアフェアーズ、R&D、臨床試験に使用しています。 小売および消費財 – Palmyra モデルは、製品説明の作成とバリエーションの作成、パフォーマンス分析、SEO アップデート、ブランドとコンプライアンスのレビュー、自動化されたキャンペーンワークフロー、RFP の分析と対応のための AI ソリューションを実現します。 テクノロジー – テクノロジー業界の企業は、パーソナライズされたアカウントベースのマーケティング、コンテンツ作成、キャンペーンワークフローのオートメーション、アカウントの準備と調査、ナレッジサポート、求人概要と候補者レポート、そして RFP への対応のために Palmyra モデルを実装しています。 Palmyra モデルは、次を含む包括的なエンタープライズグレードの機能スイートをサポートしています: 適応型思考 – 高度な推論機能とエンタープライズグレードの信頼性を組み合わせたハイブリッドモデル。複雑な問題解決や高度な意思決定プロセスで優れたパフォーマンスを発揮します。 マルチステップのツール呼び出し – 複雑なマルチステップのワークフローやエージェントアクションで使用できる高度なツール呼び出し機能のサポート。これには、システムの更新、トランザクションの実行、E メールの送信、ワークフローのトリガーなどのタスクを実行するためのエンタープライズシステムとのインタラクションが含まれます。 エンタープライズグレードの信頼性 – エンタープライズでの使用に必要となる厳格な品質基準を維持しながら、一貫性があり、かつ、精度の高い結果を実現します。モデルはビジネスコンテンツに基づいて特別にトレーニングされており、出力はプロフェッショナル基準に準拠します。 Amazon Bedrock での Palmyra X5 および X4 の使用 Amazon Bedrock におけるすべての新しいサーバーレスモデルについては、まずアクセスをリクエストする必要があります。 Amazon Bedrock コンソール のナビゲーションペインで [モデルアクセス] を選択して、 [Palmyra X5] および [Palmyra X4] モデルへのアクセスを有効にします。 モデルにアクセスできるようになると、 Amazon Bedrock Converse API を使用して、任意の AWS SDK でアプリケーションの構築を開始できます。モデルは、次の推論プロファイルを使用して クロスリージョン推論 を使用します: Palmyra X5 の場合: us.writer.palmyra-x5-v1:0 Palmyra X4 の場合: us.writer.palmyra-x4-v1:0 AWS SDK for Python (Boto3) を使用したサンプル実装を次に示します。このシナリオでは、既存の製品の新しいバージョンがあります。新機能の詳細な比較を作成する必要があります。新旧の製品マニュアルがあります。Palmyra X5 の大規模な入力コンテキストを使用して、2 つのバージョンのマニュアルを読んで比較し、比較ドキュメントの初稿を作成します。 import sys import os import boto3 import re AWS_REGION = "us-west-2" MODEL_ID = "us.writer.palmyra-x5-v1:0" DEFAULT_OUTPUT_FILE = "product_comparison.md" def create_bedrock_runtime_client(region: str = AWS_REGION): """Create and return a Bedrock client.""" return boto3.client('bedrock-runtime', region_name=region) def get_file_extension(filename: str) -> str: """Get the file extension.""" return os.path.splitext(filename)[1].lower()[1:] or 'txt' def sanitize_document_name(filename: str) -> str: """Sanitize document name.""" # 拡張子を削除してベース名を取得します name = os.path.splitext(filename)[0] # 無効な文字をスペースに置き換えます name = re.sub(r'[^a-zA-Z0-9\s\-\(\)\[\]]', ' ', name) # 複数のスペースを 1 つのスペースに置き換えます name = re.sub(r'\s+', ' ', name) # 先頭/末尾のスペースを削除します return name.strip() def read_file(file_path: str) -> bytes: """Read a file in binary mode.""" try: with open(file_path, 'rb') as file: return file.read() except Exception as e: raise Exception(f"Error reading file {file_path}: {str(e)}") def generate_comparison(client, document1: bytes, document2: bytes, filename1: str, filename2: str) -> str: """Generate a markdown comparison of two product manuals.""" print(f"Generating comparison for {filename1} and {filename2}") try: response = client.converse( modelId=MODEL_ID, messages=[ { "role": "user", "content": [ { "text": "Please compare these two product manuals and create a detailed comparison in markdown format.Focus on comparing key features, specifications, and highlight the main differences between the products." }, { "document": { "format": get_file_extension(filename1), "name": sanitize_document_name(filename1), "source": { "bytes": document1 } } }, { "document": { "format": get_file_extension(filename2), "name": sanitize_document_name(filename2), "source": { "bytes": document2 } } } ] } ] ) return response['output']['message']['content'][0]['text'] except Exception as e: raise Exception(f"Error generating comparison: {str(e)}") def main(): if len(sys.argv) < 3 or len(sys.argv) > 4: cmd = sys.argv[0] print(f"Usage: {cmd} <manual1_path> <manual2_path> [output_file]") sys.exit(1) manual1_path = sys.argv[1] manual2_path = sys.argv[2] output_file = sys.argv[3] if len(sys.argv) == 4 else DEFAULT_OUTPUT_FILE paths = [manual1_path, manual2_path] # 各ファイルの存在を確認します for path in paths: if not os.path.exists(path): print(f"Error: File does not exist: {path}") sys.exit(1) try: # Bedrock のクライアントを作成します bedrock_runtime = create_bedrock_runtime_client() # 両方のマニュアルを読みます print("Reading documents...") manual1_content = read_file(manual1_path) manual2_content = read_file(manual2_path) # ドキュメントから直接比較を生成します print("Generating comparison...") comparison = generate_comparison( bedrock_runtime, manual1_content, manual2_content, os.path.basename(manual1_path), os.path.basename(manual2_path) ) # 比較結果をファイルに保存します with open(output_file, 'w') as f: f.write(comparison) print(f"Comparison generated successfully! Saved to {output_file}") except Exception as e: print(f"Error: {str(e)}") sys.exit(1) if __name__ == "__main__": main() AWS SDK で Amazon Bedrock を利用する方法については、 「Amazon Bedrock ユーザーガイド」のコードサンプル をご覧ください。 知っておくべきこと Writer の Palmyra X5 および X4 モデル は、米国西部 (オレゴン) の AWS リージョン において、 Amazon Bedrock で、 クロスリージョン推論 とともに本日よりご利用いただけます。リージョン別のモデルサポートに関する最新情報については、 Amazon Bedrock のドキュメント をご覧ください。料金については、「 Amazon Bedrock の料金 」にアクセスしてください。 これらのモデルは、英語、スペイン語、フランス語、ドイツ語、中国語、および他に複数の言語をサポートしているため、グローバルエンタープライズアプリケーションに適しています。 これらのモデルの拡張コンテキスト機能を使用することで、デベロッパーは、広範なドキュメントの処理、複雑なマルチステップ推論の実行、高度なエージェントワークフローの処理が可能な、より高度なアプリケーションとエージェントを構築できます。 Writer の Palmyra X5 および X4 モデルの使用を今すぐ開始するには、「 Amazon Bedrock ユーザーガイド 」の Writer のモデルのセクションにアクセスしてください。また、 community.aws サイトの生成 AI セクションでは、ビルダーコミュニティがソリューションで Amazon Bedrock をどのように利用しているのかを詳しく知ることもできます。 これらの強力な新機能を使用して何を構築したのかを、ぜひお知らせください! – Danilo 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

Summit シーズンが本格的に到来しました! AWS Summit に参加したことがない方は、ぜひお近くで開催される Summit に足を運んでみてください。Summit は大規模な終日イベントで、講演に参加したり、興味深いデモやアクティビティを見たり、AWS や業界関係者と交流したりできます。また、これ以外のお楽しみもご用意しています。何より、参加費は無料です。必要なのは、登録することだけです! Summit のリストは、こちらの AWS イベントページ でご覧いただけます。ちなみに、同じページで、お近くで開催される他の AWS イベントもご覧いただけます。横にあるフィルターを使用して、興味のあるイベントを見つけてください。 AWS Summit といえば、今週は AWS Summit London (4 月 30 日) が開催されます。私にとって地元開催ということもあり、企画にも深く関わってきました。絶対に見逃せないイベントです! ぜひチェックしてみてください。会場でお会いできることを願っています。 4 月 21 日週の AWS のエキサイティングなリリースのハイライトを知りたいですか? それでは見てみましょう! 注目の新機能 まずは、4 月 21 日週にリリースされた機能強化をいくつか見てみましょう。 Amazon Q Developer が機能開発のための最先端のエージェントをリリース – AWS は、Amazon Q Developer のソフトウェア開発エージェントのアップデートを発表しました。このエージェントは、業界ベンチマークで最先端のパフォーマンスを達成し、コーディングの問題に対して複数の候補ソリューションを生成できます。この新しいエージェントは、より信頼性の高い提案を提供します。これは、デバッグ時間を短縮するのに役立つとともに、デベロッパーがより高度な設計とイノベーションに注力することを可能にします。 Amazon Cognito が更新トークンのローテーションのサポートを開始 – Amazon Cognito が OAuth 2.0 更新トークンのローテーションをサポートするようになりました。これにより、ユーザープールクライアントは、既存の更新トークンを新しい更新トークンに定期的かつ自動的に置き換えることができるため、ユーザーの再認証を必要とせずにセキュリティを強化できます。この機能は、利便性を考慮した長期トークンと、セキュリティを重視した短期トークンのいずれかをお客様に選択させるのではなく、更新トークンを頻繁に自動更新するため、お客様がシームレスなユーザーエクスペリエンスと強化されたセキュリティの両方を実現するのに役立ちます。 Amazon Bedrock Intelligent Prompt Routing の一般提供を開始 – Amazon Bedrock Intelligent Prompt Routing の一般提供が開始されました。この機能は、モデルファミリー内の異なる基盤モデルにプロンプトを自動的にルーティングすることで、応答の質とコストを最適化します。このサービスは、Claude (Anthropic)、Llama (Meta)、Nova (Amazon) などの複数のモデルファミリーにわたって向上した設定可能性を提供するため、ユーザーは、1 つのファミリーから任意の 2 つのモデルを選択し、カスタムルーティング条件を設定できます。 M365 Word および Outlook 向けの Amazon Q Business 統合のアップグレード – Microsoft Word および Outlook 向けの Amazon Q Business 統合では、企業ナレッジベースの検索、画像添付のサポート、より詳細なプロンプトのためのより大きなコンテキストウィンドウの処理が可能になりました。これらの機能強化により、ユーザーは、アプリケーションやコンテキストを切り替えることなく、ドキュメントや E メールの作成中に、インデックスが付けられた企業データにシームレスにアクセスし、よりリッチなコンテンツを取り込むことができます。 セキュリティ 4 月 21 日週はセキュリティに関する新たな改善がいくつかリリースされましたが、特に私の目に留まったものを次にご紹介します: AWS Account Management で、認可済み IAM プリンシパルを介したアカウント名の更新のサポートを開始 – AWS では、IAM プリンシパルがアカウント名を更新できるようになり、ルートユーザーアクセスに関する以前の要件がなくなりました。これは、スタンドアロンアカウントと AWS Organizations 内のメンバーアカウントの両方に適用され、そこで管理アカウントの認可済み IAM プリンシパルと委任された管理者アカウントがアカウント名を一元的に管理できます。 AWS Resource Explorer が AWS PrivateLink のサポートを開始 – AWS Resource Explorer は、すべての商用リージョンで AWS PrivateLink をサポートするようになりました。これにより、パブリックインターネットアクセスを必要とせずに、VPC 内の AWS リージョンとアカウント全体で、安全なリソース検出および検索機能を実現できます。 Amazon SageMaker Lakehouse が属性ベースのアクセス制御のサポートを開始 – Amazon SageMaker Lakehouse は、属性ベースのアクセス制御 (ABAC) をサポートするようになりました。これにより、管理者は、個別のポリシーを作成するのではなく、IAM ID に関連付けられた動的な属性を使用してデータアクセス許可を管理できます。これは、一致するタグを持つすべての IAM プリンシパルに許可が自動的に付与されるようにすることで、アクセス管理を簡素化します。これにより、チームの拡大に合わせてアクセス制御をより効率的に処理できるようになります。 ネットワーキング ご存知かもしれませんが、業界では、可能な限り既存のインフラストラクチャを移行しながら、新しいシステムのデフォルトプロトコルとして IPv6 を採用しようという気運が高まっています。今週、お客様がこの目標を達成するのをサポートするために、さらに 2 つのサービスが IPv6 のサポートを追加しました: Amazon SQS がインターネットプロトコルバージョン 6 (IPv6) のサポートを開始 – Amazon SQS は、API リクエストで IPv6 をサポートするようになりました。これにより、お客様は、パブリックエンドポイントを通じて、IPv6、IPv4、またはデュアルスタッククライアントを使用して通信できるようになりました。 AWS AppConfig がインターネットプロトコルバージョン 6 (IPv6) のサポートを開始 – 既存の IPv4 機能を維持しながら、IPv4 と IPv6 の両方のエンドポイントをサポートするようになりました。 キャパシティとコスト Amazon Kinesis Data Streams をご利用のお客様は、より高いデフォルトクォータを利用できます。また、Amazon Redshift Serverless をご利用のお客様は、新たなコスト削減の機会を活用できます。 Amazon Kinesis Data Streams のデフォルトのシャード制限が AWS アカウントあたり最大 20,000 に引き上げ – Amazon Kinesis Data Streams は、特定のリージョンでアカウントあたり最大 20,000 シャードという、より高いデフォルトの処理キャパシティをサポートするようになりました。これにより、お客様は、制限の引き上げをリクエストすることなく、10 GB/秒の入力と 20 GB/秒の出力を処理できます。 Amazon Redshift Serverless のサーバーレス予約 – 特定の RPU キャパシティを 1 年間契約することで、Amazon Redshift Serverless のコストを最大 24% 削減できるようになりました。前払いなしで 20% 割引を受けるか、全額前払いで最大限のコスト削減を実現するかを選択できます。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページにアクセスしてください。 推奨される学習リソース 最近、MCP が話題になっています! AWS で MCP を活用する可能性について、最新情報や詳細を知るのに役立つ 2 つのすばらしいブログ記事をご紹介します。 Model Context Protocol (MCP) and Amazon Bedrock – この記事では、Giuseppe Battista が Amazon Bedrock で MCP を使用する方法を解説しています。 Scaling MCP Across Your Organization Through AWS Lambda – Chris Williams 氏が、スケーラビリティとセキュリティを実現するために、AWS Lambda で実行されるリモートツールを登録しながら、MCP サーバーをローカルに維持できるようにする方法についての非常に興味深い方法をご紹介します。 毎週月曜日に公開される Weekly Roundup は、AWS のリリースに関する最新情報を把握するのに役立ちます。5 月 5 日週もぜひチェックして、エキサイティングなニュースをご覧ください! よい一日をお過ごしください! 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

本記事は 2025 年 4 月 29 日に公開された “ Extend the Amazon Q Developer CLI with Model Context Protocol (MCP) for Richer Context ” を翻訳したものです。 本日、 Amazon Q Developer はコマンドラインインターフェイス（CLI）での Model Context Protocol (MCP) サポート を発表しました。開発者は MCP サポートを使用して外部データソースを Amazon Q Developer CLI に接続し、よりコンテキストを意識した応答を得ることができます。MCP ツールとプロンプトを Amazon Q Developer CLI に統合することで、事前構築された幅広い統合リストや、 stdio をサポートするあらゆる MCP サーバーにアクセスできるようになります。この追加コンテキストにより、Amazon Q Developer は、独自の統合用のコードを開発する必要なく、より正確なコードを記述し、データ構造を理解し、適切なユニットテストを生成し、データベースドキュメントを作成し、正確なクエリを実行できるようになります。MCP ツールとプロンプトで Amazon Q Developer を拡張することで、開発者は開発タスクをより迅速に実行でき、開発者体験を効率化できます。AWS では、Anthropic による Model Context Protocol (MCP) のようなエージェント向けの人気のあるオープンソースプロトコルをサポートすることに取り組んでいます。今後数週間のうちに、Amazon Q Developer IDE プラグイン内でこの機能を拡張していく予定です。 はじめに 私は常に、自分の作業を効率化し、新しい可能性を引き出せるツールやテクノロジーを探しています。そのため、Amazon Q Developer コマンドラインインターフェイス（CLI）に Model Context Protocol (MCP) サポートが最近追加されたことをとても嬉しく思います。MCP は、アプリケーションが LLM とシームレスに統合する方法を標準化するオープンプロトコルであり、コンテキストを共有し、データソースにアクセスし、AI を活用した機能を実現する共通の方法を提供します。MCP についての詳細は この記事 で読むことができます。 Amazon Q Developer は以前からツールを実行することができました。私はこれまで、 CLI コマンドの実行や AWS リソースの記述ができることについて 紹介してきました。そして、Amazon Q Developer CLI が MCP ツールとプロンプトをサポートしたことで、さらにツールを追加できるようになりました。たとえば、これまではAWリソースを取得して確認することはできましたが、アプリケーションを開発するためには、データベーススキーマやメッセージのフォーマットなども確認する必要があります。ここで、MCP を設定してこの追加コンテキストを提供する方法を見てみましょう。 この投稿では、私が取り組んでいる単純な学習管理システム（Learning Management System : LMS）のデータベーススキーマを Amazon Q Developer に提供するための MCP サーバーを設定します。Amazon Q Developer は SQL を記述するのが得意ですが、私のデータベースのスキーマは知りません。テーブル構造やリレーションはデータベースに保存されており、プロジェクトのソースコードには含まれていません。そこで、データベーススキーマを照会できる MCP サーバーを使用することにしました。具体的には、 公式の PostgreSQL リファレンス実装 を使用して Amazon Relational Database Service (RDS) に接続します。それでは、始めましょう。 Model Context Protocol の登場前 MCP サポートが導入される以前の Amazon Q Developer CLI は、bash コマンドの実行、ファイルやファイルシステムとのやりとり、さらには AWS サービスへの呼び出しなど、ネイティブツール群を提供していました。しかし、データベースのクエリに関しては、CLI の機能は限られていました。 たとえば、MCP サーバーを設定する前に、Amazon Q Developer に「学生と各学生が取得している単位数を一覧表示するクエリを書いて」と頼みました。以下の画像にあるように、Amazon Q Developer は私の LMS のデータベーススキーマに関する具体的な知識がなかったため、一般的な SQL クエリしか生成できませんでした。 これは素晴らしいスタートですが、Amazon Q developer がデータベーススキーマを把握していれば、もっと多くのことができそうです。 Model Context Protocol の設定 Amazon Q Developer CLI の MCP サポートの開始により、MCP サーバーを簡単に設定できるようになりました。 mcp.json というファイルに 1 つ以上の MCP サーバーを設定します。この設定をホームディレクトリ（例： ~/.aws/amazonq/mcp.json ）に保存すると、マシン上のすべてのプロジェクトに適用されます。あるいは、ワークスペースのルート（例： .amazonq/mcp.json ）に設定を保存して、プロジェクトメンバー間で共有することもできます。以下は PostgreSQL の MCP サーバーの設定例です。 { "mcpServers": { "postgres": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-postgres", "postgresql://USERNAME:PASSWORD@HOST:5432/DBNAME" ] } } } MCP サーバーを設定したところで、Amazon Q Developer がどのように私の体験を向上させるかを見てみましょう。 Model Context Protocol の登場後 まず、新しい Amazon Q Developer セッションを開始すると、すぐにその良さが確認できます。既存のツールに加えて、Amazon Q Developer は以下の画像に示すように PostgreSQL にアクセスできるようになりました。これにより、追加で統合用のコードを書くことなく、データベースのスキーマを簡単に探索し、テーブルの構造を理解し、さらには複雑な SQL クエリを実行できます。 MCP サーバーをテストするために、Amazon Q Developer に「データベーステーブルを一覧表示して」と頼んでみましょう。以下の例で見られるように、Amazon Q Developer は私が PostgreSQL データベースについて尋ねていることを理解し、MCP サーバーを使用して私の 3 つのテーブル「students」「courses」「enrollment」をリストアップしました。 この投稿の前半で取り上げた例に戻ってみましょう。再び、Amazon Q Developer に「学生と各学生が取得している単位数を一覧表示するクエリを書いて」と頼むと、今度はもはや一般的なクエリを返すだけではありませんでした。代わりに、Amazon Q Developer はまず私のデータベース内の関連するテーブルについて記述し、適切な SQL クエリを生成し、それを実行して、期待する結果を提供してくれました。 もちろん、Amazon Q Developer はクエリを書くだけでなく、もっと多くのことができます。Amazon Q Developer は MCP サーバーを使用して、データベースにアクセスする Java コードを書いたり、データレイヤーのユニットテストを作成したり、データベースのドキュメントを作成したりなど、さらに多くのことができます。たとえば、Amazon Q Developer に「Mermaid 構文を使用してエンティティ関係（ER）図を作成して」と頼みました。Amazon Q Developer はデータベーススキーマの視覚的な表現を生成し、さまざまなエンティティ間の関係をより明確に理解するのに役立ちました。 MCP の Amazon Q Developer CLI への統合により、必要に応じて追加ツールを導入できるようになり、作業が大幅に効率化されました。 まとめ Amazon Q Developer CLI に MCP サポートが追加されたことで、コンテキストの共有やデータソースへのアクセスを標準化された方法で行えるようになりました。この投稿では、Amazon Q Developer CLI の MCP 統合を使用して、PostgreSQL データベースへの接続をすばやく設定し、スキーマを探索し、追加の統合コードを書くことなく複雑な SQL クエリを生成する方法をご紹介しました。今後、皆さんが MCP を活用して開発作業をさらに強化する様子を見るのが楽しみです。是非、 MCP の機能を試し 、GitHub の AWS MCP サーバー リポジトリをチェックすることをオススメします。 翻訳はApp Dev Consultantの宇賀神が担当しました。

米国東部 (バージニア北部) リージョンは、 Amazon Web Services (AWS) が初めて立ち上げた リージョン であり、過去数年間で驚異的な成長を遂げ、お客様に広く利用されてきました。現在、スタートアップから大企業まで、幅広いお客様にご利用いただいている AWS は、米国東部 (バージニア北部) リージョンのインフラストラクチャとキャパシティを着実に拡大してきました。米国東部 (バージニア北部) リージョンは 6 つの アベイラビリティーゾーン で構成されており、強化された冗長性をお客様に提供するとともに、お客様が高可用性アプリケーションを設計できるようにしています。 4 月 24 日、メリーランド州に所在する新しいアベイラビリティーゾーンが米国東部 (バージニア北部) リージョンに追加されることをお知らせします。このリージョンは 2026 年に開設予定です。 この新しいアベイラビリティゾーンは、完全に冗長的な専用ファイバー経由で、高帯域幅かつ低レイテンシーのネットワーク接続によって、他のアベイラビリティーゾーンに接続されます。メリーランド州に開設予定のアベイラビリティーゾーンは、米国東部 (バージニア北部) リージョンにおける 生成 AI と 高度なコンピューティングワークロード の急速な成長をサポートするうえでも重要な役割を果たします。 すべてのアベイラビリティーゾーンは、リージョン内において、他のアベイラビリティーゾーンから物理的に数キロメートル (km) 離れていますが、すべてのアベイラビリティーゾーンは互いに 100 km (60 マイル) 以内にあります。ネットワークパフォーマンスは、米国東部 (バージニア北部) リージョン内のメリーランド州とバージニア州のアベイラビリティーゾーン間で同期レプリケーションを実行するのに十分です。アプリケーションが複数のアベイラビリティーゾーンにパーティショニングされている場合、ワークロードはより適切に分離され、停電、落雷、竜巻、地震などの問題から保護されます。 今回の発表により、AWS が現在取り組んでいるのは、 ニュージーランド 、 サウジアラビア王国 、 台湾 、 AWS European Sovereign Cloud の 4 つの新しいリージョンと、今後立ち上げ予定の 13 の新しいアベイラビリティーゾーンとなりました。 新しいアベイラビリティーゾーンの地理的情報 3 月に、すべての AWS リージョンとアベイラビリティーゾーンの 地理的位置情報 についてのよりきめ細かい可視性を提供しました。メリーランド州に新たに開設予定のこのアベイラビリティーゾーンの新しい地理的情報を反映するため、「 AWS Regions and Availability Zones 」ページを更新しました。次のスクリーンショットに示すように、新たに開設予定のアベイラビリティーゾーンのインフラストラクチャは、米国東部 (バージニア北部) us-east-1 リージョンのために、 メリーランド州 ( 米国 ) に配置される予定です。 お客様は引き続きこの地理的情報を使用して、規制、コンプライアンス、運用上の要件に適合するアベイラビリティーゾーンを選択できます。 新しいアベイラビリティーゾーンが立ち上げられると、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK を通じて、米国東部 (バージニア北部) リージョンの他のアベイラビリティーゾーンとあわせて利用できるようになります。 引き続きご期待ください 米国東部 (バージニア北部) リージョンのこの新しいアベイラビリティーゾーンは、2026 年に一般提供が開始される予定です。新しいアベイラビリティーゾーンが開設されたらすぐに知ることができるよう、いつものように AWS ニュースブログの リージョンニュース をご確認ください。 詳細については、 AWS グローバルインフラストラクチャのリージョンとアベイラビリティーゾーン のページまたは AWS ドキュメントの「 AWS Regions and Availability Zones 」ページにアクセスしてください。フィードバックは、 AWS re:Post に、または通常の AWS サポートの連絡先を通じてお寄せください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

4 月 24 日、 AWS AppSync Events がチャネル名前空間のデータソース統合をサポートするようになったことをお知らせします。これにより、デベロッパーは、より高度なリアルタイムアプリケーションを作成できるようになりました。この新機能により、 AWS Lambda 関数、 Amazon DynamoDB テーブル、 Amazon Aurora データベース、および他のデータソースをチャネル名前空間ハンドラーに関連付けることができます。AWS AppSync Events を利用すると、データ検証、イベント変換、イベントの永続的ストレージなどの機能を備えたリッチなリアルタイムアプリケーションを構築できます。 これらの新機能により、デベロッパーは、Lambda 関数を利用してイベントを変換およびフィルタリングすることで高度なイベント処理ワークフローを作成したり、新しい AppSync_JS バッチユーティリティを使用してイベントのバッチを DynamoDB に保存したりできます。この統合により、複雑なインタラクティブフローを実現でき、開発時間と運用上のオーバーヘッドを削減できます。例えば、複雑な統合コードを記述することなく、イベントをデータベースに自動的に保存できるようになりました。 データソース統合の概要 AWS マネジメントコンソール を使用してデータソース統合をセットアップする方法を順に見ていきましょう。まず、コンソールで AWS AppSync に移動し、Event API を選択 (または新規作成) します。 イベントデータを DynamoDB に直接永続化 複数の種類のデータソース統合から選択できます。この最初の例では、データソースとして DynamoDB テーブルを作成します。まず DynamoDB テーブルが必要なので、コンソールで DynamoDB に移動し、 event-messages という新しいテーブルを作成します。この例で必要なのは、 id というパーティションキーを使用してテーブルを作成することだけです。ここで、 [テーブルを作成] をクリックし、デフォルトのテーブル設定を受け入れてから、コンソールで AppSync に戻ります。 AppSync コンソール で、先ほど設定した Event API に戻り、タブ付きナビゲーションパネルから [データソース] を選択して、 [データソースを作成] ボタンをクリックします。 データソースに名前を付けた後、 [データソース] ドロップダウンメニューから [Amazon DynamoDB] を選択します。これで DynamoDB の設定オプションが表示されます。 データソースの設定が完了したら、ハンドラーロジックを実装できます。DynamoDB にイベントを永続化するパブリッシュハンドラーの例を次に示します: import * as ddb from '@aws-appsync/utils/dynamodb' import { util } from '@aws-appsync/utils' const TABLE = 'events-messages' export const onPublish = { request(ctx) { const channel = ctx.info.channel.path const timestamp = util.time.nowISO8601() return ddb.batchPut({ tables: { [TABLE]: ctx.events.map(({id, payload}) => ({ channel, id, timestamp, ...payload, })), }, }) }, response(ctx) { return ctx.result.data[TABLE].map(({ id, ...payload }) => ({ id, payload })) }, } ハンドラーコードを追加するために、タブ付きナビゲーションで [名前空間] をクリックします。そこでは、新しい [デフォルト] の名前空間が既に作成されています。デフォルトの名前空間をクリックして開くと、設定の詳細のすぐ下に [イベントハンドラー] を追加するためのボタンがあります。 [イベントハンドラーを作成] をクリックすると新しいダイアログが開きます。そこで、設定として [データソースを使用したコード] を選択し、パブリッシュ設定として DynamoDB データソースを選択します。 ハンドラーを保存したら、コンソールに組み込まれているテストツールを使用して統合をテストできます。ここでのデフォルト値は機能するはずです。以下に示すように、2 つのイベントが DynamoDB テーブルに正常に書き込まれました。 DynamoDB でキャプチャされたすべてのメッセージは次のとおりです! エラー処理とセキュリティ 新しいデータソース統合には、包括的なエラー処理機能が含まれています。同期オペレーションでは、機密性の高いバックエンド情報をクライアントに公開しないことでセキュリティを維持しながら、 Amazon CloudWatch にログ記録される特定のエラーメッセージを返すことができます。認可シナリオでは、Lambda 関数を使用してカスタム検証ロジックを実装し、特定のチャネルまたはメッセージタイプに対するアクセスを制御できます。 今すぐご利用いただけます AWS AppSync Events のデータソース統合は、AWS AppSync が利用可能なすべての AWS リージョンで今すぐご利用いただけます。これらの新機能は、AWS AppSync コンソール、 AWS コマンドラインインターフェイス (CLI)、または AWS SDK を通じてご利用いただけます。データソース統合の使用に追加料金はかかりません。お支払いいただくのは、(Lambda 呼び出しや DynamoDB オペレーションなど) 使用した基盤となるリソースと、既存の AppSync Events の使用量についての料金のみです。 AWS AppSync Events とデータソース統合の詳細については、 AWS AppSync Events のドキュメント にアクセスしてください。より強力なリアルタイムアプリケーションの構築を今すぐ開始しましょう。 – Micah 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

2018 年の AWS Graviton プロセッサのリリース 以来、当社はイノベーションを続け、お客様のクラウドワークロードのパフォーマンスを向上させてきました。Graviton3 ベースのインスタンスの成功を受けて、NVMe ベースの SSD ローカルストレージ搭載の AWS Graviton4 プロセッサ を利用した 3 つの新しい Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーであるコンピューティング最適化インスタンス (C8gd)、汎用インスタンス (M8gd)、メモリ最適化インスタンス (R8gd) を発表できることを嬉しく思います。これらのインスタンスは、同等の AWS Graviton3 ベースのインスタンスと比較して、コンピューティングパフォーマンスが最大 30%、I/O 集約型データベースワークロードのパフォーマンスが最大 40% 向上し、I/O 集約型リアルタイムデータ分析のクエリ結果が最大 20% 高速になります。 新しいインスタンスにおいて改善された点をいくつか見てみましょう。これらのインスタンスは、Graviton3 ベースの以前のインスタンスと比較して、最大 3 倍の vCPU (最大 192 個の vCPU)、3 倍のメモリ (最大 1.5 TiB)、3 倍のローカルストレージ (最大 11.4 TB の NVMe SSD ストレージ)、75% 増のメモリ帯域幅、2 倍の L2 キャッシュを実現する、より大きなインスタンスサイズを提供します。これらの機能が、大量のデータの処理、ワークロードのスケールアップ、結果が出るまでの時間の短縮、総保有コスト (TCO) の削減を実現します。これらのインスタンスは、最大 50 Gbps のネットワーク帯域幅と最大 40 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅も提供しており、Graviton3 ベースのインスタンスに比べて大幅に改善されています。さらに、 EC2 インスタンスの帯域幅加重設定 を使用して、これらのインスタンスのネットワークと Amazon EBS の帯域幅を最大 25% 調整できるようになりました。これにより、帯域幅リソースの割り当てをより柔軟に行えるようになり、ワークロードをより適切に最適化できます。 AWS Graviton4 に構築されたこれらのインスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Container Registry (Amazon ECR) 、Kubernetes、Docker、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションを使用して構築された、マイクロサービスベースのコンテナ化されたアプリケーションを含む、ストレージ集約型の Linux ベースのワークロードに適しています。AWS Graviton4 プロセッサは、AWS Graviton3 プロセッサと比較した場合、ウェブアプリケーションでは最大 30%、データベースでは 40%、大規模な Java アプリケーションでは 45% 高速です。 インスタンスの仕様 また、これらのインスタンスには 2 つのベアメタルサイズ ( metal-24xl と metal-48xl ) が用意されているため、インスタンスを適切なサイズに設定して、物理リソースに直接アクセスできる利点があるワークロードをデプロイできます。さらに、これらのインスタンスは AWS Nitro System に構築されており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。そして、Graviton4 プロセッサは、すべての高速物理ハードウェアインターフェイスを完全に暗号化することで、強化されたセキュリティを提供します。 インスタンスはファミリーあたり 10 サイズで利用でき、それぞれ 2 種類のベアメタル構成が用意されています。 インスタンス名 vCPU メモリ (GiB) (C/M/R) ストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 2/4/8* 1 x 59 最大 12.5 最大 10 large 2 4/8/16* 1 x 118 最大 12.5 最大 10 xlarge 4 8/16/32* 1 x 237 最大 12.5 最大 10 2xlarge 8 16/32/64* 1 x 474 最大 15 最大 10 4xlarge 16 32/64/128* 1 x 950 最大 15 最大 10 8xlarge 32 64/128/256* 1 x 1900 15 10 12xlarge 48 96/192/384* 3 x 950 22.5 15 16xlarge 64 128/256/512* 2 x 1900 30 20 24xlarge 96 192/384/768* 3 x 1900 40 30 48xlarge 192 384/768/1536* 6 x 1900 50 40 metal-24xl 96 192/384/768* 3 x 1900 40 30 metal-48xl 192 384/768/1536* 6 x 1900 50 40 *メモリ値はそれぞれ C8gd/M8gd/R8gd のものです 利用可能なリージョンと料金 M8gd、C8gd、R8gd インスタンスは、現在、米国東部 (バージニア北部、オハイオ) および米国西部 (オレゴン) リージョンでご利用いただけます。これらのインスタンスは、オンデマンドインスタンス、Savings Plans、スポットインスタンスとして、またはハードウェア専有インスタンスあるいは専有ホストとして購入できます。 今すぐご利用いただけます M8gd、C8gd、R8gd の各インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または AWS SDK を使用して、サポートされているリージョンで今すぐ起動できます。詳しくは、アプリケーションを Graviton インスタンスタイプに移行する際に役立つ一連の Graviton リソース をご覧ください。 Graviton 使用開始ガイド にアクセスして、Graviton の導入ジャーニーを開始することもできます。 – Micah 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

こんにちは！アマゾン ウェブ サービス ジャパンのソリューションアーキテクト金杉です。 近年、生成 AI 技術の進化により、AI エージェントが大きな注目を集めています。特に、開発者の生産性を飛躍的に向上させる AI Coding Agent の活用が企業の間で熱を帯びています。AWS では、こうした生成 AI アプリケーションを効果的に構築・運用するためのプラットフォームを提供するとともに、GenAI Ops を通じた運用面でのサポートも充実させています。 生成 AI の最新状況をお届けするために、5月に7つのイベントを開催します。実際に導入・活用されているお客様による貴重な事例共有や、パートナー様のセッションも予定されています。本ブログでは、これらイベントについて、その概要と見どころをご紹介します。 情報満載！5月に予定されているイベント AI Agent 開発の 0→1 – AWS の実証事例に学ぶ、企画から組織展開までのメソッド (5月8日) 本セミナーは AI エージェント技術の活用を検討・推進されている方に最適です。AWS、Weights & Biases、エウレカ、TIS の各登壇者たちから実際の経験に基づいた知見をお話しします。本セミナー全体を通じ、企画から開発、運用・評価まで全工程にわたる知見を得ることが出来ます。 Amazon Bedrock Agent や W&B Weave、Langfuse などを活用した具体的な実装方法や AI Coding Agent による開発プロセスの自動化などについて実践的なアプローチを学ぶことができる貴重な機会ですので、ぜひご参加ください！ 実施日程 2025年5月8日 (木) 10:00〜12:00 形式 オンライン 登録は こちら Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ ~ (5月13日) 本セミナーでは、Cline と Amazon Bedrock を組み合わせ、企業として安全に AI Coding Agent を導入し、開発生産性の向上とセキュアな運用を両立を目指した環境を実際に体験いただきます。開発エージェントで出来ることは理解しているし、生産性が向上するメリットも分かるけど、どうやって開発業務に組み込めば良いのか分からないという方向けにぴったりのイベントです！ 実施日程 2025年5月13日 (火) 13:00〜16:10 形式 物理開催 @ AWS 目黒オフィス 登録は こちら JAWS-UG Expert Online: Amazon Q Developer 特集 (5月14日) JAWS-UG コミュニティによる Amazon Q Developer に特化したオンラインイベントです。Amazon Q Developer は直近 強化された Amazon Q Developer CLI や、 日本語を含む言語対応の拡大 などワクワクする新機能をアナウンスしています。本イベントでは、Amazon Q Developer の基礎、そして AWS のソリューションアーキテクトによる事例や活用のテクニックをライトニングトーク形式で共有します。JAWS-UG の各支部が合同で開催し、メインセッションの後に各支部が独自コンテンツを用意しています。気になった支部にぜひ参加登録してみてください！ 実施日程 2025年5月14日 (水) 19:00〜 (支部により終了時間が異なります) 形式 オンライン 登録はこちら [ 金沢 | 磐田 | 新潟 | 福岡 | AI/ML | 佐賀 ] ※ 申し込みページ準備中の支部があります。公開され次第、追記します。 GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 (5月15日) 本イベントは生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現するハンズオンワークショップです。継続的評価の重要性を説く Eval-Centric AI の考え方や、オープンソースの生成 AI オブザーバビリティのツールとして代表的な Langfuse の解説から、ハンズオンワークショップを通じた実装体験まで、GenAIOps の実践に役立つ知見を提供します。 実施日程 2025年5月15日 (木) 14:00～17:30 (開場 13:30) 形式 物理開催 @ AWS 目黒オフィス Startup Loft 登録は こちら AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 (5月22日) ソフトウェア開発の生産性が劇的に向上し、開発のあり方そのものを変えつつあるこの革新的技術について、本セミナーでは AI コーディングエージェントの現状と AWS ソリューションを幅広く扱います。開発者から、マネジメント職まで開発に携わるすべての方を対象に、AI コーディングエージェントでなにができるのか、どうこの技術と向き合っていくべきなのか、どのように導入するのかを紹介します。また、Amazon Q Developer と Cline を具体的なツールとして取り上げて、実践的な活用法を解説します。実際に導入されているお客様からの声も交え、セキュリティやガバナンス、コスト管理など実運用に必要な知識も提供します。 実施日程 2025年5月22日 (木) 14:00～16:00 形式 オンライン 登録は こちら Dify Enterprise on AWS – 企業 AI 活用の極意 (5月23日) Dify は、プログラミングの知識がなくても生成 AI アプリケーションを構築できるプラットフォームです。Dify をエンタープライズ企業で展開するのに適した Enterprise 版も提供されており、そのライセンスが AWS Marketplace 上で購入できるようになりました 。これを記念し、企業内で生成 AI 活用を推進されている方向けのセミナーを開催します。 Dify の AWS 環境でのデプロイ方法をお伝えするとともに、実際に社内展開している企業（カカクコム様、DNP 様、三越伊勢丹様）に事例を後共有いただきます。 実施日程 2025年5月23日 (金) 15:00～16:30 (開場 14:30) 形式 物理開催 @ AWS 目黒オフィス 登録は こちら Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~ 大阪開催 (5月28日) 大阪でもAIコーディングエージェントを盛り上げたい！ 本セミナーでは、Cline と Amazon Bedrock を題材に、AI コーディングエージェントを活用した開発手法に関する体験型ワークショップ（ハンズオン）を提供します。 AI コーディングエージェントである ClineやClineにネイティブで連携可能な生成AIサービスである Amazon Bedrock をご紹介します。その後、実際に VS Code に Cline の Plugin を追加し Amazon Bedrock と連携させたハンズオン形式のワークショップを行い、爆速開発を体験します。本セッションを通じて、AI コーディングエージェント活用戦略に役立つ知見を提供します。 実施日程 2025年5月28日 (火) 19:00〜21:00 形式 物理開催 @ AWS 大阪オフィス 26F 登録は こちら まとめ これらのイベントは、生成 AI そのものや AI エージェント、Coding Agent の導入を検討されている方から、すでに活用を始めている方まで、幅広い方々に価値のある内容となっています。改めて、各イベントの詳細・お申込みは、以下よりご確認いただけます。 5/8 AI Agent 開発の 0→1 – AWS の実証事例に学ぶ、企画から組織展開までのメソッド [ 登録先 ] 5/13 Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ [ 登録先 ] 5/14 JAWS-UG Expert Online: Amazon Q Developer 特集 登録先: [ 金沢 | 磐田 | 新潟 | 福岡 | AI/ML | 佐賀 ] 5/15 GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 [ 登録先 ] 5/22 AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 [ 登録先 ] 5/23 Dify Enterprise on AWS – 企業 AI 活用の極意 [ 登録先 ] 5/28 Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~ 大阪開催 [ 登録先 ] また、6月25日〜26日には AWS Summit Japan  を開催します。AWS Summit でも多くの生成 AI セッション、ワークショップ、展示が予定されていますので、ぜひ足を運んでいただければと思います (ライブ配信もございます)。皆様の生成 AI 本格活用とその先のビジネスゴール達成の一助となれば幸いです。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 6 月 25 日 (水)、26 日 (木) に幕張メッセで開かれる AWS Summit Japan 2025 の事前登録 ができるようになりました。セッション、デモ、展示、ハッカソン、ハンズオンなどを提供し、大きな会場で参加者の熱量を肌で感じながら最新のテクノロジーを学習できます。業務に活かすためのヒントを各種コンテンツから得ることもできます。セッションなどは事前予約制となっており、ぜひ早めのご登録をよろしくお願いします。場所が遠い場合は、ホテルの予約も忘れずに :) それでは、先週の主なアップデートについて振り返っていきましょう。 2025 年 4 月 21 日週の主要なアップデート 4/21(月) Amazon Q Developer でソフトウェア開発エージェントのアップデート Visual Studio Code や JetBrains IDE の Q チャットウィンドウで「/dev」と入力することで、AI エージェントが開発を支援してくれる Amazon Q Developer のソフトウェア開発エージェント機能をアップデートしました。コード出力の品質が向上し、業界ベンチマークである SWTBench Verified で高いレベルのパフォーマンス (49%) を達成し、SWEBench Verified (66%) でもトップランクのモデルの中に位置しています。最近、 Amazon Q Developer が日本語対応 したこともあり、日本語ネイティブの方に使いやすくなっています。 Amazon SQS で IPv6 をサポート Amazon SQS の API リクエストエンドポイントで、IPv6 をサポートしました。IPv6、IPv4、またはデュアル スタックで Amazon SQS と通信できます。IPv6 を利用するアプリケーションで、SQS を利用できるようになり、利用範囲が拡大した形です。 4/22(火) Amazon Cognito がリフレッシュトークンのローテーションをサポート開始 Amazon Cognito は、ユーザープールクライアントに対する OAuth 2.0 のリフレッシュトークンのローテーションをサポートしました。リフレッシュトークンは、ユーザーが再度サインインすることなくアプリケーションが新しいアクセストークンを取得できる長期間なトークンです。リフレッシュトークンのローテーションにより、既存のリフレッシュトークンを定期的に新しいものに自動的に置き換えるように設定できるようになり、セキュリティの向上に役立ちます。 Amazon EC2 R7gd インスタンスが追加の AWS リージョンで利用可能になりました 最大 3.8 TB のローカル NVMe ベースの SSD ブロックレベルストレージを備えた R7gd インスタンスが、欧州 (ロンドン) およびアジアパシフィック (ハイデラバード、大阪) リージョンで利用可能になりました。R7gd は AWS Graviton3 プロセッサと DDR5 メモリを搭載し、AWS Nitro System 上に構築されています。高速で低レイテンシのローカルストレージへのアクセスが必要なアプリケーションに最適です。 Amazon Redshift Serverless の新しい割引価格オプションである Serverless Reservations をサポート Amazon Redshift Serverless で、新しい Serverless Reservations を提供開始しました。新しい割引価格で、コストを最大 24 % 削減できます。特定数の RPU (Redshift Processing Units) を 1 年間コミットし、支払い方法を「前払いなし」or「前払いあり」から選択いただけます。いわゆる、Savings Plans や Reserved Instance の Redshift Serverless 版という理解であながち間違っていないと思います。1 時間ごとに利用する RPU を指定してコミットします。仮に夜間に Redshift Serverless を利用しない時間がある場合でも、事前にコミットした RPU 分の料金は発生するのでご留意ください。詳細は こちらのドキュメント をご覧ください。 4/23(水) AWS アカウント管理が IAM ベースのアカウント名更新をサポート AWS Organizations を利用しているお客様向けに、アカウント名を更新できる新しい API を提供開始しました。ルートユーザーを必要とせず、アカウント内の認可された IAM プリンシパルを利用してアカウント名を更新できるようになります。ルートユーザーの日常的な利用は基本的にはおすすめしていない背景があり、IAM を利用することによるベストプラクティスの準拠がやりやすくなった形です。 Amazon Redshift が 8 つのサードパーティ SaaS アプリケーションに履歴モードのサポートを追加 Amazon Redshift で、Salesforce、ServiceNow、SAP を含む 8 つのサードパーティアプリケーションとの zero-ETL の履歴モードをサポートしました。従来、Aurora、DynamoDB、RDS for MySQL で利用できていたものが、Redshift でも利用ができるようになった形です。ETL プロセスの構築をせずに、サードパーティアプリケーションの履歴データを Redshift に持つことができ、既存のデータと連結して、包括的なデータ分析をしやすくするアップデートです。 Amazon Q Business の Microsoft 365 の Word と Outlook 向け統合機能のアップデート これまで提供していた Microsoft 365 の Word と Outlook で利用できる Amazon Q Business の統合機能をアップデートしました。「企業ナレッジへアクセス」「画像の添付」「プロンプトコンテキストウィンドウの拡張」の 3 機能が追加されました。「企業ナレッジへアクセス」により、Word や Outlook の Amazon Q Business アドイン経由で質問を投げかける際に、自社でインデックス化しているデータについて直接質問できるようになりました。組織内のコンテキストを意識した形で利用しやすくなった形です。 4/24(木) WebSocket API を提供する AWS AppSync Events でデータソース統合をサポート WebSocket API を提供する AWS AppSync Events でデータソース統合をサポートしました。この新機能により、開発者はチャネル名前空間ハンドラーに AWS Lambda 関数、Amazon DynamoDB テーブル、Amazon Aurora データベースなどのデータソースを関連付けて、AppSync Events で公開している WebSocket API に対して、特定の処理を付与できるようになりました。例えば、Lambda 関数を使用して公開されたイベントを変換およびフィルタリングしたり、DynamoDB 用の新しい AppSyncJS バッチユーティリティを使用してイベントのバッチを DynamoDB に保存したりすることで、高度なイベント処理ワークフローを作成できます。詳細は こちらのブログ を参照ください。 Amazon Connect エージェントワークスペースでサードパーティアプリケーションの機能拡張 Amazon Connect エージェントワークスペースで、発信通話の実行、コンタクトの受け入れ、転送、クリア、およびエージェントステータスの更新などを行う、サードパーティーアプリケーションとの統合機能をサポートしました。例えば、エージェントは最近の顧客とのやり取りを表示するカスタムビルドの通話履歴インターフェースから、ワンクリックで発信通話を開始できるようになりました。詳細は こちらのドキュメント をご参照ください。 4/25(金) AWS Resource Groups が 160 種類以上のリソースタイプをサポート AWS でリソースに付与した Tag などを基にして、関連したリソースを整理できる AWS Resource Groups という機能があります。今回のアップデートで、新たに 160 種類のリソースタイプをサポートしました。 こちらのドキュメント  にサポートしているリソースタイプがリストされており、多数のリソースがサポートされていることが確認できます。 AWS Resource Explorer が AWS PrivateLink をサポート AWS Resource Explorer で AWS PrivateLink をサポートするようになり、パブリックインターネットを経由せずに Amazon Virtual Private Cloud (VPC) 内で AWS リソースを検索および発見できるようになりました。AWS Resource Explorer を使用すると、組織内の AWS リージョンやアカウント全体で AWS リソースを検索および発見することができます。 Amazon Q Developer の運用調査 (プレビュー) が追加リージョンで利用可能に Amazon Q Developer の運用調査機能 (プレビュー) が、東京を含めた 11 のリージョンで新たに利用可能になりました。運用調査機能は、AWS 環境全体での調査を短時間行うのに役立ちます。Amazon Q Developer は環境内の異常を探し、調査すべき関連シグナルを表示し、潜在的な根本原因の仮説を特定し、問題をより迅速に修正するための次のステップを提案します。詳細は こちらのドキュメント をご覧ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近は、毎晩寝る前に子供と一緒に、生成 AI が作成したクイズに挑戦することが習慣になっています。 さて、直近 1 ヶ月は生成 AI のイベントが盛りだくさんです。 5 月 1 日 (木)： AWS Summit Japan 2025 生成 AI ハッカソン応援企画 ユースケース開発ワークショップ 5 月 8 日 (木）： AI Agent の効果・リスク・実装方法・組織展開を 1 日で学ぶ 5 月 22 日 (木）： AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 また、6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 の 事前登録 ができるようになっています。今年も多くの生成 AI セッションを用意しています。登録をお忘れなく！ 先日発表された「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。既に多数の応募をいただいています！ それでは、4 月 21 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「株式会社平和様、社員全員が使える生成 AI アシスタントをリリース」を公開 株式会社平和 は、遊技機の開発・製造・販売を行うメーカー企業です。社内の生産性向上に向けて生成 AI の導入を検討していたのですが「ペルソナが不明確」「社内に AI 有識者の不在」といった課題を抱えていました。そこで、多数のユースケースに対応可能かつ導入が容易な Bedrock Claude Chat をベースにカスタマイズを行うことにしました。結果、1 ヶ月で開発が完了し 500 名を超える会社全体で使える生成 AI アプリ基盤のリリースに成功しました。特に新入社員が多く使用している傾向が見られ、社員の育成面にも好影響が出ているようです。今後は、RAG やエージェントの利用も検討されているようです。 ブログ記事「Amazon Bedrock Data Automation によるコンテキスト広告向けビデオインサイトの自動抽出」を公開 Amazon Bedrock Data Automation (BDA) は、ドキュメント、イメージ、ビデオ、オーディオなどの非構造化コンテンツから構造化されたデータを抽出する機能を提供しています。本ブログでは、BDA でシーン内容の自動抽出やテキスト認識などのビデオ分析を行うことで、内容に沿った広告を動的に表示する方法を紹介しています。サンプルが github に公開されています。 ブログ記事「Pixtral Large が Amazon Bedrock で利用可能になりました」を公開 4 月 8 日 に Mistral AI の Pixtral Large 基盤モデルが Amazon Bedrock で一般提供開始となりました。本ブログでは、Pixtral Large の機能と活用例について説明しています。活用例では、ER 図から SQL コードを生成したり、組織図を与えて階層構造をJSON 形式に出力する例などが紹介されています。 ブログ記事「第3回 AWS ジャパン 生成 AI Frontier Meet Up ～学びと繋がりの場～ 開催報告」を公開 生成 AI 実用化推進プログラム の参加者や、 GENIAC の関係者などが一堂に会する「生成 AI Frontier Meetup」が、2025 年 4 月 16 日に開催されました。本記事は、そのイベントの開催レポートです。AWS スピーカーによるセッションに加え、プログラム参加者の成果発表、参加者交流会が行われ、それらの様子が記載されています。このように AWS では業界横断での連携や技術支援を通じて、企業の生成 AI 活用を後押しします。 サービスアップデート Amazon Q Developer が、最先端のソフトウェア開発エージェントをリリース Amazon Q Developer では、IDEに「/dev」と入力すると開発支援をしてくれるソフトウェア開発エージェント機能を提供しています。今回、機能がアップデートされコード生成の品質が向上しました。、業界ベンチマークである SWTBench Verified（49%）で最先端の性能を達成し、SWEBench Verified（66%）でもトップランクのモデルの一つとなりました。 Amazon Q Developer の運用調査機能（プレビュー）が追加リージョンで利用可能に Amazon Q Developer では、AWS のリソースの異常に対し、調査・改善案の提案を行う運用調査機能 (Operational Investigation) を提供しています。今回のアップデートにより、アジアパシフィック（東京）リージョン含む 11 の追加リージョンで利用可能になりました。プレビュー期間中は追加費用なしで利用できますので、ぜひお試しください。 Amazon Bedrock のインテリジェントプロンプトルーティング機能が一般提供開始 Amazon Bedrock のインテリジェントプロンプトルーティングは、プロンプト内容に応じて異なる基盤モデルに処理を振り分けることによって、応答の品質とコストを最適化する機能です。これまでプレビューでの提供でしたが、一般提供となりました。Claude、Llama、Nova の対応モデルで利用することが可能です。また、使用するモデルやルーティング基準が設定できるようになり柔軟性が向上しました。詳細は ドキュメント を参照ください。 Amazon Bedrockのプロンプト最適化機能が一般提供開始 Amazon Bedrockのプロンプト最適化機能は、基盤モデルからのより質の高い応答が得られるようにプロンプトを自動で書き換える機能です。Anthropic、Llama、Nova、DeepSeek、Mistral、Titan モデルがサポートされています。今回の一般提供開始に伴い 利用料金 も設定されていますのでご確認ください。 Amazon Bedrock Data Automation がモダリティコントロール、ハイパーリンク、より大きなドキュメントをサポート Amazon Bedrock Data Automation にて、データのモダリティ選択機能が導入され、画像、音声、動画などのデータタイプを必要に応じて指定できるようになりました。文書処理においては、埋め込まれたハイパーリンクを自動的に抽出する機能が実装されています。処理可能な文書量も拡大し、一度に最大 3,000 ページまでの文書を処理できるようになりました。これらの新機能により、マルチモーダルコンテンツをより細かく制御できるようになりました。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

こんにちは ! テクニカルインストラクターの室橋です。さて、今年もゴールデンウィークが近づいてきました。皆様、ゴールデンウィークの予定はいかがでしょうか ? お出かけされる方もされない方も、皆様が素敵なゴールデンウィークを過ごせるようお祈りしております ! (私は自宅で過ごす予定です) AWS Cloud Quest の「Data Analytics」 ロールが日本語化されました ! AWS クラウドをゲームベースで学習できるコンテンツである「 AWS Cloud Quest (以下 Cloud Quest) 」はご利用いただいておりますでしょうか ? Cloud Quest は「 ゲーム内でストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを操作しながら解いていく、RPG テイストのコンテンツ 」です。ゲーム内で使用する AWS アカウントは、各課題内で一時的に用意されるものを利用できるため、サービスの利用料金などは気にせず、学習に集中することができます。「Cloud Quest をまだ知らないよ」という方は、 こちらのブログ にて詳しくご案内しておりますので、是非ご確認ください。 Cloud Quest の中には、様々なカテゴリ (ロール) の課題が含まれているのですが、この度、 ご要望の声が多かった「 Data Analytics 」ロール (データ分析ロール) について日本語対応を行いました 。Data Analytics ロールには 23 の課題 (一部他ロールと重複する課題もあります) が用意されており、AWS Glue や Amazon Kinesis、Amazon Athena をはじめとしたサービスを組み合わせながら、「スケーラブルなデータレイク、データウェアハウス、ビッグデータ分析」などに関するソリューションを構築可能です。色々なサービスを組み合わせながら実際のアカウントでソリューション構築ができますので、課題に取り組んでいただく中で新しい発見があるかもしれません。この機会に是非チャレンジしていただければと思います。 以下は「イベント駆動型 ETL 自動化」と「ストリーミング取り込み」の課題に関する画面イメージとなります。 さて、この度日本語化された Data Analytics ロールの課題と、その中で触れられるサービス (2025年4月25日現在。今後課題やサービスについては変更される可能性もあります) について、一覧を掲載いたします。 課題名 主な利用サービス クラウドコンピューティングの基本 Amazon S3 クラウド、はじめの一歩 AWS, Amazon EC2 コンピューティングの基礎 Amazon EC2 NoSQL データベースの実装支援 Amazon DynamoDB NoSQL データベースの設計 Amazon DynamoDB, Amazon EC2 ネットワークの概念 Amazon EC2, Amazon VPC リレーショナルデータベースの実装 Amazon Relational Database Service (RDS) セキュリティのコアコンセプト AWS Identity and Access Management (IAM), Amazon Relational Database Service (RDS), Amazon EC2 サーバーレス基盤 AWS Lambda データレイク AWS Lambda, Amazon S3 データレイクへのクエリ AWS Lambda, Amazon S3, Amazon Athena ビジネスインテリジェンスダッシュボード AWS Glue, Amazon Athena, Amazon QuickSight データカタログへの入力 AWS Glue, AWS Lambda, Amazon Athena, Amazon S3 ストリーミング取り込み Amazon Athena, Amazon Kinesis, Amazon S3, Amazon SQS リアルタイムデータ処理 AWS Lambda, Amazon DynamoDB, Amazon Kinesis 毎日のバッチ抽出 AWS Glue, Amazon Athena, Amazon Relational Database Service(RDS), Amazon S3 クラウドデータウェアハウス AWS Glue, Amazon Redshift, Amazon S3 データレイクの保護 AWS Glue, AWS Lake Formation, Amazon Athena, Amazon S3 イベント駆動型サーバーレス ETL AWS Glue, Amazon Redshift, Amazon S3 文書の索引付けと検索 AWS Glue, Amazon OpenSearch Service フェデレーションクエリ AWS Glue, Amazon Athena, Amazon DynamoDB イベント駆動型 ETL 自動化 AWS Glue, AWS Lambda, AWS Step Functions, Amazon Athena, Amazon S3 データ取り込み方法 AWS Glue, AWS Lambda, Amazon Athena, Amazon Kinesis 興味のある内容が見つかりましたら、是非 Skill Builder へアクセスして、Cloud Quest の Data Analytics ロール (要サブスクリプション) にチャレンジしてみてください。データ分析ロール内の課題をすべて終了させると、AWS Cloud Quest Data Analytics ロールのデジタルバッジも入手できます。デジタルバッジで成果をアピールし、ソーシャルネットワークで共有可能です。 「いきなりサブスクリプションは敷居が高いな」と思われる方には、 無料で利用可能な Cloud Practitioner ロール もご用意しておりますので、まずはこちらを試してみてください ! Skill Builder 自体への登録も無料で、AWS アカウントをお持ちでない方でもご利用が可能です 。 また、無料で利用可能な AWS Cloud Quest: Recertify Cloud Practitioner (日本語) というコースでは、名前の通り 「再受験不要で AWS Certified Cloud Practitioner を再認定」することが可能 です。「認定の有効期間が 6 ヶ月以内である」「合計 13 個の課題をクリアする必要がある ※」という制限はありますが、試験を受けずに再認定できるという部分にメリットを感じていただける方もいらっしゃるのではないでしょうか。なお、 本トレーニングは無料ベータであり、2025 年 7 月末まで無料でご利用いただけます。 ※ うち 12 課題は Cloud Practitioner ロールと共通のため、Cloud Practitioner ロールをすべて終わらせている方は実質 1 課題終わらせれば修了 AWS Skill Builder でのコースの探し方について AWS Skill Builder では、上記の AWS Cloud Quest 以外にも、データ分析関連のコースを多数ご用意しております。フィルタ機能をご利用いただくことにより、お好みのコースが探しやすくなりますので、下記にてフィルタ機能の使い方をご案内いたします。ここでは「言語が日本語」且つ「分野がデータ分析」のコースを検索しています。 １. AWS Skill Builder へアクセスし、「フィルター」をクリック ２. 「言語」より「その他のオプションを見る」から「日本語」にチェック ３. 「分野」より「Data Analytics」にチェック ４. 右上のメニューより、コースの表示順を変更することも可能です (ここでは「新しい順」にコースを並べ替えています) これにより、データ分析関連トレーニングを検索することが可能です。条件を変更いただければ、他にも皆様のご興味に合うコースが見つかるのではないでしょうか。是非色々なコースを探してみてください。 なお、上記説明に関しては AWS Skill Builder Learner Guide という学習者用のガイドの中でも動画の形でご案内しておりますので、動画の方がお好みの方は本ガイドをご利用ください。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が 2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。基盤モデルの開発者向けと、既存モデルを活用する利用者向けの 2 つの枠組みを提供し、企業の目的や検討段階に応じた最適な支援を行っています。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2025 年 4 月 16 日に開催されました。2024 年 11 月 15 日に実施された 第 1 回 、2025 年 2 月 7 日に実施された 第 2 回 に続き、今回が第 3 回となります。本記事では、そのイベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパンの事業開発統括本部 生成 AI 推進マネージャーである梶原 貴志が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベント冒頭では、AWS ジャパンの代表執行役員社長である白幡 晶彦が、AWS の生成 AI に関する取り組みと今後の展望について挨拶しました。 AWS がこれまで日本における生成 AI 開発を支援してきた実績を紹介しました。2023 年には「 AWS LLM 開発支援プログラム 」として 17 社を支援し、2024 年には 150 社超が参加する「生成 AI 実用化推進プログラム」を実施。さらに、経済産業省・NEDO が主導する「GENIAC（Generative AI Accelerator Challenge）」でも 13 社を支援しています。 白幡は、本イベントで支援企業 5 社による事例発表や、2025 年度の新たな支援プログラム構想の発表が予定されていることを説明。最後に、参加者への感謝を述べるとともに、イベントを通じて新たな価値が生まれることへの期待を込めて挨拶を締めくくりました。 AWS スピーカーによるセッション 続いて、AWS ジャパンの Data & AI 事業統括本部 事業開発マネージャーである井形 健太郎が、生成 AI を活用したビジネス価値創出の最新動向と導入事例について解説しました。2025 年は、生成 AI から「ビジネス価値」を生む年であるとし、国内外の活用事例を紹介しました。 まずは、日本企業による 3 つの具体的な取り組みです。1 つ目のカラダノート社は、中途採用業務に生成 AI を導入し、履歴書の内容を基準と照らし合わせて自動評価する仕組みを構築。Slack との連携も含めて業務フローを見直し、作業時間を約 42％ 削減しました。また、面接判断のばらつきを平準化できたことも成果の一つとして挙げられました。 2 つ目の PURPOM MEDIA LAB 社は、 Amazon Bedrock を活用したビジネスモデルキャンバス生成機能を開発。パートナー、チャネル、収益構造など 9 項目の情報を AI が自動で整理し、新規事業の検討・検証にかかる時間を大幅に短縮しています。 3 つ目の Nint 社は、EC モールのデータ分析業務に生成 AI を活用し、非エンジニアでも使いやすい対話型の分析ツールを構築しました。Amazon Bedrock の エージェント機能 も活用し、最大で 80％ の作業効率向上を実現しています。 続いて、海外事例としてカリフォルニア大学ロサンゼルス校による卒業生向け寄付金依頼の取り組みを紹介。4 万 5,000 人の卒業生に対して、個別最適化されたメールを生成 AI で作成・送信した結果、寄付額が 132％ 増加するという成果が得られたといいます。 また、韓国企業による先進的な事例も複数紹介されました。ビジネスコラボレーションツールを展開する Toss Lab 社は、日本やアジアの組織文化に合わせた独自の検索機能や、AI による要約・分析機能を構築。コンピュータービジョン領域で事業展開する Superb AI 社は、自動運転やセキュリティ、製造などの産業向けに特化したビジョン AI プラットフォームを提供しています。さらに、IT 教育プラットフォームを展開する InfLab 社は、字幕生成や多言語吹き替え機能を実現し、言語の壁を越えて学習コンテンツを提供しています。 これらの事例を踏まえ、井形は「生成 AI の活用にはアプリケーションだけでなく、しっかりとしたデータ基盤の整備が不可欠」と指摘。ストリーミングデータや構造化・非構造化データの循環的な活用を通じて、継続的に精度と価値を高めるサイクルを構築することが重要だと述べました。 セッションの終盤では、Amazon の財務部門が RAG ( Retrieval-Augmented Generation ) を活用して、複雑な財務データの処理や意思決定支援を行っている事例も紹介されました。生成 AI が膨大な非構造化データを文脈ごとに検索・解釈し、リアルタイムで的確な提案を行う仕組みは、今後あらゆる業界において応用可能であるといいます。 最後に、ソフトウェア開発生成 AI アシスタント「 Amazon Q Developer 」が新たに日本語対応を開始したことがアナウンスされました。 プログラム参加者の成果発表 生成 AI 実用化推進プログラムに参加する 5 社の企業代表者が登壇し、AWS のサービス利用を軸にした取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長の小林 正人（写真右）と、AWS シニア スタートアップ ML ソリューションアーキテクトの針原 佳貴（写真左）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社野村総合研究所 生産革新センター AI ソリューション推進部の大河内 悠磨 氏は、業界・タスク特化型 LLM の開発と活用事例について紹介しました。野村総合研究所では、保険営業におけるコンプライアンスチェックをテーマに、小規模なオープンモデルに継続事前学習と指示チューニングを施し、専門知識に特化した LLM を構築。GPT-4o を上回る正解率を記録しました。さらに、AWS の AI チップを活用して学習・推論のコスト削減も実現しています。今後は保険に限らず、他業界や多様なタスクへの応用を視野に入れ、研究と実証を進めていくと述べました。 国土交通省 総合政策局 公共交通政策部門 モビリティサービス推進課 総括課長補佐 Project LINKS テクニカル・ディレクターの内山 裕弥 氏は、国土交通省の横断的な DX を推進する「Project LINKS」について紹介しました。本プロジェクトでは、紙や PDF など非構造化された膨大な行政データを、LLMを活用して正規化されたデータにする仕組みを開発しています。2025 年にはプロトタイプとして「LINKS Veda」を構築。文脈理解に基づくデータ抽出やノーコードでの構造化処理に加え、ハルシネーション対策やチャット検索機能も備えています。 フリー株式会社の AI プロダクトマネージャーである木佐森 慶一 氏は、クラウド会計ソフト「freee 会計」の新機能「AI クイック解説」を紹介しました。財務データの読み解きに不慣れな方でも活用できるよう、LLM を用いて自然言語でわかりやすく解説する仕組みです。ジュニア層の場合は 10 時間以上、シニア層でも数時間の作業負荷軽減が期待できるといいます。近く実装予定のアップデートにより、さらに進化した機能が披露される予定です。 株式会社 NTT データ テクノロジーコンサルティング事業部の鯨田 連也 氏は、 第1回 Meetup がきっかけとなった、株式会社 昭栄美術と協業して取り組んだクリエイティブ業務支援における AI エージェント活用の事例を紹介しました。Web 検索、デザイン案生成、画像生成といった機能を担う複数のエージェントを、スーパーバイザーエージェントが統括・連携する構成を採用。展示会ブースデザインにおける情報収集やアイデア創出の属人化、手戻りの多さといった課題に対応し、大幅な効率化を実現しました。今後は機能改善を進め、幅広いお客様の業務への適用を目指しています。 株式会社エイチ・アイ・エス DX 推進本部 サービスプラットフォーム企画部の李 章圭 氏は、旅行相談窓口における業務効率化プロジェクトについて紹介しました。本事例では、英語で記載された販売条件書の読み取り業務を AI により代替することで、事務作業の負荷を軽減し、顧客との対話時間を増やすことを目指しました。Amazon Bedrock を用いた PoC を経て、要約・構造化処理の仕組みを構築。試験導入を経て、現在は関東全店舗に展開しており、5 月以降は全国 150 店舗への本格導入を予定しています。 クロージング 各セッションの終了後、AWS ジャパン Data&AI 事業開発部の瀧川 大爾がクロージングを行いました。生成 AI の社会実装を推進する取り組みとして、2025 年度も「生成 AI 実用化推進プログラム」を継続実施することを発表しました。昨年度に続き、企業や自治体、スタートアップなど、さまざまな組織を対象に、生成 AI の活用支援を行う予定です。 2025 年度の「生成 AI 実用化推進プログラム」では、企業の課題やフェーズに応じて選べる 3 種類のコースが用意されています。 1 つ目の「モデルカスタマイズコース」は、既存モデルより高精度な応答や目的特化型の生成を求める方向けで、計算リソースの調達支援や実装・事業化までの伴走支援を提供します。 2 つ目の「モデル活用コース」は、公開モデルを活用して課題解決を目指す方向けで、事例共有を起点に、ユースケース特定から実用化までを一貫して支援します。 3 つ目の「戦略プランニングコース」は、生成 AI をビジネスの中核に据えたい企業向けで、AWS とパートナー企業が連携し、業務コンサルテーションから導入支援までを包括的にサポートします。 なお、プログラム期間中には成果共有やネットワーキングを目的とした交流イベントも実施される予定です。参加される企業様は、「生成 AI 実用化推進プログラム」ページ内の Web フォーム（「登録する」）からお申込みください。 参加者交流会の様子 交流会では、各セッションで紹介された実践事例をもとに、登壇者と参加者が垣根なく意見を交わす姿が多く見られました。生成AIの導入における具体的な工夫や課題、今後の展望について活発な対話が繰り広げられ、会場は終始熱気に包まれていました。業種や立場を越えたネットワーキングも進み、現場での学びを共有しながら、今後の連携や共創のきっかけを築く機会となりました。こうしたオープンな対話の積み重ねが、生成AIのさらなる社会実装を後押ししていくことが期待されます。 また、生成 AI 領域で先進的な取り組みを進めるカラクリ株式会社 (写真上) とストックマーク株式会社 (写真下)が、会場内に開発者ブースを出展されていました。自社で構築したモデルやプロダクトに関する技術的な知見を共有し、多くの参加者と活発な意見交換を行っていました。 おわりに 本イベントでは、登壇者による実践的な知見の共有に加え、参加者同士の意見交換やネットワーキングが随所で行われ、会場全体に前向きな熱気が広がっていました。生成 AI の社会実装に向けた最新の取り組みや、具体的な業務への応用例が紹介され、実務に直結する学びの多い時間となりました。AWS ジャパンは、今後も業界横断での連携や技術支援を通じて、企業の生成 AI 活用を後押しし、持続的な実用化に貢献していきます。

この記事は Pixtral Large is now available in Amazon Bedrock (記事公開日: 2025年4月10日) を翻訳したものです。 Mistral AI の Pixtral Large 基盤モデル (FM) が Amazon Bedrock で一般提供開始となったことをお知らせします。この発表により、Mistral の最先端マルチモーダルモデルを活用して、AWS 上で生成 AI のアイデアを構築、実験、そして責任を持って拡張することが可能になります。AWS は Pixtral Large を完全マネージド型サーバーレスモデルとして提供する初めての主要クラウドプロバイダーです。 この記事では、Pixtral Large の機能とその活用例について説明します。 Pixtral Large の概要 Pixtral Large は、Mistral AI によって開発された 1240 億パラメータを持つ高度なマルチモーダルモデルです。このモデルは 1230 億パラメータの強力なマルチモーダルデコーダーと、特殊な 10 億パラメータのビジョンエンコーダーを組み合わせています。複雑な視覚的およびテキストタスクをシームレスに処理しながら、前身の Mistral Large 2 の優れた言語処理能力を継承しています。 Pixtral Large の特筆すべき機能は、128,000 トークンの広大なコンテキストウィンドウであり、大量のテキストデータと共に複数の画像を同時に処理することができます。この能力により、文書、詳細なチャート、グラフ、自然画像の分析において特に効果的であり、幅広い実用的なアプリケーションに対応しています。 Pixtral Large の主な機能は以下の通りです： 多言語テキスト分析 – Pixtral Large は画像や文書から複数言語にわたる書かれた情報を正確に解釈・抽出します。これは特に、レシートや請求書の自動処理などのタスクに有益で、計算やコンテキストを考慮した評価を実行し、経費追跡や財務分析などのプロセスを効率化します。 チャートや 可視化されたデータ の解釈 – このモデルは複雑な視覚的データ表現を理解する優れた能力を示します。可視化されたグラフ内のトレンド、異常、主要なデータポイントを容易に識別できます。例えば、Pixtral Large はトレーニング損失曲線やパフォーマンス指標内の不規則性や洞察力のあるトレンドを特定するのに非常に効果的で、データ駆動型の意思決定の精度を向上させます。 一般的な視覚分析とコンテキスト理解 – Pixtral Large はスクリーンショットや写真などの一般的な視覚データを分析し、微妙なニュアンスまで読み取り、画像内容に基づくクエリに効果的に応答する能力に長けています。この機能は、プレゼンテーション内の視覚的コンテキストの説明からコンテンツモデレーションの自動化やコンテキスト画像検索まで、さまざまなシナリオをサポートでき、その使用可能性を大幅に広げています。 追加のモデル詳細は以下の通りです： クロスリージョン推論は以下のリージョンで利用可能です： us-east-2 us-west-2 us-east-1 eu-west-1 eu-west-3 eu-north-1 eu-central-1 モデル ID: us または eu 、その後に mistral.pixtral-large-2502-v1:0 コンテキストウィンドウ: 128,000 Amazon Bedrock で Pixtral Large を使用する Mistral AI モデルを初めて使用する場合は、 Amazon Bedrock コンソール でモデルアクセスをリクエストできます。詳細については、 Amazon Bedrock 基盤モデルへのアクセス をご覧ください。 Amazon Bedrock コンソールで Pixtral Large をテストするには、ナビゲーションペインの Playgrounds の下にある Text または Chat を選択します。次に、 Select model を選択し、カテゴリとして Mistral を、モデルとして Pixtral Large を選択します。 View API を選択することで、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK のコード例を使用してモデルにアクセスすることもできます。以下のコードのように、 mistral.mistral-large-2407-v1:0 などのモデル ID を使用できます： $ aws bedrock-runtime invoke-model \ --model-id mistral.pixtral-large-2502-v1:0 \ --body "{\"prompt\":\"<s>[INST] this is where you place your input text [/INST]\", \"max_tokens\":200, \"temperature\":0.5, \"top_p\":0.9, \"top_k\":50}" \ --cli-binary-format raw-in-base64-out \ --region eu-north-1 \ invoke-model-output.txt 以下のセクションでは、Pixtral Large の機能について詳しく説明します。 Pixtral Large のユースケース このセクションでは、サンプルプロンプトを使用して Pixtral Large のユースケース例を紹介します。Pixtral Large は Mistral Large 2 をベースにしているため、ネイティブ JSON 出力モードを含んでいます。この機能により、開発者はモデルのレスポンスを構造化された読みやすい形式で受け取ることができ、さまざまなアプリケーションやシステムにシームレスに統合できます。JSON は広く使用されているデータ交換標準であるため、この機能によりモデル出力の処理プロセスが効率化され、異なる産業やユースケースにわたる開発者にとってよりアクセスしやすく実用的になっています。Converse API を使用した JSON の生成の詳細については、 Amazon Bedrock Converse API を使用した JSON の生成 を参照してください。 さらに、Pixtral Large は Converse API と ツールの使用 をサポートしています。Amazon Bedrock API を使用することで、送信するメッセージへのレスポンス生成をサポートするツールへのアクセス権をモデルに付与できます。 データベースエンティティ関係図からの SQL コードの生成 エンティティ関係 (ER) 図は、データベース設計で使用される視覚的表現で、エンティティとその属性の関係を示します。これは概念的モデリングの重要なツールであり、開発者やアナリストがデータベース内のデータ構造を理解し伝えるのに役立ちます。 この例では、エンティティとその関係を作成するための PostgreSQL 互換の SQL CREATE TABLE ステートメントを生成するモデルの能力をテストします。 以下のプロンプトを使用します： prompt = """ You are a database designer. You have created an ER diagram. You need to generate PostgreSQL compatible SQL statements to create the tables" """ 日本語訳（翻訳者追記） prompt = """ あなたはデータベース設計者です。ERダイアグラムを作成しました。このERダイアグラムに基づいてPostgreSQLと互換性のあるテーブル作成用のSQLステートメントを生成する必要があります。" """ 以下の ER 図を入力します。 モデルの応答は以下の通りです： Sure! Below are the SQL statements to create the tables based on the provided ER diagram for a PostgreSQL database. -- Create the Airport table CREATE TABLE Airport ( Airport_ID SERIAL PRIMARY KEY, AirportCity VARCHAR(255), AirportCountry VARCHAR(255) ); -- Create the Calendar table CREATE TABLE Calendar ( Day_Date DATE PRIMARY KEY, Business_Day_YN BOOLEAN ); -- Create the Flight_Details table CREATE TABLE Flight_Details ( Flight_ID SERIAL PRIMARY KEY, Source_Airport_ID INT REFERENCES Airport(Airport_ID), Destination_Airport_ID INT REFERENCES Airport(Airport_ID), Departure_Date_Time TIMESTAMP, Arrival_Date_Time TIMESTAMP, Airplane_Type VARCHAR(255) ); -- Create the Travel_Class table CREATE TABLE Travel_Class ( Travel_Class_ID SERIAL PRIMARY KEY, Travel_Class_Name VARCHAR(255), Travel_Class_Capacity INT ); -- Create the Seat_Details table CREATE TABLE Seat_Details ( Seat_ID SERIAL PRIMARY KEY, Travel_Class_ID INT REFERENCES Travel_Class(Travel_Class_ID), Flight_ID INT REFERENCES Flight_Details(Flight_ID) ); -- Create the Flight_Cost table CREATE TABLE Flight_Cost ( Seat_ID INT REFERENCES Seat_Details(Seat_ID), Valid_From_Date DATE, Cost DECIMAL(10, 2), Valid_To_Date DATE, PRIMARY KEY (Seat_ID, Valid_From_Date) ); -- Create the Flight_Service table CREATE TABLE Flight_Service ( Service_ID SERIAL PRIMARY KEY, Service_Name VARCHAR(255) ); -- Create the Service_Offering table CREATE TABLE Service_Offering ( Travel_Class_ID INT REFERENCES Travel_Class(Travel_Class_ID), Service_ID INT REFERENCES Flight_Service(Service_ID), Offered_YN BOOLEAN, From_Date DATE, To_Date DATE, PRIMARY KEY (Travel_Class_ID, Service_ID) ); -- Create the Passenger table CREATE TABLE Passenger ( Passenger_ID SERIAL PRIMARY KEY, P_FirstName VARCHAR(255), P_LastName VARCHAR(255), P_Email VARCHAR(255), P_PhoneNumber VARCHAR(255), P_Address VARCHAR(255), P_City VARCHAR(255), P_State VARCHAR(255), P_Zipcode VARCHAR(255), P_Country VARCHAR(255) ); -- Create the Reservation table CREATE TABLE Reservation ( Reservation_ID SERIAL PRIMARY KEY, Passenger_ID INT REFERENCES Passenger(Passenger_ID), Seat_ID INT REFERENCES Seat_Details(Seat_ID), Date_Of_Reservation DATE ); -- Create the Payment_Status table CREATE TABLE Payment_Status ( Payment_ID SERIAL PRIMARY KEY, Payment_Status_YN BOOLEAN, Payment_Due_Date DATE, Payment_Amount DECIMAL(10, 2), Reservation_ID INT REFERENCES Reservation(Reservation_ID) ); These SQL statements will create the tables as per the ER diagram you provided. Make sure to run these statements in the order they are listed to ensure that foreign key constraints are satisfied. 日本語訳（翻訳者追記） もちろんです！下記は提供された ER ダイヤグラムに基づいて PostgreSQL データベース用のテーブルを作成するための SQL ステートメントです。 -- 省略-- これらの SQL ステートメントは提供された ER ダイヤグラムに沿ってテーブルを作成します。外部キー制約が満たされるよう、これらの SQL ステートメントは必ず記載された順序で実行するようにしてください。 組織階層の構造化テキストへの変換 Pixtral Large は組織構造を理解し、構造化された出力を生成する能力を持っています。組織図でテストしてみましょう。 以下のプロンプトを使用します： prompt = """ Extract organization hierarchy from the given org structure. provide response in a structured json format with below: - role - name - reporting_manager """ 日本語訳（翻訳者追記） prompt = """ 与えられた組織図から階層構造を抽出してください。以下の項目を含む JSON 形式でレスポンスを提供してください： - 役職 - 氏名 - 報告先の管理者 """ 以下の組織図を入力します。 モデルの応答は以下の通りです： Here is the organization hierarchy extracted from the given org structure in a structured JSON format: [ { "role": "President", "name": "John Smith", "reporting_manager": null }, { "role": "VP Marketing", "name": "Susan Jones", "reporting_manager": "John Smith" }, { "role": "VP Sales", "name": "Rachel Parker", "reporting_manager": "John Smith" }, { "role": "VP Production", "name": "Tom Allen", "reporting_manager": "John Smith" }, { "role": "Manager", "name": "Alice Johnson", "reporting_manager": "Susan Jones" }, { "role": "Manager", "name": "Tim Moore", "reporting_manager": "Susan Jones" }, { "role": "Manager", "name": "Michael Gross", "reporting_manager": "Rachel Parker" }, { "role": "Manager", "name": "Kim Dole", "reporting_manager": "Rachel Parker" }, { "role": "Manager", "name": "Kathy Roberts", "reporting_manager": "Tom Allen" }, { "role": "Manager", "name": "Betsy Foster", "reporting_manager": "Tom Allen" } ] 日本語訳（翻訳者追記） こちらが入力された組織図から抽出した、JSON 形式の階層構造です。 -- 省略 -- チャート理解と推論 Pixtral Large はチャートやグラフを理解し、推論する能力を持っています。世界各国のオートバイ所有率の可視化データを使って Pixtral Large をテストしてみましょう。 以下のプロンプトを使用します： prompt = """Examine this visualization: 1. First, describe what this visualization represents: - What information is being shown? - How is the data displayed? - What do the different components represent? - What does the size variation indicate? 2. Analyze specific patterns: - Which region shows the highest proportion of the first category? - Which region shows the highest proportion of the second category? - Where do you observe the largest total values? - Which areas show the most balanced distribution? 3. Compare regional trends: - How do the proportions differ between continents? - What patterns emerge between different hemispheres? - Are there clear differences between different economic zones? 4. Identify interesting outliers: - Which regions stand out from their neighbors? - Can you identify any unexpected patterns? - Where do you notice significant data variations? 5. Consider geographical and demographic factors: - How might local conditions influence these patterns? - What socioeconomic factors might explain the variations? - Can you identify any correlation between size and proportions? 6. Make comparisons between: - Different geographical zones - Various population densities - Different economic development levels""" 日本語訳（翻訳者追記） prompt = """この画像を調査してください： 1. まず、この可視化されたデータが何を表しているか説明してください： - どのような情報が表示されていますか？ - データはどのように表示されていますか？ - 異なるコンポーネントは何を表していますか？ - サイズの違いは何を示していますか？ 2. 特定のパターンを分析してください： - どの地域が最初のカテゴリの最も高い割合を示していますか？ - どの地域が2番目のカテゴリの最も高い割合を示していますか？ - どこで最大の合計値が観察されますか？ - どの地域が最もバランスの取れた分布を示していますか？ 3. 地域的傾向を比較してください： - 大陸間で割合はどのように異なりますか？ - 異なる半球間でどのようなパターンの違いが現れますか？ - 異なる経済圏間に明確な違いはありますか？ 4. 特徴的な外れ値を特定してください： - どの地域が周囲と比べて際立っていますか？ - 予期しないパターンを特定できますか？ - どこで重要なデータの変動に気づきますか？ 5. 地理的および人口統計的要因を考慮してください： - 地域の状況がこれらのパターンにどのように影響する可能性がありますか？ - これらの違いを説明する社会経済的要因は何が考えられますか？ - サイズと割合の間に相関関係を特定できますか？ 6. 以下の間で比較を行ってください： - 異なる地理的ゾーン - さまざまな人口密度 - 異なる経済発展レベル""" 以下の画像を入力します。 By Dennis Bratland – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=15186498 モデルの応答は以下の通りです： Description of the Visualization: Information Shown: The visualization presents data on the population (in millions) and the proportion of vehicles (cars and motorcycles) across various regions worldwide. Display Method: The data is displayed using pie charts overlaid on a world map. The size of each pie chart corresponds to the population of the region, with larger pies indicating larger populations. Components: Pie Charts: Each pie chart is divided into two segments representing the proportion of cars (light blue) and motorcycles (dark blue). Size Variation: The size of the pie charts indicates the total population of the region, with larger pies representing higher populations. Specific Patterns: Highest Proportion of Cars: Regions like the United States and parts of Europe show a higher proportion of cars. Highest Proportion of Motorcycles: Southeast Asian countries like Indonesia and Vietnam show a higher proportion of motorcycles. Largest Total Values: Large pie charts are observed in highly populated regions like India, China, and parts of Southeast Asia. Most Balanced Distribution: Some regions in Europe and South America show a more balanced distribution of cars and motorcycles. Regional Trends: Continental Differences: North America: Predominantly cars. Europe: A mix with a slight preference for cars. Africa: Generally lower total values with varied proportions. Asia: High population with a significant proportion of motorcycles in Southeast Asia. Hemispheric Patterns: The Northern Hemisphere has more densely populated regions with varied vehicle proportions, while the Southern Hemisphere shows lower population densities and more balanced distributions. Economic Zones: Developed regions tend to have higher car proportions, while developing regions, especially in Asia, show higher motorcycle usage. Interesting Outliers: Indonesia: Stands out with a very high proportion of motorcycles compared to neighboring regions. United States: Shows a predominantly high proportion of cars, distinct from other regions. Unexpected Patterns: Some smaller African countries show unexpectedly high proportions of motorcycles despite lower populations. Geographical and Demographic Factors: Local Conditions: Urbanization and infrastructure development influence vehicle preferences. Socioeconomic Factors: Economic status and affordability play significant roles in vehicle choices. Correlation: Larger populations in developing regions often correlate with higher motorcycle usage due to affordability and convenience. Comparisons: Geographical Zones: Urban areas in developed countries show higher car usage, while rural and developing regions favor motorcycles. Population Densities: Highly populated areas in Asia show a preference for motorcycles due to traffic congestion and affordability. Economic Development: Developed economies have higher car proportions, while developing economies rely more on motorcycles. 日本語訳（翻訳者追記） 可視化されたデータの説明： 表示されている情報： この可視化されたデータは世界各地の人口（百万人単位）と車両（自動車とオートバイ）の割合に関するデータを示しています。 表示方法： データは世界地図上に円グラフでオーバーレイ表示されています。各円グラフのサイズはその地域の人口に対応し、より大きな円はより大きな人口を示しています。 構成要素： 円グラフ： 各円グラフは自動車（水色）とオートバイ（濃紺）の割合を表す2つのセグメントに分割されています。 サイズの変化： 円グラフのサイズはその地域の総人口を示し、より大きな円はより高い人口を表しています。 特定のパターン： 自動車の最高割合： アメリカ合衆国やヨーロッパの一部などの地域では自動車の割合が高くなっています。 オートバイの最高割合： インドネシアやベトナムなどの東南アジア諸国ではオートバイの割合が高くなっています。 最大の総数： インド、中国、東南アジアの一部など、人口の多い地域で大きな円グラフが観察されます。 最もバランスの取れた分布： ヨーロッパや南米の一部の地域では自動車とオートバイのより均衡のとれた分布を示しています。 地域的傾向： 大陸間の違い： 北米： 主に自動車が中心。 ヨーロッパ： 自動車をやや好む混合。 アフリカ： 一般的に総数が低く、さまざまな割合。 アジア： 高い人口で、東南アジアでは著しいオートバイの割合。 半球間のパターン： 北半球には多様な車両割合を持つ人口密度の高い地域があり、南半球では人口密度が低く、よりバランスの取れた分布を示しています。 経済圏： 先進地域では自動車の割合が高い傾向があり、特にアジアの発展途上地域ではオートバイの使用率が高くなっています。 特徴的な外れ値： インドネシア： 近隣地域と比較して非常に高いオートバイの割合が目立っています。 アメリカ合衆国： 他の地域とは異なり、圧倒的に高い自動車の割合を示しています。 予想外のパターン： 一部のアフリカの小国では、人口が少ないにもかかわらず、予想外に高いオートバイの割合を示しています。 地理的・人口統計学的要因： 地域条件： 都市化とインフラ開発が車両選択に影響します。 社会経済的要因： 経済状況と手頃な価格が車両選択において重要な役割を果たします。 相関関係： 発展途上地域の大規模な人口は、手頃な価格と利便性から、多くの場合、オートバイの高い使用率と相関しています。 比較： 地理的ゾーン： 先進国の都市部では自動車の使用率が高く、農村部や発展途上地域ではオートバイが好まれています。 人口密度： アジアの人口密集地域では、交通渋滞と手頃な価格のため、オートバイが好まれています。 経済発展： 先進経済国では自動車の割合が高く、発展途上経済国ではオートバイへの依存度が高くなっています。 まとめ この記事では、Amazon Bedrock での Pixtral Large モデルの使用開始方法を紹介しました。Pixtral Large マルチモーダルモデルを使用すると、文書理解、論理的推論、手書き認識、画像比較、エンティティ抽出、スキャンした画像から構造化データの抽出、キャプション生成など、さまざまなユースケースに対応できます。これらの機能は、eコマース（小売）、マーケティング、金融サービスなど、多数の企業アプリケーション全体の生産性を向上させることができます。 Mistral AI の Pixtral Large FM が Amazon Bedrock で利用可能になりました。Amazon Bedrock で Pixtral Large の使用を開始するには、 Amazon Bedrock コンソール にアクセスしてください。 さらに詳しく知りたい方は、 Mistral-on-AWS リポジトリ をご覧ください。Amazon Bedrock で利用可能な Mistral AI モデルについて詳しくは、 Mistral AI モデルが Amazon Bedrock で利用可能に を参照してください。 作者情報  　　　　　　 Deepesh Dhapola は AWS インドのシニアソリューションアーキテクトで、金融サービスおよびフィンテッククライアントに対する AWS クラウド上のアプリケーションの最適化やスケーリングの支援を専門としています。生成 AI、AI エージェント、Model Context Protocol (MCP) などのトレンド AI テクノロジーに強く焦点を当て、機械学習の専門知識を活かして革新的でスケーラブルかつ安全なソリューションを設計しています。AI の変革的な可能性に情熱を持ち、AWS 顧客の効率性とイノベーションを推進するため、最先端の進歩を積極的に探求しています。仕事の外では、家族との時間を大切にし、多様な料理創作を楽しんでいます。 Andre Boaventura は AWS のプリンシパル AI/ML ソリューションアーキテクトで、生成 AI およびスケーラブルな機械学習ソリューションを専門としています。ハイテクソフトウェア業界で 25 年以上の経験があり、Amazon Bedrock、Amazon SageMaker、Amazon Q などの AWS サービスを使用した AI アプリケーションの設計と展開に深い専門知識を持っています。Andre は、ビジネス価値を推進する最先端の AI/ML ソリューションを設計および実装するため、グローバルシステムインテグレーター (GSI) や様々な業界の顧客と緊密に連携しています。 Preston Tuggle は AWS のサードパーティモデルプロバイダーチームに所属するシニアスペシャリストソリューションアーキテクトです。彼は Amazon Bedrock と Amazon SageMaker にわたるモデルプロバイダーと協力し、技術的なスケーリング施策と顧客とのエンゲージメントを通じて、市場投入戦略を加速させることに焦点を当てています。 Shane Rai は AWS ワールドワイドスペシャリスト組織 (WWSO) のプリンシパル GenAI スペシャリストです。彼はトップティアの基盤モデルプロバイダーからのモデル提供を含む、AWS の幅広いクラウドベースの AI/ML サービスを使用して、業界を超えた顧客の最も差し迫ったイノベーティブなビジネスニーズを解決するために働いています。 Ankit Agarwal は Amazon Bedrock のシニアテクニカルプロダクトマネージャーで、顧客のニーズと基盤モデルプロバイダーの交差点で活動しています。彼は Amazon Bedrock サーバーレスへの最先端モデルのオンボーディングを主導し、プラットフォームの機能を強化するコア機能の開発を推進しています。 Niithiyn Vijeaswaran は AWS のサードパーティモデルサイエンスチームに所属する生成 AI スペシャリストソリューションアーキテクトです。彼の専門分野は AWS AI アクセラレーター（AWS Neuron）です。コンピュータサイエンスとバイオインフォマティクスの学士号を持っています。 Aris Tsakpinis は Amazon Bedrock のオープンソースモデルと広範な生成 AI オープンソースエコシステムに焦点を当てた生成 AI のスペシャリストソリューションアーキテクトです。彼は専門的な役割と並行して、レーゲンスブルク大学で機械学習エンジニアリングの博士号を取得中であり、その研究は科学分野における応用自然言語処理に焦点を当てています。 本記事の翻訳はソリューションアーキテクトの伊勢田氷琴が担当しました。

4 月 14 日週は、技術リーダーや業界リーダーたちから学び、AWS エキスパートや志を同じくする人たちと出会う機会を提供する世界的な Amazon Web Services (AWS) イベントの 1 つ、 AWS Summit Amsterdam が開催されました。特に、ほとんどの AWS Summit では展示会場内に開発者ラウンジとコミュニティラウンジが用意されています。 Thembile Martis が撮影した AWS Summit Amsterdam 2025 の写真 ここでは、開発者向けの 生成 AI サービスを体験したり、AWS コミュニティが準備した開発者セッションに参加したりできます。また、 Amazon Q Developer 、 AWS Skill Builder 、 AWS re:Post 、開発者向けの AWS コミュニティ を使用するための AWS ビルダー ID にサインアップした後で特別なプレゼントを受け取ることができる賞品ルーレットを回すこともできます。 スケジュールを確認して、お近くの都市で開催される AWS Summit にご参加ください。次の AWS Summit は、 バンコク (4 月 29 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)、 バンガロール (5 月 7～8 日)、 香港 (5 月 8 日)、 ソウル (5 月 14～15 日)、 ドバイ (5 月 21 日)、 テル・アビブ (5 月 28 日)、 シンガポール (5 月 29 日)、 ストックホルム (6 月 4 日)、 シドニー (6 月 4～5 日)、 ハンブルク (6 月 5 日)、 ワシントン D.C. (6 月 10～11 日)、 マドリード (6 月 11 日)、 ミラノ (6 月 18 日)、 上海 (6 月 19～20 日)、 ムンバイ (6 月 19 日)、および 東京 (6 月 25～26 日) で開催される予定です。 4 月 14 日週のリリース 私が注目したいくつかのリリースをご紹介します。 GitLab Duo with Amazon Q – ソフトウェア開発用の高度なエージェント機能が組み込まれた GitLab Duo with Amazon Q が、Self-Managed Ultimate のお客様を対象に一般提供されました。GitLab Duo with Amazon Q は、Java モダナイゼーション、強化された品質保証、コードレビュー最適化も GitLab の エンタープライズ DevSecOps プラットフォームで直接サポートします。詳細については、 こちらの DevOps ブログ記事 をお読みいだたくか、 Amazon Q Developer 統合ページ をご覧ください。 欧州 (フランクフルト) リージョンでの Amazon Q Developer – Amazon Q Developer Pro ティアのお客様は、欧州 (フランクフルト) リージョン内にデータを保存するために AWS マネジメントコンソールと統合開発環境 (IDE) で Amazon Q Developer を使用し、設定できるようになりました。推論が欧州連合 (EU) リージョン内で実行されるため、データの保存場所と転送先の選択肢が広がります。詳細については、 こちらのブログ記事 をお読みください。 AWS Control Tower での 223 個の新規 AWS Config ルール – セキュリティ、コスト、耐久性、オペレーションなどのさまざまなユースケースのために、AWS Control Tower が Control Catalog でさらに 223 個のマネージド Config ルールをサポートするようになりました。このリリースにより、これらの追加のルールを AWS Control Tower から直接検索、検出、有効化、管理し、マルチアカウント環境向けにより多くのユースケースを管理できるようになります。詳細については、「 AWS Control Tower ユーザーガイド 」をご覧ください。 Amazon CloudFront エニーキャスト静的 IP による apex ドメインのサポート – CloudFront でルートドメイン ( example.com など) を簡単に使用できます。この新機能は、これまで 21 個あった固定 IP アドレスを 3 個にすることで DNS 管理を簡素化するため、CloudFront ディストリビューションでの apex ドメインの設定と管理が容易になります。詳細については、詳しい説明と実装ガイダンスが記載されている「 CloudFront 開発者ガイド 」をご覧ください。 AWS Lambda@Edge の高度なロギングコントロール – この機能は、Lambda 関数ログがエッジで取得、処理、使用される方法を改善します。この機能強化はロギングデータのより細かな制御を可能にするため、アプリケーション動作を簡単に監視して問題を迅速に解決できるようになります。詳細については、 こちらのコンピューティングブログ記事 、「 Lambda 開発者ガイド 」、または「 CloudFront 開発者ガイド 」を参照してください。 ダカール (セネガル) での新しい AWS Wavelength Zone – Orange の子会社である Sonatel とのパートナーシップによって実現されたサブサハラ・アフリカ地域初の Wavelength Zone により、独立系ソフトウェアベンダー (ISV)、企業、および開発者は、AWS のインフラストラクチャとサービスを使用して、データレジデンシー、低レイテンシー、およびレジリエンシー要件を伴うアプリケーションをサポートできるようになりました。AWS Wavelength は、7 社の電気通信会社とのパートナーシップにより、世界中 31 の都市で提供されています。 AWS Wavelength の詳細を確認して、 今すぐ使用を開始 しましょう。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 Amazon EKS Auto Mode Workshop – EKS Auto Mode Workshop は、Auto Mode を使用して Amazon EKS にワークロードをデプロイし、Auto Mode が Kubernetes アプリケーションの実行時における運用上のオーバーヘッドを合理化する方法を理解するために必要な知識を提供します。 AWS Well-Architected 生成 AI レンズ – AWS Well-Architected フレームワーク は、AWS で生成 AI ワークロードを設計して運用するためのアーキテクチャベストプラクティスを提供します。この Well-Architected フレームワークを使用する 生成 AI レンズ は、生成 AI ワークロードの Well-Architected フレームワークレビューを実行する手順を説明します。 生成 AI のための AWS Security Reference Architecture (SRA) コード例 – 生成 AI ワークロードをセキュア化するための新しい SRA コード例 には、セキュアなモデル推論と検索拡張生成 (RAG) の実装に焦点を当てた 2 つの包括的な機能が含まれており、AWS 生成 AI サービスを使用した幅広いセキュリティベストプラクティスを取り上げています。 community.aws より community.aws から、私が個人的に気に入っている記事をご紹介します。 Introducing the AWS Guidance for Multi-Provider LLM Access (著者: Todd Fortier) Architecting Secure MCP Solutions on AWS: From Threats to Mitigations (著者: Roberto Catalano) Voice-Controlled Humanoid Robots Using Amazon Nova Sonic and AWS IoT (著者: Cyrus Wong 氏) Vibe Coding in Practice: Building a Classic Platform Jumping Game with Amazon Q Developer CLI (著者: Haowen Huang) 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Inforce – カレンダーの 6 月 16～18 日には、ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce を書き込んでおきましょう。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。イベントの最新情報に今すぐサブスクライブしてください! AWS パートナーイベント – クラウドジャーニーを始めたばかりであるか、新しいビジネス上の課題を解決したいと考えているかにかかわらず、誰もがインスピレーションと学びを得られるさまざまな AWS パートナーイベントを見つけましょう。 AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主催のカンファレンスにご参加ください。次回の Community Day は、 イスタンブール (トルコ) (4 月 25 日)、 プラハ (チェコ共和国) (4 月 25 日)、 エレバン (アルメニア) (5 月 24 日)、 チューリッヒ (スイス) (5 月 25 日)、 バンガロール (インド) (5 月 25 日) で開催される予定です。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 4 月 21 日週のニュースは以上です。4 月 28 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)