本ブログは 2025 年 8 月 29 日に公開された AWS Blog “ Amazon disrupts watering hole campaign by Russia’s APT29 ” を翻訳したものです。 Amazon の脅威インテリジェンスチームは、ロシアの対外情報庁 (SVR) に関連する脅威アクター APT29 (Midnight Blizzard としても知られる) による水飲み場型攻撃キャンペーンを特定し、阻止しました。私たちの調査により、標的を選ばない水飲み場型攻撃キャンペーンが明らかになりました。このキャンペーンでは、侵害されたウェブサイトを利用して訪問者を悪意のあるインフラストラクチャにリダイレクトし、Microsoft のデバイスコード認証フローを通じて攻撃者が制御するデバイスを承認するようユーザーを騙していました。この標的を選ばないアプローチは、APT29 が情報収集活動においてより広範な対象を捕捉するために、その運用を拡大する継続的な進化を示しています。 APT29 の進化する戦術 このキャンペーンは、私たちが以前 APT29 から観測した活動パターンと一致しています。2024 年 10 月、 Amazon は APT29 による AWS を偽装したドメイン使用の試み を阻止しました。これは攻撃者が制御するリソースを指す Remote Desktop Protocol ファイルでユーザーをフィッシングするものでした。また、2025 年 6 月には、Google の Threat Intelligence Group が、アプリケーション固有のパスワード (ASP) を使用してロシアの学者や批評家を標的としたAPT29 のフィッシングキャンペーンについて 報告 しました。現在のキャンペーンは、認証情報収集と情報収集への継続的な焦点と、技術的アプローチの改良を示しており、APT29 の工作手法が以下の点で進化していることを示しています 正規のウェブサイトを侵害し、最初に難読化された JavaScript を注入する 攻撃が阻止されたら迅速にインフラストラクチャを適応させる 新しいインフラストラクチャでは、JavaScript リダイレクトからサーバーサイドリダイレクトへの調整を行う 技術的詳細 Amazon は APT29 のインフラストラクチャ向けに作成した分析を通じてこのアクティビティを特定し、攻撃者が制御するドメイン名の発見につながりました。さらなる調査により、Amazon は攻撃者が様々な正規のウェブサイトを侵害し、訪問者の約 10% を攻撃者が制御するドメインにリダイレクトする JavaScript を注入していたことを特定しました。findcloudflare[.]com などのこれらのドメインは、正規に見えるように Cloudflare の検証ページを模倣していました。このキャンペーンの最終的な標的は Microsoft のデバイスコード認証フローでした。AWS システムの侵害はなく、AWS サービスやインフラストラクチャへの直接的な影響も観察されませんでした。 コードの分析により、以下のような回避テクニックが明らかになりました ランダム化を使用して訪問者の一部のみをリダイレクトする 悪意のあるコードを隠すために base64 エンコーディングを使用する 同じ訪問者の繰り返しのリダイレクトを防ぐためにクッキーを設定する ブロックされた場合に新しいインフラストラクチャに移行する 侵害されたページの画像、ドメイン名は削除されています。 Amazon の阻止の取り組み Amazon は、高度な脅威アクターを積極的に探索し阻止することで、インターネットのセキュリティを保護することに引き続き取り組んでいます。私たちは業界パートナーやセキュリティコミュニティと協力して、インテリジェンスを共有し脅威を軽減し続けます。このキャンペーンを発見した際、Amazon は迅速に影響を受けた EC2 インスタンスを隔離し、Cloudflare や他のプロバイダーと連携して攻撃者のドメインを無効化し、関連情報を Microsoft と共有しました。 攻撃者が AWS から別のクラウドプロバイダーへの移行を含む新しいインフラストラクチャへの移行を試みたにもかかわらず、私たちのチームは彼らの活動を追跡し阻止し続けました。私たちの介入後、攻撃者が cloudflare[.]redirectpartners[.]com などの追加ドメインを登録し、再び Microsoft のデバイスコード認証ワークフローに被害者を誘導しようとしているのを観察しました。 ユーザーと組織の保護 組織には以下の保護対策を実施することをお勧めします。 エンドユーザー向け： セキュリティ検証ページを装った不審なリダイレクトチェーンに注意してください。 デバイス認証リクエストを承認する前に、常にその信頼性を確認してください。 AWS が現在ルートアカウントに多要素認証 (MFA) を要求しているのと同様に、すべてのアカウントで MFA を有効にしてください。 コマンドをコピー＆ペーストしたり、Windows の実行ダイアログ (Win+R) でアクションを実行するよう求めるウェブページには注意してください。 これは最近文書化された「ClickFix」テクニックに一致しており、攻撃者がユーザーに悪意のあるコマンドを実行させるよう騙します。 IT 管理者向け： デバイス認証フローに関する Microsoft のセキュリティガイダンスに従い、必要でない場合はこの機能を無効にすることを検討してください。 デバイスのコンプライアンス、場所、リスク要因に基づいて認証を制限する条件付きアクセスポリシーを適用してください。 特に新しいデバイス認証を含む認証イベントのための堅牢なログ記録とモニタリングを実装してください。 侵害の痕跡 (IOC) findcloudflare[.]com cloudflare[.]redirectpartners[.]com サンプル JavaScript コード デコードされた JavaScript コード。[removed_domain]は侵害されたサイトで削除されています この投稿に関する質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングと運用を主導しています。彼のミッションは、セキュリティの利点を最小抵抗の道にすることで Amazon のビジネスを可能にすることです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO などの様々な役割を経て、最近では AWS CISO を務めた後、2023 年 9 月に Amazon Integrated Security の CISO になりました。 Amazon に入社する前、CJ は連邦捜査局 (FBI) のサイバー部門でコンピュータとネットワーク侵入の技術分析を主導していました。CJ はまた、空軍特別捜査局 (AFOSI) の特別捜査官も務めました。CJ は今日のセキュリティ業界の基礎となる複数のコンピュータ侵入調査を主導しました。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、アクティブな SRO GT America GT2 レースカードライバーです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2001 年から macOS を使用し、4 年前のリリースから Amazon EC2 Mac インスタンス を使用してきた私は、AWS での継続的インテグレーションとデリバリー (CI/CD) パイプラインのスケーリングで大勢のお客様をサポートしてきました。今日は、Amazon EC2 M4 インスタンスと M4 Pro Mac インスタンスの一般提供が開始されたことをお知らせしたいと思います。 Apple プラットフォーム向けのアプリケーションを構築している開発チームには、複雑な構築プロセスを処理し、複数の iOS シミュレータを同時に実行するための強力なコンピューティングリソースが必要です。開発プロジェクトの規模が大きくなり、より高度になるにつれて、チームもパフォーマンスを強化し、メモリ容量を増やして、迅速な開発サイクルを維持しなければなりません。 Apple M4 Mac mini を中核としたインスタンス EC2 M4 Mac (API では mac-m4.metal ) インスタンスは、 Apple M4 Mac mini コンピュータ上に構築され、 AWS Nitro System を搭載しています。10 コア CPU (4 個のパフォーマンスコアと 6 個の効率性コア)、10 コア GPU、16 コア Neural Engine、24 GB ユニファイドメモリを備えた Apple シリコン M4 チップを使用しており、iOS と macOS のアプリケーション構築ワークロードのパフォーマンスを強化します。M4 Mac インスタンスは、アプリケーションの構築時やテスト時に EC2 M2 Mac インスタンスよりも最大 20% 優れたアプリケーション構築パフォーマンスを実現します。 EC2 M4 Pro Mac (API では mac-m4pro.metal ) インスタンスは、14 コア CPU、20 コア GPU、16 コア Neural Engine、48 GB ユニファイドメモリを備えた Apple シリコン M4 Pro チップを搭載しています。これらのインスタンスは、EC2 M2 Pro Mac インスタンスよりも最大 15% 優れたアプリケーション構築パフォーマンスを実現します。増強されたメモリとコンピューティング能力により、複数のデバイスシミュレータを使用してさらに多くのテストを同時実行することが可能になります。 M4 インスタンスと M4 Pro Mac インスタンスにはそれぞれ 2 TB のローカルストレージがあり、キャッシュ、構築、テストのパフォーマンスを向上させる低レイテンシーのストレージを提供します。 どちらのインスタンスタイプも、macOS Sonoma のバージョン 15.6 以降を Amazon マシンイメージ (AMI) としてサポートしています。AWS Nitro System は、高速 Thunderbolt 接続を使用することで、最大 10 Gbps の Amazon Virtual Private Cloud (Amazon VPC) ネットワーク帯域幅と 8 Gbps の Amazon Elastic Block Store (Amazon EBS) ストレージ帯域幅を提供します。 Amazon EC2 Mac インスタンスは AWS サービスとシームレスに統合するため、以下が可能になります。 AWS CodeBuild と AWS CodePipeline を使用して自動 CI/CD パイプラインを構築する AWS Secrets Manager でビルドシークレット (Apple の開発用証明書やキーなどの) の複数バージョンを保存して管理する AWS CloudFormation を使用して開発インフラストラクチャを管理する Amazon CloudWatch を使用してインスタンスのパフォーマンスをモニタリングする 使用開始方法の説明 EC2 M4 インスタンスと M4 Pro Mac インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して起動できます。 このデモでは、コンソールから M4 Pro インスタンスを起動しましょう。まず、インスタンスを実行するための専有ホストを割り当てます。 AWS マネジメントコンソール で [EC2]、 [専有ホスト] の順に移動し、 [専有ホストの割り当て] を選択します。 次に、 [名前タグ] に入力してから、 [インスタンスファミリー] ( mac-m4pro ) と [インスタンスタイプ] ( mac-m4pro.metal ) を選択します。 [アベイラビリティーゾーン] を 1 つ選択し、 [ホストのメンテナンス] のチェックを外します。 または、コマンドラインインターフェイスを使用することも可能です。 aws ec2 allocate-hosts \ --availability-zone-id "usw2-az4" \ --auto-placement "off" \ --host-recovery "off" \ --host-maintenance "off" \ --quantity 1 \ --instance-type "mac-m4pro.metal" 専有ホストが私のアカウントに割り当てられたら、割り当てられたホストを選択して、 [アクション] メニュー、 [インスタンスをホストで起動] の順に選択します。 コンソールには、このタイプのホスト向けに [サポートされている最新の macOS バージョン] が他の情報とともに表示されているのがわかります。今回は macOS 15.6 です。   [インスタンスを起動] ページで [名前] に入力します。ここでは macOS Sequoia の Amazon マシンイメージ (AMI) を選択します。このときに、 [アーキテクチャ] が 64 ビット ARM、 [インスタンスタイプ] が mac-m4pro.metal であることを確認します。 残りのパラメータは Amazon EC2 Mac 固有のものではなく、ネットワークとストレージの設定です。開発用のインスタンスを起動するときは、200 Gb 以上のボリュームを選択するようにしてください。Xcode をダウンロードしてインストールするには、デフォルトの 100 GB ボリュームサイズでは不十分です。 準備ができたら、ページの最下部にあるオレンジ色の [インスタンスを起動] ボタンを選択します。コンソールにはインスタンスが直ちに 実行中 として表示されますが、SSH 経由で接続できるようになるまで最大 15 分かかる場合があります。 または、このコマンドを使用することも可能です。 aws ec2 run-instances \ --image-id "ami-000420887c24e4ac8" \ # AMI ID depends on the region ! --instance-type "mac-m4pro.metal" \ --key-name "my-ssh-key-name" \ --network-interfaces '{"AssociatePublicIpAddress":true,"DeviceIndex":0,"Groups":["sg-0c2f1a3e01b84f3a3"]}' \ # Security Group ID depends on your config --tag-specifications '{"ResourceType":"instance","Tags":[{"Key":"Name","Value":"My Dev Server"}]}' \ --placement '{"HostId":"h-0e984064522b4b60b","Tenancy":"host"}' \ # Host ID depends on your config --private-dns-name-options '{"HostnameType":"ip-name","EnableResourceNameDnsARecord":true,"EnableResourceNameDnsAAAARecord":false}' \ --count "1" ターミナルからの Xcode のインストール インスタンスにアクセスできるようになったら、SSH を使用してインスタンスに接続し、開発ツールをインストールできます。 Xcode 16.4 のダウンロードとインストールには xcodeinstall を使用します。 ノートパソコンから、Apple Developer 認証情報を使用してセッションを開始します。 # on my laptop, with permissions to access AWS Secret Manager » xcodeinstall authenticate -s eu-central-1 Retrieving Apple Developer Portal credentials... Authenticating... 🔐 Two factors authentication is enabled, enter your 2FA code: 067785 ✅ Authenticated with MFA. 先ほど起動した EC2 Mac インスタンスに接続します。次に、Xcode をダウンロードしてインストールします。 » ssh ec2-user@44.234.115.119 Warning: Permanently added '44.234.115.119' (ED25519) to the list of known hosts. Last login: Sat Aug 23 13:49:55 2025 from 81.49.207.77 ┌───┬──┐ __| __|_ ) │ ╷╭╯╷ │ _| ( / │ └╮ │ ___|\___|___| │ ╰─┼╯ │ Amazon EC2 └───┴──┘ macOS Sequoia 15.6 ec2-user@ip-172-31-54-74 ~ % brew tap sebsto/macos ==> Tapping sebsto/macos Cloning into '/opt/homebrew/Library/Taps/sebsto/homebrew-macos'... remote: Enumerating objects: 227, done. remote: Counting objects: 100% (71/71), done. remote: Compressing objects: 100% (57/57), done. remote: Total 227 (delta 22), reused 63 (delta 14), pack-reused 156 (from 1) Receiving objects: 100% (227/227), 37.93 KiB | 7.59 MiB/s, done. Resolving deltas: 100% (72/72), done. Tapped 1 formula (13 files, 61KB). ec2-user@ip-172-31-54-74 ~ % brew install xcodeinstall ==> Fetching downloads for: xcodeinstall ==> Fetching sebsto/macos/xcodeinstall ==> Downloading https://github.com/sebsto/xcodeinstall/releases/download/v0.12.0/xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz Already downloaded: /Users/ec2-user/Library/Caches/Homebrew/downloads/9f68a7a50ccfdc479c33074716fd654b8528be0ec2430c87bc2b2fa0c36abb2d--xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz ==> Installing xcodeinstall from sebsto/macos ==> Pouring xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz 🍺 /opt/homebrew/Cellar/xcodeinstall/0.12.0: 8 files, 55.2MB ==> Running `brew cleanup xcodeinstall`... Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`. Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`). ==> No outdated dependents to upgrade! ec2-user@ip-172-31-54-74 ~ % xcodeinstall download -s eu-central-1 -f -n "Xcode 16.4.xip" Downloading Xcode 16.4 100% [============================================================] 2895 MB / 180.59 MBs [ OK ] ✅ Xcode 16.4.xip downloaded ec2-user@ip-172-31-54-74 ~ % xcodeinstall install -n "Xcode 16.4.xip" Installing... [1/6] Expanding Xcode xip (this might take a while) [2/6] Moving Xcode to /Applications [3/6] Installing additional packages...XcodeSystemResources.pkg [4/6] Installing additional packages...CoreTypes.pkg [5/6] Installing additional packages...MobileDevice.pkg [6/6] Installing additional packages...MobileDeviceDevelopment.pkg [ OK ] ✅ file:///Users/ec2-user/.xcodeinstall/download/Xcode%2016.4.xip installed ec2-user@ip-172-31-54-74 ~ % sudo xcodebuild -license accept ec2-user@ip-172-31-54-74 ~ % 知っておくべきこと 開発目的で使用する場合は、少なくとも 200 GB の EBS ボリュームを選択してください。Xcode をインストールするには、100 Gb のデフォルトボリュームサイズでは不十分です。私は、通常 500 Gb を選択します。インスタンスの起動後に EBS ボリュームサイズを増やす場合は、 APFS ファイルシステムのサイズも忘れずに変更してください 。 別の手段として、Mac mini で利用できる低レイテンシーのローカル 2 Tb SSD ドライブに開発ツールとフレームワークをインストールすることも選択できます。そのボリュームのコンテンツは、専有ホストではなく、インスタンスライフサイクルに結び付けられていることに注意してください。つまり、インスタンスを停止して再起動すると、すべてのコンテンツが内部 SSD ストレージから削除されます。 mac-m4.metal インスタンスと mac-m4pro.metal インスタンスは、macOS Sequoia 15.6 以降をサポートします。 既存の EC2 Mac インスタンスは、移行したインスタンスが macOS 15 (Sequoia) を実行している場合に移行できます。既存のインスタンスからカスタム AMI を作成して、この AMI から M4 または M4 Pro インスタンスを起動してください。 最後に、私が作成したチュートリアルを参照することをお勧めします。これらのチュートリアルは、Amazon EC2 Mac の使用を開始するために役立ちます。 Start an Amazon EC2 Mac instance Connect to an Amazon EC2 Mac instance (3 つの異なる接続方法を紹介します) Build your applications faster with a CI/CD pipeline on Amazon EC2 Mac 料金と利用可能なリージョン 現在、EC2 M4 インスタンスと M4 Pro Mac インスタンスを利用できるのは米国東部 (バージニア北部) と米国西部 (オレゴン) リージョンですが、将来は他のリージョンでも利用可能になる予定です。 Amazon EC2 Mac インスタンスは、オンデマンドと Savings Plans の料金モデルを使用して、専有ホストとして購入できます。EC2 Mac インスタンスの料金は 1 秒単位で請求され、最小割り当て期間は Apple macOS ソフトウェアライセンス契約に従って 24 時間になっています。24 時間の最小割り当て期間が終了すると、ホストはいつでも解放でき、追加の契約は必要ありません。 私は Apple 開発者と密接に連携しているので、皆さんが開発サイクルを加速するためにこれらの新しいインスタンスをどのように使用するのかを見るのが楽しみです。パフォーマンスの向上、メモリ容量の増強、AWS サービスとの統合の組み合わせは、iOS、macOS、iPadOS、tvOS、watchOS、VisionOS プラットフォーム向けのアプリケーションを構築するチームに新たな可能性をもたらします。アプリケーション開発以外にも、Apple シリコンの Neural Engine を使用するこれらのインスタンスは、 機械学習 推論ワークロードを実行するためのコスト効率性に優れた候補になります。このトピックについては、AWS re:Invent 2025 で詳しくお話しする予定になっており、EC2 Mac インスタンスで機械学習ワークロードを最適化するためのベンチマークとベストプラクティスをご紹介します。 EC2 M4 インスタンスと M4 Pro Mac インスタンスの詳細については、Amazon EC2 Mac インスタンス ページ、または EC2 Mac ドキュメント を参照してください。これらのインスタンスは、AWS で Apple 開発ワークフローをモダナイズするために今すぐご利用いただけます。 – seb 原文は こちら です。

9 月 11 日、AWS は AWS Toolkit for Visual Studio Code への LocalStack の統合を発表しました。この統合により、開発者はサーバーレスアプリケーションのローカルでのテストとデバッグをこれまで以上に簡単に行えるようになります。この機能強化は、2025 年 7 月にリリースされた コンソールと IDE の統合やリモートデバッグ 機能などの 最近行われた AWS Lambda 開発エクスペリエンスの改善 を踏まえたもので、Amazon Web Services (AWS) でのサーバーレス開発を簡素化するという継続的な取り組みの一環です。 開発者がサーバーレスアプリケーションを構築するときは、テストエクスペリエンスを効率化するために、ユニットテスト、統合テスト、クラウド内で実行されているリソースのデバッグの 3 つの重要分野に焦点を当てるのが一般的です。 AWS サーバーレスアプリケーションモデルコマンドラインインターフェイス (AWS SAM CLI) は個々の Lambda 関数に優れたローカルユニットテスト機能を提供しますが、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon EventBridge 、 Amazon DynamoDB などの複数の AWS サービスを使用するイベントドリブンなアーキテクチャで作業を行っている開発者には、ローカル統合テストのための包括的なソリューションが必要です。LocalStack は AWS サービスのローカルエミュレーションを提供していましたが、開発者は LocalStack をスタンドアロンツールとして管理しなければならず、複雑な設定や複数のインターフェイス間における頻繁なコンテキストスイッチが必要であったため、開発サイクルの速度が低下する原因となっていました。 AWS Toolkit for VS Code への LocalStack 統合 これらの課題に対応するため、AWS は LocalStack 統合を導入して、開発者が AWS Toolkit for VS Code を LocalStack エンドポイントに直接接続できるようにしました。この統合により、開発者はツールを切り替えたり、複雑な LocalStack 設定を管理したりすることなく、サーバーレスアプリケーションのテストとデバッグを実行できます。開発者は、クラウドリソースに接続する必要があった複数のツールの管理、複雑なエンドポイント設定、サービス境界問題への対応を行わなくても、Lambda、Amazon SQS、EventBridge などのサービスを使用するイベントドリブンなワークフローをエンドツーエンドでエミュレートできるようになります。 この統合の主なメリットは、以前は不可能だった LocalStack などのカスタムエンドポイントへの AWS Toolkit for VS Code の接続が可能になったことです。これまで、AWS Toolkit for VS Code をその LocalStack 環境にポイントするには、開発者が手動設定とツール間でのコンテキストスイッチを行う必要がありました。 VS Code で LocalStack の使用を開始する方法は簡単です。開発者は、LocalStack の 無料 バージョンから始めることができます。このバージョンは、初期段階の開発とテストに最適な AWS のコアサービスのローカルエミュレーションを提供します。VS Code にあるガイド付きアプリケーションウォークスルーを使用することで、開発者は LocalStack をツールキットインターフェイスから直接インストールできます。このウォークスルーは、LocalStack 拡張機能を自動的にインストールし、セットアッププロセスをガイドします。設定されると、開発者は IDE を離れずに、サーバーレスアプリケーションをエミュレートされた環境に直接デプロイし、アプリケーションの機能をローカルでテストできます。 試してみましょう まず、AWS Toolkit for VS Code のコピーを最新バージョンに更新します。更新してから [Application Builder] に移動すると、新しいオプションが表示されているので、 [Application Builder のウォークスルー] をクリックします。そうすることで、LocalStack をワンクリックでインストールできます。 LocalStack のセットアップが完了したら、ステータスバーから起動できます。その後、 設定済みの AWS プロファイル のリストから LocalStack できるようになります。この画像では、Application Composer を使用して、 Amazon API Gateway 、Lambda、DynamoDB を使用するシンプルなサーバーレスアーキテクチャを構築しています。通常、私は AWS SAM を使用して AWS にデプロイします。今回も、同じ AWS SAM コマンドを使用してスタックをローカルにデプロイします。 コマンドラインから `sam deploy –guided –profile localstack` を実行して、いつものプロンプトに従うだけです。AWS SAM CLI を使用した LocalStack へのデプロイは、AWS へのデプロイで慣れ親しんだものとまったく同じエクスペリエンスを提供します。以下のスクリーンショットでは、AWS SAM からの標準的な出力と、AWS Toolkit Explorer にリストされている新しい LocalStack リソースを確認できます。 Lambda 関数にアクセスして、ローカルにデプロイした関数コードを編集することもできます! LocalStack のウェブサイトでは、ウェブサイトにログインして、私がローカルで実行しているすべてのリソースを見ることができます。以下のスクリーンショットでは、先ほどデプロイしたローカル DynamoDB テーブルを確認できます。 強化された開発ワークフロー これらの新しい機能は、最近リリースされたコンソールと IDE の統合やリモートデバッグ特徴量を補完することで、開発ライフサイクル全体のさまざまなテストニーズに対応する包括的な開発エクスペリエンスを生み出します。AWS SAM CLI は、個々の Lambda 関数に優れたローカルテスト機能を提供し、ユニットテストシナリオを効果的に処理します。統合テストでは、LocalStack 統合を通じて、開発速度を低下させる可能性のある AWS Identity and Access Management (IAM) 許可、Amazon Virtual Private Cloud (Amazon VPC) 設定、サービス境界問題の複雑性に煩わされることなく、マルチサービスワークフローをローカルにテストできます。 開発者が開発環境内で AWS サービスを使用してテストを実施する必要がある場合は、Amazon VPC リソースと IAM ロールへのフルアクセスを提供する、AWS のリモートデバッグ機能を使用できます。この多層的なアプローチにより、開発者は LocalStack を使用して開発の早い段階でビジネスロジックに集中し、AWS サービスの動作や設定に照らして検証する必要があるときはクラウドベースのテストにシームレスに移行できるようになります。この統合では、複数のツールや環境間の切り替えを行う必要がなくなるため、開発者は特定のニーズに適したテストアプローチを選択する柔軟性を維持しながら、問題をより迅速に特定して修正できます。 今すぐご利用いただけます これらの新特徴量は、v3.74.0 に更新した AWS Toolkit for VS Code を通じて使用を開始できます。LocalStack 統合は、 AWS GovCloud (米国) リージョンを除くすべての商用 AWS リージョン でご利用いただけます。詳細については、 AWS Toolkit for VS Code と Lambda のドキュメントをご覧ください。 より広範なサービスカバレッジや高度な機能が必要な開発者には、LocalStack がより多くの特徴量を備えた追加のティアを提供しています。この統合の使用に追加の AWS 料金はかかりません。 これらの機能強化は、サーバーレス開発エクスペリエンスを簡素化するという AWS の継続的な取り組みにおけるもう 1 つの大きな前進を表しています。この 1 年間、AWS は VS Code をサーバーレス開発者に選ばれるツールにすることに重点を置いてきました。LocalStack 統合は、サーバーレスアプリケーションをこれまで以上に効率的に構築してテストするためのツールを開発者に提供することで、このジャーニーを前進させます。 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS Summit Japan 2025 の動画アーカイブが YouTube に公開 されています。もともと、AWS 登壇セッションが公開されていましたが、少し前にお客様の登壇セッションが追加されています。実際に活用いただいているお客様の発表内容は、貴重な経験を基にしたお話となっており、大変参考にいただける話が多いです。ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月8日週の主要なアップデート 9/8(月) Amazon CloudFront が IPv6 オリジンのサポートを発表 Amazon CloudFront で、オリジンサーバーへの IPv6 接続のサポートを開始しました。これまで、クライアントからの接続は IPv6 を受け付けていましたが、オリジンサーバーへは IPv4 でのみ接続が可能でした。今回のアップデートにより、オリジンサーバーへの接続も IPv6 通信が可能になり、IPv6 ネットワーク環境でのパフォーマンス向上や IPv4 アドレス枯渇問題の解決に貢献します。設定は IPv4 のみ、IPv6 のみ、デュアルスタックから選択でき、すべての商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 9/9(火) Amazon EC2 R8g インスタンスが追加リージョンで利用可能に Amazon EC2 R8g インスタンスが大阪リージョンとカナダ中部リージョンで利用開始となりました。最新の AWS Graviton4 プロセッサを搭載し、従来の Graviton3 ベースと比べて最大 30% の性能向上を実現しています。データベースやインメモリキャッシュなどメモリを大量に使うアプリケーションに最適で、従来の R7g と比べて最大 3 倍の vCPU とメモリを提供します。詳細は こちらをご参照ください。 Amazon ElastiCache が追加の AWS リージョンで M7g および R7g Graviton3 ベースノードをサポート Amazon ElastiCache で Graviton3 ベースの M7g と R7g ノードが、大阪、香港、パリなど 13 の新しいリージョンで利用可能になりました。従来の Graviton2 と比較して、スループットが最大 28 % 向上し、レイテンシが最大 21 % 改善されます。特に Redis を使用するアプリケーションで高いパフォーマンスが期待でき、ネットワーク帯域幅も最大 25 % 向上します。詳細は こちらのドキュメントをご参照ください。 9/10(水) AWS がセキュリティ分析強化のための CloudTrail MCP Server を開始 AWS Labs MCP オープンソースリポジトリ に CloudTrail MCP Server をリリースしました。この新機能により、AI エージェントが自然言語でセキュリティ分析を実行できるようになります。従来は複雑な API 統合が必要でしたが、今回のアップデートで会話形式での操作が可能となり、90日間の管理イベント履歴検索や CloudTrail Lake での最大 10年間のデータ分析が簡単に行えます。詳細は こちらの GitHub リポジトリをご参照ください。 Amazon Bedrock AgentCore Gateway が AWS PrivateLink 呼び出しと呼び出しログ記録をサポート Amazon Bedrock AgentCore Gateway で 「AWS PrivateLink 対応」と、「Amazon CloudWatch、Amazon S3、Amazon Data Firehose を通じた呼び出しログ記録」をサポートしました。これにより VPC 内から直接アクセスでき、パブリックインターネットを経由せずセキュアに AI エージェントツールを利用できます。また CloudWatch や S3 を通じてログ記録が可能になり、エージェントの動作監視や監査が容易になりました。現在 AgentCore は Preview となっており、バージニア北部、オレゴン、シドニー、フランクフルトリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 AWS CDK Refactor (プレビュー) の紹介 AWS CDK で新機能「cdk refactor」コマンド (プレビュー版) が利用可能になりました。インフラのリファクタリングを安全に実行できる機能で、コンストラクトの名前変更やスタック間でのリソース移動、CDK アプリケーションの再編成が可能です。従来は論理 ID の変更によりリソース置換のリスクがありましたが、この機能によりデプロイ済みリソースの状態を保持しながらコード構造を改善できます。詳細は こちらの Blog 記事をご参照ください。 9/11(木) Amazon Athena がドライバーでのシングルサインオンサポートを開始 Amazon Athena で、 AWS IAM Identity Center の信頼できるアイデンティティ伝播を通じて、JDBC および ODBC ドライバーのシングルサインオン (SSO) 対応が開始されました。これまでは各ツールで個別に認証情報を管理する必要がありましたが、企業の認証情報を使って BI ツールや SQL クライアントから直接 Athena にアクセスできるようになります。Lake Formation で設定したアクセス権限も自動適用されるため、データガバナンスを保ちながら分析作業を効率化できます。詳細は こちらのドキュメントをご参照ください。 9/12(金) Amazon SageMaker Unified Studio が VS Code からのリモート接続をサポート Amazon SageMaker Unified Studio で VS Code からのリモート接続機能が提供開始されました。これまでローカルの VS Code 環境とクラウドの ML 開発環境は別々でしたが、今回の機能により慣れ親しんだ VS Code の設定やワークフローをそのまま維持しながら SageMaker のスケーラブルなコンピュートリソースにアクセスできるようになりました。AWS Toolkit 拡張機能を使った簡単な認証でデータ処理や ML ワークフローを実行でき、開発効率が向上します。詳細は こちらのドキュメントをご参照ください。 Amazon RDS Proxy がエンドツーエンド IAM 認証のサポートを発表 Amazon RDS Proxy で、エンドツーエンド IAM 認証がサポートされました。これまでデータベース接続時に Secrets Manager での認証情報管理が必要でしたが、今回のアップデートにより IAM 認証のみでの接続が可能になりました。認証情報のローテーション作業が不要となり、運用負荷が軽減されます。詳細は こちらのドキュメントをご参照ください。 S3 向けマルウェア保護がファイルサイズとアーカイブスキャン制限を拡張 GuardDuty Malware Protection for S3 のスキャン機能を強化しました。従来は 5GB までのファイルしかスキャンできませんでしたが、今回のアップデートで 100GB まで対応可能になりました。また、アーカイブファイル内の処理可能ファイル数も 1,000 個から 10,000 個に拡張されています。これにより、大容量の動画ファイルや大量のファイルが含まれた ZIP アーカイブなども安全にスキャンできるため、より包括的なセキュリティ保護が実現できます。この機能強化は全サポートリージョンで自動的に有効化されます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 M4 および M4 Pro Mac インスタンスの一般提供開始を発表 Amazon EC2 で M4 と M4 Pro Mac インスタンスの一般提供が開始されました。M4 は従来の M2 と比べて最大 20% 、M4 Pro は M2 Pro と比べて最大 15% のアプリケーションビルド性能向上を実現します。iOS や macOS など Apple プラットフォーム向けアプリの開発・テストに最適で、複数の Xcode シミュレータを並列実行することで開発サイクルを大幅に短縮できます。バージニア北部とオレゴンリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon ECS Service Connect がクロスアカウントワークロードのサポートを追加 Amazon ECS Service Connect がクロスアカウントワークロードに対応しました。AWS Resource Access Manager (RAM) との統合により、異なる AWS アカウント間でのサービス通信がシームレスに実現できます。従来は同一アカウント内でのみ利用可能でしたが、今回のアップデートで複数アカウントにまたがる大規模な組織でも効率的なサービス間通信が可能になりました。プラットフォームエンジニアは共通の名前空間を使用して複数アカウントのサービスを管理でき、運用負荷の軽減とリソースの重複回避が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS Japan の技術職の方を中心とした、 Zenn Publication を新たに作りました。AWS Japan の従業員が持つ知識や経験を元にした記事を出していくスペースとなっており、よろしければこちらも活用いただけると幸いです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近若干？の涼しさを感じる日も増えてきましたが、皆さまいかがお過ごしでしょうか。先週はAWS Amazon Nova Igniteの開催発表（ 申し込みはこちら ）や、Amazon Bedrockの新機能アップデートなど、生成AIの実運用に役立つニュースが盛りだくさんでした。今週も引き続き、現場ですぐに活用できる事例やサービスアップデートをピックアップしてお届けしますので、ぜひご一読ください。 新たに2つのプランが追加された「 AWS ジャパン生成 AI 実用化推進プログラム 」も、たくさんのお申し込みをいただいています。企業やプロジェクト単位でもまだまだ募集中ですので、この機会にご活用いただけますと幸いです。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース 資料公開 & 開催報告 「AWS for Software & Technology | Builders Forum Tokyo – AI Agent 時代の SaaS イベントを開催しました」 このブログは、2025年9月3日に開催されたAWS主催のイベント「AI Agent時代のSaaS」の詳細レポートです。300名以上が参加したこのイベントで紹介された、AIエージェント技術の最新動向と実践的な活用事例について詳しく解説しています。ブログでは、フリー、kubell、エムオーテックスの3社による貴重な導入事例が紹介されており、特に「まほう経費精算」での業務効率化や、Amazon Q Developerの全社導入により月600時間の効率化を実現した具体的な取り組みが詳細に説明されています。また、AWSのソリューションアーキテクトによる3つの技術セッションでは、マルチテナント環境でのAIエージェント設計思想、Observability、セキュリティという本番運用に欠かせない要素が包括的に解説されています。さらに、初心者向けから上級者向けまでのワークショップの内容や、Amazon Bedrock Knowledge Basesを活用したRAGの実装方法も紹介されており、実際に手を動かして学べる貴重な学習機会の様子も詳しくレポートされています。イベントの全資料も公開されていますので是非ご参照ください。 ブログ記事「チャットから仕様へ : Kiro を用いた AI 支援開発の深掘り」 AIコーディングアシスタントを使っていて「要件を整理するのに1時間かかったのに、肝心のコードは思うように生成されない」という経験はありませんか？今回ご紹介する記事では、この課題を根本から解決する新しいIDE「Kiro」と、その革新的な「仕様駆動型開発」のアプローチについて詳しく解説しています。記事では、従来のAIコーディングアシスタントがなぜ非効率になってしまうのかという根本原因から始まり、Kiroがどのようにstructure.md、tech.md、product.mdなどの基礎ドキュメントを自動生成し、その後requirements.md、design.md、tasks.mdという詳細仕様を作成することで開発プロセスを変革するかを具体的なワークフロー例とともに紹介しています。 ブログ記事「Kiro の AI エージェントフックで開発ワークフローを自動化する」 開発プロジェクトが成長するにつれて、ドキュメントの更新やテストの同期など、重要だけれど繰り返し発生する作業に多くの時間を取られていませんか？このブログではエージェント型IDE「Kiro」の革新的な「エージェントフック」機能について詳しく解説しています。ブログでは、従来の受動的なAI支援から能動的なAI統合への転換を実現するエージェントフックの仕組みを、具体的な設定方法とともに紹介しています。エージェントフックは、ファイルの保存や編集といったトリガーイベントに対して、AIが自動的にテスト更新やドキュメント同期などのアクションを実行する機能で、自然言語による設定が可能です。ブログでは、TypeScriptプロジェクトでのユニットテスト自動更新やPythonアプリケーションでのテスト生成、APIドキュメントの自動同期など、実際の開発現場で即座に活用できる具体的な実装例が豊富に紹介されています。また、フックの設定からチーム共有、ベストプラクティスまで、実際の運用に必要な知識が体系的にまとめられています。 サービスアップデート Amazon SageMaker Unified StudioにおけるAIアシスタント機能の改善 Amazon SageMaker Unified Studioの開発環境において、Amazon Q Developerのチャット機能が改善され、Jupyter NotebookとCode Editorでのコマンドライン操作時にもAmazon Q Developerが利用可能になりました。Model Context Protocol (MCP)サーバーとの統合により、プロジェクトのリソース（データ、コンピューティング、コードなど）を認識し、データエンジニアリングや機械学習開発作業において、より個々に合わせたサポートを提供できるようになります。コードのリファクタリングやファイルの修正、トラブルシューティングなどのタスクに対して、より関連性の高い支援が可能になり、開発者の生産性向上に貢献します。この機能はAmazon Q Developer Free Tierで無料で利用でき、Amazon SageMaker Unified Studioが利用可能なすべてのAWSリージョンで提供されています。 Amazon Q in Connect が Connect Web UI で直接LLMを選択可能に カスタマーサービス向けの生成AI搭載アシスタント「Amazon Q in Connect」において、コンタクトセンターの管理者がAmazon Connect web UIから直接異なる大規模言語モデル（LLM）を選択できるようになり、AIエージェントの設定がよりシンプルになりました。管理者はコードを書くことなく、ビジネスニーズに合わせて最適なLLMを選択できます。例えば、素早いレスポンスが必要な場合はAmazon Nova Proを、複雑な推論が必要な場合はAnthropic Claude Sonnetを選択するなど、顧客とのやり取りの種類に応じて柔軟にモデルを切り替えることが可能です。 Amazon BedrockでTwelveLabs’ Marengo Embed 2.7の同期推論が利用可能に Amazon BedrockでTwelveLabs社のMarengo 2.7モデルの同期推論がサポートされるようになりました。これまでは動画や音声ファイルなどの大容量コンテンツ処理に特化した非同期推論のみでしたが、今回のアップデートによりテキストや画像の埋め込みベクトル生成において低遅延での同期処理が可能になりました。これにより、自然言語クエリによる瞬時の動画検索や、画像の類似性を使ったインタラクティブな商品発見など、よりレスポンシブな検索・検索体験を構築できるようになります。一般ユーザーにとっては、動画コンテンツから特定のシーンを素早く見つけたり、商品画像から類似商品を即座に発見できるなど、より直感的で高速な検索体験が提供される点が大きな価値となります。生成AIを活用している開発者にとっては、マルチモーダル埋め込みモデルの高度な機能を低遅延で活用できることで、リアルタイム性が求められるアプリケーションの開発が格段に容易になり、ユーザーエクスペリエンスの向上と開発効率の改善を同時に実現できます。 Amazon Bedrock AgentCore GatewayがAWS PrivateLinkの呼び出しと呼び出しログ機能をサポート Amazon Bedrock AgentCore Gatewayにおいて、AWS PrivateLinkによる呼び出しと、Amazon CloudWatch、Amazon S3、Amazon Data Firehoseを通じたinvocation loggingがサポートされるようになりました。AgentCore Gatewayは開発者がエージェントツールを安全かつ大規模に構築、デプロイ、発見、接続するための基盤を提供するサービスです。AWS PrivateLinkサポートにより、VPC内のユーザーやエージェントがパブリックインターネットを経由することなく、プライベートネットワーク経由でAgentCore Gatewayにアクセスできるようになり、セキュリティが大幅に向上します。また、呼び出しログを使用すると、各呼び出しログを可視化し、問題や監査アクティビティを深く掘り下げることができます。Amazon Bedrock AgentCore は現在プレビュー段階で、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジア太平洋 (シドニー)、およびヨーロッパ (フランクフルト) でご利用いただけます。 AWSがセキュリティ分析強化のためのCloudTrail MCP Serverを発表 AWS Labs MCPオープンソースリポジトリ にAWS CloudTrail用のModel Context Protocol（MCP）サーバーを追加しました。これにより、AIエージェントが会話形式のインターフェースを通じて、CloudTrailの包括的なセキュリティおよびコンプライアンス機能を活用できるようになります。AIアシスタントはAPI呼び出しの分析、ユーザーアクティビティの追跡、AWS環境全体での高度なセキュリティ分析を自然言語で実行でき、90日間の管理イベント履歴の検索や最大10年間のCloudTrail LakeデータへのTrino SQLも実行可能です。セキュリティ担当者にとっては、複雑なセキュリティ調査やコンプライアンスワークフローが大幅に効率化され、専門的な技術知識がなくても直感的にセキュリティ分析を実行できる点が大きな価値となります。カスタムAPI統合を構築することなく、AIエージェントが自然言語でセキュリティデータにアクセスし、高度な分析を自動化できることで、セキュリティ運用の自動化と効率性が向上します。 Amazon SageMakerノートブックがP6-B200インスタンスタイプをサポート Amazon SageMakerノートブックでAmazon EC2 P6-B200インスタンスの一般提供が開始されました。P6-B200 インスタンスには、1440 GB の高帯域幅 GPU メモリを搭載した 8 機の NVIDIA B200 GPU、第 5 世代インテル Xeon スケーラブルプロセッサ (Emerald Rapids)、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージが搭載されており、従来のP5enインスタンスと比較してAIトレーニングで最大2倍の性能向上を実現します。LLM、MoEモデル、マルチモーダル推論モデルなどの大規模ファウンデーションモデルの開発やファインチューニングが可能で、JupyterLabやCodeEditor環境で効率的に実験できるようになり開発サイクルの短縮と、より高品質なAIモデルの構築が実現できます。Amazon EC2 P6-B200 インスタンスは、AWS 米国東部 (オハイオ) および米国西部 (オレゴン) リージョンの SageMaker ノートブックで利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

私が住んでいるオランダの都市、ユトレヒトでは、夏も終わりを迎えました。2 週間後の 9 月 24 日、私は Kinepolis Jaarbeurs Utrecht で開催される AWS Community Day 2025 に出席する予定です。この 1 日限りのイベントでは、オランダ全土から 500 人を超えるクラウドプラクティショナーが集まり、5 つのテクニカルトラックで合計 25 のブレイクアウトセッションが行われます。当日は、午前 9 時の仮想基調講演で始まります。その後、サーバーレスアーキテクチャの実用的な実装とコンテナ最適化戦略に焦点を当てた 2 つのブレイクアウトセッションが並行して行われ、経験レベルを問わない貴重なインサイトを提供します。 2025 年の AWS Community Day Netherlands 2024 では、さまざまなクラウドプラクティショナー、講演者、AWS 愛好家が一堂に会し、コミュニティ主導のカンファレンスを貴重な知識共有プラットフォームにしてくれました。今回の Community Day に参加する予定ならば、いつでも私に声をかけてください。AWS サービスや、クラウド実装の経験について語り合いましょう! では、9 月 1 日週の新しい発表を見てみましょう。 9 月 1 日週のリリース AWS Transform 評価がデタッチドストレージ分析の提供を開始 – AWS Transform の評価機能が拡大され、オンプレミスのデタッチドストレージインフラストラクチャを分析できるようになりました。この機能は、お客様が移行の総保有コスト (TCO) を判断するために役立ちます。新しい評価機能は、ストレージエリアネットワーク (SAN)、ネットワークアタッチドストレージ (NAS)、ファイルサーバー、オブジェクトストレージ、仮想環境を評価して、Amazon S3、Amazon EBS、Amazon FSx などの適切な AWS サービスへの移行に関する推奨事項を提供します。このツールは、パフォーマンスとコストの最適化に関する推奨事項に加えて、現在の環境と AWS 環境の包括的な TCO 比較も提供します。ストレージは移行機会全体の最大 45% を占めていることから、お客様はこの機能強化を使用してさまざまな AWS 移行オプションを視覚化できます。AWS Transform 評価は、米国東部 (バージニア北部) リージョンと欧州 (フランクフルト) リージョンでご利用いただけます。 Amazon Bedrock が Anthropic Claude Sonnet 4 のグローバルクロスリージョン推論を導入 – Amazon Bedrock で Anthropic の Claude Sonnet 4 モデルがグローバルクロスリージョン推論のサポートを開始し、推論リクエストを任意の対応商用 AWS リージョンにルーティングして処理できるようになりました。この機能強化は利用可能なリソースを最適化するとともに、複数のリージョンにトラフィックを分散することで、より高いモデルスループットを実現します。これまでは、特定の地域 (米国、EU、または APAC) に関連付けられたクロスリージョン推論プロファイルの選択が可能でしたが、新しいグローバルクロスリージョン推論プロファイルは、地域固有の処理を必要としない生成 AI ユースケースの柔軟性を高めるため、計画外のトラフィックバーストの管理やモデルスループットの向上に役立ちます。詳しい実装ガイダンスについては、 Amazon Bedrock ドキュメント を参照してください。 Amazon Neptune データベースがパブリックエンドポイントのサポートを追加 – Amazon Neptune がパブリックエンドポイントのサポートを開始し、複雑なネットワーク設定を行わなくても VPC 外から Neptune データベースに直接接続できるようになりました。この特徴量は、IAM 認証、VPC セキュリティグループ、転送時の暗号化を用いてセキュリティを維持しながら、開発者が VPN 接続や踏み台ホストを必要とすることなく、開発デスクトップからグラフデータベースにセキュアな方法でアクセスできるようにします。パブリックエンドポイントは、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して、エンジンバージョン 1.4.6 以降を実行している Neptune クラスターで有効化できます。この特徴量は、Neptune データベースが提供されているすべての AWS リージョンで、Neptune の標準料金以外の追加料金なしでご利用いただけます。実装の詳細は、 Amazon Neptune ドキュメント に記載されています。 AWS マネジメントコンソールでの ECS Exec の提供開始 – Amazon ECS が AWS マネジメントコンソールで ECS Exec を直接サポートするようになりました。このため、インバウンドポートや SSH キー管理を必要とすることなく、実行中のコンテナへのセキュアでインタラクティブなシェルアクセスが可能になります。これまでは API、CLI、SDK 経由でしか利用できなかったこの特徴量は、コンソールインターフェイスからコンテナに直接アクセスできるようにすることで、トラブルシューティングを効率化します。ECS Exec は、サービスやスタンドアロンタスクの作成時や更新時に有効化できます。その後、タスク詳細ページで [接続] を選択してコンテナに接続すると、CloudShell 経由でインタラクティブなセッションが開始されます。コンソールには、ローカルターミナルで使用するための基盤となる AWS CLI コマンドも表示されます。この特徴量はすべての商用 AWS リージョンで利用でき、「 ECS デベロッパーガイド 」に説明が記載されています。 AWS User Notifications の組織的な通知設定の一般提供開始 – AWS User Notifications が組織的な通知設定をサポートするようになりました。この機能は、AWS Organizations ユーザーが組織全体の通知を一元的に設定し、表示するために役立ちます。特定の組織部門、または組織内のすべてのアカウントに対する通知は、管理アカウント、または委任された管理者が設定できます。このサービスは、MFA を使用しないコンソールサインインなどのサポート対象 Amazon EventBridge イベントに関する通知の設定をサポートし、通知は管理者のコンソール通知センターと AWS コンソールモバイルアプリケーションに表示されます。ユーザー通知は委任された管理者を最大 5 人サポートし、AWS User Notifications が提供されているすべての AWS リージョンでご利用いただけます。実装の詳細については、「 AWS User Notifications ユーザーガイド 」を参照してください。 AWS からのお知らせのすべてが記載されたリストについては、「AWS の最新情報」ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティが交流し、コラボレートして、AWS について学ぶために一堂に会する無料のオンラインイベントと対面イベントに参加しましょう。最寄りの都市で開催されるイベントにご登録ください。日程は、 チューリッヒ (9 月 11 日)、 ロサンゼルス (9 月 17 日)、 ボゴタ (10 月 9 日) です。 AWS re: Invent 2025 – 12 月 1 日から 5 日は、最新の AWS イノベーション、ピアツーピア学習、エキスパート主導のディスカッション、貴重なネットワーキング機会のために世界中のクラウドパイオニアが米国ラスベガスに集結する AWS re:Invest に参加しましょう。 イベントカタログ の確認もお忘れなく。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日) です。 近日開催される AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 9 月 8 日週のニュースは以上です。9 月 15 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

はじめに Windows 10 のサポート終了が近づいており、エンドユーザーコンピューティング管理者はユーザーを Windows 11 の仮想デスクトップに移行する必要があります。 Amazon WorkSpaces はセルフサービスによる BYOL（Bring Your Own License）有効化機能 を提供開始しました。この新機能により、BYOL を有効化するために サポートケースを開く必要がなくなりました。BYOL を有効化することで、Amazon WorkSpaces のユーザーはカスタム Windows イメージ、ISO、または既存の AMI をインポートできるようになります。 改善された BYOL フレームワークは、以下のハイレベルな手順で構成されています： 1.WorkSpaces コンソールで BYOL を有効化し、最小限の WorkSpaces 要件に同意する 2.有効化後、Windows VM イメージを Amazon S3 にアップロードし、WorkSpaces コンソールからインポートする 3.WorkSpaces は自動的に EC2 Image Builder のパイプラインを生成し、イメージをビルド、テストして互換性に関する問題を解決する 4.イメージのインポートが成功したら、 カスタムバンドル を作成して Amazon WorkSpaces をプロビジョニングする 前提条件: 1.WorkSpaces をサポートする AWS リージョンを使用していることを確認する 2.BYOL を有効化するために、 最低限の WorkSpaces 利用コミットメント に同意する 注意: GovCloud リージョンではアカウントの自動有効化は利用できません。BYOL を有効化するには AWS サポートにケースを開く必要があります。ISO インポートオプションは GovCloud リージョンでは利用できません。 Amazon WorkSpaces での BYOL の有効化 1.WorkSpaces コンソールを開く 2.左側のナビゲーションペインで アカウント設定 を選択 3. ライセンス持ち込み (BYOL) のセクションで、「 BYOL を今すぐ開始する 」を選択し、「 BYOL のアカウントを有効にする 」をクリック 4. BYOL の最小要件 に同意するチェックボックスにチェックを入れ、「 アカウントを有効にする 」をクリック 5.BYOL が有効化されたらイメージをインポートして、WorkSpaces 管理インターフェイスの IP 範囲を選択 WorkSpaces BYOL イメージのインポート 1.WorkSpaces コンソールの「イメージ」タブに移動し、「イメージのインポート」を選択 2.Windows イメージをインポートするためのウィザードが表示されます。以下 3 つのオプションがあります: VM Import: 事前にカスタマイズされた仮想マシンイメージをインポートします。VHDX、VMDK、OVF ファイルをインポートできます ISO Import: Microsoft からダウンロードしたカスタマイズされていない Windows ISO イメージをインポートします AMI Import: 既存の EC2 AMI を WorkSpaces BYOL イメージとしてインポートします 3.次に、必要な VM イメージをアップロードした S3 バケットの場所を イメージソース として指定します。 4. インフラストラクチャ設定 では、EC2 Image Builder から既存のインフラ構成を選択するか、新しいものを作成します。これは、イメージを構築する際の設定をカスタマイズするために使用されます。詳細は AWS ドキュメント を参照してください 5. イメージの詳細 を指定し、必要に応じて タグ を追加します。タグにより、イメージやコストの追跡に必要なメタデータが生成されます WorkSpaces BYOL イメージのインポートプロセスでは、EC2 Image Builder が使用され、自動的に修復を試みますが、場合によっては手動での対応が必要になる場合があります。その際は、EC2 ビルドインスタンスにアクセスして修正を行い、WorkSpaces コンソールから再度インポートを試みてください。 トラブルシューティングガイド も参照可能です。 BYOL 管理用 IP アドレス範囲の選択 1.BYOL イメージのインポートが正常に完了した後、左ペインの アカウント設定 に移動する 2. ライセンス持ち込み（BYOL） の「 BYOL を今すぐ開始する 」をクリック 3. IP アドレス範囲を選択する にて、 「 IP アドレス範囲を選択する 」をクリック 3.検索範囲で絞り込み、Select CIDR block で選択して「 送信 」をクリック 一度 IP アドレス範囲を指定すると、後から変更することはできません。内部ネットワークと衝突しないアドレス範囲を指定してください。IP アドレス範囲に関するガイダンスやご質問がある場合は、 AWS サポート またはアカウントチームにご相談ください。 アカウントのリンク アカウントをリンクすることで、同じ基盤となる BYOL ハードウェアと管理インターフェイスを使用できます。以前アカウントのリンクは WorkSpaces API からのみ可能でしたが、WorkSpaces コンソールでリンク招待を送信することで、アカウントをリンクできるようになりました。 まとめ 新しい WorkSpaces BYOL イメージインポートプロセスの改善により、仮想化デスクトップの移行が大幅に簡素化されました。WorkSpaces の他の機能やメリットについては、 製品ページ をご覧ください。 AWS サポートチームは、これらの機能を環境に導入する際の質問に対応する準備ができています。最新のエンドユーザーコンピューティングのイノベーションについては「 What’s New with AWS 」をフォローしてください。詳細な手順とベストプラクティスについては、 YouTube プレイリスト にサブスクライブしてください。 このブログは Senior Product Manager の Brandon How、Senior Specialist Solutions Architect の Joe Jabbour と Senior Specialist Solutions Architect の Shantanu Padhye によって書かれた「 Introducing an Improved BYOL Image Import Process for Amazon WorkSpaces 」の翻訳です。 翻訳は Senior Solutions Architect の森が担当しました。

本記事は米国時間 2025 年 7 月 16 日に公開された Automate Your Development Workflow with Kiro’s AI Agent Hooks を翻訳したものです。 ソフトウェアプロジェクトが成長するにつれ、ドキュメント、テスト、コードの可読性、パフォーマンスを同期させ続けることはますます難しくなります。Kiro のエージェントフックは、こうした重要な作業をバックグラウンドで自動的に処理し、コーディング中の集中を保ちながら、毎回高品質なコードを出荷できるように支援します。 エージェント型 IDE である Kiro は、複雑なワークフローを簡素化する新しい手段としてエージェントフックを導入しました。これらのカスタム AI 駆動のトリガーは、コーディング活動にリアルタイムで反応し、テストの更新、ドキュメントの同期、コードベース全体でのコーディング規約の適用といった作業を処理します。 Kiro のエージェントフックは、受動的な AI 支援から能動的な AI 統合への根本的な転換を示しており、開発環境がニーズを予測して自動的に動く知的なパートナーへと進化します。 本記事では、Kiro のエージェントフックのセットアップ方法と使用方法を紹介し、これらのフックが開発ワークフローをどのように変革できるかを示す実践例を解説します。 Kiro のエージェントフックとは？ Kiro の エージェントフック は、ワークスペースのイベントを AI 駆動のアクションに接続するインテリジェントな自動化ルールです。開発環境における「if-then」ロジックのようなもので、自然言語 AI がコードやコンテキストを理解して動作します。つまり、Kiro のフックは、ワークスペースのアクティビティと Kiro に組み込まれた強力なエージェント機能をつなぐ橋渡しです。 フックは 2 つの主要コンポーネントから成ります: トリガー : フックを起動するイベント（ファイルの保存、編集、作成、削除など） アクション : 自動的に実行される AI 駆動の応答（コード生成、ファイル更新、ドキュメント作成など） 主な利点 タスクにユーザーの指導や専門知識が必要な場合、Kiro はマルチモーダルなエージェントチャットを通じて制御を維持します。Kiro のエージェントはコードを超えた思考を促し、難しいエンジニアリング課題を自信を持って解決できるように支援します。エージェントフックには従来の自動化を超える数多くの利点があります。 自然言語による設定 : 複雑なスクリプトではなく平易な英語でフックを定義可能 コンテキスト認識 AI : コードベースの構造を理解し、知的な判断を迅速に実行 リアルタイム実行 : 作業と同時にアクションが発生し、開発の流れを維持 協調的 : エージェントフックをバージョン管理を通じてチームと共有可能 カスタマイズ可能 : ワークフローやコーディングパターンに合わせて調整可能 最初のエージェントフックを設定する クイックスタート手順 TypeScript プロジェクトのユニットテストをコードと同期させ続けるフックを作成してみましょう。 フックパネルを開く : アクティビティバーの Kiro アイコンをクリックし、サイドバーから「Agent Hooks」を選択 フックを作成 : パネルの「+」ボタンをクリックし、 希望するフックを自然言語で記述する または既存のテンプレートから選択する 図 1: Kiro フックパネルのインターフェース。自然言語入力フィールドを使ったフック作成とサンプルプロンプトの表示 オプションを設定 : タイトル、説明、イベントタイプ、ファイルパターン、プロンプトを確認・調整 図 2: ユーザー入力に基づいて作成されたフック設定を表示する Kiro フックパネルのインターフェース フックを作成 : フックを作成すると IDE のフックパネルに表示され、 .kiro/hooks ディレクトリに対応する設定ファイルが生成されます。 { "name": "TypeScript Test Updater", "description": "Monitors changes to TypeScript source files and updates corresponding test files with tests for new functions or methods", "version": "1", "when": { "type": "fileEdited", "patterns": [ "**/*.ts", "!**/*.test.ts", "!**/*.spec.ts", "!**/node_modules/**" ] }, "then": { "type": "askAgent", "prompt": "I noticed you've edited a TypeScript file. I'll analyze the changes and update the corresponding test file. 1. First, I'll identify any new functions or methods added to the source file 2. Then I'll locate or create the corresponding test file (either .test.ts or .spec.ts in the same directory) 3. I'll generate appropriate test cases for the new functions/methods 4. I'll ensure the tests follow the project's existing testing patterns and conventions Here are my suggested test updates based on your changes:" } } フック設定オプション 一般オプション name: フック名 description: フックの説明 トリガーオプション when type: fileEdit: ファイル変更の監視 fileCreate: 新規ファイル作成に応答 fileDelete: ファイル削除イベントの処理 userTriggered: 手動トリガー patterns: GLOB パターンでファイルやディレクトリ構造を指定 アクションオプション then type: askAgent: AIエージェントに完全なコンテキストを含むカスタムプロンプトを送信する prompt: フック起動時に Kiro に取らせたいアクションを記述 フックの管理 Kiro のフックパネルでは以下が可能です。 フックの有効化/無効化 設定の編集 フックの削除 図 3: アクティブなフックと設定オプションを表示する Kiro フックパネルのインターフェース また、 .kiro/hooks ディレクトリの設定ファイルを直接編集することもできます。 実際の利用例 テスト同期 : ソースコードの変更に合わせてユニットテストを更新 ドキュメント更新 : 新機能追加時に README を自動更新 国際化サポート : ドキュメントを英語との間で翻訳 Git アシスタント : Git diff に基づく changelog 生成、コミットメッセージ補助 コンプライアンスチェック : 標準への準拠を自動確認 スタイル統一 : フォーマットやコーディング規約を自動適用 例 1: 自動テスト生成 シナリオ : Python アプリケーションを開発しており、テストをコンポーネントと常に同期させたい。 フックの説明 : You are a test-driven development assistant. The user has modified a Python source file. Your task is to: 1. Analyze the changes in the source file 2. Identify any new functions, methods, or classes that were added 3. Update or create the corresponding test file (same filename but with test_ prefix) 4. Add appropriate test cases for the new functionality 5. Ensure test coverage for the new code while maintaining existing tests, Focus on writing practical, meaningful tests that verify the behavior of the new code. Use the existing testing patterns in the project if available. If using unit test, add new test methods to the appropriate test class. If using pytest, add new test functions. 監視対象のファイルパス *.py: all the python files !test_*.py: exclude the files that start with test_ and ends with .py 何が起きるか   : Python ファイルを変更するたびに、Kiro が変更をレビューし、テストファイルを更新して新しい機能の包括的なカバレッジを維持します 図 4: Python ファイルの変更後にテストファイルを自動的に更新する Kiro エージェントフック Example 2: ドキュメント同期 シナリオ : API ドキュメントをコード変更と常に一致させたい。 フックの説明 : Monitor all my typescript files and review the API changes in workspace and update the corresponding documentation in docs/api/. Include new endpoints, parameter changes, and response formats. Maintain consistent documentation style. 監視対象のパス :  **/*.ts, **/*.tsx: all the files with ts and tsx extension. 結果 : API ドキュメントがコード変更を自動的に反映し、ドキュメントが古くなるという一般的な問題を解消します。 Kiro エージェントフックのベストプラクティス 以下は、Kiro のエージェントフックを始める際のヒント、コツ、ベストプラクティスです。 シンプルに始める ソースコード変更時にテストを更新するといった基本的なファイル間の関係から始めてください。すぐに価値を実感でき、慣れてきたらより複雑なワークフローへ発展できます。 説明的なプロンプトを使用する フックプロンプトに多くのコンテキストを提供するほど、AI が意図を正確に理解します。 // Good "Update the test file to cover the new authentication method, including edge cases for invalid tokens and expired sessions" // Better "Review the authentication changes in this file and update tests/auth.test.js to include comprehensive tests for the new authentication method. Cover success cases, invalid token scenarios, expired session handling, and ensure all tests follow our existing test patterns using Jest and supertest." ワークスペースのコンテキストを活用する プロジェクトのドキュメント、コーディング規約、パターンをフックプロンプトで参照して一貫性を維持します。 // Good "Update or create new test files to cover the new functions, make sure to include multiple tests for each function to cover different paths." // Better "Update or create new test files to cover the new functions, make sure to include multiple tests for each function to cover different paths. Look at the existing unit tests and follow the same format and use the same testing libraries used, read the package.json file to understand how we initiate the unit tests." 監視と改善 チャット履歴を利用してフックの動作を確認し、結果に基づいてプロンプトを改善してください。 図 5: 過去のフック実行を表示するチャット履歴 チームコラボレーション フックをバージョン管理にコミットしてチームと共有できます。新しく作成したフックは .kiro/hooks ディレクトリに保存されるため、すぐに共有可能です。変更をプッシュすれば、チームメイトがプルしてすぐに利用できます。これは、チームとともに成長する自動化レシピ集を共有するようなものです。 自動化の未来はフックにある Kiro のエージェントフックは、日常的な開発作業に知的な自動化をもたらし、繰り返し作業を処理することで創造的な問題解決に集中できるようにします。フォーマットの好みからデプロイ手順まで、コーディングパターンを学習し、プロジェクト全体で一貫性を維持するスマートアシスタントのように機能します。自然言語による設定で高度な自動化を誰でも利用でき、AI 駆動のアクションは知的で文脈に沿った変更をガイドします。 個人開発でも時差のあるチーム開発でも、Kiro のエージェントフックは自然にワークフローに適合します。チームは自動化レシピをコードのように共有・バージョン管理でき、プロジェクトに合わせた時間節約ツールのライブラリを拡張していけます。コードフォーマットの標準化やテスト実行の自動化といった基本から始め、慣れるにつれて複雑なワークフローへと拡張することで、スムーズで効率的な開発サイクルを実現できます。 ぜひ試してみませんか？Kiro は無料で始められ、ドキュメントには最初のフックを作成するために必要なすべての情報が揃っています。私たちは、より良いコードを効率的に書くために支援します。 X 、 LinkedIn 、 Instagram では @kirodotdev、 Bluesky では @kiro.dev をタグ付けし、ハッシュタグ #builtwithkiro を使って成果をシェアしましょう。

本記事は米国時間 2025 年 7 月 15 日に公開された From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro を翻訳したものです。 開発者であれば誰もが経験したことがあるでしょう。新しい機能やアプリケーションの素晴らしいアイデアを思いつき、お気に入りの AI コーディングアシスタントを立ち上げます。ところが…その後 1 時間を要件の洗い出しやエッジケースの明確化に費やし、コードを 1 行も書く前にコンテキストウィンドウが探索的な会話で埋め尽くされてしまいます。 Kiro という新しい IDE は、この問題を Spec-Driven Development（仕様駆動型開発） によって根本から変えます。 現在の AI コーディングアシスタントの限界 現在の AI コーディングアシスタントの限界は予測可能で非効率的なパターンに従う傾向があります。開発者が高レベルのプロンプトを与えると、AI は要件を完全に理解する前に即座にコード生成へ飛びついてしまいます。この時期尚早な行動は、「いや、実際にはこういう意味だった…」という明確化の繰り返しを招きます。初期の要件が十分に明確でなかったためです。こうした探索的対話が続くにつれ、コンテキストウィンドウは往復の議論でますます散らかり、最終的なコード生成に残るスペースは限られます。その結果、最終的なアウトプットの品質と完全性に影響が出てしまい、プロセス全体が本来よりも非効率になります。つまり、このアプローチは LLM をまずコードジェネレーターとして扱ってしまっており、本来は開発ライフサイクル全体を通して「思考のパートナー」として位置づけるべきなのです。 仕様駆動型開発: 設計意図と実装をつなぐ 難しい機能に取り組むとき、Kiro はあなたのインテリジェントな相談相手として、コードベースの理解、問題の明確化、効率的な品質解決を助けます。 Kiro と協力して、明確な要件、システムアーキテクチャ、技術スタックの考慮、実装アプローチを含む簡潔な仕様を作成できます。Kiro はすべての要件や制約を明示化し、それをコンテキストとして利用して、少ない反復回数で高精度にタスクを完了します。これこそが 仕様駆動型開発の力 です。 それでは、Kiro のアプローチがもたらす主な利点をさらに詳しく見ていきましょう。 1. 既存コードベースの理解 新開発に着手する前に、Kiro は既存コードを解析し、3 つの基礎ドキュメントである structure.md (コードベースのアーキテクチャ)、 tech.md (技術スタックとパターン)、 product.md (ビジネス文脈と要件) を生成します。これにより、チーム全員が今後の仕様策定を支える明確な基盤を共有できます。 2. プロジェクトの分析と計画 プロジェクトプロンプトを spec モードで与えると、Kiro はすぐにコーディングを始めるのではなく、要件を深く分析し、潜在的な課題を特定し、包括的な計画ドキュメントを作成します。 3. 包括的な計画ドキュメントの生成 シンプルなプロンプトから、Kiro は以下の詳細仕様ファイルを生成します。 要件分析 : プロンプトを具体的で実行可能な要件に分解 技術設計 : アーキテクチャ判断、技術選択、実装アプローチ タスク分解 : 明確な受け入れ基準を伴う粒度の細かい開発タスク 4. AI との効果的な協働 Kiro は仕様ファイルを Markdown 形式でプロジェクトディレクトリに保存します。コードが書かれる前にレビュー・編集・改善が可能になり、チームや関係者との自然なコラボレーションのチェックポイントを生み出します。 5. コーディング効率とコンテキストの最大化 実際にコーディング段階に入ると、Kiro は仕様ファイルを参照するため、探索的会話でコンテキストを圧迫することがありません。これにより、実際のコーディングタスクに最大限のコンテキストスペースを確保できます。 仕様駆動型開発の力 仕様駆動型開発は、ソフトウェアの設計・構築・維持の方法を根本から改善する重要な利点をもたらします。計画を「余計な負担」と見なすのではなく、競争優位性へと変えます。このアプローチは開発プロセスを次のように変革します。 高コストになる前に問題を発見 開発途中で要件の問題に気づくのではなく、Kiro が事前にあいまいさを特定して解消します。これによりコストのかかる手戻りを防ぎ、実装前にアラインメントが取れます。 プロジェクトの方向性を制御 仕様策定フェーズは自然な停止ポイントを作り、人間がレビュー・修正・承認できるため、リソースを投資する前に方向性を確認できます。 進捗を失わずに反復可能 要件定義でミスがあっても問題なし。仕様ファイルを修正し、実装計画を再生成できます。会話履歴をすべてやり直す必要はありません。 AI を重要な部分に集中させる 計画フェーズをファイルに外部化することで、AI のコンテキストは目の前のコーディングタスクに集中します。その結果、より高品質なコード生成が可能です。 シームレスなチームコラボレーション 仕様ファイルは生きたドキュメントとして、標準的な開発ワークフローの中でレビュー・コメント・貢献が可能です。 組織的ナレッジの構築 あらゆる決定や要件が文書化され、なぜ特定の技術選択が行われたのかという明確な監査証跡を残し、将来のチームメンバーにコンテキストを提供します。 Kiro スペックを実際に見てみよう 仕様駆動型開発を理解する最良の方法は、実際のワークフローを観察することです。新規プロジェクトでも既存コードベースでも、Kiro の体系的アプローチは堅実な基盤上で構築を可能にします。典型的なワークフローは、最初のコンセプトから実装準備の整った仕様書まで、次のように展開されます。 図1: Kiro は「仕様駆動開発」モードを使用して、要件、設計、タスクを含む詳細な出力を生成します ステップ 1: プロジェクトの開始 新機能に取り掛かる前に、まずプロジェクトのコンテキストを確立します。 ユーザー: 「このプロジェクトの steering をセットアップして」 Kiro は既存コードベースを分析し、次の 3 つの基礎ドキュメントを生成します: structure.md – 現在のアーキテクチャ、主要コンポーネント、コード構成 tech.md – 技術スタック、パターン、技術的制約 product.md – ビジネス文脈、既存機能、ユーザーワークフロー これにより、構築する対象の明確な基盤理解が得られます。 ステップ 2: プロジェクト仕様の生成 次に、構築したいプロジェクトの詳細を整理していきます。 ユーザー: 「小規模チーム向けのリアルタイム協働機能を持つタスク管理アプリを作りたい」 ここで仕様駆動型開発の真価が現れます。Kiro はフレームワーク選択や DB 設計に飛びつくのではなく、一歩下がって本当に達成したいことを理解します。既存アーキテクチャや制約を踏まえ、この新機能がどう収まるかを考えます。 Kiro は順を追って以下のドキュメントを作成します。 requirements.md – ユーザーストーリーや受け入れ基準を含む詳細な要件分解 design.md – フレームワーク、アーキテクチャ図、構造を含む技術設計 tasks.md – 実装フェーズと順序立てられたタスク一覧 図2：Kiro は3つの主要文書（要件、設計、タスクリスト）を作成します ステップ 3: レビューと改良 仕様をレビューし、例えば以下のような要件を追加できます。 ## Additional Requirements - Slack 通知との統合 - モバイル対応デザインを優先 - GDPR 準拠の考慮 ステップ 4: 情報に基づく開発 こうして Kiro がコーディングを始めるとき、参照するのは会話履歴ではなく、これらの包括的な仕様です。すべての実装判断は、文書化された要件と設計選択に基づいて行われます。 開発の未来は仕様から始まる 仕様駆動型開発は、受動的なコーディングから能動的な仕様策定への移行を意味します。これは単なるワークフロー改善ではなく、AI と協働してソフトウェアを構築する方法の根本的な進化です。AI を高度なオートコンプリートツールとして扱うのではなく、戦略的な思考のパートナーとして位置づけることで、変更コストが高くなる前により良い意思決定を行えるようになります。結果として、開発サイクルはより速くなり、コードの品質は向上し、予期せぬ事態は減少し、ドキュメントはプロセスに統合されているため後付けではなく常に最新の状態に保たれます。次に新しい機能を構築するときは、コードではなく仕様から始めてみてください。将来の自分（そしてチームメイト）はその明確さに感謝するでしょう。そして、最高のコードとは書く前に計画されたコードであると気づくかもしれません。 準備はできましたか？違いを体験してみましょう。 ウェイトリスト に参加してください。

本投稿は、 Sameer Malik とNitin Saxenaによる記事「 Getting started with Amazon EC2 bare metal instances for Amazon RDS for Oracle and Amazon RDS Custom for Oracle 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle は、クラウドでのOracle Databaseのデプロイを簡単にセットアップ、運用、拡張できるフルマネージド型の商用データベースです。 Amazon RDS Custom for Oracle を使用すると、データベース管理者はOracle Database環境とオペレーティングシステムにアクセスしてカスタマイズすることができます。 この投稿では、Amazon RDS for OracleとRDS Custom for Oracleの Amazon EC2ベアメタルインスタンス でのAWSベアメタルインスタンスのサポートについて説明します。 Amazon EC2のベアメタルインスタンスは、アプリケーションが基盤となるサーバーのプロセッサとメモリに直接アクセスできるように設計されています。Amazon EC2のベアメタルインスタンスは、非共有テナンシーモデル専用の容量を提供し、共有仮想化インスタンスと比較してより高いレベルの分離を提供します。 これらのベアメタルインスタンスは、マイクロソフトやオラクルなどのベンダーのBring Your Own License（BYOL）ライセンスモデルの対象となるソフトウェアライセンスを使用するための追加のライセンス特典も提供する場合があります。Amazon EC2のベアメタルインスタンスを使用する場合のライセンス上の利点の詳細については、AWSのライセンスパートナーであるHouse of Brickの「 Oracle Hypervisor on AWS Bare Metal 」の投稿を参照してください。 さらに、Amazon RDS for Oracleと RDS Custom for Oracle の Amazon EC2 ベアメタルインスタンスは、同じサイズの仮想化インスタンスよりも 25% 低いコンピューティングコストで提供されるため、RDS ベアメタルインスタンス上の Oracle ワークロードの費用対効果が高くなります。 EC2 ベアメタルインスタンスの一般的なユースケース EC2 ベアメタルインスタンスの一般的なユースケースは次のとおりです。 ライセンス制限のあるワークロードのサポート – 特にOracle Database、SQL Server、SAP、Windows Serverなどの従来のエンタープライズソフトウェアでは、物理コアや専用ハードウェアの方がライセンスの方が有利な場合が多いため、これが主な推進要因となることがよくあります。 ハイパフォーマンスコンピューティング（HPC）と科学シミュレーション – これらのワークロードには、最高のパフォーマンス、特殊なハードウェア機能への直接アクセス、または非常に低遅延のノード間通信が必要です。 レガシーアプリケーション – これらのアプリケーションは仮想化環境ではサポートされていないか、特定のハードウェアアクセスが必要です。 分離とセキュリティ – ベアメタルインスタンスは、共有の仮想化インスタンスと比較して高い分離レベルを提供するため、非常に機密性の高いワークロードやコンプライアンス要件に役立ちます。また、特定の企業のコンプライアンスや規制要件を満たすために、仮想化されていない環境のシングルテナントインフラストラクチャで特定のアプリケーションを実行したい場合のオプションとしても役立ちます。 Amazon RDS for Oracle, RDS Custom for Oracleで ベアメタルインスタンスを使用するメリット RDS ベアメタルインスタンスには次の利点があります。 ライセンスのメリット – RDSベアメタルインスタンスは、非共有テナントモデルにおいて完全に専用化されたキャパシティを提供するため、ライセンスは、顧客が（オラクルとの契約に応じて）従来のコア・ベースのライセンスとオラクルのプロセッサーコアファクターを適用できるオンプレミスでのデプロイに似たものになる可能性があります。 低いコンピューティングコスト – Amazon RDS for OracleとRDS Custom for Oracle の RDS ベアメタルインスタンスは、同じサイズの仮想インスタンスと比較して 25% 低いコンピューティングコストで価格設定されています。たとえば、m6i.metalベアメタルインスタンスの価格（コンピューティングコスト）は、同等のサイズの仮想化インスタンスm6i.32xlよりも 25% 低くなります。 効果的なデータベース統合 – Amazon RDS for OracleとRDS Custom for Oracleのベアメタルインスタンスのライセンス上の利点とコンピューティングコストの削減により、スキーマ統合やOracleマルチテナントオプションなど、現在サポートされているデータベース統合方法を使用して、データベースワークロードを効果的に統合できます。 特定のワークロードのパフォーマンスの向上 – Oracle Databaseワークロードを仮想環境で実行し、物理サーバー全体の半分以上のコアを使用しているお客様は、追加のライセンスコストなしで、物理サーバー全体のパフォーマンス（CPU、メモリ、IOPS、スループットなど）を利用できるようになります。 Amazon RDSコンソールを使用して、RDS for Oracleベアメタルインスタンスを作成 このセクションでは、 AWSマネジメントコンソール を使用して、ベアメタルインスタンスタイプのRDS for Oracle DBインスタンスを作成する方法を示します。詳細と前提条件については、 Oracle DB インスタンスの作成 を参照してください。  Amazon RDS コンソールにサインインします。  Amazon RDS コンソールの右上隅で、DB インスタンスを作成したい AWS リージョンを選択します。  ナビゲーションペインで、「 データベース 」を選択します。  「 データベースの作成 」を選択します。  標準作成 を選択します。   エンジンのタイプ については、 Oracle を選択します。 データベース管理タイプ については、 Amazon RDS を選択します。 エディション には、 Oracle Enterprise Edition を選択します。  ライセンス については、デフォルトの Bring Your Own License（BYOL） のままにします。   エンジンのバージョン については、ご希望のバージョンを選択します。 テンプレート セクションで、 本番稼働用 を選択してください。 DB インスタンス識別子 には、DB インスタンスの名前を入力します。 認証情報の設定 セクションで、管理者ユーザーのユーザー名を入力し、 認証情報管理 で「 セルフマネージド 」を選択して、パスワードを入力します。   暗号化キー には、任意のキーを使用します。 インスタンス設定 セクションの DB インスタンスクラスで、ベアメタルインスタンス（たとえば、db.m6i.metal）を選択します。 インスタンスの残りの作成手順を完了して、「 データベースの作成 」を選択します。 DB インスタンスを作成したら、Amazon RDS コンソールでステータスを確認できます。 AWS CLIを使用してRDS for Oracleのベアメタル・インスタンスを作成 次のコードに示すように、 AWSコマンドラインインターフェイス （AWS CLI）を使用してベアメタルインスタンスを作成することもできます。AWS CLIに必要な認証情報とデフォルトのリージョンが設定されていることを確認してください。 aws rds create-db-instance \ --db-instance-identifier metaldb \ --db-instance-class db.m6i.metal \ --engine oracle-ee \ --allocated-storage 100 \ --master-username <username> \ --master-user-password <YourStrongPassword> \ --engine-version 19.0.0.0.ru-2025-04.spb-1.r1\ --license-model license-included \ --publicly-accessible false \ --storage-encrypted \ --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \ --db-subnet-group-name my-db-subnet-group クリーンアップ RDSインスタンスの実行コストを抑えるには、上記でプロビジョニングされたRDSインスタンスを削除してください。DB インスタンスは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して削除できます。RDS インスタンスを削除する方法の詳細については、「 DB インスタンスを削除する 」を参照してください。 結論 Amazon RDS for OracleとRDS Custom for Oracle用のAmazon EC2ベアメタルインスタンスを使用すると、ライセンスの柔軟性が高まり、低コストのオプションが得られるため、Oracle DatabaseのワークロードをAmazon RDS for OracleおよびRDS Custom for Oracleで効果的に実行できます。このローンチの詳細については、「 What’s new 」を参照してください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

このブログは 2025 年 9 月 2 日に Tom Tasker と Danny Johnston によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェア攻撃は現代組織において取締役会レベルで優先課題となっています。データは次の明確な傾向を示しています: ランサムウェアのパンデミック発生以降、攻撃件数は 2 倍以上に増加し、特に金融サービス業界は標的となってきました。AWSでは、グローバルな金融サービスのお客様、規制当局、統制機関、業界パートナーとの分野横断的な連携により、 Cloud Hosted Data Vault (CHDV、略称ボールト) の認定アーキテクチャを確立しました。 大規模サイバー攻撃発生時の業務継続性強化において、ボールトは重要な検討事項です。ボールトは組織の最も重要な資産を隔離した最終防衛ラインとして機能し、従来の高可用性 (HA)、事業継続 (BC)、災害復旧 (DR)、バックアップによる復旧ができない場合においても、事業の再構築を可能にします。既存の運用レジリエンス対策にボールトを組み込むには、多角的で綿密な計画が必要です。本記事では、その計画上の考慮事項と、既存の HA、BC/DR、バックアップソリューションにさらに保護レイヤーを追加する方法を解説します。技術導入だけでなく、ボールトを機能させるための人的要素、プロセス、実践的要素に関する重要な検討事項にも焦点を当てます。 1. 何をボールトに組み込む必要があるか？ どんな事業部門の責任者も、全て、あらゆるものを組み込む必要がある、と言うでしょう。しかし、全てボールトに含める必要があるわけではなく、少なくとも即座には必要ないです。大規模なサイバーインシデントを考える際、全てのデータ、アプリケーション、サービスを重要かつボールトに保管必須とラベル付けしたくなる誘惑に駆られます。必要でなければ本番環境に存在しないはずだ、と考えるかもしれません。しかし、初期の精査なしに全てを保護しようとすると、膨大なデータ量、コスト、意図しない復旧遅延を招く可能性があります。 真のサイバーインシデント発生時には、事業再開に不可欠な中核的な IT 機能と運用サービスを、12 時間後、24 時間後、48 時間後に再開すべきか自問する必要があります。同様に重要なのは、不要なものは何かを見極めることです。これらは「最小限の事業継続機能 (Minimum Viable Business: MVB)」とも呼ばれ、お客様だけでなく二次、三次、四次関係者にも提供される中核的な機能とサービスです。 Figure 1: 何をボールトに組み込む必要があるか？ – 主要な IT 機能と運用サービスに焦点を当てる。 この問いは一夜にして答えが出るものではありません。ボールトは単なる技術的なソリューションではなく、多くの分野からの意見が関わります。MVB を特定し、それを最善の方法で保護するには、IT、セキュリティ、法務、事業部門責任者、アプリケーション責任者、経営幹部など、複数のチームからの意見、経験、知識が必要です。 2. 復旧とはどのような状態を指すのか？ サイバー攻撃は、標準的な運用復旧メカニズム (HA、BC、DR、バックアップ) を通じてシステムやサービスをオンラインに戻すことを困難、あるいは不可能にするよう設計されています。悪意のある攻撃者が身代金を確保するためには、復旧可能性を最小限にした上で最大限の混乱を引き起こすことです。大規模なサイバー攻撃に対しては、通常の運用復旧方法のみに依存することはできず、事前に検討すべき重要な考慮事項がいくつか存在します: 決定時間目標 (DTO) : ボールトから復旧するまでにどれだけの時間がかかるか、定義する目標です。セキュアで信頼できる環境における高度に自動化された復旧プロセスが侵害を受け、その結果、信頼性に不確実性が生じたり、破壊的な行為により完全に使用不能な事態が発生したとします。ボールトから完全または部分的にいつまでに復旧することが必要か、関係者と主要な意思決定ポイントを調整することが極めて重要です。 サイバー復旧時間目標 (C-RTO) とサイバー復旧時点目標 (C-RPO) : サイバーイベントの影響拡大と復旧時間を考慮して、復旧時間の期待値を調整します。従来数秒で済んだ復旧が数日かかる可能性があり、企業はサイバーインシデントに対応する方法を把握する必要があります。 最低限許容可能なサービス提供 (MASO) : MVB が事業活動に焦点を当てる一方、MASO は顧客や第三者に対して提供すべき許容可能なサービス水準を問うものです。これは主要サービスの機能制限版、あるいは代替手段でアクセスするバックアップシステムとなる可能性があります。 Figure 2: 復旧とはどのような状態を指すのか？ – 通常数秒で完了する処理が数日かかる場合があるため、事前に計画を立てる。 3. ボールトをどのように分割するか？ 単一のボールトに全てを統合するか、サービスごとにボールトを設けるかに関わらず、管理性、実用性、セキュリティのバランスを取ることが鍵となります。 簡素性 : ボールトは理解、操作、復元が可能な限り明確になるように保ちます。複雑さは遅延を生みます。 独立性 : 各ボールトは単独で機能し、待機時間を最小化し並列処理を促進します。 サービスマッピング : 復元の開始点はどこか、最適な復元順序は何か把握します。 役割と責任 : 責任者と管理者はサービス、アプリケーション、インフラストラクチャごとに割り当てられます。 保守 : アプリケーションの更新やビジネスユースケースの変化に伴い、ボールトも変化します。 Figure 3: ボールトをどのように分割するか？ – 管理性、内容、復旧プロセスのバランスをとる。 AWS が提供する柔軟性は、技術的負債を残すことなく、テスト、失敗、改善を繰り返しながら最適解を見つけることを可能にする点で非常に価値があります。ホワイトボード上でうまく機能したものが、最初の机上演習で失敗することもあり、そこから得た教訓は次のボールトでの試行に反映できます。ビジネスに適応する柔軟性を持つことで、ソリューションと復旧プロセスへの信頼性が向上します。ボールトに格納されるものは単なる「データ」の問題ではないです。—アプリケーションの責任者や事業部門からの意見が必要です。 4. ボールトをどのように管理するか？ ボールトは運用環境から切り離す必要があります。これにより、本番環境を横方向に移動するサイバー攻撃はぼーるとの入口で遮断されます。このレベルの分離がなければ、サイバー攻撃時にボールトも侵害される可能性があります。従来のエアギャップ方式では、メディアの抜去や物理的分離により、保護機構と運用環境の間に文字通りの空気の隙間 (エアギャップ) を設けていました。この隔離をクラウド環境とボールトにどう適用すべきでしょうか？クラウド上で同様のセキュリティ対策を実現するには以下の要件が必要です: イングレスゾーン : アクセス可能な時間帯にのみ利用可能な一時的な領域、サービス、機能。 多要素認証 : 許可された担当者だけがアクセス可能な物理トークン。 ゼロトラスト : あらゆる段階での認証。 AWS Identity and Access Management (IAM) : 制限された役割と責任。 変更管理 : トークンとアカウントへの承認済みアクセスを処理するプロセス。 Figure 4: ボールトをどのように管理するか？ – 可視性を維持しつつ意図的に隔離する。 5. 物流とサービスプロバイダーについてはどのように計画するか？ サイバーインシデントへの対応策を検討する際、物理的な解決策は見過ごされがちです。中核となるサービス、アプリケーション、基盤インフラに焦点を当てることで、それらを復旧させる方法を考える際に周辺的な物理的依存関係が焦点から外れてしまいます。例えば: 内部および外部ネットワークへのアクセス : 災害が発生しなくてもサービス中断を引き起こす接続障害だけで十分ニュースになります。 ソフトウェアリポジトリ : 自動化されたソフトウェアデプロイとは、デジタル依存関係なしに取得できる、引き出しに置かれた USB スティックなどの物理メディアを意味します。 サプライチェーン : 物理機器が機能不全に陥った場合、必要な場所に大量のハードウェアを調達する計画とプロセスはありますか？ 物理的な物流: : 大規模なイベントに対して大規模な対応が必要な場合、人員、設備、作業スペースをどう確保しますか？ Figure 5: 物流とサービスプロバイダー – 計画を外部依存関係まで拡大する。 サイバー攻撃の高度な手法では、個々の障害が通常の業務運営において想定され、かつ、影響も最小限であるような障害を複数強制的に発生させます。これらの障害が大規模に発生すると、複合的な影響をもたらし、複雑性と復旧の遅れを増大させる可能性があります。 6. ボールトに関するプロセスは誰が責任を持つのか？ 責任者は、ボールトに関するプロセスと管理を持ち、ベストプラクティスを提供し、復旧が必要な際には最前線に立つことになります。どのチームがボールトを責任を持つか決定することは極めて重要で、必ずしも単純な作業ではありません。ボールトの基本原則は、保護・計画・プロセスという多面的な要素をカバーするという事実に基づいており、これらには単一チームではなく、複数の部門からの意見が必要となります。 復旧の優先順位付けは、依存関係、コンプライアンス要件、ビジネスへの影響に関する理解に基づき、バックアップチームではなくビジネスステークホルダーが主導すべきです。効果的なサイバー復旧計画には、技術チームとビジネスチーム間の明確なコミュニケーションが不可欠です。 Figure 6: 人とプロセス – この2つの要素のバランスを取ることが優れた実践を推進する。 この部門横断的な協力の結果として、企業が採用し遵守しなければならない復旧計画が策定されます。しかし、バッドプラクティスにつながる可能性のある硬直的なアプローチにより、サイバーイベント復旧シナリオの質が意図せず低下する可能性があります。過度に負担の大きいプロセス、俊敏性の欠如、そして最も当たり障りのない方法を選ぶという傾向により、最良の計画が実装されない可能性があります。これはセキュリティと復旧手順には即座に影響しません。しかしながら、ボールトの原則が適用されていないことに気付く最悪のタイミングは、それらが必要な時です。サイバーイベントからの効果的な復旧を確実にするためには、組織は日常業務にベストプラクティスをシームレスに統合する必要があります。この統合には、堅牢な復旧要件と、チームがセキュリティや効率性を損なうことなく一貫して従うことができる実用的で持続可能なプロセスとの間の絶妙なバランスを取ることが必要です。 7. なぜスポンサーが必要なのか？ 組織に追加業務を導入することで、コストと苦労は確実に増大し、他の事業開発から時間とリソースを奪うことになります。時間、資金、人的リソースを消費する技術ソリューションが収益をなぜ生み出さないのか、と最高財務責任者 (CFO) なら疑問に思います。企業は、ボールトと積極的に中核業務に組み込もうとしないでしょう。したがって、その本質的価値と活用事例を理解することが極めて重要です。経営陣レベルのリーダーシップによる「トップダウン」アプローチによってのみ達成可能です。 Figure 7: スポンサーシップ – トップダウンアプローチにより、事業全体を導く。 AWS で始めましょう AWS はランサムウェア攻撃に対する多重防御層を提供します。複数の AWS データサービスにわたる即時データ保護のため、 AWS Backup は不正な改ざんの防止だけでなく迅速な復旧オプションも可能な イミュータブルバックアップ と論理的なエアギャップを備えた集中管理型バックアップ管理を提供します。 バージョニングとObject Lock を備えた Amazon S3 、および Amazon FSx for NetApp ONTAP は、重要データのための改ざん防止ストレージ機能を提供します。 検知においては、 Amazon GuardDuty が不審な活動を監視し、 AWS Security Hub が包括的なセキュリティ状況を可視化します。 Amazon Macie は標的となる可能性のある機密データを特定し、 AWS Shield と AWS WAF は初期の攻撃になりうる DDoS 攻撃や Web エクスプロイトから保護します。 AWS Network Firewall はネットワークレベルで悪意のあるトラフィックをフィルタリングします。 elastio などのパートナーは AWS Backup と連携し、組織がほぼリアルタイムでデータの整合性を検証できるようにします。これにより、ダウンタイムとデータ損失を最小限に抑えながら、あらゆる事象から完全な復旧を実現します。 アイデンティティ保護のため、 AWS IAM で最小権限アクセスを実装し、 AWS Organizations でアカウント横断的なセキュリティポリシー管理を実現します。 AWS Config と AWS CloudTrail は構成変更と API アクティビティの可視性を提供するため、インシデント後のフォレンジック分析に不可欠です。 まとめ サイバー攻撃、特にランサムウェア攻撃は年々増加しています。偶発的なインシデントから標的型攻撃に対する防御への移行は、企業と経営陣が迅速に対応転換する必要があることを意味しています。これは、深刻ではあるものの現実的に起こりうる事象が、サービスを麻痺させるだけでなく、事業を永久に閉鎖させるリスク範囲を小さくするためです。増加するサイバー攻撃への技術的ソリューションは対策の一環ではありますが、全てではありません。標的型攻撃への対応策を計画することは、日常業務で慣れ親しんだ固定観念を取り除く一環でもあります。サイバーイベントは日常業務ではないため、重要な決定をその場しのぎで行うことがないように、適切な準備と計画が必要です。効果的なサイバーレジリエンスには、組織全体にわたる包括的なアプローチが不可欠です。まず自社の業務運営において「復旧成功」の定義を明確にし、詳細な計画を通じて最悪のシナリオを想定した準備を進めます。これらの計画は定期的に見直し、復旧プロセスや手順が実際に機能することを確認するため、徹底的なテストと検証を実施してください。最も重要なのは、サイバーレジリエンスが IT 部門の枠をはるかに超える課題である点です。これは本質的に全社的な取り組みを必要とするビジネス上の課題です。運用部門や財務部門から経営陣、現場スタッフに至るまで、あらゆるチームがレジリエンス構築とインシデント発生時の復旧において重要な役割を担います。成功は「CEO からシステム管理者まで」組織全体でサイバーレジリエンスを共有責任とすることにかかっています。 <!-- '"` --> Tom Tasker Tom は Amazon Web Services のグローバル金融サービス部門に所属するストレージソリューションアーキテクトです。彼は世界最大かつ最も影響力のある金融サービス企業、規制当局、パートナーと連携し、AWS ストレージプラットフォームと統合し、同プラットフォーム上で稼働するソリューションの推進に取り組んでいます。 Danny Johnston Danny は Amazon Web Services において、グローバル金融サービス向けストレージ事業開発チームを率いています。エンタープライズ向けストレージソリューションを専門とする経験豊富な事業開発プロフェッショナルであり、顧客や規制当局との戦略的パートナーシップ構築を推進しています。金融サービス組織がデータインフラを最適化し、デジタルトランスフォーメーションの取り組みを加速させる支援に情熱を注いでいます。

2025 年 9 月 3 日に東郷記念館東京で開催された「AWS for Software &amp; Technology | Builders Forum Tokyo – AI Agent 時代の SaaS」のイベントについてレポートします。本イベントの全セッション資料は こちら です。 本イベントは現地参加・オンライン参加合わせて 300 名以上の方にご参加いただきました。参加者からは「AI エージェント時代の SaaS について具体的な実装例が聞けて非常に参考になりました」「セキュリティや可観測性の観点からの実践的なアドバイスが有用でした」などの感想をいただきました。これから AI エージェント技術を導入してみたい方、すでに利用しているがさらに活用したい方、それぞれの皆様にご参考いただける情報をご紹介させていただきました。 このイベントは、AI エージェント時代の SaaS をテーマに、 SaaS 提供者が今すぐに AI エージェントを AWS とともに取り組み始めるべき理由、既に AWS で AI エージェントに取り組まれているお客様事例、そして SaaS サービスへの AI エージェント導入のために必要な、テナントを考慮した全体像、オブザーバビリティ、セキュリティ、が紹介されました。 キーノートセッション キーノートセッションでは、AWSジャパン 常務執行役員 デジタルサービス事業統括本部長 佐藤有紀子による開会の挨拶から始まり、AWSジャパン デジタルサービス技術本部 本部長 塚田朗弘と、一般社団法人日本 CPO 協会 – 代表理事 / 株式会社 LayerX – Product Strategy のワカマツ様からはグローバルな AI エージェント導入トレンドと、企業が今すぐ取り組むべき理由について 「いつ始めるべきか？今日ではなく、昨日です！」 というメッセージと共にお話しいただきました。塚田からは AWS の日本の未来への投資内容、AWS AI スタック全体を通じた本番グレードの AI エージェント基盤としての AWS のケイパビリティ、SaaS 領域での支援実績と 我々が既にお客様と一緒に Agentic AI の世界を作っていく準備ができている ことを力強く説明しました。 いつ始めるべきか？今日ではなく、昨日です！ お客様事例: フリー宇佐美ゆう様「SaaS × AI Agent 未来 – freee が AWS で築く AI Agent 基盤」 フリー株式会社様からは、AWS 上での AI エージェント基盤の導入事例について技術選択の意思決定、セキュリティ視点で詳細にご紹介いただきました。 実装例としてご紹介いただいた「まほう経費精算」では、チャットベース UI での正確な申請により経費申請者の負担を極小化させることを目的としており、デモを踏まえてご紹介いただきました。システムの安定稼働、コスト効率、品質向上等の整備が急務であり、そのために LLM Observability による評価基盤の重要性についてご説明いただきました。 会計業務の自動化を目的として AI エージェントを導入し、ユーザーの業務効率を大幅に向上させることに成功されています。特に、マルチテナント環境でのデータ分離とセキュリティ確保、リアルタイムでの処理性能最適化、ユーザー体験の向上などの技術的な課題をどのように解決されたかについて具体的な実装例と共にお話しいただきました。AI エージェント基盤の選定理由や全体の構成について非常に参考になるため是非資料をご覧ください。 お客様事例: kubell 藤井 謙太郎様「BPaaS におけるヒトと協働する前提の AI エージェント開発」 株式会社 kubell 様からは、短期と長期で目指されている BPaaS と AI エージェントについてご紹介いただきました。AI エージェントによる業務実行は、処理結果の再現性がない、サービスレベルをわかりやすく設定困難などの課題があり、ヒトによる業務代行は属人性やスケーリングの障壁などの課題があります。両者の良いところを受け入れつつ協調型からの発展をスケーリングできる仕組みと領域を選定する、ということを短期で目指されています。現在、経費精算エージェントで、人間のアシスタント、自律 AI エージェント、ワークフロー型 AI エージェントが協調する構成を検証されており、ドメイン知識と企業別のコンテキストをマルチテナントでどのように取り扱うのかがポイントであるとご説明いただきました。現実的な AI エージェントの導入のロードマップが非常に参考になるためぜひ資料をご確認ください。 お客様事例: エムオーテックス 小沼 祐貴様「開発チーム全員で AI の世界に飛び込む！〜全員参加で進めた Amazon Q Developer 導入物語〜」 エムオーテックス株式会社様からは、チーム生産性を向上させる取り組みについてご紹介いただきました。 組織として、チーム生産性の効果測定指標の検討、PoC、勉強会＆ハンズオン、利用推進活動、報告会、等を設計され、組織に全員参加で AI コーディングエージェントを導入するための全体像を作成されました。アンケート結果から業務効率化の改善は PoC 期間の活用だけでも、600時間/月 だったとのことです。 多くの企業様では一部の社員のみで AI が活用され、全社的に広まっていかない、効果がわからないので投資判断できない、といった声を聞くことがありますが、エムオーテックス様では全員参加で利用推進の施策を取って取り組まれており、非常に参考になる社内導入の進め方ですので資料をご覧ください。 AWS テクニカルセッション: 「SaaS アーキテクチャの設計思想 AI – Agent との共創」 AWS ソリューションアーキテクトの福本より、AI エージェントと SaaS の協調アーキテクチャについて、マルチテナント環境で AI エージェントを実装・運用する際の考慮点について紹介しました。クォータ管理、テナント別プロンプト管理の効率化、監視、セキュリティ、そしてリソース使用量の最適化など、広く課題とその解決アプローチについて整理しました。 AWS テクニカルセッション: 「SaaS 開発者のための AI Agent Observability」 AWS ソリューションアーキテクトの桂井より、AI Agent の振る舞いを適切に監視・分析するためのアプローチについて紹介しました。AI Agent を活用した SaaS アプリケーションにおいて、可観測性（Observability）の確保はマルチテナントごとの精度向上、セキュリティの両面で重要な要素であり、福本の SaaS x AI エージェントセッション、後続の加治のセキュリティセッション両方に取って重要です。フリー様からも Langfuse の活用の重要性について説明いただいていることから実用上非常に重要であることが理解できます。本セッションでは AWS が AI エージェントの Observability のためにどのような仕組みを提供しているのかをわかりやすく解説しました。 AWS テクニカルセッション: 「SaaS 開発者のための AI Agent Security」 AWS ソリューションアーキテクトの加治より、AI エージェントを安全に運用するための包括的なセキュリティプラクティスについて説明しました。AI エージェントにおいても引き続き多層的なセキュリティ対策が重要であり、一般的な Web セキュリティ、SaaS セキュリティ、AI セキュリティについて包括的に考慮するための考慮ポイントを整理しました。Amazon Bedrock AgentCore Runtime、Amazon Bedrock AgentCore Identity などにも触れて本番環境のセキュリティについて概要をお伝えしました。 ワークショップ L200: マルチテナント SaaS &amp; AI エージェント 入門ワークショップ AWS ソリューションアーキテクトの後藤から初学者向けの AI エージェントのワークショップを開催しました。ハンズオン形式で資料に沿って最も初歩的なチャットエージェントから徐々に Amazon Bedrock Knowledge Bases を用いた RAG の追加、マルチテナントプロンプト管理、などの少し発展的な内容までを取り扱いました。 L400:&nbsp; Model Context Protocol Security on AWS AWS ソリューションアーキテクトの赤澤から Model Context Protocol の概要、包括的なセキュリティの考慮ポイントと対策案、について座学を実施し、そのあとはモクモク形式で参加者のペースに合わせてハンズオンを実施いただきました。MCP 含む AI エージェントのセキュリティは既に実用化のフェーズに至っているお客様にとっては喫緊の課題です。それらに対して包括的な視点から今回は MCP に特化して情報を提供しました。 ネットワーキング ご紹介したセッション・ワークショップ以外にも、現地参加ならではの体験として、ブース展示やネットワーキングパーティを実施しました。ブースにご出展をいただきましたkubell 様、セーフィー様、フリー様、また、ネットワーキングパーティ中に開催したライトニングトークにご登壇をいただきましたエクサウィザーズ様、ゼンリンデータコム様、ユーザベース様、弁護士ドットコム様、Techouse 様、ご協力をいただきありがとうございました。 おわりに 今回のイベントでは、AI エージェント時代における SaaS をテーマにグローバル動向、AWS からのキーメッセージ、お客様の事例、ソリューションアーキテクトからの技術セッションを紹介させていただきました。AI エージェントは急速に進歩しており、SaaS 業界においても新たな価値創出の機会が広がっています。AWS では、日本への継続的な投資、各種プログラム提供、Amazon Bedrock をはじめとする AI サービスを通じて、皆様の AI エージェント導入を継続的に支援してまいります。

こんにちは！Girls Meet STEM in AWS 運営メンバーの守田と嶋田です！ 私たちは普段、アマゾン ウェブ サービス ジャパン合同会社 (以下、AWS) でソリューションアーキテクトとして働いています。 イベント概要 2025 年 8 月 8 日、AWS は「Girls Meet STEM」に参加し、東京都品川区の目黒オフィスにてイベントを開催しました。 「Girls Meet STEM」は、公益財団法人山田進太郎 D&amp;I 財団が大学や企業と協力して実施するツアー形式のプログラムです。中高生女子が STEM（科学・技術・工学・数学）分野で働く人や STEM 分野で学ぶ学生、実際の現場に触れることで、将来の可能性を広げる機会を提供します。 今回のイベントには約 40 名の中高生が参加し、生成 AI 体験ワークショップや、オフィスツアー、AWS 社員によるパネルディスカッションを通じて、IT に関わる仕事の面白さや魅力についてお伝えしました。ワークショップにおいてはそれぞれ独創的なアイデアのアプリケーションを作成し、休憩時間中にも AWS 社員と進路選択や仕事の内容について質問するなど、イベント全体を通じて参加者の好奇心と熱意が際立っていました。 プログラム詳細 1. 生成 AI 体験ワークショップ 生成 AI 体験ワークショップでは、AWS の有志を中心に開発された生成 AI アプリケーションである「 Generative AI Use Cases (GenU) 」を使用しました。GenU では「AI チャット」や「翻訳」など、一般的な生成 AI ユースケースがデフォルトで搭載されています。これに加えて、「ユースケースビルダー」という機能もあり、これを使うと独自の AI ユースケースを簡単に開発することもできます。 1 人 1 台の PC および GenU のアカウントをお渡しし、参加者それぞれが「どんな AI ユースケースがあったら嬉しいか？」を考えて、独自の AI ユースケースの開発に取り組みました。 例えば「晩ごはんレシピ作成アシスタント」に今日作りたいメニューのレシピを提案してもらいたいと思った場合は… タイトル 説明 プロンプトテンプレート を考えて、以下のように入力します。 ※実際のユースケースの作成ではモデルのパフォーマンスを最適化するプロンプトを作成する点に注意する必要があります。 ユースケースを作成すると、以下のような画面で利用できるようになります。 例えば、「今日の晩ごはんにはオムライスが食べたい！」と思った場合は… このようにレシピを提案してもらうことができます。材料についても記載されるので、すぐにお買い物に行くことができますね。 ※ GenU のユースケースビルダーの詳細については、ブログ「 生成 AI アプリをノーコードで作成・社内配布できる GenU ユースケースビルダー 」をご覧ください。 シンプルに取り組める内容でありながら、内容としては「ユーザーの入力を定義する」「生成 AI に与えるシステムプロンプトを定義する」といった、アプリケーション構築の際にポイントとなる点を体験いただきました。 参加者は自由な発想で開発に取り組み、「現代文を古文にしてくれるアプリ」や「献立を考えてくれるアプリ」「平方完成を実行するアプリ」といった日々の学習や生活に役立つものから「しりとりで使える単語を提示してくれるアプリ」といった遊び心に溢れたものまで、さまざまなアプリを作成していました。 ワークショップの最後には、グループ内でそれぞれ作ったアプリケーションを発表する時間を設けて、「生成 AI に計算をさせることができた」「最新の作品の名前を答えることはできなかった」といった、学びを共有してもらいました。 「生成 AI でこんなことができるんだ！」という驚きだけでなく、自分でアプリケーションを作ってみるという体験から「考えたアイデアをアプリケーションという形にしていく楽しさ」を感じてもらいました。 2.&nbsp; オフィスツアー AWS 目黒オフィスのツアーを実施しました。植物がたくさん生えているフロアを見学した際には、「(南米の) アマゾンみたい！」「緑が多い！」という感想が出るなど、 オフィスのユニークさを体感してもらいました。 オフィス見学に加えて、AWS を使って実現されているスマートファクトリーのロボットや、普段は目にすることがないサーバーなどの展示を見た参加者は熱心に社員の説明を聞いていました。 3. AWS 社員によるパネルディスカッション AWS で活躍する 4 名の女性社員が登壇し、自身の学生時代の経験や、文理や進路を選択する際に考えていたこと、なぜ今の仕事を選んだのか？等についてお話ししました。参加者からも積極的な質問があり、「理系科目の勉強はどうやっていた？」「学生時代にどんなことをしておいたらいい？」「部長は経験しておくべき？」などの、将来のために今何をしておくべきか？という観点での疑問に関してディスカッションを行いました。 参加者からは、「文理を選ぶきっかけになったことや、学生時代にやっておいた方がいいことを知ることができてよかった」という感想がありました。 参加者の声 「普段AIを使うことはあっても、自分でAIアプリを作れるとは思っていませんでした。実際に挑戦してみると、とても楽しく、新しい発見となりました」 「文理選択を控えて進路に悩んでいた時期だったので、AWS 社員の方々の経験談を聞けたことが貴重な機会となりました。特に、文理を問わず英語力が重要だということや、IT の仕事の具体的な内容を知ることができ、将来の選択肢が広がりました」 「実際の企業のオフィスを見学させていただき、働く環境の雰囲気を体感できたことが印象的でした。社員の方々が生き生きと働いている姿を見て、会社で働くことへの印象が大きく変わりました。また、社員の方々が丁寧に質問に答えてくださり、とても充実した体験となりました」 AWS メンバーの声 「生成 AI ワークショップでは、社員の想像以上に多様なアイデアが生まれており、中高生の皆さんの発想力の素晴らしさに感銘を受けました！全体を通して、IT に良いイメージを持った、選択肢の幅が広がったという声をもらい、中高生の皆さんが将来について考える助けになれたことがとても嬉しいです。」 「休憩時間も AWS 社員と会話したり、質問したりしてくれる参加者の方が多く、社員との交流も楽しんでもらえて嬉しかったです。参加者の皆さんから学生生活の様子を聞いて、私も自分の学生時代を振り返る貴重な機会となりました。今回のイベントで、STEM や IT といった分野に興味を持ち、将来について考えるきっかけとなれば幸いです。」 &nbsp; 著者について 嶋田 朱里 (Shimada Akari) Amazon Web Services Japan G.K. のソリューションアーキテクトとして、金融業界のお客様を中心に技術支援を行うほか、Girls Meet STEM in AWS の運営メンバーとして活動しています。 守田 凜々佳 (Morita Ririka) Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心に、AWS をご利用になるお客様を技術面でサポートしています。好きなサービスは Amazon QuickSight です。週末はヴァイオリンの演奏を楽しんでいます。

イベント概要 半導体業界をリードする企業の皆様をお迎えし、「EDA on the Cloud – Tokyo」を開催します。オンプレミスからクラウドへの移行に悩むお客様に対し、AIとHPCが融合したEDAワークロードの未来、EDAに最適化されたAWSサービスやロードマップ、そして革新的な生成AIの活用など、EDA領域におけるクラウド活用のすべてをご紹介します。 本イベントはアメリカ、ロンドン、韓国、台湾で開催しているイベントの日本開催となり、アメリカよりAWSのEDAソリューションに精通したエキスパートが来日しプレゼンテーションを実施します。またAWS パートナーによる EDAのクラウド活用に関する最新動向と最先端の取り組みを紹介します。 開催日時 2025年9月16日（火）10:00 – 18:00 (9:30 開場) 開催場所 〒153-0064　東京都目黒区下目黒1-8-1　ARCO TOWER 14F JR線・東急目黒線・東京メトロ南北線・都営地下鉄三田線 目黒駅より徒歩約5分 [ googlemapで開く ] [ ARCO TOWERへのアクセス方法 ] ※入退館等詳細は別途ご連絡いたします 参加対象者 このイベントは、クラウドアーキテクトやエンジニアから、ディレクター、CTOまで、あらゆるレベルの技術リーダーやビルダーを対象としています。 プレゼンテーションでは、技術ソリューションやその実装方法、業界への影響に焦点を当てますのでクラウド上でのEDAワークロード実行における最新トレンドを把握したい方や、他社事例を参考にしたい方、EDA領域におけるAWSの実装方法に興味のある方など、多くの方にご参加いただけます。 特に以下のような方々に最適なイベントとなっております： 半導体設計におけるクラウド活用を検討されている方 EDAワークロードの最適化やコスト削減に取り組まれている方 クラウドベースの設計検証環境の構築を目指している方 大規模なEDAジョブの効率的な実行方法を模索されている方 セキュアなクラウド環境でのIP管理に関心のある方 本イベントでは、業界をリードする企業の実践事例や、最新のクラウドソリューション、そして将来的な技術展望まで、幅広いトピックをカバーいたします。また、専門家との質疑応答セッションもご用意しており、具体的な課題解決のヒントを得ていただける機会となっております。 ぜひこの機会に、次世代の半導体設計インフラの可能性を共に探求してまいりましょう。 定員 40名 （参加費無料） 参加申し込みについて 席数が限られているため、AWSの担当営業を通してのお申し込みを受け付けております。 担当営業が不明のお客様は こちら までお問い合わせください。 プログラム内容 時間 内容 9:30-10:00 受付 10:00-10:10 オープニング 10:10-10:40 The Future of EDA and AI Enhanced HPC for EDA workloads (クラウドにおけるEDAとAIによるHPCの将来 ) Ala Abunijem, Principal HPC GTM Specialist, AWS 10:40-11:10 AWS Services for EDA and optimized EC2 instances roadmap ( AWSのEDAサービスとEDAに最適化されたEC2インスタンスのロードマップ ) Allan Carter, HPC/Semicon Principal Special SA, AWS 11:10-11:40 The Future of EDA with GenAI (生成AIによるEDAの未来) Jhen-Wei Huang, Principal Specialist Solutions Architect, Hi-Tech Electronics &amp; Semiconductor, AWS 11:40-13:00 昼休憩 13:00-13:35 AWS FSx for Semiconductor NetApp様：「革新的な半導体設計を支えるAmazon FSx for NetApp ONTAPの力」 ネットアップ合同会社 AWS SE Support シニアクラウドソリューションアーキテクト 藤原 善基 様 13:35-16:25 EDA パートナーセッション (アルファベット順) AMD 様：「AMD EPYC チップレットアーキテクチャを知ると使ってみたくなる」 日本AMD株式会社 コマーシャル営業本部 セールスエンジニアリング担当 シニアマネージャー 小林 宏行 様 Cadence 様：「半導体設計のためのCadence OnCloudソリューション」 日本ケイデンス・デザイン・システムズ社 テクニカル・ビジネス・デベロップメント グループディレクター 佐藤 伸久 様 Intel 様：「HPC・EDAワークロードに最適！ インテル® Xeon® 6プロセッサー6700/6900Pシリーズ概要」 インテル株式会社 パートナー事業本部 ソリューションパートナー営業統括部 営業部長　紀ノ國 雅貴 様 Siemens EDA 様：「 Powering Next-Gen Chip Design: Siemens EDA Cloud Solutions × AWS Strategic Collaboration」 シーメンスEDAジャパン株式会社 技術本部 技術本部長 丁子 和之 様 途中休憩を含みます 16:25-18:00 AWS からのお知らせ、クロージング ネットワーキング（参加者同士の情報交換や、パートナー様やAWSメンバーへのご質問の時間としてご活用ください） アジェンダや参加パートナー企業は変更となる可能性がございます。 一部のセッションは英語での提供となりますが、通訳を手配する予定です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。既に夏休みを取られた方もいらっしゃるのではないかと思います。アウトドアでアクティブに過ごした方も、涼しい部屋でゆっくりリフレッシュできた方も、それぞれの“最高の休暇の使い方”があったのではないでしょうか。実はこの「自分に合った活用法を見つける」感覚、生成AIにピッタリ重なります。今週の週間生成AI with AWSでも、あなたの“生成AI活用体験”がさらに一歩進む情報をお届けします。 8月22日に、LLMの基礎からRAG、AIエージェントまで網羅し、ハンズオンで実践力が身につく書籍「 AWS 生成 AI アプリ構築実践ガイド 」が出版されました。基礎理解から応用・実装方法までしっかり学べる内容となっていますので、ぜひ読んでみてください！ また、先日新たに2つのプランが追加された「 AWS ジャパン生成 AI 実用化推進プログラム 」も、たくさんのお申し込みをいただいています。企業やプロジェクト単位でもまだまだ募集中ですので、この機会にご活用いただけますと幸いです。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース ブログ記事「Kiro と Model Context Protocol (MCP) で開発生産性を解き放つ」 Kiro IDE と Model Context Protocol (MCP) の統合により、開発者は既存のツールやサービスとシームレスに連携しながら AI を活用した開発が可能になります。ブログでは GitLab との統合例として、GitLab のIssueを自動的に読み込んで Kiro の仕様駆動開発機能で要件ドキュメントや設計書を生成し、実装可能なタスクリストまで自動作成する流れが紹介されています。これにより開発者はコンテキストスイッチに費やす時間を大幅に削減し、コード作成やアーキテクチャ設計といった本質的な開発作業により多くの時間を集中できるようになり、チーム全体の生産性向上と品質の高いソフトウェア開発が実現されます。 ブログ記事「Kiro の料金プランが公開されました」 Kiroが正式に料金プラン体系を発表し、Amazon Q Developer サブスクリプション非所有者向けの新しい料金モデルの提供を開始しました。無料プランでは月50件のVibeリクエストが利用可能で、全ユーザーに対して14日間有効な100件のSpecリクエストと100件のVibeリクエストのウェルカムボーナスが提供されます。有料プランとしてPro、Pro+、Powerの3つのオプションが用意され、ユーザーは自身の利用パターンに合わせて最適なプランを選択できます。また、使用状況の監視や支払い管理が可能な新しいダッシュボードも導入され、よりフレキシブルな利用が可能になりました。 ブログ記事「Amazon Q Developer CLI を使用した運用のトラブルシューティング効率化」 Amazon Q Developer CLI は、従来の複雑で時間のかかる運用トラブルシューティング作業を、自然言語による対話形式のインターフェイスで劇的に効率化する機能を提供します。記事では Nginx の 502 Gateway Timeout エラーを例に、従来であれば複数のコンソール間を行き来しながら手動で行っていた調査・分析・修正作業を、Amazon Q Developer CLI が自動的にインフラストラクチャ検出、ログ分析、根本原因特定、CDK コードの修正、デプロイ、検証まで一貫して実行する様子が紹介されています。単一の対話型インターフェイスで AWS CLI コマンドを実行し、複数サービスにわたる情報を相関分析して問題を特定・解決できるため、エンジニアは数時間から数日かかっていたトラブルシューティング作業を大幅に短縮できます。インフラストラクチャチームの認知負荷を軽減し、より本質的な改善作業に時間を集中できるようになる、運用効率化において非常に価値の高いツールです。 ブログ記事「機械の故障予防： フィジカル AI が機器の問題を予測する方法」 フィジカル AI とは、コンピューター画面の中だけでなく、現実世界で実際に動いて作業するAI技術のことです。従来のAIがテキストや画像を処理するのに対し、フィジカルAIはロボットや自動運転車のように、私たちの身の回りの環境を理解して物理的に行動できる点が大きな特徴です。この技術が機械の故障予防分野で革命的な変化をもたらしており、特に電気自動車（EV）では、車両が自分自身の健康状態を常に監視し、バッテリーやモーターの調子を学習することで、故障する前に問題を予測・防止する賢いメンテナンスシステムが実現されています。AWS IoT FleetWise、Amazon SageMaker、Amazon Bedrock などの AWS サービスを組み合わせることで、車両データの収集から機械学習による故障予測、生成 AI を活用した修理計画作成まで、総合的な予防保全ソリューションが構築できます。この技術は工場のロボット、医療機器、社会インフラにも応用でき、「壊れてから直す」従来の方法から「壊れる前に予防する」賢いシステムへと進化させ、企業の運用コスト削減と機器の長寿命化という大きな価値を提供します。 ブログ記事「Amazon Q Business と Amazon Bedrock によるSAP データ価値の最大化 – パート 1」 このブログでは、SAP システムを利用している企業が AWS の生成AI サービスを活用して、日々の業務を効率化し、データから新たな価値を創出する方法を紹介しています。多くの企業が「生成AIを使いたいが、SAPデータでどこから始めればよいかわからない」という課題を抱えている中、Amazon Q Business と Amazon Bedrock を使った2つの実践的なソリューションが提案されています。1つ目は、通常数十ページに及ぶ SAP Early Watch Analysis (EWA) レポートを自然言語で簡単に分析できるシステムで、従来の手作業による分析時間を大幅に削減し、複数システムの健康状態を迅速に把握できるようになります。2つ目は、紙やPDFの請求書処理を自動化するインテリジェントドキュメントプロセッシング機能で、手作業によるエラーを減らし、処理速度を向上させることができます。これらのソリューションは詳細な構築手順とコスト例も含まれており、SAP環境で生成AIの導入を検討している企業にとって、具体的で実用的な価値を提供します。従来の時間のかかる分析作業から、AIを活用した効率的な業務プロセスへの転換を支援する内容となっています。 ブログ記事「Realtek、Plumerai、Amazon Kinesis Video Streams を活用したエッジでの効率的な動画ストリーミングとビジョンAI」 このブログでは、最新のスマートカメラ技術を組み合わせた監視システムソリューションを紹介しています。従来の防犯カメラは常に録画してクラウドに送信していましたが、今回紹介するシステムは、カメラ自体が賢くなって人を見つけた時だけ動画を送信します。Realtek の小型で高性能なマイクロコントローラー「Ameba Pro2」、軽量で効率的な AI を提供する Plumerai の機械学習モデル、そして AWS の動画ストリーミングサービス Amazon Kinesis Video Streams を組み合わせることで実現されています。このシステムの特徴は、カメラが現地で人物検知の AI 処理を行うため、プライバシーが守られ、インターネットの通信量も大幅に削減できることです。実際の性能も優秀で、わずかなメモリ使用量で 20 メートル先の人物を検知でき、最大 20 人まで同時に追跡可能です。スマートホームから企業の監視システムまで幅広く活用でき、必要な時だけ動画を送信する賢いカメラシステムによって、コスト削減とプライバシー保護を両立した次世代の監視ソリューションを提供します。 サービスアップデート Amazon Bedrock が、Anthropic Claude Sonnet 4 と OpenAI GPT-OSS モデルのバッチ推論をサポート Amazon Bedrockで、Anthropic Claude Sonnet 4およびOpenAI GPT-OSS（120Bと20B）モデル向けのバッチ推論が利用可能になりました。複数の推論リクエストを非同期で処理できるようになり、大規模データセットでのパフォーマンスが向上し、通常のオンデマンド推論価格の半額で利用できます。ドキュメント分析、マーケティングコピーの一括生成、ナレッジベースの自動要約、サポートチケットの分類など、様々なシナリオで効率的に大量のデータを処理できるようになりました。さらに、以前のモデルと比較してバッチスループットが向上し、Amazon CloudWatchメトリクスを使ってバッチワークロードの進捗をAWSアカウントレベルで追跡することも可能になりました。大規模な生成AIワークロードをコスト効率よく処理したいユーザーにとって、非常に価値のあるアップデートです。 TwelveLabs の Pegasus 1.2 モデルが 米国東部（バージニア北部）およびアジアパシフィック（ソウル）で利用可能に TwelveLabs の Pegasus 1.2 モデルが米国東部（バージニア北部）およびアジアパシフィック（ソウル）の AWS リージョンで新たに利用可能になりました。Pegasus 1.2 は長時間ビデオに特化した言語モデルで、従来のテキスト中心のモデルとは異なり、ビデオコンテンツの理解に最適化されて設計されています。ビデオ内の視覚・音声・テキスト情報を総合的に分析してテキストを生成できる強力な機能を持っています。新しいリージョンでの提供により、ユーザーのデータや最終利用者により近い場所でアプリケーションを構築できるようになり、レイテンシーの削減とアーキテクチャの簡素化が実現できます。 Amazon Bedrock で OpenAI のオープンウェイトモデルへのアクセスが簡素化 Amazon Bedrock で OpenAI のオープンウェイトモデル（gpt-oss-120b と gpt-oss-20b）へのアクセスが大幅に簡素化されました。これまで必要だったモデルアクセスの明示的な有効化作業が不要となり、すべての Bedrock ユーザーが自動的にこれらのモデルを利用できるようになりました。ユーザーは Amazon Bedrock Console のプレイグラウンドや AWS SDK のAPI を通じて、すぐにモデルの使用を開始できます。今後、Bedrock では他の既存サーバーレスモデルにもこの簡素化されたアクセス方式を拡張し、新しいサーバーレス基盤モデルはすべてデフォルトでアクセス可能な状態でリリースされる予定です。アカウント管理者は引き続き IAM ポリシーや Service Control Policies を通じてモデルアクセスを制御できるため、セキュリティを保ちながら開発者の利便性を大幅に向上させるアップデートです。 Amazon CloudWatch の自然言語クエリ結果要約とクエリ生成機能が対応リージョンを拡大 Amazon CloudWatch Logs Insightsの自然言語クエリ結果要約機能が、東京リージョンを含むアジアパシフィック、ヨーロッパ、南米など15の新しいAWSリージョンで利用可能になりました。この機能により、複雑なログクエリの結果を自然言語で分かりやすく要約し、迅速な問題特定と洞察の獲得が可能になります。さらに、自然言語によるクエリ生成機能も6つの新しいリージョンで展開され、PPLとSQLのクエリ生成は3つのリージョンで新たに利用可能になりました。これらの機能強化により、クエリ言語の専門知識がなくても、平易な英語で簡単にログ分析が行えるようになり、運用効率の大幅な向上が期待できます。 AWS Neuron SDK 2.25.0 が一般提供開始 AWS Neuron SDK 2.25.0が一般提供を開始し、AWS InferentiaとTrainium インスタンスにおける推論ワークロードとパフォーマンス監視機能が改善されました。この最新リリースでは、コンテキストとデータ並列処理のサポートに加え、長いシーケンス処理に対応したチャンクアテンション機能が追加され、より効率的な推論処理が可能になります。また、neuron-ls と neuron-monitor API もアップデートされ、ノードアフィニティとデバイス使用率に関するより詳細な情報が取得できるようになりました。さらに、高速テンソル操作のための自動エイリアシング機能（ベータ版）や分散サービング機能（ベータ版）の改善も含まれており、推論・トレーニング用の AMI と Deep Learning Containers もアップグレードされています。これらの機能強化により、AWS の AI/ML 専用チップを使用した高性能かつコスト効率の良い機械学習ワークロードの実行がより容易になり、特に大規模言語モデルの推論処理において大きな価値を提供します。 Amazon Bedrock で Anthropic Claude モデル向けの Count Tokens API が利用可能に Amazon Bedrock において、推論実行前にプロンプトや入力データのトークン数を事前に確認できる Count Tokens API が利用可能になりました。この機能により、特定のモデル ID に送信する前にトークン数を把握できるため、より正確なコスト予測が可能になり、AI モデル使用に関する透明性と制御性が大幅に向上します。Amazon Bedrock でのトークン制限を事前に管理できるようになるため、使用量の最適化と予期しないスロットリングの回避が実現され、ワークロードがモデルのコンテキスト長制限内に収まることを事前に確認できます。特に大規模な生成 AI アプリケーションを運用する企業にとって、コスト管理とパフォーマンス最適化の両面で価値のある機能追加です。 Amazon SageMaker Unified Studio でプロジェクトにS3ファイル共有オプションを追加 Amazon SageMaker Unified Studio で、プロジェクト内のファイル保存と共有方法が大幅に簡素化されました。従来の Git リポジトリ（GitHub、GitLab、Bitbucket Cloud）に加えて、Amazon S3 バケットを使用したファイル共有オプションが新たに追加され、S3 がデフォルトオプションとして設定されています。この機能により、データサイエンティストや分析担当者は Git の複雑な操作を覚える必要がなく、JupyterLab、Code Editor、SQL クエリエディタなど SageMaker Unified Studio 内のどのツールからでも一貫したファイルビューでコードの作成・編集・共有が可能になります。また、管理者が有効にした場合は基本的なバージョン管理もサポートします。 AWS Billing and Cost Management MCP server の発表 Model Context Protocol（MCP）に対応した Billing and Cost Management MCP server が AWS Labs GitHub リポジトリでリリースされました。このMCPサーバーにより、ユーザーは任意のAIアシスタントを使用して、過去の支出分析、コスト最適化の機会の特定、新規ワークロードのコスト見積もりなどが可能になります。Amazon Q Developer以外のMCP互換のAIアシスタントでも、AWS料金データへのアクセスや分析が可能になり、専用のSQL計算エンジンを通じて信頼性の高い計算処理を実行できます。これにより、期間比較や単位コストメトリクスなどの分析が容易になり、大量のコストと使用量データを効率的に処理できるようになりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

本投稿は、 Tom AdamskiとAditya Santhanamによる記事「 Oracle Database@AWS network connectivity using Amazon VPC Lattice 」を翻訳したものです。 Oracle Database(ODB)@AWS が北米リージョンで 一般利用可能 になり、Amazon Web Services（AWS）データセンター内のOracle Exadataインフラストラクチャ（OCIが管理）とユーザーのAWSおよびオンプレミス・ネットワークとの間の接続を合理化する 新しいネットワーク接続機能 を導入します。これらの新機能には、ODBネットワークからのハイブリッド接続のための Amazon VPC Lattice 統合、およびZero-ETL、 Amazon S3 、およびODBネットワーク間のネイティブで安全なアクセスが含まれます。 この投稿では、ODBネットワークをさまざまなサービスに接続できるVPC Latticeを利用した機能に焦点を当てて、これらの機能のネットワーキングがどのように機能するかについて説明します。 これらの機能により、より自動化され合理化された統合環境が提供されると同時に、IPアドレス空間が重複する環境でも、ユーザーが管理するリソースへの安全なアクセスが可能になります。これにより、セットアップの複雑さが軽減され、ODB@AWS と安全に通信できるアプリケーションの種類が広がります。 基本的な理解 ODB @AWS を初めて使用する場合は、 AWSのドキュメント で包括的な情報を見つけることができます。新機能に取り掛かる前に、VPC Latticeを使わずにODBネットワークを Amazon Virtual Private Clouds（Amazon VPC） に接続する既存の方法を確認しておきましょう。 ODBピアリング ：1つのODBを1つのVPCに接続するための直接的で低遅延のオプションです。 AWS Transit Gateway : 複数のVPCとの大規模な接続を合理化できます。 AWS Cloud WAN : 複数のVPCとの拡張接続オプションを提供します。 私たちの新機能はVPC Latticeに依存しているので、そのコアコンポーネントを理解する必要があります。 Service network ：リソースをグループ化する論理的な境界 Service network endpoint ：サービスネットワークへのプライベートで安全なアクセスを可能にします Resource gateway :サービスネットワークがプロバイダーが公開しているリソースにアクセスできるようにします Resource :リソースゲートウェイを介してアクセス可能になったすべてのTCPアプリケーション アーキテクチャの概要 プライベートネットワークを使用して新しい ODB @AWS デプロイメントを作成すると、AWSはアカウントにデフォルトの VPC Lattice サービスネットワークを自動的にプロビジョニングします。このネットワークはあなたのために作られていますが、標準のVPC Latticeサービスネットワークと同じように動作します。独自のアプリケーションをリソースまたはサービスとして追加したり、VPCやエンドポイントに関連付けたり、 アクセスログを有効 にしてアプリケーショントラフィックを可視化したりできます。 ODBサービスネットワークには、デフォルトのService network endpoint（ODBプライベートネットワークからのアウトバウンドアクセス用）とResource Gateway（ODBプライベートネットワークリソースへのインバウンドアクセス用）があらかじめ設定されています。このVPC Latticeのデプロイメントは、ODBピアリング、AWS Transit Gateway、AWS Cloud WANなどの従来の接続オプションとシームレスに連携します。 次の図は、ODBプライベートネットワークと他のAWSサービスおよびユーザー管理リソース間で利用可能なすべてのトラフィックフローを示しています。 図 1.ハイレベルアーキテクチャの概要 ODBプライベートネットワークと他の AWS サービス、およびユーザーが管理するリソースとの間のトラフィックの流れは、次のように行われます。 ODBピアリング、Transit Gateway、AWS Cloud WANなどの従来の接続を使用して、ODBプライベートネットワークとユーザー管理型VPC間のトラフィックをルーティングします。 ODBプライベートネットワークからAmazon S3またはユーザーが管理するVPC Latticeリソースへのトランスポートレイヤートラフィック。 ユーザーのVPC（またはオンプレミス・ネットワーク）からOracleがホストする仮想マシン（Oracle VM）へのトランスポート層トラフィック。 Amazon Zero-ETL からODBプライベートネットワークへのトランスポート層トラフィック。 マネージドサービス統合の設定 Amazon S3とZero-ETLのマネージドインテグレーションは、ODB @AWS ネットワークで簡単に設定できます。図2に示すように、ODB @AWS ネットワークの作成プロセス中に、コンソールで適切なチェックボックスを選択するだけです。 図 2.ODBネットワークでのマネージドサービス統合を有効にする デフォルトのODBサービスネットワークを使用して以下のリソースに接続したい場合： 顧客管理アプリケーション 個々のOracleの仮想マシン Amazon VPC Latticeの追加設定を行う必要があります。これについては、次のセクションで詳しく説明します。 注:ODBピアリングについては、AWSのドキュメントや他のブログ記事ですでに詳しく取り上げているので、この記事ではODBピアリングについては取り上げません。 ODBネットワークからAmazon S3への接続 ODBプライベートネットワークからAmazon S3にアクセスする場合、主に2つのユースケースがサポートされます。Oracleが管理するS3バケットにアクセスして自動バックアップを行う場合、もう1つは、ユーザーが管理するS3バケットへアクセスする場合です。 独自のS3バケットへのアクセスを有効にするには、バケット名、AWSアカウント、または AWS Organizations に基づいて権限を制御する認証ポリシーを定義してください。これらのポリシーは、標準の Amazon S3エンドポイントポリシー 構文を使用しています。 ODBプライベートネットワークは、自動的に作成されたService network endpointを介してAmazon S3に接続します。Oracleが管理するAmazon S3へのバックアップアクセスは、追加の設定をしなくてもすぐに使用できます。 次の図は、Amazon S3のアクセスフローの例を示しています。 図 3.Amazon S3へのODBネットワークアクセス 任意のS3バケットと通信するために、ODBプライベートネットワークは、デフォルトのODB Lattice Service networkのフロントエンドであるService network endpointにトラフィックを送信します。 トラフィックがOracleが管理するS3バケット宛ての場合、その通信はOracleによって管理および制御されます。 ユーザー所有のバケットへのトラフィックについては、認証ポリシーを適用して、アクセスできる宛先バケットを制限できます（たとえば、特定のAWSアカウントのバケットにのみアクセスを許可するなど）。 考慮事項: ODBネットワークDNSは、Oracleの組み込みVirtual Cloud Network(VCN) DNSリゾルバーを使用している場合、リージョンのAmazon S3ホスト名のService network endpoint IPを自動的に返します。 異なる AWS リージョンの S3 バケットへのアクセスは現在サポートされていません。 S3バケットポリシーの次の条件は、このモデルを使用するトラフィックではサポートされていません。 aws:SourceVpc,&nbsp;aws:SourceVpce, and&nbsp;aws:VpcSourceIp. ODBネットワークへのZero-ETL接続 Zero-ETL統合は、 Amazon Redshift などのデータウェアハウスで、複数のオペレーションおよび取引ソースからのトランザクションやオペレーションデータを利用できるようにするフルマネージド型のソリューションです。このソリューションでは、Oracle Database仮想マシンからAmazon Redshiftデータウェアハウスへの統合を設定できます。これにより、ビジネスダッシュボード、最適化されたゲーム体験、データ品質モニタリング、ユーザー行動分析などのユースケースについて、より正確でタイムリーな洞察が得られます。 Zero-ETLユースケースでは、AWSマネージドサービスからODBネットワークへのインバウンド接続が必要です。次の図は、このユースケースのトラフィックフローを示しています。 図 4.ODBネットワークへのZero-ETL接続 Zero-ETLユースケースは、AWSによってフルマネージド管理され、デフォルトのODB VPC Latticeサービスネットワークでは表示されないカスタムネットワーク実装で構成されています。 考慮事項: Zero-ETL接続は、ODBネットワークと同じリージョンでのみサポートされています。 Zero-ETLはオプトイン機能です。実装の詳細と価格については、AWSのドキュメントを参照してください。データの初期シードと再同期、および変更データのキャプチャには、その他の 料金が適用 されます。 顧客管理リソースへのODBネットワークアクセス デフォルトのODB Latticeサービスネットワークは、Amazon S3接続のみではなくネットワーク内のカスタムリソースをサポートします。ODBピアリング、Transit Gateway、またはAWS Cloud WANとは異なり、このアプローチはエンドツーエンドのルーティング到達可能性を必要としません。VPC Latticeは、IPスペースが重複しているネットワークやアドレスファミリ（IPv4/IPv6）が異なるネットワーク間の接続を処理します。 次の図は、トラフィックフローを示しています。 図 5.デフォルトのODB VPC Latticeサービスネットワークを通じてカスタムリソースを公開 ODBネットワークは、Service networkのendpointを介して公開されているリソースまたはサービスに接続します。 VPC Lattice Service networkは、Resource gatewayを使用してユーザーが管理するリソースにアクセスしています。 VPC Latticeサービスネットワークは、関連するVPC Latticeサービスに直接アクセスできます。 VPC Latticeサービスのセットアップ（HTTP、HTTPS、TLS Passthrough） アプリケーション用の VPC Lattice サービスを作成 VPC Latticeサービスを、ODBサービスネットワークを所有するAWSアカウントと共有します （クロスアカウント設定を使用している場合） サービスをODBサービスネットワークに 関連付けます サービスの自動生成されたホスト名を特定します: ODBネットワークのService network endpointに移動します。 アソシエーションセクションを見直してください VPC Lattice リソース (TCP) のセットアップ TCPアプリケーションが置かれているVPCに Resource gatewayを作成 します。 リソース設定を作成 してください。例としては、パブリックに解決可能なアプリケーションのホスト名があります。 リソース設定を、ODBサービスネットワークを所有する AWSアカウントと共有 します（クロスアカウント設定を使用している場合）。 リソース構成を ODBサービスネットワークに関連付け ます。クライアントのAWSアカウントで、次のいずれかで接続を確立します。 リソースの自動生成されたホスト名を特定します: ODBネットワークのService network endpointに移動します アソシエーションセクションを見直してください 考慮事項: カスタムホスト名を使用してOracle VMからアプリケーションに接続するには、OCI環境のDNSを更新する必要があります。プライベート・ホスト・ゾーンを作成してOracle VCNに関連付けてから、カスタム・ホスト名からAWSが生成したホスト名へのCNAMEマッピングを作成します。 resource gatewayは、ODBネットワークと同じアベイラビリティーゾーン（AZ）にデプロイする必要があります。 Oracle VMへの顧客ネットワークアクセス VPC Latticeを使用すると、VPCからODBネットワーク内の個々のVMに直接接続できます。これらのリソースにアクセスするには、サービスネットワークと VPCアソシエーション またはService network endpointアソシエーションを確立する必要があります。 ODBプライベートネットワーク内の各VMは、VPCの観点からは個別のホスト名とIPアドレスとして表示されます。 VMに割り当てられているIPとホスト名の詳細を調べるには、Service network endpoint構成で 関連付けを確認 してください。 図 6.VPC Latticeのサービスネットワークを通じてOracleの仮想マシンを公開する VPC内のクライアントは、ODBネットワーク内のVMを表すローカルVPCのIPアドレスに接続します。 トラフィックは、ターゲットVMに転送される前に、resource gatewayでODBネットワーク範囲のIPアドレスに送信元NATされます。 Oracle VMをVPC Latticeリソース（TCP）として設定する Oracle VMのリソースを設定します: 各VMの リソース構成 を作成します &nbsp;仮想マシンのIPアドレスをターゲットとして指定します ODBネットワークのデフォルトのresource gatewayを使用しますOracle VMのリソースを設定します ODBサービスネットワークをクライアントの AWSアカウントと共有します （クロスアカウント設定を使用している場合）。 クライアントのAWSアカウントで、次のいずれかで接続を確立します。 service endpoint networkアソシエーション の作成 service endpoint VPCアソシエーション のセットアップ VMの自動生成されたホスト名には、次の方法でアクセスします: 新しく作成したService network endpointに移動します アソシエーションセクションを見直してください 考慮事項: Oracleの Single Client Access Name（SCAN）への接続はサポートされていません。個々のVMにのみアクセスできます。 IPアドレスベースのリソース構成は 次の範囲のみをサポートしま す：10.0.0.0/8、100.64.0.0/10、172.16.0.0/12、192.168.0.0/16。IPv6の場合は、VPCからのIPを指定してください。パブリックIPはサポートされていません。 ユーザーVPC側でカスタムDNS名を設定するには、VPCにプライベートホストゾーンを設定する必要があります。このプロセスの詳細については、このAmazonネットワーキングポストのガイダンスに従ってください。 図の例は、service networkのendpointを使用したアクセスを示しています。VPCアソシエーションもサポートされています。 OracleのNetwork Security Groupsが、リソース・ゲートウェイのIP範囲からのインバウンド・トラフィックを許可していることを確認してください。 結論 Amazon VPC Latticeは、ODBプライベートネットワークとAmazon S3、Zero-ETL、およびユーザー管理リソース間のシームレスな接続を可能にします。詳細な実装手順については、 AWSのドキュメント を参照してください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

本日、 AWS Billing and Cost Management において、複数の請求およびコストデータのビューを 1 ページ内で表示できる新機能「Billing and Cost Management ダッシュボード」が一般提供となったことをお知らせします。この新機能により、 AWS Cost Explorer のデータと、Savings Plans やリザーブドインスタンスに関する使用率・カバレッジを組み合わせて表示できるカスタマイズ可能なビューを作成でき、支出パターンや相関関係を把握し、データに基づいた財務的な意思決定が可能になります。また、作成したダッシュボードはアカウント間で共有できるため、FinOps チームによる組織全体での一貫したコストレポートの標準化にも貢献します。 なぜ Billing and Cost Management ダッシュボードを利用すべきか？ AWS 上でより多くのアプリケーションを構築・運用する中で、多くのお客様は比較分析、傾向把握、異常値の特定を行うために、複数のメトリクスを同時に確認・分析する必要があります。Billing and Cost Management ダッシュボードを利用することで、以下のことが可能になります： 複数の可視化されたウィジェットを組み合わせて単一ビューで表示し、相関関係や傾向を把握する 頻繁に実施する分析のためにカスタムダッシュボードを作成・保存する ダッシュボードをアカウント間で共有し、共通のレポート基準を組織内で確立する ダッシュボードの主な機能は？ Billing and Cost Management ダッシュボードは、以下の主要機能を提供します： カスタマイズ可能なダッシュボード ：複数のウィジェットを追加して、カスタムダッシュボードを自由に構築できます。各ウィジェットは独立した可視化コンポーネントであり、グラフまたはテーブル形式でデータを表示するように構成できます。複数のウィジェットを単一のダッシュボード内に組み合わせて配置することができ、相関関係の発見やデータに基づいた財務判断に役立てることができます。例えば、Savings Plans のカバレッジや使用率を示すチャートと、Amazon EC2 スポットインスタンス や オンデマンドインスタンス の費用をアプリケーション別に示すチャートを組み合わせて、コスト最適化の進捗を確認するためのダッシュボードを作成することができます。ウィジェットのサイズや位置も柔軟に調整でき、理想のレイアウトを構築できます。 複数のウィジェットタイプ ：様々なウィジェットタイプを使用してダッシュボードを構成できます： カスタムウィジェット：レポートニーズに合わせて設定可能な基本ウィジェットです。 コストウィジェット：サービスごとの支出傾向を追跡するためのコストデータを可視化します。 使用量ウィジェット：すべての AWS サービスにおける使用状況を集約して可視化し、全体的なリソース消費量を監視できます。 Savings Plans の使用率・カバレッジウィジェット：使用率ウィジェットは、Savings Plans のコミットメントのうち、対象使用量に対して実際に使用されている割合を可視化するのに役立ちます。カバレッジウィジェットは、選択した期間中に、該当する AWS の使用コストのうち何パーセントが Savings Plans でカバーされているかを表示します。 リザーブドインスタンスの使用率・カバレッジウィジェット：使用率ウィジェットは、リザーブドインスタンスのうち、対象使用量に対して実際に使用されている割合を可視化するのに役立ちます。カバレッジウィジェットは、選択した期間中に、該当する AWS の使用コストのうち何パーセントがリザーブドインスタンスでカバーされているかを表示します。 図 1：カスタムウィジェットの設定画面 事前定義済みウィジェット：すぐに使用可能なウィジェットで、サービス別月次コストや日次コストなど、一般的な用途に合わせて事前構成されています。レポートニーズに応じて、追加でカスタマイズすることも可能です。 サービス別の月次コスト：過去 6 か月間のサービスごとの月次コストを可視化 連結アカウント別の月次コスト：過去 6 か月間の連結アカウントごとの月次コストを可視化 EC2 の稼働時間の月次コスト：過去 6 か月間の Amazon EC2 の月別稼働時間に基づくコストを可視化 日次コスト：過去 6 か月間の日次コストを可視化 AWS Marketplace コスト：過去 6 か月間の AWS Marketplace におけるコストを可視化 図 2：架空企業「Unicorn」の事前定義済みウィジェットを使ったサンプルダッシュボード 柔軟なレイアウトオプション ：各ダッシュボードには最大 20 個のウィジェットを追加可能です。ウィジェットのサイズや配置を自由に調整することで、目的に応じたレイアウトを作成できます。 共有機能 ：AWS Organizations 内のアカウントや、AWS Resource Access Manager (RAM) を使用して外部アカウントへ作成した ダッシュボードを共有する ことができます。共有時には、「閲覧のみ」または「編集可能」のアクセス権限を設定できます。ダッシュボードを共有しても、コスト関連の元データそのものが共有されるわけではありません。共有されるのは各ウィジェットの設定 (例：表示されるコストメトリクスやフィルター) とレイアウト情報のみです。組織内のメンバーアカウントに対して、複数アカウントを跨ぐコストと使用状況ビューへのアクセスを許可する カスタム請求ビュー を作成することが可能です。共有先のアカウントでは、同一レイアウト・同一フィルターで、自身に許可された範囲のデータを表示することができます。 図 3：ダッシュボード共有設定画面 利用開始方法 前提条件： 開始する前に、ダッシュボードの表示、一覧取得、作成、更新、削除を行うための権限、および AWS Cost Management に対するきめ細かなアクセス制御への移行 が必要です。詳細については、「 AWS コスト管理にアイデンティティベースのポリシー (IAM ポリシー) を使用する 」を参照してください。また、コストおよび使用状況に関するウィジェットを利用するには、AWS Cost Explorer を有効化する必要があります。 ダッシュボードを組織内の他のアカウントと共有するには、 AWS Resource Access Manager (RAM) を使用する必要があります。RAM を使用することで、ダッシュボードなどのリソースを AWS アカウント間で安全に共有することができます。カスタムダッシュボードの共有には、AWS Resource Access Manager を使用してダッシュボードを共有するための権限が必要です。詳細については、「 How AWS RAM works with IAM 」を参照してください。 ユーザーガイド の手順に従って、新しいカスタムダッシュボードを作成しましょう。これらのダッシュボードは追加料金なしで利用できます。また、API を用いたプログラム経由での作成や管理も可能です。詳細については、API リファレンスガイドをご覧ください。 結論 Billing and Cost Management ダッシュボードは、AWS のコストを可視化・分析するための強力な手段を提供し、組織内でのより良いコラボレーションを可能にします。詳細については、 ドキュメント をご覧いただくか、 AWS Billing and Cost Management コンソール から今すぐ使い始めましょう。 翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文は こちら です。 　 Tushar Mukherjee Tushar Mukherjeeは、ニューヨークを拠点とする AWS のシニアテクニカルプログラムマネージャーです。FinTech 分野での豊富な経験を持ち、大手機関銀行やヘッジファンドでの勤務経験を有しています。AWS では、中国での Savings Plans のローンチをはじめとする多くの大規模プログラムを推進してきました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 9月に入り秋を少し感じられるようになってきました。 9月の builders.flash 記事が出ていますので生成AI関連のものをピックアップしてみます。 カメラ画像を Amazon Bedrock で解析 ! ~ SORACOM Flux における安全な AI 呼び出しと効果的なプロンプトの探求（株式会社ソラコム様） 少数精鋭・高創造性への転換：Amazon Q Developer CLI を活用したオフショア開発の効率化（株式会社 プロトソリューション様） エンジニアの挑戦を加速させる ! ~ 生成 AI ハンズオンワークショップ ~（株式会社豊田自動織機ITソリューションズ様） Strands SDK を使って、AWS Lambda Tool MCP Server を試してみた !（AWS） MCP (Model Context Protocol) で MCP (Minecraft Play) して親の威厳を取り戻す夏 ~ Strands Agents を添えて ~（AWS） どの記事も実践的かつ生成AI活用の観点が異なっていて参考になりますね。 直近控えているイベントとしては、2025 年 9 月 24 日 (水) に Amazon Nova による業務革新事例の紹介を中心としたイベント「AWS Amazon Nova Ignite」が開催予定です。 こちらから申し込み可能 ですので是非ご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、9 月 1 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「9 月 15 日まで無料で Kiro を使用」を公開 開発者向けエージェント型 IDE「Kiro」にて、 8 月 22 日の価格更新 に続き、9 月 15 日まで無料使用を延長することが発表されました。本ブログでは、返金処理の詳細、使用制限のリセット、超過料金の無料提供（1,000 回の vibe リクエストと 200 回の spec リクエスト）、今後の価格変更予定などについてQA形式で説明しています。 ブログ記事「SAP と AWS が AI 共同イノベーションプログラムを発表 : 市場の変動性とサプライチェーンの複雑性に対応するための生成 AI ソリューションを創出へ」を公開 2025 年の SAP Sapphire にて、AWS と SAP は AI 共同イノベーションプログラムを発表しました。本ブログでは、パートナーが ERP ワークロードに特化した生成 AI アプリケーションとエージェントを構築できるよう支援するプログラムの概要、Amazon Bedrock と SAP Business Technology Platform の統合、Accenture や Deloitte などのパートナー企業との協力事例を紹介しています。 ブログ記事「生成 AI と IoT でスマート産業機械の価値を最大化」を公開 本ブログでは、生成 AI と IoT を組み合わせてスマート産業機械の価値を最大化するユースケースや実現方法について解説しています。1/問題の診断・解決支援、2/フィールドサービスオペレーションの強化、3/装置フリート分析、4/AI診断レポートの4つのユースケースを取り上げ、Amazon Bedrock と AWS IoT サービスを活用した具体的なアーキテクチャと実装方法を紹介しています。 ブログ記事「第 4 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】」を公開 2025 年 8 月 26 日に第 4 回 AWS ジャパン生成AI Frontier Meetup を開催しました。本ブログでは、生成AI実用化推進プログラムの成果、Amazon Nova の新機能、Kiro や Amazon Bedrock AgentCore などの最新サービス、参加企業によるライトニングトーク、GENIAC 採択者による基盤モデル開発事例など、イベントで紹介された幅広い内容をまとめています。 ブログ記事「CloudWatch エージェントを用いたAI エージェントの監視方法」を公開 AI エージェントアプリケーションが想定通りの顧客体験を生み出しているかを担保するためには包括的なオブザーバビリティが必要です。本ブログでは、AI エージェントアプリケーションを Amazon CloudWatch で監視する方法について紹介しています。Strands Agents SDK を使用したサンプルアプリケーションを例に、CloudWatch エージェントの設定方法、トレース・メトリクス・ログの収集、X-Ray による可視化、実際のデプロイ手順とテレメトリデータ分析の具体的な実装方法を紹介しています。 サービスアップデート AWS Transform アセスメントに分離ストレージが含まれるように AWS Transform のアセスメント（評価機能）が拡張され、オンプレミスのストレージインフラ分析が可能になりました。これまで Compute やネットワークの評価が中心でしたが、今回 SAN や NAS などのストレージも分析対象となりました。Amazon S3 や Amazon EBS への移行推奨が自動生成され、より具体的な移行計画が立てられるようになります。 AWS Transform for VMware が柔軟なネットワーク管理とより広い AWS リージョンカバレッジをサポート AWS Transform for VMware が VPC CIDR 範囲の変更をサポート開始しました。これによりオンプレミスと AWS 環境で IP 競合なく並行稼働ができるようになりました。また、新たにオハイオ、ストックホルム、アイルランドリージョンでの利用もサポートされました。 Amazon BedrockでAnthropic Claudeモデルの簡素化されたキャッシュ管理機能を開始 Amazon Bedrock の Anthropic Claude モデル (Claude 3.5 Haiku、Claude 3.7、Claude 4) で、使いやすさが向上されたプロンプトキャッシング機能が利用できるようになりました。これまではプロンプトのどの部分をキャッシュから再利用するか開発者自身で管理する必要がありましたが、今回の機能により、リクエスト末尾にキャッシュブレークポイントを設定するのみで利用可能になりました。この機能は各モデルが提供されている全てのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Bedrock がアジアパシフィック (ジャカルタ) リージョンで利用可能に Amazon Bedrock がジャカルタリージョンで利用可能になりました。ジャカルタリージョンにデータを現地に保持しながら生成 AI アプリケーションを構築できるようになります。詳細は こちらのドキュメント をご参照ください。 Amazon BedrockがAnthropic Claude Sonnet 4のグローバルクロスリージョン推論をサポート開始 Amazon Bedrock で Anthropic Claude Sonnet 4 のグローバルクロスリージョン推論がサポートされました。これまではUS、EU、APAC などの特定の地域に紐づいたクロスリージョン推論を選択できました。今回のサポートにより、トラフィックが集中した際に特定地域に依存しない分散処理が可能となり、モデルスループットをより向上させることができます。詳細については クロスリージョン推論によるスループット向上 、および 推論プロファイルでサポートされているリージョンとモデルのドキュメント もご確認ください。 AWS が Amazon Bedrock の API キーを管理するための 3 つの新しい条件キーのサポートを追加 Amazon Bedrock の API キー管理がより柔軟になりました。3つの新しい条件キーが追加され、管理者は API キーの生成、有効期限、許可されるAPIキーのタイプをより細かく制御できます。例えば、Amazon Bedrock 専用の長期 API キー作成は許可しつつ、CodeCommit等の他サービス用の生成は禁止するといった設定が可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Neptune が生成AIアプリケーションの長期記憶を支援するZepとの統合を発表 Amazon Neptune と Zep の統合が発表されました。Zep は LLM アプリケーション向けのオープンソースメモリサーバーで、ユーザーとのやり取りの履歴の永続化、取得、および拡張が可能です。これにより、Neptune Database または Neptune Analytics をグラフストアとして利用しつつ、Amazon OpenSearch を Zep のメモリシステムのテキスト検索ストアとして使用することで、よりパーソナライズされたLLMアプリケーションが構築しやすくなりました。詳細についてはこちらの サンプルノートブック をご確認ください。 Amazon EKS の Split Cost Allocation Data が NVIDIA および AMD GPU、Trainium、Inferentia 搭載 EC2 インスタンスをサポート Amazon EKS の Split Cost Allocation Data が GPU や Trainium、Inferentia を使った加速コンピューティングワークロードに対応しました。これまで CPU とメモリのコストしか追跡できませんでしたが、今回のアップデートで NVIDIA や AMD の GPU、AWS の AI チップのコストも詳細に把握できるようになります。AI/ML ワークロードを複数のチームで運用している企業では、各チームのリソース使用量に応じた正確なコスト配分が可能になります。詳細は こちらのブログ記事 をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本投稿は、 Channy Yunによる記事 「Introducing Oracle Database@AWS for simplified Oracle Exadata migrations to the AWS Cloud」 を翻訳したものです。 2025年7月8日、AWS 内の Oracle Real Application Clusters (RAC) を含む Oracle Exadata ワークロード向けの新製品である Oracle Database @AWS の一般提供について発表しました。 過去14年間、お客様は、 Amazon Elastic Compute Cloud（Amazon EC2） を使用してクラウドでOracle Databaseのワークロードを自己管理するか、フルマネージド型の Amazon Relational Database Service（Amazon RDS）for Oracle を使用するかを選択していました。この度、クラウドへの迅速かつ簡単な移行のためにOracle RACまたはOracle Exadataを必要とするワークロード用のオプションが追加されました。費用については、AWSへのコミットメントや、Bring Your Own License（BYOL）・Oracle Support Rewardsなどの割引プログラムを含むオラクルのライセンス特典にカウントされる請求書が、AWS Marketplaceを通じて発行されます。 Oracle Database @AWS を使用すると、最小限の変更で、Oracle ExadataワークロードをAWS内の専用インフラストラクチャ上のOracle Exadata Database Serviceまたは専用Exadataインフラストラクチャ上のOracle Autonomous Databaseに移行できます。Oracle Database @AWS デプロイメントは、 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、または AWS で実行されるアプリケーション用の AWS API などの使い慣れた AWS ツールとインターフェイスを介して購入、プロビジョニング、管理できます。AWS APIは、リソースのプロビジョニングと管理に必要なOracle Cloud Infrastracture(OCI) APIを呼び出します。 2024年12月の プレビュー 以来、一般提供時にむけて本番環境のワークロードを実行するのに役立つ機能を改善または追加してきました。 リージョンの拡大 – 2025年7月時点で、Oracle Database @AWS を米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで使用できるようになりました。また、世界20のAWSリージョンに拡大する計画も発表しています。このように幅広く利用できるため、さまざまな地域のお客様の多様なニーズに対応できるため、より多くの企業がこのオプションの恩恵を受けることができます。AWSリージョンのワークロード要件に合わせて、さまざまなExadataシステムサイズを選択できます。 Zero-ETL と S3バックアップへの対応 – Amazon Redshift との Zero-ETL統合 による分析が可能になり、抽出、変換、ロード操作のためのデータパイプラインを構築および管理する必要がなくなりました。Zero-ETL統合を使えば、ネットワーク間のデータ転送コストをかけずに、AWSでデータを統合できます。99.9999999% (イレブンナイン) のデータ耐久性を備えた&nbsp; Amazon Simple Storage Service (Amazon S3) &nbsp;のバックアップを提供しています。 Autonomous VMクラスタ – Exadata専用インフラストラクチャ上のExadata VMクラスタに加えて、Autonomous VMクラスタをプロビジョニングできるようになりました。Oracle Autonomous Databaseは、専用のハードウェアとソフトウェアのリソースを使用する完全に管理されたデータベース環境である専用のExadataインフラストラクチャで実行できます。 Oracle Database @AWS は、S3 や Redshift などの AWS サービスへのネットワークパスを直接設定するための Amazon Virtual Private Cloud (Amazon VPC) Lattice、認証と承認のための AWS Identity and Access Management (IAM) 、データベースライフサイクルイベントのモニタリングのための Amazon EventBridge 、インフラストラクチャの自動化のための AWS CloudFormation 、メトリクスの収集とモニタリングのための Amazon CloudWatch 、API 操作のロギングのための AWS CloudTrail など、他の AWS サービスと統合されています。 Oracle Database@AWS 入門 Oracle Database @AWS は 2 つの主要なサービスをサポートしています。1 つは AWS データセンター内の専用インフラストラクチャ上の Oracle Exadata Database Serviceと、専用の Exadata インフラストラクチャ上の Oracle Autonomous Database です。 これらのサービスは、物理的にはAWSリージョンのアベイラビリティーゾーン内に存在し、論理的にはOCIリージョンに存在するため、高速で低遅延の接続を通じてAWSサービスとシームレスに統合できます。 アベイラビリティーゾーン内でOracle Exadata VMクラスターをホストするプライベートで独立したネットワークであるODBネットワークを作成します。次に、VPCで実行されているEC2アプリケーションサーバーにアクセスできるODBピアリングを使用します。詳細については、AWS ドキュメントの 「How Oracle Database@AWS works」 を参照してください。 AWS Marketplaceでプライベートオファーをリクエスト Oracle Database @AWS を開始するには、 AWS Console にアクセスするか、 AWS Marketplaceのプライベートオファー をリクエストしてください。AWSとOracleの営業チームがリクエストを受け取り、お客様のワークロードに最適なオプションを見つけて連絡し、アカウントを有効にします。 Oracle Database @AWS をアクティブ化してアクセスできるようになると、 ダッシュボード を使用してODBネットワーク、Exadataインフラストラクチャ、Exadata VMクラスタまたはAutonomous VMクラスタ、およびODBピアリング接続を作成できます。 詳細については、AWS ドキュメントの「 Onboarding to Oracle Database@AWS 」と&nbsp;「 AWS Marketplace buyer private offers 」をご覧ください。 ODBネットワークの作成 ODBネットワークは、AWS上でOCIインフラストラクチャをホストするプライベートな分離ネットワークです。ODBネットワークは、OCIの子サイト内に存在するネットワークに直接マッピングされ、AWSとOCI間の通信手段として機能します。 ダッシュボード で、「 Create ODB network 」を選択し、ネットワーク名を入力し、アベイラビリティーゾーンを選択し、アプリケーションによって確立されるクライアント用接続と自動バックアップに使用するバックアップ用接続のCIDR範囲を指定します。 oraclevcn.com と固定して、ドメインのプレフィックスとして使用する名前を入力することもできます。たとえば、 myhost と入力した場合、完全修飾ドメイン名は myhost.oraclevcn.com です。 オプションで、ODBネットワークアクセスを設定して、Amazon S3への自動バックアップやZero-ETLのインフラストラクチャに関する設定を行い、Amazon Redshiftを使用してほぼリアルタイムの分析とOracleデータの機械学習を行う準備を行えます。 ODBネットワークを作成したら、EC2アプリケーションサーバーのVPCルートテーブルをODBネットワークのクライアント接続CIDRで更新します。詳細については、AWSドキュメントの「 ODB network 」、「 ODB peering 」、「 Configuring VPC route tables for ODB peering 」を参照してください。 Exadataインフラストラクチャの作成 Oracle Exadataインフラストラクチャは、Oracle Exadata Databaseを実行するデータベースサーバー、ストレージサーバー、ネットワークの基盤となるアーキテクチャです。 Exadataインフラストラクチャの作成を選択し、名前を入力して、デフォルトのアベイラビリティーゾーンを使用してください。次のステップでは、 Exadata.X11M をExadataシステムモデルとして選択できます。また、データベースサーバー（最小２台〜最大３２台）とストレージサーバー（最小３台〜最大６４台、サーバーあたり80TBのストレージ容量）をそれぞれ設定することが可能です。 最後に、スケジュール、パッチモード、OCIメンテナンス通知連絡先など、システムメンテナンスの設定を構成できます。AWSコンソールからインフラストラクチャを作成した後で変更することはできません。しかし、OCIコンソールに移動して変更することはできます。 Exadataインフラストラクチャを削除するには、AWSドキュメントの「 Deleting an Oracle Exadata infrastructure in Oracle Database@AWS 」を参照してください。 Exadata VMクラスターまたはAutonomous VMクラスターを作成 Exadataインフラストラクチャー上にVMクラスターを作成し、同じODBネットワークに異なるOracle Exadataインフラストラクチャーを持つ複数のVMクラスターをデプロイできます。 VMクラスターには2種類あります： Exadata VMクラスターは、Oracle Enterprise Editionのすべての機能を含む完全なOracle Databaseがインストールされた仮想マシンのセットです。 Autonomous VMクラスターは、完全に管理されたデータベースのセットで、人間の介入なしにAI/MLを使用して主要な管理タスクを自動化します。 Exadata VMクラスターの作成 を選択し、VMクラスター名とタイムゾーンを入力し、Bring Your Own License（BYOL）またはライセンスオプションに含まれるライセンスを選択します。次のステップでは、Exadataインフラストラクチャ、grid infrastructureのバージョン、Exadata imageのバージョンを選択できます。データベースサーバーの場合は、各VMのCPUコア数、メモリ、ローカルストレージを選択するか、デフォルト値を選択することができます。 次のステップでは、ODBネットワークを選択し、VMクラスターのプレフィックスを入力することで、接続設定を構成できます。single client access name(SCAN)リスナーへのTCPアクセスのポート番号を入力できます。デフォルトのポートは1521です。または、1024〜8999の範囲でカスタムSCANポートを入力できます。SSHキーペアの場合は、VMクラスターへのSSHアクセスに使用される1つ以上のキーペアの公開鍵部分を入力してください。 次に、診断とタグを選択し、設定を確認して、VMクラスターを作成できます。VMクラスターのサイズにもよりますが、作成プロセスには最大6時間かかることがあります。 Oracle Databaseを作成して管理 VMクラスターの準備が整ったら、OCIコンソールでOracle Exadataデータベースを作成して管理できます。Exadata VMクラスターの詳細ページで「 Manage in OCI 」を選択してください。OCIコンソールにリダイレクトされます。 OCIコンソールでOracle Databaseを作成するときは、Oracle Database 19cまたは23aiを選択できます。プロビジョニングされたデータベースの自動バックアップを有効にする場合は、S3バケットまたはOCIリージョンのOCIオブジェクトストレージを使用できます。詳細については、OCI ドキュメントの 「 Provision Oracle Exadata Database Service in Oracle Database@AWS 」を参照してください。 注意事項 Oracle Database @AWS について知っておくべきことがいくつかあります。 モニタリング — VM クラスター、コンテナデータベース、およびプラガブルデータベースの AWS/ODB 名前空間にある Amazon CloudWatch メトリクスを使用して Oracle Database @AWS をモニタリングできます。AWS CloudTrailは、Oracle Database @AWS に対するすべての AWS API 呼び出しをイベントとしてキャプチャします。CloudTrailのログを使用すると、Oracle Database @AWS に対して行われたリクエスト、リクエストが行われたIPアドレス、リクエストが行われた日時、および追加の詳細を確認できます。詳細については、「 Monitoring Oracle Database@AWS 」をご覧ください。 セキュリティ — IAM を使用して、Oracle Database @AWS リソースと、データを保護するための SSL/TLS 暗号化接続を誰に管理できるかを決定する権限を割り当てることができます。 Amazon EventBridge を使用して、イベント主導型のデータベースをシームレスに運用することもできます。すべてが連携してセキュリティ基準を維持すると同時に、効率的なクラウド運用が可能になります。詳細については、「 Security in Oracle Database@AWS 」をご覧ください。 コンプライアンス — Oracle Database @AWS を使用する場合のコンプライアンス責任は、データの機密性、会社のコンプライアンス目標、および適用される法律と規制によって決まります。お客様は、オラクルのクラウド・コンプライアンスに関する情報を オラクルのウェブサイト で見つけることができます。Oracle Database @AWS は、SOC 1、SOC 2、SOC 3、HIPAA、C5、CSA STAR Attest、CSA STAR Cert、HDS (フランス)、ISO シリーズ (ISO/IEC 9001、20000-1、27001、27017、27018、27701、22301)、PCI DSS、HITRUSTなど、AWSコンプライアンスプログラムの対象範囲内のAWSサービスと統合されています。 サポート — AWSまたはOracleの営業アカウントチームが、現在のデータベースインフラストラクチャの評価、Oracle Database@AWS が組織の要件に最も合致するための方法の決定、およびカスタマイズされた移行戦略とタイムラインの策定を支援します。また、AWSクラウドで実行されるOracleベースのワークロードの設計、デプロイ、管理を専門とする AWS Oracleコンピテンシーパートナー から支援を受けることもできます。 現在利用可能な機能、近日公開予定の機能 Oracle Database @AWS は、AWS マーケットプレイスを通じて米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで利用できるようになりました。Oracle Database @AWS の価格設定と AWS マーケットプレイスのプライベートオファーはOracleによって設定されます。価格に関する具体的な詳細は、 Oracleのサービスの価格設定ペー ジで確認できます。 Oracle Database @AWS は、以下を含む南北アメリカ、ヨーロッパ、アジア太平洋地域のさらに20のAWSリージョンに拡大する予定です: 米国東部（オハイオ）、米国西部（北カリフォルニア）、アジア太平洋（メルボルン）、アジアパシフィック（ムンバイ）、アジアパシフィック（大阪）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、カナダ（中央）、ヨーロッパ（フランクフルト）、ヨーロッパ（ロンドン）、ヨーロッパ（ミラノ）、ヨーロッパ（パリ）、ヨーロッパ（スペイン）、ヨーロッパ（ストックホルム）、ヨーロッパ（チューリッヒ）、南米（サンパウロ） AWS コンソール を使って Oracle Database @AWS を使い始めることができます。詳細については、「 Oracle Database@AWS User Guide 」と OCI のドキュメント にアクセスし、通常の AWS サポートの連絡先または OCI サポート にフィードバックを送ってください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

2025 年 8 月 28 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer Meetup #2 – Amazon Q Developer を業務で活用した成果共有と最新情報 Update – 」のイベントの様子をレポートします。 このイベントは、AWS が提供する生成 AI アシスタント、 Amazon Q Developer をテーマに実施しました。まずソリューションアーキテクトの小西から、Amazon Q Developer と、 AI IDE である “Kiro” の最新情報アップデート情報をご紹介させていただきました。続いて、Amazon Q Developer をご利用いただいている株式会社 LIFULL 様、株式会社マイナビ様から、どのように業務やプロジェクトに活かしているのか、リアルな使い方や工夫、実際に感じた効果について発表していただきました。 現地参加・オンライン参加合わせて 200 名以上の方にご登録いただきました。参加者からは「各社さんの取り組み状況が聞けてとても参考になりました！」との感想をいただきました。これから Amazon Q Developer を導入してみたい方、すでに利用しているがさらに活用したい方、他社の利用状況に興味がある方、それぞれの皆様にご参考いただける情報をご紹介させていただきました。 イベント概要 開催日時: 2025年8月28日 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー 株式会社 LIFULL 様 「Amazon Q Developer 活用による業務効率化と多職種展開」 株式会社 マイナビ様 「Amazon Q Developer 導入実践記 – リスク対策から組織浸透まで」 Konishi Kyosuke, Solutions Architect, Amazon Web Services Japan G.K. 「Amazon Q Developer &amp; Kiro アップデート情報」 Amazon Q Developer &amp; Kiro の最新アップデート情報 スピーカー: Konishi Kyosuke, Solutions Architect, Amazon Web Services Japan G.K. 資料ダウンロードはこちら: Amazon Q Developer &amp; Kiro アップデート情報 はじめに、ソリューションアーキテクトの小西より、Amazon Q Developer と Kiro の最新アップデート情報をご紹介しました。Amazon Q Developer は開発者のための生成 AI アシスタントで、統合開発環境 (IDE)・コマンドライン (CLI)・AWS マネジメントコンソール と、さまざまなシチュエーションで利用者をご支援します。Kiro は仕様駆動開発 (Spec driven development) をコンセプトとした AI IDE で、AI エージェントを最大限活用した開発体験をご提供します。 小西からは Amazon Q Developer の多言語対応 (日本語含) の拡張や、CLI でのカスタムエージェント、マネジメントコンソールでの Agentic 対応などの新機能をご紹介しました。また、Kiro の価格体系の最新情報についてもご説明しました。 お客様事例: 株式会社 LIFULL 様「Amazon Q Developer 活用による業務効率化と多職種展開」 LIFULL 様のご登壇資料は Amazon Q Developer活用による 業務効率化と多職種展開 にて公開されています。 株式会社 LIFULL 様からは、「Amazon Q Developer 活用による業務効率化と多職種展開」と題して、Amazon Q Developer の活用状況について事例紹介をしていただきました。 HTML の生成によるスライド作成の自動化 (この発表資料も！) や、サービス企画におけるプロトタイプ作成に効果測定レポート自動化、アイデア出しなど、エンジニアの利用に限らない、幅広いユースケースをご紹介いただきました。社内での利用者増加トレンドや社内 MCP の利用状況、利用状況ランキング、カスタムエージェントの設定など社内での普及活動についてもご説明いただきました。 お客様事例: 株式会社マイナビ様 「Amazon Q Developer 導入実践記 – リスク対策から組織浸透まで」 ご登壇資料ダウンロードはこちら: Amazon Q Developer 導⼊実践記 – リスク対策から組織浸透まで 株式会社 マイナビ様からは、「Amazon Q Developer 導入実践記 – リスク対策から組織浸透まで」と題して、Amazon Q Developer の活用状況について事例紹介をしていただきました。 Amazon Q Developer を導入する際のリスク観点での検討内容や性能・費用、アクセス権限や暗号化・承認フローといったルール作りのプロセスについてご説明いただきました。また、利用を強制しない形での導入促進活動についてもご紹介いただきました。さらに、/context など Amazon Q Developer の便利機能の紹介や、CI/CD パイプラインのエラー分析、勉強会での活用など運用・利用両方の観点からの活用事例をご共有いただきました。 ネットワーキング 現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 おわりに 今回のイベントでは AWS が提供する生成 AI アシスタントの Amazon Q Developer をいかに導入・活用されているかをお客様の事例を中心にご紹介させていただきました。株式会社 LIFULL 様、株式会社マイナビ様にご登壇いただき、コーディングだけではなく、企画・デザイン・インフラストラクチャの運用など、さまざまな活用方法をご紹介いただきました。Amazon Q Developer、そして Kiro は今後も分野の発展に伴ってサービスアップデートを続けてまいります。 次回の開催予定 次回の Amazon Q Developer Meetup #3 は AI 駆動開発ライフサイクル (AI-DLC) をテーマに開催予定です。詳細は後日公開させていただきますので、 イベント一覧ページ の更新をお待ちください。 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用をご支援しています。Amazon Q Developer や AWS Cloud Development Kit (AWS CDK) を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。