はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの黒田です。 通信業界の企業様を対象に、2025 年 4 月 24 日に AWS Startup Loft Tokyo で「AWS GameDay for Telecom: Winning the DDoS Game」を開催しました。近年増加傾向にあり日本の通信事業者共通の課題である「DDoS 攻撃」への対策をテーマとして、AWS のサービスでどう対応していくのか体験しながら学ぶイベントです。1 チーム最大 3 名にてエントリー頂き、13 企業 / 29 チーム / 84 名のエンジニアの参加する、通信事業者横断のチーム対抗戦となりました。本記事では、当日の概要を皆様にご紹介します。 AWS GameDay とは？ AWS GameDay は、チーム毎の環境で AWS ソリューションを利用して現実世界の技術的問題を解決することを参加者に課題として提示する ゲーム化された学習イベントです。本番環境に近い条件下でシステム障害やセキュリティインシデントを模擬的に発生させ、実際の障害対応と同様の手順で問題解決に取り組み、システムの復旧やインシデント対応を体験します。この演習により、チームは障害対応スキルの向上、システム間の依存関係の把握、組織全体のレジリエンス文化の醸成を図ることができます。詳細は こちら を参照ください。 図1: AWS GameDay for Telecom の様子 Winning the DDoS Game シナリオ概要 本 AWS GameDay for Telecom では、近年急増する DDoS 攻撃への対策をテーマに、参加者がチームを組んで架空の企業「ユニコーンレンタル株式会社」のインフラを守るという設定で、実践的なセキュリティ対策を題材としました。 今回の Winning the DDoS Game シナリオでは、以下のような架空の状況が設定されました： ユニコーンレンタル社が新サービスをローンチし、注文サイトに通常の 100 倍以上の勢いでお客様からのアクセスが殺到 喜びも束の間、大規模な DDoS 攻撃によりサイトがダウン。サイトには突如 “503 Service Temporarily Unavailable” エラーが表示され、ユーザーからの批判が殺到 サイトはいつの間にか直り、サイトにアクセス可能になった。 そこで緊急対応としてお詫びキャンペーンセールを開始 図2: オープニング説明 昨日の失敗を取り戻すべく、社長からの大号令で特別セールキャンペーン開催の決定がなされました。そこで前述のサイトダウンのようにならない様に、たまたま新入社員として入社することになった参加者の皆様には、引継ぎ資料として渡されたアーキテクチャ図を基にこの危機的状況から会社を救うべく、適切な AWS サービスを活用して DDoS 対策を実施して頂きました。 図3: 引継ぎ資料として渡されたアーキテクチャ図 DDoS 対策に有効な AWS サービス (1) AWS Shield Advanced: レイヤー3-4 の保護 AWS Shield Advanced は、DDoS 攻撃の可視化レポートや専用 CloudWatch メトリクス、 AWS WAF と連携したアプリケーション層の自動緩和機能を提供します。24 時間 365 日体制の DDoS 対策専門チーム（Shield レスポンスチーム）からの支援が受けられることも大きなメリットです。保護対象は Elastic Load Balancing (ELB) 、 Amazon Route 53 、 Amazon CloudFront 等です。オンプレミスの HTTP/HTTPS ワークロードも CloudFront 経由で DDoS 保護が可能です。 図4: AWS Shield Standard と Shield Advanced の違い (2) AWS WAF: レイヤー7 の保護 AWS WAF は、Web アプリケーションに送信される HTTP/HTTPS リクエストを監視し、コンテンツへのアクセスを制御するWebアプリケーションファイアウォールです。Amazon CloudFront、 Application Load Balancer 、 Amazon API Gateway 、 AWS AppSync 、 Amazon Cognito 、 AWS App Runner 、などのリソースを保護できます。WebACL または保護パックでルールを定義し、IP アドレス、地理的位置、リクエストヘッダー、SQL インジェクション、クロスサイトスクリプティングなどの条件に基づいて、リクエストの許可・ブロック・カウント・CAPTCHA 実行を制御します。 図5: AWS WAF シナリオを進める上での工夫 本 GameDay for Telecom では生成 AI ツール等を参加者にご活用頂きながら、シナリオを進める上でのチーム内調査・解析の補佐、コミュニケーションの活性化、リアルタイムな競技進捗の可視化による企画側の盛り上げの工夫を施しました。 Generative AI Use Cases JP（略称 GenU*、AWS 独自の生成AIツール）の活用による AI 支援型の補佐 Slackを活用したチーム内/間コミュニケーション リアルタイムスコアボードによる競技進捗の可視化 *GenU は OSS として公開: https://github.com/aws-samples/generative-ai-use-cases-jp 図6: GenU 結果と上位入賞チームのご紹介 シナリオを順調に進めていただき、多くのポイントを獲得なされた上位入賞チームをご紹介します。 図7: GameDay for Telecom 結果 第1位: Team クラソル (Score: 293,700) 荒井 冬樹 氏 小林 優輝 氏 後藤 大輝 氏 第2位: dポマ (Score: 293,650) 伊藤 幹人 氏 酒井 芳章 氏 與那嶺 正美 氏 第3位: Foo (Score: 232,300) 岡田 誠 氏 岡本 康宏 氏 福嶋 慶介 氏 （氏名: 五十音順) 今回の AWS GameDay for Telecom: Winning the DDoS Game の結果ですが、1位と 2位のチームがわずか 50 ポイントという僅差で競り合う、最後の最後まで目が離せない白熱した展開となりました。上位 2 チームは 29 万ポイントを超える高得点を記録し、DDoS 攻撃への対応力の高さを示しました。3位チームも 23 万ポイントを獲得し、全体として参加チームが高い技術力を発揮した対抗戦だったと思います。 まとめ 本 GameDay for Telecom を通じて、参加者の皆様には実践的な DDoS 対策スキルを身につけていただくとともに、AWS の最新セキュリティソリューションについてのご理解を深めて頂きました。また、「実際に行っている障害調査の実施」、「リアリティのあるやり取りを交えての原因分析」、「普段一緒に仕事をしない同僚や他社の方々と同じ目標に向かっての競争・協力」、といった AWS GameDay ならではの価値もご体験頂けました。本イベントで得られた知見は、以下のような実務での課題解決にご活用いただけるかと考えております。 大規模 DDoS 攻撃への防御態勢の構築 インシデント発生時の優先順位付けと対応手順の確立 チーム間連携とコミュニケーションの最適化 AWS 最新セキュリティサービスの実践的活用 今後も AWS は、このような実践的な学習機会を提供し続け、お客様のセキュリティ対策強化を支援して参ります。 このブログの著者 黒田 由民 (Yoshimi Kuroda) 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト

このブログ記事は、AWS ソリューションアーキテクトの吉澤 稔と都築 了太郎が執筆し、住信 SBI ネット銀行様が監修しています。 住信 SBI ネット銀行株式会社（以下、住信 SBI ネット銀行）は、勘定系システムの更改に向けてアマゾン ウェブ サービス（以下、AWS）のクラウド環境を採用することを決定しました。2028 年初旬の本番稼働を目指し、AWS 上での次世代勘定系システムの設計・構築が進められており、移行完了後は、同行の主要システム全てが AWS 上で稼働することとなります。将来的なスケーラビリティを見据えた、デジタルバンク向けの次世代クラウド勘定系アーキテクチャーへの移行により、3,000 万口座を超える膨大なデータボリュームへの対応が可能となるほか、今後の事業拡大にも柔軟に対応できる設計が実現されます。 今後も、AWS を推奨クラウドプロバイダーに選定する住信 SBI ネット銀行は、AWS との連携をさらに強化し、柔軟性と拡張性に優れたクラウドや最先端の生成 AI 技術などを活用して、新たなビジネス価値創出とイノベーションを加速させます。 2017 年クラウドファーストを決定、AWS への移行開始 インターネット専業銀行として 2007 年に開業した住信 SBI ネット銀行は、「銀行を超えたテックカンパニー」を目指し、最先端の IT を駆使したイノベーションにより金融サービスの変革を推進しています。住信 SBI ネット銀行は、2017 年に 「クラウドファースト」 の意思決定を行い、勘定系以外の商用システムの AWS 移行を開始しました。AWS 選定の理由として住信 SBI ネット銀行は、FISC（金融情報システムセンター）の安全対策基準への対応に関する情報や第三者による認証、内部統制、監査に関するポリシーや結果が外部に公開されていることによる信頼性の高さ、AWS の開発力、比較的容易にエンジニアが確保できることにより運用体制の構築がスムーズに進められることなどを挙げています。また、システムの職員には AWS 認定ソリューションアーキテクトの資格取得を必須としており、AWS のサービスを積極的に活用できる体制を整えています。2020 年には、オンプレミスにあったインターネットバンキングシステムの Oracle データベース（DB）を、Amazon Aurora PostgreSQL へと移行完了しました。その後、2023 年邦銀で初めて（同年 8 月時点）、AWS のアジアパシフィック （東京） リージョン（以下、東京リージョン）およびアジアパシフィック （大阪） リージョン（以下、大阪リージョン）を活用したマルチリージョンによる冗長化を実施、インターネットバンキングシステムの可用性の向上を実現しています。 モダナイゼーションへの挑戦 住信 SBI ネット銀行において、2020 年に勘定系以外の商用システムを AWS に移行完了し、インフラ面でのハードウェア調達や構築のボトルネックが解消されました。しかし、2007 年の開業以降、顧客向けサービス開発を優先し機能を集約しながら開発した結果、プログラムの構造が複雑化し、事業のさらなる拡大に支障をきたすケースも生じてきました。そこで、これらの課題を解決し、持続的な成長を実現するため、住信 SBI ネット銀行はモダナイゼーションに着手しました。内製開発でモダナイゼーションを進めるうえで、必要な専門知識などを提供する AWS の　「DevTX プログラム」　を採用しました。同プログラムには、PACE（prototyping and cloud engineering）専門チームとの伴走により、イベントストーミング手法を用いてドメイン駆動設計のファーストステップを実現し、技術的負債の解消と組織文化変革を同時に加速しています。現在、モダナイゼーションの PoC を進めるための準備をし、顧客サービス向上や事業規模拡大に合わせた拡張性の確保を目指し、インターネットバンキングをはじめ主要システムのモダナイゼーションを進めています。 勘定系システムの AWS 移行へ 2025 年 9 月、住信 SBI ネット銀行は、勘定系システムを AWS のクラウド環境に全面移行することを決定しました。住信 SBI ネット銀行は、勘定系システムの更改に向けて、2024 年より既存のオンプレミス環境の継続も含め、拡張性・信頼性・可用性・セキュリティ・費用面などを含む複数の観点から総合的に検討を重ねました。その結果、同行において AWS の豊富な導入実績がありノウハウが蓄積されていたこと、AWS スキルを持つ人材が市場に豊富であること、安全性などから、最終的に AWS への移行を決定しました。すでに運用中の東京リージョンおよび大阪リージョンの東阪マルチリージョンに勘定系システムが加わることにより、システム処理の効率化・俊敏性の向上に加え、障害発生時の迅速な切り替えや災害時の業務継続など、一層のレジリエンシーの向上を実現します。 勘定系システムの AWS 移行の検討において住信 SBI ネット銀行は、AWS が実施するオペレーショナル・レジリエンス ワークショップに参加し、AWS で実現するレジリエンシーについて理解を深めたこともその決定に寄与しました。同ワークショップを通じて住信 SBI ネット銀行は、AWS のベストプラクティスに沿ったシステム設計を行うことで、可用性と回復力が大幅に向上し、障害発生時の迅速な切り替え、災害発生時のビジネス継続性（BCP）が確保できることを確認し、AWS による設計段階から運用まで一貫したサポートにより、安全かつ効率的な移行が実現できる体制を構築しています。 AWS 上に稼働予定の住信 SBI ネット銀行の次世代勘定系システムは、現行のオンプレミスで稼働する IBM 社の NEFSS をベースとして、 Amazon RDS for Db2 をはじめとする AWS のマネージドサービスに移行されます。将来的なスケーラビリティを見据え、クラウドネイティブな AWS のサービスを利用したデジタルバンク向け次世代クラウド勘定系アーキテクチャーに移行することで、3,000 万口座以上のデータボリュームに対応可能となり、さらにその後の事業成長にも柔軟に対応できる設計が実現されます。また、運用コストは約 30 ％削減が見込まれており、安定性・可用性・拡張性・効率性の向上により、開発・運用のスピードと柔軟性を確保できます。 さらに、これまで住信 SBI ネット銀行は、 AWS PrivateLink を活用して、他社のシステムともセキュアかつシームレスな接続を行ってきましたが、AWS に勘定系システムが移行されることで、AWS 上での他のシステムとの連携が容易になるため、サービス開発の高速化や柔軟性の向上が期待されます。これにより、新規システムの開発や機能追加の速度が大幅に向上するとともに、テスト環境の柔軟性も高まりサービス品質の向上も見込めます。その結果、BaaS（Banking as a Service）など先端技術を活用した新サービスの開発・展開が加速されることが期待されています。 住信 SBI ネット銀行株式会社　執行役員 システム副本部長　渡邊 弘様からのコメント 当行は 2017 年のクラウドファースト決定以降、段階的に AWS への移行を進めてきましたが、今回ついに勘定系システムという銀行の心臓部とも言える基幹システムの移行決定に至りました。 拡張性・信頼性・可用性・セキュリティ・費用面など、あらゆる角度から慎重な検討を重ねた結果、これまでの AWS 導入実績で培ったノウハウを活かし、3,000 万口座以上のお客様により安定的かつ効率的なサービス提供が可能になると確信しております。 全ての主要システムが AWS 上で統一されることで、システム間連携の効率化や新サービス開発の高速化が実現し、お客様により良いサービスをスピーディーにお届けできるようになります。 今後も AWS との連携を深め、生成 AI などの最先端技術も積極的に活用しながら、デジタル金融サービスのイノベーションをリードしてまいります。

はじめに SAPシステムは多くの企業のバックボーンであり、重要なビジネスプロセスを管理し、膨大な量の貴重なデータを生成しています。これらの重要なビジネスプロセスとデータは通常、エンタープライズSAPシステムを超えて拡張され、顧客は外部システムとも相互作用する必要があります。組織がより深い洞察と改善された意思決定のためにこのデータを活用しようとする中で、SAP顧客がデータやシステムとどのように相互作用するかを変革する必要性が高まっています。 Generative AIの自然言語処理（NLP）機能は、SAP ユーザーに自然言語クエリを使用して複雑なERPシステムと相互作用する強力なツールを提供し、専門的な技術知識や複雑なSQLクエリの必要性を排除します。これにより組織全体でのデータアクセスが民主化され、ビジネスユーザーが会話型インターフェースを使用してリアルタイムで質問し、レポートを生成し、洞察を得ることができるようになります。 Generative AIをSAPシステムと統合することで、組織は構造化されたERPデータと様々なSAPおよび非SAPソースからの非構造化情報との間のギャップを埋めることができ、ビジネス環境のより包括的な視点を提供します。この統合により、より正確な予測、パーソナライズされた顧客体験、そして企業エコシステム全体にわたるデータ駆動型の意思決定が可能になります。 AWSとSAPは、最先端の生成AIサービス、堅牢なインフラストラクチャ、豊富な実装リソースの包括的なスイートで、Generative AI導入ジャーニーのあらゆる段階で顧客を支援します。これらの提供物はSAPシステムと統合でき、AWSとSAPの広大なクラウドサービスエコシステムを補完します。 このブログ（2部構成シリーズのパート1）では、 Amazon Bedrock と他のAWSサービスを活用して、MS Teams、Slack、Streamlitユーザーインターフェースを通じて統一されたビューで人間の自然言語でSAPおよび非SAPデータソースから洞察を得る方法について説明し、図解します。 このブログシリーズのパート2では、 SAP BTPサービス （ SAP Build Apps 、 SAP Generative AI Hub ）を活用して、SAP Build Appsユーザーインターフェースで統一されたビューで人間の自然言語でSAPおよび非SAPシステムから洞察を得る方法について説明し、図解します。 概要 まず、SAPシステムからデータを抽出するために必要なビジネスロジックを開発します。 Bedrock Knowledge Bases と AWS Secrets Manager を含む様々なAWSサービスによってサポートされる、ビジネスロジックを実行する2つの AWS Lambda 関数を作成します。次に、追加の非SAPデータソースからデータを処理するビジネスロジックの作成に焦点を当て、物流情報を含む Amazon DynamoDB からデータを抽出するために特別に設計された別のlambda関数を実装します。システムの機能を強化するために、一般的なユーザークエリを促進する第3のデータソースとして機能するナレッジベースを確立します。その後、ユーザークエリに基づいてこれらの異なるデータソース間のフローを調整する責任を持つ Amazon Bedrock Agents を実装します。最終段階では、Streamlitを使用してユーザーインターフェースを作成し、アクセシビリティを向上させるためにMS TeamsとSlackとの代替統合オプションも提供します。 図1. ハイレベルアーキテクチャ ウォークスルー ソリューションを5つのステップに構造化しました。各ステップを順を追って説明します： ステップ1 – SAPシステムからデータを取得するビジネスロジックを作成 ステップ2 – 非SAPシステムからデータを取得するビジネスロジックを作成 ステップ3 – 一般的なクエリ用のBedrock Knowledge Basesを作成 ステップ4 – 異なるデータソース間を調整するBedrock Agentsを作成 ステップ5 – Microsoft Teams、Slack、Streamlitでユーザーインターフェースを作成 前提条件 Amazon S3 、AWS Lambda、Amazon Bedrock Agents、Amazon Bedrock Knowledge Bases、 Amazon Bedrock LLM（Claude） 、AWS Secrets Manager、Amazon DynamoDBを操作するための適切なIAM権限を持つAWSアカウント。これらのサービスに慣れていない場合は、先に進む前にそれらを確認することを強く推奨します。 SAP Sales OrderのデータソースとしてSAP ODataサービスをサポートするSAPシステム。 このデモでは標準のODataサービス、SAP Sales Order Service: API_SALES_ORDER_SRV とEntity Set: A_SalesOrder を使用していますが、ユースケースに基づいて任意のODataサービスを使用できます。ODataをインターネット上に公開していますが、SAPシステムの場所によってはインターネットに公開する必要がない場合もあります。ただし、より良いパフォーマンスとセキュリティ体制のためにプライベート接続を設定することを推奨します。詳細については、 SAP S/4HANAでODataサービスを有効にする方法 と AWSアカウントからRISEへの接続 を参照してください。 Slack統合用のSlackアカウントとMS Teams統合用のMS Teamsアカウント[オプション] ステップ1 – SAPシステムからデータを取得するビジネスロジックを作成 I. まず、S4システムの認証情報とシステム接続詳細を保存するためにAWS Secrets Managerでシークレットを作成します。 シークレットタイプを選択 で Other type of secret を選択し、 キー/値ペア の下に以下の詳細を追加します。環境に適用可能なシークレット値を入力してください。 シークレットキー シークレット値 S4_host_details https://<hostname>:<port> S4_username xxxx S4_password xxxx 詳細については、 AWS Secrets Managerシークレットの作成 を参照してください。 II. 第2ステップとして、必要に応じてSAPデータを補完・補足するために2つのBedrock Knowledge Basesを作成します。 Odata-Schema-knowledgebase このKnowledge Basesを使用してLLMにスキーマ詳細を提供し、ユーザークエリに基づいてOdata URLを作成する際に使用する属性について十分な知識をモデルが持てるようにします。 SAP-external-knowledgebase このKnowledge Basesを使用して非SAPデータに補足詳細を提供します。 2つのKnowledge Basesを作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Bedrock Knowledge Base詳細を提供 Knowledge Base名: ユーザーフレンドリーな説明とともに各Knowledge Basesの名前を選択します。 Odata-Schema-knowledgebase と SAP-external-knowledgebase を使用しました。 Knowledge Base説明: ナレッジベースを一意に定義する説明を提供します。 IAM権限 : Create and use a new service role を選択 データソースを設定 データソース : Amazon S3 を選択 データソース名 : 各データソースの名前を選択します。 S3 URI : 各Knowledge Bases用に2つのS3バケットを作成します。 Odata-Schema-knowledgebase 用に Sales_Order_Schema.json ファイルを、 SAP-external-knowledgebase 用に Shipping_Policy.pdf を GitHubリポジトリ から対応するS3バケットにアップロードし、S3 URIを提供します。 データストレージと処理を設定 埋め込みモデル : Amazon Titan Text Embeddings V2 ベクターデータベース : ベクター作成方法として Quick create a new vector store 、ベクターストアとして Amazon OpenSearch Serverless を選択。 詳細については、 Amazon Bedrock Knowledge Basesでデータソースに接続してナレッジベースを作成 を参照してください。 最終的なエントリは以下のようになります： III. 次に、ユーザークエリに基づいてSAPシステムからデータを抽出する2つのLambda関数を作成します。 SAP-Odata-URL-Generation このLambdaは、Knowledge Basesからのスキーマ詳細とAWS Secrets Managerからのホスト詳細によってサポートされるLLMの助けを借りて、ユーザークエリに基づいてOdata URLを生成するビジネスロジックを実行します。 SAP-Sales-Order-Query このLambda関数は、SAPシステムからデータを取得するためのコアビジネスロジックを実行します。SAP-Odata-URL-Generation Lambdaによって提供されるOData URLを利用し、AWS Secrets Managerに保存されたシステム認証情報に安全にアクセスします。その後、関数は取得したデータを処理し、bedrockを通じてLLMを活用し、最終的に構造化された情報をBedrock Agentに提示してさらなる使用に供します。 関数を作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Author from scratch を選択 関数名 : ユーザーフレンドリーな説明とともに各関数の名前を選択します。 SAP-Odata-URL-Generation と SAP-Sales-Order-Query を選択しました。 ランタイム : Python 3.13 アーキテクチャ : x86_64 コード : 関数 SAP-Odata-URL-Generation 用に SAP-Odata-URL-Generation.py のコードを、 SAP-Sales-Order-Query 用に SAP-Sales-Order-Query.py を GitHubリポジトリ からコピーします。 注意： kb_id、SecretIdなど、デプロイメント固有の値でコードを適応させてください。 設定 : メモリ : 1024MB 、 タイムアウト： 15min レイヤー : lambda関数に requests モジュールを追加するために、 GitHubリポジトリ から requests-layer.zip レイヤーを追加 権限： Lambda関数に以下の権限を設定する必要があります。 SAP-Odata-URL-Generation： 実行ロール – lambda基本ロールに加えて、以下のアクション bedrock:InvokeModel 、 bedrock-agent-runtime:Retrieve 、 secretsmanager:GetSecretValue を持つ新しいIAMポリシーを作成、 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 SAP-Sales-Order-Query： 実行ロール – lambda基本ロールに加えて、以下のアクション bedrock:InvokeModel 、 secretsmanager:GetSecretValue を持つ新しいIAMポリシーを作成 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 詳細については、 PythonでLambda関数を構築 と Python Lambda関数のレイヤーの操作 を参照してください。 ステップ2 – 非SAPシステムからデータを取得するビジネスロジックを作成 I. まず、以下の入力でDynamoDBテーブルを作成します。 テーブル名 : logistics パーティションキー： order_id GitHubリポジトリ の Items.json ファイルを使用してDynamoDBテーブルにアイテムを作成します。詳細については、 JSONファイルからAmazon DynamoDBテーブルアイテムを作成 を参照してください。 II. 次に、ユーザークエリに基づいてDynamoDBテーブルからデータを抽出するLambda関数を作成します。 Author from scratch を選択 関数名 : ユーザーフレンドリーな説明とともに関数の名前を選択します。 Logistics-System を選択しました ランタイム : Python 3.13 アーキテクチャ : x86_64 設定 : メモリ : 1024MB 、 タイムアウト： 15min コード : GitHubリポジトリ から Logistics-System.py のコードをコピーします。 権限 : Lambda関数に以下の権限を追加します。 実行ロール – lambda基本ロールに加えて、以下のアクション dynamodb:Query 、 dynamodb:DescribeTable を持つ新しいIAMポリシーを作成、 リソースベースポリシーステートメント – ステップ4で作成するBedrock Agent ARNへの lambda:InvokeFunction アクセス。 ステップ3 – 一般的なクエリ用のKnowledge Basesを作成 次に、3番目のナレッジベースを作成します。このナレッジベースは一般情報リポジトリとして機能します。ユーザーは、組織情報から特定の専門知識まで、必要に応じて様々なトピックについて学ぶためにこのリソースにアクセスできます。 General-information-knowledgebase : このデモでは、このナレッジベースを使用してSAPビジネスプロセスに関するガイダンスを提供します。 Knowledge Basesを作成する際に以下の入力を考慮し、残りはデフォルトのままにしました。 Knowledge Base詳細を提供 Knowledge Base名 : 各Knowledge Basesの名前を選択します。ユーザーフレンドリーな説明とともに General-information-knowledgebase を使用しました。 IAM権限 : Create and use a new service role を選択 データソースを設定 データソース : Amazon S3 を選択 データソース名 : 選択に応じてデータソースの名前を選択します。 S3 URI : S3バケットを作成し、GitHubリポジトリから「 How to create SAP Sales Order pdf 」をアップロードし、対応する S3 URI を提供します。 データストレージと処理を設定 埋め込みモデル : Amazon Titan Text Embeddings V2 ベクターデータベース : ベクター作成方法として Quick create a new vector store 、ベクターストアとして Amazon OpenSearch Serverless を選択。 最終的なエントリは以下のようになります： ステップ4 – Bedrock Agentを作成： このステップでは、前のステップで作成した異なるデータソース間を調整してユーザークエリに応答するBedrock Agentを作成します。 bedrock agentを作成する際に以下の入力を考慮し、他のすべての設定はデフォルト値のままにしました。 Agent詳細： Agent名 : エージェントの名前とユーザーフレンドリーな説明を選択します。 Business-Query-System と名付けました。 Agentリソースロール : Create and use a new service role を選択 モデルを選択 : Claude 3 Sonnet v1 を選択。異なるLLMを選択することもできますが、望ましい応答を得るためにプロンプトを適宜修正する必要があります。 Agentへの指示 : Agentに何をしてほしいかを明確に説明する正確で段階的な指示を与えます。 You are an AI assistant helping users in querying SAP sales data directly from SAP system and shipping details from logistic system. You also help users with general queries about business process from the company knowledge base. 追加設定 : ユーザー入力 で Enabled を選択 アクショングループ： アクショングループは、エージェントがユーザーの達成を支援すべきタスクを定義します。 アクショングループ : SAP-Sales-Order 。このアクショングループを使用してSAP Sales orderに関連するクエリを処理します。 アクショングループ名 : アクショングループの名前を選択し、ユーザーフレンドリーな説明を入力します。 SAP-Sales-Order と名付けました アクショングループタイプ : Define with function details アクショングループ呼び出し : Select an existing Lambda function を選択し、ステップ1で作成したlambda関数 SAP-Sales-Order-Query を選択 アクショングループ関数1名 : SalesOrder として関数の説明を提供します。 アクショングループ : Logistics-System 。このアクショングループを使用して販売注文の物流情報に関連するクエリを処理します。 アクショングループ名： アクショングループの名前を選択し、ユーザーフレンドリーな説明を入力します。 Logistics-System と名付けました アクショングループタイプ : Define with API schemas アクショングループ呼び出し : Select an existing Lambda function を選択し、ステップ2で作成したlambda関数 Logistics-System を選択。 アクショングループスキーマ : Select an existing API schema 。 S3 Url : S3バケットを作成し、 GitHubリポジトリ から logistics.json ファイルをS3バケットにアップロードし、バケットのS3 Urlを提供します。 メモリ： Enabled を選択し、 メモリ期間 を 2 days 、 最大最近セッション数 を 20 に設定。 Knowledge Bases： 以前に作成したナレッジベースを追加 Knowledge Baseを選択 : SAP-external-knowledgebase AgentのKnowledge Base指示： SAPシステム外の情報が必要で、SAPシステムデータと組み合わせて応答を完成させる場合にこのナレッジベースを使用 Knowledge Baseを選択 : General-Information-knowledgebase AgentのKnowledge Base指示： SAPシステムから利用できないユーザーからの一般的なビジネス質問に答えるためにこのナレッジベースを使用。 オーケストレーション戦略詳細 – Default orchestration 。Bedrock agentsはデフォルトプロンプト テンプレート を提供しますが、特定の要件に合わせて調整できます。特定のユースケース要件に合わせて以下のプロンプトテンプレートをカスタマイズします。 前処理 : Override pre-processing template defaults を選択。プロンプトテンプレートに以下のセクションを追加します。 -Category F: Questions that can be answered or assisted by our function calling agent using the functions it has been provided and arguments from within conversation history or relevant arguments it can gather using the askuser function AND also needs external data from the knowledge base to complete the response. Combine data from the SAP or non-SAP Logistic system and the external knowledge base to prepare the final answer オーケストレーション : Override orchestration template defaults を選択。プロンプトテンプレートの対応するセクションの下に以下のテキストを追加します。 $knowledge_base_guideline$ - If any data is not updated in the Logistic system like order shipping date, then check the knowledge base named 'SAP-external-knowledgebase' to look for the estimated delivery timeline as per the shipping category. Then consider that timeline and add the timeline to the date of 'Order Received' and share the estimated the shipping date with the user - If the SAP system throws any error due to unavailability of the requested data, check the knowledge base named 'SAP-external-knowledgebase' to look for the explanation of the ERROR CODE. Respond to the user with the explanation of the error code ONLY $tools_guidelines$ [ このセクションは存在しないため、作成する必要があります ] - Invoke tool 'SAP-Sales-Order' ONLY for any questions related to sales order - Invoke tool 'Logistics-System' ONLY for any shipping details for the sales order - Do NOT invoke both tools 'SAP-Sales-Order' and 'Logistics-System' unless user requested for both the information. $multiple_tools_guidelines$ [ このセクションは存在しないため、作成する必要があります ] - If user asks question which needs to invoke more than one tool. Invoke the tools one by one. Collect the response from both the tools and then combine them before responding to the users. For example, if user requests for both Sales order and Logistic information. First fetch the Sales Order details with Sales Order tool. Then fetch logistic details from Logistic tool. Finally combine both responses into one when responding to the user. すべての詳細を入力したら 保存 し、 準備 を選択して最新の変更を更新します。エージェント概要ページに移動するには 保存して終了 を選択します。 最後に、アプリケーションで使用するエージェントの特定のスナップショットまたはバージョンを持つために エイリアス を作成します。 作成 を選択し、ユーザーフレンドリーな 説明 とともに エイリアス名 を提供します。 スループットをデフォルトの オンデマンド にしたバージョンで 新しいバージョンを作成してこのエイリアスに関連付ける を選択します。 詳細については、 エージェントを手動で作成および設定 を参照してください。 最終的なエントリは以下のようになります： ご覧のように、エージェントの複数のエイリアスとバージョンを作成し、任意のエイリアスを選択してアプリケーションに特定のスナップショットまたはバージョンを統合できます。 次に、bedrock agentがそれらを呼び出せるようにLambda関数のIAMロールを調整する必要があります。 Lambdaのリソースベースポリシーの使用 の手順に従い、Amazon Bedrockがエージェントのアクショングループ用にLambda関数にアクセスできるようにするために、必要に応じて ${values} を置き換えて、以下のリソースベースポリシーをLambda関数にアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AccessLambdaFunction", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:${region}:${account- id}:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "${account-id}" }, "ArnLike": { "AWS:SourceArn": "arn:aws:bedrock:${region}:${account-id}:agent/${agent-id}" } } } ] } 私のポリシーは以下のようになります { "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "bedrock-agent-sales", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:1234567xxxx:function:SAP-Sales-Order-Query", "Condition": { "StringEquals": { "AWS:SourceAccount": "1234567xxxx" }, "AWS:SourceArn": { "arn:aws:bedrock:us-east-1: 1234567xxxx:agent/VX5FAWE3OO" } } } ] } ステップ5 – Microsoft Teams、Slack、Streamlitでユーザーインターフェースを作成 このステップでは、ユーザーがBedrock agentと相互作用できるユーザーインターフェースの開発を行います。 Microsoft Teams – この統合には、MS Teams（適切な権限を持つ）と Amazon Q Developer in chat application の両方へのアクセスが必要です。Amazon Q Developer in chat applications（以前のAWS Chatbot）により、Microsoft TeamsでGenAI Bedrock Agentsと相互作用できます。 ステップ1: アプリアクセスを設定： Microsoft Teamsが組織管理者によってインストールされ、承認されています。 ステップ2: Teamsチャンネルを設定： MS Teams標準チャンネルを作成するか既存のものを使用し、Amazon Q DeveloperをチャンネルにAmazon Q Developerを追加します。[ 注意： Microsoft Teamsは現在プライベートチャンネルでAmazon Q Developerをサポートしていない ため、標準チャンネルが必要です] Microsoft Teamsで、チーム名を見つけて選択し、 チームを管理 を選択します。 アプリ を選択し、 その他のアプリ を選択します。 検索バーに Amazon Q Developer と入力してAmazon Q Developerを見つけます。 ボットを選択します。 チームに追加 を選択し、プロンプトを完了します   ステップ3: TeamsクライアントのAmazon Q Developerを設定 このステップでは、 Amazon Q Developer in chat Applications にMS Teamsチャンネルへのアクセスを提供します。 AWSコンソールで Amazon Q Developer in chat applications を開きます。 チャットクライアントを設定 の下で、 Microsoft Teams を選択し、前のステップで作成したMicrosoft TeamsチャンネルURLをコピーして貼り付け、 設定 を選択します。[ Amazon Q DeveloperがあなたのAmazon Q Developerがあなたの情報にアクセスする権限を要求するTeams認証ページにリダイレクトされます]。 Microsoft Teams認証ページで、 承認 を選択します。左側に、Microsoft TeamsでTeamsチャンネルがリストされているのが確認できるはずです。 次に、MS Teamsチャンネルを設定に関連付けます。 Amazon Q Developerコンソールの Teams詳細 ページで、 新しいチャンネルを設定 を選択します。設定に以下の入力を使用し、残りはデフォルトのままにします。 設定詳細 : 設定名 : 設定の名前を選択します。 aws-sap-demos-team と名付けました Microsoft Teamsチャンネル チャンネルURL : ステップ2で作成したMicrosoft TeamsチャンネルURLをコピーして貼り付けます。 権限 ロール設定 : チャンネルロール を選択 チャンネルロール: テンプレートを使用してIAMロールを作成 を選択 ロール名: 選択した名前を選択します。 awschatbot-sap-genai-teams-role  と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role  に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:<AWS Account ID>:agent-alias/<Bedrock Agent ID>/<Agent Alias ID>/" ] } Amazon Bedrock agentをチャットチャンネルに追加するには、 @Amazon Q connector add connector_name arn:aws:bedrock:aws-region : AWSAccountID :agent/ AgentID AliasID . と入力します。選択したコネクタ名を選択してください。 私のエントリは以下のようになります。 @Amazon Q connector add order_assistant arn:aws:bedrock:us-east-1:xxxxxxx:agent/VX5FAWE3OO VG92WRF1JI 詳細については、 チュートリアル：Microsoft Teamsを開始する を参照してください。 Teamsインターフェースは以下のようになります Slack – この統合には、Slack（適切な権限を持つ）と Amazon Q Developer in chat application の両方へのアクセスが必要です。Amazon Q Developer in chat applications（以前のAWS Chatbot）により、SlackでGenAI Bedrock Agentsと相互作用できます。 ステップ1: アプリアクセスを設定： ワークスペース管理者は、ワークスペース内でのAmazon Q Developerアプリの使用を承認する必要があります。 ステップ2: Slackチャンネルを設定： slackチャンネルを作成するか既存のものを使用し、Amazon Q DeveloperをSlackチャンネルに追加します。 Slackチャンネルで、 /invite @Amazon Q と入力し、 招待する を選択します ステップ3: SlackクライアントのAmazon Q Developerを設定 このステップでは、 Amazon Q Developer in chat Applications にSlackワークスペースへのアクセスを提供します。 AWSコンソールで Amazon Q Developer in chat applications を開きます。 チャットクライアントを設定 の下で、 Slack を選択し、 設定 を選択します。[ Amazon Q Developerがあなたの情報にアクセスする権限を要求するSlackの認証ページにリダイレクトされます]。 Amazon Q Developerで使用したいSlackワークスペースを選択し、 許可 を選択します。 左側に、SlackでSlackワークスペースがリストされているのが確認できるはずです。 次に、チャンネルを設定に関連付けます。 Amazon Q Developerコンソールの ワークスペース詳細 ページで、 新しいチャンネルを設定 を選択します。設定に以下の入力を使用し、残りはデフォルトのままにします。 設定詳細 : 設定名 : 設定の名前を選択します。 sap-genai-slack-chatbot と名付けました Amazon内部設定 アカウント分類 : 非本番 を選択 Slackチャンネル チャンネルID : ステップ2で設定したslackチャンネルのチャンネルIDを提供します。 権限 ロール設定 : チャンネルロール を選択 チャンネルロール: テンプレートを使用してIAMロールを作成 を選択 ロール名: 選択した名前を選択します。 aws-sap-genai-chatbot-role  と名付けました ポリシー テンプレート : Amazon Q Developer access permissions チャンネルガードレールポリシー[ポリシー名]: AWSLambdaBasicExecutionRole 、 AmazonQDeveloperAccess。 要件に応じてIAMポリシーを調整できますが、常に 最小権限 権限 のベストプラクティスに従うことを推奨します。 ステップ4: 次に、エージェントをチャットチャンネルに接続します Amazon Q Developer Bedrock Agentコネクタには bedrock:InvokeAgent IAMアクションが必要です。 前のステップで作成したIAMロール： awschatbot-sap-genai-teams-role  に以下のポリシーを追加します。 { "Sid": "AllowInvokeBedrockAgent", "Effect": "Allow", "Action": "bedrock:InvokeAgent", "Resource": [ "arn:aws:bedrock:aws-region:<AWS Account ID>:agent-alias/<Bedrock Agent ID>/<Agent Alias ID>/" ] } Amazon Bedrock agentをチャットチャンネルに追加するには、以下のように入力します。選択したコネクタ名を選択してください。 @Amazon Q connector add connector_name arn:aws:bedrock:aws-region: AWSAccountID :agent/ AgentID AliasID . 私のエントリは以下のようになります。 @Amazon Q connector add order_assistant arn:aws:bedrock:us-east-1:xxxxxxx:agent/VX5FAWE3OO VG92WRF1JI 詳細については、 チュートリアル：Slackを開始する を参照してください。 Slackインターフェースは以下のようになります Streamlit – Streamlitは、pythonスクリプト用のインタラクティブなWebアプリを構築するために一般的に使用されるオープンソースのPythonフレームワークです。Amazon EC2インスタンスでアプリケーションをホストするために以下の手順に従いました。 EC2インスタンスを起動します。Amazon Linux t2.microインスタンスを考慮しました。 HTTP/HTTPSトラフィック（ポート80/443/8501または使用を選択した他のポート）を許可する必要なセキュリティグループでEC2インスタンスを設定 以下のように環境を準備 必要なパッケージをインストール $sudo apt update $sudo apt-get install python3-venv 仮想環境を設定 $mkdir streamlit-demo $cd streamlit-demo $python3 -m venv venv $source venv/bin/activate Streamlitをインストール $pip install streamlit Vi/Vim/nanoエディタを使用してstreamlit-app.pyという名前のファイルを作成し、 GitHubリポジトリ から streamlit-app.py のコードをコピーします。 以下のコマンドでStreamlitアプリを実行 $streamlit run streamlit-app.py 以下のコマンドでstreamlitアプリをバックグラウンドで実行 $nohup streamlit run streamlit-app.py & Streamlitは8501から1ずつ増加して利用可能なポートを割り当てます。streamlitに特定のポートを考慮させたい場合は、以下のコマンドを使用できます $streamlit run streamlit-app.py --server.port XXXX  上記のコマンドを実行した後、以下に示すように、ブラウザでStreamlitアプリケーションを開くURLを確認できました Streamlitアプリケーションは以下のようになります コスト 大規模言語モデル（LLM）の運用には、相当なインフラストラクチャ、開発、保守コストが伴います。しかし、Amazon BedrockなどのAWSサービスは、簡素化されたインフラストラクチャ管理、合理化された開発プロセス、柔軟な価格モデル、選択したLLMにアクセスするための様々なコスト最適化オプションを通じて、費用を大幅に削減できます。 AWSサービス – US East（N. Virginia） コスト 見積もり[1時間実行] Bedrock – Foundation Model LLM推論[Claude 3.5 Sonnet] 100K入力、200K出力 $3.3 Bedrock – 埋め込みモデル推論[Amazon Titan Text Embeddings v2] 100ドキュメント、各平均500語 $0.10 OpenSearch Compute Unit（OCU）– インデックス作成 2 OCU[最小2 OCU] $0.48 OpenSearch Compute Unit（OCU）– 検索とクエリ 2 OCU[最小2 OCU] $0.48 OpenSearch管理ストレージ 10GB $0.24 EC2インスタンス[Streamlitアプリ] t2.micro $ 0.0116 Lambda、Secrets Manager、DynamoDB $ 0.2                     1時間のアプリケーション使用の推定コスト – $4.8116 詳細については、 Amazon Bedrock価格 、 Amazon OpenSearch Service価格 、 Amazon EC2オンデマンド価格 、 AWS Lambda価格 、 AWS Secrets Manager価格 、 Amazon DynamoDB価格 を参照してください。 結論 このブログ投稿では、Amazon Bedrockに焦点を当てたAWSサービスを使用して、SAPと非SAPシステムの両方とシームレスに相互作用するインテリジェントな仮想アシスタントを作成する方法を実演しています。このソリューションは、販売注文データ用のSAPシステム、物流情報用の非SAPシステム、補足詳細用のKnowledge Basesを統合し、Streamlit、Microsoft Teams、Slackを含む複数のユーザーインターフェースを通じてアクセス可能です。Lambda、Bedrock、Secrets Manager、DynamoDBなどのAWSサービススイートを活用することで、実装は複雑なエンタープライズシステムとの自然言語相互作用を可能にし、堅牢なセキュリティを維持しながら多様なデータソースへの統一アクセスを提供します。サーバーレスアーキテクチャと従量課金制価格モデルにより、これは会話型AIインターフェースを通じてデータアクセス機能を強化しようとする組織にとってアクセス可能で費用対効果の高いソリューションとなります。このブログ投稿では、このソリューションを実装するための詳細な段階的ガイドを提供し、企業がSAPおよび非SAP環境で生成AIを活用する道を開きます。 このソリューションを実装することで、エンタープライズデータとの相互作用を変革する実践的な経験を得てください。 Amazon AgentCore（プレビュー） でAIエージェントを安全に大規模にデプロイ・運用、予測分析用の Amazon Forecast 、インテリジェントドキュメント処理用の Amazon Textract 、言語翻訳用の Amazon Translate 、自然言語処理用の Amazon Comprehend を含む包括的な機械学習サービススイートを探索してデジタル変革を加速してください。これらのサービスはSAPとシームレスに統合し、様々なビジネスニーズに対応し、組織の新しい可能性を解き放ちます。 何千もの顧客がSAPの移行とイノベーションでAWSを信頼する理由を学ぶには、 AWS for SAP ページをご覧ください。 本ブログはパートナー SA 松本が翻訳しました。原文は こちら です。

本ブログは 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 のローンチをはじめとする多くの大規模プログラムを推進してきました。